当前位置:首页 >> 信息与通信 >>

规约dlms111


DLMS/COSEM 规约解析(本地部分)

IEC62056-21 E 模式规约解析

版本:V2.2 日期:2008-11-12

1

DLMS/COSEM 规约解析(本地部分)

版本记录
版本 1.0
2.0 2.1 2.2

期 2008-7-2
2008-11-12 2008-12-18 2009-3-27

作者 姚青 姚青 姚青 姚青

说明 首次编制定稿 增加读写数据块的说明 增加有关 SNRM 帧中有关参数说明 增加事件上报说明

2

DLMS/COSEM 规约解析(本地部分)

Contents
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 ..................................................................................... 26 4.2.2. Get. Response .................................................................................. 27 4.2.3. 读数据块.......................................................................................... 30 4.2.4. 读数据不成功情况的典型原因...................................................... 31 4.3. 写操作(Set) ................................................................................................ 31 4.3.1. Set. Request ..................................................................................... 31 4.3.2. Set. Response ................................................................................... 32 4.3.3. 设置数据块...................................................................................... 34 4.3.4. 写数据不成功情况的典型原因...................................................... 35 4.4. 方法操作(Action) ....................................................................................... 35 4.4.1. ACTION. Request .............................................................................. 35 4.4.2. ACTION. Response ........................................................................... 36 4.5. 事件上报(Event notification) ..................................................................... 37 4.5.1. 客户端触发方式.............................................................................. 37 4.5.2. 直接上报.......................................................................................... 38 5. 引用标准............................................................................... 错误!未定义书签。
3

DLMS/COSEM 规约解析(本地部分)

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

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

本页及以后的文字中“客户端”和“主站”均指抄表端,而“服务端”和“从站”均指表计,字体为灰色 的部分 DLMS 认证第一阶段暂不考虑 4

DLMS/COSEM 规约解析(本地部分)

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地址存在。
5

DLMS/COSEM 规约解析(本地部分)

? ?

两字节:一字节高端HDLC地址和一字节低端HDLC地址。 四字节:两字节高端HDLC地址和两字节低端HDLC地址。

上述三种情况在下图说明。 一字节地址结构:
LSB 高端HDLC地址 1

两字节地址结构:
LSB 高端HDLC地址 第一字节 0 低端HDLC地址 第二字节 LSB 1

四字节地址结构:

LSB LSB 高端HDLC 高字节 第一字节 0 高端HDLC 低字节 第二字节 0

LSB 低端HDLC 高字节 第三字节 0

LSB 低端HDLC 高字节 1

第四字节

这种可变长度HDLC地址结构为每字节保留了一位来标示所给字节是最后一字节还是有 字节跟随。这意味着一字节地址的地址范围是0…0x7F,两字节地址的地址范围是 0…0x3FFF。 单独的,多播及广播的寻址可由高端HDLC地址和低端HDLC地址方便提供。 例如,一个HDLC帧以下列地址从客户机端发送到服务器端: 客户HDLC地址 = 3AH = 00111010B 服务器HDLC地址(用四字节寻址) 低端HDLC地址= 3FFFH = 0011111111111111B 高端HDLC地址 = 1234H = 0001001000110100B 消息地址域应包含以下8位字组:
服务器地址
高端HDLC,高字节 高端HDLC,低字节 低端HDLC,高字节 低端HDLC,低字节

ALL_STATION(广播)地址

客户机地址
HDLC 地址

LSB 0100100 第一字节 目的地址 4868FEFF 0 0110100 第二字节

LSB 0 1111111 第三字节

LSB 0 1111111 第四字节

LSB 1 0111010 第五字节 源地址 75

LSB 1

控制域格式
命令/应答帧控制字段的编码方式为模式8,如ISO/IEC 13239的5.5及下表规定。 表7 控制字段格式
MSB LSB
6

DLMS/COSEM 规约解析(本地部分)

I RR RNR SNRM DISC UA DM FRMR UI

R R R 1 0 0 0 1 0

R R R 0 1 1 0 0 0

R R R 0 0 1 0 0 0

P/F P/F P/F P P F F F P/F

