6. 模型管理

本节概述了前面介绍的基于模型的方法和工具如何融入现有的飞机或航空电子嵌入式系统典型开发环境。在产品的整个生命周期中，需要对模型、建模技术以及支持工具进行管理。每次模型更新都必须经过验证，以确保其可广泛使用。模型的配置支持与最终产品的配置支持有所不同，因为一个模型通常可能代表最终产品的多个变体。对现有和新的方法学概念进行评估、安装工具更新以及开展培训，这些也都属于建模框架管理的范畴。

6.1模型管理策略

对于复杂产品而言，从传统的以文档为中心的方法转变为基于模型的方法时，必须精心制定和规划如何管理模型集以及进行扩展的策略。这些策略包括形式化方法、配置管理，以及确定特定模型在认证过程中是否需要认证以及如何认证等内容。具体来说，这包括以下方面：

区分系统模型与系统中各个组件的模型。

区别管理软件模型和硬件模型。

重用功能/部件，并将可重用的部分存储在库中。

采用不同程度的形式化；明确哪些模型是形式化的，需要进行验证并实施更严格的生命周期控制。

管理用于规范的模型和用于分析的模型。

本节其余部分将深入讨论分离、重用和验证等方面的内容。

6.1.1系统层级的分离

为了便于团队并行工作，模型的划分和模型组件的规模设定了边界。图41展示了一种适用于系统/软件开发的分离方式，并给出了针对不同模型可使用的工具示例。在顶层，系统模型相对独立于其他模型。在系统模型中，定义了组件名称、接口和通用定义。在分隔线下方，各个组件作为独立的模型进行开发，各自采用不同的方法：基于Simulink的方法、以文档为中心的方法以及基于xUML的方法。规则是允许组件模型依赖系统模型，但系统模型不依赖任何组件模型。这意味着所有可重用实体的库（例如类型定义、单位定义和滤波器功能模块）都属于系统模型。当组件模型与系统模型在相同的（UML/SysML）工具中开发时，可以使用引用机制从组件模型访问相关定义，避免重复定义。对于每个组件，还有一个用于组件架构和 “本地” 定义的顶层框架模型。

6.1.2库支持

另一个重要的扩展和管理问题是对工程组件重用库的支持，这些库包含 “遗留” 信息，如规范、设计或实现。在概念阶段，需要有关可用技术和设备（数据表）的信息，而在后续阶段，更需要设计模式或经过验证的算法/功能。论文[III]中描述了对概念开发中大规模工程数据管理（EDM）的支持。对于航空航天系统而言，验证方面至关重要，在详细设计阶段使用的可重用组件库中应涵盖这方面内容。在诸如Simulink或Modelica等用于系统设计和分析的设计环境中，可重用模块的块库是基础。在构建行为模型时，工程环境中需要提供这两种用户自定义和内部开发的组件（块）库，并且易于访问：

主要用于桌面仿真的物理组件/设备模型，例如泵、阀门和涡轮机（“组件模型”）。

用于实时嵌入式软件的可重用复杂功能，例如滤波器、锁存器和坐标变换（“模型组件”）。

对于 “组件模型”，Modelica语言是合适的建模手段。“模型组件” 可以通过多种方式在Simulink中实现：作为S函数、模型引用或嵌入式Matlab块。为了创建/修改块库并确保其质量，定义了一个简单的流程，如图42所示。开发这两种组件都采用相同的基本流程。有多种方式可以对设计库进行分层组织，以便在创造性的交互工作中轻松找到可重用组件。通常情况下，不存在适用于所有类型交互搜索任务的单一层次结构。可重用对象可以根据不同方面进行分类，并通过多个并行的分类树进行访问。论文[III]中描述了一种构建多个并行分类树的技术。

6.1.3模型验证

与系统验证类似，模型验证旨在回答 “我们构建的模型正确吗？” 这一问题。图43改编自[Sargent 2007]，描述了建模过程中的验证和确认。问题实体是需要建模的系统。概念模型是系统的数学/逻辑表示，通过模型规范进行描述。计算机化模型是在计算机中实现的概念模型。图43中活动的定义依据[Sargent 2007]：

