Aŭtomata konfirmo de TOR-postuloj en la procezo de dinamika simulado

Daŭrigante la temon "Kio estas via pruvo?", ni rigardu la problemon de matematika modelado de la alia flanko. Post kiam ni estas konvinkitaj, ke la modelo respondas al la hejma vero de la vivo, ni povas respondi la ĉefan demandon: "Kion, ĝuste, ni havas ĉi tie?" Kreante modelon de teknika objekto, ni kutime volas certigi, ke ĉi tiu objekto plenumos niajn atendojn. Por ĉi tiu celo, dinamikaj kalkuloj de procezoj estas faritaj kaj la rezulto estas komparata kun la postuloj. Ĉi tio estas cifereca ĝemelo, virtuala prototipo ktp. modaj uloj, kiuj, en la dezajna etapo, solvas la problemon kiel certigi, ke ni ricevas tion, kion ni planis.

Kiel ni povas rapide certigi, ke nia sistemo estas ĝuste tio, kion ni desegnas, ĉu nia dezajno flugos aŭ flosigos? Kaj se ĝi flugas, kiom alte? Kaj se ĝi flosas, kiom profunde?

Ĉi tiu artikolo diskutas la aŭtomatigon de kontrolo de konformeco al la postuloj de teknika konstruaĵo dum kreado de dinamikaj modeloj de teknikaj sistemoj. Ekzemple, ni rigardu elementon de la teknika specifo por aviadila aera malvarmiga sistemo.

Ni konsideras tiujn postulojn kiuj povas esti esprimitaj nombre kaj kontrolitaj matematike surbaze de specifa kalkulmodelo. Estas klare, ke ĉi tio estas nur parto de la ĝeneralaj postuloj por iu ajn teknika sistemo, sed estas kontrolante ilin, ke ni elspezas tempon, nervojn kaj monon por krei dinamikajn modelojn de la objekto.

Priskribante teknikajn postulojn en formo de dokumento, oni povas distingi plurajn specojn de malsamaj postuloj, ĉiu el kiuj postulas malsamajn alirojn por la formado de aŭtomata konfirmo de la plenumo de postuloj.

Ekzemple, konsideru ĉi tiun malgrandan sed realisman aron de postuloj:

1. Atmosfera aertemperaturo ĉe la enirejo al la akvopurigsistemo:
   en la parkejo - de minus 35 ĝis 35 ºС,
   dumfluge - de minus 35 ĝis 39 ºС.
2. La senmova premo de atmosfera aero dumfluge estas de 700 ĝis 1013 GPa (de 526 ĝis 760 mm Hg).
3. La totala aerpremo ĉe la enirejo al la SVO-aera enfluo dumfluge estas de 754 ĝis 1200 GPa (de 566 ĝis 1050 mm Hg).
4. Malvarmiga aertemperaturo:
   en la parkejo - ne pli ol 27 ºС, por teknikaj blokoj - ne pli ol 29 ºС,
   dumfluge - ne pli ol 25 ºС, por teknikaj blokoj - ne pli ol 27 ºС.
5. Malvarmiga aerfluo:
   kiam estas parkita - almenaŭ 708 kg/h,
   dumfluge - ne malpli ol 660 kg/h.
6. La aera temperaturo en la instrumentaj kupeoj ne estas pli ol 60 °С.
7. La kvanto de bona libera humideco en la malvarmiga aero estas ne pli ol 2 g/kg da seka aero.

Eĉ ene de ĉi tiu limigita aro de postuloj, ekzistas almenaŭ du kategorioj, kiuj devas esti pritraktitaj alimaniere en la sistemo:

• postuloj por operaciaj kondiĉoj de la sistemo (klazoj 1-3);
• parametrikaj postuloj por la sistemo (paragrafoj 3-7).

Postuloj de la funkciado de la sistemo
Eksteraj kondiĉoj por la sistemo estanta evoluigita dum modeligado povas esti precizigitaj kiel limkondiĉoj aŭ kiel rezulto de la operacio de la ĝenerala sistemo.
En dinamika simulado, necesas certigi, ke la specifitaj funkciaj kondiĉoj estas kovritaj de la simuladprocezo.

Parametrikaj sistemaj postuloj
Ĉi tiuj postuloj estas parametroj provizitaj de la sistemo mem. Dum la modeliga procezo, ni povas akiri ĉi tiujn parametrojn kiel kalkulrezultojn kaj certigi, ke la postuloj estas plenumitaj en ĉiu specifa kalkulo.

