IEC62056-53-2 中文

1、附錄A（規(guī)范性附錄）面向連接的基于HDLC三層模型A.1 引言 COSEM應(yīng)用層僅是包含COSEM特定的服務(wù)組件、擴(kuò)展的DLMS應(yīng)用服務(wù)組件(xDLMS-ASE)的協(xié)議層。 該應(yīng)用層可以使用各種不同的低層協(xié)議完成通信功能，一個完整的協(xié)議棧（包括應(yīng)用層）稱之為通信模型（參見第4章）。 通信模型的特征取決于：· 低層協(xié)議層；· 應(yīng)用層中應(yīng)用控制服務(wù)組件（ACSE）類型（面向連接或無連接）。 COSEM制定的第一個標(biāo)準(zhǔn)化的通信模型是一個面向連接的、基于HDLC的三層模型，該模型由三個協(xié)議層組成：· COSEM應(yīng)用層，其應(yīng)用層中包含面向連接的ACSE，在本部分中定義；&#

2、183; 數(shù)據(jù)鏈路層，基于ISO/IEC 13239 HDLC協(xié)議，在 IEC 62056-46中定義；· 物理接口層，在IEC 62056-42中定義。A.2 基于HDLC的數(shù)據(jù)鏈路層 綜述 為了構(gòu)建本通信模型，從 HDLC標(biāo)準(zhǔn)ISO/IEC 13239中選擇下列內(nèi)容：· 非平衡連接模式的數(shù)據(jù)鏈路層操作 在COSEM中，主站對應(yīng)于客戶應(yīng)用，從站仍是從站。）；· 兩通道交替數(shù)據(jù)傳輸；· 選擇HDLC類過程是UNC (非平衡操作正常響應(yīng)模式類)，采用UI幀擴(kuò)展；· 幀格式類型3；· 非要素透明幀格式。 在非平衡連接模式數(shù)據(jù)鏈路操作中，要

3、涉及兩個或多個站，主站通過發(fā)送命令幀負(fù)責(zé)組織數(shù)據(jù)流和處理不可恢復(fù)的數(shù)據(jù)鏈路級出錯情況，從站通過發(fā)送響應(yīng)幀來響應(yīng)主站的命令。 為了提供組播、廣播以及從服務(wù)器到客戶機(jī)的非請求信息傳送功能，過程的UNC類的基本命令和響應(yīng)集采用不計數(shù)信息（UI）幀進(jìn)行擴(kuò)展，以支持無連接的數(shù)據(jù)通信服務(wù)。使用非平衡連接模式數(shù)據(jù)鏈路操作意味著客戶機(jī)和服務(wù)器側(cè)的數(shù)據(jù)鏈路層的HDLC幀集和狀態(tài)機(jī)不相同。A.2.1 基于HDLC的數(shù)據(jù)鏈路層服務(wù) 基于HDLC的數(shù)據(jù)鏈路層提供的服務(wù)包括：· 數(shù)據(jù)鏈路層連接管理；· 面向連接的數(shù)據(jù)通信（I幀）；· 無連接的數(shù)據(jù)通信（UI幀）。A.2.1.1 客戶機(jī)側(cè)的服

4、務(wù)圖A.1概括了COSEM客戶機(jī)應(yīng)用層面向連接的基于HDLC三層通信模型中數(shù)據(jù)鏈路層服務(wù)。 圖A.1 客戶機(jī)COSEM應(yīng)用層使用的數(shù)據(jù)鏈路服務(wù)對某些服務(wù)，對應(yīng)于應(yīng)用層（ASO）服務(wù)調(diào)用和支撐數(shù)據(jù)鏈路層服務(wù)調(diào)用之間的通信是直接的（例如，COSEM-OPEN.request服務(wù)調(diào)用直接意味著調(diào)用DLCONNECT.request服務(wù)）。對其它服務(wù)，不能建立這種直接的服務(wù)映射。A.2.1.2 服務(wù)器側(cè)的服務(wù)圖A.2概括了COSEM服務(wù)器應(yīng)用層使用面向連接的基于HDLC的三層通信模型中數(shù)據(jù)鏈路層的服務(wù)。圖A.2 服務(wù)器COSEM應(yīng)用層使用的數(shù)據(jù)鏈路服務(wù) 與客戶機(jī)類似，對某些服務(wù)，應(yīng)用層（ASO）服務(wù)調(diào)

