DE102011101064A1

DE102011101064A1 - Formale methoden nutzende zeitsteuerungsanalyse

Info

Publication number: DE102011101064A1
Application number: DE102011101064A
Authority: DE
Inventors: Swarup K. Mohalik; A C Rajeev; Manoj G. Dixit; Ramesh Sethu; Devesh B. Chokshi
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2010-05-14
Filing date: 2011-05-10
Publication date: 2011-12-01
Also published as: US8484009B2; CN102323969A; CN102323969B; US20110282640A1

Abstract

Ein Verfahren und Werkzeuge zum Liefern einer präzisen Zeitsteuerungsanalyse, die auf industrielle Fallstudien mit einer großen Anzahl von Aufgaben und Nachrichten skalierbar ist, werden geliefert, einschließlich der Fähigkeit, Aufgaben- und Nachrichten-Antwortzeiten zu modellieren und zu analysieren; einer ECU-Nutzung, einer Bus-Nutzung; einer Ende-zu-Ende-Latenzzeit von Aufgaben/Nachrichtenketten; und Probleme der Zeitsteuerungs-Synchronisierung in Aufgaben/Nachrichten-Graphen. Systemaufgaben und -nachrichten werden in einem Formalismus modelliert, der als Kalenderautomat bekannt ist. Modelle werden in einer Modellierungssprache wie zum Beispiel Promela geschrieben und mit einem für die Analysespezifikation spezifischen Code instrumentiert. Modelle und Instrumentierung werden aus der Systembeschreibung und Analysespezifikation automatisch erzeugt. Das Systemmodell wird durch einen kompatiblen Modell-Prüfer wie zum Beispiel SPIN einer eingehenden Zustandsraum-Exploration unterzogen. Während einer Exploration erzeugt der instrumentierte Code Ergebnisse für verschiedene Zeitsteuerungsanalysen. Optimierungstechniken sind vorgesehen, um Modelle zu erzeugen, welche weniger Speicher und Zeit zur Analyse erfordern und das Verfahren auf große industrielle Fallstudien skalierbar machen.

Description

