Simulink在ISO 26262功能安全项目中的完整实践指南

真正把Simulink当量产工具用起来和我早年在学校里拿它跑仿真玩完全是两种体验。尤其是这几年做永磁同步电机控制器这类带功能安全目标的项目ISO 26262要求你把每个工程决策都讲清楚需求从哪来、设计怎么落地、验证怎么证明、万一出问题怎么追溯。只靠以前的“画框图手写C代码补文档”打法已经走不通了。这篇文章我想把Simulink在ISO 26262项目里的完整用法捋一遍。我不会给你抄工具手册而是按我做电机控制器项目的实际顺序来从建模规范、需求追溯、测试验证、自动代码生成一直讲到工具资格评估和FMU导出。适合正在做功能安全项目的MBD工程师也适合那些被审核老师追着要证据、天天补文档的模型负责人。哪怕你是刚接触功能安全的新人把这套思路吃透再去碰Simulink也不会一头雾水。1. ISO 26262为什么非得用Simulink这套思路1.1 功能安全对开发流程的核心要求先聊一个最根本的问题ISO 26262到底想要什么很多人一上来就背术语ASIL、安全目标、失效模式听着高大上但落到实处就三件事可追溯、可验证、可控。可追溯是说需求里的每一句话都能找到对应的设计实现再找到对应的测试证据。可验证是说你这个设计不是拍脑袋写出来的得能被测试证明真的满足需求。可控则是说过程中每个环节出了偏差你能发现、能纠正而不是等到装车之后才暴露问题。以前做嵌入式控制器经典套路是写需求文档、画原理图、手写C代码、最后再补测试记录。文档和代码其实是两套东西需求改了代码没改代码改了文档没改审核时全是一笔糊涂账。但如果你把Simulink模型作为核心设计载体情况就完全不一样了。模型本身就是可执行的设计规格需求可以挂到模型上测试可以在模型上跑代码可以从模型自动生成。三个环节全都落到同一个物件上可追溯和可验证一下子就有了抓手。1.2 一套完整的Simulink功能安全工具链在我接触过的ISO 26262项目里MathWorks这套工具链基本可以画成一条流水线需求层用Simulink Requirements做需求导入和追溯关联模型层用Simulink建模用Simulink Check做建模规范检查验证层用Simulink Test搭测试用例用Simulink Coverage统计覆盖率再用Simulink Design Verifier补自动生成测试用例代码层用Embedded Coder做C代码生成用Polyspace做静态代码分析最后还有Tool Qualification Kit应对工具资格评估。听起来工具很多但你要理解每样东西解决什么问题。Simulink和Embedded Coder负责“生产”Simulink Check和Polyspace负责“找毛病”Simulink Test和Coverage负责“证明它没问题”Tool Qualification Kit负责“让审核老师认可这套生产流程”。少哪一环后面审计都容易卡壳。我自己比较反感的一种观念是“有了SimulinkISO 26262就自动合规了”。工具只是帮你把证据做得更省力流程责任还得自己扛。下面我按项目推进顺序把每个环节怎么用、有哪些坑一一说清楚。2. 开工前把地基打牢建模规范、模型组织与工具选型2.1 建模规范不是摆设Simulink Check加MAAB怎么落地ISO 26262-6:2018的Table 1里明明白白列了建模规范的要求。当时我看这条时心里想这有什么好规定的后来被一个混乱模型坑过一次就明白了。一个上千行的Simulink模型如果每个人按自己的习惯画Goto和From满天飞、运算模块里写eval、信号名随便起别说审核自己三个月后回去看都会懵。MAAB风格规范是目前汽车行业比较通用的建模规范参考。你不用把里面上千条规则全背下来关键是把高频高危项通过Simulink Check固化到模型里。我在项目里比较重视这么几条第一禁止不必要的Goto/From标签数据流尽量通过端口传递因为标签跳转会让模型控制流变成一张蜘蛛网。第二禁止在MATLAB Function模块里用eval这类动态执行语句这会绕过静态分析危险极大。第三状态机相关的状态命名、事件命名必须统一避免生成代码后变量名不可读。第四模型里不能有未连接的悬空端口尤其是总线信号很容易在集成时丢信号。落地时也不建议把全部检查项一股脑打开几千条告警刷出来开发人员很快会麻木。我一般做法是分三档强制性项设为error一票否决建议性项设为warning分析后记录原因可选项直接关闭或仅做参考。然后用Simulink Check的Model Advisor建一个公司内部模板跑完自动生成HTML报告集成到每日构建里。这里我要特别提醒一句建模规范是给人定的不是给工具定的。Simulink Check只是把你的规则变成机器检查如果你连规则都不写清楚工具也救不了你。我们项目里一度出现“建规报告全绿、代码评审却重写三遍”的情况就是因为规则定得太宽等于没定。2.2 模型怎么组织才不会乱组件化、模型引用与数据字典很多团队喜欢把整个控制器塞进一张大图里美其名曰“总览清晰”。实际上只要控制逻辑超过两三百个模块这种单层大图就是灾难。我见过一个VCU模型打开后滚动条能拖十屏信号线横跨整个画布审模时没人能完整看完。现在的做法是强推组件化和模型引用。把系统按照功能拆成独立单元扭矩路径计算、电流环、弱磁控制、故障诊断、监控模块、输出驱动每个单元做成独立模型再用Model Reference把这些模型装到顶层。比如我在永磁同步电机控制器项目里顶层架构大概是输入信号预处理、控制算法核心、安全监控、执行器输出四块之间接口通过Bus对象定义。Model Reference和普通Subsystem有个本质区别模型引用是独立编译、独立管理的你可以在不打开整车模型的情况下单独开发和测试某一个子模型。这对于功能安全项目太重要了。ASIL分解的时候你会希望把QM和ASIL D的功能严格隔离模型引用天然支持这种隔离。而且Simulink Test可以针对每个引用模型单独建测试工程不会互相污染。再说数据管理。参数和信号定义全部进数据字典别在模型里硬编码。数组和矩阵运算在Simulink里很常见比如电压外环弱磁控制里的坐标变换矩阵建议用Bus对象和Simulink.Parameter统一管理维度和单位。这样做的好处是后续做代码生成时数据字典里的参数可以直接映射到标定量、NVM存储块或CAN标定通道不用再手动改一遍模型。从热词里看到很多人搜“怎么整理simulink模型”我总结一句话命名有前缀、接口走Bus、组件用Model Reference、数据进字典。做到这四条模型基本乱不到哪去。2.3 目标平台与工具链选型从STM32到dSPACE工具链选型这件事越到项目后期越难改。我见过有人项目做到一半才发现Embedded Coder不支持目标芯片的某个外设最后只能手写代码封装绕过费时费力。我的建议是需求阶段就要定清楚三件事目标MCU是什么、是否使用Embedded Coder直接生成产品级代码、是否需要在快速原型或HIL阶段用dSPACE或其他实时平台。比如用STM32做电机控制Simulink有官方支持包但如果你要用AURIX TC3xx那就要确认Embedded Coder对应的嵌入式目标包和编译器链是否完整支持。如果公司以前用过dSPACE TargetLink那就必须评估迁移到Embedded Coder的代价。TargetLink在安全合规方面积累深建模风格偏严格但它在通用性和生态上不如原生的Simulink加Embedded Coder灵活。我个人的经验是新项目直接走Simulink加Embedded Coder历史项目如果已经跑在TargetLink上不要轻易中途换否则光是模型库迁移就够你喝一壶。另外提醒一下版本对齐。Simulink、Embedded Coder、支持包、编译器、甚至操作系统版本五者之间必须匹配。我有一次升级MATLAB版本后原来生成代码的定时器配置直接变了导致控制器周期抖动超标排查了一周才发现是工具链版本问题。3. 需求追得到模型也追得到测试追溯性和安全机制建模3.1 需求树怎么在Simulink里长出来ISO 26262审核时最常见的一句话是“把这条需求对应的设计给我看一下。”如果你把需求写在Word里设计画在Simulink里测试记录存在Excel里那这场审核基本就是灾难。所以从项目第一天起就要用Simulink Requirements把需求管理工具和模型串起来。具体做法是在Simulink Requirements中建立需求层次把来自DoorS、Jama或Excel的系统需求导入。每个需求分配唯一ID比如REQ_VCU_TQ_001这种格式然后把需求拖拽到模型设计元素上建立关联。这个关联可以是子系统、Stateflow状态也可以是测试用例。我踩过很深的坑是为了图省事把需求挂在信号线上。信号线在模型里是脆弱的元素你一旦调整接口布局关联就可能断掉。后来我统一规定需求只挂子系统、Stateflow状态或Simulink Test测试用例不挂信号线。虽然挂载粒度粗了一些但稳定性高得多追踪矩阵生成时也不会漏。需求追溯还要做到“双向”。从需求往模型看每条需求都有实现从模型往需求看每个设计元素至少对应一条需求。Simulink Requirements的追踪矩阵功能可以直接输出双向追溯表但关键不是工具能输出而是你要在每个设计审查节点主动跑一遍发现问题当场解决而不是等到审核前夜猛补。3.2 安全机制在Simulink里的搭法功能安全项目的核心是在模型里把安全机制实现出来而不是只在文档里写“我们有看门狗”。以永磁同步电机控制器为例如果安全目标是“防止车辆非预期加速”那在模型里至少要体现几类安全机制。第一类是冗余监控。主扭矩路径和监控路径用不同算法计算扭矩指令监控路径的结果和主路径做比较超出阈值就报故障。这两条路径在Simulink里必须物理分开各自独立输入、独立计算、独立输出不能用同一个计算模块复制一份就号称冗余那样共因失效根本躲不掉。第二类是信号合理性检查。电流传感器、旋变传感器、母线电压这些关键信号要在模型里做范围检查、变化率检查和交叉比较。比如两路电流传感器在正常情况下数值应接近偏差超过标定阈值就判定传感器漂移进入降级模式。第三类是故障注入端口。为了验证这些安全机制真的有效我会在模型的关键信号路径上预留故障注入接口。用Simulink的Fault Injection或者最简单的方式——给信号加一个测试用加法器通过外部输入注入偏移量、断线或超时。有了这些注入点后面做故障注入测试才有的放矢不然你没法证明监控逻辑在真实故障下会动作。这里有一个容易被忽略的原则安全机制在模型里的命名和层级结构要跟安全概念文档里的条目一一对应。我在监控模块的命名上统一加SFE前缀比如SFE_Torque_Monitor、SFE_Sensor_CrossCheck。审核时对方一眼就能看出这对应哪条安全需求而不是在一堆模型里挨个找。4. 验证环节才是重头Simulink Test与覆盖率要求4.1 测试体系单元到集成回归到背靠背很多团队对测试的理解就是“跑几个仿真看曲线对不对”这在功能安全项目里远远不够。功能安全要求的测试必须能证明需求被覆盖并且能发现回归问题。我常用的测试分层是这样的软件单元测试针对最小可独立验证的模型单元比如一个电流环PI控制器集成测试针对多个单元组合后的行为比如电流环加弱磁控制加扭矩限制系统级测试针对整个控制器模型甚至叠加被控对象模型做闭环。每一层测试都在Simulink Test里建立Test CaseTestCase和需求建立关联运行后自动生成测试报告。Simulink Test的Test Manager挺实用的它支持创建测试用例、设置输入、评估仿真结果。我一般用Simulation Data Inspector作为基线数据来源跑通一次后把结果存成基线后续每次改动后跑回归系统自动对比波形差异。这样每次模型修改你能立刻知道哪些功能受影响而不需要人盯着屏幕看波形。更关键的是背靠背测试也叫Back-to-Back Test。同一个测试用例分别在模型仿真、生成代码的SIL仿真、目标硬件的PIL仿真里跑然后对比三者的输出。ISO 26262要求这种对比的容差范围要被定义和评审不能拍脑袋设1%就算过。我通常在模型和SIL之间设很小的容差比如0.1%而在PIL里适当放宽到1%到2%因为定点化、编译器优化和硬件延迟会带来合理偏差。只要容差设置有理有据审核时就能解释得通。4.2 覆盖率MCDC到底怎么算才安全覆盖率这事很多人只关心“跑到了多少”不太关心“为什么是这个数”。ISO 26262对软件验证的覆盖率要求是分级的。简单来说ASIL A基本可以只做语句覆盖ASIL B要求语句加分支覆盖ASIL C和D通常要求MC/DC覆盖。MC/DC的意思是每个条件独立影响判定结果这个要求对组合逻辑很强的模型是个硬骨头。Simulink Coverage可以直接统计模型覆盖率。但这里有个容易犯的错误默认只会统计你实际执行到的部分覆盖率如果只到70%你根本不知道缺失的30%是“需求不需要”还是“测试用例没写好”。我的做法是用Simulink Design Verifier自动生成满足覆盖率目标的测试用例再结合手写测试用例把模型中的关键分支全部拉到。在我做电机控制项目的经验里MC/DC最难满足的往往是那些带长串逻辑“与”或“或”判断的诊断模块。比如一个过流保护逻辑同时判断电流幅值、持续时间、母线电压范围条件一多组合爆炸。后来我把这种复杂判定改写成Stateflow状态机用状态迁移去表达判定条件MC/DC反而更容易满足因为状态迁移的覆盖目标和逻辑表达式不一样测试路径更清晰。覆盖率报告不是生成出来放那儿就完事了。Simulink Coverage可以导出报告但你要在报告里给每条未覆盖项写原因说明是安全冗余故意不触发还是测试场景覆盖不到还是用例缺失。审核老师看的是你的分析过程不是那个百分比。4.3 静态代码检查与MISRA别等到代码生成后才做生成代码之前模型本身要过静态检查这对应的是Simulink Check。生成代码之后C代码也要做静态分析对应的是Polyspace。两件事都要做先后顺序千万别搞反。很多团队把MISRA C检查拖到代码生成之后结果Polyspace报告出来几百条告警有未初始化变量、有指针使用问题还有一堆因为代码生成器风格导致的“疑似违规”。为什么会有这种问题因为Embedded Coder生成的代码虽然不是人写的但它也是C代码功能安全标准里要求对自动生成代码进行验证不能因为是工具生成就豁免。但静态代码检查不等于无脑把告警清零。Polyspace跑MISRA C:2012会有相当一部分告警需要人工确认是误报或“无害但有风险”。我在项目里要求开发人员对每一条告警做分类确认修复、确认误报、偏差申请。偏差申请要有理有据比如“该变量由生成器统一管理不会出现未初始化场景”。审核老师看你的偏差管理表比看你把告警清零更放心。另外一个实用技巧是在模型层就把代码质量隐患提前消化掉。有些代码告警的根源其实是模型里的数据类型设计混乱。比如整型和浮点混用、隐式转换过多。你在模型里把数据类型统一好用Data Type Conversion显式转换生成的代码干净得多Polyspace的告警能少一半。5. 从模型到量产代码Embedded Coder与MCU集成5.1 模型配置、代码生成与NVM读写到了这一步Simulink模型要从“仿真设计”变成“产品代码”。Embedded Coder生成代码的基本流程我不展开重点说几个量产项目中容易出问题的环节。第一个是求解器和采样时间设置。量产的嵌入式软件必然是离散系统模型配置里要用离散求解器采样时间要和你实际的控制周期一致。我见过有人用连续求解器一路仿真到投板生成代码后在真实硬件上震荡得一塌糊涂原因就是模型里用了连续积分代码里却只能按周期步进执行。电机电流环的采样周期可能是一百微秒量级扭矩控制的外环可能是几毫秒模型里无论做仿真还是生成代码都要保持这种多速率配置。第二个是数据与代码的映射。Embedded Coder的Code Mapping功能可以把模型里的信号和参数映射到不同的存储类型。标定参数通常放到可标定的内存段比如EEPROM或专门Flash区诊断事件放到NVM里做掉电保存CAN通信信号用volatile变量。你需要在数据字典里提前把这些存储类型定义好否则生成的代码默认全是RAM变量后续做底层集成时接口根本对不上。我做一个电机控制器时有个需求是“标定参数支持在线修改并掉电保存”也就是热词里的NVM读写。处理思路是在Simulink里把标定参数都定义为Simulink.Parameter存储类型指定为CalPrm再通过代码生成接口和底层NVM驱动对接。底层驱动负责把Flash里的数据加载到RAM模型代码只负责读RAM。这样模型层不感知存储介质底层怎么存Flash、怎么校验CRC都是集成工程师的事。第三个是中断和函数调用。周期任务在模型里可以用函数调用子系统实现比如把电流环中断服务函数对应到一个Trigger子系统把慢速诊断任务对应到另一个周期子系统。代码生成后会得到不同的C函数底层代码在对应中断里调用这些函数。这个架构在项目初期就要定好后期改动的成本极高。5.2 外部模式在线调参与标定做电机控制这类强实时项目光靠离线仿真是不够的。你要在板子上跑起来看实际电流波形在线调PI参数。Simulink的外部模式也就是External Mode基本就是为这种场景准备的。外部模式的工作原理是让Simulink和板子上运行的代码建立通信通道板子实时把信号上传到Simulink的Scope或Dashboard里同时你可以在模型里改参数通过通信通道下发到板子。用支持包自带的示例STM32这类MCU通过串口或以太网就能跑起来。外部模式在开发调试阶段非常好用但我必须泼一盆冷水别把它当量产标定工具用。第一它的实时性和带宽有限上传太多信号会挤占通信资源影响控制周期。第二它和下位机的握手协议一旦在高速控制代码里抢占CPU可能造成调度抖动。我的经验是在调PI参数和验证传感器信号时用外部模式等到需要正式标定时切换到专用的标定协议比如CCP、XCP或者用板卡自带的标定通道。用外部模式时有个小技巧在模型里单独建一个Test Interface子系统专门用于放置需要观测的调试信号和临时可调参数。量产生成代码时把这个子系统排除在外避免调试代码混入产品。不然你可能会把一堆只用于调试的全局变量带进量产代码静态分析又得解释一圈。5.3 SIL、PIL、HIL和台架实测从模型到量产的验证链路我一般这样走模型仿真通过后先做SIL也就是把Embedded Coder生成的C代码编译成主机程序在MATLAB环境里跑同样的测试用例验证代码逻辑和模型逻辑一致。然后做PIL把C代码交叉编译到目标MCU上在真实芯片上跑测试用例验证目标平台上行为正确顺带看运行时间和栈使用。最后做HIL把软件放到实时仿真环境里连接被控对象模型和故障注入设备验证整个控制器的外部接口和故障响应。PIL这一步特别容易被人忽略但它最能暴露问题。比如浮点运算在不同编译器的优化下精度可能不同MCU上的定时器分辨率不足会让采样时间抖动内存对齐问题可能导致数据读取错误。这些在SIL里都发现不了。跑PIL时我会特别关注代码生成的求解器和目标硬件是否匹配必要时把模型里的连续模块全部替换成离散实现。HIL测试在电机控制项目里其实有点尴尬。电机控制很依赖真实功率级的响应HIL柜模拟电流环的动态毕竟有限所以很多团队选择在台架上直接调电流环。我的做法是功率级和故障注入相关的场景必须台架或者实车测逻辑控制和通信诊断类场景用HIL覆盖。安全机制验证比如“旋变断线后控制器进入安全状态”这种场景在HIL里注入故障信号非常合适不需要真的去破坏一台电机台架。6. 往外走FMU导出、联合仿真与生态协同6.1 导出FMU给上下游做功能安全项目的过程中模型不一定只在Simulink环境里使用。你可能需要把电机控制模型交给整车性能团队做系统级仿真或者把电池模型接进来联合仿真这时候FMU就派上用场了。FMU是基于FMI标准的模型封装格式Simulink支持把模型导出成FMU。导出时主要分两种类型Model Exchange和Co-Simulation。Model Exchange是把模型的方程导出去由对方工具的求解器来算Co-Simulation是Simulink自己完成解算在固定步长下和对方交换输入输出。我的选择原则是如果对方工具对Simulink求解器不熟悉或者你希望尽量保证模型内部行为一致用Co-Simulation更稳。如果对方需要在系统级做多模型耦合求解希望能统一控制步长那Model Exchange更合适。但Model Exchange对模型本身约束更多模型里用了大量Simulink专用模块时导出容易出问题。FMU导出还有一个隐形好处IP保护。整包模型给对方对方能看到你所有内部实现FMU封装成一个黑盒只暴露接口和参数目录。在跨公司、跨部门协作时这非常关键。我记得有一次要提供电机控制策略给客户做整车仿真内部实现是核心秘密直接给Simulink模型肯定不行最后导出一个不可展开的FMU双方都满意。导出FMU最要注意的是工具版本和编译器匹配。同一个模型在Windows上导出的FMU换到Linux平台可能跑不起来因为底层编译器不同。另外FMU 2.0和3.0的兼容性差异也要提前确认不然对方环境不支持又得返工。6.2 联合仿真案例CarSim、功率电子和其他方向Simulink生态的优势之一就是能和各种工具联合仿真。热词里常看到CarSim和Simulink联合仿真这在我做整车级功能验证时确实很有用。CarSim提供高精度的整车动力学模型Simulink里跑控制算法两者通过接口模块交换车速、纵向力、横摆角速度等信息。联合仿真最要命的问题是两个工具的采样时间不同步。CarSim可能有自己的通信步长Simulink又是固定步长控制周期接口处容易出现数值不稳。我的经验是在接口信号处增加零阶保持器或速率转换模块把异步信号变成同频采样避免生成代码后出现随机抖动。功率电子方向也很典型。LLC半桥、变频器这类仿真很多人喜欢在Simulink里直接搭功率管和电感电容模型但这是纯电路仿真思路和功能安全控制开发关系不大。我的建议是功率硬件细节尽量用专用工具或者简化模型替代把控制算法模型作为核心功率电子响应作为被控对象给一个简化模型。否则仿真步长被电路动态拖到纳秒级控制算法模型根本没法做嵌入式代码生成。还有一类常见场景比如四旋翼滑模控制、旋转倒立摆这些控制算法研究很多学生和工程师也在用Simulink。这些场景可能不涉及ISO 26262但建模习惯依然值得借鉴参数用数据字典管理控制器和被控对象分开建模仿真结果用回原测试保存。这些习惯养成了以后切到功能安全项目会顺畅很多。7. 工具资质与证据闭环审核前的最后一步7.1 Tool Impact、置信等级和资格评估ISO 26262第8部分第11章专门讲工具资质评估。很多人第一次听到Tool Qualification以为要买一堆昂贵工具证书其实核心问题是你用的工具到底能不能影响安全目标的实现能不能通过其他手段发现它引入的错误这里有个TCL概念工具置信等级。简单说TCL1是工具几乎不可能引入错误或者即使引入了其他措施也能轻易发现TCL2是有一层预防机制但还不够完全可靠TCL3是工具可能引入错误并且没有足够措施去发现这时候就需要做工具资格认证。Simulink本身作为建模环境通常评估为TCL1到TCL2因为模型本身还要经过评审和测试很多建模层面的错误能被人工发现。但Embedded Coder这类自动代码生成工具它会直接生成产品代码如果工具本身有bug且没有任何干预机制就可能被归到TCL3需要提供资格证据。MathWorks提供的Tool Qualification Kit本身不是一个“证书”而是一套支持你做工具资格的自检包。你按照它提供的手册把工具版本、使用环境、验证结果记录成文档审核老师看了才会认可。注意一点工具版本升级后资格证据很可能失效必须重新评估。所以量产项目做到后期我通常会把工具链版本锁死不随便升级MATLAB等一个完整项目节点再统一评估升级。7.2 证据流水线让报告自动生成并受控最后聊一个非常现实的问题审核前夜你手头有没有完整的证据链如果每一步都是人工操作打印报告、手动填表那一定会有遗漏。我的经验是从项目一开始就搭一套半自动的证据流水线。比如用MATLAB脚本批量调用Simulink Test跑测试用例跑完自动汇总结果到Excel用slreq.export把需求追溯矩阵导出来用Simulink Coverage生成覆盖率报告再用Polyspace的批处理接口跑静态分析。把这些命令做成一个模板脚本每次模型提交到代码库后自动执行一轮回归产物归档到受控目录。审计时你只需要展示这套流水线比临时补报告有说服力得多。版本管理也要纳入“证据”范畴。Simulink模型本身是二进制文件虽然能放到Git里但合并冲突很难处理。我用的是每轮修改导出一份受控mdl或slx版本配合数据字典、测试结果和生成代码一起归档。配合Simulink的Project功能把整个工程作为一个单元管理这样能保证你得到的报告对应的就是当时那版模型不会出现“报告和模型对不上”的尴尬。这里说一句我自己的体会。做ISO 26262项目Simulink这套工具链确实帮我省了很多事但真正让项目过审的从来不是工具本身而是团队有没有把“设计即规格、测试即证据”的习惯贯彻到底。工具能把证据收集成本压得很低但如果流程本身散漫再强大的工具也填不上管理的坑。我见过太多团队在立项时兴致勃勃地导入Simulink又在第一次审核时被问得哑口无言。问题不在Simulink不会用而在他们把工具评估当成了免责声明以为买了工具就等于买了安全。功能安全这条路没有捷径每一步的设计决策、每一次测试结论都得老老实实记录下来。用Simulink能把这件事做得更优雅但你仍然得亲自走完它。