企业官网建设流程全解析

简介：面向智能网联汽车功能安全从业者、系统与软件工程师及高校相关专业学习者，这份资料提供预期功能安全（SOTIF）领域两份核心标准的中文文本，即国际标准 ISO 21448 与国家标准 GB/T 43267，帮助读者系统理解在无实际故障情形下识别、评估并缓解自动驾驶与辅助驾驶系统潜在危险的方法论。压缩包内为 1 个 PDF 文件，约 40.15MB，内容涵盖规范定义与设计、危害识别与风险评估、潜在功能不足及触发条件的识别与评估、功能修改措施、验证与确认策略等完整章节，并附术语定义与工作成果要求，便于按标准结构逐章查阅与对照引用。目前已有 735 人学习下载，适合需要将 SOTIF 流程落地到项目开发、或准备标准符合性审查的读者作为案头参考。

1. 一份能直接翻的 SOTIF 中文版：为什么我把它放在手边

做 L2 以上辅助驾驶项目的人大概都遇到过这种场面：评审会上有人问“这个感知漏检算功能安全还是预期功能安全”，会议室安静三秒，然后大家开始翻各自存的英文版 PDF，页码对不上，术语翻译还不一致。我最早接触 SOTIF 时也是这么过来的，ISO 21448 的英文原版啃了三遍，真正落地写危害分析和场景清单时还是心里没底。后来拿到这份 GB/T 预期功能安全征求意见稿的中文版，情况才好转——它不是把英文逐字机翻，而是按国内标准体系的表述习惯重新组织了术语和流程，第 3 章的术语定义、第 5 到第 12 章的活动流程、附录 A 到 E 的工程指南，基本能对着项目节点直接查。这份资源适合三类人：刚接手 SOTIF 工作、需要快速建立流程框架的系统工程师；要写危害识别和场景评估文档的安全工程师；以及需要跟功能安全团队对齐边界的项目负责人。它解决的核心问题很具体——把“功能不足”和“故障”这两类风险拆开讲清楚，让你知道哪些归 GB/T 34590 管，哪些必须走 SOTIF 流程。

2. 先分清边界：SOTIF 和功能安全到底怎么切

2.1 从因果模型看两类风险的差异

很多人第一次读这份标准，卡在“功能不足”这个词上。标准第 3 章把它定义为规范定义不足或性能局限，并且明确说功能不足可能被认为是系统性故障，但应对措施是 SOTIF 特有的。这句话背后的逻辑是：功能安全假设预期功能本身是安全的，只处理 E/E 系统失效导致的偏离；而 SOTIF 处理的是系统没坏、但就是做不到的情况，比如摄像头在逆光下漏检、融合算法对异形车辆识别不稳、决策逻辑对加塞场景响应过慢。

标准图 2 到图 4 给的因果模型值得反复看。它把链条拆成触发条件、功能不足、输出不足、危害行为、危害事件、伤害几段，并且区分了整车层面和要素层面。整车层面的功能不足被触发后直接产生危害行为；要素层面的功能不足先产生输出不足，再和其他要素的输出不足叠加，才促成整车层面的危害行为。这个区分在写分析文档时非常实用——你可以在要素层记录“某传感器在雨雾下置信度下降”，在整车层记录“AEB 未触发”，两层分开归因，评审时不容易扯皮。

我一般会拿一个具体功能做对照练习：假设某 L2 高速公路辅助功能，感知要素在隧道出入口明暗突变时输出不稳定，这是要素层功能不足；驾驶员监控摄像头在驾驶员低头看手机时未能及时告警，这是另一条要素层功能不足；两条叠加，驾驶员没接管、系统也没降级，才构成整车层面的危害行为。按这个链条写下来，触发条件、功能不足、危害行为各归各位，比笼统写“感知不可靠”要经得起追问。

2.2 用表 1 做标准映射，避免重复劳动

