基于ARINC 653标准的嵌入式构件元模型研究

摘要：为了提高航电软件系统的设计和开发效率，文章利用构件化技术提出了一种适用于ARINC 653标准的嵌入式构件元模型ECOM，阐述了构件模型间的交互、构件的组合并定义了从构件模型到标准C++代码框架的映射规则。最后给出了一个构件模型到C++代码框架的映射实例。

新一代航电系统正朝着高度综合化、模块化和系统高度容错等方向不断发展与完善，随之也带来航电软件系统的设计与开发的工作量变大、难度变高、开发周期和成本难以控制等问题。急需得到新方法和技术来支持航电软件系统的设计与开发。

目前，基于AADL(Architecture Analvsis and Design Language)的航电系统建模技术和嵌入式构件化方法是最受重视的方法和技术。基于AADL的建模技术主要解决航电系统所面临的空间/时间确定性、测试与验证等问题，从而提高航电系统软件的可靠性，降低系统开发及验证成本。但是，由于目前AADL的语法、语义及扩展(Annex)机制等仍在发展与完善中，而且AADL十分复杂，它涉及的计算机理论较深，领域工程师和设计人员难以在较短时间内熟练掌握，因而难以短时间内推广。而嵌入式构件化技术是基于面向对象(Ob iect Oriented，OO)技术上的更高级抽象，它把已存在的嵌入式构件组装到正在开发的嵌入式软件系统框架结构中，从而提高软件开发效率、降低软件开发成本且经过多年的发展已经在相关领域应用实施，目前已相对成熟。所以文章拟通过嵌入式构件化的方法来解决航电系统目前亟待解决的问题。

嵌入式构件模型是基于构件化开发的前提，它规范了嵌入式构件必须遵循与其他构件实现正常交互的标准和习惯。目前比较成熟的嵌入式构件模型有飞利浦公司用于消费电子产品的Koala、ABB公司用于现场总线技术的PECOS以及比利时IWT协会赞助SEESCOA项目的CCOM模型同等等。但是，这些嵌入式构件模型均是针对各自专业领域所作出的设计，通过对这些模型的分析，发现它们并不支持航电软件系统所广泛采用的接口规范ARINC 653标准。Vanderbilt University通过对CORBA构件模型(Cobar Component Model，CCM)进行裁剪和修改，提出了适用于ARINC 653标准的ACM嵌入式构件，但是该构件模型支持跨分区间的方法调用，在运行过程可能由于分区间方法的调用造成分区间的相互影响，而这与ARINC 653标准所强调的时空分区不相符。通过对ARINC 653标准的研究提出了适用于ARINC 653的嵌入式构件元模型ECOM。

1 符合ARINC653的嵌入式构件模型ECOM

通过对ARINC 653标准进行分析，总结出符合ARINC653标准的构件必须满足以下4个条件：

1)构件必须满足实时性能的规定，因为ARINC 653是强实时系统;

2)构件必须有良好的交互语义，使其能够从底层的构件装配分析系统的属性;

3)构件必须支持静态内存分配，因为在ARINC 653中必须事先知道所有可能的任务以确保它们可以被调度;

4)构件的部署必须满足ARINC 653标准规定的时空分区的要求。

针对上述条件提出了符合ARINC 653标准的嵌入式构件模型ECOM，首先采用UML扩展机制定义了构件元模型，它是一个可视化、易读的模型，但其所表达的构件模型的语法并不严密，文章采用构件描述语言(Component Description Language，CDL)对ECOM构件模型的标准化描述，采用前后文无关文法(CFG)，并使用巴思诺范式(BNF)进行描述，为下一步ECOM构件模型的重用和组合提供帮助。由于文章主题及篇幅的原因，在文章中并不详细阐述关于CDL语法等相关信息。下文主要从ECOM构件元模型、构件交互和构件组合3个方面对其进行描述。

1.1 ECOM构件元模型

ECOM构件元模型如图1所示，采用UML扩展机制定义了元模型的所有元素及其相互关系。图中的每个概念在CDL中都有对应的关键字。

ECOM构件元模型的核心部件是构件(Component)，其次是具有结构化数据特点的构件触发器(Tigger)、属性(ComAtttibute)、接口(Interface)、端口(Port)和构件参数(Com Parameter)，其他辅助的元对象还有操作(Operation)、结构体(Struct)、联合体(Union)、枚举类型(Enumeration)、基本数据类型(Fundamental Types)。下面详细介绍结构化数据特点的元模型部件。

