Poursuivant le sujet de la POO dans les langages de programmation graphique, nous examinerons plus en détail la conception basée sur un modèle. Qu'est-ce que le design orienté modèle (MOS), comment le cuisiner et avec quoi manger.

En décrivant une conception orientée modèle des systèmes de contrôle, certains auteurs transmettent dans leurs publications l'idée que le mot "modèle" signifie "modèle d'un système de contrôle". Ce qui ne va pas.

Pourquoi ce n'est pas vrai, comment le faire correctement et où vient Tchernobyl, lisez la suite.

Voici un exemple typique - une image tirée d'un article rédigé par des auteurs respectés sur les «meilleures pratiques de développement de logiciels utilisant une conception orientée modèle»:

Figure 1. L'une des options pour MOS.

Personnellement, en regardant cette photo, une question indécente se pose immédiatement, et de quel endroit, je m'excuse, aviez-vous des vecteurs de test?

Ou, par exemple, une image à la recommandation d'un processus de développement logiciel typique:

Figure 2. Une autre version du processus MOS.

Où est le modèle sur cette photo? Voici cette boîte à partir de laquelle le code source est obtenu? Vraiment?! Il s'agit donc là encore d'un modèle de logiciel de contrôle.

La présence d'exigences logicielles initiales est particulièrement touchante sur cette image.
Comme vous, par exemple, avez une exigence très courante, presque classique, pour un système de contrôle:

" Lorsque la pression dépasse la valeur limite, le temps de fermeture (ouverture) de la soupape de sécurité ne doit pas dépasser 5 secondes ."

Et comment commandez-vous sous ce schéma pour vérifier combien de secondes après que la pression a été dépassée, la soupape de sécurité s'ouvrira? Apparemment, quelque chose manque ici. Nous nous tournons vers la source inépuisable de vérité en dernier ressort - Wikipedia:

La conception basée sur un modèle fournit une approche efficace pour établir un cadre commun de communication tout au long du processus de conception tout en soutenant le cycle de développement (modèle V). Dans la conception de systèmes de contrôle basée sur un modèle, le développement se manifeste par ces quatre étapes:

1. modélisation d'une plante,
2. analyser et synthétiser un contrôleur pour l'installation,
3. simuler l'installation et le contrôleur,
4. intégrer toutes ces phases en déployant le contrôleur.

Le développement d'un modèle d'objet est le premier point de détermination du MOS. D'abord, un modèle de l'objet, puis contrôlez-le. Et c'est exact: il n'y a pas de modèle objet, «merci à tous - tout le monde est libre» et ce n'est pas un design orienté modèle, mais une fraude complète des consommateurs.

Pourquoi est-ce important et d'où vient Tchernobyl?

À Tchernobyl, exactement ce qui s'est passé en l'absence d'un modèle d'objet s'est produit. Des scientifiques soviétiques se sont demandé: «Que se passera-t-il si l'alimentation électrique est déconnectée et que les pompes de refroidissement du réacteur sont alimentées en courant par un générateur fonctionnant sur une turbine en panne? "Quelle quantité d'eau les pompes pomperont-elles dans le réacteur avant l'arrêt de la turbine et du générateur?" Fait intéressant, ils ont posé une telle question sur la base de l'expérience de l'accident de la centrale nucléaire américaine, où l'approvisionnement en eau n'était pas suffisant pour le refroidissement et le réacteur américain a fondu. Et pour être sûr que nos réacteurs ne fondent pas, nous avons décidé de mener une expérience. Peut-être que la réponse à cette question rendrait la prochaine génération de réacteurs RBMK encore plus sûre. Nous voulions le meilleur, mais il s'est avéré comme toujours. À la suite de l'expérience, un réacteur sûr a d'abord été conduit à un état dangereux, puis a explosé. Et la prochaine génération de réacteurs RBMK n'est plus et n'est pas attendue. Amen.

Et si, au lieu d'expérimenter sur un réacteur, il était possible de faire la même chose sur un modèle mathématique d'un objet, alors, très probablement, nous construirions maintenant du RBMK-2400 dans le monde entier au lieu des réacteurs VVER-1200.

Après l'accident de Tchernobyl dans l'industrie nucléaire, un modèle objet (réacteur nucléaire) fait obligatoirement partie du projet. Le concepteur doit montrer sur le modèle ce qui se passera en cas de problème. Et donc, la conception orientée modèle est apparue parmi les ingénieurs nucléaires beaucoup plus tôt que dans d'autres industries, en raison des exigences des organismes de réglementation.

