Dessiner un schéma d'architecture — Supprimer les suppositions entre les intervenants et poser la base des étapes suivantes

Dernière mise à jour: 2026-09-25 ／ Catégorie: Conception de systèmes FA, matériel de commande

Un schéma d'architecture permet au tableautier, au programmeur et à l'installateur de commencer les commandes et les réglages sur les mêmes hypothèses. Ce guide s'adresse à ceux qui se partagent avec d'autres les réglages de communication et l'approvisionnement des équipements.

1. Sans schéma, chaque intervenant commence à travailler sur ses propres suppositions

Quand un automate (PLC) et un robot ne communiquent pas, deux causes reviennent sans cesse. Soit la même adresse IP a été mise dans les deux appareils, soit les deux ont été configurés en maître de la communication. Dans les deux cas, un réglage qui doit concorder aux deux extrémités a été décidé séparément par des personnes différentes.

Le tableautier suppose d'après l'armoire précédente, le programmeur d'après le projet précédent, l'installateur d'après les plans qu'il a sous la main. On découvre en général qu'une supposition était fausse quand le réseau ne monte pas sur site. Le schéma d'architecture est la page qui supprime ces suppositions avant la commande et le câblage. Il y a trois raisons de le dessiner.

2. Trois raisons de dessiner le schéma

① Décider en un seul endroit les réglages que les deux extrémités doivent partager

La première raison est de décider, sur le schéma, chaque réglage qui doit concorder aux deux extrémités d'un câble. Adresses IP et numéros de station, maître et esclave, sens des ports. Aucun ne fonctionne quand un seul côté est correct.

Pourquoi c'est nécessaire — Les deux extrémités sont configurées par des personnes différentes avec des logiciels différents. Le programmeur règle l'automate, le roboticien le robot, le tableautier le switch. Si les deux valeurs ne sont pas côte à côte sur une page, le désaccord n'est trouvé qu'une fois sur site.

② Montrer les frontières de responsabilité et les contraintes physiques

La deuxième raison est de faire apparaître sur le schéma qui commande quoi et qui en est responsable. Où s'arrête le réseau usine et où commence le réseau de commande. Si le switch a assez de ports. Si le nombre d'appareils en chaîne et le sens du câblage restent dans les règles du protocole.

Pourquoi c'est nécessaire — Quand les frontières et les quantités sont dispersées dans les plans et tableaux de chacun, personne ne les compte. Le service informatique du client s'occupe des règles du réseau, le tableautier du nombre de ports, le programmeur des limites d'appareils. Sur une page, on repère un oubli de commande, ou le trafic de commande qui inonde le réseau usine, avant que cela n'arrive.

③ Fixer d'abord la base de la conception logicielle

La troisième raison est de fixer l'ossature du système avant que la conception logicielle ne commence. Les équipements du schéma et leurs groupes deviennent les partitions de la cartographie des adresses. Les signaux échangés entre équipements deviennent les lignes du chronogramme.

Pourquoi c'est nécessaire — Tant que l'ossature n'est pas fixée, ni l'affectation des variables ni la séquence ne peuvent être décidées. Ajoutez un équipement et vous ajoutez une partition et des lignes de signaux. Changez l'architecture plus tard, et vous corrigerez à la fois la cartographie des adresses et le chronogramme.

3. Ce qu'on écrit sur le schéma

• Sur chaque liaison : le protocole et le câble — Le protocole détermine les ports, le switch et le logiciel de configuration. Le type de câble (STP, M12, fibre, etc.) sert à l'approvisionnement de l'installateur
• Sur chaque équipement : l'emplacement et l'adresse — L'emplacement détermine qui tire le câble et sa longueur. Écrivez les adresses IP et les numéros de station à côté de l'équipement auquel ils se connectent, pas dans un tableau à part
• Maître / esclave par liaison, pas par équipement — Un même appareil peut être esclave sur une liaison et maître sur une autre (voir ci-dessous)
• La topologie telle qu'elle est réellement câblée — En étoile par un switch, ou en chaîne. Certains protocoles, comme EtherCAT, distinguent le port IN du port OUT
• La frontière avec le réseau de l'usine — Quel équipement se connecte au réseau amont, et où se fait la coupure. Cela se convient avec le client ; sans la frontière sur le schéma, la discussion ne peut pas commencer
• Le circuit de sécurité — Les signaux d'arrêt d'urgence et de porte de protection passent-ils par un câblage dédié ou par un protocole de sécurité (CIP Safety, FSoE, etc.). C'est la première chose que regarde une revue de sécurité

4. Dessinez dans cet ordre : emplacements → câblage → adresses → frontière → comptage

1. Groupez les équipements par emplacement Armoire de commande, boîte de jonction, sur machine, amont (réseau usine), etc.
2. Reliez-les comme ils sont réellement câblés Dessinez l'étoile par un switch ou la chaîne telle quelle.
3. Écrivez le protocole et le maître sur chaque liaison, l'adresse sur chaque équipement Écrivez le sous-réseau avec l'adresse IP.
4. Écrivez la frontière avec le réseau de l'usine et le circuit de sécurité Envoyez dès cette étape en validation ce qui doit être convenu avec le client.
5. Comptez et vérifiez Comptez sur le schéma les ports du switch, les appareils en chaîne et les adresses en double. Prévoyez un port pour le PC de maintenance.

5. Où l'on trébuche : sens des ports, switch partagé, sous-réseaux, nombre d'appareils

• Ports IN et OUT d'EtherCAT inversés — Soit le réseau ne monte pas, soit l'ordre des appareils ne correspond pas à la configuration. Dessinez le sens des ports sur le schéma
• Réseau de commande et réseau usine sur le même switch — Le trafic de commande inonde tous les appareils, car un switch sans IGMP snooping n'arrête pas le multicast EtherNet/IP. Séparez le côté commande du côté amont, ou utilisez un switch qui le gère
• Ne pas voir une différence de sous-réseau — Des appareils sur le même câble ne peuvent pas se parler si leurs sous-réseaux diffèrent. Écrivez le sous-réseau avec l'adresse et vous le verrez sur le schéma
• Trop d'appareils sur une liaison — Chaque protocole a des limites sur le nombre d'appareils en chaîne et sur le temps de cycle. Comptez les appareils et le cycle sur le schéma et vérifiez-les par rapport à la spécification

Articles connexes

• Construire une cartographie des adresses
• Dessiner un chronogramme
• Dessiner un organigramme de commande d'automate
• Faire dessiner la spécification par une IA
• Structure des données JSON — Le format que lisent et écrivent les quatre éditeurs, avec schéma, validation et exemples
• Rédiger une spécification de commande

yk.builds