Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

2.6 技术安全概念与系统架构——从“做什么“到“怎么做“的落地

你面前摆着两页纸。左边那一页是功能安全概念：14条FSR（功能安全需求），用功能语言写的，模板一般长这样：

FSR-03：当检测到力矩控制故障时，系统应在故障确认后触发安全状态过渡。

右边那一页是空的。你现在需要填写它：技术安全概念（Technical Safety Concept, TSC）。

你拿起笔，在空白处写下第一行：

TSR-03a：EPS主控MCU内部锁步比较器（Lockstep Comparator）应在主核与校验核计算结果不匹配时，在不超过5个时钟周期内触发故障信号至SMU（安全管理单元）。

然后你停住了。你突然意识到一个问题：FSR-03中没有任何关于锁步核、SMU、时钟周期的内容。你是从哪里“变“出这些技术细节的？

这就是技术安全概念的本质。它不“变“出技术细节，而是将功能层面的安全意图，嫁接到一个具体的技术架构上。FSR说“系统应检测力矩控制故障并触发安全状态过渡“，你选择了双核锁步架构，然后FSR就自然地“生长“出了锁步比较器、SMU、独立GPIO路径这些技术安全需求。

功能安全概念问的是“What“，技术安全概念答的是“How“。

免疫隐喻：从免疫策略到免疫分子通路的实现

让我们再次回到免疫系统，这一次深入到分子层面。

功能安全概念相当于免疫系统的“免疫策略“：

  • “检测并清除病原体”（安全目标）
  • “在24小时内完成清除，期间启动发热作为辅助手段”（FSR级别的需求）

技术安全概念则相当于免疫系统的分子通路实现：

  • “Toll样受体4（TLR4）识别LPS后，激活MyD88依赖通路，通过磷酸化级联反应激活NF-κB转录因子……”（这是技术细节：相当于TSR）
  • “补体C3通过C3转化酶裂解为C3a和C3b，C3b沉积在病原体表面进行调理素标记……”（这是架构设计：相当于TSC中的具体机制描述）
  • “细胞因子IL-1β和TNF-α的释放量受负反馈回路调控，避免过度炎症反应损伤正常组织……”（这是HSI：不同系统之间的接口约束）

免疫系统是怎么从“策略“变成“分子通路“的？它经过了数十亿年的进化：每一次基因突变都是一次“技术选型“。TLR4之所以识别LPS而不是别的分子，不是因为有谁“设计“了它，而是因为在漫长的进化过程中，这个特定的分子识别机制被证明是有效的。

你的技术安全概念没有数十亿年可以试错。你必须在数周到数月内，用工程分析、已知的架构模式、安全分析，来证明你选择的这个技术方案。这个特定的锁步核、这个特定的SMU、这个特定的安全状态切换路径：能够在所有的运行场景下、面对所有相关的故障模式，满足功能安全概念的要求。

技术安全概念的定义与核心要素

ISO 26262-4第6条定义TSC为：

技术安全概念是技术安全需求（TSR）与系统架构设计的集合。它指定了系统架构中安全机制的技术实现，以满足功能安全需求，并作为硬件和软件详细设计的输入。

这句话有几个关键信息：

  1. TSC = TSR集合 + 系统架构设计。它不是单一文档，而是技术安全需求和承载这些需求的系统架构设计的总和。
  2. TSC是连接FSR和硬件/软件详细设计的桥梁。FSR → TSR（派生） → 硬件设计/软件设计（分配）。
  3. TSC的技术粒度应该足够细，使得硬件工程师和软件工程师可以直接基于TSC开始各自的详细设计。

从FSR到TSR：技术安全需求的派生

TSR不是FSR的“翻译“或“复制“。它们是派生关系：FSR告诉你“目标状态“，TSR告诉你“在当前选定的技术架构下，达到这个目标需要什么技术条件“。

以一个FSR为例：

FSR（功能层面）：“系统应监控电机实际输出力矩与指令力矩的偏差，当偏差超出阈值时应判定为故障。”

