A követelmények automatikus ellenőrzése a dinamikus modellezés során

A téma folytatásaként «Mik a bizonyítékaitok?», nézzük meg a matematikai modellezés problémáját egy másik szemszögből. Miután megbizonyosodtunk arról, hogy a modell megfelel a valós élet kíméletlen igazságának, válaszolhatunk a fő kérdésre: „mit is jelent ez valójában itt számunkra?”. Amikor egy technikai objektum modellt létrehozunk, általában szeretnénk megbizonyosodni arról, hogy ez az objektum összhangban lesz a várakozásainkkal. Ennek érdekében dinamikus számításokat végeznek, és az eredményeket a követelményekkel hasonlítják össze. Ez a digitális másolat, a virtuális prototípus és egyéb trendi dolgok, amelyek a tervezési szakaszban azt a feladatot oldják meg, hogy megkapjuk azt, amit terveztünk.

Hogyan tudjuk gyorsan megbizonyosodni arról, hogy a rendszerünk pontosan az, amit tervezünk, repülni fog vagy úszni, a konstrukciónk? Ha repül, milyen magasra? Ha úszik, milyen mélyre?

A cikkben a technikai épület követelményeinek automatikus ellenőrzését vizsgáljuk a technikai rendszerek dinamikus modelljeinek létrehozásakor. Példaként nézzük meg a légi jármű levegőhűtési rendszerére vonatkozó műszaki követelmények egyik elemét.

Azokat a követelményeket vizsgáljuk, amelyeket numerikusan kifejezhetünk, és matematikailag ellenőrizhetünk egy konkrét számítási modell alapján. Nyilvánvaló, hogy ezek csupán a technikai rendszerek általános követelményeinek egy részét képezik, de éppen ennek az ellenőrzésére költjük az időnket, idegeinket és pénzünket a dinamikus modellek létrehozásához.

A műszaki követelmények dokumentumban való leírásakor több különböző követelményfajtát is kiemelhetünk, mindegyik más-más megközelítést igényel a követelmények automatikus ellenőrzésének kialakításához.

Például nézzük meg ezt a kicsi, de valós követelménysort:

1. A légkör hőmérséklete a SVO bemeneténél:
   parkolóban − mínusz 35 és 35 ºC között,
   repülés közben − mínusz 35 és 39 ºC között.
2. A légkör statikus nyomása repülés közben − 700 és 1013 GPa között (526 és 760 mmHg között).
3. A légnyomás a SVO levegőbevezetőjénél repülés közben − 754 és 1200 GPa között (566 és 1050 mmHg között).
4. A hűtőlevegő hőmérséklete:
   parkolóban − nem több mint 27 ºC, a műszaki blokkok számára − nem több mint 29 ºC,
   repülés közben − legfeljebb 25 ºC, a technikai blokkok számára − legfeljebb 27 ºC.
5. Hűtőlevegő fogyasztás:
   parkoló állapotban − legalább 708 kg/h,
   repülés közben − legalább 660 kg/h.
6. A műszaki rekeszek levegőmérséklete − legfeljebb 60 ºC.
7. A ködös, szabad víz mennyisége a hűtőlevegőben − legfeljebb 2 g/kg száraz levegő.

Még ilyen korlátozott követelményrendszer esetén is legalább két kategóriát lehet kiemelni, amelyeket különböző módon kell kezelni a rendszerben:

• a rendszer üzemeltetési körülményei (1-3. pont);
• a rendszer paraméteres követelményei (3-7. pont).

A rendszer üzemeltetési körülményei
A tervezett rendszer külső körülményei modellezés során határfeltételekként, vagy a teljes rendszer működésének eredményeként adhatók meg.
Dinamikus modellezés esetén meg kell győződni arról, hogy a megadott működési módok lefedésre kerülnek a modellezési folyamattal.

A rendszer paraméteres követelményei
Ezek a követelmények a rendszer által biztosított paraméterek. A modellezés során ezeket a paramétereket számítási eredményként kaphatjuk meg, és ellenőrizhetjük, hogy a követelmények minden egyes számításnál teljesülnek.

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

A követelményekkel való munka megkönnyítése érdekében a létező szabványok javasolják, hogy minden követelménynek azonosítót rendeljünk. Az azonosítók hozzárendelésekor nagyon kívánatos egy egységes kódolási rendszer használata.

A követelmény kódja lehet egyszerű szám, amely a követelmény sorrendi számát tükrözi, vagy tartalmazhatja a követelménytípus kódját, a rendszer vagy aggregátum kódját, amelyre vonatkozik, a paraméter kódját, a hely kódját és egyebeket, amiket csak a mérnök elképzelhet. (a kódolási használati példákat lásd a cikkben)

Az 1. táblázatban egy egyszerű követelménykódolási példát talál.