概念模型验证是指确定概念模型所基于的理论和假设是否正确，以及模型对问题实体的表示对于模型的预期目的是否 “合理”。

计算机化模型验证是指确保概念模型在计算机编程和实现方面的正确性。

操作验证是指确定模型的输出行为在模型的预期适用范围内，对于模型的预期目的是否具有足够的准确性。

使用诸如Dymola或Simulink等建模和仿真工具（例如，更多参考见论文[II]），可以减少编程和实现错误的数量。计算机化模型验证活动主要确保使用了无错误的仿真工具，仿真语言在计算机上得到了正确实现，并且模型在仿真语言中的编程正确。由于需要来自实际系统的测量数据，操作验证活动在早期开发阶段（如概念阶段）无法完全进行。不过，仍可以进行敏感性分析，以指出对整体仿真结果有重大影响的模型组件参数。

6.2模拟器和仿真模型

航空航天领域进行仿真的主要目的是降低风险和成本。在早期阶段，通过更好地理解如何对系统/产品进行规范以及明确严格的限制条件，来降低风险和成本。在后期阶段，仿真生成 “飞行小时” 数据，为工程师和飞行员提供有关系统的知识，用于验证和实际使用。本节将讨论与建模/开发环境相关的一些仿真方面的内容。

6.2.1系统验证

验证的目的是回答 “系统是否满足指定要求？” 这个问题，简而言之就是 “我们做对了吗？”。验证可以采用多种方法，包括测试、检查、演示和分析，不过测试通常是系统验证的主要活动。当系统的模型可用（并且已经过验证）时，在验证活动中，该模型可替代真实系统。验证活动根据V模型在不同级别进行：功能验证、软件测试/验证、系统测试/验证。

6.2.2大规模仿真

长期以来，萨博航空系统公司的经验表明，在集成多个电子控制单元（ECU）、数据总线、显示器和控制器时，仿真被证明是一种有效的方法，并且是对大型、安全关键的航空电子系统进行系统验证最常用的手段。一个仿真系统包含硬件和软件，但趋势是更多地依赖设备的软件模型，而这些设备以前要么是生产设备的原型，要么是简化的（硬件）等效设备。基于软件的仿真系统的引入，使得使用更加灵活多样，例如可以通过批处理仿真进行分析。但同时也出现了新的挑战，例如配置管理方面的问题，如下所述。

批处理模式仿真

：批处理分析通过在一组指定的操作点上运行仿真（由脚本自动执行）来进行。创建场景的方式与中型规模仿真中描述的相同。也可以在稳态或动态仿真过程中引入故障。效率取决于每次仿真前获得稳态操作点所需的时间。一种提高效率的方法是提前计算并将稳态解保存到库中，然后在批处理运行期间使用这些解来初始化仿真模型。对于高效的批处理模式仿真，表4中的需求S1、S2和S4是主要驱动力。

规模扩展问题

：开发项目通常试图尽量减少系统模型的数量，因为这需要大量的管理工作，而且处理多个模型时可能会出现错误。挑战在于在系统级系统的背景下重用和组合组件模型，同时避免过多的参数设置，从而不会导致过长的执行时间。所以，一方面应该有可重用且可配置的（详细）模型，适用于小型和大型规模的使用场景；另一方面，应该有足够详细或专用的模型，使用户能够更轻松地在特定级别设置和执行仿真。一种避免使用多个不同模型的方法是采用[Kuhn 2008]中报道的多层次方法。通过多层次方法，可以在不同模型级别之间进行切换，例如：用于能耗设计的简单快速模型；用于快速网络稳定性分析的详细模型；通过增加模型组件中的方程复杂度，用于网络质量评估的详细模型。当然，使用多层次方法也存在一些限制：例如，模型的接口定义在所有细节级别（视为黑盒）都必须相同。

配置原则

