Laut einem aktuellen Bericht des McKinsey Global Institute könnte Künstliche Intelligenz bis 2030 etwa 13 Billionen Dollar zur globalen Wirtschaftsleistung beitragen.

Laut einem aktuellen Bericht des McKinsey Global Institute könnte Künstliche Intelligenz bis 2030 etwa 13 Billionen Dollar zur globalen Wirtschaftsleistung beitragen. Dies entspricht einem zusätzlichen jährlichen Wachstum von 1,2 Prozent des weltweiten BIP und wäre deutlich mehr als das Wachstum von 0,3 Prozent, das die Dampfmaschine mit sich brachte und damals den Beginn der industriellen Revolution einläutete.

Trotz all dieses Potenzials steckt Künstliche Intelligenz noch in den Kinderschuhen. Es gibt viele Gründe, warum Unternehmen Schwierigkeiten mit der Nutzung von KI haben können. Grundsätzlich lässt sich sagen, dass sich zu viele Mitwirkende nur auf die KI-Algorithmen konzentrieren. Vielmehr gibt es drei weitere Anforderungen (oder drei weitere Is, wenn Sie so wollen), um mit künstlicher Intelligenz erfolgreich zu sein: Erstens Expertenwissen einbringen, zweitens das gesamte System betrachten und drittens die Zusammenarbeit mit anderen Systemen und Menschen.

 Im ersten Fall geht es um das, was Ingenieure und Wissenschaftler in die KI einbringen, nicht das, was die KI ihnen bringt. Bei der Entwicklung einer KI ist es wichtig, dass die Tools, die man dabei nutzt, diese Erkenntnisse als einen integralen Bestandteil der Lösung einbeziehen. Zum Beispiel, indem es Daten herausfiltert, Pole und Nullstellen der Systemmodelle betrachtet und nichtlineare Optimierungen durchführt, sodass solide und sinnvolle Daten in den KI-Algorithmus eingehen und herauskommen.

Zweitens muss die Implementierung das gesamte System umfassen, nicht nur die KI-Komponente. Für Forscher bedeutet das, dass man Tests durchführen, Daten analysieren und Berichte verfassen muss. Baut man ein Auto, geht es mehr um die Erfassung von Anforderungen, Modellierung und Simulation sowie Verifizierung und Validierung. Erstellt man ein System zur Optimierung von Prozessen, geht es darum, alle notwendigen Daten zu streamen und zu konsolidieren, die KI mit Optimierungs- und Steuerungsfunktionen zu verbinden und damit die Steuerungssysteme zu betreiben.

Die dritte Anforderung – Interaktion – ist es, sicherzustellen, dass KI effektiv mit der Umgebung und komplexen menschlichen Arbeitsabläufen interagiert. Zum Beispiel kann KI in einem Auto Unfälle vermeiden, muss dies aber möglichst unmerklich tun, um sicherzustellen, dass die Fahrer trotz der automatisierten Eingriffe ein angenehmes Fahrerlebnis haben.

Erfolgreiche KI-Anwendungen erfordern daher mehr als nur die Entwicklung und Nutzung intelligenter Algorithmen. Mit diesem Ansatz bringt die Anwendung von KI viele Vorteile für die Lösung verschiedenster Problemstellungen – auch für die Umsetzung eigener Projekte.

Editorial Gast

Kommunikationstechnik und Hardware aus dem IT- und Mobilfunk-Bereich halten Einzug ins Automobil. Vehicle Computer auf Mikroprozessorbasis und externe Speicher sowie Gigabit Ethernet und drahtloser Datenaustausch mit Backends  und Cloud-Services erfordern neuartige E/E-Architekturen. Treiber sind die Megatrends Vernetzung, Elektrifizierung und Autonomes Fahren. Für Anbieter von  Automotive Software wird es höchste Zeit, sich auf diesen Umbruch vorzubereiten. Lösungen stehen bereit.

Im Automobil erfordern Vehicle Computer auf Mikroprozessorbasis und externe Speicher sowie Gigabit Ethernet und drahtloser Datenaustausch mit Backends und Cloud-Services neuartige E/E-Architekturen. Lösungen stehen bereit.

Aktuelle Megatrends bringen heutige E/E-Architekturen an ihre Grenzen. Ist das automatisierte Fahren mit über 120 im Fahrzeug verteilten Steuergeräten (ECUs) machbar, deren spezifisch für die Hardware entwickelte Software sich nur mit hohem Aufwand updaten lässt und für jede Fahrzeuggeneration neu programmiert werden muss?

Ist es trotz der stark ansteigenden Komplexität domänenübergreifender Funktionen und trotz begrenzter Computing-Performance möglich, die Kontrolle über Gas, Lenkung und Bremse mit der gebotenen Funktionalen Sicherheit ans Fahrzeug abzugeben? Kann die ECU-Infrastruktur der Vernetzung im Internet of Things (IoT) und mit Cloud-Services schritthalten?

Tatsächlich kommt Bewegung in die E/E-Architekturen. Hardware aus dem IT- und Mobilfunk-Bereich drängt ins Automobil. Vehicle Computer (VC) auf Basis von Mikroprozessoren oder System-on-a-Chip-Architekturen mit mehreren CPU-Kernen und Co-Prozessoren sorgen für stark erhöhte Computing-Performance. Als zentrale Knotenpunkte ergänzen sie die dezentralen, auf Mikrocontrollern basierenden ECUs (Bild 1).

Die Koexistenz zwischen VCs und ECUs ist mit Blick auf die Funktionale Sicherheit geboten. Denn klassische ECUs sind bei strengen Echtzeit-Anforderungen und bei der Überwachung der Kommunikationsabläufe überlegen. In deterministischen Zyklen arbeiten sie Regelungsalgorithmen ab und verarbeiten dabei zeitlich deterministisch wiederkehrende Signale der CAN-, FlexRay- oder LIN-Datenbusse. Damit können Sensoren und Aktuatoren mit hoher zeitlicher Genauigkeit ausgelesen und über effiziente, regelungsbasierte Algorithmen angesteuert werden.

Doch für die großen Zukunftsprojekte braucht es die leistungsfähigen Vehicle Computer (VC), schnellen Datenaustausch über Ethernet-Busse, Zugriff auf externe Speicher – sowie die Option, Software jederzeit over-the-air (OTA) zu aktualisieren. Schon allein, um das vernetzte Fahrzeug mit fortlaufenden Security-Updates gegen unbefugte Zugriffe und Cyberkriminelle abzusichern. Auch wird es auf Basis der Vernetzung möglich, Kunden jene User-Experience zu verschaffen, die sie von ihren Smartphones gewohnt sind. Etwa das nachträgliche Aufspielen von Funktionen aus dem App-Store. Das Fahrzeug wird zum mobilen Device mit Lenkrad und Bremse – und eröffnet dabei neue Umsatzchancen nach dem Start of Production (SoP).

Effektive Entkopplung von Hard- und Software

Vehicle Computer sind der Schlüssel zu dieser neuen Welt. Ihre Leistungsfähigkeit erlaubt es, per Hypervisor mehrere virtuelle Maschinen auf einem Rechner zu partitionieren, auf denen sich Software von verschiedensten Anbietern betreiben lässt. Bei einer entsprechenden Basissoftware ist die strikte Kapselung mit Freedom from Interference gewährleistet.

Theoretisch wäre es möglich, Funktionen auf VCs beliebig zu mischen. Praktisch werden OEMs dort Domänen bündeln, deren Fusion aus physikalischen und algorithmischen Gründen sinnvoll ist. So lassen sich für das automatisierte Fahren Funktionen von Powertrain und Chassis samt Bremse und Lenkung in Softwarepaketen auf VCs fusionieren und dort als softwarebasierte Controller ausführen.

Hintergrund: Entwickler rechnen bei der Umsetzung des automatisierten Fahrens in dreidimensionalen Bewegungstrajektorien. Die Route wird im Abgleich möglicher Trajektorien bestimmt, wobei neben sicherheitsrelevanten Informationen Parameter wie Fahrkomfort oder Energiebedarf einfließen. Die softwarebasierten Controller auf dem VCs könnten die Trajektorien empfangen, analysieren, optimieren und das Resultat in Form von Befehlen an wie auch immer geartete Elektro-, Hybrid- oder Verbrennungsantriebe und an die Chassis-Funktionen übermitteln.

E/E-Architekturen mit VCs ermöglichen es, die historisch gewachsene, mittlerweile störende Trennung der Domänen zu überwinden, indem sie eine zentralisierte Entscheidungsebene in der Fahrzeug-E/E-Architektur hinzufügen. Das senkt die Komplexität, steigert die Flexibilität – und bietet die Basis, um künftig riesige Datenmengen der Radar-, Video- oder Lidar-Umfeldsensorik zusammenzuführen, abzugleichen und im Sinne maximaler Funktionaler Sicherheit zu plausibilisieren.

Rasanter Umbruch durch Vehicle Computer  und AUTOSAR Adaptive

