發控設備軟件通用化技術實現探討

趙偉忠 丁小芩

上海機電工程研究所， 上海 201109

?

發控設備軟件通用化技術實現探討

趙偉忠 丁小芩

上海機電工程研究所， 上海 201109

針對發控設備軟件研制的現狀，分析了存在的問題，結合軟件業內的成熟做法和成功經驗，提出了如何實現發控設備軟件的通用化，從而有效提高發控設備軟件生產效率以及有效保證發控設備軟件質量。

發控設備軟件；通用化技術；軟件架構

發控設備軟件(以下簡稱發控軟件)是指與發控設備相關的軟件，大多數屬于控制軟件，運行在嵌入式芯片上，具有如下的技術特點： 1)以C語言為主的嵌入式軟件； 2)開發、聯試周期長； 3)復雜接口、復雜流程和復雜時序要求； 4) 高實時性； 5) 高安全性 ； 6) 高可靠性。隨著戰術型號領域的跨越式發展，在研型號任務越來越多，意味著多個型號的多款發控軟件同時開始工程化開發，對發控軟件人員的需求出現了急劇增長，現有的發控軟件人員儲備已經疲于應對，急需尋求解決辦法。如何實現發控軟件的通用化，從而有效提高發控軟件生產效率以及有效保證發控軟件質量，是值得探討的問題。

1 型號軟件開發現狀

按照軟件實際運行環境分類，發控軟件配置項大致可以分為基于VxWorks操作系統的產品軟件、基于DSP平臺的產品軟件以及基于Windows操作系統的產品軟件，其中，基于VxWorks操作系統的產品軟件一般是功能最為豐富、設計最為復雜的軟件，本文以基于VxWorks操作系統的產品軟件為例加以說明。

一般來講，各型號的發控軟件工作模式有相似性，都是在上級系統的指揮下，根據通信報文進行數據分析、模型解算，進而完成對下級的數據傳遞、對設備的自動化控制等。

總體來說，隨著X86，ARM，PowerPC等先進嵌入式硬件平臺的廣泛應用，基于實時多任務嵌入式操作系統VxWorks進行開發的產品軟件也越來越多。在軟件規模方面，1套發控軟件大約會包含4個左右產品軟件配置項和6個左右模擬器軟件。每個產品軟件代碼行數從3000～20000不等。

在研發模式方面，現階段，一個型號對應一支軟件隊伍，如圖1所示。軟件研發均以型號為主線，各型號軟件產品的開發由各型號的設計師團隊單獨完成，貫穿了設計、開發、調試、測試和維護等軟件全生命周期，即以型號為牽引、以軟件工程化管理為核心的研發模式 。

圖1 目前的型號軟件研發模式

2 存在的問題

目前發控軟件研發主要存在以下問題：

(1) 生產效率低，人力資源矛盾突出

生產效率低的核心原因是各項目各自為戰，相互間沒有共享設計成果。每個型號軟件都要獨立完成軟件開發的各個步驟，軟件設計各自為戰，軟件復用能力低，開發周期長，而每個型號針對每個軟件配置項均需要配備一個軟件設計人員，一旦型號任務多，則型號兼項情況嚴重，軟件設計人員任務負擔過重。

(2) 質量難以保證

以型號為主線的管理模式，導致各型號的設計師團隊相互溝通較少，缺少共同探討的學習平臺，產品設計水平的高低主要由型號設計師的設計能力和經驗來保證，無法借鑒其它型號的設計經驗和優秀設計模式，容易造成軟件設計質量參差不齊，軟件質量較大程度依賴于個人水平，從而影響產品的可靠性、維修性和通用性。

(3) 可擴展差

軟件產品可擴展性差的主要原因是軟件產品在設計之初沒有充分考慮拓展需求，也沒有充分考慮軟件整體架構。深層次的原因是各軟件項目在需求分析時各自為戰，對需求分析沒有挖掘充分和在廣度上拓展，導致后期出現需求變更時改動量大，靈活性差，不便于功能擴展。

(4) 軟件測評效率低

每個型號都要完成獨立的測評，因為沒有形成獨立的復用函數或者代碼庫，對于部分復用的代碼依然要完成全部的測評。

(5) 后期維護困難(特別是人員變更以后)

多數型號軟件是依據設計師個人思路和邏輯形成代碼的，缺乏統一的、整體性框架的約束，在型號研制后期或者批產階段，如果相應設計師換人，對原代碼的熟悉是一個漫長而痛苦的過程。

