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

Transkript

1 Univerzita obrany Fakulta vojenských technologií Zvýšení spolehlivosti a diagnostika operačních systémů pracujících v reálném čase Disertační práce Školitel: prof. Ing. Václav Přenosil, CSc. Ing. Pavel Čeleda Brno 2007

2 Je mou milou povinností poděkovat všem, kteří přispěli k tomu, že tato práce vznikla. Především mému vedoucímu disertační práce prof. Ing. Václavu Přenosilovi, CSc. za celou řadu cenných nápadů, metodické vedení a věcné i metodické připomínky. Dále děkuji všem spolupracovníkům za vstřícnost a spolupráci při řešení jednotlivých částí disertační práce.

3 Prohlašuji, že jsem disertační práci zpracoval samostatně a vyznačil v ní všechny prameny, které jsem použil. Jsem si vědom následků nepravdivosti těchto údajů. V Brně dne 1. března

4 iv 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

5 v 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

6 vi Obsah 1 Úvod Formulace problému Cíle disertační práce Struktura disertační práce Charakteristika současného stavu Operační systémy reálného času Volba operačního systému reálného času Operační systém Linux Uplatnění operačního systému Linux v armádě Rozšíření reálného času pro operační systém Linux Real-time mikrojádro Monolitické jádro s real-time rozšířením Certifikace a dodržování platných norem Spolehlivost operačních systémů reálného času Inherentní spolehlivost programového vybavení Návrh a tvorba programového vybavení Testování a nasazení programového vybavení Diagnostika operačních systémů reálného času Systémy profylaktické diagnostiky Systémy funkční diagnostiky Možné metody řešení cílů disertační práce Zdroje chyb a poruch výpočetních systémů Výskyt poruch na úrovni součástek Výskyt poruch na úrovni technického vybavení Výskyt chyb v prostoru jádra operačního systému Výskyt chyb v uživatelském prostoru Metody diagnostiky programového a technického vybavení Metody návrhu spolehlivého programového vybavení N-násobné programování Bloky zotavení SIFT programově implementovaná odolnost Kontrolní diagnostické časovače a procesory Volba metody pro řešení cílů disertační práce Charakteristika navrhovaného systému Volba diagnostické metody Volba metody návrhu spolehlivého programového vybavení

7 vii 5 Diagnostický podsystém pro operační systémy reálného času Koncepce diagnostického podsystému Uživatelské rozhraní pro dohled nad systémem Hlavní diagnostická jednotka Řídicí jednotky se zabudovanými diagnostickými prvky Návrh diagnostického podsystému Diagnostické rozhraní operačního systému Systém diagnostických zpráv Správce diagnostických úloh Dopady na real-time vlastnosti systému Přenositelnost navrženého řešení Diagnostický časovač pro operační systémy reálného času Diagnostický časovač Výhody a nevýhody diagnostického časovače Programově realizovaný diagnostický časovač Inteligentní diagnostický časovač Model diagnostického podsystému Popis systému metodou MDA Platformově nezávislý model systému Model cílové platformy Platformově specifický model systému Generování zdrojového kódu Vývojová platforma pro diagnostický podsystém Volba koncepce bezpilotního prostředku Distribuované řízení v reálném čase Řídicí sběrnice pro UAV Modulární struktura s pevně definovaným rozhraním On-line záznam a komprimace dat Fyzická realizace UAV Experimenty v prostředí operačního systému reálného času Výpočetní systém postavený na modulech PC/ Vývojový řetězec pro platformu PC/ Experiment letiště Přerov Testování real-time vlastností OS Linux Experiment s diagnostickou sběrnicí pro real-time systémy Experiment s inteligentním diagnostickým časovačem

8 viii 10 Výsledky disertační práce s uvedením nových poznatků Diagnostický podsystém pro operační systémy reálného času Model diagnostického podsystému Vývojová platforma pro diagnostický podsystém Experimenty v prostředí operačního systému reálného času Konkrétní závěry pro využití výsledků práce v praxi a pro rozvoj vědního oboru Závěr 87 Přílohy 88 A Seznam použité literatury 89 B Generování zdrojového kódu 96 B.1 Zápis UML modelu v jazyce XML B.2 Zdrojové kódy transformace modelu v jazyce MTL B.3 Zdrojový kód úlohy producent - konzument v jazyce JAVA C Zdrojové kódy pro testování real-time vlastností OS Linux 103 C.1 Test na paralelním portu bez real-time podpory - rect.c C.2 Test na paralelním portu s real-time podporou - rtai.c D Inteligentní diagnostický časovač 106 E Obsah přiloženého CD 109

9 ix Seznam obrázků 1 Spektrum aplikací pracujících v reálném čase Vývoj spolehlivosti open-source programového vybavení [12] Mikrojádrová struktura Výskyt chyb a varování při překladu linuxového jádra řady 2.6 [16] Metodika vývoje programového vybavení metodou vodopád Zdroje poruch a místa výskytu chyb v rámci výpočetního systému Vliv kosmického záření na elektronické obvody Porucha trvalé nuly t Vztah mezi modelem a zdrojovým kódem Princip N-násobného programování Princip bloků zotavení Princip SIFT Diagnostický časovač Diagnostický procesor Architektura systémů odolných proti poruchám Vestavné systémy pracující v reálném čase Tři hlavní kroky pří vývoji metodou MDA Srovnání klasického a MDA přístupu vývoje programového vybavení Hierarchická struktura diagnostického podsystému Diagnostický podsystém operačního systému reálného času Řídicí proces s diagnostickým rozhraním Adresový prostor řídicího procesu Sběrnicová topologie Hvězdicová topologii Rozhodovací strom Návrh textového rozhraní správce diagnostických úloh Sledování toků na počítačové síti pomocí protokolu NetFlow [89] Vkládání testovacích vektorů do operačního systému reálného času Princip testování RTOS Princip monitorování RTOS Měření doby odezvy systému reálného času Princip diagnostického časovače Princip inteligentního diagnostického časovače Transformace modelů PIM na PSM a zdrojový kód Platformově nezávislý model úlohy producent - konzument Třívrstvá architektura použitého řešení Princip transformace modelu Architektura překladače BasicMTL Stavový diagram úlohy producent - konzument

10 x 40 Platformově specifický model po provedení transformace PSM model použitý při metodě obousměrného vývoje Bloková struktura UAV Centrální řídicí jednotka - procesorový modul PC/ První generace UAV v hornoplošním uspořádání Druhá generace UAV v provedení delta křídla Bloková struktura výpočetního systému postaveného na modulech PC/ Umístění elektronického vybavení na bezpilotním prostředku Bloková struktura výpočetního systému použitého během experimentu Průběh dosažené výšky zaznamenaný z GPS přijímače Průběh letu zaznamenaný z GPS přijímače ve 3D zobrazení Zapojení měřicího pracoviště během experimentu Test paralelního portu bez zátěže - běžný Linux Test paralelního portu se zátěží - běžný Linux Test paralelního portu bez zátěže - Linux s RTAI rozšířením Test paralelního portu se zátěží - Linux s RTAI rozšířením Zapojení pracoviště během testu diagnostické sběrnice s RTnet Zachycená komunikace v síti RTnet Princip měření doby zpoždění na síti Zapojení pracoviště během testu diagnostické sběrnice s rozhraním CAN Princip úlohy producent - konzument Stavový diagram úlohy producent - konzument Přepínání vláken v úloze producent - konzument

11 xi Seznam zkratek API ARP AST ARINC BDM BIOS CA CAN CBR CD CFC COTS CPLD CPU CRC CSMA/CD DÚ EAL ECC FPGA GNU GPL GPOS HTTP ICMP IDE IEEE IP IRQ ISA JM JTAG LGPL LiRE MIMOSA MDA MOF MOF NMEA NMR NVS NVP OMG OS PDM PIM Application Programming Interface Address Resolution Protocol Abstract Syntax Tree Aeronautical Radio, Inc. Background Debug Mode Basic Input Output System Collision Avoidance Controller Area Network Case-Based Reasoning Collision Detection Compact Flash Card Commercial Off-The-Shelf Complex Programmable Logic Device Central Processing Unit Cyclic Redundancy Check Carrier Sense Multiple Access / Collision Detection Diagnostická Ústředna Evaluation Assurance Level Error Correcting Codes Field Programmable Gate Array GNU s Not Unix General Public License General Purpose Operating System Hyper Text Transfer Protocol Internet Control Message Protocol Integrated Drive Electronics Institute of Electrical and Electronics Engineers Internet Protocol Interrupt Request Industry Standard Architecture Jednočipový Mikropočítač Joint Test Action Group Lesser General Public License Linux Real Time Environment Machinery Information Management Open Systems Alliance Model Driven Architecture Meta-Object Facility Model Transformation Language National Marine Electronics Association N-Modular Redundant N-Version Software N-Version Programming Object Management Group Operating System Platform Description Model Platform Independent Model

12 xii POSIX POST POV PSM QoS RAM RAMS RESO ROM RTAI RTEMS RTLinux RTOS SDCARD SEU SIFT SSH S.M.A.R.T. SOP TDMA TMPFS TMR UART UDP UML VGA VM VME WDP WDT Portable Operating System Interface for Computer Environments Power-On Self Test Projekt obranného výzkumu Platform Specific Model Quality of Service Random Access Memory Reliability, Availability, Maintainability, Safety REcomputing with Shifted Operands Read Only Memory Real-Time Linux Application Interface Real-Time Operating System for Multiprocessor Systems Real-Time Linux Real-Time Operating System Secure Digital Card Single Event Upset Software Implemented Fault-Tolerance Secure Shell Self-Monitoring, Analysis and Reporting Technology State-Oriented Programming Time Division Multiple Access Temporary Filesystem Triple Modular Redundant Universal Asynchronous Receiver / Transmitter User Datagram Protocol Unified Modeling Language Vnitřní grantová agentura Virtual Machine VERSAmodule Eurocard Watchdog Processor Watchdog Timer

13 1 Úvod 1 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í. Specifická oblast použití RTOS (automobilní a letecká technika, robotické systémy, náročné výrobní procesy atd.) podtrhuje tento fakt. 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 [29, 30]. Současná součástková základna poskytuje vše potřebné pro sestavení technického vybavení nutného pro provoz RTOS. K dispozici je celá řada procesorů, podpůrných periferií, pamětí, paměťových médií, programovatelných struktur atd. Vysoká spolehlivost, kterou se vyznačují, spojená se stále se zvyšujícími parametry garantovanými výrobci, často vede k zavádějící domněnce. Mohlo by se zdát, že hrozby poruch technického vybavení jsou dávnou minulostí, a že jediný zdroj chyb a notorických problémů v současnosti představuje programové vybavení. Pokud chceme hovořit o zvyšování spolehlivosti RTOS, je nutné mít neustále na paměti, že se jedná o kombinaci technického a programového vybavení a o jejich vzájemné interakci. 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. Jsou rozebrány důvody proč neustále vznikají chyby v programovém vybavení.

14 1 Úvod 2 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 POV Záznam II. 1.1 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 starých 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.

15 1 Úvod 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 je 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 jsou 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 je 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 je 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ží k ověření funkce navrženého systému v reálných podmínkách. Provedení experimentu vyžaduje běžně dostupný operační systém reálného času, podporující standard POSIX. Hlavními cíli experimentu jsou: 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.

16 1 Úvod Struktura disertační práce Struktura disertační práce vychází z doporučeného členění daného směrnicí děkana FVT UO pro studium doktorských studijních programů. Disertační práce je členěna následujícím způsobem: cíle disertační práce, přehled o současném stavu řešené problematiky a odborné literatury, která se zabývá zkoumaným problémem, zvolené metody zpracování, řešení cílů disertační práce, výsledky disertační práce s uvedením nových poznatků, konkrétní závěry pro využití výsledků práce v praxi a pro rozvoj vědního oboru.

17 2 Charakteristika současného stavu 5 2 Charakteristika současného stavu 2.1 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 [47]. non- real-time soft real-time hard real-time počítačová simulace uživatelské rozhraní internetové video řízení dopravy telekomunikace řízení let. provozu el. řízení motoru Obr. 1: Spektrum aplikací pracujících v reálném čase Vývoj v oblasti RTOS prošel od svých počátků až do současnosti řadou fází a období. Na samém počátku se jednalo o systémy napsané v jazyce symbolických adres řešící konkrétní úlohu (sadu úloh). Ze svého principu byly tyto systémy dlouhodobě špatně udržovatelné s omezenou přenositelností na další platformy. Většinou se jednalo o systémy vytvořené v rámci jedné firmy, jedním člověkem v lepším případě menší skupinou vývojářů. Důsledkem tohoto stavu bylo, že vzniklo velké množství různorodých RTOS, které v pozměněné podobě fungují dodnes. Stále u mnohých vývojářů přetrvává názor, že jsou schopni vytvořit lepší, spolehlivější, bezpečnější a levnější RTOS, než to co bylo doposud vytvořeno někým druhým ( mýtus superprogramátora ). Tato nemalá skupina proto neustále iniciuje vývoj nových a nových RTOS. Naštěstí pomalu dochází k odklonu od tohoto přístupu. Dalším obdobím byl postupný přechod k vyšším programovacím jazykům a povýšení původních jednoduchých systémů na plnohodnotné RTOS (víceúlohovost a preemptivnost, prioritní systém vláken a procesů, synchronizační mechanizmy atd.). Cílem byla hardwarová multiplatformnost, snadná přenositelnost programového vybavení a škálovatelnost výpočetního výkonu. Na poli RTOS se postupně etablovalo několik renomovaných firem [10]. Ve většině případů se jedná o vyspělé systémy osvědčené v celé řadě složitých aplikací. Vývoj RTOS systémů není levnou záležitostí a kvalita je vyvážena adekvátní cenou. Následující výčet představuje stručný přehled významných výrobců RTOS: Wind River (VxWorks) QNX Software Systems (QNX Neutrino) Green Hills Software (INTEGRITY) LynuxWorks (LynxOS) Microsoft Corporation (Windows CE)

18 2 Charakteristika současného stavu 6 Tlak po snižování výrobních nákladů vedl postupně ke dvou dalším změnám. První je snaha o nahrazení tradičních RTOS univerzálními operačními systémy (GPOS General Purpose Operating System) s omezenými možnostmi řízení v reálném čase. Druhou hybnou silou na poli RTOS se stalo používání otevřených standardů a otevřeného programového vybavení (open source) [94]. Jednoznačně v této oblasti dominuje operační systém Linux. Následující výčet představuje stručný přehled významných open-source projektů a komerčních řešení z nich vycházejících: Red Hat (ecos) OAR Corporation (RTEMS) MontaVista Software (MontaVista Linux) TimeSys (TimeStorm Linux) RTAI (Real-Time Linux Application Interface) FSMLabs (Real-Time Linux) Přehled srovnání trhu komerčních RTOS je uveden [83]. Vývoj v oblasti vestavných zařízení a operačního systému Linux je pravidelně sledován na serveru Linux- Devices.com [52]. Je nutné upozornit, že hodnotit kvalitu jednotlivých systémů podle prodejní úspěšnosti či ceny není příliš objektivní a smysluplné. Zastoupení jednotlivých RTOS na trhu může navíc znatelně ovlivnit typ cílové aplikace, kde se daný systém používá (např.: spotřební elektronika ve srovnání s avionikou letounu). Referenčním zdrojem pro porovnání vlastností jednotlivých systémů mohou být různé studie [3, 57, 64], vždy je však nutné pečlivě posoudit uveřejněné výsledky Volba operačního systému reálného času Problematika RTOS je velice obšírná. Z tohoto důvodu je v následujícím textu objasněna pouze geneze volby operačního systému, použitého během řešení disertační práce a je analyzován jeho současný vývoj. Při řešení vědeckých úkolů v rámci projektů VGA [14, 18] a POV [74] vyvstala jasná potřeba dostatečně výkonného a po stránce technického vybavení robustního výpočetního systému. Mělo se jednat o vestavný systém vhodný jak pro civilní, tak i vojenské aplikace. Použitá součástková základna měla být běžně dostupná a kompatibilní s širokým spektrem programového vybavení. Zvolil jsem procesorové moduly PC / 104, které lze libovolně rozšiřovat o další periferie. Vnitřní architektura shodná s PC umožňuje výrazně snížit čas a náklady potřebné pro vývoj. Vybrané moduly disponují integrovanými periferiemi přímo na hlavní desce a využívají procesory kompatibilní s Intel x86 se sníženou spotřebou. Samotné technické vybavení bez operačního systému a uživatelských programů je nepoužitelné. Požadavkům na řízení v reálném čase vyhověla pouze skupina operačních systémů reálného času. Hledaný RTOS by měl být použit pro podporu výzkumu, a protože se nejednalo o aplikovaný vývoj, nebyl výběr limitován dodržováním předpisů a norem, které by předem někdo jiný stanovil. Na druhou stranu bylo jasně stanoveno množství prostředků, které lze do daného systému investovat. Hlavním kritériem bylo dodržování otevřených standardů, umožňujících přenositelnost vytvořených aplikací a platformovou nezávislost. Výsledná aplikace vytvořená na jedné platformě by měla být bez větších problému použitelná i na ostatních podporovaných platformách (cross platform development). Přes řadu nabídek výrobců komerčních RTOS byl zvolen OS Linux, doplněný o podporu real-time apli-

19 2 Charakteristika současného stavu 7 kací. Možnost vysledovat z volně dostupného zdrojového kódu, proč se daný program chová, tak jak se chová, popř. co dělá s danou periferií, otevírá nedozírné možnosti s ohledem na další výzkum, vývoj a výuku. Po počátečním tápání a nezdarech jsem zprovoznil první použitelnou verzi OS Linux na modulech PC / 104. Záhy však vyvstala podstatná otázka: Jak demonstrovat spolehlivost a doložit kvality použitého operačního systému?. Kritéria pro výrobce RTOS jsou jasně stanovena. Uznávané instituce vydávající osvědčení garantující dodržení patřičné normy či nikoliv. Podpora otevřených standardů a snaha o snížení nákladů vysunuly OS Linux do popředí zájmu zákazníků (armáda, státní sektor, průmyslové společnosti atd.) a tvůrců programového vybavení. Tento fakt vedl k řadě polemik. Na jedné straně stojí zarputilí zastánci (výrobci) proprietárních systémů poukazující na slabiny Linuxu, na druhé straně odborná veřejnost, nemající nic mimo pozitivních praktických zkušeností. K prezentovaným závěrům je třeba přistupovat s rozvahou viz obr. 2. Tvorba OS a zejména RTOS je velice náročnou úlohou, odpovídající nárokům, které požadujeme od výsledných aplikací. Nadšení pro daný OS by nemělo vést k bezmyšlenkovitému prosazování toho či jiného řešení. velká malá komunita uživatelů vysoká složitost nízká čas spolehlivost Obr. 2: Vývoj spolehlivosti open-source programového vybavení [12] Je důležité otevřeně říct, že samotný Linux není RTOS a nikdy ani nebude. Existuje avšak několik přístupů a řešení, jak doplnit podmínky nutné ke splnění požadavků na RTOS. Důkazem toho, že Linux proniknul i do oblasti RTOS, lze vysledovat z chování předních výrobců těchto systémů. Přes nesčetné pochybnosti a prohlášení o nevhodnosti Linuxu pro RTOS aplikace ve vestavných systémech se situace mění. Nejedná se o žádný módní výstřelek, nýbrž o seriózní aktivity několika organizací a institucí. Určitě se neschyluje k revoluci, kdy by Linux nahradil stávající systémy etablovaných výrobců. Do budoucna lze očekávat heterogenní systémy, kde budou jednotlivé systémy navzájem nasazeny. velká komunita vývojářů malá

