The DLMS communication survival

Page 1 of 18

The DLMS communication survival kit
This page shortly describes the basic concepts of the DLMS/COSEM model and protocols. It is certainly very incomplete and somewhat over simplified. Still, the presented information and the practical examples should give the minimal necessary knowledge needed to be able to read metering data from a compliant device. It is needless to say that the definitive reference about the COSEM/DLMS model and protocols remains the ''colored books'' (Green Book, Blue Book) of the DLMS User Association.

The Problem
We want to write a program able to read the value of the active energy register of an electricity-meter of this kind...

...using a serial line...

... and the DLMS/COSEM protocol. The problem is not trivial, and to be able to design a solution, we first need to know more about some of the main concepts of the COSEM/DLMS standard.

The Physical Device
The Physical device, is our meter, it supports one or more communication profiles. Currently, the Standard specifies two profiles: the 3-layer, connection oriented HDLC-based profile, and the TCP-UDP/IP based profile. Our device, like many others, uses the HDLC-based profile, it also has a physical address.

The Logical Device
A physical device hosts one or several Logical Devices. A logical device models a specific functionality of the physical device. For example, in a multi-energy meter, one logical device could be an electricity meter, another, a gas-meter etc. Each logical device has an address, called the logical device address.

http://www.icube.ch/DLMSSurvivalKit/dsk1.html

6/28/2011

we search for codes with ''active power'' and ''time integral'': http://www. OBIS allows to uniquely identify each of the many data items used in the energy metering equipment.icube. it has to contain a description of all the logical devices available in the physical meter. we will ignore the methods and just focus on the attributes since they contain the values that we are interested in.html 6/28/2011 . we have a simple tool. The Logical Name A logical name consists of a string of 6 values defined according to a system called OBIS for Object Identification System. what is the logical name of the active energy ''object''? Using OBISHelper. Since a logical device may contain many objects of different classes. Fortunately. how do we read the value of the active energy out of the logical devices? The COSEM Classes and object instances A logical device is a container for COSEM objects. A COSEM object is simply a structured piece of information with attributes and methods. but. with addresses 1. all physical devices have to host a special logical device called the management logical device. All objects that share the same structure are of the same COSEM class. For the moment. A physical device hosting 3 logical devices. then how do we identify the information that we are interested in? This is possible because. called OBISHelper. able to find and identify the OBIS codes in a more comfortable way. the first attribute of each object is its Logical Name. at the minimum. with the predefined address 1. with their logical addresses and names.The DLMS communication survival Page 2 of 18 According to the Standard.ch/DLMSSurvivalKit/dsk1. There are many COSEM classes (about 50) because there are many different objects kinds. Then. by definition. The management logical device itself may contain a lot of information. The list of all possible OBIS codes (OBIS code is another name for logical name) is published by the DLMS Users Association on their web site in a dense Excel document.2 and 3 So.

ch/DLMSSurvivalKit/dsk1.255.0.0.0. Each list item consists of the name and the address of a logical device.0. with the predefined name 0. at address 1.255. the association object has the predefined logical name 0.0.1.40. The mandatory elements of devices To summarize: several mandatory elements allow us to get the necessary information about the content of a physical device: Each physical device has a management logical device.0. with the predefined name 0.40.8. How can we know if such an object exists in our electricity-meter? The Association object Each logical device contains at least one object of class Association LN or Association SN. For the moment it suffices to say that the association object has an attribute (attribute 2) called the object list containing the list of all objects available in the logical device.icube. This list is the second attribute of the object of class SAP Assignment .1.41. So finally.0.0. We will come back later to these strange names.The DLMS communication survival Page 3 of 18 It appears that the required OBIS code should be (in the standard notation) 1.8.255.html 6/28/2011 .0.x.255. Each list item consists (among others) of the logical name and the class of an object. Each logical device hosts a list of all its available objects. This list is the second attribute of the object of class Association. how do we read the active energy register? The Client-Server model http://www. A management logical device hosts a list of all the available logical devices in the physical device.0. we can find out what objects are available in a logical device just by reading its object list. for example 1. Therefore.255.1. Furthermore.0.

