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

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.

Brno 2007

Ing. Pavel Čeleda

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.

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 2007

....................................................

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

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

vi

Obsah 1 Úvod 1.1 Formulace problému . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle disertační práce . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Struktura disertační práce . . . . . . . . . . . . . . . . . . . . . . . . 2 Charakteristika současného stavu 2.1 Operační systémy reálného času . . . . . . . . . . . . . . . 2.1.1 Volba operačního systému reálného času . . . . . . 2.1.2 Operační systém Linux . . . . . . . . . . . . . . . . 2.1.3 Uplatnění operačního systému Linux v armádě . . . 2.1.4 Rozšíření reálného času pro operační systém Linux 2.1.5 Real-time mikrojádro . . . . . . . . . . . . . . . . . 2.1.6 Monolitické jádro s real-time rozšířením . . . . . . . 2.1.7 Certifikace a dodržování platných norem . . . . . . 2.2 Spolehlivost operačních systémů reálného času . . . . . . . 2.2.1 Inherentní spolehlivost programového vybavení . . . 2.2.2 Návrh a tvorba programového vybavení . . . . . . . 2.2.3 Testování a nasazení programového vybavení . . . . 2.3 Diagnostika operačních systémů reálného času . . . . . . . 2.3.1 Systémy profylaktické diagnostiky . . . . . . . . . . 2.3.2 Systémy funkční diagnostiky . . . . . . . . . . . . .

1 2 3 4

. . . . . . . . . . . . . . .

5 5 6 8 8 9 9 10 10 11 12 13 14 15 16 17

. . . . . . . . . . .

19 19 19 20 21 22 23 23 25 25 26 27

4 Volba metody pro řešení cílů disertační práce 4.1 Charakteristika navrhovaného systému . . . . . . . . . . . . . . . . . 4.2 Volba diagnostické metody . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Volba metody návrhu spolehlivého programového vybavení . . . . . .

28 28 29 30

3 Možné metody řešení cílů disertační práce 3.1 Zdroje chyb a poruch výpočetních systémů . . . . . . . . . 3.1.1 Výskyt poruch na úrovni součástek . . . . . . . . . 3.1.2 Výskyt poruch na úrovni technického vybavení . . . 3.1.3 Výskyt chyb v prostoru jádra operačního systému . 3.1.4 Výskyt chyb v uživatelském prostoru . . . . . . . . 3.2 Metody diagnostiky programového a technického vybavení 3.3 Metody návrhu spolehlivého programového vybavení . . . 3.3.1 N-násobné programování . . . . . . . . . . . . . . . 3.3.2 Bloky zotavení . . . . . . . . . . . . . . . . . . . . 3.3.3 SIFT – programově implementovaná odolnost . . . 3.3.4 Kontrolní diagnostické časovače a procesory . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . .

vii 5 Diagnostický podsystém pro operační systémy reálného času 5.1 Koncepce diagnostického podsystému . . . . . . . . . . . . . . . 5.1.1 Uživatelské rozhraní pro dohled nad systémem . . . . . . 5.1.2 Hlavní diagnostická jednotka . . . . . . . . . . . . . . . . 5.1.3 Řídicí jednotky se zabudovanými diagnostickými prvky . 5.2 Návrh diagnostického podsystému . . . . . . . . . . . . . . . . . 5.2.1 Diagnostické rozhraní operačního systému . . . . . . . . 5.2.2 Systém diagnostických zpráv . . . . . . . . . . . . . . . . 5.2.3 Správce diagnostických úloh . . . . . . . . . . . . . . . . 5.3 Dopady na real-time vlastnosti systému . . . . . . . . . . . . . . 5.4 Přenositelnost navrženého řešení . . . . . . . . . . . . . . . . . . 6 Diagnostický časovač pro operační systémy reálného času 6.1 Diagnostický časovač . . . . . . . . . . . . . . . . . . . . . . 6.2 Výhody a nevýhody diagnostického časovače . . . . . . . . . 6.3 Programově realizovaný diagnostický časovač . . . . . . . . . 6.4 Inteligentní diagnostický časovač . . . . . . . . . . . . . . . . 7 Model diagnostického podsystému 7.1 Popis systému metodou MDA . . . . 7.2 Platformově nezávislý model systému 7.3 Model cílové platformy . . . . . . . . 7.4 Platformově specifický model systému 7.5 Generování zdrojového kódu . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8 Vývojová platforma pro diagnostický podsystém 8.1 Volba koncepce bezpilotního prostředku . . . . . . . . . . . . 8.2 Distribuované řízení v reálném čase . . . . . . . . . . . . . . 8.2.1 Řídicí sběrnice pro UAV . . . . . . . . . . . . . . . . 8.2.2 Modulární struktura s pevně definovaným rozhraním 8.2.3 On-line záznam a komprimace dat . . . . . . . . . . . 8.3 Fyzická realizace UAV . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . . .

. . . . . .

9 Experimenty v prostředí operačního systému reálného času 9.1 Výpočetní systém postavený na modulech PC/104 . . . . . . . 9.2 Vývojový řetězec pro platformu PC/104 . . . . . . . . . . . . 9.3 Experiment letiště Přerov . . . . . . . . . . . . . . . . . . . . 9.4 Testování real-time vlastností OS Linux . . . . . . . . . . . . . 9.5 Experiment s diagnostickou sběrnicí pro real-time systémy . . 9.6 Experiment s inteligentním diagnostickým časovačem . . . . .

. . . .

. . . . .

. . . . . .

. . . . . .

. . . . . . . . . .

. . . .

. . . . .

. . . . . .

. . . . . .

. . . . . . . . . .

. . . .

. . . . .

. . . . . .

. . . . . .

. . . . . . . . . .

33 33 33 34 35 35 35 38 40 42 44

. . . .

46 46 47 47 48

. . . . .

50 50 51 54 56 56

. . . . . .

58 58 60 61 61 62 63

. . . . . .

64 64 67 68 71 75 79

viii 10 Výsledky disertační práce s uvedením nových poznatků 10.1 Diagnostický podsystém pro operační systémy reálného času 10.2 Model diagnostického podsystému . . . . . . . . . . . . . . . 10.3 Vývojová platforma pro diagnostický podsystém . . . . . . . 10.4 Experimenty v prostředí operačního systému reálného času .

. . . .

. . . .

. . . .

. . . .

. . . .

82 82 82 83 84

11 Konkrétní závěry pro využití výsledků práce v praxi a pro rozvoj vědního oboru 86 12 Závěr

87

Přílohy

88

A Seznam použité literatury

89

B Generování zdrojového kódu 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 . . . . . .

96 96 97 101

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 . . . . . . . . 103 C.2 Test na paralelním portu s real-time podporou - rtai.c . . . . . . . . . 104 D Inteligentní diagnostický časovač

106

E Obsah přiloženého CD

109

ix

Seznam obrázků 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

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 t0 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 7 9 11 13 19 20 21 24 25 26 26 27 27 28 29 31 31 34 36 37 38 39 39 40 41 41 42 43 43 43 46 48 50 51 52 52 53 54

x 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62

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/104 . . . . . . . . . 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/104 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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řĳímače . . . . . . . . Průběh letu zaznamenaný z GPS přĳí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 . . . . . . . . . . . .

56 57 59 60 63 63 66 68 68 69 70 72 73 74 74 75 76 77 77 78 79 80 80

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

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

1

1

Úvod

1

Úvod

Vyspělé prvky informačních technologií jsou stále častěji aplikovány do celé řady přístrojů a zařízení. V mnoha případech nejsou nikterak nápadné a unikají naší pozornosti. Staly se nedílnou součástí dnešní doby a jejich vliv do budoucna stále poroste. Společnou vlastností, kterou se vyznačují, je narůstající množství na ně kladených kritérií, požadavků a úkolů. Vnitřní struktura těchto systémů je stále více složitější. Narůstá objem programového vybavení, které je nutné vytvořit a spravovat po celou dobu životnosti systému. Základ programového vybavení, které se využívá při realizaci řídicích úloh tvoří operační systém (OS – Operating System). Jeho vlastnosti a chování fundamentálně ovlivňují praktické možnosti výsledného řízení a do značné míry i architekturu řídicích aplikací. Operační systémy určené pro řídicí úlohy jsou označovány jako operační systémy reálného času (RTOS – Real-Time Operating System). Hlavní rozdíl, kterým se operační systémy reálného času odlišují od běžně používaných operačních systémů, spočívá v potenciálních následcích, které mohou vzniknout při nesplnění požadovaných kritérií. 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í.

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.

1

Úvod

1.2

3

Cíle disertační práce

S ohledem na zvýšení inherentní spolehlivosti je důležité nalezení způsobu, jak z dlouhodobého hlediska popsat vytvářené programové vybavení. Popis (model systému) musí vystihovat, jaké funkce má systém plnit a musí být nezávislý na cílové platformě. Postupná transformace modelu systému by měla za výsledek finální podobu aplikace (zdrojový kód). Pozdější úpravy by byly prováděny pouze na úrovni modelu odkud by se změny, pokud možno automaticky, promítnuly do ostatních navazujících částí. Model by zároveň sloužil jako výchozí zdroj pro ostatní procesy spojené s tvorbou programového vybavení. Jednalo by se např. o verifikaci systému formálními metodami či automatické vytváření programové dokumentace. Cílem disertační práce 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.

1

Úvod

1.3

4

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 studĳní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.

2

5

Charakteristika současného stavu

2


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]. nonreal-time

soft real-time

hard real-time

1111111111111111111111111111111111111111 0000000000000000000000000000000000000000 0000000000000000000000000000000000000000 1111111111111111111111111111111111111111 0000000000000000000000000000000000000000 1111111111111111111111111111111111111111 0000000000000000000000000000000000000000 1111111111111111111111111111111111111111 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) – http://www.windriver.com, QNX Software Systems (QNX Neutrino) – http://www.qnx.com, Green Hills Software (INTEGRITY) – http://www.ghs.com, LynuxWorks (LynxOS) – http://www.lynuxworks.com, Microsoft Corporation (Windows CE) – http://www.windowsembeddedkit.com.

2


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) – http://ecos.sourceware.org, OAR Corporation (RTEMS) – http://www.rtems.com, MontaVista Software (MontaVista Linux) – http://www.mvista.com, TimeSys (TimeStorm Linux) – http://www.timesys.com, RTAI (Real-Time Linux Application Interface) – http://www.rtai.org, FSMLabs (Real-Time Linux) – http://www.fsmlabs.com.

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 LinuxDevices.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. 2.1.1

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-

2

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í. složitost 11111111111111 00000000000000 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 00000000000000 11111111111111 čas

komunita vývojářů malá

t

iv os

hl

le

sp o

velká

komunita uživatelů malá

velká

nízká

