Wir setzen das Thema OOP in grafischen Programmiersprachen fort und werden das modellbasierte Design genauer untersuchen. Was ist modellorientiertes Design (MOS), wie wird es gekocht und womit wird gegessen?

Bei der Beschreibung eines modellorientierten Entwurfs von Steuerungssystemen vermitteln einige Autoren in ihren Veröffentlichungen die Idee, dass das Wort "Modell" "Modell eines Steuerungssystems" bedeutet. Was ist nicht richtig.

Warum dies nicht stimmt, wie man es richtig macht und wo Tschernobyl, lesen Sie weiter.

Hier ein typisches Beispiel - ein Bild aus einem Artikel angesehener Autoren über „Best Practices in der Softwareentwicklung mit modellorientiertem Design“:

Abbildung 1. Eine der Optionen für MOS.

Persönlich stellt sich beim Betrachten dieses Bildes sofort eine unanständige Frage, und von welchem ​​Ort aus, ich entschuldige mich, hatten Sie Testvektoren?

Oder zum Beispiel ein Bild zur Empfehlung eines typischen Softwareentwicklungsprozesses:

Abbildung 2. Eine andere Version des MOS-Prozesses.

Wo ist das Modell auf diesem Bild? Hier ist diese Box, aus der der Quellcode bezogen wird? Wirklich ?! Dies ist also wieder ein Modell für Steuerungssoftware.

Besonders berührend in diesem Bild ist das Vorhandensein anfänglicher Softwareanforderungen.
Wie Sie zum Beispiel ein so übliches, fast lehrbuchartiges Erfordernis für ein Steuerungssystem sind:

„ Wenn der Druck über den Grenzwert steigt, sollte die Schließzeit des Sicherheitsventils nicht mehr als 5 Sekunden betragen .“

Und wie bestellen Sie nach diesem Schema, um zu überprüfen, wie viele Sekunden nach dem Überschreiten des Drucks das Sicherheitsventil öffnet? Anscheinend fehlt hier etwas. Wir wenden uns im letzten Ausweg der unerschöpflichen Quelle der Wahrheit zu - Wikipedia:

Modellbasiertes Design bietet einen effizienten Ansatz zur Schaffung eines gemeinsamen Kommunikationsrahmens während des gesamten Designprozesses bei gleichzeitiger Unterstützung des Entwicklungszyklus (V-Modell). Beim modellbasierten Entwurf von Steuerungssystemen manifestiert sich die Entwicklung in diesen vier Schritten:

1. Modellierung einer Pflanze,
2. Analyse und Synthese einer Steuerung für die Anlage,
3. Simulation der Anlage und Steuerung,
4. Integration all dieser Phasen durch Bereitstellung des Controllers.

Die Entwicklung eines Modells eines Objekts ist der erste Punkt bei der Bestimmung des MOS. Zuerst ein Modell des Objekts und dann die Steuerung dafür. Und das ist richtig: Es gibt kein Objektmodell, „Danke an alle - jeder ist frei“ und dies ist kein modellorientiertes Design, sondern ein vollständiger Verbraucherbetrug.

Warum ist das wichtig und woher kommt Tschernobyl?

In Tschernobyl geschah genau das, was ohne Objektmodell geschah. Sowjetische Wissenschaftler fragten sich: „Was passiert, wenn die Stromversorgung unterbrochen wird und die Reaktorkühlpumpen von einem Generator mit Strom versorgt werden, der auf einer auslaufenden Turbine läuft? "Wie viel Wasser pumpen Pumpen durch den Reaktor, bevor die Turbine und der Generator anhalten?" Interessanterweise stellten sie eine solche Frage auf der Grundlage der Erfahrungen mit dem Unfall im amerikanischen Kernkraftwerk, bei dem die Wasserversorgung nicht ausreichte, um abzukühlen, und der amerikanische Reaktor schmolz. Und um sicherzugehen, dass unsere Reaktoren nicht schmelzen, haben wir beschlossen, ein Experiment durchzuführen. Vielleicht würde die Antwort auf diese Frage die nächste Generation von RBMK-Reaktoren noch sicherer machen. Wir wollten das Beste, aber es stellte sich wie immer heraus. Als Ergebnis des Experiments wurde ein sicherer Reaktor zuerst in einen gefährlichen Zustand gebracht und dann in die Luft gesprengt. Und die nächste Generation von RBMK-Reaktoren ist nicht mehr und wird nicht erwartet. Amen.

