汽车功能安全概念阶段开发【功能安全需求及方案（FSRFSC）】3

1 核心概念

1.1 安全目标 (Safety Goal - SG)

1. 安全目标 (Safety Goal - SG): 这是功能安全的顶层要求。它定义了系统 必须避免 的特定危险状况，并规定了相关的安全状态。SG 通常来源于危害分析和风险评估（HARA），并分配有 ASIL 等级 (Automotive Safety Integrity Level)。
   • 例子： 车辆在驾驶员未踩油门踏板时，应避免发生非预期的加速（ASIL D）。 (Safety State： 车辆进入跛行模式，限制扭矩输出)
   • 通俗理解： SG 是最高级别的“红灯”，告诉我们绝对不能让哪种危险情况发生，以及万一不行，系统该进入什么“应急状态”。

1.2 功能安全需求 (Functional Safety Requirement - FSR)

2. 功能安全需求 (Functional Safety Requirement - FSR): 这是将安全目标转化为具体的、可验证的系统级需求（针对每个SG，应该至少导出一个FSR）。FSR 描述了系统在功能层面为了实现 SG 必须做什么 或 不能做什么。FSR本质是需求，一般是主机厂对供应商提出的安全要求，只考虑为满足安全目标及ASIL等级，系统应该怎么正常工作，不涉及具体的技术实现方式。
   • 关键点：
     • 来源于 SG。
     • 定义了系统需要实现的“安全功能”。
     • 通常是技术无关的（描述 功能，不指定 实现）。
     • 可以包括：故障检测机制、容错机制、安全状态定义及进入路径、降级模式、报警/指示、时间约束等。
     • 也带有 ASIL 等级（继承或分解自 SG）。
   • 例子 (从上述 SG 导出)：
     • FSR1： 系统必须在 100ms 内检测到油门踏板位置传感器信号的丢失或卡滞（ASIL D）。
     • FSR2： 系统必须在检测到油门踏板位置传感器故障后 150ms 内，将发动机/电机输出扭矩限制到最大扭矩的 10% 以下（安全状态）（ASIL D）。
     • FSR3： 系统在激活安全状态时，应向仪表盘发送“跛行模式激活”警示信息（ASIL QM）。

1.3 功能安全需求需要解决的关键问题

在功能安全工程中，系统层面的功能安全需求是将顶层安全目标转化为可设计、可验证、可追溯的具体技术要求。它们直接指导系统的架构设计和安全机制实现，确保安全目标能够落地。这些需求必须精确定义系统在安全方面的"必须做什么"、“绝不能做什么"以及"必须如何检测和响应故障”。
以下是定义系统层面功能安全需求需要解决的关键问题以及主要考虑的方面：

1. 安全目标的具体实现方式
   • 解决的问题： 如何将抽象的安全目标转化为具体的系统级功能安全需求？
   • 需求方面：
     • 安全功能： 明确定义为实现安全目标必须执行的安全行动。
       • 例如： 检测到碰撞传感器故障时，必须在 X ms 内向制动控制单元发送“进入安全状态”的指令。 当主处理器超时未响应时，必须在 Y ms 内激活备份处理器并接管控制。
     • 安全约束： 明确定义系统绝不能执行的、可能导致危险的动作或在特定危险状态下允许的操作限制。
       • 例如： 在动力电池单体电压超过 Z V 时，禁止启动驱动电机。 系统处于降级模式时，最高车速不得超过 50 km/h。
     • 功能降级策略： 定义当检测到故障但又无法实现最理想安全状态（如完全关闭）时，系统如何以可控方式限制功能运行以维持可接受的安全水平（Limp-home mode）。
       • 例如： 当主电机控制器故障时，系统应限制输出扭矩至最大值的 30%，并点亮故障指示灯，允许驾驶员低速行驶至维修点。
     • 进入安全状态的策略和条件： 精确定义系统在各种故障场景下应进入哪种预先定义的安全状态（如关闭、重启、进入低功耗模式等），以及在什么条件下（检测到哪些具体故障）触发进入安全状态。
       • 例如： 检测到转向扭矩传感器信号不合理时，应在 Z ms 内进入“助力降级”模式，保留基础转向功能但移除助力。

2. 故障检测与响应

