張義彬 詹 杰*
( 湖南科技大學物理與電子科學學院,湖南 湘潭411201)
開發用于高空風能發電的控制系統軟件是一項復雜的任務, 特別是如果風箏由機載舵吊艙控制器控制的話。 除了風箏的操縱吊艙之外,整個系統的自動化還包括地面站上的多個傳感器和執行器,用于操控繩索和執行啟動與恢復,一個數據記錄系統以及用戶界面。 為此, 我們設計了控制風箏發電機系統的軟件設計思路。
控制吊艙為小批量生產的, 它嵌入了兩個專用的優化控制板: 飛行控制計算機板和用于風箏執行器的運動控制板。 驅動執行器的能量以及到機載部件的通信數據必須通過牽引繩由船向風箏傳遞。為與電纜導線的固有電阻相適應,使用了120 伏的非標準電動機供電電壓。 因此, 考慮到成本和重量兩方面因素,將電源管理和數據調制解調器電路集成到傳感器數據采集和控制計算機平臺中非常有益。 通過平衡硬件和軟件的魯棒性需求, 嵌入式控制器解決方案需遞歸地開發。 為了提高電子電路的穩定性, 所有的信號處理被限制在所需的帶寬上。 適用于在48 MHz 時鐘頻率下工作的微處理器。結果,只有那些需要自動放風箏的算法在控制艙中進行處理,包括導航、數據融合和運動控制算法。 為了降低生產成本并簡化維修技師的要求, 飛行計算機板與運動控制板分離, 以適應不同風箏尺寸的平臺策略。其結果是,僅需要改變功率分量以適應風箏尺寸。使用CAN總線將現在和以后的吊艙組件連接在一起,解決軟件體系結構的這個挑戰。 CAN 總線能夠進行確定性定時和自仲裁,在屬性上確保了高優先級消息的傳輸。 因此,在系統的未來擴展中,沒有先前驗證的定時或運動控制屬性丟失。 當將額外的傳感器或數據記錄器結合到生產等級系統中用于研究和開發時,這是有價值的。為了最大限度地利用這些屬性,我們選擇了pod 內通信數據的可變抽象,如圖1 所示。

圖1 POD 變量內部數據表示原理( UML 靜態結構)
變量由PodVariable 類表示, 并且可以附加到CAN 傳輸層,該傳輸層能夠立即將消息排入微控制器的傳出CAN 緩存中。因此,只要總線可用,就會在CAN 總線上廣播變量。易用的獲取器和設置器實現了不同數據的表示,并且通過中央消息id 文件完成對CAN 傳輸層的注冊。 這允許在編譯時檢測和消除死連接,并且軟件程序員團隊成員可以共享中心電報文檔。
因為傳感器的信息可能是當前活動的,也可能過時,操作控制算法的魯棒性關鍵取決于這些信息特征。 因此, 變量的一個重要屬性是TTL 特征,它表示變量的生存時間。
計算如下:在每個SET( )變量的訪問中,生存時間被重置為默認值。 每個控制循環調用通過一個計數遞減值。 當TTL 值耗盡時,意味著變量過時,它具有的意義是,算法可以采取相應的行動針對變量是否過時,例如切換到回收方案。
計算機在內部循環啟動的同時在CAN 總線上放置一個循環啟動報文。這允許所有總線通信參與者同步其內部控制回路。不需要進一步的機制來保證實時操作和確定性的CAN 總線訪問。
模塊集成模式如下。 模塊使用輸入向量pod 變量,operation( )調用和輸出變量的向量。 輸入和輸出變量通過引用傳遞。這允許統一的模塊文檔并簡化軟件單元測試[6,12]的開發,因為將調度實現與任務實現分離。 按照這個規范,靜態測試[5,11]以及大量運行時測試可以在臺式計算機上執行, 而不是在目標系統上執行, 這加快了開發的速度。 目標系統中的定時驗證可以通過使用消息嗅探器直接在CAN 總線上進行。
控制算法的配置參數由相同的變量抽象表示, 并且從中央數據處理計算機上傳到低帶寬信道上,并作為低優先級消息在CAN 總線上轉發。
利用這些技術,嵌入式軟件組件變得適應性強,并可得到輕松的質量保證。
發射和回收處理的系統由拖曳絞車、 可傾斜的伸縮桅桿和附加絞車組成。 這個額外的絞盤控制著一根線, 該線負責在著陸過程中引導風箏,并在風箏放走之前對風箏進行收帆處理。
整個裝置由工業PLC 控制, 以滿足ISO 13849 的功能安全要求。 根據指導方針, 即使裝置與飛控計算機通信或中央數據的采集中斷,也必須保持功能特性。 因此,可以直接在模塊級別上處理與安全相關的屬性,以盡可能擴展。 安全關鍵模塊越小,模塊之間的耦合越小,構建安全案例所需的工作就越少,并且根據IEC 61508 記錄了所需屬性的驗證。
因此,組織PLC 軟件的軟件模型被選擇為中央有限狀態自動機,其特性易于文檔化和驗證。
圖2 中概述了子模塊組織的原理。 每個子模塊都知道中央自動機狀態,并且必須自組織它的內部狀態轉換。 例如當中央自動機從飛行狀態切換到操縱狀態時,負責海浪運動補償的模塊必須正確地管理模塊內部的液壓絞車參考信號。 與單片強耦合模型相比,這更易于驗證。