S 0 0 0 0 0 1 0 0

S 0 1 0 0 0 1 1 0

S 0 0 1 0 1 1 1 1 1 1 1 1 1 1 1

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

7

DLMS/COSEM 规约解析(本地部分) 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)。

8

DLMS/COSEM 规约解析(本地部分)

链路层链接与断开
链路层的链接
链路层的连接包括客户端发送的 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 05H 01H 80H 06H 01H 80H 07H 04H 00H 00H 00H 01H 08H 04H 00H 00H 00H 01H 格式标识符 组标识符 组长(18字节) 参数标识符(最大信息字段长度,发送) 参数长度(1字节) 参数值 参数标识符(最大信息字段长度,接收) 参数长度(1字节) 参数值 参数标识符(窗口大小,发送) 参数长度(4字节) 参数值(值高字节) 参数值 参数值 参数值(值低字节) 参数标识符(窗口大小, 接收) 参数长度 参数值(值高字节) 参数值 参数值 参数值(值低字节)

在多字节字段中(如例子中)最高位码位在最先传送的八位字节中。 当信息域存在时, 前两个字节-格式标识符(81H)和组标识符(80H)一直会存在。 但任何(一 个或多个)协商参数可以缺省。
9

DLMS/COSEM 规约解析(本地部分)

信息域缺省的解释意味着每个参数都是缺省值。 如果从站接收到一正确SNRM帧并且连接请求能被接受,它将用UA帧应答。此UA帧应 带有HDLC参数的协商结果。 对应于从站接收的参数值(随SNRM帧发送),以及随UA帧接收到的参数值之间选择 较小的值来计算结果。 例如:通过SNRM/UA帧的参数协商值示例
建议参数/值(通过接收SNRM帧) 最大传送信息字段(05H)/ 80H(128D) 最大接收信息字段(06H)/ 80H(128D) 窗口大小 – 传送(07H)/0001H (1D) 窗口大小 – 接收 (08H)/0007H (7D) 对应参数值,可能被从站使用。 最大接收信息字段(06H)/ 40H (64D) 最大传送信息字段(05H)/ 80H(128D) 窗口大小 – 接收 (08H)/0007H (7D) 窗口大小– 传送(07H)/0007H (7D) 结果(从从站看发送/接收方向) 最大接收信息字段(06H)/ 40H (64D) 最大传送信息字段(05H)/ 80H (128D) 窗口大小 – 接收 (08H)/0001H (1D) 窗口大小– 传送(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

10

DLMS/COSEM 规约解析(本地部分)

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

4.0.1.

编码规则

BER 编码由三部分构成:类型,长度及值,如下图。
Identifier Length Contents

那么表达多项内容时则由一系列字节构成,如下:
I1 L1 I2 L2 I3 L3 C3 C2 C1 I4 L4 C4 I5 L5 C5 I6 L6 C6

A-XDR 编码规则与 BER 编码类似,只是 A-XDR 编码省略了冗余的类型和长度部分,比如 类型为 integer8 时,从类型便可看出长度为 1 个字节,因此可以省略掉长度部分。A-XDR 编码结构如下:
I1 L1 L2 C3 I4 L4 C2 C1 C4 L5 C5 C6 L7 C7 C8 I9 L9 C9

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

4.0.2.

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 {version1}. Application-context-name Called-ap-title Called-AE-qualifier [1]application-context-name. [2] AP-title OPTIONAL, [3] AE-qualifier OOPTIONAL,
11

[0] IMPLICIT BIT STRING

{VERSION1 (0)} DEFAULT

DLMS/COSEM 规约解析(本地部分)

Called-AP- invocation-id Called-AE-invocation-id Calling-AP-title Calling-AE-qalifier Calling-AP-invocation-id Calling-AE-invocation-id Sender-acse-requirements Mechanism-name Calling-authentication-value Implementation-information User-information } and

