Autor: Karsten Schmidt, AUDI AG Viele moderne embedded Systeme sind h\u00e4ufig verteilte Systeme, wobei an diese Systeme zus\u00e4tzliche Anforderungen bez\u00fcglich Safety, Security und Echtzeit gestellt werden. Speziell der aktuelle Umstieg auf Ethernet-basierende Kommunikationssysteme bedingt eine kritische Betrachtung der angewandten Kommunikationsparadigmen, um eine effiziente Kommunikation zu erm\u00f6glichen. Im Rahmen dieser Ver\u00f6ffentlichung werden Entwurfskriterien unter Ber\u00fccksichtigung einer sogenannten End-to-End-Betrachtung diskutiert. Es wird gezeigt, warum eine\u00a0End-to-End-Betrachtung von Kommunikationsbeziehungen unter Ber\u00fccksichtigung von querschneidenden Aspekten f\u00fcr eine gute System\u00adarchitektur wichtig ist. Anhand von Beispielen aus dem Automotive-Bereich werden\u00a0End-to-End-Eigenschaften diskutiert, und es wird untersucht, inwieweit diese Eigenschaften massiven Einfluss auf eine System- und Softwarearchitektur haben. Zus\u00e4tzlich wird das Thema der dabei notwendigen Softwareabstraktion betrachtet.<\/strong><\/p>\n Viele moderne embedded Systeme sind h\u00e4ufig verteilte Systeme, wobei an diese Systeme h\u00e4ufig zus\u00e4tzliche Anforderungen bez\u00fcglich Safety, Security und Echtzeit gestellt werden. Ein rapide steigender Vernetzungsgrad von Fahrzeugen und der sich abzeichnende Trend zu hoch automatisierten und autonomen Fahrzeugen zeigen die Notwendigkeit, dass querschneidende Aspekte gemeinsam betrachtet werden m\u00fcssen. Zus\u00e4tzlich ist es notwendig, die angewendeten Kommunikationsparadigmen kritisch zu betrachten, um eine effiziente Kommunikation zu erm\u00f6glichen.<\/p>\n Im Weiteren erfolgt eine kritische Diskussion und der Vergleich g\u00e4ngiger End-to-End-Paradigmen sowie die resultierenden Effekte auf die Softwarearchitektur und deren Einfluss auf die technische Umsetzung. Beim Entwurf von verteilten System geht es letztlich um die Frage, wo welche Teile platziert werden und welche Aufgaben diese Teile im Gesamtverbund eines verteilten embedded Systems haben. In einem solchen Kommunikationssystem trennt man gew\u00f6hnlich die Kommunikationsinfrastruktur und die eigentliche Anwendung, welche die Kommunikationsinfrastruktur nutzt. Jedoch besteht bei dieser Herangehensweise die Herausforderung, dass bestimmte Teilaufgaben der Kommunikation auf verschiedene Weise gel\u00f6st werden k\u00f6nnen. Im Folgenden soll dieser Punkt n\u00e4her untersucht werden.<\/p>\n Wir gehen von folgendem Szenario (siehe Bild 1,\u00a0PDF<\/a>) aus. Es existieren zwei Anwendungen, welche bidirektional Daten austauschen. Dazu benutzen die Anwendungen einen Kommunikationsstack und \u00fcbertragen die Anwendungsdaten \u00fcber ein Netzwerk.<\/p>\n Die interessante Frage lautet: „Welche Annahmen kann die eigentliche Anwendung \u00fcber den Kommunikationsstack und das Netzwerk treffen?“ Des Weiteren kann man diskutieren, wie die eigentliche Anwendung Anforderungen an die tieferen Schichten stellen kann. Das betrifft interessanterweise auch Anforderungen an den Kommunikationspartner. Zu den Fragen, die nun f\u00fcr die eigentliche End-to-End-Anwendungskommunikation betrachtet werden m\u00fcssen, geh\u00f6ren unter anderem:<\/p>\n Diese Betrachtung ist nicht neu. Bereits in [3] wurde dieser Aspekt betrachtet und in [4] ankn\u00fcpfend diskutiert. Fokus war hier jedoch die klassische IT-Dom\u00e4ne. In [1] und [2] erfolgte eine Anwendung dieser Ideen f\u00fcr die rein zeitliche Betrachtung einer End-to-End-Kommunikation innerhalb eines Kommunikationsnetzwerkes eines Fahrzeuges. In [13] erfolgte eine Security-Betrachtung f\u00fcr eine Kommunikationskette Fahrzeug – Backend – Backend. F\u00fcr di PDU-basierte Kommunikation existiert innerhalb des AUTOSAR-Standards [7] die M\u00f6glichkeit, die \u00fcbertragenen Daten gegen zuf\u00e4llige Fehler zu sch\u00fctzen. Neben den rein technischen Themen erfolgte in [10] auch eine Betrachtung der notwendigen Paradigmenwechsel in Bezug auf Timing-Fragestellungen. Auch in den RFC sind Hinweise auf diese \u00dcberlegungen zu finden [5] und [6].<\/p>\n Betrachten wir ein typisches vereinfachtes Beispiel aus dem Bereich des hochautomatisierten Fahrens (siehe Bild 2,\u00a0PDF<\/a>).<\/p>\n F\u00fcr eine Funktion des hochautomatisierten Fahrens wird folgendes Szenario betrachtet: Startend von Sensoren \u00fcber die in den Steuerger\u00e4ten zu verarbeitenden Sensordaten bis zu den Aktuatoren werden Daten fusioniert und aggregiert, um komplexe Entscheidungen zu treffen, die letztlich das Fahrverhalten aktiv beeinflussen. Diese Prozesse erzeugen besondere Herausforderungen an eine holistische Systemmodellierung.<\/p>\n Betrachtet man dieses Szenario, ergeben sich einige interessante Fragestellungen. Zun\u00e4chst ist zu kl\u00e4ren, wo die eigentlichen Endpunkte der Kommunikation zu finden sind. Im Sensor scheint es noch relativ einfach zu sein. Aber auch hier existieren unterschiedlichste technische Umsetzungen, die durch die Unterschiede bei der gew\u00e4hlten Kommunikationsanbindung die Systemkomplexit\u00e4t erh\u00f6hen.<\/p>\n Endpunkt dieser Kommunikation ist nun das zentrale Steuerger\u00e4t, welches wiederum Teil einer weiteren Kommunikationsbeziehung ist. Aus reiner Anwendungssicht existiert zus\u00e4tzlich die logische bzw. funktionale Beziehung Sensor zu Aktuator. So muss z.B. beim Erkennen eines Hindernisses der Aktuator eine entsprechende Reaktion ausl\u00f6sen.<\/p>\n Ausgehend von der Systembetrachtung ergeben sich nun einige interessante Frage\u00adstellungen, f\u00fcr die im Automotive-Kontext L\u00f6sungen existieren, die jedoch f\u00fcr andere Industrien in \u00e4hnlicher Auspr\u00e4gung existieren.<\/p>\n Hier geht es um den Aspekt, dass sich Sender und Empf\u00e4nger sicher sein k\u00f6nnen, dass die Daten w\u00e4hrend der \u00dcbertragung nicht zuf\u00e4llig, also durch St\u00f6rungen, ver\u00e4ndert wurden. In der Automobilindustrie gibt es etablierte Standards, um dies sicherzustellen (siehe [7]). Wie bereits in der Original-Ver\u00f6ffentlichung [3] diskutiert, muss beim gesamten Systementwurf und bei der Softwareentwicklung diskutiert werden, wo die notwendigen Komponenten f\u00fcr die ASIL-D-Funktionalit\u00e4ten umgesetzt werden. In [11] ist dazu eine Diskussion f\u00fcr ASIL-Steuerger\u00e4te zu finden.<\/p>\n Security ist ein abstrakter Begriff, der die Widerstandsf\u00e4higkeit eines Systems gegen\u00fcber vors\u00e4tzlichen Angriffen beschreibt. Dementsprechend ist der wichtigste Unterschied zum vorherigen Abschnitt der, dass \u00fcber Effekte durch b\u00f6swilligen Eingriff auf die Datenkommunikation gesprochen wird. Dazu geh\u00f6ren:<\/p>\n F\u00fcr Security-Betrachtungen richtet sich ein Angriff auf einen bestimmten Teil des Systems, wie z.B. Schnittstellen, Anwendungen oder Kommunikationskan\u00e4le. Typische Angriffsziele im Automobilbereich sind Steuerger\u00e4te (Electronic Control Units (ECUs)), Diebstahlschutzsysteme, Vernetzungs- oder Zahlungssysteme. Typische Angriffe versuchen, die Entfernung von Sicherheitsabfragen, das Abh\u00f6ren bzw. Modifizieren von Kommunikationsdaten oder \u00c4nderungen an der originalen Firmware zu erreichen [13]. W\u00e4hrend des Systementwurfs werden basierend auf einer Risikoanalyse die notwendigen Systemkomponenten identifiziert, die notwendig sind, um entsprechende Gegenma\u00dfnahmen umzusetzen. Aber auch hier spielt die Frage der Verortung der notwendigen Softwareteile eine wichtige Rolle.<\/p>\n Quality of Service [12] beschreibt die G\u00fcte eines Dienstes in einem Kommunikations-netzwerk. Innerhalb eines Netzwerkes finden unterschiedliche Kommunikationsabl\u00e4ufe mit unterschiedlichsten Protokollen statt. F\u00fcr jeden dieser Kommunikationsabl\u00e4ufe m\u00fcssen verschiedenste Aspekte betrachtet werden. Beispielsweise das Zeitverhalten, das sich in der Latenz, also der Laufzeit der Nachricht, sowie dem Jitter, also der maximalen \u00c4nderung dieser Laufzeit, ausdr\u00fcckt.<\/p>\n An den Netzwerkknoten sind Puffergr\u00f6\u00dfen sowie die Priorisierung der Nachricht bzw. des Datenpakets relevant. Innerhalb eines Steuerger\u00e4tes ergibt sich die notwendige Absch\u00e4tzung der dazu notwendigen Ressourcen. Dazu geh\u00f6ren die notwendigen Speicher f\u00fcr erforderlichen Buffer f\u00fcr unterschiedlichste Nutzdaten und die sich ergebene Rechenzeit f\u00fcr die Verarbeitung dieser Daten. Erschwerend kommt hinzu, dass die Last, die sich f\u00fcr ein einzelnes Steuerger\u00e4t ergibt, auch davon abh\u00e4ngt, wie die Gesamtkommunikation innerhalb des Fahrzeuges organisiert ist. Es ist also wichtig, die komplette Kommunikationskette zu untersuchen, da sich z.B. die Latenz \u00fcber alle Knotenpunkte betrachtet aufsummiert (vgl. Bild 2,\u00a0PDF<\/a>).<\/p>\n Ein weiterer interessanter Aspekt innerhalb dieser Betrachtungen nimmt die Software ein. Das betrifft sowohl die Anwendungssoftware als auch die Software f\u00fcr den Kommunikationsstack. In Zukunft gewinnt die Fragestellung, wo die notwendige Funktion platziert wird, die die Security, Safety oder Quality of Service sicherstellt, immer mehr an Bedeutung.<\/p>\n Die Nutzung von Standardsoftware erscheint in vielen F\u00e4llen attraktiv, da man sich mit den oben angesprochenen Fragestellungen nicht auseinandersetzen muss („die Basissoftware wird\u2019s schon richten“). Jedoch deckt dieser Ansatz typischerweise nur einen Teil der Systemanforderungen ab [14]. Durch eine geschickte Auswahl der notwendigen Software und deren sinnvolle Aufteilung in den Kommunikationsstack oder die Anwendungssoftware k\u00f6nnen effizient Systeme entwickelt werden, die zus\u00e4tzlich ein hohes Ma\u00df an Zuverl\u00e4ssigkeit besitzen.<\/p>\n Erschwert werden die Systementwicklung, Funktionsentwicklung und die eigentliche Softwareentwicklung durch die Aufgabenteilung innerhalb der Organisation. Zus\u00e4tzlich existiert die Notwendigkeit des notwendigen Know-How-Schutzes bei der Zusammen\u00adarbeit unterschiedlicher Firmen. In [10] ist dieser Fakt ausf\u00fchrlich beschrieben. Verst\u00e4rkt wird dieser Effekt durch die Integration unterschiedlicher Softwareanteile in ein Steuerger\u00e4t. Bedingt durch die Zusammenarbeit \u00fcber Firmengrenzen hinweg und die Integration von Software unterschiedlichster Parteien ist es f\u00fcr den eigentlichen Integrator schwer, bei Problemen mit einem Gesamtsystemverst\u00e4ndnis an die Fehlersuche zu gehen. Bei Fragestellungen, die Security- oder Safety-Themen betreffen, wird dies noch anspruchsvoller.<\/p>\n Die Komplexit\u00e4t im Entwicklungsprozess hochintegrierter Steuerger\u00e4te erfordert eine Ber\u00fccksichtigung von querschneidenden Entwurfsaspekten. Dazu geh\u00f6ren neben Security und Safety auch Fragen der Echtzeitf\u00e4higkeit und des Ressourcenverbrauches. Es ist wichtig zu verstehen, dass dies keine leichte Aufgabe ist, sondern dass dazu vielmehr ein Paradigmenwechsel notwendig ist. Die AUDI AG arbeitet aktuell an der Etablierung eines Security-Prozesses. Dabei werden Erfahrungen aus den Safety-Prozessen entsprechend \u00fcbernommen und adaptiert.<\/p>\n Einfache Architektur-Standardl\u00f6sungen existieren nur f\u00fcr sehr wenige Spezialf\u00e4lle. Wichtig ist die F\u00e4higkeit, komplexe Architekturen zu modellieren und zu analysieren sowie die Kompetenz von Systemarchitekten auch in den neuen Fragestellungen auszubauen.<\/p>\n [1] K. Reif, K. Schmidt, F. Gesele, S. Reichelt, M. Saeger, N. Seidler, „Networked control systems in motor vehicles“ in ATZelektronik worldwide, 04\/2008 Pages 18-23, Springer Fachmedien Wiesbaden GmbH (2008)<\/p>\n [2] K. Schmidt, M. Buhlmann, C. Ficek, K. Richter, „Design Patterns for Highly Integrated ECUs with various ASIL Level“, ATZ elektronik worldwide Edition, 2012-01.<\/p>\n [3] J.H. Saltzer, D.P. Reed and D.D. Clark, „END-TO-END ARGUMENTS IN SYSTEM DESIGN“, M.I.T. Laboratory for Computer Science<\/p>\n [4] T. Moors, „A critical review of ‚End-to-end arguments‘ in system design“<\/p>\n [5] RFC 3117, „On the Design of Application Protocols<\/a>„<\/p>\n [6] RFC 3439, „Some Internet Architectural Guidelines and Philosophy<\/a>„<\/p>\n [7] AUTOSAR 4.3 „Specification of SW-C End-to-End Communication Protection Library“<\/p>\n [8] AUTOSAR 4.3 „Specification of Module Secure Onboard Communication“<\/p>\n [9] K. Schmidt, „Ethernet und IP-Netzwerkstacks im Auto“, ESE-Kongress 2016<\/p>\n [10] K. Schmidt, D. Marx, K. Richter, K. Reif, A. Schulze, T. Fl\u00e4mig, „On Timing Requirements and a Critical Gap between Function Development and ECU Integration“, SAE World Congress, April 2015, Detroit, USA<\/p>\n [11] J. Wolf, P. M\u00fcller, „Sicherheit und Leistung durch ASIL-D-AUTOSAR-Basis-software“, Hanser automotive 7-8\/2016<\/p>\n [12] F. Netter, F. Reimann, „Quality of Service (QoS) in geswitchten Fahrzeugnetz\u00adwerken“, International Congress Electronics in Vehicles, 2015, VDI-Berichte Band 2249 (2015) Seite 561-572<\/p>\n [13] A. Weimerskirch, „Do Vehicles Need Data Security?“, SAE International, December 2011.<\/p>\n [14] C. Jakobs, P. Tr\u00f6ger, „Quo vadis, AUTOSAR?“,\u00a0\u00a0INFORMATIK 2017,<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Security steht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\n
\n<\/strong><\/p>\nBeitrag – Embedded Software Engineering Kongress 2017<\/h3>\n
Einleitung<\/h2>\n
Problemdefinition<\/h2>\n
\n
Stand der Technik<\/h2>\n
Systembetrachtung<\/h2>\n
Typische Herausforderungen<\/h2>\n
Sichersellung der Daten\u00fcbertragung unter Safety-Gesichtspunkten<\/h2>\n
Sichere Kommunikation f\u00fcr sensible Daten zwischen ECUs<\/h2>\n
\n
Quality of Service<\/h2>\n
Softwareentwicklung<\/h2>\n
Zusammenfassung<\/h2>\n
Literaturverzeichnis<\/h2>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n