mikrocontroller.net

Forum: Fahrzeugelektronik Auto Elektronik verstehen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Stefan D. (stivend)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: Oh Je (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Thomas F. (igel)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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).

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Philipp G. (geiserp01)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Thomas F. (igel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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
Autor: soul e. (souleye)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: InterWebz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Maxe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Norbert T. (atos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Stefan D. (stivend)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias B. (turboholics)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rcc (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.
Autor: N. A. (bigeasy)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Dieter (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Allein CANoe und die dafür notwendige Hardware sprengt dein Budget...

Autor: OhnePlan (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Um einfach mal mein Unwissen zur Schau zustellen... über einen OBD(2) 
Adapter die gewünschten Daten ziehen und über ein Skript auswerten ;)

Autor: Antoni Stolenkov (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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. 🐴

Autor: Philipp G. (geiserp01)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Spielverderber (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
...und spätestens wenn VKMS/SOK in die Vernetzungsarchitektur Einzug 
erhält, ist dann eh Schluss...

Autor: Joachim B. (jar)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
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

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joachim B. (jar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
:)

Autor: Matthias B. (turboholics)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... .

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.