Excerpt BB4 PDF

EXCERPT FROM Companion Specification for Energy Metering
COSEM Identification System and Interface Objects
DLMS User Association

device language message specification
Reference number:
EXCERPT FROM DLMS UA 1000-1:2001, Fourth Edition

Copyright 1997-2001 DLMS User Association
DLMS UA, EXCERPT FROM COSEM Identification System and Interface Objects, Fourth Edition
EXCERPT
DLMS UA 1000-1 ed.4
2/43
Table of Contents
1. 2. 3. 3.1 3.2 Foreword.............................................................................................................................. 5 Scope ................................................................................................................................... 6 Introduction ......................................................................................................................... 7 Referenced Documents....................................................................................................... 7 Terms, Definitions and Abbreviations .................................................................................. 8
4. COSEM Interface Classes ................................................................................................... 9 4.1 Basic Principles................................................................................................................... 9 4.1.1 Introduction ....................................................................................................................... 9 4.1.2 Class Description Notation.............................................................................................. 10 4.1.3 Common Data Types ...................................................................................................... 11 4.1.4 Data formats for date and time notation.......................................................................... 12 4.1.5 The COSEM server model .............................................................................................. 14 4.1.6 COSEM Logical Device................................................................................................... 15 4.1.7 Authentication Procedures .............................................................................................. 16 4.2 The interface classes ........................................................................................................ 17 4.2.1 Data (class_id: 1) ............................................................................................................ 18 4.2.2 Register (class_id: 3) ...................................................................................................... 18 4.2.3 Extended Register (class_id: 4) ...................................................................................... 20 4.2.4 Demand Register (class_id: 5)........................................................................................ 20 4.2.5 Register Activation (class_id: 6) ...................................................................................... 21 4.2.6 Profile Generic (class_id: 7) ............................................................................................ 21 4.2.7 Clock (class_id: 8)........................................................................................................... 21 4.2.8 Script Table (class_id: 9) ................................................................................................ 24 4.2.9 Schedule (class_id: 10)................................................................................................... 24 4.2.10 Special Days Table (class_id: 11) ................................................................................... 24 4.2.11 Activity Calendar (class_id: 20) ....................................................................................... 24 4.2.12 Association LN (class_id: 15) .......................................................................................... 25 4.2.13 Association SN (class_id: 12) ......................................................................................... 25 4.2.14 SAP Assignment (class_id: 17) ....................................................................................... 25 4.2.15 Register Monitor (class_id: 21) ....................................................................................... 25 4.2.16 Utility Tables (class_id: 26) ............................................................................................. 26 4.2.17 Single Action Schedule (class_id: 22) ............................................................................. 26 4.3 Maintenance of the Interface Classes ............................................................................... 26 4.4 Protocol related Interface Classes..................................................................................... 26 4.5 Using Short Names for accessing attributes and methods ............................................... 26 4.5.1 Guidelines for Assigning Short Names............................................................................ 27 4.5.2 Reserved base_names for Special COSEM Objects ...................................................... 27 4.6 Relation to OBIS ............................................................................................................... 27 4.6.1 Mapping of Data Items to COSEM Objects and Attributes .............................................. 28 4.6.2 Coding of OBIS Identifications ........................................................................................ 28 4.7 Previous Versions of Interface Classes ............................................................................. 28 5. 5.1 5.2 5.3 COSEM Object Identification System (OBIS) .................................................................. 29 Introduction ....................................................................................................................... 29 Scope................................................................................................................................ 29 OBIS Object identification system structure ...................................................................... 29
EXCERPT
DLMS UA 1000-1 ed.4
3/43
5.3.1 Value group A ................................................................................................................. 30 5.3.2 Value group B ................................................................................................................. 30 5.3.3 Value group C ................................................................................................................. 30 5.3.4 Value group D ................................................................................................................. 30 5.3.5 Value group E ................................................................................................................. 30 5.3.6 Value group F ................................................................................................................. 30 5.3.7 Manufacturer specific codes ........................................................................................... 30 5.4 Value group definitions...................................................................................................... 31 5.4.1 Value group A ................................................................................................................. 31 5.4.2 Value group B ................................................................................................................. 31 5.4.3 Value group C ................................................................................................................. 31 5.4.4 Value group D ................................................................................................................. 33 5.4.5 Value group E ................................................................................................................. 36 5.4.6 Value group F ................................................................................................................. 38 5.4.7 Abstract objects .............................................................................................................. 38 5.4.8 Electricity-related General purpose objects..................................................................... 39 5.4.9 List objects...................................................................................................................... 41 5.4.10 Electricity data profile objects.......................................................................................... 41 5.5 Code presentation ............................................................................................................. 41 5.5.1 Reduced ID codes (e.g. for IEC 62056-21) ..................................................................... 42 5.5.2 Display ............................................................................................................................ 42 5.5.3 Special handling of value group F ................................................................................... 42 5.5.4 COSEM........................................................................................................................... 43
EXCERPT
DLMS UA 1000-1 ed.4
4/43
1. Foreword
Copyright Copyright 1997-2001 DLMS User Association. This document is confidential. It may not be copied, nor handed over to persons outside the standardisation environment. The copyright is enforced by national and international law. The "Berne Convention for the Protection of Literary and Artistic Works", which is signed by 121 countries world-wide, and other treaties apply.
Acknowledgement The actual document has been established by a team of experts working for the meter manufacturers DZG, Enermet, Schlumberger and Siemens, with input from other members of the DLMS User Association and from working group members of standardisation bodies, e.g. IEC TC13 WG14 and CEN TC294 WG2.
Status of standardisation The actual edition 4 of this document combines the contents of draft IEC 62056-62 (Interface Objects) and draft IEC 62056-61 (OBIS Object Identification System) submitted to IEC for FDIS circulation.
EXCERPT
DLMS UA 1000-1 ed.4
5/43
2. Scope
This document specifies the functionality of the meter which is available at its interface (internal issues concerning the implementation are not covered by the specification) and how the functions and the data can be accessed from the outside. The complex functionality of the meter is divided into generic building blocks. The COSEM specifications follow a three step approach as illustrated in Figure 1: Step 1:The meter model and data identification (data model); Step 2:The mapping of the model into protocol data units (pdu); Step 3:The transportation of the bits and bytes through the communication channel. The data model uses generic building blocks to define the complex functionality of the metering equipment. It provides a view of this functionality of the meter, as it is available at its interface(s). The model does not cover internal, implementation specific issues. The communication protocol defines how the data can be accessed and exchanged.
1. Modelling
COSEM Interface Objects

n t io a ci oVersion=0 0..n Class_id=3, s Data Type Min s Max Def octet-string rA instance specific e scal_unit_type Us m/o S Mo DL
Register Attribute(s) 1. logical_name 2. value 3. scaler-unit Method(s) 1. reset

(static) (dyn.) (static)
Protocol Services to access attributes and methods 2. Messaging

Communication Protocol
Messages : Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id ) Encoding: ( APDU ) C0 01 00 03 01 01 01 08 00 FF 02

.. C, IE .
3. Transporting
O, IS
Figure 1 The three steps approach of COSEM: Modelling - Messaging - Transporting The COSEM specification specifies metering domain specific interface classes. The functionality of the meter is defined by the instances of these interface classes, called COSEM objects. This is defined in the first part of this document. Logical names (OBIS codes), identifying the COSEM objects are defined in the second part of this document. The attributes and methods of these COSEM objects can be accessed and used via the messaging services of the Application layer. The lower layers of the protocol transport the information.
EXCERPT
DLMS UA 1000-1 ed.4
6/43
3. Introduction
Driven by the need of the utilities to optimise their business processes, the meter becomes more and more part of an integrated metering and billing system. Whereas in the past the commercial value of a meter was mainly generated by its data acquisition and processing capabilities, nowadays the critical issues are system integration and interoperability. The Companion Specification for Energy Metering (COSEM) addresses these challenges by looking at the meter as an integrated part of a commercial process which starts with the measurement of the delivered product (energy) and ends with the revenue collection. The meter is specified by its behaviour as seen from the utility's business processes. The formal specification of the behaviour is based on object modelling techniques (interface classes and objects). The specification of these objects forms a major part of COSEM. The COSEM server model (comp. chapter 4.1.5) represents only the externally visible elements of the meter. The client applications that support the business processes of the utilities, of the customers and of the meter manufacturers make use of this server model. The meter offers means to retrieve its structural model (the list of objects visible through the interface), and provides access to the attributes and specific methods of these objects. The set of different interface classes (see chapter 4) form a standardised library from which the manufacturer can assemble (model) its individual products. The elements are designed such that with them the entire range of products (from residential to commercial and industrial applications ) can be covered. The choice of the subset of interface classes used to build a meter, their instantiation and their implementation are part of the product design and therefore left to the manufacturer. The concept of the standardised metering interface class library provides the different users and manufacturers with a maximum of diversity without having to sacrifice interoperability. The competitive energy markets require an ever-increasing amount of timely information concerning the usage of electrical energy. Recent technology developments enable to build intelligent static metering equipment, which are capable to capture, process and communicate this information to all parties involved. For further analysis of this information, for the purposes of billing, load-, customer- and contract management, it is necessary to uniquely identify all data in a manufacturer independent way collected manually or automatically, via local or remote data exchange. The OBIS definition of Identification codes (see chapter 5) was based on:
draft DIN 43863-3 (December 1997), Electricity meters - Part 3: Tariff metering device as additional equipment for electricity meters - EDIS - Energy Data Identification System
3.1 Referenced Documents

