功能安全概念阶段开发实施要点｜盖世大学堂功能安全系列知识讲解

一、概念阶段的核心框架与开发模型

汽车功能安全概念阶段是ISO 26262标准中“Part 3”所规定的关键环节，其核心目标是通过系统化的流程定义相关项、分析风险并设计安全方案，为后续的系统开发、硬件与软件设计奠定基础。从标准框架来看，概念阶段主要包含三个核心活动：相关项定义（Item Definition）、危害分析与风险评估（Hazard Analysis and Risk Assessment, HARA）以及功能安全概念（Functional Safety Concept, FSC）的制定。这些活动贯穿于产品的安全生命周期，是确保车辆功能在异常状态下仍能避免不合理风险的关键。

概念阶段的开发模型呈现L型流程走向，具体可分为四个核心步骤。首先，需收集与相关项有关的所有已有信息，包括功能定义、用例描述、产品设计文档等，通过梳理形成“相关项定义”文档。这一步是后续所有分析的基础，其输出的准确性直接影响风险评估的有效性。其次，基于相关项定义开展HARA活动，该过程需依赖外部输入，如VDA 702（场景分类标准）、ISO 21448（预期功能安全）等，最终输出危害分析与风险评估报告。由于HARA的结果将直接决定下游供应商的安全等级要求，因此该环节的评审需满足最高的独立性等级（I3），即由不同机构的非利益相关方进行审核，以避免因利益关联导致的风险误判。

在HARA活动之后，需结合功能或系统架构设计，将风险评估得出的安全目标转化为具体的功能安全概念。这一过程的核心是推导功能安全要求（Functional Safety Requirements, FSR），明确系统在故障情况下应采取的安全机制。最后，功能安全概念需经过认可评审与验证评审，形成验证报告，确保其符合安全目标且能有效减轻或避免危害。整个流程中，每个环节的输出都需经过严格的文档管控与评审，以保证开发过程的可追溯性与合规性。

二、相关项定义与功能定义的边界与关联

相关项定义（Item Definition）是概念阶段的起点，其核心是明确“相关项”的范围与边界。根据ISO 26262标准，相关项是指在整车层面实现完整或部分功能的系统或系统组合，例如自适应巡航控制（ACC）、电子稳定程序（ESC）、转向助力系统等。这些系统直接影响车辆的动态行为，其功能异常可能导致危害事件的发生。与之相对的“要素”（如传感器、芯片、执行器）则是支持相关项功能的组件，其本身并不直接实现整车功能，因此需以“独立于环境的安全要素”形式进行开发，无需纳入相关项定义的范畴。

相关项定义与功能定义的区别在于，功能定义聚焦于单一功能的具体表现（如转向助力的扭矩范围、制动系统的减速度），而相关项定义则从整车视角出发，整合功能与系统间的依赖关系。例如，转向助力功能的定义可能描述“在车速30km/h时提供5N·m的助力扭矩”，而相关项定义则需说明“转向助力系统与驾驶员操作、路面摩擦力、ESP系统的交互关系”。这种整合性的描述是后续危害分析的基础，确保风险评估不遗漏任何系统间的关联影响。

相关项定义文档的编制需整合多方面信息，包括但不限于：法规与标准要求（如GB 7258、ISO 26262）、功能用例（Use Case）、预实验结果、产品设计文档等。文档内容需明确以下关键信息：相关项的功能目标（如“实现0-130km/h范围内的自适应巡航”）；与驾驶员的交互方式（如“通过方向盘按键激活，仪表显示当前状态”）；运行环境限制（如“仅在铺装路面、能见度≥50m时可用”）；与其他相关项的依赖关系（如“依赖ESP系统提供的车身稳定信号”）；已知的不安全信息（如“低温环境下传感器可能延迟响应”）。这些信息需经过跨部门评审（如产品、安全、测试团队），确保全面性与准确性。

三、 危害分析与风险评估（HARA）的实施流程

危害分析与风险评估（HARA）是概念阶段的核心活动，其目的是识别功能异常可能引发的危害事件，评估风险等级，并确定对应的安全目标。HARA的实施需遵循系统化的流程，确保覆盖所有潜在风险。

（一）功能异常与危害的识别

功能异常（Malfunctioning Behavior）是指相关项偏离预期功能的表现，可通过HAZOP（危险与可操作性分析）方法识别。HAZOP方法基于“引导词+功能参数”的组合，系统性地列举潜在异常，例如针对转向助力功能，引导词“过量”与参数“扭矩”组合可得出“转向助力扭矩过量”，引导词“丢失”与参数“信号”组合可得出“转向角信号丢失”。常见的引导词包括：过量（Excessive）、不足（Insufficient）、丢失（Loss）、反向（Opposite）、非预期激活（Undemanded Activation）、卡滞（Stuck）等。不同功能的异常模式存在差异，例如制动系统的异常可能包括“制动压力不足”“非预期制动”，而转向系统则可能包括“转向角度偏移”“助力突然消失”。