标准引言里的表 1 是我用得最多的一页。它把危害来源和对应标准列成了一张映射表：E/E 系统故障归 GB/T 34590，功能不足归本文件，HMI 设计不当归本文件加人机交互原则，基于 AI 算法的功能不足归本文件，信息安全攻击归 ISO/SAE 21434 或 SAE J3061，外部基础设施和 V2X 影响归本文件加相关标准，环境因素如天气、电磁干扰归本文件加 GB/T 34590 和一系列电磁兼容标准。

这张表的实操价值在于：做 HARA 的时候，团队经常把感知性能局限也塞进功能安全的安全目标里，导致安全目标写得又大又空。正确的做法是先按表 1 分类，属于功能不足的单独建 SOTIF 风险条目，不要和随机硬件失效混在一个安全目标下。我见过一个项目把“摄像头在强光下漏检”写成 ASIL B 的安全目标，结果验证时既没法用故障注入覆盖，也没法用场景测试量化，最后返工重写。如果一开始就按表 1 切开，功能安全那边只管失效，SOTIF 这边管性能和规范不足，验证策略各走各的路，工作量反而小。

提示：表 1 里“合理可预见的误用”同时出现在本文件和 GB/T 34590 两栏，别理解成两边都要做全套。我的做法是直接误用（比如在非 ODD 场景激活功能）归 SOTIF 的触发条件分析，间接误用（比如驾驶员睡着导致可控性下降）归 SOTIF 的无法防止/探测/减轻那条线，功能安全只在误用直接引发系统失效时才介入。

2.3 接受准则的双层结构怎么落到文档里

第 3 章对接受准则的定义给了两层：第一层判断车辆行为是否属于危害行为，第二层判断残余风险是否处于合理水平。标准图 1 画了评估顺序，先看单次行为或事件是否构成有风险的危害行为，再看一定里程或时间内危害行为导致的残余风险是否可接受。

落到文档里，我一般这样组织：第一层用场景化的行为判据，比如“非预期横向加速度超过某阈值且持续超过某时长”算危害行为；第二层用统计口径，比如“每万公里危害行为导致的事件数低于某水平”，或者跟人类驾驶员在同类场景下的操作分布做对比。标准注 2 提到可以类比横风来定义车道保持辅助的接受准则，这个思路很实用——找一个使用中已被证明驾驶员可控的同类扰动作为参照，比凭空拍一个数字更有说服力。

需要提醒的是，双层准则的指标值会随技术演变和场景变化而调整，标准注 3 明确说了这一点。所以写接受准则时不要把数值写死成永久条款，留一个“指标值依据年度统计和场景库更新复核”的机制，后面改起来不至于推翻整份文档。

3. 把流程跑起来：从危害识别到场景评估的落地路径

3.1 规范定义和设计阶段要产出什么

第 5 章讲规范定义和设计，目的很明确：在功能定义阶段就把性能局限和应对措施写进去。标准要求考虑功能规范的定义、系统设计和架构、性能局限和应对措施，工作成果是相应的规范文档。这一章容易被当成“写需求”跳过，但后面所有分析都依赖这里的输入质量。

我的做法是先列一张功能能力边界表，把每个感知或决策环节的标称能力、已知局限、局限对应的场景条件写清楚。比如某前视摄像头，标称检测距离、在不同照度下的置信度变化、雨雾条件下的衰减曲线，这些数据来自供应商规格书和内部测试，不是拍脑袋。这张表直接成为第 7 章潜在功能不足分析的输入，也避免后面场景评估时找不到量化依据。

系统架构层面，标准强调要考虑要素之间的交互和冗余。这里有个常见误区：以为加了冗余就万事大吉。实际上冗余要素如果共享同一个触发条件（比如两个摄像头装在同一位置、同时被泥水遮挡），冗余就失效了。所以架构考虑里要写清楚冗余的独立性假设，以及假设不成立时的降级策略。

3.2 危害识别与风险评估的操作顺序

第 6 章给的是危害识别和风险评估的流程。标准没有规定具体方法，但给了方向：先识别危害，再评估风险，最后定义残余风险接受准则。我通常按三步走。

