Zvýšení spolehlivosti a diagnostika operačních systémů pracujících v reálném čase

Univerzita obrany Fakulta vojenských technologií Katedra komunikačních a informačních systémů

Zvýšení spolehlivosti a diagnostika operačních systémů pracujících v reálném čase Teze disertační práce

Školitel: prof. Ing. Václav Přenosil, CSc.

Brno 2007

Ing. Pavel Čeleda

Student:

Ing. Pavel Čeleda

Studĳní program: Studĳní obor:

Vojenská technika - elektrotechnická Velení a řízení, informatika a robotika

Předseda komise: Místopředseda:

prof. Ing. Vladimír Řeřucha, CSc. prof. Ing. Jaromír Krejčíček, CSc.

Školitel:

prof. Ing. Václav Přenosil, CSc.

Oponent: Oponent:

doc. Dr. Ing. Tomáš Brandejský pplk. Ing. Josef Kaderka, Ph.D.

Člen Člen Člen Člen

doc. Ing. Vladimír Vráb, CSc. doc. Ing. Rudolf Jalovecký, CSc. pplk. Ing. Vlastimil Malý, CSc. prof. Ing. Mirko Novák, DrSc.

komise: komise: komise: komise:

Datum a hodina obhajoby: Místo konání obhajoby:

26-11-P 26-11-V/036

24. května 2007, 10:00 Univerzita obrany, Kounicova 65, 612 00 Brno

Abstrakt Disertační práce se zabývá problematikou zvýšení spolehlivosti a diagnostikou operačních systémů pracujících v reálném čase. Programové a technické vybavení je stále složitější a neustále vzniká nebezpečí, že dojde k selhání zařízení v důsledku skrytých chyb. Ke vzniku chyby může dojít během všech etap životního cyklu programového vybavení. V důsledku těchto chyb hrozí materiální i lidské ztráty. Práce analyzuje aktuální stav v oblasti operačních systémů reálného času. K řešení disertační práce byl vybrán OS Linux s real-time rozšířením a navazující open-source programové vybavení vhodné pro vestavné systémy. Navržený diagnostický podsystém umožňuje metodou průběžné diagnostiky detekci a lokalizaci poruch v reálném čase. Metodou MDA je vytvořena úloha s inteligentním diagnostickým časovačem, monitorující chování řídicí úlohy a operačního systému. V rámci provedených experimentů jsou ověřeny real-time vlastnosti OS Linux. Je srovnána metoda MDA a její výstupy s klasickým přístupem, kdy zdrojový kód vytváří programátor.

Klíčová slova spolehlivost, diagnostika, operační systém, reálný čas, Linux, RTAI, RTOS, UML, MDA, MTL, PC/104, C

Abstract The dissertation deals with the problem of increasing dependability and diagnostics of real-time operating systems. Software and hardware parts in nowadays systems are more and more complex. The threat that system will fail in consequence of software or hardware bug grows continually. The bug may appear at any time during software lifecycle. In consequence of these bugs the material and human losses may arise. The work analyses the state of the art in the real-time operating systems area. Linux operating system is used to solve dissertation goals. The selected operating system uses real-time extension together with other open-source software suitable for embedded systems. Proposed diagnostics subsystem uses on-line diagnostics method to detect and locate system failure. MDA method is used to design intelligent watchdog timer for monitoring control tasks and operating system. The real-time features of Linux operating system are experimentally verified. The results of the MDA method are compared with source code written by programmer.

Key words dependability, diagnostics, operating system, real-time, Linux, RTAI, RTOS, UML, MDA, MTL, PC/104, C

1

1

Úvod

1

Úvod

Vyspělé prvky informačních technologií jsou stále častěji aplikovány do celé řady přístrojů a zařízení. V mnoha případech nejsou nikterak nápadné a unikají naší pozornosti. Staly se nedílnou součástí dnešní doby a jejich vliv do budoucna stále poroste. Společnou vlastností, kterou se vyznačují, je narůstající množství na ně kladených kritérií, požadavků a úkolů. Vnitřní struktura těchto systémů je stále více složitější. Narůstá objem programového vybavení, které je nutné vytvořit a spravovat po celou dobu životnosti systému. Základ programového vybavení, které se využívá při realizaci řídicích úloh tvoří operační systém (OS – Operating System). Jeho vlastnosti a chování fundamentálně ovlivňují praktické možnosti výsledného řízení a do značné míry i architekturu řídicích aplikací. Operační systémy určené pro řídicí úlohy jsou označovány jako operační systémy reálného času (RTOS – Real-Time Operating System). Hlavní rozdíl, kterým se operační systémy reálného času odlišují od běžně používaných operačních systémů, spočívá v potenciálních následcích, které mohou vzniknout při nesplnění požadovaných kritérií. Tento fakt podtrhuje specifická oblast použití RTOS (automobilní a letecká technika, robotické systémy, náročné výrobní procesy atd.). Zajisté by se nikomu nelíbilo, kdyby brzdový systém automobilu vypověděl službu během brždění. Složitá chemická reakce také nebude čekat, než se řídicí systém rozmyslí, jestli včas přidá další příměsi. Je zřejmé, že spolehlivost hraje v oblasti RTOS důležitou roli. S narůstajícím stupněm složitosti programového vybavení vzniká stále větší nebezpečí, že dojde k selhání celého zařízení v důsledku skrytých chyb. Ke vzniku nové chyby může dojít během návrhu, vývoje či údržby stávajícího programového vybavení. Celá řada odborníků po celém světě řeší tento ožehavý problém. Nelze však hovořit o uspokojivém stavu, protože množství chyb v programech neustále přibývá. V důsledku toho dochází stále k velkým materiálním ztrátám a v horších případech i ke ztrátám na lidských životech [6, 7]. Pojmy spolehlivost a diagnostika zdomácněly v terminologii informačních technologií, jsou však mnohdy chápány nesprávně či vykládány příliš populární formou. Oba pojmy vznikly a rozvíjely se ve vědních oborech jako je strojírenství, elektrotechnika či lékařství odkud je pak převzala informatika. Cílem disertační práce je poukázat na možnosti zvýšení spolehlivosti stávajících operačních systémů reálného času. Je navržena metoda doplnění programového vybavení o diagnostický podsystém schopný sledovat chování systému a reagovat na zjištěné problémy. Disertační práce je orientována na oblast vestavných systémů a použití volného programového vybavení (open source) k vytváření těchto systémů. Prakticky jsou navržené metody ověřeny na technickém a programovém vybavení bezpilotních letounů vytvořených v rámci projektu obranného výzkumu Záznam II.

1

Úvod

1.1

2

Formulace problému

