code safe, secure und testbar machen · märz 2020 4 automobil elektronik 03/2020 mÄrkte +...

03 / 2020 B 61060 · März 2020 · www.automobil-elektronik.de

Code safe, secure und testbar machenInterview mit Friedhelm Pickhard, ETAS 14

E/E-Entwicklung für Entscheider

SECURITYSicherheit ist die Aufgabe von Führungskräften:Management-Grundlagen 22

ADAS UND ADDatengiganten auf vier Rädern: Intelligentes Daten-management für ADAS 32

MANAGEMENTVariantenvielfalt unter Kontrolle: Anzahl der SW-Versionen begrenzen 52

01_Titelseite.indd 2 12.03.2020 08:34:26

KONGRESSJUNE 23 AND 24, 2020

KONGRESSJUNE 23 AND 24, 2020

www.automobil-elektronik-kongress.de/en

Aussteller/Unterstützer

Premium-Sponsoren

Sponsoren

A KONICA MINOLTA Company

Anzeige_Automobil-Elektronik_AEK_210x297mm_2020.indd 1 02.03.2020 12:45:1202_U2 Eigenanzeige.indd 2 10.03.2020 09:49:54

AUTOMOBIL ELEKTRONIK 03 / 2020 3www.all-electronics.de

Editorial

EDITORIAL

Variantenvielfalt unter Kontrolle: Wie

sich die Zahl der Software-Versionen

begrenzen lässtElektrobit

52

von Chefredakteur Alfred Vollmer

Die Auswirkungen der Covid-19-Pandemie bringen unser gesamtes Wirtschafts- und Sozialleben durcheinander: Der stärkste

Kursverfall an den Börsen seit 9/11, der großflächige Verzicht auf Dienstreisen, ganz Italien als rote Zone, Fußballspiele ohne Zuschauer im Stadion, massen-haft gestrichene Flüge, abgesagte Konzerte, Messen und Kongresse und, und, und... Trotz Konjunktur-Delle müssen wir dennoch dringend neue Elektronik-Systeme entwickeln.

Gleichzeitig kommt gerade die komplette Lieferkette durcheinander, weil beispielsweise nicht genügend Leiterplatten hergestellt werden konnten. Diesmal ist aber ausnahmsweise weder die Soft ware noch eine alternative An triebs tech nik Schuld an den Verzöge-rungen im Zeitplan. Ich mag mir gar nicht ausmalen, was in den zwei Wochen Totzeit zwischen dem Schrei-ben dieses Editorials bis zur Auslieferung der Druck-ausgabe auf Ihren Tisch so alles passiert, denn rein prinzipiell besteht die Gefahr, dass es zu sehr großen Erschütterungen des Gesamtsystems kommt, wenn die e-Funktion erst richtig „zuschlägt“.

Andererseits sehen wir hier viel zu plastisch, wie all-umfassend sich ein Viren-Angriff auswirken kann – auch auf Bereiche, von denen man es sich nicht hätte träumen lassen. Wenn ein Cyber-Angriff auf Fahr-zeuge erfolgte, dann kann das bekanntlich sehr schlimme Folgen haben, und weil das Fahrzeug mitt-

lerweile connected ist, müssen wir dafür sorgen, dass die Rezeptoren der Computerviren sowie die Angrif-fe der Hacker entlang der gesamten Datenkette vom Fahrzeug bis zum Backend wirksam dauerhaft geblockt werden. Die ordnungsgemäße Implemen-tierung der Cybersecurity ist daher zumindest aus meiner Sicht eine Management-Aufgabe mit Top-Priorität (siehe Beitrag ab Seite 22).

In schwierigen Zeiten zeigen sich allerdings auch wah-re Tugenden – sei es in der Gesellschaft oder im Management beziehungsweise im persönlichen/beruflichen Netzwerk. Da heißt es, zusammenzuste-hen und den (Firmen-)Egoismus hintenanzustellen. Lassen Sie uns das Gemeinwohl an erste Stelle setzen, denn wir müssen sowieso alle gemeinsam durch die-se Krise: in der EU, der Branche, einfach überall.

Ich wünsche uns allen, dass unser Immunsystem, unse-re Menschlichkeit und unser System intakt bleiben und wir uns wieder gut erholen. Aber vor allem: Blei-ben Sie selbst, Ihre Familien und Ihre Mitarbeiter gesund!

Viren – und jetzt?

[email protected]

03_Editorial.indd 3 11.03.2020 10:24:38

März 2020

4 AUTOMOBIL ELEKTRONIK 03/2020 www.all-electronics.de

MÄRKTE + TECHNOLOGIEN

06 ZVEI-Standpunkt

08 News und Meldungen

COVERSTORY

14 Code safe, secure und testbar machen Interview mit Friedhelm Pickhard, CEO von ETAS

SECURITY

18 Angriffe sicher erkennen und abwehrenCybersecurity: Anforderungen an Intrusion-Detection-Systeme im Auto

22 Sicherheit ist die Aufgabe von FührungskräftenSafety- und Security-Management: die Grundlagen

26 Cybersicherheit in voller FahrtAutomotive Cybersecurity Management

ADAS + AD

30 Wichtige Bausteine der neuen Mobilität Hochpräzise Positionssysteme und dynamische 3D Karten

32 Datengiganten auf vier RädernADAS brauchen ein intelligentes Datenmanagement

34 Vorteile einer standardisierten Software-BibliothekKostenpotenziale bei der Entwicklung eingebetteter Datenfusionssysteme

38 Absicherung autonomer Fahr funktionen im ParkhausEin Entwicklungsprojekt auf Basis von KI und Virtual Reality

42 Das digitale Zuhause an BordWie neue Nutzeransprüche die Zuliefererindustrie verändern

OPTOELEKTRONIK

44 Design-Farbwelten im InterieurPräzise Lichtmesstechnik ermöglicht dezentrale Komponentenherstellung

48 Lösungen für Kfz-InnenbeleuchtungenMicrochip engagiert sich bei ISELEDs

51 Mr. InsiderBei Licht betrachtet

MANAGEMENT

52 Variantenvielfalt unter KontrolleWie sich die Zahl der Software-Versionen begrenzen lässt

56 Keine Emotionen, keine BewegungDr. Lederers Management-Tipps

Management52 Variantenvielfalt

unter Kontrolle Um die hohe Zahl der Software-Varianten zu begrenzen, ist ein gemeinsa-mes „Komplexitätsmanage-ment“ im Bereich Software erforderlich.

14

03 / 2020 B 61060 · März 2020 · www.automobil-elektronik.de

Code safe, secure und testbar machenInterview mit Friedhelm Pickhard, ETAS 14

E/E-Entwicklung für Entscheider

SECURITYSicherheit ist die Aufgabe von Führungskräften:Management-Grundlagen 22

ADAS UND ADDatengiganten auf vier Rädern: Intelligentes Daten-management für ADAS 32

MANAGEMENTVariantenvielfalt unter Kontrolle: Anzahl der SW-Versionen begrenzen 52

01_Titelseite.indd 2 10.03.2020 14:31:49

Titelmotiv gesponsert von ETAS

04_Inhalt.indd 4 11.03.2020 09:50:25

www.all-electronics.de

RUBRIKEN

03 EditorialViren – und jetzt?

57 Neue Produkte

58 Impressum

58 VerzeichnisseInserenten-/Personen-/Unternehmens-verzeichnis

22

Automotive-Abkürzungen

Erklärungen zu mittlerweile weit über 1000 Abkürzungen rund um die Automobil-Elektronik finden Sie auf www.all- electronics.de im Bereich „Abkürzungen“ (oben Mitte).

DIAGNOSE- UND TESTLÖSUNGEN BY SOFTING

04_Inhalt.indd 5 11.03.2020 09:50:28


Märkte + Technologien ZVEI-Standpunkt

kehrssektor, die auf der im Januar 2018 veröffentlichten Studie „Klimapfade für Deutschland“ basiert.

Die Rechtslage in den KommunenWie begegnen nun die Kommunen diesem neuen Alltagsproblem? Zu beobachten ist, dass diesen zahlreichen Fällen des Falsch-parkens mit unterschiedlicher Intensität

begegnet wird. In München verhängt die Polizei Verwarnungsgelder in Höhe von 10 Euro, was bei Parkhaus-Kosten bis 10 Euro pro Stunde fast schon ein Schnäpp-chen ist. An den Parkuhren ist es nur unwesentlich günstiger. Wenn der ver-zweifelte E-Fahrer aufgrund der niedrigen Batterieladung nicht weiterfahren kann, muss er die Polizei anrufen, die je „nach Verkehrslage und Arbeitslast“ eventuell vorbeischaut, um den Falschparker abschleppen zu lassen. Die möglichen Abhilfen: das zustände Referat muss die Beschilderung ändern, beispielsweise von Elektroladeparkplatz zu Ladestation. Dann darf das Verwarnungsgeld höher ausfallen, während die Polizei dann die akute Situation der E-Fahrer erkennt und das Abschleppen veranlasst. Dies ist infol-ge entsprechender rechtlicher Regelungen seit einiger Zeit sogar möglich.

EVs brauchen Möglichkeiten zum öffentlichen Laden

Thomas Nindl ist Geschäftsführer der Brusa Elektronik GmbH und Vorsitzender des Steuerkreises Elektromobilität im ZVEI. Bil

d: ZV

EI

Das öffentliche Laden hat so seine Tücken: Geht der Energievorrat des Elektrofahrzeugs zur Neige,

beginnt die Suche nach den Möglichkei-ten der öffentlich zugänglichen „Inte-rimsladung“. Mittels einer App hat man eigentlich schnell eine „freie“ Ladestation gefunden, die sich vor Ort belegt präsen-tiert – und zwar von Verkehrsteilneh-mern, die die dezidierte Beschilderung mit dem weißen P auf blauem Grund großzügig auslegen und das Kleinge-druckte, das an diesen Stellen die erlaub-te Verweildauer auf den Ladevorgang beschränkt, selbstbewusst überlesen haben. Steht doch da: Parkplatz! Passt! Da spielt es dann auch keine Rolle mehr, ob der „Boykotteur“ einen Verbrenner sein Eigen nennt oder einen nicht angesteck-ten Stromer. Vielerorts ist zu beobachten, dass besonders gemietete E-Fahrzeuge von Car-Sharing-Unternehmen abgestellt werden, jedoch ohne einen Ladevorgang zu starten. Das Ergebnis ist in jedem Fall unerfreulich. Der Platz ist okkupiert, dringend erforderliches Laden entfällt. Stellt sich nur die Frage: ist das ein Park-platz oder eine Ladestation?

Eine Frage der VernunftKein parkplatzsuchender Autofahrer stellt sein Kfz an einer freien Benzintanksäule ab und geht. Eine Tankstelle ist zum Tan-ken da, nicht zum Parken, basta. Umso wichtiger sollte diese Erkenntnis vor dem Hintergrund sein, dass Elektromobilität einer der Schlüssel für die Mobilitätswen-de ist. Zu diesem Ergebnis kommt immer-hin eine Sonderauswertung für den Ver-

Und die Laternenparker?Damit ist das Thema des öffentlichen Ladens aber nicht erschöpft. Wenden wir nun den Blick auf die Spezies der so Later-nenparker, also jener Fahrzeuge, die qua-si weder eine Garage noch einen Stellplatz haben. Klar dürfte sein, dass Kabelgirlan-den aus Wohnbauten über den Bürgersteig zum Straßenrand nicht die Lösung sind. Also sollte das dort abgestellte Fahrzeug mangels Stellplatzsäule beziehungsweise Garagen-Wallbox vor Ort zu jeder Zeit geladen werden können. Für diese Fälle sind Ladeparkplätze vorzuhalten. Denn nur Laden und dann ein Standortwechsel in die Ruhezone sind aus Platzgründen gar nicht möglich. Im Fall der Laternen-parker ist der Straßenrand der finale Stell-platz. Zurzeit wird untersucht, wie viele „Elektro(dauer)parkplätze“ zum Beispiel in Berlin von Nöten wären und wie das zu bewerkstelligen wäre. Eine Idee wäre, die Straßenbeleuchtung nutzbar zu machen. Ein praktikabler Weg, aber insbesondere in Ballungszentren gibt es mehr Laternen-parker als Laternen. Und nun? Ein Mix aus Ladesäulen und induktiven Ladestationen?

Neue Bewertung nötigFest steht, dass die zunehmende Verbrei-tung von Elektrofahrzeugen zur Reduzie-rung von Treibhausgasemissionen beitra-gen wird. Damit Elektromobilität jedoch auf lange Sicht erfolgreich sein kann, ist eine Bewertung aus der Sicht der Nutzer erforderlich. Jetzt gilt es, zu überprüfen, wie Elektromobilität in der Praxis gelingen kann, und die Anforderungen entspre-chend anzupassen. (av) n

Damit E-Mobilität langfristig erfolg-

reich sein kann, ist eine Bewertung aus Nutzer-Sicht nötig

06_ZVEI (av).indd 6 11.03.2020 09:39:24

Schon heute arbeitet dSPACE mit Kunden aus aller Welt daran, die Vision vom autonomen Fahren wahr werden

zu lassen. Dafür bieten wir aus einer Hand eine innovative, skalierbare Toolkette für Entwicklung und Absicherung.

So werden Visionen schneller wahr. www.dspace.com

Autonomes Fahren kommt mit uns noch schneller in Fahrt.

Advert_Autonomous-Driving_210x297mm_013mmA__200218_D.indd 1 18.02.2020 09:03:2807_1_1 Anzeigenlayout.indd 7 05.03.2020 14:16:39

Märkte + Technologien Meldungen


Für die ECUWinbond und Karamba realisieren sicheren Flash-Speicher

Winbond und Karamba Security haben Flash-Speicher-Bausteine mit integrierten Runtime-Integri-ty-Features für Automotive-ECU und über das IoT vernetzte Geräte für Consumer und Industrie entwi-ckelt. Diese basieren auf dem Se-cure-Flash-Speicher W77Q von Winbord und der Embedded-Si-cherheitssoftware Xguard von Ka-ramba. Mit dieser Lösung sollen Anwender einen pinkompatiblen Ersatz für vorhandene Flash-Bau-steine erhalten, der eine Integrität des Speichers während der Lauf-zeit ermöglicht. Alle Binärdateien, die auf den Flash-Speicher geladen werden, durchlaufen eine Legitimitätsprü-fung durch Xguard. Dadurch soll der Chip vor Hackerangriffen ge-

Winbond und Karamba haben ei-nen sicheren Flash-Speicher-Bau-stein für die ECU entwickelt.

Top-FIVE

Dr. Peter Steiner wird neuer E/E-Leiter bei Audi902ael0320 Beitrag der Redaktion

1Die Mobilität von morgen ist elektrisch

300ael0220 Beitrag der Redaktion über Vitesco Technologies2

Wo die Probleme beim Langzeiteinsatz von SiC und GaN liegen

802ae0220 Beitrag der Redaktion3

Autostack Industrie macht Brennstoffzellen-Stacks serienreif

805ae0220 Beitrag der Redaktion4

CES 2020: Automotive-Trends im Überblick

301ael0220 Beitrag der Redaktion5

Die Zeitschrift AUTOMOBIL-ELEKTRONIK finden Sie jeweils als Komplett-PDF jeder Druckausgabe permanent archiviert unter www.automobil-elektronik.de. Zusätzlich stellen wir die einzel-nen Beiträge unter www.all-electronics.de online. Über den Filter „Automotive“ oder den Channel „Applikationen / Automotive“ fokussieren Sie die Auswahl auf Themen rund um die Automobil-

elektronik. Durch Eintippen des Info Direkt-Codes in die Suchmaske auf der Seite all-electronics.de gelangen Sie direkt zum Beitrag. Das Abkürzungsverzeichnis erreichen Sie jetzt komfortabel, indem Sie ganz oben auf der Homepage „Abkürzungen“ anklicken.Die folgenden neuen automotive-relevanten Beiträge wurden seit der letzten Ausgabe am häufigsten aufgerufen.

TERMINEAutomotive Testing Expo 16. bis 18.06.2020, Stuttgart testing-expo.com

24. Automobil-Elektronik Kongress 23. bis 24. 6.2020, Ludwigsburg automobil-elektronik-kongress.de

3. Iseled Conference 03.09.2020, München iseled-conference.com

IAA Nutzfahrzeuge 24. bis 30.09.2020, Hannover iaa.de

IZB 06. bis 08.10.2020, Wolfsburg izb-online.com

Infineon Automotive Cybersecurity Forum 03.12.2020, München infineon.com

Bild:

Winb

ond

duktionsanlage bis zur Anwen-dung. Die W77Q-Serie ist auf Drop-in-Replacement ausgelegt und kann bestehende Chips ersetzen, ohne dass dafür ein größerer Auf-wand für Integratoren entsteht. Dank der Verbindung des W77Q-Kanals mit der Xguard-Whitelist-Verifizierung und der CFI-Validie-rung von Karamba erhalten An-wender eine einsatzbereite Lö-sung, die bei Bedarf über ge-schützte OTA-Updates aktualisiert und angepasst werden kann.

infoDIREKT 109ae0320

schützt werden. Anwender be-kommen eine Kombination aus Laufzeitintegritätsprüfung und Si-cherheit durch eine vorinstallierte und verifizierte Zielprüfung. Die

Integritätsprüfung erstreckt sich dabei von der Entwicklung über die gesamte Lieferkette hinweg: beginnend bei der Wafer-Ferti-gung, über den Einbau in die Pro-

08_News (gk).indd 8 11.03.2020 09:40:54


AUTOMOBIL ELEKTRONIK 03 / 2020 9www.all-electronics.de

Die digitale LEDElmos und Cemm Thome treten der Iseled-Allianz bei

Die Iseled-Allianz wächst um den Halbleiterhersteller Elmos und das Unternehmen Cemm Thomme , das Automotive-Beleuchtungssysteme entwickelt und fertigt. Damit er-höht sich die Zahl der Mitglieder in dem offenen Industrieverband auf 30 Unternehmen und Einrichtun-gen. „Das breite Spektrum der Alli-anzmitglieder aus unterschied-lichsten Industriesegmenten ver-leiht der Iseled-Technologie eine immer größere Dynamik und er-weitert das potenzielle Anwen-dungsspektrum enorm – weit über die ursprünglich angedachte Auto-mobil-Innenbeleuchtung hinaus“, sagte Robert Kraus , CEO von Inova Semiconductors und einer der Gründerväter der Iseled-Allianz.Die Iseled-Allianz hat sich auf die

Die Iseled-Allianz wächst um zwei neue Mitglieder.

Bild:

Iseled

-Allia

nz/In

ova S

emico

nduc

tors

Stäubli Tec-Systems GmbH, Tel. +49 (0) 921 883 0, [email protected]

Leistung und Modularität auf neuem Niveau.

Mit Robotern, Cobots, mobilen Robotersystemen und AGVs

setzen die Automationslösungen von Stäubli Maßstäbe in

Sachen Zuverlässigkeit, E� zienz und Kompaktheit.

Stäubli – Experts in Man and Machine

www.staubli.com

Automation neu gedachtAUTOMATICA 2020 Halle B5.329

Fahnen geschrieben, ein umfas-sendes Ökosystem – eine komplet-te Systemlösung für innovative Be-leuchtungen im Automobil – auf Basis der Iseled-Technologie auf-zubauen. Die Iseled-Technologie löst elementare Probleme beim Einsatz von LEDs, indem sie die LED quasi zu einem digitalen Bau-element mit über die Laufzeit hin-weg stabilen Eigenschaften macht. In der Praxis wird das Design von Systemen viel einfacher, weil unter anderem das Binning und die Nachkalibrierung der LEDs entfällt. Mittlerweile unterstützen mehrere führende LED-Hersteller, Mikro-controller-Anbieter und Tier 1-Au-tomobilzulieferer die Technologie.

infoDIREKT 100ael0320

Ausbau der ZusammenarbeitBattery in the Cloud: Bosch kooperiert mit Human Horizons

Bosch Connected Mobility Solu-tions und der chinesische Startup-OEM Human Horizons kooperieren bei der Battery in the Cloud ge-nannten Technologie. Diese Tech-nik verbindet Batterien in Elektro-fahrzeugen mit der Cloud, um zu einer Verlängerung der Batteriele-bensdauer beizutragen und die Batterieleistung zu verbessern. Battery in the Cloud ermöglicht Predictive Diagnostics. Basierend auf den Daten des Fahrzeugs und der Flotte bewertet das System fortlaufend den Zustand der Batte-rie. Algorithmen ermöglichen es, Störungen vorherzusagen. Nach Angaben von Bosch soll sich damit die Lebensdauer der Batterie um bis zu 20 Prozent verlängern und die Ladedauer um bis zu 20 Pro-

Der Service „Battery in the Cloud“ soll Lebensdauer der Batterie erhöhen.

Bild:

Bosc

hzent verringern lassen. Bereits im April 2019 waren die Unternehmen eine strategische Kooperation bei FOTA-Lösungen (Firmware Over the Air) eingegangen. Damit sollen sich Anwendungen wie Remote Diagnostics von möglichen Proble-men in Fahrzeugen realisieren las-sen. Diese Technik soll schon im ersten Elektrofahrzeug von Human Horizons, dem Hi PHi 1, im Jahr 2021 zum Einsatz kommen.Die Partner wollen ihre Zusam-menarbeit noch über FOTA und Battery in the Cloud hinaus aus-bauen und insbesondere neue An-wendungen bei Remote Diag-nostics und anderen Connected-Mobility-Themen realisieren.


08_News (gk).indd 9 11.03.2020 09:40:57


10 AUTOMOBIL ELEKTRONIK 03 / 2020 www.all-electronics.de

Secure Element NCJ38A „Phantom“ macht es möglichDigitaler Schlüssel im Smartphone öffnet und startet das Auto

Draft International StandardLDRA unterstützt den Automotive-Cybersecurity-Standard ISO/SAE 21434

NXP Semiconductors hat jetzt eine neue Lösung für digitale Schlüssel (Digital Keys) im Automotive-Be-reich vorgestellt, mit der Smart-phones, Autoschlüssel sowie ande-re mobile Geräte digitale Schlüs-seldaten sicher austauschen, spei-chern, authentifizieren und sicher an die jeweiligen Fahrzeuge über-tragen können. Kernelement ist dabei das automo-tive-qualifizierte Secure Element NCJ38A (Code-Name Phantom). Dieses Secure Element funktioniert etwa analog zu den Mechanismen, die bei Apple Pay oder Google Pay zum Einsatz kommen. Bei diesen Bezahldiensten befindet sich be-reits eine vorinstallierte, aber zu-nächst leere Kreditkarte im Secure Element, das als Schlüsseltresor fungiert. So wie man diesen Schlüssel-Container zum Bezahlen mit der eigenen Kreditkarte bele-gen kann, bietet die Automotive-Lösung die Möglichkeit, einen Fahrzeugschlüssel zu hinterlegen. Diese neue Funktionalität macht den Zugang zum Auto noch flexib-ler, denn jetzt gibt es eine sichere Grundlage für die Realisierung neuer Funktionen wie Fahrzeug-öffnung mit Mobiltelefonen, Schlüsselweitergabe, Zugang zu mehreren Fahrzeugen und konfi-gurierbare Fahrberechtigungen.Die Lösung basiert auf den für Au-tomobilanwendungen zertifizier-

Der Autoschlüs-sel wird bald in der Apple Wallet (oder in Wallet-Passes) sicher verwahrt sein und per NFC mit dem NCJ38A im Auto kommuni-zieren.

Der neue Automotive-Cybersecurity-Stan-dard ISO/SAE 21434 befindet sich im DIS-Stadium.

Bild:

NXP

Bild:

Ado

be St

ock

ten Secure Element- und NFC-Chips von NXP. Die Lösung orien-tiert sich am Standardisierungsre-lease 2 des Car Connectivity Con-sortiums (CCC) – einer Architektur, die von den weltweit führenden Fahrzeugherstellern, Smartphone-Produzenten und Elektronikunter-nehmen unterstützt wird. Parallel dazu hat das CCC einen ei-genen Autoschlüssel-Container in den Secure Elements der neuen Smartphones definiert. Der Stan-dard ist jetzt sowohl für das Smart-phone als auch für die Autos spezi-fiziert und festgelegt. „NXP stellt die Security-Chips für die meisten Smartphones her, und jetzt stellt NXP ein neues Secure Element für den Automotive-Ein-satz vor, das die vom CCC definier-ten Anforderungen in punkto Digi-tal Key Management erfüllt“, er-klärte Rainer Lutz , der als Director of Digital Key and NFC Segments für Secure Car Access bei NXP ver-antwortlich ist, im Gespräch mit AUTOMOBIL-ELEKTRONIK. „Wir ha-ben die Logik sowohl auf der Smartphone-Seite als auch auf der Autoseite bereits implementiert und in der System-Referenzlösung getestet.“Die Sicherheits-Architektur stellt dabei sicher, dass der Schlüssel nicht abhanden kommt. Wer sich als Apple-Enthusiast bereits die Betriebssystem-Version IOS13.4

Der Automotive-Cybersecurity-Standard ISO/SAE 21434 hat nach Angaben von LDRA das DIS-Stadi-um (Draft International Standard) erreicht. Das Unternehmen hat be-reits im Zuge der formellen Her-ausgabe der Norm eine spezielle Automotive-Tool-Suite entwickelt, um den Standard umfassend zu unterstützen. Die Norm ISO/SAE 21434 (Road Vehicles, Cybersecuri-ty Engineering) wird derzeit entwi-ckelt und soll die Norm SAE J3061 (Cybersecurity Guidebook for Cyer-Physical Systems) ersetzen. Diese wurde 2016 als empfohlenes Pra-xisdokument veröffentlicht, das den Rahmen für einen Entwick-lungsprozess zur Integration mit anderen Entwicklungsprozessen für das systematische Design von

beta installiert hat, der kann jetzt schon eine „Car Key“ genannte Funktion in seiner Apple Wallet entdecken. Da IOS13.3.1 die aktuel-le Version ist, dürfte der Auto-schlüssel in der Apple Wallet mit dem nächsten größeren Software-Update live gehen. Da sowohl Apple als auch Samsung Board-Mitglieder im CCC sind, ist die Wahrscheinlichkeit groß, dass auch Samsung in diesem Bereich sehr weit unterwegs ist und bestimmt ähnlich in den Startlöchern steht. Der Datenaustausch zwischen Au-to und Mobile Device erfolgt dabei über NFC als Kommunikationska-nal. Die neue Digital Key-Lösung basiert auf NFC-Chipsätzen und Secure Element-Technologien von NXP sowie dem neuen für Auto-mobilanwendungen qualifizierten NXP Secure Element. Sie ermög-licht das Öffnen und Starten eines Autos mit einem NFC-fähigen

Smartphone, einem herkömmli-chen Autoschlüssel oder einer NFC Smart Card, die einen digitalen Schlüssel beinhaltet. Darüber hin-aus erlaubt sie die sichere Weiter-gabe der Zugangsberechtigung an andere Mobilgeräte und eröffnet so moderne und flexible Zugangs-optionen. „Außerdem lässt sie sich nahtlos in klassische Schließsyste-me wie schlüssellose Fahrzeugzu-gangssysteme integrieren“, betont Rainer Lutz.Weitere Details über die End-to-End-Sicherheitsarchitektur, das Se-cure Element selbst, neue Anwen-dernutzen und mehr finden Sie zu-sammen mit einem Anwender-Kommentar sowie einem Ausblick auf das Release 3 (inklusive BLE und UWB gegen Relay-Attacken) in der Online-Version dieses Beitrags per infoDIREKT.


Cybersecurity in Fahrzeugsyste-men bildete. Die ISO/SAE 21434 bietet laut LDRA nun die Aussicht auf eine substanzielles Dokument, das mehr ins Detail geht als die eher allgemein gehaltenen Prinzi-pien von SAE J3061 und deshalb weithin in der Branche erwartet werde. „Die ISO/SAE 21434 befin-

det sich noch im Ent-wurfsstadium, so dass wir betonen möchten, dass tiefgreifende Än-derungen am Inhalt dieser Norm momen-

tan noch absolut möglich sind“, sagte Ian Hennell , Operations Di-rector bei LDRA. Das Unternehmen rät folglich dazu, die Entwicklung neuer Produkte nur mit äußerster Vorsicht auf ein DIS-Dokument zu gründen.


Infineon und CypressUSA genehmigen Kauf

Die US-Behörden haben ihr OK ge-geben und dem Kauf von Cypress durch Infineon zugestimmt: Das Committee on Foreign Investment in the United States (CFIUS) hat die Transaktion genehmigt, obwohl die Trump-Administration sie zu-vor als Risiko für die nationale Si-cherheit eingestuft hatte. Der Ab-schluss der Übernahme unterliegt weiterhin der Genehmigung durch die Staatliche Verwaltung für Marktregulierung Chinas (SAMR). Weitere Details enthält die Lang-version dieses Beitrags, die Sie per infoDIREKT erreichen.


10_News (av, na).indd 10 11.03.2020 09:43:24


Lithium-Ionen-BatterienRohmaterialien für Elektroden: Auch mitten in Europa ist Lithium-Abbau geplant

Die Lithium-Ionen-Batterie für Elektrofahrzeuge und Hybride steht und fällt mit der Verfügbar-keit der Rohmaterialien für Katho-de und Anode – Lithium, Cobalt, Nickel und Graphit sind heiß be-gehrt. Seit 2015 hat sich die Anzahl der Megafactories zur Herstellung der Energiespeicher von drei auf mittlerweile über 20 erhöht. Bis 2029 muss viermal mehr Cobalt, siebenmal mehr Graphit und Lithi-um und elfmal mehr Nickel bereit-stehen, um die teilweise aggressi-ven Wachstumspläne ( CATL allein will zum Beispiel seinen Output bis 2028 um 143 Prozent hochfahren) der Hersteller zu realisieren. Aber nicht nur die weltweite Verfügbar-keit der Rohmaterialien macht den Fahrzeugherstellern Sorgen, son-dern auch die Probleme beim Ab-bau. Viele OEMs beteiligen sich derzeit direkt mittels Joint Ven-tures bei den Minenbetreibern. Da-bei geht es nicht nur darum, den Zugang zu Rohmaterialien abzusi-chern, sondern viele Unternehmen

Saubere Lieferketten bei Li-Ionen-Batterien sind zunehmend wichtig für OEMs. Auch die EU ist hier aktiv und plant ein Nachhaltigkeits-Label.

Bild:

Europ

ean L

ithium

