Verificació automàtica dels requisits TOR en el procés de simulació dinàmica

Continuant amb el tema "Quina és la teva prova?", mirem el problema de la modelització matemàtica des de l'altra banda. Després d'estar convençuts que el model correspon a la veritat de la vida pròpia, podem respondre a la pregunta principal: "què, exactament, tenim aquí?" Quan es crea una maqueta d'un objecte tècnic, normalment volem assegurar-nos que aquest objecte compleixi les nostres expectatives. Amb aquesta finalitat, es realitzen càlculs dinàmics de processos i el resultat es compara amb els requisits. Aquest és un bessó digital, un prototip virtual, etc. nois petits de moda que, en l'etapa de disseny, resolen el problema de com assegurar-nos que aconseguim el que teníem previst.

Com podem assegurar-nos ràpidament que el nostre sistema és exactament el que dissenyem, el nostre disseny volarà o flotarà? I si vola, a quina altura? I si flota, a quina profunditat?

En aquest article es parla de l'automatització de la verificació del compliment dels requisits d'un edifici tècnic a l'hora de crear models dinàmics de sistemes tècnics. Com a exemple, mirem un element de l'especificació tècnica d'un sistema de refrigeració per aire d'un avió.

Considerem aquells requisits que es poden expressar numèricament i verificar matemàticament a partir d'un model de càlcul concret. És evident que això només és una part dels requisits generals de qualsevol sistema tècnic, però és en comprovar-los que dediquem temps, nervis i diners a crear models dinàmics de l'objecte.

Quan es descriuen els requisits tècnics en forma de document, es poden distingir diversos tipus de requisits diferents, cadascun dels quals requereix diferents enfocaments per a la formació de la verificació automàtica del compliment dels requisits.

Per exemple, considereu aquest petit però realista conjunt de requisits:

1. Temperatura de l'aire atmosfèric a l'entrada del sistema de tractament d'aigua:
   a l'aparcament - de menys 35 a 35 ºС,
   en vol - de menys 35 a 39 ºС.
2. La pressió estàtica de l'aire atmosfèric en vol és de 700 a 1013 GPa (de 526 a 760 mm Hg).
3. La pressió total de l'aire a l'entrada de la presa d'aire SVO en vol és de 754 a 1200 GPa (de 566 a 1050 mm Hg).
4. Temperatura de l'aire de refrigeració:
   a l'aparcament - no més de 27 ºС, per als blocs tècnics - no més de 29 ºС,
   en vol - no més de 25 ºС, per a blocs tècnics - no més de 27 ºС.
5. Flux d'aire de refrigeració:
   quan està estacionat - almenys 708 kg/h,
   en vol - no menys de 660 kg/h.
6. La temperatura de l'aire als compartiments dels instruments no supera els 60 ºС.
7. La quantitat d'humitat lliure fina a l'aire de refrigeració no supera els 2 g/kg d'aire sec.

Fins i tot dins d'aquest conjunt limitat de requisits, hi ha almenys dues categories que s'han de gestionar de manera diferent al sistema:

• requisits per a les condicions de funcionament del sistema (clàusules 1-3);
• requisits paramètrics del sistema (clàusules 3-7).

Requisits de condicions de funcionament del sistema
Les condicions externes del sistema que s'està desenvolupant durant la modelització es poden especificar com a condicions de límit o com a resultat del funcionament del sistema general.
En la simulació dinàmica, cal assegurar-se que el procés de simulació cobreix les condicions de funcionament especificades.

Requisits del sistema paramètric
Aquests requisits són paràmetres proporcionats pel propi sistema. Durant el procés de modelització, podem obtenir aquests paràmetres com a resultats del càlcul i assegurar-nos que es compleixen els requisits en cada càlcul concret.

Identificació i codificació de requisits

Per facilitar el treball amb els requisits, els estàndards existents recomanen assignar un identificador a cada requisit. Quan s'assignen identificadors, és molt desitjable utilitzar un sistema de codificació unificat.

El codi de requisit pot ser simplement un número que representa el número de comanda del requisit, o pot contenir un codi per al tipus de requisit, un codi per al sistema o unitat a què s'aplica, un codi de paràmetre, un codi d'ubicació i qualsevol altra cosa que l'enginyer pugui imaginar. (vegeu l'article per a l'ús de la codificació)

La taula 1 ofereix un exemple senzill de codificació de requisits.

1. codi de la font dels requisits R-requisits TK;
2. codi tipus de requisits E - requisits - paràmetres ambientals o condicions de funcionament
   S - requisits proporcionats pel sistema;
3. codi d'estat de l'aeronau 0 - qualsevol, G - aparcat, F - en vol;
4. codi de tipus de paràmetre físic T - temperatura, P - pressió, G - cabal, humitat H;
5. número de sèrie del requisit.

