Automatische Überprüfung der Anforderungen im Lastenheft während der dynamischen Modellierung.

Das Thema weiterführend „Woher haben Sie die Beweise?“, betrachten wir das Problem der mathematischen Modellierung aus einer anderen Perspektive. Nachdem wir sichergestellt haben, dass das Modell der Realität entspricht, können wir die entscheidende Frage beantworten: „Was haben wir hier eigentlich?“ Wenn wir ein technisches Objekt modellieren, wollen wir in der Regel sicherstellen, dass dieses Objekt unseren Erwartungen entspricht. Dazu führen wir dynamische Berechnungen der Prozesse durch und vergleichen die Ergebnisse mit den Anforderungen. Dies ist der digitale Zwilling, das virtuelle Prototyping und andere moderne Begriffe, die in der Planungsphase dazu dienen, die Frage zu klären, wie wir das erreichen können, was wir uns vorgenommen haben.

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

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

Wir betrachten die Anforderungen, die numerisch ausgedrückt und mathematisch auf der Grundlage eines konkreten Berechnungsmodells überprüft werden können. Es ist klar, dass dies nur ein Teil der allgemeinen Anforderungen an jedes technische System ist, aber genau auf deren Überprüfung verwenden wir Zeit, Nerven und Geld für die Erstellung dynamischer Modelle des Objekts.

Bei der Beschreibung technischer Anforderungen in Form von Dokumenten lassen sich verschiedene Arten von Anforderungen unterscheiden, die jeweils unterschiedliche Ansätze zur automatischen Überprüfung der Einhaltung der Anforderungen erfordern.

Betrachten wir zum Beispiel einen so kleinen, aber realen Satz von Anforderungen:

1. Temperatur der Umgebungsluft am Eingang des KSS:
   im Stand − von minus 35 bis 35 ºC,
   im Flug − von minus 35 bis 39 ºC.
2. Statischer Druck der Umgebungsluft im Flug − von 700 bis 1013 hPa (von 526 bis 760 mm Hg).
3. Der Gesamtdruck der Luft am Eintritt der Luftansaugöffnung des Kühlsystems im Flug beträgt zwischen 754 und 1200 hPa (von 566 bis 1050 mm Hg).
4. Temperatur der Kühlluft:
   am Boden – höchstens 27 ºC, für technische Blöcke – höchstens 29 ºC,
   in der Luft – höchstens 25 ºC, für technische Blöcke – höchstens 27 ºC.
5. Durchflussrate der Kühlluft:
   am Boden – mindestens 708 kg/h,
   in der Luft – mindestens 660 kg/h.
6. Die Temperatur der Luft in den Instrumentenschächten darf höchstens 60 ºC betragen.
7. Die Menge an feiner freier Feuchtigkeit in der Kühlluft darf höchstens 2 g/kg trockener Luft betragen.

Selbst in diesem begrenzten Anforderungskatalog lassen sich mindestens zwei Kategorien unterscheiden, die im System unterschiedlich behandelt werden müssen:

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

Anforderungen an die Betriebsbedingungen des Systems
Die äußeren Bedingungen für das zu entwickelnde System können bei der Modellierung entweder als Randbedingungen oder als Ergebnis der Funktionsweise des Gesamtsystems festgelegt werden.
Bei der dynamischen Modellierung muss sichergestellt werden, dass die festgelegten Betriebsmodi im Modellierungsprozess abgedeckt sind.

Parametrische Anforderungen an das System
Diese Anforderungen stellen die von der Systemsoftware bereitgestellten Parameter dar. Während des Modellierungsprozesses können wir diese Parameter als Berechnungsergebnisse erhalten und sicherstellen, dass die Anforderungen in jeder spezifischen Berechnung erfüllt werden.

Identifikation und Kodierung von Anforderungen

Für eine effiziente Bearbeitung von Anforderungen empfehlen die bestehenden Standards, jeder Anforderung eine Identifikationsnummer zuzuweisen. Es ist sehr wünschenswert, ein einheitliches Kodierungssystem zu verwenden.

Der Anforderungscode kann einfach eine Nummer sein, die die Reihenfolge der Anforderung widerspiegelt, oder er kann den Code des Anforderungstyps, den System- oder Aggregatcode, auf den er angewendet wird, den Parametercode, den Standortcode und vieles mehr enthalten, das sich ein Ingenieur vorstellen kann. (Einen Anwendungsfall zur Kodierung finden Sie im Artikel.)

In Tabelle 1 finden Sie ein einfaches Beispiel für die Kodierung von Anforderungen.

