1 引言

在当今时代，产品中的软件占比不断攀升，电子零部件数量也日益增多。飞机制造商与众多其他制造企业一样，正面临着产品复杂度持续增加和全球市场竞争愈发激烈的双重挑战。在产品交付终端用户前，对其进行精准的规格定义、设计以及严格验证，成为每个行业都必须直面的关键任务。这要求企业不断提升效率、保持高度谨慎，避免因开发过程中的失误，致使最终产品出现定价不合理或质量不达市场标准的情况。鉴于安全和环境因素的考量，航空航天产品还需遵循法规和监管机构制定的严格要求。

设想这样一个工程场景：受客户需求驱动以及官方规定的限制，需要在现有产品基础上增添新的功能或特性。这不仅需要实施并集成新的设备与软件，还得确保为终端用户提供全面的培训服务，同时编制详尽的使用、维护和认证文档。

开发项目的生命周期起始于文字描述，终结于产品交付客户投入使用。显然，依据所选用工程方法的差异，项目执行方式也各不相同，如图1所示。功能的完善需借助一系列活动来实现，相较于传统的以文档为核心的方法，建模、仿真和分析等手段能够更高效地推动功能走向成熟。采用基于模型的开发（MBD）模式，可提前开展部分验证和确认工作，大大增加了在早期发现缺陷或需求理解偏差的概率。

以该示例为指引，深入研读本文，将有助于我们全面且深入地探究实时、安全关键和嵌入式系统领域中开发工作的各个层面。

为支持复杂产品的开发，众多方法和语言在学术文献中被提出，并在工业界得到了广泛评估。近年来，基于模型的开发（MBD）作为一种通过增强规范清晰度、提升一致性和强化验证支持来有效管理复杂性的手段，受到了广泛关注。

因此，本文的核心在于将工程设计问题归纳为开发项目中所运用的技能、工具和过程实施之间的权衡关系。

1.1 问题领域

本文聚焦于如何借助“基于模型的系统工程”实现高效的优质产品开发，重点探究在大型开发组织采用基于模型的方法时所涌现的问题。技术领域锁定在航空航天范畴，涵盖嵌入式和物理系统（航空电子设备和飞机子系统）的集成。该问题与多种系统工程实践紧密相关，具体表述为：

如何基于涵盖硬件和软件系统的模型方法，实现从（抽象的）概念评估到（详细的）开发，再到持续工程的高效转变？

对上述问题中的关键部分进一步阐释如下：

高效过渡

：指前序活动产生的信息能够在后续活动中顺畅流转，且不会出现严重的理解偏差。

概念评估

：在项目早期，从多个备选方案中进行对比和筛选，此时信息往往不够详尽，具有一定的抽象性。

（详细的）开发

：在选定概念的基础上，逐步补充技术细节，并针对细节进行相关决策。

持续工程

：对现有产品进行优化升级，在此过程中会涉及详细信息和概念信息的综合运用。

基于模型的方法

：一种以模型为核心而非依赖文档的工程工作模式。模型以特定格式存储信息，这些信息可用于分析和文档编制。

应用领域

：包含硬件和软件的系统，也称作混合或异构系统。硬件不仅包括计算机硬件和电子设备，还涉及活塞、泵、轮子等机械、流体或结构硬件。

本文着重围绕基于模型的方法展开研究，由此衍生出一系列值得深入探讨的问题，例如“怎样的模型架构才是最优的？”以及“在特定场景下如何选择合适的建模技术？”。这些问题与系统工程实践紧密相连，如图2所示，本文将对部分内容展开讨论。

为实现经过验证的解决方案的复用，会构建组件库。其目标之一是利用模型在比现有方法更高的抽象层面上优化系统设计。未来的建模技术需要在同一模型中更全面地展现系统的各个方面。为此，需使模型（或元模型）与经过验证的适用开发过程和标准相契合。

1.2 贡献

该领域的众多研究项目能够展示强大的技术和方法，并通过小案例或解决特定的窄领域问题来验证其有效性，但在扩大规模以适用于工业生产方面的关注相对较少。本研究将可扩展性作为重点关注方向之一，期望研究成果能够广泛适用于不同层次的员工，而非局限于毕业生或资深工程师。

本文全面调研了不同的建模技术、建模领域及其集成情况。从建模技术与工具的融合，以及基于模型的方法融入开发过程两个维度展开研究。本文的贡献在于将新兴的模块化技术与基于模型的系统工程相结合，并着重突出可扩展性，具体体现在大型系统、大型组织以及不断增长的工程信息数据集等方面。基于工具和相关技术/方法对建模领域进行定义，为分析现有工程环境或规划新环境的搭建提供了基础。期望本文及类似研究成果能够为航空航天、汽车或其他从事嵌入式系统开发的企业在未来集成开发环境（IDE）的设计方面提供参考。

1.3 研究方法

本研究对与飞机/航空电子系统工程相关的基于模型的技术、工具和标准进行了系统调查。该研究领域具有多学科交叉的特性。研究重点并非实际的系统或系统模型，而是关注那些能够支持工程师构建和运用模型的现有技术和工具。

根据[Muller 2004]的分类，本研究属于元2活动，如图3所示。元0是实际的产品创建和系统模型开发；元1是用于创建和管理产品（包括相关模型）的开发方法；元2则是本文的核心研究内容，即对元活动中可用的方法和工具进行探究。在元2层面，明确了用于比较工具和方法的研究方法。

鉴于本论文面向工业应用，重点关注新兴和成熟技术在工业大规模应用中的情况，因此基于学术报告和工业经验进行推理证伪的方法是合适的，并被选为本研究的方法。

1.4 论文大纲

本文由一篇扩展摘要和五篇论文构成。摘要的其余部分安排如下：第2章介绍了本研究的技术领域，包括航空航天、航空电子以及影响嵌入式系统和安全关键系统领域开发方法的技术标准。第3章阐述了系统工程学科，以及开发过程模型/标准，还有基于模型的方法对该学科的支持作用。

第4章详细讲解了基本建模概念和适用的建模技术，第5章描述了如何将工具和技术融入工程开发环境。第6章阐述了引入基于模型的方法在组织变革和战略方面的影响。最后，第7章对研究成果进行评估和讨论，总结全文。

2. 航空航天与航空电子学导论

航空航天时代已走过了一百多个春秋。伴随新技术的不断成熟并融入航空航天领域，众多新兴学科为新一代产品的研发贡献力量。如今，已无人能精通航空航天项目的所有知识，这一领域的工作成为了多学科交织的挑战，必须依靠团队协作才能推进。于是，系统工程这一整合性学科应运而生，它将复杂的整体挑战拆解为一个个相对简单的工程问题。系统工程团队统筹技术领域，制定新的、尽量独立的工程任务，并确立通用规则。航空电子学作为其中一个重要的技术领域，借助新一代计算机、通信硬件、软件语言及开发工具，实现了迅猛发展，逐渐演变成一个 “多学科融合的学科”。

如今人们所熟知的航空电子学，其发展历程约为航空航天的一半。简单来讲，航空电子学就是应用于飞机的电子设备，航空电子系统的核心功能是通信（Communication）、导航（Navigation）和监视（Surveillance），即CNS。与诸多现代产品类似，部分基于软件的新技术不仅催生了新的设计方案，还促使设计工作采用全新的方式。本章将介绍航空电子学的发展背景，以及在基于现代模块化架构进行开发时所面临的挑战。

2.1 航空航天构件的背景

设计并制造一款复杂产品，往往需要数百人参与，从最初的产品构思到推向市场，可能历经数年时间。因此，将其合理分解为更简单的部分至关重要。从某种意义上说，项目的成功与否，很大程度上取决于分解结构（即架构）对开发工作的支持程度。架构设计旨在定义系统中的主要构件，运用抽象和分解的方法，明确各部分及其相互连接关系。系统可被视作各部分及其相互关系的集合来进行分析。

然而在许多情况下，问题会从各个部分转移到它们之间的连接上，而这些连接依然错综复杂。这些连接将系统逻辑与物理、化学、电磁学、电子学等用于具体实现的知识领域综合起来。为航空电子应用构建系统架构时，也遵循这一逻辑，其中总线协议已演变成一种 “组件”。

实践证明，模块化方法能够通过组合不同的构件，设计出满足多样需求的产品。模块化还提升了开发、生产、维护、重用及回收的便捷性。在开发过程中，模块化使得并行工程得以实现，各团队可相对独立地并行处理系统的各个部分或模块。在生产环节，模块化允许并行装配，即模块可在最终产品总装前单独进行预装配，正如[Blackenfelt 2001]所述。

从生命周期的视角审视一个不断演进的系统架构时，很难预测并提出可持续的技术解决方案。随着系统中软件和（或）电子部件占比的不断提高，架构的选择与维护成为未来的关键问题。合理的设计能够增强构建先进功能的能力，网络架构和组件的选择也会对成本产生影响。系统架构已成为复杂可配置产品中愈发重要的组成部分。

因此，一方面，构件的引入（即模块化）简化了复杂产品的管理；另一方面，接口和配置（表格）处理工作却日益复杂，本文将对此展开深入探讨。

2.2 萨博、鹰狮战机与工程挑战

本文的大部分工作及灵感都源自瑞典萨博航空系统公司的开发项目。JAS 39“鹰狮”轻型战斗机常被用作大型（复杂）系统/产品建模的参考，见图4。在此，先简要介绍一下萨博公司和“鹰狮”战机。

图：作为系统模型的鹰狮战机（对飞机系统的理解，秒杀大多数非航空航天的机械博士）

萨博公司专注于飞机系统的开发与生产，过去十年的主打产品是“鹰狮”系统，涵盖飞机、集成传感器、武器，以及地面支持、操作支持和训练设备。传统上，该公司主要参与少数大型项目，与单一客户——瑞典空军联系紧密。然而，萨博航空系统公司的商业环境正发生多方面的变化：

公司正在推进新产品开发和生产项目，周转周期更短，无人机项目（Unmanned Aerial Vehicle）。

“鹰狮”项目逐渐拓展到多个客户的出口市场，这促使萨博公司改进对产品变体的管理，以及对旧配置的升级工作。

客户期望萨博公司主动确定、资助并开发新能力，而非延续传统的客户付费开发模式。

市场更倾向于签订完整系统的合同，而非零部件合同，例如期望获得集成解决方案，而非分别签订飞机和支持设备的合同。

早期的价值创造以及与供应商和整个供应链的沟通，正发挥着愈发关键的作用。

鉴于上述变化，提升工程生产力和质量的需求变得极为迫切。引入基于模型的系统工程（MBSE），如统一建模语言/系统建模语言（UML/SysML），被认为极具潜力。建模和仿真也被视为在协同产品开发的供应链中实现早期验证和价值创造的关键要素。

萨博航空系统公司在1994年至2000年间开展了一项重要的内部变革计划——EMPIRE。该计划与“精益飞机研究计划”（LARP，位于瑞典皇家理工学院）和“精益飞机倡议”（LAI，位于美国麻省理工学院）相关。通过EMPIRE项目，萨博公司引入了一系列系统工程技术和工具，以及配套的支持流程和方法。此后，公司在系统工程领域持续推进变革计划，为后续的工程支持和流程改进奠定了基础，涵盖需求管理、产品数据管理，以及图形建模和代码生成等方面。萨博航空系统公司目前正在推进的方法和工具变革计划总的来说就是在实践MBSE。

2.3 飞机与航空电子架构

接下来，将简要回顾核心航空电子架构不同代际的发展历程及设计原则。本节末尾，还将对飞机系统进行定义，并介绍一种对飞机系统进行分类的方法。

2.3.1 核心航空电子架构的历史

20世纪50 - 60年代，航空电子架构由独立的系统构成，采用点对点连接方式，如图5左侧所示。当时，通信通过模拟电压、继电器或开关触点等进行单向传输。

随着更多系统的加入，驾驶舱变得愈发拥挤，控制装置、显示器、继电器和布线的重量也不断增加。为提升功能，系统间需要共享更多信息。从20世纪70年代初开始，数字计算机的应用开启了更灵活的信息处理方式。不过，那时信息传输仍以模拟方式为主，需要A/D和D/A转换器。

微处理器的问世，推动了航空电子技术的飞速发展，实现了数字形式的数据传输。模拟系统在较大温度范围内运行时存在的偏差和漂移问题得到缓解。数字解决方案还支持双向数据交换，串行数据链路成为标准配置。20世纪70年代后期，大部分信息传递采用基于串行数据链路的数字通信设计。

通过共享互连介质（采用并行通信链路），“带宽与重量比” 大幅提升，1553数据总线由此诞生，其架构布局见图5右侧。子系统之间现在能够按规定顺序相互传输数据，这不仅减轻了系统重量，还增强了系统的灵活性：新设备的修改或添加不再是集成过程中的难题。

显示技术的进步，使以更灵活的方式展示更多数据成为可能。人机界面（HMI）越来越多地基于软件设计，可看作是一个独立的子系统。关于 “集中计算程度”，出现了多种设计理念。许多飞机制造商采用分离或分散的航空电子架构，为特定的飞机功能或子系统配备专用的电子控制单元（ECU）。例如，萨博航空系统公司在战斗机航空电子核心功能（如导航、通信、显示和武器控制）的设计中，选择将计算资源集中在一个（中央计算机）或一组有限的中央处理器（CPU）中，这种架构被称为集成架构，见图6。如今，大多数算法和子系统间的数据交换都能在中央计算机内完成，这不仅缩短了时间关键型计算的延迟，还简化了接口处理。整个系统的大部分信息都存储在同一个软件组件（计算机软件配置项，CSCI）中，信号/数据集成也因此得到简化。像传感器数据融合这类功能，在集中式架构中更易于实现。

随着新一代CPU硬件性能的提升，规模达百万行代码（MSLOC）级别的大型软件组件得以构建。然而，系统规模的扩大也带来了可靠性方面的问题：

执行依赖性

：若一个算术运算出现故障（如除以零或数据超出范围），整个子系统将崩溃，计算机需重启。局部故障处理难度增大。