Die verbesserte Möglichkeit der Domänenfusion ist eine wichtige Eigenschaft für zukünftige Fahrzeugfunktionen. Doch das Potenzial der Entkopplung von Software und Hardware geht weit darüber hinaus. Mit AUTOSAR Adaptive entsteht aktuell ein Standard, der als Grundlage die service-orientierte Kommunikation im Fahrzeug manifestiert. Der Übergang zu POSIX-Betriebssystemen, und damit einhergehend dem Übergang von der klassischen C-Programmierung hin zu C++, eröffnet die Nutzung einer Vielzahl von Softwarekomponenten aus Non-Automotive-Bereichen (Bild 2). Beides wird sich massiv auf die Entwicklungsprozesse für Automotive Software und auf die damit verbundene Wertschöpfung auswirken. Agile Entwicklungsmethoden ersetzen das etablierte V-Modell. Anbieter können Software unabhängig von der Hardware entwickeln, über App-Stores von OEMs vertreiben und jederzeit updaten. Letztlich wird auf VCs Software dutzender Anbieter laufen.

Während sich der Umfang von Mikrocontroller-basierter ECU-Software heute um 8 MB bewegt, soll er künftig um ein 10.000-faches auf bis zu 80 GB steigen. Das lockt neue Wettbewerber aus der IT-Branche an. Doch selbst wenn typische Automotive-Player (OEM, TIER-1 und andere Zulieferer) nur noch ein Zehntel der Software liefern, müssen sie wegen des exponentiell wachsenden Gesamtvolumens um ein Vielfaches mehr Code entwickeln, als bisher. Allerdings müssen sie ihre Kompetenzen und Kommunikationsroutinen dafür zügig an die veränderte Systematik anpassen. Unter anderem brauchen sie Geschäftseinheiten für reine Software-Entwicklung – also eine Produktion ohne klassische Fertigungsinfrastruktur.

Einarbeitung in die  AUTOSAR-Adaptive-Methodik kann sofort beginnen

Noch läuft der AUTOSAR-Adaptive-Standardisierungsprozess. Doch es bleibt nicht viel Zeit für die Vorbereitung auf den nahenden Umbruch. Bosch und ETAS haben darum frühzeitig Lösungen entwickelt, mit denen sich Entwickler schon jetzt in die neue Software-Entwicklungsmethodik einarbeiten können. Im Zentrum steht das auf AUTOSAR basierende Basissoftware-Framework RTA-VRTE (Vehicle Runtime Environment), das in ein Early Access Program eingebettet ist. Es greift bisherige Fortschritte der Standardisierung auf und bietet Entwicklern auf dieser Basis Trainings, Beratung sowie ein „Ready to go“ Software Development Kit (SDK). Damit können sie umgehend ins Prototyping für Vehicle-Computer-Architekturen einsteigen.

Das RTA-VRTE-Framework ermöglicht die Integration POSIX-konformer Betriebssysteme. Auf fünf Software-Ebenen sind alle wichtigen Funktionen abgedeckt (Bild 3). Security-Lösungen der ETAS-Tochter ESCRYPT vervollständigen das Angebot.

Effektiv sind die Trainings im Early Access Program auch deshalb, weil die RTA-VRTE auf unterschiedlicher Mikroprozessor-basierter Hardware läuft, sowohl auf Vehicle Computern wie auf handelsüblichen Desktop-PCs. Entsprechende Hardware-Abstraction-Layer machen es möglich. Damit steht einer durchgehenden Virtualisierung der Software-Entwicklung nichts mehr im Weg. Denn Software, die im Fahrzeug auf gekapselten VC-Partitionen – also auf virtuellen Maschinen (VM) – betrieben werden kann, lässt sich nun auf VMs am PC entwickeln, erproben und debuggen. Entwickler können so in die Architekturen und Methoden der Zukunft eintauchen und sich einen Know-how-Vorsprung erarbeiten, der sich bei der Neuverteilung der Wertschöpfung auszahlen wird.

Für die Umsetzung von Vernetzung, Elektrifizierung und automatisiertem Fahren sind neue E/E-Architekturen mit leistungsstarken Vehicle Computern auf Mikroprozessorbasis in Vorbereitung. Da sich diese in virtuelle Maschinen partitionieren lassen, ebnen VCs einerseits Wege zur Domänenfusion. Andererseits erlaubt es die Partitionierung, Software verschiedener ASIL-Sicherheitslevels auf ein- und derselben Hardware zu betreiben. Hierfür und für die Service-orientierte Kommunikation im Fahrzeug schafft der zukünftige Standard AUTOSAR Adaptive ein Regelwerk. Software-Entwicklung kann damit von der Hardware entkoppelt und auf agile Methoden umgestellt werden.

Bosch und ETAS bieten schon heute Werkzeuge für diese neue Methodik an. Herzstück ist das Basissoftware-Framework ETAS RTA-VRTE. Es vereint höchste Funktionale Sicherheit, verlässliche Security und die nötige Flexibilität, um gestützt auf virtualisierte Methoden schon heute Software für das vernetzte Fahrzeug der Zukunft zu entwickeln. In Zukunft dürfte die Vernetzung dazu führen, dass Fahrzeuge besonders rechenintensive Prozesse in die Cloud auslagern, sofern deren ASIL-Level es erlaubt. Es gilt, sich bereits heute den neuen Herausforderungen zu stellen. (oe)

Bild 3: Auf den fünf Schichten des Plattformsoftware-Frameworks RTA-VRTE können Funktionen sicher und flexibel aufgesetzt werden.

Bild 1: Die E/E-Architekturen im Fahrzeug werden sich rasant ändern, um den neuen Megatrends gerecht zu werden.

Bild 2: AUTOSAR Adaptive ist ein wichtiges Bindeglied zwischen AUTOSAR Classic für harte Echtzeitanforderungen und Software-Architekturen aus dem Infotainment.

16:9

Hauptartikel

Dr. Detlef Zerfowski ist Vice President Vehicle Computer und Security bei ETAS.

Dr. Nigel Tracey ist Vice President RTA Solutions und General Manager der ETAS Ltd in York.

Sicherheit für assistiertes  und Autonomes Fahren

Die Europäische Union macht weiter Druck bei der flächendeckenden Senkung der Unfallzahlen. Neue obligatorische Assistenzsysteme ab 2022 fordern OEMs  und Zulieferer heraus, innovative technische Konzepte, Entwicklungsgrundsätze und Sicherheitsprinzipien anzuwenden.

Die Europäische Union macht weiter Druck bei der flächendeckenden Senkung der Unfallzahlen. Obligatorische Assistenzsysteme ab 2022 fordern OEMs und Zulieferer heraus, innovative technische Konzepte anzuwenden.

Im Frühjahr 2019 hat die Europäische Union ein Gesetz auf den Weg gebracht, das ab 2022 einige Assistenzfunktionen in Pkw, Lkw und Bussen als Pflicht vorschreibt. In Pkw zum Beispiel einen Notbremsassistenten, einen intelligenten Geschwindigkeitsbegrenzer, eine Black Box (= Fahrtenschreiber), Rückfahrkameras sowie ein Müdigkeits-Warnsystem und ein Alkoholatemtest als Wegfahrsperre für den Fahrer. Bei Lkw sollen beispielsweise ein Abbiegeassistent als Schutz für andere Verkehrsteilnehmer sowie Reifendruck-Kontrollsysteme obligatorisch werden. Diese Systeme sollen helfen, die Zahl von bis zu 25.000 Toten pro Jahr im Straßenverkehr deutlich zu reduzieren.

Für die Autokäufer bedeutet dies zunächst höhere Kosten. So hat die amerikanische Verkehrssicherheitsbehörde NHTSA ausgerechnet, dass die Gesamtkosten für alle Komponenten wie Kamera, Steuergeräte, Konstruktion und Entwicklung sowie Werkzeugkosten schätzungsweise 200 bis 250 Euro pro Fahrzeug betragen könnten.

Auch bei Aptiv geht man von einem dreistelligen Betrag aus. „Viele dieser zukünftigen Pflicht-Systeme sind allerdings heute schon in Serie – meist in Premium-Fahrzeugen. Die EU-Verordnung sorgt für einen regelrechten Demokratisierungsschub dieser Techniken in die preissensiblen Volumensegmente hinein“, gibt David Paja, Senior Vice President und President of Advanced Safety & User Experience bei Aptiv, zu bedenken.

Um die volumenstarken Fahrzeugsegmente zu erschließen, setzt Aptiv auf eine sogenannte Satellitenarchitektur, ein neuartiges Konzept für die E/E-Architektur (Bild 1). Statt wie bisher in jedem Sensor einen Signalverarbeitungsprozessor zu integrieren, nutzt Aptiv einen leistungsfähigen Domänenrechner, der alle Rohdaten der Sensoren zentral verarbeitet.

