Richter sprechen fehlerhafte Urteile, Ärzte stellen falsche Diagnosen und natürlich machen auch Ingenieure und Informatiker Fehler. Kein Hersteller von Software und Hardware für automatisierte Fahrzeuge kann trotz umfassender Testverfahren hundertprozentige Fehlerfreiheit garantieren. Ein Restrisiko bleibt, sodass es zu Unfällen mit automatisierten Fahrzeugen kommen wird. Die entscheidende Frage ist: Wie gehen wir damit um? Wir akzeptieren in gewissen Grenzen, dass der Autofahrer Fehler macht. Warum also darf die Maschine keinen Fehler machen? Dies ist umso spannender, weil wir davon ausgehen (was aber noch nicht belegt ist), dass ein automatisiertes Fahrzeug das Potenzial hat, die Zahl der Unfälle (und Verkehrstoten) drastisch zu senken. Aber kann man das Leben eines Einzelnen, der durch einen technischen Fehler gestorben ist, mit hunderten nicht getöteter Verkehrsteilnehmer rechtfertigen? Soll das autonome Fahrzeug bei einer unvermeidbaren Kollision (Dilemmaentscheidung) die Insassen oder die anderen Verkehrsteilnehmer schützen? Geht der Schutz von Kindern vor den Schutz von Erwachsenen? Wie kann die Umweltbelastung durch zusätzliche Staus verhindert werden, weil z. B. der Individualverkehr zunimmt oder weil das Fahren auch ohne Führerschein möglich wird? Das (hoch)automatisierte Fahren beinhaltet also viele rechtliche und gesellschaftliche Fragestellungen, die durch Technik allein nicht gelöst werden können und wenige davon wurden bis heute wirklich diskutiert. Hersteller und Zulieferer brauchen aber Rechtssicherheit. Vor allem hinsichtlich der offenen Fragen wie Zulassung, wiederkehrende Betriebsprüfung solcher Fahrzeuge, der Haftung und der Strafverfolgung bei Unfällen, aber auch der Überwachung selbstlernender Software.

Im Juni 2020 wurde zwar auf Ebene der UN-Wirtschaftskommission für Europa (UN/ECE) eine Regelung für automatisierte Spurhaltesysteme verabschiedet, aber globale Bestimmungen für das vollständig autonome Fahren ab SAE-Level-4 sind noch nicht in Kraft. Diese Regulierungslücke will nun Deutschland nutzen, um zunächst auf nationaler Ebene voranzuschreiten. Konkret werden in dem deutschen Regelungsentwurf die Funktionsweise, Testverfahren und Genehmigung von autonomen Fahrfunktionen berücksichtigt. Wie schwierig eine Regulierung sein kann, zeigt sich schon allein an der Beantwortung der Frage „Wie sicher sollte ein autonomes Fahrzeug sein?“ Einig sind sich die Experten, dass das Fahrzeug sicherer sein sollte als ein menschlicher Fahrer. Doch bei der Definition, mit welcher Art von Fahrer das autonome Fahrzeug verglichen werden sollte, herrscht Uneinigkeit. Soll es ein durchschnittlicher menschlicher Fahrer sein – der oft abgelenkt ist und relativ schneller ermüdet? Oder ein Berufskraftfahrer, der mehr Risiken eingeht?

Die Berufung auf Ethik und Menschenwürde beim autonomen Fahren stellt zudem eine spezifisch deutsche Herangehensweise dar. In der angelsächsischen Rechtssprechung ist dies weniger stark ausgeprägt. Deshalb dürfte der Weg hin zu einer internationalen Regelung sowie ein globaler Konsens zum gesellschaftlichen Umgang mit Dilemma-Entscheidungen noch sehr steinig werden.

Editorial - Hauptartikel

Zeiteinsparung dank steckerloser Kontaktierungstechnik

Das patentierte TDC-System (Thermo-Direct-Connect) erlaubt erstmals die  steckerlose Kontaktierung zwischen Messstelle und Modul. Das Sensorkabel wird einfach in das Modul gesteckt. Kontaktierung und Verriegelung des Kabels  erfolgt automatisch beim Stecken. Das spart wertvolle Zeit bei der Aufrüstung von Messstellen und Sensoren und ermöglicht so noch effizientere Arbeitsabläufe.

Das patentierte TDC-System (Thermo-Direct-Connect) erlaubt erstmals die steckerlose Kontaktierung zwischen Messstelle und Modul. Das Sensorkabel wird einfach in das Modul gesteckt.

Die maßgeblichen Faktoren bei vielkanaligen Thermo-Messstellen sind Rüstzeit und Fehlersicherheit der Messstellen. Doch nicht nur effizient, schnell und fehlerlos sollte die Aufrüstung der Thermosensoren sein – allen voran sollte sie auch unkompliziert sein. Aktuell müssen Standard-Thermoleitungen zeitintensiv über Schraubklemmen im Thermostecker aufgelegt werden, wo eine Verpolung nicht ausgeschlossen werden kann. Mit dem Thermomodul M-TDC 8 und dem passenden Thermokabel von Ipetronik steht erstmals ein System zur steckerlosen Montage von Thermomodul und Thermoleitung zur Verfügung. Die Rüstzeit wird um Faktor 10 reduziert, eine Verpolung der Thermokabel ist durch den asymmetrischen Leitungsquerschnitt ausgeschlossen. Das TDC Thermokabel (sog. „TDC-IN Kabel“) wird einfach in das Gerät geschoben, spezielle Nadeladapter kontaktieren automatisch, der Verriegelungsmechanismus stellt eine sichere Verbindung her, die ein unbeabsichtigtes Lösen verhindert. Die zeitintensive und fehleranfällige Verbindung des Thermokabels mit dem Thermoelement-Steckverbinder entfällt komplett – der Messtechniker spart so wertvolle Zeit pro Thermomessstelle.

Das TDC Thermokabel kann als „Rohkabel“ auf der Rolle in vordefinierten Längen bezogen werden, um eigene Thermoelement-Fühler oder Verlängerungsleitungen konfektionieren zu können. Darüber hinaus ist das Kabel auch als vorkonfektionierter Thermoleitung mit Mantelthermoelementen verfügbar. Das TDC Thermokabel muss lediglich auf die benötige Länge gekürzt und auf das System aufgesteckt werden. Für die bei Entwicklungsunternehmen und OEMs vorkonfektionierten und in großen Stückzahlen vorhandenen Thermo-sensoren stehen entsprechende TDC-Adapter zur Verfügung, um auch mit bereits vorhandenen Sensoren die Vorteile der TDC-Technik nutzen zu können. Hierbei wird über eine/n TDC Thermoelement-Buchse / -Stecker auf das TDC-Kabel adaptiert (siehe Bild 1).

<ul><li>(1)  Zunächst wird das widerstandsfähige und mechanisch stark belastbare TDC Thermokabel mit dem speziell dafür entwickelten TDC Schneidewerkzeug auf die benötigte Länge gekürzt.</li><li> (2) Wichtig: Das Kabel muss vor dem Einstecken in das Modul bis zum Anschlag in die birnenförmige Öffnung des Schneidewerkzeugs eingeführt werden. Nur so kann ein rechtwinkliger Schnitt vorgenommen werden. Dieser Schnitt muss auf beiden Seiten des Kabels durchgeführt werden.</li><li> (3) Nun wird das erste Kabelende in das M-TDC 8 Modul eingeführt. Die schwarze Rückenlinie befindet sich oben. Die Kontaktierung und Verriegelung erfolgen automatisch und werden über verbaute LEDs signalisiert.</li><li> (4) Anschließend wird das zweite Kabelende in die TDC Buchse / den TDC Stecker gesteckt. Ähnlich dem M-TDC 8 Modul wird die TDC Sensorleitung über Federkontakte verbunden und mittels Widerhakensystem automatisch verriegelt.</li><li>(5) Im folgenden Schritt wird die TDC Buchse / der TDC Stecker mit der / dem bestehenden Miniatur-Thermoelement-Buchse / -Stecker des Standard-Thermosensors bzw. der Thermoverlängerungsleitung verbunden.</li><li>(6) Zur Kabel-Entnahme aus dem Modul wird der Hebel nach links gedrückt und das Kabel anschließend aus dem Gerät gezogen. Für eine erneute Sensor-Kontaktierung muss das Kabel nochmals rechtwinklig abgeschnitten werden.</li></ul>

Doch was macht das TDC Thermokabel so besonders? Mit der neuen Methodik der Nadelkontaktierung wurde der Leitungsquerschnitt des Kabels überarbeitet: Dieser ist asymmetrisch gestaltet, um einen verpolungssicheren Sensoranschluss gewährleisten zu können. Dadurch wird sichergestellt, dass die Thermoleitung stets mit der richtigen Polung in das Modul eingeführt wird. Zudem ist dieses mit einem auf Teflon-basierenden Mantel- und Isolationswerkstoff versehen. Dieses Material ist mechanisch belastbar und besitzt sowohl enorme Widerstandskraft gegen aggressive Medien als auch gute elektrische Isolationseigenschaften. Es ist besonders hitze- und kältebeständig und kann in einem Temperaturbereich von –190 °C bis +260 °C eingesetzt werden.

Temperaturmessstellen lassen sich außerdem ganz einfach aus dem TDC Thermokabel herstellen, indem man ein Ende in das Modul steckt und auf das andere Ende eine Messpille aufschweißt. Dank des händischen Zuschnitts von der Rolle hat man eine individuelle Ablängung und es fällt kein überschüssiges Kabel an, sodass die Applizierung von Temperaturmessstellen schnell und einfach möglich ist.

Darüber hinaus ist das TDC Thermokabel so konzipiert, dass sich auch herkömmliche Sensoren mit konventionellen Miniatur-Thermoelement-Steckern an das M-TDC 8 Thermomodul anschließen lassen – dank dem speziell hierfür entwickelten TDC Stecker und der TDC Buchse (Bild 2). Jene Buchse bildet das Bindestück zwischen dem herkömmlichen Thermostecker und dem TDC Thermokabel. Umgekehrt kann das Stecker-Buchsen-System auch verwendet werden, wenn Messgeräte oder Fühler anderer Hersteller vorhanden sind. Durch diese Kompatibilität zu den Bestandssystemen erlaubt das TDC-System volle Flexibilität und bietet einen Investschutz für die bestehende Sensorik und Messtechnik (Bild 3). Das TDC-System bietet folgende Vorteile:

<ul><li>enorme Zeitersparnis durch direkte Kabelkontaktierung</li><li>fehlerfreie Messergebnisse durch verpolungssichere Kontaktierung</li><li>hohe Flexibilität dank Kompatibilität zu Bestandssystemen über TDC Buchsen und TDC Stecker</li><li>sichere elektrische Verbindung dank hoher Verriegelungskräfte (Zugentlastung)</li><li>hohe Schock- und Temperaturresistenz zur sicheren Anwendung in rauen Umgebungen</li><li>reduzierte Lagerhaltungskosten von Thermoleitungen</li></ul>

Als führender Hersteller von Logistiksystemen und Flurförderfahrzeugen hat Jungheinrich schon vor zehn Jahren die Elektrifizierung der Fahrzeuge auf Basis von Lithium-Ionen-Technologie eingeleitet. Demzufolge muss bei Flurförderfahrzeugen mit dieser innovativen Antriebs- und Batterietechnik bereits während der Entwicklung gewährleistet sein, dass die Messtechnik unkompliziert, hochpräzise und sicher ist. Da die Gabelstapler jedoch nur spärlich Platz bieten, sollte die Technik außerdem klein und flexibel sein – so kann sie sich kleinsten Platzverhältnissen anpassen. Mit dem Mess- und Datenlogger-System von Ipetronik, bestehend aus Temperaturmessmodul M-TDC 8 (plus Equipment: TDC Thermokabel, TDC Stecker / Buchsen) und passendem Datenlogger IPEhub2, setzt Jungheinrich ein System ein, das durch seine kleine Bauform und die direkte Sensor-Kontaktierung alle Anforderungen erfüllt. Komplettiert wird das System durch die Software IPEmotion zur Messdatenerfassung und die dazugehörige Android App zur Online-Visualisierung. Hergestellt werden die applizierten Temperaturmessstellen an den Gehäusen von Leistungselektronik, Motor- und Antriebssystemen, Pumpen sowie Hydrauliköltank aus dem TDC Thermokabel: auf das eine Endstück wird eine Messpille aufgeschweißt, während das zweite Ende zur Kontaktierung in das Modul gesteckt wird. Dort baut es eine sichere elektrische Verbindung auf. Durch den händischen Zuschnitt von der Rolle fällt kein überschüssiges Kabel an, sodass durch Flexibilität der Leitungsführung und individuelle Ablängung eine Applizierung auf engstem Raum einfach und schnell möglich ist. Durch das Stecker-Buchsen-System plant Jungheinrich die Einführung des TDC Thermokabels als Standard im Prüffeld, da die volle Kompatibilität zu bestehenden Messsystemen und Sensoren gegeben ist. (oe)

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

Bild 1: Kurzbeschreibung Anschluss TDC Thermokabel an Modul & TDC Buchse.

Bild 2: Detail des TDC-IN Kabel in Thermomodul M-TDC 8.

Bild 3: Flexibilität und Kompatibilität mit dem TDC Stecker-Buchsen-System.

Hauptartikel

Nach Unterlagen der Ipetronik GmbH & Co. KG, 76532 Baden-Baden.

Messtechnik, Testlösungen, Diagnose

Elektronik

Automotive

Angesichts immer neuer Angriffstechniken, benötigen Fahrzeugflotten künftig eine fortwährende Überwachung und Absicherung. Dies begründet sich vor allem durch das neue UN-Regelwerk zu Cybersicherheit und Software-Updates. Entscheidend dabei: Das Zusammenwirken zwischen Angriffserkennung im Fahrzeug und SIEM, Threat Intelligence und Security-Analysten im Vehicle Security Operations Center.

Angesichts immer neuer Angriffstechniken, benötigen Fahrzeugflotten künftig eine fortwährende Überwachung und Absicherung. Dies begründet sich vor allem durch das neue UN-Regelwerk zu Cybersicherheit und Software-Updates.

Egal wie hoch das Schutzlevel vor Cyberangriffen, das bei der Entwicklung geschaffen wurde, auch ist, es wird über die Lebensdauer des Fahrzeugs hinweg zwangsläufig erodieren. Neue Sicherheitslücken werden entdeckt und ausgenutzt, neue Angriffsmethoden und -werkzeuge entwickelt, über die Zeit lassen sich einzelne Schwachstellen womöglich zu einer Kill Chain vervollständigen.

In Zeiten vernetzter Mobilität trifft das Problem OEMs, Flottenbetreiber und Managed Service Provider (MSP) gleichermaßen. Umso mehr als Angriffe – ganz gleich, ob nur versucht oder erfolgreich – häufig unentdeckt bleiben. Denn von gängiger Onboard-Diagnosetechnik werden Cyberangriffe nicht erfasst. Die Analyse und Reproduktion etwaiger Attacken ist daher schwierig und teuer, eine zeitnahe Reaktion kaum möglich. Was bleibt ist der Schaden: Negative Folgen für Fahrzeug, Fahrzeugnutzer und andere Verkehrsteilnehmer sowie Reputationsverlust und Folgekosten für OEMs, Flottenbetreiber und MSPs.

Fortlaufende Überwachung der Fahrzeugflotte

Genauso wie heute IT-Systeme im Unternehmen einer fortlaufenden Überwachung hinsichtlich verdächtiger Vorgänge und möglicher Cyberangriffe unterzogen werden, benötigen daher künftig auch Fahrzeug und Fahrzeugflotten ein aktives, fortwährendes Security Monitoring. Dabei geht es zum einen um die Überwachung bekannter Risiken, etwa indem die Ausnutzung bereits bekannter Angriffsvektoren kontinuierlich beobachtet wird. Zum anderen zielt ein solches Security Monitoring auf die Identifikation neuer Risiken. Es erkennt, welchen Angriffen die Fahrzeuge im Feld ausgesetzt sind und welche neuen Methoden Angreifer ausprobieren, so dass bereits frühzeitig – noch bevor die Angreifer ihre Attacken skalieren – Gegenmaßnahmen eingeleitet werden können.

Ziel einer solchen permanenten Überwachung ist es, das Security Level des Fahrzeugs fortlaufend und anforderungsgerecht nachzubessern. Das ganzheitliches Vehicle Security Operations Center (V-SOC) von Escrypt folgt hierbei dem klassischen Zyklus aus Monitoring, Angriffserkennung, Analyse und Response. Es muss demnach nicht nur den Datenverkehr im, zum und vom Fahrzeug überwachen, sondern auch gleichzeitig Anomalien und mögliche Security Events herausfiltern und melden. Und es benötigt ein Security-Backend, dass diese Auffälligkeiten qualifiziert aus- und bewertet und von dem aus die zur Aufrechterhaltung oder Wiederherstellung des Schutzniveaus nötigen Software-Patches entwickelt und per Software-Update Over-the-Air (SOTA) auf die Flotte ausgerollt werden (Bild 1).

Beobachtung des Gesamtsystems gemäß UNECE-Regularien

Dabei ist ein solcher Regelkreis zur Absicherung der Fahrzeugflotte keineswegs fakultativ. Spätestens mit Inkrafttreten der Regularien der <a href="http://UNECE.WP">UNECE.WP</a>29, die jüngst von rund 60 Ländern angenommen wurden, wird der Nachweis einer angemessenen Risikobehandlung sowie eines Security Monitorings über den gesamten Fahrzeuglebenszyklus hinweg zur verpflichtenden Voraussetzung für die Typgenehmigung. Einzelne Security-Funktionen im Fahrzeug werden dafür nicht ausreichen, sondern der kontinuierliche Schutz der Fahrzeuge bis zum Phase-out – zwingend bestehend aus Detection und Response – muss organisatorisch, prozessual und technisch unterfüttert und verbürgt sein.

Um ein aussagekräftiges Bild der Gesamtbedrohungslage zu erhalten, ist es nicht sinnvoll, das Beobachtungsfeld lediglich auf die Flotte oder auf das Backend einzuengen. Vielmehr braucht es mehrere Blickfelder und Handlungsebenen gleichzeitig: Ein Monitoring im Fahrzeug in Form eines Intrusion Detection System (IDS), das Angriffe und Manipulationen dort aufspürt, wo sie sich unmittelbar zeigen und wirksam werden, und ein Security Monitoring für das (OEM-)Backend. Sowie überdies ein Security Operations Center (SOC), in dem das Angriffsgeschehen aggregiert und ausgewertet wird, und das eine Skalierung von Angriffen über die ganze Flotte hinweg unterbindet.

Das Intrusion Detection System ist demnach von entscheidender Bedeutung für die Effektivität des Security-Monitorings insgesamt. Die Qualität und Zuverlässigkeit der Angriffserkennung im Fahrzeug misst sich dabei an zwei Fragen: Wo im Fahrzeug werden Intrusion-Detection-Systeme (IDS) eingesetzt? Und was genau beobachten diese?

Aktuell geht der Trend dahin, den fahrzeuginternen Datenverkehr (Ethernet, CAN) beobachten zu lassen und zusätzlich IDS in den am meisten exponierten ECUs (Connectivity ECUs) zu platzieren. Ziel der Intrusion Detection ist dabei insbesondere, Angriffe von außen (per Remote Connectivity) frühzeitig zu entdecken, die Manipulation fahrrelevanter Systeme (z. B. Lenksystem, Motorsteuerung) zu erkennen oder auch Manipulationsversuche über leicht zugängliche Schnittstellen (wie z. B. die Diagnoseschnittstelle) zu erkennen.

<ul><li>Ein Netzwerk-basiertes IDS für den CAN-Bus überwacht den CAN-Traffic bspw. von einem zentralen Gateway aus und analysiert ihn nach regelbasiertem Vorgehen. Die Intrusion Detection erkennt dabei typische CAN-Angriffe, etwa Angriffen auf Diagnoseprotokolle wie UDS oder die Manipulation von CAN-Signalen (Signatur basierter Ansatz) und Anomalien welche auf neue (bisher nicht klassifizierte Angriffe) hindeuten (Heuristischer Ansatz).</li><li>Ein Host-based IDS auf der Connectivity ECU überwacht beispielsweise die Integrität des Betriebssystems und der Anwendungen. Das Intrusion-Detection-System erkennt dabei Veränderungen von System- und Anwendungsdateien und scannt die aus- und eingehenden Netzwerkverbindungen.</li><li>Durch eine Kombination von Host-basierten IDS und netzwerk-basierten IDS entstehen hybride / verteilte IDS, die die Abdeckung der Angriffsfläche im Fahrzeug erhöhen und umfassende Information über das Vorgehen von Angreifern sammeln. Neue AUTOSAR-Module wie der IDS Manager (idsM) ermöglichen die Verteilung, Weiterleitung und Sammlung von Security Events im Fahrzeugnetzwerk bis zur Übergabe an das Backend in einer Connectivity ECU.</li></ul>

