A műszaki specifikációk követelményeinek automatikus ellenőrzése a dinamikus modellezés során

A téma folytatása – Mi a bizonyítékod?, nézzük a matematikai modellezés problémáját a másik oldalról. Miután megbizonyosodtunk arról, hogy a modell megfelel az élet szőtt igazságának, megválaszolhatjuk a fő kérdést: „mi is van itt pontosan?” Egy műszaki objektum modelljének elkészítésekor általában meg akarunk győződni arról, hogy ez az objektum megfelel az elvárásainknak. Ebből a célból a folyamatok dinamikus számításait elvégzik, és az eredményt összehasonlítják a követelményekkel. Ez egy digitális iker, egy virtuális prototípus stb. divatos kisfiúk, akik a tervezési szakaszban megoldják azt a problémát, hogyan biztosítsuk, hogy azt kapjuk, amit elterveztünk.

Hogyan tudjuk gyorsan megbizonyosodni arról, hogy rendszerünk pontosan az, amit tervezünk, repülni vagy lebegni fog? És ha repül, milyen magasra? És ha lebeg, milyen mélyen?

Ez a cikk a műszaki épületek követelményeinek való megfelelés ellenőrzésének automatizálását tárgyalja a műszaki rendszerek dinamikus modelljei létrehozásakor. Példaként nézzük meg a repülőgép léghűtőrendszerének műszaki specifikációjának egy elemét.

Azokat a követelményeket vesszük figyelembe, amelyek számszerűen kifejezhetők és matematikailag igazolhatóak egy adott számítási modell alapján. Nyilvánvaló, hogy ez csak egy része az általános követelményeknek bármely műszaki rendszerrel szemben, de ezek ellenőrzésére fordítunk időt, idegeket és pénzt az objektum dinamikus modelljének elkészítésére.

A műszaki követelmények dokumentum formájú leírása során többféle követelmény különböztethető meg, amelyek mindegyike más-más megközelítést igényel a követelmények teljesülésének automatikus ellenőrzésének kialakításához.

Vegyük például ezt a kicsi, de reális követelményrendszert:

1. A légköri levegő hőmérséklete a vízkezelő rendszer bejáratánál:
   a parkolóban - mínusz 35 és 35 ºС között,
   repülés közben - mínusz 35 és 39 ºС között.
2. A légköri levegő statikus nyomása repülés közben 700-1013 GPa (526-760 Hgmm).
3. A teljes légnyomás az SVO légbeömlő bejáratánál repülés közben 754-1200 GPa (566-1050 Hgmm).
4. A hűtő levegő hőmérséklete:
   a parkolóban - legfeljebb 27 ºС, a műszaki blokkok esetében - legfeljebb 29 ºС,
   repülés közben - legfeljebb 25 ºС, műszaki blokkok esetén - legfeljebb 27 ºС.
5. Hűtő levegő áramlása:
   parkoláskor - legalább 708 kg/h,
   repülés közben - legalább 660 kg/h.
6. A műszerterekben a levegő hőmérséklete nem haladja meg a 60 ºС-ot.
7. A finom szabad nedvesség mennyisége a hűtőlevegőben nem több, mint 2 g/kg száraz levegő.

Még ezen a korlátozott követelményrendszeren belül is van legalább két kategória, amelyet másként kell kezelni a rendszerben:

• a rendszer működési feltételeire vonatkozó követelmények (1-3. pont);
• a rendszer paraméteres követelményei (3-7. pont).

A rendszer működési feltételeinek követelményei
A modellezés során kialakítandó rendszer külső feltételei megadhatók peremfeltételként vagy az általános rendszer működésének eredményeként.
A dinamikus szimulációnál gondoskodni kell arról, hogy a megadott működési feltételeket lefedje a szimulációs folyamat.

Paraméteres rendszerkövetelmények
Ezek a követelmények maga a rendszer által biztosított paraméterek. A modellezés során számítási eredményként megkaphatjuk ezeket a paramétereket, és minden egyes számításnál megbizonyosodhatunk a követelmények teljesüléséről.

Követelmények azonosítása és kódolása

