COSEM Object Model & Interfaces Classess

COSEM Object Model & Interfaces Classess

1. COSEM Object Model & Interfaces Classes … in metering, we speak the same language

2. DLMS/COSEM Specification The DLMS/COSEM specification specifies a data model and communication protocols for data exchange with metering equipment. The DLMS/COSEM follows a 3 step approach Data model , to view the meter functionality at its interface(s) COSEM objects OBIS Object Identification System Messaging method to communicate with the model and to represent data as a series of bytes (APDUs) Transportation method to carry the messages over the media between the meter and remote parties

3. COSEM COSEM - Co mpanion S pecification for E nergy M etering A ddresses the challenges by looking at the utility meter as part of a complex measurement and control system. COSEM achieves this by using object modelling techniques to model all functions of the meter, without making any assumptions about which functions need to be supported, how those functions are implemented and how the data are transported. The formal specification of COSEM interface classes forms a major part of COSEM.

4. COSEM Server M odel The COSEM server is structured into three hierarchical levels Level 1: Physical device Level 2: Logical device Level 3 : Accessible COSEM objects

5. COSEM logical device COSEM logical device: The COSEM logical device contains a set of COSEM objects. Each physical device shall contain a “Management logical device ”. C OSEM logical device name (LDN) : The COSEM logical device can be identified by its unique COSEM LDN. This name can be retrieved from an instance of IC “SAP assignment” , or from a COSEM object “COSEM logical device name ”. The LDN is defined as an octet-string of up to 16 octets. The manufacturer shall ensure that the LDN, starting with the three octets identifying the manufacturer and followed by up to 13 octets, is unique.

6. COSEM Interface Objects Object: An object is a collection of attributes and methods. Attributes represent the characteristics of an object. The value of an attribute may affect the behaviour of an object. An object may offer a number of methods to either examine or modify the values of the attributes. Attributes: Each attribute has a meaning , a data type and a value range Any real-world things can be described by some attributes Methods: Methods allow performing operations on attributes All data in the meter are mapped to objects Using the object means: ...to read or write the attributes ...to invoke the methods Attribute – 1 Attribute – 2 …. Attribute – n Method – 1 Method – 2 …. Method - n Object

7. Referencing methods Attributes and methods of COSEM objects can be referenced in two different ways : Using logical names (LN referencing) : In this case, the attributes and methods 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 . Where attribute_index & method_index is used as the identifier of the attribute required. Using short names (SN referencing) : 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.

8. Modelling, from reality to abstraction Class Name Logical Name Attribute - 2 …. Attribute - n Method – 1 (m/o) …. Method - n Register Logical Name Value Scalar Unit Reset (m/o) Register 1 Logical Name ( 1.0.1.7.0.255 ) Active energy (3600) Scalar Unit (kWh) Register 2 Logical Name (1.0.14.7.0.255) Value (50) Scalar Unit (Hz) The same interface classes can be used for all energy types to hold measurement values and configuration parameters Template Interface Class Objects All data in the meter are mapped to objects The objects provide the meter’s functional model Similar objects make up an interface class (IC) Each IC has a specific set of attributes and methods All ICs are accessed with the same xDLMS services (Get/Set/Action….)

9. Interface class template Class name: Describes the interface class (e.g. “Register”, “Clock”, “Profile generic”...). Cardinality: Specifies the number of instances of the IC within a logical device Class_id: Identification code of the IC (range 0 to 65535 ). Version: Identification code of the version of the IC ( Within one logical device, all instances of a certain IC shall be of the same version ).

10. The “association view” of the logical device In order to access COSEM objects in the server, an application association (AA) shall first be established with a client. The major parts of this context are: the application context; the authentication mechanism; the xDLMS context. AAs are modelled by special COSEM objects: • instances of the IC “Association SN” – are used with short name referencing; • instances of the IC “Association LN” – are used with logical name referencing.

11. Mandatory contents of a COSEM logical device The following objects shall be present in each COSEM logical device. They shall be accessible for GET/Read in all AAs with this logical device: COSEM logical device name object; current “Association” (LN or SN) object. If the “SAP Assignment” object is present, then the COSEM logical device name object does not have to be present.

12. Common data types T he list of data types usable for attributes of COSEM objects are defined in Clause 4.1.5, Bluebook Edition 12.2. Blue_Book_edition_12-2.pdf

13. Data formats Date and time formats : Date and time information may be represented using the data type octet-string . Date and time information may be also represented using the data types date, time and date-time . Date format Time format Date - Time

14. COSEM interface classes – main categories Data storage store measurement values, parameters and statuses Access control and management allow managing the meter and to securely access data Time / event bound control control the operation of the meter based on time and events Payment metering manage the payment function of the meter Communication setup configure and manage the communication interfaces

15. COSEM I nterface Classes – Part 1

16. COSEM Interface Classes – Part 2

17. COSEM Interface C lasses – Part 3

18. Data ( class_id = 1, version = 0) This IC allows modelling various data, such as configuration data and parameters. Object_list [48,4]\Object_list.csv Any simple and complex data types listed Blue_Book_edition_12-2.pdf Generally used for : Tamper, billing, programming count, No. of power failures & Name plate details parameters

19. Register ( class_id = 3, version = 0) This IC allows modelling a process or a status value with its associated scaler and unit .

20. Register ( class_id = 3, version = 0) Attribute Data type Value Logical Name Octet String 1.0.72.7.0.255 Value Double long unsigned 2309 Scalar Unit Scaler Integer -1 Unit Enum 35 Generally used for : Voltage, Current, Power, Energy, Power factor, Frequency, power on / off duration etc. If any parameter scaler is not applicable (Attribute 3 can be used as 255) Example:

21. Extended Register ( class_id = 4, version = 0) This IC allows modelling a process value with its associated scaler, unit, status and capture time information. Generally used for : Capturing MD kW or MD kVA etc.

22. Demand register ( class_id = 5, version = 0) This IC allows modelling a demand value with its associated scaler, unit, status and time information

23. Demand register ( class_id = 5, version = 0) Current average value Last average value Capture time (Date and time when the last average value has been calculated) Status Provides “Demand register” specific status information. Start time current W hen the measurement of the current average value has been started .

24. Period: Interval between two successive updates of the last average value . ( number of periods*period is the denominator for the calculation of the demand ). Number of periods : used to calculate the last average value . Number of periods > 1 ( last average value represents “Sliding demand ” ) Number of periods = 1 ( last average value represents “Block demand”)

25. Profile generic ( class_id = 7, version = 1)

26. This IC provides a generalized concept allowing to store, sort and access data groups or data series, called capture objects . C apture objects are collected periodically or occasionally. A profile has a buffer to store the captured data. Generally used for : Instantaneous, Block load , Billing, Daily load, Name plate details & event profile etc. Profile generic ( class_id = 7, version = 1)

27. The size of profile data is determined by three parameters : T he number of entries filled ( entries in use ): This will be zero after clearing the profile; T he maximum number of entries to retain ( profile entries ): Specifies maximum number of entries, Upon changing it, the buffer will be adjusted; T he physical limit for the buffer: This limit typically depends on the objects to capture. The object will reject entries that is larger than physically possible. Profile generic ( class_id = 7, version = 1)

28. Selective Access

29. Clock ( class_id = 8, version = 0) This IC models the device clock, managing all information related to date and time (time zone, day light saving begin & end etc.) These IC also offers various methods to adjust the clock . D ate information - Includes the elements year, month, day of month and day of week. T ime information - Includes the elements hour, minutes, seconds, hundredths of seconds, and the deviation of the local time from UTC. Generally Used for: Real time clock, date & time (RTC)

30. Script table ( class_id = 9, version = 0) This IC allows modelling the triggering of a series of actions by executing scripts using the execute (data) method. These objects associate a script with each time switch

31. Schedule ( class_id = 10, version = 0) This IC, together with the IC “Special days”, allows modelling time- and date-driven activities within a device.

32. Special days table ( class_id = 11, version = 0) This IC allows defining special dates. On such dates, a special switching behaviour overrides the normal one. The IC works in conjunction with the class "Schedule" or " Activity calendar ". The linking data item is day id .

33. Schedule Vs Special Day table

34. Instances of the Image transfer IC model the process of transferring binary files, called Images to COSEM servers . Image transfer ( c lass_id = 18, version = 0)

35. Image transfer ( class_id = 18, version = 0) Image Size: Size of the whole Image to be transferred Image Block Size: Size of Image Block expressed in octets Image transferred blocks status : Provides information about the transfer status of each Image Block. 0 = Not transferred, 1 = Transferred Image transfer enabled : Controls the enabling of the Image transfer process. FALSE = Disabled, TRUE = Enabled Generally used for : For Firmware upgrade / Image transfer & Image activation

