Die Branche steht vor einem Umbruch. Einige Top-Manager sprechen sogar von der Neuerfindung des Automobils. Drei Großprojekte sind die Treiber: Die Transformation zur Elektromobilität, die Vernetzung moderner Fahrzeuge im Internet of Things (IoT) sowie das automatisierte Fahren. Jedes dieser Projekte wird von tiefgreifenden Umbrüchen begleitet; eine komplette Neuordnung der Wertschöpfungsketten steht an.
Neuordnung ist in diesen unruhigen Zeiten ein Leitmotiv. Zur Umsetzung der Großprojekte bedarf es technischer Neuordnung, ein Blick auf E/E-Architekturen verdeutlicht es: Über 120 hoch spezialisierte Steuergeräte (ECUs) sind in Oberklassefahrzeugen dezentral verbaut. Der Umfang an Software schwillt unaufhörlich an. Über 100 Millionen Lines of Code sind es bereits – hundert Mal mehr als im Space Shuttle und über viermal so viel wie in einer Boeing 787. Und das ist erst der Anfang.
Vehicle Computer als zentrale Knotenpunkte
Mit den hochkomplexen dezentralisierten Architekturen stößt das automatisierte Fahren ebenso wie die IoT-Vernetzung mit Cloud-Anbindung und umfassendem Schutz vor Cyberkriminellen an Grenzen. Klarere, möglichst zentralisierte Strukturen sind gefragt. Zugleich muss die Rechenleistung zunehmen, denn während klassische ECU-Software einen Umfang von etwa 8 MByte hat, werden es schon bald mehr als 80 GByte sein – ein Anstieg um den Faktor 10.000. Die Sensorik autonomer Fahrzeuge sammelt stündlich Daten im hohen zweistelligen Terabyte-Bereich, aus denen es relevante Informationen zu filtern gilt.
Die Zahlen verdeutlichen: Ein „Weiter wie bisher“ kann es nicht geben. Es bedarf neuer, zentralisierter E/E-Architekturen. Darin wird es mit dem Vehicle Computer (VC) eine neue Schlüsselkomponente geben: Neue, zentrale Knotenpunkte mit enormem Potenzial. Um dieses Potenzial auszuschöpfen, begleitet ein neuer Standard die Einführung: Autosar Adaptive. Bei beiden Neuerungen lohnt genaues Hinsehen, denn sie werden die Steuergeräteentwicklung und die Wertschöpfung in diesem Bereich völlig verändern.
Exkurs: Der Status Quo
Steuergeräte auf Basis von Mikrocontrollern (µCs, MCUs) führen dezidierte Funktionen im Fahrzeug aus. Die Softwareentwicklung folgt standardisierten Entwicklungsprozessen, also dem V-Modell. OEMs legen die Funktionen, Allokation und Anbindungen der Steuergeräte im Fahrzeug fest, leiten ein ECU-spezifisches Softwaredesign daraus ab und überlassen die Umsetzung den Tier-1s. Diese nutzen Steuergeräteplattformen, die sie in Entwicklungsprojekten den Spezifikationen einzelner OEM anpassen. So entwickeln die Tier-1s die komplette Hard- und Software für MCU-basierte ECUs. ETAS steuert in diesem Prozess das Betriebssystem RTA-OS, die Basissoftware RTA-BSW und die Laufzeitumgebung RTA-RTE bei. Andere Fachbereiche entwickeln die jeweils domänenspezifische Anwendungssoftware.
Rasanter Umbruch mit Vehicle Computer und Autosar Adaptive
Dieser etablierte Ablauf ändert sich mit Einführung der Vehicle Computer rasant – und grundlegend. VCs kommen zwar zusätzlich zu Deeply-Embedded-ECUs auf µC-Basis zum Einsatz, doch sie ändern die Basis: MCU- und SoC-Hardwarearchitekturen mit mehreren Kernen in der CPU sowie Coprozessoren halten Einzug. Anders als klassische ECUs, die in klar determinierten Zyklen Regelungsalgorithmen ausführen, können VCs komplexe Rechenoperationen durchführen. Genügten bisher für die Echtzeit-Signalverarbeitung klassischer ECUs die Anbindung über CAN-, LIN- oder Flexray-Busse, so wird künftig die Verarbeitung von viel mehr Daten über Ethernet inklusive Zugriffen auf externe Speicher, File-Systeme und teils auch auf Cloud-Services gefragt sein. Im Klartext heißt das neue Kommunikationswege und neue Betriebssysteme. Hinzu kommt, dass Vehicle Computer nicht mehr im engeren Sinne echtzeitfähig sind. Zwar rechnen sie oft schneller als bisherige MCU-basierte ECUs, doch ist der deterministische Ablauf nicht mehr garantiert.
Schon die wenigen genannten Unterschiede verdeutlichen, wie Vehicle Computer die E/E-Architekturen verändern werden. Um der Veränderung klare Richtlinien zu Grunde zu legen, erarbeitet die Branche mit Hochdruck den Autosar-Adaptive-Standard. Kurz gefasst geht es um einen Rahmen dafür, dass auf VCs Software verschiedener Automotive Safety Integrity Level (ASIL) laufen kann. Und es geht darum, diese Software wie bei PC und Smartphone nachträglich installieren und over-the-air (OTA) aktualisieren zu können. Das setzt eine weitere grundlegende Neuordnung voraus: Statt der V-Modelle sind neue agile Entwicklungsabläufe gefragt – Prozessverbesserungs-Ansätze, wie DevOps, in denen Softwareentwicklung und Betrieb parallel laufen, weil es im vernetzten Umfeld ohnehin ständiger Verbesserungen und Aktualisierungen bedarf. Schon allein, um vernetzte Fahrzeuge gegen veränderliche Bedrohungen zu schützen.
Zugleich eröffnen sich Chancen für neue Geschäftsmodelle. App-Stores für Fahrzeugsoftware können entstehen. Auf Vehicle-Computern dürfte schon bald Software von Dutzenden Anbietern laufen. Davon werden typische Automotive-Player (OEM, Tier-1 und andere Zulieferer) nur noch Anteile umsetzen. Das Gros werden neue, auch branchenfremde Partner zuliefern. Doch wo der Software-Umfang um das 10.000-Fache zunimmt, würde auch ein Zehntel des Kuchens für etablierte Automotive-Player auf einen Anstieg um Faktor 1000 hinauslaufen – wenn es ihnen denn gelingt, sich organisatorisch umzustellen und ihr Mindset der neuen Prozesswelt anzupassen. Wo OEMs Steuergerätehardware und Software separat einkaufen, brauchen Zulieferer Geschäftseinheiten für reine Softwareentwicklung, -vermarktung und -vertrieb. Komplettes Neuland – ohne Fertigungsinfrastruktur, dafür aber mit neuen Wettbewerbern aus der IT-Branche, die im Umgang mit Plattformen geballte Erfahrung mitbringen.
Neue Betriebssysteme, Laufzeitumgebungen und Entwicklungsplattformen
Bosch und ETAS haben früh erkannt, welche Wucht der Wandel entfalten wird und wie wichtig es für Akteure aus dem Automotive-Umfeld wird, sich schnell und konkret darauf einzustellen. Rund um die VC-Hardware haben sie daher ein neues Entwicklungsumfeld auf Basis des Autosar-Adaptive-Standards geschaffen.
Herzstück ist das Basissoftware-Framework RTA-VRTE. Das Kürzel steht für Realtime Application – Vehicle Runtime Environment und bezeichnet eine Multi-Layer-Plattform, auf der die Softwarefunktionen aufsetzen (Bild 1). Es integriert sowohl bewährte Autosar-Classic-Abläufe als auch Autosar-Adaptive-konforme Prozesse.
Ebenso wichtig ist die vorkonfigurierte Partitionierung per Hypervisor. Jede Partition entspricht einer Virtual Machine (VM), auf der eine überschaubare Menge an Softwarefunktionen läuft. Das entschärft einerseits die Komplexität. Andererseits können Anbieter unabhängig voneinander Software entwickeln, ohne auf andere Softwarekomponenten achten zu müssen (Freedom from Interference). Nur so ist verteilte Entwicklung wirtschaftlich möglich. Damit bietet das VRTE das nötige Fundament, um Software verschiedener ASIL-Kategorien von unterschiedlichen Anbietern auf Vehicle Computern zu integrieren und sicher zu betreiben.
Frühstarter können sich parallel zum Standardisierungsprozess im Early-Access-Programm mit den neuen Architekturen vertraut machen, sich in die veränderten Entwicklungsabläufe einarbeiten und lernen, den neuen Methodenbaukasten effizient zu nutzen (Bild 2). Neben einem Ready-to-go-SDK (Software Development Kit) gehören auch Beratung und Trainings zum Programm.
Der Entwicklungsprozess folgt einer hochgradig virtualisierten Methodik. Diese stellt ETAS mit der RTA-VRTE schon jetzt bereit. Die Virtual Machines übernehmen in der RTA-VRTE die Funktion virtueller ECUs, die Entwickler auf herkömmlichen Desktop-PCs simulieren können. Sie sind per Ethernet vernetzt und können damit auch untereinander kommunizieren.
Letztlich liefert ETAS Nutzern ein komplettes Virtualbox-Abbild des Vehicle-Computers mit einer aus fünf Ebenen/Layern aufgebauten Autosar-Adaptive-Architektur. Bei Virtualbox handelt es sich um eine Virtualisierungslösung für PCs von Oracle, über die Entwickler unkomplizierten Zugang zu der komplett virtualisierten Entwicklungsumgebung erhalten.
Um das effizient umzusetzen, enthält das SDK Konfigurationswerkzeuge für die Integration POSIX-konformer Betriebssysteme wie Linux oder Blackberry QNX. Ihre Subsysteme laufen auf den VMs wie auf einem eigenen Computer. Die Kontrolle der Interaktion findet auf einem anderen Layer statt. Dort gewährleistet eine Kommunikations-Middleware, dass bei Problemen einer Softwarefunktion keinerlei ungewollte Rückwirkung auf ASIL-relevante Funktionen auftreten. Die Middleware ist Bestandteil des Early Access Program. Anwender können sofort ins Prototyping einsteigen, die Architektur durchdringen und Software integrieren, erproben sowie debuggen. Auch lassen sich (noch) nicht Autosar-Adaptive-konforme Softwarelösungen integrieren, etwa Firewalls oder Gateway-Management-Lösungen.
Sauber aufgesetzte Softwareintegration gemäß Autosar Adaptive
RTA-VRTE hilft Entwicklern, die komplexe Software-Integration auf VC sauber auf- und umzusetzen. Bei Funktionen mit hoher ASIL-Relevanz werden Mikrocontroller aufgrund ihrer Vorteile bei strengen Echtzeit-Anforderungen und bei der Überwachung der Kommunikationsabläufe auch künftig das Mittel der Wahl bleiben. Safety bleibt also in vielen Fällen in ihrer Autosar-Classic-basierten MCU-Heimat.
Eckdaten
Die Layer-Struktur der RTA-VRTE deckt die ganze Vielfalt der Funktionen und Anwendungen im Fahrzeug ab – ob automatisiertes Fahren, Chassis-Kontrolle, Infotainment oder vernetzte Security-Services. RTA-VRTE liefert damit schon jetzt das Fundament, auf dem die Anwendungen in künftigen Entwicklungsprozessen aufsetzen werden. Das ermöglicht es OEMs und Zulieferern, sich parallel zur Autosar-Adaptive-Standardisierung in die neuen Entwicklungsabläufe einzuarbeiten sowie das enorme Potenzial Vehicle-Computer-basierter E/E-Architekturen zu ergründen und in wirtschaftliche Erfolge umzumünzen, sobald deren Roll-out beginnt. Das setzt umfassende Kompetenzen voraus, denn schon in naher Zukunft werden Fahrzeuge zu mobilen Internet-Devices, deren Software ungekannte Komplexität aufweisen wird. Bei 100 Millionen Lines of Code wird es ganz sicher nicht bleiben.
Neben den MCU-Cores übernehmen Mikroprozessor-Kerne die rechenintensiven Funktionen. Die Middleware sichert das Zusammenspiel ab und sorgt für die Freedom from Interference. Das setzt sauber geplante und durchgeführte Kommunikation zwischen den Virtual Machines (VM) voraus. Jede VM wird zudem sichere OTA-Updates unterstützen. Letztlich bilden µC-, µP- und leistungsfähige Grafikkarten aus dem ADAS-Umfeld die Hardware-Basis. Losgelöst davon wird die Entwicklung der Anwendungssoftware parallel bei verschiedenen Anbietern erfolgen (Bild 3).
Dafür bietet RTA-VRTE einen Hardware-Abstraction-Layer, der im Entwicklungsprozess ebenso stringent genutzt werden sollte wie ein weiterer Layer zur Abstraktion des jeweiligen POSIX-Betriebssystems. Auf den virtualisierten Basis-Layern setzt auf einer dritten Ebene besagte Middleware auf. Diese regelt die Kommunikation zwischen unterschiedlichen Protokollen an Bord (CAN, LIN, Flexray, Ethernet etc.), und sie hebt die darüber übermittelten Signale auf eine service-orientierte Ebene an. Sie wandeln also Daten in semantische Informationen – ähnlich wie moderne Telefone keine Nummerneingabe mehr verlangen, sondern auf gesprochene Namen reagieren und dann automatisch das passende Übertragungsprotokoll nutzen, das im Gespräch unbemerkt von LTE zu G3 oder G4 wechseln kann. Solche Vermittlung wird in künftigen Fahrzeug-Architekturen mit verteilten ECUs und Vehicle Computern immens wichtig, denn nur so ist es umsetzbar, dass beispielsweise Fahrerassistenzsysteme (ADAS) stets schnellstmöglich auf aktuelle Fahrzeug- oder Umfeld-Informationen zugreifen können. Solange die Information exakt und aktuell ist, ist der Ursprung ebenso unerheblich wie der genutzte Kommunikations-Bus. Auf die Flexibilität kommt es an!
Als vierten und fünften Layer bietet die VRTE die Abbildung ECU-spezifischer Grundfunktionen – etwa Diagnose oder Security-Funktionen und neue Fahrzeugservices. Dazu zählen Zwischenspeicher für OTA-Updates oder flottenübergreifende Security-Services wie die Angriffserkennung und Angriffsabwehr für Fahrzeuge von der ETAS-Tochter Escrypt.