规划符合 ISO 26262 的模型架构 及建模模式 李智慧 2015 The MathWorks, Inc. 1
ISO 26262 Road Vehicles - Functional Safety ISO 26262 是道路车辆功能安全标准 特别强调了现代软件工程概念, 比如 : 基于模型的设计 (MBD) 早期验证与确认 自动代码生成 迈斯沃克在符合 ISO 26262 流程方面一直在努力 系统复杂度的逐渐增加 来自于高级驾驶辅助系统 (ADAS) 和自动驾驶 (AD) 方面的需求 2
来自 ISO 26262 的挑战 有一个符合 ISO 26262 的开发流程吗? Simulink 能用于符合 ISO 26262 的产品开发吗? 如何高效地达到单元测试覆盖度要求? 怎样做到模块间的互不干涉? 能做到既符合 AUTOSAR 又满足 ISO 26262 吗? 迈斯沃克通过以下两种方式提供更加广泛的支持 : IEC 认证包和技术咨询服务 3
ISO 26262-6:2018 指出 Simulink 和 Stateflow 适合软件架构设计 产品开发以及代码生成 4
迈斯沃克对 ISO 26262 的支持 IEC 认证包 迈斯沃克工具链与 ISO 26262 要求之间的对应 ISO 26262 要求 迈斯沃克工具链 5
迈斯沃克对 ISO 26262 的支持 IEC 认证包 迈斯沃克工具链与 ISO 26262 要求之间的对应 基于模型设计参考流程 6
迈斯沃克对 ISO 26262 的支持 IEC 认证包 迈斯沃克工具链与 ISO 26262 要求之间的对应 基于模型设计参考流程 工具置信度确认 + 其他认证需要的材料 工具认证包 软件工具评估准则报告 软件工具鉴定报告 ( 模板 ) 参考认证报告 7
迈斯沃克对 ISO 26262 的支持 IEC 认证包 用户案例 迈斯沃克工具链与 ISO 26262 要求之间的对应 基于模型设计参考流程 工具认证包 软件工具评估准则报告 软件工具鉴定报告 ( 模板 ) 参考认证报告 8
迈斯沃克对 ISO 26262 的支持技术咨询服务 可定制的服务 ISO 26262 软件开发流程差距分析 9
迈斯沃克对 ISO 26262 的支持技术咨询服务 可定制的服务 ISO 26262 软件开发流程差距分析 验证与确认 (V&V) 流程建立 针对每一个任务, 都有文档来描述 : 目标 ( 为什么 ) 输入 ( 需求是什么 ) 活动 ( 如何去做 ) 输出 ( 输出是什么 ) 10
迈斯沃克对 ISO 26262 的支持技术咨询服务 工具预认证材料 可定制的服务 ISO 26262 软件开发流程差距分析 验证与确认 (V&V) 流程建立 工具认证支持 创建认证材料 工具需求 用户手册 测试用例 期望结果 追踪矩阵 置信度分类 参考流程 11
迈斯沃克对 ISO 26262 的支持技术咨询服务 可定制的服务 ISO 26262 软件开发流程差距分析 验证与确认 (V&V) 流程建立 工具认证支持 12
最佳实践 Mapping 上层流程 IEC 认证包 关注点在上层流程 由用户来完成具体实现 迈斯沃克咨询服务 关注点在于解决具体实施中遇到的问题 提供实施建议 具体实施问题 迈斯沃克咨询服务 13
最佳实践 通过大量具体项目的实施, 我们归纳出一组适合于早期考虑的模型架构方面的最佳实践 以下所列最佳实践基于自上而下的代码生成方法 所列满足 ISO 26262 的建模模式以外部接口的方 式实现 上层流程 具体的代码层面的实现由底层软件完成 架构相关的最佳实践 具体实施问题 迈斯沃克咨询服务 14
最佳实践 架构 信号传递 数据定义 代码生成 15
在单元级使用模型引用架构 问题 : 算法模块化差, 难以重用 单元测试无法完成 配置管理困难 功能耦合严重 最佳实践 : 单元模型采用模型引用 利用 ( 虚拟 ) 子系统进一步对功能进行分组, 实现系统的层级化 单元模型 功能组 16
在顶层将有 ASIL 要求的和 QM 模块分开架构 问题 : 无法实现功能模块间的互不干涉 最佳实践 : ASIL 功能和 QM 功能放在不同的模型 尽量在上层生成代码从而降低代码集成的复杂性 模型层级 建模模式 顶层 (ASIL / QM) 顶层模型 ( 生成代码 ) 集成子系统 ( 多层 ) 单元 模型应用 17
在模型集成层面不出现基本算法实现架构 问题 : 不管是集成模型还是单元模型的测试都非常复杂 需求 设计 测试之间的双向追踪困难 最佳实践 : 确保集成层面只有虚拟模块 参考 (MAAB/JMAAB): db_0143: Similar block types on the model levels 18
利用模型指标监控单元模型复杂度架构 模型指标显示面板 问题 : 无法有效达到单元测试覆盖度要求 模型验证困难 最佳实践 : 定义复杂度指标并进行必要的审查 I/O 数量 库的重用度 圈复杂度 (<=30)* 基本元素个数 (<500)* 使用持续集成的方法 ( 比如 Jenkins) 监控模型指标 * 参考文章 : Model Quality Objectives 作者 : Renault, Valeo, PSA, Bosch, Delphi, MathWorks 19
只把用到的信号传递给单元模型信号传递 问题 : 成百上千个信号打包成总线导致测试验证难以进行 最佳实践 : 在进入单元之前使用 Bus Selector 将用到的信号抽取出来 必要时可以使用虚拟子系统将总线处理模块封装起来, 使得模型页面清晰 20
总线 (Bus) 设计层次化信号传递 问题 : 多速率总线无法进入模型引用 难以进行数据及信号流分析 由于分类不清晰, 用户可能误将 ASIL 要求低的或者 QM 的信号传递给 ASIL 要求高的模块 最佳实践 : 总线的层次要根据 ASIL 需求以及运行速率来设计 类似于设计自上而下的模型层次结构 21
在模型上构建数据数据定义 用来生成代码的模型 问题 : 由于同一信号既在输出端口上定义又在输入端口定义, 结果导致系统仿真时出现信号冲突 最佳实践 : 让 Simulink 决定内部信号, 只在代码生成的模型接口上定义信号对象 ( 存储类 ) 最大限度降低模型集成出现信号冲突的可能性 但是不一定完全适合于所有情况, 比如为了打断代数环而加入的延迟模块 22
在模型上构建数据 ( 续 ) 数据定义 用来生成代码的模型 除了标定量, 其他的内部信号不定义信号对象 在单元模型最上层的输入输出端口模块上定义数据类型 23
有 ASIL 要求的模块与 QM 模块间的数据保护代码生成配置 问题 : 在 ASIL 功能和 QM 功能之间如何进行信号保护? Best Practice Use Get/Set storage class for signals between ASIL and QM levels 24
有 ASIL 要求的模块与 QM 模块间的数据保护 ( 续 ) 代码生成配置 问题 : 在 ASIL 功能和 QM 功能之间如何进行信号保护? 最佳实践 : 使用 Get/Set 存储类 Get/Set 存储类 25
不同 ASIL 级别以及 QM 之间存储单元分区代码生成配置 问题 : 生成的代码如何实现不同 ASIL 要求以及 QM 要求的代码放到不同的存储区域? 最佳实践 : 配置代码生成的 Memory Section 属性 26
共享代码采用不同的命名标识代码生成配置 问题 : ASIL 和 QM 要求的引用相同的函数 ( 代码共享 ) 时如何避免交叉干扰? 最佳实践 : 配置共享代码标识 Model Configuration/Code Generation/Symbols 27
AUTOSAR 实施 以上最佳实践兼容于 AUTOSAR 许多配置和定制化都可以在 AUTOSAR 架构内实现 AUTOSAR 具体实现需要做一些调整, 比如 : 以上的 Get/Set 就要用 Sender/Receiver 端口代替, 在 RTE 中实现数据保护 IEC 认证包中的参考流程支持 AUTOSAR 架构 Application Layer SWC1 SWC2 SWC Run Time Environment (RTE) Basic Software AUTOSAR 层次化架构 注 : 一篇关于 AUTOSAR 架构满足 ISO 26262 要求的论文正在准备中 28
总结 基于技术咨询的项目实践 ISO 26262 建模最佳实践 在单元级使用模型引用 在顶层将有 ASIL 要求的和 QM 模块分开 在模型集成层面不出现基本算法实现 利用模型指标监控单元模型复杂度 只把用到的信号传递给单元模型 总线 (Bus) 设计层次化 在模型上构建数据 有 ASIL 要求的模块与 QM 模块间的数据保护 不同 ASIL 级别以及 QM 之间存储单元分区 共享代码采用不同的命名标识 AUTOSAR 实施 更多 ISO 26262 建模最佳实践, 请联系我们的技术咨询部门 zli@mathworks.com 29