Im November 2020 hat die Entwicklungspartnerschaft AUTOSAR das neue Release R20–11 veröffentlicht und im Rahmen einer virtuellen AUTOSAR Open Conference der Öffentlichkeit vorgestellt.

Mit dem aktuellen Release unterstützt AUTOSAR die Entwickler mit neuen Features und Verbesserungen sowohl für die Classic- als auch für die Adaptive Plattform. Hierzu haben 295 AUTOSAR-Partner in 20 Arbeitsgruppen zusammengearbeitet und etwa 1800 Änderungsanfragen diskutiert.

Noch erfüllt AUTOSAR Classic als Standard-Middleware für die meisten Fahrzeugplattformen die gängigen Anforderungen an ein Echtzeitbetriebssystem und Funktionale Sicherheit – zumal AUTOSAR Classic über die Jahre kontinuierlich weiterentwickelt wurde und daher z. B. auch eine sichere Onboard-Kommunikation oder Schlüssel- und Zertifikatsmanagement bereitstellt. Im Hinblick auf hochautomatisiertes oder gar autonomes Fahren und V2X-Kommunikation werden jedoch Hochleistungscomputer bzw. Zonencontroller als zentrale Instanzen künftige E/E-Architekturen prägen. Solche Server-basierten Elektronikarchitekturen setzen sich in der gesamten Automobilindustrie bereits durch. Aktuelles Beispiel ist der In Car Application Server, den Continental zusammen mit Volkswagen entwickelt hat und der im VW ID.3 zum Einsatz kommt. Der Hochleistungsrechner, der künftig in über 20 Fahrzeugmodellen bei VW eingesetzt werden soll, verarbeitet etwa 30.000 Kommunikationsprotokolle, beinhaltet rund 20 Millionen Programmzeilen, die 70.000 Anforderungen abbilden und wurde von 19 verschiedenen Firmen entwickelt.

Dies verdeutlicht, dass in Zukunft wesentlich mehr, umfangreichere und unterschiedlichere Applikationen integriert werden müssen. Zudem stehen heute Aspekte wie Update- und Upgrade-Fähigkeit im Vordergrund. Vor allem mit dem steigenden Bedarf an Over-the-Air Updates für die gesamte Fahrzeugelektronik wird offensichtlich, dass es einen grundlegenden Wandel bedarf. Hier stößt der klassische AUTOSAR-Standard an seine Grenzen und wird deshalb nach und nach von AUTOSAR Adaptive als neuem zukunftsweisenden Regelwerk abgelöst. Im Gegensatz zu AUTOSAR Classic basiert Adaptive auf einem LINUX-verwandten Betriebssystem (POSIX). Zudem bietet sie eine per Hypervisor vorkonfigurierte Partitionierung, die es ermöglicht, von unterschiedlichen Anbietern unabhängig voneinander entwickelte Software-Komponenten verschiedener ASIL-Kategorien auf Vehicle Computern zu integrieren und sicher zu betreiben. Auf diese Weise können Anwendungen entwickelt werden, ohne dass im Voraus definiert werden muss, wie sie letztendlich auf die einzelnen ECUs verteilt werden. AUTOSAR Adaptive setzt somit den Rahmen für neue E/E-Architekturen. In intelligent vernetzten, hochautomatisierten Fahrzeugen werden dann leistungsfähige Computer und Zonencontroller das Kommando übernehmen.

Klaus Oertel ist Chefredakteur der Hanser automotive.

Editorial - Hauptartikel

Oertel, Klaus

Skalierbare Plattform  für ADAS-Funktionen

Um die Komplexität von ADAS-Funktionen zu beherrschen, setzen OEMs vermehrt auf Entwicklungseffizienz und Halbleiter-Plattformen, die in der Lage sind, das breite Spektrum der Anforderungen von NCAP-Grundfunktionen bis hin zum Level 2+ (Level 3 für Premiumsegment) abzudecken. Der vorliegende Beitrag von Renesas zeigt auf, wie Halbleiterhersteller ihr Angebot entsprechend an dieses neue Paradigma anpassen.

Im Automobilbereich wurden in den letzten Jahren bahnbrechende Technologien eingeführt, die in diesem Segment noch nie zuvor eingesetzt wurden, wie z. B. Deep Learning, Connected Vehicles und Big Data und haben die konventionellen Akteure der Automobilindustrie mit ihrem iterativen Ansatz unter Druck gesetzt.

Das Ziel vieler Hersteller bestand darin, als erster Anbieter ein autonomes Fahrzeug auf den Markt zu bringen. Doch die Realität sah ganz anders aus. Viele Anforderungen haben zu erheblichen Verzögerungen und zusätzlichen Ausgaben geführt, die über der ursprünglichen Schätzung lagen. Probleme bereiten den OEMs die Komplexität der Architektur aufgrund der sehr hohen Anzahl heterogener Sensoren in einem vollständig verteilten System; die Validierung eines solchen Systems mit fast unendlich vielen Anwendungsfällen und das Geschäftsmodell zwischen den verschiedenen Hardware- und Software-Anbietern. Dazu kamen noch rechtliche Hürden, die je nach Region unterschiedlich ausfielen und zum Teil sogar die Einführung von technisch verfügbaren Lösungen verzögerten.

 Neben der technischen Komplexität wurde die Entwicklung von automatisierten Autos noch durch andere Trends verzögert, wie z. B. der Elektrifizierung von Fahrzeugen aus Klimaschutzgründen oder erhöhter Safety-Anforderungen, die aufgrund von NCAP-Bewertungen und der Gesetzgebung vorangetrieben wurden. Der Hype um das autonome Fahren hat sich deshalb merklich abgekühlt, und Automobilhersteller sehen sich jetzt nach einem realistischeren Szenario für ein nachhaltiges Geschäft um.

Safety-Funktionen, die durch NCAP-Anforderungen und gesetzliche Regulierungen bestimmt werden, bleiben der wichtigste Markttreiber für Fahrerassistenzsysteme (ADAS). Darüber hinaus werden ADAS-Komfortfunktionen die Nachfrage vorantreiben, da sie erschwinglicher werden.

Der Trend zur Integration mehrerer Funktionen in eine zentralisierte Steuereinheit sieht erfolgversprechend aus, um die Anforderungen an die Skalierbarkeit zu erfüllen. Dieser Ansatz führt jedoch zu technischen Herausforderungen, wenn es darum geht, Anforderungen an die funktionale Sicherheit oder den Energieverbrauch zu gewährleisten. Zudem erfordert es ein neues Geschäftsmodell, da das herkömmliche Modell der Tier1s, Hardware und Software bereitzustellen, möglicherweise einige Änderungen erfordert. OEMs erwägen, Software selbst unternehmensintern zu entwickeln oder die Arbeit auf verschiedene Drittanbieter aufzuteilen.

Aus der Hardware-Perspektive besteht die Herausforderung darin, Halbleiterhersteller zu finden, die in der Lage sind, eine offene Plattform anzubieten. Diese sollte von der Einstiegs- bis zur Premiumklasse skalierbar sein und gleichzeitig Upgrade-Kompatibilität gewährleisten. Die Bausteine sollten ein hohes Leistungsniveau wie Consumer-ICs aus dem Mobilfunk-, PC- oder Gaming-Bereich bieten.

Aus Software-Perspektive werden die OEMs den besten Softwareanbieter für die dedizierten Funktionen auswählen und diese entweder von einem traditionellen Tier1 oder sogar von einem neuen Softwareanbieter beziehen. Die Möglichkeit, dass alle Softwareanbieter ihre eigene Software individuell entwickeln und mit vertretbarem Aufwand integrieren können, erfordert neue Entwicklungsmethoden und Software-Frameworks.

Die Halbleiterhersteller müssen ihr Angebot anpassen, um diesem neuen Paradigma zu begegnen. Die erste Herausforderung der Halbleiterindustrie besteht darin, eine Lösung vom untersten bis zum höchsten Level anbieten zu können und gleichzeitig die Wiederverwendbarkeit der Software zu gewährleisten. In der Tat konzentrieren sich die meisten Halbleiterhersteller auf Systeme der unteren bis mittleren Stufe, bei denen Systemkosten, niedriger Energieverbrauch, kritische Echtzeitaufgaben und funktionale Sicherheit die erforderlichen Schlüsselkompetenzen sind. Für die Automobilindustrie stellt dies heute den Bereich mit dem höchsten Volumen dar. Da die OEMs die Integration verschiedener Softwarekomponenten anstreben und nach Best-in-Class-Softwareanbietern suchen, ist die Notwendigkeit einer offenen Software-Plattform ein Muss. Der Black-Box-Ansatz, bei dem Hardware und Applikationssoftware gekoppelt werden, ist nicht geeignet, da er bestimmte Softwareanbieter ausschließt. Der Einsatz proprietärer Software erschwert zudem die Portierung von Algorithmen in eine optimierte Hardware-Plattform. Stattdessen werden offene Standards, wie z. B. Khronos oder SYCL bevorzugt, da sie die Unterstützung durch Drittanbieter ermöglichen. Auch die Tier1 lehnen diese Art von proprietärem Black-Box-Ansatz ab, da er es ihnen erschwert, eigenen Entwicklungsmehrwert zu schaffen.

