Automatische Überprüfung der Anforderungen des Lastenhefts im Prozess der dynamischen Modellierung

Das Thema fortsetzend „Was sind Ihre Beweise?“, lassen Sie uns das Problem der mathematischen Modellierung von einer anderen Seite betrachten. Nachdem wir unsergestellt haben, dass das Modell der schlichten Wahrheit des Lebens entspricht, können wir die Hauptfrage beantworten: „Was haben wir hier eigentlich?“. Bei der Erstellung eines Modells eines technischen Objekts möchten wir in der Regel sicherstellen, dass dieses Objekt unseren Erwartungen entspricht. Zu diesem Zweck werden dynamische Berechnungen von Prozessen durchgeführt und das Ergebnis mit den Anforderungen verglichen. Das ist der digitale Zwilling, der virtuelle Prototyp und so weiter, modische Konzepte, die in der Entwurfsphase die Aufgabe lösen, wie wir das bekommen, was wir geplant haben.

Wie können wir schnell sicherstellen, dass unser System genau das ist, was wir entwerfen? Wird es fliegen oder schwimmen? Wenn es fliegt, wie hoch? Wenn es schwimmt, wie tief?

In diesem Artikel wird die Automatisierung der Überprüfung der Einhaltung der Anforderungen an ein technisches Gebäude bei der Erstellung dynamischer Modelle technischer Systeme behandelt. Als Beispiel betrachten wir ein Element des technischen Auftrags für das Kühlsystem eines Fluggeräts.

Wir betrachten die Anforderungen, die sich numerisch ausdrücken und mathematisch anhand eines konkreten Berechnungsmodells überprüfen lassen. Es ist klar, dass dies nur ein Teil der allgemeinen Anforderungen an jedes technische System ist, aber genau für deren Überprüfung investieren wir Zeit, Nerven und Geld in die Erstellung dynamischer Modelle des Objekts.

Bei der Beschreibung technischer Anforderungen in Form von Dokumenten können verschiedene Arten von Anforderungen unterschieden werden, von denen jede unterschiedliche Ansätze zur automatischen Überprüfung der Erfüllung erfordert.

Zum Beispiel betrachten wir einen solchen kleinen, aber realen Satz von Anforderungen:

1. Temperatur der Umgebungsluft am Eingang zur SCW:
   im Stand – von minus 35 bis 35 ºC,
   im Flug – von minus 35 bis 39 ºC.
2. Statischer Atmosphärendruck im Flug – von 700 bis 1013 hPa (von 526 bis 760 mm Hg).
3. Gesamtdruck der Luft am Eingang zum Luftansaugstutzen der SCW im Flug – von 754 bis 1200 hPa (von 566 bis 1050 mm Hg).
4. Temperatur der Kühlluft:
   im Stand – nicht höher als 27 ºC, für technische Einheiten – nicht höher als 29 ºC,
   In der Luft – nicht mehr als 25 ºC, für technische Blöcke – nicht mehr als 27 ºC.
5. Luftkühlungsverbrauch:
   am Boden – nicht weniger als 708 kg/h,
   in der Luft – nicht weniger als 660 kg/h.
6. Die Lufttemperatur in den Instrumentenbehältern – nicht mehr als 60 ºC.
7. Die Menge an feiner freier Feuchtigkeit in der Kühlluft – nicht mehr als 2 g/kg trockene Luft.

Selbst in einem so begrenzten Anforderungssatz können mindestens zwei Kategorien unterschieden werden, die im System unterschiedlich behandelt werden müssen:

• Anforderungen an die Betriebsbedingungen des Systems (Punkte 1-3);
• parametrische Anforderungen an das System (Punkte 3-7).

Anforderungen an die Betriebsbedingungen des Systems
Die äußeren Bedingungen für das entwickelte System können bei der Modellierung entweder als Randbedingungen oder als Ergebnis der Gesamt- systemarbeit festgelegt werden.
Bei der dynamischen Modellierung muss sichergestellt werden, dass die angegebenen Betriebsmodi vom Modellierungsprozess abgedeckt werden.

Parametrische Anforderungen an das System
Diese Anforderungen stellen Parameter dar, die von dem System selbst bereitgestellt werden. Im Modellierungsprozess können wir diese Parameter als Berechnungsergebnisse erhalten und sicherstellen, dass die Anforderungen in jeder spezifischen Berechnung erfüllt werden.