关键程度依赖性

（执行依赖性的结果）：CSCI中的所有软件都必须按照相同的（最高）设计保证等级（DAL，详见第27页 “设计保证等级的定义”）进行开发，即便只有部分功能至关重要。这意味着需要进行更多测试，进而增加了开发时间和成本。

开发依赖性

：由于大型CSCI中所有软件的构建（编译和链接）是作为一个整体活动进行的，所有开发团队必须同步工作。

安全依赖性

：在构建、测试或调试过程中，难以限制对功能/代码中保密部分的访问，而这些操作本不应如此复杂。

在商业航空领域，由公务机领域引领，基于商用现货（COTS）产品的集成模块化航空电子（IMA）架构逐渐发展起来，并被应用于军事领域。

在IMA架构中，共享计算资源依旧是集中式的，但会通过配置表明确分配给 “应用程序”（见图7中的A1 - A6）。这些共享资源包括计算处理器、通用通信网络和通用I/O单元。在分配过程中，可通过控制或更改配置表，灵活地动态管理空闲资源。借助[ARINC - 653]分区技术，不同关键程度/DAL级别的应用程序可安全隔离，在同一物理资源中托管。其原理是在空间和时间上进行物理分离（即内存地址和执行时间框架）。ARINC - 653对软件模块的分离，极大地降低了依赖性，减少了集成架构的部分弊端。

在ARINC - 653的语境下，“砖墙分区” 这一术语用于强调其强大的分离和保护机制，见图8。该技术能确保操作系统（OS）一个分区中的系统事件不会干扰另一个分区中的事件，这与现代操作系统通过虚拟机（VM）砖墙分区提供安全性的原理类似。之所以称为虚拟，是因为每个分区看起来都像是一台独立的计算机。

架构框架的进一步演进是分布式集成模块化航空电子（DIMA），它允许多个分布式计算单元以更灵活的方式托管应用程序。不过，本文将不再深入讨论DIMA技术。

2.3.2 数据总线标准

如前文所述，MIL - STD - 1553B是军事航空电子领域的主导标准，其主要特性如下：

配置

：双向，配备中央总线控制器（BC）

比特率

：1 Mb/s

远程终端（RT）数量

：31

MIL - STD - 1773B是适用于光纤的等效标准，对高强度辐射电磁场（HIRF）具有更强的抵抗力。

在商业航空电子领域，ARINC - 429是颇受欢迎的总线标准之一。它采用名为Mark 33数字信息传输系统（DITS）的单向标准。ARINC - 429是一种两线差分总线，可将单个发射器或数据源连接到一个或多个接收器或数据汇。它有12.5 kb/s和100 kb/s两种速度可选。

ARINC 664基于IEEE 802.3以太网，利用商用现货（COTS）硬件，降低了成本和开发时间。基于ARINC 664的AFDX（航空电子全双工交换以太网）是专为安全关键应用设计的确定性总线。AFDX由空中客车公司为A380开发，能提供有保障的带宽。它采用星型拓扑网络，最多可连接24个终端系统到一个交换机，且每个交换机可与网络上的其他交换机桥接。通过这种结构，AFDX减少了布线，减轻了飞机重量。

此外，还有许多其他数据总线标准是针对不同目的制定的，其中不少被定义为ARINC标准，但本文不再一一赘述。

2.3.3 飞机系统

在核心航空电子系统发展的同时，其他飞机系统，如燃油系统、电源系统或任务计算系统的设计和开发也在紧密协同推进。航空电子系统负责为其他系统提供通信/控制手段、导航数据和可靠的计算资源等。

依据[Moir 2004]的分类，飞机系统可分为以下几类：

机身/结构

（如机身、机翼和空气动力学相关部分）

飞行器系统

（如燃油、推进和飞行控制等系统）

航空电子系统

（如导航、控制与显示和通信系统）

任务系统

（如武器、数据链和任务计算系统）

对于众多工程师而言，特定子系统的设计和开发工作通常在单一领域内开展。这些系统与工程师所学的知识领域或职业发展方向相契合。然而，集成问题愈发受到关注。例如，设计显示系统的工程师需要了解整个武器系统的相关知识，包括其驱动要求、生命周期考量以及产品（甚至产品系列）的配置管理策略。

3. 基于模型的开发

在当今的开发和制造领域，随着系统和产品模型所承载的信息量不断攀升，其对于企业的价值也日益凸显。模型的类型丰富多样，广泛应用于从成本估算到备件物流等诸多方面。本文着重聚焦于系统模型，这类模型代表的系统由硬件、软件，以及在适用场景下的人机交互共同构成，飞机的燃油系统或导航系统便是典型例子，如图9所示。一个完整的飞机模型是由多个这样的系统模型组合而成，尽管其复杂程度更高，但本质上仍属于系统模型范畴。在抽象层面，这些系统模型明确了各部分的名称以及它们之间的相互关系，这些内容共同构成了系统架构或结构。当进一步融入功能、流程以及物理方程等详细信息后，模型便具备了预测性能和动态行为的能力，从而转化为仿真模型。

此外，本文也会简要提及其他类型的模型，如成本模型和元模型（论文[III]对元模型有专门的深入探讨）。

基于模型的开发方法多种多样，具体的选择取决于应用领域、产品复杂程度，同时也会受到历史和组织因素的影响。下面将详细介绍一些与飞机和航空电子设备开发紧密相关的方法。

3.1 建模方法简介

在工程领域，模型以各种形式长期存在并发挥着重要作用。关于“模型”的定义，存在多种表述，较为普遍的一种是：模型是对真实或想象系统的简化呈现，它围绕一个或多个明确的目标，展现出该系统的核心特征 。[Larses 2005]

在工程师的工作实践中，模型的应用十分广泛。例如在构建物理模型或原型时，工程师会借助模型来模拟真实系统的特性；在使用数学公式或书面文本进行表达时，模型以符号的形式辅助思考和分析；随着计算机技术的发展，计算机辅助工程（CAE）工具成为了工程师运用模型的有力助手。语义不够明确的方框图就是一种符号模型，而形式化的符号模型，也被称为数学或分析模型，在解决工程问题方面，具有强大的功能，能够帮助工程师更清晰地理解问题本质并找到解决方案。

对于基于模型的系统工程（MBSE）和基于模型的开发（MBD），以及它们之间的关系，有诸多不同的定义。在本文中，对它们的定义如下：

MBSE

：这是一种工程策略，它借助一个核心模型来全面捕捉需求、架构和设计等方面的信息，为系统工程活动提供有力支持。

MBD

：基于具有明确预定义语义和语法的抽象表示展开开发工作，并依靠工程工具提升开发效率。

二者关系

：MBSE的原理为MBD的实施提供指导，确保开发过程更加科学、高效。

以模型作为核心信息源，在基于模型的开发方法中，选定的建模技术需要在三个关键“应用点”发挥作用，才能充分实现其价值，如图10所示。以模型M为核心，其在工程活动中的应用主要体现在以下三个方面：

促进理解

：通过清晰的结构、统一的图形符号或精确的数学表达式，帮助工程师更深入地理解工程问题，找到有效的解决方案。

便于沟通

：借助通用的符号或语言，以及直观的模型可视化展示，实现工程团队成员之间的高效沟通与协作。

数据处理

：伴随新的工程工具、元模型、数据库以及分析技术的不断涌现，更多的信息能够被存储和分析。如今，即使是普通的计算机，也具备了强大的数据处理能力，能够对系统或产品的多个方面进行深入分析。

在一个完善的建模方法体系中，必须对这三个应用点给予全面支持，因为整个建模过程的有效性取决于其中最薄弱的环节。

除了MBD和MBSE，还有一些与之含义相近的术语，如基于模型的设计（MBD）、模型驱动的系统设计（MDSD）以及基于模型的工程（MBE）。在这些术语中，MBSE的涵盖范围最为广泛，它贯穿了产品从最初设计到最终退役的整个生命周期。

术语定义

本文所使用的术语（除非另有特殊说明），其基本定义主要依据航空航天标准[ARP 4754, 1996]和[ARINC 653, 2006]。这些标准不仅是航空航天工程的基础，也为本文的研究提供了重要的参考依据。在这些标准中出现且本文使用，但未明确给出定义的术语包括：需求、验证、实施、集成、安全和规范。以下是一些有明确定义的术语：

3.2 系统工程

在本文的研究范畴中，系统工程（SE）被视为一种与具体技术学科无关的通用工程活动。它的主要任务是实现工程与项目管理接口的有机融合，同时整合不同技术学科的工作，确保整个项目的顺利推进，具体关系如图11所示。

对SE的这种理解主要基于国际系统工程协会（INCOSE）的定义以及INCOSE系统工程手册[INCOSE 2007]。

SE所涵盖的活动通常包括：

规范与需求管理

：明确项目的具体要求和规范，确保项目开发方向的准确性。

产品分解与架构

：将复杂的产品分解为多个相对简单的部分，并设计合理的架构，提高开发的可管理性。

工程预算管理

：对重量、功率、散热等工程预算进行有效管理，合理分配资源。

建模、仿真与优化技术

：运用建模和仿真技术对项目进行分析和优化，提高项目的性能和可靠性。

信息处理与控制

接口

：管理系统各部分之间的接口，确保信息的顺畅传递。

变更

：对项目中的变更进行有效控制，降低变更带来的风险。

配置

：合理配置系统资源，提高系统的适应性。

可追溯性

：建立需求、设计、测试等环节之间的可追溯性，便于项目的管理和维护。

风险状态与控制

：及时识别和评估项目中的风险，并采取有效的控制措施。

分包商管理

：对分包商的工作进行监督和管理，确保分包工作的质量。

“-ilities”相关特性

安全性

：保障系统的安全运行，防止安全事故的发生。

可用性与可靠性

：提高系统的可用性和可靠性，确保系统能够稳定运行。

可维护性

：便于系统的维护和升级，降低维护成本。

可重用性

：提高资源的利用率，减少重复开发。

安全性

：保护系统的信息安全，防止信息泄露。

与技术领域交互的SE活动执行

教育与培训

：提升团队成员的技术水平和专业素养，为项目的实施提供人才支持。

决策记录与沟通

：记录项目中的重要决策，促进团队成员之间的沟通与协作。

设计评审

：对设计方案进行评审，确保设计的合理性和可行性。

规划

：编写系统工程管理计划，为项目的实施提供指导。

在项目启动阶段，工程方法和活动的规划至关重要。然而，由于项目的实施涉及到产品生命周期的多个环节，这些活动无法在项目早期全部确定，因此在整个项目过程中都需要持续进行规划。在这种情况下，“准时制”方法更为适用，即根据项目的实际需求，在需要进行某项活动之前，再进行相应的决策、描述和培训。论文[V]中对规划以及将MBSE应用于实际项目的经验有更详细的介绍。

3.3 开发过程模型和标准

在工业生产活动中，为了实现复杂产品的高效开发，已经形成了一系列定义明确的模型和流程。航空航天领域所采用的模型，是在这些通用模型和流程的基础上，结合自身特定需求进行调整和实例化的结果。由于航空航天领域涉及范围广泛，常常会从电子或通信等相关领域借鉴一些有用的标准，例如航空电子标准。在嵌入式系统开发方法方面，汽车和航空航天领域也在不断加强知识和标准的交流。本节将详细介绍一些对开发复杂产品，尤其是嵌入式/航空电子系统开发具有重要意义的定义。

3.3.1 产品和系统生命周期

一种在系统/软件开发领域广泛应用的模型是二维模型，它将系统生命周期阶段与过程活动相结合，并按照RUP（IBM的 Rational Unified Process）的规范进行可视化展示。这里的过程活动是依据EIC/ISO 15288标准进行调整的，具体内容如图12所示。

考虑到多客户场景和产品策略（如2.2节所述）的影响，传统的产品生命周期模型进行了扩展，引入了系统生命周期的概念。从开发的角度来看，系统生命周期涵盖了整个产品系列的“系统阶段”。在设计或调整工程环境（如选择合适的方法和工具）时，这个扩展后的定义可以作为重要的参考模板。因为每个系统阶段对工程环境的能力和性能都有着不同的要求。

在本文的研究中，使用表1中的系统生命周期阶段来分析不同开发方法及其所依托的工程环境选择，对项目产生的长期影响。

3.3.2 概念生成和选择

在项目的概念阶段，模型发挥着不可或缺的作用。这是因为在该阶段，往往需要研究一些尚未实际存在的技术和组件，无法通过物理产品进行实验验证。

深入剖析概念工作可以发现，其核心目标是确定技术原理。根据[Ulrich 2000]的观点，概念阶段通常可以细分为两个不同的活动：概念生成和概念选择。在概念阶段的初期，提出的众多概念提案往往由于缺乏深入分析而被轻易否决。当筛选出一小部分具有潜力的概念后，会基于之前迭代过程中积累的想法和经验，通过组合其他概念或者创造新的概念，开启新一轮的概念生成过程，如图13所示。随着概念数量的逐渐减少，对分析方法的要求也越来越高，需要运用更复杂（同时成本也更高）的方法进行深入分析。

不过，在设计过程的早期阶段，使用过于复杂的建模方法未必是明智之举。这是因为此时项目存在较大的不确定性，过多地投入复杂建模可能无法获得与之匹配的收益。在概念阶段早期，当概念数量较多时，结合简单的电子表格工具和基础的建模方法，通常足以满足需求。在做出最终选择之前，需要运用更精确的分析方法来完善决策依据，例如进行动态建模、性能计算、安全分析或者深入的成本评估等。

在概念创建和选择过程中，如果需要处理大量的数据，使用功能/手段树来组织信息会是一个非常有效的方法。在第4.4.2节（第59页）中对此有详细的描述，若想进一步了解，可查阅论文[III]。

3.3.3 开发和建模标准

本节将简要介绍对航空电子设备开发影响重大的指导性标准。这些标准所规定的要求，需通过制定相应的政策和程序来贯彻实施，而这些政策和程序明确了项目在执行（或实例化）企业流程时应满足的具体要求。

ISO 15288标准