Und wenn es möglich wäre, anstatt an einem Reaktor zu experimentieren, dasselbe an einem mathematischen Modell eines Objekts zu tun, würden wir jetzt möglicherweise RBMK-2400 auf der ganzen Welt anstelle von VVER-1200-Reaktoren bauen.

Nach dem Unfall von Tschernobyl in der Nuklearindustrie ist ein Objektmodell (Kernreaktor) ein obligatorischer Bestandteil des Projekts. Der Designer muss auf dem Modell zeigen, was passieren wird, wenn etwas schief geht. Aufgrund der Anforderungen der Aufsichtsbehörden trat das modellorientierte Design bei Nuklearingenieuren daher viel früher auf als in anderen Branchen.

Aber selbst wenn die Regulierungsbehörden keine Anforderungen stellen, erleichtert das Modell des Objekts den Entwurf sowohl des Steuerungssystems als auch des Objekts selbst erheblich. Jetzt zeigen wir dies anhand eines Beispiels aus einer Branche, in der „Träume wahr werden“.

Der richtige modellorientierte Ansatz.

Betrachten Sie als Beispiel für den richtigen, koscheren MOS den Prozess der Entwicklung einer Steuerungssoftware für das hydraulische Steuerungssystem eines Unterwasser-Bergbaukomplexes (wie immer war es absolut zufällig, dass ich dieses Modell auf meinen Computer bekam).

Die Steuerung der Hauptströme des erzeugten Gases durch die Versorgung erfolgt durch hydraulische Unterwasserarmaturen. Am Ufer befindet sich eine Pumpstation, die Druck im Hydrauliksystem liefert, Öl wird durch eine unter Wasser unter Druck stehende Versorgungsleitung zugeführt. Das Öffnen und Schließen der Ventile erfolgt über hydraulische Stellantriebe, die von einem verteilten Steuerungssystem gesteuert werden. Das System besteht aus:

• Bodensteuerungsmodul für das gesamte Feld;
• eine Reihe von Unterwasser-Steuermodulen (PMU) zur direkten Steuerung von Ventilen.

Zur Erleichterung der Installation und Wartung werden Rohrleitungen zu Verteilern zusammengefasst, in denen die erforderlichen Ventile und Steuermodule auf einer Plattform installiert sind. Wenn Sie in der Bodenstation Standard-SCADA-Tools, Archivserver und SPS mit herkömmlichen und (oder) Echtzeitbetriebssystemen verwenden können, ist das Unterwassersteuerungsmodul in der Regel ein nicht betriebsbereiter Mikroprozessor, dessen Steuercode separat von der Küstensteuerungssoftware entwickelt werden muss . (Kein C ++, nur C, nur Hardcode) Dann sollten mehrere dieser PMUs in das gemeinsame System integriert und getestet werden. Gleichzeitig sollte das gesamte System als Ganzes funktionieren und das Öffnen und Schließen von Ventilen innerhalb von 30 Jahren unter Wasser ermöglichen.

Die Aufgabe wird durch die Tatsache erschwert, dass bis jetzt alle im Regal verwendeten Geräte westlich waren und das Regal jetzt sanktioniert wird. Dementsprechend ist es notwendig, einen Komplex zu schaffen, in dem viele technische Lösungen für uns neu und unbehandelt sind. Wie kann man das Ergebnis erzielen und Konstruktionsfehler nach Möglichkeit reduzieren? Gut für westliche Entwickler: Sie haben bereits Erfahrung und kennen die Fallstricke im Unterwasserabbau. Und hier hilft modellorientiertes Design Entwicklern. Anstatt Experimente mit teuren Geräten wie den sowjetischen Nuklearwissenschaftlern in Tschernobyl durchzuführen, erstellen wir ein Modell des Objekts und führen Experimente mit dem Modell durch.

Integriertes Modell des Unterwassersteuerungssystems

Für das Software-Design wird ein integriertes Modell in Form eines Pakets erstellt, das sowohl Hydraulikflüssigkeitsströmungsmodelle unter Wasser mit Armaturen als auch Steuerungssystemprojekte enthält. (siehe Abb. 3)

Abbildung 3. Ein Paket eines integrierten Modells des SPD-Managementsystems.

Dieses Paket enthält ein Projekt - ein Modell einer bodengestützten Hydraulikstation (Datei 200.prt in Abb. 3), das die Modellierung der dynamischen Prozesse der Ausrüstung des bodengestützten Hydraulikflüssigkeitsversorgungssystems für Wasser ermöglicht. (siehe Abb. 4)

Abbildung 4. Das Entwurfsschema der Bodenhydraulikstation.