20 2 Charakteristika současného stavu Operační systém Linux Linux je svobodný operační systém unixového typu, který byl původně vytvořen Linusem Torvaldsem (1991) a je dále rozvíjen za pomoci vývojářů z celého světa. Šíření Linuxu je prováděno pod licencí GNU General Public License [94], takže jeho zdrojový kód je volně k dispozici každému. Vývoj Linuxu je směřován, aby bylo dosaženo co největší kompatibility s normou POSIX [68]. Linux byl původně napsán pro architekturu IBM PC s procesorem i386 a vyšším. V dnešní době jsou podporovány platformy ARM, DEC Alpha, SUN Sparc, M68000, MIPS, PowerPC a další. Jedná se o plnohodnotný víceuživatelský a víceúlohový operační systém. Ve skutečnosti Linux je pouze holé jádro operačního systému. Celý systém je složen ze dvou hlavních částí. První je již zmiňované jádro a druhou část tvoří systém GNU (GNU s Not Unix) u jehož zrodu stál Richard Stallman (1984). Cílem Stallmana bylo vytvoření operačního systému unixového typu na bázi svobodného programového vybavení. V rámci GNU projektu postupně vznikla adekvátní náhrada programového vybavení dostupného na proprietárních unixových systémech. Jediné co scházelo bylo jádro operačního systému. Spojení linuxového jádra a systému GNU dalo za vznik plnohodnotnému operačnímu systému. Správné označení proto zní GNU/Linux a je takto i propagováno GNU komunitou. Zkrácený název Linux se natolik vžil, a ač terminologicky nesprávně, je ve valné většině případů používám pro označení celého operačního systému. V textu disertační práce je použit zkrácený název a pokud to není výslovně řečeno, je míněn celý operační systém Uplatnění operačního systému Linux v armádě V polovině devadesátých let minulého století Ministerstvo obrany Spojených států amerických (MO USA) odstartovalo COTS iniciativu. Cílem bylo snížení nákladů, potlačení závislosti na jednom dodavateli, zlepšení technických parametrů a zkrácení doby vývoje nových armádních systémů. Použití COTS komponent umožnilo plynulé nasazování nejmodernějších technologií do vyspělých armád. Pro armádní dodavatele to znamenalo přechod od proprietárních k otevřeným technologiím, dodržování standardů (POSIX) a použití běžně dostupného technického vybavení (VME, PC). COTS přístup můžeme popsat následující větou: Pokud již existuje vhodné zařízení (program, OS atd.), je použito místo vlastního drahého vývoje něčeho podobného. Nezanedbatelnou část nákladů každého moderního systému tvoří částka, která se platí za programové vybavení. Zde se postupně začal prosazovat i Linux do armádních aplikací. Hlavním důvodem byl fakt, že se jedná o volně dostupný operační systém unixového typu s podporou normy POSIX. Linux v roli serverů a klientských stanic začal významněji konkurovat ostatním OS a ohrožovat jejich dosavadní výsadní pozici. Snad nejkontroverznější otázka vyvstala v souvislosti s otevřeným zdrojovým kódem systému a jeho bezpečností. Jakou úroveň standardu EAL je Linux schopen garantovat? Lze ho nějakým způsobem vůbec certifikovat pro úroveň EAL-7? Je nutné podotknout, že v současnosti neexistuje COTS OS, který by byl certifikován pro úroveň vyšší jak EAL-4 [60]. Snahou předních výrobců OS je dosáhnout co nejdříve úrovně EAL-7. Situace však pro Linux není nikterak ztracena. Nic totiž nebrání

21 2 Charakteristika současného stavu 9 tomu, aby byl Linux používán nad mikrojádrem s patřičnou certifikací. Konkrétní kroky v této oblasti již podniklo francouzské Ministerstvo obrany. Na podzim roku 2004 bylo oznámeno spuštění tříletého programu, s cílem vytvořit systém založený na OS Linux garantující EAL-5 [55] Rozšíření reálného času pro operační systém Linux Jádro Linuxu bylo od začátku vyvíjeno pro potřeby univerzálního operačního systému s omezenými možnostmi řízení v reálném čase. Navržená struktura monolitického jádra je optimalizována na průměrný výkon (dobu odezvy) se zaměřením na serverové a desktopové úlohy. Samotné monolitické linuxové jádro není vhodné pro hard real-time řízení. Obliba Linuxu však vedla ke vzniku aktivit, umožňujících jeho použití ve vestavných systémech a přiblížení se splnění podmínek kladených na RTOS. Nastolený trend je nejlépe vidět u současné řady jádra 2.6, kde došlo k začlenění preemptivní podpory do jádra a snížení celkové doby odezvy systému. Jedná se o reakci na potřeby multimediálních aplikací. Zásadní změny se dočkala i škálovatelnost jádra s ohledem na vestavné systémy a jejich podporu. Dosažené výsledky lze řadit do oblasti soft real-time. Přes požadavky uživatelů byla Linusem Torvaldsem jasně odmítnuta úprava jádra (přepsání) na RTOS jádro. Determinované chování jádra a splnění RTOS podmínek lze přesto dosáhnout dvěma principiálními způsoby: kombinací real-time mikrojádra a monolitického jádra Linuxu, doplněním monolitického jádra o POSIX real-time rozšíření IEEE Real-time mikrojádro Myšlenka doplnění real-time podmínek je velice jednoduchá. Spočívá v oddělení malého real-time jádra od původního monolitického jádra Linuxu. Klasický Linux následně běží jako proces s nejnižší prioritou (idle process) nového real-time jádra. Hlavními zástupci jsou: RTAI Real-Time Linux Application Interface [75], RTLinux Real-Time Linux [27]. Uživatelské úlohy meziprocesová komunikace Jádro Linuxu Úlohy reálného času RTAI - mikrojádro Hardware Obr. 3: Mikrojádrová struktura Tvůrci RTLinuxu si nechali způsob doplnění real-time vlastností patentovat a začali s komerční distribucí produktu RTLinuxPro. Tento počin vedl k nevoli ostatních uživatelů. Důsledkem byl vznik projektu RTAI, který využívá stejný princip, ale je volně distribuován pod licencí LGPL

22 2 Charakteristika současného stavu 10 a GPL (původní kód z projektu RTLinuxu). Princip mikrojádra je úspěšně použit v řadě proprietárních RTOS. Srovnání obou variant real-time rozšíření OS Linux je uvedeno v [5, 64]. Praktické ověření naplnění deklarovaných real-time vlastností je popsáno v [51]. Výsledkem studie je konstatování, že pouze monolitické jádro s mikrojádrovým rozšířením je schopno splnit podmínky kladené na hard real-time aplikace. Zásadní nevýhodou mikrojádrového přístupu je potřeba specifického návrhu (úpravy) řídicí aplikace s ohledem na mikrojádro. Existují ale řešení, kompenzující tento nedostatek. Použití dvou jader ale není vždy žádoucí a často aplikace nepožadují zaručení hard real-time podmínek. V neposlední řadě hraje i roli nevyjasněná situace kolem patentu spojeného s RTLinuxem Monolitické jádro s real-time rozšířením Doplnění real-time vlastností v tomto případě znamená úpravu monolitického jádra o real-time rozšíření definované normou IEEE Preemptivní jádro s upraveným plánovačem, obsluhou hardwarových přerušení (IRQ), přepínání vláken atd. je pak schopno garantovat patřičné odezvy. Hlavním zástupcem na tomto poli je firma MontaVista Software, Inc., která se aktivně podílí na vývoji a integraci výsledků v této oblasti. Důkazem toho je vývojová řada jádra 2.6, která neustále rozšiřuje podporu preemptivních vlastností Linuxu. Výhodou monolitického jádra s real-time rozšířením je fakt, že není třeba dalších úprav z pohledu aplikace a jádra. Využití lze očekávat v oblasti firm real-time aplikací (časově kritický přenos dat, multimédia, jednoduché řízení atd.). Tvůrci slibují do budoucna dosažení odezvy systému v desítkách až stovkách mikrosekund Certifikace a dodržování platných norem Jak již bylo zmíněno v bodě 2.1.3, jednou z nejdůležitějších vlastností, kterou požadují náročné aplikace, je certifikace a dodržení norem pro danou kategorii zařízení. Získání patřičného certifikátu je každým výrobcem náležitě prezentováno a vyzdvihováno. Zde lze jmenovat např. normy ARINC 653, DO-178B, RAMS, ČSN 5012x, ANSI/UL 1998 aj. Z informací dostupných na Internetu vyplývá, že dostupná linuxová řešení získávají velice pomalu tyto certifikáty. Dynamický vývoj monolitického jádra v podstatě neumožňuje rozumnou certifikaci. Množství oprav a rozšíření, které jsou denně přidávány do zdrojového kódu jádra, představují vážnou hrozbu vzniku nových chyb. Nezanedbatelný faktor hraje i současná velikost jádra, která se pohybuje v řádech MiB. V budoucnu se dá spíše očekávat vývoj směrem k certifikovanému mikrojádru, nad kterým bude spuštěn Linux [42]. Význam certifikátů a dodržování norem jako etalonu kvality je zcela nezpochybnitelné. Praxe však poskytuje řadu příkladů, kdy i systémy splňující vše potřebné zklamaly a mnohdy se podařilo zabránit katastrofě jen dílem náhody. Jako příklad lze uvést chybu u sondy Mars Pathfinder s operačním systémem VxWorks. Po úspěšném přistání na planetě Mars se začal spontánně resetovat její centrální řídicí procesor. Naštěstí se chybu podařilo odstranit a sonda úspěšně splnila svoji misi [45].

23 2 Charakteristika současného stavu Varování Chyby Varování Chyby Obr. 4: Výskyt chyb a varování při překladu linuxového jádra řady 2.6 [16] 2.2 Spolehlivost operačních systémů reálného času Definice spolehlivosti prošla složitým historickým vývojem a i dnes má celou řadu různých interpretací a je používána v nejrůznějších souvislostech [37, 38, 73]. Spolehlivost je souhrnný termín používaný pro popis pohotovosti a činitelů, které ji ovlivňují: bezporuchovost, udržovatelnost a zajištěnost údržby. Tato definice reaguje na skutečnost, že schopnost objektu plnit požadované funkce není zpravidla determinována jen vlastnostmi samotného objektu, ale významně tuto schopnost ovlivňují i vnější činitelé, například míra zajištěnosti požadované údržby. Pojem spolehlivost je používán pouze pro obecný popis a takto definovanou spolehlivost nelze kvantifikovat a souhrnně vyjádřit žádným číselným ukazatelem. Její jednotlivé dílčí činitele, např. pohotovost, bezporuchovost a udržovatelnost však již kvantifikovaně hodnotit možné je pomocí konkrétních ukazatelů. Pojem spolehlivost je často používán s různými přívlastky, přičemž takto vzniklé pojmy nejsou v platných terminologických normách definovány např. ČSN Proto zde bude objasněn význam alespoň tří následujících pojmů které jsou důležité: Inherentní spolehlivost je spolehlivost vložená do objektu v průběhu jeho návrhu a výroby. Nezahrnuje zhoršující vlivy provozních podmínek, podmínek prostředí, způsobů údržby, lidského faktoru a pod. Provozní spolehlivost je spolehlivost s uvážením vlivů provozních a jiných podmínek. Odhadovaná (predikovaná) spolehlivost je spolehlivost, která je výsledkem výpočtů, analýz a prognóz spolehlivosti projektovaného objektu. Je tedy výsledkem použitých metod odhadu, vstupních informací o spolehlivosti prvků, použitého výpočtového modelu spolehlivosti systému, schopností a možností analytika provádějícího odhad a pod.

24 2 Charakteristika současného stavu 12 Pohotovost je schopnost objektu být ve stavu schopném plnit požadovanou funkci v daných podmínkách, v daném časovém okamžiku nebo v daném časovém intervalu, za předpokladu, že jsou zajištěny požadované vnější prostředky. Pohotovost je komplexní vlastnost, zahrnující bezporuchovost, udržovatelnost a zajištěnost údržby. Vnějšími prostředky, které jsou v definici uvedeny, se rozumí prostředky údržby, jiné požadované vnější prostředky pohotovost neovlivňují. Bezporuchovost je schopnost objektu plnit požadovanou funkci v daných podmínkách a v daném časovém intervalu. Obecně se předpokládá, že na začátku časového intervalu je objekt ve stavu schopném plnit požadované funkce. Kritériem pro ukončení schopnosti plnit požadovanou funkci je nastoupení jevu porucha. Udržovatelnost je schopnost objektu v daných podmínkách používání setrvat ve stavu, nebo vrátit se do stavu, v němž může plnit požadovanou funkci, jestliže se údržba provádí v daných podmínkách a používají se stanovené postupy. Jedná se tedy o schopnost objektu být udržován v provozuschopném stavu prováděním preventivní a nápravné údržby. Zajištěnost údržby je schopnost organizace poskytující servisní služby zajišťovat podle požadavků v daných podmínkách prostředky potřebné pro údržbu podle dané koncepce údržby. Jde tedy o schopnost organizace zajišťující údržbu objektu zajistit všechny potřebné prostředky jako jsou aktualizace programového vybavení, náhradní díly, spotřební materiál, diagnostické prostředky, kvalifikovaní pracovníci atd. v souladu se stanovenou koncepcí údržby 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í. Řešená problematika v rámci disertační práce je směřována právě na tuto oblast. Postupem času vznikla řada teorií a přístupů jak dosáhnout určitého stupně zvýšení spolehlivosti. Některé zůstaly na akademické úrovni, jiné se podařilo úspěšně prosadit do praxe. Přesto neustále dochází k chybám v programech. Důvodů, proč se tvůrci dopouští těchto chyb, je celá řada. Snahou všech je vytvořit funkční programové dílo, výsledky jsou však často rozdílné. Úměrně tomu dochází i ke vzniku potencionálně nebezpečných konstrukcí v kódu programu [17]. Jaké jsou důvody proč tyto chyby neustále vznikají? 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

25 2 Charakteristika současného stavu 13 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 Návrh a tvorba programového vybavení Návrh a tvorba programového vybavení v současnosti zahrnuje následující kroky (metodika vývoje typu vodopád ) [49]: zadání analýza návrh implementace testování nasazení Obr. 5: Metodika vývoje programového vybavení metodou vodopád Během prvních tří etap je specifikován navrhovaný systém (specifikace požadavků, analýza, návrh a modelování). Cílem je sdělení a ujasnění si představy o systému který vzniká mezi jednotlivými účastníky tohoto procesu (zadavatel, systémový analytik, programátor atd.). Výsledkem je obsáhlá dokumentace v textové a grafické podobě. Uznávaným prostředkem používaný k tomuto účelu se stal jednotný jazyk pro modelování (UML Unified Modeling Language [67]). Jazyk UML se skládá ze skupiny diagramů (diagram tříd, objektů, případů užití, stavů, sekvencí atd.). Model jazyka UML říká, co má systém dělat. Neříká však, jak to má udělat. Čtvrtá etapa představuje promítnutí původního návrhu do konkrétní realizace. Při tomto kroku, který se odehrává na úrovni zdrojového kódu, však časem dochází ke stále většímu oddálení se od původní dokumentace. Jak systém po několik let roste, jsou změny prováděny pouze na nejnižší tj. programové úrovni. Úpravy nejsou zpětně promítány do původní dokumentace vytvořené během prvních tří etap (časové důvody). Je věcí názoru, jestli má význam provádět tyto úpravy, protože všechny další změny budou provedeny znovu na úrovni zdrojového kódu. Tento přístup je jednou ze základních myšlenek extrémního programování [44], kde je tvorba zdrojového kódu a testování považováno za hybnou sílu vývoje. Bohužel vše funguje dobře pokud je projekt ve fázi vývoje a jeho tvůrci ho mají v hlavě. Běžná praxe ukazuje, že po ukončení vývoje původní tým zaniká a další údržbu řeší někdo jiný. Dotyčný pak musí zpětně z vytvořeného kódu zjišťovat jak program pracuje. Během implementace dochází k vazbě na konkrétní technologie. Pokrok nelze zastavit a tak se musí výrobci přizpůsobit a řídit podle stavu nejnovějších technologií.

26 2 Charakteristika současného stavu 14 Důvody k přechodu na nové technologie mohou být následující: jsou požadovány zákazníky, řeší konkrétní problémy, které staré přístupy neumožňovaly, ukončení podpory pro stávající technologie ze strany dodavatele. Následkem je rychlá devalvace technologií a produktů na nich založených. Kvalitě produktu moc nesvědčí častá změna použité technologie a její různé verze. Zpětná kompatibilita je v mnohých případech jen velice omezená. U vestavných zařízení kde se očekává dlouhá doba životnosti, vysoká spolehlivost a pouze drobné funkční úpravy, je nevhodné se ustavičně přizpůsobovat novým technologiím. Mnohem přijatelnější je konzervativní přístup, kdy vývoj je prováděn na určité úrovni použitých technologií i za cenu důsledků z toho plynoucích. Závěrečnou fází implementace je tvorba programové dokumentace. Cílem je získat informační zdroj umožňující do budoucna snadnou orientaci v navrženém systému. Ze strany vývojářů je na tento problém pohlíženo jako na nutné zlo, ale jsou to právě oni, kdo ví o systému nejvíce. Každá změna v systému by se měla promítnout do patřičné změny dokumentace. Zde je nutné rozlišovat dva typy dokumentace. První popisuje obecný systém, je vytvořena na počátku a je udržována ručně. Druhou tvoří popis, jak došlo k samotné implementaci na úrovni zdrojového kódu. Zde je vhodné, aby tato část dokumentace byla automaticky vytvářena z informací obsažených ve zdrojovém kódu [35, 81]. Poslední dvě etapy vývoje programového vybavení jsou popsány v následujícím bodu disertační práce Testování a nasazení programového vybavení Etapa testování [69] a ověření funkce slouží k odhalení chyb a nedostatků navrženého programového vybavení. Na rozdíl od technického vybavení (např. logické obvody) nelze u programu sestavit úplný test, který by deterministicky ověřil jeho správnost. Místo toho je voleno postupné testování na několika úrovních, které je schopné odhalit případné nedostatky. Jedná se o následující typy testování: Statické testování zdrojový kód programu, který je syntakticky a sémanticky správně, může ještě obsahovat celou řadu skrytých chyb. Odhalení těchto chyb představuje použití nástrojů pro statickou analýzu zdrojového kódu programu [32, 79]. Detekce chyb je prováděna bez toho, aby byl program spuštěn. Dynamické testování detekce chyb je prováděna na spuštěném programu. deterministické sada známých testovacích vektorů je automaticky aplikována při každé změně programu [25]. Cílem je ověřit zachování dosavadní funkčnosti a zjistit jestli provedená změna nemá negativní dopady na stávající systém. stochastické (injekce chybových dat) metoda je založena na testování, jak se zachová program, když se mu předloží určitý vzorek vstupních dat včetně nekorektních. Testovací vektory jsou vytvářeny náhodně a na program je pohlíženo jako na černou skříňku, která má korektně obsloužit zadaná data [9, 50]. Žádná z výše uvedených metod nemůže plně nahradit znalosti, kterými musí disponovat člověk tvořící spolehlivé programové vybavení. Je zřejmé, že do budoucna dojde k rozšíření o analytické metody testování.

27 2 Charakteristika současného stavu 15 Metody formální analýzy a verifikace systémů se pomalu stávají součástí dnešního vývoje moderního programového vybavení. Jedná se o perspektivní metodu automatizovaného ověřování vlastností navrhovaného systému, u něhož je kladen důraz na bezchybnou funkci a vysokou spolehlivost. Formální metody řeší problém bezchybného modelu, ale nemají vliv na finální podobu (zdrojový kód), který se podle daného modelu vytvoří. Úskalím testování v reálných podmínkách je možnost narušení konzistence systému, na kterém je testování prováděno. Klasický přístup testování na PC není zcela vhodný k odzkoušení nevratných i dočasných poruch technického vybavení, které může být časově a finančně velice náročné. Na druhou stranu tento způsob testování umožňuje získat celou řadu zajímavých poznatků a výsledků. Velice užitečná se jeví myšlenka použití virtuálního stroje, uvnitř něhož je spuštěn operační systém a ostatní aplikace [24]. Problematika nasazení programového vybavení je dlouhodobě známá a je spojována s provozními a logistickými problémy. Zajímavé téma se otevřelo s rozšířením síťových technologií, které umožňuje distribuci přes Internet. To vyžaduje, aby programy (jejich aktualizace, bezpečnostní záplaty atd.) byly uloženy na bezpečném místě, kde nemůže dojít k jejich neautorizované modifikaci (podvržení). 2.3 Diagnostika operačních systémů reálného času Diagnostikou se rozumí nauka, která se zabývá studiem a metodami vyhledávání znaků nějakého rodu a druhu a symptomů skutečných nebo možných špatných funkcí živého či neživého objektu. Diagnostiku tedy tvoří oblast znalostí, která zahrnuje teorii a metody organizace procesu diagnózy a také principy konstruování prostředků diagnózy. Jestliže objekt, jehož stav určujeme, je technického charakteru, potom hovoříme o technické diagnostice [43]. Technická diagnostika poskytuje objektivní informace o provozním stavu objektu či o potřebách jeho údržby a průběhu doby života [36, 80]. Technickou diagnostikou se rozumí diagnostika bezdemontážní a nedestruktivní. Při zkoumání technického stavu diagnostikovaného objektu se rozlišují následující typy úloh: zjištění současného stavu diagnostikovaného objektu v reálném čase (diagnóza), detekce poruchy (identifikace poruchy), lokalizace poruchy (určení místa poruchy), předvídání technického stavu diagnostikovaného objektu (prognóza), analýza příčin poruchy diagnostikovaného objektu (geneze). Diagnóza je popsána diagnostickým pokrytím (hloubkou detekce) a diagnostickým rozlišením (hloubkou lokalizace), které udávají počet detekovaných a lokalizovaných poruch při realizaci daného diagnostického algoritmu. Diagnostickou veličinou bývá nejčastěji jednoduchá, měřitelná fyzikální veličina, charakterizující stav objektu diagnostiky. Diagnostikovaný objekt lze dále členit na dílčí části, konající určitou funkci. Technická diagnostika rozlišuje bezvadný, provozuschopný a poruchový stav zkoumaného objektu. Bezvadný stav je takový stav objektu, kdy všechny parametry splňují předem dané podmínky (tolerance) a diagnostikovaný objekt plní zadané funkce. Jestliže jsou v tolerancích pouze hlavní parametry objektu, je stav hodno-

