Verificarea automată a cerințelor din specificația tehnică în timpul modelării dinamice.

Continuând tema „Care sunt dovezile dumneavoastră?”, să privim problema modelării matematice dintr-o altă perspectivă. După ce ne-am asigurat că modelul corespunde adevărului esențial al vieții, putem răspunde la întrebarea principală: „ce avem de fapt aici?”. Când creăm un model pentru un obiect tehnic, în general, dorim să ne asigurăm că acest obiect va corespunde așteptărilor noastre. Aceasta este motivul pentru care se efectuează calcule dinamice ale proceselor, iar rezultatul este comparat cu cerințele. Aceasta este un dublu digital, un prototip virtual și alte lucruri de acest fel, care în etapa de proiectare rezolvă sarcina de a ne asigura că obținem ceea ce ne-am planificat.

Cum putem să ne asigurăm rapid că sistemul nostru este exact ceea ce proiectăm, va zbura sau va înota construcția noastră? Și dacă va zbura, cât de sus? Dar dacă va înota, cât de adânc?

În acest articol se discută despre automatizarea verificării conformității cerințelor tehnice ale unei construcții prin crearea de modele dinamice ale sistemelor tehnice. Ca exemplu, să analizăm un element din cerințele tehnice pentru sistemul de răcire prin aer al unei aeronave.

Considerăm acele cerințe care pot fi exprimate numeric și verificate matematic pe baza unui model de calcul concret. Este evident că aceasta este doar o parte din cerințele generale pentru orice sistem tehnic, dar exact la verificarea lor ne petrecem timpul, nervii și banii pentru crearea de modele dinamice ale obiectului.

Atunci când descriem cerințele tehnice sub formă de document, putem distinge mai multe tipuri diferite de cerințe, fiecare dintre care necesită abordări diferite pentru formarea unui control automat de conformitate.

De exemplu, să luăm în considerare un set mic, dar real de cerințe:

1. Temperatura aerului atmosferic la intrarea în SVO:
   la sol - între minus 35 și 35 ºC,
   în zbor - între minus 35 și 39 ºC.
2. Presiunea statică a aerului atmosferic în zbor - între 700 și 1013 GPa (între 526 și 760 mm Hg).
3. Presiunea totală a aerului la intrarea în admisia SVO în zbor - între 754 și 1200 GPa (între 566 și 1050 mm Hg).
4. Temperatura aerului de răcire:
   la sol - nu mai mult de 27 ºC, pentru blocurile tehnice - nu mai mult de 29 ºC,
   în zbor − nu mai mult de 25 ºC, pentru unitățile tehnice − nu mai mult de 27 ºC.
5. Consum de aer de răcire:
   pe staționare − nu mai puțin de 708 kg/h,
   în zbor − nu mai puțin de 660 kg/h.
6. Temperatura aerului în compartimentele instrumentelor − nu mai mult de 60 ºC.
7. Cantitatea de umiditate fin dispersată în aerul de răcire − nu mai mult de 2 g/kg aer uscat.

Chiar și cu un set atât de limitat de cerințe, se pot distinge cel puțin două categorii care trebuie tratate diferit în sistem:

• cerințele condițiilor de operare a sistemului (p. 1-3);
• cerințele parametrice pentru sistem (p. 3-7).

Cerințele condițiilor de operare a sistemului
Condițiile externe pentru sistemul dezvoltat în modelare pot fi definite fie ca condiții limită, fie ca rezultat al funcționării sistemului general.
În modelarea dinamică, trebuie să ne asigurăm că modurile de operare specificate sunt acoperite de procesul de modelare.

Cerințele parametrice pentru sistem
Aceste cerințe reprezintă parametrii asigurați de sistemul însuși. În procesul de modelare, putem obține acești parametri ca rezultate ale calculului și ne putem asigura că cerințele sunt îndeplinite în fiecare calcul specific.

Identificarea și codificarea cerințelor

Pentru a facilita lucrul cu cerințele, standardele existente recomandă atribuirea unui identificator fiecărei cerințe. La atribuirea identificatorilor, este foarte de dorit să se utilizeze un sistem unic de codificare.

Codul cerinței poate fi pur și simplu un număr care reflectă ordinea cerinței, sau poate conține un cod pentru tipul cerinței, codul sistemului sau unității la care se aplică, codul parametrului, codul locației și multe altele ce pot fi imaginabile de către inginer. (pentru un exemplu de utilizare a codificării, vezi articolul)