A követelményekkel való munka megkönnyítése érdekében a meglévő szabványok azt javasolják, hogy minden követelményhez rendeljenek egy azonosítót. Az azonosítók hozzárendelésénél nagyon kívánatos az egységes kódrendszer alkalmazása.

A követelménykód lehet egyszerűen egy szám, amely a követelmény rendelési számát jelöli, vagy tartalmazhat a követelmény típusának kódját, annak a rendszernek vagy egységnek a kódját, amelyre vonatkozik, egy paraméterkódot, egy helykódot, és bármi mást, amit a mérnök el tud képzelni. (a kódolás használatáról lásd a cikket)

Az 1. táblázat egy egyszerű példát ad a követelmények kódolására.

1. a követelmények forrásának kódja R-követelmények TK;
2. kód típusú követelmények E - követelmények - környezeti paraméterek, vagy működési feltételek
   S - a rendszer által biztosított követelmények;
3. repülőgép állapotkód 0 – bármilyen, G – parkolt, F – repülés közben;
4. fizikai paraméter típuskódja T – hőmérséklet, P – nyomás, G – áramlási sebesség, páratartalom H;
5. a követelmény sorszáma.

ID Követelmények	Leírás	Paraméter
REGT01	Környezeti levegő hőmérséklete a vízhűtő rendszer bejáratánál: a parkolóban - mínusz 35ºС-tól. 35 ºС-ig.
REFT01	A légköri levegő hőmérséklete a légvédelmi rendszer bejáratánál: repülés közben - mínusz 35 ºС és 39 ºС között.
REFP01	A statikus légköri légnyomás repülés közben 700-1013 hPa (526-760 Hgmm).
REFP02	A teljes légnyomás az SVO légbeömlő bejáratánál repülés közben 754-1200 hPa (566-1050 Hgmm).
RSGT01	Hűtőlevegő hőmérséklet: parkoláskor legfeljebb 27 ºС
RSGT02	Hűtőlevegő hőmérséklet: parkolóban, műszaki egységeknél legfeljebb 29 ºС
RSFT01	A hűtőlevegő hőmérséklete repülés közben legfeljebb 25 ºС
RSFT02	A hűtőlevegő hőmérséklete: repülés közben, műszaki egységeknél legfeljebb 27 ºС
RSGG01	Hűtőlevegő áramlás: parkoláskor legalább 708 kg/h
RSFG01	Hűtő levegő áramlása: repülés közben legalább 660 kg/h
RS0T01	A levegő hőmérséklete a műszerterekben legfeljebb 60 ºС
RSH01	A finom szabad nedvesség mennyisége a hűtőlevegőben nem több, mint 2 g/kg száraz levegő

Követelmények ellenőrzési rendszer tervezése.

Minden tervezési követelményhez létezik egy algoritmus a tervezési paraméterek és a követelményben meghatározott paraméterek megfelelésének értékelésére. Általában véve minden vezérlőrendszer alapértelmezés szerint mindig tartalmaz algoritmusokat a követelmények ellenőrzésére. És még bármelyik szabályozó is tartalmazza ezeket. Ha a hőmérséklet túllépi a határértékeket, a légkondicionáló bekapcsol. Így minden szabályozás első lépése annak ellenőrzése, hogy a paraméterek megfelelnek-e a követelményeknek.

És mivel a hitelesítés egy algoritmus, ezért ugyanazokat az eszközöket és eszközöket használhatjuk, mint a vezérlőprogramok létrehozásához. Például a SimInTech környezet lehetővé teszi a modell különböző részeit tartalmazó projektcsomagok létrehozását, amelyeket külön projektek formájában hajtanak végre (objektummodell, vezérlőrendszer-modell, környezeti modell stb.).

A követelmény-ellenőrzési projekt ebben az esetben ugyanaz az algoritmusprojekt lesz, és a modellcsomaghoz kapcsolódik. A dinamikus modellezési módban pedig elemzést végez a műszaki specifikáció követelményeinek való megfelelés érdekében.

A rendszer kialakításának egy lehetséges példája az 1. ábrán látható.

1. ábra. Példa egy hitelesítési projekt kialakítására.

