DLMS電能表通訊協議學習筆記

本文是對于IEC62056協議族，即DLMS協議族的中文說明手冊。本文并沒有包含DLMS協議族的全部，但解釋了在應用中可能出現的大多數情況。本文的目的是為電能量數據采集終端提供與使用DLMS協議族的電能表通訊的協議說明。

?????? 本文參考文獻如下：

?????? （1）DLMS User Association , COSEM Identification System andInterface Objects , Third Edition

?????? （2）IEC62056 －53 Electricitymetering - Data exchange for meter reading, tariff and load ????????????????????????????????????????????????? ?????control -Part 53:?COSEM applicationlayer

?????? （3）IEC62056 －46Electricity metering - Data exchange for meter reading, tariff and load ?????????????????????????????????????????????????? ???????? control -Part 46:?Data link layerusing HDLC protocol

?????? （4）IEC62056 －42?Electricity metering - Data exchange for meter reading, tariff and load ????????????????????????????????????????????????? ???????? control -Part 42:?Physical layer?servicesand procedures for ??????????????????????????????????????????????????????????????????? connection-orientedasynchronous data exchange

?????? （5）IEC62056 －61 Electricity metering - Data exchange for meter reading, tariff and load ????????????????????????????????????????????????? ???????? control -Part 61: Object identificationsystem (OBIS)

?????? （6）Amber Management logical device－FR:AMBER/FW TECH_SPEC ??????????????????????????????????????????????????????????????????????????????? ???????? MANAGEMENT_LOGICAL_DEVICE

?????????（7）Amber Electricity Logical Device －?FR:AMBER/FWTECH_SPEC ???????????????????????????????????????????????????????????????????????????????? ???????? ELECTRICITY_LOGICAL_DEVICE

???? （8）A Layman's Guide to a Subset of ASN.1, BER, and DER－

?????????????????????????????????? AnRSA Laboratories Technical Note

?????????????????????????????????? Burton S. KaliskiJr.Revised November 1, 1993

?????? （9）IEC61334采用配線載波的配電自動化，譯文匯編。

一、本文的結構

?????? 由于DLMS協議族的復雜性，必然導致本文篇幅較長，涉及的內容比較多。這里有必要把本文的內容，做一個綜述，并解釋各部分之間的相互關系。

?????? 一、DLMS協儀模型：從整體上介紹DLMS協議。

?????? 二、DLMS物理層協議：講述DLMS物理層在整個協議族中的作用。

?????? 三、DLMS鏈路層協議：講述HDLC鏈路層協議在整個協議族中的作用。

?????? 四、DLMS應用層協議：講述DLMS應用層協議在整個協議族中的作用。這一部分又???????????????? 包括如下幾部分內容。

????????????? （一、）ASN.1語法：這個語法是用來描述DLMS應用層協議幀的組成的。

????????????? （二、）BER編碼與AXDR編碼：這兩種編碼是用來實現ASN.1語法的。

????????????? （三、）AARQ與AARE數據幀：這是兩個特殊的數據幀，它用來構筑DLMS協??????????????????????????????? 議中的client端與server端的應用層連接。

????????????? （四、）數據請求過程描述：介紹請求數據時所用的的數據幀。

?????? 五、請求數據實例：這里提供了幾個請求數據的實際范例的數據包文。

1、? 請求電量

2、? 請求瞬時量（電壓、電流、功率）

3、? 請求負荷曲線

4、? 請求時間

一、DLMS協儀模型

下圖從整體上描述了DLMS協儀模型。

協儀共分為3層，物理層，鏈路層，應用層。層與層之間使用指定的服務通訊。

通訊的雙方采用Client—Server結構，數據請求端（采集器）為Client，數據提供端(電表)為Server.

通訊過程描述：

（一）?? 建立物理層連接

??? 物理層位于通訊模型的最底層。DLMS規約可以建立在多種物理層之上，物理層的做用主要是對底層通訊硬件的操做（如對PSTN?MODEM的初始化，打開，?? 關閉。）

（二）?? 建立鏈路層連接

