CN115185493A - 基于模型的航电系统架构设计方法 - Google Patents

Abstract

本发明公开了一种基于模型的航电系统架构设计方法，包括以下步骤：确定航电系统架构的设计需求；分别在功能层、逻辑层、物理层、消息层中建立航电系统领域所需的元模型；其中，元模型包括航电系统领域的模型元素、模型关系、模型属性和模型约束；构建设计需求与功能之间的映射矩阵，设计各层层模型，建立每一层模型之间的纵向映射关系，形成完整航电系统架构模型；其中层模型自上层向下层依次包含功能模型、逻辑模型、物理模型和消息模型。本发明根据设计需求和各层领域元模型开展航电系统架构设计建模，对需求进行全面实现、覆盖，并在多层模型上进行资源的配置，确保当前的系统架构能够符合安全性、可靠性、实时性等要求。

Description

基于模型的航电系统架构设计方法

技术领域

本发明涉及航电系统架构设计，特别涉及一种基于模型的航电系统架构设计方法，适用于航电系统架构的分布式协同设计，支持从功能、逻辑、物理、消息四层进行系统架构设计与分析，对需求进行全面实现、覆盖、仿真、验证，并在此四层架构上进行资源的配置、评估、验证及分析，确保当前的系统架构能够符合安全性、可靠性、实时性要求。

背景技术

航电系统至今已经历了独立式、联合式、综合化和高度综合化的发展历程，从各分系统相互独立发展到采用集中控制、分布处理的层次型结构。

开放式的综合模块化航空电子(Integrated Modular Avionics，IMA)系统架构是当今航电系统发展的主要趋势，旨在降低飞机全生命周期费用、整合航电系统应用、提高系统性能、解决航电系统应用各自升级的问题等。综合化模块化航电系统在本质上是一种分布式计算系统，采用开放式体系结构和标准化以及通用化的设计，提高了系统的兼容性、可移植性，并具有较高的可扩展性和可维护性，降低了系统的生命周期费用，整合和支持不同关键安全级别的航电系统应用程序。

IMA综合模块化航电平台，是一组共享的、灵活的、可重复使用的硬件和软件资源综合而成的公共资源平台，可以驻留各种应用软件以执行各种飞机机载功能。IMA系统是一个分布式实时计算机网络，提供一个共享的资源，根据多个航电功能进行分区，以提高整个系统对公共资源的利用程度，同时采用冗余机制提高其可靠性。

当前不断发展和进化的软件和微电子技术引入了越来越多崭新的飞机系统功能，同时也使机载系统复杂度成倍提升。原来分布式的架构已经不能满足现代商用飞机“轻量化，集成化”的需求，所以能用一组分布式网络架构处理器同时驻留多个应用的高性能计算平台应运而生——即IMA系统。

IMA系统采用综合化、模块化、开放式的系统结构，具有通用的集成式处理机柜、通用的操作系统、通用的容错处理、中央电源供电以及灵活的飞机应用接口。它本身不提供任何飞机级的功能，但是它提供了数据计算、数据传输和数据转换功能，同时支持健康监控和故障管理等。

英文技术术语解释对照表

英文技术术语	中文技术术语	英文全称
			IMA	综合模块化航空电子	Integrated Modular Avionics

英文技术术语	中文技术术语	英文全称
			ICD	接口控制文档	Interface Control Document
ATA	航空运输协会	Air Transport Association
			FDAL	功能研制保证等级	Functional Development Assurance Level
LRU	外场可更换单元	Line Replaceable Unit
			ADRU	大气数据基准单元	Air Data Reference Unit
IDU	综合显示单元	Integrated Display Unit
			PFD	主飞行显示器	Primary Flight Display

现有的航电系统架构设计以及分析过程，利用自然语言描述航电系统的架构，并使用VISIO等绘图工具展示图像效果，并且以一系列文件集合的形式进行组织和保存。但是这种设计形式不具备数据的原子化存储、分析、仿真等能力，协同设计的支持也比较弱。进行架构分析时，还需在其他分析工具中将架构的部分信息重新录入一遍，再开始进行后续工作，存在大量的重复性工作。

发明内容

本发明的发明目的在于提供一种基于模型的航电系统架构设计方法，通过该设计方法：

1.构建领域统一模型，在统一的模型和语义下，确定系统建模指南和设计过程；

2.基于分层的系统设计方法；

3.将系统架构设计过程和分析过程进行整合，在统一的数据中心下进行设计，无需在不同的工具间进行数据导入导出和转换；

4.实现系统设计和分析的双向循环和优化迭代，进行快速设计和反馈；

5.支持系统架构的分布式设计及团队协同办公，加速系统设计进程推进。

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

1、一种基于模型的航电系统架构设计方法，包括以下步骤：

确定航电系统架构的设计需求；