vysoká

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.

2


2.1.2

8

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. 2.1.3

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í

2

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]. 2.1.4

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 1003.1. 2.1.5

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]. meziprocesová komunikace

Uživatelské úlohy 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

2


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. 2.1.6

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 1003.1. 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. 2.1.7

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].

2

11

Charakteristika současného stavu Varování

Chyby 60

5000 2.6.7

4500

2.6.8

2.6.9

2.6.11

2.6.10

50

4000 3500

40

30

2500

Chyby

Varování

3000

2000 20

1500 1000

10

500

22.3.2005

8.3.2005

8.2.2005

22.2.2005

25.1.2005

11.1.2005

28.12.2004

14.12.2004

30.11.2004

16.11.2004

2.11.2004

19.10.2004

5.10.2004

7.9.2004

21.9.2004

24.8.2004

10.8.2004

27.7.2004

13.7.2004

29.6.2004

15.6.2004

1.6.2004

0 18.5.2004

0

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 010102. 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.

2


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. 2.2.1

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

2

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. 2.2.2

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í.

2


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. 2.2.3

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í.

2


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-

2


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í. 2.3.1

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.

2


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. 2.3.2

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řĳatelný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.).

2


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).

3

19

Možné metody řešení cílů disertační práce

3


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)

porucha SW v jádře

vstupní data uživatel zdroje poruch špatné časování

rekonfigurace SW

programové vybavení (RTOS) - jádro OS - plánovač

- sdílení zdrojů RTOS - zotavení po chybě

porucha HW

přetečení paměti inverze priorit zdroje poruch kompromitace RTOS

rekonfigurace HW

technické vybavení (HW) - CPU (registry) - CRC, hlasování - paměť - redundance (NMR) dočasná porucha

rušení odchylky na napájení zdroje poruch špatné časování

reinicializace HW

součástková základna - tranzistory - zesilovače místo poruchy

- reset - power-down

záření (kosmické,...) mechanické namáhání zdroje poruch

oprava chyby

Obr. 6: Zdroje poruch a místa výskytu chyb v rámci výpočetního systému

3.1.1

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

3

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 3.1.2

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.

3

21


A

&

t0 1

B

F

& C Obr. 8: Porucha trvalé nuly t0 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ů. 3.1.3

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.

3


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. 3.1.4

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.

3


3.2

23

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ň

3

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 kód

vizualizace kódu

obousměrný vývoj

transformace modelu

pouze model

model

model

model

model

kód

kód

kód

kód

model neexistuje

kód je modelem

kód a model koexistují

model je kódem

kód neexistuje

Obr. 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.

3

25


3.3.1

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. a

a

Xi

Xj verze č. 1

b

b

Xi

verze č. 2

n

n

Xi

rozhodovací algoritmus

Xj

Xj verze č. n

Obr. 10: Princip N-násobného programování

3.3.2

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í

3

26


podle první z variant a testem přĳatelnosti 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žĳe 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

paměť zotavení

test přijatelnosti

varianta č. 2

výstup splněn

nesplněn

vstup

varianta č. n přepnutí na další variantu

Obr. 11: Princip bloků zotavení

3.3.3

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.

3

27


3.3.4

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

programové nulování

porucha

R 1

&

nulování

S Q

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 příznaky

systémová sběrnice operační paměť

v/v zařízení

Obr. 14: Diagnostický procesor

4

28

Volba metody pro řešení cílů disertační práce

4


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

statická

hybridní

TMR NMR

informační redundance

detekce parita

CRC

korekce

časová redundance

opakovaný výpočet

RESO

ECC

dynamická

programová redundance

N-násobné kontrolní body programování watchdog bloky zotavení

nezatížená zatížená odlehč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,

4


vestavné systémy

11 00 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 11 00 0011 11 00 11

29

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. 15.

4.2

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,

4


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: • • • •

4.3

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.

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řĳatelnosti, 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ě

4

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 funkční popis

transformace

PSM platformově závislý popis

transformace

KÓD 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. zadání teoretický iterační proces

zadání text

text MDA proces

analýza

analýza

diagramy a text návrh

PIM návrh

diagramy a text implementace praktický průběh vývoje

PSM implementace

zdrojový kód testování

zdrojový kód testování

zdrojový kód nasazení

zdrojový kód nasazení

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

4


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ů.

5

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

5

33


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 1149.1 [41] (IEEE Standard Test Access Port and Boundary Scan Architecture). IEEE 1149.1 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. 20. 5.1.1

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).

5


34

dohledové centrum

hlavní diagnostická jednotka

řídicí jednotka 1

řídicí 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í). 5.1.2

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.)

5


5.1.3

35

Ří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 x86. 5.2.1

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

5


36

uživatelský prostor proces n

proces 2

proces 1

diagnostický a monitorovací manažer

diagnostická sběrnice

diagnostický modul jádra

jádro RTOS

prostor jádra

Obr. 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ů

5


Proces 1

Proces 2

řídicí stavový diagram

řídicí stavový diagram

diagnostický stavový diagram

diagnostický stavový diagram

37

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 1149.1 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ě

5

Diagnostický podsystém pro operační systémy reálného času CODE - kódový segment (instrukce programu)

0xF000

DATA - datový segment (data programu)

Proces 1

Proces 1

Kód řídicího procesu

Data řídicího procesu

... if(pressure > 10) { printf("Alarm - pressure to high !"); } ...

Proměnné - var. pressure

Struktury - engine_01

- var. temp_01 -...var. temp_02

- engine_02 -...engine_03

Proměnné a datové struktury mapované (sdílené) mezi řídicím procesem a diagnostickým rozhraním.

0xE800 Kód diagnostického rozhraní ... switch (command) { case 0: value = read_mem(addr_reg); break; ...

38

0x1000

0x0800

Uživatelem definované diagn. registry Základní diagnostické registry - adresový registr - datový registr ... Data diagnostického rozhraní

0xE600

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. 5.2.2

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

5


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řĳí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í.

5


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). 5.2.3

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. 5.1.2. 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

5


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: watchdog id: diagnostics enabled: address register: data register: control register: status register:

1 1 yes 0x1A25 0x0012 0x3000 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ř.

5


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í.

testovaný systém testovací vektory

úloha

výsledek měření

systém reálného času 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.

5


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 vstupy

testovaný systém

výstupy

výstupy

tester

tester

výsledek testu

výsledek testu

Obr. 29: Princip testování RTOS

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 t0 a časovou značku první reakce systému t1 . Doba odezvy je pak rovna rozdílu t1 - t0 . Časové značky lze získat např. z obvodu reálného času (RTC -

5


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. 9.4.

5.4

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,

5


• • • • •

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 1003.1 až po 1238.1). 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, 1003.1b, 1003.1c) jsou nejvíce podporovány. POSIX 1003.1a definuje základní funkce operačního systému. Rozšíření reálného času jsou definovány standardy 1003.1b, 1003.1d, 1003.1j a 1003.21. POSIX 1003.13 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í.

6

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

6

46


Ř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. 3.3.4. 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. reset

watchdog

procesor

restart hodiny

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é

6


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. 3.1. 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.

6

48


6.4

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

úloha č. n WDT

SW watchdog

reset

HW watchdog

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. 9.6. 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 HWWDT 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

6


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.

7

50

Model diagnostického podsystému

7


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

7

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řĳí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. << process >> Producer −good :int << run >> + produce ():void

− prodBuf

<< process >> Consumer

Buffer −contents :int −empty :boolean = true + get ():int + put (val:int ):void

− consBuf

−good :int << 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č-

7

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

7

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

7

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

konzumuj

produkuj

konzument

1

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)

7

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

7

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

<< process , Thread >> Consumer (from PSM)

Buffer (from PSM) − prodBuf

−contents :int −empty :boolean = true + get ():int + put (val:int ):void

− consBuf << 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.

7

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. 3.3. 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 >>

− prodBuf

<< create >> + Producer (m :int ,buf :Buffer ):Producer + run ():void

<< use >>

Buffer

Producer −n:int

<< use >>

Consumer

−contents :int −empty :boolean = true + put (i:int ):void + get ():int

−n:int − consBuf

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

8

Vývojová platforma pro diagnostický podsystém

8

58


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

8

59


• limitovaná hmotnost a příkon elektronického vybavení, • přĳatelná cena a dostupnost použité součástkové základny. Motorický podsystém

Inerciální navigační soustava

Pohonové elektromotory

GPS Výškoměr

Autopilot

Řízení servopohonů Diagnostický podsystém Řídicí podsystém Komunikační podsystém

Palubní síť

Řízení sběrnice CAN

Záznamník letových dat

Aplikační SW & HW

Aplikační sběrnice

Kompas

Sběrnice řízení - CAN-BUS

Senzorický podsystém

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.

8


8.2

60

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.

8


8.2.1

61

Ří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. 8.2.2

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

8


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). 8.2.3

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í.

8


8.3

63

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

9

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

9


64

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é

9


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].

CAN0

ovládání a monitorování řídicích jednotek

Dohledové centrum

ETH0

UART0

VGA

KEYB

LPT1

SDRAM 128 MB

CAN1

CAN0

sběrnice CAN 1 Mb/s

sběrnice CAN 1 Mb/s

SJA - 1000

SJA - 1000

Modul sběrnice CAN PCM-3680

CFC 128 MB

AMD ÉlanSC520 133 MHz

5V/1A

Procesorový modul PC/104 -- MSM586SEV

ETH0

Centrální řídicí jednotka I.

sběrnice PC/104

VGA

KEYB

LPT1

SDRAM 128 MB

CAN0

SJA - 1000

CAN1

SJA - 1000

Modul sběrnice CAN PCM-3680

CFC 128 MB

AMD ÉlanSC520 133 MHz

5V/1A

Procesorový modul PC/104 -- MSM586SEV

ETH0

Centrální řídicí jednotka II.

Obr. 46: Bloková struktura výpočetního systému postaveného na modulech PC/104

115200,N,8,1 RTS/CTS

UART0 UART1

UART0 UART1

Ethernet 10/100 Mb/s

sběrnice PC/104

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

66

9


9.2

67

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).

9


9.3

68

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řĳímač GPS a elektronický kompas byly umístěny vně draku UAV. Mechanické uchycení jednotlivých částí bylo provedeno šrouby do draku UAV přes tlumící gumovou podložku nahrazující silentbloky. GPS 16A gyroskop elektronický kompas

PC/104

Obr. 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 2.4.21, – RTAI verze 24.1.12, – BusyBox verze 0.60.5, • 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-

69

38400,N,8,1

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

SDRAM 128 MB

CFC 256 MB

UART2

GPS 16A 8V / 100mA

9600,N,8,1 RTS/CTS

19200,N,8,1

UART3

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

UART0


UART1

9

19200,N,8,1

