The M-Bus: A Documentation


  Next Chapter   Table of Contents   M-Bus Home

6 Application Layer

The standardized application protocol in the standard EN1434-3 for data exchange with heat meters will be the basis for the following discussion. 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.

 

6.1 CI-Field

The CI-Field codes the type and sequence of application data to be transmitted in this frame.

The EN1434-3 defines two possible data sequences in multibyte records. The bit two (counting begins with bit 0, value 4), which is called M bit or Mode bit, in the CI field gives an information about the used byte sequence in multibyte data structures. If the Mode bit is not set (Mode 1), the least significant byte of a multibyte record is transmitted first, otherwise (Mode 2) the most significant byte. The Usergroup recommends to use only the Mode 1 in future applications.

 

Mode 1

Mode 2

Application

Definition in

51h

55h

data send

EN1434-3

52h

56h

selection of slaves

Usergroup July ´93

50h

 

application reset

Usergroup March ´94

54h

 

synronize action

suggestion

B8h

 

set baudrate to 300 baud

Usergroup July ´93

B9h

 

set baudrate to 600 baud

Usergroup July ´93

BAh

 

set baudrate to 1200 baud

Usergroup July ´93

BBh

 

set baudrate to 2400 baud

Usergroup July ´93

BCh

 

set baudrate to 4800 baud

Usergroup July ´93

BDh

 

set baudrate to 9600 baud

Usergroup July ´93

BEh

 

set baudrate to 19200 baud

suggestion

BFh

 

set baudrate to 38400 baud

suggestion

B1h

 

request readout of complete RAM content

Techem suggestion

B2h

 

send user data (not standardized RAM write)

Techem suggestion

B3h

 

initialize test calibration mode

Usergroup July ´93

B4h

 

EEPROM read

Techem suggestion

B6h

 

start software test

Techem suggestion

90h to 97h

 

codes used for hashing

obsolete and no longer recommended

Table 2 CI-Field codes used by the master

 

Application reset (CI = $50)

 

With the CI-Code $50 the master can release a reset of the application layer in the slaves. Each slave himself decides which parameters to change - e.g. which data output is default - after it has received such an application reset. This application reset by a SND_UD with CI=$50 is the counterpart to the reset of the data link layer by a SND_NKE.

 

Application reset subcode §

 

It is allowed to use optional parameters after CI = $50. The first parameter (the application reset subcode) defines which telegram function and which subtelegram is requested by the master. The datatype of this parameter is 8 bit binary. The upper 4 bits define the telegram type or telegram application and the lower 4 bits define the number of the subtelegram. The use of the value zero for the number of the subtelegram means that all telegrams are requested.

Slaves with only one type of telegram may ignore application reset and the added parameters but have to confirm it ($E5).

 

The following codes can be used for the upper 4 bits of the first parameter:

 

Coding

Description

Examples

0000b

All

 

0001b

User data

consumption

0010b

Simple billing

actual and fixed date values+dates

0011b

Enhanced billing

historic values

0100b

Multi tariff billing

 

0101b

Instaneous values

for regulation

0110b

Load management values for management

 

0111b

Reserved

 

1000b

Installation and startup

bus adress, fixed dates

1001b

Testing

high resolution values

1010b

Calibration

 

1011b

Manufacturing

 

1100b

Development

 

1101b

Selftest

 

1110b

Reserved

 

1111b

Reserved

 

Table 3 Coding of the upper four bits of the first parameter after CI = $50

 

 

 

Example:

The master releases an enhanced application reset to all slaves. All telegrams of the user data type are requested.

 

Master to Slave: 68 04 04 68 | 53 FE 50 | 10 | B1 16

Slave to Master: E5

 

Syncronize action (CI = $54) §

 

This CI-code can be used for syncronizing functions in slaves and masters (e.g. clock syncronization).

 

The use of the other control information codes is described in the chapters 6.4.1 (set baudrate to 300 .. 38400 Bd), 6.4.2 (data send) and 7 (selection of slaves).

 

The following codes can be used for the direction slave to master:

 

CI M=0

CI M=1

Application

Defined in

70h

 

report of general application errors

Usergroup March ´94

71h

 

report of alarm status

Usergroup March ´94

72h

76h

variable data respond

EN1434-3

73h

77h

fixed data respond

EN1434-3

Table 4 CI-Field codes used by the slave

The use of these control information codes is described in the chapters 6.1 (fixed data respond), 6.2 (variable data respond), 6.6 (report of general application errors) and 8.1 (report of alarm status).

 

6.2 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.

 

To identify the fixed data structure, the numbers 73h/77h for the control information field are used. In this way the master software can see how it must interpret the data.

 

Identification No.

Access No.

Status

Medium/Unit

Counter 1

Counter 2

4 Byte

1 Byte

1 Byte

2 Byte

4 Byte

4 Byte

Fig. 15 Fixed Data Structure in Reply Direction (transmit sequence from left to right)

The Identification Number is a serial number allocated during manufacture, coded with 8 BCD packed digits (4 Byte), and which thus runs from 00000000 to 99999999.

The Access Number has unsigned binary coding, and is increased by one after each RSP_UD from the slave. With the field Status various information about the status of counters, and faults which have occurred, can be communicated - see Figure 16:

 

 

Bit

Meaning with Bit set

Significance with Bit not set

0

Counter 1 and 2 coded signed binary

Counter 1 and 2 coded BCD

1

Counter 1 and 2 are stored at fixed date

Counter 1 and 2 are actual values

2

Power low

Not power low

3

Permanent error

No permanent error

4

Temporary error

No temporary error

5

Specific to manufacturer

Specific to manufacturer

6

Specific to manufacturer

Specific to manufacturer

7

Specific to manufacturer

Specific to manufacturer

Fig. 16 Coding of the Status Field

