Verificarea automată a cerințelor TOR în procesul de simulare dinamică

Continuând tema — Care este dovada ta?, să privim problema modelării matematice din cealaltă parte. După ce suntem convinși că modelul corespunde adevărului casnic al vieții, putem răspunde la întrebarea principală: „Ce, mai exact, avem aici?” Când creăm un model al unui obiect tehnic, de obicei dorim să ne asigurăm că acest obiect va satisface așteptările noastre. În acest scop, se efectuează calcule dinamice ale proceselor, iar rezultatul este comparat cu cerințele. Acesta este un geamăn digital, un prototip virtual etc. băieți la modă care, în faza de proiectare, rezolvă problema cum să ne asigurăm că obținem ceea ce ne-am planificat.

Cum ne putem asigura rapid că sistemul nostru este exact ceea ce proiectăm, va zbura sau va pluti designul nostru? Și dacă zboară, cât de sus? Și dacă plutește, cât de adânc?

Acest articol discută despre automatizarea verificării conformității cu cerințele unei clădiri tehnice atunci când se creează modele dinamice ale sistemelor tehnice. De exemplu, să ne uităm la un element al specificației tehnice pentru un sistem de răcire cu aer a aeronavei.

Considerăm acele cerințe care pot fi exprimate numeric și verificate matematic pe baza unui model de calcul specific. Este clar că aceasta este doar o parte din cerințele generale pentru orice sistem tehnic, dar tocmai pentru verificarea acestora cheltuim timp, nervi și bani pentru a crea modele dinamice ale obiectului.

Când se descriu cerințele tehnice sub forma unui document, se pot distinge mai multe tipuri de cerințe diferite, fiecare dintre acestea necesită abordări diferite pentru formarea verificării automate a îndeplinirii cerințelor.

De exemplu, luați în considerare acest set mic, dar realist de cerințe:

1. Temperatura aerului atmosferic la intrarea în sistemul de tratare a apei:
   în parcare - de la minus 35 la 35 ºС,
   în zbor - de la minus 35 la 39 ºС.
2. Presiunea statică a aerului atmosferic în zbor este de la 700 la 1013 GPa (de la 526 la 760 mm Hg).
3. Presiunea totală a aerului la intrarea în admisia de aer SVO în zbor este de la 754 la 1200 GPa (de la 566 la 1050 mm Hg).
4. Temperatura aerului de racire:
   în parcare - nu mai mult de 27 ºС, pentru blocurile tehnice - nu mai mult de 29 ºС,
   în zbor - nu mai mult de 25 ºС, pentru blocuri tehnice - nu mai mult de 27 ºС.
5. Debitul de aer de răcire:
   când este parcat - cel puțin 708 kg/h,
   în zbor - nu mai puțin de 660 kg/h.
6. Temperatura aerului din compartimentele instrumentelor nu depășește 60 °С.
7. Cantitatea de umiditate fină liberă în aerul de răcire nu este mai mare de 2 g/kg de aer uscat.

Chiar și în cadrul acestui set limitat de cerințe, există cel puțin două categorii care trebuie tratate diferit în sistem:

• cerințe pentru condițiile de funcționare ale sistemului (clauzele 1-3);
• cerințe parametrice pentru sistem (clauzele 3-7).

Condițiile de funcționare ale sistemului
Condițiile externe pentru sistemul dezvoltat în timpul modelării pot fi specificate ca condiții la limită sau ca rezultat al funcționării sistemului general.
În simularea dinamică, este necesar să se asigure că condițiile de operare specificate sunt acoperite de procesul de simulare.

Cerințe de sistem parametrice
Aceste cerințe sunt parametri furnizați de sistemul însuși. În timpul procesului de modelare, putem obține acești parametri ca rezultate de calcul și ne asigurăm că cerințele sunt îndeplinite în fiecare calcul specific.

Identificarea și codificarea cerințelor

Pentru ușurința lucrului cu cerințele, standardele existente recomandă alocarea unui identificator fiecărei cerințe. Când se atribuie identificatori, este foarte de dorit să se utilizeze un sistem de codificare unificat.

Codul de cerință poate fi pur și simplu un număr care reprezintă numărul de comandă al cerinței sau poate conține un cod pentru tipul de cerință, un cod pentru sistemul sau unitatea căreia i se aplică, un cod de parametru, un cod de locație și orice altceva isi poate imagina inginerul. (vezi articolul pentru utilizarea codificării)

Tabelul 1 oferă un exemplu simplu de codificare a cerințelor.

1. codul sursei cerințelor R-cerințe TK;
2. cod tip de cerințe E - cerințe - parametri de mediu, sau condiții de funcționare
   S - cerinţele furnizate de sistem;