[4] AP-invocation-identifier OPTIONAL, [5] AE-invocation-identifier OPTIONAL, [6] AP-title OPTIONAL, [7] AE-qualifier OPTIONAL, [8] AP-invocation-identifier OPTIONAL, [9] AE-invocation-identifier OPTIONAL, [10] IMPLICIT ACSE-requirements OPTIONAL, [11] IMPLICIT mechanism-name OPTIONAL, [12] EXPLICIT Authentication-value OPTIONAL, [29] IMPLICIT Implementation-data OPTIONAL, [30] IMPLICIT Association-information OPTIONAL,

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

AARE-apdu::=[APPLICATION 1] IMPLICIT SEQUENCE { protocol-version {version1}, application-context-name result result-source-diagnostic responding-ap-title responding-ae-qualifier responding-AP-invocation-id responding-ae-invocation-id Responder-acse-requirements Mechanism-name FUNCTIONAL UNIT IS SELED. Responding-authentication-value Implementation-information User-information } [10] EXPLICIT Authentication-value OPTIONAL, [29] IMPLICIT implementation-OPTIONAL, [30] IMPLICIT Association-information OPTIONAL [1] application-context-name, [2] association-result, [3] associate-source-diagnostic, [4] ap-title OPTIONAL, [5] ae-qualifier OPTIONAL, [6] ap-invocation-identifier OPTIONAL, [7] ae-invocation-identifier OPTIONAL, [8] IMPLICIT ACSE-requirements OPTIONAL, [9] IMPLICIT Mechanism-name OPTIONAL, [0] IMPLICIT BIT STRING {VERSION1 (0)} DEFAULT

----the following field shall not be present if only the kernel is used. ----the following field shall only be present if the authentication functional unit is selected. ----THE FOLLOWING FIELD SHALL ONLY BE PRESENT IF THE AUTHENTICATION

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

12

DLMS/COSEM 规约解析(本地部分)

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

? mechanism-name: 当 存 在 的 时 候 , 它 包 括 验 证 机 制 的 名 字 。 calling- and responding-authentication value:: 当存在的时候,它的值由特定的实现决定, 并且超出 这文件的范围。 ? implementation-information::该域留给将来使用。 user-information::该八位位串总是存在,在AARQ-pdu的情况下该域包含 DLMS-InitiateRequest-pdu;在AARE-pdu.的情况下该域包含DLMS-InitiateResponse-pdu或 DLMS-ConfirmedServiceError-pdu。该域信息可选择性加密。 ? result:: ? result-source-diagnostics: 这些域传送关联请求的结果和关联拒绝的最终原因,按照 ISO/IEC/TR2 8650-1(1996-12)中的规定,当不包括诊断的时候,该域赋空值。

4.0.3.

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 response-allowed proposed-quality-of-service proposed-dlms-version-number proposed-conformance client-max-receive-pdu-size } OCTET STRING OPTIONAL, BOOLEAN DEFAULT TRUE, [0] IMPLICIT Integer8 OPTIONAL, Unsigned8, Conformance, 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 1 0

BITSTRIN G 的值 00 BC 1F 1C 03 20

LN SN

0 0

0 0

0 0

0 1

0 1

0 1

0 0

0 0

1 0

0 0

1 0

1 0

1 0

1 0

0 1

0 1

0 0

0 0

0 1

1 0

1 0

1 0

1 0

这个建议一致块中的 LN 引用意思是: 支持优先管理(09 位) 支持 0 属性参照(10 位) 支持由 GET 服务完成的块传输(11 位)

13

DLMS/COSEM 规约解析(本地部分)

支持由 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 引用 00 BC 1F //固定长度比特串值的编码 SN 引用 1C 03 20 //固定长度比特串值的编码

------编码客户端最大接收 PDU 大小成分 (16 位无符号整型,值为 0x4B0) 04B0 //一个 16 位无符号整型的 A-XDR 编码是它的值 所以,根据给定的参数, DLMS Initiate.request-pdu 的 A-XDR 编码结果如下面的八位位组序 列: LN 引用 DLMS-Initiate.req-pdu: 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0 SN 引用 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)}
14

DLMS/COSEM 规约解析(本地部分)

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 引用 60 85 74 05 08 01 01 BE 0F 04 0D SN 引用 60 85 74 05 08 01 02

----用户信息域(标志成分,[30]) 的编码 //用户信息域 ([30],明确文本)标志的编码 //标志成分值域的长度的编码 ----应用上下文名字成分的编码(八位字节字符串) //用户信息的选择编码(八位字节字符串,通用) //八位字节字符串的值域长度编码(13 字节) //下面是 DLMS-Initiate.request-pdu 的八位字节序列: SN 引用 01 00 00 00 06 5F 04 00 1C 03 20 04 B0 SN 引用 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]

LN 引用 01 00 00 00 06 5F 04 00 00 BC 1F 04 B0 LN 引用 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 APDU 的完整编码如下(所有数都是 16 进数)

15

DLMS/COSEM 规约解析(本地部分)

4.0.4.

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

让我们回忆一下关于AARE APDU 的ASN.1规范:
AARE-apdu::=[APPLICATION 1] IMPLICIT SEQUENCE { protocol-version result responding-AP-title responding-AE-qualifier [0] IMPLICIT BIT STRING{versio1(0)}DEFAULT{version1} [1] Application-context-name [3] Associate-source-diagnostic [4] AP-titile OPTIONAL [5] AE-qualifier OPTIONAL [2] Association-result application-context-name result-source-diagnostic

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 negotiated-dlms-version-number negotiated-conformance server-maax-receive-pdu-size vaa-name } [0] IMPLICIT Integer8 OPTIONAL Unsigned8 Conformance Unsigned16 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 1 0

BITSTRIN G 的值 00 50 1F 1C 03 20

LN SN

0 0

0 0

0 0

0 1

0 1

0 1

0 0

0 0

0 0

1 0

0
0

1 0

0
0

0
0

0
1

0 1

0 0

0 0

0 1

1 0

1 0

1 0

1 0

16

DLMS/COSEM 规约解析(本地部分)

这个 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 引用 这 个 连 接 分 配 了 一 个 VAA 的 虚 拟 名 字 (0x0007)。 SN 引用 返回一个标准的 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 引用 00 50 1F SN 引用 1C 03 20

------编码服务器端最大接收 PDU 大小成分 (16 位无符号整型,值为 0x1F4) 01 F4 //16 位无符号整型的 A-XDR 编码是它的值 -----编码 VAA-NAME 成分 (16 位无符号整型,值为 0x0007) //16 位无符号整型的 A-XDR 编码是它的值 LN 引用 00 07
下:

SN 引用 FA 00

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

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

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

这个八位字节序列将被作为一个OCTET STRING加入到AARE APDU的用户信息域。 我们设想一下,为了ACSE的应用,服务器接受包含下述应用上下文的关联建议:
17

DLMS/COSEM 规约解析(本地部分)

? ?

协议版本是缺省的ACSE?的版本? 应用上下文名字如下:?

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

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

没有使用验证: 机制名字和召唤验证值都没有呈现.? ? 不包含执行信息.? 根据这些参数,AARQ-pdu 的编码(BER)如下: -- BER编码AARE APDU 61 //编码AARE-pdu的标签([应用1],应用) 28 // AARE的内容域(40字节)的长度编码 // 不对协议版本编码,因此取它的默认值 --应用上下文名字成分编码(标志为 component[1]) A1 //应用上下文名字成分([1],指定上下文)标志编码 09 //特征成分的值域长度编码 --应用上下文名字成分的编码(对象标识符) 06 //应用上下文名字成分选择的编码(对象标识符,通用) 07 //对象标识符值域长度的编码(7个字节) // 对象标识符值的编码
?

LN 引用
60 85 74 05 08 01 01

SN引用
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, 通用)

18

DLMS/COSEM 规约解析(本地部分) 0D // OCTET STRING的值域的长度的编码 (13 八位字节 ) // 这里是DLMS-Initiate.response-pdu的八位字节序列

LN 引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07

SN引用
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 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 ]

SN引用
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 ]

4.0.5.

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 引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07

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

AARE的参数: ? ? ?协议版本式缺省的ACSE版本 ?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)} ? ? ? ?

没有使用验证: 机制名字和召唤验证值都没有呈现.
不包含实现信息 结果 = rejected-permanent 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引用
19

