Mit Chronsim und Chronval lässt sich das Echtzeitverhalten simulieren und validieren.

Mit Chronsim und Chronval lässt sich das Echtzeitverhalten simulieren und validieren.Inchron

Embedded-Systeme sind in der Mehrzahl keine Industrie-PCs oder Smartphones mit GUI und Betriebssystemen à la Windows oder Linux. Die große Masse verrichtet ihre Dienste im Hintergrund und überwacht den Bremsvorgang im Auto, steuert die Röntgenstrahlung im Computertomographen oder sorgt dafür, dass die Schweißpunkte des Fertigungsroboters eine reproduzierbare Qualität liefern. Die Entwicklung solcher Systeme erfordert interdisziplinäres Wissen und hat eine Vielzahl von Design- und Qualitätsanforderungen. Eine besondere Herausforderung stellen das Echtzeitverhalten und die Performance dar.

Unlängst präsentierte der Chefingenieur eines Automobilherstellers ein Beispiel aus der Praxis: Eine neue Lichtfunktion sollte den Fahrer entlasten. Das Zusammenwirken verschiedener Fahrzeugfunktionen führte aber in seltenen Fällen dazu, dass die sicherheitsrelevante Funktion nicht rechtzeitig umschaltete. Unerwartet häufige Interrupts von der Buskommunikation verzögerten die Funktion übermäßig und verursachten damit ein Echtzeitproblem. Vermutlich waren zu Beginn der Entwicklung nicht genügend detaillierte Echtzeitkriterien der Einzelkomponenten bekannt, die erst in der Integrationsphase ihre Auswirkungen zeigten.

Auf einen Blick

Modellbasierte Entwicklung ist in – und das aus gutem Grund. Schließlich erlauben es die frühzeitige Simulation und Validierung, die Architektur eines Systems zu überprüfen, noch bevor die erste Zeile Code geschrieben ist. Mit Tools wie Chronsim und Chronval gilt das auch für das überaus heikle Echtzeitverhalten.

Echtzeitanforderungen

„Das Steuerungssystem muss in vorgegebener Zeit auf eine Eingabe reagieren“ und „Der Regler muss periodisch den Sollwert aktualisieren“ sind typische, abstrakt formulierte Vorgaben an das System. Daraus leiten sich Echtzeitanforderungen ab, die man als Antwortzeit oder Start-zu-Start-Jitter einer Software-Komponente spezifizieren wird. Jedoch ergeben sich auch aus scheinbar funktionalen Aspekten Echtzeitanforderungen. Sollen beispielsweise alle eingehenden Daten verarbeitet werden, dann kann unter Umständen ein zeitweilig gesperrter Interrupt dazu führen, dass eingegangene Daten nicht rechtzeitig aus dem Pufferspeicher ausgelesen wurden, bevor neue Daten die vorhandenen überschreiben.

Diese Echtzeitanforderungen für das Erreichen des korrekten, dynamischen Verhaltens von Systemen kann man nach verschiedenen Kriterien ermitteln. Abhängig von der gewählten Software-Architektur und -Implementierung sind unterschiedliche Kriterien entscheidend für die korrekte Funktion. Für eine Analyse ist es notwendig, sowohl die Echtzeitkriterien der Teilkomponenten als auch die des Gesamtsystems zu kennen. Typische Echtzeitkriterien sind:

  • Antwortzeiten
  • Start-zu-Start-Jitter von Tasks und Software-Komponenten
  • Mehrfachaktivierung von Tasks
  • Ausführungsreihenfolge von Software-Komponenten
  • Latenzen von Wirkketten (Event Chains)
  • Verlust von Daten
  • Alter der Daten
  • Datenkonsistenz
  • Wiederverwendung von Daten (gewollt oder unbeabsichtigt)
  • Verlust von Interrupts
  • Blockierung von Interrupts

Echtzeitkriterien modellbasiert überprüfen

Mit der Kenntnis aller relevanten Echtzeitkriterien seines Systems in möglichst frühen Entwicklungsphasen wird der Systemarchitekt das Hardware-Software-Co-Design so entwickeln, dass es auch die Timing- und Performance-Anforderungen erfüllt. Das gelingt ihm am besten, wenn er bereits in der Architekturphase überprüfen kann, ob sein System die Vorgaben an Timing und Performance auch nach der Implementierung und Integration einhalten kann. Der moderne Ansatz dazu ist ein modellbasierter Systementwurf: Bereits auf Modellebene kann der Architekt seine Lösung durch Simulation oder formale Verifikation überprüfen. Dies gilt auch für das dynamische Echtzeitverhalten, nicht nur für funktionale Aspekte.