28 2 Charakteristika současného stavu 16 cen jako provozuschopný. Pokud ani všechny hlavní parametry nemají předepsanou velikost, je stav hodnocen jako porucha objektu. Principy technické diagnostiky: Objektivnost souvisí s požadavky na jednoznačnost a opakovatelnost výsledků. Opakovaná diagnostická kontrola objektu, nacházejícího se v jednom a tomtéž technickém stavu musí vést ke stejnému výsledku. Diagnóza musí být určena pouze na základě stavu objektu a nesmí záviset na subjektivních vlivech pozorovatele. Racionálnost spočívá v tom, že měření se provádí pokud možno bezdemontážní a nedestruktivní formou. Demontáž a opětovná montáž jsou operace velice nákladné a časově náročné. V případě demontáže se projevuje nepříznivý vliv nutnosti odstavení objektu a zpětného uvedení do provozu. Diagnostickým systémem je chápán organizovaný soubor tvořený objektem diagnostiky, diagnostickými prostředky, jejich obsluhou a souborem pracovních postupů (diagnostických algoritmů). Je určen k realizaci diagnostického procesu, tj. k objektivnímu zjišťování technického stavu objektů diagnostiky pomocí zvolených diagnostických metod. Jsou rozlišovány dva druhy diagnostických systémů: Systémy profylaktické diagnostiky (off-line) jsou systémy, u kterých je objekt během diagnostikování mimo provoz. Podměty na objekt přichází od diagnostického prostředku. Algoritmy diagnostikování testem se dělí na nezávislé (kombinační) a závislé (sekvenční). U nezávislých testů je sled jednotlivých kroků testu nezávislý na výsledcích předcházejících kroků testu. Závislý algoritmus testu realizuje kroky testu v závislosti na výsledcích předcházejících kroků. Systémy funkční (provozní) diagnostiky (on-line) jsou v činnosti, když je objekt v normální činnosti. Jsou schopné nejen rozpoznat dočasné poruchy, ale také sledovat postupné zhoršování některých diagnostických veličin a náležitě reagovat. Na současné výpočetní systémy nelze z hlediska diagnostiky pohlížet jako na jeden celek. Existují veliké rozdíly v chápání a používání diagnostiky u jednotlivých typů systémů. Odlišný přístup je uplatňován u vestavných systémů, high-end serverů nebo stolních počítačů. Původní význam diagnostiky byl spojován s nízkou spolehlivostí součástkové základny a z ní sestavených počítačů. Vzhledem ke zvyšující se spolehlivosti součástek, cenovým relacím a omezeným možnostem opravy se původní poslání diagnostiky v tomto smyslu mění. Dnešní vývoj se ubírá více směrem k monitorování provozu, sledování programového vybavení, detekci a zotavení po dočasných poruchách. V dalším textu bude rozebrán aktuální stav s ohledem na vestavné systémy. Předpokládají se systémy umožňující provoz plnohodnotného operačního systému. Funkce operačního systému jsou využívány pro potřeby diagnostiky, popř. rozšířeny o nezbytné programové vybavení Systémy profylaktické diagnostiky Testovaný systém je během prověřování práceschopnosti mimo provoz. Při tomto stavu je však možnost diagnostikování integrovaných obvodů tvořících počítač velice omezená. Po zapnutí napájecího napětí dojde k nežádoucímu spuštění systému.

29 2 Charakteristika současného stavu 17 Tomu lze zabránit tím, že pomocí vnějšího podnětu se zařízení při zapnutí přepne do diagnostického režimu. Následuje ověření funkce jednotlivých funkčních bloků. Prověřování lze provést např. příznakovým analyzátorem, číslicovým osciloskopem, logickou sondou atd. Vše je však podmíněno znalostí zkoumaného systému, která v dnešní době COTS systému je většinou velice problematická. Výrobci si úzkostlivě střeží tyto informace a pokud je prověřování na této úrovni nutné, řeší se speciálním přípravkem daného výrobce. Tento stav lze označit za nevyhovující. Vazba na jednoho konkrétního výrobce a existence řady diagnostických zařízení nemusí být vždy žádoucí. Většina moderních součástek disponuje rozhraním JTAG (Joint Test Action Group). Za návrhem stojí skupina výrobců integrovaných obvodů, usilující o vytvoření standardu pokrývající metodiku testování integrovaných obvodů [82]. Jedná se o transparentní a jednoduché řešení, v současnosti hojně využívané k vývoji zařízení na bázi programovatelných struktur, jednočipových mikropočítačů a signálových procesorů. V případě výpočetních systémů má popsaný přístup velice nízkoúrovňový charakter. Svůj smysl má během vývoje, testování a výroby. Nejeví se však příliš racionální jej použít při běžném provozu. Zde poskytuje on-line diagnostika dostatečné prostředky na ověření funkce. Pokud dojde k detekci poruchy, je z ekonomického a spolehlivostního hlediska snazší nahradit nefunkční blok novým Systémy funkční diagnostiky Funkční diagnostika předpokládá spuštěný systém, který je průběžně prověřován. Je rozlišována diagnostika technického a programového vybavení. Navzdory faktu, že je snaha od počátku systém navrhnout s co největší inherentní spolehlivostí, nelze vyloučit, že dojde k jeho nepředpokládanému selhání. Nezbytná on-line diagnostika spojená s monitorováním systému může poskytnout informace použitelné pro dohledání zdroje poruchy nebo k nastavení optimálního výkonu systému. Intrusivním monitorováním (intrusive monitoring) je označován případ, kdy diagnostický algoritmus využívá zdroje sledovaného systému. Mechanizmy diagnostického algoritmu přitom mohou ovlivňovat chování sledovaného systému. Druhou variantu tvoří systémy neintrusivního monitorování (nonintrusive monitoring). Sledování systému je prováděno pasivně přídavnými prostředky, neovlivňujícími vlastní chování systému. Neintrusivní monitorování je často jediným přijatelným zdrojem informací pro dokazování (v právním smyslu) skutečných příčin poruchy. Diagnostika technického vybavení Na technické vybavení lze pohlížet jako na prostředky (zdroje) OS, které jsou přidělovány jednotlivým procesům. Přidělením zdroje OS přichází o exklusivní přístup a diagnostický algoritmus může být ovlivňován chováním nového vlastníka. Všechny zdroje by proto měly disponovat mechanizmy umožňující určitou formu sdílení diagnostických informací. Optimální je stav, pokud diagnostické testy běží autonomně bez toho, aby docházelo k poklesu výpočetního výkonu, nebo dočasného pozastavení funkce diagnostikovaného objektu. Prvotní diagnostika je provedena po zapnutí zařízení, kdy dojde k ověření funkce jednotlivých funkčních bloků (CPU, paměťový podsystém, systém přerušení atd.).

30 2 Charakteristika současného stavu 18 Testy jsou provedeny před samotným spuštěním OS a jsou součástí firmwaru základní desky (např. BIOS u PC) popř. zavaděče OS. Doba provozu OS (up-time) může u vestavných systémů dosáhnout i několika let. V závislosti na prostředí kde je systém provozován, dochází k postupnému stárnutí součástek. Současná součástková základna zatím neposkytuje dostatečný zdroj informací o životnosti součástek přímo na čipu [11]. Je snaha integrovat vestavěnou diagnostiku a monitorovací funkce zařízení přímo na úrovni obvodů. Lze najít zařízení umožňující monitorování teploty CPU, pevné disky s technologií S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology), on-line diagnostiku s možností rekonfigurace zařízení atd. Diagnostika technického vybavení systému vyžaduje patřičnou podporu ze strany použitých komponent, která v případě vestavných systémů nemusí být vždy k dispozici. Různé diagnostické testy mohou negativně ovlivňovat real-time vlastnosti provozovaného OS. Diagnostika programového vybavení Současné systémy se omezují na průběžné sledování provozních parametrů. Pokud dochází k ukládání získaných dat, jsou tato data ukládána v různých často nekompatibilních formátech. Výsledkem je množství dat, která nejsou nikterak následně zpracována (absence predikční diagnostiky). Většinou dojde na zpracování až poté, co došlo k nějakému problému. Častým zjištěním je, že dat je příliš mnoho a jediné co přinesla bylo naplnění databáze, kde jsou uložena. O standardizaci ukládaných diagnostických dat se snaží projekt MIMOSA [58]. Monitorovací nástroje jsou schopné sledovat chování spuštěných procesů. OS poskytují prostředky a nástroje na průběžný dohled nad spuštěnými úlohami. Neexistuje však možnost detailního systematického sledování chování jednotlivých úloh. Většinou se jedná o řešení, kdy z vnějších příznaků chování úlohy (např. nadměrné zatížení CPU, výpadek spojení, selhání aplikace atd.) se určuje stav, ve kterém se nachází. Detailnější informace o stavu jádra a jednotlivých úloh vyžaduje doplnění diagnostického rozhraní do zdrojového kódu. V současnosti má většina informací charakter chybových hlášení oznamujících výskyt chyby. Neexistuje návrh standardu řešící provázanost mezi aplikací a jádrem OS, který by umožňoval diagnostikovat běžící aplikaci, popř. jednotlivé části jádra OS. Současná diagnostika programového vybavení neumí rozlišit, kdy si systém spontánně ubližuje sám sobě (defektní senzor, deadlock atd.) nebo se jedná o něčí úmysl (cílený útok).

31 3 Možné metody řešení cílů disertační práce 19 3 Možné metody řešení cílů disertační práce 3.1 Zdroje chyb a poruch výpočetních systémů Technické a programové vybavení výpočetních systémů může selhat a řada příkladů z praxe ukazuje, že k tomu stále dochází. Protože vzniku chyb nelze plně zabránit, je třeba potenciální rizika minimalizovat a připravit se na výskyt nových chyb. Je nutné znát charakteristiky a chování chyb k tomu, aby došlo k omezení jejich následků na co nejmenší míru. Tento přístup umožňuje vytvořit systémy, v nichž jednotlivé chyby nepovedou ke změnám chování systému či jeho totálnímu selhání. Různé zdroje poruch mohou vyvolat vznik chyb na několika úrovních. V dalším textu disertační práce bude pod pojmem porucha, chápán stav respektive děj v technickém vybavení. U programového vybavení bude pojem chyba chápán jako projev poruchy v činnosti systému, který nemá přímý zdroj v nespolehlivosti technických prostředků, např. chyba ve zdrojovém kódu programu. programové vybavení (aplikace) - procesy - knihovny - odolné prog. vybavení - SIFT (TMR, NMR) zdroje poruch vstupní data uživatel špatné časování porucha SW v jádře rekonfigurace SW programové vybavení (RTOS) - jádro OS - plánovač - sdílení zdrojů RTOS - zotavení po chybě zdroje poruch přetečení paměti inverze priorit kompromitace RTOS porucha HW rekonfigurace HW technické vybavení (HW) - CPU (registry) - paměť - CRC, hlasování - redundance (NMR) zdroje poruch rušení odchylky na napájení špatné časování dočasná porucha reinicializace HW součástková základna - tranzistory - zesilovače - reset - power-down zdroje poruch záření (kosmické,...) mechanické namáhání místo poruchy oprava chyby Obr. 6: Zdroje poruch a místa výskytu chyb v rámci výpočetního systému Výskyt poruch na úrovni součástek Zdrojem poruch na úrovni součástek může být kosmické záření. To obsahuje prakticky všechny druhy částicového a elektromagnetického záření. Kosmické záření je schopno vyvolat radiační poškození všech možných látek, včetně biologické tkáně, elektroniky apod. Poněvadž je povrch Země chráněn atmosférou, nejsou tyto efekty

32 3 Možné metody řešení cílů disertační práce 20 příliš patrné a prokazatelné v této oblasti. Ale už u vysoko létajících objektů (letadla, družice) byly naměřeny zcela evidentní efekty, které se týkaly např. zvýšeného ozáření posádek letadel a družic a také možnosti poškození součástek elektronických systémů. Jedná se o následující typy interakcí částic. Nabité částice (protony, ionty, elektrony) interagují hlavně s elektronovým obalem, který excitují a ionizují. Část těchto poškození se reparuje. Těžké nabité částice mohou způsobit i vznik vakancí nebo intersticiálů. Nabité částice rychle ztrácejí energii a proto se např. dovnitř letadla nedostanou. Neutrony interagují téměř výlučně s jádrem a mohou způsobit vznik vakancí a intersticiálů. Sekundární částice vzniklé jadernou reakcí (protony, ionty vzniklé tříštěním, neutrony) generují poškození stejným mechanizmem. Neutrony se dostanou s vysokou pravděpodobností dovnitř letadla. Kosmické neutrony mohou mít vysokou energii (desítky až stovky MeV). Pokud se srovná tato energie s energií vazby atomů v mřížce nebo vazební energií nukleonu v jádře, lze konstatovat, že trefí-li se neutron, může udělat značné poškození. Fotony interagují hlavně s obalem (elektrony) a jejich účinek je obecně nižší, ale nikoli nulový vzhledem k vysokým energiím, které mohou mít. Stupeň poškození je zcela zanedbatelný pokud jde o mechanické poškození, ale nemusí být zanedbatelný pokud jde o možné změny elektrických vlastností součástek zejména s vysokou hustotou integrace. Je to logické, protože při eventuální interakci se zvyšuje poměr počet poškození ku počtu všech atomů součástky. Jev který způsobuje vznik poruch na úrovni součástek se v anglické literatuře nazývá SEU (Single Event Upset) [39, 59]. Stejného efektu lze docílit v laboratorních podmínkách, pokud je součástka vystavena stimulovanému toku částic např. z cyklotronu. clk_in clk_out Obr. 7: Vliv kosmického záření na elektronické obvody Výskyt poruch na úrovni technického vybavení Poruchy v číslicových systémech jsou způsobeny jednak vlastní nedokonalostí součástek, jednak nedodržením stanovených provozních podmínek nebo nevhodnou aplikací součástek. První druh poruch se nazývá poruchy z vnitřních příčin, druhý druh poruchy z vnějších příčin. Detailní popis poruch elektronických číslicových obvodů je uveden v [36]. Příčiny vnitřních poruch v číslicových systémech: poruchy integrovaných obvodů (poruchy na čipu, pouzdra atd.), poruchy spojů na desce tištěných spojů, poruchy propojů mezi deskami, konektory atd.

33 3 Možné metody řešení cílů disertační práce 21 A & t 0 B 1 F C & Obr. 8: Porucha trvalé nuly t 0 Příčiny vnějších poruch v číslicových systémech: elektrické, mechanické a klimatické přetížení, nesprávná montáž, kolísání odběru a síťového napětí, odrazy na spojích, přeslechy mezi spoji, přerušení vodivé cesty (signálové spoje, napájecí napětí, země, zkrat). Následky poruch v číslicových systémech: přerušení vodivé cesty, zkraty, zhoršení statických parametrů, zhoršení dynamických parametrů Výskyt chyb v prostoru jádra operačního systému Jádro je základním prostředkem pro ovládání technického vybavení počítače. Jeho úkolem je správa a poskytování výpočetních zdrojů ostatním úlohám v systému. Jsou rozlišovány dva základní koncepty jádra: monolitické jádro a mikrojádro. V prvním případě jsou všechny funkce jádra (správa paměti, řízení procesů, souborový systém, správa síťových rozhraní atd.) realizovány velkým monolitickým jádrem. Monolitické jádro je jednodušší na návrh a implementaci. Výhodou tohoto uspořádání je rychlý přístup na technické vybavení a efektivnost systému. Nevýhodou je úzká vazba mezi jednotlivými systémovými komponentami (sdílení společného paměťového prostoru), což v případě výskytu chyby v jedné části systému znamená selhání celého systému. Mikrojádro je jádro operačního systému, které obsahuje jen základní funkčnost pro běh operačního systému. Typicky obsahuje pouze správu paměti a správu řízení procesů. Ostatní funkční bloky jako správa souborového systému, správa síťových rozhraní, apod. je v operačním systému s mikrojádrem řešena formou samostatných procesů. Výhodou tohoto uspořádání je, mimo jiné, vyšší schopnost operačního systému se udržet v chodu i poté, co dojde v některém z podsystémů k závažné chybě. Na druhou stranu existuje větší režie při přepínání mezi jádrem a procesy. Většina soudobých jader operačních systémů je napsaná s ohledem na výkonnost, často v programovacích jazycích umožňující vznik skrytých chyb (ASM, C, C++). Pokud dojde k výskytu opravitelné chyby, potřebuje operační systém nějaký čas na zotavení, což může být časově kritické pro správné chování RTOS.

34 3 Možné metody řešení cílů disertační práce 22 Nejčastější zdroje chyb v prostoru jádra: paměťový podsystém přidělení, uvolnění nebo vyčerpání paměti, přetečení vyrovnávací paměti, zápis mimo platný paměťový prostor (chyba segmentace), plánování a řízení procesů inverze priorit, zamykání a zablokování (deadlock), přidělení, uvolnění nebo vyčerpání zdrojů, plánování a řízení zdrojů (periferií) zamykání a zablokování (deadlock), přidělení, uvolnění nebo vyčerpání zdrojů, synchronizace procesů jádra konkurenční přístup k datům a zařízením, meziprocesová komunikace, překročení časového limitu (timeout), konfigurace zdrojů chybějící nebo nesprávná konfigurace (inicializace), přetížení (zahlcení) systému neodevzdání procesoru, nevhodné programové konstrukce, bezpečnostní pravidla přístupová práva, odmítnutí služby Výskyt chyb v uživatelském prostoru V případě, že dojde k výskytu chyby, tak jádro OS by mělo být schopné, korektně ošetřit vzniklou situaci. V uživatelském prostoru vystupuje jako jeden z hlavních iniciátorů chyb samotný uživatel. Nejčastější zdroje chyb v uživatelském prostoru: paměťový podsystém přidělení, uvolnění nebo vyčerpání paměti, přetečení vyrovnávací paměti, zápis do cizího paměťového prostoru (chyba segmentace), synchronizace procesů konkurenční přístup k datům a zařízením, meziprocesová komunikace, překročení časového limitu (timeout), souborový systém nekonzistentní (narušená) data, neexistující data, špatná přístupová práva, zneužití systému získání neoprávněného přístupu do systému, manipulace se systémem, podvržení dat.

35 3 Možné metody řešení cílů disertační práce Metody diagnostiky programového a technického vybavení Diagnostické metody [36, 37] používané v systémech odolných proti poruchám, mohou mít jednu z následujících forem: spouštěcí diagnostika, periodická diagnostika, průběžná diagnostika, diagnostika redundantních částí. Spouštěcí diagnostika je soubor diagnostických testů spouštěných automaticky při zapnutí napájecího napětí. Jejich úkolem je prověřit v co nejkratší době všechny možné důležité funkce systému a signalizovat případnou poruchu. Jedná se pouze o detekční testy, které navíc často nebývají úplné. Děje se tak především tehdy, když aplikace nedovoluje příliš odkládat okamžik zahájení provozu systému. Periodická diagnostika se provádí v přestávkách mezi aplikačními programy. Po dobu testu tedy musí být výpočet na určitou dobu přerušen, aby systém mohl být podroben testu. Výsledkem takového testu je úplná informace o technickém stavu testované jednotky v okamžiku provedení testu. Není však zaručeno, že tento stav se nezmění ani během následujícího výpočtu až do okamžiku příštího testu. Proto je třeba volit periodicitu testů tak, aby pravděpodobnost vzniku poruchy mezi dvěma po sobě následujícími provedeními testu byla dostatečně malá. Periodická diagnostika se obvykle provádí programovými prostředky. Průběžná diagnostika představuje nepřetržitý zdroj informací 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. Určitou nevýhodou průběžné diagnostiky je závislost rozsahu získané informace o technickém stavu objektu na řešeném problému. Průběžná diagnostika signalizuje jen takové poruchy, které se projevily chybou při výpočtu. Tím vzniká nebezpečí výskytu latentních poruch, které mohou později nepříznivě ovlivnit výpočet. Diagnostika redundantních částí se provádí proto, že bez informací o technickém stavu záložních prvků vzniká riziko, že některý z těchto prvků bude nepoužitelný ve chvíli, kdy je třeba na něj přenést funkci. Záložní prvky jsou většinou vystaveny stejným podmínkám jako prvky provádějící vlastní řízení, takže u nich nelze předpokládat nulovou intenzitu poruch. 3.3 Metody návrhu spolehlivého programového vybavení Vývoj programového vybavení je spjat s řadou metod. Na počátku 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ň