36. Image transfer ( class_id = 18, version = 0) The Image transfer usually takes place in several steps: Step 1 (Optional ): Get Image Block Size ; Step 2: Client initiates Image transfer; Step 3: Client transfers Image Blocks ; Step 4: Client checks completeness of the Image ; Step 5: Server verifies the Image (Initiated by the client or on its own); Step 6 (Optional): Client checks the information on the images to activate; Step 7: Server activates the Image(s) (Initiated by the client or on its own ).

37. Image transfer status : Holds the status of the Image transfer process. (0) Image transfer not initiated, (1) Image transfer initiated, (2) Image verification initiated, (3) Image verification successful, (4) Image verification failed, (5) Image activation initiated, (6) Image activation successful, (7) Image activation failed

38. Activity calendar ( class_id = 20, version = 0) This IC allows modelling the handling of various tariff structures in the meter .

39. Season Profile: Contains a list of seasons defined by their starting date and a specific week profile to be executed. Season profile name is a user defined name identifying the current season profile; Season start defines the starting time of the season, formatted date-time . In season start, wildcards are allowed. If all fields are wildcards, the season will never start. Week name defines the week profile active in this season.

40. Week profile name is a user defined name identifying the current week profile ; Monday defines the day profile valid on Monday; … Sunday defines the day profile valid on Sunday. Week Profile: Contains an array of week profiles to be used in the different seasons. For each week profile, the day profile for every day of a week is identified.

41. Day id is a user defined identifier, identifying the current day profile ; Start time : defines the time when the script is to be executed (no wildcards); Script logical name : defines the logical name of the “Script table” object; Script selector : defines the script identifier of the script to be executed . Day Profile: Contains an array of day profiles, identified by their day id. For each day profile, a list of scheduled actions is defined by a script to be executed and the corresponding activation time (start time).

42. Single action schedule ( class_id = 22, version = 0) This IC allows modelling the execution of periodic actions within a meter . Generally Used for: Single action schedule (SA) for billing dates, SA for Image Activation & Data push services etc.

43. IEC HDLC setup ( class_id = 23, version = 1) This IC allows modelling and configuring communication channels according to DLMS UA 1000-2 Ed. 8.2:2017 Clause 8. Several communication channels can be configured.

44. Push setup ( class_id = 40, version = 0) The "Push setup” IC contains a list of references to COSEM object attributes to be pushed. It also contains the push destination and method as well as the communication time windows and the handling of retries.

45. S end _ destination_ and method: Contains the destination address (e.g. phone number, email address, IP address) where the data specified by the push_object_list has to be sent, as well as the sending method. send_destination_and_method ::= structure { transport_service : transport_service_type , destination: octet-string, message: message_type } T he transport_service element defines the type of service used to push the data .

46. Disconnect control ( class_id = 70, version = 0) Instances of the “Disconnect control” IC manage an internal or external disconnect unit of the meter ( e.g. electricity breaker, gas valve) in order to connect or disconnect – partly or entirely – the premises of the consumer to / from the supply.

47. Disconnect and reconnect can be requested : • Remotely, via a communication channel: remote_disconnect , remote_reconnect ; • Manually, using e.g. a push button: manual_disconnect , manual_reconnect ; • Locally, by a function of the meter, e.g . limiter, prepayment : local_disconnect , local_reconnect . States: 0 - Disconnected 1 – Connected 2 - Ready_for_reconnection

48. Control mode Configures the behaviour of the disconnect control object for all triggers, i.e. the possible state transitions . In Mode (0) the disconnect control object is always in 'connected' state. Local disconnection is always possible unless the corresponding trigger is inhibited .

49. Limiter ( class_id = 71, version = 0) Instances of the “Limiter” IC allow defining a set of actions that are executed when the value of a value attribute of a monitored object “Data”, “Register”, “Extended Register”, “Demand Register”, etc. crosses the threshold value for at least minimal duration time.

50. References IS 15959 (Part 1): 2011 IS 15959 (Part 2): 2016 IS 15959 (Part 3): 2017 IS 16444 (Part 1): 2015 IS 16444 (Part 2): 2017 DLMS Colour books (White, Yellow, Blue & Green)

51. Any Queries? Thank you..)