模型驱动的嵌入式系统设计

吴一帆，张毅玲，周世安

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

模型驱动的嵌入式系统设计

吴一帆，张毅玲，周世安

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

随着嵌入式系统设计周期越来越短，功能越来越复杂，越来越多领域的设计人员参与设计，市场需求导向致使需求变更越来越多，以传统文档形式的需求来驱动开发已根本不能满足时间和成本方面的要求。本文提出了采用可执行模型、动态需求规格和接口控制文档共同作用的驱动嵌入式系统设计方法，它能够较好地满足目前系统设计的要求。在文中，我们首先介绍了当前嵌入式系统设计中存在的一些问题，然后介绍了模型驱动设计的方法、语言和优点，并对动态需求规格和接口控制文档的执行给出了建议，最后得出模型驱动的嵌入式系统设计是一种行之有效途径的结论。

模型驱动；统一建模语言；动态需求规格；接口控制文档

1 引 言

目前嵌入式系统设计越来越复杂，已经涉及到计算机系统、电子、电气、信号处理、自动控制、软件以及机械设计等多个领域。这些领域的设计师共同合作才能完成任务，同时还要兼顾成本、时间和可靠性等多个方面的约束。对于这类涉及到多个专业领域的系统研制，其中一个很大的风险就是各个专业领域的设计人员往往只擅长本领域的知识，而却对其他专业领域了解较少，因此各个接口之间很容易出现错误，尤其在系统设计经常出现变更的情况下，这种问题更为严重。

针对这些问题，在嵌入式系统设计中往往采用迭代的开发方式，这些方式采用基于模型的方法进行预先验证。例如硬件设计师采用saber、pSpice等仿真器或者面包板等工具对硬件产品或部分电路进行预先实现和测试。机械设计师采用支持三维模型的设计工具进行设计，并通过三维模型与其他领域设计师进行交流。通过这种方式，设计师预先就可验证并且同时提供用于共同交流的平台，能够有效地降低研制过程的风险。

尽管部分领域能够建立模型进行早期验证或者提供平台进行交流，但是嵌入式系统的大部分设计领域却缺少实现这种方式行之有效的途径。

文献[l]中提到可以借助统一建模语言（UML）或系统建模语言（SysML）的高度抽象能力建立系统模型，但似乎过于重视这种模型的应用，实际上对于非功能的描述，例如一些系统约束，UML和SysML的机制还很难支持。

本文中，描述了在嵌入式系统的自顶而下的设计中，如何采用模型辅助产品的开发。其中最重要的一点就是，如何将模型、需求规格以及ICD结合起来驱动嵌入式系统的设计。

2 问题描述与定义

实现一个复杂的嵌入式系统，需要多个设计领域的设计师相互配合才能够完成。如果设计过程完全采用瀑布模式的开发方式，这些设计师的设计成果只会在最后的系统实现阶段进行系统集成，这时大量系统集成的问题才能出现。而上层需求定义不明、理解偏差、需求遗漏以及不同领域之间配合失误或者接口出现偏差等是出现很多问题的根源。

如果想控制好嵌入式系统的整个研制过程，就需要控制好各个部分的研制过程。各专业领域人员对于一个嵌入式系统理解是不同的（视图不同）。硬件设计人员熟悉的嵌入式系统是硬件电路；软件设计人员熟悉的嵌入式系统即嵌入式软件；而系统设计者熟悉的则是各种算法以及各种控制逻辑的结合体。所有设计人员都认可的是系统物理外观及动态行为——嵌入式系统通过外部事件作用和条件变化，改变自身状态，并完成对外部的反应。所有设计人员通过观察嵌入式系统对外部的反应，都可以了解基本的任务内容。因此在这个层面上视图是统一的，进行交流是最有效率的。

3 模型驱动设计

从以上分析可以看到，嵌入式系统在顶层进行建模十分必要。实际上很长时间以来，在顶层设计中，针对自动控制和信号处理应用都会采用算法工具建立模型，验证设计方案是否正确。但是一个嵌入式系统一般不会仅仅由算法构成，往往是算法（顺序工作方式）和逻辑（应激工作方式）的结合体，需要用静态结构和动态行为对模型进行描述。目前的顶层模型往往仅是基于算法和静态结构模型，针对系统动态行为——例如控制逻辑缺乏有效的方法进行描述。

在顶层利用语言描述任务，这种语言需要具备两个特点：一是需要有较高的抽象能力；一是应当具备相当严格的语义。具备较高的抽象能力才能帮助设计人员对系统和问题进行有效地描述，例如采用C++/HDL这样的语言描述系统不但繁琐，而且涉及到实现细节以至于干扰正常设计工作。采用自然语言描述系统，尽管其抽象的能力可以很高，但是语义却很难做到严格，因此完全采用自然语言描述系统往往存在二义性或者不完备性，并且难以验证，对系统设计的合理性帮助不大。完全采用形式化的语言如Z语言提出需求规格，尽管语义严格，但是较为晦涩，推广有较大的难度。