Identifizierung und Kodierung von Anforderungen

Zur Erleichterung der Arbeit mit Anforderungen empfehlen bestehende Standards, jedem Requirement eine Identifikationsnummer zuzuweisen. Bei der Zuweisung von Identifikatoren ist es wünschenswert, ein einheitliches Kodierungssystem zu verwenden.

Der Anforderungscode kann einfach eine Zahl sein, die die Reihenfolge der Anforderung widerspiegelt, oder er kann einen Code für den Typ der Anforderung, einen Code für das System oder Aggregat, auf das er angewendet wird, einen Parametercode, einen Lagecode und vieles mehr enthalten, was sich ein Ingenieur vorstellen kann. (Verwendung des Kodierungssystems siehe im Artikel)

Tabelle 1 zeigt ein einfaches Beispiel für die Kodierung von Anforderungen.

1. Anforderungscode R - Anforderungen aus dem Lastenheft;
2. Anforderungstypen-Codes E - Anforderungen - Parameter der Umgebung oder Betriebsbedingungen
   S - Anforderungen, die vom System bereitgestellt werden;
3. Code für den Zustand des Flugzeugs 0 - beliebig, G - am Boden, F - in der Luft;
4. Code für physikalische Parameter T - Temperatur, P - Druck, G - Durchfluss, H - Feuchtigkeit;
5. fortlaufende Nummer der Anforderung.

Projekt des Systems zur Überprüfung der Anforderungen.

Für jede kalkulierte Anforderung gibt es einen Algorithmus zur Bewertung der Übereinstimmung der berechneten Parameter mit den in der Anforderung angegebenen Parametern. Grundsätzlich enthält jedes Managementsystem immer Algorithmen zur Überprüfung der Anforderungen einfach per Standard. Und auch jeder Regler enthält sie. Wenn die Temperatur außerhalb der Grenzen liegt, wird die Klimaanlage eingeschaltet. Somit besteht der erste Schritt jedes Regelungsvorgangs darin, die Übereinstimmung der Parameter mit der Anforderung zu überprüfen.

Wenn die Überprüfung ein Algorithmus ist, können die gleichen Mittel und Werkzeuge verwendet werden, die wir zur Erstellung von Steuerungsprogrammen verwenden. Zum Beispiel ermöglicht die Umgebung SimInTech die Erstellung von Projektpaketen, die verschiedene Teile des Modells enthalten, die als separate Projekte ausgeführt werden (Objektmodell, Steuerungssystemmodell, Umweltmodell usw.).

Das Projekt zur Überprüfung der Anforderungen wird in diesem Fall zu einem solchen Projekt von Algorithmen und wird dem Modellpaket angeschlossen. Und im Modus der dynamischen Modellierung führt es eine Analyse der Übereinstimmung mit den Anforderungen der technischen Spezifikation durch.

Ein mögliches Beispiel für die Gestaltung des Systems wird in Abbildung 1 dargestellt.

Abbildung 1. Beispiel zur Gestaltung des Projekts zur Überprüfung.

Wie bei der Steuerungsalgorithmen können die Anforderungen auch als Satz von Blättern organisiert werden. Zur Vereinfachung der Arbeit mit Algorithmen in strukturellen Modellierungsumgebungen wie SimInTech, Simulink, AmeSim werden Funktionen zur Erstellung von mehrstufigen Strukturen in Form von Submodellen genutzt. Diese Organisation ermöglicht die Gruppierung verschiedener Anforderungen in Sätze, um die Arbeit mit der Anforderungssammlung zu erleichtern, ähnlich wie es bei Steuerungsalgorithmen der Fall ist (siehe Abb. 2).

Abbildung 2. Hierarchische Struktur des Anforderungsprüfungsmodells.

Im betrachteten Fall wurden zwei Gruppen hervorgehoben: Anforderungen für die Umgebung und Anforderungen direkt an das System. Daher wird eine zweistufige Datenstruktur verwendet: zwei Gruppen, von denen jede ein Blatt des Algorithmus ist.

Für den Anschluss von Daten an das Modell wird ein Standardmodell zur Erstellung einer Signal-Datenbank verwendet, in der Daten für den Austausch zwischen den Projektteilen gespeichert werden.