Dies soll gleich mehrere Vorteile haben: Erstens werden die Sensoren ohne Rechenintelligenz deutlich kleiner, leichter und kostengünstiger. Zweitens entstehen für das Gesamtsystem geringere Gesamtkosten und die Reparaturkosten für Sensoren bleiben im Rahmen. Drittens lassen sich aus der zentralen Verarbeitung der Rohdaten qualitativ bessere Erkenntnisse gewinnen. Viertens ist der Satellitenansatz sehr gut skalierbar, um beispielsweise für Volumenmodelle Assistenzsysteme bis zum SAE Level 2+ darzustellen. In diesem Fall werden weniger und einfachere Sensoren verwendet und eine kostenoptimierte Prozessoreinheit mit etwas weniger Rechenleistung. Diesen Ansatz werden laut Aptiv ab 2020 mehrere Volumenhersteller in ihre Fahrzeuge integrieren.

Für Audi hat Aptiv bereits ein sehr leistungsfähiges Domänensteuergerät entwickelt, das für automatisierte Fahrfunktionen nach SAE Level 3 ausgelegt ist. Ein solch leistungsfähiges High-End-Steuergerät kann zum Beispiel auch Fahrer- und Innenraum-Monitoringsysteme darstellen, die Aptiv in den letzten Jahren mit einem anderen Kunden entwickelt hat und die in der EU-Vorgabe für 2022 ebenfalls eine wichtige Rolle spielen.

Die Entwicklungspartnerschaft mit Audi für ein zentrales Fahrerassistenz-Steuergerät habe laut David Paja auch gezeigt, dass eine sehr enge Zusammenarbeit unabdingbar sei. „Für die Entwicklung des Domänenrechners und der Sensoren trugen insgesamt mehr als 20 Entwicklungspartner Systemverantwortung. Angesichts der immer komplexeren Technologien wird die Zusammenarbeit zwischen OEMs und Lieferanten in den nächsten Jahren noch weiter intensiviert werden.“

Aptiv sieht sich als eines von wenigen Unternehmen, das solche komplexe Systementwicklungen umfassend unterstützen und koordinieren kann. So hat das Unternehmen in den letzten Jahren seine Kompetenz bei Künstlicher Intelligenz, Datenfusion, funktionaler Sicherheit und Cybersicherheit gestärkt. Beispielsweise hat man die Start-Ups Ottomatika und Nutonomy gekauft, die Softwarealgorithmen für autonome Fahrfunktionen nach SAE Level 4 und 5 entwickeln.

Zusätzlich hat Aptiv mit zehn führenden OEMs und Lieferanten ein umfangreiches Whitepaper erstellt, das einen Orientierungsrahmen für die Entwicklung, den Test und die Validierung von sicheren automatisierten Personenkraftfahrzeugen bieten soll. Der Leitfaden namens „Safety First for Automated Driving“ bündelt als Gesamtschau die in vielen Publikationen bisher veröffentlichten Einzelthemen des automatisierten Fahrens. So werden erstmals die bestehenden Verifizierungs- und Validierungs-Methoden bei automatisierten Fahrzeugen nach SAE Level 3 und 4 zusammengefasst. „Aptiv hat sich als Gründungsmitglied dieser Initiative bei zahlreichen Themenbereichen wie Systemsicherheit, Validierung und Cybersicherheit eingebracht“, berichtet Glen de Vos, Vizepräsident und CTO von Aptiv. „Wir sehen das Whitepaper als lebenden Organismus und würden die Mitarbeit weiterer Unternehmen an diesem Zukunftsthema sehr begrüßen.“

Als Kern dieses Whitepapers beschreiben die beteiligten Unternehmen zwölf Grundprinzipien, welche die Eigenschaften automatisierter Fahrzeuge weitgehend definieren. Beispiele sind die Systemgrenzen des automatisierten Fahrens samt Risikominimierungs-Szenarien, die Übergabeszenarien zwischen System und Fahrer, die Funktionale Sicherheit und Cybersicherheit, die genaue Validierung der Systeme, das rechtskonforme Datenmanagement oder die Interaktion mit passiven Sicherheitssystemen. Ein übergeordnetes Ziel bei den Risikobewertungen ist, dass ein automatisiert fahrendes Fahrzeug über alle Situationen hinweg sicherer als ein durchschnittlicher menschlicher Fahrer agiert.

„Es wird noch dauern, bis all diese Aspekte rechtssicher in Normen und Standards gegossen sind“, so Glen de Vos. „Wir alle finden es wichtig, dass wir uns vorab auf global praktikable Kriterien für den Test und die Validierung von automatisierten Fahrfunktionen verständigen. Diese Kriterien finden dann hoffentlich auch bei anderen Unternehmen Anwendung und werden sich zu Standards weiterentwickeln.“ (oe)

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

Bild 1: Konzept für eine Satellitenarchitektur bis SAE Level 2+.

Moderne E/E-Architekturen müssen skalierbar sein.

Hartmut Hammer ist freier Mitarbeiter der Hanser automotive.

»Es ist wie beim Henne-Ei-Problem: Sie können  nicht auf Standards warten, und dann anfangen zu entwickeln. Erst muss sich aus dem Zusammenspiel  von Gesetzgebern und Industrieunternehmen ein breit akzeptierter technischer Quasi-Standard etablieren.«

Glen de Vos, Vizepräsident und CTO von Aptiv.

Fahrzeuge entwickeln sich immer stärker zu Computernetzwerken, um zukünftig Autonomes Fahren zu ermöglichen. Mit Adaptive AUTOSAR kommen jetzt auch moderne Service-orientierte Software-Architekturen ins Fahrzeug.

Grundsätzlich soll mit Service-orientierten Architekturen (SOA) die Strukturierung und Nutzung verteilter Funktionalitäten im Fahrzeug ermöglicht und erleichtert werden. Statt der bisherigen statischen Bindung von Funktionen in einer Applikation (Apps) werden in Zukunft viele Funktionen der Apps erst beim Start miteinander verknüpft. Diese Service-orientierten Architekturen sind in der IT-Welt nichts Neues, aber wie funktionieren sie in Embedded-Systemen im Fahrzeug?

Nach dem Einschalten des Fahrzeugs fahren die angeschlossenen Steuergeräte hoch und die dabei startenden Applikationen bieten ihre Services den Clients zur Nutzung an. Diese Services besitzen eine Versionsnummer, um hier die Kompatibilität zwischen verschieden Version sicherzustellen. Mit „Find Service“ können auch die Clients gezielt nach einem Service suchen, wenn der aktuelle Zustand nicht bekannt ist. Dadurch können sich die Kommunikationspartner zur Laufzeit in einem Netzwerk finden, ohne dass hier eine statische Konfiguration vorhanden sein muss. Weitere Applikationen, die neue Services anbieten oder Vorhandene benutzen, können auch nach der Produktion des Fahrzeugs einfach ergänzt werden. Letztlich erreicht man in Fahrzeugen ähnliche Möglichkeiten, wie sie Apps schon heute z. B. bei Smartphones bieten. Die Services selbst können auf drei Arten benutzt werden:

<ul><li> „Fire und Forget“ – hier sendet der Client Daten an den Server und wartet nicht auf das Ergebnis. Das kann zum Beispiel eine neue Stellgröße für einen Temperaturregler sein.</li><li> „Request und Response“ – hier sendet der Client Daten an den Server und erhält dann das Ergebnis als Antwort zurück. Ein Beispiel wäre das schrittweise Inkrementieren eines Stellwerts und das Zurücksenden des sich dadurch ergebenden neuen Stellwertes.</li><li>„Event“ – hier sendet der Server selbständig Informationen an einen Client, der sich zuvor registriert hat. Ein Beispiel wäre das zyklische Senden des aktuellen Messwertes der Temperatur an eine Anzeige.</li></ul>

Beendet sich ein Server, auch während des laufenden Betriebs, so teilt er dieses den Clients durch das Senden eines Broadcast „Stop Offer Service“ mit. Die Clients können daraufhin ihrerseits entsprechend reagieren.

Die Ziele der Service-orientierten Software-Architekturen entsprechen denen in der IT: So soll damit die langfristige Senkung von Kosten in der Entwicklung von Fahrzeugapplikationen erreicht werden. Die höhere Flexibilität dieser Fahrzeugapplikation ermöglicht die Wiederverwendung bestehender Services in verschiedenen Steuergeräten und unterschiedlichen Fahrzeugen. Dies ist notwendig, um die komplexere Software, welche für Autonomes Fahren entwickelt wird, in die Fahrzeuge integrieren und später warten zu können. (oe)

Grundlegende Kommunikation zwischen Apps. (© KPIT)

Hauptartiklel

Bernhard Wagner ist Diagnostics Subject Matter Expert bei KPIT Technologies.

Das Autonome Fahren erweist sich komplexer als vor Jahren noch gedacht. Dr. Sebastian Buck, als Bereichsleiter der ITK Engineering GmbH unter anderem für das Thema Autonomes Fahren verantwortlich, erläutert, welchen Beitrag ITK Engineering leistet, automatisierte Fahrfunktionen sicher auf die Straße zu bringen.

Dr. Sebastian Buck, als Bereichsleiter der ITK Engineering GmbH unter anderem für das Thema Autonomes Fahren verantwortlich, erläutert, welchen Beitrag ITK Engineering leistet, automatisierte Fahrfunktionen sicher auf die Straße zu bringen.

