1.IEC 62056-21 E模式通信

1. IEC 62056-21 E模式通信流程 4

2. HDLC帧格式 5

2.1. 标志域 5

2.2. 帧格式域 5

2.3. 地址域 5

2.4. 控制域格式 6

2.5. 头校验序列（HCS）域 8

2.6. 信息域 8

2.7. 帧校验序列（FCS）域 8

3. 链路层链接与断开 9

3.1. 链路层的链接 9

3.2. 链路层的断开 10

4. 应用层 11

4.1. 应用层的链接 11

4.1.1. 编码规则 11

4.1.2. AARQ APDU和AARE APDU规范 11

4.1.3. AARQ-pdu的编码例子 13

4.1.4. AARE-pdu的编码的例子，成功案例: 16

4.1.5. AARE-pdu例子的编码, 失败1的案例 19

4.1.6. AARE-pdu的编码的例子, 失败2的案例 20

4.1.7. 应用层链接失败原因（几乎包含了APPL_OPEN的所有测试案例） 23

4.1.8. 帧实例 24

4.2. 读操作(Get) 25

4.2.1. Get. Request 25

4.2.2. Get. Response 26

4.2.3. 读数据块 29

4.2.4. 读数据不成功情况的典型原因 30

4.3. 写操作(Set) 30

4.3.1. Set. Request 30

4.3.2. Set. Response 31

4.3.3. 设置数据块 33

4.3.4. 写数据不成功情况的典型原因 34

4.4. 方法操作(Action) 34

4.4.1. ACTION. Request 34

4.4.2. ACTION. Response 35

4.5. 事件上报(Event notification) 36

4.5.1. 客户端触发方式 36

4.5.2. 直接上报 36

5. 引用标准 37

IEC 62056-21 E模式通信流程

DLMS/COSEM协议中将Communication_profile分为TCP_profile和HDLC_profile两种，而使用HDLC_profile的又分为E模式和直接HDLC，两者的唯一的区别是E模式有波特率300bps转到Zpbs的握手过程，而直接HDLC直接进入波特率Z下通信。下图为电能表在IEC62056-21 E模式下正常工作时的通信流程：

整个通信过程为C/S模式，表计充当服务端，HHU为客户端。每一次通信过程由客户端发起，服务端应答。

HDLC帧格式

IEC62056-21 E模式中通信链路帧采用HDLC帧格式，除信息域按其指定格式外，其他域均为16进制传送，其格式如下：

标志

帧格式

目的地址

源地址

控制

HCS

信息

FCS

标志

标志域

标志域的长度为一字节，值为7EH。当两个或多个帧连续传输时，这一个标志既要用作前一帧的结束标志，又要用作下一个帧的开始标志，如图11所示。

注：当两个传输的字符之间的时段没有超过指定的最大内部字节周期时，帧可以连续传输。

7E

帧 I

7E

帧 I+1

7E

帧 I+2

7E

 

帧格式域

帧格式域的长度为两个字节，它由三个子域组成：Frame_type子域(4 bit)，分段位(S, 1 bit)和帧长度子域(11 bit)，见图12。

   MSB     LSB

1

0

1

0

S

L

L

L

L

L

L

L

L

L

L

L

格式类型子域的值为1010（二进制）。

分段位S表示是否有后续帧，如果服务端给客户端传送的数据能在一帧内传送完，那么S=0，如果有后续帧那么S=1。

长度子域的值是除两个7E标志之外的8位位组数。在一般情况下，帧长度不会超过256，因此帧格式域第一个字节为 A0或者A8 ，第二个字节表示该帧的长度。

地址域

这个帧有两个地址域：一个目的HDLC地址和一个源HDLC地址。根据数据的传输方向，客户机端地址和服务器地址都可以是目标地址或源地址。

客户机端地址总是用一个字节表示。扩展地址的使用把客户机地址的范围限制在128。

在服务器端，为了能在一个物理设备内寻址一个以上的逻辑装置并且支持多站配置，可以将HDLC地址分为两部分。 一部分称为“高端HDLC地址”用于逻辑设备（一个物理设备内可独立寻址的实体）寻址，而第二部分——“低端HDCL地址”将用于物理设备（多站配置的一个物理设备）寻址。高端HDLC地址总是存在，而低端HDCL地址在不需要时可不用。

HDLC地址扩展机制应用于以上两种地址域。这种地址扩展说明可变长度的地址域，但是考虑到该协议，一个完整的HDLC地址域的长度被限制为一字节，两字节或四字节如下：

• 一字节：只有高端HDLC地址存在。
• 两字节：一字节高端HDLC地址和一字节低端HDLC地址。
• 四字节：两字节高端HDLC地址和两字节低端HDLC地址。

上述三种情况在下图说明。

一字节地址结构：

                     LSB

高端HDLC地址

1

两字节地址结构：

                  LSB               LSB

高端HDLC地址

0

低端HDLC地址

1

第一字节             第二字节   

四字节地址结构：

                      LSB                  LSB               LSB                LSB

高端HDLC	0	高端HDLC	0	低端HDLC	0	低端HDLC	1
高字节		低字节		高字节		高字节

第一字节             第二字节               第三字节               第四字节

这种可变长度HDLC地址结构为每字节保留了一位来标示所给字节是最后一字节还是有字节跟随。这意味着一字节地址的地址范围是0…0x7F，两字节地址的地址范围是0…0x3FFF。

单独的，多播及广播的寻址可由高端HDLC地址和低端HDLC地址方便提供。

例如，一个HDLC帧以下列地址从客户机端发送到服务器端： 

客户HDLC地址 = 3AH = 00111010B

服务器HDLC地址（用四字节寻址）

低端HDLC地址= 3FFFH = 0011111111111111B   ALL_STATION（广播）地址

高端HDLC地址 = 1234H = 0001001000110100B   

消息地址域应包含以下8位字组：

服务器地址				客户机地址
高端HDLC,高字节	高端HDLC,低字节	低端HDLC,高字节	低端HDLC,低字节	HDLC 地址
LSB	LSB	LSB	LSB	LSB
0 1 0 0 1 0 0   0	0 1 1 0 1 0 0    0	1 1 1 1 1 1 1    0	1 1 1 1 1 1 1    1	0 1 1 1 0 1 0  1
第一字节	第二字节	第三字节	第四字节	第五字节
目的地址				源地址
4868FEFF				75

控制域格式

命令/应答帧控制字段的编码方式为模式8，如ISO/IEC 13239的5.5及下表规定。

表7 控制字段格式

MSB      LSB

I	R  R  R  P/F  S  S  S  0
RR	R  R  R  P/F  0  0  0  1
RNR	R  R  R  P/F  0  1  0  1
SNRM	1  0   0   P   0  0  1  1
DISC	0  1   0   P   0  0  1  1
UA	0  1   1   F   0  0  1  1
DM	0  0   0   F   1  1  1  1
FRMR	1  0   0   F   0  1  1  1
UI	0  0   0  P/F  0  0  1  1

这里RRR是接收序列号N(R)，SSS是发送序列号N(S)，P/F是查询/结束位。

链路层链接好即SNRM UA帧后，RRR和SSS均为000，发送一帧I帧SSS加1，接收到一帧I帧RRR加1，客户端和服务端都是如此。P/F标志位中P是对客户端而言的，需要响应P=1，那么广播帧时P=0；F是对服务端而言的，F表示发送是否结束，也就是是不是没有后续帧，F=1表示有后续帧，因此当客户端收到服务端发送来的帧格式域中S=1和此处的F=1的帧时，需回应RR帧等待接收未接收完的数据。

例如：

//SNRM帧 100P0011,因需要响应，P=1，所以控制字为93

客户端:7E A0 0A 48 68 FE FF 75 93 D8 F8 7E

//UA帧 011P0011,因需要响应，F=1，所以控制字为73

服务端:7E A0 21 75 48 68 FE FF 73 7C 16 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E 

//AARQ帧（属于I类型）RRR=0，SSS=0，P=1，所以控制字为10 

客户端:7E A0 46 48 68 FE FF 75 10 05 C1 E6 E6 00 60 35 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 41 42 43 44 45 46 47 48 BE 10 04 0E 01 00 00 00 06 5F 04 00 00 00 14 00 00 BD BF 7E 

//AARE帧（属于I类型）RRR=1，SSS=0，F=1，所以控制字为30

服务端:7E A0 52 75 48 68 FE FF 30 95 39 E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 41 42 43 44 45 46 47 48 BE 0F 04 0D 08 00 06 5F 04 00 00 00 14 21 34 00 07 14 53 7E 

//GET.request（属于I类）RRR=1，SSS=1，P=1，所以控制字为32

客户端:7E A0 1C 48 68 FE FF 75 32 0E 3B E6 E6 00 C0 01 81 00 07 00 00 63 01 00 FF 00 02 DE 82 7E 

//GET.response（属于I类）RRR=2，SSS=1，F=0，所以控制字为52；（S=1，所以帧格式为A8）

服务端:7E A8 8C 75 48 68 FE FF 52 CE 26 E6 E7 00 C4 01 81 00 01 22 02 06 02 02 09 0C 07 D3 06 09 FF 09 1D 0D FF FF FF FF 04 06 40 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 83 9E 7E 

//RR帧 由于上面服务端回的帧中F=0 S=0即有后续帧，所以此处客户端应回应RR帧等待服务端的后续帧

RRR=2，P=0，所以控制字为51；

客户端:7E A0 0A 48 68 FE FF 75 51 14 E4 7E 

//GET.response的后续帧 RRR=2，SSS=2，F=0，所以控制字为54；（S=1，所以帧格式为A8）

服务端:7E A8 8C 75 48 68 FE FF 54 F8 43 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 F9 31 7E 