Bei der Erstellung und Testung von Software werden in diese Datenbank die Sensorwerte (Analogwerte realer Sensoren des Systems) eingefügt, die vom Steuerungssystem genutzt werden.
Für das Testprojekt können in dieser Datenbank beliebige Parameter, die im dynamischen Modell berechnet werden, gespeichert werden, um sie zur Überprüfung der Erfüllung der Anforderungen zu verwenden.

Das dynamische Modell kann in diesem Fall in jedem mathematischen Modellierungssystem oder sogar als ausführbare Software umgesetzt werden. Die einzige Voraussetzung ist die Verfügbarkeit von Programmierschnittstellen zur Ausgabe von Modellergebnissen an die externe Umgebung.

Abbildung 3. Anschluss des Testprojekts an das umfassende Modell.

Ein Beispiel für ein grundlegendes Blatt zur Anforderungsüberprüfung ist in Abbildung 4 dargestellt. Aus Sicht des Entwicklers stellt es ein gewöhnliches Berechnungsschema dar, das in grafischer Form den Algorithmus zur Anforderungsüberprüfung zeigt.

Abbildung 4. Blatt zur Anforderungsüberprüfung.

Die Hauptteile des Blattes zur Überprüfung sind in Abbildung 5 beschrieben. Der Überprüfungsalgorithmus wird ähnlich wie die Berechnungsschemata der Steuerungsalgorithmen erstellt. Im rechten Teil befindet sich ein Block zum Auslesen von Signalen aus der Datenbank. In diesem Block erfolgt während der Modellierung der Zugriff auf die Signal-Datenbank.

Die empfangenen Signale werden analysiert, um die Bedingungen für die Überprüfung der Anforderungen zu berechnen. Im vorliegenden Fall wird die Höhe analysiert, um die Position des Flugzeugs zu bestimmen (ob es sich am Boden oder im Flug befindet). Hierfür können auch andere Signale und berechnete Parameter des Modells verwendet werden.

Die Prüfbedingungen und die zu prüfenden Parameter werden an die typischen Prüfblöcke übergeben, in denen eine Analyse der Datenparameter auf die Einhaltung der festgelegten Anforderungen durchgeführt wird. Die Ergebnisse werden in die Datenbank für Signale eingegeben, sodass sie zur automatischen Erstellung einer Checkliste verwendet werden können.

Abbildung 5. Struktur des Berechnungsblatts zur Überprüfung der Anforderungen.

Für die zu prüfenden Parameter müssen nicht unbedingt Signale verwendet werden, die in der Datenbank enthalten sind und die durch in der Modellierung berechnete Parameter gesteuert werden. Nichts hindert uns daran, im Rahmen des Anforderungsprojekts zusätzliche Berechnungen durchzuführen, genau wie wir die Prüfbedingungen berechnen.

Zum Beispiel, eine solche Anforderung:

Die Anzahl der Aktivierungen des Korrektursystems während des Flugs zum Ziel darf 5 nicht überschreiten, und die Gesamtbetriebszeit des Korrektursystems darf 30 Sekunden nicht überschreiten.

In diesem Fall wird ein Zähleralgorithmus zur Berechnung der Anzahl der Aktivierungen und der Gesamtbetriebszeit zum Anforderungsschema hinzugefügt.

Typischer Prüfblock für Anforderungen.

Jeder typische Prüfblock für Anforderungen dient zur Berechnung der Erfüllung einer bestimmten Anforderung. Beispielsweise gibt es in den Umweltanforderungen einen Temperaturbereich für die Außentemperatur am Boden und im Flug. Dieser Block sollte als Parameter die Lufttemperatur im Modell erhalten und feststellen, ob dieser Wert im festgelegten Temperaturbereich liegt.

Der Block enthält zwei Eingangsporte, param und condition.

Am ersten wird der zu prüfende Parameter angelegt. In diesem Fall die „Äußere Temperatur“.

Am zweiten Port wird eine boolesche Variable - die Bedingung für die Durchführung der Überprüfung - übergeben.

Wenn am zweiten Eingang TRUE (1) ankommt, berechnet der Block die Überprüfung der Anforderung.