Die ersten beiden Produkte der Renesas autonomy Plattform – das für NCAP-Funktionalität entwickelte R-Car V3M SoC und das R-Car V3H SoC für L2-Funktionen – bieten die Funktionalität, um den Herausforderungen des Marktes gerecht zu werden.

 Diese Plattform war anfänglich für Anwendungen mit hoher Rechenleistung wie In-Vehicle-Entertainment oder Infotainment konzipiert. Sie wird nun auf Bausteine erweitert, die in ADAS- und Fahrzeugservern zum Einsatz kommen.

Die Renesas autonomy Plattform (Bild 1) für ADAS und automatisiertes Fahren verbindet die Vorteile der RH850 MCU für Echtzeit und funktionale Sicherheit mit dem R-Car MPU/SoC für hohe Rechenleistung. Sie erfüllt sowohl die Bedürfnisse der OEMs als auch der Tier1s:

Erstens durch eine offene Architektur, die eine freie Wahl zwischen Kauf oder Eigenentwicklung bietet. Entscheidet sich ein Kunde für die Zusammenarbeit mit Partnern, erhält er über die offene Plattform die Möglichkeit, mit weltweit führenden Drittanbietern zusammenzuarbeiten.

Zweitens durch eine innovative, moderne Embedded-IP für z. B. Computer Vision und KI. Diese bietet die Wahl zwischen dem Verhältnis von Leistung und Flexibilität mit den erforderlichen IS026262-Zertifizierungen.

Drittens durch eine Plattform, die auf der Grundlage jahrzehntelanger Erfahrung für hohe Produktionsvolumen und Qualitätsansprüche entwickelt wurde, gepaart mit einer zuverlässigen Roadmap.

R-Car V3M und R-Car V3H sind die beiden ersten Produkte dieser Plattform. Sie befinden sich bereits in der Serienfertigung und kommen weltweit in Frontkamera-, Surroundview- und Lidar-Anwendungen zum Einsatz. R-Car V3M ist der Baustein, der die Einstiegs- und gesetzlichen Anforderungen von NCAP 2020 erfüllt. Er bietet zudem eine sehr kostengünstige Lösung für 3D-Surroundview-Systeme. Der R-Car V3H ist mehr auf die Premium-Features von Systemen zugeschnitten, die L2-Funktionen ermöglichen. Dieser Baustein eignet sich auch für Komfortfunktionen, wie die automatische Einparkhilfe, und wird in Lidar-Systemen eingesetzt. Beide R-Car-Bausteine unterstützen konventionelle Embedded-Computer-Vision-Algorithmen und KI für Embedded-Systeme.

Mit dem neuen R-Car V3U bietet Renesas nun auch ein System-on-Chip (SoC) für ADAS und automatisiertes Fahren nach ASIL D an. Mit 60 TOPS Deep Learning Processing bei geringer Stromaufnahme und bis zu 96.000 DMIPS ist der R-Car V3U für die Anforderungen an Performance, Safety sowie Auf- und Abwärtsskalierbarkeit von ADAS- und AD-Architekturen der nächsten Generation ausgelegt.

Dabei handelt es sich um das erste SoC, das auf der neuen R-Car-Architektur Gen 4 der offenen und flexiblen Renesas autonomy Plattform basiert. Mit dem R-Car V3U bietet die Plattform nun Skalierbarkeit von NCAP-Einstiegsanwendungen bis hin zu hochautomatisierten Fahrsystemen.

Der R-Car V3U bietet AI-Machine-Learning- und DNN-Funktionen (Deep Neural Network). Seine flexible Architektur ist in der Lage, alle modernen neuronalen Netze für die Hinderniserkennung und Klassifizierungsaufgaben im Fahrzeug zu verarbeiten, wofür 60 TOPS bei geringer Leistungsaufnahme und mittels Luftkühlung realisiert werden.

Außerdem bietet er eine breite Palette an programmierbaren Engines, einschließlich DSP für die Radarverarbeitung, Multi-Threading-Computer-Vision-Engine für traditionelle Computer-Vision-Algorithmen, Bildsignalverarbeitung zur Verbesserung der Bildqualität und zusätzliche Hardware-Beschleuniger für wichtige Algorithmen wie Dense Optical Flow, Stereo-Disparität und Objektklassifizierung.

Renesas bietet eine offene und integrierte Entwicklungsumgebung, mit der Kunden die Vorteile der integrierten Hardware der R-Car-Plattform sowie der geringen Leistungsaufnahme und der deterministischen Echtzeit-Software ausschöpfen können, um eine schnelle Markteinführung von Computer-Vision- und Deep-Learning-basierten Lösungen zu ermöglichen.

Einfach zu bedienende Debugging- und Tuning-Tools für die heterogene Multi-Core-Hardwarearchitektur ermöglichen eine effiziente Software-Entwicklung, während ein umfassendes Set an Beispielanwendungen und Online-Schulungsressourcen Entwicklern auf allen Ebenen einen schnellen Einstieg in den Entwicklungsprozess ermöglicht. Qualifizierte Compiler und Code-Generatoren für die Einhaltung von Cyber-Security- und funktionalen Sicherheitsanforderungen ermöglichen die Entwicklung sicherer Software.

Kunden können den R-Car V3U auch mit dem stromsparenden Mikrocontroller RH850, integrierten Power-Management-ICs und Power-Transistoren von Renesas kombinieren und so auf alle wichtigen Komponenten zugreifen, die sie für ihre ADAS- und AD-ECUs benötigen. Diese Kombination ermöglicht es ihnen außerdem, ihre Systeme effizient zu entwickeln und ihre Markteinführung zu beschleunigen. Muster des R-Car V3U SoC sind ab sofort verfügbar. Die Massenproduktion ist für das zweite Quartal 2023 geplant. (oe)

<a href="http://www.renesas.com/r-car-V3U">www.renesas.com/r-car-V3U</a>

<a href="http://www.renesas.com/RA">www.renesas.com/RA</a>

<a href="https://www.economist.com/leaders/2019/10/10/driverless-cars-are-stuck-in-a-jam">https://www.economist.com/leaders/2019/10/10/driverless-cars-are-stuck-in-a-jam</a>

<a href="https://www.forbes.com/sites/samabuelsamid/2020/04/28/ford-delays-commercial-automated-vehicle-launch-to-2022/#619a86cf7083">https://www.forbes.com/sites/samabuelsamid/2020/04/28/ford-delays-commercial-automated-vehicle-launch-to-2022/#619a86cf7083</a>

<a href="https://www.euroncap.com/en/ratings-rewards/driver-assistance-systems/">https://www.euroncap.com/en/ratings-rewards/driver-assistance-systems/</a>#?selectedMake=0&selectedMakeName=Select%20a%20make&selectedModel=0&selectedStar=&includeFullSafetyPackage=true&includeStandardSafetyPackage=true&selectedModelName=All&selectedProtocols=40302,34803&selectedClasses=1202,1199,1201,1196,1205,1203,1198,1179,40250,1197,1204,1180,34736&allClasses=true&allProtocols=false&allDriverAssistanceTechnologies=false&selectedDriverAssistanceTechnologies=1420,32977,1423,25341,1424,1421,6001&thirdRowFitment=false

<a href="https://abcnews.go.com/US/cars-us-now-required-backup-cameras/story?id=54854404">https://abcnews.go.com/US/cars-us-now-required-backup-cameras/story?id=54854404</a>

<a href="https://ec.europa.eu/commission/presscorner/detail/en/IP_19_1793">https://ec.europa.eu/commission/presscorner/detail/en/IP_19_1793</a>

Bild 1: Basierend auf seiner SoC- und MPU-Expertise im Consumer-Markt hat Renesas die R-Car-Automotive-Plattform entwickelt.

Bild 2: Roadmap der Renesas autonomy Plattform.

Eric Pinton ist Director des ADAS & Autonomous Systems Business Developments bei der Renesas Electronics Corporation.

Hauptartikel

Fahrerassistenzsysteme / Automatisiertes Fahren

Elektronik

Automotive

Elektronische Bauelemente

Die Architektur der Fahrzeugelektronik hat sich sukzessive mit den Anforderungen an leistungsstärkere Steuergeräte und schnellere, breitbandigere Kommunikationsbusse entwickelt. Vor allem mit dem steigenden Bedarf an Over-the-Air Updates für die gesamte Fahrzeugelektronik wird allerdings offensichtlich, dass es einen grundlegenden Wandel der E/E-Architektur bedarf.

