Sie sind auf Seite 1von 51

EXCERPT FROM Companion Specification for Energy Metering

COSEM Interface Objects

DLMS User Association

device language message specification

Reference number:

EXCERPT FROM DLMS UA 1000-1:1999, Second Edition


Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

2/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

Table of Contents
1. 2. 3. 3.1 3.2 4. 4.1.1 4.1.2 4.2 4.2.1 4.2.2 4.2.3 4.2.4 5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 6. 6.1 6.2 6.3 7. 7.1 7.1.1 7.1.2 7.2 7.2.1 7.2.2 7.3 7.3.1 7.3.2 Foreword...............................................................................................................5 Scope ....................................................................................................................6 Introduction ..........................................................................................................7 Referenced Documents .........................................................................................7 Terms, Definitions and Abbreviations ....................................................................7 Basic Principles ...................................................................................................9 Class Description Notation ...............................................................................10 Common Data Types........................................................................................12 Communications with COSEM Interface Objects .................................................12 Interoperability in COSEM ................................................................................12 COSEM Applications and Communication Protocols........................................13 The COSEM Server Model ...............................................................................15 The Association View of the Logical Device...................................................16 The Interface Classes ........................................................................................18 Data (Class_id: 1) ................................................................................................19 Register (Class_id: 3) ..........................................................................................20 Extended Register (Class_id: 4) ..........................................................................23 Demand Register (Class_id: 5) ............................................................................23 Register Activation (Class_id: 6) ..........................................................................24 Profile Generic (Class_id: 7) ................................................................................24 Clock (Class_id: 8)...............................................................................................26 Script Table (Class_id: 9).....................................................................................28 Schedule (Class_id: 10).......................................................................................28 Special Days Table (Class_id: 11) .......................................................................28 Activity Calendar (Class_id: 20) ...........................................................................29 Association LN (Class_id: 15) ..............................................................................29 Association SN (Class_id: 12)..............................................................................29 SAP Assignment (Class_id: 17) ...........................................................................30 IEC 1107 Setup (Class_id: 19) ............................................................................30 Register Monitor (Class_id: 21)............................................................................31 Maintenance of the COSEM Interface Classes.................................................32 New Interface Classes .........................................................................................32 New versions of Interface Classes.......................................................................32 Removal of Interface Classes ..............................................................................32 Appendix A: Relation to DLMS ..........................................................................33 DLMS Compliance ...............................................................................................33 Extensions to DLMS for COSEM ......................................................................34 Encoding of DLMS pdus...................................................................................35 Referencing COSEM Objects ..............................................................................35 Referencing with Logical Names (LN) ..............................................................35 Referencing with Short Names (SN).................................................................36 Example of a meter..............................................................................................38 COSEM Objects within the Logical Device of the example...............................38 Communicating with the meter using LN referencing .......................................39

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

3/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition 7.3.3 8. 8.1 8.1.1 8.1.2 8.2 Communicating with the meter using SN referencing .......................................41 Appendix B: relation to OBIS ............................................................................44 Mapping of data items to COSEM objects and attributes.....................................44 Abstract objects ................................................................................................44 Electrical energy related objects .......................................................................48 Coding of OBIS identifications .............................................................................50

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

4/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

1. Foreword
Copyright: Copyright 1997-1999 DLMS User Association.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

5/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

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: Step1: The meter model and data identification; Step2: The mapping of the model into protocol data units (pdu); Step3: The transportation of the bits and bytes through the communication channel.

1. Modelling
n io at i oc 0..n class_id=3, version=0ss A Data Type Min rMax Def e octetstring s U Instance Specific S scal_unit_type M DL

Register
Attribute(s) logical_name current_value scaler-unit Specific Service(s) reset ()
(static) (dyn.) (static)

m/o m

2. Mapping
ReadRequest::=SEQUENCE OF ([2] object-name)

pdu:

05 01 02 06 48

3. Transport
O IS

SI /O

Figure 1: The three steps approach of COSEM: Modelling of the functionality Mapping to bits and bytes Transporting via a specific channel using the appropriate protocol. The contents of this document (DLMS UA 1000-1) concentrate on step 1. It references [3] for data identification purposes. Step 2 is covered in the appendix. Step 3 is treated in [4].

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

6/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

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) considers 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 business objects forms a major part of COSEM. The COSEM server model 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 attributes of its elements and the measured data. The set of different classes 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 applications (from residential to commercial and industrial metering) can be covered. The choice of the subset of objects 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 object library provides the different users and manufacturers with a maximum of diversity without having to sacrifice interoperability.

3.1 Referenced Documents


Ref. [1] [2] [3] [4] Title Distributed Automation Using Distribution Line Carrier Systems Part 4: Data Communication Protocols; Section 4: Application Protocol; Clause 1: Distribution Line Message Specification (DLMS), IEC 1334-4-41, 1996-03 A-XDR Encoding Rule, IEC 61334-6, CDV 1998-07 Object Identification System (OBIS), "Orange Book", DLMS UA 1000-3 COSEM Communication Profile, "Green Book", DLMS UA 1000-2

3.2 Terms, Definitions and Abbreviations


Abbreviation ACSE A-XDR base_name Class_id COSEM DLMS GMT HLS IC IEC Explanation Application Control Service Element Adapted Extended Data Representation (comp. [2]) The short_name corresponding to the first attribute (logical_name)of a COSEM object.. Class identification code Companion Specification for Energy Metering Distribution Line Message Specification, IEC1334, comp.[1] . Greenwich Mean Time High Level Security Interface Class International Electrotechnical Commission

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

7/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
LLS LSB m MSB o OBIS UTC 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, comp. [3]. Universal Time Co-ordinated

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

8/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

4. Basic Principles
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 (comp 4.2.1). 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 a class with a class_id. Within a specific class the common characteristics (attributes and methods) are described once for all objects. Instantiations of a class are called objects. Figure 2 illustrates these terms by means of an example:

Class

Methods Object class identifier Attributes Instantiation

Attribute Values

Register class_id=3 logical_name: octetstring value: instance specific ...

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

reset (data,...) Total Positive Reactive Energy: Register logical_name = [1 1 3 8 0] value = 57

Figure 2: A class and the instantiation of objects The 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 (comp [3]). 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

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

9/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Figure 2 the meter contains 2 registers; i.e. two specific objects of the class register are instantiated. This means that specific values are assigned to the different attributes. Through the instantiation one register becomes a positive, active energy register whereas the other becomes a nergy register.

Remark: The objects represent the behaviour of the meter as seen from the outside (interface classes). 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.1 Class Description Notation


This section describes the notation used to define the COSEM 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:
Class name Attribute(s) 1. logical_name 2. .. 3. Specific Method(s) (if required) 1. 2. ..
(static) (..) (..)

Cardinality Data Type octet-string .. .. m/o .. ..

Class_id , Version Min Max Def