36 3 Možné metody řešení cílů disertační práce 24 abstrakce a prostředky pro popsání chování a vlastností systému. Na obr. 9 jsou znázorněny různé vztahy mezi modelem a zdrojovým kódem [13, 19]. pouze vizualizace obousměrný kód kódu 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. 9: Vztah mezi modelem a zdrojovým kódem Model neexistuje v dnešní době se jedná o nejčastěji používanou metodu vývoje. Tvůrci programového vybavení vytváří model zápisem programových konstrukcí v programovacím jazyce, který používají (C, C++, Java atd.). Pokud je používáno modelování, je zcela neformální a intuitivní a existuje ve formě vývojových diagramů, popisu funkce systému nebo přímo v hlavách vývojářů. Tento přístup je použitelný při řešení jednoduchých problémů v rámci malé skupiny vývojářů. Problematické však již začíná být, pokud narůstá složitost řešeného problému či dojde k rozrůstání skupiny vývojářů. Kód je modelem zdrojový kód je převeden do podoby diagramů (reverse engineering). Tato grafická reprezentace umožňuje snazší porozumění vnitřního strukturování a chování aplikace. Vzniklé diagramy jsou úzce spjaté se zdrojovým kódem a představují alternativní způsob jak nahlížet na zdrojový kód, popř. jak ho editovat. Kód a model koexistují obousměrný vývoj (roundtrip engineering) umožňuje koexistenci abstraktního modelu systému a zdrojového kódu. Vývojář vytvoří úvodní model systému, který transformuje do podoby zdrojového kódu. Transformace může být provedena buď ručně nebo automaticky pomocí generátoru zdrojového kódu. Vzniklý kód lze následně upravovat a zpětně transformovat (přidat) do modelu. Aby bylo možné provádět průběžné slučování modelu a zdrojového kódu, je nutné vložit do zdrojového kódu identifikační značky. Na základě těchto značek, je možné rozlišit mezi kódem, který vytvořil programátor a strojově generovanou částí. Model je kódem transformace modelu (forward engineering) umožňuje převést model na plnohodnotný zdrojový kód. K tomu je nezbytné, aby model obsahoval všechny informace nutné k automatickému generování zdrojového kódu. Modelování se proto provádí pro celou oblast řešeného problému. Pokud dochází k navazování na stávající technologie, jsou též modelovány všechny rozhraní integrující jednotlivé části systému. K popisu systému se používají návrhové vzory [28], umožňující snadnou transformaci modelu na zdrojový kód. Základ modelů tvoří programové konstrukce vytvořené programátory, které jsou doplněny o další entity modelu. Kód neexistuje model slouží vývojářům jako pomocný prostředek pro pochopení řešeného problému nebo analýzu navrhovaného řešení. Modely jsou používány k vzájemné komunikaci mezi skupinami vývojářů. Často vznikají ve fázi návrhu nových projektů. Slouží k prezentování řešených problémů třetím stranám a popisu používaného pojmového aparátu. V praxi pak finální realizace často diverguje od původního modelu.

37 3 Možné metody řešení cílů disertační práce N-násobné programování Metoda N-násobného programování [1] definuje proces, kdy podle společného zadání dojde k nezávislému vytvoření N 2 funkcionálně shodných programů. Programy jsou vykonávány souběžně (běží paralelně) a ve stanovených bodech jsou generovány testovací vektory. Vektory jsou přivedeny na vyhodnocovací člen, kde je provedeno vyhodnocení pomocí rozhodovacího algoritmu a výsledek je postoupen k dalšímu zpracování. Metoda N-násobného programování vychází z metody NMR (N-Modular Redundant) navržené pro technické vybavení. Programové vybavení je vytvářeno nezávisle, tj. jednotliví vývojáři (skupiny) vzájemně nekomunikují při práci na konkrétní variantě programového vybavení. Pokud možno jsou používány rozličné algoritmy, programovací jazyky a vývojové nástroje. Počáteční společné zadání musí obsahovat všechny informace nezbytné k popsání řešeného problému: funkční specifikaci jednotlivých verzí, rozhodovací algoritmus (algoritmy), odezvu na výsledek rozhodování, formáty speciálních dat, vektory rozhodování - určují obsah srovnávaných dat, body vzájemné kontroly - určují okamžiky vytváření vektorů rozhodování, indikace stavů rozhodování - popisují režim činnosti jednotlivých verzí, synchronizační protokol. Samotní vývojáři mají následně, co největší volnost, jak zadaný problém vyřešit. Metoda N-násobného programování umožňuje tolerovat jak chyby způsobené poruchou technického vybavení, tak i obecné chyby, tj. chyby v zadání a algoritmizaci. X i a verze č. 1 X a j X b i verze č. 2 rozhodovací algoritmus b X j n X i verze č. n n X j Obr. 10: Princip N-násobného programování Bloky zotavení Metoda bloků zotavení [1, 37] je programovou analogií technické dynamické zálohy. Základním principem metody je rozdělení programu do statických bloků. Každý z bloků je tvořen několika různými podprogramy, které realizují stejný výpočet podle různých algoritmů. Výpočet v bloku postupuje tak, že se nejprve provede řešení

38 3 Možné metody řešení cílů disertační práce 26 podle první z variant a testem přijatelnosti se ověří jeho správnost. Správný výpočet je v rámci bloku dokončen. V případě chyby při výpočtu podle první varianty se použije druhá varianta, opět se vyhodnotí atd. Nesprávný výpočet ve všech variantách znamená vyčerpání možností zotavení uvnitř bloku a musí následovat přechod k zotavení na vyšší úrovni. varianta č. 1 vstup paměť zotavení varianta č. 2 test přijatelnosti výstup splněn varianta č. n nesplněn přepnutí na další variantu Obr. 11: Princip bloků zotavení SIFT programově implementovaná odolnost Princip metody SIFT (Software Implemented Fault-Tolerance) [37] je modifikací původní obvodové realizace NMR tak, že je zachována statická redundance, ovšem rozhodovací mechanizmy a řízení jsou zajištěny programy. Procesy jsou v systému zálohovány tak, že je spuštěno několik instancí úlohy, které běží paralelně a částečně synchronizovaně. Ve stanovených intervalech každá instance komunikuje s ostatními instancemi. Během komunikace se instance vzájemně informují o stavu výpočtu. Majorizovaná data jsou použity při výpočtu. Data dále umožňují, aby řídicí program získal informace o stavu jednotlivých instancí a případně je synchronizoval. vstup instance č. 1 instance č. 2 vyhodnocovací člen výstup instance č. n Obr. 12: Princip SIFT SIFT umožňuje tolerovat stálé i nestálé poruchy. Detekce a izolace chyby je pružná a celkem snadno se udržuje i celkový přehled o chybovosti systému. Tím se zjednodušuje případná rekonfigurace systému. Programové hlasování je ve srovnání s obvodovým pomalejší, což může být v některých případech na závadu.

39 3 Možné metody řešení cílů disertační práce Kontrolní diagnostické časovače a procesory Metoda je založena na interakci programového a technického vybavení. Do zdrojového kódu programu jsou vloženy kontrolní body (obsluha diagnostického časovače nebo generování příznaků pro diagnostický procesor), ve kterých dochází ke kontrole správné funkce systému. Jednodušší přístup počítá s kontrolním obvodem diagnostického časovače WDT (Watchdog Timer) [71]. Jedná se o monostabilní klopný obvod nebo jeho funkční ekvivalent, který je programově spouštěn. Do programu jsou vloženy instrukce pro jeho spuštění tak často, aby se stále udržoval v dočasném stavu. Při poruše ve vykonávání programu lze s velkou pravděpodobností očekávat, že dojde k výpadku ve spouštění WDT a obvod se překlopí zpět do stabilního stavu. Tím je generováno hlášení o poruše. Výstupem WDT je zpravidla generován nulovací impulz počítače a tím může být celý program (systém) nastartován znovu od začátku. oscilátor čítač CY S Q porucha nulování R & 1 programové nulování RESET Obr. 13: Diagnostický časovač Metoda využívající diagnostického procesoru WDP (Watchdog Processor) [53] je založena na tom, že zdrojový kód je doplněn o příznaky indikující místo, kde se právě program nachází. Jedná se o rozšíření původní metody s diagnostickým časovačem. Diagnostický procesor provádí průběžný dohled nad systémem a v případě, že detekuje chybu při vykonávání programu (control flow checking), ohlásí ji nadřízené vrstvě (procesoru). kontrolovaný procesor chyba diagnostický procesor systémová sběrnice příznaky operační paměť v/v zařízení Obr. 14: Diagnostický procesor

40 4 Volba metody pro řešení cílů disertační práce 28 4 Volba metody pro řešení cílů disertační práce Realizace systémů odolných proti poruchám je kombinací programového a technického vybavení. O vlastnostech a koncepci navrženého řešení rozhodují jak všeobecné charakteristiky daného systému, tj. jeho architektura, způsob nasazení a využití, tak i bližší specifikace rušivých vlivů, jimž má systém úspěšně odolávat. V oblasti programování systémů odolných proti poruchám se uvažují nejen poruchy technického vybavení, ale i chyby v programech, chyby v interakci s prostředím, zneužití či poškození systému. Na obr. 15 je uvedena základní architektura systémů odolných proti poruchám. Chování systému je v pořádku, jestliže je výpočet správný a zároveň platí: program není trvale zastaven ani změněn vlivem poruchy, výsledky jsou bez chyb způsobených poruchou, výsledky jsou dodány včas, tedy doba výpočtu je uvnitř stanovených mezí. architektura systémů odolných proti poruchám technická redundance informační redundance časová redundance programová redundance statická hybridní TMR NMR dynamická parita detekce CRC korekce ECC opakovaný výpočet RESO N-násobné programování bloky zotavení kontrolní body watchdog nezatížená odlehčená zatížená Obr. 15: Architektura systémů odolných proti poruchám 4.1 Charakteristika navrhovaného systému Navrhovaný 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 bude mít 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 [34] (např. diagram stavů v jazyce UML). Převod na zdrojový kód lze uskutečnit např. metodou SOP (State-Oriented Programming) [78]. Předpokládané nasazení systému lze očekávat např. v oblasti nepřetržitého řízení technologických procesů nebo v avionických řídicích systémech. Dohled nad systémem bude dvouúrovňový. Základní dohled bude provádět samotný systém, tj. systém by měl být schopen průběžně rozpoznávat stav ve kterém se nachází a v případě detekce chyby ji lokalizovat a opravit. Druhou úroveň bude tvořit operátor,

41 4 Volba metody pro řešení cílů disertační práce 29 vestavné systémy operační systémy reálného času vestavné systémy pracující v reálném čase Obr. 16: Vestavné systémy pracující v reálném čase který bude mít možnost provést manuální korekci chování systému. Výměna informací mezi dohledovými prvky uvnitř systému bude strojově orientovaná. Výstupní data pro operátora budou převedena ze strojové do operátorovi srozumitelné podoby. Chyby, které mohou v systému vzniknout lze rozdělit do tří základních kategorií (detailněji viz kap. 3.1): chyby v návrhu chyby programového vybavení, chyby technického vybavení, logické chyby, fyzikální poruchy chyby výroby, chyby opotřebením, chyby vzniklé rušením, chyby interakce zneužití systému, chyby na vstupu. Cílem disertační práce není pokrýt celé spektrum rušivých vlivů (zdrojů poruch), které mohou na systém působit. Systém by měl být odolný vůči poruchám v důsledku výskytu chyb v programovém vybavení. Další možné zdroje chyb a poruch nebudou uvažovány. Jejich ošetření (potlačení) se předpokládá pomocí metod používaných u systémů odolných proti poruchám viz obr Volba diagnostické metody V dosavadním textu disertační práce byly popsány různé metody a způsoby jak provádět diagnostiku technického a programového vybavení výpočetních systémů (viz kap. 2.3 a 3.2). Bylo uvedeno, že cíle disertační práce jsou směřovány do oblasti diagnostiky programového vybavení. Konkrétně se jedná o oblast řídicích úloh spuštěných nad RTOS. Snahou je průběžně sledovat chování úloh a v případě detekce chyby, systém udržet v práce schopném stavu. Kritéria kladená na diagnostický systém: detekce stanovené množiny poruch, které se mohou v systému vyskytnout, lokalizace poruchy, která způsobila chybu,

42 4 Volba metody pro řešení cílů disertační práce 30 včasné odhalení poruchy, aby systém mohl zareagovat, klasifikace chyby podle příčin jejího vzniku. Z metod uvedených v kap. 3.2, se jeví jako adekvátní pro řešení cílů disertační práce metoda průběžné diagnostiky. Metoda poskytuje nepřetržitý zdroj informací o správnosti operací prováděných v systému. U technického vybavení na kterém bude výsledný systém provozován (COTS zařízení), nelze uvažovat s podporou diagnostických prostředků na straně technického vybavení. Principy metody průběžné diagnostiky bude proto nutné upravit tak, aby šly realizovat čistě programovým řešením. Popis metody průběžné diagnostiky uvedený v kap. 3.2, je velice obecný. Proto bude dále v textu disertační práce detailněji rozvedena problematika v následujících oblastech: zdroje diagnostických informací, předávání diagnostických informací v systému, vyhodnocení diagnostických informací, reakce na zjištěný stav systému. 4.3 Volba metody návrhu spolehlivého programového vybavení V kap. 3.3 byly uvedeny základní metody, jak je možné přistupovat k návrhu a tvorbě zdrojového kódu. Většina uvedených metod používaných pro programové vybavení systémů odolných proti poruchám, využívá principu redundance. Redundantní části jsou buď identické (metoda SIFT) nebo různorodé (metoda N-násobného programování a metoda bloků zotavení). Průběžné výsledky jsou vyhodnocovány (test přijatelnosti, hlasování na majoritním členu) a případné chyby se systém snaží maskovat. Společným bodem pro všechny metody je jednotné zadání popisující systém. Na základě zadání pak mohou vznikat různé varianty programového vybavení. Logicky vyplývá, že čím větší bude počet různých variant programu, tím větší budou nároky na výpočetní zdroje systému a lidské zdroje, které systém musí vytvořit a udržovat. Odpovídajícím způsobem se pak tyto faktory promítají do výsledné ceny systému. Myšlenka vytváření programového vybavení pomocí modelů je základem metody MDA (Model Driven Architecture) [65]. MDA je překládána do českého jazyka jako modelem řízená architektura a představuje koncepci pro vývoj programového vybavení definovaného skupinou OMG (Object Management Group). Klíčovou funkci tvoří model (jednotné zadání), který je základem pro vývoj (modelování) navrhovaného systému. Metoda MDA se svými vlastnostmi jeví jako vhodná pro návrh spolehlivého programového vybavení. Vytvoření diagnostického podsystému pomocí metody MDA Výsledkem první části disertační práce je navržená koncepce diagnostického podsystému. Pro samotný experiment s metodou MDA není vhodné od počátku pracovat s tak komplexním modelem. Mnohem racionálnější se jeví zvolit dílčí diagnostický algoritmus vycházející z navrženého diagnostického podsystému. Cílem je, aby sestavená testovací úloha (aplikace doplněná o diagnostický algoritmus) dostatečně

43 4 Volba metody pro řešení cílů disertační práce 31 demonstrovala použitou diagnostickou metodu a umožnila snadno zkoušet různé postupy v rámci MDA. Testovací úloha bude zpočátku popsána modelem PIM (Platform Independent Model) vytvořeným v jazyce UML. Následnou postupnou transformací dojde k převodu do platformově specifického modelu PSM (Platform Specific Model). Poslední krok bude představovat převod modelu PSM na zdrojový kód použitelný na cílové platformě. PDM popis platformy PIM PSM KÓD funkční popis transformace platformově závislý popis transformace zdrojový kód Obr. 17: Tři hlavní kroky pří vývoji metodou MDA 1) PIM platformově nezávislý model: volba dílčí a samostatně funkční úlohy v rámci diagnostického podsystému, návrh modelu PIM diagnostického algoritmu v jazyce UML, návrh modelu PIM testovací úlohy v jazyce UML. 2) PSM platformově specifický model: návrh modelu PDM (Platform Description Model) cílové platformy, volba transformační metody pro převod modelu PIM PSM, postupná transformace modelu PIM PSM. 3) zdrojový kód: volba metody generování zdrojového kódu, vytvoření zdrojového kódu z PSM modelu, statická analýza a překlad zdrojového kódu. teoretický iterační proces praktický průběh vývoje zadání analýza návrh implementace testování nasazení text diagramy a text diagramy a text zdrojový kód zdrojový kód MDA proces zadání analýza návrh implementace testování nasazení text PIM PSM zdrojový kód zdrojový kód Obr. 18: Srovnání klasického a MDA přístupu vývoje programového vybavení Etapa vzájemné transformace jednotlivých modelů mezi sebou, završená vygenerováním zdrojového kódu, se dosud prováděla ručně. Cílem MDA je tento proces zautomatizovat pomocí transformačních nástrojů. Řada výrobců vývojových

44 4 Volba metody pro řešení cílů disertační práce 32 a transformačních nástrojů tvrdí, že jejich produkt podporuje MDA. Ve skutečnosti se však jedná o dílčí pokrytí problematiky MDA a přitom cena těchto nástrojů často dosahuje nemalých částek. Problematika MDA je v současnosti v samých počátcích a řada nutných nástrojů stále chybí. Je otázkou, nakolik se tento problém v budoucnu podaří vyřešit. Mnoho nástrojů je v různých fázích rozpracování a vzájemná nekompatibilita je běžným problémem současného programového vybavení. Snahou je použití MDA nástrojů k naplnění cílů disertační práce, není však uvažován vlastní vývoj MDA nástrojů.

45 5 Diagnostický podsystém pro operační systémy reálného času 33 5 Diagnostický podsystém pro operační systémy reálného času Současné vestavné systémy používají různé přístupy pro testování, monitorování a diagnostikování svého chování. Cílem je získat ucelené informace o stavu systému. V závislosti na konkrétní platformě a aplikaci se lze setkat s prostředky jako jsou diagnostické časovače, spouštěcí diagnostika (POST Power-On Self Test), testy paměti, monitorování zdrojů a výkonu atd. Používané diagnostické metody, však stále postrádají podporu pro programové řešení ekvivalentní s IEEE [41] (IEEE Standard Test Access Port and Boundary Scan Architecture). IEEE slouží k diagnostice elektronických obvodů s vysokým stupněm integrace. Jedná se o průmyslový standard pro který se vžilo označení JTAG a stejným jménem je i označováno diagnostické rozhraní integrované v obvodech s vysokým stupněm integrace (FPGA, CPLD, MCU, CPU atd.). Vestavné systémy jsou často limitované množstvím dostupných výpočetních zdrojů a velikostí výsledné aplikace. Množství požadavků kladených na tyto systémy (přesné časování, spolehlivost, bezpečnost, výkon, cena atd.) jasně stanovuje směry a priority při návrhu těchto systémů. Diagnostický podsystém představuje součást systému, která není přímo zapojena do řídicího procesu, ale může mít zásadní vliv na chování systému. 5.1 Koncepce diagnostického podsystému V kap. 4.1 byla uvedena základní charakteristika navrhovaného systému. Diagnostický podsystém bude mít hierarchickou strukturu viz obr. 19, kterou tvoří tři základní úrovně: uživatelské rozhraní pro dohled nad systémem, hlavní diagnostická jednotka (nadřízený - master), výkonné řídicí jednotky (podřízení - slaves) se zabudovanými diagnostickými prvky. 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 Uživatelské rozhraní pro dohled nad systémem Jedná se o nejvyšší vrstvu v diagnostickém podsystému, která představuje rozhraní člověk - stroj. Cílem je zpřístupnit operátorovi (uživateli) ovládání a dohled nad systémem. Na této úrovni dochází k převodu a vizualizaci strojově zpracovávaných dat do člověku srozumitelné podoby. Tato část bude sloužit ke kontrole chování systému a případnému zásahu operátora do jinak autonomního chování diagnostického podsystému. Základní vlastnosti uživatelského rozhraní jsou: textová nebo grafická nadstavba pro vizualizaci a ovládání podřízených systémů, obsluha operátorem s adekvátní reakční dobou (sekundy, minuty).

46 5 Diagnostický podsystém pro operační systémy reálného času 34 dohledové centrum hlavní diagnostická jednotka řídicí řídicí jednotka 1 jednotka 2 řídicí jednotka n Obr. 19: Hierarchická struktura diagnostického podsystému V závislosti na konkrétní situaci lze uvedené funkce např. realizovat přenosným počítačem (notebook, PDA atd.). Dohledová jednotka může být následně trvale připojena ke sledovanému systému, nebo podle potřeby zapojena/odpojena (např. bezdrátové připojení) Hlavní diagnostická jednotka Hlavní diagnostická jednotka bude provádět průběžnou diagnostiku celého systému. Diagnostické informace o chování podřízených jednotek budou vyhodnocovány v reálném čase. V případě, že dojde k výskytu poruchy (chyby v programovém vybavení), jednotka provede lokalizaci poruchy a adekvátně zareaguje tak, aby systém zůstal v práceschopném stavu, popř. se přepnul do definovaného (stabilního) stavu. Zodpovědný za udržení systému v práceschopném stavu je správce diagnostických úloh, který bude spuštěn na hlavní diagnostické jednotce. Chod správce diagnostických úloh bude probíhat pokud možno autonomně a nezávisle na operátorovi. Za tímto účelem je nutné navrhnout a realizovat rozhodovací funkce správce diagnostických úloh podporující autonomní chování. Zde se nabízí použití metod z oblasti umělé inteligence [56] (agentní systémy, neuronové sítě, fuzzy logika). Bohužel metody umělé inteligence svou dobou odezvy nejsou příliš vhodné pro rozhodování v reálném čase, kde je nedílnou podmínkou pro správnost výpočtu i dodržení času do kterého má být výsledek vypočten. Vzhledem k charakteru řídicích úloh ve vestavných systémech se bude spíše jednat o stereotypní rozhodování podle předem stanovených kritérií. Zde lze využít např. metody případového uvažování [87] (CBR - Case-Based Reasoning), metody rozhodovacích stromů [91] atd. Součástí hlavní diagnostické jednotky bude i datové úložiště pro ukládání diagnostických informací. Tato data bude následně možné využít pro off-line diagnostiku a sledování vývoje chování systému v čase. Podle množství ukládaných diagnostických informací a typu aplikace se bude volit paměťové médium (EEPROM, COMPACT FLASH, SDCARD atd.)