Welche Lösungen bietet ITK seinen Kunden für das automatisierte Fahren an?

Sebastian Buck: Wir liefern bekanntlich keine Produkte, sondern verstehen uns als unabhängiger Lösungs- und Systemlieferant. Wir entwickeln für unsere Kunden einerseits maßgeschneiderte Software, können aber auch ein Gesamtsystem mit Hardware und Software liefern.

Am Anfang steht dabei die Beratung des Kunden: Welche Hard- und Software-Architektur benötigt er, wie lassen sich Funktionale Sicherheit und Cybersecurity gewährleisten? Weiter geht es mit dem oben erwähnten ganzheitlichen Umfeldmodell und den Fahrfunktionen. ITK verfolgt dabei eine Frontloading-Strategie auf der linken Seite des V-Modells.

Dort haben wir frühzeitig Aufgaben wie die Absicherung und Freigabe der Fahrfunktionen im Auge, um in späteren Entwicklungsphasen den Aufwand und die Komplexität zu begrenzen. Da ITK Engineering seit mehreren Jahrzehnten Erfahrungen in der Automobilbranche gesammelt hat, ebenso wie bei Trendthemen wie Computer Vision und KI, verfügen wir über einen breites Kompetenzportfolio.

Welche Ansprüche stellt das automatisierte Fahren an die Hard- und Software?

Die für Level 3 bis 5 erforderliche Rechenleistung ist bis zu tausendmal höher als bei einem üblichen Automotive-Steuergerät. Allerdings müssen diese Prozessoren in einer sehr rauen Umgebung hundertprozentig zuverlässig sein. Neben dieser Funktionalen Sicherheit ist ein sehr hohes Maß an Cybersecurity erforderlich, die Hackerangriffe sofort erkennt und im Keim erstickt. Die Algorithmen zur Bildverarbeitung und KI sind schon lange bekannt und werden von uns geschickt eingesetzt. Das Herausfordernde ist die Integration all dieser Bausteine in ein absolut zuverlässiges, komplexes Gesamtsystem.

Welche Herausforderungen stellt die Sensorfusion an ITK?

Wir müssen aus den verschiedenen Wahrnehmungen der Sensoren ein möglichst konsistentes Umfeldmodell erzeugen. Die Sensortechniken (Kamera, Radar, Lidar, Ultraschall, auch Infrarot u. a.) und Fusionsalgorithmen dazu sind gut bekannt. Hier besteht die Kunst darin, in einem komplexen Gesamtsystem ein widerspruchsfreies Umfeldmodell zu erzeugen.

Sind für die großen Datenströme auch andere Datenüberträger erforderlich?

Nicht nur neue Datenübertragungstechniken, sondern komplett neue E/E-Architekturen mit hochintegrierten und extrem schnellen Großrechnern. Dieser Paradigmenwechsel geht mit schnellen Datenbussen, hohen Bandbreiten, sehr gut gesicherten Schnittstellen und dem neuen Mobilfunkstandard 5G einher – so letzterer denn schnell und flächendeckend kommt.

Wer sind denn die ITK-Kunden beim automatisierten Fahren?

Einerseits die klassischen OEMs, andererseits Start-ups mit guten Ideen für Fahrfunktionen oder Geschäftsmodelle, aber bisher noch geringem Automotive-Know-how. Auch unseren Mutterkonzern Bosch unterstützen wir natürlich bei seinen Projekten zum automatisierten Fahren.

Wieviel Mitarbeiter arbeiten an Projekten zum Autonomen Fahren?

Bei ITK Engineering arbeiten inzwischen etwa 200 Personen in diesem Themenfeld. Um neue Aufgaben anzugehen, wollen wir die Belegschaft deutlich ausbauen.

Wie sehen Sie mittelfristig die Entwicklung des automatisierten Fahrens?

Aktuell erkennt man, dass die früheren Zeithorizonte etwas zu optimistisch waren. Etliche Herausforderungen sind doch komplexer als angenommen – etwa die Funktionale Sicherheit. Die OEMs können automatisierte Fahrfunktionen nur in Serie bringen, wenn sie höchste Sicherheitsstandards zuverlässig erfüllen. Zusätzlich hinken die Gesetzgebung und Homologation der Systeme noch etwas dem technischen Fortschritt hinterher.

Wann könnten Level-3-Fahrzeuge in Serie gehen?

Ich rechne frühestens in fünf Jahren damit. Bei Privatfahrzeugen könnte ich mir in Europa den Highway-Piloten vorstellen. Geschäftsmodelle wie Carsharing-Services planen einen vollautomatisierten kommerziellen Personen- und Güterverkehr ab Level 4. Dort engagieren sich etablierte OEMs und ganz neue Mobilitätsplayer, etwa Logistikdienstleister. Aufgrund der aktuellen regulatorischen und politischen Situation in einzelnen Weltregionen werden diese Mobilitätssysteme vermutlich zuerst in Asien oder Nordamerika realisiert.

Was muss bis dahin in der Entwicklung noch geschehen?

Ich sehe zwei Knackpunkte: Erstens die absolut zuverlässige und umfassende Lokalisierung und Umfelderkennung. Da sind wir schon ziemlich weit, beherrschen aber noch nicht alle Verkehrssituationen perfekt. Zweitens bilden Verkehrssituationen ein System mit offenem Kontext, es können theoretisch unendlich viele Einflussfaktoren auftreten. Ich denke dabei nicht nur an Hindernisse wie Baustellen oder herumliegende Reifenteile, sondern auch an verlorene Ladung oder unvorhersehbare Situationen wie zum Beispiel Kühe oder Drohnen auf der Fahrbahn. Diese – zugegeben nicht alltäglichen – Situationen müssen auch in der KI-gestützten Entscheidungsfindung abgebildet werden, ohne dass für solche Situationen im Vorfeld bereits Requirements spezifiziert wurden.

Ist der Hacker nicht immer im Vorteil im Vergleich zum Systementwickler?

Das Thema beginnt schon bei der Funktionalen Sicherheit. Wenn die Sicherheit der Funktionen gewährleistet ist, kann jede Fehlfunktion sofort als Eingriff von außen klassifiziert werden. Dafür verfügt ITK über ein versiertes Expertenteam, das große Erfahrung über typische Schwachstellen hat und auf Kundenwunsch sogar als „Weißer Ritter“ Schwachstellen in den Kundensystemen ausfindig macht. Mit einer Art Virenscanner überwachen wir die Fahrzeuge kontinuierlich auf Angriffe von außen und stellen den Kunden dafür auch sukzessive Updates zur Verfügung.

Wie autonom fährt Ihr Auto. Wie oft nutzen Sie diese Funktionen?

Mein Wagen kann tatsächlich einige Sekunden ohne meine Lenkbewegungen sowie Gas- und Bremsbefehle fahren, aber ich muss heute noch weiterhin alles überwachen. Das ist natürlich noch lange nicht als autonom zu bezeichnen.

Das Interview führte Jürgen Goroncy, freier Mitarbeiter der Hanser automotive.

Von der Beratung bis zur Systemabsicherung, ITK unterstützt den Kunden in allen Projektphasen.

Beim automatisierten Fahren wurden die früheren Zeithorizonte etwas zu optimistisch angenommen.

Dr. Sebastian Buck (45) studierte Informatik an der Universität Karlsruhe (heute KIT) und promovierte an der TU München über das Thema „Experience-Based Control and Coordination of Autonomous Mobile Systems in Dynamic Environments“. 2003 startete er seine Karriere beim Entwicklungspartner ITK Engineering. Dort ist er seit 2012 als Bereichsleiter unter anderem für das Thema Autonomes Fahren verantwortlich.

Um den vollen Sicherheitsvorteil des automatisierten Fahrens auszuschöpfen, müssen automatisierte Fahrsysteme eine sehr hohe Verfügbarkeit haben. Auch die dabei eingesetzten KI-Systeme sind herausfordernd, wenn es um Zuverlässigkeit und Sicherheit geht. Auf dem Branchenevent ELIV 2019 am 16. und 17. Oktober 2019 in Bonn zeigen Experten aktuelle Entwicklungen und Trends rund um diese Themen, die einen Schwerpunkt des Internationalen VDI-Kongresses bilden.

Automatisierte Fahrsysteme müssen eine sehr hohe Verfügbarkeit haben. Das ist auch für die eingesetzten KI-Systeme herausfordernd. Auf dem Internationalen VDI-Kongress ELIV 2019 im Oktober zeigen Experten Entwicklungen und Trends rund um diese Themen.

Die Nutzung Künstlicher Intelligenz im Fahrzeug ist schon heute gang und gäbe. Spracherkennungssysteme beispielsweise wären auf dem heutigen Niveau ohne KI und entsprechende Algorithmen nicht vorstellbar. Komfortfunktionen, Gestensteuerungen für Entertainment und Klimatisierung – vielfältige weitere Anwendungen mit KI-Unterstützung werden folgen. Deutlich herausfordernder sind die Anforderungen an die Zuverlässigkeit, Robustheit und Sicherheit der Systeme, wenn es um das Autonome Fahren von morgen geht.