Table 1: Class description template Each attribute and method must be described in detail. Describes the class (e.g. Register, Clock, Profile, ...) Class name Cardinality Specifies the number of instances of the class within a logical device (comp 4.2.3). val The class shall be exactly val times instantiated. 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 65535). The class_id is provided by methods of an Association object. The class_id's from 0 to 8191 are reserved to be specified by the DLMS UA. Class_id's from 8192 to 32767 are reserved for manufacturer specific interface classes. Class_id's from 32768 to 65535 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 is provided by methods of an Association object. Within one logical device all instances of a certain class must conform to the same version. Specifies the attribute(s) that belong to the class. min..max

Class_id

Version

Attribute(s)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

10/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition (dyn.) Classifies an attribute that carries a process value which is updated by the meter itself. (static) 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 (object) of this class. The value of the logical_name conforms to OBIS (comp [3]). Defines the data type of an attribute (comp. 4.1.2). Specifies if the attribute has a minimum value. x <empty> Max The attribute has a minimum value. The attribute has no minimal value.

logical_name

Data Type Min

Defines if the attribute has a maximum value. x <empty> The attribute has a maximum value. The attribute has no maximum value.

Def

Specifies if the attribute has a default value. This is the value of the attribute after reset. x The attribute has a default value <empty> The default value is not defined by the class definition .

Specific Method(s)

m/o

Provides a list of the specific methods (beside those declared in the conformance block comp Error! Reference source not found.) 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. m (mandatory) o (optional) The method is mandatory .The method is 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 object(s). Note: Services for accessing attributes or methods ( READ/WRITE or GET/SET, ACTION, as defined in the conformance block, comp Error! Reference source not found. ) are considered to be pre-defined. Therefore they are not included here.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

11/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition 4.1.1.1 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.2 Common Data Types

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

4.2 Communications with COSEM Interface Objects


This chapter gives an overview of the COSEM communications model. A more detailed description can be found in [4].

4.2.1 Interoperability in COSEM


COSEM communication is based on the client/server paradigm in a connection oriented environment (comp. Figure 3). The communication takes place between a client and a server1 application, where the COSEM device (meter) plays the role of the server. The client and the server applications first must establish a connection. This application level connection is called Application Association.
Client Application Server Application (COSEM device) Service.Request Service.Response

Figure 3 The Client/Server communication model

As server, the COSEM device provides services upon the requests of the client. The server does not initiate any communication it just responds to the requests of the client. The only exception to this rule is the InformationReport / EventNotification service, which is initiated by the server. A complete communications session consists of three phases as illustrated in Figure 4.

Multicast and Broadcast transmission from one Client towards multiple Servers are also allowed

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

12/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Client Application Phase 1. Connection Establishment Phase 2. Data Communication t Phase 3. Connection Release Server Application

Figure 4 A communications session in the connection oriented environment During the first - connection establishment - phase, the two participants mutually identify/authenticate themselves. In addition, they also negotiate the application context for phase 2. Negotiable elements of this context are: available services, used references to COSEM objects, etc If the connection phase terminates successfully, the client and the server can exchange messages during phase 2, following the rules established during the connection phase. If the connection establishment fails, no communication is possible between these two applications. At the end of the communication session the connection is released during phase 3. For COSEM compliant devices operating in the environment described above, interoperability is defined as follows: All interoperable COSEM devices use the same standard protocol during the connection establishment phase (phase 1, Figure 4). This protocol is specified in [4].
Note:

The concept described above allows COSEM compliant devices to use different application contexts during the data communication phase (phase 2, Figure 4). Interoperability is guaranteed by the ability of the device to establish this context in a standardised way.

4.2.2 COSEM Applications and Communication Protocols


When the Application Association is successfully established, the client and server applications exchange messages using the COSEM communications protocol.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

13/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Client Application Service.Request Service.Response Service.Request Protocol e.g.PST Service.Response Protocol Server Application

Figure 5 The COSEM communications model, including the protocol The purpose of the protocol is to carry the Service Request/Response messages between the Client and Server applications as illustrated in Figure 5. A message consists of an identifier of the required service, and an identifier of the element to which the service is applied. However, in COSEM only the COSEM Interface Objects are visible from the external world (from the client), thus the only valid elements that can be referenced in a service are COSEM Objects their attributes and/or their methods. The complete COSEM communications model is shown in Figure 6.
COSEM Client COSEM Objects Service.Request Client Application Service.Response Service.Request Protocol Server Application Service.Response Protocol e.g. PSTN COSEM Server Real Objects

Figure 6 The complete COSEM communications model Objects of a metering application (e.g. Total Energy Consumption) are modelled for communication purposes as COSEM Interface Objects (e.g. as a Register object). The client never sees the real objects. Only a server application (comp. Figure 6) knows the relation between the COSEM Interface Objects and the real objects. Once the Application Association is established, the COSEM client may issue requests referencing COSEM objects. These requests may be attribute specific (e.g.: read an attribute of a COSEM object) or method specific (e.g. capture a pre-defined set of data). The server application, in receiving the request, checks whether the service can be provided or not (validity, client access right, availability, etc), and, if everything is O.K., locally applies the required service on the cor-

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

14/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition responding real object. If the service demands a response (e.g. if the required service is a read of an attribute), the server application will generate the appropriate Service.Response message. The generic message structure is as follows: Service Identifier ( COSEM Object Attribute/Method Identifier, [ Data ] ) Attributes and methods of COSEM objects can be referenced in different ways: 1. 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 ; And the reference for a method: 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. Service Identifiers are as follows: GET(Request/Response), SET(Request/Response), EventNotification(Request/Response), ACTION(Request/Response) The GET.Request service with this type of referencing is: GET.Request( xxx, yyy, zzz ) Where xxx is the Class_id of the referenced object, yyy is the value of the logical_name attribute of the referenced object, and zzz is the attribute_index of the requested attribute (comp. 7.2.1). 2. Using short names: This kind of referencing is intended to be used for simple devices. In this case each attribute and method of a COSEM object is identified with a 13 bits integer, as it would be the name of the DLMS Named Variable object. In this case the Service Identifier will reference one of the following DLMS services: 3. READ(Request/Response), WRITE(Request/Response), UnconfirmedWRITE(Request), InformationReport(Response) A READ.Request service with this type of referencing is: READ.Request( yyy ), where yyy represents the named variable corresponding to the short name (comp. 7.2.2).

4.2.3 The COSEM Server Model


The COSEM server is structured into 3 hierarchical levels as shown in Figure 7: Level 1: Physical Device
DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

15/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Level 2. Level 3: Logical Device Accessible COSEM Interface Objects

COSEM Physical Device A

COSEM Logical Device 2 COSEM Logical Device 1 COSEM Objects COSEM Objects

Figure 7: The COSEM server model The following example (comp Figure 8) shows how a combined metering device can be structured using the COSEM server model. Physical Device Combined Metering Device

Logical Device

Electricity Meter A Register Total Energy Register Tariff

Gas Meter

Water Meter

Objects

Register Total Volume A

Register Total Volume

A: Association object Figure 8: Combined metering device

4.2.4 The Association View of the Logical Device


In order to access interface objects in the server, an application association must be first established as described in 4.2.1. This characterises the context within which the associated applications will communicate. The major parts of this context are:

Location information Information on the application context Information on the COSEM (DLMS) context Information on the used authentication mechanism etc.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

16/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition This information is contained in a special COSEM Interface 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 established association between the client and the server different access rights may be granted by the server. Access rights concern a set of COSEM Interface Objects the Visible Objects which can be accessed (seen) within the given association. In addition, access to attributes and methods of these objects may also be restricted within the association (e.g. a certain type of clients can only read a particular attribute of an object). The list of the visible objects the Association View - can be obtained by the client in reading object_list attribute of the appropriate Association object. Additional information about the access rights (Read, Write, Read/Write) to the attributes and the availability of the methods (under the established association) can be found via specific methods provided by the Association objects (comp. 5.12).

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

17/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5. The Interface Classes


The currently defined interface classes for meters and the relations between them are illustrated in Figure 9. Notes: 1. The COSEM Interface Class Base itself is not specified explicitly. It contains only one attribute "logical_name". 2. 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

Figure 9: Overview of the COSEM Interface Classes

IEC 1107 Setup Activity Calendar Register Monitor Special Days Table

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

18/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5.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) Attribute Description logical_name Identifies the data contained in value. Identifiers are specified in chapter 8.1. Contains the data. instance specific
(static)

0..n Data Type octet-string instance specific m/o

Class_id=1, Version=0 Min Max Def

value

The data type of the value depends on the instantiation defined by logical_name.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

19/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5.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 (comp chapter 8.1).
Register Attribute(s) 1. logical_name 2. value 3. scaler-unit Specific Method(s) 1. reset
(static) (dyn.) (static)

0..n Data Type octet-string instance specific scal_unit_type m/o o

Class_id=3, Version=0 Min Max Def

Attribute Description value Contains the current process or status value. instance specific 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 (according to DLMS data description). The type has to be chosen such that, together with the logical_name, a unambiguous interpretation of the value is possible. provides information on the unit and the scaler of the value scal_unit_type: structure { scaler, unit } 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=0 shall be used. unit: enum enumeration defining the physical unit; details see below

scaler-unit

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]

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

20/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
unit ::= ENUMERATED ( yr mo wk d h min s oC amount m m/s m3 m3N m3/h m3N/h m3/d m3N/d L kg N Nm Pa bar J J/h W VA Var Wh VAh Varh A C V V/m F rho Wb T A/m H Hz Rac Rre Rap V2h A2h (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), (42), (43), (44), (45), (46), (47), (48) (49) -----------------------------------------------year month week day hour minute second phase angle (degree) temperature (degree centigrade) local currency meter speed volume volume after correction factor volume per hour corrected volume per hour volume per day corrected volume per day liter (10-3 m3) kilogram Newton Newtonmeter Pascal (1 N/m2) bar (105 N/m2) Joule (1 Nm, 1 Ws) Thermal power Watt (power) apparent power reactive power active energy apparent energy reactive energy Current electrical charge (As) Volt electrical field strength Capacity (As/V) Resistance (Ohm) specific resistance (mm2/m) Flux (1 Vs) Induction (1 Wb/m2) magnetic field strength Inductivity (Wb/A) Frequency (1/s) active energy meter constant (imp/kWh) reactive energy meter constant (imp/kvarh) apparent energy meter constant (imp/kVAh)

ou nu )

(254), (255)

-- other unit -- no unit

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

21/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
examples of values : value 263788 593 3467 Scaler -3 3 0 unit m3 Wh V Value 263,788 m3 593 kWh 3467 V

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

22/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5.3 Extended Register (Class_id: 4)


An Extended Register object stores 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 follows ...


(comp. DLMS UA 1000-1, Second Edition)

5.4 Demand Register (Class_id: 5)


A Demand Register object stores a power value with its associated status, unit, and time information. The demand register measures and computes its current_value periodically. Each new measuring period is triggered externally (to the object2) by using the next_period () method. The time interval T over which the power is measured or computed is defined by specifying number_of_periods and period. T = number_of_periods * period N 2 period t start_time capture_time now 1 T is the time interval used for calculation of the current_value of a sliding demand register

Figure 10: The attributes when measuring sliding demand The demand register delivers two types of demand: the current_average_value and the last_average_value. (comp Error! Reference source not found.and Error! Reference source not found.) The demand register knows its type of process value which is described in logical name" using the OBIS identification system.

the object itself does not provide the triggering mechanism

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

23/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition energy/period period current-average_value 0 start_time now start_time+period t

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

5.5 Register Activation (Class_id: 6)


The Register Activation object 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 which are not part of the active_mask are disabled. All register objects not defined in any register_assignment are enabled by default.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

5.6 Profile Generic (Class_id: 7)


The profile object 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 register or clock and a value range, or an entry range may be specified, asking to retrieve all entries whose values or entry number lie within the given range. The capture objects whose values have to be retained (with method capture) are specified by assigning the corresponding objects to the profile. 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 power register with a one entry deep sorted profile capturing and sorted by a power register. It is just as simple to define a profile retaining the three largest values of some period. The size of profile data is determined by three parameters: 1. The number of filled entries. This will be zero after clearing the profile.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

24/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
2. The maximum number of entries to retain. If all entries are filled and a capture () request oc-

curs, the least important entry (according to the requested sorting method) will get lost. This maximum number of entries may be specified. Upon changing it, the buffer will adjusted. 3. The physical limit for the buffer. This limit typically depends on the objects to capture. The object will reject an attempt of setting the maximum number of entries that is larger than physically possible. ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

25/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5.7 Clock (Class_id: 8)


The Clock object handles all information that is related to date and time, including leap years and the deviation from the local time to a generalised time reference which may be the Greenwich Mean Time (GMT), the Universal Time Co-ordinated UTC or another Generalised Time Reference. The deviation from the local time to the generalised time reference can change depending on the season (e.g. summer time vs. winter time). The interface to an external client is based on date information specified in day, month and year, time information given in 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 in the UTC 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 11: 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 Attribute Description time DLMS User Association
(static) (dyn.) (static) (dyn.) (static) (static) (static) (static) (static)

0..1 Data Type octet-string UTC long clock_status UTC UTC integer boolean enum m/o o o o o o o

Class_id=8, Version=0 Min Max Def

Contains the meters local time, its deviation to GMT and the

EXCERPT

DLMS UA 1000-1 ed.2

26/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
status. See also the description in 4.1.2. If this value is set, only specified fields of the UTC are changed. For example for setting the date without changing the time, all time relevant octets of the UTC must be set to not specified. The clock_status must always be set when writing the time. UTC time_zone .

The deviation of local, normal time to GMT in minutes. long

status

The status is equal to the status read in time. See also the description in 4.1.2. clock_status

daylight_savings_begin

Defines the local switch date and time when the local time has to be deviated from the normal time. For the algorithm this attribute contains the month, first possible day of month, the day of week and the switch time. With this information its possible to calculate the switch point for every year from the point of time this attribute was set. UTC

daylight_savings_end

See above. UTC

daylight_savings_deviation

Contains the number of minutes the deviation in generalised time must be corrected at daylight savings begin. integer Deviation range of about 2 hours

daylight_savings_enabled