elektronický kompas HMR 3300 8V / 24mA

gyroskop 8V / 200mA

5V/1A

aktivní chlazení NiMH baterie 8 článků SANYO - 3000 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řĳímače Získaný záznam datových vět ve formátu NMEA z GPS přĳímače byl předzpracován a byly vyloučeny neplatné záznamy (fáze kdy GPS přĳímač nebyl zasynchronizovaný). Následně byla data zobrazena programem GnuPlot. Na obr. 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řĳímače to znamená věnovat patřičnou pozornost naměřeným hodnotám, které budou použity k samotnému řízení UAV. UAV - Flight Level (Přerov 15-7-2004) 180 Flight Level

160

140

Flight Level [m]

120

100

80

60

40

20

0 12:02:30

12:03:00

12:03:30

12:04:00

12:04:30

12:05:00

12:05:30

Universal Time (UTC) [h]

Obr. 49: Průběh dosažené výšky zaznamenaný z GPS přĳímače

9

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 15-7-2004) Flight Level

Flight Level [m] 180 160 200

140 120

150

100 80

100

60 40

50

20

landing

0 0

launching

1723.6

1723.5

1723.4

1723.3

Longtitude

1723.2

1723.1

1723

4925.55 4925.5 4925.45 4925.4 4925.35 4925.3 Latitude 4925.25 4925.2 4925.15 1722.94925.1

Obr. 50: Průběh letu zaznamenaný z GPS přĳí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řĳí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.

9

71


9.4

Testování real-time vlastností OS Linux

Cílem experimentu bylo ověřit real-time vlastnosti OS Linux bez a se zapnutou podporou pro real-time aplikace. Testy byly prováděny na procesorovém modulu PCM-3350 s linuxovém jádrem 2.6.8 a real-time rozšířením RTAI 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 = 100000 (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 2005/04/18 09:01:35 2005/04/18 09:01:36

min: min: min:

-1676 -1676 -1676

max: max: max:

384686 386362 386362

average: average: average:

50829 44774 44633

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]: * latency: min: * latency: min: * latency: min:

timer setup=1676 ns, resched latency=2514 -98, max: 348, average: 17; fastjit: 164, -98, max: 348, average: 16; fastjit: 197, -98, max: 358, average: 17; fastjit: 197,

ns. slowjit: 27 slowjit: 27 slowjit: 27

9


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), SWITCH TIME (INCLUDING FULL FOR 30 TASKS: TIME 579 (ms), SWITCH TIME (INCLUDING FULL

SUSP/RES SWITCHES 120000, FP SUPPORT) 5215 (ns) SEM SIG/WAIT SWITCHES 120000, 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 paralelní port D0 (vývod 2)

číslicový osciloskop

kanál A 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

9


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

9


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 1 1 = = = 10 kHz T t0 + t1 50 µs + 50 µs

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

9


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ř. http://people.redhat.com/mingo/realtime-preempt). 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. 9.1. 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

9

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.

IP: 10.0.0.1/24

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

eth0

eth0

MASTER PC

RTnet

rozbočovač (HUB)

RTnet

RTnet eth0

IP: 10.0.0.3/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].

9


77

Obr. 57: Zachycená komunikace v síti RTnet Měření doby zpoždění 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 t0 na server, který paket přĳme a neprodleně odešle zpět klientovi. Po přĳmutí paketu klient vytvoří druhou časovou značku t1 a vypočte dobu zpoždění na síti podle následujícího vzorce round trip time = t1 − t0

klient

server

t0

t1

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.

9


78

Start of rt_client ***** May 4 2005 16:33:22 ***** local ip address =00000000 server ip address 10.0.0.1=0100000a interval = 500 packetsize = 58 start timer 0 Roundtrip = 6921us (min: 6921us, max: 6921us) Roundtrip = 6916us (min: 6916us, max: 6921us) Roundtrip = 6793us (min: 6793us, max: 6921us) Roundtrip = 6808us (min: 6793us, max: 6921us) Roundtrip = 6941us (min: 6793us, max: 6941us) Roundtrip = 6920us (min: 6793us, max: 6941us) Roundtrip = 6786us (min: 6786us, max: 6941us)

Změřená hodnota zpoždění v síti RTnet dosáhla 7 ms a lze ji vysvětlit následujícím způsobem. Pro paket s časovou značkou (58 B) bylo nutné přenést po Ethernetu celkem 84 B. Přenášený rámec tvořila preambule (7 B) + začátek rámce (1 B) + min. velikost ethernetového rámce (60 B) + CRC (4 B) + mezirámcová mezera (12 B) viz literatura [40] str. 38. Pro přenosovou rychlost 10 Mb/s, která byla dána max. rychlostí použitého rozbočovače, odpovídal přenos 84 B času 67,2 µs. Další zpoždění při přenosu na síti Ethernet představoval aktivní prvek (rozbočovač), přes který musel vyslaný rámec projít. Zbývající čas připadl na vyslání/příjem paketu operačním systémem a zpracování uživatelskou aplikací. V neposlední řadě svou roli hrála i velikost TDMA slotu, která byla nastavena na 5000 µs. Z výše uvedeného odstavce je zřejmé, že zpoždění v síti RTnet je ovlivněno celou řadou faktorů. Změnou konfigurace protokolu RTnet a použitého technického vybavení lze snížit dobu zpoždění v síti RTnet až na 65 µs [93]. Test diagnostické sběrnice založené na sběrnici CAN Procesorový modul MSM586SEV byl doplněn o modul PCM-3680, připojující řídicí jednotku na sběrnici CAN. Programové vybavení dostupné v rámci dodávky modulu PCM-3680 nebylo kompatibilní s operačním systémem Linux. Patřičná náhrada byla nalezena u projektu Linux/RTLinux CAN driver [72], jehož zdrojový kód byl během testu použit.

MASTER procesorový modul MSM586SEV CAN0

CAN1

SLAVE procesorový modul MSM586SEV CAN1

CAN0

Obr. 59: Zapojení pracoviště během testu diagnostické sběrnice s rozhraním CAN Pro testování diagnostické sběrnice s rozhraním CAN, bylo zapojeno měřicí pracoviště podle obr. 59. Konfigurace programového vybavení pro modul PCM-3680 byla provedena podle uživatelské dokumentace [72]. K ovládání rozhraní CAN slouží znaková zařízení /dev/can0 a /dev/can1.

9


79

Vysílání a příjem dat bylo úspěšně ověřeno pomocí testovacích programů rxtx, send, readburst a sendburst, které jsou součástí zdrojového kódu ovladače CAN. Tyto nástroje umožňují ovládání rozhraní CAN z příkazové řádky a lze je použít např. v dávkových souborech. K ovládání rozhraní CAN z aplikace poskytuje ovladač rozhraní (API), které je detailně popsané v programové dokumentaci. V rámci experimentu nebylo hlouběji testováno real-time chování ovladače. Ovladač byl primárně vyvinut pro OS Linux a jeho komerční real-time variantu RTLinux. V případě použití s RTAI rozšířením by bylo nutné provést modifikace zdrojového kódu, aby bylo možné dosáhnout hard real-time chování. Závěr k testování diagnostické sběrnice pro real-time systémy Během experimentu byly odzkoušeny dva typy rozhraní (Ethernet a CAN) zvažované pro jednoúčelovou diagnostickou sběrnici. Byly otestovány základní vlastnosti obou rozhraní a možnosti jak je programově ovládat. Z pohledu využití pro další vývoj diagnostického podsystému testy ověřily přenosové vlastnosti obou rozhraní. Nejednalo se však o testy, kde by bylo prováděno vysílání diagnostických zpráv a jejich vyhodnocování. Tato oblast zůstává otevřená a je předmětem dalšího vývoje. Každý typ rozhraní je vhodný pro jiný typ aplikací. Rozhraní sítě Ethernet se bude obtížně realizovat u malého jednočipového mikropočítače určeného pro průmyslové aplikace. Na druhou stranu výpočetní systém na bázi PC ve standardní konfiguraci bude jen těžko disponovat rozhraním CAN.

9.6

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

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

vyrovnávací paměť

producent

konzument

zapiš

čti

Obr. 60: Princip úlohy producent - konzument Demonstrační příklad je napsán v jazyce C a zdrojový kód je součástí přílohy D. Úloha je tvořena třemi vlákny (SW-WDT, producent a konzument), která sdílí společný datový prostor. K předávání dat mezi producentem a konzumentem slouží vyrovnávací paměť, kterou tvoří proměnná datového typu int (celé číslo). Vlákna využívají mechanizmů definovaných v rámci standardu POSIX 1003.1 [90] a jejich

9

80


implementace pro operační systém Linux. Obr. 61 zachycuje stavový diagram úlohy producent - konzument, doplněné o inteligentní diagnostický časovač.

producent - konzument update WDT

start

SW-WDT porucha

start

produkuj

producent

start

konzumuj

konzument

porucha

porucha

Obr. 61: Stavový diagram úlohy producent - konzument Úloha je spuštěna v nekonečné smyčce a na kooperativní bázi dochází v kruhu k přepínání mezi jednotlivými vlákny (viz obr. 62). Vlákno SW-WDT po spuštění provede inicializaci HW-WDT, reprezentované zařízením /dev/watchdog. Průběžně pak provádí kontrolu ostatních vláken a nulování HW-WDT.

SW-WDT

11111 00000 00000 11111 00000 11111

producent

11111 00000 00000 11111 00000 11111

konzument čas

Obr. 62: Přepínání vláken v úloze producent - konzument Každé vlákno disponuje vlastním čítačem aktivity, který se v definovaném bodě inkrementuje pokaždé, když vlákno dostane přidělený procesor. Vlákno SW-WDT provádí porovnání hodnoty svého čítače s hodnotami vláken producenta a konzumenta. V případě, že se hodnota některého z čítačů neshoduje s hodnotou čítače SW-WDT, je detekována porucha. Dojde-li k selhání obou vláken producenta a konzumenta, přestane SW-WDT nulovat HW-WDT a systém bude znovu zaveden. Program provádí pouze detekci poruchy jednotlivých vláken a nesnaží se o žádné maskování poruch či případnou obnovu po poruše. Ovládání programu je pomocí parametrů z příkazové řádky, kde lze definovat počet cyklů, po kterých dojde k výskytu poruchy ve vlákně producenta (přepínač -p) nebo konzumenta (přepínač -c). Porucha vlákna se projeví jeho ukončením. Následující výstup z terminálu dokumentuje chování programu.

9


81

