Communication Protocols
We work on developing products within a range of different communication protocols, with expertise in, among others, M-Bus and Modbus. We have extensive experience in this area 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 and their structure, do not hesitate to ask us. We also gladly welcome your feedback for future development.
The electrical interface M-Bus was developed at the University of Paderborn, Germany, under the leadership of Professor Dr. Horst Ziegler. M-Bus, or Meter-Bus as it is properly called, is a European standard for remote reading of heat meters or other types of consumption meters. M-Bus can also be used to read various modules such as pulse converters, analog/digital input signal modules, and more.
M-Bus is a cost-effective fieldbus for transferring consumption data from various types of meters. A central master, for example a PC with a converter from Ethernet to M-Bus, or alternatively RS232 to M-Bus, communicates via a 2-wire bus with the units (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 electrical interface M-Bus 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 phase, disagreements arose between the two companies that developed the protocol. This resulted in a variant of Modbus being developed, namely Jbus. The main difference is that the register address has an offset of one, which often, even today, causes quite a bit of confusion.
Initially, communication was only via RS232, but soon support for RS485 was added, allowing multi-drop, longer cables, and higher speeds. Over time, support for Modbus over TCP was also introduced, which involved adding an extra block in the message. The most important part of this extra block is a so-called transaction ID, which makes TCP traffic more secure from a communication perspective.
A few years ago, many thought Modbus would become obsolete as it is an old protocol. However, what has happened is that Modbus has experienced a renaissance and is now used in many different contexts. Modbus is one of the few protocols that is truly widespread on all continents.
The M-Bus ASCII protocol was developed by PiiGAB to facilitate reading M-Bus meters in a simple way, without needing a traditional M-Bus driver installed.
The protocol is a typical request/response protocol. Requests can be made via serial or UDP/TCP communication. The requests consist of so-called OPC Items sent as ASCII strings. These strings are then encoded according to the OPC standard, and the meter response is sent back as a string. These values can now easily be displayed on a screen 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 seamless information flow between devices from different manufacturers. The OPC Foundation is responsible for the development and maintenance of the standard. The OPC standard consists of several specifications developed through collaboration among many world-leading automation suppliers, end users, and software developers. The specifications define the interface between clients and servers as well as between servers, including access to real-time data, alarm and event display, 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 standardized interface. This made it possible for HMI/SCADA systems to communicate through a “middleware” that could convert general OPC read and write requests to protocol-specific equivalents and vice versa.
Initially, the OPC standard was limited to Windows operating systems. This meant the standard was based on OLE COM (Object Linking and Embedding Component Object Model) and DCOM (Distributed Component Object Model) technologies. These specifications are now called OPC Classic and have had a major impact in many industries, such as 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 security and data modeling. The OPC Foundation developed the OPC UA specifications to meet these needs while providing 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 organizations are moving to OPC UA for its flexible platform.
If you want to learn more about OPC, please visit www.opcfoundation.org. PiiGAB has extensive experience in communication and drivers for most common types of facilities. This includes everything from building automation to heavy industrial production. Water and sewage facilities with associated dial-up to pumping stations are also within our scope of operations.
We have worked with Citect since the late 1990s, with most of our work focused on our specialty area of communication and drivers. We have developed several Citect drivers from initial specifications to beta-tested and finished drivers. We have also adjusted and supplemented several drivers. In addition, we have been project managers for the development of about thirteen different Citect drivers. If you need a new Citect driver or other communication assistance, please contact us.