>> RTOS UppLYSning
>> By: Jan Lindblad
Page 1
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 2
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 3
>> RTOS UppLYSning
>> By: Jan Lindblad
Jan Lindblad
janl@enea.se
• RTOS programmering
> VxWorks
> Embedded Solaris
> OSE
• Andra liknande exekveringsomgivningar
> OTP/Erlang
> Concurrent C
Page 4
>> RTOS UppLYSning
>> By: Jan Lindblad
Enea OSE Systems
Company Profile
> Fully owned subsidiary of Enea Data
> European headquarters in Stockholm, Sweden
> US headquarters in Dallas, Texas
> Offices throughout Europe and the US
> 100+ employees worldwide
> Sales $13 Million (1998)
Page 5
>> RTOS UppLYSning
>> By: Jan Lindblad
OSE Worldwide
Company Profile offices
Page 6
>> RTOS UppLYSning
>> By: Jan Lindblad
Company Enea Data
Profile
> 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)
Page 7
>> RTOS UppLYSning
>> By: Jan Lindblad
Company Enea Data
Profile
@internet
> enea.se first domain registered in Sweden (1986)
> Enea Swedish IP backbone operator until 1988
> First e-mail in Sweden received at Enea (14:02, April 7, 1983)
> Enea hosted first Swedish Unix system (VAX/780, BSD Unix)
Page 8
>> RTOS UppLYSning
>> By: Jan Lindblad
OSE Customers
> There are millions of products with OSE inside!
Telecommunications Datacommunications Automotive Wireless Petrochemical
Ericsson, Nokia, Phillips, Sagem, Philips Mercedes, SAAB Ericsson, Nokia, ICS, Triconex
Lucent, Siemens Lucent, R&S
Consumer Electronics Medical Industrial Defence Industry
Sony, Sagem Siemens, Medtronic, Landis & Gyr, ABB Racal, British Aerospace,
GE Medical, Atlas Copco, Fisher SAAB, Lockheed Martin
Gambro, Controls,
Phillips Medical Fisher Rosemount
Page 9
>> RTOS UppLYSning
>> By: Jan Lindblad
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.”
Page 10
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 11
>> RTOS UppLYSning
>> By: Jan Lindblad
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?
Page 12
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 13
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 14
>> RTOS UppLYSning
>> By: Jan Lindblad
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
• …
Page 15
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 16
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 17
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 18
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 19
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 20
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 21
>> RTOS UppLYSning
>> By: Jan Lindblad
Minneshanteringsmodell
Fragmentering
% Fragmentering = 1 - (största fria block) / (fritt minne)
100 %
50 %
0%
t
Extern vs intern fragmentering
Page 22
>> RTOS UppLYSning
>> By: Jan Lindblad
Minneshanteringsmodell
Största fria block 50kB
Fragmentering Fritt minne 5MB
99% fragmentering
% Fragmentering = 1 - (största fria block) / (fritt minne)
100 %
50 %
0%
t test t krach t
tex 2 timmar tex 2 veckor
Page 23
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 24
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 25
>> RTOS UppLYSning
>> By: Jan Lindblad
Avbrott Avbrottsmodell
genereras
av hårdvara
Som
bäst
max
RTOS ISR (Interrupt service routine) utan
tillgång till RTOS systemanrop
40ns
Som
Avbrottsprocess eller
bäst RTOS
max ISR (Interrupt service routine)
2 us
Finns
max?? Desktop OS
Page 26
>> RTOS UppLYSning
>> By: Jan Lindblad
Avbrott Avbrottsmodell
genereras •Längsta tid avbrotten kan vara avstängda
av hårdvara •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
Som •Hoppa till avbrottshanteringen
bäst
max
RTOS ISR utan tillgång till •När avbrottet är klart, återställ avbrottsmasken
RTOS systemanrop
40ns
Som
Avbrottsprocess eller
bäst RTOS
max ISR (Interrupt service routine)
2 us
Finns
max?? Server/Desktop OS
•Längsta tid avbrotten kan vara avstängda •Lägg rätt device driver i skeduleringskön
•Ta reda på vad som orsakade avbrottet •Fortsätt med det som gjordes innan
•Skedulera device driver
Page 27
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 28
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 29
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 30
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 31
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 32
>> RTOS UppLYSning
>> By: Jan Lindblad
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)
Page 33
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 34
>> RTOS UppLYSning
>> By: Jan Lindblad
#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)
Page 35
>> RTOS UppLYSning
>> By: Jan Lindblad
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)
Page 36
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 37
>> RTOS UppLYSning
>> By: Jan Lindblad
Felhanteringsmodell
Processövervakning, exempel
P
Kernel
Attach( xyzzy ,Q)
P lämnar ett meddelande
till kärnan (fungerar som
advokat). Kärnan returnerar
meddelandet till P vid Qs död,
Q
eller friar det vid Ps död
Page 38
>> RTOS UppLYSning
>> By: Jan Lindblad
Felhanteringsmodell
Processövervakning, exempel
P Q
xyzzy
P
Kernel
Skicka meddelande
och vänta på svar
Send( foo )
Q
Page 39
>> RTOS UppLYSning
>> By: Jan Lindblad
Felhanteringsmodell
Processövervakning, exempel
P Q
xyzzy
P
Kernel
Vänta på svar
Send( reply )
Q
Q svarar
Page 40
>> RTOS UppLYSning
>> By: Jan Lindblad
Felhanteringsmodell
Processövervakning, exempel
P Q
xyzzy
P
Kernel
Vänta på svar
Istället för det väntade
svaret kom dödsnotisen P kan vara Qs
•Övervakare (supervisor)
Q •Barn (child)
•Server
•Klient
Eller Q dör •...
Page 41
>> RTOS UppLYSning
>> By: Jan Lindblad
Felhanteringsmodell
Processövervakning, exempel
P Q
xyzzy
P
Kernel
Vänta på svar
Istället för det väntade Exakt samma sak
svaret kom dödsnotisen Transport i ett distribuerat fall
Samma sak händer
Q om ett helt kort eller
Kernel nätet fallerar
Eller Q dör
Page 42
>> RTOS UppLYSning
>> By: Jan Lindblad
#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
Page 43
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 44
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 45
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 46
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 47
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 48
>> RTOS UppLYSning
>> By: Jan Lindblad
Vilka RTOS finns?
Tidsstyrda Händelsestyrda
Rubus
Perts
Mailboxarna Signalerarna UNIX klubben Grafikerna
VxWorks OSE Linux Windows CE
pSOS Embedded Solaris Epoc
VRTX
UNIX Signaler
Småttingarna QNX
Ecos Lynx
Nucleus Chorus
… och massor av andra!
Page 49
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 50
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 51
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 52
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 53
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 54
>> RTOS UppLYSning
>> By: Jan Lindblad
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
Page 55
>> RTOS UppLYSning
>> By: Jan Lindblad
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?
Page 56