Csakúgy, mint a vezérlési algoritmusok esetében, a követelményeket lapkészletként is fel lehet állítani. Az olyan szerkezeti modellezési környezetekben, mint a SimInTech, Simulink, AmeSim, az algoritmusokkal való munka kényelme érdekében a többszintű struktúrák almodellek formájában történő létrehozásának lehetőségét használják. Ez a felépítés lehetővé teszi a különféle követelmények halmazokba történő csoportosítását, hogy egyszerűsítsék a munkavégzést egy sor követelményrendszerrel, ahogy az a vezérlőalgoritmusoknál történik (lásd 2. ábra).

2. ábra A követelményellenőrzési modell hierarchikus felépítése.

Például a vizsgált esetben két csoportot különböztetünk meg: a környezettel szemben támasztott követelményeket és a közvetlenül a rendszerrel szembeni követelményeket. Ezért kétszintű adatszerkezetet használunk: két csoportot, amelyek mindegyike az algoritmus levele.

Az adatok modellhez való csatlakoztatásához egy szabványos jeladatbázis létrehozására szolgáló sémát használnak, amely adatokat tárol a projekt részei közötti cseréhez.

Szoftver létrehozása és tesztelése során a vezérlőrendszer által használt szenzorok (valódi rendszerérzékelők analógjai) leolvasásai ebben az adatbázisban kerülnek elhelyezésre.
Egy tesztprojekt esetében a dinamikus modellben számított bármely paraméter tárolható ugyanabban az adatbázisban, és így ellenőrizhető, hogy a követelmények teljesülnek-e.

Ebben az esetben maga a dinamikus modell végrehajtható bármilyen matematikai modellező rendszerben, vagy akár futtatható program formájában is. Az egyetlen követelmény a modellezési adatok külső környezetbe történő kiadásához szükséges szoftveres interfészek megléte.

3. ábra: A hitelesítési projekt összekapcsolása a komplex modellel.

A 4. ábrán látható egy példa egy alapvető követelmény-ellenőrző lapra. A fejlesztő szemszögéből ez egy hagyományos számítási diagram, amelyen grafikusan bemutatjuk a követelményellenőrző algoritmust.

4. ábra Követelmények ellenőrző lapja.

Az ellenőrző lap főbb részeit az 5. ábra mutatja be. Az ellenőrző algoritmus a vezérlőalgoritmusok tervezési diagramjaihoz hasonlóan épül fel. A jobb oldalon van egy blokk az adatbázisból érkező jelek olvasására. Ez a blokk hozzáfér a jeladatbázishoz a szimuláció során.

A vett jeleket elemzik a követelmények ellenőrzési feltételeinek kiszámításához. Ebben az esetben magasságelemzést végeznek a repülőgép helyzetének meghatározására (akár parkol, akár repülés közben). Erre a célra használhatja a modell egyéb jeleit és számított paramétereit.

Az ellenőrzött hitelesítési feltételek és paraméterek átkerülnek a szabványos hitelesítési blokkokba, amelyekben ezeket a paramétereket elemzik, hogy megfelelnek-e a meghatározott követelményeknek. Az eredmények úgy kerülnek rögzítésre a jeladatbázisban, hogy azokból automatikusan ellenőrző lista generálható legyen.

5. ábra Követelményellenőrző számítási lap felépítése.

A vizsgálandó paraméterek nem feltétlenül használnak az adatbázisban található jeleket, amelyeket a szimulációs folyamat során számított paraméterek vezérelnek. Semmi sem akadályoz bennünket abban, hogy a tervezet követelményeinek keretein belül további számításokat végezzünk, ahogy az igazolási feltételeket is.

Például ez a követelmény:

A korrekciós rendszer aktiválódásainak száma a célba repülés során nem haladhatja meg az 5-öt, a korrekciós rendszer teljes működési ideje pedig nem haladhatja meg a 30 másodpercet.

Ebben az esetben az indítások számát és a teljes üzemidőt ellenőrző algoritmus hozzáadódik a követelmények tervezési diagramjához.

Tipikus követelmények ellenőrzési blokk.

Minden szabványos követelmény jelölőnégyzet egy bizonyos típusú követelmény teljesítésének kiszámítására szolgál. Például a környezetvédelmi követelmények egy sor környezeti üzemi hőmérsékletet foglalnak magukban parkoláskor és repülés közben. Ennek a blokknak meg kell kapnia a modellben lévő levegő hőmérsékletét paraméterként, és meg kell határoznia, hogy ez a paraméter lefedi-e a megadott hőmérsékleti tartományt./p>

