Ma règle générale est que vous devriez envisager un système d'exploitation si le produit nécessite un ou plusieurs des éléments suivants: une pile TCP / IP (ou une autre pile réseau complexe), une interface graphique complexe (peut-être une avec des objets GUI tels que des fenêtres et des événements ) ou un système de fichiers.
Si vous avez fait du codage à nu, vous connaissez probablement l' architecture du programme de super-boucle . Si les exigences du micrologiciel du produit sont suffisamment simples pour être implémentées avec une super-boucle maintenable (et, espérons-le, quelque peu extensible), vous n'avez probablement pas besoin d'un système d'exploitation.
À mesure que les exigences logicielles augmentent, la super-boucle devient plus complexe. Lorsque les exigences logicielles sont si nombreuses que la super-boucle devient trop complexe ou ne peut pas répondre aux exigences en temps réel du système, il est temps d'envisager une autre architecture.
Une architecture RTOS vous permet de diviser les exigences logicielles en tâches. Si cela est fait correctement, cela simplifie la mise en œuvre de chaque tâche. Et avec la hiérarchisation des tâches, un RTOS peut faciliter la satisfaction des exigences en temps réel. Un RTOS n'est cependant pas une panacée. Un RTOS augmente la complexité globale du système et vous ouvre à de nouveaux types de bogues (tels que les blocages). Comme alternative au RTOS, vous pouvez envisager une architecture de machine d'état basée sur les événements (telle que QP ).
Si votre produit possède un réseau, une interface graphique complexe et un système de fichiers, vous pourriez être au point où vous devriez envisager des systèmes d'exploitation complets tels que VxWorks, Windows ou Linux. Les systèmes d'exploitation complets comprendront des pilotes pour les détails de bas niveau et vous permettront de vous concentrer sur votre application.