Automatische Überprüfung der TOR-Anforderungen im Prozess der dynamischen Simulation

Fortsetzung des Themas "Was ist Ihr Beweis?"Schauen wir uns das Problem der mathematischen Modellierung von der anderen Seite an. Nachdem wir überzeugt sind, dass das Modell der einfachen Wahrheit des Lebens entspricht, können wir die Hauptfrage beantworten: „Was genau haben wir hier?“ Wenn wir ein Modell eines technischen Objekts erstellen, möchten wir normalerweise sicherstellen, dass dieses Objekt unseren Erwartungen entspricht. Hierzu werden dynamische Berechnungen von Prozessen durchgeführt und das Ergebnis mit den Anforderungen verglichen. Hierbei handelt es sich um einen digitalen Zwilling, einen virtuellen Prototyp usw. modische kleine Kerle, die bereits in der Entwurfsphase das Problem lösen, wie wir sicherstellen können, dass wir das bekommen, was wir geplant haben.

Wie können wir schnell sicherstellen, dass unser System genau dem entspricht, was wir entwerfen? Wird unser Design fliegen oder schweben? Und wenn es fliegt, wie hoch? Und wenn es schwimmt, wie tief?

In diesem Artikel geht es um die Automatisierung der Überprüfung der Einhaltung der Anforderungen eines technischen Gebäudes bei der Erstellung dynamischer Modelle technischer Systeme. Schauen wir uns als Beispiel ein Element der technischen Spezifikation für ein Flugzeug-Luftkühlsystem an.

Wir berücksichtigen solche Anforderungen, die sich anhand eines konkreten Berechnungsmodells numerisch ausdrücken und mathematisch verifizieren lassen. Es ist klar, dass dies nur ein Teil der allgemeinen Anforderungen an ein technisches System ist, aber gerade 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 eines Dokuments lassen sich mehrere Arten unterschiedlicher Anforderungen unterscheiden, die jeweils unterschiedliche Ansätze zur Bildung einer automatischen Überprüfung der Anforderungserfüllung erfordern.

Betrachten Sie zum Beispiel diese kleinen, aber realistischen Anforderungen:

1. Atmosphärische Lufttemperatur am Eingang der Wasseraufbereitungsanlage:
   auf dem Parkplatz - von minus 35 bis 35 ºС,
   im Flug - von minus 35 bis 39 ºС.
2. Der statische Druck der atmosphärischen Luft im Flug beträgt 700 bis 1013 GPa (526 bis 760 mm Hg).
3. Der Gesamtluftdruck am Eingang zum SVO-Lufteinlass beträgt im Flug 754 bis 1200 GPa (von 566 bis 1050 mm Hg).
4. Kühllufttemperatur:
   auf dem Parkplatz - nicht mehr als 27 ºС, für technische Blöcke - nicht mehr als 29 ºС,
   im Flug - nicht mehr als 25 ºС, für technische Blöcke - nicht mehr als 27 ºС.
5. Kühlluftstrom:
   im geparkten Zustand - mindestens 708 kg/h,
   im Flug - nicht weniger als 660 kg/h.
6. Die Lufttemperatur in den Instrumentenräumen beträgt nicht mehr als 60 °C.
7. Der Anteil an feiner freier Feuchtigkeit in der Kühlluft beträgt nicht mehr als 2 g/kg trockene Luft.

Selbst innerhalb dieser begrenzten Anforderungen gibt es mindestens zwei Kategorien, die im System unterschiedlich gehandhabt werden müssen:

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

Anforderungen an die Systembetriebsbedingungen
Äußere Bedingungen für das bei der Modellierung zu entwickelnde System können als Randbedingungen oder als Ergebnis des Betriebs des Gesamtsystems angegeben werden.
Bei der dynamischen Simulation muss sichergestellt werden, dass die vorgegebenen Betriebsbedingungen durch den Simulationsprozess abgedeckt werden.

Parametrische Systemanforderungen
Diese Anforderungen sind Parameter, die vom System selbst bereitgestellt werden. Während des Modellierungsprozesses können wir diese Parameter als Berechnungsergebnisse erhalten und sicherstellen, dass die Anforderungen in jeder einzelnen Berechnung erfüllt werden.

Identifizierung und Kodierung von Anforderungen

Um die Arbeit mit Anforderungen zu erleichtern, empfehlen bestehende Standards, jeder Anforderung eine Kennung zuzuweisen. Bei der Vergabe von Identifikatoren ist es äußerst wünschenswert, ein einheitliches Kodierungssystem zu verwenden.

Der Anforderungscode kann einfach eine Zahl sein, die die Bestellnummer der Anforderung darstellt, oder er kann einen Code für die Art der Anforderung, einen Code für das System oder die Einheit, für die er gilt, einen Parametercode, einen Standortcode usw. enthalten alles andere, was sich der Ingenieur vorstellen kann. (Informationen zur Verwendung der Kodierung finden Sie im Artikel.)

Tabelle 1 enthält ein einfaches Beispiel für die Anforderungscodierung.

1. Code der Anforderungsquelle R-Anforderungen TK;
2. Codetyp der Anforderungen E – Anforderungen – Umgebungsparameter oder Betriebsbedingungen
   S – vom System bereitgestellte Anforderungen;
3. Flugzeugstatuscode 0 – beliebig, G – geparkt, F – im Flug;
4. Typcode des physikalischen Parameters T – Temperatur, P – Druck, G – Durchflussrate, Feuchtigkeit H;
5. Seriennummer der Anforderung.

ID Bedarf	Beschreibung	Parameter
REGT01	Umgebungslufttemperatur am Eingang zum Wasserkühlsystem: auf dem Parkplatz - ab minus 35 °C. bis zu 35 ºС.
REFT01	Atmosphärische Lufttemperatur am Eingang des Luftverteidigungssystems: im Flug - von minus 35 °C bis 39 °C.
REFP01	Der statische atmosphärische Luftdruck im Flug beträgt 700 bis 1013 hPa (526 bis 760 mm Hg).
REFP02	Der Gesamtluftdruck am Eingang zum SVO-Lufteinlass beträgt im Flug 754 bis 1200 hPa (566 bis 1050 mm Hg).
RSGT01	Kühllufttemperatur: im geparkten Zustand nicht mehr als 27 °C
RSGT02	Kühllufttemperatur: auf dem Parkplatz, für technische Einheiten nicht mehr als 29 ºС
RSFT01	Kühllufttemperatur im Flug nicht mehr als 25 ºС
RSFT02	Kühllufttemperatur: im Flug, für technische Einheiten nicht mehr als 27 ºС
RSGG01	Kühlluftstrom: im Stand mindestens 708 kg/h
RSFG01	Kühlluftstrom: im Flug mindestens 660 kg/h
RS0T01	Die Lufttemperatur in den Instrumentenräumen beträgt nicht mehr als 60 °C
RSH01	Der Anteil an feiner freier Feuchtigkeit in der Kühlluft beträgt nicht mehr als 2 g/kg trockene Luft

Design des Anforderungsüberprüfungssystems.

Für jede Designanforderung gibt es einen Algorithmus zur Beurteilung der Übereinstimmung der Designparameter und der in der Anforderung spezifizierten Parameter. Im Großen und Ganzen enthält jedes Steuerungssystem standardmäßig immer Algorithmen zur Anforderungsprüfung. Und selbst jede Regulierungsbehörde enthält sie. Wenn die Temperatur die Grenzwerte überschreitet, schaltet sich die Klimaanlage ein. Daher besteht der erste Schritt jeder Regulierung darin, zu prüfen, ob die Parameter den Anforderungen entsprechen.

Und da es sich bei der Verifizierung um einen Algorithmus handelt, können wir dieselben Werkzeuge und Werkzeuge verwenden, die wir zum Erstellen von Steuerungsprogrammen verwenden. Mit der SimInTech-Umgebung können Sie beispielsweise Projektpakete erstellen, die verschiedene Teile des Modells enthalten und in Form separater Projekte (Objektmodell, Steuerungssystemmodell, Umgebungsmodell usw.) ausgeführt werden.

Das Anforderungsüberprüfungsprojekt wird in diesem Fall zum gleichen Algorithmusprojekt und ist mit dem Modellpaket verbunden. Und im dynamischen Modellierungsmodus führt es eine Analyse zur Einhaltung der Anforderungen der technischen Spezifikationen durch.

Ein mögliches Beispiel für einen Systementwurf ist in Abbildung 1 dargestellt.

Abbildung 1. Beispiel für den Entwurf eines Verifizierungsprojekts.

Genau wie bei Steuerungsalgorithmen können Anforderungen in Form von Blättern erstellt werden. Um die Arbeit mit Algorithmen in Strukturmodellierungsumgebungen wie SimInTech, Simulink, AmeSim zu vereinfachen, wird die Möglichkeit genutzt, mehrstufige Strukturen in Form von Untermodellen zu erstellen. Diese Organisation ermöglicht es, verschiedene Anforderungen in Gruppen zu gruppieren, um die Arbeit mit einer Reihe von Anforderungen zu vereinfachen, wie dies bei Steuerungsalgorithmen der Fall ist (siehe Abb. 2).

