Vérification automatique des exigences TOR dans le processus de simulation dynamique

Continuant le thème "Quelle est votre preuve?", regardons le problème de la modélisation mathématique de l'autre côté. Une fois convaincus que le modèle correspond à la vérité artisanale de la vie, nous pouvons répondre à la question principale : « qu’avons-nous exactement ici ? Lors de la création d'une maquette d'un objet technique, nous voulons généralement nous assurer que cet objet répondra à nos attentes. A cet effet, des calculs dynamiques des processus sont effectués et le résultat est comparé aux exigences. Il s'agit d'un jumeau numérique, d'un prototype virtuel, etc. des petits gars à la mode qui, dès la phase de conception, résolvent le problème de savoir comment s'assurer que nous obtenons ce que nous avons prévu.

Comment pouvons-nous rapidement nous assurer que notre système correspond exactement à ce que nous avons conçu ? Notre conception volera-t-elle ou flottera-t-elle ? Et s’il vole, à quelle hauteur ? Et s’il flotte, à quelle profondeur ?

Cet article traite de l'automatisation de la vérification du respect des exigences d'un bâtiment technique lors de la création de modèles dynamiques de systèmes techniques. A titre d'exemple, regardons un élément de la spécification technique d'un système de refroidissement par air d'avion.

Nous considérons 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 qu'il ne s'agit là que d'une partie des exigences générales de tout système technique, mais c'est à leur vérification que nous consacrons du temps, des nerfs et de l'argent à créer des modèles dynamiques de l'objet.

Lors de la description des exigences techniques sous la forme d'un document, plusieurs types d'exigences différentes peuvent être distingués, chacun nécessitant des approches différentes pour la formation d'une vérification automatique du respect des exigences.

Par exemple, considérons cet ensemble d’exigences restreint mais réaliste :

1. Température de l'air atmosphérique à l'entrée du système de traitement de l'eau :
   sur le parking - de moins 35 à 35 ºС,
   en vol - de moins 35 à 39 ºС.
2. La pression statique de l'air atmosphérique en vol est de 700 à 1013 GPa (de 526 à 760 mm Hg).
3. La pression totale de l'air à l'entrée de la prise d'air SVO en vol est de 754 à 1200 GPa (de 566 à 1050 mm Hg).
4. Température de l'air de refroidissement :
   sur le parking - pas plus de 27 ºС, pour les blocs techniques - pas plus de 29 ºС,
   en vol - pas plus de 25 ºС, pour les blocs techniques - pas plus de 27 ºС.
5. Débit d'air de refroidissement :
   en stationnement - au moins 708 kg/h,
   en vol - pas moins de 660 kg/h.
6. La température de l'air dans les compartiments à instruments ne dépasse pas 60 ºC.
7. La quantité d’humidité libre fine dans l’air de refroidissement ne dépasse pas 2 g/kg d’air sec.

Même au sein de cet ensemble limité d’exigences, il existe au moins deux catégories qui doivent être traitées différemment dans le système :

• exigences relatives aux conditions de fonctionnement du système (clauses 1 à 3);
• exigences paramétriques pour le système (articles 3 à 7).

Exigences relatives aux conditions de fonctionnement du système
Les conditions externes du système développé lors de la modélisation peuvent être spécifiées comme conditions aux limites ou comme résultat du fonctionnement du système général.
En simulation dynamique, il est nécessaire de s'assurer que les conditions de fonctionnement spécifiées sont couvertes par le processus de simulation.

Exigences paramétriques du système
Ces exigences sont des paramètres fournis par le système lui-même. Au cours du processus de modélisation, nous pouvons obtenir ces paramètres sous forme de résultats de calcul et nous assurer que les exigences sont respectées dans chaque calcul spécifique.

Identification et codage des exigences

Pour faciliter l'utilisation des exigences, les normes existantes recommandent d'attribuer un identifiant à chaque exigence. Lors de l'attribution des identifiants, il est hautement souhaitable d'utiliser un système de codage unifié.