Darüber hinaus erbringt das IDS im Fahrzeug einen weiteren entscheidenden Vorteil: Es reduziert den Bandbreitenbedarf für die Übertragung der Security Monitoring-Informationen erheblich. Denn im Gegensatz zum Security Monitoring in der Enterprise-IT, das sich auf breitbandige Netzwerkanbindung stützt und so z. T. den kompletten Netzwerkverkehr mitschneiden und die gesamten Logs der einzelnen Systeme übertragen kann, verfügt die Fahrzeugflotte nur über eine Anbindung mit geringer Bandbreite. Das IDS wirkt hier wie ein Filter – statt des gesamten Datenverkehrs und großer Logs reportet es nur die entdeckten Anomalien an das Backend. Die Menge der zu übertragenden Daten wird dadurch drastisch reduziert.

Security Incident und Event Management (SIEM)

Zentrale Herausforderung bei der Sicherung der Flotte ist es, bislang unbekannte Angriffe frühzeitig zu erkennen. Ein zentrales Werkzeug dabei ist das Security Incident und Event Management (SIEM). Es sammelt – über einen definierten Zeitraum hinweg – alle IT-Sicherheitsereignisse, die die Security-Sensoren im Backend und in den Fahrzeugen melden.

SIEM-Lösungen bringen eine Reihe nützlicher Funktionen mit: Sie werten Logdateien unterschiedlicher Serverprodukte (Firewalls, Proxys, VPN-Appliances, Server und andere Security-kritische Komponenten) aus und bedienen sich dabei der marktüblichen Logformate. Sie sammeln die Logdaten, und unterstützen die Retention alter, nicht mehr benötigter Daten. Zudem hilft das SIEM bei der Analyse der gesammelten Log-Dateien, indem es diese durchsucht, darstellt und mitunter sogar ermöglicht, mittels Machine-Learning-Funktionalitäten eigene Modelle zu entwickeln. Und nicht zuletzt veranschaulichen SIEMs mittels Dashboards die Risikolage und sind vielfach sogar mit Vulnerability-Management-Lösungen kombinierbar.

SIEM: Gut bei bekannten, weniger gut bei unbekannten Angriffen

Um automatisiert bekannte Angriffe zu erkennen, sind SIEMs daher bestens geeignet, zumal sie sich häufig an Use Cases orientieren. Das SIEM sucht nach bestimmten vorher definierten Angriffsmustern und durchkämmt seine Datenbasis nach entsprechenden Symptomen. Auf diese Weise identifiziert das System bekannte Angriffe präzise und zuverlässig, wertet sie aus und macht sie bspw. über ein Dashboard sichtbar und löst im Idealfall sogar automatisch die geeignete Incident Response aus.

Jedoch ist eine SIEM-Lösung weniger geeignet, um bis dato unbekannte Angriffsszenarien zu erkennen. Denn neue Muster, die noch nicht als Angriffe bewertet wurden, können vom System auch nicht als solche erfasst werden. In der Enterprise-IT kann das SIEM auf umfangreiches Wissen über Angriffspfade zurückgreifen und die hochgradig standardisierte Enterprise-IT-Landschaft ermöglicht ein automatisches, extern zukaufbares Vulnerability-Management. Für das vernetzte Fahrzeug allerdings ist die Ausgangsituation eine andere: Viele seiner Komponenten sind dediziert für die Fahrzeugplattform entwickelt und angepasst worden, und es gibt kein standardisiert anwendbares oder zukaufbares Vulnerability-Management für diese Komponenten. Alle Erkenntnisse über neue Bedrohungen können also nur aus der Beobachtung der Flotte gewonnen werden, und auch Gegenmaßnahmen müssen zumeist passgenau entwickelt werden.

Ein Denken in Use-Cases greift hier also zu kurz. Vielmehr benötigt die vernetzte Fahrzeugflotte neben dem technischen Betrieb einer SIEM-Lösung noch einen fachlich-inhaltlichen Betrieb – das Vehicle Security Operations Center (Bild 2). Ein solches Security Operations Center fügt zwei zusätzliche Komponenten in das System ein:

<ul><li>Eine Threat Intelligence, die Quellen über neue Angriffe und Angriffsmethoden systematisch auswertet und überprüft, ob diese auf die Flotte übertragbar sind. Und die in der Folge „Indicators of Compromise“ im eigenen Datenbestand ableitet und gezielt nach Symptomen dieser neuen Angriffstechniken sucht.</li><li> Security-Analysten mit Automotive Security Domänen Know-how, die gezielt nach neuen Bedrohungen suchen und diese in den Logdatenbeständen (Threat Hunting) verfolgen. Dabei dienen ihnen zum Beispiel Erkenntnisse und Auffälligkeiten aus machine-learning-basierten Analysen als Anhaltspunkte bzw. Ausgangshypothesen.</li></ul>

Davon ausgehend können die Security-Analysten potenzielle weitere Schritte im Angriffspfad entdecken und beschreiben (z. B. Lateral Movements) sowie die Analysemethoden des SIEM und der der IDS-Sensoren dahingehend erweitern, dass es Bedrohungsszenarien künftig automatisch erfasst und auf deren evtl. bereits erfolgte Ausnutzung hin prüft. Überdies haben die Security-Analysten die Möglichkeit, die Erkenntnisse aus der Threat Intelligence als Startpunkt für das Threat Hunting zu verwenden, indem sie Informationen aus öffentlich zugänglichen und kommerziellen Quellen hinsichtlich ihrer Relevanz für das Gesamtsystem auswerten.

Alert Validation und verbesserte Bedrohungserkennung

Ein gutes V-SOC sollte dem Flottenbetreiber „actionable information“ liefern, also Erkenntnisse über eine bereits eingetretene oder bevorstehende neue Bedrohung, die es ihm erlauben, geeignete Gegenmaßnahmen zu entwickeln, zu testen und auszurollen. In der Regel erfolgt dies über qualifizierte Reports, angereichert durch Evidenzdaten, gepaart mit einer Beratung und Einschätzung der Situation durch qualifizierte Security-Analysten

Dementsprechend besteht eine der größten Herausforderungen und Aufgaben des V-SOC darin, eine Unterscheidung zwischen „falsch-positiven“ und „echten“ Problemen zu treffen (Alert Validation). Dafür muss für die große Zahl an Assets (klassische ECUs, Domänencontroller, Aktoren, Sensoren u.v.m.), die im Gesamtsystem der vernetzten Fahrzeugflotte vorliegen, ein hoher Grad der Automatisierung angestrebt werden. Zudem müssen für eine situativ effektive und korrekte Bewertung zum Zeitpunkt der Alert-Validation zusätzliche Informationen im V-SOC vorliegen: Wie sind die Softwarestände im Fahrzeuge? Wurden ECUs ausgetauscht? Befindet sich das Fahrzeug in einer Werkstatt?

Das heißt, dem V-SOC müssen Datenquellen des OEMs oder Flottenbetreibers integriert zur Verfügung stehen, um zu verhindern, dass eine Flut falsch-positiver Meldungen zu Unbenutzbarkeit oder Alarmermüdung (Alert Fatigue) führt. Letztlich ist die Alert Validation und die Fähigkeit der Security-Analysten, ein machine-learning-basiertes System in der Unterscheidung der Alerts zu trainieren, ein wesentliches Qualitätsmerkmal des V-SOC.

Das Vehicle Security Operations Center reicht damit über den rein technischen Betrieb einer SIEM-Lösung hinaus. Während das SIEM gut geeignet ist, bekannte Angriffe zu erkennen, fügt das V-SOC ihm eine zielführende Infrastruktur und vor allem qualifiziertes Personal hinzu – und ermöglicht so, die Methodik zur Bedrohungserkennung kontinuierlich anzupassen und zu erweitern.

Aufbau weltweit verteilter Security-Strukturen

Für Betreiber großer, mitunter weltweit verteilter Flotten sind Aufbau und Betrieb eines überspannenden Vehicle Security Operations Center eine gewaltige Aufgabe. Um die nötige Zuverlässigkeit und Resilienz zu erreichen, wird es unumgänglich sein, in verschiedenen Regionen weltweit entsprechende Security-Strukturen zu unterhalten. Zudem werden OEMs und große Flottenbetreiber ungeachtet einer Cloud-Infrastruktur allein deshalb schon auf geografisch verteilte Security Operations Center zurückgreifen müssen, um die länderspezifisch unterschiedlichen rechtlichen Anforderungen (bspw. hinsichtlich Datenschutz) zu erfüllen und die angemessene Risikobehandlung ihrer Flotten im Feld gegenüber Genehmigungs- und Aufsichtsbehörden jederzeit nachweisen zu können.

Es gibt – für den Bereich der Enterprise-IT – heute bereits leistungsfähige Angebote für verteiltes weltweites Security Monitoring. Auf diese vorhandenen Infrastrukturen und Best Practices lässt sich kosteneffizient zurückgreifen. Zumal sie erwiesenermaßen in der Lage sind, die selbst bei Einsatz eines IDS hohen Datenmengen adäquat zu verarbeiten und Erkenntnisse über neue, zu erwartende Angriffe zu Tage zu fördern. Auf dieser Basis lässt sich ein Zyklus der fortwährenden Beobachtung und gezielten Nachbesserung der Security im Fahrzeug realisieren, der den Vorgaben der neuen Security-Regelwerke entspricht und den Schutzlevel über die gesamte Lebenszeit des Fahrzeugs ermöglicht.. (oe)

Bild 1: Security Incident Management Journey – Das IDS erkennt Anomalien und typische Angriffssignaturen in der Fahrzeugkommunikation und reduziert so den Bandbreitenbedarf für die Übertragung der Security Monitoring-Informationen.

Bild 2: Bestandteile eines ganzheitlichen Vehicle Security Operations Center – Von der Intrusion Detection zum Security Operation Center. 

16:9

 Dr. Jens Gramm ist Senior Product Manager Vehicle Security  Operations Center bei ESCRYPT am Standort Stuttgart.

Dr. Eric Knauel ist Projektmanager Vehicle Security Operations  Center bei ESCRYPT am Standort Stuttgart.

Safety / Security

Betriebssichere Architektur  als Sekundärkanal

Angesichts der beabsichtigten Serienfertigung autonomer Fahrzeuge tritt die Komplexität sicherheitsorientierter autonomer Software immer deutlicher zu Tage. In diesem Fachbeitrag von KPIT Technologies wird ein systematischer Ansatz zur Ableitung einer betriebssicheren Architektur am Beispiel einer autonomen Autobahnpilot-Funktion diskutiert. Dazu werden detaillierte Systementwicklungstätigkeiten und Funktionssicherheitsanalysen durchgeführt.

Angesichts der beabsichtigten Serienfertigung autonomer Fahrzeuge tritt die Komplexität sicherheitsorientierter autonomer Software immer deutlicher zu Tage.