分别在功能层、逻辑层、物理层、消息层中建立航电系统领域所需的元模型；其中，元模型包括航电系统领域的模型元素、模型关系、模型属性和模型约束；

构建设计需求与功能之间的映射矩阵，设计各层层模型，建立每一层模型之间的纵向映射关系，形成完整航电系统架构模型；其中层模型自上层向下层依次包含功能模型、逻辑模型、物理模型和消息模型；航电系统架构模型中包含至少二层层模型。

本发明的有益效果在于：

1.实现功能与需求之间的可追溯性。

2.模型复用、提高效率：元模型支持特定建模、提高效率；输出的模型可支持谱系化建模。

3.一致性:输出的模型内部，及模型与ICD(接口控制文档)和文档的一致性。

4.采用关系型数据库保存建模数据，所有信息原子化，摒弃了过去基于文档的系统设计；同时基于数据库支持不同的客户端工具接入，进行协同设计。

5.领域设计操作组合化，减少过于零碎的原子设计，提高工作效率；分解设计、交互设计、变更设计，都体现了这一点。

6.借助于模型规范，批量发现设计过程中模型的不一致性问题，效率远高于基于文档的设计。基于文档的设计，依赖于大量的人工评审，才能发现问题。

7.借助于系统仿真，通过动态的设计过程模拟，挖掘出系统设计缺陷，更加直观；效果远超静态文档。

8.批量的各类报告生成，保证报告与设计信息的一致性，且将设计人员的精力真正放在设计、分析上，而不是撰写各类报告上。

附图说明

图1基于模型的航电系统架构设计方法的流程图。

图2基于模型的航电系统架构设计方法的原理图。

图3航电系统架构元模型设计流程。

图4航电系统架构模型设计流程。

图5基于模型的航电系统架构设计方法中航电系统架构模型示意图。

图6航电系统架构建模的对象关系。

图7航电系统架构设计流程。

图8建模规则校验整体架构图。

图9模型规则校验流程进度和结果展示图。

图10软件系统整体框架结构示意图。

图11导航系统功能分解图。

图12提供校准空速的计算和输出功能分解。

图13提供单通道校准空速的计算和输出功能分解。

图14功能属性的设置。

图15校准空速的功能交互图。

图16功能参数的属性设置。

图17大气数据系统逻辑定义。

图18单通道大气数据系统逻辑定义。

图19大气数据系统校准空速显示的逻辑交互。

图20大气数据系统的物理定义。

图21大气系统ADRU与IMA平台RDIU相连的物理架构。

图22大气数据系统物理架构。

图23IMA系统的物理架构。

图24消息架构模型图。

图25指示空速功能四层架构模型图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。

请参见图1-图2，本实施例提供了一种基于模型的航电系统架构设计方法，可由任意计算机语言实现，包括以下步骤：

S100、确定航电系统架构的设计需求。

设计需求包括标准需求、接口控制文档、约束需求、资源配置需求。

具体地，确定航电系统架构的设计需求的方法包括：

从航电系统架构的设计标准、设计信息、以及需求规范中获取标准需求；

以航电系统架构的原始需求为输入，根据实现角度定义航电系统架构的功能接口、软硬件接口，以形成接口控制文档(ICD，Interface Control Document)，并且获得对应于各功能、软件、硬件的约束需求(包括性能、安全性等)，以及资源配置需求。

设计需求被保存在DOORS中，设计需求的合规校验由DOORS把控。

S200、分别在功能层、逻辑层、物理层、消息层中建立航电系统领域所需的元模型。其中，元模型包括航电系统领域的模型元素、模型关系、模型属性和模型约束。

具体地，请参见图3，建立元模型的方法包括以下步骤：

建立元模型的方法包括：

S210、定义各元模型的元对象(比如，定义矩形框、正方形框、菱形框等)；

S220、定义元模型之间的关系(需要说明的是，多个元模型之间的关系也是一种元模型)。元模型之间的关系包含功能、逻辑、物理、消息这四层中各层内部之间的约束关系，以及层与层之间的约束关系，这样能够防止各层架构设计建模中出现无法满足要求或无法实现设计调整，以及防止层与层之间的映射矩阵出现错误；

S230、定义元模型的属性，设定属性的约束规则(比如，名称大于8位，重量的单位是kg或g，数值只能是正数)，并且对属性进行归类(比如，ID和名称是通用的，归类为常规属性；体积、重量、功耗、可靠性、可用性、延迟时间、重启时间是一类属性，归类为性能属性；安全性是一类属性，归类为安全属性；处理资源、存储资源、通信资源是一类属性，属于资源属性；……。)。

S240、根据元模型的对象、关系、属性和约束建立元模型。建立的元模型为符合SysML规范的航电领域元模型。