47 5 Diagnostický podsystém pro operační systémy reálného času Řídicí jednotky se zabudovanými diagnostickými prvky Jednotlivé řídicí jednotky budou principiálně obsahovat výkonnou část podílející se na řízení úlohy a diagnostickou část. Výkonná část musí reflektovat existenci diagnostických prvků a být připravena s ní spolupracovat. Stávající programové vybavení (zdrojový kód) se bude muset patřičně upravit. U nově vznikajících částí se bude muset zahrnout diagnostické rozhraní do návrhu. Diagnostická část bude rozdělena na prostředky pro získávání informací o chodu úlohy (procesu) a na komunikační rozhraní pro předávání diagnostických informací. Získávané diagnostické informace mohou být buď interního nebo externího charakteru. Interní informace představují hodnoty proměnných, stavů úlohy, příznaků atd. během vykonávání kódu programu. Externí informace zahrnují hodnoty, které lze získat vnějším pozorováním chování diagnostikované úlohy (úloha je spuštěna/vypnuta, aktuální využití systémových zdrojů, systémové logy atd.). S ohledem na možnosti konkrétního systému může dojít k různým kombinacím těchto dvou zdrojů informací. Komunikační rozhraní pro předávání diagnostických informací bude sloužit ke vzájemné komunikaci mezi jednotlivými prvky diagnostického podsystému. Komunikační protokol pro výměnu informací musí splňovat požadavky kladené na diagnostické protokoly (otevřenost, spolehlivost, rychlost atd.), dále viz [20]. 5.2 Návrh diagnostického podsystému Dosavadní popis diagnostického podsystému byl na velice abstraktní úrovni. V dalším textu bude uvažována varianta diagnostického podsystému provozovaného v rámci operačního systému reálného času nad společným technickým vybavením. Konkrétně se jedná o operační systém Linux doplněný o real-time podporu. Technické vybavení je reprezentované architekturou kompatibilní s Intel x Diagnostické rozhraní operačního systému Jednotlivé řídicí procesy (vlákna) budou obsahovat rozhraní pro sdílení informací (aktuálního stavu) s diagnostickým podsystémem. Operační systém reálného času a diagnostický podsystém budou sdílet společný procesor, paměť atd. a proto lze označit tento typ monitorování za intrusivní monitorování. Diagnostický podsystém nesmí v žádném případě mít vliv na chod sledovaného systému a nesmí ho nikterak ovlivňovat (např. nestálost časování nebo pokles výkonu nejsou dovoleny). Navržená struktura diagnostického podsystému je založena na struktuře vyobrazené na obr. 20. 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. 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

48 5 Diagnostický podsystém pro operační systémy reálného času 36 uživatelský prostor diagnostický a monitorovací manažer proces 1 proces 2 proces n diagnostická sběrnice diagnostický modul jádra jádro RTOS prostor jádra Obr. 20: Diagnostický podsystém operačního systému reálného času 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í viz obr. 21. Obě části ve finální realizaci (spuštěná úloha v rámci operačního systému reálného času) sdílí společný adresní prostor (kód a data). 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. Popis stavových automatů může být proveden zápisem zdrojového kódu programu nebo pomocí jazyka UML. V prvním případě programátor transformuje algoritmus popsaný stavový automatem do podoby zdrojového kódu (metoda SOP), který lze následně přeložit a spustit. Ve druhém případě dochází k automatickému vytváření zdrojového kódu metodou MDA. V současnosti stále dominuje přístup, kdy je zdrojový kód vytvářen programátorem. Dochází však ke zvyšující se tendenci zahrnout použití UML a MDA do procesu tvorby programového vybavení pro vestavné systémy. Stávající MDA nástroje nejsou zatím ještě v řadě případů na takové úrovni, aby umožnily návrh složitých aplikací. Nezanedbatelný je také fakt, že jsou kladeny nové znalostní požadavky na vývojáře programového vybavení, pro které se může jednat o nový a neznámý přístup vývoje. 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 (instrukce a data procesu) a jsou tvořeny fixní sadou základních registrů

49 5 Diagnostický podsystém pro operační systémy reálného času 37 Proces 1 řídicí stavový diagram Proces 2 řídicí stavový diagram diagnostický stavový diagram diagnostický stavový diagram diagnostická sběrnice Obr. 21: Řídicí proces s diagnostickým rozhraním a uživatelsky definovanými registry. Základní diagnostické registry jsou implementovány ve formě SW-JTAGu [62]. Myšlenka koncepce SW-JTAGu využívá principu IEEE pro potřeby on-line 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. Základní diagnostické registry tvoří: adresový registr, datový registr, řídicí registr, stavový registr. Uživatelsky definované registry reprezentují aplikačně specifické proměnné, datové struktury atd. připojené k diagnostickým registrům během sestavovaní programu. Uživatelsky definované registry tvoří: důležité lokální a globální proměnné, datové struktury (pole, struktury atd.). Na obr. 22 je zobrazeno umístění jednotlivých částí řídicího procesu v paměti. Instrukce procesoru, které reprezentují řídicí a diagnostický algoritmus, jsou umístěny a vykonávány ze segmentu paměti určeného pouze pro čtení (ROM, RAM, EPROM, FLASH). Data procesu jsou umístěna v segmentu paměti určeného pro čtení a zápis. Řídicí a diagnostická část procesu sdílí společný paměťový prostor. Díky tomu není diagnostická část procesu nikterak omezena v přístupu k datům a instrukcím řídicího procesu. Diagnostický modul jádra operačního systému Struktura současných operačních systémů je dělena do dvou základních částí, které tvoří prostor jádra a uživatelský prostor. Procesy spuštěné v prostoru jádra řídí a poskytují přístup k systémovým zdrojům (RAM, CPU, periferie atd.) platformově

50 5 Diagnostický podsystém pro operační systémy reálného času 38 CODE - kódový segment (instrukce programu) DATA - datový segment (data programu) 0xF000 Proces 1 Proces 1 0x1000 Kód řídicího procesu Data řídicího procesu... if(pressure > 10) { Proměnné - var. pressure Struktury - engine_01 printf("alarm - pressure to high!"); } - var. temp_ var. temp_02 - engine_ engine_03 0xE Proměnné a datové struktury mapované (sdílené) mezi řídicím procesem a diagnostickým rozhraním. 0x Kód diagnostického rozhraní Uživatelem definované diagn. registry switch (command) { case 0: value = read_mem(addr_reg); break; Základní diagnostické registry - adresový registr - datový registr... 0xE Data diagnostického rozhraní 0x0600 Obr. 22: Adresový prostor řídicího procesu nezávislým způsobem. Ovládání a využívání systémových zdrojů je řešeno na úrovni zdrojového kódu pomocí API (Application Programming Interface) rozhraní. Diagnostický modul jádra OS slouží ke sledování a ovládání spuštěných úloh v rámci celého OS. Díky tomu, že se jedná o modul jádra OS, jsou využívány z toho plynoucí výhody: přímý přístup k HW a SW zdrojům, privilegovaný (neomezený) přístup k HW a SW zdrojům, vysoká priorita, výkon. Diagnostický modul může např. ovládat diagnostické prostředky integrované v technickém vybavení, kde se může jednat o obvody WDT, vyhodnocování parity, CRC atd. Získané informace lze následně využít v diagnostickém podsystému k detekci a lokalizaci poruch. Správce diagnostických úloh bude používat diagnostický modul jádra k ovládání spuštěných procesů v OS a provádět s nimi operace spuštění, ukončení či zjištění aktuálního stavu spuštěné úlohy Systém diagnostických zpráv Diagnostická sběrnice slouží k zasílání zpráv uvnitř systému. Pro datové přenosy mezi systémovými komponentami lze volit mezi jednoúčelovou sběrnicí nebo sdílenou systémovou sběrnicí. Vyhrazená jednoúčelová sběrnice představuje nárůst ceny výsledného zařízení (dodatečné vodiče, konektory atd.). Na druhou stranu lze dosáhnout vyššího stupně nezávislosti na sledovaném systému (neintrusivní monitorování). V některých případech však není možné jednoúčelovou diagnostickou sběrnici doplnit (např. jednočipové systémy kde CPU, RAM aj. jsou integrované přímo na čipu), protože nelze

51 5 Diagnostický podsystém pro operační systémy reálného času 39 provést dodatečné úpravy technického vybavení. Teoreticky lze využít k diagnostice programového vybavení JTAG rozhraní, pokud je integrované u daného typu obvodu. Tato varianta však předpokládá přístup k JTAG rozhraní z aplikace a znalost JTAG instrukcí nezbytných k samotné implementaci diagnostiky programového vybavení. Často se však jedná informace, které výrobci procesorových obvodů volně nezveřejňují. Ve většině případů diagnostika programového vybavení využívá přenosy mezi procesorem a pamětí a spadá do kategorie se sdílenou systémovou sběrnicí. Vazba mezi procesorem a pamětí je velice těsná a datové přenosy jsou optimalizované, aby bylo možné dosáhnout co nejvyššího výkonu. Jednoúčelovou diagnostickou sběrnici má smysl vytvářet u komplexních systémů využívajících více funkčních bloků schopných se na sběrnici připojit a komunikovat přes ni. Diagnostické zprávy musí být pokud možno krátké s definovanou prioritou a dobou doručení. Jednotlivé zprávy mohou být adresovány následujícím způsobem: individuální adresování (unicast) - zpráva je zaslaná jednomu cílovému zařízení, skupinové adresování (multicast) - zpráva je zaslaná zařízením sdruženým v jedné skupině, všesměrové vysílání (broadcast) - zpráva je zaslaná všem zařízením. Diagnostická sběrnice musí být schopna provést adresování nejméně 256 zařízení. Adresování lze provést přímo adresou konkrétního rozhraní v daném zařízení (např. adresa zařízení na RS485 lince, IP adresa v lokální síti). Struktura uvažované diagnostické sběrnice bude založena na sběrnicové topologii, tj. kterékoliv připojené zařízení může začít vysílat a zároveň všechny ostatní uzly začnou přijímat (např. sběrnice CAN-Bus). Zvolený přístup umožňuje propojit mezi sebou více než dvě zařízení bez nutnosti použití rozbočovače. V případě, že by bylo nutno vzájemně propojit větší diagnostické celky, nelze již vystačit se sběrnicovou topologií a je vhodné použít hvězdicovou topologii a strukturování do hierarchických úrovní (např. lokální síť realizovaná pomocí strukturované kabeláže). Obr. 23: Sběrnicová topologie Obr. 24: Hvězdicová topologii Hlavní nevýhodou sdílené sběrnice (média) je nutnost řídit přístup ke společné sběrnici pro potřeby vysílání. Při současném vysílání více zařízení může dojít k výskytu kolizí na sběrnici. Aby k výskytu kolizí nedocházelo byly navrženy metody řízení přístupu [70] ke sdílenému médiu: vylučující kolize (CA - Collision Avoidance), detekující kolize (CD - Collision Detection), bez detekce kolizí.

52 5 Diagnostický podsystém pro operační systémy reálného času 40 U systémů pracujících v reálném čase je důležitá i doba, za jakou je úloha vyřešena. Diagnostická sběrnice by měla proto zohledňovat i dobu za jakou je daná zpráva doručena. Zde se pak vyskytují problémy kvality služby (QoS - Quality of Service) popř. přidělování přenosového média na určitou dobu metodou TDMA (Time division multiple access) Správce diagnostických úloh Správce diagnostických úloh je zodpovědný za řízení a dohled nad systémem. Chování správce diagnostických úloh bude probíhat pokud možno autonomně, viz kap V prvotní fázi se nepočítá u správce diagnostických úloh s použitím prostředků umělé inteligence. Rozhodování bude řešeno pomocí pevně stanovených pravidel, která budou definována na základě znalostí chování systému. Pravidla budou zapsána ve formě rozhodovacího stromu, aby rozhodovací proces byl optimální a nedocházelo k nedodržování real-time vlastností výsledného systému. Podle typu aplikace bude navržen konkrétní rozhodovací strom, který bude pokrývat množinu možných poruch, které mohou v systému nastat. Rozhodovací stromy jsou vhodné pro úlohy, ve kterých má být provedena klasifikace nebo předpověď. Užitečné jsou v oblastech, ve kterých můžeme hodnoty proměnných rozdělit do relativně malého počtu skupin. Na druhou stranu nejsou vhodné pro případy, kdy je úkolem předpovězení kvantitativních hodnot. Rozhodovací strom se skládá z uzlů. Uzel na nejvyšší úrovni je označován pojmem kořenový. Vnitřní uzly představují testy jednotlivých atributů (kořenový uzel je rovněž testem). Větví nazýváme možný výsledek testu. Externí uzly jsou označovány jako listy. kořenový uzel větve listový uzel listový uzel množina možných odpovědí množina možných odpovědí Obr. 25: Rozhodovací strom Diagnostický podsystém bude sbírat informace o systému a tato data předávat správci diagnostických úloh jako vstup pro rozhodovací strom. Na základě těchto dat bude proveden test a získán výsledek, který bude reprezentovat aktuální stav systému a zobrazovat případný výskyt poruchy. Aby systém byl udržen v práceschopném stavu, je třeba nalezenou poruchu lokalizovat a odstranit. Pro komunikaci s uživatelem bude správce diagnostických úloh poskytovat textové a grafické rozhraní. Textové rozhraní umožňuje přímo čtení diagnostických informací na cílovém systému, např. přes sériový port nebo zabezpečené SSH spojení po lokální síti. Informace o aktuálním stavu operačního systému jsou na OS Linux poskytované uživateli pomocí virtuálního souborového systému připojeného

53 5 Diagnostický podsystém pro operační systémy reálného času 41 do adresáře /proc [48]. Čtení probíhá pomocí unixového příkazu cat(1) např. cat /proc/cpuinfo. Zápis a nastavování hodnot pak pomocí příkazu echo(1) např. echo "3" > /proc/acpi/sleep. Obdobné textové rozhraní bude poskytovat i správce diagnostických úloh viz obr. 26. $ cat /proc/diag/task1/info task id: 1 watchdog id: 1 diagnostics enabled: yes address register: 0x1A25 data register: 0x0012 control register: 0x3000 status register: 0x0120 Obr. 26: Návrh textového rozhraní správce diagnostických úloh Výhodou textového rozhraní je jeho relativně snadná realizace, vizualizace, ovladatelnost a malá náročnost na výpočetní zdroje. Díky těmto vlastnostem je dobře implementovatelný do prostředí vestavných systémů. Numerický výstup bohužel zobrazuje pouze aktuální stav sledovaných hodnot a schází informace o průběhu v čase, ve formě grafu nebo tabulky. Při dlouhodobém sledování chování systému je však tato informace velice důležitá, protože na grafu lze často pouhým pozorováním odhalit výskyt dočasných poruch viz obr. 27. Obr. 27: Sledování toků na počítačové síti pomocí protokolu NetFlow [89] Grafické rozhraní musí poskytovat stejné informace jako textové rozhraní. Navíc bude doplněno o grafické znázornění průběhu jednotlivých sledovaných hodnot. Je nutné si uvědomit, že poskytovaná funkcionalita klade patřičné nároky na výpočetní zdroje. Grafický výstup může být realizován následujícím způsobem: Lokálně spuštěná aplikace s grafickým výstupem. Vyžaduje počítač s grafickou kartou a výstupem na monitor. Je nutná fyzická přítomnost obsluhy u řídicí jednotky. Vzdáleně spuštěná aplikace s grafickým výstupem. Vyžaduje operační systém s podporou pro přesměrování grafického výstupu přes počítačovou síť (např.

54 5 Diagnostický podsystém pro operační systémy reálného času 42 MS Windows 2000, Linux atd.). Není nutná fyzická přítomnost obsluhy u řídicí jednotky. Grafický výstup přes webové rozhraní. Platformová nezávislost na straně klienta (webového prohlížeče) díky protokolu HTTP. Vyžaduje připojení do počítačové sítě. Není nutná fyzická přítomnost obsluhy u řídicí jednotky. Získaná diagnostická data mohou být použita pro základní statistiky např. s maximální periodou jednoho měsíce. Nahrazování (přepis) dat pak bude fungovat na principu kruhové vyrovnávací paměti, tj. nejstarší záznamy budou nahrazeny nejnovějšími záznamy. Množství dat nutných ukládat pro další zpracování závisí na počtu zdrojů informací, velikosti jednotlivých položek a periodě čtení. Množství měřených dat může v krátké době přesáhnout paměťovou kapacitu vyhrazenou pro ukládání popř. překročit max. rychlost ukládání dat na zvolené paměťové médium. V těchto případech je pak nezbytné aplikovat mechanizmy vzorkování vstupních dat a předzpracování ve formě agregace. Správce diagnostických úloh tvoří v neposlední řadě rozhraní, pomocí kterého bude nejen možné data číst, ale i vkládat (injektovat) do systému. Pro prověřování správné činnosti diagnostického podsystému tak bude možno vkládat poruchy (testovací vektory) do výpočetního systému a měřit následky, které vyvolají. testovací vektory testovaný systém úloha systém reálného času výsledek měření Obr. 28: Vkládání testovacích vektorů do operačního systému reálného času 5.3 Dopady na real-time vlastnosti systému Je zřejmé, že doplněním diagnostického podsystému do operačního systému reálného času dojde k ovlivnění jeho původních vlastností. Diagnostické prostředky nesmí potlačit real-time chování systému. Z tohoto důvodu musí výsledná implementace diagnostického podsystému patřičně respektovat real-time mechanizmy poskytované operačním systémem. Diagnostické prostředky budou integrované do operačního systému a další aplikace je pak budou moci využívat standardním způsobem jako ostatní systémové zdroje. Použití real-time mechanizmů operačního systému však automaticky negarantuje, že výsledný systém bude nadále splňovat real-time podmínky. Z tohoto důvodu je třeba uskutečnit kontrolní měření a na základě získaných výsledků provést případnou optimalizaci. Testování systémů reálného času není jednoduché a vyžaduje často úplný test. V případě programového vybavení je provedení takového testu velice problematická záležitost. Z tohoto důvodu je nutné vytvořit statistické odhady spolehlivosti na základě provedených testů reálného systému nebo jeho modelu [46]. Vytvoření a ověření modelu je schůdné pouze pro dílčí části systému, ne však pro celý systém.

55 5 Diagnostický podsystém pro operační systémy reálného času 43 Během testu je testovaný systém (SUT System Under Test) vystaven požadavkům vytvářených testerem a jsou sledovány následné reakce systému, viz obr. 29. Testování může být prováděno s ohledem na zjištění jestli se systém chová tak jak má (conformance testing). Určuje se, zda chování systému odpovídá zadání či modelu, podle kterého byl vytvořen. Druhým možným způsobem je testování na kritické situace (testing for criticality requirements), kdy je systém vystaven nejhorším možným požadavkům na vstupu (worst case). Nejedná se samozřejmě o úplný výčet možných testovacích metod. Další metody lze nalézt v literatuře [61]. testovaný systém testovaný systém vstupy výstupy výstupy tester tester výsledek testu Obr. 29: Princip testování RTOS výsledek testu Obr. 30: Princip monitorování RTOS Mimo klasického testování lze provádět i monitorování chování systému reálného času. Principiální uspořádání je uvedeno na obr. 30. V tomto případě se provádí pasivní sledování chování systému a vyhodnocuje se, jestli nedošlo k porušení real-time podmínek. vstupy systém reálného času výstupy měření doby odezvy výsledek testu Obr. 31: Měření doby odezvy systému reálného času Na obr. 31 je zobrazeno měření doby odezvy systému reálného času. Dobou odezvy (response time) se rozumí doba od odeslání dotazu po první reakci systému. Nezahrnuje v sobě dobu celé odpovědi, protože ta může být závislá, např. na rychlosti výstupního zařízení. K určení doby odezvy je zapotřebí získat časovou značku odeslání dotazu t 0 a časovou značku první reakce systému t 1. Doba odezvy je pak rovna rozdílu t 1 - t 0. Časové značky lze získat např. z obvodu reálného času (RTC -

56 5 Diagnostický podsystém pro operační systémy reálného času 44 real time clock) nebo měřením průběhů na vývodech procesoru číslicovým osciloskopem. Detailnější popis a výstupy měření u operačního systému Linux jsou uvedeny v kap Přenositelnost navrženého řešení Přenositelnost každého programového díla je ovlivněna celou řadou faktorů. Stejně je tomu i u diagnostického podsystému, který byl popsán v předchozím textu. Mezi základní faktory ovlivňující přenositelnost aplikace patří: adresní prostor - uživatelský prostor (uživatelské aplikace) nebo prostor jádra (ovladače HW, správa paměti, plánovač úloh,... ), rozhraní - textový nebo grafický vstup/výstup, HW závislost - aplikace vyžaduje HW funkce, které nemusí být dostupné na jiné platformě např. instrukce procesoru, SW závislosti - aplikace vyžaduje knihovny, programy, aj. které nemusí být dostupné pro jiný operační systém, složitost - aplikace je příliš složitá na údržbu, popř. vyžaduje příliš mnoho výpočetních zdrojů, aby mohla být spuštěna na jiné platformě, bezpečnost, spolehlivost - aplikace může být shledána tvůrci operačního systému jako málo spolehlivá, popř. vytvářející potenciální bezpečnostní rizika pro zbytek operačního systému, lidský faktor - neochota vývojářů provést portaci aplikace na další platformu a provádět její průběžnou údržbu, dokumentace - nedostupná dokumentace k HW a SW součástem systému nezbytných k portaci aplikace, standardy - nedodržování obecně platných standardů a norem v navrženém HW a SW řešení, licence - licenční omezení, zabraňující portaci na jiné platformy popř. užívání v jiných zemích. Dnešní aplikace již nefungují jako samostatné entity v systému, ale místo toho spolupracují s dalšími částmi systému. Často jsou jednotlivé části aplikace napsány v různých programovacích jazycích a využívají nejrůznější knihovny a jejich verze. Sestavení programu ze zdrojového kódu popř. instalace z předpřipravených instalačních balíčků nemusí být vždy tak triviální, jak je popisovaná v uživatelské dokumentaci. Může se stát, že přes veškerou snahu se uživatel nedopracuje k tíženému výsledku. Cílem je implementace diagnostického podsystému do operačního systému unixového typu. Diagnostický podsystém bude napsán v jazyce C. Základní charakteristiky jazyka C shrnuje následující výčet: univerzální programovací jazyk nízké úrovně, není specializovaný na jednu oblast používání, jazyk C byl navržen a implementován pro operační systém UNIX, jazyk C pracuje přímo pouze se standardními datovými typy, jazyk C neumožňuje přímo práci s řetězci, poli, HW komponentami a problém řeší přes volání funkcí (knihoven), z toho vyplývá jednoduchost jazyka a nezávislost na HW,

57 5 Diagnostický podsystém pro operační systémy reálného času 45 snadné vytvoření překladače jazyka C vedlo k jeho velkému rozšíření a oblibě, velká efektivita kódu a dobrá přenositelnost, náchylnost na vznik skrytých chyb v programu, jazyk C je standardizován - ANSI C, ISO/IEC 9899:1999, specifická (špatně přenositelná) rozšíření jazyka C pro vestavné systémy. Jazyk C využívá řady uživatelských a systémových knihoven. Volba vhodného překladače a navazující množiny nezbytných knihoven zásadně ovlivňuje přenositelnost vytvořeného zdrojového kódu. Pokud bude systém provozován na více operačních systémech, různých verzích těchto systémů a odlišných platformách, tak se nebude možné ubránit výskytu specifického kódu vytvořeného pro konkrétní variantu systému. Automatické přepínání a výběr zdrojového kódu se musí řešit pomocí prostředků podmíněného překladu. Musí být definován cyklus, po který bude udržována podpora pro starší verze operačního systému. Čím bude množina podporovaných variant systémů větší, tím více se bude původní zdrojový kód rozrůstat o specifické části pro jednotlivé varianty. Jedním z klíčových standardů, který bude nutné dodržovat při sestavování diagnostického podsystému je standard POSIX. Tvůrcem standardu POSIX (Portable Operating System Interface for Computer Environments) je organizace IEEE. Cílem standardu je definovat model obecného operačního systému a pro něj implementovaných programovacích jazyků pro zaručení přenositelnosti vytvořených aplikací. V případě, že výsledná aplikace má být přenositelná na jiný typ technického vybavení a operační systém, je standard POSIX způsobem, jak toho dosáhnout. Dodržování standardu POSIX se stalo jedním ze základních cílů tvůrců vyspělých operačních systémů. Standard POSIX se snaží o standardizaci rozhraní operačních systémů tak, aby aplikace byly přímo sestavitelné na různých platformách z jednoho zdrojového kódu. Existuje asi třicet standardů POSIX daných čtyřmístným označením (od až po ). Původní návrh standardu POSIX vycházel z operačních systémů typu UNIX, nicméně i operační systémy firmy Microsoft s ním proklamují kompatibilitu. POSIX definuje standardní cestu aplikací k rozhraní operačního systému. Původní standard definoval rozhraní funkcí jako jsou operace se soubory, správa procesů, signály a zařízení. Následující vydání definují i real-time rozšíření a práci s vlákny [63]. Z více než třiceti standardů POSIX jich sedm přísluší systémům reálného času a vestavným systémům. První tři standardy (1003.1a, b, c) jsou nejvíce podporovány. POSIX a definuje základní funkce operačního systému. Rozšíření reálného času jsou definovány standardy b, d, j a POSIX standard definuje víceuživatelský real-time systémový profil, který dovoluje real-time procesům uzamknout se v paměti a tím se bránit odstránkování na pevný disk. Zvláštní plánovač pak zajišťuje, že procesy jsou vždy vykonávány v předvídatelném pořadí.

58 6 Diagnostický časovač pro operační systémy reálného času 46 6 Diagnostický časovač pro operační systémy reálného času Řada dnešních výpočetních systémů pracuje v autonomním režimu. V případě selhání jejich programového vybavení může nastat situace, kdy není možný fyzický zásah operátora (např. vesmírná sonda), následkem čehož může dojít k trvalé poruše celého systému. Na druhou stranu existují systémy, kde reakční doba operátora, nutná ke spuštění nulování systému, je příliš dlouhá. Ve všech těchto případech nacházejí své uplatnění diagnostické časovače. 6.1 Diagnostický časovač Základní princip diagnostického časovače WDT byl uveden v kap Synchronní verze WDT může být jak v externím, tak v interním provedení a je běžně součástí jednočipových mikropočítačů. Pokud nepoužívá hodiny procesoru, může mít vlastní oscilátor. Toto druhé řešení umožňuje detekovat výpadek centrální synchronizace. Částečně lze tuto schopnost doplnit kontrolním obvodem funkce centrálního oscilátoru. watchdog reset procesor hodiny restart Obr. 32: Princip diagnostického časovače Výstupem WDT bývá zpravidla generován nulovací signál celého systému, jímž může být celý program systému opětovně spuštěn. Pokud by však nastala porucha v paměti programu, tak se nulování systému bude periodicky opakovat, což pochopitelně není žádoucí činnost. Proto indikace výpadku prostřednictvím WDT bývá zapojena do obvodu regenerace systému, který provádí identifikaci hlášení poruchy a podle ní se potom rozhoduje o další činnosti systému. Jednou z možností je použití mechanizmu nulovacích vektorů, z nichž každý provádí částečně odlišnou činnost v závislosti na zdroji hlášení poruchy. Např. při hlášení poruchy od WDT periférií není třeba nulovat celý systém, stačí nulovat periferní obvody a spustit ovladač periférií z definovaného bodu. Pokud je WDT součástí procesoru, může být adresován jako běžný registr. Pokud je však činnost WDT aktivována, musí být technicky zablokován jeho nežádoucí přepis (často se stává, že při poruše může část programu bloudit a způsobit nežádoucí přepisy i v oblasti řídicích registrů). Z tohoto důvodu je programová obsluha WDT řešena pomocí řídicí sekvence více instrukcí. Pokud je WDT umístěn mimo procesor, může být ovládán bitem řídicí sběrnice nebo adresován adresovým dekodérem jako běžná periférie. Pro správnou činnost WDT je nezbytné v programu rozmístit instrukce obsluhy WDT tak, aby byl dodržen správný interval jeho obsluhy. Musí být vloženy ve všech větvích řídicího programu, hlavního programu, podprogramů a obsluh přerušení. Je nutno zvažovat dobu provádění cyklů programu. Při ladění programu je vhodné

59 6 Diagnostický časovač pro operační systémy reálného času 47 činnost WDT blokovat. K tomu může sloužit bit z registru řídicího slova číslicového systému nebo jiný vhodný mechanizmus. Je vhodné si také uvědomit, že při použití WDT se uplatňuje latence mezi okamžikem vzniku poruchy a její indikací. Tato doba může být z hlediska řízeného procesu značně dlouhá (cyklus WDT bývá řádově v jednotkách ms) a během této doby může být vyvolána řada chybných operací. 6.2 Výhody a nevýhody diagnostického časovače Výše uvedený princip WDT umožňuje provést nulování systému v případě jeho selhání. K selhání programového vybavení může dojít v důsledku působení okolního prostředí na systém, které vyvolá výskyt dočasné poruchy (elektromagnetické rušení, nestabilní zdroj napájení, mechanické namáhání atd.). Svou roli hrají i skryté chyby v programu. Patřičným rozmístěním kontrolních bodů ve zdrojovém kódu lze zabezpečit, že WDT vyvolá nulování systému, který bude znovu spuštěn (zaveden). V této podobě je WDT standardně používán v řídicích systémech využívajících jednočipové mikropočítače. Operace znovuzavedení systému v případě, že došlo k vynucenému nulování ze strany WDT může vést u složitějších systému k trvalé poruše systému. Běžně používané operační systémy umožňují vykonávání více aplikací současně. Chování systému je často závislé na datech, které se v čase mění (konfigurace, data v databázi atd.). Zde již nelze hovořit o stavu, kdy je program uložen v paměti FLASH, EPROM přímo na čipu jednočipového mikropočítače a vykonává jednoduchou řídicí úlohu. Množství potenciálních zdrojů selhání programového vybavení v těchto systémech je mnohem větší a umístění kontrolních bodů pro WDT se stává netriviální záležitostí. Nejčastější zdroje chyb a poruch výpočetních systémů jsou uvedeny v kap Zásadní nevýhoda kontroly funkčnosti systému pomocí WDT spočívá v tom, že pokud dojde k částečnému zablokování systému (např. vykonává se pouze uzavřená smyčka programu, kde se periodicky obnovuje WDT), nemusí WDT detekovat, že došlo k poruše systému. 6.3 Programově realizovaný diagnostický časovač Řešením výše uvedených obtíží je integrace WDT do operačního systému [21] a jeho obsluha pomocí uživatelských aplikací. Jádro operačního systému se stará o nastavení WDT a vytvoření rozhraní (např. na OS Linux - /dev/watchdog) pro komunikaci s uživatelskými aplikacemi. WDT je ovládán nezávisle na jeho fyzické realizaci přes jednotné API. Jednotlivé aplikace pak provádí obsluhu WDT s periodou v jednotkách sekund. Dochází ke generalizaci pohledu na systém a kontrola práceschopnosti systému je prováděna až na úrovni aplikací. Fyzická realizace WDT pak může mít jednu z následujících forem: obvod WDT integrovaný v procesoru nebo na základní desce, rozšiřující karta do počítače, externí periferie připojená na sériové nebo paralelní rozhraní počítače, WDT proces uvnitř jádra operačního systému (čistě SW řešení). V případě selhání aplikace a nebo systému provede WDT nulování technického vybavení a dojde k pokusu o znovuzavedení operačního systému.

60 6 Diagnostický časovač pro operační systémy reálného času Inteligentní diagnostický časovač Stávající řešení WDT pro diagnostické použití ve víceúlohových systémech není zcela optimální. Z tohoto důvodu navrhuji 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é struktury WDT umožní sledovat chování jednotlivých součástí řídicího systému. Hierarchická struktura WDT bude nedílnou součástí diagnostického podsystému, který bude sledovat chování celého systému. úloha č. 1 WDT úloha č. 2 WDT SW watchdog reset HW watchdog úloha č. n WDT RESET systému Obr. 33: 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, 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. Základní koncept inteligentního diagnostického časovače byl ověřen v rámci experimentu popsaného v kap V případě detekce poruchy by se systém snažil o její lokalizaci a odstranění, místo okamžitého nulování celého systému a pokusu o jeho znovuzavedení. Popsané řešení je založeno na programové realizaci (instrukce programu které se vykonávají). Závažnější porucha programového vybavení by mohla způsobit celkové selhání systému. Z tohoto důvodu bude SW-WDT doplněn o obvod WDT realizovaný v technickém vybavení. V případě kritické poruchy by byl systém nulován obvodem HW- WDT a poté znovu zaveden. Selhání technického vybavení může vyústit ve stálé nulování systému. V takovém případě by měl systém s WDT disponovat mechanizmy, kterými bude schopen omezit maximální počet nulování systému. Diagnostický časovač umožňuje zotavení systému po výskytu dočasné poruchy. Většina současných jednočipových mikropočítačů disponuje integrovaným WDT. Bohužel se však často jedná o velice jednoduché obvody, které pokud nejsou obslouženy během stanovené doby provedou pouze vynucené nulování systému. Vyspělejší WDT obvody umožňují vygenerovat přerušení od WDT předtím, než dojde k nevratnému vynulování systému. Po výskytu tohoto přerušení je systému poskytnuto

61 6 Diagnostický časovač pro operační systémy reálného času 49 určité množství času pro bezpečné ukončení a vytvoření ladicích informací s popisem proč došlo k poruše. Špatně navržená obsluha WDT může eliminovat dočasné poruchy, na druhou stranu však může způsobit nepředvídané chování systému (trvalou poruchu). Přestože princip WDT je velice triviální, obvody WDT se staly nedílnou součástí výpočetních systémů pracujících v autonomním režimu.

62 7 Model diagnostického podsystému 50 7 Model diagnostického podsystému V kapitole 5 byla uvedena struktura diagnostického podsystému. Vytvoření modelu celého diagnostického podsystému a následný převod do podoby funkčního programového vybavení by přesáhlo rámec disertační práce a nebylo ani jejím cílem. Z tohoto důvodu byla vybrána dílčí část v podobě diagnostického časovače popsaná v kapitole 6. Úloha 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. Model úlohy producent - konzument byl převeden do podoby zdrojového kódu několika metodami popsanými v kapitolách 3.3 a 4.3. Především se jednalo o metodu MDA použitou pro návrh programového vybavení vestavných systémů. Bylo provedeno srovnání metody MDA s metodou, kdy je zdrojový kód vytvářen programátorem. 7.1 Popis systému metodou MDA Metoda (koncept) MDA se sestává z jazyka UML 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. 34: Transformace modelů PIM na PSM a zdrojový kód Na obr. 34 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 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.),

