Outomatiese verifikasie van TOR-vereistes in die proses van dinamiese simulasie

Gaan voort met die tema "Wat is jou bewyse?", kom ons kyk na die probleem van wiskundige modellering van die ander kant af. Nadat ons oortuig is dat die model ooreenstem met die tuisgemaakte waarheid van die lewe, kan ons die hoofvraag beantwoord: "wat presies het ons hier?" Wanneer 'n model van 'n tegniese voorwerp geskep word, wil ons gewoonlik seker maak dat hierdie voorwerp aan ons verwagtinge sal voldoen. Vir hierdie doel word dinamiese berekeninge van prosesse uitgevoer en die resultaat word met die vereistes vergelyk. Dit is 'n digitale tweeling, 'n virtuele prototipe, ens. modieuse shnyags wat in die ontwerpstadium die probleem oplos van hoe om seker te maak dat ons kry wat ons beplan het.

Hoe kan ons vinnig seker maak dat ons stelsel presies is wat ons ontwerp, sal ons ontwerp vlieg of dryf? En as dit vlieg, hoe hoog? En as dit dryf, hoe diep?

Hierdie artikel bespreek die outomatisering van verifikasie van voldoening aan die vereistes van 'n tegniese gebou wanneer dinamiese modelle van tegniese stelsels geskep word. As 'n voorbeeld, kom ons kyk na 'n element van die tegniese spesifikasie vir 'n vliegtuig lugverkoelingstelsel.

Ons oorweeg daardie vereistes wat numeries uitgedruk en wiskundig geverifieer kan word gebaseer op 'n spesifieke berekeningsmodel. Dit is duidelik dat dit slegs deel is van die algemene vereistes vir enige tegniese stelsel, maar dit is om dit te kontroleer dat ons tyd, senuwees en geld spandeer om dinamiese modelle van die voorwerp te skep.

Wanneer tegniese vereistes in die vorm van 'n dokument beskryf word, kan verskeie tipes verskillende vereistes onderskei word, wat elkeen verskillende benaderings vereis vir die vorming van outomatiese verifikasie van vereistesvervulling.

Oorweeg byvoorbeeld hierdie klein maar realistiese stel vereistes:

1. Atmosferiese lugtemperatuur by die ingang van die waterbehandelingstelsel:
   in die parkeerterrein - van minus 35 tot 35 ºС,
   in vlug - van minus 35 tot 39 ºС.
2. Die statiese druk van atmosferiese lug tydens vlug is van 700 tot 1013 GPa (van 526 tot 760 mm Hg).
3. Die totale lugdruk by die ingang na die SVO-luginlaat in vlug is van 754 tot 1200 GPa (vanaf 566 tot 1050 mm Hg).
4. Verkoeling lug temperatuur:
   in die parkeerterrein - hoogstens 27 ºС, vir tegniese blokke - nie meer as 29 ºС nie,
   in vlug - hoogstens 25 ºС, vir tegniese blokke - nie meer as 27 ºС nie.
5. Verkoelende lugvloei:
   wanneer geparkeer - ten minste 708 kg/h,
   in vlug - nie minder nie as 660 kg/h.
6. Die lugtemperatuur in die instrumentkompartemente is nie meer as 60 ºС nie.
7. Die hoeveelheid fyn vrye vog in die verkoelingslug is nie meer as 2 g/kg droë lug nie.

Selfs binne hierdie beperkte stel vereistes is daar ten minste twee kategorieë wat verskillend in die stelsel hanteer moet word:

• vereistes vir bedryfstoestande van die stelsel (klousule 1-3);
• parametriese vereistes vir die stelsel (klousule 3-7).

Stelsel bedryfstoestande vereistes
Eksterne toestande vir die stelsel wat tydens modellering ontwikkel word, kan gespesifiseer word as grenstoestande of as gevolg van die werking van die algemene stelsel.
In dinamiese simulasie is dit nodig om te verseker dat die gespesifiseerde bedryfstoestande deur die simulasieproses gedek word.

Parametriese stelselvereistes
Hierdie vereistes is parameters wat deur die stelsel self verskaf word. Tydens die modelleringsproses kan ons hierdie parameters as berekeningsresultate verkry en seker maak dat daar aan die vereistes voldoen word in elke spesifieke berekening.

Vereistes identifikasie en kodering