(6) 難以創新

難以進行高層次創新的主要原因是缺少高層次的決策指導。不斷創新是航天工程持續發展的不竭動力。以往，每個軟件項目都是以滿足上級任務書要求為基本目標，加之時間、人手的限制，很少主動去考慮技術創新，并且有大量低層次的重復勞動。長此以往下去，會造成技術停滯不前。

3 解決思路

首先觀察一下整個軟件行業，在解決代碼復用的問題上，目前業界普遍在用3種不同層次的方法：代碼模式(函數模式)、設計模式和架構模式。以下分別針對3種模式分析用于型號發控軟件研發的可行性和意義。

3.1 代碼模式

代碼模式(函數模式)主要指函數的復用，目前已開始運用，但是局限在一些細節層面，整體利用率低，因為函數是最基本的復用單元，如果沒有統一的規劃，單純進行函數復用，很難提高整體復用率。例如某型號的發控軟件的函數復用率僅為3%左右，具體數據如表1所示。

表1 函數復用率具體數據舉例

3.2 設計模式

設計模式是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。它確定了所包含的類和實例，它們的角色、協作方式以及職責分配。每一個設計模式都集中于一個特定的面向對象設計問題或設計要點，描述了什么時候使用它，在另一些設計約束條件下是否還能使用，以及使用的效果和如何取舍。因為設計模式描述的是面向對象設計，其實現語言是C++、JAVA等主流面向對象編程語言，而不是過程式語言。目前經典的設計模式共包含23個(如抽象工廠模式、適配器模式、觀察者模式等)。設計模式可以幫助人們運用對象、接口、類和繼承之類的概念寫出靈活的、可復用的軟件。

目前的型號發控軟件基本都是在VxWorks或DSP下使用C語言開發的，如果引入設計模式，需要采用面向對象的設計方法和面向對象設計語言，目前整個航天的軟件工程管理需要做一定的調整。這是一個發展方向，也是需要比較漫長的過程。

3.3 架構模式

軟件體系結構通常被稱為軟件架構，指可以預制和可重構的軟件框架結構。軟件系統的架構也被描述為軟件組件與組件之間的交互。軟件的架構設計是軟件的核心，任何一個軟件都有其架構，區別在于架構的好壞。總結來說，軟件架構的主要特點如下：

1) 軟件架構(Architecture) 不是軟件，而是關于如何設計的決策；

2) 框架 (FrameWork) 是軟件架構的代碼實現；

3) 架構是關于如何劃分系統，及各部分如何交互的；

4) 架構是系統的高層次策略，可作為具體軟件體系結構的模板；

5) 已經成熟的軟件架構模式包括十多種，如分層模式、倉庫系統知識庫模式和過程控制模式等。

如果說函數是磚，設計模式是墻體，那么架構是整棟建筑的框架。一旦將整棟建筑的框架設計好，在這個基礎上靈活地增加墻體和磚，就像軟件的二次開發和擴展，是比較容易的事情。也即，只有將軟件的架構設計好，才能研發出通用性好、擴展性好、復用率高和代碼質量高的軟件，才能進一步地進行功能創新。

綜上所述，基于通用架構的軟件復用是最高層次、最具效率、能最大范圍規范產品質量的復用模式。在型號發控軟件通用化研發方面，應當采用基于通用架構的軟件復用方式進行研發，以最大程度提高軟件的復用率和質量，保證發控軟件的生產效率。

4 具體方案

依據軟件架構設計思想，必須結合型號嵌入式軟件的自身特點，有針對性地進行型號軟件的通用化軟件架構的設計。

現在研發的基于VxWorks系統的發控軟件一般有如下特點：

1)操作系統VxWorks提供底層BSP支持、中斷處理、多任務調度和任務間通信等支持，其wind內核保證任務間切換時間嚴格限制在毫秒級，且任何時刻系統的狀態都可預測；

2)驅動程序一般由硬件開發商提供，負責處理與底層擴展板卡的交互，包括網絡、CAN、1553B、串口、DIO、DA、AD和定時器等。在運行時態上一般分為函數調用、中斷處理和任務查詢等幾種方式；

3)產品應用代碼更多地關注功能的實現，比如數據分析、算法解算和硬件自動化控制，從而完成發控設備的工作流程。性能上，要實現軟件內部復雜邏輯關系的有序銜接，必須規劃好任務間的時序，做好CPU的時間分配，多任務間資源的互斥保護等，最終依靠VxWorks操作系統的實時調度，保證軟件運行的可靠性和可控性。