Aktuelle Entwicklungen, Forschungsprojekte und Trends rund um dieses Thematik bilden einen Schwerpunkt des Internationalen VDI-Kongresses ELIV 2019 vom 16. bis 17. Oktober 2019 in Bonn.

Kooperationsmodelle werden ein wichtiger Weg sein, um den Entwicklungsaufwand für neue, KI-basierte Funktionen leisten zu können. Davon ist Dr. Ulrich Bodenhausen, Vector Consulting Services GmbH, überzeugt. „Die Bereitstellung des Sicherheitsnachweises erfordert eine gemeinschaftliche Anstrengung aller beteiligten Partner“, meint der KI-Experte mit langjähriger Automotive-Erfahrung und verweist auf den im Januar 2019 veröffentlichten Standard SOTIF (Safety of the intended Functionality).

SOTIF deckt den Missbrauch eines Fahrzeugs ab (Beispiel: Das Aufbringen eines Aufklebers auf die Frontscheibe, um die Kamera abzudecken) sowie technische Leistungsbeschränkungen, die zu unerwünschtem, gefährlichem Verhalten des Fahrzeugs führen (Beispiel: Sonnenschein blendet die Frontkamera während der Fahrt auf einer Autobahn). Wie das jeweilige Risiko zu bewerten ist, muss individuell untersucht werden. „SOTIF stellt dafür einen Prozess bereit. Wenn das Risiko als zu hoch eingestuft wird, muss der Anwendungsfall eingeschränkt oder die Funktionalität verbessert werden, also zum Beispiel die Robustheit gegenüber Gegenlicht erhöht werden“, erklärt Dr. Bodenhausen.

Brancheninitiative für gemeinsame Standards

So wie SOTIF Sicherheitsstandards setzt, will eine weitere Brancheninitiative einen Rahmen für Entwicklung, Test und Validierung von sicheren, automatisierten Personenkraftfahrzeugen schaffen. Elf führende Unternehmen aus der Automobilbranche und dem Bereich automatisiertes Fahren haben dazu kürzlich das Dokument „Safety First for Automated Driving“, (SaFAD) veröffentlicht, das auf der ELIV von Dr.-Ing. Christian Knobel, BMW Group (Development Autonomous Driving, Driver Assistance) näher vorgestellt wird. Die beteiligten Unternehmen Aptiv, Audi, Baidu, BMW, Continental, Daimler, Fiat Chrysler Automobiles, HERE, Infineon, Intel und Volkswagen repräsentieren einen weiten Bereich der Industrie.

Das Ziel des SaFAD white papers ist es zu betonen, wie wichtig „safety by design“ zusammen mit Verifizierung und Validierung ist, wenn es darum geht, als Industrie einen Standard für das automatisierte Fahren zu schaffen. Die Grundlage des SaFAD white papers stellen zwölf Grundprinzipien dar, welche weiter verfeinert die Eigenschaften („capabilities“) automatisierter Fahrzeuge definieren sollen.

Neue Fehler-Architekturen für autonome Systeme

Zu den wesentlichen Herausforderungen für Entwickler autonomer Systeme zählt der Aufbau adäquater Fail-Operational-Architekturen. Im Gegensatz zum Fail-Safe-Paradigma, das heute Standard ist und in der Regel für menschlich betriebene Systeme ausreicht, werden Fail-Operational-Architekturen typischerweise viel komplexer und anspruchsvoller sein. Über ein wegweisendes Forschungsprojekt berichten Vertreter des Fraunhofer Institute for Experimental Software Engineering (Fraunhofer IESE), Kaiserslautern.

Um die Fail-Operational-Architektur für jede erdenkliche Situation zu wappnen und damit einen sicheren Betrieb auch unter widrigen Umständen zu gewährleisten, muss zunächst analysiert werden, wie sich kritische Ereignisse auf die Fahrzeugfunktionalitäten auswirken. Dr.-Ing. Rasmus Adler, Programm-Manager „Autonome Systeme“ des Fraunhofer IESE, erläutert dazu: „Man kann drei Klassen von kritischen Ereignissen unterscheiden: Änderungen der systemeigenen Fähigkeiten (zum Beispiel aufgrund von Hardware- oder Software-Fehlern), Änderungen der Umgebungsbedingungen oder Änderungen der Verfügbarkeit oder Qualität von V2X-Daten.“

Im Idealfall werden die Analysen sehr früh im Entwicklungsprozess durchgeführt, um späte Änderungen, die typischerweise kostspielig sind, zu vermeiden. „Zu diesem Zweck ist bereits in einer frühen Phase der Entwicklung eine geeignete Spezifikation der Fail-Operational-Architektur erforderlich. Diese Spezifikation muss alle relevanten Funktionen und ihre jeweiligen Ein- und Ausgänge umfassen“, erläutert Adler weiter.

Der im IESE-Projekt gemeinsam mit Hitachi verwendete komponentenbasierte Modellierungsansatz ermöglicht es, Komponenten zu einer gemeinsamen, hierarchischen Komponente zusammenzufassen. Das reduziert die Zahl der möglichen Konfigurationen – auf die, welche tatsächlich praktisch relevant und wichtig sind. „Da in weiteren Zusammensetzungen nur die hierarchischen Konfigurationen berücksichtigt werden, wird die Komplexität des Designs auf jeder Hierarchieebene signifikant reduziert“, erklärt Dr. Adler. (oe)

<a href="http://www.vdi-wissensforum.de/eliv/eliv-kongress">www.vdi-wissensforum.de/eliv/eliv-kongress</a>

Bearbeitet nach Unterlagen des VDI Wissensforums, Düsseldorf.

Der Kongress ELIV (Electronics In Vehicles) hat sich in den letzten Jahren zu dem wichtigsten Branchentreff für Elektronikexperten entwickelt. Der Austausch zwischen Fahrzeugherstellern und Zulieferern im Rahmen des Kongresses wird mehr und mehr ein »Muss«, um Innovationen, Entwicklungen und Problemstellungen in der Automobilelektronik frühzeitig zu erfassen. Seit vielen Jahren wird während der Veranstaltung nicht nur über diese Themen berichtet, sondern auch Trends gesetzt und für die Automobilindustrie wesentliche Entscheidungsgrundlagen geschaffen. Ergänzend zu den Fachvorträgen können sich Teilnehmer in der begleitenden Fachausstellung bei 145 Zulieferern und weiteren Dienstleistern über neue Produkte und Services informieren.

»In einer frühen Phase der  Entwicklung ist eine geeignete  Spezifikation der Fail-Operational- Architektur erforderlich.«

Dr.-Ing. Rasmus Adler, Programm-Manager  „Autonome Systeme“ des Fraunhofer IESE.

»Die Bereitstellung des Sicherheitsnachweises erfordert eine  gemeinschaftliche Anstrengung aller beteiligten Partner.«

Dr. Ulrich Bodenhausen, Vector Consulting Services GmbH.

Die Self-Healing Software von Aurora Labs nutzt künstliche Intelligenz und Machine Learning, um Fahrzeuge zukunftssicher zu machen. Die Lösung wartet den gesamten Software-Code im Fahrzeug, indem sie Fehler automatisch erkennt, repariert und durch Updates dafür sorgt, Software-Probleme auf Null zu reduzieren. Zudem ist es möglich neue Fahrzeugfunktionen über Over-the-Air-Updates zu implementieren – selbst, wenn das Fahrzeug fährt.

Die Self-Healing Software von Aurora Labs nutzt künstliche Intelligenz und Machine Learning, um Fahrzeuge zukunftssicher zu machen. Sie wartet den gesamten Software-Code im Fahrzeug, führt Updates durch und implementiert neue Fahrzeugfunktionen über Over-the-Air-Updates.

Die Software von Autos wird heute vermehrt per Fernwartung gemanagt und aktualisiert – über sogenannte Over-the-Air-Updates (OTA). Technologien wie Künstliche Intelligenz und Machine Learning haben viele Vorteile für das Management von Automotive-Software. Die Lösung von Aurora Labs, die diese neuen Technologien einsetzt, bettet das eigentliche Update in einen vierstufigen Selbstheilungsprozess ein.

<ul><li>Auto Detect: Zunächst analysiert ein Machine-Learning-Algorithmus die Beziehungen zwischen den Millionen Zeilen von Softwarecode im Fahrzeug. So können Automobilhersteller erkennen, wenn Anomalien im Softwareverhalten auftreten, die auf eine Änderung der Softwarekonfiguration, einen Softwarefehler oder einen Hack hinweisen können. Die selbstheilende Software kann vorhersagen, welche dieser Anomalien zu Problemen werden und zu Systemausfällen führen können (Bild 1).</li><li> Auto Fix: Wird ein Problem identifiziert, setzt die Lösung die betroffene Software nahtlos auf die letzte sichere Version zurück. Im Grunde heilt sich das Auto selbst, was Ausfallzeiten und Fehlfunktionen vorbeugt.</li><li>Auto Update: Als dritter Schritt erfolgt das OTA-Update. Dabei kann entweder eine vollkommen neue Softwareversion aufgespielt oder lediglich eine Delta-Datei oder einzelne Codezeilen aktualisiert werden. Während des gesamten Prozesses entstehen keine Ausfallzeiten und der tägliche Gebrauch des Fahrzeugs wird nicht beeinträchtigt.</li><li>Auto Validate: Zuletzt werden die Struktur, Beziehungen und Abhängigkeiten der Software in Echtzeit überprüft. Ein Algorithmus identifiziert und bildet auf funktionaler Ebene ab, welche Software auf der ECU läuft, welche Code-Zeilen von dem Update betroffen sind und welche Funktionen eine Typgenehmigung benötigen.</li></ul>

