Teze disertační práce

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
Studijní program:
Studijní 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
Charakteristika současného stavu
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
Charakteristika současného stavu
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
Postup řešení cílů disertační práce
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
Postup řešení cílů disertační práce
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
Postup řešení cílů disertační práce
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
Postup řešení cílů disertační práce
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
Postup řešení cílů disertační práce
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
Experimenty v prostředí operačního systému
reálného času
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řijí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
Experimenty v prostředí operačního systému reálného času
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řijímače
Získaný záznam datových vět ve formátu NMEA z GPS přijímače byl předzpracován a byly vyloučeny neplatné záznamy (fáze kdy GPS přijí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řijí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
Experimenty v prostředí operačního systému reálného času
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
Experimenty v prostředí operačního systému reálného času
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
Experimenty v prostředí operačního systému reálného času
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řijí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
Výsledky disertační práce
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řijí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
Experimenty v prostředí operačního systému reálného času
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
Výsledky disertační práce
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: <http://www-128.ibm.com/
developerworks/rational/library/>.
[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: <http://www-128.ibm.com/developerworks/
rational/library/>.
[6] Ganssle, J. Disaster! [online], poslední revize 1998–05 [cit. 2004–11–28]. URL:
<http://www.ganssle.com/articles/disaster.htm>.
[7] Ganssle, J. Disaster redux! [online], poslední revize 2004–09–12 [cit. 2004–11–
28]. URL: <http://www.embedded.com//showArticle.jhtml?articleID=
55300689>.
[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: <http://www.uml.org/mda>.
[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: <http://www.kermeta.org/>.
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.