Všechny etapy životního cyklu programového vybavení jsou úzce spjaty s problémem spolehlivosti. Pokud již v počátku dojde ke vzniku chyby v programovém vybavení, je často tato chyba dále přenášena a ovlivňuje navazující etapy. Z tohoto důvodu lze považovat za jednu z klíčových úloh zvýšení inherentní spolehlivosti programového vybavení. Inherentní spolehlivostí je označována spolehlivost „vložená“ do objektu v průběhu jeho návrhu a realizace. S ohledem na kritéria a specifika armádních podmínek lze výše uvedené tvrzení dále rozvést. Dlouhá životnost armádních zařízení (10 a více let) má za následek, že většina programového a technického vybavení přestane být postupem času podporována (ukončení výroby, ukončení podpory produktu, zánik dodavatele atd.). K udržení požadované funkce se pak často musí dané zařízení adaptovat novým technologiím, do určité míry modernizovat, nebo znovu vyvinout. Při malých sériích, které jsou typické pro tento druh zařízení a potřebě kvalitní vývojové základny, dochází k velkým finančním nákladům. Je zřejmé, že spolehlivost nového zařízení nemusí vždy dosahovat úrovně svého provozem ověřeného předchůdce. Z dlouhodobého hlediska lze označit za slabiny současných metod vývoje programového vybavení následující příčiny: • za hybnou sílu vývoje je stále považována tvorba zdrojového kódu, • postupné vzdalování se zdrojového kódu od původního popisu systému, rostoucí s počtem oprav skrytých chyb programu a inovací úlohy, • nízká úroveň opětovného použití již vytvořeného programového vybavení, • úzká vazba na konkrétní technologie (technické a programové vybavení), • absence univerzálního přístupu umožňující migraci mezi technologiemi, • rychlá devalvace technologií a produktů na nich založených, • problematické použití metod formální analýzy a verifikace systému. Současné možnosti provádění cílené diagnostiky programového vybavení jsou stále v řadě případů limitované. Většina operačních systémů poskytuje prostředky, které umožňují sledování vnějšího chování systému. Problematické však již bývá sledování vnitřního chování a stavu jednotlivých spuštěných úloh bez toho, aby musely být spuštěny v nějakém speciálním režimu (např. krokování programu, sledování systémových volání a signálů atd.). Systémy funkční (on-line) diagnostiky operačních systémů reálného času mají stále ještě řadu rezerv, mezi které patří: • absence standardu, který by definoval podmínky a metodiku průběžné diagnostiky programového vybavení, • programové vybavení (aplikace a jádro operačního systému) většinou nepředpokládá průběžnou diagnostiku, • diagnostika je zaměřena na technické vybavení a jeho monitorování, diagnostika programového vybavení je opomíjena, • zabezpečení distribuovaných diagnostických a monitorovacích systémů proti zneužití, • včasné a adekvátní vyhodnocení nashromážděných diagnostických dat.

1

Úvod

1.2

3

Cíle disertační práce

S ohledem na zvýšení inherentní spolehlivosti je důležité nalezení způsobu, jak z dlouhodobého hlediska popsat vytvářené programové vybavení. Popis (model systému) musí vystihovat, jaké funkce má systém plnit a musí být nezávislý na cílové platformě. Postupná transformace modelu systému by měla za výsledek finální podobu aplikace (zdrojový kód). Pozdější úpravy by byly prováděny pouze na úrovni modelu odkud by se změny, pokud možno automaticky, promítnuly do ostatních navazujících částí. Model by zároveň sloužil jako výchozí zdroj pro ostatní procesy spojené s tvorbou programového vybavení. Jednalo by se např. o verifikaci systému formálními metodami či automatické vytváření programové dokumentace. Cílem disertační práce bylo navrhnout diagnostický podsystém pro operační systém reálného času, vhodný pro vestavné systémy s omezenými výpočetními a paměťovými prostředky. Provést specifikaci, analýzu a návrh diagnostického podsystému pomocí zvolené metody pro tvorbu spolehlivého programového vybavení. Výsledný diagnostický podsystém následně experimentálně ověřit v prostředí operačního systému reálného času. Cíle disertační práce byly rozděleny do tří hlavních částí, které tvoří: 1) specifikace, analýza a návrh diagnostického podsystému, 2) vytvoření diagnostického podsystému, 3) experiment v prostředí operačního systému reálného času. Cílem specifikace a analýzy diagnostického podsystému bylo vytvoření koncepce navrhovaného systému. Zvážení dopadů plynoucích z doplnění jádra a aplikačních procesů o rozšiřující diagnostické funkce na real-time vlastnosti celého systému. Volba metody umožňující optimální sledování chování programového vybavení uvnitř systému s možností dynamicky reagovat na vzniklé poruchy. První část je členěna na následující dílčí problémy: • • • • •

diagnostické rozhraní systému, systém diagnostických zpráv, správce diagnostikovaných úloh, dopady na real-time vlastnosti systému, přenositelnost a použitelnost systému pro COTS (Commercial Off-The-Shelf ) operační systémy.

Druhá část vychází z návrhu diagnostického podsystému a vybraná část byla postupně transformována do podoby funkční aplikace. Výsledkem je zdrojový kód aplikace obsahující programové konstrukce umožňující on-line diagnostiku: • platformově nezávislý model diagnostického podsystému, • model diagnostického podsystému pro zvolenou platformu, • zdrojový kód diagnostického podsystému. Závěrečný experiment sloužil k ověření funkce navrženého systému v reálných podmínkách. Provedení experimentu vyžadovalo použít operační systém reálného času, podporující standard POSIX. Hlavními cíli experimentu byly: • volba a sestavení výpočetního systému vhodného pro experiment, • ověření funkce diagnostického podsystému u zvoleného operačního systému reálného času, • určení vlivu diagnostického podsystému na real-time vlastnosti systému.

2

Charakteristika současného stavu

2

4


Operační systémy reálného času Obecně lze pohlížet na systém reálného času jako na systém, který zpracovává asynchronní události a za všech podmínek v pevně stanoveném čase na ně produkuje odpovědi. Systémy reálného času jsou členěny do dvou hlavních kategorií (hard a soft real–time). Rozdíl mezi jednotlivými kategoriemi spočívá v dodržení časových podmínek kladených na funkce systému a aplikací na něm spuštěných. Operační systém reálného času je takový systém, v němž správnost výpočtu nezáleží pouze na logické správnosti algoritmu, ale i na čase, ve kterém byl výsledek vypočten. Pokud časové podmínky systému nejsou dodrženy, říká se, že systém selhal [11].

Inherentní spolehlivost programového vybavení V oblasti informačních technologií lze považovat úroveň inherentní spolehlivosti za jeden z klíčových faktorů k dosažení vysoké spolehlivosti výsledného programového vybavení. Postupem času vznikla řada metod jak dosáhnout určitého stupně zvýšení spolehlivosti. Přesto neustále dochází k chybám v programech. Jaké jsou důvody proč tyto chyby neustále vznikají [3]? • Neutuchající každoroční prudký růst v oblasti informačních technologií. Tlak na dosažení co největší produktivity a zkrácení doby vývoje produktu (SW a HW) na minimum. Vytváření zdrojového kódu aplikací je považována obecně za nejdůležitější činnost. • Používání programovacích jazyků (C, C++, ASM) umožňuje vznik nebezpečných konstrukcí, které mohou vést k selhání programu. Nedostatečné používání nástrojů na testování zdrojových kódů programu. • Programátoři jsou lidé a mají tendence si zjednodušovat práci. Často volí jednodušší přístup řešení problému před komplexním přístupem zohledňujícím všechny rizika. Byli, jsou a budou špatní programátoři s nedostatečnými znalostmi a praktickými zkušenostmi. • Množství programového vybavení, které je nutné udržovat po delší dobu, stále narůstá. Společně s tím roste i objem zdrojového kódu nezbytného pro jeho realizaci. Často je přehlížen fakt, že i drobné úpravy ve zdrojovém kódu mohou mít dalekosáhlé následky na spolehlivost.

Diagnostika operačních systémů reálného času Diagnostické metody [9, 10] používané v systémech pracujících v reálném čase, mohou mít jednu z následujících forem: • • • •

spouštěcí diagnostika, periodická diagnostika, průběžná diagnostika, diagnostika redundantních částí.

2

5


Pro řešení cílů disertační práce byla zvolena metoda průběžné diagnostiky. Tato metoda poskytuje informace o správnosti operací prováděných v systému a je v podstatě totožná se zabezpečením systému proti poruchám. Obvykle je založena na kontrole správnosti bezpečnostního kódu a je prováděna technickými prostředky. Hlavní výhodou průběžné diagnostiky realizované tímto způsobem je její časová nenáročnost (výpočet se nepřerušuje ani nezpomaluje) a velmi jednoduché řízení. Průběžná diagnostika však může být realizována i jinou formou kontroly správnosti výsledku, např. kontrolním výpočtem probíhajícím v jiném procesoru, opakovaným výpočtem ve stejném procesoru, jednoduchou kontrolou důležitých vlastností získaného výsledku (např. porovnáním s mezními hodnotami) apod.

Metody návrhu programového vybavení Na počátku vývoje programového vybavení je vždy zadání (popis systému), na základě kterého dojde k vytvoření programového vybavení. Popis systému je často představován modelem, který poskytuje potřebný stupeň abstrakce a prostředky pro popsání chování a vlastností systému. Na obr. 1 jsou znázorněny různé vztahy mezi modelem a zdrojovým kódem [1, 5]. pouze kód

vizualizace kódu

obousměrný vývoj

transformace modelu

pouze model

model

model

model

model

kód

kód

kód

kód

model neexistuje

kód je modelem

kód a model koexistují

model je kódem

kód neexistuje

Obr. 1: Vztah mezi modelem a zdrojovým kódem

3

6

Postup řešení cílů disertační práce

3


V rámci disertační práce navržený systém se zvýšenou spolehlivostí a zabudovanou diagnostikou, je určen pro vestavné systémy pracující v reálném čase. Systém je tvořen operačním systémem reálného času a úlohami na něm spuštěnými. Vlastnosti výsledného systému jsou součtem vlastností jak jádra RTOS, tak i spuštěných úloh. Vestavný systém má k dispozici omezené výpočetní a paměťové prostředky. Typické řídicí úlohy ve vestavných systémech jsou charakteristické tím, že úloha prochází v nekonečné smyčce konečným počtem stavů. K popisu jednotlivých stavů a přechodů mezi nimi, lze použít stavové automaty [8]. Převod na zdrojový kód lze uskutečnit např. metodou SOP (State-Oriented Programming) [15]. Cílem disertační práce nebylo pokrýt celé spektrum poruch, které mohou na systém působit. Systém má být odolný vůči poruchám v důsledku výskytu chyb v programovém vybavení. Další možné zdroje chyb a poruch nebyly uvažovány.

3.1

Diagnostický podsystém pro operační systémy reálného času

Navržený diagnostický podsystém má hierarchickou strukturu, kterou tvoří tři základní úrovně: • uživatelské rozhraní pro dohled nad systémem, • hlavní diagnostická jednotka (nadřízený), • výkonné řídicí jednotky (podřízení) se zabudovanými diagnostickými prvky. řídicí jednotka

dohledové centrum

hlavní diagnostická jednotka

řídicí jednotka

řídicí jednotka

Obr. 2: Hierarchická struktura diagnostického podsystému S ohledem na konkrétní aplikaci mohou jednotlivé úrovně představovat samostatná navzájem propojená zařízení. Na druhou stranu se však může jednat i o systém, kde jednotlivé vrstvy budou představovat procesy spuštěné v rámci operačního systému reálného času nad společným technickým vybavením viz obr. 3. Diagnostické rozhraní operačního systému Jednotlivé řídicí procesy obsahují rozhraní pro sdílení informací s diagnostickým podsystémem. Operační systém reálného času a diagnostický podsystém sdílí společný procesor, paměť atd. a proto lze označit tento typ monitorování za intrusivní monitorování.

3

7


Navržená struktura diagnostického podsystému je založena na struktuře vyobrazené na obr. 3. Diagnostický podsystém je složen ze čtyř základních částí, které tvoří: • • • •

řídicí procesy s diagnostickým rozhraním, diagnostická sběrnice, diagnostický modul jádra operačního systému, správce diagnostikovaných úloh. uživatelský prostor proces n

proces 2

proces 1

diagnostický a monitorovací manažer

diagnostická sběrnice

diagnostický modul jádra

jádro RTOS

prostor jádra

Obr. 3: Diagnostický podsystém operačního systému reálného času Jednotlivé části diagnostického podsystému jsou umístěny do uživatelského prostoru (user space) a prostoru jádra (kernel space). Prostor jádra je využíván pro privilegované procesy a procesy s vysokou prioritou. Pro ostatní části diagnostického podsystému je vyhrazeno místo v uživatelském prostoru. Z důvodu spolehlivosti a bezpečnosti systému by měla být většina procesů spuštěna v uživatelském prostoru. Diagnostické rozhraní řídicího procesu Řídicí proces je popsán stavovým automatem, který popisuje funkci daného procesu. Současně se stavovým automatem řídicího procesu je prováděn i stavový automat diagnostického rozhraní. Diagnostické rozhraní řídicího procesu je složeno ze tří částí, které tvoří: • diagnostický stavový automat - představuje vybraný diagnostický algoritmus, • rozhraní mezi diagnostickým a řídicím stavovým automatem - výměna dat mezi řídicí a diagnostickou částí uvnitř prováděné úlohy, • rozhraní mezi diagnostickým stavovým automatem a diagnostickou sběrnicí předávání diagnostických zpráv uvnitř systému. Informace o aktuálním stavu řídicího procesu jsou získávány pomocí diagnostických registrů. Diagnostické registry umožňují přístup do adresového prostoru řídicího procesu a jsou tvořeny sadou základních registrů a uživatelsky definovanými registry. Základní diagnostické registry jsou implementovány ve formě SW-JTAGu [12]. Myšlenka koncepce SW-JTAGu využívá principu IEEE 1149.1 pro potřeby

3

8


Proces 1

Proces 2

řídicí stavový diagram

řídicí stavový diagram

diagnostický stavový diagram

diagnostický stavový diagram

diagnostická sběrnice

Obr. 4: Řídicí proces s diagnostickým rozhraním průběžné diagnostiky programového vybavení. Doplněním SW-JTAGu do programového vybavení se naskýtá možnost sledovat v reálném čase chod jednotlivých částí systému, detekovat a lokalizovat případný výskyt poruchy.

3.2

Inteligentní diagnostický časovač

Stávající řešení s diagnostickými časovači (WDT – Watchdog Timer ) pro použití ve víceúlohových systémech není zcela optimální. Z tohoto důvodu bylo navrženo následující rozšíření WDT: • vytvoření a přiřazení dedikovaného (virtuálního) WDT jednotlivým součástem řídicího systému (procesy, jádro OS atd.), • zapojení jednotlivých (virtuálních) WDT do centrálního SW-WDT napojeného na fyzický HW-WDT, • začlenění mechanizmů obnovení po detekci poruchy v systému. Vytvořená hierarchická struktura WDT umožňuje sledovat chování jednotlivých součástí řídicího systému. Inteligentní diagnostický časovač je nedílnou součástí diagnostického podsystému, který sleduje chování celého systému. úloha č. 1 WDT úloha č. 2 WDT

úloha č. n WDT

SW watchdog

reset

HW watchdog

RESET systému

Obr. 5: Princip inteligentního diagnostického časovače Každá část systému má vlastní charakteristické chování. Úlohy s vysokou prioritou jsou vykonávány častěji v porovnání s úlohami běžícími na pozadí. Použitím jednoho společného WDT by vedlo k tomu, že pokud by jedna část systému selhala,

3

9


zbývající části by mohly dál udržovat WDT v iluzi, že je vše v pořádku. Bylo by problematické detekovat, zda úlohy s nižší prioritou jsou funkční a obsluhují WDT. Použitím inteligentního diagnostického časovače se tento problém eliminuje.

3.3

Model diagnostického podsystému

Úloha inteligentního diagnostického časovače byla podrobena dalšímu zkoumání. Zejména se jednalo o vytvoření modelu úlohy producent - konzument bez a s diagnostickým časovačem a jeho převod do podoby zdrojového kódu. Bylo provedeno srovnání metody MDA (Model Driven Architecture) [13] s metodou, kdy je zdrojový kód vytvářen programátorem.

Popis systému metodou MDA Metoda MDA se sestává z jazyka UML (Unified Modeling Language) pro popis a vizualizaci modelů, standardu MOF (Meta Object Facility), popisujícího abstraktní jazyk pro správu a uchování objektů a modelů vytvořených pomocí UML v datovém skladu a konverzního prostředku XMI (XML Metadata Interchange) pro výměnu modelů mezi jednotlivými MDA nástroji. model platformy model aplikace model diagnostického podsystému

platformově specifický model

zdrojový kód

model RTOS

Obr. 6: Transformace modelů PIM na PSM a zdrojový kód Na obr. 6 jsou zobrazeny jednotlivé modely a transformace nutné k vytvoření zdrojového kódu metodou MDA. Metoda MDA definuje obousměrnou transformaci, tj. změny na vyšší úrovni jsou promítány do modelů nižší úrovně a naopak. Platformově nezávislé modely (PIM – Platform Independent Model ) popisují tři základní části programového vybavení výpočetního systému: • model operačního systému reálného času - popisuje entity, které se vyskytují v operačních systémech reálného času (procesy, metody plánování, synchronizační mechanizmy, vstupně/výstupní operace atd.), • model diagnostického podsystému - popisuje entity, které jsou součástí diagnostického podsystému (diagnostické rozhraní OS a úloh, diagnostická sběrnice, systém diagnostických zpráv, správce diagnostických úloh atd.),

3


10

• model aplikace - popisuje entity tvořící aplikaci (uživatelské rozhraní, obsluha vstupů/výstupů, řídicí algoritmy atd.). Platformově nezávislé modely popisují koncepci řešení diagnostiky programového vybavení u systémů reálného času. Modely PIM neobsahují informace spojené s konkrétními technologiemi a umožňují provést řešení na obecné úrovni. Transformace modelů PIM na PSM (Platform Specific Model ) zahrnuje následující kroky: • Doplnění mapovacích značek do PIM modelu. Mapovací značky definují, která transformační pravidla se mají použít. • Výběr cílové platformy (modelu platformy), pro který bude vytvořen PSM model. • Transformace modelu PIM na PSM s ohledem na zvolenou cílovou platformu a transformační pravidla. Vytvořený PSM model má strukturu velice blízkou výslednému zdrojovému kódu. Závěrečná transformace převádí PSM model na zdrojový kód. Generátor zdrojového kódu využívá předpřipravených šablon k převedení PSM modelu na zdrojový kód. Výsledný kód je bez dalších úprav použit k sestavení finální aplikace.

Generování zdrojového kódu Platformově nezávislý model úlohy producent - konzument byl transformován pomocí jazyka MTL (Model Transformation Language) na PSM model. Vytvořený PSM model byl následně použit jako vstup pro generátor zdrojového kódu. Generování zdrojového kódu bylo provedeno dvěma způsoby: • generátor zdrojového kódu napsaný v jazyce MTL, • generátor zdrojového kódu modelovacího nástroje Poseidon CE. V prvním případě se jednalo o návrh vlastního generátoru zdrojového kódu pomocí jazyka MTL. Generátor umožňoval převést PSM model úlohy producent - konzument na zdrojový kód v jazyce Java. K transformaci PSM modelu byla použita metoda dopředného vývoje. Výsledný zdrojový kód obsahoval převedené diagramy tříd (data, metody). V kódu však scházely příkazy (operace) v těle metod. Jazyk UML ve verzi 1.4 nedisponuje dostatečnými prostředky, které by byly schopny popsat detailně vstupní model. Pro vygenerování plnohodnotného zdrojového kódu metodou dopředného vývoje je však nezbytné, aby vstupní model obsahoval všechny potřebné informace. V druhém případě byl zdrojový kód generován pomocí modelovacího nástroje Poseidon CE. Modelovací nástroj Poseidon CE využívá metody obousměrného vývoje, kdy model a zdrojový kód koexistují. Generátor zdrojového kódu převedl model PSM na zdrojový kód. Scházející části ve vygenerovaném zdrojovém kódu, byly doplněny ručně a následně byly zpětně importovány do PSM modelu.

4

Experimenty v prostředí operačního systému reálného času

4

11


Během vypracování disertační práce bylo provedeno několik experimentů. Výchozím bodem pro všechny experimenty byl funkční operační systém reálného času, který byl provozován na procesorových modulech PC/104. Experimenty byly prováděny jak v laboratorních podmínkách, tak i prakticky během letových zkoušek s bezpilotními letouny.

4.1

Experiment letiště Přerov

Praktický experiment s bezpilotním prostředkem se uskutečnil 15. července 2004 na letišti v Přerově. Do draku UAV (Unmanned Aerial Vehicle) byla zabudována minimalizovaná verze diagnostické ústředny (DÚ) [2, 14]. Cílem experimentu bylo ověřit základní funkce DÚ v reálných podmínkách. Během letu byly na paměťové médium zaznamenávány údaje z GPS, elektronického kompasu a gyroskopu. Rozmístění jednotlivých funkčních bloků je vyobrazeno na obr. 7. Přĳímač GPS a elektronický kompas byly umístěny vně draku UAV. Mechanické uchycení jednotlivých částí bylo provedeno šrouby do draku UAV přes tlumící gumovou podložku nahrazující silentbloky. GPS 16A gyroskop elektronický kompas

PC/104

Obr. 7: Umístění elektronického vybavení na bezpilotním prostředku

Záznam dat během experimentu Centrální řídicí jednotka prováděla záznam dat ze senzorů připojených na sériových rozhraních ttyS1 – ttyS3 (UART1 – UART3) viz obr. 8. Jednotlivé senzory byly přednastaveny v laboratorních podmínkách, aby se vyloučila možná chyba konfigurace. Jeden cyklus měření odpovídal době od připojení systému na zdroj napájení až po regulérní vypnutí systému. Funkce DÚ byla v reálném čase monitorována pomocí rádiového spoje z pozemního stanoviště. Díky této funkci se podařilo odhalit počáteční problémy s mechanickým uchycením konektorů, které v důsledku vibrací uvnitř UAV vedly k jejich svévolnému rozpojení.