Architekturen mit bis zu 100 und mehr updatefähigen Steuergeräten sind weder hinsichtlich Komplexität noch Kostenaufwand darstellbar. Hatte ein Auto vor zehn Jahren noch rund zehn Millionen Zeilen Software-Code, wird die Software von automatisiert fahrenden Fahrzeugen zwischen 300 und 500 Millionen Codezeilen umfassen. Die traditionelle Softwareentwicklung in einzelnen, voneinander unabhängigen Bereichen gerät damit zunehmend an ihre Grenzen. Daher bündeln Zulieferer wie Bosch, ZF und Continental ihre Kräfte in der automobilen Softwareentwicklung zukünftig in eigenen Einheiten.

Hochleistungsrechner (HPC) vereinen in allen Fahrzeugbereichen die immer umfassenderen Funktionen und übernehmen die Aufgaben einzelner Steuergeräte. Mit der Umstellung der Architektur (Bild 1) werden unter anderem Funktionslogiken von getrennten Steuergeräten auf Hochleistungsrechner horizontal integriert. So ersetzen diese Fahrzeugcomputer bestimmte Steuergeräte, interagieren aber auch in einem Netzwerk mit weiteren Elektroniken, wie Zonencontroller, Sensoren oder Aktoren (Bild 2). Zonencontroller kümmern sich daneben um die hardwarenahen Aufgaben.

Entlang dieser Logik geht nahezu die gesamte Automobilindustrie den Weg zum „software-defined Vehicle“. Da diese Fahrzeugcomputer sowohl für Cockpit- und Vernetzungsfunktionen, für Fahrerassistenzsysteme und automatisiertes Fahren sowie den Antrieb nun erstmals in einer übergreifenden Einheit entwickelt werden, entsteht eine durchgängige IT-Architektur für das gesamte Fahrzeug. „Der Wandel der E/E-Architektur findet schrittweise statt. So sind High-Performance Computer der aktuellen Generation weitestgehend auf jeweils eine Elektronikdomäne spezialisiert. Für die Zukunft zeigt sich eine Entwicklung zu stärker standardisierten Serverplattformen, die domänenübergreifend eingesetzt werden können,“ erklärt Werner Köstler, Leiter Key Projects bei Vehicle Networking and Information, Continental.

Mit zunehmender Vernetzung erstreckt sich die Architektur immer stärker auch über das Fahrzeug hinaus: Cloud und Fahrzeugelektronik bis zur Sensor- und Aktuatorebene werden zu einer vertikal integrierten Säule. Entlang dieser Gesamtarchitektur müssen beide Aspekte – vertikale und horizontale Integration – beherrscht werden, um Hochleistungsrechner für die Serie umzusetzen.

Auch in der Entwicklung ergeben sich mit der neuen service-orientierten Architektur enorme Vorteile: Denn mit dem Schritt zu einer softwarezentrischen Betrachtung können Software- und Hardwareentwicklung immer stärker voneinander getrennt werden. Damit lassen sich die Potenziale hinsichtlich Agilität und Geschwindigkeit in der Softwareentwicklung besser ausschöpfen.

Mit dem In Car Application Server 1 (ICAS 1) hat Continental bereits einen hochkomplexen Fahrzeugcomputer in Serie gebracht. Das Projekt mit Volkswagen markiert für Continental den Einstieg in den vielversprechenden HPC-Markt, der bis zum Jahr 2030 jährlich um rund 15 Prozent wachsen soll. Allein der ICAS 1 wird künftig in über 20 Fahrzeugmodellen genutzt. Bis 2022 will Continental mehr als 2,5 Millionen Server bei VW verbauen.

Allein diese Zahlen zeigen Größe und Komplexität eines derartigen Projekts: Rund 600 Entwickler verbrachten bislang knapp über zwei Millionen Stunden mit der Programmierung der komplexen Software für den ICAS 1. Der für den VW ID.3 entwickelte Hochleistungsrechner verarbeitet etwa 30.000 Kommunikationsprotokolle, beinhaltet rund 20 Millionen Programmzeilen und bildet 70.000 Anforderungen ab. Die Software dafür wurde von 19 verschiedenen Parteien entwickelt. Neben dem eigentlichen Produkt müssen auch noch Faktoren wie System, Prozess, Organisation und Schnittstellen zum Automobilhersteller berücksichtigt werden. Der größte Anteil der Entwicklung kommt dabei der Funktionsintegration, dem Testen, Validieren und der Fehlerbehebung zu. Das beginnt bereits in der Entwicklungsphase vor dem Serienstart und endet erst mit dem Ende des Lebenszyklus eines Fahrzeugs.

Um solche softwarelastige Großprojekte stemmen zu können, hat Continental im Geschäftsfeld Vehicle Networking and Information zwei wesentliche organisatorische Weichen gestellt: So wurde ein zentraler Entwicklungsbereich geschaffen, der gesamtheitlich an Plattformen und Modulen für Hard- und Software arbeitet. Daneben hat Continental auch ein Kompetenzzentrum für Projektmanagement ins Leben gerufen: Mit VNI Key Projects stellt Continental nun konsequent auf agile Methoden und Kultur um und begegnet so den immer komplexer werdenden Projekten.

Geschäftsbereich Cross-Domain Computing Solutions

Dem Trend zu immer anspruchsvollerer Elektronik sowie immer mehr Software begegnet auch Bosch mit der neuen Geschäftseinheit Cross-Domain Computing Solutions. Ziel des neuen Bereichs ist es, die Komplexität mit übergreifenden Software- und Elektroniklösungen zu reduzieren. Zudem sollen neue Fahrzeugfunktionen künftig deutlich schneller auf die Straße kommen. Dafür führt Bosch Mitarbeiter aus der Software-, Elektrik- sowie der Elektronikentwicklung aus den Bereichen Fahrerassistenz und automatisiertes Fahren, Car Multimedia sowie Antrieb und Body Electronics zusammen. Der neue Geschäftsbereich wird damit rund 17 000 Mitarbeiter an mehr als 40 Standorten und in über 20 Ländern beschäftigen. Entwickelt wird in der neuen Einheit künftig sowohl die Basissoftware der Fahrzeugcomputer und Steuergeräte als auch die Software der Fahrzeugfunktionen – von der Einparkhilfe und dem Spurhalteassistenten bis zum Musikstreaming.

Auch bei ZF geht man einen ähnlichen Weg und wird Software-Systeme für zukünftige Architekturen konzernweit entwickeln und dem gesamten Unternehmen zur Verfügung zu stellen. Der ZF-Ansatz zielt jedoch nicht darauf ab, die Software-Entwicklung zu zentralisieren. Der Grund dafür ist einfach: Wo erfahrene Teams seit langem auf Komponentenebene miteinander verknüpfte Hard- und Software entwickeln, werden keine Kompetenzen abgebaut. „Stattdessen unterstützen wir komplementär und schaffen durch gemeinsame Software-Integrationsprojekte ideale Rahmenbedingungen. So können sich die Expertenteams auf ihre Arbeit konzentrieren und haben dennoch über das Global Software Center Zugriff auf die neuesten Ressourcen,“ erklärte Dr. Dirk Walliser, Senior Vice President Corporate  Research & Development bei ZF. Zum Jahreswechsel wurde dazu das Global Software Center unter Leitung von Dr. Nico Hartmann, Vice President, Software Solutions & Global Software Center, gegründet.

In einer Vorschau auf die CES 2021 präsentierte ZF zudem seine neue Middleware. Diese offene Software-Plattform dient als „Vermittler“ zwischen dem Betriebssystem eines Fahrzeugrechners und seinen Software-Anwendungen. Schlüsselfunktionen der Middleware sind die Abstraktion der Computer-Hardware von Software-Anwendungen und die Kommunikation zwischen diesen Anwendungen. Als umfassende Software-Plattform wird die ZF-Middleware ab 2024 in Serienfahrzeugen verfügbar sein. (oe)

Bild 1: High-Performance Computer integrieren Funktionen von getrennten Steuergeräten, und sorgen für das Datenmanagement – im Fahrzeug und darüber hinaus.

Bild 2: Fahrzeugcomputer ersetzen Steuergeräte und interagieren mit Zonencontroller, Sensoren oder Aktoren.

Bild 3: Die ZF-Middleware ermöglicht eine effiziente Kommunikation von Software-Funktionen zu Hardware-Komponenten. Sie bietet Unabhängigkeit und Kompatibilität, um Fahrzeugplattformen zukunftssicher zu machen.

Klaus Oertel ist Chefredakteur der Hanser automotive.

»Software aus einer Hand zu liefern, ist unsere  Antwort auf die immense Herausforderung,  Autos immer stärker zu digitalisieren «

Harald Kröger ist Geschäftsführer in der Mobilitätssparte der Robert Bosch GmbH und verantwortet den neuen Geschäftsbereich Cross-Domain Computing Solutions.

»In unserem neuen  Kompetenzzentrums VNI Key Projects können wir schneller, agiler und effizienter auf Marktveränderungen reagieren  und somit Kundenanforderungen noch besser gerecht werden «

Werner Köstler, Leiter VNI Key Projects bei Continental.