Gleichzeitig mit dem Modell physikalischer Prozesse wird ein Steuerungssystemprojekt entwickelt, das das Ein- und Ausschalten von Geräten und das Steuern der Betriebsmodi dieser Geräte vorsieht. Abbildung 5 zeigt den Entwurf der Steueralgorithmen für das Bodensteuerungsmodul.

Abbildung 5. Aufbau eines Bodenmodul-Steuerungssystems.

In dieser Phase ist es möglich, die Entwicklung von Steuerungsalgorithmen auf verschiedene Teams aufzuteilen. Für Entwickler einer landgestützten Hydraulikstation sind beispielsweise die Kosten der Unterwassermodule und der Druck in ihnen Randbedingungen. Für Entwickler von Unterwassergeräten ist die Randbedingung der Druck, der von der Pumpstation an Land erzeugt wird.

Die Entwicklung von Unterwassersteuerungsmodulen (PMUs) erfolgt auf der Grundlage des Projekts zur Aufteilung des Hauptgasnetzes zwischen den Verteilern. Zuerst werden Brunnen gebildet, die Rohrleitungen und Armaturen zwischen den Brunnen und dem Ufer bestimmt, dann wird ein hydraulisches Steuersystem für diese Ventile entwickelt.

Für jedes Unterwassermodul werden ein Steuerungssystemprojektmodell und ein Entwurfsmodell des Verteilerhydrauliksystems mit installierten Ventilen gebildet. Nach dem Auslegungsschema des Hydrauliksystems sind Ventile installiert, die von diesem Unterwassermodul aus gesteuert werden. Dieser Entwurf kann parallel zur Entwicklung des Bodensteuerungsmoduls durchgeführt werden, während die Entwicklung unabhängig und parallel durchgeführt werden kann. Zur Entwicklung der PMU-Algorithmen und des Ventilbetriebs wird das externe System durch Steuerbefehle und Randbedingungen für das Hydrauliksystem definiert.

Betrachten Sie das Unterwassersteuerungsmodul (PMU) 502. Hier werden zwei Projekte verwendet:

• 502.prt - Modell von Hydrauliksystemen (Abb. 6, 7);
• 502a.prt - das Projekt des Steuerungssystems der PMU (Abb. 8).

Abbildung 6. Der Hydraulikkreis der PMU.

Dieses Entwurfsschema bietet eine Simulation des Verhaltens des hydraulischen Steuerungssystems und die Berechnung von Durchflussraten und Drücken in einem System, das von 502 PMU gesteuert wird. Mit dem berechneten Hydraulikkreis können Sie die Auswirkungen auf die Aktuatoren einstellen und Sensordaten abrufen, die im Modell physikalischer Prozesse berechnet wurden. Solange wir keine Bodenstation im 502 P-Block haben (untere linke Ecke von Abb. 6), können wir den vom Wasserkraftwerk erzeugten Druck als Randbedingung festlegen.

In dem System zeigt die Abbildung 6 hydraulische Absperr- und Steuerventile (ZRA), von denen jedes von Natur aus einen Hydraulikzylinder darstellt, der mit zwei Hoch- und Niederdruckleitungen verbunden ist. Wir üben mehr Druck auf den oberen Teil des Zylinders aus, der Druck bewegt die Stange nach unten, wir üben mehr Druck auf den unteren Teil des Zylinders aus, die Stange steigt an.

Das Schalten wird über Steuerventile im weißen Block gesteuert (siehe Abb. 7).

Abbildung 7. Verteilerventilblock im Modell.

Das Funktionsprinzip ist einfach: Abhängig von der Position des Schieberventils werden die Zylinderkammern an verschiedene Leitungen angeschlossen. Spule bewegt - Änderte die Bewegungsrichtung der Stange im Zylinder. (Weitere Details zur hydraulischen Modellierung finden Sie hier ... )

Abbildung 8. Aufbau des PMU-Steuerungssystems.

Die Projektmanagementsoftware für das Unterwassersteuerungsmodul enthält mehrere Berechnungsblöcke, die jeweils von einem separaten Entwickler oder Team entwickelt werden können. In diesem Fall erfolgt die Aufteilung in Module nach einem Funktionsattribut, wobei jeder Block für die Steuerung eines bestimmten Ventiltyps verantwortlich ist. Die Methodik der objektorientierten Programmierung wird angewendet, wobei der Block die OOP-Klasse ist (weitere Details hier ... und hier ... ).