The field Medium/Unit is always transmitted with least significant byte first and gives the medium measured for both counter states, and the units for each of the two counter states. The units of counter 1 are coded with the first 6 bits of the first byte, and the units of counter 2 with the first 6 bits of the second byte. The coding of the medium is made up of the two highest bits of these bytes, and can therefore have 16 different values (4 bits). Tables to represent the physical units and the coding of the medium are in the appendix.

 

 

Byte

Byte No. 8 (byte 2 of medium/unit)

Byte No. 7 (byte 1 of medium/unit)

Bit

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

 

Medium

physical unit of counter 2

Medium

physical unit of counter 1

 

MSB

 

MSB

       

LSB

 

LSB

MSB

       

LSB

Fig. 17 Coding of physical unit and medium in fixed data structure (data type E)

To allow transmission of one historic value with one of the two counters the special unit (111110b or hex code share of 3Eh) has been defined. This unit declares that this historic counter has the same unit as the other actual counter.

 

Example for a RSP_UD with fixed data structure (mode 1):

The slave with address 5 and identification number 12345678 responds with the following data (all values hex.):

 

68 13 13 68 header of RSP_UD telegram (L-Field = 13h = 19d)

08 05 73 C field = 08h (RSP_UD), address 5, CI field = 73h (fixed, LSByte first)

78 56 34 12 identification number = 12345678

0A transmission counter = 0Ah = 10d

00 status 00h: counters coded BCD, actual values, no errors

E9 7E Type&Unit: medium water, unit1 = 1l, unit2 = 1l (same, but historic)

01 00 00 00 counter 1 = 1l (actual value)

35 01 00 00 counter 2 = 135 l (historic value)

3C 16 checksum and stop sign

 

 

6.3 Variable Data Structure

The CI-Field codes 72h/76h are used to indicate the variable data structure in long frames (RSP_UD). Figure 18 shows the way this data is represented:

 

 

Fixed Data Header

Variable Data Blocks (Records)

MDH

Mfg.specific data

12 Byte

variable number

1 Byte

variable number

Fig. 18 Variable Data Structure in Reply Direction

 

6.3.1 Fixed Data Header

The first twelve bytes of the user data consist of a block with a fixed length and structure (see fig. 19).

 

Ident. Nr.

Manufr.

Version

Medium

Access No.

Status

Signature

4 Byte

2 Byte

1 Byte

1 Byte

1 Byte

1 Byte

2 Byte

Fig. 19 Fixed Data Block

§ In contrast to the fixed data structure here the Identification Number is a customer number, coded with 8 BCD packed digits (4 Byte), and which thus runs from 00000000 to 99999999. It can be preset at fabrication time with a unique number, but could be changeable afterwards, especially if in addition an unique and not changeable fabrication number (DIF = $0C, VIF = $78, see chapter 6.7.3) is provided.

The access number is described above in the fixed data structure (see chapter 6.2).

The field manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the ASCII code of EN 61107 manufacturer ID (three uppercase letters) with the following formula:

 

IEC 870 Man. ID = [ASCII(1st letter) - 64] · 32 · 32

+ [ASCII(2nd letter) - 64] · 32

+ [ASCII(3rd letter) - 64]

 

The field version specifies the generation or version of this counter and depends on the manufacturer. In contrast to the fixed data structure, the Medium is coded with a whole byte instead of four bits and the lowest two bits of the Status field are used to indicate application errors (see chapter 6.6). Apart from this, the significance of the individual bits of the Status field is the same as that of the fixed data structure. The Signature remains reserved for future encryptation applications, and until then is allocated the value 00 00 h.

 

6.3.2 Variable Data Blocks

The data, together with information regarding coding, length and the type of data is transmitted in data records. As many blocks of data can be transferred as there is room for, within the maximum data length of 255 Bytes, and taking account of the C, A , and CI fields, the fixed data block. The upper limit for characters in the variable data blocks is thus 240 byte. The Usergroup recommends a maximum total telegram length of 255 bytes (234 bytes for variable data blocks) to avoid problems in modem communication. The manufacturer data header (MDH) is made up by the character 0Fh or 1Fh and indicates the beginning of the manufacturer specific part of the user data and should be omitted, if there is no manufacturer specific data.

Data Information Block

DIF

DIFE

VIF

VIFE

Data

1 Byte

0-10 (1 Byte each)

1 Byte

0-10 (1 Byte each)

0-N Byte

Data Information Block DIB

Value Information Block VIB

 

Data Record Header DRH

 

Fig. 20 Structure of a Data Record (transmitted from left to right)

Each data record contains one value with its description as shown in figure 20, 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). The following information is contained in a DIF:

Bit 7

6

5

4

3

2

1

0

Extension

Bit

LSB of storage number

 

Function Field

Data Field :

Length and coding of data

Fig. 21 Coding of the Data Information Field (DIF)

 

The function field gives the type of data as follows:

 

Code

Description

Code

Description

00b

Instantaneous value

01b

Maximum value

10b

Minimum value

11b

Value during error state

 

The data field shows how the data from the master must be interpreted in respect of length and coding. The following table contains the possible coding of the data field:

 

Length in Bit

Code

Meaning

Code

Meaning

0

0000

No data

1000

Selection for Readout

8

0001

8 Bit Integer

1001

2 digit BCD

16

0010

16 Bit Integer

1010

4 digit BCD

24

0011

24 Bit Integer

1011

6 digit BCD

32

0100

32 Bit Integer

1100

8 digit BCD

32 / N

0101

32 Bit Real

1101

variable length

48

0110

48 Bit Integer

1110

12 digit BCD

64

0111

64 Bit Integer

1111

Special Functions

Table 5 Coding of the data field

For a detailed description of data types refer to appendix 8.2 " Coding of data records"
(BCD = Type A, Integer = Type B, Real = Type H).

Variable Length:

With data field = `1101b` several data types with variable length can be used. The length of the data is given after the DRH with the first byte of real data, which is here called LVAR (e.g. LVAR = 02h: ASCII string with two characters follows) § .

