船舶能量管理系統子站通信接口研究

楊 鵬 卜樂平 王黎明

海軍工程大學電氣工程學院，湖北武漢 430033

1 引 言

隨著全電力船舶的發展，船舶能量管理系統的應用逐漸成為未來發展的必然趨勢。電力系統運行狀態信息的獲取是船舶能量管理系統的基礎性問題，是制定能量調度方案的重要依據。船舶能量管理系統子站（以下簡稱“子站”）作為底層數據采集裝置，是上述信息的主要來源，為主站提供通用數據幀（電力系統正常運行時的狀態信息）和故障錄波數據幀（故障信息），同時還作為主站的“執行者”根據主站發送的命令幀輸出相應的數字量和模擬量控制信號。此外，子站還需根據主站發送的動態配置幀來對自身參數進行動態配置。主站根據子站上傳的信息對當前電力系統運行狀態進行監控，并對電力系統故障進行處理。

現有的船舶電力采集系統一般是采用上層以太網，下層CAN網的組網方式。但CAN網在遠距離數據傳輸時速率受限［1-2］，無法保證大容量數據幀傳輸的實時性。此外，傳統的數據集中處理方式也帶來了巨大的數據處理壓力問題。

針對上述問題，本文提出了一種基于分布式網絡結構的船舶電力系統運行狀態獲取方法，如圖1所示。系統的上層主干網為環形工業以太網，下層為子站與供配電系統的各個局域網，上下層之間采用交換機相連接。系統中的各種信息以以太網的方式在上下層之間流通，同時電力系統狀態信息將被保存到海量數據庫中，以供系統分析使用。子站對電力系統的各種信息進行預處理，再根據需要采用不同的方式上傳，從而減輕了主站的數據處理壓力，提高了系統整體性能。

2 需求分析

以太網是當前應用最普遍的局域網技術，具有通信速率高、信息量大、網絡管理功能完善等顯著優點［3］，適用于船舶有限網絡空間內的信息交互。以太網通信建立在TCP／IP協議的基礎上，TCP／IP協議的傳輸層提供了兩種服務：用戶數據包協議（UDP）和傳輸控制協議（TCP）。其中UDP是面向無連接的協議，其不與對方建立通信連接，而是直接將數據包發送過去，因此，UDP協議通信的實時性高、費用低、效率高［4］。使用UDP協議可以保證通信的實時性并降低網絡費用，但同時也降低了通信的可靠性。TCP為面向連接和高可靠性的協議。TCP協議通過三次握手在通信雙方之間建立一個可靠的鏈接，并在通信過程中使用序號和確認機制，利用超時重傳、擁塞控制與流控制等機制來確保所有發送的數據包都能到達目的地。因此TCP協議通信可靠性高，但TCP中用于保證可靠性傳輸的各種機制也降低了通信的實時性［5］。

針對船舶能量管理系統子站對數據幀實時性和可靠性的需求，大容量的通用數據幀可采用UDP協議傳輸以滿足其對實時性的需求。故障錄波數據幀作為分析電網故障的重要參考信息和動態配置幀、命令幀，一并采用TCP協議傳輸，以確保這些重要數據和命令能夠準確送達主站。考慮到船舶空間資源的有限性，子站采用嵌入式實現。采用ARM處理器作為子站的主控制器。由于ARM處理器存在資源受限的問題，并考慮到系統多任務處理的需求，通過使用輕量級TCP／IP協議棧LwIP和高實時性的操作系統COS-II，可以有效減少存儲空間的占用并提高代碼的運行效率。LwIP實現的重點是在保持TCP／IP協議主要功能的基礎上減少對ARM的占用，這使得LwIP很適合在低端嵌入式系統中使用［6］。

3 通信接口的硬件設計

子站的通信接口硬件結構如圖2所示。本系統采用Cortex-M3內核ARM處理器LM3S8962作為硬件平臺，LM3S8962的以太網控制器由一個完全集成的媒體訪問控制器 （MAC）和網絡物理（PHY）接口器件組成。無需增加外部的MAC芯片或PHY芯片，這使得本系統的以太網接口硬件設計大大簡化，只需添加簡單的外圍設備即可實現以太網通信功能。

4 通信接口的軟件設計

通信軟件總體設計采用客戶端／服務器模式，通過該模式可以充分利用兩端硬件環境的優勢，將任務合理分配到客戶端和服務器來實現，一方面能降低系統的通信開銷，另一方面可減輕服務器運行數據負荷，而且該模式還使系統易于擴展［7-8］，滿足船舶能量管理系統大容量數據發送和接收的需求。服務器和客戶端是一個相對的概念。在船舶能量管理系統中，子站在發送通用數據幀和故障錄波數據幀時是作為客戶端，而在接收配置幀和命令幀時是作為服務器。在μCOS-II平臺下完成上述功能只需分別建立任務作為客戶端和服務器完成相應的功能即可。