Mais même lorsqu'il n'y a aucune exigence de la part des autorités réglementaires, le modèle de l'objet facilite grandement la conception du système de contrôle et de l'objet lui-même. Maintenant, nous montrons cela avec un exemple d'une industrie où «les rêves deviennent réalité».

La bonne approche orientée modèle.

Comme exemple du MOS casher correct, considérons le processus de développement d'un logiciel de contrôle pour le système de contrôle hydraulique d'un complexe minier sous-marin (comme toujours, c'est absolument par accident que j'ai eu ce modèle sur mon ordinateur).

Le contrôle des principaux flux du gaz produit par l'alimentation est assuré par des équipements hydrauliques sous-marins. Sur le rivage, il y a une station de pompage, qui fournit de la pression dans le système hydraulique, l'huile est fournie par un ombilical sous pression sous l'eau. L'ouverture et la fermeture des vannes sont effectuées par des actionneurs hydrauliques, qui sont contrôlés par un système de contrôle distribué. Le système comprend:

• module de contrôle au sol pour l'ensemble du champ;
• un ensemble de modules de contrôle sous-marin (PMU) assurant un contrôle direct des vannes.

Pour faciliter l'installation et la maintenance, les canalisations sont combinées en collecteurs, où les vannes et modules de commande nécessaires sont installés sur une seule plate-forme. Si, dans la station au sol, vous pouvez utiliser des outils SCADA standard, des serveurs d'archivage et des automates programmables avec des systèmes d'exploitation conventionnels et (ou) en temps réel, alors le module de contrôle sous-marin est, en règle générale, un microprocesseur non opérationnel, dont le code de contrôle doit être développé séparément du logiciel de contrôle côtier . (Pas de C ++, seulement du C, seulement du hardcode) Ensuite, plusieurs de ces PMU devraient être intégrées dans le système commun et testées. Et en même temps, l'ensemble du système devrait fonctionner dans son ensemble et permettre l'ouverture et la fermeture des vannes dans les 30 ans sous l'eau.

La tâche est compliquée par le fait que jusqu'à présent, tout l'équipement utilisé sur l'étagère était occidental, et l'étagère est maintenant sous sanctions. Et, en conséquence, il est nécessaire de créer un complexe dans lequel de nombreuses solutions techniques sont nouvelles et non traitées pour nous. Comment obtenir le résultat en réduisant si possible les erreurs de conception? Bon pour les développeurs occidentaux: ils ont déjà de l'expérience, ils connaissent les pièges de l'exploitation minière sous-marine. Et ici, la conception orientée modèle vient en aide aux développeurs. Au lieu de mener des expériences sur des équipements coûteux, comme les scientifiques nucléaires soviétiques de Tchernobyl, nous créons un modèle de l'objet et réalisons des expériences sur le modèle.

Modèle intégré du système de contrôle sous-marin

Pour la conception de logiciels, un modèle intégré est créé sous la forme d'un ensemble contenant à la fois des modèles d'écoulement de fluide hydraulique sous l'eau avec des raccords et des projets de système de contrôle. (voir fig.3)

Figure 3. Un package d'un modèle intégré du système de gestion SPD

Ce package contient un projet - un modèle de station hydraulique au sol (fichier 200.prt sur la figure 3), qui fournit la modélisation des processus dynamiques de l'équipement du système d'alimentation en eau hydraulique au sol pour l'eau. (voir fig.4)

Figure 4. Schéma de conception de la station hydraulique au sol.

Parallèlement au modèle des processus physiques, un projet de système de contrôle est en cours d'élaboration qui prévoit d'allumer et d'éteindre l'équipement et de contrôler les modes de fonctionnement de cet équipement. La figure 5 montre les ébauches d'algorithmes de commande pour le module de commande au sol.

Figure 5. Conception d'un système de contrôle de module au sol.

A ce stade, il est possible de répartir le développement d'algorithmes de contrôle entre différentes équipes. Par exemple, pour les développeurs d'une station hydraulique terrestre, les coûts des modules sous-marins et leur pression sont des conditions aux limites. Pour les développeurs d'équipements sous-marins, la condition aux limites est la pression créée par la station de pompage à terre.

Le développement de modules de contrôle sous-marin (PMU) est réalisé sur la base du projet de division des conduites principales de gaz entre les collecteurs. Tout d'abord, des puits sont formés, la tuyauterie et les raccords entre les puits et le rivage sont déterminés, puis un système de commande hydraulique pour ces vannes est développé.

Pour chaque module sous-marin, un modèle de projet de système de contrôle et un modèle de conception du système hydraulique du collecteur avec des vannes installées sont formés. Sur le schéma de conception du système hydraulique, des vannes sont installées, qui sont contrôlées à partir de ce module sous-marin. Cette conception peut être réalisée en parallèle avec le développement du module de commande au sol, tandis que le développement peut être réalisé indépendamment et en parallèle. Pour développer les algorithmes PMU et le fonctionnement des vannes, le système externe est défini par les commandes de contrôle et les conditions aux limites du système hydraulique.