»Mit unserem Global Software Center können  wir neue Trends, Technologien, Methoden,  Verfahren, Tools und Funktionen koordinieren und standardisieren, und allen ZF-Bereichen auf  einer gemeinsamen Entwicklungsplattform zur Verfügung zu stellen.«

Dr. Dirk Walliser ist Senior Vice President Corporate  Research & Development bei ZF.

Software / Betriebssysteme / KI

Connectivity (Bussysteme, Telekommunikation, 4G / 5G, WLAN)

Die Vorteile bürstenloser Gleichstrommotoren (BLDC) haben scheinbar so gut wie alle motorisierten Anwendungen durchdrungen – viele werden aber immer noch mit bürstenbehafteten DC-Motoren realisiert. Denn die zu erzielenden Effizienzverbesserungen rechtfertigen das komplexere Design und die Kosten von BLDC-Motor Implementierungen oftmals nicht.

Fahrzeugbesitzer profitieren schon lange vom Einsatz elektrischer Motoren und den damit verbundenen Vorteilen der Elektrifizierung, die für viele wahrscheinlich mit elektrischen Fensterhebern begann. Anstatt sich beim Verlassen eines Parkplatzes oder beim Drive-in mit dem Kurbelhebel herumzuschlagen, genügt ein einfacher Knopfdruck, um das Fenster zu öffnen und wieder zu schließen. Bei Fahrzeugen, die von mehreren Fahrern genutzt werden, kommt es häufig zu der Situation, dass der Sitz scheinbar immer für den anderen Fahrer konfiguriert ist. Hier sind häufig mehrere Motoren mit einer Speicher-/Memory-Funktion integriert, sodass jeder Fahrer mit einem einzigen Knopfdruck seine bevorzugte Fahrposition einnehmen kann. Und im Familien-Van können selbst die kleinsten Passagiere die Schiebetür dank Motorisierung problemlos öffnen und schließen.

Die Vorteile bürstenloser Gleichstrommotoren (BLDC) haben scheinbar so gut wie alle motorisierten Anwendungen durchdrungen – viele der hier aufgeführten werden aber immer noch mit bürstenbehafteten DC-Motoren realisiert. Dies liegt daran, dass die zu erzielenden Effizienzverbesserungen das komplexere Design und die Kosten von BLDC-Motor-Implementierungen nicht rechtfertigen. Bei einer Kraftstoffpumpe, die während der gesamten Fahrt in Betrieb ist, sind die längere Lebensdauer und die Energieeinsparungen eines BLDC-Motors offensichtlich. Aber bei motorbetriebenen Anwendungen, die eine nicht so präzise Regeldynamik erfordern oder nur einige Sekunden, vielleicht ein- oder zweimal pro Fahrt eingesetzt werden, kommen die Vorteile bürstenbehafteter DC-Motoren zum Tragen.

Geht es um das Design der Steuerelektronik für DC-Motoren, haben Entwickler die Qual der Wahl. Ein Mikrocontroller (MCU) bildet die Basis des Steuergerätes (ECU), empfängt Steuersignale typischerweise über CAN oder LIN und wandelt diese in Motorkontrollsignale um. Diese müssen dann die Leistungsschalter (meist MOSFETs) ansteuern, an die der Motor angeschlossen ist. Die MOSFETs befinden sich in einer H-Brückenkonfiguration. Dadurch kann der Motor in beide Richtungen drehen und mithilfe eines pulsbreitenmodulierten (PWM) Signals die Drehzahl des Rotors gesteuert werden. Die Logikausgänge der MCU liefern jedoch nicht genügend Strom, um die MOSFETs direkt durchzuschalten. Daher sind Gate-Treiber erforderlich, die die Logikausgänge der MCU auf Leistungspegel erhöhen, die zur Ansteuerung der MOSFETs erforderlich sind.

Der einfachste Weg solche Systeme zu partitionieren, ist nach Funktion: MCU, Pre-Driver, H-Brücke (Bild 1). Da die Entwickler unter dem Druck stehen, kompaktere und zuverlässigere Designs bereitzustellen, sind alternative, höher integrierte Ansätze erforderlich. Die Integration von MCU und Pre-Driver ist eine Möglichkeit. Der Nachteil dabei ist, dass die Wiederverwendbarkeit der MCU womöglich eingeschränkt ist, sollten sich die Pre-Driver Anforderungen in Folgeprojekten ändern. Ist die MCU Software vorhanden, getestet und sicherheitsgeprüft, stellt eine dann notwendige Portierung der Software eine erhebliche Hürde dar.

Möchte man die MCU jedoch beibehalten, besteht die Alternative darin, einen Motortreiber (MCD; Motor Control Driver) zu verwenden, der den Pre-Driver und die H-Brücke integriert. Zukünftige Projekte mit veränderten Motoranforderungen können unter Beibehaltung der MCU mithilfe eines maßgeschneiderten MCD aus dem verfügbaren Lineup realisiert werden.

Toshiba erweitert sein Angebot an integrierten 12-V-Pre-Driver/H-Brücken um die kürzlich eingeführten TB9053FTG und TB9054FTG. Diese 2-Kanal-DC-Motortreiber werden in robuster BiCD-Technologie gefertigt und kombinieren die Vorteile der Bipolar-, CMOS- und DMOS-Technik. Jeder Baustein hat zwei integrierte H-Brücken, die zugehörigen Pre-Driver sowie Diagnose- und Kontrollfunktionen. Betriebs- und etwaige Fehlerzustände können mittels der SPI Schnittstelle detailliert ausgelesen werden.

Die DC-Motortreiber lassen sich im SMALL-Modus mit bis zu zwei 5-A-Motoren oder im LARGE-Modus mit beiden Kanälen parallel geschaltet betreiben, um einen Motor mit bis zu 10 A anzusteuern (Bild 2). Der BiCD-Prozess garantiert, dass die Bauteile einen entsprechend niedrigen Schaltwiderstand aufweisen (290 mΩ pro Halbbrücke bei Tj=150 °C). Dies reduziert die Verlustleistung und die sich daraus ergebende Wärmeentwicklung. Um die Anzahl der erforderlichen externen Bauelemente zu minimieren, sind die Kondensatoren für die Ladungspumpen des Pre-Drivers bereits integriert. Das Design ist so ausgelegt, dass ein 100% PWM-Tastverhältnis gewährleistet ist.

Die Ansteuerung der Motortreiberbausteine kann über die PWM-Ausgänge einer MCU erfolgen. Die vier integrierten Halbbrücken verfügen über separate PWM-Eingänge, die zwischen 1 und 20 kHz betrieben werden können. Wobei die Totzeiteinfügung automatisch erfolgt. Weitere MCD Eingänge sind für die Konfiguration und Enable/Disable vorgesehen.

Über die serielle SPI-Schnittstelle hat man Zugriff auf eine Vielzahl von Konfigurationsmöglichkeiten und Diagnosedaten. Ferner können die Treiberbausteine über SPI kaskadiert werden, um mehrere Motorgruppen zu betreiben. Ein Überstromschwellwert, der als Chopper-Strombegrenzung implementiert ist, lässt sich im SMALL-Modus zwischen 4,6 und 6,5 A oder im LARGE-Modus zwischen 9,2 und 13 A einstellen.

Die DC-Motoren lassen sich über den Motortreiber sogar vollständig über SPI ansteuern (Bild 3). Ein integrierter eigener 16-MHz-Oszillator und ein PWM-Generator reduzieren die Anzahl der erforderlichen Signale, die die MCU liefern muss. Alternativ kann ein einzelner MCU-Taktausgang als Zeitbasis verwendet werden. Fällt dieses externe Signal wegen einem Fehlerfall aus, dient der interne Oszillator als Ersatz.

Um EMV-Anforderungen (Elektromagnetische Verträglichkeit) gerecht zu werden, bietet der TB905xFTG sieben Stufen für die Regelung der Flankensteilheit (Slew-Rate) für die MOSFET Ansteuerung (Bild 4).

Der schon angesprochene niedrige Durchlasswiderstand trägt dazu bei, die Wärmeentwicklung minimal zu halten. Die entstehende Wärme lässt sich über das thermisch optimierte Gehäuse des TB9053FTG verbessert abführen. Ein zusätzlicher integrierter Metallkern führt zu einem geringen Wärmewiderstand von nur 0,67 °C/W.

Das für den TB9054FTG verwendete Gehäuse ist ein 6 mm × 6 mm Wettable-Flank-VQFN mit 0,5 mm Pin-Abstand, wodurch sich dieser AEC-Q100 Baustein für die automatisierte optische Inspektion (AOI) eignet.