???????????????????? 物理層連接建立之后，數據通訊的第一步是建立鏈路層的連接，鏈路層主要負?????? ?? ? 責數據傳輸的可靠性，包括以下幾個方面，地址校驗，幀長校驗，數據的CRC校??????????????? 驗。長數據幀的拆包組包。同時向應用層提供鏈路傳輸的服務。

（三）?? 建立應用層連接

????????????? 鏈路層連接建立之后，在DLMS協儀中還要建立應用層連接，才可進行數據通訊。

?????? 這個應用層連接建立過程被稱為Negotioation。

????????????? 這個過程是為數據通訊提供一些配置參數。應用層連接請求由Client端發起，Client????? 端發aarq幀，Server端響應aare幀

（四）?? 進行數據通訊

?????? 當連接建立起后，就可進行數據通訊了。Client端發送數據請求幀Server端以數據響應。Client在請求不同的數據時，要使用特定數據的獨有的class id和OBIS，用以標識不同類型的數據。

（五）?? 數據通訊結束，釋放鏈路，解除連接。

?????? 數據通訊結束后，發鏈路結束幀，結束一次通訊過程。一次數據通訊結束后，可以通過發鏈路結束幀，來結束一次通訊過程。也可以，不發任何數據幀，依靠server端的超時掛斷機制，來結束一次通訊過程。一般應使用前者。

（六）?? 解除物理層連接

關閉物理端口（如掛斷Modem）。從物理上結束一次通訊。

二、DLMS物理層協議

?????? 物理層協議位于DLMS協議族的最底層，負責數據通訊的物理傳輸。DLMS可以工作于多種不同的物理介質上（PSTN，網絡，串行通道等）。

?????? 物理層的功能是接受鏈路層數據，發送到物理介質上，傳送到通信的對端。或是接收通信的對端傳送來得數據，再傳送到鏈路層，供更高層的協議處理數據。

?????? DLMS物理層協議，主要規定了物理層應實現的服務，如：打開端口，初始化端口，收發數據，關閉端口等。在通常的嵌入式系統中（如電能量采集裝置），物理層對應于系統的底層驅動部分。這部分一般不被通訊規約控制。因此，在不影響通訊協議功能實現的前提下，本文將不具體討論物理層服務。

三、DLMS鏈路層協議

?????? 物理層之上即為鏈路層，鏈路層是物理層與應用層通信的通道。DLMS鏈路層使用的是HDLC高速鏈路控制協議。

??????

鏈路層的構成：

?????? 鏈路層由兩個子層構成，即LLC子層，和MAC子層。

?????? （一）、LLC子層（邏輯鏈路控制子層）

?????? 這一層的功能是將MAC子層的數據轉發到應用層，或將應用層的數據轉發到MAC子層。LLC子層只是作轉發而不對數據做出處理。其存在的重要性在于向應用層提供鏈路傳輸的服務（從鏈路層接收或發送數據）。

?????? 具體到數據通訊時，對于client端應用層發送的數據，要加上LLC幀頭（0xe6 , 0xe6, 0x00）,server端應用層發送的數據，要加上LLC幀頭（?0xe6 ?, ?0xe7 ,?0x00）。

?????? 由于LLC子層鏈路傳輸服務的具體實現，可以不受DLMS協議的限制，由應用程序實現。故本文不具體說明LLC子層的各種服務。

?????? （二）、MAC子層（媒體訪問控制子層）

?????? MAC子層在鏈路層中負責數據傳輸的可靠性，包括地址檢查，數據的CRC校驗，長數據幀的打包拆包等。這些工作對于數據通訊都是必不可少的，MAC子層功能的說明將是以下的重點。

1??HDLC幀格式

（1）不包含應用層數據信息

0x7e

幀類型與幀長

目的地址域

源地址域

控制域

數據幀校驗

0x7e

兩個0x7e是HDLC數據幀固定的幀頭與幀尾，兩個0x7e之間是鏈用戶數據。

（2）?包含應用層數據信息

0x7e

幀類型與幀長

目的地址域

源地址域

控制域

幀頭校驗

LLC幀頭

用戶數據信息

數據幀校驗

0x7e

