Couverture ElectroniqueS n°127

Au-delà de la spécificité de base d'un OS temps réel, à savoir le déterminisme, les caractéristiques des téléphones 3G imposent au système d'exploitation des garanties supplémentaires en termes de fiabilité et d'efficacité. Enea Embedded Technology détaille les mécanismes clés requis par le RTOS embarqué dans un mobile. Un téléphone mobile de troisième génération est un produit complexe qui intègre souvent plusieurs types de processeurs différents (Risc, DSP) sur lesquels fonctionnent un ou plusieurs systèmes d'exploitation (voir l'article de « Tendance » dans Electronique n°140, p. 48). Parmi ces OS, il en est un qui est incontournable, c'est le système d'exploitation temps réel (RTOS), utilisé seul ou en complément d'un système généraliste. En effet, les exigences au niveau de la gestion des signaux radio, de la bande de base de la pile de protocole, du codage/décodage de la voix et du contrôle général du téléphone mobile ne peuvent être satisfaites qu'avec un système temps réel. Les mécanismes intimes de celui-ci doivent alors être examinés, car c'est d'eux que dépend le respect des contraintes de communication strictes imposées aux plates-formes de téléphonie mobile de 3e génération. Ces mécanismes sont détaillés ici pour le noyau Ose, dont l'une des principales caractéristiques est d'utiliser la technologie du passage de message direct pour la partie communication entre tâches logicielles (Electronique n°112, p. 67).Le partitionnement logiciel est une des méthodes mises en &oelig;uvre pour atteindre un bon niveau de robustesse d'un produit. Il s'agit de concevoir l'application de façon modulaire, la caractéristique principale étant ici l'indépendance des différents modules entre eux. Dans un système multitâche, les « process » (également appelés « threads » ou « tâches ») qui s'exécutent de manière concurrente offrent de manière intrinsèque un premier niveau d'indépendance. Permettre de regrouper ces « process » dans des unités d'exécution basiques ou unités logiques apporte un niveau de partitionnement supplémentaire (ces unités logiques sont appelées « blocs » au sein du noyau Ose). L'avantage en termes de stabilité logicielle est que l'on peut appliquer de nombreuses caractéristiques au niveau d'une unité logique, comme démarrer ou arrêter l'ensemble des process de l'unité ou encore affecter à une unité un « pool mémoire » séparé (un « pool mémoire » est une zone d'adresses réservées, connue à l'avance, allouée à chacun des process). Ainsi, les données relatives à des fonctions différentes peuvent être aisément isolées dans des zones mémoire séparées.De plus, malgré ce partitionnement, la communication par messages entre les différentes unités logiques du programme reste simple, et la possibilité de pouvoir rediriger des messages à l'intérieur même d'une unité augmente la flexibilité de l'architecture logicielle et la facilité de conception du programme (figure 1).La protection mémoire est un mécanisme de base en termes de fiabilité logicielle. Elle évite des situations catastrophiques résultant de la corruption de certaines zones mémoire. Si une application est défectueuse, on tolère que son exécution soit compromise, mais il est inacceptable que ce dysfonctionnement s'étende à d'autres applications, voire au système dans son ensemble. Par conséquent, la prise en charge par le système d'exploitation des mécanismes matériels de protection mémoire (MMU, Memory management unit) est essentielle pour renforcer le partitionnement logiciel. En effet, en créant des domaines mémoire distincts, la séparation logicielle des données en pools mémoire séparés devient une protection physique grâce à la MMU.Inconvénient : lorsqu'on décide de tirer parti des mécanismes de protection mémoire, on perd en flexibilité et en facilité de conception. En effet, dans ce cas la synchronisation entre les process n'est plus assurée en raison de la « barrière physique » imposée par la MMU. La communication entre « process » (IPC, interprocess communication) par passage de message direct constitue ici une réponse idéale à ce phénomène, dès lors que la « transparence » du mécanisme est garantie. En effet, l'IPC reste indépendante du partitionnement et permet aux applications de communiquer de façon protégée sans avoir à se soucier de leurs localisations respectives, à savoir à l'intérieur du même domaine mémoire ou non (figure 2).La gestion des erreurs (error handling) est aussi un pilier de la fiabilité d'un système. Elle permet la mise en place d'une politique de retour à l'état nominal en cas de dysfonctionnement. La détection des erreurs est réalisée par le système d'exploitation à l'aide de tests effectués soit régulièrement, soit en fonction des appels système. Un appel système ne retourne pas de code d'erreur à l'application, seul les appels se terminant avec succès rendant la main à l'application. Si l'appel échoue, le contrôle est automatiquement transféré vers un gestionnaire d'erreurs centralisé, accompagné d'un code erreur pour identification. Ce gestionnaire d'erreurs est implanté sur trois niveaux : « process »,« unité logique » et système. Après détection d'une erreur, le gestionnaire décide alors entre trois actions : corriger le problème, terminer le « process » en appelant ou passer au niveau suivant. Comparé à des mécanismes plus classiques qui laissent la responsabilité de la gestion d'erreur à l'application, un tel mécanisme garantit qu'une erreur ne pourra être ignorée. De plus, cela permet de libérer l'application du traitement d'erreur, la rendant ainsi plus lisible et donc plus facilement maintenable (figure 3).La supervision des « process » et des programmes est un élément essentiel dans un système dynamique comme un téléphone 3G : les différents programmes ou applications clientes, comme un jeu ou un fichier MP3, doivent s'arrêter ou démarrer en fonction des actions demandées par l'utilisateur ou bien selon les impératifs du contrôle interne du système. Dans ce cas de fonctionnement typique d'une architecture client/serveur, le serveur a besoin d'être informé de la disponibilité des clients et, plus encore, si un client n'est pas disponible, le serveur a besoin de savoir quand il le sera de nouveau. Si des mécanismes de supervision sont intégrés au système d'exploitation, alors la gestion de tels comportements dynamiques se trouve facilitée. Les éléments de base d'une supervision dynamique sont la notification automatique et la recherche. N'importe quelle application (client ou serveur) peut demander explicitement la supervision d'une autre application. Si l'application supervisée devient indisponible, le système d'exploitation envoie alors automatiquement une notification, exprimant cette indisponibilité à ceux qui l'ont demandée. Le mécanisme de recherche (Hunt) est ensuite utilisé pour trouver de nouveau les applications recherchées après leur indisponibilité. La puissance d'un tel mécanisme est sans limite. Il permet, par exemple, à un serveur de superviser plusieurs de ses clients (ce qui, par ailleurs, est un complément puissant au gestionnaire d'erreurs mentionné ci-dessus) et de prendre les mesures qui s'imposent si un ou plusieurs clients deviennent indisponibles.Le RTOS doit fournir des fonctions clésParmi la longue liste des fonctionnalités d'un système d'exploitation temps réel, certaines sont fondamentales pour les appareils 3G. Le support multic&oelig;ur, pour supporter à la fois Risc et DSP avec le même RTOS et la même API, élimine de fait la nécessité d'introduire un OS supplémentaire pour prendre en charge le DSP. Cet avantage devient capital dès lors que le RTOS supporte les systèmes distribués et permet ainsi de concevoir l'application dans son ensemble, sans présumer de la localisation définitive des différents process. Jusqu'aux phases de conception les plus tardives, des applications peuvent facilement être déplacées d'un processeur à l'autre.L'autre avantage majeur du support des systèmes distribués est que les process communiquent strictement de la même façon avec des process locaux (résidant sur le même processeur), des process distants (sur un autre processeur) ou même des process s'exécutant sur d'autres appareils (via une connexion Bluetooth par exemple). Les processeurs hébergeant les différents process n'ont même pas besoin d'être du même type. Dans une architecture à passage de message direct, la communication transparente entre les applications et les programmes distants peut être résolue très élégamment. La technologie qui autorise une telle transparence pour le RTOS Ose est le Link Handler (figure 4).Le chargement dynamique de programmes est sans doute la caractéristique qui va entraîner les changements les plus visibles pour l'utilisateur final. En effet, les téléphones plus anciens ne permettaient pas la mise à jour de leurs programmes, puisque toutes les fonctionnalités étaient préinstallées. Des environnements interprétés comme Java offrent des possibilités de chargement dynamique, mais celles-ci s'appliquent uniquement à des applications Java. Si la fonctionnalité de chargement dynamique est implémentée au niveau du système d'exploitation, alors toute application peut être téléchargée, qu'elle soit écrite en C, C++ ou assembleur. Ceci inclut, par exemple, les codecs multimédias et le logiciel système (figure 5).En plus des fonctionnalités propres au module de téléchargement dynamique lui-même, le système d'exploitation doit supporter quelques caractéristiques pour rendre l'opération de chargement/déchargement efficace et sûre. Tout d'abord, si le système comporte une MMU, toute application téléchargée doit bénéficier de la protection mémoire et, par exemple, être totalement isolée. Ensuite, le chargement de programme doit supporter la mémoire flash, puisqu'elle économise de la Ram et diminue la consommation d'énergie. Il doit donc être possible de télécharger directement en mémoire flash, puis d'exécuter le programme directement depuis cette flash (fonction XiP, Execute-in-Place). Puis, pour permettre aux fabricants de décider pour chaque programme quel type de mémoire utiliser, il doit être possible de sauvegarder les applications (compressées ou non) vers d'autres mémoires moins coûteuses que la flash XiP.Enfin, quand une application est stoppée, toutes les ressources utilisées par l'application doivent automatiquement être libérées par le système d'exploitation. On imagine en effet les dysfonctionnements qui pourraient résulter des zones mémoires allouées dynamiquement et non libérées, ou encore des messages adressés à des process qui auraient entre-temps disparu.Enea Embedded TechnologyEva Skoglund est responsable marketing technique chez Enea Embedded Technology. Diplômée du Royal Institute of Technology de Stockholm (Master of Science), elle a rejoint Enea il y a neuf ans. Après avoir travaillé au sein des équipes d'ingénierie, de marketing et de management produits, elle a aujourd'hui pour mission de définir et positionner les produits Ose sur le marché, pour la gamme wireless

L’OS temps réel fiabilise les radiotéléphones 3G

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

L’OS temps réel fiabilise les radiotéléphones 3G

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure