Verwenden von Modellierung und Simulation zum Testen von Designs und Anforderungen

Die Modellierung ist eine effiziente und kostengünstige Möglichkeit, ein reales System darzustellen. Ein Modell kann Schlüsselaspekte des Systems darstellen, wie z. B. die zugrunde liegenden Anforderungen, die Komponenten und wie diese Komponenten miteinander kommunizieren. Das Modell kann simuliert werden, sodass Designer Designs testen können, bevor Hardware verfügbar ist, oder Bedingungen testen, die in der realen Welt schwierig oder teuer zu replizieren sind. Die Iteration zwischen Modellierung und Simulation kann die Qualität des Systemdesigns in einem frühen Stadium verbessern und so die Anzahl der später im Designprozess entdeckten Fehler reduzieren.

Trotz dieser Vorteile nutzen Designer, die sich hauptsächlich auf Handcodierung verlassen, nicht immer die Vorteile von Modellierung und Simulation. Die Testeinrichtung kann schwierig und zeitaufwändig sein, und wenn für jede Domäne separate Tools verwendet werden, kann es schwierig sein, eine Entwurfsansicht auf Systemebene zu erhalten. Infolgedessen werden Fehler, die möglicherweise während der Modellierungs- und Simulationsphase entdeckt wurden, häufig in der Implementierungsphase gefunden, in der es teurer ist, sie zu beheben.

Diese Probleme wurden in Simulink®, einer Plattform für Modellierung und Simulation, angegangen. Simulink unterstützt nicht nur Multidomänenmodellierung, sondern auch Simulation mit einem eigenen Satz von Solvern für gewöhnliche Differentialgleichungen (ODE). Ein grundlegender Vorteil der Verwendung von Simulink besteht darin, dass Sie verschiedene Domänen wie Steuerungssysteme, Zustandsmaschinen und Umgebungsmodelle in einem einzigen Modell darstellen und dann Simulationen in Simulink ausführen können, um zu überprüfen, ob das Modell korrekt erstellt wurde. Während die Simulation ausgeführt wird, können Sie auf Analysefunktionen wie Datenvisualisierungen, Statusanimationen und bedingte Haltepunkte zugreifen. Nach Abschluss der Simulation können die aufgezeichneten Daten mit MATLAB-Skripten und Visualisierungstools analysiert werden.

In diesem Artikel beschreiben wir einen Arbeitsablauf zum Erstellen eines Komponentenmodells aus Anforderungen, zum Simulieren und Testen dieses Komponentenmodells und zum anschließenden Verbinden mit einem Modell auf Systemebene für weitere Simulationen und Tests. Um diesen Arbeitsablauf zu veranschaulichen, werden wir die Fehlermanagementkomponente des HL-20 bauen und testen, eines Wiedereintrittsfahrzeugs, das von der NASA als Ergänzung zum Space-Shuttle-Orbiter entwickelt wurde. Wir werden unsere Komponente mit einem Modell auf Systemebene verbinden, das Umgebungsmodelle und Flugsteuerungen sowie Führung, Navigation und Steuerung (GNC) umfasst; Später werden wir das Modell auf Systemebene simulieren, um sein Verhalten zu validieren.

Das in diesem Beispiel verwendete Modell ist im Aerospace Blockset verfügbar.

Erstellen des Komponentenmodells aus den Anforderungen

Der erste Schritt besteht darin, die Fehlermanagementlogik des Aktuatorsystems zu modellieren. Das Anforderungsdokument gibt fünf mögliche Modi für den Aktor an: Passiv, Standby, Aktiv, Isoliert und Aus. Der Einfachheit halber betrachten wir nur die ersten vier Modi. Wir stellen diese Modi dar, indem wir einem Stateflow®-Zustandsdiagramm vier Zustände hinzufügen (Abbildung 1).

Als nächstes müssen wir bestimmen, wie das System von einem Zustand (oder Modus) in einen anderen übergeht. Anhand der im Anforderungsdokument bereitgestellten Informationen fügen wir Übergänge hinzu, die die Zustände verbinden, und geben an, welche Bedingungen erfüllt sein müssen, damit das System Zustände ändert. Außerdem gruppieren wir die Zustände „Passiv“, „Aktiv“ und „Warten“ in einem einzigen Superzustand, da sie alle in den Zustand „Isoliert“ wechseln, wenn dieselbe Bedingung eintritt. Diese hierarchische Modellierungstechnik hilft uns, komplexe Logik auf visuelle und einfache Weise zu modellieren (Abbildung 2).

Wir bauen das Modell weiter und verbinden jedes Element mit einer bestimmten Systemanforderung (Abbildung 3). Später können wir in unserem Modell auf das Anforderungsdokument zurückgehen, um zu erklären, warum eine bestimmte Designentscheidung getroffen wurde.