//RR帧 由于上面服务端回的帧中F=0 S=0即有后续帧，所以此处客户端应回应RR帧等待服务端的后续帧

RRR=2，P=0，所以控制字为71

客户端:7E A0 0A 48 68 FE FF 75 71 16 C5 7E 

//GET.response的后续帧 RRR=2，SSS=3，F=0，所以控制字为56；（S=1，所以帧格式为A8）

服务端:7E A8 8C 75 48 68 FE FF 56 EA 60 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 02 02 09 0C FF FF FF FF FF 0F 08 34 FF FF FF FF 04 06 40 02 02 09 0C FF FF FF FF FF 0F 0E 1F FF FF FF FF 04 06 40 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 14 24 7E 

//RR帧 由于上面服务端回的帧中F=0 S=0即有后续帧，所以此处客户端应回应RR帧等待服务端的后续帧

RRR=3，P=0，所以控制字为91

客户端:7E A0 0A 48 68 FE FF 75 91 18 22 7E 

//GET.response的后续帧 RRR=2，SSS=4，F=0，所以控制字为58； 

服务端:7E A0 75 75 48 68 FE FF 58 40 72 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 00 00 00 10 00 00 10 00 00 02 06 00 02 02 09 0C FF FF FF FF FF 11 23 0C FF FF FF FF 04 06 40 00 00 10 00 00 10 00 00 A2 1B 7E 

客户端:7E A0 0A 48 68 FE FF 75 B1 1A 03 7E 

服务端:7E A0 0A 75 48 68 FE FF 51 39 E7 7E 

客户端:7E A0 0A 48 68 FE FF 75 53 06 C7 7E

服务端:7E A0 0A 75 48 68 FE FF 73 29 E5 7E

头校验序列（HCS）域

HCS的长度是两个字节。

HCS计算除开始标志和HCS本身外的头的字节数。

HCS的计算方法跟帧校验序列（FCS）类似。不包含信息域的帧，仅含FCS（在这种情况下，HCS被看作FCS）。HCS（和FCS）的计算方法采用CRC校验算法，不等式为X**0+X**5+X**12+X**16。

信息域

信息域可以是任意字节序列。

帧校验序列（FCS）域

FCS域的长度是两个字节，用来计算除开始标志和FCS本身 外的完整的帧长度。不包含信息域的帧只包含FCS（这里HCS被看作FCS）。

链路层链接与断开

链路层的链接

链路层的连接包括客户端发送的SNRM帧和服务端发送的UA帧。

SNRM/UA信息交换不但允许建立连接，而且允许协商一些数据链路参数。该协商的HDLC参数子集包含两部分：

• WINDOW_SIZE 参数（最大窗体数，即一次最多可传输的帧数，这个参数不能大于7）
• MAXIMUM_INFORMATION_FIELD_LENGTH 参数（信息域的最大字节数）

这些参数的缺省值如下：

• 默认WINDOW_SIZE=1
• 默认 MAXIMUM_INFORMATION_FIELD_LENGTH=128(80H)

协商规则如下：

协商从SNRM帧开始。该帧可能包含信息域。当信息域存在时，它应采用下面格式(见ISO/IEC13239  5.5.3.2条)：

信息域编码的格式举例(参数值为缺省值):

81

80

12

05

01

80

06

01

80

07

04

00

00

00

01

08

04

00

00

00

01

这里：

81H   格式标识符

80H  组标识符

12H 组长(18字节)

05H  参数标识符(最大信息字段长度，发送)

01H  参数长度（1字节）

80H  参数值

06H  参数标识符(最大信息字段长度，接收)

01H 参数长度（1字节）

80H  参数值

07H  参数标识符(窗口大小,发送)

04H  参数长度（4字节）

00H  参数值(值高字节)

00H  参数值

00H 参数值

01H 参数值(值低字节)

08H 参数标识符(窗口大小, 接收)

04H 参数长度

00H 参数值(值高字节)

00H 参数值

00H 参数值

01H 参数值(值低字节)

在多字节字段中(如例子中)最高位码位在最先传送的八位字节中。

当信息域存在时，前两个字节-格式标识符(81H)和组标识符(80H)一直会存在。但任何(一个或多个)协商参数可以缺省。

信息域缺省的解释意味着每个参数都是缺省值。

如果从站接收到一正确SNRM帧并且连接请求能被接受，它将用UA帧应答。此UA帧应带有HDLC参数的协商结果。

对应于从站接收的参数值（随SNRM帧发送），以及随UA帧接收到的参数值之间选择较小的值来计算结果。

例如：通过SNRM/UA帧的参数协商值示例

建议参数/值（通过接收SNRM帧）	对应参数值，可能被从站使用。	结果(从从站看发送/接收方向)
最大传送信息字段(05H)/ 80H(128D)	最大接收信息字段(06H)/ 40H (64D)	最大接收信息字段(06H)/ 40H (64D)
最大接收信息字段(06H)/ 80H(128D)	最大传送信息字段(05H)/ 80H(128D)	最大传送信息字段(05H)/ 80H (128D)
窗口大小 – 传送(07H)/0001H (1D)	窗口大小 – 接收 (08H)/0007H (7D)	窗口大小 – 接收 (08H)/0001H (1D)
窗口大小 – 接收 (08H)/0007H (7D)	窗口大小– 传送(07H)/0007H (7D)	窗口大小– 传送(07H)/0007H (7D)
注： 这里输入的SNRM帧应包含一信息域。但在这个域里只有“窗口大小-接收”参数是必需存在的。因为其他参数都是默认值。

在SNRM帧的信息域中包含其它未知的参数将被拒绝。这时，一DM帧（带“在SNRM帧的信息域中带有错误参数列表”）应被发送到主站。

在信息域中包含其它参数意味着SNRM帧的拒绝。这时，一DM帧（带“在SNRM帧的信息字段中带有错误参数列表”）应被发送到主站。

除了这些可协商的HDLC参数，SNRM帧的信息字段还可能包含用户定义的参数子段。该子段保留作以后用。

值得注意的是：为了提高通信效率，主站的最大接收信息字段应该大于等于从站最大传送信息字段，如，当主站发送的SNRM帧中参数均为默认值，而表计回复的UA帧中最大传送信息字段的值为256，此时主站应该将其最大接收信息字段调整至256。

例如：不带参数协商的SNRM帧

客户端:7E A0 0A 48 68 FE FF 75 93 D8 F8 7E

服务端:7E A0 21 75 48 68 FE FF 73 7C 16 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 01 53 3B 7E

带参数协商的SRNM帧 

客户端:7E A0 0A 48 68 FE FF 75 93 D8 F8 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 04 00 00 00 07 41 23 7E

服务端:7E A0 21 75 48 68 FE FF 73 7C 16 81 80 12 05 01 40 06 01 80 07 04 00 00 00 07 08 04 00 00 00 07 53 3B 7E

  无必要时采用默认参数即80H，80H，0001H，0001H。

链路层的断开

断开链路层包括客户端发送的DISC帧和服务端回应的UA/DM帧。

接收到DISC时没有断开链路，服务端回UA，然后链路断开；接收到DISC时链路已经断开则服务端回应DM帧。

DISC帧、UA帧和DM帧固定，只要将地址域及HCS域更换，如下：

DISC帧为 7E A0 0A 48 68 FE FF 75 53 06 C7 7E

UA帧为  7E A0 0A 75 48 68 FE FF 73 29 E5 7E

DM帧为  7E A0 0A 75 48 68 FE FF 1F 98 AD 7E

应用层

应用层的链接

应用层链接由客户端发起的AARQ帧和服务端回应的AARE帧构成。主要协商引用机制（逻辑名引用还是短名引用，海兴暂定为逻辑名引用）、支持的应用操作（读、写、方法）、用户级别等。对于ASN.1语义AARQ、AARE（除用户信息单元中的Initial部分）采用的是BER编码规则，其余均采用A-XDR编码规则。

编码规则

BER编码由三部分构成：类型，长度及值，如下图。

Identifier

Length

Contents

那么表达多项内容时则由一系列字节构成，如下：

I1

L1

I2

L2

I3

L3

C3

I4

L4

C4

I5

L5

C5

I6

L6

C6

C2

C1

A-XDR编码规则与BER编码类似，只是A-XDR编码省略了冗余的类型和长度部分，比如类型为integer8时，从类型便可看出长度为1个字节，因此可以省略掉长度部分。A-XDR编码结构如下：

I1

L1

L2

C3

I4

L4

C4

L5

C5

C6

L7

C7

C8

I9

L9

C9

C2

C1

各类型编码实例请参见Overview A-XDR.doc。

AARQ APDU和AARE APDU规范

在COSEM中,AARQ APDU在BER中被编码,而且包含一个AXDR编码为DLMS-Initiate.request的pdu，作为用户信息单元内部的 OCTETSTRING。

AARQ和AARE APDU-s规范如下（实际为AARQ AARE帧中信息域的参数，OPTIONAL表示该参数可缺省）：

AARQ-apdu ：=[APPLICATION 0] IMPLICIT SEQUENCE