危害（Hazard）是功能异常在整车层面引发的不安全状态，需结合车辆运动的六个自由度（纵向、横向、垂直、俯仰、侧倾、偏航）分类。例如，纵向方向的危害可能包括“非预期加速”“制动失效”；横向方向的危害可能包括“非预期转向”“侧滑”。危害的描述需聚焦于整车级后果，而非功能本身的异常，例如“转向助力过量”是功能异常，而“车辆非预期偏离车道”才是危害。

（二）危害事件的构建

危害事件（Hazardous Event）是“危害+运行场景”的组合，其中运行场景（Operating Situation）需涵盖环境、道路、交通参与者等要素。运行场景的分类可参考VDA 702（场景目录）、SAE J2980等标准，典型维度包括：位置（如城市道路、高速公路、停车场）；道路条件（如干燥、湿滑、结冰）；交通状况（如拥堵、畅通、交叉路口）；车辆状态（如静止、加速、转弯）；环境因素（如光照、能见度、风速）。例如，“城市道路交叉路口处，车辆因制动失效导致追尾前方车辆”即为一个完整的危害事件，其中“制动失效”是危害，“城市道路交叉路口”是运行场景。

在构建危害事件时，需注意场景的“颗粒度”。过于宽泛的场景（如“道路行驶”）会导致风险评估不准确，而过于细化的场景（如“晴天30℃、风速2m/s的城市主干道”）则会增加分析复杂度。企业需根据产品特性定义合适的颗粒度，例如针对自动泊车功能，需重点关注“狭小空间（≤2.5m宽车位）”“障碍物密集区域”等场景。

（三）风险等级的评估

风险等级由暴露度（E）、危害度（S）、可控度（C）三个维度决定，每个维度分为4个等级，最终映射为ASIL等级（A、B、C、D）或QM（质量管理）。

暴露度（E）衡量危害事件所在场景的发生频率或持续时间，分为E1（极低）至E4（极高）。若危害与场景发生次数相关（如通过交叉路口的次数），则采用频率维度：E1（每年＜1次）、E2（每年几次）、E3（每月几次）、E4（每次驾驶）。若与场景持续时间相关（如高速公路行驶时长），则采用时间占比维度：E1（＜1%）、E2（1%-10%）、E3（10%-30%）、E4（＞30%）。例如，“高速公路巡航”场景的暴露度通常为E3（中等），而“停车场泊车”场景可能为E2（低）。

危害度（S）评估伤害的严重程度，参考AIS（损伤严重度评分）分为S0（无伤害）至S3（致命伤害）。S0对应AIS 0（无伤害，如轻微刮擦）；S1对应AIS 1-2（轻伤至中度伤害，如皮肤挫伤、单纯性骨折）；S2对应AIS 3-4（严重但非致命伤害，如颅骨骨折、内脏损伤）；S3对应AIS 5-6（致命伤害，如脊柱断裂、体腔开放伤）。实际评估中，可结合碰撞速度判断：例如正面碰撞中，Δv（相对速度）＜10kph通常为S0；10-40kph为S1-S2；＞40kph为S3。不同碰撞类型（正面、侧面、追尾）的阈值存在差异，侧面碰撞因车身保护较弱，Δv＞20kph即可评为S3。

可控度（C）评估交通参与者规避伤害的能力，分为C0（可控）至C3（不可控）。C0指“超过99%的普通驾驶员可规避伤害”（如低速下的轻微转向偏移）；C1指“90%-99%的驾驶员可规避”（如高速公路上的车道偏离，驾驶员有足够时间修正）；C2指“不足90%的驾驶员可规避”（如突发制动失效，需紧急操作）；C3指“几乎无法规避”（如高速行驶中转向突然失灵）。C2需通过测试验证：选取20名不同驾驶经验的测试者，在场景复现中若均能规避伤害，可证明85%以上的可控性；C1可基于专家判断；C3无需验证。

（四）安全目标的确定

安全目标（Safety Goal）是针对每个危害事件制定的风险控制目标，其ASIL等级由E、S、C的组合确定。根据ISO 26262标准，E、S、C的不同组合对应不同ASIL等级，例如：S3（致命伤害）+E4（高暴露）+C3（不可控）=ASIL D；S2（严重伤害）+E3（中暴露）+C2（低可控）=ASIL B。安全目标需以“防止/减轻危害事件”的形式表述，例如“防止因制动失效导致的高速行驶中追尾事故（ASIL D）”。

