嵌入式軟件自動(dòng)化開(kāi)發(fā)模式的研究

唐政清

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

0 引言

在萬(wàn)物互聯(lián)的時(shí)代,物聯(lián)網(wǎng)技術(shù)高速發(fā)展。隨著越來(lái)越多的物件產(chǎn)生控制需求,嵌入式軟件呈現(xiàn)指數(shù)增長(zhǎng)態(tài)勢(shì)。傳統(tǒng)的基于生命周期的軟件開(kāi)發(fā)模式面臨日益嚴(yán)峻的挑戰(zhàn)。軟件自動(dòng)化開(kāi)發(fā)模式成為研究的熱點(diǎn)。在此背景下,研究嵌入式控制系統(tǒng)軟件開(kāi)發(fā)模式,探尋1種高效、快捷的開(kāi)發(fā)方式具有重要意義。

軟件自動(dòng)化開(kāi)發(fā)模式的關(guān)鍵技術(shù)為自動(dòng)代碼生成技術(shù)。國(guó)內(nèi)外相關(guān)研究多數(shù)在計(jì)算機(jī)領(lǐng)域開(kāi)展,而嵌入式軟件也有部分研究。嵌入式軟件自動(dòng)代碼生成技術(shù)的研究主要包括:使用Matlab平臺(tái)的基于模型自動(dòng)代碼生成工具的研究[1-3];使用高安全性應(yīng)用開(kāi)發(fā)環(huán)境(security-critical application develoment environment,SCADE)平臺(tái)軟件,將SCADE模型轉(zhuǎn)換為軟件代碼的研究[4-6]。這2種方案均高度依賴國(guó)外平臺(tái)軟件。本文探索自主平臺(tái)軟件實(shí)現(xiàn)代碼生成的方案,對(duì)組合式空調(diào)嵌入式控制系統(tǒng)軟件進(jìn)行基于模板的代碼生成技術(shù)研究,以實(shí)現(xiàn)訂單需求到訂單軟件的自動(dòng)生成,從而解決控制系統(tǒng)軟件重復(fù)開(kāi)發(fā)的問(wèn)題。

組合式空調(diào)是1種提供多種功能段組合的暖通設(shè)備。功能段多達(dá)24個(gè),包括進(jìn)風(fēng)段、排風(fēng)段、混合段等,可根據(jù)用戶需求進(jìn)行功能組合。組合式空調(diào)支持客戶需求定制。其系統(tǒng)結(jié)構(gòu)簡(jiǎn)單、節(jié)省空間、安裝維護(hù)方便,故廣泛應(yīng)用于工業(yè)性場(chǎng)所、商用民用大中型公共建筑場(chǎng)所,包括電子儀表廠、精密機(jī)械制造廠、紡織廠、化工廠、展覽中心、體育館、寫(xiě)字樓、公共交通樞紐建筑等。組合式空調(diào)機(jī)組中的每個(gè)工程都會(huì)根據(jù)實(shí)際需求靈活選擇若干個(gè)功能段。同一工程中不同位置的空調(diào)的功能段也會(huì)不同。組合式空調(diào)機(jī)組控制系統(tǒng)需要根據(jù)每個(gè)工程的實(shí)際情況進(jìn)行定制非標(biāo)開(kāi)發(fā)?？紤]到控制系統(tǒng)非標(biāo)訂單開(kāi)發(fā)量大、從接單到交貨的時(shí)間短,通?？刹捎每删幊踢壿嬁刂破?programmable logic controller,PLC)以及直接數(shù)字控制器(direct digital controller,DDC)等進(jìn)行開(kāi)發(fā),利用其內(nèi)置的采樣、比例微分積分等控制模塊開(kāi)發(fā)相應(yīng)的功能段控制軟件代碼[7]。即使如此,由于每個(gè)組合式空調(diào)訂單的控制軟件均需要進(jìn)行人工編程,必須投入大量的人力才能滿足訂單的開(kāi)發(fā)需求,開(kāi)發(fā)模式亟需革新。

1 軟件開(kāi)發(fā)模式的探索

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

1.1 生命周期軟件開(kāi)發(fā)模式

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

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

1.2 自動(dòng)化開(kāi)發(fā)模式的探索

