Hallo Elektronik Freunde, Ich stehe gerade vor folgendem Problem. Habe ein Budget von ca. 5000 und soll dafür Hard-/Software kaufen, zur Analyse von Fahrzeugdaten (Forensische Aufzeichnungen). Da ich noch leichter Anfänger in diesem Gebiet bin und noch keine Dinge vorhanden sind, wollte ich dieses Geld sinnvoll einsetzen. Mein Gedanke dazu war: 1. die Software CANeo (vector) kaufen, um Simulationsaufbauten zu erstellen (anhand schon vorhandenen Daten, wie z.b Canbus usw.) 2. Gängige Chips und auslese Hardware zum testen von Abläufen von direkter Datenauslese. 3. Hardware um Physikalische Simulation durchzuführen. Meine Frage ist nun: 1. Mach das Sinn, für den Anfang oder gibt es bessere Wege dafür? 2. Wenn es ok ist, welche Komponente wären für 1.,2. und 3. am geeignetsten?
Ohne jetzt SPezialist in dem Gebiet zu sein: Stefan D. schrieb: > Habe ein Budget von ca. 5000 und soll dafür Hard-/Software kaufen, zur > Analyse von Fahrzeugdaten (Forensische Aufzeichnungen). Ich würde mir im ersten Schritt erst mal definieren WAS GENAU aufgezeichnet werden soll. Dann als 2. Schritt bei welchen Autos aufgezeichnet werden soll. Als drittes wie ich an diese Daten komme (Wo stehen sie, welche Protokolle, etc.) Erst dann würde ich nach vorhandener Hard und Software schauen.
Stefan D. schrieb: > 2. Wenn es ok ist, welche Komponente wären für 1.,2. und 3. am > geeignetsten? Forensische Aufeichnungen heisst nach einem Unfall, heisst von Amts wegen. Ich würde den Hersteler fragen. Die meisten Steuergeräte haben auslesbaren Speicher über die vergangenen Vorgänge und Fehlercodes. Die können ausgelesen werden, aber bei jedem Hersteller mit anderer Hardware, genau die musst du also kaufen und sie kostet leicht über 5000 ER, und meistens braucht man Schlüssel also eine online-Verbindung zum Hersteller, einen Account wie eine Markenwerkstatt. Ein UNIVERSELLES System gibt es nicht, und einfach nur mit CAN Bus Schnüffeln kommst du nicht an die Daten ran.
Stefan D. schrieb: > Analyse von Fahrzeugdaten (Forensische Aufzeichnungen). > Meine Frage ist nun: > 1. Mach das Sinn, Nein. Was willst du denn genau aufzeichnen? CAN, CAN FD, LIN, Flexray, Automotive Ethernet? Und hast du auch die entsprechenden Datenfestlegungen der Fahrzeuge, denn ohne diese siehst du gar nichts? CANoe als Einsteiger halte ich für völlig überzogen. Fange doch erst mal mit Hard- und Software von PEAK an, Die kostet nur eine Bruchteil. Um komplette Busse zu simulieren braucht es schon viel Erfahrung und Fachwissen. Fange erst mal mit Auslesen an.
Aufgezeichnet werden sollen alle Kommunikationen (Anforderungen sehr allgemein gehalten). Wobei weniger Wert auf die Kommunikation gelegt wird, sondern die eigentliche Hardware auslese (davon habe ich mehr Ahnung, bräuchte aber eine geeignete Testumgebung dafür) Vorhandene Daten sind von CAN-Bus und ein paar aus dem MOST. Des weiteren wären für den Anfang auch FlexRay sehr interessant (LIN auch, aber gerade mit geringerer Priorität) Später soll auch Ethernet angebunden werden (aber das ist erst mal ein Problem für die Zukunft). Auto spezifisch gibt es keine Vorgaben (Anforderungen sind auch wieder sehr allgemein gehalten). Bisher und in naher Zukunft werden nur vorhandene Daten verwertet, eigentliche auslese am Auto wird deshalb vorerst als gegeben angesehen. (Vorhanden von verschiedenen Modellen der Marken Honda, Toyota, Chrysler und Renault) Deshalb auch die Simulation, ohne eigentliche Hardware (Auto).
Stefan D. schrieb: > Bisher und in naher Zukunft werden nur vorhandene Daten verwertet, > eigentliche auslese am Auto wird deshalb vorerst als gegeben angesehen. > (Vorhanden von verschiedenen Modellen der Marken Honda, Toyota, Chrysler > und Renault) Wie lautet der Auftrag, was ist die Zielsetzung? Willst Du auswerten, dass Blinker vorne rechts 200ms vor dem Unfall ausgefallen ist, weil die Karre in den Baum gefahren ist? Das bringt doch nichts. Die wenigstens loggen Position, Geschwindigkeit und Beschleunigungsdaten mit. Und wieviele Fahrzeuge fahren heute noch problemlos ohne das ganze CAN Bus Gerumpel rum? Wäre cool wenn Du mal etwas mehr Licht ins Dunkel bringen könntest.
Eine interpretation der Komunikation (Datentransfer) wird nicht betrachtet. Deshalb denke ich auch nicht an eine spezifische Spreche der einzelnen Fahrzeuge. Bzw. wird an einem Modell nur betrachtet (genauers Fahrzeug ist noch nicht bekannt). Danke, werde mir mal die Hard- und Software von PEAK anschauen.
Mir ist auch bekannt, das es auslese Software für Hersteller gibt (und auch deren ihre Preise), diese soll hier aber noch nicht eingesetzt werden. Und das es ein UNIVERSELLES System nicht gibt, ist mir auch bekannt. Deshalb war ich in Hinsicht Hardware auch nicht spezifisch. Hätte aber auch dazu schreiben können, das eine Hardware Kombination eines Autoherstellers gewählt werden sollte (zu Testzwecken). Der CAN-Bus soll auch auf Grund dessen nicht erschnüffelt werden (sondern schon als gegeben angesehen) und als Endresultat auch schon als abgearbeitet (aber trotzdem mit der Möglichkeit im Testaufbau diesen zu manipulieren)
Philipp G. schrieb: > Stefan D. schrieb: >> Bisher und in naher Zukunft werden nur vorhandene Daten verwertet, >> eigentliche auslese am Auto wird deshalb vorerst als gegeben angesehen. >> (Vorhanden von verschiedenen Modellen der Marken Honda, Toyota, Chrysler >> und Renault) > > Wie lautet der Auftrag, was ist die Zielsetzung? > > Willst Du auswerten, dass Blinker vorne rechts 200ms vor dem Unfall > ausgefallen ist, weil die Karre in den Baum gefahren ist? Das bringt > doch nichts. Die wenigstens loggen Position, Geschwindigkeit und > Beschleunigungsdaten mit. Und wieviele Fahrzeuge fahren heute noch > problemlos ohne das ganze CAN Bus Gerumpel rum? > > Wäre cool wenn Du mal etwas mehr Licht ins Dunkel bringen könntest. Ziel ist es, das in Zukunft auch Daten ausgewertet werden können, wenn etwas manipuliert wurde (durch unbefugte Dritte) oder genau bestimmt werden kann, wer (Fahrer oder Auto) die nötigen Handlungen für den Unfall begangen hat. Ich verzweifle aber gerade daran, das dies sehr allgemein gemacht werden soll, also keine Hersteller spezifische angaben (da noch als Forschung ausgelegt)
Stefan D. schrieb: > Ziel ist es, das in Zukunft auch Daten ausgewertet werden können, wenn > etwas manipuliert wurde (durch unbefugte Dritte) oder genau bestimmt > werden kann, wer (Fahrer oder Auto) die nötigen Handlungen für den > Unfall begangen hat. Es gibt doch genügend Crash Logger die genau das machen. Aus den Daten vom Fahrzeug bekommst Du sowas gar nicht mit.
Philipp G. schrieb: > Stefan D. schrieb: >> Ziel ist es, das in Zukunft auch Daten ausgewertet werden können, wenn >> etwas manipuliert wurde (durch unbefugte Dritte) oder genau bestimmt >> werden kann, wer (Fahrer oder Auto) die nötigen Handlungen für den >> Unfall begangen hat. > > Es gibt doch genügend Crash Logger die genau das machen. Aus den Daten > vom Fahrzeug bekommst Du sowas gar nicht mit. Ja, das ist ja genau das Problem. Das soll sich vielleicht mal ändern, deshalb die Forschung daran. Da aber leider nur Forensisches, aber kein KFZ spezifisches Wissen bekannt ist, muss man irgendwo anfangen. Und da es noch ganz am Anfang (Grundlagen) Forschung ist, wird auch noch keine Zusammenarbeit mit Herstellern angestrebt. Da Forschungsgelder am 1.1 leider auf magische weise verschwinden, sollte ich das Geld doch lieber für etwas Sinnvolles ausgeben (deshalb meine „naive“ Fragen). Da die Gelder schon generell sehr begrenze sind und ich leider noch nicht die nötige Erfahrung in dem Bereich habe, um dafür Zukunftssicher Geld auszugeben. Und das alles führt leider zu meiner Situation. Deshalb war meine Idee: Kommunikationsstrang mit der Möglichkeit diesen zu manipulieren als Testbett, welcher im nächsten Schritt (nächstes Jahr) erweitert wird (durch Hersteller spezifischere Chips). Diesen aber schon nutzen, um allgemeine (für KFZ zugelassene Chips) zu testen. Um mögliche Probleme zu analysieren und dementsprechend weiter zu verfahren. Wobei noch kein Merkmal auf die Hersteller spezifische Firmware gelegt wird (dies dann im nächsten oder übernächsten Schritt).
Philipp G. schrieb: > Es gibt doch genügend Crash Logger die genau das machen. Aus den Daten > vom Fahrzeug bekommst Du sowas gar nicht mit. Wenn die ECU noch Saft nach dem Ereignis bekommen hat, bleiben einem die Freeze Frames der letzten Fehler. Je nach ECU kriegt man dann die Werte, bei denen der Fehler auftrat, wie z.B. Geschwindigkeit, Drehzahl, Motortemperatur und ähnliches. Das klappt bei neueren Fahrzeugen über ein gutes OBD-II Diagnosegerät - aber bei älteren Autos gehts entweder gar nicht, oder über herstellerspezifische Interfaces.
:
Bearbeitet durch User
Matthias S. schrieb: > Wenn die ECU noch Saft nach dem Ereignis bekommen hat, bleiben einem die > Freeze Frames der letzten Fehler. Je nach ECU kriegt man dann die Werte, > bei denen der Fehler auftrat, wie z.B. Geschwindigkeit, Drehzahl, > Motortemperatur und ähnliches. Das ist klar. Dennoch, für forensische Zwecke sind keine umfassenden brauchbaren Daten vorhanden. Stefan D. schrieb: > Kommunikationsstrang mit der Möglichkeit diesen zu manipulieren als > Testbett, welcher im nächsten Schritt (nächstes Jahr) erweitert wird > (durch Hersteller spezifischere Chips). > Diesen aber schon nutzen, um allgemeine (für KFZ zugelassene Chips) zu Dein Thema ist zu breit. Entweder legst Du dich auf ein spezifisches Auto fest für eine Studie, oder du gehst eher in Richtung Crash Recorder. Unfälle passieren nun mal zu 99.9% durch menschliches Versagen.
Stefan D. schrieb: > Kommunikationsstrang mit der Möglichkeit diesen zu manipulieren als > Testbett, welcher im nächsten Schritt (nächstes Jahr) erweitert wird > (durch Hersteller spezifischere Chips). Was sind denn herstellerspezifische Chips? Meinst du ASICs? > um allgemeine (für KFZ zugelassene Chips) zu testen Schon wieder zugelassene Chips. Meinst du Automotive Controller? Die sind von den Herstellern und den OEMs schon getestet. Stefan D. schrieb: > Wobei noch kein Merkmal auf die Hersteller spezifische > Firmware gelegt wird (dies dann im nächsten oder übernächsten Schritt) An die Firmware in Sourcecode kommt man nicht ran. Ich fürchte dir fehlt noch einiges an Fachwissen um das Thema überhaupt einschätzen zu können. Kauf dir für 500€ irgendeine Schrottkarre mit CAN-Bus und fange an da am Bus rumzuspielen. Denn dieser Bus läuft schon und du musst nicht erst einen aufbauen. Allein der Aufbau eines Testbett nach deier Beschreibung dauert ein halbes Jahr.
Philipp G. schrieb: > Matthias S. schrieb: >> Wenn die ECU noch Saft nach dem Ereignis bekommen hat, bleiben einem die >> Freeze Frames der letzten Fehler. Je nach ECU kriegt man dann die Werte, >> bei denen der Fehler auftrat, wie z.B. Geschwindigkeit, Drehzahl, >> Motortemperatur und ähnliches. > > Das ist klar. Dennoch, für forensische Zwecke sind keine umfassenden > brauchbaren Daten vorhanden. Das soll sich hoffentlich mal ändern. > > Stefan D. schrieb: >> Kommunikationsstrang mit der Möglichkeit diesen zu manipulieren als >> Testbett, welcher im nächsten Schritt (nächstes Jahr) erweitert wird >> (durch Hersteller spezifischere Chips). >> Diesen aber schon nutzen, um allgemeine (für KFZ zugelassene Chips) zu > > Dein Thema ist zu breit. Entweder legst Du dich auf ein spezifisches > Auto fest für eine Studie, oder du gehst eher in Richtung Crash > Recorder. Meine Idee war, da die Kommunikation recht ähnlich aufgabaut ist (nur der inhalt ist Herstellerspezifisch) eine erst eine "Pseudosprache" (oder aufgenommene) Datenlage zu nehmen, ohne 100% verhandenen sein aller Komponenten, als Test (also dann als Test ein Simuliertes Auto ohne Blinker oder Rückfahrkamera). Damit man das vielleicht später (im nächsten Schritt) ersetzen/ergenzen kann (am besten mit einem Autohersteller zusammen) > > Unfälle passieren nun mal zu 99.9% durch menschliches Versagen. Ja, aber in Zukuft vielleicht nicht mehr (nach den vorstellungen vieler großer US Unternehmen). Dashalb befasse ich mich damit.
Stefan D. schrieb: > Meine Idee war, da die Kommunikation recht ähnlich aufgabaut ist (nur > der inhalt ist Herstellerspezifisch) eine erst eine "Pseudosprache" > (oder aufgenommene) Datenlage zu nehmen Kannst Du auch. Der Standard heisst ODB-2. Damit bekommst Du motorbezogene Daten raus, für forensische Zwecke nicht brauchbar. Dein Vorhaben funktioniert genau mit einem Auto, einer Baureihe, sogar nur mit einem Jahrgang. Erschwerend kommt dazu, dass die Hersteller keinen Quellcode herausrücken, reverse engineering für ein einzelnes definiertes Auto kann Dich Monate bis Jahre kosten bis du alles verstehst. Es gibt sogar Modelle die speichern die Daten stark verschlüsselt ab. Und davon abgesehen, selbst wenn Du das schaffst und jedes Modell auswendig kennst; die Hersteller arbeiten schneller als du. Rechne pro Monat mit 20 neuen Modellen, das Reverse Engineering eines dauert Monate.
:
Bearbeitet durch User
In jedem Lastenheft steht drin, dass das Speichern unfallbezogener Daten verboten ist. Andererseits wollen Steuergerätehersteller bei abnormen Betriebsfällen einen Datensatz haben, der später die Analyse des Ausfallteils erleichtert. Daher kommst Du an diese Daten nur mit den internen Tools des Steuergeräteherstellers dran. Der OEM weiss oft gar nicht dass die überhaupt existieren, und öffentlich dokumentiert sind sie erst recht nicht. Um die Situation nach einem Unfall zu analysieren müsstest Du von allen relevanten Steuergeräten Dumps des NVRAMs und sofern noch vorhanden des RAMs erstellen. Bei hinreichender Kenntnis der Software (die man vorher disassembliert und verstanden hat) kann man dann den Betriebszustand rekonstruieren. D.h. Du brauchst Debugger bzw Programmiertools zum Auslesen der gängigen Controller (Renesas, Infineon, TI, NXP, STM), ggf Tools zum Umgehen des Ausleseschutzes und ein paar IDApro-Lizenzen. Zur Nachbildung von Fahrzuständen brauchst Du eine Restbus-Simulation. Da wäre Vector CANoe das Mittel der Wahl. Ein VN1640 mit zwei CAN und zwei LIN oder ein VN8970 für Flexray, dazu die passenden CANoe-Lizenzen. Mit Deinen 50kEUR Budget solltest Du für Hardware und Lizenzen hinkommen. Die Beschaffung des nötigen Fachwissens (also das Anheuern geeigneter Leute) dürfte aber erheblich teurer werden.
Philipp G. schrieb: > Stefan D. schrieb: >> Meine Idee war, da die Kommunikation recht ähnlich aufgabaut ist (nur >> der inhalt ist Herstellerspezifisch) eine erst eine "Pseudosprache" >> (oder aufgenommene) Datenlage zu nehmen > > Kannst Du auch. Der Standard heisst ODB-2. Damit bekommst Du > motorbezogene Daten raus, für forensische Zwecke nicht brauchbar. Davon habe ich auch für gewisse Hersteller schon Daten, welche auch schon von anderen Reverse Engineert wurden. Will dies Daten dann nur Nutzen, um einen Testbaum zu konstruieren, den man dann auch maniulieren kann, ohne vollständigkeit oder 100%ige richtigkeit zu verlangen (auch nicht mit den gegebenen Mittel möglich). > > Dein Vorhaben funktioniert genau mit einem Auto, einer Baureihe, sogar > nur mit einem Jahrgang. Erschwerend kommt dazu, dass die Hersteller > keinen Quellcode herausrücken, reverse engineering für ein einzelnes > definiertes Auto kann Dich Monate bis Jahre kosten bis du alles > verstehst. > > Es gibt sogar Modelle die speichern die Daten stark verschlüsselt ab. Ein problem, was nicht betrachtet wird. Annahme ist, wenn man die Daten bekommt, man diese auch entschlüsseln kann, auch wenn das nicht unbedingt der Realität entspricht (würde auch sonst den Rahmen sprengen). > > Und davon abgesehen, selbst wenn Du das schaffst und jedes Modell > auswendig kennst; die Hersteller arbeiten schneller als du. Rechne pro > Monat mit 20 neuen Modellen, das Reverse Engineering eines dauert > Monate. Denke, das ist für alle ein Problem, deshalb ist es auch nicht mein Ziel diese (all) zu Reverse Engineering, sondern höchsten ein/zwei. Und nach einem Test (mit vielleicht auch Fakedaten) einen Hersteller hinzu zuholen. Eine eierlegende Wollmilchsau ist auch nicht das Ziehl, sondern die Machbarkeit zu prüfen. (Deshalb auch Grundlagen Forschung) Aber danke schon mal für den bisherigen Input. Leider hilft mir das noch nicht genau weiter, wofür das Geld jetzt eingesetzt wird.
soul e. schrieb: > In jedem Lastenheft steht drin, dass das Speichern unfallbezogener Daten > verboten ist. Zeichnet bei einem Unfall nicht fast jeder Fahrzeughersteller die letzen Sekunden auf, das dachte ich zumindest? So ein Lastenheft würde mich mal persönlich interessieren (kommt man aber warscheinlich nicht so einfach ran). > Andererseits wollen Steuergerätehersteller bei abnormen > Betriebsfällen einen Datensatz haben, der später die Analyse des > Ausfallteils erleichtert. Daher kommst Du an diese Daten nur mit den > internen Tools des Steuergeräteherstellers dran. Der OEM weiss oft gar > nicht dass die überhaupt existieren, und öffentlich dokumentiert sind > sie erst recht nicht. Der gedanke an dem ganzen Projekt ist, dass in X Jahren die Hersteller vielleicht mal verplichtet werden einen Standart zu nutzen oder zumindest einheitliche Daten sammeln und dafür dann Fachwissen zu haben (betrifft nicht nur Autohersteller). > > Um die Situation nach einem Unfall zu analysieren müsstest Du von allen > relevanten Steuergeräten Dumps des NVRAMs und sofern noch vorhanden des > RAMs erstellen. Bei hinreichender Kenntnis der Software (die man vorher > disassembliert und verstanden hat) kann man dann den Betriebszustand > rekonstruieren. Das wäre natürlich am besten, soweit bin ich aber noch nicht. Deshalb der Eigenbau eines geschlossen aber nicht vollständigen Systems (das man auch spezielle Steuergeräte erweitern/umschreiben kann). Daher meine Frage, was man nehmen kann, was auch in der Zukunft auch noch verwendet werden kann. z.B. ein System, welches so abgeändert werden könnte, um vielleicht wenn nötig noch ein Restbussimulation durch zu führen. Ohne direkt damit starten zu müssen. (Quasi eine Testumgebung um sich einzuarbeiten, bei dem man auch schon was sehen/machen kann) > > D.h. Du brauchst Debugger bzw Programmiertools zum Auslesen der gängigen > Controller (Renesas, Infineon, TI, NXP, STM), ggf Tools zum Umgehen des > Ausleseschutzes und ein paar IDApro-Lizenzen. Die Hersteller spezifischen Lizenzen und Hardware wäre jetzt noch nicht so wichtig. Gibt es ein Debugger bzw Programmiertool für diese Zwecke (welches größte mögliche Bandbreite abdeckt)? > > Zur Nachbildung von Fahrzuständen brauchst Du eine Restbus-Simulation. > Da wäre Vector CANoe das Mittel der Wahl. Ein VN1640 mit zwei CAN und > zwei LIN oder ein VN8970 für Flexray, dazu die passenden CANoe-Lizenzen. Dritte Frage war dann ob, diese momentan überhaupt nötig/Sinnvoll sind? > > Mit Deinen 50kEUR Budget solltest Du für Hardware und Lizenzen > hinkommen. Die Beschaffung des nötigen Fachwissens (also das Anheuern > geeigneter Leute) dürfte aber erheblich teurer werden. leider nur 5k, weitere Person mit mehr Fachwissen in KFZ ist schon eingeplant. Lizenzen könnten aber im späteren Projekt verlauf noch nachgekauft werden (ist zumindest eine größeres Budget eingeplant). Aber danke für die hilfreiche Antwort.
soul e. schrieb: > Mit Deinen 50kEUR Budget solltest Du für Hardware und Lizenzen > hinkommen. Die Beschaffung des nötigen Fachwissens (also das Anheuern > geeigneter Leute) dürfte aber erheblich teurer werden. Aeh, er hat 5k Budget, nicht 50k. @TO: Der Soul eye kommt aus der Branche, glaub es ihm ruhig.
Thomas F. schrieb: > Stefan D. schrieb: >> Kommunikationsstrang mit der Möglichkeit diesen zu manipulieren als >> Testbett, welcher im nächsten Schritt (nächstes Jahr) erweitert wird >> (durch Hersteller spezifischere Chips). > > Was sind denn herstellerspezifische Chips? Meinst du ASICs? > > >> um allgemeine (für KFZ zugelassene Chips) zu testen > > Schon wieder zugelassene Chips. Meinst du Automotive Controller? Die > sind von den Herstellern und den OEMs schon getestet. > > Stefan D. schrieb: >> Wobei noch kein Merkmal auf die Hersteller spezifische >> Firmware gelegt wird (dies dann im nächsten oder übernächsten Schritt) > > An die Firmware in Sourcecode kommt man nicht ran. Weiß ich und ist ohne Beteiligung der besagten Firmen auch nicht möglich. Soll deshalb umgangen werden (auch wenn durch bestimmte Standarte nicht eingehalten werden oder auch nicht ganz Vollständig, als „kleines“ Test Beispiel für die Machbarkeit oder Stress Testen) > > Ich fürchte dir fehlt noch einiges an Fachwissen um das Thema überhaupt > einschätzen zu können. Deshalb leider auch meine Fragen und die Hoffnung, hier Unterstützung zu bekommen. Ändert sich aber in der nächsten Zeit, leider aber nicht, bis Mitte nächsten Monats. > > Kauf dir für 500€ irgendeine Schrottkarre mit CAN-Bus und fange an da am > Bus rumzuspielen. Denn dieser Bus läuft schon und du musst nicht erst > einen aufbauen. Allein der Aufbau eines Testbett nach deier Beschreibung > dauert ein halbes Jahr. Dauer für den Aufbau ist weniger das Problem, sondern die Finanziellen mittel, welche jetzt ausgegeben werden müssen, da sie sonst verfallen. Deshalb am besten für Dinge, welche ich dann in diesem halben Jahr oder noch später gebrauchen kann. Und nicht eine Schrottkarre, welche nach einem mal richtig benutzen entsorgt werden muss. Darum wird auch nicht so viel Wert auf die Vollständigkeit der Systems gelegt, sondern auf die Wiederverwertbarkeit.
ein typischer Textbaustein eines europäischen OEM: "STLH-xxxx: Diese Komponente darf keine Unfalldatenschreiberfunktionalität (Event Data Recorder - EDR) enthalten. In Steuergeräten ohne Unfalldatenschreiberfunktionalität (Event Data Recorder - EDR) dürfen keine dynamischen Fahrzeugdaten mit Zeitbezug zu einem Crash-Ereignis nichtflüchtig gespeichert werden." Wenn der OEM Unfalldaten speichern will, dann macht er das an zentraler Stelle. Das RCM (Airbag-Steuergerät) wäre dafür nicht gänzlich ungeeignet. Aber warum sollte er das tun? Um sich bei einem Unfall noch technisches Versagen nachweisen zu lassen oder mit irgendwelchen Gutachtern und Versicherungen diskutieren zu müssen? Ohne gesetzliche Anforderung macht das keiner. Die Low-cost-Lösung zum Auslesen nicht auslesegeschützter Controller ist das jeweilige Evalkit des Herstellers. Da ist irgendein Dingsbums dabei, mit dem man den Controller programmieren und debuggen kann. Die Low-cost-Lösung zum Angucken von CAN-Botschaften ist ein Lawicel-kompatibler CAN-Adapter mit CANHacker oder CanCool-Freeware. Da gibt es haufenweise Selbstbauprojekte. Oder man kauft einen originalen Lawicel, von irgendwas müssen die Schweden ja auch leben. LIN und K-Line ist UART mit anderen Spannungspegeln. Das kann man mit einem Terminalprogramm am PC mitschneiden. Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit Profi-Equipment. Hier wurde der Begriff "OBD2" genannt: OBD2 ist eine standardisierte Schnittstelle zum Auslesen abgasrelevanter Diagnosedaten. Das hat absolut nichts mit der OEM-spezifischen Fahrzeugdiagnose zu tun, auch wenn diese über den gleichen Stecker erfolgt. Telefon und Internet laufen auch über das gleiche Kabel und sind trotzdem komplett verschiedene Dienste. Manchmal liegen am OBD-Stecker die Fahrzeugbusse direkt auf. Dann kann man da tatsächlich die Kommunikation zwischen einzelnen Steuergeräten beobachten. In den meisten Fällen hängt aber ein Gateway als Firewall dazwischen. Dann kannst Du dort nur die Daten einspeisen und beobachten, die auch zur Weiterleitung bestimmt waren.
https://www.gin.de/ hatte hier mal vor langer zeit ein Gespräch und mir wurde erklärt das man dort DatenLoggingSysteme für die Automotive Industrie entwickelt/baut. Justmy2Cents
Stefan D. schrieb: > Der gedanke an dem ganzen Projekt ist, dass in X Jahren die Hersteller > vielleicht mal verplichtet werden einen Standart zu nutzen oder > zumindest einheitliche Daten sammeln und dafür dann Fachwissen zu haben > (betrifft nicht nur Autohersteller). Das passt ja jetzt auch zum Titel "Autoelektronik verstehen". Dann wuerde ich mir doch mal nur ein (aktuelles, weit verbreitetes) KFZ rauspicken, z.B. einen Passat. Oder schau im Fuhrpark nach, was auf dem Hof steht. Davon ausgehend waere dann die Fragestellung, wie die Elektronik genau dort funktioniert, welche Busse zum Einsatz kommen, an welche Daten (auch unwichtige) man generell rankommt. ODB wurde ja schon genannt als System, das externen Datenzugriff standardisiert vorsieht. Wobei es ja dort um die Abgaskontrolle und Repariererei geht. Koennte durch Gesetze auch noch um Unfalldaten erweitert werden.
Ich würde mich für Renault entscheiden - im Netz geistert DDT2000, Software, die für Diagnostik missbraucht wird, dabei handelt es sich aber um Entwicklungssoftware für Renault-Zulieferer. Die Software ist modular aufgebaut und beliebig anpassbar, die Module sind XML Dateien, die man einsehen und modifizieren kann, man sieht auch die Formeln, wie die jeweiligen Daten/Impulse umgerechnet werden. Man kann auf alles zugreifen, was aus den ECUs rauskommt. Dabei gibt es Editoren um Ausgaben anzupassen, auch als Grafik etc. Die Datenbank dazu umfasst über 1500 Module, also ECUs, ABS, ESP usw., eigentlich alles was es gibt. Sofern sich die Module über KKL auslesen lassen, reicht ein einfacher VAG KKL Adapter, für CAN braucht man allerdings einen Derelek Adapter und die sind eigentlich nur für Zulieferer zugänglich, man findet die aber manchmal z. B. auf Ebay.
Maxe schrieb: > ODB wurde ja schon genannt als System, das externen Datenzugriff > standardisiert vorsieht. Wobei es ja dort um die Abgaskontrolle und > Repariererei geht. Koennte durch Gesetze auch noch um Unfalldaten > erweitert werden. Solange es keinen Gesetzesentwurf gibt werden die Hersteller einen Scheiss dafür machen. Kein unfallrelevanten Daten speichern. Wozu auch? Dass es dann in einer Rückrufaktion ausartet weil jeder nachsehen kann, dass die Zeile 'fire airbag' auskommentiert ist? ;) soul e. schrieb: > Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit > Profi-Equipment. Wobei die beiden ja sehr BMW lastig sind. Lass mich raten: Du arbeitest bei Bosch?
:
Bearbeitet durch User
soul e. schrieb: > ein typischer Textbaustein eines europäischen OEM: "STLH-xxxx: Diese > Komponente darf keine Unfalldatenschreiberfunktionalität (Event Data > Recorder - EDR) enthalten. In Steuergeräten ohne > Unfalldatenschreiberfunktionalität (Event Data Recorder - EDR) dürfen > keine dynamischen Fahrzeugdaten mit Zeitbezug zu einem Crash-Ereignis > nichtflüchtig gespeichert werden." Ok, wusste ich jetzt nicht. Werde ich mir aber merken. > > Wenn der OEM Unfalldaten speichern will, dann macht er das an > zentraler Stelle. Das RCM (Airbag-Steuergerät) wäre dafür nicht gänzlich > ungeeignet. Aber warum sollte er das tun? Um sich bei einem Unfall noch > technisches Versagen nachweisen zu lassen oder mit irgendwelchen > Gutachtern und Versicherungen diskutieren zu müssen? Ohne gesetzliche > Anforderung macht das keiner. > Gesetzliche Verpflichtungen gibt es dazu tatsächlich noch nicht, kann sich aber ändern (sicher sehr unwahrscheinlich). Es muss ja nicht immer alles zu einem Unfall führen. So gibt es jetzt schon selbstfahrende Autos und Infrastruktur, welche mit dem Auto kommuniziert. Wenn man beides verbindet (für höhere Sicherheit) kann es auch mal zu Grauzonen kommen, wogegen sich der Auto-/Infrastrukturhersteller absichern will. Andere Beispiele sind auch bei den Versicherungen zu beobachten, welch gerne Fahrerdaten haben wollen (im Ausland schon weiter verbreitet). Und da sind auch Tür und Tor offen für die persönliche Preisoptimierung eines Übeltäters. > > > Die Low-cost-Lösung zum Auslesen nicht auslesegeschützter Controller ist > das jeweilige Evalkit des Herstellers. Da ist irgendein Dingsbums dabei, > mit dem man den Controller programmieren und debuggen kann. Daran habe ich gar nicht gedacht (manchmal steht man auf mehr als nur einen Schlauch). Gibt es da Einpfählungen, welche Evalkits gut oder weniger gut sind? Aber auch dritt Unternehmerischen wollen jedes Fahrzeug selbstfahrend machen (z.B. comma.ai). Die eingeschleusten CAN Befehle (über OBD2) können da auch statistisch von Menschlichen Fahrern Unterschieden werden. > > Die Low-cost-Lösung zum Angucken von CAN-Botschaften ist ein > Lawicel-kompatibler CAN-Adapter mit CANHacker oder CanCool-Freeware. Da > gibt es haufenweise Selbstbauprojekte. Oder man kauft einen originalen > Lawicel, von irgendwas müssen die Schweden ja auch leben. Guter Hinweis, werde ich auf jedenfalls Vergleichen. > > LIN und K-Line ist UART mit anderen Spannungspegeln. Das kann man mit > einem Terminalprogramm am PC mitschneiden. > > Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit > Profi-Equipment. Schade, muss man aber auch erst mal wissen. > > > > > Hier wurde der Begriff "OBD2" genannt: OBD2 ist eine standardisierte > Schnittstelle zum Auslesen abgasrelevanter Diagnosedaten. Das hat > absolut nichts mit der OEM-spezifischen Fahrzeugdiagnose zu tun, auch > wenn diese über den gleichen Stecker erfolgt. Telefon und Internet > laufen auch über das gleiche Kabel und sind trotzdem komplett > verschiedene Dienste. > > Manchmal liegen am OBD-Stecker die Fahrzeugbusse direkt auf. Dann kann > man da tatsächlich die Kommunikation zwischen einzelnen Steuergeräten > beobachten. In den meisten Fällen hängt aber ein Gateway als Firewall > dazwischen. Dann kannst Du dort nur die Daten einspeisen und beobachten, > die auch zur Weiterleitung bestimmt waren.
Stefan D. schrieb: >> Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit >> Profi-Equipment. > > Schade, muss man aber auch erst mal wissen. Für Dein Vorhaben wäre es wohl das beste wenn du dich direkt an soul eye wendest. Er kommt IHMO aus der Branche und kann am besten helfen. Vielleicht könnt ihr ja mal telefonieren.
soul e. schrieb: > In jedem Lastenheft steht drin, dass das Speichern unfallbezogener Daten > verboten ist. Andererseits wollen Steuergerätehersteller bei abnormen > Betriebsfällen einen Datensatz haben, der später die Analyse des > Ausfallteils erleichtert. Daher kommst Du an diese Daten nur mit den > internen Tools des Steuergeräteherstellers dran. Der OEM weiss oft gar > nicht dass die überhaupt existieren, und öffentlich dokumentiert sind > sie erst recht nicht. Stimmt so nicht, zumindest für einige Modelle deutscher Hersteller die in Europa in Betrieb sind. Die Varianten für den US Markt haben sowieso die Funktionalität des EDR eingebaut (weil gesetzlich vorgeschrieben), aber auch bei einigen Modellen für den EU Markt ist sie vorhanden und aktiv. Einfach mal die Liste mit den unterstützten Fahrzeugen von Bosch Diagnostics CDR (Crash Data Retrieval) ansehen, dort sind inzwischen viele Modelle auch aus dem EU Markt dabei. Und auch wenn da steht dass nur die US Variante unterstützt wird heißt das nicht zwingend dass das auch tatsächlich so ist und nicht doch Crash-Daten gespeichert werden, auch wenn CDR diese nicht auslesen kann (selbst überprüft). Für das Auslesen der EDR Daten gibts übrigens sogar einen SAE Standard und die meisten aktuellen Fahrzeuge mit EDR benutzen das auch (bei älteren Fahrzeugen ist das nicht der Fall).
soul e. schrieb: > Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit > Profi-Equipment. Das kommt eventuell darauf an was man machen will. BroadR-Reach Media Konverter auf 100BASE-T1 gibt es für um die EUR 200. Evaluation Boards mit FlexRay Unterstützung bekommt man für unter EUR 100. Brauchbarer Beispiel-Code für FlexRay ist häufig nicht dabei aber mit Erfahrung in der Mikrocontroller-Programmierung kann man das hinbekommen. Wenn die Parameter des zu untersuchenden FlexRay Bus nicht bekannt sind wird es etwas mühsamer, weil man die Parameter erst herausbekommen muss, aber auch das ist machbar (für BMW bwz. Audi bereits ausprobiert, sowohl als passiver Teilnehmer und auch als Cold-Start Node). Das Ganze ist nicht trivial, man sollte einiges an Zeit einplanen, aber es geht. Klar, wenn man keine Zeit hat und genügend Etat dann gibt es auch andere Wege.
Ohne mir jetzt alles durchgelesen zu haben: Abgesehen von Fehlereinträgen mit Timestamp und einem evtl vorhandenem Unfalldatenschreiber loggt kein Auto die aktuellen Fahrzeugdaten mit. Das, was per Diagnosesystem bei einer Testfahrt geloggt wird, wird in der Diagnosesoftware gespeichert, nicht imSteuergerät des Fahrzeugs. VG
Philipp G. schrieb: > Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit >> Profi-Equipment. > > Wobei die beiden ja sehr BMW lastig sind. Lass mich raten: Du arbeitest > bei Bosch? Oder Audi oder Daimlerlastig bei Flexray oder sogar VW bei BroadR...
Beitrag #6030320 wurde vom Autor gelöscht.
Rcc schrieb: > Philipp G. schrieb: >> Bei Flexray und BroadRReach bist Du raus. Das geht (bisher) nur mit >>> Profi-Equipment. >> >> Wobei die beiden ja sehr BMW lastig sind. Lass mich raten: Du arbeitest >> bei Bosch? > > Oder Audi oder Daimlerlastig bei Flexray... ...oder Porsche (Panamera, Cayenne).
:
Bearbeitet durch User
Um einfach mal mein Unwissen zur Schau zustellen... über einen OBD(2) Adapter die gewünschten Daten ziehen und über ein Skript auswerten ;)
Stefan D. schrieb: > Mein Gedanke dazu war: > 1. die Software CANeo (vector) kaufen, um Simulationsaufbauten zu > erstellen (anhand schon vorhandenen Daten, wie z.b Canbus usw.) > 2. Gängige Chips und auslese Hardware zum testen von Abläufen von > direkter Datenauslese. > 3. Hardware um Physikalische Simulation durchzuführen. Ich weiß nicht was Ihr für Probleme habt. Das ist eine Fahrhilfe. Fertig. ? Macht 10.000,- Euro. Stefan D. schrieb: > Habe ein Budget von ca. 5000 und soll dafür Hard-/Software kaufen, zur > Analyse von Fahrzeugdaten (Forensische Aufzeichnungen). Oder wollt Ihr euch etwa auf einen endlosen Kleinkrieg mit Argumentationshilfen einlassen? ? P.S.: Das Ding kann nie und niemals etwas anderes sein als eine Fahrhilfe und ist nur was für Leute die sich keinen Schofför leisten können. ?
OhnePlan schrieb: > Um einfach mal mein Unwissen zur Schau zustellen... über einen OBD(2) > Adapter die gewünschten Daten ziehen und über ein Skript auswerten ;) Ist nur Diagnose Zwecke.
:
Bearbeitet durch User
...und spätestens wenn VKMS/SOK in die Vernetzungsarchitektur Einzug erhält, ist dann eh Schluss...
Matthias B. schrieb: > Abgesehen von Fehlereinträgen mit Timestamp und einem evtl vorhandenem > Unfalldatenschreiber loggt kein Auto die aktuellen Fahrzeugdaten mit. ach https://www.golem.de/news/media-control-unit-totgeschriebener-flash-speicher-legt-teslas-lahm-1910-144560.html
Joachim B. schrieb: > ach > https://www.golem.de/news/media-control-unit-totgeschriebener-flash-speicher-legt-teslas-lahm-1910-144560.html Naja, du hast schon recht, das die Aussage 'kein Auto loggt' falsch ist, aber der Tesla ist im Moment wirklich noch die grosse Ausnahme - und es geht, wie man sieht, nach hinten los.
Matthias S. schrieb: > Naja, du hast schon recht, das die Aussage 'kein Auto loggt' falsch ist Klasse dann weiss ich immer wenn ich viel - bekomme das ich Recht habe :)
Joachim B. schrieb: > > ach > https://www.golem.de/news/media-control-unit-totgeschriebener-flash-speicher-legt-teslas-lahm-1910-144560.html Das Mediasystem loggt bis zum Umfallen die Daten mit. Warum das Ding dann auch noch das Ladesystem steuern muss, weiß nur Tesla... .
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.