LVAR = 00h .. BFh : ASCII string with LVAR characters

LVAR = C0h .. CFh : positive BCD number with (LVAR - C0h) · 2 digits

LVAR = D0h .. DFH : negative BCD number with (LVAR - D0h) · 2 digits

LVAR = E0h .. EFh : binary number with (LVAR - E0h) bytes

LVAR = F0h .. FAh : floating point number with (LVAR - F0h) bytes [to be defined]

LVAR = FBh .. FFh : Reserved

Like all multibyte fields in mode 1 the last character and in mode 2 the first character is transmitted first.

 

Special Functions (data field = 1111b):

 

DIF

Function

0Fh

Start of manufacturer specific data structures to end of user data

1Fh

Same meaning as DIF = 0Fh + More records follow in next telegram

2Fh

Idle Filler (not to be interpreted), following byte = DIF

3Fh..6Fh

Reserved

7Fh

Global readout request (all storage#, units, tariffs, function fields)

 

If data follows after DIF=$0F or $1F these are manufacturer specific data records. The number of bytes in these manufacturer specific data can be calculated with the L-Field. The DIF 1Fh signals a request from the slave to the master to readout the slave once again. The master must readout the slave until there is no DIF=1Fh inside the respond telegram (multi telegram readout).

 

 

The Bit 6 of the DIF serves to give the storage number of the data concerned, and the slave can in this way indicate and transmit various stored counter states or historical values, in the order in which they occur. This bit is the least significant bit of the storage number and allows therefore the storage numbers 0 and 1 to be given without further DIFE's. In this way the storage number 0 stands for the actual value. If higher storage numbers are needed, the slave allows a DIFE to follow the DIF, and indicates this by setting the extension bit.

 

Each DIFE (maximum ten) contains again an extension bit to show that a further DIFE is being sent. Besides giving the next most significant bit of the storage number, this DIFE allows the transmission of informations about the tariff and the subunit of the device from which the data come. In this way, exactly as with the storage number, the next most significant bit or bits will be transmitted. The figure 22 which follows shows the structure of a DIFE:

 

Bit 7

6

5

4

3

2

1

0

Extension Bit

(Device) Unit

Tariff

Storage Number

Fig. 22 Coding of the Data Information Field Extension (DIFE)

With the maximum of ten DIFE´s which are provided, there are 41 bits for the storage number, 20 bits for the tariff, and 10 bits for the subunit of the meter. There is no application conceivable in which this immense number of bits could all be used.

Value Information Block (VIB)

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.

 

Bit 7

6

5

4

3

2

1

0

Extension Bit

Unit and multiplier (value)

Fig. 23 Coding of the Value Information Field (VIF)

There are five types of coding depending on the VIF:

1. Primary VIF: E000 0000b .. E111 1011b

The unit and multiplier is taken from the table for primary VIF (chapter 8.4.3).

2. Plain-text VIF: E111 1100b

In case of VIF = 7Ch / FCh the true VIF is represented by the following ASCII string with the length given in the first byte. Please note that the byte order of the characters after the length byte depends on the used byte sequence. This plain text VIF allows the user to code units that are not included in the VIF tables.

3. Linear VIF-Extension: FDh and FBh

In case of VIF = FDh and VIF = FBh the true VIF is given by the next byte and the coding is taken from the table for secondary VIF (chapter 8.4.4). This extends the available VIF´s by another 256 codes.

4. Any VIF: 7Eh / FEh

This VIF-Code can be used in direction master to slave for readout selection of all VIF´s. See chapter 6.4.3.

5. Manufacturer specific: 7Fh / FFh

In this case the remainder of this data record including VIFE´s has manufacturer specific coding.

 

 

 

The VIFE can be used for actions which shall be done with the data (master to slave, chapter 6.5), for reports of application errors (slave to master, chapter 6.6) and for an enhancement of the VIF (orthogonal VIF, chapter 8.4.5). The last feature allows setting VIF´s into relation to the base physical units (e.g. VIF=10 liter, VIFE= per hour) or coding indirect units, pulse increments and change speeds.

In case of VIFE = FFh the next VIFE's and the data of this block are manufacturer specific, but the VIF is coded as normal.

After a VIF or VIFE with an extension bit of "0", the value information block is closed, and therefore also the data record header, and the actual data follow in the previously given length and coding.

 

6.3.3 Manufacturer Specific Data Block

 

The MDH consists of the character 0Fh or 1Fh (DIF = 0Fh or 1Fh) and indicates that all following data are manufacturer specific. When the number of bytes given in the length field of the connection protocol has not yet been used up, then manufacturer specific data follow this character, whose coding is left to the manufacturer. The length of this data is calculated from the L-Field minus the length of the so-called standard data (C-Field, A-Field, CI-Field and the data up to and including the data block 0Fh).

In case of MDH = 1Fh the slave signals to the master that it wants to be readout once again (multitelegram readouts). The master must readout the data until there is no MDH = 1Fh in the respond telegram.

 

Example for a RSP_UD with variable data structure answer (mode 1):

(all values are hex.)

68 1F 1F 68 header of RSP_UD telegram (length 1Fh=31d bytes)

08 02 72 C field = 08 (RSP), address 2, CI field 72H (var.,LSByte first)

78 56 34 12 identification number = 12345678

24 40 01 07 manufacturer ID = 4024h (PAD in EN 61107), generation 1, water

55 00 00 00 TC = 55h = 85d, Status = 00h, Signature = 0000h

03 13 15 31 00 Data block 1: unit 0, storage No 0, no tariff, instantaneous volume,

12565 l (24 bit integer)

DA 02 3B 13 01 Data block 2: unit 0, storage No 5, no tariff, maximum volume flow,

113 l/h (4 digit BCD)

8B 60 04 37 18 02 Data block 3: unit 1, storage No 0, tariff 2, instantaneous energy,

218,37 kWh (6 digit BCD)

18 16 checksum and stopsign

 

6.4 Configuring Slaves

The means for configuring slaves, for example set primary address or secondary address, set baudrate or set other configuration data inside the slave are explained in this section.

6.4.1 Switching Baudrate

All slaves must be able to communicate with the master using the minimum transmission speed of 300 baud. Splitted baudrates between transmit and receive are not allowed, but there can be devices with different baudrates on the bus.

In point to point connections the slave is set to another baudrate by a Control Frame (SND_UD with L-Field = 3) with address FEh and one of the following CI-Field codes:

 

 

CI-Field

B8h

B9h

BAh

BBh

BCh

BDh

BEh

BFh

Baud

300

600

1200

2400

4800

9600

19200

38400

Note

1

1

1

1,2

2

Fig. 24 CI-Field-Codes for Baudrate Switching

 

Notes:

1) These baudrates are not recommended.

