Ein Angebot von

Zeiteigenschaften in der Embedded-System-Entwicklung

| Autor / Redakteur: Raphael Weber * / Sebastian Gerstl

Generischer V-Entwicklungsprozess.
Generischer V-Entwicklungsprozess. (Bild: Vekrot Informatik)

Zeiteigenschaften manifestieren sich in allen Schritten der eingebetteten System-Entwicklung. Angefangen bei High-Level Kunden- oder Safety-Anforderungen bis zur Performance-Optimierung der Implementierung. Dieser Beitrag zeigt entlang des allgemeinen V-Entwicklungsprozesses, wo Zeiteigenschaften eine Rolle spielen und wie man sie sinnvoll repräsentieren, visualisieren und verarbeiten kann.

Jeder Autofahrer möchte sicher von A nach B kommen. Um diese (funktionale) Sicherheit (Safety im Sinne der ISO26262 [1]) garantieren zu können, muss, je nach-dem wie sicherheitskritisch eine Funktion ist, mehr oder weniger Arbeit investiert werden. So entsteht ein zusätzlicher Aufwand dort wo Zeit eine sicherheitskritische Rolle spielt. Ein sehr bekanntes Beispiel hierfür ist das rechtzeitige Öffnen eines Airbags bei einem Autounfall. Dort wo das zu frühe oder zu späte Auftreten eines systemgesteuerten Verhaltens dazu führt, dass die korrekte Funktion nicht gewährleistet ist spricht man von Echtzeiteigenschaften oder auch Zeiteigenschaften.

In der Entwicklung eingebetteter Systeme folgt man üblicherweise dem V-Entwicklungsprozess [2] um die Komplexität beherrschen zu können. Eine mögliche Ausprägung dieses V-Prozesses ist in Abbildung 1 dargestellt. Sie ist unter anderem inspiriert von dem generischen Entwicklungsprozess des SPES2020 Projekts [3].

Angefangen bei der Anforderungsdefinition (Requirements Engineering, links oben in der Abbildung) über den Funktionsentwurf (Functional Design) und die logische Architektur (Logical Architecture, auch Systemarchitektur genannt) bis zur plattformspezifischen technischen Architektur (Technical Architecture) und der eigentlichen Umsetzung (Realization) werden nach diesem Prozess in Top-Down-Manier eingebettete Systeme entwickelt. Anschließend (auf der rechten Seite) werden die einzelnen Artefakte (die auf der linken Seite entstanden sind) zusammengefügt, validiert und getestet. Je nachdem, wieviel Funktionalität bereits aus Vorgängerumsetzungen weiterverwendet werden soll, kann man sich an den V-Entwicklungsprozess mehr oder weniger gut halten. Das ist z.B. dann nicht möglich, wenn existierende Teillösungen (und deren Entwicklungsprozess) angepasst werden müssen.

Zeiteigenschaften im V-Entwicklungsprozess

Wo sind hier die Zeiteigenschaften? Behauptung: Überall! Das Airbag-Beispiel zeigt es sehr gut: Die Kundenforderung nach einem funktionierenden Airbag ist im ersten Schritt im V-Prozess sichtbar. Technisch interpretiert, enthält sie sogar schon genaue Zeitangaben, beispielsweise könnte eine Anforderung heißen: „Nach einer Aufprallerkennung muss der Airbag innerhalb von 20 ms öffnen können“. Die genaue Dauer hängt natürlich noch von weiteren Faktoren ab, wie z.B. der tatsächlichen Geschwindigkeit. Dennoch müssen die 20 ms auch im schlimmsten Fall, das heißt egal wie gravierend diese Faktoren ausfallen, eingehalten werden.

