Architecture OCCOX
La plateforme OCCOX a été conçue pour implémenter des dispositifs industriels pouvant fonctionner à ultra basse consommation. Le prix de revient de ces dispositifs est en général faible devant leur coût de déploiement. Il est donc fondamental de leur assurer une fiabilité et une longévité importante. Cela permet de limiter les interventions après installation.
Ce choix nécessite :
- de disposer de sources d'énergie stockée ou de sources de production d'énergie "naturelles",
- d'utiliser une architecture matérielle adaptée,
- d'utiliser un modèle de programmation spécifique.
L'architecture OCCOX a alors été imaginée pour aider la conception de dispositifs satisfaisant ces contraintes.
Architecture matérielle : Symmetric MultiProcessing
Un module OCCOX, dont chaque carte est un élément, est une architecture dite Symmetric MultiProcessing constituée d'un ensemble de processeurs (micro-contrôleurs en ce qui concerne OCCOX) indépendants les uns des autres. Aucun processeur n'est le maître. Cette architecture introduit de la redondance, elle permet des modes de fonctionnement dégradés. Ainsi, si au sein d'un module, un des processeurs tombe en panne, le module peut continuer sur des fonctionnalités réduites. Ainsi, chaque carte possède son propre processeur.
Elle permet un fonctionnement inter-cartes totalement asynchrone favorable à une très basse consommation en énergie.
Architecture logicielle
Un logiciel firmware est typiquement event-driven. L'environnement du processeur change d'état de temps en temps et chaque changement d'état constitue un événement (associé au mécanisme d'interruption du processeur) auquel le firmware doit réagir. Le modèle théorique associé à un logiciel event-driven est une machine à états finis.
On constate très rapidement qu'il ne suffit pas de rassembler des composants à très basse consommation pour obtenir un équipement (module) à très basse consommation. En fait, les composants dit "à basse consommation" possède des modes de repos pendant lesquels ils consomment effectivement très peu d'énergie mais qu'ils consomment "normalement" lorsqu'ils sont actifs. Le modèle de programmation utilisé doit donc permettre de détecter et d'exploiter tous les instants où les composants de l'équipement peuvent être endormis.
Une machine à état finis est un système qui passe l'essentiel de son temps à "attendre un événement" ; ces temps d'attente peuvent être associés à un endormissement du processeur.
Les performances du firmware vont dépendre de la méthode utilisée pour implémenter la machine à état finis décrivant l'application.
Bare Metal : implémentation directe
L'impémentation directe est celle qui donnera les meilleures performances. Cependant, cette implémentation est plus difficile à mettre en œuvre et va demander le plus de temps lors de sa mise au point.
Cette méthode est à priviligier si :
- la mémoire est à économiser,
- de l'ultra basse consommation est souhaitée.
Noyaux adaptés : implémentation assistée
La gestion des événements peut être prise en charge par des noyaux spécifiques. Ces noyaux prennent en charge la collecte des événements et leur association aux handlers correspondant. Une fois acquise la connaissance de leur utilisation, le développement est plus rapide. Les performances ultimes ne seront cependant pas atteintes.
Deux noyaux :
-
AvrX : " AvrX is a Real Time Multitasking Kernel written for the Atmel AVR series of micro controllers. AvrX contains approximately 40 API in the following Six categories:
- Tasking,
- Semaphores,
- Timer Management,
- Message Queues,
- Single Step Debugging support,
- Byte FIFO support with synchronization.
The Kernel is written in assembly. Total kernel size varies from ~500 to 700 words depending upon which version is being used. Since the kernel is provided as a library of routines, practical applications take up less space because not all functions are used. "
- TinyOS : " TinyOS is an open source, BSD-licensed operating system designed for low-power wireless devices, such as those used in sensor networks, ubiquitious computing, personal area networks, smart buildings, and smart meters. A worldwide community from academia and industry use, develop, and support the operating system as well as its associated tools, averaging 35,000 downloads a year. "
- FreeRTOS : " It's probably safe to say at this point that FreeRTOS goes through more 'peer-review' than any other RTOS available on the planet. I have used it in several projects - one of which was a multiprocessor environment that used more than 64 processors and needed to run for months reliably. The FreeRTOS core performed well. Take FreeRTOS for a spin. " — John Westmoreland