Vir gerief om met vereistes te werk, beveel bestaande standaarde aan om 'n identifiseerder aan elke vereiste toe te ken. Wanneer identifiseerders toegewys word, is dit hoogs wenslik om 'n verenigde koderingstelsel te gebruik.

Die vereiste kode kan bloot 'n nommer wees wat die bestelnommer van die vereiste verteenwoordig, of dit kan 'n kode vir die tipe vereiste, 'n kode vir die stelsel of eenheid waarop dit van toepassing is, 'n parameterkode, 'n liggingkode en enigiets anders wat die ingenieur kan voorstel. (sien die artikel vir die gebruik van enkodering)

Tabel 1 verskaf 'n eenvoudige voorbeeld van vereisteskodering.

1. kode van die bron van vereistes R-vereistes TK;
2. kode tipe vereistes E - vereistes - omgewingsparameters, of bedryfstoestande
   S - vereistes wat deur die stelsel verskaf word;
3. vliegtuigstatuskode 0 – enige, G – geparkeer, F – in vlug;
4. fisiese parameter tipe kode T – temperatuur, P – druk, G – vloeitempo, humiditeit H;
5. reeksnommer van die vereiste.

ID Vereistes	Beskrywing	Parameter
REGT01	Omringende lugtemperatuur by die ingang van die waterverkoelingstelsel: op die parkeerterrein - vanaf minus 35ºС. tot 35 ºС.
REFT01	Atmosferiese lugtemperatuur by die ingang van die lugafweerstelsel: in vlug - van minus 35 ºС tot 39 ºС.
REFP01	Statiese atmosferiese lugdruk tydens vlug is van 700 tot 1013 hPa (van 526 tot 760 mm Hg).
REFP02	Die totale lugdruk by die ingang van die SVO-luginlaat in vlug is van 754 tot 1200 hPa (vanaf 566 tot 1050 mm Hg).
RSGT01	Verkoelingslugtemperatuur: wanneer geparkeer nie meer as 27 ºС nie
RSGT02	Verkoelingslugtemperatuur: in die parkeerterrein, vir tegniese eenhede nie meer as 29 ºС nie
RSFT01	Verkoelende lugtemperatuur tydens vlug nie meer as 25 ºС nie
RSFT02	Verkoelingslugtemperatuur: tydens vlug, vir tegniese eenhede nie meer as 27 ºС nie
RSGG01	Verkoeling van lugvloei: wanneer geparkeer nie minder nie as 708 kg/h
RSFG01	Verkoelingslugvloei: in vlug nie minder nie as 660 kg/h
RS0T01	Lugtemperatuur in instrumentkompartemente nie meer as 60 ºС nie
RSH01	Die hoeveelheid fyn vrye vog in die verkoelingslug is nie meer as 2 g/kg droë lug nie

Vereistes verifikasie stelsel ontwerp.

Vir elke ontwerpvereiste is daar 'n algoritme om die ooreenstemming van die ontwerpparameters en die parameters gespesifiseer in die vereiste te assesseer. Oor die algemeen bevat enige beheerstelsel altyd algoritmes om vereistes na te gaan bloot by verstek. En selfs enige reguleerder bevat hulle. As die temperatuur buite die perke gaan, skakel die lugversorger aan. Die eerste fase van enige regulasie is dus om te kyk of die parameters aan die vereistes voldoen.

En aangesien verifikasie 'n algoritme is, kan ons dieselfde gereedskap en gereedskap gebruik wat ons gebruik om beheerprogramme te skep. Byvoorbeeld, die SimInTech-omgewing laat jou toe om projekpakkette te skep wat verskeie dele van die model bevat, uitgevoer in die vorm van afsonderlike projekte (voorwerpmodel, beheerstelselmodel, omgewingsmodel, ens.).

Die vereistesverifikasieprojek word in hierdie geval dieselfde algoritmeprojek en word aan die modelpakket gekoppel. En in die dinamiese modelleringsmodus voer dit 'n ontleding uit vir voldoening aan die vereistes van die tegniese spesifikasies.

'n Moontlike voorbeeld van 'n stelselontwerp word in Figuur 1 getoon.

Figuur 1. Voorbeeld van ontwerp van 'n verifikasieprojek.

