引

言

本文是美国喷气推进实验室就MBSE技术在火星2020项目的应用阶段总结性论文，论文给出了使用MBSE的最初动因、遇到的问题、实践过程中的经验和目前的困境。该论文可为MBSE在系统工程应用的定位带来一些客观的思考。

本文为知元公司根据原文翻译整理，鉴于专业能力，翻译中难免存在错误或理解歧义，请参考使用。

摘要

喷气推进实验室（JPL）好奇号火星探测任务的成功，促使美国宇航局支持Mars2020火星探测实验室建造第二个火星车（毅力号）。Mars2020选择引入基于模型的系统工程（MBSE）来协助设计飞行系统。本文将介绍在Mars2020项目中引入MBSE的动机，并将解释Mars2020飞行系统模型的当前状态。此外还将讨论MBSE方法的局限性。

1引言

2012年8月6日，喷气推进实验室（JPL）火星探测器科学实验（MSL），的好奇号探测器成功登陆火星表面，开始了它的地质和环境研究，寻找火星上过去存在生命环境的证据，这些环境非常适合支持微生物的生命。飞行器着陆方式设计为自主式，飞行器在火星大气层中自动转向，展开降落伞，并采用了一种空中起重机方式，把直立的火星探测器漫游者用绳子拉下来，让它的轮子在火星上着陆。在不到一年的时间里这次令人惊奇的着陆方式，好奇号已经达到了它的主要科学目标，并继续在火星岩石中钻取样品，通过分析仪器内的车载试验室分析样品的化学成分。

MSL的成功促使美国宇航局向喷气推进实验室提出新的挑战，要求它建造第二个火星车，要求价格仅为原计划的一小部分。这项新任务命名为Mars2020，要求继承MSL的大部分飞行系统（FS）设计，但有新设计的科学仪器用来寻找火星上过去生命的迹象。此外，该探测器将收集和储存一套土壤和岩石样本，这些样本将会返回地球，这次任务还将测试新的土壤和岩石样本有利于未来机器人和人类探索火星的技术。 Mars2020必须最大限度地利用MSL的成果，以满足项目的成本要求，包括早期购买的传统硬件的再次使用，重复使用MSL的软件等。

在Mars2020开发的早期，发现在获取MSL项目已有数据方面存在的问题。MSL项目整个研制过程技术基线是使用“盒子学”管理的，技术都是以幻灯片和视图方式记录、存储，缺乏严谨性或共同的术语，并经常存在多个版本的时效问题。系统工程设计文档，如系统块图表和电气互连清单，最新的配置单等重要资料的获取非常可困难。此外，MSL两年的发射周期存在重大的人为因素和人员不连续性，导致很难把从项目开始到结束所有的数据资料都恢复过来。遇到这些困难后，飞行系统工程（FSSE）团队提出了Mars2020综合技术基线的工作目标，该团队希望提供一个权威的飞行系统信息源，整个项目都可以很容易地访问它，从而消除信息孤岛的危险，提高系统的可用性、技术基线变更的可见性和可追溯性。

    Mars2020 飞行系统工程团队选择利用MBSE的先进技术来更好地解决上述问题。本文将进一步阐述MSL 系统工程方面的经验教训和M2020 飞行系统工程团队的目的，以解释基于飞行系统模型的系统工程（FSMBSE）方法。将MSL信息作为飞行信息并填充飞行系统设计模型（FSDM）的过程，讨论并举例说明项目正在使用的模型生成产品的当前能力。

2从MSL到Mars2020

在MSL工作的Mars2020 飞行系统工程团队成员开始了一个总结经验的过程，最终了列出Mars2020项目希望改进的系统工程挑战：

（1）“盒子”模式的技术基线：技术基线是用无关联的视图创建生成的，技术基线无法用来解释技术之间的内聚；一个演示文稿中的矩形也可以用线条代替表达，没有人能解释两者的区别；各种数据表格使问题更加复杂；缺乏综合术语的技术基线容易理解混淆。各种技术文件/表格的解释权留给使用者导致开发后期发现设计问题的风险增加。

（2）信息孤岛：需要一个庞大的团队来管理航天器的复杂性。团队成员在本地管理信息，然后定期向管理层和其他团队成员。数据存储在个人手里的现状的导致了团队成员之间需要花费较大的代价对信息的可用性进行知识交流。虽然有共享的数据库，但信息的实效性一直是一个问题。因此不得不采用通过电子邮件联系信息所有者以获得最新的数据。共享数据库在描述航天器设计时缺乏一致性，消耗大量的时间和精力来协调信息不一致、团队成员互相向对方解释自己的数据。

（3）人员/工作不连续性：MSL在2008年经历了一次发射失败，因此在项目组工作的部分人员过渡到其他的项目。导致了集体知识的丧失。MSL开始重新安排员工，在理解完成的工作、还有什么工作要做上存在很大的不连续性，技术文档记录的正确性和不连续性导致了项目风险。

（4）并行工程：随着航天器设计的复杂度提高，很多工作很难量化。这一困难部分归因于航天器各个系统设计的成熟度各不相同，很难执行并行协作和并行工程。

（5）产品一致性和相关性：通常情况下，系统工程所关注的工作与需要交付的产品并不一致。管理分歧、审查工作经常导致团队不得不定期停止或减少其工程的研制工作，花很多精力手工创建必要的表格、图表和图表。而在发射前的几个月里，项目的重点又成了测试和发射航天器，而没有人再关注技术状态是否被记录在文件和表格里。

值得注意的是，Mars2020/MSL 系统工程的挑战并非这个项目所独有。系统工程界对当前使用的系统工程流程和方法来管理跨学科、信息和技术高度复杂的项目感到悲观。基于这些经验教训，Mars2020 飞行系统工程团队旨在解决在飞行系统工程技术基线方面减少与此相关的各种障碍。技术基线一个方面要解决的是准确捕捉探测器设计和产品的制造，两者在性能方面都应是一致的信息内容和布局。另一个方面要解决的是改善沟通、理解和可见性，通过提供一个权威的信息来源来改善整个团队都可以访问的信息（从而减少信息孤岛并减少人员不连续性造成的信息缺失），以及通过定义一种通用语言来描述飞行系统。

Mars2020 飞行系统工程团队新的技术基线技术的目标是采用系统建模语言（SysML）来表达FS设计中的信息模型、包括模型创建和维护。最初的重点是对MSL遗留设计变化的支持。Mars2020 FS由巡航级、下降级和巡航级组成，火星车是FS的主要组成部分，它与MSL传统设计不同，原因是要适应新的科学仪器和样品缓存系统，这导致火星车成为MBSE初期工作的主要应用重点。

3 Mars2020 建模框架

MSL的大多数设计工作都是在非集成的表格视图中开展的，因此，对于FSDM的创建来说希望有一个共同的语言来描述系统，更重要的是对设计意图信息的表达理解。Mars2020建模框架定义了模型元素以及它们之间的关联关系表达要素。该框架扩展了一个通用的SysML，并嵌入系统工程4.0以及JPL特定的框架中，术语的规定按照Mars2020经常熟悉和具体的术语为基准。从2020年3月建模框架开始研发，它可以扩展以满足项目生命周期的需求进展。框架的当前内容专注于支持飞行系统工程期间需要交付的产品，随着设计的成熟和产品从权衡研究、基线转换将设计识别转化为分析验证，框架也将发生扩展。

抽象符号是用于描述Mars2020物理飞行系统的主要组件。它允许在设计时定义无需更多信息（例如零件编号或采购规格）的情况下定义一个物理对象。这对模型的创建提供了极大的便利，团队可以用抽象符号来表达各种组件。因此，框架将抽象符号定义为表达模型的主对象。该框架允许抽象符号之间以两种方式相互关联：一是它们在航天器上的物理组成以及它们的电气连接。二是可以通过其各自的质量和MSL传统使用的关系来表征。框架提供了一种模式来对抽象符号表达的规范性进行检查。