# ./wdt -p4 -c2 HW-WDT enabled. SW-WDT thread is up. Producer thread is up. Consumer thread is up. SW - WDT - wdt flag sw 0 | prod 0 | cons 0 - HW-WDT cleared Producer - wdt flag 1 - buffer - 1 Consumer - wdt flag 1 - buffer - 1 SW - WDT - wdt flag sw 1 | prod 1 | cons 1 - HW-WDT cleared Producer - wdt flag 2 - buffer - 2 Consumer - wdt flag 2 - buffer - 2 SW - WDT - wdt flag sw 2 | prod 2 | cons 2 - HW-WDT cleared Producer - wdt flag 3 - buffer - 3 SW - WDT - wdt flag sw 3 | prod 3 | cons 2 - HW-WDT cleared Consumer failure detected! Producer - wdt flag 4 - buffer - 4 SW - WDT - wdt flag sw 4 | prod 4 | cons 2 - HW-WDT cleared Consumer failure detected! SW - WDT - wdt flag sw 5 | prod 4 | cons 2 - HW-WDT cleared Producer failure detected! Consumer failure detected! Program failure detected! Waiting for HW-WDT reboot!

Položka wdt flag zobrazuje stav hodnoty čítače aktivity jednotlivých vláken. Obsah vyrovnávací paměti je zobrazen v položce buffer. Z výstupu programu je vidět, že vlákno konzumenta bylo po dvou opakováních ukončeno. Následně SW-WDT detekoval poruchu vlákna konzumenta. Vlákno producenta bylo ukončeno po čtyřech opakováních. SW-WDT detekoval poruchu obou kontrolovaných vláken a pomocí HW-WDT byl opětovně spuštěn systém. Závěr k testování inteligentního diagnostického časovače Provedený experiment ověřil koncept inteligentního diagnostického časovače navrženého v kapitole 6.4. Demonstrační úloha producent - konzument, představuje jednu ze základních úloh, se kterými se lze setkat ve víceúlohových systémech pracujících v reálném čase. Chování systému bylo z pohledu výskytu poruch částečně idealizované. Jednalo se zejména o stav, kdy došlo k výskytu poruchy, které vedlo k definovanému ukončení vlákna. V praxi však může nastat stav, kdy dojde k zacyklení uvnitř vlákna a zablokování přepínání na ostatní vlákna. Demonstrační příklad tuto situaci řeší pomocí HW-WDT, který by v tomto případě opětovně spustil systém. Jestliže má být systém schopen maskování poruchy či případné obnovy po poruše, musí disponovat prostředky, jak procesu (vláknu) nedobrovolně odebrat procesor. Proces kterému by byl následně přidělen procesor, by provedl pokus o ukončení blokujícího procesu a jeho opětovné spuštění, popř. přepnutí na záložní proces.

10

Výsledky disertační práce s uvedením nových poznatků

82

10 Výsledky disertační práce s uvedením nových poznatků Řešené téma disertační práce, popsané v předchozím textu, je relativně obsáhlé. Cílem bylo zvolit koncepci disertační práce, která by obsahovala jak řešení teoretického problému, tak i možnost reálného experimentu. Ověření poznatků získaných z experimentů mělo potvrdit či vyvrátit očekávané výsledky a přínosy disertační práce.

10.1


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

10.2


V kapitole 7 a 9.6 byl vytvořen model části diagnostického podsystému, který pomocí diagnostického časovače umožňuje provádět průběžnou diagnostiku programového vybavení. Zvolená úloha producent - konzument představuje klasický příklad řešení problému synchronizace mezi dvěma procesy a demonstruje typickou úlohu v řídicích systémech pracujících v reálném čase.

10


83