Le code d'exigence peut être simplement un nombre qui représente le numéro d'ordre de l'exigence, ou il peut contenir un code pour le type d'exigence, un code pour le système ou l'unité auquel il s'applique, un code de paramètre, un code d'emplacement et tout ce que l'ingénieur peut imaginer. (voir l'article pour l'utilisation de l'encodage)

Le tableau 1 fournit un exemple simple de codage des exigences.

1. code de la source des exigences R-exigences TK ;
2. code type d'exigences E - exigences - paramètres environnementaux ou conditions de fonctionnement
   S - exigences fournies par le système ;
3. code d'état de l'avion 0 – n'importe lequel, G – stationné, F – en vol ;
4. Code de type de paramètre physique T – température, P – pression, G – débit, humidité H ;
5. numéro de série du besoin.

ID Exigences	description	Paramètre
REGT01	Température de l'air ambiant à l'entrée du système de refroidissement par eau : sur le parking - à partir de moins 35ºС. jusqu'à 35 ºС.
REFT01	Température de l'air atmosphérique à l'entrée du système de défense aérienne : en vol - de moins 35 ºС à 39 ºС.
REFP01	La pression atmosphérique statique en vol est de 700 à 1013 hPa (de 526 à 760 mm Hg).
REFP02	La pression totale de l'air à l'entrée de la prise d'air SVO en vol est de 754 à 1200 hPa (de 566 à 1050 mm Hg).
RSGT01	Température de l'air de refroidissement : en stationnement pas plus de 27 ºС
RSGT02	Température de l'air de refroidissement : dans le parking, pour les unités techniques pas plus de 29 ºС
RSFT01	Température de l'air de refroidissement en vol ne dépassant pas 25 ºС
RSFT02	Température de l'air de refroidissement : en vol, pour les unités techniques pas plus de 27 ºС
RSGG01	Débit d'air de refroidissement : en stationnement, pas moins de 708 kg/h
RSFG01	Débit d'air de refroidissement : en vol pas moins de 660 kg/h
RS0T01	Température de l'air dans les compartiments à instruments ne dépassant pas 60 ºС
RSH01	La quantité d'humidité libre fine dans l'air de refroidissement ne dépasse pas 2 g/kg d'air sec.

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

Pour chaque exigence de conception, il existe un algorithme permettant d'évaluer la correspondance des paramètres de conception et des paramètres spécifiés dans l'exigence. Dans l'ensemble, tout système de contrôle contient toujours des algorithmes permettant de vérifier les exigences simplement par défaut. Et même n’importe quel régulateur en contient. Si la température dépasse les limites, le climatiseur s'allume. Ainsi, la première étape de toute réglementation consiste à vérifier si les paramètres répondent aux exigences.

Et puisque la vérification est un algorithme, nous pouvons alors utiliser les mêmes outils et outils que ceux que nous utilisons pour créer des programmes de contrôle. Par exemple, l'environnement SimInTech permet de créer des packages de projets contenant différentes parties du modèle, exécutés sous forme de projets distincts (modèle objet, modèle de système de contrôle, modèle d'environnement, etc.).

Dans ce cas, le projet de vérification des exigences devient le même projet d'algorithme et est connecté au package modèle. Et en mode modélisation dynamique, il effectue une analyse pour vérifier le respect des exigences des spécifications techniques.

Un exemple possible de conception de système est présenté à la figure 1.

Figure 1. Exemple de conception d'un projet de vérification.

Tout comme pour les algorithmes de contrôle, les exigences peuvent être rédigées sous forme de fiches. Pour faciliter le travail avec des algorithmes dans des environnements de modélisation structurelle tels que SimInTech, Simulink, AmeSim, la possibilité de créer des structures multi-niveaux sous forme de sous-modèles est utilisée. Cette organisation permet de regrouper diverses exigences en ensembles pour simplifier le travail avec un ensemble d'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 considéré, on distingue deux groupes : les exigences liées à 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 connecter les données au modèle, un schéma standard de génération d'une base de données de signaux est utilisé, qui stocke les données à échanger entre les parties du projet.

Lors de la création et du test du logiciel, les lectures des capteurs (analogues des capteurs réels du système) utilisés par le système de contrôle sont placées dans cette base de données.
Pour un projet de test, tous les paramètres calculés dans le modèle dynamique peuvent être stockés dans la même base de données et ainsi utilisés pour vérifier si les exigences sont remplies.

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

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

Un exemple de fiche de vérification des exigences de base est présenté dans la figure 4. Du point de vue du développeur, il s’agit d’un schéma de calcul classique sur lequel l’algorithme de vérification des exigences est présenté graphiquement.

Figure 4. Feuille de vérification des exigences.

Les principales parties de la feuille de contrôle sont décrites dans la figure 5. L'algorithme de contrôle est formé de la même manière que les schémas de conception des algorithmes de contrôle. Sur le côté droit se trouve un bloc pour lire les signaux de la base de données. Ce bloc accède à la base de données de signaux pendant la simulation.