5、用和支撐數(shù)據(jù)鏈路層服務(wù)調(diào)用之間的通信是直接的，對其它服務(wù)，不能被建立這種直接的服務(wù)映射。 為了支持從服務(wù)器到客戶機(jī)透明的長數(shù)據(jù)傳送，服務(wù)器側(cè)規(guī)定了本地的DLDATA.confirm服務(wù)。A.2.1.3 面向連接的基于HDLC三層模型的特殊組件A.2.1.3.1 支持應(yīng)用連接的特別特征 在COSEM環(huán)境中，一個AA完全由客戶機(jī)和服務(wù)器應(yīng)用進(jìn)程使用的一對低層SAPs所標(biāo)識，換而言之，在應(yīng)用連接和支持該AA的低層連接之間存在著一一對應(yīng)的關(guān)系。 在基于HDLC的CO三層模型中，每個AA都與一個支撐數(shù)據(jù)鏈路層連接相對應(yīng)，建立一個AA意味著建立一個客戶機(jī)和服務(wù)器數(shù)據(jù)鏈路層之間的連接。請求建立此連接的地址信

6、息包含在COSEM-OPEN的Protocol_Connection_Parameters服務(wù)參數(shù)中，此信息包括下列數(shù)據(jù)：Server_Lower_MAC_Address, (COSEM物理設(shè)備地址)Server_Upper_MAC_Address, (COSEM邏輯設(shè)備地址)Client_MAC_Address,Server_LLC_Address,Client_LLC_Address 任何一個服務(wù)器（目的站）的地址參數(shù)都可以包含特殊的地址(ALL_STATION，NO_STATION，等等)，此外，此模型在建立連接時還要遵循下列規(guī)則：· COSEM-OPEN.request服務(wù)的

7、User_Information服務(wù)參數(shù)（參見6.5.1.2）要插入到SNRM HDLC幀的“用戶數(shù)據(jù)子字段”中，在建立數(shù)據(jù)鏈路連接時發(fā)送。在服務(wù)器側(cè)，如果接收到SNRM幀包含“用戶數(shù)據(jù)子字段”，則此字段的內(nèi)容應(yīng)通過COSEM-OPEN.indication服務(wù)的user_information服務(wù)參數(shù)（參見6.6.1.2）傳送給服務(wù)器的應(yīng)用進(jìn)程。· 如果客戶機(jī)應(yīng)用層采用無確認(rèn)的COSEM-OPEN.request 服務(wù)調(diào)用(參照6.5.1.2)發(fā)送一個AARQ幀，則該幀應(yīng)采用UI（不計數(shù)的信息）類型的HDLC幀來發(fā)送 。在COSEM中，通常通過斷開低層連接來斷開應(yīng)用連接，參照6.5

8、.2。在面向連接的基于HDLC的三層模型中，調(diào)用COSEM-RELEASE.request服務(wù)原語將導(dǎo)致相應(yīng)的HDLC連接的斷開，數(shù)據(jù)鏈路層使用DISC命令幀并且UA/DM響應(yīng)HDLC幀（參見IEC 62056-46）。對于AA的正?；虍惓嚅_，要遵循以下附加規(guī)則：· 在COSEM-RELEASE.request服務(wù)中出現(xiàn)User_Information服務(wù)參數(shù)時（參見6.5.2.2），它應(yīng)插入到DISC HDLC幀的“用戶數(shù)據(jù)子字段”中，在斷開數(shù)據(jù)鏈路連接時發(fā)送，如果被服務(wù)器接收到的DISC幀包含“用戶數(shù)據(jù)子字段”， 則此字段的內(nèi)容應(yīng)通過COSEMRELEASE.indicatio

9、n服務(wù)的user_information服務(wù)參數(shù)（參見6.6.1.2）傳送給服務(wù)器的應(yīng)用進(jìn)程。· 在COSEM-RELEASE.response服務(wù)中出現(xiàn)User_Information服務(wù)參數(shù)時（參見6.6.2.2），它應(yīng)插入到UA或DM HDLC幀的“用戶數(shù)據(jù)子字段”中發(fā)送，用于響應(yīng)DISC幀。如果客戶機(jī)接收到的UA或DISC幀包含“用戶數(shù)據(jù)子字段”， 則此字段的內(nèi)容應(yīng)通過COSEM-RELEASE.confirm服務(wù)的user_information服務(wù)參數(shù)（參見6.5.2.3）傳送給客戶機(jī)的應(yīng)用進(jìn)程。· COSEM-ABORT.indication 服務(wù)的診斷參數(shù)(

10、參見 6.5.2.4和6.6.2.3)可包含一個不計數(shù)信息的發(fā)送狀態(tài)參數(shù)，這個參數(shù)指示當(dāng)物理層異常終止指示時刻，數(shù)據(jù)鏈路層是否還有待發(fā)的不計數(shù)信息報文（UI），此參數(shù)的類型和值是本地發(fā)出的，它不在本部分范圍之內(nèi)。A.2.1.3.2 數(shù)據(jù)通信服務(wù)的特別特征 在本模型中數(shù)據(jù)通信服務(wù)沒有特別特征/服務(wù)參數(shù)，對數(shù)據(jù)通信服務(wù)，COSEM應(yīng)用層是完全透明的。 確認(rèn)的數(shù)據(jù)通信服務(wù)（GET/SET/ACTION Read/Write)調(diào)用在數(shù)據(jù)鏈路層采用I幀傳送，另一方面，無確認(rèn)的數(shù)據(jù)通信服務(wù)調(diào)用采用UI幀傳送。因此，無確認(rèn)服務(wù)的編碼形式應(yīng)放入一個HDLC幀中。A.2.1.3.3 EventNotificat

