ISO 26262 Part 4 系统阶段：技术安全概念（TSC）深度解析——从功能需求到技术落地

---

目录

1. 引言：为什么 TSC 是功能安全从概念到实现的关键一跳
2. 标准理解：TSC 与系统架构的条款要求
3. 工程实现方法：TSR 导出与架构迭代
4. 具体案例：动力电池系统 TSC 开发
5. 总结与关键要点

---

1. 引言：为什么 TSC 是功能安全从概念到实现的关键一跳

在 ISO 26262 的 V 模型中，概念阶段（Part 3）完成了三件事：定义 Item（相关项定义）、分析风险并导出安全目标（HARA）、将安全目标分解为功能安全需求（FSC）。FSC 的产出物——功能安全需求（FSR）——描述的是 Item 层面的安全行为，例如"动力电池系统在检测到单体过压时，应在 FTTI 内断开充电回路进入安全状态"。

但 FSR 到可实现的技术方案之间还有关键的一层——技术安全概念（TSC）。TSC 位于 Part 4 系统阶段，承接 FSC，需要完成以下核心工作：

TSC 的核心工作	从 FSR 继承什么	TSC 需要新增/细化什么
TSR 导出	FSR 的功能行为和 FTTI 总预算	将 FTTI 分解为 FDTI + FRTI，明确到系统架构中哪个组件在检测到什么故障/信号后、在多长时间内执行什么操作
系统架构设计	FSR 不涉及内部架构	定义系统内部所有要素（传感器/控制器/执行器/通信/电源），展示要素间的交互关系和接口
安全分析	FSR 的安全目标	通过 FMEA/FTA/DFA 验证架构和 TSR 的完整性，发现遗漏的失效模式，补充诊断类 TSR
ASIL 继承与分解	FSR 的 ASIL 等级	系统要素继承其实现 TSR 的最高 ASIL；ASIL 分解需 DFA 验证独立性
HSI 定义	无	定义硬件-软件接口的顶层规范，为 Part 5/6 提供输入

在 ISO 26262 V 模型中，TSC 位于 Part 4 系统阶段，承接 FSC，产出 TSR（技术安全需求）。TSC 和系统架构设计是迭代推进的——TSR 的导出需要架构支撑，架构设计需要 TSR 分配，安全分析发现问题后反过来修正 TSR 和架构，三者形成迭代闭环：

层级	需求类型	标准条款	描述内容	示例
Part 3 FSC	FSR	ISO 26262-3 Clause 7	功能行为——Item 级安全行为描述，动力电池系统检测到故障后应在 FTTI 内进入安全状态，或避免输出/执行不当操作	“动力电池系统在检测到单体电压超过充电截止阈值时，应在 FTTI 内断开充电回路进入安全状态”
Part 4 TSC	TSR	ISO 26262-4 Clause 6	系统级技术需求——系统架构中具体组件在检测到具体故障/信号持续 FDTI 后，在 FRTI 内执行具体操作	“BCU 在接收到 CMU 上报的过压信号持续 FDTI ≤ 2s 确认为故障后，应在 FRTI ≤ 200ms 内断开主正接触器并进入安全状态”

---

2. 标准理解：TSC 与系统架构的条款要求

2.1 Part 4 的整体结构

ISO 26262-4:2018 涵盖系统阶段的全部活动：

条款	主题	核心内容
Clause 5	系统级产品开发启动	启动系统开发、确认输入完整性
Clause 6	技术安全需求规范	导出 TSR、定义 TSC、HSI 定义、系统架构设计
Clause 7	系统集成与测试	Item 集成、集成测试
Clause 8	安全验证	验证安全目标达成
Clause 9	功能安全评估	评估安全措施充分性

2.2 TSC 的定义

ISO 26262-1:2018 对 Technical Safety Concept 的定义：

“specification of how the functional safety requirements are implemented by the system”

即：系统如何实现功能安全需求的规范。

TSC 的核心产出物是技术安全需求（TSR）和系统架构设计。TSR 将 FSR 的功能描述转化为系统级技术需求，但不下沉到硬件参数或软件算法级别。

2.3 TSC 与系统架构的迭代流程

ISO 26262-4:2018 明确要求 TSC 和系统架构设计是迭代推进的：

• 技术安全需求和系统架构设计迭代开发
• 架构建立后，TSR 分配到系统要素并细化
• 架构衍生的新需求（包括 HSI）添加到 TSR 中
• 安全分析验证架构和 TSR 的完整性，发现问题后迭代修正

2.4 TSR 的来源

TSR 不是只从一个地方来的。标准要求 TSR 综合以下来源：

来源	贡献内容	示例
FSR（主要来源）	FSR 的技术实现需求，ASIL 从 FSR 继承	FSR：“动力电池系统在检测到单体过压时，应在 FTTI 内断开充电回路” → TSR：“BCU 在接收到 CMU 上报的过压信号持续 FDTI ≤ 2s 确认为故障后，应在 FRTI ≤ 200ms 内断开主正接触器”
系统架构设计	架构衍生需求——架构选型带来的约束和接口需求	“采用双通道冗余架构” → “两条通道应独立运行”
安全分析结果	FMEA/FTA 发现的失效模式需要对应的安全机制	“FMEA 发现 AFE 基准电压漂移” → “BCU 应周期性执行 AFE 基准校准，校准异常持续 FDTI 内标记故障”
HSI 需求	硬件-软件接口约束	“ADC 共享需定义优先级” → “安全采样优先于非安全采样”
非安全相关约束	非安全需求对安全功能的影响	"通信周期 10ms"约束安全检测的响应时间

