CN105159670A - 一种通用座舱显示控制系统软件开发框架 - Google Patents

Abstract

本发明公开了一种通用座舱显示控制系统软件开发框架，包括座舱显示控制系统软件框架建模环境(101)、座舱显示控制系统软件设计时框架(102)、座舱显示控制系统软件运行时框架(103)。本发明为现代大中型民用飞机座舱显控系统软件开发提供一个具有高重用性、好的扩展性和易维护性的应用软件框架。大大提高了软件开发效率以及代码的复用性，对传统的航空电子系统软件开发模式和方法的进行了有效的改进，为机载航空电子系统领域软件研发提供了关键技术路线图。

Description

一种通用座舱显示控制系统软件开发框架

技术领域

本发明涉及计算机软件架构领域设计技术，特别涉及一种软件架构技术中使用的座舱显示控制系统软件开发框架。

背景技术

座舱显示控制系统是一个由多个系统、多种环境、多项任务、多种资源构成的相互关联、相互支持、相互集成和相互制约的复杂系统，具有多目标、多信息、多专业、多任务、多功能、多资源和多过程组成的复杂系统构成与管理特征。

随着座舱显示控制系统软件产品推出时间的越来越短，软件复杂度越来越大，且现在座舱显示控制系统软件开发往往要求能够实时动态地修改变动需求，安全性要求也越来越高。传统的座舱显示控制系统软件开发过程的最大特征是以源程序为开发中心，这种开发方式成本高、效率低、开发周期长、可靠性低，已经不能满足研发的要求。

模型驱动架构(ModelDrivenArchitecture，MDA)提供了应对业务和技术不断变化的开发的解决方案。MDA将业务和应用逻辑与底层平台相关技术分离开来。平台无关模型(PlatformIndependentModel，PIM)使用UML及其他建模标准定义应用或集成系统的功能和行为，然后通过MDA实现在不同类型的平台上面(例如WebService、.Net、CORBA、J2EE及其他平台)。PIM将应用的业务功能和行为与技术相关的实现代码分离，并将应用的核心与相关技术以及冗长的修改周期隔离，同时实现内部和跨平台的互操作性。通过将业务和相关技术解耦，使得它们可以在各自的领域发展：业务逻辑与业务需求契合，而技术根据业务不断发展。

发明内容

座舱显示控制系统软件具有软硬件结合紧密、软件规模大、复杂度和耦合度高的特点，随着座舱显示控制系统软件复杂性不断扩大，早期的嵌入式软件开发方法不能够完全满足嵌入式软件设计需求。如何设计与实现高质量的复杂座舱显示控制系统软件成为工业界面临的难题。为了解决现有技术的不足，本发明的发明目的在于提供一种通用座舱显示控制系统软件开发框架，能够在早期阶段对系统进行分型和验证，提高软件的质量属性，大大提高了软件开发效率以及代码的复用性，并有效的控制开发时间和成本。

本发明的发明目的通过以下技术方案实现：

一种通用座舱显示控制系统软件开发框架，包括座舱显示控制系统软件框架建模环境101、座舱显示控制系统软件设计时框架102、座舱显示控制系统软件运行时框架103；

所述座舱显示控制系统软件框架建模环境101采用UML、SysML或AADL模型根据用户描述的显控系统软件的静态结构和动态行为，建立软件模型，并抽象、定义和实现显控系统软件的基本要素和机制；

所述座舱显示控制系统软件设计时框架102用于在软件模型建立后，定制显控系统软件的业务功能；

所述座舱显示控制系统软件运行时框架103用于对定制的显控系统软件自动生成能够编译和运行在嵌入式平台中的代码。

依据上述特征，所述座舱显示控制系统软件框架建模环境101包含基于AADL的架构建模，基于SysML和UML的功能建模及验证模块，基于MARTE的非功能建模及分析模块；

所述架构建模用于供用户定义显控系统软件的静态结构；

所述功能建模及验证模块用于供用户定义显控系统软件的功能属性；

所述非功能建模及分析模块用于供用户定义显控系统软件的非功能属性。

依据上述特征，所述架构建模子模块包括系统交联关系视图、系统逻辑结构视图、系统部署视图和系统进程视图；

所述系统交联关系视图用于供用户描述显控系统软件与所有外部系统之间的交联关系；

所述系统逻辑结构视图用于供用户描述显控系统软件由哪些子系统组成以及它们之间的逻辑关系；

所述系统部署视图用于供用户在系统交联关系视图及系统逻辑结构视图的基础上定义系统架构中外部系统、外部总线、子系统及内部总线的平台相关属性，包括操作系统、总线型号、协议；

所述系统进程视图用于供用户在系统部署视图的基础上对主控子系统的各个线程与显控设计模式代理间的绑定关系。

依据上述特征，所述功能建模及验证子模块包括系统需求模型、系统用例模型、黑盒系统功能模型、白盒系统功能模型、主控制子系统功能模型：

所述系统需求模型用于根据导入的系统高层需求建立系统低层需求，使用SysML的需求图建立它们之间的追溯关系；

所述系统用例模型用于使用UML的用例图对系统用例进行建模，明确系统外部设备及参与者；

所述黑盒系统功能模型用于针对每个关键用例，使用SysML的活动图、顺序图及状态机图对黑盒系统的功能进行设计并使用Rhapsody进行验证；

所述白盒系统功能模型用于使用SysML的活动图、顺序图及状态机图对系统中各个子系统之间的交互及状态行为进行建模并使用Rhapsody进行验证；

所述主控制子系统功能模型用于将主控子系统划分为四种分析类:总线通信类、信息显示类、控制响应类及任务管理类，使用SysML的活动图、顺序图及状态机图对分析类之间的交互进行建模，并使用Rhapsody进行验证。

依据上述特征，所述座舱显示控制系统软件设计时框架模块包括架构模板、显控设计模式、复用组件三部分；

所述架构模板子模块用于描述显控设计模式及复用组件的树状逻辑关系；

所述显控设计模式用于对显控系统软件的基本要素和机制的抽象及定义；

所述复用组件用于根据对软件不同粒度的划分，提供可复用的代码单元。

依据上述特征，所述架构模板从任务合成目标、信息融合目标和结构化综合目标三个层次描述与设计模式及复用组件的树状逻辑关系；

所述任务合成目标的架构模板从系统功能任务的角度描述显示设计模式及复用组件的树状逻辑关系，任务合成目标的架构模块包括多个功能任务，以及各功能任务之间包含的关联；

所述信息融合目标的架构模板从领域实体的角度描述显示设计模式及复用组件的树状逻辑关系；

所述结构化综合目标的架构模板从系统的外部交联关系、内部逻辑结构等角度描述显示设计模式及复用组件的树状逻辑关系。

依据上述特征，所述显控设计模式分为总线通信设计模式、IO通信设计模式、信息显示设计模式、控制响应设计模式及数据处理设计模式五大类；

所述总线通信设计模式是对总线交互功能的抽象，用于定制具体总线型号、通信协议以及具体外部系统；

所述IO通信设计模式是对IO设备交互功能的抽象，用于定制内部总线型号、通信协议以及具体IO设备；

所述信息显示设计模式是页面数据显示功能的抽象，用于定制显示通信协议、页面组织定义、事件响应；

所述控制响应设计模式是外部控制事件响应功能的抽象，用于定制控制响应表，控制响应函数；

所述数据处理设计模式是数据处理功能的抽象，用于实现显示数据处理、总线数据处理以及函数数据处理。

依据上述特征，所述复用组件分为子系统组件、功能任务组件、显控设计模式组件、数据实体组件及功能函数组件；

所述子系统组件是从物理角度对显控系统软件的粗粒度划分，每个组件运行在独立进程；

所述功能任务组件是从逻辑角度对显控系统软件的较粗粒度划分；

所述显控设计模式组件是从基本要素和机制的角度对显控系统软件的较细粒度划分，合成策略包括代码嵌入、功能函数组件选用以及代码生成三种；

所述数据实体组件是从领域实体角度对显控系统软件的业务数据的更细粒度划分，封装了数据结构体定义和对数据的基本操作函数；

所述功能函数组件是在函数级别上对显控系统软件业务功能实现的最细粒度划分。

依据上述特征，所述座舱显示控制系统软件运行时框架包括初始运行时框架和已定制运行时框架；

所述初始运行时框架用于提供在没有对各个显控业务功能进行配置的初始状态；

所述已定制运行时框架用于提供对各个显控业务功能进行配置之后的状态。

依据上述特征，所述初始运行时框架包括显控设计模式组件容器、应用初始化、时钟机制实现、依赖注入机制实现、面向对象机制实现；

所述显控设计模式组件容器是设计模式组件部署和运行的环境，包括总线通信设计模式组件容器、IO通信设计模式组件容器、控制响应设计模式组件容器、信息显示设计模式组件容器；

所述应用初始化负责显控应用软件的初始化功能，包括设置时钟、设置信号量、任务初始化及创建；

所述时钟机制实现是指通过信号量控制操作系统上各个任务按频率运行的机制；

所述面向对象机制实现支持在C语言基础上提供对面向对象思想，包括抽象、封装、编译时继承、编译时多态。

本发明座舱显示控制系统软件开发框架，由于采取了以上技术措施，使用户开发所有软件共用的核心框架，确立软件系统的结构和各组件所依赖的环境；然后再递增地开发运行在核心框架之上的各种组件。实现软件产品线，大大提高座舱显示控制系统软件整体的质量属性及开发和维护效率。

可以在模型层对软件架构设计进行验证，并根据模型自动生成能够编译和运行在嵌入式平台中的代码。

附图说明

图1是本发明通用座舱显示控制系统软件开发框架的框图；

图2座舱显示控制系统软件开发框架建模环境框图；

图3座舱显示控制系统软件设计时框架框图；

图4座舱显示控制系统软件运行时框架框图；

图5座舱显示控制系统软件框架总线通信模式框图；

图6座舱显示控制系统软件框架IO通信模式框图；

图7座舱显示控制系统软件框架信息显示设计模式框图；

图8座舱显示控制系统软件框架控制响应设计模式框图；

图9为通用座舱显示控制系统软件开发框架的开发方法说明；

图10为系统交联关系视图示意图。

具体实施方式

下面对本发明做进一步详细说明。

一、框架组成

图1是本发明通用座舱显示控制系统软件开发框架(简称：CDSF框架)的框图。包括座舱显示控制系统软件框架建模环境101、座舱显示控制系统软件设计时框架102、座舱显示控制系统软件运行时框架103。

1、座舱显示控制系统软件框架建模环境

如图2所示，座舱显示控制系统软件框架建模环境101包括基于AADL的架构建模，基于SysML和UML的功能建模及验证，基于MARTE的非功能建模及分析。

1.1基于AADL的架构建模

基于AADL的架构建模包括以下四个视图:

a、系统交联关系视图:描述系统与所有外部系统之间的交联关系。

b、系统逻辑结构视图:描述系统由哪些子系统(例如MCM、IOP等〉组成以及它们之间的逻辑关系。

c、系统部署视图:在系统交联关系视图及系统逻辑结构视图的基础上定义系统架构中外部系统、外部总线、子系统及内部总线的平台相关属性，包括操作系统、总线型号、协议等。

d、系统进程视图:在系统部署视图的基础上对主控子系统的各个线程与显控设计模式代理间的绑定关系。

1.2基于SysML和UML的建模

基于SysML和UML的功能建模及验证使用IBM公司的商业建模软件RationalRhapsody，主要包括以下几个模型:

a、系统需求模型:导入系统高层需求，建立系统低层需求，使用SysML的需求图建立它们之间的追溯关系。

b、系统用例模型:使用UML的用例图对系统用例进行建模，明确系统外部设备及参与者。

c、黑盒系统功能模型:针对每个关键用例，使用SysML的活动图、顺序图及状态机图对黑盒系统的功能进行设计并使用Rhapsody进行验证。

d、白盒系统功能模型:使用SysML的活动图、顺序图及状态机图对系统中各个子系统之间的交互及状态行为进行建模并使用Rhapsody进行验证。

e、主控子系统功能模型:将主控子系统划分为4种分析类:总线通信类、信息显示类、控制响应类及任务管理类，使用SysML的活动图、顺序图及状态机图对分析类之间的交互进行建模，并使用Rhapsody进行验证。

1.3基于MARTE的建模

基于MARTE的建模使用IBM公司的商用建模软件RationalRhapsody通过导入MARTE概要文件，对系统中非功能属性进行标注，建立系统非功能模型。

CDSF框架的建模环境包括AADL建模环境、SysML建模环境、MARTE建模环境、UML建模环境及ARINC661建模环境。

●AADL建模环境

AADL(ArchitectureAnalysisandDesignLanguage，架构分析与设计语言)是一种支持对系统的体系结构进行描述的建模语言。AADL建模工具可选用开源或商业化产品。

●SysML建模环境

SysML是一种基于UML2扩展的可视化系统建模语言。SysML建模工具可选用IBM公司的RationalRhapsody。

●MARTE建模环境

MARTE(modelingandanalysisofrealtimeandembeddedsystems)是UML在嵌入式实时系统领域的扩展，支持对嵌入式实时系统的非功能属性建模。MARTE建模工具可选用IBM公司的RationalRhapsody。

●UML建模环境

UML(UnifiedModelingLanguage)是一种标准的、基于面向对象思想的可视化软件系统建模语言。UML建模工具可选用IBM公司的RationalRhapsody。

●ARINC661建模环境

ARINC661(CockpitDisplaySystemInterfacestoUserSystems，座舱显示系统到用户系统的接口)模型主要描述系统的UI(UserInterface，用户界面)。ARINC661建模工具可选用开源或商业化产品。

2、座舱显示控制系统软件设计时框架

如图3所示，座舱显示控制系统软件设计时框架与座舱显示控制系统软件运行时框架相对应，是一套已验证的、可供定制的显控系统模型，包括架构模版、显控设计模式及复用组件三类。

●架构模板

架构模板从任务(Mission)合成目标，信息融合目标和结构化综合目标三个目标层次提供可复用架构方案。任务合成目标的架构模板从系统功能任务(例如态势)的角度描述与设计模式及复用组件的树状逻辑关系；信息融合目标的架构模板从领域实体的角度描述与设计模式及复用组件的树状逻辑关系；结构化综合目标的架构模板从系统(例如EFIS、直升机、教练机等型号显控系统)的外部交联关系、内部逻辑结构等角度描述与设计模式及复用组件的树状逻辑关系。

●显控设计模式

显控设计模式是对座舱显示系统应用软件的基本要素和机制的抽象及定义，分为总线通信、IO通信、信息显示、控制响应及数据处理五大类。

1)总线通信设计模式：AFDX模式、FC模式、TTP模式、TTE模式、ARINC429(HB6019)模式、1553B模式等。

总线通信设计模式组成视图如图5所示，总线通信设计模式是对总线交互功能的抽象，是对显控应用开发中总线交互基本问题的一个通用解决方案。该类设计模式可定制具体总线型号、通信协议以及具体外部系统等。

显控应用的业务数据实体(例如航线、航路点数据)存放于数据实体区。总线通信代理按固定频率读写总线数据区，再调用总线中间件的收发函数。显控设计模式定制工具通过数据区映射机制将逻辑的总线数据区映射到该数据实体区，还支持通过共享内存区数据协议定义明确设备号与外部设备的映射关系。

该类显控设计模式中不同的设计模式就是选用不同的总线中间件。

该类设计模式的设计元素主要包括总线数据区、数据区映射机制、总线通信代理、总线数据处理函数、总线中间件以及共享内存区数据协议定义。

◆总线数据区

总线数据区是一种逻辑概念，通过数据区映射机制映射到数据实体区。总线通信代理读写总线数据区。每个通过总线连接的外部系统都有相应的总线数据区，例如惯导INS外部系统对应INS总线数据区。

◆数据区映射机制

数据区映射机制维护逻辑的总线数据区与实体数据区的映射关系，映射关系是一对多的。

◆总线通信代理

总线通信代理是实现总线交互功能的代码段，它按固定频率执行，周期读写总线数据区，并调用read_bus(总线类型,连接的外部系统,数据缓冲区)、send_bus(总线类型,连接的外部系统,数据缓冲区)、read_bus_processing(数据缓冲区,总线数据区)和send_bus_processing(总线数据区,数据缓冲区)四个接口函数执行读写总线和总线数据处理的功能。

◆总线数据处理函数

总线数据处理函数是在代理中用于对从总线读出的数据和准备写入总线的数据进行处理的接口函数，分别为read_bus_processing(数据缓冲区,总线数据区)和send_bus_processing(总线数据区,数据缓冲区)。该处理函数与数据处理设计模式关联，复用数据处理设计模式组件。

◆总线中间件

总线中间件是对具体总线板卡等硬件相关代码的封装，为总线通信代理提供总线读写功能的实现。

◆共享内存区数据协议定义

共享内存区数据协议定义明确设备号与外部系统(例如INS、AHRS)的映射关系。该共享内存区是指总线中间件所在的板卡与总线板卡之间共享的内存地址空间。

2)IO通信设计模式：RS422模式、HDLC模式、CPCI模式等。

IO通信设计模式组成视图如图6所示，IO通信设计模式是对IO设备交互功能的抽象，是对显控应用开发中IO设备交互基本问题的一个通用解决方案。该类设计模式可定制内部总线型号、通信协议以及具体IO设备等。

IO驱动不属于控制IO通信设计模式。它的作用是和具体的IO设备交互，读取设备的数据和键码内容，放置到共享内存区中。

该类显控设计模式中不同的设计模式就是选用不同的IO驱动。

该类设计模式的设计元素主要包括IO信号区、IO数据区及共享内存区数据协议定义。

◆IO信号区

IO信号区为每个IO数据区提供一个信号位，标识该IO数据区是否具有IO事件。通过IO信号区，控制响应代理不需要将所有的IO数据都读一遍并与以前的数据进行比对来确定是否有新的IO事件。

◆IO数据区

IO数据区存储了具体的IO数据。IO数据并不只是包括键码值，同时也包括如旋钮的数值、读卡器读取的数据等。

3)信息显示设计模式：ARINC661模式、自定义DF模式、页面数据模式等。

显示设计模式的组成视图如图7所示，信息显示设计模式是页面数据显示功能的抽象，是对显控应用开发中显示基本问题的一个通用解决方案。该设计模式可定制显示通信协议、页面组织定义、事件响应等。

该类设计模式的设计元素主要包括显示器、用户应用、显示通信协议、事件、命令、显示数据区以及页面组织定义。

◆显示器(Display)

显示器是负责绘制页面并展示的显示器，可接收飞行员的交互操作。

◆用户应用(UA)

用户应用负责准备显示数据，通过显示通信协议发送给显示器，以及接受从显示器传过来的交互操作事件。

◆显示通信协议

显示器和用户应用之间的信息交换需遵循显示通信协议，分为ARINC661显示、自定义DF显示以及页面显示三种。显示通信协议规定了事件和命令的传输方式。

◆事件

事件由显示器在接收用户操作后触发。

◆命令

命令由用户应用发送给显示器，主要内容为显示数据，使用自定义DF作为通信协议时，还包括页面组织定义。

◆显示数据区

显示数据区专用于存放显示数据，具体可分为页面数据(如页面号、光标位置等)和显示处理数据(经过数据处理后显示专用数据)。

◆页面组织定义

飞机显控系统的显示分为静态数据和动态数据两部分。页面组织定义明确了整个页面的布局，如坐标、图元类型及静态内容等；动态数据是不断变化的，如经度、维度等的实际数据。页面组织定义还明确了页面元素与数据实体区、显示数据区的映射关系。

◆信息显示代理

信息显示代理是实现数据显示的代码段，它可以按固定频率执行，并调用get_view_update_function(页面号)、view_processing(页面号)两个接口函数执行获取页面更新函数、页面数据处理的功能。

4)控制响应设计模式：轮询模式、事件响应模式等。

控制响应设计模式组成视图如图8所示，控制响应设计模式是外部控制事件响应功能的抽象，是对显控应用开发中控制响应基本问题的一个通用解决方案。该类设计模式可定制控制响应表，控制响应函数等。

页面号是信息显示设计模式中的元素，用于标识显示器所显示的页面。屏幕号是用来标识不同显示器硬件，由通信规约定义。

该类显控设计模式中不同的设计模式选用的是不同的触发机制。轮询模式就是按固定频率周期地执行的控制响应设计模式；事件响应模式是通过监听事件触发执行的控制响应设计模式。

该类设计模式的设计元素主要包括键码、控制响应表、控制响应函数、控制响应代理以及共享内存区。

◆键码

键码是根据硬件按钮被按压后，用于标识该按钮的唯一标识(用数字标识，在ICD中规定)。在飞机显控系统开发中，通常使用键码来确定具体按压事件的响应操作。

◆控制响应表

控制响应表维护了页面号+键码与相应控制响应函数之间的映射关系，并提供get_response_function(页面号，键码)接口函数。控制响应表内部使用表代替原来的switch/case编程方式，页面号+键码与控制响应函数之间的关系是多对一的，即允许对不同页面号+键码执行同一个控制响应函数。

◆控制响应函数

控制响应函数是对外部控制事件进行响应的业务的函数，可分为总线通信响应函数、IO通信响应函数、信息显示响应函数、数据处理响应函数及综合响应函数五类。

■总线通信响应函数与总线通信设计模式关联，功能包括总线写、总线读等，例如按压火控开火按钮，需将火控指令通过总线发送给火控外部设备。

■IO通信响应函数与IO通信设计模式关联，功能包括IO写、IO读等，例如按压飞行计划加载按钮，需读取DTD设备中的飞行计划数据。

■信息显示响应函数与信息显示设计模式关联，功能包括页面切换(修改页面号)、显示内容修改、光标移动等。

■数据处理响应函数与数据处理设计模式关联，进行数据处理。

■综合处理响应函数是结合如上四种函数，对外部控制进行响应。

◆控制响应代理

控制响应代理是实现外部控制事件响应的代码段，它可以按固定频率执行或根据中断或事件机制执行，并调用read_control_key(屏幕号)、read_input_string(屏幕号)、get_response_function(页面号,键码)三个接口函数执行获取键码、获取用户数据及键码响应的功能。

5)数据处理设计模式：

数据处理设计模式是数据处理功能的抽象，是对显控应用开发中数据处理基本问题的一个通用解决方案。数据处理设计模式从功能上分为显示数据处理设计模式、总线数据处理设计模式以及函数数据处理设计模式。

◆显示数据处理设计模式

显示数据处理设计模式与信息显示设计模式相关，用于处理显示数据，将数据实体区中数据处理并存放于显示数据区中。

◆总线数据处理设计模式

总线数据处理设计模式与总线通信设计模式相关，用于对于从总线读出的数据以及准备写入总线的数据进行处理，对总线数据区进行读写。

◆函数数据处理设计模式

函数数据处理设计模式对飞机显控系统提供其他数据处理功能。

●复用组件

复用组件是对软件不同粒度的划分，是可复用的代码单元(例如.h和.c文件)，分为子系统组件、功能任务(Mission)组件、显控设计模式组件、数据实体组件及功能函数组件。

a)子系统组件

子系统组件是从物理角度对显控系统软件的粗粒度划分，每个组件运行在独立进程(分区)上，与系统逻辑结构视图(架构模版中的结构化综合目标)中的子系统相对应。例如，EFIS系统的显示处理计算机DPU中的主控制模块MCM、输入输出模块IOP、地图模块DMM、视频处理模块VPM、数据通讯模块DCM等。

b)功能任务组件

功能任务组件是从逻辑角度对于显控系统软件的较粗粒度划分，该组件与架构模版中的任务合成目标相对应，例如态势。

c)显控设计模式组件

显控设计模式组件是从基本要素和机制的角度对显控系统软件的较细粒度划分，是显控设计模式的具体实现。

d)数据实体组件

数据实体组件是从领域实体角度对显控系统软件的业务数据的更细粒度划分，与领域实体中的通用数据(架构模版中信息融合目标)相对应，例如由航路点及航线组成的飞行计划。数据实体组件封装了数据结构体定义和对数据的基本操作函数。

e)功能函数组件

功能函数组件是在函数级别上对显控系统软件业务功能实现的最细粒度划分，是最小粒度的可复用组件。每个组件可包含一个或多个函数。

3、座舱显示控制系统软件运行时框架

如图4所示，座舱显示控制系统软件运行时框架与座舱显示控制系统软件设计时框架相对应，是一套可编译并在目标机上可运行的代码框架，分为初始运行时框架和已定制运行时框架。

●初始运行时框架

初始运行时框架是不包括显控业务功能，提供应用初始化、显控设计模式组件容器、时钟机制实现、依赖注入机制实现、面向对象机制实现等功能的可编译可运行代码框架。

a)显控设计模式组件容器

显控设计模式组件容器是指设计模式组件部署和运行的环境。设计模式组件是总线通信、IO通信、信息显示、控制响应及数据处理五类设计模式的具体实现。以总线通信设计模式组件为例，该组件包含有总线通信代理，分为读总线代理和写总线代理两种，它们分别调用read_bus(总线类型,连接的外部系统,数据缓冲区)、read_bus_processing(数据缓冲区,总线数据区)、send_bus(总线类型,连接的外部系统,数据缓冲区)和send_bus_processing(总线数据区,数据缓冲区)四个接口函数执行读写总线和总线数据处理的功能。读总线代理和写总线代理运行在不同的线程上，这两个线程及这四个接口函数的空的实现构成了总线通信设计模式组件容器。