1. a követelmény forrásegyesítő kódja R - műszaki követelmények;
2. a követelménytípus kódja E - követelmények - a külső környezet paraméterei, vagy az üzemeltetési körülmények
   S - a rendszer által biztosított követelmények;
3. a repülőgép állapotának kódja 0 - bármely, G - parkoló, F - repülés közben;
4. a fizikai paraméterek típusának kódja T - hőmérséklet, P - nyomás, G - átáramlás, H - páratartalom;
5. a követelmény sorszáma.

A követelmények ellenőrzésének rendszere.

Minden egyes számított követelményhez van egy értékelési algoritmus, amely az értékelt paramétereket és a követelményben megadott paramétereket összeveti. Alapvetően bármely irányító rendszer tartalmazza a követelmények ellenőrzésének algoritmusait alapértelmezés szerint. Sőt, bármely szabályozó is tartalmazza ezeket. Ha a hőmérséklet a határértéken túllép, a légkondicionáló bekapcsol. Így bármilyen szabályozás első lépése a paraméterek követelményhez való megfelelőségének ellenőrzése.

Mivel az ellenőrzés algoritmus, ugyanazokat az eszközöket és módszereket lehet használni, amelyeket a vezérlőrendszerek létrehozásához használunk. Például a SimInTech környezet lehetővé teszi projektcsomagok létrehozását, amelyek különböző modellrészeket tartalmaznak, amelyeket külön projektek formájában valósítanak meg (objektum modellje, vezérlőrendszer modellje, környezeti modell stb.).

A követelmények ellenőrzésének projektje így algoritmusok projektjévé válik, és csatlakozik a modellcsomaghoz. Dinamikus modellezési üzemmódban a követelményeknek való megfelelőségi elemzést hajt végre.

Egy lehetséges projektbemutatási példa a rendszer számára a 1. ábrán látható.

1. ábra. A követelmények ellenőrzésének projektjének példája.

A követelmények vezérlési algoritmusaihoz hasonlóan, ezeket is lehet lapok halmazaként megformálni. A vezérlési algoritmusokkal való munka megkönnyítése érdekében olyan struktúrált modellezési környezetekben, mint a SimInTech, Simulink, AmeSim, több szintű szerkezetek létrehozására van lehetőség almodellek formájában. Ez a szervezési forma lehetővé teszi a különböző követelmények halmazokba való csoportosítását, hogy a követelmények tömegével való munka egyszerűbb legyen, akárcsak a vezérlési algoritmusok esetében (lásd a 2. ábrát).

2. ábra. A követelmények ellenőrzési modelljének hierarchikus struktúrája.

Például a vizsgált esetben két csoportot azonosítottak: a környezeti követelmények és közvetlenül a rendszerhez kapcsolódó követelmények. Ezért egy kétszintű adatstruktúra használata szükséges: két csoport, mindkettő az algoritmus egyik lapját képezi.

Az adatok modellezéséhez egy standard signal database construct eljárás használatos, amely tárolja az adatokat a projekt különböző részei között való kommunikációhoz.

Szoftver készítése és tesztelése során ebbe az adatbázisba kerülnek a szenzorok (a rendszer valós szenzorainak analógjai) mérései, amelyek a vezérlőrendszer által használtak.
A tesztelési projekthez kapcsolódóan ebben az adatbázisban bármilyen paraméter képes megőrződni, amelyek a dinamikus modellben számíthatók, és így felhasználhatóak a követelmények teljesítésének ellenőrzésére.

Magának a dinamikus modellnek ez esetben bármilyen matematikai modellező rendszerben megvalósíthatónak kell lennie, vagy akár futtatható programként is. Az egyetlen követelmény – a modellezési adatok külső környezetbe való kiadásához programozási interfészek megléte.

3. ábra. A tesztelési projekt csatlakoztatása a komplex modellhez.

A követelmények ellenőrzésének alaplapja a 4. ábrán látható. A fejlesztő szempontjából ez egy szokásos számítási séma, amely grafikus formában mutatja a követelmények ellenőrzésének algoritmusát.

4. ábra. A követelmények ellenőrzési lapja.

A követelmények ellenőrzési lap főbb részei az 5. ábrán láthatók. Az ellenőrzési algoritmus hasonlóan épül fel, mint a vezérlési algoritmusok számítási sémai. A jobb oldalon található egy blokk a jeladatok olvasásához az adatbázisból. Ebben a blokban történik a jeladatbázis elérése a modellezés ideje alatt.

A kapott jeleket elemzik a követelmények ellenőrzési feltételeinek kiszámítására. A vizsgált esetben a magasság elemzése történik a repülőgép helyzetének meghatározására (parkolóban van vagy repül). E célra más jelek és a modell által számított paraméterek is használhatók.