與不包含應用層數據信息的數據幀相比這里多了3項：

幀頭校驗：為增強通訊的可靠性，對幀頭的數據也加上CRC校驗。幀頭包括如下??

字段：幀類型與幀長、目的地址域、源地址域、和控制域

LLC幀頭：用戶數據信息前要加0xe6 , 0xe6, 0x00或0xe6 , 0xe7, 0x00。

用戶數據信息：應用層處理的數據。

注：出于數據完整性的考慮，用戶數據信息的最大長度，默認為128字節。如果想要更多的字節，可以在SNRM數據幀中協議。

2??幀類型字段與‘S’位

幀類型與幀長字段，共兩個字節。內容如下：

FrameType ：用于指出當前數據幀的類型。HDLC有多種數據幀類型，DLMS使?用Frame Type 3。FrameType恒為A（1010）。

?????? S：（segmentation Bit）這個字段只有一位，它用于說明數據幀是否被分割。在長數據幀傳輸時要使用到這一位。長數據幀的傳輸將在后面解釋。

?????? FrameLength Sub－field ：這個字段用于說明當前數據幀的長度，（以字節為單位，不包括兩個0x7e）

3??????????地址解析

?????? 地址域分為兩部分。目的地址域和源地址域。對于client端，目的地址為server的地址，源地址為client的地址。對于server端正好相反。

（1）擴展編址技術

?????? HDLC使用擴展編址技術，即某一個地址字節的最低位如為0，則表明該地址域沒有結束，仍有后續字節是該地址域的一部分。若某一地址字節最低位為1，則說明該地址域已經結束，沒有后續字節。

（2）地址結構

?????? ?????? Client端的地址永遠是一個字節，由于擴展編址技術的使用，最低位置1，所以client?????? 端的地址只能有128個。

?????? Server端為了實現一個物理地址對應多個邏輯地址，將地址分成了兩部分upper HDLCAddress?用于表述邏輯地址，lower HDLC address用于表述物理地址。Upper?address總是應當有的，lower address在確認不需要的情況下，可以不出現。（sl7000 電表這兩部分地址都是需要的）。

?????? Server端的地址在使用擴展編址技術時，也并非是可以無限長（雖然在理論上可以，但在實踐上是有上限的）。Server端的地址結構可以使用如下方式：

?????? Onebyte: only the upper HDLC address is present.

?????? 一字節：只出現HDLC高位一字節地址。??????

?????? 兩字節：只出現HDLC高位一字節地址，和HDLC低位一字節地址。??????

?????? 四字節：只出現HDLC高位兩字節地址，和HDLC低位兩字節地址

???????? 對于SL7000電表，經測試只有四字節sever地址結構可用。

（3）特殊地址

?????? 有一些地址被HDLC定為保留地址。這其中比較重要的是廣播地址。??????

?????? 對于SL7000電能表，實踐中可行的地址結構是client端一字節，server端4字節。對于DLMS協議族是可以使用上述地址結構中的任一種，并且支持特殊地址。

4??????????幀控制字

?????? 幀控制字字段主要負責，通訊中的幀計數，以及特殊數據幀的標識。

?????? 幀控制字字段結構如下：

?????? 對應項的解釋如下：

?????? RRR：為接收幀計數。

?????? SSS：為發送幀計數。

????????????? ?注：對幀計數的解釋，

????????????? ?????? 在鏈路層連接建立之后，第一次請求數據時（在client端，包括發送AARQ）???????????????? RRR置為0，SSS置為0。Server端收到這一幀數據后，返回數據響應RRR為1，????????? ?????? SSS為0。Client再次請求數據時RRR加1，SSS加1。Server端收到這一幀數據后，????????????? 返回數據響應RRR加1（成為2），SSS加1。如此反復直到client得到所有的數據??????????????? 為止。整個數據傳輸過程以I數據幀請求和響應。這里要說明的是在請求數據結束?? ????????????? 后還要再發送RR幀，收到確認后。才可以再發送DISC幀結束鏈路。其中Client端??????????????? 的RR幀中的幀計數位RRR只需將client的幀計數位RRR加1得到。

????????????? 下圖描述了幀計數位的變化過程：

