Recherche information sur des PLC Distech Control

[Kallysto]

Bonjour,

Je recherche des info sur des PLC Distech Control. J'ai épluché les doc dispo en ligne mais certains questions restent en suspend.
Et je préfère ne pas joindre la société directement... j'ai déjà tenté l'expérience avec d'autres et depuis j'ai le commercial qui m'harcèle pour que j'accepte un rdv pour me présenter un produit dont je ne veux pas... et ça dure depuis 3 ans.

Si vous avez tout ou une partie des réponses, je prends !

• Est-il possible de paramétrer les PLC en DHCP ?
• Est-il capable de communiquer avec d'autres PLC en DHCP ? C'est à dire en faisant une requête "Query IP Name" avec le nom de l'automate avec lequel on souhaite communiquer pour en obtenir l'adresse IP ?
• Est-il capable de communiquer avec un serveur OPC (modbus TCP/IP) ?
• Existe-t'il des modules "room" qui ne communiquent pas via TCP/IP mais via un bus de terrain ?
• Les modules "room" sont-ils préprogrammés ou peut-on les programmer intégralement comme on le souhaite ?

Merci pour votre aide.

[tuscaonline]

oui a toute les réponse.
Pour ton point 2 il faut que ton serveur DNS? soit mis a jour par le DHCP, souvent quand tu demandes ca aux informaticiens ils te regardent sans comprendre.

[Kallysto]

oui a toute les réponse.

Il existe donc des modules pour "pièce" qui ne sont pas ethernet ? Je n'en trouve pas trace sur le site, pour ça que je te redemande.

Pour ton point 2 il faut que ton serveur DNS? soit mis a jour par le DHCP, souvent quand tu demandes ca aux informaticiens ils te regardent sans comprendre.

Oui, parce que ça n'a pas vraiment de sens en fait... Le serveur DNS est une entité indépendante qui met à jour sa liste automatiquement. Le service DHCP fournit uniquement l'adresse IP à laquelle on peut joindre le serveur DNS.

Et sont-ils capables de communiquer en modbus en étant dans des sous réseaux différents ?

Genre :
PLC 1 : 172.26.169.106 / 255.255.255.128
PLC 2 : 172.26.82.37 / 255.255.255.128

Parce que pareil que plus haut, il est dit sur leur site qu'il faut qu'ils soient dans le même sous réseau. Si c'est bien le cas, c'est mort.

[tuscaonline]

T'as les ECB-PTU en Bacnet MS/TP pour faire des Room
Les router bacnet loytec integre le bbmd qui permet d'éviter les probleme avec les DSI qui ne comprenne pas le routage des paquet broadcast.

Disctech c'est assez proche de niagara, ca fait tres bien du Modbus.

[Kallysto]

T'as les ECB-PTU en Bacnet MS/TP pour faire des Room
Les router bacnet loytec integre le bbmd qui permet d'éviter les probleme avec les DSI qui ne comprenne pas le routage des paquet broadcast.

Disctech c'est assez proche de niagara, ca fait tres bien du Modbus.

On ne veut pas du BacNet : trop de risques d'emmerdes.
Et interdiction d'avoir des équipements de réseau informatique autre qu'un simple switch pour faire la liaison PLC - HMI.

Le réseau info ne m'appartient pas, il est géré par un service à part. J'ai juste le droit de demander une adresse IP dessus (à condition de ne pas foutre le bordel avec des trames broadcast entre autres).
Et mes équipements sont régulièrement "scannés" par le service sécurité informatique pour vérifier leur fiabilité. Du coup quand il y a une couille de sécurité sur un firmware, en général, c'est moi qui la signale... puisque j'ai la sécurité info qui me tombe dessus.

[Dorlis]

T'as les ECB-PTU en Bacnet MS/TP pour faire des Room
Les router bacnet loytec integre le bbmd qui permet d'éviter les probleme avec les DSI qui ne comprenne pas le routage des paquet broadcast.

Disctech c'est assez proche de niagara, ca fait tres bien du Modbus.

On ne veut pas du BacNet : trop de risques d'emmerdes.
Et interdiction d'avoir des équipements de réseau informatique autre qu'un simple switch pour faire la liaison PLC - HMI.