Betrachten Sie den Prozess des Entwurfs einer Steuereinheit für Abschalt- und Steuergeräte. Dieser Block in der Schaltung empfängt 4 Eingangssignale und erzeugt 8 Ausgangssignale. (siehe Abb. 9)

Abbildung 9. ZRA-Steuereinheit (Typ 1).

Das interne Blockdiagramm besteht aus zwei Blättern von Algorithmen. Das erste Blatt ist in 10a gezeigt, das zweite in 10b.

Abbildung 10a. Das Konstruktionsschema der Ventilsteuereinheit. Blatt 1.

Abbildung 10b. Das Konstruktionsschema der Ventilsteuereinheit. Blatt 2.

Bei der Entwicklung dieses Geräts werden die folgenden Signaltypen verwendet:

• über Kommunikationsleitungen empfangene Signale (blaue Blöcke);
• von der Signaldatenbank empfangene Parameter und Signale (hellgelbe Blöcke);
• an die Signaldatenbank übertragene Signale (hellblaue Blöcke);
• an den Speicher übertragene Signale (hellgelbe Blöcke);
• Vom Speicher empfangene Signale (hellgrüne Blöcke).

Das Auslegungsdiagramm der Ventilsteuereinheit ist ein Vektor. Dies bedeutet, dass nicht ein einziges Steuersignal auf jeder Leitung übertragen wird, sondern ein Signalvektor, dessen Dimension der Menge der im PMP installierten Geräte dieses Typs entspricht. Für die Kommunikation zwischen der Recheneinheit und den Signalen, Parametern und Befehlen für ein bestimmtes Gerät werden Schnittstelleneinheiten verwendet.

Nachdem ein Steuerkreis eines typischen Elements entwickelt und getestet wurde, können so viele Schnittstelleneinheiten auf dem Stromkreis platziert werden, wie die Ausrüstung dieses Typs mit dem Unterwassersteuermodul verbunden ist. In diesem Fall gibt es in der PMU zwei Schnittstelleneinheiten für Absperr- und Steuerventile Typ 1 (siehe Abb. 8).

Alle variablen Signale und Parameter, die für die Steuereinheit benötigt werden, werden in die entsprechende Kategorie der ZRAT1- Signalbasis eingeordnet . Ein Teil der Kategorie ist in Abbildung 11 dargestellt.

Die Trennung einer separaten Kategorie ermöglicht die Trennung der Entwicklung von Steuerungssoftwaremodulen in Teile und die klare Definition der Interaktionsschnittstelle zwischen den verschiedenen Teilen des Programms. Somit verläuft die Entwicklung des Steuermoduls isoliert entlang der Schnittstellen von anderen Modulen in der Software.

Abbildung 11. Signalgruppe für das Steuergerät ZRAT1

Projektcodierungssystem

Das System enthält mehrere Instanzen dieser Art von Geräten, was bedeutet, dass die Verwaltungssoftware noch mehr Variablen enthält. Um mit dem Namen der Variablen verbundene Fehler zu beseitigen, wird ein Gerätecodierungssystem verwendet. In der Signaldatenbank werden Gruppen von Signalen gebildet, deren eindeutige Namen den Systemcode, den Gerätetyp und einen eindeutigen Code innerhalb des Systems enthalten.

In diesem Beispiel befinden sich im Hydraulikkreis zwei Instanzen des Ventils im System 502, das vom Block ZRA TYP 1 gesteuert wird. (siehe Abb. 12.) Ihre Namen in der Datenbank sind 502GTVOO1 und 502GTVOO2 . Das Signaldatenbankfenster ist in Abbildung 12 dargestellt.

Abbildung 12. Datenbank mit Signalen von Geräten des Steuerungssystems SPD.

Das Codierungssystem ermittelt die Namen von Variablen für die Module der Steuerungssoftware und ermöglicht es Ihnen, die Prozesse der Benennung von Signalen innerhalb des gesamten entwickelten Softwaremoduls zu automatisieren. Jeder Variablenname besteht aus dem Signalgruppennamen und dem Variablennamen, die durch das Zeichen „_“ verbunden sind.

Für alle Absperr- und Steuerventile, die sich auf den Schießstand "ZRA Type1" beziehen, sieht der Name der Eingangssignale, Zustandsvariablen und Ausgangsvariablen wie " Ankercode " _ " Signalname " aus. Für das Ventil 502GTV002 enthält die Signaldatenbank 65 Variablen, zum Beispiel:

Mannschaften:
502GTV002_open_rem - Fernöffnungsbefehl .
502GTV002_close_rem - Befehl zum Schließen der Fernbedienung.
502GTV002_open_rem_z - vorläufiger Befehl zum Schließen.