Während viele motorisierte Anwendungen mit bürstenlosen DC-Motoren ausgestattet werden, gibt es nach wie vor eine Vielzahl von Automotive-Systemen, die aufgrund ihrer Designkomplexität und Kosten weiterhin auf herkömmliche (bürstenbehaftete) DC-Motoren setzen. Motortreiber wie der TB905xFTG basieren auf fortschrittlichen Prozesstechnologien wie BiCD, um eine hochgradig konfigurierbare und effiziente Motorsteuerung zu ermöglichen. Sie erfüllen die strengen Anforderungen im Automotive-Bereich und ermöglichen Plattformansätze, bei denen bestehende MCU-Lösungen wiederverwendet werden können. Durch ihre umfassenden Diagnosefunktionen lassen sich die neuen Motortreiber in die intelligenten Automotive-Plattformen von heute integrieren. (oe)

<a href="http://toshiba.semicon-storage.com">toshiba.semicon-storage.com</a>

Bild 1: Integrierte Pre-Driver und H-Brücken Lösungen sind für DC-Motorsteuerungen am sinnvollsten und ermöglichen die flexible Auswahl einer geeigneten MCU.

Bild 2: Der TB905xFTG kann bis zu 5 A pro Kanal für zwei Motoren im SMALL-Modus oder bis zu 10 A im LARGE-Modus für einen einzelnen Motor liefern.

Bild 3: Die SPI-Schnittstelle reduziert die Anzahl der erforderlichen MCU-Pins aufgrund des internen Oszillators und der vorhandenen PWM-Generatoren.

Bild 4: Der TB905xFTG bietet sieben Stufen zur Steuerung der Flankensteilheit (Slew-Rate), um die EMV-Anforderungen zu erfüllen.

Anwendungen bürstenbehafteter DC-Motoren.

Klaus Neuenhüskes ist Chief Engineer Solution Marketing bei Toshiba Electronics Europe.

Dual Banking für reibungslose SOTA-Updates

Upgrades für Fahrzeugfunktionen sind im Zusammenhang mit autonomen und vernetzten Automobilen von entscheidender Bedeutung. SOTA (Software Over the Air) Updates werden zukünftig der Standard bei Bugfixes, Erweiterungen und neuen Funktionsmerkmalen sein. Dual Banking ist in einem solchen Szenario für ein positives Kundenerlebnis unverzichtbar.

Bei Dual Banking ist der Speicherbedarf für updatefähige Softwarekomponenten in der ECU doppelt so hoch wie gewöhnlich. Der Speicher wird in zwei als Bank-A und Bank-B bezeichnete gleich große Partitionen aufgeteilt. Von den zwei Bänken ist zu jedem Zeitpunkt jeweils immer eine aktiv und die andere inaktiv. Die neue Software wird laufend in die inaktive Speicherbank heruntergeladen. Nach einem erfolgreichen Software-Update kann die neue Software dann durch Umschalten der Speicherbank ausgeführt werden. Die Funktionsmerkmale des Dual Banking sind in Bild 1 dargestellt.

Während das Fahrzeug läuft, also während Software aus der aktiven Bank ausgeführt wird, kann das Telematiksteuergerät (TCU) im Fahrzeug die neuen Software-Updates empfangen, die dann in die inaktive Speicherbank der Ziel-ECU geladen werden. Dies wird als Hintergrundprogrammierung bezeichnet, und es gibt dabei keine Fahrzeugausfallzeiten aufgrund eines Software-Updates. Normalerweise wird die Software digital signiert und in die Ziel-ECU heruntergeladen, um nicht authentifizierte Updates zu vermeiden. Auch eine Fahrzeugdiagnose ist während der Hintergrundprogrammierung möglich.

Mit der Software-Teildownloadfunktion ist es nicht erforderlich, bei jedem Software-Update alle Softwarekomponenten einer ECU herunterzuladen. Es besteht die Möglichkeit, nur die überarbeiteten Softwarekomponenten einzeln herunterzuladen, um die Gesamtdauer des Updates zu verkürzen und die damit verbundenen Übertragungskosten zu reduzieren.

Während der Hintergrundprogrammierung kann das Software-Update unterbrochen werden, wenn die ECU oder der Server offline geht und dann später bei erneuter Verfügbarkeit fortgesetzt oder abgebrochen werden. Auf diese Weise lassen sich die Gesamtdauer des Software-Updates und die entsprechenden Datenkosten reduzieren. Das unterbrochene/abgebrochene Software-Update wirkt sich in keiner Weise auf die ECU aus, da es sich in der inaktiven Speicherbank befindet.

Nach einem erfolgreichen Software-Update wird die aktualisierte Software beim nächsten Fahrzeugstart aus der Download-Speicherbank ausgeführt. Der Kunde kann die aktualisierte Software in ein paar Probeläufen nutzen und sie dann aktivieren, wenn er mit der Leistung der aktualisierten Version zufrieden ist.

Nach der Aktivierung der Software wird die aktive Speicherbank inaktiv und die Probelauf-Speicherbank aktiv. Ist der Kunde mit der Leistung der aktualisierten Software nicht zufrieden, kann er die vorherige Version der Software wiederherstellen, indem er einfach die Speicherbank umschaltet, sodass er von der neuen Version nicht betroffen ist.

Sobald das Software-Update aktiviert ist, die frühere Version wiederhergestellt oder auch das Update abgebrochen ist, wird die Software bei laufendem Fahrzeug aus der aktiven Bank in die inaktive Bank kopiert. Dieser Vorgang wird als Softwaresynchronisation bezeichnet und ist nützlich, um zulässige Software in beiden Bänken der ECU sicherzustellen. Ist die Software in der aktiven Speicherbank aus irgendeinem Grund beschädigt, kann die Software aus der inaktiven Bank verwendet werden. In diesem Fall wird die aktive Bank zur inaktiven und die inaktive Bank zur aktiven, und die Software aus der neuen aktiven Speicherbank wird ausgeführt. Dies hilft, einen ECU-Ausfall zu verhindern und das Fahrzeug am Laufen zu halten.

In Servicestellen kann die ECU per OBD neu programmiert werden, um den Bootloader bei Bugfixes, Erweiterungen und neuen Funktionen zu aktualisieren. Dies verbessert die SOTA-Updatefähigkeit des Fahrzeugs und trägt somit dazu bei, Stillstandszeiten zu vermeiden. Auch ist es immer möglich, mit einer solchen Vordergrundprogrammierung Komponenten der Anwendungssoftware zu aktualisieren.

Wenn der Ziel-Mikrocontroller in der ECU die Neuzuordnung logischer Adressen zu physikalischen Adressen unterstützt, kann die ECU-Software mit logischen Adressen aufgebaut werden, die sich aus einer beliebigen Bank ausführen lassen. Dies erleichtert eine schnellere Speicherbankumschaltung bei jedem neuen Software-Update und verhindert so mögliche Fahrzeugstartverzögerungen nach einem neuen Software-Update.

Das SOTA-Update ist anfällig für Hacker-Angriffe. Um nicht authentifizierte Software-Updates zu vermeiden, muss die ECU-Software mit Signaturalgorithmen wie ECDSA, RSA und anderen digital signiert werden. Während des Software-Updates berechnet die ECU den Hash-Wert und verifiziert die Signatur der heruntergeladenen Software anhand des in der ECU gespeicherten öffentlichen Schlüssels/Zertifikats. Die heruntergeladene Software wird als gültig behandelt, wenn die Signaturverifizierung erfolgreich ist. Dieser sichere Download der Software hilft, die Programmierung nicht authentifizierter Software und somit Fahrzeug-Stillstandszeiten zu vermeiden.

Es ist offensichtlich, dass Dual Banking durch die oben erläuterten Funktionen zur Verbesserung des Kundenerlebnisses beiträgt. Des Weiteren können auch Fahrzeugrückrufe wegen Software-Updates und die damit verbundenen Kosten vermieden werden. Eine problemlose Wartung, Software-Updates und -erweiterungen verbessern die Sicherheit und Leistungsfähigkeit des Fahrzeugs. Dies wiederum führt zu einem besseren Kundenerlebnis ohne Stillstandszeiten während der Software-Updates. (oe)

Der Autor Prabakaran Chinnasamy  ist Senior Solution Architect bei KPIT Technologies.

Bild 2: Software-Update bei laufendem Fahrzeug.

In der Produktion und Entwicklung von Steuergeräten ist es notwendig, schnell und flexibel auf Software-Updates eines OEMs reagieren zu können. Eine Herausforderung ist dabei, bereits große Mengen an produzierten Steuergeräten auf den neuesten Softwarestand zu bringen, ohne hohe Zusatzkosten zu verursachen.

Im Tier1-Umfeld beispielsweise muss auf den verspäteten Erhalt von Software-Updates innerhalb der Produktionsphase schnell reagiert werden. Zusätzlich gibt es für das Re-Flashen von Steuergeräten in hoher Produktionsanzahl strenge zeitliche Vorgaben, die besonders bei großen Herstellungsmengen nur schwer einzuhalten sind. Das Tool GiraBITE von b-plus automotive bietet mit der Parallelisierung des UDS Downloads nun eine Lösung, um bis zu 40 Steuergeräte parallel zu flashen und so eine hohe Zeitersparnis zu erreichen. Veoneer gehört zu den ersten Kunden, die auf die Lösung von b-plus automotive setzt und beschreibt die Vorteile aus Sicht eines Steuergeräteherstellers.

