遲海龍，劉金偉，劉曉彤，龔傳利

（1.北京中水科水電科技開發(fā)有限公司，北京 100038；2.中廣核工程有限公司，廣東 深圳 518100；3.中國水利水電科學研究院，北京 100038）

0 前言

IEC60870-5-103[1](以下簡稱為103規(guī)約)繼電保護通信規(guī)約采用FT1.2異步式字節(jié)傳輸(Asynchronous byte transmission)的幀格式。規(guī)約可以多種方式實現。通常采用的方法是在接收和發(fā)送兩個端點上分別設置兩個計算工作線程，通信過程就是兩臺設備的收發(fā)端點進行交互的過程。該方法一般可歸為同步處理的信息交互方式，對平衡的通信模式比較適用。同步模式因具有程序簡單明了的優(yōu)點，被很多早期規(guī)約處理程序所采納。但這種方式有明顯的不足：①程序交互過程中為同步接受和發(fā)送的信息設置的大量等待時間導致處理程序對外界信息反應遲鈍，嚴重時可導致信息遺漏。②當通信間隔裝置在采用非平衡的一對多點輪詢拓撲結構通信模式時，由于通信主站（以下簡稱主站）要面對大量被控站（以下簡稱從站），這使得主站在跟蹤各從站的通信狀態(tài)時需要大量輔助狀態(tài)變量，程序處理比較繁雜。為此，需要采用新的方法予以解決，本文提出的可以跟蹤主站以及從站通信狀態(tài)的狀態(tài)機模型方法，是解決這一問題方法之一，可以大幅降低程序開發(fā)和維護擴展的難度。本文主要討論狀態(tài)管理模型在103通信主站側的實現。

1 通信過程

1.1 概述

規(guī)約的傳輸過程中的數據采集就是主站和從站之間通過若干個請求/確認或者指示/響應服務原語[2](REQ/CONF 或者IND/RESP)的周期性數據交換達到兩端數據一致的過程。采集過程按照數據的多少可分單周期或者多周期時間完成。交互過程可通過過程圖或者狀態(tài)圖表示。圖1A、1B為交互的狀態(tài)圖，圖1C為動作序列示意圖。本文主要討論主站端的有限狀態(tài)機的實現方式，文中只給出通信過程的發(fā)送端狀態(tài)圖，其他圖可以類似思路實現。

圖1 交互過程狀態(tài)圖及序列圖

103規(guī)約工作在單點對多點的主從Polling（輪詢）方式。正常工作時，主站依次輪詢從站的2級用戶數據，如果從站產生1級數據，通過上送的2級數據報文控制域中的ACD標志位[2]，請求主站查詢1級數據。主站在接收到從站查詢請求后可以馬上發(fā)出再次1級數據召喚或者在下一次輪詢周期內發(fā)出再次召喚1級數據直到從站將ACD復位0后不再請求召喚為止。通常主站查詢完某個從站的1級數據后，則繼續(xù)開始對下一個從站的查詢。這是正常通信的一個基本過程。

主站在開始新一輪發(fā)送/確認服務時，改變下發(fā)報文控制域中幀計數位FCB的狀態(tài)。如超時（等待時間50 ms）未收到從站發(fā)回的確認幀或響應幀，則不改變FCB狀態(tài)重發(fā)原報文，最大重傳次數為3次。如果重發(fā)3次后仍收不到應答報文，則首先發(fā)復位幀計數位（FCB）復位命令，如果仍收不到應答報文，則復位從站（CU）。復位幀計數位（FCB）復位把FCB置0、發(fā)送緩沖區(qū)不清零。復位從站把FCB置0、發(fā)送緩沖區(qū)清零。從站上電或復位后，待收到FCB或CU復位命令后，響應確認并請求訪問1級數據。以ASDU5標識報文上送廠家名稱等設備信息，參數傳送原因項為FCB或CU。然后是時間同步（ASDU6）和總查詢（ASDU7）。初始化時對時采用SEND /CONFIRM方式，分別對每一個從站對時。

1.2 遙測過程

主站周期地順次對每個間隔單元召喚 2 級用戶數據，從站以ASDU03或ASDU09上送遙測數據。這個過程的全部狀態(tài)及動作序列如圖1所示 。

1.3 遙信過程