需要说明的是，元模型中定义有模型元素、类、实例。一个元模型相当于一套数据库，包括数据参数及属性。比如，直升机的转速(飞行速度为0)、喷气式飞机的飞行速度(无转速)，需要建立两个元模型。飞机的载货量、载人量，可建立一个元模型，也可以根据经验定义两个元模型。

S300、构建设计需求与元模型之间的映射矩阵，获得各层层模型，建立每一层模型之间的纵向映射关系，形成完整航电系统架构模型；其中层模型自上层向下层依次包含功能模型、逻辑模型、物理模型和消息模型；航电系统架构模型包含至少二层层模型。

在本方案中，对功能和设计需求进行关联，实现功能到需求的追溯。建立每一层模型之间的纵向映射关系，能够保证需求<->功能模型<->逻辑模型<->物理模型<->消息模型的完整追溯关系。

具体地，请参见图5-图6，在步骤S300中，还构建有功能到逻辑的映射矩阵、逻辑到物理的映射矩阵，这样便于实现模型变更。

其中，请参见图4-图6、以及图7，步骤S300具体包括以下步骤：

S310、功能架构设计建模：根据设计需求，利用功能层元模型定义航电系统架构的功能，设置功能的属性；分解功能，得到功能模型的功能分解图，并将设计需求分解为树形结构的层次状功能；根据定义和分解功能的结果确定功能参数，设置功能参数属性信息，并进行功能交互，得到功能模型的功能交互图；定义功能之间交互的接口信息，分析功能异常时的交互机制，补充更新接口信息。

请参见图5-图7，在步骤S310中，在功能分解图中，描述飞机级功能逐级分解到航电系统功能后，ATA系统内部功能分解的功能组件。功能分解用于将系统需求分解为树形结构的层次状功能。

在功能交互图中，首先定义功能交互的参数，然后构建功能交互关系。功能交互关系用于描述不同功能之间的功能参数交互。

功能架构设计建模还包括定义航电系统通用功能，支持迭代时的复用。

需要说明的是，功能架构设计的目的是达到对功能需求的追溯覆盖，解决设计与需求的一致性问题，并通过航电系统供应商按照相应系统的ARINC标准联合子系统供应商定义子系统之间的实现机制和信息接口的建模过程，解决在多个子系统之间保持接口信息一致性问题。

S320、逻辑架构设计建模：根据设计需求，利用逻辑层的元模型定义航电系统架构的逻辑组件，设置逻辑组件的属性；将功能分别分配至逻辑组件，得到逻辑模型的逻辑定义图；根据定义和分配的结果确定逻辑参数，设置逻辑参数的属性，进行逻辑交互，得到逻辑模型的逻辑交互图；将功能参数分配至逻辑参数、并将功能交互的接口分配至逻辑交互的接口，得到逻辑模型的逻辑交互图。

请参见图5-图7，在步骤S320中，在逻辑定义图中，描述实现功能的逻辑组件(软硬件配置项)，每个软硬件配置项可以承载多个功能。如果一个功能不能分配到特定的软硬件配置项中，则说明该功能需要继续进行分解。其中，逻辑为系统配置项，逻辑分解对粗粒度的逻辑项进行树形结构分解。

在逻辑交互图中，首先定义逻辑交互的参数，然后构建逻辑交互关系，用于描述不同逻辑项之间的数据收发关系。一个功能参数可以分解为多个逻辑参数。

在步骤S320中，逻辑架构设计建模还可以创建消息架构的驻留功能。

在步骤S320中，逻辑架构设计建模还包括定义航电系统通用逻辑组件，支持迭代时的复用。

需要说明的是，逻辑架构设计的目的是确保所有功能及其对应需求是可实现的，并通过定义软件之间的边界和参数接口，解决软件接口参数与系统接口参数一致性问题。

S330、物理架构设计建模：根据设计需求，利用物理层的元模型定义航电系统架构的物理设备外场可更换单元和综合模块化航空电子平台的公共物理设备，设置物理设备的属性；将逻辑组件分配至物理设备外场可更换单元，得到物理模型的物理定义图；根据定义和分配的结果进行物理设备交联，得到物理模型的物理架构图，包括：根据航电系统架构的物理设备外场可更换单元确定航电系统架构的物理设备的物理总线、以及物理设备的类型，将逻辑交互的接口分配至物理设备外场可更换单元的总线接口，设置物理总线和接口的属性，得到物理模型的物理架构图。

进一步地，请参见图5-图7，在步骤S330中，在物理定义图中，描述航电LRU类，即描述的是系统中的物理设备实体的类。在物理架构图中，描述物理设备的连接情况，物理总线可以是ARINC 664、ARINC 429、ARINC 825、模拟量或离散量等。构建物理设备实例，创建设备端口，用总线创建物理设备之间的连接关系。设定物理设备之间交互的消息路径以及参数,并创建消息架构的发送参数和接收参数。

在步骤S330中，物理架构设计建模还包括定义IMA平台公共物理设备，支持迭代时的复用。

需要说明的是，物理架构设计的目的是确保功能接口需求实现的全覆盖，并通过定义物理设备单元之间的边界和总线接口，解决多个子系统设备之间保持物理连接协调性问题。

S340、消息架构设计建模：根据设计需求、逻辑组件的属性确定消息模型的驻留功能、驻留应用，设置消息模型的属性；将逻辑组件分配置驻留功能、驻留应用，并将驻留功能、驻留应用分配至物理设备外场可更换单元；根据物理设备外场可更换单元的属性、逻辑组件之间传递的逻辑参数确定消息模型的发送参数、接收参数，并设置其属性；根据发送参数、接收参数传输时的物理设备外场可更换单元的总线的类型，对航电系统架构的消息进行打包。

请参见图5-图7，在步骤S340中，消息架构设计建模还包括：将驻留功能分配向物理设备，将收发参数分配至总线接口。

需要说明的是，消息架构设计的目的是为ICD设计提供模型基础，通过将逻辑组件映射为驻留功能，定义用于组成ARINC 664、ARINC 429、ARINC 825、模拟量、离散量消息包结构的收发参数，形成消息架构。即抽象为终端节点和节点之间的数据收发，为ICD设计过程消息组包和资源配置过程提供输入。消息架构描述的是发送方、接收方的驻留功能之间交互的数据所走的网络链路。并在后续的设计中，确认这些数据的消息帧编码格式。

在设计各层层模型时，若其中一个层模型无法满足设计需求和/或设计需求被调整，则回溯至该层模型的上一层的层模型的架构设计建模，对上一层的层模型进行变更调整；调整包括模型属性信息的调整、模型元素的合并拆分调整、模型纵向分配关系调整等。

在步骤S320中，进行逻辑架构设计建模时，若无法支持功能实现，或出现设计调整等情况，则回溯至步骤S310中的功能架构设计建模；

在步骤S330中，进行物理架构设计建模时，若无法支持逻辑实现，或出现设计调整等情况，则回溯至步骤S320中的逻辑架构设计建模；

在步骤S340中，进行消息架构设计建模时，若无法构建消息通路，或出现设计调整等情况，则回溯至步骤S330中的物理架构设计建模。

需要说明的是，回溯过去目的是为了进行变更，使得系统自上向下符合设计思路，但允许根据项目需要，先拟定出版物理架构，再开展功能、逻辑和消息的设计。

在步骤S300之后还包括以下步骤：

S400、校验航电系统的架构模型，并生成校验报告，根据各层模型中的数据类型对各航电系统的架构模型的数据进行分类整合，导出模型描述接口控制文档，进行资源配置生成；

S500、对资源配置进行计算评估，判断是否满足实时性、可靠性等要求；

S600、将符合要求的资源配置信息导入架构模型中；

S700、获取当前的航电系统架构模型的配置数据，并将当前航电系统模型和上一基线的航电系统架构模型进行对比，生成基线数据比对报告。

本实施例是以四层架构进行的举例说明，在实际应用中各层架构还可以进行进一步的拆分，例如可以是把功能架构设计改成航电级功能架构设计和航电子系统功能架构设计，也可以是其他的拆分方式。不同的拆分方式，是为了表达不同的目的。本实施例提出的四层，是一种更泛的方式，可以支持更多的情况。通过本实施例设计的航电系统架构模型可以满足以下需求：

(一)支持模型变更：

在步骤S300中，模型变更主要用于描述功能层、逻辑层的模型层级调整、模型合并、模型拆分，同时兼顾纵向分配关系的重新调整。

(1)场景1：功能合并

具体包括以下步骤：

1.选择两个待合并的功能；

2.点击合并菜单；

3.设置合并方以及被合并方，确认主次的关系；

4.功能分解关系预览，展示合并前以及合并后的效果图；

5.受影响的元素展示，主要包含：受影响的模型图，受影响的功能，受影响的参数；

6.模型纵向关系调整，调整功能到逻辑的分配关系；

7.确认模型调整；

8进行模型数据更新以及模型图更新。

进一步地，针对步骤6中的模型纵向关系调整，具体包括以下步骤：

根据步骤5的逻辑，提取出所有受影响的功能；

提取出这些功能中的叶子节点功能，只有叶子节点功能会和逻辑项进行映射；

展示功能到逻辑的映射表，根据实际映射关系进行调整；

检查功能端口和逻辑端口的映射关系，检查关系是否继续保持，有缺失进行补充。

进一步地，针对步骤7，调整如下内容：

调整模型层级关系，保证模型的层级关系是照合并后关系进行调整；

调整模型交互关系，保证模型的交互关系是按照新的模型层级关系进行交互。

(2)场景2：功能拆分

具体包括以下步骤：

1.用户选择一个功能项；

2.选择功能拆分；

3.输入要拆分增加的功能，并确认功能参数的分配关系；

4.功能分解关系预览，查看拆分前、拆分后效果；

5.受影响的元素展示，主要包含：受影响的模型图，受影响的功能，受影响的功能参数；

6.模型纵向关系调整，调整功能到逻辑的分配的关系，确保不违反模型规则(1个功能只对应1个逻辑，1个逻辑可以对应多个功能)；

7.确认模型调整；

8.更新模型数据，包括受影响的模型图内容更新。

进一步地，针对步骤6中的模型纵向关系调整，具体包括以下步骤：

根据步骤5的逻辑，提取出受影响的功能；

提取出这些功能中的叶子节点功能，只有叶子节点功能会和逻辑项进行映射；

展示一个映射界面，界面中是原有的映射关系，用户自行调整；

检查功能端口和逻辑端口的映射关系，检查关系是否依旧保持，有缺失进行补充。

进一步地，针对步骤7，调整如下内容：

调整模型层级关系，保证模型的层级关系是按照拆分后的关系进行调整；

调整模型交互关系，保证模型的交互关系是按照新的模型层级关系进行交互。

(3)场景3：逻辑合并

思路和功能合并类似。

(4)场景4：逻辑拆分

思路和功能拆分类似。

(5)场景5：模型层级调整

具体包括以下步骤：

1.在功能分解图中选择一个功能；

2.进行层级调整，为选中的功能选择一个新父亲；

3.功能分解关系预览，展示调整前和调整后的效果图；

4.展示受影响的元素，受影响的模型图，功能元素及功能参数；

5.点击确认，调整数据组织关系以及模型图展示。

(二)支持模型一致性：

在步骤S700中，请结合图8予以理解，根据系统架构建模规则，对整个系统内的模型进行自检，分析其是否符合建模规则。

若某条规则，所有涉及到的模型都符合，那么该规则状态为PASS；若有模型不符合该项规则，将所有不符合该规则的模型都罗列出来，并且以日志、报告的形式进行展现。

(1)系统设计

整体功能为两个模块，模型规则校验库和模型规则校验插件。模型规则校验库和模型规则校验插件之间通过插件交互接口进行数据交换。模型规则校验库主要提供模型校验规则的定义和模型规则校验功能。模型规则校验插件提供模型规则校验的用户界面，包含模型规则校验配置，模型规则校验清单展示，模型规则校验流程和结果展示，模型规则校验结果的导出(文档生成)。模型规则校验库和模型规则校验插件通过框架开发SDK实现数据库的访问和日志记录等操作。

(2)模型规则校验库

模型规则校验库分为模型校验规则定义、校验数据提供模块、插件交互接口三个主要部分。具体为：

模型校验规则定义主要用于定义规则校验的标准输入、输出和行为，并提供外部(第三方)规则调用的功能，定义模型校验规则的映射关系。

校验数据提供模块为校验任务提供模型信息数据源，优化数据分配，在不同校验规则但使用相同数据源的情况下集中获取数据并分配给校验任务，减少数据频繁访问的性能消耗。

插件交互接口提供插件访问接口，用于插件获取模型规则校验清单，请求模型校验任务；模型校验任务以异步方式执行，使用回调方式反馈校验进度和状态。

关于校验规则定义

1.校验规则定义

校验规则定义是描述系统对规则检查的具体实现，用于模型与校验规则的映射，实现模型与校验规则实现的解耦，也是模型校验清单返回的一部分。校验规则定义包含规则编号，规则描述，补充信息，规则所属DLL(动态链接库)，规则校验命名空间，规则校验实现类，规则模型数据源(校验规则数据结构定义)，规则校验参数类型。

2.校验规则实现

校验规则实现是模型规则校验的实际代码实现，分为通用规则、模型类型特有规则等，实现统一的校验入口，以规则编号与校验规则定义绑定，由反射工厂提供规则实现类的实例。

3.外部(第三方)规则调用

外部规则调用是指由第三方实现的模型规则校验算法调用。通过系统的校验规则实现包装外部规则算法调用过程来实现。

4.模型校验规则映射

模型校验规则映射定义了模型校验的具体规则检查内容，使用模型与校验规则定义的绑定，使用反射工厂提供的规则实现类实例完成具体规则的校验。模型校验规则映射使用父类继承的方式实现模型校验多层级的定义。

关于校验数据提供模块(即模型规则校验数据源)

1.校验规则数据结构定义

校验规则数据结构定义将多个规则属于同一类的模型数据整合为一个数据源，对该数据源使用统一结构类型定义，用于校验规则定义时对规则模型数据源的绑定。