子站以太網通信接口整體設計結構如圖3所示。在LM3S8962上移植μCOS-II實時操作系統，針對片內的以太網控制器編寫驅動程序，并移植TCP／IP協議棧。完成μCOS-II和協議棧的移植后，由操作系統管理各任務，包括網絡通信程序和其它應用程序。子站的通信軟件設計主要包括協議棧的移植、驅動程序設計、數據幀結構的定義和嵌入式以太網通信程序設計。

4.1 協議棧的移植

協議棧的移植主要是操作系統模擬層的移植，包含以下兩個方面：與CPU或編譯器有關的文件移植和與底層操作系統相關的結構體和函數［9］。參照LwIP官方文檔sys_arch.txt可知，LwIP在設計時為了簡化協議棧移植，把所有與硬件、操作系統、編譯器等有關的部分全部獨立出來放在了／src／arch 目錄下。因此，LwIP 在 uC／OS-Ⅱ下的移植主要是根據不同硬件平臺修改這個目錄下的相關文件。

4.1.1 與CPU或編譯器有關的文件

在／src／arch／目錄下的文件中有一些與 CPU或編譯器相關的定義，如數據長度、字的高低位順序等。這些與移植μCOS-II時的定義應一致。

4.1.2 與底層操作系統相關的結構體和函數

主要包括信號量及相關函數、消息隊列及相關函數、超時處理函數以及創建新線程函數等。這些結構體和函數在文件 sys_arch.c和 sys_arch.h中實現。

1）線程間通信。LwIP需要使用信號量、消息隊列進行線程間同步和通信等操作。在移植COSII時已經實現了相關的操作，故只需適當的封裝和處理μCOS-II中的相關函數即可。

2）超時處理。LwIP中每一個有網絡連接作用的線程都具有超時屬性，即維護一個sys_timeouts鏈表。移植時需要編寫sys_arch_timeouts（void）函數，該函數返回線程當前的sys_timeouts結構體指針。

3）創建線程。LwIP創建線程實際上就是利用μCOS-II的系統函數創建了一個任務，因此sys_thread_new函數實現比較簡單。

4.2 網絡驅動程序設計

LwIP的網絡驅動有一定的模型，該模型位于目錄 ／src／neti／ethernetif.c 文件中，主要包括網卡初始化、數據包接收和數據包發送等函數。LM3S8962的以太網控制芯片完全集成在片內，因此編寫網絡驅動程序只需在此框架中完成與底層硬件相關的部分即可。

本系統的網絡驅動程序流程如圖4所示。首先由以太網初始化函數（InitNic）調用LwIP協議棧初始化函數（LwIPInit），同時建立接收線程并添加數據包接收函數（stellarisif_input），接收函數調用ethernet_input（）函數來處理接收數據包。在LwIPInit中，調用網絡接口初始化函數（stellarisif_init）來初始化與此網絡接口對應的結構體，同時向LwIP注冊發送函數（etharp_output）和鏈路層發送函數（low_level_output），并調用 low_level_init函數來完成以太網底層硬件驅動。

當網絡接口接收到一個數據包時，通過接收中斷向接收線程發送信號量，啟動接收線程處理接收數據包，若為ARP數據包，則調用ARP接收函數處理；若為IP數據包，則更新ARP緩沖表，將數據傳送到傳輸層，判斷是TCP還是UDP方式，再由應用層對數據包進行處理。

若從網絡接口發送一個數據包，便調用etharp＿output函數從 ARP緩沖表中查找目標MAC地址，并添加以太網幀頭部，調用鏈路層發送函數通過底層發送函數 （low＿level＿transmit）來完成實際的發送。若無法找到與IP匹配的MAC地址，則發送ARP請求數據包來獲取MAC地址。

4.3 子站通信程序的設計

4.3.1 多任務模式下的通信程序設計

LwIP協議棧提供3種形式的API函數：BSD API、RAW API和 LwIP API［10］。BSD API要求在協議棧中將要發送的數據從應用程序拷貝到內部緩存，效率低且消耗資源多；RAW API要求應用程序駐留在TCP／IP進程中，這導致通信與應用程序不能同時進行，降低了通信性能；LwIP API將負責通信的部分駐留在TCP／IP進程中，負責大量運算的部分作為一個單獨的進程，通過進程間通信機制實現應用進程與協議棧進程之間的通信［11］。由于子站既要對AD采集的大量數據進行處理，又要立即響應接收數據，故采用LwIP API作為應用程序接口，將應用程序分成了兩部分，一部分處理通信，一部分處理數據。負責通信的部分被劃分為3個任務，即一個TCP服務器任務，負責接收主站的控制指令；一個TCP客戶端任務，負責故障錄播幀的發送；一個UDP客戶端任務，負責通用數據幀的傳遞。負責處理數據的部分被劃分為兩個任務，以分別對主站指令和AD采樣數據進行處理。

