SIST EN 13757-3:2005
(Main)Communication systems for and remote reading of meters - Part 3: Dedicated application layer
Communication systems for and remote reading of meters - Part 3: Dedicated application layer
This document applies to communication systems for meters and remote reading of meters.
Kommunikationssysteme für Zähler und deren Fernablesung - Teil 3: Spezieller Application Layer
Erarbeitung einer Norm für den M-Bus Application Layer.
Systemes de communication et de télérelevé de compteurs - Partie 3: Couches d'application spéciale
Préparer une norme pour la couche d'application spéciale M-Bus.
Komunikacijski sistemi za merilnike in daljinsko odčitavanje - 3. del: Posebna aplikacijska plast
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
SIST EN 13757-3:2005
01-april-2005
.RPXQLNDFLMVNLVLVWHPL]DPHULOQLNHLQGDOMLQVNRRGþLWDYDQMHGHO 3RVHEQD
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
SIST EN 13757-3:2005 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST EN 13757-3:2005
---------------------- Page: 2 ----------------------
SIST EN 13757-3:2005
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.
---------------------- Page: 3 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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
2
---------------------- Page: 4 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
3
---------------------- Page: 5 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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)).
4
---------------------- Page: 6 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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
5
---------------------- Page: 7 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
6
---------------------- Page: 8 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
7
---------------------- Page: 9 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
8
---------------------- Page: 10 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
9
---------------------- Page: 11 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
10
---------------------- Page: 12 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
11
---------------------- Page: 13 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
12
---------------------- Page: 14 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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.
13
---------------------- Page: 15 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
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)
14
---------------------- Page: 16 ----------------------
SIST EN 13757-3:2005
EN 13757-3:2004 (E)
6.4 Data Field
The data field shows how the data from the master
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.