圖2 由中央自動機組織的PLC 軟件模塊
此外,模塊可以在組件測試床上投入運行,從而加速軟件開發。 當這些模塊連接到運行中的風箏推進系統中的中央控制自動機上時,先前驗證過的特性不會受到影響。
風箏推進系統的中央計算機利用工業PC 機接收、記錄、處理和轉發來自每個系統部件的數據。 選擇了基于PC 的硬件,因為它可以輕松記錄所有傳感器數據軌道,控制算法的輸出值和輔助數據,如算法參數和用戶輸入。 日志記錄每天產生大約三千兆字節的未壓縮數據,這些數據被壓縮存儲在硬盤上。 由于數據采集和處理主循環必須與飛控計算機的控制周期同步,所以Linux 操作系統安裝了一個實時擴展功能。 其優點包括Linux高分辨率計時器和快速響應時間,但代價是處理速度會顯著降低。
由于牽引繩通信的調制解調器被限制在有限的帶寬內,因此與飛控計算機交換的通信分組被分為兩個部分:一個部分的特征是可變數據,稱為等時數據。 在多路復用時隙中傳輸較少更新的變量。 另一部分包括面向信道的排隊消息傳輸。 實現高優先級和標準優先級隊列,為用戶命令路由和安全關鍵消息提供高優先級隊列,而標準隊列用于更新配置數據和從飛控計算機傳輸調試消息。
可以通過TCP 連接將多個圖形用戶接口連接到中央控制計算機。 在船橋上連續使用一個GUI 用于系統的用戶操作,另外一些GUI 可用于服務以及實驗目的。 這一特征在研究過程中具有特殊的重要價值。 開展飛行試驗, 需要從船舶艏樓區域進行嚴格監督。 因此,必須實現事件模型,它允許以安全的方式處理多個并發的用戶交互。 圖3 給出了解決方案的概述。
每個GUI 向中央控制計算機提供事件輸入, 這些事件輸入在內部事件隊列中排隊,并在內部自動化控制中觸發動作。 控制自動機生成事件, 這些事件被傳送到飛控計算機。 這臺計算機上運行的自動化程序通過更新同步變量來回傳它們的狀態,以便控制自動機根據需要采取行動。 發射與回收系統的PLC 由同一個系統范式連接,它接收狀態改變請求事件,并將中央自動機的實際狀態發送回。 為了減少實現錯誤,為PLC 和中央控制計算機開發了基于XML 描述文件的自動代碼生成工具。
將中央控制納入運作的一個核心問題是選擇模塊組織模式。 如果組件之間的耦合較低,則軟件更易于開發、測試和維護。因此,在用于新設計的復雜控制系統中, 通常選擇使用通信中間件。但是,對于整個系統來說,為了滿足交付期限問題,放棄某些關鍵模塊的測試覆蓋率是不可接受的。 因此, 現代技術已經被合并到遺留變量抽象中, 其結果在圖4 中描述。 除了顯著降低開發復雜性之外,變量實現的單元測試比通信中間件的測試和維護工作更少。

圖3 事件傳播模型

圖4 變量抽象和XML 驅動的工廠模式
變量實現的特點是封裝了三種可能的數據類型:整數( 對于狀態自動機很重要)、浮點和文本字符串。 整數和浮點類型可以直接附加到通信對象等時段, 而字符串僅限于面向通道的段。變量還包括獲取變量的接口信息,全文描述,物理單元信息和時間實時設定值。 變量配置由XML 描述文件維護,運行時對象由工廠類實例化。 這使得配置管理更容易。 對變量的訪問由快速名稱服務完成,其數據庫( 即散列表)在對象生成過程期間建立。如果名稱請求失敗,則返回對虛擬對象的引用。這減少了模塊之間的耦合,因此,當應用經常變化時,增加了實驗軟件的穩定性。 模塊實現遵循與飛控計算機軟件相同的規范。 在初始化模塊時,通過名稱服務建立到變量的連接,在模塊操作時調用循環operate()方式。
在本文中,詳細介紹了控制系統組件,以及所遇到的挑戰,并解釋了如何通過軟件工程技術解決這些問題。 本文為高空風能的利用及風箏發電機控制系統的設計提供了相關基礎。