Un RTOS pour les gouverner tous

C’est toujours bien d’avoir le choix, mais quand il s’agit de systèmes d’exploitation en temps réel (RTOS), il y en a tout simplement trop ! Si vous avez déjà pris le temps de rechercher sur le Web, vous constaterez qu’il existe plus d’une centaine de RTOS différents ! Certains sont généraux, d’autres essaient de se différencier par secteur comme l’IoT. D’autres prétendent qu’ils sont meilleurs parce que ce sont des produits commerciaux tandis que les produits open source prétendent qu’ils sont gratuits et tout aussi bons que les produits commerciaux. Demandez à trois ingénieurs quels sont leurs choix RTOS et vous constaterez probablement qu’ils ont tous un favori différent.

J’ai toujours été un grand fan du Seigneur des Anneaux, avec un seul anneau pour les gouverner tous. Ne serait-ce pas bien s’il n’y avait qu’un seul RTOS ? La réponse est en fait NON ! L’espace des systèmes embarqués est tout simplement trop diversifié pour créer un seul RTOS qui répondrait aux besoins de tout le monde. Les personnes travaillant dans des logiciels critiques pour la sécurité voudraient un déterminisme robuste et étanche au laser où les développeurs commerciaux seraient heureux de répondre aux besoins en temps réel souple et considéreraient le déterminisme robuste comme exagéré. Il n’y aura jamais un seul RTOS pour les gouverner tous, mais que se passe-t-il si le RTOS lui-même ressemble davantage aux anneaux de puissance et qu’une couche d’abstraction du système d’exploitation (OSAL) est l’unique anneau ?

Diriger le RTOS via les OSAL

Les OSAL sont un outil incroyablement utile que les développeurs peuvent exploiter pour extraire le RTOS spécifique qu’ils ont choisi. Un OSAL est essentiellement une interface générique qui peut être utilisée pour interagir avec et contrôler un nombre quelconque de RTOS existants. Si un développeur aime FreeRTOS, il enveloppe simplement les API FreeRTOS avec l’OSAL. Si un autre développeur souhaite utiliser ThreadX, uC OS III ou un autre RTOS, il enveloppe simplement les appels RTOS avec l’interface OSAL.

Il y a en fait pas mal d’avantages à utiliser un OSAL. Premièrement, l’OSAL permet aux développeurs de découpler leur code d’application du RTOS. Avec autant d’options disponibles et de nombreuses entrées et sorties de style, les équipes ne devraient pas écrire leurs applications autour d’un RTOS. Le RTOS n’est qu’un composant ou un outil et moins il y a de dépendance au RTOS dans l’application, mieux c’est ! Un exemple parfait pourrait être celui où un RTOS est utilisé pendant la validation de principe car il est gratuit tandis qu’une version certifiée de sécurité peut être utilisée pendant le développement et la production. Avec un OSAL en place, il n’est pas nécessaire de réécrire le code de l’application, il suffit de rediriger l’interface OSAL vers l’autre RTOS et de recompiler.

Deuxièmement, l’OSAL permet à un développeur de concevoir son logiciel sans se soucier du RTOS utilisé. Un architecte logiciel souhaite travailler avec des détails abstraits afin de pouvoir se concentrer sur l’architecture et les règles métier de l’application. Les détails essentiels du RTOS sont donc poussés derrière l’OSAL et deviennent un détail d’implémentation auquel les architectes d’application n’ont pas besoin de penser. (Oui, cela limite l’utilisation de fonctionnalités spécifiques au RTOS, mais pour une conception d’architecture évolutive et flexible, nous transmettons ces détails aux implémenteurs).

Enfin, avec le RTOS derrière l’OSAL, cela facilite grandement le test et la simulation du logiciel. Lorsqu’un RTOS est étroitement couplé à l’application, les développeurs doivent trouver comment faire fonctionner le RTOS sur un serveur d’intégration continue et comment le faire se comporter correctement lors des tests de simulation et d’intégration. Avec l’OSAL, le comportement peut être beaucoup plus facilement moqué, ce qui peut aider à gagner du temps mais surtout empêcher les niveaux de stress des développeurs d’atteindre des niveaux critiques.

Conclusion

Il n’y aura jamais un seul RTOS utilisé par tout le monde dans l’industrie des systèmes embarqués. Le mieux que nous puissions espérer est que les développeurs de l’industrie des systèmes embarqués adoptent un seul OSAL qui agisse comme une interface standard pour toute application embarquée. Il existe des OSAL potentielles telles que CMSIS-RTOS v2 pour les utilisateurs d’Arm et quelques autres spécifiques aux fournisseurs de microcontrôleurs. Je n’ai pas encore l’impression que les équipes de développement les adoptent comme elles le devraient.

Un OSAL est avantageux car il permet aux développeurs d’écrire leurs applications sans avoir à sélectionner immédiatement le RTOS qu’ils utiliseront. Ils peuvent simuler le comportement d’un RTOS générique et écrire leur code d’application, voire le tester tout en retardant le RTOS spécifique qu’ils utiliseront jusqu’à la phase de mise en œuvre de leur projet. L’OSAL est ce qui se rapproche le plus d’un seul RTOS pour les gouverner tous.