：ISO 15288是一个系统工程过程框架，全面涵盖了标准过程和生命周期的各个阶段。该标准将过程细分为四类：技术过程、项目过程、协议过程和企业过程。每个过程的描述都详细阐述了目的、具体活动以及预期达成的结果。其涉及的生命周期阶段包括概念、开发、生产、使用、支持和退役。ISO 15288与其他系统工程描述紧密相关，其中包括INCOSE手册、ISO 12207以及CMMI等。

SS EN - 9100标准

：EN - 9100以ISO 9100:2000为基础，并针对航空航天行业的特点进行了定制化。该标准充分考虑了开发公司或项目在组织层面的问题，要求在多个关键领域建立完善的流程体系：包括对产品开发活动进行全面的规划与控制；明确设计和开发过程中的职责与权限；确定配置控制的强制性步骤和方法；对输入数据进行严格审查，确保其与项目要求一致；在每个开发阶段开展适当的审查、验证和确认工作；将设计工作结构化地分解为重要元素；以及有效管理不同团队之间的接口。正如许多标准所强调的，该标准的最后一项（过程）要求明确指出，必须以清晰明确的（产品）要求作为项目开展的基石：一方面，这些要求是制定项目技术目标的依据，确保项目朝着正确的方向推进；另一方面，它们也是为适航性/认证目的验证产品的重要准则。根据萨博航空系统公司的实践经验，区分这两种产品要求至关重要，因为它们的目的不同。然而，现行标准中并未针对如何实际区分这两种要求提供有效的指导。

ANSI/EIA - 632标准

：美国国家标准协会发布的[ANSI/EIA - 632 1999]标准《系统工程过程》，定义了一套用于工程（或再工程）系统的方法，这套方法融合了行业内的最佳实践经验。该方法主要包含三个部分：首先，系统是由一个或多个最终产品以及一组相关的使能产品构成，这些使能产品能够帮助最终产品在其使用生命周期内满足利益相关者的需求和期望；其次，产品是由分层元素集成而成的组合体，通过集成这些元素来满足预先定义的利益相关者需求；最后，系统及其相关产品的工程实现，需要一个多学科团队对系统层次结构中的每个元素应用一系列过程来完成，团队成员应具备所需的知识和技能。一个系统通常具有产品分解和规范结构，如图14所示。每个产品会按照分层的方式进一步分解为子系统，从而形成系统之系统的视图，如图15所示。这意味着每个层次的系统都有其专属的一组使能产品，在基于模型的开发环境下，这些使能产品包含了最终产品的实际模型。EIA - 632标准清晰地区分了“获取方需求”和“其他利益相关者需求”。其他利益相关者需求的来源较为广泛，包括政府和行业法规、国际公约、环境限制以及公司内部指令等。一般来说，这些需求会对系统开发形成多方面的约束，不仅影响最终产品的特性，还会对开发过程产生限制。由于这些需求之间往往存在冲突，要满足特定系统的所有需求通常是不现实的。因此，尽早开展全面的需求分析至关重要，借助建模（在合适的情况下结合仿真）的方式能够更有效地进行需求分析。

RTCA标准

：美国航空无线电技术委员会（RTCA，一个非营利性标准化组织）制定的指导标准和建议，在民用航空领域的航空电子设备开发过程中具有重要的影响力。RTCA/DO - xx系列在军事领域的应用也越来越广泛，其中一些值得重点关注的标准包括：DO - 178B《机载系统和设备认证中的软件考虑因素》在机载软件领域被广泛认可和引用，被誉为该领域的“圣经”。它为开发者提供了结构化的指导，帮助他们确保软件方面符合适航要求[RTCA, 1992]。目前，新版本DO - 178C正在制定中，该版本旨在纳入新兴的软件开发技术和趋势，如基于模型的方法、面向对象方法以及形式化方法等。DO - 254《机载电子硬件设计保证指南》则为飞机开发者和飞机电子设备供应商提供了重要的指导，帮助他们确保设备能够安全地执行预定功能[RTCA, 2000]。DO - 297《集成模块化航空电子（IMA）开发指南和认证考虑因素》专注于IMA特定的安全和设计保证方面，为相关开发和认证工作提供了专业的指导[RTCA, 2005]。

航空航天推荐实践（ARP）标准

：ARP 4754《高度集成或复杂飞机系统的认证考虑因素》[ARP 4754 1996]主要针对飞机及实现飞机功能的系统的开发过程。它在一定程度上与DO - 178B中的软件方面以及DO - 254中的硬件方面保持一致，但并未涉及软件或电子硬件开发的具体细节。

设计保证等级的定义

：设计保证等级（DAL）或关键程度等级是现代飞机软件开发的基本定义之一。在RTCA和ARP中，该定义是许多开发和认证活动的基础，它对工作流程、工具和建模技术的选择有影响。根据系统故障可能产生的后果，关键程度分为五个等级，如表2所示。不同DAL等级的功能示例如下：关键功能，如速度信息显示、剩余燃油量的传感和计算；非关键功能，如军事领域用于战术评估的操作数据记录、民用航空的客舱娱乐功能。达到更高等级的要求成本更高，实际增加的开发成本差异存在争议，这取决于方法、工具和技能。有数据表明，与D/E级系统相比，A/B级系统的成本增加幅度在75%到200%之间。[Hilderman 2007]指出，如果有效地实施ARP和RTCA标准，最初增加的航空电子设备开发成本会少很多，并且从长期来看，由于可重用性提高、错误修复减少、停机时间缩短以及用户/市场接受度增加，可能具有成本效益。根据[Matharu 2006]的观点，软件组件的重用是航空开发中的主要收益/节省因素。

模型驱动架构

：如[Mellor 2002]所述，模型驱动架构（MDA）方法是一种支持将功能规范与实现分离的方式。MDA用于软件开发密集型系统，自动代码生成是该过程的一部分。其基本概念是通过引入平台独立模型（PIM）和平台特定模型（PSM），将“做正确的事”与“正确地做事”区分开来。从PIM到PSM的转换由平台定义模型（PDM）中的规则定义，通常由自动化工具执行。从模型到不同源代码语言（如ADA、C++或Java）的转换，以及到硬件（固件）规范语言（如VHDL，在硬件/软件协同设计领域逐渐兴起）的转换都有应用[Rieder 2006]。对象管理组织（OMG）提议将特定的UML子集或概要文件，即可执行UML（“xUML”）进行标准化[OMG 2005]，以支持MDA方法。可执行UML是Shlaer - Mellor方法向UML的演进。有关Shlaer - Mellor方法的参考，可查阅[Shlaer 1988]和[Starr 1996]。

表2. 保证等级的定义

需要注意的是，达到更高等级的要求成本自然更高。实际增加的开发成本差异存在争议，这取决于所采用的方法、工具以及技术人员的技能水平。有数据表明，与D/E级系统相比，A/B级系统的成本增加幅度在75%到200%之间。[Hilderman 2007]指出，如果有效地实施ARP和RTCA标准，初期增加的航空电子设备开发成本会少很多，并且从长期来看，由于软件组件可重用性提高、错误修复减少、停机时间缩短以及用户/市场接受度增加，在航空开发中可能更具成本效益。根据[Matharu 2006]的观点，软件组件的重用是航空开发中的主要收益/节省因素。

3.3.4 V模型

在描述产品开发过程的众多模型中，V模型是一种应用广泛的方式，用于展示整个系统的开发流程，具体可参照图16。

V模型的左侧主要涵盖定义、规范和建模等活动，在这一阶段，通常还没有实际的产品部件。工程师们依据系统需求和设计理念，从飞机整体层面的规格说明出发，逐步深入到子系统以及设备/软件层面，进行细致的定义、规范制定和建模工作。这一过程构建起了系统的理论框架，为后续开发提供了重要的指导方向，但此时尚未涉及实际产品的制造。

V模型的右侧则聚焦于使用实际部件或物品开展的集成和测试活动。从设备/软件的获取、制造和实现开始，首先在设备/软件层面进行单独测试，确保每个组件的功能正常。接着，在子系统层面进行集成和测试，检验子系统内部各组件之间的协同工作能力。最后，上升到飞机级别进行全面的集成和测试，其中包括飞行测试等关键环节，以此全面验证整个系统是否符合设计要求。

V模型具有较为明显的自上而下的导向性。它强调从高层级的设计逐步细化到低层级的具体实现，再从低层级的实现反向逐步向上进行验证。不过，根据不同的理解和应用场景，这种导向性的强弱可能会有所差异。在一些项目中，V模型的自上而下特性表现得较为突出，严格按照从设计到实现再到验证的顺序推进；而在另一些项目里，可能会根据实际情况对其进行灵活调整，使得这种导向性相对弱化，但整体的开发和验证逻辑依然遵循V模型的基本框架。

3.3.5 迭代和增量方法

在大型系统的开发与交付过程中，采用增量方式是一种行之有效的风险降低策略。模型驱动软件开发中的增量方法，其起源可追溯至20世纪90年代初期。彼时，用于生成代码的软件模型，核心是借助类图、用例以及有限状态机来记录的对象模型。

自那以后，软件开发领域涌现出了众多方法，从传统的瀑布模型，到像极限编程（XP）这样极具代表性的高度增量式方法[Beck 2000] ，不一而足。现代增量式方法普遍具有一个显著特征，即它们都倡导一系列有助于项目成功的通用“文化”价值观，并通过工具和库所支持的最佳实践，进一步强化这些价值观。

极限编程（XP）

：极限编程由肯特·贝克创立，它是一套紧密结合人员需求与商业需求的价值观体系，涵盖了沟通、简单性、反馈和勇气这几个关键要素。这些价值观通过一系列具体实践得以体现：

规划游戏

：通过综合考量业务优先级和技术评估结果，迅速确定下一次软件发布的范围。并且，随着项目实际情况的动态变化，及时对计划进行更新调整，确保项目始终朝着正确的方向推进。

小版本发布

：快速将一个基础的简单系统投入生产，随后以较短的周期持续发布新版本。这种方式能够让用户尽早接触到产品，及时获取反馈，便于开发团队根据实际情况进行优化改进。

隐喻

：运用一个简洁明了且易于理解的故事，为整个开发过程提供指引，使团队成员能够清晰地把握整个系统的运行机制，增强团队协作的默契度。

简单设计

：在开发过程的任何阶段，都追求系统设计的简洁性。一旦发现设计中存在不必要的复杂性，立即进行简化处理，避免过度设计带来的资源浪费和维护成本增加。

测试

：程序员需要持续编写单元测试用例，只有当所有测试都顺利通过时，开发工作才能继续推进。同时，客户也参与到测试环节，编写用于验证功能完整性的测试用例，确保开发出的产品符合实际需求。

重构

：程序员在不改变系统外部行为的前提下，对系统内部结构进行优化重组。这一过程旨在消除代码中的重复部分，提升代码的可读性和可维护性，增强系统的灵活性和扩展性。

结对编程

：所有生产代码均由两名程序员在同一台机器上共同编写。这种方式不仅能够促进知识共享和经验交流，还能在一定程度上提高代码质量，减少错误的发生。

集体所有权

：团队中的每一位成员都有权在任何时间对系统中的任何代码进行修改。这一实践打破了传统的代码所有权界限，鼓励团队成员积极参与到代码的优化和维护中，提高团队整体的开发效率。

持续集成

：每天多次对系统进行集成和构建操作，每当完成一个任务，就立即进行集成。这样可以及时发现不同模块之间的兼容性问题，确保整个系统的稳定性和一致性。

工作时间限制

：遵循每周工作不超过40小时，且连续两周不加班的原则。这一规定旨在保障团队成员的工作生活平衡，避免过度劳累，从而提升工作效率，保证项目的可持续发展。

现场客户参与

：邀请真实的用户全程参与开发过程，随时为开发团队解答疑问。通过这种方式，开发团队能够更直接地了解用户需求，开发出更符合市场需求的产品。

编码标准

：程序员严格按照强调代码沟通性的规则编写所有代码，确保代码的规范性和可读性，方便团队成员之间的交流与协作。

Telelogic Harmony

：Harmony[Douglass 2007]是一种面向UML/SysML的增量式开发方法或过程，尤其适用于嵌入式软件开发等系统类型，并且可以根据具体项目需求进行定制化调整。它包含15条最佳实践，与极限编程的实践理念有相似之处，但更侧重于大型项目的开发管理。在Harmony中，对团队成员的角色、能力以及任务描述都有详细的文档记录，有助于明确分工，提高团队协作效率。例如其中的第12条“使用框架”、第13条“明智地应用模式”以及第15条“管理接口”等，都是项目开发过程中的重要指导原则。图17展示了Harmony方法的大致框架。

Harmony的系统工程组件（Harmony - SE）采用“服务请求驱动”的独特建模方法，运用系统建模语言（SysML）符号进行系统描述。在这种方法中，系统结构通过SysML结构图表进行清晰呈现，以模块作为基本的结构元素。模块之间的通信通过消息（即服务请求）来实现，服务请求的接收方负责提供相应的服务，而状态/模式的更改或操作（活动）则被描述为操作契约。

Harmony - SE设定了以下关键目标：精准识别并推导出系统所需的功能；明确相关的系统状态和模式；将系统功能和模式合理地分配到物理架构中。其中，功能分解是通过对活动操作契约的分解来实现的，这种方式有助于将复杂的系统功能逐步细化，便于开发团队进行具体的设计和实现。

3.4 模型分类与建模领域

在科学与工程领域，建模早已成为用于规范阐释和问题求解的重要实践手段。随着时间的推移，可用的建模技术和工具数量呈现出爆发式增长。这一现象的产生，一方面得益于工作站和计算机技术的持续进步，另一方面也源于建模在攻克复杂问题方面所展现出的卓越价值。一般来说，每种建模技术都有其擅长处理的特定类型问题，尽管在实际应用中，它们的适用范围可能更为广泛。在大型开发项目中，面临着一个关键抉择：是选用众多功能强大的专用工具，还是采用少数功能较为通用但相对缺乏针对性的工具和技术，这需要进行谨慎的权衡。为此，人们进行了大量尝试，力求对建模技术进行合理分类。在本文中，分类主要依据问题领域以及可用（或可替代）的工具来进行。