beziehen Rohmaterialien nur noch direkt vom abbauenden Unterneh-men, um die Lieferkette sauber zu halten. Sauber heißt: keine Kinder-arbeit, keine dubiosen Zwischen-händler und ein umweltschonen-der Abbau. Auch die EU legt zuneh-mend genau darauf Wert und könnte den Import „schmutziger“ Batterien untersagen und plant auch derzeit, ein Nachhaltigkeits-Label für Energiespeicher einzu-führen. Gerade bei Lithium soll es bald einfacher sein, die Lieferkette sauber zu halten: Infinity Lithum und European Lithium sind aktuell dabei, Abbaumöglichkeiten für Battery Grade Lithium in Europa zu erschließen. Hinsichtlich Kobalt hatte sich in 2019 die Versorgungs-situation entspannt: eine Überpro-duktion sorgte für stark fallende Preise. Aber nun könnte Kobalt bald wieder rar werden: zum einen hatte die DR Kongo durch die an-haltende Trockenheit Probleme bei der Energieversorgung der Minen durch Wasserkraftwerke und Mi-

nenbetreiber Glencore hat Ende 2019 die Mutanda-Mine für min-desten zwei Jahre für Maintenance-Arbeiten geschlossen. Auch daher ist es wichtig, das Batterie-Recyc-ling zur Rohmaterialgewinnung noch stärker auszubauen und vor allem den größten Kostenfaktor dabei – Transport und Verpackung der Akkus – drastisch zu senken und die hohe Brandgefahr beim Transport und bei der Lagerung

beschädigter Energiespeicher in den Griff zu bekommen. Noch sehr viel mehr Details und aktuelle Hin-tergründe zur Verfügbarkeit von Batterie-Rohmaterialien und zu Re-cycling-Technologien finden Sie auf über 30 Bildern in der Bilderga-lerie unter https://bit.ly/2PZZOS7 oder unter Info-Direkt 808ae0220 auf www.all-electronics.de.


10_News (av, na).indd 11 11.03.2020 09:43:27



Forschungsprojekt Hy-Nets4allSo sollen sich Funktionen für automatisiertes Fahren absichern lassen

kurz & BÜNDIGWeitere Informationen zu einigen Kurzmel-dungen finden Sie auf www.all-electronics.de, indem Sie dort den jeweiligen infoDIREKT-Code in die Suchmaske eingeben. IAA : Die Automobilausstellung findet künftig in München statt. infoDIREKT 103ael0320 Mercedes ist laut Brand Finance das dritte Mal in Folge die wertvollste Automobilmarke der Welt.

ZKW Group : Der Lichtsysteme-Spezialist er-reichte im Jahr 2019 mit 3300 Beschäftigten ei-nen Höchststand beim Personal. Daimler : Der eCitaro von Evobus hat als erster Elektrobus in Deutschland das Umweltzeichen Blauer Engel erhalten. Open Synergy : Der Spezialist für Automotive-Virtualisierungstechnologie geht Partner-schaften mit Global Logic und Mobica ein.

Dataspeed und DFEV stellen während der NAIAS 2020 Michigan Mobility Challenge auto-nome Airport Shuttles bereit. Greenerity baut ein zweites Werk für die Fer-tigung von Komponenten für Brennstoffzellen und Wasser-Elektrolyseure. Autotalks : Das Chipset des Anbieters von V2X-Lösungen wurde für eine Serienfertigung in China ausgewählt.

Verbesserung der FahrzeugsicherheitAnalog Devices und Jungo kooperieren bei Lösung für Innenraumüberwachung

Analog Devices (ADI) will mit Jungo an einer Ka-meralösung arbeiten, die auf dem ToF-Prinzip basiert und in Fahrzeugen die Überwachung des Fahrers und des Innenraums ermöglicht. Die Kombination der ToF-Technologie von ADI mit der Software Codriver von Jungo schafft die Grundlage, um Fahrzeuginsassen durch Beob-achtung der Kopf- und Körperposition sowie der Blickrichtung auf Schläfrigkeit und Ablenkung zu überwachen. Außerdem soll die Lösung eine intelligente Fah-rer-Fahrzeug-Interaktion auf der Grundlage von Gesichts-, Körper- und Handgesten möglich ma-chen und eine Gesichtserkennungsfunktion be-inhalten. Dadurch lassen sich Personen im Fahr-

zeuginnenraum identifizieren, wodurch ihnen wiederum der Zugang zu Funktionen wie Perso-nalisierung von Infotainment, personalisierte Dienste und Abrechnung bei Fahrgemeinschaf-ten ermöglicht wird. Hinter dem 3D-ToF-Prinzip verbirgt sich eine Art Lidar ohne Laserscanner, welches mithilfe von optischen Hochleistungs-impulsen Tiefeninformationen von einer rele-vanten Szene erfasst. Die Software Codriver von Jungo verwendet Deep-Learning-, Machine-Learning- und Computer-Vision-Algorithmen, um den Zustand des Fahrers mithilfe von Kame-ras in Echtzeit zu erkennen.


Die gemeinsame Lösung von Analog Devices und Jungo überwacht im Fahrzeuginnenraum, ob der Fahrer möglicherweise abgelenkt oder schläfrig ist.

Bild:

Analo

g Dev

ices

dSPACE , Denso , die RWTH Aachen und die Uni-versität Paderborn setzen das Projekt Hy-Nets4all fort, in dem eine Validierungsumge-bung zur Verbesserung des elektrifizierten Fah-rens aufgebaut wird. Mit dieser Umgebung sol-len sich Funktionen für automatisiertes Fahren für elektrifizierte Fahrzeuge ganzheitlich entwi-ckeln und absichern lassen. Die Partner wollen damit den Energiebedarf verringern, elektrische Komponenten weiterentwickeln und Fahrzeug-konzepte auf die Ladeinfrastruktur abgestimmt auslegen. Der Europäische Fonds für regionale Entwicklung (EFRE) fördert das Projekt über drei Jahre.Im Vorgängerprojekt Hy-Nets, das abgeschlos-sen ist, hatten die Unternehmen und For-schungseinrichtungen gezeigt, dass mit Hilfe smarter Toolketten Energie und somit Emissio-nen eingespart werden könnten.Bei dem Ansatz Hy-Nets4all sollen Simulations-modelle und Realbauteile interagieren und für die Weiterentwicklung und Validierung von Fahrfunktionen genutzt werden. Die Fahrten führen die Partner in einer virtuellen Abbildung der Stadt Paderborn als Simulationsumgebung durch. Dabei berücksichtigen sie neben der

V2X-Kommunikation auch die bereits existie-rende und eine zukünftig aufzubauende Lade-infrastruktur.Konkret simulieren die Partner den Einsatz von mehreren Fahrzeugen des Modell E-Go, um die Wechselwirkungen verschiedener Fahrzeuge und Fahrzeugtypen in einer Umgebung zu un-tersuchen. Durch die Einbindung von realen Komponenten wie zum Beispiel Verbrennungs-motor, E-Maschine und Leistungselektronik messen sie dabei echte Emissionswerte und den Energiebedarf. Die Unternehmen und Forschungseinrichtun-gen wollen auf diese Weise die Interaktion mit dem Verkehrsfluss und die Auswirkungen von kooperativen Fahrfunktionen in einem In-the-Loop-Ansatz darstellen. Geplant ist, dass sich elektrische Komponenten ressourcenschonend entwickeln und verbessern sowie Fahrfunktio-nen einfach absichern lassen. Nutzer wie Auto-mobilhersteller und Zulieferer sollen auf die ge-plante Validierungsplattform künftig über SaaS-Schnittstellen (Software as a Service) zugreifen können.


Dr. Klaus Büttner leitet jetzt die Ab-teilung „Intelligent Cockpit und Body“ in der Car-Software-Organisation von VW . Er gehört damit zum Führungskreis von CEO Diess in der Organisation Di-gital Car & Services.

Kurt Sievers steigt bei NXP Ende Mai zum CEO und Execu-tive Director auf. Er folgt damit auf den bisherigen CEO Rick Clemmer , der das Unternehmen seit dem Jahr 2009 lei-tet. Sievers war bis-her Präsident.

PERSONEN

12_News (gk).indd 12 11.03.2020 09:46:50



Vorausschauender RückblickEinwandfreie Sicht nach hinten durch ein im Innenspiegel integriertes Display. Kameras in den Außenspiegel reduzieren den toten Winkel. Warnhinweise & Informationsanzeigen im Displayspiegel sorgen für mehr Sicherheit. Kameras und Sensoren im Innenraum steigern Wohlbefi nden und Komfort.

Gentex bietet die Lösung für digitale Sichtsysteme in Fahrzeugen von heute mit Technologien von morgen.

TODAY’S FEATURES » TOMORROW’S TECHNOLOGY

GENTEX.COM // GENTEXTECH.COM

DISPLAYSPIEGEL1-Kamera-System

DIGITALE SPIEGELERSATZSYSTEME3-Kamera-System

INFORMATIONSDISPLAYS ADAS-Warnhinweise &

Informationen

SENSORIKInnenraumsensoren

TODAY AUTONOMOUS

2019-Gentex-Automobil-Produktion-Digital-Vision-ad-GER.indd 1 1/8/20 10:54 AM

Für FahrzeugflottenCyberschutz von NTT und Escrypt

Escrypt kooperiert mit NTT bei Sicherheitslösungen für Fahrzeug-flotten.

Bild:

Escry

pt

Mit der Vernetzung von Fahrzeu-gen steigt das Risiko für Cybersi-cherheitsvorfälle. Um solche An-griffe zu erkennen und abzuweh-ren, benötigt die Automobilindus-trie Lösungen, die die Fahrzeug-Security mit kontinuierlicher Über-wachung und zentralem Security-Management vereinen. Um das möglich zu machen, bringen NTT und Escrypt ihre Expertise zusam-men. Die Partner bieten künftig Lösungen an, die für den Cyber-schutz von Fahrzeugflotten sorgen sollen. Escrypt offeriert bereits Lö-sungen zur Angriffserkennung und -abwehr für Fahrzeuge. Doch OEM und Flottenbetreiber benötigen solche Schutzsysteme nicht nur im Fahrzeug, sondern auch im Mobil-funknetz und im Backend. Deshalb ist es erforderlich, alle IT- und Tele-kommunikationssysteme rund um das vernetzte Fahrzeug während der gesamten Betriebsdauer auf Auffälligkeiten zu überwachen und vor Attacken abzuschirmen. Um die wachsende Anzahl ver-netzter Fahrzeuge wirksam zu schützen, sind somit zusätzliche IT-Infrastrukturen und -Prozesse erforderlich.


Die Reisebeschränkungen auf Grund von Sars-CoV-2 zeigen Wirkung3. Iseled Conference wird auf den 3.9.2020 verschoben

Die 3. Iseled Conference wird auf den 3. September 2020 verscho-ben. Ursprünglich sollte sie am 26. März stattfinden. „Wir denken, dass die Verschiebung eine ange-messene Maßnahme in der aktuel-len Situation ist, um mit den Be-denken und Unsicherheiten be-züglich des Corona-Virus umzuge-hen“, sagte Robert Kraus , CEO von Inova Semiconductors und einer der Gründerväter der Iseled-Alli-anz. Die Veranstaltung in Koopera-

Roland Neumann , CTO von Inova Semi-conductors auf der 2. Iseled Conference in München.

Bild:

Alfre

d Voll

mer

tion mit dem Hüthig Verlag im Hochhaus des Süddeutschen Ver-lags vermittelt, wo Iseled heute steht. Über 14 Allianzmitglieder werden ihre Produkte und Lösun-gen präsentieren. Branchenexper-ten halten die Teilnehmer über neue Trends und Möglichkeiten im Bereich der Autombilbeleuchtung auf dem Laufenden. Parallel zur Reifung des Produkts hat die Iseled-Allianz ein weiteres Ziel er-reicht: ein Ökosystem um die digi-

tale LED herum aufzubauen. Aktu-ell gibt es laut Allianz einen Mei-lenstein zu feiern: Die ersten Autos mit Iseled-Technologie haben ihre Zulassung erhalten. Die Registrie-

rungen der Teilnehmer behalten übrigens ihre Gültigkeit. Das glei-che gilt für Aussteller.


12_News (gk).indd 13 11.03.2020 09:46:53

Coverinterview ETAS


INTERVIEW mit Fr iedhelm Pickhard, CEO von ETAS

Alles, was unter dem OEM-Betriebs-system liegt, wollen

wir anbieten.Friedhelm Pickhard, ETAS

Code safe, secure und testbar machenSoftware gilt branchenweit als der Enabler neuer Funktionen und Funktionalitäten schlechthin. Aber wie kön-nen die Entwickler dafür sorgen, dass die Software auch betriebs- und datensicher ist? Darüber sowie über die in diesem Zusammenhang erforderlichen Tools, Organisationsstrukturen und vieles mehr sprach AUTOMOBIL-ELEKTRONIK mit Friedhelm Pickhard, dem CEO von ETAS. Das Interview führte Alfred Vollmer

Weg räumt. In meiner Tätigkeit, auch als CEO, muss ich jetzt viel intensiver im Haus unterwegs sein und schauen, wo Barrieren im Unternehmen sind. Wie kann ich helfen, diese Barrieren mög-lichst effizient zu beseitigen, damit die Kolleginnen und Kollegen, die in der fachlichen Domäne entscheiden können, möglichst schnell weiterkommen? Das ist schon ein beachtlicher Wandel, und so wird man auch gemessen. Man wird heute als Führungs-kraft viel stärker daran gemessen, welche Probleme man löst, als daran, welche Entscheidungen man aufgrund der eigenen hier-archischen Autorität fällen darf. Die Teams achten sehr genau darauf, welche Wertschöpfung man als Führungskraft für das Team erbringt.

Auch für mich persönlich ist es viel interessanter, so zu arbei-ten, denn ich werde viel stärker direkt in das Team einbezogen,

und das Team hat die Erwartung an die Führungskraft, dass sie neben der Strate-giearbeit zusätzlich Barrieren beseitigt. Die-sen Wandel haben wir bei ETAS in den letz-ten Jahren durchgeführt; die zahlreichen Rückmeldungen von den Mitarbeitern zei-gen, dass sie heute das Unternehmen ETAS viel stärker als ihre ETAS sehen und so auch unserem Firmensitz den Namen „ETAS Home“ gegeben haben. Es ist unser Home,

weil der Gestaltungsraum, der Freiraum für die Mitarbeiter grö-ßer geworden ist, und alle haben verstanden, dass wir an einem Strang ziehen.

Wie verändert sich das Produktportfolio von ETAS?

Friedhelm Pickhard: ETAS ist gut gerüstet, die Automobilindustrie in ihrer Transformation zu unterstützen. Aufgrund der zuneh-menden Bedeutung von Software verändern sich die Entwick-lungs-Paradigmen und somit auch die Anforderungen an unse-re Lösungen. Ein gutes Beispiel hierfür ist Continuous X – ein Thema, das eigentlich aus der reinen IT sowie aus dem IT-Platt-form-Geschäft kommt. In Zukunft müssen wir davon ausgehen, dass man Software nur dann effizient und performant entwickeln kann, wenn man kontinuierlich integrieren, testen und auch Software auf Rechner verteilen kann – und zwar in der Kette OEM über alle Tiers. Das funktioniert eigentlich nur in der Cloud, denn dort lassen sich die Rechenleistung entsprechend skalieren

Wie entwickelt sich ETAS organisatorisch weiter?

Friedhelm Pickhard: ETAS hat ja eine 25-jährige Tradition und kommt aus einem Konzern, den es schon über 130 Jahre gibt. Mittler-weile passen bestimmte Organisationsformen, bestimmte Lea-dership-Ausprägungen nicht mehr zu der modernen Software-Entwicklung und auch nicht mehr zur Community. Unser Ziel ist es, ETAS als agile Organisation fit für die Zukunft zu machen. Es gibt künftig keine klare Trennung mehr in Produktmanage-ment und Entwicklung.

Mit der Einführung von Scaled Agile Framework, kurz SAFe genannt, zum 1. März haben wir dafür die Voraussetzungen geschaffen. SAFe bedeutet eine Veränderung der Art und Weise, wie wir zusammenarbeiten. Entscheidungen werden nicht mehr von Einzelpersonen innerhalb einer Hierarchie getroffen. Statt-dessen werden Verantwortlichkeiten auf eine Reihe von verschiedenen Rollen übertragen. Es gibt künftig keine klare Trennung mehr in Produktmanagement und Entwicklung.

Darüber hinaus adressieren wir auch die Erwartungshaltung der Software-Commu-nity. Wichtig ist allerdings auch, dass viele Manager in ihrer Ausbildung nicht mit agi-len Software-Entwicklungsmethoden groß geworden sind. Daher haben wir beschlos-sen, dass fachliche Entscheidungen dort getroffen werden sollen, wo die Kompetenz ist, sodass Leadership jetzt eine ganz andere Bedeutung als in der Vergangenheit hat. Früher hat ein Abtei-lungs- oder Bereichsleiter sehr stark aufgrund seiner eigenen Erfahrung in der fachlichen Domäne die entsprechende Abteilung oder den Bereich geführt und seine Entscheidungen getroffen. Das geht heute nicht mehr, weil die jeweiligen Technologien während der Zeit, in der die Führungskraft selbst in der opera-tiven Entwicklungsarbeit war, noch gar nicht existierten. Deshalb müssen Führungskräfte jetzt viel stärker als in der Vergangenheit Fachexperten führen.

Was heißt das konkret für die Führungspraxis?

Friedhelm Pickhard: Im Unterschied zu früher ist man als Führungs-kraft weniger ein Abteilungs- oder Bereichsleiter mit großem Büro, sondern eher ein Scrum-Master, der dann operativ für Teams beziehungsweise für die Fachexperten Barrieren aus dem

14_ETAS (av).indd 14 10.03.2020 11:54:05

Coverinterview ETAS

AUTOMOBIL ELEKTRONIK 03/2020 15www.all-electronics.de

und große Datenmengen effizient verarbeiten. Solche Cloud-Anwendungen ermöglichen darüber hinaus eine effiziente Zusammenarbeit in weltweiten Kooperationsnetzwerken. Das heißt für uns natürlich auch, dass unsere Software-Entwick-lungstools, die früher PC-Anwendungen waren, jetzt cloudfähig sein müssen. Wir bringen aktuell unsere Mess- und Kalibrier-software INCA und weitere Verifikationstools in die Cloud; das ist ein Paradigmenwechsel. Weil eine Cloud-Anwendung ein anderes Computing-Modell erfordert, müssen sich auch die Tools entsprechend anpassen: mit anderen Architekturen und anderem Software-Know-how als bei der klassischen Embedded Software.

Unser Ziel ist, dass wir die Software-Performance, also die Performance in der Software-Entwicklung, in der Automotive-Industrie voranbringen wollen, und dazu wollen wir auch die passenden Werkzeuge liefern, um sehr schnelles Testen in kurzen Iterationsschritten mit schnellen Rückkoppelschleifen, also Con-tinuous Integration, Deployment und Testing von Software-Komponenten in virtuellen Fahrzeugen, zu ermöglichen. Wir gehen dabei auch das schnelle und umfangreiche Testen in gro-ßen Szenarien – Stichwort: Open World Kontext – an.

Auch auf die Frage „Wie kann ich Software möglichst effizient optimieren?“ wollen wir eine Antwort geben. In der Vergangenheit lag hier ein Schwerpunkt im Bereich Kalibration, aber jetzt geht es auch um andere Aspekte wie zum Beispiel Schaltstrategien: Wann schalte ich in den Verbrennungsmotorbetrieb, wann in den Batteriebetrieb, und wann ist Segeln, das heißt das komplet-te Abschalten des Antriebs während der Fahrt, angebracht? Hier-für müssen sehr umfangreiche Szenarien getestet und optimiert werden. Auch das haben wir auf der Agenda: Wir wollen zur Optimierung von Software, Systemen oder Subsystemen ent-

scheidend beitragen. Ein System kann dabei auch ein Motor mit seiner gesamten Steuerungsstrategie und Abgasnachbehandlung sein. Hierfür müssen wir die Software-Entwicklungsperformance in der Automobilindustrie dahin bringen, wo sie in der IT-Indus-trie bereits angekommen ist. Hier hat die Automobilindustrie sehr viel nachzuholen, und da wollen wir unseren Beitrag leisten.

Inwiefern ist da Optimierung erforderlich, wo ist Nachholbedarf?

Friedhelm Pickhard: Ein gutes Beispiel hierfür ist ein System aus Motorsteuerung und Abgasnachbehandlung, das im Rahmen der Einführung der Euro-6-Norm in jedem Fahrzeug nicht nur auf dem Prüfstand, sondern auch unter allen realen Fahrsituati-onen garantiert nie die Grenzwerte überschreiten darf. Ein der-art hochkomplexes Problem kann ich nicht durch ein paar Fahr-ten im Raum Berlin oder an sonstigen Orten nachweisen. Viel-mehr muss ich alles statistisch absichern, was sehr teuer ist. Inklusive Vorbereitung dauert eine derartige Testfahrt 12 Stunden. Wenn ich jetzt 1.000 reale Fahrten machen muss, sind das 12.000 Stunden. Es kostet somit immer Zeit und Geld.

ETAS kann heute eine derartige Fahrt auf einem PC hinreichend genau simulieren, sodass die Simulation innerhalb der Genauig-keit einer realen PEMS-Messung liegt. Eine derartige Simulation dauert 12 Minuten auf einem PC. Mit einer Cloud-Lösung können wir bei entsprechender Skalierung diese 1.000 Simulationsfahrten auch in 12 Minuten durchführen. Hinzu kommt nur noch etwas Zeit, um die Daten zusammenzufassen. 12 Minuten Cloud-Simu-lation ersetzen somit 12.000 Stunden realer Testfahrt, und dabei ist das Ergebnis bereits statistisch abgesichert bezüglich der entsprechenden Abgasnormen. Diese Fähigkeit, Systeme zu opti-mieren, bezieht sich nicht nur auf die Abgasnachbehandlung,

Friedhelm Pickhard (hier im Gespräch mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer):

„Wir wollen zur Optimierung von Software, Systemen oder Subsystemen entscheidend beitragen... Hierfür müssen wir die Software-Entwicklungsperformance in der Automobilindustrie dahin bringen, wo sie in der IT-Industrie bereits angekommen ist. Hier hat die Auto-mobilindustrie sehr viel nachzuholen, und da wollen wir unseren Beitrag leisten.“

Alle

Bilde

r: Alfr

ed Vo

llmer

14_ETAS (av).indd 15 10.03.2020 11:54:09

Coverinterview ETAS


sondern kann auch zur Optimierung anderer Systeme eingesetzt werden – inklusive Software-Optimierung.

Ist diese Lösung bereits auf dem Markt?

Friedhelm Pickhard: Wir haben diese Kombination bereits prototy-pisch abgesichert und werden sie im Juni 2020 offiziell auf den Markt bringen. Pilotprojekte mit großen Kunden laufen bereits. Es handelt sich dabei um eine Kombination aus Produkten wie INCA, COSYM und ETAS ASCMO mit Komponenten zum effi-zienten Zusammenführen in der Cloud.

Welche Bedeutung hat Security für ETAS?

Friedhelm Pickhard: Die ETAS-Tochtergesellschaft ESCRYPT ist heute schon der größte unabhängige Security-Provider für Embedded Systeme. Was technisch und in punkto State-of-the-Art möglich ist, um ein Fahrzeug kryptographisch abzusichern, das bietet ESCRYPT an.

Was tut sich in den Bereichen Autosar und Echtzeit-Systeme?

Friedhelm Pickhard: Im Bereich RTA, Real Time Applications, wird es zu Konsolidierungen kommen. Wir sehen in Zukunft drei mögliche Anbieter einer Automotive-Plattform, und bei den Automotive-Betriebssystemen wird es in Zukunft maximal drei Plattformen für die Domain Controller geben. Das bedeutet, dass

sich der Markt aufteilen wird, und wir werden einer der drei Anbieter sein.

Mittlerweile sind wir, obwohl wir Nachzügler waren, der zweit-größte Autosar-Provider auf dem Markt, und im Bereich der ECUs sind wir sogar der größte Anbieter von Echtzeit-Betriebssystemen. Gerade im Bereich ADAS-Frameworks sind wir gut unterwegs, denn wir wollen die Automotive-Middleware für die Domain Controller komplett anbieten. Darauf aufbauend ergänzen die OEMs dann ihr individuelles API (Application Programming Interface, die Redaktion), das dann sowohl fahrzeugbezogen als auch individuell für die OEMs sein wird: in Form eines OEM-Betriebssystems. Alles, was unter dem OEM-Betriebssystem liegt, wollen wir anbieten; das ist unser Anspruch für das ETAS Appli-cation Field RTA.

Was meinen Sie jetzt mit OEM-Betriebssystem genau?

Friedhelm Pickhard: Jeder redet von Betriebssystemen, aber oft-mals gibt es wirklich unterschiedliche Definitionen. Aus diesem

Grund ist es gut, zurück zu den Wurzeln zu gehen und zu schauen, was Betriebssystem in der Informatik heißt. Verein-facht betrachtet, handelt es sich bei Betriebssystemen um eine Software-Infrastruktur, die Rechnerressourcen und/oder Funk-tionsgruppen (Services) – abstrahiert von darunterliegenden Schichten über APIs – zur Verfügung stellt. Beispiele hierfür sind Zugriffe auf Rechnerschnittstellen oder die Bereitstellun-gen von Kommunikationsprotokollen. Jede dieser voneinander unterschiedlichen Software-Infrastrukturen stellt eine Art Betriebssystem mit zunehmender Abstraktion dar.

ETAS bietet hier in diesem Zusammenhang die Autosar-Abstraktionen (Adaptive und Classic sowie Erweiterungen hierzu) und Domain-spezifische Frameworks, beispielsweise für ADAS, an – inklusive der entsprechenden Konfigurations- und entwicklungsbegleitenden Tools.

Security-Komponenten gewinnen zunehmend an Bedeutung und sind selbstverständlich über unsere Tochtergesellschaft ESCRYPT im Angebot. Des Weiteren bieten wir auch die für den gesamtem Software-Stack benötigten Hypervisor und POSIX-Betriebssystemkomponenten über unsere Partner, wie-zum Beispiel BlackBerry QNX, an.

ETAS konzentriert sich somit auf die Bereitstellung vollstän-diger Middleware-Stacks für Automotive-Anwendungen, ins-besondere unter Einhaltung von Echtzeit-, Security- und Safety-

Anforderungen.Wir sehen uns als einer der führenden

Anbieter von diesen Abstraktionen, auf denen dann weitere Frameworks aufbauen, beispielsweise für OEM-spezifische APIs (OEM.OS), die über mehrere Steuergeräte-grenzen hinweg genutzt werden können. Darauf aufbauend können die Applikations-entwickler ihre Aktivitäten entwickeln und Applikationen wie Navigation, Beleuch-tungslogik sowie vieles mehr entwickeln, aber alle greifen auf die Services der API zurück.

ETAS hat den Anspruch, die darunterlie-gende Plattform an die OEMs zu liefern. Mit unserer Mutter-gesellschaft Bosch haben wir auch einen der großen Anwender an unserer Seite, mit dem wir diese Lösungen bereits in Serie bringen.

Wie meistert ETAS den Spagat, als Tochterunternehmen von Bosch

auch viele andere Tier-1s zu beliefern?

Friedhelm Pickhard: Das ist eine gute Frage mit zwei Antworten. Erstens ist die Welt mittlerweile so vernetzt, dass man manchmal Partner, manchmal Zulieferer, manchmal Kunde ist mit den glei-chen Teilnehmern.

Zweitens sind wir seit 25 Jahren im Geschäft mit allen Wett-bewerbern von Bosch. Wir sind unabhängig, sodass wir auch Projekte mit Bosch-Wettbewerbern durchführen. Die einzelnen Projekte sind alle voneinander isoliert und mit einer starken Firewall versehen.

Wir haben nachgewiesen, dass man uns vertrauen kann und dass wir alle Kunden mit der gleichen Priorität bedienen.

Wir sehen in der Automotive-Middleware nebst Tooling ein starkes

Wachstumsfeld und haben unsere Invest-ments entsprechend darauf ausgerichtet.

Friedhelm Pickhard, ETAS

14_ETAS (av).indd 16 10.03.2020 11:54:12

Coverinterview ETAS


InterviewerAlfred VollmerChefredakteur AUTOMOBIL-ELEKTRONIK


Warum kooperiert ETAS mit NI?

Friedhelm Pickhard: Im SiL-Geschäft – also im Bereich Software in the Loop – sind wir gut aufgestellt. Wir arbeiten nun daran, dass die gleiche Software sowohl auf den HiL-Syste-men als auch in der Cloud läuft. Dabei müs-sen wir unsere Kunden bei unseren HiL-Sys-temen mit attraktiver Hardware versorgen – und das geht nur mit den richtigen Econo-mies of Scale. Genau hier passt National Ins-truments (NI) mit seinen vielen Hardware-Komponenten bestens hinein. Deshalb ent-wickeln wir alle neuen HiL-Systeme auf Basis von NI-Hardware. Gleichzeitig erreichen wir durch diese Zusammenarbeit einen viel grö-ßeren Markt.

ETAS hat sich in den letzten Jahren stark

gewandelt. Wie geht es weiter?

Friedhelm Pickhard: Das war ein evolutionärer Prozess, bei dem wir uns permanent an den Marktgegebenheiten orientiert haben. Wir sind in einer Expertennische im SE-Bereich, also beim Software-Engineering. Zusätzlich haben wir das TV-Geschäft – Test & Validation – rund um HiL, Testen und Veri-fikation. Bisher war der Bereich Powertrain unser wirtschaftlich wichtigster Bereich, und dort ging es fast nur um den Verbren-nungsmotor, wo wir auch noch Innovationen sehen, aber wir werden zunehmend unabhängiger von dem klassischen ICE-Geschäft, wobei ICE hier für Internal Combustion Engine steht. Mit dem Thema Security hat unsere Tochtergesellschaft ESC-RYPT ein neues Wachstumsfeld besetzt, in dem ein zweistelliges Wachstum zu verzeichnen ist. Das gesamte Security-Team von ESCRYPT wuchs seit unserer Übernahme in 2012 von anfangs 20 auf heute etwa 350 Mitarbeiter an.

Hinzu kommt die Embedded-Kompetenz, die vor allem im Bereich Safety ein Wachstumsfeld bleiben wird. Mit der zuvor erwähnten Automotive-Middleware sind wir da bestens unter-wegs, indem wir neben den Autosar-Abstraktionen nebst Erwei-terungen auch Domain-spezifische Frameworks, wie zum Beispiel ADAS, anbieten. Wir können hier den gesamten Echtzeit-, Safe-ty- und Security-Unterbau als Komplettlösung liefern. Wir sehen in der Automotive-Middleware nebst Tooling ein starkes Wachs-tumsfeld und haben unsere Investments entsprechend darauf ausgerichtet.