Popis modelu diagnostické úlohy byl proveden v jazyce UML. Použitá metoda MDA umožňuje transformovat vstupní platformově nezávislý model na platformově specifický model. Cílová platforma operačního systému reálného času byla popsána modelem platformy. Transformace modelu byla provedena v jazyce MTL. Výstupem transformace byl platformově specifický model, který byl použit jako vstup pro generátor zdrojového kódu. Generování zdrojového kódu bylo provedeno metodou přímé transformace modelu (forward engineering) a metodou obousměrného vývoje (roundtrip engineering). Zdrojový kód získaný přímou transformací modelu se sestával z převedeného diagramu 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. Metoda obousměrného vývoje díky zásahu programátora umožnila vytvoření plnohodnotného zdrojového kódu, který bylo možné použít k sestavení finální aplikace. Použití metody MDA umožnilo vytvořit popis programového vybavení pomocí UML modelů. Výsledkem postupné transformace jednotlivých modelů byl zdrojový kód aplikace. Škálovatelnost metody MDA v kombinaci s MTL jazykem zatím neumožňuje řešení problémů pro větší programové celky, jako je např. jádro operačního systému. Metoda MDA je založena na jazyce UML, který využívá objektového přístupu k popisu struktury systému. Výsledný zdrojový kód, který vznikne transformací modelů, je objektově orientovaný (Ada, Java, C++, C#). Ne vždy jsou však tyto jazyky vhodné k sestavení aplikací pracujících v reálném čase s omezenými paměťovými a výpočetními zdroji (např. jazyk Java a správa paměti pomocí garbage collectoru).

10.3


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

10


10.4

84


Kapitola 9 shrnuje provedené experimenty během řešení disertační práce. Cílem experimentů bylo praktické ověření teoreticky navržených postupů s operačním systémem Linux, doplněném o podporu reálného času. Experimenty byly prováděny jak v laboratorních podmínkách, tak i prakticky během letových zkoušek s UAV. První experiment byl proveden na letišti v Přerově, kde byl výpočetní systém zabudován do draku UAV a bylo provedeno několik pilotovaných letů. Získaná data z měření byla postoupena k dalšímu zpracování, aby bylo možné určit základní letové charakteristiky UAV. Navazující plánované experimenty s UAV nebylo možno uskutečnit z důvodu komplikované situace kolem podpory projektu obranného výzkumu Záznam II. Z tohoto důvodu byly další experimenty provedeny pouze v laboratorních podmínkách. Druhý experiment byl zaměřen na ověření real-time vlastností OS Linux bez a se zapnutou podporou pro real-time aplikace. Byly demonstrovány základní vlastnosti jádra OS Linux. Standardní jádro nedisponuje příliš dobrými real-time vlastnostmi a odezva systému se pohybuje v řádech ms. Dobu odezvy linuxového jádra lze snížit speciální úpravou plánovače úloh. Pro úlohy, které však vyžadují splnění hard realtime podmínek, je nezbytné použít RTAI rozšíření, které garantuje odezvy v řádech desítek µs. Třetí experiment byl zaměřen na ověření koncepce diagnostické sběrnice pro systémy pracující v reálném čase. Diagnostická sběrnice byla realizovaná pomocí sítě Ethernet s přenosovou rychlostí 10/100 Mb/s a sběrnicí CAN s přenosovou rychlostí 1 Mb/s. Každá z těchto sběrnic se vyznačuje jinými vlastnostmi. Síť Ethernet byla navržena pro počítačové sítě a nedisponuje metodami pro inteligentní řízení přístupu ke sdílenému komunikačnímu médiu. Pokud na síti Ethernet chceme dosáhnout definované doby odezvy, je nutné toto provést programově. Jednou z metod jak toho docílit je použití metody TDMA, kterou využívá i protokol RTnet, který byl použit pro vytvoření diagnostické sběrnice v síti Ethernet. Na druhou stranu sběrnice CAN byla od počátku navržena pro průmyslové použití. Řešení přístupu na společnou sběrnici, priority zpráv atd. je nedílnou součástí mechanizmů, kterými sběrnice CAN disponuje. Provedené experimenty ukázaly, že v závislosti na použitém technickém vybavení lze pro diagnostickou sběrnici použít jak sítě Ethernet, tak i sběrnice CAN. Je však nutné patřičně zohlednit faktory jako je topologie diagnostické sběrnice, vzdálenost jednotlivých uzlů, zdroje rušení atd. Čtvrtý experiment byl zaměřen na ověření inteligentního diagnostického časovače pro sledování chování programového vybavení. Úloha producent - konzument byla doplněna o inteligentní diagnostický časovač. Úlohu tvořily tři vlákna (SW-WDT, producent a konzument). Stav jednotlivých vláken byl sledován pomocí čítačů aktivity. V případě výskytu byla porucha detekována a zobrazena na terminálu. Při úplném selhání úlohy, byl systém znovu zaveden pomocí HW-WDT. Vytvořená úloha neprováděla maskování poruch nebo obnovu po poruše. Použitá diagnostická metoda nikterak nenarušila real-time chování celého systému. Tento čtvrtý experiment zároveň sloužil k porovnání metody MDA s ručně vytvořeným zdrojovým kódem. Úvodní fáze (zadání, analýza a návrh) jsou v obou případech shodné. Rozdíly se však projevují ve fázi implementace. Metoda MDA

10


85

se snaží o postupný převod jednotlivých modelů (jejich upřesňování). Naproti tomu ručně vytvořený zdrojový kód je od prvopočátku pevně spjat s cílovou platformou. V případě vestavných systémů pracujících v reálném čase existuje celá řada faktorů, které je třeba zohlednit u modelů nezbytných pro MDA metodu. V případě, že má proces transformace proběhnout plně automatizovaně, je třeba vytvořit detailní popisy jednotlivých modelů a transformací. Mnohdy jsou však tyto popisy natolik složité, že je u nich vysoká pravděpodobnost vzniku skrytých chyb. Zatím neexistují nástroje, které by byly schopné odhalit tento druh chyb.

11 Konkrétní závěry pro využití výsledků práce v praxi a pro rozvoj vědního oboru 86

11

Konkrétní závěry pro využití výsledků práce v praxi a pro rozvoj vědního oboru

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

12

12

Závěr

87

Závěr

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

Přílohy

A

A

Seznam použité literatury

89

Seznam použité literatury

[1] A. Avizienis. The Methodology of N-Version Programming, 1995. URL: . [2] Advantech Co. PCM–3680 Dual-port Isolated CAN interface Module. [online], poslední revize 2004–04–19 [cit. 2004–04–19]. URL: . [3] Aeolean Inc. Introduction to Linux for Real–Time Control. [online], poslední revize 2002–12–11 [cit. 2004–11–25]. URL: . [4] Advanced Micro Devices, Inc. ÉlanSC520 Microcontroller. [online], poslední revize 2004–11–28 [cit. 2004–11–28]. URL: . [5] Andersson, M.; Lindskov, J. Running real-time Linux on the Axis ETRAX system-on-chip. [online], poslední revize 2003–03–09 [cit. 2004–11–28]. URL: . [6] Armada. Complete Guide to Drones and Sensors. Armada International, 2001. Vol. 25, No. 5, ISSN: 0252-9793. [7] Armada. The Growing World of Unmanned Airborne Spies. Armada International, 2004. Vol. 28, No. 3, ISSN: 0252-9793. [8] Armada. From Scepticism to Sine Qua Non. Armada International, 2005. Vol. 29, No. 3, ISSN: 0252-9793. [9] Barton, M. Fuzz Testing of Application Reliability. [online], poslední revize 2002–06–19 [cit. 2005–01–25]. URL: . [10] Barr, M. Choosing an RTOS. [online], poslední revize 2002–12-12 [cit. 2005– 01–25]. URL: . [11] Bihler, E.; Vermeire, B.; Goodman, D. Lebensdauer–Monitoring auf dem Chip. [online], poslední revize 2004 [cit. 2004–12–15]. URL: . [12] Braun, D., Glenn. Available source code can work wonders, but watch out. [online], last revision 2003–09–01 [cit. 2006–03–14]. URL: . [13] Brown, A. An introduction to Model Driven Architecture. [online], last revision 2004–02–17 [cit. 2006–06–14]. URL: .

90 [14] Bureš, Z.; Čeleda, P.; Hrdlička, I.; Křivánek, V.; Mořkovský, T. Diagnostická ústředna – automatizovaný systém sběru dat u bezpilotního prostředku. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004. [15] BusyBox Team. BusyBox - The Swiss Army Knife of Embedded Linux. [online], poslední revize 2007–01–25 [cit. 2007–01–25]. URL: . [16] Čeleda, P.; Koníř, T. Spolehlivost open-source programového vybavení. Sborník technické diagnostiky – DIAGON 2005, s. 117 – 121. UTB Zlín, 2005. ISBN 80–7318–293–9. [17] Čeleda, P. Bezpečné programování - prevence vzniku bezpečnostních chyb v programech. Sborník konference – SVŘ5. VA Brno, 2004. [18] Čeleda, P. Zvýšení spolehlivosti operačních systémů pracujících v reálném čase. Závěrečná zpráva o řešení projektu VGA, Univerzita obrany, 2004. [19] Cernosek, G.; Naiburg, E. The Value of Modeling. [online], last revision 2004– 10–29 [cit. 2006–06–14]. URL: . [20] Claesson, V. Efficient and Reliable Communication in Distributed Embedded Systems. [online], poslední revize 2002–12 [cit. 2006–10–24]. URL: . [21] Cox, A. Watchdog Timer Interfaces For The Linux Operating System. The Linux Kernel Archives. URL: . [22] DIGITAL–LOGIC AG. MSM586SEN/SEV/SL – datasheet. [online], poslední revize 2004–10–27 [cit. 2004–10–27]. URL: . [23] Eclipse Foundation. Eclipse - an open development platform. [online], poslední revize 2007–01-14 [cit. 2007–01–19]. URL: . [24] FAUmachine Team. FAUmachine Project. [online], poslední revize 2004–12– 15 [cit. 2005–01–25]. URL: . [25] Faught, D. Unit Test Tools. [online], poslední revize 2005–01–14 [cit. 2005–01– 20]. URL: . [26] Free Software Foundation, Inc. GNU C Library. [online], poslední revize 2006– 12–06 [cit. 2007–01–25]. URL: . [27] Finite State Machine Labs. FSMLabs – The RTLinux Company. [online], poslední revize 2004–11–28 [cit. 2004–11–28]. URL: . [28] Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1995. ISBN 0–2016–3361–2.

91 [29] Ganssle, J. Disaster! [online], poslední revize 1998–05 [cit. 2004–11–28]. URL: . [30] Ganssle, J. Disaster redux! [online], poslední revize 2004–09–12 [cit. 2004–11– 28]. URL: . [31] Gentleware Inc. Poseidon for UML. [online], poslední revize 2007–01–19 [cit. 2007–01–19]. URL: . [32] Gimpel Software. PC-lint and FlexeLint. [online], poslední revize 2003 [cit. 2005–01–25]. URL: . [33] GCC team. GNU Compiler Collection. [online], poslední revize 2004–11–26 [cit. 2004–11–28]. URL: . [34] Harel,D.; Politi, M. Modeling Reactive Systems With Statecharts : The Statemate Approach. McGraw-Hill Companies, 1998. ISBN 0–07–026205–5. [35] Heesch, D. Doxygen. [online], poslední revize 2005–01–29 [cit. 2005–01–30]. URL: . [36] Hlavička, J.; Kotek, E.; Zelený, J. Diagnostika elektronických číslicových obvodů. SNTL, 1982. ISBN 04–538–82. [37] Hlavička, J.; Racek, S.; Golan, P.; Blažek, T. Číslicové systémy odolné proti poruchám. ČVUT, 1992. ISBN 80–01–00852–5. [38] Holub, R.; Vintr, Z. Spolehlivost letadlové techniky. VUT Brno, 2001. [online], poslední revize 2001 [cit. 2004–12–07] URL: . [39] IBM. Terrestrial cosmic rays and soft errors. IBM Journal of Research and Development, 1996. Vol. 40, No. 1. [40] IEEE, Inc. IEEE Std 802.3-2002 - Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications. IEEE, 2002. ISBN 0–7381–3089–3. [41] Institute of Electrical and Electronic Engineers. IEEE Standard Test Access Port and Boundary Scan Architecture. IEEE Std 1149.1-2001, 2001. [42] Jaluna SA. Jaluna/Linux RT. [online], poslední revize 2004–11–15 [cit. 2005–01–25]. URL: . [43] Janoušek, I.; Kozák, J.; Taraba, O. Technická diagnostika. SNTL Praha, 1988. [44] Jeffries, R. XProgramming.com an Extreme Programming Resource. [online], poslední revize 2005–01–16 [cit. 2005–01–25]. URL: .

92 [45] Michael B. Jones. What really happened on Mars? [online], last revision 1997– 12–16 [cit. 2006–06–14]. URL: . [46] Jürjens, J. Playing the Devil’s Advocate - Testing Real-Time Systems. [online], poslední revize 2006–12–18 [cit. 2006–12–18]. URL: . [47] Kačmář, D. Operační systémy reálného času. Softwarové noviny, 2003. [48] Kašpárek, T. Seriál Co před námi tají /proc. [online], poslední revize 2001–11–8 [cit. 2006–12–7]. URL: . [49] Kleppe, A.; Warmer, J.; Bast, W. MDA explained: the model driven architecture: practice and promise. Pearson Education, Inc., 2003. ISBN 0–321– 19442–X. [50] Koopman, P. The Ballista Project: COTS Software Robustness Testing. [online], poslední revize 2004 [cit. 2005–01–25]. URL: . [51] Laurich, P. A comparison of hard real-time Linux alternatives. [online], poslední revize 2003–11–19 [cit. 2004–11–28]. URL: . [52] LinuxDevices. Snapshot of the Embedded Linux market. [online], poslední revize 2004–03–12 [cit. 2004–11–28]. URL: . [53] Majzik, I. Concurrent Error Detection Using Watchdog Processors. [online], poslední revize 1996–10–29 [cit. 2006–06–17]. URL: . [54] Malák, F. OS Linux RTAI pro řízení autonomního mobilního prostředku. Diplomová práce, Univerzita obrany, 2005. [55] Mandrakesoft. Mandrakesoft to Participate in Development of Highly Secure Open Operating System Solution. [online], poslední revize 2004–09–23 [cit. 2005–01–25]. URL: . [56] Mařík, V. Trendy v komplexní automatizaci. [online], poslední revize 2000– 07 [cit. 2006–10–24]. URL: . [57] Melanson, P.; Tafazoli, S. A Selection Methodology for the RTOS Market. [online], poslední revize 2003–06–04 [cit. 2004–11–28]. URL: .

93 [58] MIMOSA. Machinery Information Management Open Systems Alliance. [online], poslední revize 2004–10–5 [cit. 2005–01–25]. URL: . [59] NASA. The NASA ASIC Guide. [online], poslední revize 1993 [cit. 2006–06–11]. URL: . [60] NIAP CCEVS. EAL – Validated Products List. [online], poslední revize 2005– 01–11 [cit. 2005–01–25]. URL: . [61] Nielsen, B. Specification and Test of Real-Time Systems. PhD Thesis, 2000, ISSN 1399-8145. [62] Nikora, A.; Some, R.; Tamir, Y. Increasing Software Testability with Standard Access and Control Interfaces. ISSRE 2003 Fast Abstracts, 2003. [63] Obenland, K. POSIX in Real-Time. [online], poslední revize 2001 [cit. 2006– 12–27]. URL: . [64] OCERA Project. RTOS state of the art analysis. [online], poslední revize 2002–11–15 [cit. 2005–01–25]. URL: . [65] Object Management Group. OMG Model Driven Architecture. [online], poslední revize 2005–01–19 [cit. 2005–01–25]. URL: . [66] Object Management Group. Object Constraint Language. [online], poslední revize 2006–05–01 [cit. 2007–01–25]. URL: . [67] Object Management Group. UML Resource Page. [online], poslední revize 2005–01–19 [cit. 2005–01–25]. URL: . [68] The Open Group. The Single UNIX Specification, Version 3. [online], poslední revize 2002–01–27 [cit. 2004–11–28]. URL: . [69] Patton, R. Testování software. Computer Press, 2002. ISBN 80–7226–636–5. [70] Peterka, J. Řízení přístupu. [online], poslední revize 2006–12 [cit. 2006–12–7]. URL: . [71] Pinker, J. Mikroprocesory a mikropočítače. BEN, 2004. ISBN 80–7300–110–1. [72] Píša, P. Linux/RT-Linux CAN driver and CANopen framework. [online], poslední revize 2004–11–28 [cit. 2004–11–28]. URL: . [73] Polsterová, H. Spolehlivost v elektrotechnice. VUT FEKT Brno, 2003. [74] Přenosil, V.; Bureš, Z.; Čeleda, P.; Křivánek, V.; Rozehnal, D. Konfigurace mobilního retranslátoru. Závěrečná zpráva projektu obranného výzkumu ZÁZNAM II, Univerzita obrany, Masarykova univerzita v Brně, 2005.

94 [75] RTAI team. RTAI – Real-Time Application Interface. [online], poslední revize 2004–11–28 [cit. 2004–11–28]. URL: . [76] RTnet. RTnet - Hard Real-Time Networking for Real-Time Linux. [online], poslední revize 2006 [cit. 2006–12–27]. URL: . [77] RTS group. The Scalable Processing Box (SPB) and LiRE. [online], poslední revize 2004–11–26 [cit. 2004–11–28]. URL: . [78] Samek, M. Practical Statecharts in C/C++ : Quantum Programming for Embedded Systems. CMP Books, 2002. ISBN 1–57820–110–1. [79] SPLINT group. Splint - Secure Programming Lint. [online], poslední revize 2004–02–17 [cit. 2005–01–25]. URL: . [80] Stodola, J. Diagnostika motorových vozidel. VUT Brno, 2003. [online], poslední revize 2003–11–03 [cit. 2004–12–07] URL: . [81] Sun Microsystems. Javadoc. [online], poslední revize 2004 [cit. 2005–01–30]. URL: . [82] Texas Instruments. IEEE Std 1149.1 (JTAG) Testability. [online], poslední revize 2003–02–17 [cit. 2005–01–25]. URL: . [83] Timmerman, M. RTOS Market Overview. [online], poslední revize 1999–02 [cit. 2004–11–28]. URL: <www.omimo.be/magazine/99q2/RTOSmarketoverview. pdf>. [84] Triskell Team. Kermeta language. [online], poslední revize 2007–02–14 [cit. 2007–02–19]. URL: . [85] Triskell Team. MTL - Model Transformation Language. [online], poslední revize 2005–08–05 [cit. 2007–01–19]. URL: . [86] Vojtisek, D.; Jézéquel, J. MTL and Umlaut NG: Engine and Framework for Model Transformation. [online], poslední revize 2004–07 [cit. 2007–01–19]. URL: . [87] Wikipedia. Case-based reasoning. [online], poslední revize 2006–10–24 [cit. 2006–10–24]. URL: . [88] Wikipedia. Eiffel programming language. [online], poslední revize 2007– 01–19 [cit. 2007–01–28]. URL: . [89] Wikipedia. NetFlow. [online], poslední revize 2006–12–18 [cit. 2006–12–18]. URL: .

95 [90] Wikipedia. POSIX Threads. [online], poslední revize 2006–12–19 [cit. 2006–12– 28]. URL: . [91] Wikipedia. Decision tree. [online], poslední revize 2006–10–24 [cit. 2006–10–24]. URL: . [92] Yaghmour, K. Building Embedded Linux Systems. O’Reilly, 2003. ISBN 0–596– 00222–X. [93] Yaghmour, K. Having fun with RTNet. [online], poslední revize 2000–09–18 [cit. 2006–12–27]. URL: . [94] OSI. Open Source Initiative (OSI) homepage. [online], last revision 2006–06–01 [cit. 2006–06–14]. URL: .

B


B B.1

Generování zdrojového kódu Zápis UML modelu v jazyce XML

50

< XMI xmi . version = ’ 1.2 ’ xmlns : UML = ’ org . omg . xmi . namespace . UML ’ timestamp = ’ Fri Jun 16 15:02:48 CEST 2006 ’ > < XMI . header > < XMI . documentation > < XMI . exporter > Netbeans XMI Writer < XMI . exporterVersion >1.0 < XMI . content > ... ... ... < UML : Class xmi . id = ’ a13 ’ name = ’ Consumer ’ visibility = ’ public ’ i s S pe c i f i c a ti o n = ’ false ’ isRoot = ’ false ’ isLeaf = ’ false ’ isAbstract = ’ false ’ isActive = ’ false ’ > < UML : ModelElement . stereotype > < UML : Stereotype xmi . idref = ’ a4 ’/ > < UML : Classifier . feature > < UML : Operation xmi . id = ’ a14 ’ name = ’ consume ’ visibility = ’ public ’ i s S pe c i f i c a ti o n = ’ false ’ ownerScope = ’ instance ’ isQuery = ’ false ’ concurrency = ’ sequential ’ isRoot = ’ false ’ isLeaf = ’ false ’ isAbstract = ’ false ’ > < UML : ModelElement . stereotype > < UML : Stereotype xmi . idref = ’ a6 ’/ > < UML : B e h a v i o r a l F e a t u r e . parameter > < UML : Parameter xmi . id = ’ a15 ’ name = ’ return ’ i s S p ec i f i c a ti o n = ’ false ’ kind = ’ return ’ > < UML : Parameter . type > < UML : DataType xmi . idref = ’ a8 ’/ > < UML : Method xmi . id = ’ a16 ’ i s S p e c i fi c a t i o n = ’ false ’ isQuery = ’ false ’ > < UML : Method . body > < UML : P r o c e d u r e E x p r e s s i o n xmi . id = ’ a17 ’ language = ’ java ’ body = ’ ’/ > < UML : Method . specification > < UML : Operation xmi . idref = ’ a14 ’/ > ... ... ...

51

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

96

B

B.2 1 2 3 4 5 6 7

97


/* * * * * * */

Zdrojové kódy transformace modelu v jazyce MTL File Library Version Author Date

: : : : :

C o n s u m e r P r o d u c e r . mtl ConsumerProducer 1.0 Pavel Celeda June 16 , 2006 1 0 : 4 3 : 3 0 AM CEST

8 9

library C o n s u m e r P r o d u c e r ;

10 11 12 13

main () : Standard :: Void { metamodelFilename , inputFilename , o ut put Fi le nam e : Standard :: String ;

14

ProdConsTrans : Imp or tU mlM od el ;

15 16

ProdConsTrans := new I mpo rt Um lMo de l ();

17 18

’ *** program launched *** ’. toOut ();

19 20

/* define input , output and m e t a m o d e l f i l e n a m e s */ m e t a m o d e l F i l e n a m e := ’ ../ metamodels / Uml1 .4 _Metamodel . xmi ’; inputFilename := ’ ./ models / prodCons . xmi ’; ou tp ut Fil en ame := ’ ./ models / p r o d C o n s _ u p d a t e d . xmi ’;

21 22 23 24 25

ProdConsTrans . init ( metamodelFilename , inputFilename , o ut put Fi le nam e ); ProdConsTrans . c o n n e c t S o u r c e M o d e l (); ProdConsTrans . M o d e lP I M m a p pi n g ();

26 27 28 29

’ *** program finished *** ’. toOut ();

30 31

1 2 3 4 5 6 7

} /* * * * * * */

File Library Version Author Date

: : : : :

I m p o r t U m l M o d e l . mtl ConsumerProducer 1.0 Pavel Celeda June 16 , 2006 1 0 : 4 9 : 4 0 AM CEST

8 9

library C o n s u m e r P r o d u c e r ;

10 11

model source_model : R ep o s i t o ry M o d e l ;

/* r e p o s i t o r y model */

12 13 14 15 16

class Im por tU mlM od el { /* F i l e n a m e s */ metamodelFilename , inputFilename , o ut put Fi le nam e : Standard :: String ;

17 18 19 20

umlEntryPoint : source_model :: M o d e l _ M a n a g e m e n t :: Package ; pkgPSM , pkgPIM , pkgPDM : source_model :: M o d e l _ M a n a g e m e n t :: Package ; pkgMapping , pkgJava , pkgOut : source_model :: M o d e l _ M a n a g e m e n t :: Package ;

21 22 23 24 25 26 27 28 29 30

/* * Constructor */ init ( m e t a m o d e l F i l e n a m e : Standard :: String ; inputFilename : Standard :: String ; ou tp ut Fil en ame : Standard :: String ) { this . m e t a m o d e l F i l e n a m e := m e t a m o d e l F i l e n a m e ; this . inputFilename := inputFilename ; this . ou tpu tF il ena me := ou tp utF il ena me ; }

31 32 33 34 35 36 37 38

/* * Connect to the model */ c o n n e c t S o u r c e M o d e l () { /* local v a r i a b l e s */ mdrdriver : MDRDriver :: MD R M o d e l Ma n a g e r ;

B

98


39

/* we i n i t i a l i z e the MDR driver */ mdrdriver := new MDRDriver :: M D R M od e l M a n a ge r (); mdrdriver . init ();

40 41 42 43

/* i n s t a n c i a t e the model , save result in another file */ source_model := mdrdriver . g et M o d e l Fr o m X M I ( metamodelFilename , ’ UML ’ , /* name of the root package in the Uml1 .4 m e t a m o d e l */ ’ UML1 .4 _model ’ , /* name of the new model in the r e p o s i t o r y */ inputFilename , ou tp ut Fil en ame );

44 45 46 47 48 49 50 51

}

52 53 54 55 56 57 58 59

/* * Return a set of all d e c l a r e d entry points for uml14 model . */ g e t E n t r y P o i n t s I n U m l 1 4 S o u r c e M o d e l () : Standard :: Set { return ! source_model :: M o d e l _ M a n a g e m e n t :: Model !. allInstances (); }

60 61 62 63 64 65 66 67 68 69 70 71 72

/* We are looking for a simple entry point of Uml14 model * as there is usually only one Package of type Model in a uml14 model * if not , one should use g e t E n t r y P o i n t s I n U m l 1 4 S o u r c e M o d e l () * return the first element of this Set */ g e t E n t r y P o i n t I n U m l 1 4 S o u r c e M o d e l () : source_model :: M o d e l _ M a n a g e m e n t :: Package { modelIterator : Standard :: Iterator ; modelIterator := g e t E n t r y P o i n t s I n U m l 1 4 S o u r c e M o d e l (). ge tN ewI te ra tor (); return modelIterator . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); }

73 74 75 76 77 78 79

/* * Get p a c k a g e s from model . */ g e t M o d e l P a c k a g e s () { p a c ka g e I t e r at o r : Standard :: Iterator ;

80 81 82

p a c ka g e I t e r at o r := umlEntryPoint . ownedElement . ge tN ewI te ra tor (); ’ Found packages : ’. toOut ();

83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

while p a c k ag e I t e r at o r . isOn () { if ( p a c k a ge I t e r a t or . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name pkgPSM := pa c k a g e I te r a t o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgPSM . name . toOut (); } elseif ( p a c k ag e I t e r at o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name pkgPIM := pa c k a g e I te r a t o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgPIM . name . toOut (); } elseif ( p a c k ag e I t e r at o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name pkgPDM := pa c k a g e I te r a t o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgPDM . name . toOut (); } elseif ( p a c k ag e I t e r at o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name pkgMapping := p a c k ag e I t e r a to r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgMapping . name . toOut (); } elseif ( p a c k ag e I t e r at o r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name

= ’ PSM ’ ){

= ’ PIM ’ ){

= ’ PDM ’ ){

= ’ Mapping ’ ){

= ’ java ’ ){

B


pkgJava := p a c k a ge I t e r a to r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgJava . name . toOut ();

112 113 114

} p a c ka g e I t e r at o r . next ();

115 116

}

117 118

p a c ka g e I t e r at o r := pkgJava . ownedElement . ge tN ewI te rat or ();

119 120

while p a c k ag e I t e r a to r . isOn () { if ( p a c k a ge I t e r a t or . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !). name = ’ lang ’ ){ pkgJava := p a c k a ge I t e r a to r . item (). oclAsType \ (! source_model :: M o d e l _ M a n a g e m e n t :: Package !); pkgJava . name . toOut (); } p a c ka g e I t e r at o r . next (); }

121 122 123 124 125 126 127 128 129 130 131

}

