DesignSpark Electrical Logolinkedin
Ask a Question

19 Jun 2019, 6:33

Quand l’automatisation classique rencontre le monde étranger de l’informatique: Part 2

Dans lapartie 1, j'ai décrit les principales différences d'objectifs et d'architecture système entre les systèmes d’automatisation classiques et l'informatique classique : l’automatisation requiert des systèmes très fiables, rapides et prévisibles, alors que le monde de l'informatique doit être plus "social" : polyvalence, communication et adaptation sont nécessaires. Dans cette deuxième partie, je vais essayer d'expliquer les différences fondamentales dans la communication.

Partie 2

Les bus de terrain et les protocoles internet

Un automate programmable (voir la partie 1 pour l'explication) échantillonne ses entrées et les combine avec un instantané de ses états internes appelé une "image de processus". Cet instantané est utilisé pour les calculs et les décisions. Il en résulte un renouvellement d'états simultanés (changement) de toutes les sorties. Les signaux d'entrée et de sortie sont normalement soit des signaux numériques 24 V, soit des signaux analogiques avec une tension de 0 à 10 V ou des boucles de courant de 4 à 20 mA. Mais lorsqu'il y a des centaines d'entrées de capteur, il n'est plus possible de les connecter physiquement avec des câbles individuels. La solution consiste alors à utiliser un "bus" qui n’a que quelques fils. Il transporte l'information de façon séquentielle (fonctionnement en "série" et non pas en "parallèle, image 1) entre l'automate et les nombreux capteurs et actionneurs. Ces derniers doivent être plus "intelligents" : ils ont besoin de comporter un processeur de communication intégré pour échanger leurs valeurs avec le contrôleur.

Image 1 : câblage conventionnel (à gauche) et le câblage à bus de terrain (à droite).

Les "bus de terrain" ou "bus industriels" doivent transporter l'information de manière prédictive. La prévisibilité dans les moyens de communication sous-entend que vous avez besoin de connaître précisément le temps de réaction maximal entre une requête et la réponse à cette requête (c’est d'ailleurs la définition de la "capacité de traitement en temps réel", et non un délai absolu arbitraire). Quel que soit ce temps de réaction, toute déviation de sa valeur nominale est appelée "jitter" et rend le système moins prédictif. Un jitter maximum petit et connu est une propriété essentielle d'un système en temps réel dans l’automatisation. C'est la raison pour laquelle la réduction du temps de réaction par le biais d'interruptions n'est pas une bonne idée : toute interruption introduit un facteur probabiliste, et l'ensemble du système perd sa propriété déterministe. Il n’est pas étonnant que les bus de terrain fonctionnent souvent de manière cyclique et déterministe, tout comme les contrôleurs (automates) auxquels ils sont connectés. Un système cyclique a un jitter défini. On peut donc penser que le fait de combiner plusieurs systèmes cycliques asynchrones (tels qu'un automate et un bus de terrain) additionne les jitters. La synchronisation du cycle du bus avec le cycle de l’automate est une solution facile à ce problème.

Image 2 : temps de réaction et jitter dans l'automatisation.

Les "protocoles" sont des accords entre les partenaires de communication qui définissent les phases et le comportement pendant la communication. Le problème majeur provient de la diversité historique de ces protocoles d'automatisation. Les machines parlent souvent dans des "langues" différentes, et il existe toute une industrie qui s’emploie à traduire ces langues. Jetons un coup d'œil à l'un des bus de terrain classiques, défini dans la norme CEI 61784 / EN 50170 comme "Bus de terrain de processus pour périphériques décentralisés" (Profibus DP). Il utilise un signal numérique différentiel sur deux fils, selon la norme RS485, mais avec des débits très élevés (jusqu'à 12 Mbit/s). Il fonctionne avec un rapport maître-esclave très strict et la partie DP V0 du protocole transporte les données de manière cyclique (image 3). Le contrôleur (automate) est maître, et les périphériques d’entrée et de sortie sont des dispositifs esclaves seulement autorisés à répondre aux demandes cycliques du maître.