A tesztelési feltételek és az ellenőrzött paraméterek átkerülnek a standard ellenőrzési blokkokba, ahol az ezen paraméterek adatainak elemzése történik a megadott követelményeknek való megfelelés érdekében. Az eredményeket a jelek adatbázisába rögzítik úgy, hogy azokat automatikusan fel lehessen használni egy ellenőrző lista létrehozásához.

5. ábra. A követelmények ellenőrző lapjának felépítése.

Ellenőrzött paraméterként nem kötelező csak a modellben található, a modellezés során számított paraméterekkel vezérelt jeleket használni. Semmi sem akadályozza meg, hogy a követelmények projekt keretein belül további számításokat végezzünk, ahogy az ellenőrzési feltételeket kiszámítjuk.

Például egy ilyen követelmény:

A korrigáló rendszer beindításainak száma a célhoz való repülés során nem haladhatja meg az 5-öt, és a korrigáló rendszer összes működési ideje nem haladhatja meg a 30 másodpercet.

Ebben az esetben a követelmények számítási sémájához hozzáadódik a beindítások számának és az összes működési időnek a számláló algoritmusa.

Standard követelményellenőrző blokk.

Minden standard követelményellenőrző blokk egy adott típusú követelmény teljesítése számítására szolgál. Például a környezeti követelmények között szerepel a környezeti levegő működési hőmérsékletének tartománya parkolóban és repülés közben. Ennek a blokknak meg kell kapnia a levegő hőmérsékletét paraméterként a modellből, és meg kell határoznia, hogy ez a paraméter fedezi-e a megadott hőmérsékleti tartományt.

A blokk két bemeneti porttal rendelkezik, param és condition.

Az első bemenetre az ellenőrzött paraméter kerül. Ebben az esetben a „Külső környezet hőmérséklete”.

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

Ha a második bemenetre TRUE (1) érkezik, akkor a blokk megkezdi a követelmény ellenőrzésének számítását.

Ha a második bemenet FALSE (0) értéket kap, akkor a vizsgálati feltételek nem teljesülnek. Ez szükséges ahhoz, hogy figyelembe lehessen venni a számítási feltételeket. A mi esetünkben ezt a bemenetet használjuk a vizsgálat engedélyezésére vagy letiltására a modell állapotának függvényében. Ha az LÁ a modellezés során a földön van, akkor a repülésre vonatkozó követelmények nem ellenőrződnek, és fordítva - ha az LÁ repül, akkor a parkolásra vonatkozó követelmények nem ellenőrződnek.

Ezt a bemenetet a modell beállításainál is használhatjuk, például a számítás kezdeti szakaszában. Amikor a modellt a kívánt állapotba hozzák, a vizsgálati blokk letiltott, de amint a rendszer eléri a kívánt működési módot, a vizsgálati blokkok aktiválódnak.

A blokk paraméterei a következők:

• határfeltételek: felső (UpLimit) és alsó (DownLimit) határok, amelyeket ellenőrizni kell;
• a rendszernek a határértékeken való tartózkodásának szükséges ideje (TimeInterval) másodpercekben;
• a követelmény azonosítója ReqName;
• a határok túllépésének elfogadhatósága Out_range – egy logikai változó, amely meghatározza, hogy a vizsgált érték túllépése a követelmény megsértése-e.

Egyes esetekben a vizsgált érték túllépése azt jelenti, hogy a rendszernek van tartaléka, és működhet a munkatartományon kívül. Más esetekben a túllépés azt jelenti, hogy a rendszer nem képes megtartani a megadott paramétereket a tartományon belül.

6. ábra. A vizsgálati blokk típusa a sémán és annak paraméterei.

A blokk számítása során a kimeneten a Result változó alakul ki, amely a következő értékeket veheti fel:

• 0 – rNone, az érték nincs meghatározva;
• 1 – rDone, a követelmény teljesül;
• 2 – rFault, a követelmény nem teljesül.

A blokk képe tartalmazza:

• az azonosító szövege;
• a mérési határok digitális megjelenítése;
• az állapotparaméter színes azonosítója.

A blokk belsejében elég bonyolult logikai következtetési séma található.

Például a 6. ábrán bemutatott blokk működési tartományának hőmérsékletvizsgálatára a belső séma a 7. ábrán látható.

7. ábra. A hőmérséklet-tartomány meghatározásának belső sémája.

A blokk sémáiban a blokk paramétereibe megadott tulajdonságok használatosak.
A követelményeknek való megfelelés elemzése mellett a belső blokk sémája tartalmazza azt a grafikont, amely szükséges a modellezési eredmények megjelenítéséhez. Ez a grafikon használható a számítások során, valamint az eredmények utólagos elemzésére is.