DLMS/COSEM 规约解析(本地部分)
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 引用
08 00 06 5F 04 00 00 50 1F 01 F4 00 07

SN引用
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 ]

4.0.6.

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的编 码中),指明失败的原因。 特定的确定服务错误消息如下:

20

DLMS/COSEM 规约解析(本地部分)

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的参数如下: ? ? 协议版本使用缺省的ACSE版本 Application-context-name: COSEM_Application_Context_NameLogical_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)} ?

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

21

DLMS/COSEM 规约解析(本地部分)

? ? ?

不包含执行信息.?
Result = rejected-permanent 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 ]

22

DLMS/COSEM 规约解析(本地部分)

4.0.7.

应用层链接失败原因(几乎包含了 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

2. 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

3. 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) 。。 。 4. AARQ 中有 implementation information,但是错误的信息 (暂不知道正确的信息应该是怎 样,GREEN book 第 4 版第 188 页中说到该参数没有在该文档中定义,但 CTT 发出的错误 信 息 知 道 ) 如 CTT 中 发 送 的
7EA0330321108289E6E6006025A109060760857405080101BD060544756D6D79BE10040E01000000065F1F04 00000019FFFF98547E A2 03 02 01 01 A3 05 A1 03 02 01 01

5.

AARQ 中 User-information 中 dedicated-key 出 现 即 不 为 00 , 如 CTT 中 发 送 的

7EA031032110F4B0E6E6006023A109060760857405080101BE16041401010544756D6D790000065F1F040000 0019FFFF09B17E A2 03 02 01 01 A3 05 A1 03 02 01 01

6.
7E

AARQ 中 User-information 中 proposed-dlms-version-number 小于 6,如 CTT 中发送的 7

EA02B032110FBAFE6E600601DA109060760857405080101BE10040E01000000055F1F0400000019FFFF2E9E

23

DLMS/COSEM 规约解析(本地部分) A2 03 02 01 01 A3 05 A1 03 02 01 01

7. AARQ 中 User-information 中 proposed-conformance 中服务与表计中支持的不相符,如: 信息中参数既支持 ln 引用又支持 sn 引用等。此处可以回复错误信息(应用层链接失败) , 也可以回复正确的 proposed-conformance 参数(应用层链接成功) 。如果回复错误信息,那 么为以下错误信息:
A2 03 02 01 01 A3 05 A1 03 02 01 01

8.
A47E

AARQ 中 User-information 中 client-max-receive-pdu-size 小于 12,如 CTT 中发送

7EA02B032110FBAFE6E600601DA109060760857405080101BE10040E01000000065F1F0400000019000B2C

A2 01

03

02

01

01

A3

05

A1

03

02

01

4.0.8.

帧实例

不使用安全机制: 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 24

DLMS/COSEM 规约解析(本地部分)

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。 02 02 09 0C 07 DA 04 19 FF 0B 28 01 00 80 00 01 11 28 这个是事件的数据块。。前面4字节 代表什么意思。。时间从07 DA 04 19 FF 0B 28 01 开始的最后的11是什么意思。28好像是40 开端钮盖。 02 -- 后边是结构体数据类型 节型 0C --- 包含12个字节 02----结构体内有两个量 09 --- 第一个量的数据类型为字 最后的11--第二个量的数据类型为无符号8位字符型