În tabelul 1 este prezentat un exemplu simplu de codificare a cerințelor.

1. cod sursă al cerinței R- cerințele din FI;
2. cod tip cerințe E – cerințe – parametrii mediului extern sau condiții de operare
   S — cerințe asigurate de sistem;
3. codul stării avionului 0 – orice, G – staționar, F – în zbor;
4. codul tipului de parametri fizici T – temperatură, P – presiune, G – flux, umiditate H;
5. numărul ordinii cerinței.

Proiectul sistemului de verificare a cerințelor.

Pentru fiecare cerință de calcul există un algoritm de evaluare a conformității parametrilor calculați cu parametrii specificați în cerință. În linii mari, orice sistem de control conține întotdeauna algoritmi de verificare a cerințelor, pur și simplu prin definiție. Chiar și orice regulator le conține. Dacă temperatura depășește limitele, se pornește aerul condiționat. Astfel, prima etapă a oricărei reglări este verificarea conformității parametrilor cu cerințele.

Și, având în vedere că verificarea este un algoritm, se pot folosi aceleași resurse și instrumente pe care le folosim pentru a crea programe de control. De exemplu, mediu SimInTech permite crearea de pachete de proiecte care conțin diverse părți ale modelului, realizate sub formă de proiecte separate (modelul obiectului, modelul sistemului de control, modelul mediului etc.).

Proiectul de verificare a cerințelor devine astfel un proiect similar de algoritmi și se conectează la pachetul modelului. Și, în modul de modelare dinamică, efectuează analiza conformității cerințelor din specificații.

Un posibil exemplu de prezentare a proiectului sistemului este ilustrat în figura 1.

Figura 1. Exemplu de prezentare a proiectului de verificare.

La fel ca pentru algoritmii de control, cerințele pot fi exprimate sub forma unui set de foi. Pentru a facilita lucrul cu algoritmii în medii de modelare structurală, cum ar fi SimInTech, Simulink, AmeSim, se utilizează capacitățile de creare a structurilor multi-nivel în formă de submodele. Această organizare permite gruparea diferitelor cerințe în seturi pentru a simplifica lucrul cu un ansamblu de cerințe, așa cum se face pentru algoritmii de control (vezi figura 2).

Figura 2. Structura ierarhică a modelului de verificare a cerințelor.

De exemplu, în cazul analizat, au fost identificate două grupuri: cerințe pentru mediu și cerințe direct pentru sistem. Prin urmare, se utilizează o structură de date bidimensională: două grupuri, fiecare dintre ele fiind o foaie a algoritmului.

Pentru conectarea datelor la model se folosește o schemă standard de formare a bazei de date a semnalelor, în care sunt stocate datele pentru schimbul între părțile proiectului.

La crearea și testarea software-ului, în această bază sunt introduse măsurătorile senzorilor (analogii senzorilor reale din sistem), care sunt utilizate de sistemul de control.
Pentru proiectul de testare, în aceeași bază de date pot fi salvate orice parametrii calculați în modelul dinamic, și astfel pot fi utilizați pentru verificarea îndeplinirii cerințelor.

Modelul dinamic în acest caz poate fi realizat în orice sistem de modelare matematică sau chiar sub forma unui program executabil. Singura cerință este existența interfețelor software pentru livrarea datelor de simulare în mediul extern.

Figura 3. Conectarea proiectului de verificare la modelul complex.

Un exemplu de foaie de bază pentru verificarea cerințelor este prezentat în figura 4. Din perspectiva dezvoltatorului, aceasta reprezintă o schemă de calcul obișnuită, în care algoritmul de verificare a cerințelor este prezentat grafic.

Figura 4. Foia de verificare a cerințelor.

Părțile principale ale foii de verificare sunt descrise în figura 5. Algoritmul de verificare este format similar schemelor de calcul ale algoritmilor de control. În partea dreaptă se află un bloc care citește semnalele din baza de date. În acest bloc se face apel la baza de date a semnalelor în timpul modelării.

Semnalele primite sunt analizate pentru a determina condițiile de verificare a cerințelor. În cazul analizat, se efectuează o evaluare a altitudinii pentru a determina poziția avionului (dacă se află pe pistă sau în zbor). Pentru acest scop, pot fi utilizate și alte semnale și parametrii calculați ai modelului.

Condițiile de verificare și parametrii verificați sunt transmise către modulele de verificare standardizate, unde se efectuează analiza acestor date în raport cu cerințele stabilite. Rezultatele sunt înregistrate în baza de date a semnalelor astfel încât să poată fi utilizate pentru formarea automată a unui checklist.

