Vérification automatique des exigences du cahier des charges lors de la modélisation dynamique

Poursuivant le sujet «Quelles sont vos preuves ? », examinons le problème de la modélisation mathématique sous un autre angle. Une fois que nous avons vérifié que le modèle correspond à la dure réalité de la vie, nous pouvons répondre à la question principale : « Qu'avons-nous ici, en fait ? ». En créant un modèle d'un objet technique, nous voulons généralement nous assurer que cet objet répondra à nos attentes. C'est pour cela que des calculs dynamiques des processus sont effectués et que le résultat est comparé aux exigences. C'est ce qu'on appelle un jumeau numérique, un prototype virtuel et d'autres tendances modernes qui, au stade de la conception, résolvent le problème de comment s'assurer que nous obtenons ce que nous avions prévu.

Comment pouvons-nous rapidement nous assurer que notre système est exactement ce que nous concevons, s'il volera ou naviguera, notre construction ? Et s'il vole, à quelle hauteur ? Et s'il flotte, à quelle profondeur ?

Cet article traite de l'automatisation de la vérification de la conformité aux exigences techniques d'un bâtiment lors de la création de modèles dynamiques de systèmes techniques. Prenons pour exemple un élément du cahier des charges pour un système de refroidissement par air d'un aéronef.

Nous examinons les exigences qui peuvent être exprimées numériquement et vérifiées mathématiquement sur la base d'un modèle de calcul spécifique. Il est clair que ce n'est qu'une partie des exigences générales pour tout système technique, mais c'est précisément sur leur vérification que nous dépensons temps, nerfs et argent pour la création de modèles dynamiques de l'objet.

Lors de la description des exigences techniques sous forme de document, plusieurs types d'exigences peuvent être identifiés, chacune nécessitant des approches différentes pour la formation de vérifications automatiques de conformité.

Par exemple, considérons ce petit ensemble mais réel d'exigences :

1. Température de l'air atmosphérique à l'entrée du système de refroidissement :
   au sol - de -35 à 35 ºC,
   en vol - de -35 à 39 ºC.
2. Pression statique de l'air atmosphérique en vol - de 700 à 1013 hPa (de 526 à 760 mm Hg).
3. Pression totale de l'air à l'entrée du collecteur d'air en vol - de 754 à 1200 hPa (de 566 à 1050 mm Hg).
4. Température de l'air de refroidissement :
   au sol - pas plus de 27 ºC, pour les blocs techniques - pas plus de 29 ºC,
   en vol - pas plus de 25 ºC, pour les blocs techniques - pas plus de 27 ºC.
5. Débit d'air de refroidissement :
   au sol - pas moins de 708 kg/h,
   en vol - pas moins de 660 kg/h.
6. La température de l'air dans les compartiments d'instruments - pas plus de 60 ºC.
7. La quantité de petites particules d'humidité libre dans l'air de refroidissement - pas plus de 2 g/kg d'air sec.

Même avec cet ensemble limité d'exigences, on peut identifier au moins deux catégories qui doivent être traitées différemment dans le système :

• les exigences des conditions d'exploitation du système (par. 1-3);
• les exigences paramétriques du système (par. 3-7).

Exigences des conditions d'exploitation du système
Les conditions extérieures pour le système en cours de développement lors de la modélisation peuvent être définies comme des conditions limites, ou comme le résultat du fonctionnement du système global.
Lors de la modélisation dynamique, il est nécessaire de s'assurer que les modes de fonctionnement spécifiés sont couverts par le processus de modélisation.

Exigences paramétriques du système
Ces exigences constituent des paramètres fournis par le système lui-même. Au cours de la modélisation, nous pouvons obtenir ces paramètres comme résultats du calcul et vérifier que les exigences sont satisfaites dans chaque calcul spécifique.

Identification et codage des exigences

Pour faciliter le travail avec les exigences, les normes existantes recommandent d'attribuer un identifiant à chaque exigence. Lors de l'attribution des identifiants, il est fortement conseillé d'utiliser un système de codage uniforme.

Le code de l'exigence peut simplement être un numéro représentant l'ordre de l'exigence, ou il peut contenir un code de type d'exigence, un code système ou d'assemblage auquel il s'applique, un code de paramètre, un code de localisation et bien d'autres choses que l'ingénieur peut imaginer. (voir l'article pour un exemple d'utilisation du codage)

Le tableau 1 présente un exemple simple de codage des exigences.

