Protocoles de communication
Nous développons des produits prenant en charge de nombreux protocoles de communication, avec une expertise particulière notamment en M-Bus et Modbus. Nous possédons une très longue expérience dans ce domaine et nous nous efforçons continuellement de développer des produits faciles à utiliser et conviviaux.
Vous trouverez ici des informations plus détaillées sur les protocoles que nous utilisons au quotidien. Si vous avez des questions concernant les protocoles ou leur structure, n'hésitez pas à nous les poser. Nous accueillons également avec plaisir vos commentaires pour nos développements futurs.
L'interface électrique M-Bus a été développée à l'Université de Paderborn, en Allemagne, sous la direction du professeur Dr Horst Ziegler. M-Bus, ou Meter-Bus comme il s'appelle officiellement, est une norme européenne pour le relevé à distance des compteurs d'énergie thermique et d'autres types de compteurs de consommation. M-Bus peut également être utilisé pour relever différents modules, tels que des convertisseurs d'impulsions, des modules d'entrée analogique/numérique, etc.
M-Bus est un bus de terrain économique permettant de transmettre les données de consommation provenant de différents types de compteurs. Un maître central, par exemple un PC équipé d'un convertisseur Ethernet vers M-Bus ou RS232 vers M-Bus, communique via un bus à 2 fils avec les appareils (jusqu'à 250 unités de charge par segment), tels que des compteurs d'énergie thermique, des compteurs d'eau, des compteurs électriques, des compteurs de gaz et d'autres types de compteurs.
De plus en plus de fabricants intègrent l'interface électrique M-Bus dans leurs compteurs. M-Bus est une norme européenne décrite dans les normes EN1434-3, EN13757-1, -2, -3, -4, -5, -6
Modbus trouve ses origines à la fin des années 1970. Au cours du développement du protocole, des divergences sont apparues entre les deux entreprises qui le développaient. Cela a conduit à la création d'une variante de Modbus, appelée Jbus. La principale différence réside dans le décalage de un de l'adresse des registres, ce qui pose souvent, encore aujourd'hui, de nombreux problèmes.
Au début, la communication s'effectuait uniquement via RS232, mais la prise en charge de RS485 est rapidement apparue, permettant le multi-drop, des câbles plus longs et des vitesses plus élevées. La prise en charge de Modbus sur TCP a ensuite été ajoutée, avec l'introduction d'un bloc supplémentaire dans le message. La partie la plus importante de ce bloc supplémentaire est un identifiant de transaction, qui rend le trafic TCP plus sûr du point de vue de la communication.
Il y a quelques années, beaucoup pensaient que Modbus allait disparaître parce qu'il s'agissait d'un ancien protocole. Pourtant, Modbus a connu une renaissance et est aujourd'hui utilisé dans de très nombreux contextes. Modbus est l'un des rares protocoles véritablement largement utilisés sur tous les continents.
Le protocole M-Bus ASCII a été développé par PiiGAB afin de faciliter la lecture des compteurs M-Bus, sans avoir à installer un pilote M-Bus traditionnel.
Le protocole est typiquement basé sur un modèle question/réponse. Les questions peuvent être envoyées via une communication série ou UDP/TCP. Elles sont constituées de ce que l'on appelle des OPC Items, envoyés sous forme de chaînes ASCII. Ces chaînes sont ensuite encodées conformément à la norme OPC, puis la réponse du compteur est renvoyée sous forme de chaîne. Ces valeurs peuvent alors être facilement affichées sur un écran ou un site web.
OPC est une norme compatible permettant d'échanger des données de manière sûre et fiable dans l'automatisation industrielle et dans d'autres contextes d'automatisation. Elle est indépendante des plateformes et garantit un flux d'informations fluide entre des appareils de différents fabricants. L'OPC Foundation est responsable du développement et de la maintenance de la norme. La norme OPC se compose d'un ensemble de spécifications standard développées grâce à une collaboration entre de nombreux fournisseurs mondiaux de solutions d'automatisation, utilisateurs finaux et développeurs de logiciels de premier plan. Les spécifications définissent l'interface entre les clients et les serveurs ainsi qu'entre les serveurs, notamment l'accès aux données en temps réel, l'affichage des alarmes et des événements, ainsi que l'accès aux données historiques et à d'autres applications.
Lors de sa première publication en 1996, la norme avait pour objectif de transférer les protocoles spécifiques aux automates programmables industriels, tels que Modbus et Profibus, vers une interface standardisée. Cela permettait aux systèmes HMI/SCADA de communiquer via une « couche intermédiaire » capable de convertir les requêtes OPC génériques de lecture et d'écriture en équivalents spécifiques aux protocoles, et inversement.
À l'origine, la norme OPC était limitée aux systèmes d'exploitation Windows. Elle reposait donc sur les technologies OLE COM (modèle objet composant) et DCOM (modèle objet composant distribué). Ces spécifications sont désormais appelées OPC Classic et ont connu un grand succès dans de nombreux secteurs, notamment l'industrie manufacturière, l'automatisation des bâtiments, le pétrole et le gaz, les énergies renouvelables, ainsi que bien d'autres.
Avec l'introduction des architectures orientées services dans les systèmes de production, de nouveaux défis sont apparus en matière de sécurité et de modélisation des données. L'OPC Foundation a développé les spécifications OPC UA pour répondre à ces besoins tout en créant une technologie riche en fonctionnalités, dotée d'une architecture ouverte, indépendante des plateformes, évolutive et extensible.
Ce ne sont là que quelques-unes des raisons pour lesquelles de nombreux membres de l'OPC et d'autres organisations technologiques migrent vers OPC UA pour bénéficier de sa plateforme flexible.
Si vous souhaitez en savoir plus sur OPC, consultez le site www.opcfoundation.org. PiiGAB possède une très longue expérience en matière de communication et de pilotes pour la plupart des types d'installations courants. Cela va de l'automatisation des bâtiments aux environnements de production industrielle les plus exigeants. Les installations d'eau et d'assainissement, avec la numérotation associée vers les stations de pompage, font également partie de notre domaine d'activité.
Nous travaillons avec Citect depuis la fin des années 1990, principalement dans notre domaine de spécialité : la communication et les pilotes. Nous avons développé plusieurs pilotes Citect, depuis les spécifications initiales jusqu'à la version bêta testée et au pilote finalisé. Nous avons également adapté et complété plusieurs pilotes. En outre, nous avons été chefs de projet pour le développement d'environ treize pilotes Citect différents. Si vous avez besoin d'un nouveau pilote Citect ou d'une autre assistance en matière de communication, contactez-nous.