11、ion服務(wù)的特別特征 在數(shù)據(jù)鏈路層EventNotification APDU 采用HDLC UI 幀傳送，因此，與數(shù)據(jù)通信服務(wù)類似，本服務(wù)的編碼形式也應(yīng)放入一個HDLC幀中。傳送EventNotification APDU的HDLC UI幀的源和目的地址總是相同的。源地址是管理邏輯設(shè)備（必選的）的HDLC地址（保留的HDLC地址為0x01），目的地址總是客戶機(jī)管理應(yīng)用進(jìn)程的HDLC地址（保留的HDLC地址為0x01）。 非平衡的HDLC模型不允許采用實時的、非請求的方式發(fā)送一個協(xié)議數(shù)據(jù)單元，因此，在本模型中，通過調(diào)用客戶機(jī)應(yīng)用層的Trigger_EventNotification_sendi

12、ng服務(wù)原語來明確請求發(fā)送一個EventNotification幀（參見6.5.4.2）。一旦調(diào)用該服務(wù)，客戶機(jī)將發(fā)送一個空的UI幀，并使P/F位設(shè)為TRUE，允許服務(wù)器數(shù)據(jù)鏈路層發(fā)送事件通告幀，服務(wù)器數(shù)據(jù)鏈路層發(fā)送未覺的Event-Notification-Request APDU作為UI幀，并利用EventNotification.indication向客戶機(jī)應(yīng)用進(jìn)行指示，至此，事件通告過程完成。(規(guī)范性附錄)xDLMS應(yīng)用服務(wù)組件B.1 引言 COSEM方法的主要目的在于向商業(yè)領(lǐng)域為計量設(shè)備和系統(tǒng)提供面向COSEM接口對象的模型，同時保持對現(xiàn)有的DLMS標(biāo)準(zhǔn)向后的兼容性。為達(dá)到這些目的，

13、COSEM對DLMS進(jìn)行了發(fā)展，在保持完全遵循DLMS標(biāo)準(zhǔn)的同時，COSEM可通過COSEM接口對象提供更多計量方面特定的意圖。 COSEM應(yīng)用層的xDLMS服務(wù)組件基于IEC 61334-4-41制定的DLMS規(guī)范。B.2 DLMS一致性 COSEM 數(shù)據(jù)交換會話總是從建立應(yīng)用連接開始，建立應(yīng)用連接總是由客戶機(jī)啟動。在建立連接期間，借助xDLMS-Initiate服務(wù)，用于訪問COSEM接口對象的屬性和方法的DLMS服務(wù)在客戶機(jī)和服務(wù)器之間進(jìn)行協(xié)商。如果響應(yīng)是確認(rèn)的，則應(yīng)用連接建立在給定的COSEM應(yīng)用語境和xDLMS語境中。 另外，COSEM制定了一個新的一致性塊規(guī)范以擴(kuò)展有效的DLMS服

14、務(wù)數(shù)量，見8.5。B.3 COSEM擴(kuò)展的DLMS 為了制定COSEM規(guī)范，對DLMS標(biāo)準(zhǔn)進(jìn)行一些擴(kuò)展是必要的。擴(kuò)展部分定義了增加的功能，而不是對現(xiàn)有功能的修改。擴(kuò)展部分與現(xiàn)有的DLMS標(biāo)準(zhǔn)不存在沖突。B.3.1 增加的服務(wù) 為了能夠使用邏輯名對COSEM接口對象的屬性和方法進(jìn)行引用，定義了下列新的服務(wù)：· GET用于讀取COSEM接口對象屬性的值· SET用于設(shè)置COSEM接口對象屬性的值· ACTION用于調(diào)用COSEM接口對象的方法· EventNotification用于從服務(wù)器到客戶發(fā)送一個非請求消息 這些服務(wù)已分別在6.5.3和6.6.3.2

