IEC6532 中文.docx
《IEC6532 中文.docx》由会员分享，可在线阅读，更多相关《IEC6532 中文.docx（37页珍藏版）》请在冰豆网上搜索。
IEC6532中文
附 录 A
（规范性附录）
面向连接的基于HDLC三层模型
A.1 引言
COSEM应用层仅是包含COSEM特定的服务组件、扩展的DLMS应用服务组件（xDLMS-ASE）的协议层。
该应用层可以使用各种不同的低层协议完成通信功能，一个完整的协议栈（包括应用层）称之为通信模型（参见第4章）。
通信模型的特征取决于：
∙低层协议层；
∙应用层中应用控制服务组件（ACSE）类型（面向连接或无连接）。
COSEM制定的第一个标准化的通信模型是一个面向连接的、基于HDLC的三层模型，该模型由三个协议层组成：
∙COSEM应用层，其应用层中包含面向连接的ACSE，在本部分中定义；
∙数据链路层，基于ISO/IEC13239HDLC协议，在IEC62056-46中定义；
∙物理接口层，在IEC62056-42中定义。
A.2 基于HDLC的数据链路层–综述
为了构建本通信模型，从HDLC标准ISO/IEC13239中选择下列内容：
∙非平衡连接模式的数据链路层操作）；
∙两通道交替数据传输；
∙选择HDLC类过程是UNC（非平衡操作正常响应模式类），采用UI帧扩展；
∙帧格式类型3；
∙非要素透明帧格式。
在非平衡连接模式数据链路操作中，要涉及两个或多个站，主站通过发送命令帧负责组织数据流和处理不可恢复的数据链路级出错情况，从站通过发送响应帧来响应主站的命令。
为了提供组播、广播以及从服务器到客户机的非请求信息传送功能，过程的UNC类的基本命令和响应集采用不计数信息（UI）帧进行扩展，以支持无连接的数据通信服务。
使用非平衡连接模式数据链路操作意味着客户机和服务器侧的数据链路层的HDLC帧集和状态机不相同。
基于HDLC的数据链路层服务
基于HDLC的数据链路层提供的服务包括：
∙数据链路层连接管理；
∙面向连接的数据通信（I帧）；
∙无连接的数据通信（UI帧）。
客户机侧的服务
图A.1概括了COSEM客户机应用层面向连接的基于HDLC三层通信模型中数据链路层服务。
图A.1客户机COSEM应用层使用的数据链路服务
对某些服务，对应于应用层（ASO）服务调用和支撑数据链路层服务调用之间的通信是直接的（例如，COSEM-OPEN.request服务调用直接意味着调用DLCONNECT.request服务）。
对其它服务，不能建立这种直接的服务映射。
服务器侧的服务
图A.2概括了COSEM服务器应用层使用面向连接的基于HDLC的三层通信模型中数据链路层的服务。
图A.2服务器COSEM应用层使用的数据链路服务
与客户机类似，对某些服务，应用层（ASO）服务调用和支撑数据链路层服务调用之间的通信是直接的，对其它服务，不能被建立这种直接的服务映射。
为了支持从服务器到客户机透明的长数据传送，服务器侧规定了本地的DLDATA.confirm服务。
面向连接的基于HDLC三层模型的特殊组件
支持应用连接的特别特征
在COSEM环境中，一个AA完全由客户机和服务器应用进程使用的一对低层SAPs所标识，换而言之，在应用连接和支持该AA的低层连接之间存在着一一对应的关系。
在基于HDLC的CO三层模型中，每个AA都与一个支撑数据链路层连接相对应，建立一个AA意味着建立一个客户机和服务器数据链路层之间的连接。
请求建立此连接的地址信息包含在COSEM-OPEN的Protocol_Connection_Parameters服务参数中，此信息包括下列数据：
Server_Lower_MAC_Address,（COSEM物理设备地址）
Server_Upper_MAC_Address,（COSEM逻辑设备地址）
Client_MAC_Address,
Server_LLC_Address,
Client_LLC_Address
任何一个服务器（目的站）的地址参数都可以包含特殊的地址（ALL_STATION，NO_STATION，等等），此外，此模型在建立连接时还要遵循下列规则：
∙COSEM-OPEN.request服务的User_Information服务参数（参见6.5.1.2）要插入到SNRMHDLC帧的“用户数据子字段”中，在建立数据链路连接时发送。
在服务器侧，如果接收到SNRM帧包含“用户数据子字段”，则此字段的内容应通过COSEM-OPEN.indication服务的user_information服务参数（参见6.6.1.2）传送给服务器的应用进程。
∙如果客户机应用层采用无确认的COSEM-OPEN.request服务调用（参照6.5.1.2）发送一个AARQ帧，则该帧应采用UI（不计数的信息）类型的HDLC帧来发送。
在COSEM中，通常通过断开低层连接来断开应用连接，参照6.5.2。
在面向连接的基于HDLC的三层模型中，调用COSEM-RELEASE.request服务原语将导致相应的HDLC连接的断开，数据链路层使用DISC命令帧并且UA/DM响应HDLC帧（参见IEC62056-46）。
对于AA的正常或异常断开，要遵循以下附加规则：
∙在COSEM-RELEASE.request服务中出现User_Information服务参数时（参见6.5.2.2），它应插入到DISCHDLC帧的“用户数据子字段”中，在断开数据链路连接时发送，如果被服务器接收到的DISC帧包含“用户数据子字段”，则此字段的内容应通过COSEMRELEASE.indication服务的user_information服务参数（参见6.6.1.2）传送给服务器的应用进程。
∙在COSEM-RELEASE.response服务中出现User_Information服务参数时（参见6.6.2.2），它应插入到UA或DMHDLC帧的“用户数据子字段”中发送，用于响应DISC帧。
如果客户机接收到的UA或DISC帧包含“用户数据子字段”，则此字段的内容应通过COSEM-RELEASE.confirm服务的user_information服务参数（参见6.5.2.3）传送给客户机的应用进程。
∙COSEM-ABORT.indication服务的诊断参数（参见6.5.2.4和6.6.2.3）可包含一个不计数信息的发送状态参数，这个参数指示当物理层异常终止指示时刻，数据链路层是否还有待发的不计数信息报文（UI），此参数的类型和值是本地发出的，它不在本部分范围之内。
数据通信服务的特别特征
在本模型中数据通信服务没有特别特征/服务参数，对数据通信服务，COSEM应用层是完全透明的。
确认的数据通信服务（GET/SET/ACTION–Read/Write）调用在数据链路层采用I帧传送，另一方面，无确认的数据通信服务调用采用UI帧传送。
因此，无确认服务的编码形式应放入一个HDLC帧中。
EventNotification服务的特别特征
在数据链路层EventNotificationAPDU采用HDLCUI帧传送，因此，与数据通信服务类似，本服务的编码形式也应放入一个HDLC帧中。
传送EventNotificationAPDU的HDLCUI帧的源和目的地址总是相同的。
源地址是管理逻辑设备（必选的）的HDLC地址（保留的HDLC地址为0x01），目的地址总是客户机管理应用进程的HDLC地址（保留的HDLC地址为0x01）。
非平衡的HDLC模型不允许采用实时的、非请求的方式发送一个协议数据单元，因此，在本模型中，通过调用客户机应用层的Trigger_EventNotification_sending服务原语来明确请求发送一个EventNotification帧（参见6.5.4.2）。
一旦调用该服务，客户机将发送一个空的UI帧，并使P/F位设为TRUE，允许服务器数据链路层发送事件通告帧，服务器数据链路层发送未觉的Event-Notification-RequestAPDU作为UI帧，并利用EventNotification.indication向客户机应用进行指示，至此，事件通告过程完成。
附 录 B
（规范性附录）
xDLMS应用服务组件
B.1 引言
COSEM方法的主要目的在于向商业领域为计量设备和系统提供面向COSEM接口对象的模型，同时保持对现有的DLMS标准向后的兼容性。
为达到这些目的，COSEM对DLMS进行了发展，在保持完全遵循DLMS标准的同时，COSEM可通过COSEM接口对象提供更多计量方面特定的意图。
COSEM应用层的xDLMS服务组件基于IEC61334-4-41制定的DLMS规范。
B.2 DLMS一致性
COSEM数据交换会话总是从建立应用连接开始，建立应用连接总是由客户机启动。
在建立连接期间，借助xDLMS-Initiate服务，用于访问COSEM接口对象的属性和方法的DLMS服务在客户机和服务器之间进行协商。
如果响应是确认的，则应用连接建立在给定的COSEM应用语境和xDLMS语境中。
另外，COSEM制定了一个新的一致性块规范以扩展有效的DLMS服务数量，见8.5。
B.3 COSEM扩展的DLMS
为了制定COSEM规范，对DLMS标准进行一些扩展是必要的。
扩展部分定义了增加的功能，而不是对现有功能的修改。
扩展部分与现有的DLMS标准不存在冲突。
增加的服务
为了能够使用逻辑名对COSEM接口对象的属性和方法进行引用，定义了下列新的服务：
∙GET－用于读取COSEM接口对象属性的值
∙SET－用于设置COSEM接口对象属性的值
∙ACTION－用于调用COSEM接口对象的方法
∙EventNotification－用于从服务器到客户发送一个非请求消息
这些服务已分别在6.5.3和6.6.3.2中定义，相应的APDU在8.6.1中定义。
附加的数据类型
增加的数据类型在8.3中定义。
一致性块
为了能够优化COSEM服务器的实现，增加了一个具有扩展功能的一致性块，参见8.5。
COSEM一致性块可以通过其标记“Application31”与DLMS标准的一致性块进行区分。
DLMS应用语境通过该一致性块和修改的xDLMS-Initiate/DLMS-Response服务进行协商。
DLMS版本号
DLMS版本号与xDLMS协议的第一版的版本号一致，都为6。
其它必要的修改
为了阐明客户机和服务器可使用的最大PDU大小的含义，下列修改是必要的。
IEC61334-4-41第61页，表3：
DLMS标准
COSEM修改
请求的最大PDU大小
客户机最大可接收的PDU大小
DLMS标准
COSEM修改
协商的最大PDU大小
服务器最大可接收的PDU大小
IEC61334-4-41第63页，第5段：
DLMS标准
COSEM修改
建议最大的PDU长度参数，其数据类型为Unsigned16，用于为信息交换的DLMSPDU申请最大的长度（用字节数表示）。
在启动请求中申请最大的长度必需足够大，以确保初始错误PDU的传送。
客户机最大可接收的PDU长度参数，其数据类型为Unsigned16，包含服务器可以发送的DLMSPDU的最大长度（用字节数表示），客户机应丢弃接收到的超过该最大长度的PDU。
该值必需足够大，以确保启动出错PDU的传送。
小于10的值被保留，该值为0表示对PDU的大小没有限制。
IEC61334-4-41第63页，最后一段：
DLMS标准
COSEM修改
协商的最大PDU长度参数，其数据类型为Unsigned16，包含信息交换的DLMSPDU的最大长度（用字节数表示），超过该最大长度的PDU应被丢弃。
该最大值取请求的最大PDU大小和VDE处理器所支持的最大PDU大小中较小的一个。
服务器最大可接收的PDU长度参数，其数据类型为Unsigned16，包含客户机可以发送的DLMSPDU的最大长度（用字节数表示），服务器应丢弃接收到的超过该最大长度的PDU。
小于10的值被保留，该值为0表示对PDU的大小没有限制。
附 录 C
（资料性附录）
AARQ和AARE编码的示例
本附录包含一些AARQ和AAREAPDU的示例，这些示例包括各种不同等级的身份验证情况，以及成功和失败的情况。
在COSEM中，AARQ和AAREAPDU（见8.2）以BER（ISO/IEC8825）编码。
在user-information方面，它们分别包含采用A-XDR编码成为OCTETSTRING的xDLMSInitiate.Request/.Response或DLMSConfirmedServiceErrorPDU。
C.1 xDLMS-Initiate.requestPDU编码的示例
首先，是xDLMS-Initiate.requestPDU编码的示例，其定义如下：
xDLMS-Initiate.request:
:
=SEQUENCE
{
dedicated-keyOCTETSTRINGOPTIONAL,
response-allowedBOOLEANDEFAULTTRUE,
proposed-quality-of-service[0]IMPLICITInteger8OPTIONAL,
proposed-dlms-version-numberUnsigned8,
proposed-conformanceConformance,
client-max-receive-pdu-sizeUnsigned16
}
其中proposed-conformance参数包含客户机请求的COSEM一致性块，见8.5。
假定客户机希望构建下列xDLMS语境的应用连接：
∙不加密（可选的dedicated-key不出现）；
∙response-allowed=TRUE（取缺省值）;
∙无proposed-quality-of-service（可选的proposed-quality-of-service参数不出现）；
∙proposed-dlms-version-number为6（xDLMS）；
∙proposed-conformance（为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
位串值
LN
0
0
0
0
0
0
0
0
0
1
1
1
1
1
1
0
0
0
0
1
1
1
1
1
007E1F
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
1C0320
本一致性块中LN的引用的含义为：
∙不支持SET的Attibute_0引用（Bit_08）
∙支持优先级管理（Bit_09）
∙支持GET的Attibute_0引用（Bit_10）
∙支持GET服务的块传输（Bit_11）
∙支持SET服务的块传输（Bit_12）
∙支持ACTION服务的块传输（Bit_13）
∙支持多重引用（Bit_14）
∙支持所有的LN服务（GET,SET,
ACTION,EVENTNOTIFICATION）（Bit_19,20,22,23）
∙支持选择性访问特征（Bit_21）
本一致性块中SN引用的含义：
∙支持所有的SN服务（READ,WRITE,
∙UNCONFIRMEDWRITE（信息报告）（Bit_03,04,05,15）
∙支持多重引用（Bit_14）
∙支持参数化访。
。
。
。
问（Bit_18）
∙client-max-receive-pdu-size为1200D=0x4B0。
对上述参数的xDLMS-Initiate.requestPDU一起采用A-XDR规则进行编码：
--对xDLMS-Initiate.requestPDU采用A-XDR规则进行编码
01//DLMSPDU中InitiateRequest的编码标记（显式标记）
--dedicated-key组件的编码（OPTIONAL,不出现）
00//dedicated-key组件的使用标志（FALSE,不出现）
--response-allowed组件的编码（TRUE,缺省值）
00//response-allowed组件的使用标志（FALSE,defaultvalueconveyed）
--proposed-quality-of-service组件的编码（OPTIONAL,不出现）
00//proposed-quality-of-service组件的使用标志（FALSE,不出现）
--proposed-dlms-version-number组件的编码（Unsigned8,value=6）
06//Unsigned8类型的数据的A-XDR编码就是它的值
--对Conformanceblock[APPLICATION31]IMPLICITBITSTRING（SIZE（24））进行编码
5F1F//[APPLICATION31]标记（ASN.1显式标记）的编码
04//'contents'字段的长度（八位字节数）的编码（长度=4）
00//对BITSTRING的最后字节中不使用的比特数进行编码
重要说明为了与现有的实现一致，在采用面向连接的基于HDLC的三层模型时，对[Application31]标记的编码采用一个字节（5F）代替两个字节（5F1F）是可以接受的。
LN引用
SN引用
007E1F//对固定长度的位串值的编码
1C0320//对固定长度的位串值的编码
--对client-max-receive-pdu-size组件的编码（Unsigned16,value=0x4B0）
04B0//Unsigned16的数据的A-XDR编码就是它的值
因此，对上述给定参数的xDLMS-Initiate.requestPDU采用A-XDR规则进行编码，产生的八位字节序列为：
LN引用
SN引用
01000000065F1F0400007E1F04B0
01000000065F1F04001C032004B0
该八位字节序列应作为一个OCTETSTRING插入到AARQAPDU的user-information字段。
C.2 AARQ不使用ACSE安全机制时的编码示例
对ACSE的使用，假定客户机期望按下列应用语境建立应用连接：
∙protocol-version为缺省的ACSE版本；
∙application-context-name：
LN引用
SN引用
{joint-iso-ccitt
（2）country（16）country-name（756）
identified-organization（5）DLMS-UA（8）
applicationcontext
（1）context_id
（1）}
{joint-iso-ccitt
（2）country（16）country-name（756）
identified-organization（5）DLMS-UA（8）
applicationcontext
（1）context_id
（2）}
∙不使用身份验证：
mechanism-name和calling-authenticationvalue都不出现；
∙不包含implementation-information。
AARQAPDU采用BER编码，对应参数如下：
--对AARQAPDU进行BER编码
60//AARQAPDU（[APPLICATION0],Application）的编码标记
1D//AARQcontent字段长度的编码（29个八位字节）
--对协议版本没有进行编码，因此认为协议版本为缺省值
--application-context-name组件的编码（taggedcomponent[1]）
A1//application-context-name组件（[1],Context-specific）标记的编码
09//标记的组件值的长度编码
--application-context-name组件（OBJECTIDENTIFIER）的编码
06//对application-context-name（OBJECTIDENTIFIER,Universal）选择的编码
07//ObjectIdentifier的值字段的长度的编码（7个八位字节）
//ObjectIdentifier）值的编码
LN引用
SN引用
60857405080101
60857405080102
--user-information字段组件（taggedcomponent,[30]）的编码
BE//user-information字段component（[30],Context-specific）的标记的编码
10//标记的组件值字段的长度的编码
--theapplication-context-name组件（OCTETSTRING）的编码
04//对user-information（OCTETSTRING,Universal）选择的编码
0E//OCTETSTRING值字段长度的编码（14个八位字节）
//下面是xDLMS-Initiate.requestPDU的八位字节序列
LN引用
SN引用
01000000065F1F0400007E1F04B0
01000000065F1F04001C032004B0
因此，一个具有上述给定参数的AARQAPDU完整编码如下（所有数据都用十六进制表示）：
LN引用
SN引用
AARQ-pdu=[601DA109060760857405080101BE10040E01000000065F1F0400007E1F04B0]
AARQ-pdu=[601DA109060760857405080102BE10040E01000000065F1F040
升级会员 