第一步，从功能场景出发做危害识别。把目标功能在 ODD 内的典型场景列出来，逐场景问“这个功能在这里可能做出什么危害行为”。这一步不要过早收敛，宁可多列。第二步，对每个危害行为评估严重度、暴露度和可控性，但注意 SOTIF 的风险评估和功能安全的 HARA 不完全一样——这里更关注场景条件和触发条件的组合，而不是失效模式。第三步，按第 3 章的双层接受准则定义哪些风险可接受、哪些必须改设计或加措施。

下面这段伪代码是我用来管理危害条目的结构，实际项目里用表格或需求管理工具实现，这里用 Python 字典示意字段组织方式：

# 危害条目结构示意，字段对应标准第6章的工作成果要求 hazard_item = { "id": "SOTIF-HZ-012", "function": "高速公路辅助驾驶", "odd_scene": "隧道出入口，明暗突变，前车为异形货车", "hazardous_behavior": "未保持安全跟车距离，纵向减速度不足", "trigger_conditions": ["照度突变", "异形目标", "前车突然减速"], "severity": "高", # 按整车层面伤害潜力评估 "exposure": "中", # 场景出现频率 "controllability": "低", # 驾驶员在该场景下的可控性 "acceptance_layer1": "横向/纵向行为判据", # 危害行为接受准则 "acceptance_layer2": "每万公里事件数上限", # 残余风险接受准则 "measures": ["增加隧道场景标定", "融合毫米波雷达距离"], "status": "待验证" }

这段结构的关键在trigger_conditions和measures两个字段。触发条件要写到可复现的程度，不能只写“光照变化”，要写清楚变化速率和范围；措施要对应到具体的设计修改或验证活动，不能写“加强测试”这种空话。字段acceptance_layer1和acceptance_layer2分开存，是为了后面第 10、11 章评估时能分别引用。

3.3 潜在功能不足与触发条件的分析手法

第 7 章是整份标准里技术含量最高的部分之一。它要求识别潜在功能不足和潜在触发条件，并预估系统对触发条件的响应可接受度。标准附录 B 给了场景和系统分析指南，包括推导误用场景的方法、场景因素构建示例、以及 STPA 方法在 ADAS 和自动驾驶 SOTIF 研究中的应用。

我常用的组合是：先用场景因素分解把 ODD 拆成道路、交通、天气、光照、目标物几类因素，每类因素列出取值和组合；再对每个功能环节做 STPA 式的控制结构分析，找“控制动作在什么条件下会不安全”。STPA 的好处是不依赖失效假设，正好契合 SOTIF 处理“没坏但不够好”的场景。

举个具体例子：某自动紧急制动功能，控制结构里感知环节输出目标距离和相对速度，决策环节判断是否触发制动。用 STPA 分析时，问“感知输出的距离在什么条件下会偏大导致制动过晚”，得到的触发条件包括目标物反射率低、雨天镜头水膜、逆光过曝。这些条件再和场景因素组合，就形成第 10 章已知场景评估的测试用例来源。

标准第 7 章还要求预估系统对触发条件的响应的可接受度。这一步我一般用分级方式：响应完全可接受、响应可接受但需监控、响应不可接受需修改设计。分级依据来自第 5 章的能力边界表和第 6 章的接受准则，不是主观打分。

3.4 修改功能与验证确认策略的衔接

第 8 章讲修改功能以解决 SOTIF 相关风险，第 9 章讲定义验证和确认策略。这两章要连起来看，因为修改措施直接决定验证什么。标准第 8 章列的措施包括改进规范定义、增加冗余、限制 ODD、增加驾驶员监控等，每类措施对应的验证方法不同。