Considérons le module de contrôle sous-marin (PMU) 502. Deux projets sont utilisés ici:

• 502.prt - modèle de systèmes hydrauliques (Fig. 6, 7);
• 502a.prt - le projet du système de contrôle de l'UGP (Fig. 8).

Figure 6. Le circuit hydraulique du PMU.

Ce schéma de conception fournit une simulation du comportement du système de commande hydraulique et le calcul des débits et des pressions dans un système contrôlé par 502 PMU. Le circuit hydraulique calculé vous permet de définir l'impact sur les actionneurs et d'obtenir des données de capteur calculées dans le modèle des processus physiques. Tant que nous n'avons pas de station au sol dans le bloc 502 P (coin inférieur gauche de la figure 6), nous pouvons définir la pression créée par la centrale hydroélectrique comme condition aux limites.

Dans le système, la figure montre 6 vannes d'arrêt et de commande hydrauliques (ZRA), chacune représentant intrinsèquement un vérin hydraulique connecté à deux conduites haute et basse pression. Nous appliquons plus de pression sur la partie supérieure du cylindre, la pression fait descendre la tige, nous appliquons plus de pression sur la partie inférieure du cylindre, la tige monte.

La commutation est contrôlée par des vannes de régulation situées à l'intérieur du bloc blanc (voir Fig. 7).

Figure 7. Bloc de vannes de distribution dans le modèle.

Le principe de fonctionnement est simple: en fonction de la position du tiroir, les chambres du vérin seront connectées à différentes lignes. Déplacé la bobine - changé le sens de déplacement de la tige dans le cylindre. (plus de détails sur la modélisation hydraulique peuvent être trouvés ici ... )

Figure 8. La conception du système de contrôle PMU.

Le logiciel de gestion de projet pour le module de contrôle sous-marin contient plusieurs blocs de calcul, chacun pouvant être développé par un développeur ou une équipe distinct. Dans ce cas, la séparation en modules se fait selon un attribut fonctionnel, chaque bloc est responsable de la commande d'un certain type de vanne. La méthodologie de la programmation orientée objet est appliquée, où le bloc est la classe OOP (plus de détails ici ... et ici ... )

Considérez le processus de conception d'une unité de commande pour les équipements d'arrêt et de commande. Ce bloc dans le circuit reçoit 4 signaux d'entrée et génère 8 signaux de sortie. (voir fig.9)

Figure 9. Unité de commande ZRA (Type 1).

Le schéma fonctionnel interne se compose de deux feuilles d'algorithmes. La première feuille est représentée sur la figure 10a, la seconde sur la figure 10b.

Figure 10a. Le schéma de conception de l'unité de commande de soupape. Fiche 1.

Figure 10b. Le schéma de conception de l'unité de commande de soupape. Fiche 2.

Lors du développement de cette unité, les types de signaux suivants sont utilisés:

• signaux reçus via les lignes de communication (blocs bleus);
• paramètres et signaux reçus de la base de données de signaux (blocs jaune pâle);
• signaux transmis à la base de données de signaux (blocs bleu pâle);
• signaux transmis à la mémoire (blocs jaune vif);
• signaux reçus de la mémoire (blocs vert clair).

Le schéma de conception de l'unité de commande de vanne est vectoriel. Cela signifie que pas un seul signal de commande n'est transmis sur chaque ligne, mais un vecteur de signaux dont la dimension correspond à la quantité d'équipements de ce type installés dans le PMP. Pour la communication entre l'unité de calcul et les signaux, paramètres et commandes pour un équipement spécifique, des unités d'interface sont utilisées.

Ainsi, après avoir développé et testé un circuit de commande d'un élément typique, autant d'interfaces peuvent être placées sur le circuit que l'équipement de ce type est connecté au module de commande sous-marin. Dans ce cas, dans le PMU, il existe deux unités d'interface pour les vannes d'arrêt et de régulation de type 1 (voir Fig. 8).

Tous les signaux et paramètres variables nécessaires à l'unité de commande sont placés dans la catégorie correspondante de la base de signaux ZRAT1 . Une partie de la catégorie est illustrée à la figure 11.

La séparation d'une catégorie distincte permet de séparer le développement des modules logiciels de contrôle en parties et de définir clairement l'interface d'interaction entre les différentes parties du programme. Ainsi, le développement du module de contrôle se déroule de manière isolée le long des interfaces des autres modules du logiciel.

