Communication protocols

Det elektriska gränssnittet M-Bus har utvecklats på Universitetet i Paderborn, Tyskland under ledning av Professor Dr Horst Ziegler. M-Bus eller Meter-Bus, som det egentligen heter, är en Europeisk standard för fjärravläsning av värmemängdsmätare eller andra typer av konsumtionsmätare. M-Bus kan också användas för att läsa av olika moduler som pulsomvandlare, analoga/digitala insignalsmoduler m.m.

M-Bus is a cost-effective fieldbus for transmitting consumption data from different types of meters. A central master for example a PC with a converter from Ethernet to M-Bus, 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 others types of meters.

More and more manufactures implement the electrical interface M-Bus in their meters. M-Bus is a European standard which is described in standard EN1434-3, EN13757-1,2,3,4,5

Modbus has its roots from the end of the 70s. During the development of the protocol the two developing companies did not agree, which led to a variant to Modbus called Jbus. The main difference is that the register address has a displacement of 1, which even today can be a source of confusion.

In the early days all the communication was by RS232 but in not too long RS485 was supported, which meant multi-drop, longer cables and higher speed. Later support was added for Modbus over TCP, which meant that an extra block was added in the message. The most important part in this is the so called transactionsid which makes the traffic over TCP more secure from a communication standpoint.

The prediction was that Modbus was going to die out a few years ago since it is an old protocol. However, it seems Modbus has had a renaissance and is being used in a variety of situations. Modbus is one of the few protocols that is big across all continents.

M-Bus ASCII is a protocol developed by PiiGAB to facilitate users to read M-Bus meters without having a traditional M-Bus driver installed.

The protocol is a typical question/answer protocol. The questions can be asked via serial or UDP/TCP communication. The questions consist of so called OPC Items that are being sent as ASCII strings. These strings are decoded according to OPC standards and then the meter reply is sent back as a string. These values can easily be presented on a display or a website.

OPC is the interoperability standard for the secure and reliable exchange of data in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.
The OPC standard is a series of specifications developed by industry vendors, end-users and software developers. These specifications define the interface between Clients and Servers, as well as Servers and Servers, including access to real-time data, monitoring of alarms and events, access to historical data and other applications.

When the standard was first released in 1996, its purpose was to abstract PLC specific protocols (such as Modbus, Profibus, etc.) into a standardized interface allowing HMI/SCADA systems to interface with a “middle-man” who would convert generic-OPC read/write requests into device-specific requests and vice-versa. As a result, an entire cottage industry of products emerged allowing end-users to implement systems using best-of-breed products all seamlessly interacting via OPC.

Initially, the OPC standard was restricted to the Windows operating system. As such, the acronym OPC was borne from OLE (object linking and embedding) for Process Control. These specifications, which are now known as OPC Classic, have enjoyed widespread adoption across multiple industries, including manufacturing, building automation, oil and gas, renewable energy and utilities, among others.

With the introduction of service-oriented architectures in manufacturing systems came new challenges in security and data modeling. The OPC Foundation developed the OPC UA specifications to address these needs and at the same time provided a feature-rich technology open-platform architecture that was future-proof, scalable and extensible.

These are just some of the reasons why so many members and other technology organizations (collaborations) are turning to OPC UA for their interoperability platform.

To learn more about the collaborations currently underway, contact the www.opcfoundation.org

PiiGAB has a very long and extensive experience in the field of communication and drivers for different types of buildings and constructions. This includes everything from building automation to heavy industries. We have worked with Citect for fifteen years where the majority of the time has been spent in our specializations: communication and drivers.

We have developed many Citect drivers from base specifications, to beta test, to finalized drivers, as well as adjusted and added to many existing drivers. In addition, we have been project managers for about thirteen different Citect drivers. If you are in need of a new Citect driver or need any kind of communication support please contact us.