在选定的技术架构下（有一个主控MCU、两个独立的力矩传感器、一个三相电机驱动桥、一个独立的监控MCU），这条FSR可能派生为以下TSR：

  • TSR-A：主控MCU应以不低于1kHz的频率采集力矩传感器1和力矩传感器2的原始数据，并通过交叉校验确保两个传感器信号的一致性（允许偏差≤3%满量程）。
  • TSR-B：主控MCU应通过相电流采样重构实际电机力矩，并以不低于1kHz的频率与指令力矩进行比较。当重构力矩与指令力矩的偏差超过预设阈值（T_threshold）持续超过T_debounce时，应触发故障标志位。
  • TSR-C：独立监控MCU应通过独立的ADC通道读取相电流，独立重构电机力矩并与收到的指令力矩（通过独立SPI通讯获取）进行比较。当偏差超过T_threshold_independent时，应通过独立硬件路径触发安全状态。
  • TSR-D：主控MCU与独立监控MCU之间的SPI通讯应受CRC-16保护，通讯更新频率不低于1kHz，通讯失效率（在规定的时间窗口内检测到连续3帧CRC错误）应触发通讯故障标志位。

注意这些TSR的细节：

  • 它们是技术特定的（1kHz采样频率、3%偏差阈值、CRC-16、连续3帧）
  • 它们是可分配给硬件或软件的（ADC通道、SPI接口是硬件关注点；采样逻辑、阈值比较是软件关注点）
  • 它们并没有规定具体的硬件型号或软件算法的内部实现（不需要指定MCU型号、不需要指定滤波算法）
  • 它们保持了与FSR的可追溯性

系统架构设计

技术安全概念中的系统架构设计，不是普通意义上“把系统分几个模块“的架构图，而是以安全为核心目标的系统架构设计。它必须展现以下特性（ISO 26262-4, Clause 6.4）：

1. 模块化（Modularity）

安全相关的功能和非安全相关的功能应该在架构层面清晰隔离。你不能让空调控制的软件和一个ASIL D的EPS控制的软件运行在同一个没有分区保护的MCU上：除非你能证明空调控制无论如何都不能干扰EPS控制（这就是FFI，Freedom From Interference，免于干扰）。

模块化还意味着：如果一个安全功能需要变更（比如安全阈值的调校），这个变更不应该波及整个系统。它应该被局限在明确定义的模块边界内。

2. 足够的粒度（Adequate Granularity）

架构分解必须足够细，使得：

  • 每个元素的安全需求可以明确分配
  • 每个元素的安全特性可以独立验证
  • 元素之间的接口可以明确定义
  • 失效的传播路径可以追溯

不够细的架构设计是安全分析的噩梦。当一个故障发生时，你无法确定它来自哪里、影响了谁。

3. 简洁性（Simplicity）

这里的“简洁“不是“简单“，而是“不引入不必要的复杂性“。每增加一个安全机制，你就在系统中增加了一个可能的失效点。一个好的安全架构应该在满足安全需求的前提下，尽量少地引入额外的复杂度。

免疫系统也遵循简洁性原则：它不需要为每一种可能的病原体专门准备一套检测机制，而是用有限的几种模式识别受体（TLR）覆盖绝大多数威胁。这就是简洁性：用最少的机制覆盖最多的场景。

4. 接口定义与FFI

系统架构设计必须明确定义内部和外部接口，确保：

  • 一个元素的行为不能对其他安全相关元素产生不利影响
  • 低ASIL（或QM）的元素不能干扰高ASIL元素的正确执行
  • 共享资源（内存、总线、I/O引脚）的访问受到控制

对于ASIL D的系统，FFI通常通过以下手段实现：

  • 物理分离：安全相关的MCU和QM功能的MCU是两颗不同的芯片
  • 时间分离：安全相关的任务和QM任务在不同的时间槽中执行（如果共享同一颗MCU）
  • 内存保护：通过MPU（内存保护单元）或MMU确保安全相关软件的内存区域不被其他软件访问
  • 通讯保护：所有安全相关的通讯使用端到端（E2E）保护，包括但不限于CRC、序列号、超时检测

HSI（硬件-软件接口）规范

HSI（Hardware-Software Interface）规范是技术安全概念的一个核心工作产品。它梳理并定义了硬件和软件之间所有交互要素的规格，确保软件开发团队和硬件开发团队对“对方会做什么、对方期望什么“有一致的理解。