12

38400,N,8,1

Procesorový modul PC/104 - MSM586SEV AMD ÉlanSC520 133 MHz

SDRAM 128 MB

CFC 256 MB

UART2

GPS 16A 8V / 100mA

9600,N,8,1 RTS/CTS

19200,N,8,1

UART3

Aerocomm AC 4486 868 MHz radio link 5V / 1A

UART0


UART1

4

19200,N,8,1

elektronický kompas HMR 3300 8V / 24mA

gyroskop 8V / 200mA

5V/1A

aktivní chlazení

Zdroj napájení

NiMH baterie 8 článků SANYO - 3000 mAh

stabilizátor 5V / 5A

napětí z baterie 9,2V

stabilizátor 3,3V / 1A

Obr. 8: Bloková struktura výpočetního systému použitého během experimentu Vyhodnocení dat z GPS přĳímače Získaný záznam datových vět ve formátu NMEA z GPS přĳímače byl předzpracován a byly vyloučeny neplatné záznamy (fáze kdy GPS přĳímač nebyl zasynchronizovaný). Následně byla data zobrazena programem GnuPlot. Na obr. 9 je znázorněna dosažená výška během letu UAV, vztažená k nadmořské výšce letiště. UAV - Flight Level (Přerov 15-7-2004) 180 Flight Level

160

140

Flight Level [m]

120

100

80

60

40

20

0 12:02:30

12:03:00

12:03:30

12:04:00

12:04:30

12:05:00

12:05:30

Universal Time (UTC) [h]

Obr. 9: Průběh dosažené výšky zaznamenaný z GPS přĳímače Závěr k experimentu na letišti v Přerově Během experimentu se podařilo ověřit funkčnost DÚ navržené v rámci projektů VGA [2, 4]. V DÚ byla použita zjednodušená verze výpočetního systému (obr. 8), založená na procesorovém modulu MSM586SEV a inteligentních senzorech určených pro sběr letových charakteristik UAV. Získané údaje ze senzorů byly použity k dalšímu vyhodnocení, které ukázalo, že je nutné věnovat pozornost hlavně snímačům inerciální navigační soustavy a jejich okolí. Nainstalovaný operační systém nevykazoval žádné výpadky. Systém fungoval spolehlivě a v logovacích záznamech se neobjevily žádné poruchy.

4


4.2

13

Testování real-time vlastností OS Linux

Cílem experimentu bylo ověřit real-time vlastnosti OS Linux bez a se zapnutou podporou pro real-time aplikace. Testy byly prováděny na procesorovém modulu PCM-3350 s linuxovém jádrem 2.6.8 a real-time rozšířením RTAI (Real-Time Linux Application Interface) verze 3.1. Byly provedeny následující testy: • • • •

test test test test

latence, preemptivity, přepínačů, vstupně/výstupních operací.

Test vstupně/výstupních operací Test slouží k ověřování real-time chování při vstupně/výstupních operacích. Na datových vývodech paralelního portu je generován obdélníkový průběh (0 - 5 V) s frekvencí přibližně 10 kHz. Pokud dojde k velkému zatížení procesoru a frekvence na paralelním portu se nezmění, je to známka správného real-time chování. V opačném případě systém nesplňuje real-time podmínky a nelze ho použít k real-time řízení. procesorový modul PCM-3350 paralelní port D0 (vývod 2)

číslicový osciloskop

kanál A GND (vývod 25)

Obr. 10: Zapojení měřicího pracoviště během experimentu Na obr. 11 je zobrazen výsledek testu OS Linux s RTAI rozšířením se zátěží. Zobrazený obdélníkový signál má frekvenci 10 kHz a nevykazuje žádné výpadky.

Obr. 11: Test paralelního portu se zátěží - Linux s RTAI rozšířením

4


14

Závěr k testování real-time vlastností OS Linux Provedené experimenty demonstrovaly základní real-time vlastnosti OS Linux. Bylo ukázáno, že standardní linuxové jádro nedisponuje příliš dobrými real-time vlastnostmi. Lze jej použít v případě, že jsou pro řídicí úlohu akceptovatelné latence v řádech ms. Výkon operačního systému lze dále zlepšit zapnutím preemptivní podpory v jádře. Pro úlohy vyžadující splnění hard real-time podmínek je nutné použít RTAI rozšíření, které garantuje latence v řádech desítek µs.

4.3

Experiment s diagnostickou sběrnicí pro real-time systémy

Cílem experimentu bylo ověřit vlastnosti vybraných sběrnic použitelných pro diagnostickou sběrnici v real-time systémech. V prvním případě byla diagnostická sběrnice realizovaná pomocí ethernetové sítě s přenosovou rychlostí 10/100 Mb/s. V druhém případě se jednalo o sběrnici CAN s přenosovou rychlostí 1 Mb/s. Test diagnostické sběrnice založené na RTnet Jednoúčelová diagnostická sběrnice byla zapojena pomocí ethernetových rozhraní modulů PC/104. Pro vzájemnou komunikaci mezi moduly, byl použit protokol RTnet, umožňující komunikaci v reálném čase na ethernetové síti. Pro předcházení nepředvídatelných kolizí na Ethernetu, dané přístupovou metodou CSMA/CD, slouží zvláštní protokolová vrstva řízení RTmac. Sdílení přenosového média je řešeno pomocí metody TDMA (Time Division Multiple Access).

IP: 10.0.0.1/24

monitorovací PC v promiskuitním režimu IP: 10.0.0.3/24

SLAVE procesorový modul PCM-3350 IP: 10.0.0.2/24

eth0

eth0

eth0

MASTER PC

RTnet

RTnet

RTnet

rozbočovač (HUB)

Obr. 12: Zapojení pracoviště během testu diagnostické sběrnice s RTnet Síť RTnet je tvořena jedním nadřízeným uzlem (master) a jedním nebo několika podřízenými uzly (slaves). Pro testování diagnostické sběrnice a sítě RTnet, bylo zapojeno měřicí pracoviště podle obr. 12. Závěr k testování diagnostické sběrnice pro real-time systémy Během experimentu byly odzkoušeny dva typy rozhraní (Ethernet a CAN) zvažované pro jednoúčelovou diagnostickou sběrnici. Byly otestovány základní vlastnosti obou rozhraní a možnosti jak je programově ovládat. Z pohledu využití pro další vývoj diagnostického podsystému testy ověřily přenosové vlastnosti obou rozhraní. Nejednalo se však o testy, kde by bylo prováděno vysílání diagnostických zpráv a jejich vyhodnocování. Tato oblast zůstává otevřená a je předmětem dalšího vývoje.

4


4.4

15

Experiment s inteligentním diagnostickým časovačem

Cílem experimentu bylo ověřit koncept inteligentního diagnostického časovače popsaného v kapitole 3.2. Demonstrační příklad s inteligentním diagnostickým časovačem realizuje úlohu producent - konzument. Producent je vlákno data produkující a konzument je druhé vlákno, které data přĳímá a dále zpracovává. Producent a konzument využívají ke vzájemné komunikaci vyrovnávací paměť omezené velikosti. vyrovnávací paměť

