Prof.Dr.H.Ziegler CEN/TC176-WG4-N107 Rev.4

The original EN1434-3 defined two possible data sequences in multibyte records. The bit two (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 Mode 2 (M=1) is obsolete and should not be used. It is documented here only as a reference for universal master software with support of old meters.

Mode 1	(Mode 2)	Application
00h-4Fh		reserved for DLMS
50h		application reset
51h	(55h)	data send (master to slave)
52h	(56h)	selection of slaves
53h		reserved
54h-58h		reserved for DLMS
59h-5Bh		reserved
5Ch		synchronize action
60h-6Fh		reserved
70h-7Fh	(74h)	reserved for answer directionslave to master: report of application errors
71h		slave to master: report of alarms
72h	(76h)	slave to master: Variable format data respond
73h	(77h)	slave to master: Fixed format data respond
7880h-8Fh		reserved
90h-97h		manufacturer specific (obsolete)
A0h-AFh		manufacturer specific
B0-B7h		manufacturer specific (obsolete)
B8h		set baudrate to 300 baud
B9h		set baudrate to 600 baud
BAh		set baudrate to 1200 baud
BBh		set baudrate to 2400 baud
BCh		set baudrate to 4800 baud
BDh		set baudrate to 9600 baud
BEh		set baudrate to 19200 baud
BFh		set baudrate to 38400 baud
C0h-FFh		reserved

Table 1 CI-Field codes used by the master

"Reserved for DLMS" refers to the DLMS PDU´s in A-XDR encoding of the FDIS version of the IEC-DLMS standard. Choosing CI-fields different from these code simplifies the construction of slaves which can have dual application layers for both standards and which then can automatically distinguish between communication according to both standards.

Note that the CI-codes $50, $52/$56, $5C, $70/$74, $71, $A0-$AF and $B8-$BF are optional compatible enhancements of the original 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.

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.

It is allowed to use optional parameters after CI = $50. 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 lower four bits may me 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 but have to confirm it ($E5).

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 = $50

Note that this table has been expanded with optional elements from the original standard.

The CI-Field codes 51h(55h) are used to indicate the data send from master to slave:

Fig. 1 Variable Data Structure master to slave

Note that this structure is identical to the slave to master direction (see chapter 4) with the exception of the fixed header which is omitted in this direction.

The CI-Field codes 52h(56h) are used for the management of an optional netwerk layer using secondary adressing (See chapter 9).

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.

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

Table 3 CI-Field codes used by the slave

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

For details of the report of application errors see chapter 6.

For details of the report of alarm status errors see appendix C.

In the reply direction (slave to master) with a long frame originally two different data structures were 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 theseis reasons the fixed data structure is not recommended for future developments. For information on this obsolete fixed data structure see appendix D. For new development therefore only the CI-field $72 shall be used. This is a restriction from the original standard.

To identify the fixed data structure, the numbers 73h/77h for the control information field are used. In this way a universal master software can see how it must interpret the data. For further details on the structure of telegrams starting with CI-values of $72/($76) see chapter 3.

These optional commands can be used by a master to switch the baudrate of a slave.
For details see chapter 9.1.

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

Fig. 12 Variable Data Structure in Answer Direction

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

Fig. 23 Fixed Data HeaderBlock

The Identification Number is either a fixed fabrication number or a customer number changable 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 = $0C, VIF = $78, see chapter 6.7.3) is provided.

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:

Note that currently the flag association administers these three letter manufacturers ID of EN61107. For details see appendix X.

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.

The medium device byte is coded as follows:

Note that this table has been expanded with optional elements from the original standard.

The Access Number has unsigned binary coding, and is increased (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.

Table 5 Fig. 4 Application Errors coded with the Status-Field

Note that more detailed error signalling can be provided by application telegrams starting with CI=$70 and/or using data records signalling even more detailed error information.

The Signature is reserved for optional encryptation of the application data. If no encryptation is used its value shall be 00 00 h.

3.8.1 Functions

Data privacy for consumption meters values

Detecting simulated meter transmission

Preventing later playback of old meter values

3.8.2 Structure of encrypted telegrams

a) The first 12-byte block containing the ID-number,