針對(duì)組合式空調(diào)控制系統(tǒng)訂單需求的特點(diǎn),本文探索軟件自動(dòng)化開(kāi)發(fā)模式,以解決訂單軟件開(kāi)發(fā)海量耗費(fèi)問(wèn)題。自動(dòng)化開(kāi)發(fā)的思路是開(kāi)發(fā)1個(gè)平臺(tái)軟件作為代碼生成器,對(duì)訂單需求進(jìn)行分析,從而提煉出訂單特征信息并輸出到平臺(tái)軟件中。平臺(tái)軟件自動(dòng)生成該訂單對(duì)應(yīng)的軟件代碼。

目前,自動(dòng)代碼生成技術(shù)主要有基于模型、基于模板、基于對(duì)象關(guān)系映射、基于文檔注釋和基于動(dòng)態(tài)代理這5種。其中,基于模型和基于模板為主流的代碼生成技術(shù)[9]?；谀Ｐ偷拇a生成方法是先對(duì)業(yè)務(wù)邏輯建立模型,再通過(guò)軟件工具將模型轉(zhuǎn)換為代碼?；谀０宓拇a生成方法是將業(yè)務(wù)邏輯需求設(shè)計(jì)成模板代碼文件,通過(guò)軟件工具將變化的個(gè)性需求作為元數(shù)據(jù)轉(zhuǎn)換到模板文件中。組合式空調(diào)是1個(gè)非線性系統(tǒng),具有輸入變量多、相互耦合強(qiáng)的特點(diǎn)。組合式空調(diào)控制系統(tǒng)需求特點(diǎn)適合采用基于模板的自動(dòng)代碼生成技術(shù),把軟件需求分為相對(duì)固定部分和隨外部輸入變化的個(gè)性化部分。相對(duì)固定部分開(kāi)發(fā)作為平臺(tái)軟件的模板。個(gè)性化部分通過(guò)平臺(tái)軟件自動(dòng)生成所需要的軟件代碼。

2 軟件自動(dòng)代碼生成

軟件自動(dòng)代碼生成過(guò)程為:首先,進(jìn)行需求劃分和轉(zhuǎn)換,得到共性需求和個(gè)性需求;然后,設(shè)計(jì)分層結(jié)構(gòu)框架和代碼生成方案;最后,實(shí)現(xiàn)代碼自動(dòng)生成。

2.1 需求劃分和轉(zhuǎn)換

自動(dòng)代碼生成的前提是需求的劃分和轉(zhuǎn)換,即通過(guò)需求迭代進(jìn)行劃分和轉(zhuǎn)換。需求迭代是分別對(duì)不同的訂單需求進(jìn)行需求分析,并迭代到軟件模板功能書(shū)中,同時(shí)生成和該訂單需求對(duì)應(yīng)的控制點(diǎn)表,從而將需求劃分和轉(zhuǎn)換為共性需求軟件模板功能書(shū)和個(gè)性需求控制點(diǎn)表?？刂泣c(diǎn)表定義了負(fù)載和傳感器的數(shù)量、類型和接口等個(gè)性化信息。需求迭代過(guò)程如圖1所示。

圖1 需求迭代過(guò)程示意圖

2.2 分層結(jié)構(gòu)框架

根據(jù)嵌入式軟件及組合式空調(diào)特點(diǎn),設(shè)計(jì)分成6層軟件結(jié)構(gòu)框架。軟件結(jié)構(gòu)框架由下至上依次為硬件抽象層、微內(nèi)核層、設(shè)備驅(qū)動(dòng)層、控制層、邏輯層和交互層。軟件結(jié)構(gòu)框架的各層具體內(nèi)容如下。

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

②微內(nèi)核層是基于嵌入式系統(tǒng)的實(shí)時(shí)內(nèi)核,可以作為1個(gè)小型嵌入式操作系統(tǒng),負(fù)責(zé)嵌入式內(nèi)核管理、調(diào)控,以及對(duì)操作系統(tǒng)任務(wù)和進(jìn)程的調(diào)度。

③設(shè)備驅(qū)動(dòng)層負(fù)責(zé)提供輸入/輸出(input/out,I/O)、文件系統(tǒng)、網(wǎng)絡(luò)等設(shè)備的驅(qū)動(dòng)程序。

④控制層包括負(fù)載控制模塊和傳感器控制模塊。負(fù)載控制模塊執(zhí)行對(duì)特定負(fù)載的輸出動(dòng)作。傳感器控制模塊執(zhí)行特定傳感器的采樣和檢測(cè)。