each of client's layer exchanges data with the peer server's layer. if you don't have the required credentials. The addressing In the COSEM/DLMS communication framework. Nevertheless. The server address is the doublet: { address of the logical device.icube. before being able to send such requests. the HDLC layer and the Application layer. By definition.8. others are far more restrictive. There are several mechanisms to control the access rights. There can be other kind of clients. The client sends requests and the server answers responses.255'' and the server would answer ''1789. for example a Data Collection System.html 6/28/2011 .0. The meter knows you by your client address and. For example. but you will also have to provide somewhere a password or even more complex security elements. you will not even be authorized to read the active energy! Connecting the layers We assume that our meter implements the 3-layer. the client has first to establish a connection with the other side. each side of the connection has an address. Some manufacturers allow public clients to read many objects. though. a public client is always authorized to access the logical management device.ch/DLMSSurvivalKit/dsk1. a Manufacturer. The Standard states that a client with address 16 (decimal) is a public client. The Access Rights Of course. the client address is a byte value. our application would send something like ''read the object 1. The simplest one is based on the following rule: your access rights depend on who you are. the addresses of those clients are not defined in the Standard. according to that address.1. it will present you (via the Association object) just the objects that you are allowed to read (or write). The 3 layers of the HDLC profile are the Physical layer. Still.The DLMS communication survival Page 4 of 18 The data exchange between our program and the meter uses the client-server model. a Consumer. then. connection-oriented. not everybody is allowed to read or write any value in a meter. HDLCbased profile. as we have seen.8 kWh''. the value of the client address determines also the real nature of the client. Furthermore.0. If you are not a public client. address of the physical device }. therefore an addressing system is needed. But. According to the Open Systems Interconnection (OSI) model. you will have more privileges. The physical layer http://www. In some cases. Our application is the client and the meter plays the role of server. the other side is not just a physical device but a collection of logical devices.

The data elements exchanged by the HDLC peer layers are called HDLC-frames. in our target program. Establishes an HDLC connection with the peer layer.to there.. The connection between the two peers layers is accomplished. In some cases. . it boils down to a simple (3-wires) serial cable between a COM port of our PC and the appropriate connector of our meter. The HDLC layer is connection oriented. The HDLC layer The next layer is the HDLC layer. in a point-to-point configuration with a single meter.. the lower part can be omitted. http://www. however. we don't care about the physical address of the meter... We will use 16 (decimal) which means public client. DataReceived). it identifies the client. HDLCDisconnect(). In our practical example. Note. and the lower part is the physical device address. Then... For example. We will not go into the details of the HDLC exchanges. Instead.. it monitors various timeouts. The whole ''two ways alternate'' HDLC layer traffic is rather complex: the HDLC layer is able to segment long data into information frames (I-Frame) and reassemble information frames into long data. it verifies the sequencing of frames.icube. It means that the peer HDLC layers must first build a logical connection with each other by exchanging and negotiating some connection parameters. they can exchange data. it checks the frames integrity using CRCs. The server (or meter) MAC address is divided in two parts. it corresponds to the layers 2 to 4 of the OSI model. HDLCSendReceive(DataToSend.. There are several parameters to set before calling the HDLC routines.. the most important are the HDLC-addresses (also called MAC addresses). the upper part is the logical device address. . From here.by mechanically connecting the two sides.The DLMS communication survival Page 5 of 18 The lowest layer is the physical layer. that implements the whole HDLC traffic and just exposes three routines: HDLCConnect(). The client MAC address is a byte value. as long as needed and finally they close the connection. we will use our ezhdlc library. that this feature is not implemented by all manufacturers.html 6/28/2011 . Sends data to the peer layer and receives the response from the peer layer.ch/DLMSSurvivalKit/dsk1.. Closes the connection. it is the layer 1 in the OSI model. .