Wer kennt die Herausforderung nicht: die Fertigung arbeitet unter Hochdruck, doch die Software auf den produzierten Steuergeräten ist durch neue Kundenfeatures bereits überholt. Eine schnelle Aktualisierung würde häufig ein Öffnen der Gehäuse und damit einen erhöhten Zeit- und Kostenaufwand bedeuten. Wie soll der Tier1 mit dieser Konfliktsituation nun umgehen? Um das Öffnen der Hardware zu vermeiden, ist der Einsatz eines OEM-Flashprozesses über die Fahrzeugschnittstelle naheliegend. Allerdings stehen diese Flashing-Tools in der Fertigung nicht zwangsläufig zur Verfügung. Zudem können bestehende Tools häufig nur ein einziges Steuergerät zur gleichen Zeit updaten und ermöglichen nicht das parallele Flashen mehrerer Steuergeräte gleichzeitig.

Für diesen Problemfall hat b-plus automotive das etablierte Entwickler-Flashtool „GiraBITE“ um die für Steuergeräteentwicklung relevante „Multi Instance License“ erweitert. Damit wird es für Hersteller möglich, mit nur einem Rechner bis zu 40 Steuergeräte parallel und OEM-konform über die Fahrzeugschnittstelle zu flashen.

GiraBITE ist ein hardware-unabhängiges UDS-Flashtool für Steuergeräte, welches entlang des gesamten Prozesses für die Entwicklung, den Test, die Fertigung und Diagnose von Steuergeräten eingesetzt werden kann. Dabei lassen sich nahezu beliebig viele ECUs gleichzeitig flashen, was eine enorme Zeitersparnis darstellt. Über eine Kommandozeile lassen sich die Flash-Prozesse zusätzlich automatisieren und vereinfachen somit das Flashen von ECUs zusätzlich.

Das bei Veoneer eingesetzte Tool von b-plus automotive liefert zudem stets Transparenz über den Flash-Status und den Fortschritt des Prozesses. Aufgrund der flexiblen und schnellen Anpassung an kundenspezifische Vorgaben und Workflows sowie die Integration in bestehende Kundensysteme, konnte GiraBITE sofort als Lösung bei Veoneer eingesetzt werden und zur schnellen Aktualisierung des Softwarestands auf den bereits produzierten Steuergeräten beitragen. Neben dem erwähnten Anwendungsfall bei Veoneer wird GiraBITE auch für Remote-Updates von Steuergerätesoftware in Prototypenfahrzeugen oder am Labortisch verwendet, um das Öffnen des Gehäuses zu vermeiden.

Veoneer ist einer der ersten Kunden, der auf GiraBITE setzt. Das schwedische Unternehmen mit Hauptsitz in Stockholm bietet Technologien für die Automobilindustrie an, unter anderem auch die Entwicklung von Fahrerassistenz-Steuergeräten. Gerade in diesem hochdynamischen Umfeld wird die Software stetig weiterentwickelt, auch während Test- und Validierungsphasen. Überholte Software auf Steuergeräten führt oft zu Verzögerungen im Fertigungsprozess. Im Veoneer-Projekt sorgte eine Prozessverzögerung dieser Art dafür, dass die Einhaltung der Deadline zur Auslieferung ihrer Steuergeräte gefährdet war. Mithilfe des Einsatzes von GiraBITE konnte dies verhindert und der Auslieferungstermin eingehalten werden.

Die zeit- und kostenintensive Aktualisierung der Software auf Steuergeräten und das damit verbundene Öffnen des Gehäuses sowie das anschließende Einspeisen in die Fertigungslinie, war für Veoneer aus Kapazitätsgründen nicht möglich. Es galt, tausende Steuergeräte, die bereits auf Lager waren, mit einer mittleren Flashdauer von ca. 15 Minuten in sehr kurzer Zeit mit Software-Updates zu flashen. Das Re-Flashing mit Standardtools kam somit aus Zeit- und Kostengründen nicht in Frage.

Da Veoneer und b-plus automotive bereits in der Vergangenheit mehrere erfolgreiche Projekte gemeinsam durchgeführt hatten, wurde für das bestehende Flashtool GiraBITE eine MES-Anbindung entwickelt (MES – Manufactoring Execution System). Somit konnte GiraBITE direkt in die Fertigungssoftware eingebunden und die erforderliche Traceability gewährleistet werden. Das vorgegebene Zeitlimit von 15 Minuten zur Aktualisierung der Steuergeräte konnte durch den Einsatz des b-plus automotive Tools sogar unterschritten werden. Die fristgerechte Lieferung der ECUs an den OEM wurde somit sichergestellt. Nach dem erfolgreichen Projektende wird das Flashtool von beiden Projektteilnehmern, Veoneer und dem OEM, weiterhin genutzt.

Die erwähnte flexible Anbindung von GiraBITE an das spezifische Steuergeräteverhalten bei Veoneer war nur aufgrund von spezifischen Features des Produkts möglich. Dazu gehört die große Vielfalt an unterstützten Inputformaten, wie ODX-Flash, Motorola S-Record und Intel-Hex sowie an Bus-Technologien wie CAN, FlexRay, Ethernet, etc. Des Weiteren unterstützt GiraBITE verschiedene Hersteller von CAN- und FlexRay-Interfaces. In Kombination mit guten Security-Mechanismen, wie die Seed & Keed-Berechnung, die Checksummen- sowie die Signaturberechnung, konnte die Einbindung von GiraBITE in die Fertigungssoftware problemlos erfolgen, ohne die laufende Produktion unterbrechen zu müssen. (oe)

Bild 1: Grafische Darstellung der Tool-Integration in das Fertigungsmanagement-Tool von Veoneer sowie der Flash-Prozess.

Bearbeitet nach Unterlagen der b-plus automotive GmbH, 94469 Deggendorf.

Messtechnik, Testlösungen, Diagnose

Infotainment- und AUTOSAR-Konsolidierung auf einer ECU

Dieser Artikel zeigt, wie ein Hypervisor eine zuverlässige Lösung für die Konsolidierung von Infotainment- und AUTOSAR-Anwendungen auf demselben Steuergerät ermöglicht. Dies ist aufgrund der effizienten Leistung und der geringen Kosten für Portierungsanwendungen möglich.

Neue und innovative Funktionen wie Benutzeroberflächen, Cloud-basierte Dienste, Ad-hoc-Netzwerke und autonomes Fahren erhöhen die Komplexität der Elektrik- und Elektronikarchitektur eines Fahrzeugs und stellen neue Anforderungen an vernetzte Softwaresysteme. Dies zwingt Automobilhersteller dazu, mehrere Geräte in einer einzigen High-Computing-Plattform zu konsolidieren.

Während dieser Ansatz zwar das Netzwerk des Fahrzeugs vereinfacht, stellt er die Architektur von Automobil-Softwaresystemen vor weiteren Herausforderungen in Bezug auf Sicherheit und Vernetzung, Für die fahrzeuginterne Kommunikation und sicherheitskritische Anforderungen sind häufig Echtzeitbetriebssysteme (RTOS) erforderlich, während Infotainment-Anwendungen, die nicht sicherheitsrelevant sind, auf gewöhnlichen Linux-Betriebssystemen ausgeführt werden. Ein Ansatz zur Lösung dieses Problems besteht darin, zwei Mikrocontroller auf demselben Steuergerät zu verwenden. Auf einer MCU wird die Linux-basierte Anwendung ausgeführt, die für Aufgaben mit hohem Rechenaufwand wie beispeilsweise KI-Algorithmen und Infotainment-Funktionen verantwortlich ist, während auf der anderen MCU einfache Echtzeitanwendungen zur Ausführung gebracht werden, die für die fahrzeuginterne Kommunikation verwendet werden. Beide MCUs sind dabei mit einer seriellen Peripherieschnittstelle verbunden, die die Kommunikation zwischen diesen beiden Anwendungen ermöglicht. Obwohl dieser Ansatz zwar den Einsatz von Standard-Softwarearchitekturen ermöglicht, ist er ineffizient und recht kostspielig, da für jedes System eine eigene Hardware bereitgestellt werden muss. Ein anderer Ansatz besteht darin, Echtzeitanwendungen nach Linux zu portieren.

Siemens EDA (vorm. Mentor, A Siemens Business) bietet mehrere Produkte an, mit denen solche Probleme behoben werden können. Mit dem Mentor Embedded Multicore Framework beispielsweise können mehrere Betriebssysteme auf homogenen und heterogenen Multicore-Prozessoren bereitgestellt werden. Diese Lösung basiert auf dem OpenAMP-Standard, der von Mentor und Xilinx gemeinsam entwickelt wurde. Ein weiterer Ansatz ist der Einsatz des Mentor Embedded Hypervisor, der mithilfe von Virtualisierungstechniken mehrere Gast-Betriebssysteme auf demselben Prozessor konsolidiert.