Ref. Title DLMS UA 1000-2 COSEM Three Layer Connection Oriented Architecture, Second Edition (2001) IEC 61268:1995 Alternating current static var-hour meters for reactive energy (classes 2 and 3) IEC 61334-4-41:1996 Distribution automation using distribution line carrier systems - Part 4: Data communication protocols - Section 41: Application protocols - Distribution line message specification
EXCERPT
DLMS UA 1000-1 ed.4
7/43
Ref. IEC 62056-21 IEC 62056-31:1999 IEC 62056-46 IEC 62056-53 IEC 62056-61 IEC 62056-62 ANSI C12.19:1997
Title Data exchange for meter reading, tariff and load control Part 21: Direct local data exchange Electricity metering Data exchange for meter reading, tariff and load control Part 31- Using local area networks on twisted pair with carrier signalling Electricity metering Data exchange for meter reading, tariff and load control Part 46 Data link layer using HDLC-protocol Electricity metering Data exchange for meter reading, tariff and load control Part 53- COSEM Application layer Electricity metering Data exchange for meter reading, tariff and load control Part 61- OBIS Object Identification System Data exchange for meter reading, tariff and load control Part 62: Interface Classes IEEE 1377:1998, Utility industry end device data tables
3.2 Terms, Definitions and Abbreviations

Abbreviation AARE AARQ ACSE APDU ASE A-XDR base_name Class_id COSEM COSEM object DLMS GMT HLS IC IEC LLS LSB m MSB o OBIS PDU UTC Explanation Application Association Response Application Association Request Application Control Service Element Application protocol data unit Application Service Element Adapted Extended Data Representation The short_name corresponding to the first attribute (logical_name)of a COSEM object.. Class identification code Companion Specification for Energy Metering An instance of an interface class Distribution Line Message Specification Greenwich Mean Time High Level Security Interface Class International Electrotechnical Commission Low Level Security Least significant bit mandatory, used in conjunction with attribute and method definitions Most significant bit optional, used in conjunction with attribute and method definitions Object Identification System Protocol data unit Universal Time Co-ordinated
EXCERPT
DLMS UA 1000-1 ed.4
8/43
4. COSEM Interface Classes
4.1 Basic Principles

4.1.1 Introduction
This section describes the basic principles on which the COSEM interface classes are built. It also gives a short overview on how interface objects (instantiations of the interface classes) are used for communication purposes. Meters, support tools and other system components that follow these specifications can communicate with each other in an interoperable way. Object modelling: for specification purposes this document uses the technique of object modelling. An object is a collection of attributes and methods. The information of an object is organised in attributes. They represent the characteristics of an object by means of attribute values. The value of an attribute may affect the behaviour of an object. The first attribute in any object is the "logical_name". It is one part of the identification of the object. An object offers a number of methods to either examine or modify the values of the attributes. Objects that share common characteristics are generalised as an interface class with a class_id. Within a specific class the common characteristics (attributes and methods) are described once for all objects. Instantiations of an interface class are called COSEM objects. Manufacturers may add proprietary methods or attributes to any object, using negative numbers. Figure 2 illustrates these terms by means of an example:
Methods Object Class Attributes Instantiation class identifier Register class_id=3 logical_name: octet-string value: instance specific ... Attribute Values
Total Positive Active Energy: Register logical_name = [1 1 1 8 0] value= 1483
reset Total Positive Reactive Energy: Register logical_name = [1 1 3 8 0] value = 57
Figure 2 An interface class and its instances
EXCERPT
DLMS UA 1000-1 ed.4
9/43
The interface class "Register" is formed by combining the features necessary to model the behaviour of a generic register (containing measured or static information) as seen from the client (central unit, hand held terminal). The contents of the register are identified by the attribute "logical_name". The logical_name contains an OBIS identifier (see Clause 5 or IEC 62056-61). The actual (dynamic) content of the register is carried by its "value" attribute. Defining a specific meter means defining several specific registers. In the example of Figure 2 the meter contains 2 registers; i.e. two specific COSEM objects of the class "Register" are instantiated. This means that specific values are assigned to the different attributes. Through the instantiation one COSEM object becomes a "total, positive, active energy register" whereas the other becomes a "total, positive, reactive energy register".
REMARK The COSEM objects (instances of interface classes) represent the behaviour of the meter as seen from the "outside". Therefore modifying the value of an attribute must always be initiated from the outside (e.g. resetting the value of a register). Internally initiated changes of the attributes are not described in this model (e.g. updating the value of a register).
4.1.2 Class Description Notation

This section describes the notation used to define the interface classes. A short text describes the functionality and application of the class. A table gives an overview of the class including the class name, the attributes and the methods. Table 1 Class description template
Class name Attribute(s) 1. logical_name (static) 2. .. (..) 3. (..) Specific Method(s) (if required) 1. .. 2. .. Cardinality Data Type octet-string .. .. m/o .. .. class_id, Version Min. Max. Def
Each attribute and method must be described in detail.

Class name Cardinality Describes the class (e.g. Register, Clock, Profile, ...) Specifies the number of instances of the class within a logical device (see 4.1.5). The class shall be instantiated exactly value times. The class shall be instantiated at least min. times and at most max. times. If min. is zero (0) then the class is optional, otherwise (min. > 0) "min." instantiations of the class are mandatory. Identification code of the class (range 0 to 65 535). The class_id can be obtained from an Association object. The class_id's from 0 to 8 191 are reserved to be specified by the DLMS UA. Class_id's from 8 192 to 32 767 are reserved for manufacturer specific interface classes. Class_id's from 32 768 to 65 535 are reserved for user group specific interface classes. DLMS UA reserves the right to assign ranges to individual manufacturers or user groups. Identification code of the version of the class. The version can be obtained from an Association object. Within one logical device all instances of a certain class must be of the same version. Specifies the attribute(s) that belong to the class. value min...max.
class_id
Version
Attribute(s)
EXCERPT
DLMS UA 1000-1 ed.4 10/43
(dyn.)
Classifies an attribute that carries a process value, which is updated by the meter itself.
(static) logical_name
Data Type Min.
Classifies an attribute which is not updated by the meter itself (e.g. configuration data). octet-string The logical name is always the first attribute of a class. It identifies the instantiation (COSEM object) of this class. The value of the logical_name conforms to OBIS (see Clause 5 or IEC 62056-61). Defines the data type of an attribute (see 4.1.3). Specifies if the attribute has a minimum value. The attribute has a minimum value.
Max.
<empty> The attribute has no minimal value. Defines if the attribute has a maximum value. x The attribute has a maximum value.
Def
<empty> The attribute has no maximum value. Specifies if the attribute has a default value. This is the value of the attribute after reset. x The attribute has a default value.
Specific Method(s)
<empty> The default value is not defined by the class definition. . Provides a list of the specific methods that belong to the object. Method Name () The method has to be described in the subsection "Method Description". Defines if the method is mandatory or optional. The method is mandatory. The method is optional.
m/o
m (mandatory) o (optional)
Attribute Description Describes each attribute with its data type (if the data type is not simple), its data formats and its properties (Minimum value, Maximum value and Default value). Method Description Describes each method and the invoked behaviour of the instantiated COSEM object(s).
NOTE Services for accessing attributes or methods by the protocol are described in DLMS UA 1000-2 or IEC 62056-53.
Selective Access The common methods READ/WRITE and GET/SET typically reference the entire attribute addressed. However, for certain attributes selective access to just part of the attribute may be provided. The part of the attribute is identified by specific selective access parameters. These selective access parameters are defined as part of the attribute specification.
4.1.3 Common Data Types

