UppLYSning

1
(No Transcript)
2
Agenda

• Några ord om mig själv99 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 Lindbladjanl_at_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 Lindbladjanl_at_enea.se

• RTOS programmering
• VxWorks
• Embedded Solaris
• OSE
• Andra liknande exekveringsomgivningar
• OTP/Erlang
• Concurrent C

5
Enea OSE Systems
Company Profile
6
OSE Worldwide offices
Company Profile
7
Enea Data
Company 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), gt500 today

• Sales of 35 Million (1998)

8
Enea Data_at_internet
Company Profile

• enea.se first domain registered in Sweden (1986)

• Enea Swedish IP backbone operator until 1988

• First e-mail in Sweden received at Enea (1402,
  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
Automotive Mercedes, SAAB
Datacommunications Sagem, Philips
Wireless Ericsson, Nokia, Lucent, RS
Petrochemical ICS, Triconex
Industrial Landis Gyr, ABB Atlas Copco, Fisher
Controls, Fisher Rosemount
Defence Industry Racal, British Aerospace, SAAB,
Lockheed Martin
Medical Siemens, Medtronic, GE Medical,
Gambro, Phillips Medical
Consumer Electronics Sony, Sagem
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älv99 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 designkriteriervid 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 designkriteriervid val av RTOS

• Tilläggsprodukter (kommunikation, minnesskydd,
  filsystem, )
• Integrationer med 3e-parts leverantörers
  produkter
• Prestanda på allt detta
• Säkerhet (safety, security)
• Utvecklingsmiljö, verktyg

15
Andra designkriteriervid 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
CPU- och minneskrav
Snabb
Centralprocessor televäxel64-bit RISC
TalkodareDSP
Router32-bit RISC
GPS mottagare32-bit
Dialysapparat32-bit
TextTV modul8-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ändelsestyrtStrikt 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å
• TidsstyrtPeriodiska 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
MinneshanteringsmodellFragmentering
Fragmentering 1 - (största fria block) /
(fritt minne)
100
50
0
t
Extern vs intern fragmentering
23
MinneshanteringsmodellFragmentering
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 veckor
tex 2 timmar
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 genererasav hårdvara
Som bäst max 40ns Som bäst max 2 us Finns max??
ISR (Interrupt service routine) utan tillgång
till RTOS systemanrop
RTOS
RTOS
Avbrottsprocess ellerISR (Interrupt service
routine)
Desktop OS
27
Avbrottsmodell
Avbrott genererasav 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 Som bäst max 2 us Finns max??
ISR utan tillgång till RTOS systemanrop
RTOS
RTOS
Avbrottsprocess ellerISR (Interrupt service
routine)
Server/Desktop OS

• Lägg rätt device driver i skeduleringskön
• Fortsätt med det som gjordes innan
• Skedulera device driver

• Längsta tid avbrotten kan vara avstängda
• Ta reda på vad som orsakade avbrottet

28
Vanliga tekniska designkriteriervid 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! 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/Signal
er

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

• 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
FelhanteringsmodellProcessövervakning, exempel
Kernel
P
Attach( , Q )
P lämnar ett meddelandetill kärnan (fungerar
somadvokat). Kärnan returnerarmeddelandet till
P vid Qs död,eller friar det vid Ps död
Q
39
FelhanteringsmodellProcessövervakning, exempel
Kernel
P
Skicka meddelandeoch vänta på svar
foo
Send( )
Q
40
FelhanteringsmodellProcessövervakning, exempel
Kernel
P
Vänta på svar
Q
Q svarar
41
FelhanteringsmodellProcessövervakning, exempel
Kernel
P
Vänta på svarIstä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
FelhanteringsmodellProcessövervakning, exempel
Kernel
P
Vänta på svarIstället för det väntade svaret
kom dödsnotisen
Exakt samma saki ett distribuerat fall
Transport
Kernel
Samma sak händerom ett helt kort ellernä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 9or, 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 somplug 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 designkriteriervid 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älv99 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 OSenligt 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?
Tidsstyrda Rubus Perts
Händelsestyrda
UNIX klubben Linux Embedded Solaris
Mailboxarna VxWorks pSOS VRTX
Signalerarna OSE
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älv99 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
• SafetyEtt system är safe när det inte skadar
  någon/något
• SecurityEtt 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älv99 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?