4、概念阶段在安全生命周期中的位置：输入、输出及其与系统、硬件、软件阶段的关系
在ISO 26262功能安全标准中，安全生命周期被划分为多个相互关联的阶段，而概念阶段（Concept Phase）是整个安全活动的起点与基石。它位于“相关项定义（Item Definition）”之后，是安全活动从“项目规划”走向“技术实现”的关键桥梁。概念阶段的核心任务并非编写代码或设计电路，而是通过系统化的危害分析与风险评估，定义出顶层安全目标（Safety Goals），并据此推导出功能安全概念（Functional Safety Concept, FSC）。这一阶段的输出将直接决定后续系统、硬件、软件阶段的安全需求分解方向与安全机制设计边界。如果概念阶段定义的安全目标不完整或安全需求存在歧义，那么后续所有阶段的工作都将建立在“流沙”之上，导致安全论证失效甚至产品召回。因此，理解概念阶段在安全生命周期中的精确位置、其输入输出的依赖关系，以及它与系统、硬件、软件阶段的接口，是每一位功能安全工程师必须掌握的核心技能。
上图清晰地展示了概念阶段在ISO 26262安全生命周期中的核心枢纽地位。它接收来自“相关项定义”的输入，经过内部的安全分析活动，向下游的系统、硬件、软件阶段输出安全需求。值得注意的是，概念阶段并非一次性活动，它与后端的验证确认活动存在反馈回路，当系统集成测试或安全评估发现安全目标不完整时，需要回溯至概念阶段进行修正。下面我们将从输入、输出以及与各阶段的关系三个维度进行深度拆解。
4.1 概念阶段的输入：相关项定义与安全启动条件
概念阶段并非凭空开始，其首要输入是相关项定义（Item Definition）。该定义由项目前期完成，它详细描述了被开发对象的功能、边界、接口、环境条件、法规要求以及已知的潜在危害。相关项定义的质量直接决定了概念阶段HARA（危害分析与风险评估）的覆盖度。如果相关项定义中对系统边界描述模糊，例如未明确“驾驶员干预”是否属于系统边界内的功能，那么后续的HARA将无法准确判断驾驶员误操作场景下的危害等级。
除了相关项定义，概念阶段还需要输入安全启动条件，包括：项目安全计划（确认安全活动的时间与资源）、安全案例框架（明确安全论证的预期结构）、以及初步的ASIL（汽车安全完整性等级）等级假设。这些输入确保了概念阶段的活动不是孤立的技术分析，而是嵌入在整个项目质量管理体系中的受控过程。
4.2 概念阶段的输出：安全目标与功能安全概念
概念阶段的核心输出物有两项：安全目标（Safety Goals, SG）和功能安全概念（Functional Safety Concept, FSC）。安全目标是从危害事件中提炼出的顶层安全要求，例如“避免车辆在行驶过程中发生非预期的加速”。每个安全目标都关联一个ASIL等级（A到D）和一个安全状态（Safe State）。安全目标不涉及具体技术实现，它只描述“要避免什么”以及“多严重”。
功能安全概念则是将安全目标转化为功能层面的安全需求。它定义了在检测到故障或危险事件时，系统应执行哪些功能行为。例如，针对“非预期加速”的安全目标，FSC可能要求“当检测到加速踏板位置传感器信号不合理时，系统应限制发动机扭矩输出至怠速状态，并点亮故障指示灯”。FSC中的每个安全需求都需分配ASIL等级，并明确其所属的系统元素（如传感器、控制器、执行器）。
| 输出物 | 内容描述 | ASIL等级 | 下游使用者 |
|---|---|---|---|
| 安全目标 (SG) | 避免特定危害事件发生的顶层安全要求 | ASIL A-D | 系统阶段、硬件/软件安全需求定义 |
| 功能安全概念 (FSC) | 实现安全目标的功能性安全需求，含故障检测与降级策略 | 继承自SG，可细化 | 系统架构设计、硬件/软件需求规格 |
| 安全需求规范 | 包含SG与FSC的汇总文档，含ASIL、FTTI、安全状态等属性 | 混合 | 安全验证与确认计划 |
4.3 概念阶段与系统阶段的关系：安全需求的分解与分配
概念阶段与系统阶段（ISO 26262-4）的关系最为紧密。概念阶段的输出——安全目标与FSC——是系统阶段技术安全需求（Technical Safety Requirements, TSR）的唯一来源。系统阶段将FSC中的功能需求进一步细化为技术实现方案，例如确定采用冗余传感器架构还是监控处理器架构。在此过程中，系统阶段会将FSC中的ASIL等级分解到具体的硬件和软件组件上。
例如，一个ASIL D的安全目标要求“避免转向系统丧失助力”。在系统阶段，工程师可能决定采用双电机冗余方案，并将ASIL D分解为两个独立的ASIL C(D)的通道。这种分解必须遵循ISO 26262-9中关于ASIL分解的规则，且分解后的需求必须可追溯到原始安全目标。概念阶段与系统阶段之间并非简单的线性传递，系统阶段在技术方案设计过程中，若发现FSC中的某些需求在物理上不可实现，必须将问题反馈至概念阶段进行FSC修订。
4.4 概念阶段与硬件、软件阶段的关系：间接但决定性的影响
虽然硬件阶段（ISO 26262-5）和软件阶段（ISO 26262-6）不直接接收概念阶段的输出，但它们的设计约束却完全由概念阶段衍生而来。硬件安全需求（HSR）和软件安全需求（SSR）均是从系统阶段的TSR中分解出来的。因此，概念阶段对硬件和软件的影响是“间接但决定性”的。
以硬件阶段为例，如果概念阶段的FSC中定义了“当车速超过120km/h时，禁止开启全景天窗”这一安全需求，那么硬件阶段在设计天窗控制器时，就必须考虑车速信号的输入接口、信号滤波电路以及故障诊断逻辑。如果FSC中未定义该需求，硬件设计将不会包含相关电路，导致最终产品无法满足安全目标。软件阶段同理，FSC中定义的故障响应时间（FTTI）直接决定了软件中断优先级和任务调度策略的设计。
4.5 案例拆解：电动助力转向系统（EPS）的概念阶段实践
为了更直观地理解概念阶段的位置与接口关系，我们以一款电动助力转向系统（EPS）为例进行拆解。该系统由扭矩传感器、电子控制单元（ECU）、无刷直流电机（BLDC）和减速机构组成。
背景与约束：该EPS系统需满足ISO 26262 ASIL D等级要求，整车厂要求系统在转向助力失效时，仍能保持机械转向的基本功能，且驾驶员必须能通过仪表盘故障灯获知助力失效。
初始现象与目标：在概念阶段，安全团队首先基于相关项定义进行HARA。识别出关键危害事件为“车辆行驶过程中转向助力突然丧失”，该事件在高速工况下可能导致车辆失控。通过ASIL评级，确定该危害事件对应的安全目标SG1为“避免转向助力在行驶过程中完全丧失”，ASIL D，安全状态为“机械转向可用，且点亮故障灯”。
关键输入数据：相关项定义中明确了EPS的工作电压范围（9V-16V）、工作温度（-40℃至85℃）以及转向柱的机械限位。HARA分析中考虑了驾驶员模型（5%至95%百分位）和路面附着系数（0.1至0.9）。
分析判断过程：基于SG1，团队定义了三条功能安全概念需求：FSC1：当检测到电机相电流异常时，应在50ms内切断电机驱动信号，并激活机械转向模式；FSC2：当检测到扭矩传感器信号失效时，应使用电机位置传感器信号进行冗余计算，并限制助力输出至50%；FSC3：当系统进入安全状态时，应通过CAN总线发送故障码，并点亮仪表盘故障灯。
实际操作步骤：系统阶段根据FSC1，将ASIL D分解为：硬件负责电机驱动电路（ASIL C(D)），软件负责故障诊断逻辑（ASIL C(D)）。硬件阶段据此设计了双路MOSFET驱动电路和电流采样电路；软件阶段设计了基于RTOS的高优先级诊断任务，确保50ms的响应时间。
结果对比与复盘：在后续的集成测试中，发现当电机相电流采样受到电磁干扰时，诊断任务可能误触发，导致频繁进入机械转向模式。通过回溯，发现概念阶段的FSC1中未定义“故障确认时间”和“去抖策略”。团队不得不修订FSC，增加“连续3次采样超限且持续10ms才确认故障”的需求。这一案例说明，概念阶段的输出必须足够精确，否则下游阶段的设计将缺乏鲁棒性。