The following list contains some data types common to all interface classes.
EXCERPT
DLMS UA 1000-1 ed.4 11/43
Simple data types integer, long, double-long, unsigned, long-unsigned, double-long-unsigned, boolean enum
Data types carrying one data item only Simple data types as defined in IEC 61334-4-41:1996 (A.12, Data). Examples: integer Integer8 1 byte long Integer16 2 bytes double-long Integer32 4 bytes The elements of the enumeration type need to be defined in the subsection Attribute Description. Any not listed value for an enumeration is reserved by default. Real data types according to the REAL specification of IEC 61334-441:1996. An ordered sequence of ASCII-characters respectively octets (8-bit bytes). An ordered sequence of boolean values.
real32, real64 visible-string, octet-string
bit-string
Complex data types array compact array structure
More than one data item is included, or the data item itself is not simple The array elements need to be defined in the sub-section Attribute Description. The array elements need to be defined in the sub-section Attribute Description. The structure type needs to be defined in the sub-section Attribute Description. The data type of the attribute needs to be specified in the instantiation of the object for a particular meter (instance model).
instance specific
4.1.4 Data formats for date and time notation

Date and time notations are normally using octet-string as data type, but the formatting of the data is defined precisely. date octet-string{ year highbyte, year lowbyte, month, day of month, day of week } year: interpreted as unsigned16 range 0..big 0xFFFF = not specified year highbyte and year lowbyte reference the 2 bytes of the unsigned 16 month: interpreted as unsigned8 range 1..12, 0xFD,0xFE,0xFF 1 is January 0xFD= daylight_savings_end 0xFE= daylight_savings_begin 0xFF = not specified dayOfMonth: interpreted as unsigned8 range 1..31, 0xFD, 0xFE, 0xFF nd 0xFD = 2 last day of month 0xFE = last day of month 0xE0 to 0xFC = reserved 0xFF = not specified
EXCERPT
DLMS UA 1000-1 ed.4 12/43
dayOfWeek: interpreted as unsigned8 range 1..7, 0xFF 1 is Monday 0xFF = not specified For repetitive dates the unused parts must be set to not specified. time octet-string {hour, minute, second, hundredths} hour: interpreted as unsigned8 range 0..23, 0xFF 0xFF = not specified minute: interpreted as unsigned8 range 0..59, 0xFF 0xFF = not specified second: interpreted as unsigned8 range 0..59, 0xFF 0xFF = not specified hundredths: interpreted as unsigned8 range 0..99, 0xFF 0xFF = not specified} For repetitive times the unused parts must be set to not specified. deviation Integer16 -720..720: in minutes of local time to GMT 0x8000 = not specified
clock_status
Unsigned8 interpreted as 8 bit string The status bits are defined as follows: a bit 0 (LSB): invalid value b bit 1: doubtful value c bit 2: different clock base d bit 3: invalid clock status bit 4: reserved bit 5: reserved bit 6: reserved e bit 7 (MSB): daylight saving active
date_time
octet-string { year highbyte year lowbyte month day of month day of week hour minute second hundredths of second deviation highbyte deviation lowbyte clock status } Individual fields of date_time are encoded as defined above. Some may be set to not specified as described above in date and time.
Time could not be recovered after an incident. Detailed conditions are manufacturer specific (e.g. after the power to the clock has been interrupted). Time could be recovered after an incident but the value cannot be guaranteed. Detailed condi-
EXCERPT
DLMS UA 1000-1 ed.4 13/43
tions are manufacturer specific. Bit is set if the basic timing information for the clock is presently taken from a timing source different from the source specified in clock_base This bit indicates that at least one bit of the clock status is invalid. Some bit may be correct. The exact meaning shall be explained in the manufacturers documentation. Flag set to true: the transmitted time contains the daylight saving deviation (summer time), Flag set to false: the transmitted time does not contain daylight saving deviation (normal time)
4.1.5 The COSEM server model

The COSEM server is structured into 3 hierarchical levels as shown in Figure 3: Level 1: Level 2: Level 3: Physical Device Logical Device Accessible COSEM objects COSEM physical device A
COSEM COSEM COSEM Objects

Logical device 2 Management logical device COSEM
Objects
Figure 3 The COSEM server model The following example (see Figure 4) shows how a combined metering device can be structured using the COSEM server model. Physical device
Combined metering device

Management logical device Logical device 2 Logical device 3
Logical device
LDN Register Objects LDN: COSEM logical device name object A: Association object Total Energy
Register Tariff 1
LDN Register Total Volume A
LDN Register Total Volume
Figure 4 Combined metering device
EXCERPT
DLMS UA 1000-1 ed.4 14/43
4.1.6 COSEM Logical Device

4.1.6.1 General The COSEM Logical Device is a set of COSEM objects. Each physical device must contain a "Management logical device". The addressing of COSEM Logical Devices must be provided by the addressing scheme of the lower layers of the protocol used. 4.1.6.2 COSEM Logical Device Name The COSEM Logical Device can be identified by its unique COSEM Logical Device Name. This name can be retrieved from an instance of IC "SAP Assignment" (see 4.2.14), or of a COSEM object "COSEM Logical Device Name". This name is defined as an octet-string of up to 16 octets. The first three octets uniquely identify the manufacturer of the device. The manufacturer is responsible for guaranteeing the uniqueness of the octets that follow (up to 13 octets). 4.1.6.3 The "Association View" of the Logical Device In order to access COSEM objects in the server, an application association must be first established. This characterises the context within which the associated applications will communicate. The major parts of this context are information on the application context; information on the COSEM context; information on the authentication mechanism used; etc. This information is contained in a special COSEM object, the "Association" object. There are two types of this Association object defined. One for associations using Short Name referencing (Association SN) and one for using Logical Name referencing (Association LN). Depending on the association established between the client and the server different access rights may be granted by the server. Access rights concern a set of COSEM objects - the Visible objects - which can be accessed ('seen') within the given association. In addition, access to attributes and methods of these COSEM objects may also be restricted within the association (e.g. a certain type of clients can only read a particular attribute of a COSEM object). The list of the visible COSEM objects - the "Association View" - can be obtained by the client by reading the "object_list" attribute of the appropriate Association object. Additional information about the access rights (read only, write only, read and write) to the attributes and the availability of the methods (within the established association) can be found via specific methods provided by the Association objects (see 4.2.12, 4.2.13). 4.1.6.4 Mandatory Contents of a COSEM Logical Device The following objects must be part of each COSEM logical device. They must be accessible for GET/READ in all application associations with this logical device: COSEM logical device name object Current Association (LN or SN) object
EXCERPT
DLMS UA 1000-1 ed.4 15/43
4.1.7 Authentication Procedures

4.1.7.1 Low Level Security (LLS) Authentication more details, see complete Blue Book DLMS UA 1000-1 ... 4.1.7.2 High Level Security (HLS) Authentication more details, see complete Blue Book DLMS UA 1000-1 ...
EXCERPT
DLMS UA 1000-1 ed.4 16/43
4.2 The interface classes

The currently defined interface classes for meters and the relations between them are illustrated in Figure 5.
NOTES The interface class "Base" itself is not specified explicitly. It contains only one attribute "logical_name". In the description of the "Demand Register", "Clock" and "Profile Generic" interface classes, the 2nd attributes are labelled differently than the 2nd attribute of the "Data" interface class, namely "current_average_value", "time" and "buffer" vs. "value". This is to emphasise the specific nature of the "value".
Base Data Register Extended Register Demand Register Clock Profile Generic Association LN Association SN Register Activation Script Table Schedule SAP Assignment IEC optical port Setup Activity Calendar Register Monitor Special Days Table Single Action Schedule PSTN modem config.
PSTN auto answer
Figure 5 Overview of the interface classes

PSTN auto dial IEC HDLC Setup
IEC Twisted Pair (1) Setup
Utility Tables
EXCERPT
DLMS UA 1000-1 ed.4 17/43
4.2.1 Data (class_id: 1)

A Data object stores data related to internal meter object(s). The meaning of the value is identified by the logical_name. The data type of the value is instance specific. Data is typically used to store manufacturer specific configuration data and parameters having manufacturer specific logical names.
Data Attribute(s) 1. logical_name 2. value Specific Method(s) 0..n Data Type octet-string instance specific m/o class_id = 1, Version = 0 Min. Max. Def
(static)
Attribute Description
logical_name value Identifies the data contained in value. Identifiers are specified in 4.6.1. Contains the data. instance specific
The data type of the value depends on the instantiation defined by logical_name.
4.2.2 Register (class_id: 3)