63 7 Model diagnostického podsystému 51 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.), model aplikace - popisuje entity tvořící aplikaci (uživatelské rozhraní, obsluha vstupů/výstupů, řídicí algoritmy atd.). Platformově nezávislé modely (PIM) 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 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. Použitelnost metody MDA v praxi není tak jednoznačná a jednoduchá, jak by snad mohlo vypadat z předchozího textu. Následující text disertační práce popisuje provedené experimenty s MDA během autorovy zahraniční stáže na vysoké škole ENSIETA ve Francii. 7.2 Platformově nezávislý model systému Platformově nezávislý model byl vytvořen pro úlohu producent - konzument. UML diagram tříd modelu PIM je zobrazen na obr. 35. Úloha producent - konzument představuje klasický příklad řešení problému synchronizace mezi dvěma procesy. Producent je úloha produkující data a konzument je druhá úloha, která data přijímá a dále zpracovává. Producent a konzument využívají ke vzájemné komunikaci vyrovnávací paměť omezené velikosti. Pro experiment s metodou MDA poskytuje zvolená úloha dostatek možností na ověření základních principů (mechanizmů), které se vyskytují ve vestavných systémech. Jedná se např. o souběžné vykonávání více úloh, sdílení společné vyrovnávací paměti, synchronizaci procesů atd. good :int << process >> Producer prodbuf Buffer contents :int empty :boolean = true consbuf good :int << process >> Consumer << run >> + produce ():void + get ():int + put (val:int ):void << run >> + consume ():void Obr. 35: Platformově nezávislý model úlohy producent - konzument Grafické znázornění modelu v jazyce UML je vhodné pro člověka, nelze ho však dále strojově zpracovávat. K tomuto účelu slouží standard XMI, který pomocí znač-

64 7 Model diagnostického podsystému 52 kovacího jazyka XML zapisuje UML model. Samotný UML model je popsán metamodelem vyjádřeným pomocí standardu MOF. V příloze B.1 je uvedena ukázka části XMI souboru PIM modelu úlohy producent - konzument. Model PIM byl vytvořen modelovacím nástrojem Poseidon CE [31] s UML metamodelem verze 1.4. Operace s modely a jednotlivé transformace byly prováděny v meta jazyce MTL (Model Transformation Language) [85, 86]. Jazyk MTL je objektově orientovaný a byl inspirován jazyky Eiffel [88] a OCL (Object Constraint Language) [66]. Primárně je jazyk MTL zaměřen na transformaci modelů. Transformace (programy) zapsané v jazyce MTL se chovají stejně jako programy napsané v jazyce Java nebo C#. Jazyk MTL je nezávislý na použitém modelovacím nástroji a úložišti modelů. Na obr. 36 je zobrazena třívrstvá architektura použitého MDA přístupu, kterou tvoří: modelovací nástroj (Poseidon CE), transformační stroj (BasicMTL plugin do vývojového prostředí Eclipse [23]), úložiště modelů (MDR - MetaData Repository). modelovací nástroj Poseidon CE transformační stroj Eclipse - BasicMTL úložiště modelů MetaData Repository Obr. 36: Třívrstvá architektura použitého řešení Princip transformace modelu je zachycen na obr. 37. Během experimentů s MDA byl výlučně použit metamodel jazyka UML verze 1.4, protože jiný metamodel nebyl pro jazyk MTL k dispozici. transformační metamodel zdrojový metamodel transformační model cílový metamodel zdrojový model transformace modelu cílový model Obr. 37: Princip transformace modelu

65 7 Model diagnostického podsystému 53 Transformaci modelu provádí program napsaný v jazyce MTL. Překladač BasicMTL slouží k převodu programu v jazyce MTL do jazyka Java. Přeložený program v jazyce Java je vykonáván virtuálním strojem a dochází k postupné transformaci zdrojového modelu. Výsledkem transformace je cílový model (XMI soubor), který lze dále upravovat. Architektura překladače BasicMTL je zobrazena na obr. 38. překladač AST BasicMTL -> AST Java MTL modelovací nástroj (Eclipse) MTL stroj (Java VM) transformace modelu MTL API modely pro čtení modely pro zápis a čtení modelovací nástroj (Poseidon CE) metamodel založený na MOF 1.3 Obr. 38: Architektura překladače BasicMTL Jazyk MTL a základní programové vybavení dostupné s překladačem BasicMTL umožňuje provádět následující operace: načtení modelu a metamodelu z úložiště, procházení XML stromu modelu, práci se základními datovými typy (Integer, String, OclType atd.), typovou konverzi, asociace, třídy atd., zápis modelu po ukončení transformace. Z pohledu jazyka MTL je výše uvedený výčet dostačující k provedení transformace modelu. Při experimentech s transformacemi modelů však scházela širší podpora v podobě knihovních funkcí, které by umožnily přímou práci s jednotlivými UML diagramy. Tento stav vedl k tomu, že bylo nutno věnovat nemalé úsilí studiu metamodelu jazyka UML a způsobu zápisu UML diagramů nástrojem Poseidon CE. Výsledkem je knihovna umožňující práci s následujícími UML diagramy: diagramy struktury - popisují strukturu systému diagram tříd (class diagram), diagramy chování - popisují funkci systému diagram užití (use case diagram), diagram aktivit (activity diagram),

66 7 Model diagnostického podsystému 54 stavový diagram (state diagram), sekvenční diagram (sequence diagram). Platformově nezávislý model diagramu tříd (obr. 35) popisuje pouze strukturu úlohy producent - konzument. Pro úplný popis chování úlohy je nutné doplnit PIM model o stavový diagram viz obr. 39. producent - konzument start start producent produkuj 1 konzument konzumuj Obr. 39: Stavový diagram úlohy producent - konzument 7.3 Model cílové platformy Platformově nezávislý model představuje co nejobecnější popis systému. Na rozdíl od toho model cílové platformy (PDM) vkládá do modelu konkrétní informace o technologiích dostupných na cílové platformě. Pro operační systém Linux s rozšířením reálného času byl PDM model navržen následujícím způsobem (nejedná se o úplný výčet): úloha proces (Linux, RTAI) uživatelský prostor prostor jádra vlákno (POSIX threads, RTAI) uživatelský prostor prostor jádra synchronizace zámky (mutexy) monitory semafory binární počítací plánování úloh first in first out plánování (SCHED_FIFO) round robin plánování (SCHED_RR)