：对于仿真系统而言，配置管理方面的挑战在某些方面比仿真模型所代表的产品更加困难。这是因为每个子模型都可以配置为代表真实组件的多个变体。例如，在鹰狮战斗机的案例中，一个用于计算重量、重心和惯性的模块，必须管理单座和双座版本以及所有可能的有效载荷配置的数据。配置管理分多个阶段进行，在大型规模的模型仿真环境和模拟器平台中，通常有一些用于（变体）配置的机制。硬件和软件组件都是模拟器配置活动的一部分，并且必须存在预定义的规则，以支持根据安装的设备类型进行变体处理和系统软件的机载配置。这个问题可以通过切换技术来解决，如模型时间切换、编译时间切换或运行时间切换。模型时间切换会创建不同的源代码变体，编译时间切换会创建不同的目标代码。运行时间切换是最灵活的选择，它使仿真工程师能够在 “飞行过程中” 更改配置。对于特定的选择情况，使用哪种切换技术取决于多种因素，例如安全性、保密性和可维护性。对于所有这些技术，类似于综合模块化航空电子（IMA）部分中描述的结构化配置表，能够提高仿真/开发过程的效率和可扩展性质量。

6.3工具管理策略

一方面是紧密集成的方法-工具链，另一方面是各自在其专业领域提供前沿工程支持的独立工具，这两者之间需要权衡。集成方式可以是对等类型的，将一个工具与另一个工具连接以进行单向或双向信息传输；也可以更倾向于平台类型，将多个工具插入到预定义的框架中，比如开放式开发平台[Eclipse]。本节将讨论一些战略选择：集成的紧密程度、集成方式以及使用的技术，因为这些因素会在很长一段时间内决定可能性、局限性和成本水平。一种解决方案是依赖成熟的标准化接口，而不是工具供应商特定的接口和插件，因为后者随着时间推移更有可能发生变化。

6.3.1工具选择标准

以下参数构成了选择基于模型的系统工程方法的决策基础。理想情况下，建模方法应：

具有广泛的市场渗透率并基于标准。

具备从系统工程无缝过渡到专业工程的能力。

有多个商业工具支持该语言/符号。

在[Friedenthal 2008]中，有一份SysML工具的选择标准列表，例如：

符合SysML规范

文档生成和导出能力

符合XMI和AP233标准

与其他工程工具（包括现有系统开发环境中的遗留工具）集成

需求和配置管理工具

工程分析和性能仿真工具

软件、电气建模和机械CAD工具

测试和验证工具

项目管理工具

性能（用户数量、模型大小）

模型检查

培训、在线帮助和支持

模型库的可用性（例如SI单位）

生命周期成本（采购、培训、支持）

供应商的生存能力

论文[V]中描述了萨博公司和Skeldar项目的类似标准。IBM/Telelogic Rhapsody被选为Skeldar项目的工具，这一决策部分基于萨博航空系统公司早期一个航空电子项目中使用Rhapsody和UML进行软件设计和文档编制的经验。在Skeldar项目中引入UML/SysML并选择Rhapsody，是基于以下分析：

产品/项目对系统工程支持的需求（例如模块化、变体处理）

先前项目中现有的最佳实践以及与工具供应商的关系

对现有前沿系统工程支持工具和方法的基准测试

在系统的整个生命周期中提供长期的系统工程支持

未来合作伙伴和顾问的策略

工具选择标准不应过于侧重于技术方面（例如导出能力或模型检查），因为这些功能/特性可能在未来的工具版本中添加。更重要的是，工具应具有合理的底层结构和符合标准的开放接口。

6.3.2长期考量

