M-Bus – Informatie

Bron: iotsys * Github

M-Bus Protocol Overview

The M-Bus standard is defined in EN 13757-2 (physical and link layer) and EN 13757-3 (application layer). A detailed description is available at the official M-Bus homepage {1}.

The M-Bus was developed to fill the need for a system for the networking and remote reading of utility meters, for example to measure the consumption of gas or water in the home. This bus fulfills the special requirements of remotely powered or battery driven systems, including consumer utility meters. When interrogated, the meters deliver the data they have collected to a common master, which can, for example, be a hand-held computer, connected at periodic intervals to read all utility meters of a building. {1}

Physical Layer

The M-Bus is a hierarchical system, with communication controlled by a master. The M-Bus consists of the master, a number of slaves (end-equipment meters) and a two-wire connecting cable. The slaves are connected in parallel to the transmission medium.

In order to realize an extensive bus network with low cost for the transmission medium, a two-wire cable was used together with serial data transfer. In order to allow remote powering of the slaves, the bits on the bus are represented as follows:

The transfer of bits from master to slave is accomplished by means of voltage level shifts. A logical “1” (Mark) corresponds to a nominal voltage of +36V at the output of the bus driver (repeater), which is a part of the master; when a logical “0” (Space) is sent, the repeater reduces the bus voltage by 12V to a nominal +24V at its output. Bits sent in the direction from slave to master are coded by modulating the current consumption of the slave. A logical “1” is represented by a constant (versus voltage, temperature and time) current of up to 1.5mA, and a logical “0” (Space) by an increased current drain requirement by the slave of additional 11-20mA. The mark state current can be used to power the interface and possibly the meter or sensor itself.

Data Link Layer

The physical layer makes certain demands on the data link layer. Besides half-duplex asynchronous serial transmission with data rates between 300 and 9600 Baud, these include the requirement that at least every eleventh bit should be a logical 1, and also that there should be a Master-Slave structure, since the slaves can not communicate with each other. The protocol of the data link layer is based on the international standard IEC 870-5, which defines the transmission protocols for telecontrol equipment and systems. The M-Bus protocol described below derives from the above standard, but doesn´t use all the IEC functions.

Transmission Parameters

This protocol uses asynchronous serial bit transmission, in which the synchronization is implemented with start and stop bits for each character. There must be no pauses within a telegram, not even after a stop bit. Since quiescence on the line corresponds to a 1 (Mark), the start bit must be a Space, and the stop bit a Mark. In between the eight data bits and the even parity bit are transmitted, ensuring that at least every eleventh bit is a Mark. The bits of data are transmitted in ascending order, i.e. the bit with the lowest value (LSB = least significant bit) is the first one to be found on the line. The transmission takes place in half duplex and with a data rate of at least 300 Baud.

Telegram Format

In the M-Bus specification there are three different telegram formats, which can be recognized by means of special start characters. In the table below the telegram formats used for the M-Bus will now be explained.

Single Character: This format consists of a single character, which the E5h (decimal 229), and serves to acknowledge receipt of transmissions.

Short Frame: This frame with a fixed length begins with the start character 10h, and besides the C and A fields includes the check sum (this is made up from the two last mentioned characters), and the stop character 16h.

Long Frame: With the long frame, after the start character 68h, the length field (L field) is first transmitted twice, followed by the start character once again. After this, there follow the function field (C field), the address field (A field) and the control information field (CI field). The L field gives the quantity of the user data inputs plus 3 (for C,A,CI). After the user data inputs, the check sum is transmitted, which is built up over the same area as the length field, and in conclusion the stop character 16h is transmitted.

Control Frame: The control sentence conforms to the long sentence without user data, with an L field from the contents of 3. The check sum is calculated at this point from the fields C, A and CI.

Meaning of the Fields

C Field: The following table shows the function codes used in the calling and the replying directions:

A Field: The address (A) field is used to address a slave in calling direction and to identify the sender of information in receiving direction. The addresses 1 to 250 can be allocated to the individual slaves, up to a maximum of 250. The address 0 is reserved for unconfigured slaves and the addresses 254 and 255 are used for broadcasts.

CI Field: The control information (CI) field is already a part of the Application Layer, and is described in more detail in section Application Layer. It is used to distinguish between the formats of the long and the control frames. The control information allows the implementation of a variety of actions in the master or the slaves.

