Source: https://www.scribd.com/document/53321060/61968-9-Message-profiles-for-DLMS
Timestamp: 2018-01-22 06:59:10
Document Index: 555121719

Matched Legal Cases: ['art-9', 'arts 3', 'art 9', 'art 11', 'art 61968', 'art 61', 'art 53', 'art 62', 'art 11']

61968-9 Message profiles for DLMS | Class (Computer Programming) | Xml
Uploaded by Ana_Rossello_B_9523
DLMS/COSEM/CIM Study Report
61968-9 Message profiles for DLMS/COSEM
14 th June 2010 Final
Study report by:
Don Taylor and Gyozo Kmethy
Gyozo Kmethy Don Taylor
Secretary, IEC TC 13 and President, DLMS User Association National expert, IEC TC13 WG15 and IEC TC57 WG14
DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00
FOREWORD.........................................................................................................................3 INTRODUCTION...................................................................................................................4 1 2 3 4 5 6 7 8 Scope ............................................................................................................................5 Conclusion .....................................................................................................................5 Recommendations ..........................................................................................................6 Practical use of the results..............................................................................................6 References.....................................................................................................................8 Terms, definitions and abbreviations ...............................................................................8 6.1 Abbreviations ........................................................................................................8 DLMS/COSEM as extension of the CIM...........................................................................9 Message profiles ..........................................................................................................13 8.1 8.2 8.3 8.4 8.5 GetRequest and GetResponse .............................................................................13 SetRequest and SetResponse .............................................................................18 ActionRequest and ActionResponse.....................................................................21 EventNotification .................................................................................................24 XML Schema of GetRequest ................................................................................26
Figure 1 – UML representation of DLMS_COSEM Object as extension to CIM ........................9 Figure 2 – XML Schema for GetRequest..............................................................................13 Figure 3 – XML Schema for GetResponse ...........................................................................15 Figure 4 – Sequence of message exchange for GetRequest and GetResponse ....................16 Figure 5 – XML Schema for SetRequest ..............................................................................18 Figure 6 – XML Schema for SetResponse ...........................................................................19 Figure 7 – Sequence of message exchange for SetRequest and SetResponse .....................20 Figure 8 – XML Schema for ActionRequest..........................................................................21 Figure 9 – XML Schema for ActionResponse .......................................................................22 Figure 10 – Sequence of message exchange for ActionRequest and ActionResponse ..........23 Figure 11 – XML Schema for EventNotification ....................................................................24 Figure 12 – Sequence of message exchange for EventNotification .......................................25 Table 1 – Message and attribute truth table mapping ...........................................................11
1) IEC TC57 deals with the generation, transmission and distribution standards related to interfaces for message exchange between systems. 2) These interfaces are derived from UML information models created in the CIM that represents a common set of information found in the utilities business application domain. 3) TC57 WG14 deals with those interfaces for systems related to distribution networks and publish these in the IEC 61968 series of standards. 4) The scope of these interfaces is limited to facilitate communication/integration between ERP systems and the Metering System (MS) head-end and does not include the downstream protocols from the MS to the meter end device. 5) IEC TC13 deals with metering, tariff and load control and in particular data models and communications protocols used for data exchange between the MS head-end down to the meter end device. 6) The DLMS/COSEM specification, part of the IEC 62056 suite specifies the COSEM data model specifying the COSEM objects. The COSEM application layer specifies the DLMS messaging services to access the COSEM model. The resulting DLMS application messages are transported through any suitable set of lower layers. IEC TC 13 WG 14 works with the DLMS UA to promote, support, develop and maintain DLMS/COSEM. IEC 62056 has also been adopted by CEN TC 294 for data exchange with meters other than electricity (gas, water, heat).
TC57 WG14 approached TC13 with a request to investigate the feasibility of modelling end devices using the DLMS/COSEM object modelling the CIM with the aim to create 61968 compliant message profiles that will enable an ERP system to send messages via the MS head-end to COSEM Objects residing in end devices installed in the metering system.
NOTE: It is important to note that TC57 message profiles are not concerned with the protocols used between the metering system head-end and the downstream meters or devices. However, the contextual relationships between information elements in the metering domain are important to be known by the message profiles and therefore these elements need to be accurately modelled in the CIM.
14 th June 2010 –4– DLMS/COSEM/CIM Study Report INTRODUCTION IEC TC57 standards relevant to this investigation: IEC 62361-100 Naming and Design Rules covers the rules for XML structure of message profiles derived from the UML in the CIM. The DLMS UA regularly offers the latest editions of the Blue Book and the Green Book for international standardization to IEC and CEN. CIMTool is a software tool that imports the UML in XMI format and then enables the operator to create XML Schema (XSD) format documents for each message profile required. XMLspy is a software tool that allows the viewing of XSD files in graphical notation. Other tools relevant to this investigation: Enterprise Architect (EA) is a software tool that allows the operator to create UML notation models and sequence diagrams. IEC 61968-9 covers interface message profiles for meter reading and load control. See clause 5 for the list of references DLMS User Association specifications relevant to this investigation: The Blue Book covers the COSEM interface class specifications and the OBIS data identification system. DLMS_COSEM_CIM_profile_report_final. IEC 61968-11 covers the CIM for Distribution in UML notation. TC13 standards relevant to this investigation: IEC 62056 covers meter data exchange including the DLMS/COSEM suite. The Green Book specifies the protocol layers and the communication profiles.docsaved on 14/06/2010 08:33:00 .
a) ERP can selectively “write” values down to individual attribute level of COSEM Objects in Logical Devices located in physical devices. A UML model of a COSEM physical device with logical device was created as an extension to the CIM. One logical device. DLMS_COSEM_CIM_profile_report_final. The following message profiles were then created in CIMTool: ActionRequest.xsd GetResponse. based on iec61970cim14v12_iec61968cim10v28_combined_DLMS(1. NOTE that this model is a first-approach only and still needs some further work for optimisation in the final version. XMLspy was then used to view these XSD files and displayed in graphical diagram notation for ease of interpretation by the reader.xsd EventNotification. The UML was exported to an XMI format file and then imported to CIMTool as a project. 2) The XSD message profile.xsd SetResponse. so produced.14 th June 2010 –5– DLMS/COSEM/CIM Study Report 1 Scope The COSEM data model models physical devices as a set of one or more COSEM logical devices. maintains the attribute definitions and the class relationships as modelled in the CIM. the Management Logical device is mandatory.xsd SetRequest.xsd NOTE also the following: 1) CIMTool creates message profiles in conformance with the Naming and Design Rules.02).xsd ActionResponse. EA was used to create use case sequence diagrams to show the interaction and message interchange between the 3 actors: ERP_System.xsd GetRequest. It is also relatively simple to create DLMS/COSEM message profiles in XSD that covers almost all the functionality required for an ERP system to talk to DLMS/COSEM compliant end devices via the MS head-end. These are detailed in the below text for further reading and interest. NOTE In the Management Logical Device. uniquely identifying the Logical Device.docsaved on 14/06/2010 08:33:00 . Each COSEM logical device contains two or more COSEM objects. The two mandatory objects are the Current Association object controlling the access to the resources and the Logical Name object. holding the names and the SAPs of each logical device present. 2 Conclusion The COSEM model is a relatively simple structure as captured in UML notation in the CIM. b) ERP can selectively “read” values down to individual attribute level of COSEM Objects in Logical Logical Devices located in physical devices. MS_System and Meter_EndDevice. the Logical Device Name object may be replaced by the SAP assignment object.eap.
CIS has a copy of the DLMS/COSEM specification and thus it knows which logical device. If the answer is affirmative.docsaved on 14/06/2010 08:33:00 . It will thus be an extension of IEC 61968-9 that will enable ERP systems to communicate to the metering head-end when the meters are DLMS/COSEM compliant.14 th June 2010 –6– DLMS/COSEM/CIM Study Report c) ERP can “invoke” actions down to individual method level of COSEM Objects in Logical Devices located in physical devices. the logical device name for each meter. So. the objects of interest for each logical device and the attributes of interest for each object. ⎯ Mr. which object and which attributes it wants the values from. 4 Practical use of the results The standards produced by TC57 WG14 are message profiles to be used for integration of systems at the ERP level related to the utility business domain in the distribution network. from whence came the initial enquiry for this investigation. ⎯ DLMS User Association management committee and core team. it plugs into the GetRequest message (the one we created) the meter serial numbers of interest. extending to the meters and other end devices. The message exchange is not directly between the ERP system and the end device. Such a submission can possibly be done via a D-Liaison between DLMS User Association and TC57 WG14 specifically set up for this purpose. Eric Lambert at ERDF. It now sends this message to the metering system head-end (HE) with the request to please obtain the information specified in the message for it from the meters specified in the message. ⎯ IEC TC13 WG14. but always indirectly via the metering system head-end. The following example may illustrate this more clearly: Let’s say the customer information system (CIS) wants to obtain a certain set of readings from a particular known group of meters. but it cannot directly speak to the meters. Don Taylor is willing to take the lead of a sub-team in the current Part-9 team in TC57 WG14 to deal with the DLMS-COSEM work and Gyozo Kmethy is willing to play the lead role from the DLMS User Association side with a team of DLMS experts supporting him. d) ERP can receive unsolicited event notifications from individual COSEM Objects in Logical Devices located in physical devices. by means of a request/response message exchange protocol and is always asynchronous (no system state). ⎯ IEC TC57 WG14. then the content of this report could be submitted to TC57 WG14 as a work item for inclusion into the current work program for the revision of IEC 61968-9 Ed2. The shortfall of messages not yet covered can be completed on a next round of refinements. who expressed an independent interest in this work A decision needs to be made whether it is desirable to progress this work further into an IEC standard under the IEC 61968 suite. 3 Recommendations This report is to be circulated to the following parties: ⎯ Team of experts that participated on the teleconference call in November 2009. HE then goes away and in its DLMS_COSEM_CIM_profile_report_final.
puts these into the GetResponse message. This is an example of ERP to HE integration. each dealing with a different part of the business application domain in the utility distribution network (see table below). For example MDM or MDC may also send the same message request to HE and obtain the same information in the same standard format. It may rightfully be asked: what is the specific advantage of the particular message profiles that we have created for this purpose? It may also be argued that CIS could have compiled any message in any format agreed between CIS and HE to achieve this. Now. attribute and method exactly as is defined in the DLMS/COSEM standards. but the same is true for peer-peer integration. Below is a current list of work items in TC57 WG14 in the IEC 61968 suite. logical device. This is ultimately the purpose of the 61968 interface standards . 61968-9 specifically deals with message profiles relating to meter reading and control. I would also refer the reader to 61968-1-1 Enterprise Service Bus. there are other parts of 61968.to provide a standard set of message profiles for system integration at the back-end. object. which it sends back to CIS in reply to its original request. Parts 3 to 10 and 12 to 14 are message profiles for those particular business domains.docsaved on 14/06/2010 08:33:00 . Thus the CIS never speaks directly to the meter. while the message profiles will end up in Part 9. It is true. but always via the HE. Part 11 contains the UML model of the CIM from which the message profiles are derived (in the same way as we have done for this DLMS/COSEM investigation) and that is also where the UML part in our report will end up.14 th June 2010 –7– DLMS/COSEM/CIM Study Report own time performs a DLMS-protocol session with the meters of interest. reads the values and when it is ready. Part 61968-1 61968-1-1 61968-1-2 61968-2 61968-3 61968-4 61968-5 61968-6 61968-7 61968-8 61968-9 61968-10 61968-11 61968-12 61968-13 61968-14-1 61968-14-2 Title Interface Architecture Enterprise Service Bus Webservices Implementation Profile Glossary Network Operations Records & Asset Management Operational Planning Maintenance & Construction Network Extension Customer Support Meter Reading & Control Distributed Energy Resources CIM for Distribution Compliance & Interoperability Common Distribution Power System Model MultiSpeak mapping to 61968 MultiSpeak profile Stage IS WD WD TR IS FDIS WD WD WD WD ED1 WD CDV WD FDIS WD WD DLMS_COSEM_CIM_profile_report_final. No session state is held between CIS and HE or CIS and meter and the exchange is totally asynchronous. which has a direct interest to TC13. which is one such integration bus defined exactly for this purpose and using the 61968 message profiles. but the difference is a) we have defined a standard message structure and b) the message structure maintains the contextual relationship between physical device. However.
COSEM Interface Classes and the OBIS Identification System (the "Blue Book") DLMS UA 1000-1 Ed. definitions and abbreviations Abbreviations Device Language Message Specification Companion Specification for Energy Metering Common Information Model Unified Modelling Language Extensible Markup Language XML Schema Document International Electrotechnical Commission Technical Committee 57 Technical Committee 13 TC 57 Working Group 14 TC13 Working Group 15 TC13 Working Group 14 Enterprise Resource Planning Metering System Enterprise Architect XML Metadata Interchange Logical device Name DLMS COSEM CIM UML XML XSD IEC TC57 TC13 TC57 WG14 TC13 WG15 TC13 WG14 ERP MS EA XMI LDN DLMS_COSEM_CIM_profile_report_final. tariff and load control – Part 61: OBIS Object identification system IEC 62056-62 Ed 2.0:2006. 9.0:2009.0:2006. tariff and load control – Part 53: COSEM Application layer IEC 62056-61 Ed 2. Electricity metering – Data exchange for meter reading.0:2006.14 th June 2010 –8– DLMS/COSEM/CIM Study Report 5 References IEC 61968-11. Electricity metering – Data exchange for meter reading. tariff and load control – Part 62: Interface classes DLMS UA 1000-1 Ed. DLMS/COSEM Architecture and Protocols (the “Green Book”) NOTE Lower layer standards from the IEC 62056 DLMS/COSEM suite are not listed here. 6 6. Electricity metering – Data exchange for meter reading. SYSTEM INTERFACES FOR DISTRIBUTION MANAGEMENT – Part 11: Common information model (CIM) extensions for distribution IEC 62056-53 Ed 2.docsaved on 14/06/2010 08:33:00 .0:2009.1 Terms.7.
14 th June 2010 –9– DLMS/COSEM/CIM Study Report 7 DLMS/COSEM as extension of the CIM Figure 1 – UML representation of DLMS_COSEM Object as extension to CIM DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
Each COSEM object is an aggregation of one or more attributes. The service class refers to the DLMS service used to access the attributes. The response may include data. Otherwise.docsaved on 14/06/2010 08:33:00 . it may be confirmed (response is expected) or unconfirmed (response is not expected). it may be confirmed or unconfirmed. A PhysicalDevice is an aggregation of one or more logical devices. as specified by the SelectiveAccessDescriptor. actionResult or both. End devices are conceptually those device physically located at or near to (but associated with) the ServiceDeliveryPoint at the end of the distribution network. but primarily serves to demonstrate the required functionality. Access to COSEM object methods may include sending data from the HE to the meter as method invocation parameters. The version of the interface class need to be known by the HE. Each COSEM objects may have zero or more methods. the version information is not part of the data exchanges between the HE and the meter. by reading the appropriate attributes of the Association objects.14 th June 2010 – 10 – DLMS/COSEM/CIM Study Report How to read Figure 1: EndDeviceAsset is a child class in the inheritance hierarchy of asset classes modelled in the CIM. It can be retrieved from the meter. Each LogicalDevice is identified by a unique logical device name (LDN). A LogicalDevice is an aggregation of one or more COSEM objects. Some COSEM object attributes may be accessed selectively. The ServiceDeliveryPoint is the point on the network where ownership and risk transfers fron the service supplier to the customer and is practically the point where a dwelling is connected to the network. DLMS_COSEM_CIM_profile_report_final. The serviceClass refers to the DLMS service used to access the attributes. Each CosemObject has a classId – defining the number and kind of attributes and methods . Each Attribute is identified by its attributeId. NOTE The required functionality at the customer’s premises may be implemented in one or more physical devices. Access to COSEM object attributes – for reading or writing – results in data or data access result sent by the meter. Note that this model is not optimised for final inclusion into the CIM.a version (of the class) and a logicalName. In this context a billing meter is such an EndDeviceAsset and is typically connected to the ServiceDelivery point. Thus MeterAsset is a child class of (or a “kind of”) EndDeviceAsset In the DLMS/COSEM context we model the PhysicalDevice as a “kind of” EndDeviceAsset (rather than a MeterAsset) because COSEM objects may locate in devices other than meters.
Note that the presence of the various elements is shown for the data exchange between the ERP and the HE. Table 1 shows the attributes and their use by each message in accordance with which rules the message profiles were created.14 th June 2010 – 11 – DLMS/COSEM/CIM Study Report For example: CosemData and CosemResult could be modelled as compound data types that would improve the model. The presence of these elements in the data exchange between the HE and the end devices is specified in the DLMS/COSEM standards. M = mandatory O = optional Blank = not used Table 1 – Message and attribute truth table mapping Message GetRequest GetResponse SetRequest SetResponse ActionRequest ActionSesponse EventNotification LDN M M M M M M M classID logicalName version M M O M M O M M O M M O M M O M M O M M O attributeID serviceClass M M M M M M M accessSelector O O methodID serviceClass M M M DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
description ActivityRecord.name PhysicalDevice.createdDateTime ActivityRecord.docsaved on 14/06/2010 08:33:00 .description PhysicalDevice.serialNumber O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O DLMS_COSEM_CIM_profile_report_final.data CosemData.data AccessParamete.localName PhysicalDevice.severity O O O O O O O O PhysicalDevice.dataType AccessParameter.name ActivityRecord.category ActivityRecord.dataType M M M M dataAccessResult actionResult O M O M ActivityRecord.mRID ActivityRecord.mRID PhysicalDevice.14 th June 2010 – 12 – O M M DLMS/COSEM/CIM Study Report O O M M CosemData.reason ActivityRecord.localName ActivityRecord.
1 Message profiles GetRequest and GetResponse Figure 2 – XML Schema for GetRequest DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 13 – DLMS/COSEM/CIM Study Report 8 8.
SelectiveAccessDescriptor (optional). The serviceClass specifies if a response is expected or not. the Logical Device Name object may be replaced by the SAP assignment object. Each LogicalDevice contains one or more CosemObjects. holding the names and the SAPs of each logical device present. This LDN is held by a Logical Device Name object.14 th June 2010 – 14 – DLMS/COSEM/CIM Study Report How to read Figure 2 The solid boxes are mandatory data elements contained in the message payload. Attribute 1 holds the LogicalName. and version and has one or more CosemAttributes. Each physical device contains one or more Logical Devices. • • GetRequest is a document referencing one or more logical devices in a physical device. Each CosemAttribute reference contains the class_id. Each CosemObject is identified by its classID. identified by their unique Logical Device Name. The SelectiveAccessDescriptor (if present) contains one accessSelector and one set of AccessParameters The set of AccessParameters contains one data element and one dataType element The PhysicalDevice contains one mRID.docsaved on 14/06/2010 08:33:00 . and the LogicalName of the object. A similar interpretation is used for the other figures in this document. one localName. that in the Management Logical Device. Note. one name and one serialNumber (these are all optional) the attributeID and optionally a • • • • • • Note that the absence of a cardinality (multiplicity) number below an element implies a value of 1. logicalName. one description. The dotted line boxes are optional data elements contained in the message payload. DLMS_COSEM_CIM_profile_report_final.
14 th June 2010 – 15 – DLMS/COSEM/CIM Study Report Figure 3 – XML Schema for GetResponse DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
docsaved on 14/06/2010 08:33:00 . Meter_EndDevice sends the values back to MS-HeadEnd in DLMS notation.14 th June 2010 – 16 – DLMS/COSEM/CIM Study Report Figure 4 – Sequence of message exchange for GetRequest and GetResponse How to read Figure 4: ERP_System sends a GetRequest message to MS_HeadEnd in the prescribed format given by IEC 61968 series. MS_HeadEnd translates the received message into DLMS notation and sends the translated message on to the specified Meter_EndDevice. MS_EndDevice receives the message and performs the required operation to read the specified values in the meter. DLMS_COSEM_CIM_profile_report_final. LogicalDevice and Attributes specified in the message profile GetRequest. It uses the verb CREATE (as defined in 61968 series) to tell MS_HeadEnd system to create a new set of data and to obtain the values from the PhysicalDevice.
DLMS_COSEM_CIM_profile_report_final. The message exchange process is now complete. It uses the verb CREATED (as defined in 61968 series) to tell ERP_System that this is the reply to the original request.14 th June 2010 – 17 – DLMS/COSEM/CIM Study Report MS-HeadEnd translates the received message back into the prescribed format given by IEC 61968 series and sends it on to the ERP_System as a GetResponse message.docsaved on 14/06/2010 08:33:00 .
2 SetRequest and SetResponse Figure 5 – XML Schema for SetRequest DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 18 – DLMS/COSEM/CIM Study Report 8.
14 th June 2010 – 19 – DLMS/COSEM/CIM Study Report Figure 6 – XML Schema for SetResponse DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
14 th June 2010 – 20 – DLMS/COSEM/CIM Study Report Figure 7 – Sequence of message exchange for SetRequest and SetResponse DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 21 – DLMS/COSEM/CIM Study Report 8.3 ActionRequest and ActionResponse Figure 8 – XML Schema for ActionRequest DLMS_COSEM_CIM_profile_report_final.
docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 22 – DLMS/COSEM/CIM Study Report Figure 9 – XML Schema for ActionResponse DLMS_COSEM_CIM_profile_report_final.
docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 23 – DLMS/COSEM/CIM Study Report Figure 10 – Sequence of message exchange for ActionRequest and ActionResponse DLMS_COSEM_CIM_profile_report_final.
docsaved on 14/06/2010 08:33:00 .14 th June 2010 – 24 – DLMS/COSEM/CIM Study Report 8.4 EventNotification Figure 11 – XML Schema for EventNotification DLMS_COSEM_CIM_profile_report_final.
14 th June 2010 – 25 – DLMS/COSEM/CIM Study Report Figure 12 – Sequence of message exchange for EventNotification DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
5 XML Schema of GetRequest - - - - - - - <?xml version="1.ch/TC57/CIM-generic#LogicalDevice.org</xs:documentation> </xs:annotation> <xs:element name="GetRequest" type="m:GetRequest" /> <xs:complexType name="GetRequest"> <xs:sequence> <xs:element name="LogicalDevice" type="m:LogicalDevice" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="LogicalDevice" sawsdl:modelReference="http://iec.classId"> <xs:annotation /> DLMS_COSEM_CIM_profile_report_final.ch/TC57/CIM-generic#CosemObject"> <xs:sequence> <xs:element name="classId" type="xs:long" sawsdl:modelReference="http://iec.w3.au/2005/Message#" xmlns:m="http://iec.0" encoding="UTF-8" ?> <xs:schema xmlns:xs="http://www.CosemObjects"> <xs:annotation /> <xs:complexType sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#CosemObject.ch/TC57/CIM-generic#LogicalDevice"> <xs:annotation> <xs:documentation>at least one Association LN or Association SN object must be present</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="LDN" type="xs:string" sawsdl:modelReference="http://iec.org/2001/XMLSchema" xmlns:a="http://langdale. see http://cimtool.com.ch/TC57/2007/GetRequest#" targetNamespace="http://iec.docsaved on 14/06/2010 08:33:00 .ch/TC57/2007/GetRequest#" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:annotation> <xs:documentation>Generated by CIMTool Beta .au/2005/Message#" xmlns:sawsdl="http://www.14 th June 2010 – 26 – DLMS/COSEM/CIM Study Report 8.org/ns/sawsdl" xmlns="http://langdale.ch/TC57/CIMgeneric#LogicalDevice.LDN"> <xs:annotation /> </xs:element> <xs:element name="CosemObjects" maxOccurs="unbounded" sawsdl:modelReference="http://iec.w3.com.
ch/TC57/CIM-generic#SelectiveAccessDescriptor"> <xs:sequence> <xs:element name="accessSelector" type="xs:int" sawsdl:modelReference="http://iec.version"> <xs:annotation> <xs:documentation>optional if ERP system wants to specify which version this message applies to</xs:documentation> </xs:annotation> </xs:element> <xs:element name="CosemAttributes" maxOccurs="unbounded" sawsdl:modelReference="http://iec.CosemAttributes"> <xs:annotation /> <xs:complexType sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#CosemAttribute.ch/TC57/CIMgeneric#CosemObject.attributeID"> <xs:annotation /> </xs:element> <xs:element name="serviceClass" type="xs:boolean" sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#CosemObject.14 th June 2010 – 27 – DLMS/COSEM/CIM Study Report - - - - - - - </xs:element> <xs:element name="logicalName" type="xs:string" sawsdl:modelReference="http://iec. 0=unconfirmed</xs:documentation> </xs:annotation> </xs:element> name="SelectiveAccessDescriptor" minOccurs="0" sawsdl:modelReference="http://iec.accessSelector"> <xs:annotation /> DLMS_COSEM_CIM_profile_report_final.ch/TC57/CIMgeneric#CosemObject.ch/TC57/CIM<xs:element generic#CosemAttribute.docsaved on 14/06/2010 08:33:00 .logicalName"> <xs:annotation /> </xs:element> <xs:element name="version" type="xs:int" minOccurs="0" sawsdl:modelReference="http://iec.serviceClass"> <xs:annotation> <xs:documentation>values: 1= confirmed.ch/TC57/CIM-generic#CosemAttribute"> <xs:sequence> <xs:element name="attributeID" type="xs:int" sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#SelectiveAccessDescriptor.ch/TC57/CIMgeneric#CosemAttribute.SelectiveAccessDescriptor"> <xs:annotation /> <xs:complexType sawsdl:modelReference="http://iec.
ch/TC57/CIM-generic#CosemData"> <xs:sequence> <xs:element name="data" type="xs:string" sawsdl:modelReference="http://iec.data"> <xs:annotation /> </xs:element> <xs:element name="dataType" type="xs:string" sawsdl:modelReference="http://iec.ch/TC57/CIM-generic#PhysicalDevice"> <xs:sequence> <xs:element name="mRID" type="xs:string" minOccurs="0" sawsdl:modelReference="http://iec.docsaved on 14/06/2010 08:33:00 .AccessParameter"> <xs:annotation /> <xs:complexType sawsdl:modelReference="http://iec.mRID"> <xs:annotation> DLMS_COSEM_CIM_profile_report_final.ch/TC57/CIM-generic#CosemData.14 th June 2010 – 28 – DLMS/COSEM/CIM Study Report - - - - - </xs:element> <xs:element name="AccessParameter" sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#CosemData.ch/TC57/CIMgeneric#LogicalDevice.ch/TC57/CIMgeneric#IdentifiedObject.PhysicalDevice"> <xs:annotation /> <xs:complexType sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#SelectiveAccessDescriptor.dataType"> <xs:annotation /> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="PhysicalDevice" sawsdl:modelReference="http://iec.
It may be non unique and may not correlate to a naming hierarchy.g.serialNumber"> <xs:annotation> <xs:documentation>Serial number of this asset.description"> <xs:annotation> <xs:documentation>The description is a free human readable text describing or naming the object. Substation. the naming hierarchy usually has several levels. use IdentifiedObject. The simplest naming hierarchy has just one parent (the root) giving a flat naming hierarchy.localName shall not be used. Equipment etc. If the uniqueness requirement cannot be met IdentifiedObject.ch/TC57/CIMgeneric#Asset. e.name"> <xs:annotation> <xs:documentation>The name is a free text human readable name of the object. Children of the same parent have names that are unique among them.docsaved on 14/06/2010 08:33:00 .</xs:documentation> </xs:annotation> </xs:element> <xs:element name="description" type="xs:string" minOccurs="0" sawsdl:modelReference="http://iec. then the mRID is globally unique.name instead.14 th June 2010 – 29 – DLMS/COSEM/CIM Study Report - - - - <xs:documentation>A Model Authority issues mRIDs. It is only used with objects organized in a naming hierarchy.ch/TC57/CIMgeneric#IdentifiedObject.localName"> <xs:annotation> <xs:documentation>The localName is a human readable name of the object. Given that each Model Authority has a unique id and this id is part of the mRID. It may be non unique and may not correlate to a naming hierarchy.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="localName" type="xs:string" minOccurs="0" sawsdl:modelReference="http://iec.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="serialNumber" type="xs:string" minOccurs="0" sawsdl:modelReference="http://iec. However.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="name" type="xs:string" minOccurs="0" sawsdl:modelReference="http://iec.ch/TC57/CIMgeneric#IdentifiedObject. VoltageLevel.ch/TC57/CIMgeneric#IdentifiedObject.</xs:documentation> </xs:annotation> </xs:element> DLMS_COSEM_CIM_profile_report_final.
14 th June 2010 – 30 – DLMS/COSEM/CIM Study Report </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:schema> DLMS_COSEM_CIM_profile_report_final.docsaved on 14/06/2010 08:33:00 .
Documents Similar To 61968-9 Message profiles for DLMS
DLMS Meters Testing 30-03-2012.PDF