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

空间控制技术与应用Aerospace Con tro l and Applicati o n 第34卷 第1期2008年2月模型驱动的嵌入式系统设计吴一帆,张毅玲,周世安(北京控制工程研究所,北京100080)摘 要:随着嵌入式系统设计周期越来越短,功能越来越复杂,越来越多领域的设计人员参与设计,市场需求导向致使需求变更越来越多,以传统文档形式的需求来驱动开发已根本不能满足时间和成本方面的要求。

本文提出了采用可执行模型、动态需求规格和接口控制文档共同作用的驱动嵌入式系统设计方法,它能够较好地满足目前系统设计的要求。

在文中,我们首先介绍了当前嵌入式系统设计中存在的一些问题,然后介绍了模型驱动设计的方法、语言和优点,并对动态需求规格和接口控制文档的执行给出了建议,最后得出模型驱动的嵌入式系统设计是一种行之有效途径的结论。

关键词:模型驱动;统一建模语言;动态需求规格;接口控制文档中图分类号:TP3 文献标识码:A 文章编号:1674 1579(2008)01 0060 05M ode lD ri ven Em bedded Sy ste m D eve l op m entWU Y ifan,Z HANG Y ili n g ,ZHOU Sh ian(B eijing Institute o f Control Engineeri n g,B eijing 100080,China)Abst ract :This paper presen ts a m e t h od for developm ent of e m bedded syste m s .It addresses issues ho w to desi g n a m ulti technolog ies syste m w ith he l p o fm ode,l specs and interface contro l docum ents(I C D ).Theex isti n g proble m s w ith the desi g n are first analyzed .Then the paper addresses the issues that m ode,l acti v e specs and I CD can drive the deve l o pm ent o f e m bedded syste m s effectively during t h e design phase .F i n all y ,so m e usef u l conclusions for t h e e m bedded syste m developm en t driven by m odel are g i v en .K eyw ords :m ode l dri v en ;UM L ;active spec ;I CD收稿日期:2007 12 09作者简介:吴一帆(1972-),男,四川人,高级工程师,研究方向为电子线路设计(e ma i:l w uy @f bice .org .cn)。

1 引 言目前嵌入式系统设计越来越复杂,已经涉及到计算机系统、电子、电气、信号处理、自动控制、软件以及机械设计等多个领域。

这些领域的设计师共同合作才能完成任务,同时还要兼顾成本、时间和可靠性等多个方面的约束。

对于这类涉及到多个专业领域的系统研制,其中一个很大的风险就是各个专业领域的设计人员往往只擅长本领域的知识,而却对其他专业领域了解较少,因此各个接口之间很容易出现错误,尤其在系统设计经常出现变更的情况下,这种问题更为严重。

针对这些问题,在嵌入式系统设计中往往采用迭代的开发方式,这些方式采用基于模型的方法进行预先验证。

例如硬件设计师采用saber 、pSpice 等仿真器或者面包板等工具对硬件产品或部分电路进行预先实现和测试。

机械设计师采用支持三维模型的设计工具进行设计,并通过三维模型与其他领域设计师进行交流。

通过这种方式,设计师预先就可验证并且同时提供用于共同交流的平台,能够有效地降低研制过程的风险。

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

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

本文中,描述了在嵌入式系统的自顶而下的设计中,如何采用模型辅助产品的开发。

其中最重要的一点就是,如何将模型、需求规格以及I CD结合起来驱动嵌入式系统的设计。

2 问题描述与定义实现一个复杂的嵌入式系统,需要多个设计领域的设计师相互配合才能够完成。

如果设计过程完全采用瀑布模式的开发方式,这些设计师的设计成果只会在最后的系统实现阶段进行系统集成,这时大量系统集成的问题才能出现。

而上层需求定义不明、理解偏差、需求遗漏以及不同领域之间配合失误或者接口出现偏差等是出现很多问题的根源。

如果想控制好嵌入式系统的整个研制过程,就需要控制好各个部分的研制过程。

各专业领域人员对于一个嵌入式系统理解是不同的(视图不同)。

硬件设计人员熟悉的嵌入式系统是硬件电路;软件设计人员熟悉的嵌入式系统即嵌入式软件;而系统设计者熟悉的则是各种算法以及各种控制逻辑的结合体。

所有设计人员都认可的是系统物理外观及动态行为 嵌入式系统通过外部事件作用和条件变化,改变自身状态,并完成对外部的反应。

所有设计人员通过观察嵌入式系统对外部的反应,都可以了解基本的任务内容。

因此在这个层面上视图是统一的,进行交流是最有效率的。

3 模型驱动设计从以上分析可以看到,嵌入式系统在顶层进行建模十分必要。

实际上很长时间以来,在顶层设计中,针对自动控制和信号处理应用都会采用算法工具建立模型,验证设计方案是否正确。

但是一个嵌入式系统一般不会仅仅由算法构成,往往是算法(顺序工作方式)和逻辑(应激工作方式)的结合体,需要用静态结构和动态行为对模型进行描述。