2) These baudrates will be available in future with new repeater hardware. CI-Field codes are suggestions by the Usergroup.

 

The slave confirms the correctly received telegram by transmitting an E5h with the old baudrate and uses the new baudrate from now on, if he is capable of this.

The master must know the highest available baudrate on the bus to forbid the user switching to a transmission speed, which is not available on the bus. Otherwise the slave would never answer again.

 

Example:

The master switches the slave (in point to point connection) from now 2400 baud to 9600 baud.

Master to slave: 68 03 03 68 | 53 FE BD | 0E 16 with 2400 baud

Slave to master: E5 with 2400 baud

From that time on the slave communicates with the transmission speed 9600 baud.

 

6.4.2 Writing Data to a Slave

The master can send data to a slave using a SND_UD with CI-Field 51h for mode 1 or 55h for mode 2. Note that the data structure in such a write telegram has been changed in contrast to previous definitions by means of leaving out the fixed data header of 12 byte. The following figure shows the data structure for a write telegram. The order of the first three blocks in the following figure can be turned round, but the write only data record must be at the end of the telegram. All records are optional.

 

Primary Address Record

Enhanced Identifica-

tion Record

Normal

Data Records

Write Only Data Records

Fig. 25 Data Structure for Writing Data

· Primary Address Record:

The primary address record is optional and consists of three bytes:

DIF = 01h

VIF = 7Ah

Data = Address (1 byte binary)

With this data record a primary address can be assigned to a slave in point to point connections. The master must know all the used addresses on the bus and forbid setting the address of a slave to an already used address. Otherwise both slaves with the same address couldn´t be read out anymore.

 

· Enhanced Identification Record:

With this optional data record the identification (secondary address) can be changed. There are two cases to be distinguished:

1) Data is only the identification number

DIF = 0Ch

VIF = 79h

Data = Identification No. (8 digit BCD)

2) Data is the complete identification

DIF = 07h

VIF = 79h

Data = complete ID (64 bit integer)

The data is packed exactly as in the readout header of a $72/$76 variable protocol with low byte first for mode 1 and high byte first for mode 2:

 

Identification No.

Manufacturer ID

Generation

Medium

 

4 byte

2 byte

1 byte

1 byte

 

· Normal Data Records:

The data records, which can be read out with a REQ_UD2, are sent back to the slave with the received DIF and VIF and the new data contents. Additional features can be implemented using the generalized object layer (see chapter 6.5 § ).

· Write-Only Data:

Data, which cannot be read out of the slave with a normal data block, can be transmitted using the VIF = 7Fh for manufacturer specific coding. The DIF must have a value corresponding to the type and length of data.

 

After receiving the SND_UD correctly without any error in data link layer the slave must answer with an acknowledgement (E5h). The slave decides whether to change variables or not after a data write from the master. In case of errors in executing parts of or whole write instructions the slave can decide whether to change no variables or single correct variables. The slave can report the this errors to the master in the next RSP_UD telegram using some of the methods which are described in chapter 6.6.

There are some methods for implementing write protect, for example allowing only one write after a hardware reset of the processor or enabling write if a protect disable jumper is set.

 

Examples:

1. Set the slave to primary address 8 without changing anything else:

68 06 06 68 | 53 FE 51 | 01 7A 08 | 25 16

 

2. Set the complete identification of the slave (ID=01020304, Man=4024h (PAD), Gen=1, Med=4 (Heat):

68 0D 0D 68 | 53 FE 51 | 07 79 04 03 02 01 24 40 01 04 | 95 16 §

 

3. Set identification number of the slave to "12345678" and the 8 digit BCD-Counter (unit 1 kWh) to 107 kWh.

68 0F 0F 68 | 53 FE 51| 0C 79 78 56 34 12 | 0C 06 07 01 00 00 | 55 16

 

 

 

6.4.3 Configuring Data Output

For default the slave transmits all his data with a RSP_UD. It could be useful for some applications to read only selected data records out of one or more devices. There are two ways to select data records:

 

Selection without specified data field

The selection of the wanted data records can be performed with a SND_UD (CI-Field = 51h/55h) and data records containing the data field 1000b, which means "selection for readout request". The following VIF defines the selected data as listed in EN1434-3 and no data are transmitted. The answer data field is determined by the slave. The master can select several variables by sending more data blocks with this data field in the same telegram.

 

Special multiple values can be selected with the following methods:

· Any VIF:

The VIF-Code $7E (any VIF) is especially for readout request of "all VIF" from the slave and can be interpreted as a selection wildcard for the value information field.

· Global readout request:

The DIF-Code $7F is defined as "selection of all data for readout request", i.e. all storage numbers, units, tariffs and functions. If this DIF is the last byte of user data or the VIF=$7E follows, then all data is requested. So the selection of all data of one slave can de done with a SND_UD and the character $7F as the user data. If there follows a DIF unequal to $7E, then all subfields of this VIF are selected for readout.

· All Tariffs:

The highest tariff number in the selection record is defined as selection of "all tariffs". For example the tariff 1111b (15) means selection of all tariffs in a record with two DIFE´s.

· All Storage Numbers:

A selection of all storage numbers can be done with the maximum storage number if there is a minimum of one DIFE. For example the highest storage number is $1F (31) with one DIFE and $1FF (511) with two DIFE´s.

· All Units:

"All units" can be selected by using a data record header with minimum two DIFE´s and the highest unit number.

 

· High Resolution Readout:

The master can select the slave to answer with the maximum resolution to a given value / unit by a VIF with "nnn" = 000 (minimum exponent for range coding). The meter may then answer with a resolution of e.g. 1mWh (VIF=0000000b) or some higher decimal value if required. The unit values have been chosen so that their minimum provides sufficient resolution even for calibration. A readout request for a VIF with "nnn"=max (maximum exponent for range coding) signals a request for the standard resolution of the meter.

 

After the next REQ_UD2 the slave answers with the selected data in his own format, if the requested data are available. Otherwise the slave transmits his normal data and the master has to find out that the data are not the requested one. If there are more than one variables with the selected VIF, the device should send all these data records.

 

Selection with specified data field

The master is able to perform a readout request with a specified data field by using the object action "add to readout list" (VIFE = E000 1100b) from VIFE-table for object actions (see chapter 6.5). The master transmits a SND_UD (CI-Field = 51h/55h) with a data record which consists of the desired DIF (data field), VIF and the VIFE = 0Ch / 8Ch. No data follows this VIFE and the slave should ignore the data field on reception. The slave should transmit this data record with the requested data field from now on, if he is capable of this. If the slave doesn´t support this data field (data coding), it can report a record error using one of the VIFE = E000 011x (data class not implemented or data size not implemented).

 

Deselection of data records

The master can release a reset of the application layer and especially a fallback to the slaves standard RSP_UD-Telegram by transmitting a SND_UD with the CI-Field $50.

Single data records can be deselected by transmitting a data record with DIF, VIF and the VIFE for the object action "Delete from Readout-List" (VIFE = E000 1101b).

 

 

 

 

If the selected data is supported by the slave but too long for one RSP_UD telegram (especially for readout of all historic values), the slave transmits an additional data record consisting only of the DIF=$1F, which means that more data records follow in the next respond telegram. In this case the master must readout the slave again until the respond telegram is only an $E5 (no data) or there is no DIF=$1F in the RSP_UD.

To avoid lost of data respond telegrams the slave should in this case support the Frame Count Bit (FCB). If the master wants to premature end such a multitelegram sequential readout of the selected data, it may send an application reset with CI=$50 instead of further REQ_UD2´s.

 

 

 

Examples:

 

1. A slave with address 7 is to be configured to respond with the data records containing volume (VIF=13h: volume, unit 1l) and flow temperature (VIF=5Ah: flow temp.,

unit 0.1 °C).

68 07 07 68 | 53 07 51 | 08 13 08 5A | 28 16

 

2. A slave with address 1 is to be configured to respond with all storage numbers, all tariffs,

and all VIF´s from unit 0.

68 06 06 68 | 53 01 51 | C8 3F 7E | 2A 16

 

3. A slave with address 3 is to be configured to respond with all data for a complete readout of all available. After that the master can poll the slave to get the data.

68 04 04 68 | 53 03 51 | 7F | 26 16

 

6.5 Generalized Object Layer

The fundamental idea of an object is the encapsulation of data and methods or actions for the data. In case of writing data to a slave the master software can pack data and information about the action, which the slave shall do with this data, in one data record. This variable data record with actions is now called an object. If the VIF has not got the value $FD (extended VIF-Code table) the following VIFE-Codes define the action:

 

Action: (E: extension bit)

 

VIFE-Code binary

Action

Explanation

E000 0000

Write (Replace)

replace old with new data

E000 0001

Add Value

add data to old data

E000 0010

Subtract Value

subtract data from old data

E000 0011

OR (Set Bits)

data OR old data

E000 0100

AND

data AND old data

E000 0101

XOR (Toggle Bits)

data XOR old data

E000 0110

AND NOT (Clear Bits)

NOT data AND old data

E000 0111

Clear

set data to zero

E000 1000

Add Entry

create a new data record

E000 1001

Delete Entry

delete an existing data record

E000 1010

Reserved

 

E000 1011

Freeze Data

freeze data to storage no.

E000 1100

Add to Readout-List

add data record to RSP_UD

E000 1101

Delete from Readout-List

delete data record from RSP_UD

E000 111x

Reserved

 

E001 xxxx

Reserved

 

Fig. 26 Action Codes for the Generalized Object layer (Master to Slave)

 

With these actions the master can alter the data of the slaves or configure the output data of the slaves (actions 12 and 13). The actions 0 to 6 alter the data of the slave by replacing the old data (action 0, equals to data write without VIFE) or do arithmetical or logical operations with the old and the transmitted data.

Note that this method of configuring the readout list (action 12 and 13) allows not only the adding but also the removal of elements in contrast to the method of using the DIF=1000b-type of readout request (described in chapter 6.4.3).

All these actions can be used for normal slaves and for intelligent master which are manipulated by a higher order master.

The functions "Add entry" and "Delete entry" are useful to tell an intelligent master to add e.g. a new data record like maximum or minimum values of any slave.

 

With the action "freeze data to storage #" the master can tell the slave to freeze the actual value corresponding to the transmitted VIF, unit, tariff and function to a certain storage number given in the DIF/DIFE´s. In this case the data field inside the VIF has got the value 0000b (no data). This action allows freeze of selected values or multiple freeze with VIF=$7E (all VIF). The date / time should also be freezed to the same storage number.

 

Examples:

1) Set the 8 digit BCD-Counter (instantaneous, actual value, no tariff, unit 0) with VIF=06 (1kWh) of the slave with address 1 to 107 kWh.

