En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies pour vous proposer des contenus et services adaptés à vos centres d'intérêts. En savoir plus et gérer ces paramètres. OK X
 
 

 

 

Techniques

Passer du M2M à l’IIdO

Par Simon Duggleby, Product Marketing Manager, Electronics Division, RS Components

Publication: 27 février

Partagez sur
 
Les protocoles industriels continuent d’évoluer pour une mise en réseau en temps réel...
 

De nos jours, il n’est pas facile de parler des dispositifs connectés sans faire référence à l’Internet des objets (IdO). Mais bien avant que l’IdO ne soit imaginé, les dispositifs des environnements industriels communiquaient déjà entre eux. En s’amplifiant, cette tendance nous a menés à l’âge du M2M (Machine-à-Machine). Les premiers échanges simples d’un point à un autre, ont rapidement évolué pour rapprocher l’atelier, du bureau, en utilisant un réseau commun. Ce phénomène fut désigné comme l’industrie 4.0 et depuis, comme ces usines sont maintenant accessibles depuis n’importe quel endroit, à tout instant, le terme « Internet industriel des objets » (IIdO) prédomine.

Cette évolution naturelle ne reflète pas simplement le développement exponentiel de la collecte et du transfert des données, mais aussi la façon dont l’IIdO permet à la commande de suivre le même chemin. Construire l’IIdO se fonde largement sur l’existence de communications à différents niveaux. La majorité des prérequis sousjacents sont déjà en place, alors que d’autres ne font qu’émerger. Du point de vue des ingénieurs, amener toute cette interconnectivité dans un format robuste et abordable représente le genre de défi qui motive les développeurs.

Des prérequis très divers

En tant qu’initiative intersectorielle, l’IIdO en général est étudié sous plusieurs angles, mais il parait clair que son implémentation nécessitera une hiérarchisation. L’Internet offre la dorsale idéale pour le transfert de données de masse, mais il n’est pas bien adapté à la commande en temps réel ; il y a trop de latence incorporée dans les protocoles de base de l’Internet.

En termes simples, dans une maison connectée tous les appareils électroménagers peuvent être connectés et commandés à l’aide d’un réseau local, et accessibles par Internet. Il est possible mais lourd d’utiliser l’Internet pour commander les dispositifs localement ; une lampe mettrait, par exemple, quelques secondes à s’éteindre, ou une télé à changer de chaîne. Par conséquent, le concept d’ « avatars de dispositifs », selon lequel chaque dispositif existe aussi en version virtuelle dans le « cloud », est en train de gagner du terrain. Localement, les dispositifs sont commandés directement par un réseau local (local area network). La commande à distance se ferait par Internet, et ce serait les avatars qui recevraient les instructions de changement. Ces changements seraient alors relayés vers leurs équivalents dans le monde réel. Cette duplication semble superflue mais permet de surmonter les limitations d’un réseau non déterministe pour commander localement des dispositifs.

Dans un environnement industriel, la difficulté est encore amplifiée par la nécessité d’une commande « impérativement en temps réel », dans laquelle les petits paquets de données sont envoyés/reçus entre dispositifs. Dans ce cas, le prérequis sous-jacent est que les paquets arrivent de manière fiable dans un temps déterminé. Les premiers protocoles industriels, comme par exemple le protocole HART (Highway Addressable Remote Transducer), ont évolué au cours du temps pour parvenir à ce but. Ce protocole se distingue par le fait qu’il utilise les anciennes connexions point-à-point 4-20mA, et qu’il accepte des signaux analogiques comme des signaux numériques sur une simple paire torsadée. L’interface physique utilise la modulation par déplacement de fréquence (FSK), par laquelle un “1” logique (marque) est représenté par une onde sinusoïdale avec une fréquence centrale de 1,2kHz, et un « 0 » logique (espace) par une onde sinusoïdale avec une fréquence centrale de 2,2kHz. Ces représentations numériques peuvent être modulées en se superposant au courant analogique dans l’intervalle compris entre 4 et 20mA, constituant un protocole flexible pour les applications industrielles. De plus, le protocole peut être implémenté à l’aide d’un microcontrôleur (MCU), avec un modem HART adapté comme interface physique, tel que le A5191HRTPG-XTD de ON Semiconductor. Cela peut être réalisé à l’aide de convertisseurs de courant CNA/CAN si le MCU a une ALU capable de faire tourner l’algorithme requis pour générer et reconnaître les fréquences de FSK.

Alors que le protocole HART peut aussi être utilisé dans une configuration multipoint, il peut ne pas convenir à toutes les applications industrielles, et ne serait définitivement pas utilisé pour une mise en réseau vers Internet. Ce patchwork de protocoles se retrouve partout en commande industrielle, et ce n’est pas près de changer.

Le bon outil pour le travail