7E A0 1C 00 02 04 01 03 10 63 FE E6 E6 00 C0 01 81 00 07 00 00 63 62 00 FF 02 00 91 79 7E 这个是不带时间 7E A0 49 00 02 04 01 03 54 2F 78 E6 E6 00 C0 01 81 00 07 01 00 63 61 00 FF 02 01 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 19 07 DA 06 0A 04 0E 04 00 FF 80 00 00 19 07 DA 09 0A 05 0E 04 00 FF 80 00 00 00 70 C8 7E 段不一样。 不带时间的属性后面就是00,比如读属性02,那就是obis+属性+00.带时间的话就是属性+01+ 时间起始 那时间的起始还要加时间结束。01+ 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 19 07 DA 06 0A 04 0E 04 00 FF 80 00 00 19 07 DA 09 0A 05 0E 04 00 FF 80 00 00 00 70 C8 7E。。就是从+的后面怎么解析。 02 04 12 00 08 09 06 00 00 01 00 00 FF 0F 02 12 00 00 是一个结构体,代表选择的参数 是时间 12 00 08代表时间的class id;09 06 00 00 01 00 00 FF是时间的obis;0F 02是属性2; 12 00 00是索引这个是固定的 19 07 DA 06 0A 04 0E 04 00 FF 80 00 00 19 07 DA 09 0A 05 0E 04 00 FF 80 00 是时间 的起始结束,19是数据类型date-time;07 DA 06 0A 04 0E 04 00 FF 80 00 00 是起始时间; 19 07 DA 09 0A 05 0E 04 00 FF 80 00是结束时间 这个是带时间段的 是 不是带时间段的只是时间那块不一样, 如果换成读其他事件其他的地方都一样只是OBIS和时间

25

DLMS/COSEM 规约解析(本地部分)

19 07 DA 06 0A 04 0E 04 00 FF 80 00 00 00就是开始时间和结束时间了。。 后面两个00固定

-

19 07 DA 09 0A 05 0E 04 00 FF 80 00 00

那如果换成其他的事件的话只是OBIS和19 07 DA 06 0A 04 0E 04 00 FF 80 00 00 07 DA 09 0A 05 0E 04 00 FF 80 00 00 00变化的。。

-

19

4.1.1.

Get. Request

数据请求帧
GET-Request ::= CHOICE { get-request-normal get-request-next get-request-with-list } Get-Request-Normal ::= SEQUENCE { invoke-id-and-priority cosem-attribute-descriptor access-selection-parameters } Get-Request-Next ::= SEQUENCE { invoke-id-and-priority block-number } Cosem-Attribute-Descriptor ::= SEQUENCE { class-id Cosem-Class-Id, instance-id Cosem-Object-Instance-Id, attribute-id Cosem-Object-Attribute-Id } Invoke-Id-And-Priority, Unsigned32 Invoke-Id-And-Priority, Cosem-Attribute-Descriptor, Selective-Access-Descriptor OPTIONAL [1] IMPLICIT Get-Request-Normal, [2] IMPLICIT Get-Request-Next, [3] IMPLICIT Get-Request-With-List

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

26

DLMS/COSEM 规约解析(本地部分)

以请求反向有功为例:
客户端: 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)没超过128 直接就一个字节,超过128字节,则加81 后 边的字节是长度,超过255字节,则加82 后边的2个字节是长度 00 03//Class id 01 01 02 08 00 ff //反向总有功 OBIS 02 //反向总有功的第二属性,值域。 00 // haven’t access-selection-parameters XX XX 7E //HDLC Tail

4.1.2.

Get. Response

数据响应帧。
GET-Response ::= CHOICE { get-response-normal get-response-with-datablock get-response-with-list } Get-Response-Normal ::= SEQUENCE { invoke-id-and-priority result } Get-Response-With-Datablock ::= SEQUENCE { invoke-id-and-priority result } Get-Data-Result ::= CHOICE { data [0] Data, data-access-result [1] IMPLICIT Data-Access-Result } Data ::= CHOICE
27

[1] IMPLICIT Get-Response-Normal, [2] IMPLICIT Get-Response-With-Datablock, [3] IMPLICIT Get-Response-With-List

Invoke-Id-And-Priority, Get-Data-Result

Invoke-Id-And-Priority, DataBlock-G

DLMS/COSEM 规约解析(本地部分)