1. code de la source des exigences R - exigences de spécifications techniques ;
2. code type d'exigences E - exigences - paramètres de l'environnement extérieur, ou conditions d'exploitation
   S - exigences fournies par le système ;
3. code de l'état de l'avion 0 - tout état, G - au sol, F - en vol ;
4. code type de paramètres physiques T - température, P - pression, G - débit, H - humidité ;
5. numéro d'ordre de l'exigence.

Projet du système de vérification des exigences.

Pour chaque exigence de calcul, il existe un algorithme d'évaluation de la conformité des paramètres calculés et des paramètres établis dans l'exigence. En gros, tout système de gestion contient toujours des algorithmes de vérification des exigences par défaut. Même tout régulateur les contient. Si la température dépasse les limites, le climatiseur s'active. Ainsi, la première étape de tout réglage est la vérification de la conformité des paramètres à l'exigence.

Et comme la vérification est un algorithme, on peut utiliser les mêmes moyens et outils que nous utilisons pour créer des programmes de gestion. Par exemple, l'environnement SimInTech permet de créer des packages de projets contenant diverses parties du modèle, réalisées sous forme de projets distincts (modèle d'objet, modèle de système de gestion, modèle d'environnement, etc.).

Le projet de vérification des exigences devient alors un projet d'algorithmes et se connecte au package modèle. Et en mode de modélisation dynamique, il effectue une analyse de conformité aux exigences du cahier des charges.

Un exemple possible de la présentation du projet système est illustré à la figure 1.

Figure 1. Exemple de présentation du projet de vérification.

Tout comme pour les algorithmes de contrôle, les exigences peuvent être présentées sous forme d'un ensemble de feuilles. Pour faciliter le travail avec les algorithmes dans des environnements de modélisation structurelle tels que SimInTech, Simulink, AmeSim, les fonctionnalités de création de structures multi-niveaux sous forme de sous-modèles sont utilisées. Cette organisation permet de regrouper diverses exigences en ensembles pour simplifier le travail avec l'ensemble des exigences, comme cela se fait pour les algorithmes de contrôle (voir Fig. 2).

Figure 2. Structure hiérarchique du modèle de vérification des exigences.

Par exemple, dans le cas examiné, deux groupes ont été identifiés : les exigences pour l'environnement et les exigences directement liées au système. Par conséquent, une structure de données à deux niveaux est utilisée : deux groupes, chacun étant une feuille de l'algorithme.

Pour relier les données au modèle, un schéma standard de formation d'une base de données de signaux est utilisé, dans laquelle les données pour l'échange entre les parties du projet sont stockées.

Lors de la création et des tests de logiciels, les mesures des capteurs (analogues aux réels capteurs du système) sont insérées dans cette base.
Pour le projet de test, n'importe quels paramètres calculés dans le modèle dynamique peuvent également être sauvegardés dans cette même base de données, et ainsi être utilisés pour vérifier le respect des exigences.

Le modèle dynamique lui-même peut, dans ce cas, être réalisé dans n'importe quel système de modélisation mathématique ou même sous forme de programme exécutable. La seule exigence est la présence d'interfaces logicielles pour émettre des données de modélisation dans un environnement externe.

Figure 3. Connexion du projet de vérification au modèle complexe.

Un exemple de feuille de vérification des exigences est présenté à la figure 4. Du point de vue du développeur, il représente un schéma de calcul habituel, où l'algorithme de vérification des exigences est représenté de manière graphique.

Figure 4. Feuille de vérification des exigences.

Les parties principales de la feuille de vérification sont décrites à la figure 5. L'algorithme de vérification se forme de manière similaire aux schémas de calcul des algorithmes de contrôle. Dans la partie droite se trouve un bloc de lecture des signaux provenant de la base de données. Ce bloc accède à la base de données des signaux pendant la modélisation.