Figura 5. Structura foii de calcul pentru verificarea cerințelor.

Ca parametri verificați, nu este obligatoriu să se folosească semnalele din baza de date, care sunt gestionate de parametrii calculați în timpul modelării. Nimic nu împiedică, în cadrul proiectului cerințelor, realizarea de calcule suplimentare, la fel cum calculăm condițiile de verificare.

De exemplu, o astfel de cerință:

Numărul de activări ale sistemului de corectare în timpul zborului către obiectiv nu trebuie să depășească 5, iar timpul total de funcționare a sistemului de corectare nu trebuie să depășească 30 de secunde.

În acest caz, în schema de calcul a proiectului cerințelor se adaugă un algoritm pentru numărarea activărilor și a timpului total de funcționare.

Modulul standard de verificare a cerințelor.

Fiecare modul standard de verificare a cerințelor este destinat să calculeze îndeplinirea cerinței unui anumit tip. De exemplu, în cerințele ambientale este prezent un interval de temperaturi de lucru ale aerului ambiental atât pe pistă, cât și în zbor. Acest modul trebuie să primească ca parametru temperatura aerului din model și să determine dacă acest parametru acoperă intervalul de temperaturi specificat.

Modulul conține două porturi de intrare, param și condition.

La primul port este furnizat parametrul verificat. În acest caz, „Temperatura mediului extern”.

La al doilea port este furnizată o variabilă booleană – condiția de îndeplinire a verificării.

Dacă la a doua intrare vine TRUE (1), atunci modulul efectuează calculul verificării cerinței.

Dacă la a doua intrare se primește FALSE (0), atunci condițiile de control nu sunt îndeplinite. Acest lucru este necesar pentru a putea lua în considerare condițiile de calcul. În cazul nostru, această intrare este utilizată pentru a activa sau dezactiva controlul în funcție de starea modelului. Dacă aeronava este pe teren în timpul modelării, cerințele legate de zbor nu sunt verificate, și invers - dacă aeronava este în zbor, cerințele legate de activitatea la sol nu sunt verificate.

Această intrare poate fi folosită și în timpul configurării modelului, de exemplu, în etapa inițială a calculului. Atunci când modelul este adus în starea dorită, blocurile de control sunt dezactivate, dar de îndată ce sistemul ajunge în regimul de funcționare dorit, blocurile de control sunt activate.

Ca parametri ai acestui bloc se stabilesc:

• condițiile limită: limitele superioare (UpLimit) și inferioare (DownLimit) ale intervalelor care trebuie verificate;
• timpul necesar de așteptare al sistemului la limitele de limită (TimeInterval) în secunde;
• identificatorul cerinței ReqName;
• posibilitatea de a depăși intervalul Out_range – o variabilă booleană care determină dacă depășirea limitei este considerată o încălcare a cerinței.

În unele cazuri, ieșirea valorii verificate indică că sistemul are un rezervor și poate funcționa dincolo de intervalul de lucru. În alte cazuri, ieșirea indică că sistemul nu reușește să mențină parametrii specificați în cadrul intervalului.

Figura 6. Blocul tipic de control al proprietăți pe schemă și parametrii săi.

Ca urmare a calculului acestui bloc, se generează o variabilă Result, care poate lua următoarele valori:

• 0 – rNone, valoare nedefinită;
• 1 – rDone, cerința este îndeplinită;
• 2 – rFault, cerința nu este îndeplinită.

Imaginea blocului conține:

• textul identificatorului;
• afișări numerice ale parametrilor limitelor de măsurare;
• identificatorul de culoare al stării parametrului.

În interiorul blocului ar putea exista o schemă logică destul de complexă.

De exemplu, pentru a verifica intervalul de lucru al temperaturilor blocului prezentat în figura 6, schema internă este prezentată în figura 7.

Figura 7. Schema internă a blocului de determinare a intervalului de temperatură.

În interiorul blocului, schemele folosesc proprietăți stabilite în parametrii blocului.
Pe lângă analiza conformității cerințelor, schema internă a blocului conține un grafic necesar pentru a reda rezultatele simulării. Acest grafic poate fi folosit atât pentru vizualizare în timpul calculului, cât și pentru analiza rezultatelor după calcul.

Rezultatele calculelor sunt transmise la ieșirea blocului și în același timp sunt înregistrate într-un fișier comun de raport, care este creat pe baza rezultatelor întregului proiect. (vezi figura 8)