⑤邏輯層包括空調(diào)運(yùn)行模式模塊和功能段模塊?？照{(diào)運(yùn)行模式模塊執(zhí)行供冷、供熱、通風(fēng)、自動(dòng)這4種基本運(yùn)行模式邏輯。功能段模塊執(zhí)行組合式空調(diào)特定功能段邏輯。

⑥交互層包括人機(jī)交互模塊、遠(yuǎn)程交互模塊和控制點(diǎn)表交互模塊。人機(jī)交互模塊接收人員操作指令,并顯示、反饋設(shè)備相關(guān)狀態(tài)。遠(yuǎn)程交互模塊接收遠(yuǎn)端聯(lián)網(wǎng)設(shè)備的控制指令,并反饋設(shè)備相關(guān)狀態(tài)到遠(yuǎn)端聯(lián)網(wǎng)設(shè)備。控制點(diǎn)表交互模塊負(fù)責(zé)處理個(gè)性化需求。

2.3 代碼自動(dòng)生成

代碼自動(dòng)生成方案是根據(jù)設(shè)計(jì)的分層結(jié)構(gòu)框架,定義模板和元數(shù)據(jù)(即輸入數(shù)據(jù)模型),開(kāi)發(fā)平臺(tái)軟件,并將元數(shù)據(jù)轉(zhuǎn)換成模板能識(shí)別匹配的程序代碼。

在模板方面,通過(guò)需求迭代轉(zhuǎn)換和分層結(jié)構(gòu)框架,將相對(duì)固定部分需求模板功能書(shū)分解到交互層、邏輯層和控制層中,并設(shè)計(jì)成模板文件。設(shè)備驅(qū)動(dòng)層、微內(nèi)核層和硬件抽象層是嵌入式軟件和硬件設(shè)備相關(guān)部分,可以編寫(xiě)底層驅(qū)動(dòng)程序,封裝成驅(qū)動(dòng)函數(shù)庫(kù)[10],并直接設(shè)計(jì)成模板文件。代碼文件結(jié)構(gòu)如圖2所示。

圖2 代碼文件結(jié)構(gòu)示意圖

元數(shù)據(jù)是描述其他數(shù)據(jù)的數(shù)據(jù)。其對(duì)數(shù)據(jù)通用屬性進(jìn)行抽象和標(biāo)準(zhǔn)化,具有唯一的身份元素信息[11]。元數(shù)據(jù)在代碼自動(dòng)生成中用于表述代碼生成的內(nèi)容,由個(gè)性化需求抽象而成?？刂泣c(diǎn)表包含負(fù)載和傳感器的數(shù)量、類型和接口等信息,代表了個(gè)性化需求。項(xiàng)目中控制點(diǎn)表的每個(gè)負(fù)載和傳感器都看作1個(gè)基本元素。數(shù)字化和數(shù)據(jù)接口標(biāo)準(zhǔn)化并對(duì)象化后,可作為元數(shù)據(jù)。以傳感器為例,其對(duì)象化后可以作為擴(kuò)展標(biāo)記語(yǔ)言(extensible markup language,XML)數(shù)據(jù)。XML數(shù)據(jù)示例如下。

...

平臺(tái)軟件作為代碼生成器,包含定義好的模板文件和元數(shù)據(jù)轉(zhuǎn)換功能。平臺(tái)軟件將元數(shù)據(jù)轉(zhuǎn)換成交互層控制點(diǎn)表模塊,將元數(shù)據(jù)插入到模板中,生成對(duì)應(yīng)的代碼。例如,對(duì)于傳感器元數(shù)據(jù),平臺(tái)軟件從元數(shù)據(jù)庫(kù)XML文件讀入傳感器數(shù)據(jù),通過(guò)預(yù)定義的結(jié)構(gòu)體將其生成控制點(diǎn)表模塊代碼文件。預(yù)定義的結(jié)構(gòu)體是元數(shù)據(jù)的1種代碼模板,是元數(shù)據(jù)庫(kù)XML文件中傳感器數(shù)據(jù)的代碼表現(xiàn)形式,通過(guò)平臺(tái)軟件實(shí)例后即生成傳感器數(shù)據(jù)的代碼。

//預(yù)定義結(jié)構(gòu)體,可根據(jù)實(shí)際功能預(yù)定義

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 測(cè)試驗(yàn)證及應(yīng)用

測(cè)試驗(yàn)證主要分為模板驗(yàn)證、元數(shù)據(jù)驗(yàn)證和模擬使用驗(yàn)證。模板驗(yàn)證要求保證完備性和邏輯性,確認(rèn)是否包含模板功能書(shū)的全部?jī)?nèi)容、是否滿足需求的邏輯功能。元數(shù)據(jù)驗(yàn)證要求不同的元數(shù)據(jù)能正確轉(zhuǎn)換,以及元數(shù)據(jù)插入到模板的邏輯對(duì)應(yīng)關(guān)系正確。元數(shù)據(jù)驗(yàn)證是測(cè)試驗(yàn)證的重點(diǎn),至少應(yīng)包括以下內(nèi)容。