⚠️ 关键纠正

• TSR 不仅仅来自 FSR 继承——架构衍生需求和 HSI 需求也是重要来源
• TSR 不仅仅来自安全分析——安全分析是验证和补充，不是唯一来源
• FSR 是主要来源，架构和安全分析是补充来源，三者共同构成完整的 TSR

2.5 安全分析的具体内容：系统阶段 FMEA/FTA/DFA 分析什么

安全分析在系统阶段（Part 4）的核心目的是：验证初步架构和 TSR 的完整性，发现遗漏的失效模式，导出补充的 TSR。三种分析方法各有侧重：

FMEA（故障模式与影响分析）——归纳法，自底向上

系统级 FMEA 在系统要素级别执行，分析流程：

步骤	分析内容	示例（动力电池系统）
1. 确定分析要素	系统架构中的每个功能块/要素	BCU 主控、CMU 从控、菊花链通信、接触器、电流传感器、12V 电源
2. 识别失效模式	每个要素可能怎样失效	传感器供电失效、信号卡死/漂移、继电器驱动电源失效、通信数据损坏、存储器位翻转、继电器粘连
3. 分析失效影响	失效对系统功能和安全目标的影响	供电失效 → 电压采集异常 → 过压无法检测 → 安全目标 SG-01 被违反
4. 评估现有安全机制	已有 TSR 是否覆盖该失效模式	已有 TSR-A01 监控传感器供电？如果没有 → 需新增
5. 评估诊断覆盖率	安全机制对该失效模式的检测能力	部分覆盖 / 完全覆盖 / 无覆盖
6. 故障分类	按 ISO 26262-5 分类	安全故障 / 单点故障 / 残余故障 / 多点故障（已检测/已感知/潜伏）

FMEA 导出 TSR 的逻辑：发现失效模式 → 现有 TSR 不覆盖 → 新增故障检测/指示 TSR

FTA（故障树分析）——演绎法，自顶向下

系统级 FTA 从安全目标被违反作为顶事件，向下分解：

步骤	分析内容	示例（SG-01 防止过充）
1. 定义顶事件	安全目标被违反	“电池过充导致热失控”
2. 分解中间事件	通过 AND/OR 门分解	“过压未检测到” OR “检测到但未断开”
3. 识别基本事件	最底层的独立失效	“CMU 电压采集通道全部失效” AND “电流传感器同时失效” = 多点故障
4. 验证安全机制覆盖	顶事件的所有路径是否被安全机制阻断	如果存在未被阻断的路径 → 需补充 TSR
5. 识别组合失效	多个失效同时发生的情况	双通道同时失效的概率是否可接受

FTA 导出 TSR 的逻辑：顶事件路径未被阻断 → 需增加独立检测/反应路径 → 新增 TSR

DFA（相关失效分析）——独立性验证

DFA 在系统阶段验证ASIL 分解通道的独立性：

分析类型	检查内容	示例
共因失效	两个通道是否因同一原因同时失效	CMU 和电流传感器共用 12V 供电 → 共因
级联失效	一个要素的失效是否导致另一个要素失效	BCU 软件死锁 → 监控分区也死锁（共享 RAM）

DFA 导出 TSR 的逻辑：独立性不成立 → 需增加隔离措施 → 新增 TSR 或取消分解回到原始 ASIL

安全分析与 TSR 的关系总结

分析方法	输入	分析内容	产出	对 TSR 的影响
FMEA	系统要素 + 失效模式	失效模式 → 影响 → 覆盖率	补充故障检测/指示 TSR	新增 a)类措施
FTA	安全目标 + 架构	顶事件 → 路径 → 阻断验证	补充独立检测/反应路径 TSR	新增 a)类措施，验证 b)类
DFA	分解方案 + 架构	独立性验证	隔离/独立性 TSR	影响架构决策和 ASIL 分解有效性

安全分析方法（FMEA/FTA/DFA/自由干扰）的详细操作步骤、模板和工具将在后续单独的章节展开。

2.6 TSR 中安全机制的六类措施

ISO 26262-4 Clause 6.4.2.1 要求 TSR 指定必要的安全机制，包括以下六类措施：

措施类别	含义	示例
a) 故障检测、指示和控制	检测系统自身及要素的故障，指示故障并控制故障传播	电压采集链路供电监控、传感器信号合理性检查
b) 达到和维持安全状态	故障后使系统进入并维持安全状态，包括防止故障传播	断开充电继电器使系统进入安全状态
c) 达到和维持降级状态	不能进入安全状态时进入降级/降低风险状态	限制充放电功率、启动最大冷却
d) 驾驶员/操作员指示	向驾驶员/操作员发出警告	仪表盘亮故障灯、发送故障码
e) 外部安全措施	依赖 Item 外部的安全措施	请求 VCU 执行紧急停车
f) 防止潜伏故障	防止故障变为潜伏故障的措施	上电自检、周期性在线诊断