1. Quellcode der Anforderungen R - Requirements of the specification;
2. Typencode der Anforderungen E - Anforderungen - Parameter der externen Umgebung oder Betriebsbedingungen.
   S - Anforderungen, die vom System bereitgestellt werden;
3. Statuscode des Flugzeugs 0 – beliebig, G – am Boden, F – in der Luft;
4. Code der physikalischen Parameter T – Temperatur, P – Druck, G – Verbrauch, H – Feuchtigkeit;
5. fortlaufende Nummer der Anforderung.

Projekt des Anforderungskontrollsystems.

Für jede Berechnungsanforderung gibt es einen Algorithmus zur Bewertung der Übereinstimmung zwischen den berechneten Parametern und den im Anforderungen angegebenen Parametern. Grundsätzlich enthält jedes Managementsystem standardmäßig Überprüfungsalgorithmen. Selbst jede Regulierungsbehörde nutzt sie. Wenn die Temperatur einen bestimmten Wert überschreitet, wird die Klimaanlage eingeschaltet. Damit ist der erste Schritt jeder Regelung die Überprüfung der Übereinstimmung der Parameter mit den Anforderungen.

Da die Überprüfung ein Algorithmus ist, können dieselben Mittel und Werkzeuge verwendet werden, die wir zur Erstellung von Steuerungsprogrammen nutzen. Beispielsweise ermöglicht die SimInTech-Umgebung die Erstellung von Projektpaketen, die verschiedene Teile des Modells enthalten, die in Form einzelner Projekte ausgeführt werden (Objektmodell, Steuerungsmodell, Umweltmodell usw.).

Das Projekt zur Überprüfung der Anforderungen wird in diesem Fall zu einem Projekt von Algorithmen und ist in das Modellpaket integriert. Im Modus der dynamischen Modellierung führt es eine Analyse der Übereinstimmung mit den Anforderungen der Spezifikation durch.

Ein mögliches Beispiel für die Gestaltung eines Systemprojekts ist in Abbildung 1 dargestellt.

Abbildung 1. Beispiel für die Gestaltung des Überprüfungsprojekts.

Ähnlich wie bei den Steuerungsalgorithmen können Anforderungen in Form eines Satzes von Blättern organisiert werden. Um die Arbeit mit Algorithmen in strukturierten Modellierungsumgebungen wie SimInTech, Simulink, AmeSim zu erleichtern, werden mehrstufige Strukturen in Form von Submodellen erstellt. Diese Organisation ermöglicht es, verschiedene Anforderungen in Gruppen zusammenzufassen, um die Arbeit mit dem Anforderungsmassiv zu vereinfachen, wie es auch bei Steuerungsalgorithmen der Fall ist (siehe Abb. 2).

Abbildung 2. Hierarchische Struktur des Anforderungsprüfungsmodells.

In dem betrachteten Fall wurden beispielsweise zwei Gruppen herausgearbeitet: Anforderungen an die Umgebung und Anforderungen an das System selbst. Daher wird eine zweistufige Datenstruktur verwendet: zwei Gruppen, von denen jede ein Blatt des Algorithmus darstellt.

Für die Verbindung von Daten mit dem Modell wird ein standardisiertes Schema zur Erstellung einer Signal-Datenbank verwendet, in der die Daten für den Austausch zwischen den Teilen des Projekts gespeichert werden.

Bei der Erstellung und dem Testen von Software werden in diese Datenbank die Messwerte von Sensoren (Entsprechungen realer Sensoren des Systems) eingetragen, die von der Steuerungseinheit genutzt werden.
Für das Testprojekt können in dieser Datenbank beliebige Parameter gespeichert werden, die in dem dynamischen Modell berechnet werden, um somit die Erfüllung der Anforderungen zu überprüfen.

Das dynamische Modell kann in diesem Fall in jedem System für mathematische Modellierung oder sogar als ausführbares Programm realisiert werden. Die einzige Voraussetzung ist die Verfügbarkeit von Programmierschnittstellen, um die Simulationsdaten an die externe Umgebung auszugeben.

Abbildung 3. Anbindung des Prüfprojekts an das umfassende Modell.

Ein Beispiel für ein Basis-Anforderungsprüfbogen ist in Abbildung 4 dargestellt. Aus der Sicht des Entwicklers stellt er ein gewöhnliches Berechnungsschema dar, das das grafische Verfahren zur Überprüfung der Anforderungen zeigt.

Abbildung 4. Prüfblatt für Anforderungen.