68 0A 0A 68 | 53 01 51 | 0C 86 00 07 01 00 00 | 3F 16

 

2) Same as in example 1) but add 10 kWh to the old data.

68 0A 0A 68 | 53 01 51 | 0C 86 01 10 00 00 00 | 48 16

 

3) Add an entry with an 8 digit BCD-Counter (instantaneous, actual value, no tariff,

unit 0, 1kWh) with the start value of 511 kWh to the data records of the slave with address 5.

68 0A 0A 68 | 53 05 51 | 0C 86 08 11 05 00 00 | 59 16

 

4) Freeze actual flow temperature (0.1 °C: VIF = 5Ah) of the slave with address 1

into the storage number 1.

68 06 06 68 | 53 01 51 | 40 DA 0B | CA 16

 

 

6.6 Application Layer Status

There can be so far only data link layer errors reported from slave to master by means of leaving out the acknowledgement or negative acknowledgement. It is not allowed to report errors in the application layer, which can occur for example in data writing, using any of the above methods, because these are reserved for link layer errors. The slave can transmit an $E5 after a REQ_UD2 to indicate that it has received the telegram, but can´t respond with data. There are three different techniques for reporting application errors:

1. Status Field

One possible solution is to use the reserved 2 lowest bits of the Status field in the variable data structure for the application layer status:

 

Status bit 1 bit 0

Application status

0 0

No Error

0 1

Application Busy

1 0

Any Application Error

1 1

Reserved

Fig. 27 Application Errors coded with the Status-Field

2. General Application Errors

For reporting general application errors a slave can use a RSP_UD telegram with CI=$70 and zero or one byte data, which then describes the type of error:

 

68h

04h

04h

68h

08h

PAdr

70h

DATA

CS

16h

Fig. 28 Telegram for reporting general application errors

The following values for DATA are defined:

 

0

Unspecified error: also if data field is missing

1

Unimplemented CI-Field

2

Buffer too long, truncated

3

Too many records

4

Premature end of record

5

More than 10 DIFE´s

6

More than 10 VIFE´s

7

Reserved

8

Application too busy for handling readout request

9

Too many readouts (for slaves with limited readouts per time)

10..255

Reserved

Table 6 Codes for general application errors

3. Record Errors

To report errors belonging to a special record the slave can use this data record header with a VIFE containing one of the following values to code the type of application error, which has been occured.

 

VIFE-Code

Type of Record Error

Error Group

E000 0000

None

 

E000 0001

Too many DIFE´s

 

E000 0010

Storage number not implemented

 

E000 0011

Unit number not implemented

 

E000 0100

Tariff number not implemented

DIF Errors

E000 0101

Function not implemented

 

E000 0110

Data class not implemented

 

E000 0111

Data size not implemented

 

E000 1000 to

E000 1010

Reserved

 

E000 1011

Too many VIFE´s

 

E000 1100

Illegal VIF-Group

 

E000 1101

Illegal VIF-Exponent

VIF Errors

E000 1110

VIF/DIF mismatch

 

E000 1111

Unimplemented action

 

E001 0000 to

E001 0100

Reserved

 

E001 0101

No data available (undefined value)

 

E001 0110

Data overflow

 

E001 0111

Data underflow

 

E001 1000

Data error

Data Errors

E001 1001 to

E001 1011

Reserved

 

E001 1100

Premature end of record

 

E001 1101

to

E001 1111

Reserved

Other Errors

Table 7 Codes for record errors (E = extension bit)

In case of record errors the data maybe invalid. The slave has some options to transmit the data:

˙ datafield = 0000b: no data

˙ datafield = 0000b: no data and idle filler (DIF=$2F): fill telegram up to the normal length

˙ other datafield: dummy data of correct length

˙ other datafield: unsafe or estimated data

 

 

6.7 Special Slave Features

Some optional or recommended features of the slaves, which are not mentioned in EN1434-3, will be described in this section.

6.7.1 Auto Speed Detect

§ This feature is implemented in several slaves. It is no longer recommended by the M-Bus Usergroup because it is difficult to guarantee a hamming distance of four with this method.

 

The fact that several baudrates are allowed on the bus causes the problem for the master to know the used baudrates of all connected slaves. The software must perform the search for primary and secondary addresses with all allowed baudrates. For this reasons it is useful, if the slaves would answer with just the baudrate, which the master uses for this telegram. In addition the risk to loose contact with a slave would be dismissed and commands for baudrate switching would no longer be required.

 

The slave detects the baudrate by scanning the start sign of the telegram, which has the value 10h for a short frame or the value 68h for a long frame.

 

Startsign 10h on the bus:

Start

LSB

Bit 1

Bit 2

Bit 3

Bit 4

Bit 5

Bit 6

MSB

Parity

Stop

0

0

0

0

0

1

0

0

0

1

1

 

Startsign 68h on the bus:

Start

LSB

Bit 1

Bit 2

Bit 3

Bit 4

Bit 5

Bit 6

MSB

Parity

Stop

0

0

0

0

1

0

1

1

0

1

1

 

The startsign 10h begins with five space bits and the startsign 68h with four space bits on the line. After detecting the beginning of a new telegram the device measures the duration of space. By comparing the space duration with a stored table of ranges for five and four bits of all implemented transmission speeds the slave makes a decision about the baudrate and the number of space bits (four or five). Then it receives the remaining bits of the startsign (seven or six) with the detected transmission speed. This procedure has to set for example a flag or a variable to tell the normal receive procedure the used baudrate.

Auto speed detect of 300, 2400 and 9600 baud has been implemented with an eigth bit microcontroller and works fine. This feature can be easily programmed in microcontrollers using software polling for communication, but is more difficult with UART-based communication.

 

6.7.2 Slave Collision Detect

