Trochgean mei it tema , lit ús sjen nei it probleem fan wiskundige modellering fan 'e oare kant. Nei't wy binne derfan oertsjûge dat it model oerienkomt mei de homespun wierheid fan it libben, kinne wy beäntwurdzje de wichtichste fraach: "wat, krekt, hawwe wy hjir?" By it meitsjen fan in model fan in technysk objekt wolle wy meastal der wis fan wêze dat dit objekt oan ús ferwachtings foldocht. Foar dit doel wurde dynamyske berekkeningen fan prosessen útfierd en it resultaat wurdt fergelike mei de easken. Dit is in digitale twilling, in firtuele prototype, ensfh. modieuze lytse jonges dy't, yn it ûntwerpstadium, it probleem oplosse hoe't jo derfoar soargje kinne dat wy krije wat wy pland hawwe.
Hoe kinne wy fluch soargje dat ús systeem krekt is wat wy ûntwerpe, sil ús ûntwerp fleane of driuwe? En as it fljocht, hoe heech? En as it driuwt, hoe djip?
Dit artikel besprekt de automatisearring fan ferifikaasje fan neilibjen fan de easken fan in technysk gebou by it meitsjen fan dynamyske modellen fan technyske systemen. As foarbyld, lit ús sjen nei in elemint fan de technyske spesifikaasje foar in fleantúch lucht cooling systeem.
Wy beskôgje dy easken dy't kin wurde útdrukt numerike en ferifiearre wiskundich basearre op in spesifyk berekkening model. It is dúdlik dat dit mar in diel is fan 'e algemiene easken foar elk technysk systeem, mar it is op it kontrolearjen fan har dat wy tiid, senuwen en jild besteegje oan it meitsjen fan dynamyske modellen fan it objekt.
By it beskriuwen fan technyske easken yn 'e foarm fan in dokumint kinne ferskate soarten ferskillende easken wurde ûnderskieden, elk fan dy fereasket ferskate oanpak foar de foarming fan automatyske ferifikaasje fan ferfolling fan easken.
Besjoch bygelyks dizze lytse, mar realistyske set fan easken:
- Atmosfearyske luchttemperatuer by de yngong nei it wettersuveringssysteem:
op it parkearplak - fan min 35 oant 35 ºС,
yn flecht - fan min 35 oant 39 ºС. - De statyske druk fan atmosfearyske loft yn flecht is fan 700 oant 1013 GPa (fan 526 oant 760 mm Hg).
- De totale luchtdruk by de yngong fan 'e SVO-luchtyntak yn' e flecht is fan 754 oant 1200 GPa (fan 566 oant 1050 mm Hg).
- Cooling lucht temperatuer:
op it parkearplak - net mear as 27 ºС, foar technyske blokken - net mear as 29 ºС,
yn flecht - net mear as 25 ºС, foar technyske blokken - net mear as 27 ºС. - Cooling luchtstream:
as parkeard - op syn minst 708 kg / h,
yn flecht - net minder as 660 kg / h. - De lofttemperatuer yn 'e ynstrumintfakken is net mear as 60 ºС.
- It bedrach fan fyn frije focht yn 'e koellucht is net mear as 2 g / kg droege loft.
Sels binnen dizze beheinde set fan easken binne d'r op syn minst twa kategoryen dy't oars moatte wurde behannele yn it systeem:
- easken foar wurking betingsten fan it systeem (clausules 1-3);
- parametric easken foar it systeem (clausules 3-7).
Systeem bedriuwsbetingsten easken
Eksterne betingsten foar it systeem dat wurdt ûntwikkele tidens modellering kinne wurde oantsjutte as grinsbetingsten of as gefolch fan 'e wurking fan it algemiene systeem.
Yn dynamyske simulaasje is it nedich om te soargjen dat de oantsjutte bedriuwsbetingsten wurde dekt troch it simulaasjeproses.
Parametric systeem easken
Dizze easken binne parameters levere troch it systeem sels. Tidens it modellearingsproses kinne wy dizze parameters krije as berekkeningsresultaten en soargje derfoar dat de easken foldien wurde yn elke spesifike berekkening.
Easken identifikaasje en kodearring
Foar it gemak fan wurkjen mei easken riede besteande noarmen oan om in identifier oan elke eask ta te jaan. By it tawizen fan identifiers is it heul winsklik om in unifoarm kodearringsysteem te brûken.
De easkkoade kin gewoan in nûmer wêze dat it folchoardernûmer fan 'e eask fertsjintwurdiget, of it kin in koade befetsje foar it type eask, in koade foar it systeem of ienheid wêrop it jildt, in parameterkoade, in lokaasjekoade, en alles wat de yngenieur him kin foarstelle. (sjoch it artikel foar it brûken fan kodearring)
Tabel 1 jout in ienfâldich foarbyld fan easken kodearring.
- koade fan de boarne fan easken R-easken TK;
- koade type easken E - easken - miljeuparameters, as bedriuwsbetingsten
S - easken levere troch it systeem; - fleantúch status koade 0 - eltse, G - parkeard, F - yn flecht;
- fysike parameter type koade T - temperatuer, P - druk, G - flow rate, vochtigheid H;
- serial number fan de eask.
| ID easken |
beskriuwing | Parameter |
| REGT01 | Ambient luchttemperatuer by de yngong nei it wetterkoelingssysteem: op it parkearplak - fan min 35ºС. oant 35 ºС. | |
| REFT01 | Atmosfearyske luchttemperatuer by de yngong fan it luchtferdigeningssysteem: yn flecht - fan min 35 ºС oant 39 ºС. | |
| REFP01 | Statyske atmosfearyske luchtdruk yn flecht is fan 700 oant 1013 hPa (fan 526 oant 760 mm Hg). | |
| REFP02 | De totale luchtdruk by de yngong fan 'e SVO-luchtyntak yn' e flecht is fan 754 oant 1200 hPa (fan 566 oant 1050 mm Hg). | |
| RSGT01 | Koelluchttemperatuer: as parkeard net mear as 27 ºС | |
| RSGT02 | Koelluchttemperatuer: op it parkearplak, foar technyske ienheden net mear as 29 ºС | |
| RSFT01 | Koelluchttemperatuer yn 'e flecht net mear as 25 ºС | |
| RSFT02 | Koelluchttemperatuer: yn 'e flecht, foar technyske ienheden net mear as 27 ºС | |
| RSGG01 | Cooling luchtstream: doe't parkeard net minder as 708 kg / h | |
| RSFG01 | Cooling luchtstream: yn flecht net minder as 660 kg / h | |
| RS0T01 | Luchttemperatuer yn ynstrumintfakken net mear as 60 ºС | |
| RSH01 | It bedrach fan fyn frije focht yn 'e koellucht is net mear as 2 g / kg droege loft |
Easken ferifikaasje systeem design.
Foar elke ûntwerpeask is d'r in algoritme foar it beoardieljen fan 'e korrespondinsje fan' e ûntwerpparameters en de parameters spesifisearre yn 'e eask. Yn 't algemien befettet elk kontrôlesysteem altyd algoritmen foar it kontrolearjen fan easken gewoan standert. En sels elke tafersjochhâlder befettet se. As de temperatuer bûten de grinzen giet, giet de airconditioning oan. Sa is de earste etappe fan elke regeljouwing om te kontrolearjen oft de parameters foldogge oan de easken.
En om't ferifikaasje in algoritme is, dan kinne wy deselde ark en ark brûke dy't wy brûke om kontrôleprogramma's te meitsjen. Bygelyks, de SimInTech-omjouwing kinne jo projektpakketten meitsje mei ferskate dielen fan it model, útfierd yn 'e foarm fan aparte projekten (objektmodel, kontrôlesysteemmodel, miljeumodel, ensfh.).
It projekt foar ferifikaasje fan easken wurdt yn dit gefal itselde algoritmeprojekt en is ferbûn mei it modelpakket. En yn 'e dynamyske modelleringsmodus docht it in analyse foar it neilibjen fan' e easken fan 'e technyske spesifikaasjes.
In mooglik foarbyld fan in systeemûntwerp wurdt werjûn yn figuer 1.
figuer 1. Foarbyld fan ûntwerp fan in ferifikaasje projekt.
Krekt as foar kontrôlealgoritmen kinne easken opsteld wurde as in set blêden. Foar it gemak fan wurkjen mei algoritmen yn strukturele modellewurkomjouwings lykas SimInTech, Simulink, AmeSim, wurdt de mooglikheid brûkt om struktueren op meardere nivo's te meitsjen yn 'e foarm fan submodellen. Dizze organisaasje makket it mooglik om in groep ferskate easken yn sets te ferienfâldigjen wurk mei in rige fan easken, lykas wurdt dien foar kontrôle algoritmen (sjoch figuer 2).
figuer 2. Hierarchyske struktuer fan de easken ferifikaasje model.
Bygelyks, yn 'e oantsjutte saak wurde twa groepen ûnderskieden: easken foar it miljeu en easken direkt foar it systeem. Dêrom wurdt in twa-nivo gegevensstruktuer brûkt: twa groepen, elk fan dat is in blêd fan it algoritme.
Om gegevens oan it model te ferbinen, wurdt in standertskema brûkt foar it generearjen fan in sinjaaldatabank, dy't gegevens bewarret foar útwikseling tusken dielen fan it projekt.
By it meitsjen en testen fan software wurde de lêzingen fan sensoren (analogen fan echte systeemsensors) dy't wurde brûkt troch it kontrôlesysteem yn dizze databank pleatst.
Foar in testprojekt kinne alle parameters berekkene yn it dynamyske model wurde opslein yn deselde databank en dus brûkt wurde om te kontrolearjen oft de easken foldien wurde.
Yn dit gefal kin it dynamyske model sels wurde útfierd yn elk wiskundige modelsysteem of sels yn 'e foarm fan in útfierber programma. De ienige eask is de oanwêzigens fan software-ynterfaces foar it útjaan fan modellearingsgegevens oan 'e eksterne omjouwing.
figuer 3. Ferbining fan it ferifikaasjeprojekt oan it komplekse model.
In foarbyld fan in basis easken ferifikaasje sheet wurdt presintearre yn figuer 4. Ut de ûntwikkelder syn eachpunt, it is in konvinsjonele berekkening diagram dêr't de easken ferifikaasje algoritme wurdt grafysk presintearre.
figuer 4. Easken check sheet.
De wichtichste dielen fan de kontrôle sheet wurde beskreaun yn figuer 5. De kontrôle algoritme wurdt foarme fergelykber mei it ûntwerp diagrammen fan kontrôle algoritmen. Oan de rjochterkant is der in blok foar it lêzen fan sinjalen út de databank. Dit blok makket tagong ta de sinjaaldatabank by simulaasje.
De ûntfongen sinjalen wurde analysearre om betingsten foar ferifikaasje fan easken te berekkenjen. Yn dit gefal wurdt hichteanalyse útfierd om de posysje fan it fleantúch te bepalen (oft it parkeard is as yn flecht). Foar dit doel kinne jo oare sinjalen en berekkene parameters fan it model brûke.
De ferifikaasjebetingsten en parameters dy't wurde kontrolearre wurde oerbrocht nei standert ferifikaasjeblokken, wêryn dizze parameters wurde analysearre foar neilibjen fan 'e oantsjutte easken. De resultaten wurde op sa'n manier yn 'e sinjaaldatabase opnommen dat se kinne wurde brûkt om automatysk in checklist te generearjen.
figuer 5. Struktuer fan de easken ferifikaasje berekkening sheet.
De te testen parameters brûke net needsaaklik sinjalen befette yn 'e databank, dy't wurde regele troch parameters berekkene tidens it simulaasjeproses. Neat belet ús om yn it ramt fan de konsept-easken ekstra berekkeningen út te fieren, lykas wy de ferifikaasjebetingsten berekkenje.
Bygelyks, dizze eask:
It oantal aktivaasjes fan it korreksjesysteem yn 'e flecht nei it doel moat net mear wêze as 5, en de totale operaasjetiid fan it korreksjesysteem moat net mear as 30 sekonden wêze.
Yn dit gefal wurdt in algoritme foar it tsjingean fan it oantal starts en totale wurktiid tafoege oan it ûntwerpdiagram fan 'e easken.
Typyske easken ferifikaasje blok.
Elk karfakje foar standert eask is ûntworpen om de ferfolling fan in eask fan in bepaald type te berekkenjen. De miljeu-easken omfetsje bygelyks in berik fan omjouwingstemperatueren by parkeare en yn flecht. Dit blok moat de lofttemperatuer yn it model ûntfange as parameter en bepale oft dizze parameter it oantsjutte temperatuerberik dekt./p>
It blok befettet twa ynfier havens, param en condition.
De earste wurdt fiede mei de parameter dy't kontrolearre wurdt. Yn dit gefal, "Eksterne temperatuer".
In Boolean fariabele wurdt levere oan de twadde haven - de betingst foar it útfieren fan de kontrôle.
As TRUE (1) wurdt ûntfongen by de twadde ynfier, dan fiert it blok in eask ferifikaasje berekkening.
As de twadde ynfier FALSE (0) ûntfangt, dan wurde de testbetingsten net foldien. Dit is nedich sadat de berekkeningsbetingsten rekken holden wurde kinne. Yn ús gefal wurdt dizze ynfier brûkt om de kontrôle yn te skeakeljen of út te skeakeljen ôfhinklik fan 'e steat fan it model. As it fleantúch op 'e grûn is tidens de simulaasje, dan wurde de easken yn ferbân mei flecht net kontrolearre, en oarsom - as it fleantúch yn'e flecht is, dan wurde de easken relatearre oan operaasje op stand net kontrolearre.
Dizze ynfier kin ek brûkt wurde by it opsetten fan it model, bygelyks yn 'e earste faze fan berekkening. As it model yn 'e fereaske steat brocht wurdt, wurde de kontrôleblokken útskeakele, mar sa gau as it systeem de fereaske bestjoeringsmodus berikt, wurde de kontrôleblokken ynskeakele.
De parameters fan dit blok binne:
- grinsbetingsten: boppeste (UpLimit) en legere (DownLimit) berik grinzen dy't moatte wurde kontrolearre;
- fereaske systeem exposure tiid by de grins berik (TimeInterval) yn sekonden;
- Request ID ReqName;
- tastimming fan it berikken Out_range is in Booleaanske fariabele dy't bepaalt oft in wearde grutter is as it kontrolearre berik is in ynbreuk op de eask.
Yn guon gefallen jout de testwearde-útfier oan dat it systeem wat marzje hat en kin wurkje bûten it wurkbereik. Yn oare gefallen betsjut in útgong dat it systeem net by steat is om de setpoints binnen berik te hâlden.
figuer 6. In typysk eigendom kontrôle blok yn it diagram en syn parameters.
As gefolch fan 'e berekkening fan dit blok wurdt de Resultaat fariabele foarme by de útfier, dy't de folgjende wearden nimt:
- 0 - rGjin, wearde net definiearre;
- 1 - rDone, de eask wurdt foldien;
- 2 - rFault, de eask wurdt net foldien.
De blokôfbylding befettet:
- identifier tekst;
- digitale werjeften fan parameters foar mjittinggrinzen;
- kleur identifier fan de parameter status.
Binnen it blok kin d'r in frij komplekse logyske konklúzjekring wêze.
Bygelyks, om it wurktemperatuerberik te kontrolearjen fan 'e ienheid werjûn yn figuer 6, wurdt it ynterne circuit werjûn yn figuer 7.
figuer 7. Ynterne diagram fan de temperatuer berik bepaling ienheid.
Binnen it circuitblok wurde de eigenskippen oantsjutte yn 'e blokparameters brûkt.
Neist it analysearjen fan neilibjen fan easken, befettet it ynterne diagram fan it blok in grafyk nedich foar it werjaan fan de simulaasjeresultaten. Dizze grafyk kin brûkt wurde sawol foar it besjen tidens berekkening en foar it analysearjen fan de resultaten nei berekkening.
De berekkeningsresultaten wurde oerbrocht nei de útfier fan it blok en wurde tagelyk opnommen yn in algemien rapportbestân, dat wurdt makke op basis fan de resultaten foar it hiele projekt. (sjoch fig. 8)
In foarbyld fan in rapport makke op basis fan de simulaasjeresultaten is in html-bestân makke neffens in opjûne opmaak. It formaat kin willekeurich ynsteld wurde nei it formaat dat akseptearre wurdt troch in bepaalde organisaasje.
Binnen it circuitblok wurde de eigenskippen oantsjutte yn 'e blokparameters brûkt.
Neist it analysearjen fan neilibjen fan easken, befettet it ynterne diagram fan it blok in grafyk nedich foar it werjaan fan de simulaasjeresultaten. Dizze grafyk kin brûkt wurde sawol foar it besjen tidens berekkening en foar it analysearjen fan de resultaten nei berekkening.
De berekkeningsresultaten wurde oerbrocht nei de útfier fan it blok en wurde tagelyk opnommen yn in algemien rapportbestân, dat wurdt makke op basis fan de resultaten foar it hiele projekt. (sjoch fig. 8)
In foarbyld fan in rapport makke op basis fan de simulaasjeresultaten is in html-bestân makke neffens in opjûne opmaak. It formaat kin willekeurich ynsteld wurde nei it formaat dat akseptearre wurdt troch in bepaalde organisaasje.
figuer 8. Foarbyld fan in rapport triem basearre op simulaasje resultaten.
Yn dit foarbyld is it rapportfoarm direkt yn 'e projekteigenskippen konfigureare, en it formaat yn' e tabel wurdt ynsteld as globale projektsinjalen. Yn dit gefal oplost SimInTech sels it probleem fan it opsetten fan it rapport, en it blok foar it skriuwen fan resultaten nei in bestân brûkt dizze rigels om te skriuwen nei it rapportbestân.
figuer 9. It ynstellen fan it rapport opmaak yn globale projekt sinjalen
Mei help fan in sinjaal databank foar easken.
Om it wurk mei eigendomsynstellingen te automatisearjen, wurdt in standertstruktuer makke yn 'e sinjaaldatabase foar elke typyske blok. (sjoch ôfb. 10)
figuer 10. Foarbyld fan de struktuer fan in eask kontrôle blok yn in sinjaal databank.
Signal databank biedt:
- It opslaan fan alle nedige parameters foar systeemeasken.
- Handig besjen fan besteande projekteasken út oantsjutte parameters en hjoeddeistige modellearingsresultaten.
- It ynstellen fan ien blok of in groep blokken mei in skriptprogrammearringstaal. Feroarings yn 'e sinjaaldatabase liede ta feroaringen yn' e wearden fan blokeigendom yn it diagram.
- Opslaan fan tekstbeskriuwings, keppelings nei items fan technyske spesifikaasjes as identifiers yn it systeem foar easkenbehear.
Sinjaaldatabankstruktueren foar easken kinne maklik konfigureare wurde om te wurkjen mei in systeem foar easkenbehear fan tredden. In algemien diagram fan ynteraksje mei systemen foar easkenbehear wurdt presintearre yn figuer 11.
figuer 11. Diagram fan ynteraksje mei de easken behear systeem.
De folchoarder fan ynteraksje tusken it SimInTech-testprojekt en it easkkontrôlesysteem is as folget:
- De betingsten fan referinsje binne opdield yn easken.
- De easken fan 'e technyske spesifikaasjes wurde identifisearre dy't kinne wurde ferifiearre troch wiskundige modellering fan technyske prosessen.
- Attributen fan de selektearre easken wurde oerdroegen oan de SimInTech sinjaal databank yn de struktuer fan standert blokken (bygelyks, maksimum en minimum temperatuer).
- Tidens it berekkeningsproses wurde struktuergegevens oerdroegen oan blokûntwerpdiagrammen, analyse wurdt útfierd en de resultaten wurde opslein yn in sinjaaldatabase.
- Sadree't de berekkening foltôge is, wurde de analyseresultaten oerdroegen oan it easkenbehearsysteem.
Easken stappen 3 oant 5 meie wurde werhelle tidens it ûntwerp proses as feroarings oan it ûntwerp en / of easken plakfine en de ynfloed fan de feroarings moatte wurde opnij hifke.
Konklúzjes.
- It makke prototype fan it systeem soarget foar in signifikante reduksje yn 'e tiid fan analyze fan besteande modellen foar it neilibjen fan' e easken fan 'e technyske spesifikaasjes.
- De foarstelde testtechnology brûkt al besteande dynamyske modellen en kin sels brûkt wurde foar alle dynamyske modellen, ynklusyf dy net útfierd yn 'e SimInTech-omjouwing.
- Mei it brûken fan batchgegevensorganisaasje kinne jo pakketten foar ferifikaasje fan easken oanmeitsje parallel mei modelûntwikkeling, of sels dizze pakketten brûke as technyske spesifikaasjes foar modelûntwikkeling.
- De technology kin wurde yntegrearre mei besteande easken foar behearsystemen sûnder signifikante kosten.
Foar dyjingen dy't lêze oant it ein,
Boarne: www.habr.com