Wenn am zweiten Eingang FALSE (0) ankommt, werden die Prüfbedingungen nicht erfüllt. Dies ist notwendig, um die Berechnungsbedingungen berücksichtigen zu können. In unserem Fall wird dieser Eingang verwendet, um die Prüfung abhängig vom Zustand des Modells ein- oder auszuschalten. Wenn das Flugzeug während der Modellierung am Boden ist, werden die flugbezogenen Anforderungen nicht überprüft, und umgekehrt – wenn das Flugzeug im Flug ist, werden die Anforderungen, die mit dem Betrieb am Boden verbunden sind, nicht geprüft.

Dieser Eingang kann auch zur Modellanpassung verwendet werden, beispielsweise in der Anfangsphase der Berechnung. Wenn das Modell in den erforderlichen Zustand versetzt wird, sind die Prüfblöcke deaktiviert. Sobald das System jedoch in den erforderlichen Betriebsmodus übergeht, werden die Prüfblöcke aktiviert.

Als Parameter dieses Blocks werden festgelegt:

• Grenzbedingungen: obere (UpLimit) und untere (DownLimit) Grenzen der Bereiche, die geprüft werden müssen;
• die erforderliche Haltezeit des Systems an den Grenzbereichen (TimeInterval) in Sekunden;
• die Anforderung-ID ReqName;
• die Zulässigkeit des Überschreitens des Bereichs Out_range – eine boolesche Variable, die angibt, ob es sich bei der Überschreitung des Wertes über den geprüften Bereich um einen Verstoß gegen die Anforderung handelt.

In einigen Fällen bedeutet das Überschreiten des geprüften Wertes, dass das System Spielraum hat und außerhalb des Betriebsbereichs arbeiten kann. In anderen Fällen bedeutet es, dass das System die vorgegebenen Parameter im Bereich nicht einhalten kann.

Abbildung 6. Typischer Prüfblock für Eigenschaften im Diagramm und seine Parameter.

Als Ergebnis der Berechnung dieses Blocks wird eine Variable Result erzeugt, die folgende Werte annehmen kann:

• 0 – rNone, Wert nicht definiert;
• 1 – rDone, Anforderung wird erfüllt;
• 2 – rFault, Anforderung wird nicht erfüllt.

Das Bild des Blocks enthält:

• Text der Identifikation;
• digitale Anzeigen der Messbereichsgrenzen;
• farbige Kennung des Parameterstatus.

Innerhalb des Blocks kann sich ein recht komplexes logisches Ausgabemuster befinden.

Zum Beispiel wird zur Überprüfung des funktionalen Temperaturbereichs des Blocks, der in Abbildung 6 dargestellt ist, das interne Muster in Abbildung 7 dargestellt.

Abbildung 7. Internes Schema des Temperaturbereichsbestimmungsblocks.

Innerhalb des Blocks werden Eigenschaften verwendet, die in den Blockparametern festgelegt sind.
Neben der Analyse der Übereinstimmung der Anforderungen enthält das interne Schema des Blocks ein Diagramm, das für die Ausgabe der Simulationsergebnisse erforderlich ist. Dieses Diagramm kann sowohl während der Berechnung zur Ansicht als auch zur Analyse der Ergebnisse nach der Berechnung verwendet werden.

Die Berechnungsergebnisse werden an den Ausgang des Blocks übertragen und gleichzeitig in eine gemeinsame Berichtdatei geschrieben, die auf Grundlage der Ergebnisse des gesamten Projekts erstellt wird. (siehe Abb. 8)

Ein Beispiel für einen Bericht, der auf den Simulationsergebnissen basiert, ist eine HTML-Datei, die nach einem festgelegten Format erstellt wurde. Das Format kann beliebig auf das von einer bestimmten Organisation akzeptierte Format angepasst werden.

Innerhalb des Blocks werden Eigenschaften verwendet, die in den Blockparametern festgelegt sind.
Neben der Analyse der Übereinstimmung der Anforderungen enthält das interne Schema des Blocks ein Diagramm, das für die Ausgabe der Simulationsergebnisse erforderlich ist. Dieses Diagramm kann sowohl während der Berechnung zur Ansicht als auch zur Analyse der Ergebnisse nach der Berechnung verwendet werden.

Die Berechnungsergebnisse werden an den Ausgang des Blocks übertragen und gleichzeitig in eine gemeinsame Berichtdatei geschrieben, die auf Grundlage der Ergebnisse des gesamten Projekts erstellt wird. (siehe Abb. 8)