Identigo kaj kodigo de postuloj

Por facileco labori kun postuloj, ekzistantaj normoj rekomendas asigni identigilon al ĉiu postulo. Dum asignado de identigiloj, estas tre dezirinde uzi unuigitan kodigan sistemon.

Postulkodo povas esti simple nombro kiu reprezentas la ordnumeron de la postulo, aŭ ĝi povas enhavi kodon por la speco de postulo, kodon por la sistemo aŭ unuo al kiu ĝi aplikas, parametrokodo, lokkodo, kaj ion alian inĝenieron povas imagi. (vidu la artikolon pri la uzo de kodado)

Tablo 1 provizas simplan ekzemplon de postkodigo.

1. kodo de la fonto de postuloj R-postuloj TK;
2. kodo tipo de postuloj E - postuloj - mediaj parametroj, aŭ funkciado kondiĉoj
   S - postuloj provizitaj de la sistemo;
3. aviadilo statuskodo 0 - ajna, G - parkumita, F - dumfluge;
4. fizika parametro tipo kodo T - temperaturo, P - premo, G - flukvanto, humideco H;
5. seria numero de la postulo.

ID postuloj	Priskribo	Parametro
REGT01	Ĉirkaŭaera temperaturo ĉe la enirejo al la akvomalvarmigsistemo: en la parkejo - de minus 35ºС. ĝis 35 ºС.
REFT01	Atmosfera aera temperaturo ĉe la enirejo al la aerdefenda sistemo: dumfluge - de minus 35 ºС ĝis 39 ºС.
REFP01	Senmova atmosfera aerpremo dumfluge estas de 700 ĝis 1013 hPa (de 526 ĝis 760 mm Hg).
REFP02	La totala aerpremo ĉe la enirejo al la SVO-aera enfluo dumfluge estas de 754 ĝis 1200 hPa (de 566 ĝis 1050 mm Hg).
RSGT01	Malvarmiga aerotemperaturo: kiam estas parkita ne pli ol 27 ºС
RSGT02	Malvarmiga aerotemperaturo: en la parkejo, por teknikaj unuoj ne pli ol 29 ºС
RSFT01	Malvarmiganta aertemperaturo dumfluge ne pli ol 25 ºС
RSFT02	Malvarmiga aero temperaturo: dumfluge, por teknikaj unuoj ne pli ol 27 ºС
RSGG01	Malvarmiga aerfluo: kiam estas parkita ne malpli ol 708 kg/h
RSFG01	Malvarmiga aerfluo: dumfluge ne malpli ol 660 kg/h
RS0T01	Aera temperaturo en instrumentaj kupeoj ne pli ol 60 ºС
RSH01	La kvanto de bona libera humideco en la malvarmiga aero estas ne pli ol 2 g/kg da seka aero

Dezajno de sistemo pri konfirmo de postuloj.

Por ĉiu dezajnpostulo ekzistas algoritmo por taksi la korespondado de la dezajnoparametroj kaj la parametroj specifitaj en la postulo. Ĝenerale, ĉiu kontrolsistemo ĉiam enhavas algoritmojn por kontroli postulojn simple defaŭlte. Kaj eĉ ajna reguligisto enhavas ilin. Se la temperaturo iras ekster la limoj, la klimatizilo ŝaltas. Tiel, la unua etapo de iu ajn regularo estas kontroli ĉu la parametroj plenumas la postulojn.

Kaj ĉar konfirmo estas algoritmo, tiam ni povas uzi la samajn ilojn kaj ilojn, kiujn ni uzas por krei kontrolprogramojn. Ekzemple, la medio SimInTech permesas krei projektpakaĵojn enhavantajn diversajn partojn de la modelo, ekzekutitaj en la formo de apartaj projektoj (objekta modelo, kontrolsistemo modelo, mediomodelo ktp.).

La postula konfirmprojekto en ĉi tiu kazo iĝas la sama algoritmo projekto kaj estas konektita al la modelpakaĵo. Kaj en la dinamika modeliga reĝimo ĝi faras analizon por plenumado de la postuloj de la teknikaj specifoj.

Ebla ekzemplo de sistemdezajno estas montrita en Figuro 1.

Figuro 1. Ekzemplo de dezajno de kontrola projekto.

