Agenda Några ord om mig själv 99 sekunder om företaget Enea och OSE

En presentation över ämnet: "Agenda Några ord om mig själv 99 sekunder om företaget Enea och OSE"— Presentationens avskrift:

1

2 Agenda Några ord om mig själv 99 sekunder om företaget Enea och OSE
Varför RTOS? Vad skiljer ett RTOS från ett desktop OS? Kan man skriva ett RTOS själv? Vilka RTOS finns? Hur mycket kan man lita på ett RTOS? Ditt liv hänger på fungerande RTOS

3 Jan Lindblad janl@enea.se
KTH Datateknik, examen -95 M.Sc.CS Ericsson Software Technology + Ericsson Telecom (Erlang utv) Enea OSE Systems Anchor FAE - Field Application Engineer 12: Lödde ihop första datorn, ZX81 17: Skrev luffarschack som lär sig av sina misstag 17: Skrev min första kompilator 21: Medlem i Stacken 24: Exjobb i Sophia Antipolis på Franska sydkusten 25: Ericsson: distribuerade plattformar och telefonväxlar... Idag: Gift och dotter, 2 år

4 Jan Lindblad janl@enea.se
RTOS programmering VxWorks Embedded Solaris OSE Andra liknande exekveringsomgivningar OTP/Erlang Concurrent C

5 Company Profile Enea OSE Systems Fully owned subsidiary of Enea Data
European headquarters in Stockholm, Sweden 100+ employees worldwide Sales $13 Million (1998) US headquarters in Dallas, Texas Offices throughout Europe and the US

6 OSE Worldwide offices Company Profile

7 Company Profile Enea Data Founded in 1968
Head Office in Stockholm, Sweden Listed on the Swedish stock exchange Specialists in Real-Time, Tools and OO 360 employees (1998), >500 today Sales of $35 Million (1998)

8 Company Profile Enea Data @internet
enea.se first domain registered in Sweden (1986) Enea Swedish IP backbone operator until 1988 First in Sweden received at Enea (14:02, April 7, 1983) Enea hosted first Swedish Unix system (VAX/780, BSD Unix)

9 OSE Customers There are millions of products with OSE inside!
Telecommunications Ericsson, Nokia, Phillips, Lucent, Siemens Datacommunications Sagem, Philips Automotive Mercedes, SAAB Wireless Ericsson, Nokia, Lucent, R&S Petrochemical ICS, Triconex Consumer Electronics Sony, Sagem Medical Siemens, Medtronic, GE Medical, Gambro, Phillips Medical Industrial Landis & Gyr, ABB Atlas Copco, Fisher Controls, Fisher Rosemount Defence Industry Racal, British Aerospace, SAAB, Lockheed Martin

10 Objective of Enea OSE Systems
”Enea OSE Systems provides a leading, highly reliable RTOS solution by offering front-end technology and a close and flexible co-operation with key customers within the communications and safety related industries.”

11 Agenda  Några ord om mig själv 99 sekunder om företaget Enea och OSE
Varför RTOS? Vad skiljer ett RTOS från ett desktop OS? Kan man skriva ett RTOS själv? Vilka RTOS finns? Hur mycket kan man lita på ett RTOS? Ditt liv hänger på fungerande RTOS

12 Varför RTOS? Vilket OS skulle du välja för att bygga en
UMTS basstation? IP router? TextTV modul? Dialys apparat? GPS mottagare för flygplan? Talkodare för GSM telefoner? Allt detta går att göra i Linux eller tom Windows 95 Varför finns då en massa RTOS?

13 Vanliga tekniska designkriterier vid val av RTOS
Dessa 10 tittar vi strax närmare på CPU- och minneskrav Kärnmodell Processmodell Skeduleringsmodell Minneshanteringsmodell Avbrotts (interrupt) modell Interprocesskommunikation (IPC) Felhanteringsmodell Drivrutinsmodell (DD) Programladdning och kontinuerlig drift

14 Vanliga tekniska designkriterier vid val av RTOS
Tilläggsprodukter (kommunikation, minnesskydd, filsystem, …) Integrationer med 3:e-parts leverantörers produkter Prestanda på allt detta Säkerhet (safety, security) Utvecklingsmiljö, verktyg

15 Andra designkriterier vid val av RTOS
Trevlig säljare Pris, -modell Support (snabbhet, kunskap, språk, tidzon, besöksfrekvens) Kurser (nivå, när, var) Konsulter med kunskap om OSet finns Upplevd kvalitet Tillgång på källkod (och var ligger ansvaret?) Leveranstid Stabil (=stor) leverantör Flashiga demon …