2.7 TSR 中的时间预算：FDTI / FRTI / FHTI

FSC 阶段给出了 FTTI（Fault Tolerant Time Interval）总预算。TSC 阶段将其分解：

参数	定义	谁分配
FTTI	从故障发生到可能进入危险状态的最大时间	FSC 阶段
FDTI	从故障发生到被检测到的时间	TSC 阶段
FRTI	从检测到故障到进入安全状态的时间	TSC 阶段
FHTI	FDTI + FRTI，必须 ≤ FTTI	TSC 阶段验证

注意：FDTI/FRTI 在涉及故障检测和故障反应的 TSR 中是必要的。但对于非时序类的 TSR（如架构分配、HSI 接口定义），不强制要求携带 FDTI/FRTI。

TSR 如何表达时间预算：

TSR 应定义可测量的检测、处理、反应步骤，明确到具体组件的交互时序，并关联 FTTI。以过压保护为例：

FTTI = 3s（来自 FSC）
├── FDTI ≤ 2s（故障检测时间）
│   ├── CMU 采样单体电压并判定是否超过充电截止阈值
│   ├── CMU 通过菊花链周期性上报电压数据/故障标志
│   ├── BCU 接收菊花链数据（通信延迟）
│   └── BCU 过压判定算法确认故障（去抖周期后确认）
├── FRTI ≤ 200ms（故障反应时间）
│   ├── BCU 发出断开主正接触器指令
│   ├── 接触器驱动电路响应
│   └── 主接触器物理断开 + 灭弧
└── FHTI = FDTI + FRTI = 2.2s ≤ FTTI = 3s ✓

TSR 的写法应明确：哪个组件在检测到什么具体故障或信号持续 FDTI 后，在 FRTI 内执行什么具体操作。具体到"采样精度 ±5mV""采样周期 10ms"这些是 HSR/SSR 的细化参数，TSR 只需定义 FDTI/FRTI 的分配和 FHTI ≤ FTTI 的验证。

2.8 系统架构设计

系统架构 vs Item 架构的区别：

维度	Item 定义（Part 3）	系统架构（Part 4）
视角	外部边界视角——定义 Item 边界和与外部的接口	内部实现视角——定义系统内部所有组件
内容	Item 的功能行为、运行模式、与外部 Item 的接口	传感器、控制器、执行器、通信链路、电源
颗粒度	ECU/系统级别	要素级别（传感器、ECU、执行器、总线、电源）
是否画外部 Item	是——需要定义与 VCU/PCS 等的接口	否——只关注系统内部组件

系统架构 vs 硬件架构的区别：

维度	系统架构（Part 4）	硬件架构（Part 5）
内容	要素级别：传感器、ECU、执行器、通信总线、电源	组件级别：ADC 通道、分压电路、驱动芯片型号、引脚
ASIL	继承 TSR 的 ASIL	继承 HSR 的 ASIL，细化到组件
安全分析	FMEA/FTA/DFA 在系统要素级别	FMEDA 在硬件组件级别

系统架构应包含的要素类型：

以主流动力电池系统为例，采用分布式主从架构（BCU + CMU + BDU）：

要素类型	说明	动力电池系统示例
电池模组	能量存储单元	多个电池模组（含电芯）
从控单元（CMU/CSC）	模组级采集单体电压/温度，执行均衡	每个模组配一个 CMU
主控单元（BCU/BMU）	执行安全逻辑、SOC/SOP/SOH 估算、整车通信	BMS 主控制器
菊花链通信	BCU 与多个 CMU 之间的内部通信	菊花链（TI BQ7961x / NXP MC33664）
断开单元（BDU）	高压安全网关：主接触器、预充电路、保险丝、Pyrofuse	BDU（Battery Disconnect Unit）
执行器	执行安全动作的组件	主正/主负接触器、预充继电器、Pyrofuse
传感器	测量物理量的组件	电流传感器、HVIL 互锁回路、绝缘监测
外部通信链路	与外部 Item 的通信	CAN-FD（→ PCS）、CAN（→ VCU）
低压系统	LV 供电和 LV 控制	12V 安全电源 + 电源监测
热管理接口	温度采集和冷却控制	NTC 温度传感器组、冷却控制接口
软件分区	系统级软件分区策略	安全应用分区 + 监控分区

⚠️ 颗粒度原则

系统架构应展示"充分理解系统如何实现 TSR 和安全机制"的细节，但不下沉到硬件组件内部设计。标准要求架构设计应展示：模块化、适当的颗粒度、简单性。

2.9 ASIL 继承与分解

ASIL 不是"分配"的，是"继承"的：

每个系统架构要素继承其实现的所有 TSR 中最高的 ASIL。例如，如果一个要素实现了 ASIL D 的 TSR 和 ASIL B 的 TSR，该要素的 ASIL 为 D。

ASIL 的生命周期：