{

protocol-eversion             [0] IMPLICIT BIT STRING  {VERSION1 (0)} DEFAULT {version1}.

  Application-context-name      [1]application-context-name.

  Called-ap-title                [2] AP-title OPTIONAL,

  Called-AE-qualifier           [3] AE-qualifier OOPTIONAL,

  Called-AP- invocation-id       [4] AP-invocation-identifier OPTIONAL,

  Called-AE-invocation-id        [5] AE-invocation-identifier OPTIONAL,

  Calling-AP-title               [6] AP-title OPTIONAL,

  Calling-AE-qalifier            [7] AE-qualifier OPTIONAL,

  Calling-AP-invocation-id       [8] AP-invocation-identifier OPTIONAL,

  Calling-AE-invocation-id       [9] AE-invocation-identifier OPTIONAL,

----The following field shall not be present if only the kernel is used.

Sender-acse-requirements       [10] IMPLICIT ACSE-requirements OPTIONAL,

----The following field shall only be present if the authentication functional unit is selected.

Mechanism-name             [11] IMPLICIT mechanism-name OPTIONAL,

----The following field shall only be present if the authentication functional unit is selected.

Calling-authentication-value     [12] EXPLICIT Authentication-value OPTIONAL,

Implementation-information     [29] IMPLICIT Implementation-data OPTIONAL,

User-information              [30] IMPLICIT Association-information OPTIONAL,

}

and

AARE-apdu::=[APPLICATION 1] IMPLICIT SEQUENCE

{

protocol-version                [0] IMPLICIT BIT STRING {VERSION1 (0)} DEFAULT {version1},

application-context-name         [1] application-context-name,

result                         [2] association-result,

result-source-diagnostic          [3] associate-source-diagnostic,

responding-ap-title               [4] ap-title OPTIONAL,

responding-ae-qualifier           [5] ae-qualifier OPTIONAL,

responding-AP-invocation-id      [6] ap-invocation-identifier OPTIONAL,

responding-ae-invocation-id       [7] ae-invocation-identifier OPTIONAL,

----the following field shall not be present if only the kernel is used.

Responder-acse-requirements      [8] IMPLICIT ACSE-requirements OPTIONAL,

----the following field shall only be present if the authentication functional unit is selected.

Mechanism-name               [9] IMPLICIT Mechanism-name OPTIONAL,

----THE FOLLOWING FIELD SHALL ONLY BE PRESENT IF THE AUTHENTICATION FUNCTIONAL UNIT IS SELED.

Responding-authentication-value   [10] EXPLICIT Authentication-value OPTIONAL,

Implementation-information       [29] IMPLICIT implementation-OPTIONAL,

User-information                [30] IMPLICIT Association-information OPTIONAL

}

COSEM使用这些ACSE-pdus的如下域：

1. protocol-version:协议版本：使用缺省值。
2. Application-context-name: 使用适当的COSEM应用环境给名字。
3. OPTIONAL called, caller and responding titles, qualifiers  and identifiers:：这些域在COSEM的面向连接的3层环境中不使用。在该环境中，客户机和服务器应用过程由低层地址明确识别（数据链路层SAPS）。

sender- and responder-acse-requirements:：当存在的时候，它携带BITSTRING { authentication (0) }的值。

1. mechanism-name:当存在的时候，它包括验证机制的名字。calling- and responding-authentication value:：当存在的时候,它的值由特定的实现决定，并且超出这文件的范围。
2. implementation-information:：该域留给将来使用。

user-information:：该八位位串总是存在，在AARQ-pdu的情况下该域包含DLMS-InitiateRequest-pdu；在AARE-pdu.的情况下该域包含DLMS-InitiateResponse-pdu或 DLMS-ConfirmedServiceError-pdu。该域信息可选择性加密。

1. result:：
2. result-source-diagnostics:这些域传送关联请求的结果和关联拒绝的最终原因，按照ISO/IEC/TR2 8650-1(1996-12)中的规定，当不包括诊断的时候，该域赋空值。

AARQ-pdu的编码例子

AARQ APDU包含一个AXDR编码为DLMS-Initiate.request的pdu，作为用户信息单元内部的 OCTETSTRING，即该部分属于4.1.1中AARQ-apdu的User-information内容。

DLMS-Initiate.request pdu定义为:

InitiateRequest::=SEQUENCE

{

dedicated-key             OCTET STRING OPTIONAL,

response-allowed            BOOLEAN DEFAULT TRUE,

proposed-quality-of-service   [0] IMPLICIT Integer8 OPTIONAL,

proposed-dlms-version-number Unsigned8,

proposed-conformance       Conformance,

client-max-receive-pdu-size    Unsigned16

}

设想一下，客户端要与如下xDLMS上下文建立关联：

1 不用密码（没有呈现可选的dedicated-key）

2 Response-allowed=true（保留默认值）

3 没有被建议的关于服务的质量(没有呈现可选参数proposed-quality-of-service)

4 建议DLMS的版本数是6（xDLMS）

建议一致块－－为LN和SN建议所有可能的服务和特定的特性－－描叙如下：

	Bit_00	Bit_01	Bit_02	Bit_03	Bit_04	Bit_05	Bit_06	Bit_07	Bit_08	Bit_09	Bit_10	Bit_11	Bit_12	Bit_13	Bit_14	Bit_15	Bit_16	Bit_17	Bit_18	Bit_19	Bit_20	Bit_21	Bit_22	Bit_23	BITSTRING的值
LN	0	0	0	0	0	0	0	0	1	0	1	1	1	1	0	0	0	0	0	1	1	1	1	1	00 BC 1F
SN	0	0	0	1	1	1	0	0	0	0	0	0	0	0	1	1	0	0	1	0	0	0	0	0	1C 03 20

这个建议一致块中的LN引用意思是：

支持优先管理（09位）

支持0属性参照（10位）

支持由GET服务完成的块传输（11位）

支持由SET服务完成的块传输（12位）

支持由ACTION服务完成的块传输（13位）

支持多点引用（14位）

支持所有LN服务（GET,SET,ACTION,EVENT NOTIFICATION）（19，20，21，22，23位）

支持可选访问特性（21位）

SN引用的意思是：

支持所有SN服务（READ,WRITE,UNCONFIRMED WRITE,INFORMATION REPORT）(03,04,05,15位)

支持多点引用（14位）

支持参数接入 （18位）

客户端最大接收PDU大小是1200D=0x4B0

由这些参数，A-XDR编码成DLMS Initiate.request pdu如下：

－－A-XDR编码成DLMS Initiate.request-pdu

01   //编码DLMS PDU选择（初始请求）的标签(外在标签) 

      ----编码专用键成分(可选,不出现) 

00   //专用键的使用标志(FALSE,不出现)

----编码响应允许成分(TRUE，默认值)

00 //响应允许成分的使用标志 (FALSE,默认值传播)

----编码建议质量服务成分 (可选,不出现)

00 //建议质量服务成分的使用标志(FALSE,不出现)

----建议DLMS版本号成分的编码(8位无符号整型,值为6)

06 //关于一个8位无符号整型的A-XDR编码是它的值

----编码一致性块[应用31]明确比特串(24位) 

5F //编码[应用31]标签(ASN.1明确标签) 

04 //编码八位字节第四位的"内容"域的长度

00 //比特串最后一个八位字节的无用比特数的编码

LN引用	SN引用
00 BC 1F //固定长度比特串值的编码	1C 03 20 //固定长度比特串值的编码

------编码客户端最大接收PDU大小成分 (16位无符号整型,值为0x4B0)

04B0 //一个16位无符号整型的A-XDR编码是它的值

所以,根据给定的参数, DLMS Initiate.request-pdu的A-XDR编码结果如下面的八位位组序列:

LN引用	SN引用
DLMS-Initiate.req-pdu:  01 00 00 00 06 5F 04 00 00 BC 1F 04 B0	DLMS-Initiate.req-pdu:  01 00 00 00 06 5F 04 00 1C 03 20 04 B0

这些八位位组序列要作为一个OCTET STRING插入到AARQ QPDU比特串的用户信息单元中。

1.为用于ACSE,让我们想象一下,客户端要建立与下列应用上下文的关联:

2.协议版本是默认的ACSE版本

3.应用上下文名字:COSEM_Application_Context_Name-Logical_Name_Referencing(LN ref.) {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) application-context(1) context_id(1)}

4. 应用上下文名字:COSEM_Application_Context_Name-Short_Name_Referencing(SN ref.) {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) application-context(1) context_id(1)}

6.没有使用验证: 机制名字和召唤验证值都没有呈现.

7.不包含执行信息.

根据这些参数,AARQ-pdu的编码(BER)如下:

----BER编码AARQ QPDU 

60 //编码AARE-pdu的标签([应用0],应用) 

1C //AARE的内容域(28字节)的长度编码

----不对协议版本编码,因此取它的默认值

----应用上下文名字成分编码(标志为 component[1])

A1 //应用上下文名字成分([1],指定上下文)标志编码

09 //特征成分的值域长度编码

----应用上下文名字成分的编码(对象标识符)

06 //应用上下文名字成分选择的编码(对象标识符,通用)

07 //对象标识符值域长度的编码(7个字节)

----对象标识符37值的编码

（八位字节标识符的BER编码是表现弧形标签的数据的包序列。每个数据——除了最先的两个数据，他们已经组合成一个数据了——表现为一个八位字节的系列，每个八位字节用到7个比特并且除了最后一个八位字节外,最重要的位被设为1。

在这个例子中的对象标识符(2,16,756,8,1,1),第一个八位字节的编码是把最前面的两个数组合成一个数字,所用的规则是:40*第一个数+第二个数->40*2+16=96=0x60.对象标识符的第三个数需要两个八位字节:它的16进制数为0x2F4,也就是00000010 11110100,但是根据上面的规则,MSB的第二个八位字节应该设为0，因而你应该转换这个MSB到第一个八位字节，并且设置这个MSB的第一个八位字节的第一位为1,二进制也就是10000101 01110100,等于0x8574.每个剩下的对象标识符的数据都必须编码成一个八位字节,于是就得到上面的编码结果:60 85 74 05 08 01 01）

LN 引用	SN引用
60 85 74 05 08 01 01	60 85 74 05 08 01 02