Lors de la configuration, l'ingénieur doit indiquer au contrôleur le nombre et le type de périphériques connectés. Après une séquence de démarrage (la "paramétrisation" et la "configuration") dans laquelle chaque esclave doit "rejoindre" le réseau, l'automate interroge cycliquement tous les périphériques E/S avec un taux d’interrogation déterminé ("trame d’interrogation"). Les périphériques esclaves acceptent la réception de leurs données et répondent immédiatement avec leurs états E/S ("trame de réponse").

Image 3 : échange de données cyclique sur un réseau Profibus

Afin de ne pas compliquer cette courte introduction, je vais me contenter de mentionner qu'il peut exister une communication token ring permettant la présence de plusieurs maîtres sur un réseau Profibus (seul le maître avec le jeton est autorisé à interroger et lorsque son cycle est terminé, il passe le jeton à un autre maître). Il existe une grande sécurité intégrée au système : par exemple, si un esclave n'est pas interrogé dans un temps prédéfini, il change sa sortie sur un "état sécurisé" prédéfini. Si un esclave détecte une défaillance, il peut configurer l’alarme ("diagnostic") dans sa réponse à l'automate, ce qui à son tour permet au maître demander des données de diagnostic lors sa prochaine requête.

Il existe également des méthodes intégrées pour faire face au "problème de cohérence" d'un bus série : dans la première partie, j’ai présenté l'"image de processus". J'ai mentionné à quel point il est important dans l'automatisation d'obtenir un instantané uniforme des entrées (ou d'activer les sorties simultanément). Mais comment est-il possible d'obtenir un tel instantané lorsque les informations d'entrée de plusieurs capteurs sont transmises de façon séquentielle ? Lorsque la deuxième valeur de capteur répond à la demande de requête, la valeur du premier capteur pourrait déjà avoir changé. Le Profibus connaît une commande "gel". Lorsque le PLC diffuse cette commande, tous les esclaves gèlent leurs valeurs d'entrée jusqu'à ce qu'ils aient été interrogés. De cette façon, vous obtenez un aperçu du moment où le PLC a envoyé l’"arrêt sur image" (télégramme).

Le débit du bus limite le taux d’interrogation et en cas d'erreurs de transmission, il est possible que certains cycles ne reflètent pas l’état actuel du périphérique. Mais au final, ce type de communication est exceptionnellement fiable et déterministe. Le Profibus a été introduit dans les années 90, et avec plus de 40 millions d'appareils certifiés, il est toujours l'un des protocoles de communication les plus utilisés dans l'industrie de l'automatisation. Sa fiabilité le rend idéal pour la technologie de la sécurité (nous aborderons ce sujet dans la partie 3 de cette série).

Le caractère cyclique du concept maître-esclave peut paraître étrange aux ingénieurs informaticiens : pourquoi demander continuellement la position d’un commutateur, et pourquoi un commutateur devrait-il indiquer continuellement au contrôleur que son état est "on" au lieu d'envoyer un message seulement lorsque son état passe de "off" à "on" ? Parce qu'il serait difficile de construire un système déterministe en utilisant un tel type de communication basé sur un évènement.

Lorsqu'un programme d'application communique avec une base de données, et qu'ils fonctionnent tous deux sur un matériel différent, on a souvent une architecture client-serveur. Un seul serveur doit traiter des données pour de nombreux clients. Voyez-vous la différence fondamentale ? Les nombreux clients doivent pouvoir ouvrir la communication - ils sont maîtres de la communication - et le serveur central réagit comme un système esclave. Utiliser un dialogue déclenché par un message est beaucoup plus naturel dans un tel environnement. Il serait bien sûr possible d'envisager un réseau déterministe basé sur des messages (par exemple Token Ring). Mais en raison de leur débit global de données statistiques très élevé, ce sont les réseaux probabilistes comme Ethernet qui ont remporté la course. Ces réseaux permettent à n’importe quel participant d’établir la communication à tout moment en envoyant un message. Cette liberté a pour conséquence d’éventuelles "collisions" lorsque deux clients commencent en même temps. Mais une détection rapide de la collision et une stratégie de réaction permet d’avoir toujours un débit exceptionnel. Dans les topologies de réseau modernes (en étoile au lieu de bus ou mash), les collisions sont évitées grâce à de puissants commutateurs qui décalent simultanément les messages pour les "configurer en étoile".

