Modellbasierter Software-Entwurf für echtzeit-kritische Systeme
Wie genau darf’s denn sein?
Fortsetzung des Artikels von Teil 1
Anwendbarkeit auf eine verteilte Automobilsteuerungsplattform mit mehreren Controllern
Das in Bild 3 skizzierte System stellt ein Netzwerk von Automobil-ECUs dar, und die hierin verwendeten Steuerungs- und Sicherheitsfunktionen erfordern spezifische strenge Echtzeit-Einschränkungen des Kommunikationsprotokolls, die sehr gut verstanden werden müssen. Um diese Anforderungen zu erfüllen, werden immer öfter jene zeitgesteuerten Protokolle verwendet, welche auf CAN-TT- und FlexRay-Bussen implementiert sind.
Jobangebote+ passend zum Thema
Auch ein solches System lässt sich modellieren, so dass der Entwickler darauf aufbauend wichtige Kriterien wie die erforderliche Bandbreite und Latenz der vernetzten Struktur sowie das (zeitliche) Verhalten der Steuerungseinheiten unter extremen und durchschnittlichen Bedingungen überprüfen kann. Ein gutes Beispiel dafür wäre, wenn Motorcontroller und Radaufhängungscontroller jeweils Teil eines verteilten Kfz-Stabilitätscontrollers sind.
Es ist zu beachten, dass am Modell durchgeführte Experimente viel mehr Testfälle behandeln können als jene an einem realen Fahrzeugteil oder einer Komponente. Die meisten Entwickler finden das überraschend. Die Kontrollierbarkeit eines Modells und die Möglichkeit, extreme Situationen zu konfigurieren, sowie die Fähigkeit, Daten zur Verfügung zu stellen, die mit Hilfe des Modells über ein physikalisches Produkt gesammelt wurden, ermöglichen umfassende Tests. Häufig finden diese Tests mit dem VSP in Echtzeit statt (manchmal sogar schneller als in Echtzeit).
Das eben genannte Beispiel gewährte einen Einblick in die Modellierungsanforderungen von Prozessoren, (Bus-)Verbindungen und ECUs. Zudem wird ersichtlich, wie viele Zielfunktionen zu lösen sind, um das optimale System zu finden, wobei mit dem VSP ein experimenteller Ansatz verfolgt wird. Eine Konstante bleibt jedoch bestehen: Modelle müssen zeitgenau sein und über hohe Leistung verfügen, um für architektonisches Experimentieren und für die Entwicklung von Software für Echtzeit-Steuerungssysteme verwendet werden zu können. Für Software, die auf ungenauen und/ oder unvollständigen Modellen entwickelt wurde, kann keine Garantie übernommen werden, dass diese auf Hardware korrekt läuft. Derartige Modelle können keinerlei Echtzeit-Fähigkeiten garantieren wie das Einhalten von Latenzzeiten, Energieverbrauch, Performance, Bandbreite und Durchsatz.
Front-End-Designprozess im Vergleich zum Back-End-Designprozess
Konventionelle (sequenzielle) Design-umgebungen sind, was die Anforderungen an technische Ressourcen und Risiken angeht, naturgemäß „Back-End“-lastig. Im Vergleich dazu konzentrieren sich VSP-basierte, architekturorientierte Designmethoden auf das Front-End. Die Anzahl der benötigten Entwicklungsingenieure ist gleichmäßiger über die gesamte Projektlaufzeit verteilt. Fehler können schon früher in der Designphase erkannt werden und müssen damit nicht am Ende der Projektphase mit einem erheblichen Personalaufwand im „Back-End-Design“ ausgemerzt werden.
Man beachte in Bild 4 die Ressourcenanforderungen, Risikofaktoren und Entwicklungszeiten, die mit dem konventionellen Prozess verbunden sind, und zwar im Vergleich zum parallelen VSP-basierten Designprozess (unten im Bild). Jedes Schaubild zeigt Schemata für die Bereitstellung von technischen Ressourcen während des Projektablaufs:
- Architekturbewertung, Entwicklung und Spezifikation,
- Hardwaredesign und Entwicklung,
- Software-/FW-Design und Entwicklung,
- Systemintegration (einschließlich Verifikation und Debugging),
- das Projekt als Ganzes (Summe aller oben genannten Aktivitäten).
Jede vertikale Rasterlinie stellt eine Zeitspanne von sechs Wochen dar. Wie die Grafik zeigt, dauerte mit der konventionellen (sequenziellen) Methode die gesamte Entwicklungszeit 18 Monate. Der Designprozess beanspruchte 800 Mannwochen, mit einem maximalen Personaleinsatz von 146 Ingenieuren im fünfzehnten Monat.
Im Vergleich hierzu beanspruchte das architekturorientierte, VSP-basierte Design mit seiner parallelen Entwicklung von Hardware und Software nur 520 Mannwochen, einen maximalen Personaleinsatz von 97 Ingenieuren im fünften und sechsten Monat. Außerdem betrug die gesamte Projektlaufzeit unter Verwendung des neuen Arbeitsablaufs nur 13 Monate – eine um fünf Monate verkürzte Entwicklungszeit!
Ein besonders interessanter Aspekt tut sich auf, wenn man die Risikofaktoren der unterschiedlichen Designabläufe betrachtet. Im Fall des konventionellen (sequenziellen) Ablaufs liegt es auf der Hand, dass ein erhöhter Mitarbeitereinsatz gegen Ende des Projekts auch die mit dem Projekt verknüpften Risiken erhöht.
| [1] | Venture Data Corporation. Collett International Report on Embedded Systems. 2004. |
| [2] | Frischkorn, H-G.: Automotive Software –The Silent Revolution. Keynote Speech of the Automotive Software Workshop San Diego, Feb. 2004. |
| [3] | Schubert, P.J.; Vitkin, L.; Winters, F.: Executable Specs: What Makes One, and How are They Used? SAE Technical Paper Series 2006-01-1357. |
| [4] | Winters, F.J.; Mielenz, C.; Hellestrand, G.R.: Design Process Changes Enabling Rapid Development, Convergence 2004, 2004-21-0085. |
| [5] | Hellestrand, G.R.: The Engineering of Supersystems. IEEE Computer, 38, 1(Jan. 2005), S. 103 –105. |
| [6} | Hellestrand, G.R.; Seddighnezhad, M; Brogan, J.E.: Profiles in Power: Optimizing Real-Time Systems for Power as well as Speed, Response Latency & Cost. Power Aware Real-time Conference (PARC2005), Sept. 2005, Jersey City, NY. |
| [7] | Jakobsson, P.: AUTOSAR – Die Rolle der Chiplieferanten. Hanser Automotive, Januar/Februar 2006, S. 18 –22. |
| [8] | Alford, C.: Virtual prototyping benefits in safety-critical automotive systems. Hanser Automotive, März/April 2006. |
 | Dr. Elof Frank, geboren in Nairobi/Kenya und schwedischer Staatsbürger, studierte in Paderborn Informatik und promovierte 1995 im VLSI-Entwurf digitaler Systeme. Seine ersten Berufserfahrungen sammelte er als Software-Entwickler und Projektleiter im Silicon Valley, bevor er 1998 den Startup Get2Chip von der Gründungsphase bis zur erfolgreichen Aquisition durch Cadence Design Systems begleitete. Unter anderem eröffnete und leitete er während dieser Zeit ein Entwicklungsbüro in München für Get2Chip. Seit 2003 ist er in München verantwortlich für den Aufbau der europäischen Vertriebsaktivitäten von VaST Systems, vor allen Dingen in Zentral- und Nordeuropa. |
 | Dipl.-Ing. Martin Schnieringer, geboren in Fürstenfeldbruck, studierte Elektrotechnik mit dem Fokus auf Nachrichtensysteme an der Technischen Universität Karlsruhe. Nach seinem Studium fing er 1995 bei Analog Devices in München an, wo er sich auf Digitale Signalprozessoren spezialisierte. 1999 folgte ein Wechsel zu Synopsys, wo er Simulations-tools auf System- und RTL-Ebene betreute. Seit gut einem Jahr ist er als Senior Field Application Engineer bei VaST in München zuständig für die Kundenbasis in Zentral- und Nord-Europa. |
- Wie genau darf’s denn sein?
- Anwendbarkeit auf eine verteilte Automobilsteuerungsplattform mit mehreren Controllern
- Mosaiksteine, die den Weg bereiten“
- Architektur-orientiertes, VSP-basiertes Design