Darüber hinaus unterstützen wir unsere Kunden, die Entwick-lungs-Performance zu steigern, in dem die Software-Verifikati-on, -Validierung und -Optimierung nicht mehr auf der Zielhard-ware oder im Fahrzeug stattfinden muss, sondern kosten- und zeitoptimiert in der Cloud stattfinden kann. Dadurch werden wesentliche Test- und Verifikationsschritte aus dem kritischen Projektpfad genommen. Heute können wir nicht nur automati-sche Software-Entwicklungstools anbieten, die automatisch Code generieren, sondern wir können auch dafür sorgen, dass diese Software safe, secure und testbar ist.

Wir werden unsere Tools so weiterentwickeln, dass wir sie

offen gestalten, um eine Integration in die Entwicklungsketten von OEMs bis zu Tiers zu ermöglichen. Mittlerweile können wir mit unserem Produkt COSYM das gesamte E/E-Netzwerk simulieren. Damit besteht auch die Möglichkeit, im Fahrzeug verteilte Software in ihren Abhängigkeiten und Wechselwir-kungen zu testen sowie in der Cloud zu vali-dieren.

Wie verändert sich die Zusammenarbeit ent-

lang der Entwicklungs- und Lieferkette?

Friedhelm Pickhard: Da wird sich Wesentliches ändern. Noch sind die Fahrzeuge in ihrer Architektur so organisiert wie die OEMs und Zulieferer in ihren Unternehmen organisiert sind. Ich gehe stark davon aus, dass zukünf-tig das Sourcing der Controller-Hardware weitestgehend unabhängig von der Software erfolgen wird. In Zukunft werden vielmehr Elektronik, Software und System-Enginee-ring-Leistung im Einkaufprozess separate Rollen spielen. Zum System-Engineering

zähle ich auch Integration, Test, Software und Hardware. Durch die große Unabhängigkeit im Sourcing werden sich die Geschäfts- und Zusammenarbeitsmodelle ändern. Das wirkt sich auch auf die Zulieferer aus. Insbesondere muss die gesamte Lieferkette eine effiziente Integration und Verifika-tion von Software unterschiedlicher Quellen unter Safety- und Security-Aspekten sicherstellen – bei steigender Komplexität. Hier kommt der Markenkern von ETAS ins Spiel, denn wir wol-len diejenigen sein, die einen Beitrag dazu leisten, dass die Auto-mobilindustrie das Thema Softwarekomplexität effizient, hoch-performant und optimiert beherrscht.

Welche Bedeutung hat denn der Automobil-Elektronik Kongress

in Ludwigsburg für Sie?

Friedhelm Pickhard: In Ludwigsburg bekomme ich extrem effizient einen Überblick über die wirklichen Trends in der Automobil-industrie. Das ist in der Tat auch ein Input für die Strategie-entwicklung. Gleichzeitig ist diese Konferenz eine Gelegenheit, Netzwerke zu bilden und Menschen zu treffen, die ich sonst nicht treffe. Das gilt auch für die anderen ETAS Mitarbeiter, die den Kongress besuchen. Außerdem haben wir dort immer eine sehr gute Möglichkeit, unser Unternehmen in der Ausstellung zu präsentieren. Dieser Event ist ein echtes Highlight und für mich ein Muss. n

12 Minuten Cloud-Simulation ersetzen 12.000 Stunden realer

Testfahrt.Friedhelm Pickhard, ETAS

14_ETAS (av).indd 17 10.03.2020 11:54:15


Security IDS

Angriffe sicher erkennen und abwehrenCybersecurity: Anforderungen an Intrusion-Detection-Systeme im Auto

Viele neue Funktionen im Fahrzeug basieren auf einer umfangreichen Vernetzung von Onboard- und Off-board-Diensten. Damit ergibt sich auch die Herausforderung, das Fahrzeug gegen Cybersecurity-Angriffe zu schützen. Neben den etablierten Security-Mechanismen diskutiert die Branche gerade intensiv den Einsatz von Intrusion Detection Systemen (IDS), für die es im Automotive-Umfeld besondere Herausforderungen gibt. Autor: Dr. Eduard Metzger

Schwachstellen (Vulnerabilities) reagieren muss, die in seinen Fahrzeugen aufgetre-ten sind. Das kann er aber nur, wenn er diese Schwachstellen auch kennt. Dazu können Automotive-IDS beitragen. Diese bestehen aus einem Onboard-IDS in den Fahrzeugen und einem Backend.

Onboard-IDS erkennen potentielle Security-Events im Fahrzeug und unter-stützen deren schnelle Weitergabe an ein Security Operation Center (SOC) beim Fahrzeughersteller. Die dort arbeitenden Security-Experten plausibilisieren die vom Onboard-IDS gelieferten Daten und inte-grieren sie mit den Daten von weiteren gleichartigen Fahrzeugen. Damit erhalten

Für das Absichern von Fahrzeugen gegen unbefugten Zugriff kommen in Zukunft auch Intrusion Detection Systeme (IDS) zum Einsatz. Diese können aber nicht einfach so aus dem IT-Umfeld übernommen werden. Stattdessen müssen automotive-spezifische Anforderungen wie limitierte Rechenleistungen, geringe Speicherkapazität und Echtzeitfähigkeit berücksichtigt werden. Die Standardisierung eines solchen Automotive-Onboard-IDS erleichtert den Datenaustausch zwi-schen Entwicklungswerkzeugen und vereinfacht das firmenübergreifende Umsetzten von Secu-rity-Prozessen zwischen Fahrzeugherstellern, Zulieferern und Security-Experten.

Eck-DATEN

Security ist ein wichtiger Wegbereiter für die sichere Vernetzung von Fahrzeugen. Zunehmend etablieren

sich beispielsweise signierte Software-Updates, sichere OnBoard-Kommunika-tion und Secure Boot. Aktuell rücken Intrusion-Detection-Systeme (IDS) als ein weiterer Security-Mechanismus in den Fokus der Aufmerksamkeit. Obwohl IDS ein lang bekannter Security-Mechanis-mus klassischer IT-Systeme ist, sind sie im Automobil noch nicht fest etabliert.

Fehlende Standardisierung Ein Grund dafür ist deren mangelnde technische Standardisierung. Es gibt kei-nerlei Standards für die Spezifikation von Security-Events (SEvs), deren Verarbeitung und Reporting im Fahrzeug, ihre effizien-te Speicherung und auch keine definierte Onboard-Infrastruktur für das Realisieren von IDS. Außerdem lassen sich die Ent-wicklungsprozesse von IDS-Anbietern häufig nur schwer in existierende Syste-mentwicklungsprozesse bei Fahrzeugher-

stellern und -zulieferern integrieren. Es sind zum Teil Eingriffe in die Steuergerä-tesoftware notwendig, die bereits abge-schlossene Safety-Prozesse torpedieren oder nicht zu der heutigen Aufgabentei-lung zwischen Fahrzeughersteller und -zulieferer passen. Einige IDS-Ansätze verlangen den Einsatz proprietärer Hard-warekomponenten, die die Kosten für IDS explodieren lassen.

Gleichzeitig entsteht aktuell der Stan-dard ISO 21434 (Road vehicles – Cyberse-curity Engineering). Dieser fordert unter anderem einen definierten Incident-Res-ponse-Prozess (Bild 1). Darin ist festgelegt, dass ein Fahrzeughersteller auf Security-

18_Vector (wi).indd 18 10.03.2020 11:55:40

AUTOMOBIL ELEKTRONIK 03/2020 19

Security IDS


sie die Grundlage für eine tiefgehende Analyse der Ereignisse und entscheiden die weiteren Schritte. Auf Basis der Erkenntnisse werden beispielsweise Gegenmaßnahmen implementiert und getestet, die die erkannten Bedrohungen ausschalten. Durch Software-Updates las-sen sich die Gegenmaßnahmen auf den Fahrzeugen der betroffenen Flotte instal-lieren. Dadurch verbessert sich der Schutz vor ähnlichen Angriffen in der Zukunft.

Anforderungen an Automotive-IDSFür Automotive-IDS gelten eine Reihe spe-zifischer Herausforderungen. Zum einen stellt die E/E-Architektur von Fahrzeugen ein verteiltes System dar. Viele bekannte Fahrzeugfunktionen sind erst durch das Zusammenspiel von zwei oder mehr Steu-ergeräten realisierbar. Diese Eigenschaft hat Auswirkungen auf eine mögliche Onboard-IDS-Architektur. Da kein zent-raler Knoten Wissen über alle Security-Events auf anderen Knoten hat, muss das IDS selbst ein verteiltes System sein.

Ein weiterer Punkt, der für ein verteiltes Onboard-IDS spricht, ist die Vermeidung eines Single Point of Failure. In der Steu-ergerätesoftware sind Erkennungsalgo-rithmen implementiert – so genannte Sen-soren. Diese erkennen beispielsweise durch Hacker-Angriffe provozierte Pro-tokollverletzungen. Falls die Security-Sensoren auf einem Steuergerät ausfallen, soll der Rest des IDS noch möglichst ein-schränkungsfrei funktionieren. Deshalb müssen die Schnittstellen zwischen den verteilten Elementen des IDS eindeutig definiert sein.

Eine weitere Herausforderung für ein Automotive-IDS sind die heterogenen Software- und Hardwareplattformen. Die Einführung der Autosar-Adaptive-Platt-form hat auch die Vielfalt der Softwarelö-sungen erhöht. Aus Sicht eines Fahrzeug-herstellers sollten allerdings die Schnitt-stellen und die Security-Event-Definitio-nen möglichst konsistent sein, um das Gesamtsystemdesign nicht unnötig kom-plex zu machen.

Zusätzlich sind in den Steuergeräten die Ressourcen Rechenleistung und Speicher-kapazität äußerst knapp bemessen. Die Entwickler müssen dies gerade beim Ver-arbeiten der Security-Events im RAM als auch bei deren Speicherung im Nichtflüch-

tigen-Speicher (NVRAM) berücksichtigen. Hier sind Optimierungen notwendig, die in klassischen IT-Systemen so nicht anfal-len. Daher nutzen die Automotive-IDS einen Vorverarbeitungsschritt, um die gemeldeten Security-Events zu sammeln und zu qualifizieren – so lange, bis festge-legte Kriterien erfüllt sind. Die Qualifika-tion verhindert das Verschwenden von Ressourcen für irrelevante Security-Events. Das gilt besonders für den Fall, wenn Secu-rity-Events aus dem Fahrzeugnetzwerk über eine Sendestelle, den Intrusion Detec-tion Reporter (IdsR), an ein Backend wei-tergeleitet werden. Daher ist eine wichtige Randbedingung, eine unnötige Belastung des Netzwerks zu vermeiden. Natürlich muss dabei berücksichtigt werden, dass die Qualifizierungen typischerweise unter Echtzeitbedingungen erfolgen.

Letztendlich unterliegt das IDS selbst einer Reihe von Security-Anforderungen. Beispielsweise müssen die einzelnen Ele-mente des verteilten IDS einander vertrau-en können. Dies gilt zum einen für die qualifizierten Security-Events (QSEv), deren Übertragung im Fahrzeugnetzwerk an den IdsR erfolgt. Der IdsR muss über-prüfen, ob das empfangene QSEv von einem authentischen Sender kommt und unverändert empfangen wurde. Falls ein Angreifer QSEv aufzeichnet und wieder-holt abspielt (Replay Attack), muss der IdsR dies erkennen. Auch das SOC auf dem Backend muss den Daten vertrauen, die es von den angeschlossenen Fahrzeugen empfangen hat. Dies wird erreicht, indem der IdsR die Daten vor dem Versenden mit einem fahrzeugspezifischen Schlüssel sig-niert.

Bild 1: Der Security-Standard ISO 21434 fordert einen Incident-Res-

ponse-Prozess für Security-Schwachstellen.

Bild 2: Einbettung des Security Event Memory (SEM) in den Auto-sar-Software-Stack.

18_Vector (wi).indd 19 10.03.2020 11:55:43

20 AUTOMOBIL ELEKTRONIK 03/2020

Security IDS


Außerdem sind sowohl die vom IDS im NVM dauerhaft gespeicherten QSEvs als auch IDS-Konfiguration mit den Regeln für die Qualifizierung von Security-Events schützenswert.

Standardisierung der Intrusion Detection in AutosarEin erster Schritt in Richtung Standardi-sierung wurde schon 2018 mit der Defini-tion von Security-Events in Autosar 4.4 vollzogen. Diese sind seitdem als Spezifi-kationselement in den Autosar-Dokumen-ten verfügbar. Dadurch wurde die Grund-lage dafür geschaffen, dass für jedes Auto-sar-Basissoftwaremodul die von ihm gemeldeten Security-Events im Standard definiert sind. Zudem wurde das Basissoft-waremodul Diagnostic Event Manager (Dem) um spezielle Security-Anforderun-gen erweitert. Neben dem Standard-Dia-

gnosespeicher ist ein Security Event Memory (SEM, Bild 2) konfigurierbar. Es ermöglicht das Speichern von Security-Events in einem getrennten und besonders abgesicherten Bereich. Für das Verwalten der Security-Events kommt weiterhin die existierende Werkzeug- und Prozesskette zum Einsatz.

In der kommenden Autosar-Version 20/11 wird die Standardisierung der Secu-rity-Mechanismen im Rahmen des Kon-zepts für den Intrusion Detection System Manager (IdsM) weiterentwickelt und detailliert. Der Fokus liegt dabei auf den folgenden Aspekten:

• Standardisierung einer High-Level-Architektur für verteilte Onboard-IDS.

• Standardisierung eines Interface für das Melden von Security-Events der Basissoft-waremodule und Applikat ionssoft-warekomponenten an den IdsM.

• Standardisierung von Qualifizierungs-filtern. Diese überführen die von den Sen-soren gemeldeten Security-Events in qua-lifizierteSecurity-Events.

• Standardisierung der Kommunikation zwischen den Modulen IdsM und IdsR.

• Standardisierung konkreter Security-Event-Typen für ausgewählte Basissoft-waremodule.

Integration des IdsM-Moduls in AutosarDas Prinzip des IdsM lässt sich am besten anhand seiner High-Level-Architektur vorstellen (Bild 3). Jeder Knoten der E/E-Architektur kann einen eigenen lokalen IdsM beinhalten. Es können also sowohl Autosar-Classic- als auch Autosar-Adap-tive-Steuergeräte einen IdsM enthalten. Zwischen den einzelnen IdsM besteht kei-nerlei hierarchische Abhängigkeit. Jeder lokale IdsM empfängt die Security-Events seiner lokalen Security-Sensoren. Diese sind entweder hostbasierte oder netzwerk-basierte Sensoren.

Ein Beispiel für einen hostbasierten Sen-sor ist das für Schlüsselmaterial zustän-dige Modul Key Manager (KeyM). Im Sin-ne eines Security-Sensors erzeugt das KeyM Module ein Security-Event, wenn jemand ein Root-Zertifikat installiert, des-sen Gültigkeit abgelaufen oder dessen Signatur nicht valide ist. Ein Netzwerk-basierter Sensor auf einem Gateway-Steu-ergerät überprüft beispielsweise, ob CAN-IDs empfangen wurden, die das Ziel-Netz-werk laut Kommunikationsdefinition nicht erreichen sollen.

Relevante Security-Events leitet der lokale IdsM an den IdsR weiter. Der IdsR überträgt die Security-Events an das Secu-rity Operation Center. Welche Knoten der E/E-Architektur über einen IdsM verfügen ist eine Entscheidung, die der Fahrzeug-hersteller im Laufe des Security-Enginee-ring-Prozesses trifft.

Zum besseren Verständnis lohnt sich ein Blick auf die Integration des IdsM in die Autosar-Classic-Architektur (Bild 4). Die blauen Pfeile zeigen Verbindungen von beispielhaften Modulen mit Security-Sensoren zum IdsM. Nach der Qualifika-tion der Security-Events im IdsM werden je nach Konfiguration die QSEv dauerhaft im Steuergerät gespeichert oder via IdsR an das SOC gesendet. Das Speichern

Bild 3: High-Level-Architektur eines Onboard-IDS mit einer beispielhaften Verteilung der Module auf Steuergeräte.

Bild 4: Integration des IdsM in die Autosar-Classic-Architektur. Al

le Bil

der: V

ecto

r Infor

mati

k

Damit sich Hackern keine Mitfahrgelegenheit bietet.

secunet Pentest macht vernetzteFahrzeuge premiumsicher.

Wo Schwächen im Code und Angri s� ächen aufgespürt werden müssen, steht secunet bereit. Mit praxiserprobten Testverfahren überprüfen wir herstellerunabhängig vernetzte Fahrzeuge und Komponenten und geben konkrete Empfehlungen für Premiumsicherheit auf der Straße.

secunet – Ihr Partner für IT-Premiumsicherheit.

18_Vector (wi).indd 20 10.03.2020 11:55:46

Security IDS

AutorDr. Eduard Metzker Produktmanager Vector Cybersecurity Solutions bei Vector Informatik


erfolgt im Security Event Memory (orange Pfeile). Für das Ablegen der Daten verwen-det das Sem-Modul den Non Volatile RAM Manager (Nvm). Optional kann der Nvm die Daten verschlüsseln (grüne Pfeile) und so ablegen, dass der IdsM Manipulationen erkennt. Zusätzlich zur lokalen Speiche-rung lassen sich QSEv über den PduR an den IdsR schicken (braune Pfeile).

Auf Basis dieser Grundarchitektur las-sen sich Onboard-IDS entwickeln, mit denen eine angemessene Balance zwi-schen der Verfügbarkeit von Ressourcen und den benötigen Security-Event-Daten erreicht wird. Dazu muss das IDS ein hohes Maß an Konfigurierbarkeit bieten, beispielsweise durch Anpassen der fol-genden Aspekte für jedes Security-Event: Qualifizierungsregeln, lokale, dauerhafte Speicherung der QSEv – ja oder nein – und Weiterleitung der QSEv an den IdsR – ja oder nein.

AusblickAuf Basis der genannten Anforderungen hat Vector einen Designvorschlag für ein

verteiltes Automotive-Onboard-IDS zur Standardisierung in Autosar erstellt. Die-ser Designvorschlag adressiert die darge-stellten Randbedingungen und funktio-nalen Anforderungen. Parallel zur Stan-dardisierung in Autosar entwickelt Vector eine standardkonforme IDS-Lösung als Teil seiner Autosar-Basissoftware Micro-sar. Diese Implementierung wird schon vor dem Release des Standards Autosar 20/11 verfügbar sein.

Die Standardisierung von Automotive-Onboard-IDS bietet einen großen Mehr-wert für Automotive-Security. Dadurch ergibt sich die Chance auf ein nachhaltiges und robustes Ökosystem für Automotive-IDS, in das Hersteller, Zulieferer und Secu-rity-Experten ihre spezifischen Stärken einbringen: Die Fahrzeughersteller defi-nieren Ihre Security-Anforderungen. Basissoftware-Hersteller bringen ihre Expertise ein, um die technische Infra-struktur rund um IdsM, IdsR und Securi-ty-Sensoren in den Basissoftware-Modu-len effizient zu implementieren. Und die Security-Experten beteiligen sich mit

Ihren Kompetenzen zum Definieren von fortschrittlichen Security-Sensoren, die beispielsweise auf Künstlicher Intelligenz (KI) basieren, als auch mit innovativen Qualifizierungsregeln für Security-Events. Diese Zusammenarbeit wird durch das im Rahmen der Standardisierung definierte Austauschformat Security Extract (SecXT) vereinfacht. Das SecXT erleichtert den Datenaustausch zwischen Entwicklungs-werkzeugen und vereinfacht das firmen-übergreifende Umsetzten von Security-Prozessen. So wird die Aufgabenteilung zwischen Fahrzeugherstellern und Zulie-ferern beim Thema Security auf eine neue Ebene gehoben. (na) ■

Damit sich Hackern keine Mitfahrgelegenheit bietet.

secunet Pentest macht vernetzteFahrzeuge premiumsicher.

Wo Schwächen im Code und Angri s� ächen aufgespürt werden müssen, steht secunet bereit. Mit praxiserprobten Testverfahren überprüfen wir herstellerunabhängig vernetzte Fahrzeuge und Komponenten und geben konkrete Empfehlungen für Premiumsicherheit auf der Straße.

secunet – Ihr Partner für IT-Premiumsicherheit.

18_Vector (wi).indd 21 11.03.2020 10:33:55


Security Grundlagen

Sicherheit ist die Aufgabe von FührungskräftenSafety- und Security-Management: die Grundlagen

Die Automobilindustrie befindet sich in einem Umbruch, wahrscheinlich dem größten, den diese Branche je gesehen hat. Megatrends, wie Vernetzung, Elektrifizierung des Antriebs-strangs und autonomes Fahren erhöhen die Risiken in Form von Technologiemissbrauch. Es ist deshalb speziell für Führungskräfte wichtig, die Bedeutung von Safety und Security zu verste-hen – sowohl hinsichtlich Software als auch der Hardware. Autor: Stephan Janouch

• Wird das in Frage kommende Bauteil von den darüber liegen-den (sicheren) Software-Schichten unterstützt? Oder müssen potenziell unsichere Anpassungsschichten eingefügt oder Ände-rungen vorgenommen werden?

• Kann der Sicherheitsaspekt über die gesamte Wertschöpfungs-kette dargestellt werden, das heißt von der Halbleiter-Fab über Assemblierung, Packaging, Testing, Lagerung, Distribution bis hin zur Unterstützung im Feld?Die spezifischen Anforderungen und damit die genaue Frage-stellung kann natürlich von Projekt zu Projekt variieren, aller-dings sollte kein Gesichtspunkt völlig außer Acht gelassen wer-den, da dies einen deutlichen Einfluss auf die übergreifende Sicherheitsarchitektur hätte.

Safety und SecurityZunächst ist es wichtig herauszustellen, dass es in den meisten Fällen von Vorteil ist, die englischen Begriffe Safety und Securi-ty anstelle des deutschen Wortes Sicherheit zu nutzen. „Sicher-heit“ deckt nicht eindeutig sondern nur kontextabhängig beide

Der Wandel scheint dieser Tage die einzige Konstante innerhalb der automobilen Landschaft darzustellen. Während in der Vergangenheit Markttrends bestimm-

te Technologieaspekte beeinflussten, lassen sich die derzeit dis-kutierten, sogenannten Megatrends, nicht unabhängig vonein-ander betrachten. Getrieben von deren gegenseitigen Wechsel-beziehungen, arbeitet die Industrie an elektrisch angetriebenen Fahrzeugen, die sich autonom bewegen während sie mit anderen Fahrzeugen, Infrastruktureinrichtungen oder der Cloud verbun-den sind. Das ultimative Ziel dieser Anstrengungen: günstige, sichere und ökologisch verträgliche Mobilität für Jedermann.

Allerdings bringt diese sehnsüchtig erwarte Fahrzeugkate-gorie nicht nur Vorteile für den Nutzer mit sich, sie beinhaltet gleichzeitig ein erhebliches Risikopotenzial: fahrlässiger oder vorsätzlicher Missbrauch kann zu einer Reihe von Konsequen-zen führen, von einzelnen Personenschäden, Einbußen hin-sichtlich des Vertrauens in den Kfz-Hersteller, oder im Falle eines Angriffs auf eine Fahrzeugflotte, Lösegeldforderungen, bis hin zum Einsatz derselben als Massenvernichtungswaffe.

Es ist deshalb nicht nur ratsam, sondern eine zwingende Not-wendigkeit für Führungskräfte, die Zusammenhänge zwischen Safety und Security zu verstehen, sowohl für Software als auch für Hardware, ebenso wie deren Bedeutung und die daraus resul-tierenden Handlungsempfehlungen. Dieser Beitrag beschreibt:

• Unterschied und Wechselwirkungen zwischen Safety und Security

• Schlechte Safety-/Security-Planung als Wurzel alles Übels

• Die Bedeutung von Zertifizierungen

• Rechtliche ImplikationenDer Fokus liegt dabei auf den Safety- und Security-Aspekten von Software, wobei sich die meisten der hier vorgestellten Prinzipi-en ebenso anwenden lassen, wenn es um die Auswahl der rich-tigen Hardware-Plattform für ein sicherheitskritisches Projekt geht. Allerdings bedarf es für die Bewertung von in Frage kom-menden Bauteilen, wie beispielsweise Prozessoren, noch einer genaueren Untersuchung. Hierbei sind gegebenenfalls die fol-genden drei Aspekte zu betrachten:

• Unterstützt das Bauteil (beziehungsweise enthält es die ent-sprechenden Module und Funktionsblöcke) alle benötigten Funk-tionen, zum Beispiel Secure Boot, Key Storage, HSM (Hardware Security Module), MMU (Memory Management Unit)?

Bild 1: Mehrschichtige Verteidigungsstrategie: Security muss auf jeder Schicht einer Software-Architektur Anwendung finden. Beginnend vom Betriebssystem als Kern bis zu den höheren/äußeren Schichten.

22_Green Hills (wi).indd 22 10.03.2020 11:57:36


Security Grundlagen


Bereiche ab und die gelegentlich genutzten Begriffe Funktions-sicherheit (Safety) und Datensicherheit (Security) können für Verwirrung sorgen.

Safety beziehungsweise Functional Safety dient vereinfacht dargestellt dazu, die Wahrscheinlichkeit zu verringern, mit der eine Maschine, also beispielsweise ein Fahrzeug, eine Person verletzt. Dazu wird eine detaillierte Beschreibung aller Nutzungs-szenarien und -risiken erstellt, sowie Maßnahmen ergriffen, um diese Risiken zu minimieren beziehungsweise zu eliminieren und das erwünschte Systemverhalten zu gewährleisten.

Verschiedene Techniken lassen sich einsetzen, die dafür sorgen sollen, ein vorhersehbares Systemverhalten zu erreichen, zum Beispiel soll ein Notbremsassistent eine Vollbremsung auslösen, falls bestimmte Objekte die Trajektorie des Fahrzeugs kreuzen (Bild 2). Dies betrifft etwa Personen, andere Fahrzeuge oder Gebäude, allerdings keine kleinen Objekte wie Bierdosen oder Müllsäcke. Im Rahmen des Entwicklungsprozesses setzt man dazu auf Anforderungsnachverfolgung/-monitoring, Design- und Code-Reviews und natürlich umfangreiche Funktionstests.

Es ist an dieser Stelle anzumerken, dass ein hoher Grad an Safety bei einem vernetzten System nur dann erreicht werden kann, wenn auch das Thema Security entsprechend adressiert wird (natürlich ist Security auch in nicht-vernetzten Systemen wichtig, allerdings ist hier die Zahl der potenziellen Bedrohungen und der daraus resultierende Aufwand deutlich niedriger).

Security wiederum soll sicherstellen, dass niemand, als Ergeb-nis einer inadäquaten Software-Architektur oder eines mangel-haften Entwicklungsprozesses, einem gegebenen System schaden oder es in schädlicher Weise beeinflussen kann. In anderen Wor-ten schützen Security-Mechanismen ein System, so dass es die ihm zugedachten Funktionen erfüllen kann, ohne von einer dritten Person beeinflusst zu werden, was letztendlich zu einem unsicheren (unsafe) Betriebsverhalten führen könnte.

Dies lässt sich an einem Kamerasystem veranschaulichen, das zur Verkehrszeichenerkennung genutzt wird. Würde ein Hacker etwa die Referenzdaten manipulieren, die herangezogen werden, um die Bedeutung von Verkehrsschildern (zum Beispiel Tempo-limit) zu erkennen, könnte das System eine falsche erlaubte Höchstgeschwindigkeit annehmen und in dessen Folge den Temporegelautomaten falsch anleiten, was letztendlich das Unfallrisiko erhöhen würde oder sogar zu einem Unfall führen

Saftey und Security sind zwei Paar Schuhe, die zwar auf den ersten Blick nichts miteinander zu tun haben, aber bei der Entwicklung – in jeder Hin-sicht – sicheren Systemen nicht ge-trennt betrachtet werden können. Im Gegenteil: Gerade die komplexe Ver-flechtung von Saftey und Security sorgt dafür, dass die beiden Aspekte von Anbeginn einer Entwicklung be-rücksichtigt und in den Entwicklungs-prozess mit einbezogen werden müs-sen. Gerade Führungskräfte sind hier besonders gefordert.

Eck-DATEN

könnte. In einem korrekt aufgebauten System wäre es allerdings für einen Hacker nicht möglich, Zugang zu safety-kritischen Daten oder Funktionen zu erlangen, da diese von nicht-kritischen Komponenten separiert wären.

Während innerhalb der Automobilindustrie mittlerweile ein tiefgreifendes Verständnis hinsichtlich der Anforderungen an ein sicheres (safe) System existiert, ist das beim Thema Security nur bedingt der Fall, zumal auch noch eine andere Herangehens-weise notwendig ist. Zunächst ist es wichtig, alle sicherheitskri-tischen (safe) Funktionen (Fahrerassistenzsysteme, Telltales im Kombiinstrument) zu identifizieren, und sie von nicht-kritischen Funktionen (zum Beispiel Radio) zu trennen. Einem Hacker wäre zwar der Zugang zu offenen, nicht-kritischen Teilen des Systems möglich, alle sicherheitskritischen Funktionen verbleiben aber in einen entsprechend geschützten, nicht-zugänglichen Bereich.

Ein System kann als sicher (im Sinne von Safety) betrachtet werden, falls während der Entwicklung alle entsprechenden Standards und Normen, sowie Test- und Verifikationsmethoden zum Einsatz kommen (vorausgesetzt es gibt keine gravierenden Änderungen der Umgebungsbedingungen, die Auswirkungen auf das ursprüngliche Safety-Konzept hätten). Security bezie-hungsweise Security-Maßnahmen unterliegen demgegenüber einem steten Wandel. Die zunehmende Vernetzung von Fahr-zeugsystemen mit Consumer- oder Netzwerkinfrastruktur öffnet quasi täglich neue Einfallstüren für Hacker und gewährt zumin-dest indirekten Zugang zu verschiedenen Steuergeräten. Gleich-zeitig wird die Schutzfunktion etablierter Verschlüsselungsalgo-rithmen durch die Verfügbarkeit praktisch unbegrenzter Rechen-leistung ausgehebelt.

