基于模型的航天嵌入式软件研制应用问题探讨
作者：王政
王政博士，师从何积丰院士/Kim G. Larsen院士，研究方向为实时嵌入式系统形式化建模与验证，博士毕业后加入中国航天。
曾在杨孟飞院士的高可信软件技术研究团队中，承担形式化方法的研究工作。从事航天器软件研制六年，负责研制的多个软件产品已随多颗航天器在轨稳定工作。
现任北京轩宇信息技术有限公司软件工具部副部长，负责“软件研制一体化平台”业务多款工具产品质量及研发效率提升工作，承担航天科技五院MBSE/MBD在控制领域的实施工作。
摘要：
基于模型的设计/开发（Model Based Design/Development，MBD）改变了传统的开发流程，加速了开发进程，使可靠性和安全性得到了有效提升。MBD已经在工业界得到了广泛应用，包括民用航空、汽车电子、轨道交通等领域。业界成熟的MBD语言和工具软件包括SysML/UML、Lustre/SCADE、Simulink、Modelica等。NASA、ESA、波音、洛马等机构或企业也在许多型号项目中应用了MBD技术。因此，目前的问题不是航天嵌入式软件研制要不要应用MBD技术，而是怎样应用、推广MBD技术。本文分析了应用、推广MBD技术可能遇到的挑战和影响，给出了相应的发展策略，讨论了在型号工程实践中需要开展的流程与工具变革。
01概述
所包含的子系统的功能以及各个子系统之间的交互关系势必越来越复杂，从而对系统及其所包含软硬件的要求也是越来越高。能够快速的开发出运行正确、安全可靠以及易于维护的软件是研制单位产品开发成败的关键。传统的基于文档的系统及其软件开发方法面临着许多挑战，诸如需求定义不清晰容易引起二义性、大量手写代码容易引入人为错误、需求设计错误往往在开发完成集成测试时才能发现，这些都会极大的影响产品的质量，提高产品的开发成本，拖延产品交付。
图 1 现有软件研制流程面临的问题
面对上述问题，基于模型的开发（Model Based Development，MBD）应运而生。MBD改变了传统的开发流程，加速了开发进程，使可靠性和安全性得到了有效提升。MBD已经在工业界得到了广泛应用，包括民用航空、汽车电子、轨道交通等领域。
相比于传统的方法，MBD保证了软件需求描述无二义性，在模型级别进行验证，尽早发现问题，自动生成代码，提高开发效率。因此，目前的问题不是航天嵌入式软件研制要不要应用MBD技术，而是怎样应用、推广MBD技术。
本文探讨了如何在航天嵌入式软件研制过程中应用MBD方法的策略，其关键策略在于分阶段开展MBD的应用。本文还讨论了在开展MBD应用过程中可能遇到的问题和挑战及其应对方法。
本文主要分为以下三个部分，一是面临的挑战和影响，二是应当采取的策略，三是流程和工具的变更。
在第一个部分，本文讨论了下列问题：
1)对于组织成员来说，MBD带来了哪些变化？
2)组织成员需要什么样的新技能？
3)是否需要对组织进行重组？
第二个部分主要分析了分阶段应用MBD技术的过程中应当采取的策略，包括：
1)需要解决哪些问题？
2)应当从什么样的型号项目开始进行试点应用？
3)如何证明MBD方法在实际型号中的价值？
4)在应用推广MBD的过程中，如何降低风险？
5)MBD方法如何充分利用几十年来积累的组织资产？
6)完成初始的MBD型号应用之后，该如何继续推进？
本文的最后一个部分按照软件研制的阶段，分别阐述了在应用推广MBD技术的过程中，需要对流程和工具进行哪些变更。
02、面临的挑战和影响
说起MBD技术的应用，人们总是喜欢讨论工具的采购、人员的培训及代码自动生成。然而，在工程实践中充分发挥MBD的优势，更受制于其它因素，主要包括下列三个方面：
1)新的工作
2)需求和设计的加强
3)流程和工具的整合
2.1 新的工作
首先，应用MBD技术往往带来新的工作。使用传统方法时，这些工具一般在实际物理原型上完成。以机电控制软件为例，在应用MBD方法以前，软件完成了单元测试和组装测试之后，就被部署在真实物理环境下，使用真实的电机，进行闭环测试。
应用MBD技术之后，机电工程师就需要使用建模工具开发电机模型，软件工程师首先使用电机模型，在数学仿真环境、半物理仿真环境下进行充分的验证之后，再将软件部署到物理环境下，与真实的电机进行闭环验证。
与传统的CAD/CAE建模不同，我们这里讨论的MBD建模主要关注于与软件相关的部分。被控对象模型的光机电热等多种属性往往被抽象到少数几个输入-输出-状态量。因此，应用MBD方法之后，部门之间的交流沟通更加密切，方案-软件-单机部件之间以模型为表达方法，进行更加紧密的协作。
MBD方法的应用对组织成员的技能有新的要求，组织成员应当理解建模语言及其建模方法，掌握建模工具的使用。
2.1 需求和设计的加强
MBD方法的一大优势在于提前验证，尽早发现问题、解决问题，实现质量重心前移。为了充分发挥这一优势，就需要加强需求和设计环节。传统方法的一个弊端就是需求和设计环节偏弱，实现环节处理了许多应当在设计环节甚至需求环节就应当解决的问题。
MBD方法的另一个优势在于代码自动生成，避免了实现环节由于人员的因素，额外引入问题。因此，在实现阶段或验证阶段发现代码存在BUG，如果BUG属于自动生成的代码，那么应当杜绝直接修改这部分代码，而应当追溯到模型，在模型级别进行BUG修复，进行模型的回归验证。使用新的模型重新生成代码，进行代码的回归验证。
2.3 流程和工具的整合
为了充分发挥MBD方法的作用，应当在组织层面进行流程和工具的整合，配备相应的流程和工具支持团队。该团队的工作主要包括：
1)创建并维护开发人员使用的MBD工具环境；
2)定义并实施流程和工具的变更及整合，主要包括MBD工具与其它工具的接口，涉及配置管理、需求管理、缺陷跟踪及项目管理等方面；
3)定义并实施MBD相关的标准，对于一个组织来说，MBD方法的实施标准是至关重要的。这些标准涉及架构和建模风格、模型审查要求、自动代码要求等诸多方面。
MBD方法并不会取代现有的控制策略设计、软件架构等专业分工，它带来的变化在于各类角色的产品输出形式、关注点发生了变化。得益于基于模型的验证、代码自动生成，控制策略设计人员一般不再需要全程参与整个产品研制周期。软件开发人也可以从繁琐的代码实现中解放出来，将更多的精力投入到架构设计、性能优化等更有价值的工作。
03应用策略
在型号软件研制中应用MBD技术，也伴随着软件研制流程的变化。为了尽量降低风险，应当采用一定的策略，确保MBD技术的顺利应用。
3.1 明确问题
应用MBD技术之前，应当先明确现有传统方法存在的问题和弊端。如果传统方法足以满足型号要求，并无明显问题，那么在实际型号中应用MBD就不那么必要了。例如，某单机产品研制单位，单机软件规模一般不超过5000行，继承性良好，软件缺陷率低于组织要求，那么该组织实施MBD软件研制方法的必要性就不大。
因此，需要明确软件研制方法的度量指标，包括质量评价指标、进度指标、人力资源指标等。通过定量与定性相结合的方法，明确问题，进行分析，得出MBD方法应用的突破点。我们认为，MBD技术的应用，有助于解决下列问题：
1) 需求二义性：建模语言具有明确的语法和语义，可以有效避免自然语言不精确导致的二义性。
2) 需求设计验证不及时不充分：可执行的需求/设计模型实现了“所见即所得”的效果，可以在完成需求/设计之后，立即进行验证。而传统的方法一般需要完成软件代码的修改之后，才能进行验证。
3) 软件编码环节引入BUG：设计模型可以自动生成应用层代码，与系统软件、硬件驱动的接口代码可以根据配置文件自动生成，避免了人工编码引入BUG的问题。
4) 变更成本高：需求的变更可以在需求层面得到充分验证，得益于代码自动生成、测试用例复用、基于模型的测试用例生成等技术，可以更加高效地完成变更。
3.2 选择试点内容
一般来说，面对一种新技术，人们总是喜欢找个简单的对象实施试点。然而，对于MBD技术而言，需要选择一个适当的项目，而非简单的项目。过于简单的项目并不能体现MBD的优势。试点项目应当具有下列特征：
1) 具有一定的代表性：覆盖组织的常规业务，以便评估本组织的业务是否适合MBD技术；
2) 具有一定的复杂程度：建模过程中涉及MBD语言及其支撑工具的主要特征，以便评估该MBD建模语言及其支撑工具是否适用于本组织；
3) 具有可对比性：该项目已有传统方法开发的版本，以便充分说明MBD技术应用的优劣。
关于第三点，还应当注意，如果应用MBD方法的工程师恰好与用传统方法开发该项目的工程师是同一批人，那么完全可能蜕变为使用模型重构这个项目。需求的分析和验证被弱化甚至忽略，直接将C/C++的实现“翻译”为建模实现。
3.3 分阶段应用
为了降低风险，应当分阶段实施MBD技术。每一个阶段都应当清晰地定义阶段目标、评价准则及里程碑。每个阶段的活动既包括MBD本身，也包括相应的流程改进。
MBD相关流程和工具的开发与改进是一个渐进式的过程。在逐步应用MBD技术的过程中，在收获新的成果的同时，也会发现新的问题。一般来说，MBD逐步应用推广的过程，也是软件研制流程逐步规范化、自动化的过程。
首先从规划开始，结合本组织的特点和现阶段亟待解决的问题，制定MBD技术应用实施规划。然后从组件、项目再到组织级，逐步优化和推广。
3.3.1 规划
本阶段的主要目标有二，一是选择适当的MBD工具，二是明确MBD工具如何与现有软件研制工具链整合，三是完成基本的人员技能培训。该阶段的里程碑有二，一是完成某个简单案例的建模、验证、代码生成及部署；二是完成MBD的应用推广规划。
3.3.2 组件级实施
本阶段的目标是选择某个真实型号的某个组件作为MBD技术应用实施的对象，完成建模、验证、代码生成及部署的整个过程。在这一阶段，将自动生成的代码当作手写代码进行验证。通过组件级实施，逐步暴露问题，解决问题。
一年多以前，航天某所利用某退役型号进行了MBD方法的组件级实施。使用MBD方法开发了该型号软件某个模式的控制算法模块，通过补丁的方式，注入到该退役型号。测控数据表明，使用MBD技术开发的组件在轨表现完全符合型号指标要求。
3.3.3 项目级实施
本阶段的目标是使用MBD方法研制某个型号项目的应用层软件。使用MBD工具，对应用层进行完整的建模、验证、代码生成及部署。该阶段的难点在于划分模型-非模型的界限，如何实现自动生成代码与系统软件、硬件驱动软件的集成与部署。
为了控制风险，在本阶段不必追求集成部署的全自动化。本阶段的里程碑不是实现自动生成代码的自动集成与部署，而是识别自动集成与部署所需的接口、协议及工具支撑。具体如何实现，可以到下一个阶段完成。
3.3.4 优化及推广
在单个型号项目中完成MBD技术应用之后，面临的问题就是如何在更多的型号项目中应用MBD技术，如何更加高效地应用MBD。
本阶段的主要目标是总结前期发现的问题，比较试点项目与其它项目的异同，优化MBD流程，改进MBD工具支持。常见的优化包括模型审签、验证自动化、自动代码的自动集成与部署、文档自动生成等。
04流程与工具的变更
MBD方法为嵌入式软件研制提供了丰富的支撑技术和工具，覆盖分析、设计、实现和验证整个研制周期。一个组织需要理清原有方法与MBD方法中的各项活动的差异，对流程和工具进行变更，以便充分发挥MBD方法的优势。图 2给出了嵌入式软件研制的典型流程。
图 2 嵌入式软件研制典型流程
本节按照研究研制流程，讨论应用MBD技术所面临的流程与工具的变更问题。
4.1 需求阶段
需求分析阶段的输出产品是需求规格说明，主要活动是分析并记录软件产品应当满足的需求和约束。使用MBD方法建立可执行的需求规格，通过静态分析和动态仿真的方法进行需求验证，以便高效、及时地验证需求。
实际工程经验表明，需求中的错误是软件BUG最主要的来源，也是软件研制周期拖后的主要原因之一。越早发现需求中的错误，软件产品质量越高。DO-178C推荐使用形式化的需求模型，如果建立形式化模型存在困难，也可以退而求其次，建立可执行的需求模型。
建立可执行的需求模型遇到的一个工程问题就是如何把控模型的粒度。可执行的需求模型并非粒度越细越好，过于细化的需求模型实质上就是在需求分析阶段完成了设计甚至实现的工作，无助于尽早发现需求中的错误。
需求规格说明的主要作用是在软件任务提出方与软件承制方之间建立一致。可执行的需求模型既可以作为需求规格说明文档生成的源头，也可以直接作为需求规格说明，与软件任务提出方进行沟通和确认。
4.2 设计阶段
设计阶段的主要活动是定义软件架构和接口，开发各项软件功能，并确保软件各项功能性质指标满足需求的约束。在MBD方式下，模型取代了设计文档。需求分析阶段输出的可执行的需求模型可以直接作为设计模型的首个版本。相比于传统方法，更有利于保持需求与设计的一致性。设计模型也可以作为设计文档自动生成的源头。在MBD工具链的支撑下，通过桌面仿真和快速原型，可以高效地验证设计是否存在错误。
许多传统方法中的原则，在MBD方法下，仍然应当遵循。例如，尽早选定软件架构，确定软件模块划分。在传统的手工编码的方式下，需要遵循一定的编程规范，在MBD方式下，也需要遵循一定的建模规范，例如，MathWorks公司针对汽车电子行业提出的MAAB规范。航天某所也在去年批准了相关建模规范。
由于现有的MBD技术主要针对嵌入式软件的应用层，因此，有些传统方式的原则，在MBD方式下，变得更加重要。例如，设计分层。许多MBD工具都不提供系统软件、硬件驱动程序的建模机制。以SCADE为例，仅生成应用层代码，由软件开发者自行实现应用层代码与系统软件、硬件驱动程序的接口。Simulink也仅仅针对市面上流行的部分操作系统提供适配功能。
因为这一特点，汽车等民用领域产生了一批诸如Vector、BTC等二次工具链公司。航天嵌入式软件大多使用自研的硬件和操作系统，一般无法直接使用市面上的商业工具，只能进行必要的自主研发。
4.3 实现阶段
实现阶段的主要任务是将设计转换为可以在硬件环境下执行的代码。MBD工具链支持将设计模型转换为可执行的代码。应用MBD技术，应当避免直接修改自动生成的代码。
嵌入式软件的最终部署运行依赖于硬件环境。因此，MBD充分发挥作用依赖于代码自动生成、集成与部署的自动化程度。如4.2节所言，MBD建模的主要对象是应用层软件，航天嵌入式系统又往往使用自研的硬件和操作系统。因此，在型号软件中应用MBD技术，还需要解决代码集成与部署自动化的问题。
4.4 验证阶段
与传统方法相比，MBD的验证活动其实是贯穿整个软件研制周期的活动，见图 3。验证活动的目标是说明设计满足需求，实现也满足需求。MBD方法将这一目标分成若干小目标。在模型级别，进行模型在环的验证。通过之后，生成代码，进行软件在环的验证。通过之后，进行集成与部署，进行硬件在环的验证。
传统方法的验证手段之一是设计评审。MBD方法也强调评审，但是评审的对象不再是文档和代码，而是模型。
4.5 配置管理
传统方法的配置管理对象是文档和代码，MBD方法的配置管理对象包括模型、模型生成的文档和代码，以及为了实现代码集成部署的配置文件。
由于模型是结构化的，MBD的配置管理的粒度可以细化到功能模块级别。配置管理的细化，也为跟踪管理的细化提供了必要条件，最终有助于实现项目管理的精细化。
05小结与展望
航天嵌入式领域应用MBD技术是大势所趋，本文列举了在航天型号软件中应用MBD技术可能面临的挑战和应用，分析了可行的应用策略，预测了流程和工具所需的变更。但是如何全面推广和应用该技术，每一个厂所如何落地实施，还存在许多待解决的问题。轩宇信息作为中国航天下属的全资子公司，愿携手业界同仁，共同推动MBD技术的应用和落地，提升航天软件产品研制的质量和效率！
-End-