Le réseau info ne m'appartient pas, il est géré par un service à part. J'ai juste le droit de demander une adresse IP dessus (à condition de ne pas foutre le bordel avec des trames broadcast entre autres).
Et mes équipements sont régulièrement "scannés" par le service sécurité informatique pour vérifier leur fiabilité. Du coup quand il y a une couille de sécurité sur un firmware, en général, c'est moi qui la signale... puisque j'ai la sécurité info qui me tombe dessus.

Tu peux développer sur ce qui t'enmmerde sur le BacNet?

[Kallysto]

Tu peux développer sur ce qui t'enmmerde sur le BacNet?

C'est un langage objet qui en plus n'est pas figé.
Au lieu d'aller simplement chercher la valeur d'une case mémoire, on récupère des objets "température", "vanne", etc.
Depuis le départ du BacNet le contenu de ces objets a énormément évolué : par exemple une sonde de température, au départ l'objet BacNet était uniquement la valeur de la sonde et si elle était en alarme ou pas. Maintenant c'est la valeur de la sonde, une alarme haute, une alarme basse, et les 2 seuils qui vont avec.

En théorie les versions de BacNet sont compatibles entre elles. En pratique c'est si le fabricant a bien fait son taff et n'a pas foutu aux oubliettes une partie des points de la norme. Et même comme ça, les modifications d'installations ne sont pas si simples : il est difficile d'évoluer d'une version à une autre sans tout refaire.

Cette année, juste cette année, j'ai eu sur mon site 27 chantiers qui ont impliqués de l'automatisme :

