Modellbasierte Software-Entwicklung in agilen Prozessen nutzen

Grundsätzlich beginnt der Weg für eingebettete Regler- und Algorithmen-Entwicklung mit der ingenieurtechnischen Leistung, den Regler zu konzipieren, wofür Ingenieure seit jeher Modelle erstellen. Die Einführung von Simulink machte erstmals die rechnergestützte Entwicklung (Computer-Aided Engineering; CAE) von Modellen und Reglern möglich. Damit gab es eine natürliche Möglichkeit, schnell zu einem einzigen und simulierbaren Artefakt zu kommen – dem Simulink-Modell. Das simulierbare Modell bringt viele Vorteile mit sich: ein gemeinsam verständliches Artefakt sowie die Möglichkeit, den Regler direkt in der Entwicklungsumgebung zu testen.

Diese Art zu entwickeln, offenbarte die noch bestehende Lücke in der Prozesskette. Der Informationsaustausch zwischen Funktionsentwickler und Programmierer war noch immer ein manueller Schritt. Denn die Software-Implementierung des Reglers musste immer noch per Hand erstellt und dafür zunächst eine textuelle Spezifikation des Simulink-Modells an den Programmierer kommuniziert werden (Bild 1).

Im Jahr 1999 schloss sich diese Lücke mit der Einführung von TargetLink. Es generierte erstmalig Seriencode direkt aus dem Simulink-Modell. Die manuelle Programmierung ist damit automatisiert und die Lücke im Prozess geschlossen. Seriencode-Generierung ermöglicht damit die erfolgreiche Anwendung der Methode MBD. In diesem konzeptuellen Ansatz entwickelt der Funktionsentwickler das Reglermodell und der Software-Entwickler reichert dasselbe Modell mit den nötigen Software-Informationen an. Das garantiert einen schnellen und einfachen Austausch desselben Artefakts und somit der zugrundeliegenden Informationen. Erst durch die automatische Code-Generierung entsteht in kurzer Zeit nach der Software-Bedatung hochqualitativer und effizienter C-Code.

Bild 1: Aus Pol-Nullstellen- und Bode-Diagrammen etc. entstehen zunächst die textuellen Anforderungen für die Software. Daraus entwickelt ein Software-Entwickler mittels Handcode die Funktionalität für das Steuergerät. dSPACE

Vor der Einführung von Seriencode-Generatoren rechnete man vom Design bis zur Implementierung aufgrund hoher Abstimmungs- und Korrekturaufwände mit Turnaround-Zeiten von Monaten. Denn reine textuelle Software-Anforderungen bieten großen Interpretationsspielraum. Dank des Single-Source-Prinzips und der automatischen Code-Generierung reduzierten sich die Turnaround-Zeiten auf Wochen (Bild 2).

Mindestanforderung für MBD

Die Entwicklung von Algorithmen für eingebettete Steuergeräte war und ist durch Hardware-Restriktionen geprägt. Die geringe Leistung oder der begrenzte Speicher der Systeme fordern hohe Performance und Effizienz von dem erzeugten C-Code. Neben hochoptimiertem Code für eine bestimmte Zielplattform lassen sich Hardware-Ressourcen mittels Fixed-Point-optimierten Codes effizient ausnutzen. Die Aufgabe, Fixed-Point-C-Code zu erzeugen, ist allerdings anspruchsvoll. Typischerweise ist sowohl die Auflösung der Zahlendarstellung als auch der Wertebereich stark eingeschränkt. Das führt zu Quantisierungseffekten im Wertebereich. Wird die Quantisierung zu grob gewählt, führt dies wiederum zu schlechtem Regler- und Systemverhalten. Software-Entwickler brauchen also eine Möglichkeit, Quantisierungsfehler zu messen und das Ausmaß des Fehlers zu bewerten. Denn insbesondere aufgrund der Quantisierungsfehler weicht der automatisch generierte C-Code in Fixed-Point-Darstellung von dem in Floating-Point gerechneten Modell ab.

Da das Modell und der Code in derselben Entwicklungsumgebung entstehen, ist es möglich, die Konsistenz zwischen Funktionsmodell und dem generierten Code zu vergleichen. Zunächst testet ein Funktionsentwickler seinen Algorithmus im Model-in-the-Loop-Modus (MIL) auf die grundsätzliche Funktion im Entwicklungswerkzeug. Im nächsten Schritt verifiziert der Software-Entwickler das Ergebnis dieses Floating-Point-Tests ebenfalls noch einmal. Diesmal jedoch wird der auf dem Host-Computer kompilierte C-Code unter denselben Randbedingungen wie das Modell simuliert. Die Simulation findet im Software-in-the-Loop (SIL)-Modus statt.