the client address is always a byte. Four bytes addressing. From now on. There is an upper address on 1 byte and a lower address on 1 byte. The Application layer The last layer of the 3-layers profile is the Application layer. Note that not all manufacturers support the three variants. we send an Association request and we expect an Association response. if the association has been correctly established. There is just an upper address. All the requests and their corresponding responses are defined in the Standard using http://www. the library routine HDLCConnect sends a SNRM-frame to the server. The lower address is not specified (one byte addressing). One byte addressing In XmlDemo. The next picture shows the resulting frame exchange. After having connected the physical layer and the HDLC layer.icube. In the OSI terminology. the server address consists of two parts and there are three variants: One byte addressing.ch/DLMSSurvivalKit/dsk1.html 6/28/2011 . Therefore. when we click ''Connect''. Two bytes addressing. Finally. It is a byte value. we have to connect the Application layer. Then. to establish an association. The green frame is the SNRM-frame and the red is the UA-frame: The connection of the peer HDLC-Layers This frame exchange establishes the HDLC layer connection. we continue to send requests and receive responses until we are finished. XMLDemo parameters. data frames (I-Frame) can be exchanged between the two sides. this kind of connection is called an Association. The server responds with an UA-frame. we release the association by disconnecting the HDLC-Layer.The DLMS communication survival Page 6 of 18 To summarize: on the HDLC layer. There is an upper address on 2 bytes and a lower address on two bytes. Here is an example of the HDLC-layer parameters as set in the XmlDemo application: We set 10 (hexa) for the client address (public client) and 1 for the logical device address (management logical device).

we will use our xmlpdu library. when the meter responds with another bytes sequence..The DLMS communication survival Page 7 of 18 the ASN. we translate it back to XML with PduToXml(). Decodes the PDU into a sequence of XML lines..1 notation. like in the following: <ReadRequest Qty="0001" > <ParameterisedAccess> <VariableName Value="60E8" /> <Selector Value="01" /> <Parameter> <Structure Qty="0004" > <Structure Qty="0004" > <LongUnsigned Value="0008" /> <OctetString Value="0000010000FF" /> <Integer Value="02" /> <LongUnsigned Value="0000" /> </Structure> <OctetString Value="07D8021DFF0C130DFF8000FF" /> <OctetString Value="07D90A1DFF0B3622FF8000FF" /> <Array Qty="0000" > </Array> </Structure> </Parameter> </ParameterisedAccess> </ReadRequest> This is a ReadRequest element. For example. Encode the XML to PDU using XmlToPdu().icube. the XML lines cannot be sent directly. the encoded PDU of the above ReadRequest is this bytes sequence. parse the XML of the response. using HDLCSendReceive(). They must be first encoded into a byte sequence known as a protocol data unit (PDU). To summarize: all request/response exchanges follow these five steps: Have the XML of a request.. Encodes a sequence of XML lines into a PDU PduToXml(Pdu. the specific instances of requests and responses are presented in a XML notation. However. How can we send such a request to the meter? Of course. Decode the response PDU into XML with PduToXml(). Then. Instead. XmlLines). 05 01 04 60 E8 01 02 04 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 09 0C 07 D8 02 1D FF 0C 13 0D FF 80 00 FF 09 0C 07 D9 0A 1D FF 0B 36 22 FF 80 00 FF 01 00 . Finally. Send the PDU to the other side and get a response PDU. Finally. in our target program. Pdu). we parse the received XML using any appropriate method. that implements the encoding and decoding procedures. according to the rules specified in the Standard. by calling HDLCSendReceive() and pass the bytes sequence as parameter.that we send to the meter using the HDLC layer.. http://www.ch/DLMSSurvivalKit/dsk1.html 6/28/2011 . in our tools and libraries. We will not go into the details of the encoding. The library exposes two routines: XmlToPdu(XmlLines.

that differ in the way the data is addressed (or referenced). if we want to read the energy register? The AssociationRequest The AssociationRequest is the first request that we have to send in order to establish the Association. In our example. Rather.html 6/28/2011 . Therefore. In the short name reference context (or SN) the data is referenced (addressed) by a unique 16 bit integer. The context cannot be freely chosen by the client. it is fixed by the meter's manufacturer. the relevant services are Get (to read data) and Set (to write data) and in SN context the services are Read and Write. It looks like this: <AssociationRequest> <ApplicationContextName Value="SN" /> <InitiateRequest> <ProposedDlmsVersionNumber Value="06" /> <ProposedConformance> <ConformanceBit Name="ParametrizedAccess" /> <ConformanceBit Name="MultipleReferences" /> <ConformanceBit Name="Write" /> <ConformanceBit Name="Read" /> </ProposedConformance> <ProposedMaxPduSize Value="FFFF" /> </InitiateRequest> </AssociationRequest> The application context name The exchanges with the meter can take place in two flavors called ''contexts''. Furthermore. it is the version number of the DLMS protocol. The Proposed Dlms Version Number This value is currently fixed to 6. The Proposed Conformance This is a list of capabilities that we are expecting the meter to have. the services used to access the data are different in each context. In the logical name reference context (or LN) the data is referenced by the logical name (OBIS code). For a LN meter we would have used this kind of AssociationRequest: <AssociationRequest> <ApplicationContextName Value="LN" /> <InitiateRequest> <ProposedDlmsVersionNumber Value="06" /> <ProposedConformance> <ConformanceBit Name="Action" /> http://www. since we are in SN context. the meter's context must be known beforehand.icube. ParametrizedAccess: to allow to read subsets of large attributes. MultipleReferences: to be able to handle several reads (or writes) at once.ch/DLMSSurvivalKit/dsk1. Write: to support the write service. it is a characteristic of its implementation. we are expecting the following capabilities: Read : to support the read service. In LN context.The DLMS communication survival Page 8 of 18 To come back to the problem: what requests will we have to send and what responses will we expect.