Check Sum: The Check Sum is used to recognize transmission and synchronization faults. The Check Sum is calculated from the arithmetical sum of the data mentioned above without taking carry digits into account.

Communication Process

The Data Link Layer uses the two kinds of transmission services Send/Confirm (SND/CON) and Request/Respond (REQ/RSP).

Send/Confirm Procedures:

SND_NKE → Single control character This procedure is used to start up after the interruption or beginning of communication. The slave responds to a correctly received SND_NKE with an acknowledgment using of a single character (E5h).

SND_UD → Single control character With this procedure the master sends user data to the slave. The slave can either confirm the correct receipt of data with a single character acknowledge (E5h), or by omitting a confirmation signal that it did not receive the telegram correctly.

Request/Respond Procedures:

REQ_UD2 → RSP_UD The master requests data from the slave according to Class 2. The slave can either transfer its data with RSP_UD, or give no response indicating that the REQ_UD2 telegram has not been received correctly or that the address contained in the REQ_UD2 telegram does not match.

Application Layer

The standardized application protocol is defined in the standard EN1434-3 for data exchange with heat meters. This standard is also suitable for other consumer utility meters, e.g. for gas and water. However, EN1434-3 only covers the data structure in the reply direction, the data structure generally used in the direction master to slave will be presented here.

The CI field encodes the mode of operation of the data transfer between the master and a slave. To send the requested data from a slave to the master there are two possible data structures, namely fixed data structure and variable data structure.

The configuration of slaves is also defined in this layer, but won’t be described here, because M-Bus meters are only read with IoTSyS.

Fixed Data Structure

In the reply direction with a long frame two different data structures are used. The fixed data structure, besides a fixed length, is limited to the transmission of only two counter states of a predetermined length, which have binary or BCD coding. In contrast the variable data structure allows the transmission of more counter states in various codes and further useful information about the data. The number of bytes of the transmitted counter states is also variable with this data structure. Contrary to the fixed structure, the variable structure can also be used in calling direction. For this reasons the fixed data structure is not recommended for future developments.

The frame of the fixed data structure is shown in the following table:

Variable Data Structure

The frame of the variable data structure is shown in the table below:

Fixed Data Header:

The first twelve bytes of the user data consist of a block with a fixed length and structure :

Variable Data Blocks:

Each data record contains one value with its description as shown in the table below, a data record, which consists of a data record header (DRH) and the actual data. The DRH in turn consists of the DIB (data information block) to describe the length, type and coding of the data, and the VIB (value information block) to give the value of the unit and the multiplier.

The DIB contains at least one byte (DIF, data information field), and can be extended by a maximum of ten DIFE’s (data information field extensions). After a DIF or DIFE without a set extension bit there follows the VIB (value information block). This consists at least of the VIF (value information field) and can be expanded with a maximum of 10 extensions (VIFE). The VIF and also the VIFE’s show with a set MSB that a VIFE will follow. In the value information field VIF the other seven bits give the unit and the multiplier of the transmitted value. The meaning of the multiplier can be look up in the M-Bus standard {1}.

Manufacturer Specific Data Block:

The manufacturer specific data block consists of the manufacturer data header (MDH) and manufacturer specific data. This can’t be encoded because it depends on the manufacturer how this part of frame structure looks like.

Example: Slave Read Out

Master sends a request (REQ_UD2) for reading data of slave with address 1:

10 7B 01 7C 16

Encoded request send from master to slave with address 1:

Received data from slave with address 1:

68 6A 6A 68 08 01 72 43 53 93 07 65 32 10 04 CA 00 00 00 0C 05 14 00 00 00 0C 13 13 20 00 00 0B 22 01 24 03 04 6D 12 0B D3 12 32 6C 00 00 0C 78 43 53 93 07 06 FD 0C F2 03 01 00 F6 01 0D FD 0B 05 31 32 4D 46 57 01 FD 0E 00 4C 05 14 00 00 00 4C 13 13 20 00 00 42 6C BF 1C 0F 37 FD 17 00 00 00 00 00 00 00 00 02 7A 25 00 02 78 25 00 3A 16

Encoded data from slave with address 1:

[#/handleidingen/mbus_info” ]