DECOS Nemzeti Nap október 15. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Átírás

1 Megfelelőség tanúsítása modell alapon Dr. Polgár Balázs

2 Miről lesz szó? 2

3 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

4 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

5 Cél Kidolgozott technológia validálása architektúra modell, alap és magas szintű szolgáltatások, hardver, eszközök Partíciók Szenzorok/beavatkozók DECOS Hálózat Biztonságkritikus job OS támogató réteg Végrehajtó környezet Kommunikációs I/O Layered TTP - LTTP vezérlo Virtuális (L-Flexray)... átjárók Fizikai HFTL * átjárók HW Csomagolás Fault-Tolerance összehasonlítás Layer - HFTL Nem biztonságkritikus job Nem biztonságkritikus job OS támogató réteg OS tám. Alap Core operációs Operating rendszer System (COS) (COS) OS tám. Védett osztott memória FPGA kártya (Xilinx Virtex4) Technológia használatával fejlesztett alkalmazások validálása 5

6 Cél pontosítása Keretrendszer kidolgozása, mely támogatja a teljes ellenőrzési folyamatot, képes külső ellenőrző eszközöket 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

7 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

8 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

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 9

10 Megoldandó feladatok 1. Szabványokban 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

11 Megoldandó feladatok 2. Ellenőrzési folyamat finomítása elemi lépésekre Elemi lépésekhez tartozó ellenőrző eszközöket integrálni kell Tapasztalatok szerint az eszközök integrációja ugyanannyiba szokott kerülni, mint maga az eszközök összértéke MQ-t használjuk, fölötte workflow motor 3. Központi modellek harmonizálása az ellenőrző eszközök, mérési környezetek saját modellezési nyelvével modelltranszformációs probléma megvalósítás VIATRA-val 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 12

13 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 tevékenységek 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

14 Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 14

15 Általános tesztkörnyezet a keretrendszer Függőleges irány: tartalmazza vagy használja DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 15

16 Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Vízszintes irány: információáramlás Külső teszt eszközök 16

17 Biztonsági eset Általános tesztkörnyezet Tesztelendő a keretrendszer elem specifikus Bizonyítja, hogy az adott elem megfelelően biztonságos DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 17

18 Tesztelendő elem specifikus Tartalmazza a teljesítendő követelmények listáját Leírja a kapcsolódó tevékenységeket Metainformációkat tartalmaz (pl. felelős) Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 18

19 Példa: PIM validálása Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 19

20 Általános tesztkörnyezet a keretrendszer Pl. a már említettek DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Szabványok Más források (pl. domain) Követelmények Validációs terv (V-Plan) tevékenységek Teszteset generálás eljárások Bizonyítékok Eszközök Köztes réteg (middleware) Hardver Modellek (pl. PIM) Alkalmazások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök Pl. autóiparban SIL3-as szintet kell elérni, repülőgépiparban SIL4 a követelmény 20

21 Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Más források (pl. domain) Követelmények tevékenységek Teszteset generálás eljárások 1. RACER bemeneti modelljének előállítása 2. RACER futtatása Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Pl. PIM validálása RACER-rel Külső teszt eszközök 21

22 Általános tesztkörnyezet a keretrendszer Szabványok PROPANE (Hibainjektálás) Követelmények Más források (pl. domain) DECOS - Test Bench keretrendszer Például: ITEM (Veszély és kockázat analízis) RACER (Formális verifikáció) SCADE MTC (Szimuláció) DECOS elemek LDRA (Tesztelés) EMI teszt környezet Biztonsági eset (safety case) Validációs terv (V-Plan) tevékenységek Teszteset generálás eljárások Bizonyítékok Tanúsítási bizonylatok Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök DECOS Egy Nemzeti DECOS Nap elem konkrét megvalósulása (pl. egy adott PIM modell) 22

23 Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 23

24 Általános tesztkörnyezet a keretrendszer DECOS - Test Bench keretrendszer Biztonsági eset (safety case) Tanúsítási bizonylatok DECOS elemek Validációs terv (V-Plan) Bizonyítékok Szabványok Követelmények tevékenységek Más források (pl. domain) Teszteset generálás eljárások Tesztelendő elem eszközök Pozitív Negatív Visszajelzés a tervezőnek Külső teszt eszközök 24

25 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

26 Fejlesztési és folyamat kapcsolódása 26

27 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

28 Általános tesztkörnyezet eszközök 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

29 Példa DOORS-ban implementált ellenőrző listára 29

30 Példa kézzel végrehajtott külső eszközre (LDRA) 30

31 Példa automatikusan végrehajtott külső eszközre PIM validáció Racerrel ellenőrzendő PIM 31

32 User Általános felépítés (példa: PIM ellenőrzés RACER-rel) DOORS Client 32

33 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

34 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

35 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

36 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

37 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á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 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

38 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

39 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

40 Példa Helyes modell VIATRA Domain Specifikus Modell Editor 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

41 Összefoglalás Általános verifikációs és validációs keretrendszer került kidolgozásra eszközök 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