html 6/28/2011 . Any other value indicates a failure. then the requested capabilities are different.ch/DLMSSurvivalKit/dsk1. The value "FFFF" means "no limits".icube. The Negotiated Conformance The negotiated conformance is a list of capabilities that the meter implements. The Negotiated MaxPdu Size http://www. For example. It contains all the capabilities that we have requested in the negotiated conformance of the AssociationRequest except the capabilities which are NOT supported by the meter. The Proposed MaxPdu Size is the size of the longest PDU that the client is able to store.The DLMS communication survival Page 9 of 18 <ConformanceBit Name="EventNotification" /> <ConformanceBit Name="SelectiveAccess" /> <ConformanceBit Name="Set" /> <ConformanceBit Name="Get" /> <ConformanceBit Name="BlockTransferWithAction" /> <ConformanceBit Name="BlockTransferWithSet" /> <ConformanceBit Name="BlockTransferWithGet" /> <ConformanceBit Name="Attribute0SupportedWithGet" /> <ConformanceBit Name="PriorityMgmtSupported" /> <ConformanceBit Name="Attribute0SupportedWithSet" /> </ProposedConformance> <ProposedMaxPduSize Value="FFFF" /> </InitiateRequest> </AssociationRequest> As a LN meter supports different service than a SN meter. Otherwise the two requests are the same. The AssociationResponse The meter's response to an AssociationRequest is an AssociationResponse. a SN meter would send this response: <AssociationResponse> <ApplicationContextName Value="SN" /> <AssociationResult Value="00" /> <ResultSourceDiagnostic> <AcseServiceUser Value="00" /> </ResultSourceDiagnostic> <InitiateResponse> <NegotiatedDlmsVersionNumber Value="06" /> <NegotiatedConformance> <ConformanceBit Name="ParametrizedAccess" /> <ConformanceBit Name="MultipleReferences" /> <ConformanceBit Name="Write" /> <ConformanceBit Name="Read" /> </NegotiatedConformance> <NegotiatedMaxPduSize Value="0960" /> <VaaName Value="FA00" /> </InitiateResponse> </AssociationResponse> The Association Result A value of zero indicates that the request succeeded.

If the association fails.8. therefore "Qty" is set to 1.ch/DLMSSurvivalKit/dsk1. The VaaName is the short name of the (current) association object. The (short name) reference of the attribute we want to read is the value of the element "VariableName". this name is defined as ''FA00''. it is called the Object List and it is also the second attribute of the (current) Association object. in the example. we just want to read one single attribute. Here is an example: <ReadRequest Qty="0001" > <VariableName Value="2BC8" /> </ReadRequest> A ReadRequest allows to read several attributes at once. then. In fact. A client should never send a PDU longer than this value. Our goal is to read the value of the object with logical name 1.icube. the object list doesn't really contain the short name of all attributes but rather one single base name for each object instance. This is a very simple service. how do we know the relationship (mapping) between the logical names and the short names? The mapping between SN and LN The mapping information between the short names and the logical names is directly available from the meter itself.1. The value of the AcseServiceUser element is an error code. then the response will look like this: <AssociationResponse> <ApplicationContextName Value="LN" /> <AssociationResult Value="01" /> <ResultSourceDiagnostic> <AcseServiceUser Value="0B" /> </ResultSourceDiagnostic> <InitiateResponse> <NegotiatedDlmsVersionNumber Value="06" /> <NegotiatedConformance> <ConformanceBit Name="Action" /> <ConformanceBit Name="SelectiveAccess" /> <ConformanceBit Name="Set" /> <ConformanceBit Name="Get" /> <ConformanceBit Name="BlockTransferWithGet" /> <ConformanceBit Name="Attribute0SupportedWithGet" /> </NegotiatedConformance> <NegotiatedMaxPduSize Value="2134" /> <VaaName Value="0007" /> </InitiateResponse> </AssociationResponse> The association result is not null. still. http://www. How to read data from a SN meter The service used to read data from a short name referencing meter is the ReadRequest.0.1.255.The DLMS communication survival Page 10 of 18 is the size of the longest PDU that the meter is able to store.html 6/28/2011 . But what is then the base name of the Association object itself? Fortunately. We will ignore it.