Les réseaux informatiques et leurs protocoles sont non seulement capables de transporter des gigabits par seconde au lieu de mégabits comme Profibus mais leur topologie aussi est flexible. Il est techniquement possible d'étendre un tel réseau dans le monde entier, comme internet. Une des clés de cette flexibilité est l'abstraction du protocole dans des "couches" qui construisent une "pile". Le modèle de référence OSI compte sept couches (voir image 4). Profibus par exemple en compte seulement trois (couches 1, 2 et 7). Internet, avec son protocole TCP/IP, les utilise toutes.

Image : Couches de protocoles OSI ; HTTP comme exemple.

La flexibilité de cette architecture de communication résulte du fait que les deux partenaires peuvent communiquer en utilisant la même couche mais n'ont pas besoin de connaître le processus de communication des couches inférieures. Ils reçoivent leurs messages à partir de la couche inférieure suivante comme s'ils communiquaient directement avec leur réseau partenaire sur la même couche (image 5). C’est une sorte de "communication virtualisée" avec la couche (partenaire) voisine.

Image 5 : communication couche à couche à l'aide de piles de protocoles.

L’utilisation d’une couche réseau (couche 5 OSI) offre la possibilité d'un acheminement à commutation par paquets : chaque nœud du réseau peut décider lui-même du nœud voisin auquel il transmet un paquet d'informations reçues pour l'acheminer à l'adresse du récepteur désiré (IP). Cela constitue la base d’internet, et signifie simplement qu’il n’est jamais possible de savoir par où les paquets d'informations transitent de l’expéditeur IP au récepteur IP.

L’inconvénient de cette flexibilité est la perte de "capacité en temps réel". Il n'est plus possible de prévoir ou définir précisément un délai de réponse maximal de votre partenaire de communication. Si vous utilisez un réseau TCP/IP pour communiquer un changement d'état d'un commutateur, plusieurs microsecondes ou des dizaines de millisecondes peuvent s'écouler avant que le contrôleur ne reçoive le message. Les normes "TSN" (time sensitive networking) permettent de faire face à ces difficultés et visent à établir la capacité en temps réel dans les protocoles réseau.

La bonne nouvelle, c’est que la capacité en temps réel n’est pas nécessaire à l'IoT industriel. La latence n'est pas le critère principal. Mais il y a toutefois une limitation particulière lorsque l’on prévoit d'amener une machine industrielle sur internet : les piles de protocoles de communication événementielle nécessitent toujours un filetage ou des systèmes d'exploitation multi-tâches. Les PLC classiques ne sont généralement pas dotés de tels systèmes d'exploitation. Les applications modernes "soft PLC" sont des applications exécutées sur des IPC (PC industriels ou ordinateurs sans clavier, souris ni moniteur qui sont souvent montés des rails DIN)  fonctionnant sous Linux. Bien que de tels systèmes puissent gérer efficacement les piles de protocoles TCP/IP, il est recommandé de séparer strictement la communication IoT industrielle basée sur des messages et le contrôle du logiciel. Les passerelles constituent une solution idéale pour séparer le réseau et le logiciel. Une passerelle peut se comporter comme n'importe quel périphérique pour le PLC (communiquant avec son protocole de bus de terrain) et se connecter à l'internet basé sur les messages de l'autre côté. Les passerelles sont souvent l’endroit où la sécurité rencontre la sûreté, mais nous en parlerons dans la troisième partie...

Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (and his MD grade). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.

19 Jun 2019, 6:33

Commentaires