Echtzeit-Systemdesign mit Hilfe der AUTOSAR-Methodik
Echtzeitfähigkeit ist alles
Fortsetzung des Artikels von Teil 5
Timing-Chains
Gegenwärtig fehlen im Metamodell von AUTOSAR jegliche Informationen zu den Timing-Anforderungen. Generell gibt es zwei Arten von Timing-Anforderungen für Echtzeitsysteme. Einerseits gibt es abstrakte Timing-Anforderungen wie End-to-End-Latenzzeiten, die das zeitliche Verhalten eines Systems bezogen auf der logischen Abstraktionsebene der Systemfunktionen beschreiben (High Level Requirement). Andererseits gibt es Timing-relevante Implementierungsdetails auf der System-Ebene (System Level Property). Diese müssen aus den abstrakten Vorgaben abgeleitet werden, um die implementierungsunabhängige Spezifikation der Timing-Anforderungen einzuhalten.
Als Beispiel sei eine Funktion „Automatischer Türöffner“ angeführt. Diese soll die Tür eines Autos selbsttätig entriegeln, wenn sich die Hand des Benutzers dem Türgriff nähert und sich der Autoschlüssel in einem gewissen Radius um das Fahrzeug befindet. Der Fahrzeugschlüssel sendet hierzu eine digitale Chiffre, die von einer ECU empfangen und verifiziert wird.
Eine typische Timing-Anforderung für diese Funktion könnte lauten, dass die Türen binnen 100 ms nach Annähern der Hand zu entriegeln sind. Derartige Vorgaben für die End-to-End-Latenzzeit finden sich in aller Regel in Systemspezifikationen. Die für die technische Umsetzung dieser Funktion erforderliche Hard und Software muss folglich so schnell sein, dass sie innerhalb von 100 ms reagieren kann. Eine daraus hergeleitete Systemanforderung könnte lauten, einen Prozessor zu verwenden, der die Verifikation des digitalen Schlüssels in der vorgegebenen Zeit ermöglicht. Eine andere könnte die Verwendung eines Sensors verlangen, dessen Abtastrate die rechtzeitige Erkennung der sich nähernden Hand gestattet. Softwareseitig ist ein geeignetes Scheduling der Tasks und Bus-Meldungen zu fordern, ergänzt durch schnelle Sensor- und Kommunikationstreiber.
Wie im genannten Beispiel beziehen sich der Anfang und das Ende von High-Level-Anforderungen häufig auf Ereignisse wie „die Hand hat sich genähert“ oder „der digitale Schlüssel wurde verifiziert“. Gestützt auf diese Erkenntnisse wurden ein Metamodell zur Erfassung der abstrakten Vorgaben und eine Implementierung zur Berechnung der entsprechenden Latenzzeiten auf der System-Ebene entwickelt. Ein Grundgedanke dieser Methodik ist das abstrakte Ereignis. Es handelt sich hier nicht um ein Ereignis im Sinn der Auslösung einer Reaktion bei irgendeinem Empfänger, sondern um ein bei laufendem System passiv beobachtbares Geschehnis. Dabei ist zwischen internen und externen Ereignissen zu unterscheiden. Externe Ereignisse verkörpern die Grenze zwischen dem technischen System und seiner Umgebung. Das System nutzt Sensoren und Aktoren, um mit eben dieser Umgebung zu interagieren. Externe Ereignisse stehen daher für das Eintreten irgendeiner Aktion der Umgebung, die von einem Sensor erkannt oder von einem Aktor ausgelöst werden muss. Für jede Sensor‑ und Aktor-Komponente des Systems existiert ein externes Ereignis, das für die High-Level-Timing-Anforderungen herangezogen werden kann. Zur Beschreibung abstrakter Vorgaben benötigt man jedoch zusätzlich bestimmte interne Ereignisse, die Aktionen innerhalb der Grenzen des Systems beschreiben.
Jobangebote+ passend zum Thema
An dieser Stelle kommt es darauf an, einen passenden Abstraktionsgrad zur Modellierung der High-Level-Anforderungen zu finden. Es muss aus diesem Grund interne Ereignisse geben, mit denen sich eine Anforderung vom Stimulus bis zur Response (Endereignis der Anforderung) eindeutig beschreiben lässt. Bei zu detaillierter Beschreibung werden die Modellierung und die algorithmische Verifikation zu komplex. AUTOSAR bietet hierzu das Konzept der Runnable Entities, die gewissermaßen als Container für das in einer Programmiersprache implementierte Funktionsverhalten dienen. Sie interagieren dabei über Input- und Output-Daten-Elemente, die Bestandteil einer Komponenten-Schnittstelle sind. Damit werden die Runnable Entities zu optimalen Anwärtern für das Produzieren interner Ereignisse. Wir definieren deshalb das Runnable-Startereignis und das Runnable-Endereignis als mögliche Ereignisse zur Verknüpfung mit High-Level Timing-Anforderungen.
Eine Timing-Chain modelliert High-Level-Timing-Anforderungen und wird mit internen oder externen Ereignissen als Stimulus oder Response definiert (siehe Bild 3). Zwischen dem Auftreten eines Stimulus und der zugehörigen Reaktion kann eine minimale und eine maximale Latenzzeit festgelegt sein. Gemäß dem zuvor angeführten Beispiel kann eine Anforderung wie „zwischen dem Annähern der Hand an den Sensor und der Verifikation des Schlüssels dürfen höchstens 70 Millisekunden vergehen“ nunmehr als Timing-Chain modelliert werden, wobei das externe Ereignis der Sensor-Komponente als Stimulus und das Endereignis der Runnable Entity zur Verifikation des digitalen Schlüssels als Response benutzt werden. Kein Bestandteil der Abstraktionsebene dieses Timing-Chain-Modells ist die Zeit, die von der Basis-Software oder komplexen Gerätetreibern benötigt wird, denn als Ereignis-Quellen kommen hier ausschließlich Runnable Entities in Frage.
Das AUTOSAR-Metamodell enthält bereits einige technische Details des Systems, die für die Verifikation der abstrakten Timing-Chains benötigt werden. Diese repräsentieren die Vorgaben auf der System-Ebene, die implementiert werden müssen, um die High-Level-Anforderungen zu erfüllen. Zu beantworten ist die Frage, ob die in den Timing-Chains spezifizierten abstrakten Vorgaben mit einer konkreten technischen Realisierung des Systems erfüllt werden können. Beispiele für derartige Details sind die WCETs (Worst Case Execution Times) von Runnable Entities sowie die Zykluszeiten von Tasks, die diese Entitäten ausführen sowie das Scheduling von Bus-Nachrichten für die Übertragung von Datenelementen. All diese Systemdaten werden vom Verifikationsalgorithmus zur Berechnung der maximalen und minimalen Latenzzeit einer Timing-Chain verwendet und mit dem spezifizierten Latenzzeit-Intervall verglichen.
- Echtzeitfähigkeit ist alles
- Literatur:
- Tasks und Runnables
- Bewältigung der Herausforderungen
- Es bleiben Fragen offen
- Timing-Chains
- Der AUTOSAR-RTE-Generator