L’utilisation de protocoles destinés spécifiquement aux communications par Internet présente de nombreuses limitations dans un environnement industriel. En plus de la latence, il peut être nécessaire, dans un environnement industriel, d’horodater les évènements, une fonctionnalité qui n’est pas compatible avec les protocoles courants de mise en réseau tel que TCP/IP. Ethernet est la “face publique” d’Internet, c’est le moyen par lequel la plupart des gens s’y relient. Alors qu’il est vrai que les protocoles Internet utilisés sur Ethernet ne sont pas adaptés à la commande en temps réel, il estégalement vrai qu’Ethernet peut, en fait, fournir une infrastructure de réseau robuste et fiable quand les bons protocoles sont utilisés.

Il existe un certain nombre de protocoles visant le secteur industriel qui utilisent Ethernet comme une interface. Le plus remarquable est sans doute EtherCAT. Il s’agit d’un des protocoles basés sur Ethernet qui font maintenant partie de la famille Fieldbus telle qu’elle est définie par la norme IEC 61158. Parce qu’il utilise la même interface physique qu’Ethernet, le protocole EtherCAT peut être implémenté à l’aide d’un microcontrôleur avec MAC Ethernet, tel que le XMC4500 d’Infineon. La famille XMC4000 est basée sur l’ARM Cortex-M, et Infineon offre maintenant les XMC4800 et XMC4300 qui sont les premiers microcontrôleurs de l’industrie à intégrer un noeud EtherCAT sur un MCU ARM Cortex-M avec mémoire flash intégrée et fonctionnalités à signaux mixtes.

Dans une topologie industrielle, les dispositifs effectuant les actions (moteurs, éléments chauffants, pompes, actionneurs etc.) sont normalement commandés directement par un API (automate programmable industriel). La tendance actuelle dans l’IIdO est de mettre en réseau des API avec des protocoles en temps réel avec faible latence, tels que ceux de la famille Fieldbus. Malgré le nom et les années d’effort, il n’existe toujours pas de norme Fieldbus commune, et les nombreux protocoles qui y font référence ne sont pas nécessairement interopérables. Il en résulte que les API doivent accepter des protocoles multipoint pour pouvoir fonctionner dans un environnement industriel avec un degré de mise en réseau plus élevé.

La technologie Fieldbus la plus largement déployée est certainement PROFIBUS, mais il en existe beaucoup d’autres dont PROFINET, CAN et Modbus. De nombreux microcontrôleurs intègrent maintenant les interfaces CAN, alors qu’il est possible d’ajouter Modbus à l’aide d’un UART et d’implémenter le protocole dans l’application tournant sur le microcontrôleur.

Assistance logicielle

Alors que de nombreux protocoles déployés pour la commande dans l’IIdO sont relativement simples à implémenter même dans un microcontrôleur bon marché, il parait raisonnable de s’attendre à une consolidation importante ; des microcontrôleurs plus puissants seront utilisés pour manipuler une plus grande variété de protocoles dans une topologie en réseau. A ce stade, l’utilisation d’un système d’exploitation (et dans le cas de la commande industrielle, un système d’exploitation en temps réel, ou RTOS) devrait être avantageux. Faire tourner un RTOS sur un microcontrôleur impose certaines exigences au niveau du matériel, qui se reflètent alors dans le déplacement vers les architectures 32 bits telles que la famille ARM Cortex-M.

Il n’est plus inhabituel pour les fournisseurs de microcontrôleur et de processeurs de collaborer étroitement avec les vendeurs de RTOS pour s’assurer que les piles de communication et les noyaux en temps réel fonctionnent de manière efficace sur leur matériel ; c’est le cas, par exemple, d’Analog Devices avec Micrium. Les processors embarqués Blackfin 16/32bits d’Analog Devices sont directement compatibles avec le système d’exploitation en temps réel ìC/OS de Micrium, équipé de logilogiciels médiateurs pour TCP/IP, USB, CAN bus et Modbus.

La nécessité pour ces protocoles industriels de fonctionner sur des processeurs embarqués hautement intégrés, se reflète dans le fait qu’un nombre croissant de vendeurs d’RTOS offre désormais des piles de protocoles pour la commande industrielle sous forme de logiciel médiateur pour les intégrer dans leur technologie.

Conclusion

Créer un réseau industriel qui permet la commande à distance et assure le contrôle en temps réel nécessite une combinaison de protocoles de communications. Heureusement, les fournisseurs de semiconducteurs l’ont compris et offre déjà une gamme de dispositifs capables de fournir les interfaces matérielles et la puissance de traitement nécessaire pour que l’IIdO devienne une réalité. Il est aussi évident que les protocoles utilisés à l’heure actuelle dans le monde de l’industrie auront toujours leur place dans l’IIdO.

http://fr.rs-online.com/web/general...

Suivez Electronique Mag sur le Web

 

Newsletter

Inscrivez-vous a la newsletter d'Electronique Mag pour recevoir, régulièrement, des nouvelles du site par courrier électronique.

Email: