Modellbasierter Software-Entwurf für echtzeit-kritische Systeme
Wie genau darf’s denn sein?
Fortsetzung des Artikels von Teil 2
Mosaiksteine, die den Weg bereiten“
Die Tatsache, dass ein VSP unter echten Softwarelasten arbeiten kann, generiert wertvolle Informationen auf dem Weg zur optimalen Systemarchitektur. Hierzu gehören:
Jobangebote+ passend zum Thema
- Busauslastungen,
- Prozessorauslastung und die damit verbundene Prozessorauswahl,
- Cache-Zugriffsstatistiken abhängig von der Software-Architektur und Cache-Struktur,
- Latenzzeiten des Systems auf interne und externe Ereignisse,
- Abhängigkeiten zwischen externen Komponenten, Hardware, Software und deren dazugehörige Ereignisse,
- Transaktions- und Algorithmendurchsatz.
Sobald die optimale Architektur ermittelt worden ist, übernimmt das VSP-Modell die Spezifizierung der ausführbaren Komponenten. Das bedeutet, dass das Hardware-Entwicklungsteam das VSP als Referenzmodell verwenden und an ihm den Funktionsumfang der Hardware-Elemente des Designs verifizieren kann.
Der wichtigste Vorteil eines VSP jedoch ist, dass das Software-Entwicklungsteam mit der Arbeit beginnen kann, sobald die Systemarchitektur festgelegt worden ist – also 6 bis 12 Monate früher als beim sequenziellen Entwicklungsprozess –, und dass die Hardware- und Softwareelemente des Designs parallel nebeneinander erstellt werden können (Bild 1).
Qualität entwickeln“ versus „Qualität testen“
| Entdeckte Fehlerquellen mit dem VSP |
Aufgrund der Lint-ähnlichen Fähigkeiten des VSP mit der Überschlagserkennungs-ECU konnten folgende Problemstellungen bereits in frühen Software-Entwicklungsphasen gefunden werden:
|
- Der virtuelle Systemprototyp ist in der Lage, den gleichen kompilierten und verknüpften Zielcode wie die echte Hardware auszuführen. Außerdem verhält sich der virtuelle Systemprototyp taktzyklengenau, um die Echtzeit-Kriterien zu analysieren, die mit den Automobilelektronik-Anwendungen verknüpft sind.
- Der VSP, der für dieses Projekt erstellt wurde, kann die echten Unfalldaten des Fahrzeugs in die Simulationsumgebung schreiben. Er ist ferner dafür verwendbar, um die serielle Buskommunikation auf Systemebene zu überprüfen. Zudem lässt er Fehlerinjektion zu und stellt eine Skriptumgebung zur Verfügung, die Tests auf Produktebene verbessert.
- Alle Peripheriemodelle sind so programmiert, dass sie den Software-Entwickler bei falscher Verwendung der Spezifikationen warnen. Eben dieses VSP-Feature kann kein Hardwareprototyp bieten, und der Kasten listet diesbezüglich einige Probleme auf, die beim Entwickeln der Software sofort aufgedeckt wurden.
- Aufgrund der Zyklusgenauigkeit aller Bestandteile eines VSP bestand die Möglichkeit, die Leistungsfähigkeit des Systems quantitativ zu erfassen; darauf aufbauend konnten dann auch noch Verbesserungen auf der Produktebene vorgenommen werden.
- Wie genau darf’s denn sein?
- Anwendbarkeit auf eine verteilte Automobilsteuerungsplattform mit mehreren Controllern
- Mosaiksteine, die den Weg bereiten“
- Architektur-orientiertes, VSP-basiertes Design