producent

konzument

zapiš

čti

Obr. 13: Princip úlohy producent - konzument Úloha je tvořena třemi vlákny (SW-WDT, producent a konzument), která sdílí společný datový prostor. Obr. 14 zachycuje stavový diagram úlohy producent - konzument, doplněné o inteligentní diagnostický časovač.

producent - konzument start

update WDT

SW-WDT porucha

start

produkuj

producent porucha

start

konzumuj

konzument porucha

Obr. 14: Stavový diagram úlohy producent - konzument Úloha je spuštěna v nekonečné smyčce a na kooperativní bázi dochází v kruhu k přepínání mezi jednotlivými vlákny. Každé vlákno disponuje vlastním čítačem aktivity, který se v definovaném bodě inkrementuje pokaždé, když vlákno dostane přidělený procesor. Vlákno SW-WDT provádí porovnání hodnoty svého čítače s hodnotami vláken producenta a konzumenta. V případě, že se hodnota některého z čítačů neshoduje s hodnotou čítače SW-WDT, je detekována porucha. Dojde-li k selhání obou vláken producenta a konzumenta, přestane SW-WDT nulovat HW-WDT a systém bude znovu zaveden. Závěr k testování inteligentního diagnostického časovače Provedený experiment ověřil koncept inteligentního diagnostického časovače. Demonstrační úloha producent - konzument, představuje jednu ze základních úloh, se kterými se lze setkat ve víceúlohových systémech pracujících v reálném čase.

5

Výsledky disertační práce

5 5.1

16

Výsledky disertační práce Diagnostický podsystém pro operační systémy reálného času

Navržený diagnostický podsystém pro operační systémy reálného času využívá metody průběžné diagnostiky. Metoda poskytuje v reálném čase informace o chování systému. K získávání diagnostických informací slouží diagnostické rozhraní operačního systému a řídicích procesů. Takto získané informace jsou dále předávány ke zpracování pomocí diagnostické sběrnice a diagnostických zpráv do správce diagnostických úloh. Prováděná průběžná diagnostika je založena na diagnostickém rozhraní označeném SW-JTAG. Jednotlivé řídicí procesy spolupracují s diagnostickým podsystémem na kooperativní bázi. Operační systém reálného času a diagnostický podsystém sdílí společný procesor, paměť a ostatní periferie. Jedná se tedy o intrusivní monitorování. Diagnostický podsystém je navržen tak, aby neměl vliv na chod sledovaného systému a nedocházelo k ovlivňování real-time vlastností systému. Diagnostický podsystém má hierarchickou strukturu. Jednotlivé úrovně mohou představovat samostatná, navzájem propojená zařízení nebo procesy spuštěné v rámci operačního systému reálného času nad společným technickým vybavením. Správce diagnostických úloh je zodpovědný za řízení a dohled nad sledovaným systémem. Rozhodování správce diagnostických úloh je řešeno pomocí pevně stanovených pravidel, která jsou definována na základě znalostí chování sledovaného systému. Pravidla jsou zapsána ve formě rozhodovacího stromu, aby rozhodovací proces byl optimální a nedocházelo k nedodržování real-time vlastností systému.

5.2

Model diagnostického podsystému

Vytvořený model části diagnostického podsystému provádí pomocí diagnostického časovače průběžnou diagnostiku programového vybavení. Zvolená úloha producent - konzument představuje klasický příklad řešení problému synchronizace mezi dvěma procesy a demonstruje typickou úlohu v řídicích systémech pracujících v reálném čase. Popis modelu diagnostické úlohy byl proveden v jazyce UML. Použitá metoda MDA umožňuje transformovat vstupní platformově nezávislý model na platformově specifický model. Cílová platforma operačního systému reálného času byla popsána modelem platformy. Transformace modelu byla provedena v jazyce MTL. Výstupem transformace byl platformově specifický model, který byl použit jako vstup pro generátor zdrojového kódu. Generování zdrojového kódu bylo provedeno metodou přímé transformace modelu (forward engineering) a metodou obousměrného vývoje (roundtrip engineering). Použití metody MDA umožnilo vytvořit popis programového vybavení pomocí UML modelů. Výsledkem postupné transformace jednotlivých modelů byl zdrojový kód aplikace. Škálovatelnost metody MDA v kombinaci s MTL jazykem zatím neumožňuje řešení problémů pro větší programové celky, jako je např. jádro operačního systému. Metoda MDA je založena na jazyce UML, který využívá objektového přístupu k popisu struktury systému. Výsledný zdrojový kód, který vznikne transformací

5


17