A számítás eredményei a blokk kimenetére kerülnek, és egy időben rögzítésre kerülnek egy általános jelentésfájlban, amely a projekt teljes eredményei alapján készül. (lásd 8. ábra)

A modellezés eredményei alapján készült jelentés példája egy html fájl, amely a megadott formátum szerint készül. A formátum tetszőlegesen testreszabható a konkrét szervezet által elfogadott formátumra.

A blokk sémáiban a blokk paramétereibe megadott tulajdonságok használatosak.
A követelményeknek való megfelelés elemzése mellett a belső blokk sémája tartalmazza azt a grafikont, amely szükséges a modellezési eredmények megjelenítéséhez. Ez a grafikon használható a számítások során, valamint az eredmények utólagos elemzésére is.

A számítás eredményei a blokk kimenetére kerülnek, és egy időben rögzítésre kerülnek egy általános jelentésfájlban, amely a projekt teljes eredményei alapján készül. (lásd 8. ábra)

A modellezés eredményei alapján készült jelentés példája egy html fájl, amely a megadott formátum szerint készül. A formátum tetszőlegesen testreszabható a konkrét szervezet által elfogadott formátumra.

8. ábra. A modellezés eredményeihez készült jelentés fájl példája.

Ebben a példában a jelentés formátumának beállítása közvetlenül a projekt tulajdonságaiban történik, míg a formátum a táblázatban globális jelekként van megadva. Ebben az esetben a SimInTech automatikusan megoldja a jelentés beállításának feladatát, és a fájlba történő eredményjegyzés blokkja ezeket a sorokat használja a jelentés fájlba történő íráshoz.

9. ábra. A projekt globális jeleinek jelentésformátumának beállítása

Jeladatalap használata a követelményekhez.

A minden egyes típusú blokk tulajdonság-beállításainak automatizálása érdekében típusos struktúra készül a jeladatalapban. (lásd 10. ábra)

10. ábra. A követelményellenőrző blokk példájaként a jeladatalapban.

A jeladatalap biztosítja:

• Minden szükséges rendszerkövetelmény paraméterének tárolása.
• A projektben lévő követelmények meglévő paramétereiből és a modell jelenlegi eredményeiből kényelmes megjelenítés.
• Egy blokk vagy blokkcsoport konfigurálása programozási scripting nyelv használatával. A jeladatalapban végzett módosítások a blokk sémájának tulajdonságainak értékeiben változást eredményeznek.
• Szöveges leírások tárolása, hivatkozások a műszaki specifikációk pontjaira vagy az azonosítók a követelménykezelő rendszerben.

A követelményekhez kapcsolódó jeladatalap struktúrái könnyen testreszabhatók harmadik fél követelménykezelő rendszerével való együttműködéshez, az interakció általános sémáját a 11. ábra mutatja be.

11. ábra. A követelménykezelő rendszerrel való interakciós séma.

A SimInTech tesztelési projekt kölcsönhatásának folyamata a következőképpen zajlik:

1. A műszaki specifikáció követelményekre bontása történik.
2. Azokat a műszaki specifikációs követelményeket emelik ki, amelyeket matematikai modellezéssel ellenőrizni lehet.
3. A kiemelt követelmények attribútumait a SimInTech jeladatbázisába továbbítják a tipikus blokkok struktúráiba (például maximális és minimális hőmérséklet).
4. A számítás folyamán a struktúrák adatai a blokkok számítási sémáiba kerülnek, elemzés történik, és az eredmények a jeladatbázisba mentésre kerülnek.
5. A számítás befejezése után az elemzési eredmények a követelmények kezelésére szolgáló rendszerbe kerülnek.

A követelményekkel való munka 3-5-ös lépései megismételhetők a tervezés során, amikor változások történnek a szerkezetben és/vagy a követelményekben, és így szükség van a végrehajtott változtatások hatásának újbóli ellenőrzésére.

Következtetések.

• A létrehozott rendszer prototípusa jelentős időmegtakarítást biztosít a meglévő modellek követelményeknek való megfelelőségének elemzése során.
• A javasolt tesztelési technológia már létező dinamikai modelleket használ, és bármilyen dinamikai modellhez alkalmazható, beleértve azokat is, amelyeket nem a SimInTech környezetében készítettek.
• Az adatok csomagolt szervezésének használata lehetővé teszi, hogy a követelmények ellenőrzésére szolgáló csomagokat párhuzamosan hozzák létre a modellek kidolgozása során, vagy akár a csomagokat műszaki specifikációként használják a modellek fejlesztéséhez.
• A technológia jelentős költségek nélkül integrálható a meglévő követelménykezelő rendszerekkel.

Akik végigolvassák, link egy videóra, amely bemutatja a prototípus működését.

Forrás: habr.com