Obwohl ein gewisser Anteil an Security-Funktionen über die Betriebsdauer eines Fahrzeugs stabil bleibt, müssen spezielle Verteidigungsmechanismen oder kryptografische Verschlüsse-lungsalgorithmen bedarfsabhängig aktualisiert werden. Ironi-scherweise birgt die Funktion zur Software-Aktualisierung per Funkschnittstelle (over-the-air update, OTA), was sowohl aus wirtschaftlichen Gründen als auch bezüglich Safety/Security nötig sein kann, ebenso Security-Risiken, falls deren Implemen-tierung Mängel aufweist. Dies ist eine reale Bedrohung, vor allem für die Millionen von Fahrzeugen, bei denen keine zuverlässige Separierung beziehungsweise Isolation von sicherheitskritischen Funktionen vorgenommen wurde.

Bild 2: Ein Not-bremsassistent soll eine Voll-bremsung auslö-sen, falls be-stimmte Objekte die Trajektorie des Fahrzeugs kreuzen.

Bilde

r: Gree

n Hills



Security Grundlagen


Safety- und Security-PlanungSafety- und Security-Planung teilen sich eine Gemeinsamkeit: in beiden Fällen ist es unabdingbar, schon zu Beginn des Ent-wicklungsprojekts mit der jeweiligen Planung zu starten. Wie bereits beschrieben, ist eine korrekt ausgeführte Systemarchi-tektur ein wesentlicher Bestandteil, um ein hohes Safety- und Security-Niveau zu erreichen. Zusätzliche Funktionen oder Eigen-schaften, welche Safety oder Security verbessern sollen, können nur schwerlich zu einem späteren Zeitpunkt hinzugefügt werden; wenn überhaupt möglich, dann nur in Verbindung mit hohen Kosten und signifikantem Risiko.

Speziell bei hohen Security-Anforderungen ist eine frühzeiti-ge (sprich: vor Projektbeginn) Planung essenziell für den Pro-jekterfolg. Man kann dies mit dem Versuch vergleichen, ein neu-es, zusätzliches Steuergerät in die E/E-Architektur eines sich bereits in Produktion befindlichen Fahrzeugs integrieren zu wollen. Dabei verursacht nicht in erster Linie die physische und elektrische Integration Aufwand und Kosten, sondern die gegen-seitigen Verflechtungen und Abhängigkeiten mit anderen Steu-ergeräten (beziehungsweise Steuergerätefunktionen) und der daraus resultierende Testaufwand. Die Integration in einen in der Regel komplizierten Produktionsprozess mit entsprechenden notwendigen Modifikationen erzeugt zusätzlichen Stress bei allen Beteiligten.

Zwei Methoden haben sich in diesem Zusammenhang als sehr wertvolle Herangehensweisen bewährt: Inside-out-Security und Security-in-Depth. Security-in-Depth ist von einer altbewährten, militärischen Abwehrstrategie abgeleitet, bei der davon ausge-gangen wird, dass jeder Abwehrmechanismus durchbrochen wird und deshalb ein schichtweiser Aufbau der Abwehrmaß-nahmen sinnvoll ist (Bild 1). Übertragen auf die Fahrzeugsyste-me bedeutet dies, dass die kritischen Teile des Systems durch mehrere übereinanderliegende, aber unterschiedliche Security-Mechanismen geschützt werden.

Inside-out-Security ist ein hierzu symbiotischer Ansatz, der empfiehlt, bei der Zusammenstellung der verschiedenen Schutz-mechanismen im Kern des Systems beziehungsweise auf der

untersten Ebene zu beginnen. Dabei werden zunächst Bereiche des Systems identifiziert, die geschützt werden müssen. Diese kritischen Teile werden dann von den nicht-kritischen Teilen über entsprechende Software- oder Hardware-Separierungs-funktionen voneinander getrennt. Security-in-Depth sollte nicht als Ersatz für eine Inside-out-Security-Herangehensweise dienen, es dient vielmehr als Erweiterung zum prinzipiellen Ansatz der Trennung von kritischen/nicht-kritischen Systembestandteilen.

ZertifizierungenJede Branche hat im Laufe der Zeit ihre eigenen Normen und Zertifizierungen hervorgebracht, wie beispielsweise die Auto-mobilindustrie die Norm ISO26262 für funktionale Sicherheit oder die kommende ISO/SAE21434 für Cybersecurity-Anwen-dungen im Fahrzeug. Es ist empfehlenswert diesen Normen zu folgen und dabei zwei Punkte zu beachten:

• Ein System, welches komplett aus beziehungsweise mit gemäß ASIL D zertifizierten Komponenten und Werkzeugen zusam-mengesetzt wird, ergibt nicht automatisch ein Gesamtsystem, welches sich ebenfalls nach ASIL D zertifizieren lässt. Neben der sicher sinnvollen Verwendung von vor-zertifizierten Komponen-ten, ist der eigentliche Systemaufbau mindestens genauso wich-tig. Der Vorteil von vor-zertifizierten Komponenten oder Modu-len liegt darin, dass sich die Zertifizierung des Gesamtsystem, zum Beispiel gemäß ASIL D, schneller und zu niedrigeren Kos-ten durchführen lässt.

• Ein vorhandenes Zertifikat kann dabei helfen, Aussagen über eine einzusetzende Komponente zu verifizieren und gegebenen-falls verschiedene Angebote zu vergleichen. Speziell bei der Ent-wicklung von hochsicheren (secure) Systemen ist die Auswahl der richtigen Komponenten, zum Beispiel die Wahl des richtigen Betriebssystems, von entscheidender Bedeutung. So erscheint es sehr unwahrscheinlich, dass sich ein sicheres (secure) System auf Basis eines Betriebssystems entwickeln lässt, welches ledig-lich gemäß EAL4+ (Evaluation Assurance Level) oder sogar niedriger zertifiziert ist (Bild 3). Um die größtmögliche Security zu erreichen, ist es angeraten auf ein Betriebssystem mit „Sepa-ration Kernel Architektur“ zu setzen, wie sie beispielsweise das Echtzeitbetriebssystem Integrity-178 von Green Hills Software bietet. Integrity-178 ist das einzige kommerziell verfügbare Echt-zeitbetriebssystem, welches gemäß EAL 6+ zertifiziert ist und damit eine absolut sichere Basis für die darüber liegenden Soft-ware-Schichten bietet. Die richtige Wahl bezüglich der untersten Software-Schicht ist entscheidend für die Sicherheit des Gesamt-systems, da das Echtzeitbetriebssystem nicht nur alle Hardware-Ressourcen kontrolliert, zum Beispiel Speicher- und Kommuni-kationsschnittstellen, sondern gleichzeitig auch verschiedene Funktionen beziehungsweise Applikation voneinander separiert, was gleichzeitig das System vor einem Angreifer schützt, der unter Umständen bereits die Schutzmechanismen einer einzel-nen Software-Partition überwunden hat.

Rechtliche ImplikationenTraditionell wird im Falle eines Verkehrsunfalls der Fahrzeug-führer zur rechtlichen Verantwortung gezogen (ein Grund für die Einführung der Haftpflichtversicherung). Bezogen auf den

Bild 3: Evaluation Assurance Levels entsprechend der Common Criteria Se-curity-Evaluierung. Typischerweise bezeichnet ein „+“ angehängt an die Einstufung, dass das entsprechende Produkt über die jeweilige Stufe hin-aus, weitere Anforderungen erfüllt.

EAL1 Functionally tested No security related threats expected.

EAL2 Structurally tested Design according to good practice. No substantial investment in dedicated security measures.

EAL3 Methodically Tested and Checked

Moderate level of assured security.

EAL4 Semiformally Designed, Tested and Reviewed

Moderate to high level of assured security. Highest economically feasible level for retrofit.

EAL5 Semiformally Designed and Tested

High level of assured security. System specifically designed to reach EAL5.

EAL6 Semiformally Verified Design and Tested

Security for high-value assets against significant risks.

EAL7 Semiformally Verified Design and Tested

Security for extremely high risk and/or high value assets (whose value justi-fies the higher costs).

Quell

e: W

ikipe

dia



Discover Innovation in Motion

AUTOMOTIVE Produkte

RUTRONIK AUTOMOTIVE bietet innovative Produkte führender Hersteller für die Automotive Industrie. RUTRONIK AUTOMOTIVE bringt komplette Lösungen für folgende Themenbereiche:

Body & Convenience Drive Train Chassis & Safety Connected Car eMobility Consulting

Informationen unter: www.rutronik.com/[email protected] | Tel. +49 (0) 7231 801-1552

Connected Car

Consulting

Body & Convenience

Drive Train

eMobility

Chassis & Safety

derzeitigen Trend von Fahrerassistenzsystemen hin zum auto-nomen Fahren, verschiebt sich die Verantwortung allerdings kontinuierlich in Richtung Fahrzeugproduzent, also OEM. Für diesen gestaltet sich diese Situation dahingehend schwierig, dass er nicht in allen Fällen einen kompletten Einblick in die genaue Implementierung einer speziellen Funktion hat, vor allem wenn diese Funktion auf große Mengen von Applikations-Software zurückgreift. Natürlich wird ein Großteil der eingesetzten Soft-ware vom OEM kontrolliert, zum Beispiel der Kommunikations-Stack, um Interoperabilität zwischen verschiedenen Steuergerä-ten zu garantieren, die wiederum von verschiedenen Zulieferern stammen können, aber in vielen Fällen handelt es sich um pro-prietäre Software, deren genauer Aufbau dem OEM nicht bekannt ist. Das bedeutet, dass der OEM – trotz sorgfältiger Spezifikati-on, Test und Validierung – der Kompetenz des Zulieferers ver-trauen und im Falle von schweren Defekten, Schadensersatzfor-derungen an diesen weiterreichen muss.

Um sich gegen derartige rechtliche Schritte und/oder Prozes-se zu schützen, müssen Zulieferer bei der Auswahl von Hardware, Software, Prozessen und auch Werkzeugen mit äußerster Vorsicht vorgehen. Dabei ist generell zu unterscheiden zwischen den „anerkannten Regeln der Technik“, „Stand der Technik“ sowie „Stand von Wissenschaft und Technik“. Obwohl diese drei Begrifflichkeiten in vielen Fällen wahllos untereinander ausge-tauscht werden, unterscheidet sich deren Bedeutung deutlich – eine Tatsache, die speziell bei der Ausformulierung eines Werk-vertrages nicht ignoriert werden sollte.

Die unterste Stufe dieser „Drei-Stufen-Theorie“ hört auf den Namen „anerkannte Regeln der Technik“ und enthält diejenigen Werkzeuge und Methoden, die in der Praxis am weitesten ver-breitet sind. Eine wissenschaftliche Bestätigung beziehungswei-se Überprüfung, ob diese den besten Weg darstellen, um ein bestehendes Problem zu lösen, ist nicht notwendig.

„Stand der Technik“ nähert sich dem an, was zumindest the-oretisch möglich ist. Dies beinhaltet Methoden und Werkezeuge, die nach wissenschaftlichen Gesichtspunkten, den effizientesten und fortschrittlichsten Lösungsansatz bieten.

„Stand von Wissenschaft und Technik“ stellt die höchste Stu-fe dar und enthält alle neuen Erfindungen und Technologien, wobei kein Augenmerk auf deren technisch oder ökonomisch sinnvollen Einsatz gelegt wird.Entsprechend dieser feinen Unterschiede ist es mehr als anzu-raten, Anforderungs-Management mit größtmöglicher Sorgfalt zu betreiben. Anforderungen, speziell in Bereichen, in denen Richtlinien oder rechtliche Rahmenbedingungen lückenhaft sind oder ganz fehlen, sollten sehr präzise und eindeutig formuliert werden. (wi) ■

Autor Stephan Janouch Senior Manager Business Development EMEA, Green Hills Software




Security Managementsysteme


Cybersicherheit in voller FahrtAutomotive Cybersecurity-Management

Durch diverse Cyberangriffe ist die IT-Sicherheit von Autos ins Blickfeld des Gesetzgebers gelangt. Eine Ar-beitsgruppe der Vereinten Nationen entwickelt derzeit eine Regulierung, welche für die gesamte Branche ei-nen Paradigmenwechsel darstellt: Die Typgenehmigung von Fahrzeugen wird künftig nur noch mit Zertifizie-rung eines Cybersecurity-Managementsystems möglich sein. Cybersicherheit rückt damit auf die Agenda eines jeden Automobil-CEOs. Autoren: Dr. Moritz Minzlaff, Dr. Christopher Kusch, Hans-Peter Fischer

Mittlerweile werden fortlaufend Angrif-fe bekannt, die sich insbesondere die zunehmende Digitalisierung und Kon-nektivität der Fahrzeuge und der dadurch wachsenden Angriffsf läche zunutze machen (Bild 1). Immer deutlicher zeigt sich, welches Risiko nicht ausreichend geschützte Fahrzeuge für Hersteller, Besit-zer und Verkehrsteilnehmer bergen. Längst ist auch klar, dass Automotive Cybersecurity einer ganzheitl ichen Betrachtung und Orchestrierung über alle Instanzen und den gesamten Lebenszyk-lus des Fahrzeuges hinweg bedarf (Bild 2).

Einer der ersten veröffentlichten Hacks eines Automobils gelang 2009 einer Gruppe von Wissen-

schaftlern um Stephen Checkoway. Sie beschrieben, wie sie einen Laptop an einen Kontrol lzugang des Autos anschlossen, um auf das fahrzeuginterne Netzwerk zuzugreifen. Dadurch waren sie in der Lage, kritische Systeme des Autos zu manipulieren, konnten bei-spielsweise den Motor abschalten oder die Bremsen blockieren. Noch kritischer wurde es 2015, als Charlie Miller und Chris Valasek es schafften, einen Jeep

Cherokee ferngesteuert zu übernehmen. Über das Entertainment-System des Geländewagens erlangten sie Kontrolle über Multimediasysteme, Scheibenwi-scher, Kl imaanlage, Bremsen und Geschwindigkeit des Fahrzeugs. Sie stoppten das Auto, dessen Fahrer als Tes-ter angeheuert war, mitten auf der Auto-bahn. Dazu mussten sie sich nicht per Kabel mit dem Auto verbinden, sondern nutzten die Internetverbindung des Wagens. Chrysler musste im Anschluss circa 1,4 Millionen Fahrzeuge zurückru-fen und nachbessern.

Bild:

hxdy

l | Sh

utter

stock

, Esc

rypt

26_Escrypt (av).indd 26 10.03.2020 11:59:33


Neue Vorgaben für Cybersicher-heit von FahrzeugenWeltweit laufen daher Bestrebungen, Cybersicherheit weiter zu regulieren und zu standardisieren. So gibt es etwa Geset-zesinitiativen im US-Kongress, den Cybersecurity Act in der EU, das chine-sische ICV-Programm und neue Richtli-nien von JASPAR in Japan. In all diesen Regularien lassen sich drei wesentliche Trends erkennen:

• Eine stärkere Konkretisierung von Cybersicherheit auf Spezifika der Auto-mobilindustrie,

• die Anforderung, die Sicherheit der Fahrzeuge im Feld aufrecht zu erhalten, sowie

• der zunehmend verpflichtende Charak-ter der Vorgaben und deren Überprüfung zum Zeitpunkt der Typgenehmigung.

Diese Trends manifestieren sich insbeson-dere in der aktuellen regulatorischen Ini-tiative der UNECE WP.29 TF-CS/OTA und der kommenden Norm ISO/SAE 21434, die explizite Managementsysteme zum Schutz von Fahrzeugen definieren.

Die Typgenehmigung von Fahrzeugen wird künftig nur noch mit Zertifizierung eines Cybersecu-rity-Managementsystems möglich sein. In Anbetracht typischer Entwicklungszeiten im Automo-bilbereich müssen sich Hersteller und Zulieferer also bereits heute mit diesen Cybersicherheits-anforderungen auseinandersetzen, um die Typgenehmigung für ihre nächsten Produkte sicher-stellen zu können. Das Problem dabei: Experten, die sowohl Cybersicherheit als auch die speziel-len Anforderungen der Automobilindustrie verstehen, sind rar.

Eck-DATEN

UNECE WP.29 TF-CS/OTADas Weltforum für die Harmonisierung von Fahrzeugvorschriften der Vereinten Nationen (WP.29) entwickelt derzeit ein Regelwerk, das Cybersicherheit relevant für die Genehmigung neuer Fahrzeugty-pen macht. Der Vorschlag der Unterarbeits-gruppe TF-CS/OTA besteht aus zwei Kern-forderungen: Dem Betrieb eines zertifi-zierten Cybersecurity-Managementsys-tems (CSMS) sowie der Anwendung des CSMS auf den konkreten Fahrzeugtyp zum Zeitpunkt der Typgenehmigung. Die EU plant, die Einhaltung dieser Vorgaben für neue Fahrzeugtypen bereits ab Mitte 2022 einzufordern und später auf Bestandsar-chitekturen auszudehnen.

In Anbetracht typischer Entwicklungs-zeiten im Automobilbereich müssen sich Hersteller und Zulieferer also bereits heu-te mit diesen Cybersicherheitsanforderun-gen auseinandersetzen, um die Typgeneh-migung für ihre nächsten Produkte sicher-stellen zu können. Dazu müssen sie einen risikobasierten Ansatz verfolgen, der durchgängig für den Fahrzeugtyp, dessen

PCAN-USB X6Sechskanal-CAN-FD-Interface für USB. Auslieferung mit D-Sub- oder M12-Anschlüssen inkl. Software, APIs und Treiber für Windows® und Linux.

ab 735 €

PCAN-USB X6Sechskanal-CAN FD-Interface

PCAN-USB X6

PCAN-Explorer 6Professionelle Windows®-Software zur Steuerung und Überwachung von CAN-FD- und CAN-Bussen.

ab 510 €

PCAN-Router FDFrei programmierbarer Router für CAN und CAN FD mit 2 Kanälen. Erhältlich mit D-Sub- oder Phoenix-Anschlusssteckern inklusive Entwicklungspaket.

250 €

You CAN get it...Hardware und Software für CAN-Bus-Anwendungen…

All

e P

reis

e ve

rste

hen

sic

h z

zgl.

Mw

St.

, Po

rto

un

d V

erp

acku

ng

. Irr

tüm

er u

nd

tec

hn

isch

e Ä

nd

eru

ng

en v

orb

ehal

ten

.

www.peak-system.com

Otto-Röhm-Str. 6964293 Darmstadt / Germany

Tel.: +49 6151 8173-20Fax: +49 6151 8173-29

[email protected]

Bild 1: Die Zahl der Angriffsvektoren für potenzielle Cyberattacken wächst mit zunehmender Vernet-zung des Fahrzeugs und seines Ökosystems eklatant.

26_Escrypt (av).indd 27 12.03.2020 08:15:41




externe Schnittstellen und dessen Subsys-teme ein angemessenes Risikoniveau ermitteln, erreichen und erhalten kann. Zu berücksichtigen sind hierbei ausdrück-lich auch die Security-relevanten Abhän-gigkeiten und Informationen von Zuliefe-rern, Dienstleistern und weiteren Dritten.

Angesichts eines sich stetig wandelnden Bedrohungsumfelds und langer Fahrzeug-lebenszyklen fokussiert das geforderte CSMS insbesondere auch auf die Phase

spezifika (siehe Infobox „ISMS und CSMS“): Zum einen sind Produkt und Lieferkette überaus komplex. Zum anderen unterliegt das Fahrzeug ganz spezifischen kritischen Aspekten wie etwa den Wech-selwirkungen mit funktionaler Sicherheit, der Einhaltung von Umweltvorschriften und dem Diebstahlschutz.

ISO/SAE 21434Parallel zur TF-CS/OTA erarbeitet die Automobilindustrie im Rahmen der Inter-nationalen Organisation für Standardisie-rung (ISO) und des Verbands der Automo-bilingenieure (SAE) den Standard ISO/SAE 21434 für Cybersicherheit von Fahrzeugen. Genau wie das durch die WP.29 definierte CSMS legt diese Norm das Augenmerk auf die notwendige Organisation und richtigen Prozesse, um das Fahrzeug entlang Seines kompletten Lebenszyklus vor Cyberatta-cken zu schützen. Da ein Begleitdokument des UN-Regulierungsentwurfs konse-quent auf diesen Standard zur Umsetzung der CSMS-Anforderungen verweist, ver-dient die ISO/SAE 21434 besondere Auf-merksamkeit. Mit einer gemeinsamen Ter-minologie und definierten Maßnahmen wird hier eine industrieweite Grundlage geschaffen, auf der Hersteller und Zulie-ferer ihre Schnittstellen, geteilten Verant-wortlichkeiten und Prozesse aufbauen können. Die finale Fassung wird Ende 2020 erwartet.

Auswirkungen auf die AutomobilindustrieDie Automobilindustrie ist mit Vorgaben seitens des Gesetzgebers zwar in vielerlei Hinsicht durchaus vertraut, doch kennt sie spezifischen Regulierungen zur Informa-tions- oder Cybersicherheit bislang nur vereinzelt. So hat der Verband der Auto-mobilindustrie (VDA) etwa aufgrund des Wunschs der OEMs nach mehr Transpa-renz hinsichtlich des Informationssicher-heitsniveaus der Zulieferer einen Katalog für Information Security Assessments (ISA) entwickelt. Mit dem auf diesem Katalog basierende TISAX-Modell (Trus-ted Information Security Assessment Exchange) können OEMs dann den Umgang der Zulieferer mit sensiblen Daten, beispielsweise bei der Entwicklung von Prototypen, überprüfen. Neben die Aspekte der Informationssicherheit in

nach Produktionsstart und die kontinu-ierliche Risikobehandlung im Fahrzeug-betrieb. Prozessual organisiertes IT-Sicherheitsmanagement hält damit regu-latorisch Einzug in die Automobilindus-trie. Zwar kann auf Erfahrungen mit Infor-mationssicherheitsstandards wie der ISO 27000-Reihe zurückgegriffen werden, jedoch besteht die wesentliche Herausfor-derung bei der Ausgestaltung eines CSMS in der Berücksichtigung der Automobil-

Bild 2: Automotive Cybersecurity muss über den gesamten Fahrzeuglebenszyklus hinweg organisiert werden.

Bild 3: Zertifiziertes Cybersecurity-Managementsystem (CSMS) und Typgenehmigung gemäß dem Regulierungsentwurf der UNECE WP.29 TF-CS/OTA.

Bild:

Escry

pt

Bild:

Escry

pt

26_Escrypt (av).indd 28 10.03.2020 11:59:40




AutorDr. Moritz MinzlaffSenior Manager, Escrypt

Dr. Christopher KuschSecurity Consultant, Escrypt

Hans-Peter FischerPartner Cyber Security, KPMG


TISAX setzt die ISO/SAE 21434 nun Anforderungen an die Cybersicherheit der Produkte selbst.

Mit Bestandsaufnahmen zum VerbesserungsfahrplanDie Automobilindustrie hat seit dem Jeep-Hack 2015 den Schutz von Fahrzeugen zwar verstärkt, mit der UN-Regulierung und dem neuen ISO/SAE-Standard jedoch wird Cybersicherheit über den unverbind-lichen Status hinauswachsen und zur Vor-aussetzung für die Geschäfts- und Wett-bewerbsfähigkeit von Herstellern und Zulieferern.

Vor dem Hintergrund des digitalen Wandels gilt es, dabei nicht nur die regu-latorischen Vorgaben zu erfüllen, sondern gemäß der eigenen Unternehmensstrate-gie und Produkt-Roadmap den optimalen Security-Ansatz mit der höchsten Wirk-samkeit zu finden. Die Unternehmen müs-sen ganzheitlich organisatorische und technische Maßnahmen implementieren, die es ermöglichen, Cybersicherheit in der gesamten Wertschöpfungskette dauerhaft zu definieren, zu kontrollieren, zu steuern und zu verbessern. Folgerichtig wächst seit längerem der Bedarf an Bestandsaufnah-men oder „Gap-Analysen“, die den Stand der Umsetzung eines CSMS ermitteln.

Idealerweise ermittelt die Bestandsauf-nahme nicht nur etwaige Lücken, son-dern identifiziert zusätzlich auch vorhan-dene Stärken, beispielsweise aus einem Qualitätssicherungssystem oder Prozes-sen zur Erreichung funktionaler Sicher-heit. Nur wenn der Zustand relevanter Cybersicherheitsaspekte in der Organi-sation vollständig transparent ist, kann ein optimaler Fahrplan erstellt werden, der Maßnahmen priorisiert, die bereits vorhandenen Potenziale voll ausschöpft und weiterschreibt und so innerhalb der kurzen Zeitspanne bis zur Umsetzung der UN-Regulierung sicher zum Ziel führt.

Eine besondere Herausforderung stel-len darüber hinaus jeweils die techni-schen Implikationen der Regulierung auf Bestandarchitekturen dar. Komponenten und Systeme, die fertig entwickelt und eigentlich bereits in der Gewinnphase des Produktlebenszyklus sind, müssen nun einer Eignungsuntersuchung unter-zogen und gegebenenfalls mit neuen

Investitionen für Cybersicherheit nach-gerüstet werden. Eine technische Lücken-analyse der E/E-Architektur, ähnlich der Prozess-fokussierten Lückenanalyse für das CSMS, kann eine solide Entschei-

dungsbasis für die wirtschaftl ichen Abwägungen schaffen.

Doppelkompetenz nötig: Automotive + Cybersecurity Wie viele andere Branchen wird auch die Automobilindustrie auf einen Fachkräfte-mangel blicken: Experten, die sowohl Cybersicherheit als auch die speziellen Anforderungen der Automobilindustrie verstehen, sind rar. Gleichzeitig wachsen die Cyberrisiken aufgrund der Digitalisie-rung so rasant, dass das eigene Wissen der Unternehmen auf dem Gebiet der Cyber-sicherheit typischerweise nicht ausreicht, um alle Herausforderungen rechtzeitig allein zu bewältigen. Denn aufgrund der Typgenehmigungsrelevanz ist es dringend geboten, bereits im ersten Anlauf alle Anforderungen sicher und möglichst effi-zient umzusetzen.

Angesichts der komplexen Aufgaben-

stellung ist es durchaus ratsam, hierbei auf die Hilfestellung externer Cybersicher-heitsexperten zurückzugreifen. OEMs und Zulieferer benötigen Security-Partner, die einerseits spezielle Erfahrung darin haben, Cybersicherheit in der Automobilindustrie von der Konzeption bis hin zur Serienrei-fe zu führen und anschließend im Betrieb das gewünschte Sicherheitsniveau auf-recht zu erhalten, und andererseits große Fachkenntnis in Assessment und dem Ausrollen von Sicherheitsmanagement-systemen mitbringen.

Eine derartige Symbiose komplementä-rer Expertise ermöglicht es, die – im Sinne eines holistischen Ansatzes – notwendigen Änderungen auf der Organisations- und Prozessebene so zu gestalten, dass Aus-wirkungen auf die Entwicklung und den wirtschaftlichen und effektiven Betrieb der Sicherheitslösungen berücksichtigt und optimiert sind. (wi)� n

ISMS und CSMS

Information Security Managementsysteme (ISMS) gemäß der ISO/IEC 27000-Reihe sind in der Security-Branche längst als Standard etabliert. Sie beschreiben, wie Informationssicherheit im Unternehmen systematisch risikobasiert definiert, implementiert, analysiert und kontinuierlich verbessert wird.Mit den UNECE WP.29- und ISO/SAE 21434-Aktivitäten etabliert sich In der Automobilbranche dagegen der Begriff des Cybersecurity-Managementsystems (CSMS). Das CSMS definiert, wie für das Produkt und seinen Betrieb ein akzeptables Sicherheitsniveau erreicht, gewährt und kontinuierlich aufrechterhalten wird.Während ein ISMS den Schutz der Unternehmensinformationen und jeglicher Angriffe auf die-se einbezieht – also einen internen Fokus hat – hat ein CSMS einen externen Fokus speziell auf die Erkennung und Abwehr von Cyberangriffen auf das Produkt und sein Einsatzfeld. Insbeson-dere auch wegen der Implikation für funktionale Sicherheit und Diebstahlschutz verlangt dies nach geeignet angepassten Prozessen. Der Produkt-zentrische Ansatz bedeutet zudem einen Perspektivenwechsel: Im Gegensatz zum Kostenfaktor ISMS wird im Produktumfeld das CSMS zum Bestandteil der Unternehmensmission.

OEMs und Zulieferer

benötigen Security-Partner, die spezielle Erfahrung

mit Cybersicherheit und Automotive-Systemen

haben

26_Escrypt (av).indd 29 10.03.2020 11:59:43

30 AUTOMOBIL ELEKTRONIK 03 / 2020

ADAS + AD Positionierung


Wichtige Bausteine der neuen MobilitätHochpräzise Positionssysteme und dynamische 3D Karten

Die Digitalisierung aller Lebensbereiche schreitet rasanter voran denn je. Besonders zu spüren ist dies in den Bereichen Mobilität und soziale Infrastruktur. Bald sollen hochpräzise Positionssysteme eine sichere, komfor-table und automatisierte Mobilitätsgesellschaft ermöglichen. Umfangreiche digitalisierte Kopien sozialer Infra-struktur bedeuten auf ähnliche Weise einen Schlüssel zur digitalen Gesellschaft von morgen. Japan hat mit sei-ner „Society 5.0“ bereits eine Vision gemalt, innerhalb derer der Mensch im Mittelpunkt des digitalen Wandels steht. AUTOMOBIL-ELEKTRONIK stellt das System kurz vor. Autor: Kenji Nakakuki

Es ist besonders wichtig, die Wahrnehmung der Umgebung und Selbstpositionierung eines Fahrzeugs durch Infrastruktur zu gewährleis-

ten. Vor kurzem hat Japan den Service des von Mit-subishi Electric entwickelten Quasi-Zenith-Satelli-tensystems (QZSS) und des Centimeter Level Aug-mentation Service (CLAS) gestartet. Dieser spielt eine wesentliche Rolle bei der Korrektur von Positi-onsfehlern von Satellitendaten, beispielsweise her-vorgerufen durch den Einfluss von Ionosphäre und Troposphäre. Die hochpräzisen Daten werden dazu beitragen, den Weg für den automatisierten Betrieb einer Vielzahl von Fahrzeugen in Bereichen zu ebnen, die Straßen- und Nutzfahrzeuge, das Andocken von Schiffen, Drohnen sowie den Agrarsektor und mehr abdecken.

Um eine hochpräzise Positionierungsinfrastruktur auf der ganzen Welt zu verwirklichen, gründeten Bosch , Mitsubishi Electric , Geo++ und U-Blox im Jahr 2017 gemeinsam die Sapcorda Services GmbH, um ein weltweites hochpräzises Positionierungsnetzwerk auf Zentimeterniveau bereitzustellen, das dem japa-nischen CLAS ähnelt. Sapcorda startete seinen Dienst just offiziell am 31. Januar 2020. Neben derartiger Positionierungsinfrastruktur bedeuten umfangreiche digitalisierte Kopien sozialer Infrastruktur die zwei-te Stütze zukünftiger, automatisierter und sicherer Mobilität.