2.模型信息数据查询

模型信息数据查询分析模型规则校验任务中的所有校验规则定义中规则模型数据源，整理、合并所有需要的数据源，并执行同意查询。减少对数据库的频繁访问。

关于插件交互接口

1.模型规则校验清单生成

模型规则校验清单生成是通过传入的插件校验请求，向校验规则定义请求计算模型规则校验清单。该清单根据模型校验规则映射定义计算所有请求中关联的校验规则，以模型校验规则映射中的父子类关系计算输出为一个树形检查清单。清单包含具体模型和对应的校验规则定义。

2.模型规则校验任务分配

模型规则校验任务分配根据插件提交的校验清单进行任务分配，任务以异步方式执行，包含进度和状态反馈。任务执行的主要行为包含：数据源请求，树形结构层级化执行校验，同层级多个规则校验分线程同时计算。

(3)模型规则校验插件

模型规则校验插件提供模型规则校验的用户界面，包含模型规则校验配置，模型规则校验清单展示，模型规则校验流程和结果展示，模型规则校验结果的导出(文档生成)。

1.模型规则校验配置

模型规则校验配置提供用户对于规则校验的常量参数配置、校验计划任务配置等。

2.模型规则校验清单展示

模型规则校验清单展示模型规则校验清单生成的结果，可以由用户筛选最终校验的规则项。

3.模型规则校验流程进度和结果展示如图9所示。

4.模型规则校验结果的导出

模型规则校验结果的导出提供校验日志、数据表(Excel)、报告(Word/Pdf)等文档形式的结果导出。

请参见图10，其为软件系统整体框架图。

航电分系统用户针对各自负责的分系统进行系统的整体四层架构建模、并对设计好的模型进行架构分析、架构对比、架构权衡、模型变更、架构模型规范性检查、基线对比等工作，并生成各类报告。在该过程中，软件系统会提供各类辅助工具，帮助用户降低设计难度、通过批量处理减少重复性劳动，提高工作效率，加快系统架构设计进度。主要插件功能有：

1.核心基础插件

负责和配置中心的数据接口对接，获取各类配置数据；提供模型封装等各类基础功能；

2.架构设计支持插件

辅助用户进行航电系统的架构设计，分别支持功能架构、逻辑架构、物理架构以及消息架构。

3.架构分析支持插件

针对功能架构、逻辑架构使用活动图、状态图分析，发现设计架构设计中的各类缺陷，完善需求确认，分析完毕后将分析结果反馈至功能架构、逻辑架构中进行架构完善。

4.架构模型变更及影响分析插件

架构模型变更及影响分析插件支持模型的变更向导过程，如模型元素的拆分、合并、层级调整、属性修改，并展示受影响的图、元素、属性，根据用户选择对被影响的图、元素和属性进行批量修改。

5.架构与需求关联支持插件

支持用户为构建的功能建立起与需求管理工具(DOORS)中需求的追溯关系，并支持从需求管理工具(DOORS)中获取插件和用户创建的功能建立起追溯关系，方便后期进行需求变更以及功能变更的影响分析。

6.架构模型及XML规范性检查插件

针对架构模型以及从中导出的基于XML格式的模型文件，按照指定的规则进行检查，生成检查报告，辅助用户快速定位到问题模型并进行变更修复。

7.架构模型版本对比插件

通过对多套架构的技术性能参数进行分析对比，从而权衡出更优的技术架构方案。

8.基线发布过程影响分析插件

将当前模型信息和上一基线的模型进行对比，生成对比分析报告，告知用户模型的变化信息。主要包含模型新增、模型修改、模型删除、模型交互变更、模型属性调整等内容。

9.模型设计模板及模型复用插件

支持从其他项目中导入已有的架构模型进行重用裁剪，支持设计师设计模型模板，直接导入项目中进行重用。

以下对该系统架构设计方法结合具体案例进行举例说明。

按照航空运输协会(Air Transport Association，ATA)的规定，航电系统可包含显示系统(ATA 31)、飞行管理系统(ATA 34)、机载维护系统(ATA 45)、综合监视系统(ATA34)、通信系统(ATA 23)、导航系统(ATA 34)、IMA系统(ATA 42)、大气数据惯性基准系统(ATA34)、客舱信息系统(ATA 46)等分系统。

关于步骤S100中的获取需求：

从标准、系统架构设计信息和主机需求规范中完成航电系统的需求捕获。

以指示空速为例，已知指示空速是由指示空速表测量得到，指示空速表是根据开口膜盒在动压的作用下产生变形，带动指针来指示表速。指针的转角完全取决于动压的大小，即指示空速的大小。