Collisions between transmitting slaves can occur during slave search activities by the master. Very light collisions of (22..33) mA, which are equivalent to 2 or 3 transmitting slaves, are electrically undetectable by master and slave. New master hardware with double current detect can detect light collisons of (20..200) mA and then transmit a break (50 ms space) on the bus. The slave can detect medium collisions of (70..500) mA, if this is a collision between a mark and a space and if the slave supports this feature. Heavy collisions of (90..5000mA) will have the effect of a break down of the bus voltage (power fail in the slave) and possibly a shortcircuit in the master.

To avoid these consequences of (heavy) collisions new master have the feature of double current detect with break signaling and switching off the bus in overcurrent states. There are some means for the slaves to detect collisions and then stop transmitting:

 

1. Software based UART´s can test at the end of each Mark-Send-Bit whether the input is really a mark. This guarantees a very fast detection of collisions, is simple to implement and is strongly recommended for pure software UART.

2. A variation of the preceeding method is to test whether the bus voltage is mark after each stop-bit. This is simple for a software UART, but very tricky for a hardware UART and requires a master sending a break on collision detect.

3. A simple method for unbuffered hardware UART, but tricky for buffered hardware UART, is to compare the transmitted with the received byte.

4. Another method, which requires a master with break collision detect, is a hardware UART with break detect.

5. The baudrate of the communication process after a detected break will be 300 Baud § .

 

6.7.3 Use of the fabrication Number

(§ new chapter)

The fabrication number is a serial number allocated during manufacture. It is part of the variable data block (DIF = $0C and VIF = $78) and coded with 8 BCD packed digits (4 Byte).

 

Example:

 

68 15 15 68 header of RSP_UD telegram (length 1Fh=31d bytes)

08 02 72 C field = 08 (RSP), address 2, CI field 72H (var.,LSByte first)

78 56 34 12 identification number = 12345678

24 40 01 07 manufacturer ID = 4024h (PAD in EN 61107), generation 1, water

13 00 00 00 TC = 13h = 19d, Status = 00h, Signature = 0000h

0C 78 04 03 02 01 fabrication number = 01020304

9D 16 checksum and stopsign

 

The use of this number is recommended if the identification number is changeable. In this case two or more slaves can get the same secondary adress and can not be uniquely selected. The fabrication number together with manufacturer, version and medium field build an unique number instaed. Suitable masters use this number for an enhanced selection method if two or more slaves have the same secondary adress (see chapter 7.4).

6.7.4 Hex-Codes $A-$F in BCD-data fields

(§ new chapter)

General description

1.) Standard Reference

EN1434 allows multi-digit BCD-coded datafields. The current standard does not contain information about what happens if a non-BCD hex code ($A-$F) is detected by the master software.

2.) Purpose of this proposal

a) Define the treatment of non BCD-digits in slave to master RSP_UD-telegrams

To fully define a master software including error treatment such a definition would be desirable.

 

 

b) Utilize these codes for simplified error treatment by slave

The current user group proposal contains various techniques for signalling errors or abnormal situations. Most of them are hard to implement on weak mikro-processors. Utilizing these "illegal" codes $A to $F for signalling these states to the master would simplify the software design of the slaves.

c) Anormal states of variables

This happens for example, if a fixed date value is not yet available, because the first fixed date is in the future. The display at the meter or the remote PC should read "----".

This could happen for a temperature variable, if the sensor is malfunctioning. The display at the meter or a remote PC should signal some error code. Multiple error codes should be supported.

Exceeding the upper count limit on integral values or the upper value limit on momentary values should be signallable. For a wrap around carry of integral variables the display should be consistent with old mechanical wrap around counters. In addition a wrap around flag should be extractable.

Underflowing the lower count limit of 00 on integral values or a negative value on momentary values should be signallable. For a wrap around carry of integral variables the display should be consistent with old mechanical wrap around counters. In addition a wrap around flag should be extractable.

To simplify the design of slaves with integrated displays, the above mentioned non-BCD states of the variables should be both transmittable in the form of suitable (Hex) codes but also be displayable directly from the value codes of a 7-segment (usually LCD) display by extending the normal ten entry BCD to 7-segment decoding table to either a dual 16-entry or a single 32-entry decoding table where 16 entries are used for decoding the MSD (Most Significant Digit) and the other 16 entries are used for the decoding for all other for all other digits. For very weak mikroprocessors with a maximum of a single decoding table with only 16-entries a compatible solution with decreased functionality is also presented.

 

New proposal

1.) Definition of hex code meanings

a) $A

Such a code in the MSD (Most significant digit) position signals a one digit value overflow either of a number or due to an addition or increment carry. The display at the meter or a remote PC should display a "0" at the appropriate display position. This makes the display compatible with conventional counter rollover. In addition the leading digit can be treated by the slave software simply as a hexadecimal digit instead of the BCD-coded other digits to realize this function. Processing software in the master could convert this data digit to a value of 10 in an extended length data field. In addition an appropriate application error code could be generated if desired. If this hex code appears in any other digit position than the MSD, it signals a value error of the complete data field. If an alternative display decoding table for the digits other than the MSD is possible, this hex code should be displayed in these other digit positions as the symbol "A". This would allow more flexible displayable error codes.

Example: A 4-digit BCD code of "A321" should be interpreted by the master software as "10321" with an optional overrange VIFE-error code and displayed as 0321 on a 4-digit only display.

 

b) $B

Such a code in the MSD digit position signals a two digit value overflow either of a number or due to an addtion or increment carry. The display at the meter or a remote PC should display a "1" at the appropriate display position. This makes the display compatible with conventional counter rollover. In addition the leading digit can be treated by the slave software simply as a hexadecimal digit instead of the BCD-coded other digits to realize this function. Processing software could convert this data digit to a value of 11 in an extended length data field. In addition an appropriate application error code could be generated if desired. If this hex code appears in any other digit position than the MSD, it signals a value or availability error of the complete data field. It should be displayed as the symbol "-".