132 133 134 135 136 137 138 139 140 141 142 143 144 145

/* * Add some stuff to model . */ M o d el P I M m a p pi n g () { it , itAssEnd : Standard :: Iterator ; clPIM , clPSM , clJava : source_model :: Core :: Class ; aAssCl1 , aAssCl2 : source_model :: Core :: Class ; aAssEnd1 , aAssEnd2 : source_model :: Core :: As so cia ti on End ; stePSM : source_model :: Core :: Stereotype ; anOperation : source_model :: Core :: Operation ; aType : source_model :: Core :: Classifier ; aParameter : source_model :: Core :: Parameter ;

146 147 148 149

uml : UML_Utils ; uml := new UML_Utils (); uml . init ( source_model );

150 151

umlEntryPoint := g e t E n t r y P o i n t I n U m l 1 4 S o u r c e M o d e l ();

152 153 154

’ *** get packages from UML model *** ’. toOut (); g e t M o d e l P a c k a g e s ();

155 156 157

’ *** create new output package *** ’. toOut (); pkgOut := uml . c r e a t e A n d A d d P a c k a g e ( ’ PSM ’ , umlEntryPoint );

158 159 160

’ *** get classes for the given package *** ’. toOut (); it := pkgPIM . ownedElement . g et Ne wIt er at or ();

161 162 163 164 165 166

while it . isOn () { if ( it . item (). oclIsKindOf (! source_model :: Core :: Class !)) { clPIM := it . item (). oclAsType (! source_model :: Core :: Class !);

167 168 169 170 171 172

/* --- Thread <-> Process mapping --- */ if ( uml . hasStereotype ( clPIM , ’ process ’) ) { clPSM := uml . c r e a t e A n d A d d C l a s s ( clPIM . name . oclAsType \ (! Standard :: String !) , pkgOut );

173 174 175 176 177

stePSM := uml . c r e a t e S t e r e o t y p e ( ’ process ’ , pkgOut ); uml . a s s o c i a t e S t e r e o t y p e ( stePSM , clPSM ); stePSM := uml . c r e a t e S t e r e o t y p e ( ’ Thread ’ , pkgOut ); uml . a s s o c i a t e S t e r e o t y p e ( stePSM , clPSM );

178 179

clJava := uml . searchClass ( ’ Thread ’ , pkgJava );

180 181 182 183 184

if ( isNull ( clJava ). not ()) { uml . c r e a t e A n d A d d I n h e r i t a n c e B e t w e e n ( pkgOut , clPSM , clJava ); }

99

B


100

185

uml . copyClass ( clPIM , clPSM );

186 187

/* --- create o p e r a t i o n run () ... process body --- */ anOperation := uml . s e a r c h O p e r a t i o n W i t h S t e r e o t y p e ( ’ run ’ , clPSM );

188 189 190

if ( isNull ( anOperation ). not ()){ anOperation . name := ’ run ’; } } /* --- map all non - s t e r e o t y p e d classes --- */ else { clPSM := uml . c r e a t e A n d A d d C l a s s ( clPIM . name . oclAsType \ (! Standard :: String !) , pkgOut ); uml . copyClass ( clPIM , clPSM ); }

191 192 193 194 195 196 197 198

}

199 200

it . next ();

201

}

202 203

’ *** add new main class to output package *** ’. toOut ();

204 205

/* --- add main f u n c t i o n --- begin --- */ clPSM := uml . c r e a t e A n d A d d C l a s s ( umlEntryPoint . name . oclAsType \ (! Standard :: String !) , pkgOut ); anOperation := uml . c r e a t e A n d A d d O p e r a t i o n ( ’ main ’ , clPSM );

206 207 208 209 210

aType := uml . g e t T y p e A s C l a s s i f i e r ( ’ void ’ ); aParameter := uml . c r e a t e A n d A d d T y p e d R e t u r n P a r a m e t e r ( aType , anOperation ); aParameter . name := ’ return ’;

211 212 213 214

anOperation . concurrency := ! source_model :: Data_Types :: \ C a l l C o n c u r r e n c y K i n d !. cc k_ seq ue nt ial ; anOperation . ownerScope := ! source_model :: Data_Types :: \ ScopeKind !. sk_classifier ;

215 216 217 218 219

uml . c r e a t e A n d L i n k M e t h o d ( ’ java ’ , ’ // add process code here ... ’ , anOperation ); /* --- add main f u n c t i o n --- end --- */

220 221 222

’ *** associate classes for the given package *** ’. toOut (); it := pkgPIM . ownedElement . g et Ne wIt er at or ();

223 224 225

while it . isOn () { /* --- PIM -> PSM a s s o c i a t i o n mapping --- */ if ( it . item (). oclIsKindOf (! source_model :: Core :: Association !)) { itAssEnd := it . item (). oclAsType \ (! source_model :: Core :: Association !). connection . g etN ew It era to r ();

226 227 228 229 230 231 232 233

aAssEnd1 := itAssEnd . item (); itAssEnd . next (); aAssEnd2 := itAssEnd . item ();

234 235 236 237

aAssCl1 := uml . searchClass ( aAssEnd1 . participant . name . oclAsType \ (! Standard :: String !) , pkgOut ); aAssCl2 := uml . searchClass ( aAssEnd2 . participant . name . oclAsType \ (! Standard :: String !) , pkgOut );

238 239 240 241 242

/* --- add new a s s o c i a t i o n to PSM --- */ if ( isNull ( aAssCl1 ). not () and isNull ( aAssCl2 ). not ()){ uml . c r e a t e A n d A d d A s s o c i a t i o n B e t w e e n ( it . item (). oclAsType (! source_model :: Core :: Association !). \ name . oclAsType (! Standard :: String !) , pkgOut , uml . c o p y A s s o c i a t i o n E n d ( aAssEnd1 , aAssCl1 ) , uml . c o p y A s s o c i a t i o n E n d ( aAssEnd2 , aAssCl2 )); }

243 244 245 246 247 248 249 250 251

}

252 253

it . next ();

254

}

255

}

256 257

}

