基于模型开发(MBD)在汽车功能安全中的应用

1.基于模型开发(model-based development, MBD)简介

模型是表示另一个事物的某种东西，可以是一个比真实物体小的物理对象，或者是一个可以用于计算的简单描述[30]。

基于模型开发是使用模型描述待开发元素的行为或属性的开发方法（ISO 26262-2018 Part 1）[1]。基于模型开发是一种通过事先对事物、过程或概念进行抽象化、去除非本质细节，突出问题本质的开发方法。它从逻辑角度理解系统，并在不考虑具体实现细节的情况下，利用模型来进行开发，从而有效降低复杂系统的开发难度。建模本身也是一个层次化的过程，在每个抽象层次中，可以采用不同的视角进行建模。这种方法有助于平衡系统各个利益相关方的需求，进而提出合理有效的解决方案。

传统的开发方式是基于自然语言的开发，这种方式在每个阶段（如需求、架构等）的工作成果都是文档形式，并且不同团队和阶段的沟通也是基于文档来进行的。随着时间的推移，系统不断地被修改，文档、设计图表和代码之间的距离就越来越疏远。团队之间使用文档容易引起歧义和误解。

2.基于模型开发与 V 模型

传统的开发模式有瀑布模型、V 模型、大爆炸模型和螺旋模型等。V 模型是一种软件开发和测试方法，有 4 个层次 7 个过程，因其流程呈现出类似字母“V”的形状而得名，如图 1 所示。它遵循结构化和线性的开发路径，强调每个开发阶段与其相应的测试阶段之间的明确对应关系。每个阶段在进入下一个阶段之前完成。V 模型以需求为驱动，注重规划和文档化，确保开发过程具有可验证性、可追溯性和可预测性，经常被应用于安全性要求高的汽车、医疗、航空、轨道交通、核电领域。

图 1 基于文档开发的 V 模型

图 2 基于模型开发的 Y 模型[3]

当基于模型开发时，传统的 V 模型将会变为 Y 模型，如图 2 所示。用户将会更多精力放在需求、架构、测试方面。繁琐、易错的单元设计、实现、测试由 MBD 工具完成。基于模型开发能够降低软件的开发周期、开发成本；提高软件的可靠性与安全性。有数据表明 MBD 可以降低 50%开发成本，节省 50%的开发时间（空客公司）。

基于模型开发为什么能将 V 模型变成 Y 模型：

1）模型语言的语义明确、无歧义。

2）静态模型检查（形式化验证），符合模型规范。

3）生成代码语言是模型语言的子集，保证模型到代码转换的完整性。

4）代码生成器通过安全认证，保证模型生成代码的正确性、一致性、完整性。

注：SCADE ACG 代码生成器通过了安全认证，已应用于大众的 ID3、ID4 车型，斯巴鲁的 XV 车型。

5）模型依赖的软件组件通过了安全认证（ISO 26262、DO-178，IEC 61508、EN 50128）。

6）生成 C 语言代码符合 MISRA C 规范。

7）自动生成测试用例与自动化测试，满足测试覆盖率要求（模型测试、单元测试）。

生成符合安全认证的文档。

3.基于模型开发与敏捷

汽车行业正在迈向软件定义汽车（Software Defined Vehicle），软件开发周期缩短。敏捷开发越来越多地被应用于汽车软件开发。可执行的模型可以作为良好的媒介，促进开发人员与客户之间的协作。敏捷开发与 MBD 目的都是缩小需求分析与实现的差距。敏捷通过快速迭代、客户直接参与来减少差距。MBD 通过自动化开发、半形式化表述来缩小差距。MBD 天然具备一些符合敏捷开发的特性如表 1 所示。

表 1 敏捷开发在 MBD 中的应用[6]

MBD 开发方法可以解决敏捷开发一些固有的缺点，如表 2 所示。

表 2 MBD 解决敏捷开发固有问题[6]

总结，无论使用敏捷还是 V 模型开发方法，都可以与 MBD 相结合。在软件项目初期，可以根据组织架构、人员能力（开发方法的熟练程度）、开发时间约束、开发成本、安全完整性等级等因素选择适合的开发方法，敏捷与 V 模型的差异见表 3。

表 3 敏捷与 V 模型的区别[6]

4.基于模型的开发过程

基于模型开发的过程可以分解为以下 6 个步骤，如图 3 所示：

1）建模：系统建模活动包括创建系统的数学和行为表示。

2）仿真：通过可执行软件实现模型和行为的一种方法。

3）快速原型开发：为控制和信号处理工程师提供了一种快速且经济的方式，用于在早期阶段验证设计并评估设计权衡。