Example: A 4-digit BCD code of "B321" should be interpreted by the master software as "11321" with an optional overrange VIFE-error code and displayed as 1321 on a 4-digit only display with digit selective decoding.

 

c) $C

Such a code in the MSD digit position signals a three digit value overflow either of a number or due to an addition or increment carry. The display at the meter or a remote PC should display a "2" at the appropriate display position. This makes the display compatible with conventional counter rollover. In addition the leading digit can be treated by the slave software simply as a hexadecimal digit instead of the BCD-coded other digits to realize this function. Processing software could convert this data digit to a value of 12 in an extended length data field. In addition an appropriate application error code could be generated if desired. If this hex code appears in any other digit position than the MSD, it signals a value error of the complete data field. It should be displayed as the symbol "C". Note that the suggested interpretation of $A to $C in the MSD effectivly supports a 30% overrange guard band against an undetected rollover and flexible error codes including the letters "A", "C", "E" and "F".

Example: A 4-digit BCD code of "C321" should be interpreted by the master software as "12321" with an optional overrange VIFE-error code and displayed as 2321 on a 4-digit only display.

 

d) $D

Such a code in any digit position signals a general error of the complete data field. The display at the meter or a remote PC should display a blank at the appropriate display position. Since both an overflow from $C and an underflow from $E end in this out of range type error the function of an out-of-range over/underflow can be implemented by simple hex arithmetic. It is however recommended that the slave arithmetic checks this $D-code in the MSD before incrementing or decrementing the value for integral variables to make such an error irreversible if the slave does not expect such an over- or underflow.

 

e) $E

Such a code in the MSD digit position signals a two digit value underflow either of a number or due to a subtraction or decrement borrow. The display at the meter or a remote PC should display an "8" at the appropriate display position. This makes the display compatible with conventional counter rollunder. In addition the leading digit can be treated by the slave software simply as a hexadecimal digit instead of the BCD-coded other digits to realize this function. Processing software could convert the data in the field to a negative value using 16´s complement on the leading digit and tens complement at the other digits. In addition an appropriate application error code could be generated if desired. If this hex code appears in any other digit position than the MSD, it signals a value error of the complete data field. It should be displayed as the symbol "E".

Example: A 4-digit BCD code of "E321" should be interpreted by the master software as "- 1679" (F999-E321+1) with an optional underrange VIFE-error code and displayed as 8321 on a 4-digit only display.

f) $F

Such a code in the MSD digit position signals an one digit value underflow either of a number or due to a subtraction or decrement borrow. The display at the meter or a remote PC should display an "9" at the appropriate display position. This makes the display compatible with conventional counter rollunder. In addition the leading digit can be treated by the slave software simply as a hexadecimal digit instead of the BCD-coded other digits to realize this function. Processing software could convert the data in the field to a negative value using 16´s complement on the leading digit and tens complement at the other digits. In addition an appropriate application error code could be generated if desired. If an alternative display decoding table for the digits other than the MSD is possible, this hex code should be displayed in these other digit positions as the symbol "F". Note that the suggested interpretation of $E and $F in the MSD effectivly supports a 20% underrange guard band against an undetected rollunder for displays and flexible error displays if dual decoding tables are available. In addition it allows a simplified coding for small negative values as often required for values like temperature or flow rate.

Example: A 4-digit BCD code of "F321" should be interpreted by the master software as "- 0679" (F999-F321+1) with an optional underrange VIFE-error code and displayed as 9321 on a 4-digit only display.

 

g) Combinations

If with the exception of the MSD all other digits are true BCD-digits ($0-$9) the value is either considered as "Overflow" for the MSD hex codes $A to $C or as "Underflow" for the MSD hex codes $E and $F or a general error for the MSD hex code $D.

The code $DB..BB in the data field is always considered as "not available". This is displayed as " ----" (with a blank in the MSD). Any other non BCD-hex codes in one or several digits other than the MSD is interpreted as an error for the complete data field. The error type is formed from the characters "A", "C", "E", "F" (all corresponding to their hex code), "-", blank and the digits 0-9. The display may show an identical error code if displaying the variable, but the MSD digit on the display can contain only blank or the digits 0..9.

 

h) Decoding table for 2*16 entries (or 32 entries)

 

0

1

2

3

4

5

6

7

8

9

$A

$B

$C

$D

$E

$F

MSD

"0"

"1"

"2"

"3"

"4"

"5"

"6"

"7"

"8"

"9"

"0"

"1"

"2"

" "

"8"

"9"

other digits

"0"

"1"

"2"

"3"

"4"

"5"

"6"

"7"

"8"

"9"

"A"

"-"

"C"

" "

"E"

"F"

 

 

i) Subset functions

A slave may utilize either non, a single, several or all suggested special functions and their associated hex codes. A slave might utilize also a different number of hex code functions for different data fields. A slave could also use different display implementations for the various special functions and error displays but the suggested solution would simplify the operation of the system, since the master display will be identical to the slave display for the value associated with the appropriate data field.

 

2.) Subset for single 16-entry display decoding

a) Decoding table

0

1

2

3

4

5

6

7

8

9

$A

$B

$C

$D

$E

$F

"0"

"1"

"2"

"3"

"4"

"5"

"6"

"7"

"8"

"9"

"0"

"-"

"C"

" "

"E"

"9"

 

b) Overrange

The overrange feature should be limited to a 10% overrange ($A in MSD). A further increment should lead directly to the MSD-error hex code $D, which should stop further increment and decrement and generate a suitable error code in the other digits

 

c) Underrange

The underrange feature should be limited to a 10% underrange ($F in MSD). A further decrement should lead directly to the MSD-error hex code $D, which should stop further increment and decrement and generate a suitable error code in the other digits.

 

d) Error codes

Error codes may contain only the letters "C" and "E", blank, "-" and the digits 0-9.

 

e) Compatiblity

At the master side this subset realisation is completely compatible and transparent to the full implementation.

 


  Next Chapter   Table of Contents   M-Bus Home