causes this response: <ReadResponse Qty="0001" > <Data> <OctetString Value="0000280000FF" /> </Data> </ReadResponse> By definition. Let's read the object list: <ReadRequest Qty="0001" > <VariableName Value="FA08" /> </ReadRequest> Here is the response: <ReadResponse Qty="0001" > <Data> <Array Qty="00F0" > <Structure Qty="0004" > <Long Value="00C8" /> <LongUnsigned Value="2716" /> <Unsigned Value="00" /> <OctetString Value="0000F00D00FF" /> </Structure> . Then. for example. Therefore. the responded OctetString is simply the logical name of the current Association: What are the short names of the other attributes? By definition. http://www.The DLMS communication survival Page 11 of 18 From the base name to the short name By definition... <ReadRequest Qty="0001" > <VariableName Value="FA00" /> </ReadRequest> .icube. Therefore its short name is FA00 + 8 = FA08.. the first attribute (attribute 1) of any object instance is its logical name.. the base name of an object instance is also the short name of its first attribute. the object list is the attribute 2 of the current association. the following request....ch/DLMSSurvivalKit/dsk1. the short name of attribute N is given by: ShortNameOfAttributeN = BaseName + 8 * (N-1) According to the standard.html 6/28/2011 .

.. Finally. but we still don't have the ''real'' value. There are many classes in COSEM. Class 3 is the Register Class. we know that the active energy (OBIS 1.1.icube. therefore the short name of the active energy value is 1770 + 8 = 1778. Each entry describes one object instance using a structure of 4 elements..ch/DLMSSurvivalKit/dsk1. The COSEM/DLMS Blue Book shows us that the layout of the Register Class is: This tells us that the value attribute is attribute 2. Let's read the value: <ReadRequest Qty="0001" > <VariableName Value="1778" /> </ReadRequest> <ReadResponse Qty="0001" > <Data> <Long64 Value="000000000000017D" /> </Data> </ReadResponse> The response gives the ''digits'' of value of the active energy. </Array> </Data> </ReadResponse> The object list is an array of 240 (F0) entries.8. Let's consider the item in blue: The first element is the base name of the object instance: "1770" The second element is the class identifier of the object instance. We also need to read the third attribute (scaler_unit): <ReadRequest Qty="0001" > <VariableName Value="1780" /> </ReadRequest> <ReadResponse Qty="0001" > <Data> http://www.0.The DLMS communication survival Page 12 of 18 <Structure Qty="0004" > <Long Value="1770" /> <LongUnsigned Value="0003" /> <Unsigned Value="00" /> <OctetString Value="0101010800FF" /> </Structure> .1.255) is an object instance of class 3 with a base name of 1770. here it is version 0.17D (hexa) or 381 (dec). the fourth element is the logical name of the object instance: "0101010800FF" Thanks to the object list.html 6/28/2011 . The third element is the class version of the class of the object instance.

