So bekommen Sie Stateflow mit Modellierungsrichtlinien in den Griff

Stateflow einsetzen: Ergebnisse der Umfrage

Verbreitung von Stateflow in der modellbasierten Entwicklung

Im Jahr 2022 haben wir in Zusammenarbeit mit 30 Praxis-Expert:innen aus Unternehmen wie der Mercedes-Benz Group AG, der Bosch-Gruppe, der Continental AG und anderen eine auf Stateflow ausgerichtete Umfrage durchgeführt.

Zunächst wollten wir wissen, ob Fachleute in der modellbasierten Entwicklung Stateflow einsetzen. Die Ergebnisse zeigen, dass die meisten Anwender:innen Stateflow in 20 bis 50 Prozent ihrer Modelle verwenden.

Bevorzugte „Action Language“ in Stateflow

Die zweite Frage bezog sich auf die verwendete „Action Language“. Das nachfolgende Kreisdiagramm zeigt deutlich, dass die meisten Anwender:innen MATLAB gegenüber C bevorzugen. Gründe dafür sind die einfachere Nutzung und die enge Integration in das Simulink-Ökosystem.

Häufige Herausforderungen bei der Nutzung von Stateflow

Anschließend fragten wir nach den größten Schwierigkeiten beim Arbeiten mit Stateflow. Die häufigste Antwort war fehlendes Wissen. Gleichzeitig gab ein beachtlicher Teil der Teilnehmer:innen an, keine Probleme zu haben. Fehlende Funktionen wurden am seltensten genannt. Das deutet darauf hin, dass vor allem Schulungen und bessere Dokumentation helfen können.

Stateflow für arithmetische Berechnungen

Die vierte Frage bezog sich auf den Einsatz von Stateflow für arithmetische Berechnungen. Eine Mehrheit von 56 % bejahte diese Frage. Dies unterstreicht die Vielseitigkeit des Tools bei der Bewältigung komplexer Berechnungen, wie sie in Automobilsystemen häufig erforderlich sind.

Häufig verwendete Stateflow-Elemente und -Muster

Zum Schluss fragten wir nach den am häufigsten verwendeten Stateflow-Elementen und -Mustern. Die Ergebnisse zeigten eine relativ gleichmäßige Verteilung. „Statecharts“ und „Condition Actions“ wurden etwas häufiger genutzt, während „Boxes“ die geringste Verbreitung aufwiesen. Das deutet auf eine klare Präferenz für strukturierte und bedingungsbasierte Modellierung hin, insbesondere bei der Umsetzung von Entscheidungslogik.

10 Methoden für bessere Stateflow-Modelle

1. Korrekte Syntax für „Transition Labels“ sicherstellen

Eine saubere Syntax für „Transition Labels“ verbessert Lesbarkeit, Wartbarkeit und Vorhersagbarkeit von Stateflow-Modellen. Gleichzeitig unterstützt sie eine korrekte Codegenerierung in Werkzeugen wie TargetLink.

Die Bestandteile eines „Transition Labels“ sind:

• „Event“: Definiert ein Ereignis, das den Übergang auslöst
• „Condition“: Definiert einen booleschen Ausdruck, der den Übergang erlaubt
• „Condition Action“: Wird ausgeführt, sobald die Bedingung wahr ist
• „Transition Action“: Wird ausgeführt, nachdem das Ziel des Übergangs validiert wurde

Eine mögliche Syntax lautet: trigger [condition] {condition_action} / transition_action.

Es müssen nicht alle Bestandteile verwendet werden. Empfehlenswert ist es, „Events“ möglichst zu vermeiden und stattdessen „Conditions“ zu nutzen, da diese dem Standard entsprechen. Außerdem sollte bewusst zwischen „Condition Actions“ und „Transition Actions“ entschieden werden.

2. Das sichere „Subset“ der Modellierungssprache verwenden

Basierend auf den Modellierungsrichtlinien: mes_slsf_3110 | misra_slsf_047_ab | misra_slsf_046_a

„History Junctions“ sollten vermieden werden, da sie:

• Fehlinterpretationen des Modells verursachen können
• den Validierungsprozess erschweren
• Funktionalität verstecken und die Wartbarkeit verschlechtern
  

Das folgende Bild zeigt eine „History Junction“ gekennzeichnet mit dem Symbol „H“. Dies könnte zu den zuvor erwähnten Fehlern führen.

3. „Condition Actions“ und „Transition Actions“ korrekt einsetzen

Basierend auf den Modellierungsrichtlinien: misra_slsf_045_e | misra_slsf_045_f | misra_slsf_045_g

Vermeiden Sie es, Variablen in „Condition Actions“ und „Transition Actions“ zu schreiben. Änderungen an Variablen in diesen Bereichen können unerwartetes Verhalten verursachen und das Debugging erschweren.