阶段	ASIL 来源	说明
HARA（Part 3）	S×E×C 评级	安全目标获得 ASIL
FSC（Part 3）	从安全目标继承	FSR 继承安全目标的 ASIL
TSC（Part 4）	从 FSR 继承	TSR 继承 FSR 的 ASIL
架构（Part 4）	从 TSR 继承	系统要素继承其实现 TSR 的最高 ASIL
分解（Part 9）	冗余分解	ASIL D → B(D) + B(D)，需 DFA 证明独立

关键认知：ASIL 从 HARA 一路继承下来，不是在架构阶段"拍脑袋分配"的。架构阶段的任务是确认继承关系和分解有效性。

2.10 软件层面的安全机制

标准条款依据：

软件安全监控在系统阶段和软件阶段的分工，有明确的条款依据：

标准条款	阶段	对安全监控的要求
ISO 26262-4 Clause 6.4.2.1	系统阶段	TSR 应指定安全机制以检测故障并防止或缓解系统输出端的失效——这是系统阶段安全监控的核心条款
ISO 26262-6 Clause 6	软件阶段	从 TSC 和系统架构导出 SSR，定义软件的安全相关功能和属性
ISO 26262-6 Clause 7.4.14	软件阶段	软件架构层面推荐使用外部监控设施和合理性检查来运行时检测和解决错误

系统阶段（Part 4）vs 软件阶段（Part 6）的职责边界：

ISO 26262-4 Clause 6.4.2.1 要求 TSR 指定安全机制来检测故障并防止或缓解系统输出端的失效。这意味着系统阶段需要定义"监控什么"和"采用什么类型的监控策略"，而软件阶段（Part 6 Clause 6）将监控需求细化为 SSR 并设计软件架构实现：

决策内容	系统阶段（Part 4, Clause 6.4.2.1）	软件阶段（Part 6, Clause 6 + 7.4.14）
安全监控需求	定义系统需要监控什么、为什么监控	将监控需求细化为 SSR
安全机制策略	定义采用什么类型的监控（合理性检查、冗余估算等）	设计软件架构实现监控策略（Clause 7.4.14）
ASIL 分配	将 TSR 分配到软件要素，确定 ASIL	继承 ASIL，设计满足 ASIL 的软件
软件分区	决定是否需要软件分区（影响架构）	实现分区（MPU/内存隔离/调度隔离）
HSI	定义 HW-SW 接口顶层规范	细化 HSI 到寄存器级
具体算法	不定义	设计和实现具体算法

⚠️ 标准不强制规定监控类型的固定清单

ISO 26262-4 Clause 6.4.2.1 要求 TSR 指定安全机制检测故障，但不列举具体的监控技术。程序流监控、数据完整性检查、合理性检查、冗余估算等是行业实践中常见的实现方式，属于安全机制的实现手段。监控策略在系统阶段（TSR 层面）确定"需要什么类型的监控"，软件阶段（SSR 层面）实现具体方案。标准不强制某类监控必须在系统阶段还是软件阶段定义——取决于 TSC 的分配和 HSI 规范。

软件安全机制分类（系统阶段确定策略，软件阶段实现）：

类别	软件安全机制	对应措施类别	系统阶段确定（Clause 6.4.2.1）	软件阶段实现（Clause 7.4.14）
程序流监控	看门狗、执行顺序监控	a) 故障检测	监控策略和需求	看门狗配置、程序流设计
数据完整性	RAM ECC 检查、CRC 校验、关键变量冗余	a/f)	需要保护的数据范围	ECC 配置、CRC 算法实现
输入合理性	信号范围检查、变化率检查、多源交叉验证	a)	检查策略（范围/变化率/交叉）	具体阈值和算法
SOX 估算监控	SOC/SOP/SOH 估算结果合理性检查	a)	监控策略（双通道/合理性/范围）	监控算法实现
输出监控	输出回读验证	a)	需要回读的输出清单	回读逻辑实现
周期性诊断	上电自检、在线诊断测试	f)	诊断项目和周期	诊断测试代码实现

2.11 硬件-软件接口（HSI）

HSI 在系统阶段定义顶层接口，在 Part 5/6 细化：

HSI 内容	说明
软件可控的硬件设备	软件通过寄存器控制的硬件外设
支持软件运行的硬件资源	CPU 核心、RAM、Flash、中断控制器
共享与独占资源	安全相关资源独占或共享
硬件特性约束	硬件特有的限制条件

---

3. 工程实现方法：TSR 导出与架构迭代

3.1 第一步：初步系统架构设计

基于 FSC 的 FSR 分配方向，设计系统架构——定义系统内部所有实现组件：

要素类型	需定义的内容	示例（动力电池系统）
电池模组	模组数量、串并联方式	N 个模组，每个 M 串
从控单元（CMU）	数量、采集对象、菊花链接口	每模组一个 CMU，采集单体电压/温度
主控单元（BCU）	选型方向、核心架构、安全特性	双核锁步 MCU 或双 MCU
菊花链通信	协议、拓扑（链式/环式）、隔离	TI BQ7961x 或 NXP MC33664
断开单元（BDU）	接触器配置、预充电路、Pyrofuse	主正/主负接触器 + 预充继电器 + Pyrofuse
电流传感器	类型、安装位置	分流器或霍尔传感器
HVIL 互锁	回路设计、监测策略	低压互锁回路，断开时触发 HV 断开
绝缘监测	方式、监测周期	绝缘电阻监测，周期性检测
外部通信	总线类型、冗余方向	CAN-FD（→ PCS）、CAN（→ VCU）
低压系统	12V 供电方案、电源监测	安全供电 + 欠压监测
热管理接口	温度采集、冷却控制	NTC 传感器组 + 冷却控制请求
软件分区	分区策略、监控方向	安全应用分区 + 监控分区