Die Komplexitäten sicherheitsorientierter autonomer Software ergeben sich aus mehreren Faktoren wie Sicherheitskonformität, datengestützter Sicherheitsarchitektur, Integration, Testabdeckung, virtueller Simulation, Laufleistungsabdeckung und Homologation. Dementsprechend kommt es bei den meisten Produktionsprogrammen für die Autonomiestufe L3 und höher zu Verzögerungen. Des Weiteren ist die Erfüllung der ISO 26262 im kompletten Software-Stack für das autonome Fahren ein kritischer Aspekt um die Anforderungen von L3 und höherer Autonomiestufen zu erfüllen.

Eine „betriebssichere“ redundante Softwareschicht als Sekundärkanal sorgt für Redundanz im Software-Stack für das autonome Fahren, um die ASIL D-Anforderungen zu erfüllen. Auch wenn jede Funktion und jedes Leistungsmerkmal im Primärkanal dem Sicherheitskonzept entsprechen muss, ist ein Sekundärkanal zur Erfüllung der ASIL D-Anforderungen ebenfalls unerlässlich, da dessen „betriebssichere“ Funktion bei einem Ausfall des Primärkanals die dynamische Fahraufgabe übernimmt, um die Fahrsicherheit des autonomen Fahrzeugs zu gewährleisten.

Wenn Störungen im Primärkanal erkannt werden und der Fahrer nicht rechtzeitig die Kontrolle übernimmt, übernimmt die Sekundärkanalfunktion den gestörten Betrieb, der zum sicheren Stopp des autonomen Fahrzeugs führt. Dies wird durch eine voll funktionsfähige betriebssichere Software erreicht, die Erkennung, Wahrnehmung, Lokalisierung, Planung und Bewegungssteuerung umfasst. Zur Definition der Architektur der Sekundärkanalsoftware wurde eine detaillierte Systementwicklungs- und Sicherheitsanalyse gemäß ISO 26262-Prozess durchgeführt, die später beschrieben wird. Eine L3-Funktion im System wird erwogen zur Ableitung der Elementdefinitionen, Betriebsbedingungen und Gefahrenanalyse und Risikobewertung (HARA). Diese Störungen werden dann als Teil von HARA analysiert und minimale Risikoanteile (MRC) definiert. Um das System während eines Ausfalls in einen sicheren Zustand zu bringen, werden MRCs die Grundlage zur Definition von MRMs. Die betriebssichere Architektur für einen Sekundärkanal wird anhand der MRMs definiert.

Ein hochautomatisiertes Fahrsystem oder L3+ System stützt sich bei allen dynamischen Fahraufgaben hauptsächlich auf das System selbst. Dazu gehören Längs- und Querregelung, Objekterfassung und -erkennung und Fallback bei dynamischen Fahraufgaben. Beim hochautomatisierten Fahrsystem wird davon ausgegangen, dass der auf einen Fallback vorbereitete Benutzer kurzfristig wieder die Kontrolle übernimmt, wenn das System ihn dazu auffordert. Diese Systeme können nicht erwarten, dass der Fahrer angesichts der begrenzten Reaktionszeit auf die Aufforderung reagiert. Der Schlüssel zur Lösung dieses Problems liegt in einem höheren Grad an Autonomie und Verfügbarkeit und einer Verbesserung des Systems. Eine betriebssichere Architektur für das autonome Fahrsystem ist erforderlich, um ein akzeptables Sicherheitsniveau zu erreichen, und sie muss das minimale Risikomanöver ausführen, um das System in einen sicheren Zustand zu bringen, wenn irgendwelche Komponenten oder Unterfunktionen ausfallen. Das betriebssichere System muss von Störungen verursachte Fehler erfassen, den Schaden beurteilen, den Fehler in fehlertoleranter Zeit beheben und die Störung isolieren. Das System gewährleistet die Integrität der zur Steuerung der Fahrzeugstellantriebe verwendeten Ausgangsdaten und sorgt bei Störungen für einen kontinuierlichen sicheren Betrieb. Eine Möglichkeit zur Erreichung von Betriebssicherheit ist die Erhöhung der Redundanz von Sensoren, Steuerungen, Stellgliedern usw., dies führt jedoch zu mehr Kosten, Gewicht und Raumbedarf, und dies sind einige der Sachzwänge in der Automobilindustrie. Die Lösung kann also nur im Software-Stack liegen.

Der Prozess zur Definition, Entwicklung und Validierung einer Sicherheitsfunktion

Bevor wir uns mit den Details der Architektur beschäftigen, ist es sehr wichtig, den vollständigen Prozess zu verstehen, der zur Definition, Entwicklung und Validierung solcher Sicherheitsfunktionen befolgt wird. In Bild 1 ist der Prozessablauf dargestellt.

Ein Prozess gewährleistet eine systematische Entwicklung sicherer Software. Im Allgemeinen wird der Detailprozess vor Realisierung des Prototyps nicht genau befolgt. Aber für das betriebssichere System ist es von entscheidender Bedeutung, den Prozess zur Definition der Architektur zu befolgen, der aus den Artefakten der Sicherheitsanalyse abzuleiten ist.

Durch ein durchdachtes System und die Sicherheitsentwicklung wird die betriebssichere Architektur abgeleitet, um die ASIL D-Anforderungen auf der Ebene des autonomen Fahrsystems zu erfüllen. In Bild 2 ist die Systemarchitektur zur Sicherstellung einer sicheren Fahrt auf der Autobahn durch die Primär- und Sekundärfunktionen dargestellt. Sowohl die Primär- als auch die Sekundärfunktion sind mit einer unabhängigen Stromversorgung galvanisch getrennt, um Einzelpunktfehler zu vermeiden. Eine ungleiche Softwarearchitektur (primär und sekundär) würde mehr Robustheit und Neutralität durch verschiedene Technologie bieten, da es unterschiedliche Besitzer gibt.

Basierend auf dem Szenario in der Architektur wird jeder Komponentenausfall analysiert, und daraus werden mehrere mögliche MREs abgeleitet. Diese MREs werden dann in der Architektur (Abbildung 2) nach Komponentenschicht gruppiert. Das Ziel all dieser MREs ist die Erreichung der endgültigen MRC in Form von Sicherheit/Komfort/Not-Halt. Beispielsweise wird MRE_Gruppe1 zur Ableitung der internen MREs ausgearbeitet, um eine betriebssichere Bedingung im Fall irgendeines Komponentenversagens zu erreichen.

Die Architektur berücksichtigt geeignete Schnittstellen mit Primärkanalfunktionen wie zum Beispiel Sensor-, Anwendungs- und Middleware-Schnittstellen. Jede Schicht der Architektur wird in verschiedene MRE-Gruppen aufgeteilt (Wahrnehmung, Fahrstrecke, Fahrzeugbewegungskontrolle, usw.). Ein reibungsloser Übergang von der Ausführung des Primärsystems zur betriebssicheren Funktion muss gewährleistet sein.

Die Wahrnehmungskomponente kann aufgrund eines oder mehrerer Komponentenausfälle auf den Ebenen der Objekt-, der Spur- und/oder der Sensorfusion fehlschlagen. Für jeden Komponentenausfall wird eine detaillierte Analyse durchgeführt, um interne MREs abzuleiten und einen eingeschränkten Betrieb zu erreichen.

Wie in Bild 3 gezeigt, kann die Objektfusion aus mehreren Gründen wie Kameraerfassungs- oder Radererfassungsstörungen oder beidem fehlschlagen, was schwerwiegende Objekterfassungsfehler zur Folge hat. Wenn zum Beispiel der Ausfall eines Kamerasensors festgestellt wird, kann sich das Wahrnehmungsmodul immer noch auf andere Sensoren stützen, wenn ein bewegliches Objekt per Radar erfasst wird. Einige andere Techniken wie die Sperre der Zielinformationen, wenn sie über mehr als einen bestimmten Zeitraum erfasst werden und die Verwendung dieser historischen Informationen vor dem Fehlerzustand kann helfen, den ausfallsicheren Betrieb durchzuführen. Ebenso lassen sich bei Ausfall der Radarerfassung Kameradatenfehler aufgrund von Pitch durch kreiselbasierte Abstandsstabilisierung abmildern.

Wenn es eine Teilfahrspurerkennung oder Kameradaten mit geringer Zuverlässigkeit gibt, lässt sich die Ego-Spurgeometrie auf Basis anderer Verkehrsobjektpfade schätzen. Werden die Straßenränder oder die Leitplanke erfasst (Cluster in Radarreflexionen), können sie bei der Erstellung virtueller Spurinformationen helfen. Im ungünstigsten Fall, wenn keine Spurinformationen verfügbar sind, kann sie sich auf vordere oder seitliche Zielinformationen stützen und dem Zielobjekt in einem sicheren Abstand folgen.

Bei zeitweise auftretenden IMU-Störungen hilft die Verwendung dynamischer Modelle und Fahrzeugzustände (Fahrzeugsensor) und die Auslegung von linearen/erweiterten/Unscented Kalman-Filtern die Sensorgenauigkeit zu verbessern. Bei schwerwiegenden Fehlern empfiehlt sich jedoch ein redundanter Sensor für den Sekundärkanal in der Architektur.

Der Bedarf an der sekundären Sicherheitsfunktion wurde im Systementwicklungsprozess erkannt. Ein systematisches Konzept zur Entwicklung einer betriebssicheren Sekundärfunktion gemäß ISO 26262 wurde anhand eines Beispiels besprochen.

Die unabhängige Entwicklung der Sicherheitsfunktion mit allen Systemen und Sicherheitsartefakten würde die Konzentration auf die Besitzer der Primärfunktion beseitigen. Die Architektur ist modular ausgelegt und lässt sich individuell anpassen und in die Primärfunktionen und Middleware integrieren, um den Software-Stack für das autonome Fahren kompatibel zu ASIL-Anforderungen zu machen.

Dies beschleunigt seinerseits die Entwicklung des autonomen Fahrens bei gleichzeitiger Erfüllung der gesetzlichen Anforderungen. (oe)

Bild 2: Betriebssichere Architektur für die Sekundärfunktionen.

Bild 3: Abgeleitete mögliche MREs für Objektfusionsstörungen.

Reshma Sheerin ist Senior Solution Architect bei KPIT Technologies.

Bild 1: Sicherheitsprozess zur Definition der betriebssicheren Architektur.

Dr. Manaswini Rath ist Vice President and Global Head Autonomous Driving bei KPIT Technologies.

