Dans le monde de l'Internet des objets (IoT), la notion d'"objet" dépasse largement l'idée d'une simple entité physique. Certes, de nombreux objets dans l'IoT sont tangibles, comme des véhicules, des appareils électroménagers, des humains, des animaux ou des chaînes de production. Cependant, de nombreux objets dans l'IoT sont également virtuels. Par exemple, le code exécuté sur un processeur peut être considéré comme un objet, capable de s'identifier, de prendre des mesures (par exemple, de ses propres performances) et d'activer d'autres objets qui contrôlent son environnement, comme le module sans fil pour conserver l'énergie. D'autres exemples d'objets virtuels incluent la bourse ou même la météo.

Les ingénieurs en systèmes embarqués qui souhaitent rendre leurs systèmes compatibles avec les développements futurs de l'IoT doivent garder à l'esprit la diversité des objets avec lesquels leur système pourrait éventuellement interagir. En effet, la gamme de capacités des objets est considérable. Les objets simples peuvent uniquement s'identifier, tandis que des objets plus sophistiqués peuvent réaliser des opérations allant de la simple détection et signalisation des conditions environnementales à l'activation de mécanismes affectant ces mêmes conditions, en passant par l'analyse de la situation et même la prise de décisions intelligentes.

Un objet peut être assez complexe, par exemple, un système embarqué complet, et inclure d'autres objets comme parties intégrantes de sa structure. Ce réseau d'objets peut être organisé sous une forme hiérarchique basée sur des classes et sous-classes, connue dans la communauté de l'intelligence artificielle (IA) sous le nom de hiérarchie ISA (IS-A). Par exemple, une ambulance est un véhicule d'urgence, et un véhicule d'urgence est lui-même un véhicule. Une civière peut également être considérée comme un véhicule d'urgence dans certains contextes. Un système de surveillance de la santé qui nécessite une aide d'urgence pourrait, dans certains cas, appeler une ambulance ou, dans d'autres, demander une civière. La prise de décision dans ce contexte nécessite un certain degré d'intelligence, soit intégrée dans le système, soit accessible par un mécanisme de consultation externe. Ce type de raisonnement doit être pris en compte par les ingénieurs lors de la conception de systèmes embarqués, car il peut s'avérer nécessaire que ces systèmes interagissent avec d'autres objets de manière nécessitant une forme d'intelligence.

De même, des objets individuels peuvent inclure d'autres objets comme composants, ce que l'IA appelle la relation HASA (HAS-A). Par exemple, une voiture est un objet, et elle possède un sous-système de direction qui est lui-même un autre objet. La gestion coopérative de ces différents objets dans l'IoT peut exiger une connaissance de cette structure, semblable à celle des relations ISA mentionnées plus haut.

Les objets, qu'ils soient physiques ou virtuels, génèrent des données spécifiques à leur nature. Ces données peuvent être numériques ou analogiques, et prendre des formes variées : des mesures discrètes comme la température actuelle, ou des flux continus, comme des vidéos. Ces objets ont également une durée de vie, tout comme les êtres humains. Ils naissent (créés) et meurent (destructions). Les objets qui transmettent des données au monde extérieur possèdent une forme de persistance à travers l’historique des données qu'ils génèrent et qui sont conservées dans des référentiels comme le cloud. Les objets peuvent aussi entrer et sortir de l'Internet, c’est-à-dire se connecter et se déconnecter à tout moment. Les objets mobiles, comme des véhicules ou des animaux équipés de capteurs, peuvent se déplacer hors de portée de la connexion Internet. Par ailleurs, les objets alimentés par batterie peuvent voir leur énergie se dissiper avant d’être rechargés ou remplacés. Il est important de souligner qu’un échec de communication avec un objet ne signifie pas nécessairement qu'il est défaillant.

Chaque objet de l'IoT doit être identifiable par un nom unique, afin de pouvoir être référencé et localisé. L’industrie a mis en place des normes pour nommer ces objets, ainsi qu’un Service de Nommage d’Objets (ONS), extension du service DNS (Domain Name System) déjà utilisé sur Internet. Dans de nombreux cas, les objets communiqueront directement entre eux sans qu’il soit nécessaire de chercher un chemin de communication. Par exemple, deux voitures approchant l’une de l’autre se reconnaîtront dès qu’elles seront à portée de leurs circuits de communication sans fil respectifs. Mais, dans d'autres situations, un système devra recourir à l'ONS pour localiser un objet avec lequel il tente d’établir une connexion, comme une station de base d’un système de surveillance des migrations animales cherchant à se connecter à un capteur attaché à un animal en déplacement.