15、中定義，相應(yīng)的APDU在8.6.1中定義。B.3.2 附加的數(shù)據(jù)類型 增加的數(shù)據(jù)類型在 8.3中定義。B.3.3 一致性塊 為了能夠優(yōu)化COSEM服務(wù)器的實現(xiàn)，增加了一個具有擴(kuò)展功能的一致性塊，參見8.5。COSEM一致性塊可以通過其標(biāo)記“Application 31”與DLMS標(biāo)準(zhǔn)的一致性塊進(jìn)行區(qū)分。 DLMS應(yīng)用語境通過該一致性塊和修改的xDLMS-Initiate/DLMS-Response服務(wù)進(jìn)行協(xié)商。B.3.4 DLMS 版本號 DLMS版本號與xDLMS協(xié)議的第一版的版本號一致，都為6。 B.3.5 其它必要的修改 為了闡明客戶機(jī)和服務(wù)器可使用的最大PDU大小的含義，下列修改是必要

16、的。IEC 61334-4-41第61頁，表3：DLMS標(biāo)準(zhǔn)COSEM修改請求的最大PDU大小客戶機(jī)最大可接收的PDU大小DLMS標(biāo)準(zhǔn)COSEM修改協(xié)商的最大PDU大小服務(wù)器最大可接收的PDU大小IEC 61334-4-41第63頁，第5段：DLMS標(biāo)準(zhǔn)COSEM修改建議最大的PDU長度參數(shù)，其數(shù)據(jù)類型為Unsigned16，用于為信息交換的DLMS PDU申請最大的長度（用字節(jié)數(shù)表示）。在啟動請求中申請最大的長度必需足夠大，以確保初始錯誤PDU的傳送?？蛻魴C(jī)最大可接收的PDU長度參數(shù)，其數(shù)據(jù)類型為Unsigned16，包含服務(wù)器可以發(fā)送的DLMS PDU的最大長度（用字節(jié)數(shù)表示），客戶機(jī)應(yīng)丟

17、棄接收到的超過該最大長度的PDU。該值必需足夠大，以確保啟動出錯PDU的傳送。小于10的值被保留，該值為0表示對PDU的大小沒有限制。IEC 61334-4-41第63頁，最后一段：DLMS標(biāo)準(zhǔn)COSEM修改協(xié)商的最大PDU長度參數(shù)，其數(shù)據(jù)類型為Unsigned16，包含信息交換的DLMS PDU的最大長度（用字節(jié)數(shù)表示），超過該最大長度的PDU應(yīng)被丟棄。該最大值取請求的最大PDU大小和VDE處理器所支持的最大PDU大小中較小的一個。服務(wù)器最大可接收的PDU長度參數(shù)，其數(shù)據(jù)類型為Unsigned16，包含客戶機(jī)可以發(fā)送的DLMS PDU的最大長度（用字節(jié)數(shù)表示），服務(wù)器應(yīng)丟棄接收到的超過該最大

18、長度的PDU。小于10的值被保留，該值為0表示對PDU的大小沒有限制。(資料性附錄)AARQ和AARE 編碼的示例本附錄包含一些AARQ和AARE APDU的示例，這些示例包括各種不同等級的身份驗證情況，以及成功和失敗的情況。在COSEM中，AARQ和AARE APDU（見8.2）以BER（ISO/IEC 8825）編碼。在user-information方面，它們分別包含采用A-XDR編碼成為OCTETSTRING的xDLMS Initiate.Request/.Response或DLMS ConfirmedServiceError PDU。C.1 xDLMS-Initiate.reques

19、t PDU編碼的示例 首先，是xDLMS-Initiate.request PDU編碼的示例，其定義如下：xDLMS-Initiate.request : = SEQUENCEdedicated-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-ma

20、x-receive-pdu-size Unsigned16其中proposed-conformance參數(shù)包含客戶機(jī)請求的COSEM一致性塊，見8.5。 假定客戶機(jī)希望構(gòu)建下列xDLMS語境的應(yīng)用連接：· 不加密（可選的dedicated-key不出現(xiàn)）；· response-allowed = TRUE (取缺省值);· 無proposed-quality-of-service（可選的proposed-quality-of-service參數(shù)不出現(xiàn)）；· proposed-dlms-version-number為6（xDLMS）；· prop

