汽车功能安全系统阶段开发【技术安全方案TSC以及安全分析】5

1 技术安全方案 (Technical Safety Concept - TSC)

• 技术安全方案 (Technical Safety Concept - TSC)

  • 是什么： TSRs 在更高层次技术实现上的顶层设计方案，属于系统阶段围绕TSR开发的工作内容汇总，形成的系统化工作输出结果。它描述了如何通过技术手段（硬件、软件、系统结构）来满足TSRs。TSC 是系统安全架构设计的主要输入之一。如下图：
    

  • 核心：

    • 识别和定义所需的关键安全机制（SM）。
    • 描述这些安全机制在系统层面如何协同工作以实现安全目标。
    • 描述系统元素（硬件、软件模块、外部设备）之间为确保安全所需进行的交互。
    • 初步考虑故障检测、处理流程和安全状态实现路径。
    • 目标： 将分散的TSRs 整合为一个连贯的、技术可行的实现蓝图。

  • 特点：

    • 比TSR更抽象（尚未细化到具体硬件选型或软件实现）。
    • 侧重于技术策略和逻辑关系。
    • 定义了系统层面的安全行为逻辑。

  • 示例：

2 系统安全架构设计 (System Safety Architecture Design)

• 系统安全架构设计 (System Safety Architecture Design)

  • 是什么： 基于TSC，定义系统的物理或逻辑结构，明确各组件/元素及其接口，并分配功能和安全要求（包括TSRs）到这些元素。它是系统设计蓝图，特别关注满足安全要求所需的架构特性。

  • 关键活动：

    • 分解系统： 识别系统的逻辑和/或物理元素（ECUs、传感器、执行器、软件分区、硬件模块）。
    • 定义接口： 明确定义元素之间的交互接口（信号、协议、时序要求），包括安全相关信息的传输。
    • 分配安全要求： 将TSC中定义的策略和TSRs 细化并分配到具体的系统元素和接口上。
    • 实现安全机制： 设计架构以支持TSC中定义的安全机制（如冗余通道、监控单元、分区隔离）。
    • 实现： 定义满足非功能性TSRs（如FTTI, DC）的架构手段（如通信速率、硬件选择、软件调度）。
    • 独立性/隔离： 确保关键元素或冗余通道在故障传播上具有足够的独立性（空间/时间/因果）。
    • 要素定义： 明确每个元素的内部和外部功能、接口要求、资源需求。

  • 目标： 创建一个能够有效实施TSC、满足所有安全需求且可行的系统结构。

  • 示例：
    

  • 说明： 这个简化的架构展示了制动相关元素：主制动ECU (BCU)、轮速传感器、电子手刹ECU (EPB)、监控ECU (MON) 和CAN总线。架构体现了：

    • 传感器输入到BCU。
    • BCU包含主控制逻辑和安全逻辑分区（实施TSC中的双通道策略）。
    • 监控单元独立监控BCU和EPB的活动（看门狗），并检查总线数据完整性（CRC）。
    • CAN总线用于通信。
    • 安全状态指示通过仪表盘实现。

3 如何进行安全分析 (Safety Analysis)

安全分析贯穿ISO 26262开发流程的各个阶段，是识别危害、定义安全目标和验证设计方案的核心手段。主要方法：

1. 危害分析和风险评估 (Hazard Analysis and Risk Assessment - HARA):

   • 目的： 识别由系统故障行为引起的潜在危害场景，并为每个危害场景确定汽车安全完整性等级 (ASIL)。
   • 输入： 功能描述、运行场景。
   • 输出： 危害事件清单、安全目标 (Safety Goals - SGs) 及其ASIL等级。
   • 方法： 头脑风暴、场景分析、FMEA/FTA启发。

2. 故障树分析 (Fault Tree Analysis - FTA):

   • 目的： 自顶向下 分析特定顶层事件（通常是违反安全目标）发生的根本原因组合。量化分析（可选）。
   • 输入： 安全目标、高层系统架构。
   • 输出： 导致顶层事件的逻辑组合路径（最小割集）、识别系统薄弱点。
   • 作用：
     • 支持安全目标定义和ASIL分解。
     • 验证架构设计（展示设计是否能阻止故障传播）。
     • 确认安全机制的有效性。
   • 流程图： FTA本身是树状图，不易用线性流程图表达逻辑。可理解为：
     • 顶事件： 违反SG（如“非预期急加速”）。
     • 中间事件： 导致顶事件的组合逻辑（AND/OR门连接）。
     • 底事件： 基本故障（传感器失效、软件bug、通信丢失）。
       

3. 失效模式与影响分析 (Failure Mode and Effects Analysis - FMEA):

   • 目的： 自底向上 系统地识别组件（零件、软件模块、接口）的所有潜在失效模式 (Failure Mode) ，分析其本地影响、对上级元素的影响，以及最终对系统或车辆层面的影响（是否能违反安全目标）。
   • 输入： 详细的设计信息（组件规格、接口定义）。
   • 输出： 失效模式列表及其影响、严重性等级、检测方法、改进措施（通常是安全机制）。
   • 作用：
     • 识别单点故障和潜在多点故障。
     • 推导出对安全机制的需求（特别是检测措施）。
     • 支持设计改进，提高鲁棒性。
   • 流程图(简化过程)：