• 解决的问题： 系统如何发现自身或部件的失效？发现后应该做什么？需要在多快时间内完成？
• 需求方面：
  • 故障检测机制： 要求实现特定的方法或技术来检测硬件随机失效、系统性失效以及通信失效。
    • 例如： 必须实现周期性自检（周期 T）以诊断微控制器内核逻辑故障。 必须对来自传感器的信号进行范围检查（合理区间）和合理性检查（与其他信号一致性）。
  • 故障诊断覆盖率： 对关键安全功能相关的元件，需要规定其故障检测机制要达到的诊断覆盖率。
    • 例如： 用于安全关断的动力开关，其开路和短路故障的诊断覆盖率必须达到 DC ≥ 90%。
  • 故障响应时间： 明确规定从检测到潜在危险故障到执行所需安全动作（如进入安全状态）的最大允许时间。
    • 例如： 检测到电池热失控征兆后，必须在 ≤ 100ms 内断开主继电器并激活电池包内的灭火装置。
  • 故障指示/通知： 定义系统如何将诊断出的故障信息可靠地通知给操作员、维护人员或其他系统（如更高层级控制器或云平台）。
    • 例如： 所有检测到的 ASIL D 级故障必须在诊断确认后 ≤ 1s 内通过专用安全总线上报给中央网关，并在仪表盘上点亮红色警告灯。

3. 冗余与独立性

• 解决的问题： 如何确保即使部分系统失效，安全功能仍然可靠？
• 需求方面：
  • 冗余要求： 明确规定哪些功能或通道需要冗余设计（硬件冗余、软件冗余、信息冗余等）。
    • 例如： 转向角度测量必须由两个独立的传感器实现，并安装在不同位置以规避共因故障。
  • 独立性要求： 精确定义需要冗余的组件或子系统之间的独立性级别（物理隔离、空间隔离、电气隔离、不同技术原理等），确保单点故障不会同时影响冗余部分。
    • 例如： 安全控制单元的主、辅处理器必须采用独立的电源供电，并位于不同电路板上。
  • 安全机制的触发和执行独立性： 确保检测故障的机制和执行安全响应的机制也具有足够的独立性，避免共因失效。
    • 例如： 独立于主控制回路的看门狗定时器必须在主程序失效时触发硬件复位电路。

4. 功能安全相关的时间特性

• 解决的问题： 系统对安全事件的响应有多快？关键操作的时序是怎样的？
• 需求方面：
  • 时序约束： 定义安全功能的执行必须满足的最差情况时间限制（循环周期、响应延迟等）。
    • 例如： 碰撞预警信号的处理与决策环路必须在 ≤ 10ms 内完成。
  • 同步要求： 如果冗余通道需要同步决策或动作，需要明确定义同步的机制和可允许的漂移量。
    • 例如： 两个用于安全刹车的控制单元间的心跳信号同步误差必须 ≤ 5ms。

5. 相关项的外部接口

• 解决的问题： 系统如何与其他系统（可能由其他供应商提供或不同安全完整性等级）安全地交互？
• 需求方面：
  • 输入安全约束： 定义系统从外部接收的、用于安全功能的数据必须满足的条件（范围、有效性、时效性）。
    • 例如： 来自 ADAS 摄像头的目标物速度信息用于自动紧急制动时，其传输延迟必须 ≤ 50ms，且附带有效性和完整性校验码。
  • 输出安全约束： 定义系统发送给外部设备的、可能影响安全的指令或数据的约束条件。
    • 例如： 系统发送给引擎管理单元的“扭矩限制”指令信号必须具有硬件级的冗余路径和错误检测（如 CRC）。
  • 接口故障处理： 定义当检测到外部接口故障（如超时、数据错误、物理层故障）时，系统应采取的应对措施。
    • 例如： 若与稳定控制单元的通信丢失持续 ≥ 500ms，系统应进入制动功能受限模式，并仅提供基础机械制动。

6. 实现安全架构的要求

• 解决的问题： 系统架构层面需要满足哪些基本安全原则？
• 需求方面：
  • 免于干扰： 明确要求系统中的安全相关功能和非安全相关功能之间必须有防护措施（例如内存分区、时间分区、硬件防火墙），确保非安全功能或低安全等级功能不会错误地影响或干扰高安全等级功能的运行。
    • 例如： ASIL D 的制动控制软件分区和非关键的媒体播放器软件分区必须使用硬件内存管理单元进行隔离，且媒体播放器软件不能访问控制单元的关键内存区域。
  • 避免共因失效： 提出设计措施要求，以最小化由单一原因（如电压骤降、电磁干扰、特定软件错误、常见维护错误等）导致多个组件同时失效的可能性。
    • 例如： 安全冗余通道必须使用不同型号的微处理器和来自不同供应商的编译器。 关键电源输入必须配备瞬态电压抑制器。
  • 简化设计： 鼓励和要求在安全相关部分尽可能使用简单、成熟、易于理解和验证的设计。复杂度本身就是安全性的敌人。

7. 安全状态定义

• 解决的问题： 当故障发生时，什么是可接受且可控的风险状态？
• 需求方面：
  • 明确定义的安全状态： 精确描述不同故障场景下，系统应达到的一个或多个安全状态及其特征（例如能量消耗量、操作能力范围）。避免含糊不清的表述。
    • 例如： 定义安全状态 S1：动力电池主继电器断开，驱动电机控制器断电，动力转向维持基础助力水平(受限)，仪表盘显示“安全故障-请停车”。
  • 维持安全状态： 要求系统在进入安全状态后，能够稳定维持该状态，并确保后续不会因该故障或系统行为而自发退出或恶化（除非经过安全控制确认恢复）。