21、osed-conformance（為LN和SN引用請求所有可能的服務(wù)和特別特征）如下：Bit_00Bit_01Bit_02Bit_03Bit_04Bit_05Bit_06Bit_07Bit_08Bit_09Bit_10Bit_11Bit_12Bit_13Bit_14Bit_15Bit_16Bit_17Bit_18Bit_19Bit_20Bit_21Bit_22Bit_23位串值LN00000000011111100001111100 7E 1FSN0001110000000011001000001C 03 20本一致性塊中LN的引用的含義為：· 不支持SET的Attibute_0引用

22、 (Bit_08)· 支持優(yōu)先級管理 (Bit_09)· 支持GET的Attibute_0引用 (Bit_10)· 支持GET服務(wù)的塊傳輸 (Bit_11)· 支持SET服務(wù)的塊傳輸 (Bit_12)· 支持ACTION服務(wù)的塊傳輸 (Bit_13)· 支持多重引用 (Bit_14)· 支持所有的LN服務(wù) (GET, SET, ACTION,EVENT NOTIFICATION) (Bit_19, 20, 22, 23)· 支持選擇性訪問特征 (Bit_21)本一致性塊中SN引用的含義：· 支持所有的SN

23、 服務(wù) (READ, WRITE,· UNCONFIRMED WRITE(信息報告) (Bit_03, 04, 05, 15)· 支持多重引用 (Bit_14)· 支持參數(shù)化訪。問 (Bit_18)· client-max-receive-pdu-size為1200D = 0x4B0。 對上述參數(shù)的xDLMS-Initiate.request PDU一起采用A-XDR規(guī)則進(jìn)行編碼：- 對xDLMS-Initiate.request PDU采用A-XDR規(guī)則進(jìn)行編碼01 / DLMS PDU中InitiateRequest的編碼標(biāo)記(顯式標(biāo)記)- dedi

24、cated-key組件的編碼(OPTIONAL, 不出現(xiàn))00 / dedicated-key組件的使用標(biāo)志(FALSE, 不出現(xiàn))- response-allowed組件的編碼(TRUE, 缺省值)00 / response-allowed組件的使用標(biāo)志(FALSE, default value conveyed)- proposed-quality-of-service組件的編碼(OPTIONAL,不出現(xiàn))00 / proposed-quality-of-service組件的使用標(biāo)志(FALSE,不出現(xiàn))- proposed-dlms-version-number組件的編碼(Unsigne

25、d8, value=6)06 /Unsigned8類型的數(shù)據(jù)的A-XDR編碼就是它的值- 對Conformance block APPLICATION 31 IMPLICIT BITSTRING (SIZE(24)進(jìn)行編碼5F 1F / APPLICATION 31標(biāo)記(ASN.1顯式標(biāo)記)的編碼04 / 'contents' 字段的長度（八位字節(jié)數(shù)）的編碼（長度=4）00 / 對BITSTRING的最后字節(jié)中不使用的比特數(shù)進(jìn)行編碼重要說明 為了與現(xiàn)有的實現(xiàn)一致，在采用面向連接的基于HDLC的三層模型時，對Application 31標(biāo)記的編碼采用一個字節(jié)(5F)代替兩個字節(jié)(

26、5F 1F)是可以接受的。LN引用SN引用00 7E 1F /對固定長度的位串值的編碼1C 03 20 /對固定長度的位串值的編碼- 對client-max-receive-pdu-size組件的編碼(Unsigned16, value=0x4B0)04 B0 / Unsigned16的數(shù)據(jù)的A-XDR編碼就是它的值 因此，對上述給定參數(shù)的xDLMS-Initiate.request PDU采用A-XDR規(guī)則進(jìn)行編碼，產(chǎn)生的八位字節(jié)序列為：LN引用SN引用01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B001 00 00 00 06 5F 1F 04 00 1C

27、 03 20 04 B0該八位字節(jié)序列應(yīng)作為一個OCTET STRING插入到AARQ APDU的user-information字段。C.2 AARQ不使用ACSE安全機(jī)制時的編碼示例對ACSE的使用，假定客戶機(jī)期望按下列應(yīng)用語境建立應(yīng)用連接：· protocol-version為缺省的ACSE版本；· application-context-name：LN引用SN引用joint-iso-ccitt(2) country(16) country-name(756)identified-organization(5) DLMS-UA(8)applicationcontext

28、(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都不出現(xiàn)；· 不包含implementation-information。 AARQ APDU采用BER編碼，對應(yīng)參數(shù)如下：- 對AARQ APDU進(jìn)行BER編碼60 / AARQ APDU (APP

29、LICATION 0, Application)的編碼標(biāo)記1D / AARQ content字段長度的編碼(29個八位字節(jié))- 對協(xié)議版本沒有進(jìn)行編碼，因此認(rèn)為協(xié)議版本為缺省值- application-context-name組件的編碼(tagged component 1)A1 / application-context-name組件(1, Context-specific )標(biāo)記的編碼09 / 標(biāo)記的組件值的長度編碼- application-context-name組件(OBJECT IDENTIFIER)的編碼06 / 對application-context-name (OBJEC

30、T IDENTIFIER, Universal)選擇的編碼07 / Object Identifier的值字段的長度的編碼(7個八位字節(jié))/ Object Identifier 八位字節(jié)標(biāo)識碼的BER編碼是一個表示弧形標(biāo)簽的數(shù)字包序列，每個數(shù)字（最開始的兩個除外，這兩個數(shù)字要合成為一個數(shù)字）代表一串八位字節(jié)，除最后的八位字節(jié)之外，在每個八位字節(jié)中使用七位，最高有效位置1，所使用的八位字節(jié)數(shù)必需是最少的。本示例對象標(biāo)識碼（2,16,756,5,8,1,1）編碼的第一個八位字節(jié)是最開始的兩個數(shù)字組合而成的一個數(shù)字，遵循的規(guī)則為40*First+Second -> 40*2 + 16 = 96

31、 = 0x60。對象標(biāo)識碼的第三個數(shù)字(756)需要兩個字節(jié)：其十六進(jìn)制的值為0x2F4，二進(jìn)制表示為00000010 11110100，按照上述規(guī)則，第二個八位字節(jié)的MSB應(yīng)置為0，將其MSB移位到第一個八位字節(jié)，并把第一個八位字節(jié)的MSB置為1，得到的二進(jìn)制數(shù)為10000101 01110100，其十六進(jìn)制為0x8574。對象標(biāo)識碼的其余每個數(shù)字要求編碼為一個八位字節(jié)，上述標(biāo)識碼的編碼結(jié)果為60 85 74 05 08 01 01。）值的編碼LN引用SN引用60 85 74 05 08 01 0160 85 74 05 08 01 02- user-information字段組件 (tag

32、ged component, 30)的編碼BE / user-information字段component (30, Context-specific )的標(biāo)記的編碼10 / 標(biāo)記的組件值字段的長度的編碼- the application-context-name組件 (OCTET STRING)的編碼04 / 對user-information (OCTET STRING, Universal)選擇的編碼0E / OCTET STRING值字段長度的編碼(14個八位字節(jié))/ 下面是xDLMS-Initiate.request PDU的八位字節(jié)序列LN引用SN引用01 00 00 00 06

33、5F 1F 04 00 00 7E 1F 04 B001 00 00 00 06 5F 1F 04 00 1C 03 20 04 B0 因此，一個具有上述給定參數(shù)的AARQ APDU完整編碼如下（所有數(shù)據(jù)都用十六進(jìn)制表示）：LN引用SN引用AARQ-pdu = 60 1D 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 7E 1F 04 B0 AARQ-pdu = 60 1D A1 09 06 07 60 85 74 05 08 01 02 BE 10 04 0E 01 00 00 00 06

34、 5F 1F 04 00 1C 03 20 04 B0 C.3 AARQ使用低級身份驗證時編碼的示例 本編碼的示例與C.2示例類似，只有必需進(jìn)行編碼的三個附加字段與上面示例不同，這些字段是：· sender-acse-requirements：指示選用的ACSE功能單元；· mechanism-name：default-COSEM-low-level-security-mechanism-namejoint-iso-ccitt (2) country (16) country-name (756) identified-organization (5) DLMSUA (8)

35、 authentication_mechanism_name (2) mechanism_id (1);· calling-authentication-value：包含口令(假定為“12345678”)的GraphicString。注：這三個字段在user-information-field之前立即編碼。- sender-acse-requirements字段組件(tagged component, 10 )的編碼8A / acse-requirements 字段component (10, IMPLICIT,Context-specific)標(biāo)記的編碼02 /標(biāo)記的組件值字段的長

36、度的編碼- sender-acse-requirements組件(ACSE-requirements := BIT STRING)的編碼07 / BIT STRING最后字節(jié)中沒有使用的比特數(shù)的編碼80 /身份驗證功能單元(0)的編碼注： 比特數(shù)的在不同的客戶機(jī)之間可以不同，但是在COSEM環(huán)境中，只有BIT 0置為1時（指示身份驗證功能單元是否需要）值得注意。- mechanism-name組件(tagged component 11)的編碼8B / mechanism-name組件(component 11, IMPLICIT,Context-specific)的標(biāo)記的編碼07 /標(biāo)記的組

37、件值字段的長度的編碼- 對象標(biāo)識碼值的編碼60 85 74 05 08 02 01- calling-authentication-value組件(tagged component 12)的編碼AC / mechanism-name組件(component 12, Context-specific)標(biāo)記的編碼0A / 標(biāo)記的組件值字段的長度的編碼- calling-authentication-value組件 (Authentication-information := CHOICE)的編碼80 / 對Authentication-information (charstring 0 IMPLI

38、CIT GraphicString)的編碼選擇08 / Authentication-information值字段長度的編碼(8個八位字節(jié))-口令值 (GraphicString “12345678”)的編碼31 32 33 34 35 36 37 38因此，一個具有上述給定參數(shù)的AARQ APDU的完整的編碼如下（所有數(shù)據(jù)都用十六進(jìn)制表示）：LN引用SN引用AARQ-pdu = 60 36 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

39、37 38 BE 10 04 0E 01 00 00 00 06 5F 1F 04 00 00 7E 1F 04 B0 AARQ-pdu = 60 36 A1 09 06 07 60 85 74 05 08 01 02 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 1F 04 00 1C 03 20 04 B0 C.4 使用高級身份驗證時AARQ編碼的示例本編碼的示例與C.3的示例類似，只有兩個字段的內(nèi)容不同：· mech

40、anism-name：default-COSEM-high-level-security-mechanism-name；· calling-authentication-value：假定不需要客戶機(jī)到服務(wù)器的呼叫信息。- mechanism-name組件 (tagged component 11)的編碼8B / mechanism-name組件(component 11, IMPLICIT, Context-specific)標(biāo)記的編碼07 / 標(biāo)記的組件值字段的長度的編碼- Object Identifier (default-COSEM-high-level-security-m

41、echanism-name)的編碼60 85 74 05 08 02 02- calling-authentication-value組件(tagged component 12)的編碼AC / mechanism-name組件(component 12, Context-specific)標(biāo)記的編碼02 / 標(biāo)記的組件值字段的長度的編碼- calling-authentication-value組件 (Authentication-information := CHOICE)的編碼80 / 對Authentication-information (charstring 0 IMPLICIT

42、GraphicString)選擇的編碼00 / Authentication-information值字段的長度的編碼(0個八位字節(jié))-口令 (GraphicString)的編碼/ 由于串是空的，不需要編碼因此，一個具有上述給定參數(shù)的AARQ APDU的完整的編碼如下（所有數(shù)據(jù)都用十六進(jìn)制表示）：LN引用SN引用AARQ-pdu = 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 1F 04 00 00

43、7E 1F 04 B0 AARQ-pdu = 60 2E A1 09 06 07 60 85 74 05 08 01 02 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 1F 04 00 1C 03 20 04 B0 C.5 AARE APDU編碼示例，成功的情況 回憶AARE ADPU的ASN.1規(guī)范：AARE-apdu := APPLICATION 1 IMPLICIT SEQUENCEprotocol-version 0 IMPLICIT BIT STRING versio

44、n1 (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-identifie

45、r OPTIONAL,responding-AE-invocation-id 7 AE-invocation-identifier OPTIONAL,- 如果僅僅使用內(nèi)核，下列字段不出現(xiàn)responder-acse-requirements 8 IMPLICIT ACSE-requirements OPTIONAL,- 只有在選用身份驗證單元是，下列字段出現(xiàn)mechanism-name 9 IMPLICIT Mechanism-name OPTIONAL,- 只有在選用身份驗證單元是，下列字段出現(xiàn)responding-authentication-value 10 EXPLICIT Authe

46、ntication-value OPTIONAL,implementation-information 29 IMPLICIT Implementation-data OPTIONAL,user-information 30 IMPLICIT Association-information OPTIONAL在COSEM中，該APDU采用BER進(jìn)行編碼，user-information包含一個xDLMS-Initiate.response PDU的A-XDR編碼（OCTETSTRING）。C.6 xDLMS-Initiate.response PDU編碼示例 xDLMS-Initiate.res

47、ponse的規(guī)范如下：xDLMS-Initiate.response : = SEQUENCEnegotiated-quality-of-service 0 IMPLICIT Integer8 OPTIONAL,negotiated-dlms-version-number Unsigned8,negotiated-conformance Conformance,server-max-receive-pdu-size Unsigned16,vaa-name ObjectName其中，ObjectName的數(shù)據(jù)類型為ObjectName := Unsigned16，協(xié)商的一致性參數(shù)包含服務(wù)器支持的

48、xDLMS服務(wù)和特征。 假定服務(wù)器接受請求的具有下列xDLMS語境的應(yīng)用連接：· 沒有negotiated-quality-of-service (可選的proposed-quality-of-service參數(shù)不出現(xiàn))；· 協(xié)商的DLMS版本號為6 (xDLMS);· 接受的xDLMS一致性塊（其指示接受的LN引用和SN引用的服務(wù)與特別特征）如下：Bit_00Bit_01Bit_02Bit_03Bit_04Bit_05Bit_06Bit_07Bit_08Bit_09Bit_10Bit_11Bit_12Bit_13Bit_14Bit_15Bit_16Bit_17B

49、it_18Bit_19Bit_20Bit_21Bit_22Bit_23位串值LN00000000010100000001111100 50 1FSN0001110000000011001000001C03 20本一致性塊中LN引用的含義為：不支持SET的Attibute_0引用 (Bit_08)支持優(yōu)先級管理 (Bit_09)不支持GET的Attibute_0引用 (Bit_10)支持GET服務(wù)的塊傳輸 (Bit_11)不支持SET服務(wù)的塊傳輸 (Bit_12)不支持ACTION服務(wù)的塊傳輸 (Bit_13)不支持多重引用 (Bit_14)支持所有的LN服務(wù) (GET, SET,ACTION,

50、EVENT NOTIFICATION) (Bit_19, 20, 22, 23)支持選擇性訪問特征 (Bit_21)本一致性塊中SN引用的含義：支持所有的SN 服務(wù) (READ, WRITE,UNCONFIRMED WRITE(信息報告) (Bit_03, 04, 05, 15)支持多重引用 (Bit_14)支持參數(shù)化訪問 (Bit_18)· server-max-receive-pdu-size為500D = 0x1F4；· vaa-name.LN引用SN引用給該連接賦一個虛設(shè)的VAA名返回標(biāo)準(zhǔn)的連接SN的短名(0xFA00) 具有上述參數(shù)的xDLMS-Initiate.

51、response PDU的A-XDR編碼如下：- xDLMS-Initiate.response PDU的A-XDR編碼08 / DLMS PDU選項表中InitiateResponse的標(biāo)記（顯式標(biāo)記）的編碼- negotiated-quality-of-service組件(可選項, 不出現(xiàn))00 / proposed-quality-of-service組件的使用標(biāo)記(FALSE, 不出現(xiàn))- negotiated-dlms-version-number組件的編碼(Unsigned8, value=6)06 / 類型為Unsigned8的數(shù)據(jù)的A-XDR編碼就是它的值- 一致性塊APPLI

52、CATION 31 IMPLICIT BITSTRING (SIZE(24)的編碼5F 1F / APPLICATION 31 標(biāo)記 (ASN.1 顯式標(biāo)記)的編碼04 / 'contents' 字段長度（用八位字節(jié)數(shù)表示）的編碼（4個八位字節(jié)）00 / 位串的最后一個八位字節(jié)沒有使用的比特數(shù)的編碼/ 固定長度位串值的編碼LN引用SN引用00 50 1F 1C 03 20 - server-max-receive-pdu-size組件的編碼(Unsigned16, value=0x01F4)01 F4 / 類型為Unsigned16的數(shù)據(jù)的A-XDR編碼就是它的值- VAA-N

53、ame組件的編碼 (Unsigned16, 使用LN引用時值=0x0007，使用SN引用時值= FA 00)/ 類型為Unsigned16的數(shù)據(jù)的A-XDR編碼就是它的值LN引用SN引用00 07FA 00 因此，對具有上述給定參數(shù)的xDLMS-Initiate.response PDU進(jìn)行A-XDR編碼應(yīng)產(chǎn)生如下八位字節(jié)序列：LN引用SN引用08 00 06 5F 1F 04 00 00 50 1F 01 F4 00 0708 00 06 5F 1F 04 00 1C 03 20 01 F4 FA 00 這個八位字節(jié)序列應(yīng)作為一個OCTET STRING 插入到AARE APDU的user-

54、information 字段。C.7 不使用安全措施或使用低級安全措施時AARE的編碼 對ACSE的使用，假定服務(wù)器接受按下列應(yīng)用語境建立應(yīng)用連接：· 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