Halbleiter-Schaltungen (ICs) müssen immer mehr die strengen Sicherheitsanforderungen der Norm ISO 26262 erfüllen. Die Fähigkeit, mögliche latente und transiente Fehler über die gesamte Lebensdauer abzudecken, bestimmt die Gesamtdiagnoseabdeckung der Schaltung, die das erreichbare Niveau der Sicherheitsintegrität (ASIL) bestimmt. Dies stellt Hersteller von ICs und Systemen für die Automobilindustrie zunehmend vor neue Herausforderungen.

Halbleiter-Schaltungen (ICs) müssen immer mehr die strengen Sicherheitsanforderungen der Norm ISO 26262 erfüllen. Die Fähigkeit, mögliche latente und transiente Fehler über die gesamte Lebensdauer abzudecken, bestimmt die Gesamtdiagnoseabdeckung der Schaltung, die das erreichbare Niveau der Sicherheitsintegrität (ASIL) bestimmt.

Integrierte Schaltungen (ICs) für Fahrzeuge werden zunehmend nach modernsten Verfahren entwickelt und hergestellt. Sie werden nicht mehr nur für einfache Funktionen wie die Steuerung von Fenstern oder der Lichtsignale eingesetzt, sondern jetzt auch für komplexere Funktionen im Zusammenhang mit Fahrerassistenzsystemen genutzt und zunehmend für autonome Fahranwendungen benötigt. Die für diese erweiterten Funktionen erforderliche Verarbeitungsleistung führt dazu, dass sehr große und komplexe ICs benötigt werden, bei denen eine optimale Energieeffizienz wichtig ist. Verbunden mit der Notwendigkeit, dass diese Schaltungen die strengen Sicherheitsanforderungen der Norm ISO 26262 erfüllen, stellt dies die Hersteller von Schaltungen und Systemen für die Automobilindustrie vor neue Herausforderungen. Es sind Lösungen erforderlich, die gewährleisten, dass neue komplexe elektronische Fahrzeugsysteme während der gesamten Lebensdauer des Fahrzeugs jederzeit sicher funktionieren. Dies wird als funktionale Sicherheit bezeichnet.

Die funktionale Sicherheit beruht auf Mechanismen innerhalb der Schaltung, die als Sicherheitsmechanismen bezeichnet werden und die den korrekten funktionalen Betrieb der Schaltung im Einsatz überwachen und überprüfen sollen. Äußerst beliebt ist hier der Ansatz, eine Reihe eingebetteter Überwachungsfunktionen zu verwenden, die über jede Halbleiterschaltung verteilt und über eine globale Kommunikationsinfrastruktur miteinander verbunden sind, was die schnelle Erkennung und Meldung zufälliger Fehler überall im System ermöglicht. Diese Überwachung muss stattfinden, ohne den normalen funktionalen Betrieb zu beeinträchtigen und die Flexibilität aufweisen, je nach Endanwendung des Halbleiters und der zugehörigen ASIL-Klassifizierung einen unterschiedlichen Grad an Fehlerabdeckung bereitzustellen. Ein Beispiel einer Testarchitektur auf Chipebene, die eine verteilte systemweite Überwachung unterstützt, ist in Bild 1 dargestellt.

Ein standardmäßiger IEEE 1149.1-Testzugriffsport (TAP) bietet eine Schnittstelle zu allen On-Chip-Testressourcen während des Produktionstests. Der TAP stellt eine Verbindung zu einem rekonfigurierbaren seriellen Zugriffsnetzwerk her, das auf dem IEEE 1687-Standard basiert (häufig als IJTAG-Standard bezeichnet). Dieses IJTAG-Netzwerk besteht aus Konfigurations-Elementen, die als Segment Insertion Bits (SIBs) bezeichnet werden. Mit jedem SIB kann ein Teilnetzwerk eingeschaltet oder umgangen werden, wodurch ein optimierter Zugriff auf alle Testressourcen innerhalb des Netzwerks möglich wird. Auf das IJTAG-Netzwerk wird auch von einem IST-Controller (In-System Test) zugegriffen, in diesem Fall dem Tessent MissionMode-Controller. Der MissionMode-Controller kommuniziert über eine CPU/DMA-Schnittstelle entweder mit der Außenwelt oder einem internen Sicherheitsmanager und führt die für die Datenübermittlung zwischen dem CPU/DMA-Bus und dem internen IJTAG-Netzwerk erforderliche Parallel-Seriell- und Seriell-Parallel-Datenkonvertierung durch. Dieser IST-Controller ermöglicht eine Kommunikationsarchitektur auf Systemebene, wie in Bild 2 dargestellt.

Ein Serviceprozessor kann über jeden eingesetzten Fahrzeugbus wie CAN oder I2C auf den IST-Controller jedes Chips und damit auf jede On-Chip-Testressource zugreifen.

Bei erweiterten Ein-Chip-Systemen kann die Sicherheitsmanager-CPU als Teil der Schaltung eingebettet werden. Diese Architektur wird allgemein als „Sicherheitsinsel“ bezeichnet. Wenn man den Sicherheitsmanager in die Sicherheitsinsel integriert, verringert sich die Wahrscheinlichkeit, dass er durch Defekte im funktionalen Teil der Schaltung beeinträchtigt wird. Dies wird als „Insel“ bezeichnet, weil sie als separate physische und Leistungspartition auf dem Chip behandelt wird, häufig dedizierte Strom- und Steuersignale empfängt und so weit wie möglich physisch von der funktionalen Logik isoliert ist. Die einzige Datenverbindung zwischen der Sicherheitsinsel und der anderen funktionalen Logik sind die Verbindungen zum Testnetzwerk. Bild 3 zeigt die Hauptteile einer typischen Sicherheitsinsel.

Die Wirksamkeit dieses verteilten Systems auf einer einzelnen Schaltung oder mehreren Schaltungen hängt von den Testressourcen ab, die in den verschiedenen Schaltungen implementiert sind. Um die ISO 26262-Zertifizierung zu erhalten, müssen diese Ressourcen in der Regel eine Mischung aus funktionalen und strukturellen Sicherheitsmechanismen sein. Die wahrscheinlich häufigste Form der On-Chip-Strukturressource ist der Memory Built-In Self-Test (MBIST). Eine MBIST-Engine testet einen eingebetteten Speicher vollständig, indem sie algorithmisch eine Folge von Lese- und Schreiboperationen erzeugt, die den gesamten Adressraum abdecken.

Eine große Herausforderung bei der Durchführung eines solchen Speichertests während des Fahrzeugbetriebs besteht darin, dass der Speicher zuerst abgeschaltet werden muss, damit die MBIST-Engine die Kontrolle übernehmen kann. Es kann auch erforderlich sein, den Speicherinhalt vor dem Ausführen des Tests zu sichern und den Inhalt anschließend wiederherzustellen, da der Speichertest den Speicherinhalt vor dem Test löscht. Eine weitere Schwierigkeit besteht darin, dass das Abschalten des Speichers wahrscheinlich auch die Systemleistung beeinträchtigt, was bei einigen Anwendungen möglicherweise nicht akzeptabel ist. Eine nicht-destruktive MBIST-Technik wurde entwickelt, um all diese Probleme zu vermeiden. Bei diesem Ansatz testet die MBIST-Engine den Speicher mithilfe einer Reihe kurzer Transaktionssequenzen, die häufig als Bursts bezeichnet werden. Ein Burst dauert normalerweise nur eine kleine Anzahl von Taktzyklen (möglicherweise 20 bis 30) und richtet sich jedes Mal auf unterschiedliche Teile des Speichers. Der gesamte Speicher wird daher mittels einer großen Anzahl kurzer MBIST-Abläufe getestet. Dieser Ansatz ist nicht-destruktiv, da die durch einen Burst geänderten Speicherteile während jedes Bursts von der MBIST-Engine gespeichert und danach wiederhergestellt werden. Die funktionale Leistung wird hierdurch nicht wesentlich beeinträchtigt, da die Bursts nur ausgelöst werden, wenn die zwischen der MBIST-Engine und der Funktionslogik implementierte Arbitrierungslogik feststellt, dass der Speicher zugreifbar ist.

Logic BIST ist eine weitere beliebte Form struktureller systeminterner Testressourcen, auf die über den IST-Controller zugegriffen werden kann. Diese Testlösung beruht auf der Erzeugung von Zufallstestmustern auf dem Chip, die auf Scanketten angewendet werden, um den Logikteil eines Chips zu testen. Die Antworten des Chips auf alle Zufallstestmuster werden zu einer Signatur zusammengefasst, die am Ende des Tests untersucht wird und ergibt, ob der Chips den Test bestanden oder nicht bestanden hat. Die Testabdeckung, die durch Anwenden einer zunehmenden Anzahl von Zufallstestmustern erreicht wird, wächst logarithmisch, wie in Bild 4 (A) gezeigt.

Bei diesem Ansatz stellt sich jedoch häufig das Problem, innerhalb eines bestimmten Zeitbudgets eine ausreichend hohe Testabdeckung zu erreichen. Eine Lösung für dieses Problem besteht darin, den Test in mehrere Abläufe zu unterteilen, wie in Bild 4 (B) dargestellt. Jeder aufeinanderfolgende Testablauf wird während einer verfügbaren Unterbrechung des funktionalen Betriebs durchgeführt. Beispielsweise könnte in einem Bildprozessor, der zum Verarbeiten visueller Daten verwendet wird, jeder Testablauf zwischen der Verarbeitung der einzelnen Bilder durchgeführt werden. Das Management dieser mehreren Teiltests erfordert eine sorgfältige Koordination zwischen dem IST-Controller und der Logic BIST-Engine. Der IST-Controller muss verfolgen, welcher Testabschnitt als Nächstes angewendet werden soll, die Logic BIST-Engine initialisieren, damit sie den richtigen Satz von Zufallstestmustern erzeugt, und dann die Zwischensignatur abrufen und vergleichen, um festzustellen, ob der Test bestanden wurde oder nicht.

Es gibt jedoch Fälle, in denen diese Art der Verteilung entweder nicht möglich ist oder immer noch nicht die erforderliche Abdeckung im FTTI (Fault Tolerant Time Interval) bietet. Hier ist eine neue Technologie nützlich, die die Logic BIST Testzeit erheblich verkürzt und so die Gesamtreaktionszeit erheblich verbessert. Dieser Logic BIST mit Observation Scan-Technologie (OST) verwendet spezielle Testpunkte, die in das Design eingefügt wurden, sowie eine kleine dedizierte Scan-Kette von Beobachtungs-Scan-Zellen, mit denen die Fehlerabdeckung der Funktionslogik bei jedem Zyklus effektiv erfasst werden kann, anstatt nur bei dem Erfassungszyklus jedes Musters. Dies wird in Bild 5 dargestellt. Das Ergebnis ist eine viel schnellere Testabdeckung der funktionalen Logik, so dass diese Sicherheitsmechanismen ihre erforderlichen Qualitätsziele schneller als bei einem herkömmlichen Logic BIST erreichen können. Bild 6 zeigt den Vergleich zwischen LBIST-OST und herkömmlichem Logic BIST.