4.3.2 子站通信程序工作流程

子站通信程序工作流程如圖5所示。AD數據采集模塊在定時器的控制下周期性地對被測電力設備的電壓、電流值進行采樣，然后通過郵箱將采樣數據傳遞給數據處理模塊1，通過對數據的解析，判斷電力設備是否出現故障，如果出現故障，則立即啟動故障錄播模式，詳細記錄故障點的原始數據并打包成故障錄播幀。由于這些數據是分析和解決故障的重要判據，必須保證準確無誤地傳遞給主站，因此通過TCP方式傳輸。若是正常數據，便將數據封裝成通用數據幀，通過UDP方式傳遞給主站。子站采用TCP方式接收來自主站的控制指令和動態配置幀。TCP一直監聽設定的端口，有數據到來時對數據進行判斷，如果數據有效，便通過郵箱發送給數據處理模塊2，經解析后執行主站的指令。

5 以太網通信測試

5.1 基本通信測試

為了驗證本系統設計的可行性與正確性，首先在實驗室環境下搭建簡單的嵌入式以太網通信系統，用來測試在多任務模式下TCP和UDP通信信道的運行狀況。將子站設置成回環通信調試模式，即回發接收到的主站命令，在調試助手中建立TCP客戶端以向子站發送命令，可以看到，在接收窗口中可以看到同樣的命令，這說明子站收到了命令，并將此命令回發給主站。同時，讓子站通過TCP和UDP兩種方式向主站發送模擬數據，在調試助手中分別建立TCP、UDP服務器以接收子站發送的數據。如圖6所示，兩種方式數據上傳正常。

5.2 全系統測試

主站的監控軟件由Qt編寫，能以圖形和文字兩種方式實時顯示電力系統被測節點的運行狀態，單擊開關按鈕可以改變子站開關的狀態，并將開關變化后的狀態上傳至主控界面，監控軟件界面如圖7所示。通過實驗驗證，在子站中采用TCP和UDP方式通信取得了預想的結果，點擊界面上的不同菜單，可分別將各被測節點的電壓、電流、功率和開關狀態顯示到界面上，并且可以查看各數據的歷史曲線。

6 結 語

針對船舶能量管理系統中高實時性與低網絡開銷的大容量通用數據幀傳輸和高可靠性與完整性的故障錄播幀、配置幀以及命令幀的傳輸，本文采用基于LwIP協議棧和μCOS-II實時操作系統相結合的嵌入式以太網通信接口設計方法，實現了分別用TCP和UDP對不同性質數據幀的傳輸，并可通過主站監控界面對子站進行遠程監控。本系統采用模塊化思想優化軟件體系，利用多任務方式處理各個模塊，增加了模塊內部的內聚性，降低了模塊之間的耦合性，提高了系統的靈活性。實驗證明，設計方案滿足船舶能量管理系統中對通信可靠性和實時性的需求，實現了電力系統狀態信息獲取與數據幀傳輸的網絡化。

［1］趙浩，李聲晉，蘆剛.基于CAN總線和以太網的遠程監控系統設計［J］.測控技術，2006，25（10）：53-56.

［2］甘永梅，李慶豐，劉曉娟，等.現場總線技術及其應用［M］.北京：機械工業出版社，2005.

［3］ZOU J N，CHEN J，LIN R J.Implementation of access controller for Ethernet passive optical network ［J］.Journal of Shanghai University，2006，10（5）：425-430.

［4］鄭巨明，張和生，賈利民，等.基于 μC／OS-Ⅱ和 Lwip的嵌入式以太網接口設計 ［J］.計算機測量與控制，2009，17（11）：2238-2242.

［5］SCAGLIA S.嵌入式Internet TCP／IP基礎、 實行及應用［M］.北京：北京航空航天大學出版社，2008.

［6］邱書波，陳偉.基于ARM的輕量級TCP／IP協議棧的研究及移植［J］.計算機應用與軟，2009，26（8）：90-92.

［7］方濤.基于B／S與C／S混合模式下的電廠燃料管理系統的研究［D］.保定：華北電力大學，2005.

［8］李先軍，劉波，余丹，等.一種基于AJAX技術的B／S與C／S 混合構架模式［J］.計算機應用，2009，29（4）：1135-1138.

［9］孔棟，鄭建宏.嵌入式TCPIP協議棧LWIP在ARM平臺上的移植與應用［J］.通信技術，2008.41（6）：38-40.

［10］焦海波，劉健康.嵌入式系統網絡設計［M］.北京：北京航空航天大學出版社，2008.

［11］高強.嵌入式WEB發布平臺在變電站自動化系統中的應用研究與實現［D］.成都：西南交通大學，2006.