Linux is niet gebouwd voor missiekritische taken. Gebruik het daar dan ook niet voor, maar combineer de kracht van het open-source OS met de sterke punten van een besturingssysteem dat wel bedoeld is voor het zware werk. Hans Jürgen Rauscher van Wind River over de inzet van een gemengde OS-omgeving voor hard realtime toepassingen.
Aan een aantal eisen van hard realtime OS‘en valt niet te tornen: de kernel moet preëmptief zijn, de vertraging bij de interruptrespons klein en het moet mogelijk zijn om het verschil tussen de best-case en worst-case prestatie concreet te beschrijven. Ook dienen ze taken foutloos te prioriteren. Volgens een recent onderzoek willen de meeste kopers van borden voor realtime embedded gebruik een reactietijd van 50 ms of minder. Voeg daaraan toe de al even strenge eisen van een kleine geheugenomvang, een laag energieverbruik en redundantie, en de lat ligt voor menig OS te hoog.
Zowel in defensietoepassingen als in de luchtvaart is ’hard realtime‘ synoniem voor ’missiekritisch‘. Voor beide geldt dat een systeemcrash ernstige gevolgen heeft en vergaarde data waardeloos maakt. De software mag gewoonweg geen deadline missen. Een realtime besturingssysteem is als een piloot: 98 procent verveling, maar in opperste staat van paraatheid als er iets onverwachts gebeurt. Conventionele RTOS‘en reageren noodzakelijkerwijs nog lokaal op onverhoede situaties, maar de toenemende beschikbaarheid van uitgebreide, Mils-compatibele netwerkfunctionaliteit brengt remote diagnose en foutoplossing, zelfs op interplanetaire afstand, binnen handbereik.
Sterke punten
Als hard realtime besturingssysteem heeft Linux zijn sporen nog niet verdiend en het is maar zeer de vraag of dat ooit gaat gebeuren, zelfs met kernelwijzigingen. De kracht van het open-source OS ligt in het grafisch weergeven van complexe data en op het gebied van I/O-doorvoer in een genetwerkte omgeving, twee waardevolle eigenschappen voor command and control en geïntegreerde luchtvaarttoepassingen. Daarnaast werkt de gemeenschap er hard aan om Linux betrouwbaar genoeg te maken voor soft realtime toepassingen, met aanpassingen aan versie 2.6 van de kernel en onafhankelijke ontwikkelingen binnen een aantal commerciële Linux-releases.
’Soft‘ realtime betekent dat de software wel tijdkritisch is, maar dat de gevolgen van een gemiste deadline aanzienlijk minder ernstig zijn dan bij hard realtime. Het systeem kan zijn werk blijven doen en de geproduceerde gegevens behouden hun waarde na een crash. Digitale displayapparatuur, mediaspelers en veel netwerktoepassingen vallen in deze categorie. Soft realtime is de arena waar Linux succesvol de oversteek zal maken van de desktop naar de cockpit.
Test less, verify Moore
At the Bits&Chips Event 2023 on 12 October 2023, Phillipa Hopcroft from Crocotec and Ivo ter Horst from ASML will kick off with a keynote speech on transforming how lithography machine software is built. Make sure to keep an eye on the website for program updates and save the date!
Hierbij is het belangrijk om in het achterhoofd te houden dat er aan Linux andere uitgangspunten ten grondslag liggen dan aan een realtime besturingssysteem. Het open-source OS is gebouwd om een zo goed mogelijke doorvoer te leveren met goede gemiddelde prestaties, terwijl een RTOS is ontworpen om deterministisch, hard realtime gedrag te bieden. Die eigenschappen moeten vanaf het allereerste begin worden meegenomen. Ze achteraf inbouwen is heel lastig.
Bij een RTOS moeten operaties die niet onderbroken mogen worden, bijvoorbeeld gebruikmaken van algoritmes die onafhankelijk zijn van de dataset. Zo kan een tijdkritisch systeem niet even een gelinkte lijst doorlopen om de gereedstaande taak met de hoogste prioriteit te vinden. Daarnaast moet het interrupts zo snel mogelijk afhandelen om de vertraging te minimaliseren. In plaats van in een interruptroutine te blijven hangen en data uit een kanaal te pompen, moet het dat werk afschuiven naar een taak die wel onderbroken mag worden.
In de basis verschilt Linux aanzienlijk van een realtime besturingssysteem. Allebei hebben ze hun eigen sterke punten en allebei hebben ze ook een aantal toepassingen waar ze minder geschikt voor zijn. Bij de complexe systemen van de toekomst is het zaak om de goede eigenschappen van beide ten volle te benutten in een gemengde OS-omgeving.
Open standaarden
In 1997 zwakte het Amerikaanse ministerie van Defensie zijn eis af dat programmeurs militaire software in Ada moesten schrijven. Sindsdien hebben we grote vooruitgang geboekt om een efficiënte en foutvrije omgeving te realiseren voor applicatieontwikkeling in meerdere talen. Door deze basis te verbreden kunnen we gewenste C-functionaliteit toevoegen zoals gedistribueerde toepassingen, interfaces met OpenGL en andere grafische bibliotheken, IPv6-ondersteuning en uitgebreid hergebruik van bestaande code.
De uitdagingen voor het creëren van effectieve mixed-language programmeerhulpmiddelen zijn dezelfde als die voor het bouwen van een omgeving om applicaties te schrijven voor meerdere OS‘en in één systeem. Met het laatste gereedschap kunnen ontwikkelaars code kloppen zonder zich te hoeven bekommeren om de specifieke details van het onderliggende softwareplatform. Ze kunnen de eisen van de applicatie afstemmen op de mogelijkheden van het OS, met de zekerheid dat hun producten ook in het veld kunnen communiceren met elkaar en met bedrijfsbrede toepassingen voor het manipuleren van data en het remote monitoren en beheren van apparaten.
Een geïntegreerde applicatieomgeving zou kaarten die op verschillende besturingssystemen draaien, kunnen clusteren om zo een breed scala aan realtime-eisen in te willigen, uiteenlopend van ’extreem‘ tot ’komt niet zo nauw‘. Door voor elk programma het optimale softwareplatform op te nemen, hoeven ontwikkelaars OS‘en niet in te zetten voor toepassingen waar ze niet voor bedoeld zijn. Zo hoeven ze niet te proberen een geavanceerde GUI toe te voegen aan een uitgeklede kernel die efficiënt op een hard realtime systeem draait, of zo veel functionaliteit uit het Linux-hart te verwijderen dat het zijn werk doet met missiekritische precisie.
De Amerikaanse regering denkt al weer een paar jaar vooruit. Het ministerie van Defensie schrijft open standaarden voor om apparatuur over services heen te standaardiseren (de ’common cockpit‘) en zowel hardware- als software-innovaties te realiseren zonder dat complexe systemen verouderd raken. Voor besturingssoftware begint die integratie, interoperabiliteit en standaardisatie bij een op open standaarden gebaseerde ontwikkelomgeving die elk project weer inzetbaar is, ongeacht het aantal (verschillende) OS‘en waaruit het systeem bestaat.
De beveiligings- en Posix-vereisten die de Amerikaanse regering stelt, brengen dermate complexe taken en langetermijndoelen met zich mee, dat Cots-verkopers er pas over zes tot zesendertig maanden volledig aan kunnen voldoen. Daar moeten we ons echter niet door laten ontmoedigen. Door gebruik te maken van een duurzaam, standaardgebaseerd ontwikkelpakket dat zo open is als de Defensie-normen, kunnen we vandaag al zorgen voor een convergentie van de standaarden en de systeemperformance van morgen. Geen organisatie, publiek of privaat, het leger noch Boeing, kan het zich nog langer veroorloven om huisgemaakte ontwikkeltools te ondersteunen. Met een codeomvang die zelfs bij een gemiddelde commerciële toepassing elke twee jaar verdubbelt, is de toekomst eenvoudigweg te complex.
Certificatie
Het voldoen aan regels voor veiligheid in een gemengde OS-omgeving is een van de grootste uitdagingen voor de embedded-ontwikkelaars van vandaag. Vuistregel bij certificatie op het hoogste veiligheidsniveau, DO-178B Level A, is dat daar een prijskaartje aan hangt van 50 dollar per regel code. Voor beveiliging zijn de eisen nog strenger en bovendien een stuk vager. De Evaluation Assurance Levels (EAL‘s) zoals vastgelegd in ISO-15408 (Common Criteria) beschrijven hoe een systeem op een veilige manier kan omgaan met data van verschillend veiligheidsniveaus. Hoe groter het verschil, hoe hoger het benodigde peil: een onderlinge afstand van drie vereist EAL 7, een niveau zo uitzonderlijk dat de criteria ervoor nog in ontwikkeling zijn. Tot nu toe is niemand ter wereld nog hoger gekomen dan EAL 4.
We zien dat steeds meer Cots-verkopers overgaan tot certificatie. Het bijbehorende proces is echter duur en tijdrovend. Het kunnen aangeven waar een product op dit moment aan de regels voldoet, waar dat binnenkort het geval zal zijn en waar het nog tekortschiet, is al een oefening in engineeringintegriteit op zich.
Vanwege hun wortels in open source ontberen de huidige Linux-distributies de documentatie die nodig is voor high-level veiligheidsevaluaties. De bestaande commerciële RTOS‘en hebben de eerste stappen op weg naar de hoogste niveaus van dataseparatie al wel gezet en zullen zich sterk in die richting blijven ontwikkelen. Deze scheiding onderstreept nog maar eens hoe belangrijk het is om het beste OS te kiezen voor het gebruik dat we voor ogen hebben.
De compatibliteitsissues die gepaard gaan met een gemengde OS-omgeving tackelen we zoals ontwikkelaars de problemen rond mixed-language programmeren hebben opgelost. De nadruk ligt daarbij op het bereiken van een gelijkwaardige integratie op elk gebruikt besturingssysteem. Tevens is het belangrijk om de interprocescommunicatie te verzorgen en de netwerkbeveiliging te regelen op een manier die zowel strikt is als inventief.