{ null-data array structure boolean bit-string double-long floating-point octet-string visible-string time bcd integer long unsigned long-unsigned compact-array { contents-description array-contents } long64 long64-unsigned enum float32 float64 don’t-care } Data-Access-Result ::= ENUMERATED { success hardware-fault temporary-failure read-write-denied object-undefined object-class-inconsistent object-unavailable type-unmatched scope-of-access-violated data-block-unavailable (0), (1), (2), (3), (4), (9), (11), (12), (13), (14), [20] IMPLICIT Integer64, [21] IMPLICIT Unsigned64, [22] IMPLICIT ENUMERATED, [23] IMPLICIT OCTET STRING (SIZE(4)), [24] IMPLICIT OCTET STRING (SIZE(8)), [255] IMPLICIT NULL [0] TypeDescription, [1] IMPLICIT OCTET STRING [0] IMPLICIT NULL, [1] IMPLICIT SEQUENCE OF Data, [2] IMPLICIT SEQUENCE OF Data, [3] IMPLICIT BOOLEAN, [4] IMPLICIT BIT STRING, [5] IMPLICIT Integer32, [7] IMPLICIT OCTET STRING(SIZE(4))33, [9] IMPLICIT OCTET STRING, [10] IMPLICIT VisibleString, [11] IMPLICIT GeneralizedTime, [13] IMPLICIT Integer8, [15] IMPLICIT Integer8, [16] IMPLICIT Integer16, [17] IMPLICIT Unsigned8, [18] IMPLICIT Unsigned16, [19] IMPLICIT SEQUENCE

double-long-unsigned [6] IMPLICIT Unsigned32,

28

DLMS/COSEM 规约解析(本地部分)

long-get-aborted no-long-get-in-progress long-set-aborted no-long-set-in-progress other-reason }

(15), (16), (17), (18), (250)

DataBlock-G ::= SEQUENCE -- G == DataBlock for the GET.response service { last-block block-number result { raw-data data-access-result } } [0] IMPLICIT OCTET STRING, [1] IMPLICIT Data-Access-Result CHOICE BOOLEAN, Unsigned32,

81 D3 01 0C

D3是数据块长度, 01--数组对象

0C--12个数组

81 DB 01 81 C8

DB-是数据块长度,

01---数组对象

C8--200个数组

当长度超过127字节时,带81 然后后续1个字节表示长度 超过255字节,带82,然后后续2个字节是长度

以响应“请求反向有功”为例,读数据成功:
服务端: 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

解释:

29

DLMS/COSEM 规约解析(本地部分)

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

4.1.3.

读数据块

当一次读取数据量较大时,表计可采用 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
30

DLMS/COSEM 规约解析(本地部分)

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

4.1.4.

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

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。

4.2.1.

Set. Request

数据设置请求帧
SET-Request::=CHOICE { Normal-Set-request Set-request-with-first-datablock Set-request-with-datablock Normal-Set-request-with-list Set-request-with-list-and-first-datablock }
31

[1] IMPLICIT Set-request-pdu [2]IMPLICIT Set-request-with-first-datablock-pdu [3] IMPLICIT Set-request-with-datablock-pdu [4] IMPLICIT Set-request-with-list-pdu [5]IMPLICIT

Set-request-with--list-and-first-datablock-pdu

DLMS/COSEM 规约解析(本地部分)

Set-request-PDU::=SEQUENCE { invoke-id-and-priority Class-ld Instance-ld Attribute-ld Access_Selection Value } Set-Request-With-First-Datablock ::= SEQUENCE { invoke-id-and-priority cosem-attribute-descriptor access-selection datablock } DataBlock-SA ::= SEQUENCE -- SA == DataBlock for the SET.request and ACTION.request services { last-block block-number raw-data } 以设置时钟时间为例:
客户端: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

Invoke-Id-And-Priority,

COSEM-CLASS-ID, COSEM-OBJECT-INSTANCE-ID, COSEM-OBJECT-ATTRIBUTE-ID, selective-access-descriptor OPTIONAL, Data

Invoke-Id-And-Priority, Cosem-Attribute-Descriptor, Selective-Access-Descriptor OPTIONAL, DataBlock-SA

BOOLEAN, Unsigned32, OCTET STRING

解释: 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

4.2.2.

Set. Response

数据设置响应。
SET-Response::=CHOICE
32

DLMS/COSEM 规约解析(本地部分)

