文献综述.doc
- 文档编号:2499884
- 上传时间:2023-05-03
- 格式:DOC
- 页数:7
- 大小:120KB
文献综述.doc
《文献综述.doc》由会员分享,可在线阅读,更多相关《文献综述.doc(7页珍藏版)》请在冰点文库上搜索。
AADL:
一种复杂嵌入式实时系统体系结构设计与分析语言
摘要:
近年来,软件体系结构逐渐成为复杂嵌入式实时系统设计与开发中的关键技术之一。
而作为该领域的体系结构设计与分析语言标准,AADL日益受到学术与工业界的关注,并发展成为一个重要的研究方向。
分析与归纳了AADL的发展历程及其主要研究内容,从系统全生命周期的角度,综述了AADL在不同阶段的研究与应用,并对AADL的工业应用进行了概述。
最后,探讨了AADL的发展趋势。
关键词:
嵌入式实时系统;AADL;UML;ADL;全生命周期,综述
嵌入式实时系统广泛应用于航空航天、汽车控制、机器人、工业过程控制设备、医疗设备等领域,这些系统具有资源受限、实时响应、容错、专用输入输出硬件等特点,对性能、可靠性等性质有较高的要求[1],文献[2]称之为性能关键系统(PerformanceCritcialSystems,PCS)。
由于计算精度、实时响应的要求,这类系统变得越来越复杂,如何设计与实现高可靠、高质量的复杂嵌入式实时系统,并有效控制开发时间与成本,成为现在学术界和工业界的热门话题。
软件体系结构是控制软件复杂性、提高软件质量、支持软件开发和复用的重要手段之一。
研究复杂嵌入式实时系统的体系结构,不仅可以为方便软件工程师和控制、机械工程师之间的交流与协作,而且可以在早期阶段对系统进行分析与验证,有助于保证系统的质量属性。
UML以及C2、Darwin、Wright、Aesop、Unicon、Rapide等ADLs不是专门面向嵌入式实时系统领域,尚不能解决该领域的时限响应、并发处理等特定需求。
为了能够对嵌入式实时系统建模与分析,OMG先后定义了UMLprofileforSPT(Schedulability,Performance,andTime,SPT[3]),UMLprofileforQos/FT(QualityofServiceandFaultTolerance,Qos/FT[4])。
但这些方法还是很难支持基于模型、体系结构驱动的嵌入式实时系统设计与开发[5]。
2004年,SAE(SocietyofAutomotiveEngineers)组织提出嵌入式实时系统体系结构分析与设计标准AADL(ArchitectureAnalysisandDesignLanguage)[6]。
AADL借鉴了UML、MetaH[7]及多种ADLs的优点,目的是提供一种标准的、足够精确的方式,设计与分析嵌入式实时系统的软件、硬件体系结构及其性能关键属性。
在嵌入式实时系统领域,还有其他体系结构描述语言:
UMLprofileMarte(ModelingandAnalysisofReal-TimeandEmbeddedsystems,Marte[8])是OMG最近提出的嵌入式实时系统体系结构描述语言标准,Marte提供多模型多分析的模式,容易导致各种模型之间的不一致性,且语言本身还不成熟。
ESAT-ADL[9]是专门面向汽车嵌入式电子系统的体系结构描述语言。
AADL以语法简单、语义精确、功能强大的优点,日益受到学术界和工业界的广泛关注和支持。
1AADL简介
AADL是一种体系结构描述语言,主要是用于对嵌入式实时系统进行建模。
它在很多项目中都充当了核心的角色,像COTRE[Farinesetal.,2003a],ASSERT[ASSERT,2006],TOPCASED[FarailetGaufillet,2005]等等。
AADL的第一个版本于2004年11月发布,第二个版本正在制定中。
AADL标准定义了三种模型描述的方式:
文本化,XML和图形化。
正是由于这种多样化的描述方式,AADL可以被许多不同的工具所使用。
对UML的支持同样允许我们在UML的工具中插入AADL。
作为一种体系结构描述语言,AADL通过描写构件和连接来建立系统的体系结构。
一个AADL的描述由对一系列构件的描述组成,通过对这种描述的实例化来建立系统体系结构的模型。
1.1构件描述
AADL的构件被定义成两部分:
类型和实现。
一个AADL的构件拥有一个类型(componenttype)以及对应的零个,一个或者很多个实现(componentimplementation)。
构件的类型描述了外部的接口(进出端口,属性等)。
继承的机制允许我们通过对一个已知类型的扩展定义一个新的类型。
构件的实现(componentimplementation)描述了构件的内部结构(子构件,其他的属性等)。
一个构件的类型可以有多个实现,和构件类型一样,一个实现同样可以扩展为其他的实现。
1.2构件的种类
AADL定义了很多构件的种类,总的来说可以分成三大类:
软件构件,硬件构件以及组合构件。
每个种类中构件的语义和组合规则都被严格地定义。
软件构件定义了系统体系结构中的应用元素。
·数据(data)代表了在构件之间能够存储或者交换的那些结构数据。
·线程(thread)是软件应用程序的组成元素;
·线程组(threadgroup)允许集中线程用来建立系统的层次结构。
·进程(process)定义了执行线程的内存空间。
·子程序(subprogram)用来对指定程序语言的过程进行建模,例如ADA或者C。
硬件构件(或者叫执行平台构件)对硬件元素进行建模。
·总线(bus)用来描述各种类型的连接网络以及总线等。
·内存(memory)代表了所有的存贮设备:
硬盘,读写存储器等等。
·处理器(processor)用来描写含有调度程序的微处理器。
·外设(device)代表了系统体系结构内部忽略的元素,例如传感器。
组合构件(system)用来集中各种不同的构件(软件和硬件),在逻辑上以实体的形式建立系统的体系结构。
1.3特征
构件的特征(features)在构件类型(type)中声明,以这样的方式,构件类型的所有实现(implementation)给其他构件提供同样的接口。
AADL存在很多种的特征:
交互的进出端口(port),接口子程序(subprogram),子程序的参数(parameter),以及子构件的存取。
它们之间通过定义在实现(implementation)中的连接(connection)来完成。
1.4属性
属性(property)是AADL组成中重要的一个方面,它不但能够描述AADL实体的不同的特性,而且能够描述应用在体系结构中的约束条件,进而验证系统的可靠性,例如,属性被用来规定子程序的执行时间,线程的周期,数据或事件端口的等待队列协议等。
属性的声明集中在属性集(propertysets)中,有三种声明方式:
类型,常量和属性名。
一些属性已经定义在AADL标准里,用户可以根据自己的需要定义新的属性
1.5扩展
当定义新的属性不能满足用户需要时,AADL又引入了附件(annex)的概念。
附件是另一种对描述的元素添加信息的方式,和属性的不同,它仅仅能够使用在构件的声明中,并且拥有自己独立的语法规则。
附件的使用允许我们扩展AADL的语法规则以用于描述构件的动态行为。
2AADL的研究现状
在学术和工业界的共同努力下,AADL的研究已经渗透到系统全生命周期的各个阶段。
AADL的研究与传统软件工程、软件体系结构的研究一样,AADL的研究首先关注全生命周期的设计阶段,然后过渡到设计之后的实现、后开发阶段,最后再关注设计之前的需求分析阶段,从而成为覆盖全生命周期的整体框架。
表1从系统全生命周期的角度,对现有的AADL研究进行了分类与总结。
Table1ResearchandpracticeofAADLinthesystemlifecycle
表1系统全生命周期中AADL的研究与应用
Requirementphase
Systemlevelrequirements:
systemdecompositionandarchitecturalconstraints
Timingrequirements
Designphase
FunctionalityandsemanticsextensionofAADL:
behaviorannex,errormodelannex,ARINC653annexandUMLannex
ArchitectureDescriptionusingAADL
AnalysisandVerificationofAADLModel:
DependabilityAnalysis,SchedulabilityAnalysis,ModelCheckingandSimulation
Implementationphase
Modeltransfermation
Codegeneration:
C,ADA,AutoSAR
ComponentsComposition
Post-developmentphase
AADLcomponentsaresplitintospecificationandimplementation,whichcanhelpinmodifyingimplementations
Dynamicarchitecture
Architecturereconstruction
2.1需求阶段的AADL研究
在需求阶段研究AADL,主要有如下两种:
用AADL的基本元素和描述手段在较高抽象层次规约系统需求与问题;研究基于其他描述方法的需求规约自动或半自动地转换到AADL模型。
AADL提供一种面向体系结构的需求工程方法,将软件体系结构的概念引入到需求分析阶段,有助于保证需求规约和设计之间的一致性和可追踪性。
AADL用构件和连接子的概念来对系统级别的需求进行形式化规约,得到系统的层次组织结构、构件的需求规约、连接子的需求规约以及系统约束的需求规约等,例如构件接口需求规约、可靠性需求规约、实时任务的时间需求规约、资源需求规约等。
AADL能够同时获取与描述功能需求和非功能需求,对于嵌入式实时系统,非功能需求显得尤为重要。
在设计阶段,功能与非功能需求的实现将会被验证与分析。
由于UML、XUML、SysML等描述语言已经广泛应用于需求的描述,因此AADL结合这些描述语言的优势是必要的,从需求模型到AADL模型的转换成为重要的研究内容。
文献[]采用UML作为需求模型,并提出结构化转换(Structuraltransformation)作为需求模型到AADL模型转换的规则,这些规则包括UML类转换到AADLComponentType、UML类之间的组合连接(CompositionLinks)转换到AADLSubcomponent、UML类之间的直接连接(DirectedAssociations)转换到AADLPort等。
文献[]研究了将XUML和AADL集成到统一的模型驱动开发过程(MDD),通过一些经验规则来完成需求模型到AADL模型的转换。
SysML是UML在系统工程领域的改进,增加了需求图、参数图,并修改了活动图和配置图,SysML能够更好的描述系统层次的需求,文献[]采用SysML作为需求模型,并研究了SysML到AADL的模型转换。
总体上,需求阶段的AADL研究还处于初步阶段。
如何保证模型转换的可追踪性是需求模型到AADL模型的关键。
现有的需求模型到AADL模型的转换大部分只涉及如何根据需求模型构件AADL模型,但很少涉及模型转换的可追踪性。
传统软件体系结构领域,采用表格[]、UseCaseMap[]、“特征-责任-构件”映射关系[]、全局分析[]等方法来维护模型转换的可追踪性,为需求模型到AADL模型转换有很好的借鉴作用。
2.2设计阶段的AADL研究
设计阶段的AADL研究是最早被关注的。
这个阶段的研究也是最丰富和成熟的。
主要包括AADL本身的功能和语义完善、基于AADL的体系结构描述以及AADL模型分析与验证方法等。
AADL语言功能和语义的完善,首先是为了适应更多特定领域的需求,其次更是为了更好的设计、分析与验证系统的体系结构。
2.2.1AADL语言扩展
AADL核心语言(CoreLanguage)提供了一些具有精确语义的建模概念,用于实时、资源受限、安全关键以及包括特殊外设硬件的系统的描述,但它并不能适应所有的体系结构分析。
AADL提供了两种扩展方式:
引入新属性或符号;经核准的子语言(SubLanguage)扩展。
对于第一种方式,AADL标准允许用户或工具提供商为各种构件引入新的属性集,或专用于特殊分析的符号。
后者则很严格,需要先提议、发展、投票以及被核准,才能成为AADL语言的一部分,一般以AADL标准附件文档(Standardannexdocuments)的形式给出,主要包括子语言的语法,并要与AADL标准相符合。
刚开始的AADL核心标准是非图形化的,GraphicalAADLNotationAnnex[]为AADL图形化标注定义了一系列图形符号,这些符号用于表示AADL模型中构件(Components)、属性(Featrues)、连接(Connections)之间的关系。
GraphicalAADLNotationAnnex为用户提供了方便的图形视图。
TheProgrammingLanguageComplianceandAPIAnnex[]为用户提供了AADL模型到Ada、C语言源代码的转换规则。
TheMetaModelandInterchangeFormatsannex[]定义了AADL元模型以及基于XML的AADL模型交互格式。
元模型定义AADL模型的结构,也就是AADL规约的对象表示(Objectrepresentation)。
这些对象表示可以用一种标准的的交互格式保存成XML文档。
这种交互格式能够使得支持XMLSchema或XMI的不同工具能够对AADL模型进行互操作。
Errormodelannex(2006)[]定义了一些能够规约冗余管理、风险管理的属性,使得用户能够对系统的安全性、可靠性、完整性、可用性以及可维护性进行定性与定量分析。
该Annex提供了一个子语言可以为每个构件定义errormodel。
AADL一般通过规约模式变化(Modechanges)来描述事件响应、模式依赖流程来描述子程序调用等行为,而构件的实际行为则要用目标执行语言来描述,例如C或Ada。
为了能够对行为进行精确分析,法国IRIT提出了Behaviorannex[]。
Behaviorannex采用扩展Mode自动机的方法,对Thread、subprogram构件的动态行为进行描述与分析,并保证与AADL执行模型的语义一致。
但由于目前的Behaviorannex只能描述一些简单行为,并且没有给出Behaviorannex的形式语义,需要进一步研究与扩展Behaviorannex的描述能力。
随着AADL逐渐成为工业界的实际标准,对AADL扩展的需求会更多,来适合不同的应用需求。
在嵌入式实时系统领域,AADL成熟的应用于航空与航天领域,例如,ARINC653是重要的航空电子标准,Honewell实验室目前正在研究与开发AADLARINC653annex,研究AADL模型与ARINC653标准之间的转换[]。
由于AADL属于高层体系结构规约,在嵌入式自动控制领域应用还较少,这就需要与其他领域的方法和标准结合,例如AADL与OSEK[]、AutoSAR[]、EAST-ADL[]等标准的集成。
AADL还可以与UMLMarteProfile[]等标准集成。
为了支持通用领域的应用,EdwardColbert研究了AADLUMLProfileannex[],可以与UML进行集成。
2.2.2AADL形式语义
在AADL标准中,软件构件、硬件构件、系统构件以及连接的语义都是用自然语言来定义的。
构件包括一个类型Type和一个或多个实现Implementations,构件接口、构件交互都给出了完整定义。
但我们知道,很多ADLs都定义了构件及其构件交互的形式语义。
例如,Darwin使用Pi演算作为形式语义模型、Wright采用CSP作为形式语义模型、Rapide使用偏序时间集(Partiallyorderedeventsets)描述构件的语义。
形式化方法能够给出更精确的语义,同时有助于体系结构规约的验证与分析。
因此,研究AADL的形式语义是十分必要的。
AADL标准本身提供了使用混成自动机(HybridAutomata)描述Threads的执行语义。
AADL的创始人PeterH.Feiler等正在利用一些形式化方法给出构件交互(ComponentInteractions)的时序语义。
法国IRIT实验室采用动作时序逻辑描述语言TLA+对AADL执行模型的形式语义做了初步的研究[],目前只对通过端口的构件间通信(Communicationthroughports)、通过共享变量的构件间通信(Communicationthroughsharedvariables)、抢占式调度策略(PreemptionSchedulingstrategy)的语义进行了形式描述,目的是为了能够更好的验证体系结构性质以及为AADL的执行平台开发提供形式规约。
通过我们的研究表明,由于AADL的构件种类(Categories)、属性(Properties)、规则(Rules)和约束(Constrains)很多,AADL还有很多语义需要形式化。
1)目前AADL通过一些规则来描述构件组合(ComponentComposition),每种构件都有相应规则,因此构件组合非常复杂,尤其构件是可以扩展的,更加增加了构件组合的复杂性[]。
因此,需要研究AADL构件层次组合(ComponentsHierarchicalComposition)的形式语义。
2)AADL构件可以标注非功能属性,AADL标准也只是给出了一些规则,各种构件能够标注什么样的属性,某个属性能否被哪些构件标注。
所有属性构成属性集合(PropertiesSet),根据属性集合可以进行非功能属性分析。
文献[]提出AADL属性定义不清晰,主要表现在构件类型与属性关系不清晰以及属性集合与非功能属性分析关系不清晰。
因此,需要研究AADL属性定义的形式语义。
2.2.3AADL模型分析与验证
在早期进行体系结构分析与验证,能够尽早发现系统设计的潜在错误。
主要通过分析与验证AADL模型,预测系统的质量属性。
传统的体系结构分析方法一般分为两类:
基于形式化、模拟仿真方法;基于场景分析、调查等手段。
目前对AADL模型进行分析与验证主要是采用形式化方法。
法国LAAS实验室研究了基于随机Petri网的AADL模型可靠性分析(DependabilityAnalysis)[],提出将AADL系统体系结构模型和AADL系统Errormodel结合作为AADL可靠性模型,并转换成GSPN可靠性模型,然后进行可靠性分析。
Pennsylvania大学研究了AADL模型的可调度分析(ScheduabilityAnalysis)[],提出将AADL模型转换成时间进程代数ACSR,并基于工具VERSA进行可调度分析、时间分析。
可调度分析一般是基于模型检测方法,存在状态空间爆炸问题。
法国Brest大学LISYC实验室FrankSinghoff等人提出采用仿真的方法对AADL模型进行可调度分析,并开发了Cheddar[]工具,Cheddar是一个开源的实时系统调度分析工具。
由法国巴黎电信研究的Ocarina[]工具,能够对AADL模型进行处理、形式模型产生、可调度分析以及代码生成。
在实时系统形式验证方面已经取得了很多重要研究成果,例如瑞典Uppsala大学WangYi等研究的基于扩展时间自动机网的模型检测方法及其工具UPPAAL[],可调度分析工具TIMES[]、CATS[]。
法国LAAS实验室研究的基于时间petri网的模型检测工具TINA[]。
这些都可以作为AADL模型分析与验证的方法与工具。
由于复杂嵌入式实时系统对性能、安全性、容错等其他性能关键属性有较高要求,因此会需要更多不同的模型分析与验证方法。
2.3实现阶段的AADL研究
从高层的系统体系结构层次到系统实现层次的有效转换,是研究复杂嵌入式实时系统体系结构的意义所在。
目前的研究主要包括基于AADL的模型驱动开发以及代码生成。
(1)基于AADL的模型驱动开发
AADL被证明是嵌入式实时系统领域较好的建模语言,而模型驱动开发(ModelDrivenDevelopment,MDD)正在成为主流的开发过程,文献[]提出AADL与MDD结合,能够使得AADL得到广泛使用。
模型转换(ModelTransformation)是MDD的核心,传统MDD定义了三个层次的抽象:
平台独立模型(PlatformIndependentModel,PIM)、平台特定模型(PlatformSpecificModel,PSM)以及代码(Code)。
一个PIM可以转换为一个或多个PSM,并在转换规则中加入平台相关细节。
PSM到Code的模型转换则是在转换规则中加入执行细节。
根据嵌入式实时系统的特殊需求,文献[]给出了基于AADL的模型驱动开发过程:
1)获得AADLPIM模型。
主要是将AADL与UML结合起来使用,根据AADLUMLProfileAnnex,将AADL版型(Stereotype)标注在UML模型上,这样的UML模型作为AADLPIM。
例如,每个构件用UMLClass来表示,并标注构件类型(Thread、Process等)。
2)利用功能转换(FunctionalTransformations)规则,转换成AADLPSM。
3)利用非功能转(Non-FunctionalTransformation)换规则,将PSM转换成AADL分析模型(AnalysisModel),可以进行可调度、性能分析。
4)转成可执行代码。
MDD已经成为相对独立的软件工程领域,研究者提出了很多MDD方法和自动化工具,例如OptimalJ[]。
在自动化工具的支持下,通过平台提供的转换模式实现从PIM到PSM的转换,并允许用户修改PSM以加入更多的细节。
这些研究成果对基于AADL的模型驱动开发方法有很好的借鉴意义。
(2)代码生成
代码生成(CodeGeneration)主要研究从AADL模型到可执行代码的生成规则、方法、工具以及语义一致性验证等。
从软件体系结构到实现的过程中,借助一定的中间件技术,体系结构更容易映射成相应的实现。
目前可以生成的程序语言有Ada、C、C++、Java-RTSJ(RealTimeSpecificationforJava)等。
法国巴黎电信研究开发的Ocarina[],支持从AADL体系结构描述生成Ada语言,这些Ada应用是运行在PolyORB[]中间件基础之上的,同时支持生成POSIX和RTEMS[]平台之上的C代码。
STOOD[]是支持AADL、UML2.0、HOOD、HRT-HOOD等建模方法的商业设计与开发环境,支持C/C++,Ada代码生成以及HTML、RTF、MIF等文档的生成,还支持Ada、C代码到AADL体系结构规约的逆向转换。
法国IRIT正在研究AADL体系结构描
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 文献 综述