----用户信息域(标志成分，[30]) 的编码

BE //用户信息域 ([30],明确文本)标志的编码

0F //标志成分值域的长度的编码

----应用上下文名字成分的编码(八位字节字符串)

04 //用户信息的选择编码(八位字节字符串,通用)

0D //八位字节字符串的值域长度编码(13字节)

//下面是DLMS-Initiate.request-pdu的八位字节序列：

LN引用	SN引用
01 00 00 00 06 5F 04 00 00 BC 1F 04 B0	01 00 00 00 06 5F 04 00 1C 03 20 04 B0

所以根据给定的参数,AARQ APDU的完整编码如下(所有数都是16进数)

LN引用	SN引用
AARQ-pdu=[60 1C A1 09 06 07 60 85 74 05 08 01 01 BE 0F 04 0D 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0]	AARQ-pdu=[60 1C A1 09 06 07 60 85 74 05 08 01 02 BE 0F 04 0D 01 00 00 00 06 5F 04 00 1C 03 20 04 B0]

AARE-pdu的编码的例子，成功案例:

让我们回忆一下关于AARE APDU 的ASN.1规范:

AARE-apdu::=[APPLICATION 1] IMPLICIT SEQUENCE

{

protocol-version [0] IMPLICIT BIT STRING{versio1(0)}DEFAULT{version1}

application-context-name [1] Application-context-name

result [2] Association-result

result-source-diagnostic [3] Associate-source-diagnostic

responding-AP-title [4] AP-titile OPTIONAL

responding-AE-qualifier [5] AE-qualifier OPTIONAL

responding-AP-invocation-id [6] AP-invocation-identifier OPTIONAL

responding-AE-invocation-id [7] AE-invocation-identifier OPTIONAL

-----如果只用到核心,下面的域不应该出现

responder-acse-requirements [8] IMPLICIT ACSE-requirements OPTIONAL

-----如果选择了验证功能单元的话,只能出现下面的域

responding-authentication-value [10] EXPLICIT Authentication-value OPTIONAL

implementation-information [29] IMPLICIT Implementation-data OPTIONAL

user-information [30] IMPLICIT Association-information OPTIONAL

}

在COSEM中,这种APDU被编码在BER中,而且包含一个在用户域中作为OCTETSTRING的A-XDR编码DLMSInitiate.response pdu。

让我们从DLMS-Initiate.response pdu开始,它被定义为:

initiateResponse::=SEQUENCE

{

negotiated-quality-of-service     [0] IMPLICIT Integer8 OPTIONAL

negotiated-dlms-version-number Unsigned8

negotiated-conformance Conformance

server-maax-receive-pdu-size Unsigned16

vaa-name         OjectName

}

其中,ObjectName 类型被定义为ObjectName::=Unsigned16,一致性参数和前面例子里DLMS-Initiate.request-pdu的一样.

设想一下,服务器接收建议连接,包含以下的xDLMS上下文:

没有negotiated-quality-of-servic(不表现OPTIONAL的proposed-quality-of服务参数)

DLMS协商版本号是6(xDLMS)

描述了LN,SN引用的公认服务和特殊特性的公认xDLMS一致性块,应该如下表所述:

	Bit_00	Bit_01	Bit_02	Bit_03	Bit_04	Bit_05	Bit_06	Bit_07	Bit_08	Bit_09	Bit_10	Bit_11	Bit_12	Bit_13	Bit_14	Bit_15	Bit_16	Bit_17	Bit_18	Bit_19	Bit_20	Bit_21	Bit_22	Bit_23	BITSTRING的值
LN	0	0	0	0	0	0	0	0	0	1	0	1	0	0	0	0	0	0	0	1	1	1	1	1	00 50 1F
SN	0	0	0	1	1	1	0	0	0	0	0	0	0	0	1	1	0	0	1	0	0	0	0	0	1C 03 20

这个LN引用的一致块的意思是：

支持优先管理（09位）

支持0属性参照（10位）

支持由GET服务完成的块传输（11位）

支持由SET服务完成的块传输（12位）

支持由ACTION服务完成的块传输（13位）

不支持多点引用（14位）

支持所有LN服务（GET,SET,ACTION,EVENT NOTIFICATION）（19，20，21，22，23位）

支持可选接入特性（21位）

SN引用的意思是：

支持所有SN服务（READ,WRITE,UNCONFIRMED WRITE,INFORMATION REPORT）(03,04,05,15位)

支持多点引用（14位）

支持参数接入 （18位）

服务器端最大接收PDU大小是500D=0x1F4

LN引用	SN引用
这个连接分配了一个VAA的虚拟名字(0x0007)。	返回一个标准的SN连接(0xFA00)的固定的短名字。

DLMS-Initiate.response-pdu带着这些参数的A-XDR编码如下：

－－A-XDR编码成DLMS Initiate.response-pdu

08 //DLMS PDU选择标签(初始响应)的编码

----协商质量服务成分编码(可选,不出现)

00 //服务的建议质量成分的使用标志(FALSE,不出现)

----协商DLMS版本号成分的编码(8位无符号整型,值为6)

06 //一个8位无符号整型数的A-XDR编码是它的值

----一致性块[应用31]明确比特串(24位)编码

5F // [应用31]标签(ASN.1明确标签)编码

04 //八位字节（4）的"内容"域的长度编码

00 //比特串最后一个八位字节的无用比特的总数的编码

LN引用	SN引用
00 50 1F	1C 03 20

------编码服务器端最大接收PDU大小成分 (16位无符号整型,值为0x1F4)

01 F4 //16位无符号整型的A-XDR编码是它的值

-----编码VAA-NAME 成分 (16位无符号整型,值为0x0007)

//16位无符号整型的A-XDR编码是它的值

LN引用	SN引用
00 07	FA 00

因此，DLMS Initiate.response-pdu的附带上述参数的A-XDR编码的八位字节序列形式的结果如下：

LN引用	SN引用
DLMS-Initiate.res-pdu:  08 00 06 5F 04 00 00 50 1F 01 F4 00 07	DLMS-Initiate.res-pdu: 08 00 06 5F 04 00 1C 03 20 01 F4 FA 00

这个八位字节序列将被作为一个OCTET STRING加入到AARE APDU的用户信息域。

我们设想一下，为了ACSE的应用，服务器接受包含下述应用上下文的关联建议：

1. 协议版本是缺省的ACSE的版本
2. 应用上下文名字如下：

LN引用	SN引用
COSEM_Application_Context_Name- Logical_Name_Referencing {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) applicationcontext( 1) context_id(1)}	COSEM_Application_Context_Name- Short_Name_Referencing {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) applicationcontext( 1) context_id(2)}

1. 没有使用验证: 机制名字和召唤验证值都没有呈现.
2. 不包含执行信息.

根据这些参数,AARQ-pdu的编码(BER)如下:

-- BER编码AARE APDU

61 //编码AARE-pdu的标签([应用1],应用) 

28 // AARE的内容域(40字节)的长度编码

// 不对协议版本编码,因此取它的默认值

--应用上下文名字成分编码(标志为 component[1])

A1 //应用上下文名字成分([1],指定上下文)标志编码

09 //特征成分的值域长度编码

--应用上下文名字成分的编码(对象标识符)

06 //应用上下文名字成分选择的编码(对象标识符,通用)

07 //对象标识符值域长度的编码(7个字节)

// 对象标识符值的编码

LN 引用	SN引用
60 85 74 05 08 01 01	60 85 74 05 08 01 02

-- 结果成分的编码(标志成分[30])

A2 // 结果成分的标志和长度的编码([2], 特定上下文)

03 // 标志成分值域的长度的编码

-- 结果成分的编码(整形数)

02 // 结果选择的编码(整形数, 通用)

01 // 结果的值域的长度的编码(1八位字节)

00 // 结果的值的编码(0, 公认的)

A3 // result-source-diagnostics成分的标志的编码([2], 特定上下文)

05 // 标志成分值域的长度的编码

A1 // acse-service-user选择标志的编码(1)

03 // 标志成分的值域的长度的编码

--  result-source-diagnostics成分的编码(整形数)

02 // result-source-diagnostics选择的编码 (整形数, 通用)

01 // 值域的长度的编码 (1 八位字节)

00 // 值: 0的编码, 没有提供诊断

-- user-information域成分的编码 (标志成分, [30])

BE // user-information域成分的标志的编码 ([30], 特定上下文 )

0F // 标志成分的值域的长度的编码

-- application-context-name成分的编码 (OCTET STRING)

04 // user-information的选择的编码 (OCTET STRING, 通用)

0D // OCTET STRING的值域的长度的编码 (13 八位字节 )

// 这里是DLMS-Initiate.response-pdu的八位字节序列 

LN 引用	SN引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07	08 00 06 5F 04 00 1C 03 20 01 F4 FA 00

因此一个带有上述参数的AARE APDU的完整编码如下（所有数值使用十六进制）：

LN 引用	SN引用
AARE-pdu = [ 61 28 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 0F 04 0D 08 00 06 5F 04 00 00 50 1F 01 F4 00 07 ]	AARE-pdu = [ 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 0F 04 0D 08 00 06 5F 04 00 1C 03 20 01 F4 FA 00 ]

AARE-pdu例子的编码, 失败1的案例

这个例子展示了一个, 当一个服务器因为接收到的application-context-name不适合于应用上下文，不能接受建议的关联时，一个服务器可以支持的AARE-pdu的构筑。

这个案例中，AARE-pdu的‘result’域将包含‘rejected-permanent’值，‘result-source-diagnostic’域包含‘application-context-name-not-supported’值，并且——假设服务器可以支持建议的xDLM上下文——用户域将包含一个恰当的DLMS-Initiate.response-pdu构筑（被编码为一个A-XDR，作为一个OCTET