P/F：poll/final bit。

?????? ?Poll bit ：由client發送，置1時表示server端回應，置0時表示不允許回應。

?????? ?final bit：由server發送，置1時表示一次數據幀的發送結束，置0時表示還未???????????????????????? 發送完。final bit只有在通訊窗口（window size）大于1的情況下才有意?????????????? 義。在window size ＝ 1時，由server端返回的數據幀中的這一位總是???????????????????? 置1。（關于window size將會在“建立鏈路層連接”時解釋）

?????????????

幾種不同的數據幀分別應用在不同的場合，下圖列出了幾種請求和響應的對應的情況。

????????????????????

?????? I????? ：信息傳輸幀

RR?? ：準備接收數據幀（用來表示準備接收下一幀數據）

RNR：接收沒有準備好（receive not ready）。相當于別的通訊協議中的忙幀。

SNRM：設置正常相應數據幀。用于建立鏈路層連接。

UA：對SNRM和DISC的響應幀。

DISC：結束鏈路幀。

DM：對DISC的響應幀。（Disconnected?mode）

UI：可以用于保持鏈路，這個數據幀的發送，對于鏈路的控制沒有任何影響。

FRMR：拒絕接收幀（Frame reject），由于不確定的某種原因拒絕接收到的數據幀。

5??????????長數據幀的傳輸

?????? 在很多情況下，數據不能在一次請求和一次響應中，就能夠結束數據傳輸的過程（受限于用戶數據字節不超過128字節）。這時就有必要啟動長數據幀鏈路控制流程。

?????? 注：請求負荷曲線時一定是使用長數據幀。

?????? 當使用長數據幀時，必須把長數據幀分割成短數據幀。然后把這些短數據幀依次發送出去，在接收端將這些短數據幀依次處理。這樣就實現了一個較大的數據包，完整的傳送到接收端。

?????? 在數據幀被分割時，幀類型與幀長字段中的‘S’位，將被置1。當接收端檢測到這一位被置位后，就知道數據幀已被分割，此時要做出對分割數據幀的相應處理。

?????? 下圖介紹了長數據幀的收發過程：

client端通過發送RR數據幀來請求被分割的數據幀的其他部分。

6??????????數據幀校驗

?????? HDLC使用16位CRC校驗。使用的多項式是：

?????? 具體的實現程序，可參照英文參考文獻IEC62056 － 46的附錄A。

（三）、鏈路層連接的建立，與斷開

?????? （1）建立連接

?????? 鏈路層在開始工作之前，要建立鏈路層連接（Association）。這一步驟是通過client端發送SNRM數據幀，server端響應UA數據幀表示已建立連接，server端響應DM數據幀表示鏈路斷開，連接沒有建立。

UA數據幀常含有鏈路參數的配置信息。鏈路參數是指2個控制數據傳輸的參數。

WINDOW_SIZE parameter;???????? 這個參數描述通訊時，通訊的雙方一次發送數據幀的數目。?????????????????????????????????? ????????????? HDLC允許一次發送多幀數據。

MAXIMUM_INFORMATION_FIELD_LENGTHparameter . 最大信息域長度，這個參數用于描????????????????????????????????????? ?????? 述一個鏈路數據幀中用戶數據的長度。

?????? 這兩個參數的默認值如下

default WINDOW_SIZE = 1;

defaultMAXIMUM_INFORMATION_FIELD_LENGTH ＝ 128（BYTEs）

具體在數據幀中有如下4個參數：

transmit maximum information field length 

receive maximum information field length 

transmit window size

receive window size

注：這里沒有給出數據幀的具體格式，而是用舉例來說明如何組幀。這種做法可能給讀者帶來不便。但在DLMS的規約原文中就是用這種辦法，故這里仍這樣做。

以下舉例說明如何建立連接：

//SNRM

S: 7e a021 00 22 00 23 03 93 0b 14 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 0400 00 00 07 65 5e 7e

解釋：

a0 21????? 幀類型與幀長

00 22 0023??? 目的地址

03 ???????? 源地址

93?????????? 控制字

0b 14 ??? 幀頭校驗