Mit einem sogenannten Mobile Mapping System (MMS) ermöglicht Mitsubishi Electric die Erstellung höchst präziser 3D-Karten und räumlicher Daten für die Überwachung und Verwaltung der Instandhaltung wichtiger Infrastruktur von der Straßen- bis zur Tun-nelinspektion in städtischen und abgelegenen Gebie-ten. Das MMS wurde zudem von dem japanischen Konsortium Dynamic Map Planning Co., Ltd. zur Kartierung aller 29.205 Kilometer von Japans Auto-bahnen mit einer Genauigkeit von 25 Zentimetern verwendet, um die wesentlichen hochpräzisen 3D-Karten für den automatisierten Fahrbetrieb zu erstellen. Federführend beteiligt an dem Konsortium sind ein staatlicher Innovationsfonds und Mitsubishi Electric, sowie alle großen japanischen OEMs der

Vor kurzem hat Japan den Service des von Mitsubishi Electric entwickelten

Quasi-Zenith-Satellitensystems (QZSS) und des Centimeter Level Augmentati-

on Service (CLAS) gestartet.

Äußerst genaue Positionssysteme und dynamische, dreidimensionale Karten sind mit die wichtigsten Bau-steine für eine sichere, komfortable und automatisierte Mobilitätsgesell-schaft. Mitsubishi Electric hat dafür den hochpräzisen Empfänger AQLOC entwickelt, der es ermöglicht, den neuen Positionsservice CLAS in Japan zu nutzen. Ein weiteres Produkt, das den SAPA-Dienst in Europa nutzt, soll demnächst folgen.

Eck-DATEN

30_Mitsubishi (wi).indd 30 10.03.2020 12:05:02


Automobilindustrie sowie heimische Vermes-sungs- und Kartierungsunternehmen.

Diese 3D-Karten werden zukünftig wieder-um in dynamische Karten integriert. Dynami-sche Karten sind ein zukunftsorientiertes Kon-zept für Straßenkarten der nächsten Generati-on. Dafür ist ein logischer Datensatz, der Sens-ordaten mit einer hochpräzisen 3D-Straßen-karte verknüpft, notwendig. Die Sensordaten werden in drei Kategorien eingeteilt, nämlich dynamische Daten, quasi-dynamische Daten und quasi-statische Daten. In Japan war die Erstellung der hochpräzisen 3D-Karten für Dynamic Map eine landesweite Kooperation, da Dynamic Map eines der wichtigen For-schungsgebiete des SIP-Adus-Projekts war (http://www.sip-adus.jp/). In Europa wurden Spezifikationen und Standardisierung von der NDS Association (https://www.nds-association.org/) und Ertico-ITS Europe (http://ertico.com/) erörtert.

So können Autos auch entfernte Bedingungen vorhersehen, die von Sensoren nicht erfasst werden können, und Fahrzeugmanöver in Situ-ationen unterstützen, in denen die Fahrspur nicht gesehen werden kann, zum Beispiel auf schneebedeckten Straßen. Dynamische Karten sind essenziell für zukünftig autonom oder semi-autonom fahrende Autos. Mit der Kom-bination aus hochpräziser Positionierung auf Zentimeter-Ebene und dynamischen Karten von gleicher Genauigkeit kann das Fahrzeug seine aktuelle Position und die Fahrspur auf Zentimeter-Ebene genau nachvollziehen.

Autor Kenji Nakakuki Division Manager, High Precision Positioning Systems, Mitsubishi Electric Europe


noffz.com

[email protected].: +49-2151-99878-0

RF & Wireless Test Plattform für ADAS Produkte:

eCall, NADs, TCUs, Connected Gateways,

Radar Systems, 5G Test

Radar Test System & 5G OTA Test

RF Testplatform Cellular, GNSS & WirelessGNSS & Wireless

Multi DUT RF Test

NEW UWTUniversal Wireless

Tester

12143 Anzeige Noffz productronic 60x303 AUSGABE_12.indd 1 07.08.19 13:42

2 Mitsubishi Electric bietet seit November 2019 einen hochpräzisen GNSS-Empfänger namens AQLOC Light an, der es Nutzern erlaubt den CLAS-Service in Japan zu emp-fangen.

3 Mit einem Mobile Mapping System ermöglicht Mitsubishi Electric die Erstellung höchst präziser 3D-Karten und räum-licher Daten für die Überwachung und Verwaltung der In-standhaltung wichtiger Infrastruktur.

4 Das MMS wurde zur Kartierung aller 29.205 Kilometer Japans Autobahnen mit einer Genauigkeit von 25 Zenti-metern verwendet.

Mitsubishi Electric bietet seit November 2019 einen hochpräzisen GNSS-Empfänger namens AQLOC Light an, der es Nutzern erlaubt den CLAS-Service in Japan zu empfangen. In Euro-pa und den USA wird Mitsubishi Electric in Kürze ein ähnliches Produkt auf den Markt bringen, das hochpräzise Positionierungsdiens-te wie den einzigartigen Premium-GNSS-Posi-tionierungsdienst SAPA (Safe And Precise Aug-mentation) von Sapcorda Services nutzen kann. Mit diesem Dienst und dem Empfänger können Benutzer eine sicherheitskritische Navigations-anwendung im globalen Maßstab realisieren, die die Schaffung einer Gesellschaft für hoch-präzises Positionieren einschließlich eines ech-ten autonomen Fahrens erleichtert.

Um seine Schlüsseltechnologien, das MMS und den hochpräzisen GNSS-Empfän-ger AQLOC, in Europa zu vermarkten, hat das Unternehmen 2019 eine Geschäftseinheit in seiner deutschen Niederlassung gegründet. Die lokale Einheit hat das Ziel, die Akzeptanz und Realisierung digitalisierter Kopien sozialer Inf-rastruktur und einer neuen hochpräzisen Mobi-lität mit voranzutreiben. (wi) ■

2 3

4

Bilde

r: Mits

ubish

i Elec

tric

30_Mitsubishi (wi).indd 31 10.03.2020 12:05:05


ADAS + AD Datenmanagement für ADAS

TByte an Daten pro Tag und Fahrzeug. Da die Hersteller Flotten von Testfahrzeugen mit weltweit bis zu 100 Fahrzeugen auf die Straße schicken, ist die Menge der anfallenden Testdaten schon heute enorm – Tendenz steigend! Aus diesen Daten leiten sich deshalb neue Anforderungen für das Datenmanagement ab, die insbesondere für autonome Fahrzeuge hoch sind. Im Zentrum stehen Deep-Learning-Algorithmen, die neuronale Netze nut-zen, um Muster in Daten zu erkennen und aus ihnen zu lernen. Neuronale Netze erfordern dabei große Data Lakes, in denen OEMs und Tier-One-Zulieferer die Daten abspeichern, um damit ihre Systeme zu trainieren. Angesichts der riesigen Datenflut ist es daher entscheidend, dass aus Testfahrten nur die Daten in die Cloud oder ins Rechenzentrum gelangen, die für den Entwick-lungsprozess relevant sind.

Besonders wichtig ist hierbei die Auswahl der richtigen Fahr-szenen und den korrelierenden Sensordaten. Für die Validierung eines Notbrems-Assistenten sind zum Beispiel nur die 15 Sekun-den vor und nach einem Bremseingriff von Bedeutung. Da in Fahrzeugen die Energieversorgung der limitierende Faktor ist, kommt es heute primär zu einer Speicherung der gigantischen Sensor-Datenströme. Im Fahrzeug selbst findet zurzeit wenig Vorverarbeitung statt, denn Rechenleistung benötigt Energie und Kühlung. Stattdessen erfolgt die Sichtung und Vorauswahl der Daten bei der Datenübergabe in die Werkstatt automatisch, um dann eine zielgerichtete Reduktion durchzuführen. In naher Zukunft sollte die Leistungsfähigkeit und Energieanforderung von Spezial-Prozessoren aber so weit fortgeschritten sein, dass die Datenverarbeitung und -analyse direkt im Fahrzeug stattfin-den kann (Edge Computing). Diese Verlagerung an den Rand des Netzwerks reduziert die Kosten für den Transport und die Speicherung der Daten im Rechenzentrum oder in der Cloud.

Von Unterhaltungsangeboten und Navigation über Fah-rerassistenz bis hin zur Unfallvermeidung unterschei-den sich die heutigen Autos erheblich von denen vor

einigen Jahren. Die große Chance, die Zukunft von vernetzten Autos mitzugestalten, insbesondere das autonome Fahren, zieht das Interesse von Technologie- und Automobilherstellern gleichermaßen an.

Die Entwicklung von intelligenten Fahrerassistenzsystemen (ADAS) ebnet dabei zunehmend den Weg zum autonomen Fahren. Diese unterstützen den Fahrer dabei, die Spur zu hal-ten, rückwärts einzuparken oder im Falle einer plötzlichen Notsituation automatisch zu bremsen. Möglich machen dies Sensoren, 360-Grad-Kameras und Lasersysteme, die enorme Datenmengen produzieren – und das Fahrzeug damit vom rei-nen Transportmittel zum Datenlieferanten verwandeln.

Zu den Datenquellen gehören unter anderem Sensordaten über den Zustand des Wagens, des näheren Umfelds, Wetter-daten, Satellitendaten, Verhaltens- und andere persönliche Daten über den Fahrer sowie Diagnosedaten. Die Zunahme der zu verarbeitenden Sensordaten sowie die Komplexität der Ver-arbeitungsalgorithmen erfordern leistungsfähigere Verarbei-tungsplattformen, auf denen sich die Datenmengen zusam-mentragen und auswerten lassen. Darüber hinaus gilt es, Aspek-te wie funktionale Sicherheit und Plattformsicherheit zu berück-sichtigen.

Nur ausgewählte Daten transportieren und speichernNeben den Vorteilen eines vernetzten Autos stellt die steigende Masse an erhobenen Daten OEMs und Tier-One-Zulieferer vor große Herausforderungen. Das Volumen ist schwindelerregend: Aktuelle Test- und Entwicklungsfahrzeuge produzieren rund 80

Melexis, a global leader in automotive ambient lighting solutions, extends its successful IC family with a new generation of its LIN RGB(W) LED controller. The new member – the MLX81113 – will support the further growth of RGB LED-based automotive ambient lighting, also known as LIN RGB, which is already well established within nearly every OEM worldwide. The MLX81113 features more on-chip memory, higher output current and increased EMC robustness compared to the popular MLX81108. It also offers ISO 26262 functional-safety compliance to support its use in ASIL-A classified systems.

LED-based automotive ambient lighting, also known as LIN RGB, which is already well established within nearly every OEM worldwide. The MLX81113 features more on-chip memory, higher output current and increased EMC robustness compared to the popular MLX81108. It also offers ISO 26262 functional-safety compliance to support its use in ASIL-A classified systems.

LIN RGB LED DRIVERFOR AUTOMOTIVE AMBIENT LIGHTING

functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.


Light guide

Module

LED

PCB

MLX81108/10/13

www.melexis.com

More info:

Datengiganten auf vier RädernADAS brauchen ein intelligentes Datenmanagement

Das Automobil entwickelt sich rasant von einer isolierten, weitgehend mechanischen Maschine zu einer der technisch anspruchsvollsten und vernetzten Plattformen der Welt. Zur Realisierung immer komplexerer Fah-rerassistenzsysteme und um Fortschritte beim autonomen Fahren zu erlangen, spielt das intelligente Daten-management eine zunehmend wichtigere Rolle. Autor: Christian Muszynski

Bild:

Getty

Imag

es N

r.692

8194

26

32_IBM (aok).indd 32 10.03.2020 12:06:20

ADAS + AD Datenmanagement für ADAS

Hohe Parallelität und großer DatendurchsatzDie Auswertung riesiger Mengen an Sensor- und Videodaten stellt eine weitere Herausforderung für OEMs und Zulieferern dar. Sol-che Big-Data-Analysen unterstützen aktuelle Verarbeitungs-Tools wie IBM Data Science Experience oder Hadoop. Sie sind dank Parallelisierung leistungsstark und verfügen über umfangreiche Bibliotheken und Schnittstellen. Ihre Spezialität: das gleichzeitige Ausführen von schnellen Datenabfragen (Queries) auf große Datenmengen im TByte-Bereich. Die Basis hierfür ist das aus dem Supercomputing-Umfeld kommende, parallele Filesystem IBM

Spectrum Scale, das linear skaliert und somit hohe Datenzugriffs-raten erzielt. Zum Trainieren von selbstlernenden KI-Algorithmen haben sich mittlerweile Graphics Processing Units (GPU) durch-gesetzt. Ursprünglich für 3D-Berechnungen von geometrischen Berechnungen, Texture Mapping oder Shading konzipiert, macht die Kombination aus Parallelisierung und Matrix-Rechnung GPUs so effektiv für heutige KI-Methoden wie neuronale Netze.

Interdisziplinäre ZusammenarbeitDer steigende Bedarf an leistungsfähiger und Hard- und Soft-ware für KI-Anwendungen ist auch der Grund, warum Auto-hersteller, Zulieferer und IT-Unternehmen zunehmend mitein-ander kooperieren. Die Autohersteller haben erkannt, dass sie mit dem eigenen Know-how die Herausforderungen einer KI-Entwicklung für das automatisierte Fahren nicht erfolgreich bewältigen können. Insbesondere beim Datenmanagement kön-nen Ansätze aus den Bereichen des Supercomputings und der Medienbranche zu deutlichen Verbesserungen führen. (aok) ■

Autor Christian Muszynski CTO EBU Industrial bei IBM



LED-based automotive ambient lighting, also known as LIN RGB, which is already well established within nearly every OEM worldwide. The MLX81113 features more on-chip memory, higher output current and increased EMC robustness compared to the popular MLX81108. It also offers ISO 26262 functional-safety compliance to support its use in ASIL-A classified systems.

LIN RGB LED DRIVERFOR AUTOMOTIVE AMBIENT LIGHTING

functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.functional-safety compliance to support its use in ASIL-A classified systems.


Light guide

Module

LED

PCB

MLX81108/10/13

www.melexis.com

More info:

Aus Testfahrten sollen nur die Daten in die Cloud oder ins Rechenzentrum gelangen, die für den Entwicklungsprozess relevant sind.

Bild:

Getty

Imag

es N

r.102

3344

400

32_IBM (aok).indd 33 10.03.2020 12:06:24


ADAS + AD Datenfusion für AD


Vorteile einer standardisierten Software-BibliothekKosteneinsparpotenziale bei Entwicklung eingebetteter Datenfusionssysteme

Die Datenfusion ist eine der Schlüsselkomponenten für das automatisierte Fahren. Mit einer standar-disierten Software-Bibliothek für die Entwicklung eingebetteter Datenfusionssysteme lassen sich bei der Softwareentwicklung Kosten und Zeit sparen. Autoren: Holger Löbel und Maren Siegert

vorteile können Automobilunternehmen deutlich fle-xibler auf Markt- und Kundenanforderungen reagie-ren, die eigenen Innovationen für die Serienentwick-lung mit geringerem Risiko vorantreiben und deutlich schneller auf den Markt bringen.

Datenfusion als SchlüsselkomponenteDatenfusionssysteme werden für spezifische Anwen-dungsfälle entwickelt: für ein bestimmtes Fahreras-sistenzsystem, ein bestimmtes automatisiertes Fahr-zeug oder eine spezifische Sensorkonfiguration. Ein einfaches Beispiel ist ein Notbremsassistent (Auto-nomous Emergency Braking, AEB). Wesentliche Bau-

Die Leistungsfähigkeit, Zuverlässigkeit und Flexibilität der Datenfusionssysteme können den Erfolg der Fahrzeugkommunikation ent-

scheidend beeinflussen. Für die Entwicklung von ein-gebetteten Datenfusionssystemen ist eine standardi-sierte Software-Bibliothek verfügbar, die laut einer Referenzrechnung von Baselabs Einsparpotenziale bei der Softwareentwicklung von 50 Prozent ermög-licht und dabei die Entwicklungszeit für die Datenfu-sion deutlich reduziert. Bereits bei relativ einfachen Zwei-Sensor-Systemen aus zum Beispiel Radar und Kamera betragen die Einsparungen gemäß Referenz-rechnung 600.000 Euro. Durch die Zeit- und Kosten-

Bilde

r: Bas

elabs

34_Baselabs (na).indd 34 10.03.2020 12:07:33




steine dafür sind die Sensoren, die Datenfusion und die eigentliche Fahrfunktion, bestehend aus einer Manöverplanung und der Ansteuerung der Aktuato-ren im Fahrzeug.

Aufgabe der Datenfusion ist es, die Daten von allen verfügbaren Sensoren zu kombinieren, um so ein möglichst vollständiges und zuverlässiges Abbild der Fahrzeugumgebung – das Umfeld-Modell – zu berechnen. Je nach Komplexität des Gesamtsystems muss die Datenfusionssoftware unterschiedliche Daten verschiedener Sensor-Hersteller und Sensor-Typen verarbeiten. Für die Datenfusion sind zuver-lässige und leistungsstarke Datenfusionsalgorithmen und -funktionen für die Sensordatenverarbeitung in Form von Software-Code notwendig (Bild 1).

Für den Einsatz in Serienfahrzeugen muss die Soft-ware als C-Quellcode vorliegen und zusätzlich den Anforderungen an sicherheitskritische Anwendungen entsprechen. Notwendige Arbeiten umfassen dabei das Aspice-prozesskonforme Testen (zum Beispiel Software Qualification Tests), die Umsetzungen von Anforderungen aus der funktionalen Sicherheit, sowie die entsprechende Dokumentation. Die Aufwendun-gen dafür können die eigentliche Entwicklung der Basisfunktionalität der Datenfusion um den Faktor 10 übersteigen. Mit steigender Komplexität des Gesamtsystems, Anzahl der Sensoren im Zielfahrzeug und notwendigen Iterationen für die Fehlerbehebung und Verbesserung des Systems, zum Beispiel den Austausch eines Sensortyps oder eines anderen Her-stellers, steigen die Gesamtkosten erneut um ein Viel-faches und die Gesamtdauer der Entwicklung erhöht sich ebenfalls entsprechend.

Projektbasierte SoftwareentwicklungFür die Datenfusionsentwicklung gibt es vereinfa-chend zwei grundsätzliche Möglichkeiten: Zum einen die projektbasierte Entwicklung, zum anderen besteht die Möglichkeit, standardisierte Softwarebibliotheken einzusetzen.

Für die Entwicklung von eingebetteten Datenfusionssystemen stehen standardi-sierte Software-Bibliotheken zur Verfügung. Nutzer von am Markt verfügbaren Standard-Bibliotheken profitieren von einem erheblich geringeren Implementie-rungsaufwand, da funktionale und formale Anforderungen bereits in der Bibliothek berücksichtigt und ohne Zusatzaufwand für die Entwicklung verfügbar sind. Wei-terhin ermöglichen die deutlich verkürzten Entwicklungszeiten für den Software-Code eine kürzere Time-to-Market und sichern dadurch Wettbewerbsvorteile für das Automobilunternehmen.

Eck-DATEN

Projektbasierte Entwicklung: Diese Unternehmen entwickeln die Software individuell pro Projekt. Ein solches Projekt ist zum Beispiel ein Notbremsassistent für einen Mittelklasse-PKW eines bestimmten OEM. Der Code entsteht häufig in einer hardwarenahen Programmiersprache, um den Code direkt auf einem Steuergerät testen und später für die Serie implemen-tieren zu können. Bei der Entwicklung wird nach Möglichkeit auf bestehende Source-Code-Blöcke aus vorigen Projekten zurückgegriffen, die Wiederver-wendbarkeit hat aber nicht die höchste Priorität.

Bibliotheksbasierte SoftwareentwicklungNeben der Entwicklung von eigenen Tools besteht die Möglichkeit, etablierte Werkzeuge für die Ent-wicklung von Datenfusionssoftware zu nutzen. Bei diesem Modell liegt der Entwicklungs- und Pfle-geaufwand für die Bibliothek und komplementäre Tools beim Anbieter der Software und nur ein Anteil davon ist vom jeweiligen Nutzer über eine Lizenz-gebühr zu tragen. Die Nutzer können sich auf die Entwicklung und Optimierung des Gesamtsystems und der eigentlichen Fahrfunktionen konzentrieren und differenzieren sich darüber gegenüber ihren Wettbewerbern. Die Standard-Bibliothek liefert die zugrundeliegende Basisfunktionalität in Form des Datenfusionscodes. Durch die entstehenden Zeit- und Kostenvorteile kann das Automobil-Unterneh-men deutlich flexibler auf Markt- und Kundenan-forderungen reagieren, die eigenen Innovationen für

Bild 1: Datenfusions-schicht im Gesamtsys-tem: Die Entwicklung der Datenfusionssoft-ware kann unabhän-gig von den anderen Systembestandteilen erfolgen. Dabei kom-men unter anderem die Technologien Ob-jektfusion und Grid-Fusion zum Einsatz, je nachdem, welche Sensordaten verar-beitet und welche Ausgangsgrößen für die Fahrfunktionen benötigt werden.

34_Baselabs (na).indd 35 10.03.2020 12:07:37




jekt hat das Unternehmen für einen OEM die Umfel-derkennung für ein Notbremsassistenzsystem imple-mentiert. Der Datenfusionscode ist nach Qualitätspro-zessen (Aspice) und Sicherheitsanforderungen (ISO 26262) entwickelt. Für die bibliotheks-basierte Ent-wicklung kommt im Beispiel Software Baselabs Crea-te Embedded zum Einsatz.

Dabei wird gezeigt, dass bereits solche einfachen Systeme Entwicklungskosten von mindestens 1,2 Mil-lionen Euro verursachen. Die Implementierungszeiten für derartige Systeme können dabei schnell deutlich mehr als elf Monate erreichen. Beim Einsatz von stan-dardisierten Softwarebibliotheken mit unterstützen-dem Tooling lassen sich diese Aufwände deutlich reduzieren. Baselabs ermittelte in der Referenzrech-nung mögliche Einsparpotenziale in Höhe von 600.000 Euro, also 50 Prozent der Entwicklungskos-ten. Die Entwicklungszeit für die Datenfusion wird ebenfalls deutlich reduziert. Die Gesamtkosten und Entwicklungszeiten zeigt Tabelle 1.

Die Grundlage der Berechnung ist das Construc-tive Cost Model (Cocomo), ein etablierter Ansatz aus der Software-Entwicklung, um die Kosten- und den Aufwand zu schätzen. Auf der Basis von Einschät-zungen der Projekt-Komplexitätsklassen und der Anzahl der Code-Zeilen des Projektes wird mit empi-risch abgeleiteten Funktionen der zeitliche Aufwand in Personenmonaten sowie die Gesamtdauer für die Realisierung eines Softwareprojekts bestimmt. Bei der Projektentwicklung entsteht der gesamte benö-tigte Code inklusive aller Iterationen für die Fehler-behebung und Verbesserung im Projekt. Diese impli-zieren einen hohen Arbeitsaufwand und eine lange Umsetzungszeit.

In der bibliotheksbasierten Entwicklung konzent-riert sich der Entwickler auf die Konfiguration der Datenfusion und die Verbesserung der Performance, beispielsweise durch die Verbesserung der Sensor-modelle. Dadurch ist die absolute Arbeitszeit an der eigentlichen Datenfusion relativ gering. Bei Durch-führung am Stück ist auf Basis von Projekterfahrung

die Serienentwicklung mit geringerem Risiko vor-antreiben und deutlich schneller auf den Markt brin-gen (Bilder 2 und 3).

Kostenrechnung für ein Referenz-Projekt Baselabs hat anhand eines realen Referenzprojekts am Beispiel eines einfachen Zwei-Sensor-Systems die pro-jektbasierten und bibliotheksbasierten Entwicklungs-ansätze gegenübergestellt. Im zugrundeliegenden Pro-

Bild 2: Nutzung der standardisierten Da-tenfusionsbibliothek Baselabs Create Em-bedded für die Ent-wicklung von Daten-fusionssystemen für automatisierte Fahr-funktionen. Der resul-tierende C-Quellcode kann entlang der ge-samten Entwick-lungskette genutzt werden.

Bild 3: Typisches Da-tenfusionsergebnis der Standard-Bibliothek Baselabs Create Em-bedded. Die Datenfusi-on kombiniert Detekti-onen und Objekte der konfigurierten Senso-ren zu einer einheitli-chen Objektliste der Fahrzeugumgebung. Für jedes Objekt wer-den Größen wie Positi-on, Geschwindigkeit und Klassifizierung er-mittelt.

34_Baselabs (na).indd 36 10.03.2020 12:07:40

AUTOMOBIL ELEKTRONIK 03 / 2020 37



Maren Siegert Head of Marketing bei Baselabs

AutorHolger Löbel Director / Co-Founder von Baselabs


die Arbeitszeit für das Referenzsystem auf maximal drei Monate zu schätzen, wenn ein erfahrener Ent-wickler die Implementierung vornimmt. Die eigent-lichen Kosten für die Entwicklung der Bibliothek, welche die kurze Entwicklungszeit ermöglicht, wird auf zahlreiche Anwender in der Industrie umgelegt, so dass der Nutzer nur einen Teil dieser Kosten in Form von Lizenzgebühren tragen muss.

Neben dem aus der Bibliothek generierten Code für das Zielsystem fallen begleitende Arbeiten für das konkrete Datenfusionssystem an, welche etwa ein halbes Mannjahr Aufwand bedeuten. Diese Arbeiten umfassen das Aspice-prozesskonforme Testen (zum Beispiel Software Qualification Tests), die Umsetzun-gen von Anforderungen aus der funktionalen Sicher-heit, sowie entsprechender Dokumentation. Dieser Aufwand fällt teilweile parallel zur Code-Entwicklung an, so dass die Entwicklungsdauer bei rund acht Monaten insgesamt liegt. Für die Datenfusionsent-wickler und -designer, die Create Embedded als eine Softwarebibliothek einsetzen, entfällt neben der Quellcode-Implementierung auch die Notwendigkeit, entsprechend detaillierte Design-Dokumente sowie die korrespondierenden Tests zu erstellen und durch-zuführen. In den Design-Dokumenten sind nur die entsprechenden Schnittstellen zu referenzieren bezie-hungsweise zu beschreiben.

Mithilfe einer Personalkostenschätzung lässt sich in der Folge der finanzielle Aufwand berechnen. In der Vergleichsrechnung werden gesamte Arbeitskos-ten für ein Mann-Jahr in Höhe von 156.000 Euro ange-nommen. Darin sind durchschnittliche Personal- und Overheadkosten berücksichtigt.

Die Anzahl der Code-Zeilen im Referenzprojekt ist mit 15.000 Zeilen relativ klein. Davon sind etwa 1000 Zeilen individueller Code, zum Beispiel kundenspe-zifische Sensormodelle. Die verbleibenden Zeilen stellen überwiegend die erforderlichen mathemati-schen Implementierungen der Algorithmen dar. Die-ser Code ist also kompakt, jedoch inhaltlich heraus-fordernd. Grundlage für die Berechnung ist aus-schließlich der Code für die Datenfusion, das heißt die Aufwände für die Funktionsentwicklung, Integ-ration und Validierung sind nicht erfasst. Cocomo berücksichtigt nur den „delivered code“, also der anfallende Test-Code, der weitere circa 45.000 Zeilen umfasst, ist nicht in der Vergleichsrechnung enthalten.

FazitStark vereinfachende Rechenmodelle wie Cocomo können nur bedingt die Realität komplexer Software-Entwicklungsprojekte und firmenindividuelle Fakto-ren abbilden. Jedoch geben die vorgestellten Ergeb-nisse interessante Anhaltspunkte, um Make-or-Buy-Entscheidungen für die Datenfusionsentwicklung zu diskutieren. Nutzer von am Markt verfügbaren Stan-

dard-Bibliotheken profitieren von einem erheblich geringeren Implementierungsaufwand, da funktio-nale und formale Anforderungen bereits in der Bib-liothek berücksichtigt und ohne Zusatzaufwand für die Entwicklung verfügbar sind. Weiterhin ermögli-chen die deutlich verkürzten Entwicklungszeiten für den Software-Code eine kürzere Time-to-Market und sichern dadurch Wettbewerbsvorteile für das Auto-mobilunternehmen.

Andererseits verbleibt mehr Zeit, um die implemen-tierten Algorithmen zu optimieren, zum Beispiel indem mehr unterschiedliche Parameter-Sätze testbar sind. Außerdem erleichtert das Tool, mit geänderten Systemkonfigurationen und häufigen Change Requests in der Design-Phase umzugehen und wird dadurch den Anforderungen bei der Entwicklung komplexer Software gerecht. Bei der Bewertung der Ergebnisse ist zu beachten, dass das zugrundeliegen-de Referenzsystem ein vergleichsweise einfaches Zwei-Sensor-System ist. Diese Kostenschätzung ist also als eine untere Grenze für die Entwicklung von Datenfusionssystemen zu verstehen, steigende Sys-temkomplexität wird die Kosten deutlich darüber hinaussteigen lassen. Der bibliotheksbasierte Ansatz ist bei steigender Komplexität des Systems umso mehr zu bevorzugen. (na) ■

Tabelle 1: Gesamtkos-ten und Entwick-lungszeiten projekt-basierte und biblio-theksbasierte Ent-wicklung im Vergleich am Beispiel eines ein-fachen Zwei-Sensor-Systems für ein Not-bremsassistent und bei einmaliger Lizen-sierung.

34_Baselabs (na).indd 37 10.03.2020 12:07:43


ADAS + AD AD-Absicherung


Absicherung autonomer Fahrfunktionen im ParkhausEin Entwicklungsprojekt auf Basis von KI und Virtual Reality

Wie wäre es, wenn wir uns die lästige Parkplatzsuche künftig sparen könnten? Stattdessen stellen wir das Auto vor dem Parkhaus ab – und ganz ohne unser Zutun sucht es seinen Weg und parkt auf einem freien Platz. In einem internen Entwicklungsprojekt arbeitet die ASAP Gruppe an einer Lösung zur Absi-cherung der für das Parkhaus der Zukunft benötigten Fahrerassistenzsysteme. Neu daran: das Unterneh-men setzt dabei auf Methoden Künstlicher Intelligenz sowie Virtual Reality. Autoren: Jan Hamann, Timo Nels

Kombination mit diversen Sensoren genutzt. Dafür ist es not-wendig spezielle Innovationsfahrzeuge aufzubauen, die sich in realen Parkhäusern anhand groß angebrachter QR-Codes ori-entieren. Unter Verwendung einer solchen restriktiven Simula-tionsumgebung kann die eingesetzte Fahrzeugumfeldsensorik dabei in begrenzter Weise konfiguriert werden. Weshalb besteht also die Notwendigkeit für ein Entwicklungsprojekt zu einem neuen Ansatz, bei dem die Absicherung in ein virtuelles Parkhaus verlagert wird? Grund hierfür ist zum einen, dass die Absicherung mit echten Prototypen nicht nur zeitintensiv, sondern auch kost-spielig und vergleichsweise unflexibel ist: im realen Versuch muss das Fahrzeug nach jedem Testlauf im Parkhaus wieder an die Ausgangsposition gefahren werden – eine ständige Betreuung ist notwendig.

Zudem können die Sensorik oder die Verarbeitung ihrer Daten durch die Fahrfunktionen beim Test versagen, was in kostspie-ligen Schäden am Fahrzeug oder der Testumgebung resultieren würde. Hier setzt das ASAP-Entwicklungsprojekt an: mit der neuen Methode lassen sich die aufgeführten Nachteile der Absi-

Im Parkhaus der Zukunft werden Fahrzeuge durch eine Kom-munikation mit der Infrastruktur selbst Teil des Parkhauses. Für das autonome Parken im Parkhaus der Zukunft bedarf

es jedoch neben einer Vielzahl an Fahrzeugumfeldsensorik einer umfänglichen Absicherung autonomer Fahrfunktionen, darun-ter Notbremssystem, Objekt- sowie Personenerkennung und Parkassistenzsystem. Für diese Absicherung arbeitet ASAP in einem internen Entwicklungsprojekt an einer neuen Lösung, die Testautomatisierung und virtuelle Absicherung miteinander ver-knüpft, und auf diese Weise eine realitätsnahe Durchführung in VR ermöglicht: im virtuellen Parkhaus sollen virtuell aufgebau-te Fahrzeuge durch den Einsatz von Machine Learning selbstän-dig das Navigieren und Parken sowie den dafür benötigten Umgang mit der nachgebildeten Sensorik erlernen. Das Ziel: nach erfolgreicher Validierung werden die gewonnenen Daten aus der Simulationsebene auf echte Hardware übertragen – und stehen damit auch in der Realität zur Verfügung.

In aktuellen Forschungsprojekten werden zur Entwicklung des autonomen Parkvorgangs bereits hochkomplexe Algorithmen in

Im Parkhaus der Zukunft navigiert das Fahrzeug selbständig zu einem freien Platz und parkt ein.

Bild:

ASAP

/Shu

tterst

ock

38_ASAP (wi).indd 38 10.03.2020 12:28:48




cherung in realer Testumgebung künftig umgehen und gleich-zeitig KI-Methoden wie Machine Learning gewinnbringend ein-setzen. Für die Entwicklung und Absicherung autonomer Fahr-funktionen und zur Realisierung des Parkhauses der Zukunft bedeutet dies einen deutlichen Gewinn an Schnelligkeit, Flexibi-lität sowie Kosteneffizienz. Gleichzeitig ermöglicht der Einsatz der VR-Technologie in der Absicherung die Immersion, selbst in der VR-Szene anwesend zu sein. Die Entwickler können die Test-fahrten demnach virtuell erleben und die gesamte VR-Szene beliebig oft aus allen Blickwinkeln betrachten, um sie schließlich bewerten zu können.

Konditioniert auf EinparkenFür die Entwicklung und Absicherung autonomer Fahrfunktio-nen im virtuellen Raum werden zunächst das Innovationsfahr-zeug, das Parkhaus sowie darin eingesetzte Objekte und auch Personen virtuell nachgebildet. Zur virtuellen Darstellung großer und komplexer Datenmengen mit hoher Performance wird rea-le Hardware in VR im Verhältnis 1:1 nachgebildet und reale Soft-ware mittels einer Schnittstelle mit der VR-Szene verbunden. Bei der Erstellung des virtuellen Fahrzeugs können CAD-Daten realer Fahrzeuge genutzt werden, während für das virtuelle Park-haus entweder ein 3D-Scan eines realen Parkhauses oder ein fiktives Parkhaus erstellt wird. Beim Aufbau des virtuellen Inno-vationsfahrzeugs besonders wichtig: die eingesetzte Fahrzeu-gumfeldsensorik – Kameras, Radar- und Lidarsysteme, Weit-sichtradar und Ultraschalltechnik. Die richtige Konfiguration der Fahrzeugumfeldsensorik, insbesondere Ausrichtung und Anzahl, sowie ihre zuverlässige Funktionalität stellen Grundvorausset-zungen für automatisierte Fahrfunktionen dar – denn auf Basis

Für die Entwicklung und Absicherung autonomer Fahrfunktionen in einem Parkhaus sind riesige Datenmengen von der Fahrzeugumfeld-sensorik notwendig. Wie erhält man diese? Nun, man kann sogenann-te Innovationsfahrzeuge aufbauen und in einem echten Parkhaus fah-ren lassen, aber dass ist teuer und zeitaufwändig. Die Firma ASAP setzt deshalb in einem Entwicklungsprojekt auf Virtual Reality und Künstli-che Intelligenz. Damit lassen sich die notwendigen Daten nicht nur schneller gewinnen, sondern auch flexibel auf unterschiedliche Sen-sorsysteme reagieren.

Eck-DATEN

der über die Sensorik aufgenommenen Informationen berechnen die Steuergeräte im autonomen Fahrzeug beispielsweise, ob Per-sonen oder Objekte in Sicht sind, also der Einparkvorgang durch-geführt werden kann.

Beim Aufbau des virtuellen Fahrzeugs kommt zusätzlich Künst-liche Intelligenz, genauer Machine Learning, zum Einsatz: auf diese Weise wird es dazu befähigt, den richtigen Umgang mit den Eingangsdaten der Sensorik selbst zu erlernen und mit ihrer Hilfe fehlerfrei ein- sowie auszuparken. Durch den Einsatz von Machine Learning sucht sich das System selbständig den besten Algorithmus zur Nutzung der eingehenden Sensorik-Daten zum autonomen Fahren und Parken. Das Machine Learning konditi-oniert den Algorithmus auf die bestmögliche Nutzung der Ein-gangsdaten, indem es immer dann eine Belohnung erteilt, wenn das Navigieren durch sowie das Einparken im virtuellen Parkhaus fehlerfrei erfolgen.

Da die Entwickler die während des autonomen Parkvorgangs zu belohnenden Punkte frei festlegen können, lassen sich zudem weitere Parameter belohnen und entsprechend anlernen. So lässt sich der Algorithmus auch dahingehend optimieren, dass der autonome Parkvorgang nicht nur fehlerfrei, sondern auch mög-lichst schnell abgeschlossen wird. Zum Anlernen und Optimie-ren der Algorithmen sind idealerweise tausende Testfahrten und die damit verbundene Aufnahme und Auswertung von Sensor-daten notwendig. Mithilfe der Absicherung in VR lässt sich die-ser Prozess künftig erheblich beschleunigen.

Virtuelles Lernen – Reales AnwendenFür die Durchführung der Testläufe im virtuellen Parkhaus legt der Entwickler schließlich lediglich eine beliebige Anzahl ver-schiedener Sensorkonfigurationen für das virtuelle Fahrzeug fest. Ohne weiteres Zutun des Entwicklers erfolgt dann der Vali-dierungsprozess im virtuellen Parkhaus: die Eingangsdaten der jeweiligen Fahrzeugumfeldsensorik-Konfiguration werden zur Navigation zu einem freien Parkplatz und dort zum Einparken sowie zum anschließenden Ausparken und der Navigation zum Ausgang genutzt. Durch die Anwendung von Machine Learning ist der Algorithmus in der Lage, aus Fehlern – etwa einer Kolli-sion mit einem Objekt in der Testumgebung – zu lernen und diese bei darauffolgenden Testläufen gezielt zu vermeiden. Nach Durchlauf aller Testläufe können die Entwickler dann anhand

Über das Smartphone lässt sich im Parkhaus der Zukunft etwa der Befehl zum Einparken geben.

Mit der VR-Brille lassen sich beispielsweise die Abstrahlwinkel der Sensorik anzeigen .

Bild:

ASAP

/Shu

tterst

ock

Bild:

ASAP

/Shu

tterst

ock

38_ASAP (wi).indd 39 10.03.2020 12:28:52




AutorenJan HamannProjektleiter Elektronik- und Softwareentwicklung bei ASAP

Timo NelsLeiter Elektronikentwicklung | Bedien- und Anzeige-systeme bei ASAP


der aufgezeichneten Testergebnisse auswerten, ob die vorge-schlagenen Sensor-Konfigurationen zum Erfolg geführt haben beziehungsweise können entsprechende Änderungen an ihnen vornehmen. Der Algorithmus, der auf diese Weise in sicherer, da virtueller, Welt angelernt wurde, kann schließlich auf echte Hard-ware übertragen werden und so auch in der Realität Anwendung finden.

Durch die Verlagerung der Absicherung in ein virtuelles Park-haus haben die Entwickler während der Testläufe zudem die Möglichkeit zum Echtzeiteingriff: über eine VR-Brille und am Körper angebrachte Sensoren können sie sich selbst als Avatare im Parkhaus sehen. Dabei sind sie in der Lage, ihre Bewegungen aus der realen in die virtuelle Welt zu transferieren – die Bewe-gungsübertragung findet im Verhältnis 1:1 statt. Auf diese Wei-se können sie in Echtzeit beispielsweise die Sensordaten des virtuellen Fahrzeugs als Passant beeinflussen – und das Fahrzeug so auf seine Reaktion, also etwa die Funktionstüchtigkeit der Personenerkennung, testen. Die Entwickler haben damit die Möglichkeit, in die virtuelle Umgebung einzutauchen und unter Zuhilfenahme diverser virtueller Tools neue Fahrfunktionen aus erster Hand abzusichern. Die Freiheiten der virtuellen Testum-gebung bedeuten dabei auch, dass Sensor-Konfigurationen nicht nur ohne großen Aufwand getestet werden können und jederzeit frei modifizierbar sind – auch noch nicht existierende Sensoren lassen sich so virtuell erdenken und umsetzen sowie schließlich auf Basis der Testergebnisse real nachbilden.

Sichtbar machen, was sonst verborgen istNeben der Möglichkeit des Echtzeiteingriffs sowie den Freihei-ten, die eine virtuelle Testumgebung der Entwicklung bietet, weist der neue Ansatz weitere Vorteile für die Entwicklung und Absicherung hochautomatisierter Fahrfunktionen auf: zum einen lassen sich künftig Bauteil-Bibliotheken für virtuelle Sensoren aufbauen. Ziel hiervon ist es, wie bei einem Baukasten-System

in der Produktion, wiederkehrende Elemente jederzeit bei Bedarf abrufen zu können. Dadurch ist es möglich, bei der Erstellung der Sensorkonfigurationen häufig benötigte Elemente innerhalb weniger Minuten virtuell einzusetzen und direkt hinsichtlich ihrer Auslegung zu prüfen. Indem wiederkehrende Komponen-ten nicht bei Bedarf stets neu virtuell konstruiert werden müssen, lässt sich die Entwicklung weiter beschleunigen.

Ein weiterer Vorteil ist, dass sich die Entwickler mit der VR-Brille – anders als in der Realität – die Abstrahlwinkel der Sen-sorik anzeigen lassen können. Dadurch wird sichtbar, wie viel ihrer Umgebung die aktuell getestete Sensorik-Konfiguration erfassen kann und dementsprechend auch, ob beispielsweise die Platzierung der Sensorik im virtuellen Fahrzeug angepasst wer-den muss. Denn für stets freie Sicht aller Sensoren und die damit verbundene Verlässlichkeit der Fahrfunktionen, müssen sich die Abstrahlwinkel überschneiden, sodass 100 Prozent des Fahrzeu-gumfelds jederzeit eindeutig erkannt werden.

Zusätzlich zu der Anzeige dieser in der Realität nicht sichtba-ren Details, sind alle Parameter im virtuellen Parkhaus jederzeit anpassbar – die Änderung von Form und Farbe anderer Fahr-zeuge und Schilder, die Platzierung von Hindernissen oder das Kreieren spezieller Situationen mit Passanten sind problemlos möglich. Dadurch lassen sich die Funktionen weitaus tiefer und umfassender absichern, als es unter realen Umständen und inner-halb eines annehmbaren Kosten- und Zeitrahmens möglich wäre. In Summe bedeuten all diese Faktoren, dass sich die Absicherung der Fahrfunktionen mit dem neuen Ansatz des virtuellen Park-hauses schneller, kostengünstiger und auch flexibler umsetzen lassen.

Möglichkeiten: unbegrenzt Für die zuverlässige Absicherung autonomer Fahrfunktionen, für die eine schier unendliche Anzahl an Parametern und Kom-binationen selbiger validiert werden müssen, bedeutet das vir-tuelle Parkhaus einen enormen Vorsprung in der Entwicklung. Die einzige Grenze für die Entwicklung und Absicherung in VR besteht letztendlich in der Vorstellungskraft und Kreativität des Entwicklerteams – denn im virtuellen Parkhaus lässt sich jede nur erdenkbare Kombination an Parametern flexibel realisieren. Das bedeutet auch, dass im virtuellen Parkhaus viele weitere Zukunftsszenarien getestet werden können, solange sie nur erdacht werden. (wi)� n

Notbremsassistent / Fußgängererkennung / Kollisionsvermeidungssystem

Abstandsregel- tempomat

Einparkassistent

Kollisionswarnsystem

Totwinkel- warner

Totwinkel- warner

Einparkassistent

Rundumsicht Rundumsicht

Querverkehrsassistent

Verkehrszeichenerkennung / Spurhalteassistent

AUTONOMES FAHRZEUGRadar

Lidar

Kameras

Weitsichtradar

Ultraschalltechnik

Die richtige Konfiguration der Fahrzeugumfeldsensorik ist entscheidend für hochautomatisierte Fahrfunktionen.

Bild:

ASAP

38_ASAP (wi).indd 40 12.03.2020 08:20:30

Unsere Antriebe sind Wegbereiter nachhaltiger Mobilität. Ob E-Auto, Hybrid oder elektrifizierter Verbrenner: Vitesco Technologies liefert moderne Antriebstechnik für saubere und effiziente Fahrzeuge. Antrieb für Generationen – Vitesco Technologies.

UNSER ZIEL IST EINE SAUBERE UND NACHHALTIGE MOBILITÄT.

IHRE ZUKUNFT IST UNSER ANTRIEB.

WWW.VITESCO-TECHNOLOGIES.COM

210x297mm_VT_AZ_Brunswick_AutomobilElektronik_DE_RZ_45L.indd 1 07.02.20 11:1741_1_1 Anzeigenlayout.indd 41 05.03.2020 14:17:32


ADAS + AD Infotainment

Das digitale Zuhause an BordWie neue Nutzeransprüche die Zuliefererindustrie verändern

Wie lassen sich ADAS/AD und Infotainment auf höheren Leveln in Einklang bringen? Nutzer erwarten heute ein Mobilitätserlebnis, das ihr durch Technologie geprägtes Leben aufgreift und erweitert. Das Auto verabschiedet sich damit endgültig von seinem Stand als Statussymbol und wird zu einem Elektronik-Produkt neben vielen anderen. Für die hieraus resultierende Neuorientierung braucht die Branche eine modernisierte Auffassung davon, wie Komponenten konzipiert und aufeinander abgestimmt werden können. Dieser Wandel kommt einem Paradigmenwechsel gleich. Autor: Andreas Wlasak

einstellungen, sichtbar und leicht zugäng-lich. Insassen können mit diesem ausge-klügelten IVI-Display Inhalte und Funk-tionen jederzeit individuell Wünsche anpassen.

Multifunktionale KomponentenDas Cockpit der Zukunft wird natürlich nicht nur durch Displays geprägt. Vielmehr bietet eine Vernetzung der digitalen und physischen Komponenten die Möglichkeit, auch abseits von futuristischen – und bald altmodisch anmutenden – Bildschirmen eine Vielzahl an Services in das Auto ein-zubinden. So kann etwa ein Luftausströ-mer zugleich funktional, dekorativ und interaktiv gestaltet und eingesetzt werden, beispielsweise indem er am Ende eines Massageprogramms eine aktivierende Funktion übernimmt. Die Beleuchtung des Türpanels kann neben ihrer dekorativen Funktion dazu dienen, den Fahrer bei Hin-dernissen auf der Fahrbahn zu alarmieren. Die Bündelung von Funktionen und der Schulterschluss zwischen den traditionel-len Hardwarekomponenten (zum Beispiel den Sitzen), den interaktiven Elementen

Wie kreiert man ein anspre-chendes Interieur, das neue, immersive Erlebnisse nahtlos

mit bestehenden Funktionen verbindet, die Vernetzung von Komponenten ermöglicht und dabei in allen Anwen-dungsszenarien eine nutzerfreundliche User Experience bietet? Mit dieser Frage sehen sich OEMs und Zulieferer verstärkt konfrontiert.

Der Appstore im AutoEin gutes Beispiel für das nahtlose Digi-talerlebnis im Fahrzeug und die damit ver-bundenen Herausforderungen ist die Inte-gration des Smartphones in das Interieur. Kaum ein Element hat den Fahrzeugin-nenraum bisher so sehr beeinflusst, ohne Teil des selbigen zu sein. Die „always on“-Mentalität, die Nutzer mit ihrem Smart-phone verbinden, überträgt sich auch auf das Cockpit der Zukunft. User erwarten neben der reibungslosen Weiterbenutzung ihrer Geräte oder VPAs, wie Siri und Ale-xa, nicht nur die sinnvolle Darstellung der bestehenden Applikationen, sondern auch weitere, fahrzeugspezifische Anwendun-

E-Mirror : Die digitalen Spiegel geben die über Außenkameras aufgenommene Umgebung im Cockpit des Innenraums wieder.

gen. Die Crux hieran ist die Adaption von Apps und Co. auf die Anforderungen im Auto. Insbesondere für Fahrer von Level-1-bis-3-Fahrzeugen steht dabei die Über-sichtlichkeit im Vordergrund, denn diese hat unmittelbaren Einfluss auf die Fahr-sicherheit.

Es braucht also eine grafische Oberflä-che, die verwirrende Menüstrukturen eli-miniert und mehr Flexibilität bei der Aus-wahl und Verwaltung von fahrzeugeige-nen und externen Funktionen bietet – das bestätigt auch die UX-Forschung. Die von Faurecia entwickelte Trenza HMI ermög-licht Benutzern, ihre am häufigsten ver-wendeten Apps oder Dienste übersichtlich auf dem IVI-Display (In-Vehicle-Infotain-ment) zu organisieren. Es vereinfacht zudem die Anpassung von Onboard-Ein-stellungen und individuellen Präferenzen. Um potenzielle Ablenkungsquellen für den Fahrer zu reduzieren, verwendet es eine Prioritätsverwaltung in der grafischen Designoberfläche. Das heißt: Wenn ein Fenster kleiner wird, bleiben wichtigere Einstellmöglichkeiten, wie z.B. Tempera-tur oder Lautstärke für HLK- oder Audio-

42_Faurecia (wi).indd 42 10.03.2020 12:29:47


ADAS + AD Infotainment


(Displays, Bedienoberflächen etc.) und der nutzerfreundlichen Software hat den Vor-teil, dass Platz und Ressourcen im Innen-raum gespart und Kosten reduziert werden.

Gaming und Cinema an BordDer Wunsch nach einem zunehmend indi-viduellen, abwechslungsreichen Erlebnis an Bord wächst – besonders durch neue Mobilitätskonzepte wie Shared Mobility und autonomes Fahren. Nicht mehr die Fahrt an sich, sondern der Zeitvertrieb während selbiger rückt in den Fokus. Ein vollkommenes Abtauchen in eine andere Welt wird möglich, wenn Hardware- und Software-Komponenten im Fahrzeug für weitere Nutzungsszenarien ineinander-greifen und ein immersives Entertainment an Bord erschaffen. Ton, Licht, Lüftung und Sitzvibrationen verbunden mit hoch-auflösenden Displays erweitern die Wahr-nehmung von Filmen und Gaming-Anwendungen zu multisensorischen 4D-Erlebnissen, die die Autofahrt für Pas-sagiere völlig verändern.

Durch die Vernetzung kann das Fahr-zeug zu einem Spielraum werden – im wahrsten Sinne des Wortes. So können über das zentrale Infotainmentsystem Passagiere auf Vorder- und Rücksitz mit-einander über ein lokales Netzwerk spie-len. Gemeinsam mit Microsoft implemen-tiert Faurecia im Cockpit der Zukunft die Microsoft Connected Vehicle Platform, die unter anderem die Integration von immersiven Gaming-Anwendungen ermöglicht. Basis hierfür ist der neue Stre-aming Service xCloud von Microsoft. Die-ser ermöglicht Nutzern, durch das Anschließen eines Xbox-Controllers auf ihr persönliches Nutzerprofil der Konso-

ESP Consulting), einer Sport- und Leis-tungsberatung, hat Faurecia Aktivitäten entwickelt, die an die Fahrzeugumgebung angepasst sind und auf spezifische Ziele wie Gewichtsabnahme oder eine Verbes-serung des Muskeltonus abzielen. Das Programm lässt sich unter Berücksichti-gung der physiologischen Variablen indi-viduell zuschneiden, beeinflusst durch Fahrzeugsensoren und Dauer der jeweili-gen Reise. Die Sensoren verfolgen den Trainingsfortschritt und folgen der Kör-perbewegung, während der Insasse unter-schiedliche Biege-, Hebe- oder Drehbe-wegungen ausführt. Das Programm kann mit anderen Onboard-Technologien, wie beispielsweise Infrarotkameras, verknüpft werden, um zu überprüfen, ob der Passa-gier überhitzt – dementsprechend kann im Anschluss die Lüftung angepasst wer-den. Die gesammelten Daten über Erfolge und Fortschritte können im Fahrzeug gespeichert oder an die Cloud weiterge-geben werden, um so das reguläre per-sönliche Trainingsprogramm zu Hause oder im Fitnessstudio fortzuführen und zu erweitern.