• 9 suppressions totales (2 bâtiments détruits,1 réfection complète d'un bâtiment)
• 2 constructions de bâtiments pour un total d'ajout de 18 PLC,
• 3 nouvelles installations complètement nouvelles (armoire + équipements pilotés) qui interagissent avec 6 autres installations d'âge divers,
• 8 rénovations / ajouts d'installations sur des PLC existants d'âge divers (de 2012 à 2022),
• 5 rénovations / créations totales : dépose de l'ancienne régulation si existante, changement et recâblage complet des anciens capteurs et actionneurs

Et ça c'est sans compter l'ensemble des opérations de maintenance sur un ensemble de 162 ha avec :

• 260 bâtiments tertiares et 77 barraques (une baraque étant un préfabriqué plus ou moins amélioré)
• une chaufferie de 3 chaudières de 15 MW et son réseau de chauffage de 20 km,
• une chaufferie de 3 chaudières de 5MW et son réseau de chauffage de 5 km,
• 150 sous-stations de chauffage,
• 150 réseaux de radiateurs,
• 300 unités de traitement d'air,
• 50 unités de chauffage de l'air,
• 1 000 unités de climatisation,
• 500 systèmes d'extraction,
• 100 unités de production d'eau glacée,
• 1 district de refroidissement 2MW,
• 200 unités de production d'eau chaude sanitaire,
• 20 adoucisseurs d'eau,
• 30 humidificateurs,
• 100 panneaux solaires,
• 700 cellules d'alimentation électrique et de contrôle,
• 370 automates programmables (nouvelle génération - installations faites depuis 2012, sinon les installations les plus vieilles datent de 1957),
• 30 000 capteurs et actionneurs.

Bien que catégorisées comme "tertiaires" nos installations vont du simple réseau radiateurs à eau chaude aux salles blanches avec température, humidité et pression contrôlées.

Et pour gérer tout ça, on est 3 :

• Moi qui suit embauchée par l'organisation qui gère ce site,
• l'automaticien de la société contractante pour la maintenance et une partie des travaux HVAC,
• l'automaticien de la société contractante pour la maintenance et les travaux électriques (éclairage)

BREF.
J'ai suffisamment de fun dans ma vie pour ne pas me prendre le choux avec des versions de BacNet.
Le Modbus c'est nickel : une adresse de machine, une adresse mémoire, et tu as la valeur. C'est compatible avec tout le monde.
Sauf la dernière gamme de siemens dédiés HVAC où ils sont repartis 30 ans en arrière pour le Modbus TCP/IP en le bloquant avec des PLC qui ne peuvent être que serveur ou que client. Ce qui est ultra bloquant pour la maintenance comme pour les travaux.

j'ajoute qu'il y a également l'aspect financier à prendre en compte.
Par exemple, il existe depuis pas mal d'années des vannes et des pompes qui fonctionnent en modbus RTU. En théorie on gagne de l'argent : 1 alimentation et un bus à tirer seulement par équipement et pour les vannes, elles peuvent faire compteurs d'énergie ce qui évite d'en ajouter un. Et moins de cartes de sorties.

Problème : la maintenance.

Une vanne, une pompe ne démarre pas, un technicien de maintenance va vérifier l'alimentation, et le pilotage : le 0/10V arrive-t-il bien sur la vanne ? oui -> vanne HS, non-> décablage au bornier de l'armoire et vérification au bornier -> si OK au bornier alors problème de câble ou de vanne, si NOK vérification au cul de la carte de sortie -> si OK vérification dans l'armoire si NOK appel à l'automaticien.

Avec une vanne modbus, la seule chose que sait vérifier seul le technicien de maintenance c'est l'alimentation et la continuité du bus. Pour tout le reste, il faut faire appel à un automaticien.
Ce qui voudrait dire donc que pour mon site, il me faudrait à temps plein entre 3 et 6 automaticiens. Le surcoût serait énorme.

En général, quand une société de maintenance a autant d'installations sous sa coupe, elle a effectivement 3 à 6 automaticiens... mais également ces installations sont réparties sur au moins 30 clients, nous, on est un seul client pour payer la facture.

Donc ouais, pour plein de trucs je peux faire "vieux jeu" mais c'est pas "parce que c'était mieux avant", c'est parce que les solutions modernes et ultra technologiques ont un coût totalement délirants sur un site aussi énorme que le mien.

[Dorlis]

Tu peux développer sur ce qui t'enmmerde sur le BacNet?

C'est un langage objet qui en plus n'est pas figé.
Au lieu d'aller simplement chercher la valeur d'une case mémoire, on récupère des objets "température", "vanne", etc.
Depuis le départ du BacNet le contenu de ces objets a énormément évolué : par exemple une sonde de température, au départ l'objet BacNet était uniquement la valeur de la sonde et si elle était en alarme ou pas. Maintenant c'est la valeur de la sonde, une alarme haute, une alarme basse, et les 2 seuils qui vont avec.

En théorie les versions de BacNet sont compatibles entre elles. En pratique c'est si le fabricant a bien fait son taff et n'a pas foutu aux oubliettes une partie des points de la norme. Et même comme ça, les modifications d'installations ne sont pas si simples : il est difficile d'évoluer d'une version à une autre sans tout refaire.

Cette année, juste cette année, j'ai eu sur mon site 27 chantiers qui ont impliqués de l'automatisme :

• 9 suppressions totales (2 bâtiments détruits,1 réfection complète d'un bâtiment)
• 2 constructions de bâtiments pour un total d'ajout de 18 PLC,
• 3 nouvelles installations complètement nouvelles (armoire + équipements pilotés) qui interagissent avec 6 autres installations d'âge divers,
• 8 rénovations / ajouts d'installations sur des PLC existants d'âge divers (de 2012 à 2022),
• 5 rénovations / créations totales : dépose de l'ancienne régulation si existante, changement et recâblage complet des anciens capteurs et actionneurs

Et ça c'est sans compter l'ensemble des opérations de maintenance sur un ensemble de 162 ha avec :

• 260 bâtiments tertiares et 77 barraques (une baraque étant un préfabriqué plus ou moins amélioré)
• une chaufferie de 3 chaudières de 15 MW et son réseau de chauffage de 20 km,
• une chaufferie de 3 chaudières de 5MW et son réseau de chauffage de 5 km,
• 150 sous-stations de chauffage,
• 150 réseaux de radiateurs,
• 300 unités de traitement d'air,
• 50 unités de chauffage de l'air,
• 1 000 unités de climatisation,
• 500 systèmes d'extraction,
• 100 unités de production d'eau glacée,
• 1 district de refroidissement 2MW,
• 200 unités de production d'eau chaude sanitaire,
• 20 adoucisseurs d'eau,
• 30 humidificateurs,
• 100 panneaux solaires,
• 700 cellules d'alimentation électrique et de contrôle,
• 370 automates programmables (nouvelle génération - installations faites depuis 2012, sinon les installations les plus vieilles datent de 1957),
• 30 000 capteurs et actionneurs.

Bien que catégorisées comme "tertiaires" nos installations vont du simple réseau radiateurs à eau chaude aux salles blanches avec température, humidité et pression contrôlées.

Et pour gérer tout ça, on est 3 :

• Moi qui suit embauchée par l'organisation qui gère ce site,
• l'automaticien de la société contractante pour la maintenance et une partie des travaux HVAC,
• l'automaticien de la société contractante pour la maintenance et les travaux électriques (éclairage)

BREF.
J'ai suffisamment de fun dans ma vie pour ne pas me prendre le choux avec des versions de BacNet.
Le Modbus c'est nickel : une adresse de machine, une adresse mémoire, et tu as la valeur. C'est compatible avec tout le monde.
Sauf la dernière gamme de siemens dédiés HVAC où ils sont repartis 30 ans en arrière pour le Modbus TCP/IP en le bloquant avec des PLC qui ne peuvent être que serveur ou que client. Ce qui est ultra bloquant pour la maintenance comme pour les travaux.

j'ajoute qu'il y a également l'aspect financier à prendre en compte.
Par exemple, il existe depuis pas mal d'années des vannes et des pompes qui fonctionnent en modbus RTU. En théorie on gagne de l'argent : 1 alimentation et un bus à tirer seulement par équipement et pour les vannes, elles peuvent faire compteurs d'énergie ce qui évite d'en ajouter un. Et moins de cartes de sorties.

Problème : la maintenance.

Une vanne, une pompe ne démarre pas, un technicien de maintenance va vérifier l'alimentation, et le pilotage : le 0/10V arrive-t-il bien sur la vanne ? oui -> vanne HS, non-> décablage au bornier de l'armoire et vérification au bornier -> si OK au bornier alors problème de câble ou de vanne, si NOK vérification au cul de la carte de sortie -> si OK vérification dans l'armoire si NOK appel à l'automaticien.

Avec une vanne modbus, la seule chose que sait vérifier seul le technicien de maintenance c'est l'alimentation et la continuité du bus. Pour tout le reste, il faut faire appel à un automaticien.
Ce qui voudrait dire donc que pour mon site, il me faudrait à temps plein entre 3 et 6 automaticiens. Le surcoût serait énorme.

En général, quand une société de maintenance a autant d'installations sous sa coupe, elle a effectivement 3 à 6 automaticiens... mais également ces installations sont réparties sur au moins 30 clients, nous, on est un seul client pour payer la facture.

Donc ouais, pour plein de trucs je peux faire "vieux jeu" mais c'est pas "parce que c'était mieux avant", c'est parce que les solutions modernes et ultra technologiques ont un coût totalement délirants sur un site aussi énorme que le mien.

Ok tu gères une petite ville en fait, d'ailleurs je serais curieux de savoir ce que vous avez comme supervision pour gérez tout ça?
Je comprends ta position surtout d'un point de vue maintenance, j'imagines que du coup tu dois te faire c**** avec des drivers, des passerelles etc...
Après je pense que pour le développement ça reste quand même bien plus simple, tu n'as pas besoin de t'embêter avec des adresses, à harceler les fabricants pour avoir la bonne table de la bonne version, puisque tout est dans l'automate. Il n'y a pas non plus de retraitement à faire pour exploiter les datas.

[Kallysto]

Ok tu gères une petite ville en fait, d'ailleurs je serais curieux de savoir ce que vous avez comme supervision pour gérez tout ça?
Je comprends ta position surtout d'un point de vue maintenance, j'imagines que du coup tu dois te faire c**** avec des drivers, des passerelles etc...
Après je pense que pour le développement ça reste quand même bien plus simple, tu n'as pas besoin de t'embêter avec des adresses, à harceler les fabricants pour avoir la bonne table de la bonne version, puisque tout est dans l'automate. Il n'y a pas non plus de retraitement à faire pour exploiter les datas.

Pourquoi se faire chier avec des drivers et des passerelles quand le modbus IP existe ?
Il est simple, rapide, efficace.

Et non, en fait c'est pas si simple que ça à utiliser le BACNet. Il y a plein de petits paramètres qui peuvent faire que ça ne marchera pas ou qu'une modification ou un ajout sur l'automate devienne une tannée.

Il n'y a ni bacnet, ni lonworks sur nos installations, ni M-Bus, ni rien. C'est modbus RTU ou modbus IP. Tous les équipements qu'on installe sont Modbus nativement.
Les automates sont nativement modbus IP et modbus RTU, et les équipements types compteurs, etc eux sont modbus RTU. Rien d'autres que nos automates et nos écrans sur le réseau IP. Sinon de toute manière à un moment ou un autre, ils font connaissance avec les "scans" du service sécurité informatique et ça se passe mal.

Pas de supervision. Pourquoi faire ?

Mes automates ont chacun 2 bits d'alarmes : 1 et 2. L'un déclenche la maintenance 24/24, l'autre la maintenance en heures ouvrées.
Ils sont remontés via un serveur OPC qui communique toutes les 5 à 10s avec les automates (pas besoin de plus).
Ensuite, on a un outil qui vient lire le serveur OPC, le filtre et vient afficher le tout au centre de contrôle qui fait les demandes de maintenance et les appels d'astreinte.

Et à partir de là, soit on consulte à distance ou sur l'écran tactile sur place les pages web des automates. Chaque automate intègre un serveur Web dans lequel on développe une interface complète : pages de visualisation, pages de paramètres, popup de réglages, listes d'alarmes, listes de défauts, etc.

Et pour les valeurs à enregistrer, je peux le faire via le même outil que celui qui lit mes alarmes. Simplement, au lieu d'être envoyé au centre de contrôle, ça va dans le système de data tracking interne qui enregistre une valeur toutes les minutes (je peux le faire plus rapide, mais aucun intérêt).
Ensuite j'ai encore un outil interne qui me permet d'aller voir les enregistrements, de tracer les courbes que je voudrais tracer et de faire des exports au format CSV.

Chaque automate vient écrire à une adresse précise qui lui est réservé dans un automate de surveillance 2 registres : un mot de vie et un registre de synthèse : alarmes en cours, modes actifs sur l'installation (éco, urgence, etc), etc. Et lire 2 mots d'instructions (passage en mode Eco, stop, etc).
L'automate de surveillance nous permet de vérifier si tous les automates sont en route, combien sont en alarmes, combien sont hors réseau, combien sont en mode Eco, etc. Petit script en IL dans l'automate de surveillance qui compte ça.
Chaque automate de surveillance peut ainsi surveiller et piloter 250 automates "classiques".
Le tout en modbus IP et en DHCP.

Et actuellement je travaille avec un autre service, celui qui nous fait notre version interne de "google maps" pour qu'on puisse afficher sur un calque qui nous serait réservé des points avec les PLC : vert (installation en fonctionnement), jaune (alarme niveau 1), rouge (alarme niveau 2), fushia (hors réseau / HS), bleu (mode manuel actif).
Et nous faire un lien avec les pages web de l'installation quand on clique dessus.

Bref, j'ai pas besoin d'une supervision. En plus vu le nombre de chantier et de maintenance en même temps sur le site, pour tenir à jour une supervision ça serait l'horreur. Le seul moyen pour éviter qu'un intégrateur vienne écraser le travail d'un autre ça serait que ça soit une seule entreprise qui fasse la supervision et on se retrouverait pieds et poings liés avec cette entreprise puisque les chantiers ne s'arrêtent jamais chez nous. Situation de monopole et en plus ça nous coûterait un pognon de dingue.

Oui, on se compare souvent à une ville. Il y a environ entre 14 000 et 18 000 personnes qui viennent bosser ici tous les jours suivant les périodes. Et là où j'habite, la ville ne compte que 11 000 habitants.

Et oui, quand on gère des monstres pareil, on se rend compte de plusieurs choses :

• plus c'est simple, mieux on se porte.
• L'hyper technologie n'est pas toujours la solution,
• si on ne réfléchit pas sur le long terme, on se prend un retour de bâton qui coûte très cher
• Il y a masse de systèmes qu'on utilise de partout qui sont en fait pas si indispensables que ça

[itasoft]

slts,
Comment la Kallysto arrive à écrire toutes ces lignes de texte ? Je tape avec un seul doigt et après 5 lignes de texte je suis au bord de l’épuisement