TRUE enables daylight savings function. boolean

clock_base

defines where the basic timing information comes from enum 0: not defined, 1: internal crystal, 2: mains frequency 50 Hz, 3: mains frequency 60 Hz, 4: GPS (global positioning system), 5: DCF 77 (Braunschweig time standard).

Method Description adjust_time (data) Sets the meters time to the nearest (+/-) quarter of an hour value (*:00, *.15, *30, *45). data ::= adjust_to_measuring_period (data) integer (0).

Sets the meters time to the nearest (+/-) starting point of a measuring period. data ::= integer (0).

adjust_to_minute (data)

Sets the meters time to the nearest minute. If second_counter < 30s, so second_counter is set to 0. If second_counter 30s, so second_counter is set to 0 and minute_counter and all depending clock values are incremented if necessary.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

27/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
data ::= adjust_to_preset_time (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)

preset_adjusting_time (data)

Presets the time to a new value (preset_time) and defines a validity_interval within which the new time can be activated. data ::= structure { preset_time: UTC; validity_ interval_start: UTC; validity_interval_end: UTC }

shift_time (data)

Shifts the time by n (-900 <= n <= 900) seconds. data ::= long

5.8 Script Table (Class_id: 9)


The IC Script table provides the possibility to trigger a series of actions by issuing an execution 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 an object or modifies attributes of an object within the logical device. A specific script may be activated by other objects within the same logical device or from the outside. For broadcasting purposes, the instantiation of a broadcast-receiver script table is foreseen.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

5.9 Schedule (Class_id: 10)


The IC Schedule together with the IC Special Days Table handles time and date driven activities within a device. ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

5.10 Special Days Table (Class_id: 11)


The class allows to define dates, which will override normal switching behaviour for special days. The class works in conjunction with the class "Schedule" or "Activity calendar" and the linking data item is day_id.
DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

28/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

5.11 Activity Calendar (Class_id: 20)


The Activity Calendar object 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 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. The Activity Calendar defines the activation of certain scripts, which can perform different activities inside the meter. The interface to the object Script is the same as for the object Schedule. (comp 5.9) The Activity Calendar allows references between special days (comp 5.10) and day-profiles. ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

5.12 Association LN (Class_id: 15)


COSEM Logical Devices which are able to establish application associations within a COSEM context using Logical Name references, model the associations instances of the Association LN object. A COSEM Logical Device has as many instances of that object as many associations the device is able to support.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

5.13 Association SN (Class_id: 12)


The Association SN interface class provides information which is specific to the logical_device under the current client-server association. The Association SN object is used only if the established association uses short name references. The short_name of the Association SN object itself is fixed within the COSEM context. It is given in 7.2.2.2 as .0xFA00 ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

29/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

5.14 SAP Assignment (Class_id: 17)


The SAP Assignment interface class contains the information on the assignment of the logical devices to their Service Access Points (SAP) (comp [4]) ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

5.15 IEC 1107 Setup (Class_id: 19)


IEC1107Setup Attribute(s) 1. logical_name 2. default_mode 3. default_baud 4. prop_baud 5. response_time 6. device_addr 7. pass_p1 8. pass_p2 9. pass_w5 Specific Method(s) Attribute Description default_mode
(static) (static) (static) (static) (static) (static) (static) (static) (static)

0..n Data Type

Class_id=19, Version=0 Min Max Def

octet-string
enum enum enum enum octet-string octet-string octet-string octet-string m/o

Defines the protocol proposed by the meter according to IEC 62056-21 (3rd release of old IEC 61107) enum 0 IEC (7bit, even) 1 HDLC (8bit, none) Defines the baud rate for the opening sequence enum (0) 300 baud (1) 600 baud (2) 1200 baud (3) 2400 baud (4) 4800 baud (5) 9600 baud (6) 19200 baud (7) 38400 baud (8) 57600 baud (9) 115200 baud Defines the baud rate to be proposed by the meter enum (0) 300 baud (1) 600 baud (2) 1200 baud (3) 2400 baud (4) 4800 baud (5) 9600 baud (6) 19200 baud (7) 38400 baud (8) 57600 baud (9) 115200 baud Defines the minimum time between the reception of a request and the transmission of the response enum (0) 20 msec (1) 200 msec

default_baud

prop_baud

response_time

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

30/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
device_addr pass_p1 pass_p2 pass_w5 IEC device address octet-string Password 1 according to IEC octet-string Password 2 according to IEC octet-string Password W5 according to VDEW needs for load profile reading octet-string

5.16 Register Monitor (Class_id: 21)


This interface class allows to define a set of scripts (comp 5.8 ) that are executed when an attribute of a monitored register type object (Data, Register, Extended Register, Demand Register, etc.) is crossing a set of threshold values. The IC Register Monitor requires an instantiation of the IC Script in the same logical device.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

31/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

6. Maintenance of the COSEM Interface Classes


Any modification of interface classes as described below in chapter 6.2 will be recorded by moving the old or obsolete version of a interface class into chapter Error! Reference source not found.

6.1 New Interface Classes


The DLMS UA reserves the right to be the exclusive administrator of Interface classes.

6.2 New versions of Interface Classes


Any modification of an existing interface class results in a new version (version:=version+1) and must be documented accordingly. The following rules must be followed: 1. 2. 3. 4. New attributes and methods may be added. Existing attributes and methods may be invalidated BUT the indices of the invalidated attributes and methods must not be re-used by other attributes and methods. If these rules cannot be met , then a new interface class must be created. New versions of COSEM interface classes are administrated by the DLMS UA

6.3 Removal of Interface Classes


Besides one association object no instantiation of an interface class is mandatory within a meter. Therefore even unused classes will not be removed from the standard. They will be kept to ensure compatibility with possibly existing implementations.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

32/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

7. Appendix A: Relation to DLMS


The main objective of the COSEM approach is to provide a business domain oriented interface object model for metering devices and systems. The second objective is to keep backward compatibility to the existing DLMS standard [1]. The result is that the COSEM approach is an evolution to DLMS. Remaining completely compliant to the DLMS standard, COSEM provides a more metering specific view through the COSEM interface objects.

7.1 DLMS Compliance


A DLMS communications session starts with the association establishment (comp. Figure 4, phase 1). The association is always initiated by the Client. The used DLMS services are negotiated between the Client and the Server with the help of the DLMS Initiate service during the association establishment. The corresponding message sequence (without authentication) is as follows:
3 Client Application AARQ (including DLMS Initiate.request)

Server Application

AARE4 (including DLMS Initiate.response) t

Figure 12 Association establishment with the DLMS Initiate service If the association response is positive, the application association is established within a given application and DLMS context. The latter is negotiated with the standard DLMS Initiate service. For application association establishment, COSEM is also using the standard DLMS Initiate services by incorporating them into the AARQ/AARE services of the standard (ITU) ACSE as shown in Figure 12. In addition, COSEM specifies a new conformance block extending the number of available DLMS services (comp. Error! Reference source not found.).

