SOA Flashcards
Start & Hauptziel
Start
Sehr geehrte Damen und Herren, Liebe Kommilitoninnen und Kommilitonen, ich begrüße Sie herzlich zu meinem Vortrag „Optimierung und Zeitanalyse Serviceorientierter Architekturen auf E/E-Architekturen“.
Hauptziel
Das Hauptziel meines Vortrags ist die Veranschaulichung des Ansatzes aus dem Konferenzbeitrag „Model-Based Resource Analysis and Synthesis of Service-Oriented Automotive Software Architectures“ von den Autoren Obergfell, Kugele und Sax, das im Jahr 2019 in München von der Institute of Electrical and Electronics Engineers veröffentlicht wurde.
Inhalt
Inhalt
Davor werde ich auf die wichtigsten Änderungen in der Automobilindustrie eingehen, die der Grund für den Einsatz solcher Ansätze sind. Da eine Serviceorientierte Architektur die Basis des Ansatzes bildet, werde ich im nächsten Teil eine Einführung dazu geben. Danach werde ich kurz den Unterschied zwischen Signalbasierter und Serviceorientierter Kommunikation verdeutlichen. Der Rest dieses Vortrags wird den Ansatz aus dem Konferenzbeitrag beinhalten, wobei ich zuerst ein Überblick geben werde. Dann werde ich ein Beispiel aus dem Bereich des automatisierten Fahrens vorstellen, die Anforderungen der Architektur nennen, das Optimierungsproblem definieren, anhand der optimalen Lösung durchgeführte Simulationsexperimente darstellen und ein Fazit daraus ziehen.
Automobilindustrie im Wandel & Autonomie
Automobilindustrie im Wandel
Die Automobilindustrie hat sich in den letzten Jahrzehnten so geändert, dass effiziente Vorgehensweisen bei der Entwicklung unverzichtbar wurden. Dabei spielen die Sicherheit der Fahrer und die funktionale Sicherheit des ganzen Systems eine wichtige Rolle. Im Folgenden werde ich diese Änderungen in die 3 wichtigsten Bereiche unterteilen.
Autonomie
Der 1. Bereich ist die Autonomie. Seit 2014 sind die Stufen der Fahrautomatisierung in der internationalen Norm SAE J3016 definiert. Auf Stufe 3 und 4 übernimmt das System nur dann die Fahraufgabe, wenn das aktuelle Szenario dafür geeignet ist. Im Gegensatz zu Stufe 3 sendet das System in Stufe 4 in diesen Szenarien keine Aufforderung an den Fahrer, das System zu übernehmen. Die höchste Stufe dieser Norm definiert das vollautomatisierte Fahren. Hier kann das System jede Herausforderung bezüglich der Fahrbahn und der Umgebung autonom bewältigen, vorausgesetzt der Mensch kann das auch.
Künstliche Intelligenz & Vernetzung
Künstliche Intelligenz
- Ist der wichtigste Faktor für die Autonomie
- Tritt bspw. ein Fußgänger an einem Zebrastreifen auf die Straße, muss das Auto mit seiner künstlichen Intelligenz sofort – am besten schon vorher – erkennen, dass der Fußgänger die Straße überqueren will.
- Doch auch in herkömmlichen, also nicht selbstfahrenden Autos, kommt künstliche Intelligenz heute schon zum Einsatz. Das Auto kann sich z.B. merken, an welchem Tag zu welcher Uhrzeit ein Autofahrer eine bestimmte Person anruft oder einen bestimmten Weg fährt. Es schlägt dem Fahrer dann die Telefonnummer oder die Strecke vor.
- Auch eine natürliche Spracherkennung für die Infotainment-Steuerung sowie die Bilderkennung für den Verkehrszeichenassistenten basieren auf KI.
- Das sind nur ein paar Anwendungsbeispiele.
Vernetzung
Sollen Fahrzeuge autonom fahren, müssen sie miteinander und mit der Umgebung kommunizieren. Das führt uns zu der Vernetzung des Autos. Dabei steht die Car-to-X Kommunikation im Mittelpunkt. Car-to-X bezeichnet die Kommunikation von Fahrzeugen untereinander und mit der Verkehrsinfrastruktur. Ein Vorteil ist z.B. die Unfallvermeidung.
SOA > SOA-Dreieck
Serviceorientierte Architekturen
SOA-Dreieck
- Wie der Name schon sagt, stehen bei serviceorientierten Architekturen die Dienste im Mittelpunkt. Die Zuordnung von Diensten zu deren Spezifikationen wird über ein Dienstverzeichnis organisiert. Die tatsächliche Bindung zwischen den Softwareelementen Dienstnutzer und Dienstanbieter erfolgt zur Ausführungszeit der Programmlogik des Dienstnutzers durch die dynamische Zuordnung zwischen den geforderten und den angebotenen Eigenschaften von Diensten, die im Dienstverzeichnis registriert sind.
- Es besteht demnach keine feste Kopplungsbeziehung zwischen Dienstnutzer und Dienstanbieter, da die Kopplung beider Elemente abhängig von einem Vergleich geforderter und angebotener Eigenschaften ist.
Signalbasiert > Serviceorientiert
Von Signalbasiert zu Serviceorientiert
- Die traditionellen Automobil-Kommunikationen funktionieren immer noch nach dem signalbasierten Ansatz. Angenommen zwei Anwendungen wollen interagieren. Hier müssen Ingenieure logische Signale manuell in Protokolldateneinheiten gruppieren, die wiederum CAN-Nachrichten zugeordnet sind. Dies ist ein zeitaufwändiger und fehleranfälliger Prozess, der auch die Dynamik und damit die Neukonfiguration der Netzwerktopologie zur Laufzeit beeinträchtigt.
- Bei einem serviceorientierten Ansatz muss nur das Interaktionsmuster definiert werden. Der Rest wird automatisch erledigt.
- Es wird zwischen zwei Interaktionsmustern unterschieden: (1) das Request/Response-Verfahren. Der Client sendet eine Anforderung an den Server, der wiederum auf den Client antwortet. Auf diese Weise wird ein Methodenaufruf realisiert; und (2) das Publish/Subscribe-Verfahren. Der Server veröffentlicht zunächst einen Dienst in der Registry, den der Client finden kann. Der Client abonniert dann den Dienst und wird entweder regelmäßig benachrichtigt oder durch eine Änderung auf der Serverseite.
SOA-basierter Ansatz
SOA-basierter Ansatz
- Im Folgenden möchte ich den am Anfang angekündigten Ansatz aus dem Konferenzbeitrag vorstellen.
- Dieser Ansatz zielt auf eine frühzeitige Analyse der Hardwareressourcen und die Synthese von SOA-basierten Automobilsoftwarearchitekturen ab. Der Ansatz besteht aus den folgenden Teilen:
(1) Der erste Teil beschreibt ein Metamodell, das zur Formalisierung von Automobildienstleistungen als Hauptbausteine einer serviceorientierten Architektur verwendet wird.
(2) Im zweiten Teil wird eine automatisierte Design Space Exploration (DSE) für die Zuweisung von Computerressourcen durch Dienste aus verschiedenen Automobilbereichen erörtert.
(3) Schließlich wird die Timing-Eigenschaft der Architektur mit Simulationsexperimenten getestet.
Umgebungsmodell (Diagramm)
Umgebungsmodell
Im Mittelpunkt der SOA stehen also die Dienste. Die Dienste bieten Funktionen über die Dienstschnittstelle an, die von Clients verbraucht werden können. Die Dienstschnittstelle wird als periodisches Benachrichtigungsereignis instanziiert. Bei einem periodischen Benachrichtigungsereignis wird das Timing als eine Zeitperiode betrachtet, in dem der Client eine Mindestanzahl von Ereignissen abrufen muss. Die für die Dienstschnittstelle relevanten Daten, die anschließend dem Client bereitgestellt werden sollen, werden in einer Struct verschachtelt.
Umgebungsmodell (Beispiel)
- Die Dienstschnittstelle wird anhand eines Beispiels aus dem Bereich des automatisierten Fahrens veranschaulicht. Angenommen wird, dass das Fahrzeug mit Hilfe von verschiedenen Sensoren Daten aus der Umgebung sammeln kann und diese dann vereint, um daraus ein Modell zu erstellen. Allgemein soll das Fahrzeug mehrere Hindernisse erkennen und die wichtigsten Informationen zu den Hindernissen zurückgeben. Die Hindernisse sind hier als 3D-Box dargestellt und pro Hindernis wird ein Tupel mit den folgenden Informationen zurückgegeben:
die Koordinaten des Box-Schwerpunkts, die Maße der Box, der Winkel um die z-Achse und der Typ des Hindernisses (Auto, Fußgänger, Radfahrer) - Hier sieht man einen Auszug aus einem Objektdiagramm des Umgebungsmodells. In diesem Beispiel empfängt der Client 3 Ereignisse pro Zeitperiode mit jeweils 30ms Dauer. Die gesammelten Informationen aus der Umgebung werden in einer Struct der Dienstschnittstelle verschachtelt. Rechts ist die Header-Datei für die Struct zu sehen.
Anforderungen von E/E-Architekturen
Anforderungen von E/E-Architekturen
- Die Modernisierung in der Automobilindustrie hat dazu geführt, dass die Anzahl der Anforderungen von E/E-Architekturen gestiegen sind. Das Ziel, eine möglichst hohe Stufe nach der Norm SAE J3016 zu erreichen, erhöht auch die Relevanz von Funktionen in den Bereichen Computer Vision und Maschinelles Lernen. Das bedeutet, dass die Soft- und Hardware immer auf dem neuesten Stand gehalten werden muss. Die Anforderungen von E/E-Architekturen werden in folgende Punkte unterteilt: (1) die Funktion , (2) die Sicherheit und (3) die Technologie.
- Die Funktionen an sich stellen besondere Rechenanforderungen an die Hardware. Um diese Anforderungen zu erfüllen wird eine zentralisierte Computerplattform verwendet, an die mehrere Steuergeräte angebunden sind. Die ECUs sind wiederum mit Sensoren, Kameras und weiteren Geräten verbunden, die z.B. den Abstand und die Geschwindigkeit messen. Die verarbeiteten Daten können entweder über eine Switch und eine Gateway an die Fahrdynamik-ECU weitergeleitet werden oder die Betätigung erfolgt über ein mit der Plattform verbundenen Sensor, das die Energie in Bewegung umwandelt. Die Fahrdynamik-ECU ist mit Geräten verbunden, die für das Beschleunigen, Bremsen und Lenken zuständig sind. Mit Hilfe der Kombination der Fahrdynamik-ECU mit den Sensoren, die direkt an die Plattform gebunden sind, soll das automatisierte Fahren realisiert werden.
Optimierung der Architektur > Logische Architektur
Optimierung der Architektur
- Bevor ich auf die Optimierung der Architektur eingehe, möchte ich die logische Architektur zeigen, die auf der Computerplattform bereitgestellt werden soll. Hier ist die vereinfachte logische Architektur für das automatisierte Fahren zu sehen. Es besteht aus mehreren Komponenten, die jeweils Daten liefern und verbrauchen. Die unterste Schicht besteht aus Funktionen, die die Umgebung mithilfe von Sensoren wie Lidar, Radar oder Kameras erfassen und darüber hinaus die Fahrzeugbewegung mithilfe von Aktuatoren zum Lenken und Beschleunigen beeinflussen. Sensorische Informationen sind die Datenbasis für das Umgebungsmodell in der zweiten Schicht. Auf dieser Schicht befindet sich auch die Fahrdynamik als Aktuator-Koordinationseinheit. Das Umgebungsmodell liefert Daten an die Trajektorienplanung auf der obersten Ebene. Hier werden Steueranforderungen berechnet, die schließlich von den Fahrdynamikfunktionen in seitliche und longitudinale Steueraktionen umgewandelt werden.
- Die logische Architektur wird in die Netzwerktopologie eingebunden. Das Umgebungsmodell wird zweimal bereitgestellt, eine nominelle und eine Fail-Operational-Instanz (FO). Das hat den Vorteil, dass bestimmte Funktionen im Fehlerfall, wenn z.B. eine Komponente ausfällt, weiterarbeiten.
Optimierung der Architektur > Pareto
- Im Gegensatz zu Einzelprozessorarchitekturen bieten Multi-Core-SoCs mehr Spielraum für die Implementierung. Das hat den Vorteil, mehrere Steuergeräte in einen einzigen SoC zu integrieren. Der Nachteil ist, dass dadurch der Entwurfsraum größer wird. Aus diesem Grund muss die Architektur optimiert werden. Es müssen jedoch mehrere Ziele gleichzeitig optimiert werden, was zu einem Optimierungsproblem mit mehreren Zielen führt, auch bekannt als Pareto-Optimierung. Neben Optimierungszielen müssen auch Einschränkungen berücksichtigt werden. Notwendige Einschränkungen verhindern, dass Lösungen Prozessoren überlasten, Speicherkapazitäten überschreiten oder Sicherheitsanforderungen ungültig machen. Die Pareto-Optimierung wird mathematisch wie folgt angegeben:
- f_1 (x),…,f_m (x) sind die Zielfunktionen, die minimiert werden sollen
- X ist der Entscheidungsraum mit den Entscheidungsvariablen x=(x_1,x_2,…,x_k ), die eine Lösung beschreiben.
- g_i und h_j sind die Einschränkungen, wobei 𝑔 die Ungleichheit und ℎ die Gleichheit beschreibt. Die Einschränkungen beziehen sich oft auf begrenzte Ressourcen, wie z.B. den Arbeitsspeicher. Die Variablen 𝑥, die diese Einschränkungen erfüllen, bilden zusammen den Entscheidungsraum. Jede dieser Variablen stellt im Koordinatensystem der Zielfunktionen einen Punkt dar. Anhand dieser Punkte kann festgestellt werden, welche die Restlichen dominiert.
- Es werden zwei Ziele betrachtet. Das Ziel 𝑓_1 ist das Minimieren der Anzahl verwendeter Kerne und 𝑓_2 das Minimieren der Anzahl verwendeter Kerne, die nach hohem ASIL-Level für Anwendungen qualifiziert sind, die nicht die höchsten Level erfordern. Oder anders gesagt: Es soll beim zweiten Ziel verhindert werden, dass nicht sicherheitskritische Softwarekomponenten auf Kernen mit einem hohen ASIL-Level bereitgestellt werden. ASIL ist ein Risikoklassifizierungsschema, das in der Norm ISO 26262 definiert ist.
Optimierung der Architektur > Softwarefunktionen
- Es werden insgesamt 25 Softwarefunktionen aus den Bereichen: Komfort (15), Infotainment (6) und automatisiertes Fahren (4) betrachtet.
- Jede Funktion hat einen spezifischen Ressourcenbedarf in Bezug auf (1) die Auslastung des Prozessorkerns, (2) den Flash-Speicher, (3) den flüchtigen Speicher und (4) die ASIL-Klassifizierung. In der Tabelle werden die Anzahl der Funktionen angegeben, die den Prozessor von 0-1000% auslasten, den Flash-Speicher und den RAM von 0-15000 Kibibyte verwenden und einen ASIL-Level von QM, B und D haben.
- Mit Hilfe einer Pareto-Optimierung erhält man ein Pfad im Koordinatensystem, das Pareto-Front genannt wird. Die Pareto-Front besteht aus allen Pareto-optimalen Entscheidungsvariablen. In diesem Fall wird die Pareto-Front mit 5 Kandidatenlösungen betrachtet. Auf der x-Achse befindet sich die Anzahl der Prozessorkerne und auf der y-Achse die Summe aller Strafen. Mit Strafen sind hier die Verstöße gegen die ASIL-Anforderungen gemeint. Für die effiziente Nutzung von Hardwarekomponenten ist es wichtig, dass so wenig wie möglich gegen die ASIL-Anforderungen verstoßen wird. Das bedeutet ein minimaler Wert für die Summe aller Strafen. Aus diesem Grund wird für die im weiteren Verlauf durchzuführenden Experimente der Kandidat mit 12 Prozessorkernen und einer Strafe von 8 ausgewählt.
Simulationsexperimente
Simulationsexperimente
- Für die Analyse des Netzwerk-Timings der entworfenen serviceorientierten Architektur werden basierend auf dem ausgewählten Kandidaten zwei Simulationsexperimente durchgeführt. Eine kurze Erinnerung an das Umgebungsmodell: Der Client muss in 30ms Zeitintervallen 3 Listen von Hindernissen erhalten.
- Bei dem ersten Experiment wird der Fail-Operational-Pfad im Falle eines Ausfalls nicht aktiviert. Aus diesem Grund ist nur die Kommunikation zwischen ECU 1 und ECU 2 wichtig. Das bedeutet, dass ECU 1 an ECU 2 über Switched-Ethernet die Daten schickt, die mit Hilfe den Sensoren gesammelt wurden. Das Ergebnis des ersten Experiments ist, dass die Timing-Anforderung für 500 Simulationsläufe erfüllt wird.
- Bei dem zweiten Experiment wird im Falle eines Ausfalls der Fail-Operational-Pfad aktiviert, sodass die Netzwerktopologie zur Laufzeit neu konfiguriert werden kann. Durch die Neukonfiguration der Netzwerktopologie kann der Client einen neuen und gleichzeitig die gleiche Funktion erfüllenden Dienst abonnieren. Der Client wechselt bei der Neukonfiguration von der nominellen Instanz des Umgebungsmodells zur Fail-Operational-Instanz. Das Problem ist, dass durch diesen Wechsel der Publish/Subscribe-Prozess ein zweites Mal durchgeführt werden muss, was eine zusätzliche Latenz bedeutet. Aus diesem Grund wird eine maximale Zeit von 130ms festgelegt. Das Ergebnis des zweiten Experiments ist, dass in 498 von 500 Simulationsläufen die Neukonfiguration die Timing-Anforderung erfüllt, wobei sich 21 von den erfolgreichen 498 Läufen im kritischen Bereich von 117ms bis 130ms befinden.
- Insgesamt lässt sich festhalten, dass das Umgebungsmodell ohne die Fail-Operational-Instanz die Timing-Anforderungen erfüllt. Betrachtet man außerdem noch die Neukonfiguration zur Laufzeit, dann befinden sich einige Simulationsläufe an der Grenze der Timing-Anforderung.
Fazit & Ende
Fazit
- Das Ziel der Autoren war es, zu testen, ob eine serviceorientierte Architektur durch die Verwendung eines modellbasierten Ansatzes mit den in der Automobilindustrie bekannten Tools und Techniken auf einer zukünftigen E/E-Architektur bereitgestellt werden kann. Im Allgemeinen sollte das Ziel durch eine Analyse und anschließende Synthese der Ressourcen unter Berücksichtigung der Zeit-, Funktions- und Sicherheitsanforderungen erreicht werden. Der Bedarf an der Optimierung mehrerer Ziele hat zu der Definition der Pareto-Optimierung geführt. Nach der Bestimmung der Pareto-optimalen Lösung unter Berücksichtigung der Einschränkungen bezüglich der Prozessorüberlastung, Speicherkapazität und den Sicherheitsbedingungen konnte die Timing-Analyse durchgeführt werden. Mit den am Ende in jeweils zwei Schritten und 500 Simulationsläufen durchgeführten Simulationsexperimenten konnte gezeigt werden, dass zumindest für den Fall ohne einer Neukonfiguration zur Laufzeit die Timing-Anforderung des Umgebungsmodells zu 100% erfüllt wird. Das heißt, die Machbarkeit der Bereitstellung einer serviceorientierten Architektur auf einer E/E-Architektur der nächsten Generation wurde größtenteils nachgewiesen.
- Als Fazit zu serviceorientierten Architekturen lässt sich folgendes festhalten:
Sie fördern eine bessere Laufzeitentkopplung zwischen Software und Hardware als derzeit dominierende signalorientierte Architekturen. Außerdem werden Aktivitäten zur Entwurfszeit vereinfacht, da Kommunikationsabhängigkeiten zwischen verteilten Softwareanwendungen nicht vordefiniert werden müssen. Eine weitere Herausforderung ist die Bereitstellung einer SOA auf Computerplattformen, die mit Hilfe einer zentralen Plattform bewältigt werden kann.
Ende
Damit bin ich am Ende meines Vortrags. Vielen Dank für Ihre Aufmerksamkeit! Ich bin gerne bereit, Fragen zu beantworten.