ISO 26262-4 Clause 6.4.7要求HSI规范包含以下内容：

硬件设备的操作模式与配置参数

软件需要知道硬件的哪些寄存器控制什么行为、哪些工作模式可用、如何在模式之间安全切换。一个典型的例子：EPS控制器的MOSFET驱动桥有一个“安全禁用“模式，这个模式是通过某个特定寄存器的特定位组合来触发的。HSI规范必须明确说明：这个寄存器叫什么、位域怎么定义、写入这个寄存器后硬件多久完成模式切换、切换完成后硬件输出什么信号来确认。

共享资源与互斥

如果主控核和监控核共享了某个ADC模块，那么HSI规范必须定义它们之间的互斥机制：谁在什么时间窗口使用ADC、如何防止同时访问导致的数据损坏。

时间约束

硬件必须在多长时间内响应软件的请求？软件必须在多短的延迟内处理硬件的中断？这些时间约束必须在HSI规范中明确规定，因为它们直接影响FTTI的分配和验证。

例如：电机电流采样中断的延迟必须小于50μs（从硬件触发到软件进入ISR开始读取ADC数据的最大延迟），否则TSR中规定的1kHz控制环频率将得不到保证。这条时间约束既约束了硬件（中断控制器的优先级配置、中断响应延迟上限），也约束了软件（ISR中不允许有不可中断的长临界区）。

硬件诊断与错误报告

硬件提供了哪些自诊断能力？如何在软件层面访问这些诊断结果？如果硬件的BIST（Built-In Self Test，内置自检）在启动阶段发现了故障，硬件如何通知软件？是通过特定的状态寄存器的值，还是通过一个专用的故障信号引脚？

所有这些信息，都属于HSI规范的范畴。

安全分析：FTA与FMEA

技术安全概念不能只靠“我觉得这个设计挺安全的“来说服安全评估师。你需要结构化、系统化的安全分析来证明：在选定的技术架构下，所有识别到的故障、所有潜在的故障传播路径，都已经被安全机制覆盖。

ISO 26262-4对不同的ASIL等级推荐了不同的安全分析方法：

FTA（故障树分析，Fault Tree Analysis）

适用对象：ASIL C和D高度推荐，ASIL B可以考虑。

FTA是一种演绎（Deductive）分析：从顶层的危害事件出发，向下推导“什么故障组合会导致这个危害“。它回答的问题是：“这个危害事件是怎么发生的？”

FTA将危害事件放在树的顶端（顶事件），然后通过逻辑门（AND、OR等）向下分解为中间事件和基本事件（底事件）。分析一直持续到找到所有的底事件：也就是可以被设计直接控制的、最根本的故障原因。

例如，对于顶事件“EPS在高速行驶时非预期输出50Nm左转力矩“：

顶事件：EPS非预期输出50Nm左转力矩（AND门）
├── 子事件1：转向指令存在错误（OR门）
│   ├── 底事件1.1：力矩传感器输出错误读数
│   ├── 底事件1.2：CAN总线上的转向角度信号被篡改
│   └── 底事件1.3：主控MCU的RAM中指令参数被比特翻转
└── 子事件2：安全机制未能阻止错误指令的执行（OR门）
    ├── 底事件2.1：独立监控MCU与主控MCU同时故障（共因失效）
    ├── 底事件2.2：安全状态切换的GPIO硬件路径断线
    └── 底事件2.3：SMU配置错误导致未能触发安全状态

FTA的价值在于它的结构化。你可以量化为防止顶事件发生，需要控制多少个底事件、底事件之间是AND关系还是OR关系。如果发现一个AND门下的多个底事件存在共因（比如底事件1.3和底事件2.1都源于同一颗晶振的时钟故障），那么你可以及时识别并在设计中采取措施（如使用独立时钟源）。

FMEA（失效模式与影响分析，Failure Mode and Effects Analysis）

适用对象：所有ASIL等级（从ASIL A到ASIL D）。

FMEA是一种归纳（Inductive）分析：从底层的每个元件的每个失效模式出发，向上推导“这个失效会导致什么后果“。它回答的问题是：“如果这个元件这样坏了，会发生什么？”

FMEA的分析单位可以是：

  • 系统级FMEA：以系统功能块为分析单位，关注功能失效
  • 硬件FMEA：以分立元件（电阻、电容、IC管脚）或功能组件（MCU、传感器模块）为分析单位，关注硬件失效模式
  • 软件FMEA：以软件函数、变量、接口为分析单位，关注软件失效模式（变量值超出范围、函数调用时序错误等）

一个硬件FMEA的条目示例：

元件失效模式失效影响（局部）失效影响（系统级）严重度检测手段现有控制
力矩传感器T1信号线开路ADC读数跌落至0V力矩监控检测到T1/T2偏差超限，触发安全状态S3（如未被检测）ADC范围检查+T1/T2交叉校验TSR-C中的交叉校验机制，检测到偏差后50ms内进入安全状态

FTA与FMEA的互补

FTA是“从顶向下“，帮你确保你“没有漏掉任何可能的原因组合“。 FMEA是“从底向上“，帮你确保你“没有漏掉任何一个元件的任何失效模式“。

两者合在一起，覆盖了安全分析的“立体空间“。

对于ASIL D系统，两者通常都需要执行，并且彼此的结果要相互核对：FTA识别到的每个底事件，在FMEA中都应该能找到对应的条目；FMEA中识别出高严重度但没有被FTA覆盖的失效模式，需要回溯FTA看是否有遗漏。

TSC的工作产品（Work Products）

根据ISO 26262-4，技术安全概念阶段需要产出的工作产品包括：

工作产品内容注释
技术安全需求规范（TSR Spec）从FSR派生的所有技术安全需求每条TSR必须可回溯到至少一条FSR
技术安全概念（TSC）系统架构设计 + TSR在架构元素上的分配包含安全机制的架构图和分配矩阵
系统架构设计说明系统架构设计文档展现模块化、粒度、简洁性、接口
硬件-软件接口规范（HSI Spec）硬件和软件之间的所有接口约定的详细说明包含模式、配置、共享资源、时间约束
安全分析报告FTA和/或FMEA的结果包含分析范围、假设、发现的问题、改进措施
TSC验证报告验证TSC是否满足FSR、是否正确分配、分析是否完整通常以评审的形式进行

技术安全概念验证

在技术安全概念发布给硬件和软件团队作为输入材料之前，它必须经过验证。验证的内容包括：

  1. TSR与FSR的一致性：每条TSR是否至少对应一条FSR？TSR合在一起是否充分实现了FSR？
  2. 系统架构的充分性：架构是否展现了模块化、足够的粒度、简洁性？
  3. 安全机制的覆盖：安全分析是否识别了所有相关的失效模式？安全机制是否充分覆盖？
  4. FFI的有效性：QM和低ASIL元素是否确实无法干扰高ASIL元素？
  5. HSI规范的完整性：硬件和软件之间的所有交互是否都被HSI规范覆盖？
  6. FTTI的可实现性：TSR中分配的时间约束在选定的技术方案下是否可以实现？

验证通常是**评审（Review）**的形式，由独立于TSC开发团队的专家进行。对于ASIL C和D，评审需要更加正式和系统化：有明确的检查清单、评分标准，评审结果需要记录和追踪。

本篇小结

  1. TSC = TSR集合 + 系统架构设计：将功能安全需求转化为技术实现规范
  2. TSR从FSR派生，粒度要精确到“接口约定“而非“实现选择“
  3. 系统架构必须展现模块化、足够粒度、简洁性，关键是在高低ASIL之间建立FFI隔离
  4. HSI规范是硬件和软件之间的“合同“
  5. 安全分析（FTA+FMEA）是系统性方法：FTA从顶向下，FMEA从底向上，两者互补
  6. TSC的所有工作产品必须经过独立验证

【下集预告】： 系统架构搭好了，HSI写清楚了。下一节钻到硬件层面：47个元器件，每个都有自己的失效模式——开路、短路、漂移。SPFM问的是：这些失效中有多少是“一步到位“直接要命的？你为它们设计的诊断电路覆盖率够不够？99%是ASIL D的及格线，差一个百分点都不能放行。