Same kiel por kontrolalgoritmoj, postuloj povas esti desegnitaj kiel aro de folioj. Por la komforto labori kun algoritmoj en strukturaj modelaj medioj kiel SimInTech, Simulink, AmeSim, la kapablo krei plurnivelajn strukturojn en la formo de submodeloj estas uzata. Ĉi tiu organizo ebligas grupigi diversajn postulojn en arojn por simpligi laboron kun aro da postuloj, kiel estas farita por kontrolalgoritmoj (vidu Fig. 2).

Figuro 2. Hierarkia strukturo de la postula konfirmmodelo.

Ekzemple, en la konsiderata kazo, du grupoj estas distingitaj: postuloj por la medio kaj postuloj rekte por la sistemo. Tial, dunivela datumstrukturo estas uzata: du grupoj, ĉiu el kiuj estas folio de la algoritmo.

Por konekti datumojn al la modelo, oni uzas norman skemon por generi signalan datumbazon, kiu stokas datumojn por interŝanĝo inter partoj de la projekto.

Dum kreado kaj testado de programaro, la legaĵoj de sensiloj (analogoj de realaj sistemaj sensiloj), kiuj estas uzataj de la kontrolsistemo, estas metitaj en ĉi tiun datumbazon.
Por testa projekto, ĉiuj parametroj kalkulitaj en la dinamika modelo povas esti stokitaj en la sama datumbazo kaj tiel uzataj por kontroli ĉu la postuloj estas plenumitaj.

En ĉi tiu kazo, la dinamika modelo mem povas esti efektivigita en iu ajn matematika modeliga sistemo aŭ eĉ en la formo de plenumebla programo. La nura postulo estas la ĉeesto de softvarinterfacoj por elsendi modeligajn datenojn al la ekstera medio.

Figuro 3. Konektante la konfirmprojekton al la kompleksa modelo.

Ekzemplo de baza konfirma folio estas prezentita en Figuro 4. De la vidpunkto de la programisto, ĝi estas konvencia kalkuldiagramo sur kiu la postula kontrola algoritmo estas grafike prezentita.

Figuro 4. Kontrolfolio de Postuloj.

La ĉefaj partoj de la kontrolfolio estas priskribitaj en Figuro 5. La kontrolalgoritmo estas formita simile al la dezajnaj diagramoj de kontrol-algoritmoj. Sur la dekstra flanko estas bloko por legi signalojn de la datumbazo. Ĉi tiu bloko aliras la signaldatumbazon dum simulado.

La ricevitaj signaloj estas analizitaj por kalkuli postulajn konfirmkondiĉojn. En ĉi tiu kazo, altecanalizo estas farita por determini la pozicion de la aviadilo (ĉu ĝi estas parkumita aŭ dumfluge). Por ĉi tiu celo, vi povas uzi aliajn signalojn kaj kalkulitajn parametrojn de la modelo.

La kontrolaj kondiĉoj kaj parametroj kontrolitaj estas translokigitaj al normaj kontrolaj blokoj, en kiuj ĉi tiuj parametroj estas analizitaj por konformeco al la specifitaj postuloj. La rezultoj estas registritaj en la signala datumbazo tiel, ke ili povas esti uzataj por aŭtomate generi kontrolon.

Figuro 5. Strukturo de la kalkultabelo pri kontrolado de postuloj.

La parametroj testendaj ne nepre uzas signalojn enhavitajn en la datumbazo, kiuj estas kontrolitaj per parametroj kalkulitaj dum la simuladprocezo. Nenio malhelpas nin fari pliajn kalkulojn en la kadro de la malnetaj postuloj, same kiel ni kalkulas la kontrolajn kondiĉojn.

Ekzemple, ĉi tiu postulo:

La nombro da aktivigoj de la korekta sistemo dum la flugo al la celo ne devus superi 5, kaj la totala funkciada tempo de la korekta sistemo ne devus superi 30 sekundojn.

En ĉi tiu kazo, algoritmo por kontraŭstari la nombron da komencoj kaj totala funkciada tempo estas aldonita al la dezajnodiagramo de la postuloj.

Tipaj postuloj kontrola bloko.

Ĉiu markobutono de norma postulo estas dizajnita por kalkuli la plenumon de postulo de certa tipo. Ekzemple, la mediaj postuloj inkludas gamon da ĉirkaŭaj funkciigadtemperaturoj kiam parkumite kaj dumfluge. Ĉi tiu bloko devas ricevi la aertemperaturon en la modelo kiel parametron kaj determini ĉu ĉi tiu parametro kovras la specifitan temperaturon./p>