Die Self-Healing Software bietet noch weitere Vorteile und Funktionen für innovative OTA-Updates. Durch Machine Learning können moderne OTA-Lösungen selbst einzelne Codezeilen analysieren, um ein Verständnis der Beziehungen und Abhängigkeiten zwischen ihnen zu gewinnen. Das ermöglicht es, die kleinstmögliche Änderung zwischen zwei Codeversionen (die Delta-Update-Datei) zu erstellen und auszuspielen. Da Delta-Dateien viel kleiner sind als herkömmliche Updates, bei denen die gesamte Software aktualisiert wird, werden Speicher- und Energiebedarf sowie der Zeitaufwand minimiert. Darüber hinaus ist es auch möglich, die Software zu analysieren und Anomalien zu identifizieren, während das Auto fährt.

Herkömmliche OTA-Lösungen benötigen fünf speicherintensive Verfahren, um die Software zu aktualisieren:

<ul><li> Das Einlesen von Blöcken aus dem Flash-Speicher in den RAM,</li><li>Ein Patch-Write der Delta-Datei in den RAM,</li><li> Ein Burn-Write der gepatchten Blöcke auf einen redundanten Platz im Speicher,</li><li>Das Löschen des Flash-Speichers,</li><li>Ein Burn-Write des gepatchten Blocks in den richtigen Platz im Flash-Speicher.</li></ul>

Self-Healing Software verwendet eine Standarddatei für eingebettete Systeme. Dadurch entfällt die Verwendung einer proprietären Delta-Datei, die von einem dedizierten Update-Client extrahiert und rekonstruiert werden muss. Stattdessen kann die Software in einem clientlosen Prozess, der keine Ausfallzeiten verursacht, nahtlos in den nächsten freien Speicherplatz gepatcht werden.

Aktuelle OTA-Lösungen benötigen eine proprietäre Client-Software, die in jedes Steuergerät integriert werden muss. Diese benötigen zusätzliche Ressourcen, um eine Delta-Datei zu extrahieren, was sowohl den CPU-Durchsatz als auch den Speicherbedarf beansprucht.

Neue OTA-Lösungen verwenden deshalb Standard-Dateiformate (ELF-Datei, S-Record oder Intel Hex), was zu einer clientlosen Lösung führt, die die verschiedenen internen Netzwerke eines Fahrzeugs sowie unabhängige Computerkomponenten mehrerer Anbieter problemlos unterstützt. So können Automobilhersteller die Lösungen ihrer Lieferanten problemlos integrieren. Herkömmliche OTA-Lösungen erfordern auch, dass das Gerät, auf das ein Update aufgespielt wird, offline genommen, in den Update-Client gebootet, aktualisiert und erst dann mit der aktualisierten Software neu gestartet wird. Dieser Prozess kann bis zu einer Stunde dauern. Die Self-Healing Software hingegen bietet nahtlose Updates, ohne das Fahrzeug offline zu nehmen und ohne zusätzlichen Speicherplatz zu benötigen, indem die aktualisierte Softwareversion einfach auf den nächsten verfügbaren Speicherplatz geschrieben wird. Dies führt zu wesentlich effizienteren Updates und zu einem besseren Kundenerlebnis.

Self-Healing Software ermöglicht es Automobilherstellern, aktiv auf zukünftige Architekturen, Prozesse und Services von Fahrzeugsoftware zu reagieren. Aurora Labs nutzt Machine-Learning-Algorithmen, um alle vier Phasen der Softwarewartung zu adressieren und die nächste Generation von softwaregesteuerten Automobilfunktionen zukunftssicher zu machen. So wird die Lösung bereits heute von Automobilherstellern eingesetzt:

<ul><li> Zur Erkennung von Softwareproblemen und Wiederherstellung des Idealzustands, um die Lebensdauer des Motors zu verlängern.</li><li> Für die autonome und rekursive Qualitätssicherung in der Postproduktion.</li><li>Zum Eliminieren von bösartigem Code im Karosseriesteuergerät durch Zurücksetzen auf eine sichere Softwareversion.</li></ul>

Die Menge an Software in modernen Fahrzeugen nimmt stetig zu. Deshalb steht die Bedeutung von Software-Management-Lösungen außer Frage. Jede Software hat Fehler und kann gehackt werden. Die Self-Healing Software überwacht den „Gesundheitszustand“ der Software und stellt automatisch sicher, dass stets die sicherste und aktuellste Softwareversion im Fahrzeug verwendet wird. (oe)

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

Bild 1: Ein Machine-Learning-Algorithmus analysiert den Code im Fahrzeug. So werden Anomalien erkannt werden, die auf eine Änderung der Softwarekonfiguration, einen Softwarefehler oder einen Hack hinweisen können.

Zohar Fox ist Mitbegründer und CEO von Aurora Labs. Er ist ein Pionier im Bereich der selbstheilenden Software, die die Automobilindustrie zukunftssicher macht.

Während das vernetzte Auto zunehmend zum Standard auf deutschen Straßen wird, steht das autonome Fahrzeug bereits in den Startlöchern, um sich in den intelligenten Verkehrsfluss einzureihen. Diese schöne neue Mobilität hat jedoch nur dann eine Chance, wenn die Hersteller die Menschen von ihren Sorgen vor Cyberangriffen im Auto befreien. Dies erfordert intelligente Vorkehrungen auf allen Ebenen des vernetzten Fahrzeugs – vom CAN-Bus bis zur globalen Lieferkette.

Damit autonomes Fahren eine Chance hat, müssen die Menschen die Sorgen vor Cyberangriffen im Auto verlieren. Dies erfordert intelligente Vorkehrungen auf allen Ebenen des vernetzten Fahrzeugs – vom CAN-Bus bis zur globalen Lieferkette.

Langsam können sich die Deutschen mit dem Thema Autonomes Fahren anfreunden. Laut einer Studie vom Mai 2019 weicht die anfängliche Skepsis zunehmender Akzeptanz.

Während noch im Februar 2018 28% aller Befragten meinten, die Automobilhersteller sollten sich aktiv beim Autonomen Fahren engagieren, sind es im März 2019 bereits 41%. Herausgefunden hat das das Zentrum für empirische Kommunikationsforschung (ZEK) an der DHBW Ravensburg in einer Studie zu Mobilitätstrends.

Allerdings: Ist das Auto mit dem Internet verbunden, dann drohen ihm, wie allen smarten Geräten, Gefahren durch Manipulatoren von außen wie zum Beispiel einer Fremdsteuerung durch Hackerangriffe. Und darin sehen noch 69% ein Problem für die Akzeptanz des Autonomen Fahrens. Gefürchtet wird ein Gefahrenpotenzial, das schon jetzt, im Zeitalter des vernetzten Autos, mit großer Sorgfalt entschärft werden muss.

Täter muss nicht hinter dem Steuer sitzen

Zwei grundsätzliche Gefahren muss man sich dabei vergegenwärtigen: Anders als ein Smartphone oder ein IT-Netzwerk ist ein Auto ein wuchtiger Gegenstand, der sich mit hoher Geschwindigkeit auf mitunter stark frequentierten Straßen bewegt. Übernimmt ein Krimineller von außen das Steuer, kann er das Auto in eine äußerst gefährliche Waffe verwandeln. Ein gekidnapptes Auto kann immensen Schaden an Mensch und Umwelt anrichten. Dabei muss der Täter nicht einmal hinter dem Steuer sitzen.

Die andere grundsätzliche Gefahr betrifft die persönlichen Informationen. Je neuer und moderner ein Auto heute ist, desto mehr digitale Funktionen hat es zu bieten. Wie beim Smartphone wird sich auch das Auto in Zukunft hin zu einer Plattform für Apps entwickeln, samt Marktplatz und Ökosystem. Und auf dieser Plattform werden Daten dann ausgetauscht – Kreditkarteninformationen, identitätsbezogene Daten – von denen sich jeder wünscht, dass sie vertraulich bleiben, weil sie in den Händen Unbefugter Schaden anrichten können.

Wo stecken die Risiken und welche Schwächen des vernetzten Autos bieten Hackern Ansatzpunkte? Und wie kann man es davor schützen? Vorweg: Die Gefahren sind vielfältig, Sicherheitslösungen müssen dementsprechend auf vielen Ebenen greifen.