Abbildung 2. Hierarchische Struktur des Anforderungsüberprüfungsmodells.

Im betrachteten Fall werden beispielsweise zwei Gruppen unterschieden: Anforderungen an die Umgebung und Anforderungen direkt an das System. Daher wird eine zweistufige Datenstruktur verwendet: zwei Gruppen, von denen jede ein Blatt des Algorithmus ist.

Um Daten mit dem Modell zu verbinden, wird ein Standardschema zur Generierung einer Signaldatenbank verwendet, in der Daten für den Austausch zwischen Teilen des Projekts gespeichert werden.

Beim Erstellen und Testen von Software werden die Messwerte von Sensoren (Analoga realer Systemsensoren), die vom Steuerungssystem verwendet werden, in dieser Datenbank abgelegt.
Für ein Testprojekt können alle im dynamischen Modell berechneten Parameter in derselben Datenbank gespeichert und so zur Überprüfung verwendet werden, ob die Anforderungen erfüllt sind.

In diesem Fall kann das dynamische Modell selbst in jedem mathematischen Modellierungssystem oder sogar in Form eines ausführbaren Programms ausgeführt werden. Einzige Voraussetzung ist das Vorhandensein von Softwareschnittstellen zur Ausgabe von Modellierungsdaten an die externe Umgebung.

Abbildung 3. Verbindung des Verifizierungsprojekts mit dem komplexen Modell.

Ein Beispiel für ein Basis-Anforderungsüberprüfungsblatt ist in Abbildung 4 dargestellt. Aus Sicht des Entwicklers handelt es sich um ein herkömmliches Berechnungsdiagramm, auf dem der Anforderungsüberprüfungsalgorithmus grafisch dargestellt wird.

Abbildung 4. Anforderungsprüfblatt.

Die Hauptteile des Prüfblatts sind in Abbildung 5 beschrieben. Der Prüfalgorithmus ist ähnlich wie die Entwurfsdiagramme von Steueralgorithmen aufgebaut. Auf der rechten Seite befindet sich ein Block zum Auslesen von Signalen aus der Datenbank. Dieser Baustein greift während der Simulation auf die Signaldatenbank zu.

Die empfangenen Signale werden analysiert, um Bedingungen für die Anforderungsüberprüfung zu berechnen. In diesem Fall wird eine Höhenanalyse durchgeführt, um die Position des Flugzeugs zu bestimmen (ob es geparkt ist oder sich im Flug befindet). Zu diesem Zweck können Sie andere Signale und berechnete Parameter des Modells verwenden.

Die zu prüfenden Verifikationsbedingungen und Parameter werden an Standard-Verifikationsblöcke übergeben, in denen diese Parameter auf Einhaltung der spezifizierten Anforderungen analysiert werden. Die Ergebnisse werden in der Signaldatenbank so erfasst, dass daraus automatisch eine Checkliste erstellt werden kann.

Abbildung 5. Struktur des Berechnungsblatts zur Anforderungsüberprüfung.

Die zu testenden Parameter verwenden nicht unbedingt in der Datenbank enthaltene Signale, die durch während des Simulationsprozesses berechnete Parameter gesteuert werden. Nichts hindert uns daran, im Rahmen des Anforderungsentwurfs zusätzliche Berechnungen durchzuführen, ebenso wie wir die Prüfbedingungen berechnen.

Zum Beispiel diese Anforderung:

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

In diesem Fall wird dem Auslegungsdiagramm der Anforderungen ein Algorithmus zur Zählung der Anzahl der Starts und der Gesamtbetriebszeit hinzugefügt.

Typischer Anforderungsüberprüfungsblock.

Jedes Kontrollkästchen für Standardanforderungen dient dazu, die Erfüllung einer Anforderung eines bestimmten Typs zu berechnen. Zu den Umweltanforderungen gehören beispielsweise verschiedene Umgebungstemperaturen beim Parken und im Flug. Dieser Block muss die Lufttemperatur im Modell als Parameter erhalten und ermitteln, ob dieser Parameter den angegebenen Temperaturbereich abdeckt./p>

Der Block enthält zwei Eingabeports, Parameter und Bedingung.

Der erste wird mit dem zu prüfenden Parameter gefüttert. In diesem Fall „Außentemperatur“.

Am zweiten Port wird eine boolesche Variable bereitgestellt – die Bedingung für die Durchführung der Prüfung.