0381kWh Since our meter supports ''MultipleReferences''. There are several variants of GetRequest. Finally. we will always set InvokeIdAndPriority to "C1". we can also read the attributes 2 and 3 at once: <ReadRequest Qty="0002" > <VariableName Value="1778" /> <VariableName Value="1780" /> </ReadRequest> <ReadResponse Qty="0002" > <Data> <Long64 Value="000000000000017D" /> </Data> <Data> <Structure Qty="0002" > <Integer Value="FF" /> <Enum Value="1E" /> </Structure> </Data> </ReadResponse> How to read data from a LN meter In logical name referencing. unit = 1E = Wh (according to the Blue Book). AttributeDescriptor This 3 elements structure identifies the object instance and the attribute that we want http://www. Therefore.ch/DLMSSurvivalKit/dsk1. scaler = -1. Here it is: <GetRequest> <GetRequestNormal> <InvokeIdAndPriority Value="C1" /> <AttributeDescriptor> <ClassId Value="0003" /> <InstanceId Value="0101010800FF" /> <AttributeId Value="02" /> </AttributeDescriptor> </GetRequestNormal> </GetRequest> InvokeIdAndPriority is a byte value. The bit 6 selects the service class and will be set to 1. we use the Get service to read the data. we have it: the value of the active energy is: ActiveEnergy = 381 * 10-1 = 38. The bit 7 selects the priority.icube.1 Wh = 0. the simplest is the GetRequestNormal.html 6/28/2011 . 1 means high priority. In our examples.The DLMS communication survival Page 13 of 18 <Structure Qty="0002" > <Integer Value="FF" /> <Enum Value="1E" /> </Structure> </Data> </ReadResponse> The scaler-unit is a structure of two elements. The first element is an integer power of 10 (scaler). The remaining bits are an unsigned value identifying this particular invocation of GetRequestNormal. The second element gives the measuring unit.

The AttributeId can be found in the Blue Book.html 6/28/2011 . Therefore. a GetResponseNormal would result in a very long PDU. and.255. </Array> </Data> </Result> </GetResponsenormal> </GetResponse> This object list is very small..0. According to the Blue Book. Each entry describes one object instance using a structure of 4 elements. as here: <GetResponse> <GetResponsenormal> <InvokeIdAndPriority Value="C1" /> <Result> <Data> <Array Qty="0002" > <Structure Qty="0004" > <LongUnsigned Value="0001" /> <Unsigned Value="00" /> <OctetString Value="00002A0000FF" /> <Structure Qty="0002" > <Array Qty="0002" > <Structure Qty="0003" > <Integer Value="01" /> <Enum Value="01" /> <NullData /> </Structure> <Structure Qty="0003" > <Integer Value="02" /> <Enum Value="01" /> <NullData /> </Structure> </Array> <Array Qty="0000" > </Array> </Structure> </Structure> . AttributeId is the attribute number of the attribute we want to read.40. The ClassId and the InstanceId can be found in the object list. InstanceId is the logical name of that object read. when the meter has many objects. the ClassId is 15 (Association LN).The DLMS communication survival Page 14 of 18 to read: ClassId is the class identifier of the object that hosts the attribute we want to read... the GetRequestNormal to read the object list looks like this: <GetRequest> <GetRequestNormal> <InvokeIdAndPriority Value="C1" /> <AttributeDescriptor> <ClassId Value="000E" /> <InstanceId Value="0000280000FF" /> <AttributeId Value="02" /> </AttributeDescriptor> </GetRequestNormal> </GetRequest> The response can be a GetResponseNormal. provided that the http://www. the object list is the attribute 2 of the object 0.0.0. However. Therefore.ch/DLMSSurvivalKit/dsk1.icube. It has only two entries.

Finally.. the RawData (in the inner Result) is an octet string containing the first n bytes of our data. it will send the data in several blocks rather than in one large single chunk. we save the RawData.icube. In that case the response will be: <GetResponse> <GetResponsewithDataBlock> <InvokeIdAndPriority Value="C1" /> <Result> <LastBlock Value="00" /> <BlockNumber Value="00000001" /> <Result> <RawData Value="018201B3020412. and ask for the next block using GetRequestForNextDataBlock: <GetRequest> <GetRequestForNextDataBlock> <InvokeIdAndPriority Value="C1" /> <BlockNumber Value="00000001" /> </GetRequestForNextDataBlock> </GetRequest> InvokeIdAndPriority stays the same. BlockNumber is an unsigned value and is the number of this block. The outer Result is a structure of 3 elements: LastBlock is a boolean which indicates if this block is the last block of the block transfer (00 = false). we will repeat the process until we have received the last block (LastBlock = true): <GetResponse> <GetResponsewithDataBlock> <InvokeIdAndPriority Value="81" /> http://www. This feature is called ''block transfer''.html 6/28/2011 .6020002031601000100" /> </Result> </Result> </GetResponsewithDataBlock> </GetResponse> The element InvokeIdAndPriority is the same as in the request.The DLMS communication survival Page 15 of 18 meter has the capability BlockTransferWithGet (which is listed in the NegotiatedConformance of the AssociationResponse). BlockNumber is the number of the last block that we have received. The response to this request will be another GetResponseWithDataBlock (BlockNumber 2) and we will right-concatenate its RawData to the T: T := T + RawData Then. Having the first block. say T. it is indeed a data segmentation mechanism supported in the application layer and we have to handle it in details.ch/DLMSSurvivalKit/dsk1.. LN Block Transfer When a LN meter receives a GetRequestNormal (for example to read the object list) it may decide to respond with a GetResponseNormal or it may rather switch to block transfer and respond with a GetResponseWithDataBlock.