Wie das Automobil zum Schreibtisch auf Rädern wird, wie sich die gefühlte Sicherheit erhöhen lässt sowie weitere Aspekte finden Sie in der Langversion die-ses Beitrags per infoDIREKT 706ael0320 auf www.all-electronics.de. (wi) n

AutorAndreas WlasakVice President Design bei Faurecia


Der Streaming Service xCloud von Microsoft ermöglicht es Nutzern, auf ihr persönliches Nutzerprofil der Xbox-Konsole zuzugreifen und ihre persönli-chen Spielstände im Cockpit fortzusetzen.

Durch die Vernetzung wird bei Bedarf das Fahrzeug zu einem Spielraum. So können über das zentrale Infotainmentsystem Passagiere auf Vorder- und Rücksitz miteinander über ein lokales Netzwerk spielen.

le zuzugreifen und ihre persönlichen Spielstände im Cockpit fortzusetzen.

Wellness & WorkoutDa sich Fahrzeuginsassen mit zunehmen-der Automatisierung immer weniger auf die Straße konzentrieren müssen, rückt der Fokus auf ihr körperliches Wohlbefin-den. So bieten im Sitz eingebettete pneu-matische Elemente eine Reihe von ver-schiedenen Massage- und Vibrationsse-quenzen, die die Körpermuskulatur sti-mulieren oder entspannen. Diese werden mit Belüftung, Beleuchtungsakzenten, entspannender Musik und Düften kom-biniert, um das individuelle Wohlbefinden zu steigern. Faurecia entwickelt außerdem Sitzkonzepte, die aktiv Symptomen von Reisekrankheit vorbeugen.

Da der visuelle Fokus des Insassen oft-mals nicht in Fahrtrichtung liegt, sondern auf dem Smartphone oder einem Buch, nimmt das Auge nicht die gleiche Infor-mation auf wie der Körper, der beispiels-weise in einer Kurve der Zentrifugalbe-schleunigung ausgesetzt ist. Faurecia wirkt diesem Missverhältnis mit dem AVS-Sitz entgegen, der durch eine zusätzliche Leh-nen-Kopf-Verstellung den Oberkörper des Beifahrers soweit aufrichtet, dass die Umgebung auch bei Konzentration auf einen Bildschirm wahrgenommen wird. Zudem können optische Informationen, wie zum Beispiel die Horizontlinie, durch künstlich erzeugte visuelle Reize ersetzt werden. So kann auch bei extremeren Lie-gepositionen aktiv der entstehenden Rei-sekrankheit vorgebeugt werden.