3.2 第二步：TSR 导出

TSR 从多个来源导出，按标准的六类安全机制措施组织：

从 FSR 继承的 TSR（主要来源）：

FSR（Part 3）	→ TSR	对应措施类别	时间预算
“动力电池系统在检测到单体过压时，应在 FTTI 内断开充电回路进入安全状态”	“BCU 在接收到 CMU 上报的过压信号持续 FDTI ≤ 2s 确认为故障后，应在 FRTI ≤ 200ms 内断开主正接触器，使系统进入安全状态”	b) 安全状态	FDTI ≤ 2s, FRTI ≤ 200ms
“动力电池系统在确认故障后，应在 FTTI 内向 PCS 发送停止充电指令”	“BCU 在确认过压/过流故障后，应在 FRTI 内通过 CAN-FD 向 PCS 发送停止充电指令”	e) 外部措施	包含在 FRTI 内
“限制充放电功率”	“BCU 在检测到温度超限信号持续 FDTI 内确认后，应在 FRTI ≤ 1s 内限制充放电功率至安全水平”	c) 降级状态	FRTI ≤ 1s

从架构衍生的 TSR：

架构决策	→ TSR	对应措施类别
“采用双通道冗余架构”	“两条检测通道应独立运行，一条通道的故障不应导致另一通道失效”	a) 故障控制
“安全应用与监控应用分区”	“安全应用分区与监控分区应通过 MPU 实现内存隔离”	a) 故障控制

从安全分析导出的 TSR（补充来源）：

安全分析方法	发现的失效模式	→ TSR	对应措施类别
FMEA	CMU 传感器供电失效	“CMU 应监控自身传感器供电电压，当供电异常持续 FDTI ≤ 2s 时向 BCU 上报故障标志”	a) 故障检测
FMEA	接触器驱动电源失效	“BCU 应监控接触器驱动电源状态，当驱动电源异常持续 FDTI ≤ 2s 时标记驱动故障并禁止合闸指令”	a) 故障检测
FMEA	传感器信号异常	“BCU 应对 CMU 上报的电压信号执行合理性检查（范围/变化率），当信号异常持续 FDTI ≤ 2s 时标记传感器故障”	a) 故障检测
FMEA	菊花链通信数据损坏	“BCU 应对菊花链通信实施 E2E 保护（CRC + rolling counter + timeout），当检测到 CRC 错误或消息超时持续 FDTI ≤ 2s 时标记通信故障”	a) 故障检测
FMEA	存储器损坏	“BCU 应通过 ECC/CRC 检测 RAM/Flash 完整性，当检测到不可纠正错误时在 FDTI 内标记存储器故障”	f) 潜伏故障预防
FMEA	接触器粘连	“BCU 在发出接触器断开指令后，应回读母线电压确认断开状态；若回读电压未降至阈值以下，标记断开失败故障”	a) 故障检测

⚠️ TSR 的三种来源缺一不可：

• 只有 FSR 继承 → 安全功能本身有了，但不知道怎么防自身失效
• 只有架构衍生 → 知道架构约束，但不知道要实现什么安全功能
• 只有安全分析 → 知道防什么失效，但不知道安全功能本身怎么做
• 三者合在一起才是完整的 TSC

3.3 第三步：TSR 的 HW/SW 分配

TSR 导出后，判断每条 TSR 由系统中的哪个要素、以硬件还是软件方式实现：

TSR 措施类别	分配方向	示例
故障检测（a）	HW 传感器 + SW 判定逻辑	电压检测：传感器（HW）+ 过压判定（SW）
安全状态（b）	HW 驱动 + SW 控制	继电器断开：驱动电路（HW）+ 控制逻辑（SW）
降级状态（c）	SW 控制为主	功率限制：功率管理模块（SW）
外部措施（e）	HW 通信 + SW 协议	CAN 通信：收发器（HW）+ E2E 保护（SW）
潜伏故障预防（f）	HW 机制 + SW 自检	上电自检：硬件初始化（HW）+ 诊断测试（SW）

3.4 第四步：ASIL 继承确认

系统要素的 ASIL 通过继承确定，经过安全分析验证：

阶段	依据	结果
继承	要素实现的所有 TSR 中最高的 ASIL	继承 ASIL
分解验证	DFA 证明分解通道独立性	独立 → 分解有效；不独立 → 回到原始 ASIL
混合 ASIL 验证	自由干扰分析证明低 ASIL 不干扰高 ASIL	无干扰 → 可共存；有干扰 → 需隔离或升级

安全分析三件套：

