模型验证流程建立的关键和实践经验 John Lee MathWorks Consulting China MAC, 2014 2014 The MathWorks, Inc. 1
议程 通过一个实例来回答以下问题 为何要建立产品验证流程? 怎样建立产品验证流程? 结果如何? 2
背景 一家美国的汽车零部件供应商 产品 : 稳定控制系统 控制算法采用基于模型设计方法, 应用层代码 100% 自动生成 在原型车上完成算法开发, 软件在正在量产的控制器硬件上运行 上层开发流程 自下而上地开发控制算法 采用仿真验证单元模块的功能 使用快速原型系统进行集成测试 ( 整车测试 ) 3
为什么会担心? 汽车已经在路上跑了 这意味着什么呢? 控制算法在所有工况下都能正常工作吗? 软件里是否有漏洞没被发现呢? 是不是所有的失效条件都被验证过呢? 控制算法是否完全按照需求实现的呢? 4
降低开发成本 each delay in the detection and correction of a design error makes it an order of magnitude more expensive to fix Where Errors Are Introduced... and Detected 错误被引入及发现的地方 Clive Maxfield and Kuhoo Goyal EDA: Where Electronics Begins TechBites Interactive, October 1, 2001 ISBN: 0971406308] 70% 60% 50% 60% 55% 设计缺陷的发现及改正每延迟一个时间点, 修正的成本会上升一个数量级 40% 30% 20% 10% 8% 21% 15% 12% 22% 0% Spec 文档 Design 设计 Implement 实现 7% Test 测试 Detected 发现错误 Introduced 引入错误 5
行业标准 ISO26262 Generic safety standard 通用安全标准 Derivative standards 衍生标准 IEC 61508 1998-2000 EN 5012x 2001 IEC 61511 2003 IEC 61513 IEC 60601 IEC 61508 Ed 2.0 2010 ISO/CD 26262 2008 ISO/DIS 26262 2009 ISO 26262 2011 7
快速原型 ( 非正式 )-- 正式的产品化验证流程 Is this a production level process? 8
原型开发 -- 产品化验证流程 顶层开发流程 自下而上开发算法 采用仿真验证单元模块的功能 存在的问题 缺乏需求 无法确定设计是否完整 难以重用 将快速原型扩展应用到集成测试 ( 实车测试 ) 系统需求 系统集成及调校 系统设计 硬件 / 软件集成 软件设计 软件集成 编程实现 9
原型开发 -- 产品化验证流程 顶层开发流程 存在的问题 自下而上开发算法 验证的基础是设计而不是需求 采用仿真验证单元模块的功能 不能满足 ISO26262-6 的要求 将快速原型扩展应用到集成测试 ( 实车测试 ) 10
原型开发 -- 产品化验证流程 顶层开发流程 自下而上开发算法 采用仿真验证单元模块的功能 存在的问题 需要昂贵的实车测试 在车上无法测到所有可能情况 基于快速原型的验证会产生难以记录的变更 将快速原型扩展应用到集成测试 ( 实车测试 ) 11
议程 通过一个实例来回答以下问题 为什么建立产品验证流程 如何建立产品验证流程? 12
公司在提高产品验证水平过程中经常遇到的共性问题 纵向发展以及工具为导向的方法会浪费精力 流程和工具的选择不考虑上下游工作兼容性 受限于已有的建模及产品代码生产流程 过分依赖硬件在环 (HIL) 和实车测试 哪些设备和方法是必需的, 没有明确定义 团队间的交流合作以及具体分工不明确 点对点的开发流程没能完整定义 13
解决办法是以 职能 为导向 可追溯性 失效模式分析, 故障树分析 (FMEA, FTA) 功能测试 系统工程师 代码测试 安全工程师 稳健性测试覆盖度分析 设计工程师 软件工程师 验证工程师 14
Example: 可追溯性是一个流程不是一项活动 单向还是双向? 追溯深度如何定义? 谁来创建追溯? 如何使用追溯信息? 怎样维护和更新追溯信息? 工具或功能选择 需求管理 模型架构 设计评审流程 需求分解 组织架构 配置管理 需求 实现模型 追踪 15
Verification is a process 验证也是一个流程 16
议程 通过一个实例来回答以下问题 为何要建立产品验证流程? 怎样建立产品验证流程? 结果如何 17
Non- VV (ISO26262-6) Gate review Non- VV (ISO26262-6) Subsystem Requirement VV (ISO26262-6) Optional Add more about high level project planning/tool selection...etc The result is this flow D E E A Create ECU software functional requirement E C Create unit level test cases and safety critical property Unit plan Integration plan Create integration level test cases G H Create system level test cases System plan Developer plan Integration plan Safety / ance requirement breakdown Unit plan System plan Trace unit level test cases and property to requirement Trace integration level test cases to requirement Trace system level test cases to requirement The flowchart shown below should be adjusted by using inputs based on objectives Create project specific modeling guidelines Create Unit Level Requirements Safety Requirement ance Requirement D Create unit level test vectors and property implementation Create integration level test vectors Create plant model F F Create HIL system Create system level test vectors Create architecture model and software build process unit level plan review A,C integration level plan review A,G system level plan review A,H architecture model structural analysis passed Trace architecture model to requirement Unit level models unit level testing architecture model review A unit level coverage analysis Developer plan passed passed Create unit level algorithm unit level back to back (equivalence) test Unit Level Developer Testing Model Structural Test -Model standards -Unreachable coverage objectives -Signal range analysis -Overflow / Divide by zero Model functional test Software build test Software run time error analysis unit level result review A,C passed passed I I Integrate application and basic software Basic software I integration level testing F Integrate unit level model into integration level model integrated build testing Collect code function coverage Integration Level Developer Testing Model Functional test Software integration build test integrated run time error testing integration level back to back (equivalence) test integrated software result review A,C integration level model result review A,G unit level model review A passed passed Trace unit level algorithm to requirement Integrated Software Package passed virtual HIL testing Integrated Software Package ECU build traceability analysis traceability analysis review HIL testing A passed Release review A Create unit level Software Description Document passed final unit level review A Software release Passed Unit level models Starting Point 出发点 动作需求收集和差距分析 输出差距分析报告, 建议的流程以及目标流程 收益得到项目所需的目标清晰可测的需求 单元级软件到需求的跟踪可追溯性分析可追溯性分析评审 符合 ISO26262 的流程 18
Example: 开发功能模块的验证流程 好处 完善的验证流程会迫使工程师开发好的需求文档 提供一个支持持续验证以及自动回归测试的环境 提高产品的整体质量 确定详细流程 开发流程所需的工具 流程及工具培训 工具的部署实施 19
项目成果 顶层开发流程 结果 采用自下而上的方法开发软件 通过逆向工程获得设计需求, 然后为以后的项目开发需求管理策略 采用仿真验证单元模块的功能 将快速原型扩展应用到集成测试 ( 实车测试 ) 开发了一套工具, 使得开发人员利用回归测试框架非常容易的按照 ISO26262 要求测试他们的模型 创建了一个集成仿真平台 20
Summary 总结 这个例子与我们在中国看到的情况非常相似 关键是要认识到原型开发流程与产品开发流程的差异 提高设计信心的方法是建立一套完整的产品开发流程 迈斯沃克有丰富的流程建立和工具开发经验, 为客户提供专业的技术支持及工程服务 21
Thank you! 谢谢! 22