B


B.3 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Zdrojový kód úlohy producent - konzument v jazyce JAVA

/* * Consumer - Producer * * Description : We would like to s y n c h r o n i z e p r o d u c e r and c o n s u m e r * so that p r o d u c e r puts a number in the buffer , then * the c o n s u m e r takes it out , then the p r o d u c e r puts * another number , and so on . * * Target system : any JAVA enabled o p e r a t i n g system * * Build command : gcj - Wall - p e d a n t i c -- main = C o n s u m e r P r o d u c e r G o o d \ * -o C o n s u m e r P r o d u c e r G o o d C o n s u m e r P r o d u c e r G o o d . java */ import java . util .*; import java . io .*;

16 17 18 19 20 21

public class C o n s u m e r P r o d u c e r G o o d { public static void main ( String [] args ) { Buffer buf = new Buffer ();

22

// create new threads Thread prod = new Producer (10 , buf ); Thread cons = new Consumer (10 , buf );

23 24 25 26

// s t a r t i n g threads prod . start (); cons . start ();

27 28 29 30

// wait for the threads to finish try { prod . join (); cons . join (); } catch ( I n t e r r u p t e d E x c e p t i o n e ) { return ;}

31 32 33 34 35

}

36 37

}

38 39 40 41 42 43

// Simple buffer to e x c h a n g e data between p r o d u c e r and c o n s u m e r . class Buffer { private int contents ; private boolean empty = true ;

44 45 46 47 48 49 50 51 52

public synchronized void put ( int i ) throws I n t e r r u p t e d E x c e p t i o n { // wait till the buffer becomes empty while ( empty == false ) { try { wait (); } catch ( I n t e r r u p t e d E x c e p t i o n e ) { throw e ;} }

53

contents = i ; empty = false ; System . out . println ( " Producer : put ... " + i ); notify ();

54 55 56 57 58

}

59 60 61 62 63 64 65 66 67

public synchronized int get () throws I n t e r r u p t e d E x c e p t i o n { // wait till s o m e t h i n g appears in the buffer while ( empty == true ) { try { wait (); } catch ( I n t e r r u p t e d E x c e p t i o n e ) { throw e ;} }

68 69 70 71

101

empty = true ; notify (); int val = contents ;

B


System . out . println ( " Consumer : got ... " + val ); return val ;

72 73

}

74 75

}

76 77 78 79 80 81

// P r o d u c e r puts data into buffer . class Producer extends Thread { private Buffer prodBuf ; private int n ;

82

public Producer ( int m , Buffer buf ) { n = m; prodBuf = buf ; }

83 84 85 86 87