分析方法	解决的问题	对 ASIL 的影响
FMEA	要素坏了影响什么？	发现新单点 → 需加安全机制 → 新增 TSR
FTA	安全目标失败需要什么条件？	验证安全机制覆盖率是否充分
DFA	分解的两个通道独立吗？	不独立 → 分解无效 → 要素回到原始 ASIL

FMEA/FTA/DFA的详细操作方法将在后续单独的章节展开。

---

4. 具体案例：动力电池系统 TSC + 架构迭代

Item 名称：动力电池系统（Traction Battery System）

本节以 SG-01（防止过充，ASIL D）为主线，展示完整的 TSC + 架构迭代过程。

4.1 输入回顾：从 FSC 到 TSC

FSR 编号	FSR 描述	ASIL	FSC 中的分解方案
FSR-01a	动力电池系统在检测到单体电压超过充电截止阈值时，应在 FTTI 内断开充电回路进入安全状态	D	通道 A：ASIL B(D)
FSR-01b	动力电池系统在检测到充电电流超过安全限值时，应在 FTTI 内断开充电回路进入安全状态	D	通道 B：ASIL B(D)
FSR-01c	动力电池系统在确认过压或过流故障后，应避免输出错误的充电许可信号，应在 FTTI 内断开主接触器	D	不分解（执行端）
FSR-01d	动力电池系统在确认故障后，应在 FTTI 内向 PCS 发送停止充电指令	D	通道 B：ASIL B(D)

FSC 给出的 FTTI = 3s。FSR 描述的是 Item 级（动力电池系统）安全行为——不涉及内部组件分解、FDTI/FRTI 时间预算、或具体信号的确认逻辑。这些是 TSC/TSR 的工作：将"动力电池系统检测到过压"细化为"CMU 采样上报 → BCU 确认 → BCU 断开接触器"的组件级交互。

4.2 第一步：系统架构设计

系统架构展示系统内部所有实现组件——采用主流分布式主从架构（BCU + CMU + BDU），按功能域划分：

架构说明（按功能域）：

功能域	核心要素	安全职责	对外接口
电池模组组	电芯 + NTC 温度传感器	能量存储、温度采集	→ CMU（电压/温度信号）→ BDU（HV 功率）
BDU 电池断开单元	主正/主负接触器、预充继电器、HV 保险丝、Pyrofuse、电流传感器	高压安全网关：正常通断、过流保护、紧急断开	← BCU 控制 / → HV 输出
CMU 从控组	CMU 1~N + 菊花链通信	模组级单体电压/温度采集，菊花链上报	→ 菊花链 → BCU
BCU 主控单元	安全应用分区 + 监控分区 + 看门狗 + 12V 安全电源	安全逻辑执行、SOX 估算、整车通信、程序流监控	→ BDU 控制 / → CAN-FD → PCS / → CAN → VCU
安全辅助	HVIL 高压互锁 + 绝缘监测	高压连接完整性检测、绝缘电阻监测	→ BCU

关键设计特征：

• 分布式主从架构：BCU（主控）通过菊花链管理多个 CMU（从控），菊花链比 CAN 更适合内部大量单体数据传输，减少线束和隔离器件
• BDU 独立为高压安全网关：主正/主负接触器 + 预充电路 + 保险丝 + Pyrofuse + 电流传感器构成完整的断开和保护单元
• HV/LV 隔离：高压域和低压域通过数字隔离器在菊花链和控制信号处隔离，防止 HV 故障侵入 LV 控制电路
• BCU 软件分区：安全应用分区执行安全逻辑，监控分区（独立看门狗 + 程序流监控）作为独立安全机制——两者需 MPU 内存隔离（自由干扰分析要求）

4.3 第二步：ASIL 继承

各要素的 ASIL 通过继承确定：

系统要素	继承的 TSR	ASIL	来源
BCU 主控单元	TSR-B01/B02（安全状态）等	D	不分解
监控分区	TSR-A05（程序流监控）等	D	安全分析
CMU 从控 1~N（通道 A）	TSR-A01（电压检测）	B(D)	FSC 分解方案
电流传感器（通道 B）	TSR-A02（电流检测）	B(D)	FSC 分解方案
菊花链通信	TSR-A01 依赖（数据传输）	B(D)	架构衍生
主正/主负接触器	TSR-B01/B02（断开继电器）	D	不分解
预充继电器	TSR-B01 依赖（安全合闸）	D	安全分析
Pyrofuse	TSR-B03（紧急断开）	D	安全分析
HV 保险丝	TSR-B04（过流保护）	D	安全分析
HVIL 互锁	TSR-A06（HVIL 监测）	C	安全分析
绝缘监测	TSR-A07（绝缘监测）	D	安全分析
12V 安全电源	TSR-A08（供电监测）	D	安全分析
CAN-FD 通信链路	TSR-E01（停止充电指令）	B(D)	FSC 分解方案
看门狗	TSR-A05（程序流监控）	D	安全分析

4.4 第三步：TSR 导出

以下按标准的六类安全机制措施组织 TSR（选取 SG-01 防止过充的部分 TSR）：

a) 故障检测、指示和控制