Alle hier beschriebenen Technologien und Methoden ermöglichen die Implementierung einer beliebigen Anzahl sicherheitsrelevanter Funktionen auf Systemebene. Alle Testfehler können an den Sicherheitsmanager zurückgemeldet werden, um Korrekturmaßnahmen durchzuführen. Auch bei IST-Steuerungen können Fehler vom Sicherheitsmanager überwacht und Maßnahmen ergriffen werden, die vom Deaktivieren bestimmter Funktionen bis zum Versetzen des Fahrzeugs in einen sicheren Betriebszustand reichen können. Da es von entscheidender Bedeutung ist, schnell Korrekturmaßnahmen zu ergreifen, ist die Reaktionszeit dieser Sicherheitsmechanismen so wichtig. (oe)

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

Bild 5: Logic BIST mit Observation Scan-Architektur.

Bild 6: Verbesserung der Testzeit durch LBIST-OST.

Bild 1: Testarchitektur auf Chipebene für systeminterne Tests.

Bild 4: Management der Testzeit des Logic BIST.

Lee Harrison ist Automotive IC Test Solutions Manager in der Tessent-Gruppe bei Mentor, einem Siemens Unternehmen.

Höhere Sicherheit bei Kfz-Funkschlüssel

RKE-System mit MEMS- Beschleunigungssensor

Die am häufigsten für Autodiebstähle angewandte Methode ist die so genannte Relaisattacke, bei der ein Repeater das Signal des Schlüssels an das in einiger Entfernung geparkte Auto überträgt. Als Abhilfe gegen dieses Problem kann in den Funkschlüssel ein MEMS-Bewegungssensor integriert werden, der mehr Sicherheit bietet, da der Funkschlüssel die Kommunikation mit dem Fahrzeug nur dann anstößt, wenn die Grenzbeschleunigung überschritten wird.

Die am häufigsten für Autodiebstähle angewandte Methode ist die so genannte Relaisattacke, bei der ein Repeater das Signal des Schlüssels an das in einiger Entfernung geparkte Auto überträgt.

Bei Funkschlüsseln ist neben der Herausforderung des Stromverbrauchs die Sicherheit ein kritischer Aspekt. Wenn ein Funkschlüssel fortlaufend senden würde, wäre das Funksignal ständig verfügbar, obwohl es nicht benötigt würde. Das Signal selbst und die enthaltenen Codes würden dabei unnötigerweise exponiert. Dies wäre beispielsweise der Fall, wenn sich der Funkschlüssel im Hauseingang befindet und das Auto in der Garage oder auf der Straße geparkt ist. Unbefugte Personen könnten solche Situationen ausnutzen, um das Fahrzeug zu stehlen.

Die am häufigsten für Autodiebstähle angewandte Methode ist die so genannte Relaisattacke, bei der ein Repeater das Signal des Schlüssels an das in einiger Entfernung geparkte Auto überträgt. Der Fahrzeugdieb initiiert in diesem Fall die Kommunikation zum Anstoßen des Authentifizierungsprozesses, der dann im Prinzip nur zwischen Schlüssel und Fahrzeug erfolgt. Bei dieser verblüffend simplen Methode muss der Autodieb die Kommunikation nicht einmal entschlüsseln, sondern die Daten lediglich mithilfe des Repeaters weiterreichen.

Alternativ ist es auch möglich, die Funksignale abzuhören und die Kommunikation abzufangen, um die digitalen Codes und den Schlüssel daraufhin mithilfe von Brute-Force-Methoden zu entschlüsseln. Durch Reproduzieren des decodierten digitalen Schlüssels könnten sich dann unbefugte Personen Zugang zum Fahrzeug verschaffen, um es zu starten und zu stehlen. Zur Minimierung dieses Risikos erfolgt die Kommunikation nur dann, wenn der Fahrzeugbesitzer tatsächlich Zugang zum Fahrzeug wünscht, während die Funk-Kommunikation zu allen anderen Zeiten inaktiv ist.

Als Abhilfe gegen diese Probleme kann in den Funkschlüssel ein auf MEMS-Technologie (Micro Electro Mechanical System) basierender Bewegungssensor integriert werden, der als intelligenter Schalter fungiert. Der MEMS-Bewegungssensor erfasst im Prinzip Beschleunigungen in beliebigen Richtungen (X-, Y- und Z-Achse), wenn der Funkschlüssel bewegt wird, was darauf hindeutet, dass der Fahrzeugbesitzer Zugang zum Fahrzeug wünscht. Wenn eine bestimmte Grenz-Beschleunigung registriert wird, kann der Bewegungssensor ein Interruptsignal an den Mikrocontroller senden, um das System zu aktivieren. Dieses befand sich bis zu diesem Zeitpunkt im Standby-Modus, in dem besonders die Funk-Transceiver keinerlei Strom verbrauchten. Im Standby-Status ist nur der äußerst stromsparende MEMS-Sensor aktiv, der aber mit sehr geringer Frequenz arbeitet und deshalb nur wenige hundert Nanoampere Strom aufnimmt.

Der Sensor bietet jedoch insbesondere mehr Sicherheit, da der Funkschlüssel die Kommunikation mit dem Fahrzeug nur dann anstößt, wenn die Grenz-Beschleunigung überschritten wurde. Demzufolge besteht kein Risiko, dass die digitalen Codes und Schlüssel abgefangen werden, solange der Funkschlüssel irgendwo abgelegt ist.

Wird die Beschleunigungsschwelle überschritten, kann der Mikrocontroller außerdem vor Freigabe der Kommunikation eine Reihe von Daten-Evaluierungen ausführen, um das genaue Bewegungsmuster zu erkennen. Auf diese Weise können irrelevante Bewegungen, wenn der Funkschlüssel beispielsweise in einem Rucksack, einer Handtasche oder in der Hosentasche getragen wird, während man Treppen steigt oder sich vom Fahrzeug wegbewegt, identifiziert werden. In solchen Fällen kann der Funkschlüssel aktiv entscheiden, keine Daten zu senden, damit diese nicht von in der Nähe befindlichen potenziellen Dieben zum Stehlen des Fahrzeugs genutzt werden können. Erst wenn eindeutig das Entnehmen des Funkschlüssels aus der Hosen- oder Handtasche erkannt wird, kann die Kommunikation mit dem Fahrzeug erfolgen.

Der MEMS-Beschleunigungssensor löst also die Probleme, jedoch kommt dafür ein neuer Aspekt zum Tragen: Verkraften die in Funkschlüsseln verwendeten MEMS-Sensoren die mechanischen Belastungen, die entstehen, wenn ein Schlüssel fallengelassen wird, was ja nicht selten vorkommt?

Tatsächlich enthalten MEMS-Sensoren bewegliche Teile, die bei mechanischen Stößen beschädigt werden können. Nur ein robuster Fertigungsprozess in Verbindung mit speziellen Designtechniken sowie Prüf- und Qualifikationsprotokollen, die aufgrund von Erfahrungen aus ähnlichen Anwendungen (z. B. Mobiltelefone und Wearables) entwickelt wurden, erlauben das Design und die Produktion eines MEMS-Sensors mit der für solche Anwendungen erforderlichen, Robustheit. Hinsichtlich der Robustheit hat STMicroelectronics seine Bewährungsprobe als MEMS-Hersteller bestanden. Das Unternehmen lieferte bislang bereits mehr als 17 Milliarden MEMS-Bauelemente aus, und dies großenteils für Anwendungen mit ähnlichen mechanischen Belastungen, wie sie bei Funkschlüsseln auftreten.

Unter der Bezeichnung AIS2DW12 bietet STMicroelectronics einen 3-Achsen-MEMS-Beschleunigungssensor an, der für einen Messbereich von ±2g oder ±4g konfigurierbar ist und die zuvor beschriebenen Anforderungen an Bewegungssensoren für diese Anwendung erfüllt. Mit nur 380 nA Stromaufnahme bei der niedrigsten Ausgangs-Datenrate von 1,6 Hz und 1,8 V Versorgungsspannung entspricht dieses Bauelement den Forderungen des Markts nach möglichst geringem Stromverbrauch.

Für Systeme, die eine höhere Datenrate verlangen, um Bewegungen besser überwachen zu können, bietet sich der 12,5-Hz-Modus mit 3 V Versorgungsspannung an, in dem die Stromaufnahme typisch 1,5 µA bzw. maximal 2,9 µA beträgt. Um den Wirkungsgrad des Gesamtsystems zu optimieren, steht ein Wake-up-Modus mit programmierbaren Schwellenwerten und Interrupt-Pin zur Verfügung. Darüber hinaus kann mit dem so genannten On-Demand-Modus bei Bedarf auch eine Einzelmessung initiiert werden. Hiermit lassen sich während langer Ruheintervalle sporadische Checks vornehmen.

Neben den mechanischen Elementen enthält der AIS2DW12 auch einen ASIC, der die Kapazitätsänderung in eine Spannung umwandelt. Weitere Funktionsabschnitte in dem Chip erzeugen aus der analogen Spannung einen digitalen Wert, der über ein schnelles Interface ausgelesen werden kann – entweder über eine vieradrige SPC-Schnittstelle oder eine zweiadrige I²C-Schnittstelle.

Zu den weiteren Features gehören ein eingebauter FIFO-Speicher mit 32 Ebenen, ein Selbsttest zur Überprüfung der korrekten Funktion der Mechanik und Elektronik sowie ein eingebauter Temperatursensor. Eine interne Einheit verarbeitet die Bewegungs- und Beschleunigungsdaten beim freien Fall, in Bewegung und in Ruhe, beim Aufwecken, bei Aktivität und Inaktivität sowie die 6D/4D-Orientierung.

Geeignet ist der AIS2DW12 auch für zahlreiche weitere Automotive-Anwendungen, in denen Beschleunigungssensoren oder Positionssensoren im Allgemeinen benötigt werden. Dazu zählen unter anderem die Positionsermittlung in Navigations- und Telematikgeräten, das Verriegeln des Displays in Infotainmentsystemen, Dach- und Türmodule, Alarmanlagen und Mautsysteme sowie Neigungs- und Stabilisierungs-Anwendungen.

Zum schnellen Evaluieren kann das Board STEVAL-MKI206V1 zusammen mit dem Motherboard STEVAL-MKI109V3 geordert werden. (oe)