一架战斗机在经过充分升级后，可能会服役30 - 40年，而民用航空项目的规划使用寿命甚至更长。在这样使用寿命较长的产品中，由于工具的支持和额外的集成工作，可能会给系统的整体生命周期成本增加不必要的额外成本。例如，将一个规范工具更新到新版本，可能会生成不同（不完全相同）的模型或报告。如果该工具用于开发安全关键的机载系统，那么工具更新将需要额外的审查、验证，甚至可能需要进行系统测试。在大型系统中，这些活动可能会导致相当高的成本。如果不随着新版本的发布更新工具，从长远来看也会增加成本。例如，当一个操作系统（OS）（或其某个版本）过时需要升级，但某些工具在新的OS版本中无法工作。解决这种不兼容问题的一种方法是在现代OS中模拟（虚拟运行）旧的OS。例如，可以模拟带有VMS操作系统的旧VAX计算机，这在技术上解决了问题，但会为采购、维护以及掌握另一个软件组件的使用增加额外成本。论文[IV]对使用Simulink进行基于模型的软件开发的三种不同方法进行了研究。研究表明，如果在工程环境中随着供应商的每次发布更新工具，那么依赖Simulink模型生成高质量软件的策略在长期内成本较高。因此，依赖工具生成代码的方法容易受到工具变更的影响。

6.4组织架构与职责

作为飞机集成商或原始设备制造商（OEM），如果一级供应商能够在项目所需的恰当时机提供具有足够详细程度的模型，那自然是最为理想的。但如果无法实现，公司内部或第三方建模与仿真团队就必须提供模型样机、环境模型、模拟器以及带有 “内部” 开发模型的测试台。不过，这些模型的开发需要借助供应商提供的规格说明/设计文档，并且最好能与供应商密切合作。

在特定项目中，针对不同工程阶段所采用的形式化方法，需要做出诸多选择，其中包括：

基线与变更控制。

对接口、模型和文档的审查级别。

审查格式，即确定有多少模型信息要导出到文档中。

在仿真模型开发、集成和管理过程中，需要明确指定以下角色和职责，参考图44：

模型规范制定

：该角色依据仿真需求和系统规范，确定仿真模型的需求、接口和行为。

模型实现

：负责将指定的模型在特定的仿真平台上进行实现。

模拟器平台管理

：针对每个模拟器，对其仿真设施与功能、模型配置以及相关文档进行基线设定、验证，并发布以供在开发项目中广泛使用。

模拟器总经理

：负责规划模拟器平台的更新，以及制定验证和发布流程（这属于支持性产品模拟器的系统工程活动）。一种有效的管理方式是，在规划和控制会议上召集其他相关角色共同参与。

对于较小的模型和模拟器，根据实际情况，可将模型规范制定和模型实现这两个角色合并。

这种工作组织方式有助于在不同模拟器平台之间复用模型，并且能够提高模型规范的一致性，保证模型的高质量。只要条件允许，每个仿真模型在开发时都应满足其所要应用的所有模拟器平台的需求。然而，在某些情况下，不同平台的特定需求差异较大，此时就必须对同一系统组件的不同模型进行管理。每个模拟器平台上所有模型的变体和修订版本都需要在产品生命周期管理（PLM）系统中进行管控，将其作为一种支持性产品，与最终产品保持一致。

7. 讨论与结论

在学术界，有大量不同的建模方法及配套工具，人们通常使用相对较小的示例对其进行评估。这些方法和工具通常会应用于实际工程问题，以评估其实际用途，但展示时往往使用相对较小或较为合适的示例（与工业案例相比），且未将其置于多种方法和手段并存的环境中进行考量。在工业领域，如今 “工具集”“工具链” 和 “方法链” 这些术语经常被用于定义一个工程环境，其中包含某种方法、集成工具以及使用说明。本讨论涵盖了部分所研究建模技术的可扩展性，以及在未来十年内，在飞机和航空电子设备开发公司中实施基于模型的系统工程（MBSE）和基于模型的开发（MBD）的合理规划程度。

7.1讨论

对于以基于模型的开发为重点的工业系统工程而言，特定领域的建模技术和方法并非核心，整体工作流程才是关键，正如以下引述所表明的：“通常情况下，没有单一工具能够解决所有这些问题，因此在整个设计过程中会使用一套工具。由于这些工具几乎无法兼容，项目团队之间的信息共享和协调不可避免地会导致大量协作成本，而且容易出错、效率低下且成本高昂。此外，相似的任务可能会被多次执行，甚至同时进行。” 正是基于模型的开发在集成、协作和扩展方面的特性，为飞机和航空电子设备开发项目增添了最大价值，以下将对这些方面展开讨论。