ID Requisits	Descripció	Paràmetre
REGT01	Temperatura de l'aire ambient a l'entrada del sistema de refrigeració d'aigua: a l'aparcament - des de menys 35ºС. fins a 35 ºС.
REFT01	Temperatura de l'aire atmosfèric a l'entrada del sistema de defensa aèria: en vol - de menys 35 ºС a 39 ºС.
REFP01	La pressió atmosfèrica estàtica en vol és de 700 a 1013 hPa (de 526 a 760 mm Hg).
REFP02	La pressió total de l'aire a l'entrada de la presa d'aire SVO en vol és de 754 a 1200 hPa (de 566 a 1050 mm Hg).
RSGT01	Temperatura de refrigeració de l'aire: quan està estacionat no més de 27 ºС
RSGT02	Temperatura de l'aire de refrigeració: a l'aparcament, per a unitats tècniques no superior a 29 ºС
RSFT01	La temperatura de l'aire de refrigeració en vol no supera els 25 ºС
RSFT02	Temperatura de l'aire de refrigeració: en vol, per a unitats tècniques no superior a 27 ºС
RSGG01	Flux d'aire de refrigeració: quan està estacionat no menys de 708 kg/h
RSFG01	Flux d'aire de refrigeració: en vol no inferior a 660 kg/h
RS0T01	La temperatura de l'aire als compartiments dels instruments no supera els 60 ºС
RSH01	La quantitat d'humitat lliure fina a l'aire de refrigeració no supera els 2 g/kg d'aire sec

Disseny del sistema de verificació de requisits.

Per a cada requisit de disseny hi ha un algorisme per avaluar la correspondència dels paràmetres de disseny i els paràmetres especificats en el requisit. En general, qualsevol sistema de control sempre conté algorismes per comprovar els requisits simplement per defecte. I fins i tot qualsevol regulador els conté. Si la temperatura supera els límits, l'aire condicionat s'encén. Així, la primera etapa de qualsevol regulació és comprovar si els paràmetres compleixen els requisits.

I com que la verificació és un algorisme, podem utilitzar les mateixes eines i eines que utilitzem per crear programes de control. Per exemple, l'entorn SimInTech us permet crear paquets de projectes que contenen diverses parts del model, executades en forma de projectes separats (model d'objecte, model de sistema de control, model d'entorn, etc.).

El projecte de verificació de requisits en aquest cas es converteix en el mateix projecte d'algorisme i està connectat al paquet del model. I en la modalitat de modelització dinàmica realitza una anàlisi per al compliment dels requisits de les especificacions tècniques.

Un exemple possible de disseny de sistema es mostra a la figura 1.

Figura 1. Exemple de disseny d'un projecte de verificació.

Igual que per als algorismes de control, els requisits es poden elaborar com un conjunt de fulls. Per a la comoditat de treballar amb algorismes en entorns de modelització estructural com ara SimInTech, Simulink, AmeSim, s'utilitza la capacitat de crear estructures de diversos nivells en forma de submodels. Aquesta organització permet agrupar diversos requisits en conjunts per simplificar el treball amb una sèrie de requisits, com es fa per als algorismes de control (vegeu la figura 2).

Figura 2. Estructura jeràrquica del model de verificació de requisits.

Per exemple, en el cas considerat, es distingeixen dos grups: requisits per al medi ambient i requisits directament per al sistema. Per tant, s'utilitza una estructura de dades de dos nivells: dos grups, cadascun dels quals és una fulla de l'algorisme.

Per connectar les dades al model, s'utilitza un esquema estàndard per generar una base de dades de senyals, que emmagatzema dades per a l'intercanvi entre parts del projecte.

En crear i provar programari, les lectures dels sensors (anàlegs de sensors del sistema real) que s'utilitzen pel sistema de control es col·loquen en aquesta base de dades.
Per a un projecte de prova, qualsevol paràmetre calculat en el model dinàmic es pot emmagatzemar a la mateixa base de dades i, per tant, utilitzar-se per comprovar si es compleixen els requisits.

En aquest cas, el propi model dinàmic es pot executar en qualsevol sistema de modelització matemàtica o fins i tot en forma de programa executable. L'únic requisit és la presència d'interfícies de programari per emetre dades de modelatge a l'entorn extern.

Figura 3. Connexió del projecte de verificació amb el model complex.

A la figura 4 es presenta un exemple de full de verificació de requisits bàsics. Des del punt de vista del desenvolupador, és un diagrama de càlcul convencional sobre el qual es presenta gràficament l'algorisme de verificació de requisits.

Figura 4. Full de comprovació de requisits.