8. 总结 - 功能安全需求的核心任务

系统层面功能安全需求的核心任务是： 将抽象的“避免危害”目标，分解细化为可工程实施的、无歧义的、可验证的技术指令，解决“做什么、不做什么、如何防、如何测、多快做”等关键问题，并要求在系统架构和设计中融入安全保障基础（独立性、免干扰、故障控制）。它们是设计安全可靠系统的基石。

记住： 好的功能安全需求需要满足SMART原则：具体、可测量、可实现、相关、时限性。 它们应能清晰地向下分配到硬件和软件，并向上追溯到安全目标。严格定义这些需求并进行有效的验证与确认，是达到功能安全目标的根本保障。

1.4 功能安全方案 (Functional Safety Concept - FSC)

功能安全方案 (Functional Safety Concept - FSC): FSC本质上是概念阶段所有开发工作进行系统化汇总后形成的工作输出产物。
ISO 26262 对FSC定义比较模糊，即为了满足安全目标，FSC包括安全措施(含安全机制)。
那到底什么是安全措施(Safety measure)呢? 它和安全机制(Safety mechanism)有什么区别：

• 1. 安全措施：事前预防+事后补救，较为广泛，一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称。
• 2. 安全机制：事后补救部分，只是安全措施的一部分，针对系统功能出现异常后，为探测，显示，控制故障的所采取的措施。一般涉及具体技术手段，在概念阶段不做具体要求，在系统阶段进行定义。
     所以理论上讲，只要是为保证相关项功能安全，所有在功能层面采取的解决方案都属于功能安全方案。一般来讲，一个完整的FSC应该包含以下主要内容:
     
     其中，安全状态主要包括: 关闭功能，功能降级，安全运行模式，Limp Home等Fail to safe策略，目前Fail to operational，如冗余运行等策略相对较少。
     系统一旦违反安全目标，安全机制必须在**容错时间间隔(FTTI)**将系统转移到安全状态。
     怎么确定故障容错时间间隔(FTTI)：
     一般可以根据安全目标所对应的代表性危害事件(一般是ASIL等级最高的危害事件)，通过对应运行场景定量或定性评估得到，包括历史数据，仿真计算，实际测试等。
     在实际操作中，如果难以计算确定，可以根据经验对其进行预设，然后对代表性危害事件进行实车运行场景模拟，最后根据测试数据和安全确认指标(Validation criteria)确定假设合理性。
     对于ASIL等级较高的安全需求，理论上都应该进行车辆测试确认。
     FSR和FSC形式和书写工具问题：
     首先，FSR一般都是直接包含在FSC之中，多采用需求管理或者文本工具，如Doors，Word进行书写和管理，方便进行版本管理和评审。
     其次，FSC内容没有统一的结构要求，将所需内容合理组织形成输出结果且保证分析结果可追溯性即可。

2 流程详解：从 SG -> FSR -> FSC -> 分配到系统架构

2.1 从安全目标 (SG) 导出功能安全需求 (FSR)

1. 从安全目标 (SG) 导出功能安全需求 (FSR):

   • 方法： 通过系统性地考虑所有可能导致违反 SG 的故障模式（故障失效分析 - FMEA/FTA 有助于此过程），以及系统需要如何检测、处理和响应这些故障。
   • 关键问题：
     • 如何检测 可能导致危险状况的故障？（故障检测机制需求）
     • 检测到故障后，系统 必须做什么？（进入安全状态、降级、报警 - 故障响应需求）
     • 进入安全状态/降级模式需要 多长时间？（时间约束需求）
     • 系统在故障条件下应该处于什么状态？（安全状态定义）
     • 需要 哪些信息 来支持故障决策？（输入数据验证需求）
     • 如何确保故障检测和响应机制 自身可靠？（监控或诊断的可靠性和覆盖需求）
   • 流程示意 :
   • 汽车行业实例 (电子助力转向系统 - EPS):
     • SG: 避免在驾驶员未输入转向意图时发生非预期的转向助力（ASIL D）。(Safety State: 关闭助力或提供极小恒定助力)
     • 导出的 FSRs (部分示例):
       • FSR1: 系统必须在 50ms 内检测到方向盘扭矩传感器的信号故障（短路、开路、超范围）（ASIL D）。
       • FSR2: 系统必须在检测到方向盘扭矩传感器故障后 100ms 内，将助力电流降为零或维持在一个预定义的极低安全电流水平（ASIL D）。
       • FSR3: 系统必须使用独立的硬件通道（如监控MCU）或高覆盖率的软件自检算法监控主控制通道（主MCU）的活性和执行正确性（ASIL D）。
       • FSR4: 系统在发生影响助力功能的故障进入安全状态时，应向驾驶员仪表盘发送“转向助力失效”信息（ASIL QM）。