TECHNISCHES GEBIET
Die Erfindung bezieht sich allgemein auf eine Taktzeit- bzw. Zeitsteuerungsanalyse eingebetteter Systeme unter Verwendung formaler Methoden und insbesondere auf ein im Computer ausführbares Verfahren für eine formale Modellierung und Zeitsteuerungsanalyse eines Systems, das unter Verwendung von Kalenderautomaten beschrieben wird.
HINTERGRUND
Bestehende Verfahren, die für die Zeitsteuerungsanalyse eingebetteter Systeme verwendet werden, beinhalten analytische, simulationsgestützte und stochastische Verfahren. Diese Verfahren liefern eine ungenaue Analyse. Analytische Verfahren, die eine Planbarkeits- bzw. Schedulability-Analyse und Echtzeitberechnung nutzen, ergeben sichere Näherungen. Da sie jedoch einige Operationsdetails des betrachteten Systems nicht behandeln können und die erreichbaren Zustände in einem Modell des Systems nicht berechnen, können die Ergebnisse sehr pessimistisch sein. Stochastische Verfahren sind gut für eine Analyse eines Durchschnittsfalls, sind aber nicht geeignet für eine Worst-Case-Analyse. Ferner erlauben diese Verfahren keine deterministische Modellierung beliebiger Ablaufplanungs- bzw. Scheduling-Algorithmen und Controller-Puffer-Strategien, welche tatsächliche Ergebnisse beeinflussen. Außerdem liefern bestehende analytische und stochastische Analysewerkzeuge keine guten Lösungen für Probleme bei einer Zeitsteuerungs-Synchronisierung, da diese Probleme mit einer gleichzeitigen Analyse mehrerer Ereignisketten verbunden sind, welche die Fähigkeiten dieser Verfahren übersteigen. Simulationsgestützte Verfahren können Operationsdetails behandeln. Sie garantieren jedoch keine Abdeckung von grenzwertigen Fällen (engl. corner cases) während einer Systemsimulation und Zeitsteuerungsmessungen, was somit möglicherweise optimistische Ergebnisse liefert.
Formale verfahrensgestützte Werkzeuge und Verfahren zur Zeitsteuerungsanalyse existieren, waren aber nicht auf große industrielle Beispiele skalierbar. Zum Beispiel können auf zeitgesteuerte Automaten basierende formale Verfahren nicht die große Datenmenge adressieren, die mit einem komplexen System verbunden ist, und scheitern typischerweise aufgrund des großen Speichers und der Zeit, die erforderlich sind, um die Analyse abzuschließen. Mit der zunehmenden Komplexität elektrischer Systeme wie zum Beispiel kraftfahrzeugtechnischer elektrischer Systeme mit mehreren elektronischen Steuerungseinheiten (ECUs), die über mehrere Busse eines Steuerbereichsnetzwerks bzw. Control-Area-Network (CAN) kommunizieren, werden skalierbare Verfahren und Werkzeuge zur Zeitsteuerungsanalyse benötigt, die die komplexen Systeme präzise und sorgfältig analysieren können.
ZUSAMMENFASSUNG
Hierin werden ein Verfahren und System geliefert, um eine Zeitsteuerungsanalyse eines eingebetteten Systems durchzuführen, das zumindest eine elektronische Steuerungseinheit (ECU) und/oder zumindest einen Bus enthält. Das Verfahren beinhaltet ein Liefern einer Systembeschreibung, ein Liefern einer Analysespezifikation für das System, ein automatisches Erzeugen eines formalen Modells des Systems unter Verwendung eines Modellgenerators, ein Analysieren des formalen Modells des Systems unter Verwendung eines Modell-Prüfers und ein Liefern von Ergebnissen der Analyse. Die Systembeschreibung kann Aufgaben beschreibende Aufgabenparameter, Nachrichten beschreibende Nachrichtenparameter, Abhängigkeitsbeziehungen zwischen den Aufgaben und den Nachrichten und andere Details des Systems enthalten. Das formale Modell kann ein Kalenderautomatenmodell und eine Instrumentierung enthalten.
Ein Analysieren des formalen Modells des Systems kann beinhalten ein Analysieren von Antwortzeiten der Aufgaben und der Nachrichten, ein Analysieren einer Ende-zu-Ende-Latenzzeit von Aufgaben/Nachrichtenketten und/oder ein Analysieren einer Zeitsteuerungs-Synchronisierung in Aufgaben/Nachrichten-Graphen. Das Verfahren und System können ferner ein Liefern von Ablaufplanungs- bzw. Scheduling-Strategien für die ECUs oder Busse, die in dem System enthalten sind; und ein Liefern von Regeln für eine Ereignisaktivierung einschließen, welche zumindest eine Regel enthalten kann, die einen zeitgesteuerten Übergang oder einen diskreten Übergang betrifft.
Das Modell kann optimiert werden unter Verwendung einer oder mehrerer Optimierungstechniken, um den Zustandsraum des Modells zu reduzieren oder zu optimieren, um eine effiziente Zustandsraum-Untersuchung bzw. -Exploration zu ermöglichen. Zum Beispiel kann das Modell optimiert werden, indem eine Antwortzeit einer Aufgabe oder einer Nachricht dynamisch berechnet wird; indem die Analysespezifikation verwendet wird, um einen Abschnitt oder Teil der Systembeschreibung zu filtern, die von der Analysespezifkation unabhängig oder für diese nicht kritisch ist; oder indem eine Kombination dieser Techniken angewendet wird.
Die obigen Merkmale und Vorteile und andere Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden detaillierten Beschreibung der besten Verfahren zum Ausführen der Erfindung leicht ersichtlich, wenn sie in Verbindung mit den beiliegenden Zeichnungen vorgenommen wird.
KURZESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Flussdiagramm, das ein Verfahren für eine Zeitsteuerungsanalyse unter Verwendung formaler Verfahren beschreibt;
2 ist eine schematische graphische Darstellung eines veranschaulichten Beispiels eines eingebetteten Systems;
3 ist eine Tabelle von Aufgaben/Nachrichtenzuordnungen und Parametern des Systems von 2;
4 ist eine Tabelle von Aufgaben/Nachrichtenketten in dem System von 2;
5A und 5B sind graphische Modelle von Regeln für Zustandsänderungen bei Ereignisaktivierung für Aufgaben bzw. Nachrichten;
6 ist ein formales Modell einer Regel für einen diskreten Übergang für ein Ereignis ready, ausgedrückt in einem Kalenderautomaten;
7A, 7B und 7C sind graphische Modelle für Regeln für eine Analyse der Ende-zu-Ende-Latenzzeit von Aufgaben, wobei 7A, 7B und 7C erste, zwischenliegende bzw. letzte Aufgaben in einer Kette repräsentieren;
8 ist ein graphisches Modell, das eine fliegende Berechnung einer Aufgaben-Antwortzeit veranschaulicht;
9 ist ein Algorithmus zum Berechnen eines Überlaufs bzw. Spill gemäß dem Verfahren von 1; und
10A, 10B und 10C sind veranschaulichende Beispiele repräsentativer Ergebnisse einer Zeitsteuerungsanalyse des Systems der 2, 3 und 4, die gemäß dem Verfahren von 1 durchgeführt wurde.
AUSFÜHRLICHE BESCHREIBUNG
Ein Verfahren und Werkzeuge werden geliefert, um genaue Zeitsteuerungsanalysen durchzuführen, welche auf industrielle Fallstudien mit einer großen Anzahl von Aufgaben und Nachrichten skalierbar sind, ohne Sorgfalt bzw. Genauigkeit aufzugeben. Das Verfahren und die Werkzeuge, die hierin vorgesehen werden, beinhalten die Fähigkeit, Aufgaben-Antwortzeiten zu modellieren und zu analysieren, einschließlich Aufgaben-Antwortzeiten im besten Fall und schlechtesten Fall und einer Schedulability-Analyse; eine Verwendung elektronischer Steuerungseinheiten (ECU) einschließlich einer prozentualen Nutzung von ECU-Berechnungszeit; Nachrichten-Antwortzeiten einschließlich Nachrichten-Antwortzeiten im besten Fall und schlechtesten Fall und einer Schedulability-Analyse; eine Busnutzung einschließlich einer prozentualen Nutzung des Busses und einer Leerlaufzeit-Verfügbarkeit; eine Ende-zu-Ende-Latenzzeit für Aufgaben/Nachrichtenketten, einschließlich Latenzzeiten für First in-First out (FIFO), First in-Last out (FILO), Last in-First out (LIFO), Last in-Last out (LILO); Probleme einer Zeitsteuerungs-Synchronisierung unter Aufgabengraphen; eine maximale Zeittrennung zwischen mehreren Zielen, beginnend von einer einzigen Quelle; und eine maximale Zeittrennung zwischen mehreren Quellen, die zum gleichen Ziel führen.
In dem hierin beschriebenen Verfahren werden Systemaufgaben und -nachrichten in einer formalen Notation oder einem Formalismus wie zum Beispiel einem Kalenderautomaten modelliert. Die Modelle werden in einer Modellierungssprache wie zum Beispiel Process Meta Language (Promela) geschrieben. Ferner sind die Modelle mit einem Code instrumentiert, der eine formale Notation nutzt und spezifisch entworfen ist, um die betreffende Analyse zu adressieren. Die Modelle zusammen mit der Instrumentierung werden aus zumindest Aufgaben/Nachrichtenbeschreibungen und Scheduling-Strategien automatisch erzeugt. Andere Operationsdetails wie zum Beispiel Controller-Puffer-Strategien können ebenfalls in Modellen enthalten sein oder solche geliefert werden. Optimierungstechniken können verwendet werden, um den Zustandsraum für eine Modellprüfung weiter zu optimieren. Das modellierte System wird durch einen kompatiblen Modell-Prüfer wie zum Beispiel einen Simple Promela Interpreter (SPIN) einer eingehenden Zustandsraum-Exploration unterzogen. Während einer Exploration erzeugt der instrumentierte Code Ergebnisse für verschiedene Zeitsteuerungsanalysen, welche von einem Berichtgenerator als Analyseergebnisse aufgezeichnet und ausgegeben werden, welche Zeugen (engl. witnesses) enthalten können.
Nutzen des Verfahrens, des Modells und der Werkzeuge, die hierin vorgesehen sind, beinhalten eine hohe Präzision, die durch die Analyse aufgrund der detaillierten Operationsmodelle des Systems erreicht wird, das unter Verwendung mathematischer Formalismen und einer eingehenden Zustandsraum-Exploration beschrieben wird. Skalierbarkeit wird erreicht aufgrund der Verwendung eines diskreten Ereignismodells, insbesondere der Verwendung des Formalismus eines Kalenderautomaten und eines sorgfältigen Entwurfs der Modelle, welche in einer beispielhaften Ausführungsform Promela-Modelle sind, welche viele reguläre Merkmale aufgabengestützter Architekturen ausnutzen. Die formalen Modelle werden optimiert, um Skalierbarkeit ohne Aufgabe bzw. Kompromiss bei der Sorgfalt bzw. Genauigkeit zu erreichen.
Vorteile des Verfahrens und der Werkzeuge, die hierin vorgesehen sind, beinhalten eine automatische Modellerzeugung und -analyse; die Fähigkeit, Operationsdetails wie zum Beispiel Controller-Puffer-Strategien und spezifische Scheduling-Algorithmen im Systementwurf zu behandeln und einzubeziehen, und die Fähigkeit, eine gleichzeitige Analyse mehrerer Aufgaben/Nachrichtenketten durchzuführen, um Probleme einer Zeitsteuerungs-Synchronisierung festzustellen. Ferner liefern das Verfahren und die Werkzeuge eine verbesserte Präzision aufgrund der Fähigkeit zur eingehenden Zustandsraum-Exploration, Skalierbarkeit auf große Systeme mit Sorgfalt bzw. Genauigkeit und der Fähigkeit, Szenarien und Simulationsspuren, worauf auch als Zeugen, Zeugenpfade oder Zeugenspuren verwiesen wird, zu erzeugen, die verwendet werden können, um die Ursachen von Verletzungen einer Zeitsteuerungsanforderung zu identifizieren.
Fundamental für die vorliegende Erfindung ist die Verwendung eines Kalenderautomatenmodells und dessen Instrumentierung für verschiedene Zeitsteuerungsanalysen und ein Optimieren der Codierung des Kalenderautomatenmodells, um den Zustandsraum zu reduzieren, der untersucht werden muss, was ermöglicht, dass man eine Modellierung und Analyse innerhalb einer vernünftigen Zeitspanne und innerhalb vernünftiger Speicheranforderungen ablaufen lässt.
Das Verfahren und die Werkzeuge für eine Zeitsteuerungsanalyse unter Verwendung formaler Methoden wie hierin beschrieben können auch verwendet werden für die Analyse eines beliebigen Systems einschließlich eingebetteter Systeme, die kraftfahrzeugtechnische oder nicht-kraftfahrzeugtechnische Systeme sein können. Das Verfahren und die Werkzeuge, die hierin beschrieben werden, können verwendet werden, um gegenwärtige und antizipierte Anforderungen einer Automotive Open System Architecture (AUTOSAR) und Spezifikationen für eine Architektur einer Fahrzeug-Software zu erfüllen, von denen einige, zum Beispiel Probleme bei einer Zeitsteuerungs-Synchronisierung, mit bestehenden analytischen, simulationsgestützten oder stochastischen Werkzeugen nicht präzise oder sorgfältig analysiert werden können.
Bezug nehmend auf 1 ist bei 100 allgemein ein Verfahren für eine Zeitsteuerungsanalyse unter Verwendung formaler Modelle angegeben. Eine Systembeschreibung 10 ist vorgesehen, welche die Architekturdetails des zu analysierenden eingebetteten Systems beschreibt. In einer beispielhaften Ausführungsform ist das eingebettete System ein elektrisches Steuerungssystem eines Kraftfahrzeugs, das aus mehreren elektronischen Steuerungseinheiten (ECUs) besteht, die durch einen oder mehrere Busse eines Controller-Area-Network (CAN) verbunden sind.
Bezug nehmend auf 2 ist als ein veranschaulichendes Beispiel eine graphische Darstellung eines eingebetteten Systems gezeigt, das einen Satz ECUs, die als E₁ bis E₄ bezeichnet sind, und einen Bus B enthält. Ein Satz Aufgaben ist auf jeder ECU untergebracht, und verschiedene Sätze von Aufgaben sind auf verschiedenen ECUs untergebracht. Zum Beispiel sind Aufgaben τ₁ und τ₂ auf einer ECU E₁ wie in 2 gezeigt untergebracht. Ein Satz Nachrichten, die mit Aufgaben verbunden sind, werden auf einem Bus übertragen. Zum Beispiel sind Nachrichten m₁ bis m₅ einem in 2 dargestellten Bus B zugewiesen. Jede Aufgabe wird durch ein Tupel beschrieben, wobei ein Tupel eine geordnete Liste von Parametern ist, die die Aufgabe beschreiben. Zum Beispiel wird jede Aufgabe beschrieben durch ein Tupel wie <Priorität, Anfangs-Offset, Periode, Ausführungszeit>. Jede Nachricht wird durch ein ähnliches Tupel beschrieben. Die in 3 gezeigte Tabelle zeigt Zuordnungen von Aufgaben/Nachrichten zu ECUs/Bussen und Aufgaben/Nachrichtenbeschreibungen in Tupel-Form, die einen Aufgaben/Nachrichtennamen (o_i) für jede Aufgabe τ_i oder Nachricht m_i, eine Priorität (π_i), einen Anfangs-Offset (O_i), eine Periode (P_i) und eine Ausführungszeit (E_i) enthält. Die Ausführungszeit einer Aufgabe umfasst die Zeit, um Daten zu lesen, zu verarbeiten und auszugeben. Die Ausführungszeit einer Nachricht ist die Übertragungszeit der Nachricht auf einem Bus und kann aus einer Busgeschwindigkeit und der Größe der Nachricht inklusive eines Bit-Stuffing bzw. Bit-Stopfens berechnet werden. Andere Aufgabenparameter können für jede Aufgabe beschrieben werden, wie zum Beispiel eine Deadline bzw. Frist, zu der die Aufgabe ihre Ausführung abschließen muss. Falls all diese Parameter enthalten sind, kann die Aufgabe durch ein Tupel wie zum Beispiel <ECU, Priorität, Anfangs-Offset, Periode, Ausführungszeit, Deadline> beschrieben werden. Das Nachrichten-Tupel kann Parameter enthalten wie <Bus, ID, Anfangs-Offset, Periode, Länge, Deadline>, wobei jede Nachricht beschrieben wird durch den Bus, dem sie zugewiesen ist, beispielsweise ein Hochgeschwindigkeits-Controller-Area-Netzwerk (CAN) mit einer typischen Baud-Rate von 5000 Kilobits pro Sekunde (kbps) oder ein Niedriggeschwindigkeits-CAN mit einer Baud-Rate von 33,3 kbps, die ID als Ausdruck einer Priorität, den Anfangs-Offset und die Periode, die in Bytes ausgedrückte Nachrichtenlänge und die Deadline, ausgedrückt als eine festgelegte Zeitspanne, in der die Nachricht ihr Ziel erreichen muss. Aperiodische oder durch Ereignisse ausgelöste Aufgaben/Nachrichten können ebenfalls unter Verwendung ähnlicher Tupel repräsentiert werden.
Die Systembeschreibung 10 kann ferner bestimmte Eigenschaften oder Parameter spezifizieren, die in den Modellgenerator eingegeben werden sollen, um die Codierung des Kalenderautomatenmodells zu optimieren, sodass der Zustandsraum des Modells, das zu analysieren ist, reduziert wird. Die Beziehungen der Datenabhängigkeit unter einem Satz von Aufgaben und Nachrichten können spezifiziert werden, was eine Beschreibung einschließen kann, wie die Daten von einer Aufgabe/Nachricht zu einer anderen Aufgabe/Nachricht durchgeleitet werden. Die Beziehungen der Datenabhängigkeit unter einem Satz von Aufgaben und Nachrichten des eingebetteten Systems sind in 2 durch die in dem Graphen dargestellten Richtungspfeile (engl. directed edge) veranschaulicht. Ein Richtungspfeil von τ_i zu τ_j spezifiziert, dass die Ausgabe der Aufgabe τ_i eine Eingabe in eine Aufgabe τ_j ist. Als ein Beispiel zeigt, wie in 2 dargestellt ist, in ECU E₂ der Richtungspfeil von τ₇ zu τ₁₁ die Datenabhängigkeit zwischen τ₇ und τ₁₁. Ein Richtungspfeil von τ_i zu m_j spezifiziert, dass die Nachricht m_j eine Ausgabe der Aufgabe τ_i enthält. Ähnlich spezifiziert der Richtungspfeil von m_j zu τ_k, dass die Nachricht m_j eine Eingabe der Aufgabe τ_k enthält. Als Beispiel gibt in der ECU E₂ die Aufgabe τ₁₁ eine Nachricht m₅ aus, die wiederum eine Eingabe in die Aufgabe τ₂ in ECU E₁ ist. Eine Auswahl von Aufgaben/Nachrichtenketten, die die Beziehungen der Datenabhängigkeit in dem Beispielsystem von 2 darstellen, sind in der in 4 dargestellten Tabelle zusammengefasst.
Ein Optimieren des Modells kann ein Filter eines Teils der Systembeschreibung einschließen, der von der Analysespezifikation unabhängig ist, beispielsweise kann ein Optimieren der Codierung ein Modellieren und/oder Analysieren nur jener Aufgaben/Nachrichten einschließen, welche für die spezifizierte Zeitsteuerungsanalyse kritisch sind, wodurch der Typ und die Anzahl von Ereignissen reduziert werden, die in das diskrete Ereignismodell einbezogen werden sollen. Ein Optimieren des Systemmodells 40 reduziert den Zustandsraum im Vergleich zu einem generischen Systemmodell, indem die Ereignisse in dem diskreten Ereignismodell beschränkt werden und indem das Modell basierend auf einer Analysespezifikation 20 instrumentiert wird. Zum Beispiel können drei Ereignisse wie ready, start, finish für jede Aufgabe oder Nachricht modelliert werden. In 5A ist ein Beispielmodell einer Aufgabe τ_i mit drei Ereignissen dargestellt, und in 5B ist ein Beispielmodell einer Nachricht m_i mit drei Ereignissen dargestellt.
Ereignisse können codiert werden, sodass sie zu bekannten, aus den Aufgaben/Nachrichtenparametern bestimmten Zeitpunkten auftreten. Zum Beispiel können die Ereignisse ready, start, finish einer Aufgabe τ_i mit ihren Aktivierungszeiten für eine gegebene Analysespezifikation modelliert werden als:

(ready_i, t): Die Aufgabe τ_i wird nach t Zeiteinheiten von der aktuellen Zeit an ausgelöst

(start_i, t): Die Aufgabe τ_i wird eine Ausführung nach t Zeiteinheiten von der aktuellen Zeit an starten

(finish_i, t): Die Aufgabe τ_i wird eine Ausführung nach t Zeiteinheiten von der aktuellen Zeit an beenden.
Für eine Aktivierung ausgewählter Modelle können Regeln modelliert werden. Zum Beispiel kann eine Regel für einen Zeitfortschritt, auch bekannt als zeitgesteuerter Übergang, vorgesehen werden, welcher von der Systembeschreibung 10 und Analysespezifikation 20 unabhängig sein kann. Die Regel für einen zeitgesteuerten Übergang kann spezifizieren, dass, falls kein Ereignis zur aktuellen Zeit aktiviert werden kann, die Zeit zur nächsten Aktivierungszeit irgendeines Ereignisses voranschreitet. Ein formales Modell der Regel für einen zeitgesteuerten Übergang kann im Kalenderautomaten ausgedrückt werden als: 1. min(C) > 0 ⇒ 2. Δ ← min(C) 3. C ← C – Δ (1) wobei C ein Satz aller Ereignisse zusammen ihren Aktivierungszeiten ist, min(C) die nächste Aktivierungszeit irgendeines Ereignisses in C berechnet und, falls min(C) > 0 gilt, dessen Wert von Aktivierungszeiten aller Einträge in C subtrahiert wird.
Die Regeln für Ereignis-Aktivierungen, auch bekannt als diskrete Übergänge, können beispielsweise von der Systembeschreibung 10 oder Analysespezifikation 20 oder beiden abhängig sein, indem sie von Nachrichten/Aufgaben-Tupeln, Scheduling-Strategien von ECUs/Bussen etc. abhängen. Ein formales Modell der Regel für diskrete Übergänge für ein Ereignis ready kann wie in 6 dargestellt in einem Kalenderautomaten ausgedrückt werden, wo C ein Satz aller Ereignisse mit ihren Aktivierungszeiten ist, Zeile 1 die Bedingung der Ereignisaktivierung repräsentiert und Zeilen 2–21 eine Implementierung von Regeln für eine Bedingung Aufgabe-Bereit repräsentieren.
Regeln oder Strategien können auch modelliert werden für eine Aufgaben- und Nachrichten-Schedulability. Wieder auf 5A und 5B verweisend kann sich zum Beispiel das Modell der Aufgabe, dargestellt in 5A, oder das Modell der Nachricht, dargestellt in 5B, von einem Anfangszustand idle, wenn ein ready-Ereignis aktiviert ist, zu einem Zustand wait bewegen und bei Aktivierung eines Startereignisses zu einem Zustand exec übergehen. Aufgaben können präemptiv geplant werden, wobei eine Aufgabe τ_i durch eine Aufgabe τ_j höherer Priorität unterbrochen (engl. preempt) werden kann. Zum Beispiel kann sich die Aufgabe τ_i, veranschaulicht durch den Graph von 5A, von einem Zustand exec zu einem Zustand wait bewegen, wenn eine Aufgabe τ_j höherer Priorität bereit ist, eine Ausführung zu starten. Wie in 5B veranschaulicht ist, werden CAN-Nachrichten typischerweise nicht-präemptiv geplant, daher gibt es für diese Nachrichten keinen Übergang von einem Zustand exec zu einem Zustand wait.
Ein Optimieren der Codierung kann ferner beinhalten ein Spezifizieren von Eigenschaften wie zum Beispiel einer Ende-zu-Ende-Latenzzeit oder Zeitsteuerungs-Synchronisierung, welche aus der Analysespezifikation 20 erhalten werden. Zum Beispiel sind 7A, 7B und 7C graphische Modelle der Regeln für eine Analyse der Ende-zu-Ende-Latenzzeit einer Kette, wobei 7A, 7B und 7C erste, dazwischenliegende bzw. letzte Aufgaben in einer Kette repräsentieren. Nachrichten in einer Kette können ähnlich modelliert werden.
Ein Optimieren des Systemmodells 40 reduziert den Zustandsraum verglichen mit einem Modell eines generischen Systems, indem die Ereignisse in dem diskreten Ereignismodell beschränkt werden und das Modell basierend auf einer Analysespezifikation 20 instrumentiert wird, wodurch eine Analyse unter Verwendung einer formalen Modellierung und einer eingehenden Zustandsraum-Exploration unter Verwendung eines Modell-Prüfers ermöglicht wird.
Wie in 1 gezeigt ist, wird eine Systembeschreibung 10 an einen Modellgenerator 30 in Verbindung mit einer Analysespezifikation 20 geliefert. Die Analysespezifikation 20 beschreibt die spezifische Zeitsteuerungsanalyse, die für das eingebettete System, das modelliert und analysiert wird, abgeschlossen werden soll. Die Beschreibungen werden unter Verwendung eines Kalenderautomaten oder einer anderen formalen Notation formalisiert. Die Analysespezifikation 20 kann verschiedene Systemparameter und Charakteristiken adressieren, wobei einbezogen ist ein Vorsehen einer Analyse von:

(1) Aufgaben-Antwortzeiten: Aufgaben-Antwortzeiten für den besten Fall und schlechtesten Fall und eine Schedulability-Analyse;
(2) ECU-Nutzung: prozentuale Nutzung von ECU-Berechnungszeit;
(3) Nachrichten-Antwortzeiten: Nachrichten-Antwortzeiten für den besten Fall und schlechtesten Fall und eine Schedulability-Analyse;
(4) Bus-Nutzung: prozentuale Nutzung eines Busses, wie viel Leerlaufzeit übrig ist;
(5) Ende-zu-Ende-Latenzzeit für Aufgaben/Nachrichtenketten: gegeben eine Kette von Aufgaben und Nachrichten, verschiedene Ende-zu-Ende-Latenzzeiten (zum Beispiel FIFO, FILO, LIFO, LILO);
(6) Probleme bei einer Zeitsteuerungs-Synchronisierung in Aufgaben/Nachrichten-Graphen;
(7) maximale Zeittrennung zwischen mehreren Zielen, beginnend von einer einzigen Quelle; und/oder
(8) maximale Zeittrennung zwischen mehreren Quellen, die zu dem gleichen Ziel führen.

Die Analysespezifikation 20 kann ferner Problemspezifikationen und Problemparameter für den Modellgenerator 30 spezifizieren, um das Modell zu optimieren, indem der zu analysierende Zustandsraum reduziert wird, wo zum Beispiel der Umfang von modellierten und getesteten Ereignissen beschränkt ist. Die Analysespezifikation 20 kann typischerweise Spezifikationen einschließen, um die Zeit für Ereignisketten zu messen, einschließlich des Folgenden: Worst case response time of task/messages: ready(t), finish(t)> (2) End-to-end latency of a task/message chain: <ready(t1), finish(t1), ready(t2), finish(t2), .., ready(tn), finish(tn)> (3) Timing Synchronization: <ready(t1), .., finish(tm)> <ready(t1), .., finish(tn)> (4)
Die Analysespezifikation 20 kann auch Fristen bzw. Deadlines und andere Details definieren, die mit den Anforderungen an die Systemanalyse zusammenhängen.
Bei einem in 1 gezeigten Schritt 30 erzeugt der Modellgenerator automatisch ein formales Modell 40 basierend auf einem Kalenderautomaten unter Verwendung der von der Systembeschreibung 10 und der Analysespezifikation 20 des Systems gelieferten Information. Das formale Modell 40 kann in Promela oder irgendeiner anderen geeigneten Modellierungssprache ausgedrückt werden. Das formale Modell 40 hat zwei Teile, ein Systemmodell, das aus der Systembeschreibung 10 abgeleitet wird, und eine Property-Instrumentierung oder Analyse-Instrumentierung, die aus der Analysespezifikation 20 abgeleitet wird. Das formale Modell kann beschrieben werden, indem die Beziehungen der Datenabhängigkeit zwischen den Aufgaben und den Nachrichten für einen Satz Aufgaben und Nachrichten spezifiziert, Scheduling-Strategien für ECUs oder Busse, die im System enthalten sind, vorgesehen und Regeln für eine Ereignisaktivierung vorgesehen werden, wobei die Regeln für eine Ereignisaktivierung zumindest eine Regel enthalten, die einen eines zeitgesteuerten Übergangs oder eines diskreten Übergangs betrifft. Die Analysespezifikation kann während des formalen Modellierungsprozesses verwendet werden, um das Systemmodell weiter zu optimieren, um den zu analysierenden Zustandsraum zu reduzieren.
Das formale Modell 40 kann ferner optimiert werden durch eine Vielzahl von Optimierungstechniken. Eine Optimierungstechnik besteht darin, Teile der Systembeschreibung zu filtern, die von der betrachteten Analysespezifikation von dem Modell unabhängig sind, um den Zustandsraum des Modells zu reduzieren. Wenn zum Beispiel die Analysespezifikation auf eine Schedulability-Analyse für eine spezifische ECU, zum Beispiel ECU E₁, dargestellt in 2, beschränkt ist, kann dann das formale Modell 40 von 1 so gefiltert werden, dass es nur Aufgaben auf der ECU E₁ betreffende Details enthält.
Eine andere hierin vorgesehene Optimierungstechnik, die für eine präemptive Planung mit fester Priorität verwendet werden kann, und typischerweise für präemptiv geplante Aufgaben, besteht darin, die Aufgaben-Antwortzeit dynamisch, zum Beispiel fliegend, zu berechnen. Durch Kombinieren einer Modellprüfung mit einer fliegenden Berechnung von Antwortzeiten für Analysespezifikationen, die Probleme der Ende-zu-Ende-Latenzzeit und/oder Zeitsteuerungs-Synchronisierung einschließen, kann eine signifikante Skalierbarkeit zur Behandlung von Systemen und Problemen im Industriemaßstab ermöglicht werden. In 8 ist ein graphisches Modell dargestellt, das eine fliegende Berechnung einer Aufgaben-Antwortzeit veranschaulicht, wobei man versteht, dass, wann immer eine Aufgabe in einer Kette aktiviert wird, zum Beispiel am Ende einer Periode, die Aufgabe einen Eingabepuffer liest, und am Ende einer Berechnung die Aufgabe ihren Ausgabepuffer aktualisiert. Das Aktualisieren des Ausgabepuffers nimmt infolge von Verzögerungen von Aufgaben höherer Priorität eine unterschiedliche Zeit in Anspruch; daher ist die Aktualisierungszeit tatsächlich gleich der Antwortzeit einer Aufgabe. Die Antwortzeit der Aufgabe kann dynamisch, zum Beispiel fliegend, unter Verwendung der Gleichung berechnet werden:
wo ω die berechnete Antwortzeit von τ_j repräsentiert, spill wie hierin definiert ist, E_j die Ausführungszeit von τ_j im schlechtesten Fall ist, hp(j) der Satz aller Aufgaben mit einer höheren Priorität als τ_j ist, O'_l den nächsten Aktivierungs-Offset von τ_l von der aktuellen Zeit an repräsentiert, T_l die Periode von τ_l repräsentiert und E_l die Ausführungszeit von τ_l im schlechtesten Fall repräsentiert. Überlauf bzw. Spill, in der obigen Gleichung und für einen gegebenen Aufgabenaktivierungsvorgang, ist definiert als die verbleibende Ausführungszeit einer unmittelbaren Aufgabe höherer Priorität, die im Ausführungszustand ist, und kann unter Verwendung des in 9 gezeigten Algorithmus berechnet werden. Da ein Spill-Wert von den verschiedenen Umständen von Aufgaben höherer Priorität abhängig ist, welche aktiviert waren, während die betrachtete Aufgabe aktiviert ist, repräsentiert dessen Berechnung die restliche Verpflichtung von Aufgaben höherer Priorität hinsichtlich einer Ausführung, und dessen Berechnung ist daher nicht trivial.
Noch eine andere Optimierungstechnik oder -strategie, welche auf eine nicht-präemptive Ablaufplanung fester Priorität angewendet werden, die in einem Bus wie zum Beispiel einem CAN-Bus ähnlich dem im System von 2 gezeigten Bus B verwendet wird, besteht darin, die Kalenderautomatenmodelle zu optimieren, indem nur zwei Ereignisse verwendet werden, ein Boole'sches Array, das die Liste von Ready-Nachrichten verfolgt, und eine Zeitgebervariable. Das erste Ereignis wird verwendet, um die verbleibende Übertragungszeit der Nachricht zu verfolgen, die die Arbitrierung jüngst gewann. Das zweite Ereignis ist ein einzelnes zyklisches Timeout-Ereignis, das ausreicht, um eine periodische Aktivierung aller Nachrichten auf dem Bus zu verfolgen. Durch Verwenden dieser Optimierungstechnik anstelle eines Verfolgens der Aktivierungszeit separat für alle Nachrichten, wenn eine Antwortzeit im schlechtesten Fall von Nachrichten analysiert wird, kann der zum Analysieren des CAN-Netzwerks erforderliche Zustandsraum signifikant reduziert werden, was beim Erhöhen der Skalierbarkeit hilft.
Wieder auf 1 Bezug nehmend wird bei Schritt 50 das formale Modell 40 einer eingehenden Zustandsraum-Exploration durch einen Modell-Prüfer unterzogen, um zu bestimmen, ob das Systemmodell der Analysespezifikation entspricht. Der Modell-Prüfer 50 ist so eingerichtet, dass er mit dem Modellgenerator 30 kompatibel ist. Für ein bei Schritten 30 und 40 in einer Promela-Modellierungssprache erzeugtes Modell kann beispielsweise der Modell-Prüfer 50 als der Modell-Prüfer Simple Promela Interpreter (SPIN) ausgebildet sein. Eine Optimierung des Modells, wie vorher diskutiert, gestattet, dass das Modell in einer vernünftigen Zeit und innerhalb vernünftiger Speicheranforderungen untersucht wird. Während einer Untersuchung bzw. Exploration erzeugt der instrumentierte Code Ergebnisse für die vorher diskutierten verschiedenen Zeitsteuerungsanalysen, welche als eine Ausgabe in Form eines Berichts bei Schritt 60 zusammengefasst werden.
Der Bericht, der vom Berichtgenerator bei Schritt 60 erzeugt wird, liegt in für eine Person verständlicher Form vor, einschließlich Analyseergebnisse 70, und kann verwendet werden, um die Erfüllung bzw. Einhaltung der Entwurfsannahmen der Systembeschreibung 10 mit den Spezifikationen und Anforderungen, die in der Analysespezifikation 20 enthalten sind, zu bestimmen. Die Analyseergebnisse 70 können zum Beispiel Ergebnisse enthalten, wie sie in 10A, 10B und 10C dargestellt sind. In 10A sind Analyseergebnisse dargestellt für Antwortzeiten im besten Fall (BCRT) und Antwortzeiten im schlechtesten Fall (WCRT) für jede Aufgabe und Nachricht, beispielsweise für jede in 3 gezeigte Aufgabe/Nachricht. Die Tabelle von 10 liefert Analyseergebnisse für Berechnungen von Last-in-First out (LIFO) Verzögerungen, worauf auch als First-through (FT) für jede Aufgabe/Nachrichtenkette verwiesen wird, die als eine Eingabe in dem Modellgenerator 30 spezifiziert ist, zum Beispiel für jede Aufgabe/Nachrichtenkette, die in 4 gezeigt ist. 10C zeigt Analyseergebnisse für Berechnungen von Last in-Last out (LILO) Verzögerungen, worauf auch als Max-age (MA) für jede Aufgabe/Nachrichtenkette verwiesen wird, spezifiziert als eine Eingabe in den Modellgenerator 30 zum Beispiel für jede in 4 dargestellte Aufgabe/Nachricht.
Die Analyseergebnisse 70 können ferner Simulationsspuren enthalten, auf welche auch als Zeugen verwiesen werden kann, wann immer es eine Verletzung von Zeitsteuerungsbeschränkungen oder -spezifikationen während der Zustandsraum-Exploration gibt. Diese Simulationsspuren können verwendet werden, um bei der Fehlersuche zu helfen, indem die Ursache von Analysestörungen lokalisiert wird und Parameteränderungen identifiziert werden, um die Anomalie aufzulösen. Die Systemarchitektur kann neu entworfen werden, um sicherzustellen, dass Zeitsteuerungsbeschränkungen adressiert bzw. angegangen werden, und die neu entworfene Architektur kann so modelliert und analysiert werden, um zu bestätigen, dass die durch den Zeugen aufgezeichnete Anomalie eliminiert wurde.
Die Fähigkeit, eine eingehende Zustandsraum-Exploration eines Systems zu modellieren und durchzuführen, schafft den Vorteil einer frühen Analyse, sodass Probleme, die man während einer Modellierung findet, genutzt werden können, um den Architekturentwurf des Systems zu korrigieren oder zu verbessern, einschließlich von Änderungen an dem Bus/ECU-Entwurf und der Aufgaben/Nachrichten-Zuordnung, einer Optimierung der ECU/Bus-Nutzung, einer Durchführung einer Schedulability-Analyse, einer Optimierung von Antwortzeiten von Nachrichten und Aufgaben und Lösen von Problemen der Zeitsteuerungs-Synchronisierung in Aufgaben/Nachrichten-Graphen, um sicherzustellen, dass Zeitsteuerungsanforderungen erfüllt werden, und die Systemarchitektur zu optimieren. Diese Systemänderungen können innerhalb eines angemessenen Zeitraums einfach neu bewertet werden, indem die Änderungen in die Systembeschreibung 10 und Analysespezifikation 20 eingebaut und Schritte 30 bis 60 wiederholt werden, um den Einfluss der Änderungen zu bestimmen.
Obgleich die besten Verfahren zum Ausführen der Erfindung im Detail beschrieben wurden, erkennt der Fachmann für die Technik, auf die sich diese Erfindung bezieht, verschiedene alternative Entwürfe und Ausführungsformen, um die Erfindung innerhalb des Umfangs der beigefügten Ansprüche praktisch umzusetzen.

