芯片安全手册（Safety Manual）怎么用：别把它当成PDF附件

原文链接：https://mp.weixin.qq.com/s/JxOOsHZh8Pdvdpre3uoNKQ

摘要：芯片安全手册不是产品合格证，而是把芯片使用假设、安全机制、诊断配置、集成限制和验证证据传递给系统项目的工程接口。用不好，安全机制就无法闭环。

图 1　芯片安全手册不是合格证，而是系统集成的安全接口

很多项目第一次接触芯片 Safety Manual 时，容易把它放在两个极端里理解：一种是把它当成供应商给出的“功能安全合格证”，觉得只要芯片宣称支持 ISO 26262、手册里列了 ECC、Lockstep、BIST、Clock Monitor，系统安全就自然有了基础；另一种是把它当成供应商免责文件，里面写了大量假设、限制和注意事项，看完觉得“这都是芯片厂商甩锅”，于是只在资料包里归档，不再进入工程闭环。

这两种理解都不够工程化。Safety Manual 真正的价值，不在于证明某颗芯片“已经安全”，而在于把半导体器件作为一个安全相关元素交付给系统项目时，把供应商已经分析过的失效模式、诊断机制、使用假设、配置要求、验证边界和用户责任说清楚。它不是终点，而是系统项目继续做安全设计、软件配置、硬件集成和安全案例构建的输入。

图 2　Safety Manual怎么用的工程问题

在底盘、制动、转向、域控、底盘融合控制这类项目里，控制器越来越依赖高性能 MCU、SoC、电源管理芯片、通信收发器和外部监控器。芯片能力越强，内部安全机制越多，系统团队越不能只靠“我用了某某安全芯片”来支撑安全论证。因为芯片安全机制只有在正确配置、正确连接、正确监控、正确验证、正确响应的情况下，才会从数据手册里的功能变成项目里的安全证据。

所以这篇文章不从术语堆砌开始，而从项目落地视角谈一个实际问题：拿到芯片 Safety Manual 以后，系统工程师、软件工程师、硬件工程师、功能安全工程师到底该怎么用，怎样避免它变成资料包里的 PDF 附件。

一、Safety Manual不是芯片合格证

图 3　Safety Manual管什么

Safety Manual 经常伴随功能安全芯片、SEooC、安全包或参考设计一起提供。很多项目评审时会问：“这颗芯片有没有 Safety Manual？”这个问题本身没错，但如果下一句变成“有 Safety Manual，所以芯片没问题”，风险就来了。

Safety Manual 通常不等于产品认证证书，也不等于系统安全结论。它更像一个工程接口文档：供应商告诉你，这个器件在怎样的假设下被分析过，内部哪些安全机制可以覆盖哪些失效，哪些机制需要用户启用，哪些诊断结果要由软件读取，哪些故障反应要由系统定义，哪些外部电路或监控条件不能省略，哪些限制超出后原有分析不再成立。

换句话说，Safety Manual 回答的不是“你这个 ECU 是否合格”，而是“如果你想把这个器件放进一个安全相关系统里，需要怎样使用它，才能让芯片层面的安全分析和系统层面的安全论证接得上”。

这种接口属性决定了它不能被简单归档。它里面每一条“assumption of use”，都可能变成系统需求、硬件约束、软件配置、集成测试项或安全案例证据。它里面每一个“recommended safety mechanism”，也不只是一个机制名称，而要进一步明确谁负责启用、如何配置、如何监控、如何注入故障验证，以及失效后系统进入什么状态。

如果项目只是把手册放进配置管理库，却没有把内容分解到需求、架构、代码、测试和安全分析里，评审时最容易出现一个尴尬局面：资料都在，但证据链断了。

二、它到底管什么

Safety Manual 管的东西很多，但可以先压缩成五类：使用假设、安全机制、配置约束、验证建议、证据接口。

第一类是使用假设。比如芯片可能假设外部供电满足某些监控条件，时钟源满足某些稳定性要求，复位链路具备确定行为，软件会在规定阶段执行自检，系统会周期性读取错误状态，通信链路会配置端到端保护，安全机制不会被应用软件随意关闭。这里的关键不是记住条款，而是判断这些假设在自己的项目里是否成立。