3. codul de stare a aeronavei 0 – oricare, G – parcat, F – în zbor;
4. cod tip parametru fizic T – temperatura, P – presiune, G – debit, umiditate H;
5. numărul de serie al cerinței.

ID Cerințe	descriere	Parametru
REGT01	Temperatura aerului ambiental la intrarea în sistemul de răcire cu apă: în parcare - de la minus 35ºС. până la 35 ºС.
REFT01	Temperatura aerului atmosferic la intrarea în sistemul de apărare antiaeriană: în zbor - de la minus 35 ºС la 39 ºС.
REFP01	Presiunea statică a aerului atmosferic în zbor este de la 700 la 1013 hPa (de la 526 la 760 mm Hg).
REFP02	Presiunea totală a aerului la intrarea în priza de aer SVO în zbor este de la 754 la 1200 hPa (de la 566 la 1050 mm Hg).
RSGT01	Temperatura aerului de răcire: atunci când este parcat nu mai mult de 27 ºС
RSGT02	Temperatura aerului de răcire: în parcare, pentru unitățile tehnice nu mai mult de 29 ºС
RSFT01	Temperatura aerului de răcire în zbor nu mai mult de 25 ºС
RSFT02	Temperatura aerului de răcire: în zbor, pentru unitățile tehnice nu mai mult de 27 ºС
RSGG01	Debitul de aer de răcire: la parcare nu mai puțin de 708 kg/h
RSFG01	Debit de aer de răcire: în zbor nu mai puțin de 660 kg/h
RS0T01	Temperatura aerului în compartimentele instrumentelor nu mai mult de 60 ºС
RSH01	Cantitatea de umiditate fină liberă în aerul de răcire nu este mai mare de 2 g/kg de aer uscat

Proiectarea sistemului de verificare a cerințelor.

Pentru fiecare cerință de proiectare există un algoritm de evaluare a corespondenței parametrilor de proiectare și a parametrilor specificați în cerință. În general, orice sistem de control conține întotdeauna algoritmi pentru verificarea cerințelor pur și simplu implicit. Și chiar și orice regulator le conține. Dacă temperatura depășește limitele, aparatul de aer condiționat se pornește. Astfel, prima etapă a oricărei reglementări este verificarea dacă parametrii îndeplinesc cerințele.

Și deoarece verificarea este un algoritm, atunci putem folosi aceleași instrumente și instrumente pe care le folosim pentru a crea programe de control. De exemplu, mediul SimInTech vă permite să creați pachete de proiecte care conțin diverse părți ale modelului, executate sub formă de proiecte separate (model de obiect, model de sistem de control, model de mediu etc.).

Proiectul de verificare a cerințelor în acest caz devine același proiect de algoritm și este conectat la pachetul model. Și în modul de modelare dinamică efectuează o analiză pentru conformitatea cu cerințele specificațiilor tehnice.

Un exemplu posibil de proiectare a unui sistem este prezentat în Figura 1.

Figura 1. Exemplu de proiectare a unui proiect de verificare.

La fel ca pentru algoritmii de control, cerințele pot fi întocmite ca un set de foi. Pentru confortul lucrului cu algoritmi în medii de modelare structurală, cum ar fi SimInTech, Simulink, AmeSim, este utilizată capacitatea de a crea structuri pe mai multe niveluri sub formă de submodele. Această organizare face posibilă gruparea diferitelor cerințe în seturi pentru a simplifica lucrul cu o serie de cerințe, așa cum se face pentru algoritmii de control (vezi Fig. 2).

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

De exemplu, în cazul în cauză, se disting două grupuri: cerințe pentru mediu și cerințe direct pentru sistem. Prin urmare, se utilizează o structură de date pe două niveluri: două grupuri, fiecare dintre acestea fiind o frunză a algoritmului.

Pentru a conecta datele la model, se utilizează o schemă standard pentru generarea unei baze de date de semnal, care stochează date pentru schimbul între părți ale proiectului.

La crearea și testarea software-ului, citirile senzorilor (analogii senzorilor de sistem reali) care sunt utilizați de sistemul de control sunt plasate în această bază de date.
Pentru un proiect de testare, orice parametri calculați în modelul dinamic pot fi stocați în aceeași bază de date și astfel utilizați pentru a verifica dacă cerințele sunt îndeplinite.

În acest caz, modelul dinamic în sine poate fi executat în orice sistem de modelare matematică sau chiar sub forma unui program executabil. Singura cerință este prezența interfețelor software pentru emiterea datelor de modelare către mediul extern.

Figura 3. Conectarea proiectului de verificare la modelul complex.

Un exemplu de fișă de verificare a cerințelor de bază este prezentat în Figura 4. Din punctul de vedere al dezvoltatorului, este o diagramă de calcul convențională pe care este prezentat grafic algoritmul de verificare a cerințelor.