A blokk két bemeneti portot tartalmaz, a paramétert és a feltételt.

Az elsőt az ellenőrzött paraméterrel tápláljuk. Ebben az esetben a „Külső hőmérséklet”.

A második portra egy logikai változó kerül – az ellenőrzés végrehajtásának feltétele.

Ha a második bemeneten IGAZ (1) érkezik, akkor a blokk követelményellenőrző számítást hajt végre.

Ha a második bemenet FALSE (0) értéket kap, akkor a tesztfeltételek nem teljesülnek. Erre azért van szükség, hogy a számítási feltételeket figyelembe lehessen venni. Esetünkben ez a bemenet szolgál az ellenőrzés engedélyezésére vagy letiltására a modell állapotától függően. Ha a repülőgép a szimuláció során a földön tartózkodik, akkor a repüléssel kapcsolatos követelmények nem kerülnek ellenőrzésre, és fordítva - ha a repülőgép repülésben van, akkor az állóhelyi üzemeltetéssel kapcsolatos követelmények nem kerülnek ellenőrzésre.

Ez a bemenet a modell felállításakor is használható, például a számítás kezdeti szakaszában. Amikor a modellt a kívánt állapotba hozzuk, az ellenőrző blokkok letiltásra kerülnek, de amint a rendszer eléri a kívánt üzemmódot, az ellenőrző blokkok bekapcsolódnak.

Ennek a blokknak a paraméterei a következők:

• peremfeltételek: felső (UpLimit) és alsó (DownLimit) tartományhatárok, amelyeket ellenőrizni kell;
• a rendszer szükséges megvilágítási ideje a határtartományokban (TimeInterval) másodpercben;
• Request ID ReqName;
• a tartomány túllépésének megengedettsége Out_range egy logikai változó, amely meghatározza, hogy az ellenőrzött tartományt meghaladó érték megsérti-e a követelményt.

Egyes esetekben a tesztérték kimenete azt jelzi, hogy a rendszernek van némi tartaléka, és előfordulhat, hogy a működési tartományán kívül működik. Más esetekben a kimenet azt jelenti, hogy a rendszer nem tudja tartományon belül tartani az alapjeleket.

6. ábra Egy tipikus tulajdonság-ellenőrző blokk a diagramban és paraméterei.

A blokk számításának eredményeként a kimeneten az Eredmény változó jön létre, amely a következő értékeket veszi fel:

• 0 – rNincs, érték nincs megadva;
• 1 – rKész, a követelmény teljesül;
• 2 – rHiba, a követelmény nem teljesül.

A blokkkép a következőket tartalmazza:

• azonosító szöveg;
• mérési határértékek paramétereinek digitális kijelzői;
• a paraméter állapotának színazonosítója.

A blokkon belül egy meglehetősen összetett logikai következtetési áramkör lehet.

Például a 6. ábrán látható egység üzemi hőmérséklet-tartományának ellenőrzéséhez a belső áramkört a 7. ábra mutatja.

7. ábra A hőmérséklet-tartomány-meghatározó egység belső diagramja.

Az áramköri blokkon belül a blokkparaméterekben megadott tulajdonságok kerülnek felhasználásra.
A blokk belső diagramja a követelmények betartásának elemzése mellett a szimulációs eredmények megjelenítéséhez szükséges grafikont is tartalmazza. Ez a grafikon a számítás közbeni megtekintésre és az eredmények számítás utáni elemzésére egyaránt használható.

A számítási eredmények továbbításra kerülnek a blokk kimenetére, és egyidejűleg rögzítésre kerülnek egy általános jelentésfájlban, amely a teljes projekt eredményei alapján jön létre. (lásd 8. ábra)

A szimulációs eredmények alapján készített jelentésre példa egy adott formátum szerint készített html fájl. A formátum tetszőlegesen beállítható egy adott szervezet által elfogadott formátumra.

Az áramköri blokkon belül a blokkparaméterekben megadott tulajdonságok kerülnek felhasználásra.
A blokk belső diagramja a követelmények betartásának elemzése mellett a szimulációs eredmények megjelenítéséhez szükséges grafikont is tartalmazza. Ez a grafikon a számítás közbeni megtekintésre és az eredmények számítás utáni elemzésére egyaránt használható.