Net soos vir beheeralgoritmes, kan vereistes as 'n stel velle opgestel word. Vir die gerief om met algoritmes in strukturele modelleringsomgewings soos SimInTech, Simulink, AmeSim te werk, word die vermoë gebruik om multi-vlak strukture in die vorm van submodelle te skep. Hierdie organisasie maak dit moontlik om verskeie vereistes in stelle te groepeer om werk met 'n verskeidenheid vereistes te vereenvoudig, soos gedoen word vir beheeralgoritmes (sien Fig. 2).

Figuur 2. Hiërargiese struktuur van die vereistesverifikasiemodel.

Byvoorbeeld, in die geval onder oorweging, word twee groepe onderskei: vereistes vir die omgewing en vereistes direk vir die stelsel. Daarom word 'n twee-vlak datastruktuur gebruik: twee groepe, wat elkeen 'n blaar van die algoritme is.

Om data aan die model te koppel, word 'n standaardskema vir die generering van 'n seindatabasis gebruik, wat data stoor vir uitruiling tussen dele van die projek.

Wanneer sagteware geskep en getoets word, word die lesings van sensors (analoë van werklike stelselsensors) wat deur die beheerstelsel gebruik word in hierdie databasis geplaas.
Vir 'n toetsprojek kan enige parameters wat in die dinamiese model bereken word, in dieselfde databasis gestoor word en dus gebruik word om te kontroleer of aan die vereistes voldoen word.

In hierdie geval kan die dinamiese model self in enige wiskundige modelleringstelsel of selfs in die vorm van 'n uitvoerbare program uitgevoer word. Die enigste vereiste is die teenwoordigheid van sagteware-koppelvlakke vir die uitreiking van modelleringsdata aan die eksterne omgewing.

Figuur 3. Koppel die verifikasieprojek aan die komplekse model.

'n Voorbeeld van 'n basiese vereistes-verifikasieblad word aangebied in Figuur 4. Vanuit die ontwikkelaar se oogpunt is dit 'n konvensionele berekeningsdiagram waarop die vereistesverifikasie-algoritme grafies voorgestel word.

Figuur 4. Vereisteskontroleblad.

Die hoofdele van die kontroleblad word in Figuur 5 beskryf. Die kontrolealgoritme word soortgelyk aan die ontwerpdiagramme van beheeralgoritmes gevorm. Aan die regterkant is daar 'n blok vir die lees van seine vanaf die databasis. Hierdie blok kry toegang tot die seindatabasis tydens simulasie.

Die ontvangde seine word ontleed om vereistesverifikasietoestande te bereken. In hierdie geval word hoogte-analise uitgevoer om die posisie van die vliegtuig te bepaal (of dit geparkeer is of in vlug). Vir hierdie doel kan jy ander seine en berekende parameters van die model gebruik.

Die verifikasievoorwaardes en parameters wat nagegaan word, word na standaard verifikasieblokke oorgedra, waarin hierdie parameters ontleed word vir voldoening aan die gespesifiseerde vereistes. Die resultate word op so 'n manier in die seindatabasis aangeteken dat dit gebruik kan word om outomaties 'n kontrolelys te genereer.

Figuur 5. Struktuur van die vereistesverifikasieberekeningsblad.

Die parameters wat getoets moet word, gebruik nie noodwendig seine wat in die databasis vervat is nie, wat beheer word deur parameters wat tydens die simulasieproses bereken word. Niks verhinder ons om bykomende berekeninge binne die raamwerk van die konsepvereistes uit te voer nie, net soos ons die verifikasievoorwaardes bereken.

Byvoorbeeld, hierdie vereiste:

Die aantal aktiverings van die regstellingstelsel tydens die vlug na die teiken moet nie 5 oorskry nie, en die totale bedryfstyd van die regstellingstelsel moet nie 30 sekondes oorskry nie.

In hierdie geval word 'n algoritme om die aantal begin en totale bedryfstyd teë te werk by die ontwerpdiagram van die vereistes gevoeg.

Tipiese vereistes verifikasie blok.

Elke standaardvereiste-merkblokkie is ontwerp om die nakoming van 'n vereiste van 'n sekere tipe te bereken. Die omgewingsvereistes sluit byvoorbeeld 'n reeks omgewingsbedryfstemperature in wanneer geparkeer en in vlug. Hierdie blok moet die lugtemperatuur in die model as 'n parameter ontvang en bepaal of hierdie parameter die gespesifiseerde temperatuurreeks dek./p>