该框架还包括一组用于验证模型规范的python脚本。对框架中定义的模型进行验证的好处有两个：确认团队正确地实现了抽象符号，框架可以以可量化的方式询问关于设计模型的完整性和剩余工作的问题。所有这些都允许FSSE团队对技术基线设计管控。例如，编写一个验证规则来检查给定的SysML模型种某类抽象符号的数量，在技术方面这意味着物理组件在物理硬件中的位置是未知的可能会缺少电气连接。FSSE可以运行验证规则，检查验证错误日志，并进行工程评估，以确定错误是否为设计失误或缺陷。

图1 Mars2020框架。黄色区域为Mars2020特有的对象表达模式，白色为继承的其他表达模式。

4基于模型的系统产品表达

飞行系统设计采用SysML模型，FSSE团队可以查看和使用这些信息模型，整个FSSE产品的信息孤岛、不一致的信息和缺乏产品一致性的情况会大大减少。更有意义工作的是从SysML模型提取文档工件方面取得了重大进展，所有技术手段在Mars2020项目中发挥了支撑作用。通过SysML模型视图和python脚本，FSSE团队能够将设计模型“投影”到更广泛的用户所期望和熟悉的各种数据表格视图，每次执行信息数据转换时都会验证模型信息，确保所产生的技术文档与Mars2020建模框架一致，是正确和完整的。目前正在基于SysMl模型生成的此类产品技术文档的包括产品组成逻辑图、电气功能列表、以及大量设备清单。用于生成这些列表的相同模型也用来生成技术说明报告，如接口资源度量列表（标识备用和连接的电气接口）以及质量趋势报告（航天器的当前质量，并显示了航天器质量图）等。这些模型生成的文档可以通过web界面访问。web界面提供按需或按计划生成文档、以pdf或html格式查看文档的功能。

图2文档生成：Python脚本可遍历FSDM并将模型转换为表格形式，不同类型的模型元素（工作包、参考指示符）逻辑和它们之间的关系被转换生成到一个数据表中，其中每一行标识一个引用指示符及其与其他模型元素的关系。从而为更广泛的项目成员提供由模型生成的详细描述文档。

 

飞行系统工程团队已经做了大量的工作来解决如何利用SysML建立的模型派生各种视图。当前的MBSE实践大多把精力放在如何用SysML创建各种模型，如内部框图、用例图、活动图。但这些模型图并不能被所有的团队人员能够使用，必须按不同的视角来产生数据表、描述文档等辅助文件，问题在于这些辅助文件是根据SysML模型来手工维护的。随着SysML模型的复杂度提高，辅助文件的生产会非常缓慢，并且更新图表的过程非常耗时。目前没有什么手段能保证SysML模型与辅助文件之间的一致性和完整性。FSSE团队对当前MBSE实践发现的另一个问题是SysML图不能有效地将设计意图传达给更广泛的受众。大多数项目成员在查看电气连接视图时不希望看到SysML模型的端口信息，虽然端口在语义上是正确的，并且有利于对电气功能进行建模，但是它们在项目成员的视角中存在没有必要，团队成员不得不使用非语义驱动的工具（例如，PowerPoint）来对SysML模型的细节进行简化、删除、添加要素等图片化处理。

FSSE团队已经开始使用商用图形建模软件来实现图表的自动生成和布局。通过使用这个工具，团队能够执行元素表示规则（例如，所有1553个数据连接应表示为蓝色虚线）如下所示以及元件的布局（例如，所有探测器航空电子设备箱应位于探测器结构内部）。额外的好处这些关系图可以静态地作为文档包含的图片使用，也可以动态地作为基于web的交互式应用程序交互使用。Mars2020 MBSE工具箱中定制模型生成的图表的功能插件，该功能插件减少了飞行系统工程团队在保障能够提供了更广泛的成员不同视图文件的前提下，维护系统的典型“powerpoint”视图的时间，这些事SysML或MBSE商业公司无法做到的。

图3基于规则的模型视图实例：规则生产的视图能允许轻松看懂模型，辨识技术类别和更新状态

 

而在更新设计后，在新的设计模型中只需按下一个按钮，模型生成的辅助文档就可以与新的设计模型保持一致的信息内容，并提供时间戳来通知更团队成员关于设计信息的变更，允许他们查看并依据他们的工程判断继续提供不要的工程信息。

