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

Hasonló dokumentumok
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

Autóipari beágyazott rendszerek. Integrált és szétcsatolt rendszerek

Tartalom Platform-független modellezés Alkalmazás-modellezés A DECOS hardver platform Platform modellezés Hardver-szoftver integráció Implementáció 2

DECOS Nemzeti Nap. DECOS Nemzeti Nap. DECOS Nemzeti Nap

Csertán György Balogh András. Fejlesztési környezet áttekintés PIM-PSM editor bemutatás Ellenőrzési tesztkörnyezet bemutatása

Miért is transzformáljunk modelleket? Varró Dániel

Nagy bonyolultságú rendszerek fejlesztőeszközei

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Csertán György Pataricza András. Idővezérelt architektúrák Robosztus partícionálás Kódgenerálás Integrált, automatizált V&V Tanusítás

Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK

Követelménykezelés A követelményspecifikáció ellenőrzése

Szoftverminőségbiztosítás

Követelménykezelés Specifikáció készítés A specifikáció ellenőrzése

Norway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.

Intervenciós röntgen berendezés teljesítményszabályozójának automatizált tesztelése

Digitális eszközök típusai

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

Szemantikus világháló a BME-n

Szolgáltatás Orientált Architektúra a MAVIR-nál

Transzformációk integrált alkalmazása a modellvezérelt szoftverfejlesztésben. Ráth István

Követelmény-specifikáció készítés és ellenőrzés

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

Autóipari beágyazott rendszerek. Kockázatelemzés

Használati alapú és modell alapú tesztelés kombinálása szolgáltatásorientált architektúrák teszteléséhez az ipari gyakorlatban

matematikus-informatikus szemével

A fejlesztési szabványok szerepe a szoftverellenőrzésben

Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom

Követelménykezelés A követelményspecifikáció ellenőrzése

Komponens alapú fejlesztés

WEB2GRID: Desktop Grid a Web 2.0 szolgálatában

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

Miskolci Egyetem Alkalmazott Informatikai Intézeti Tanszék A minőségbiztosítás informatikája. Készítette: Urbán Norbert

Szoftvertechnológia ellenőrző kérdések 2005

Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT

Tartalom Kontextus modellek Viselkedési modellek Adat-modellek Objektum-modellek CASE munkapadok (workbench)

Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.

Automatikus tesztgenerálás modell ellenőrző segítségével

Verifikáció és validáció Általános bevezető

Integrációs mellékhatások és gyógymódok a felhőben. Géczy Viktor Üzletfejlesztési igazgató

IRÁNYÍTÓ RENDSZER IRÁNYÍTANDÓ FOLYAMAT. Biztonsági funkciók Biztonsági integritás. Normál működés. Hibák elleni védettség Saját (belső) biztonság

UML (Unified Modelling Language)

Emerald: Integrált jogi modellező keretrendszer

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Informatikai technológiák szakirány Rendszertervezés ágazat

Modell alapú tesztelés mobil környezetben

S01-8 Komponens alapú szoftverfejlesztés 2

Szárazföldi autonóm mobil robotok vezérlőrendszerének kialakítási lehetőségei. Kucsera Péter ZMNE Doktorandusz

Ráth István. A fejlesztés evolúciója

Erőforrás gazdálkodás a bevetésirányításban

Autóipari beágyazott rendszerek Dr. Balogh, András

Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék

MŰSZAKI TESZTTERVEZÉSI TECHNIKÁK A TESZT FEJLESZTÉSI FOLYAMATA A TESZTTERVEZÉSI TECHNIKÁK KATEGÓRIÁI

Rendszertervezés ágazat

Programozás 1. 2.gyakorlat

Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve

01. gyakorlat - Projektalapítás

Dr. Topár József 3. Eladás Marketing Külső szolgáltatás Alvállalkozók Fogyasztók. Engineering Termelés Anyagszabályozás Beszerzés Minőség

