模型驅(qū)動的嵌入式系統(tǒng)設(shè)計

吳一帆，張毅玲，周世安

（北京控制工程研究所，北京l00080）

模型驅(qū)動的嵌入式系統(tǒng)設(shè)計

吳一帆，張毅玲，周世安

（北京控制工程研究所，北京l00080）

隨著嵌入式系統(tǒng)設(shè)計周期越來越短，功能越來越復(fù)雜，越來越多領(lǐng)域的設(shè)計人員參與設(shè)計，市場需求導(dǎo)向致使需求變更越來越多，以傳統(tǒng)文檔形式的需求來驅(qū)動開發(fā)已根本不能滿足時間和成本方面的要求。本文提出了采用可執(zhí)行模型、動態(tài)需求規(guī)格和接口控制文檔共同作用的驅(qū)動嵌入式系統(tǒng)設(shè)計方法，它能夠較好地滿足目前系統(tǒng)設(shè)計的要求。在文中，我們首先介紹了當前嵌入式系統(tǒng)設(shè)計中存在的一些問題，然后介紹了模型驅(qū)動設(shè)計的方法、語言和優(yōu)點，并對動態(tài)需求規(guī)格和接口控制文檔的執(zhí)行給出了建議，最后得出模型驅(qū)動的嵌入式系統(tǒng)設(shè)計是一種行之有效途徑的結(jié)論。

模型驅(qū)動；統(tǒng)一建模語言；動態(tài)需求規(guī)格；接口控制文檔

1 引 言

目前嵌入式系統(tǒng)設(shè)計越來越復(fù)雜，已經(jīng)涉及到計算機系統(tǒng)、電子、電氣、信號處理、自動控制、軟件以及機械設(shè)計等多個領(lǐng)域。這些領(lǐng)域的設(shè)計師共同合作才能完成任務(wù)，同時還要兼顧成本、時間和可靠性等多個方面的約束。對于這類涉及到多個專業(yè)領(lǐng)域的系統(tǒng)研制，其中一個很大的風(fēng)險就是各個專業(yè)領(lǐng)域的設(shè)計人員往往只擅長本領(lǐng)域的知識，而卻對其他專業(yè)領(lǐng)域了解較少，因此各個接口之間很容易出現(xiàn)錯誤，尤其在系統(tǒng)設(shè)計經(jīng)常出現(xiàn)變更的情況下，這種問題更為嚴重。

針對這些問題，在嵌入式系統(tǒng)設(shè)計中往往采用迭代的開發(fā)方式，這些方式采用基于模型的方法進行預(yù)先驗證。例如硬件設(shè)計師采用saber、pSpice等仿真器或者面包板等工具對硬件產(chǎn)品或部分電路進行預(yù)先實現(xiàn)和測試。機械設(shè)計師采用支持三維模型的設(shè)計工具進行設(shè)計，并通過三維模型與其他領(lǐng)域設(shè)計師進行交流。通過這種方式，設(shè)計師預(yù)先就可驗證并且同時提供用于共同交流的平臺，能夠有效地降低研制過程的風(fēng)險。

盡管部分領(lǐng)域能夠建立模型進行早期驗證或者提供平臺進行交流，但是嵌入式系統(tǒng)的大部分設(shè)計領(lǐng)域卻缺少實現(xiàn)這種方式行之有效的途徑。

文獻[l]中提到可以借助統(tǒng)一建模語言（UML）或系統(tǒng)建模語言（SysML）的高度抽象能力建立系統(tǒng)模型，但似乎過于重視這種模型的應(yīng)用，實際上對于非功能的描述，例如一些系統(tǒng)約束，UML和SysML的機制還很難支持。

本文中，描述了在嵌入式系統(tǒng)的自頂而下的設(shè)計中，如何采用模型輔助產(chǎn)品的開發(fā)。其中最重要的一點就是，如何將模型、需求規(guī)格以及ICD結(jié)合起來驅(qū)動嵌入式系統(tǒng)的設(shè)計。

2 問題描述與定義