Im weiteren Verlauf, beim Funktionsentwurf, verfeinert man jetzt diese Anforderung, inklusive des Zeitverhaltens, und verteilt die so entstandenen Subfunktionen, welche die Airbag-Funktion umsetzen. Beispielsweise kann man drei Subfunktionen mit deren Zeitgrenzen bilden: Aufprall erkennen (2 ms), Zündzeitpunkt berechnen (9 ms), Airbagzündung ansteuern (5 ms). Offensichtlich darf die Summe der Zeitgrenzen nicht größer als 20 ms sein, damit die übergeordnete Anforderung erfüllt werden kann. Wenn die Summe (wie hier) kleiner ist, kann es passieren, dass man potenzielle Lösungen ausschließt (kann gewollt sein). Wichtig ist hier auch die Betrachtung der Umgebung der zu entwickelnden Funktion: Gibt es einen Zeitversatz zwischen dem tatsächlichen Aufprall und dem gemessenen, d. h. wie alt ist die Information die man bekommt? Dies ist besonders wichtig, wenn man den Aufprallsensor regelmäßig (z.B. alle 4 ms) ausliest. Der Messwert ist dann im schlimmsten Fall bereits einen Zyklus alt. Diese impliziten Annahmen über die Umgebung der zu entwickelnden Funktion sollten in die Anforderungen mit aufgenommen werden, weil sie (wie in diesem Fall) den Lösungsraum einschränken und bei der Validierung der Kundenanforderungen mit einfließen. Die Idee, der expliziten Dokumentation der Annahmen unter welchen eine Anforderung eingehalten werden soll, stammt vom Contract-based Design [4].

Während beim Funktionsentwurf Überlegungen zum Datenaustausch zwischen Funktionen und deren Reihenfolgen eine untergeordnete Rolle spielen, betrachtet man in der logischen Architekturentwicklung genau diese Aspekte. Hier werden zu-nächst atomare (nicht weiter dekomponierte) Funktionen zu logischen Komponenten kombiniert (z.B. in PREEvision). Zwischen diesen Komponenten wird dann die Kommunikation (logische Signale) ausdefiniert, d.h. die vergebenen Zeitbudgets aus dem Funktionsentwurf werden jetzt auf logische Komponenten und Signale verteilt. Die logische Architektur ist mit den AUTOSAR [5] Software-Komponenten/Kompositionen und Zeiteigenschaften mit den AUTOSAR Timing Extensions abbildbar. Wie in der AUTOSAR Komponentenbeschreibung, hat das zu entwickelnde System bis zu diesem Punkt keine plattformspezifischen Eigenschaften. Diese werden in der technischen Architektur ausgearbeitet.

Beim technischen Architekturentwurf wird die Zielplattform und -hardware mit betrachtet. Die Hardware besteht aus Steuergeräten mit Prozessoren, Speichereinheiten, Sensoren, Ansteuerungen für Aktoren, usw. und Bussystemen für die Kommunikation zwischen den Steuergeräten. Da diese Hardware begrenzt ist (u.a. durch Kosten), müssen sich die logischen Komponenten und Signale die verfügbaren Ressourcen untereinander teilen. Wie dabei die zeitliche Teilung passiert, wird durch das Betriebssystem (z.B. durch Scheduling) und dessen Konfiguration bestimmt. In der technischen Architektur kommen also noch Ressourcenteilungseffekte (Speicherzugriffe, Buszugriffe, Betriebssystem-Overheads, …) in den Zeitbetrachtungen dazu. An dieser Stelle müssen die zeitlichen Teilungseffekte bei der Validierung des Verhaltens der technischen Architektur des zu entwickelnden Systems berücksichtigt werden (z.B. in einer Simulation mit der TA Tool Suite).

Die anschließende Implementierung beinhaltet die Umsetzung der einzelnen Softwareteile, so dass diese auf der Zielhardware korrekt funktionieren, sowie die Konfiguration der Zielplattform (Softwareteile auf Prozessoren und Kerne, Nachrichten auf Busse, Variablen auf Speicherbereiche, etc.). Aufgrund der Komplexität, der zeitlichen Zusammenhänge und deren Dynamik gibt es in diesen letzten beiden Prozess-schritten (Technische Architektur und Implementierung) die meisten Iterationen. Wenn man dann auf der rechten Seite des V-Entwicklungsprozesses, beim Testen/Tracing und Validieren des zu entwickelnden Systems auf mehreren Steuergeräten, Fehler im Zeitverhalten feststellt, ist eine Korrektur umso aufwändiger. Speziell für Zeiteigenschaften stellt sich hier die Frage, wie man solche späten aufwändigen Korrekturen vermeiden kann. Ich glaube, dass es, wie oben beschrieben, mit einer durchgängigen Betrachtung der Zeiteigenschaften im gesamten Entwicklungsprozess möglich ist.