67 7 Model diagnostického podsystému 55 sdílení času (SCHED_OTHER) vstupně/výstupní operace standardní vstup, výstup a chybový výstup znaková zařízení (sériový port, klávesnice) bloková zařízení (pevný disk, CDROM) pseudo zařízení (/dev/null) meziprocesová komunikace sdílená paměť globální proměnné sokety (síťové, unixové) roura fronta zpráv systém souborů binární soubory textové soubory paměťový podsystém virtuální paměť hromada, zásobník PDM model není v uvedené podobě vhodný k transformaci modelu PIM na PSM. Popis PDM modelu je příliš obecný (lidsky srozumitelný), ale nelze ho použít k zápisu transformace v MTL jazyce. Pro transformaci modelu PIM na PSM je nutné detailně popsat v PDM modelu mapování jednotlivých částí z PIM na PSM model. PIM model tvoří diagram tříd (obr. 35) a stavový diagram (obr. 39). Diagram tříd popisuje strukturu úlohy producent - konzument. Jedná se o objektový popis a jednoznačně definovaná struktura třídy (atributy, metody) umožňuje snadnou transformaci mezi modely. Nevýhodou diagramu tříd je, že objektové jazyky jako Java, C++ a další nejsou zatím běžně používané u vestavných systémů. Pro vestavné systémy a nízkoúrovňové programování je typické použití jazyka C se strukturovaným přístupem. S ohledem na objektovou strukturu diagramu tříd a modelovací nástroj Poseidon CE (primárně zaměřen na jazyk Java) byla pro experiment s MDA změněna cílová platforma z OS Linux na platformu Java. Pro novou platformu a úlohu producent - konzument byla navržena následující MTL transformace (PDM model): PIM model jednoduché datové typy (celé číslo, logická hodnota, znak,... ) referenční datové typy třída (vlastnosti a chování) proces asociace Java PDM model int, boolean, char,... objekty, pole, datový typ null class (data a metody) vlákno - třída Thread vektory tříd (objektů) Tab. 1: PIM - PDM model diagramu tříd úlohy producent - konzument

68 7 Model diagnostického podsystému 56 PIM model počáteční stav stav koncový stav změna stavu (rozvětvení/spojení) synchronizace Java PDM model metoda start - spuštění vlákna metoda run - jádro vlákna metoda join - ukončení vlákna metody suspend, resume, sleep, yield metody wait, notify Tab. 2: PIM - PDM model stavového diagramu úlohy producent - konzument 7.4 Platformově specifický model systému Platformově nezávislý model úlohy producent - konzument byl transformován pomocí jazyka MTL na PSM model. Transformační pravidla a PDM model byly zapsány v jazyce MTL. Model PIM obsahoval mapovací značky (stereotypy), které definovaly volbu transformačních pravidel. Zdrojový kód transformace je uveden v příloze B.2. Na obr. 40 je zobrazen výsledný PSM model získaný transformací PIM modelu. ProdConsModel (from PSM) + main ():void << process, Thread >> Producer (from PSM) good :int << run >> + run ():void prodbuf Buffer (from PSM) contents :int empty :boolean = true + get ():int + put (val:int ):void consbuf << process, Thread >> Consumer (from PSM) << run >> + run ():void << read only >> Thread (from java::lang ) Obr. 40: Platformově specifický model po provedení transformace 7.5 Generování zdrojového kódu 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.

69 7 Model diagnostického podsystému 57 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 (forward engineering) viz kap 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 (roundtrip engineering), 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. Výsledný PSM model je uveden na obr. 41 a zdrojový kód je součástí přílohy B.3. main Main ConsumerProducerGood + main (args :String[] ):void << use >> << use >> << use >> n:int Producer << create >> + Producer (m:int,buf :Buffer ):Producer + run ():void prodbuf Buffer contents :int empty :boolean = true + put (i:int ):void + get ():int consbuf n:int Consumer << create >> + Consumer (m:int,buf :Buffer ):Consumer + run ():void << read only >> Thread (from java::lang ) + start ():void + join ():void Obr. 41: PSM model použitý při metodě obousměrného vývoje

70 8 Vývojová platforma pro diagnostický podsystém 58 8 Vývojová platforma pro diagnostický podsystém Následující text popisuje návrh koncepce elektronického a programového vybavení pro bezpilotní prostředek (UAV - Unmanned Aerial Vehicle). Je uveden základní popis systému, který slouží jako vývojová platforma pro diagnostický podsystém navrhovaný v rámci disertační práce. Jedná se o systém se zvýšenou spolehlivostí, neboť selhání řídicího systému by vedlo ve valné většině případů k destrukci celého bezpilotního prostředku. Od prvopočátku bylo jasné, že celý UAV bude nutné navrhovat s ohledem na bezpečnost, zvýšenou spolehlivost a diagnostiku. Zpětné doplňování těchto vlastností do funkčního zařízení přináší vždy řadu komplikací a mnohdy se nelze dobrat uspokojivých výsledků. 8.1 Volba koncepce bezpilotního prostředku Rozvoj technologií v oblasti aerodynamiky, mikroelektroniky, optiky a navigace na konci 20. století umožnil realizaci nových typů bezpilotních prostředků [6, 7, 8]. Jedná se o obor, kde došlo v posledních dvaceti letech k bouřlivému rozvoji, jenž není ještě zdaleka u svého konce. Bezpilotní prostředek obecně představuje pohybující se objekt bez lidské posádky. Své uplatnění většinou nalézá v oblastech, kde je nevhodné a riskantní vystavovat pilotované prostředky a jejich posádky nebezpečí pro velmi vysokou pravděpodobnost ztrát na lidských životech. Malé rozměry umožňují nepozorovaně proniknout do střežených a rizikových oblastí a plnit tam stanovené úkoly. Pro nižší výrobní a provozní náklady a absenci operátora nachází stále větší uplatnění jak v armádním, tak i v civilním sektoru. Výchozím bodem při návrhu architektury libovolného systému je analýza požadavků, které je nutné splnit, aby bylo možné nalézt optimální řešení zkoumaného problému. Zde lze uplatnit jednu ze dvou základních metod přístupu. První metoda předpokládá expertní znalost navrhovaného systému, umožňující vytvoření finální koncepce již v samotném prvopočátku návrhu. Druhá metoda je založena na postupné realizaci klíčových prvků a vytvoření znalostní báze, umožňující nalezení cílového řešení. V obou případech jsou kladeny vysoké nároky na teoretické a praktické znalosti zkoumané problematiky nutné k navržení celkové koncepce řešení. Nedílnou součást tvoří i vlastní realizace s dostupnou součástkovou základnou a programovým vybavením. U komplexních systémů, kam spadá i konstrukce UAV, nelze často apriori shromáždit potřebnou bázi informací, nutnou k popsání chování systému (např. fyzická konstrukce draku, vlastnosti pohonů, aerodynamické vlastnosti, užitečná zátěž, příkon avioniky atd.), což bylo důvodem použití druhé metody. Start i přistání UAV provádí operátor z pozemního stanoviště pomocí bezdrátového řízení. Vlastní let a plnění úkolu mise musí být zcela autonomní s minimální komunikací s pozemním personálem. Základní seznam požadavků kladených na řídicí systém UAV: distribuované řízení v reálném čase, řídicí sběrnice se systémem priorit a garancí doručení zpráv, modulární struktura s pevně definovaným rozhraním, zálohování (redundance) klíčových prvků,

71 8 Vývojová platforma pro diagnostický podsystém 59 limitovaná hmotnost a příkon elektronického vybavení, přijatelná cena a dostupnost použité součástkové základny. Senzorický podsystém Motorický podsystém Inerciální navigační soustava Kompas GPS Výškoměr Autopilot Sběrnice řízení - CAN-BUS Pohonové elektromotory Řízení servopohonů Diagnostický podsystém Řídicí podsystém Komunikační podsystém Aplikační sběrnice Palubní síť Řízení sběrnice CAN Záznamník letových dat Aplikační SW & HW Obr. 42: Bloková struktura UAV Bezpilotní prostředek je členěn do následujících podsystémů: senzorický zajišťuje monitorování stavu vlastního systému, obsahuje čidla pro podporu své činnosti, pohon zahrnuje všechny části, které se podílejí na pohonu bezpilotního prostředku, autopilot obsahuje prvky pro stabilizaci pohybu UAV, diagnostický monitoruje stav UAV, hodnoty význačných provozních signálů porovnává s referenčními hodnotami a o výsledku zpravuje řídicí podsystém UAV, palubní síť její součástí jsou všechny prvky zapojené do procesu úpravy a distribuce napájecích napětí, řídicí zajišťuje plánování mise a podle něj řídí chování UAV, komunikační umožňuje obousměrnou komunikaci s pozemním stanovištěm, záznamník letových dat zaznamenává data o průběhu letu letounu, aplikační SW & HW rozšiřující zařízení (kontejner) realizuje vlastní úkol mise UAV.

72 8 Vývojová platforma pro diagnostický podsystém Distribuované řízení v reálném čase Základním univerzálním nástrojem, který se využívá při realizaci řídicích úloh, je operační systém. 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í. Řízení UAV vyžaduje naprosto přesně determinovatelné chování operačního systému se zaručenými odezvami, které kladou vysoké nároky v oblasti rychlosti reakce na vnější podněty. Použitý operační systém musí patřit do kategorie hard real-time OS, neboť pozdní odezva systému by mohla vést k destrukci UAV. Výběr OS je spjat s volbou vhodné hardwarové platformy schopné garantovat potřebný výpočetní výkon. V projektu Záznam II byl zvolen operační systém Linux s RTAI rozšířením na hardwarové platformě PC/AT kompatibilní. Jedním z hlavních důvodů byla cenová dostupnost tohoto řešení v porovnání s komerčními distribucemi OS pracujících v reálném čase. Centrální řídicí jednotka je založena na architektuře PC/104 a je kompatibilní s většinou běžně dostupného programového vybavení. Výhodou je zejména možnost využít předchozích znalostí z oblasti programového a technického vybavení PC a výrazně tak snížit čas a náklady potřebné pro vývoj. Systém je navíc mechanicky konfigurovatelný a rozšiřitelný standardními moduly typu PC/104. Obr. 43: Centrální řídicí jednotka - procesorový modul PC/104 Koncepce řešení postavená na hardwarové platformě PC/104 má mimo již zmíněné výhody i jednu zásadní nevýhodu. Obecně procesorový modul PC/104 (procesor a základní periferie PC) nedisponuje žádnými volnými číslicovými a analogovými vstupy/výstupy. Jakékoliv měření analogových veličin vyžaduje použití další rozšiřující měřicí karty. V případě UAV se jedná o distribuované měření, kdy se měřené veličiny nacházejí v různých částech letounu a centralizace měření je obtížná. Navržená varianta předpokládá zálohovanou centrální řídicí jednotku, do které jsou zasílány předzpracované informace po sběrnici CAN. Samotné měření je pak prováděno pomocí inteligentních senzorů připojených na sběrnici CAN.

73 8 Vývojová platforma pro diagnostický podsystém Řídicí sběrnice pro UAV Výběr optimální řídicí sběrnice zahrnoval analýzu sběrnic používaných v současné době pro víceprocesorové systémy. Každá z dostupných technologií má své klady a zápory, a proto může být vhodná pro jiný typ úlohy. Na základě požadovaných kritérií bylo nutné uvážit a stanovit základní množinu parametrů, kterých by měla výsledná sběrnice dosahovat. Studiem technické dokumentace jednotlivých sběrnic byla na závěr vybrána jako optimální sběrnice CAN (Controller Area Network). Vlastnosti sběrnice CAN: sdílená sběrnice s prioritním rozhodováním o přístupu k médiu, zaručená doba odezvy, libovolný uzel může vyslat zprávu, přenosová rychlost do 1 Mb/s, detekce chyb a automatické opakování chybných zpráv, automatické odpojení poškozených jednotek. Pro zvýšení spolehlivosti systému, byla použita zdvojená řídicí sběrnice CAN (hlavní a záložní). Následně došlo k vytvoření topologie a přiřazení priorit mezi jednotlivými uzly bezpilotního prostředku. Bezpilotní prostředek disponuje i aplikační sběrnicí určenou pro uživatelské aplikace spojené s úkoly plněných misí. Tato sběrnice se vyznačuje vysokou přenosovou rychlostí s možností připojení více uzlů a podle typu aplikační úlohy se může měnit (např. Ethernet, SPI, SMB atd.). Funkčnost zvoleného řešení byla ověřena programovou simulací komunikace jednotlivých uzlů uvnitř bezpilotního prostředku. K simulaci slouží vývojové prostředí CANalyzer. Výstupem programu je simulace letu bezpilotního prostředku s možností interaktivních změn přenášených parametrů. Prostředí CANanalyzer umožňuje kombinovat reálné prvky na sběrnici CAN s virtuálními (simulovanými) uvnitř PC. Lze snadno provádět verifikaci funkce sběrnice, uměle vnášet poruchy do systému a zkoumat odezvu systému Modulární struktura s pevně definovaným rozhraním Základem celého systému UAV je centrální řídicí jednotka založena na architektuře PC/104, ke které se přes rozšiřující kartu s CAN rozhraním připojují ostatní inteligentní senzory a podpůrné obvody. Jádro inteligentních senzorů tvoří výkonný 16bitový jednočipový mikropočítač (JM). Výběr správného JM je jedním z kritických rozhodnutí, která často ovlivňují úspěch či selhání celého projektu. Hlavním cílem při návrhu inteligentních senzorů byla volba moderního JM schopného splnit požadavky kladené současným trendem v oblasti vývoje vestavných zařízení. Stále více inteligentních periferií je integrováno přímo na čipu. Tato skutečnost se pozitivně projevuje co do nárůstu spolehlivosti (testování již během výroby, snížení počtu externích periferií) a komfortu při ovládání (dedikované instrukce procesoru). Vyloučení externích prvků sebou přináší i snížení požadavků na velikost desky plošných spojů a příkon celého zařízení. Poměr kapacity paměti RAM ku FLASH se v minulosti pohyboval 1:32, dnešní trend však směřuje k 1:16 (1:8). Větší kapacita paměti RAM umožňuje použít při

74 8 Vývojová platforma pro diagnostický podsystém 62 vývoji programového vybavení vyšších programovacích jazyků. Pro aplikace, kde se předpokládá změna kódu programu, jsou vhodné JM s pamětí programu typu FLASH a rozhraním ISP popř. JTAG. V komplexnějších projektech je těžiště při samotné realizaci v oblasti návrhu a testování firmwaru. Vhodná volba vývojových a podpůrných nástrojů šetří množství zbytečných komplikací nyní i v budoucnu. Není důvod se obávat nasazení vyšších programovacích jazyků. Sestavený kód programu v kvalitním překladači jazyka C pro JM je dnes plně srovnatelný s programem napsaným v jazyce symbolických adres. Jedním z klíčových prvků při výběru JM byla mimo dostatečného výpočetního výkonu (požadavky na výpočty v plovoucí řádové čárce) i fyzická integrace dvou řadičů CAN přímo na čipu. Byl vybrán JM Hitachi H8S/2638, který splňuje výše uvedené požadavky. Úlohy, u kterých hraje důležitou roli časování (např. ovládání servomotorů, přepínání řízení UAV), byly navrženy pomocí programovatelných logických obvodů FPGA (Field Programmable Gate Arrays) On-line záznam a komprimace dat Záznamové zařízení musí být schopno ukládat velké objemy dat ve standardním formátu tak, aby bylo možné tato data po ukončení letu jednoduše postoupit k dalšímu zpracování. Množství dat v nekomprimovaném stavu se předpokládá v řádech desítek až stovek megabajtů. Objem ukládaných dat se redukuje použitím bezztrátové komprimace. Existuje několik typů médií, která jsou schopná pojmout získaná data. Pro účely bezpilotního prostředku byla zvolena záznamová karta typu COMPACT FLASH, sloužící zároveň jako paměť systému souborů pro řídicí jednotku. Tato koncepce garantuje možnost ukládání dat do několika souborů současně a po skončení letu vysokorychlostní přenos dat do PC. Zvolené řešení ušetřilo řadu problémů v porovnání s vývojem proprietárního záznamového zařízení.

75 8 Vývojová platforma pro diagnostický podsystém Fyzická realizace UAV Fyzická realizace první generace UAV Drak bezpilotního prostředku je koncipovaný jako model letadla v hornoplošním uspořádání o hmotnosti 12 kg, délce 2,18 m a rozpětí 2,5 m. Hornoplošní uspořádání bylo zvoleno z důvodu autostabilizace letounu. Pohon zabezpečuje benzínový spalovací motor a napájení elektrických systémů je řešeno akumulátory. Užitečná zátěž je přibližně 2 3 kg. Bezpilotní prostředek je schopen dosáhnout rychlosti 80 km/h. Obr. 44: První generace UAV v hornoplošním uspořádání Fyzická realizace druhé generace UAV Drak druhé generace bezpilotního prostředku je koncipovaný jako model letadla v provedení delta křídla o hmotnosti 9,2 kg a rozpětí 2,8 m. Delta uspořádání bylo zvoleno z důvodu autostabilizace letounu za letu. Pohon zabezpečují akumulátory LiPol. Užitečná zátěž je přibližně 5 kg. Bezpilotní prostředek je schopen dosáhnout rychlosti 100 km/h. Obr. 45: Druhá generace UAV v provedení delta křídla

76 9 Experimenty v prostředí operačního systému reálného času 64 9 Experimenty v prostředí operačního systému reálného času Pro ověření navržených postupů a dosažení stanovených cílů disertační práce bylo během vypracování práce 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. 9.1 Výpočetní systém postavený na modulech PC/104 V kapitole 8 byla popsána koncepce vývojové platformy pro diagnostický podsystém. Základem pro navržený výpočetní systém (obr. 46) se staly moduly PC/104, které umožnily snadné a rychlé sestavení centrální řídicí jednotky pro bezpilotní letoun. Systém je tvořen dvěma procesorovými moduly MSM586SEV [22], vzájemně propojenými po sběrnici CAN (1 Mb/s) a Ethernet (100 Mb/s). Rozhraní CAN-Bus není přímo integrované na procesorovém modulu MSM586SEV. Z tohoto důvodu byl systém doplněn o modul sběrnice CAN PCM-3680 [2], disponující dvěma nezávislými rozhraními CAN. Vznikl tím systém poskytující dostatečný výpočetní výkon a funkcionalitu nezbytnou pro praktické ověření teoretických myšlenek v praxi. Procesorový modul MSM586SEV Prvním krokem při sestavení zvoleného řešení, bylo samotné zapojení a oživení procesorového modulu MSM586SEV, viz obr. 43. Specifikace PC/104 vznikla z potřeby použít počítače třídy PC pro vestavné systémy. Mechanické rozměry základních desek PC však nesplňují potřeby a zvyklosti praktikované ve vestavných systémech. Procesorový modul PC/104 (procesor + základní periferie PC) odpovídá funkčně základní desce PC, kterou lze rozšířit pomocí sběrnice PC/104 (modifikovaná verze ISA sběrnice) o další moduly. Jednotlivá rozhraní jsou vyvedena na konektorové lišty a podle potřeby můžeme připojit běžné periferie PC, což znamená připojit klávesnici, monitor, pevný disk a zdroj napájení. V závislosti na výrobci může být potřebná kabeláž součástí dodávky, nebo ji musíme vlastnoručně zhotovit. K uložení a zavedení OS můžeme použít pevný disk s IDE rozhraním, paměťové médium Compact Flash nebo jinou dostupnou variantu (Disk-on-Chip, paměť FLASH atd.). Pevný disk je těžký, mechanicky málo odolný a běžně vyžaduje napájení 5 a 12 V. Vhodnější se jeví použití paměti CF, kterou stačí zasunout do patřičného slotu a nastavit v BIOSu procesorového modulu. U systémů vystavených mimořádným mechanickým vibracím je nutno učinit patřičná opatření, např. zalepení (zalití) konektorů, vyloučení nadbytečných konektorů, zapájení do desky tištěného spoje. Napájecí zdroj musí být schopen dodat stabilizované napětí 5 V a proud špičkově do 3 A. Samotný procesorový modul neobsahuje prostředky pro stabilizaci napětí 5 V. Minimum integrovaných proudových a přepěťových ochran neskýtá příliš velkou ochranu elektroniky vzhledem k celkové ceně zařízení. Při experimentech bylo nutné