Les signaux reçus sont analysés pour calculer les conditions de vérification des exigences. Dans ce cas, une analyse d'altitude est effectuée pour déterminer la position de l'avion (qu'il soit stationné ou en vol). À cette fin, vous pouvez utiliser d'autres signaux et paramètres calculés du modèle.

Les conditions de vérification et les paramètres vérifiés sont transférés vers des blocs de vérification standard, dans lesquels ces paramètres sont analysés pour vérifier leur conformité aux exigences spécifiées. Les résultats sont enregistrés dans la base de données de signaux de manière à pouvoir être utilisés pour générer automatiquement une liste de contrôle.

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

Les paramètres à tester n'utilisent pas nécessairement des signaux contenus dans la base de données, qui sont contrôlés par des paramètres calculés lors du processus de simulation. Rien ne nous empêche d'effectuer des calculs complémentaires dans le cadre du projet d'exigences, au même titre que nous calculons les conditions de vérification.

Par exemple, cette exigence :

Le nombre d'activations du système de correction pendant le vol vers la cible ne doit pas dépasser 5 et la durée totale de fonctionnement du système de correction ne doit pas dépasser 30 secondes.

Dans ce cas, un algorithme de comptage du nombre de démarrages et de la durée totale de fonctionnement est ajouté au schéma de conception des besoins.

Bloc de vérification des exigences typiques.

Chaque case à cocher d'exigence standard est conçue pour calculer le respect d'une exigence d'un certain type. Par exemple, les exigences environnementales incluent une plage de températures ambiantes de fonctionnement en stationnement et en vol. Ce bloc doit recevoir la température de l'air dans le modèle en paramètre et déterminer si ce paramètre couvre la plage de température spécifiée./p>

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

Le premier est alimenté avec le paramètre en cours de vérification. Dans ce cas, « Température extérieure ».

Une variable booléenne est fournie au deuxième port - la condition pour effectuer la vérification.

Si VRAI (1) est reçu à la deuxième entrée, alors le bloc effectue un calcul de vérification des exigences.

Si la deuxième entrée reçoit FAUX (0), alors les conditions de test ne sont pas remplies. Ceci est nécessaire pour que les conditions de calcul puissent être prises en compte. Dans notre cas, cette entrée permet d'activer ou de désactiver le contrôle en fonction de l'état du modèle. Si l'avion est au sol pendant la simulation, alors les exigences liées au vol ne sont pas vérifiées, et vice versa - si l'avion est en vol, alors les exigences liées au fonctionnement au poste de stationnement ne sont pas vérifiées.

Cette entrée peut également être utilisée lors de la configuration du modèle, par exemple au stade initial du calcul. Lorsque le modèle est amené à l'état requis, les blocs de contrôle sont désactivés, mais dès que le système atteint le mode de fonctionnement requis, les blocs de contrôle sont activés.

Les paramètres de ce bloc sont :

• conditions aux limites : limites de plage supérieure (UpLimit) et inférieure (DownLimit) à vérifier ;
• temps d'exposition requis du système aux plages limites (TimeInterval) en secondes ;
• ID de demande NomReq ;
• possibilité de dépasser la plage Out_range est une variable booléenne qui détermine si une valeur dépassant la plage vérifiée constitue une violation de l'exigence.

Dans certains cas, la sortie de la valeur de test indique que le système a une marge et peut fonctionner en dehors de sa plage de fonctionnement. Dans d'autres cas, une sortie signifie que le système est incapable de maintenir les points de consigne dans les limites.

Figure 6. Un bloc de vérification de propriété typique dans le diagramme et ses paramètres.

Suite au calcul de ce bloc, la variable Résultat est formée en sortie, qui prend les valeurs suivantes :

• 0 – rAucun, valeur non définie ;
• 1 – rFait, l’exigence est remplie ;
• 2 – rDéfaut, la condition n'est pas remplie.

L'image du bloc contient :

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

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

Par exemple, pour vérifier la plage de température de fonctionnement de l'unité illustrée à la figure 6, le circuit interne est illustré à la figure 7.

Figure 7. Schéma interne de l'unité de détermination de la plage de température.

À l'intérieur du bloc de circuit, les propriétés spécifiées dans les paramètres du bloc sont utilisées.
En plus d'analyser le respect des exigences, le schéma interne du bloc contient un graphique nécessaire à l'affichage des résultats de simulation. Ce graphique peut être utilisé à la fois pour visualiser pendant le calcul et pour analyser les résultats après le calcul.

Les résultats du calcul sont transmis à la sortie du bloc et sont simultanément enregistrés dans un fichier de rapport général, créé sur la base des résultats de l'ensemble du projet. (voir fig. 8)

Un exemple de rapport créé sur la base des résultats de simulation est un fichier HTML créé selon un format spécifié. Le format peut être arbitrairement configuré selon le format accepté par une organisation particulière.

À l'intérieur du bloc de circuit, les propriétés spécifiées dans les paramètres du bloc sont utilisées.
En plus d'analyser le respect des exigences, le schéma interne du bloc contient un graphique nécessaire à l'affichage des résultats de simulation. Ce graphique peut être utilisé à la fois pour visualiser pendant le calcul et pour analyser les résultats après le calcul.

Les résultats du calcul sont transmis à la sortie du bloc et sont simultanément enregistrés dans un fichier de rapport général, créé sur la base des résultats de l'ensemble du projet. (voir fig. 8)

Un exemple de rapport créé sur la base des résultats de simulation est un fichier HTML créé selon un format spécifié. Le format peut être arbitrairement configuré selon le format accepté par une organisation particulière.

Figure 8. Exemple de fichier de rapport basé sur les résultats de simulation.

Dans cet exemple, le formulaire de rapport est configuré directement dans les propriétés du projet et le format du tableau est défini comme signaux globaux du projet. Dans ce cas, SimInTech résout lui-même le problème de configuration du rapport, et le bloc d'écriture des résultats dans un fichier utilise ces lignes pour écrire dans le fichier rapport.

Figure 9. Définition du format de rapport dans les signaux globaux du projet

Utilisation d'une base de données de signaux pour les exigences.

Pour automatiser le travail avec les paramètres de propriété, une structure standard est créée dans la base de données de signaux pour chaque bloc typique. (voir fig. 10)

Figure 10. Exemple de structure d'un bloc de contrôle d'exigences dans une base de données de signaux.

La base de données de signaux fournit :

• Stockage de tous les paramètres de configuration système nécessaires.
• Visualisation pratique des exigences du projet existant à partir des paramètres spécifiés et des résultats de modélisation actuels.
• Mise en place d'un bloc ou d'un groupe de blocs à l'aide d'un langage de programmation de script. Les modifications dans la base de données de signaux entraînent des modifications dans les valeurs des propriétés de bloc dans le diagramme.
• Stockage des descriptions textuelles, des liens vers des éléments de spécifications techniques ou des identifiants dans le système de gestion des exigences.

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

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

La séquence d'interaction entre le projet de test SimInTech et le système de contrôle des exigences est la suivante :

1. Les termes de référence sont déclinés en exigences.
2. Les exigences des spécifications techniques sont identifiées et peuvent être vérifiées par modélisation mathématique des processus techniques.
3. Les attributs des exigences sélectionnées sont transférés à la base de données de signaux SimInTech dans la structure de blocs standard (par exemple, température maximale et minimale).
4. Pendant le processus de calcul, les données de structure sont transférées vers des schémas de conception, une analyse est effectuée et les résultats sont stockés dans une base de données de signaux.
5. Une fois le calcul terminé, les résultats de l'analyse sont transférés au système de gestion des exigences.

Les étapes 3 à 5 des exigences peuvent être répétées pendant le processus de conception lorsque des modifications de la conception et/ou des exigences surviennent et que l'impact de ces modifications doit être retesté.

Conclusions.

• Le prototype créé du système permet une réduction significative du temps d'analyse des modèles existants pour vérifier leur conformité aux exigences des spécifications techniques.
• La technologie de test proposée utilise des modèles dynamiques déjà existants et peut être utilisée même pour n'importe quel modèle dynamique, y compris ceux non réalisés dans l'environnement SimInTech.
• L'utilisation de l'organisation des données par lots vous permet de créer des packages de vérification des exigences en parallèle avec le développement du modèle, ou même d'utiliser ces packages comme spécifications techniques pour le développement du modèle.
• La technologie peut être intégrée aux systèmes de gestion des exigences existants sans coûts importants.

Pour ceux qui liront jusqu'au bout, lien vers une vidéo montrant le fonctionnement du prototype.

Source: habr.com