4）嵌入式部署：将控制器模型转换为详细的可执行软件代码的软件过程。

5）闭环测试：通过将目标硬件和生产代码结合到基于模型的测试中，可以使用数据检查器或日志工具，将模型的动态输出与软件在环测试、处理器在环测试中收集的数据或测试实验室中测量的数据进行比较。

6）集成活动：MBD 环境可自动从模型中生成文档。文档以模板形式存在，允许用户指定每个文档部分的内容。MBD 工具一般支持与 Jenkins, Git, GitHub 等其他敏捷开发工具集成。

图 3 MBD 流程[23]

V 模型测试左移，通过原型开发（模型验证），迭代需求、架构。实现了 V 模型右侧验证过程移动到 V 模型左侧。提高了需求、架构的安全性，降低了 V 模型上层变更带来的不确定性风险，减少了多次迭代的工作量。MBD 验证与确认流程如图 4 所示。

图 4 MBD 的验证与确认流程

5.MBD 满足功能安全要求

5.1 ISO 26262-2018 涉及 MBD 的范围

在 ISO 26262-2018 中涉及基于模型开发的内容详见图 5。

图 5 ISO 26262-2018 与 MBD 相关部分[1]

5.2 背靠背测试与非预期功能测试

背靠背测试（也称为比较测试、等效性检查、符合性测试）。背靠背测试的目的是确保测试对象在测试目标方面的行为（功能、接口、准确性）与其模型等效，如图 6 所示。

图 6 背靠背测试示意图[9]

不存在非预期的功能测试，仅背靠背测试可能不足以证明生成的源代码中不存在非预期功能，可以通过以下两种方法保证生成代码不存在非预期功能：

1）比较模型和代码的覆盖率，覆盖率差异分析。

2）可追溯性分析，所有 C 代码都可以追溯到模型。

5.3 建模语言及建模语言规范（Part 6-5）

MBD 工具（例如 Simulink、SCADE）涵盖了软件级别完整生命周期，天然具备软件各阶段产物一致性、信息交换一致性的特点；建模语言多为半形式化语言，其语法完全定义。支持模块化、抽象、封装。

1）建模语言规范

可参考 Advisory Board Control Algorithm Modeling Guidelines，Modeling Guidelines for High-Integrity Systems，Modeling Guidelines for Code Generation.

2）生成代码规范

可参考 MISRA C，software-quality-objectives.

5.4 软件需求阶段（Part 6-6）

MBD 工具可以通过以下方式支持软件需求阶段符合功能安全：

1）Simulink 的 Requirements Toolbox 支持富文本方式创建需求。

2）Simulink 的 Requirements Toolbox 支持从 Word, Excel, DOORS 导入需求。可以在工具链中实现需求、架构、单元实现、单元测试的双向追溯。如图 7 所示。

图 7 Simulink 导入需求设置窗口

需求文档通常是项目的基础，定义了系统的目标、约束和期望功能。需求的高层抽象性和非技术性特征使得它们往往无法直接转化为模型，例如法律、法规、性能、可靠性、鲁棒性等。模型可以补充需求的描述和验证，提高需求的质量，经验表明：程序源代码中所发现的失效将近 50%可以追溯到需求缺陷；编码阶段是需求阶段解决缺陷成本的 20 倍；验证阶段是需求阶段解决缺陷成本的 100 倍[29]。基于模型的半形式化描述便于沟通，减少潜在的不一致和二义；与自然语言规范相比，研发人员更加深入了解真实设计意图的动态表现；基于模型的需求分析，开发过程中可以更早、更多地发现缺陷；基于模型的测试能够保证需求的完整性和正确性。

5.5 软件架构阶段（Part 6-7）

MBD 工具在描述软件架构的动态行为（调度、数据流、状态机）有天然的优势。基于模型语言建模直接可架构设计，模型语言满足功能安全要求的半形式化表示方法。

1）模型语言规范，支持标准中对架构设计可理解性、一致性、简单性、可验证性、模块化、抽象、封装、可维护性的要求。

2）支持架构分层、限制组件大小、限制接口大小、高内聚、低耦合、合适的调度属性、限制中断的要求。空间隔离、共享资源仍需设计者自己决定。

3）架构设计走查、检查同样适用于基于模型的架构设计。

4）MBD 架构设计最佳实践示例如下：

4.1）单元级模型设计使用模型引用

4.2）选择策略将单元按特性分组

4.3）在顶层模型中按照 ASIL 等级和 QM 等级进行拆分

4.4）集成级别不包括具体算法