AARQ = Application Association Request. This a-pdu is sent by the standard ACSE following a COSEMOpen.Request service invocation at the Client side. AARE = Application Association Response. This a-pdu is sent by the standard ACSE following a COSEMOpen.Response service invocation at the Server side.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

33/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Implementation domain (real) objects

Server Application COSEM Logical Device VAA


Named Variables
Other DLMS Objects COSEM IInterface Objects

VDE

Association

Incoming Association Request


DLMS edition 1 extended DLMS (edition 2)

Figure 13 The COSEM extension to DLMS The role of DLMS in the COSEM environment is illustrated in Figure 13. Real metering objects can be modelled for the communication purpose in the traditional DLMS (edition 1) way as Named Variables or other DLMS objects (comp. [1]), or as COSEM Interface objects, specified in this document. Depending on the contents of the incoming Association Request message which follows the same syntactical and semantical rules in both cases the association application is established either with the VDE or with the COSEM Logical Device interface object. The established association is then modelled either by the VAA or by the Association interface object, respectively. Once the association is established, the information exchange between the Client and the Server applications follows the rules, corresponding to the established association. The services which can be invoked by the Client are the services which have been negotiated during the association establishment phase.

7.1.1 Extensions to DLMS for COSEM


The following extensions to the DLMS standard [1] are necessary in the COSEM environment. They define added functionality; i.e. the existing functionality is not modified. The extensions are made such that there is no conflict with existing DLMS (edition 1) implementations which do not provide these extensions. The extensions are being included in the second edition of the DLMS standard.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

34/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

... more follows ...


(comp. DLMS UA 1000-1, Second Edition)

7.1.2 Encoding of DLMS pdus


DLMS pdus - as all A pdus in COSEM - shall be encoded using A-XDR (comp. [2]).

7.2 Referencing COSEM Objects


In the COSEM environment the attributes and methods of the COSEM Objects can be referenced in two different ways: via logical names via short names

7.2.1 Referencing with Logical Names (LN)


The following, newly added DLMS services are using logical name references to COSEM Objects: - GET Request/Response - SET Request/Response - EVENT NOTIFICATION Request - ACTION Request/Response In order to use this type of referencing it must be ensured that the association with the COSEM Logical Device is within a COSEM context supporting these services. The information on supported services is carried by the Conformance Block (comp. Error! Reference source not found.) of the Initiate service. When these services are supported, the application association is modelled by the COSEM object Association LN (comp 5.12). These four services can be classified as follows: Attribute oriented services Invoked by the Client

GET.Request SET.Request GET.Response SET.Response EVENT NOTIFICATION.Request ACTION.Request ACTION.Response

Invoked by the Server

Method oriented services Invoked by the Client Invoked by the Server:

Attribute oriented services contain a reference to the attribute of a COSEM Interface object instance (which attribute to SET or to GET), and the method oriented ACTION services contain a reference to a method of a COSEM Interface object instance. References to an attribute is as follows: COSEM_Interface_Object_Instance_Identifier, Attribute_Identifier COSEM_Interface_Object_Instance_Identifier, Method_Identifier

References to a method is as follows:


DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

35/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition The COSEM_Interface_Object_Instance_Identifier shall identify unambiguously a COSEM Interface Object Instance. Hence a COSEM Interface Object Instance is identified unambiguously by its Class_Id and by the value of its Logical name attribute., the services described above use these two parameters as COSEM_Interface_Object_Instance_Identifiers. Considering the fact that the Logical name attribute contains the Identifier of a object instance and that the attributes and the methods can be referenced by their indices, the following references are obtained: References to an attribute: COSEM Class_Id, logical_name, Attribute_Index COSEM Class_Id, logical_name, Method_Index

References to a method:

Indexes for attributes and methods are signed, one byte integers: positive values point on publicand negative values point on proprietary attributes/methods. The first public attribute has index 1 and index 0 is reserved to reference ALL attributes. A GET.Request for the value attribute of a COSEM Register type object instance with the Logical name of 0x010101080000 could be as follows: GET.Request( 3, 0x010101080000, 2) Where 3 is the Class_Id for the Register COSEM Interface Class, 0x01010108000 is the logical_name for that instance, and 2 is the attribute index for the value attribute.

7.2.2 Referencing with Short Names (SN)


The following DLMS services (comp. [1]) support SN references to COSEM Objects:
READ Request/Response WRITE Request/Response Unconfirmed WRITE Request

Information Report Request/Response In order to use this type of referencing it must be ensured that the association with the COSEM Logical Device is within a COSEM context supporting these services. The information on supported services is carried by the Conformance Block of the Initiate service. When these services are supported, the application association is modelled by the COSEM object Association SN (comp.5.12). The Association SN can be accessed via the base name 0x FA00 (comp. 7.2.2.2). In the SN referencing scheme the attributes and methods of the COSEM Interface Object instances are identified with a 16 (13) bits integer, similar to the value of the name attribute of the DLMS Named Variables (comp. [1] ,p. 51). Example (compare also 7.2.1): Assuming that the base name of the COSEM Register object instance (with the Logical name 0x010101080000) is 0x0000. Reading the contents of the attribute value (comp. 5.2) is achieved by calling the DLMS service: READ.Request ( 0x0008 ).

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

36/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

7.2.2.1 Guidelines for assigning Short Names ... more follows ...
(comp. DLMS UA 1000-1, Second Edition)

7.2.2.2 Reserved base_names for Special COSEM Objects In order to grant access for devices just 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. The following specific base_names are defined: base_name (ObCOSEM object jectName) Association SN 0x FA00 Script Table (instatiation: broad0x FB00 cast_receiver script) SAP Assignment 0x FC00 Register Object containing the CO0x FD00 SEM Logical Device Name in the attribute "value"

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

37/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

7.3 Example of a meter


7.3.1 COSEM Objects within the Logical Device of the example
The COSEM Logical Device in this example contains: One instance of the COSEM Association LN or COSEM Association SN Object type, depending on the established association. Two instances of the COSEM Register Object type (Register 1 and Register 2) One instance of the COSEM Clock Object type One instance of the COSEM Generic Profile Object type

These instances are specified as follows: Register 1 (positive, active energy) COSEM Register: class_id=3, version=0
Attribute n 1 2 Attribute name logical_name value Attribute Value 0x0101010800FF 1234 Comment OBIS code A=1,B=1,C=1,D=8,E=0 1.1.1.8.0.255 Instance specific: here integer16 This value is dynamically updated by the meter, the given value is for the example only. Integer Enumerated ( 30 = Wh, Active Energy )

3 Method n 1

scaler-unit

Scaler = 3 Unit = 30 Method Parameters

Method name reset

Register 2 (positive, reactive energy) COSEM Register: class_id=3, version=0


Attribute n 1 2 Attribute name logical_name value Attribute Value 0x0101030800FF 5678 Comment 1.1.3.8.0.255 Instance specific: here integer16 This value is dynamically updated by the meter, the given value is for the example only. Integer Enumerated ( 32 = Varh, Reactive Energy )

3 Method n 1

scaler-unit

Scaler = 3 Unit = 32 Method Parameters

Method name reset

Clock COSEM Clock: class_id=8, version=0


