课程导入：功能安全与预期功能安全的定义、区别与联系，课程目标与学习路径

在汽车电子与自动驾驶技术飞速迭代的今天，功能安全（Functional Safety, FS）与预期功能安全（Safety of the Intended Functionality, SOTIF）已成为产品量产落地不可回避的硬性门槛。许多工程师在接触ISO 26262与ISO 21448时，常常混淆两者的边界：误以为SOTIF只是功能安全在自动驾驶场景下的“换皮”，或者认为只要满足了ASIL等级就能覆盖所有风险。实际上，两者在安全目标、分析对象、触发条件与验证方法上存在本质差异，但又必须协同工作才能构建完整的安全防线。本节作为全课程的导入，将首先厘清这两个核心概念的准确定义、适用边界与内在联系，随后明确本课程的学习路径与实战目标，帮助学员建立系统化的安全工程思维框架。

1.1 核心定义：从“故障”到“功能不足”的安全视角迁移

功能安全（Functional Safety），依据ISO 26262标准，其核心关注点是E/E系统故障行为。这里的“故障”包括硬件随机失效（如电阻短路、芯片引脚虚焊）和系统性失效（如软件编码错误、需求规格遗漏）。功能安全的目标是确保当这些故障发生时，系统能够通过安全机制（如看门狗、冗余通道、故障诊断）将车辆引导至安全状态，避免对人员造成伤害。例如，当制动踏板位置传感器信号丢失时，系统应能识别该故障并切换至冗余制动模式，而不是直接失效。

预期功能安全（SOTIF），依据ISO 21448标准，其关注对象是预期功能在无故障情况下的性能不足或可合理预见的误用。这里的“功能不足”并非指系统坏了，而是指系统在特定场景下“能力不够”或“判断错误”。典型例子包括：摄像头在逆光或暴雨环境下无法准确识别行人；激光雷达对低反射率物体（如黑色车辆）漏检；自动驾驶系统在复杂路口对交通警察手势的误判。SOTIF的核心挑战在于：这些场景并非由故障引起，而是由功能本身的性能边界与复杂环境的不确定性共同导致。

1.2 判断方法：如何区分一个安全问题属于FS还是SOTIF

在实际工程中，安全工程师经常需要快速判断一个已识别的风险点应归入哪个标准体系进行管理。以下提供一套实用的判断流程：

1. 第一步：检查是否存在E/E系统故障。如果问题源于硬件随机失效、软件bug、电磁干扰导致的信号异常等，则属于功能安全范畴，应启动ISO 26262流程。
2. 第二步：若不存在故障，则评估功能性能是否满足设计规格。如果系统行为符合设计规格，但该规格本身在特定场景下无法保证安全（例如，毫米波雷达对静止目标的漏检是已知技术局限），则属于SOTIF范畴。
3. 第三步：考虑可合理预见的误用。例如驾驶员在自适应巡航开启时长时间脱手方向盘，系统虽未故障但无法应对该误用场景，这同样归入SOTIF。
4. 第四步：检查是否存在系统性安全漏洞。如果问题源于需求定义错误或安全分析不充分（如未识别某个关键场景），则可能同时涉及FS（系统性失效）和SOTIF（场景覆盖不足），需要两个标准协同处理。

1.3 案例拆解：AEB系统的一个典型安全分析场景

为帮助学员直观理解FS与SOTIF的协同关系，我们以自动紧急制动（AEB）系统为例进行拆解。AEB系统通过前向摄像头和毫米波雷达融合感知，在检测到前方障碍物且驾驶员未采取制动时自动刹车。

场景背景：某OEM在AEB系统开发中，安全团队需要完成功能安全与预期功能安全的双重分析。系统规格要求：在车速30-80km/h范围内，对前方静止车辆（含夜间场景）的检测率不低于99%。

初始现象与目标：在实车测试中，发现两个问题：① 在雨天夜间，摄像头图像噪声增大，导致目标识别延迟约200ms；② 当目标车辆为深色（如黑色）且无尾灯照明时，毫米波雷达反射截面积（RCS）过低，融合算法置信度不足，系统未触发制动。

分析判断过程：

• 问题①：摄像头在低照度+雨滴干扰下的性能下降，属于传感器物理极限，并非硬件故障。该问题应归入SOTIF范畴，需通过优化图像增强算法、增加雷达权重或限制系统运行条件（如恶劣天气降级为仅雷达模式）来解决。
• 问题②：深色车辆RCS低导致雷达漏检，属于传感器技术局限。但进一步分析发现，融合算法在置信度不足时默认“不制动”的策略，属于功能定义缺陷，同样归入SOTIF。然而，如果该策略导致系统在无故障情况下频繁误判，则可能引发驾驶员投诉或事故，需通过SOTIF场景库补充该边缘场景。
• 若在分析中发现，由于软件代码中某个变量溢出导致融合模块崩溃，则属于功能安全问题，需按ISO 26262进行ASIL等级评估并增加安全机制。

实际操作步骤：

1. 建立跨职能安全团队，分别负责FS（硬件/软件失效分析）和SOTIF（场景/算法性能分析）。
2. 针对问题①，在SOTIF框架下定义“雨天夜间”为触发条件，设计仿真场景并采集真实雨天数据，调整传感器融合权重策略。
3. 针对问题②，在SOTIF框架下扩展场景库，加入“深色静止车辆+无尾灯”场景，并优化置信度阈值逻辑，增加“保守制动”策略。
4. 在FS框架下，对融合模块进行FMEDA分析，识别变量溢出风险，增加输入范围检查和安全监控。

结果对比与复盘：经过上述协同优化，AEB系统在雨天夜间的误触发率降低40%，深色车辆检测率提升至97%。复盘经验表明：FS与SOTIF并非独立工作流，而是需要在系统架构层面共享传感器数据、场景信息和安全目标。若仅关注FS而忽略SOTIF，系统可能在无故障情况下依然不安全；反之，若仅关注SOTIF而忽略FS，则无法应对硬件失效风险。

1.4 课程目标与学习路径：从标准条款到工程落地

本课程的目标并非逐条解读标准条款，而是帮助学员建立一套可落地的安全工程方法论。课程将围绕以下四个核心能力展开：

• 体系构建能力：理解ISO 26262与ISO 21448的完整生命周期流程，能够根据项目特点裁剪流程并建立安全计划。
• 分析实战能力：掌握HARA（危害分析与风险评估）、FMEDA、FTA、STPA（系统理论过程分析）等核心方法，并能独立完成安全分析报告。
• 验证确认能力：熟悉功能安全测试（故障注入、鲁棒性测试）与SOTIF验证（场景仿真、实车测试、数据回灌）的工程方法。
• 管理协同能力：学会在项目进度、成本与安全目标之间取得平衡，推动跨部门安全评审与问题闭环。

学习路径分为四个阶段：第一阶段（第1-5章）夯实基础，掌握FS与SOTIF的核心概念、标准框架与安全文化；第二阶段（第6-15章）深入功能安全实战，覆盖从概念阶段到硬件/软件开发的完整流程；第三阶段（第16-24章）聚焦SOTIF落地，包括场景分析、算法验证与预期功能安全评估；第四阶段（第25-30章）进行综合实战演练，通过完整案例串联两大标准，并探讨AI安全、数据驱动安全等前沿话题。

1.5 常见误区与总结复盘

在课程导入阶段，有必要澄清几个常见误区，避免学员在后续学习中走弯路：