Startseite > Automotive > Infotainment > Modellbasierte Erkennung von Fehlverhalten

Infotainment

Modellbasierte Erkennung von Fehlverhalten

2. November 2012, 9:36 Uhr | Thomas Pramsohler, Dirk Kaule und Annette Paulić

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Schnittstellenzentrierte Betrachtung

Für die Absicherung der Schnittstelle einer Komponente ist nur ihr Blackbox-Verhalten relevant. Zur Verifikation des Verhaltens im Zusammenspiel mit anderen Komponenten wird deshalb bei der schnittstellenzentrierten Betrachtung nur das Verhalten der Komponente modelliert, welches auch an ihrer Schnittstelle beobachtet werden kann. Das bedeutet, dass keine internen Abläufe der Komponente modelliert werden, die nicht im Zusammenhang mit der Kommunikation auf dem Medium stehen. Die resultierenden Modelle werden dadurch kompakt gehalten und sind verständlicher. Das Modell abstrahiert von der eigentlichen Buskommunika-tion und beschreibt lediglich die Interaktion der Komponente mit ihrer Umgebung.

In aktuellen Infotainment-Systemen ist hauptsächlich der MOST-Bus (Media Oriented Systems Transport) mit einem funktionsorientierten Paradigma zu finden. Dabei kapselt ein MOST-Funktionsblock einen bestimmten Funktions-umfang und bietet eine klar definierte Schnittstelle durch die Bereitstellung von Funktionen (Attribute und Methoden). MOST bietet nach dem Client-Server-Muster auch eine Differenzierung zwischen Con-troller und Slaves. Slaves werden durch einen Controller gesteuert und haben selbst kein Systemwissen. In einer XML-basierten Schnittstellen-Beschreibungssprache, dem Funktionskatalog, wird die Struktur eines Funktionsblockes beschrieben. Darin werden die Funktionen und deren Parameter definiert, ebenso welche Funktionen den Notifizierungsmechanismus unterstützen und so bei einer Änderung alle auf diese Funktion registrierten Funktionsblöcke benachrichtigen.

Ein wichtiger Aspekt im Umgang mit Funktionsblöcken ist, dass ein Funktionsblock zusätzlich zur eigentlichen Applikationslogik individuell dafür zuständig ist, das MOST-Protokoll korrekt zu implementieren. So müssen bei der Absicherung grundlegende Abläufe wie beispielsweise der Notifizierungsmechanismus für jeden Funktionsblock erneut auf Korrektheit überprüft werden.

Bei der Verifikation von MOST-Sequenzen werden zwei verschiedene Nachrichtenarten unterschieden:

Stimuli-Nachrichten, die der Controller an den Funktionsblock sendet.
aus den Stimuli resultierende Funktionsblock-Nachrichten, die zurück an den Controller geschickt werden.

Die vorgestellte Verifikationsmethode wurde speziell für den MOST-Bus implementiert und evaluiert. Deshalb wurden auch speziell die für MOST charakteristischen Fehlerarten betrachtet. Folgende Fehler im MOST-Verbund sind besonders häufig und werden durch die vorgestellte Methodik adressiert:

Ausbleibende/fehlerhafte Antwort des Funktionsblocks: Durch einen Fehler in der Implementierung des Funktionsblocks antwortet der Funktionsblock nicht korrekt auf einen korrekten Stimulus des Controllers. Dies kann entweder bedeuten, dass der Funktionsblock gar nicht auf den Stimulus reagiert, oder dass der Funktionsblock mit einer Nachricht antwortet, die nicht mit der spezifizierten Reaktion übereinstimmt. Dabei kann entweder eine falsche MOST-Nachricht gesendet werden oder die Parameter der Nachricht entsprechen nicht der Spezifikation.
Vertauschung der Nachrichtenreihenfolge: Durch eine von der Spezifika-tion abweichende Implementierung des Funktionsblocks kann es zu einer Vertauschung in der spezifizierten Nachrichtenreihenfolge kommen. Dies kann passieren, wenn der Funktionsblock mit mehreren Nachrichten auf einen Stimulus antwortet. Dabei muss die Vertauschung nicht zwangsweise zu einem sichtbaren Fehler führen, sie stellt jedoch eine Abweichung von der Spezifikation dar.
Duplizierte Nachrichten: Durch eine nicht zur Spezifikation konformen Implementierung kann es sowohl auf Seiten des Funktionsblocks als auch auf Seiten des Controllers zu duplizierten MOST-Nachrichten kommen. Das bedeutet, dass eine MOST-Nachricht mehrfach gesendet wird. Auch wenn oft nicht auf eine duplizierte Nachricht reagiert wird, ist dieses Verhalten trotzdem nicht spezifikationskonform und kann Fehler nach sich ziehen.
Ausbleibende Controller-Nachricht: Obwohl kein korrekter Stimulus vom Controller empfangen wurde, sendet der Funktionsblock eine MOST-Nachricht.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Der hier vorgestellte Ansatz zur modellbasierten Erkennung von Fehlverhalten ermöglicht es, die beschriebenen Fehlerfälle zu identifizieren und die Position des Fehlers im Ablauf zu bestimmen. Zur modellbasierten Spezifikation werden dabei UML-Zustands- und Sequenzdiagramme eingesetzt. Diese Modelle beschreiben das Soll-Verhalten des Funktionsblocks. Bild 1 ordnet die einzelnen Artefakte grob in den Entwicklungsprozess des V-Modells ein. Der MOST-Funktionskatalog, der die Schnittstellen der einzelnen Funktionsblöcke spezifiziert, sowie die modellierten Sequenzen bilden die Spezifikation eines MOST-Funktionsblocks und dienen als Basis für das Referenzmodell. Dieses ist ein ausführbares Modell und stellt das spezifizierte Verhalten des Funktionsblocks dar. Damit ist sichergestellt, dass für die Modellierung nur spezifizierte, syntaktisch korrekte Ausdrücke verwendet werden.