以上這點可以開發出性能出色的產品軟件，但是不能保證某些設計師寫出非常糟糕的代碼，為整個系統的后期聯調、試驗埋下諸多隱患。因此必須在此基礎上，做好通用化的軟件架構，提升軟件整體質量。而通用化軟件架構的設計和行業的業務邏輯關系緊密，好的軟件架構設計是建立在對業務邏輯、數學建模的充分理解之上的。

下面通過汽車電子行業標準的研究得到一些啟發。

現代汽車功能創新不斷、多樣化差異化加劇，給汽車電子系統的研發提出更多創新、定制、快速上市的要求。AutoSAR標準就是汽車電子控制單元(ECU)軟件研發的行業標準，也就是行業頂層通用化軟件架構。該標準的架構目標就是能跨平臺、跨產品復用軟件模塊，避免不同產品之間的代碼反復開發等。

AutoSAR標準的關鍵設計思想之一是將應用層、服務層、ECU抽象層和微控制器抽象層的分離。其中，微控制器抽象層包括與微控制器相關的驅動，封裝了微控制器的控制細節，使得上層模塊獨立于微控制器。ECU抽象層，將ECU結構進行抽象、封裝，該層的實現與ECU硬件相關，但與控制器無關。服務層提供包括網絡服務、存儲服務和操作系統服務等系統服務，與平臺無關。應用層包括各種應用程序，與硬件無關。具體如圖2所示。

圖2 汽車電子行業標準(AutoSAR)

這樣的分層模型，將一個大型軟件按實現功能不同分成了若干個能力單元，并歸入不同層中。這樣在面對不同的應用需求時，可以在每個分層中都做到最大程度的復用，而且各層之間的關系耦合度低，只要層與層之間的接口不變，改變某層的內部代碼，不會影響其他層的運行。借鑒外部經驗，通過對發控設備的業務流程的分析，基于VxWorks的型號軟件通用化架構非常適合采用分層模型。

總的來說，以VxWorks操作系統為平臺，發控軟件架構設計可以分為5層，自底向上分別為：

第1層——驅動層：相關硬件驅動。負責處理與底層擴展板卡的最基本交互，主要是包括網絡、CAN、1553B、串口、DIO、DA、AD和定時器等芯片的初始設置、寄存器的操作等。在運行時態上一般分為函數調用、中斷處理和任務查詢等幾種方式；

第2層——驅動管理層：調用驅動層的函數或者任務實現不同的通信功能或硬件動作，比如網絡/串口/CAN/1553B的初始化、數據發送和接收，DIO，DA，AD的數據讀取與賦值等；

第3層——數據解析層：將從驅動管理層接收到的報文解析后形成有定義的數據發送給過程層；將從過程層接收到的數據裝訂成報文發送給驅動管理層。數據解析層只負責數據的解析和傳遞，與硬件和驅動無關。報文的解析是可以根據不同的通信協議靈活定制的。該層的數據解析還包括了任務間的數據傳遞和解析；

第4層——過程層：也可以解釋為最小執行單元層，系統工作流程被細化成最小執行單元，這些最小執行單元對于不同的型號來說，應當是相同的。比如目標的加電、自檢、發射單步步驟、IO讀寫和故障檢測等。最小執行單元被主控層調用；

第5層——主控層：負責根據不同型號的工作流程將最小執行單元組織起來，完成特定的功能，這一層是根據不同型號的需求個性化定制的，包括與運行機制相關的功能。

基于VxWorks的發控軟件通用架構5層模型如圖3所示。

圖3 通用軟件架構五層模型

在數據傳遞和軟件時序控制方面，架構設計要充分考慮中斷、任務調度、內存分配等因素，遵循數據傳遞的松耦合性、時序運行的可控性原則，定義數據傳遞規則和流程，確立任務調度關系，從而將軟件的整體運行框架固化。

分層模型首先就要解決數據傳遞的問題，主要包括層與層之間的數據傳遞。在5層模型中，層與層之間的數據傳遞要制定統一的協議，數據格式也要統一，這樣能保證個別層中發生更改，在數據接口不變的情況下不影響其他層。在數據傳遞機制上，各層大多以任務的形式在內存中運行，任務間要實現松耦合，可利用VxWorks的消息隊列或管道機制實現數據傳遞[1-2]，必要時可以對消息隊列或管道進行二次封裝。