81 80 ??SNRM 標識

12 ???????? group lenth.

05Hparameter identifier (maximum information field length transmit)

????????????? 01H parameter length (1 octet)

????????????? 80H parameter value(128 bytes)

06Hparameter identifier (maximum information field length receive)

????????????? 01H parameter length (1 octet)

????????????? 80H parameter value? (128 bytes)

07Hparameter identifier (window size, transmit)

????????????? 04H parameter length (4 octets)

????????????? 00H parameter value? (high byte of value)

????????????? 00H parameter value

?????? ?????? 01Hparameter value? (low byte of value)

08Hparameter identifier (window size, receive)

????????????? 04H parameter length (4 octets)

????????????? 00H parameter value? (high byte of value)

????????????? 00H parameter value

????????????? 07H parameter value? (low byte of value)

65 5e????? 數據幀校驗（CRC校驗）

在SNRM數據幀中的用戶信息可以不出現，表示client接收server端的已配置數據。

//UA

R: 7E A021 03 00 22 00 23 73 28 F0 81 80 12 05 01 80 06 01 80 07 04 00 00 00 01 08 0400 00 00 01 53 3B 7E

解釋：

7E//Flag

?????? 0xA0 21//(type=a :frame type 3 , s=0 :end of frame , len=021 : 33 bytes)

?????? 03//source address

?????? 00 22

?????? 00 23 //destination address

?????? 73 //control UA

?????? 28 F0 //hcs

?????? 81 80 12 05 01 80 06 01 80 07 04 00 00 0001 08 04 00 00 00 01

?????? //information field

?????? //parameter negotiation

?????? //81

?????? //80

?????? //12

?????? //05? 0180?????????????????????????? :maximuminformation field length? transmit (128BYTEs)

?????? //06? 0180?????????????????????????? :maximuminformation field length? receive? (128 BYTEs)

?????? //07? 0400 00 00 01????????????? :window size,transmit (1)

?????? //08? 0400 00 00 01????????????? :window size,receive? (1)

?????? 53 3B//fcs

?????? 7E

?????? （2）斷開連接

?????? 斷開連接由于不用參數設置，所以比建立連接要簡單。Client端發送DISC數據幀，Server端響應UA或DM表示斷開連接。UA表示接到DISC后斷開連接。DM表示在接到DISC之前已處于斷開狀態。

一下仍給出具體的通訊實例：

S: 7e a0 0a 00 22 00 23 03 53 06 c7 7e

解釋：

7e a0 0a 00 22 00 23 03

53 // 幀類型Disc

06 c7 7e

R: 7E A0 0A 03 00 22 00 23 1F 43 4C 7E

解釋：

7E A0 0A 03 00 22 00 23

1F//幀類型DM

43 4C 7E

（四）、關于鏈路層的透明數據傳輸

0x7e

幀類型與幀長

目的地址域

源地址域

控制域

幀頭校驗

LLC幀頭

用戶數據信息

數據幀校驗

0x7e

?????? HDLC是一種透明數據傳輸的鏈路層協議。用戶數據信息與鏈路層沒有任何關系。在DLMS的協議模型中，鏈路層負責數據傳輸的可靠性，應用層處理用戶數據信息。鏈路層為應用層數據的傳輸提供透明通道。

四、DLMS應用層協議

?????? 理解DLMS應用層協議，需要首先建立以下幾個概念：

?????? ASN.1語法，BER編碼，AXDR編碼。

??? ASN.1語法是用來描述應用層數據幀的。DLMS協議不同于其他一些簡單通訊協議的地方就在于此。他不是用一些表格，及一些固定的幀格式來描述的，而是用一種抽象語法語言來描述。這樣做的好處是，極大的提高了協議的抽象性和通用性，有利于程序移植。

?????? BER編碼和AXDR編碼是用來實現ASN.1語法的。為了實現ASN.1的抽象性和通用性，這個語法要用特殊的編碼來描述。這就引入了BER編碼和AXDR編碼。

?????? 以下分別解釋這幾項。

（一）ASN.1語法

?????? 一個用ASN.1語法描述的數據幀，看上去應該是下面的樣子：