3.4.1 模型的价值

在挑选模型技术时，其为项目创造显著价值的能力至关重要，同时，深入了解该技术的特性也不可或缺。以下内容改编自[NASA 1995]，其中列举了模型技术的关键特性：

决策者眼中的可信度

：一个拥有成功预测历史的模型，往往更容易获得决策者的信任，可信度较高。然而，要实现对模型的完全验证，即确凿证明其预测能够精准反映现实，难度极大。这是因为在实际操作中，观测数据常常难以获取，或者所获取的数据质量无法满足要求。

响应性

：模型的响应性体现了它在权衡研究等场景中，区分不同备选方案的能力。以航空电子架构成本模型为例，一个响应性良好的模型，应当能够敏锐地捕捉到不同系统架构、设计方案、操作理念或物流策略所对应的成本差异。

透明度

：透明度指的是模型的数学关系、算法、参数、支持数据以及内部运行机制（即元模型）对用户的公开程度。这种透明度使得模型结果具备可追溯性，即便某些结果可能无法得到所有人的认同，但至少人们能够清晰地了解其推导过程。透明度也是模型获得认可的重要因素。当模型配备完备的文档，并且能够接受公众的公开评议时，它更容易被大众所接受。像[Modelica]这样的开放语言，就为提升模型的透明度提供了有力支持。相反，专有模型由于缺乏透明度，往往在获取认可方面面临较大困难。例如，部分供应商提供的用于仿真工具的组件库，虽然有相应的文档说明，但源代码并不向用户开放，[SimElectronics]工具箱（由The MathWorks提供）就是典型的例子。

用户友好性

：对于终端用户而言，用户友好性反映在工程师学习使用建模技术、准备输入数据以及理解输出结果的难易程度上。而对于高级用户来说，用户友好性还涉及到更新、验证、管理和支持模型所需投入的工作量，同时也包括帮助终端用户解读高级分析结果的便捷性。此外，管理员（支持机构）在模型的安装、升级、错误报告以及与供应商沟通等方面的便捷体验，在模型的实际使用过程中也发挥着不可忽视的作用。

3.4.2 规范和分析模型

一种常见的模型分类方法，是将其划分为“规范”和“分析”模型。以实体建模以及硬件/结构开发领域为例进行说明：

规范模型主要用于定义组件的表面特征（形状）和内部构成（材料），通常借助3D CAD（计算机辅助设计）工具，以可视化原型的方式来完成这一定义过程。

而与之紧密相关的分析模型，则是在规范模型的基础上，针对同一组件进行应力分析。不过，进行分析时需要额外添加边界条件（如力的频谱）等特定信息。

分析过程是基于规范模型中的部分信息，并结合特定分析所需的额外数据来展开的，具体可参考图18。因此，同一个规范系统模型可以作为对系统多个方面进行深入分析的基石。在航空电子设计领域，故障树分析（TFA）、形式化方法分析以及仿真分析等，都是分析模型的典型应用场景。

3.4.3 建模领域

在萨博航空系统公司2006 - 2009年推进基于模型的系统工程（MBSE）变革计划期间，将建模工具及其相关技术、方法划分成不同的建模领域，成为了一项关键举措。这一举措旨在深入剖析不同建模方法与工具的优劣，从而科学地组织工作流程。变革计划的重要目标之一，便是确保工作的全面性和深入性，通过合理的调查研究和资源投入，推动公司组织的持续进步，实现效率提升、质量优化，并构建一个极具吸引力的工程环境。虽然该变革计划的支持范畴不止涵盖航空电子设计和飞机仿真，但这些建模领域的相关工作在这两个方面贡献突出。因此，下面将对所有已定义的建模领域展开详细介绍。

概述

建模领域的具体定义见图19。在本节内容中，将对这些建模领域进行深入探讨，重点聚焦于“使用、需求和要求”以及“架构和接口”这两个领域。对于其他领域，在此先做简要说明，它们与更为具体的建模技术紧密相关，后续第4章和第5章会对其进行详细阐释。

建模领域大致可分为上下两个部分。下半部分主要涉及物理对象及其属性，包括空间、时间、能量和物质等方面；上半部分则与信息（以及有关信息的信息）紧密相连。

使用、需求和要求

在设计诸如航空电子设备这类包含嵌入式电子/软件的产品时，通常需要依据其功能能力方面的需求来开展工作。“使用、需求和要求”领域涵盖了一系列建模方法，这些方法旨在精确描述产品的使用场景，进而助力设计出具备竞争力的产品。对于与使用相关的功能需求，利用UML或SysML中的描述性用例进行建模是较为理想的方式。在抽象层面开展离散事件模拟，也有助于清晰展示产品与用户、相关系统或环境之间的交互情况。非功能需求则需借助专门的流程来获取，相关信息通过数据库、电子表格以及普通文档等多种方式进行管理。非功能需求的技术层面包括系统安全、性能、可靠性、可用性；非技术层面则包括成本、安全性、过时处理、灵活性与增长潜力、可承受性与风险等。例如，在飞行控制设计中，技术需求的来源示例可参考论文[1]中的图1。成本建模存在多种方法，COCOMO和COSYSMO[Valerdi 2008]是应用较为广泛的成本模型。基于产品分解构建的成本模型易于搭建，并且能与其他开发活动有效配合，但为避免模型规模过大，需要将其控制在一定的汇总级别。另一种成本预测方法是Lichtenberg方法[Lichtenberg 2000]，该方法借助一个跨学科的创意团队，对定性和定量数据进行收集与建模。此外，处理假设（作为需求的补充内容）正逐渐成为一个备受关注的领域，ARP 4754以及新兴的SPEEDS技术为其提供了有力支持。关于SPEEDS技术的更多详细信息，可查阅第55页的相关内容。

架构建模

系统的架构模型承担着定义系统边界、内部组成部分（组件或子系统）、各组件行为职责以及内外部接口的重要任务。为实现对系统的全面描述，顶层模型还需明确作用于系统的参与者以及系统运行所处的物理环境。图20展示了一个使用UML/SysML符号表示的顶层架构模型示例。在描述和分析各种可能的架构，或是探索设计空间时，需要从不同角度进行审视。此外，强大的工具支持不可或缺，这有助于实现建模、分析、设计以及文档生成等功能。架构的分解形成了一个模块化框架，借助该框架，模块的任何细化版本都能轻松接入，而无需对模型的其他部分重新考量或设计。对于执行安全关键功能的产品部分（子系统）而言，可视化数据流极为关键，这有助于深入理解因果关系（依赖性），并便于在大型团队中开展设计评审工作。在嵌入式系统架构建模领域，已有诸多相关的书籍和研究成果，例如[Lavi 2004]、[Muller 2004]、[Larses 2005]以及[Weilkiens 2008]等。

控制

控制建模领域聚焦于系统的闭环视角，为产品、子系统及组件的操作方案构建提供了专业的建模方法。其控制模型规范覆盖范围广泛，从高层次的任务场景规划，到中间抽象层级的控制理论模型搭建，再到实时操作计算机硬件中的可执行代码，以及机械、电气、液压等各类硬件所实现的控制机制，均在其范畴之内。该领域的模型具有显著特征，呈现因果关联特性，以信号流为导向，其动力学原理基于微分方程或差分方程，这使得时域和频域之间的数学变换，如拉普拉斯变换或Z变换得以实现。

信息

信息领域集成了一系列建模工具，主要用于明确航空电子系统中不同协作实体间信息的术语定义、确切含义、命名规则以及表示格式。这里所提及的“实体”，涵盖范围广泛，包括从人类操作员到软件、硬件等各类对象。在基于建模的开发过程中，信息建模占据着关键地位，因为在此过程中所涉及的各类模型，其核心管理内容即为信息。为模型制定语义规则，这一行为本身也属于建模范畴，具体来说就是构建其元模型。

人机界面与虚拟环境

人机界面（MMI）和虚拟环境领域着重对显示界面、实时交互过程以及行为历史记录进行建模。该领域聚焦于人与机器的交互环节，例如关注用户（飞行员）在信息繁杂场景中的态势感知获取能力、任务规划的传达方式，以及实际操作时的具体情境。

结构

结构领域的基础信息主要围绕空间布局和材料特性展开。借助CAD模型，设计师能够在产品开发的早期阶段，验证设备的安装可行性，确保其能够顺利连接到电气触点和冷却接口。此领域还配备了一系列建模工具，用于精确指定、标注尺寸、计算和分析航空电子产品中主要承载硬件组件的属性。

物理系统

物理系统领域涵盖了用于对机械硬件以及流体/能量流进行指定、模拟和虚拟交互的建模工具。在产品开发的早期阶段，通常会运用相对简单的模型进行概念评估。而在后期阶段，则侧重于通过模型对系统进行验证，尽管最终的验证往往依赖于最终产品的实际配置。微分方程，尤其是微分代数方程（DAEs，详细定义见4.2.4节），在该领域的建模工作中发挥着重要作用。

电子、光电子

电子和光电子领域拥有一系列建模工具，可用于对航空电子产品及其所处环境中的电子电路和光电子组件进行指定、模拟和虚拟交互操作。在设计过程中，故障树分析（FTA）等分析手段，以及在维护过程中基于模型的诊断和故障排除技术，都是该领域的基础应用技术。

模型集成与系统仿真

模型集成旨在对集成系统的特定方面进行验证。例如，在基于CAx的流程中，用于安装和碰撞分析的3D数字样机就是模型集成的应用实例。对于软件/系统的验证工作，如5.3.3节和6.2.2节中所描述的中到大规模仿真，均属于该领域的范畴。

工具支持

针对每个建模领域，都配备了一组用于建模（定义或指定系统）的工具，以及用于分析建模信息特定方面的工具。5.2.8节“工具汇总”中的表5展示了在不同建模领域中用于建模和分析的工具示例。

本节内容及相关表格，列举了与已定义建模领域相关的工具。然而，在航空电子设计和飞机仿真领域，还存在许多其他重要的工程方法和工具，本文并未一一列出。

4. 建模与分析技术

本章将深入介绍并分类适用于航空航天和航空电子行业的各类建模技术，详细定义模型的不同属性，如静态/动态、离散/连续等特性。同时，深入探讨如何借助模型对系统进行分析，重点阐释广泛应用的仿真技术，包括在仿真过程中通过故障注入引入错误的方法。

4.1 技术介绍与分类

建模技术是基于特定的方式来描述所研究的现象或系统。建模元素的定义、通用名称、属性以及它们之间的相互关系，共同构成了元模型。人们多次尝试通过分类树对建模技术和工具进行分类，但由于这些分类树的适用性依赖于具体的使用情境，所以并不存在通用的分类标准。在行为建模技术部分，将会展示一个源自[Cassandras 1999]的分类树示例。

一种常见的主要分类方式，是将结构模型与行为模型区分开来。结构和行为是系统描述的两个基本视角，行为体现了系统的功能，而结构则展示了系统的构建形式。这两种视角，再加上行为与结构之间的映射关系，共同构成了完整的系统描述。若将期望的行为与结构分开定义，便能够轻松确定替代结构，并将期望行为映射到各个结构之上[Oliver 1997]。

4.1.1 架构建模技术

架构建模，也被称作“系统架构设计”或“系统结构建模”。架构设计活动的核心目标，是确保从需求到实际产品的整个过程具备一致性和平衡性。参与产品创建的人员规模差异较大，少则寥寥数人，多则可达数百人，并且工作的并行程度较高。从事新产品开发的工程师往往仅掌握部分信息，这就导致不一致性和局部最优（次优）解决方案频繁出现。架构设计是应对系统质量自然下降的有效手段，既可以通过明确清晰的需求和系统分解来主动预防问题，也能够借助跟踪详细设计、实施和测试的反馈进行被动调整。

在产品创建过程中，会产生众多设计决策，而这些决策通常是在特定的时间点和有限的信息范围内做出的，这就使得后续决策可能出现相互矛盾的情况。数据字典是保障架构信息一致性的简单而有效的工具，它作为一个集中的信息仓库，存储了组件、名称、含义、与其他组件的关系、历史以及所做决策等相关信息。尽管数据字典概念看似简单，但在包含新组件与遗留组件、军民两用部件复用，以及因安全因素存在不同计算机网络的复杂环境中，其实施过程颇具挑战。因此，对数据字典本身进行建模和架构设计是非常有必要的。

一个系统的架构模型至少包含边界、内部部件以及接口（内部和外部）等要素。对于一个部件或模型，可以从不同的视角进行观察，或者定义不同的透明度级别，具体如下：

黑盒

：仅展示名称和接口，内部信息处于隐藏状态。这种视角常用于规范和验证阶段，当仅需从外部对部件进行考量时较为适用。使用SysML的“块定义图”（bdd）进行建模是较为理想的选择。

灰盒

：在黑盒视图的基础上，增加了内部部件结构、部件连接性以及模型（包括部件）的状态和参数信息。这种视图有助于了解内部结构，但不会呈现所有细节。使用SysML的“内部块图”（ibd）进行建模，能够很好地体现这种视图。它还适用于“半物理”模型，这种模型融合了基于自然法则的方程和参数化黑盒模型。

白盒

：涵盖灰盒视图的所有内容，还包括所有系统变量、行为等信息。对于系统规范或系统模型而言，所有内部信息都清晰可见。在安全关键的软件组件中，需要进行白盒规范和测试，以此验证是否符合设计规则等要求。

扩展

：包含所有相关信息，例如启动、执行、状态更新以及仿真增强功能等。通过这个扩展视图，与模型或建模技术本身相关的信息也能够被查看。

4.2.1节“使用对象和类进行建模”中，对架构建模或结构建模的信息元素进行了详细描述。

4.1.2 行为建模技术

为了准确描述系统行为，需要一系列建模元素。根据[Oliver 1997]的定义，必要的语义元素包括：

函数

：负责接受输入，并将其转化为输出。

输入和输出

：具有多种不同的类型。

控制运算符

：用于定义函数的执行顺序。

图21展示了一个源自[Cassandras 1999]的分类示例，该示例适用于离散事件系统（DES）建模技术。图中下方加粗部分属于DES的定义范畴，这些被定义为事件驱动、离散状态、非线性、时不变的动态模型。

以下是模型的一些基本属性：

静态或动态

：当模型中变量之间的关系呈现瞬时性时，该模型为静态模型。例如，理想电阻就是典型的静态模型，其电流与电压遵循欧姆定律，成正比例关系，不存在对变量历史的依赖。与之相反，动态模型的行为依赖于其过往状态，通常由微分方程和（或）差分方程构建而成。

时不变或时变

：这个分类主要依据模型的交互规则是否与时间相关。若模型的交互规则不随时间变化，则为模型时不变模型；反之，若交互规则依赖于时间，则为模型时变模型。

线性或非线性

：如果模型中输入信号、状态和输出信号之间仅存在线性依赖关系，那么该模型属于线性模型。非线性模型在某些特定的操作点可以进行线性化处理，但这种线性化仅在该点附近有效。一般而言，线性模型在分析过程中相对容易处理。

离散状态或连续状态

：这一属性与模型描述变量的取值范围相关。在离散状态模型中，变量只能取离散的一组值。离散事件模型属于连续时间/离散状态模型。而在连续状态模型中，变量的取值范围可以用实数（或其区间）来表示。微分方程模型就是典型的连续时间/连续状态模型。

时间驱动或事件驱动

：在时间驱动模型中，时间是核心的建模元素；而在事件驱动模型中，时间甚至可能未被定义。这种差异使得这两种模型的集成面临一定挑战。

确定性或随机性

：该分类基于模型中的因果关系。若模型仅包含变量之间的确切关系，不存在随机变量，那么这个模型就是确定性模型。而随机（概率）模型由随机变量或随机过程来描述，至少包含一个随机变量。

离散时间或连续时间

：模型可以依据其时间基准进行分类。在连续时间模型中，时间被设定为连续流动，模型时钟平稳推进，取值为不断增大的实数。在离散时间模型中，时间以跳跃的方式前进，模型时钟按周期跳动，从一个整数跳转到下一个整数（这些整数代表某个指定时间单位的倍数）。

因果或非因果

：因果性体现了因果关系的属性。对于信息流或传感器、CPU的模型，系统的输入和输出决定了因果性。而对于具有能量和质量流的物理系统，因果性则取决于所采用的建模技术或工具。在非因果（或无因果）模型中，因果关系无需明确指定。一些仿真工具（如[Dymola]）能够将非因果模型的方程整理成仿真代码。在创建因果模型时，建模者需要确定将哪些内容视为组件的输入和输出，键合图建模技术是一种有助于从非因果模型转换为因果模型的方法。键合图是一种基于能量的图形技术，用于构建动态系统的数学模型，详细内容可参考[Cellier 1995]。

同步或异步

：这一属性涉及复合系统中各子系统之间的通信情况，同时也能定义更大模型的特性。同步通信以规则的时间间隔进行，而异步通信则用于描述数据间歇性传输而非稳定流动的通信场景。在具有中央求解器的仿真系统中，模型通常同步执行；而在采用分散式求解器的情况下，异步行为更为常见。

开放或封闭

：此类别用于描述模型与其所处环境的关系。如果环境对模型没有任何影响（即无输入），那么该模型为封闭（或自治）模型。开放或非自治模型具有输入变量，其值不受模型控制，但模型必须对这些输入做出响应。

4.2 基本建模概念

每种建模工具或技术都蕴含着一个（或多个相互结合的）建模概念。这些概念与不同的基础概念模型紧密相连，而这些基础概念模型可能基于数学原理、面向对象思想或因果关系等方法构建。以下所描述的基本概念，虽只是众多概念中的一部分，但它们与飞机和航空电子设备的应用领域高度相关。

4.2.1 对象和类建模

在过去的几十年间，面向对象（OO）建模方法备受瞩目。在大型系统的分析（OOA）、设计（OOD）以及文档编制工作中，该方法展现出独特的优势，它所具备的封装和模块化特性，为系统开发提供了有力支持。诸如ADA 95、C++、Java和UML等编程/建模语言的出现，更是为面向对象编程（OOP）范式的应用提供了便利。[SysML]、[Mellor 2002]以及[Johansson 1996]等文献，是深入理解这些概念的重要参考资料。

面向对象方法的应用

：在飞机和航空电子设备的开发过程中，面向对象技术有着广泛的应用场景。本节主要聚焦于两个差异较为明显的应用领域：其一，飞机子系统/软件功能开发，这一领域涉及实时行为以及系统安全等重要方面；其二，工程数据管理（EDM）工具的开发，该领域在一定程度上以信息论为基础。在这两个应用领域中，对象的识别与分类都是核心环节，但二者也存在明显区别。例如，在飞机子系统/软件功能开发中，需要对物理对象进行分析；而在EDM工具开发中，主要关注的是信息对象。尽管存在差异，这两个应用领域都依赖于面向对象的基本概念，下面将对其中的主要概念进行介绍。

类/对象

：类和对象的概念是人类认知世界的重要思维方式。像柏拉图这样的伟大哲学家，就曾对这一概念进行过深入的思考与研究。奎因同样对类/对象概念投入了诸多关注，本书中对物理对象和逻辑（或信息）对象的区分，部分源于[奎因，1981]的理论。从概念层面来讲，对象可分为以下两类：

物理对象（实体）

：它具有唯一性，在四维时空里占据特定的位置。

逻辑对象

：作为类的实例，逻辑对象需要一个唯一的标识符来加以区分。

在不同的应用领域中，类的定义会存在一定的差异。但总体而言，类可被定义为 “具有共同属性的对象集合”。在SysML中，“块（block）” 的概念与其他语言中的类相似，只不过使用 “块” 这个术语，是为了突出其在特定情境下的不同用途。表3引用了不同参考文献中对类/块的定义。

可以看出，这些定义之间存在细微差别。Johansson和SysML的定义，分别是针对各自特定的应用场景而设计的，Johansson的定义适用于EDM工具开发领域，而SysML的定义则更契合飞机子系统/软件功能开发的需求。在类的概念范畴内，还有许多类似的表述，如类别（Category）、种类（Kind of）、类型（Type of）、分类（Sort of）、对象组（Object group）、集合（Set of）等，它们的语义会因上下文的不同而略有差异。尽管类的概念定义多样，但只要特定建模工具具备明确的使用方法，建模活动就不会受这些概念差异的过多影响。不过，在工具的互操作性方面，尤其是在数据传输和工具连接过程中，这些差异可能会引发一些问题。

属性

：属性用于定义对象的特征或特性，反映了特定对象或类所具有的独特性质。属性值的取值范围和格式，由其类型规范进行限定。以飞机类为例，起飞重量、颜色、最大速度等都属于飞机类的属性。通常情况下，对象的属性值会随着时间的推移而发生变化。在基于模型的系统工程（MBSE）环境中，为了实现模型的规模扩展以及保证长期的一致性，对属性进行清晰明确的定义和规范至关重要，这包括对属性的准确描述、明确连续属性的单位，以及确定枚举属性的离散值等方面。

抽象

：抽象是一种简化复杂现实的有效手段，通过构建适宜的模型，使其契合具体问题的求解需求，并在系统的特定层面以最具价值的抽象级别开展工作。在大型系统中，抽象概念尤为关键，它能够帮助人们在众多信息中精准聚焦，在合适的抽象层次上深入探讨问题和解决方案，避免因无关细节的干扰而影响工程讨论的效率。例如，在软件规范过程中，功能模型描述里关于类型和执行速率的实现细节，可能会对当前的工程讨论造成干扰，这在论文[IV]中有更为详细的阐述。“细节级别” 也是一种与抽象相关的机制，但在此处暂不深入分析。需要注意的是，“抽象” 的概念可能会因个体在特定工程领域的知识储备差异而产生不同理解，对某些人来说抽象的内容，在另一些人眼中可能是具体明确的。

继承

：继承机制在建模领域中发挥着重要作用，它允许在模型构建过程中复用通用的概念描述。在面向对象编程语言中，继承更是实现功能复用的重要方式，有效减少了定义的重复工作。子类作为类的特殊化版本，能够继承其父类的属性和行为。例如，在数据库设计场景中，航空电子设备类（Avionics_Equipment）可能包含计算机（Computer）、传感器（Sensor）和记录单元（Recording_Unit）等子类。具体到某个任务计算机1（Mission_Computer_1），它就是计算机子类的一个实例。假设航空电子设备（父）类定义了端口数量（Number_Of_Ports）和所需冷却空气量（Cooling_Air_Required）等属性，那么其所有子类（计算机、传感器和记录单元）都会继承这些属性，这就使得数据库设计者仅需对这些属性进行一次定义即可。多重继承是指一个子类从多个并非相互继承关系的父类中获取属性和行为的方式。在EDM工具开发中，多重继承能够提高开发效率，但并非所有的系统/编程语言都支持这一特性，特别是那些针对飞机子系统/软件功能开发设计的语言。

关系

：关系作为模型元素之间的语义连接，主要包含部分 - 整体关系（part - of）、关联关系（association）和泛化关系（generalization）这三种类型。在[UML]中，关系被定义为 “存在于两个或多个分类器之间的连接，用于明确它们实例之间的关联”。这就导致一个UML关系可能拥有两个以上的 “关系端”，这种情况在概念上并非必要，反而增加了UML元模型的复杂程度。实际上，实现三元（三重）关系可以通过更为简洁的方式，即使用一个类与三个二元关系进行连接，并合理设置基数约束来达成。

示例

：为了更直观地帮助读者理解类/对象概念，这里以本书为例进行说明。本书具有ISBN标识符，这个ISBN代表了所有本书副本（对象）的集合。我此刻正在阅读的这本书，就是属于ISBN代码为978 - 91 - 7393 - 692 - 7的这一类论文中的一个具体实例。ISBN作为同类书籍的唯一标识符，发挥着重要的区分作用。

物理对象

：每一本纸质版的书都是一个物理对象，它在四维时空里具有唯一的存在位置。为了突出物理对象的唯一性，纸质副本通常会进行编号，比如这本副本的物理对象编号为[具体编号]。

逻辑对象

：存储在计算机或服务器上的电子副本属于逻辑（或信息）对象，与物理对象不同，它们无法通过具体的物理位置进行唯一标识。信息具有易创建、易移动、易复制和易删除的特点。

4.2.2 信号流模型

信号流建模非常适合借助图形编辑器来实现。在实际操作时，用户可以从包含预定义块和连接的库中进行拖放操作，以完成建模工作，其中箭头用于表示信号的流向，如图22所示。这些库依据功能进行分类，例如，所有的滤波器会被归为一组。当在模型中使用特定的块时，用户可以通过选择合适的参数值对其进行实例化。除了信号名称外，每个信号还可以被赋予单位、描述等属性。用户可以定义具有输入和输出的聚合模型，并在不同的层次级别上多次复用这些复合模型。连接用于表示具有固定因果关系的标量或向量信号。

4.2.3 离散事件模型

离散事件系统（DES）技术在建模领域占据着重要地位，众多研究团队投身于该领域的研究，并且不断有新的工具涌现，以满足大规模（或工业）应用的需求。在此，将对DES建模的主要元素进行定义，并介绍语义略有不同的建模技术。

基本定义

：

事件

：事件是在时间上瞬间发生的现象，不具有时间延续性。其中，显式事件是经过命名或预先定义的，而隐式事件则是在系统运行过程中发生，但未被预先明确界定的事件。例如，当某个特定条件达成时的时间点，就是一个隐式事件，如图23所示。

实体

：实体是在系统中流动的对象，例如数据总线上传输的消息。通常情况下，一个事件（如消息到达）会与一个实体（如该消息）相关联。

不变量

：不变量是系统或模型所具备的一种属性，无论系统处于何种操作模式，该属性始终保持不变。

模式

：模式代表了系统的特定操作条件。比如飞机的起飞、巡航、着陆等操作阶段，以及系统的正常运行、降级运行等状态，都属于系统的不同模式。

谓词

：谓词是一种特殊的函数，它的返回值只有真或假两种情况。

状态

：状态用于描述系统在某一时刻的操作条件。通常，人们会通过枚举系统所有可能的状态以及状态之间的转换关系，来表示系统的运行功能。例如，可以利用状态图、有限状态机或Petri网等工具，来描述特定系统中状态变化的规则。事件的发生往往会促使系统状态发生改变。

队列

：队列可以理解为一个任务列表、等待发送的消息缓冲区，或者是任何实体因特定原因等待事件发生的场所。

调度

：调度是指为现有实体安排新的未来事件的操作。

状态图、状态机和状态charts

：状态图以图形化的方式展示系统的行为，系统由有限个状态组成。状态图存在多种形式，它们在细节和语义上存在一定差异。状态图所基于的形式化机制是有限状态机（FSM），此外，状态转换表也是一种表示系统状态变化的方式。状态机主要有摩尔（Moore）状态机和米利（Mealy）状态机两种类型，它们之间的关键区别如下：

摩尔状态机

：摩尔状态机的输出仅取决于机器当前所处的状态。因此，除了状态转换的瞬间，其输出始终保持有效。

米利状态机

：米利状态机的输出不仅与机器的状态有关，还取决于输入。这就导致其输出仅在状态转换后的瞬间有效。

哈雷尔状态图（Harel statechart）是对简单状态图的拓展，由大卫·哈雷尔（David Harel）设计。它增加了超状态、并发状态以及作为状态一部分的活动等特性。状态图的非正式定义为：状态图是一种可视化的形式化工具，用于以模块化的方式描述状态和转换，支持聚类、正交性（即并发）和细化操作，并且具备 “缩放” 功能，方便用户在不同的抽象级别之间进行切换。在UML和SysML中，“状态机图” 用于对系统的状态相关行为进行建模，不过其符号表示并未完全严格形式化。在[Simulink]/[Stateflow]、[SCADE]或[SystemBuild]等工具中，对状态图的支持是基础功能之一，但由于工具本身的特性以及模型的使用目的不同，具体的支持程度会有所限制。例如，在代码生成场景下，这些限制使得系统工程师能够在一定范围内较为自由地进行建模，而无需过多关注生产代码的布局以及安全/质量等方面的问题。图24展示了Stateflow中燃油控制模型的状态图。

