EN 13757-3:2004

SLOVENSKI STANDARD
01-april-2005
.RPXQLNDFLMVNLVLVWHPL]DPHULOQLNHLQGDOMLQVNRRGþLWDYDQMHGHO3RVHEQD
DSOLNDFLMVNDSODVW
Communication systems for and remote reading of meters - Part 3: Dedicated application
layer
Kommunikationssysteme für Zähler und deren Fernablesung - Teil 3: Spezieller
Application Layer
Systemes de communication et de télérelevé de compteurs - Partie 3: Couches
d'application spéciale
Ta slovenski standard je istoveten z: EN 13757-3:2004
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
35.100.70 Uporabniški sloj Application layer
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 13757-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2004
ICS 33.200; 35.100.70
English version
Communication systems for and remote reading of meters - Part
3: Dedicated application layer
Systèmes de communication et de télérelevé de compteurs Kommunikationssysteme für Zähler und deren
- Partie 3: Couches d'application spéciale Fernablesung - Teil 3: Spezieller Application Layer
This European Standard was approved by CEN on 23 September 2004.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the Central Secretariat or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the official
versions.
CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,
Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,
Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2004 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 13757-3:2004: E
worldwide for CEN national Members.

Contents
page
Foreword.3
Introduction .4
1 Scope .5
2 Normative references .5
3 Terms and definitions .5
4 General principles : Cl-field.6
5 Variable Data Respond (Cl = 72h, Cl = 78h, Cl = 7Ah).9
6 Variable Data Blocks (Records) .14
7 Value Information Block (VIB) .18
8 Application Layer Status and error reporting.25
9 Generalized Object Layer.28
10 Manufacturer Specific unstructured Data Block .28
11 Management of lower layers.29
Annex A (normative)  Coding of Data Records .33
Annex B (normative) Interpretation of Hex-Codes Ah - Fh in BCD-data fields .39
Annex C (normative)  Non metric units .40
Annex D (informative)  Alarm Protocol.41
Annex E (informative)  Examples.42
Annex F (informative)  Secondary Search .49
Annex G (informative)  International reference works.52
Annex H (informative)  Meaning of "device type specific" parameters of Mbus for Radio products.53
Bibliography .55