Für jeden Funktionsblock existieren genau ein Referenzmodell als Zustandsdiagramm und beliebig viele Sequenzdiagramme. Diese spezifizieren dabei Kommunikationsabläufe zwischen zwei oder mehreren Komponenten. Bild 2 zeigt eine Beispielsequenz, die das erfolgreiche Aufstarten des MOST-Funktionsblocks AuxiliaryInput in Kommunikation mit dem ConnectionManagement beschreibt. Außerdem ist dargestellt, wie das Abspielen eines Musik-Titels, angestoßen durch den Benutzer, an der Komponentenschnittstelle abläuft. Der AuxilaryInputController (der Controller des Funktionsblocks AuxiliaryInput) ist dabei die Head-Unit des Infotainment-Systems. Das Referenzmodell wird manuell aus den Informationen des Funktionskatalogs und der Sequenzdiagramme erstellt. Es beschreibt dabei die Kommunikation aus Sicht einer einzigen Komponente. Sequenzen, wie in Bild 2 dargestellt, beschreiben jeweils einen gültigen Pfad durch das Referenzmodell bzw. einen Teil des Referenzmodells. Durch den engen Zusammenhang zwischen Sequenzen und Referenzmodell wird sichergestellt, dass alle in den Modellen enthaltenen Abläufe auch tatsächlich später auf dem Kommunikationsmedium beobachtet werden können. Diese schnittstellenzentrierte Betrachtung hilft dabei, die Modelle schlank zu halten, da nur das Verhalten an der Schnittstelle modelliert wird. So wird auch die Gefahr verringert, dass das eigentlich als Abstraktion gedachte Modell zu nahe an die tatsächliche Implementierung kommt. Die Zustände im Modell müssen somit nicht mit den später im Steuergerät implementierten Zuständen identisch sein, sondern beschreiben diese aus Kommunikationssicht. Bild 3 zeigt ein Referenzmodell für den MOST-Funktionsblock AuxiliaryInput, welches die in Bild 2 dargestellte Sequenz enthält. Das Referenzmodell entspricht der UML-Statechart-Spezifikation. Dabei sind Zustände rein passive Einheiten, die keine Aktionen enthalten. Die Transitionen beschreiben das Verhalten an der MOST-Schnittstelle und ermöglichen den Übergang von einem zum anderen Zustand. Die Stimuli-Nachrichten, welche vom Controller an den Funktionsblock gesendet werden, bilden die Auslöser der Transitionen (z.B. die Nachricht Allocate_StartResult in Bild 3). Guards an den Transitionen ermöglichen es, das Auslösen eines Zustandsübergangs weiter einzuschränken. So löst in Bild 3 die Nachricht SourceActivity_StartResult [Activity=‘On‘] nur dann einen Zustandsübergang aus, wenn der Guard erfüllt ist, d.h. wenn der Parameter Activity den Wert ‘On‘ hat. Aktionen innerhalb der Transitionen werden verwendet, um die Antwort des Funktionsblocks auf einen Stimulus zu beschreiben. Sobald der Funktionsblock die Nachricht DeckStatus_Set mit Parameter DeckStatus=‘Play‘ erhält, wird in Bild 3 durch die Aktion SEND(Deck-Status_Status(Deck-Status_‘ Play‘)) die Nachricht DeckStatus_Status vom Funktionsblock an den Controller gesendet, wobei der Parameter DeckStatus wieder den Wert ‘Play‘ enthält.