?????? Name ?::= ?[tag]? ??????IMPLICIT/ EXPLICIT ????????Data type

?????? {

?????? null-data ????????? [0]?IMPLICIT NULL,

?????? item1????? ?????? [1]?IMPLICIT/ EXPLICIT??? Data type? A1 OPTIONAL

?????? item2????? ?????? [2]?IMPLICIT/ EXPLICIT?????Data type ?A2 OPTIONAL

?????? item3???????????? [3] Data type????????????

?????? …

?????? }

?????? 下面解釋這個語法描述。

Name? ? －??? 是這個數據幀的名字。

Tag???????? －??? tag包含兩部分classtype 和一個數字

???????????????????? Class type有以下四種：

???????????????????? ?????? 1）Universal? 表明name定義的數據幀在所有的DLMS應用中的含義是唯一的。

???????????????????? ?????? 2）Application 表明name定義的數據幀的含義同具體的應用有關。

???????????????????? ?????? 3）Private?表明name定義的數據幀只在某一廠家的自定義范圍之內。

???????????????????? ?????? 4）Context-specific 表明name定義的數據幀同上下文數據項的含義有關。??????????????????????????? 這種類型的數據，在不同的結構中可能有不同的含義。

???????????????????? Tag中的數字，是作為這個數據幀的標號存在的，它做為該數據幀的句柄出現?????????????? 在應用數據單元中。

IMPLICIT/ EXPLICIT －?????當前數據幀（稱為子數據幀）可能派生于某一數據幀（稱為父數?????????????????????????????????? ?????? 據幀），這個字段用來描述子數據幀同父數據幀的關系。

? ? ? ? ?IMPLICIT? ：???? 改變了父數據幀的Tag。

? ? ? ? ? EXPLICIT ：?? 不改變父數據幀的Tag。

? ? ? ? ? 不注明IMPLICIT的項即為EXPLICIT。

Data type －???? 描述數據幀的數據類型。數據類型分為簡單型和復合型。多數數據類型可以從?????????????? 名字看出其類型。以下列出了幾種，完整的數據類型集合請參見附錄。

???Type???????????????????? Tag number???? Tag number

???????????????????????????? (decimal)????? (hexadecimal)

??? INTEGER????????????????? 2????????????? 02

??? BIT STRING?????????????? 3????????????? 03

??? OCTET STRING???????????? 4????????????? 04

??? NULL???????????????????? 5????????????? 05

??? OBJECT IDENTIFIER??????? 6????????????? 06

??? SEQUENCE and SEQUENCE OF 16???????????? 10

??? SET and SET OF?????????? 17???????????? 11

??? PrintableString????????? 19???????????? 13

??? T61String??????????????? 20???????????? 14

??? IA5String??????????????? 22???????????? 16

??? UTCTime????????????????? 23???????????? 17

“{}”－??????? 大括號中的內容，即為數據幀中的數據項。每一數據項后的數字序號，即為該???????????????????? 數據項的標識（tag）。每一數據項可以是對另一數據幀的復合。即一個數據?????????????????????? 幀通常是對其它數據幀的一種組合。

OPTIONAL －這個關鍵字描述的數據項，在用戶認為需要的場合可以省略。

比較重要的兩種復合類型SEQUENCE和CHOICE 下面舉例解釋：

?????? 1）SEQUENCE ：數據幀中的內容是順序排列的。下面以舉例說明SEQUENCE類型。

????????????? Get-Request-Normal ::=?SEQUENCE

????????????? {

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

????????????? cosem-attribute-descriptor?? Cosem-Attribute-Descriptor,

????????????? access-selection-parameters Selective-Access-DescriptorOPTIONAL

????????????? }

?????? 這是一個在請求數據時常用的數據幀。SEQUENCE表明數據幀的內容是順序排列的。

?????? 2）CHOICE ：即選則類型，它表明當前數據幀是從幾個數據幀中選擇一種做為當前數???????????????? 據幀的類型。下面以舉例說明CHOICE類型。

?????? ?????? 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數據幀只能填入三個選擇項之一。