Les signaux reçus sont analysés pour déterminer les conditions de vérification des exigences. Dans ce cas, une analyse de l'altitude est effectuée pour déterminer la position de l'avion (s'il est au sol ou en vol). D'autres signaux et paramètres calculés par le modèle peuvent également être utilisés à cet effet.

Les conditions de vérification et les paramètres vérifiés sont transmis à des blocs de vérification type, où l'analyse de ces paramètres est effectuée afin de vérifier leur conformité aux exigences spécifiées. Les résultats sont enregistrés dans une base de données de signaux de manière à pouvoir être utilisés pour générer automatiquement une checklist.

Figure 5. Structure de la feuille de calcul de vérification des exigences.

Les paramètres à vérifier ne doivent pas nécessairement utiliser des signaux présents dans la base de données, gérés par des paramètres calculés lors du processus de modélisation. Rien n’empêche de réaliser des calculs supplémentaires dans le cadre du projet d'exigences, tout comme nous calculons les conditions de vérification.

Par exemple, une exigence telle que :

Le nombre d'activations du système correcteur pendant le vol vers la cible ne doit pas dépasser 5, et le temps total de fonctionnement du système correcteur ne doit pas dépasser 30 secondes.

Dans ce cas, un algorithme de compteur du nombre d'activations et du temps total de fonctionnement est ajouté au schéma de calcul du projet d'exigences.

Bloc de vérification type des exigences.

Chaque bloc de vérification type des exigences est conçu pour calculer la conformité d'une exigence spécifique. Par exemple, les exigences liées à l'environnement comprennent une plage de températures de fonctionnement de l'air ambiant au sol et en vol. Ce bloc doit recevoir comme paramètre la température de l'air dans le modèle et déterminer si ce paramètre couvre la plage de températures spécifiée.

Le bloc contient deux ports d'entrée, param et condition.

Le premier reçoit le paramètre vérifié. Dans ce cas, "Température de l'environnement externe".

Le deuxième port reçoit une variable booléenne – condition de réalisation de la vérification.

Si TRUE (1) arrive à la deuxième entrée, le bloc effectue le calcul de vérification de l'exigence.

Si le second signal est FALSE (0), alors les conditions de vérification ne sont pas remplies. Cela est nécessaire pour tenir compte des conditions de calcul. Dans notre cas, ce signal est utilisé pour activer ou désactiver la vérification en fonction de l'état du modèle. Si l'aéronef est au sol pendant la modélisation, les exigences liées au vol ne sont pas vérifiées, et vice versa – si l'aéronef est en vol, les exigences liées aux opérations au sol ne sont pas vérifiées.

Ce signal peut également être utilisé lors de la configuration du modèle, par exemple au début du calcul. Lorsque le modèle est amené à l'état désiré, les blocs de vérification sont désactivés, mais dès que le système entre dans le mode de fonctionnement requis, les blocs de vérification sont activés.

Les paramètres de ce bloc sont les suivants :

• conditions limites : limite supérieure (UpLimit) et limite inférieure (DownLimit) des plages à vérifier ;
• le temps de maintien requis du système aux limites des plages (TimeInterval) en secondes ;
• l'identifiant de l'exigence ReqName ;
• la possibilité de sortie de la plage Out_range – une variable booléenne qui détermine si le dépassement de la valeur dans la plage vérifiée constitue une violation de l'exigence.

Dans certains cas, le dépassement de la valeur vérifiée signifie que le système a une marge et peut fonctionner en dehors de la plage de travail. Dans d'autres cas, le dépassement signifie que le système ne parvient pas à maintenir les paramètres requis dans la plage.

Figure 6. Bloc de vérification typique sur le schéma et ses paramètres.

En conséquence du calcul de ce bloc, une variable de sortie Result est formée, qui prend les valeurs suivantes :

• 0 – rNone, valeur non définie ;
• 1 – rDone, exigence satisfaite ;
• 2 – rFault, exigence non satisfaite.

L'image du bloc contient :

• texte de l'identifiant ;
• affichages numériques des paramètres de limites de mesure ;
• identifiant de couleur de l'état du paramètre.

À l'intérieur du bloc, il peut y avoir un schéma logique d'inférence assez complexe.

Par exemple, pour vérifier la plage de température de travail du bloc illustré à la figure 6, le schéma interne est présenté à la figure 7.

Figure 7. Schéma interne du bloc de définition de la plage de température.

À l'intérieur du bloc, les propriétés définies dans les paramètres du bloc sont utilisées.
En plus de l’analyse de conformité aux exigences, le schéma interne du bloc contient un graphique nécessaire pour afficher les résultats de la modélisation. Ce graphique peut être utilisé tant pour la visualisation pendant les calculs que pour l’analyse des résultats après les calculs.

Les résultats du calcul sont transmis à la sortie du bloc et en même temps enregistrés dans un fichier de rapport général, qui est créé sur la base des résultats de l’ensemble du projet. (voir fig. 8)

Un exemple de rapport créé à partir des résultats de la modélisation se présente sous la forme d’un fichier HTML, élaboré selon un format spécifié. Le format peut être configuré librement selon le format adopté dans l’organisation concernée.

À l'intérieur du bloc, les propriétés définies dans les paramètres du bloc sont utilisées.
En plus de l’analyse de conformité aux exigences, le schéma interne du bloc contient un graphique nécessaire pour afficher les résultats de la modélisation. Ce graphique peut être utilisé tant pour la visualisation pendant les calculs que pour l’analyse des résultats après les calculs.

Les résultats du calcul sont transmis à la sortie du bloc et en même temps enregistrés dans un fichier de rapport général, qui est créé sur la base des résultats de l’ensemble du projet. (voir fig. 8)

Un exemple de rapport créé à partir des résultats de la modélisation se présente sous la forme d’un fichier HTML, élaboré selon un format spécifié. Le format peut être configuré librement selon le format adopté dans l’organisation concernée.

Figure 8. Exemple de fichier de rapport sur les résultats de la modélisation.

Dans cet exemple, la configuration de la forme du rapport est effectuée directement dans les propriétés du projet, tandis que le format est donné dans le tableau comme signaux globaux du projet. Dans ce cas, SimInTech détermine lui-même la tâche de configuration du rapport, et le bloc d’enregistrement des résultats dans le fichier utilise ces lignes pour écrire dans le fichier de rapport.

Figure 9. Configuration du format du rapport dans les signaux globaux du projet

Utilisation de la base de données des signaux pour les exigences.

Pour automatiser le travail avec les propriétés de configuration de chaque bloc type, une structure type est créée dans la base de données des signaux. (voir fig. 10)

Figure 10. Exemple de structure de bloc de vérification des exigences dans la base de données des signaux.

La base de données des signaux fournit :

• Le stockage de tous les paramètres nécessaires aux exigences du système.
• Une visualisation pratique des exigences existantes dans le projet à partir des paramètres définis et des résultats actuels de la modélisation.
• La configuration d’un bloc, d’un groupe de blocs en utilisant un langage de programmation script. Les modifications dans la base de données des signaux entraînent un changement des valeurs des propriétés du bloc sur le schéma.
• Le stockage des descriptions textuelles, des liens vers des articles du CCT ou des identifiants dans le système de gestion des exigences.

Les structures de la base de données des signaux pour les exigences peuvent facilement être configurées pour fonctionner avec un système de gestion des exigences tiers. Le schéma général d’interaction avec les systèmes de gestion des exigences est présenté à la figure 11.

Figure 11. Schéma d'interaction avec le système de gestion des exigences.

La séquence d'interaction du projet de test SimInTech avec le système de gestion des exigences est la suivante :

1. Le cahier des charges est réparti en exigences.
2. On identifie les exigences du cahier des charges qui peuvent être vérifiées par la modélisation mathématique des processus techniques.
3. Les attributs des exigences identifiées sont transférés dans la base de données des signaux SimInTech dans des structures de blocs standards (par exemple, température maximale et minimale).
4. Lors du calcul, les données structurées sont transférées vers les schémas de calcul des blocs, l'analyse est effectuée et les résultats sont enregistrés dans la base de données des signaux.
5. À la fin du calcul, les résultats de l'analyse sont transférés dans le système de gestion des exigences.

Les étapes de travail avec les exigences 3 à 5 peuvent être répétées pendant le processus de conception, lorsque des modifications dans la conception et/ou les exigences se produisent, nécessitant ainsi une nouvelle vérification de l'impact des changements apportés.

Conclusions.

• Le prototype de système créé permet de réduire considérablement le temps d'analyse des modèles existants pour vérifier leur conformité aux exigences du cahier des charges.
• La technologie de test proposée utilise des modèles dynamiques déjà existants et peut être utilisée même pour tout modèle dynamique, y compris ceux réalisés en dehors de l'environnement SimInTech.
• L'utilisation d'une organisation de données par lots permet de créer des paquets de vérification des exigences, parallèlement au développement des modèles, ou même d'utiliser ces paquets comme cahier des charges pour le développement des modèles.
• La technologie peut être intégrée sans coût substantiel aux systèmes de gestion des exigences existants.

Pour ceux qui ont lu jusqu'à la fin, lien vers une vidéo de démonstration du fonctionnement du prototype.

Source : habr.com