the manufacturer etc. 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 encryptation method. The code 0 signals no

encryptation. Currently only the encryptation codes 2 or 3

(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 is currently defined

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.

3.8.3 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 must 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 must contain encrypted

manufacturer specific data a record with a suitable length

DIF (possibly a variable length string DIF) and a VIF=

$7F (manufacturer specific data record) must be used

instead of the usual MDH-DIF=$0F. This is required to

enable after decryptation standard DIF/VIF-decoding of a previously partially encrypted telegram containing

encrypted manufacturer specific data .

3.8.4 Encryptation methods

a) Encryptation according to the DES (data encryptation

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: (Encryptation Method Code=2). 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 the first 6

bytes of the identification header in mode 1 sequence,

i.e. identification number in 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 encryptation method is coded as "3".

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

e) Due to the mathematical nature of the DES-algorithm

the encrypted length contained in the low byte of the

signature word must be an integer multiple of 8 if

the high byte signals DES-encryptation.

Unused bytes in the last 8-byte block must 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=$2F are suggested to fill such gaps.

f) The application of certain encryptation methods might be

prohibited by local laws.

The Signature remains reserved for future encryptation applications, and until then is allocated the value 00 00 h.

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 234255 Bytes, and taking account of the C, A, and CI fields, and the data header. This limits the total telegram length to 255 bytes. This restriction is required to enable gateways to other link- and application layers. e upper limit for characters in the variable data blocks is thus 240 byte. A maximum total telegram length of 255 bytes (234 bytes for variable data blocks) is recommended to simplify gateways and the integration in other link 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.

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

Each data record contains one value (data) with its description (DRH)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:

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

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:

Table 46 Coding of the data field

Note that this table has been expanded with optional elements from the original standard.

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

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

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

Table 7: DIF-coding for special functions

Note that this table has been expanded with optional elements from the original standard.

If data follows after DIF=$0F or $1F 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 must readout the slave until there is no DIF=1Fh inside the respond telegram (multi telegram readout) or use an application reset.

The function field gives the type of data as follows:

Table 8: Function Field

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 timepoint. So all data records with the same storage number refer to the value of the associated variable at this (common) timepoint for this storage number. It is recommended, that a time/date record with this storage number is included somewhere to signal this timepoint. Normally (but not necessarily) higher storage numbers indicate an older timepoint. 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 coding for such a block description in contrast to an individual time/date record for each individula storage number is given in the appendix.

The extension bit (MSB) signals that more detailed or extended descriptions (data field extension=DIFE)-bytes follow.

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 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 8 which follows shows the structure of a DIFE:

Fig. 58 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.

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

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 adresses. 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 idential) 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 reccomended. 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.

After a DIF (with the the exception of $xF) 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.

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

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

Note that this table has been expanded with optional elements from the original standard.

Table 10: Special VIF-Codes

Note that this table has been expanded with optional elements from the original standard.

Note that this optional table has been added to the original standard.

Πnn = 00 second(s)

01 minute(s)

10 hour(s)

11 day(s)

 The information about usage of data type F (date and time) or data type G (date) can be derived from the datafield (0010b: type G / 0100: type F).

Ž pp = 00 hour(s)

01 day(s)

10 month(s)

11 year(s)

Note that this optional table has been added to the original standard.

Note that this optional table has been added to the original standard.

Π"Date(/time) of" or "Duration of" relates to the information which the whole data record header contains.

 The information about usage of data type F (date and time) or data type G (date) can be derived from the datafield (0010b: type G / 0100: type F).

The data link layer reports only communication errors by means of omittingleaving out the acknowledgement $E5 or a via a negative acknowledgement. It is not allowed to report errors of the application layer (which can occur for example in data writing) via the link layer. The slave can transmit an $E5 after a SND_UD to indicate that it has received the telegram, but can´t respond with data. There are three different techniques for reporting application errors:

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. Following any VIF including a VIF=$FD or VIF=$FB with the true value information in the first VIFE another (usually the last) VIFE can be added which contains a code signalling object actions according to the following table.

Action: (E: extension bit)