TSR 编号	TSR 描述	来源	ASIL	FDTI	分配
TSR-A01	CMU 应监控自身传感器供电电压，当供电电压持续低于阈值达到 FDTI ≤ 2s 时，向 BCU 上报供电异常故障标志	FMEA	D	≤ 2s	CMU SW 诊断
TSR-A02	BCU 应对 CMU 上报的电压信号执行合理性检查（范围/变化率），当信号异常持续 FDTI ≤ 2s 时标记传感器故障	FMEA	D	≤ 2s	BCU SW 诊断
TSR-A03	BCU 应监控主接触器驱动电源状态，当驱动电源异常持续 FDTI ≤ 2s 时标记驱动故障并禁止合闸指令	FMEA	D	≤ 2s	BCU SW + HW 监测
TSR-A04	BCU 在发出接触器断开指令后，应回读母线电压确认断开状态；若回读电压未降至阈值以下持续 FRTI 内，标记断开失败故障	FMEA	D	≤ 2s	BCU SW + HW 回读
TSR-A05	看门狗应监控 BCU 程序执行流，当程序流异常持续 FDTI ≤ 500ms 内触发复位	FMEA	D	≤ 500ms	HW 看门狗 + BCU SW
TSR-A06	BCU 应对菊花链通信实施 E2E 保护（CRC + rolling counter + timeout），当检测到 CRC 错误或消息超时持续 FDTI ≤ 2s 时标记通信故障	FMEA	B(D)	≤ 2s	BCU SW
TSR-A07	BCU 应通过 ECC/CRC 检测 RAM/Flash 完整性，当检测到不可纠正错误时在 FDTI 内标记存储器故障	FMEA	D	≤ 2s	HW ECC + BCU SW

b) 达到和维持安全状态

TSR 编号	TSR 描述	来源	ASIL	FRTI	分配
TSR-B01	BCU 在接收到 CMU 上报的过压信号（持续 FDTI ≤ 2s 确认为故障）后，应在 FRTI ≤ 200ms 内断开主正接触器，使系统进入安全状态	FSR-01a/c	D	≤ 200ms	BCU SW 控制 + 接触器 HW 驱动
TSR-B02	BCU 在接收到电流传感器的过流信号（持续 FDTI ≤ 2s 确认为故障）后，应在 FRTI ≤ 200ms 内断开主正接触器，使系统进入安全状态	FSR-01b/c	D	≤ 200ms	BCU SW 控制 + 接触器 HW 驱动

c) 达到和维持降级状态

TSR 编号	TSR 描述	来源	ASIL	时间	分配
TSR-C01	BCU 在检测到温度超限信号持续 FDTI 内确认为故障后，应在 FRTI ≤ 1s 内限制充放电功率至安全水平	FSR-05d	D	≤ 1s	BCU SW 控制

d) 驾驶员/操作员指示

TSR 编号	TSR 描述	来源	ASIL	时间	分配
TSR-D01	BCU 在确认安全相关故障后，应在 FRTI ≤ 1s 内通过 CAN 向仪表盘发送故障指示	FSR	B(D)	≤ 1s	BCU SW 通信

e) 外部安全措施

TSR 编号	TSR 描述	来源	ASIL	时间	分配
TSR-E01	BCU 在确认过压/过流故障后，应在 FRTI 内通过 CAN-FD 向 PCS 发送停止充电指令	FSR-01d	B(D)	包含在 FRTI 内	BCU SW 通信
TSR-E02	BCU 在检测到热失控风险信号持续 FDTI 内确认后，应在 FRTI ≤ 1s 内向 VCU 发送紧急停车请求	FSR-05d	D	≤ 1s	BCU SW 通信

f) 防止潜伏故障

TSR 编号	TSR 描述	来源	ASIL	分配
TSR-F01	BCU 应在每次上电时执行自检测试，覆盖关键硬件要素（ADC/接触器驱动/绝缘监测/HVIL）	FMEA	D	HW 初始化 + BCU SW 自检
TSR-F02	BCU 应周期性执行在线诊断测试（RAM March/ROM CRC/绝缘功能验证），覆盖潜伏故障	FMEA	D	BCU SW 诊断

时间预算验证（SG-01）：

• FDTI（故障检测）≤ 2s：对应 TSR-A01~A07 的检测措施
• FRTI（故障反应）≤ 200ms：对应 TSR-B01/B02 的安全状态措施 + TSR-E01 的外部措施
• FHTI = FDTI + FRTI = 2.2s ≤ FTTI = 3s ✓

4.5 第四步：安全分析反馈——ASIL 迭代

对初步架构和 TSR 进行安全分析后的反馈：