4.5）使用模型指标监控单元复杂度

4.6）按 ASIL 等级、特性和速率对总线信号进行分组

4.7）仅向单元传递需要的信号

4.8）优化信号和参数对象的布局

4.9）对不同 ASIL 等级模块之间交换的数据进行保护

MBD 工具对于架构设计的验证也具备天然的优势。架构设计基于模型设计，具有清晰、可理解、无歧义的，可动态运行展示态设计，方便验证人员走查；MBD 工具一般都能适配硬件，降低架构适配目标环境的工作量；内置设计规则可勾选，可以自动化实现架构设计规则检查。

5.6 软件单元设计与实现阶段（Part 6-8）

1）单元设计与实现均由 MBD 工具链根据架构设计自动实现。开发的自动化程度高，降低人为引起的缺陷和错误。

2）MBD 工具链的追溯和模型验证可以支持软件单元与软件架构设计 ASIL 的一致性、软件单元与架构设计的一致性、软件单元与 HSI 的一致性。

3）单元设计可以以模型形式表示。

4）模型形式无法表示的单元设计应使用其他形式记录。

5.7 软件单元验证（Part 6-9）

基于模型自动化测试用例提高了代码的验证效率。

1）生成代码应满足语句覆盖、分支覆盖、MC/DC 覆盖率要求。Simulink 支持自动化测试，给出覆盖率，对于不符合项，需要进一步修改并进行测试。

注：SCADE 进行模型层级的覆盖分析，并确保生成代码符合覆盖率要求。

2）单元验证方法最佳实践可参考 Software Quality Objectives 文档中 Table7。

表 4 软件单元验证方法实践[14]

3）在模型级别进行验证可以替代源代码级别的验证，前提是代码生成保持了这些特性。

4）生成代码应符合代码规范；Simulink 可以根据设置规则检查生成代码与编码规范的符合性。

5）单元设计与实现的最佳实践可以参考 Software Quality Objectives 文档中 Table6。

注：SCADE 可以生成符合编码规范的代码。

表 5 单元设计及实现原则实践[14]

6）背靠背测试。

7）不存在非预期的功能测试。

5.8 软件集成与测试阶段（Part 6-10）

1）软件集成可以替换为在模型层面的集成，并随后从集成模型自动生成代码，降低了对硬件的依赖。

2）生成代码的软件集成测试应满足函数覆盖、调用覆盖率。

3）模型集成测试可以使用类似函数覆盖率的结构覆盖率代替。

4）软件集成测试可以在模型在环（MIL）、软件在环（SIL）、处理器在环（PIL）、硬件在环（HIL）环境中执行；

5）软件集成测试应进行背靠背测试保证生成代码的功能、时序、时间约束、准确性与模型的一致性。

6）不存在非预期的功能测试。

7）模型生成的用例不应作为验证模型和生成代码的唯一来源。

5.9 安全需求的定义和管理（Part 8-6）

1）基于模型工具链的自动化追溯能够保证开发的一致性。

2）执行模型可用于验证需求。

5.10 验证（Part 8-9）

1）在设计阶段可以通过评审、仿真、分析的方法对模型产物进行验证。需求设计、架构设计、单元设计均可使用基于模型的评审、仿真、分析进行验证。

2）应将验证工作纳入计划、制定规范、执行验证并记录结果。模型规范应进行验证活动。

3）半形式化验证是使用半形式化符号进行验证。半形式化符号即语法完全定义，但语义定义可能不完整。常见的半形式化方法有：

基于 UML，Sysml，Simulink，Stateflow 建模方法；
基于伪代码方法；
基于逻辑/功能框图，数据流图，时间 Petri 网，实体关系图，决策/真值表方法。

图 8 UML 和 Sysml 的区别[8]

MBD 工具支持半形式化验证包括：

MIL\SIL\PIL\HIL 仿真验证需求（安全功能、安全机制、FTTI、鲁棒性等）；
MIL\SIL\PIL\HIL 仿真验证架构（接口、时序、扇出、内聚、功能分配、FFI 等）；
验证 MBD 工程的模型规则符合性；
验证生成代码的 MSIRA C 符合性；
验证生成代码的语句、分支、MC\DC 覆盖率符合性。

5.11 软件工具置信度（Part 8-11）

使用基于模型开发工具时应：

1）评估 TCL 的适用性。

2）确定工具运行环境的适用性。

3）确定工具版本正确性。

4）工具版本兼的容性。

5）确定工具配置的适用性。

6）检查工具上下文无关的假设。

7）工具使用人员的能力。

