嵌入式軟件自動化開發模式的研究

唐政清

(珠海格力電器股份有限公司,廣東 珠海 519000)

0 引言

在萬物互聯的時代,物聯網技術高速發展。隨著越來越多的物件產生控制需求,嵌入式軟件呈現指數增長態勢。傳統的基于生命周期的軟件開發模式面臨日益嚴峻的挑戰。軟件自動化開發模式成為研究的熱點。在此背景下,研究嵌入式控制系統軟件開發模式,探尋1種高效、快捷的開發方式具有重要意義。

軟件自動化開發模式的關鍵技術為自動代碼生成技術。國內外相關研究多數在計算機領域開展,而嵌入式軟件也有部分研究。嵌入式軟件自動代碼生成技術的研究主要包括:使用Matlab平臺的基于模型自動代碼生成工具的研究[1-3];使用高安全性應用開發環境(security-critical application develoment environment,SCADE)平臺軟件,將SCADE模型轉換為軟件代碼的研究[4-6]。這2種方案均高度依賴國外平臺軟件。本文探索自主平臺軟件實現代碼生成的方案,對組合式空調嵌入式控制系統軟件進行基于模板的代碼生成技術研究,以實現訂單需求到訂單軟件的自動生成,從而解決控制系統軟件重復開發的問題。

組合式空調是1種提供多種功能段組合的暖通設備。功能段多達24個,包括進風段、排風段、混合段等,可根據用戶需求進行功能組合。組合式空調支持客戶需求定制。其系統結構簡單、節省空間、安裝維護方便,故廣泛應用于工業性場所、商用民用大中型公共建筑場所,包括電子儀表廠、精密機械制造廠、紡織廠、化工廠、展覽中心、體育館、寫字樓、公共交通樞紐建筑等。組合式空調機組中的每個工程都會根據實際需求靈活選擇若干個功能段。同一工程中不同位置的空調的功能段也會不同。組合式空調機組控制系統需要根據每個工程的實際情況進行定制非標開發。考慮到控制系統非標訂單開發量大、從接單到交貨的時間短,通常可采用可編程邏輯控制器(programmable logic controller,PLC)以及直接數字控制器(direct digital controller,DDC)等進行開發,利用其內置的采樣、比例微分積分等控制模塊開發相應的功能段控制軟件代碼[7]。即使如此,由于每個組合式空調訂單的控制軟件均需要進行人工編程,必須投入大量的人力才能滿足訂單的開發需求,開發模式亟需革新。

1 軟件開發模式的探索

在需求特點上,組合式空調控制系統的基本功能和常規空調類似,有供冷、供熱、通風、自動4種運行模式。但是,組合式空調可能包含24個功能段中的若干功能段,且每個功能段可能存在若干數量的負載和傳感器。負載可能包含風機、水閥、風閥、電加熱、加濕器、聯動外機空調、過濾器和其他開關型負載。每種負載也可能存在不同類型,如:風機可能是送風機、排風機或回風機;接口可能是定速風機、變頻風機或者多檔位風機。傳感器除了溫度、濕度、風壓、頻率等類型不同外,接口也可能存在負溫度系數電阻、0～10 V、4～20 mA、開關量檢測等多種形式。上述接口品類繁多,覆蓋了主流的工業標準接口[8]。負載和傳感器的數量、類型、接口均隨具體工程需求的變化而變化,存在海量的組合情況。

1.1 生命周期軟件開發模式

軟件的常規開發模式是生命周期軟件開發模式。例如,瀑布模型就是非常有效的基礎軟件開發管理模式。每個工程組合式空調的需求存在差異。但是對于具體的工程,其組合式空調控制需求是比較明確和清晰的,采用基礎瀑布模型軟件開發模式就能滿足項目需要。為了加快訂單產品的推出,通常采用DDC進行控制軟件開發。DDC可以配置負載和傳感器的類型,可以集成采樣模塊、比例微分積分過程控制模塊等,還可以通過軟件開發編程,較快完成產品開發。其開發過程為:針對工程訂單需求,項目經理進行需求分析,編寫功能書;開發人員進行DDC軟件開發編程;測試人員進行軟件測試,并在測試合格后完成訂單產品的開發。