目前的顶层模型往往仅是基于算法和静态结构模型,针对系统动态行为 例如控制逻辑缺乏有效的方法进行描述。

在顶层利用语言描述任务,这种语言需要具备两个特点:一是需要有较高的抽象能力;一是应当具备相当严格的语义。

具备较高的抽象能力才能帮助设计人员对系统和问题进行有效地描述,例如采用C++/HDL这样的语言描述系统不但繁琐,而且涉及到实现细节以至于干扰正常设计工作。

采用自然语言描述系统,尽管其抽象的能力可以很高,但是语义却很难做到严格,因此完全采用自然语言描述系统往往存在二义性或者不完备性,并且难以验证,对系统设计的合理性帮助不大。

完全采用形式化的语言如Z语言提出需求规格,尽管语义严格,但是较为晦涩,推广有较大的难度。

UML从1997年确立为标准以来,经过10年的发展已经升级至UML2.1。

尽管最初其应用的主要对象是软件设计,但是随着应用越来越广泛和逐渐发展成熟,已经开始进入到硬件及系统设计领域。

目前OMG(制订UM L标准的组织)和I NCOSE合作基于UM L制订了系统建模语言Sys ML(基本上是UML的子集)语言,UM L/Sys M L俨然成为了系统设计主流语言之一。

UML是一种基于图形的语言,包含了13种形式化和非形式化的图形,可以用来描述静态结构和动态行为。

例如设计者可以采用UM L中的用例图(U se Case)对需求分析的结果进行规格化说明;采用类图、复合结构图和部署图进行系统级静态结构描述;此外可以采用活动图、时序图以及状态图进行系统的动态行为描述。

UM L具有很高的抽象能力,例如如果采用文字对某一个通讯方式进行描述,可以写成如下方式:系统每30m s进行一次通讯,通讯成功后,错误计数器清零,设置速率更新标志为真;如果通讯失败,在错误计数器计数为零的情况下,进行串口初始化,并且计数器计数递增一次,如果计数器不为零,则计数器计数同样递增一次,0.5m s后再次通讯,当错误计数器计数大于5时,系统不再进行通讯,同时关闭时钟中断。

图1为采用UML中的状态图描述系统进行通讯的动态行为。

采用状态图形式的模型可视性!61空间控制技术与应用34卷大大增强,而且由于状态图是一种形式化的描述方式,因此可以相当严格地描述系统动态行为。

同时由于是形式化描述,就可以采用形式化验证技术和工具,在不输入任何测试向量的情况下对系统进行测试,可以发现逻辑上出现的死锁或者未达状态等问题。

图1 通讯状态图再以状态图为例说明UM L的描述能力,状态图支持并发!和层次!,状态并发!可以降低状态爆炸的可能性,而层次!则可以隐藏底层复杂的逻 辑,因此可以描述非常复杂的动态行为。

如图2所示,它描述的是一个电子控制系统中某一个部件的一个工作状态,这个控制逻辑如果采用文字形式进行描述,要表达清楚则非常困难。

UML不适合描述算法,因此将擅长描述算法的语言与UML结合构建模型是一种极佳的选择。

文献[2]采用s语言(si m uli n k支持)和UM L以及快速原型工具进行联合完成电机控制器顶层的建模工作。

在模型中由si m ulink完成闭环算法,而采用基于UML的工具rhapsody完成控制以及故障处理逻辑的设计,快速原型工具提供命令面板和仪表。

电机控制器模型虽然包含算法和控制逻辑,但是都已经通过快速原型工具封装在一起,通过面板接受外部的命令,通过仪表向外部设计人员显示电机工作状态。

通过这种方式建立模型,就可以以一种整体概念面向设计者,从而使所有参与工作的设计人员从中获得感性认识,并和顶层设计人员就各种问题进行有效的沟通。

顶层设计人员实际上建立的是一个与平台无关的模型(PI M),通过模型可以进行各种方案的尝试,划分子系统,同时向子系统提出需求。

图2 复杂状态图例在一个复杂的嵌入式系统研制过程中,为了便于管理和实现,往往需要将系统分解为多个子系统并行开发。

在进行系统划分的过程中,一般会根据系统功能以及专业进行划分,而此时由于出现跨域的策划和需求,如果仅依据文档即便是进行交流,其效率仍然比较低。

因此顶层设计人员将模型分配给各个专业领域的设计人员,由他们对模型进行细化,实际上这也正是子系统的设计人员进行需求分析和设计的过程。

子系统的设计人员可以根据经验、需求和各种约束,进一步细化模型的静态结62第1期吴一帆等:模型驱动的嵌入式系统设计构和动态行为,将完成细化后的这一 虚拟产品!重新提交给顶层设计人员所构造的模型环境中进行验证。

这样不但可以尽早发现过去可能只在集成时发现的问题,并且在需求或设计发生变更时,设计人员还可以快速对影响域进行评估。