實現(xiàn)一個復(fù)雜的嵌入式系統(tǒng)，需要多個設(shè)計領(lǐng)域的設(shè)計師相互配合才能夠完成。如果設(shè)計過程完全采用瀑布模式的開發(fā)方式，這些設(shè)計師的設(shè)計成果只會在最后的系統(tǒng)實現(xiàn)階段進行系統(tǒng)集成，這時大量系統(tǒng)集成的問題才能出現(xiàn)。而上層需求定義不明、理解偏差、需求遺漏以及不同領(lǐng)域之間配合失誤或者接口出現(xiàn)偏差等是出現(xiàn)很多問題的根源。

如果想控制好嵌入式系統(tǒng)的整個研制過程，就需要控制好各個部分的研制過程。各專業(yè)領(lǐng)域人員對于一個嵌入式系統(tǒng)理解是不同的（視圖不同）。硬件設(shè)計人員熟悉的嵌入式系統(tǒng)是硬件電路；軟件設(shè)計人員熟悉的嵌入式系統(tǒng)即嵌入式軟件；而系統(tǒng)設(shè)計者熟悉的則是各種算法以及各種控制邏輯的結(jié)合體。所有設(shè)計人員都認可的是系統(tǒng)物理外觀及動態(tài)行為——嵌入式系統(tǒng)通過外部事件作用和條件變化，改變自身狀態(tài)，并完成對外部的反應(yīng)。所有設(shè)計人員通過觀察嵌入式系統(tǒng)對外部的反應(yīng)，都可以了解基本的任務(wù)內(nèi)容。因此在這個層面上視圖是統(tǒng)一的，進行交流是最有效率的。

3 模型驅(qū)動設(shè)計

從以上分析可以看到，嵌入式系統(tǒng)在頂層進行建模十分必要。實際上很長時間以來，在頂層設(shè)計中，針對自動控制和信號處理應(yīng)用都會采用算法工具建立模型，驗證設(shè)計方案是否正確。但是一個嵌入式系統(tǒng)一般不會僅僅由算法構(gòu)成，往往是算法（順序工作方式）和邏輯（應(yīng)激工作方式）的結(jié)合體，需要用靜態(tài)結(jié)構(gòu)和動態(tài)行為對模型進行描述。目前的頂層模型往往僅是基于算法和靜態(tài)結(jié)構(gòu)模型，針對系統(tǒng)動態(tài)行為——例如控制邏輯缺乏有效的方法進行描述。

在頂層利用語言描述任務(wù)，這種語言需要具備兩個特點：一是需要有較高的抽象能力；一是應(yīng)當具備相當嚴格的語義。具備較高的抽象能力才能幫助設(shè)計人員對系統(tǒng)和問題進行有效地描述，例如采用C++/HDL這樣的語言描述系統(tǒng)不但繁瑣，而且涉及到實現(xiàn)細節(jié)以至于干擾正常設(shè)計工作。采用自然語言描述系統(tǒng)，盡管其抽象的能力可以很高，但是語義卻很難做到嚴格，因此完全采用自然語言描述系統(tǒng)往往存在二義性或者不完備性，并且難以驗證，對系統(tǒng)設(shè)計的合理性幫助不大。完全采用形式化的語言如Z語言提出需求規(guī)格，盡管語義嚴格，但是較為晦澀，推廣有較大的難度。

UML從l997年確立為標準以來，經(jīng)過l0年的發(fā)展已經(jīng)升級至UML2.l。盡管最初其應(yīng)用的主要對象是軟件設(shè)計，但是隨著應(yīng)用越來越廣泛和逐漸發(fā)展成熟，已經(jīng)開始進入到硬件及系統(tǒng)設(shè)計領(lǐng)域。目前OMG（制訂UML標準的組織）和INCOSE合作基于UML制訂了系統(tǒng)建模語言SysML（基本上是UML的子集）語言，UML/SysML儼然成為了系統(tǒng)設(shè)計主流語言之一。

UML是一種基于圖形的語言，包含了l3種形式化和非形式化的圖形，可以用來描述靜態(tài)結(jié)構(gòu)和動態(tài)行為。例如設(shè)計者可以采用UML中的用例圖（Use Case）對需求分析的結(jié)果進行規(guī)格化說明；采用類圖、復(fù)合結(jié)構(gòu)圖和部署圖進行系統(tǒng)級靜態(tài)結(jié)構(gòu)描述；此外可以采用活動圖、時序圖以及狀態(tài)圖進行系統(tǒng)的動態(tài)行為描述。UML具有很高的抽象能力，例如如果采用文字對某一個通訊方式進行描述，可以寫成如下方式：