要素	继承 ASIL	分析方法	发现的问题	修正结果
CMU 从控组（通道 A） + 电流传感器（通道 B）	B(D) + B(D)	DFA	CMU 和电流传感器共用 12V 供电 → 共因失效，独立性不成立	改为独立供电后重新分解；或回到 ASIL D
监控分区	B(D)	DFA	与 BCU 安全应用共享 RAM → 级联失效	需增加 MPU 隔离，或升级为 ASIL D
QM 功能软件	QM	自由干扰分析	与 ASIL D 安全软件共享同一分区	需 MPU 内存隔离，或升级为 A(D)
菊花链通信	B(D)	FMEA	菊花链断线/通信丢失导致 CMU 数据无法到达 BCU	新增 TSR：BCU 检测到菊花链通信超时持续 FDTI 内应标记通信故障并在 FRTI 内进入安全状态
Pyrofuse 驱动	D	FMEA	Pyrofuse 驱动电源失效 → 碰撞时无法紧急断开	新增 TSR：BCU 应监控 Pyrofuse 驱动电源，异常持续 FDTI 内标记故障
预充电路	D	FMEA	预充电阻过热/开路 → 合闸时浪涌电流损坏接触器	新增 TSR：BCU 在闭合主接触器前应确认预充完成（母线电压达到阈值），否则禁止合闸
HVIL 互锁	C	FMEA	HVIL 回路断开但 BCU 未在 FDTI 内响应	确认 TSR-A06 已覆盖（HVIL 断开 → FDTI 内断开 HV）

4.6 最终 ASIL 确认

要素	继承 ASIL	最终 ASIL	变化原因
BCU 主控单元	D	D	不分解
监控分区	B(D)	D	DFA 发现 RAM 共享 → 级联风险，升级
CMU 从控组	B(D)	B(D)	使用独立 12V 供电后分解成立
电流传感器	B(D)	B(D)	使用独立供电后分解成立
菊花链通信	B(D)	B(D)	新增通信超时检测 TSR
主正/主负接触器	D	D	不分解
Pyrofuse	D	D	新增驱动电源监测 TSR
预充继电器	D	D	新增预充确认 TSR
HV 保险丝	D	D	不变
HVIL 互锁	C	C	不变
绝缘监测	D	D	不变
12V 安全电源	D	D	不变
看门狗	D	D	不变
软件分区隔离（MPU）	—	D（新增）	自由干扰分析要求

4.7 TSR 追溯矩阵

三种来源清晰可追溯：

• TSR-B01/B02（安全状态）← FSR 继承：FSR 说"动力电池系统检测到过压时在 FTTI 内断开" → TSR 细化为"BCU 在接收到 CMU 过压信号持续 FDTI 确认后，在 FRTI 内断开主正接触器"
• TSR-A01~A07（故障检测）← FMEA 安全分析 + 架构决策：明确到具体组件（CMU/BCU/看门狗）检测什么故障、FDTI 多少
• TSR-F01/F02（潜伏故障预防）← FMEA 安全分析：明确 BCU 在上电和周期性诊断时执行什么测试

4.8 HSI 顶层定义

硬件资源方向	安全相关	ASIL	用途
菊花链通信接口	是	B(D)	BCU ↔ CMU 单体电压/温度数据
电流采样接口	是	B(D)	分流器电压采集
接触器驱动输出	是	D	主正/主负接触器 + 预充继电器控制
Pyrofuse 驱动输出	是	D	紧急断开控制
HVIL 输入	是	C	高压互锁状态检测
绝缘监测接口	是	D	绝缘电阻采集
CAN-FD 控制器	是	B(D)	PCS 通信
CAN 控制器	是	C	VCU 通信
看门狗	是	D	程序流监控
MPU	是	D	内存分区隔离
ECC	是	D	存储器故障检测
12V 电源监测	是	D	低压供电状态检测

系统阶段 HSI 只定义"需要什么类型的硬件资源"和 ASIL，不定义具体通道号和寄存器地址。

---

5. 总结与关键要点

✅ 核心结论

TSC 是功能安全从"概念"到"实现"的关键一跳——它把 FSR 转化为系统级技术需求（含时间预算），并通过安全分析导出诊断需求，为后续硬件和软件开发提供明确输入。

要点	核心结论
TSC 的定位	Part 4 Clause 6，承接 FSC，产出 TSR + 系统架构 + HSI
TSR 颗粒度	系统级技术需求 + FDTI/FRTI 时间预算 + HW/SW 分配方向，不下沉到 HSR/SSR 级别
HSR/SSR	细化的安全需求（非仅参数）：安全机制行为、故障检测/处理、容错、架构指标、数据完整性（Clause 5-6 / Clause 6）
TSR 来源	FSR 继承（主） + 架构衍生 + 安全分析导出（补充）
安全机制分类	标准 6.4.2.2 的六类措施：故障检测/安全状态/降级/指示/外部措施/潜伏故障预防
时间预算	FHTI = FDTI + FRTI ≤ FTTI，涉及故障检测和反应的 TSR 携带时间分配
安全分析内容	FMEA（失效模式→影响→覆盖率）、FTA（顶事件→路径→阻断）、DFA（独立性验证）→ 补充 TSR
系统架构	展示系统内部所有实现组件（传感器/控制器/执行器/通信/电源），不画外部 Item
架构颗粒度	要素级别，ADC/GPIO 等硬件组件在 Part 5
ASIL	从 TSR 继承，不是"分配"；分解需 DFA 验证
软件监控	系统阶段（Clause 6.4.2.1）定义监控策略，软件阶段（Clause 6 + 7.4.14）实现；标准不强制固定清单
安全分析三件套	FMEA + FTA + DFA
追溯链	SG → FSR → TSR（三种来源）；架构 → 安全分析 → 诊断 TSR

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/2401_86887187/article/details/164507293