從站的全遙信通過主站對從站的總查詢上送。當主控或從站初始化過程中啟動總查詢，以收集帶有總查詢標志的信息?？偛樵冞^程：主站向從站發(fā)總查詢命令（采用ASDU7），裝置以確認幀回答后，在將總查詢信息轉成1級用戶數據后，在當前上送報文里控制域的要求訪問位（ACD）[3]置1。總控收到ACD=1后，向裝置查詢 1 級數據。裝置以 ASDU 01（02）上送全遙信。運行正常以后，主站按一定時間間隔（約15 min）啟動總查詢。在兩次總查詢間隔過程中，總控輪詢各裝置2級數據，裝置一旦檢測到發(fā)生遙信變位，則把上送2級數據報文ACD置1，

通知主站查詢1級數據。裝置通過ASDU 01（01H）上送變位遙信和ASDU02（02H）上送SOE。

1.4 命令過程

有兩種標準的命令傳輸過程，即:①選擇和執(zhí)行命令；②直接命令。直接命令就是主站下達命令（IND原語）后，從站立刻執(zhí)行并把結果通過RESP原語反饋給主站。這里重點討論前者的狀態(tài)過程。

主站給從站發(fā)送請求原語SELECT（REQ），從站接收后，如應用進程準備接收“選擇命令”，它將產生“選擇響應”，通過SELECT(RESP)選擇命令響應原語返送給主站。主站接收后通過SELECT（CON）選擇確認原語產生“選擇確認”。 選擇過程可由“撤消命令”停止執(zhí)行。如選擇命令得到確認，主站再以 EXCO（REQ）請求原語向從站發(fā)“執(zhí)行命令”。 從站以 EXCO（IND）指示原語傳遞給應用進程功能， 將“執(zhí)行響應”返回給控制站，產生肯定或否定的確認。詳細的過程參見文獻[3]。文獻中給出了選擇和執(zhí)行命令傳輸過程序列圖。本文給出主站端的命令傳輸的狀態(tài)圖（圖2）。圖中給出了命令發(fā)送端需要預置的3個相關狀態(tài)（總狀態(tài)的一個子集）：①設備就緒（命令起始態(tài)），②命令選擇態(tài)度，③命令下達狀態(tài)。設備就緒態(tài)為起始態(tài)，每次命令下達都要從此處出發(fā)，完成傳輸后也要回歸此態(tài)。命令選擇態(tài)和命令下達為中間過渡態(tài)，命令選擇態(tài)主要決定命令的下達與撤銷的不同路徑，命令下達態(tài)為設備等待命令執(zhí)行的中間過渡過程。

圖2 主站命令傳輸狀態(tài)轉換圖

2 狀態(tài)機（State Machine 以下簡稱SM）管理模型

狀態(tài)機是有限狀態(tài)自動機的簡稱，是現實事物運行規(guī)則抽象而成的一個數學模型。狀態(tài)機主要由狀態(tài)構成，可以描述為一組狀態(tài)事件集合和狀態(tài)轉換圖。

2.1 狀態(tài)集合

狀態(tài)集合是狀態(tài)機的重要組成部分，是SM工作當中的主要依據，對其的設計需要考慮以下幾個方面：狀態(tài)的定義和使用的便利性。通常一個工業(yè)級的SM都會有大量的狀態(tài)變量，狀態(tài)變量的管理對SM的設計有很重要的作用，決定了自動機可維護性。狀態(tài)的分組和繼承。先設計頂層狀態(tài)量然后通過繼承的機制不斷分化和細化頂層狀態(tài)的細節(jié)狀態(tài)并作為該頂層狀態(tài)的各個子狀態(tài)。按照1.2節(jié)中過程討論103規(guī)約應該設置的狀態(tài)如表1所示。

表1 狀態(tài)定義

2.2 事件和槽函數

狀態(tài)機的事件和各個槽函數如表2所示。具體過程描述參考狀態(tài)轉換圖。

表2 事件及槽函數集合

3 狀態(tài)轉換圖

狀態(tài)轉換圖是狀態(tài)機模型的動態(tài)工作的具體體現，這里主要討論初始化過程和采集通信過程中的狀態(tài)轉換圖的細節(jié)。

3.1 初始化及異常狀態(tài)轉換圖