自动机理论

：自动机是有限状态机的数学表达形式，在[Cassandras 1999]的第2章中，对其用于数学表达、执行和分析状态机的原理进行了详细阐述。自动机在接收到一组事件作为输入时，会依据转换函数在一系列状态之间进行 “跳转”（转换函数也可以用表格形式呈现）。自动机((M))是一个五元组（5 - 元组），即(M = (S, E, T, s_0, F))，其中：

(S)表示有限状态集。

(E)是有限（输入）事件集。

(T)是一个转换函数，它为每一个状态/输入对分配一个对应的状态。

(s_0)是(S)中的一个元素，被称为初始或起始状态（例如上述例子中的pump_from_aft）。

(F)是(S)的一个子集，即最终状态集（例如上述例子中的emptied）。

(M)代表转换函数（机器）。

基于自动机的基本原理，衍生出了许多扩展和功能强大的模型变体，如定时自动机、混合自动机以及与之相关的Petri网。

Petri网

：参考[Cassandras 1999]第4章的内容，Petri网由位置（places）(P)、转换（transitions）(T)以及具有特定方向的弧组成。标记Petri网会在位置上分配令牌（在图形上用点表示），图25展示了一个简单的Petri网示例。令牌放置在某个位置，意味着该位置所代表的条件得到了满足。位置可以容纳一个或多个令牌，通过 “触发” Petri网，可以改变位置上令牌的数量。令牌在位置上的分布情况被称为标记（marking）。弧仅在位置和转换之间连接，从位置指向转换的弧所对应的位置，是转换的输入位置；从转换指向位置的弧所对应的位置，则是转换的输出位置。Petri网的执行具有非确定性：当多个转换同时满足触发条件时，其中任何一个转换都有可能被触发，但并非一定会触发。由于触发的不确定性，并且网络中同一位置或不同位置都可能存在多个令牌，使得Petri网在对分布式系统的并发行为进行建模时具有独特的优势。目前，虽然存在多种Petri网建模工具，但它们与航空电子领域常用的其他建模标准和工具之间的集成度普遍不高。例如，[Modelica]虽提供了Petri网扩展，但在使用过程中存在一些不便之处，位置(P)的输入和/或输出弧的数量是预先设定好的，在模型元素中无法直接修改，若要更改，需要替换整个位置元素才能获得正确数量的预定义输入/输出。

4.2.4 微分方程

自艾萨克·牛顿时代起，对于连续型问题，微分方程就一直是进行物理/数学建模的重要工具。在众多应用场景中，常微分方程（ODE）（1）被广泛使用，并且有许多功能强大的求解器和分析工具可供选择。线性微分方程组（2）是一种更为特殊且相对简单的表示形式。在特定的操作点，常微分方程（1）可以通过线性化处理转化为（2），这使得一系列（线性）分析和综合技术得以应用。

在一些特定的问题领域，尤其是力学和电子学领域，当物理定律等约束条件起主导作用时，会得到一组微分代数方程（DAE）（3）。相较于常微分方程，微分代数方程在仿真模型中具有更强的通用性和表现力。将微分代数方程转换为常微分方程不仅耗时费力，还容易出错，在某些情况下甚至无法实现；而在 “DAE工具” 中使用常微分方程则较为便捷，因为常微分方程实际上是微分代数方程的一个子集。在工程建模中，还有一种常用的微分方程——偏微分方程（PDE），其未知函数是多个独立变量及其偏导数的函数，常用于解决热分布等问题。若想深入了解微分方程的基本性质以及在物理问题中的应用示例，可参考[Andrews 1986]。

4.2.5 传输线

在针对硬件组件开展的仿真建模工作里，传输线作为一种常用的技术手段，属于功率端口的变体形式。传输线运用双向数据交换机制，其节点与实际的物理连接相对应。

依据[Krus 2005]的研究成果，借助传输线和分布式求解器，模型的“面向对象”特征会更加突出。这是由于组件类不仅封装了相关数据与操作，还将求解器纳入其中。采用分布式求解器并以传输线作为连接元素，能够从物理层面合理地划分系统。这样一来，组件模型在数值计算方面能够相互独立，具备高度稳健的数值特性。该技术在系统的高速仿真中具有重要应用价值，并且在基于仿真的优化过程中也展现出良好的稳定性。在优化时，系统会在不同的模型参数设置下多次进行仿真。

利用传输线元素对系统进行划分并非唯一选择，传统的仿真技术在子系统中依然适用。这意味着，为传输线构建的组件可用于连接不同仿真软件所开发的仿真模型。使用分布式求解器还有一个显著优势，即它允许从预编译模块组装模型。在协同系统设计场景中，这一优势尤为明显。因为在向合作伙伴提供模块时，既无需披露源代码，也无需详细说明所需的求解器技术。

随着模型规范工具的持续发展，能够高效建模的系统规模不断扩大。与此同时，硬件性能的提升也使得对这些大型模型进行仿真和分析成为现实。然而，在处理大型复杂系统时，存在一个普遍问题：大多数仿真软件包依赖集中式集成算法，这些算法在应对大规模系统时，扩展性表现欠佳。对于大规模系统而言，如果能将其划分为多个部分，且各部分之间的相互作用尽可能小，将极大地提高仿真和分析的效率。

随着多核桌面计算机的问世，实现简单高效的并行化架构成为可能。包含求解器的组件可以以最优方式映射（部署）到各个核心上，从而充分利用多核计算资源，提升系统仿真和分析的性能。

4.2.6 物理流与信号流

在构建面向物理系统的仿真模型时，有一种方法对用户很有吸引力，那就是使模型与系统的结构或“拓扑”保持一致，如图26右图所示。使用功率端口连接组件的方式备受青睐，因为这不仅能直观呈现系统结构，还能以描述性的方式指定方程（采用DAE形式）。这意味着，该方法主要用于以非因果形式定义系统方程，而不涉及方程的求解过程。这种方法通常被称为“功率端口”建模技术。

图26左图展示了使用信号流技术和显式方程规范（采用ODE形式）对同一系统进行建模的情况。当这种信号流技术用于系统的物理部分建模时，很容易使模型变得过于复杂。这是因为模型中的箭头代表的是信息流动，而非系统中的实际物理流动路径。对于小型系统而言，这种缺点可能并不明显，但在大型复杂系统中，可能会导致模型理解和分析的困难。关于这些建模技术的更多讨论，以及两种技术的集成应用，可在论文[II]中找到详细内容。

4.2.7 面向对象与信号流

对于软件密集型和嵌入式系统，有两种常见且重要的建模技术。一种是基于面向对象范式，在行业内，该范式已逐渐趋于统一，UML和SysML成为了标准的语言/符号表示。另一种则是基于信号流范式，其主要的建模语言是信号图或数据流图（DFD）。这两种方法都能从不同角度为系统建模提供重要视角，但它们各自关注的是系统的不同方面。

为了深入理解并准确指定应用程序或系统的目标和功能，需要以一种与领域和平台无关的方式提取其功能需求，并形成初始规范。在这个功能规范制定过程中，一种有效的方法是将面向对象和数据流的观点进行整合与结合，用于系统的分析和设计。该方法遵循功能分解的原则来指定系统，同时充分利用面向对象和数据流两种观点的优势来进行系统表示。[Fernandes 2004]对整合这两种观点的价值进行了论证，文中指出：“遗憾的是，在软件领域，这两种主要范式之间存在着一种竞争文化。如今，常见的做法是要么采用‘纯粹’的面向对象方法，要么采用‘纯粹’的函数式方法。但我们更倾向于将它们视为互补的方法，每种方法都有其独特的优势和不足。我们认为，合理地结合这两种方法，能够实现优势互补。”

在采用分区IMA架构的航空电子系统中，可以根据系统的某些属性，如数据管理量、时间/事件驱动程度以及关键程度等，在不同的应用开发中灵活选择这两种范式。例如，对于数据管理量较大、对实时性要求较高的应用，可以更多地采用基于信号流的开发方式；而对于功能模块划分明确、需要强调封装和复用的应用，则可以优先考虑面向对象的开发范式。

4.3 规范技术

规范聚焦于系统应当达成的目标，而非实现这些目标的具体方式。在对系统或产品进行规范描述时，可以采用不同程度（语义层面）的形式化方法。下面将先简要介绍传统的（非数学形式化）规范方法，鉴于形式化方法与基于模型的方法关联更为紧密，后续会着重详细介绍新兴的规范技术——SPEEDS。

4.3.1 传统规范

传统规范中的核心信息是需求。需求会经过精心的结构化处理，并依据优先级等标准进行评估。在信息模型里，需求与系统元素相互关联，并被归类为功能、性能或其他系统特性类别。在过去，当缺乏先进的需求管理工具或面向对象的文档工具时，这些信息通常以普通文档或电子表格的形式进行管理。然而，当系统规模变得庞大时，需求评审、更新以及收集和整合来自不同人员的需求及相关信息等工作就会面临诸多挑战。大量的时间被消耗在手动对比不同版本以及将多人提供的信息合并到 “主” 文件的繁琐操作中。

不过，只要制定严格的规则，明确各方的责任，并借助某些（数据库）工具的支持，即使是大型系统，也能够实现高效且经济的规范工作。在萨博航空系统公司，基于[MIL - STD - 498 1994]中的信息结构，参照[Hull 2002]的描述，并利用[DOORS]工具的辅助，实施了一套完善的需求和规范流程。

4.3.2 形式化规范

形式化规范是运用数学手段对系统进行的精准描述，它能够为系统的实现过程提供清晰的指导。借助形式化规范，形式化验证技术得以应用，从而可以严格证明给定设计与规范的一致性。

形式化规范语言

：经过多年的发展，已经涌现出多种形式化规范语言和方法，其中部分已经在工业领域得到了实际应用。以下是一些典型的形式化规范语言/技术示例：

标准化语言

：例如经过ISO标准化的特定语言，具有广泛的通用性和规范性。

Esterel

：作为一种同步语言，它能够被转换为有限状态机，为系统的状态建模提供了有效的手段。

Lustre

：这是一种形式化定义的、声明式的同步数据流语言，同时也是[SCADE]工具的核心语言，具有强大的数据流处理能力。

Petri网

：在4.2.3节中对其进行了单独且详细的介绍，它在描述系统的并发和异步行为方面具有独特的优势。

VDM

：维也纳开发方法是一种形式化语义语言，不仅可以证明模型的属性，还包含一个可执行子集，使得模型能够通过测试进行分析，增强了模型的可验证性。

Z符号

：它是一种基于基本集合论的规范语言，为系统的形式化描述提供了坚实的数学基础。

此外，还有一些半形式化语言，在实际应用中也发挥着重要作用，包括：

- UML/SysML：统一建模语言和系统建模语言，由对象管理组织进行标准化，具有广泛的应用场景和丰富的建模元素。

- AADL：架构分析与设计语言，由美国汽车工程师学会标准化，专注于系统架构的分析和设计。

尽管形式化语言方法已经发展了数十年，并且理论上有望 “自动证明” 给定设计满足系统规范，但在航空航天行业中，它尚未得到大规模的推广应用。相反，半形式化语言的使用正在迅速增加，逐渐成为行业内的主流选择。

SPEEDS

：下面将深入探讨基于组件的规范技术SPEEDS。如需了解更多背景信息和详细文档，请参考[Engel 2008]和[SPEEDS]。SPEEDS方法建立在组件建模方法的基础之上，开发了一种异构丰富组件（Heterogeneous Rich Component，HRC）元模型，为该方法提供了坚实的语义基础。HRC元模型内容丰富，旨在支持源自SysML、Simulink和SCADE等多种语言和工具的组件模型表示。其精心设计的语义使得这些工具中的任何一个都可以作为前端，用于创建符合HRC标准的模型，大大提高了模型的兼容性和可扩展性。

HRC的核心元素是组件。HRC借鉴了Eiffel方法，支持契约的定义。一个HRC组件可以拥有任意数量的接口，每个接口都与组件的功能或非功能属性紧密相关。HRC与其他基于块的规范方法类似，例如SysML内部块图或Simulink块模型，具有良好的直观性和可理解性。每个接口都可以关联任意数量的断言（假设或承诺），具体定义如下：

- 假设：在接口声明中，假设描述了从环境通过该接口输入的预期属性（信号、物理或逻辑属性），这些属性不受组件本身的控制，是组件正常运行的外部条件。

- 承诺：同样在接口声明中，承诺是指在环境满足对其他组件接口所做假设的前提下，组件接口保证具备的属性，体现了组件的功能和性能保证。

单独来看，一个HRC组件及其相关断言可以如图27所示进行清晰展示。

接口通常以流接口的形式呈现，但也可以为工程过程中涉及的任何系统属性（如组件重量或成本）创建接口，以满足不同场景下的建模需求。

接下来，需要将不同组件的假设和承诺相互关联，形成契约。通过契约，可以明确一个组件输入接口的假设特性确实能够由提供信息的组件输出所满足。图28展示了组件K1和K2的接口之间捕获的契约。其语义为，对于契约C1，假设A21必须由承诺P11来满足，确保了组件之间的交互和协作的正确性。

断言可以用普通英语进行指定，但为了实现更精确的规范和形式化分析，该项目还开发了一种形式化语言——契约规范语言（Contract Specification Language，CSL）。使用CSL进行规范能够实现形式化分析，因此，只要使用CSL对K1和K2进行明确规范，就可以准确确定契约C1是否得到满足。契约将断言进行分组，可以在以下几种情况下的接口之间进行制定：

- 同一分解层级的组件之间：确保同一层级组件之间的交互符合预期，保证系统的整体功能正常运行。