?????? 以上簡單介紹了ASN.1語法，由這一語法描述的各種數據幀，將在附錄中全部給出。這些各種各樣的數據幀，將構成DLMS協議中Client同Server應用層交互時使用的語言。

?????? 讀者如對ASN.1語法有不解之處，可參閱本文的英文參考文獻【7】

（二）BER編碼與AXDR編碼

?????? ASN.1只是一種語法，要把它寫入數據幀中，就要把它轉換為一個個數據字節。這就要一種（實際是兩種）編碼來實現這種語法。于是就引入了BER編碼與AXDR編碼。

?????? 在DLMS中用ASN.1描述的DLMS協議，用BER編碼實現；用ASN.1描述的XDLMS協議用AXDR編碼實現。

?????? 注：DLMS中只有AARQ與AARE數據幀的部分內容是使用DLMS協議的。絕大多數的應用層數據通訊使用XDLMS。這里無意對DLMS和XDLMS做出劃分和解釋，具體的解釋可參見英文參考文獻【2】。這里只需知道這兩種協議使用不同的編碼。

1 BER

編碼的詳細語法參見附錄。

通常的BER編碼采用如下結構，其中數據內容部分可以嵌套另一BER編碼結構：

數據標識

數據長度

數據內容

數據長度，和數據內容從名字即可知道內容。

這里有必要解釋一下數據標識的構成：

一個BER數據標識和一個BER數據長度構成一個16位的位串：

bit15????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? bit0

datatype classes（bit15、14）

Data type（bit13）

data length（bit12－bit0）

1）datatype classes 字段：這一字段用于對ASN.1語法中的class type編碼

???? Universal??? (00)

???? Application? (01)

???? Context-specific? (10)

???? Private ?????????? (11)

2）Datatype字段：用于描述數據內容的結構

???? Primitive ???????? (0)???? 簡單類型

???? Constructed ?????? (1)????? 復合類型（數組或結構）

3）datalength字段：用于描述數據內容的長度（以字節為單位）。

下面以接收到的AARE數據幀為例：

AARE數據幀的語法描述：

AARE-apdu ::= [APPLICATION1] IMPLICIT SEQUENCE

――[APPLICATION 1] == [ 61H ] = [ 97 ]

{

protocol-version?????????????????????????? [0] IMPLICIT BITSTRING {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 presentif only the kernel is used.

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

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

mechanism-name????????????????????? ?????? ?[9] IMPLICITmechanism-name?OPTIONAL,

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

responding-authentication-value??? ?[10] EXPLICIT authentication-value?OPTIONAL,

implementation-information????????????? [29] IMPLICIT implementation-dataOPTIONAL,

user-information?????????????????????????????????? [30]IMPLICIT association-information?OPTIONAL

}

AARE數據幀的BER編碼和AXDR編碼實現：

61 //AARE tag

42 //AARE len

A1 //tag of COSEM_Application_Context_Name

?09?????????????????????? ?//數據長度

?06????//(OBJECTIDENTIFIER, Universal)OBJECT IDENTIFIER是一種????????????????????????????????????? ????//ASN.1數據類型.

? 07???????????????????????? //數據長度

?6085 74 05 08 01 01 //數據內容

//以下的數據幀可以用同樣的方法一一解釋

A2 //Tag of Association-result,

03 02 01 00

A3 //Tag of Associate-source-diagnostic

05 A1 03 02 0100

88 //IMPLICIT ACSE-requirements OPTIONA

02 07 80

89 //IMPLICIT mechanism-name OPTIONAL

07 60 85 74 0508 02 01

AA //EXPLICIT authentication-value OPTIONAL

0A 80 08 41 4243 44 45 46 47 48

04 // encoding the choice for user-information (OCTET?STRING,Universal)

0E // encoding of the length of the OCTET STRING’s value field (14 octets)

??? /*以下內容為XDLMS用AXDR描述*/

08 //encoding the tag (explicit tag) of the DLMS PDU CHOICE(InitiateResponse)

00 // usage flag for the proposed-quality-of-service component(FALSE, not present)

06 //negotiated-dlms-version-number

5F 1F // encoding the [APPLICATION 31] tag (ASN.1 explicit tag)

04 // encoding the length of the 'contents' field in octet (4)

00 // encoding of the number of unused bits in the final octet ofthe bitstring

00 08 1D// encoding of the fixed length BITSTRING value????????????????? ??

21 34 // the A-XDR encoding of an Unsigned16 is its value

? 0007 // the A-XDR encoding of an Unsigned16 is its value . 00 07 == LN??

2? A-XDR:

?????? 這種編碼是對unix的XDR（外部數據標識法）編碼的擴展。參見IEC61334采用配線載波的配電自動化，譯文匯編，下冊，第六部分。本文參考文獻【9】

3???? 兩種編碼的比較：

?????? A-XDR編碼，與BER編碼的區別可從下例看出。

?????? 對兩數進行編碼，其值分別為0x1234,0x5678

1）用BER編碼

序列標識

序列長度

A的標識（整型）

A的字長

A的數值

B的標識（整型）

B的字長

B的數值

??????

2) 用AXDR編碼