Les parts principals del full de comprovació es descriuen a la figura 5. L'algorisme de comprovació es forma de manera similar als diagrames de disseny dels algorismes de control. A la part dreta hi ha un bloc per llegir senyals de la base de dades. Aquest bloc accedeix a la base de dades de senyals durant la simulació.

Els senyals rebuts s'analitzen per calcular les condicions de verificació dels requisits. En aquest cas, es realitza una anàlisi d'altitud per determinar la posició de l'aeronau (si està estacionada o en vol). Per a aquest propòsit, podeu utilitzar altres senyals i paràmetres calculats del model.

Les condicions de verificació i els paràmetres que s'estan verificant es transfereixen a blocs de verificació estàndard, en els quals s'analitzen aquests paràmetres per complir amb els requisits especificats. Els resultats es registren a la base de dades de senyals de manera que es poden utilitzar per generar automàticament una llista de verificació.

Figura 5. Estructura del full de càlcul de verificació de requisits.

Els paràmetres a provar no utilitzen necessàriament els senyals continguts a la base de dades, que estan controlats per paràmetres calculats durant el procés de simulació. Res no ens impedeix realitzar càlculs addicionals en el marc de l'esborrany de requisits, de la mateixa manera que calculem les condicions de verificació.

Per exemple, aquest requisit:

El nombre d'activacions del sistema de correcció durant el vol cap a l'objectiu no ha de ser superior a 5 i el temps total de funcionament del sistema de correcció no ha de superar els 30 segons.

En aquest cas, s'afegeix un algorisme per contrarestar el nombre d'inicis i el temps total de funcionament al diagrama de disseny dels requisits.

Bloc de verificació de requisits típics.

Cada casella de selecció de requisit estàndard està dissenyada per calcular el compliment d'un requisit d'un tipus determinat. Per exemple, els requisits ambientals inclouen un rang de temperatures ambientals de funcionament quan està estacionat i en vol. Aquest bloc ha de rebre la temperatura de l'aire al model com a paràmetre i determinar si aquest paràmetre cobreix el rang de temperatura especificat./p>

El bloc conté dos ports d'entrada, paràmetre i condició.

El primer s'alimenta amb el paràmetre que s'està comprovant. En aquest cas, "Temperatura externa".

Es subministra una variable booleana al segon port, la condició per dur a terme la comprovació.

Si es rep TRUE (1) a la segona entrada, el bloc realitza un càlcul de verificació de requisits.

Si la segona entrada rep FALSE (0), no es compleixen les condicions de prova. Això és necessari perquè es puguin tenir en compte les condicions de càlcul. En el nostre cas, aquesta entrada s'utilitza per habilitar o desactivar la comprovació en funció de l'estat del model. Si l'aeronau està a terra durant la simulació, no es comproven els requisits relacionats amb el vol, i viceversa, si l'aeronau està en vol, no es comproven els requisits relacionats amb l'operació a l'estand.

Aquesta entrada també es pot utilitzar quan es configura el model, per exemple en l'etapa inicial del càlcul. Quan el model es posa a l'estat requerit, els blocs de verificació estan desactivats, però tan bon punt el sistema arriba al mode de funcionament requerit, els blocs de verificació s'activen.

Els paràmetres d'aquest bloc són:

• condicions de límit: límits de rang superior (UpLimit) i inferior (DownLimit) que s'han de comprovar;
• temps d'exposició del sistema necessari als intervals de límit (TimeInterval) en segons;
• ID de sol·licitud ReqName;
• la permissibilitat de superar l'interval Out_range és una variable booleana que determina si un valor que supera l'interval marcat és una violació del requisit.

En alguns casos, la sortida del valor de prova indica que el sistema té algun marge i pot estar operant fora del seu rang de funcionament. En altres casos, una sortida significa que el sistema no pot mantenir els punts de consigna dins del rang.

Figura 6. Un bloc típic de verificació de propietats al diagrama i els seus paràmetres.

Com a resultat del càlcul d'aquest bloc, a la sortida es forma la variable Resultat, que pren els valors següents:

• 0 – rCap, valor no definit;
• 1 – rFet, es compleix el requisit;
• 2 – rFalla, no es compleix el requisit.

La imatge del bloc conté:

• text identificador;
• visualitzacions digitals dels paràmetres dels límits de mesura;
• identificador de color de l'estat del paràmetre.

Dins del bloc hi pot haver un circuit d'inferència lògica força complex.

Per exemple, per comprovar el rang de temperatura de funcionament de la unitat que es mostra a la figura 6, el circuit intern es mostra a la figura 7.

Figura 7. Esquema intern de la unitat de determinació del rang de temperatura.

Dins del bloc de circuits, s'utilitzen les propietats especificades als paràmetres del bloc.
A més d'analitzar el compliment dels requisits, el diagrama intern del bloc conté un gràfic necessari per visualitzar els resultats de la simulació. Aquest gràfic es pot utilitzar tant per visualitzar durant el càlcul com per analitzar els resultats després del càlcul.

