Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei V&V folyamatok Eszközintegrációs szintek. Megfelelőség tanúsítása modell alapon

Átírás

1 Megfelelőség tanúsítása modell alapon Dr. Polgár Balázs Miről lesz szó? 2 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamatok Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 3 1

2 Biztonságkritikus job OS támogató réteg Végrehajtó környezet Partíciók OS támogató réteg Szenzorok/beavatkozók Virtuális átjárók OS tám. I/O Fizikai átjárók OS tám. DECOS Hálózat Kommunikációs Layered TTP - LTTP vezérlo (L-Flexray) HFTL * Csomagolás összehasonlítás Layer - HFTL Védett osztott memória FPGA kártya (Xilinx Virtex4) Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamatok Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 4 Cél Kidolgozott technológia validálása architektúra modell, alap és magas szintű szolgáltatások, hardver,... Nem biztonságkritikus job Nem biztonságkritikus job HW Fault-Tolerance Alap Core operációs Operating rendszer System (COS) (COS) Technológia használatával fejlesztett alkalmazások validálása 5 Cél pontosítása Keretrendszer kidolgozása, mely támogatja a teljes ellenőrzési folyamatot, képes külső ellenőrző et integrálni nyílt, könnyen bővíthető Az ellenőrzési (verifikációs-validációs ) folyamat követelmény-vezérelt biztonsági, minőségi szabványokra épül megoldja az alábbi lépéseket: feladatkiadás eredménybegyűjtés eredménykiértékelés 6 2

3 Különböző szabványokat kell tudni kezelni a fázisban. Technológiára vonatkoznak Hogyan kell felépülnie a fejlesztési folyamatnak? Komponensek ellenőrzésére vonatkoznak Mit hogyan kell validálni? 7 Különböző szabványokat kell tudni kezelni a fázisban. Autóipar ISO/IEC 61508, ISO WD Repülőgépipar DO 178B, DO 160D, MIL-STD-461E Ipari folyamatvezérlés IEC 61511, IEC 61131, EMC-directive 89/336/EC Egyebek: EN 50129, IEC 62061, IEC Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamat Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 9 3

4 Megoldandó feladatok 1. ban megfogalmazott általános metodikai előírások lefordítása egy ellenőrzési folyamatra workflow lépései minél magasabb fokon automatizálhatók legyenek feladatkiadás adatmozgatás határidőfigyelés eredménybegyűjtés eredménykiértékelés DOORS-ban implementálva meglévő workflow-modellek készen átvehetők 10 Megoldandó feladatok 2. Ellenőrzési folyamat finomítása elemi lépésekre Elemi lépésekhez tartozó ellenőrző et integrálni kell Tapasztalatok szerint az integrációja ugyanannyiba szokott kerülni, mint maga az összértéke MQ-t használjuk, fölötte workflow motor 3. Központi modellek harmonizálása az ellenőrző, mérési környezetek saját modellezési nyelvével modelltranszformációs probléma megvalósítás VIATRA-val 11 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamat Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 12 4

5 Toolchain verifikációs része 1. lépés: Ellenőrzési folyamat definiálása Megvalósulás: validációs terv (V-terv) Technológiafejlsztés során kell elkészíteni 2. lépés: Ellenőrzési folyamat végrehajtása sorozata részben technológiafejlsztés során részben alkalmazásfejlesztés során 2.a lépés: Ellenőrző eszköz bemeneti modelljének előállítása Központi modellek transzformációja 2.b lépés: Egy ellenőrzési lépés ( tevékenység) végrehajtása 13 Külső teszt 14 Függőleges irány: tartalmazza vagy használja Külső teszt 15 5

6 Vízszintes irány: információáramlás Külső teszt 16 Biztonsági eset Általános tesztkörnyezet Tesztelendő a keretrendszer elem specifikus Bizonyítja, hogy az adott elem megfelelően biztonságos Külső teszt 17 specifikus Tartalmazza a teljesítendő követelmények listáját Leírja a kapcsolódó et Metainformációkat tartalmaz (pl. felelős) Külső teszt 18 6

7 Példa: PIM validálása Külső teszt 19 Pl. a már említettek Eszközök Köztes réteg (middleware) Hardver Modellek (pl. PIM) Alkalmazások Külső teszt Pl. autóiparban SIL3-as szintet kell elérni, repülőgépiparban SIL4 a követelmény RACER bemeneti modelljének előállítása 2. RACER futtatása Pl. PIM validálása RACER-rel Külső teszt 21 7

8 Például: ITEM (Veszély és kockázat analízis) RACER (Formális verifikáció) SCADE MTC (Szimuláció) LDRA (Tesztelés) PROPANE (Hibainjektálás) EMI teszt környezet Külső teszt Egy DECOS elem konkrét megvalósulása (pl. egy adott PIM modell) 22 Külső teszt 23 Külső teszt 24 8