Bild 3: Schon im 2g-Messbereich und bei einer Ausgangs-Datenrate von 1,6 Hz lässt sich das typische Bewegungsmuster beim Gehen mit dem Autoschlüssel in der Hosentasche erkennen. In der Grafik links sind nur die Schritte zu sehen, da sich der Funkschlüssel die ganze Zeit in der Hosentasche befindet. Rechts dagegen ist nach einigen Schritten ein völlig anderes Muster zu erkennen, wenn der Schlüssel aus der Tasche geholt wird. Beide Muster können überwacht und zur Freigabe des Zugangs zum Fahrzeug genutzt werden, wobei neue Designs auch das Einsteigen in das Auto ermöglichen, ohne dass der Funkschlüssel aus der Tasche geholt wird.

Bild 1: Bei einer Relaisattacke sind zwei Angreifer nötig. Angreifer A initiiert die Kommunikation mit dem Fahrzeug (1), um den Authentifizierungsprozess seitens des Fahrzeugs anzustoßen (2). Dieser Prozess wird von Angreifer A an Angreifer B weitergeleitet, der die Kommunikation mit dem Funkschlüssel (4) aufbaut, um die Antwort auf die Authentifizierungs-Challenge bereitzustellen (5) und die Antwort an Angreifer A zurückzuleiten (6), der diese schließlich an das Fahrzeug weitersendet (7). Damit ist der Zugang zum Auto frei, das daraufhin an einen Ort gefahren werden kann, an dem sich das Zugangssicherungs-System umprogrammieren lässt.

Bild 2: Remote Keyless Entry System mit dem 3-Achsen-Beschleunigungssensor AIS2DW12 im Funkschlüssel.

Llorenç Vallmajó ist Senior Product Marketing Manager bei STMicroelectronics.

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

Transformation von SOME/IP  in Richtung SOME/CAN

Bei der Vernetzung künftiger Automobilgenerationen werden im Wesentlichen die verschiedenen Ethernet- und CAN-Varianten zum Einsatz kommen. Eine wichtige Rolle für das effiziente Neben- und Miteinander der beiden grundverschiedenen Konzepte soll das neue CAN XL übernehmen. Dabei stellen sich die Fragen, ob auch CAN-XL-Steuergeräte an der servicebasierten Kommunikation werden teilnehmen können und welche Wege es gibt, um dies zu realisieren?

Bei der Vernetzung künftiger Automobilgenerationen werden im Wesentlichen die verschiedenen Ethernet- und CAN-Varianten zum Einsatz kommen.

Die technischen Eckdaten von CAN XL sind weitgehend definiert: Die neue CAN-Variante bietet Datenraten bis 10 Mbit/s und ist mit einer variablen Nutzdatenlänge im Bereich von 1...2048 bit unter anderem in der Lage, komplette Ethernet Frames innerhalb von CAN XL Frames zu transportieren. Erwartungsgemäß ist CAN XL ansonsten weitgehend rückwärtskompatibel zu CAN oder CAN FD und dem Konzept der signalbasierten Kommunikation. Dies ist insbesondere von Vorteil für die Weiterentwicklung der Elektronikarchitekturen von Klein- und Mittelklassewagen, bei denen noch keine Ethernet-Hochleistungskommunikation für fortgeschrittene Assistenzsysteme (ADAS) und autonomes Fahren erforderlich ist. CAN XL erlaubt es, vorhandene Vernetzungskonzepte, Vernetzungstopologien und Kabelbäume ohne große Modifikationen weiterzuverwenden.

Mit CAN XL das Beste aus beiden Welten nutzen

Dennoch gehört die Zukunft der serviceorientierten IP-Kommunikation mit Ethernet, bei der der Middleware SOME/IP (Scalable service Oriented MiddlewarE over IP) mit ihrem Service-Discovery-Verfahren SOME/IP-SD eine zentrale Bedeutung zukommt. SOME/IP ermöglicht innerhalb von Fahrzeugen einen dynamischen Verbindungsaufbau zwischen Providern (Datenquellen) und Consumern (Datensenken). Wer die Dienste oder Daten liefert ist für moderne Anwendungen unerheblich.

Weiter beherrscht die serviceorientierte Kommunikation das Übertragen dynamischer Datenstrukturen. Bei Sensordaten-Fusions-Anwendungen beispielsweise ergibt sich die Größe der zu übertragenden Daten erst während der Laufzeit. Solche Daten lassen sich nicht statisch mappen, wie es bei der signalbasierten Kommunikation üblich ist, vielmehr muss das Kommunikationssystem sie dynamisch serialisieren. Verantwortlich für die Serialisierung ist in der AUTOSAR-Classic-Plattform das SomeIpXf-Modul. Da es Teil der Middleware-Ebene von AUTOSAR ist, lässt sich die Funktionalität zum Serialisieren dynamischer Daten auch für CAN XL nutzen.

Dynamischer Verbindungsaufbau mit SOME/IP-SD

SOME/IP unterstützt sowohl einen volldynamischen als auch einen semi-dynamischen Verbindungsaufbau. Der volldynamische Verbindungsaufbau kommt zur Anwendung, wenn die Netzwerkknoten keinerlei Kenntnisse über IP- und MAC-Adressen voneinander haben. Er baut auf allen Protokollebenen die Kommunikation dynamisch auf, womit einige Vorteile verbunden sind: so lässt sich ein Service im Netzwerk beliebig auf andere Knoten verschieben, ohne dass Änderungen an den Steuergeräten notwendig sind. Dasselbe gilt für MAC- und IP-Adressen. Beim volldynamischen Verbindungsaufbau nutzen Consumer und Provider gegebenenfalls mehrfach das Address Resolution Protocol (ARP), um gegenseitig die MAC- und IP-Adressen zu ermitteln.

Ebenso gibt es Gründe, die für den semi-dynamischen Verbindungsaufbau sprechen, bei dem IP-Adressen und MAC-Adressen statisch festgelegt sind. Jedes Steuergerät verfügt über eine Mapping-Tabelle, in der die IP- und MAC-Adressen der anderen Netzwerkknoten hinterlegt sind. Auch diese Methode baut zur Laufzeit dynamisch die Kommunikation auf der Serviceebene auf, erlaubt aber einen schnelleren Start der Kommunikation, da sie ohne ARP auskommt. Auch beim semi-dynamischen Verbindungsaufbau lassen sich Services beliebig verschieben, da alle IP- und MAC-Adressen bekannt sind. Der Nachteil besteht darin, dass IP/MAC-Adressen nun nicht mehr veränderbar sind. In diesem Fall sind zusätzlich die Mapping-Tabellen in allen betroffenen Steuergeräten zu aktualisieren. Wichtig zu wissen ist, dass die Industrie, je nach Fahrzeug beziehungsweise Modellreihe, manchmal volldynamischen und manchmal semi-dynamischen Verbindungsaufbau einsetzt. SOME/IP funktioniert mit jeder Ethernet-Variante, egal ob es sich um rein geswitchte Netzwerke handelt oder solche mit Bustopologie.

Serviceorientierte Kommunikation auf CAN XL

Um der Rolle als Bindeglied zwischen Ethernet- und CAN-Domänen gerecht zu werden, soll CAN XL auch an der serviceorientierten Kommunikation teilnehmen können. Von großem Interesse für die Designer künftiger E/E-Architekturen ist daher, welche Möglichkeiten CAN XL aus technischer Sicht in dieser Richtung bietet. Gleichzeitig streben die Anwender stets nach der kostengünstigsten Lösung, und somit ist entscheidend, welche Anforderungen die einzelnen Lösungen an den Software Stack und die Steuergerätehardware stellen.

Eine erste Möglichkeit ist es, Ethernet Frames auf CAN XL zu routen. Dazu lässt sich ein Standard Ethernet-Switch verwenden. Hardwareseitig ist zwischen dem Port, an dem das CAN-XL-Netz hängt, und dem CAN-XL-Bus ein noch neu zu entwickelnder CAN XL PHY einzufügen. Dieser soll in der Lage sein, die kompletten Ethernet Frames in CAN XL Frames zu kopieren und umgekehrt – je nach Richtung der Kommunikation. Der CAN XL PHY ist lediglich am Ethernet Switch nötig, während an den CAN-XL-Knoten gängige Transceiver ausreichen. Grundsätzlich ist es natürlich auch möglich ein herkömmliches Gateway zu verwenden (Bild 1).

Deutliche höhere Anforderungen stellen sich dafür an den CAN XL Stack. Sobald Ethernet Frames in CAN XL eingebunden sein können, ist zusätzlich ein üblicher TCP/IP Stack im CAN-XL-Steuergerät erforderlich. Wohlgemerkt: Im CAN XL Frame ist ein Ethernet Frame eingebettet, welcher wiederum ein IP-Paket enthält. Der Interface Layer wiederum muss sowohl das Verhalten von CAN als auch das von Ethernet beherrschen. Der CAN-Teil des Interface Layers packt den Ethernet Frame aus, der Ethernet-Anteil den IP Frame. Des Weiteren erfordert jeder CAN-XL-Knoten eine virtuelle MAC-Adresse. Dann wird für den CAN XL PHY nur ein CAN Frame benötigt, um die vom Ethernet-Netzwerk empfangenen Frames auf CAN XL weiter zu senden und für jeden CAN-XL-Knoten jeweils einen weiteren CAN Frame für Antwortdaten. Filterfunktionen können auf Basis der im Frame eingebetteten MAC-Adresse stattfinden. Unter diesen Voraussetzungen arbeiten SOME/IP, SOME/IP-SD und ARP genauso wie in einem reinen Ethernet-Netzwerk (Bild 2)

Als zweiter Weg bietet es sich an, mit Hilfe eines passenden Gateways statt Ethernet Frames die IP Frames auf CAN XL zu routen. Das Gateway hat jetzt die Aufgabe, den IP Frame aus dem Ethernet Frame auszupacken. Mit Hilfe einer entsprechenden Routing-Tabelle im Gateway erkennt dieses anhand der eingebetteten IP-Adresse, dass es sich um ein Paket handelt, das in einen CAN XL Frame einzupacken und auf den CAN-XL-Bus zu routen ist. Auch hier ist wieder ein TCP/IP Stack auf Seiten des CAN-XL-Steuergerätes nötig. Beim CAN Interface sind nur kleinere Änderungen in der Implementierung notwendig, größere Änderungen sind im TCP/IP Stack zu erwarten. Zum Filtern bietet sich die im Frame eingebettete IP-Adresse an. Auch in diesem Szenario funktionieren SOME/IP und SOME/IP-SD genauso, wie in einem reinen Ethernet-Netzwerk (Bild 3).