b)应用初始化

应用初始化负责显控应用软件(子系统级别)的初始化功能，包括设置时钟、设置信号量、任务(Task，每个任务一个线程)初始化及创建。

i.设置时钟：设置系统辅助时钟执行的频率

ii.设置信号量：设置控制每个任务运行的操作系统信号量

iii.任务初始化及创建：调用由任务实现代码定义的初始化函数，并创建运行该任务的线程实例

c)时钟机制实现

时钟机制是指通过信号量控制操作系统上各个任务按频率运行的机制。频率和信号量均由应用初始化设置。

d)依赖注入机制实现

依赖注入机制是指接口与接口实现两者之间的依赖关系在编译时注入的机制。

e)面向对象机制实现

面向对象的基本要素包括抽象、封装、继承、多态。基于CDSF框架的应用建模支持面向对象方法，该机制实现支持在C语言基础上提供对面向对象思想，包括抽象、封装、编译时继承、编译时多态。

◆抽象与封装

面向对象的抽象主要是指将客观实体抽象成类，并将类实例化为对象；封装主要是指在类的定义中属性和操作封装在一起，支持数据隐藏和实现隐藏。C语言不支持类的概念，该机制实现利用C的结构体实现类的属性部分，利用C函数(以类名作为函数名前缀，显式传入this指针)实现类的操作部分。

◆编译时继承

面向对象的的继承主要是指子类可以继承父类的属性和操作。C语言不支持类和继承的概念，该机制实现利用C结构体的嵌套实现类的属性部分的单根继承，利用指向void类型的this指针支持父类操作的this指针可传入子类结构体的地址。

◆编译时多态

面向对象的多态主要是指在单一的接口后面隐藏不同的实现，即子类的操作可覆盖父类的同名操作，在运行时同一操作名可以根据对象的类型绑定不同的操作体。CDSF框架的接口与实现分离机制可用于实现C语言上的多态，但这种多态不是真正意义上的运行时多态，我们称为编译时多态。

●已定制运行时框架

已定制运行时框架是在初始运行时框架基础上，通过对架构模版、设计模式、复用组件的定制，增加了显控业务功能的可编译可运行代码框架。

二、基于座舱显示控制系统软件框架的开发方法说明

座舱显示控制系统软件框架的开发方法详细流程如图9所示，分为软件需求阶段、软件设计阶段以及软件编码阶段。

(一)、软件需求阶段

软件需求阶段需要完成以下工作：

1、导入三个顶层需求文档并建立系统需求模型

本步骤首先需要使用Rhapsody工具通过Gateway将操作手册、接口规范文档、系统规格说明书三个需求顶层文档导入到Rhapsody中，建立与之对应的低层需求，并建立顶层需求与低层需求之间的追溯关系。具体如下：

1)使用Rhapsody中的Gateway工具可以将文件格式或者使用需求管理工具维护的需求文档引用进来，并解析文档内部结构，建立系统需求。

2)为导入的需求添加顶层需<<HLL>>的构造型标注。

3)根据顶层需求的描述，建立系统低层需求，描述系统需要完成的功能细节，如“可以显示提示及告警信息”。

4)使用SysML中的需求图(RequirementDiagram)对系统底层需求与顶层需求的追溯关系标注<<trace>>构造型。

2、建立系统交联关系视图及系统逻辑结构视图

本步骤首先检索架构模板库，复用架构模板，根据系统规格说明中的描述，拖拽组件库中的组件，建立系统交联关系视图与系统逻辑结构视图。具体包含以下步骤：

1)使用CDS项目管理工具，建立显控应用软件实例项目并添加项目描述。

2)使用架构模板管理工具，检索并查看架构模板，点击“复用”按钮，即创建该架构模板的一个副本作为新项目的外部交联关系视图及逻辑结构视图。

3)使用应用实例架构定义工具，设计系统交联关系视图(如图10所示)

a)使用Device组件来表示外部系统，并使用领域实体管理工具的接口检索相应的航电设备领域实体，并建立与其的依赖关系。

b)使用Bus组件来表示外部总线，同样使用领域实体管理工具的接口检索相应的航电设备领域实体，如AFDX或A429，并建立与其的依赖关系。

c)使用System组件来表示显控系统。

d)为外部系统及显控系统建立总线端口，并分别与外部总线相连。

4)在系统外部交联关系视图的基础上，建立系统逻辑结构视图：

a)为显控系统创建子图，如果复用的架构模板则直接修改显控系统的子图(即系统逻辑结构视图)。

b)使用Device组件来表示各个非主控的子系统，并建立与领域实体的依赖。

c)使用Bus组件来表示内部总线，并建立与领域实体的依赖。

d)使用Processor组件来表示主控子系统的硬件设备，并建立领域实体的依赖。

e)使用System组件表示主控子系统的软件实现，通过应用实例架构定义工具，将组件的类型设置为“主控子系统”。

f)使用Memory组件表示各个子系统之间的共享数据区。

g)分别为各个内部设备建立总线端口，并与相应的内部总线相连。

h)分别为与主控子系统交互子系统及主控子系统(System组件)本身建立数据端口和连接。

3、建立系统用例模型以及与需求的追溯关系

本步骤首先将通过管理环境讲系统用例参与者及内部子系统导出，使用参与者建立系统用例模型，并确定系统关键用例。具体包含以下步骤：

1)通过点击项目首页的“下载参与者”按钮，可以下载包含系统参与者及CDS框架概要文件的XMI模型文件，其中包括：

a)从系统交联关系视图(AADL模型)中转换过来的标记了<<OuterSystem>>构造型的用例参与者(UML模型)。

b)从系统逻辑结构视图(AADL模型)中转换过来的标记了<<SubSystem>>构造型的内部子系统(SysML模型)。

c)CDS框架概要文件中包含系统功能模型所需要的构造型、显控设计模式中预定义的接口及事件等(在稍后章节中详述)。

2)使用Rhapsody的XMIImporter工具可以导入该模型文件，并选择需要导入的内容为Avionics概要文件以及ImportedModel包。

3)使用导入的参与者建立系统用例模型(用例图)。

4)使用SysML的需求图使用《satisfy》构造型建立系统用例与低层需求之间的满足关系。

5)明确系统关键用例，使用《Mission》构造型对对应用例进行标注。