Els resultats del càlcul es transmeten a la sortida del bloc i es registren simultàniament en un fitxer d'informe general, que es crea a partir dels resultats de tot el projecte. (vegeu la figura 8)

Un exemple d'informe creat a partir dels resultats de la simulació és un fitxer html creat segons un format determinat. El format es pot configurar arbitràriament amb el format acceptat per una organització concreta.

Dins del bloc de circuits, s'utilitzen les propietats especificades als paràmetres del bloc.
A més d'analitzar el compliment dels requisits, el diagrama intern del bloc conté un gràfic necessari per visualitzar els resultats de la simulació. Aquest gràfic es pot utilitzar tant per visualitzar durant el càlcul com per analitzar els resultats després del càlcul.

Els resultats del càlcul es transmeten a la sortida del bloc i es registren simultàniament en un fitxer d'informe general, que es crea a partir dels resultats de tot el projecte. (vegeu la figura 8)

Un exemple d'informe creat a partir dels resultats de la simulació és un fitxer html creat segons un format determinat. El format es pot configurar arbitràriament amb el format acceptat per una organització concreta.

Figura 8. Exemple d'un fitxer d'informe basat en els resultats de la simulació.

En aquest exemple, el formulari d'informe es configura directament a les propietats del projecte i el format de la taula s'estableix com a senyals globals del projecte. En aquest cas, el mateix SimInTech resol el problema de configurar l'informe, i el bloc per escriure resultats en un fitxer utilitza aquestes línies per escriure al fitxer d'informe.

Figura 9. Configuració del format d'informe en senyals globals del projecte

Ús d'una base de dades de senyals per als requisits.

Per automatitzar el treball amb la configuració de propietats, es crea una estructura estàndard a la base de dades de senyals per a cada bloc típic. (vegeu la figura 10)

Figura 10. Exemple de l'estructura d'un bloc de verificació de requisits en una base de dades de senyals.

La base de dades de senyal ofereix:

• Emmagatzemar tots els paràmetres necessaris dels requisits del sistema.
• Visualització còmoda dels requisits del projecte existents a partir dels paràmetres especificats i dels resultats actuals del modelatge.
• Configuració d'un bloc o d'un grup de blocs mitjançant un llenguatge de programació d'scripts. Els canvis a la base de dades de senyals provoquen canvis en els valors de propietat del bloc del diagrama.
• Emmagatzemar descripcions de text, enllaços a elements d'especificacions tècniques o identificadors al sistema de gestió de requisits.

Les estructures de bases de dades de senyals per als requisits es poden configurar fàcilment per treballar amb un sistema de gestió de requisits de tercers. A la figura 11 es presenta un diagrama general d'interacció amb els sistemes de gestió de requisits.

Figura 11. Diagrama d'interacció amb el sistema de gestió de requisits.

La seqüència d'interacció entre el projecte de prova SimInTech i el sistema de control de requisits és la següent:

1. Els termes de referència es desglossen en requisits.
2. S'identifiquen els requisits de les especificacions tècniques que es poden verificar mitjançant modelització matemàtica de processos tècnics.
3. Els atributs dels requisits seleccionats es transfereixen a la base de dades de senyal SimInTech en l'estructura de blocs estàndard (per exemple, temperatura màxima i mínima).
4. Durant el procés de càlcul, les dades de l'estructura es transfereixen a diagrames de disseny de blocs, es realitza l'anàlisi i els resultats s'emmagatzemen en una base de dades de senyals.
5. Un cop finalitzat el càlcul, els resultats de l'anàlisi es transfereixen al sistema de gestió de requisits.

Els passos del 3 al 5 dels requisits es poden repetir durant el procés de disseny quan es produeixen canvis en el disseny i/o els requisits i s'ha de tornar a provar l'impacte dels canvis.

Conclusions.

• El prototip creat del sistema proporciona una reducció important del temps d'anàlisi dels models existents per al compliment dels requisits de les especificacions tècniques.
• La tecnologia de prova proposada utilitza models dinàmics ja existents i es pot utilitzar fins i tot per a qualsevol model dinàmic, inclosos els que no es realitzen a l'entorn SimInTech.
• L'ús de l'organització de dades per lots us permet crear paquets de verificació de requisits en paral·lel amb el desenvolupament de models, o fins i tot utilitzar aquests paquets com a especificacions tècniques per al desenvolupament de models.
• La tecnologia es pot integrar amb els sistemes de gestió de requisits existents sense costos significatius.

Per als que llegiu fins al final, enllaç a un vídeo que mostra com funciona el prototip.

Font: www.habr.com