Bewehrungsstatusvariablen:
502GTV002_geöffnet - das Ventil ist vollständig geöffnet.
502GTV002_notopened - Ventil nicht geöffnet.
502GTV002_notclosed - Ventil nicht geschlossen.
502GTV002_losed - Das Ventil ist vollständig geschlossen.

Parameter für den Einlass und Auslass von Hydraulikflüssigkeit:

502GTV002_XTK1 - Druck in der Arbeitsleitung.
502GTV002_XTK2 - Druck in der Druckleitung.
502GTV002_XTK3 - Druck in der Abflussleitung.

Wenn wir diesem Schema eine weitere Verstärkungseinheit hinzufügen, lautet der Name 502GTV003, wobei dies dem akzeptierten Codierungssystem entspricht

502 ist der Name des Moduls.
GTV - Art der Verstärkung.
003 - Seriennummer der Ventile dieses Typs im Modul.

Während der Entwicklung des Steuermoduls können Parameterwerte in der Signaldatenbank eingestellt werden, und somit wird der Zustand einer separaten Steuereinheit überprüft. Insbesondere wird der Zustand der Ventile in diesem Beispiel durch den Druck in den Einlass- und Auslassleitungen der Hydraulikflüssigkeit bestimmt. Um das Steuermodul getrennt vom Rest des Systems zu testen, kann dieser Druck manuell in der Signaldatenbank eingestellt werden.

Wenn das Gerät als Teil der PMU betrieben wird, müssen die Druckwerte von den jeweiligen Sensoren auf das Steuergerät übertragen werden. Hierzu werden Schnittstellenblöcke verwendet, deren Name mit dem Namen des Geräts übereinstimmt - siehe Abb. 13. Zur Vereinfachung des Debuggens zeigt derselbe Block die Werte der von Sensoren empfangenen Signale an.

Abbildung 13. Übertragung von Signalen von Sensoren an die Steuereinheit ZRA T1.

Durch den Betrieb dieser Einheit wird ein Team gebildet, um die Spulen in den Steuerventilen zu bewegen, die für das Vorschaltgerät mit dem Namen 502GTV002 verantwortlich sind .

Während der Gelenkberechnung werden die im Hydraulikmodell berechneten Parameterwerte an die Sensorleseverarbeitungseinheit (siehe Abb. 14) übertragen, wo die erhaltenen Daten auf Zuverlässigkeit, Filterung und Übersetzung in die erforderlichen Messwerte analysiert werden.

Abbildung 14. Das Entwurfsschema für die Verarbeitung von Sensoren.

Das in Abbildung 14 gezeigte Berechnungsschema für die Verarbeitung von Sensorwerten ist ebenfalls ein voll funktionsfähiges Programm. Um diese Schaltung auf ein reales Steuergerät zu übertragen, reicht es aus, wenn der von der Eingangs- / Ausgangsplatine des realen Sensors empfangene Wert in der Variablen „Schätzwert“ auf dem Datenaustausch-Takt in einem realen Gerät platziert wird.

Diese Schaltung ist ebenfalls vektoriell und stellt die Verarbeitung aller Sensoren bereit, die in der Hydraulikschaltung 502.prt enthalten sind

Entworfene und getestete Standardentwurfsblöcke werden in eine Bibliothek von Standardlösungen gestellt und anschließend von anderen Entwicklern für alle Geräte dieses Typs verwendet.

Nach dem Debuggen und Überprüfen aller erforderlichen Berechnungsschemata typischer Programme wird die Entwicklung von Steuerungssoftware für jedes Unterwassermodul klar, einfach und effektiv. Sie können jedes Gerät in zwei Schritten hinzufügen:

• Stellen Sie das Gerätesteuergerät auf.
• Fügen Sie so viele Schnittstelleneinheiten hinzu, wie viele Geräteinstanzen an die PMU angeschlossen werden.

OOP-Methodik in grafischen Sprachen in Aktion.

.

. . .

.

« , () 5 »

, . . . . . , , , . , , - , .

, - (. . 15).

15. .

. , 9, 10 7, 8 (. . 16).

16. .

(. . 17). , , . , , .

17. .

, , .

18 . , .

19 .

18. 2- .

19. .

, , , , 30,5 , , 32, .

« () 5 »

, 5 , . , « () 5 », , , , 8 ( ). ( ).

Schlussfolgerungen

- , !

. .

. .

, , , , . , - , .

- , !

, — .