第二类是安全机制。常见机制包括存储器 ECC、寄存器保护、CPU 锁步或比较、时钟监控、电压监控、上电自检、周期自检、程序流监控、外设诊断、通信保护、错误聚合模块、故障中断或安全状态输出。手册会说明这些机制面向什么失效，覆盖边界在哪里，是否需要用户配置，诊断结果通过哪个寄存器或接口暴露。

第三类是配置约束。安全机制不是默认存在就算启用。很多机制需要在启动阶段设置寄存器、配置阈值、打开中断、映射故障反应、锁定关键配置、安排周期测试窗口。项目里经常发生的问题是：系统安全分析里写了“由芯片 ECC 诊断存储器随机硬件故障”，但软件初始化没有完整打开 ECC 相关中断，或者错误状态没有进入安全监控任务。这样机制名写得再漂亮，也不能形成闭环。

第四类是验证建议。Safety Manual 往往不会替项目完成最终验证，但会告诉用户需要确认哪些机制可用、哪些故障需要注入、哪些诊断路径需要检查、哪些寄存器状态需要读取、哪些反应时间需要结合系统需求评估。真正有价值的做法，是把这些建议转成集成测试、故障注入测试、启动诊断测试、周期诊断测试和异常处理测试。

第五类是证据接口。芯片供应商可能提供 FMEDA 摘要、安全分析结果、诊断覆盖率假设、安全应用说明、软件安全库说明、驱动配置指南等材料。项目不能把这些材料原封不动贴进安全案例，而要说明它们如何被项目吸收：哪些假设已经确认，哪些机制已经实现，哪些诊断已经验证，哪些残余风险已经纳入系统分析。

三、先给结论：五步用法

图 4　先给结论：五步使用Safety Manual

对项目团队来说，Safety Manual 最实用的用法可以归纳成五步。

第一步，把手册里的使用假设逐条转成项目工程项。不要只读“assumption”，要问它在项目中由谁负责，落在哪个需求里，靠什么设计满足，用什么证据证明。

第二步，把安全机制映射到系统、硬件和软件责任。芯片内部机制只是资源，系统团队要决定哪些机制用于满足哪些安全需求，哪些由启动软件启用，哪些由运行时监控，哪些由外部电路配合。

第三步，把诊断配置变成可验证对象。机制是否启用、故障是否上报、反应是否符合要求，都要有测试策略。不能只在文档里写“使用芯片自诊断”，然后在测试阶段没有任何故障注入和状态读取证据。

第四步，把不成立的假设显式升级为项目风险。如果项目因为成本、架构或平台约束无法满足某条假设，就必须重新分析影响，不能默默忽略。可能的处理包括补充外部诊断、调整安全机制、降低依赖、修改安全需求分配，或者和供应商确认替代用法。

第五步，把 Safety Manual 的结论放进安全案例，而不是停在设计资料。安全案例需要说明为什么这个系统在目标场景下可以接受，而 Safety Manual 只是其中一部分输入。项目最终要证明的是系统级安全需求被满足，不是证明供应商文档存在。

这五步看起来并不复杂，但它改变了一个习惯：从“我读过手册”变成“我把手册变成了工程闭环”。

四、第一步：使用假设要落地

图 5　使用假设要落地

Safety Manual 里最容易被忽略、但最容易引发评审问题的内容，是使用假设。很多手册会用 assumption、requirement、recommendation、user responsibility 等词描述用户必须满足的条件。这些内容如果只停留在 PDF 里，就没有工程意义。

比较好的做法，是建立一张“使用假设落地矩阵”。每条手册假设至少要有六个字段：手册原始条目、项目解释、责任团队、设计实现、验证证据、当前状态。

手册原始条目用于保证追溯，不要只写自己理解后的短句。项目解释用于把芯片语言翻译成系统语言，例如“MCU requires periodic monitoring of clock failure indication”不能只翻译成“需要时钟监控”，而要明确本项目是否使用该时钟域、故障指示由哪个软件模块读取、异常后触发什么降级或安全状态。

责任团队很关键。很多假设跨越硬件、软件、系统和测试。如果没有责任人，最后会变成所有人都知道、没有人关闭。比如外部电源监控可能由硬件设计实现，阈值和复位策略需要系统确认，诊断状态可能由软件读取，故障注入由测试团队执行，安全论证由功能安全团队汇总。