Foreword
This document (EN 13757-3:2004) has been prepared by Technical Committee CEN/TC 294 “Communication
systems for meters and remote reading of meters”, the secretariat of which is held by AFNOR.
This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by May 2005, and conflicting national standards shall be withdrawn at the
latest by May 2005.
This standard consists of the following parts:
EN 13757-1, Communication system for meters and remote reading of meters - Part 1: Data exchange.
EN 13757-2, Communication systems for and remote reading of meters - Part 2: Physical and link layer.
EN 13757-3, Communication systems for and remote reading of meters - Part 3: Dedicated application layer.
prEN 13757-4, Communication systems for meters and remote reading of meters - Part 4: Wireless meter
readout.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to implement this European Standard: Austria, Belgium, Cyprus, Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland
and United Kingdom.
Introduction
This document belongs to a series of parts of EN 13757 which covers communication systems for meters and
remote reading of meters. Part 1 contains generic descriptions and a communication protocol. Part 2 contains
a physical and a link layer for twisted pair base band (M-Bus). Part 4 (currently an enquiry is under
preparation) describes wireless communication.
The bus communication system of EN 1434–3 is commonly called M-Bus. Its application layer describes a
standard especially for meter readout.
It can be used with various physical layers and with link layers and network layers which support the
transmission of variable length binary transparent telegrams. Frequently the physical and link layers of
EN 13757-2 (Twisted pair baseband) and prEN 13757-4 (wireless) or the alternatives described
in EN 13757-1 are used.
An overview of communication systems for meters is given in EN 13757-1, which also contains further
definitions.
This standard is a compatible enhancement of the 6.4 to 6.6 of the original standard EN 1434–3:1997.
Besides some clarifications and implementation hints it contains optional enhancements especially for
complex meters. Due to technical progress some variants (Fixed format and mode 2=high byte first) are no
longer supported in this standard.
It should be noted that this standard contains only directions how data should be coded. It is beyond the task
of an application layer standard to define which data will be transmitted under what conditions by which types
of slaves or which data transmitted to a slave will have which reactions. Therefore adherence to this standard
guarantees the coexistence and common communication and readout capability of slaves via a universal
master software (covering all optional features), but not yet functional or communication interchangeabilty of
meters following this standard. For several meter types and meter classes a group of remote heating users
have provided such application descriptions required for full interchangeability. They are accessible via the
www-server of the m-bus users group http://www.m-bus.com/files/default.html (file name: WG4N99R4.EXE
(this is a self expanding .doc-file)).
1 Scope
This document applies to communication systems for meters and remote reading of meters.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
EN 13757-2:2004, Communication systems for and remote reading of meters - Part 2: Physical and link layer.
NOTE Further information and examples are available in the download area of http://www.m-bus.com.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 Table of abbreviations
DES Data Encryption Standard
DRH Data Record Header
DIB Data Information Block
DIF Data Information Field
DIFE Data Information Field Extensions
VIB Value Information Block
VIF Value Information Field
VIFE Value Information Field Extensions
RSP_UD Respond User Data
SND_UD Send User Data to slave
REQ-UD Request User Data
MDH Manufacturer Specific Data Block
CI Control Information Field
E Extension Bit
3.2
hexadecimal numbers
hexadecimal numbers are designated by a following "h"
Binary numbers
4 General principles : Cl-field
4.1 Overview
All application layer telegrams have variable length. The length information is part of the link layer. It shall be
known to the application layer in order to properly terminate its decoding of each telegram. Each telegram
starts with a one byte CI (control information) field, which distinguishes between various telegram types and
application functions. It is also used to distinguish between true application layer communication and
management commands for lower layers. The meaning of the remaining bytes of the telegram depends also
on the value of the CI-field.
Table 1 — CI-Field codes used by the master or the slave
Application
00h to 4Fh reserved for DLMS-based applications
50h application reset
51h data send (master to slave)
52h selection of slaves
53h reserved
54h to 58h reserved for DLMS-based applications
55h to 5Bh reserved
5Ch synchronize action
60h to 6Fh reserved
70h slave to master: report of application errors
71h slave to master: report of alarms
72h slave to master: 12 byte header followed by variable format data
73h to 77h reserved
78h slave to master: Variable data format response without header
79h reserved
7Ah slave to master: 4 byte header followed by Variable data format response
7Bh to 80h reserved
81h reserved for a future CEN–TC294– Radio relaying and application Layer
82h reserved for a future CENELEC–TC205 network/application Layer
82h to 8Fh reserved
90h to 97h manufacturer specific (obsolete)
A0h to AFh manufacturer specific
B0 to B7h manufacturer specific
B8h set baud rate to 300 baud
B9h set baud rate to 600 baud
BAh set baud rate to 1 200 baud
BBh set baud rate to 2 400 baud
BCh set baud rate to 4 800 baud
BDh set baud rate to 9 600 baud
BEh set baud rate to 19 200 baud
BFh set baud rate to 38 400 baud
C0h to FFh reserved
Note that the CI-codes 50h, 52h, 5Ch, 70h, 71h, 78h, 7Ah, 80h, 81h, A0h – AFh and B8h – BFh are optional
compatible enhancements of the EN 1434-3:1997 standard. Note also that even if the functions of these
optional CI-codes are not implemented in a slave the link layer protocol requires a proper link layer
acknowledge of SND_UD telegrams containing any of these CI-codes.
The EN 1434–3 defined two possible data sequences in multibyte records. This standard supports only the
mode where the least significant byte of a multibyte record is transmitted first.
4.2 Application reset (Cl = 50h), (optional)
4.2.1 General
With the CI-Code 50h 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.
4.2.2 Application reset subcode (optional)
It is allowed to use optional parameters after CI = 50h. If more bytes follow, the first byte is the application
reset subcode. Further bytes are ignored. 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 meaning of this number is device specific). The lower four bits may be ignored for slaves which provide
only a single telegram for each application. 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. The following
codes can be used for the upper 4 bits of the first parameter:
Table 2 — Coding of the upper four bits of the first parameter after CI = 50h
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 address, fixed dates
1001b Testing high resolution values
1010b Calibration
1011b Manufacturing
1100b Development
1101b Selftest
1110b Reserved
1111b Reserved
Note that this table has been expanded with optional elements from the original standard.
4.3 Master to slave data send (51h) (optional)
The CI-Field code 51h is used to indicate the data send from master to slave:
Variable Data Blocks (Records) MDH(opt)O Opt.Mfg.specific data Opt)
variable number 1 Byte variable number
Figure 1 — Variable Data Structure master to slave
Note that this structure is identical to the slave to master direction (see clause 5) with the exception of the
fixed header which is omitted in this direction.
4.4 Slave select (52h) (optional)
The CI-Field code 52h is used for the management of the optional secondary addressing (see 11.3).
4.5 Synchronize action (Cl = 5 Ch) (optional)
This CI-code can be used for synchronizing functions in slaves and masters (e.g. clock synchronization).
Special actions or parameter loads may be prepared but their final execution is delayed until the reception of
such a special CI-field command. No data follows this CI-code.
4.6 Report of application errors (slave to master) (Cl = 70h) (optional)
For details of the report of general application errors see 8.2. For error reporting of individual data elements
see 8.3.
4.7 Report of alarm status (slave to master) (Cl = 71h) (optional)
For details of the report of alarm status errors see annex D.
4.8 Variable data respond (slave to master) (Cl = 72h, 78h, 7Ah)
For details, see clause 5.
4.9 Baud rate switch commands B8h – BFh (otpional)
These optional commands can be used by a master to switch the baud rate of a slave. For details, see 11.2.
5 Variable Data Respond (Cl = 72h, Cl = 78h, Cl = 7Ah)
5.1 Introduction
Data Header of variable data respond The CI-Field codes 72h, 78h, 7Ah are used to indicate the variable data
structure in long frames (RSP_UD) with optional fixed header. Note that the CI-fields 78h and 7Ah are
extensions from the EN 1434–3. They are recommended for new master implementations to simplify the
integration of radio based communication.
Figure 2 shows the way this data is represented.
Data Header(Req.) Variable Data Blocks (Records) MDH(opt)O Opt.Mfg.specific data Opt)
0 byte (CI = 78h)
4 byte (CI = 7Ah) variable number 1 Byte variable number
12 byte (CI = 72h)
Figure 2 — Variable Data Structure in Answer Direction
5.2 Structure of Data Header (Cl = 72h)
The first twelve bytes of the user data consist of a block with a fixed length and structure (see Figure 3).
Ident. Nr. Manufr. Version Device type Access No. Status Signature
4 Byte 2 Byte 1 Byte 1 Byte 1 Byte 1 Byte 2 Byte
Figure 3 — Data Header CI = 72h
5.3 Structure of Data Header (Cl = 7Ah)
The first four bytes of the user data consist of a block with a fixed length and structure (see Figure 4).
This CI-field is proposed for systems using the future physical and link layer standard for radio communication.
In this standard the link layer address contains the information fields of the manufacturer, the device type, the
version and the identification number, so that these 8 bytes from the fixed header of the CI = 72h are not
required in the application layer part of a telegram.
Access No. Status Signature
1 Byte 1 Byte 2 Byte
Figure 4 — Data Header CI=7Ah
5.4 Identification Number
The Identification Number is either a fixed fabrication number or a number changeable by the customer,
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 = 0Ch, VIF = 78h, see 7.2) is provided.
5.5 Manufacturer identification
The field manufacturer is coded unsigned binary with 2 bytes. This manufacturer ID is calculated from the
ASCII code of EN 62056-21 manufacturer ID (three uppercase letters) with the following formula:
Man. ID = [ASCII(1st letter) – 64] • 32 • 32
+ [ASCII(2nd letter) – 64] • 32
+ [ASCII(3rd letter) – 64]
Note that the flag association, UK (www.dlms.com/flag) administers these three letter manufacturers ID of
EN 62056-21.
5.6 Version identification
The field version specifies the generation or version of the meter and depends on the manufacturer. It can be
used to make sure, that within each version number the identification # is unique.
5.7 Device type identification
The device byte is coded as follows:
Table 3 — Device type identification
Code bin. Code hex.
Device type (previously called medium)
Bit 7 … 0
Other 0000 0000 00
Oil 0000 0001 01
Electricity 0000 0010 02
Gas 0000 0011 03
Heat 0000 0100 04
Steam 0000 0101 05
Warm Water (30 °C … 90 °C) 0000 0110 06
Water 0000 0111 07
Heat Cost Allocator 0000 1000 08
Compressed Air 0000 1001 09
Cooling load meter (Volume measured at return temperature: 0000 1010 0A
outlet)
Cooling load meter (Volume measured at flow temperature: inlet) 0000 1011 0B
Heat (Volume measured at flow temperature: inlet) 0000 1100 0C
Heat / Cooling load meter 0000 1101 OD
Bus / System component 0000 1110 0E
Unknown Medium 0000 1111 0F
Reserved … 10 to 14
Hot water (≥ 90 °C) 0001 0101 15
Cold water 0001 0110 16
Dual register (hot/cold) Water meter (see NOTE ) 0001 0111 17
Pressure 0001 1000 18
A/D Converter 0001 1001 19
Reserved … 1Ah to 20h
Reserved for valve 0010 0001 21h
Reserved 22h to FFh
NOTE Such a meter registers water flow above a limit temperature in a separate register with an appropriate tariff ID.
Note that this table has been expanded with optional elements from EN 1434-3.
5.8 Access Number
The Access Number has unsigned binary coding, and is incremented (modulo 256) by one before or after
each RSP_UD from the slave. Since it can also be used to enable private end users to detect an unwanted
overfrequently readout of its consumption meters, it should not be resettable by any bus communication.
5.9 Status byte
Table 4 — Coding of the Status Field
Bit Meaning with Bit set Significance with Bit not set
0,1 See Table 5 See Table 5
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
Table 5 — Application Errors coded with the Status-Field
Status bit 1 bit 0 Application status
0 0 No Error
0 1 Application Busy
1 0 Any Application Error
1 1 Reserved
Note that more detailed error signalling can be provided by application telegrams starting with C I= 70h and/or
using data records signalling even more detailed error information.
5.10 Signature field
5.10.1 General
The Signature is reserved for optional encryption of the application data. Such an encryption might be
required for transmit only wireless meter readout. It is assumed, that each meter (or a group of meters) could
have an individual encryption key. If no Encryption is used its value shall be 00 00 h.
5.10.2 Functions
 Data privacy for consumption meters values;
 detecting simulated meter transmission;
 preventing later playback of old meter values.