Die blok bevat twee invoerpoorte, param en toestand.

Die eerste een word gevoer met die parameter wat nagegaan word. In hierdie geval, "Eksterne temperatuur".

'n Boole-veranderlike word aan die tweede poort verskaf - die voorwaarde vir die uitvoering van die kontrole.

Indien WAAR (1) by die tweede inset ontvang word, voer die blok 'n vereiste verifikasie berekening uit.

As die tweede inset ONWAAR (0) ontvang, word daar nie aan die toetsvoorwaardes voldoen nie. Dit is nodig sodat die berekeningsvoorwaardes in ag geneem kan word. In ons geval word hierdie invoer gebruik om die kontrole te aktiveer of te deaktiveer, afhangende van die toestand van die model. As die vliegtuig tydens die simulasie op die grond is, word die vereistes wat verband hou met vlug nie nagegaan nie, en omgekeerd - as die vliegtuig in vlug is, dan word die vereistes wat verband hou met operasie op staanplek nie nagegaan nie.

Hierdie inset kan ook gebruik word wanneer die model opgestel word, byvoorbeeld by die aanvanklike stadium van berekening. Wanneer die model in die vereiste toestand gebring word, word die kontroleblokke gedeaktiveer, maar sodra die stelsel die vereiste bedryfsmodus bereik, word die kontroleblokke aangeskakel.

Die parameters van hierdie blok is:

• grensvoorwaardes: boonste (UpLimit) en onderste (DownLimit) reekslimiete wat nagegaan moet word;
• vereiste stelselblootstellingstyd by die grensreekse (Tydinterval) in sekondes;
• Versoek ID Versoeknaam;
• toelaatbaarheid om die reeks te oorskry Out_range is 'n Boole-veranderlike wat bepaal of 'n waarde wat die gekontroleerde reeks oorskry, 'n oortreding van die vereiste is.

In sommige gevalle dui die toetswaarde-uitset aan dat die stelsel 'n mate van marge het en moontlik buite sy bedryfsreeks werk. In ander gevalle beteken 'n uitset dat die stelsel nie in staat is om die stelpunte binne bereik te hou nie.

Figuur 6. 'n Tipiese eienskapkontroleblok in die diagram en sy parameters.

As gevolg van die berekening van hierdie blok word die Resultaatveranderlike by die uitset gevorm, wat die volgende waardes neem:

• 0 – rGeen, waarde nie gedefinieer nie;
• 1 – rKlaar, daar word aan die vereiste voldoen;
• 2 – rFout, daar word nie aan die vereiste voldoen nie.

Die blokbeeld bevat:

• identifiseerder teks;
• digitale vertonings van parameters vir meetgrense;
• kleur identifiseerder van die parameter status.

Binne die blok kan daar 'n taamlik komplekse logiese afleidingskring wees.

Byvoorbeeld, om die bedryfstemperatuurreeks van die eenheid wat in Figuur 6 getoon word na te gaan, word die interne stroombaan in Figuur 7 getoon.

Figuur 7. Interne diagram van die temperatuurreeksbepalingseenheid.

Binne die stroombaanblok word die eienskappe wat in die blokparameters gespesifiseer word, gebruik.
Benewens die ontleding van voldoening aan vereistes, bevat die interne diagram van die blok 'n grafiek wat nodig is om die simulasieresultate te vertoon. Hierdie grafiek kan beide gebruik word vir besigtiging tydens berekening en vir die ontleding van die resultate na berekening.

Die berekeningsresultate word na die afvoer van die blok oorgedra en word gelyktydig in 'n algemene verslaglêer aangeteken, wat op grond van die resultate vir die hele projek geskep word. (sien Fig. 8)

'n Voorbeeld van 'n verslag wat op grond van die simulasieresultate geskep is, is 'n HTML-lêer wat volgens 'n gegewe formaat geskep is. Die formaat kan arbitrêr gekonfigureer word na die formaat wat deur 'n spesifieke organisasie aanvaar word.

Binne die stroombaanblok word die eienskappe wat in die blokparameters gespesifiseer word, gebruik.
Benewens die ontleding van voldoening aan vereistes, bevat die interne diagram van die blok 'n grafiek wat nodig is om die simulasieresultate te vertoon. Hierdie grafiek kan beide gebruik word vir besigtiging tydens berekening en vir die ontleding van die resultate na berekening.