Die Hauptteile des Prüfblatts sind in Abbildung 5 dargestellt. Der Prüfalgorithmus wird ähnlich wie die Berechnungsschemata von Steuerungsalgorithmen gebildet. Im rechten Teil befindet sich der Block zum Lesen von Signalen aus der Datenbank. In diesem Block wird während der Simulation auf die Signaldatenbank zugegriffen.

Die erhaltenen Signale werden analysiert, um die Prüfbedingungen zu berechnen. In diesem Fall erfolgt eine Höhenanalyse, 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 standardisierte Prüfblöcke übergeben, in denen die Datenparameter auf ihre Übereinstimmung mit den festgelegten Anforderungen analysiert werden. Die Ergebnisse werden in der Signaldatenbank so festgehalten, dass sie zur automatischen Erstellung einer Checkliste verwendet werden können.

Abbildung 5. Struktur des Berechnungsblatts für die Anforderungen.

Bei den überprüfbaren Parametern ist es nicht zwingend erforderlich, Signale aus der Datenbank zu verwenden, die von den während der Modellierung berechneten Parametern 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 zur Zielposition darf 5 nicht überschreiten, und die Gesamtdauer des Betriebs des Korrektursystems darf 30 Sekunden nicht überschreiten.

In diesem Fall wird der Berechnungsalgorithmus zur Zählung der Aktivierungen und der Gesamtbetriebszeit in das Anforderungsprojekt integriert.

Typisches Prüfmodul für Anforderungen.

Jedes typische Prüfmodul ist darauf ausgelegt, die Erfüllung einer bestimmten Anforderungstyp zu berechnen. Beispielsweise enthält die Umgebungsvorgabe einen Temperaturbereich der Umgebungstemperatur auf dem Boden und im Flug. Dieses Modul sollte die Lufttemperatur im Modell als Parameter erhalten und überprüfen, ob dieser Parameter innerhalb des vorgegebenen Temperaturbereichs liegt.

Der Block verfügt über zwei Eingangsports: param und condition.

An den ersten Port wird der zu prüfende Parameter angelegt. In diesem Fall ist es die "Außentemperatur".

An den zweiten Port wird eine Boolesche Variable – die Bedingung für die Überprüfung – angeschlossen.

Wenn am zweiten Eingang TRUE (1) ankommt, berechnet der Block die Anforderungen.

Wenn am zweiten Eingang FALSE (0) ankommt, werden die Überprüfungsbedingungen nicht ausgeführt. Dies ist notwendig, um Berechnungsbedingungen zu berücksichtigen. In unserem Fall wird dieser Eingang verwendet, um die Überprüfung je nach Zustand des Modells zu aktivieren oder zu deaktivieren. Wenn das Luftfahrzeug während der Simulation am Boden ist, werden die flugerforderlichen Anforderungen nicht überprüft, und umgekehrt – wenn das Luftfahrzeug in der Luft ist, werden die Anforderungen, die mit dem Bodenbetrieb verbunden sind, nicht überprüft.

Dieser Eingang kann auch bei der Modellenstellung verwendet werden, beispielsweise in der Anfangsphase der Berechnung. Wenn das Modell in den gewünschten Zustand versetzt wird, sind die Überprüfungsblöcke deaktiviert, aber sobald das System in den erforderlichen Betriebsmodus wechselt, werden die Überprüfungsblöcke aktiviert.

Die Parameter dieses Blocks sind:

• Grenzbedingungen: obere (UpLimit) und untere (DownLimit) Grenzen der Bereiche, die überprüft werden müssen;
• benötigte System-Pausenzeit an den Grenzbereichen (TimeInterval) in Sekunden;
• Anforderungs-Identifikator ReqName;
• Erlaubtheit des Überschreitens des Bereichs Out_range – eine boolesche Variable, die definiert, ob das Überschreiten des überprüften Bereichs eine Verletzung der Anforderungen darstellt.

In einigen Fällen bedeutet das Überschreiten des überprüften Wertes, dass das System Spielraum hat und außerhalb des Arbeitsbereichs arbeiten kann. In anderen Fällen bedeutet das Überschreiten, dass das System nicht in der Lage ist, die vorgegebenen Parameter innerhalb des Bereichs einzuhalten.

Abbildung 6. Typischer Prüfbalken für Eigenschaften in der Darstellung und seine Parameter.

Durch die Berechnung dieses Blocks entsteht die Variable Result, die folgende Werte annimmt:

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

Das Blockbild enthält:

• Textbezeichnung;
• digitale Anzeigen der Messgrenzen;
• Farbkennung des Parameterstatus.

Innerhalb des Blocks kann sich ein komplexes logisches Schaltschema befinden.