There is one array entry for each object instance. To convert T to XML we left-concatenate it with the byte FF: T := FF + T and pass it to PduToXml.601000100" /> </Result> </Result> </GetResponsewithDataBlock> </GetResponse> Here again. T := T + RawData The final data T will be a very long PDU. <Structure Qty="0004" > <LongUnsigned Value="0003" /> <Unsigned Value="00" /> <OctetString Value="0101010800FF" /> <Structure Qty="0002" > <Array Qty="0003" > <Structure Qty="0003" > <Integer Value="01" /> <Enum Value="01" /> <NullData /> </Structure> <Structure Qty="0003" > <Integer Value="02" /> <Enum Value="01" /> <NullData /> </Structure> <Structure Qty="0003" > <Integer Value="03" /> <Enum Value="01" /> <NullData /> </Structure> </Array> <Array Qty="0000" > </Array> </Structure> </Structure> . Each entry is a structure of 4 elements: http://www...The DLMS communication survival Page 16 of 18 <Result> <LastBlock Value="01" /> <BlockNumber Value="00000006" /> <Result> <RawData Value="02041200071...icube. </Array> </Data> The resulting data is an array with (possibly) many elements. The resulting XML will look like this: <Data> <Array Qty="01B3" > .html 6/28/2011 .. we right-concatenate the RawData to the data received so far.ch/DLMSSurvivalKit/dsk1....

Finally.icube.html 6/28/2011 . the fourth element lists the access rights of the attributes and methods of the instance. we can send a GetRequestNormal to read the ''digits'' of the energy register: <GetRequest> <GetRequestNormal> <InvokeIdAndPriority Value="C1" /> <AttributeDescriptor> <ClassId Value="0003" /> <InstanceId Value="0101010800FF" /> <AttributeId Value="02" /> </AttributeDescriptor> </GetRequestNormal> </GetRequest> Here is the response: <GetResponse> <GetResponsenormal> <InvokeIdAndPriority Value="C1" /> <Result> <Data> <DoubleLongUnsigned Value="000007D3" /> </Data> </Result> </GetResponsenormal> </GetResponse> We read the scaler with this request: <GetRequest> <GetRequestNormal> <InvokeIdAndPriority Value="C1" /> <AttributeDescriptor> <ClassId Value="0003" /> <InstanceId Value="0101010800FF" /> <AttributeId Value="03" /> </AttributeDescriptor> </GetRequestNormal> </GetRequest> And the response is: <GetResponse> <GetResponsenormal> <InvokeIdAndPriority Value="C1" /> <Result> <Data> <Structure Qty="0002" > <Integer Value="FE" /> <Enum Value="1E" /> </Structure> </Data> </Result> </GetResponsenormal> </GetResponse> Finally the active energy is: http://www.ch/DLMSSurvivalKit/dsk1.The DLMS communication survival Page 17 of 18 The first element (LongUnsigned) is the ClassId of the instance. as we know the parameters. Finally. The third element is the logical name of the instance. The second element (Unsigned) is the version number of the class of the instance.

The DLMS communication survival Page 18 of 18 ActiveEnergy = 2003 * 10-2 = 20.02003kWh icube software route d'Eclagnens 5 1376 Goumoens-la-Ville Switzerland Home infos@icube.html 6/28/2011 .icube.ch/DLMSSurvivalKit/dsk1.ch http://www.03 Wh = 0.

Sign up to vote on this title
UsefulNot useful