系統(tǒng)每30ms進行一次通訊，通訊成功后，錯誤計數(shù)器清零，設(shè)置速率更新標志為真；如果通訊失敗，在錯誤計數(shù)器計數(shù)為零的情況下，進行串口初始化，并且計數(shù)器計數(shù)遞增一次，如果計數(shù)器不為零，則計數(shù)器計數(shù)同樣遞增一次，0.5ms后再次通訊，當錯誤計數(shù)器計數(shù)大于5時，系統(tǒng)不再進行通訊，同時關(guān)閉時鐘中斷。

圖l為采用UML中的狀態(tài)圖描述系統(tǒng)進行通訊的動態(tài)行為。采用狀態(tài)圖形式的模型“可視性”大大增強，而且由于狀態(tài)圖是一種形式化的描述方式，因此可以相當嚴格地描述系統(tǒng)動態(tài)行為。同時由于是形式化描述，就可以采用形式化驗證技術(shù)和工具，在不輸入任何測試向量的情況下對系統(tǒng)進行測試，可以發(fā)現(xiàn)邏輯上出現(xiàn)的死鎖或者未達狀態(tài)等問題。

圖l 通訊狀態(tài)圖

再以狀態(tài)圖為例說明UML的描述能力，狀態(tài)圖支持“并發(fā)”和“層次”，狀態(tài)“并發(fā)”可以降低狀態(tài)爆炸的可能性，而“層次”則可以隱藏底層復(fù)雜的邏輯，因此可以描述非常復(fù)雜的動態(tài)行為。如圖2所示，它描述的是一個電子控制系統(tǒng)中某一個部件的一個工作狀態(tài)，這個控制邏輯如果采用文字形式進行描述，要表達清楚則非常困難。

UML不適合描述算法，因此將擅長描述算法的語言與UML結(jié)合構(gòu)建模型是一種極佳的選擇。文獻[2]采用s語言（simulink支持）和UML以及快速原型工具進行聯(lián)合完成電機控制器頂層的建模工作。在模型中由simulink完成閉環(huán)算法，而采用基于UML的工具rhapsody完成控制以及故障處理邏輯的設(shè)計，快速原型工具提供命令面板和儀表。電機控制器模型雖然包含算法和控制邏輯，但是都已經(jīng)通過快速原型工具封裝在一起，通過面板接受外部的命令，通過儀表向外部設(shè)計人員顯示電機工作狀態(tài)。通過這種方式建立模型，就可以以一種整體概念面向設(shè)計者，從而使所有參與工作的設(shè)計人員從中獲得感性認識，并和頂層設(shè)計人員就各種問題進行有效的溝通。頂層設(shè)計人員實際上建立的是一個與平臺無關(guān)的模型（PIM），通過模型可以進行各種方案的嘗試，劃分子系統(tǒng)，同時向子系統(tǒng)提出需求。

圖2 復(fù)雜狀態(tài)圖例

在一個復(fù)雜的嵌入式系統(tǒng)研制過程中，為了便于管理和實現(xiàn)，往往需要將系統(tǒng)分解為多個子系統(tǒng)并行開發(fā)。在進行系統(tǒng)劃分的過程中，一般會根據(jù)系統(tǒng)功能以及專業(yè)進行劃分，而此時由于出現(xiàn)跨域的策劃和需求，如果僅依據(jù)文檔即便是進行交流，其效率仍然比較低。因此頂層設(shè)計人員將模型分配給各個專業(yè)領(lǐng)域的設(shè)計人員，由他們對模型進行細化，實際上這也正是子系統(tǒng)的設(shè)計人員進行需求分析和設(shè)計的過程。子系統(tǒng)的設(shè)計人員可以根據(jù)經(jīng)驗、需求和各種約束，進一步細化模型的靜態(tài)結(jié)構(gòu)和動態(tài)行為，將完成細化后的這一“虛擬產(chǎn)品”重新提交給頂層設(shè)計人員所構(gòu)造的模型環(huán)境中進行驗證。這樣不但可以盡早發(fā)現(xiàn)過去可能只在集成時發(fā)現(xiàn)的問題，并且在需求或設(shè)計發(fā)生變更時，設(shè)計人員還可以快速對影響域進行評估。