STRING的BER）。（它将于前述的例子相同）。因此DLMS Initiate.response-pdu的A-XDR编码将如下所示：

LN 引用	SN引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07	08 00 06 5F 04 00 1C 03 20 01 F4 FA 00

AARE的参数:

1. 协议版本式缺省的ACSE版本
2.  Application-context-name: COSEM_Application_Context_Name-

Logical_Name_Referencing (the proposed)

{joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMSUA(

8) application-context(1) context_id(1)}

1. 没有使用验证: 机制名字和召唤验证值都没有呈现.
2. 不包含实现信息
3. 结果 = rejected-permanent
4. Associate-source-diagnostics = application-context-name-not-supported

AARE-pdu的(BER)编码, 及相应的这些参数如下：

-- AARE APDU的BER编码

61 // AARE-pdu的标签的编码([APPLICATION 1], Application)

28 // AARE的内容域的长度的编码(40 octets)

// 没有协议版本的编码，因此它由它的缺省值决定

-- application-context-name成分的编码(tagged component [1])

A1 // application-context-name成分标签的编码 ([1], Context-specific )

09 // 标记成员的值域的长度的编码

-- application-context-name成分的编码 (OBJECT IDENTIFIER)

06 // application-context-name选择的编码 (OBJECT IDENTIFIER, Universal)

07 // 对象标识的值域的长度的编码 (7 octets)

LN 引用	SN引用
60 85 74 05 08 01 01 // 为LN引用的对象标识(2,16,756,5,8,1,1)的值的编码	60 85 74 05 08 01 02 // 为SN引用的对象标识(2,16,756,5,8,1,2)的值的编码

-- 结果成分的标签和长度的编码 (tagged component [2])

A2 // 结果成分的标签的编码 ([2], Context-specific )

03 // 标记成分的值域的长度的编码

-- 结果成分的编码 (INTEGER)

02 // 结果选择的编码 (INTEGER, Universal)

01 // 结果的值域的长度的编码 (1 octets)

// 结果的值的编码 (1, rejected-permanent)

-- result-source-diagnostics成分的编码 (tagged component [3])

A3 // result-source-diagnostics成分的标签的编码 ([2], Context-specific )

05 // 标记成分的值域的长度的编码

A1 // acse-service-user CHOICE的标签的编码 (1)

03 // 标记成分的值域的长度的编码

-- result-source-diagnostics成分的编码 (INTEGER)

02 // result-source-diagnostics的选择的编码 (INTEGER, Universal)

01 // 值域的长度的编码 (1 octets)

// 值: 2的编码, application-context-name-not-supported.

-- user-information域成分的编码 (tagged component, [30])

BE // user-information域成分的标签的编码 ([30], Context-specific )

0F // 标记成分的值域的长度的编码

-- application-context-name成分的编码 (OCTET STRING)

04 // user-information选择的编码 (OCTET STRING, Universal)

0D // OCTET STRING的值域的长度的编码 (13 octets )

// 这里是DLMS-Initiate.response-pdu的八位字节序列

LN 引用	SN引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07	08 00 06 5F 04 00 1C 03 20 01 F4 FA 00

因此AARE APDU带着所有给定参数使用LN参考的完整编码如下 (所有值使用十六进制表示):

AARE-pdu = [ 61 28 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 01 A3 05 A1 03 02 01 02

BE 0F 04 0D 08 00 06 5F 04 00 00 50 1F 01 F4 00 07 ]

对SN引用，如下:

AARE-pdu = [ 61 28 A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 01 A3 05 A1 03 02 01 02

BE 0F 04 0D 08 00 06 5F 04 00 1C 03 20 01 F4 FA 00 ]

AARE-pdu的编码的例子, 失败2的案例

这个例子展示了, 当一个服务器因为它服务器不支持被提议的xDLMS上下文（带有“被提议的DLMS的版本号太低”的原因），而不能接受建议的关联时，的一个AARE-pdu的构筑。（被提议的应用上下文可以被接受。）

这个案例中，AARE-pdu的‘result’域将包含‘rejected-permanent’值，‘result-source-diagnostic’域‘no-reason-given’值，并且user-information域将包含一个恰当的DLMSConfirmedServiceError-pdu构筑（作为一个OCTET STRING的BER包含在A-XDR的编码中），指明失败的原因。

特定的确定服务错误消息如下：

ConfirmedServiceError ::= CHOICE

{

-- tag 0 is reserved

initiateError [1] ServiceError,

getStatus [2] ServiceError,

getNameList [3] ServiceError,

. . .

terminateUpLoad [19] ServiceError

}

其中的服务错误如下:

ServiceError ::= CHOICE

{

. . .

initiate [6] IMPLICIT ENUMERATED

-- initiate service error

{

other (0),

DLMS-version-too-low (1), -- proposed DLMS version too low

incompatible-conformance (2), -- proposed services not sufficient

PDU-size-too-short (3), -- proposed PDU size too long

refused-by-the-VDE-Handler (4) -- vaa creation impossible or not allowed

}

. . .

}

因此，ConfirmedServiceError PDU的带着上述条件的A-XDR编码如下所示：

-- DLMS ConfirmedServiceError-pd的A-XDR编码

0E // DLMS PDU CHOICE的标签(外在标签)的编码(ConfirmedServiceError)

-- 选择InitiateError的标签的编码 (InitiateError = 1)

01 // ConfirmedServiceError CHOICE的标签(外在) (InitiateError =1)

-- 选择ServiceError的标签的编码 (Initiate = 6)

06 // ServiceError CHOICE的标签(外在) (Initiate 6)

-- 列举失败原因的编码 (被提议的DLMS的版本太低 = 1)

01 // ENUMERATED类型的值的编码

因而，导出这个DLMS-ConfirmedServiceError-pdu的带有上述参数的A-XDR编码，得到如下八位字节序列：

DLMS-ConfirmedServiceError-pdu: 0E 01 06 01 (LN和SN引用相同)

这个八位字节序列将被作为一个OCTET STRING插入到用户信息域中。

假如，AARE的参数如下:

1. 协议版本使用缺省的ACSE版本

1. Application-context-name: COSEM_Application_Context_Name- Logical_Name_Referencing (the proposed) {joint-iso-ccitt(2) country(16) country-name(756) identified-organization(5) DLMS-UA(8) application-context(1) context_id(1)}

1. 没有使用验证: 机制名字和召唤验证值都没有呈现.
2. 不包含执行信息.
3. Result = rejected-permanent
4. Associate-source-diagnostics = no-reason-given

AARE-pdu的(BER)编码, 相应的这些参数如下:

-- AARE APDU的BER编码

61 // AARE-pdu的标签的编码 ([APPLICATION 1], Application)

1F // AARE的内容的域的长度的编码 (31 octets)

// 没有协议版本编码，因而它由缺省值确定

-- application-context-name成分的编码 (tagged component [1])

A1 // application-context-name成分的标签的编码 ([1], Context-specific )

09 // 标记成分的值域的长度的编码

-- application-context-name成分的编码 (OBJECT IDENTIFIER)

06 // application-context-name选择的编码 (OBJECT IDENTIFIER, Universal)

07 // 对象标识值域的长度的编码 (7 octets)

60 85 74 05 08 01 01 // 对象标识的值的编码 (2,16,756,5,8,1,1)

-- 结果成分的标签和长度的编码 (tagged component [2])

A2 // 结果成分的标签的编码 ([2], Context-specific )

03 // 标记成分的值域的长度的编码

-- 结果成分的编码 (INTEGER)

02 // 结果选择的编码 (INTEGER, Universal)

01 // 结果的值域的长度的编码 (1 octets)

01 // 结果的值的编码 (1, rejected-permanent)

-- result-source-diagnostics成分的编码 (tagged component [3])

A3 // result-source-diagnostics成分的标签的编码 ([2], Context-specific )

05 // 标记成分的值域的长度的编码

A1 // acse-service-user CHOICE的标签的编码 (1)

03 // 标记成分的值域的长度的编码

-- result-source-diagnostics成分的编码 (INTEGER)

02 // result-source-diagnostics选择的编码 (INTEGER, Universal)

01 // 值域的长度的编码 (1 octets)

// 值: 1的编码, no-reason-given

-- user-information域成分的编码 (tagged component, [30])

BE // user-information域成分的标签的编码 ([30], Context-specific )

06 // 标记成分的值域的长度的编码

-- application-context-name成分的编码 (OCTET STRING)

04 // user-information的选择的编码 (OCTET STRING, Universal)

04 // OCTET STRING的值域的长度的编码

0E 01 06 01 // 这里是DLMS-ConfirmedServiceError-pdu的八位字节序列

所以一个AARE APDU使用LN引用的带着给定参数的完整编码如下所示（所有值采用十六进制）：

AARE-pdu = [ 61 1F A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 01 A3 05 A1 03 02 01

03 BE 06 04 04 0E 01 06 01 ]

对SN引用, 如下:

AARE-pdu = [ 61 1F A1 09 06 07 60 85 74 05 08 01 02 A2 03 02 01 01 A3 05 A1 03 02 01

03 BE 06 04 04 0E 01 06 01 ]

应用层链接失败原因（几乎包含了APPL_OPEN的所有测试案例）

应用层链接失败即回应的AARE帧中应含有错误信息的原因有如下情况：

1. AARQ帧中存在Protocol version（标识 80），且它的值按照编码规则不为1或者0，CTT中为02 44

7E A0 2F 03 21 10 17 DD E6 E6 00 60 21 80 02 02 44 A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 00 19 FF FF E0 51 7E