设计实现要写具体，不要写“满足”。如果手册要求关键电源轨被监控，就要说明用哪类监控路径；如果要求启动阶段执行内存测试，就要说明在启动流程的哪个阶段执行、覆盖哪些区域、失败后如何处理；如果要求错误信号连接到外部监控器，就要说明接口、电平、诊断周期和系统反应。

验证证据要能被复查。评审时最怕的不是“有问题”，而是“说不清证据在哪里”。一条假设可以对应原理图审查记录、软件配置审查记录、单元测试、集成测试、故障注入报告、HIL 测试记录或安全分析更新记录。关键是证据与假设之间要能追溯。

当前状态则用于管理闭环。建议使用“已接受、已实现、已验证、需澄清、项目偏离、供应商确认中”等状态，而不是简单的“完成/未完成”。因为使用假设有时不是一次关闭的，它会随芯片版本、手册版本、软件驱动版本、硬件原理图和系统安全需求变化而变化。

五、第二步：安全机制要映射责任

图 6　安全机制怎么映射

芯片 Safety Manual 中列出的安全机制，通常是项目最容易“看起来很安全”的部分。ECC、Clock Monitor、Voltage Monitor、Self-test、Communication Check 这些词一出现，文档就显得专业。但功能安全评审不会只看机制名字，而会追问机制怎样进入系统架构。

一个机制至少要回答四个问题：它覆盖什么失效，它依赖什么配置，它的诊断结果去哪里，它触发什么系统反应。

以存储器 ECC 为例。它可能覆盖某些存储阵列中的随机位翻转，但不同存储区、不同访问路径、不同错误类型的处理方式可能不同。单比特错误可能被纠正并记录，多比特错误可能触发异常或中断。项目需要确认使用的存储区域是否在覆盖范围内，启动配置是否打开，错误中断是否映射，错误计数是否监控，达到阈值后是否进入降级或安全状态。

以时钟监控为例。芯片内部可能有时钟失效检测、频率偏差检测或时钟源切换机制，但系统安全需求关心的是控制算法是否会在错误时基下输出错误控制量。项目需要把时钟监控和任务调度、控制周期、通信超时、故障响应联系起来。否则芯片检测到了时钟异常，系统却没有及时停止相关输出，安全机制就没有完成最后一段路。

以电压监控为例。芯片可能有内部电压监控，也可能建议外部供电监控。系统团队要判断被监控的是哪条电源轨，阈值与器件工作范围和系统安全需求是否匹配，异常时是复位、关断输出、保持状态，还是进入受控降级。这里很容易出现一个误区：芯片内部有电压监控，就默认系统供电安全已经覆盖。实际项目中，外部供电拓扑、传感器供电、执行器驱动供电和 MCU 内核供电可能承担不同安全责任，不能混为一谈。

以自检机制为例。上电自检和周期自检的价值不一样。上电自检可以在系统进入运行前发现潜在故障，但无法覆盖运行过程中产生的全部随机故障；周期自检可以提高运行期诊断能力，但会带来时间窗口、资源占用和安全反应设计问题。项目要结合故障容忍时间间隔、启动时间、控制任务负载和安全目标来安排，而不是简单地把所有测试都打开。

所以，安全机制映射表应该包含机制名称、手册章节、目标失效、项目安全需求、硬件依赖、软件配置、诊断读取路径、故障反应、验证方法、证据编号。做到这一步，芯片安全机制才从供应商语言转成项目语言。

六、第三步：诊断不是写名字

图 7　诊断不是写名字

在很多安全分析文档里，诊断措施一栏经常写得很轻：ECC、CRC、Clock Monitor、ADC plausibility、Communication timeout。问题是，诊断措施写进表格并不代表它在系统里真实有效。

诊断的有效性至少要经历四个层次。第一层是机制存在，芯片或软件库具备相关能力。第二层是机制启用，项目配置确实打开了它。第三层是故障可观测，诊断结果能被安全相关软件、监控任务或外部监控链路读取。第四层是反应有效，系统在规定时间内进入预期状态，并且这个状态与安全目标一致。