16 #1: Kriterier vid val av CPU
Somliga väljer CPU först, RTOS sen. Somliga tvärt om. Det RTOS man till slut väljer måste i alla fall finnas tillgängligt på den processor man väljer: Pris per enhet Beräkningsprestanda Avbrottsfördröjning (interrupt latency) Tillgängliga kompilatorer Extra funktioner på ett kisel (inbyggd ethernet controller, …) Fysisk storlek Effektförbrukning, värmeavledningskrav Storlek på instruktionerna (minnesförbrukning) Störningstålighet (RFI) Hanterbarhet vid montering

17 Centralprocessor televäxel 64-bit RISC
CPU- och minneskrav Snabb Centralprocessor televäxel 64-bit RISC Talkodare DSP Router 32-bit RISC GPS mottagare 32-bit Dialysapparat 32-bit TextTV modul 8-bit CPU Långsam 1kB 1MB 1GB Minnesbehov

18 #2: Kärnmodell Vilka delar av systemet kan kärnan leva utan?
Minskade minnes- och CPU krav Minskad risk (buggar, testning, intrång) Vilka delar kan bytas ut? Skriva en egen ersättning för en komponent Snygg design Få, enkla koncept som är användbara till mycket En (liten) OS-kärna där man kan ta bort eller byta ut vitala komponenter kallas ofta Mikrokärna (micro kernel) Nästan alla OS kallar sin kärna för mikrokärna, allt från 1kB till 500

19 #3: Processmodell Normalt lättviktiga processer process = tråd
I många RTOS kallas en process för task Processernas livslängd Statiska processer Dör en statisk process dör hela det programmet Statiska processer finns “alltid” och har ett globalt namn, man behöver aldrig kolla om processen lever Dynamiska processer

20 #4: Skeduleringsmodell
Händelsestyrt Strikt prioriterad avbrytande (preemptive) skedulering Bland de processer som är redo för exekvering kör man alltid processen med högst prioritet Inga processbyten för att vara “snäll” “Round robin” möjligen inom samma prio nivå Tidsstyrt Periodiska processer med hårda tidskrav (deadlines) Skeduleringen schemaläggs redan vid systemdesign Formella metoder kan bevisa att en applikation kommer att fungera Svårt att applicera på allt utom mycket små system

21 #5: Minneshanteringsmodell
Minneshantering är mycket centralt i inbyggda system Virtuellt minne Olika modeller för olika OS, ganska vanligt att använda Vanligt med virtuell adress = fysisk adress Swapping (sidväxling) Väldigt sällan använt i RTOS sammanhang Fragmentering Det svåraste problemet att lösa. Mycket viktigt att lösa väl Multipla pooler Olika delar av systemet har ofta olika minnespooler, så en del av systemet kan få slut på minne medans en annan kör som vanligt

22 Minneshanteringsmodell Fragmentering
% Fragmentering = 1 - (största fria block) / (fritt minne) 100 % 50 % 0 % t Extern vs intern fragmentering

23 Minneshanteringsmodell Fragmentering
Största fria block 50kB Fritt minne 5MB  99% fragmentering % Fragmentering = 1 - (största fria block) / (fritt minne) 100 % 50 % 0 % t t t test krach tex 2 timmar tex 2 veckor

24 #6: Avbrottsmodell Avbrott (interrupt) är mycket centralt i inbyggda system Typiska egenskaper: Avbrott har högre prioritet än andra processer Sinsemellan har olika avbrott olika prioritet Avbrott av högre prio avbryter lägre prioriterade avbrott Avbrott kan vara periodiska eller aperiodiska Tidsuppfattningen i ett OS drivs typiskt av ett periodiskt tick avbrott från en timer-krets med några millisekunders mellanrum

25 Avbrottsmodell Tiden det tar från hårdvarans avbrottssignal tills att hanteringen av avbrottet börjar kallas avbrottsfördröjning (interrupt latency). Intressanta storheter är dess max, medel, min och jitter Max anger hur lång tid man kan behöva vänta i värsta fall Skillnaden mellan Max och Min ger längden på systemets längsta kodavsnitt med avbrott avstängda Medel anger hur många avbrott/sek man kan hantera (interrupt throughput) Jitter är intressant om man ska sampla något vid varje avbrott Typiskt rör sig max mellan några hundra mikrosekunder (M68k) som värst till några tiotals nanosekunder som bäst (TMS320C62) Hur lång tiden blir beror framförallt på processorarkitekturen

26 Avbrottsmodell Avbrott genereras av hårdvara
Som bäst max 40ns 2 us Finns max?? ISR (Interrupt service routine) utan tillgång till RTOS systemanrop RTOS RTOS Avbrottsprocess eller ISR (Interrupt service routine) Desktop OS