在主站端上電后或者發(fā)送請求報文超過3次收不到應答的情況下，系統(tǒng)會跳轉到初始化階段對通信鏈路進行重置。在這一狀態(tài)下主要做復位、召喚鏈路、時鐘同步等工作。狀態(tài)圖如圖3所示。異常狀態(tài)是設備在鏈路應答超時或者遇到通信錯誤時需要設置的狀態(tài)，該狀態(tài)負責設備從錯誤中復位的工作。

圖3 初始化狀態(tài)圖

3.2 采集通信狀態(tài)轉換圖

采集通信態(tài)主要負責遙測遙信采集和命令的傳輸。遙測遙信的采集過程狀態(tài)圖如圖4所示。工作態(tài)由子狀態(tài)s21至s25構成。s21為起始狀態(tài)和穩(wěn)定態(tài)，其他狀態(tài)均為請求過程中的過渡狀態(tài)。過渡狀態(tài)中均有定時器負責超時后處理工作。采集主要負責規(guī)約中1級2級數據的召喚工作。

圖4 采集通信狀態(tài)圖

4 通信程序實現

4.1 總體框架

IEC103通信程序主要由主控端、SM狀態(tài)機模塊和接口消息處理模塊3個部分組成(圖5)。主控模塊主要負責系統(tǒng)上電自檢復位以及正常順序調度等工作。 SM模塊是規(guī)約的具體執(zhí)行模塊，按照之前討論的方式對各種通信的報文指令作出正確的判斷及響應。消息處理作為單獨一個作業(yè)任務，主要監(jiān)視通信串口發(fā)過來的信息，并將信息進行分類判斷后翻譯成SM能夠識別的事件和數據。

圖5 IEC103通信主體框架

4.2 SM框架實現

本文采用自定義框架的開發(fā)方式，同時借鑒了商用SM的成熟經驗。從最頂層開始狀態(tài)可設置為起始狀態(tài)和中間過渡狀態(tài)。兩種狀態(tài)的最大差別在于中間過渡狀態(tài)中要加入定時器超時處理。具體做法是在狀態(tài)State 類的onEnter（）和onExit（） 狀態(tài)出入函數中加入定時器啟停操作和狀態(tài)在本狀態(tài)的超時次數（Repetitions）的判斷，如果在本狀態(tài)中超時重復次數超過3次則需要向SM繼續(xù)發(fā)送一條重復大于3次的事件，狀態(tài)機轉而到異常處理狀態(tài)中。起始狀態(tài)下派生出設備初始化狀態(tài)s0和設備就緒工作態(tài)s21，中間過渡態(tài)包括了除了上面兩個狀態(tài)之外的其他狀態(tài)。

狀態(tài)機的核心是狀態(tài)轉移表的定義，在程序中可以定義為如下結構數組,其中第一列對應當前狀態(tài)，第二列對應事件，第三列對應轉移后狀態(tài)，第四列為槽函數，最后為函數的參數定義。這里第一行定義了在通信采集狀態(tài)下，遇到總召事件后要跳轉到總召狀態(tài)中，對應的處理函數為發(fā)送總召命令SendNegotiateDataCmd。該狀態(tài)轉移表為狀態(tài)機工作的核心部分，狀態(tài)機在每次遇到事件到達時都要首先查找這個轉移列表來確定下一步的操作。當業(yè)務變化時只需修改這里的狀態(tài)定義表即可，從而提高程序重用性。

5 結束語

本文先后討論了IEC103規(guī)約主要通信過程的實現以及從SM的角度去實現規(guī)約的主要要求。通信過程一般分為多個階段，每一階段對應著不同的狀態(tài)，因而有狀態(tài)改變過程。狀態(tài)機天然屬性很好地滿足了通信過程的這種特點，采用狀態(tài)機模型主要有以下優(yōu)點：

（1）面對非平衡傳輸模式傳輸的設備時，能夠很好地記錄下各個子站設備的當前工作狀態(tài)并按照實時狀態(tài)做出正確及時的響應，提高通信響應速度 。

（2）采用的狀態(tài)機框架同時也符合程序設計中的狀態(tài)模式，該模式不僅使程序更加結構化，避免大量分支語句帶來的混亂，而且大大提高了程序的擴展和維護的便利性。