A Register object stores a process value or a status value with its associated unit. The Register object knows the nature of the process value or of the status value. The nature of the value is described by the attribute "logical name" using the OBIS identification system (see 4.6.1).
Register Attribute(s) 1. logical_name 2. value 3. scaler_unit Specific Method(s) 1. reset 0..n Data Type octet-string instance specific scal_unit_type m/o o class_id = 3, Version = 0 Min. Max. Def
(static) (dyn.) (static)
value Contains the current process or status value. The data type of the value depends on the instantiation defined by logical_name and possibly from the manufacturer. Therefore, this attribute must provide the value and the data type when it is accessed by a client. The type has to be chosen such that, together with the logical_name, an unambiguous interpretation of the value is possible. Provides information on the unit and the scaler of the value. If the value uses a complex data type, the scaler and unit apply to all elements. scal_unit_type: structure { scaler, unit } DLMS User Association instance specific
scaler_unit
EXCERPT
DLMS UA 1000-1 ed.4 18/43
scaler: integer
This is the exponent (to the base of 10) of the multiplication factor
REMARK If the value is not numerical then the scaler shall be set to 0.
unit: enum
Enumeration defining the physical unit; details see below
Method Description
reset (data) This method forces a reset of the object. By invoking this method the value is set to the default value. The default value is an instance specific constant. data ::= integer(0)
unit ::= enum Code (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25) (26) (27) (28) (29) (30) (31) (32) (33) (34) (35) (36) (37) (38) (39) (40) (41)
// Unit a mo wk d h min. s C currency m m/s 3 m 3 m 3 m /h 3 m /h 3 m /d 3 m /d l kg N Nm Pa bar J J/h W VA var Wh VAh varh A C V V/m F 2 m /m Wb T
// // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // // //
Quantity time time time time time time time (t) (phase) angle temperature (T) (local) currency length (l) speed (v) volume (V) corrected volume volume flux corrected volume flux volume flux corrected volume flux volume mass (m) force (F) energy pressure (p) pressure (p) energy thermal power active power (P) apparent power (S) reactive power (Q) active energy apparent energy reactive energy current (I) electrical charge (Q) voltage (V) electrical field strength (E) capacity (C) resistance (R) resistivity () magnetic flux () induction (T)
Unit year month week day hour minute second degree degree centigrade meter
SI definition
7*24*60*60 s 24*60*60 s 60*60 s 60 s s rad*180/ K-273.15
kilogram newton newtonmeter pascal bar joule watt
m m/s 3 m 3 m 3 m /(60*60s) 3 m /(60*60s) 3 m /(24*60*60s) 3 m /(24*60*60s) -3 3 10 m kg N J = Nm = Ws 2 N/m -5 2 10 N/m J = Nm = Ws J/(60*60s) W = J/s
ampere coulomb Volt farad ohm weber tesla
W*(60*60s) VA*(60*60s) var*(60*60s) A C = As V V/m C/V = As/V = V/A m Wb = Vs 2 Wb/m
EXCERPT
DLMS UA 1000-1 ed.4 19/43
Code (42) (43) (44) (45) (46) (47) (48) (49) (50) (51) (52) ... (253) (254) (255)
// Unit A/m H Hz Rac Rre Rap Vh 2 Ah kg/s S mho

2
Quantity Unit magnetic field strength (H) inductivity (L) henry hertz frequency (f, ) active energy meter constant // reactive energy meter constant // apparent energy meter constant // // // mass flux // conductance siemens // // // // // // // // // reserved ... reserved other unit no unit, unitless, count
SI definition A/m H = Wb/A 1/s 1/(Wh)
V (60*60s) 2 A (60*60s) kg/s 1/
other count
Table 2 Example of values and units

Value 263788 593 3467 Scaler -3 3 0 Unit 3 m Wh V Data 3 263,788 m 593 kWh 3467 V
4.2.3 Extended Register (class_id: 4)

Instances of an Extended Register class store a process value with its associated status, unit, and time information. The Extended Register object knows the nature of the process value. The nature of the value is described by the attribute "logical name" using the OBIS identification system. more details, see complete Blue Book DLMS UA 1000-1 ...
4.2.4 Demand Register (class_id: 5)

Instances of a Demand Register class store a demand value with its associated status, unit, and time information. The demand register measures and computes its current_average_value periodically. The time interval T over which the demand is measured or computed is defined by specifying "number_of_periods" and "period".
T = number_of_periods * period T is the time interval used for calculation of the current_value of a sliding demand register
2
period
1 t
capture_time now
start_time_current
Figure 6 The attributes when measuring sliding demand The demand register delivers two types of demand: the current_average_value and the last_average_value (see Figure 7).
EXCERPT
DLMS UA 1000-1 ed.4 20/43
The demand register knows its type of process value which is described in "logical name" using the OBIS identification system.
energy/period period last_average_value current_average_value 0 start_time_current now start_time+period t
Figure 7 The attributes when measuring current_average_value if number of periods is 1 more details, see complete Blue Book DLMS UA 1000-1 ...
4.2.5 Register Activation (class_id: 6)

An instance of the Register Activation class is used to handle different tariffication structures. It specifies which Register, Extended Register and Demand Register objects are enabled if a specific Activation Mask is active (active_mask). All other register objects defined in register_assignment not being part of the active_mask are disabled. All register objects not defined in any register_assignment are enabled by default. more details, see complete Blue Book DLMS UA 1000-1 ...
4.2.6 Profile Generic (class_id: 7)

The Profile Generic class defines a generalised concept to store dynamic process values of capture objects. A capture object is either a register, a clock or a profile. The capture objects are collected periodically or occasionally. A profile has a buffer to store the captured data. To retrieve a part of the buffer, either a value range or an entry range may be specified, asking to retrieve all entries whose values or entry numbers fall within the given range. Assigning the corresponding objects to the profile specifies the capture objects the values of which have to be retained (with method capture). The buffer has homogenous entries (all have the same size and structure), and the assignment is defined statically. The modification of the capture object assignment clears the buffer of the profile completely. All profiles capturing this modified profile will be cleared as well to guarantee the homogeneity of their entries. The buffer may be defined as sorted by one of the registers or by a clock, or the entries are stacked in a "last in first out" order. So for example, it is very easy to build a "maximum demand register" with a one entry deep sorted profile capturing and sorted by a demand register. It is just as simple to define a profile retaining the three largest values of some period.
more details, see complete Blue Book DLMS UA 1000-1 ...
4.2.7 Clock (class_id: 8)

An instance of the clock interface class handles all information that is related to date and time, including leap years and the deviation of the local time to a generalised time reference (Greenwich
EXCERPT
DLMS UA 1000-1 ed.4 21/43
Mean Time GMT). The deviation from the local time to the generalised time reference can change depending on the season (e.g. summer time vs. wintertime). The interface to an external client is based on date information specified in day, month and year, time information given in hundredths of seconds, seconds, minutes and hours and the deviation from the local time to the generalised time reference. It also handles the daylight savings function in that way; i.e. it modifies the deviation of local time to GMT depending on the attributes. The start and end point of that function is normally set once. An internal algorithm calculates the real switch point depending on these settings.
Deviation
LocalTime
GMT daylight_savings_begin daylight_savings_end
Figure 8 The generalised time concept

Clock Attribute(s) 1. logical_name 2. time 3. time_zone 4. status 5. daylight_savings_begin 6. daylight_savings_end 7. daylight_savings_deviation 8. daylight_savings_enabled 9. clock_base Specific Method(s) 1. adjust_time 2. adjust_to_measuring_period 3. adjust_to_minute 4. adjust_to_preset_time 5. preset_adjusting_time 6. shift_time 0..1 Data Type octet-string octet-string long unsigned8 octet-string octet-string integer boolean enum m/o o o o o o o class_id = 8, Version = 0 Min. Max. Def
(static) (dyn.) (static) (dyn.) (static) (static) (static) (static) (static)
time Contains the meters local date and time, its deviation to GMT and the status. See also the description in 4.1.4. When this value is set, only specified fields of the date_time are changed. For example for setting the date without changing the time, all time relevant octets of the date_time must be set to not specified. The clock_status must always be set when writing the time. DLMS User Association
EXCERPT
DLMS UA 1000-1 ed.4 22/43
time_zone
octet-string, formatted as set in 4.1.4 for date_time. The deviation of local, normal time to GMT in minutes. long The status is equal to the status read in time. See also the description in 4.1.4. unsigned8, formatted as set in 4.1.4 for clock_status Defines the local switch date and time when the local time has to be deviated from the normal time. For generic definitions wildcards are allowed. octet-string, formatted as set in 4.1.4 for date_time. See above. octet-string, formatted as set in 4.1.4 for date_time. Contains the number of minutes by which the deviation in generalised time must be corrected at daylight savings begin. integer Deviation range of up to 120 min TRUE enables daylight savings function. boolean
status
daylight_savings_begin
daylight_savings_end
daylight_savings_deviation
daylight_savings_enabled
clock_base
Defines where the basic timing information comes from. enum (0) (1) (2) (3) (4) (5) not defined internal crystal mains frequency 50 Hz mains frequency 60 Hz GPS (global positioning system) Radio Controlled
Method Description
adjust_time (data) Sets the meters time to the nearest (+/-) quarter of an hour value (*:00, *:15, *:30, *:45). data ::= integer (0). Sets the meters time to the nearest (+/-) starting point of a measuring period. data ::= integer (0). Sets the meters time to the nearest minute. If second_counter < 30 s, so second_counter is set to 0. If second_counter 30 s, so second_counter is set to 0 and minute_counter and all depending clock values are incremented if necessary. data ::= integer(0) This method is used in conjunction with the preset_adjusting_time method. If the meters time lies between validity_interval_start and validity_interval_end, then time is set to preset_time. data ::= integer(0) Presets the time to a new value (preset_time) and defines a
adjust_to_measuring_period (data)
adjust_to_minute (data)
adjust_to_preset_time (data)
preset_adjusting_time (data) DLMS User Association
EXCERPT
DLMS UA 1000-1 ed.4 23/43
validity_interval within which the new time can be activated. data ::= structure { preset_time: octet-string; validity_interval_start: octet-string; validity_interval_end: octet-string } all octet-strings formatted as set in 4.1.4 for date_time. Shifts the time by n (-900 <= n <= 900) s. data ::= long
shift_time (data)
4.2.8 Script Table (class_id: 9)