{ Normal-Set-response Set-response-datablock Set-response-last-datablock [1] IMPLICIT Set-response-pdu [2] IMPLICIT Set-response-for-datablock-pdu [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 } Set-response-PDU::=SEQUENCE { invoke-id-and-priority result } Get-Data-Result ::= CHOICE { data data-access-result } Set-Response-Datablock ::= SEQUENCE { invoke-id-and-priority block-number } Set-Response-Last-Datablock ::= SEQUENCE { invoke-id-and-priority result block-number } Invoke-Id-And-Priority, Data-Access-Result, Unsigned32 Invoke-Id-And-Priority, Unsigned32 [0] Data, [1] IMPLICIT Data-Access-Result Invoke-Id-And-Priority, Get-Data-Result [5]IMPLICIT Set-response-with-list-pdu

已设置时间回应为例,设置成功情况如下:
服务端: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

33

DLMS/COSEM 规约解析(本地部分)

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

4.2.3.

设置数据块

当 一 次 设 置 的 数 据 量 很 大 时 可 采 用 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//不是最后一个数据块
34

DLMS/COSEM 规约解析(本地部分)

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数据块

4.2.4.

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

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。

4.3.1.

ACTION. Request

ACTION-Request::=CHOICE { Normal-Action-request Action-request-for-next-pblock Action-request-with-list [1] IMPLICIT Normal-Action-request-pdu [2] IMPLICIT Action-request-for-next-pblock-pdu [3] IMPLICIT Action-request-with-list-pdu [4] IMPLICIT

Action-request-with-list-and-first-pblock Action-request-with-list-and-first-pblock-pdu Action-request-with-pblock } Normal-Action-request-pdu::=SEQUENCE { invoke-id-and-priority Class-ld Instance-ld Method-ld Method_Inv_Params } 以清当前正向有功电量为例:

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

Invoke-Id-And-Priority, COSEM-CLASS-ID, COSEM-OBJECT-INSTANCE-ID, COSEM-OBJECT-OPERATION-ID, Data OPTIONAL,(有些执行动作需要带参数)

35

DLMS/COSEM 规约解析(本地部分) 客户端: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

4.3.2.

ACTION. Response

ACTION-Response::=CHOICE { Normal-Action-response Action-Response-with-pblock Action-Response-with-list Action-Response-for-next-pblock } Normal-Action-response-pdu::=SEQUENCE { invoke-id-and-priority single-response } Action-Response-With-Optional-Data ::= SEQUENCE { result return-parameters } Action-Result::=ENUMERATED { success hardware-fault temporary-failure read-write-denied object-undefined object-unavailable type-unmatched (0), (1), (2), (3), (4), (11), (12),
36

[1] IMPLICIT Normal-Action-response-pdu [2] IMPLICIT Action-response-with-pblock-pdu [3] IMPLICIT Action-response-with-list-pdu [4] IMPLICIT Action-Response-for-next-pblock-pdu

Invoke-Id-And-Priority, Action-Response-With-Optional-Data

Action-Result, Get-Data-Result OPTIONAL

object-class-inconsistent(9),

DLMS/COSEM 规约解析(本地部分)

scope-of-access-violated (13), data-block-unavailable long-action-aborted other-reason } 已清正向有功电量回应为例,设置成功情况如下:
服务端:7E A0 12 75 48 68 FE FF B8 XX XX E6 E7 00 C7 01 81 00 XX XX 7E

(14), (15), (250) --这是新类型 --这是新类型 --这是新类型

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

解释: 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 XX XX 7E//HDLC Tail

(255)

事件上报(Event notification)

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

4.4.1.

客户端触发方式

暂不考虑此种模式。

37

DLMS/COSEM 规约解析(本地部分)

4.4.2.

直接上报

当服务端和客户端没有建立物理连接时,服务端需要先主动建立物理层连接(如 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//帧尾 注:事件上报时如果有链路层的通信,那么上报帧可在一个信息帧后上报。

38


相关文章:
规约dlms111
规约dlms111_信息与通信_工程科技_专业资料。介绍标准的DLMS系统规约 DLMS/COSEM 规约解析(本地部分) IEC62056-21 E 模式规约解析 版本:V2.2 日期:2008-11-...
更多相关标签:
dl t645 2007 规约 | dl476规约 | dl476规约解析 | dl476规约报文解析 | ms111 | 戴尔ms111 | dell ms111 | ms111 t |