UML从l997年确立为标准以来，经过l0年的发展已经升级至UML2.l。尽管最初其应用的主要对象是软件设计，但是随着应用越来越广泛和逐渐发展成熟，已经开始进入到硬件及系统设计领域。目前OMG（制订UML标准的组织）和INCOSE合作基于UML制订了系统建模语言SysML（基本上是UML的子集）语言，UML/SysML俨然成为了系统设计主流语言之一。

UML是一种基于图形的语言，包含了l3种形式化和非形式化的图形，可以用来描述静态结构和动态行为。例如设计者可以采用UML中的用例图（Use Case）对需求分析的结果进行规格化说明；采用类图、复合结构图和部署图进行系统级静态结构描述；此外可以采用活动图、时序图以及状态图进行系统的动态行为描述。UML具有很高的抽象能力，例如如果采用文字对某一个通讯方式进行描述，可以写成如下方式：

系统每30ms进行一次通讯，通讯成功后，错误计数器清零，设置速率更新标志为真；如果通讯失败，在错误计数器计数为零的情况下，进行串口初始化，并且计数器计数递增一次，如果计数器不为零，则计数器计数同样递增一次，0.5ms后再次通讯，当错误计数器计数大于5时，系统不再进行通讯，同时关闭时钟中断。

图l为采用UML中的状态图描述系统进行通讯的动态行为。采用状态图形式的模型“可视性”大大增强，而且由于状态图是一种形式化的描述方式，因此可以相当严格地描述系统动态行为。同时由于是形式化描述，就可以采用形式化验证技术和工具，在不输入任何测试向量的情况下对系统进行测试，可以发现逻辑上出现的死锁或者未达状态等问题。

图l 通讯状态图

再以状态图为例说明UML的描述能力，状态图支持“并发”和“层次”，状态“并发”可以降低状态爆炸的可能性，而“层次”则可以隐藏底层复杂的逻辑，因此可以描述非常复杂的动态行为。如图2所示，它描述的是一个电子控制系统中某一个部件的一个工作状态，这个控制逻辑如果采用文字形式进行描述，要表达清楚则非常困难。

UML不适合描述算法，因此将擅长描述算法的语言与UML结合构建模型是一种极佳的选择。文献[2]采用s语言（simulink支持）和UML以及快速原型工具进行联合完成电机控制器顶层的建模工作。在模型中由simulink完成闭环算法，而采用基于UML的工具rhapsody完成控制以及故障处理逻辑的设计，快速原型工具提供命令面板和仪表。电机控制器模型虽然包含算法和控制逻辑，但是都已经通过快速原型工具封装在一起，通过面板接受外部的命令，通过仪表向外部设计人员显示电机工作状态。通过这种方式建立模型，就可以以一种整体概念面向设计者，从而使所有参与工作的设计人员从中获得感性认识，并和顶层设计人员就各种问题进行有效的沟通。顶层设计人员实际上建立的是一个与平台无关的模型（PIM），通过模型可以进行各种方案的尝试，划分子系统，同时向子系统提出需求。

图2 复杂状态图例

在一个复杂的嵌入式系统研制过程中，为了便于管理和实现，往往需要将系统分解为多个子系统并行开发。在进行系统划分的过程中，一般会根据系统功能以及专业进行划分，而此时由于出现跨域的策划和需求，如果仅依据文档即便是进行交流，其效率仍然比较低。因此顶层设计人员将模型分配给各个专业领域的设计人员，由他们对模型进行细化，实际上这也正是子系统的设计人员进行需求分析和设计的过程。子系统的设计人员可以根据经验、需求和各种约束，进一步细化模型的静态结构和动态行为，将完成细化后的这一“虚拟产品”重新提交给顶层设计人员所构造的模型环境中进行验证。这样不但可以尽早发现过去可能只在集成时发现的问题，并且在需求或设计发生变更时，设计人员还可以快速对影响域进行评估。

图3 MDA基本流程