Im Folgenden wird gezeigt, wie der Mentor Embedded Hypervisor eingesetzt werden kann, um eine Echtzeit-AUTOSAR-Anwendung mit einer Linux-basierten Anwendung zu konsolidieren.

Es gibt zwei Typen von Hypervisors, die heute häufig verwendet werden (Bild 1):

<ul><li>Typ 1 Native Hypervisor: Ein Hypervisor, der nativ auf Hardware ausgeführt wird, da er im Prinzip selbst als Betriebssystem fungiert.</li><li>Typ 2 Gehosteter Hypervisor: Diese Art von Hypervisor muss von einem anderen Betriebssystem gehostet werden und ist nur für die Virtualisierung des Gast-Betriebssystems unter Verwendung der Ressourcen verantwortlich, die ihm vom Host-Betriebssystem zur Verfügung gestellt werden.</li></ul>

Der Embedded Hypervisor von Siemens EDA ist ein Typ-1-Hypervisor (Bild 2) und basiert auf einer Mikrokernel-Architektur, bei der der Kern des Systems die grundlegenden Funktionen konsolidiert, die der Hypervisor für die Ausführung auf der Hardware benötigt.

Dieser Ansatz bietet auch den Vorteil, die kritischsten Teile des Systems für ein Höchstmaß an Sicherheit zu qualifizieren, da die Größe der vertrauenswürdigen Computerbasis im System verringert wird. Er minimiert auch den Speicherbedarf des Hypervisors entsprechend den Anforderungen der Gäste, z. B. nicht verwendete Funktionen, die dann so konfiguriert werden können, dass sie aus dem Hypervisor-Image entfernt werden.

Der Embedded Hypervisor bietet mehrere Modelle für den Zugriff auf Peripheriegeräte und bietet damit mehr Flexibilität beim Systemdesign. Einige dieser Modelle umfassen:

<ul><li>Direkter Zugriff: Weist Hardwaregeräte ausschließlich einer virtuellen Maschine zu, was direkten Zugriff ermöglicht. Dies ist vorteilhaft, wenn ein Hardwaregerät auf Systemebene so konzipiert ist, dass es nur von einer virtuellen Maschine verwendet werden kann, da keine Hypervisor-Eingriffe erforderlich sind, um die Systemleistung zu verbessern.</li><li>Geteilter Zugriff: Wenn ein Hardwaregerät einer virtuellen Maschine zugeordnet ist und erkannt wird, dass dieses Gerät gemeinsam genutzt wird, erfolgt die Behandlung auf der Ebene der virtuellen Maschine.</li><li>Emulierter Zugriff: Ein gängiges Modell für die gemeinsame Nutzung von Hardwaregeräten zwischen virtuellen Maschinen, bei dem der Hypervisor den Gerätezugriff über Trap-and-Emulate-Techniken steuert, während jede virtuelle Maschine annimmt, dass ihr das Hardwaregerät zugeordnet ist.</li><li>Virtueller Zugriff: Ähnlich wie beim emulierten Zugriff, bei dem das Hardwaregerät dem Hypervisor zugeordnet ist, die virtuelle Maschine jedoch erkennt, dass ihr das Hardwaregerät nicht zugeordnet ist, und einen virtuellen Treiber für den Hardwarezugriff verwendet. Hier ist keine Emulation des Geräts erforderlich.</li></ul>

Die Verwendung von Virtualisierung in der Architektur von Automobilsoftware bietet einen besseren Ansatz, um diese Probleme zu lösen. Dies kann erreicht werden, indem verschiedene heterogene Automobilplattformen in virtuellen Maschinen (VM) gekapselt werden, die auf derselben Hardware ausgeführt werden. Dieser Ansatz bietet nicht nur eine effizientere Kommunikationsmethode durch Verwendung der Kommunikation zwischen VMs anstelle von seriellen Verbindungen, sondern reduziert auch die Kosten für das Hinzufügen eines dedizierten Mikrocontrollers zu jeder Plattform. Auch ältere Plattformen können als virtuelle Maschinen wiederverwendet werden, ohne dass neue Anpassungen erforderlich sind.

Die Kommunikation zwischen VMs kann mithilfe einfacher Zugriffstechniken für gemeinsam genutzten Speicher oder mithilfe strukturierterer Frameworks wie VirtIO erreicht werden. Obwohl AUTOSAR VirtIO nicht unterstützt, bietet es eine Spezifikation mit der Bezeichnung Complex Device Drives (CDDs), nach der nicht unterstützte Treiber wie VirtIO integriert werden können.

Für die AUTOSAR-Demo-App bestand das Ziel darin, die strikten Echtzeitanforderungen für die Auslösung der Ablaufpunkte der Schedule Table zu erreichen. Die Schlüsselfaktoren für dieses Ziel in der virtualisierten Umgebung sind:

<ul><li> IRQ-Routing zur virtuellen Maschine</li><li> Generischer Interrupt-Controller-Zugriff</li><li>Virtueller Timer-Zugriff</li></ul>

Bild 3 zeigt eine Übersicht über diese Demo-App. Die AUTOSAR-App wird als VM1 auf einem dedizierten Core ausgeführt. Die App nutzt die AUTOSAR-Kryptografiebibliothek, um zwei Vorgänge auszuführen: MAC-Überprüfung und AES-Entschlüsselung verschlüsselter Daten (alle 100 ms). Eine andere App wird mit der Verarbeitung entschlüsselter Daten beauftragt. Dies wird mithilfe einer Schedule Table (Bild 4) organisiert.

Die Linux-Anwendung wird als VM2 auf einem dedizierten Core ausgeführt und teilt die UART-Konsole mit dem Hypervisor, um den Wechsel zwischen der Hypervisor-Konsole und der Linux-Konsole zu ermöglichen, wobei letztere die Anbindung an das Linux-Dateisystem ermöglicht (Bild 5).

Es konnte bestätigt werden, dass bei Verwendung der AUTOSAR OS-Laufzeitmessung die Leistung der App beim Ausführen in einer virtualisierten Umgebung nicht beeinträchtigt wurde. Die Gesamt-CPU-Auslastung bei Ausführung in einer virtualisierten Umgebung stieg nur um circa 0,2%. Dies ist der Overhead, der durch IRQ-Routing und Hypervisor-Scheduler-Handling entsteht.

Da es für den Zugriff auf den virtuellen Timer oder die GIC-CPU-Schnittstelle keinen Overhead gab, wurden bei den Kernel-Ein- und Ausstiegszeiten für das AUTOSAR OS in einer virtualisierten Umgebung keine Änderungen vorgenommen. Die IRQ-Routing-Zeit war sehr kurz (561 ns für 1-GHz-Taktfrequenz), so dass die Latenz für den Timer-Interrupt des Betriebssystems nicht beeinflusst wurde.

Gezeigt wurde, wie der Hypervisor von Siemens EDA eine zuverlässige Lösung für die Konsolidierung von Infotainment- und AUTOSAR-Anwendungen auf demselben Steuergerät ermöglicht.

Die Flexibilität bei der Konfiguration des Hypervisors ermöglicht es dem Anwender, den Eingriff des Hypervisors auf ein Minimum zu reduzieren, wodurch unterschiedliche Echzeit-Anforderungen erfüllt werden.

Eine Standardisierung der Virtualisierung in der Architektur von Automobilsoftware wäre ein wichtiger Schritt zur Bereitstellung neuer Lösungen in heutigen Steuergeräten. Aus diesem Grund unterstützt Siemens EDA Hypervisor Standards wie VirtIO für virtuelle Geräte oder AUTOSAR für fahrzeuginterne Echtzeitanwendungen. (oe)

<a href="http://www.mentor.com">www.mentor.com</a>

Bild 1: Es gibt zwei Typen von Hypervisors, die häufig verwendet werden.

Bild 2: Der Embedded Hypervisor unterstützt mehrere Gast-Betriebssysteme wie  Android,  AUTOSAR,  Mentor Embedded Linux und  Nucleus RTOS.

Bild 5: Wechseln zwischen Hypervisor- und Embedded Linux-Konsolen.

Der Autor, Mohamed Mounir, ist Embedded-Software-Ingenieur bei Siemens EDA und beschäftigt sich mit Virtualisierungskonzepten in Automobilsystemen.

AUTOSAR auch für zukünftige E/E-Architekturen

Im November 2020 hat die weltweite Entwicklungspartnerschaft AUTOSAR  das neue Release R20–11 des AUTOSAR Standards veröffentlicht und am  4. Dezember 2020 im Rahmen eines virtuellen Release-Events einer breiten Öffentlichkeit vorgestellt. Präsentiert wurden neben neuen Features und  Highlights der AUTOSAR Standards für die Classic Platform und die Adaptive Platform auch ein Ausblick auf 2021.