Sobald wir die Logik für den linken inneren Aktuator erstellt haben, können wir dieses Design für den rechten inneren Aktuator wiederverwenden, da die Struktur genau gleich ist. Die einzigen Elemente, die geändert werden müssen, sind die Bedingungen für jeden Übergang, wie im Anforderungsdokument beschrieben (Abbildung 4).

Bauteilprüfung durch Simulation

Jetzt, da die Komponente teilweise gebaut ist, können wir Simulationen ausführen, um zu überprüfen, ob sie sich korrekt verhält. Dazu bauen wir ein einfaches Testframework auf, das über eine Kombination aus Konstanten und Schaltblöcken Eingangssignale an das Bauteil bringt (Bild 5).

Mit Simulink und Stateflow können wir die Simulation starten, ohne Variablen manuell definieren zu müssen. Wenn Sie auf die Play-Schaltfläche klicken, erscheint ein Dialogfeld mit den Variablen, die definiert werden müssen, damit die Simulation ausgeführt werden kann. Durch Klicken auf OK werden diese Variablen automatisch erstellt (Abbildung 6).

Während die Simulation läuft, wird das Zustandsdiagramm zu einer Animation, die uns mitteilt, welcher Zustand gerade aktiv ist und wie das System von einem Zustand in einen anderen übergeht.

Ein Ad-hoc-Test durch Ein- oder Ausschalten von Eingangssignalen deckt einen Fehler im Design auf (Abbildung 7). Wenn der linke innere Aktuator aktiviert wird, sollte auch der rechte innere Aktuator aktiviert werden. Die Tatsache, dass wir die Eingabebedingungen so konfigurieren konnten, dass dies nicht auftritt, weist darauf hin, dass unser Design fehlerhaft ist.

Es stellt sich heraus, dass die Bedingung des Übergangs von Active nach Standby fehlerhaft ist. Da wir jede Bedingung mit einer Anforderung verknüpft haben, können wir von dieser Bedingung zur zugrunde liegenden Anforderung zurückkehren und überprüfen, ob der Fehler im Anforderungsdokument und nicht im Design liegt (Abbildung 8).

Die letzte Zeile sollte lauten „oder der linke innere Aktuator befindet sich im aktiven Modus“.

Wir korrigieren den Wortlaut des Anforderungsdokuments, überprüfen den Zustand, simulieren das Modell neu und prüfen, ob sich das System nun korrekt auf Eingangssignale verhält.

Systemcheck mit der neuen Komponente

Nachdem die FDIR-Komponente nun unabhängig verifiziert wurde, sind wir bereit, sie im Modell auf Systemebene zu testen. Wir betten die Komponente in Form eines Modellblocks mit dem Namen FDIR_application in das Modell ein. Sobald das Modell in das Systemmodell integriert ist, können wir mithilfe der Modellreferenzierungsfunktion von Simulink unabhängig vom Rest des Systems weiter daran arbeiten (Abbildung 9).

Wir simulieren das Modell auf Systemebene und visualisieren das Verhalten der Komponente im Zustandsdiagramm sowie das Verhalten des Gesamtsystems mit FlightGear, einem Open-Source-Visualisierungstool.

Um das System zu testen, richten wir ein Framework ein, das Fehler in das Aktuatorsystem einspeist, sodass wir überprüfen können, ob sowohl die Komponente als auch das System als Ganzes korrekt reagieren (Abbildung 10).

Bisher haben wir eine Komponente aus den Anforderungen erstellt, diese Komponente simuliert und getestet und sie dann für weitere Simulationen und Tests mit einem Modell auf Systemebene verbunden. Es gibt eine Reihe zusätzlicher Schritte, die wir unternehmen können, um unseren Modellierungs- und Simulationsworkflow zu verbessern.

Zum Beispiel können wir Folgendes tun:

• Implementieren Sie einen formellen Test- und Verifizierungsprozess mit Designtests, Abdeckungsanalyse und Testfallgenerierung.

• Erhöhen Sie die Simulationsleistung mit dem Performance Advisor in Simulink.

• Ersetzen Sie Blöcke durch Hardwareverbindungen, sobald Hardware verfügbar wird.

• Verwenden Sie Tools, um zu überprüfen, ob die Designparameter optimal sind.

Welcher nächste Schritt auch immer gewählt wird, der Schlüssel liegt darin, das System so oft und so schnell wie möglich zu modellieren, zu simulieren und zu testen, um Fehler frühzeitig zu erkennen und zu beheben und so die Implementierungskosten des Gesamtsystems zu reduzieren.