Für die ersten beiden vorgestellten Wege lässt sich zusammenfassend sagen: SOME/IP-Funktionalität ist in beiden Fällen realisierbar. Das Routen von Ethernet Frames benötigt einen neuen CAN PHY am Standard Switch, während für den Software Stack auf den CAN-XL-Steuergeräten eine neue Zwischenschicht erforderlich ist. Auch beim Routen von IP Frames sind Änderungen im Software Stack notwendig. Logische Änderungen sind in den Softwaremodulen nicht notwendig, lediglich in der Implementierung sind Anpassungen notwendig. In beiden Fällen wäre eine Hardwarefilterung sinnvoll aber aufwändig zu realisieren.

Serviceorientierung auf CAN XL ohne TCP/IP

Eine dritte Lösungsmöglichkeit ist ganz auf den TCP/IP Stack zu verzichten. Die Motivation dafür ist darin begründet, weil sich so etwa 50...100 kB ROM Speicherplatz in jedem CAN-XL-Steuergerät einsparen lässt, was folglich die Nutzung von kleineren und günstigeren Controllern erlaubt. Dazu ersetzt im Software Stack ein neu eingeführter „SOME/CAN“ Layer die Module TCP/IP (TCPIP) und Socket Adaptor (SOAD). Der SOME/CAN Layer ist ein Vorschlag der Autoren und daher bei Marktinteresse noch ausführlicher zu spezifizieren und zu implementieren. Das Routen und die Umwandlung von SOME/IP in SOME/CAN geschieht im Gateway. SOME/IP Messages werden im PDU-Router-Modul umgewandelt. SOME/IP-SD Messages sind in der Applikation zu deserialisieren und korrespondierend als SOME/CAN Messages wieder zu serialisieren. Dabei ersetzt das Gateway die IP-Adresse und die Port-Nummer im SOME/IP-SD Header, zum Beispiel jeweils durch eine CAN ID, und kennzeichnet den Frame als „CAN XL Type“. Ein CAN XL Frame transportiert nun einen eingebetteten modifizierten SOME/IP Frame, der folgerichtig als „SOME/CAN Message“ zu bezeichnen ist. Während bei Ethernet SOME/IP-Teilnehmer auf einen dedizierten (UDP) Port hören, warten SOME/CAN-Teilnehmer auf spezielle SOME/CAN IDs. Ob es sich um eine SOME/CAN Message oder um Service Discovery handelt, wird im Header durch den Message Value angezeigt. Der Message Value mit dem Wert 0xFFFF 8100 kennzeichnet eine Service Discovery Message (Bild 4).

SOME/IP-Kommunikation lässt sich auf die gezeigte Weise ohne TCP/IP Stack auf CAN transformieren. Damit ist SOME/CAN machbar, jedoch angewiesen auf bestimmte Softwaremodule eines entsprechend erweiterten AUTOSAR Stack. Ein Filtern via Hardware ist deshalb ausgeschlossen.

Erweiterungen in Richtung Hardwarefilterung

Entwickelt man den SOME/CAN-Ansatz adäquat weiter, ist eine Hardwarefilterung doch noch praktikabel. Dazu erhält jeder Teilnehmer eine Knotenadresse. Die Knotenadresse erlaubt nun ein Filtern per Hardware. Weiter ist es in diesem Zusammenhang notwendig, Multicast- oder Broadcast-Adressen für das Service Offering bereitzustellen. Da zum Adressieren nun Knotenadressen dienen, muss das Gateway diese statisch mappen. Für ein dynamisches Mapping ist eine passende Address-Resolution-Lösung für CAN-Knotenadressen umzusetzen. Durch eine Knotenadresse sind Filterung und Netzwerkzugriff voneinander getrennt. Das heißt, die Priorität kann damit geändert werden, ohne dass eine Änderung an einem Teilnehmer erfolgen muss.

Der Beitrag stellt mehrere Optionen vor, wie sich mit CAN XL eine serviceorientierte Kommunikation verwirklichen lässt. Das Routen von Ethernet Frames und IP Frames ist vorstellbar, benötigt aber eine gute Möglichkeit der Hardwarefilterung, um effizient zu sein. Um kleinere und kostengünstigere Controller zu realisieren, wäre es sinnvoll die SOME/IP-Kommunikation unter Verzicht eines TCP/IP Stack auf CAN XL zu realisieren. Das Problem der frühen Hardwarefilterung lässt sich durch die Einführung einer Knotenadresse beseitigen, um Interrupt-Lasten zu vermeiden. In welche Richtung sich die serviceorientierte Kommunikation auf CAN XL genau entwickelt, ist im Detail noch offen. Dass Serviceorientierung auf CAN XL notwendig ist, zeigen die zu realisierenden Anwendungsfälle. Insgesamt ist CAN XL dafür gut gerüstet. (oe)

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

Bild 1: Ethernet-CAN-Netzwerk mit „CAN PHY“.

Dipl.-Ing. (FH) Oliver Garnatz ist seit 2000 bei Vector Informatik und arbeitet als Solution Manager im Bereich Embedded Software.

Bild 4: Serialisierung von SOME/IP in einem Stack mit neuem „SOME/CAN“ Modul.

Bild 2: Stack für eingebettete Ethernet Kommunikation über CAN XL.

Bild 3: Stack für eingebettete IP Kommunikation über CAN XL.

 Mit CAN XL können vorhandene Vernetzungskonzepte, Vernetzungstopologien und Kabelbäume ohne große Modifikationen weiterverwendet werden.

Dipl.-Ing. (FH) Peter Decker ist seit 2002 bei Vector  Informatik und arbeitet als CAN Product Manager im Bereich Networks and Distributed Systems.

Mikrocontroller für  Zonen-Steuergeräte

Die Komplexität der Funktionen im Fahrzeug nimmt zu, mit höherem Aufwand  bei der Verkabelung, der Absicherung und vor allem der Software-Integration.  Um diesen Anforderungen gerecht zu werden, bedarf es optimierter, software- orientierter E/E-Architekturen. Dieser Beitrag diskutiert die Auslegung dieser Architekturen mit einem besonderen Fokus auf die Zone-Controller-Unit (ZCU) sowie die Funktionalitäten der Aurix-Mikrocontroller von Infineon.

Die Komplexität der Funktionen im Fahrzeug nimmt zu, mit höherem Aufwand bei der Verkabelung, der Absicherung und vor allem der Software-Integration. Um diesen Anforderungen gerecht zu werden, bedarf es optimierter, software- orientierter E/E-Architekturen.

Fahrzeuge sind üblicherweise in funktionale Bereiche (Domänen) wie Karosserie, Fahrwerk, Antriebsstrang oder Infotainment gegliedert. Diese Domänen arbeiten normalerweise unabhängig voneinander mit spezifischen Security-, Safety- und Performance-Anforderungen. Steuergeräte in den Domänen sind über separate Bussysteme verbunden. Die aktuellen E/E-Architekturen mit Domänen-Controllern und einem zentralen Gateway haben sich über Jahre entwickelt, sind mittlerweile sehr komplex und machen mit einem Gewicht von bis zu 80 kg und einer gesamten Kabellänge von bis zu 5 km den drittschwersten Teil eines Fahrzeugs aus.

Der Zuwachs an Komplexität und Kabellänge hat nicht nur einen großen Einfluss auf die Kosten und den Arbeitsaufwand, sondern auch auf die Leistungsaufnahme und die Leistungsfähigkeit. Hinzu kommen Trends wie das automatisierte Fahren, die Elektrifizierung des Antriebsstrangs, Safety- und Security-Belange sowie eine Reduzierung des Energieverbrauchs. Mit ihnen steigt der Bedarf an neuen Aktuatoren und Sensoren, Datenverarbeitung, Daten-Bandbreiten, Netzwerk-Sicherheit, Redundanz, Rekonfigurierbarkeit und intelligenter Leistungsverteilung weiter an.

Domänen-basierten Architekturen mangelt es an Flexibilität und Modularität, wenn es darum geht neue Funktionen in die ECUs zu integrieren bzw. bestehende Fahrzeugfunktionen zu erweitern oder dynamische Konfigurationen zu ermöglichen. Darüber hinaus müssen immer mehr Fahrzeugfunktionen mit Sensordaten von verschiedene Domänen versorgt werden. Herkömmliche Architekturen sind jedoch nur schlecht für die Interaktion zwischen verschiedenen Domänen geeignet. Außerdem erfordern höhere Safety-Anforderungen eine Netzwerk-Redundanz, die mit bisherigen Konzepten schwer realisierbar ist. Skalierbare, zentralisierte und domänenübergreifende E/E-Architekturen sind hierfür deutlich besser geeignet. Vor diesem Hintergrund wurde die Idee einer Zonen-Architektur vorgestellt (Bild 1).

Die Zonen-Architektur stellt einen völlig neuen Ansatz im Vergleich zur herkömmlichen Domänen-Architektur dar: An die Stelle einer strikten funktionellen Partitionierung nach Domänen tritt eine räumliche Ausrichtung nach Fahrzeugbereichen wie Front, Heck, rechte und linke Seite. Funktionen verschiedener Domänen und mit verschiedener Kritikalität verteilen sich über mehrere ECUs und Netzwerke. So kann sich beispielsweise eine einzelne Funktion aus Teil-Funktionen zusammensetzen, die von verschiedenen ECUs ausgeführt werden. Wie in Bild 2 dargestellt, basieren typische Zonen-Architekturen auf drei verschiedenen ECU-Ebenen: Computing-Plattformen, Zone-Controller-Units sowie Sensoren, Aktuatoren und spezialisierten ECUs (Bild 2).

Bei Computing-Plattformen handelt es sich um SoC-basierte Steuereinheiten mit schnellen Schnittstellen, die als fahrzeuginterne Applikationsserver agieren und eine service-orientierte Architektur (SOA) unterstützen. Die Einheiten verfügen üblicherweise über mehrere spezifische SoCs (z. B. für Bild- oder Radar-Verarbeitung, KI, etc.) und sind voll skalierbar und aufrüstbar.

Zone-Controller-Units (ZCU) bilden die Verbindung zwischen den zentralen Computing-Plattformen und der mechatronischen Peripherie (bestehend aus Sensoren, Aktuatoren und spezialisierten ECUs). Außerdem fungieren sie in ihrer Fahrzeugzone zum Beispiel als lokales Gateway zwischen etablierten Automobilbussen (CAN, LIN, FlexRay) und dem Ethernet-Backbone. Sie sorgen für die Stromversorgung sowie die elektronische Absicherung und unterstützen alle Arten von Schnittstellen für Sensoren und Aktuatoren. Daneben stehen hoch spezialisierte ECUs, zum Beispiel für die Motorsteuerung, Getriebe oder Radar.