Serviceorientierte E/E-Architektur mit der Innovationsplattform HARRI
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
TITELTHEMA Automatisiertes Fahren
Serviceorientierte
E/E-Architektur mit der
Innovationsplattform HARRI
Serviceorientierte Kommunikation ist ein Thema, das die Automobilbranche stark beschäftigt.
Immer mehr E/E-Architekturen, die diese Konzepte anwenden, werden von Automobilherstellern,
Systemlieferanten oder Technologiefirmen vorgestellt. Jedoch ergeben sich damit auch Risiken
und Grenzen, die es zu untersuchen gilt. Mit der Innovationsplattform HARRI stellt Bertrandt
eine eigene Lösung für zukünftige Fahrzeug-E/E-Architekturen vor.
© Bertrandt
26
AUTOREN STATUS QUO
Die aktuellen technologischen Heraus
forderungen der Automobilindustrie
stellen neue Anforderungen an zu ver
arbeitenden Datenmengen sowie an
Geschwindigkeiten des Datentransports.
Dipl.-Ing. Cornelius Butzkamm Die Einführung von Automotive Ether
ist Teamleiter Architektur und net bietet einen Lösungsansatz, der neue
Vernetzung bei Bertrandt Möglichkeiten bezüglich Geschwindig
in Ingolstadt.
keit und Datenmenge mit sich bringt und
zusätzliche Chancen bietet, den Informa
tionsaustausch konzeptionell neu zu
gestalten. Ein weiterer aktueller Trend
zeigt sich in der Einführung von E/E-
Architekturen mit hochperformanten
Domain-Controllern. Durch die techno
Konstantin Brand, M. Sc.
logischen Neuerungen werden vermehrt
ist Spezialist für Automotive
Ethernet und SOA bei serviceorientierte Kommunikationskon
Bertrandt in Ingolstadt. zepte auf Ethernet-basierten Netzwerk
strukturen eingesetzt. Ein Protokoll,
das serviceorientierte Kommunikation
gewährt, ist das SOME/IP-Protokoll
(Scalable Oriented MiddlewarE over IP).
Dabei handelt es sich um ein Remote
Procedure Call (RPC) Protocol, das nach
den Bedürfnissen der Automobilindus
trie entwickelt wurde [1].
FÜR AUTONOMES, VERNETZTES
UND ELEKTRIFIZIERTES FAHREN
Bertrandt entwickelt Lösungen für künf
tige technologische Fragestellungen der
automobilen Welt entlang der gesamten
Wertschöpfungskette und beschäftigt
sich dabei mit den aktuellen Trendthe
men Digitalisierung, autonomes Fahren,
Vernetzung und Elektromobilität. Die
technischen Lösungen dafür wurden auf
der Innovationsplattform HARRI zusa
mengefasst. Bei dem Projekt wurden
sowohl Ansätze der agilen Entwicklung
als auch von SPICE vereint und so eine
User Experience auf Basis von psycholo
gischen und technischen Ansätzen bis
hin zur intuitiven Kommunikation zwi
schen Mensch und Maschine mit einem
benutzerfreundlichen Interface (HMI)
geschaffen. Die Datenverarbeitung im
und außerhalb des Fahrzeugs ist Grund
voraussetzung für eine erfolgreiche Digi
talisierung und Vernetzung. Der Show
case demonstriert Themen wie eine
solide Backend-Struktur, schnelle Erken
nung und Verarbeitung von gesammel
ten Daten und Car-2-X-Kommunikation.
Um die technischen Schwerpunkte
rund um die oben genannten Trendthe
men realisieren zu können, wurde eine
ATZ elektronik 03|2020 15. Jahrgang 27
TITELTHEMA Automatisiertes Fahren
BILD 1 Fahrzeugseitige Systemarchitektur
Debug-
Schnittstelle
Automotive Switch von HARRI mit den einzelnen Domänen und
deren Subkomponenten (© Bertrandt)
EDC ADC HDC CDC
Debug-
Schnittstelle
Antenne 1
BMS Winkel- Bremse Eye-Tracker
100 V sensor ABS IMU links Antenne 2
US-Steuergerät
Eye-Tracker
LE Lenkung GPS 1 Debug-
rechts
Schnittstelle
Debug- Display links
OBC Joystick Sitzerkennung GPS 2 Schnittstelle Lidar-Switch Diagnose Audio
US-Sensor 1 Kamera 1
Start / Stopp Display rechts
BMS 48 V Diagnose USB US-Sensor 2 Kamera 2 AD-Wandler
Lidar 1
US-Sensor 3 Kamera 3
Lidar 2
Mikro links
BDC Lidar 3
ESC
Lidar 4 Mikro rechts
Lidar 5 Display Front
US-Sensor 15 Kamera 11
Rücklicht
Sitzerkennung US-Sensor 16 Kamera 12 Display Back
Blinker links
360°-Lauflicht
Start / Stopp
Blinker rechts
Debug-
Schnittstelle Surface
neue E/E-Architektur mit fünf Domain- Fahrzeug, hat sich herausgestellt, dass realisieren, werden sogenannte hoch
Controllern implementiert, bei der auf es unterschiedliche Interpretationsmög integrative Steuergeräte konzipiert, auf
Interdomain-Ebene mittels 100BASE-T1 lichkeiten und Vorteile der einzelnen denen mehrere virtuelle Steuergeräte
[2] mit SOME/IP kommuniziert wird. Ansätze gibt. Im Folgenden werden realisiert werden. Die serviceorientierte
Mit HARRI wurde somit ein Ansatz diese verschiedene Ansätze sowie Architektur (SOA) dient dabei dazu, die
einer clusterbasierten, serviceorientierten die Besonderheiten gegenübergestellt. Software dieser Steuergeräte modular
Domain-Rechnerarchitektur umgesetzt. Um die bestmögliche Lösung zur Inte und erweiterbar zu gestalten. Die defi
Die Domains wurden wie folgt aufgeteilt: gration in den Showcase zu erhalten, nierten Services tauschen Informatio
Der Autonomous-Drive-Domain-Control hat sich das zuständige Team ausführ nen direkt untereinander aus (Software-
ler (ADC) vereint in seiner Subdomain lich mit den verschiedenen Ansätzen Parameterübergabe). Diese virtuellen
vor allem Sensorik zur Umfelderken beschäftigt, BILD 2. Signale sind nicht auf einem physikali
nung (Lidar, Kamera, Ultraschall). In der schen Medium messbar, was in einem
Subdomain des Electric-Vehicle-Domain- fortgeschrittenen Integrationsstadium
ZENTRALISIERTER ANSATZ
Controllers (EDC) befinden sich Aktu zu Herausforderungen führen kann.
atorik/Regelkreise zum Bewegen eines In zentralisierten Architekturen werden Zudem zeigt sich, dass in diesem Ansatz
Elektrofahrzeugs (X-by-Wire-Anwen alle Informationen in einer zentralen Services voneinander abhängen und
dungen). Unterhalb des HMI-Domain- Stelle zusammengeführt. Um dies zu unter Umständen sogenannte Deadlocks
Controllers (HDC) wurde ein HMI-Kon
zept für autonom fahrende Fahrzeuge
umgesetzt (Displays, Sprachdialogsys
tem). Der Connectivity-Domain-Control
ler (CDC) ist für die Kommunikation
zwischen Fahrzeug und Backend mit BILD 2 Bei HARRI wurde ein dezentraler
weiteren Frontend-Anwendungen verant Ansatz mit einer Domain-Struktur
wortlich. In der Body-Domain-Controller- umgesetzt (© Bertrandt)
Subdomain (BDC) wurden Sitzplatzbele
gungen und Lichtfunktionen umgesetzt,
BILD 1.
VERSCHIEDENE
ARCHITEKTURKONZEPTE
Aufgrund verschiedener Veröffentli
chungen, Präsentationen und Fachdis
kussionen, bezogen auf serviceorien
tierte Kommunikationskonzepte im
28
mit sich bringen. Vorteil von virtuellen es konkrete Aufgabenfelder, die in Themengebiet handeln kann. Damit das
Steuergeräten, die über Services mit logische Domains mit einem leistungs möglich ist, wurde die clusterbasierte
einander kommunizieren, ist unter starken Domain-Controller unterglie Domain-Architektur gewählt, das heißt
anderem eine sehr kurze Latenzzeit dert sind. In deren Subdomain befin eine Domain hat direkten Zugriff auf alle
des Datenaustausches. den sich alle notwendigen Peripherie für sie relevanten Informationen und
geräte, die zur Umsetzung der Services kann ihre Themen eigenständig bear
dienen. Dies hat den Vorteil, dass jede beiten. Der direkte Zugriff wird zum
DEZENTRALISIERTER ANSATZ
Domain autark arbeiten kann. Herun Beispiel durch klassische Bussysteme
MIT LOAD BALANCING
tergebrochen auf den Nutzdateninhalt (CAN, LIN) realisiert. Mit dem Service
Dezentralisiertes Load Balancing ist ein der Ethernet-Frames werden bei die können die realisierten Funktionen im
Ansatz, bei dem Steuergeräte mit einem sem Ansatz Nutzdaten im klassischen Fahrzeug zur Verfügung gestellt werden.
leistungsstarken Backbone verbunden Sinne der Fahrzeugkommunikation Um dies realisieren zu können, musste
sind. Zu Beginn startet jedes Steuergerät über das physikalische Medium trans allerdings die Gewohnheit, Funktionen
mit vordefinierten Services. Befindet portiert, die somit erfassbar und auch ganzheitlich zu planen, aufgegeben
sich das Steuergerät in einem bestimm interpretierbar sind. werden. Daher wurde die Philosophie
ten Leistungsschwellwert, kann es über etabliert, dass jeder Service eine Auf
ein Handover-Konzept Services zu einem gabe, beispielsweise von A-N erfüllt.
PHILOSOPHIE DER
anderen Steuergerät mit freien Rechen Durch die Serviceschnittstelle kann
SO -ARCHITEKTUR
kapazitäten übergeben. Ein Service er diese von anderen aufgenommen und
möglicht somit, dass eine Berechnungs Bei der Umsetzung von HARRI wurde weiter genutzt werden, um eigene Funk
aufgabe am Ort A durch freie Rechen ein Service als Dienst verstanden, der tionen umzusetzen; beispielsweise von
kapazitäten am Ort B berechnet wird. eine bestimmte Aufgabe erfüllt. Er ist M-Z. Als Beispiel ist bei HARRI der
Dadurch wird ein dynamisches Nutzen eine einheitliche Schnittstelle, hinter ADC für das autonome Fahren (Objekt
freier Kapazitäten ermöglicht. Herunter der mehrere Applikationen verborgen erkennung, alternative Routenplanung,
gebrochen auf den Nutzdateninhalt der sind. Ein Service besteht daher aus vie Überholvorgang) verantwortlich, aber
Ethernet-Frames werden hier interne len kleineren Methoden, sogenannten nicht für deren Umsetzung. Der Elec
Berechnungsgrößen und Rechendaten Remote Procedure Calls (RPC), an denen tric-Vehicle-Domain-Controller (EDC)
über das physikalische Medium trans sich andere Services bedienen können. kann den Service des autonomen Fah
portiert, die somit erfassbar, aber nicht Die Bedienung von RPCs entspricht rens abonnieren und die Information
interpretierbar sind. einem der Grundgedanken des Kom vom ADC erhalten. Was allerdings mit
munikationsprotokolls SOME/IP [3]. den Informationen geschieht, entschei
Die Service-Philosophie sieht vor, det der EDC. Dieser erhält zusätzliche
DEZENTRALISIERTER ANSATZ
dass ein Service es ermöglicht, eine Informationen von seiner Domain (Bat
MIT THEMENCLUSTERN
Aufgabe zu erledigen, von welcher der terieleistung, Status der Lenkung, ma
In einer dezentralen, clusterbasierten Nutzer nicht weiß, wie sie funktioniert. nueller Fahrwunsch) und verbindet
Architektur, wie sie bei der Innova Als Grundregel wurde dafür definiert, diese Informationen mit denen des
tionsplattform eingesetzt wurde, gibt dass ein Service eigenständig in einem ADCs. Der ADC übernimmt den DienstTITELTHEMA Automatisiertes Fahren
Bertrandt Industry Bertrandt Automotive
Cloud (BIC) Cloud (BAC)
Traffic Lights
LTE &
Automotive Switch Gateway Controller (ASG)
WLAN
100BASE-T1
SOME/IP, DoIP
Autonomous Drive Electric Vehicle HMI Body Connectivity
Domain Controller (ADC) Domain Controller (EDC) Domain Controller (HDC) Domain Controller (BDC) Domain Controller (CDC)
BILD 3 Über verschiedene Integrationsstufen von HARRI wurde das Prinzip der serviceorientierten Kommunikation stetig hinterfragt und weiterentwickelt
(© Bertrandt)
des „Sehens“, der EDC entscheidet, gemeinsamer Speicher verwendet, in meinverständlichen Umgang mit Ser
wie es am besten umzusetzen ist. Mit dem die Services Informationen teilen vices zu ermöglichen. Nach über zwei
hilfe von komplexen Datenstrukturen können. Der einfache Methodenaufruf Jahren Entwicklungsarbeit der Innovati
kann ein digitales Abbild einer Situa wird derzeit bewusst nicht benutzt. onsplattform HARRI hat Bertrandt eine
tion beziehungsweise eines Szenarios Außerdem werden innerhalb eines Fahrzeugarchitektur entwickelt, die auf
geschaffen werden, das von einem an Services keine weiteren Sub-Services einem zuverlässigen serviceorientierten
deren Teilnehmer aufgenommen und integriert. So ist es gelungen, die Kette Ansatz basiert. Es ist schwer vorherzu
interpretiert werden kann. von Abhängigkeiten der Services zu sagen, in welchen Bereichen sich ser
Die Umsetzung gemäß dieser Philo verringern. Eine weitere Besonderheit viceorientierte Kommunikationsansätze
sophie birgt weitere Vorteile: Durch der Innovationsplattform ist, dass alle durchsetzen und ob sich einer der oben
die einheitliche Schnittstelle müssen Services zwingend direkt über den beschriebenen Ansätze gegenüber ande
Informationen von der Applikation Ethernet-Bus kommunizieren. Damit ren Ansätzen absetzen wird. HARRI re
zum Service abstrahiert werden. Somit war es möglich, die einzelnen Domains präsentiert eine lauffähige, dynamisch
ist ein Austausch von Hardware- oder isoliert messtechnisch zu erfassen und erweiterbare und testfähige Umsetzung
Softwarekomponenten innerhalb der erfolgreich zu testen. Services in HARRI einer serviceorientierten E/E-Architektur
EDC-Subdomain möglich (leistungs können bewusst ein- und ausgeschaltet in einem fahrbaren Fahrzeug [4].
stärkere E-Maschine oder Lenkung), werden. Sind beispielsweise die oben
ohne einen Anpassungsaufwand auf erwähnten Fahrerassistenzsysteme LITERATURHINWEISE
Seiten des ADCs, BILD 3. vom Fahrer nicht gewünscht, so wird [1] Autosar SOME/IP protocol specifcation, http://
www.some-ip.com/papers.shtml, aufgerufen am
die Servicekommunikation nicht aufge 22.11.2019
baut und die Kommunikation auf dem [2] Metcalfe, B.; et al.: Automotive Ethernet – The
ABHÄNGIGKEITEN VON
Ethernet-Kanal deutlich reduziert. Es Definitive Guide. Intrepid Control Systems, 2014
SERVICES VERRINGERN [3] Matheus, K.;Königseder, T.: Automotive Ether-
konnten Buslasten um bis zu 40 % redu
net. Cambridge: Cambridge University Press, 2017
Bei der Entwicklung der Innovations ziert werden. Dies erlaubt ein situations [4] Schiekofer, P.: Aufbau eines Technologieträgers
plattform stellte Bertrandt fest, dass basiertes Ressourcenmanagement. für das autonome und elektrische Fahren. In: ATZ
jeder Fachbereich die Schnittstellen und 122 (2020), Nr. 3, S. 54-58
Methoden der Services beliebig definiert
AUSBLICK
hat. Als Folge gab es komplexe Service
abhängigkeiten, die zu Deadlocks führ Serviceorientierte Architekturen spielen
ten. Um diese Thematik zu beherrschen, in der Automobilindustrie eine immer
wurden die RPC kategorisiert. Events größere Rolle. Zudem werden immer
dienen der „klassischen Kommunika mehr hochintegrative Steuergeräte ent
tion“, wenn beispielsweise mehrere Ser wickelt. Eine Herausforderung besteht
READ THE ENGLISH E-MAGAZINE
vicemitglieder über Ereignisse informiert darin, Serviceschnittstellen einheitlich Test now for 30 days free of charge:
werden sollen. Felder werden als zu definieren, um somit einen allge www.ATZelectronics-worldwide.com
30Sie können auch lesen