5.10.3 Structure of encrypted telegrams
a) The data header (CI=72h see 5.2 or CI = 7Ah see 5.3) is always unencrypted. The last word of this block
is the signature word. If the following data are unencrypted, this signature word contains a zero.
b) If the transmission contains encrypted data, the high byte of this signature word contains a code for the
encryption method. The code 0 signals no encryption. Currently only the encryption codes 02xxh or 03xxh
(see below) are defined. The other codes are reserved. The number of encrypted bytes is contained in
the low byte of the signature word. The content of this signature word had been defined in the EN 1434–3
as zero, corresponding consistently to no encrypted data.
c) The encrypted data follow directly after the signature word, thus forming the beginning of the DIF/VIF-
structured part of the telegram.
5.10.4 Partial Encryption
a) If the number of encrypted bytes is less than the remaining data of the telegram, unencrypted data may
follow after the encrypted data. They shall start at a record boundary, i.e. the first byte after the encrypted
data will be interpreted as a DIF.
b) If a partially encrypted telegram shall contain encrypted manufacturer specific data a record with a
suitable length DIF (possibly a variable length string DIF) and a VIF = 7Fh (manufacturer specific data
record) shall be used instead of the usual MDH-DIF = 0Fh. This is required to enable after decryption
standard DIF/VIF-decoding of a previously partially encrypted telegram containing encrypted
manufacturer specific data.
5.10.5 Encryption methods
a) Encryption according to the DES (data encryption standard) as described in ANSI X3.92:1981;
b) Cipher Block Chaining (CBC)-method as described in ANSI X3.106:1983 with an initial initialization vector
of zero: (Encryption Method Code = 02xxh). In this case the data records should contain the current date
before the meter reading.
Note that in this case the data after the date record, i.e. especially the encrypted meter reading data
change once per day even if their data content itself is constant. This prevents an undetectable later
playback of stored encrypted meter readings by a hacker.
c) The "Initialization Vector IV" with length 64 bits of this standard may alternatively be defined by the first
6 bytes of the identification header in mode 1 sequence, i.e. identification number in the lowest 4 bytes
followed by the manufacturer ID in the two next higher bytes and finally by the current date coded as in
record structure "G" for the two highest bytes.
In this case the Encryption method is coded as "03xxh". Note that in this case all encrypted data change
once per day even if the data content itself is constant. This prevents an undetectable later playback of
any stored encrypted data by a hacker.
d) To simplify the verification of correct decoding and to prevent an undetected change in the identification
of the not encrypted header, the encrypted part of the telegram shall contain at least together with the
appropriate application layer coding (DIF and VIF) again the same identification number as in the
unencrypted header;
e) Due to the mathematical nature of the DES-algorithm the encrypted length contained in the low byte of
the signature word shall be an integer multiple of 8 if the high byte signals DES-Encryption. Unused bytes
in the last 8-byte block shall be filled with appropriatly structured dummy data records to achieve the
required record boundary at the end of the encrypted data. One or several bytes containing the filler
DIF = 2Fh are suggested to fill such gaps;
f) The application of certain Encryption methods might be prohibited by local laws.
5.11 Address structure if used together with the wireless link layer according to EN 13757-4
This link layer contains an 8 byte address header, which starts with a two byte manufacturer identification
according to EN 62056-21 followed by a 6 byte address. If this wireless link layer is used together with the
application layer of this standard and the CI-fields 78h or 7Ah this six byte address is structured similarily to
the fixed header of the CI-field 72h as follows:
Ident-Nr. (4 byte BCD) according to 5.3 followed by the one byte version identification according to 5.5 and
finally the one byte device type according to 5.6.
6 Variable Data Blocks (Records)
6.1 General
The data, together with information regarding coding, length and the type of data is transmitted in data records
in arbitrary sequence. As many records can be transferred as there is room for within the maximum total data
length of 234 Bytes, taking into account the C, A, and CI fields and the fixed data header. This limits the total
telegram length to 255 bytes. This restriction is required to enable gateways to other link- and application
layers. 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 are no
manufacturer specific data.
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
Figure 5 — Structure of a Data Record (transmitted from left to right)
Each data record contains one value (data) with its description (DRH). 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. Note that an application telegram can contain either just
a single data record but also an arbitray number of such data records in arbitrary order, each describing and
containing a data element. For examples of such multrecord telegrams see annex E or documents of
http://www.m-bus.com.
6.2 Data Information Block (DIB)
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).
6.3 Data Information Field (DIF)
The following information is contained in a DIF:
Bit 7 6 5 4 3 2 1 0
Extension LSB of
Data Field :
storage
Bit Function Field
number
Length and coding of data
(E)
Figure 6 — Coding of the Data Information Field (DIF)
6.4 Data Field
The data field shows how the data from the master shall be interpreted in respect of length and coding. The
following table contains the possible coding of the data field:
Table 6 — 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/Binary 1001 2 digit BCD
16 0010 16 Bit Integer/Binary 1010 4 digit BCD
24 0011 24 Bit Integer/Binary 1011 6 digit BCD
32 0100 32 Bit Integer/Binary 1100 8 digit BCD
32 / N 0101 32 Bit Real 1101 variable length
48 0110 48 Bit Integer/Binary 1110 12 digit BCD
64 0111 64 Bit Integer/Binary 1111 Special Functions
Note that this table has been expanded with optional elements from the original standard.
For a detailed description of data types refer to annex A ”Coding of data records” (e.g. 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 : 8-bit text string according to ISO 8859–1 with LVAR (0 to 191) characters. Note
that a text string (like all other mutibyte data) is transmitted “Least significant
byte first”
LVAR = C0h – C9h :
positive BCD number with (LVAR – C0h, i.e. 0 to 9) • 2 digits (0 to 18 digits)
LVAR = D0h – D9h :
negative BCD number with (LVAR – D0h) • 2 digits (0 to 18 digits)
LVAR = E0h – Efh : Binary number with (LVAR – E0h) bytes (0 to 15 bytes)
LVAR = F8h : floating point number according to IEEE 754
Others LVAR values : Reserved
Like all multibyte fields the last character is transmitted first.
Special Functions (data field = 1111b):
Table 7 — DIF-coding for special functions
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 of next record
3Fh … 6Fh Reserved
7Fh Global readout request (all storage#, units, tariffs, function fields)
Note that this table has been expanded with optional elements from the original standard.
If data follows after DIF = 0Fh or 1Fh these are manufacturer specific unstructured data. The number of bytes
in these manufacturer specific data can be calculated from the link layer information on the total length of the
application layer telegram. The DIF 1Fh signals a request from the slave to the master to readout the slave
once again. The master shall readout the slave until there is no DIF = 1Fh inside the respond telegram (multi
telegram readout) or use an application reset.
6.5 Function field
The function field gives the type of data as follows:
Table 8 — Function Field
Code Description Code Description
00b Instantaneous value 01b Maximum value
10b Minimum value 11b Value during error state
6.6 Storage number
The Bit 6 of the DIF serves as the LSB of the storage number of the data concerned, and the slave can in
this way indicate and transmit various stored metering values or historical values of metering data. This bit is
the least significant bit of the storage number and allows therefore the storage numbers 0 and 1 to be coded.
If storage numbers higher than “1” are needed, following (optional) DIFE´s contain the higher bits. The storage
number 0 signals an actual value. Note that a each storage number is associated with a given time point. So
all data records with the same storage number refer to the value of the associated variable at this (common)
time point for this storage number. It is recommended, that a time/date record for each storage number used
is included somewhere in the telegram to signal this time point associated with this storage number. This date
or date/time is coded with a data record with a VIF=E110110n. Normally (but not necessarily) higher storage
numbers indicate an older time point. A sequential block of storage numbers can be associated with a
sequence of equidistantly spaced time points (profile). Such a block can be described by its starting time, by
the time spacing, by the first storage number of such a block and by the length of such a block. The document
CBDIPW6.EXE of the download area of http://www.m-bus.com (only available in German) gives detailed
examples of configuring meters for profiles and tariffs.
6.7 Extension Bit (E)
The extension bit (MSB) signals that more detailed or extended descriptions (data field extension = DIFE)-
bytes follow. E = 1 if other VIFE or DIFE follow.
6.8 Data field extension byte(s) (DIFE)
Each DIFE (maximum ten) contains again an extension bit to show whether a further DIFE is being sent.
Besides giving the next most significant bits of the storage number, DIFE´s allow the transmission of
information about the tariff and the subunit of the device. In this way, exactly as with the storage number, the
next most significant bit or bits will be transmitted. The Figure 7 which follows shows the structure of a DIFE:
Bit 7 6 5 4 3 2 1 0
Value Extension (Device)
Bit Unit
Tariff Storage Number
(E)
Figure 7 — 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.
6.9 Tariff information
For each (unique) value type designation given by the following value information block (VIB) at each unique
time point (given by the storage number) of each unique function (given by the function field) there might exist
still various different data, measured or accumulated under different conditions. Such conditions could be time
of day, various value ranges of the variable (i.e. separate storage of positive accumulated values and negative
accumulated values) itself or of other signals or variables or various averaging durations. Such variables
which could not be distinguished otherwise are made different by assigning them different values of the tariff
variable in their data information block. Note that this includes but is not necessarily restricted to various tariffs
in a monetary sense. It is at the distinction of the manufacturer to describe for each tariff (except 0) what is
different for each tariff number. Again as with the storage numbers all variables with the same tariff
information share the same tariff associating condition.
6.10 Subunit information
A slave component may consist of several functionally and logically independent subunits of the same or of
different functionallity. Such a device may either use several different primary and/or secondary addresses.
Such it is from a link layer and an application layer view just several independent devices which share a
common physical layer interface. This is recommended for devices which represent a physical collection of
several truely independent (often similar or identical) devices. For devices which share common information
and values and have logical connections an approach with a common link layer (i.e.a single address) is
recommended. The various subunits can include their specific information into a common telegram and have
them differentiated by the individual subunit number in the subunit-datafield of their records.
7 Value Information Block (VIB)
7.1 General
After a DIF (with the exception of 0xFh) or a 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
Value Extension
Bit
Unit and multiplier (value)
(E)
Figure 8 — Coding of the Value Information Field (VIF)
There are five types of coding depending on the VIF:
a) Primary VIF: E000 0000b … E111 1011b
The unit and multiplier is taken from the table for primary VIF (7.2).
b) 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. Since only the “LSB first mode” (M = 1) of multibyte data transmission is
recommended, the rightmost character is transmitted first. This plain text VIF allows the user to code units
that are not included in the VIF tables.
c) Linear VIF-Extension: FDh and FBh
In case of VIF = FDh and VIF = FBh the true VIF is given by the next byte (i.e. the first VIFE) and the
coding is taken from the Tables 12 respectively Table 13 for secondary VIF (7.4 or 7.5). This extends the
available VIF´s by another 256 codes.
d) Any VIF: 7Eh / Feh
This VIF-Code can be used in direction master to slave for readout selection of all VIF´s. See special
function in 6.4.
e) Manufacturer specific: 7Fh / FFh
In this case the remainder of this data record including VIFE´s has manufacturer specific coding.
7.2 Primary VIF's (main table)
The first section of the main table contains integral values, the second typically averaged values, the third
typically instantaneous values and the fourth block contains parameters (E: extension bit).
Table 9 — Primary VIF-codes
Coding Description Range Coding Range
(nnn-3)
E000 0nnn Energy 0,001 Wh to 10 000 Wh
10 Wh
(nnn)
E000 1nnn Energy 0,001 kJ to 10 000 kJ
10 J
(nnn-6) 3
E001 0nnn Volume 0,001 l to 10 000 l
10 m
(nnn-3)
E001 1nnn Mass 0,001 kg to 10 000 kg
10 kg
E010 00nn On Time nn = 00b seconds
nn = 01b minutes Duration of meter power up
nn = 10b hours
nn = 11b  days
nn = 11   days
E010 01nn Operating Time coded like OnTime Duration of meter accumulation
(nnn-3)
E010 1nnn Power 0,001 W to 10 000 W
10 W
(nnn)
E011 0nnn Power 0,001 kJ/h to 10 000 kJ/h
10 J/h
(nnn-6) 3
E011 1nnn Volume Flow 0,001 l/h to 10 000 l/h
10 m /h
(nnn-7) 3
E100 0nnn Volume Flow ext. 0,000 1l/min to 1 000 l/min
10  m /min
(nnn-9) 3
E100 1nnn Volume Flow ext. 0,001 ml/s to 10 000ml/s
10 m /s
(nnn-3)
E101 0nnn Mass flow 0,001 kg/h to 10 000 kg/h
10 kg/h
(nn-3)
E101 10nn Flow Temperature 0,001 °C to 1 °C
10 °C
(nn-3)
E101 11nn Return Temperature 0,001 °C to 1 °C
10 °C
(nn-3)
E110 00nn Temperature Difference 1 mK to 1000 mK
10 K
(nn-3)
E110 01nn External Temperature 0,001 °C to 1 °C
10 °C
(nn-3)
E110 10nn Pressure 1 mbar to 1 000 mbar
10 bar
E110 1100 Date (actual or associated data field =0010b, type G
with a storage
number/function)
b
Date and time (actual or data field= 0100b, type F
E110 1101
associated with a storage
number/function)
b
Extendend time point Time to s data field= 0011b, type J
E110 1101
(actual or associated with a
storage number/function)
b
Extented Date and Time Time and date to sec. data field= 0110b, type I
E110 1101
Point (actual or associated
with a storage
number/function)
E110 1110 Units for H.C.A. Dimensionless
E110 1111 Reserved for a future third
table of VIF-extensions
E111 00nn Averaging Duration nn coded like OnTime
E111 01nn Actuality Duration nn coded like OnTime
E111 1000 Fabrication No see E.3
E111 1001 (Enhanced) Identification
E111 1010 Address For EN 13757-2: one byte link layer
address, data type C (x = 8)
For EN 13757-4: data field 110b
(6 byte Header-ID) or 111b (Full
8 byte Header)
Note b Meaning depends on data field.
Note that this table has been expanded with optional elements from the original standard.
7.3 VIF-Codes for special purposes
Table 10 — Special VIF-Codes. Note that this table has been expanded with optional elements from the
original standard
Coding Description Purpose
1111 1011 First Extension of VIF- true VIF is given in the first VIFE and is coded using
codes
(FBh) (Table 11 in 7.5) (128 new VIF-Codes)
a
E111 1100 VIF in following string
allows user definable VIF´s (in plain ASCII-String)
(length in first byte)
1111 1101 Second Extension of VIF- true VIF is given in the first VIFE and is coded using
codes
(FDh) (Table 11 in 7.4) (128 new VIF-Codes)
1110 1111 Reserved for third Reserved for a future table especially for electricity meters
Extension table of VIF-
(EFh)
codes
E111 1110 Any VIF Used for readout selection of all VIF´s
(see 6.4)
E111 1111 Manufacturer Specific VIFE´s and data of this block are manufacturer specific
a
Coding the VIF in an ASCII-String in combination with the data in an ASCII-String (datafield in DIF = 1101 b) allows the
representation of data in a free user defined form.
7.4 Main VIFE-Code Extension table (following VIF = FDh for primary VIF)
Table 11 — Main VIFE-code extension table
Coding Description Group
nn-3
E000 00nn
Credit of 10 of the nominal local legal currency
Currency Units
units
nn-3
E000 01nn
Debit of 10 of the nominal local legal currency units
E000 1000 Access Number (transmission count)
E000 1001 Device type
E000 1010 Manufacturer
E000 1011 Parameter set identification Enhanced Identification
E000 1100 Model / Version
E000 1101 Hardware version #
E000 1110 Metrology (firmware) version #
E000 1111 Other software version #
E001 0000 Customer location
E001 0001 Customer
E001 0010 Access Code User
"to be continued"
Table 11 (continued)
Coding Description Group
E001 0011 Access Code Operator Improved Selection
E001 0100 Access Code System Operator and other user requirements
E001 0101 Access Code Developer
E001 0110 Password
E001 0111 Error flags (binary) (Device type specific)
E001 1000 Error mask
E001 1001 Reserved
E001 1010 Digital Output (binary)
E001 1011 Digital Input (binary)
E001 1100 Baud rate [Baud]
E001 1101 Response delay time [bittimes]
E001 1110 Retry
E001 1111 Remote control (device specific)
E010 0000 First storage # for cyclic storage
E010 0001 Last storage # for cyclic storage
E010 0010 Size of storage block
E010 0011 Reserved Enhanced storage
a
E010 01nn management
Storage interval [sec(s) … day(s)]
E010 1000 Storage interval month(s)
E010 1001 Storage int
...