7.1.1重用与库

在产品或团队之间进行重用显然是高效且有价值的，有助于降低不确定性/风险和成本。随着各类开源社区的兴起，软件重用的趋势日益明显，在航空航天和汽车行业，嵌入式功能或代码片段（遗留代码）的重用也备受关注。更为重要的是设计的重用，因为设计能够帮助工程师理解功能，并实现系统的长期维护。这是推动基于模型的设计/开发的强大动力，因为它要求以结构化且易于维护的方式记录设计。为了实现高效重用，相关流程应鼓励将优秀、经过充分验证和文档记录的（可重用）组件存储在一个运行良好、广为人知的存储库中，即设计库。因此，建议将关注点从实现库转移到设计库。重用存在一个缺点，即重用的组件可能并不完全符合特定用途。它通常内置了额外或更多的功能，但在特定实例中这些功能可能并不需要。可以说这增加了 “无效功能”，从而需要进行额外的验证活动。因此，对于重用而言，通常需要在重用带来的节省与验证成本之间进行权衡。

7.1.2基于模型的系统工程中的硬件与软件

如论文[II]所示，托管仿真技术经过评估，总体上是一种非常有前景的方法。对于指定包含硬件 - 传感器 - 软件 - 执行器回路的普通飞机子系统模型而言，SysML是一种合适的语言。然而，经验表明，它在物理流方面的支持不足。在许多情况下，在SysML图中无法直观判断一个流是实际的物理流（例如燃油流）还是系统中关于该流的信息。区分物理流和信息流的连接器，如在Modelica或基于Simscape的图中所示（见图45），是未来SysML扩展的期望功能之一。有一种将SysML与基于Modelica的仿真建模相结合的提议，包括方程和仿真图，称为ModelicaML，相关内容在[Akhvlediani 2006]中有报道。从工业大规模基于模型的开发角度来看，这种集成视图的价值很有吸引力。在实践中，这可能会催生同时支持SysML和Modelica的工具，这固然不错，但可能难以扩展，因为它无法支持通过分层方法和构建块结构实现的关注点分离。如图46所示，仅使用一个能够处理需求、用例、系统结构以及方程、变量和仿真设置的模型，这种想法很诱人。该图展示了SysML中的需求以及定义仿真组件的两个块。从软件开发中吸取的经验教训表明，当系统规模和复杂性增加时，分离策略更为可取。从长远来看，将需求存储在适合需求和行为模型的模型/工具中，而将执行/仿真相关内容存储在面向执行/仿真的工具中，更有利于支持产品系列生命周期的各个阶段。模型对象与需求之间的可追溯性也需要工具支持，以及实现可追溯性链接的方法，例如，将唯一的需求标识符存储在相关模型组件的跟踪/引用（或者注释或批注）属性中。在早期概念评估阶段，集成方法可能会有一定的价值，因为在这个阶段应尽量减少使用高级工具，它可以作为当前常用的 “电子表格技术” 的补充。

7.1.3长期影响

先进的工程环境面临着工具（或供应商）锁定的威胁，即工具供应商很少或根本不提供与非供应商提供的工具进行信息交换的方式。例如，尽管模型驱动架构（MDA）旨在实现（技术）平台独立性，但目前MDA供应商并不积极推动其MDA工具集实现互操作性。这种结果可能会使采用MDA方法的用户陷入供应商锁定的困境。同样的情况也适用于其他建模领域，如多物理场建模和仿真，尽管Modelica语言的发展推动了开放性和工具互操作性，但在其细分市场中占据较大市场份额的供应商，如MathWorks公司的Simscape语言，却选择了专有策略，与Modelica不兼容。基于本文所描述的复杂产品开发中的一些权衡问题/关系，可以将 “基于模型的开发的悖论” 定义如下：

为了解决复杂性问题，引入模型以便通过分析模型更好地理解需求、约束和设计效果。