Le rôle de l'IPv6 est crucial dans ce contexte, car il permet de gérer une quantité bien plus grande d'adresses que l'IPv4, qui est déjà limité à environ 4,3 milliards d’adresses distinctes. L’IPv6 permet ainsi de répondre à l’énorme croissance du nombre d'objets connectés.

La mise en échelle dans l'IoT, bien que ne constituant pas une préoccupation immédiate pour les ingénieurs de systèmes embarqués lors de la conception d’un produit particulier, comme un pont par exemple, est un sujet récurrent dans la littérature actuelle sur l'IoT. Le nombre de dispositifs connectés pourrait atteindre 50 milliards d'ici 2020, et ce nombre devrait continuer à croître, doublant potentiellement tous les quelques années. En revanche, le nombre d'objets dans un système embarqué donné est généralement fixe ou croît très lentement par rapport à l’IoT. La conception de ces systèmes doit prendre en compte cette possibilité de croissance, que ce soit pour intégrer de nouveaux capteurs ou interacteurs à un système existant, comme dans le cas d’un système de contrôle agricole pouvant être étendu si un fermier acquiert des terres supplémentaires.

Un autre aspect de la mise à l'échelle dans l'IoT concerne les réseaux. Des milliards d’objets devront communiquer sur l'Internet en utilisant une variété de protocoles de communication. Cela contraste fortement avec les systèmes embarqués, où la structure du réseau et les protocoles sont définis de manière fixe lors de la conception du système. Dans une vision futuriste de l’IoT, un système embarqué pourrait être amené à interagir avec des objets externes d'une manière qui n'a pas été anticipée durant la phase de conception. Les ingénieurs doivent donc envisager cette possibilité et décider s'ils souhaitent intégrer ces options dans le système dès le départ ou bien prévoir des mécanismes permettant une telle communication à l’avenir.

Comment la simulation et les graphes de reachabilité aident à la conception des systèmes dynamiques complexes

Les systèmes complexes, notamment ceux modélisés par des réseaux de Petri, sont souvent difficiles à analyser sans outils mathématiques ou de simulation adaptés. La reachabilité, ou capacité à atteindre certains états à partir d’autres dans un réseau, est une propriété essentielle qui peut être démontrée de manière formelle ou explorée à l’aide de simulations. Cette étude devient particulièrement cruciale lorsqu'il s'agit de vérifier si des états indésirables peuvent survenir, ou dans quels cas un système peut rencontrer des conflits ou des erreurs de conception. Par exemple, dans le cas d'un réacteur nucléaire modélisé par un réseau de Petri, certaines configurations de jetons pourraient mener à des états dangereux, qu’il faut absolument éviter.

Prenons l'exemple d'un pont, où certaines configurations doivent être évitées à tout prix. Imaginons que les places P3 et P5 dans un modèle représentant un pont sous lequel une embarcation traverse soient en même temps occupées par des jetons. Une telle configuration est logiquement inadmissible, car cela signifierait que le bateau est en traversée tout en étant sous un pont baissé. En d’autres termes, le modèle devrait permettre de détecter immédiatement ces états non atteignables ou indésirables, et ainsi alerter sur une erreur dans la conception.

De même, dans des systèmes de production automatisée, comme une ligne de robots, la simulation permet de découvrir des conflits potentiels pour les ressources partagées. Par exemple, si un robot occupe une zone de préparation de pièces, l'autre pourrait se retrouver contraint d'attendre. Ce type de conflit peut parfois être résolu par une refonte du processus, par exemple, en réorganisant l’ordonnancement ou l'espace de travail afin que chaque robot utilise la zone de préparation de manière alternative. En d’autres termes, une planification soignée du mouvement des robots permet de s'assurer que les espaces de travail sont toujours libres lorsqu’un robot approche, réduisant ainsi le temps d'attente et optimisant l'efficacité.

Une des principales forces de l’analyse de la reachabilité réside dans sa capacité à identifier des inefficacités dans les processus. Par exemple, dans un modèle simplifié où deux robots travaillent en alternance sur une zone de préparation, une telle configuration peut non seulement réduire la taille de l’espace de stockage mais aussi améliorer l’efficacité. En forçant les robots à travailler de manière séquentielle plutôt que simultanée, on élimine deux types d'inefficacité : le premier robot attend inutilement lorsque le second occupe la zone, et inversement. Ce type d'analyse peut être réalisé en étudiant les graphes de reachabilité, qui, en plus de simplifier le modèle, permettent aussi d’identifier des processus parallèles potentiels. Dans notre exemple des robots, il est possible que, pendant qu’un robot travaille dans la zone de préparation, l'autre se déplace entre la zone de stockage et cette même zone de préparation. Le graphe de reachabilité met en lumière ces chemins parallèles et permet une compréhension plus profonde du modèle dynamique.

