Nous suivre Industrie Techno

7 grands axes de recherche

Thierry Mahé

Sujets relatifs :

,
- Pour progresser, les systèmes embarqués requièrent un "supplément d'âme" en R&D qui va des mathématiques appliquées aux procédés de fabrication. Sept voies prometteuses.

Environnés que nous sommes par les objets technologiques, on ne réalise même plus que l'informatique n'a qu'un demi-siècle d'âge et son excroissance la plus prometteuse, les systèmes embarqués, tout au plus vingt ans d'existence. C'est dire que tout s'est développé très vite, de façon parfois confuse... Certains ratés de l'électronique automobile en témoignent. Aujourd'hui, seules les biotechnologies peuvent se comparer à l'informatique embarquée en termes d'inflorescence des travaux de recherche, d'interactions fiévreuses entre projets théoriques, applications industrielles, création de nouveaux services...

La France, avec au moins trois grands pôles moteurs (régions Rhône-Alpes, Midi-Pyrénées, Île-de-France), n'est cette fois pas à la traîne. C'est heureux car, à l'aube du déploiement des systèmes nomades, compagnons ou fantômes - qui tiennent dans la poche ou se dissimulent dans le décor - un immense besoin de recherche se fait jour.

La science des systèmes embarqués prend racine dans le corpus mathématique. Ces travaux très abstraits poursuivent la quête de la "preuve formelle" (démontrer rigoureusement que le logiciel est dénué d'erreurs) et visent à une globalisation de notre approche de ces systèmes qui marient étroitement numérique et réel. Mais, comme on va le voir ici, la R&D sur les systèmes embarqués se nourrit d'un nombre invraisemblable de nouvelles connaissances, dans des domaines comme les biotechnologies, la photonique, les procédés électroniques, les télécommunications, l'énergie. Servant à tout, les systèmes embarqués font ventre de tout.

1 Maîtriser la complexité Les approches par modèles

Naguère, les systèmes embarqués mettaient à profit des logiciels performants mais de petites tailles, utilisant peu de mémoire, centrés sur un périmètre d'action réduit et généralement produits par une seule et même équipe. On s'écarte à grand pas de cette vision ! D'abord parce que ces systèmes tendent à régir un domaine de plus en plus vaste (dans l'automobile : du "simple" ABS à l'ensemble du contrôle châssis) et aussi parce qu'ils se mettent à plusieurs afin de réaliser une fonction communicante. Aussi, le temps réel a-t-il dû se mettre en quête de méthodologies de conception rigoureuses, tant pour définir l'architecture globale et répartir les tâches, que pour assurer une interface de communication "standard" entre modules.

Cet outil d'intégration, le temps réel l'a trouvé dans UML (Unified Modeling Language, en français langage de modélisation objet unifié), qui fait consensus. Cette approche par modèles est d'abord née des langages objet afin de leur apporter la structuration qui leur faisait défaut. Et elle est aujourd'hui adoptée par une large communauté du temps réel. Dans ce domaine, un programme français fait référence, c'est le projet Caroll, démarré en 2003 sur quatre ans. Il réunit Thales, l'Inria et le CEA. Citons également le projet Eclipse (Model Driven Development Integration), issu du premier, dont est partie prenante IBM.

La philosophie "modèles" consiste à rester le plus longtemps possible dans l'abstrait afin de définir l'architecture, pour ensuite découper les tâches. Cette approche va souvent de pair avec des outils semi-automatiques de génération de codes et de vérification formelle du code généré.

Le diagramme en "V" qui définit le cycle qui va de la conception d'ensemble au test final est toujours valable : on teste selon le chemin inverse de celui utilisé pour concevoir, c'est-à-dire du particulier vers le général. Mais la démarche se trouve compliquée du fait que les modules logiciel + matériel ne reçoivent pas seulement les données d'un ordre pyramidal mais de tout l'environnement dans lequel ils sont plongés (l'ABS obéit à l'action de freiner du conducteur mais aussi à la mesure faite de l'adhérence au sol).

2 Se rendre maître du temps Le mariage du synchrone et de l'asynchrone

Intrinsèquement, le temps réel obéit à un fonctionnement asynchrone. C'est-à-dire que les processus du logiciel s'enclenchent sur apparition d'un événement, comme l'airbag lors d'une collision. En fait, le monde réel "fonctionne" de façon asynchrone, alors que les processus informatiques sont régis par un cadencement du temps. C'est pourquoi le temps asynchrone est au départ celui des automaticiens. Or, si cette approche convient fort bien à un système autonome, elle est insuffisante lorsque plusieurs systèmes embarqués se coordonnent afin de remplir une fonction globale. Par exemple, la sécurité dans l'automobile, où le freinage, la direction, le contrôle châssis, les actionneurs de l'habitacle doivent travailler de concert afin d'éviter l'accident ou d'en réduire la gravité. Or, beaucoup de systèmes embarqués, dans l'automobile en particulier, sont des systèmes dormants qui se réveillent sur un signal. Toute une famille de travaux vise donc à démontrer la stabilité d'un système qui reçoit des informations fortement échantillonnées ou totalement sporadiques.

En d'autres termes, on veut d'un système qu'il anticipe en continu sur ce qui peut survenir, afin d'apporter le moment venu la réponse la plus appropriée. Ainsi, la connaissance du tracé de la route ou de la distance au véhicule qui précède (données captées en continu, de façon synchrone) apportera un plus considérable au choix de la stratégie de freinage d'urgence (action événementielle, asynchrone).

Toute une famille de travaux tend à mettre au point l'architecture idéale qui traite aussi bien les tâches sporadiques (sur événement) que périodique (séquencement, scrutation), dans l'optique d'un système facile à valider, moins coûteux à concevoir, mais aussi moins gourmand en énergie (voir point 7). Les systèmes de plus complexes qui apparaissent sont de toute façon régis par plusieurs bases de temps : le "temps" d'un airbag n'est pas celui d'un lève-vitre. Or tous ces systèmes sont appelés à converser... Il faut "mettre de la colle" entre des temps différents.

Un projet phare, dans le domaine du synchrone, est Espresso (Environnement de spécification de programmes réactifs synchrones) que dirige Jean-Pierre Talpin, de l'Irisa (Rennes, Ille-et-Villaine). Le projet veut démontrer que « l'approche synchrone favorise la réutilisation de composants logiciels réactifs et permet de les déployer en temps et coûts minimaux, sur des systèmes distribués, et dans un cadre mathématique offrant les garanties de fiabilité maximales ».

Les architectures synchrones (ou polychrones lorsque plusieurs horloges cohabitent) ont pour elles de s'appuyer sur un très riche corpus scientifique et sur un large outillage de langages et de méthodologies. Ainsi, le projet Espresso du Léti s'appuie sur la notation BDL et met à profit les langages vedettes du synchrone que sont Esterel, Lustre ou Signal. Esterel s'est notamment fait un nom pour avoir servi à la programmation des commandes de l'Airbus A380.

Ces architectures ont un autre atout. Elles se prêtent à merveille à la vérification formelle, à la génération automatique de codes, elles acceptent les événements simultanés, etc. On peut penser que ce sont les mieux adaptées aux systèmes hypersécurisés de l'automobile, des transports en général. Ainsi, la communauté des experts de l'électronique automobile a jugé comme un réel progrès, sous l'angle de la sûreté de fonctionnement, la transition progressive entre le bus de multiplexage CAN (communication sur événement) et le réseau FlexRay qui conjugue les deux modes. Ce n'est pas un hasard si ce réseau constitue la colonne vertébrale du consortium Autosar qui ouvre l'informatique embarquée automobile aux modèles économiques de l'informatique "desktop".

Les architectures asynchrones ont pour autant de sérieux atouts. Dans ces configurations, les processeurs échangent par "poignée de main" : un processeur actif utilise un protocole pour dialoguer avec un autre, éventuellement "endormi". On ne retrouve donc pas ici cette notion de flux de données constamment alimenté que prônent les architectures synchrones. Rien que sous cet aspect, l'asynchrone est extrêmement intéressant pour baisser la consommation d'énergie, d'où le vif intérêt qu'il suscite au CEA-Léti, pour la conception de systèmes nomades ou autonomes.

Les architectures asynchrones se prêtent aussi beaucoup mieux aux procédés calculatoires puisqu'elles "admettent" qu'un calcul prend... un certain temps. C'est rendu possible au prix d'une gestion très complexe de l'ordonnancement des tâches, de leur pouvoir à s'interrompre mutuellement, et à partager des ressources communes : une donnée utilisée par un processus peut en effet avoir été modifié précédemment par un autre. Pour toutes ces raisons, les modèles asynchrones sont très difficiles à valider.

On s'en doute, une pléthore de travaux théoriques visent à unifier des modèles d'architecture totalement hybrides au regard du temps.

3 Rationaliser le développement La théorie des composants

Ce qu'on nomme la théorie des composants est dans la suite logique de l'approche par modèles : une fois qu'on a parfaitement défini l'architecture, autant construire avec des briques toutes faites, disponibles auprès du plus grand nombre et aussi rendre réutilisable les modules que l'on réalise. On pense évidemment aux librairies de fonctions d'un langage évolué. Mais dans les systèmes embarqués, un composant est beaucoup plus complexe qu'une simple procédure réutilisable. Ici, un composant est une abstraction d'un élément fonctionnel, qu'il soit logiciel ou matériel. La notion est proche de celle d'une cellule dans un organisme vivant.

Cette approche "composants" (Component-based Design) est l'un des piliers du réseau Artist, coordonné par Verimag. Ces composants présentent par nature un large degré d'abstraction par rapport aux couches matérielles et utilisent le moins possible les spécificités du système d'exploitation. L'une des approches premières dans ce domaine est celle réalisée par le laboratoire Tima de l'INPG de Grenoble. Ce système, Roses, rassemble des composants à l'aide de scripts. Le langage de description d'architecture ADL a pour but d'unifier ce "Lego" logiciel.

Cette vision, très neuve, apporte un réel progrès en matière d'adaptabilité et de réutilisabilité du logiciel. Tout l'enjeu, comme le souligne Ali Erdem Ozcan (STMicroelectronics, Grenoble) est de la faire migrer dans le monde la microélectronique pour la réalisation de systèmes sur puce.

4 Fusionner les données L'intelligence de groupe

Le "Speckled Computing Consortium" est un groupe d'universitaires britanniques qui prétend rien moins que développer des capteurs d'une taille à peine visible qu'on pourrait disséminer dans l'environnement à partir d'un spray. Autonomes en énergie, ils collecteraient et se transmettraient l'information en réseau pour constituer une véritable cartogra-phie de la mesure. Quelle que soit la nature de cette mesure ! Le niveau de sécheresse dans un champ, l'usure d'une pièce mécanique très sollicitée ou la pression sanguine sur tout le système artériel d'un individu.

Cette vision de l'avenir des réseaux de capteurs est, pour le coup, futuriste. Mais pas irréaliste. Cela dit, entre la philosophie de la mesure qui sied aujourd'hui et celle qui régnera peut-être demain, il y a un complet changement de paradigme. D'un côté, l'état de l'art : un petit ensemble de capteurs, fragiles, précis et judicieusement positionnés, régis par un algorithme déterministe. De l'autre, une avalanche de capteurs répandus comme de la mauvaise graine, des corpuscules qui agissent non comme des individus mais comme une population. L'un tombe en panne ? Puisque des dizaines le suppléent, on le laissera simplement se déliter là où il est. Le coût de sa perte n'a que peu d'incidence, l'information qu'il apporte n'est pas indispensable. Et si le capteur émet à faible distance, il peut se passer de pile au profit d'énergies captées sur son environnement - solaire, chimique.

Évidemment, on n'en est pas là. Mais on s'y dirige à grand pas. Ainsi, des viticulteurs californiens utilisent dès aujourd'hui le réseau de capteurs ZigBee pour se tenir informés des besoins en eau de chaque plan de vigne. Alimenté par pile, chaque capteur d'humidité fait transiter l'information vers un autre pied jusqu'au serveur. Le réseau ZigBee se limite aujourd'hui à quelques centaines ou milliers de noeuds. Mais rien dans l'essentiel ne sépare ZigBee d'un réseau informel de millions de capteurs. D'autant que le principe fondateur de ces nouveaux réseaux tient en deux points. Primo, peu de débit transmis. Secundo, n'importe quel chemin est le bon. Que le cofondateur de Microsoft, Paul Allen, et l'inventeur d'Ethernet, Bob Metcalfe aient investi dans le standard est de bon augure. Mais ZigBee a déjà beaucoup de concurrents comme le système TinyOS, développé en open source par l'Université de Berkeley (États-Unis), lui aussi dédié à la gestion d'un vaste parc de capteurs sans fil. Le champ des applications est immense : du contrôle routier à la détection de germes dans l'eau potable.

Une multitude de capteurs, même peu fiables, même "volatils" peut être plus efficace qu'un système de contrôle dûment prémédité. Le spectaculaire viaduc de Millau est un des premiers ouvrages d'art littéralement "habité" de capteurs : anémomètres, accéléromètres, inclinomètres, extensomètres à fibre optique, capteurs de température sont situés sur l'auvent, le tablier, les piles, les pylônes. Une première réalisée par la société Sites. On mesure ainsi le comportement de la structure par grand vent. Des capteurs micro-accoustiques surveillent l'usure des haubans ou encore les joints de chaussée. Ces appareils fournissent jusqu'à cent mesures par seconde, ce qui donne à la fois un constat de l'usure sur le long terme, mais aussi le suivi en continu des phénomènes vibratoires, par exemple par grand vent.

Bruno Bouyssounouse, pilote du projet d'excellence Artist2, évoque ce troupeau de zèbres suivis sur de vastes étendues... de collier en collier. En effet, toute liaison satellite serait impossible. Un animal "capté" se fait alors le rapporteur de la vie de toute la horde.

Cette pullulation des capteurs résout apparemment le problème. Apparemment car toute la complexité se trouve reportée sur l'intelligence "qui est derrière". En fait, dès que le nombre de capteurs excède quelques centaines, on entre dans le domaine de l'interprétation, c'est-à-dire une "image" dont il faut extraire l'information pertinente. Passer des systèmes centralisés que l'on connaît aujourd'hui (l'information converge vers le haut) à des organisations de capteurs totalement décentralisées (tout le monde parle à tout le monde) fait appel à des théories mathématiques peu triviales, qui vont de la reconnaissance de forme, au traitement probabiliste en passant par les sciences neuromimétiques (réseaux de neurones artificiels).

Un bon exemple est donné par le projet Actidom (Actimétrie à domicile) pour la surveillance de personnes dépendantes à domicile. Ce projet, qui rassemble France Télécom, LI2G-GPSP UJF, TIMC et Teamlog, utilise les microcentrales accélérométriques Trident développées par le CEA. Il s'agit, bien sûr, de mesurer le plus d'informations possible sur les mouvements et l'orientation du corps. Et, in fine, de déterminer si la personne se trouve en état de détresse. Or, ce signal en 0 ou 1 en sortie est le fruit de la fusion algorithmique d'un nombre colossal de données temporelles. La miniaturisation, l'autonomie et les capacités à communiquer (biper le médecin) sont ici des verrous techniques. Mais la réelle complexité se situe bien au niveau de la prise de décision logicielle.

5 Bâtir des "micro-usines" La fusion électronique, micro- et nanotechnologies

Ce qu'on sait très bien faire aujourd'hui, c'est gérer des mouvements d'électrons. Si bien qu'on parvient à intégrer plusieurs centaines de millions de transistors sur une puce. Demain, dans la même puce s'échangeront des flux mécaniques, fluidiques, photoniques, moléculaires... Pour un spectre d'applications immense qui ira de la biologie - puces in situ injectés dans le corps humain - à la chimie, l'environnement...

Aujourd'hui, ce sont les biopuces qui donnent la vision la plus pertinente de ces objets miniaturisés à l'extrême, hétérogènes, où s'interpénètrent toutes les disciplines. Ainsi, depuis les années 1990, on sait déposer sur des électrodes des films de molécules fonctionnalisés, capables entre autres de réagir à des molécules comme des protéines. Dans les "puces ADN" actuelles, le résultat du test (est-ce qu'un gène s'exprime ?) se traduit généralement par fluorescence.

L'intégration de plus en plus poussée de capacités de mesure et de traitement au sein même de la sonde est en train de faire exploser tout le secteur du diagnostic médical : en vitesse, en transportabilité, en coût... Quelques gouttes de salive ou de sang permettront, en tout lieu, d'identifier un agent pathogène. Révolution aussi, dans la recherche pharmaceutique, puisque des centaines d'expériences (criblage à haut débit) pourront se dérouler en parallèle. Les biopuces seront bientôt capables de traitements en série : séparation cellulaire, extraction de l'ADN, amplification des séquences génétiques, etc.

Une grande difficulté est le contrôle de mouvement de fluides d'un module à l'autre, au travers des canaux microscopiques. À très petite échelle, par exemple, les effets de surface l'emportent sur la gravité. Que l'on utilise des procédés piézo-électriques ou électrostatiques, le logiciel de contrôle doit être gravé dans la puce elle-même, au plus près de l'échantillon. Ces biopuces utiliseront aussi des robots miniatures capables de manipuler des gouttelettes de quelques dizaines de picolitres. On peut être amené à mesurer des courants ioniques (à travers les canaux ioniques des cellules) de quelques milliardièmes d'ampère.

Pour donner une idée de la complexité des logiciels embarqués, dans la puce Medics du CEA (développée avec Silicon Biosystems) 100 000 microélectrodes sur 40 mm2 peuvent être actionnées unitairement afin de piéger une cellule à l'endroit précis que l'on souhaite.

Dans le même ordre d'idée, le projet Neurocom a pour objectif l'étude spatiale d'un réseau de neurones vivants. Ce projet labellisé par le Réseau des micronanotechnologies (RMNT) allie, entre autres, le CNRS et le Léti aux entreprises grenobloises Memscap et Bio-Logic.

Il s'agit, dans un premier temps, d'un objet d'observation pour les neurosciences, qui comprendra dans la même puce un réseau de microélectrodes (1 000 à 2 000 voies) et le processeur d'acquisition et de traitement du signal. Mais, à terme, se profile un usage bien plus ambitieux : celui de neuroprothèses implantés sur le système nerveux humain, dans le but de pallier un handicap (vision, audition, système moteur) ou de prévenir des crises d'épilepsie.

Depuis 2004, et pour une durée de trois ans, le CEA-Léti et l'Inria ont associé leurs expertises, nanotechnologie et ingénierie logicielle, dans l'optique de développer des "systèmes sur une puce" (SOC). On pense évidemment au biomédical, mais sont également visées les applications domestiques, bureautiques, automobiles... Jean-René Lequepeys est responsable du service de conception des circuits intégrés au Léti. « Une partie importante de nos travaux a trait à la modélisation de la consommation électrique des circuits et à la conception de circuits économes. »

6 Garantir un fonctionnement sans faille Des systèmes à toute épreuve

C'est à coup sûr l'industrie ferroviaire et l'industrie aéronautique qui ont posé, en termes les plus pointus, le problème de la sécurité des systèmes embarqués. Le développement du métro automatique Météor a familiarisé des centaines d'informaticiens avec les langages à preuve (à l'époque, le langage B) : à gros trait, un outil logique débroussaille l'immense bouquet de contraintes que l'on impose au fonctionnement de la ligne pour, au final, aboutir à une contradiction (le problème est mal posé) ou conclure par une tautologie : tout va bien !

Dans le même temps, l'industrie aéronautique, Airbus le premier, rendait irréversible le passage au numérique en supprimant la tringlerie de commande (Fly-by-wire) et en inventant des modes de vol optimaux mais antinaturels (commandes inversées). La rançon : une explosion des systèmes redondants s'observant mutuellement.

Au respect absolu de la vie humaine succède aujourd'hui plus trivialement d'immenses intérêts économiques : une panne dans la climatisation d'un entrepôt, ce sont des tonnes d'aliments à jeter.

En informatique "de bureau", la fiabilité c'est se garantir qu'un programme ne bogue pas, c'est-à-dire qu'il ne rencontre pas un cas non prévu face auquel son comportement devient imprévisible. La problématique de la sûreté de fonctionnement dans les systèmes embarqués est bien plus complexe pour au moins trois raisons. D'abord, on ne peut généralement pas envisager tous les cas de figure qui mènent à une réponse inappropriée : la réalité est trop imaginative ! C'est pourquoi, une tendance de fond est de substituer (ou de surajouter) à la phase de test, l'utilisation d'outils permettant la détection d'erreurs d'exécution, ce en phase de compilation. La société Polyspace est l'un des leaders de ce domaine, particulièrement présente dans l'aéronautique. La recherche est particulièrement fertile dans la vérification formelle des logiciels. Citons pour seul exemple le programme Astree (Analyse statistique de logiciels temps réels embarqués) de l'ENS, auquel participe le groupe Airbus.

Deuxième grande difficulté, un système embarqué est un tout, avec ses "bras" dans le réel que sont les capteurs et actionneurs. Aux erreurs de logique s'ajoutent donc les dysfonctionnements physiques. Et, surtout, alors qu'un logiciel "de bureau" apporte une aide, un système embarqué remplit une mission ! C'est dire qu'en bonne partie, l'intégrité de son environnement, dépend de lui et de lui seul. C'est évidemment vrai dans le transport, mais aussi dans les prothèses médicales actives... ou dans n'importe quel objet qui perd sa valeur d'usage si le programmeur est endommagé. De plus, les logiciels enfouis sont difficilement accessibles à la maintenance.

On demande encore bien plus aux systèmes embarqués : agir sans faute, bien sûr, mais aussi marcher avec des béquilles. C'est-à-dire se reconfigurer automatiquement, dans le cas de pertes de certains capteurs ou actionneurs, toujours afin de remplir au mieux leur mission. C'est vrai pour les systèmes, mais aussi pour les circuits eux-mêmes. Jean-René Lequepeys (Léti) note : « La tendance, par rapport aux Asic figés d'aujourd'hui, est d'aller vers des circuits versatiles, qui changent en cours de route leur mode de fonctionnement. »

Un avionneur voudra que son appareil soit réparé à sa base en cas de dysfonctionnement, et donc puisse continuer à voler, dans un mode dégradé mais acceptable au regard de la sécurité de vol. Dans le cas du spatial, c'est pire encore !

De plus en plus est décrit dans les cahiers des charges un ensemble de modes dégradés ou exceptionnels. « Par exemple, les réseaux cellulaires de nos téléphones mobiles accordent une meilleure qualité de service à un appel d'urgence », note Bruno Bouyssounouse (Verimag).

Par ailleurs, un concept porteur est celui de BIST, pour Built in self test - capacités de test intégrées au circuit, et d'autodiagnostic.

7 Disséminer des systèmes autonomes Les économies d'énergie

La gestion au plus juste de l'énergie est au coeur des nouvelles problématiques de l'intelligence embarquée, en particulier sur des systèmes nomades, ou éparpillés, hors de portée de toute intervention humaine. Sur un réseau RFID (Radio Frequency Identification), aucun problème puisque les ondes électromagnétiques véhiculent l'énergie nécessaire au fonctionnement de la puce. Sur courtes distances ! Au-delà ? L'énergie dépensée à la communication s'accroît avec le débit transmis et croît bien plus vite encore avec la distance.

La solution ? Composite et variée, on s'en doute. Cela peut conduire à utiliser des sources d'énergie très efficaces en termes de densité au regard de la masse embarquée. Et là, les piles à combustible miniatures, souvent à base d'alcool, sont d'excellentes candidates, en substitution des couples électrochimiques, comme le lithium-ion. Ces derniers apportent une énergie spécifique de l'ordre de 130 Wh/kg. Un ratio qui n'augmentera plus significativement. Les piles à combustible à méthanol direct offrent, elles, trois à cinq fois plus d'autonomie.

Bien. Mais pas suffisant encore au regard des consommateurs, qui réclament encore deux fois mieux. Cela est vrai pour les outils numériques qui s'interfacent avec l'humain (PDA, téléphone mobile, etc.). En France, le CEA (son laboratoire Liten, dédié aux énergies nouvelles) travaille à des piles jusqu'à 10 W tenant sur substrats silicium de 4 pouces sur lesquels sont gravés les canaux de circulation de gaz : un must dans l'intégration. Le même laboratoire est l'un des seuls à réaliser des batteries lithium-ion par dépôt de couches minces.

Outre ces techniques de microstockage d'énergie, beaucoup d'objets nomades pourraient s'alimenter par effet photovoltaïque voire en convertissant l'énergie des vibrations que lui impose le corps humain ou le système mobile à bord desquels ils sont. Il y a aussi la possibilité de les munir d'une autonomie énergétique qui égale leur durée de vie.

On peut aussi jouer sur le débit mis en oeuvre. Ainsi un réseau ZigBee n'est pas destiné à la transmission d'un flux dense d'informations. Il gère plutôt des ordres brefs, d'où son intérêt en domotique ou dans le contrôle de process : baisser un store, fermer une valve. Et là, les ingénieurs ont fait des exploits puisqu'avec un débit de 20 Kbit/s sur une distance de quelques dizaines de mètres, ils ont une autonomie de plusieurs années.

La technologie même de fabrication des circuits électroniques a un fort impact sur la consommation. Ainsi, selon un responsable du Léti, « la technologie SOI (Silicon on Insulator ou silicium sur isolant) s'impose parce qu'elle fait gagner jusqu'à 40 % en consommation ».

En vue de l'obtention de systèmes basse consommation, on peut arriver à des solutions matérielles et logicielles totalement inédites. C'est la voie du "logiciel basse consommation". À la façon dont le chien qui dort maintient juste le niveau d'attention qu'il faut pour surveiller son environnement, un hardware peut parfaitement mettre en veille tout ce qu'il n'est pas nécessaire d'alimenter... lorsqu'il ne se passe rien. En soi, l'horloge est une très grande consommatrice d'énergie : d'où l'idée d'adapter sa fréquence au besoin. Mieux, une équipe du laboratoire Tima (rattaché à l'Imag de Grenoble) a démontré qu'on peut diminuer de 70 % la consommation de certains systèmes embarqués. Comment ? En conjuguant des processeurs asynchrones et en implémentant un algorithme adaptatif de la tension d'alimentation.

vous lisez un article d'Industries & Technologies N°0874

Découvrir les articles de ce numéro Consultez les archives 2006 d'Industries & Technologies

Bienvenue !

Vous êtes désormais inscrits. Vous recevrez prochainement notre newsletter hebdomadaire Industrie & Technologies

Nous vous recommandons

BOUGEZ,
RESTEZ BRANCHÉS !

BOUGEZ, RESTEZ BRANCHÉS !

- La combinaison d'informatique mobile et de télécommunications permet d'accéder à distance aux applications métiers de l'entreprise. À la clé, des[…]

01/06/2006 | INFORMATIQUE MOBILE
Les éditeurs de logiciels misent sur la mobilité

Les éditeurs de logiciels misent sur la mobilité

Le chantier de BTP suivi en temps réel

Le chantier de BTP suivi en temps réel

BEKAERT MET DU "DIAMANT" DANS VOTRE MOTEUR

BEKAERT MET DU "DIAMANT" DANS VOTRE MOTEUR

Plus d'articles