在本阶段结束时，架构师可以从系统用例中确定关键用例。在候选架构设计与验证阶段，需要基于这些关键用例进行系统架构设计及系统功能建模及验证。

(二)软件设计阶段(候选架构设计及验证)

软件设计阶段包括两个子阶段：候选架构设计及验证子阶段以及基于候选架构的迭代式设计子阶段。本节介绍候选架构的设计及验证子阶段，主要包括以下工作：

1、针对系统与外部设备的交互，建立并验证黑盒系统功能模型。

本步骤中针对每一个系统关键用例，执行1)至8)步骤，建立黑盒系统活动图，建立黑盒系统块中的操作及属性，细化黑盒顺序图，建立黑盒内部块图，并定义状态机图，最终通过顺序图及状态机图的模型执行验证系统功能模型。最终将各个关键用例的建模合并。

1)使用Rhapsody的SE-Toolkit为每一个系统关键用例建立黑盒系统模型，包括黑盒系统块、黑盒活动图、黑盒内部块图以及黑盒块定义图。

2)分析用例，建立系统黑盒活动图，定义用例中所涉及的活动及系统与外部设备之间的交互。

3)使用ActorPin细化系统与外部设备交互的方式，包括In/Out/In&Out。

4)使用Rhapsody的SEModellingTool，选择活动建立系统用例场景(顺序图)。建模人员可以建立多个用例场景来覆盖系统运行的所有可能情况，并使用SE-Toolkit对活动的覆盖率进行分析。

5)为黑盒系统块建立操作、属性及事件，并细化系统用例场景，明确调用的函数及交互的事件。

6)建立黑盒内部块图明确系统与外部设备的交互接口及通信端口。

7)为所有外部设备块以及黑盒块建立状态机图，定义它们所拥有的状态以及基于事件或时间的状态转移。

8)使用Rhapsody执行顺序图及状态机图，通过手动创建事件来模拟外部环境及用户操作，比较实际调用顺序以及状态转移是否与设计相一致。

经过以上步骤，即对各个关键用例对进行了黑盒系统功能建模及验证。在DesignSynthesis包下建立一个白盒系统块，使用Rhapsody提供的SE-Toolkit，将各个关键用例中定义的操作、属性及事件合并在一起。

2、针对子系统之间的交互，建立并验证白盒系统功能模型。

本步骤针对已经合并了各个关键用例的系统白盒模型，建立块定义图(内部组成)，在原有黑盒活动图基础上建立带泳道的白盒活动图以及白盒顺序图，定义白盒内部块图(内部子系统交互)，并对各个子系统建立状态机图，最终通过模型执行对白盒系统功能模型进行验证。

1)使用导入的子系统，白盒系统块定义图，定义各个子系统与白盒系统之间的从属关系。

2)针对每个关键用例，沿用黑盒活动图，将活动迁移到相应的子系统泳道中，建立白盒活动图,并进一步细化每个子系统的操作以及子系统之间交互活动。

3)根据白盒活动图，使用Rhapsody的SE-Toolkit定义分配表，并将操作、属性及事件分配到各个子系统中。

4)沿用黑盒顺序图，建立白盒顺序图，对子系统之间的函数调用、事件传递进行建模。

5)沿用黑盒内部块图，建立白盒内部块图，明确子系统块之间的交互接口及通信端口。

6)对各个子系统建立状态机图，并使用Rhapsody执行顺序图及状态机图，对白盒系统功能建模进行验证。

3、针对显控设计模式，建立主控子系统功能模型

本步骤将主控子系统划分为总线通信、IO通信、信息显示及控制响应四种分析类，并将其包含的操作及属性根据不同的功能划分到相应的分析类中，并对它们进行CDS框架构造型标注，最终将模型模型导出，并导入到管理环境中。

1)分别建立四个分析类：BusInteractor,IOInteractor,InformationDisplayer以及ControlResponser，它们分别实现在CDS框架概要文件中的四个接口。

2)建立主控子系统块定义图，明确四个分析类与主控子系统块的归属关系。

3)使用Rhapsody的SE-Toolkit将主控子系统的操作、属性及事件分配到四种分析类上，其中与总线通信相关的分配到BusInteractor，与输入输出有关的分配到IOInteractor，与显示内容相关的分配到InformationDisplayer，与控制响应相关的分配到ControlResponser。

4)使用CDS框架概要文件中定义的构造型对四种分析类中的操作及属性进行标注：

a)数据区<<DataZone>>：标注分析类中的属性及关联，分别定义对应领域实体的URI、数据区的预设大小及数据区的类型，包括：总线数据区、显示数据区或实体数据区。

备注：数据区进行tags标注时，普通类型的数据区可以不标注entityURI，但是需要标记该attribute的type。数据区的类型有display、data_entity和bus。

总线数据区需要标注所有对应的领域实体的URI以分号隔开。

b)控制事件<<PilotEvent>>：标注在ControlResponser分析类中的事件上，定义用户键码及页面号。

备注：控制事件进行tags标注时，键码需要保证唯一性，以16进制进行标注；pageURI对应具体页面的名称，用户可以自行定义。

c)控制响应函数<<EventResponser>>：标注在ControlResponser分析类中的操作上，定义其与哪个控制事件的响应。

d)信息显示设计模式代理<<InformationDisplayAgent>>：标注在InformationDisplayer的操作上，定义显示的页面号以及与该页面内容相关的显示数据区。

备注：信息显示设计模式代理进行tags标注时，dataZones需要包含以上定义的数据区的URI，以分号隔开。pageURI对应具体页面的名称。

e)总线通信设计模式代理<<BusInteractionAgent>>：标注在BusInteractor分析类中的操作上，定义与哪个总线通信、通信设备、相关的总线数据区以及交互的周期频率。

备注：总线通信设计模式代理进行tags标注时，需要标注具体的频率，dataZones需要包含以上定义的数据区的URI。

5)使用MARTE中的<<TimedProcessing>>构造型为每个显控设计模式代理进行非功能时间标注，需要定义该代理的估算运行时间周期。

6)使用Rhapsody中的ExportXMIfromRhapsody工具，将包含CDS构造型标注的SysML模型导出来。

7)使用管理环境，将XMI模型文件导入，并将模型转换为CDS框架模型，显控设计模式定制工具可以解析CDS框架模型，并直接将模型中的定制信息预设到项目中，包含总线通信代理、总线数据区、显示数据区、显示页面、控制响应表以及实体数据区。