Safety Manual 的价值之一，是帮助项目识别这些层次之间的断点。比如手册说明某个错误状态需要用户定期轮询，项目却只在初始化时读取一次；手册说明某个安全机制需要锁定配置寄存器，项目却允许运行时重新配置；手册建议对错误处理路径进行故障注入，项目测试却只做了正常启动；手册把某个诊断覆盖率建立在特定配置上，项目却修改了相关外设模式。

因此，验证 Safety Manual 不是验证 PDF 是否齐全，而是验证项目是否真的按它使用了器件。比较可靠的验证路径包括：需求审查确认每条用户责任被分解，配置审查确认寄存器和驱动参数符合手册，静态检查确认安全机制不会被非安全软件关闭，故障注入确认诊断链路可触发，HIL 或台架测试确认系统反应满足时间和状态要求，安全案例确认相关证据被引用。

这里要特别警惕“机制覆盖率”和“系统诊断覆盖”的混用。供应商可能在芯片 FMEDA 或安全分析中给出某些诊断覆盖假设，但这些假设往往依赖使用条件。系统项目如果没有满足使用条件，就不能直接把供应商的覆盖结论搬过来。反过来，即使芯片诊断机制本身很强，如果系统没有定义正确的失效反应，也不能说明系统风险已经降低到目标水平。

一句话，诊断不是写名字，而是形成可触发、可观测、可响应、可证明的闭环。

七、第四步：假设不成立会怎样

图 8　假设不落地会怎样

Safety Manual 中最有工程价值的地方，往往不是它告诉你“能做什么”，而是它告诉你“在什么条件下才成立”。项目中真正的风险，经常发生在这些条件被默认忽略的时候。

举一个常见场景。系统安全分析中分配给 MCU 的任务，是在检测到关键计算路径异常后停止危险输出。芯片手册建议使用锁步核、程序流监控、错误信号输出和外部监控器组合实现。项目因为成本和平台继承原因，没有使用外部监控器，只保留内部错误处理。文档中如果仍然照搬手册的安全机制组合，就会产生一个隐性问题：供应商分析中假设的外部监控路径不存在，原来的诊断覆盖和故障反应论证不再完整。

再比如，手册要求某些自检在启动阶段运行，并在失败时阻止系统进入正常模式。项目为了缩短启动时间，把部分自检延后到运行阶段，或者只在生产测试中执行。这个调整不是绝对不可以，但必须重新分析：运行前未完成自检的风险是什么，运行阶段执行是否影响控制任务，失败后系统如何处理，安全目标是否仍然可满足。如果只是改了软件流程却没有更新安全分析，证据链就会出现缺口。

还有一种常见情况是芯片版本和手册版本不一致。项目早期选型基于某一版 Safety Manual，量产前芯片修订、驱动版本、安全库版本或 errata 更新，手册中的限制、推荐配置或已知问题发生变化。如果项目没有把 Safety Manual 纳入配置管理和变更影响分析，就可能出现“设计基于旧假设，交付使用新器件”的情况。

处理假设不成立，不能靠一句“项目确认可接受”。至少要说明偏离内容、偏离原因、影响范围、替代措施、验证结果和审批结论。必要时要向芯片供应商获取澄清，或者在系统安全分析中降低对该机制的依赖。功能安全项目并不要求所有推荐措施都一字不差照做，但要求每一个偏离都有清楚的工程理由和证据。

这也是 Safety Manual 和普通数据手册最大的差异之一。数据手册更多告诉你参数边界，Safety Manual 更多告诉你安全论证边界。越是安全相关系统，越不能把边界当装饰。

八、第五步：从Safety Manual到安全案例

Safety Manual 最终要进入安全案例。这里的安全案例，不是某一个模板文件，而是项目用来说明安全目标、技术安全需求、硬件软件设计、验证确认、残余风险和流程证据之间关系的一整套论证。

在安全案例里引用 Safety Manual，需要避免两种写法。第一种是空泛引用，例如“芯片具备 Safety Manual，因此满足功能安全要求”。这种说法太粗，无法证明项目使用方式正确。第二种是堆砌引用，把手册条款大量复制到项目文档里，却没有说明项目如何实现和验证。复制越多，不代表证据越强；证据强不强，取决于能否追溯到项目活动。

