做ISO 26262相关项目的人，最开始接触的往往是A-SPICE流程、功能安全文档、HARA分析这些“流程味”很重的东西。可真正写控制算法、做模型验证的时候，几乎所有团队又默认用Simulink。这两套逻辑碰在一起，很多人第一反应是“模型能跑就行，安全文档后面再补”。但真正干过两个功能安全项目之后你会发现，Simulink在ISO 26262里绝不只是画框图、搭算法的工具，它更像是一条把需求、设计、代码、测试全部串起来的“主线”。
ISO 26262本身并不规定你必须用哪款工具，但它对“在开发流程里引入的工具”提出了非常具体的要求，也就是工具鉴定（Tool Qualification）。我见过一个团队用Simulink开发车身控制器，模型里大量使用Goto/From、用各种土办法传信号，功能是能跑，但后面做工具鉴定和代码审查时，几乎每一关都磕磕绊绊。其实很多问题不是Simulink不好用，而是没有按功能安全的玩法去用。这篇内容我会从工具规划、建模约束、代码生成、测试验证、常见坑几个角度，把我实操中积累的一些经验和教训系统整理一下，给准备在ISO 26262项目里用Simulink的工程师做个参考。
1. 先搞清ISO 26262到底在“卡”什么：Simulink的角色与工具鉴定
1.1 基于模型设计在功能安全中的真实价值
用基于模型设计（MBD）做开发，最大的好处是把需求、算法设计、代码生成全部拉进同一条链路，避免“纸面设计一套、C代码另一套”的偏差。ISO 26262里要求安全需求到技术需求的追溯，在Simulink里可以直接通过需求链接（Requirements Link）把条目关联到模型元素上。实际操作中，这个机制比维护一个Excel矩阵可靠得多。某个需求一变更，你能直接看到哪个子系统、哪个接口受影响，而不是在文档里翻半天。
所以我的理解是，Simulink在功能安全项目中的独特价值就是“单一数据源”。模型既是设计，又是后续仿真的主体，也是代码生成的输入。只要模型管理得足够好，设计实现的一致性基本不会被破坏。反过来，如果只把Simulink当画图工具，画完架构图就丢给C语言团队去手写代码，那ISO 26262要求的“设计与实现一致性”就只能靠大量文档和评审来补救，效率极低，而且很容易漏项。
1.2 工具鉴定没那么玄，但也没那么简单
ISO 26262关于工具的鉴定，很多人一听就头大。其实核心逻辑就一句话：如果你的开发流程用到了某个工具，这个工具的输出会影响安全代码的行为，那你就必须证明“工具引入的错误要么不会发生，要么能被及时发现”。这就是工具置信等级（TCL）的概念。
MathWorks针对Embedded Coder、Simulink Check、Simulink Coverage、Polyspace这些都提供了ISO 26262认证/鉴定文件。但这些文件不是“免死金牌”，它对应的是“工具按推荐工作流和标准配置使用”这个前提。你需要先根据工具在开发里的“干预程度”给它分类：
- T1：工具输出不直接影响安全代码，即使出错也容易被其他环节发现，要求最低。
- T2：工具包含设计或实现部分，出现错误可能不容易检测，需要一定鉴定。
- T3：工具产生错误且不易检测，往往需要最严格的鉴定。
举个例子。自动代码生成工具Embedded Coder，如果它参与了整个控制算法的C代码生成，那它通常是T2甚至T3的候选。虽然MathWorks有官方认证，但你的项目必须按官方推荐的工作流来配置工具，认证才有效。很多实际项目里团队会自定义回调、使用非标准存储类、改掉大量代码生成选项，这样就相当于偏离了“已鉴定配置”，认证报告就不能直接覆盖这些用法。这时候，你要么把自定义部分做额外验证，要么把用法拉回标准路径。
如果一个项目用的是自定义目标系统，比如针对STM32自己做目标支持包，而非使用MathWorks官方的Embedded Coder目标支持包，那就更要注意了。当你脱离MathWorks的官方支持环境时，工具鉴定的证据链会出现缺口。我在类似项目里通常补充的做法是：保留自动生成代码与模型一致性的大量自动对比测试，比如使用Simulink Code Inspector对模型和生成代码做逐模块比对，同时配合覆盖率数据，给审核方提供一个“额外验证”的证据包。
提示：工具鉴定的输出不一定是一堆文档，重点是把“工具配置固定下来，版本记录下来，使用方式形成脚本或说明文档”，证明你整个开发过程都在可控范围内。
2. 建模阶段怎么把安全要求“焊”进模型：规范、引用与配置管理
2.1 建模规范不是形式主义，是帮验证省事
ISO 26262相关项目通常会要求在建模时遵守MAAB（MathWorks Automotive Advisory Board）指南，国内不少团队也会参考JMAAB。很多工程师觉得MAAB规则啰嗦，一开始我也觉得“能跑就行”才是硬道理。但等到做代码生成和SIL测试时才发现，规则里的很多要求其实是在帮后续验证扫清障碍。
最典型的例子是避免使用Goto/From。模型中信号满天飞，用Goto/From确实能让布线看起来“清爽”，但它会绕过子系统边界，全局数据流很难追踪。一旦某个安全需求的信号被Goto拉到远处，后续做需求追溯时根本查不到。而MAAB要求尽量用数据端口传递信号，模型层级结构更清晰，代码生成后变量作用域也更可控。
实际操作上，你可以在Simulink Cache中加载Model Advisor，选上MAAB规则集和Simulink AlertCarding Rules，然后批量扫描整个工程。刚开始跑的时候，上千条警告很正常，不用全消除，但至少要把以下几类清零：
- 包含Goto/From的；
- 存在无符号/有符号类型混用的；
- 涉及未初始化信号的；
- 模型层级超过推荐深度的；
- 使用非虚拟Bus且信号元素未被标记的。
规则检查结果本身就是很好的安全证据，评审时可以导出报告存档。
2.2 模型引用的用法与S-Function的边界
对于大团队、大项目，我强烈建议用模型引用（Model Reference），少用传统库（Library）。库的好处是共享模块，但隐患也在这里：改一个库，所有引用它的模型都会跟着变，变化的影响面很难评估。模型引用则支持版本化、增量编译，每个引用模型可以有自己的配置和版本，集成时接口变化可控。
在实际操作中，用模型引用还能让多个成员并行开发。每个人负责一个子模型，通过接口定义把输入输出定清楚，再用顶层模型统一集成。这对功能安全项目的开发计划、模块评审、版本管理都非常友好。
另一个边界是S-Function自建库。有些团队喜欢把之前手写的C算法用S-Function包起来，方便复用。如果你只是做预研或纯仿真，这没问题。但如果你打算把这个S-Function用于生产代码生成，那就得想清楚几件事：
- S-Function不在Embedded Coder标准支持路径里，代码生成行为比较难精确控制；
- 工具鉴定的覆盖范围很可能不包含这部分；
- 后续如果做MC/DC覆盖率，S-Function内部几乎是盲区。
所以我的建议是：在功能安全量产项目中，中后期一定要把关键算法从S-Function迁移到有明确认证依据的模块，或者用合规的C代码集成方式（如通过External Code接口导入），否则很难向审核方解释“这个自定义模块为什么可信”。
2.3 配置管理：模型也有一套“版本基因”
模型版本管理，很多人以为就是“存个slx文件到Git里”，但Simulink模型的差异比较，比普通文本复杂得多。你不仅要管理模型文件，还要管理配套的MATLAB脚本、数据字典（sldd）、测试用例、仿真场景、生成代码和报告。ISO 26262对配置管理的要求是“可复现”，也就是说，任何一次模型构建，你都要能重现出完全相同的代码和结果。
我自己的做法是：所有模型相关的“不可见配置”都尽量放进数据字典，而不是散落在各模型的基础工作区里。数据字典可以统一管理Simulink.Parameter、Simulink.Signal、枚举类型、存储类，而且能跟着模型一起做版本控制。模型里尽量不要直接引用基础工作区的变量，否则换了电脑，基础工作区一清空，模型看起来还在，实际跑不起来。
另外，配置管理还要覆盖工具链版本。假设某人更新了MATLAB版本，生成的代码格式或注释可能发生微小变化，这会影响评审和鉴定結論。所以在项目里最好固定一个“经过验证的工具链快照”：MATLAB/Simulink版本、Embedded Coder版本、编译器版本、代码生成配置集合，都要有明确的基线。
3. 自动代码生成的关键配置：从C代码到MCU落地
3.1 代码生成前的模型和求解器设置
代码生成不是点一下“Build”就完事。你在Simulink里建模时用的是连续求解器，生成代码就必须用固定步长离散求解器，step-size要和实际运行周期对齐。这是很多刚开始做自动代码生成的人最容易忽略的一点。你在仿真里跑得很好的连续控制系统，一旦换成离散求解器，可能稳定性都变了，更别说代码生成后的实时行为。
具体来说，模型配置里要重点检查这么几项：
- Solver选择discrete，固定步长，步长根据控制周期设置；
- 代数环问题必须解决，代码生成阶段代数环处理起来非常麻烦；
- 信号数据类型要明确，不能依赖Simulink自动推断，尤其不能混用double和single；
- 尽量避免在模型里使用全局变量和持久变量，实在要用，必须通过正式的数据字典接口定义。
代码生成的目标语言编译器（Target Language Compiler）默认生成风格，在ISO 26262项目里通常还需要配置为“符合MISRA C风格”。Embedded Coder提供了MISRA C配置模板，开启后会自动避免递归、动态内存分配、goto等不安全结构。别小看这个步骤，它直接决定了后面做静态代码检查和MISRA结论时的通过率。
3.2 存储类与NVM读写、数组参数的落地
到了MCU开发场景，Simulink模型里一个很常见的需求是：某个标定参数或NVM数据需要在运行时读取和更新。比如你建模时用一个Constant模块给控制器提供标定系数，默认情况下代码生成后这个系数会被写死到代码里。如果它需要放在NVM里，启动时从外部读取，那你就不能直接用普通Constant，而是要把它定义成Simulink.Parameter，并指定自定义存储类，映射到NVM所在的全局变量区域。
实际项目中我会维护一张存储类映射表，把模型里的参数对象映射到ECU的内存段：
- 标定常量：映射到Calibration区域（如CalPAGE）；
- NVM数据：映射到NVM管理接口变量，由底层驱动启动时加载；
- 快速信号：映射到RAM，生成全局变量；
- 只读常量：映射到Flash/ROM常量段。
数组参数在这时候特别容易踩坑。模型里的查找表、标定表都是数组，生成C代码后数组维度和索引顺序必须和底层接口严格对齐。比如二维表的行优先/列优先问题，Simulink里的排列习惯和C语言的内存布局经常不一致。我遇到过项目里用MATLAB Function块写数据索引，仿真时结果都正常，生成C代码后在特定编译器优化下却出现了越界访问。后来排查下来，就是因为数组维度的计算在代码生成时和Simulink环境里不一致。建议是多用Simulink的Selector、Lookup Table这类原生模块，少在MATLAB Function里手工做数组索引，必须手工做时，对数组尺寸和索引边界做显式约束，并配合静态度量。
3.3 导出FMU模型做联合仿真
FMU（Functional Mock-up Unit）在ISO 26262项目里一般用在不同团队或不同工具之间的模型交换。比如OEM和供应商之间不方便共享全部源代码，可以导出FMU给对方做联合仿真。在Simulink中导出FMU，可以使用FMI Kit相关工具或新版MATLAB里的配置界面，重点记住两件事：导出的FMU所依赖的仿真步长和接口信号定义要固定下来，否则对方拿过去仿真结果不一致；另外，FMU通常只用于验证和系统集成，不是量产代码，不能替代最终的Embedded Coder代码生成环节。
我实际用过FMU做CarSim联合仿真的场景。把控制器模型导出成FMU，再导入到CarSim的仿真环境里，验证车辆动力学闭环效果。这样做的好处是CarSim不需要安装完整的Simulink，也不需要暴露控制器内部算法给车辆团队，双方各自版本锁定后，仿真结果可复现。注意，FMU和CarSim的接口版本要提前验证，不同FMI标准版本（如FMI 2.0或3.0）之间兼容性问题不少，建议先导一个小模型试联一遍，再上完整控制器。
3.4 外部模式调试与发布版代码的“隔离”
外部模式（External Mode）是我很推荐在开发早期使用的调试方式。通过串口或以太网，Simulink可以直接连接目标硬件，在线调参、实时观测信号。特别是用STM32自定义目标支持包做嵌入式控制代码生成时，外部模式能省掉很多串口打印的功夫。
但外部模式在ISO 26262项目里是个“双刃剑”。它允许运行时修改模型参数，这在标定现场确实方便，可在交付给产线的发布版代码里，这种“可远程改写内部参数”的后门一旦残留，安全审计肯定是过不去的。所以在实际项目里，我会把模型配置分成两套：
- Debug配置：开启外部模式，方便调试和早期验证；
- Release配置：关闭外部模式，发布代码不包含任何外部调试端口改写能力。
同时，在发布版代码里需要标定功能时，应该走正式的标定协议和XCP等手段，而不是继续留外部模式通路。这个切换要写进脚本，通过同一个配置入口生成两套代码，避免手工误操作。
4. 测试验证链路：SIL/PIL/HIL与联合仿真的配合打法
4.1 用Simulink Test把测试用例变成“证据”
ISO 26262要求有可追溯的测试，Simulink Test（Test Manager）在项目里的价值就是帮你把测试用例跟需求挂起来。实际操作中，我通常这样组织：
- 在Simulink Test里创建测试用例，输入给到模型输入，预期结果要么来自参考模型，要么来自手工计算；
- 测试用例和需求建立追溯关系，用Requirements Toolbox链接需求条目；
- 跑完后自动生成PDF或HTML报告，包含通过/失败结果和覆盖率；
- 报告存档到配置管理工具，作为评审证据。
这里有个经验：测试用例一定要留“可重复性”参数，比如仿真时长、步长、输入信号源版本。项目后期最怕的就是“上次跑过了，但现在复现不了”。把这个写进团队规范，能少很多扯皮。
Simulink Coverage也可以和Simulink Test联动，自动统计模型覆盖率、语句覆盖率和MC/DC覆盖率。MC/DC在功能安全里经常被用于高安全等级（比如ASIL C/D）的逻辑测试，建议在一开始就开启覆盖率分析，不然到最后再补，成本非常高。
4.2 SIL/PIL/HIL的分工：每一步该验什么
现在很多团队都接受“V模型”的说法，但在实操里，SIL、PIL、HIL这三个阶段经常被混淆。我的理解是：
- SIL（软件在环）：把模型生成的C代码编译后，在PC上和Simulink环境一起跑。主要验证“代码是否符合设计”，这时候能发现很多离散化、数据类型、计算误差的问题；
- PIL（处理器在环）：把代码编译到目标MCU或评估板上，通过串口/以太网把MCU和Simulink闭环起来。能验证代码在目标处理器上的行为，包括时间性能、编译优化差异、内存对齐问题；
- HIL（硬件在环）：控制器是完全真实的ECU，被控对象用实时仿真模型代替。验证的是“完整ECU与外部环境的交互”。
我强烈建议不要跳过PIL直接去做HIL。很多编译相关的诡异错误，PIL阶段最容易暴露。比如浮点数行为不一致、结构体对齐变化、数组访问越界在优化等级下的表现，在PIL里能更早定位。特别是在用自定义目标系统做STM32嵌入式控制时，PIL阶段对堆栈和中断的影响，只有实际跑目标硬件才能暴露。
4.3 第三方工具联合仿真：CarSim和其他车辆模型
控制器开发过程中，没有整车就只能靠车辆模型做闭环。CarSim是比较常用的一款车辆动力学仿真工具，它是通过S-Function或FMI集成到Simulink里。跟其他工具联调时，我建议提前确认几件事：
- MATLAB/Simulink版本和CarSim版本的兼容性列表，最好能固定组合；
- 64位/32位编译接口是否一致；
- 联合仿真时步长设置，CarSim侧和Simulink侧要用相同的全局采样步长；
- 是否支持在多核或多进程下并行，优先级如何分配。
在ISO 26262项目里，被控对象模型（比如CarSim）不是安全相关部分，但它作为验证环境必须可靠。审核时老师基本都会问“你的仿真环境模型可信吗”，所以我们至少要保存“仿真环境版本”和“标定过的车辆参数”，最好和台架数据做过对比。没有经过确认的仿真环境，验证结果就没有说服力。
4.4 静态代码检查与MISRA C
自动代码生成之后，静态代码检查建议做两维：一维用Polyspace Bug Finder或类似工具查运行错误、除零、数组越界；另一维用MISRA C规则检查，看代码风格和安全约定。Embedded Coder本身支持生成MISRA C合规的代码，但前提是模型配置里编了一些“建议性”规则，比如不能使用递归、不能用动态内存分配、不能有无符号符号混用等等。
实际项目里，我们通常会看到Polyspace报告里有一大堆告警。不要急着一个个消，先把“高严重度”和“会影响控制逻辑”的过滤出来，映射回模型里的对应模块。比如某些告警源于信号类型不一致，这时候与其在代码级做强制类型转换，不如回到模型里把数据类型统一掉，这样代码重新生成后问题才会真正消失。直接在生成代码上改，下一轮代码生成又被覆盖了，没有任何意义。
5. 常见问题排查：NVM、数组读取和静态检查的实战避坑
5.1 NVM读写不生效，参数总被重置
我见过不少团队在Simulink里已经用Simulink.Parameter定义了NVM参数，也设置了存储类，但代码运行后参数还是被初始化成模型里的默认值。排查下来，最常见原因是存储类的“宏定义/声明”没有正确对应到底层NVM驱动。你可以把生成的代码翻出来看，如果参数变量被声明成const或者放在只读段，那就对了；如果是一个局部变量或者每次初始化的静态变量，那底层的NVM启动加载根本不会接管它。
另一个NVM相关的坑是，Simulink模型里调用外部NVM驱动的方式不统一。有人直接用External Code导入函数，有人写在S-Function里，还有人用C Caller模块。推荐的做法是，把所有底层访问统一封装成一个“硬件抽象接口”，模型里只调用这个接口函数。后续换芯片、换NVM驱动时，只需要改底层实现，模型不用动。
5.2 数组维度、索引顺序在代码生成后变了
数组问题在Simulink模型里不太容易暴露，因为仿真环境里的数组维度和代码生成后的布局可能不同。尤其是MATLAB Function块的逻辑，对索引的处理非常隐晦。我的建议是：
- 尽量使用Model块和原生模块，少用MATLAB Function做数组运算；
- 必须用MATLAB Function时，明确声明输入输出尺寸和数据类型，避免用
coder.extrinsic； - 生成代码后，抽查数组相关的变量定义和循环边界，确认维度和Simulink侧一致；
- 在PIL阶段添加数组边界检查，很多越界只有在目标编译器优化下才会出现。
5.3 外部模式连不上或时好时坏
外部模式连接失败，大部分原因是目标支持包和工具链版本不匹配，或者目标板上的通信中断处理不够健壮。解决思路是先排除法：换串口线、降低波特率、关掉看门狗、检查目标板供电。还有一个很常见的问题是，外部模式代码里如果嵌入了中断服务函数，可能会在通信帧处理时被抢占，导致超时。你可以把通信任务优先级调高，或者先关掉部分中断做测试。
在功能安全项目里，我建议把“外部模式连通性测试”放到每个里程碑的验证清单里，确认开发配置和发布配置没有混淆。一旦发现某个版本生成了带外部模式通路的发布代码，别犹豫，立刻重新生成并做回归验证。
5.4 常见问题速查表
| 现象 | 可能原因 | 检查与解决方案 |
|---|---|---|
| 生成的C代码变量与模型信号对不上 | 存储类或信号命名配置不完整 | 在数据字典里统一命名规则，使用Simulink.Signal明确生成名称 |
| 模型仿真通过，PIL结果不一致 | 浮点精度、优化选项、中断时序问题 | 对比SIL与PIL结果，定位第一个差异点，检查编译器优化等级 |
| 覆盖率始终不达标 | 测试用例覆盖不到某些分支 | 反推未覆盖逻辑，补充边界和异常场景用例 |
| 外部模式频繁掉线 | 中断抢占或通信帧错误 | 提高通信优先级，降低波特率，关闭无关中断 |
| FMU导入第三方工具后结果偏差 | 求解器步长或接口定义不一致 | 导出前固定步长和数据字典，联调前先跑基准用例 |
| 静态检查报警集中在某个模块 | 模型里数据类型混用或隐式转换 | 回到模型统一数据类型，重新生成代码，避免手工改代码 |
最后分享一点个人习惯
做了几年功能安全项目以后，我最深的一个体会是：工具链只是载体，能不能落地关键还是流程和纪律。Simulink再强大，如果团队只是拿它画个架构图、搭个初步算法，后面全部手写代码，那安全论证就非常费劲。反过来，如果你愿意把需求、模型、代码生成、测试用例全部串起来，Simulink其实能成为整个安全案例里最有说服力的一条证据链。
我自己的习惯是把所有工具配置、代码生成脚本、测试集成都代码化、脚本化，而不是靠“某个人记得怎么点”。新同事加入时，跑一遍启动脚本，就能复现整个模型和代码生成环境。项目换人时，交接成本低很多。版本变更时，对比脚本输出和存档结果，很快能发现哪里发生了变化。
最后再补一句：别指望审核方看到模型就相信你，他们更看重的是你能不能稳定地复现同一个结果。这也是为什么我一直强调“固定版本、固定配置、固定流程”。做到了这三条，ISO 26262里的很多工具相关争议都会迎刃而解。
