Communication Protocols
We develop products for a wide range of communication protocols, with particular expertise in M-Bus and Modbus. We have extensive experience in this field and continuously strive to develop easy-to-use and user-friendly products.
Here you can find more detailed information about the protocols we work with on a daily basis. If you have any questions about the protocols or how they are structured, please do not hesitate to ask us. We also welcome your feedback for future development.
The M-Bus electrical interface was developed at the University of Paderborn, Germany, under the direction of Professor Dr Horst Ziegler. M-Bus, or Meter-Bus as it is actually called, is a European standard for remote reading of heat meters and other types of consumption meters. M-Bus can also be used to read various modules, such as pulse converters, analogue/digital input modules, etc.
M-Bus is a cost-effective fieldbus for transferring consumption data from various types of meters. A central master, such as a PC with an Ethernet-to-M-Bus converter or an RS232-to-M-Bus converter, communicates via a 2-wire bus with the devices (up to 250 load units per segment), such as heat meters, water meters, electricity meters, gas meters and other types of meters.
More and more manufacturers are implementing the M-Bus electrical interface in their meters. M-Bus is a European standard described in standards EN1434-3, EN13757-1, -2, -3, -4, -5, -6
Modbus has its roots in the late 1970s. During the protocol's development, disagreements arose between the two companies that developed it. This resulted in the development of a Modbus variant called Jbus. The main difference is that the register address is offset by one, which often, even today, causes considerable confusion.
Initially, communication took place exclusively via RS232, but support for RS485 was introduced fairly soon, enabling multi-drop, longer cables and higher speeds. Support for Modbus over TCP was later added, which involved adding an extra block to the message. The most important part of this extra block is a so-called transaction ID, which makes traffic over TCP more secure from a communications perspective.
A few years ago, many people thought that Modbus would die out because it is an old protocol. What has happened instead is that Modbus has experienced a renaissance and is now used in a great many different contexts. Modbus is one of the few protocols that is truly widely used on every continent.
The M-Bus ASCII protocol was developed by PiiGAB to simplify the reading of M-Bus meters without having to install a traditional M-Bus driver.
The protocol is a typical request/response protocol. Requests can be sent via serial or UDP/TCP communication. The requests consist of so-called OPC Items, which are sent as ASCII strings. These strings are then encoded according to the OPC standard, after which the meter response is returned as a string. These values can then easily be presented on a display or website.
OPC is a compatible standard for securely and reliably exchanging data in industrial automation and other automation contexts. It is platform-independent and ensures a seamless flow of information between devices from different manufacturers. The OPC Foundation is responsible for developing and maintaining the standard. The OPC standard consists of a number of standard specifications developed through collaboration between a large number of world-leading automation suppliers, end users and software developers. The specifications define the interfaces between clients and servers and between servers and servers, including access to real-time data, the display of alarms and events, and access to historical data and other applications.
When the standard was first released in 1996, its purpose was to transfer PLC-specific protocols, such as Modbus and Profibus, to a standardised interface. This made it possible for HMI/SCADA systems to communicate through an "intermediate layer" that could convert general OPC read and write requests into protocol-specific equivalents and vice versa.
Initially, the OPC standard was limited to Windows operating systems. As a result, the standard was based on OLE COM (Component Object Model) and DCOM (Distributed Component Object Model) technologies. These specifications are now known as OPC Classic and have had a major impact across many industries, including manufacturing, building automation, oil and gas, renewable energy and many others.
With the introduction of service-oriented architectures in manufacturing systems, new challenges arose in the areas of security and data modelling. The OPC Foundation developed the OPC UA specifications to meet these needs while also creating a feature-rich technology with an open platform architecture that is future-proof, scalable and extensible.
These are just some of the reasons why so many OPC members and other technology organisations are switching to OPC UA because of its flexible platform.
If you would like to learn more about OPC, please visit www.opcfoundation.org PiiGAB has extensive experience in communications and drivers for most common types of facilities. This ranges from building automation to heavy industrial production. Water and wastewater facilities, including dial-up connections to pumping stations, are also within our area of expertise.
We have worked with Citect since the late 1990s, primarily within our specialist area of communications and drivers. We have developed several Citect drivers all the way from basic specifications to beta-tested, finished drivers. We have also modified and supplemented a number of drivers. In addition, we have been project managers for the development of approximately thirteen different Citect drivers. If you need a new Citect driver or other communications assistance, please contact us.