Wenn am zweiten Eingang TRUE (1) empfangen wird, führt der Baustein eine Anforderungsüberprüfungsberechnung durch.

Wenn der zweite Eingang FALSE (0) empfängt, sind die Testbedingungen nicht erfüllt. Dies ist notwendig, damit die Berechnungsbedingungen berücksichtigt werden können. In unserem Fall wird dieser Eingang verwendet, um die Prüfung je nach Zustand des Modells zu aktivieren oder zu deaktivieren. Befindet sich das Luftfahrzeug während der Simulation am Boden, werden die flugtechnischen Anforderungen nicht geprüft, und umgekehrt – befindet sich das Luftfahrzeug im Flug, werden die flugtechnischen Anforderungen nicht geprüft.

Diese Eingabe kann auch beim Aufbau des Modells verwendet werden, beispielsweise in der Anfangsphase der Berechnung. Wenn das Modell in den erforderlichen Zustand gebracht wird, werden die Prüfblöcke deaktiviert. Sobald das System jedoch den erforderlichen Betriebsmodus erreicht, werden die Prüfblöcke aktiviert.

Die Parameter dieses Blocks sind:

• Randbedingungen: obere (UpLimit) und untere (DownLimit) Bereichsgrenzen, die überprüft werden müssen;
• erforderliche Systembelichtungszeit in den Grenzbereichen (TimeInterval) in Sekunden;
• Anforderungs-ID ReqName;
• Zulässigkeit der Bereichsüberschreitung Out_range ist eine boolesche Variable, die bestimmt, ob ein Wert, der den überprüften Bereich überschreitet, einen Verstoß gegen die Anforderung darstellt.

In einigen Fällen weist die Testwertausgabe darauf hin, dass das System über einen gewissen Spielraum verfügt und möglicherweise außerhalb seines Betriebsbereichs arbeitet. In anderen Fällen bedeutet eine Ausgabe, dass das System nicht in der Lage ist, die Sollwerte innerhalb des Bereichs zu halten.

Abbildung 6. Ein typischer Eigenschaftsprüfblock im Diagramm und seine Parameter.

Als Ergebnis der Berechnung dieses Blocks wird am Ausgang die Ergebnisvariable gebildet, die folgende Werte annimmt:

• 0 – rNone, Wert nicht definiert;
• 1 – rFertig, die Anforderung ist erfüllt;
• 2 – rFault, die Anforderung ist nicht erfüllt.

Das Blockbild enthält:

• Identifikationstext;
• Digitale Anzeigen von Messgrenzparametern;
• Farbkennung des Parameterstatus.

Innerhalb des Blocks befindet sich möglicherweise eine ziemlich komplexe logische Schlussfolgerungsschaltung.

Um beispielsweise den Betriebstemperaturbereich des in Abbildung 6 gezeigten Geräts zu überprüfen, ist der interne Schaltkreis in Abbildung 7 dargestellt.

Abbildung 7. Internes Diagramm der Temperaturbereichsbestimmungseinheit.

Innerhalb des Schaltungsblocks werden die in den Blockparametern angegebenen Eigenschaften verwendet.
Neben der Analyse der Einhaltung der Anforderungen enthält das interne Diagramm des Blocks eine Grafik, die zur Darstellung der Simulationsergebnisse erforderlich ist. Dieses Diagramm kann sowohl zur Anzeige während der Berechnung als auch zur Analyse der Ergebnisse nach der Berechnung verwendet werden.

Die Berechnungsergebnisse werden an den Ausgang des Blocks übertragen und gleichzeitig in einer allgemeinen Berichtsdatei aufgezeichnet, die auf Basis der Ergebnisse für das gesamte Projekt erstellt wird. (siehe Abb. 8)

Ein Beispiel für einen Bericht, der auf der Grundlage der Simulationsergebnisse erstellt wird, ist eine HTML-Datei, die in einem bestimmten Format erstellt wurde. Das Format kann beliebig an das von einer bestimmten Organisation akzeptierte Format angepasst werden.

Innerhalb des Schaltungsblocks werden die in den Blockparametern angegebenen Eigenschaften verwendet.
Neben der Analyse der Einhaltung der Anforderungen enthält das interne Diagramm des Blocks eine Grafik, die zur Darstellung der Simulationsergebnisse erforderlich ist. Dieses Diagramm kann sowohl zur Anzeige während der Berechnung als auch zur Analyse der Ergebnisse nach der Berechnung verwendet werden.