更好的写法，是把 Safety Manual 放在证据链的中间层。上游连接芯片供应商的安全分析和用户责任，下游连接项目需求、架构、实现、测试和安全分析。比如某条安全机制在手册中用于检测特定失效，项目安全分析把相关失效分配给该机制，软件需求定义启用和监控方式，硬件设计提供必要连接，测试报告证明故障可以被检测并触发反应，最终安全案例引用这一组证据说明风险控制成立。

这种写法对底盘控制器尤其重要。底盘系统往往同时涉及传感器输入、控制算法、执行器驱动、通信网络、电源管理和故障降级。芯片只是其中一层。如果安全案例只停在芯片层，就无法说明整车行为；如果完全忽略芯片层，又无法说明底层随机硬件故障如何被控制。Safety Manual 的作用，就是帮助芯片层和系统层对上话。

项目团队可以把 Safety Manual 相关证据分成四类归档。第一类是供应商输入，包括手册、FMEDA 摘要、适用范围说明、限制条件、errata 和安全库说明。第二类是项目分解，包括使用假设矩阵、安全机制映射表、需求追溯和偏离记录。第三类是实现证据，包括硬件原理图、软件配置、启动流程、错误处理设计和安全监控任务。第四类是验证证据，包括审查记录、故障注入、集成测试、HIL 测试和确认报告。

这样做的好处是，评审时不再围绕“有没有这个文档”争论，而是可以直接检查“这条供应商假设在项目里如何关闭”。这才是 Safety Manual 真正进入工程的样子。

九、常见误区

图 9　四个常见误区

第一个误区，是把 Safety Manual 当成合格证。芯片厂商提供功能安全文档，说明它在特定范围和假设下完成了相应分析，但系统合规仍然取决于项目如何集成、配置、验证和论证。把供应商输入直接等同于系统结论，是很多评审问题的源头。

第二个误区，是复制安全机制名称。比如在安全分析中写“Memory ECC”并不等于使用了 ECC。项目需要说明 ECC 覆盖哪些区域、何时启用、错误如何上报、是否有中断或状态寄存器、软件如何处理、是否做过故障注入。没有这些内容，机制名只是标签。

第三个误区，是忽略使用假设。Safety Manual 里看似普通的“用户应当”“系统需要”“建议配置”，很可能是供应商安全分析成立的前提。项目不满足这些前提时，不能假装前提仍然成立。

第四个误区，是没有证据链。项目可能真的做了很多工作，但如果使用假设、机制映射、配置实现和测试报告之间没有追溯关系，评审人员仍然无法判断安全闭环是否成立。功能安全不只看做没做，也看能不能证明做对了。

第五个误区，是忽略变更。芯片修订、手册版本、errata、安全库、驱动、编译器、硬件原理图、系统安全需求发生变化，都可能影响 Safety Manual 的适用性。项目要把它纳入变更影响分析，而不是项目初期读一次就结束。

第六个误区，是让功能安全工程师单独消化手册。Safety Manual 的落地一定是跨角色的。功能安全工程师可以组织追溯和论证，但硬件工程师要看供电、复位、监控和连接，软件工程师要看启动、配置、诊断和故障处理，系统工程师要看安全需求分配和降级策略，测试工程师要看验证方法和故障注入。任何一个角色缺席，闭环都可能不完整。

十、项目落地检查清单

图 10　Safety Manual检查清单

如果项目已经拿到芯片 Safety Manual，可以用下面这套检查逻辑快速判断是否真正用起来了。

第一，手册版本是否与芯片型号、芯片修订、驱动版本和安全库版本一致。不要只看文件名，要确认适用范围。

第二，使用假设是否已经逐条登记。每条假设是否有项目解释、责任人、实现方式、验证证据和关闭状态。

第三，安全机制是否完成项目映射。每个被项目依赖的机制是否对应安全需求、硬件依赖、软件配置、诊断路径和故障反应。

第四，配置是否经过审查。启动配置、寄存器设置、中断映射、错误聚合、阈值、锁定策略、测试周期是否与手册要求一致。

第五，诊断是否经过验证。至少要确认关键诊断可以被触发、状态可以被读取、反应可以被观察、时间可以被评估。