L’un des concepts fondamentaux étudiés à travers le graphe de reachabilité est la notion de "vivacité" des transitions, c’est-à-dire la capacité des transitions à être activées dans certains contextes. Si un jeton reste constamment absent dans une place, cela signifie que les transitions associées à cette place ne peuvent jamais se produire. Une transition ainsi inactive est qualifiée de "morte", ce qui indique un défaut dans la conception du modèle. Cette analyse de la vivacité, et notamment des quatre niveaux possibles (une transition activée au moins une fois, une transition activée de manière répétée, etc.), est cruciale pour identifier les processus qui pourraient mener à un blocage ou à une inefficacité.

Les graphes de reachabilité sont donc des outils puissants permettant non seulement de vérifier la validité d’un modèle mais aussi d’en optimiser la performance. Par exemple, dans un réseau de Petri modélisant un processus de travail, la "matrice d'incidence" permet de représenter de manière concise les relations entre les places et les transitions, et d’étudier comment l’activation de certaines transitions affecte l'état du réseau. Cette approche permet de tester différentes configurations et d’évaluer si un marquage particulier est atteignable à partir d'un marquage initial donné, en suivant une séquence de transitions bien définie.

À travers l'analyse de la matrice d'incidence, il devient possible d'identifier la séquence de transitions qui mène à un état spécifique, ce qui est crucial pour comprendre comment un système évolue sous différentes conditions. Cette étude peut être particulièrement utile pour des systèmes de production ou des réseaux de contrôle complexes, où chaque transition représente un changement d'état du système. Ainsi, une simulation minutieuse permet de tester différentes configurations et de vérifier la validité des hypothèses de conception, tout en recherchant d’éventuels problèmes de performance ou de fonctionnalité.

Dans ce contexte, les simulations ne sont pas seulement un moyen de tester des hypothèses mais deviennent un outil essentiel pour affiner les modèles et améliorer leur robustesse. Elles permettent de découvrir des problèmes invisibles à l’analyse théorique pure, comme des conflits imprévus, des goulets d'étranglement dans les processus, ou des erreurs de conception qui n’apparaissent qu’à l’échelle du système complet.

L'analyse des réseaux de Petri à travers les graphes de reachabilité et les matrices d'incidence ne doit pas être vue comme une simple formalité mathématique, mais comme un moyen d’optimiser des systèmes complexes, en éliminant les inefficacités et en assurant leur bon fonctionnement. Ces outils offrent non seulement une validation formelle du modèle mais permettent aussi une simulation dynamique qui, si elle est utilisée de manière judicieuse, peut conduire à une amélioration continue de la conception.

Comment les FPGA et CPLD Transforment la Conception des Systèmes Embarqués

Les FPGA (Field Programmable Gate Arrays) peuvent être programmés pour accomplir les étapes d’un algorithme, et ces étapes se dérouleraient à la vitesse des transistors, c'est-à-dire en nanosecondes ou moins, plutôt qu'à la vitesse d'exécution des instructions, qui se mesure en microsecondes ou fractions de microsecondes. Un système embarqué pourrait utiliser un FPGA en complément d’un processeur traditionnel. Le processeur serait chargé de collecter et éventuellement de formater les données provenant des entrées du système, telles que des capteurs ou des connexions réseau, avant de les transmettre au FPGA. Ce dernier traiterait ensuite les données et produirait les sorties sans nécessiter davantage l’intervention du processeur, et ce, à des vitesses plusieurs ordres de grandeur supérieures. Une extension intéressante de cette idée est l’utilisation des FPGA programmables en circuit (in-circuit programmable). Le logiciel qui fonctionne sur le processeur du système peut télécharger différents fichiers sur le FPGA reprogrammable, modifiant ainsi les fonctions qu’il exécute. Ainsi, un seul FPGA peut implémenter plusieurs parties d’un système embarqué tant que ces parties n’ont pas besoin d’être réalisées simultanément.

Cependant, l’utilisation de l’FPGA implique un certain coût : il occupe de l’espace sur la carte et consomme de l’énergie. Bien que ce dernier inconvénient doive être mis en balance avec la puissance qu’aurait utilisée le processeur pour accomplir la même tâche, ce compromis repose sur la vitesse et, éventuellement, sur un coût inférieur du processeur si celui-ci peut accomplir les tâches restantes du système avec moins de puissance. L’examen approfondi de ce sujet dépasse le cadre de cet ouvrage, bien qu’une démonstration simple dans la section suivante montre comment un FPGA peut implémenter un algorithme élémentaire. Pour les lecteurs intéressés, les références [1-3] et d’autres ouvrages offrent des lectures complémentaires. Il suffit que l’étudiant prenne conscience de cette alternative pour l’implémentation de certaines parties du système embarqué.