①各類負(fù)載對(duì)象驗(yàn)證測(cè)試。負(fù)載包括風(fēng)機(jī)、水閥、風(fēng)閥、電加熱、加濕器、聯(lián)動(dòng)外機(jī)空調(diào)、過(guò)濾器和其他開(kāi)關(guān)型負(fù)載。每個(gè)負(fù)載對(duì)象由不同的負(fù)載類型、不同的負(fù)載接口驗(yàn)證測(cè)試。不同的負(fù)載組合、負(fù)載數(shù)量需分別驗(yàn)證測(cè)試。

②各類傳感器對(duì)象驗(yàn)證測(cè)試。傳感器包括溫度、濕度、風(fēng)壓、頻率等。每個(gè)傳感器對(duì)象的各種類型、接口需分別驗(yàn)證測(cè)試。不同的傳感器組合、傳感器數(shù)量需分別驗(yàn)證測(cè)試。

③負(fù)載對(duì)象和傳感器各種組合測(cè)試驗(yàn)證。

本文根據(jù)歷史訂單的需求進(jìn)行模擬使用驗(yàn)證,以驗(yàn)證需求迭代、需求分解和代碼生成全過(guò)程是否存在漏洞。驗(yàn)證完成后,就可以進(jìn)行工程應(yīng)用。接到新的組合式空調(diào)工程訂單后,開(kāi)發(fā)人員直接從訂單需求提取出控制點(diǎn)表,以抽象化后數(shù)據(jù)作為元數(shù)據(jù),并通過(guò)平臺(tái)軟件生成該訂單的軟件代碼。

工程應(yīng)用流程如圖3所示。

圖3 工程應(yīng)用流程圖

本文以某縣發(fā)展中心和某市黨校新區(qū)工程項(xiàng)目訂單為例,分析工程應(yīng)用過(guò)程。資源耗費(fèi)對(duì)比如表1所示。

表1 資源耗費(fèi)對(duì)比

工程應(yīng)用結(jié)果表明:本文研究的嵌入式軟件自動(dòng)開(kāi)發(fā)模式能夠快速自動(dòng)生成訂單軟件代碼,大幅降低代碼開(kāi)發(fā)耗費(fèi);在平臺(tái)軟件已經(jīng)驗(yàn)證充分的前提下,應(yīng)用測(cè)試僅需復(fù)核控制點(diǎn)表模塊的接口部分,可有效減少代碼測(cè)試資源的耗費(fèi)。

4 結(jié)論

本文對(duì)組合式空調(diào)儀控系統(tǒng)軟件自動(dòng)化開(kāi)發(fā)模式進(jìn)行研究和探索。根據(jù)組合式空調(diào)控制需求特點(diǎn),采用基于模板的自動(dòng)代碼生成技術(shù),以自主平臺(tái)軟件作為代碼生成器,設(shè)計(jì)分層結(jié)構(gòu)框架和代碼生成方案。該代碼生成方案通過(guò)平臺(tái)軟件將共性需求模板功能書(shū)設(shè)計(jì)成模板代碼,將個(gè)性需求轉(zhuǎn)換成交互層控制點(diǎn)表模塊代碼,以生成項(xiàng)目最終軟件代碼。該研究實(shí)現(xiàn)了訂單需求到訂單軟件代碼的自動(dòng)生成,并將測(cè)試驗(yàn)證和應(yīng)用到工程訂單中,有效解決了組合式空調(diào)儀控系統(tǒng)軟件的重復(fù)開(kāi)發(fā)耗費(fèi)問(wèn)題。

基于組合式空調(diào)的控制軟件自動(dòng)化開(kāi)發(fā)模式的實(shí)踐,有效解決了嵌入式軟件的重復(fù)開(kāi)發(fā)問(wèn)題。本文研究了中小項(xiàng)目自主開(kāi)發(fā)平臺(tái)軟件實(shí)現(xiàn)自動(dòng)代碼生成及工程應(yīng)用,為國(guó)產(chǎn)自主儀控系統(tǒng)軟件自動(dòng)化開(kāi)發(fā)提供了借鑒。