 Hallo, ich bin Kami, ich bin ein Forscher bei Toyota Infotech und genau, es geht um Rammentech, die Forschung in der Automotivindustrie möglich machen soll. Automotive Projekte sind häufig sehr teuer und es gibt Non-Diskloser-Agrimente Darum möchte ich dieses Projekt vorstellen, dass eine andere Methode benutzt, um Automotive-Systeme anzuschauen, die Open Source sind, sodass jeder sich die Forschung nachvollziehen kann und auch selber forschen kann. Das Hauptziel ist Sicherheit, aber das nicht nur Sicherheit, die Sicherheitsteil kommt am Ende des Vortrages. Wir fangen mit einem kurzen Informationen über Automotiv-Autosysteme an, dann reden wir über unsere Test-Setup und ist die Software und Hardware davon, wie es benutzt werden kann. Ich werde euch ein bisschen zeigen, wie es kontrolliert werden kann und ich werde durch den ganzen Entwicklungsprozess gehen von der Entwicklung der Formeln und unterschiedliche Kontrollstrategien analysieren und Fahrsimulatoren anzeigen, denn nur die Information aus dem Canvas ist und das machen wir mit ausschließlich Open Source Werkzeugen. Dieses zeigt, wie das Test-Setup benutzt werden kann, aber auch, wie es als Referenz benutzt werden kann. Wenn man mit einem echten Auto arbeitet, ich möchte auch zeigen, wie wir Zugang zu der Software haben und willkommen können, ohne Non-Disclose Agreements oder Geheimhaltungserklärungen unterschreiben zu müssen. Bevor wir anfangen, wir machen hier mit keinem Gewinn und wir sind hier unabhängig. Also zuerst einen kurzen Beispiel über Automobile-Systeme. Es geht um Systeme in vier unterschiedlichen Bereichen. Das eine ist der Antriebsstrang, das zweite ist das Gehäuse, das Steuerung und das Steuern, dann Lichter und Struktur und so weiter und Infotainment. Wir sind die unterschiedlichen Controller, die wir hier finden, ECUs, elektronisch kontrollierte Einheiten. Es gibt bis zu hunderte davon und die sind so beliebt. Sie nehmen Informationen von Sensoren und kontrollieren irgendwelche Aktuatoren. Zum Beispiel eine Airbag ECU benutzt einen Bewegungssensor als Input und den Airbag Trigger als Ausgang und wir benutzen einen Schock zu erkennen und dann die Signal an weiterzuleiten. Es ist sehr häufig, dass die ECUs miteinander verbunden sind. Meistens müssen ECUs Daten mit anderen ECUs auszahlen. Zum Beispiel wird das Input von der ECU die Aktionen von Pots um den Regen gaut bestellen. ECUs müssen auch mit ECUs in anderen Bereichen zu, zum Beispiel wir müssen, wenn wir haben, die Technologie, die für die Kommunikation ist, kann. Es wurde an Versuch gestattet, das auf 64 Watt hochzuschrauben. Wenn wir hier den Netzwerk sehen, dann machen die Hersteller eine Abitration ID für jedes Gerät und über diese Sache wird der Verkehr referenziert als DBC-Datei. Hier sehen wir zum Beispiel eine Lampenkontrolle und zwei Lampen an dem Bus und diese Nummer wird benutzt, um beide Lampen anzustellen. Und die 124 ist dann dafür genutzt, Feedback über den Status zu geben. Die rechte Lampe kann das über die 125 machen. Jede dieser Nachrichten wird immer wieder periodisch ausgesendet bei der ECU und als Basis für die meisten Sachen benutzen. Das ist soweit die Einleitung. Wenn ihr weiter interessiert seid, die Aktivität, die von den Medien die meisten Aufmerksamkeit bekommt, ist natürlich irgendwie schwachstellen zu finden. Aber es gibt natürlich auch andere Gründe, zum Beispiel die Dankenschutzgrundverordnung. Vielleicht gibt es auch Leute, die experimentieren, wollen Innovationen erschaffen wollen und wir wollen helfen, diesen Bildungsprozess voranzubrennen. Warum ist es so schwierig mit Autos zu experimentieren? Die Hersteller wollen ihre intellektuelle Besitzung nicht hergeben und deswegen versuchen sie das zu finden, dass man da gut rankommt. Und wir wollen natürlich Bildung in diesem Bereich haben, aber wenn du keine Zugang zu Informationen hast, ist das sehr schwierig. Wir haben wenig Technologien, um davon zu wählen. Das heißt, wir können nicht so besonders viel entwickeln und auswerten. Viele Firmen versuchen also daher sicherzustellen, dass alle, die hier mitmachen, sich in Automobilsystemen gut auskennen. Gibt es vielleicht irgendwann eine Opsource car? Wenn das passiert, wird es noch sehr, sehr lange dauern. Hersteller haben nicht mal 100% Zukunft zu ihren Code, weil die ITUs intellektuelle Besitze von anderen Firmen beinhalten. Also wir als Researcher können nicht unbedingt in diese Richtung Kraft aussuchen. Aber wir können das anders gemacht. Wir können sagen, wir machen Open Source Sachen und die machen wir zugesicht, damit man davon lernen kann und entwickeln Werkzeuge dafür. Und das ist, was wir versucht haben mit Rahmen. Und das ist der Grund, warum ich diese Präsentation erhalte. Die Idee ist, eine Plattform zu bieten, die offen ist, die leicht zu benutzen ist und natürlich sollte sie billig sein und möglichst wenig Wissen voraussetzen. Es sollte natürlich ausgeschlossen sein, als Unfälle passieren und Dinge unterbrechen worden. Du solltest also quasi das Gleiche machen können, als ob du mit einem echten Auto arbeitest. Du brauchst natürlich ein ICN-Netzwerb. Also das ist natürlich, macht dein eigenes Testbed, statt einem echten Auto. Du kannst viele Testbanken sehen, wie du sie auf Security-Konferenz findest, wieso was her. Das sieht natürlich sofort interessant aus. Und leider ist es nicht leicht, das zu programmieren, weil du die ganzen ECU-Informationen durch die N programmieren musst. Das ist also nicht zugänglich für jeden. Eine andere Option ist, Developer-Boards wie zum Beispiel Arduino zu verwenden und das sieht man oft an akademischen Papers. Du kannst natürlich das reproduzieren und den Source-Code einsehen. Das geht natürlich um die Hardware und Software. Aber mit kurzen Kabel kannst du trotzdem das gleich erreichen, wie ein echten Kabel. Und das ist nicht gerade motivierend für Anfänger. Die nächste Option ist ein professionelle Testbank zu benutzen. Das ist eine sehr gute Option, weil man den Source-Code verfügbar hat und man kann die ECUs erreichen. Also die Basisarbeit ist bereits gemacht. Aber das größte Problem ist, dass es super teuer ist. Das kann also sich nicht jeder leisten. Da gibt es natürlich immer Optionen, was zu studieren und zu lernen. Und ja, wir wollen die Leute halt die Lage bringen, dass sie motiviert sind und Sachen erreichen können. Mit anderen Industrien hast du viele Möglichkeiten loszulegen, mit einem Raspberry Pi und so. Wenn du mit Elektronik loszulegen willst, dann fängst du halt mit einem Arduino an und wir wollten irgendwie was ähnliches, aber für die Bildung im Automobil-Systembereich. Okay, die meisten Testbanken, Testungebungen, haben ungefähr vier ECUs und diesen mit einem Kanbus miteinander verbunden. Wir haben also alles das versucht auf einen Board zu kriegen und wir haben dieses Raman Visuel Gubas. Wir haben hier einen Kan-FD-Bus mit flexibulierenden Braten und ein Terminal-Block, ein USB-Eingang, um es an USB anzuschließen, um auch die Spannungsversorgung zu betreiben. Und natürlich kann man hier Sensor und Aktoren und zusätzliche Hardware einschließen. Und es gibt natürlich hier Testpunkte, damit man sie leicht erreichen kann, denn wir wollen ja daran fordern. Der gibt es eine Referenz zu Pasta, weil das eine freie verfügbare Sache ist. Die Nachrichten können unterschiedliche Payload-Güssen haben, sicherweise sind sie acht weit. Es gibt eine Zuwerteilungs-ID, zwei beiden Daten, zwei bei Zähler und dann vier bei Zufall, die man noch benutzen kann. Man kann natürlich die Formate variieren, wie ich sage hier, by wire. Das heißt, alle physikalischen Möglichkeiten sollen durch den Kan-Bus erreichbar sein. Das ist nicht unruh der Fall. Hier sieht man ein Block, den wir kommen, davon, basiert also so, wie ich das vorhin erklärt habe. Alle ECUs, periodisch, ihre Nachrichten, seien sie aus an alle anderen und man kann den Verkehr beobachten. Das sieht vielleicht ein bisschen kompliziert aus, aber so sieht man es hier. Okay, die Platine reicht aus, das Netzwerk zu simulieren und jetzt brauchen wir natürlich noch Sensoren und Akteuren, um das zu interaktieren. Das hier ist zum Beispiel ein Display, um die Infotainment-Bereich zu zeigen. Wir haben den Buddy-Domain, da haben wir den Schlüssel, den wir hier einstecken können, mit den Kontrolllampen, den Bereich, haben wir hier einen Poti, der Bremsen und den Steuerrad-Blenkrad simulieren kann. Und hier haben wir auch noch einen simulierten Gaspedal. Am Anfang beginnt es ein S-Like-Socket-Cann-Interface, der ja kein Unterlinux automatisch benutzt werden und wenn man das Board mit PSBI, mit dem Auto anschossen soll, dann soll es sich als USB-Cann-Adapter ausgeben und das heißt, man braucht keinen zulässigen Cann-Adapter. So sieht es aus, wenn es läuft. Wenn wir den Linux benutzen, dann sieht es aus, wie ein normales Kennnetzwerk gerät. Und dann können wir die ganzen Werkzeuge benutzen, um den Verkehr auszulesen. Zum Beispiel Kennsniffer. Hier ist die CanID-Links und die Payload auf der rechten Seite. Das heißt, wir können ein ECU mit Netzwerk interpretieren, aber es sieht immer noch nicht so aus, als ob man mit einem echten Auto interagiert. Eine ECU soll so realistisch wie möglich sein und nicht nur einfach so potent zur Meta auslesen. Und um das mit einem Open-Source-Auto-Simulator zu kriegen, wäre ein gutes Ziel, dass man sich so fühlt, als würde man fahren. Möglicherweise gibt es einen sehr einfachen Open-Source-Phase-Simulator. Es benutzt eine Python-AP und ist sehr einfach damit umzugehen. Und man kann sofort anfangen, damit RUMs experimentieren. Auf der anderen Seite steuern wir das Auto und kriegen die ganzen Signale über das ECU-Netzwerk. Und so wird das simuliert. Das ist jetzt nicht ganz real, aber es ist zu greifbar. Gibt hier auch Euron, um manuell darauf zuzugreifen. Es ist sehr einfach. Es gibt eine API, das Events-Data-Tour als Fahrtkontrollen benutzt, um die physikalische Simulation zu entinfluizieren. Wir haben eine Python-Klasse erstellt, die mit dem Canvas interagiert und mit Kala haben wir nur die Tastaturkontrollen mit den Daten aus dem Canvas ersetzen. Und die ganzen Informationen aus der Python-AP sind hier in den Physik-Simulator übertragen. Hier sind die Potenzienmeter und hier drücke ich die Beschleunigung und kann das Auto mit dem Wenkrad kontrollieren. Wir haben wieder Streamprobleme. Netzwerk-Kontrolle ist schön, aber automatisierte Kontrolle ist besser, denn man kann sich anschauen, was mit dem Canvas passiert. Im originalen Kala-System war schon immer eine Funktionalität für automatisieren, wo es eine KI gibt, die die Entscheidung trifft und mit dem Auto fährt. Das heißt, wir haben einen Algorithmus, aber die Kontrolle wird an das ECU-Netzwerk gegeben und wir senden die ganzen Sensor-Daten aus der Physik-Simulation an das Netzwerk, was identisch ist zu dem, was man sonst als Mensch macht. Die ganze Status wird von der KI an das ECU-Netzwerk weitergeleitet, sodass das Netzwerk weiß, welche Kontrolle die KI anders auszulösen möchte. Mit der Allerweise würde es sein, den Status per USB senden, dass dann als Canvas weitergedendet wird und alle ECUs im Netzwerk kriegen diese Informationen und fahren das Auto mit ihren eigenen Algorithmen weiter. Das heißt, zum Beispiel kann eine Bremse gesetzt werden und dann kriegen wir die höchste Nachricht vom KI und dem Potentiometer. Alle ECUs bekommen die Nachricht, manche ignorieren sie und benutzen sie und interagieren. Zum Beispiel, wenn die Bremsen gesteuert werden, dann soll die Bremsenkontrolle leichter angehen. Dann werden die ECU-Nachrichten weitergeleitet werden an den Computer, wo dann die Daten angepasst werden. Ich muss wieder die Handbremse lösen und dann fährt das Auto von selber. Das Auto wird vom ECU-Netzwerk kontrolliert, das heißt, wenn es bremst, dann kriegen das ECU die Nachricht auch. Das Bremskontrolle ist hier sehr sichtbar und jetzt wird sie wieder aufgehen, weil eine Bremsnachricht über den Canvas übertragen wurde. Da die ECU die Kontrolle macht, kann ich einfach eine Notbremsung einnalten, da ich die Bremse auf einstelle. Wenn man ein Canvas-Adapter anschließt, dann kann man die ganzen Nachrichten auch empfangen und senden. Mit RAM kann man mit dem Canvas spielen, ohne ein Auto zu haben. Wenn man eine ECU in der echten Welt ramieren möchte, dann gibt es zwei Optionen. Entweder man nutzt den Hardware-Bootloader oder man kann das auch mit der Diagnostik- und Kalibrationssoftware benutzen. Die sind abhängig vom Autohersteller und es gibt auch weitere Optionen, zum Beispiel diese Standard-Protokolle. Normalerweise hört man über UDS und OBD2, die auch auf IoTP aufbauen. Aber es gibt auch weitere Protokolle, wie zum Beispiel KWP2000 oder XCP. Alle diese Protokolle können auch anders implementiert werden. Bei Hardware-Bootloader hängt es davon vom Hersteller ab. Zum Beispiel kann man sie über Canvas updaten, über die Applications-Node 3154 oder über USB mit nur dieses 3156 oder andere Protokolle. Bei Rahmen benutzen wir den Mac-Controller und Canvas und vielleicht machen wir noch zusätzliche Protokolle. Wie man die ECU über die Standard-Protokolle benutzt, ist hier implementiert oder hier definiert. Es gibt eine regelkostige Software, aber manchmal kann man sie auf irgendwelchen Seiten auch kostenlos wenden. Was interessanter ist, ist der Hardware-Bootloader. Die Methodik, um den Controller in den Bootloader-Modus zu bringen, ist hier definiert. Hier unten ist definiert, wie man ihn über Ken neu programmiert. Es gibt einen speziellen Command-Code mit einem Argument. Wir wollten es einfacher machen, mit dem Controller zu interagieren. Hier ist ein Skript, das wir benutzen, um mit dem Controller zu interagieren. Wir geben die Debug-Informationen aus, auf den, zum Beispiel, der Version, eine ChipID, und dann gibt es sich einen Read-Memory-Command, um Teile aus dem Controller auszulesen. Das beinhaltet auch die Firmware. Das heißt, wir können hier mit Reverse Engineering anfangen. Wir können auch die Memory-Readout-Schutz einschalten und sehen, was dann passiert. Und in diesem Fall werden die Daten nicht mehr ausgelesen. Man kann es neu starten und danach können wir den Bootloader benutzen, um neu zu programmieren. Noch weitere Features. Hier gibt es zum Beispiel die erste PI-Pakete für den E-Prom und so. Das dritte, was wir gemacht haben, ist ein Wort, ein vertrauensvolles Plattform-Modul hinzuzufügen und das letzte ist eine Schnittstille, um einen ChipVisperer-Flüsterer dazu einzustecken. Also wir haben JTA Connection und ein weiteres Speicher für ein weiterer Wort. Diese Erweiterungen sind alle miteinander komfortibel. Man kann sie halt übereinander starten und ein sehr komplexes Netzwerk machen mit vielen ECUs und Speicher. Es sieht natürlich besser aus, wenn die Sachen übereinander sind. Aber weil wir das für Bildung machen wollten, haben wir natürlich auf die unterschiedlichen elektrischen Signale in der Weiterung versucht, unterschiedlichen zu machen. Also es sollte so sein, dass man leicht auch externe Tools anbauen kann. Man kann eine der vielen Debakpunkte benutzen, um es an Oszilloskop anzuschließen und dann hier zum Beispiel das Prozentsometer für die Bremse am Oszilloskop-Antat zu stellen oder digitale Signale untersuchen, indem man einen Logik-Analysator daran stießt, wie man hier zum Beispiel an diesem Bildschirm sieht. Die Hardware haben wir einfach designed, zwei Layer. Die Komponenten sind alle auf derselben Seite und wir haben große Toleranzen verwendet. Wenn du ein bisschen Lütz gehört hast, dann solltest du das selber zusammenbilden können. Wir haben die Hardware mit KeyCad designed. Das ist ein Programm um Hardware zu den Designisieren. Die Schematik und das Layout könnt ihr euch hier anschauen. Der Firmware ist mit dem STM32QE entwickelt. Man kann dort einfach konfigurieren die Schnittstellen. Du wirst zum Beispiel die geschätzte Stromverbrauch angezeigt bekommen. Aber du kannst natürlich auch selber damit interagieren und das beobachten. Wir haben RTOS als System benutzt und die Sachen parallel laufen zu lassen. Periodische Aufgaben können in Glyphen abgearbeitet werden und es gibt unterschiedliche Interrupt Services. Wir können Ques und DMA-Memory überschreiben und benutzen. Es gibt durchaus die ganzen Nachrichten, die sind in den Schlangen angeschätzt. Mit der berufsisesystemen konfigurieren, kann man das kausische Interface benutzen, um die Prioritäten zu sehen. Man kann Interrupts hinzufügen oder wegnehmen. Man kann auch die Schlangen angehen und sieht man zum Beispiel den Speicherverbrauch. Hier ist es noch viel Speicher üblich. Man kann also die eigene Anwendung hier oben drauf noch dazufügen. Das ist alles für den Hard- und Software-Bereich. Jetzt geht es mit dem nächsten Kapitel weiter. Ich würde euch ein paar Beispiele zeigen. Es gibt zwei Probleme üblicherweise für Leute, die in der Automatisierung sind, die arbeiten. Das ist eine Sicherheitskonferenz. Also muss ich euch nicht erklären, wie man Wissenschaften und Forschung in diesen Bereichen betreiben kann, in der Sicherheitsseite. Deswegen würde ich Diagnostik und Kalibrieren auch nicht sagen, weil das wird auch von vielen anderen Vorträgen schon behandelt. Also werde ich darüber die Zeit nicht verwenden. Also werden wir die Zeit dafür verwenden, um über Sachen zu reden, die auf Sicherheitskonferenzen oft nicht besprochen werden, und zwar Steuerungsalbumen und ein sicherheitskritischer Hard-and-Software. Und deshalb möchte ich hier ein Design für ein Tempomat vorstellen. Ich möchte euch zeigen, wie das für Sicherheitsingenieure relevant ist und wie das Ingenieure in Automobile-Industrie versuchen mit Open Source Tools zu verbessern, inklude und da Ramen für mit benutzen. Ich werde diese Sache dann als Referenz benutzen, um über andere Netzwerke zu reden und die Unterschiede zwischen Hard-and-Software. Also lasst uns anfangen. Tempomat ist sehr einfach. Je nachdem, wie gut der Fahrer die Gaspeder bewegt, wird er unterschiedlich schnell. Was wir wollen ist, dass ECU die Sache optimiert und dass wir eine dauerhaft gleichheitbleibende Geschwindigkeit haben. Also fahren. Ein automatisches Auto kann sehr einfach getrostelt werden. Du siechst ein Signal rein und die Geschwindigkeit kommt raus. Aber das ist nicht wirklich die Geschwindigkeit. Du musst auch die Gesetze der Dynamik beachten. Es gibt Köfte, die auf das Auto beeilen wirken. Die Masse und die Beschleunigung spielen eine Rolle und das Getreibung und den Antrieb. Wenn wir diese Virenzialkleichungen lösen, dann erwarten wir eigentlich, dass die Geschwindigkeit einen exponentiellen Verlauf hat und eine einfache Möglichkeit die Geschwindigkeit zu erreichen ist, den Controller zu eröffnen. Du hast eine Beziehung zwischen einer Trollen und der Geschwindigkeit. Diese ECU kannst du also benutzen, einen Lookup-Tabel in einem Tabelle nachzuschauen. Wenn du 100 km pro Stunde haben willst, dann musst du 20% öffnen und dann kannst du das weiterrechnen. Das ist natürlich in einer Situation mit der Trollenklappe so. Aber was ist denn, wenn wir jetzt ein bisschen berghoch fahren, dann werden wir Geschwindigkeit verlieren, weil die Gravitation ist nach unten. Das ist zumindest was wir erwarten. Aber wir sollten das auf dem Canvas verifizieren. Hier sehen wir einen externen Kanadaptor, der die Platine anschließt. An einem zweiten Computer sehen wir dann die Nachrichten. Ich habe nur die Firmware für die Antriebsachse ECU verangepasst. Ich habe sonst nichts angepasst. Der Simulator im Hintergrund wurde niemals modifiziert oder auch nicht neu gestattet. Hier fahre ich jetzt halt ein bisschen rum. Ich habe nach einem Platz gesucht, wo man am Anfang eine glatte Straße gehabt hat und dann einen Hügel der Berg aufführt. Dann habe ich das programmiert, dann habe ich das Auto fahren lassen und habe die Daten auf dem Canvas beobachtet und aufgezeichnet. Ich habe ein Open Source Tool benutzt, den Busmaster, der erlaubt es uns, die DBZ-Tasteilung anzuschauen. Ich habe Busmaster einfach gesagt, er soll alle Nachrichten mit dem Shuttle ID benutzen und aufzeichnen. Und wie die Payload aussah, das wollte ich wissen. Wenn ich das getan habe, kann ich das die Drosselung und die Geschwindigkeit über die Zeit darfloggen. Und das ist nicht, was ich erwartet habe von unseren DBZ-Ergleichungen. Die Geschwindigkeit hat einen exponentiellen Verlauf und es gibt natürlich ein bisschen Rauschen bei kleinen Geschwindigkeiten, aber sonst stimmt unser Modell. Was wir hier sehen, ist, dass es ungefähr 40 Sekunden dauert für eine Testfahrung. 40 Sekunden ist aber bereits viel zu lang. Wir benutzen die Software, die das simulieren kann und den Bus-Kontroll-Augurten muss schneller behandeln. Wir wollen nicht immer 40 Sekunden warten. Da gibt es natürlich oft Prof. Nettetool wie Matlab Simulink oder Psylab, aber hier wollten wir ein Open Source Tool nehmen, Psylab, genau. Das hat eine Schnittstelle, wo wir innen und Ausgänger, innen und Ausgänger anstellen können. Die Differenzialgleichungen sind manchmal schwierig zu behandeln, weil in Eingaben und Ausgaben sehr komplizit sein können. Du kannst die Laplace-Transformation benutzen, um die Variablen von T nach zu einer komplizierten Zeit S zu bekommen. Du musst nur wissen, dass die Differenzialisierung mit der Multiplizierung von S gleich gesetzt werden kann. In unserem System ist es einfacher, mit der Laplace-Transformation zu modellieren. Wir haben einfacher Zusammenhang zwischen Trosselung und Geschwindigkeit. Und basiert auf der Messung von Kanbus ist das die Transfer-Gleichung, 1 über 1 plus 4S. Wir können das Auto somit hier simulieren. Mit Psylab können wir diese Szenarien simulieren und die Antworten sofort bekommen. Mit Null-Geschwindigkeit anzufangen und nach 20 Sekunden haben wir die Karriktation hinzugefügt, also quasi den Anstieg. Und das ist natürlich eine Veränderung. Jede Psylab-Visualisierung kann man natürlich auch wieder Informationen rausbekommen. Wir wollen nach ungefähr 14 Sekunden sind wir in der Nähe des maximalen Geschwindigkeiten. Und sobald es eine Störung gibt, zum Beispiel die Karriktation, dann gibt es keine Reaktion der Trosselung. Das scheint also offensichtlich zu sein. Man braucht hier noch ein Feedback. Wir müssen dem ECU beibringen, dass er die Geschwindigkeitsdaten auswertet und mit benötigt. Die erste Möglichkeit, die wir zu überlegen ist die Peng-Peng-Steuerung. Wenn die Geschwindigkeit über eine Geschwindigkeit geht, dann hörst du auch zu Trosseln. Und wenn er runterkommt, dann fängst du es wieder an. Das kann man auch einfach in C oder C++ umsetzen und implementieren. Und wenn man das eingepackt hat, dann kann man den Kanbuss noch mal bemessen und dann sieht man, wir verlieren hier keine Geschwindigkeit mehr. Aber was man hier sehen kann, ist ein paar Schwingungen. Wie man sich das vorstellen kann, das ist nicht besonders nett für Mitfahrende. Und das ist der Grund, warum es die Tempomat-Steuerung entwickelt wurde. Das funktioniert jetzt so ein bisschen, aber das würde nicht ausreichen, um eine Geschwindigkeit zu regeln. Und ein weiteres Ding aus der Kontrolltheorie ist der PIT-Regler. Der PIT-Controller ist einer der Kontrollmechanismen, die häufig in Autoböserflair benutzt wird. Und der benutzt den Unterschied zwischen der Zielgeschwindigkeit und der aktuellen Geschwindigkeit. Und man kann diese Frequenz-Controller benutzen. Das ist integral von dem Unterschied. Und genau, das mit Kp. Es gibt zwei Beschleunigungen, Konstanten Kp, KI und Kd in diesem Fall. Man muss diese Verstärkungen sehr genau anpassen. Wir haben hier unterschiedliche Verstärkungsoptionen und optimieren das dann. Wir können simulieren und schauen, wie man damit das Auto echt fahren kann. Wenn wir die richtigen Werte hier einstellen können und eingestellt haben, dann kriegen wir dieses hier. Die ECU kriegt, dass die Zielgeschwindigkeit ziemlich schnell erreicht. Und wenn ein Unterschied ist, wird die Kontrolle dynamisch angepasst, dass der Zielgeschwindigkeit eingehalten werden kann. Das ist gut, weil das ist, was wir haben wollen für eine Cruise-Controller, eine Geschwindigkeits-Controller. Aber wenn ein dieser Werte falsch ist, dann kriegen wir komplett anderes Ergebnis. Und das ist ein Problem, weil wir müssen diese Daten, die Kalibrationsdaten immer richtig haben. Weil wenn die falsch kalibriert sind, können sie zu einem falschen, zu einer gefälligen Situation kommen zu einem gefälligen Verhalten der Kontrolle. Was jetzt ist, wie wir diesen Algorithmus in C bekommen, ist nicht einfach, weil die Integration und so nicht digital umsetzbar ist. Die erste Möglichkeit ist es, anzunehren. Wir schauen die Unterschiede der Fehler an und wir können das Integrationsalgorithmus annähern mit einer Summe der unterschiedlichen Fehler. Und das Ganze wird über die Samplingzeit multipliziert. Aber wenn wir uns das näher anschauen, dann ist nur eine Kombination von Konstanten und Werten, die Nachrichten aus dem Kennbus berechnet werden können. Die echte Implementation in C sieht so aus. Wir haben die zwei Variablen, den einen um die aktuellen Abweichungssumme zu haben und die letzte Elsteabweichung zu haben. In der Kontrollsteife haben wir diese Konstanten und wir berechnen den aktuellen Abweichung. Wir addieren den Fehler zu der Federsumme oder die Abweichung zur Abweichungssumme und wir schauen den Unterschied zwischen den aktuellen Abweichung und der vorherigen Abweichung an, senden die Werten in den Output-Variabler und überprüfen, dass es nicht zu weit außerhalb des gültigen Bereichs kommt. Und dann setzen wir den nächsten Abweichung auf die letzte Abweichung. Die zweite Herangehensweise ist eine Laplast zu benutzen. Wir machen eine Z-Transformation, der Laplast-Transformation. Es ist ziemlich komplex, aber es gibt viele Werkzeuge, die das für einen machen, wenn ihr das behandeln wollt, dann könnt ihr eine biliniere Transformation benutzen, wo es mit dem hier ersetzt wird. Und ja, dann kann man da Mathe drauf anwenden. Und das sieht jetzt alles komplex aus, aber man kann das hier auch wieder berechnen. Wir haben die Daten von zwei Daten, von den vorherigen Abweichen, die aktuelle Werte und vorherige Sensorwerte. Und es ist equivalent, aber es sieht komplett anders aus. Und was ich hier nochmal sagen möchte, dass unterschiedliche Algorithmen unterschiedlich implementiert werden können. Und das, ja, zwei equivalenten Algorithmen, die unterschiedlich implementiert sind. Das ist schwer für Reverse Engineer. Und beide sind in der Lage, eine konstante Geschwindigkeit für das Auto zu erreichen. Das ist das Beispiel, was ich euch zeigen wollte, mit realistischen Inhalten auf dem Kennenbus, wo die ECUs nicht irgendwelchen sinnfreien Arbeit machen. Die Theorie ist ein bisschen komplex. Und wenn es zu schnell war, dann hoffe ich, dass es euch wenigstens zeigt, dass noch viele Methoden Sachen gibt, die erforderlich werden können, die ihr euch selber anschauen könnt. Und jeder Schritt wurde mit Open Source Werkzeugen realisiert. Jetzt würde ich ein paar sagen, was der Unterschied zwischen echten ECUs ist und echte ECUs Software ist nicht so einfach wie das hier. Außerdem möchte ich die Sachen, die, ja, wir haben gezeigt, dass diese Cruise Control funktioniert, aber wir haben nur ein sehr einfaches Szenario, zum Beispiel nur auf dem Flatten VR. Aber was ist dieses Szenario, wo ein Auto davor langsam fährt oder ein Szenario, wo wir in Hügel herunterfahren? In dieser Situation kann es nicht zu einer Beschleunigung kontrollieren, weil sie Bremsen nicht kontrolliert. Und dass die Frage ist, was für Sicherheit ist, kann man alle Szenarien finden, kann man alle kontrollieren und sichern. Das ist was Automotive Safety oder Autosicherheit so unterschiedlich macht. Um zu beweisen, dass es relativ sicher ist, muss man diesen Standard befolgen. Und der Standard definiert unterschiedliche Anforderungen an die ECUs. Nicht alle sind gleich relevant und darum gibt es immer ein Auto-Sicherheits-Integriertats-Level. Sie sind ACLA von nicht so relevant und ACLD sehr relevant. Das heißt, wenn man eine wirkliche Control-Instance macht, dann kann man nicht einfach nur irgendwelche Sachen anschließen und auf der Autobahn berußen. Man muss viel analysieren, man muss eine Haarsop-Analyse machen und so weiter. Es gibt so viele Anforderungen, dass die nur nicht mehr von einem Menschen in der Nacht verfolgt werden können. Darum gibt es dedizierte Werkzeuge, um diese Anforderungen zu überwachen. Wie wäre die Software an das? Die Hauptziel von Automotive Security ist es, die Sicherheit hinzuzufügen. Aber ohne Umgehungsmethoden können viele Sachen falsch werden. Es kann z.B. ein Back-in-Code sein. Es kann sein, dass irgendwelche Transistenzfehler, irgendwelche Hardware existieren. Es könnten Probleme mit den Bibliotheken und der Toolshine, die die Firma erstellt. Und es kann auch Probleme mit den Bibliotheken in z.B. den Betriebssystemen existieren. Wenn wir auf diesen Teilen des Beispieles schauen, dann sehen wir, dass es eine grausame Implementation ist. Wir haben Integers und unnichtsignierte Integers und Floats und überprüft das nicht, wie das ordentlich gekastet wird und andere Fehler. Das ist aus Sicherheitsgründen nicht akzeptabel aus Safetygrund. In diesem Fall ist es sehr klar, aber teilweise sind es sehr kleine Fehler, die irgendwo sind. Und die machen dieses System gefährlich. Und um solche Szenarien zu umgehen, muss in der Regel eins von diesen Sachen benutzt werden, von diesen Coding-Skatlines, benutzt werden. Normalerweise wird in der Automotive-Industrie MISTRA-C benutzt. Bei der Autoherstellung ist es ziemlich ähnlich zu CRC, die woanders benutzt wird. Um einen Sprach-Subset, nur einen kleinen Teil der Sprache zu benutzen, ist nur ein Teil der Anforderung. Es gibt noch viele andere Anforderungen. Man muss sicherstellen, dass die Software relativ klein ist, sicherstellen, dass die Software gut funktioniert und dass die nicht zu viele Interrupts passieren. Aber man muss auch noch weitere Anforderungen, wie zum Beispiel WoEinstritts und Ausgangspunkte sind, globale Variablen, Limitieren und so weiter. Was andere Problem ist, auch mit Bugs, ist, dass es Fehler passieren können. In den Gibbungen, in einem Auto sind Daten nicht immer zuverlässig. Es kann ein Bitflip sein, oder außerhalb des Arbeitsspeichers, zum Beispiel, dass das Radiointerferenz ist auf den Datenleitungen. Das sind grundlegende Hardware-Fehler, aber sie müssen von der Software abgefangen werden. Und das kann zu kleinen Fehler zu großen Auswirkungen führen. Und um diese Probleme heranzugreifen, gibt es redundante CPUs oder redundanten Daten, die gespeichert werden. In ECUs wird normalerweise Mikrocontroller für Autos hergestellt worden. Aber in der Regel braucht man da einen Geheimhaltungserklärung unterschreiben. Aber das macht es ein bisschen schwer, sie zu analysieren in echten Mikrocontrollers von echten Software-Design. Aber EC26262 ist nicht der einzige Standard für dieses Autosichtsthema. EC26262 ist von IEC 61508 angeneitet und die sind ähnliche Konzepte. Und die meisten EC61508-Kontroller haben keine Geheimhaltungserklärung. Und für diese Mikrocontroller braucht man keine Geheimhaltungserklärung. Man kann die Features finden, die die Software benutzt und man kann weitere Daten anfordern, um komplett zu werden. Und um diese Daten zu bekommen, müsste man eine Geheimhaltungserklärung unterschreiben. Aber ich glaube nicht, dass diese Daten nicht für Forschung nicht benutzt werden können. Aber das sind ähnliche Konzepte und nur für Forschung und nicht, um sie in einem Auto zu benutzen. Ich kann jetzt nicht über alle Sicherheitsfeatures reden, aber insbesondere hier die Sicherheitsretondanz und wie wir sie benutzen. In diesem Beispiel haben wir diese Daten im Arbeitsspeicher als Konstanten, um die Daten sicherer zu machen. Sollten sie in Datenflash liegen, um sicherzustellen. Und sie sollten nie zweimal gespeichert werden und sollten im Idealfall mit Sicherheitschecksum geschützt werden, dass sie nicht kaputt gehen. Es gibt auch diesen SRAM Bereich. Kritische Variablen müssen in einem speziellen Bereich geschrieben werden. SRAM 2, wo Bitflips gefunden werden. Konstanten möchte man auch Schreppschutz aktivieren. Es ist auch nur in SRAM 2 verfügbar. Und letzte über Software. Wir benutzen die GCC Toolchain. Aber wir müssen sicherstellen, dass es keine Fehler durch die Kompile hinzugefügt werden. D.h. da können wir keine GCC benutzen. Echtzeitbetriebssysteme müssen auch zertifiziert sein und FreeARTOS ist nicht zertifiziert. Oder nur begrenzt zertifiziert. Aber es sieht so aus, als ob Azure RTOS benutzt werden könnte. Irgendwann in der Zukunft. Also, dass echte ISO 26262 Betriebssysteme benutzt werden können. Und dann lassen wir doch mal über Hardware reden. Wenn das nicht klar war, wir können diese Software nicht benutzen in einem normalen Auto. Weil ein kaltes Auto, ein geparktes Auto sehr extrem mit Temperaturen ausgesetzt werden könnte. Und wenn ihr denkt, darüber nachdenkt, wie das schwer das Leben ist im normalen Passagierbeteil, dann denkt drüber nach, wie hoch die Anforderungen auf ein Auto, auf die Kontrolleinheiten von einem Motor z.B. sind. Und extreme Temperaturen sind nur einen der unterschiedlichen Interfaces. Es muss auch noch sicher vor unterschiedlichen anderen Sachen sein, z.B. Staub und elektromagnetische Strahlung sein. Und auch sicher vor Menschen sein. Und das können wir machen, um es dagegen zu schützen. Es gibt also viele Anforderungen an die Komponenten. Es gibt Elektromikation. Und wenn Metall aus den elektrischen Komponenten rausgeht, dann haben wir ein Problem. Das könnte in einen sehr gefährlichen Fehler führen. Offensichtlich müssen die ECUs so designen, dass sie diese potenziellen Schwierigkeiten bewinden können. Und um stresvolle Umgebungen zu simulieren, gibt es entsprechende Werkzeuge, was wir machen können, das einzelne Komponenten zu testen, bei AIC. Das ist ihr könnt sie auch an deinem Besuch. Auf der einen Seite haben wir versucht, ein Design zu machen, das ähnlich ist. Aber natürlich ist es viel weniger verfügbar. Also wir haben z.B. die AIC Q100 versucht einzuhalten, außer natürlich die Verbindung zum Mikrocontroller, denn die sollten verfügbar sein. Das ist wie leicht. Bindet es bei uns von minus 40 bis ungefähr 125 Grad. Es ist schon eine große Reichweite, aber es ist noch nicht ausreichend für die elektronischen Deuereinheiten in Fahrzeiten. Also wir hoffen, dass wir damit einen Einfluss haben auf die Herstellung und Toleranz in der Umweltbedingung der ECUs und der Zukunft. Ein Sicherheitsingenieur, der z.B. auf die Hardware-Charakteristik achten muss. Die müssen dann halt vielleicht da noch was bedenken. Also man kann jetzt leicht einen großen Testbereich von vielen Netzwerken haben, aber nicht alles ist 100% perfekt. Und jetzt der letzte, der letzte Kapitel. Die Sicherheitsgegenmaßnahmen. Das machst du natürlich auch in anderen Industrien. Wenn du deine Kreditkarte erkennst, wenn es zu kalt ist, dann sagst du vielleicht, das ist wahrscheinlich ein Angriff, ich mach jetzt nicht weiter. Auf der anderen Seite muss das Auto schnell reagieren. Die Kreditkarten haben wir uns in Auslaufdatum nach ein paar Jahren. Autos haben sowas eher nicht. Die sind eher jahrzehntelang da. Und die Sicherheitsgegenmaßnahmen sollten natürlich weiterhin bestehen. Es gibt also unterschiedliche Anfrüchte. Ein Sicherheitstechnologie ist offensichtlich selten sicherer, wenn es auch kälter wird. Hier gibt es z.B. Coldboot-Angriffe, bei hohen Temperaturen gibt es auch Paper, die sagen, manche Sachen verhalten sich anders. 60 Grad oder 100 Grad macht das vielleicht Unterschiede für die ECUs. Es ist außerdem so, dass ältere Elektronik andere Sicherheitseigenschaften haben. Die Sicherheitsmerkmale, solche Mikrocontroller, erlauben auch andere Attacken, z.B. Glitching-Angriffe. Selbst der ISO 26262, das ist die höchste Sicherheitsstandard, ist anfällig für Glitching. Das ist also vermutlich genug, deine Segenkreditzugabe mit hin. Man muss also die Sicherheitsproblemstrategien überdenken. Mit Kreditkarten ist es nicht unbedingt unüblich, zu sagen, wenn die Authentifizierung nicht funktioniert hat, versuch's einfach nochmal. Und wenn es dann funktioniert, alles gut. Es geht hier nicht um Leben und Tod. Aber in einem Auto, wenn du versuchst, die Bremse zu drücken und die kann sich nicht authentifizieren, was sollte das Auto dann tun? Sollte das Auto sich wie sollte sich das Auto verhalten? Vielleicht ist es eine Angriff und dann solltest du oder es ist nur ein Fehler. Und was ist das Schlimmerere davon? Wenn wir jetzt Komplexität in das System hinzufügen, haben wir auch die Wahrscheinlichkeit für Probleme erhöhnt. Was ist schlimmer, wenn wir bremsen, weil es ein Angriff ist oder weil wir nicht bremsen, weil es ein Fehler ist? Und es gibt keine einfache Antwort auf diese Frage. Viele Sicherheitsgegenmaßnahmen, insbesondere bei Autos, sagen, man muss den Cannbus entschlüssen und macht die Debugports aus und verschlüsselt deine Filmwehr. Wenn du ein Fehler in der ECU vermutest, dann musst du dahinter hergehen. Du kannst dich auf das Auto austauschen. Diese Fehler können Leute verletzen. Technologie kann beides machen. Anforderungen erfüllen und Sicherheit zum Forschung verbessern. Ohne Geheimhaltungserklärungen oder extreme Kosten. Und jetzt wollen wir natürlich Angriffe simulieren. Also eine Möglichkeit, eine Entwürze kann Nachricht auf den Bus zu werfen, um das Auto anzugreifen. Und jetzt schauen wir uns das hier an. Eine andere Sache, die ich nicht angesprochen habe, ist Angriffe auf Sensoren und Akteuren. Ich habe einfach mal das Link hat hier verändert und diese Situation, das heißt nicht, dass die Kontrolle über das Lenkrad verloren hat. Es versucht einfach noch weiterhin glatze kommen. Okay, ich bin am Ende meines Vortrags. Wir haben eine billige, sichere und interaktive Plattform erstellt um Forschung und Erkundung und Lehre an Automativen Systemen zu ermöglichen. Es ist für Beginner freundlich. Sie sind nicht ganz Automobil-Lebbel, aber sind dicht genug dran, um Bildung und Forschung zu betreiben. Und wenn ihr Fragen habt, dann sprecht uns gerne an. Schienen, lieben Dank für diesen umfassenden Vortrag. Der war hervorragend. Wir haben leider nicht mehr sonderlich viel Zeit für Fragen, aber eine Frage kam aus, wie habt ihr das Design, wie viel kostet das, wie kann man das bekommen? Also ich habe alles mit Keycard designt. Vor ein paar Jahren war es sehr schwierig, Hardware zu designen, aber heutzutage gibt es footprint zu Bibliotheken online. Es ist sehr viel einfacher geworden. Es kostet zwischen 50 und 100 Euro. Die Mikro-Kontrolle sind natürlich die teuren und die Platine, die Teile sind natürlich von der Platine abhängig. Wenn du Fragen hast, schreibt mich auf GitHub an oder...