Accueil » Logiciel Enfoui » PXROS – Real-time OS pour TriCore et AURIX

PXROS
Système Temps-Réel pour TriCore et Aurix

Logo PXROSPXROS est un système d’exploitation en temps réel (RTOS) orienté objet doté d’un micro-noyau très moderne et de caractéristiques exceptionnelles. Il est particulièrement adapté au déploiement sur des MCU multicœurs avancés. Avec la dernière version de PXROS-HR, il améliore les concepts d’encapsulation et de robustesse. En effet, il utilise des mécanismes de protection matérielle à granularité fine (MPU), disponibles dans les micro-contrôleurs modernes comme l’AURIX.

Certification SIL3 PXROS-HRLe système d’exploitation PXROS-HR pour TriCore a été officiellement homologué en matière de sécurité. HighTec a reçu le certificat confirmant l’aptitude de PXROS-HR pour les applications liées à la sécurité jusqu’à SIL 3 (IEC61508) et ASIL D (ISO 26262), valable de février 2019 à février 2024.

PXROS_TriCore_multi-core_support

La certification comprend un rapport d’évaluation contenant les résultats de l’évaluation de l’autorité de certification, TÜV-Nord Systems GmbH & Co. KG.

PXROS-HR est développé avec le compilateur HighTec C/C++ pour TriCore/AURIX. Il convient parfaitement aux applications industrielles, ainsi qu’aux applications automobiles où la sécurité est essentielle. En particulier, le RTOS s’intègre aux frameworks logiciels MCAL et SafeTlib d’Infineon. De plus il n’est pas basé sur AUTOSAR et il est hautement optimisé pour l’architecture TriCore. Ainsi, il supporte les multi-cœurs de la famille AURIX.

Introduction au RTOS

PXROS-HR (High Reliability) est le successeur du micro-noyau temps réel original PXROS, qui a été développé pour la première fois en 1983. Celui-ci est utilisé avec succès depuis 1985 sur des milliers d’applications/appareils différents. Trois objectifs de conception très importants avaient été fixés pour le PXROS original, qui ont été pleinement atteints :

  • Un excellent comportement en matière d’interruptions (pas de verrouillage des interruptions !).
  • La philosophie du système d’exploitation conduit à une bonne structure et à une clarté architecturale.
  • Comportement extrêmement robuste sous forte charge

L’un des principes les plus importants qui sous-tendent PXROS est l’encapsulation des informations et des activités.

Ces deux éléments contribuent à améliorer la fiabilité et la protection contre les interférences involontaires ou malveillantes. Les activités (tâches au sens de processus) vivent dans des capsules et ne peuvent communiquer qu’en échangeant des objets de message et des signaux. Les processus de ce type ne connaissent que les objets nécessaires à l’accomplissement de leur tâche et se comportent de manière à affecter le moins possible le reste du système. Par exemple, ils ne devraient jamais utiliser de verrous d’interruptions durs, car cela pourrait détruire les hypothèses concernant le comportement du timing à d’autres endroits. Les ressources doivent être utilisées de manière à ce qu’un goulot d’étranglement local n’ait pas d’effets globaux.

Support PXROS_TriCore-MPU

L’API PXROS offre l’ensemble des services nécessaires pour atteindre les objectifs mentionnés ci-dessus. Cette API permet également d’émuler les API de nombreux autres systèmes d’exploitation. Dans PXROS-HR, les principes d’encapsulation sont garantis par des contrôles automatiques effectués par l’AURIX MPU. L’AURIX MPU se comporte comme un comparateur d’adresses qui vérifie les limites des adresses. PXROS-HR gère la MPU AURIX et s’assure qu’un accès illégal aux données par une tâche sera immédiatement détecté à l’exécution par la MPU, et que toute propagation d’erreur sera évitée. Si une tâche est planifiée, PXROS-HR changera la configuration du MPU de la tâche correspondante.

Tâches et handlers

Parce que de nombreuses applications techniques exigent des réactions rapides à certains événements, PXROS met en œuvre le concept de transparence complète des interruptions. C’est-à-dire que PXROS ne change jamais l’état du système d’interruption du microcontrôleur. Cette caractéristique permet de réaliser un démarrage à chaud avec PXROS. Ainsi, il n’y a pas de verrou d’interruption causé par PXROS et les services d’interruption peuvent toujours interrompre PXROS. Alors, le RTOS gère uniquement les ressources temporelles restantes d’une boucle principale. En raison de la transparence des interruptions, les applications existantes sans OS peuvent facilement être portées sur PXROS-HR.  Ainsi que les OS qui sont partiellement ou totalement implémentés au niveau des interruptions. Comme la gestion des interruptions n’est pas “prédéfinie” ou interférée par le micro-noyau, l’application peut mettre en œuvre toute vérification nécessaire ou raisonnable pour l’activité liée aux interruptions.