第 9 章把验证和确认分成集成和测试的定义，工作成果是验证确认策略文档。我的经验是策略文档里必须写清楚三件事：每个 SOTIF 风险条目对应哪类测试（仿真、场地、道路、在环），测试的通过判据是什么，以及覆盖度怎么算。标准附录 C 给了验证和确认指导，包括确认目标的导出、感知系统的验证确认、场景参数化及场景抽样、减少确认测试的考虑，这几节在写策略时值得逐条对照。

场景抽样那块特别实用。标准 C.5 讲场景参数化，意思是把场景拆成可调参数（比如车速、距离、光照强度、目标物类型），用抽样方法覆盖参数空间，而不是穷举。我一般先用拉丁超立方或均匀设计做初筛，再对高风险区域加密采样。这样既控制测试量，又能说清楚覆盖逻辑。C.6 还讨论了减少确认测试的考虑，前提是你有充分的论证支撑，不是随便砍用例。

4. 已知场景与未知场景：两套评估逻辑别混用

4.1 已知场景评估的四个层面

第 10 章把已知场景的评估拆成感知验证、规划算法验证、执行验证、系统集成验证，最后汇总已知危害场景导致的残余风险。这个拆分方式很工程化，因为不同层面的验证手段和判据完全不同。

感知验证关注检测率、误检率、测距测速精度在不同场景条件下的表现，通常用标注数据集加仿真回放，场地测试做补充。规划算法验证关注决策逻辑在场景序列中的正确性，更多依赖仿真和场景库回放。执行验证关注底盘响应是否跟得上规划指令，场地测试为主。系统集成验证看端到端行为，道路测试和影子模式数据是主要来源。

我踩过的一个坑是把感知验证的指标直接当成系统级通过判据。感知召回率达标不代表端到端行为可接受，因为规划环节可能把感知的不确定性放大，也可能因为保守策略导致通行效率不可接受。所以第 10 章最后一步的残余风险评估必须站在整车行为层面做，不能拿要素层指标凑数。

4.2 未知场景评估的现实做法

第 11 章讲未知场景评估，标准给的方向是评估未知场景残余风险，工作成果是相应文档。这一章读起来最“虚”，因为未知场景没法穷举。我的理解是它要求两件事：一是证明你的已知场景覆盖方法有合理的外推能力，二是建立运行阶段的发现机制。

外推能力靠场景参数化的覆盖论证，比如你证明了在光照强度连续变化维度上采样足够密，那么未采样的中间值风险可控。发现机制靠第 13 章的运行阶段活动，包括现场监控和 SOTIF 问题评估解决流程。标准附录 D 里对机器学习的建议、OTA 更新的 SOTIF 考虑，都是为未知场景留的口子——模型更新可能引入新的未知，所以更新流程里要带回归评估。

注意：未知场景评估不是写一句“持续监控”就交差。评审时会被追问监控什么指标、触发什么动作、多久复盘一次。我一般会定义几个先行指标，比如特定场景下的接管率突增、感知置信度分布偏移、影子模式中规划与人类驾驶的偏离度，指标越界就触发场景库补充和风险评估更新。

4.3 SOTIF 成果评估与发布推荐

第 12 章讲 SOTIF 成果的评估，包括评估方法和准则、SOTIF 发布推荐。这一章对应项目节点的安全发布决策。标准没有给一刀切的通过线，而是要求基于前面各章的工作成果做综合评估。

实操上我会准备一份 SOTIF 论证包，内容包括：功能定义和能力边界、危害条目及措施闭环状态、已知场景验证结果、未知场景评估和外推论证、运行阶段监控方案。发布推荐基于这份包做评审，而不是只看某一项测试报告。附录 A.1 给了用 GSN 构建 SOTIF 论证的示例，如果团队习惯用 GSN，可以直接参考那个结构把论证包组织成目标-策略-证据的树形，评审时逻辑链更清楚。

5. 避坑与排查：五条血泪经验

5.1 把功能不足当故障写，验证阶段返工