Les FPGA ne sont pas toujours nécessaires dans tous les systèmes embarqués, particulièrement dans les circuits à faible coût. Les FPGA et CPLD (Complex Programmable Logic Devices) de bas de gamme sont couramment utilisés pour implémenter la logique booléenne au niveau de la carte de circuit imprimé. Ces dispositifs sont particulièrement utiles pour générer des signaux de sélection de puce à partir des adresses du processeur (voir Exemple 12.1) ou pour réaliser d’autres fonctions "collantes" nécessaires à l’interface entre les circuits de la carte. Ils sont également utilisés pour générer des signaux de contrôle spéciaux (voir Exemple 12.2), implémenter la logique booléenne des signaux systèmes et réaliser des fonctions similaires au niveau de la carte. De plus, ils peuvent servir à la prototypage et à l’essai de circuits intégrés spécifiques à une application (ASICs) avant leur fabrication en format ASIC.

Prenons l'exemple d’un CPLD de bas de gamme typique, tel que le ATF22V10 de la famille 22v10 d’Atmel. Ce circuit possède un format de boîtier à 24 broches en DIP (Double In-line Package) et un format à 28 broches en PLCC (Plastic Leaded Chip Carrier). Le format PLCC dispose de broches supplémentaires pour la masse (GND) et pour la tension commune du collecteur (VCC). Douze de ces broches sont dédiées aux entrées, et l'une d’elles peut être utilisée comme une horloge pour réaliser des fonctions logiques séquentielles. Dix autres broches peuvent être configurées comme entrée ou sortie lors du processus de programmation. Ce type de circuit peut être utilisé pour générer des signaux de sélection de puces à partir des bits d'adresse du processeur.

Prenons un exemple simple. Un système composé d’un processeur 8051 et de plusieurs périphériques tels que des mémoires et un UART, utilise un CPLD pour générer des signaux de sélection de puce à partir des adresses envoyées par le processeur. L’idée est de contrôler l’accès aux différents périphériques en fonction de certaines plages d'adresses. Par exemple, les bits d'adresse A13, A14 et A15 pourraient être utilisés pour déterminer quel périphérique est sélectionné, en fonction des adresses des circuits mémoires. Cette sélection est effectuée à l'aide de portes logiques dans le CPLD, qui gère les signaux de sélection de manière beaucoup plus compacte qu’avec une logique traditionnelle.

Dans un autre exemple, il est possible d’utiliser un CPLD pour gérer des fonctionnalités plus complexes comme la gestion de la lecture/écriture de mémoires spécifiques. Imaginons qu’un demi-bloc d’une mémoire EEPROM doive être protégé tandis que l’autre moitié est modifiable par l’utilisateur. Dans ce cas, il est essentiel de s’assurer que certaines opérations de lecture ou d’écriture ne se produisent que lorsque l’adresse est dans une plage donnée. Cela pourrait être géré facilement avec un CPLD qui génère un signal de contrôle d’écriture lorsque l’adresse et les autres conditions sont remplies. Cette logique est spécifiée à l’aide de petites équations qui décrivent les conditions sous lesquelles chaque signal doit être activé ou désactivé.

Les CPLD comme le 22v10 sont également capables de réaliser des circuits logiques séquentiels, où les sorties sont régies par un signal d’horloge. Les registres internes du CPLD peuvent conserver les valeurs des signaux d’un cycle d’horloge à l’autre, ce qui permet d’implémenter des fonctionnalités qui nécessitent de la mémoire à court terme, comme des compteurs ou des états de machine à états finis. Cette capacité de feedback, combinée à la flexibilité de la programmation, permet aux CPLD de s’adapter à une grande variété de besoins en matière de logique embarquée.

Un autre aspect important à prendre en compte est la consommation d'énergie. Bien que les FPGA offrent des performances impressionnantes, les CPLD de bas de gamme consomment moins d’énergie et sont souvent suffisants pour les applications simples où seule une logique combinatoire ou séquentielle est nécessaire. Le choix entre un FPGA haut de gamme et un CPLD de bas de gamme dépend des exigences spécifiques du système : si la vitesse et la flexibilité sont primordiales, un FPGA pourrait être nécessaire, mais pour des fonctions plus simples et moins gourmandes en énergie, un CPLD pourrait suffire.

Pourquoi l’héritage financier peut-il être une malédiction pour la jeunesse ?
La confiance dans la gestion de produit : Comment préparer des décisions avec assurance
Le rôle du gaz naturel dans la consommation énergétique mondiale et son impact sur les ressources énergétiques