Claims

Verfahren zum Durchführen einer Zeitsteuerungsanalyse eines eingebetteten Systems, mit den Schritten: Liefern einer Systembeschreibung; Liefern einer Analysespezifikation für das System; automatisches Erzeugen eines formalen Modells des Systems aus der Systembeschreibung und der Analysespezifikation unter Verwendung eines Modellgenerators; wobei das formale Modell ein Kalenderautomatenmodell und eine Instrumentierung enthält; Analysieren des formalen Modells des Systems unter Verwendung eines Modell-Prüfers; und Liefern von Ergebnissen der Analyse.
Verfahren nach Anspruch 1, ferner mit dem Schritt: Optimieren des Kalenderautomatenmodells durch zumindest einen der Schritte: dynamisches Berechnen einer Antwortzeit einer Aufgabe; dynamisches Berechnen einer Antwortzeit einer Nachricht; und Filtern der Systembeschreibung unter Verwendung der Analysespezfikation.
Verfahren nach Anspruch 1, wobei ein Liefern der Systembeschreibung beinhaltet: Liefern von Aufgabenparametern für eine Aufgabe; Liefern von Nachrichtenparametern für eine Nachricht; und Liefern von Datenabhängigkeiten unter einem Satz von Aufgaben und Nachrichten.
Verfahren nach Anspruch 1, wobei ein Analysieren des formalen Modells des Systems unter Verwendung eines Modell-Prüfers zumindest einen der Schritte enthält: Spezifizieren der Analyse, die durchgeführt werden soll, unter Verwendung der Analysespezifikation; Analysieren einer Antwortzeit einer Aufgabe; Analysieren einer Antwortzeit einer Nachricht; Analysieren einer Ende-zu-Ende-Latenzzeit einer Aufgaben/Nachrichten-Kette; und Analysieren einer Zeitsteuerungs-Synchronisierung in einem Aufgaben/Nachrichten-Graph.
Verfahren nach Anspruch 1, wobei das eingebettete System eine elektronische Steuerungseinheit (ECU) und einen Bus enthält, wobei das Verfahren ferner zumindest einen der Schritte aufweist: Liefern einer Scheduling-Strategie für die ECU; und Liefern einer Scheduling-Strategie für den Bus.
Verfahren nach Anspruch 1, ferner mit dem Schritt: Liefern einer Regel für eine Ereignisaktivierung; wobei die Regel für eine Ereignisaktivierung einen eines zeitgesteuerten Übergangs und eines diskreten Übergangs betrifft.
Verfahren nach Anspruch 1, wobei die Ergebnisse der Analyse einen Zeugenpfad oder eine Simulationsspur enthalten. Liefern einer Systembeschreibung; Liefern einer Analysespezifikation für das System; automatisches Erzeugen eines formalen Modells des Systems einschließlich eines Kalenderautomatenmodells und einer Instrumentierung; Analysieren des formalen Modells des Systems unter Verwendung eines Modell-Prüfers; und Liefern von Ergebnissen der Analyse.
System zum Durchführen einer Zeitsteuerungsanalyse eines eingebetteten Systems, wobei das System umfasst: eine Beschreibung des eingebetteten Systems, die eine Aufgabe und eine Nachricht enthält; eine Analysespezifikation für das eingebettete System; einen Generator für ein formales Modell, wobei der Generator für ein formales Modell dafür eingerichtet ist, ein formales Modell des eingebetteten Systems und der Analysespezifikation zu erzeugen; wobei das formale Modell ein Kalenderautomatenmodell und eine Instrumentierung enthält; und einen Modell-Prüfer, der dafür eingerichtet ist, das formale Modell zu analysieren und Ergebnisse der Analyse zu liefern.
System nach Anspruch 8, ferner aufweisend: ein optimiertes Kalenderautomatenmodell, wobei das optimierte Kalenderautomatenmodell eines der folgenden enthält: eine dynamische Berechnung einer Antwortzeit einer Aufgabe; eine dynamische Berechnung einer Antwortzeit einer Nachricht; und wobei das optimierte Kalenderautomatenmodell definiert wird, indem die Beschreibung des eingebetteten Systems unter Verwendung der Analysespezifikation gefiltert wird.
System nach Anspruch 8, wobei das eingebettete System mehrere elektronische Steuerungseinheiten (ECUs) enthält, die durch einen oder mehrere Busse verbunden sind, ferner aufweisend: einen Satz von Scheduling-Strategien für die mehreren ECUs und für den einen oder mehrere Busse; und einen Satz Regeln für eine Ereignisaktivierung, wobei der Satz Regeln für eine Ereignisaktivierung eine Regel enthält, die einen eines zeitgesteuerten Übergangs und eines diskreten Übergangs betrifft.