5 MBSE的采用和改进

FSDM已经开始使用建模框架来表达新的飞行系统硬件设计，即科学仪器和样品缓存系统，并已扩展到考虑电气符合等具有概念性的功能，同时还能够在为更广泛的团队成员提供生成产品技术文档。事实上，我们的努力已经变成了设计表达、接口和质量的标准，允许FSSE团队把大部分时间花在设计新元素上。此外，设计团队开始将FSDM扩展到他们特定的主题领域。目前有一个端到端的信息系统（EEIS）原型工作正在进行中，希望连接FSDM的数据接口，将其进一步扩展以连接到地面数据系统（GDS）模型。最终的EEIS模型将用来更加精准的评估MSL和Mars2020运行差异。

当两年前FSDM工作开始时，FSSE团队的很大一部分人不熟悉SysML和与之配套的建模软件。6位MBSE专业人员加入到团队引导设计实践。首先，六名MBSE专业人员的工作人员用MSL的历史数据填充了FSDM的飞行设计信息。在六个月的时间里，整体框架被确定，大量的模型被梳理并创建，并从这些生成初步文件。当时因为MBSE专业人员中的一个成员转移到其他项目，导致剩下的FSSE团队成员维持并为项目付出更大的努力。FSSE团队使用MBSE的一个障碍是，所有人员不能每天都有时间开展MBSE的学习。该小组尝试通过利用公司的MBSE wiki门户，其中包含MBSE相关软件、网站、文档和视频的链接来实现成员的培训，以及发布学习计划、制定个人目标、学习成果分享等。MBSE专业人员中另一位培训师将注意力集中在如何使用模型生成扩展报告上面。此外，MBSE培训师也要负责模型设计的具体工作。MBSE的实践是一个真正的双向工作，MBSE培训师们也要学习Mars2020产品的其他专业知识。

在系统工程师的日常工作流程中引入MBSE还有很多工作要做。而模型作为设计的权威来源，FSSE团队成员仍在探索其他辅助工具来提高他们的工作效率。基于模型的协作性是人们希望多人使用模型的动机之一。在当前工具集中，一个团队成员可以锁定限制其他人对模型进行编辑。模型信息的静态报告文档生成是另一个动机，团队目前正在评估与在线模型编辑工具集成的潜在解决方案。

MBSE方法能够让团队更加关注其工作的困难和复杂的工程方面，并让团队更确信他们所使用的信息是完整的和最新的。Mars2020框架促进了MSL遗留的数据作为飞行工程产品被协调成一个有凝聚力的飞行系统模型，它的好处是在任务生命周期的早期能够修复设计误解/错误。不一致的地方就会被识别和发现，如果做不到这一点，修复成本或任务风险可能会更大，因为很可能在制造或集成之前不会被发现。

从模型生成文档和可视化的能力也使FSSE团队能够快速的回答、追踪可行性研究管理者的各种询问，而这以往通常需要耗费大量时间。这类问题的一个例子电气功能设计，现在工程师可以将更多精力关注那些没有被归类为规范的电气功能。线束设计者和电路数据表设计者都在使用此电气功能模型告知他们的工作日程。

6总结

Mars2020飞行系统采用MBSE方法，以克服常见的SE挑战，这是一项持续的工作。Mars2020建模框架：提供了一个通用术语，可用于描述飞行整个项目的系统，从而提供精确，明确的设计沟通。框架提供了一种易于扩展和添加飞行系统设计信息的机制和一种从模型提取信息的能力。规则检查与验证提供了一种识别信息不一致或不连续性设计信息的能力。

模型生成系统工程产品：通过模型生成一致的数据表、报告文档。通过web界面访问文档可以减少信息孤岛，通过提供一个公共位置来访问飞行系统设计信息。

基于规则的图表创建：直接从模型转换，可单独处理数据的布局和显示方式，使更广泛的团队成员能够多种视角访问模型，减少信息孤岛。

随着MBSE的发展，Mars2020飞行系统将从长远考虑注入更先进技术以期对飞行系统设计有更深入的了解。

文章来源知元创通