Die Berechnungsergebnisse werden an den Ausgang des Blocks übertragen und gleichzeitig in einer allgemeinen Berichtsdatei aufgezeichnet, die auf Basis der Ergebnisse für das gesamte Projekt erstellt wird. (siehe Abb. 8)

Ein Beispiel für einen Bericht, der auf der Grundlage der Simulationsergebnisse erstellt wird, ist eine HTML-Datei, die in einem bestimmten Format erstellt wurde. Das Format kann beliebig an das von einer bestimmten Organisation akzeptierte Format angepasst werden.

Abbildung 8. Beispiel einer Berichtsdatei basierend auf Simulationsergebnissen.

In diesem Beispiel wird die Berichtsform direkt in den Projekteigenschaften konfiguriert und das Format in der Tabelle als globale Projektsignale eingestellt. In diesem Fall löst SimInTech selbst das Problem der Berichtserstellung und der Block zum Schreiben von Ergebnissen in eine Datei verwendet diese Zeilen zum Schreiben in die Berichtsdatei.

Abbildung 9. Einstellen des Berichtsformats in globalen Projektsignalen

Verwendung einer Signaldatenbank für Anforderungen.

Um die Arbeit mit Eigenschaftseinstellungen zu automatisieren, wird für jeden typischen Block eine Standardstruktur in der Signaldatenbank erstellt. (siehe Abb. 10)

Abbildung 10. Beispiel für die Struktur eines Anforderungsprüfblocks in einer Signaldatenbank.

Die Signaldatenbank bietet:

• Speicherung aller notwendigen Systemvoraussetzungsparameter.
• Komfortable Einsicht in bestehende Projektanforderungen aus vorgegebenen Parametern und aktuellen Modellierungsergebnissen.
• Einrichten eines Blocks oder einer Gruppe von Blöcken mithilfe einer Skript-Programmiersprache. Änderungen in der Signaldatenbank führen zu Änderungen der Blockeigenschaftswerte im Diagramm.
• Hinterlegung von Textbeschreibungen, Links zu technischen Spezifikationspositionen oder Identifikatoren im Anforderungsmanagementsystem.

Signaldatenbankstrukturen für Anforderungen können einfach für die Zusammenarbeit mit einem Anforderungsmanagementsystem eines Drittanbieters konfiguriert werden. Ein allgemeines Diagramm der Interaktion mit Anforderungsmanagementsystemen ist in Abbildung 11 dargestellt.

Abbildung 11. Diagramm der Interaktion mit dem Anforderungsmanagementsystem.

Der Ablauf der Interaktion zwischen dem SimInTech-Testprojekt und dem Anforderungssteuerungssystem ist wie folgt:

1. Die Leistungsbeschreibung ist in Anforderungen gegliedert.
2. Es werden die Anforderungen der technischen Spezifikationen identifiziert, die durch mathematische Modellierung technischer Prozesse überprüft werden können.
3. Attribute der ausgewählten Anforderungen werden in der Struktur von Standardblöcken (z. B. maximale und minimale Temperatur) an die SimInTech-Signaldatenbank übertragen.
4. Während des Berechnungsprozesses werden Strukturdaten in Blockdiagramme übertragen, Analysen durchgeführt und die Ergebnisse in einer Signaldatenbank gespeichert.
5. Nach Abschluss der Berechnung werden die Analyseergebnisse an das Anforderungsmanagementsystem übertragen.

Die Anforderungsschritte 3 bis 5 können während des Designprozesses wiederholt werden, wenn Änderungen am Design und/oder an den Anforderungen auftreten und die Auswirkungen der Änderungen erneut getestet werden müssen.

Schlussfolgerungen.

• Der erstellte Prototyp des Systems ermöglicht eine erhebliche Verkürzung der Zeit für die Analyse bestehender Modelle auf Einhaltung der Anforderungen der technischen Spezifikationen.
• Die vorgeschlagene Testtechnologie nutzt bereits vorhandene dynamische Modelle und kann sogar für alle dynamischen Modelle verwendet werden, auch für solche, die nicht in der SimInTech-Umgebung durchgeführt werden.
• Mithilfe der Batch-Datenorganisation können Sie Anforderungsüberprüfungspakete parallel zur Modellentwicklung erstellen oder diese Pakete sogar als technische Spezifikationen für die Modellentwicklung verwenden.
• Die Technologie kann ohne nennenswerte Kosten in bestehende Anforderungsmanagementsysteme integriert werden.

Für diejenigen, die bis zum Ende lesen: Link zu einem Video, das zeigt, wie der Prototyp funktioniert.

Source: habr.com