在軟件運行時序控制上，整個軟件是以主控層為核心運行的。主控層以任務方式運行，其基本調度模式有2種：1)靠定時器激勵的定周期模式；2)靠外部消息激勵的非定周期模式，包括外部報文、故障信息和任務間消息等。另外，驅動層以函數調用方式運行，是依靠外部激勵或者驅動管理層的調用運行的。驅動管理層以任務方式運行，依靠外部數據進行激勵，外部數據包括中斷處理、數據解析層傳遞的數據等。數據解析層以任務方式運行，依靠外部數據進行激勵，外部數據包括驅動管理層、過程層傳遞的數據等。過程層以函數調用或者任務方式運行，依靠主控層的調用或者數據解析層傳遞的數據進行激勵。

兩者結合起來的情況如圖4所示。

以上給出了通用發控軟件架構的分層模型、數據流關系、時序控制邏輯，基本確定了一個發控軟件的核心，這樣的架構可以普遍應用于基于VxWorks的發控設備的產品軟件中。依據這樣的軟件架構可以生成最基本的軟件框架代碼，這是對于各個型號、各個軟件都可用的軟件代碼。然后在此代碼的基礎上，進一步開發個性功能的本地化，最終得到型號發控產品軟件。通過這種研發模式，實現軟件架構的框架代碼被復用到各個型號，提高了代碼復用率，規范了各個型號的軟件，也保證了代碼的質量，實現了發控軟件產品化。

5 管理模式改進

在項目管理方式上，由面向單項目管理改進為項目集管理，設定項目集經理進行頂層管控，在各項目之間統籌人力和知識資源，促進設計成果共享，協同完成各個項目。做好項目集管理的核心是各種資源的統籌復用，其中包括知識復用和人力復用。要實現知識復用，包括設計成果的復用，最好的方法就是發控軟件產品化，復用到各個型號中；要實現人力復用，需要對應的組織架構支持和考核辦法跟進。

圖4 通用發控軟件架構數據流和時序圖

6 結論

目前面向多項目的發控軟件研發模式還缺乏足夠的實施案例，尚處于初期的研究與應用中，雖然推廣這樣的研發模式非常具有價值，但是鑒于傳統的習慣做法和嚴格的規范要求，這種模式被廣泛接受和采納還需要時間。但型號軟件研發面臨的局面迫使管理者必須做出選擇，隨著應用的推廣，該研發模式最終將被軟件工程化規范接納和吸收，成為指導所有型號軟件研制的依據之一。另外，如果在硬件設計、作戰流程設計及通信協議設計上考慮周全，不同型號間做到充分復用，那么不同型號間就可以實現軟件需求上的充分復用。

[1] 王雷,樊曉椏,王黨輝.龍芯3A平臺VxWorks移植的研究和實現[M].西安：微電子學與計算機，2012，2.(Wang Lei，Fan Xiaoya，Wang Danghui. The Research and Realization of VxWorks Transplant for LongXin 3A Platform[M]. Xi’an：Microelectronics & Computer，2012，2.)

[2] 陳智育,溫彥軍,陳琪.VxWorks程序開發實踐[M].北京：人民郵電出版社，2004，5. (Chen Zhiyu，Wen Yanjun，Chen Qi. The VxWorks’ Program Development Practice[M].Beijing: Posts and Telecommunications Press，2004，5.)

Research of the Generalized Technologies for the Software of Launch-Control Equipment

Zhao Weizhong1，Ding Xiaoqin2

Shanghai Electro-Mechanical Engineering Institute, Shanghai 201109, China

Theexistingproblemsaboutthestatus-quoofthedevelopmentofthelaunch-controlequipmentsoftwareareanalyzedinthispaper,whicharecombinedwiththematurityandsuccessfulexperienceofthesoftwareindustry.Thesolutionproposedishowtorealizethegeneralizedtechnologiesofthelaunch-controlequipmentsoftwareinordertoimprovetheproductivityofthelaunch-controlequipmentsoftwareandeffectivelyguaranteethequalityofthelaunch-controlequipmentsoftware.

Launch-controlequipmentsoftware;Generalizedtechnology;Softwarestructure

2015-12-07

趙偉忠(1970-)，男，江蘇南通人，碩士研究生，高級工程師，主要研究方向為武器系統軟件總體設計；丁小芩(1987-)，女，安徽潛山人，碩士研究生，工程師，主要研究方向為武器系統軟件總體設計。

TP311.52

A

1006-3242(2016)03-0077-06