Softwareentwicklung für Elektrofahrzeuge

«Wer heute qualitativ hochstehende, elektrische Maschinen liefern kann, kriegt öfter den Lieferzuschlag.»

Der Druck zur Dekarbonisierung setzt seitens der Entwicklungsabteilungen kürzere Entwicklungszyklen voraus. Manpower oder Erfahrung der KMU sind oft nicht darauf ausgerichtet, komplett neue Systeme zu entwickeln. Darunter leiden oft die Spezifikationen, Validierung, Standardisierung und damit die Qualität. Daraus resultieren Mängel, welche sich auf die Kundenzufriedenheit auswirken können. Gerade in der VCU (Vehicle Control Unit) Softwareentwicklung ist es essenziell, die Spezifikationen qualitativ hochwertig zu erfüllen und diese bereits vor der Inbetriebnahme mit geeigneten Methoden repetitiv zu testen.

Die zunehmende Komplexität und Vernetzung der Systeme verlangt eine ganzheitliche und durchdachte «state of the art» VCU-Softwarelösung für Elektrofahrzeuge, welche schnell und zuverlässig aufgebaut, gewartet sowie erweiterbar ist. Eine moderne VCU muss deshalb:

• Funktionale Anforderungen im branchenspezifischen Anwendungsfeld abdecken
• Diagnose Codes ablegen und per Fernwartung anzeigen
• Elektrische Sicherheitsanforderungen erfüllen (ECE R100 – VCU betreffend)
• Funktionale Sicherheitsanforderungen abdecken (IEC61508 / ISO26262 / ISO13849 / ISO25119)
• Anforderungen an die Produktesicherheit gerecht werden (ISO12100)
• Cyber Security Standards entsprechen (ECE R155/R156)

Gleichzeitig muss die VCU mit sämtlichen elektrischen Komponenten im Fahrzeug kommunizieren. Das bringt eine sehr hohe Anzahl an Entwicklungstasks mit sich, welche gemäss Entwicklungsprozess klassifiziert und durch Quality Gates freigegeben werden müssen. Hier lohnt es sich, ein modernes Taskmanagement System einzurichten. Beispiele dafür sind Jira oder Wrike. Zusätzlich bietet sich der Prozess des V-Models für System- und Softwareentwicklung besonders gut an, wobei – und das ist ganz wichtig – das V-Model auch grob die Reihenfolge der Tasks aufzeigt.

Welche Qualität an Software darf es denn sein? Um diese Frage beantworten zu können, bedarf es einer sorgfältigen Analyse des Zielsystems und des Zielmarkts, denn hohe Qualität bringt auch höhere Kosten mit sich. Typischerweise wird der Qualitätsstand von Software in die folgenden vier Safety Classification Level (SCL) unterteilt:

Durch ein Funktionsmuster mit SCL1, zum Beispiel als Tischaufbau der Hardware-Komponenten, lassen sich bereits sehr früh Tests auf Stufe Integration durchführen und damit ClosedLoop-Daten für den MIL-Tests (Model In the Loop) liefern. Das hilft bei der Software-Integration in das Fahrzeug und bei der Erprobung des Konzeptes (SCL2) auf Fahrzeug-Stufe. Das Fahrzeug kann mit SCL2 bereits zu Validierungszwecken betrieben werden. Durch SCL3 wird die Vorbereitung für die erforderlichen funktionalen Software-Sicherheitsfunktionen (FuSi / SVCU) implementiert. Mit SCL4 werden diese durch eine entsprechende Testvielfalt validiert und dokumentiert. Mit SCL4 kann der Produktionsstart (SOP) voll zertifiziert starten.

Folgende Faktoren spielen bei der Definition des angestrebten SCLs eine Rolle:

• Genereller Qualitäts- und Sicherheitsanspruch des OEM
• Erwartete Absatzzahlen
• Angesprochener Zielmarkt
• Heranzuziehende Normen
• Servicenetzwerk und Diagnosesysteme
• Time-to-Market

Die Problemlösung findet sich oft im strikten Befolgen des Entwicklungsprozesses. Dabei sieht das V-Model den folgenden Workflow als Vorbereitung für die Softwareentwicklung vor:

Nachfolgend die Beschreibung der einzelnen Schritte bei der Umsetzung des V-Modells:

Sind die Anforderungen an das System und die Software definiert (Definition>85%), so kann die Implementierung sowie das Testing zeitgleich und effizient starten. Bei der Implementierung ist es wichtig, den Fokus nicht zu verlieren und die Vielzahl an Requirements priorisiert abzuarbeiten und sofort zu testen, solange man gedanklich alles präsent hat. Dadurch wird wertvolle Zeit bei der Fehlersuche im Nachgang gespart.

«Software können wir erst testen, wenn das Fahrzeug und die Komponenten verfügbar sind.»

Diese Meinung ist noch immer in den allermeisten Entwicklungsabteilungen vertreten. Doch moderne Toolchains, wie sie beispielsweise Matlab Simulink bietet, sind exakt auf frühes Testen ausgerichtet. Testharnesse lassen sich über Funktionen oder ganze Modelle definieren und als MIL, SIL oder PIL ausführen. Dabei werden fehlende Systeme und Signalfeedback von ClosedLoop-Systemen durch ein Model-Plant nachgebildet. Dadurch werden Fehler im Konzept, in der Spezifikation oder in der Programmierung in frühen Projekt-Phasen gefunden und können kosteneffizient behoben werden. Mit einem abschliessenden Integrationstest, ausgeführt auf Stufe HIL, können die Schnittstellen zu den untergeordneten Systemen sowie zu den Hardware-Komponenten vor, während und auch nach der Inbetriebnahme repetitiv geprüft werden.