Attribute n Attribute name Attribute Value Comment

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

38/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
1 logical_name 0x0000010000FF The OBIS_Id for the Clock object 0.0.1.0.0.255

2 3 4 5 6 7 8 9 Method n 1 2 3 4 5 6

time time_zone status daylight_savings_begin daylight_savings_end daylight_savings_deviation daylight_savings_enabled clock_base Method name adjust_time adjust_to_measuring_period adjust_to_minute adjust_to_preset_time preset_adjusting_time shift_time

Method Parameters

Profile generic (set of billing values)


The Profile object is used to define a set of billing values which must be retrieved with an typical readout (e.g. via HHU or PSTN). With one read access to attribute 2 (buffer) the values and the scaler_units of the two registers are fetched.

COSEM Profile generic: class_id=7, version=2


Attribute n 1 Attribute name logical_name Attribute Value 0x0000670000FF Comment The OBIS_Id for the Profile object "IECreadout" 0.0.1.3.0.0.255

2 3

buffer capture_objects

{ { 0x0101010800FF, 3, 2}, { 0x0101010800FF, 3, 3}, { 0x0101030800FF, 3, 2}, { 0x0101030800FF, 3, 3}, }

4 5 6 7 8 Method n 1 2

capture_period sort_method sort_object entries_in_use profile_entries Method name reset capture

1 1 * 1 1 Method Parameters

7.3.2 Communicating with the meter using LN referencing


For the purpose of that example lets suppose that the application association between a Client and the Logical Device has been already established within an application context which supports Logical Name references to COSEM interface objects. The established association is modeled by an Association LN object instance, with the following attributes: logical_name:
5

0.0.100.0.1.2555

In this example we display only OBIS codes obviously for the transmission it is encoded to octets.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

39/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition object_list: associated_partners_id: application_context_name: COSEM_context_info: authentication_mechansim_name: authentication_value: LLS_secret: HLS secret: association_status list of visible objects client-SAP: 0x15 server-SAP: 0x1234 default COSEM Application context name descriptor of the established COSEM context no-authentication-security dont care dont care dont care associated

The object_list attribute contains the list of the visible objects inside this association, with the access rights to these objects, on attribute per attribute and method per method basis. For that example lets suppose that within this association : the visible object list includes both Register object instances and the only instance belonging to the Profile Generic class. the Clock object is not visible at all, all attributes of the Register instances can be only read, except of the value attribute of Register2. the reset() special service of the Register instances can not be invoked. both special service of the Profile instance can be invoked. 7.3.2.1 Retrieving the list of Register Class Objects of this COSEM Logical Device The Invoked service is a GET.Request service. The service invocation shall always contain the reference for the object_list attribute of the Association LN object instance. Here, in addition to that, the choice and the parameters for a selective GET are also included, because of the required operation is to get back only identifiers of Register class object.
GET.Request ( class_id logical_name attribute_id Tag for Service_Parameters

15, 0.0.100.0.1.255, 2, 2, 3 )

class-list The response primitive shall include the logical names of the Register Class instances which are visible within this association. This primitive shall be as follows: GET.Response( 2, 3, 1.1.1.8.0.255, 1.1.3.8.0.255 ) Where the first 2 shows that it is a response for a selective GET.Request with the selection criteria of Classes ( comp.5.12 ). The following 3 shows that the following logical names are logical names of Register Class instances, and finally there the fitting elements of the object_list attribute of the Association LN object instance. Note, that the returned list is not ordered.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

40/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition 7.3.2.2 Accessing attributes of COSEM Objects action
Getting the set of billing values Getting the data of the positive active energy register. (Register 1) Getting all attributes of the positive reactive energy register (Register 1)

Invoked service by the Client


GET.Request(7,0.0.103.0.0.255, 2) GET.Request(3,1.1.1.8.0.255, 2)

Invoked response by the Server


GET.Response( Value of the buffer attribute of the Profile object instance) GET.Response(Value of the value attribute of Register1 instance 0x1234)

GET.Request(3,1.1.1.8.0.255, 0) Note: Attribute_Id = 0 means that we are requesting for all attributes of the referenced object.

GET.Response( Values of the attributes of the referenced object )

action
Setting a new value for the positive active energy register (Register 1) Setting a new value for the positive reactive energy register (Register 2)

Invoked service by the Client


SET.Request (3, 1.1.1.8.0.255, 2, NewValue )

Invoked response by the Server


SET.Response( OK )

SET.Request (3, 1.1.3.8.0.255, 2, NewValue )

SET.Response ( ERROR, NO_ACCESS_RIGHT )

7.3.2.3 Invoking methods of COSEM Objects action


Resetting the positive active energy register (Register 1) Capturing a record to the buffer of the Profile Generic object

Invoked service by the Client


ACTION.request (3, 1.1.1.8.0.255, 1)

Invoked response by the Server


ACTION.response( OK )

ACTION.request(7,0.0.103.0.0.255, 2)

ACTION.response ( OK )

7.3.3 Communicating with the meter using SN referencing


Identification scheme for the COSEM Interface Object instances with short names is as follows: Register 1 (positive, active energy)
COSEM Register: class_id=3, version=0 attribute 1 attribute 2 attribute 3 method 1 logical_name value scaler-unit reset DLMS nv name 0x0000(base_name) 0x0008 0x0010 0x0028

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

41/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Register 2 (positive, reactive energy)
COSEM Register: class_id=3, version=0 attribute 1 attribute 2 attribute 3 method 1 logical_name value scaler-unit reset DLMS variable name (object_name) 0x1000 (base_name) 0x1008 0x1010 0x1028

Clock (clock1) COSEM Clock: class_id=8, version=0 attribute 1 attribute 2 attribute 3 attribute 4 attribute 5 attribute 6 attribute 7 attribute 8 attribute 9 method 1 method 2 method 3 method 4 method 5 method 6 logical_name time time_zone status daylight_savings_begin daylight_savings_end daylight_savings_deviation daylight_savings_enabled clock_base adjust_time adjust_to_measuring_period adjust_to_minute adjust_to_preset_time preset_adjusting_time shift_time DLMS variable name (object_name) 0x2000 (base_name) 0x2008 0x2010 0x2018 0x2020 0x2028 0x2030 0x2038 0x2040 0x2060 0x2068 0x2070 0x2078 0x2080 0x2088

Profile generic (set of billing values) The Profile object is used to define a set of billing values which must be retrieved with an typical readout (e.g. via HHU or PSTN). With one read access to attribute 3 (buffer) the data and the scaler_units of the the two registers are fetched.