A számítási eredmények továbbításra kerülnek a blokk kimenetére, és egyidejűleg rögzítésre kerülnek egy általános jelentésfájlban, amely a teljes projekt eredményei alapján jön létre. (lásd 8. ábra)

A szimulációs eredmények alapján készített jelentésre példa egy adott formátum szerint készített html fájl. A formátum tetszőlegesen beállítható egy adott szervezet által elfogadott formátumra.

8. ábra. Példa egy szimulációs eredményeken alapuló jelentésfájlra.

Ebben a példában a jelentésűrlap közvetlenül a projekttulajdonságokban van konfigurálva, és a táblázat formátuma globális projektjelként van beállítva. Ebben az esetben a SimInTech maga oldja meg a jelentés beállításának problémáját, és az eredmények fájlba írásának blokkja ezeket a sorokat használja a jelentésfájlba való íráshoz.

9. ábra: Jelentésformátum beállítása globális projektjelekben

Jeladatbázis használata a követelményekhez.

A tulajdonságbeállításokkal végzett munka automatizálása érdekében minden tipikus blokkhoz szabványos struktúra jön létre a jeladatbázisban. (lásd 10. ábra)

10. ábra Példa egy követelmény-ellenőrző blokk felépítésére egy jeladatbázisban.

A jeladatbázis a következőket nyújtja:

• Az összes szükséges rendszerkövetelmény-paraméter tárolása.
• A meglévő projektkövetelmények kényelmes megtekintése a megadott paraméterek és az aktuális modellezési eredmények alapján.
• Egy blokk vagy blokkcsoport beállítása script programozási nyelv használatával. A jeladatbázis változásai a diagram blokktulajdonság-értékeinek változásához vezetnek.
• Szöveges leírások, a műszaki specifikáció elemeire mutató hivatkozások vagy azonosítók tárolása a követelménykezelő rendszerben.

A követelményekhez tartozó jeladatbázis-struktúrák könnyen konfigurálhatók úgy, hogy egy harmadik féltől származó követelménykezelő rendszerrel működjenek A követelménykezelő rendszerekkel való interakció általános diagramja a 11. ábrán látható.

11. ábra: A követelménykezelő rendszerrel való interakció diagramja.

A SimInTech tesztprojekt és a követelményvezérlő rendszer közötti interakció sorrendje a következő:

1. A feladatmeghatározás követelményekre van lebontva.
2. A műszaki leírások követelményeit azonosítják, amelyek a műszaki folyamatok matematikai modellezésével ellenőrizhetők.
3. A kiválasztott követelmények attribútumai szabványos blokkok struktúrájában kerülnek át a SimInTech jeladatbázisba (például maximális és minimális hőmérséklet).
4. A számítási folyamat során a szerkezeti adatok blokktervezési diagramokba kerülnek, elemzésre kerül sor, az eredményeket pedig egy jeladatbázisban tárolják.
5. A számítás befejezése után az elemzési eredmények átkerülnek a követelménykezelő rendszerbe.

A követelmények 3–5. lépései megismételhetők a tervezési folyamat során, ha a tervezésben és/vagy a követelményekben változás történik, és a változtatások hatását újra kell tesztelni.

Következtetések.

• A rendszer megalkotott prototípusa jelentősen csökkenti a meglévő modellek elemzési idejét a műszaki specifikáció követelményeinek való megfelelés érdekében.
• A javasolt tesztelési technológia már meglévő dinamikus modelleket használ, és bármilyen dinamikus modellhez is használható, beleértve azokat is, amelyeket nem a SimInTech környezetben hajtanak végre.
• A kötegelt adatszervezés használatával a modellfejlesztéssel párhuzamosan igényellenőrző csomagokat hozhat létre, vagy akár modellfejlesztési műszaki specifikációként is használhatja ezeket a csomagokat.
• A technológia jelentős költségek nélkül integrálható a meglévő követelménykezelő rendszerekkel.

Azoknak, akik a végéig elolvasták, link egy videóra, amely bemutatja a prototípus működését.

Forrás: will.com