将飞机所具有的空速归化为标准海平面上飞机相对于空气的运动速度，即不考虑飞机所在处大气参数随高度而变化的空速。指示空速只与动压有关，如下式所示。

已知动压为全压和静压之差，即可在获得动压和静压后，计算得到指示空速。

本案例的需求和信息主要来自标准、系统架构设计信息和主机需求规范。

表1指示空速设计需求信息说明

关于步骤S200中元模型的构建

本案例使用的航电领域元模型是前期构建的元模型，支持IMA平台及其驻留功能、显示、飞行管理、机载维护、通信、导航、综合监视、大气数据与惯性基准的专业领域特征，可服务于不同项目，亦可支持本项目。

需要注意的是，如果项目不采用IMA架构，则需要根据需要对已有元模型进行修改。

关于步骤S300中的功能架构设计建模

功能分解：

以航电各个ATA分系统功能为顶功能，对功能进行分解。

以ATA34导航系统功能为例，面向大气数据系统可以分解为ADS(校准空速解算功能)和SADS(单通道校准空速和解算功能)的功能[两者为异构设计，以提高系统可靠性]，如图11所示的导航系统功能分解图。

ADS和SADS提供校准空速的功能分解分别如图12所示的提供校准空速的计算和输出功能分解图、图13所示的提供单通道校准空速的计算和输出功能分解图。

在功能分解后，可以对功能的FDAL(Functional Development Assurance Level，功能研制保证等级)等属性进行设置，如图14所示的功能属性的设置。

ATA 31显示系统功能可以分解为提供主飞行显示功能和提供备份显示功能等。

功能交互：

功能之间交互的参数为功能参数，根据功能定义和分解的结果，确定发送端和接收端的功能交互，并且确定功能参数，此处功能参数为L206_Indicated_airspeed。具体请参见如图15所示的校准空速的功能交互图。

根据系统需求，对功能进行设计，补充功能的属性信息，如图16所示的功能参数的属性设置。

关于步骤S300中的逻辑架构设计建模

逻辑定义：

定义设计的逻辑组件，并将功能分配至逻辑组件。

根据功能架构信息和大气数据系统、单通道大气数据系统以及显示系统的架构信息，请参见图17，在发送端的大气数据系统中定义5个逻辑组件：全压受感器、静压受感器、大气全压数据转换、大气静压数据转换、大气数据解算，其中图中第二排的5个蓝色框对应定义的5个逻辑组件。请参见图18，单通道大气数据系统中定义5个逻辑组件：单通道全压受感器、单通道静压受感器、单通道大气全压数据转换、单通道大气静压数据转换、单通道大气数据解算。在接收端的显示系统中定义2个逻辑组件：主飞行显示(PFD)、备份显示。

逻辑交互：

根据逻辑定义和分配的结果，定义逻辑组件之间交互的信息。比如，如图19所示的大气数据系统校准空速显示的逻辑交互。在构建逻辑交互后，可对逻辑参数的属性进行设置。

关于步骤S300中的物理架构设计建模

物理定义：

定义航电物理设备LRU，将逻辑组件分配至LRU，如下表2和图20所示。

表2物理实体及其对应的类和实例

物理架构：

根据航电物理设备与其他设备通信的需求，确定配置的物理端口，并通过物理总线连接形成物理架构。

以指示空速显示功能为例，根据标准和以往设计经验，分析通信数据特性，设计ATA34和ATA31分系统的LRU的物理总线接口。对发送端和接收端的物理实体建立A429物理端口，然后对发送端和接收端进行物理连接，以A429消息的命名规则进行物理总线的构建，最终形成物理总线连接关系，如图21-图23所示。

关于步骤S300中的消息架构设计建模

1)根据逻辑架构和物理架构，设计消息架构的驻留功能(Hosted Function)，将逻辑组件分配至驻留功能，同时将驻留功能绑定至LRU。

2)当LRU作为消息发送方时，将该接口发布的逻辑参数设计为消息架构的发送参数；当LRU作为消息接收方时，且该接口对应的发送参数已经创建，则将该接口接收的逻辑参数设计为消息架构的接收参数，同时建立接收参数与发送参数的关系。

3)对驻留功能类和实例填写属性。

4)对接收参数与发送参数，填写属性。

5)收发参数构建好之后，按照对应总线类型，进行消息打包。

针对逻辑参数L206_Computed_Airspeed_Data，从ATA34 NAV到ATA 31CDS的消息架构模型图如图24所示。

经过上述过程，可以构建指示空速功能的航电系统架构设计。以ADRU1发出的消息为例，其功能-逻辑-物理-消息架构如图25所示,不同架构模型之间具备特定相关关系。

可以理解的是，对本领域普通技术人员来说，可以根据本发明的技术方案及其发明构思加以等同替换或改变，而所有这些改变或替换都应属于本发明所附的权利要求的保护范围。