A2 03 02 01 01 A3 05 A2 03 02 01 02

1. AARQ帧中Application context（标识 A1）内容错误，暂认为不是60 85 74 05 08 01 01的为错误信息，如下为CTT发送的错误Application context：

7E A0 2B 03 21 10 FB AF E6 E6 00 60 1D A1 09 06 07 60 85 74 05 08 01 02 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 00 19 FF FF 8D 57 7E

7E A0 2B 03 21 54 DB AB E6 E6 00 60 1D A1 09 06 07 5F 85 75 04 07 02 03 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 00 19 FF FF A7 4C 7E

A2 03 02 01 01 A3 05 A1 03 02 01 02

1. AARQ帧中身份验证机制不对应。

情况A：采用最低安全级别的地址（如客户端公共地址0x10）链接，而AARQ中有sender-acse-requirements（标识 8A）且bit0 为1（按照编码规则为07 80），有machanism-name（标识 8B）和calling-authentication-value（标识：AC），如CTT中发送的7E A0 41 03 21 10 B1 EA E6 E6 00 60 33 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 07 80 05 44 55 4D 4D 59 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 00 19 FF FF FB B9 7E

A2 03 02 01 01 A3 05 A1 03 02 01 02

情况B：表中有低安全级别，AARQ中有sender-acse-requirements（标识 8A）且bit0 为1（按照编码规则为07 80）和machanism-name（标识 8B）而没有calling-authentication-value（标识：AC）

情况C：采用低安全级别，AARQ中有machanism-name（标识 8B）和calling-authentication-value（标识：AC），但sender-acse-requirements（标识 8A）且bit0 为0（按照编码规则为07 00）

情况D： AARQ中有sender-acse-requirements（标识 8A）且bit0 为1（按照编码规则为07 80）但无machanism-name（标识 8B）和calling-authentication-value（标识：AC）

。。。

1. AARQ中有implementation information,但是错误的信息（暂不知道正确的信息应该是怎样，GREEN book第4版第188页中说到该参数没有在该文档中定义，但CTT发出的错误信息知道）如CTT中发送的7EA0330321108289E6E6006025A109060760857405080101BD060544756D6D79BE10040E01000000065F1F0400000019FFFF98547E

A2 03 02 01 01 A3 05 A1 03 02 01 01

1. AARQ中User-information中dedicated-key出现即不为00，如CTT中发送的7EA031032110F4B0E6E6006023A109060760857405080101BE16041401010544756D6D790000065F1F0400000019FFFF09B17E

A2 03 02 01 01 A3 05 A1 03 02 01 01

1. AARQ中User-information中proposed-dlms-version-number小于6，如CTT中发送的7 EA02B032110FBAFE6E600601DA109060760857405080101BE10040E01000000055F1F0400000019FFFF2E9E7E

A2 03 02 01 01 A3 05 A1 03 02 01 01

1. AARQ中User-information中proposed-conformance中服务与表计中支持的不相符，如：信息中参数既支持ln引用又支持sn引用等。此处可以回复错误信息（应用层链接失败），也可以回复正确的proposed-conformance参数（应用层链接成功）。如果回复错误信息，那么为以下错误信息：

 A2 03 02 01 01 A3 05 A1 03 02 01 01

1. AARQ中User-information中client-max-receive-pdu-size小于12，如CTT中发送7EA02B032110FBAFE6E600601DA109060760857405080101BE10040E01000000065F1F0400000019000B2CA47E

A2 03 02 01 01 A3 05 A1 03 02 01 01

帧实例

不使用安全机制：

AARQ: 7E A0 2E 48 68 FE FF 75 10 XX XX E6 E6 00 60 60 1D A1 09 06 07 60 85 74 05 08 01 01 BE 10 04 0E 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0 XX XX 7E

AARE: 7E 72 52 75 48 68 FE FF 30 95 39 E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 BE 0F 04 0D 08 00 06 5F 04 00 00 00 14 21 34 00 07 XX XX 7E

使用低身份验证，密码为12345678：

AARQ: 7E 8C 46 48 68 FE FF 75 10 XX XX E6 E6 00 60 35 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 31 32 33 34 35 36 37 38 BE 10 04 0E 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0 XX XX 7E

AARE: 7E A4 52 75 48 68 FE FF 30 XX XX E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 31 32 33 34 35 36 37 38 BE 0F 04 0D 08 00 06 5F 04 00 00 00 14 21 34 00 07 XX XX 7E

使用高级身份验证：

AARQ: 7E 7C 46 48 68 FE FF 75 10 XX XX E6 E6 00 60 2E A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 02 AC 02 80 00 BE 10 04 0E 01 00 00 00 06 5F 04 00 00 00 14 00 00 XX XX 7E

AARE: 7E A0 52 75 48 68 FE FF 30 XX XX E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 00 A3 05 A1 03 02 01 00 88 02 07 80 89 07 60 85 74 05 08 02 01 AA 0A 80 08 41 42 43 44 45 46 47 48 BE 0F 04 0D 08 00 06 5F 04 00 00 00 14 21 34 00 07 XX XX 7E

使用低身份验证，密码为12345678，失败：

AARQ: 7E 8C 46 48 68 FE FF 75 10 XX XX E6 E6 00 60 35 A1 09 06 07 60 85 74 05 08 01 01 8A 02 07 80 8B 07 60 85 74 05 08 02 01 AC 0A 80 08 31 32 33 34 35 36 37 38 BE 10 04 0E 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0 XX XX 7E

AARE: 7E 72 52 75 48 68 FE FF 30 XX XX E6 E7 00 61 41 A1 09 06 07 60 85 74 05 08 01 01 A2 03 02 01 01 A3 05 A1 03 02 01 02 BE 0F 04 0D 08 00 06 5F 04 00 00 00 14 21 34 00 07 XX XX 7E

读操作(Get)

分为Get. Request和Get.Response。

Get. Request

数据请求帧

GET-Request ::= CHOICE

{

get-request-normal [1] IMPLICIT Get-Request-Normal,

get-request-next [2] IMPLICIT Get-Request-Next,

get-request-with-list [3] IMPLICIT Get-Request-With-List

}

Get-Request-Normal ::= SEQUENCE

{

invoke-id-and-priority Invoke-Id-And-Priority,

cosem-attribute-descriptor Cosem-Attribute-Descriptor,

access-selection-parameters Selective-Access-Descriptor OPTIONAL

}

Get-Request-Next ::= SEQUENCE 

{ 

invoke-id-and-priority           Invoke-Id-And-Priority, 

block-number                  Unsigned32 

} 

Cosem-Attribute-Descriptor ::= SEQUENCE

{

class-id Cosem-Class-Id,

instance-id Cosem-Object-Instance-Id,

attribute-id Cosem-Object-Attribute-Id

}

Cosem-Object-Instance-Id ::= OCTET STRING (SIZE(6))

Cosem-Object-Attribute-Id ::= Integer8

以请求反向有功为例：

客户端: 7E A0 1C 48 68 FE FF 75 54 XX XX E6 E6 00 C0 01 81 00 03 01 01 02 08 00 FF 02 00 XX XX 7E  

解释：

7e a0 1c 00 22 00 23 03 54 XX XX e6 e6 00 //Hdlc head

c0 // get-request Cosem apdu[192]

01 //Request Nomal(因此，在DLMS认证第一阶段，规约里所有的读操作ID均为C001)

81 // invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81或C1，超过则为8C CC）

00 03//Class id

01 01 02 08 00 ff //反向总有功 OBIS

02 //反向总有功的第二属性，值域。

00 // haven’t access-selection-parameters

XX XX 7E //HDLC Tail

Get. Response

数据响应帧。

GET-Response ::= CHOICE

{

get-response-normal [1] IMPLICIT Get-Response-Normal,

get-response-with-datablock [2] IMPLICIT Get-Response-With-Datablock,

get-response-with-list [3] IMPLICIT Get-Response-With-List

}

Get-Response-Normal ::= SEQUENCE

{

invoke-id-and-priority Invoke-Id-And-Priority,

result Get-Data-Result

}

Get-Response-With-Datablock ::= SEQUENCE 

{ 

invoke-id-and-priority          Invoke-Id-And-Priority, 

result                        DataBlock-G 

} 

Get-Data-Result ::= CHOICE

{

data [0] Data,

data-access-result [1] IMPLICIT Data-Access-Result

}

Data ::= CHOICE

{

null-data [0] IMPLICIT NULL,

array [1] IMPLICIT SEQUENCE OF Data,

structure [2] IMPLICIT SEQUENCE OF Data,

boolean [3] IMPLICIT BOOLEAN,

bit-string [4] IMPLICIT BIT STRING,

double-long [5] IMPLICIT Integer32,

double-long-unsigned [6] IMPLICIT Unsigned32,

floating-point [7] IMPLICIT OCTET STRING(SIZE(4))33,

octet-string [9] IMPLICIT OCTET STRING,

visible-string [10] IMPLICIT VisibleString,

time [11] IMPLICIT GeneralizedTime,

bcd [13] IMPLICIT Integer8,

integer [15] IMPLICIT Integer8,

long [16] IMPLICIT Integer16,

unsigned [17] IMPLICIT Unsigned8,

long-unsigned [18] IMPLICIT Unsigned16,

compact-array [19] IMPLICIT SEQUENCE

{

contents-description [0] TypeDescription,

array-contents [1] IMPLICIT OCTET STRING

}

long64 [20] IMPLICIT Integer64,

long64-unsigned [21] IMPLICIT Unsigned64,

enum [22] IMPLICIT ENUMERATED,

float32 [23] IMPLICIT OCTET STRING (SIZE(4)),

float64 [24] IMPLICIT OCTET STRING (SIZE(8)),

don’t-care [255] IMPLICIT NULL

}