2.2 定义功能安全方案 (FSC)

2. 定义功能安全方案 (FSC):

   • 输入： FSRs。
   • 方法： 设计一个功能性的架构概念，明确定义：
     • 实现每个 FSR 需要哪些功能块 (Functional Blocks)。
     • 功能块之间的职责划分 (哪个块负责检测、哪个负责决策、哪个负责执行)。
     • 功能块之间的交互逻辑和信息流（接口规范）。
     • 用于实现 FSR 的安全机制 (例如：输入信号范围检查、合理性检查、数据校验、冗余比较、软件程序流监控、硬件看门狗)。
     • 故障处理策略和状态机（正常模式、降级模式、安全状态之间的转换条件）。
   • 流程示意:
   • 汽车行业实例 (续 EPS):
     • FSC: 双通道监控架构。
       • 功能块 A (主通道): 主MCU（主控制单元）：执行正常的转向控制算法，从方向盘扭矩传感器读取信号（经过基本范围检查）。
       • 功能块 B (诊断监控通道): 监控MCU（或主MCU内的独立分区/核心）：持续监控主扭矩传感器信号的范围、变化率合理性（与车辆速度关系）、与转角传感器信号的逻辑一致性（驾驶员意图）。执行对主MCU应用软件任务执行时序的监控（通过程序流监控）或控制硬件看门狗。
       • 功能块 C (安全机制管理器): 通常集成在监控MCU或主MCU的安全逻辑中。接收来自功能块B的故障指示。根据故障类型和FSR要求，决定是否触发安全状态（关闭助力），并发送相应的安全指令给功能块D。管理系统状态（正常 -> 降级/安全状态）。
       • 功能块 D (执行器控制)： 电机驱动电路。接收来自主通道的正常指令或安全机制管理器的安全指令（限流/关闭指令）。
       • 功能块 E (HMI): 仪表盘控制单元。接收来自安全机制管理器的故障消息并显示。
       • 接口： 定义传感器信号线、监控通道到管理器的信号线、管理器到电机驱动的信号线、管理器到HMI的信号线、看门狗喂狗线等所需的电气/通信特性和协议。
       • 安全机制： 扭矩信号范围检查、信号变化率检查、扭矩-转角一致性检查、主MCU软件程序流监控（程序序列监控）、硬件看门狗。

3. 将 FSC 分配到系统架构 (Technical Architecture Allocation):

   • 输入： FSC（已定义的功能块和需求）。
   • 目标： 将 FSC 中定义的概念性功能块映射到系统实际的技术组件上（硬件和软件元素）。
   • 步骤:
     1. 架构设计： 设计详细的系统架构（硬件图、软件框图、网络拓扑）。
     2. 映射： 将 FSC 中的每个功能块及其职责、安全机制具体分配给：
        • 硬件组件（项）： 特定ECU、传感器、执行器、专用硬件模块（如ASIC、监控IC）。
        • 软件组件（项）： 具体软件模块、任务、驱动程序、操作系统服务。
        • 接口： 将概念接口映射到具体的物理或逻辑接口（如 CAN ID, LIN ID, SPI信号线, 内存共享区地址）。
     3. 需求分解: FSRs 和 FSC 中定义的需求需要被进一步细化为针对具体硬件和软件组件的技术安全需求 (Technical Safety Requirement - TSR)。这些 TSR 包含了具体的电气特性、时序约束、诊断覆盖率目标、编码要求、测试要求等。
     4. 依赖性分析： 分析技术组件的相互依赖关系（特别是共享资源）。
     5. 独立性检查 (ISO 26262 Part 9): 对于高ASIL (C, D)需求，尤其当单个组件无法满足其ASIL时，需要检查分配给不同组件的安全机制的独立性（如不同ECU，不同电源域，分区隔离），以确保共因故障不会同时影响多个冗余路径。常用方法包括故障模式与影响分析（FMEA）、故障树分析（FTA）和共因故障分析（CCA）。
   • 流程示意:

通俗比喻：

• SG (Safety Goal): 开车出门的核心目标——绝对不能让车自己突然加速撞墙！
• FSR (Functional Safety Requirement): 为了达到“不撞墙”这个大目标，汽车工程师定下的详细规矩：1)必须时刻检查油门踏板有没有发疯乱报数据；2)万一踏板疯了，得在极短时间内把车速压到基本不动才算安全；3)万一车被限速了，记得亮灯告诉司机。
• FSC (Functional Safety Concept) : 工程师设计的“防疯踏板”实施方案草图：装两个独立系统，一个负责正常开车（A系统），一个负责出现故障时启动（B系统）。