Real-time besturingssystemen verkennen

In de jaren tachtig had logistiek dienstverlener Federal Express (nu FedEx) een geweldige tv-reclame om hun volgende-dag-bezorgservice onder de aandacht te brengen. De reclame eindigde met de slogan: “Federal Express. Als het er absoluut zeker de volgende ochtend moet zijn”. Dit geldt eigenlijk ook voor Real-time Operating Systems (RTOS). Net als FedEx zijn ze bedoeld om levering van bits volgens een exact schema te garanderen. Maar net als FedEx is RTOS niet in elke situatie de beste keuze. Algemene besturingssystemen, zoals Windows of Linux, zijn prima voor de meeste activiteiten. Net zoals de meeste pakketten prima via de post verstuurd kunnen worden.

Het verschil is dat een RTOS is ontworpen om ervoor te zorgen dat elke toepassing, elke service, elk bericht en elke taak en thread wordt afgehandeld op een manier die onmiddellijke, consistente en verzekerde uitvoering garandeert. Een concept dat bekend staat als determinisme. Multithreading en multitasking zijn twee kernconcepten in besturingssystemen voor algemene doeleinden. In een RTOS worden deze op een andere manier afgehandeld. Zo kunnen programmeurs exact bepalen welke programmatische elementen prioriteit krijgen in de wachtrij en hoe het systeem reageert als het zwaar belast is. Het resultaat: de belangrijkste zaken worden telkens afgehandeld volgens een strak gedefinieerd tijdschema. Denk hierbij bijvoorbeeld aan de real-time verwerking van en de reactie op druk- en temperatuurgegevens in een kerncentrale. 

Eigenlijk bestaan er twee soorten RTOS: harde real-time besturingssystemen en zachte real-time besturingssystemen. De meest veeleisende scenario’s vragen om harde real-time besturingssystemen.

• Harde real-time: Deze zijn ontworpen om te garanderen dat reactiedeadlines altijd worden gehaald. Een gemiste deadline wordt beschouwd als een totale systeemstoring.
• Zachte real-time: Zijn geoptimaliseerd om reactiedeadlines te halen. Een gemiste deadline leidt tot steeds slechter wordende systeemprestaties. Dit kan leiden tot een systeemstoring als deadlines herhaaldelijk worden gemist.

Wanneer heb je een RTOS nodig?

De meeste RTOS-toepassingen vallen in twee brede categorieën: reactie op gebeurtenissen en een gesloten regelkring. Een goed voorbeeld van het eerste is een kwaliteitscontroletoepassing in een fabriek. Daar leggen camera’s onderdelen op een lopende band vast. Zo worden defecten optisch herkend en kan een herstelproces worden gestart. Het systeem kan een complexe gebeurtenis herkennen en in een zeer kort tijdsbestek actie ondernemen. In het geval van een gesloten regelkring is er sprake van voortdurende monitoring en controle. Denk aan een koelsysteem dat voortdurend druk- en stroomwaarden meet en klepinstellingen dynamisch aanpast om binnen vastgestelde limieten te blijven.

De opkomst van het Industrial Internet of Things (IIoT) heeft geleid tot een nieuwe generatie apparaten. Met behulp van RTOS-raamwerken is effectieve besluitvorming en procesautomatisering mogelijk. Naarmate embedded systemen steeds “slimmer” worden, ontstaat er een behoefte aan een steeds grotere mate van autonomie. Daardoor is real-time besluitvorming een wezenlijk onderdeel geworden van efficiënt hardwarebeheer. De apparaten in een IIoT-omgeving moeten niet alleen met elkaar kunnen communiceren. Ze moeten ook net zo snel gegevens naar de cloud (of de fog, zoals we in een volgend artikel zullen toelichten) kunnen doorsturen en kunnen ontvangen. Real-time omgevingen worden steeds meer de ideale oplossing voor netwerkbeheerders en automatiseringsprofessionals binnen Industry 4.0.

Zijn er nadelen aan een RTOS?

Net als aan de volgende-dag-spoeddienst van FedEx, hangt er ook een prijskaartje aan RTOS. Deze strak georganiseerde en aangepaste systemen missen de aantrekkelijke kanten van besturingssystemen voor algemene doeleinden, zoals Windows en veel versies van Linux. Bovendien moet de software die ontwikkelaars voor een RTOS schrijven, met uiterste precisie zijn gemaakt. Anders leidt dit tot ernstige fouten. Denk aan het ruimtevaartuig, de Mars Pathfinder, die vlak na de landing in 1997 een reeks systeemresets onderging als gevolg van een prioriteitsinversiefout in de RTOS-toepassingscode, geschreven door Jet Propulsion Laboratories. Het team had het geluk dat het de fout in zijn laboratoria kon reproduceren en een programma in C kon uploaden om het conflict op te lossen. Op de website Microsoft Research staat een geweldig verslag van dit incident.

RTOS-producten, zoals QNIX Neutrino, Wind River VxWorks en Microsoft Windows Embedded Compact (voorheen Windows CE) zijn krachtige tools die veeleisende consistentie in bedrijfskritische omgevingen mogelijk maken. Ze zijn echter niet geschikt voor elke taak. Dat gezegd hebbende, is RTOS misschien de juiste keuze als het er metaforisch gesproken “absoluut zeker de volgende ochtend moet zijn”.