modelů, je objektově orientovaný (Ada, Java, C++, C#). Ne vždy jsou však tyto jazyky vhodné k sestavení aplikací pracujících v reálném čase s omezenými paměťovými a výpočetními zdroji (např. jazyk Java a správa paměti pomocí garbage collectoru).

5.3

Vývojová platforma pro diagnostický podsystém

Navržená vývojová platforma se stala součástí technického a programového vybavení bezpilotního prostředku vyvíjeného v rámci projektu obranného výzkumu Záznam II. Jednalo se o systém se zvýšenou spolehlivostí, neboť selhání řídicího systému by s velkou pravděpodobností vedlo k destrukci celého bezpilotního prostředku a případně dalším škodám. Řízení UAV bylo založeno na distribuovaném řízení v reálném čase. Zálohovaná centrální řídicí jednotka se skládala z procesorových modulů PC/104 vzájemně propojených pomocí sběrnice CAN a sítě Ethernet. Jednotlivé zprávy vysílané po řídicí sběrnici CAN měly definovanou prioritu a zaručenou dobu odezvy. Vzniklá modulární struktura s pevně definovaným rozhraním (CAN, Ethernet) umožnila připojení ostatních inteligentních senzorů a podpůrných obvodů. Vlastnosti a funkčnost navrženého systému byly prakticky ověřeny během experimentu na letišti v Přerově. Experiment byl zaměřen na ověření chování výpočetního systému v polních podmínkách a sběr letových charakteristik UAV z inteligentních senzorů (elektronický kompas, přĳímač GPS, gyroskop). Výsledek experimentu ukázal na slabá místa v návrhu. Jednalo se zejména o malou mechanickou odolnost propojovacích konektorů. Výpočetní systém jako celek nevykazoval poruchy a sběr letových charakteristik UAV byl úspěšně proveden.

5.4


Kapitola 4 shrnuje provedené experimenty během řešení disertační práce. Cílem experimentů bylo praktické ověření teoreticky navržených postupů s operačním systémem Linux, doplněném o podporu reálného času. Experimenty byly prováděny jak v laboratorních podmínkách, tak i prakticky během letových zkoušek s UAV. První experiment byl proveden na letišti v Přerově, kde byl výpočetní systém zabudován do draku UAV a bylo provedeno několik pilotovaných letů. Získaná data z měření byla postoupena k dalšímu zpracování, aby bylo možné určit základní letové charakteristiky UAV. Navazující plánované experimenty s UAV nebylo možno uskutečnit z důvodu komplikované situace kolem podpory projektu obranného výzkumu Záznam II. Z tohoto důvodu byly další experimenty provedeny pouze v laboratorních podmínkách. Druhý experiment byl zaměřen na ověření real-time vlastností OS Linux bez a se zapnutou podporou pro real-time aplikace. Byly demonstrovány základní vlastnosti jádra OS Linux. Standardní jádro nedisponuje příliš dobrými real-time vlastnostmi a odezva systému se pohybuje v řádech ms. Dobu odezvy linuxového jádra lze snížit speciální úpravou plánovače úloh. Pro úlohy, které však vyžadují splnění hard realtime podmínek, je nezbytné použít RTAI rozšíření, které garantuje odezvy v řádech desítek µs.

5


18

Třetí experiment byl zaměřen na ověření koncepce diagnostické sběrnice pro systémy pracující v reálném čase. Diagnostická sběrnice byla realizovaná pomocí sítě Ethernet s přenosovou rychlostí 10/100 Mb/s a sběrnicí CAN s přenosovou rychlostí 1 Mb/s. Každá z těchto sběrnic se vyznačuje jinými vlastnostmi. Síť Ethernet byla navržena pro počítačové sítě a nedisponuje metodami pro inteligentní řízení přístupu ke sdílenému komunikačnímu médiu. Pokud na síti Ethernet chceme dosáhnout definované doby odezvy, je toto nutné provést programově. Jednou z metod jak toho docílit je použití metody TDMA, kterou využívá i protokol RTnet, který byl použit pro vytvoření diagnostické sběrnice v síti Ethernet. Na druhou stranu sběrnice CAN byla od počátku navržena pro průmyslové použití. Řešení přístupu na společnou sběrnici, priority zpráv atd. je nedílnou součástí mechanizmů, kterými sběrnice CAN disponuje. Provedené experimenty ukázaly, že v závislosti na použitém technickém vybavení lze pro diagnostickou sběrnici použít jak sítě Ethernet, tak i sběrnice CAN. Je však nutné patřičně zohlednit faktory jako je topologie diagnostické sběrnice, vzdálenost jednotlivých uzlů, zdroje rušení atd. Čtvrtý experiment byl zaměřen na ověření inteligentního diagnostického časovače pro sledování chování programového vybavení. Úloha producent - konzument byla doplněna o inteligentní diagnostický časovač. Úlohu tvořily tři vlákna (SW-WDT, producent a konzument). Stav jednotlivých vláken byl sledován pomocí čítačů aktivity. V případě výskytu byla porucha detekována a zobrazena na terminálu. Při úplném selhání úlohy, byl systém znovu zaveden pomocí HW-WDT. Vytvořená úloha neprováděla maskování poruch nebo obnovu po poruše. Použitá diagnostická metoda nikterak nenarušila real-time chování celého systému. Tento čtvrtý experiment zároveň sloužil k porovnání metody MDA s ručně vytvořeným zdrojovým kódem. Úvodní fáze (zadání, analýza a návrh) jsou v obou případech shodné. Rozdíly se však projevují ve fázi implementace. Metoda MDA se snaží o postupný převod jednotlivých modelů (jejich upřesňování). Naproti tomu je ručně vytvořený zdrojový kód od prvopočátku pevně spjat s cílovou platformou. V případě vestavných systémů pracujících v reálném čase existuje celá řada faktorů, které je třeba zohlednit u modelů nezbytných pro MDA metodu. V případě, že má proces transformace proběhnout plně automatizovaně, je třeba vytvořit detailní popisy jednotlivých modelů a transformací. Mnohdy jsou však tyto popisy natolik složité, že je u nich vysoká pravděpodobnost vzniku skrytých chyb. Zatím neexistují nástroje, které by byly schopné odhalit tento druh chyb.

6

6

Přínos disertační práce

19

Přínos disertační práce

Za teoretický přínos disertační práce považuji návrh diagnostického podsystému vhodného pro vestavné systémy s omezenými výpočetními prostředky. Diagnostický podsystém umožňuje provádět průběžnou diagnostiku programového vybavení. Přes veškerou snahu a použití nejmodernějších metod pro tvorbu programového vybavení vestavných systémů mohou stále nastat nepředpokládané stavy v řídicích úlohách. Z tohoto důvodu je nezbytné provádět průběžnou diagnostiku programového vybavení. Získané diagnostické informace mohou sloužit k lokalizaci slabých míst v systému, optimalizaci výkonu systému a zvýšení jeho spolehlivosti. Diagnostický podsystém provádí detekci a lokalizaci poruch v reálném čase a není nutné provádět odstávku systému. Přístup k diagnostickým datům je zcela transparentní a data jsou k dispozici i pro pozdější zpracování. Za další teoretický přínos disertační práce považuji popis programového vybavení metodou MDA. Metoda MDA umožňuje popsat systém z dlouhodobého hlediska. Model programového vybavení vystihuje co má systém dělat, neřeší však, jak toho dosáhnout konkrétními technologiemi. Postupná transformace jednotlivých modelů vede až na automatické vygenerování zdrojového kódu. Metoda MDA umožňuje zvýšení inherentní spolehlivosti programového vybavení při změně použitých technologií během dlouhé životnosti vestavných systémů. V neposlední řadě se jedná o posun od tradičního způsobu návrhu vestavných systémů směrem k návrhu založeném na modelech a zvýšení stupně abstrakce náhledu na systém. Za praktický přínos disertační práce považuji použití jazyka MTL k transformaci UML modelů. V současnosti byl jazyk MTL nahrazen svým nástupcem jazykem Kermeta [16], který představuje další evoluční krok v oblasti transformace modelů. Za hlavní praktický přínos disertační práce považuji použití open-source programového vybavení u vestavných systémů. Praktické experimenty ukázaly plně vyhovující vlastnosti operačního systému Linux a dalšího open-source programového vybavení v řídicích úlohách. Vytvořená platforma pro diagnostický podsystém umožňuje provozování plnohodnotného operačního systému reálného času. Použitá součástková základna založená na modulech PC/104 nabízí další volitelná rozšíření tohoto systému. Díky kompatibilní architektuře s PC je k dispozici široké spektrum programového vybavení. Aplikace vytvořené na PC lze bez dalších úprav provozovat na modulech PC/104. Otevřená koncepce celého systému ho předurčuje k použití v dalších výzkumných projektech a výuce.

7

7

Závěr

20

Závěr

Disertační práce uvádí ucelený pohled na oblast diagnostiky programového a technického vybavení u současných výpočetních systémů. Práce je výsledkem několikaletého autorova snažení v oblasti návrhu vestavných systémů s volně šiřitelným programovým vybavením. K řešení cílů disertační práce byl zvolen operační systém Linux s rozšířením pro práci v reálném čase. Jsou popsány a ověřeny možnosti doplnění real-time chování do operačního systému Linux pro použití v řídicích aplikacích. Navržený diagnostický podsystém umožňuje provádět průběžnou diagnostiku řídicích úloh. Funkčnost navrženého systému byla experimentálně ověřena na úloze inteligentního diagnostického časovače. K vytvoření diagnostického podsystému byla použita metoda MDA. Pomocí metod dopředného a obousměrného vývoje byla provedena postupná transformace vstupních modelů v jazyce MTL. Výsledný automaticky generovaný zdrojový kód byl porovnán se zdrojovým kódem vytvořeným programátorem. Praktické experimenty uskutečněné při řešení disertační práce byly provedeny na vývojové platformě sestavené z modulů PC/104. Experimenty byly provedeny jak v laboratorních podmínkách, tak i během pilotovaných letů s bezpilotním prostředkem. Stanovené cíle disertační práce se podařilo naplnit. Stále však zůstává řada otevřených problémů k řešení a zlepšení. Jedná se např. o problém škálovatelnosti metody MDA a jejího plnohodnotného použití při návrhu programového vybavení a standardizaci diagnostických metod pro sledování chování programového vybavení v operačních systémech reálného času a řídicích úlohách.

8

Seznam v tezích použité literatury

8

21

Seznam v tezích použité literatury

[1] Brown, A. An introduction to Model Driven Architecture. [online], last revision 2004–02–17 [cit. 2006–06–14]. URL: . [2] Bureš, Z.; Čeleda, P.; Hrdlička, I.; Křivánek, V.; Mořkovský, T. Diagnostická ústředna – automatizovaný systém sběru dat u bezpilotního prostředku. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004. [3] Čeleda, P. Bezpečné programování - prevence vzniku bezpečnostních chyb v programech. Sborník konference – SVŘ5. VA Brno, 2004. [4] Čeleda, P. Zvýšení spolehlivosti operačních systémů pracujících v reálném čase. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004. [5] Cernosek, G.; Naiburg, E. The Value of Modeling. [online], last revision 2004– 10–29 [cit. 2006–06–14]. URL: . [6] Ganssle, J. Disaster! [online], poslední revize 1998–05 [cit. 2004–11–28]. URL: . [7] Ganssle, J. Disaster redux! [online], poslední revize 2004–09–12 [cit. 2004–11– 28]. URL: . [8] Harel,D.; Politi, M. Modeling Reactive Systems With Statecharts : The Statemate Approach. McGraw-Hill Companies, 1998. ISBN 0–07–026205–5. [9] Hlavička, J.; Kotek, E.; Zelený, J. Diagnostika elektronických číslicových obvodů. SNTL, 1982. ISBN 04–538–82. [10] Hlavička, J.; Racek, S.; Golan, P.; Blažek, T. Číslicové systémy odolné proti poruchám. ČVUT, 1992. ISBN 80–01–00852–5. [11] Kačmář, D. Operační systémy reálného času. Softwarové noviny, 2003. [12] Nikora, A.; Some, R.; Tamir, Y. Increasing Software Testability with Standard Access and Control Interfaces. ISSRE 2003 Fast Abstracts, 2003. [13] Object Management Group. OMG Model Driven Architecture. [online], poslední revize 2005–01–19 [cit. 2005–01–25]. URL: . [14] Přenosil, V.; Bureš, Z.; Čeleda, P.; Křivánek, V.; Rozehnal, D. Konfigurace mobilního retranslátoru. Závěrečná zpráva projektu obranného výzkumu ZÁZNAM II, Univerzita obrany, Masarykova univerzita v Brně, 2005. [15] Samek, M. Practical Statecharts in C/C++ : Quantum Programming for Embedded Systems. CMP Books, 2002. ISBN 1–57820–110–1. [16] Triskell Team. Kermeta language. [online], poslední revize 2007–02–14 [cit. 2007–02–19]. URL: .

9

9

Přehled publikovaných výsledků disertační práce

22

Přehled publikovaných výsledků disertační práce

Vystoupení na konferencích a články v časopisech [1] Čeleda, P.; Přenosil, V. Diagnostika programového vybavení pomocí inteligentních diagnostických časovačů. Sborník konference Opotřebení, spolehlivost, diagnostika 2006, ročník 15, 31.10-1.11 2006, s. 217-222, UO Brno, ISBN 80–7231–165–4. [2] Čeleda, P. Embedded systems and open source. Sborník konference XXVIII. konference EurOpen.CZ, ročník 28, s. 87-95, 21-24.5 2006, Chudenice u Švihova, ISBN 80–86583–10–4. [3] Bureš, Z.; Čeleda, P. Testovací a diagnostický systém pro benzinové spalovací motory. Sborník konference Technická diagnostika - DIAGON 2006. ročník 29, 11.5 2006, s. 75-80, UTB Zlín 2006. ISBN 80–7318–410–9. [4] Čeleda, P.; Koníř, T. Open-source programové vybavení pro průmyslové systémy. Automa - časopis pro automatizační techniku, březen 2006, roč. 12, č. 3, s. 106-108, ISSN 1210–9592 [5] Čeleda, P. Software diagnostics for embedded systems. Sborník konference Opotřebení, spolehlivost, diagnostika 2005, ročník 14, 25.-26.10 2005, s. 25-30, UO Brno, ISBN 80–7231–026–7. [6] Čeleda, P.; Koníř, T. Spolehlivost open-source programového vybavení. Sborník konference Technická diagnostika - DIAGON 2005. ročník 28, 26.4. 2005, s. 117-121, UTB Zlín 2005. ISBN 80–7318–293–9. [7] Čeleda, P. Operační systémy pracující v reálném čase. Sborník IEEE konference Radešín 2004:, 22-25.září 2004, roč. 2, s. 25-26. ISBN 80–214–2726–4. [8] Čeleda, P. Bezpečné programování - prevence vzniku bezpečnostních chyb v programech. Sborník konference – SVŘ5. VA Brno, 2004. [9] Čeleda, P.; Křivánek, V. Automatizovaný systém sběru dat u bezpilotního prostředku. Sborník konference Technická diagnostika - DIAGON 2004, ročník 27, 17.6. 2004, s. 116 120. UTB Zlín, 2004. ISBN 80–7318–195–9. [10] Čeleda, P. Zvýšení spolehlivosti operačních systémů pracujících v reálném čase. Sborník IEEE konference Radešín 2003, 8-11.října 2003, roč. 1, s. 116. ISBN 80–214–2479–6. [11] Čeleda, P. Přetečení paměti. DSM: data, security, management, 9. dubna 2003. roč. 7, č. 2, s. 24-27, ISSN 1211–8737.

Výzkumné zprávy [1] Přenosil, V.; Bureš, Z.; Čeleda, P.; Křivánek, V.; Rozehnal, D. Konfigurace mobilního retranslátoru. Závěrečná zpráva projektu obranného výzkumu ZÁZNAM II, Univerzita obrany, Masarykova univerzita v Brně, 2005. [2] Čeleda, P. Zvýšení spolehlivosti operačních systémů pracujících v reálném čase. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004. [3] Bureš, Z.; Čeleda, P.; Hrdlička, I.; Křivánek, V.; Mořkovský, T. Diagnostická ústředna – automatizovaný systém sběru dat u bezpilotního prostředku. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004.

Pavel Čeleda Teze disertační práce – Zvýšení spolehlivosti a diagnostika operačních systémů pracujících v reálném čase Grafická úprava a sazba Pavel Čeleda Univerzita obrany, Kounicova 65, 612 00 Brno. www: http://www.unob.cz e-mail: [email protected] Sazba programem LATEX 2ε . Neprošlo jazykovou úpravou. V Brně 2007, počet stran 26.

Zvýšení spolehlivosti a diagnostika operačních systémů pracujících v reálném čase

Recommend Documents