27 Avbrottsmodell Avbrott genereras av hårdvara
Längsta tid avbrotten kan vara avstängda Tid för processorn att stanna pipeline och spara register Ta reda på vad som orsakade avbrottet Slå upp prioriteten för avbrottshanteringen Maska bort enheter med lägre prioritet Slå på avbrotten igen Hoppa till avbrottshanteringen När avbrottet är klart, återställ avbrottsmasken Som bäst max 40ns 2 us Finns max?? ISR utan tillgång till RTOS systemanrop RTOS RTOS Avbrottsprocess eller ISR (Interrupt service routine) Server/Desktop OS Längsta tid avbrotten kan vara avstängda Ta reda på vad som orsakade avbrottet Lägg rätt device driver i skeduleringskön Fortsätt med det som gjordes innan Skedulera device driver

28 Vanliga tekniska designkriterier vid val av RTOS
 CPU- och minneskrav  Kärnmodell  Processmodell  Skeduleringsmodell  Minneshanteringsmodell  Avbrotts (interrupt) modell Interprocesskommunikation (IPC) Felhanteringsmodell Drivrutinsmodell (DD) Programladdning och kontinuerlig drift

29 #7: Interprocesskommunikation (IPC) Varning
#7: Interprocesskommunikation (IPC) Varning! min OSE bakgrund kan lysa igenom… ;-) IPC är oerhört centralt i inbyggda system. Vanligaste typerna: Rena semaforer + ev. delat minne Mailboxar Meddelanden/Signaler (inte UNIX signaler!) Pipes Sockets Många RTOS stödjer alla ovanstående, fast olika bra I inbyggda system ovanliga mekanismer för IPC: Filer Unix signaler WinPostMsg, DDE Corba, RMI

30 Interprocesskommunikation (IPC) Rena semaforer + ev. delat minne
En riktig klassiker. Vanligt i äldre eller mindre OS Normalt en semafor för varje händelse man kan signalera Bra därför: Enkelt och litet att implementera Mycket lätt att begripa Snabbt Dåligt därför: Kräver delat minne, dvs kan ej användas med minnesskydd eller i distribuerade system Råkar ofta ut för prioritetsinversion Om processer kan dö när de äger en semafor blir det en riktig soppa Inte alls kul att debugga

31 Interprocesskommunikation (IPC) Mailboxar
Också klassiker. Vidareutveckling av semafor + delat minne Normalt en mailbox per slag av information och mottagare Bra därför: Enkelt och litet att implementera Lätt att begripa Snabbt Dåligt därför: Kräver delat minne, dvs kan ej användas med minnesskydd eller i distribuerade system Råkar ofta ut för prioritetsinversion Om processer kan dö när de äger en mailbox blir det en riktig soppa Inte så kul att debugga

32 Interprocesskommunikation (IPC) Meddelanden/Signaler
Vanligt bland nya RTOS som stödjer distribuerade eller säkra system Normalt en signalkö (skapas automatiskt) per mottagare Bra därför: Mycket lätt att begripa Snabbt Fungerar exakt likadant (bara långsammare) över minnesskydd eller processorgränser Praktiskt om processer kan dö när som helst (och de kan de i distribuerade system) Trevligt att debugga (innehållet förstås av debugger / OS) Dåligt därför: Det går även här att ådstakomma prioritetsinversion och cirkulära beroenden

33 Interprocesskommunikation (IPC) Pipes, Sockets
Vanligt bland större RTOS. Sockets är ofta ett krav för att kunna kommunicera med omvärlden Bra därför: Lätt att begripa om man är van vid Unix Fungerar exakt likadant över minnesskydd eller processorgränser Praktiskt om processer kan dö när som helst (och det kan de i distribuerade system) Portabelt (sockets) Inbyggd flödeskontroll Dåligt därför: Långsamt, bla måste allt data kopieras en eller flera gånger Kräver relativt stora OS moduler (filsystem eller nätverksstöd)

34 #8: Drivrutinsmodell (Device Driver model)
Direkt modell Varje applikation pratar direkt med hårdvara efter behov I princip alla RTOS tillåter detta Avbrottscentrerad modell handleRX(), handleTX(), handleEX() Effektivt lågnivå gränssnitt Unix-modell read(), write(), select() och felkoder Enkelt och lättbegripligt för klienten Möjliggör unifierad I/O, allt är fildeskriptorer Jobbigt att skriva drivrutinen Inte speciellt effektivt