The IC Script table provides the possibility to trigger a series of actions by activating an execute method. For that purpose Script table contains a table of script entries. Each table entry (script) consists of a script_identifier and a series of action_specifications. An action_specification activates a method of a COSEM object or modifies attributes of a COSEM object within the logical device. A specific script may be activated by other COSEM objects within the same logical device or from the outside.
4.2.9 Schedule (class_id: 10)

The IC Schedule together with an object of the IC Special Days Table handles time and date driven activities within a device.
4.2.10 Special Days Table (class_id: 11)

The interface class allows defining dates, which will override normal switching behaviour for special days. The interface class works in conjunction with the class "Schedule" or "Activity Calendar" and the linking data item is day_id.
4.2.11 Activity Calendar (class_id: 20)

An instance of the Activity Calendar class is typically used to handle different tariffication structures. It is a definition of scheduled actions inside the meter, which follow the classical way of calendar based schedules by defining seasons, weeks... It can coexist with the more general object Schedule and can even overlap with it. If actions are scheduled for the same activation time in an object Schedule and in the object Activity Calendar, the actions triggered by Schedule are executed first. After a power failure only the "last action" missed from the object Activity Calendar is executed (delayed). This is to ensure proper tariffication after power up. If a Schedule object is present, then the missed "last action" of the Activity Calendar must be executed at the correct time within the sequence of actions requested by the Schedule.
EXCERPT
DLMS UA 1000-1 ed.4 24/43
The Activity Calendar defines the activation of certain scripts, which can perform different activities inside the logical device. The interface to the object Script is the same as for the object Schedule. (see 4.2.9) If an instance of the interface class "Special Days Table" (see 4.2.10) is available, relevant entries there take precedence over the Activity Calendar object driven selection of a day profile. The day profile referenced in the "Special Days Table" activates the day_schedule of the day_profile_table in the "Activity Calendar" object by referencing through the day_id.
4.2.12 Association LN (class_id: 15)

COSEM Logical Devices able to establish application associations within a COSEM context using Logical Name references, model the associations through instances of the Association LN class. A COSEM Logical Device has one instance of this IC for each association the device is able to support.
4.2.13 Association SN (class_id: 12)

COSEM Logical Devices able to establish application associations within a COSEM context using Short Name references, model the associations through instances of the Association SN class. A COSEM Logical Device has one instance of this IC for each association the device is able to support. The short_name of the Association SN object itself is fixed within the COSEM context. It is given in 4.5.2 as 0xFA00
4.2.14 SAP Assignment (class_id: 17)

The interface class SAP Assignment contains the information on the assignment of the logical devices to their Service Access Points (SAP) (see DLMS UA 1000-2 or IEC 62056-46)..
4.2.15 Register Monitor (class_id: 21)

This interface class allows to define a set of scripts (see 4.2.8) that are executed when the value of an attribute of a monitored register type object (Data, Register, Extended Register, Demand Register, etc.) crosses a set of threshold values. The IC Register Monitor requires an instantiation of the IC Script Table in the same logical device.
EXCERPT
DLMS UA 1000-1 ed.4 25/43
4.2.16 Utility Tables (class_id: 26)

An instance of the Utility Tables class encapsulates ANSI C12.19:1997 table data. With this interface class definition, each "Table" is represented as an instance. The specific instance is identified by its logical_name.
4.2.17 Single Action Schedule (class_id: 22)

Many applications request periodic actions within a meter. These actions are not necessarily linked to tariffication (activity calendar or schedule). more details, see complete Blue Book DLMS UA 1000-1 ...
4.3 Maintenance of the Interface Classes

4.4 Protocol related Interface Classes

Each communication device and / or protocol needs some setup parameters to be defined for proper operation.
4.5 Using Short Names for accessing attributes and methods

Attributes and methods of COSEM objects can be referenced in two different ways: Using COSEM Logical Names: In this case the attributes and methods of a COSEM object are referenced via the identifier of the COSEM object instance to which they belong. The reference for an attribute is: class_id, value of the 'logical_name' attribute, attribute_index; The reference for a method is: class_id, value of the 'logical_name' attribute, method_index; attribute_index is used as the identifier of the required attribute. method_index is used as the identifier of the required method. Using Short Names: This kind of referencing is intended for use in simple devices. In this case each attribute and method of a COSEM object is identified with a 13 bit integer. The syntax for the Short Name is the same as the syntax of the name of a DLMS Named Variable.
EXCERPT
DLMS UA 1000-1 ed.4 26/43
4.5.1 Guidelines for Assigning Short Names

This clause gives guidelines for assigning short names for public attributes and methods.
Data class_id = 1, Version = 0 Attribute(s) logical_name value Specific Method(s) Register class_id = 3, Version = 0 Attribute(s) logical_name value scaler_unit Specific Method(s) reset Short name Remarks
x x+8
x is the base_name of the object.
Short name
Remarks
x x+8 x+16 x+40
x is the base name of the object.
4.5.2 Reserved base_names for Special COSEM Objects

In order to grant access for devices offering accessing by short_names some short_names are reserved as base_names for special COSEM objects. The reserved range of names is from 0xFA00 to 0xFFF8. Table 3 Reserved base_names for Special COSEM Objects
base_name (objectName) 0x FA00 0x FB00 0x FC00 0x FD00 COSEM object Association SN Script Table (instantiation: broadcast_receiver script) SAP Assignment Register object containing the COSEM Logical Device Name in the attribute "value"
4.6 Relation to OBIS

The OBIS identification system serves as a basis for the COSEM logical names. The system of naming COSEM objects is defined in the basic principles (see 4.1) the identification of real data items is specified in Clause 5 or IEC 62056-61. The following clauses define the usage of those definitions in the COSEM environment. All codes, which are not explicitly listed, but below the manufacturer specific range (128 .. 255) are reserved for future use.
EXCERPT
DLMS UA 1000-1 ed.4 27/43
4.6.1 Mapping of Data Items to COSEM Objects and Attributes

This clause defines the usage of OBIS identifications and their mapping to COSEM objects of certain interface classes and their attributes.
4.6.2 Coding of OBIS Identifications

To identify different instances of the same interface class they have to differ in their logical_name. In COSEM the logical_name is taken from the OBIS definition (see Clause 5 or IEC 62056-61). OBIS codes are used within the COSEM environment as an octet-string[6]. Each octet contains the unsigned value of the corresponding OBIS value group, coded without tags. If a data item is identified by less than 6 value groups, all unused value groups must be filled with 0xFF.
4.7 Previous Versions of Interface Classes