4、建立系统部署视图

本步骤需要使用架构定义工具，在系统交联关系视图与系统逻辑结构视图的基础上，为各个组件(外部系统、子系统及总线)添加平台相关信息，包括总线类型、总线协议、操作系统等。

5、显控设计模式定制及组件复用

本步骤使用显控设计模式定制工具，建立实体数据区，并在与预设的定制基础上，对每一个设计模式进行详细定制。

1)通过领域实体管理工具提供的服务，选择并建立实体数据区。

2)定制总线通信设计模式，首先建立总线通信代理，选择在系统交联关系视图中定义的外部设备，明确代理的执行频率，创建总线数据区与实体数据区映射，并从复用组件库中选择合适的数据处理功能函数组件进行总线读之后以及总线写之前的数据处理函数。

3)定制IO通信设计模式，选择在系统逻辑结构视图中定义的子系统，明确它们的设备号。

4)定制信息显示设计模式，首先建立显示数据区，建立显示页面，并根据页面组织定义为页面添加相应的显示元素，包括静态字符、动态内容以及点线圆。

5)定制控制响应设计模式，定义各个用户控制键码，选用功能函数组件作为响应函数建立控制响应表。

6、建立系统进程视图，绑定显控设计模式代理与执行线程

本步骤使用应用实例架构定义工具，在系统逻辑结构视图基础上创建多个执行线程，并将显控设计模式代理绑定到线程上。

1)为主控子系统的System组件创建子图，应用实例架构定义工具会自动创建一个主进程，并建立相应的数据端口与系统端口相连。

2)使用Thread组件为主进程添加执行线程，并创建相应端口与进程数据端口相连接。

3)使用Period属性为各个线程确定执行周期。

4)为每个线程创建子图，使用显控设计模式管理工具接口获取当前项目已定义的显控设计模式代理列表，选择并使用SubProgram组件添加到相应的线程上。

5)为各个子系统添加数据端口，并与线程数据端口连接。

7、设计并验证系统非功能需求

本步骤导出为AADL模型，并导入到OSATE建模工具中，为各线程添加延时属性后执行延时分析，并根据结果调整线程绑定关系。

1)使用应用实例架构定义工具将系统进程视图以AADL标准格式(.aaxl)形式导出，该模型中包括建模人员设置的每个线程的执行周期以及通过计算的得到的线程每个周期的预计计算时间。

2)在OSATE工具中建立AADL项目，并将AADL模型文件导入。

3)执行时间延时分析，并查看分析结果。由于线程上的预计计算时间可能大于每个线程的执行周期，因此可能出现线程延时超过100％的情况。

4)根据分析报告以及显控应用软件具体需求，选择提高线程的执行周期或者添加新的线程并将相应的显控设计模式代理迁移过去的方式来降低线程延时。

5)在应用实例架构定义工具对系统进程视图进行修改后，可以进行再次分析，直到分析结果来预想范围位置。

在本阶段结束后，可以得出通过功能及非功能验证的系统候选架构，并且已经针对关键用例对显控设计模式和复用组件进行了定制。

(三)软件设计阶段(基于候选架构的迭代设计)

在对候选架构进行定义之后，就可以基于候选架构对剩余非关键用例进行迭代式设计，可以在原有Rhapsody中建立的SysML的基础上对非关键用例进行系统功能建模及验证，也可以直接对显控设计模式和复用组件进行定制。

1、建立并验证系统功能模型(可选)

本步骤工作与针对关键用例的功能建模相似，并在已有的系统功能模型上进行迭代的设计。

1)为用例创建用例模型，并根据用例场景建立黑盒活动图，进而针对该用例定义黑盒系统块的操作、属性及事件，并定义黑盒顺序图。

2)定义该用例中黑盒系统与外部系统的交互接口，建立黑盒系统内部块图，包括通信端口及连接。

3)定义黑盒系统状态机图并执行以验证黑盒系统功能模型。

4)沿用原有白盒块定义图，建立带泳道的白盒活动图，并将黑盒系统中的操作、属性及事件分配相应的子系统中。

5)修改原有白盒内部块图，加入该用例涉及的子系统间交互，进一步修改白盒系统状态机并执行验证。

6)将主控子系统中的操作、属性及事件根据功能分配到对应的分析类中，使用CDS框架构造型标注其操作、属性及事件。

7)导出模型文件并导入管理环境。

2、显控设计模式定制及组件复用

本步骤工作与针对关键用的显控设计模式定制及组件复用工作完全一致，不在此重复。

(四)软件编码阶段

软件编码阶段主要需要完成生成代码及基于生成的代码的二次开发：

1、代码生成

在完成对所有系统用例的显控设计模式定制后，通过代码生成工具生成目标代码，目标代码中包含的内容包括以下几部分：

a)复用组件：在显控设计模式定制中选择的复用组件以及它所依赖的组件，包括接口定义头文件及接口实现源文件及若干依赖文件。

b)领域实体：在显控设计模式定制中选择的领域实体以及它所依赖的领域实体，包括定义结构体的头文件及领域实体相关操作的头文件及源文件。

c)显控设计模式代理：在显控设计模式定制中定制的各个显控设计模式代理，根据相应的代码模板生成。

d)线程注册代码：在架构定义工具中定义了主控子系统主进程中的线程及其执行周期，根据相应模板，分别生成执行线程所需的信号量及线程注册语句。

e)CDSF运行时框架：非本文工作，负责执行生成代码，并根据信号量的注册调用指定函数。

2、基于生成代码的二次开发及仿真

编码人员使用集成开发环境下载生成的代码，直接在生成代码上进行二次开发及仿真。

a)通过集成开发环境中的项目视图可检索项目，下载项目目标代码，并建立C语言项目。

b)编码人员可在目标源码基础上进行二次开发。

可以通过集成开发环境中的仿真执行按钮直接调用在仿真环境(非本文工作)中展示当前代码的运行效果。

Claims (10)

1.一种通用座舱显示控制系统软件开发框架，包括座舱显示控制系统软件框架建模环境(101)、座舱显示控制系统软件设计时框架(102)、座舱显示控制系统软件运行时框架(103)，其特征在于：

所述座舱显示控制系统软件框架建模环境(101)通过采用UML、SysML或AADL的模型根据用户描述的显控系统软件的静态结构和动态行为，建立软件模型，并抽象、定义和实现显控系统软件的基本要素和机制；

所述座舱显示控制系统软件设计时框架(102)用于在软件模型建立后，定制显控系统软件的业务功能；