Bild 2: Vergleich zwischen der eingebetten Software-Entwicklung ohne MBD und automatischer Seriencode-Generierung (unten) und der Entwicklungsgeschwindigkeit mit dem Seriencode-Generator TargetLink und einem MBD-Prozess (oben). dSPACE

Neben den Abweichungen des Codes durch beispielsweise Quantisierungseffekte können zusätzliche Abweichungen durch Unzulänglichkeiten in der Compiler-Prozessor-Toolkette entstehen. Die Funktion muss also auch auf dem Prozessor getestet werden. Der Entwickler kann durch die Anbindung der Entwicklungsumgebung an Testboards darüber hinaus den Algorithmus auf der eigentlichen Zielplattform im PIL-Modus (Processor-in-the-Loop) evaluieren. Zusätzlich liefert der PIL-Test Aussagen über den Ressourcenverbrauch.

Ob nun im SIL- oder im PIL-Modus, damals als Zielplattform mit einem C166 oder heute mit einem modernen Aurix-Prozessor, Funktionstests sind durch den MBD-Ansatz mit Autocoding direkt in der Entwicklungsumgebung möglich. So lässt sich auf ganz einfache Weise die kaum von numerischen Effekten behaftete Simulation des Simulink-Modells, das Fixed-Point-Verhalten des generierten Codes und der von Hardware- und Compiler-Effekten betroffene C-Code auf der Zielplattform vergleichen.

Größer und komplexer

Die direkte Ausführbarkeit und die höhere Entwicklungsgeschwindigkeit hatten zur Folge, dass sich MBD sehr schnell verbreitete. Mit zunehmender Erfahrung und wachsendem Vertrauen in die Methode und die Werkzeuge steigen neben der Anzahl der Modelle auch deren Größe und Komplexität. Die bisherige Praxis sämtliche Software-Eigenschaften direkt am Modell-Block zu spezifizieren, erweist sich schnell für große Modelle als nicht praktikabel. Insbesondere Änderungen globaler Eigenschaften sind aufwendig und fehlerträchtig. Wenn sich beispielsweise die Skalierung eines global genutzten Parameters ändert, muss jede Verwendungsstelle im Modell einzeln bearbeitet werden.

Bild 3: Ohne die automatische Code-Generierung aus Matlab/Simulink sind oftmals aufwendige, manuelle Code-Reviews zur Erfüllung der ISO notwendig. Mit MBD können die Reviews auf Modell-Ebene durchgeführt werden, da der Code automatisch generiert wird. dSPACE

Eine Möglichkeit, dieser Herausforderung zu begegnen, besteht darin, die implementierungsspezifischen Daten vom Modell zu trennen. Der Entwickler kann so den oben erwähnten Parameter an einer zentralen Stelle spezifizieren. Ein Beispiel hierfür ist das TargetLink Data Dictionary. Im Modell referenziert der Entwickler damit nun an allen Verwendungsstellen die zentrale Spezifikation. Dadurch wirkt sich eine Änderung automatisch auf alle Verwendungen aus und garantiert so Konsistenz und korrektes Verhalten.

Wiederverwendung – MBD und Autosar machen es möglich

Die steigende Komplexität betrifft nicht nur die MBD-Entwicklung. Die gesamte Automobilindustrie steht immer wieder vor neuen Herausforderungen. 2003 führte der Anstieg der Systemkomplexität dazu, dass sich viele namhafte OEMs und Tier-1 zu einer Entwicklungspartnerschaft zusammenschlossen, um einen neuen Software-Entwicklungsstandard aus der Taufe zu heben: Autosar.

Autosar definiert ein einheitliches Architektur-Metamodell, präzise Spezifikation von Schnittstellen und Parametern sowie einen wohldefinierten Austausch von Artefakten und deren Entwicklungsprozess. Das erlaubt erstmalig einen geordneten Austausch von Entwicklungsdaten zwischen unterschiedlichen Abteilungen oder gar Firmen. Um dies zu ermöglichen, stellt Autosar eine Zwischenschicht zur Verfügung und abstrahiert so von der Hardware des Steuergeräts. Der Entwickler verwendet dann nur noch Funktionen dieser Zwischenschicht. Die Autosar-Beschreibung regelt eindeutig, welche Funktionen es gibt, welche Funktionalität sie erfüllen und welche Eigenschaften sie haben. Das ermöglicht den angestrebten Austausch.

