Presentation laddar. Vänta.

Presentation laddar. Vänta.

>> RTOS UppLYSning >> By: Jan Lindblad Page 1. >> RTOS UppLYSning >> By: Jan Lindblad Page 2 Agenda Några ord om mig själv 99 sekunder om företaget Enea.

Liknande presentationer


En presentation över ämnet: ">> RTOS UppLYSning >> By: Jan Lindblad Page 1. >> RTOS UppLYSning >> By: Jan Lindblad Page 2 Agenda Några ord om mig själv 99 sekunder om företaget Enea."— Presentationens avskrift:

1 >> RTOS UppLYSning >> By: Jan Lindblad Page 1

2 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 3 Jan Lindblad 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 4 Jan Lindblad RTOS programmering >VxWorks >Embedded Solaris >OSE Andra liknande exekveringsomgivningar >OTP/Erlang >Concurrent C

5 >> RTOS UppLYSning >> By: Jan Lindblad Page 5 Company Profile > 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 Enea OSE Systems

6 >> RTOS UppLYSning >> By: Jan Lindblad Page 6 Company Profile OSE Worldwide offices

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

8 >> RTOS UppLYSning >> By: Jan Lindblad Page 8 > 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) > enea.se first domain registered in Sweden (1986) Company Profile Enea

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

10 >> RTOS UppLYSning >> By: Jan Lindblad Page 10 ”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.” Objective of Enea OSE Systems

11 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 17 CPU- och minneskrav Talkodare DSP Router 32-bit RISC Centralprocessor televäxel 64-bit RISC TextTV modul 8-bit CPU Långsam Snabb 1kB1MB 1GB Minnesbehov Dialysapparat 32-bit GPS mottagare 32-bit

18 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 22 Minneshanteringsmodell Fragmentering % Fragmentering = 1 - (största fria block) / (fritt minne) t Extern vs intern fragmentering 50 % 100 % 0 %

23 >> RTOS UppLYSning >> By: Jan Lindblad Page 23 Minneshanteringsmodell Fragmentering % Fragmentering = 1 - (största fria block) / (fritt minne) t t test t krach tex 2 veckortex 2 timmar 50 % 100 % 0 % Största fria block 50kB Fritt minne 5MB  99% fragmentering

24 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 26 Avbrottsmodell RTOS Desktop OS Avbrottsprocess eller ISR (Interrupt service routine) Avbrott genereras av hårdvara ISR (Interrupt service routine) utan tillgång till RTOS systemanrop RTOS Som bäst max 40ns Som bäst max 2 us Finns max??

27 >> RTOS UppLYSning >> By: Jan Lindblad Page 27 Avbrottsmodell RTOS Server/Desktop OS Avbrottsprocess eller ISR (Interrupt service routine) Avbrott genereras av hårdvara ISR utan tillgång till RTOS systemanrop RTOS 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 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 Som bäst max 40ns Som bäst max 2 us Finns max??

28 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 38 Felhanteringsmodell Processövervakning, exempel P Q xyzzy Attach(, Q ) Kernel 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

39 >> RTOS UppLYSning >> By: Jan Lindblad Page 39 Send( ) Felhanteringsmodell Processövervakning, exempel P Q foo Kernel xyzzy PQ Skicka meddelande och vänta på svar

40 >> RTOS UppLYSning >> By: Jan Lindblad Page 40 xyzzy PQ Felhanteringsmodell Processövervakning, exempel P Q Send( ) reply Kernel Vänta på svar Q svarar

41 >> RTOS UppLYSning >> By: Jan Lindblad Page 41 xyzzy PQ Felhanteringsmodell Processövervakning, exempel P Q Kernel 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... Eller Q dör

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

43 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 49 Vilka RTOS finns? UNIX klubben Linux Embedded Solaris Mailboxarna VxWorks pSOS VRTX Signalerarna OSE Grafikerna Windows CE Epoc Tidsstyrda Rubus Perts Händelsestyrda UNIX  Signaler QNX Lynx Chorus … och massor av andra! Småttingarna Ecos Nucleus

50 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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 >> RTOS UppLYSning >> By: Jan Lindblad Page 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?


Ladda ner ppt ">> RTOS UppLYSning >> By: Jan Lindblad Page 1. >> RTOS UppLYSning >> By: Jan Lindblad Page 2 Agenda Några ord om mig själv 99 sekunder om företaget Enea."

Liknande presentationer


Google-annonser