La bloko enhavas du enigajn havenojn, param kaj kondiĉon.

La unua estas nutrita kun la parametro estanta kontrolita. En ĉi tiu kazo, "Ekstera temperaturo".

Bulea variablo estas liverita al la dua haveno - la kondiĉo por plenumi la kontrolon.

Se VERA (1) estas ricevita ĉe la dua enigo, tiam la bloko elfaras postulan konfirmkalkulon.

Se la dua enigo ricevas FALSE (0), tiam la testkondiĉoj ne estas plenumitaj. Ĉi tio estas necesa por ke la kalkulkondiĉoj estu konsiderataj. En nia kazo, ĉi tiu enigo estas uzata por ebligi aŭ malŝalti la kontrolon depende de la stato de la modelo. Se la aviadilo estas surtere dum la simulado, tiam la postuloj rilataj al flugo ne estas kontrolitaj, kaj inverse - se la aviadilo estas en flugo, tiam la postuloj rilataj al operacio ĉe stando ne estas kontrolitaj.

Ĉi tiu enigo ankaŭ povas esti uzata dum agordado de la modelo, ekzemple ĉe la komenca etapo de kalkulo. Kiam la modelo estas alportita en la bezonatan staton, la kontrolblokoj estas malŝaltitaj, sed tuj kiam la sistemo atingas la postulatan operacian reĝimon, la kontrolblokoj estas ŝaltitaj.

La parametroj de ĉi tiu bloko estas:

• limkondiĉoj: supra (UpLimit) kaj malsupra (DownLimit) intervallimoj kiuj devas esti kontrolitaj;
• postulata sistema ekspontempo ĉe la limintervaloj (TimeInterval) en sekundoj;
• Peto ID ReqName;
• permesebleco superi la intervalon Out_range estas Bulea variablo kiu determinas ĉu valoro superanta la kontrolitan intervalon estas malobservo de la postulo.

En iuj kazoj, la testvalora eligo indikas, ke la sistemo havas iom da marĝeno kaj povas funkcii ekster sia operacia intervalo. En aliaj kazoj, produktaĵo signifas ke la sistemo estas nekapabla konservi la fikspunktojn ene de intervalo.

Figuro 6. Tipa posedaĵkontrolbloko en la diagramo kaj ĝiaj parametroj.

Kiel rezulto de la kalkulo de ĉi tiu bloko, la Rezulta variablo estas formita ĉe la eligo, kiu prenas la sekvajn valorojn:

• 0 – rNenio, valoro ne difinita;
• 1 – rFarita, la postulo estas plenumita;
• 2 – rFaŭlto, la postulo ne estas plenumita.

La blokbildo enhavas:

• identigilo teksto;
• ciferecaj ekranoj de mezuraj limoj parametroj;
• koloridentigilo de la parametro statuso.

Ene de la bloko povas ekzisti sufiĉe kompleksa logika inferenca cirkvito.

Ekzemple, por kontroli la funkcian temperaturon de la unuo montrita en Figuro 6, la interna cirkvito estas montrita en Figuro 7.

Figuro 7. Interna diagramo de la temperatura intervalo determina unuo.

Ene de la cirkvitbloko, la propraĵoj specifitaj en la blokparametroj estas uzataj.
Krom analizado de konformeco al postuloj, la interna diagramo de la bloko enhavas grafeon necesan por montri la simulajn rezultojn. Ĉi tiu grafikaĵo povas esti uzata kaj por vidi dum kalkulo kaj por analizi la rezultojn post kalkulo.

La kalkulrezultoj estas transdonitaj al la eligo de la bloko kaj estas samtempe registritaj en ĝenerala raportdosiero, kiu estas kreita surbaze de la rezultoj por la tuta projekto. (vidu Fig. 8)

Ekzemplo de raporto kreita surbaze de la simulaj rezultoj estas html-dosiero kreita laŭ donita formato. La formato povas esti arbitre agordita al la formato akceptita de aparta organizo.

Ene de la cirkvitbloko, la propraĵoj specifitaj en la blokparametroj estas uzataj.
Krom analizado de konformeco al postuloj, la interna diagramo de la bloko enhavas grafeon necesan por montri la simulajn rezultojn. Ĉi tiu grafikaĵo povas esti uzata kaj por vidi dum kalkulo kaj por analizi la rezultojn post kalkulo.