构件：它是元模型所要描述的核心部件。构件中可以包含零个或多个构件参数、零个或多个构件属性、零个或多个接口、零个或多个端口Port。构件中所包含的接口分为向构件外部提供服务的接口(Provide接口)和需要外部其它构件提供服务的接口(Require接口);所包含的端口分为向外部发布数据的端口(Publish端口)和接收其它构件所发布的数据的端口(Consume端口)。

构件触发器：是指构件中可以被周期性触发的内部方法。它可以是由时钟触发也可以由一个事件来触发这个内部方法，而且必须有一个有限的、非零的周期。本文提出的构件模型通过在模型中加入构件触发器并通过设置构件触发器及其配置属性来使构件满足系统要求的实时性能。例如加入周期、截止时间、构件执行的的前置条件和后置条件等来判断构件的执行与否以及故障反馈等。

构件属性：是指构件自身的状态。构件状态是由其自身的属性值反映的，可以外部观察到。状态的设置只能由构件自身进行，外部不得设置其状态，只能通过调用构件关于属性的get方法获取构件的状态。

接口：独立于构件之外定义，使接口的定义可以在不同的构件中复用。每一个构件定义必须说明自己对外提供哪些provide接口，以及需要外部提供哪些require接口。接口只有本地接口一种，即只能向同一分区中的构件提供方法调用服务。

端口：是指数据端口，用于在构件间进行数据或事件的通信。它也独立于构件之外定义，每一个构件定义必须说明自己对外提供哪些publish端口，以及需要外部提供哪些consumer端口。端口定义关联一个已定义的数据类型，比如可以是一个枚举、结构、或者联合体。端口定义为本地或远程端口，本地端口仅能为同一分区内的各构件进行数据通信，而远程端口则可以跨分区甚至跨CPU进行通信。

构件参数：用于在初始化过程中配置属性信息，用于控制构件的工作模式。由于ARINC 653中的时空分区，构件部署必须是静态内存分配，且不允许动态的分配内存，所以一旦在初始化过程中设置构件的属性则在该构件的生命周期中保持不变。

1.2 构件交互

由于ARINC 653规范所要求分区间空间的隔离，在分区间和分区内所采用的通信机制并不相同，所以定义ECOM构件间交互为远程交互和本地交互。远程交互负责分区间构件的交互而本地交互负责同一分区内构件的交互。

远程交互：构件间只能通过端口进行交互，实现分区间进程的通信。端口交互属于异步交互，一个consumer端口只能连接一个publish端口，但一个publish端口可被连接到多个consumer端口。publish端口和consumer端口之间的消息类型需要严格的事件类型匹配。在ECOM构件模型中，publish端口和consumer端口都分为周期性和非周期性，因此在构件的定义过程中应注意端口数据有效性，即数据停留在端口的时间小于用户设置的数据刷新周期时间。

本地交互：构件间不仅能够通过上述的端口通信实现分区内进程间的通信，而且能够通过接口方法调用实现进程间的同步。接口交互属于同步交互，即采用调用-返回语义，但是接口可以由关键字oneway指明其是单向的，即调用者调用该接口时，不必等待其返回结果，也可实现异步接口调用。一个require接口只能关联一个provide接口。一个prov ide接口可以关联多个require接口。由于这些交互的同步特性，调用者require接口中的方法的截止期必须大于被调用者的provide接口中方法的截止期限。

需要注意的是，虽然远程交互和本地交互均采用了端口交互，但是在交互的实现过程中远程交互依赖APEX中的分区间通讯接口实现，而本地端口则采用APEX分区内通讯接口实现。

1.3 构件组合

根据ARINC 653系统所要求的应用软件分区部署提出将构件的组合分为3类。

1)子构件：构件内部不包含其他构件的构件;

2)分区内组合构件：在ARINC 653系统中同一分区内部，由多个构件通过本地端口和接口组装而成的构件，使多个功能简单的构件构成一个功能更为复杂的构件;

3)系统构件：在ARINC 653系统中不同分区，各分区内组合构件通过构件容器端口组合成的一个完整的软件系统。