安全目标需明确两个关键属性：安全状态（Safe State）和FTTI（故障容错时间间隔）。安全状态是指故障发生后应达到的安全状态，例如“制动系统失效后，激活电子驻车制动，保持车辆静止”；FTTI是从功能异常到危害事件发生的最大允许时间，需通过仿真或测试确定，例如转向系统的FTTI通常为200ms（即故障发生后，需在200ms内完成诊断与安全状态迁移）。FTTI的确定需考虑最坏场景：例如在湿滑路面上，转向失效后车辆可能在1.5s内偏离车道，因此FTTI需≤1.5s。

四、功能安全概念（FSC）的设计与验证

功能安全概念（FSC）是基于安全目标推导的整车级安全方案，核心是将安全目标转化为可执行的功能安全要求（FSR），并分配至系统或组件层面。

（一）功能安全要求（FSR）的推导

FSR的推导需覆盖故障处理的全流程，包括故障避免、探测、响应及安全状态迁移。以“防止近光灯非预期关闭（ASIL B）”的安全目标为例，FSR可分为：

输入层：开关模块（SM）需持续发送“点亮”信号（FSR1：SM在驾驶员激活后，每秒发送一次“近光灯开启”信号，信号错误率≤10⁻⁸/h）；

传输层：CAN总线需检测信号异常（FSR2：通讯链路需采用CRC校验，错误帧比例≤10⁻⁶）；

处理层：车身控制模块（BCM）需验证信号有效性（FSR3：BCM若连续3次未收到信号，需激活备用电源点亮近光灯）；

输出层：灯具执行器需确保冗余（FSR4：至少保持一盏近光灯点亮，即使其中一个灯泡故障）。

FSR需明确以下属性：运行模式（如“仅在点火开关ON时生效”）；容错时间（如“BCM需在100ms内检测到信号丢失”）；安全状态（如“近光灯保持常亮”）；冗余设计（如“双路电源供电，单路故障时自动切换”）。对于辅助驾驶等复杂系统，还需考虑紧急运行策略：例如“当辅助驾驶系统失效时，在5s内提醒驾驶员接管，若未响应则执行靠边停车”。

（二）外部依赖与接口设计

功能安全概念可能依赖非电子电气技术（如机械、液压系统）或外部相关项（如ESC、ADAS系统），需明确这些依赖的安全要求。例如，若制动系统的安全概念依赖机械驻车制动（非电子系统），则需导出：“机械驻车制动在车速≤5km/h时，制动效能≥300N·m（ASIL QM）”。对于外部电子系统，如“辅助驾驶系统依赖ESC提供的横摆角速度信号”，则需提出：“ESC发送的横摆角速度信号误差≤2°/s，更新频率≥100Hz（ASIL C）”，并要求ESC遵循ISO 26262的对应等级开发流程。

接口设计需定义信号格式、校验机制及容错策略。例如，CAN通讯接口需规定：“信号采用8位数据格式，包含1位奇偶校验位；连续3次校验失败时，触发备用通讯链路（如LIN总线）”。对于跨系统接口，还需考虑时序要求：“ADAS系统向制动系统发送的减速请求，需在10ms内得到响应，超时则触发降级”。

（三）功能安全概念的验证

功能安全概念的验证需证明其符合安全目标，包括以下方式：

评审验证：由独立团队（I2等级）审核FSR的完整性（是否覆盖所有安全目标）、一致性（不同FSR之间无冲突）及可行性（技术上可实现）；

仿真验证：通过CarSim、Prescan等工具仿真故障场景，验证安全机制的有效性，例如“仿真转向助力丢失后，ESP系统是否能在FTTI内纠正车辆轨迹”；

原型验证：在HIL（硬件在环）测试台架上，模拟ECU故障（如信号中断、计算错误），验证安全状态迁移的及时性，例如“人为切断转向传感器信号，测量BCM激活备用模式的响应时间是否≤150ms”。

验证需形成文档，包括验证计划（明确验证目标与方法）、测试用例（覆盖所有FSR）、结果报告（记录实测值与目标值的偏差）。对于高ASIL等级（如C、D）的安全目标，验证需采用更严格的方法，例如增加测试样本量（≥50次）、引入第三方机构审核。

汽车功能安全概念阶段是安全开发的基石，其核心是通过相关项定义明确边界，通过HARA识别风险，通过FSC设计安全方案。相关项定义需聚焦整车功能与交互，确保分析范围的准确性；HARA需系统化识别危害事件，科学评估E、S、C以确定ASIL等级；FSC需将安全目标转化为可执行的FSR，覆盖故障处理全流程，并验证其有效性。

概念阶段的输出直接影响后续开发环节，因此需注重文档的规范性与评审的独立性。企业需建立跨部门协作机制（如安全委员会），确保产品、安全、工程团队的协同；同时，需积累场景库与故障案例（如基于实际事故数据），提升HARA的准确性。随着辅助驾驶等复杂功能的普及，概念阶段还需结合预期功能安全（SOTIF，ISO 21448），考虑性能局限导致的风险，实现更全面的安全保障。