La kalkulrezultoj estas transdonitaj al la eligo de la bloko kaj estas samtempe registritaj en ĝenerala raportdosiero, kiu estas kreita surbaze de la rezultoj por la tuta projekto. (vidu Fig. 8)

Ekzemplo de raporto kreita surbaze de la simulaj rezultoj estas html-dosiero kreita laŭ donita formato. La formato povas esti arbitre agordita al la formato akceptita de aparta organizo.

Figuro 8. Ekzemplo de raportdosiero bazita sur simulaj rezultoj.

En ĉi tiu ekzemplo, la raportformularo estas agordita rekte en la projektaj propraĵoj, kaj la formato en la tabelo estas agordita kiel tutmondaj projektsignaloj. En ĉi tiu kazo, SimInTech mem solvas la problemon de agordo de la raporto, kaj la bloko por skribi rezultojn al dosiero uzas ĉi tiujn liniojn por skribi al la raportdosiero.

Figuro 9. Agordi la raportan formaton en tutmondaj projektsignaloj

Uzante signala datumbazo por postuloj.

Por aŭtomatigi laboron kun posedaĵagordoj, norma strukturo estas kreita en la signala datumbazo por ĉiu tipa bloko. (vidu Fig. 10)

Figuro 10. Ekzemplo de la strukturo de postulkontrola bloko en signala datumbazo.

Signala datumbazo disponigas:

• Stokante ĉiujn necesajn sistemajn postulajn parametrojn.
• Konvena spektado de ekzistantaj projektpostuloj de specifitaj parametroj kaj nunaj modelaj rezultoj.
• Agordi unu blokon aŭ grupon de blokoj uzante skriptan programlingvon. Ŝanĝoj en la signala datumbazo kondukas al ŝanĝoj en la blokaj posedaĵvaloroj en la diagramo.
• Stoki tekstajn priskribojn, ligilojn al teknikaj specifaĵoj aŭ identigilojn en la postula administradsistemo.

Signalaj datumbazaj strukturoj por postuloj povas esti facile agordeblaj por labori kun triaparta sistemo de administrado de postuloj.Ĝenerala diagramo de interago kun sistemoj de administrado de postuloj estas prezentita en Figuro 11.

Figuro 11. Diagramo de interago kun la postula administradsistemo.

La sekvenco de interagado inter la SimInTech-testprojekto kaj la postula kontrolsistemo estas kiel sekvas:

1. La terminoj de referenco estas dividitaj en postulojn.
2. La postuloj de la teknikaj specifoj estas identigitaj, kiuj povas esti kontrolitaj per matematika modeligado de teknikaj procezoj.
3. Atributoj de la elektitaj postuloj estas transdonitaj al la signala datumbazo SimInTech en la strukturo de normaj blokoj (ekzemple, maksimuma kaj minimuma temperaturo).
4. Dum la kalkulprocezo, strukturdatenoj estas transdonitaj al blokdezajnodiagramoj, analizo estas farita kaj la rezultoj estas stokitaj en signala datumbazo.
5. Post kiam la kalkulo estas kompleta, la analizrezultoj estas transdonitaj al la postula administradsistemo.

Postulpaŝoj 3 ĝis 5 povas esti ripetitaj dum la dezajnprocezo kiam ŝanĝoj al la dezajno kaj/aŭ postuloj okazas kaj la efiko de la ŝanĝoj devas esti retestita.

Konkludoj.

• La kreita prototipo de la sistemo provizas signifan redukton en la tempo de analizo de ekzistantaj modeloj por plenumi la postulojn de la teknikaj specifoj.
• La proponita testa teknologio uzas jam ekzistantajn dinamikajn modelojn kaj povas esti uzata eĉ por iuj dinamikaj modeloj, inkluzive de tiuj ne faritaj en la SimInTech-medio.
• Uzado de grupa datumorganizo permesas krei postulajn konfirmpakaĵojn paralele kun modelevoluo, aŭ eĉ uzi ĉi tiujn pakaĵojn kiel teknikajn specifojn por modelevoluo.
• La teknologio povas esti integrita kun ekzistantaj postulaj administradsistemoj sen signifaj kostoj.

Por tiuj, kiuj legas ĝis la fino, ligo al video montranta kiel la prototipo funkcias.

fonto: www.habr.com