KPIT und ZF bilden eine Entwicklungskooperation für eine branchenführenden Middleware-Lösung
- Schließt die große Lücke bei der Verfügbarkeit einer ausgereiften, modularen, integrierten Middleware-Lösung, die es Mobilitäts-OEMs ermöglicht, die kontinuierlich wachsende Softwarekomplexität zu bewältigen und gleichzeitig die volle Kontrolle über die Architektur zu behalten.
- Basiert auf nachhaltige Investitionen von KPIT und ZF in Lösungen für "software-definierte Fahrzeuge".
- Durch die gemeinsame Entwicklung wird eine offene und skalierbare Plattform geschaffen, die von OEMs und Mobilitätskunden genutzt werden kann.
KPIT Technologies, ein führender unabhängiger Softwareentwicklungs- und Integrationspartner für die Automobil- und Mobilitätsindustrie, und die ZF Group, ein weltweit tätiges
Technologieunternehmen, das Systeme für PKW, Nutzfahrzeuge und Industrietechnik liefert, gaben bekannt, dass sie bei der Entwicklung einer branchenführenden Middleware-Lösung für das Mobilitäts-Ökosystem zusammenarbeiten werden.
Die stetig steigende Softwarekomplexität in Verbindung mit einer Hochleistungs-Computing-Infrastruktur erfordert eine robuste und zuverlässige Middleware-Lösung. Das Fehlen einer solchen Lösung kann die Fahrzeugentwicklung möglicherweise verzögern und die Technologieausgaben in die Höhe treiben.
Mit dem Software-Know-how von KPIT und dem fundierten Wissen von ZF über Fahrzeugsysteme entsteht eine ausgereifte, modulare Middleware-Lösung, die OEM-übergreifend eingesetzt werden kann und eine große Chance für das Mobilitäts-Ökosystem darstellt. Diese Kooperation bringt auch Lösungen anderer Technologieunternehmen an Bord, darunter Halbleiterspezialisten, Softwareunternehmen, Cloud-Dienste und Start-ups.
Die Middleware-Entwicklung wird auf die Erfahrung von KPIT in mehreren Produktionsprogrammen, die Expertise in Architekturberatung & Softwareintegration und seine Stärken bei Cloud-basierten vernetzten Diensten zurückgreifen und wird bestehenden Assets, Tools und Accelerators von KPIT sowie andere Kerninfrastrukturen nutzen.
Kishor Patil, CEO von KPIT Technologies, sagte: "Wir freuen uns sehr über die Zusammenarbeit mit ZF bei der Entwicklung einer branchenführenden Middleware-Lösung. Die OEMs sind an offenen und skalierbaren MiddlewareLösungen interessiert, die die Grundlage für die künftige Fahrzeuggeneration bilden und erhebliche Qualitäts- und Produktivitätsverbesserungen bringen können. Eine geeignete Middleware-Lösung hilft OEMs und unseren Mobilitätskunden beim Übergang zu einer soliden zentralen Computerarchitektur. Gemeinsam bringen wir Software-Know-how, Systemverständnis und Wissen über die Bedürfnisse von OEMs und Mobilitätskunden ein. Diese Entwicklungskooperation für Middleware-Lösungen wird unseren globalen Automobil- und Mobilitätskunden einen immensen Mehrwert bieten und die Entwicklungszyklen erheblich verkürzen."
"Die nächste Fahrzeuggeneration, die auf den Markt kommt, wird über elektrische Antriebe, einen hohen Automatisierungsgrad sowie Konnektivität verfügen und wird softwaredefiniert sein.", erklärt Dr. Dirk Walliser, SVP Corporate R&D, ZF Group. "Mit dem, was wir gemeinsam mit KPIT entwickeln, können wir unseren Automotive-Kunden noch umfassendere Softwarelösungen anbieten, die sich nahtlos in unser Systemportfolio für das softwaredefinierte Fahrzeug einfügen: High-Performance-Computing, Software, intelligente Sensoren und intelligente Aktoren."
Im Januar 2021 gründete ZF ein Global Software Center, das konzernweit für die Entwicklung von Softwaresystemen für zukünftige Architekturen zuständig ist. Ein Kernprodukt ist eine Automotive-Middleware, die als "Vermittler" zwischen dem Betriebssystem eines Fahrzeugcomputers und seinen Softwareanwendungen dient. Diese Entwicklung ist eng mit der Entwicklung von Anwendungssoftware für Mobilitätsbereiche wie automatisiertes Fahren, integrierte Sicherheit, Fahrzeugbewegungssteuerung und Elektromobilität verbunden.
Über ZF
ZF ist ein weltweit tätiges Technologieunternehmen, das Systeme für Pkw, Nutzfahrzeuge und Industrietechnik liefert und damit der nächsten Generation der Mobilität den Weg bereitet. ZF lässt Fahrzeuge sehen, denken und handeln. In den vier Technologiefeldern Vehicle Motion Control, Integrierte Sicherheit, Automatisiertes Fahren und Elektromobilität bietet ZF umfassende Produkt- und Softwarelösungen für etablierte Fahrzeughersteller und neu entstehende Verkehrs- und
Mobilitätsdienstleister. ZF elektrifiziert eine breite Palette von Fahrzeugtypen. Mit seinen Produkten trägt das Unternehmen dazu bei, Emissionen zu reduzieren, das Klima zu schützen und eine sichere Mobilität zu ermöglichen.
Im Geschäftsjahr 2020 erzielte ZF einen Umsatz von 32,6 Milliarden Euro. Das Unternehmen beschäftigt mehr als 150.000 Mitarbeiter an rund 270 Standorten in 42 Ländern.
Weitere Presseinformationen und Fotos finden Sie unter www.zf.com
KPIT ist ein führender unabhängiger Softwareentwicklungs- und Integrationspartner, der die Mobilität auf den Weg in eine saubere, intelligente und sichere Zukunft bringen will. Mit 7000 Automobelievers auf der ganzen Welt, die sich auf eingebettete Software, KI und digitale Lösungen spezialisiert haben, beschleunigt KPIT die Implementierung von Technologien der nächsten Generation für die zukünftige Mobilitäts-Roadmap. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit führenden Unternehmen der Automobil- und Mobilitätsbranche zusammen und ist dort präsent, wo sich das Ökosystem verändert. Weitere Informationen finden Sie unter www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Global Head, Marketing, KPIT Technologies
Telefon: +91 (98811) 36726
E-Mail: mohit.kochar@kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT will verstärkt in softwaredefinierte Fahrzeuglösungen investieren mit besonderem Schwerpunkt auf Middleware
- OEMs bewegen sich immer schneller auf eine zentrale Compute-Architektur zu und investieren in erheblichem Umfang, um die Entwicklungszyklen zu verkürzen
- KPIT entwickelt und verbessert Middleware-Technologien sowie Infrastrukturen, um den Kunden den Weg zu softwaredefinierten Fahrzeugen zu ebnen
- Die bewährte Softwareintegrationsexpertise von KPIT in den Bereichen Autonome, Elektrifizierung, Karosserieelektronik und vernetzte Fahrzeuge, ergänzt durch Architekturberatung, integrierte Tools und Infrastruktur, wird für diese Initiative von entscheidender Bedeutung sein.
- KPIT wird darüber hinaus zusammen mit Partnern ein Ökosystem aufbauen, um integrierte Lösungen für softwaredefinierte Fahrzeuge zu entwickeln
KPIT Technologies Ltd, ein führender unabhängiger Softwareentwicklungs- und Integrationspartner für die Automobil- und Mobilitätsindustrie, gab heute bekannt, dass das Unternehmen erhebliche Investitionen tätigen wird mit besonderem Schwerpunkt auf Middleware-Lösungen, um die Umstellung der Kunden auf softwaredefinierte Fahrzeuge sowohl im Pkw- als auch im Nutzfahrzeugsegment zu beschleunigen.
Das Kundenerlebnis im Fahrzeug wird entscheidend durch die Software bestimmt. Es wird immer wichtiger, Hardware und Software zu trennen, und die OEMs müssen Softwarelösungen über den gesamten Fahrzeuglebenszyklus hinweg entwickeln, einsetzen und aktualisieren.
Die OEMs bewegen sich schneller als erwartet auf eine Central-Compute-Architektur zu. Das Automobil-Ökosystem bemüht sich verstärkt um den Aufbau einer robusten und zuverlässigen Softwareplattform, die verschiedene Bereiche wie autonomes Fahren/ADAS, digitales Cockpit, elektrischer Antriebsstrang und Karosseriesteuerungsmodule unterstützen kann.
KPIT beabsichtigt, Technologien und Infrastrukturen zu entwickeln und zu verbessern, um OEMs und Tier-1-Unternehmen bei dieser großen Transformation der Fahrzeugarchitektur zu unterstützen. Den neuen Herausforderungen will KPIT mit Lösungen in den Bereichen Softwareintegration, Architekturberatung, Integration von Plattformkomponenten, integrierte Werkzeuge und CI/CT/CD*-Infrastruktur begegnen, um OEMs dabei zu helfen, die Zusammenführung verschiedener Komponenten zu beschleunigen.
Die Art und Weise, wie Software erstellt, getestet und in Fahrzeugen eingesetzt wird, wird sich erheblich verändern und global verteilte Teams sowie neue Sicherheitsstandards für die Cybersicherheit und die Sicherheit autonomer Fahrzeuge erfordern. Investitionen werden in der nahen Zukunft weiter erhöht, um spezifische Lösungen und Fähigkeiten zu entwickeln, die den sich ändernden Bedürfnissen entsprechen.
KPIT bietet heute ein breites Spektrum an technischen Lösungen an und verfügt über reiche Erfahrung bei der Unterstützung verschiedener Produktionsprogramme für seine Mobilitätskunden. Die neuen Investitionen von KPIT in Full-Service-Fähigkeiten, Plattformen, Tools und Beschleuniger ergänzen die bestehenden Software-Integrationskapazitäten in den Bereichen Autonomes Fahren, elektrischer Antriebsstrang, Connected Vehicle, Karosserieelektronik, AUTOSAR, Diagnose und OTA. Darüber hinaus arbeitet KPIT proaktiv mit seinen Partnern zusammen, um ein Ökosystem zu entwickeln und integrierte Lösungen zu schaffen, die OEMs und Tier 1s dabei helfen, ihren Transformationsprozess zu beschleunigen.
Kishor Patil, CEO von KPIT Technologies, sagt zu diesem wichtigen Meilenstein: „Das Hauptziel von KPIT bei dieser Schwerpunktsetzung ist es, unseren Kunden einen schnellen und nahtlosen Übergang zu einer Central-Compute-Architektur zu ermöglichen. Unsere Plattformen, Tools, Beschleuniger und Methoden bieten die Geschwindigkeit, die Bandbreite und die Unabhängigkeit, die OEMs benötigen. Wir freuen uns auf die Zusammenarbeit mit Partnern, um einen Beitrag für das Ökosystem zu leisten und den Übergang um mindestens ein Jahr zu beschleunigen.“
*CI/CT/CD – Continuous Integration/Continuous Testing/Continuous Delivery (Kontinuierliche Integration/kontinuierliche Prüfung/kontinuierliche Bereitstellung)
KPIT ist ein führender unabhängiger Softwareentwicklungs- und Integrationspartner, der die Mobilität auf den Weg in eine saubere, intelligente und sichere Zukunft bringen möchte. Mit 7000 Automobelievers auf der ganzen Welt, die sich auf eingebettete Software, KI und digitale Lösungen spezialisiert haben, beschleunigt KPIT die Implementierung von Technologien der nächsten Generation für die zukünftige Mobilitäts-Roadmap. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit führenden Unternehmen der Automobil- und Mobilitätsbranche zusammen und ist dort präsent, wo sich das Ökosystem wandelt. Weitere Informationen finden Sie unter www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Verdeckte Schwachstellen erkennen und ausmerzen
Heutzutage integriert die Automobilindustrie zahlreiche neue Funktionen in vernetzte Fahrzeuge, und es gibt eine zunehmende Interaktion zwischen verbundenen ECUs über bordeigene Kommunika tionsprotokolle. Dieser enorme Datenfluss muss im Sicherheitskontext validiert werden, um zu überprüfen, ob irgendwelche potenziellen Schwachstellen zu Beeinträchtigungen bei Kernfunktionen führen können. Um diese Echtzeit-Schwachstellen über das CANUDS-Protokoll zu finden, wird ein Black-Box-Fuzz-Testing-Ansatz genutzt. Die zentrale Idee beim Fuzzing ist die Entwicklung eines Fuzzers. Er besteht aus einer positiven Testsuite sowie veränderten Kriterien und Fuzzing-Kriterien. Zudem generiert und liefert er ungültige Eingaben an das zu testende System (SUT). Das Verhalten des SUT wird überwacht und Anomalien werden gemeldet.
Mit Fuzzing lassen sich Schwachstellen an verschiedenen Schnittstellen und Steuergeräten (Electronic Control Units, ECUs) auffinden. Der Prozess umfasst das Abrufen der IDs und Sitzungen vom SUT, um das Fuzzing durchzuführen. Anschließend wird eine positive Testsuite mit gültigen CAN-Nachrichten erstellt. Die gültigen Eingabeaufforderungen werden weiter verändert, dem SUT werden veränderte Eingaben vorgelegt, und seine Reaktionen werden auf Abstürze oder Unterbrechungen analysiert. Durch ungültige Eingaben an das System wird das Verhalten der ECU beobachtet. Auf diese Weise werden fehlerhafte Antworten der ECU gefunden und gemeldet. Diese Anfragen und Antworten werden in einer Datei gespeichert und analysiert.
UDS – ISO 14229
Der Standard Unified Diagnostic Services (UDS), auch als ISO 14229 [1] bekannt, ist eine in Straßenfahrzeugen verwendete Anwendungsprotokollschnittstelle für die Diagnose, Fehlerbehebung und Konfiguration von ECUs. UDS definiert, wie Nachrichten zu formatieren sind, nicht jedoch, wie sie zu implementieren sind – obwohl der Standard einige bewährte Verfahren vorschlägt. Daher handelt es sich um eine Schnittstelle. Bild 1 zeigt die Struktur und die Arten von Diagnosemeldungen. Der UDSClient ist im Allgemeinen ein an einen Fahrzeugdiagnose-Port anzuschließendes Prüfgerät. Der UDS-Server ist im Allgemeinen ein Gerät oder eine elektronische „Name of ECU“-Steuereinheit (ECU) im Fahrzeug, die mit dem CANBus verbunden ist – zugänglich über den Diagnose-Port.
Jede Funktion des Standards ist innerhalb des Konzepts eines Dienstes gruppiert. Ein Dienst ist eine Anfrageart, die einige Parameter aufweist. Hier einige Beispiele, wie Funktionen in Service-Kennungen gruppiert sind:
- ECU Reset – 0x11
- Diagnostic Session Control – 0x10
- Tester Present – 0x3E
- Read Data by identifier – 0x22
Diese Services können spezifische Unterfunktionen aufweisen. So hat zum Beispiel der Dienst „ECU Reset“ eine Unterfunktion, die die Art der Rücksetzung beschreibt, die der Client durchführen möchte. Das kann ein harter Reset (Einschaltzyklus) oder ein softer Reset (Neustart der Firmware) sein. Die Unterfunktion ist das erste Byte der Dienstnutzlast, und ihr Wert wird durch UDS definiert. Wie der Server eine Rücksetzung auslöst, wird nicht von UDS definiert und bleibt dem Server-Programmierer überlassen.
Beim Herstellen einer Verbindung mit einem Server verfügt der Client über eine Sitzung und eine Sicherheitsstufe. In der Voreinstellung weist der Server den Client der „Standardsitzung“ zu, in der nur einige wenige spezifische Dienste zugänglich sind, wie etwa das Auslesen der Diagnosefehler-Codes (DTCs). ISO 14229 definiert vier Sitzungstypen und definiert die Liste der verfügbaren Dienste – aber nur für die Standardsitzung. Mit anderen Worten, der ECU-Hersteller entscheidet, welche Dienste für jede Sitzung verfügbar sind, mit Ausnahme der Standardsitzung. Ein Client kann mit dem Dienst Diagnostic -SessionControl ohne Einschränkungen auf jede Sitzung wechseln. Der ECUHersteller kann 32 zusätzliche Sitzungen definieren.
Die Sicherheitsstufe ist ein Status, den der Client durch Freischalten von Funktionen im Server mittels Sicherheitsschlüssel erreicht. Die UDS-Auslegung erlaubt bis zu 64 Sicherheitsstufen, die letztendlich im Server gesetzte Boolesche Flags sind. Diese Sicherheitsstufen und was sie freischalten, wird nicht von UDS definiert, sondern vom Hersteller der ECU. Eine Sicherheitsstufe kann einen kompletten Dienst, eine Unterfunktion oder den Zugriff auf einen spezifischen Wert freischalten. So setzt zum Beispiel das Schreiben der Fahrgestellnummer (VIN) möglicherweise eine spezifische Sicherheitsstufe voraus, die sich von dem unterscheidet, was zum Schreiben der Höchstgeschwindigkeit oder zum Überschreiben der Fahrzeug-IOs erforderlich ist.
In der Standardsitzung ist das Freischalten von Sicherheitsstufen nicht zulässig. Um einige Privilegien zu gewinnen, muss der Client zunächst auf eine Nicht-Standardsitzung schalten, die den SecurityAccess-Dienst aktiviert. Nur dann kann der Client den Handshake ausführen, der die gewünschte Funktion freischaltet. Im Allgemeinen laufen erlangte Privilegien nach einem kurzen vom ECU-Hersteller definierten Zeitraum ab. Eine Keep-Alive-Nachricht hält die Sicherheitsstufe freigeschaltet und die Sitzung aktiv, wobei diese Keep-Alive-Nachrichten mit dem Dienst TesterPresent versendet werden.
Die zum Freischalten einer Sicherheitsstufe zu sendende Nutzlast ist nicht von UDS definiert: UDS definiert die Vorgehensweise beim Schlüsselaustausch. Dieser Prozess basiert auf zwei Anfrage/Antwort-Austauschvorgängen zwischen Client und Server. Er geht wie folgt vonstatten:
- Zunächst fragt der Client ein Seed an, um eine spezifische Sicherheitsstufe, die durch eine Nummer gekennzeichnet ist, freizuschalten. Dieses Seed ist im Allgemeinen ein Zufallswert, den der Client verwenden muss, um den Schlüssel zu berechnen. Damit soll verhindert werden, dass jemand den Nachrichtenaustausch des CAN-Busses aufzeichnet und sich dann Privilegien durch unbesehenes Zusenden der Aufzeichnungen verschafft. Kryptografisch gesehen ist das Seed eine Nonce zur Vermeidung von Replay-Angriffen.
- Sobald der Client das Seed erhält, muss er einen Schlüssel berechnen, indem er einen Algorithmus verwendet, der vom ECU-Hersteller definiert wurde und dem Server bekannt ist.
- Der Client sendet den Schlüssel dann an den Server, der Server überprüft ihn und wenn er zum Server-Wert passt, wird die Sicherheitsstufe freigeschaltet, und der Client erhält eine positive Nachricht.
Der Sicherheitsalgorithmus kann ein beliebiger Algorithmus sein. Der Mangel an Algorithmusdefinition im UDS-Standard lässt einigen Raum für gute Sicherheitskonzepte, aber auch für schlechte – es hängt ganz vom Hersteller ab. In der Tat nutzen einige Hersteller das Konzept „Sicherheit durch Verschleierung“, während sich andere für ein robusteres Pre-Shared-Key-Schema entscheiden.
Prozessablauf
Ziel dieses Experiments war die Verallgemeinerung des Fuzzer-Algorithmus, sodass er für alle ECUs zum Einsatz kommen kann, die UDS über CAN gemäß UDS-Protokoll nutzen [1]. Weil ein Black-Box-Fuzzing durchgeführt wird, bekommt man ein Grundverständnis des Systems. In der Erkundungsphase hat sich KPIT mit dem Systemverständnis beschäftigt. Darauf folgte die Erstellung einer positiven Testsuite auf der Grundlage der Ergebnisse der Erkundungsphase. Es wurde eine Änderung umgesetzt, und die Ausgaben wurden auf der Basis eines Satzes von Kriterien klassifiziert. Des Weiteren wird jede Phase des Fuzzings im Detail erläutert. Bild 2 stellt einen Fuzzing-Prozess dar.
Zu testendes System
Der Prozess begann mit der Identifizierung des UDS über CAN-Ports/OBD-IIPorts, gefolgt von einer Hardware-Konfiguration. Für diese wurde die korrekte Spannung bereitgestellt und das SUT unter Verwendung eines USB-2-CAN-Protokollkonverters mit dem Laptop verbunden. Um Kriterien, Überwachung, Veränderung und Analyse der Pakete festzulegen, wurden CAPL-Skripts entwickelt.
Erkundung
Für eine erfolgreiche Durchführung des Fuzzings (Bild 2) ist es sehr wichtig, die diagnostische Arbitrierungs-ID zu finden. Die Feststellung der Arbitrierungs-ID ist ein wichtiger Schritt zur Kommunikation mit der ECU per Diagnose über CAN. Dazu wurde ein CAPL-Skript zur Identifizierung der Arbitrierungs-ID entwickelt. Das CANoe-CAPL-Skript spielt mit dem 8-Byte-Datenfeld des CANFrames. Das Arbitrierungs-ID-Feld der Reihe wird nach auf bis zu 11 Bit für den Standard-CAN-Frame geändert – dabei bleiben andere Datenfelder konstant. Auf ähnliche Weise werden die in den ECUs implementierten Dienste, die Dienst-IDs und die Unterfunktions-IDs festgestellt.
Positive Testfallgenerierung und Definition von Fuzzing-Kriterien
Zu diesem Schritt gehört die Erstellung gültiger UDS-Anfragen. Zu diesem Zweck wurde der UDS-Protokollstandard [1] und den UDS über CAN-Standard [2] untersucht. Damit werden Unified-Diagnostic-Services-Anforderungen für die Anwendungsschicht definiert. Diese ISO wurde untersucht und man hat eine positive Testsuite erstellt. Die positive Testsuite wird automatisch vom Fuzzer generiert. Der Algorithmus generiert automatisch eine positive Testsuite, mit der das Verhalten der ECU beobachtet und Fuzzing-Kriterien definiert werden.
Systematische Veränderung in CAN-Paketen
Mutationsbasiertes Fuzzing ist ein effektiver Ansatz zur Verbesserung der Sicherheit und Zuverlässigkeit von Protokollimplementierungen. Der Änderungsbasierte Fuzzer arbeitet mit gültigen Daten und wendet zufällige Veränderungen darauf an. Mit dieser Technik lässt sich tief in die Nachrichtenverarbeitung am Ziel eindringen. Die gültige Eingabeaufforderung wird verändert. Veränderte Eingaben werden dem SUT vorgelegt und die Reaktionen des SUT werden auf Abstürze oder Unterbrechungen analysiert. Durch ungültige Eingaben an das System wird das Verhalten der ECU beobachtet. Auf diese Weise werden fehlerhafte Antworten der ECU gefunden und gemeldet. Diese Anfragen und Antworten werden in einer Datei gespeichert und analysiert. Während der Analyse wird eine generierte Liste anfälliger Nachrichten hervorgehoben. Ein Nachrichtenlängen-Byte, ein Unterfunktions- Byte mit und ohne gesetztem SPR-Bit und ein Datenlängencode (DLC) wurden verändert. Ebenso wurden Änderungen an Diensten ohne Unterfunktion durchgeführt. Dieser Prozess wird auf Dienste sowohl in Standard- als auch in Nicht-Standardsitzungen angewendet. Der Grund dafür ist, dass einige Dienste in Standardsitzungen und einige in Nicht-Standardsitzungen implementiert sind.
Versuchsaufbau
Die Einrichtung besteht aus dem zu testenden System (SUT). Bild 3 zeigt einen Versuchsaufbau für das Fuzzing. Damit wurde ein Fuzzing an mehreren ECUs von Drittanbietern durchgeführt. Das SUT ist mit der Vector-CAN-Schnittstelle verbunden. Diese ist an den PC angeschlossen, der als Prüfgerät fungiert. Die Fuzzer-Skripts werden mit CANoe-CAPL auf dem PC ausgeführt.
Datenanalyse-basierte Algorithmen
Am Ende des Fuzzing-Prozesses wird eine Liste von Sicherheitslücken erstellt, bei denen es sich um Antworten handelt, die weder negativ noch positiv gemäß ISO 14229–1 sind. Das wird durch Entwicklung Datenanalyse-basierter Algorithmen für das Berichtsmodul erreicht. Der Algorithmus wendet Datenanalysetechniken auf die positive Testsuite und ECU-Antwort an, um Anomalien festzustellen, die dann in einer Excel-Tabelle berichtet werden. Alle gültigen Antworten werden ebenfalls protokolliert, und die Anomalien werden hervorgehoben. Bild 4 zeigt die gelb hervorgehobenen Anomalien. Der Bericht besteht aus Arbitrierungs-ID, Sitzungen, der mutierten Nutzlast und dem DLC sowie dem Ergebnis. (eck)
Quellenverzeichnis
[1] Straßenfahrzeug – Einheitliche Diagnosedienste (UDS) ISO 14229–1, ISO 14229–1, 2013.
[2] Straßenfahrzeuge – Diagnosekommunikation über Controller Area Network (DoCAN) – ISO 15765 Teil 2, 2004.
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT als Leader gelistet in der Everest Group PEAK-Matrix Bewertung für autonome, vernetzte, elektrische und shared mobility (ACES) Automotive Engineering Services 2021
- Das Leader-Ranking ist Audruck der weitreichenden Visionen und Fähigkeiten von KPIT und seiner Marktstellung
- Die Bewertung umfasste 23 Unternehmen aus der Mobilitätsbranche, die als Leader, Hauptakteure oder Aspiranten eingestuft wurden
- Die Leader-Bewertung unterstreicht unsere Vision, die Mobilität für eine sauberere, intelligentere und sicherere Welt zusammen mit dem Ökosystem neu zu denken und zu gestalten
KPIT Technologies, führender unabhängiger Softwareentwicklungs- und Integrationspartner für die Automobil- und Mobilitätsindustrie gibt bekannt, dass es in der PEAK-Matrix-Bewertung der Everest Group für autonome, vernetzte, elektrische und shared mobiliy (ACES) im Bereich Automotive Engineering Services 2021 als Leader klassifiziert wurde.
Dieses jährliche Assessment durch die Everest-Gruppe bewertet globale Engineering-Unternehmen objektive nach der Gesamtfähigkeit und Marktbedeutung. KPIT ist unter den 23 in dieser Studie bewerteten globalen Engineering-Unternehmen als Leader eingestuft worden.
Gewürdigt wurde bei der Bewertung die Vision und die Umsetzungsfähigkeiten von KPIT bei der weltweiten Implementierung der Technologien der nächsten Generation (ACES) für die Automobil- und Mobilitätsindustrie. KPIT arbeitet mit führenden Unternehmen der Mobilitätsbranche auf der ganzen Welt zusammen und sorgt für Skalierbarkeit und Verlässlichkeit bei der Entwicklung und Integration von Softwarefunktionen, um so die Softwareentwicklung vom Prototyp bis zur Produktion zu beschleunigen.
Die Bewertung hebt Bereiche und Domänen hervor, in denen KPIT mit Automobil-OEMs und Tier1-Unternehmen zusammenarbeitet wie z.b.: Autonomes Fahren und ADAS; Elektrifizierung und konventioneller Antriebsstrang; eCockpit und Konnektivität; gemeinsame Middleware für neue E/E-Architekturen (AUTOSAR, Cybersicherheit, OTA); Fahrzeugdiagnose und neue Fahrzeugtechnik und -design.
Sachin Tikekar, Präsident und Board Member, KPIT Technologies sagte: Wir fühlen uns geehrt und in unserer Arbeit bestärkt, dass wir in der PEAKMatrix- Studie der Everest-Gruppe als LEADER eingestuft wurden. Durch unseren Fokus auf Automotive und Mobility und die Zusammenstelllung verschiedener Bausteine in den letzten 20+ Jahren sind wir in einer idealen Position, um den Wandel zu begleiten und zu meistern. Die sorgfältige Studie und das Ranking der Everest-Gruppe geben ein klares Bild des MobilitätsÖkosystems und bieten einen guten Anhaltspunkt."
Akshat Vaid, Vice President der Everest Group, bemerkte: "KPIT hat seine globale Präsenz und Investitionen in Softwareentwicklungszentren an Standorten wie Pune, Bangalore, Detroit und München erfolgreich genutzt, um mit führenden OEMs und Tier-1-Unternehmen an ACES-Themen zu arbeiten. Sie haben starke Kompetenzen in den Bereichen Elektro- und Hybridantriebe, Ladesysteme und Leistungselektronik, Sensorfusion Algorithmen und assistiertes Fahren innerhalb der Elektromobilität und des autonomen Fahrens entwickelt. Das Unternehmen bietet Fähigkeiten in der Entwicklung von Embedded-Architekturen und Software-Stacks, ein zuverlässiges V&V-Setup und proprietäre Lösungen rund um HMI, Middleware-Komponenten, Konnektivität und autonome Plattformen. Der Kunde schätzt den Fokus von KPIT auf Qualität ohne Fehler bzw. minimale Nacharbeit sowie starke Projektmanagementfähigkeiten."
KPIT ist ein führender unabhängiger Softwareentwicklungs- und Integrationspartner, der die Mobilität auf ihren Weg in eine saubere, intelligente und sichere Zukunft unterstützt. Mit 7000 "Automobelievers" auf der ganzen Welt, die sich auf eingebettete Software, KI und digitale Lösungen spezialisiert haben, beschleunigt KPIT die Implementierung von Technologien der nächsten Generation für die zukünftige Mobilitäts-Roadmap. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit führenden Unternehmen der Automobil- und Mobilitätsbranche zusammen und ist dort präsent, wo sich das Ökosystem verändert. Weitere Informationen finden Sie unter www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT tritt dem Autonomous Vehicle Computing Consortium bei, mit dem Ziel Erkenntnisse und Expertise bei der Softwareentwicklung für autonomes Fahren beizusteuern
- KPIT schließt sich mit führenden Unternehmen aus der Mobilitätsbranche zusammen, um Best Practices in die Entwicklung komplexer Software für autonomes Fahren einzubringen
- KPIT bringt umfangreiche praktische Erfahrungen in der Entwicklung von Produktionssoftware für autonomes Fahren mit
- Das Konsortium bemüht sich darum, die besten Lösungen für kritische Hardware- und Software-Plattformen zu finden
KPIT Technologies, ein führender unabhängiger Softwareentwicklungs- und Integrationspartner für die Automobil- und Mobilitätsindustrie, hat seinen Beitritt zum Autonomous Vehicle Computing Consortium™ (AVCC) bekanntgegeben. Dies ist Ausdruck unseres Bestrebens, gemeinsam mit anderen weltweit führenden Unternehmen der Mobilitätsbranche den Weg in die Zukunft des autonomen Fahrens anzuführen.
KPIT schließt sich führenden OEMs, Tier 1s und Halbleiterunternehmen wie GM, Toyota, Subaru, Veoneer, ARM, Bosch, NXP, Renesas als Mitglied des AVCC an, um gemeinsam mit ihnen an der Technologie für das autonome Fahren zu arbeiten.
AVCC ist ein globaler Zusammenschluss von führenden Automobil- und Technologieunternehmen, das sich auf computerbasierte Lösungen für automatisiertes und assistiertes Fahren konzentriert. Die Art und Weise, wie autonome Fahrlösungen entwickelt werden, ändert sich sowohl aus der Hardware- als auch aus der Software-Perspektive rasant. Die Rolle von Halbleitern, Middleware, Betriebssystemen und vor allem eingebetteter Software ist einem Wandel unterworfen. AVCC hilft, Unternehmen zusammenzubringen, die in diesem Bereich stark engagiert sind, um Lösungen für die Zukunft zu diskutieren und zu entwickeln.
KPIT arbeitet seit mehr als einem Jahrzehnt an der Entwicklung von Advanced Driver Assistance Systems (ADAS)/ Autonomous Driving (AD) und über 50 Fahrzeugproduktionsprogrammen und möchte seine wichtigen Erkenntnisse über Software-Architekturen, Plattformen und Komponenten diesem Konsortium zur Verfügung stellen.
Anup Sable, CTO, KPIT Technologies, sagte: „Wir sind seit vielen Jahren am Makrt aktiv und investieren seit über einem Jahrzehnt in ADAS- und ADSoftware- Kompetenzen. Deshalb haben zahlreiche OEMs und Tier 1 Unternehmen uns als strategischen Partner bei der Entwicklung autonomer Fahrzeuge der Zukunft ausgewählt. AVCC bietet uns ein großartiges Forum, um Einblicke zu geben und Erfahrungen auszutauschen, speziell im Bereich Software, Middleware und AUTOSAR."
Giuseppe Rosso, AVCC-Vorsitzender, sagte: „AVCC ist hocherfreut, KPIT im Konsortium begrüßen zu dürfen. Wir schätzen die Expertise von KPIT im Bereich ADAS/AD-Fahrzeuge sehr, und das Konsortium freut sich auf wertvolle technische Beiträge zu den Arbeitsgruppen und den allgemeinen AVCC-Aktivitäten."
Über AVCC
Das Autonomous Vehicle Computing Consortium, Inc.™ (AVCC) ist eine globale gemeinnützige Organisation von führenden Unternehmen der Automobil- und Technologiebranche, die sich zusammengeschlossen haben, um die Massenproduktion von sicheren und erschwinglichen Fahrzeugen mit assistiertem Fahren und autonomer Technologie (Level 1-5) zu beschleunigen. AVCC definiert eine skalierbare Referenzarchitektur und – plattform, die es ermöglicht, die Ziele des assistierten und autonomen Fahrens innerhalb der Leistungs-, Wärme- und Größenbeschränkungen eines Fahrzeugs zu realisieren. Diese Computing-Plattform wird speziell entwickelt, um die heutigen AV-Prototypsysteme im großen Maßstab zum Einsatz zu bringen. Das Konsortium arbeitet auch an der Entwicklung von Standards für die Architektur der Compute-Plattform unter Berücksichtigung der Hardware-Anforderungen und Software-APIs für die Bausteine in autonomen Fahrzeugsystemen. www.avcconsortium.org
KPIT ist ein führender unabhängiger Softwareentwicklungs- und Integrationspartner, der dazu beitragen möchte, die Mobilität in eine saubere, intelligente und sichere Zukunft zu führen. Mit 7000 "Automobelievers" auf der ganzen Welt, die sich auf eingebettete Software, KI und digitale Lösungen spezialisiert haben, beschleunigt KPIT die Implementierung von Technologien der nächsten Generation für die zukünftige Mobilitäts-Roadmap bei seinen Kunden. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit führenden Unternehmen der Automobil- und Mobilitätsbranche zusammen und ist dort präsent, wo sich das Ökosystem verändert. Für weitere Informationen besuchen Sie [url=http://www.kpit.com]www.kpit.com[/url]
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Anforderungen für erfolgreiche Projekte
Warum ist die Software-Industrialisierung die zentrale Herausforderung für AD-Produktionsprogramme der Stufen 2 und 4, und wie lässt sie sich umsetzen?
In den letzten Jahren gab es großes Interesse für autonomes Fahren (AD) in der Nutzfahrzeugbranche. ADAS und autonome Fahrtechnologien (AD) von Nutzfahrzeugen (CVs) haben das Potential, die Kosten zu verbessern und die Sicherheit zu erhöhen. Diese Business Cases für autonome Nutzfahrzeuge wurden bereits bewiesen. Die CV-Branche zielt jetzt auf Modelle mit Funktionen wie Hub-to-Hub-Fahren, Highway Pilot mit Level-2- und späteren Level 4-Funktionen für Produktionsprogramme ab. Um die Markteinführung autonomer Nutzfahrzeuge (CV, Commercial Vehicle) zu beschleunigen, arbeiten CV-OEMs mit AD-Plattformanbietern wie Torc Robotics, Tu Simple, Aurora, Gatik und Anderen zusammen. Im Rahmen dieser Zusammenarbeit beziehen die OEMs die Software und in manchen Fällen die Hardwareplattform von dessen Plattformanbietern. Die Kontrolle über die Gesamtsystemintegration sowie die Einhaltung von ISO 26262 und der Homologationsanforderungen müssen jedoch bei den OEMs liegen.
Durch das Fehlen von Erfahrungen mit Nutzfahrzeugherstellern für autonome Software und die mangelnden Erfahrungen mit Plattformanbietern bei der Entwicklung von Produktionssoftware und -hardware für sicherheitskritische Systeme entsteht jedoch eine Lücke.
In einem Financial-Times-Interview im Januar 2021 betonte der damalige CEO von Waymo die Tatsache, dass die Umstellung vom Prototyp auf eine sichere produktionsbereite Plattform Erfahrung in den Bereichen Domain, Sicherheit, Simulation und Integration erfordert. Die Plattformsoftware zur Produktionsreife zu bringen und dabei alle Sicherheits- und Regulierungsanforderungen zu erfüllen, ist ein extrem komplexer Vorgang. Sicherheitskritische ADAS- und AD-Software reif für die Produktion zu machen, erfordert ein fundiertes Fachwissen und Erfahrung.
Daher besteht im Nutzfahrzeug-Ökosystem Bedarf für die Zusammenarbeit mit einem "Industrialisierungspartner", der über entsprechende Kompetenz verfügt. Dieser Beitrag stellt Methoden und Best Practices der Software-Industrialisierung für Sicherheitssysteme vor. In ADAS- und AD-Programmen gilt es, die in Bild 1 aufgelisteten Faktoren zu berücksichtigen. Jeder der in Bild 1 erwähnten Punkte umfasst Faktoren, die sich nur aus einem vollständigen Produktionsprogramm heraus verstehen lassen.
Einhaltung von ASPICE- und ISO-Prozessen
Im Allgemeinen konzentrieren sich Plattformanbieter auf die Entwicklung von ADAS- und AD-Funktionen sowie die Erstellung prototypfähiger Lösungen. Diese Lösungen werden dann am Konzeptfahrzeug in kontrollierter Umgebung auf der Straße demonstriert. Bei der Entwicklung dieser Prototypen werden die ASPICE- und ISO-Prozesse nicht befolgt, aber während der Produktionsphase ist es unerlässlich, einen maßgeschneiderten Prozess anzuwenden, alle Dokumentationen einzuhalten und zusätzlich die Entwickler zu schulen, um eine strikte Umsetzung beziehungsweise Einhaltung sicherzustellen.
Ein Software-Industrialisierungspartner übernimmt diese Aufgabe auf dem Weg vom Prototyp zur Produktion, wo er sicherheitskritische Prozesse einführt, die ASPICE als Basisprozess betrachten und alle erforderlichen Prozesse aus ISO 26262, ISO 15288 und anderen Prozessen zusammenführt. Die Implementierung des Prozesses muss dann auch an ein agiles Betriebsmodell angepasst werden. KPIT bietet maßgeschneiderte Prozesse und hat den ISO-Prozess in einer agilen Umgebung bereits umgesetzt.
Die zentrale Bedeutung der Prozessumsetzung liegt nicht in der Prozessdefinition, sondern in der Prozesseinhaltung. Der in Bild 2 erwähnte Prozess wurde unter Berücksichtigung des Selbsterklärungsaspekts und der mit dem Prozess verbundenen Schulung entwickelt. Jeder Entwickler soll dadurch verstehen, was er in der Software tun muss, um den Sicherheitsprozess einzuhalten.
Systementwicklung und -anforderungen
Die Systementwicklung ist ein wichtiger Bestandteil beim Aufbau sicherheitskritischer Systeme. Die Luft- und Raumfahrtindustrie, die ebenfalls sicherheitskritische Systeme für autonomes Fahren erstellt, folgt dem Systementwicklungsprozess bereits in der Konzeptphase mit größter Sorgfalt. Bei der Entwicklung von ADAS und AD ist zu beobachten, dass sich die Entwickler in der Konzeptphase auf die Erprobung des Konzepts in einem Fahrzeug konzentrieren und Systementwicklung, Festlegung von Detailanforderungen sowie Architekturentwicklung für die Folgephasen der Entwicklung vorgesehen sind.
Daher wird es während der Produktionsphase sehr wichtig, die Systemarchitektur sowie die logische und die physische Softwarearchitektur zusammen mit den System-, Software- und Hardwareanforderungen zu erfassen. Zu beachten ist auch, dass die Anzahl der Anforderungen in die Zehntausende geht und sehr große Aufwendungen in Kombination mit umfangreichen Fachkenntnissen erfordert.
KPIT folgt einer Drei-Ansichten-System-Engineering-Methodik, die Skalenexpertise zur Entwicklung von Architektur und Anforderungen mit einer umfangreichen Bibliothek von Artefakten bietet, die Zeit- und Kosteneinsparungen im Programm erzielen.
Umsetzung von ISO 26262 in Prozess, System, Software und Validierung
Die Implementierung der funktionalen Sicherheit gemäß ISO 26262 ist ein Schlüsselfaktor. Beginnend mit dem Sicherheitsprozess sind eine Reihe von Sicherheitsanalysen auf System-, Software- und Hardwareebene durchzuführen.
– Funktionssicherheitskonzept (FSC)
– Gefahren- und Risikoanalyse (HARA)
– Technisches Sicherheitskonzept (FSC)
– Fehlermöglichkeits- und Einflussanalyse (FMEA)
– Fehlerbaumanalyse (FTA)
Neben diesen Aktivitäten sind auch detaillierte Sicherheitsanforderungen Teil der Produktionsphase.
– Anforderungen an die funktionale Sicherheit (FSR)
– Technische Sicherheitsanforderungen (TSR)
– Software-Sicherheitsanforderungen (SSR)
– Hardware-Sicherheitsanforderungen (SSR)
Neben den oben genannten Sicherheitsaktivitäten ist auch die Sicherheitsvalidierung von entscheidender Bedeutung. Es erfordert umfassende Domänenerfahrung und spezielles Fachwissen zum Ableiten von Testfällen anhand von Sicherheitsanforderungen und zum Durchführen von Fehlerinjektionstests sowohl für die Anwendungs- als auch für die Middleware-Software. Die Sicherheit der vorgesehenen Funktion (SOTIF) ist ein weiterer wichtiger Bereich, der in der Produktionsphase zu berücksichtigen ist. KPIT stellt fertig entwickelte Testfallbibliotheken und SOTIF-Szenarien bereit, mit denen sich bei der Produktion Zeit einsparen lässt. Das Unternehmen hat umfassende Engineering- Services für die Umsetzung von ISO 26262 sowie eine Reihe von Beschleunigern anzubieten, mit denen sich Zeit und Kosten optimieren lassen.
Software-Refactoring und -Industrialisierung, insbesondere für Komponenten der KI
Die zentralen Herausforderungen bei ADAS- und AD-Programmen der Stufe 3+ sind der Reifegrad sowie die Qualität der Funktionen und der Algorithmen. In der Prototypenphase findet die Feature-Validierung in einer kontrollierten Umgebung statt.
Daher ist es von entscheidender Bedeutung, die Funktionsreife der Software während der Produktion zu erreichen.
Reifegrad und Qualität werden durch Refactoring und Optimierung des Codes erzielt. Der Code muss MISRA, Standards für funktionale Sicherheit und anderen Richtlinien entsprechen und auch die Grundlagen einer Embedded Umgebung befolgen.
Da die meisten der Algorithmen und Funktionen Modelle künstlicher Intelligenz (KI) enthalten, wird das Refactoring des Codes zu einer Herausforderung. Die Schwierigkeit liegt dabei eher in der Neuartigkeit, weil dies eine der ersten Anwendungen ist, bei denen künstliche Intelligenz für sicherheitskritische Anwendungen zum Einsatz kommt und es keine bewährten Methoden gibt, diese einsatzbereit für die Produktion zu machen. KPIT hat eine robuste und praxisbewährte KI-Industrialisierungsmethodik entwickelt.
Softwareintegration und -leistung in der Multicore-Plattform
Nach dem Software-Refactoring ist der nächste wichtige Schritt die Optimierung des Codes, damit er erstens auf der gewünschten eingebetteten Plattform und zweitens mit der gewünschten Geschwindigkeit ausgeführt wird. Dabei bestimmt die Reaktionszeit von der Erfassung bis zur Betätigung die Leistung des gesamten ADAS- und AD-Systems; diese Reaktionszeit hängt von der Qualität, dem Reifegrad und der eingebetteten Implementierung des Codes ab. Während der Implementierung des Prototyps erfolgen Tests von Funktionen oder Algorithmen nur als einzelne Komponenten, so dass die Reaktionszeit in diesem Fall nicht sonderlich kritisch ist.
In der Produktionsphase jedoch kommen Middleware-Komponenten wie Autosar, Adaptive Autosar und Sicherheitskomponenten hinzu, um den Stack zu komplettieren.
Das Erreichen der gewünschten Mikrosekunden- Anforderungen in Bezug auf die Antwortzeit hängt zum einen davon ab, wie der Code beim Refactoring optimiert wird, zum anderen von den Architekturentscheidungen zur Partitionierung. Daher kommt der Softwarearchitektur, welche die Partitionierung von Software bezüglich der Ausführung auf verschiedenen Grundlagen in Betracht zieht, eine sehr hohe Bedeutung zu. KPIT bringt Erfahrung mit fast allen SoCs (System On Chip) mit, die im ADAS- und AD-Bereich implementiert sind, sowie Best Practices und Methoden für die Partitionierung und Optimierung.
Virtuelle Simulation und Gewährleistung der Abdeckung
Die Validierung autonomer Software durch Simulation ist heutzutage eine unverzichtbare Praxis. Auch die Validierung durch Simulation wird immer ausgereifter. Allerdings ist die Frage, wie die Abdeckung in der Simulation sichergestellt werden kann, in Produktionsprogrammen noch immer ein ungelöstes Problem.
KPIT hat eine Validierungsstrategie entwickelt, um die Abdeckung von kritischen Grenzund SOTIF-Fällen sicherzustellen. Die zur Sicherstellung der Abdeckung berücksichtigten Eingaben umfassen Domänenerfahrung, Analyse von Unfalldaten von über 20 Jahren, Sicherheitsanalysen sowie von NHTSA und ISO empfohlene ODDs (Operat ion Design Domains, Betriebsdesign-Domänen). Bild 3 zeigt die von KPIT entwickelten Bibliothek von Grenz- und SOTIF-Fällen, mit der sich im großen Umfang Zeit und Kosten einsparen lassen.
Homologation und Laufleistungsabdeckung
Die letzten, aber alles andere als unwichtigen Aktivitäten sind die Laufleistungsabdeckung und die Homologation. Dazu gehört nicht nur die SIL/HIL-Methodik sondern auch die Integration von Datenerhebung, Datenaufnahme, Datenmanagement, Analyse und Cloud-Implementierungen. Zusammen mit führenden Industriepartnern hat KPIT eine End-to-End- Methodik entwickelt, um die Prüfstands- und Testmethoden zur Gewährleistung der Homologation umzusetzen.
Schließung der Lücke mit Software-Industrialisierung
Der nächste Schritt besteht darin, Prototypen oder Technologie-Demonstrationen für das autonome Fahren in die Produktion zu bringen, die von Nutzfahrzeug-OEMs und ihren Plattformpartnern entwickelt wurden. Die wichtigsten Anforderungen für diesen Schritt sind das Know-how in puncto ADAS/ADSoftware, die Erfahrung mit Produktionsprogrammen und die Skalierung zur Optimierung von Zeit und Kosten. Mit einem adäquaten Partner lassen sich Einsparungen von bis zu 35 Prozent durch fertige Komponenten und Automatisierungstools und -frameworks erzielen.
Autorin
Dr. Manaswini Rath
Vice President & Global Head of Autonomous Driving,
KPIT Technologies
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Adaptive AUTOSAR reprogrammiert klassische Steuergeräte
Adaptive AUTOSAR bietet bei der Realisierung von komplexeren Softwarearchitekturen im Fahrzeug eine hohe Flexibilität. Diese Flexibilität der Software benötigt zur Wartung sogenannte Over the Air (OTA) Updates. Mit der EU7-Regulation könnte OTA für Onboard-Monitoring (OBM) sogar regulativ verpflichtend werden.
In Adaptive AUTOSAR gibt es seit dem Release 2019–11 mit dem Update und Configuration-Management (UCM) eine bordeigene Lösung für Updates von Software Clustern (SWC). Die vielen anderen Butter- und Brot-Steuergeräten im Fahrzeug, die weiterhin mit Classic-AUTOSAR oder mit proprietären Lösungen arbeiten, benötigen ebenso eine Lösung. Mit dem neuen Release 2020–11 wurde die UCM-Spezifikation um die Programmierung von Classic- Steuergeräten erweitert. Die gefundene einfache Lösung beruht auf dem seit 2009 in Off-Board-Testern etablierten Standard ISO 22900–2 „Diagnostic-Protocol Data Unit API“, einfach auch als D-PDU API bezeichnet (Bild 1).
OTA Client
Ausgangspunkt des Update Prozesses ist eine als “OTA Client“ bezeichnete adaptive Applikation. Diese für ein Fahrzeug und OEM spezifische Applikation hat die Aufgabe mit einem OEM-Backend in der Cloud oder alternativ mit einem herkömmlichen Werkstatttester zu kommunizieren und die Flash-Daten im Fahrzeug bereitzustellen. Die Kommunikationskanäle und -physik sind hierbei nicht näher von der AUTOSAR-Architektur vorgegeben. Typisch sind aber kryptografisch abgesicherte Verbindungen über ein Funknetz in die Cloud, oder mit einem lokalen Werkstatttester über Ethernet oder CAN.
Die OTA-Client Applikation ist für die externe Kommunikation verantwortlich und abstrahiert diese Kommunikation völlig. Der UCM-Master ist eine davon getrennte adaptive Service-Instanz. Er stellt die Information über Steuergeräte (ECUs), das Fahrzeug selber, die installierte Software und den Status von Aktualisierungskampagnen über ein ARA::COM Interface für den OTA-Client, aber auch für die „Vehicle Driver Application“ und den „Vehicle State Manager“ zur Verfügung. Die letzten beiden Applikationen stellen sicher, dass sowohl der Fahrer einem Update zustimmt und andererseits während einer Aktualisierungskampagne das Fahrzeug nicht in Betrieb genommen werden kann.
Der UCM-Master empfängt, die als Vehicle Packages bezeichneten Flash-Daten eines gesamten Fahrzeuges. Ein Vehicle Package wird typischerweise vom OEM für ein gesamtes Fahrzeug bereitgestellt. Es enthält neben einem einzigen Vehicle Package Manifest eine Kollektion von Software-Paketen für die verschiedenen (virtuellen) Hardware- Plattformen, ECUs und Softwarecluster.
Weiterhin enthält es für jedes Software- Paket eine eindeutige Möglichkeit, dieses seinem UCM-Client zuzuordnen.
Nachdem das Vehicle Package aus Bild 2 von dem UCM-Master korrekt empfangen wurde, kann der Update- Prozess des Fahrzeuges beginnen. Ein Update umfasst jeweils eine oder mehrere Plattformen, ECUs und (Root-) Softwarecluster.
UCM stellt mit Hilfe der Daten aus dem Vehicle Package den zeitlich korrekten Ablauf der Updates sicher.
Dieser Ablauf kann auch mehrere Reboots von ECUs, der adaptiven Plattform und von UCM selbst enthalten. Dazu werden die verschiedenen UCMClients, auch als UCM-Surrogates bezeichnet, in der notwendigen Reihenfolge aufgerufen.
Der UCM-Master beginnt dann die Programmierung eines Software-Paketes (SWP) durch den Aufruf von RequestPackage am OTA-Client, wie in Bild 3 gezeigt wird. Der UCM-Master führt für alle UCM-Clients die folgenden drei Phasen durch. Hierbei hat er alle Abhängigkeiten der verschiedenen Software-Pakete und ECUs untereinander zu berücksichtigen.
Software-Paket Datentransfer
Der Ablauf startet mit dem Transfer der eigentlichen Flash-Daten von OTA-Client über den UCM-Master zu den UCMClients.
Diese Daten werden mit einer zu UDS analogen Reihenfolge von TransferStart, mehreren TransferData gefolgt von einem finalen TransferExit zu den verschiedenen UCM-Clients übertragen.
Dieser Ablauf darf zur Geschwindigkeitsoptimierung auch parallel für verschiedene UCM-Clients erfolgen. Der Flashing Adapter wird daher die Daten zunächst zwischenspeichern.
Nachdem das Einverständnis des Fahrers vorliegt und weitere Vorbedingungen – wie ein Fahrzeugsstillstand – sichergestellt sind, kann nun die eigentliche Reprogrammierung des Classic- Steuergerätes durch den zugeordneten Flashing Adapter erfolgen.
Software-Pakete Bearbeitung
Der UCM Master entscheidet auf Basis der Daten des Vehicle Package wann die Bearbeitung des Software-Paketes im Gesamtablauf stattfinden darf. Er triggert zum definierten Zeitpunkt das Update der ECU durch den Flashing Adapter mit ProcessSw Package an.
Daraufhin führt der Flashing Adapter eine normale UDS Flash-Sequenz aus, so wie sie in der ISO 14229–1:2020 in den Kapiteln 17.2.1.1 „Pre-Programming step of phase #1“ und 17.2.1.2 „Programming step of phase #1 — Download of application software and data“ beschrieben ist. Ein Flashing Adapter kennt und beachtet den für das Steuergerät spezifischen Ablauf und stellt alle notwendigen Daten bereit, z. B. für einen Security Access und das Erase Memory.
Der Flashing Adapter baut zur Übertragung der UDS-Services auf eine im Umfang deutlich reduzierte D-PDU API „C“-Schnittstelle auf. Diese UDS-Daten werden über einen CAN- oder Ethernet- Bus an das zu reprogrammierende Classic- Steuergerät übertragen. Der Flashing Adapter stellt hierzu nur die eigentlichen Binärdaten (PDU‘s) unabhängig von einem Protokoll oder der Implementierung der D-PDU API zur Verfügung. Er kann daher in verschiedenen adaptiven Umgebungen oder unterschiedlichen Hardware Plattformen ohne Änderung genutzt werden.
Nach den TransferExit schließt dieser Ablauf mit der Berechnung und Überprüfung der Checksumme der neu programmierten Applikation der Classic- ECU ab. Das Ergebnis dieses Flashprozess wird abschließend für diesen Schritt an den UCM-Master mit Current- Status=READY zurückgemeldet.
Aktivierung
Nach dem Transfer der Daten zur Classic- ECU überprüft der UCM-Master nochmals die Abhängigkeiten der beteiligten Software Cluster untereinander und die Sicherheitsbedingungen des Fahrzeuges. Im positiven Fall ruft dann
der UCM-Master den Flashing Adapter nochmals mit Activate auf. Dieser Aufruf löst die in der ISO 14229–1:2020 unter Punkt 17.2.1.3 und 17.2.1.4 beschriebenen Post-Programming Schritte zur Finalisierung aus. Insbesondere wird dadurch auch das verbundene Classic Steuergerät durch einen „Hard Reset“ neu gestartet. Der Flashing Adapter beendet seine Tätigkeit mit der Rückmeldung an den OTA-Client, dass das neue Software-Paket CurrentStatus=ACTIVATED ist. Nach dem Ablauf der Reprogrammierung meldet seinerseits der UCM-Master den erfolgreichen Transfer des Pakets mit den State TransferState= IDLE an den OTA-Client und der Ablauf ist abgeschlossen.
Diese Architektur bringt viele Vorteile mit sich:
– Bei der Bereitstellung eines Vehicle Packages macht es für die Software- Pakete keinen Unterschied ob es sich um ein Adaptive- oder Classic- Steuergerät handelt. Ein adaptiver OTA-Client eines OEMs im Fahrzeug, kann somit alle vernetzten Steuergeräte dieses Fahrzeuges aktualisieren.
– Der Flashing Adapter als UCMClient hat nach oben (Layer 7) die AUTOSAR UCM-Schnittstelle und nach unten (Layer 5) die standardisierte D-PDU API-Schnittstelle. Er hängt somit weder von der Hardware noch von Lieferanten eines AUTOSAR-Stacks ab. Zulieferer für Steuergeräte können somit einen parametrisierten Flashing Adapter als AUTOSAR-Applikation zu ihren Classic-Steuergeräten an den OEM liefern um ihre Steuergeräte im Feld zu reprogrammieren.
– Die ISO 22900–2 (D-PDU API) hat sich seit 2008 in vielen Off-Board Diagnosesystemen im Feld bewährt. In der D-PDU API sind alle Protokollparameter und deren Verhalten vollumfänglich standardisiert, was für einen Austausch von Applikationen essenziell ist.
– Der On-Board Flashing Adapter ist in den relevanten Teilen identisch zu einer Off-Board Diagnoseapplikation entsprechend der ISO 22900–3. Dadurch können Flash-Sequenzen einfach zunächst Off-Board entwickelt und getestet werden, bevor sie dann final als Flashing Adapter in eine adaptive AUTOSAR-Umgebung integriert werden.
Fazit
KPIT hat bei mehreren großen OEMs bereits sehr gute Erfahrungen mit einem Vorläufer dieses Konzeptes, bestehend aus OTA-Client und Flashing Adapter, gesammelt. Insbesondere die standardisierten Protokollparameter sind bei notwendigen Anpassungen während einer dynamischen Entwicklung sehr vorteilhaft. Die Fahrzeug-Updates selber verlaufen problemlos, unauffällig und sind leicht zu testen. www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
Dual Banking für reibungslose SOTA-Updates
Bei Dual Banking ist der Speicherbedarf für updatefähige Softwarekomponenten in der ECU doppelt so hoch wie gewöhnlich. Der Speicher wird in zwei als Bank-A und Bank-B bezeichnete gleich große Partitionen aufgeteilt. Von den zwei Bänken ist zu jedem Zeitpunkt jeweils immer eine aktiv und die andere inaktiv. Die neue Software wird laufend in die inaktive Speicherbank heruntergeladen. Nach einem erfolgreichen Software-Update kann die neue Software dann durch Umschalten der Speicherbank ausgeführt werden. Die Funktionsmerkmale des Dual Banking sind in Bild 1 dargestellt.
Hintergrundprogrammierung
Während das Fahrzeug läuft, also während Software aus der aktiven Bank ausgeführt wird, kann das Telematiksteuergerät (TCU) im Fahrzeug die neuen Software-Updates empfangen, die dann in die inaktive Speicherbank der Ziel-ECU geladen werden. Dies wird als Hintergrundprogrammierung bezeichnet, und es gibt dabei keine Fahrzeugausfallzeiten aufgrund eines Software-Updates. Normalerweise wird die Software digital signiert und in die Ziel-ECU heruntergeladen, um nicht authentifizierte Updates zu vermeiden. Auch eine Fahrzeugdiagnose ist während der Hintergrundprogrammierung möglich.
Software- Teildownload
Mit der Software-Teildownloadfunktion ist es nicht erforderlich, bei jedem Software-Update alle Softwarekomponenten einer ECU herunterzuladen. Es besteht die Möglichkeit, nur die überarbeiteten Softwarekomponenten einzeln herunterzuladen, um die Gesamtdauer des Updates zu verkürzen und die damit verbundenen Übertragungskosten zu reduzieren.
Pause, Wiederaufnahme und Abbruch
Während der Hintergrundprogrammierung kann das Software-Update unterbrochen werden, wenn die ECU oder der Server offline geht und dann später bei erneuter Verfügbarkeit fortgesetzt oder abgebrochen werden. Auf diese Weise lassen sich die Gesamtdauer des Software-Updates und die entsprechenden Datenkosten reduzieren. Das unterbrochene/ abgebrochene Software-Update wirkt sich in keiner Weise auf die ECU aus, da es sich in der inaktiven Speicherbank befindet.
Nach einem erfolgreichen Software-Update wird die aktualisierte Software beim nächsten Fahrzeugstart aus der Download-Speicherbank ausgeführt.
Der Kunde kann die aktualisierte Software in ein paar Probeläufen nutzen und sie dann aktivieren, wenn er mit der Leistung der aktualisierten Version zufrieden ist.
Nach der Aktivierung der Software wird die aktive Speicherbank inaktiv und die Probelauf-Speicherbank aktiv. Ist der Kunde mit der Leistung der aktualisierten Software nicht zufrieden, kann er die vorherige Version der Software wiederherstellen, indem er einfach die Speicherbank umschaltet, sodass er von der neuen Version nicht betroffen ist.
Softwaresynchronisation
Sobald das Software-Update aktiviert ist, die frühere Version wiederhergestellt oder auch das Update abgebrochen ist, wird die Software bei laufendem Fahrzeug aus der aktiven Bank in die inaktive Bank kopiert. Dieser Vorgang wird als Softwaresynchronisation bezeichnet und ist nützlich, um zulässige Software in beiden Bänken der ECU sicherzustellen. Ist die Software in der aktiven Speicherbank aus irgendeinem Grund beschädigt, kann die Software aus der inaktiven Bank verwendet werden.
In diesem Fall wird die aktive Bank zur inaktiven und die inaktive Bank zur aktiven, und die Software aus der neuen aktiven Speicherbank wird ausgeführt.
Dies hilft, einen ECU-Ausfall zu verhindern und das Fahrzeug am Laufen zu halten.
Vordergrundprogrammierung
In Servicestellen kann die ECU per OBD neu programmiert werden, um den Bootloader bei Bugfixes, Erweiterungen und neuen Funktionen zu aktualisieren.
Dies verbessert die SOTA-Updatefähigkeit des Fahrzeugs und trägt somit dazu bei, Stillstandszeiten zu vermeiden.
Auch ist es immer möglich, mit einer solchen Vordergrundprogrammierung Komponenten der Anwendungssoftware zu aktualisieren.
Schnellere Umschaltung
Wenn der Ziel-Mikrocontroller in der ECU die Neuzuordnung logischer Adressen zu physikalischen Adressen unterstützt, kann die ECU-Software mit logischen Adressen aufgebaut werden, die sich aus einer beliebigen Bank ausführen lassen. Dies erleichtert eine schnellere Speicherbankumschaltung bei jedem neuen Software-Update und verhindert so mögliche Fahrzeugstartverzögerungen nach einem neuen Software- Update.
SW-Authentifizierung
Das SOTA-Update ist anfällig für Hacker-Angriffe. Um nicht authentifizierte Software-Updates zu vermeiden, muss die ECU-Software mit Signaturalgorithmen wie ECDSA, RSA und anderen digital signiert werden. Während des Software- Updates berechnet die ECU den Hash-Wert und verifiziert die Signatur der heruntergeladenen Software anhand des in der ECU gespeicherten öffentlichen Schlüssels/Zertifikats. Die heruntergeladene Software wird als gültig behandelt, wenn die Signaturverifizierung erfolgreich ist. Dieser sichere Download der Software hilft, die Programmierung nicht authentifizierter Software und somit Fahrzeug-Stillstandszeiten zu vermeiden.
Fazit
Es ist offensichtlich, dass Dual Banking durch die oben erläuterten Funktionen zur Verbesserung des Kundenerlebnisses beiträgt. Des Weiteren können auch Fahrzeugrückrufe wegen Software-Updates und die damit verbundenen Kosten vermieden werden. Eine problemlose Wartung, Software-Updates und -erweiterungen verbessern die Sicherheit und Leistungsfähigkeit des Fahrzeugs.
Dies wiederum führt zu einem besseren Kundenerlebnis ohne Stillstandszeiten während der Software-Updates. W (oe)
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT erhält von der BMW Group einen wichtigen strategischen Großauftrag für das Ladeelektronikprogramm der nächsten Generation
Die kombinierte Antriebskoordinationseinheit steuert die Leistungselektroni-karchitektur der nächsten Generation von BMW Battery Electric Vehicles (BEV) und umfasst Softwareentwicklung, -integration und -wartung. Die darin integrierte Ladeeinheit ist ein Onbord-Ladegerät, das mit der Fahrzeugsteuereinheit kombiniert ist.
Microfuzzy, ein Unternehmen der KPIT-Gruppe und Nischenspezialist für Fahrzeugelektrifizierungstechnik wird als Elektroantriebsteam zusammen mit KPIT, bei der Umsetzung dieses strategischen Softwareprogramms an vorderster Front stehen und stellt für BMW Group den ersten Schritt im Aufbau strategischer Software-Entwicklungspartner für Automotive-Software dar.
Im Rahmen der strategischen Zusammenarbeit wurde KPIT als Single-Source-Software-Integrator für das kombinierte Ladeelektronikprogramm 11KW der nächsten Generation, für die kommenden BEVs der BMW Group nominiert. MicroFuzzy und KPIT, als strategischer Softwarepartner übernehmen die Rolle für die vollständige Entwicklung, Integration, Validierung und Wartung der Serien-Software, um die Technologien zu beschleunigen, die ein zukünftiges Elektrofahrzeug erfordert.
Kishor Patil, CEO von KPIT Technologies, teilte mit: „Wir freuen uns sehr über die Weitsicht der BMW Group, in Programme zur Fahrzeugelektrifizierung zu investieren, die weitreichende Auswirkungen haben werden. Wir freuen uns, unsere bestehenden Partnerschaften mit der BMW Group zu erweitern und unser Angebot als Software-Integrator zu verstärken.
KPIT ist ein globales Technologieunternehmen mit Softwarelösungen, die die Mobilität in Richtung einer autonomen, sauberen, intelligenten und vernetzten Zukunft unterstützen. Mit mehr als 6500 Automobelievern weltweit, die auf embedded Software, KI- und digitale Lösungen spezialisiert sind, ermöglicht KPIT Kunden die Implementierung von Mobilitätstechnologien der nächsten Generation zu beschleunigen. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien. KPIT arbeitet mit führenden Mobilitätsunternehmen zusammen und ist dort präsent, wo sich das Ökosystem verändert.
Weitere Informationen finden Sie unter www.kpit.com
KPIT Technologies GmbH
Frankfurter Ring 105b
80807 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Head of Marketing Germany
Telefon: +49 (89) 3229966-140
Fax: +49 (89) 3229966-999
E-Mail: stefanie.koehler@kpit.com
KPIT erweitert seine Präsenz in Europa durch ein neues Software Engineering Center in München
• Größtes Zentrum für Softwareentwicklung und -integration im Bereich Elektrifizierung, autonomes Fahren, AUTOSAR und Fahrzeugdiagnose außerhalb Indiens.
• Wirkungsstätte für Talente aus mehr als 25 europäischen Ländern.
KPIT Technologies, ein führender Softwareintegrationspartner für OEMs und Tier 1s im Automobilsektor, gab heute die Errichtung eines europäischen Software Engineering Centers in München bekannt. Es wird das größte globale Softwareintegrations- und Technologiezentrum von KPIT im Bereich Elektrifizierung, autonomes Fahren, AUTOSAR und Fahrzeugdiagnose sein und darüber hinaus auch über Know-How aus anderen Bereichen, einschließlich Digital Cockpit verfügen. Es wird die anderen globalen Entwicklungszentren von KPIT in den USA, Japan, Thailand, China und Indien ergänzen und dazu beitragen, eine nahtlose Softwarebereitstellung für globale Fahrzeugprogramme zu ermöglichen.
KPIT ist seit über 15 Jahren in Deutschland tätig und zählt führende europäische OEMs und deren Zulieferer zu seinen Kunden. Mit über 700 Mitarbeitern aus mehr als 25 verschiedenen Ländern wird dieser Standort als globales Kompetenzzentrum dienen, um den komplexen Anforderungen an die Software für die Automobilindustrie, speziell in Zeiten erheblicher technologischer Veränderungen, gerecht zu werden. KPIT ist in Europa sowohl organisch als auch durch Akquisitionen und Partnerschaften mit europäischen Technologieunternehmen stetig gewachsen. MicroFuzzy, ein auf Software für die Fahrzeugelektrifizierung spezialisiertes Unternehmen und Teil der KPIT-Gruppe, wird ebenfalls in diesem Zentrum ansässig sein.
Im Interesse der Sicherheit der Mitarbeiter während der Covid-19-Pandemie, wird KPIT in den kommenden Monaten größtmögliche Sicherheitsvorkehrungen für eine phasenweise Belegung für diesen Standort treffen.
Kishor Patil, CEO von KPIT Technologies, kommentierte diesen wichtigen Meilenstein wie folgt: "Europa ist jetzt unser größter Wachstumsmarkt und zeugt von den bedeutenden Investitionen, die wir in den letzten zehn Jahren in Technologien getätigt haben, welche das Automobil- und das Mobilitätsökosystem verändern werden. Die Investition in diesen Standort bekräftigt unser Commitment, die besten Talente zusammenzubringen und Innovationen im Bereich der Automobilsoftware für unsere Kunden weltweit voranzutreiben.
KPIT ist ein globales Technologieunternehmen, das Softwarelösungen anbietet, die der Mobilität zum Sprung in eine saubere, intelligente und sichere Zukunft verhelfen. Mit mehr als 7000+ Automobelievern rund um den Erdball, die sich auf Embedded Software, KI & digitale Lösungen spezialisiert haben, ermöglicht KPIT den Kunden eine schnellere Umsetzung der Mobilitätstechnologien der nächsten Generation. Mit Entwicklungszentren in Europa, den USA, Japan, China, Thailand und Indien arbeitet KPIT mit Marktführern im Bereich der Mobilität zusammen und ist dort präsent, wo sich das Ökosystem wandelt.
Nähere Details finden Sie unter [url=http://www.kpit.com]www.kpit.com[/url]
KPIT Technologies GmbH
Adams-Lehman-Str. 109
80797 München
Telefon: +49 (89) 3229966-0
Telefax: +49 (89) 3229966-99
http://www.kpit.com
Global Head, Marketing
E-Mail: mohit.kochar@kpit.com
Director – Marketing
E-Mail: sunil.r@kpit.com
Marketing Lead, Germany
E-Mail: Stefanie.koehler@kpit.com
Team Gutenberg
Telefon: +91 8149773632
E-Mail: reema@thegutenberg.com