S01-7 Komponens alapú szoftverfejlesztés 1

A szemantikus világháló oktatása

Számítógépes munkakörnyezet II. Szoftver

Részletes szoftver tervek ellenőrzése

Alkalmazás technológiai frissítés migrációs és üzemeltetési tapasztalatok

hardver-szoftver integrált rendszer, amely Xwindow alapú terminálokat szervez egy hálózatba

Tartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet

5. Témakör TARTALOMJEGYZÉK

Informatikai rendszertervezés

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Steps Towards an Ontology Based Learning Environment. Anita Pintér Corvinno Technologia Transzfer Kft

A Hibatűrő Rendszerek Kutatócsoport EU kutatási projektekjei

Alkalmazásokban. Dezsényi Csaba Ovitas Magyarország kft.

Mit látnak a robotok? Bányai Mihály Matemorfózis, 2017.

Tudásalapú információ integráció

Bánsághi Anna 2014 Bánsághi Anna 1 of 31

Szolgáltatásintegráció (VIMIM234) tárgy bevezető

Informatikai rendszertervezés

Laborinformációs menedzsment rendszerek. validálása. Molnár Piroska Rikker Tamás (Dr. Vékes Erika NAH)

TSIMMIS egy lekérdezés centrikus megközelítés. TSIMMIS célok, technikák, megoldások TSIMMIS korlátai További lehetségek

Modellezési Kockázat. Kereskedelmi Banki Kockázatmodellezés. Molnár Márton Modellezési Vezető (Kockázatkezelés)

Szoftver újrafelhasználás

EGYÜTTMŰKÖDŐ ÉS VERSENGŐ ERŐFORRÁSOK SZERVEZÉSÉT TÁMOGATÓ ÁGENS RENDSZER KIDOLGOZÁSA

Optimalizáció ESX-től View-ig. Pintér Kornél ügyfélszolgála3 mérnök

A J2EE fejlesztési si platform (application. model) 1.4 platform. Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom

Modellezési alapismeretek

Megoldások a mintavizsga kérdések a VIMIAC04 tárgy ellenőrzési technikák részéhez kapcsolódóan (2017. május)

Mikrorendszerek tervezése

Szoftverminőségbiztosítás

Modellezési alapismeretek

Szoftverminőségbiztosítás

A tesztelés szükségessége

IV.3. MODELL-ALAPÚ MÓDSZER KIDOLGOZÁSA IT INFRASTRUKTÚRÁK ROBOSZTUSSÁGÁNAK ELEMZÉSÉHEZ KOCSIS-MAGYAR MELINDA

OpenCL alapú eszközök verifikációja és validációja a gyakorlatban

Petri-hálók és produkciós hálók közötti kapcsolat

A TANTÁRGY ADATLAPJA

Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése

Modellellenőrzés a vasút automatikai rendszerek fejlesztésében. XIX. Közlekedésfejlesztési és beruházási konferencia Bükfürdő

A Feldspar fordító, illetve Feldspar programok tesztelése

Programfejlesztési Modellek

8.3. AZ ASIC TESZTELÉSE

Üzleti folyamatok rugalmasabb IT támogatása. Nick Gábor András szeptember 10.

Átírás:

Megfelelőség tanúsítása modell alapon Dr. Polgár Balázs polgar@mit.bme.hu

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

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, 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

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

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 26262 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 60601 8

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

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

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

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

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

Á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

Á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

Á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

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

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

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

Á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

Á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

Á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

Á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

Á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

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

Á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 emaillel 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

Példa automatikusan végrehajtott külső eszközre PIM validáció Racerrel 1 14 2 4 7 5 6 13 8 11 9 10 3 12 ellenőrzendő PIM 31

User Általános felépítés (példa: PIM ellenőrzés RACER-rel) DOORS Client 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 e-mailen + 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 e-mailen visszaküldve Bemenet és kimenet formátuma szabványosítva 33

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

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

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

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

Ö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