Fahrzeugnetzwerk Neue Herausforderungen für Autosar »ir ...· Trend-Guide Automotive 2019 13 Fahrzeugnetzwerk page 1
Fahrzeugnetzwerk Neue Herausforderungen für Autosar »ir ...· Trend-Guide Automotive 2019 13 Fahrzeugnetzwerk page 2
Fahrzeugnetzwerk Neue Herausforderungen für Autosar »ir ...· Trend-Guide Automotive 2019 13 Fahrzeugnetzwerk page 3

Fahrzeugnetzwerk Neue Herausforderungen für Autosar »ir ...· Trend-Guide Automotive 2019 13 Fahrzeugnetzwerk

  • View
    212

  • Download
    0

Embed Size (px)

Text of Fahrzeugnetzwerk Neue Herausforderungen für Autosar »ir ...· Trend-Guide Automotive 2019 13...

  • 13Trend-Guide Automotive 2019 www.markt-technik.de

    Fahrzeugnetzwerk

    Neue Herausforderungen für Autosar

    » Wir spielen nach den Automotive-Regeln«

    Autosar soll die Entwicklung von Fahrzeugen mit vielen Steuergeräten erleichtern. Doch welche Rolle wird der Standard zukünftig bei einer zentralisierten Bordnetz architektur und angesichts der Konkurrenz von Android oder Linux spielen? Darüber haben wir mit Dr. Günther Heling, Leiter Embedded Software und Systeme bei Vector, gesprochen.

    Markt&Technik: Herr Dr. Heling, Autosar wurde vor über 15 Jahren eingeführt. Wie weit konnte sich der Standard in der Au- tomobilbranche mittlerweile durchset- zen? Dr. Günther Heling: Bis Ende 2018 hat Autosar in der Classic-Variante weltweit eine Markt- durchdringung von über 70 Prozent erreicht. Dabei gibt es regionale Unterschiede: In Deutschland sind alle OEMs dabei. In Europa ist der Marktanteil ebenfalls hoch; Asien und die USA folgen mit einem gewissen zeitlichen Versatz. Auch die neuen Automobilhersteller in China setzen überwiegend auf Autosar.

    Wieviel Luft nach oben sehen Sie noch? OEMs steigen typischerweise um, wenn sie eine neue Fahrzeugplattform auflegen. Das passiert im Schnitt so alle sieben Jahre. Von daher erwarte ich durchaus noch Zuwächse. Eine hundertprozentige Durchdringung wird Autosar allerdings nie erreichen. Und zwar aus einem einfachen Grund: Manche Steuergerä- te – wie etwa kleine LIN-Knoten – besitzen eine so geringe Rechenleistung, dass Autosar dort nicht passend ist. Dagegen ist im Body- Bereich die Verbreitung sehr hoch, weil dort eine Vielzahl von Steuergeräten von unter- schiedlichen Lieferanten zum Einsatz kommt. In solchen Fällen ist eine Standardisierung durch Autosar besonders sinnvoll. In dem von mir verantworteten Bereich Embedded Soft- ware und Systeme sind wir zurzeit bei rund 1000 Steuergeräte-Projekten im Jahr ange- kommen – und wir wachsen weiter.

    Seit Anfang 2017 gibt es neben Autosar Classic auch die flexibel erweiterbare Adaptive-Variante. Wird es bei einer pa- rallelen Nutzung der beiden Standards bleiben oder ist für die Zukunft mit ei- ner vereinheitlichten Version zu rech- nen?

    Die Flexibilität, Dynamik und Service-Orien- tierung von Autosar Adaptive hat viele Vor- teile, aber sie hat auch einen Preis: Man braucht eine deutlich leistungsfähigere Hard- ware und mehr Speicherplatz. Mit Classic er- reiche ich dagegen maximale Effizienz, da bei Classic ein System entsteht, das aufgrund sei- ner statischen Konfiguration hochgradig op- timiert werden kann. Selbst wenn ich pro Steuergerät für Adaptive nur einen Euro mehr investieren müsste, tut das bei 80 und mehr ECUs schon weh. Hinzu kommt, dass eine ser- viceorientierte Kommunikation erst über eine Ethernet-Verbindung wirklich sinnvoll ist. Die- se Voraussetzung erfüllen vor allem kleinere Steuergeräte nicht. Daher ist die Aufteilung von Autosar in Classic und Adaptive sinnvoll.

    Bei der aktuellen Fahrzeug-Generation machen Ethernet-Verbindungen nur ei- nen kleinen Teil des Bordnetzes aus. Mit der Einführung einer günstigen 10-Mbit/s-Variante könnte sich dies je- doch deutlich ändern. Eine stärkere Verbreitung von Ethernet – und damit auch von servicebasierter Kommunika- tion – im Fahrzeugnetzwerk vereinfacht zu- nächst einmal die Systembeschreibung. Das bedeutet aber nicht, dass dann auf jedem ein- zelnen Knoten Adaptive laufen muss. Es lassen sich nämlich auch Classic-Steuergeräte in eine servicebasierte Kommunikation einbin- den. Die OEMs können so auf der Systemebe- ne einen Service festlegen, ohne sich darum kümmern zu müssen, wie er von welchen Steuergeräten realisiert wird. Auf bestimmten Steuergeräteklassen wird mit Sicherheit noch lange Classic laufen – eine Fensterhebersteu- erung etwa geht typischerweise so auf den Schrottplatz, wie sie in die Serie gestartet ist. Da besteht einfach kein Bedarf für nachträg- liche Funktions-Updates. Wir gehen im Übri- gen davon aus, dass auch künftig CAN und LIN

    Dr. Günther Heling, Vector„Der Übergang zu zentralisierten Rechnern ist

    letztlich nur eine Fortführung der Autosar-Idee auf einem

    höheren Abstraktionslevel.“

  • Trend-Guide Automotive 2019 www.markt-technik.de 14

    Fahrzeugnetzwerk

    in Verbindung mit signalbasierter Kommuni- kation eine wesentliche Rolle in der Vernet- zung spielen werden.

    Die gesamte Fahrzeugarchitektur steht vor großen Veränderungen – von einer Vielzahl einzelner Steuergeräte hin zu einem Domänen-basierten Netzwerk bzw. sogar einer echten Server-Struktur mit wenigen Großrechnern im Auto. Was bedeutet diese Entwicklung für Autosar? Bei den Zentralrechnern, die wir als „Vehicle Brains“ bezeichnen, wird auf jeden Fall Adap- tive zum Einsatz kommen. Ebenso bei den Do-

    mänen-Steuergeräten bzw. Zonenintegrato- ren, die für einen bestimmten Fahrzeugbereich die benötigten Funktionen zusammenfassen. Anders sieht das bei intelligenten Sensoren und Aktoren aus. Dort wird wahrscheinlich weiterhin Classic laufen. Der Gedanke, sich bei der Funktionsentwicklung weitgehend von der Rechner-Hardware zu lösen, gehörte immer schon zu Autosar. Der Übergang zu zentrali- sierten Rechnern, die ihre Ressourcen nahezu beliebig auf unterschiedliche Aufgaben ver- teilen können, ist letztlich nur eine Fortfüh- rung dieser Idee auf einem noch höheren Ab- straktions-Level.

    Beim konkreten Designprozess dürfte sich der Wechsel zu einer zentralisier- ten Netzwerkarchitektur aber schon be- merkbar machen. Mit den Änderungen im Bordnetz geht auch eine Verlagerung von Zuständigkeiten einher. Bei den Zentralrechnern werden die OEMs die Verantwortung an sich ziehen, weil dort die wirklich wettbewerbsdifferenzierenden Ent- wicklungen stattfinden. Dass Tier-Ones – wie heute bei vielen Steuergeräten üblich – kom- plette Systeme zuliefern, wird bei den Vehi cle Brains so nicht mehr die Regel sein. Darüber hinaus müssen auch die Entwicklungswerk- zeuge den neuen Strukturen angepasst wer- den. Ein Tool wie beispielsweise CANoe ist ja bislang vor allem für die Analyse des Netz- werks ausgelegt. Wenn die relevanten Inter- aktionen zukünftig aber überwiegend inner- halb eines zentralen Steuerrechners stattfinden, dann müssen die Entwickler tiefer in ein solches System hineinschauen können. Daran arbeiten wir gerade.

    Speziell im Infotainment-Bereich fassen zunehmend auch Linux- oder Android- Systeme Fuß. Entsteht da eine neue Kon- kurrenz für Autosar? Wir sehen Systeme im Markt, die gut gepflegt sind und umfangreiche Libraries für Infotain- ment-Anwendungen mitbringen. Doch da hal- ten wir uns raus: Die Entwicklung solcher Bi- bliotheken ist definitiv nicht unser Ziel. Wir setzen stattdessen auf eine Kombination bei- der Welten – also Linux/Android und Autosar Adaptive. Dazu kommt in den entsprechenden Steuergeräten ein Hypervisor zum Einsatz, der im Prinzip beliebig viele Partitionen mit un- terschiedlichsten Sicherheits-Leveln anlegen

    „Anders als Linux oder Android ist Autosar von OEMs und Zulieferern

    für OEMs und Zulieferer gemacht.“

    Die 2003 u.a. von BMW, Bosch, Continental, Daimler und Volkswagen gegründete Entwicklungspartnerschaft Autosar (Automotive Open System Architecture) hat das Ziel, die Erstellung von Steuergeräte- Software durch einen gleichnamigen offenen Industriestandard zu vereinfachen. Autosar in der zuerst entwickelten Classic-Variante be- steht im Wesentlichen aus drei Schichten: einer Basissoftware, einer Laufzeitumgebung für den Informationsaustausch sowie einer größ- tenteils Hardware-unabhängigen Anwendungsschicht. Diese Auftei- lung hat den Vorteil, dass sich auf der Anwendungsebene wiederver- wendbare Softwarekomponenten definieren lassen, die in ganz unterschiedlichen Fahrzeugen und Modellen zum Einsatz kommen können. Aus den im Entwicklungsprozess erstellten Softwarekompo- nenten erzeugen dann Code-Generatoren automatisch eine Steuer- geräte-spezifische Version von Basissoftware und Laufzeitumgebung. Die Classic-Plattform ist für Echtzeit-Steuergeräte auf Osek-Basis

    konzipiert, der Informationsaustausch erfolgt hier vornehmlich sig- nalbasiert. Dynamische Änderungen der Softwarekomponenten wäh- rend der Laufzeit sind nicht möglich.

    Um auch nach Fertigstellung des Steuergerätes noch Softwarefunk- tionen hinzufügen oder ändern zu können, wurde Anfang 2017 die Autosar-Adaptive-Plattform veröffentlicht. Diese setzt auf ein Po- six-Betriebssystem sowie eine servicebasierte Kommunikation. Ap- plikationen stellen ihre Funktionalität als Service zur Verfügung oder verwenden ihrerseits angebotene Services. Entsprechende In- formationen werden dabei über Ethernet-Verbindungen ausge- tauscht. Auf der Service-Ebene lassen sich Funktionen dynamisch hinzufügen oder modifizieren, die Umsetzung auf die jeweilige Hardware-Plattform bzw. Fahrzeugarchitektur übernimmt die Ad- aptive-Plattform. (ku)

    Autosar Classic und Autosar Adaptive

    Bi ld

    : t em

    p- 64

    GT X/

    st oc

    k. ad

    ob e.

    co m

  • Trend-Guide Automotive 2019 www.markt-technik.de

    Rosenberger_TG04_Automotive.pdf;S: 1;Format:(112.00 x 297.00 mm);15.Apr 2019 15:37:57

    Fahrzeugnetzwerk

    kann. Da läuft dann etwa fürs Infotainment ein Linux-System auf einer Partition, doch für die sicherheitsrelevanten Funktionen ist Au- tosar zuständig. Nach unseren Beobachtun- gen sind die OEMs bei einem so starken Part- ner wie etwa Google im Fall von Android vorsichtig. Infotainment-Anwendungen sind da eher unkritisch, aber die Kernfunktionen möchte man nicht aus der Hand

Recommended

View more >