8）理解工具的安装指导、使用指导、安全机制、安全限制、安全状态、配置限制等。

9）承接工具输出给使用者的风险，确保所有的风险都被降低到可接受的程度。

10）ISO 26262-2018 中无单独章节描述工具的安全手册内容，可以参考 IEC 61508-2010 Part 2 Annex D。

5.12 软件组件鉴定（Part 8-12）

1）软件组件可以是模型，也可以是源代码或预编译的代码或编译和链接的软件。

2）基于模型开发时，应确定模型依赖的代码库是否通过了安全认证。

3）可以将模型生成的代码替换成已认证的库代码。

4）ISO 26262-2018 中无单独章节描述软件组件的安全手册内容，可以参考 IEC 61508-2010 Part 3 Annex D。

5.13 相关失效分析（Part 9-7）

1）分析共因失效时，应考虑基于模型开发工具导致的共因失效。确保风险都降低到了可接受的程度。

2）分析共因失效时，应考虑模型语言导致的共因失效。确保风险都降低到了可接受的程度。

5.14 安全分析（Part 9-8）

基于模型的安全分析（model based safety analysis, MBSA），是一种计算机辅助分析技术，可以将安全分析过程抽象为模型，使用计算机自动化生成危险源与系统风险。有 2 种常见的方式实现基于模型安全分析，分别是失效传播模型与故障注入模型。

失效传播模型，如图 9 所示。是一种将传统失效分析模块化的方法。安全工程师根据个人对系统的理解，使用在组件级别模型搭建系统。模型包含了各组件的失效的模式、传播、融合、屏蔽、一直、消除等信息。通过运行模型，计算出不同失效组合产生的危险事件，推导出危险事件的最小割集。也可以与传统的归纳、演绎分析方法互相验证完整性、正确性。此方法更适合项目初期需求推导验证。

图 9 失效传播模型原理

故障注入模型，如图 10 所示。是在系统建模之初就将功能安全纳入考虑，模型中包含了失效模式。是一种安全分析与系统设计的高度融合。与失效传播模型相比优势在于：

1）无需单独为功能安全简历模型，减少工作强度。

2）保证功能安全与系统设计的一致性、同步性。

此方法更适合系统功能稳定、需求明确的项目或项目后期的验证环节。

图 10 故障模型原理

MBSA 的优点如下：

1）能够降低功能安全人员能力的依赖。

2）能够提高功能安全分析效率降、低劳动强度。

3）能够提高安全分析的质量。

4）具有统一、规范、严谨的系统描述。

5）标准模型库和失效模型库，一旦设计变化可以快速分析。

5.15 MBD 工具厂商支持

Simulink 和 SCADE 等基于模型开发的商业工具，不仅在技术上实现了天然符合功能安全要求。还提供了符合功能安全标准的实践文档。通过学习商业工具的文档能够学习到 MBD 如何满足功能安全，例如下列文档：

1）Simulink 可以参考文档《cn-iso-26262-best-practices-white-paper》、《software-quality-objectives-v4-1》、IEC Certification Kit 工具箱。

2）SCADE 可以参考文档《Efficient Development of Safe Automotive Software with lSO 26262 and ASPICE using SCADE》。

6.总结

无论基于何种开发方法都应满足功能安全标准的原始目标要求。基于模型开发与基于文档开发的主要差异在于：增加了，工具、模型语言带来的风险；减少了，单元设计、单元实现、单元验证的工作量与系统失效风险；改变了，架构设计、安全分析、需求验证、文档追溯的工作方式。MBD 主要存在以下优势：

△ 基于模型的半形式化描述便于沟通，减少潜在的不一致和二义性。

△ 与自然语言规范相比，研发人员更加深入了解真实设计意图的动态表现。

△ 基于模型的需求分析，开发过程中可以更早、更多地发现缺陷。

△ 基于模型的测试能够保证需求的完整性和正确性。

△ 模型规范自动化检查能够提高软件架构的质量。

△ 开发的自动化程度高，降低人为引起的缺陷和错误。

△ 基于模型自动化测试用例提高了代码的验证效率。

△ 基于模型集成，降低了对硬件的依赖。

△ 基于模型的自动化追溯能够保证开发的一致性。

△ 能够减降低功能安全人员能力的依赖。

△ 能够提高功能安全分析效率降、低劳动强度。

△ 能够提高安全分析的质量。

参考文献

END

作者：郭宗方
文章来源：sasetech

推荐阅读

更多物联网安全，PSA 等技术干货请关注平台安全架构(PSA)专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入PSA 技术交流群，请备注研究方向。