This chapter lists those interface class definitions which where included in previous editions of this document. The previous interface class versions differ form the current versions by at least one attribute and/or method and by the version number. For new implementations in metering devices only the current versions shall be used. Communication drivers at the client side must also support previous versions. more details, see complete Blue Book DLMS UA 1000-1 ...
EXCERPT
DLMS UA 1000-1 ed.4 28/43
5. COSEM Object Identification System (OBIS)
5.1 Introduction
The competitive electricity market requires an ever-increasing amount of timely information concerning the usage of electrical energy. Recent technology developments enable to build intelligent static metering equipment, which are capable to capture, process and communicate this information to all parties involved. For further analysis of this information, for the purposes of billing, load-, customer- and contract management, it is necessary to uniquely identify all data in a manufacturer independent way collected manually or automatically, via local or remote data exchange. The definition of identification codes was based on DIN 43863-3 December:1997, Electricity meters Part 3: Tariff metering device as additional equipment for electricity meters EDIS Energy Data Identification System
5.2 Scope
The Object Identification System (OBIS) defines the identification codes (ID-codes) for commonly used data items in electricity metering equipment. This standard specifies the overall structure of the identification system and the mapping of all data items to their identification codes. The Object Identification System (OBIS) provides a unique identifier for all and every data within the metering equipment, including not only measurement values, but also abstract values used for configuration or obtaining information about the behaviour of the metering equipment. The ID codes defined in this standard are used for identification of logical names of the various instances of the Interface Classes, or objects, as defined in Clause 4 or IEC 62056-62; data transmitted through communication lines (see 5.5.1); data displayed on the metering equipment (see 5.5.2). This standard applies to all types of electricity metering equipment, like fully integrated meters, modular meters, tariff attachments, data concentrators etc. To cover metering equipment measuring other energy types than electricity, combined metering equipment measuring more than one type of energy or metering equipment with several physical measurement channels, the concept of channels and medium are introduced. This allows meter data originating from different sources to be identified. While this standard fully defines the structure of the identification system for other media, the mapping of non-electrical energy related data items to ID codes needs to be completed separately. In co-operation with CEN TC294, WG2 some non-electrical codes are already implemented.
5.3 OBIS Object identification system structure

OBIS codes are a combination of six value groups, which describe in a hierarchical way the exact meaning of each data item (see Figure 9).
EXCERPT
DLMS UA 1000-1 ed.4 29/43
Figure 9 OBIS code structure
5.3.1 Value group A

The value group A defines the characteristic of the data item to be identified (abstract data, electricity-, gas-, heat-, water-related data).
5.3.2 Value group B

The value group B defines the channel number, i.e. the number of the input of a metering equipment having several inputs for the measurement of energy of the same or different types (e.g. in data concentrators, registration units). Data from different sources can thus be identified. The definitions for this value group are independent from the value group A.
5.3.3 Value group C

The value group C defines the abstract or physical data items related to the information source concerned, e.g. current, voltage, power, volume, temperature. The definitions depend on the value of the Value group A. Measurement, tariff processing and data storage methods of these quantities are defined by value groups D, E and F. For abstract data the hierarchical structure of the 6 code fields is not applicable.
5.3.4 Value group D

The value group D defines types, or the result of the processing of physical quantities identified with the value groups A and C, according to various specific algorithms. The algorithms can deliver energy and demand quantities as well as other physical quantities.
5.3.5 Value group E

The value group E defines the further processing of measurement results identified with value groups A to D to tariff registers, according to the tariff(s) in use. For abstract data or for measurement results for which tariffs are not relevant, this value group can be used for further classification.
5.3.6 Value group F

The value group F defines the storage of data, identified by value groups A to E, according to different billing periods. Where this is not relevant, this value group can be used for further classification.
5.3.7 Manufacturer specific codes

If any value group C to F contains a value between 128 and 254 the whole code is considered as manufacturer specific.
EXCERPT
DLMS UA 1000-1 ed.4 30/43
5.4 Value group definitions

5.4.1 Value group A
The range for value group A is 0 to 15. Table 4 Value group A codes
0 1 4 5 6 7 8 9 Value group A Abstract objects Electricity-related objects Heat cost allocator related objects Cooling related objects Heat-related objects Gas-related objects Cold water-related objects Hot water related objects
1
All other possible values are reserved .
5.4.2 Value group B

The range for value group B is 1 to 255. Table 5 Value group B codes
0 1 64 65127 128 .. 254 255 Value group B No channel specified Channel 1 Channel 64 Reserved Manufacturer specific codes Reserved
With implementations that contain one channel only, even not channel-specific data can be assigned to channel 1.
5.4.3 Value group C

The range for value group C is 0 to 255. 5.4.3.1 Abstract objects Abstract objects are data items, which are not related to a certain type of physical quantity. Table 6 Value group C codes (abstract objects)
Value group C Abstract objects (A = 0) a Context specific identifiers
089
Administered by the DLMS User Association
EXCERPT
DLMS UA 1000-1 ed.4 31/43
94 96 97 98 127 128254 All other

a
Country specific identifiers General service entries, see 5.4.7 General error messages, see 5.4.7 General list objects, see 5.4.9 Inactive objects Manufacturer specific codes Reserved
b
Context specific identifiers identify objects specific to a certain protocol and/or application. For the COSEM context the identifiers are defined in Clause 4 or IEC 62056-62.
An inactive object is an object, which is defined and present in a meter, but which has no assigned functionality.
5.4.3.2 Quantities for electrical energy related objects Table 7 Value group C codes (electricity objects)
Value group C Electricity related objects (A = 1) General purpose objects (see 5.4.8) Li Active power+ Li Active powerLi Reactive power+ Li Reactive powerLi Reactive power QI Li Reactive power QII Li Reactive power QIII Li Reactive power QIV Li Apparent power+ Li Apparent powerCurrent: any phase Voltage: any phase Average power factor Supply frequency LI Active power QI+QIV+QII+QIII LI Active power QI+QIV-QII-QIII Li Active power QI Li Active power QII Li Active power QIII Li Active power QIV L1 Active power+ L1 Active powerL1 Reactive power+ L1 etc. (see 4-10) a L1 Current L1 Voltage L1 Power factor L1 Frequency L1 Active power ... etc. (see 15-20) L2 Active power+ L2 Active power-
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24-30 31 32 33 34 35-40 41 42 DLMS User Association
EXCERPT
DLMS UA 1000-1 ed.4 32/43
43 44-60 61 62 63 64-80 81 82 91 92
L2 Reactive power+ L2 etc. (see 24-40) L3 L3 L3 L3 Active power+ Active powerReactive power+ etc. (see 24-40)
b
Angles Unitless quantity (pulses or pieces) L0 current (neutral) L0 voltage(neutral)
96 97 98 99 127 128 .. 254 255

NOTES
Electricity-related service entries, see 5.4.7 Electricity-related error messages Electricity list Electricity data profile see 5.4.10 Reserved Manufacturer specific code Reserved
L i Quantity is the value (to be measured) of a measurement system connected between the phase i and a reference point. In 3 phase 4-wire systems the reference point is the neutral. In 3 phase 3-wire systems the reference point is the phase L 2 .
a b
L i quantity is the total measurement value across all systems.

For details of extended codes, see 5.4.5.1 For details of extended codes, see 5.4.5.2
The quadrant definitions are according to IEC 61268:1995 - Annex E, Figure E.1.
Figure 10 Quadrants for power measurement
5.4.4 Value group D