4. 相关性失效分析 (Dependent Failure Analysis - DFA):
   • 目的： 识别可能导致冗余或多样性安全机制同时失效的共同原因 (Common Cause) 或级联失效 (Cascading Failures) 。
   • 类型：
     • 共因失效 (CCF): 由同一个根本原因导致多个元素同时失效（如电压浪涌损坏多个芯片）。
     • 级联失效： 一个元素的失效引发另一个元素的失效（如某模块崩溃导致共享内存损坏）。
   • 作用： 确保安全机制之间以及安全机制与被监控元素之间具有足够的独立性。评估FTA/FMEA中可能遗漏的共同失效场景。
   • 方法： 特定方法（如CCFA - Common Cause Failure Analysis），检查表（分析空间隔离、时间隔离、设计多样性、环境应力等）。

总结安全分析的关系： HARA定义顶层目标和风险等级；FTA和FMEA互为补充，分别从顶向下和自底向上识别设计中的故障弱点，并指导安全机制的设置和验证；DFA则专门应对安全机制本身可靠性的关键问题（独立性）。它们共同确保系统设计能满足安全目标。

4 技术安全需求 (TSR) 如何分配到系统架构

这是系统安全架构设计的核心活动之一。目标是清晰、无歧义地将TSRs落实到具体的系统元素上，确保每个元素的职责明确，并最终能追溯回安全目标。

1. 分配流程：

2. 关键步骤详解：

   • 理解TSC和TSRs： 深刻理解技术安全方案中定义的安全策略以及每条TSR的具体内容和意图（功能性、诊断覆盖率、FTTI、安全状态等）。
   • 分析架构元素： 仔细审视系统架构草案（如ECU框图、软件模块划分、总线网络拓扑）。
   • 映射策略到元素：
     • 识别责任归属： 对于TSC中定义的每个安全策略或安全机制，确定由哪个（或哪几个）系统元素主要负责实现（Implement）和/或执行（Execute）。哪个元素负责检测到故障后触发进入安全状态？哪个元素负责监控？哪个元素负责执行降级操作？
       • 示例（双通道转向控制策略）:
         • 主通道逻辑实现 -> 主ECU软件模块A
         • 冗余通道逻辑实现 -> 主ECU软件模块B (或在独立冗余ECU上)
         • 通道比较监控 -> 主ECU内安全监控模块C (或独立监控ECU)
         • 输出驱动 & 检测到不一致时限制输出 -> 主ECU驱动模块D
     • 分配TSRs： 将与该策略/机制直接相关的TSRs 分配或细化后分配到对应的元素上。
       • 示例：
         • TSR-DC1 (通道比较诊断覆盖率≥99%) -> 分配给负责实现比较功能的模块C (细化：模块C需要能够比较A和B的输出结果，并能在XX时间内检测到YY范围内的差异）。
         • TSR-T1 (主通道失效切换时间≤50ms) -> 分配给模块C (需在X ms内检测到异常) + 模块D (需在Y ms内执行切换和限制逻辑，且X+Y ≤ 50ms)。
   • 定义接口需求： 为了实现元素间协作执行安全功能（如传递监控结果、触发安全状态、同步冗余数据），必须在元素接口规范中明确定义安全相关的要求：
     • 需要交换哪些安全相关的信号/数据？
     • 传输这些信号的协议是什么？（如AUTOSAR COM、带有CRC/Counter的PDU）
     • 时序要求（最大延迟、超时）？
     • 数据的新鲜度/有效性如何保证？（如时效管理）
     • 错误检测机制？（如校验和、信号范围检查）。
     • 示例：
       • 主ECU模块A和模块B向模块C发送计算结果数据，接口定义：
         • 需包含CRC校验（满足可靠性要求）。
         • 最大传输延迟 ≤ 5ms（满足总体FTTI要求的一部分）。
         • 数据需带时间戳或序号（满足新鲜度要求）。
       • 模块C检测到不一致需要通知模块D，接口定义：
         • 高优先级中断信号或专用快速通信通道。
         • 传输延迟≤ 1ms。
   • 细化TSRs： 系统级的TSRs通常比较抽象。分配到元素时需要将其细化（Decompose） 为该元素级别的、更具体、可验证的要求。
     • 系统级TSR： 整个制动系统的非预期制动响应FTTI ≤ 150ms。
     • 细化分配到元素级：
       • 传感器失效检测时间（TSR-Sensor-Detect） ≤ 50ms
       • 信号处理延迟（TSR-ECU-Process） ≤ 30ms
       • 安全状态激活延迟（TSR-ECU-Actuate） ≤ 30ms
       • CAN通信延迟（TSR-CAN-Delay） ≤ 40ms （用于监控/响应信息传递）
       • 验证