Figure 11. Groupe de signaux pour l'unité de commande ZRAT1

Système de codage de projet

Le système contient plusieurs instances de ce type d'équipement, ce qui signifie qu'il y a encore plus de variables dans le logiciel de gestion. Afin d'éliminer les erreurs associées au nom des variables, un système de codage d'équipement est utilisé. Dans la base de données de signaux, des groupes de signaux sont formés dont les noms uniques contiennent le code système, le type d'équipement et un code unique au sein du système.

Dans cet exemple, sur le circuit hydraulique, nous avons deux instances de la vanne située dans le système 502, qui est contrôlée par le bloc ZRA TYPE 1 . (voir Fig. 12.) Leurs noms dans la base de données sont 502GTVOO1 et 502GTVOO2 . La fenêtre de la base de données de signaux est illustrée à la figure 12.

Figure 12. Base de données des signaux des équipements du système de contrôle SPD.

Le système de codage détermine les noms des variables pour les modules du logiciel de contrôle et vous permet d'automatiser les processus de dénomination des signaux dans l'ensemble du module logiciel développé. Tout nom de variable se compose du nom du groupe de signaux et du nom de variable reliés par le signe «_».

Pour toutes les vannes d'arrêt et de commande liées à la plage de prise de vue "ZRA Type1", le nom des signaux d'entrée, les variables d'état, les variables de sortie ressemble à " code_vanne " _ " nom_signal ". Pour la vanne 502GTV002 , il y a 65 variables dans la base de données de signaux, par exemple:

Équipes:
502GTV002_open_rem - commande d'ouverture à distance.
502GTV002_close_rem - commande de fermeture à distance.
502GTV002_open_rem_z - commande préliminaire pour fermer.

Variables d'état d'armature:
502GTV002_opened - la vanne est complètement ouverte.
502GTV002_notopened - valve non ouverte.
502GTV002_notclosed - valve non fermée.
502GTV002_losed - La vanne est complètement fermée.

Paramètres d'entrée et de sortie du fluide hydraulique:

502GTV002_XTK1 - pression dans la ligne de travail.
502GTV002_XTK2 - pression dans la conduite de pression.
502GTV002_XTK3 - pression dans la conduite de vidange.

Si nous ajoutons une unité de renforcement supplémentaire à ce schéma, son nom sera 502GTV003, selon le système de codage accepté.

502 est le nom du module.
GTV - type de renfort.
003 - numéro de série des vannes de ce type dans le module.

Pendant le développement du module de contrôle, les valeurs des paramètres peuvent être définies dans la base de données de signaux, et ainsi, la santé d'une unité de contrôle séparée est vérifiée. En particulier, l'état des soupapes dans cet exemple est déterminé par la pression dans les conduites d'entrée et de sortie du fluide hydraulique. Pour tester le module de commande séparément du reste du système, cette pression peut être réglée manuellement dans la base de données des signaux.

Lorsque l'unité fonctionne dans le cadre de la PMU, il est nécessaire de transférer les valeurs de pression des capteurs respectifs vers l'unité de commande. Pour cela, des blocs d'interface sont utilisés, dont le nom coïncide avec le nom de l'équipement - voir Fig. 13. Pour faciliter le débogage, le même bloc affiche les valeurs des signaux reçus des capteurs.

Figure 13. Transmission des signaux des capteurs à l'unité de contrôle ZRA T1.

À la suite du fonctionnement de cette unité, une équipe est formée pour déplacer les bobines dans les vannes de commande, qui sont responsables de l'équipement de commande avec le nom 502GTV002 .

Pendant le calcul conjoint, les valeurs des paramètres calculées dans le modèle hydraulique sont transférées à l'unité de traitement de lecture du capteur (voir Fig.14), où les données obtenues sont analysées pour la fiabilité, le filtrage et la traduction dans les valeurs de mesure requises.

Figure 14. Schéma de conception pour le traitement des capteurs.

Le schéma de calcul pour le traitement des lectures de capteur illustré à la figure 14 est également un programme entièrement fonctionnel. Pour transférer ce circuit vers un équipement de contrôle réel, il suffit que la valeur reçue de la carte d'entrée / sortie du capteur réel soit placée dans la variable "Valeur estimée" sur l'horloge d'échange de données dans l'équipement réel.

, 502.prt

.

, . :

• .
• , .

.

.

. . .

.

« , () 5 »

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

, - (. . 15).

15. .

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

16. .

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

17. .

, , .

18 . , .

19 .

18. 2- .

19. .

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

« () 5 »

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

Conclusions

- , !

. .

. .

, , , , . , - , .

- , !

, — .