35 #9: Felhanteringsmodell
Felhanteringen äv väldigt olika även bland RTOS Typisk felhantering i desktop OS är ett felmeddelande på skärmen eller en dialogruta: diff: fel.fil: No such file or directory Windows warning: Running low on virtual memory... I ett förarlöst system måste systemet själv fixa detta Hur/om returneras felkoder Återhämtningsstrategi (recovery strategy) Processövervakning (process supervision)

36 Felhanteringsmodell Felkoder
void *foo = malloc(sizeof(Foo)); if(!foo) { do_something(); } Returnera felkoder, applikationen kollar (eller borde iaf) Kontroll för felfall minst två gånger Felkodskontroll kan “glömmas bort” Ofta inkonsistent hantering om den inte samlas upp som ovan Returnera inte felkoder, hoppa direkt till felhanterare Går ej att tillämpa på standardiserade funktioner som malloc(), fopen(), select() etc. Mer lättläst kod Snabbare kod (mindre kod med bara en kontroll och bättre minneslokalitet)

37 Felhanteringsmodell Återhämtningsstrategi
Om en process upptäcker ett fel så är det enda man kan vara säker på att processen befinner sig i ett tillstånd som den som designade systemet inte tänkt på Kör-på strategi (forward recovery) Traditionell programmering, lista ut vad som gick snett, fixa det och försök igen. Tex en parameter har för stort värde, sätt den till max tillåtet värde istället och kör vidare Backa-tillbaks strategi (backward recovery) Viktigt att verkligen säkert bli av med felet  backward recovery Backward recovery  döda processer tvärt Processer kan dö när som helst  Semaforer eller mailboxar kan inte användas Uppstädning av resursägare (server), ej själv (klient) Processövervakningsmekanism nödvändig

38 Felhanteringsmodell Processövervakning, exempel
Kernel P Attach( , Q ) xyzzy P lämnar ett meddelande till kärnan (fungerar som advokat). Kärnan returnerar meddelandet till P vid Qs död, eller friar det vid Ps död Q

39 Felhanteringsmodell Processövervakning, exempel
xyzzy P Q Kernel P Skicka meddelande och vänta på svar foo Send( ) Q

40 Felhanteringsmodell Processövervakning, exempel
xyzzy P Q Kernel P Vänta på svar Send( ) reply Q Q svarar

41 Felhanteringsmodell Processövervakning, exempel
xyzzy P Q Kernel P Vänta på svar Istället för det väntade svaret kom dödsnotisen P kan vara Qs Övervakare (supervisor) Barn (child) Server Klient ... Q Eller Q dör

42 Felhanteringsmodell Processövervakning, exempel
xyzzy P Q Kernel P Vänta på svar Istället för det väntade svaret kom dödsnotisen Exakt samma sak i ett distribuerat fall Transport Kernel Samma sak händer om ett helt kort eller nätet fallerar Q Eller Q dör

43 #10: Programladdning I system som ska vara igång länge utan avbrott (läs: basstationer, växlar, routers) är det viktigt att kunna lägga till och byta ut delar av systemet (hård och mjukvara) under drift I telekombranchen brukar man tala om 5 9:or, dvs 99,999% av tiden ska systemet vara i drift. Det blir 5 minuter planerad och oplanerad tid ur drift per år Lika viktigt som att kunna ladda program i drift är att kunna ladda ur program i drift Byte av hårdvara i drift har på senare tid marknadsförts som “plug & play” alternativt “plug & pray” För att uppnå 5 nior måste systemet starta om snabbt vid oplanerad återstart (reboot) Vissa RTOS klarar till och med byte av operativsystemskärnan i drift, även på ett en-processor system. Det innebär dock att systemet blir otillgängligt ett ögonblick

44 Vanliga tekniska designkriterier vid val av RTOS
 CPU- och minneskrav  Kärnmodell  Processmodell  Skeduleringsmodell  Minneshanteringsmodell  Avbrotts (interrupt) modell  Interprocesskommunikation (IPC)  Felhanteringsmodell  Drivrutinsmodell (DD)  Programladdning och kontinuerlig drift De ovan nämnda tekniska egenskaperna hos ett RTOS är anledningen till att många utvecklare vill använda sådana

45 Agenda  Några ord om mig själv 99 sekunder om företaget Enea och OSE
 Varför RTOS? Vad skiljer ett RTOS från ett desktop OS? Kan man skriva ett RTOS själv? Vilka RTOS finns? Hur mycket kan man lita på ett RTOS? Ditt liv hänger på fungerande RTOS