Die Zeit an Bord kann zudem auch für körperliches Training genutzt werden. In Zusammenarbeit mit Human Fab (ehemals

Bilde

r: Fau

recia

42_Faurecia (wi).indd 43 10.03.2020 12:29:51


Optoelektronik Opto-Messtechnik


Design-Farbwelten im InterieurPräzise Lichtmesstechnik ermöglicht dezentrale Komponentenherstellung

Damit sich Fahrer und Passagiere im Fahrzeug wohlfühlen, sollte die Farbgebung der Displays und Bedienelemente im Innenraum Ton-in-Ton sein, so dass sämtliche wichtigen Informationen leicht und schnell erkennbar sind. Die Qualität optischer Parameter ist dabei bereits in der Produktion zu überprüfen, was eine dezentrale Komponentenfertigung ermöglicht. Autor: Cameron Hughes

Bild:

Syda

Prod

uctio

ns –

stoc

k.ado

be.co

m

44_Instrument Systems (aok).indd 44 10.03.2020 12:31:09




Displays sind heutzutage die Hauptinterakti-onsflächen, über die Passagiere und Fahr-zeug miteinander kommunizieren. Ihre

Anzahl im Auto steigt kontinuierlich, da sie neben dem typischen Infotainment immer mehr Spezial-aufgaben übernehmen, wie zum Beispiel auch die des Seitenspiegels. Zusätzlich sollen LED-Lichtstreifen und weitere leuchtende Elemente in der Passagierka-bine positiv zum Wohlfühlfaktor beitragen. Die Erwartungen der Fahrzeuginsassen in Bezug auf Bild- und Farbqualität von Displays sind stark von mobilen Endgeräten geprägt und daher extrem hoch. Das Ton-in-Ton-Konzept der Automobilhersteller für den Innenraum ist damit in der technischen Umset-zung äußerst anspruchsvoll und herausfordernd.

Technische Herausforderungen an Farb- und LeuchtdichtemessungenDie Kombination von unterschiedlichen, optischen Elementen kann im Interieur eines Fahrzeugs zu Irritationen führen, wenn deren Farben nicht präzi-se aufeinander abgestimmt sind. Selbst Farben, die nur leicht, aber dennoch erkennbar, voneinander abweichen, wirken unruhig und Passagiere empfin-den diese als störend. Je mehr leuchtende und bild-gebende Komponenten insgesamt vorhanden sind, desto größer ist dann das Risiko für ein abweichen-des und unharmonisches Element.

In der Regel stellen unterschiedliche Zulieferer die verschiedenen Bauelemente her. Für eine objektive und absolute Prüfung der optischen Parameter wie Farbe und Helligkeit ist daher an jedem Produktions-standort sehr spezifische Lichtmesstechnik erforder-lich, die hoch vergleichbare und metrologisch rück-führbare Messergebnisse garantiert und keine Refe-renzmessung mit einem Golden Sample benötigt. Für 2D-Displays ist zusätzlich eine bildgebende, räumlich

Die steigende Anzahl an Displays im Fahrzeuginnenraum sowie die Weiterentwick-lungen im Bereich Consumer Electronics erhöhen die Notwendigkeit für absolute und standardisierte Messungen. Für aussagekräftige Vergleiche zwischen EOL-Prü-fungen von Lieferanten und Nutzern müssen die verwendeten Lichtmessgeräte rückführbar geprüft sein. Die höchste Effizienz in Produktionslinien liefern kombi-nierte Systeme, die sowohl genau als auch schnell und robust sind. Instrument Sys-tems hat hierzu das Lumi-Top-Prinzip entwickelt.

Eck-DATEN

aufgelöste Analyse sowie die Beurteilung weiterer Aspek-te wie zum Beispiel der Homogenität notwendig. Dies erhöht die Komplexität der notwendigen Prüfprozesse und damit die Ansprüche an das Messequipment.

Qualitätsanforderungen an die HerstsellerDie deutschen Automobilhersteller Audi, BMW, Porsche und Volkswagen erarbeiten im Rahmen des Deutschen Flachdisplay-Forums (DFF) in der German Automotive OEM Working Group strenge Qualitätsmaßstäbe für optische und abbildende Eigenschaften von LC-Displays im Automotive-Bereich. Im Dokument Display Specifi-cation for Automotive Application V5.1 ist festgelegt, welche Pass-/Fail-Kriterien für optische Parameter bei zugelieferten Displays gelten und wie hoch die Akzep-tanz-Grenzwerte sind. Gemeinsam mit Messtechnik-Spezialisten werden auch die erforderlichen standardi-sierten Messverfahren und Auswertungsmethoden in unterschiedlichen Entwicklungsphasen festgelegt.

Für einen End-of-Line-Test (EOL-Test) ist außerdem eine umfangreiche Untersuchung erforderlich. Sie umfasst zum Beispiel die Helligkeit bei unterschiedlichen Grau-stufen (Gamma), Gleichmäßigkeit von Weiß- und Schwarz-Bildern (Bild 1), sowie die Erkennung von defek-ten Regionen des Displays (Dot-Defekte). Die Auswertung und Analyse der genannten Eigenschaften ist nicht tri-

Bild 1: Black Mura – Ungleichmäßigkeiten in der Helligkeit eines LCD sind mit einer Falschfarbdarstellung der Leuchtdichte leicht erkennbar. Für solche Messungen sind 2D-Messmethoden erforderlich.

Luminance of black test image on LCD tablet

1 cd/m2

0.3 cd/m2

Bild 2: Spektrale Messungen sind für Farbmessungen zu bevor-zugen, da sich damit die Intensität der einzelnen Farben, aus denen sich das Licht zusammensetzt, messen lässt.





HIGH FREQUENCY. HIGH PERFORMANCE. HIGH END. Wir sind die Partner für die Automobilindustrie mit Lösungen für aktuelle und zukünftige messtechnische Herausforderungen in F&E und Produktion für die Bereiche Radar, Vernetzung, Infotainment, EMV, Ethernet und elektronische Steuergeräte.

Test it. Trust it.

www.rohde-schwarz.com/automotive

MM-110118_AUT-Awareness_AEL-02_210x146_d.indd 1 03.03.2020 10:59:16

vial, und setzt eine Vereinheitlichung der Prüfungs-methoden voraus, um Ergebnisse aus unterschiedli-chen Lieferketten vergleichbar zu machen.

Dezentrale Vergleichbarkeit Da die Spezifikationen der OEM Working Group abso-lute Werte für die Leuchtdichte und die Farbkoordina-ten enthalten, müssen die verwendeten Lichtmessge-räte mithilfe von Kalibrierstandards justiert und somit ihre Messergebnisse rückführbar zu einem nationalen Institut wie der PTB (Physikalisch-Technische Bun-desanstalt) sein. Dieser Prüfprozess garantiert, dass Abweichungen in den Messwerten nur noch durch die Messunsicherheit des verwendeten Messinstruments entstehen. Je hochwertiger dieses ist, desto kleiner ist sein Fehlerbudget und umso besser ist die Überein-stimmung von wiederholten oder dezentralen Mes-sungen. Unter diesen Voraussetzungen ist ein realis-tischer Vergleich zwischen Eingangs- und Ausgangs-kontrolle bei Zulieferern und OEMs möglich und die Effizienz der gesamten Lieferkette verbessert.

Schnelle und präzise 2D-MessungenDie vollständige Überprüfung von Displays setzt 2D-Lichtmesstechnik voraus. Filterbasierte Leucht-dichte- und Farbmesskameras ermöglichen eine räumliche Auflösung der Messung und können bei Bedarf auf Subpixel-Niveau analysieren. Eine genaue Farbauswertung erfolgt über spektrale Messungen, die die Intensität des Lichts in Abhängigkeit zur Wellenlänge charakterisieren und detaillierte Infor-mationen darüber geben, welche Farben das Display anzeigt (Bild 2).

Weder die Umsetzung mit einem Spektrometer noch mit einem filterbasierten Colorimeter kann jedoch alle Anforderungen der OEM Working Group erfüllen. Spektrometer bestimmen den Farbort mit einer hervorragenden Genauigkeit und deutlich bes-ser als zum Beispiel filterbasierte Farbmessgeräte. Ihre Ergebnisse sind aber für einen begrenzten Spot ermittelt und deshalb nicht geeignet für eine 2D-Flä-chenanalyse. Ein bildgebendes (Filterrad-)Colori-meter kann Leuchtdichte und Farbort in 2D vermes-sen, ist aber deutlich langsamer im Vergleich zum Spektrometer, weil die verschiedenfarbigen Filter der Kamera nacheinander messen.

Das optimale System, das alle Anforderungen bezüglich Geschwindigkeit und Genauigkeit erfüllt, ist die Kombination von einer Leuchtdichte- und Farbmesskamera mit einem Spektrometer. Das Spek-trometer liefert präzise Daten für einen Spot, der sich als Referenz für die Farbmesskamera nutzen lässt. Als Ergebnis liefert die Messung Daten mit spekt-ralradiometrischer Genauigkeit für das gesamte 2D-Bild. Das kombinierte System besitzt eine schnel-le Taktzeit und kann das gesamte Bild in unter einer Sekunde aufnehmen. Damit erreicht es die im Auto-motive-Bereich typische Anforderung, mehrere Dut-zend Bilder inklusive ihrer Auswertung in wenigen Sekunden anzufertigen.

Das Messsystem muss neben einfachen Messun-gen (wie unter anderem maximale Helligkeit für weißes, rotes, blaues und grünes Display) auch kom-plexe Untersuchungen von zum Beispiel Leucht-dichtehomogenität und Graueinstellungen unter verschiedensten Betriebsbedingungen abbilden. Dazu gehören zum Beispiel die Umgebungstempe-ratur (Temperaturbereich von -40 °C bis +85 °C) oder das Umgebungslicht (Tag- beziehungsweise Nacht-licht) oder auch Langzeittests (angestrebte Lebens-dauer bis zu 15 Jahren).

Umsetzung in der ProduktionslinieFür EOL-Prüfungen entwickelte Messgeräte müssen besonders hohe Ansprüche erfüllen: hohe Messgenau-igkeit bei gleichzeitig kurzen Messzeiten und eine robuste 24/7-Performance. Speziell für diesen Einsatz hat Instrument Systems das Lumi-Top-Prinzip ent-

Bild 3: Das Lumi-Top-Prinzip der 3-in-1-Lösung (Farbkamera, Spektrometer und Photo-meter) ermöglicht EOL-Untersuchungen mit hoher Genauigkeit, schnellen Messungen und robuster Operation.

Bild 4: Für die Integration weiterer EOL-Komponenten ist ein SDK für die Kamera zwin-gend erforderlich.

Grundfunktion(Bildbearbeitung/Analyse)

Bildaufnahme Messprozess Pass / Fail

Analyse

Gerätesteuerung(Kommuniktion, Messung)

Black:Mura Auswertung

GammaAuswertung

SDK Funktionen

SDK KomponentenBil

der: I

nstru

men

t Sys

tems



HIGH FREQUENCY. HIGH PERFORMANCE. HIGH END. Wir sind die Partner für die Automobilindustrie mit Lösungen für aktuelle und zukünftige messtechnische Herausforderungen in F&E und Produktion für die Bereiche Radar, Vernetzung, Infotainment, EMV, Ethernet und elektronische Steuergeräte.

Test it. Trust it.

www.rohde-schwarz.com/automotive

MM-110118_AUT-Awareness_AEL-02_210x146_d.indd 1 03.03.2020 10:59:16

Autor Cameron Hughes Product Manager BU Lab Equipment bei Instrument Systems


wickelt (Bild 3). Es kombiniert eine RGB-Kamera und eine schnelle Photodiode mit einem High-End-Spek-tralradiometer. LCDs können abhängig von Betriebs-spannung oder Backlight erkennba-re optische Modulationen der Leuchtdichte aufweisen, die für einen Anwender störend wirken. Mittels Photodiode lässt sich dieser Flicker-Effekt nach JEITA-Standard (Japan Electronics and Information Technology Industries Association) untersuchen und bestimmen. Die 3-in-1-Lösung des Lumi-Top-Prinzips bietet in der Produktionslinie eine schnelle und einfache Messlö-sung für diese und andere Messanforderungen.

Integration weiterer SteuerlementeFür eine automatisierte Umsetzung in der Produk-tionslinie, sind in der Regel weitere Steuerelemente in eine EOL-Prüfstation zu integrieren. Diese steu-ern dann die Displayanzeige, rufen die notwendigen Bilder ab und ermöglichen außerdem Anpassungen der Display-Justierung.

Zur Untersuchung des Black-Mura-Standards ist zum Beispiel eine senkrechte Ausrichtung des Dis-plays mit einer Genauigkeit unter 0,5° in alle Rich-

tungen nötig. Idealerweise besitzen die Komponen-ten der Prüfstation jeweils ein Software-Develop-ment-Kit (SDK) mit Treiber für alle wichtigen Funk-

tionen des Systems. Dies verein-facht die Integration in das Hand-lersystem und gewährleistet einen reibungslosen Testablauf.

Von Vorteil ist eine standardisier-te Auswertung der OEM-Spezifika-tionen mithilfe vorkonfigurierter Analyse-Tools, um eine schnelle Beurteilung nach Pass-/Fail-Krite-

rien durchzuführen und so den Durchsatz zu opti-mieren (Bild 4). Sämtliche Softwaremodule sollten mit den OEM-Spezifikationen konform sein, um zu garantieren, dass Ergebnisse aus unterschiedlichen Quellen beziehungsweise Messungen die gleiche Qualität liefern. (aok) ■

Das Messsystem arbeitet bei

Umgebungs-temperaturen von

-40 bis 85 °C.



Optoelektronik Iseled


Lösungen für Kfz-InnenbeleuchtungenMicrochip engagiert sich im Bereich Iseled

Mit Ausnahme von Hintergrund-Beleuchtungsfunktionen gab es in der Vergangenheit praktisch keine komplexe oder steuerbare Umgebungsbeleuchtung im Fahrzeuginnenraum. Heute entwickelt sie sich zum De-facto-Standard für designrelevante Implementationen im Kfz und in seiner Umgebung. Autor: Stefan Kouba

hinaus kommen die LEDs von unter-schiedlichen Lieferanten, aus verschiede-nen Fertigungslosen, und unterliegen einer Alterungs- und Temperaturdrift-Kurve. Folglich ist es kaum möglich, dass Unternehmen dieses Umgebungslicht-Konzept integrieren können, deren Kern-kompetenzen beim Lenkrad, bei kapazitiv-berührungsempfindlichen Knöpfen, bei Kabelbaum-Platzierung, LED-Fertigungs-sortierung, -Kompensation oder -Kalib-rierung liegt.

Innovation bei Kfz-Innenausstattungen im Zusammenspiel mit Beleuchtungs-

Iseled-Module sind mit einem intelligenten Bauteil ausgestattet, das es dem Modul ermöglicht, eine Farbtemperatur-Kompensation, Binning und Kalibrierung durchzuführen. Dadurch verhal-ten sich die LEDs identisch, unabhängig von Fertigungslos, Lieferlos, Zeit oder Temperatur. Jede LED zeigt genau die gleiche Farbtemperatur. Deshalb kommt die Iseled-Technologie jetzt vor al-lem in Kfz-Anwendungen zum Einsatz, bei denen oft unterschiedliche Zulieferer mit Beleuch-tungsmodulen arbeiten, die erst später im Fahrzeug zusammengeführt werden.

Eck-DATEN

Die Bedienelemente in Fahrzeugen haben sich im letzten Jahrzehnt stark weiterentwickelt. Benutzte

man früher viele Einzelknöpfe, die jeweils eine spezifische Funktion hatten, sind Schalter im Innenraum heute komplexer. Sie bieten Mehrfach-Funktionsbelegun-gen, Mini-Nutzung und interaktive Dis-plays. Zusätzlich beeinflussen unterstüt-zende Fahrfunktionen sowie Assistenz-funktionen den Inhalt über HMI-Interak-tionsfenster, und bringen ein neues Maß an Komplexität in modernen Fahrzeugen.

Aktuelle Raumbeleuchtungs-System-designs leiden unter einigen deutlichen, fertigungsbedingten Einschränkungen. Lichtführungen lassen sich nur dort anordnen, wo der Hersteller von Kabel-bäumen sie einfach installieren kann – von links nach rechts, im Fußraum etc.. Lichtführungen lassen sich nur schwer nahe beim Lenkrad, beim Schalthebel oder in einer Dachkonsole platzieren, da

diese nicht vernetzt sind. Um Unterschie-de bei den Farbtönen zu vermeiden, wählt man Umgebungslicht-LEDs mit vollkom-men unterschiedlichen Farben aus (bläu-liches Umgebungslicht an der Lichtfüh-rung und Orange an den Knöpfen auf dem Lenkrad). Nichts ist verwirrender als vier unterschiedliche rote Farbtöne bei vier verschiedenen Knöpfen im glei-chen Bereich.

Mit verschiedenen Lieferanten-Quellen für die Lichtführung, das Lenkrad, die Dachkonsole und die Türmodule ist dies eine komplexe Herausforderung. Darüber

Bild 1: Umfeld-Beleuchtungskonzept in einem zukünftigen Fahrzeug.

48_Microchip (wi).indd 48 11.03.2020 10:42:08

AUTOMOBIL ELEKTRONIK 03 / 2020 49



Integration ist ein sehr anspruchsvoller Aufgabenbereich. Das Licht in Bild 1 ist dort angeordnet, wo sich die Führung pro-blemlos rund um das Display oder den Fußraum platzieren lässt, aber nicht wo es aus Sicht des Designs wirklich sinnvoll wäre. Sicherheitsbezogene Aspekte wie die Integration auf dem Lenkrad oder in der Dachkonsole (siehe Bild 1) wären eben-falls wünschenswert.

Zudem können Beleuchtungsmodule nicht synchron miteinander kommunizie-ren; dies macht Implementationen wie dynamische Lichtef fekte prakt isch unmöglich. So kann man beispielsweise keine Umstellung des Licht-Farbton von der linken zur rechten Seite erzielen. Zur Lösung dieser Probleme und zum Einstieg in die nächste Evolutionsstufe des Innen-beleuchtungs-Designs im Fahrzeug ist eine Implementation neuer Design-Ver-fahren und -Konzepte nötig. Man stelle sich ein autonomes Level 3 Fahrzeug im Selbstfahrbetrieb vor, das diesen Betrieb in grüner oder blauer Farbe anzeigen könnte. Fordert das Fahrzeug den Fahrer zur Übernahme der Lenkfunktion am Lenkrad auf, dann würde es dies für 10 Sekunden mit durchlaufenden Streifen in gelb oder rot anzeigen. Kurz bevor der Fahrer übernehmen muss, könnte die Beleuchtung beginnen, rot zu blinken.

Die LösungDie Iseled-Technologie wurde als Lösung für diese Probleme entwickelt; dazu besitzt sie ein integriertes, intelligentes Bauteil im Inneren des LED-Moduls. Dieses Modul übernimmt Farbtemperatur-Kompensati-on, Binning und Kalibrierung. Als Ergeb-nis verhalten sich die LEDs identisch,

Mbit/s miteinander verschalten lassen (sie-he Bild 3). Diese Spezifikation ermöglicht neue Anwendungen wie dynamische Lichteffekte mit unterschiedlichen Farb-konzepten und Farbmischungen. Weitere Möglichkeiten innerhalb von Matrix-Rücklicht-Anwendungen, Außenbeleuch-tung und der Steuerung von Hintergrund-beleuchtungen umfassen verschiedene dynamische Dimming-Stufen der LED-Hintergrundbeleuchtung zur Steigerung von Kontrast und Farbqualität.

unabhängig von Fertigungslos, Lieferlos, Zeit oder Temperatur. Jede LED zeigt genau die gleiche Farbtemperatur, und löst damit wichtige Probleme, die Autoherstel-ler in der Vergangenheit überwinden mussten. Die Kalibrierung wird auf LED-Ebene ausgeführt, und große Hersteller wie Osram und Dominant Opto fertigen bereits solche LEDs.

Ein weiterer Vorteil besteht darin, dass sich mehr als 4000 Knoten in Reihe und mit einer sehr hohen Datenrate von 2

... und heute.

Bild 4: Wahl der Mikrocontroller je nach Anwendung.

LightEffects

µCTpd = 2 clock cyclesdata nearly simultaneously at all LEDsLEDs can be addressed individually

2MBits/sdifferential;no clock

2 Wire

Bild 3: In Reihe verschaltete Iseled-Konfigurati-on mit 2 Mbit/s.

LightEffects

µC

Tpd = 2 clock cyclesdata nearly simultaneously at all LEDsLEDs can be addressed individually

2MBits/sdifferential; no clock2 Wire

8 ld package

Bild 1: Armaturenbretter gestern ...





AutorStefan KoubaMarketing Manager, Automotive Products Group, Microchip


Lösungen von MicrochipIm praktischen Einsatz erfordert die Ansteuerung der Iseled-LED-Kette einen Mikrocontroller, der ein spezielles Proto-koll mit einer Iseled-fähigen seriellen Engine benötigt. Die Stärke von Micro-chips Mikrocontrollern ist die Implemen-tation von sogenannten „Core Indepen-dent Peripherals“ (CIPs).

Diese Block-Sätze lassen sich über Glue-Logik und andere Peripherieelemente, Flipflops usw. miteinander verbinden. So ist es möglich, Iseled-Peripherieelemente komplett in Hardware zu erstellen. Damit entfallen Software und CPU-Lasten, was die Belastung des Prozessors verringert. Dank dieser Features lassen sich Iseled-LEDs selbst mit der einfachsten und kleinsten 8-Bit MCUs steuern. Zusätzlich unterstützt Microchip Iseled auf allen sei-nen Mikroprozessoren bis zu seiner 32-Bit-Autosar-MCU mit 2 MB Speicher (sie-he Bild 4).

Darüber hinaus ermöglicht diese Fähig-keit die Implementation und Mischung weiterer wichtiger Sätze von Design-Bau-steinen sowie weitere Innovationen. Einer der Bausteine könnten ein LIN, ein Boot-loader, ein kapazitiv-berührungsempfind-liches Wischmodul oder ein kapazitiver Näherungssensor sein. Ist noch verblei-bende Bandbreite verfügbar, lassen sich diese Implementationen bei minimalem zusätzlichen Softwareaufwand und eini-gen zusätzlich nötigen CPU-Zyklen mit CIPs ergänzen.

So besitzt beispielsweise die PIC18F K42 MCU-Familie ein eingebautes Iseled-Modul sowie ein LIN UART mit einer spezifischen LIN-Zustandsmaschine in Hardware neben Sync Break und Auto-baud UART-Funktionen. Darüber hinaus

Code-Konfigurator und stellt die Entwick-lung schnell fertig. Dabei geht es darum, eine Implementation von Iseled-Innova-tionen möglichst schnell und einfach zu gestalten.

FazitRGB-Innenbeleuchtung ist mit komplexen Problemen verbunden, die in vielen Fahr-zeug-Anwendungen zu Einschränkungen der Innovation beim Versuch führten, andere Funktionen mit der Umgebungs-beleuchtung zu kombinieren. Iseled und Microchip überwinden diese technischen Hürden in Entwicklung und Fertigung. Microchip bietet ein umfassendes Pro-dukt-Portfolio für Iseled von High-End 32-Bit-MCUs bis zu einfach einsetzbaren, stromsparenden und kosteneffizienten 8-Bit-MCUs. Weiterhin gibt es bei Micro-chip Kombinationen aus LIN-to-Iseled, Spannungsversorgung und kapazitiven Berührungsfunktionen. All dies ist auf einem Single-Chip-Baustein erhältlich, der in einem 5 × 5 mm Gehäuse das welt-weit kleinste LIN-to-Iseled Modul enthält. CIPs lassen sich über den Microchip MPLAB Code Configurator und eine Iseled-Evaluierungsversion konfigurieren. Daraus generierten Quellcode kann man anschließend auf eine Entwicklungspla-tine herunterladen. (wi)� n

wird diese Bauteilfamilie mit einem in Hardware realisierten CAPTouch-Modul gefertigt.

Aus dem Microchip 32-Bit-Produktan-gebot bietet die SAM-HA1-Bausteinfami-lie besondere Fähigkeiten: Diese Familie besitzt neben den Iseled, LIN UART und kapazitiven, berührungsempfindlichen PTC-Modulen eine integrierte Vbat Load-Dump-Funktion sowie LDO- und LIN-Transceiver. Damit lässt sich eine Single-Chip-Lösung als LIN-to-Iseled mit inter-nem Näherungssensor-Modul in einem nur 5 × 5 mm großen Gehäuse realisieren. Dabei handelt es sich um die kleinste leis-tungsfähige Iseled-Lösung auf dem heu-tigen Markt.

Zur Konfigurierung und Aktivierung einer Iseled-Peripherieschaltung ist die Modul-Konfiguration in einer separaten, herunter ladbaren Datei, dem MPLAB Code Configurator integriert. Mit diesem GUI-fähigen Konfigurator kann man die Peripherieschaltungen über wenige ein-fache Mausklicks einrichten. Dieser Kon-figurator lässt sich zudem mit anderen Peripherieschaltungen wie etwa Berüh-rungs- und LIN-Modulen kombinieren.

Der Code-Konfigurator ist kostenlos per Download von der Microchip-Website oder beim Microchip-Vertrieb erhältlich. Für diesen Zweck muss man einen kos-tenlosen Evaluierungs-Lizenzvertrag akzeptieren (siehe Bild 6). Für seine MCUs bietet Microchip außerdem Entwicklungs-Boards mit einfachen Einsteck-Optionen für die Iseled Plug-in-Hardware (siehe Bild 5); weitere Einsteck-Optionen für den LIN-Transceiver und kapazitiv-berührungs-empfindliche Sensoren sind ebenfalls erhältlich. Nun steckt man die Iseled-Ket-ten ein; anschließend startet man den

Bild 5: Entwicklungs-platine mit Iseled Plug-in-Modul.

Bild 6: MPLAB Code Configurator für Iseled.

65 Bilde

r: Micr

ochip



Optoelektronik Mr. Insider

mal außen vorlässt, dann landet man bei dreckigen Scheinwerfern. Schon eine 10-prozentige Verschmutzung erhöht die Blendwirkung messbar.

Staub und Dreck streuen LichtDie feinen Staub- und Dreckpartikel auf dem Glas wirken wie mikroskopische Streulinsen und verteilen den parallel ausgerichteten Lichtstrom in uner-wünschte Bereiche. So gelangt Streulicht

auch nach oben in die Sichtlinie.

Natürlich wird Autofahrern gera-ten, ihre Schein-werfer sauber zu halten. Das liegt ebenso in ihrem

eigenen Interesse, weil Staub auf dem Glas Licht „schluckt“, wie im Interesse des Gegenverkehrs, den das Streulicht massiv stört. Gerade bei winterlichen Straßenver-hältnissen genügen schon wenige Minuten Fahrt, um neuen Dreck auf die Scheinwer-fer zu bringen.

Systematische Versuche an vier ver-schiedenen LED-Scheinwerfern sowie an einem herkömmlichen H7-Halogenlicht sprechen da eine klare Sprache. Es gibt nämlich gemäß ECE R45 zwei kritische Messpunkte für solche Bewertungen. Die sogenannten Blendpunkte l iegen in Augenhöhe der entgegenkommenden Fahrer (B50L bei Linkslenkerfahrzeugen, B50R bei Rechtslenkerfahrzeugen). Dort-hin darf kein Licht gelangen. Bei der

Bei Licht betrachtet

Mr. Insider weiß, worum es geht, denn er arbeitet in unserer Branche: manchmal beim OEM, manchmal beim Zulieferer und manchmal einfach nur in diesem Dunstkreis. Er arbeitet an den Grundlagen und Pro-jekten, die uns weiterbringen sollen: vom Powertrain über Body-Control und ADAS bis hin zum Infotain-ment. Mr. Insider will niemandem schaden, sondern dafür sorgen, dass wir Aufgaben gemeinsam angehen und uns bewusst werden, wo wir noch ein paar Steine aus dem Weg räumen müssen. Diesmal geht es um Beleuchtungstechnik. Autor: Mr. Insider

Messreihe sah das jedoch sehr oft anders aus. Je nach dem Anteil der Staubbede-ckung (10 bis 80 %) und der Art der Scheinwerfer nahm die Blendwirkung an B50L um jeweils zwischen 140 % und bis zu über 700 % zu!

De facto zeigt sich, dass auch Schein-werfer unterhalb der Grenze von 2000 lm Lichtstrom ein irritierendes Streulicht erzeugen, wenn sie dreckig sind. Die momentane gesetzliche Regelung mit der 2000 Lumen-Grenze ist damit unzuläng-lich. Die Tests bestätigen: Xenonschein-werfer, bei denen SRA und LWR gesetzlich vorgeschrieben sind, unterscheiden sich in diesem Punkt in keinster Weise von den anderen Scheinwerfern mit geringerem Lichtstrom (I < 2000 lm).

Auch LED- und Halogenscheinwerfer mit schmutzigen Gläsern blenden. Und gerade die Augen der wachsenden Zahl älterer Verkehrsteilnehmer reagieren emp-findlich darauf.

Ein bisschen wie beim FußballIn Abwandlung einer allseits bekannten Fußballweisheit könnte man es so formu-lieren: „Was zählt, ist auf der Straße.“ Und da sieht es eben anders aus als in der The-orie der ECE R48.

So bleibt letztendlich nur eine sinnvolle Maßnahme: Wir sollten einen verpflich-tenden Einbau von SRAund LWRfür alle Scheinwerfertypen endlich im richtigen Licht betrachten. Im Sinne aller Verkehrs-teilnehmer besteht nämlich wirklich Handlungsbedarf.(av) n

Auch LED-und Halogenscheinwerfer mit schmutzigen Gläsern

blenden.

Zugegeben, es ist ein etwas schmut-ziges Thema: verdreckte Schein-werfer und deren Blendwirkung.

Momentan bleibt es dem Autofahrer über-lassen, für saubere Abdeckscheiben zu sorgen. Es gibt allerdings ein paar wenige Ausnahme: Bei Scheinwerfern mit einem Lichtstrom von über 2000 lm (etwa bei (Bi-)Xenon-Scheinwerfern) sind Reini-gungsanlagen vorgeschrieben. Bei allen anderen Scheinwerfern geht der Gesetz-geber allerdings davon aus, dass es keinen Anlass für den verpflichten-den Einbau von Scheinwerferrei-nigungsanlagen (SRA) und einer Leuchtweitenregelung (LWR) gibt (ECE R48). Ein Trugschluss und eine Deutungs-lücke, wie Messungen zeigen.

Sichere Nachtfahrten ermöglichenGutes Licht ist eine Voraussetzung für sichere Nachtfahrten. Des einen Freud‘ kann allerdings des anderen Leid sein. Das weiß jeder, der schon einmal vom Gegen-verkehr geblendet wurde. Aber halt, wie kann das denn sein? Moderne Scheinwer-fer erzeugen eine scharfe Hell-Dunkel-Grenze, die so den Gegenverkehr ausspa-ren und damit eine Blendung vermeiden soll. Woher kommt dann trotzdem eine Blendwirkung? Wenn man offensichtliche Fehler wie falsch justierte Scheinwerfer oder überladene Fahrzeuge ohne LWR ein-

Bild:

kent

oh –

Ado

beSto

ck

51_Mr. Insider (av).indd 51 10.03.2020 12:32:56


Management Komplexität


Variantenvielfalt unter KontrolleWie sich die Zahl der Software-Versionen begrenzen lässt

Software spielt eine immer wichtigere Rolle in Fahrzeugen. Doch Programme zu entwickeln und zu pflegen, wird für Automobilhersteller und OEMs immer aufwändiger und stellt sie vor neue Heraus-forderungen. Ein Grund ist die hohe Zahl der Software-Varianten. Gefordert ist daher ein gemeinsa-mes „Komplexitätsmanagement“ im Bereich Software. Autor: Martin Schleicher

zeuge permanent („Always-on“) mit einer Cloud ver-bunden. Über Cloud-Plattformen kann der Nutzer individuelle Services buchen, etwa einen Car-Sha-ring-Dienst oder einen

Platz an einer Ladesäule. Auch Software-Updates lassen sich künftig „Over the Air“ (OTA) via Cloud aufspielen. Das gilt auch für aktualisierte Sicherheits-funktionen, die ein Fahrzeug vor Hacker-Angriffen schützt. Wohin die Reise geht, zeigt beispielsweise der ID.3 von Volkswagen. Das Elektro-Fahrzeug lässt

Software im Automobil wird wichtiger und kom-plexer. Dies ist Trends wie Connected Car, dem autonomen Fahren, dem Einsatz von Assis-

tenzsystemen und neuen Formen von Human Machi-ne Interfaces geschuldet. Davon profitieren Käufer von Fahrzeugen. Denn ihnen stehen zusätzliche Komfort- und Sicherheitsfunktionen zur Verfügung wie beispielsweise Sprachsteuerungen, die Sprachas-sistenten von Anbietern wie Amazon (Alexa), Goog-le und Apple nutzen. Zudem sind immer mehr Fahr-

52_Elektrobit (wi).indd 52 10.03.2020 12:34:09




sich je nach Version mit 2D- und 3D-Human-Machi-ne-Interfaces ausstatten.Doch diese Entwicklung bringt für Hersteller und OEMs auch Herausforderungen mit sich:

• Der Aufwand für das Entwickeln neuer und das Anpassen vorhandener Software-Funktionen steigt und wird zu einem ernstzunehmenden Kostenfak-tor für die Automobilindustrie.

• Die Zahl und Komplexität der Fahrzeugmodelle sowie Ausstattungsoptionen, und damit auch der Steuergeräte, Prozessorderivate und Software-Architekturen nimmt zu. Das führt zu vielen Soft-ware-Varianten, die es zu verwalten gilt.

Wie lässt sich die Variantenvielfalt der Software im Auto in den Griff bekommen? Ei-ne Möglichkeit ist die Standardisierung der Software im Automobil, wie beispiels-weise bei Autosar geschehen. Eine weitere Option ist ein aktives Management von Software-Varianten. Dies muss in der Software-Architektur angelegt sein. Drittens durch die Einführung agiler Entwicklungsmethoden wie Lean Development, Scrum, Kanban und DevOps.

Eck-DATEN

• Zahlreiche Software-Funktionen wurden über Jah-re hinweg weiterentwickelt und gepflegt. Der Pfle-geaufwand steigt dadurch kontinuierlich.

Diese Faktoren verdeutlichen, dass der Anteil der Software- und E/E-Komponenten (Electrical and Elec-tronics) in Fahrzeugen erheblich steigt. Laut der Stu-die „Automotive Software and Electronics 2030“ des Beratungsunternehmens McKinsey von 2019 wird der Wertanteil von Lösungen aus beiden Bereichen von 238 Milliarden Dollar im Jahr 2020 bis 2030 auf rund 470 Milliarden Dollar steigen. Der Bereich Soft-ware (Funktionen, Betriebssysteme und Middleware) legt in den kommenden zehn Jahren um durchschnitt-lich 9 Prozent pro Jahr zu. Die Aufwendungen für Services wie Integration, Verifizierung und Validie-rung steigen um zehn Prozent.

Die zunehmende Komplexität der Software hat weitere Effekte: McKinsey zufolge ergibt sich eine immer größere Lücke zwischen der Produktivität der Software-Fachleute und der Anforderung, immer reichhaltigere Programme möglichst schnell verfüg-bar zu machen. Der Ansatz Software-Projekte mit immer größeren Teams durchzuführen wird auf Dau-er nicht mehr umsetzbar sein. Ein Infotainment-Sys-tem zu entwickeln, dauert beispielsweise drei Jahre und bindet Hunderte von Entwicklern. An die 30 bis 50 Prozent der Zeit und damit des Aufwandes müssen diese darauf verwenden, die Komponenten der diver-sen Zulieferunternehmen in die Lösung einzubinden und zu testen.

Problempunkt: Vielfalt von Software-VariantenEin weiterer Problempunkt ist die große Zahl von funktionalen und Anwendungsvarianten von Soft-ware-Komponenten, die eigentlich dieselbe Funktion erfüllen. Ein Beispiel sind Navigations- und Infotain-ment-Systeme. Die Anforderungen vieler Automo-bilhersteller an diese Lösungen sind ähnlich, doch die Umsetzung der Funktionen in Software unter-scheidet sich häufig im Detail, etwa aufgrund des Einsatzes unterschiedlicher Schnittstellen oder indi-vidueller Anforderungen der Hersteller. Selbst bei nicht differenzierenden Software-Komponenten wie Autosar gibt es eine Vielzahl OEM-spezifischer Inter-pretationen des Standards sowie OEM-spezifische Erweiterungen. Dadurch müssen vorhandene Soft-ware-Module an die individuellen Anforderungen jedes Automobilherstellers angepasst werden. Eine unveränderte Wiederverwendung von vielen Modu-len ist praktisch ausgeschlossen. Das erhöht den Auf-wand und die Kosten bei der Entwicklung beziehungs-weise Anpassung und der langfristigen Pflege.

Hinzu kommt der Aufwand, den das Anpassen von Software beim Wechsel von einer Fahrzeuggenerati-on zur nächsten erfordert. Während man davon aus-

Die steigende Soft-ware-Komplexität im Fahrzeug erfordert ein Umdenken in der Automobilindustrie.

Bilde

r: Elek

trobit





geht, dass der Löwenanteil des Aufwandes in die Entwicklung neuer Funktionen fließen sollte, zeigen Auswertungen von Elektrobit, dass nur etwa 40 Pro-zent des Entwicklungsbudgets für neue Funktionen aufgewendet werden, aber 60 Prozent für die Pflege bestehender Funktionen.

Weitere Herausforderung: Vielzahl von Hardware-Komponenten und PlattformenDoch ein Reduzieren der Software-Versionen wird durch die hohe Zahl der Hardware- und Plattform-varianten bei den einzel-nen Automobilherstellern erschwert. Durch die Ein-führung f lexibler Platt-formkonzepte haben die Autobauer in den letzten Jahren erreicht, dass sie vergleichsweise einfach neue Fahrzeugmodelle ableiten können. Vor 40 Jahren hatte Daimler zirka zehn Fahrzeugmodelle, in den 2000er Jahren waren es bereits 20 und für das Jahr 2020 sind bis zu 40 Modelle vorgesehen. Dies bedeu-tet, dass auch die eingesetzte Software diese Vielfalt abbilden muss. Das erfolgt durch die Anpassung der Programme, die in den Steuergeräten in einem Fahr-zeug eingesetzt werden.

Dieser Faktor erhöht den Aufwand, der mit der Entwicklung von Software verbunden ist. Gleiches gilt für die Integration und den Test der Software-Varianten. Während Fahrzeughersteller eine ausge-feilte Logistik für die Handhabung von unterschied-lichen Fahrzeugteilen besitzen, fehlen häufig Kon-zepte für den Umgang mit Software-Varianten.

Ansätze zur Reduzierung der Komplexität von PlattformenAbhilfe kann eine stärkere Standardisierung der Soft-ware in Automobilen schaffen, etwa im Rahmen von Gremien wie Autosar. Autosar ist als Standard eta-

bliert und hat zu einer erheblichen Kosteneinsparung und Qualitätssteigerung bei Standardsoftware geführt. Durch die immer noch große Variantenviel-falt ist das Potenzial jedoch noch nicht ausgeschöpft. Ein Beispiel ist Autosar 4.x. Obwohl damit bereits eine weitgehende Vereinheitlichung definiert wurde, gibt es immer noch eine Vielzahl von OEM-spezifi-schen Varianten und Erweiterungen. Das führt dazu, dass Software nur eingeschränkt wiederverwendet werden kann. Die Qualität von Standardsoftware lässt sich so nur schrittweise verbessern. Es gilt also,

zusätzlich neue Ansätze hinzuziehen.

Ein Vorbild für schnelle und effiziente Entwick-lung von Standards kön-nen dabei Ansätze von Open Source sein. Open Source erlaubt eine ver-

gleichsweise einfache Evaluation und Weiterentwick-lung neuer Software-Lösungen, da sich nur wenige Standards flächendeckend durchsetzen. Lösungen, die nicht praktikabel sind, finden keine weitere Ver-wendung.

Aktive Verwaltung von Software-VariantenEine weitere Option ist ein aktives Management von Software-Varianten. Dies muss in der Software-Archi-tektur angelegt sein. Eine Möglichkeit ist, Varianten an möglichst wenigen Stellen in der Software anzule-gen, etwa in Abstraktionsschichten (Layern). Dadurch ist es einfacher, standardisierte Software-Bausteine auf unterschiedlichen Systemen zu verwenden.

Die Wiederverwendung von Software ist kein Selbstzweck. Wiederverwendung macht dann Sinn, wenn sie zu Kostensenkungen und Qualitätssteige-rung führt. Dies muss in der Architektur angelegt sein. In vielen Projekten wird die Priorität jedoch auf eine individuelle Optimierung von Software gelegt, bezogen auf das Steuergerät sowie die OEM-Archi-

Die Wiederverwendung von Software ist kein

Selbstzweck

Die Evolution der E/E-Architektur in Fahr-zeugen: Die Entwick-lung geht in Richtung einer serviceorien-tierten Software- Architektur (SOA).

Fahrzeugnetzwerk

Mikrocontroller-ECUs

Statisch konfiguriertes Betriebssystem

Service-orientierte Architektur (SOA)

Always-on Cloud-Konnektivität

Zonenarchitektur Rechenzentrum im

Fahrzeug





AutorMartin SchleicherExecutive Vice President Business Management bei Elektrobit


tektur und Funktion. Dies geht zu Lasten der langfristigen Qualität und Stabilität der Software und führt zu einem höheren Aufwand.

Agile Entwicklungsmethoden einsetzenEine andere Möglichkeit ist die Einführung agiler Ent-wicklungsmethoden wie Lean Development, Scrum, Kan-ban und DevOps. Durch sie lassen sich Ergebnisse schnell auf Nutzbarkeit praktisch untersuchen. Während bei Lean Development die kontinuierliche Verbesserung der Arbeitsabläufe sowie die Stärkung der Eigenverantwor-tung der Entwicklerteams im Vordergrund stehen, setzt sich agile Entwicklung insbesondere mit der Risikomini-mierung auseinander, um dank höherer Transparenz im Entwicklungsprozess Produkte schneller zur Serienreife zu bringen.

Bei Scrum handelt es sich um eine Umsetzung dieser beiden Konzepte für die Steuerung von Software-Projek-ten. Dabei werden die anstehenden Aufgaben in kleinere und überschaubare Abschnitte strukturiert, um ihre Kom-plexität zu reduzieren. Kanban schließlich reduziert die Zahl paralleler Arbeiten durch eine Visualisierung der bestehenden Arbeitsabläufe. Dadurch werden sowohl der Projektfortschritt als auch Engpässe schneller sichtbar. Ergänzend lassen sich Verfahren wie DevOps (Develop-ment – IT Operations) einsetzen. DevOps zielt darauf ab, das Zusammenspiel zwischen Software-Entwicklung und der IT-Infrastruktur zu verbessern.

Total Cost of Ownership für SoftwareUnabhängig von solchen Optimierungsmaßnahmen gilt es jedoch, das Bewusstsein von Herstellern und Zuliefe-rern für den „Kostenfaktor Software“ zu schärfen. Wich-tig ist beispielsweise, dass bereits bei der Projektplanung geprüft wird, wie viele neue Software-Varianten tatsäch-lich benötigt werden und wie sich der Aufwand für Vari-anten und Anpassungen bestehender Komponenten redu-zieren lässt.

Dazu ist es sinnvoll, Software-Kosten im Rahmen der „Total Cost of Ownership“ ganzheitlich zu betrachten. Das ist heutzutage allerdings häufig noch nicht der Fall. In einem Beispiel bei Elektrobit hätte der Austausch eines Mikrocontrollers zu einer Einsparung von etwa einem Euro pro Steuergerät geführt. In diesem Fall würde das bei geplanten acht Millionen Fahrzeugen zu einer erheb-lichen Kosteneinsparung führen. Andererseits erfordert der Austausch des Controllers aber auch eine Requalifi-zierung des Betriebssystems und dazugehörige kontinu-ierliche Integrationsarbeiten sowie Tests über die Projekt-laufzeit hinweg.

Für Anpassungen, Test und Integration kann sich das zu einem Projektteam von 30 Mitarbeitern über drei Jah-re summieren. Die so erforderliche Anpassung der Soft-ware verschlingt damit etwa zehn Millionen Euro. Dadurch würde der Einspareffekt in der Hardware ad absurdum geführt.

Gemeinsam die Komplexität reduzierenLetztlich bedeutet dies, dass die Industrie beim Ein-satz von Software umdenken muss: Es sollten nicht nur die Kosten von Bauteilen und mechanischen Kom-ponenten von Steuerungssystemen berücksichtigt werden, sondern auch die Aufwendungen für die Entwicklung und Anpassung der Software. Das heißt: Die Industrie muss eine neue Sichtweise für Software-Entwicklung erlangen und gemeinsam die Komple-xität und Vielfalt von Software aktiv reduzieren. Soft-ware-Unternehmen aus der IT-Industrie arbeiten aktiv daran, die Anzahl von gepflegten Produktversionen gering zu halten. Neue Funktionen werden nur in der letzten Software-Version entwickelt; für ältere Soft-ware-Versionen werden lediglich Bugfixes angeboten. Diese Software-Unternehmen versuchen auch die Abhängigkeit ihrer Software von Hardware oder Sys-temen zu isolieren, um Anpassungsaufwände mög-lichst gering zu halten.

Ein gemeinsames Umdenken ist unabdingbar. Denn die Komplexität der Software entwickelt sich zuneh-mend zu einem Problem für das gesamte Ökosystem Auto: Hersteller und Zulieferer sehen sich mit wach-senden Kosten durch die Implementierung und War-tung von Software konfrontiert. Dieser Trend ist ange-sichts des immer härteren Wettbewerbs im Automo-bilsektor nicht akzeptabel. (wi)� n

Zur höheren Komple-xität von Software im Automobilbereich tragen gleich mehre-re Faktoren bei: der wachsende Funktions-Umfang, die System- und Konfigurations-varianten sowie die Zahl der Marken und der individuellen Fahrzeugversionen für spezielle Märkte.

System-/Fahrzeug- Konfigurationsvarianten

Funktionen, z. B. Standard, mittel, hoch

Marken, Regionen



Und wieder ist es passiert: Ich hat-te mir so fest vorgenommen, im neuen Jahr regelmäßig Joggen zu

gehen, wenigstens zweimal die Woche, weil es meiner Fitness guttut. Zwei Mona-te sind inzwischen um, und wie häufig war ich draußen? Ganze drei Male. Das ist nicht mal ein Viertel der Mindest-Perfor-mance, die ich mir vorgenommen hatte.

Vielleicht kennen Sie das aus eigener Erfahrung, nicht nur beim Sport, sondern auch beim Rauchen aufhören, Abneh-men, Aufgaben erledigen und derglei-chen. Sie nehmen es sich fest vor, doch Sie tun es nicht. Im Kopf ist alles klar, Trainings-, Entwöhnungs- und Ernäh-rungspläne sind durchdacht und verstan-den, trotzdem passiert nichts. Warum? Weil das Herz nicht dabei ist und folglich der emotionale Antrieb fehlt. Mehr als Disziplin und Pflichtgefühl sind dann nicht zu erwarten – Freude macht das keine.

Sehr ähnlich ergeht es mir bei den der-zeitigen Ankündigungen in der Automo-bilindustrie. Dabei stehen „fundamenta-le Veränderungen“, die „nötigen Maß-nahmen“, der „fehlende Mut“, eine „intel-ligente Gesamtstrategie“, der „Fokus aufs Kerngeschäft“ und „Radikalumbau“ im Mittelpunkt. Wie geht es Ihnen damit? Wie klar ist Ihnen, wo es hingeht und wie emotionalisiert sind Sie dafür?

Andocken ans ErlebenEs scheint nach wie vor nicht in die Köpfe zu wollen, dass mit reinen Zahlen, Daten und Fakten, mit Management-Geschwur-bel oder „Rumturnen auf der Meta-Ebene“ kein Mensch hinterm Ofen hervorzuholen ist. Unser Hirn ist im konkreten Erleben unterwegs und filtert all das, was nicht daran andockt, gnadenlos weg. Da nutzen auch resolutes Auftreten und markige Sprüche nichts. Was hilft? Ein Blick in die Salutogenese, die drei einfache Kriterien

dafür benennt, dass Menschen sich als tat-kräftig und veränderungsbereit erleben:

• Sinnhaftigkeit: Ich sehe den Sinn hinter den Veränderungen, die auf mich zukom-men, und es lohnt sich, dass ich mich dafür einsetze.

• Verstehbarkeit: Ich kann Veränderun-gen, die auf mich zukommen, im spezifi-schen Kontext meines Erlebens nachvoll-ziehen und erklären.

• Handhabbarkeit: Ich habe die Ressour-cen, um Veränderungen, die auf mich zukommen, zu bewältigen, oder bekomme die passende Unterstützung dafür.In vielen Ankündigungen fehlen zwei oder alle drei Elemente. Kein Wunder, dass dann nichts vorangeht. Bei meinem Joggen lag es übrigens an der Sinnhaftigkeit: „Fitness“ hat nicht genug emotionalisiert. (av) ■

Keine Emotionen, keine Bewegung Dr. Lederers Management-Tipps

Karik

atur: H

einric

h Sch

warze

-Blan

ke

Management Frisch vom Lederer

Autor Dr. Dieter Lederer Unternehmensberater, Keynote-Speaker und Veränderungsexperte.

56_Lederer (av).indd 56 10.03.2020 12:34:54

Neue Produkte


Linux, Android und Adaptive Autosar kombinierenHochintegriertes FahrzeugcockpitGreen Hills Software und Tata Elxsi bieten gemeinsam eine softwarege-steuerte und hochintegrierte Cockpit-Lösung für Fahrzeuge an, die auf dem Echtzeit-Betriebssystem Integrity (RTOS) und der Integrity-Multivi-

sor-Virtualisierung läuft. Das eCockpit erfüllt die Anforderun-gen eines voll ausgestatteten Fahrzeugcockpits und unter-stützt Infotainment-, Kombi-instrument-, HUD- und ADAS-Funktionen über einen einzigen SoC-Baustein (System on Chip). Außerdem lässt es sich mit dem ASIL-zertifizierten Integrity RTOS und seiner sicheren Multi-

visor-Virtualisierungsarchitektur verbinden, um Anwendungen mit ge-mischter Kritikalität auf einem einzigen, Automotive-qualifizierten R-Car-H3-Prozessor von Renesas sicher zu betreiben.


Geringerer Helligkeitsverlust LED verbessert Sichtbarkeit Mit der Synios P2720 CR (Converted Red) hat Osram eine LED entwickelt, mit der sich Nebelschlussleuchten besonders kompakt designen lassen. Die LED mit Chip-Abmessungen von 0,5 mm2 beziehungsweise 1,0 mm2 ist in einem

kompakten 2,0 mm × 2,7 mm × 0,6 mm großen Gehäuse untergebracht. Ihre ge-ringe Größe führt zu einer Ersparniss beim Bauraum für Frontscheinwerfer und Heckbeleuchtung, was in umfang-reicheren Designmöglichkeiten für die Hersteller resultiert. Eines der zentralen Probleme von bisher oftmals verwende-ten monochromatischen LEDs für Nebel-

schlussleuchten ist ein hoher Verlust an Helligkeit (Degradation, etwa 50 Prozent) sobald eine Betriebstemperatur von +60 bis +70 °C erreicht ist. Die auf Konversion basierte Lösung der Synios P2720 CR soll den Helligkeitsver-lust auf rund 10 Prozent reduzieren. Der LED-Chip liefert 49 lm bei einer Stromaufnahme von 350 mA und der 1,0 mm2 Chip 103 lm bei 700 mA.


Im Infrarot-BereichLED-Serie für GesichtserkennungslösungenEverlight Electronics hat LED-Serien für drei Infrarot-Anwendungen für die intelligente Automatisierung von Automotive-Komponenten entwi-

ckelt. VS-FI3535 kann Augen und Gesichts-ausdruck des Fahrers wahrnehmen, um Blickfokus, Schläfrigkeit oder Ablenkung zu erkennen. VS-FI3535-D110-85/L2-W0940/TR8-AM (2,8 W, 3,5 mm × 3,5 mm × 1,6 mm) hat eine Wellenlänge von 940 nm und einen Abstrahlwinkel von 110° × 85°. Die temperaturbedingte Wellenlängenver-schiebung beträgt 0,07 nm/K, die Betriebs-

temperatur liegt bei -40 °C bis +105 °C. Diese AEC-Q102-qualifizierte LED-Serie mit kurzen Reaktionszeiten unterscheidet sich von normalen LEDs hinsichtlich ihrer Zielerfassung und Effizienz. Die Optosensoren der ALS-DPDIC17-Serie haben die Abmessung 2,0 mm × 2,0 mm × 0,63 mm, eine Auflösung von 16 Bit, einen Betriebsstrom von 160 mA und eine Sensor-Leuchtdichte von 0,0033 bis 83,000 Lux.


Framework für Automotive und EngineeringMessdatenmanagement-SystemMit Ipecloud MDM hat Ipetronik ein Matlab-basiertes Messdatenmanage-mentsystems (MDM) entwickelt. Dieses System bietet ein spezielles Frame-work für das Automotive- und Engineering-Messdatenmanagement und ist

darauf ausgelegt, Messdaten großer Flotten oder Prüfstände einer syste-matischen Ordnerstruktur, Datenver-arbeitung und -auswertung zu unter-ziehen. Die Datenverarbeitung erfolgt in erster Linie mit Matlab-Skripten. Da-bei können Entwickler ihre bestehen-den Matlab-Funktionen in die Platt-

form einbetten, was große Synergien bei der Erstellung der Auswerte-Rou-tinen schaffen kann. Das cloudbasierte und skalierbare Datenmanage-mentsystem ist hardwareunabhängig, besitzt eine große Bibliothek an Da-tentreibern und verarbeitet Messdaten von verschiedenen Mess- und Da-tenloggersystemen. Standardmäßig werden die importierten Daten in das TDMS-Format konvertiert; die Rohdaten bleiben zusätzlich erhalten.


Widerstandsbereich von 5 mΩ bis 220 mΩShunt-Widerstände mit 4 W NennleistungRohm kündigt mit der GMR50-Serie kompakte Shunt-Widerstände im 5,0 mm × 2,5 mm großen Gehäuse an. Die Bauelemente zeichnen sich durch eine hohe Nennleistung von 4 W (bei einer Elektrodentemperatur von 90 °C)

beziehungsweise 3 W (bei 100°C) und einen Widerstandsbereich von 5 mΩ bis 220 mΩ aus. Die GMR50-Serie ver-wendet eine Hochleistungsmetallle-gierung als Widerstandselement. Da-durch erreicht sie selbst im niederoh-migen Bereich einen hohen Tempera-turkoeffizienten (TCR), zum Beispiel 0 bis +25 ppm/°C für einen 5-mΩ-

Widerstand. Dies gestattet eine genaue Strommessung, die unempfindich gegenüber Schwankungen der Umgebungstemperatur ist und so die Zuver-lässigkeit der Anwendung erhöht. Die höhere Nennleistung ermöglicht Shunt-Widerstände, die in der 4-W-Klasse um eine Baugröße kleiner ausfal-len. Ihre Widerstandstoleranz ist mit F (±1 Prozent) spezifiziert.


Doppelte Bandbreite: Bis zu 490 MHzLidar-ICs für schnellere selbstfahrende AutosMaxim bietet kleine Lidar-ICs mit einer Bandbreite von bis zu 490 MHz und 2,1 pA/√Hz eingangsbezogener Rauschdichte an, um eine genauere Ab-standsmessung bei Lidar-Anwendungen zu unterstützen. Der Hochge-

schwindigkeitskomparator MAX40026 und die Transimpe-danzverstärker MAX40660/MAX40661 ermöglichen mit ihrer hohen Bandbreite eine um 15 km/h schnellere auto-nome Fahrt bei Autobahnge-schwindigkeiten, indem sie in einem Lidar-Modul bei gleich-

bleibender Modulgröße eine mehr als doppelt so hohe Bandbreite und 32 zusätzliche Kanäle (128 statt bisher 96) bereitstellen. Durch die Fähigkeit, 33 Prozent mehr Kanäle innerhalb derselben Lidar-Modulgröße im Vergleich zu anderen Bauelementen unterzubringen, liefern MAX40660/MAX40661 den Entwicklern von optischen Empfängern höher aufgelöste Bilder.


Bild:

Osram

Bild:

Gree

n Hills

Softw

are

Bild:

Everl

ight

Bild:

Rohm

Bild:

Ipetr

onik

Bild:

Max

im

57_PBs.indd 57 10.03.2020 12:36:06

Impressum/Verzeichnisse


dSPACE 7ETAS 4.USGentex 13Melexis 33

NOFFZ 31PEAK-System 27Rohde & Schwarz 47Rutronik 25

Secunet 21Softing 5Stäubli Tec-Systems 9Süddeutscher Verlag 2.US, Beilage

Synopsys 11Vitesco 41

Büttner, Dr. Klaus 12Clemmer, Rick 12Fischer, Hans-Peter 26Hamann, Jan 38Hennell, Ian 10Hughes, Cameron 44Janouch, Stephan 22

Kouba, Stefan 48Kraus, Robert 9, 13Kusch, Christopher 26Lederer, Dr. Dieter 56Löbel, Holger 34Lutz, Rainer 10Metzker, Eduard 18

Minzlaff, Moritz 26Muszynski, Christian 32Nakakuki, Kenji 30Nels, Timo 38Neumann, Roland 13Nindl, Thomas 6Pickhard, Friedhelm 14

Schleicher, Martin 52Siegert, Maren 34Sievers, Kurt 12Steiner, Peter 8Wlasak, Andreas 42

Amazon 52Analog Devices 12Apple 52ASAP 38Audi 8, 44Autotalks 12Baselabs 34BMW 44Bosch 9, 30Brusa Elektronik 6CATL 11Cemm Thomme 9Daimler 12, 52Dataspeed 12Denso 12DFEV 12dSPACE 12Dynamic Map Planning 30

Elektrobit 52Elmos 9Escrypt 13, 14, 26ETAS 14European Lithium 11Everlight Electronics 57Faurecia 42Geo++ 30Glencore 11Global Logic 12Google 52Greenerity 12Green Hills Software 22, 57Human Fab 42Human Horizons 9IAA 12IBM 32Infineon 8, 10

Infinity Lithum 11Inova Semiconductors 9, 13Instrument Systems 44Ipetronik 57Iseled-Allianz 9Jungo 12Karamba Security 8KPMG 26LDRA 10Maxim 57McKinsey 52Microchip 48Microsoft 42Mitsubishi Electric 30Mobica 12National Instruments 14NTT 13NXP 10, 12

Open Synergy 12Osram 57Porsche 44QNX 14Renesas 57Rohm 57RWTH Aachen 12Sapcorda Services 30Tata Elxsi 57U-Blox 30Universität Paderborn 12Vector Cybersecurity Solutions 18Vector Informatik 18Vitesco Technologies 8Volkswagen 12, 44, 52Winbond 8ZKW Group 12ZVEI 6

Unternehmen

Inserenten

Personen

Impressum

REDAKTION

Chefredaktion: Dipl.-Ing. Alfred Vollmer (av) (v.i.S.d.P.) Tel: +49 (0) 8191 125-206, E-Mail: [email protected]

Redaktion: Dr.-Ing. Nicole Ahner (na) Tel: +49 (0) 8191 125-494, E-Mail: [email protected]. Hans Jaschinski (jj) Tel: +49 (0) 8191 125-830, E-Mail: [email protected]. Peter Wintermayr (wi)Tel: +49 (0)8191 125-135, E-Mail: [email protected]. Gunnar Knüpffer (gk) Tel: +49 (0) 8191 125-145, E-Mail: [email protected] Probst (prm) Tel: +49 (0) 8191 125-214, E-Mail: [email protected]é Oliver Klein (aok), Volontär Tel: +49 (0) 8191 125-403, E-Mail: [email protected] Mitarbeiter: Jens Wallmann (jwa)

Office Manager und Sonderdruckservice: Waltraud Müller, Tel: +49 (0) 8191 125-408, E-Mail: [email protected]

ANZEIGEN

Anzeigenleitung: Frank Henning, Tel: +49 (0) 6221 489-363, E-Mail: [email protected]

Anzeigendisposition: Angelika Scheffler, Tel: +49 (0) 6221 489-392, E-Mail: [email protected]

Zur Zeit gilt die Anzeigenpreisliste Nr. 18 vom 01.10.2019

VERTRIEB

Vertriebsleitung: Hermann WeixlerAbonnement: http://www.automobil-elektronik.de/abo/ Inland € 98,00 (zzgl. € 8,00 Euro Versandkosten + Mwst. = € 113,42) Ausland € 98,00 ( zzgl. € 16,00 Versandkosten + Mwst. = € 121,98)

Einzelverkaufspreis € 20,00 ( inkl. Mwst. + zzgl. Versand) Der Studentenrabatt beträgt 35 %. Alle Preise verstehen sich inkl. MwSt.

Kündigungsfrist: Jederzeit mit einer Frist von 4 Wochen zum Monatsende.

Abonnement und Leser-Service: Hüthig GmbH, Leserservice, 86894 Landsberg Tel: +49 (0) 8191 125-777, Fax: +49 (0) 8191 125-799 E-Mail: [email protected]

Erscheinungsweise: 6 × jährlich

VERLAG

Hüthig GmbH, Im Weiher 10, 69121 Heidelberg www.huethig.de, Amtsgericht Mannheim HRB 703044

Geschäftsführung: Fabian Müller

Leiter digitale Produkte: Daniel Markmann

Leitung Zentrale Herstellung: Hermann Weixler

Herstellung: Herbert Schiffers

Art Director: Jürgen Claus

Layout und Druckvorstufe: Cornelia Roth, Susanne Brenneis

Druck: Qubus media GmbH, 30457 Hannover

© Copyright Hüthig GmbH 2020, Heidelberg.

Eine Haftung für die Richtigkeit der Veröffentlichung kann trotz sorgfälti-ger Prüfung durch die Redaktion, vom Ver leger und Herausgeber nicht übernommen werden. Die Zeitschriften, alle in ihr enthaltenen Beiträge und Abbildungen, sind urheberrechtlich geschützt. Jede Verwertung au-ßerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustim-mung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspei-cherung und Bearbeitung in elektronischen Systemen.

Mit der Annahme des Manuskripts und seiner Veröffent lichung in dieser Zeitschrift geht das umfassende, ausschließliche, räumlich, zeitlich und inhaltlich unbeschränkte Nutzungsrecht auf den Verlag über. Dies umfasst insbesondere das Printmediarecht zur Veröffentlichung in Printmedien aller Art sowie entsprechender Vervielfältigung und Verbreitung, das Recht zur Bearbeitung, Umgestaltung und Übersetzung, das Recht zur Nutzung für eigene Werbezwecke, das Recht zur elektronischen/digitalen Verwer-

tung, z. B. Einspeicherung und Bearbeitung in elektronischen Systemen, zur Veröffentlichung in Datennetzen sowie Datenträger jedweder Art, wie z. B. die Darstellung im Rahmen von Internet- und Online-Dienstleistun-gen, CD-ROM, CD und DVD und der Datenbanknutzung und das Recht, die vorgenannten Nutzungsrechte auf Dritte zu übertragen, d. h. Nachdruck-rechte einzuräumen. Die Wiedergabe von Gebrauchsnamen, Handelsna-men, Warenbezeichnungen und dergleichen in dieser Zeitschrift berechtigt auch ohne besondere Kennzeichnung nicht zur Annahme, dass solche Namen im Sinne des Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Für unverlangt eingesandte Manuskripte wird keine Haftung übernommen. Mit Namen oder Zeichen des Verfassers gekennzeichnete Beiträge stellen nicht unbedingt die Meinung der Redaktion dar. Es gelten die allgemeinen Geschäftsbedingungen für Autorenbeiträge.

AUSLANDSVERTRETUNGEN

Schweiz, Liechtenstein: Katja Hammelbeck, interpress gmbh Ermatinger Straße 14, CH-8268 Salenstein, Tel: +41 (0) 71 552 02 12, Fax: +41 (0) 71 552 02 10, E-Mail: [email protected]

USA, Kanada, Großbritannien, Österreich: Marion Taylor-Hauser, Max-Böhm-Ring 3, 95488 Eckersdorf, Tel: +49 (0) 921 316 63, Fax: +49 (0) 921 328 75, E-Mail: [email protected]

Angeschlossen der Informationsgemeinschaft zur Feststellung der Verbreitung von Werbeträgern (IVW), (Printed in Germany)

DATENSCHUTZ

Ihre Angaben werden von uns für die Vertragsabwicklung und für interne Marktforschung gespeichert, verarbeitet und genutzt und um von uns und per Post von unseren Kooperationspartnern über Produkte und Dienstleistungen informiert zu werden. Wenn Sie dies nicht mehr wünschen, können Sie dem jederzeit mit Wirkung für die Zukunft unter [email protected] widersprechen. Ausführliches zum Datenschutz und den Informationspflichten finden Sie unter www.huethig.de/datenschutz

www.automobil-elektronik.dewww.all-electronics.deISSN 0939-532618. Jahrgang 2020

IHRE KONTAKTE: Abonnement- und Leser-Service: Tel: +49 (0) 8191 125-777, Fax: +49 (0) 8191 125-799 E-Mail: [email protected] Redaktion: Tel: +49 (0) 8191 125-206, Fax: -141 Anzeigen: Tel: +49 (0) 6221 489-363, Fax: -482

58_Verzeichnisse.indd 58 12.03.2020 08:22:34

E/E-Entwickler, Ingenieure, Manager. AUTOMOBIL-ELEKTRONIK hat die gesamte Wertschöpfungs kette im Fokus – von der Entwicklung bis zum fertigen System. Jetzt kostenlos testen: www.automobil-elektronik.de/kostenlos

Hüthig GmbHIm Weiher 10D-69121 Heidelberg

Tel. +49 (0) 6221 489-232Fax +49 (0) 6221 489-482www.huethig.de

ael_testabo_210x297.indd 1 15.07.2019 09:41:3759_U3.indd 3 10.03.2020 12:36:49

Automotive Cybersecurityneu durchdenken!Cybersecurity wird Voraussetzung für die Typgenehmigung.

UNECE WP.29 & ISO/SAE 21434 - Jetzt aktiv werden!

Mit der neuen UNECE WP.29-Regulierung und der ISO/SAE 21434 wird die Cybersicherheit von Fahrzeugen schon bald Bedingung für die Typgenehmigung.

Mit PROOF, dem Product Security Organization Framework, unterstützt ESCRYPT Sie bei der e� zienten Umsetzung kün fti-ger Cybersicherheits-Anforderungen. ESCRYPT kooperiert dabei mit KPMG.

www.escrypt.com www.kpmg.de Jetzt Whitepaper lesen!

In Kooperation mit

60_U4.indd 4 10.03.2020 09:57:08

code safe, secure und testbar machen · märz 2020 4 automobil elektronik 03/2020 mÄrkte +...

Documents