Bild 1: Wenn der Anwender sein Systemmodell mit Timing-Informationen anreichert, können Tools wie Chronsim und Chronval das Echtzeitverhalten simulieren und validieren.

Bild 1: Wenn der Anwender sein Systemmodell mit Timing-Informationen anreichert, können Tools wie Chronsim und Chronval das Echtzeitverhalten simulieren und validieren.Inchron

Um das Echtzeitverhalten des Systems analysieren zu können, werden im Modell zunächst die Ressourcen (Mikrocontroller, Bussysteme und teils auch Peripheriebausteine) beschrieben, die den Code ausführen oder mit denen die Daten übertragen werden. Für jede dieser Ressourcen wird angegeben, nach welchem Schema sie belegt oder frei sind und wie gleichzeitige Anforderungen der Ressource von verschiedenen Funktionen geregelt werden. Dieses Scheduling ist bei Bussystemen beispielsweise durch Nachrichtenprioritäten geregelt. Bei Mikrocontrollern hat die Interrupt-Verarbeitung höchste Priorität und danach regelt das Betriebssystem die Abarbeitung der Software-Funktionen. Für jedes Nachrichtenpaket und jede Software-Funktion wird im Modell definiert, wie lange sie netto die Ressource belegen und durch welches Ereignis sie aktiviert werden. Die Aktivierung kann ein externer Interrput oder ein Timer-Interrupt sein, der Aufruf durch eine vorhergehende Funktion oder häufig auch ein eintreffendes Datenpaket.

Gutes Timing

Das Modell beschreibt somit das Zeitverhalten des Systems und berücksichtigt dabei die Funktionalität, sofern diese das Zeitverhalten beeinflusst. Bedingen beispielsweise Betriebsmodi des Systems, dass zusätzliche Funktionalität abgearbeitet wird, muss das Modell auch dessen zusätzlich benötigte Ausführungszeit beschreiben und berücksichtigen. Die Abstraktion von der Funktionalität ermöglicht es, einfache Modelle frühzeitig zu entwickeln und für das Timing irrelevante, funktionale Aspekte vorerst auszulassen.

Das so erstellte Timing-Modell wird mittels Simulation oder formaler, mathematischer Analyse zur Überprüfung der Echtzeitanforderungen genutzt. Die Simulation, beispielsweise mit dem Programm Chronsim, ermittelt für alle Prozesse deren Zustände und führt das Scheduling auf den Ressourcen aus. In verschiedenen Diagrammen kann der Anwender die Kommunikation, Aktivierungen und Blockierungen analysieren, aber auch den Stack-Verbrauch und die Ressourcenauslastungen über der Zeit ermitteln. Mit Hilfe der Validierung mit Chronval erhält der Anwender die garantierten oberen und unteren Grenzen der Antwortzeiten, Ressourcenauslastung und Verdrängungen von Prozessen. Diese Worst- und Best-Cases geben schnell Aufschluss darüber, ob ein System unter allen Timing-Situationen die Echtzeitanforderungen einhalten wird.

Wirkketten

Echtzeitanforderungen an komplexe Datenabhängigkeiten oder Abläufe kann der Systemarchitekt auch mit Hilfe von Wirkketten beschreiben. Diese entsprechen teils dem Datenfluss und verlaufen beispielsweise von Sensoren und Eingängen über verschiedene Hardware- und Software-Komponenten (etwa Mechatronik, Bussysteme, Treiber-Software) zur Applikations-Software, die aus den Eingangsdaten und Systemzuständen eine Reaktion ermittelt. Diese Reaktion wird wieder über verschiedene Komponenten zu den Aktoren übertragen.

Bild 2: Die Wirkketten offenbaren in Task-Zustandsdiagrammen, welche Abläufe sich gegenseitig in die Quere kommen.

Bild 2: Die Wirkketten offenbaren in Task-Zustandsdiagrammen, welche Abläufe sich gegenseitig in die Quere kommen.Inchron

Die Systemreaktion hängt von vielen Faktoren ab. Zustandsautomaten müssen in definierten Zuständen sein, Eingangswerte in vorgegebenen Wertebereichen und all dies zum richtigen Zeitpunkt. Da viele Wirkketten für verschiedene Funktionen gemeinsam ablaufen, interagieren und interferieren sie häufig. Diese Zusammenhänge statisch zu beschreiben, ist bereits eine komplexe Aufgabe. Im dynamischen, zeitlichen Zusammenhang betrachtet, ist eine Beherrschung des Systems nur mit Hilfe von Echtzeit-Simulationsmodellen möglich.