Durchgängige Betrachtung von Zeiteigenschaften

Je früher man im Entwicklungsprozess Zeiteigenschaften und -anforderungen erhebt und dokumentiert, desto frühzeitiger kann man sie auch validieren und verifizieren. Die Verifikation der Gültigkeit einer Verfeinerung von Zeiteigenschaften kann man zudem noch automatisieren indem man die entsprechenden Eigenschaften maschinell verarbeitbar spezifiziert (z.B. durch Sprachmuster). Ob die Summe der Zeitbudgets von Subfunktionen kleiner oder gleich des Zeitbudgets der verfeinerten Funktion ist, lässt sich auf diese Weise automatisch überprüfen.

Explizite oder implizite Annahmen über die Umgebung sind bei Zeiteigenschaften besonders wichtig. Einerseits werden sie benötigt um frühzeitig Auslastungen ab-schätzen zu können, andererseits braucht man sie um maximal mögliche zeitliche Versatze frühzeitig quantifizieren zu können. Mit gut dokumentierten zeitlichen An-nahmen, kann man auch Funktionsbaukästen aufbauen, um das Varianten-Management zu vereinfachen.

Zeiteigenschaften: Eine querschnittliche Thematik in der Entwicklung eingebetteter Systeme

Anhand eines generischen V-Entwicklungsprozesses wurde in diesem Beitrag beleuchtet, in welchen Prozessschritten und in welcher Form sich Zeiteigenschaften manifestieren. Eine durchgängige Betrachtung kann sich auszahlen – besonders bei der frühzeitigen Identifikation von zeitlichen Inkonsistenzen. Eine maschinell verarbeitbare Spezifikation der Zeiteigenschaften kann helfen diesen Prozess zu automatisieren.

In Zukunft werden immer mehr Funktionen im Auto automatisiert bis hin zum voll-autonomen Fahrzeug. Die Anzahl der zeitkritischen und gleichzeitig sicherheitskritischen Funktionen wird daher weiter zunehmen. Eine frühzeitige Betrachtung von Zeiteigenschaften muss damit fester Bestandteil des Entwicklungsprozesses werden.

Modellbasiertes Vorgehen bei Echtzeitanforderungen

Modellbasiertes Vorgehen bei Echtzeitanforderungen

08.01.19 - Beim Embedded Software Engineering gehören Zeitanforderungen zu den wichtigsten nicht-funktionalen Anforderungen. Deshalb gibt es spezialisierte Werkzeuge, die das Zeitverhalten eines realisierten Embedded Software Systems analysieren und validieren können. lesen

Visualisierung von Antwortzeiten in FreeRTOS

Visualisierung von Antwortzeiten in FreeRTOS

06.06.19 - Die effiziente Entwicklung von auf FreeRTOS basierender Firmware setzt voraus, dass das Timing und die Interaktionen zwischen Tasks, Interrupts und Kernel genau bekannt sind. Wie lassen sich diese aber in Software-Tests visuell darstellen und nachvollziehbar machen? lesen

Literatur

[1] ISO26262, Road vehicles – functional safety, 2011.
[2] Das V-Model XT, https://www.cio.bund.de/Web/DE/Architekturen-und-Standards/V-Modell-XT/vmodell_xt_node.html, Abrufdatum: 12.10.2018.
[3] Pohl, K., Hönninger, H., Achatz, R., Broy, M.: Model-Based Engineering of Embedded Systems – The SPES 2020 Methodology. Springer Berlin Heidelberg, 2012.
[4] Meyer, B.: Applying „design by contract“, Computer, vol. 25, no. 10. pp. 40-51, 1992.
[5] AUTOSAR (AUTomotive Open System ARchitecture), https://www.autosar.org, Abrufdatum: 12.10.2018.

(Der Beitrag wurde mit freundlicher Genehmigung des Autors dem Embedded Software Engingeering Kongress Tagungsband 2018 entnommen.)

* Raphael Weber ist Senior Research Engineer bei der Vector Informatik GmbH.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46255947 / Test & Qualität)