圖3 MDA基本流程

當前，隨著技術(shù)的發(fā)展，國外系統(tǒng)和軟件設(shè)計界提出了模型驅(qū)動體系結(jié)構(gòu)（MDA）[3]。如圖3所示，MDA基本可以分為兩個方面，建模人員通過創(chuàng)建一個與平臺無關(guān)的模型（PIM）來表示特定應(yīng)用。而后，使用模型編譯器將模型轉(zhuǎn)變成一個平臺特定的模型（PSM）。對于前者如前敘述。對于后者實際則是通過模型編譯器將模型直接變?yōu)榭刹渴鸬南到y(tǒng)。例如對simulink中描述的模型，可以采用編譯器將其轉(zhuǎn)變?yōu)镠DL語言，進而設(shè)計成為FPGA或者ASIC，也可以轉(zhuǎn)變?yōu)榛贒SP的軟件代碼。另一方面，將UML模型轉(zhuǎn)變?yōu)镃/C++/Java/Ada等語言的技術(shù)已經(jīng)較為成熟，在企業(yè)級和嵌入式設(shè)計領(lǐng)域都已經(jīng)得到應(yīng)用。例如嵌入式系統(tǒng)設(shè)計工具rhapsody，可以根據(jù)UML描述的模型生成基于多種嵌入式操作系統(tǒng)的代碼，只要不是在資源極度受限的情況下，可以直接應(yīng)用這些自動生成的代碼。對于沒有操作系統(tǒng)的嵌入式軟件，也可以采用一些開源或者商業(yè)的模型編譯器將UML模型轉(zhuǎn)換為8位、l6位以及32位CPU的C代碼。

此外，UML提供了profile、stereotype、tag等機制供使用者進行擴展。各個領(lǐng)域的使用者可以采用這些機制針對自己的應(yīng)用場合設(shè)計特定的建模語言以及向PSM影射的方法。通過這種方式，UML語言可以產(chǎn)生例如HDL、SystemC[4～5]、System Verilog以及各種硬件專有C語言等[6]。通過采用MDA，設(shè)計者可以將更多的精力集中到分析、設(shè)計以及驗證上，通過借助自動化工具，可盡量將嵌入式系統(tǒng)的實現(xiàn)階段縮短且減少人為的錯誤。

4 系統(tǒng)設(shè)計

盡管模型驅(qū)動的方式對嵌入式系統(tǒng)的設(shè)計有諸多好處，但是對于實現(xiàn)一個產(chǎn)品來說還遠遠不夠。例如對于嵌入式產(chǎn)品相關(guān)的各類規(guī)范和法規(guī)等約束條件、可靠性要求和工藝等，采用模型都還很難表述清楚，因此模型可以作為傳統(tǒng)技術(shù)的輔助手段，主要針對部分功能和性能進行說明。

目前比較傳統(tǒng)的方法都是通過文檔化的需求規(guī)格說明和ICD驅(qū)動設(shè)計。但是文檔化的需求規(guī)格說明存在很多的缺點，首先它提供的有效信息往往淹沒于大量已知的信息中，很難發(fā)現(xiàn)遺漏的和相互沖突的信息。研制一個復(fù)雜的嵌入式系統(tǒng)，設(shè)計需求本身是一個動態(tài)變化的過程，因此文檔化的需求很難適應(yīng)這種變化，最終的結(jié)果往往是許多需求實現(xiàn)先于需求提出，極大地損壞了需求的可跟蹤性。

為了提供有效需求，需求規(guī)格應(yīng)當滿足以下幾個條件：提供模板以便能有效地捕獲和組織需求；能夠?qū)⑿枨蟀磳哟瘟斜硪怨┓治?；能夠準確地定位導(dǎo)出需求（derived requirement）；能夠按照要求對需求進行排序、過濾以及提供索引；各個層次間的需求能夠鏈接以便提高需求的可跟蹤能力；可以對需求進行版本管理能力；能夠?qū)Ω黝愋枨笤O(shè)置屬性等等。