序列標識

A的數值

B的數值

這里給出一個AXDR編碼的實例：

注：這里的語法仍是ASN.1但將采用不同的編碼。

ASN.1語法描述：（這一數據幀是AARQ數據幀的一部分）

xDLMS-Initiate.request ::=?SEQUENCE

{

dedicated-key OCTET STRINGOPTIONAL,

response-allowed?BOOLEANDEFAULT TRUE,

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

proposed-dlms-version-numberUnsigned8,

proposed-conformanceConformance,

client-max-receive-pdu-sizeUnsigned16

}

AXDR編碼：

01--------------------------------------------------------dlmspuu標識

00 ----------------------------------//usageflag for the dedicated-key component (FALSE, not present)

00--------------- //usage flag for theresponse-allowed component (FALSE, default value conveyed)

00-------------- //usage flag for theproposed-quality-of-service component (FALSE, not present)

06-------------- //the A-XDR encoding of anUnsigned8 is its value

5f ---------- //encoding the [APPLICATION31] tag (ASN.1 explicit tag)

?04---------- //encoding the length of the'contents' field in octet (4)

?????? 00-----//encoding of the number of unused bits in the final octet of the BITSTRING

?????? ?00 00 10------- // encoding of the fixedlength bitstring value.(LN/SN)

00 80 // client-max-receive-pdu-size（128 bytes）

（三）AARQ與AARE數據幀

?????? 有了基本的語法和編碼的概念后，下面就開始討論具體的DLMS應用層協議。在前面的DLMS協議模型中已經說明，在進行應用層數據通訊之前，要建立鏈路層連接和應用層連接。鏈路層連接已經在鏈路層協議中解釋過，下面講如何建立應用層連接。

?????? 應用層連接的建立是通過client端發送AARQ數據幀，server端響應AARE數據幀來實現的。這兩個數據幀主要是配置應用層數據通訊的參數。

?????? 關于AARQ,AARE：

在標準的面向連接的應用層服務控制（ACSE）中，為了同服務的使用者進行交互，ACSE提供了很多功能單元。在COSEM中只使用了其中的兩個：the?kernel?and theauthentication functional units.

（一） AARQ ， AARE數據幀的具體描述（ASN.1語法描述）：

AARQ-apdu ::= [APPLICATION0] IMPLICIT SEQUENCE

{

protocol-version ???????????????????????? [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?OPTIONAL,

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-qualifier ?????????????????? [7] AE-qualifier?OPTIONAL,

calling-AP-invocation-id ?????????? [8] AP-invocation-identifier?OPTIONAL,

calling-AE-invocation-id???????????? [9] AE-invocation-identifier?OPTIONAL,

.?Thefollowing 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 presentif the authentication functional unit is selected.

mechanism-name ??????????????????? [11] IMPLICIT mechanism-nameOPTIONAL,

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

calling-authentication-value????? [12] EXPLICIT authentication-value?OPTIONAL,

implementation-information?? [29] IMPLICIT implementation-data?OPTIONAL,

user-information ??????????????????????? [30] IMPLICITassociation-information?OPTIONAL