Ein Beispiel für einen Bericht, der auf den Simulationsergebnissen basiert, ist eine HTML-Datei, die nach einem festgelegten Format erstellt wurde. Das Format kann beliebig auf das von einer bestimmten Organisation akzeptierte Format angepasst werden.

Abbildung 8. Beispiel einer Berichtdatei zu den Simulationsergebnissen.

In diesem Beispiel erfolgt die Anpassung des Berichtformats direkt in den Eigenschaften des Projekts, während das Format in der Tabelle als globale Signale des Projekts festgelegt wird. In diesem Fall übernimmt SimInTech selbst die Aufgabe der Berichtsanpassung, und der Block zum Speichern der Ergebnisse in einer Datei verwendet diese Zeilen zum Schreiben in die Berichtdatei.

Abbildung 9. Anpassung des Berichtformats in den globalen Signalen des Projekts.

Verwendung der Signaldatenbank für Anforderungen.

Um die Arbeit mit den Eigenschaften der Einstellungen für jeden Standardblock zu automatisieren, wird eine standardisierte Struktur in der Signaldatenbank erstellt. (siehe Abb. 10)

Abbildung 10. Beispiel für die Struktur eines Anforderungskontrollblocks in der Signaldatenbank.

Die Signaldatenbank stellt sicher:

• Die Speicherung aller notwendigen Parameter für die Anforderungen an das System.
• Die bequeme Ansicht der bestehenden Anforderungen im Projekt basierend auf festgelegten Parametern und den aktuellen Ergebnissen der Simulation.
• Die Anpassung eines Blocks oder einer Gruppe von Blöcken unter Verwendung einer Programmiersprache. Änderungen in der Signaldatenbank führen zu einer Änderung der Werte der Blockeigenschaften im Schema.
• Die Speicherung von Textbeschreibungen, Links zu Punktzahlen oder IDs im Requirements Management System.

Die Strukturen der Signaldatenbank für Anforderungen können leicht auf die Arbeit mit einem externen Requirements Management System eingestellt werden. Das allgemeine Interaktionsschema mit den Requirements Management Systemen ist in Abbildung 11 dargestellt.

Abbildung 11. Schema der Interaktion mit dem Requirements Management System.

Die Interaktion des Testprojekts SimInTech mit dem Anforderungsmanagementsystem verläuft wie folgt:

1. Das Lastenheft wird in Anforderungen unterteilt.
2. Solche Anforderungen des Lastenhefts, die durch mathematische Modellierung technischer Prozesse überprüft werden können, werden identifiziert.
3. Die Attribute der identifizierten Anforderungen werden in die Datenbank der SimInTech-Signale in Strukturen typischer Blöcke übertragen (zum Beispiel maximale und minimale Temperatur).
4. Im Berechnungsprozess werden die Daten der Strukturen an die Berechnungsschemata der Blöcke übermittelt, eine Analyse wird durchgeführt und die Ergebnisse werden in der Signaldatenbank gespeichert.
5. Nach Abschluss der Berechnung werden die Analyseergebnisse an das Anforderungsmanagementsystem übermittelt.

Die Schritte 3 bis 5 bei den Anforderungen können während des Entwurfsprozesses wiederholt werden, wenn Änderungen an der Konstruktion und/oder den Anforderungen auftreten, und entsprechend eine erneute Überprüfung der Auswirkungen der vorgenommenen Änderungen erforderlich ist.

Fazit.

• Der erstellte Prototyp des Systems ermöglicht eine signifikante Verkürzung der Zeit für die Analyse bestehender Modelle hinsichtlich der Übereinstimmung mit den Anforderungen des Lastenhefts.
• Die vorgeschlagene Testtechnologie nutzt bereits vorhandene dynamische Modelle und kann sogar für beliebige dynamische Modelle verwendet werden, die nicht in der Umgebung von SimInTech erstellt wurden.
• Die Nutzung einer paketierten Datenorganisation ermöglicht es, Prüfpakete für Anforderungen parallel zur Entwicklung von Modellen zu erstellen oder diese Pakete sogar als Lastenheft für die Modellentwicklung zu verwenden.
• Die Technologie kann ohne wesentliche Kosten in bestehende Anforderungsmanagementsysteme integriert werden.

Für diejenigen, die bis zum Ende gelesen haben, hier ist der Link zu einem Video mit einer Demonstration der Arbeit des Prototyps.

Quelle: habr.com