但是,訂單需求多樣化的特性決定了負載和傳感器之間互相組合的情況存在非常多的不確定性,降低了DDC軟件的兼容性和代碼的可重用性。每個不同的訂單需求都要進行1次軟件開發,并重復1次瀑布模型開發過程。這使得開發的資源耗費隨訂單數量的增加而倍增。

1.2 自動化開發模式的探索

針對組合式空調控制系統訂單需求的特點,本文探索軟件自動化開發模式,以解決訂單軟件開發海量耗費問題。自動化開發的思路是開發1個平臺軟件作為代碼生成器,對訂單需求進行分析,從而提煉出訂單特征信息并輸出到平臺軟件中。平臺軟件自動生成該訂單對應的軟件代碼。

目前,自動代碼生成技術主要有基于模型、基于模板、基于對象關系映射、基于文檔注釋和基于動態代理這5種。其中,基于模型和基于模板為主流的代碼生成技術[9]。基于模型的代碼生成方法是先對業務邏輯建立模型,再通過軟件工具將模型轉換為代碼。基于模板的代碼生成方法是將業務邏輯需求設計成模板代碼文件,通過軟件工具將變化的個性需求作為元數據轉換到模板文件中。組合式空調是1個非線性系統,具有輸入變量多、相互耦合強的特點。組合式空調控制系統需求特點適合采用基于模板的自動代碼生成技術,把軟件需求分為相對固定部分和隨外部輸入變化的個性化部分。相對固定部分開發作為平臺軟件的模板。個性化部分通過平臺軟件自動生成所需要的軟件代碼。

2 軟件自動代碼生成

軟件自動代碼生成過程為:首先,進行需求劃分和轉換,得到共性需求和個性需求;然后,設計分層結構框架和代碼生成方案;最后,實現代碼自動生成。

2.1 需求劃分和轉換

自動代碼生成的前提是需求的劃分和轉換,即通過需求迭代進行劃分和轉換。需求迭代是分別對不同的訂單需求進行需求分析,并迭代到軟件模板功能書中,同時生成和該訂單需求對應的控制點表,從而將需求劃分和轉換為共性需求軟件模板功能書和個性需求控制點表。控制點表定義了負載和傳感器的數量、類型和接口等個性化信息。需求迭代過程如圖1所示。

圖1 需求迭代過程示意圖

2.2 分層結構框架

根據嵌入式軟件及組合式空調特點,設計分成6層軟件結構框架。軟件結構框架由下至上依次為硬件抽象層、微內核層、設備驅動層、控制層、邏輯層和交互層。軟件結構框架的各層具體內容如下。

①硬件抽象層定義了基于嵌入式硬件的配置。

②微內核層是基于嵌入式系統的實時內核,可以作為1個小型嵌入式操作系統,負責嵌入式內核管理、調控,以及對操作系統任務和進程的調度。

③設備驅動層負責提供輸入/輸出(input/out,I/O)、文件系統、網絡等設備的驅動程序。

④控制層包括負載控制模塊和傳感器控制模塊。負載控制模塊執行對特定負載的輸出動作。傳感器控制模塊執行特定傳感器的采樣和檢測。

⑤邏輯層包括空調運行模式模塊和功能段模塊。空調運行模式模塊執行供冷、供熱、通風、自動這4種基本運行模式邏輯。功能段模塊執行組合式空調特定功能段邏輯。

⑥交互層包括人機交互模塊、遠程交互模塊和控制點表交互模塊。人機交互模塊接收人員操作指令,并顯示、反饋設備相關狀態。遠程交互模塊接收遠端聯網設備的控制指令,并反饋設備相關狀態到遠端聯網設備。控制點表交互模塊負責處理個性化需求。

2.3 代碼自動生成

代碼自動生成方案是根據設計的分層結構框架,定義模板和元數據(即輸入數據模型),開發平臺軟件,并將元數據轉換成模板能識別匹配的程序代碼。

在模板方面,通過需求迭代轉換和分層結構框架,將相對固定部分需求模板功能書分解到交互層、邏輯層和控制層中,并設計成模板文件。設備驅動層、微內核層和硬件抽象層是嵌入式軟件和硬件設備相關部分,可以編寫底層驅動程序,封裝成驅動函數庫[10],并直接設計成模板文件。代碼文件結構如圖2所示。

圖2 代碼文件結構示意圖

元數據是描述其他數據的數據。其對數據通用屬性進行抽象和標準化,具有唯一的身份元素信息[11]。元數據在代碼自動生成中用于表述代碼生成的內容,由個性化需求抽象而成。控制點表包含負載和傳感器的數量、類型和接口等信息,代表了個性化需求。項目中控制點表的每個負載和傳感器都看作1個基本元素。數字化和數據接口標準化并對象化后,可作為元數據。以傳感器為例,其對象化后可以作為擴展標記語言(extensible markup language,XML)數據。XML數據示例如下。

...

平臺軟件作為代碼生成器,包含定義好的模板文件和元數據轉換功能。平臺軟件將元數據轉換成交互層控制點表模塊,將元數據插入到模板中,生成對應的代碼。例如,對于傳感器元數據,平臺軟件從元數據庫XML文件讀入傳感器數據,通過預定義的結構體將其生成控制點表模塊代碼文件。預定義的結構體是元數據的1種代碼模板,是元數據庫XML文件中傳感器數據的代碼表現形式,通過平臺軟件實例后即生成傳感器數據的代碼。

//預定義結構體,可根據實際功能預定義

typedef struct

{

unsigned char *Name[2];

unsigned char Gateway;

unsigned char Type;

signed int Minimum;

signed int Maximum;

signed int SetValue;

signed int Value;

}SenseUnit;

3 測試驗證及應用

測試驗證主要分為模板驗證、元數據驗證和模擬使用驗證。模板驗證要求保證完備性和邏輯性,確認是否包含模板功能書的全部內容、是否滿足需求的邏輯功能。元數據驗證要求不同的元數據能正確轉換,以及元數據插入到模板的邏輯對應關系正確。元數據驗證是測試驗證的重點,至少應包括以下內容。

①各類負載對象驗證測試。負載包括風機、水閥、風閥、電加熱、加濕器、聯動外機空調、過濾器和其他開關型負載。每個負載對象由不同的負載類型、不同的負載接口驗證測試。不同的負載組合、負載數量需分別驗證測試。

②各類傳感器對象驗證測試。傳感器包括溫度、濕度、風壓、頻率等。每個傳感器對象的各種類型、接口需分別驗證測試。不同的傳感器組合、傳感器數量需分別驗證測試。

③負載對象和傳感器各種組合測試驗證。

本文根據歷史訂單的需求進行模擬使用驗證,以驗證需求迭代、需求分解和代碼生成全過程是否存在漏洞。驗證完成后,就可以進行工程應用。接到新的組合式空調工程訂單后,開發人員直接從訂單需求提取出控制點表,以抽象化后數據作為元數據,并通過平臺軟件生成該訂單的軟件代碼。

工程應用流程如圖3所示。

圖3 工程應用流程圖

本文以某縣發展中心和某市黨校新區工程項目訂單為例,分析工程應用過程。資源耗費對比如表1所示。

表1 資源耗費對比

工程應用結果表明:本文研究的嵌入式軟件自動開發模式能夠快速自動生成訂單軟件代碼,大幅降低代碼開發耗費;在平臺軟件已經驗證充分的前提下,應用測試僅需復核控制點表模塊的接口部分,可有效減少代碼測試資源的耗費。

4 結論

本文對組合式空調儀控系統軟件自動化開發模式進行研究和探索。根據組合式空調控制需求特點,采用基于模板的自動代碼生成技術,以自主平臺軟件作為代碼生成器,設計分層結構框架和代碼生成方案。該代碼生成方案通過平臺軟件將共性需求模板功能書設計成模板代碼,將個性需求轉換成交互層控制點表模塊代碼,以生成項目最終軟件代碼。該研究實現了訂單需求到訂單軟件代碼的自動生成,并將測試驗證和應用到工程訂單中,有效解決了組合式空調儀控系統軟件的重復開發耗費問題。

基于組合式空調的控制軟件自動化開發模式的實踐,有效解決了嵌入式軟件的重復開發問題。本文研究了中小項目自主開發平臺軟件實現自動代碼生成及工程應用,為國產自主儀控系統軟件自動化開發提供了借鑒。