77 9 Experimenty v prostředí operačního systému reálného času 65 použít dostatečně tvrdý laboratorní zdroj, protože jinak docházelo k nestabilnímu chování systému. Z hlediska ochrany elektroniky a univerzálnosti nasazení je lepší použít samostatný modul stavebnice PC/104 fungující jako zdroj napětí. OS Linux na modulech PC/104 Klasické distribuce OS Linux používané pro desktopová a serverová řešení jsou navrženy tak, aby poskytly uživatelům co největší spektrum aplikací a služeb. Naproti tomu jsou vestavné systémy tvořeny na míru a jsou omezeny množstvím dostupných výpočetních a paměťových prostředků. Struktura OS Linux umožňuje upravit velikost systému do velice kompaktní podoby. Záleží pouze na znalostech patřičného vývojáře a jeho umu zvládnout danou úlohu. Principiálně musíme provést následující kroky: zjištění hardwarové konfigurace zařízení (CPU, chipset, sběrnice, paměti atd.), konfigurace a sestavení jádra pro cílové zařízení, vytvoření kořenového systému souborů (root filesystem), sestavení, instalace a konfigurace základních knihoven a systémových programů, sestavení, instalace a konfigurace zavaděče jádra. Detailní dokumentaci k hardwarové konfiguraci stolních PC lze dnes získat jen výjimečně. Spíše hovoříme o obchodních názvech, pod kterými je dané zařízení (komponenta) prodáváno. U vestavných systémů PC/104 tomu tak naštěstí není a z patřičné dokumentace se dá zjistit vše potřebné. Konfigurace jádra OS je díky různým grafickým nadstavbám relativně snadná a dobře zdokumentovaná. Na základě vlastností navrhovaného systému lze rozdělit jádro do samostatných modulů a částí napevno začleněných v jádře. Vytvoření kořenového systému souborů, představuje vytvoření hierarchické struktury adresářů a souborů nutných pro funkci OS. Z důvodů jednoduchosti je ve vestavných systémech upřednostňována statická varianta vytváření kořenového systému souborů. Samotné jádro OS je pouhým základním stavebním blokem, který je nutné dále rozšířit o systémové nástroje a knihovny. Projekt BusyBox [15] realizuje sadu nástrojů odpovídající běžným systémovým programům, ale v mnohem kompaktnější verzi. Obdobně je tomu i u knihovny libc [26] a jejích derivátů pro vestavné systémy. Zavedení OS do paměti řeší zavaděč jádra (bootloader), kterému po zapnutí zařízení předá BIOS řízení. Architektura IBM/PC nedisponuje nativním přesměrováním standardního vstupu a výstupu na sériovou linku. Po spuštění patřičně nakonfigurovaného zavaděče však tohoto efektu může též dosáhnout. Ovládání celého systému probíhá bez přítomnosti klávesnice a monitoru. Výstup BIOSu a jeho přesměrování závisí na výrobci. Moduly MSM586SEV používají proprietární protokol a bez speciální aplikace (platformově omezenou) není možno tuto vlastnost využít. Detailní popis a rozbor problematiky použití OS Linuxu ve vestavných systémech je popsán v literatuře [92].

78 9 Experimenty v prostředí operačního systému reálného času 66 ETH0 VGA KEYB LPT1 ETH0 VGA KEYB LPT1 UART ,N,8,1 RTS/CTS Procesorový modul PC/ MSM586SEV AMD ÉlanSC520 SDRAM 128 MB 133 MHz SJA SJA SJA SJA CAN0 CAN1 CAN0 CAN1 UART0 UART0 ETH0 CAN0 Centrální řídicí jednotka I. Centrální řídicí jednotka II. Procesorový modul PC/ MSM586SEV AMD ÉlanSC520 SDRAM 128 MB 133 MHz CFC 128 MB 5V/1A UART1 sběrnice PC/104 UART1 sběrnice PC/104 Dohledové centrum ovládání a monitorování řídicích jednotek Ethernet 10/100 Mb/s CFC 128 MB 5V/1A Modul sběrnice CAN PCM-3680 Modul sběrnice CAN PCM-3680 sběrnice CAN 1 Mb/s sběrnice CAN 1 Mb/s Obr. 46: Bloková struktura výpočetního systému postaveného na modulech PC/104

79 9 Experimenty v prostředí operačního systému reálného času Vývojový řetězec pro platformu PC/104 Technické vybavení nutné pro vývoj a oživení systému Při ověřování návrhu technického vybavení je často nutné otestovat zapojení a funkci jednotlivých funkčních bloků nově navrhovaného systému. Použité moduly PC / 104 nebylo nutno nikterak dále upravovat popř. rozšiřovat o periferie vlastní konstrukce. Při ladění časově podmíněné obsluhy periferií a při analýze odezvy systému na vnější události je nutná hardwarová emulace a záznam dějů v reálném čase. Většina nových CPU (MCU) je k těmto účelům vybavena některým z rozhraní JTAG, BDM nebo jiným rozhraním charakteristickým pro daného výrobce. Odpadá nutnost použít klasický obvodový emulátor CPU. Ladící nástroje postavené na integrované podpoře uvnitř CPU představují levnou alternativu vůči drahým emulátorům. Jsou vhodné pro ověření logické funkce zařízení, ale při ladění složitých časových průběhů mohou mít své hranice. Procesorový modul MSM586SEV je osazen CPU AMD ÉlanSC520 [4]. JTAG rozhraní je vyvedeno na externí konektor. Programová a hardwarová podpora je možná pomocí technologie AMDebug dostupná v nástrojích firmy CAD-UL. Jedná se o komerční rozšíření GNU vývojového prostředí. Uvedené nástroje však nebyly k dispozici a nebylo je možné prakticky vyzkoušet. Programové vybavení nutné pro vývoj aplikací Vývojové nástroje se využívají k převodu zdrojového kódu programu do strojového kódu, který bude následně vykonávat cílový procesor. Jednotlivé vývojové prostředky jsou členěny hierarchicky a překlad je postupně prováděn z vyšší do nižší úrovně. Pro lepší přenositelnost mezi systémy je v dnešní době na systémové úlohy upřednostňován programovací jazyk C a C++. Pro úlohy na aplikační úrovni se pak jedná o programovací jazyky ADA, C, C++, dále pak JAVA, PYTHON, PERL atd. Programové vybavení pro moduly PC/104, realizované během řešení disertační práce, bylo napsáno v jazyce C. Byl zvolen volně dostupný překladač jazyka C GCC (GNU Compiler Collection) [33], který je k dispozici pro většinu operačních systémů. Velkým přínosem je okolnost, že ve většině případů lze po drobné modifikaci zdrojového kódu program sestavit pro jinou cílovou platformu (cross platform development). Další nezanedbatelnou skupinu nástrojů tvoří prostředky pro kontrolu, hledání zdrojů chyb a měření rychlosti vykonávání aplikací. U systémů s dostatečnými výpočetními zdroji je využíváno přímo funkcí OS a speciálních uživatelských aplikací. V případě, že nelze použít tento přístup (jednočipové mikropočítače), jsou využívány prostředky popsané v předchozím bodě popř. ladění probíhá na úrovni zdrojového kódu (source level debugging).

80 9 Experimenty v prostředí operačního systému reálného času 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 byla zabudována minimalizovaná verze diagnostické ústředny (DÚ) [14, 74]. Cílem experimentu bylo ověřit základní funkce DÚ v reálných podmínkách. Během pilotovaného 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. 47. 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. gyroskop GPS 16A elektronický kompas PC/104 Obr. 47: 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. 48. 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 příkazem shutdown(8). Z důvodu limitované životnosti (omezený počet zápisů) paměťové karty CF, byla data ukládána do paměti RAM (tmpfs temporary filesystem). Každých pět minut systém provedl periodickou zálohu naměřených dat (fyzický zápis na CF). Zápis dat byl proveden i během operací restartu a vypnutí systému. Konfigurace centrální řídicí jednotky distribuce OS Linux - LiRE verze 0.2 [77], jádro operačního systému verze , RTAI verze , BusyBox verze , ovládání přes rádiový modul připojený na sériové rozhraní UART0 (ttys0), záznam o průběhu letu na paměťové médium CF 256 MB, napájení z osmi článků NiMH baterie SANYO 3000 mah. 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 mecha-

81 9 Experimenty v prostředí operačního systému reálného času 69 Aerocomm AC MHz radio link 5V / 1A 9600,N,8,1 RTS/CTS UART0 Procesorový modul PC/104 - MSM586SEV AMD ÉlanSC520 SDRAM 128 MB 133 MHz UART ,N,8,1 elektronický kompas HMR V / 24mA GPS 16A 8V / 100mA 38400,N,8,1 UART1 CFC 256 MB 5V/1A UART ,N,8,1 gyroskop 8V / 200mA aktivní chlazení NiMH baterie 8 článků SANYO mah Zdroj napájení napětí z baterie 9,2V stabilizátor 5V / 5A stabilizátor 3,3V / 1A Obr. 48: Bloková struktura výpočetního systému použitého během experimentu nickým uchycením konektorů, které v důsledku vibrací uvnitř UAV vedly k jejich svévolnému rozpojení. 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. 49 je znázorněna dosažená výška během letu UAV, vztažená k nadmořské výšce letiště. Je nutné uvést, že v naměřených datech se objevil i záznam se zápornou nadmořskou výškou. Pro další použití GPS přijímače to znamená věnovat patřičnou pozornost naměřeným hodnotám, které budou použity k samotnému řízení UAV. 180 UAV - Flight Level (Přerov ) Flight Level Flight Level [m] :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. 49: Průběh dosažené výšky zaznamenaný z GPS přijímače

82 9 Experimenty v prostředí operačního systému reálného času 70 Na obr. 50 je znázorněna trajektorie letu UAV. Jedná se o převedení obr. 49 do 3D rozměru. UAV - Flight (Přerov ) Flight Level Flight Level [m] landing launching Longtitude Latitude Obr. 50: Průběh letu zaznamenaný z GPS přijímače ve 3D zobrazení 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 [14, 18]. V DÚ byla použita zjednodušená verze výpočetního systému (obr. 48) 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 další pozornost hlavně snímačům inerciální navigační soustavy a jejich okolí. Během experimentu se podařilo lokalizovat slabá místa navrženého výpočetního systému. Jednoznačně se ukázalo, že mechanické namáhání (vibrace působící na systém) jsou tak veliké, že dochází ke svévolnému rozpojování použitých konektorů. Výpadky radiového spoje prokázaly původní domněnku, že použité moduly Aerocomm AC 4486 nejsou vhodné pro nestacionární objekty, kde dochází ke změně polohy přijímače a vysílače. Nainstalovaný operační systém nevykazoval žádné výpadky. Systém fungoval spolehlivě a v logovacích záznamech se neobjevily žádné poruchy. V další generaci výpočetního systému bylo naplánováno odstranění výše popsaných problémů. Navíc měl být systém doplněn o diagnostické prostředky popsané v kapitole 5. Další praktické experimenty s UAV však byly negativně ovlivněny situací kolem podpory vědy a výzkumu v resortu ministerstva obrany. Vývoj personální situace na půdě UO postupně vedl ke stavu, kdy část vývojového týmu odešla na jiné vysoké školy nebo do vševojskové praxe. V důsledku těchto událostí byly navazující experimenty provedeny už pouze v laboratorních podmínkách.

83 9 Experimenty v prostředí operačního systému reálného času 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 a real-time rozšířením RTAI 3.1. Provedené testy vycházely z testů, které jsou součástí zdrojového kódu RTAI a jednalo se o: test latence, test preemptivity, test přepínačů. Jako doplňující test bylo provedeno měření vstupně/výstupních operací na paralelním portu PC. Detailní popis jednotlivých testů je uveden v [54]. Následující výčet představuje krátké shrnutí provedených testů a jejich výsledků. Test latence Test slouží k ověřování latence použité HW platformy a časové nestability (jitter) od spuštění úlohy až po fázi plánování. Je-li použit se stabilním časovým spínačem v režimu jednorázového měření (oneshot), pak ho lze využít k přesnému seřízení průměrné latence plánovače úloh reálného času. V režimu oneshot se jedná o měření rozdílu v čase, resp. rozdílu mezi předpokládanou dobou spuštění a dobou samotného zařazení úlohy do časového rozvrhu. Naproti tomu v cyklickém režimu odpovídají odchylky v délce periody úlohy hodnotě zpoždění při plánování (časové nestabilitě). ## RTAI latency calibration tool ## # period = (ns) # avrgtime = 1 (s) # check overall worst case # do not use the FPU # start the timer # timer_mode is oneshot 2005/04/18 09:01:34 min: max: average: /04/18 09:01:35 min: max: average: /04/18 09:01:36 min: max: average: Test preemptivity Test preemptivity je zaměřený na ověření faktu, že časové plánovače pracují při velké zátěži preemptivně. Jedná se o jednoduchý test, v němž je kombinováno měření latence s rychlou a pomalou úlohou takovým způsobem, že máme dva stupně preemptivity, v nichž jsou dány dohromady různé (nepárové) úlohy. Výstupem testu jsou výchylky kontroly zpoždění (min/max/průměrná hodnota), největší priorita a maximální výchylka rychlé a pomalé úlohy. Přiměřené výchylky jsou známkou preemptivity. RTAI[sched_up]: timer setup=1676 ns, resched latency=2514 ns. * latency: min: -98, max: 348, average: 17; fastjit: 164, slowjit: 27 * latency: min: -98, max: 348, average: 16; fastjit: 197, slowjit: 27 * latency: min: -98, max: 358, average: 17; fastjit: 197, slowjit: 27

84 9 Experimenty v prostředí operačního systému reálného času 72 Test přepínačů Test zkouší čas přepínání úloh opakovaným procházením stavů pozastavení/pokračování a semaforu signál/čekej. Test odpovídá zpracovávání přibližně třiceti úloh. Výsledkem testu je doba nezbytná pro přepnutí úlohy. FOR 30 TASKS: TIME 626 (ms), SUSP/RES SWITCHES , SWITCH TIME (INCLUDING FULL FP SUPPORT) 5215 (ns) FOR 30 TASKS: TIME 579 (ms), SEM SIG/WAIT SWITCHES , SWITCH TIME (INCLUDING FULL FP SUPPORT) 4828 (ns) Test vstupně/výstupních operací na paralelním portu PC 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 (např. překlad jádra operačního systému, umělé zatížení CPU atd.) 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í. Na obr. 51 je zobrazeno zapojení měřicího pracoviště během experimentu. Generovaný obdélníkový signál je přiveden na číslicový osciloskop, kde je měřena jeho frekvence. procesorový modul PCM-3350 číslicový osciloskop paralelní port kanál A D0 (vývod 2) GND (vývod 25) Obr. 51: Zapojení měřicího pracoviště během experimentu Pro generování obdélníkového signálu na paralelním portu je použita funkce outb(), která provádí fyzický zápis do výstupních registrů periferií PC. V prvním kroku jsou vývody paralelního portu D0-D7 přepnuty do výstupního režimu. Následně jsou v nekonečné smyčce na paralelní port zapisovány hodnoty 00h a FFh. K testování na paralelním portu byly sestaveny dva programy. Zdrojové kódy obou programů jsou součástí přílohy C disertační práce. První varianta programu (rect.c) nevyužívá žádné podpůrné real-time funkce a demonstruje běžné real-time vlastnosti OS Linux. Druhá varianta programu (rtai.c) využívá RTAI funkcí, které doplňují real-time vlastnosti do OS Linux. Testy byly provedeny v režimu bez zatížení výpočetního systému a se stimulovanou zátěží. K zatížení systému byl použit program stress. Program umožňuje nastavení řady kombinací typů zatížení. Během experimentu bylo použito následující nastavení programu stress: # stress cpu 15 io 15 vm 15 vm-bytes 1M hdd5 hdd-bytes 200M timeout 30s

85 9 Experimenty v prostředí operačního systému reálného času 73 Úroveň zatížení procesoru lze následně sledovat například pomocí programu top(1). Program stress zatěžuje bohužel pouze jádro OS Linux a jím spuštěné aplikace. OS Linux je spuštěn v rámci RTAI jako proces s nejnižší prioritou (idle process). Samotné RTAI tím pádem není zcela optimálně zatíženo. Pro zatížení vlastního RTAI by bylo nutné spustit real-time procesy, běžící přímo pod RTAI. Přes tento fakt výsledky měření jednoznačně ukazují, která varianta splňuje real-time podmínky a která ne. Na obr. 52 je zobrazen výsledek testu běžného OS Linux bez zátěže. Zobrazený obdélníkový signál má frekvenci 500 Hz a nevykazuje žádné výpadky. Dosažený nízký kmitočet odpovídá rozlišení daném hlavním časovačem OS Linux, které je typické pro GPOS, kde je výkon optimalizován na průměrný výkon (dobu odezvy). Zápisy na paralelní port byly prováděny bez jakéhokoliv zpoždění a změny hodnot 00h FFh 00h se měly projevit okamžitou změnou na výstupu. Voláním funkce outb() došlo k zápisu na paralelní port a jádro operačního systému následně předalo řízení další úloze. Obr. 52: Test paralelního portu bez zátěže - běžný Linux

86 9 Experimenty v prostředí operačního systému reálného času 74 Na obr. 53 je zobrazen výsledek testu běžného OS Linux se zátěží. Je vidět, že dosažená frekvence obdélníkového signálu zůstala stejná jako v předchozím případě. Dochází však k výpadkům v průběhu signálu a jeho nestálosti. Toto chování odpovídá stavu, kdy operační systém v důsledku zatížení (např. ukládání dat na disk) není schopen obsloužit danou úlohu v přesně definovaném čase. Obr. 53: Test paralelního portu se zátěží - běžný Linux Na obr. 54 je zobrazen výsledek testu OS Linux s RTAI rozšířením bez zátěže. Zobrazený obdélníkový signál má frekvenci 10 khz a nevykazuje žádné výpadky. Dosažený vysoký kmitočet odpovídá rozlišení daném hlavním časovačem RTAI, který je upraven pro potřeby RTOS. Systém je optimalizován pro dosažení rychlé doby odezvy. Zápisy na paralelní port jsou prováděny po 50 µs, což odpovídá změřené frekvenci 10 khz. f = 1 T = 1 t 0 + t 1 = 1 50 µs + 50 µs = 10 khz Obr. 54: Test paralelního portu bez zátěže - Linux s RTAI rozšířením

87 9 Experimenty v prostředí operačního systému reálného času 75 Na obr. 55 je zobrazen výsledek testu OS Linux s RTAI rozšířením se zátěží. Zobrazený obdélníkový signál má stejné vlastnosti jako v předchozím případě, kdy nedocházelo k zatížení výpočetního systému programem stress. Obr. 55: Test paralelního portu se zátěží - Linux s RTAI rozšířením Závěr k testování real-time vlastností OS Linux Provedený experiment demonstruje základní real-time vlastnosti OS Linux. Je 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 a případnými dalšími modifikacemi na úrovni zdrojového kódu jádra (viz např. 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. 9.5 Experiment s diagnostickou sběrnicí pro real-time systémy Cílem experimentu bylo ověřit vlastnosti vybraných sběrnic (rozhraní) použitelných pro diagnostickou sběrnici v real-time systémech. Testy vycházely ze struktury výpočetního systému popsaného v kap 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. RTnet [76] je open-source hard real-time síťový protokol pro RTAI. Ke své funkci využívá standardních síťových adaptérů, na kterých implementuje podporu pro protokoly UDP/IP, ICMP a ARP. RTnet poskytuje aplikační rozhraní na bázi BSD

88 9 Experimenty v prostředí operačního systému reálného času 76 soketů (Berkeley sockets) pro použití s RTAI moduly jádra a LXRT procesy (RTAI real-time rozšíření pro uživatelský prostor). 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. Oddělený ethernetový segment je nezbytný pro garanci ohraničených prodlev přenosu. RTnet vytváří mechanizmy pro vytvoření tunelu pro TCP/IP komunikaci klasického Linuxu přes RTmac. MASTER PC IP: /24 eth0 SLAVE procesorový modul PCM-3350 IP: /24 eth0 RTnet rozbočovač (HUB) RTnet RTnet eth0 IP: /24 monitorovací PC v promiskuitním režimu Obr. 56: 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. 56. V první fázi byla provedena základní konfigurace a propojení všech uzlů sítě, kterou tvořily master a slave. Pro sledování vzájemné komunikace mezi uzly sítě byl zapojen třetí počítač, který se síťovým adaptérem v promiskuitním režimu zobrazoval zachycená data. K zobrazení dat byl použit program Ethereal s modulem pro dekódování protokolu RTnet. Na obr. 57 je zachycena komunikace mezi nadřízeným uzlem (AcerTech_a0:a7:82) a podřízeným uzlem (Advantec_01:63:99) při navazování spojení. Ve střední části obrázku je zobrazen obsah rámce, kterým rozesílá nadřízený uzel všesměrovým vysíláním oznámení, že ukončil konfiguraci (vytvoření) sítě a je připraven ke komunikaci. Při testování vlastností protokolu RTnet se ukázalo, že konfigurace není zcela triviální záležitostí. Značnou roli hrály i chyby v konfiguračních skriptech, obsažené ve verzi 0.8.1, která byla během testů k dispozici. Naštěstí se podařilo tyto chyby odhalit a následně nahlásit vývojářům projektu RTnet. Popis upravených spouštěcích skriptů a další doplňující informace ohledně zprovoznění RTnet je uveden v [54].

89 9 Experimenty v prostředí operačního systému reálného času 77 Měření doby zpoždění v síti RTnet Obr. 57: Zachycená komunikace v síti RTnet Jedná se o měření doby odezvy (round trip time) při komunikaci mezi dvěma uzly v síti RTnet, viz obr. 58. Klient vysílá paket s časovou značkou t 0 na server, který paket přijme a neprodleně odešle zpět klientovi. Po přijmutí paketu klient vytvoří druhou časovou značku t 1 a vypočte dobu zpoždění na síti podle následujícího vzorce round trip time = t 1 t 0 klient server t 0 t 1 Obr. 58: Princip měření doby zpoždění na síti Zdrojový kód testovací aplikace je součástí zdrojového kódu projektu RTnet a v testované verzi byl uložen v adresáři addons/examples/round-trip-time. Následující výpis zobrazuje výsledky měření doby zpoždění v síti RTnet.