当前，随着技术的发展，国外系统和软件设计界提出了模型驱动体系结构（MDA）[3]。如图3所示，MDA基本可以分为两个方面，建模人员通过创建一个与平台无关的模型（PIM）来表示特定应用。而后，使用模型编译器将模型转变成一个平台特定的模型（PSM）。对于前者如前叙述。对于后者实际则是通过模型编译器将模型直接变为可部署的系统。例如对simulink中描述的模型，可以采用编译器将其转变为HDL语言，进而设计成为FPGA或者ASIC，也可以转变为基于DSP的软件代码。另一方面，将UML模型转变为C/C++/Java/Ada等语言的技术已经较为成熟，在企业级和嵌入式设计领域都已经得到应用。例如嵌入式系统设计工具rhapsody，可以根据UML描述的模型生成基于多种嵌入式操作系统的代码，只要不是在资源极度受限的情况下，可以直接应用这些自动生成的代码。对于没有操作系统的嵌入式软件，也可以采用一些开源或者商业的模型编译器将UML模型转换为8位、l6位以及32位CPU的C代码。

此外，UML提供了profile、stereotype、tag等机制供使用者进行扩展。各个领域的使用者可以采用这些机制针对自己的应用场合设计特定的建模语言以及向PSM影射的方法。通过这种方式，UML语言可以产生例如HDL、SystemC[4～5]、System Verilog以及各种硬件专有C语言等[6]。通过采用MDA，设计者可以将更多的精力集中到分析、设计以及验证上，通过借助自动化工具，可尽量将嵌入式系统的实现阶段缩短且减少人为的错误。

4 系统设计

尽管模型驱动的方式对嵌入式系统的设计有诸多好处，但是对于实现一个产品来说还远远不够。例如对于嵌入式产品相关的各类规范和法规等约束条件、可靠性要求和工艺等，采用模型都还很难表述清楚，因此模型可以作为传统技术的辅助手段，主要针对部分功能和性能进行说明。

目前比较传统的方法都是通过文档化的需求规格说明和ICD驱动设计。但是文档化的需求规格说明存在很多的缺点，首先它提供的有效信息往往淹没于大量已知的信息中，很难发现遗漏的和相互冲突的信息。研制一个复杂的嵌入式系统，设计需求本身是一个动态变化的过程，因此文档化的需求很难适应这种变化，最终的结果往往是许多需求实现先于需求提出，极大地损坏了需求的可跟踪性。

为了提供有效需求，需求规格应当满足以下几个条件：提供模板以便能有效地捕获和组织需求；能够将需求按层次列表以供分析；能够准确地定位导出需求（derived requirement）；能够按照要求对需求进行排序、过滤以及提供索引；各个层次间的需求能够链接以便提高需求的可跟踪能力；可以对需求进行版本管理能力；能够对各类需求设置属性等等。

因此需求规格不应采用文档化方式而应当采用动态方式。例如根据一个嵌入式系统的需求规格，机械设计师可以迅速提取出系统对机械尺寸的需求，电气工程师可提取出驱动电路的需求，软件工程师可提取出对软件的需求，电子工程师既可以要求只显示系统模拟输出信号数目，同时又可以一起对整个需求规格进行讨论。讨论结果生成的更改，既可以独立于其他需求独立显示出来，又可以按照格式要求融入到需求规格中，便于系统外的人员查阅和评审。此外，需求规格应当具备和模型紧密联系的能力，例如需求规格中完成的更改能够在模型中得到反映，或者是模型中进行的修改直接反映到需求规格中去。

ICD也应当具有同需求规格同样的特点，它应当具有检索、分类、排序以及过滤能力。而且ICD应当和模型紧密地结合到一起。这是因为在嵌入式系统中，系统工作往往都是由各种条件和信号驱动的，这些信号特点大多都在ICD中进行了具体的表述，因此模型和ICD中的信号如果能够双向更动即做到同步，那么设计者在模型中所作的工作更有效率。

将模型以及动态形式的需求规格与ICD相结合驱动嵌入式系统设计，设计师可以通过模型进行交流和验证，同时可以改进自己的设计。由于模型和需求规格以及ICD可以进行双向更动，因此改进内容可以在需求规格和ICD中自动修改，从而使整个设计同步进行，不会出现遗漏。还可以利用其动态需求规格和ICD的跟踪、检索、排序和过滤能力，完成模型设计很难实现的设计覆盖性检查、跟踪评估以及明晰的结构表述等。因此利用这种优势互补可以使嵌入式系统设计效率大大提高。

5 结 论

嵌入式系统设计变得越来越复杂，随着开发周期、成本和可靠性等诸多方面的压力，迫切需要出现一种新的设计方法，而采用由模型、非文档式的需求规格和ICD共同驱动嵌入式系统设计，应当是一条非常可行的途径。

[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]吴一帆，徐阳.统一建模技术研究[C].航天软件技术发展交流会，2007，北京

[3]Martin F著，徐家福译.UML精粹[M].北京：清华大学出版社，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-），男，四川人，高级工程师，研究方向为电子线路设计（e-mail：wuyf@bice.org.cn）。