Beispielsweise wird das interne Schema zur Überprüfung des Temperaturarbeitsbereichs des in Abbildung 6 gezeigten Blocks in Abbildung 7 dargestellt.

Abbildung 7. Internes Schema des Temperatursensorblocks.

Im Inneren des Blocks werden Eigenschaften verwendet, die in den Blockparametern festgelegt sind.
Neben der Überprüfung der Anforderung erfüllt das interne Schema des Blocks eine Grafik, die zur Darstellung der Simulationsergebnisse erforderlich ist. Diese Grafik 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 einer allgemeinen Berichtdatei aufgezeichnet, die auf Basis 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 bestimmten Format erstellt wurde. Das Format kann beliebig an die in der jeweiligen Organisation übliche Formatgestaltung angepasst werden.

Im Inneren des Blocks werden Eigenschaften verwendet, die in den Blockparametern festgelegt sind.
Neben der Überprüfung der Anforderung erfüllt das interne Schema des Blocks eine Grafik, die zur Darstellung der Simulationsergebnisse erforderlich ist. Diese Grafik 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 einer allgemeinen Berichtdatei aufgezeichnet, die auf Basis 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 bestimmten Format erstellt wurde. Das Format kann beliebig an die in der jeweiligen Organisation übliche Formatgestaltung angepasst werden.

Abbildung 8. Beispiel einer Berichtdatei zu den Simulationsergebnissen.

In diesem Beispiel wird die Konfiguration des Berichtformats direkt in den Projekteigenschaften vorgenommen, während das Format in der Tabelle als globale Signale des Projekts festgelegt wird. In diesem Fall übernimmt SimInTech die Aufgabenstellung zur Berichterstellung, und der Block zum Speichern von Ergebnissen in eine Datei verwendet diese Zeilen, um in die Berichtdatei zu schreiben.

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

Verwendung der Datenbanksignale für Anforderungen.

Zur Automatisierung der Arbeit mit den Eigenschaften für jeden Typblock wird eine standardisierte Struktur in der Datenbank der Signale erstellt. (siehe Abbildung 10)

Abbildung 10. Beispiel einer Struktur des Anforderungsprüfblocks in der Datenbank der Signale.

Die Datenbank der Signale ermöglicht:

• Speicherung aller notwendigen Parameter für Systemanforderungen.
• Bequeme Ansicht der bestehenden Anforderungen im Projekt basierend auf angegebenen Parametern und aktuellen Simulationsergebnissen.
• Konfiguration eines Blocks oder einer Gruppe von Blöcken unter Verwendung einer Skriptsprache. Änderungen in der Datenbank der Signale führen zu Änderungen der Eigenschaftswerte des Blocks im Schema.
• Speicherung von textlichen Beschreibungen, Links zu Anforderungen oder IDs im Anforderungmanagementsystem.

Datenbankstrukturen für Signale von Anforderungen können einfach so konfiguriert werden, dass sie mit einem externen Anforderungsmanagementsystem arbeiten. Das Gesamtschema der Interaktion mit den Anforderungsmanagementsystemen ist in Abbildung 11 dargestellt.

Abbildung 11. Schema der Interaktion mit dem Anforderungsmanagementsystem.

Der Ablauf der Interaktion des Testprojekts SimInTech mit dem Anforderungsmanagementsystem gestaltet sich folgendermaßen:

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

Die Schritte zur Bearbeitung der Anforderungen 3 bis 5 können während des Entwurfsprozesses wiederholt werden, wenn Änderungen an der Konstruktion und/oder den Anforderungen vorgenommen werden und daher eine erneute Prüfung der Auswirkungen dieser Änderungen erforderlich ist.

Fazit.

• Der erstellte Systemprototyp ermöglicht eine erhebliche Reduzierung der Zeit für die Analyse bestehender Modelle hinsichtlich ihrer Übereinstimmung mit den Anforderungen des Lastenhefts.
• Die vorgeschlagene Testtechnik nutzt bereits vorhandene dynamische Modelle und kann sogar für beliebige dynamische Modelle verwendet werden, die nicht in der SimInTech-Umgebung erstellt wurden.
• Die Verwendung einer strukturierten Datenorganisation ermöglicht die Erstellung von Prüfpaketen parallel zur Entwicklung der Modelle oder sogar die Verwendung dieser Pakete als technische Vorgaben für die Modellentwicklung.
• Die Technologie kann ohne wesentliche Kosten in bestehende Anforderung-Management-Systeme integriert werden.

Für diejenigen, die bis zum Ende gelesen haben, hier ist der Link zu einem Video, das die Funktionsweise des Prototyps demonstriert.

Quelle: habr.com