COSEM Profile generic: class_id=8, version=2 attribute 1 ues) attribute 2 attribute 3 attribute 4 attribute 5 attribute 6 attribute 7 attribute 8 method 1 method 2 logical_name (set of billing valbuffer capture_objects: capture_period: sort_method: sort_object: entries_in_use: profile_entries: reset capture

DLMS variable name (object_name) 0x3000 (base_name) 0x3008 0x3010 0x3018 0x3020 0x3028 0x3030 0x3038 0x3058 0x3060

7.3.3.1 Retrieving the model of the Logical Device (meter): Assuming that the client is addressing the logical device for the first time and does not know anything about its structure. After the client-server association is established the client proceeds as follows: A READ to the DLMS variable 0xFA08 (representing the attribute object_list of the COSEM Association SN, comp. 5.13) reveals the following information:
DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

42/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
Base_name DLMS: variable-name 0x0000 0x1000 0x2000 0x3000 0xFA00 class_id 3 3 8 7 12 version 0 0 0 2 0 logical_name 0x0101010800FF 0x0101030800FF 0x0000010000FF 0x0000670000FF 0x0000640000FF

The client - knowing the definition of the interface classes 3 and,7 8 (comp. 0) - can now individually address the desired attributes and methods. 7.3.3.2 Retrieving data knowing the model of the Logical Device (meter): The following examples show how data is read and methods are activated via the DLMS variablenames. If the structure of the meter is known - or has been retrieved (comp. 7.3.3.1) - this method offers the most efficient access to data and methods. action
Reading the set of billing values

DLMS service
READ.Request::= SEQUENCE OF { [2] ObjectName::=0x3008 } READ.Request::= SEQUENCE OF { [2] ObjectName::=0x0008 } READ.Request::= SEQUENCE OF{ [2] ObjectName::= 0x1008; [2] ObjectName::= 0x1010 } WRITE.Request::= SEQUENCE{ SEQUENCE OF { [2] ObjectName::= 0x2060 }; SEQUENCE OF { Data::= [15] 0x00 }; }

Reading the data of the positive active energy register Reading the data and the unit_scaler of the positive reactive energy register

adjusting the time to the nearest quarter-on-an-hour value

7.3.3.3 Retrieving data NOT knowing the model of the Logical Device (meter): If the meter provides the optional method read_by_logicalname (comp 5.12) any attribute can be read directly (without knowing the structure of the meter). The following example shows how the positive active energy register is directly addressed via its EDIS code (logical_name). action
Reading the data of the positive active energy register via the logical_name

DLMS service
READ.Request::= SEQUENCE OF { [4] IMPLICIT SEQUENCE { ObjectName::= 0xFA30; Data::= { 3, class_id 0x0101010800FF, logical_name 2 attribute index } }

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

43/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

8. Appendix B: relation to OBIS


The EDIS identification system serves as a basis for the COSEM logical_names. The systematic of naming objects is defined in the basic priciple (comp. 0) the identification of real data items are specified in the Orange Book (comp. [3]). The following chapters define the usage of those definitions in the DLMS-COSEM environment. All codes which are not explicitly listed, but below the manufacturer specific range (128 .. 255) are reserved for future use.

8.1 Mapping of data items to COSEM objects and attributes


This chapter defines the usage of OBIS identifications and their mapping to objects of certain classes and their attributes.

8.1.1 Abstract objects


This chapter contains definitions for data items which are not directly linked to a energy type. 8.1.1.1 Clock This object controls the system clock of the physical device. It is an instance of the Interface class "Clock".
Clock Clock object OBIS identification
IC A B C D E F

Clock

0xFF

The usage of value group E shall be: If just one object is instantiated, value E shall be 0 If more then one object is instantiated in the same physical device its value group E shall number the instantiations from 1 to the needed maximum value. 8.1.1.2 Script tables These object control the behaviour of the device. Several instances of the Interface class "Script table" are predefined and normally available as hidden scripts only with access to the execute() method. The following table contains only the identifiers for the standard instances of the listed scripts. Implementation specific instances of these scripts should use values different from 0 in value group D.
script table objects global meter reset
6

OBIS identification
IC A B C D E F

MDI reset / cumulation

Script Table Script Table

0 0

x x

10 10

0 0

0 1

0xFF 0xFF

The activation of these scripts is performed by calling the execute() method to the script identifier 1 of the corresponding script object.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

44/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
tariffication script table Activate test mode
6 6

Activate normal mode broadcast script table

Script Table Script Table Script Table Script Table

0 0 0 0

x x x x

10 10 10 10

0 0 0 0

100 101 102 125

0xFF 0xFF 0xFF 0xFF

The tariffication script table defines the entry point into tariffication by standardising utility-wide how to invoke the activation of certain tariff conditions. The broadcast script table allows to standardise utility wide the entry point into regularly needed functionality. 8.1.1.3 Special Days Table This object defines and controls the behaviour of the device regarding calendar functions on special days for clock control . It is an instance of the Interface class "Special days Table"
Special Days Table OBIS identification
IC

Special Days Table object

Special Days Table

A 0

B x

C 11

D 0

E 0

F 0xFF

8.1.1.4 Schedule This objects defines and controls the behaviour of the device in a sequenced way. It is an instance of the Interface class "Schedule"
Schedule OBIS identification
IC

Schedule object

Schedule

A 0

B x

C 12

D 0

F 0xFF

The usage of value group E shall be: If just one object is instantiated, value E shall be 0 If more then one object is instantiated in the same physical device its value group E shall number the instantiations from 1 to the needed maximum value. 8.1.1.5 Activity Calendar This object defines and controls the behaviour of the device in a calendar based way. It is an instance of the Interface class "Activity Calendar"
Activity Calendar OBIS identification
IC

Activity Calendar object

Activity Calendar

A 0

B x

C 13

D 0

E 0

F 0xFF

8.1.1.6 IEC1107 Setup This objects define and contros the behaviour of the device regarding the communication parameters on the optical port according to IEC 61107. It is an instance of the Interface class "IEC 1107 Setup"
DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

45/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition
IEC 1107 Setup OBIS identification
IC

IEC 1107 Setup object

IEC 1107 Setup

A 0

B x

C 20

D 0

E x

F 0xFF

The usage of value group E shall be: If just one object is instantiated, value E shall be 0 If more then one object is instantiated in the same physical device its value group E shall number the instantiations from 1 to the needed maximum value. 8.1.1.7 Device ID A series of objects is used to communicate ID numbers of the device. Those can be numbers which are manufacturer definitions (manufacturing number) or which are user defined numbers. The different ID numbers are instances of the Interface class "Data", with data type octet-string. If more than one of those is used it is also allowed to combine them into one instance of the Interface class "Profile". In this case the captured objects are the device ID data objects, the capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are limited to 1.
Device ID Device ID 1 object Device ID 10 object Device ID's object OBIS identification
IC A B C D E F

data7 data
7

0 0 0

x x x

96 96 96

1 1 1

0 9 0

0xFF 0xFF 0xFF

profile

8.1.1.8 Parameter changes A set of simple objects describe the history of the configuration of the device. All values are transported by instances of the Interface class "Data".
Parameter changes Number of parameterisations object Date of last parameterisation change object Date of last time switch programme change object Date of last ripple control receiver program change object OBIS identification
IC A
7

data 7 data data data


7 7

0 0 0 0

x x x x

96 96 96 96

2 2 2 2

0 1 2 3

0xFF 0xFF 0xFF 0xFF

8.1.1.9 I/O pulse- and control signals These objects defines and controls the status of I/O lines and the pulse duration of physical pulse outputs of the device. Status is defined by a instance of the Interface class "Data".

In cases where the class data is not available, the class register (with scaler=0, unit=255) may be used.

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

46/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition The duration is given in milliseconds. It is an instance of the Interface class "register" with scaler = -3 and unit = s
I/O control signals Status of the I/O control signals object I/O Pulse Duration object OBIS identification
IC A
7

data Register

0 0

x x

96 0

3 9

0 5

0xFF 0xFF

8.1.1.10 Internal status These objects define the internal status of control signals and the internal operating status. The used interface class for these objects is "Data" with data type octet string. This data type is used to transport binary information from a bitmap.
Internal status status of internal control signals object internal operating status object OBIS identification
IC A
7

data 7 data

0 0

0 x

96 96

4 5

0 0

0xFF 0xFF

8.1.1.11 Power failures Different possibilities to represent values coming from power failure monitoring of the device are available. Simple counting of events is represented by objects of Interface class "Data" with data type unsigned or long unsigned. If more sophisticated information is presented the object shall be of Interface class "Profile".
Power failure Total power failure object Power failure Phase 1 object Power failure Phase 2 object Power failure Phase 3 object OBIS identification
IC A B C D E F

data or profile data or profile data or profile data or profile

0 0 0 0

0 0 0 0

96 96 96 96

7 7 7 7

0 1 2 3

0xFF 0xFF 0xFF 0xFF

8.1.1.12 Error values A series of objects is used to communicate error indications of the device. The different error values are instances of the Interface class "Data", with data type octetstring. If more than one of those is used it is also allowed to combine them into one instance of the Interface class "Profile". In this case the captured objects are the device ID data objects, the capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are limited to 1.
Error values Error 1 object Error 10 object Error profile object DLMS User Association OBIS identification
IC A
7

data data

0 0 0

0 0 0

97 97 97

97 97 97

0 9 0

0xFF 0xFF 0xFF

profile

Error code objects can also be related to a energy type and to a channel. Comp. [3]

EXCERPT

DLMS UA 1000-1 ed.2

47/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

8.1.1.13 Association objects A series of objects is used to identify association objects within a physical device.
Association objects Association, instance 1 .. Association, instance n OBIS identification
IC A B C D E F

Association LN/SN Association LN/SN

100

0xFF

100

0xFF

8.1.1.14 Standard readout profile A set of objects is defined to carry the standard readout as it would appear with IEC 1107.
Standard readout general IEC 61107 readout additional readout profile 1 .. additional readout profile n OBIS identification
IC A B C D E F

Profile Profile Profile

0 0 0

0 0 0

103 103 103

0 0 0

0 1 n

0xFF 0xFF 0xFF

Standard readout objects can also be related to a energy type and to a channel. Comp. [3]

8.1.2 Electrical energy related objects


8.1.2.1 Value group D definitions The different values as defined by different value group D, and which do not represent historical data, are used in following way: Cumulative values are represented by objects which are instances of Interface class "register" Maximum and minimum values are represented by objects which are instances of Interface class "profile" with sorting method maximum or minimum, depth according to implementation and captured objects according to implementation Current and last average values are the respective attributes of objects which are instances of Interface class "demand", using the OBIS code of the current value as logical name Time integral values are represented by of objects which are instances of Interface class "register" 8.1.2.2 Historic data DLMS-COSEM treats historical values as profiles. It is possible to identify a bulk of historical values as well as each value. With value group F having a value between 0 and 99, and 101 the direct access to historical data is available. This is managed by objects of class profile which are 1 entry deep and contain the timestamp of the storage in addition to the stored value. Note: no historic values are available for values of type current and last average. With value group F having a value between 102 and 1xx the data are represented by objects which are instances of Interface class "Profile", with suitable values for the controlling attributes.
DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

48/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition Important: All data items which do not represent a historic value shall use 0xFF in the value group F. 8.1.2.3 Electricity ID numbers The different Electricity ID numbers are instances of the Interface class "Data", with data type octetstring. If more than one of those is used it is also allowed to combine them into one instance of the Interface class "Profile". In this case the captured objects are the Electricity ID data objects, the capture period is 1 to have just actual values, the sort method is FIFO, the profile entries are limited to 1.
Electricity ID OBIS identification
IC A
7

Electricity ID 1 object

data data

1 1 1

x x x

0 0 0

0 0 0

0 9 0

0xFF 0xFF 0xFF

Electricity ID 10 object Electricity ID's object

profile

8.1.2.4 Historical data related entries Those values are represented by instances of the Interface class "Data" with data type unsigned.
Historical data related entries Status of historical value counter object Number of available historical values object OBIS identification
IC A
7

data 7 data

1 1

x x

0 0

1 1

0 1

0xFF 0xFF

The time stamps of historical data values shall be part of the captured objects within the objects representing the historic values. The values can also be related to a channel. 8.1.2.5 Program entries Those values are represented by instances of the Interface class "Data" with data type unsigned or long unsigned.
Program entries Program version No. object Time switch program No. object RCR program no. object OBIS identification
IC A
7

data 7 data 7 data

1 1 1

x x x

0 0 0

2 2 2

0 2 3

0xFF 0xFF 0xFF

Program entries can also be related to a channel. Comp. [3]

8.1.2.6 Input and Output pulse constants, Nominal values Those values are represented by instances of the Interface class "Register".

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

49/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition 8.1.2.7 Ratios Those values are represented by instances of the Interface class "Data" with useful data types. 8.1.2.8 Threshold values Those values are represented by instances of the Interface class "Register Monitor" by defining the monitored register, the threshold itself and the actions to be performed, when a threshold is crossed. 8.1.2.9 Measurement- registration period values, time entries Those values are represented by instances of the Interface class "Register".

8.2 Coding of OBIS identifications


To identify different instances of the same class they have to differ in their logical_name. In DLMS-COSEM the logical_name is taken from the OBIS definition (comp. [3]). 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. Octet 1 contains the binary coded value of A (A= 1, 2, ...8) in the four rightmost bits. The 4 leftmost bits contain the information on the identification system. The 4 leftmost bits set to zero indicate that the OBIS identification system (version 1) is used as logical_name . Used identification system OBIS, comp. [3] Reserved for future use 4 leftmost bits of octet 1 (MSB left) 0000 0001 ... 1111

Within all value groups the usage of a certain selection is fully defined, others are reserved for future use. Value group A is fully defined respective reserved for all possible values. No defined value group item within groups B to F exists above 127. Each value which is not linked to a historical set must be tagged 0xFF in the value group F. The usage of the code space 128 to 254 (0xFE) characterises a manufacturer specific code. If one value in a group B to F is used above 127 the whole code is characterised as manufacturer specific and even the other value groups (with the exception of group A) are not necessarily bearing any meaning defined by this standard.

... more follows ...


(comp. DLMS UA 1000-1, Second Edition) DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

50/51

Copyright 1997-1999 DLMS User Association

DLMS User Association, EXCERPT FROM COSEM Interface Objects, Second Edition

DLMS User Association

EXCERPT

DLMS UA 1000-1 ed.2

51/51

Copyright 1997-1999 DLMS User Association