Data-Access-Result ::= ENUMERATED

{

success (0),

hardware-fault (1),

temporary-failure (2),

read-write-denied (3), 

object-undefined (4),

object-class-inconsistent (9),

object-unavailable (11),

type-unmatched (12),

scope-of-access-violated (13),

data-block-unavailable (14),

long-get-aborted (15),

no-long-get-in-progress (16),

long-set-aborted (17),

no-long-set-in-progress (18),

other-reason (250)

}

DataBlock-G ::= SEQUENCE -- G == DataBlock for the GET.response service 

{ 

last-block                   BOOLEAN, 

block-number               Unsigned32, 

result    CHOICE 

 { 

  raw-data                  [0] IMPLICIT OCTET STRING, 

  data-access-result         [1] IMPLICIT Data-Access-Result 

 } 

} 

以响应“请求反向有功”为例，读数据成功：

服务端: 7E A0 18 75 48 68 FE FF 74 XX XX E6 E7 00 C4 01 81 00 06 00 35 7B 18 XX XX 7E

解释：

7E A0 18 03 00 22 00 23 74 XX XX E6 E7 00  //Hdlc head

C4 01 //Response Normal（在DLMS认证第一阶段，规约里所有的回应读操作操作ID均为C401)

81 // invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

00 //by data

06 //数据类型

00 35 7B 18 //反向有功值

XX XX 7E//HDLC Tail

读数据不成功，以object-undefined为例：

服务端: 7E A0 14 75 48 68 FE FF 74 XX XX E6 E7 00 C4 01 81 01 04 XX XX 7E

解释：

7E A0 14 03 00 22 00 23 74 XX XX E6 E7 00  //Hdlc head

C4 01 //Response Normal（在DLMS认证第一阶段，规约里所有的回应读操作操作ID均为C401)

81 // invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

01// data-access-result [1] IMPLICIT Data-Access-Result

04 //object-undefined

XX XX 7E//HDLC Tail

读数据块

当一次读取数据量较大时，表计可采用Get-Response-With-Datablock的方式回复。以读取负荷曲线数据为例：

客户端: 7E A0 1C 48 68 FE FF 75 54 XX XX E6 E6 00 C0 01 81 00 07 00 00 62 01 00 7E 03 00 XX XX 7E

服务端: 7E A0 LL 75 48 68 FE FF 74 XX XX E6 E7 00 C4 02 81 00 00 00 00 01 00 73 01 0E 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 00 00 01 00 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 08 01 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 08 02 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 08 03 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 08 04 FF 0F 02 12 00 00 02 04 12 00 04 XX XX 7E

C4 02//Get-Response-With-Datablock

81// invoke-id and priority

00//不是最后的数据块

00 00 00 01//数据块序号 1

00//raw-data，表明回复的是数据；如果为01则表示回复的是data-access-result

73//此数据块长度

01 0E//此负荷曲线记录了14列数据项

02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00//第1个数据项：时间

02 04 12 00 03 09 06 01 00 00 01 00 FF 0F 02 12 00 00//第2个数据项：结算次数

02 04 12 00 03 09 06 01 01 01 08 01 FF 0F 02 12 00 00//第3个数据项：A+ T1

02 04 12 00 03 09 06 01 01 01 08 02 FF 0F 02 12 00 00//第4个数据项：A+ T2 

02 04 12 00 03 09 06 01 01 01 08 03 FF 0F 02 12 00 00//第5个数据项：A+ T3 

02 04 12 00 03 09 06 01 01 01 08 04 FF 0F 02 12 00 00//第6个数据项：A+ T4 

02 04 12 00 04//接下一个数据块中

客户端: 7E A0 1C 48 68 FE FF 75 76 XX XX E6 E6 00 C0 02 81 00 00 00 01 XX XX 7E

c0 02// get-request-next

81 00 00 00 01//已经接收第一个数据块

服务端: 7E A0 LL 75 48 68 FE FF 96 XX XX E6 E7 00 C4 02 81 00 00 00 00 02 00 73 09 06 01 01 01 06 01 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 06 02 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 06 03 FF 0F 02 12 00 00 02 04 12 00 03 09 06 01 01 01 06 04 FF 0F 02 12 00 00 … XX XX 7E

C4 02//Get-Response-With-Datablock

81// invoke-id and priority

00//不是最后的数据块

00 00 00 02//数据块序号 2

00//raw-data，表明回复的是数据；如果为01则表示回复的是data-access-result

73//此数据块长度

09 06 01 01 01 06 01 FF…//接上一数据块的后续数据

客户端: 7E A0 1C 48 68 FE FF 75 98 XX XX E6 E6 00 C0 02 81 00 00 00 02 XX XX 7E

服务端: 7E A0 LL 75 48 68 FE FF B8 XX XX E6 E7 00 C4 02 81 FF 00 00 00 03 00 LL …XX XX 7E

C4 02//Get-Response-With-Datablock

81// invoke-id and priority

FF//是最后的数据块

00 00 00 03//数据块序号 3

…//剩余的数据

客户端: 7E A0 1C 48 68 FE FF 75 BA XX XX E6 E6 00 C0 02 81 00 00 00 03 XX XX 7E

读数据不成功情况的典型原因

1. 不支持的读操作，如表计中只支持get-response-normal的读操作，而试图用get-response-with-datablock或者其他来读数据，如CTT发送：7EA0190321326FD8E6E600C004C1000F0000280000FF0100DAF97E，则表计回应的get.response数据域中应该为01 0C（scope-of-access-violated）
2. Get.Request的数据域中缺少参数或者没有的OBIS，比如缺少Class ID和属性，CTT发送：7EA0150321767B4BE6E600C001C1000028000100C23A7E或者7EA0190321BA2FD0E6E600C001C1000FFFFFFFFFFFFF0100EF6C7E，则表计回应的get.response数据域中应该为01 04（object-undefined）
3. 读取对象不存在的属性，如CTT发送：7EA0190321FE0FD4E6E600C001C1000F0000280000FF090039B77E，则表计回应的get.response数据域中应该为01 03（read-write-denied）

写操作(Set)

分为Set. Request和Set.Response。

Set. Request

数据设置请求帧

SET-Request::=CHOICE

{

Normal-Set-request                   [1] IMPLICIT Set-request-pdu

Set-request-with-first-datablock        [2]IMPLICIT Set-request-with-first-datablock-pdu

Set-request-with-datablock            [3] IMPLICIT Set-request-with-datablock-pdu

Normal-Set-request-with-list           [4] IMPLICIT Set-request-with-list-pdu

Set-request-with-list-and-first-datablock  [5]IMPLICIT Set-request-with--list-and-first-datablock-pdu

}

Set-request-PDU::=SEQUENCE

{

invoke-id-and-priority Invoke-Id-And-Priority,

Class-ld        COSEM-CLASS-ID,

Instance-ld      COSEM-OBJECT-INSTANCE-ID,

Attribute-ld      COSEM-OBJECT-ATTRIBUTE-ID,

Access_Selection  selective-access-descriptor OPTIONAL,

Value             Data

}

Set-Request-With-First-Datablock ::= SEQUENCE 

{ 

invoke-id-and-priority                Invoke-Id-And-Priority, 

cosem-attribute-descriptor           Cosem-Attribute-Descriptor, 

access-selection                    Selective-Access-Descriptor OPTIONAL, 

datablock                          DataBlock-SA 

} 

DataBlock-SA ::= SEQUENCE -- SA == DataBlock for the SET.request and ACTION.request services 

{ 

last-block                    BOOLEAN, 

block-number                Unsigned32, 

raw-data                    OCTET STRING 

} 

以设置时钟时间为例：

客户端:7E A0 29 48 68 FE FF 75 98 XX XX E6 E6 00 C1 01 81 00 08 00 00 01 00 00 FF 02 00 09 0C 07 D2 0C 04 03 0A 06 0B FF 00 78 00 XX XX 7E

解释:

7E A0 27 95 75 98 B8 DB E6 E6 00//Hdlc head

C1 01// SET.normal request（在DLMS认证第一阶段，规约里所有的设置操作ID均为C101)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

00 08// class id

00 00 01 00 00 FF// LN

02// set the 2nd attribute, time

00// haven’t access-selection-parameters

09 0C 07 D2 0C 04 03 0A 06 0B FF 00 78 00// just SET the value read before

XX XX 7E//HDLC Tail

Set. Response

数据设置响应。

SET-Response::=CHOICE

{

Normal-Set-response             [1] IMPLICIT Set-response-pdu

Set-response-datablock        [2] IMPLICIT Set-response-for-datablock-pdu

Set-response-last-datablock    [3] IMPLICIT Set-response-for-last-datablock-pdu

Set-response-for-last-datablock-with-list [4]IMPLICIT Set-response-for-last-datablock-with-list-pdu

Set-response-with-list             [5]IMPLICIT  Set-response-with-list-pdu

}

Set-response-PDU::=SEQUENCE

{

invoke-id-and-priority Invoke-Id-And-Priority,

result Get-Data-Result

}

Get-Data-Result ::= CHOICE

{

data                         [0] Data,

data-access-result             [1] IMPLICIT Data-Access-Result

}

Set-Response-Datablock ::= SEQUENCE 

{ 

invoke-id-and-priority       Invoke-Id-And-Priority, 

block-number             Unsigned32 

} 

Set-Response-Last-Datablock ::= SEQUENCE 

{ 

invoke-id-and-priority       Invoke-Id-And-Priority, 

result                     Data-Access-Result, 

block-number              Unsigned32 

} 

已设置时间回应为例，设置成功情况如下：