MBD bietet eine weitere Abstraktionsstufe. Sie entkoppelt die konkrete Implementierung nach Autosar von der Funktion im Modell. Das ermöglicht die direkte Wiederverwendung von existierenden Funktionen in einer Autosar-Umgebung. Der Seriencode-Generator erzeugt automatisch die passenden Funktionsaufrufe konsistent für sämtliche Software-Anteile. Im Gegensatz zu Handcode ändert der Software-Entwickler nur die Spezifikation einer Schnittstelle im Modell, muss jedoch nicht den kompletten Code aufgrund einer Änderung der Funktionsaufrufe ändern. Ein Modellartefakt kann somit leicht für verschiedene Einsatzzwecke wiederverwendet werden und ist unabhängiger und austauschbarer als Handcode. MBD bedeutet dementsprechend auch Flexibilität in Bezug auf die Software-Implementierung.

Sicher ist sicher – Funktionale Sicherheit mit MBD und ISO 26262

Mittlerweile ist die Anzahl von Steuergeräten und die Nutzung von Software in einem Automobil so hoch wie nie zuvor. Funktionalitäten wie ESP und Notfallbremsassistenten sind für ein sicheres Auto essenziell geworden und müssen besonders getestet werden. Ein wesentlicher Anteil dieser Tests ist die Absicherung der funktionalen Anforderungen. Und somit prägt der Standard ISO 26262 seit 2011 die Software-Entwicklung in der Automobilindustrie.

Damit die Software konform mit ISO 26262 ist, bedarf es vieler Absicherungsschritte. Darunter fallen unter anderem vollständige Coverage-Metriken und Prüfungen auf Einhaltung von Entwicklungsrichtlinien. MBD ist bei dieser Herausforderung hilfreich. Denn wie eingangs erwähnt ist das Simulink-Modell eine ausführbare Spezifikation. Die automatische Code-Generierung übersetzt anhand fester Regeln dasselbe Modell immer in denselben Code. Das bedeutet, dass der Entwickler nur noch das Modell gegenüber den Anforderungen verifiziert. Dadurch verlagern sich sämtliche Verifikationsschritte ins Simulink-Modell. Das beschleunigt sowohl die Tests der Software als auch den Review-Prozess erheblich, da die manuelle Review des Codes gegen die Anforderungen entfällt (Bild 3). Er wird durch hochautomatisierbare und effiziente Back-2-Back-Tests ersetzt.

Bild 4: MBD wird agil. Ganze Toolketten werden im Zuge von immer schnelllebigeren Software-Produkten auf eine agile Vorgehensweise umgestellt, um den geänderten Rahmenbedingungen zu genügen. MBD und Seriencode-Generatoren passen sich hervorragend in den geänderten Prozess ein. dSPACE

Diese Schritte sind im Kontext einer ISO-konformen Entwicklung nur Teil eines umfassenderen Entwicklungsprozesses. Selbstverständlich müssen alle Teile des Entwicklungsprozesses miteinander abgestimmt sein. Daher ist eine professionelle Begleitung des gesamten Entwicklungsprozesses inzwischen sehr wichtig. So bedarf es einer guten Planung des Gesamtprozesses und dedizierten Verantwortlichkeiten innerhalb der Prozessorganisation, um einen ISO-konformen Prozess zu unterhalten.

MBD heute und morgen

Die Rahmenbedingung für automobile Software ändern sich im Moment rapide. Dadurch, dass ein großer Teil der Wertschöpfung in der Software steckt, wächst die Komplexität der Software so stark an, dass sie als Ganzes nicht mehr handhabbar ist. Um diese Herausforderung zu meistern, teilen Entwicklungsteams große und komplexe Software auf einzelne Entwickler auf.

Leider stellt sich nun erst bei der Software-Integration heraus, ob das Gesamtsystem korrekt funktioniert. An dieser Stelle können durch die Aufteilung in kleine Software-Module neue Fehler entstehen. Beispiele hierfür sind inkonsistente Spezifikationen der Schnittstellen und Parameter, die sich über den Entwicklungszeitraum ergeben können. Um solche Fehler früh zu finden, bieten sich agile Vorgehensweisen wie Continuous Integration an (Bild 4). Der wesentliche Vorteil liegt darin, dass bei einem im Test gefunden Fehlverhalten identifizierbar ist, welche Änderung dieses verursacht. Deswegen ist schon heute ein hoher Automatisierungsgrad bei der Entwicklung von modularen Modellen besonders bedeutsam.

Darüber hinaus diskutieren Architekten und Entwickler in der Automobilindustrie Möglichkeiten große dezentrale Steuergeräteverbände auf Domänen-Controllern zu konsolidieren. Dafür übernimmt die Automobilindustrie Technologien aus der IT, die solche Probleme löst. Adaptive Autosar beispielsweise nutzt in Kombination mit SOME/IP in erheblichem Maße serviceorientierte Architekturen. Das Ziel dabei ist, eine lose Kopplung von zahlreichen Komponenten zu erreichen und bei Bedarf deutlich flexibler Funktionen auf einem Steuergerät zu aktualisieren, zum Beispiel durch Over-the-Air-Updates.

(prm)