Exemplul unui raport creat pe baza rezultatelor simulării este un fișier html, generat conform unui format specificat. Formatul poate fi personalizat în mod liber după standardele acceptate de organizație.

În interiorul blocului, schemele folosesc proprietăți stabilite în parametrii blocului.
Pe lângă analiza conformității cerințelor, schema internă a blocului conține un grafic necesar pentru a reda rezultatele simulării. Acest grafic poate fi folosit atât pentru vizualizare în timpul calculului, cât și pentru analiza rezultatelor după calcul.

Rezultatele calculelor sunt transmise la ieșirea blocului și în același timp sunt înregistrate într-un fișier comun de raport, care este creat pe baza rezultatelor întregului proiect. (vezi figura 8)

Exemplul unui raport creat pe baza rezultatelor simulării este un fișier html, generat conform unui format specificat. Formatul poate fi personalizat în mod liber după standardele acceptate de organizație.

Figura 8. Exemplu de fișier de raport pe baza rezultatelor simulării.

În acest exemplu, configurarea formei raportului se efectuează direct în proprietățile proiectului, iar formatul din tabel este definit ca semnale globale ale proiectului. În acest caz, SimInTech rezolvă singur problema configurării raportului, iar blocul de înregistrare a rezultatelor în fișier folosește aceste linii pentru a scrie în fișierul de raport.

Figura 9. Configurarea formatului raportului în semnalele globale ale proiectului.

Utilizarea bazei de date a semnalelor pentru cerințe.

Pentru automatizarea lucrului cu setările proprietăților pentru fiecare bloc tipic, se creează o structură tipică în baza de date a semnalelor. (vezi figura 10)

Figura 10. Exemplu de structură a blocului de verificare a cerinței în baza de date a semnalelor.

Baza de date a semnalelor asigură:

• Stocarea tuturor parametrilor necesari cerințelor sistemului.
• Vizualizarea convenabilă a cerințelor existente în proiect din parametrii specificați și rezultatele curente ale simulării.
• Configurarea unui bloc, a unui grup de blocuri folosind un limbaj de programare script. Modificările din baza de date a semnalelor conduc la schimbarea valorilor proprietăților blocului în schematică.
• Stocarea descrierilor textuale, a legăturilor către punctele din TDR sau a identificatorilor în sistemul de management al cerințelor.

Structurile bazei de date a semnalelor pentru cerințe pot fi ușor configurate pentru a funcționa cu un sistem extern de management al cerințelor. Schema generală de interacțiune cu sistemele de management al cerințelor este prezentată în figura 11.

Figura 11. Schema de interacțiune cu sistemul de management al cerințelor.

Secvența de interacțiune a proiectului de testare SimInTech cu sistemul de gestionare a cerințelor este următoarea:

1. Specificațiile tehnice sunt împărțite în cerințe.
2. Se evidențiază cerințele din specificațiile tehnice care pot fi verificate prin modelarea matematică a proceselor tehnice.
3. Attributele cerințelor evidențiate sunt transmise în baza de date a semnalelor SimInTech în structuri de blocuri tipizate (de exemplu, temperatura maximă și minimă).
4. În timpul calculului, datele structurilor sunt transmise în schemele de calcul ale blocurilor, se efectuează analiza, iar rezultatele sunt salvate în baza de date a semnalelor.
5. După finalizarea calculului, rezultatele analizei sunt transmise sistemului de gestionare a cerințelor.

Etapele de lucru cu cerințele 3 - 5 pot fi repetate în timpul procesului de proiectare, când au loc modificări în construcție și/sau cerințe, și, prin urmare, este necesară o verificare ulterioară a impactului modificărilor efectuate.

Concluzii.

• Prototipul creat al sistemului asigură o reducere semnificativă a timpului de analiză a modelelor existente, în ceea ce privește conformitatea cu cerințele specificației tehnice.
• Tehnologia de testare propusă utilizează deja modele dinamice existente și poate fi utilizată chiar și pentru orice modele dinamice, inclusiv cele realizate în afara mediului SimInTech.
• Utilizarea organizării batch a datelor permite crearea de pachete de verificare a cerințelor, simultan cu dezvoltarea modelelor, sau chiar utilizarea acestor pachete ca specificație tehnică pentru dezvoltarea modelelor.
• Tehnologia poate fi integrată fără costuri semnificative în sistemele existente de gestionare a cerințelor.

Pentru cei care au citit până la capăt, linkul către video-demo cu funcționarea prototipului.

Sursa: habr.com