46 Kan man skriva ett RTOS själv?
Naturligtvis kan man det De som kommer sig för att göra det brukar tycka det är ganska kul, intressant och utvecklande dessutom Man får ett system som är skräddarsytt för det man vill göra Man har källkod och kompetens att förändra och vidareutveckla Hemmabyggen vanligaste “RTOSet”, än idag Trenden är dock nedåtgående, allt fler köper in sina OS enligt marknadsanalysföretag De flesta hembyggda OS är relativt små med begränsad funktionalitet

47 Kan man skriva ett RTOS själv?
Problemet med egna OS brukar vara Risk att George slutar (arkitekten och implementatören) Mycket jobb att skriva bra verktyg Mycket jobb att skriva bra tilläggskomponenter som minnesskydd, programladdning, nätverk, filsystem, web server, databas, … Drivrutiner... Nästa gång vill man köra på en annan processorarkitektur

48 Vilka RTOS finns? Frågar man Yahoo hittar man omkring 50 kommersiella RTOS. Det finns säkert minst det dubbla. De flesta är regionala Olika RTOS har olika nischningar Mot vissa slags applikationer Mot viss hårdvara Mot vissa kunder Med vissa säkerhetskrav I olika prisnivåer

49 Vilka RTOS finns? … och massor av andra! Tidsstyrda Rubus Perts
Händelsestyrda Mailboxarna VxWorks pSOS VRTX Signalerarna OSE UNIX klubben Linux Embedded Solaris Grafikerna Windows CE Epoc UNIX  Signaler QNX Lynx Chorus Småttingarna Ecos Nucleus … och massor av andra!

50 Agenda  Några ord om mig själv 99 sekunder om företaget Enea och OSE
 Varför RTOS? Vad skiljer ett RTOS från ett desktop OS?  Kan man skriva ett RTOS själv? Vilka RTOS finns? Hur mycket kan man lita på ett RTOS? Ditt liv hänger på fungerande RTOS

51 Säkerhetsdefinitioner
Säkerhet på svenska kan översättas på två sätt på engelska Safety Ett system är “safe” när det inte skadar någon/något Security Ett system är “secure” när det inte kan skadas av någon/något De flesta system kan förstås inte vara helt “safe” om de inte i viss utsträckning är “secure” Farlighet Ett systems farlighet bedöms som summan av alla tänkbara skadeverkningar gånger deras respektive sannolikheter System med stora tänkbara skadeverkningar oavsett sannolikhet måste kontrolleras noggrant

52 Säkerhetsdefinitioner
Man kan placera in system på ett koordinatsystem med axlarna Säkerhet (safety) Tillförlitlighet (reliability) Till exempel En Volvo Amazon som inte gillar kalla morgnar är säker men inte inte speciellt tillförlitlig De flesta pistoler är tillförlitliga men inte säkra Ibland spelar även systemets tillgänglighet (availability) en viktig roll SOS alarms system är inte säkert när det är ur drift! Ett cockpit system som säger “computer malfunction” är säkert om man är på marken

53 Certifiering Enligt lag måste någon som bygger ett flygplan, dialysapparat, raffinaderi etc bevisa för myndigheterna i landet där anläggningen ska brukas att anläggningen är säker För respektive område finns ett antal olika säkerhetsstandarder, vissa kompletterar varandra, vissa konkurrerar Certifieringen utförs av ackrediterade certifieringsorganisationer Rätten att ackreditera delas ut av myndigheten, eller så ackrediterar myndigheten själv Certifiering av mjukvara består av Granskning av kod Granskning av organisationens metoder Testsviter med kodtäckningsanalys (code coverage) Administrativt system för att rätta och meddela ev buggar

54 Säkerhetsstandarder Komponentbaserade
Certifiering som byggblock med vissa regler IEC 61508, SIL1-4 Kontrollmyndighet: IEC (EU organ) Medecin- och industrisystem Detta är den enda komponentbaserade säkerhetsstandarden OSE enda certifierade operativsystemet, certifierat till SIL3: “10-tals liv står på spel” OSE genomgår fn certifiering till SIL4

55 Säkerhetsstandarder Systembaserade
Certifiering per användningsfall, varje kund måste göra en egen certifiering DO-178B Kontrollmyndighet: FAA (Federal Aviation Administration) i USA Flyg-, rymd- och militära system Den absolut mest populära standarden i den här branchen OSE undergår flera certifieringar, bla en till högsta nivån Några andra OS har också klarat certifiering

56 Agenda  Några ord om mig själv 99 sekunder om företaget Enea och OSE  Varför RTOS? Vad skiljer ett RTOS från ett desktop OS?  Kan man skriva ett RTOS själv? Vilka RTOS finns?  Hur mycket kan man lita på ett RTOS? Ditt liv hänger på fungerande RTOS Frågor?