第六，偏离是否有记录。凡是没有采用手册建议、没有满足使用假设、修改了推荐流程或替换了安全机制的地方，都要有影响分析和审批结论。

第七，证据是否可追溯。不要把证据散落在不同文件夹里，而要能从 Safety Manual 条目追溯到需求、设计、实现、测试和安全案例。

第八，变更是否会重新触发评估。当芯片、手册、硬件、软件、工具链或安全需求变化时，相关使用假设和机制映射是否重新检查。

这八项并不是为了制造文档工作量，而是为了让项目从“拥有手册”走向“正确使用手册”。对于复杂底盘控制器来说，这一步越早做，后期返工越少。

十一、对不同角色的具体建议

系统工程师要重点关注安全需求分配。不要把芯片安全机制当成系统安全目标本身，而要判断某个机制能支持哪条技术安全需求，能降低哪类失效风险，失效后系统应进入什么状态。系统工程师还要定义降级策略和安全状态，否则芯片上报错误后，软件和执行器不知道该如何行动。

硬件工程师要重点关注供电、复位、时钟、外部监控、错误信号、调试接口和器件连接。很多 Safety Manual 条款看起来像软件配置，背后却依赖硬件设计。例如错误输出是否连接到外部监控路径，电源轨是否被独立监控，复位链路是否存在单点风险，外部晶振或时钟源是否满足要求。

软件工程师要重点关注启动流程、寄存器配置、诊断读取、异常处理、安全机制锁定、周期任务和故障反应。软件实现不能只保证功能跑起来，还要保证安全机制在正确时间启用，错误状态不会被漏读，故障路径不会被普通异常处理吞掉，安全相关配置不会被后续代码覆盖。

测试工程师要重点关注故障注入和可观测性。Safety Manual 中建议的验证点，不能全部靠普通功能测试覆盖。需要设计专门的异常测试、接口测试、启动失败测试、通信错误测试、状态寄存器检查和系统反应检查。对于无法真实注入的故障，也要说明替代验证方法和局限。

功能安全工程师要重点关注追溯和论证。不是替所有角色做技术细节，而是把供应商输入、项目需求、实现证据和验证证据组织成可以审查的结构。功能安全工程师最应该追问的问题是：这条手册假设在项目哪里关闭？这个机制在安全分析里承担了什么？这个诊断是否真的被验证？这个偏离是否重新评估？

供应商接口负责人也不能缺席。手册里不清楚的地方，要及时向芯片供应商确认。尤其是诊断覆盖假设、机制适用范围、errata 影响、安全库使用边界、推荐配置的必要性、不同芯片修订之间的差异，不能靠项目内部猜测解决。

十二、总结：它不是终点，而是输入

图 11　Safety Manual不是终点，是安全案例的输入

Safety Manual 最值得被重视的地方，是它让芯片层面的安全分析可以被系统项目继承。但“可以继承”不等于“自动继承”。项目必须确认使用假设成立，必须正确配置安全机制，必须验证诊断链路，必须处理偏离和变更，必须把证据放进安全案例。

真正成熟的项目，不会在评审时简单说“芯片有 Safety Manual”。它会说：我们识别了手册中的用户责任，建立了假设落地矩阵；我们把安全机制映射到系统需求、硬件设计和软件实现；我们完成了关键诊断配置审查和故障注入验证；我们记录了所有偏离及其影响分析；我们把供应商证据和项目证据共同纳入安全案例。

做到这一步，Safety Manual 才不再是供应商资料包里的一份 PDF，而是项目安全闭环中的工程输入。它不替你完成系统安全，但能帮你少走很多弯路；它不替你承担最终责任，但能把芯片供应商、系统团队、硬件团队、软件团队、测试团队和功能安全团队放在同一张证据地图上。

对功能安全项目来说，文档本身从来不是目的。真正重要的是：每一个安全假设有没有被确认，每一个安全机制有没有被正确使用，每一个诊断有没有被验证，每一个结论有没有证据支撑。Safety Manual 用得好，芯片才不只是“安全芯片”，而是系统安全论证中可被信任的一环。

文章图片来源于网络，若有侵权，请联系删除。