Auf Technologieebene liegt ein Risiko in den existierenden CAN-Bus-Netzwerken, über die die Elektronik im Auto organisiert ist. Allerdings hat sich der CAN-Bus in einer Zeit etabliert, in der man sich noch nicht vorstellen konnte, in welchem Umfang Autos heute und in Zukunft vernetzt sein werden. Wenn es einem Angreifer gelingt, über eine Sicherheitslücke auf dieses Netzwerk zu gelangen, dann kann er buchstäblich die Kontrolle übernehmen.

Gerade bei älteren Autos kann dieses Manko bezüglich der Netzwerk-Architektur akut werden. In der Vergangenheit hat man die sicherheitskritischen Steuergeräte nicht von unkritischen Systemen getrennt wie z. B. Infotainment, Türverriegelung oder Remote-Keys. Die ersten autonomen Funktionen wie der adaptive Tempomat oder das automatische Parksystem wurden ebenso über CAN-Bus angesteuert, wie Bremse oder Gaspedal.

Ein weiteres Risiko lauert in der steigenden Menge an Software, die für die vielen Steuergeräte (ECUs) und digitalen Funktionen geschrieben wird. Ob Telematik, Infotainmentsystem, Motorsteuerung, Kupplung oder Türverriegelung – überall im Auto wird gerechnet, in modernen Fahrzeugen läuft nichts mehr ohne Software. Und die wird von Menschen programmiert – Menschen, denen Fehler unterlaufen können, die wiederum von Hackern ausgenutzt werden. Und je mehr Zeilen an Code, desto größer das Risiko.

Die komplexe Lieferkette in der Automobilindustrie verschärft dieses Problem. Auch die zugelieferten Teile basieren mehr und mehr auf Software. Oft erhalten die OEMs dafür nur den Quellcode und wissen nicht, was ihnen genau geliefert wurde. Haben die Programmierer des Partners zum Beispiel immer die aktuellen Patches für das jeweilige Betriebssystem installiert? Um sich nicht blind auf die Sorgfalt der Lieferanten verlassen zu müssen, benötigen OEMs einen Überblick über den gesamten Code, der in ihrem Fahrzeug eingesetzt wird. Und der ist schwer zu bekommen.

Was kann man gegen diese Gefahren tun? Die Angelegenheit ist dringend: Eine Studie aus dem Jahr 2018 ergab, dass in mehr als 70 Städten weltweit bereits Tests mit autonomen Fahrpiloten auf öffentlichen Straßen stattfinden (drei davon in Deutschland). Diese Zahl ist seitdem sicher noch weiter angestiegen. Automobilhersteller und Flottenmanager müssen der Cybersicherheit bei der Entwicklung der autonomen Fahrzeuge von 2021 bis 2022 oberste Priorität einräumen, um auf die oben genannten Bedrohungen angemessen reagieren zu können.

Um die Bedrohungen zu beherrschen, müssen Automobilhersteller einen proaktiven Ansatz verfolgen und die Sicherheitslage ihrer Flotte permanent im Blick haben, um gegebenenfalls schnell Gegenmaßnahmen ergreifen zu können, falls eine Schwachstelle offenbar wird. Und da die Gefahren in verschiedenen Schichten des vernetzten Autos bzw. des Ökosystems lauern, gibt es auch nicht die eine universale Cybersecurity-Lösung. Multi-Layer-Ansätze sind gefragt, die das Fahrzeug innen an neuralgischen Punkten überwachen und zugleich das Ökosystem im Blick haben.

Sichtbarkeit ist der entscheidende Faktor. In der traditionellen IT-Sicherheit gibt es das Sprichwort: „Man kann nicht schützen, was man nicht sehen kann“. Das gilt auch für die Fahrzeugsicherheit. Der Ansatz von Harman liefert ein Beispiel dafür, wie dieses Prinzip in eine effektive, ganzheitliche Sicherheitslösung für das vernetzte oder autonome Fahrzeug umgesetzt werden kann.

Die Sichtbarkeit beginnt dort, wo OEMs heute noch ihren blinden Fleck haben: In den vielen Zeilen Binärcode der Software von Lieferantenkomponenten. Wie bereits erwähnt, kann es in dieser Software noch Schwachstellen geben. Und hier kommt die Software-Vulnerability-Management-Lösung von Harman ins Spiel: Als Teil des Harman Remote Vehicle Service (OTA) „röntgt“ sie die Software aller Komponenten, die über die Lieferkette in den Fertigungsprozess gelangen. Damit kann jede Binärdatei auf Schwachstellen überprüft werden, ohne dass auf den Quellcode zugegriffen werden muss. Auf diese Weise können OEMs sicherstellen, dass die gelieferten Fahrzeugteile kontinuierlich auf neue Bedrohungen und Schwachstellen überprüft werden.

Die Sichtbarkeit ist der wichtige erste Schritt im Kampf gegen Bedrohungen. Schnelle Analyse und Reaktion müssen folgen, um das Fahrzeug jederzeit zu schützen. Harman organisiert diesen Gesamtprozess im Automotive Operations Center (AOC). Dieses „zentrale Nervensystem“ für Automobilhersteller ist darauf ausgelegt, Fahrzeugdaten zu sammeln, zu analysieren und nahezu in Echtzeit auf jede Art von Ereignis reagieren zu können.

Das AOC (Bild 1) führt dabei alle wichtigen Daten, Analyse- und Reaktionsfunktionen für das vernetzte Fahrzeug zusammen: Dazu zählen etwa Harman Ignite mit fahrzeugzentrierten Marktplatz, virtuellem Assistenten, verbesserter Navigation mit POI-Suche und intelligenter Personalisierung. Auch der genannte Remote Vehicle Updating Service zählt dazu, der als einziger OTA-Dienst die Fernadressierung von Systemstörungen und Sicherheitsbedrohungen ermöglicht. Das AOC bereitet zudem die Fahrzeugdaten für KI-Features und -Services (KI-Hub) auf. Und nicht zuletzt erfasst es mittels „Voice of the Vehicle“ unmittelbar das Feedback des Fahrers und setzt es mit den Fahrzeugdaten in Bezug, um Herstellern Indikatoren für Qualitätsverbesserungen bereitzustellen.

Entscheidend für das Sicherheitsproblem aber ist: Das AOC kombiniert diese Datenintelligenz auch mit den Sicherheitsfunktionen, die das Fahrzeug auf allen Ebenen schützen, einschließlich der Software-Vulnerability-Management-Lösung sowie des Harman SHIELD (Bild 2). Diese umfassende Intrusion Detection and Prevention Solution (IDPS) erkennt, verwaltet, entschärft und reagiert auf Cyberangriffe. Die SHIELD-Agents bestehen aus modernen Bausteinen, die eine modulare, skalierbare Architektur für OEMs und Fahrzeugflotten bieten. Sie verwenden eine hochwertige IDPS-Technologie und sind mit vollständigen Backend-Berichtsfunktionen und OTA-Update-Fähigkeit ausgestattet.

Der große Vorteil für die OEMs besteht darin, dass sie auf Basis einzelner Cybersicherheitsereignisse an einem Fahrzeug schnelle Gegenmaßnahmen für die gesamte Flotte organisieren können. So kann beispielsweise das OTA-Backend melden, dass bei einem Scan eine Schwachstelle in einer Zulieferkomponente festgestellt wurde. Der OEM kann nun das Verhalten der betroffenen Fahrzeuge über On-Board-Agents überwachen. Wenn die Agents einen Alarm auslösen, kann dies mit der gemeldeten Schwachstelle zusammenhängen. Die OEMs können nun schnell analysieren, welche Fahrzeuge betroffen sind und ob und welche Gegenmaßnahmen erforderlich sind – alles innerhalb des AOC. Und wenn der Patch verfügbar ist, kann er sofort über OTA an die betroffenen Fahrzeuge gesendet werden, während Harman SHIELD das Fahrzeug schützt. Das AOC kann dann die Informationen mit anderen OEMs austauschen und den Vorfall an Branchenorganisationen wie Auto-ISAC melden. Es bietet damit einen schnellen und effizienten Schutz – was für das vernetzte sowie Autonome Fahren unerlässlich ist.

Während das vernetzte Auto zunehmend zum Standard auf deutschen Straßen wird, steht das autonome Fahrzeug bereits in den Startlöchern, um sich in den intelligenten Verkehrsfluss einzureihen. Diese schöne neue Mobilität hat jedoch nur dann eine Chance, wenn die Hersteller die Menschen von ihren Sorgen vor Cyberangriffe im Auto befreien. Der Ansatz von Harman von der Überprüfung der Binärdateien bis hin zur Erfassung, Analyse und Reaktion auf Ereignisse im Automotive Operations Center ist ein Beispiel dafür. (oe)

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

Bild 1: Das Automotive Operations Center (AOC) ist das „zentrale Nervensystem“ der Automobilhersteller; es dient der Erfassung von Fahrzeugdaten, deren Analyse und kann nahezu in Echtzeit auf jede Art von Ereignis reagieren – und das ist eine wesentliche Voraussetzung für den Schutz vor Risiken durch Schwachstellen.