现象：危害分析文档里把感知性能局限写成失效模式，验证计划里安排故障注入测试，结果测不出问题，评审被质疑覆盖不足。原因：没有按标准表 1 做标准映射，功能安全和 SOTIF 的条目混在一起。解决：回到第 3 章的功能不足定义和第 6 章流程，把条目按“失效导致”和“规范/性能导致”分开，前者走 GB/T 34590 的验证方法，后者走场景测试和触发条件注入。返工成本高，最好在危害识别阶段就分栏管理。

5.2 触发条件写得太粗，场景库建不起来

现象：触发条件只写“雨天”“逆光”“异形目标”，到了建场景库时发现没法参数化，测试用例只能靠人拍脑袋。原因：第 7 章要求识别潜在触发条件时没有落到可观测、可控制的参数。解决：每条触发条件至少带一个可量化维度，比如降雨量范围、照度变化速率、目标物长宽比范围。标准附录 C.5 的场景参数化方法可以直接拿来当模板，先定参数再写条件。

5.3 接受准则只有一层，残余风险说不清

现象：项目评审时被问“单次危害行为可接受，但一年跑下来累积风险怎么算”，答不上来。原因：只定义了危害行为判据，没定义残余风险接受准则，违反第 3 章双层结构的要求。解决：补第二层准则，用里程或时间口径统计危害行为导致的事件率，参照标准注 2 的类比方法找可比对象。两层准则分开写、分开评，别混成一句话。

5.4 验证确认策略漏掉在环测试的定位

现象：验证计划里仿真、场地、道路都有，但 SIL/HIL/MIL 的用途说不清楚，被问“为什么这个场景要在 HIL 做”时只能答“惯例”。原因：第 9 章要求定义集成和测试时没有把在环测试和风险条目对应起来。解决：按标准引言示例 2 的思路，把在环测试定位为触发条件注入和场景覆盖的手段，每个在环测试用例标注它覆盖哪个触发条件和哪个功能不足，策略文档里写清楚选择理由。

5.5 运行阶段监控指标和 SOTIF 条目脱节

现象：第 13 章的运行阶段活动写了一套监控指标，但和前面的危害条目对不上，出了现场问题不知道回溯到哪条分析。原因：监控方案独立编写，没有和危害条目 ID 关联。解决：每个现场监控指标至少挂一个危害条目或触发条件 ID，SOTIF 问题评估解决流程里要求回溯到对应条目并更新风险评估。这样运行阶段的数据才能真正反哺设计和验证。

6. 进阶用法：把附录当工具箱，用 GSN 串起论证链

这份标准正文给流程，附录给方法，真正干活时附录的使用频率不比正文低。附录 A.1 的 GSN 论证示例我建议每个做 SOTIF 发布评审的人都看一遍，它把“功能安全目标达成”拆成策略和证据，正好对应第 12 章的成果评估。附录 B.4 的 STPA 应用示例适合做第 7 章分析时对照，尤其是控制结构画法和不安全控制动作的归类。附录 C.4 感知系统验证确认和 C.5 场景参数化抽样，是建场景库和定测试量的直接参考。附录 D 里 D.2 机器学习建议、D.5 感知性能目标量化与传感器局限举例、D.6 OTA 更新考虑，对应现在项目里最常见的三类新问题，遇到时先翻这几节再决定要不要另找资料。

我自己的习惯是建一个“标准条款-项目文档”对照表，左边列标准章节和附录编号，右边列项目里对应的文档或数据库条目，每次评审前过一遍，看哪些条款还没有落地证据。这个表最初是手写的，后来变成需求管理工具里的一个视图。下面是一个简化示例，用表格说明对照关系：

这张表最大的作用是防止“标准读完了但项目里找不到对应物”。有一次内部评审，第 7 章的触发条件清单只有半页，对照表一拉出来就发现感知环节的触发条件几乎没写，当场补了两周的分析。从那以后我每次做 SOTIF 节点评审前，都强制走一遍这张对照表，缺哪补哪，不靠记忆。希望这份中文版和这套用法能帮到你，少走几段我走过的弯路。

本文还有配套的精品资源，点击获取