public void run () { int value =0;

88 89 90 91

for ( int i = 0; i < n ; i ++) { try { // sleep for a r a n d o m l y chosen time Thread . sleep ( ( int ) Math . random () * 100); // put data into buffer prodBuf . put ( value ++); } catch ( I n t e r r u p t e d E x c e p t i o n e ) { throw new R u n t i m e E x c e p t i o n ( e );} }

92 93 94 95 96 97 98 99 100 101

}

102 103

}

104 105 106 107 108 109

// C o n s u m e r gets data from buffer . class Consumer extends Thread { private Buffer consBuf ; private int n ;

110

public Consumer ( int m , Buffer buf ) { n = m; consBuf = buf ; }

111 112 113 114 115

public void run () { int value ;

116 117 118 119

for ( int i = 0; i < n ; i ++) { try { // get data from buffer value = consBuf . get (); // sleep for a r a n d o m l y chosen time Thread . sleep ( ( int ) Math . random () * 100); } catch ( I n t e r r u p t e d E x c e p t i o n e ) { throw new R u n t i m e E x c e p t i o n ( e );} }

120 121 122 123 124 125 126 127 128 129

}

130 131

}

102

C

Zdrojové kódy pro testování real-time vlastností OS Linux

C C.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Zdrojové kódy pro testování real-time vlastností OS Linux Test na paralelním portu bez real-time podpory - rect.c

/* * P a r a l l e l Port Digital Output * * Description : Program toggles p a r a l l e l port data pins D0 - D7 . * * Target system : GNU / Linux 2.4 or 2.6 kernel * * Build command : gcc - Wall - p e d a n t i c rect . c -o rect * */ # include < stdio .h > # include < unistd .h > # include < sys / io .h > # include < signal .h >

15 16

# define BASEPORT 0 x378

/* p a r a l l e l port base address */

int end = 0 ;

/* end program if 1 */

17 18 19 20 21 22 23 24 25 26 27 28 29 30

/* * * \ brief UNIX signal handler * * Handles r e c e i v e d UNIX signals . * * \ param signal signal number */ void si gna l_ ha ndl er ( int signal ) { end = 1; }

/* t e r m i n a t e program on any signal */

31 32 33 34

int main ( int argc , char ** argv ) { printf ( " Press CTRL - C to terminate program .\ n " );

35

if ( ioperm ( BASEPORT ,3 ,1) ) /* set p a r a l l e l port I / O p e r m i s s i o n s */ { perror ( " ioperm open failed " ); return ( -1); }

36 37 38 39 40 41

signal ( SIGINT , si gna l_ han dl er ); /* install signal handler */

42 43 44

outb (0 , BASEPORT +2);

/* set p a r a l l e l port to output mode */

while (! end ) { usleep (0); outb (0 , BASEPORT ); usleep (0); outb (255 , BASEPORT ); }

/* p a r a l l e l port pins D0 - D7 low */

45 46 47 48 49 50 51 52

/* p a r a l l e l port pins D0 - D7 high */

53

if ( ioperm ( BASEPORT ,3 ,0) ) /* drop p a r a l l e l port I / O p e r m i s s i o n s */ { perror ( " ioperm close failed " ); return ( -1); }

54 55 56 57 58 59

return (0);

60 61 62

}

103

C


C.2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

104

Test na paralelním portu s real-time podporou - rtai.c

/* * P a r a l l e l Port Digital Output - RTAI * * Description : Program toggles p a r a l l e l port data pins D0 - D7 . * O r i g i n a l source code d o w n l o a d e d from * http :// www . captain . at / p r o g r a m m i n g / rtai / test . php * * Target system : GNU / Linux 2.6 kernel * * Build command : use make command * */ # include < linux / module .h > # include < rtai .h > # include < rtai_sched .h >

16 17 18 19 20

# define # define # define # define

TICK_PERIOD 50000 TASK_PRIORITY 1 STACK_SIZE 10000 BASEPORT 0 x378

/* 50 us tick */

/* p a r a l l e l port base address */

21 22 23

static RT_TASK rt_task ; static RTIME tick_period ;

24 25 26 27 28 29 30 31 32 33 34

static void pp_toggle ( int t ) { while (1) { outb (0 , BASEPORT ); r t _ t a s k _ w a i t _ p e r i o d (); outb (255 , BASEPORT ); r t _ t a s k _ w a i t _ p e r i o d (); } }

/* p a r a l l e l port task */

int xinit_module ( void ) { outb (0 , BASEPORT +2);

/* module init f u n c t i o n */

/* p a r a l l e l port pins D0 - D7 low */ /* p a r a l l e l port pins D0 - D7 high */

35 36 37 38

/* set p a r a l l e l port to output mode */

39

r t _ s e t _ p e r i o d i c _ m o d e (); rt_task_init (& rt_task , pp_toggle , 1 , STACK_SIZE , TASK_PRIORITY , 1 , 0); tick_period = st ar t_r t_ ti mer ( nano2count ( TICK_PERIOD )); r t _ t a s k _ m a k e _ p e r i o d i c (& rt_task , rt_get_time () + tick_period , tick_period );

40 41 42 43 44

return 0;

45 46

}

47 48 49 50 51 52

void x c l e an u p _ m o d ul e ( void ) { stop_rt_timer (); rt _t as k_d el ete (& rt_task ); }

53 54 55 56 57

module_init ( xinit_module ); module_exit ( x c l e a nu p _ m o d u le ); MO DU LE _LI CE NSE ( " GPL " );

/* module s h u t d o w n f u n c t i o n */

C


Makefile pro linuxové jádro řady 2.6 1

obj - m := p a r p o r t _ r t _ p r o c e s s . o

2 3 4 5

KDIR := / lib / modules / $ ( shell uname -r )/ build PWD := $ ( shell pwd ) EXTRA_CFLAGS := -I / usr / realtime / include -I / usr / include /

6 7 8

default : $ ( MAKE ) -C $ ( KDIR ) SUBDIRS = $ ( PWD ) modules

Zavedení modulů jádra 1 2 3

modprobe rtai_hal modprobe rtai_ksched modprobe p a r p o r t _ r t _ p r o c e s s

Odstranění modulů jádra 1 2 3 4

rmmod rmmod rmmod rmmod

parport_rt_process rtai_up rtai_ksched rtai_hal

105

D

D 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19


106


/* * HW / SW - WDT for real - time systems * * Description : C o n s u m e r - p r o d u c e r example based on POSIX thread * library . P r o d u c e r puts a number in the buffer , then * the c o n s u m e r takes it out , then the p r o d u c e r puts * another number , and so on . HW / SW w a t c h d o g s s u p e r v i s e * the a p p l i c a t i o n health . * * Target system : GNU / Linux * * Build command : gcc - Wall - p e d a n t i c - l p t h r e a d wdt . c -o wdt */ # include < stdio .h > # include < stdlib .h > # include < pthread .h > # include < sched .h > # include < unistd .h > # include < fcntl .h >

20 21 22 23 24 25 26

/* SW typedef int int int } WDT ;

w a t c h d o g d e s c r i p t o r */ struct wdt { cons_wdt , cons_ctr ; prod_wdt , prod_ctr ; sw_wdt ;

27 28

int buffer = 0;

/* buffer to share data between c o n s u m e r and p r o d u c e r */

29 30 31 32 33 34 35 36 37 38 39 40

/* * * \ brief C o n s u m e r thread . * * P r o d u c e r puts a number in the buffer . * * \ param * arg pointer to WDT d e s c r i p t o r * \ return NULL */ void * consumer ( void * arg ) { WDT * wdt = ( WDT *) arg ;

41

printf ( " Consumer thread is up .\ n " ); sched_yield (); /* switch to other thread */

42 43 44 45

do {

46

wdt - > cons_wdt ++; /* i n c r e m e n t c o n s u m e r WDT flag */ printf ( " Consumer - wdt flag % d - buffer - % d \ n " , wdt - > cons_wdt , buffer ); sched_yield (); /* switch to other thread */ } while ( wdt - > cons_wdt < wdt - > cons_ctr );

47 48 49 50

return ( NULL );

51 52

/* t e r m i n a t e thread */

}

53 54 55 56 57 58 59 60 61 62 63 64

/* * * \ brief P r o d u c e r thread . * * C o n s u m e r takes it out data from the buffer . * * \ param * arg pointer to WDT d e s c r i p t o r * \ return NULL */ void * producer ( void * arg ) { WDT * wdt = ( WDT *) arg ;

65 66 67

printf ( " Producer thread is up .\ n " ); sched_yield (); /* switch to other thread */

68 69 70 71

do { wdt - > prod_wdt ++; /* i n c r e m e n t p r o d u c e r WDT flag */ printf ( " Producer - wdt flag % d - buffer - % d \ n " , wdt - > prod_wdt , ++ buffer );

D


107

sched_yield (); /* switch to other thread */ } while ( wdt - > prod_wdt < wdt - > prod_ctr );

72 73 74

return ( NULL );

75 76


}

77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98

/* * * \ brief SW - WDT thread . * * Thread o b s e r v e s a p p l i c a t i o n health . HW w a t c h d o g is enabled and * cleared by SW - WDT thread . * * \ param * arg pointer to WDT d e s c r i p t o r * \ return NULL */ void * sw_wdt ( void * arg ) { int fd ; WDT * wdt = ( WDT *) arg ; /* enable HW w a t c h d o g */ if (( fd = open ( " / dev / watchdog " , O_WRONLY )) == -1) { perror ( " Watchdog open " ); exit (1); } else { printf ( " HW - WDT enabled .\ n " ); }

99

printf ( " SW - WDT thread is up .\ n " ); sched_yield (); /* switch to other thread */

100 101 102

while (1) { write ( fd , " \0 " ,1); fsync ( fd );

103 104 105 106

/* clear HW w a t c h d o g */

107

printf ( " \ nSW - WDT - wdt flag sw % d | prod % d | cons % d - HW - WDT cleared \ n " , wdt - > sw_wdt , wdt - > prod_wdt , wdt - > cons_wdt );

108 109 110

if ( wdt - > sw_wdt > wdt - > prod_wdt ) printf ( " Producer failure detected !\ n " );

111 112 113

if ( wdt - > sw_wdt > wdt - > cons_wdt ) printf ( " Consumer failure detected !\ n " );

114 115 116

if ( wdt - > sw_wdt > wdt - > cons_wdt && wdt - > sw_wdt > wdt - > prod_wdt ) { printf ( " Program failure detected !\ n " ); printf ( " Waiting for HW - WDT reboot !\ n " ); break ; }

117 118 119 120 121 122

wdt - > sw_wdt ++; sched_yield ();

123 124

/* i n c r e a s e SW - WDT flag */ /* switch to other thread */

}

125 126

return ( NULL );

127 128


}

129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

/* * * \ brief Program help . * * \ param * name program name */ void usage ( char * name ) { printf ( " Usage : % s [ - h ] [ - b int -c int -p int ]\ n " , name ); printf ( " -c int consumer count value , by default 10\ n " ); printf ( " -p int producer count value , by default 10\ n " ); printf ( " -h program help \ n " ); }

D

145 146 147 148 149


int main ( int argc , char ** argv ) { pthread_t thread_wdt , thread_prod , thread_cons ; int c ; WDT wdt ={0 ,10 ,0 ,10 ,0};

150

/* parse command line p a r a m e t e r s */ while (( c = getopt ( argc , argv , " c : p : h " )) != -1) { switch ( c ) { case ’c ’: /* c o n s u m e r loop counter */ wdt . cons_ctr = atoi ( optarg ); break ; case ’p ’: /* p r o d u c e r loop counter */ wdt . prod_ctr = atoi ( optarg ); break ; case ’h ’: /* show help */ usage ( argv [0]); return 0; default : return -1; } }

151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167

/* create producer , c o n s u m e r pt hr ea d_c re ate (& thread_wdt , pt hr ea d_c re ate (& thread_prod , pt hr ea d_c re ate (& thread_cons ,

168 169 170 171

and w a t c h d o g threads */ NULL , sw_wdt , ( void *) & wdt ); NULL , producer , ( void *) & wdt ); NULL , consumer , ( void *) & wdt );

172

/* wait till all threads c o m p l e t e */ pthread_join ( thread_prod , NULL ); pthread_join ( thread_cons , NULL ); pthread_join ( thread_wdt , NULL );

173 174 175 176 177

return 0;

178 179

}

108

E

E

Obsah přiloženého CD

109

Obsah přiloženého CD

Text disertační práce včetně kompletního programového vybavení vytvořeného v rámci disertační práce je uložen na datovém CD. Toto CD je přiloženo jako elektronická příloha disertační práce. Data uložená na CD mají následující adresářovou strukturu: • doc: – src ∗ text disertační práce ve formátu LATEX ∗ obrázky použité v disertační práci ve formátu xfig – text disertační práce ve formátu PDF • src: – zdrojové kódy programů v jazyce C – zdrojové kódy programů v jazyce JAVA – zdrojové kódy transformací v jazyce MTL

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

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

Recommend Documents