Bild 2: Schutz für das vernetzte Auto: In-Vehicle-Agents erkennen und entschärfen Cyberattacken im Fahrzeug, das Cybersecurity Analytics Center überblickt alle Risiken.

Wie alle smarten Dinge ist auch das vernetzte Auto potenziell anfällig für Hackerangriffe. Der mögliche Schaden kann tödlich sein. Mehrstufige Sicherheitslösungen schützen davor.

Geoffrey Wood arbeitet bei HARMAN im Global Business Development, Automotive Cyber Security.

Digitaler Spiegel für mehr Sicht nach hinten

 Kameras und Displays sollen das Sichtfeld des Fahrers nach hinten zur Seite verbessern und die Sicherheit für alle Verkehrsteilnehmer erhöhen. Eine Kundenakzeptanzstudie zeigt jedoch jetzt, dass noch einige Herausforderungen zu meistern sind.

 Kameras und Displays sollen das Sichtfeld des Fahrers nach hinten zur Seite verbessern und die Sicherheit für alle Verkehrsteilnehmer erhöhen. Eine Kundenakzeptanzstudie zeigt jedoch, dass noch einige Herausforderungen zu meistern sind.

Automobilhersteller wie Chevrolet, Nissan oder Cadillac ersetzen bereits herkömmliche Rückspiegel durch Kamerasysteme. Solche Lösungen erweitern das Sichtfeld nach hinten und eliminieren den toten Winkel, ein Plus für alle Verkehrsteilnehmer, egal ob Fahrer, Fußgänger oder Radfahrer. In absehbarer Zeit wird es auch Hybridsysteme geben, bei denen Spiegel und Videoanzeigen nebeneinander verwendbar sind. Der Automobilzulieferer Gentex hat jetzt einen Full Display Mirror auf den Markt gebracht, der aus einer nach hinten gerichteten Kamera und einem im Innenspiegel integrierten Display besteht. Das Besondere: Der Spiegel bietet zwei verschiedene Funktionen (Hybridfunktion). Im Spiegelmodus funktioniert er als normaler abblendbarer Rückspiegel. Durch Umschalten versetzt man den Spiegel in den Display-Modus und ein Display wird auf der Oberfläche des Spiegels angezeigt. „Eine Hybridlösung kombiniert die Vorteile von Spiegeln und Displays, sodass der Fahrer je nach Fahrverhältnissen selbst entscheiden kann, wann er welches System einsetzt“, so Brad Bosma, Vice President of Vision Systems bei Gentex.

Doch wie kommt diese Technik bei den Nutzern an? Dieser Frage ging Gentex gemeinsam mit den Hochschulen Kempten und München nach. Die Untersuchung sollte zeigen, wie gut Nutzer mit digitalen Rückspiegeln umgehen können und wie sie das System bewerten. Eingesetzt wurden zwei Audi A6, die mit dem „Full Display Mirror“ von Gentex ausgerüstet wurden. Die Studie wurde mit 50 Probanden im Alter zwischen 18 und 66 Jahren durchgeführt (30 Prozent Frauen; 70 Prozent Männer). „Über 71 Prozent der Studienteilnehmer halten das System für technisch ausgereift und 55 Prozent würden es kaufen“, so Prof. Bernhard Schick, Leiter des Forschungsbereiches Fahrdynamik und Fahrerassistenzsysteme sowie des Forschungslabors Adrive Living Lab der Hochschule Kempten. Entscheidender Faktor für die positive Bewertung sei der deutlich größere Sichtbereich nach hinten. Die Zufriedenheit in diesem Punkt sei der Studie zufolge doppelt so hoch wiebei konventionellen Spiegeln.

Als Herausforderung für die digitalen Systeme sieht Schick Wetterverhältnisse wie Regen oder Schnee, eine tiefstehende Sonne oder blendende Frontscheinwerfer. Die Probanden nannten weitere Punkte, die Probleme bereiteten: So falle es schwer, die Größe der dargestellten Objekte richtig einzuschätzen. Das wirke sich zudem negativ beim Einparken aus. „Wir schätzen, dass zwischen 10 und 15 Prozent der Autofahrer digitale Spiegelsysteme ablehnen“, ergänzte Brad Bosma, von Gentex. „Die allgemeine Herausforderung für die Automobilindustrie besteht nun darin, Kamera-Monitoring-Systeme im Fahrzeug zu verbauen und gleichzeitig die Endkunden dafür zu gewinnen. Der Übergang vom herkömmlichen zum digitalen Rückspiegel bringt jedoch noch andere Herausforderungen mit sich. Steigt der Hersteller von herkömmlichen Spiegeln auf Kameras und Displays um, entstehen bereits erhebliche Kosten. „Wenn Sie die zusätzlichen Entwicklungs- und Werkzeugkosten berücksichtigen, kann dies insbesondere bei Fahrzeugen im Niedrigpreissegment problematisch sein.“ Auch Normen und gesetzliche Anforderungen an das Sichtfeld des Fahrers sind von Land zu Land unterschiedlich, was eine global kompatible Lösung für die Automobilhersteller nahezu unmöglich macht. (oe)

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

Der Full Display Mirror von Gentex besteht aus einer Kamera und einem im Innenspiegel integrierten Display und bietet zwei verschiedene Funktionen. (© Gentex)

Bearbeitet nach Unterlagen der Gentex Corp.

Von der digitalen LED zum Licht- und Sensorfeldbus

Nach der ISELED-Technik, die ein dynamische Ambientenlicht im Fahrzeuginnenraum mit 30 und mehr, einzeln ansteuerbaren RGB-LEDs auf einem Lichtstreifen ermöglicht hat, schießt jetzt Inova Semiconductor das ISELED Light and Sensor Network (ILaS) nach. Dieser Feldbus erlaubt nicht nur die Ansteuerung von LEDs über das ISELED-Protokoll, sondern auch die Ansteuerung und das Auslesen von Sensoren und Aktuatoren – und das in praktisch beliebiger Anzahl und Kombination.

Der Feldbus ISELED Light and Sensor Network (ILaS) von Inova Semiconductor erlaubt nicht nur die Ansteuerung von LEDs über das ISELED-Protokoll, sondern auch die Ansteuerung und das Auslesen von Sensoren und Aktuatoren – in praktisch beliebiger Anzahl und Kombination.

Vor der Einführung der ISELED-Technk mussten Unternehmen LEDs binnen (LEDs mit ähnlicher Helligkeit in Behältern, den „Bins“, zusammenfassen) und dann später im System kalibrieren, wenn sie in einem System mehrere LEDs mit einheitlicher Farb- und Helligkeitskonsistenz erhalten wollten.

Das ISELED-Konzept basiert dagegen auf der Idee, einen dedizierten Controller zusammen mit den LEDs in einem Gehäuse zu integrieren, der Korrekturdaten für die einzelnen Farb-LEDs enthält. Dieser Controller kann damit die LEDs auch unter Einbeziehung deren Temperaturgangs ständig im Betrieb nachregeln. Die Korrekturdaten werden dafür während des Endtests der RGB-LED beim Hersteller ermittelt und direkt auf dem Chip abgelegt.

Eine RGB-LED kann so als rein digitale Komponente mit einem „schlanken“ Protokoll und ohne den bisherigen Overhead betrieben werden – daher auch die Bezeichnung „Digitale LED“ – da zu deren Ansteuerung jetzt nur noch die Übertragung von Adresse, Farb- und Helligkeitswert notwendig ist.

Das ISELED-Protokoll kann mit einer Datenrate von 2 Mbit/s die Farbe und Helligkeit von ca. 100 LEDs alle 5 ms aktualisieren bzw. ändern. Es können theoretisch bis zu 4.079 hintereinandergeschaltete RGB-LEDs gesteuert werden.

Dabei lässt sich jede LED sowohl einzeln adressieren, es können aber auch Gruppen von LEDs im Broadcast-Modus gemeinsam angesprochen werden. Das ISELED-Protokoll sieht aber nicht nur die Steuerung vieler RGB-LEDs mit bis zu Videogeschwindigkeit vor. Es ist auch ein Rückkanal hin zum Controller implementiert, über den jede einzelne LED überwacht und deren „Live-Daten“ wie Zustand oder Stromaufnahme ausgelesen werden können: Eine Voraussetzung, um ISELED auch bei Anwendungen im Bereich der Funktionalen Sicherheit einsetzen zu können. Entsprechende ISELED-Anwendungen sind bereits in der Entwicklung.

Jetzt hat Inova Semiconductors eine Weiterentwicklung auf den Weg gebracht, die es erlaubt, neben reinen LED-Streifen auch andere Elemente wie Matrix-LED-Leuchten und Aktoren über das ISELED-Protokoll ansteuern zu können. Bewährte Busse erlauben dies nur mit großen Einschränkungen: LIN ist zu langsam und unterstützt nur bis zu 16 Clients. CAN erlaubt zwar bis zu 64 Clients, aber selbst diese Zahl reicht bei einigen Anwendungen nicht aus. Darüber hinaus ist CAN relativ komplex und verfügt über keine deterministische Latenzzeit (Bild 1).