所述座舱显示控制系统软件运行时框架(103)用于对定制的显控系统软件自动生成能够编译和运行在嵌入式平台中的代码。

2.根据权利要求1所述的一种通用座舱显示控制系统软件开发框架，其特征在于所述座舱显示控制系统软件框架建模环境(101)包含基于AADL的架构建模，基于SysML和UML的功能建模及验证模块，基于MARTE的非功能建模及分析模块；

所述架构建模用于供用户定义显控系统软件的静态结构；

所述功能建模及验证模块用于供用户定义显控系统软件的功能属性；

所述非功能建模及分析模块用于供用户定义显控系统软件的非功能属性。

3.根据权利要求2所述的一种通用座舱显示控制系统软件开发框架，其特征在于：所述架构建模子模块包括系统交联关系视图、系统逻辑结构视图、系统部署视图和系统进程视图；

所述系统交联关系视图用于供用户描述显控系统软件与所有外部系统之间的交联关系，

所述系统逻辑结构视图用于供用户描述显控系统软件由哪些子系统组成以及它们之间的逻辑关系；

系统部署视图用于供用户在系统交联关系视图及系统逻辑结构视图的基础上定义系统架构中外部系统、外部总线、子系统及内部总线的平台相关属性，包括操作系统、总线型号、协议；

所述系统进程视图用于供用户在系统部署视图的基础上对主控子系统的各个线程与显控设计模式代理间的绑定关系。

4.根据权利要求2所述的一种通用座舱显示控制系统软件开发框架，其特征在于：

所述功能建模及验证子模块包括系统需求模型、系统用例模型、黑盒系统功能模型、白盒系统功能模型、主控制子系统功能模型：

所述系统需求模型用于根据导入的系统高层需求建立系统低层需求，使用SysML的需求图建立它们之间的追溯关系；

所述系统用例模型用于使用UML的用例图对系统用例进行建模，明确系统外部设备及参与者；

所述黑盒系统功能模型用于针对每个关键用例，使用SysML的活动图、顺序图及状态机图对黑盒系统的功能进行设计并使用Rhapsody进行验证；

所述白盒系统功能模型用于使用SysML的活动图、顺序图及状态机图对系统中各个子系统之间的交互及状态行为进行建模并使用Rhapsody进行验证；

所述主控制子系统功能模型用于将主控子系统划分为四种分析类:总线通信类、信息显示类、控制响应类及任务管理类，使用SysML的活动图、顺序图及状态机图对分析类之间的交互进行建模，并使用Rhapsody进行验证。

5.根据权利要求1所述的一种通用座舱显示控制系统软件开发框架，其特征在于：所述座舱显示控制系统软件设计时框架模块包括架构模板、显控设计模式、复用组件三部分；

所述架构模板子模块用于描述显控设计模式及复用组件的树状逻辑关系；

所述显控设计模式用于对显控系统软件的基本要素和机制的抽象及定义；

所述复用组件用于根据对软件不同粒度的划分，提供可复用的代码单元。

6.根据权利要求5所述的一种通用座舱显示控制系统软件开发框架，其特征在于：所述架构模板从任务合成目标、信息融合目标和结构化综合目标三个层次描述与设计模式及复用组件的树状逻辑关系；

所述任务合成目标的架构模板从系统功能任务的角度描述显示设计模式及复用组件的树状逻辑关系，任务合成目标的架构模块包括多个功能任务，以及各功能任务之间包含的关联；

所述信息融合目标的架构模板从领域实体的角度描述显示设计模式及复用组件的树状逻辑关系；

所述结构化综合目标的架构模板从系统的外部交联关系、内部逻辑结构等角度描述显示设计模式及复用组件的树状逻辑关系。

7.根据权利要求5所述的一种通用座舱显示控制系统软件开发框架，其特征在于：所述显控设计模式分为总线通信设计模式、IO通信设计模式、信息显示设计模式、控制响应设计模式及数据处理设计模式五大类；

所述总线通信设计模式是对总线交互功能的抽象，用于定制具体总线型号、通信协议以及具体外部系统；

所述IO通信设计模式是对IO设备交互功能的抽象，用于定制内部总线型号、通信协议以及具体IO设备；

所述信息显示设计模式是页面数据显示功能的抽象，用于定制显示通信协议、页面组织定义、事件响应；

所述控制响应设计模式是外部控制事件响应功能的抽象，用于定制控制响应表，控制响应函数；

所述数据处理设计模式是数据处理功能的抽象，用于实现显示数据处理、总线数据处理以及函数数据处理。

8.根据权利要求5所述的一种通用座舱显示控制系统软件开发框架，其特征在于所述复用组件分为子系统组件、功能任务组件、显控设计模式组件、数据实体组件及功能函数组件；

所述子系统组件是从物理角度对显控系统软件的粗粒度划分，每个组件运行在独立进程；

所述功能任务组件是从逻辑角度对显控系统软件的较粗粒度划分；

所述显控设计模式组件是从基本要素和机制的角度对显控系统软件的较细粒度划分，合成策略包括代码嵌入、功能函数组件选用以及代码生成三种；

所述数据实体组件是从领域实体角度对显控系统软件的业务数据的更细粒度划分，封装了数据结构体定义和对数据的基本操作函数；

所述功能函数组件是在函数级别上对显控系统软件业务功能实现的最细粒度划分。

9.根据权利要求1所述的一种通用座舱显示控制系统软件开发框架，其特征在于：所述座舱显示控制系统软件运行时框架包括初始运行时框架和已定制运行时框架；

所述初始运行时框架用于提供在没有对各个显控业务功能进行配置的初始状态；

所述已定制运行时框架用于提供对各个显控业务功能进行配置之后的状态。

10.根据权利要求9所述的一种通用座舱显示控制系统软件开发框架，其特征在于所述初始运行时框架包括显控设计模式组件容器、应用初始化、时钟机制实现、依赖注入机制实现、面向对象机制实现；

所述显控设计模式组件容器是设计模式组件部署和运行的环境，包括总线通信设计模式组件容器、IO通信设计模式组件容器、控制响应设计模式组件容器、信息显示设计模式组件容器；

所述应用初始化负责显控应用软件的初始化功能，包括设置时钟、设置信号量、任务初始化及创建；

所述时钟机制实现是指通过信号量控制操作系统上各个任务按频率运行的机制；

所述面向对象机制实现支持在C语言基础上提供对面向对象思想，包括抽象、封装、编译时继承、编译时多态。