Claims (10)

1.一种基于模型的航电系统架构设计方法，其特征在于包括以下步骤：

确定航电系统架构的设计需求；

分别在功能层、逻辑层、物理层、消息层中建立航电系统领域所需的元模型；其中，元模型包括航电系统领域的模型元素、模型关系、模型属性和模型约束；

构建设计需求与功能之间的映射矩阵，设计各层层模型，建立每一层模型之间的纵向映射关系，形成完整航电系统架构模型；其中层模型自上层向下层依次包含功能模型、逻辑模型、物理模型和消息模型；航电系统架构模型中包含至少二层层模型。

2.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于设计需求包括标准需求、接口控制文档、约束需求、资源配置需求；

确定航电系统架构的设计需求的方法包括：

从航电系统架构的设计标准、设计信息、以及需求规范中获取标准需求；

以航电系统架构的原始需求为输入，根据实现角度定义航电系统架构的功能接口、软硬件接口，以形成接口控制文档，并且获得对应于各功能、软件、硬件的约束需求，以及资源配置需求。

3.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于建立元模型的方法包括：

定义各元模型的元对象；

定义元模型之间的关系；

定义元模型的属性，设定属性的约束规则，并且对属性进行归类；

根据元模型的对象、关系、属性和约束建立元模型。

4.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于在设计各层层模型时，若其中一个层模型无法满足设计需求和/或设计需求被调整，则回溯至该层模型的上一层的层模型的架构设计建模，对上一层的层模型进行变更调整；调整包括模型属性信息的调整、模型元素的合并拆分调整、模型纵向分配关系调整。

5.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于，在设计功能模型时包括以下步骤：

根据设计需求，利用功能层元模型定义航电系统架构的功能，设置功能的属性；

分解功能，得到功能模型的功能分解图，并将设计需求分解为树形结构的层次状功能；

根据定义和分解功能的结果确定功能参数，设置功能参数属性信息，并进行功能交互，得到功能模型的功能交互图；

定义功能之间交互的接口信息，分析功能异常时的交互机制，补充更新接口信息。

6.如权利要求5所述的一种基于模型的航电系统架构设计方法，其特征在于在设计逻辑模型时包含以下步骤：

根据设计需求，利用逻辑层元模型定义航电系统架构的逻辑组件，设置逻辑组件的属性；

将功能分别分配至逻辑组件，得到逻辑模型的逻辑定义图；

根据定义和分配的结果确定逻辑参数，设置逻辑参数的属性，进行逻辑交互，得到逻辑模型的逻辑交互图；

将功能参数分配至逻辑参数、并将功能交互的接口分配至逻辑交互的接口，得到逻辑模型的逻辑交互图。

7.如权利要求6所述的一种基于模型的航电系统架构设计方法，其特征在于在设计物理模型时包括以下步骤：

根据设计需求，利用物理层元模型定义航电系统架构的物理设备外场可更换单元和综合模块化航空电子平台的公共物理设备，设置物理设备的属性；

将逻辑组件分配至物理设备外场可更换单元，得到物理模型的物理定义图；

根据定义和分配的结果进行物理设备交联，得到物理模型的物理架构图，包括：根据航电系统架构的物理设备外场可更换单元确定航电系统架构的物理设备的物理总线、以及物理设备的类型，将逻辑交互的接口分配至物理设备外场可更换单元的总线接口，设置物理总线和接口的属性，得到物理模型的物理架构图。

8.如权利要求7所述的一种基于模型的航电系统架构设计方法，其特征在于在设计消息模型时包括以下步骤：

根据设计需求、逻辑组件的属性确定消息模型的驻留功能、驻留应用，设置消息模型的属性；

将逻辑组件分配置驻留功能、驻留应用，并将驻留功能、驻留应用分配置物理设备外场可更换单元；

根据物理设备外场可更换单元的属性、逻辑组件之间传递的逻辑参数确定消息模型的发送参数、接收参数，并设置消息模型的属性；

根据发送参数、接收参数传输时的物理设备外场可更换单元的总线的类型，对航电系统架构的消息进行打包；

将发送参数、接收参数分配至物理设备外场可更换单元的总线接口，得到消息模型的消息架构图。

9.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于在获得航电系统架构模型后，校验航电系统架构模型，并生成校验报告，根据各层模型中的数据类型对各航电系统架构模型的数据进行分类整合，导出模型描述接口控制文档，并根据需要导入模型描述文档。

10.如权利要求1所述的一种基于模型的航电系统架构设计方法，其特征在于在获得航电系统架构模型后，生成并发送多层模型的基线数据比对报告，包括：

获取当前的航电系统的架构模型的配置数据，并将当前模型和上一基线的航电系统的架构模型进行对比，生成基线数据比对报告。

Images