Im November 2020 hat die weltweite Entwicklungspartnerschaft AUTOSAR das neue Release R20–11 des AUTOSAR Standards veröffentlicht und am 4. Dezember 2020 im Rahmen eines virtuellen Release-Events einer breiten Öffentlichkeit vorgestellt.

Mit mehr als 290 Partnern auf der ganzen Welt zielt die Entwicklungspartnerschaft AUTOSAR (AUTomotive Open System ARchitecture) darauf ab, die Software-Architektur in Fahrzeugen zu standardisieren, um die Gesamteffizienz der Software-Entwicklung und -Integration von Fahrzeugsystemen zu verbessern. Das Ziel der Partnerschaft ist es, einen globalen Standard für eine gemeinsame E/E Systemarchitektur, Anwendungssoftware Schnittstellen und Methoden bei der Entwicklung von Embedded Software und Systeme für E/E Architekturen und deren elektronischen Steuergeräte in Kraftfahrzeugen zu etablieren.

Mit dem aktuellen Release R20–11 unterstützt AUTOSAR die Entwickler mit neuen Features und Verbesserungen sowohl für die Classic als auch für die Adaptive Plattform. Hierzu haben die AUTOSAR-Partner in 20 Arbeitsgruppen zusammengearbeitet und Lösungen für etwa 1800 Änderungsanfragen entwickelt, abgestimmt und im AUTOSAR Release veröffentlicht.

„Die Zeit der weitgehend unveränderlichen Funktionalität im Fahrzeugnetzwerk ist vorüber. Hochautomatisiertes Fahren und die zunehmende Vernetzung zur Außenwelt verlangen nach flexibleren Software-Architekturen – und einem hohen Grad an funktionaler Sicherheit und IT-Sicherheit,“ erklärte AUTOSAR-Sprecher Dr. Günter Reichart. AUTOSAR stellt hierfür wichtige Features in beiden Bereichen sowie für Connectivity und Update- und Upgrade von Fahrzeugfunktionen bereit.

Die AUTOSAR Classic Platform erfüllt für viele Fahrzeugfunktionen die gängigen Anforderungen an ein Echtzeitbetriebssystem und die funktionale Sicherheit sowie für Vernetzung. Daher wurde und wird AUTOSAR Classic über die Jahre kontinuierlich weiterentwickelt und stellt zum Beispiel auch Security-Mechanismen bereit, wie etwa für eine sichere Onboard-Kommunikation oder das Schlüssel- und Zertifikatsmanagement.

Im Hinblick auf hochautomatisiertes Fahren und V2X-Kommunikation werden jedoch Vehicle Computer gepaart mit Zonensteuergeräten als zentrale Instanzen künftige E/E-Architekturen prägen und das Fahrzeug wird zu einem Software-dominierten System (siehe Bild 1). Zusätzlich sind deutlich mehr, umfangreichere und unterschiedlichere Applikationen zu integrieren. Die AUTOSAR-Classic Platform stößt hier an ihre Grenzen und wird deswegen um die AUTOSAR Adaptive Platform zu einem neuen zukunftsweisenden Gesamtansatz ergänzt. „Während die Entwicklung konventioneller Steuergeräte hauptsächlich von hohen Echtzeit- und Sicherheitsanforderungen getrieben wurde, stehen heute Aspekte wie Update- und Upgrade-Fähigkeit im Vordergrund. Dazu gehören das dynamische Laden von Software, die Verwendung von Standardbibliotheken zum Beispiel für die Bildanalyse oder die Unterstützung von Machine Learning Algorithmen,“ ergänzte Reichart.

Im Gegensatz zu AUTOSAR Classic basiert AUTOSAR Adaptive (Bild 2) auf einem POSIX-basierten Betriebssystem. Die AUTOSAR Adaptive Platform ermöglicht eine Partitionierung der Software Anwendungsprozesse, um zum Beispiel Anwendungen von unterschiedlichen Zulieferern bzw. unterschiedlicher ASIL-Kritikalität zu integrieren und sicher zu betreiben. Sie bietet somit flexiblere Optionen für zukünftige Fahrzeugarchitekturen. Zonensteuergeräte ermöglichen die zentrale Verbreitung von Informationen und die Bereitstellung von Services, unabhängig von der Sensor- und Aktuatorebene. Auf diese Weise können serviceorientierte Anwendungen entwickelt werden, ohne dass im Voraus definiert werden muss, wie sie letztendlich auf die einzelnen Steuergeräte verteilt werden.

Die Haupteinsatzgebiete der AUTOSAR Adaptive Platform sind:

<ul><li> Hochautomatisiertes Fahren (HAD) und Fahrerassistenzsysteme (ADAS)</li><li> Vernetzung des Fahrzeugs mit seiner Umgebung (V2X) auf Basis der neuesten Security Anforderungen</li><li> Anwendungen mit Over-the-air-Update (OTA)</li></ul>

Entsprechend seiner serviceorientierten Architektur (SOA) und zusätzlichen Features wie etwa Over-the-Air-Updates setzt die AUTOSAR Adaptive Platform auch bei der Automotive Security im Hinblick auf die ISO/SAE 21434 auf zusätzliche Maßnahmen und aktuelle Standards.

„Die AUTOSAR Adaptive Plattform wurde unter Berücksichtigung der Anforderungen serviceorientierter Software-Architekturen entwickelt und legt ihren Schwerpunkt auf Flexibilität. Sie ermöglicht den Entwurf von flexibel strukturierter Steuergeräte-Software, die auch nach der Veröffentlichung noch angepasst werden kann. Damit ist sie ideal für neue Anwendungsbereiche wie das autonome Fahren geeignet,“ erklärte Rinat Asmus, stellvertretender Vorsitzender von AUTOSAR.

Mit dem aktuellen Release wird besonderer Wert auf die die Interoperabilität zwischen den beiden AUTOSAR-Plattformen Classic und Adaptive gelegt. Insbesondere in den Bereichen Security, Safety und Health Management wurden Fortschritte erzielt, um die Interoperabilität im Fahrzeug zu verbessern. Das aktuelle Release bündelt daher gemeinsame Anforderungen und technische Spezifikationen (z. B. Kommunikationsprotokolle), die von den AUTOSAR-Plattformen gemeinsam genutzt werden, in der AUTOSAR Foundation. Bild 3 zeigt die Neuerung der aktuellen AUTOSAR Release R20–11.

Das AUTOSAR Release R20–11 wird auf der AUTOSAR Webseite (<a href="http://www.autosar.org" target="_blank">www.autosar.org</a>) zur Information bereitgestellt. Weitere Details können Sie den plattformspezifischen „Release Overview“ Dokumenten entnehmen.

Die AUTOSAR Classic Platform und Adaptive Platform ergänzen sich gegenseitig: Die Classic Platform ist auf effiziente, tief eingebettete Funktionen der klassischen Automobilbereiche spezialisiert, während die Adaptive Platform auf die sich schnell entwickelnde Domäne des hochautomatisierten Fahrens abzielt, mit all der Flexibilität, die dieser Bereich erfordert.

OTA-Updates, zunehmend abstrahierte und leistungsfähige E/E-Plattformen und Cloud/Edge-Lösungen ermöglichen neue Geschäfts- und Kundenbindungsmodelle. Der Weg zu solch intelligent vernetzten Fahrzeugen führt über die AUTOSAR Adaptive Platform. Sie hält Funktionen bereit, die sich schon heute in die E/E-Architekturen von morgen integrieren lassen.

Die AUTOSAR Adaptive Platform bietet die Freiheitsgrade für neue E/E-Architekturen. In intelligent vernetzten, hochautomatisierten Fahrzeugen werden leistungsfähige Vehicle Computer und Zonensteuergeräte dominieren.

Unter dem Motto „Herausforderungen der Automobilsoftware mit Hilfe von AUTOSAR bewältigen“ hat die AUTOSAR Entwicklungspartnerschaft zudem die nächste virtuelle AUTOSAR Open Conference im März 2021 angekündigt. Die Veranstaltung wird sich auf die Anwendung der AUTOSAR-Plattformen mit Beispielen aus der Serienentwicklung, die Kommunikation und Vernetzung zwischen den AUTOSAR-Plattformen sowie funktionale Sicherheit und Automotive Security-Aspekte fokussieren.

<a href="http://www.autosar.org">www.autosar.org</a>

Bild 1: Steigende Funktionsvielfalt und Vernetzung bringen herkömmliche verteilte E/E-Architekturen mit bis zu 100 und mehr Steuergeräten an die Grenzen hinsichtlich Komplexität und Leistungsfähigkeit.

Bild 2: Drei Säulen sind die Voraussetzung für ADAS-Anwendungen. Die Adaptive Platform vermeidet die Nachteile einer fest definierten Kommunikation durch die Implementierung einer serviceorientierten Kommunikationsarchitektur und ist unabhängig von den eigentlichen Anwendungen. Die Kommunikation wird zwischen allen Anwendungen hergestellt, die den Service benötigen.

Bild 3: Die neuen Features und Verbesserungen des AUTOSAR Release R20–11.