4. Kreuzende Übergänge in Stateflow vermeiden

Basierend auf der Modellierungsrichtlinie: mes_slsf_3109

„Transitions“ sollten keine Zustandsgrenzen kreuzen. Solche Kreuzungen erschweren die Lesbarkeit des Charts und erhöhen das Risiko von Fehlinterpretationen und Modellierungsfehlern.

Zusätzlich erschwert ein unübersichtliches Layout Debugging und Wartung. Durch logisch organisierte „Transitions“ und klare Pfade verbessern Sie Lesbarkeit, Wartbarkeit und Zuverlässigkeit Ihrer Stateflow-Modelle.

In den folgenden Grafiken sind Übergänge zu erkennen, die parallele Zustandsgrenzen überschreiten. Es ist äußerst wichtig, solche Überschneidungen zu vermeiden, da sie zu Verwirrung und möglichen Modellierungsfehlern führen können.

6. „Backtracking“ in Stateflow vermeiden

Basierend auf den Modellierungsrichtlinien: mes_sf_002 | misra_slsf_043_h

Stateflow unterstützt kein „Backtracking“. Bereits ausgeführte Aktionen bleiben wirksam, selbst wenn der Übergangspfad den vorgesehenen Endzustand nicht erreicht. Das kann zu unerwartetem Verhalten führen.

Um solche Probleme zu vermeiden, sollte jeder Übergangspfad einen bedingungslosen Default Pfad besitzen. Außerdem sollten „Condition Actions“ nur im letzten Abschnitt eines Übergangs verwendet werden oder alternativ „Transition Actions“ eingesetzt werden.

(Wie in Abschnitt 3 erläutert, gibt es gute Gründe, sich für Übergangsmaßnahmen zu entscheiden.)

Beispiel für ein „Backtracking“-Problem:

7. Best Practices zum Befolgen der Ausführungsreihenfolge

Basierend auf der Modellierungsrichtlinie: mes_is_0002

Stateflow definiert die Ausführungsreihenfolge standardmäßig im Uhrzeigersinn, insbesondere bei parallelen Zuständen. Schon kleine Änderungen am Layout oder das Hinzufügen neuer Elemente können die Ausführungsreihenfolge verändern.

Die folgende Grafik veranschaulicht, wie sich die Ausführungsreihenfolge der Übergänge in einem Stateflow-Diagramm ändert, wenn ein neues Ereignis (Event1) eingeführt wird, und verdeutlicht damit, wie wichtig es ist, die Ausführungsreihenfolge manuell festzulegen.

8. Globale Stateflow-Funktionen vermeiden

Basierend auf der Modellierungsrichtlinie: mes_slsf_3106

Stateflow-Funktionen sollten lokal innerhalb des jeweiligen Charts definiert werden. Das verbessert die Modularität und verhindert unbeabsichtigte Wechselwirkungen.

Die Funktion „Export Chart Level Functions (Make Global)“ erlaubt einen globalen Zugriff auf grafische Funktionen innerhalb des gesamten Modells. Diese Funktionen lassen sich jedoch nur schwer nachverfolgen und führen zu intransparentem Verhalten.

Auch die Option „Allow exported functions to be called by Simulink“ sollte nicht aktiviert werden, da sie zusätzliche Komplexität bei Datenfluss und Funktionsverwaltung erzeugt.

9. Rekursive Schleifen vermeiden

Basierend auf der Modellierungsrichtlinie: jc_0804

Um unbeabsichtigtes Verhalten zu vermeiden und die Modellintegrität zu gewährleisten, ist es von entscheidender Bedeutung, dass grafische Funktionen in Stateflow weder rekursiv definiert werden noch andere grafische Funktionen aufrufen. Rekursive Aufrufe können zu Endlosschleifen, Stapelüberläufen und einer erhöhten Komplexität bei der Fehlersuche und Wartung führen.

Das folgende Diagramm veranschaulicht ein Problem mit rekursiven Schleifen in grafischen Stateflow-Funktionen. Bei der Ausführung von func1(x) wird func2(x) aufgerufen, das wiederum func1(x) aufruft, wodurch eine unendliche Rekursion entsteht. Um dieses Problem zu vermeiden, wird empfohlen, direkte oder indirekte rekursive Funktionsaufrufe in grafischen Stateflow-Funktionen zu vermeiden.

10. Eingangsvariablen explizit definieren

Beim Arbeiten mit TargetLink, Simulink und Stateflow sollten Eingangsvariablen explizit definiert werden, um eine konsistente und klar strukturierte Schnittstelle sicherzustellen.
Der TargetLink Property Manager von dSPACE unterstützt dabei, Variablendefinitionen zentral zu verwalten und Konsistenz zwischen Modell und Implementierung sicherzustellen.