Home>Berichten>Industriële IoT, Techniek uitgelegd>Real-time besturingssystemen verkennen

Real-time besturingssystemen verkennen

By ·Categorieën: Industriële IoT, Techniek uitgelegd·Published On: oktober 24th, 2016·3,6 min read·

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.

Real Time Spectrum

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

Find a hardware platform at onlogic.com graphic

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”.

Understanding MTBF White Paper by Logic Supply

Ontvang de laatste Tech Updates

Abonneer je op onze nieuwsbrief en ontvang updates van OnLogic. Hoor als eerste OnLogic nieuws en inzichten van onze experts. Meld je aan op de inschrijfpagina.

Inschrijven

Delen

About the Author: Darek Fanton

Darek is the Communications Manager at OnLogic. His passion for both journalism and technology has led him from the newsrooms of local papers to the manufacturing floor of IBM. His background in news gathering has him always on the lookout for the latest in emerging tech and the best ways to share that information with readers. In addition to his affinity for words, Darek is a music lover, juggler and huge fan of terrible jokes.
Volg OnLogic op LinkedIn

DELEN

Heb je een project? Neem contact op

Meer artikelen