9 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamat Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 25 Fejlesztési és folyamat kapcsolódása 26 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamat Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 27 9

10 Általános tesztkörnyezet integrációja Eszközintegrációs szintek Nincs külső eszköz: pl. ellenőrző lista Eszköz DOORS-ban implementálva Kézzel végrehajtott külső eszköz: pl. PROPANE (SWIFI) Eszköz indítása dialógusablakban ( adott gomb megnyomásával ) Automatikusan végrehajtott külső eszköz: pl. RACER (Ontologia alapú konzisztencia és teljesség ellenőrzés) Eszköz indítása a megfelelő szervernek küldött üzenettel (felhasználói közreműködésre nincs szükség) Külső tesztkörnyezet: pl. EMI Hardware Test Bench Az eszköz különálló hardveren fut, visszacsatolás lel vagy üzenettel 28 Példa DOORS-ban implementált ellenőrző listára 29 Példa kézzel végrehajtott külső eszközre (LDRA) 30 10

11 Példa automatikusan végrehajtott külső eszközre PIM validáció Racerrel ellenőrzendő PIM 31 Általános felépítés (példa: PIM ellenőrzés RACER-rel) 32 Példa távoli, külső tesztkörnyezet kézi integrációjára EMI Hardver teszt és szimuláció tesztbemenet laborba elküldve en + referencia az adatra részletes DUT (Device Under Test) leírás EMC jelenség tesztelése DUT felhasználótól kerül a laborba tesztberendezés a tesztbemenetnek megfelelően kerül beállításra tesztek kézzel' kerülnek végrehajtásra a laborban teszteredmények en visszaküldve Bemenet és kimenet formátuma szabványosítva 33 11

12 Tartalom Célkitűzés Megoldandó feladatok A tesztkörnyezet komponensei folyamat Eszközintegrációs szintek Megfelelőségtanúsítás ontológia alapon 34 Modellezési folyamat részeként 1. nyelveket tervezünk technológiatervezés domain specifikus nyelvek (metamodellek) követelményleírásokkal kiegészítve (pl. OCL kényszerek) Technológia tervezés UML SySML DECOS 2. adott nyelven modellezünk alkalmazástervezés metamodellek példányai Alkalmazás tervezés MODEL 35 Feladat 1. Megtervezett nyelvek konzisztenciáját ellenőrizni kell pl. nincs körkörös tartalmazás a nyelvi elemek között pl. nincs kielégíthetetlen nyelvi elem metamodell konzisztenciájának ellenőrzése 2. Domain specifikus modellt (alkalmazásmodellt) ellenőrizni kell adott nyelven van-e leírva (metamodellnek való megfelelőség) konzisztens-e teljes-e extra követelményeket kielégíti-e Ontológiák használata 36 12

13 Az ontológiákat általában tudásreprezentációra használják. Tipikus felhasználási területek: mesterséges intelligencia szemantikus web Leírásuk leíró logikákkal (description logic) történik következtetőgépek ezek fölött működnek ilyen pl. a RACER Ontológia Olyan adatmodell, ami egy domain-t jelenít meg és a használata támogatja a következtetéseket a domain objektumaival és a köztük lévő relációkkal kapcsolatban. Az ontológiák az alábbi főbb elemekből állnak: Indivídumok: alap szintű objektumok Osztályok: halmazok, gyűjtemények vagy objektumtípusok Attribútumok: tulajdonság, karakterisztika vagy paraméter, amivel az objektum rendelkezhet Relációk: objektumok közti kapcsolatok 37 Eredmény Konzisztens metamodellek (nyelvek) a technológiafejlesztés folyamán A nyelv minden modellje bizonyítottan konzisztens lesz Eszköz az alkalmazásmodellek ellenőrzésére metamodellnek való megfelelés konzisztensség, teljesség extra kényszerek ellenőrzése (pl. multiplicitás, logikai, strukturális) Számszerűségek ellenőrzése Modell elemeinek klasszifikálása 38 Példa Logikai kényszer: Egy erőforrás (Resource) replikáinak száma (redundancydegree) meg kell egyezzen az erőforrást kezelő folyamat (Job) replikáinak számával (redundancydegree) 39 13

14 Példa Helyes modell Domain Specifikus Modell Editor VIATRA VIATRA transzformációs keretrendszer RACER ontológia alapú következtető Inkonzisztens modell Domain Specifikus Model Editor VIATRA transzformációs keretrendszer RACER ontológia alapú következtető 40 Összefoglalás Általános verifikációs és validációs keretrendszer került kidolgozásra integrálása viszonylag kis ráfordítással megoldható DECOS-ban néhányat megvalósítottunk Támogatja a tanúsított technológiák és alkalmazások kidolgozását Alkalmas szabványos ellenőrzési folyamatok megfogalmazására Modellező nyelvek helyessége formálisan ellenőrizhető Ontológiák és leíró logikák feletti következtetőgépek használatával 41 14