Die berekeningsresultate word na die afvoer van die blok oorgedra en word gelyktydig in 'n algemene verslaglêer aangeteken, wat op grond van die resultate vir die hele projek geskep word. (sien Fig. 8)

'n Voorbeeld van 'n verslag wat op grond van die simulasieresultate geskep is, is 'n HTML-lêer wat volgens 'n gegewe formaat geskep is. Die formaat kan arbitrêr gekonfigureer word na die formaat wat deur 'n spesifieke organisasie aanvaar word.

Figuur 8. Voorbeeld van 'n verslaglêer gebaseer op simulasieresultate.

In hierdie voorbeeld word die verslagvorm direk in die projekeienskappe gekonfigureer, en die formaat in die tabel word as globale projekseine gestel. In hierdie geval los SimInTech self die probleem op om die verslag op te stel, en die blok vir die skryf van resultate na 'n lêer gebruik hierdie lyne om na die verslaglêer te skryf.

Figuur 9. Stel die verslagformaat in globale projekseine

Gebruik 'n seindatabasis vir vereistes.

Om werk met eiendomsinstellings te outomatiseer, word 'n standaardstruktuur in die seindatabasis vir elke tipiese blok geskep. (sien Fig. 10)

Figuur 10. Voorbeeld van die struktuur van 'n vereistekontroleblok in 'n seindatabasis.

Sein databasis bied:

• Stoor al die nodige parameters vir stelselvereistes.
• Gerieflike besigtiging van bestaande projekvereistes vanaf gespesifiseerde parameters en huidige modelleringsresultate.
• Die opstel van een blok of 'n groep blokke met behulp van 'n script programmeertaal. Veranderinge in die seindatabasis lei tot veranderinge in die blokeiendomwaardes in die diagram.
• Berging van teksbeskrywings, skakels na tegniese spesifikasie-items of identifiseerders in die vereistesbestuurstelsel.

Seindatabasisstrukture vir vereistes kan maklik gekonfigureer word om met 'n derdeparty-vereistebestuurstelsel te werk. 'n Algemene diagram van interaksie met vereistesbestuurstelsels word in Figuur 11 aangebied.

Figuur 11. Diagram van interaksie met die vereistesbestuurstelsel.

Die volgorde van interaksie tussen die SimInTech-toetsprojek en die vereistebeheerstelsel is soos volg:

1. Die verwysingsopdrag word in vereistes opgedeel.
2. Die vereistes van die tegniese spesifikasies word geïdentifiseer wat geverifieer kan word deur wiskundige modellering van tegniese prosesse.
3. Eienskappe van die geselekteerde vereistes word oorgedra na die SimInTech-seindatabasis in die struktuur van standaardblokke (byvoorbeeld maksimum en minimum temperatuur).
4. Tydens die berekeningsproses word struktuurdata na blokontwerpdiagramme oorgedra, ontleding word uitgevoer en die resultate word in 'n seindatabasis gestoor.
5. Sodra die berekening voltooi is, word die ontledingsresultate na die vereistesbestuurstelsel oorgedra.

Vereistestappe 3 tot 5 kan tydens die ontwerpproses herhaal word wanneer veranderinge aan die ontwerp en/of vereistes plaasvind en die impak van die veranderinge hertoets moet word.

Gevolgtrekkings.

• Die geskepde prototipe van die stelsel bied 'n aansienlike vermindering in die tyd van ontleding van bestaande modelle vir voldoening aan die vereistes van die tegniese spesifikasies.
• Die voorgestelde toetstegnologie gebruik reeds bestaande dinamiese modelle en kan selfs vir enige dinamiese modelle gebruik word, insluitend dié wat nie in die SimInTech-omgewing uitgevoer word nie.
• Die gebruik van bondeldata-organisasie laat jou toe om vereistesverifikasiepakkette te skep parallel met modelontwikkeling, of selfs hierdie pakkette as tegniese spesifikasies vir modelontwikkeling te gebruik.
• Die tegnologie kan geïntegreer word met bestaande vereistesbestuurstelsels sonder noemenswaardige koste.

Vir diegene wat tot die einde toe lees, skakel na 'n video wat wys hoe die prototipe werk.

Bron: will.com