因此需求規(guī)格不應(yīng)采用文檔化方式而應(yīng)當采用動態(tài)方式。例如根據(jù)一個嵌入式系統(tǒng)的需求規(guī)格，機械設(shè)計師可以迅速提取出系統(tǒng)對機械尺寸的需求，電氣工程師可提取出驅(qū)動電路的需求，軟件工程師可提取出對軟件的需求，電子工程師既可以要求只顯示系統(tǒng)模擬輸出信號數(shù)目，同時又可以一起對整個需求規(guī)格進行討論。討論結(jié)果生成的更改，既可以獨立于其他需求獨立顯示出來，又可以按照格式要求融入到需求規(guī)格中，便于系統(tǒng)外的人員查閱和評審。此外，需求規(guī)格應(yīng)當具備和模型緊密聯(lián)系的能力，例如需求規(guī)格中完成的更改能夠在模型中得到反映，或者是模型中進行的修改直接反映到需求規(guī)格中去。

ICD也應(yīng)當具有同需求規(guī)格同樣的特點，它應(yīng)當具有檢索、分類、排序以及過濾能力。而且ICD應(yīng)當和模型緊密地結(jié)合到一起。這是因為在嵌入式系統(tǒng)中，系統(tǒng)工作往往都是由各種條件和信號驅(qū)動的，這些信號特點大多都在ICD中進行了具體的表述，因此模型和ICD中的信號如果能夠雙向更動即做到同步，那么設(shè)計者在模型中所作的工作更有效率。

將模型以及動態(tài)形式的需求規(guī)格與ICD相結(jié)合驅(qū)動嵌入式系統(tǒng)設(shè)計，設(shè)計師可以通過模型進行交流和驗證，同時可以改進自己的設(shè)計。由于模型和需求規(guī)格以及ICD可以進行雙向更動，因此改進內(nèi)容可以在需求規(guī)格和ICD中自動修改，從而使整個設(shè)計同步進行，不會出現(xiàn)遺漏。還可以利用其動態(tài)需求規(guī)格和ICD的跟蹤、檢索、排序和過濾能力，完成模型設(shè)計很難實現(xiàn)的設(shè)計覆蓋性檢查、跟蹤評估以及明晰的結(jié)構(gòu)表述等。因此利用這種優(yōu)勢互補可以使嵌入式系統(tǒng)設(shè)計效率大大提高。

5 結(jié) 論

嵌入式系統(tǒng)設(shè)計變得越來越復(fù)雜，隨著開發(fā)周期、成本和可靠性等諸多方面的壓力，迫切需要出現(xiàn)一種新的設(shè)計方法，而采用由模型、非文檔式的需求規(guī)格和ICD共同驅(qū)動嵌入式系統(tǒng)設(shè)計，應(yīng)當是一條非?？尚械耐緩?。

[l]Bruce C，Erik D，Michael M，etal.Model driven systems development for space systems[C].58thInternational Astronautic Congress，September 24-28，2007，Hyderabad，India

[2]吳一帆，徐陽.統(tǒng)一建模技術(shù)研究[C].航天軟件技術(shù)發(fā)展交流會，2007，北京

[3]Martin F著，徐家福譯.UML精粹[M].北京：清華大學(xué)出版社，2004，5～7

[4]Riccobene E，Scandurra P，Rosti A，Bocchio S.A SoC design methodology involving a UML 2.0 profile for system[C].Proceedings of the Conference on Design，Automation and Test in Europe，Volume 2，2005，704～709

[5]Ramanan M.SoC，UML&MDA-an investigation[C].UML-SoC 2006 Presentations，2006，San Francisco，USA

[6]Wu Y F，Xu Y.Model-driven SoC/SoPC design via UML to impulse[C].UML-SOC，the 44thDesign Automation Conference，June 3，2007，San Diego，USA

Mode1 Driven Embedded System Deve1opment

WU Yifan，ZHANG Yiling，ZHOU Shian
（Beijing Institute of Control Engineering，Beijing 100080，China）

This paper presents amethod for development of embedded systems.It addresses issues how to design amulti-technologies system with help ofmodel，specs and interface control documents（ICD）.The existing problems with the design are first analyzed.Then the paper addresses the issues that model，active specs and ICD can drive the development of embedded systems effectively during the design phase.Finally，some useful conclusions for the embedded system development driven by model are given.

model driven；UML；active spec；ICD

TP3

A

l674-l579（2008）0l-0060-05

2007-l2-09

吳一帆（l972-），男，四川人，高級工程師，研究方向為電子線路設(shè)計（e-mail：wuyf@bice.org.cn）。