单一模型并不足够，因为需要分析不同的方面。这就需要基于不同建模技术（或元模型）的不同分析方法，并且还需要强大的工具支持。

对于每种类型的工具，都需要相应的方法、支持团队、用户指南和培训（甚至可能需要一个流程）。

引入的这一套方法、工具和所需技能增加了开发工作的复杂性。

这个悖论清楚地表明，（一般来说）基于模型的开发存在一个最佳水平。对于某些建模领域（如计算机辅助设计制造或控制工程），建模范式更为成熟，自然会选择高度依赖模型的方法。然而，锁定效应和复杂的集成仍然是一个长期问题，在每个项目的启动阶段都应仔细考虑。

7.1.4大规模建模与仿真

当扩展一种先进的工作方法，将相关工具和工程系统联系起来时，整个过程很快就会变得复杂，必须对其进行深入分析、理解和沟通。基于模型的方法一直是飞机及其组件开发的重点手段，但在本文以及工业界中，它尚未用于开发工程系统（支持性产品）。然而，对（建模）过程进行建模也具有巨大潜力，这有助于获得通用的术语、明确角色和职责、明晰不同学科之间的交接以及过程中的顺序。建模应关注变化，以便能够分析当前（“现状”）过程并将其改进为未来（“目标”）过程。

图47展示了一个过程模型的小示例。这种建模方式可称为业务流程建模（BPM），它有自己的社区、符号和工具，[Hommes 2004]对此进行了总结。在工程环境中使用SysML进行过程建模，不仅有助于过程分析和深入理解，还能让工程师和管理人员同时熟悉建模概念以及UML/SysML符号。其他需要深入分析且最好使用业务流程模型的方面和新兴技术包括：产品系列方法的模块化（例如综合模块化航空电子系统（IMA）和ARINC - 653标准）和配置；分布式开发，包括将仿真模型和建模指南分发给供应商和合作伙伴；基于软件的模拟器，能够在夜间进行大规模批处理运行，这需要针对大量数据的评估技术和工具；多核技术，用于提高仿真执行性能，最终可能会影响仿真模型的建模活动，以及在计算资源上部署仿真线程/进程的方式。一种尚未在大规模建模和仿真中进行评估的有趣技术是4.2.5节中描述的双向传输线数据交换。这种基于本地求解器的方法，可以同时满足模块化需求以及通过简化多核部署任务来提高性能的要求。

7.1.5人为因素

本文未涉及一些人为或社会因素，但这些因素与工业规模的基于模型的系统工程和基于模型的开发的引入密切相关。它们包括项目的组织方式、公司内的能力结构，以及对组织变革的（内在）抵制。在个人层面，不同的工程师对抽象/具体类型的开发方法有不同的偏好。面向对象的思维方式吸引了一些人，但并非所有人都认同。有些人更喜欢图形化表示，而另一些人则更喜欢文本描述。在大规模环境中，所选择的方法在任何方面都不应过于 “极端”，以便大多数工程师能够理解和接受。问题在于，如何在一个已经因各种支持系统、数据库、操作系统以及登录/访问权限而变得足够复杂的（不断变化的）环境中，让人们接受引入一种不同的工作方式。工程师的负担和压力可能会不必要地增加，但通过合理的抽象水平、成熟的工具以及逐步引入的策略，我坚信基于模型的方法是未来的发展方向。因为通过模型，人们能够获得知识，并感受到对复杂性的掌控。

7.2结论