服务端：7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00 C5 01 81 00 XX XX 7E

解释:

7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00//Hdlc head

C5 01// SET.normal response（在DLMS认证第一阶段，规约里所有的设置操作响应ID均为C501)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

00// success

XX XX 7E//HDLC Tail

设置失败，如temporary-failure：

服务端：7E A0 13 75 48 68 FE FF B8 XX XX E6 E7 00 C5 01 81 01 02 XX XX 7E

解释:

7E A0 13 75 48 68 FE FF B8 XX XX E6 E7 00//Hdlc head

C5 01// SET.normal response（在DLMS认证第一阶段，规约里所有的设置操作响应ID均为C501)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

01// data-access-result [1] IMPLICIT Data-Access-Result

02 //temporary-failure

XX XX 7E//HDLC Tail

设置数据块

当一次设置的数据量很大时可采用Set-request-with-first-datablock/ Set-request-with-datablock的方式实现，以设置节假日为例：

客户端:7E A0 29 48 68 FE FF 75 54 XX XX E6 E6 00 C1 02 81 00 0B 00 00 0B 00 00 FF 02 00 00 00 00 00 01 BA 01 14 02 03 12 07 D8 09 05 FF FF 01 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 02 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 03 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 04 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 05 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 06 01 FF 11 01 02 03 12 07 D8 09 05 XX XX 7E

C1 02//Set-request-with-first-datablock

81// invoke-id and priority

00 0B 00 00 0B 00 00 FF 02 00//设置项的CLASS ID\OBIS和属性等

00//不是最后一个数据块

00 00 00 01//第1数据块

BA//数据块长度

01 14//20个节假日

02 03 12 07 D8 09 05 FF FF 01 01 FF 11 01//第1个节假日

02 03 12 07 D8 09 05 FF FF 02 01 FF 11 01//第2个节假日

…

02 03 12 07 D8 09 05//续下一个数据块

服务端：7E A0 13 75 48 68 FE FF 74 XX XX E6 E7 00 C5 02 81 00 00 00 01 XX XX 7E

C5 02//Set-response-datablock

00 00 00 01//收到第1数据块

客户端:7E A0 29 48 68 FE FF 75 76 XX XX E6 E6 00 C1 03 81 00 00 00 00 02 LL FF FF 07 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 08 01 FF 11 01 … XX XX 7E

C1 03//Set-request-with-datablock

81// invoke-id and priority

00//不是最后一个数据块

00 00 00 02//第2数据块

LL//数据块长度

FF FF 07 01 FF 11 01 02 03 12 07 D8 09 05 FF FF 08 01 FF 11 01 … //紧接上一数据快数据

服务端：7E A0 13 75 48 68 FE FF 96 XX XX E6 E7 00 C5 02 81 00 00 00 02 XX XX 7E

//收到第2数据块

客户端:7E A0 29 48 68 FE FF 75 98 XX XX E6 E6 00 C1 03 81 FF 00 00 00 03 LL… XX XX 7E

C1 03//Set-request-with-datablock

81// invoke-id and priority

00//不是最后一个数据块

00 00 00 03//第3数据块

LL//数据块长度

… //紧接上一数据快数据

服务端：7E A0 13 75 48 68 FE FF 96 XX XX E6 E7 00 C5 03 81 00 00 00 00 03 XX XX 7E

C5 03//Set-response-last-datablock

81//

00// Data-Access-Result:OK

00 00 00 03//收到弟3数据块

写数据不成功情况的典型原因

1. 不支持的写操作，如表计中只支持Normal-Set-request l的写操作，而试图用其他来写数据，如CTT发送：7EA0210321324571E6E600C106C1000F0000280000FF010009060000280000FF4F967E则表计回应的get.response数据域中应该为01 0C（scope-of-access-violated）
2. Set.Request的数据域中缺少参数或者没有的OBIS，比如缺少Class ID和属性  
3. 设置对象不存在的属性

方法操作(Action)

分为ACTION Request和ACTION.Response。

ACTION. Request

ACTION-Request::=CHOICE

{

Normal-Action-request        [1] IMPLICIT Normal-Action-request-pdu

Action-request-for-next-pblock   [2] IMPLICIT Action-request-for-next-pblock-pdu

Action-request-with-list          [3] IMPLICIT Action-request-with-list-pdu

Action-request-with-list-and-first-pblock    [4] IMPLICIT  Action-request-with-list-and-first-pblock-pdu

Action-request-with-pblock      [5]IMPLICIT Action-request-with-pblock-pdu

}

Normal-Action-request-pdu::=SEQUENCE

{

invoke-id-and-priority Invoke-Id-And-Priority,

Class-ld                    COSEM-CLASS-ID,

Instance-ld                  COSEM-OBJECT-INSTANCE-ID,

Method-ld                  COSEM-OBJECT-OPERATION-ID,

Method_Inv_Params           Data OPTIONAL,（有些执行动作需要带参数）

}

以清当前正向有功电量为例：

客户端:7E A0 1C 48 68 FE FF 75 98 XX XX E6 E6 00 C3 01 81 00 03 01 01 01 08 00 FF 01 00 XX XX 7E

解释:

7E A0 1c 48 68 FE FF 75 98 xx xx E6 E6 00//Hdlc head

C3 01// ACTION.normal request（在DLMS认证第一阶段，规约里所有的执行操作ID均为C301)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

00 03// class id

01 01 01 08 00 FF//  正向有功总电量的LN

01 // Action the 1nd method, reset()

00// haven’t data

XX XX 7E//HDLC Tail

ACTION. Response

ACTION-Response::=CHOICE

{

 Normal-Action-response            [1] IMPLICIT Normal-Action-response-pdu

 Action-Response-with-pblock       [2] IMPLICIT Action-response-with-pblock-pdu

Action-Response-with-list           [3] IMPLICIT Action-response-with-list-pdu

Action-Response-for-next-pblock    [4] IMPLICIT  Action-Response-for-next-pblock-pdu

}

Normal-Action-response-pdu::=SEQUENCE

{

invoke-id-and-priority    Invoke-Id-And-Priority,

single-response          Action-Response-With-Optional-Data

}

Action-Response-With-Optional-Data ::= SEQUENCE 

{ 

result                    Action-Result, 

return-parameters         Get-Data-Result OPTIONAL 

} 

Action-Result::=ENUMERATED

{

      success                  (0),

      hardware-fault           (1),

      temporary-failure        (2),

      read-write-denied        (3),

      object-undefined         (4),

      object-class-inconsistent(9),

      object-unavailable       (11),

      type-unmatched           (12),

      scope-of-access-violated (13),

      data-block-unavailable   (14),

      long-action-aborted      (15),     --这是新类型

      no-long-action-in-progress(16),    --这是新类型

      other-reason             (250)     --这是新类型

}

已清正向有功电量回应为例，设置成功情况如下：

服务端：7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00 C7 01 81 00 XX XX 7E

解释:

7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00//Hdlc head

C7 01// ACTION.normal response（在DLMS认证第一阶段，规约里所有的设置操作响应ID均为C701)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

00// success

XX XX 7E//HDLC Tail

设置失败，如other-reason：

服务端：7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00 C7 01 81 FF XX XX 7E

解释:

7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00//Hdlc head

C7 01// ACTION.normal response（在DLMS认证第一阶段，规约里所有的设置操作响应ID均为C501)

81// invoke-id(000 0001) and priority(1) （数据域数据不超过数据域规定长度时，固定为81，超过则为8C）

FF// RESULT：other-reason             (255)

XX XX 7E//HDLC Tail

事件上报(Event notification)

事件上报不需要链路层及应用层的链接。分为两种情形：服务端直接上报和客户端触发后服务端上报。

客户端触发方式

暂不考虑此种模式。

直接上报

当服务端和客户端没有建立物理连接时，服务端需要先主动建立物理层连接（如TCP模式时发送心跳包）。例如发生某故障，故障寄存器需上报其状态，则帧如下：

服务端：7E A0 LL 75 48 68 FE FF 13 XX XX E6 E7 00 C2 01 07 D8 06 19 14 0A 32 02 00 00 00 00 00 01 01 00 61 61 00 FF 02 06 RR RR RR RR XX XX 7E 

7E A0 LL 75 48 68 FE FF 13 XX XX E6 E7 00//与前面服务含义一致，要注意的是：控制字有区别，由于事件上报为UI（无序信息）帧，因此其控制字为0x13，参考2.3.

c2// Event_notification_request

01//出现时间

07 d8 06 19 14 0a 32 02 00 00 00 00//时间: 2008年6月 19日10 点32分2秒

00 01 01 00 61 61 00 FF 02//上报的对象的类号+OBIS+属性

06 RR RR RR RR//上报数据

XX XX 7E//帧尾

注：事件上报时如果有链路层的通信，那么上报帧可在一个信息帧后上报。

引用标准

1. IEC 62056-21, Electricity Metering-Data Exchange for Meter Reading, Tariff and Load Control-Part 21: Direct local data exchange.2001
2. IEC 62056-61, Electricity Metering-Data Exchange for Meter Reading, Tariff and Load Control-Part 61: Object Identification System（OBIS）. 2001
3. IEC 62056-62, Electricity Metering-Data Exchange for Meter Reading, Tariffand Load Control-Part 62: Interface Classes. 2001 Data exchange of automatic meter reading system
4. IEC62056-46, Electricity Metering-Data Exchange for Meter Reading, Tariff and Load Control-Part 46: Data link layer using HDLC protocol
5. IEC 62056-53, Electricity Metering-Data Exchange for Meter Reading, Tariff and Load Control-Part 53: COSEM Application Layer. 2001
6. IEC 61334-6, A-XDR encoding rule