- 具有父子关系的组件之间：保证父组件与子组件之间的功能衔接和属性传递正确，实现系统的层次化设计和管理。

- 不同抽象层级描述系统的组件之间：实现不同抽象层次的系统描述之间的一致性和连贯性，使得系统在不同粒度上都能得到准确的建模和分析。

SPEEDS技术（包括工具支持）目前尚未完全成熟，暂时无法在工业领域大规模应用。不过，萨博（Saab）和空客（Airbus）等公司正在对其可扩展性进行评估，期待未来它能在行业中发挥更大的作用。

4.4设计技术

设计技术（或方法）有助于工程团队理解、分解、分析和记录工程问题及探索出的解决方案。在所有已记录的设计技术中，这里介绍一小部分与航空电子设计相关的技术。

4.4.1设计矩阵

矩阵是一种强大的工具，可用于系统地分析和记录设计活动中的关系。矩阵的每个轴上可以包含任何类型的信息，这里描述两种定义好的矩阵类型：公理设计和依赖结构矩阵。

公理设计

：公理设计是一种基于两条规则/公理的设计方法，它使用矩阵可视化来分析客户需求到功能需求、设计参数和过程变量的转化。该方法名称源于其使用的设计原则或设计公理（即无需证明的给定条件），这些公理指导着高质量产品或系统设计的分析和决策过程。该方法由N. P. Suh博士开发。这一理论的基础由两条原则——公理组成：独立公理，即保持功能需求的独立性；信息公理，即最小化设计中的信息含量。

根据图29定义了四个领域。客户领域的特点是客户需求或客户所寻求的属性。在功能领域，需求是根据功能需求{FR}和约束{C}来指定的。为了满足指定的{FR}，在物理领域中使用设计参数{DP}。最后，为了生产出用{DP}描述的系统，在过程领域中必须开发一个以过程变量{PV}为特征的过程。即{FR}到{DP}的映射是通过设计矩阵[A]线性完成的。在分析[A]时，特别是其稀疏性，可以确定给定设计中存在多少耦合。如果[A]是三角形的，则称该设计是解耦的；如果是对角线的，则称该设计是无耦合的；否则就是耦合的。独立公理指出，设计应尽可能无耦合，如果无法实现，则至少应是三角形的。信息公理表明，信息（复杂性）应保持在最低水平。

依赖结构矩阵

：依赖结构矩阵（DSM），如图30所示，是一种紧凑的矩阵表示形式，用于表示一个系统，它列出了所有组成子系统或设计参数，并重点关注它们之间的相互依赖关系和信息流。DSM分析有助于深入了解如何管理复杂系统或项目，突出信息流、任务序列和迭代。它可以帮助设计团队优化不同相互依赖组件之间的信息流。DSM分析还可用于管理变更的影响。例如，如果必须更改某个组件的规格，可以快速识别所有对该规格的依赖关系，从而降低遗漏接口变更的风险。另一种类似的技术是质量屋（HoQ）方法，它将功能到组件的映射分析与组件到组件的依赖关系相结合。有关这些以及飞机设计中其他基于矩阵的方法的更详细描述和总结，请参见[Gavel 2007]。

4.4.2功能/手段树

在处理大量、稀疏的数据时，矩阵会变得繁琐，此时功能/手段树（或F/M树）更为合适，如[Johansson 2006]中所述。这是一种用于功能分解、将功能分配到实现手段（满足需求的组件）以及概念生成的方法。它支持概念的详细开发，并能够以结构化的方式处理大量数据。对于具有许多软件应用程序的模块化航空电子系统（即IMA），这些基于分配的设计技术对于依赖关系分析和工程支持非常有价值。

功能/手段树建模

：通过促进对先前深入研究产品的概念模型的重用，可以将更多时间花在开发包含新一代产品优势的部分上。功能/手段树建模是一种将主要功能分解为子功能的方法，这些子功能带有可替代的解决方案元素，并可以按层次结构进行排列，如图31所示。通过这种方式，可以指定一个解决方案空间，从中生成不同的概念。在详细的功能-手段树中，相同的功能会在许多地方重复出现，尤其是在较低层次。需要重用现有的子树，以避免信息重复、不一致和大量维护工作。一种解决方法是使树中的一个对象（例如一个功能）能够从另一个功能继承其所有信息，包括子树。在论文[III]中可以找到功能-手段模型的示例。

大型F/M模型的对象继承技术

：复杂产品的概念设计需要付出相当大的努力，因为如果产品模型要涵盖重要方面，其规模会变得非常大。为了应对这一整体工作，设计师必须依赖传统设计并进行重用，并在产品代际和变体之间逐步改进产品概念。论文[III]中描述了一种称为通用对象继承的广义继承机制，它能够在概念产品模型的层次分解结构的任何级别快速重用和修改模型。这使得修改后的概念能够保持在完整的可分析产品模型的上下文中，从而可以研究变更的影响，而无需维护相同对象结构的多个副本。该论文描述了通用对象继承如何用于开发小型商务喷气机概念产品模型的下一代版本。在创建新版本模型时，重用了先前版本的基本部分，并对设计参数和子结构进行了微小修改。

4.5分析技术

模型代表了系统的不同方面，这些方面可以通过分析模型来（部分）验证。因此，进行分析活动是为了检查或验证系统设计。当使用大型或复杂模型来指定系统时，对模型本身进行一些分析（例如静态模型检查）是合适的，如检查一致性、语义或语法。在系统层面，分析/验证的一项重要（且通常成本高昂）的活动是仿真。在组件或子系统层面，在建模工具或特定（中型规模）仿真软件/环境中进行的桌面仿真，能加深对系统设计的理解并增强信心。对于整个飞机系统，这项活动的特点是大规模仿真，如第5章所述，有特定的前提条件。

4.5.1故障树分析

故障树分析（FTA）是一种自上而下的分析技术，用于识别可能导致已识别的系统级危险的因素（错误/故障/失效）。FTA是一种反馈技术，即从系统级危险开始，通过识别所有可能的危险原因逆向推导。有关FTA的参考资料，请参见[ARP 4754 1996]和[Herrmann 1999]。

4.5.2 中型规模仿真

测试在基于软件的模拟器和基于硬件的系统模拟器（试验台）中进行，试验台配备与产品相当的计算机和其他设备。中型到大型规模的仿真有不同类型的模拟设施：

桌面仿真工具

：价格便宜且易于使用。

操纵品质模拟器

：基于软件，可选择是否有飞行员参与。

演示与机动模拟器

：专注于人机交互。

系统模拟器（试验台）

：配备大量目标硬件和其他与产品相当的设备。这种类型的仿真被定义为大规模仿真。

图32展示了一种用于中型规模飞行员参与的较简单模拟器。基于软件的仿真模型易于在一系列不同的用户场景下执行，也可以 “批处理模式” 运行，最好在 “非工作时间” 进行分布式计算，以最大化公司计算资源的利用率。通过选择输入值（例如负载配置、燃油量、速度和高度）创建一组场景。在数千个模拟场景/机动动作中，包括降级模式，挑选出关键的机动动作进行进一步验证。对于每种有效载荷组合，选择一组最严重和关键的机动动作进行飞行员参与的仿真，甚至可能进行飞行测试。关于这类 “中型规模” 仿真的更多细节，可在论文[I]和[II]中找到。基于模型的方法依赖于仿真工具，其一个缺点是某些方面难以覆盖，因此无论如何都必须构建一个包含系统真实组件的测试台。例如，在验证多通道系统时，诸如冗余策略、定时和性能等通道间行为，必须在基于硬件的试验台（配备目标软件）中与基于模型的功能验证并行进行单独测试。

故障注入

：需要针对不同的故障条件建立模型进行模拟和分析，并用于飞行员训练。当然，要模拟的故障取决于相关系统，但经验法则是系统中的传感器容易出错。如何对传感器的故障条件进行建模很重要，并且有很多不同的方法，下面列出几个例子：

间歇性故障

：反复出现和消失的故障，例如松动的连接器。

早期故障

：从无故障逐渐发展为越来越严重故障的情况，例如组件的缓慢退化。

突然变化

：变量出现非常快速变化的故障，例如组件的突然故障。

为了便于在传感器或其连接中处理故障，在建模框架中构建故障注入功能很方便。然后，每个传感器模型都增加了额外的输出设置，如图33所示。这是一个传感器信号通用故障注入设置的示例，根据萨博航空系统公司的经验，这种通用功能在中型和大型规模的建模和仿真中非常有用，因为它易于实现和使用。当然，对于某些类型的分析或飞行员训练，特定的传感器故障是必要的，这些最好由设备/传感器供应商内置在传感器模型中。

5. 开发环境

一个对航空电子设备开发特别有用的工程环境，是由一套协同工作（即集成）的工程工具构成的。良好集成的工具能减少用户与单个工具交互，以及在不同工程工具之间手动传输数据所浪费的时间，更不会出现更糟糕的情况，比如在不同操作系统（Solaris、Windows、Linux等）上运行的工具/应用程序之间传输数据。该环境还包括流程/方法描述、培训和支持资源。出于可扩展性考虑，管理用户账户、用户组、权限及其他安全相关问题的管理支持也很重要。对于一个现代高效的环境而言，灵活访问用于深度分析和桌面模拟的计算资源必不可少。

5.1高效团队合作的基本要求

开发环境需要满足一系列需求，以实现高效的团队合作。明确规定特定工具或完整工具链的具体要求很困难，例如，工程师们作为个体，需求、技能和偏好都有所不同。有些人更喜欢基于文本的用户界面，而另一些人则青睐用于与工程工具进行交互和工作的图形用户界面。下表4列出了作为SPEEDS项目一部分得出的 “系统需求”，这些需求主要来自萨博航空系统公司，同时空客和以色列航空工业公司也提供了重要的输入信息。这份清单并非详尽无遗，但它表明了实际的航空航天项目和公司所关注的需求类型。清单中使用的缩写有：SM——系统模型；SMIDE——系统建模集成开发环境。

5.2.2Modelica及相关工具

[Modelica]是一种描述性的、面向对象的建模语言，适用于基于物理的行为和性能仿真与分析。它有开源和商业的模型库，通常支持机械、电气、电子、液压、热、电力或过程导向的组件。下面是一个理想电容器组件的文本模型定义示例。在这个模型中，参数（C）用于实例化具有不同电容值的模型。这种参数化的组件非常适合通过模型库在用户之间重用和共享。有关使用Modelica进行建模的参考，请参见[Fritzson 2004]。

Dymola

：动态建模实验室[Dymola]，是最成熟的Modelica建模和仿真环境。在图34中，展示了一个Dymola模型，它使用了上述定义的电容模型实例，电容值为2200μF。根据萨博航空系统公司的经验，Dymola已达到工业工程环境中进行中等规模建模和仿真所需的成熟度水平。

5.2.3基于数学的工具

Matlab

：矩阵实验室[Matlab]，是一个具有高级Matlab语言和交互式环境的工具，能够以解释方式进行计算原型设计。多年来，工程师和科学家因其数据处理能力，即数据转换和可视化/绘图功能，而选择使用Matlab。在控制理论领域，有多个用于特定设计和分析技术的工具箱。

5.2.4信号流建模工具

这些工具的功能逐渐扩展，例如增加了离散状态图，并支持物理组件和功率端口技术。

SCADE

：[SCADE]代表安全关键应用开发环境，是Esterel Technologies公司的商业产品。它基于正式的、同步的和面向数据流的Lustre编程语言。该工具集可以生成C或Ada代码，据其供应商[Esterel]称，它已被认证为适用于DO - 178B最高到A级的开发工具。因此，其主要应用领域是航空航天和航空电子，但也用于其他行业（如汽车、铁路运输和核电站）。

Simulink

：[Simulink]是基于Matlab构建的用于动态系统多域仿真和基于模型设计的平台。它基于时域，提供了一个交互式图形环境和一组可定制的模块库，可用于特定应用的设计。Simulink的模块集包含用于连续和离散模型的模块。在图35中，展示了与图22相同模型的两种不同Simulink表示，一个是连续时间模型，另一个是离散时间模型。Simulink仿真引擎包含一组基于常微分方程（ODE）的积分算法或求解器。复杂的ODE求解器使用可变时间步长，自适应地选择与系统最小时间常数相匹配的时间步长，并且在截断误差超过用户设置的限制时进行回溯。从R2008b版本开始，Simulink团队实现了一种基于Matlab的建模语言（Matlab方言），称为[Simscape]，用于多物理非因果建模和仿真，与Modelica类似。

SystemBuild

：[SystemBuild]是MATRIXx产品系列的一部分，是一个用于模型开发和仿真的图形环境，适用于大型模型的管理。通过分层组织，模型可以在不同级别进行分段。其结构化原则简化了模型的重用和共享。它具有用于系统验证和模型确认的仿真和分析功能。SystemBuild与Simulink非常相似，但市场份额较小，近年来在新功能和工具箱开发方面也不如Simulink活跃。论文[I]中对SystemBuild有更详细的描述，论文[IV]中对它和Simulink进行了比较。

5.2.5UML和SysML工具

标准化组织对象管理集团（OMG）发布了统一建模语言[UML 2007]和系统建模语言[SysML 2008]的规范。这两种语言都是通用的面向对象图形建模语言，用于指定、分析、设计和验证复杂系统。UML提供了具有语义基础的图形表示法，用于对行为和结构进行建模。SysML是UML的一个子集，并进行了扩展，增加了系统工程所需的需求和参数（基本数学支持）。它们对构建仿真模型的支持较弱，但大多数工具都有代码生成引擎，支持编译和执行。图36展示了SysML 1.1中定义的图表类型。对于特定项目而言，减少使用的UML/SysML图表类型是很方便的，因为图表类型之间存在一些重叠。有限的图表类型集也简化了UML/SysML建模的引入，包括指南制定、培训和工具设置。如论文[V]中所述，在航空电子系统开发中，适合开始使用的一组图表是：用于分析的用例图和活动图；用于设计、实现和测试的类/块定义图、序列图、状态机图和部署图。SysML还内置了维度和国际单位制（SI）单位的定义（例如，“维度：频率，单位：赫兹” 或 “维度：功率，单位：瓦特”）。还可以添加 “用户定义” 的单位，这在航空电子/航空规范和设计中是必要的。在航空领域，飞行速度和高度通常以非国际单位制的节（Knot）和英尺（Foot）来处理。有关SysML语言的更多详细信息，例如可参见[Herzog 2005]、[Friedenthal 2008]和[Weilkiens 2008]。以下是一些能够进行UML和SysML建模的商业工具示例。此外，还有一系列免费软件工具，特别是用于UML的工具。