Figura 4. Fișa de verificare a cerințelor.

Principalele părți ale foii de verificare sunt descrise în Figura 5. Algoritmul de verificare este format în mod similar cu diagramele de proiectare ale algoritmilor de control. În partea dreaptă există un bloc pentru citirea semnalelor din baza de date. Acest bloc accesează baza de date de semnal în timpul simulării.

Semnalele primite sunt analizate pentru a calcula condițiile de verificare a cerințelor. În acest caz, se efectuează analiza altitudinii pentru a determina poziția aeronavei (dacă este parcata sau în zbor). În acest scop, puteți utiliza alte semnale și parametri calculați ai modelului.

Condițiile de verificare și parametrii verificați sunt transferați în blocuri standard de verificare, în care acești parametri sunt analizați pentru conformitatea cu cerințele specificate. Rezultatele sunt înregistrate în baza de date de semnale astfel încât să poată fi folosite pentru a genera automat o listă de verificare.

Figura 5. Structura fișei de calcul de verificare a cerințelor.

Parametrii de testat nu folosesc neapărat semnale conținute în baza de date, care sunt controlate de parametrii calculați în timpul procesului de simulare. Nimic nu ne împiedică să efectuăm calcule suplimentare în cadrul proiectului de cerințe, așa cum calculăm condițiile de verificare.

De exemplu, această cerință:

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

În acest caz, la diagrama de proiectare a cerințelor se adaugă un algoritm pentru contracararea numărului de porniri și a timpului total de funcționare.

Bloc de verificare a cerințelor tipice.

Fiecare casetă de selectare a cerințelor standard este concepută pentru a calcula îndeplinirea unei cerințe de un anumit tip. De exemplu, cerințele de mediu includ o gamă de temperaturi ambientale de funcționare atunci când sunt parcate și în zbor. Acest bloc trebuie să primească temperatura aerului din model ca parametru și să determine dacă acest parametru acoperă intervalul de temperatură specificat./p>

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

Primul este alimentat cu parametrul verificat. În acest caz, „Temperatura exterioară”.

O variabilă booleană este furnizată celui de-al doilea port - condiția pentru efectuarea verificării.

Dacă TRUE (1) este primit la a doua intrare, atunci blocul efectuează un calcul de verificare a cerinței.

Dacă a doua intrare primește FALSE (0), atunci condițiile de testare nu sunt îndeplinite. Acest lucru este necesar pentru a putea fi luate în considerare condițiile de calcul. În cazul nostru, această intrare este folosită pentru a activa sau dezactiva verificarea în funcție de starea modelului. Dacă aeronava se află la sol în timpul simulării, atunci cerințele legate de zbor nu sunt verificate și invers - dacă aeronava este în zbor, atunci cerințele legate de funcționarea la stand nu sunt verificate.

Această intrare poate fi utilizată și la configurarea modelului, de exemplu în etapa inițială a calculului. Când modelul este adus în starea necesară, blocurile de verificare sunt dezactivate, dar de îndată ce sistemul ajunge la modul de operare necesar, blocurile de verificare sunt pornite.

Parametrii acestui bloc sunt:

• condiții de limită: limitele superioare (UpLimit) și inferioare (DownLimit) care trebuie verificate;
• timpul necesar de expunere a sistemului la intervalele limită (TimeInterval) în secunde;
• ID cerere ReqName;
• permisibilitatea depășirii intervalului Out_range este o variabilă booleană care determină dacă o valoare care depășește intervalul verificat este o încălcare a cerinței.

În unele cazuri, rezultatul valorii de testare indică faptul că sistemul are o anumită marjă și poate funcționa în afara intervalului său de funcționare. În alte cazuri, o ieșire înseamnă că sistemul nu poate menține valorile de referință în interval.

Figura 6. Un bloc tipic de verificare a proprietăților din diagramă și parametrii săi.

Ca rezultat al calculului acestui bloc, la ieșire se formează variabila Rezultat, care ia următoarele valori:

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

Imaginea blocului conține:

• text de identificare;
• afișaj digital al parametrilor limitelor de măsurare;
• identificatorul de culoare al stării parametrului.

În interiorul blocului poate exista un circuit de inferență logic destul de complex.

De exemplu, pentru a verifica intervalul de temperatură de funcționare a unității prezentat în Figura 6, circuitul intern este prezentat în Figura 7.

Figura 7. Diagrama internă a unității de determinare a intervalului de temperatură.

În interiorul blocului de circuit, sunt utilizate proprietățile specificate în parametrii blocului.
Pe lângă analiza conformității cu cerințele, diagrama internă a blocului conține un grafic necesar pentru afișarea rezultatelor simulării. Acest grafic poate fi folosit atât pentru vizualizarea în timpul calculului, cât și pentru analiza rezultatelor după calcul.