The range for value group D is 0 to 255. 5.4.4.1 Electricity related objects Table 8 Value group D codes (electricity)
Value group D Electricity related objects A = 1, C <> 0, 96,97,98,99 Billing period average (since last reset) Cumulative minimum 1 Cumulative maximum 1 Minimum 1 Current average 1 Last average 1 Maximum 1 Instantaneous value Time integral 1 Time integral 2
0 1 2 3 4 5 6 7 8 9
EXCERPT
DLMS UA 1000-1 ed.4 33/43
10 11 12 13 14 15 16
Time integral 3 Cumulative minimum 2 Cumulative maximum 2 Minimum 2 Current average 2 Last average 2 Maximum 2
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 55 58 128 .. 254 all other
Cumulative minimum 3 Cumulative maximum 3 Minimum 3 Current average 3 Last average 3 Maximum 3 Current average 5 Current average 6 Time integral 5 Time integral 6 Under limit threshold Under limit occurrence counter Under limit duration Under limit magnitude Over limit threshold Over limit occurrence counter Over limit duration Over limit magnitude Missing threshold Missing occurrence counter Missing duration Missing magnitude Test average Time integral 4 Manufacturer specific codes Reserved
NOTES Averaging Scheme 1 Controlled by measurement period 1 (see 5.4.8) a set of registers is calculated by a metering device. (codes 1..6). The typical usage is for billing purposes. Averaging Scheme 2 Controlled by measurement period 2 (see 5.4.8) a set of registers is calculated by a metering device. (codes 11..16). The typical usage is for billing purposes. Averaging Scheme 3 Controlled by measurement period 3 (see 5.4.8) a set of registers is calculated by a metering device. (codes 21..26). The typical usage is for instantaneous values. Averaging Scheme 4 Controlled by measurement period 4 (see 5.4.8) a test average value. (code 55) is calculated by the metering device. Last average
EXCERPT
DLMS UA 1000-1 ed.4 34/43
The value of the demand register at the end of the last measurement period. Current average 5 The value of a current demand register using recording interval 1 as time base. Current average 6 The value of a current demand register using recording interval 2 as time base. Time integral 1 Without the inclusion of a billing period code (F <> 255): time integral of the quantity calculated from the origin (first start of measurement) to the instantaneous time point. With a billing period code included (0<=F<100): time integral of the quantity calculated from the origin to the end of the billing period given by the billing period code. Time integral 2 Without the inclusion of a billing period code(F <> 255): Time integral of the quantity calculated from the beginning of the current billing period to the instantaneous time point. With a billing period code included (0<=F<100): Time integral of the quantity calculated over the billing period given by the billing period code. Time integral 3 Time integral of the positive difference between the quantity and a prescribed threshold value. Time integral 4 ("Test time integral) Time integral of the quantity calculated over a time specific to the device or determined by test equipment. Time integral 5 used as a base for load profile recording: Time integral of the quantity calculated from the beginning of the current recording interval to the instantaneous time point for recording period 1. Time integral 6 used as a base for load profile recording: Time integral of the quantity calculated from the beginning of the current recording interval to the instantaneous time point for recording period 2. Under limit values Values under a certain threshold (e.g. dips). Over limit values Values above a certain threshold (e.g. swells). Missing values Values considered as missing (e.g. interruptions).
For identifiers of abstract objects see 5.4.7. For identifiers of electricity related General purpose objects see 5.4.8. 5.4.4.2 Value group D for country specific identifiers This table specifies the identifiers for country specific applications. Wherever possible the phone codes are used. In this table there are no reserved ranges for manufacturer specific codes. The usage of value group E and F are defined in country specific documents. Table 9 Value group D codes (country specific)
Value group D a Country specific identifiers (A = 0, C = 94) Finnish identifiers USA identifiers Canadian identifiers Russian identifiers Czech identifiers Bulgarian identifiers Croatian identifiers Irish identifiers
00 01 02 07 10 11 12 13
EXCERPT
DLMS UA 1000-1 ed.4 35/43
14 15 16 27 30 31 32 33 34 35 36 38 39 40 41 42 43 44 45 46 47 48 49 55 61 62 64 65 81 86 90 91
a
Israeli identifiers Ukraine identifiers Yugoslavian identifiers South African identifiers Greece identifiers Dutch identifiers Belgian identifiers French identifiers Spanish identifiers Portuguese identifiers Hungarian identifiers Slovenian identifiers Italian identifiers Romanian identifiers Swiss identifiers Slovakian identifiers Austrian identifiers United Kingdom identifiers Danish identifiers Swedish identifiers Norwegian identifiers Polish identifiers German identifiers Brazilian identifiers Australian identifiers Indonesian identifiers New Zealand identifiers Singapore identifiers Japanese identifiers Chinese identifiers Turkish identifiers Indian identifiers
Must be limited to two characters NOTE 1 All other codes reserved NOTE 2 Objects that are already identified in this document but not included in 5.4.4.2 must not be re-identified by a country specific identifier.
5.4.5 Value group E

The range for value group E is 0 to 255. Table 10 Value group E codes (electricity)
Value group E Electrical energy related objects (A=1) Total
EXCERPT
DLMS UA 1000-1 ed.4 36/43
1 2 3 .. 9 .. 63 128254 all other
Rate 1 Rate 2 Rate 3 ... Rate 9 Rate 63 Manufacturer specific code Reserved
This table is not valid if one of the following separate specifications for value group E apply. 5.4.5.1 Usage of value group E for current and voltage measurements The following table show the meaning of the group E value while measuring current or voltage. Table 11 Extended current/voltage measurement
Value group E Electrical energy related objects (A = 1); current/voltage measurement (C = 31, 51, 71, 32, 52 or 72; D = 7) Total 0 st 1 harmonic (fundamental) 1 nd 2 harmonic 2 th n harmonic th 127 harmonic 127 128254 255 manufacturer specific Reserved
5.4.5.2 Usage of value group E for measuring angles The following table shows the meaning of the group E value while measuring angles. Table 12 Extended angle measurement
Value group E Electrical energy related objects (A = 1); angle measurement (C = 81; D = 7) Angle U(L1) U(L2) U(L3) I(L1) I(L2) I(L3) I(L0) U(L1) (00) 10 20 40 50 60 70 U(L2) 01 (11) 21 41 51 61 71 U(L3) 02 12 (22) 42 52 62 72 I(L1) 04 14 24 (44) 54 64 74 I(L2) 05 15 25 45 (55) 65 75 I(L3) 06 16 26 46 56 (66) 76 I(L0) 07 17 27 47 57 67 (77) <= From
^ To (Reference)
For identifiers of abstract objects see 5.4.7. For identifiers of electricity related General purpose objects see 5.4.8.
EXCERPT
DLMS UA 1000-1 ed.4 37/43
5.4.6 Value group F

The range for value group F is 0 to 255. In all cases, if value group F is not used, it is set to 255. 5.4.6.1 Usage of value group F for billing periods Value group F specifies the allocation to different billing periods (sets of historical values) for the objects with following codes: Value Group A: 1 Value Group C: 1 to 99 Value Group D: 0 to 3; 6; 8 to 13; 16; 21 to 23; 26. This allocation is valid for 0<=F<100.
5.4.7 Abstract objects

Table 13 Abstract object codes
Abstract objects, general service entries Device ID numbers (non energy/channel related) Complete device ID (manufacturing number) Device ID 1 ............ Device ID 10 Parameter changes, calibration and access Number of configuration program changes Date of last configuration program change Date of last time switch program change Date of last ripple control receiver program change Status of security switches Date of last calibration Date of next configuration program change a Number of protected configuration program changes a Date of last protected configuration program change Input/output control signals State of the input control signals State of the output control signals State of the internal control signals Internal operating status Battery entries Battery use time counter Battery charge display Date of next change Battery voltage Number of power failures Total failure of all three phases longer than internal autonomy Phase L1 Phase L2 Phase L3 Operating time Time of operation Time of registration rate 1 Time of registration rate 2 Time of registration rate 63 Environmental related parameters OBIS code A 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 B 0 0 0 x x x x x x x x x x x x x x x x x 0 0 0 0 x x x x C 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 96 D 1 1 1 2 2 2 2 2 2 2 2 2 3 3 4 5 6 6 6 6 7 7 7 7 8 8 8 8 E F
0 9 0 1 2 3 4 5 6 10 11 1 2 0 0 0 1 2 3 0 1 2 3 0 1 2 63
EXCERPT
DLMS UA 1000-1 ed.4 38/43
Abstract objects, general service entries Ambient temperature Manufacturer specific ..................... Manufacturer specific
a
OBIS code A 0 0 0 B x x x C 96 96 96 D 9 50 96 E 0 x x F x x
Protected configuration is characterized by the need to open the main meter cover to modify it, or to break a metrological seal. If a value field is shaded, then this value group is not used. x is equal to any value within the range.
REMARK
Table 14 General error messages

Abstract objects, general error messages Error object
REMARK
a
OBIS code A 0 B x C 97 D 97 E a x F
If a value field is shaded, then this value group is not used. x is equal to any value within the range.
If only one object is instantiated, the value shall be 0
In the manufacturer specific objects only those values shall be placed, which are not represented by another defined code, but need representation on the display as well. If this is not required, the code shall use the possibilities of a value group above 127.
5.4.8 Electricity-related General purpose objects

Table 15 General purpose codes (electricity)
Electricity related General purpose objects Free ID-numbers for utilities Complete combined electricity ID Electricity ID 1 ... Electricity ID 10 Billing period values/reset counter entries Billing period counter Number of available billing periods Time stamp of the billing period VZ (last reset) Time stamp of the billing period VZ-1 ......................................................... Time stamp of the billing period VZ-n Program entries Configuration program version number Parameter record number Time switch program number RCR program number Meter connection diagram ID Output pulse constants RLW (Active energy, metrological LED ) RLB (Reactive energy, metrological LED) RLS (Apparent energy, metrological LED) RAW (Active energy, output pulse) RAB (Reactive energy, output pulse) RAS (Apparent energy, output pulse) Ratios DLMS User Association OBIS-code A B C 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 x x x x x x x x x x x x x x x x x x x 0 0 0 0 0 0 0 ..... 0 0 0 0 0 0 0 0 0 0 0 0 D 0 0 0 1 1 1 1 ...... 1 2 2 2 2 2 3 3 3 3 3 3 E F
0 9 0 1 2 2 ...... 2 0 1 2 3 4 0 1 2 3 4 5
VZ VZ-1 ....... VZ-n
EXCERPT
DLMS UA 1000-1 ed.4 39/43
Electricity related General purpose objects Reading factor for power Reading factor for energy b Transformer ratio current (numerator) b Transformer ratio voltage (numerator) b Overall transformer ratio (numerator) b Transformer ratio current (denominator) b Transformer ratio voltage (denominator) b Overall transformer ratio voltage (denominator) Nominal values Voltage [V] Basic/nominal current [A] Frequency [Hz) Maximum current [A] Reference voltage for power quality measurement Input pulse constants REW [Imp/kWh] (active energy) REB [Imp/kvarh] (reactive energy) RES [Imp/kVAh] (apparent energy) Measurement-/registration-period duration Measurement period 1, for average value 1 Measurement period 2, for average value 2 Measurement period 3, for instantaneous value Measurement period 4, for test value Recording interval 1, for load profile Recording interval 2, for load profile Billing period Time entries Time expired since last end of billing period Local time Local date Reserved Reserved Week day (0..7) Time of last reset Date of last reset Output pulse duration Clock synchronization window Clock synchronization method Coefficients Transformer magnetic losses Transformer thermal losses Line resistance losses Line reactance losses Measurement methods Algorithm for active power measurement Algorithm for active energy measurement Algorithm for reactive power measurement Algorithm for reactive energy measurement Algorithm for apparent power measurement Algorithm for apparent energy measurement Algorithm for power factor calculation
OBIS-code A B C 1 x 0 1 x 0 1 x 0 1 x 0 1 x 0 1 x 0 1 x 0 1 x 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
D 4 4 4 4 4 4 4 4 6 6 6 6 6 7 7 7 8 8 8 8 8 8 8 9 9 9 9 9 9 9 9 9 9 9 10 10 10 10
E 0 1 2 3 4 5 6 7 0 1 2 3 4 0 1 2 0 1 2 3 4 5 6 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3
F
a
V-y a V-y a V-y a V-y a V-y a V-y
V-y
V-y a V-y a V-y V-y a V-y a V-y

a
V-y a V-y a V-y a V-y
1 1 1 1 1 1 1
x x x x x x x
0 0 0 0 0 0 0
11 11 11 11 11 11 11
1 2 3 4 5 6 7
EXCERPT
DLMS UA 1000-1 ed.4 40/43
Electricity related General purpose objects

a
OBIS-code A B C
y can be set at any value between 1 and n ; for current values group F is not used. b If a transformer ratio is expressed as a fraction the ratio is numerator, divided by denominator. If the transformer ratio is expressed by an integer or real figure, only the numerator is used. REMARK If the value field F is shaded, then value group F is not used.
It has to be observed, that some of the codes above are normally not used, as the related data items are covered by attributes of already defined objects (application dependent). See Clause 4 or IEC 62056-62.
5.4.9 List objects

Lists identified with one single OBIS code are defined as a series of any kind of data (e.g. measurement value, constants, status, events). Table 16 General list objects
General list objects Data of billing period
a
OBIS code A 0 B x C 98 D 1 E x F a VZ
see 5.5.3
5.4.10 Electricity data profile objects

Data profiles identified with one single OBIS code are defined as a series of measurement values of the same type or of groups of the same kind consisting of a number of different measurement values. Table 17 Profile codes (electricity)
Electricity data profile objects Load profile with recording period 1 Load profile with recording period 2 Load profile during test Dips voltage profile Swells voltage profile Cuts voltage profile Voltage harmonic profile Current harmonic profile Voltage unbalance profile Event log Certification data log
a
OBIS-code A B C 1 X 99 1 X 99 1 X 99 1 X 99 1 X 99 1 X 99 1 X 99 1 X 99 1 X 99 1 1 x x 99 99
D 1 2 3 10 10 10 11 12 13 98 99
E a x a x 0 1 2 3 th n th n 0 x a x
a
0 0 0 0 0 0
If only one object of each kind is instantiated, the value shall be 0
5.5 Code presentation

Depending on the environment used the presentation of codes can be slightly different.
EXCERPT
DLMS UA 1000-1 ed.4 41/43
5.5.1 Reduced ID codes (e.g. for IEC 62056-21)

To comply with the syntax defined for protocol modes A to D of IEC 62056-21, the range of ID codes is reduced to fulfil the limitations which are usually applied to the number of digits and the ASCII representation of them. All value groups are limited to a range of 0 .. 99 and within that to the limits given in the relevant chapters. Some value groups may be suppressed, if they are not relevant to an application: Optional value groups: A,B,E,F Mandatory value groups: C,D To allow the interpretation of shortened codes delimiters are inserted between all value groups:
Figure 11 Reduced ID code presentation The delimiter between value groups E and F can be modified to carry some information about the source of a reset (& instead of * if the reset was performed manually). For compatibility with existing implementations, in value group A an identifier for an energy type may be used even for abstract objects.
5.5.2 Display
The usage of OBIS codes to display values is normally limited in a similar way as for data transfer, e.g. according to IEC 62056-21. Some codes may be replaced by letters to indicate clearly the differences from other data items: Table 18 Example of display code replacement
Value group C OBIS code Display code 96 C 97 F 98 L 99 P
5.5.3 Special handling of value group F

Identifying values from previous billing periods uses the group F field to indicate the actual time periods/point. Table 19 Values of billing periods
Value group F Future period Period 1 Period 2 Period 3 Period 4
VZ+1 VZ VZ-1 VZ-2 VZ-3 DLMS User Association
EXCERPT
DLMS UA 1000-1 ed.4 42/43
Value group F VZ-4 etc. 101 102 . 125 126 ...
Most recent value Two most recent values 25 most recent values unspecified number of most recent values
The value of the most recent (youngest) billing period is identified using the ID-code VZ (state of the billing period counter), and the second youngest is identified by the code VZ-1 etc. The operating mode of the billing period counter can differ, e.g. modulo-12 or modulo-100. The value that is represented after reaching the limit of the billing period counter, contains the billing period value code 0 for modulo-100, and 1 for other (e.g. modulo-12). Values above 100 allow to identify profiles which contain values of more than one billing period. The maximum allowed value for this is 125. The value 126 identifies a profile with values of an unspecified number of billing periods. For thresholds the value group F contains a reference into several threshold levels for the same quantity (if applicable).
5.5.4 COSEM
The usage of OBIS codes in the COSEM environment is defined in Clause 4 or IEC 62056-62.
EXCERPT
DLMS UA 1000-1 ed.4 43/43

Excerpt BB4 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Excerpt BB4 PDF

Uploaded by

Copyright:

Available Formats

EXCERPT FROM Companion Specification for Energy Metering

COSEM Identification System and Interface Objects

DLMS User Association

EXCERPT FROM DLMS UA 1000-1:2001, Fourth Edition

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

COSEM Interface Objects

Register Attribute(s) 1. logical_name 2. value 3. scaler-unit Method(s) 1. reset

Protocol Services to access attributes and methods 2. Messaging

Messages : Service_Id( Class_Id, Instance_Id, Attribute_Id/Method_Id ) Encoding: ( APDU ) C0 01 00 03 01 01 01 08 00 FF 02

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

3.1 Referenced Documents

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

3.2 Terms, Definitions and Abbreviations

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

4. COSEM Interface Classes

4.1 Basic Principles

Total Positive Active Energy: Register logical_name = [1 1 1 8 0] value= 1483

reset Total Positive Reactive Energy: Register logical_name = [1 1 3 8 0] value = 57

Figure 2 An interface class and its instances

DLMS User Association

DLMS UA 1000-1 ed.4

Copyright 1997-2001 DLMS User Association

4.1.2 Class Description Notation

Each attribute and method must be described in detail.

DLMS User Association

DLMS UA 1000-1 ed.4 10/43

Copyright 1997-2001 DLMS User Association

Data Type Min.

4.1.3 Common Data Types

DLMS UA 1000-1 ed.4 11/43

Copyright 1997-2001 DLMS User Association

real32, real64 visible-string, octet-string

Complex data types array compact array structure

4.1.4 Data formats for date and time notation

DLMS User Association

DLMS UA 1000-1 ed.4 12/43

Copyright 1997-2001 DLMS User Association

DLMS User Association

DLMS UA 1000-1 ed.4 13/43

Copyright 1997-2001 DLMS User Association

4.1.5 The COSEM server model

COSEM COSEM COSEM Objects

Combined metering device

LDN Register Total Volume A

LDN Register Total Volume

Figure 4 Combined metering device

7246060 s 246060 s 6060 s 60 s s rad*180/ K-273.15

m m/s 3 m 3 m 3 m /(6060s) 3 m /(6060s) 3 m /(246060s) 3 m /(246060s) -3 3 10 m kg N J = Nm = Ws 2 N/m -5 2 10 N/m J = Nm = Ws J/(60*60s) W = J/s

W(6060s) VA(6060s) var(6060s) A C = As V V/m C/V = As/V = V/A m Wb = Vs 2 Wb/m

V (6060s) 2 A (6060s) kg/s 1/