Dans la terminologie PXROS, les routines de service d’interruption sont appelées handlers, qui, en principe, sont complètement sous le contrôle de l’application. Mais ils  peuvent néanmoins utiliser un sous-ensemble de services PXROS. Ces services sont gérés d’une manière spéciale, afin de minimiser la surcharge liée à PXROS au niveau des interruptions.
Un gestionnaire peut, par exemple, envoyer des signaux (événements) à une tâche. Ce service n’est pas exécuté au niveau de l’interruption, mais est inséré dans une liste à la place. Ensuite, ce service est exécuté avant de revenir du niveau des interruptions au niveau des tâches. Cela se fait à temps, car la prochaine tâche à exécuter doit être déterminée avant de quitter le niveau des interruptions.

Gestion interruption PXROSL’utilisation de handlers garantit un temps de réponse optimal (comme sans système d’exploitation), mais à l’exception du niveau d’interruption le plus élevé, elle a des effets sur les autres interruptions. Les actions au sein d’une tâche n’ont aucun effet sur le système d’interruption, mais l’ordonnancement des tâches et la communication génèrent une certaine surcharge. Il est donc vital pour les performances globales d’une application de trouver un bon équilibre entre l’exécution des parties de l’application basée sur les handlers et sur les tâches.

Dans la philosophie de PXROS, un handler appartient toujours à une tâche et à son espace d’adressage. Cela signifie que dans PXROS-HR, les handlers seront contrôlés par le MPU. Les handlers et la tâche correspondante ont une relation comme les interruptions à la boucle principale.

Dans les systèmes PXROS – configurés dynamiquement (une configuration statique est également possible), les tâches sont responsables de l’installation et de la désinstallation des gestionnaires correspondants. Ce concept permet la configuration et la reconfiguration dynamiques d’un système en fonctionnement.

Le micro-noyau PXROS-HR est exécuté en mode superviseur et gère l’unité de protection de la mémoire du contrôleur. Les tâches et les gestionnaires sont exécutés en UserMode-0 ou UserMode-1. En UserMode-1, l’accès aux périphériques et au système d’interruption est activé. Dans le UserMode-0 restreint, le code peut être exécuté, mais l’interruption et les périphériques ne sont pas accessibles. Des services spéciaux de PXROS-HR permettent un accès sélectif aux périphériques en UserMode-0.

Le mode superviseur et les modes utilisateurs utilisent des ensembles séparés de registres de protection. Ceux-ci sont commutés automatiquement par le matériel TriCore sans surcharge. Si le noyau PXROS-HR est actif, le noyau restreint son accès à l’objet qui doit être modifié.

Contrôle des ressources

En matière de sécurité et de robustesse, il est très important d’éviter les goulets d’étranglement ou du moins de limiter leurs effets globaux. Pour cette raison, les ressources sont soumises à des quotas. Ainsi, chaque tâche possède des comptes, desquels sont déduites les ressources consommées 

Base Memory Layout PXROS

– allocation de mémoire statique et dynamique – ou auxquels sont réaffectées les ressources libérées. Cela signifie également que les objets sont soit libres (inutilisés), soit affectés à une tâche.

Tous les objets spéciaux (boîtes aux lettres, classes de mémoire, pools d’objets, objets de messages) sont créés à partir d’objets “universels” libres pris dans les pools d’objets et redeviennent des objets “universels” lorsqu’ils sont libérés.Cela signifie notamment que, tant que des objets libres sont disponibles, des objets de toute nature peuvent être créés et supprimés pendant l’exécution. Chaque tâche reçoit de la mémoire et des objets de son créateur. Avec des quotas appropriés, les goulets d’étranglement de la mémoire et des objets peuvent être limités à la tâche ou au sous-système concerné. De plus il est possible de construire des systèmes partiellement dynamiques sans que les goulets d’étranglement n’aient d’effets compromettants sur les fonctions vitales du système global.

Signalisation et communication

PXROS permet l’interaction entre les gestionnaires et les tâches et entre les tâches via des événements et des objets-messages. Les événements sont de courts messages implémentés comme des champs de bits, pour lesquels les tâches peuvent attendre sélectivement à l’aide d’un masque de bits, indiquant lequel des bits doit terminer l’état d’attente. Les objets messages consistent en une description d’objet accessible uniquement par le système d’exploitation et la zone de données correspondante.

La description de l’objet contient également l’information sur la tâche qui utilise actuellement l’objet. De plus, il existe des éléments de liaison permettant de lier l’objet à une boîte aux lettres (liste), de sorte qu’une boîte aux lettres peut recevoir un nombre arbitraire de messages. Si l’objet est envoyé, il quitte l’espace d’adressage de l’expéditeur et devient partie intégrante d’une boîte aux lettres.

La réception d’un objet d’une boîte aux lettres supprime l’objet de la boîte aux lettres et l’assigne à l’espace d’adresse de la tâche de réception. Un service PXROS supplémentaire est alors requis par la tâche de réception pour obtenir un pointeur vers la zone de données. Si le microcontrôleur (par exemple AURIX) dispose d’une protection mémoire appropriée, PXROS-HR peut se protéger, ainsi que tous les objets gérés, contre les accès erronés et illégaux.

Communication PXROSL’envoi d’un message ou d’un événement est asynchrone et l’instance d’envoi ne doit pas supposer que l’effet de ces opérations sera immédiat. La synchronisation doit être faite explicitement.

Dans PXROS-HR, le contenu des messages est protégé par le MPU, ce qui conduit au plus haut niveau d’encapsulation des données et permet d’atteindre un haut niveau de sécurité.

Pour une mise en œuvre propre de ce concept de protection des objets, le microcontrôleur doit disposer d’une unité de protection de la mémoire (MPU) appropriée avec une granularité fine telle que l’AURIX . Sans une MPU appropriée, il y a soit un compromis dans la sûreté et la sécurité, soit une utilisation excessive des ressources. Contrairement à la communication basée sur les sémaphores, le passage d’objet par message comme dans PXROS signifie un transfert atomique de la référence et des droits d’accès. Il est possible de garantir qu’à tout moment, un objet ne peut être utilisé ou modifié que ( !) par une seule instance. Les objets communs peuvent encore être manipulés en toute sécurité s’ils sont stockés (déposés) dans une boîte aux lettres actuellement non utilisée par d’autres instances. Tout comme les autres objets, les boîtes aux lettres peuvent être créées et supprimées dynamiquement.
PXROS permet l’attente simultanée d’objets messages et d’événements

Mécanisme général d'abandon

Tous les services conduisant éventuellement à un état d’attente peuvent être interrompus par des événements. De plus, une fonction arbitraire peut être appelée de manière à ce qu’elle soit soumise à l’arrêt via des événements sélectionnés. Cela peut être utile dans les cas où le calcul doit être limité dans le temps (problèmes de convergence) ou pour d’autres raisons importantes telles que des situations de panne de courant.

Gestion du timing

Objets temporels PXROS

PXROS est complètement piloté par les événements et n’a donc pas besoin de tic-tac pour son fonctionnement interne. Comme les temporisations logicielles sont souvent nécessaires ou utiles, PXROS offre des “delay-jobs” comme mécanismes de temporisation de base. Un delay-job permet l’exécution de fonctions définies par l’utilisateur (avec des paramètres) après un nombre donné de ticks. La période de ticks et donc la granularité du temps sont définies par l’application. Les delay-jobs sont exécutés en tant que handlers au niveau d’interruption de la source de tick. La base de temps de ces soft timers peut bien sûr être sujette à une gigue si des interruptions supérieures existent.

Comme indiqué, PXROS, en tant que micro-noyau contrôlé par des événements, n’a pas besoin d’événements de synchronisation, mais il supporte le découpage temporel si des ticks sont disponibles..

Conséquences de l'amélioration de la puissance de calcul

Les mesures de sûreté et de sécurité augmentent souvent les besoins en temps et en espace. Dans le passé, cela se traduisait par des compromis en matière de sécurité ou de performance. Avec les microcontrôleurs modernes à haute performance tels que le TriCore, des approches propres et une encapsulation stricte deviennent possibles avec une surcharge minimale. Dans PXROS-HR, les frais généraux pertinents pour l’encapsulation des tâches et le transfert d’objets de message sont constitués du temps nécessaire pour une opération d’envoi et de réception avec ordonnancement des tâches.

La redondance, le vote, la diversité et d’autres avantages sont désormais possibles même pour les processus rapides. En outre, les instances de contrôle peuvent être insérées de manière transparente dans le flux de données et de contrôle.

Pour en avoir plus

Vous trouverez plus d’informations sur la page PXROS-HR du site de HighTec.

Votre nom
Numéro de Tel:
Société