该系统构件是闭合的，所以该系统构件中的所有为其他构件提供数据端口必须绑定到其实现上，而需要其他构件提供数据的端口必须注意其数据类型的匹配。图2描述了构件层次及其端口连接。其中端口和接口的实心代表本地端接口，空心代表远程端口。

构件组合的原则是：

1)在复合构件中提供的端口与接口是由其子构件的远程端口和远程接口提供的，复合构件本身尽量避免提供在子构件没有的端口和接口;

2)复合构件内部构件的交互如果是分区内构件交互通过本地端口或本地接口直接交互;

3)复合构件内部构件的交互如果是不同分区构件的交互，则必须通过构件容器所提供的端口进行交互。

2 CDL/标准C++框架代码的生成

将上文定义的ECOM构件模型利用CDL语言进行描述并将其映射成能够运行在ARINC 653系统的C++应用成为验证ECOM构件元模型正确性和可用性的重要标准，同时也是采用构件化开发航电系统软件的关键点之一。目前，为提高效率、降低难度，采用Windows平台下Vxworks 653仿真系统对模型的正确性等进行验证，开发环境为VS2010。将构件模型的CDL文件经CDL编译器编译映射为C++框架代码，构件实现人员只需添加构件的业务逻辑处理代码就可编译运行在仿真系统中。

标准C++中存在操作、结构体、联合体以及基本数据类型的关键字，所以只需将CDL中的这些元素的关键字直接映射为C++中的关键字即可，在此并不详述。文章列举了ECOM构件关键元素的CDL文法到标准C++代码框架映射规则。

规则1：CDL中的每一个构件类型映射为C++中的一个头文件和一个CPP文件。一个构件(Compent)映射的C++的一个class，在相应的头文件中存放所映射的C++类的申明，其中声明部分包括构件参数、构件属性、端口以及接口的声明。在CPP文件中，放置该类中相关方法的实现代码;

规则2：CDL中每一个端口类型(Port)映射为C++的一个头文件，将CDL该类型的一个端口映射为该头文件中的一个class，该类包含protect数据成员，用于记录端口所要求的数据结构，同时也是要发布数据的缓冲区。在实现该端口的cpp文件中，若端口为本地端口，调用APEX中的分区内通讯接口，否则，调用APEX中分区间通讯接口实现。

规则3：CDL的每一个接口类型(Interface)映射为C++的一个头文件，将CDL该类型的一个接口映射为C++头文件中的一个class，其中接口中的操作(Operation)映射为类中pu blic的纯虚函数。在实现该端口的cpp文件中，调用APEX中的分区内通讯接口。

规则4：CDL构件的参数(ComParamater)和属性(ComAttribute)由于均只能是基本数据类型或枚举类型，对构、件中的每个参数或属性将它们映射为C++中对应的基本类型或枚举类型，并自动生成对应的set()和get()方法对其进行设定和读取。

规则5：CDL构件的触发器(Tigger)映射为C++的一个头文件，将CDL该类型映射为C++头文件的一个class，其中的方法映射为类中public的纯虚函数。在实现该方法中，调用APEX中时间管理接口来实现。

3 应用实例

以一个简化的导航系统为例，介绍ECOM构件模型及其自动生成标准C++代码框架的具体实现。

首先，为导航系统构件模型定义名为Navigation.cdl的文本文件，描述GPS构件模型经传感器构件获取实时数据，加工处理传递给导航构件处理的功能，其CDL定义如图3左部构件模型CDL描述所示，根据映射规则，将CDL文件中结构体、端口以及接口映射到名为DataType的文件中，将Sensor、GPS、NaviDIsply三个构件模型映射分别映射到以其命名的文件中，Navigation.cdl文件经编译后自动生成如下的代码框架，如图3右部给出了GPS构件的CDL描述映射为C++代码。

4 结论

文章利用构件化思想提出了一个适用于ARINC 653的构件元模型ECOM，并设计其交互规范及构件间的组合，通过将构件模型转化为C++代码框架并运行在仿真环境下，验证了构件模型的正确性，使构件开发人能够专注于构件内部的逻辑实现，提高了开发效率，降低了开发难度。在后续的工作中，还将研究在构件模型实例化时确定构件的实时特性，以满足构件开发人员灵活的定义航电系统应用软件的实时性要求，以及研究利用WorkBench工具使用ECOM构件在VxWorks653系统上开发出更加实际和复杂的航电系统应用。