Die modellorientierte Entwicklung stellt eine sowohl von System- als auch von Software-Ingenieuren genutzte Umgebung für die grafische Spezifikation und Analyse bereit. Modelle werden zur Definition der Systemarchitektur ebenso eingesetzt wie auch zur Bestimmung von Komponenten-Schnittstellen, Regelungs- und Signalverarbeitungs-Algorithmen, Zustandsautomaten oder des Echtzeit-Verhaltens. Bei der modellorientierten Entwicklung von Regelungsanwendungen müssen die Anforderungen sicherheitskritischer Systeme erfüllt werden, zum Beispiel Flugzeugelektronik oder X-by-Wire-Systeme für Automobile. Erst wenn der fertige Objekt-Code extrem kompakt, schnell und verifizierbar ist, kann der Übergang in die Serienfertigung erfolgen.
Da Serien-ECUs in der Regel in sehr großen Stückzahlen und deshalb auf möglichst kostengünstigen und häufig mit Festkomma-Arithmetik arbeitenden Mikroprozessoren produziert werden, sollte die fertige Implementierung ebenfalls hocheffizient sein. Typische Aufgaben der modellorientierten Entwicklung sind die Systemspezifikation, ein detaillierter Software-Entwurf, die Generierung von Produktions-Codes als auch die Code-Integration und -Verifikation. Andere Aufgaben, z.B. die System-Validierung oder die automatische Dokumentation, werden zwar unterstützt, aber hier nicht näher beschrieben.
Systemspezifikation
Mit Modellen werden sämtliche Aspekte eines Systems spezifiziert – von seinem funktionalen Verhalten bis hin zum detaillierten Aufbau. Um die Jahrtausendwende bestand ein konventionelles Systemmodell aus Blöcken, Subsystemen, Filtern und Lookup-Tables in Simulink, Zustandsautomaten und Steuerflusslogiken in Stateflow sowie anwenderdefiniertem Quellcode in manuell optimierten SFunctions. Der Code konnte für ANSIC erzeugt und mit Schnittstellen (Hook) für die Analyse und Optimierung versehen werden (Bild 1). Heute können Modelle außerdem Embedded-Matlab-Funktionen, Stateflow-Wahrheitstabellen und mit dem Legacy Code Tool optimierte S-Functions enthalten. Der Code kann für ANSI/ISO-C und C++, mit Target Function Librarys optimierten C-Code, VHDL und Verilog generiert werden.
Große Modelle können mithilfe von „Model“-Blöcken partitioniert werden. Durch diese kann ein Modell ein anderes referenzieren, ohne es während der Simulation zu öffnen und in den Speicher des Host-Rechners zu laden. Im Vergleich mit der klassischen Arbeitsweise mit „Atomic Subsystems“ spart diese Modell-Referenzierung viel Zeit bei der Simulation und der Code-Generierung. Mithilfe solcher „Model“-Blöcke sind Ingenieure heute in der Lage, Modelle mit fast einer Million Blöcken aufzubauen und zu simulieren. Die Modell-Referenzierung unterstützt außerdem die inkrementelle Code-Generierung, bei der immer nur für diejenigen Blöcke neuer Code generiert wird, an deren referenziertem Modell Veränderungen vorgenommen wurden. Durch Busse und damit verbundene Busobjekte lassen sich saubere Schnittstellen für Block-Komponenten mit Dutzenden oder sogar Hunderten von Schnittstellendaten realisieren.
Während der Code-Generierung können Busse devirtualisiert werden, so dass sie im generierten Code Strukturen (C Struct Types) erzeugen. Seit R2006a lassen sich „Atomic Subsystems“ automatisch in „Model“-Blöcke umwandeln und Busobjekte automatisch erzeugen. Ingenieure können sich damit auf einfache Weise für eine bestimmte Form der Architekturbildung entscheiden. Mit R2007b können „Model“-Blöcke im Normalmodus und im beschleunigten Modus simuliert werden, wodurch Ingenieure die Wahl haben, ihr Modell mit vollen Analyseund Kontrollmöglichkeiten oder aber mit der größtmöglichen Simulationsgeschwindigkeit auszuführen.
Die Modellierung und Simulation auf einem Host-Computer allein kann aber nicht den ganzen Weg zur Produktion hin zurechtlegen. Der Grund dafür sind ungenaue Umgebungsmodelle, schwer zu simulierende Timing-Effekte und andere, nur in der realen Welt auftretende Effekte. Letztere müssen jedoch berücksichtigt werden, um das Verhalten eines Algorithmus wirklich zu verstehen. Zur Überwindung dieser Beschränkungen eignet sich besonders gut das Rapid Prototyping. Hierbei wird zum Testen der ECU statt des Umgebungs-Modells die tatsächliche Anlagen-Hardware in die Regelschleife eingebaut.