- Startseite
- Forum
- Wissen
- Fahrzeugtechnik
- theoretische Haltbarkeit von Auto
theoretische Haltbarkeit von Auto
Folgende Frage treibt mich schon länger um. Mir fehlt leider das nötige technische Wissen, um sie selber beantworten zu können:
Woran geht ein Auto eigentlich zu Grunde?
Um die Frage diskutieren zu können, würde ich vorschlagen, wir nehmen folgende Bedingungen an:
- Auto wird nach Herstellerangaben Scheckheftgepflegt
- Fahrerprofil ist auf die Kilometer bezogen so was wie 70% BAB / 20% Landstraße / 10% Stadt
- Fahrer geht normal mit seinem Auto um.
- Äußere Faktoren lassen wir mal außen vor (Unfälle oder auch Durchrosten)
- Wir fahren ca 50.000 km im Jahr
Wenn nun alle Services eingehalten werden und der Fahrer sorgsam mit seinem Auto umgeht, woran stirbt denn ein Auto dann?
Beste Antwort im Thema
Die meisten sterben aus Langeweile und werden nach Sueden oder Osten verkauft.
Ähnliche Themen
620 Antworten
Konnte leider nur 1x DANKE drücken! :(
:eek:
@subbukus: Also zwischen dem Steuergerät eines Oldtimers und einer Mercedes S Klasse gibt es schon unterschiede. In den "oberklasse" Wägen kommen mittlerweile mindestens 4 verschiedene Bus Systeme zum einsatz, jedes davon proprietär, die Entwickler dieser Systeme wollen ja auch was verdienen.
Zur Bauteildiskussion: Naja, etwas mehr als in einem Ghettoblaster steckt schon drin. Grade sachen wie Motorelektronik oder ABS/EDS/ESP sind alles Echtzeitsysteme, deren Entwicklung und Programmierung ist doch etwas aufwendiger als die eines Radios.... Dazu kommt, dass da nicht 0815 Widerstände und Standard Transistoren drinnen sind, sondern schon recht hochwertige Bauteile die auch mal 10-20 Jahre halten (sollten).
Ein High End Prozessor für den Heim-PC kostet auch 500 - 1000 Euro, Mainboard nochmal 250, Grafikkarte 500. Da beschwert sich auch niemand.
und nochmal subbukus: Beachtliche Leistung, Zweifellos. Aber stell dir vor du hättest das für eine Firma machen müssen, und die müssen garantieren dass dein Code funktioniert (Gibst du etwa Garantie für Software ab? Wer würde so etwas schon machen?), die Zahlen sich dumm und blöd um eine Weltweite Zulassung zu haben.
Vgl. Pharmaindustrie, eine Arzneimittelzulassung ist auch teuer, nicht zuletzt kommen Medikamentenpreise davon. Nicht immer sind es die pösen pösen Premiumhersteller die sich einfach ohne Ende bereichern wollen. Sicher auch, aber die Preise sind Teilweise gerechtfertigt.
Warum ich für meinen 20 Jahren alten Audi allerdings fast 1000 euro für einen Kabelbaum hinblättern muss, konnte mir bis heute keiner Sagen. Denn Kupfer ist Kupfer. egal was.
Also ich hab mir in China gerade eine Smartphone bestellt da sind 8 Kerne drin mit je 1,7 Ghz, dazu einen Grafikchip der wohl besser ist als mein erstes Thinkpad. Das hatte auch nur ein Kern und der hatte 1,7Ghz. Das Smartphone kostet dort 125€, also ich weiß nicht was die machen das die CPU so teuer sind für Desktop PC. Die sterben ab eh aus. Das kaufen nur noch Hardcore Gamer und Firmen, Uni etc.
Für den Hausgebrauch werden portable Geräte gekauft. Aktuell sehr viele Pads und Tabletts und immer weniger Notebooks.
Ja, davon werden aber auch tatsächlich MILLIONEN produziert. Was man von einem Auto STG so leicht nicht sagen kann. Und einen 1.7Ghz mobile ARM prozessor mit einer richtigen workstation cpu zu vergleichen... naja das hinkt etwas.
Naja, wenn Sukkubus nicht gerade ein Entwickler für KFZ-Steuergeräte eines bestimmten Herstellers ist, dann frage ich mich schon, wo er die Informationen her hat, um die, in diesen Steuergeräten verbauten Custom-Chips nach eigenem Gusto neu programmieren zu können, und den "Schrott der hauseigenen Programmierer" zu beseitigen. Auf dem Level, von dem wir hier reden, gibt es nix in der Bucht, oder sonst wo.
Diese Chips werden auch nicht in so großen Stückzahlen gefertigt, dass jemand vom Franzis-Verlag, oder sonst wer, ein "Wie programmiere ich das Ding"-Buch darüber schreiben könnte!!
Deswegen nennt man die auch Custom-Chips, weil die nur für einen bestimmten Kunden in begrenzter Auflage hergestellt werden.
Die Funktionen dieser Chips sind oberstes Betriebsgeheimnis!
Schon aus dem Grund, weil man es der Konkurrenz nicht zu leicht machen will.
Sicherlich jedoch nicht, um private Spezialisten, die das besser, als die eigentlichen Entwickler selbst, programmieren könnten, zu behindern.
Hier geht es darum, Industriespionage zu verhindern!
Einen Programm zu de-assemblieren, ist nur möglich, wenn man weiß, wie es assembliert wurde!
VW wird z.B. an geneigte Kunden natürlich sehr gerne seinen Assemblercode rausrücken, und seine Produkte lieber als Open-Source vertreiben... :D
Aber auch, wenn man diese Hürde geschafft hätte, weiß man noch lange nichts über die eigentlichen Funktionen des Geräts, das man da programmiert, zumal der de-assemblierte Code so was von unleserlich wird, dass man sich sowieso besser eine Glaskugel kaufen könnte.
Dann hat so ein Hersteller noch die dumme Angewohnheit, da zwei bis dreimal im Jahr gravierende Änderungen durchzuführen, die irgendwelche Datenblätter des vorhergehenden Steuergeräts absolut obsolet macht.
Ohne eine genaue Beschreibung so eines Custom-Chips ist es einfach so gut, wie unmöglich, da etwas an dessen Ansteuerungs-Programm zu ändern, ohne dass man da a'la Try and Error, gerade im Auto, sein Leben riskiert!
Die Betriebserlaubnis ja sowieso!
*** Und bevor jetzt die Frage kommt: Nein, so was kann man nicht mit VCDS programmieren, und schon gar nicht mit einem OBD-Programmiergerät!! Das ist die sogenannte Firmware, die da 'reingeflasht' wird. Passt die nicht zu dem Steuergerät, so ist das hinterher so dumm, wie ein Holz-Klotz...***
Es mag sein, dass solche Bauteil-Informationen für historische Fahrzeuge (Die Frage ist jedoch, was historisch ist: So was gibt es ja noch nicht so lange) mittlerweile mehr, oder weniger legal im Internet verfügbar sind. Doch für ein aktuelles Fahrzeug eher kaum!
Und, sogar, wenn ich Assemblercode beherrsche, und alle Programmiertricks, würde ich mir nie anmaßen, z.B. das ABS-Steuergerät eines Serienherstellers besser zu programmieren und anzusteuern, als der, der das zu seinem Programm hat entwickeln lassen...
Die hatten da ein Pflichtenheft, um eine bestimmte Funktion zu realisieren.
Dazu mussten dann Änderungen in den Chips der Steuergeräte her. Das wurde an Subunternehmen delegiert. ist das Programm fertig, der Chip verfügbar, dann muss getestet werden. Waren die Tests erfolgreich, geht es damit ans KBA zur Abnahme.
Und Hallo: Das ist eine verdammt teure Geschichte!!
So Long...
So Long...
Zitat:
@Triumph BGH 125 schrieb am 21. Oktober 2014 um 02:43:53 Uhr:
Und Hallo: Das ist eine verdammt teure Geschichte!!
So Long...
So Long...
Ja verdammt teuer und eine elend lange (Entwicklungs)geschichte. Man könnte sagen, development takes So Long..., so very, very long. Der heutige konstruktive Ansatz ist schlicht eine Fehlentwicklung. Da muß dringend etwas passieren, um markenübergreifend und erdweit einerseits die Anzahl der im einzelnen Fahrzeug verbauten Steuergeräte drastisch zu verringern, andererseits dann auf Großserienstückzahlen von mehreren Millionen jährlich zu kommen. Das passt nahtlos in das längst bestehende Konzept des Outsourcing, also ganze Baugruppen markenübergreifend von den großen Zulieferfirmen entwickeln und produzieren zu lassen.
Erfreulicherweise ist z.B. Siemens an diesem Thema dran, Stichwort "Race":
Zitat:
Was ist Race?
Bei Race geht es darum, das Bordnetz beziehungsweise die Steuergeräte an Bord der Autos grundlegend zu simplifizieren. Race schafft es, die übliche Anzahl von 60 bis 70 Steuergeräten auf drei oder vier zu reduzieren. Wenn man bisher eine Fahrzeugfunktionalität ändern wollte, dann musste man ein oder mehrere Steuergeräte ersetzen oder zusätzlich neue Steuergeräte plus einer Verkabelung ins Fahrzeug einbauen. Das ist viel zu aufwendig und zu teuer. Und deshalb passierte das nicht.
Mit Race hat man das Problem dieser Hardware-Komponenten nicht, weil die Funktionalität nicht an die Hardware geknüpft, sondern eine Frage der Software ist. Änderungen, auch nachträgliche Änderungen, geschehen also über das Aufspielen neuer Software, wie beim Computer. Das ist ein Riesenschritt.
http://adacemobility.wordpress.com/.../#more-10524
Die Herstellerinteressen werden sich schon mit DRM so schützen lassen, daß die Fahrzeuge ausstattungsabhängig nur begrenzte Funktionen freigeschaltet bekommen. Bei der Softwareentwicklung läßt sich dann prinzipiell jeweils auf dem bisher erreichten Stand an Funktionalität und Sicherheit aufbauen und in einzelnen Punkten weiterentwickeln. Die Hersteller können an ihren diversen Alleinstellungsmerkmalen festhalten. Es muß aber nicht jedesmal das Rad neu erfunden werden.
Damit werden sich die Kosten für Hard- und Software drastisch senken lassen. Wieweit die Hersteller dann dazu bereit sein werden, dem kaufenden Kunden auch ein paar Brosamen dieser Kosteneinsparung zukommen zu lassen, ist ein anderes Thema.
Zitat:
@Triumph BGH 125 schrieb am 21. Oktober 2014 um 02:43:53 Uhr:
Einen Programm zu de-assemblieren, ist nur möglich, wenn man weiß, wie es assembliert wurde!
VW wird z.B. an geneigte Kunden natürlich sehr gerne seinen Assemblercode rausrücken, und seine Produkte lieber als Open-Source vertreiben... :D
Aber auch, wenn man diese Hürde geschafft hätte, weiß man noch lange nichts über die eigentlichen Funktionen des Geräts, das man da programmiert, zumal der de-assemblierte Code so was von unleserlich wird, dass man sich sowieso besser eine Glaskugel kaufen könnte.
absoluter blödsinn von einem, der wahrscheinlich bestenfalls mal basic als programmiersprache gesehen hat.
mach dich erstmal mit den grundlagen vertraut.
wenn du halbwegs begriffen hast, was da steht, google z.b. mal nach idaPro...:rolleyes:
also, bitte, grundlagen, bevor du hier so einen dummsinn faselst.
du kennst noch niemals den unterschied von quell (source)code und der reinen maschinensprache. also link lesen....
der 'customchip' von meiner ecu wurde sicherlich in millionen geräten verbaut; kannst du auch googlen:
68hc11a1.
damit weiß man schon mal die einsprungsadressen und aufbau. das gibt man dann bei ida ein, und schon bekommt man den instruction code.
den muß man allerdings verstehen, das ist dann sowas:
Code:
3f00 CE004C ldx #$4c
3F03 09 dex
3F04 BC3FF0 cpx $3ff0
3F07 26F7 bne $3f00
3F07 8E00FF lds #$FF
3F0A jmp $4c17
da du dich so gut damit auskennst, wirst du mir sicher sagen können, was passiert. oder ist das 'geheimer code der autohersteller'?:D
das ist eigentlicher programmcode, der auf einem speicherchip von grade mal 32kb liegt. von dem wird hardwaremässig bereits nur die hälfte genutzt; in dem verbleibenden rest klaffen auch riesenlücken.
war für mich praktisch, weil ich hier über umbiegen von sprungadressen in freie teile 'meinen' code hineintransplantieren konnte.
einzig richtig ist, das 'moderne' steuergeräte mehr code enthalten und teilweise verschlüsselt wird. dazu wird das ganze um nefz-verarschungsroutinen etc. aufgebläht.
aber unmöglich ist es nicht; dauert bloß länger.;)
es ist klar, dass das nicht unbedingt etwas ist für einen, der bestenfalls seine spielstände manipulieren oder so grade excel anwerfen kann; aber machbar.
und man sieht, dass die hersteller auch nur mit wasser kochen:D
denn vom schwierigskeitgrad her sind etliche opensource/freewareprg. anspruchsvoller, als was sich manche (lustlose?) werksprogrammierer verzapfen.......
Load X
Decrement X
Compare X
Branch Not Equal
Lds kA, LoaD s...?
und jump.
Ist ja fast schon Intel Assembler :p
Die Kommentarblöcke dahinter hättest schon drin lassen können ;)
Sollte mein ABS/Airbag/ESP/whatever System irgendwann mit verteiltem Echtzeitjava programmiert sein, steige ich auf's Rad um.
Wäre ja doof, wenn der Airbag erst auslöst nachdem das Auto schon im Gegenverkehr zerschellt ist, weil just zu dem Zeitpunkt der Gargabe-Collector mit Aufräumen beschäftigt war... ;)
Zitat:
@FiXe schrieb am 27. Oktober 2014 um 13:13:01 Uhr:
Sollte mein ABS/Airbag/ESP/whatever System irgendwann mit verteiltem Echtzeitjava programmiert sein, steige ich auf's Rad um.
Java, wichtige Systeme und Echtzeit in einem Satz zu verwenden, ist aber schon ein starkes Stück wie ich finde :D :D :D
Zitat:
@Hafnernuss schrieb am 27. Oktober 2014 um 16:26:25 Uhr:
Zitat:
@FiXe schrieb am 27. Oktober 2014 um 13:13:01 Uhr:
Sollte mein ABS/Airbag/ESP/whatever System irgendwann mit verteiltem Echtzeitjava programmiert sein, steige ich auf's Rad um.
Java, wichtige Systeme und Echtzeit in einem Satz zu verwenden, ist aber schon ein starkes Stück wie ich finde :D :D :D
Ich warte auf den Tag, an dem nach einem Update der Navisoftware plötzlich die ASK-Toolbar im Bildschirm prangert! :D
Spaß beiseite: Die Fehleranfälligkeit durch Software im KFZ steigt einfach exponentiell. Auf der einen Seite kann man darüber lästern, dass früher alles besser war und man den ganzen Quatsch nicht braucht.
Auf der anderen Seite finde ich viele Features einfach angenehm und ziehe meinen Hut vor den Entwicklerteams, die es doch vergleichsweise gut im Griff haben. Ich hätte eigentlich erwartet, dass wir schon viel mehr Unfälle durch Programmierfehler gehabt hätten, als es der Fall ist.
Ein Realtime-System, wie das ABS wird sicherlich niemals in Java programmiert werden. (Gott bewahre uns davor!!!!)
Für Realtime-Anwendungen ist Java ja wohl absolut ungeeignet...
Ich habe auch bisher noch keine Java-Anwendungen in meinem Auto entdeckt, die essentielle Funktionen, wie das ABS, das ESP, oder sonstige betreffen.
Das Thema Garbage-Collection hat mit der verwendeten Programmiersprache auch eher gar nichts zu tun, denn so was passiert auf einer der viel weiter unten angeordneten Schichten (ich empfehle dazu das Studium des OSI-Layer Modells)!!
Für diejenigen, die da nur Bahnhof verstehen:
Garbage-Collection bedeutet in etwa "Müllabfuhr".
Gemeint ist da ein wichtiger Bestandteil eines Betriebssystems.
Das hat die Aufgabe, die sogenannten I/O-Funktionen (z.B. Festplatten und Speicherzugriffe) bereitzustellen.
Wird ein Programm gestartet, fordert es vom Betriebssystem eine bestimmte Menge Speicher an.
Je nachdem, wie sauber der Programmierer hier gearbeitet hat, gibt das Programm den Speicher auch wieder für andere Anwendungen frei, wenn der nicht mehr benötigt wird.
Hat er das nicht getan, dann kommt die sogenannte Garbage-Collection zum Zug: Die räumt gnadenlos alles aus dem Speicher, was offensichtlich nicht mehr benötigt wird.
Doch, so was ist Aufgabe des Betriebs-Systems, und das schert sich nicht darum, ob ein Programm in Java, Visual-C, oder sonst was geschrieben ist: Für dieses sind das alles nur "Anwendungen", die Speicher reserviert, aber nicht mehr freigegeben haben. Dann kommt halt in regelmäßigen Abständen diese "Müllabfuhr" vorbei, und gibt frei, was offensichtlich nicht mehr in Verwendung ist.
Insofern ist die Garbage-Collection eine Art von Selbstheilung...
So Long...
Es gibt durchaus Möglichkeiten Java Echtzeitfähig zu machen und die großen Vorteile von Java zu nutzen.
@Triumph BGH 125
Die Ironie meines Beitrags war eventuell nicht ausreichend gekennzeichnet.
Das OSI-Modell hat mit dem Garbage-Collector allerdings nicht viel zutun, das ist das Schichtenmodell für Netzwerkprotokolle/-anwendungen. Davon ab ist die Garbage-Collection sehr wohl abhängig von der Programmiersprache und eher unabhängig vom Betriebssystem.
Das Betriebssystem kommt erst zum Zug, wenn die Anwendung über seine Speichergrenzen hinaus Schreib- oder Lesezugriffe versucht, dann haut es dazwischen. Alternativ nach Beendigung, wenn die Ressourcen wieder abgeräumt werden. Zur Laufzeit ist die Garbage-Collection allein Aufgabe der jeweiligen Laufzeitumgebung (der JVM z.B.).
@RedRunner10
Ja, die Ansätze sind mir bekannt, für harte(!) Echtzeitanforderungen ist das allerdings ein ziemlich zweifelhaftes Konzept. Zunächst muss erst geklärt werden, was für den jeweiligen Zweck Echtzeit (=schnell genug) bedeutet. Oft geht dann die Reise weiter zur Auswahl eines geeigneten RTOS und/oder es wird ein FPGA herangezogen. Erst dann geht's an die Entwicklung der Software, da ist der defacto Standard noch immer blankes C, weil dort die Entwickler die Speicherverwaltung eben selbst in der Hand haben und sehr hardwarenah entwickeln können.
Das Thema weiter durchzukauen würde den Rahmen hier aber wahrscheinlich völlig sprengen...
ich will mal schwer hoffen, dass auf meinen neueren ecu's kein 'betriebssystem' läuft (am besten windows 8 CE (Chaos Extrem):D :confused: :eek:)
sowas gehört in maschinensprache programmiert.
die jüngeren werden sich noch an den klassischen vergleich 'bildschirm füllen' in basic (betriebssystem) vs maschinensprachecode erinnern....
Zitat:
@FiXe schrieb am 28. Oktober 2014 um 12:46:55 Uhr:
Das Thema weiter durchzukauen würde den Rahmen hier aber wahrscheinlich völlig sprengen...
da hast du wohl recht, selbst in diesem technik-forum:D