Rezultatele calculului sunt transmise la ieșirea blocului și sunt înregistrate simultan într-un fișier de raport general, care este creat pe baza rezultatelor pentru întregul proiect. (vezi Fig. 8)

Un exemplu de raport creat pe baza rezultatelor simulării este un fișier html creat după un format dat. Formatul poate fi configurat în mod arbitrar la formatul acceptat de o anumită organizație.

În interiorul blocului de circuit, sunt utilizate proprietățile specificate în parametrii blocului.
Pe lângă analiza conformității cu cerințele, diagrama internă a blocului conține un grafic necesar pentru afișarea rezultatelor simulării. Acest grafic poate fi folosit atât pentru vizualizarea în timpul calculului, cât și pentru analiza rezultatelor după calcul.

Rezultatele calculului sunt transmise la ieșirea blocului și sunt înregistrate simultan într-un fișier de raport general, care este creat pe baza rezultatelor pentru întregul proiect. (vezi Fig. 8)

Un exemplu de raport creat pe baza rezultatelor simulării este un fișier html creat după un format dat. Formatul poate fi configurat în mod arbitrar la formatul acceptat de o anumită organizație.

Figura 8. Exemplu de fișier de raport bazat pe rezultatele simulării.

În acest exemplu, formularul de raport este configurat direct în proprietățile proiectului, iar formatul din tabel este setat ca semnale globale ale proiectului. În acest caz, SimInTech însuși rezolvă problema setării raportului, iar blocul pentru scrierea rezultatelor într-un fișier folosește aceste linii pentru a scrie în fișierul raport.

Figura 9. Setarea formatului de raport în semnalele globale ale proiectului

Utilizarea unei baze de date de semnal pentru cerințe.

Pentru a automatiza lucrul cu setările proprietăților, o structură standard este creată în baza de date de semnal pentru fiecare bloc tipic. (vezi Fig. 10)

Figura 10. Exemplu de structură a unui bloc de verificare a cerințelor într-o bază de date de semnal.

Baza de date de semnal oferă:

• Stocarea tuturor parametrilor necesari cerințelor sistemului.
• Vizualizarea convenabilă a cerințelor existente ale proiectului din parametrii specificați și rezultatele actuale ale modelării.
• Configurarea unui bloc sau a unui grup de blocuri folosind un limbaj de programare de scripting. Modificările în baza de date de semnal duc la modificări ale valorilor proprietăților blocului din diagramă.
• Stocarea descrierilor de text, a link-urilor către articole din specificațiile tehnice sau a identificatorilor în sistemul de management al cerințelor.

Structurile bazei de date de semnal pentru cerințe pot fi ușor configurate pentru a funcționa cu un sistem de management al cerințelor terță parte.O diagramă generală a interacțiunii cu sistemele de management al cerințelor este prezentată în Figura 11.

Figura 11. Diagrama interacțiunii cu sistemul de management al cerințelor.

Secvența interacțiunii dintre proiectul de testare SimInTech și sistemul de control al cerințelor este următoarea:

1. Termenii de referință sunt împărțiți în cerințe.
2. Sunt identificate cerințele specificațiilor tehnice care pot fi verificate prin modelarea matematică a proceselor tehnice.
3. Atributele cerințelor selectate sunt transferate în baza de date de semnal SimInTech în structura blocurilor standard (de exemplu, temperatura maximă și minimă).
4. În timpul procesului de calcul, datele de structură sunt transferate în diagrame de proiectare bloc, se efectuează analiza și rezultatele sunt stocate într-o bază de date de semnal.
5. Odată ce calculul este finalizat, rezultatele analizei sunt transferate în sistemul de management al cerințelor.

Cerințele pașii de la 3 la 5 pot fi repeți în timpul procesului de proiectare atunci când apar modificări ale proiectării și/sau cerințelor și impactul modificărilor trebuie retestat.

Concluzii.

• Prototipul creat al sistemului asigură o reducere semnificativă a timpului de analiză a modelelor existente pentru conformitatea cu cerințele specificațiilor tehnice.
• Tehnologia de testare propusă utilizează modele dinamice deja existente și poate fi utilizată chiar și pentru orice modele dinamice, inclusiv pentru cele care nu sunt efectuate în mediul SimInTech.
• Utilizarea organizării datelor pe lot vă permite să creați pachete de verificare a cerințelor în paralel cu dezvoltarea modelului sau chiar să utilizați aceste pachete ca specificații tehnice pentru dezvoltarea modelului.
• Tehnologia poate fi integrată cu sistemele existente de management al cerințelor fără costuri semnificative.

Pentru cei care citesc până la capăt, link către un videoclip care arată cum funcționează prototipul.

Sursa: www.habr.com