Timing und Tasks

Im Timing-Model markiert der Anwender neben dem Rechenzeitbedarf der Funktionen auch die Wirkketten. In Bild 2 sind zwei Mikrocontroller (ECU1 und 2) mit je drei Tasks sowie ein Flexray-Bus modelliert und im Task-Zustandsdiagramm vom Chronsim in der Simulation dargestellt. Abhängig von der Phasenlage der periodischen Tasks auf verschiedenen CPUs zueinander wird die Wirkkette eventuell stark verzögert abgearbeitet. Denn in dem System sind die Mikrocontroller zueinander und gegenüber dem Bus asynchron, werden also mit der Zeit driften. Daten, die in der Applikation auf ECU1 (unten) erzeugt werden, können je nach Phasenlage doppelt in der Applikation von ECU2 (oben) verarbeitet werden oder dort nie ankommen.

Mit Hilfe der Task-Modelle und insbesondere der Wirkketten kann der Anwender die Ablaufdetails der Einzelkomponenten (und damit die verteilte Detailkenntnis jeder Entwicklergruppe) in einem gemeinsamen Simulationsmodell erfassen. Die Simulation der Wirkketten hilft allen Beteiligten, die Abläufe im Ganzen besser zu verstehen und diejenigen Pfade durch das System zu identifizieren, deren Verhalten echtzeitkritisch sind.

Beispiel Multicore

Immer häufiger besteht die Anforderung, existierende Systeme auf Multicore-Mikrocontroller umzustellen. Zum einen steigen die geforderten Funktionalitäten rapide an, zum anderen erhofft man sich mit Multicores die Taktraten und damit den Energiebedarf zu senken. Zuvor sequenziell ausgeführte Funktionen können nun auch parallel zu einander ablaufen. Das bringt eine nicht zu unterschätzende Komplexität in das dynamische Verhalten des Systems ein. Mit Hilfe von detaillierten Echtzeitanforderungen der einzelnen Funktionen wird der Architekt eine Verteilung auf die Cores modellieren und analysieren können. Diese iterative Optimierung erfolgt wesentlich früher, schneller und damit kostengünstiger, als die aufwändige Implementation und Integration auf realer Hardware.

Bild 3: Bei der Portierung von Single-Core-Lösungen auf Multicore-Prozessoren können überraschende Schwierigkeiten auftreten. Hier zeigt sich ein Datenkonsistenzproblem.

Bild 3: Bei der Portierung von Single-Core-Lösungen auf Multicore-Prozessoren können überraschende Schwierigkeiten auftreten. Hier zeigt sich ein Datenkonsistenzproblem.Inchron

Beispielsweise werden in Bild 3 zwei zyklische Funktionen 1 und 2 auf verschiedene Cores gemapped, die miteinander Daten austauschen. Um sicherzustellen, dass die Daten immer aktuell sind, wird in der Software-Architektur festgelegt, dass ein fester Offset die zweite Funktion nach der ersten aktiviert. Das stellt sicher, was zuvor die Abarbeitung nacheinander auf nur einem Core automatisch erledigte (Bild 3, links). Was aber unberücksichtigt blieb, war der Einfluss von anderen, höher prioren Funktionen und der Kommunikation. Verdrängungen der ersten Funktion können in ungünstigen Situationen mit vielen, gehäuft auftretenden Bus-Nachrichten dazu führen, dass der Offset der zweiten Funktion auf Core 2 nicht mehr ausreicht, die weiter verarbeiteten Daten also nicht mehr konsistent sind (Bild 3, rechts).

Immer im Bilde

Embedded-Entwickler müssen viele Kriterien beachten. Häufig werden ihre Systeme in sicherheitskritischen Bereichen eingesetzt und jede Domäne, ob Automobil, Luftfahrt, Medizin oder Automatisierung bringt ihre eigenen Anforderungen hinzu. Das korrekte Echtzeitverhalten ist dabei häufig ein Grund für Projektverzögerungen, da mit herkömmlicher Entwicklungsmethodik Timing-Effekte erst nach der Integration abgeprüft werden.

Mit dem hier vorgestellten, modellbasierten Ansatz zur Simulation und Validierung des Echtzeitverhaltens bereits in deutlich früheren Entwicklungsphasen wird dieses Projektrisiko wesentlich vermindert. Die beschriebenen Echtzeitkriterien helfen bereits in der Anforderungsphase das Verhalten mit einzuplanen und während des Entwicklungsprozesses ständig im Auge zu behalten.