本文对方法、工具和新兴建模技术进行了综述，并通过附录中的论文介绍了萨博航空系统公司在引入基于模型的系统工程/基于模型的开发以支持系统开发过程中的一些经验。对于未来的复杂产品，如战斗机、民用航空飞机或无人机系统，开发工作的主要部分将集中在系统和软件方面。系统工程变得越来越复杂，需要支持不同的应用领域、市场和工程学科。在航空电子项目中，SysML语言的应用才刚刚起步，目前来看前景良好。但在基于SysML的基于模型的系统工程成为开发复杂系统项目的自然选择之前，在方法和工具支持方面仍有多个领域需要改进，例如语言和工具的复杂性以及配置管理支持等方面。由于工程在很大程度上是在相互冲突的目标之间进行权衡（或做出取舍）的行为，因此设计工程方法/工具链也是一项多维度的权衡行为。单一的核心工具无法满足所有需求，但工具过多又会增加开发的复杂性。权衡结果表明，一个平衡的选择是在每个建模领域仅使用一种方法/工具进行规范制定。对于分析活动，有必要为工程团队提供针对特定目的的强大分析手段，但要避免过于 “僵化” 的过程集成，以防止出现锁定效应。总之，结论如下：

航空电子系统中新兴的模块化标准/技术能够在设计保证级别、开发方法上实现差异化，并提高整体灵活性。

方法/工具和标准存在重叠，这为工程环境的设计提供了自由度。

为避免锁定效应，集成应依赖标准化接口和格式，而非依赖供应商的点对点工具连接。

计算机性能的提升、成熟的元建模和数据库技术，使得对大量数据进行建模、仿真和分析成为可能。

航空电子开发的许多方面都有标准，但在大规模仿真领域仍需改进。其中一个需求是来自软件配置管理（SCM）和产品数据管理（PDM）的配置支持框架。

UML和SysML的语义无法清晰区分物理对象/流和信息对象/流。

在设计方法 - 工具链和组织变革时都必须考虑人为因素。此外，不同的人/工程师对图形化/文本化以及抽象/具体类型的开发方法有不同的偏好。

尽管 “工程系统” 复杂到足以成为基于模型的系统工程的研究对象，但过程建模的受关注程度不如产品建模。

7.3未来工作

在本文涵盖的广泛领域中，有许多问题值得进一步研究。自然的延伸是进一步开发基于建模方法的应用 “集成” 设计的方法（和标准），这里的 “集成” 是指模型既能用于生成大规模仿真目的的模型，又能用于在实际航空电子系统中实现。未来工作的主要重点领域概述如下：

7.3.1标准化

与航空电子设计相关的需求示例包括应用组件的定义和标准化。汽车标准[AUTOSAR]是一个最近开发的包含组件开发定义和模式的框架，其中部分内容也适用于航空电子领域。在标准领域，AUTOSAR提供了不同的应用接口（API）以分离不同的软件层；定义了符合AUTOSAR标准的软件数据类型；识别具有标准化接口的基本软件模块。另一个需要标准化的领域是可模拟传感器组件的故障注入模式（如图33所示），在这方面，航空航天和航空电子领域显然还有进一步的工作要做。SysML、Modelica和Simulink都同样适用于实现故障注入模式。在CRESCENDO研究项目中，计划定义仿真框架的其他部分，包括清晰的定义、使用场景、预定义模式和接口。该项目的目标之一是开发行为数字飞机（BDA）范式的基础。BDA有望成为仿真领域的一个平台，涵盖从概念设计阶段到测试和验证的整个设计生命周期。基于本文的工作，计划在大规模仿真领域继续研究，并有可能在以下方面为BDA做出贡献：[Kuhn 2008]中报道的多层次方法；托管仿真技术的接口和工具支持。

7.3.2配置管理

当前的建模和仿真工具通常提供与标准软件配置管理工具集成的接口。这类工具在版本管理方面具有很强的能力，但缺乏产品数据管理工具中的集成支持，以及实现产品和系统演进与维护所需的标准。需要为产品系列内的大规模仿真设置指定配置管理原则，使其与软件配置管理（SCM）和产品数据管理（PDM）学科的原则和概念保持一致。

7.3.3区分信息流和物理流

经验表明，在同一图表中明确清晰地指定信息流和物理流的支持不足。像Dymola和Simulink/Simscape这样带有功率端口连接器的面向仿真的工具具备这种支持，但在SysML的系统级规范图中，无法直观判断一个流是实际的物理流还是系统中关于该流的信息。在我看来，SysML显然需要补充功率端口的语义和图形功能。

目录

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

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