Magic Draw

：[Magic Draw]是一款新开发的工具，具有现代的外观和使用体验，被定位为与XMI存储格式兼容性最佳的UML工具。Magic Draw有一个用于SysML版本的插件，称为 “Paramagic”，它将SysML中的参数与数学/分析工具连接起来。这种集成背后的基本原理和概念可在[Peak 2007]中找到。

Rhapsody

：IBM/Telelogic的[Rhapsody]，是一个用于软件密集型系统模型驱动开发的环境，用于规范、设计和测试。Rhapsody使用UML和SysML符号以图形方式指定系统和软件设计，使系统工程师和软件开发人员能够对软件进行仿真和验证。尽管Rhapsody的背景和主要应用领域是软件开发，传统上对系统工程的支持较弱，但SysML插件正逐渐成熟。图37展示了Rhapsody中用户定义的单位节（Knot）和英尺（Foot）的可视化示例。在论文[V]中，描述了萨博航空系统公司和Skeldar项目中使用UML/SysML的应用示例。

5.2.6面向状态的建模工具

随着图表层次结构的引入[Harel 1987]以及在 “StateMate” 工具中的实现，基于状态图形式的面向状态建模在工业领域取得了突破。

Stateflow

：[Stateflow]是Matlab/Simulink的插件工具，它与StateMate中实现的状态图的主要区别在于动作语言。Stateflow的动作语言主要进行了扩展，以便引用Matlab函数和Matlab工作区变量。此外，在转换表达式中添加了条件动作的概念。

BridgePoint

：在[BridgePoint]中，使用UML子集 “可执行UML”（xUML）作为建模符号。这种技术源于Shlaer - Mellor方法，参见[Starr 1996]，并采用了3.3.3节末尾所述的MDA原则。为了从BridgePoint系统/软件模型生成代码，规则和映射由一个元模型定义，与系统/软件模型的定义方式相同。这使得能够以比许多其他工具更灵活的方式创建用户可调整的结构和代码布局。例如，在Simulink/Stateflow或Rhapsody中，使用与系统建模语言不同的语言来控制代码布局，这需要额外的技能。

5.2.7基于事件的仿真和分析工具

对于大型模型或系统的基于事件的仿真，工具需要具备一些基本功能或建模实体，如时钟、事件列表、随机数生成器和统计报告。

SimEvents

：作为Simulink/Stateflow的一个模块集，[SimEvents]插件能够对基于事件的系统进行仿真并创建图形模型。SimEvents与Stateflow配合使用，可表示包含详细状态转换图的系统，这些状态转换图可能产生或受离散事件控制。它以仿真为导向，具有统计测量功能，但没有基于形式化方法的实际分析引擎。

UPPAAL

：UPPAAL是由乌普萨拉大学和奥尔堡大学合作开发的工具，用于实时系统的建模、仿真和验证，参见[UPPAAL 2008]和[Behrmann 2006]。它适用于将系统建模为具有有限控制结构和实值时钟（即时序自动机）的非确定性过程集合，这些过程通过通道或共享数据结构进行通信。典型应用包括实时控制器、通信协议以及其他对时间要求严格的系统。UPPAAL工具既有用于建模的图形用户界面，也有用于例如批处理验证的命令行界面。例如，[Braspenning 2008]报告了其在大规模使用方面的研究，但UPPAAL仍然是一个面向研究的工具。尽管用于分析较大模型的算法已经得到改进，但状态爆炸问题仍然是一个需要进一步研究的问题。

5.2.8工具总结

表5按建模领域列出了一些工具，并根据3.4.2节的分类，将其分为规范工具和分析工具。本节和表格列举了与定义的建模领域相关的工具示例。然而，本文未列出其他对航空电子设计和飞机仿真很重要的工程方法/工具。

5.3集成

特定领域建模的进步为其主要目的创造了强大的工具，如表5所示。从宏观角度看，许多工具的建模或分析领域有限，这凸显了整合不同建模领域的信息/模型的必要性。为了进行更大范围（例如飞机层面）的分析或模拟，需要集成基于不同建模技术的模型和工具。理想的情况是，一个系统模型由以下三种（子）模型集成而成：用于性能评估和尺寸确定的硬件模型（如电学中的电阻器和电容器，或流体学中的管道和喷嘴）；用于控制和监测硬件的嵌入式软件模型；系统环境模型，例如其他子系统。目前，系统工程活动中的信息交换主要依赖于专有数据格式的文本文档和电子表格，但数据交换标准正在不断涌现，例如：AP233 - ISO 10303，即系统工程数据交换标准，参见[AP233]；XMI - XML元数据交换，为UML框架定义，参见[XMI 2002]；RIF - 需求交换格式，参见[RIF 2008]。在本节的其余部分，将介绍一些集成策略，并以鹰狮（Gripen）航空电子演示器为例进行说明。

5.3.1集成策略

由于产品采用基于分层构建块的结构，不同集成级别以及不同建模领域的信息和模型通常需要集成，以用于分析和/或验证活动。[Carloni]认为，单一环境无法满足使用混合/集成模型来表示正在开发系统的设计师的全部需求。例如，对物理系统与作为软件实现的控制和监测算法进行联合仿真。论文[II]中介绍了用于这种集成目的的托管仿真技术。根据萨博航空系统公司的经验，应选择 “松散集成” 策略，以避免锁定效应和工具集成（“工具胶水”）的高昂长期维护成本。这就要求明确定义或标准化格式和接口，以便集成工具并维持这种集成。另一方面，紧密集成依赖于工具在执行分析或仿真时相互连接并并行运行，同时进行数据交换。松散集成概念降低了对同时使用两个或多个工具的依赖。建模领域之间存在多个需要集成的接口。在图38中展示了主要的集成需求模式，从左侧的 “重型” 硬件/结构开始，经过设备、电子、控制和信息，到右侧的 “轻型” 图形布局。在分析开发工具的特性时，有趣的是许多工具供应商试图通过为其工具添加功能来覆盖越来越多的领域。参考图38，有三个例子：达索系统（Dassault）宣布将Modelica集成到CATIA的未来版本中，扩展其动态仿真能力（在图中为CATIA向右扩展），参见[Dassault 2006]；在Modelica语言中，已经开发了用于Petri网和状态图的库，以扩展Modelica的功能（在图中向右扩展），参见[Modelica]；Simulink与Stateflow集成（在图中向右扩展），并通过Simscape进行增强（在图中向左扩展），参见[Simulink]、[Stateflow]和[Simscape]。

具有支持多个建模领域功能的工具固然很好，这使工程师和团队在进行特定工程任务时可以在多个工具中进行选择。然而，在大型项目中，随着时间的推移会组建多个团队，每个团队专注于特定的工程任务，并且团队在选择工具链方面有一定的自由度，这可能会导致工具的多样性以及使用方式的差异。从长远来看，这可能会导致方法/工具的实施不够优化，效率低下，特别是在规范建模方面。关于仿真建模，建模领域的连接或集成在不同层面进行。在组件和子系统层面，可以使用协同仿真或托管仿真技术在桌面工具中进行集成仿真。在更高的集成层面，则需要使用更高效的执行技术来进行大规模仿真。

5.3.2软件设计的行为建模

早期阶段的行为建模以概念化的方式进行，专注于系统功能及其相关的驱动需求，通常采用简化的视图，例如使用基本的活动图或序列图。这里不再进一步讨论。在后期阶段，采用组件方法更为合适，即确定架构、定义组件，并使用UML、Simulink或类似技术对每个组件的详细行为进行建模。参考论文[I]和[IV]，以下讨论软件设计行为建模的一些方面。论文[IV]中介绍了三种不同的使用Simulink进行详细软件设计的方法：

面向功能的系统建模与仿真方法

：该方法以功能为核心，模型足够完整以便进行仿真，但从实现角度来看较为抽象。

面向实现的规范方法

：该方法基于具有预定义系统架构、调度、数据类型和离散化规则的建模框架。最终的嵌入式软件根据模型规范进行手工编码。

与方法二类似，但此处嵌入式软件使用高质量代码生成器自动生成

。

图39展示了不同方法与开发过程的映射关系。在论文[IV]中可以找到关于这三种方法的更详细信息以及使用Simulink创建的小模型示例。论文[I]描述了鹰狮飞行控制系统的基于模型的开发过程，其中使用的建模工具是SystemBuild，采用的方法是上述中间方法（方法二）。

5.3.3集成仿真技术

有多种商业和内部开发的工具可用于连接不同的仿真模型。使用和集成来自不同领域的仿真模型面临着越来越大的挑战，因为最终系统验证越来越依赖于仿真模型的结果，而不是昂贵的飞行测试。计算机性能和建模与仿真工具的发展使得仿真规模越来越大。因此，对集成模型及其验证的需求也在不断增长。当模型基于不同的建模技术/工具时，这就成为了一个挑战。飞机系统的仿真（子）模型可以分为以下主要类别：用于性能评估和尺寸确定的设备模型（例如电学中的电阻器和电容器、液压学中的管道和喷嘴）；用于控制系统功能以及监测功能和设备/硬件的嵌入式软件模型；系统环境模型。有多种方法可以进行集成仿真。这里介绍两种用于桌面仿真（适用于中等规模）的方法。

协同仿真

：协同仿真的概念是将来自不同仿真引擎的模型集成在一起并同时执行。这种方法得到了多个工具供应商的支持，他们提供插件或软件包来连接工具以进行仿真设置。协同仿真非常适合通过数据总线连接的电子控制单元（ECU）系统，但在连接的模型存在物理交互，需要使用功率端口建模技术和中央方程求解器时，其作用就相对较小。

托管仿真

：另一种组合仿真模型的方法是托管仿真（HS），在仿真过程中，使用其中一个建模和仿真工具的仿真引擎来 “托管” 其他模型。自然地，模型是使用不同的工具开发的，这些工具依赖于不同的建模技术，每个工具都专注于支持特定的工程学科。当为了仿真目的组合这些模型时，集成模型的范围可能超出了任何一个建模工具的能力。托管仿真方法通过代码生成来实现。在一个工具中创建的模型被简单地生成为可执行代码，然后导入（托管）到另一个工具中进行仿真。该原理和定义源自[SPEEDS]项目。通过托管仿真，工程团队可以将多种类型的系统（如机械、液压或电气系统）与传感器、控制和软件等系统组合在一起。最终的模型结构是一个异构工程系统，这是应对飞机系统开发复杂性的一个示例。

集成仿真技术的评估

：在论文[II]的工作中，对两种不同的托管仿真方法进行了评估：一种是以功率端口工具（Dymola）作为托管工具，另一种是以信号流工具（Simulink/Stateflow）作为托管工具。主要结论是，如果要分析的系统以设备（硬件）为主，则首选Dymola作为托管工具，反之亦然。对于软件和硬件含量都相当高的系统，建议采用同时依赖这两种方法的流程，因为综合分析结果将为系统验证和确认提供重要依据。进一步研究发现，与协同仿真相比，托管仿真技术具有以下优点：用户无需拥有所有工具即可执行仿真，只需要仿真工具；所有仿真结果都可以在单个工具中获取；它具有更好的性能，因为无需使用消息总线，也无需在不同仿真器之间进行协调；即使设计工具没有仿真功能（许多UML工具就是如此），它也能够模拟与组件的交互。其主要缺点是无法查看托管模型的内部行为，只能监测它们之间的交互。托管仿真的应用主要限于桌面和基于软件的仿真系统，通常认为其规模为中等。论文[II]中提供了更多关于托管仿真的详细信息。

5.4示例

附录中的论文提供了一些基于模型的系统工程（MBSE）/基于模型的开发（MBD）应用示例，以及所使用的开发环境和工具：

论文[I]中，通过建模进行设计和开发，并对配备 “相位补偿速率限制器” 的鹰狮飞行控制律进行了大量批处理仿真分析。同时，还介绍了为鹰狮产品中的 “合成姿态和航向参考系统（SAHRS）” 功能设计 “扩展卡尔曼滤波器” 的过程。

论文[II]中，构建了无人机（UAV）燃油系统模型，分别在功率端口工具Dymola和信号流工具Simulink中进行建模，然后通过托管仿真进行分析。

论文[III]中，使用FMDesign工具通过功能/手段建模，构建了虚构的小型商务喷气式飞机RAVEN的概念设计模型。

论文[V]中，在开发SKELDAR V150（一种短至中程移动无人机系统）的过程中，使用UML/SysML和Rhapsody工具进行系统建模和规范制定。

另一个示例来自萨博航空系统公司的鹰狮航空电子演示项目，展示了鹰狮新应急模式的开发过程。功能原型设计包括架构、信号流和显示布局，如图40所示，该模型由以下部分组成：

用SysML构建的架构模型

用VAPS XT构建的显示布局模型

包含缩放、滤波和逻辑功能的Simulink模型

当初步设计通过评审并达成一致后，项目便从原型或概念阶段进入开发阶段。此时，转变对模型本身的看法非常重要。在概念阶段，模型应易于修改、测试新的变体，并在无需所有细节的情况下进行仿真等操作。从概念阶段过渡到开发阶段时，模型要进行形式化转换。所有不符合建模规则和指南的部分都要进行替换，例如，要明确计算速率，将时间连续的模块替换为离散时间的等效模块。此外，还需对额外的模型注释和文档进行评审，以确保在长期内能够高效地更新和维护该功能。

目录

1.飞行器系统建模综述（上）

2.飞行器系统建模综述（下）