ISO 26262-4 系统级开发：从概念到实现

引言

如果说 ISO 26262-3 概念阶段是绘制蓝图，那么 ISO 26262-4 系统级开发就是根据蓝图建造房子的主体结构。在这个阶段，我们将概念阶段定义的抽象安全目标转化为具体的技术实现方案。

想象一个实际场景：某汽车电子公司开发了一款电子稳定控制系统（ESC），概念阶段确定了"防止车辆失控"的安全目标（ASIL D）。但是，如何实现这个目标？需要什么样的硬件？需要什么样的传感器？如何设计软件架构？如何确保系统在故障时仍然安全？这些都是系统级开发要回答的问题。

ISO 26262-4 提供了完整的框架，指导我们如何：

• 设计系统架构
• 将功能安全需求分配到硬件和软件
• 定义硬件和软件的接口
• 集成和测试系统

系统级开发的目标和范围

系统级开发的核心活动

ISO 26262-4 定义了系统级开发的六个核心活动：

1. 技术安全概念（TSC）的开发

   • 将功能安全概念转化为技术实现方案
   • 定义系统架构和安全机制

2. 系统安全需求（SSyR）的制定

   • 从 FSR 派生系统级安全需求
   • 分配到硬件和软件

3. 硬件安全需求（HSR）和软件安全需求（SSR）

   • 将系统安全需求具体化
   • 定义硬件和软件的接口

4. 系统架构设计

   • 设计硬件架构
   • 设计软件架构
   • 定义硬件和软件的交互

5. 硬件/软件集成（HSI）

   • 定义硬件和软件的接口
   • 确保接口的一致性

6. 系统集成和测试

   • 集成硬件和软件
   • 验证系统满足安全需求

系统级开发的输入和输出

输入

• 功能安全概念（FSC）：来自概念阶段
• 功能安全需求（FSR）：来自概念阶段
• 安全目标（SG）：来自概念阶段
• 系统需求：非安全相关的系统需求
• 硬件和软件约束：技术约束、成本约束、时间约束

输出

• 技术安全概念（TSC）：技术实现方案
• 系统安全需求（SSyR）：系统级安全需求
• 硬件安全需求（HSR）：硬件级安全需求
• 软件安全需求（SSR）：软件级安全需求
• 系统架构设计：硬件和软件架构
• 硬件/软件接口规范（HSIS）：接口定义
• 系统集成测试报告：测试结果

技术安全概念（TSC）的开发

TSC 的定义和作用

技术安全概念（TSC） 是实现功能安全概念的技术策略。它描述了：

1. 如何在技术上实现安全目标
2. 如何在硬件和软件之间分配安全需求
3. 如何设计安全机制
4. 如何确保硬件和软件的独立性

TSC 的开发步骤

第一步：分析功能安全概念

首先，需要深入理解概念阶段定义的功能安全概念。

第二步：确定技术实现策略

选择合适的技术方案，如：

• 冗余架构（双通道、三模冗余）
• 故障检测机制（看门狗、CRC、ECC）
• 故障容错机制（投票机制、降级模式）
• 故障恢复机制（重启、安全状态切换）

第三步：设计系统架构

设计硬件架构和软件架构，并确定安全机制的分配。

第四步：分配安全需求到硬件和软件

将系统安全需求具体化为硬件安全需求和软件安全需求。

案例：制动系统的技术安全概念

让我们以**电子液压制动系统（EHB）**为例，展示 TSC 的开发过程。

功能安全概念（来自概念阶段）

安全目标（SG-1）：

“制动助力系统的故障不得导致制动性能的显著降低，ASIL C”

功能安全需求（FSR-1.1）：

“系统应在 100 ms 内检测到制动助力失效”

功能安全需求（FSR-1.2）：

“在检测到助力失效后，系统应立即启动机械制动备份”

技术实现策略

技术方案选择：

1. 冗余架构：双通道控制器架构
2. 故障检测：压力传感器冗余、电流监测、看门狗
3. 故障容错：主通道故障时切换到备份通道
4. 故障恢复：系统重启、故障记录

系统架构设计

硬件架构：

                    电源管理单元
                         │
          ┌──────────────┼──────────────┐
          │              │              │
    主控制器（MCU1）  备份控制器（MCU2）  安全监控器
          │              │              │
          │              │              │
    压力传感器1      压力传感器2      阀门驱动
          │              │              │
          └──────────────┼──────────────┘
                         │
                    液压执行单元
                         │
                    车轮制动器

软件架构：

应用层
    ├── 控制算法层
    │   ├── 制动控制
    │   ├── 压力调节
    │   └── 故障诊断
    │
中间件层
    ├── 通信层（CAN、SPI）
    ├── 诊断层（UDS）
    └── 时间管理
    │
硬件抽象层（HAL）
    ├── ADC 驱动
    ├── GPIO 驱动
    ├── SPI 驱动
    └── 看门狗驱动
    │
硬件层
    ├── MCU1
    ├── MCU2
    ├── 传感器
    └── 执行器

技术安全需求

TSR-1.1.1：

“硬件应实现双通道压力传感器，每个传感器由独立的 MCU 监测”

TSR-1.1.2：

“软件应每 10 ms 读取一次压力传感器数据，并执行一致性检查”

TSR-1.2.1：

“硬件应实现双通道控制器架构，主/备通道独立运行”

TSR-1.2.2：

“软件应实现主/备通道的故障检测和切换逻辑”

TSR-1.3.1：

“硬件应实现独立于 CPU 的看门狗定时器”

TSR-1.3.2：

“软件应定期喂狗（例如每 5 ms）”

系统安全需求（SSyR）的制定

SSyR 的定义和作用

系统安全需求（SSyR） 是系统级的安全需求，它从功能安全需求派生而来，是硬件和软件需求的桥梁。

SSyR 的分类

1. 性能需求

定义系统的性能指标，如：

• 响应时间
• 故障检测时间
• 故障恢复时间

2. 功能需求

定义系统的功能要求，如：

• 故障检测功能
• 故障容错功能
• 故障恢复功能

3. 接口需求

定义系统内部和外部接口，如：

• 硬件/软件接口
• 与其他系统的接口

4. 约束需求

定义系统的约束条件，如：

• 硬件资源约束
• 软件资源约束
• 时序约束

案例：制动系统的系统安全需求

SSyR-1（来自 FSR-1.1）：

“系统应在 100 ms 内检测到制动助力失效”

SSyR-1.1（性能需求）：

“压力传感器的采样周期不得大于 10 ms”

SSyR-1.2（功能需求）：

“系统应实现压力传感器故障诊断算法”

SSyR-1.3（性能需求）：

“故障诊断算法的执行时间不得超过 20 ms”

SSyR-1.4（功能需求）：

“系统应实现压力传感器数据一致性检查”

SSyR-2（来自 FSR-1.2）：

“在检测到助力失效后，系统应立即启动机械制动备份”

SSyR-2.1（功能需求）：

“系统应实现主/备通道故障检测和切换逻辑”

SSyR-2.2（性能需求）：

“通道切换时间不得超过 50 ms”

SSyR-2.3（功能需求）：

“系统应实现机械制动备份路径的控制逻辑”

硬件安全需求（HSR）和软件安全需求（SSR）

HSR 的定义和作用

硬件安全需求（HSR） 是对硬件的具体安全要求。

HSR 的内容

1. 硬件组件需求：

   • MCU 选型要求
   • 传感器选型要求
   • 执行器选型要求

2. 硬件接口需求：

   • 电源接口
   • 信号接口
   • 通信接口

3. 硬件安全机制需求：

   • 看门狗定时器
   • ECC 内存
   • 冗余设计

SSR 的定义和作用

软件安全需求（SSR） 是对软件的具体安全要求。

SSR 的内容

1. 软件架构需求：

   • 分层架构
   • 模块化设计
   • 独立性要求

2. 软件功能需求：

   • 故障检测算法
   • 故障容错逻辑
   • 故障恢复流程

3. 软件质量需求：

   • MISRA C 编码规范
   • 代码复杂度要求
   • 测试覆盖率要求

案例：制动系统的 HSR 和 SSR

HSR-1.1.1（来自 TSR-1.1.1）：

“硬件应实现双通道压力传感器，每个传感器由独立的 MCU 监测”

具体要求：

• 压力传感器型号：Bosch 0 986 593 501
• 压力传感器精度：±0.1 bar
• 压力传感器故障模式检测：开路、短路、漂移
• MCU1 和 MCU2 应独立供电

HSR-1.3.1（来自 TSR-1.3.1）：

“硬件应实现独立于 CPU 的看门狗定时器”

具体要求：

• 看门狗类型：外部窗口看门狗
• 看门狗超时时间：可配置（默认 100 ms）
• 看门狗复位类型：系统复位

SSR-1.1.2（来自 TSR-1.1.2）：

“软件应每 10 ms 读取一次压力传感器数据，并执行一致性检查”

具体要求：

• 使用硬件定时器中断，周期 10 ms
• 一致性检查算法：
  • 如果 |P1 - P2| > 阈值，判定为故障
  • 阈值根据工况动态调整
• 故障判定逻辑：
  • 连续 3 次检测到不一致，判定为传感器故障

SSR-1.2.2（来自 TSR-1.2.2）：

“软件应实现主/备通道的故障检测和切换逻辑”

具体要求：

• 主通道故障检测：
  • MCU1 看门狗超时
  • MCU1 压力传感器故障
  • MCU1 通信故障
• 切换逻辑：
  • 检测到主通道故障，立即切换到备份通道
  • 切换时间 < 50 ms
  • 切换过程中保持制动功能

系统架构设计

硬件架构设计

硬件架构的原则

1. 独立性原则：冗余通道之间应该独立，避免共因故障
2. 多样性原则：不同通道采用不同的实现方式，避免系统性故障
3. 诊断性原则：硬件应具备自诊断能力

硬件架构的类型

1. 单通道架构：

   • 适用于 ASIL A/B
   • 成本低
   • 安全性有限

2. 双通道冗余架构：

   • 适用于 ASIL C/D
   • 成本中等
   • 安全性高

3. 三模冗余架构（TMR）：

   • 适用于 ASIL D 高要求场景
   • 成本高
   • 安全性最高

案例：ASIL D 系统的三模冗余架构

对于 ASIL D 的电子驻车制动系统（EPB），采用三模冗余架构：

           传感器
             │
    ┌────────┼────────┐
    │        │        │
  MCU1     MCU2     MCU3
    │        │        │
    └────────┼────────┘
             │
         投票器
             │
          执行器

可靠性计算：

假设单个 MCU 的可靠度为 $R = 0.9999$（在任务时间内）。

系统成功运行的条件是：至少两个 MCU 正常工作。

$$ R_{\text{system}} = R^3 + 3 \times R^2 \times (1-R) $$

代入数值： $$ R_{\text{system}} = 0.9999^3 + 3 \times 0.9999^2 \times 0.0001 $$ $$ R_{\text{system}} = 0.9997 + 0.00029997 $$ $$ R_{\text{system}} = 0.99999997 $$

可以看到，通过三模冗余，系统可靠度从 99.99% 提升到了 99.999997%。

软件架构设计

软件架构的原则

1. 分层原则：应用层、中间件层、硬件抽象层、硬件层
2. 模块化原则：每个模块功能单一，接口清晰
3. 独立性原则：安全相关软件与非安全相关软件分离

软件架构的类型

1. 分层架构：

   • 优点：模块化、可维护性好
   • 缺点：性能开销大

2. 面向对象架构：

   • 优点：灵活性高、可扩展性好
   • 缺点：资源消耗大

3. 事件驱动架构：

   • 优点：实时性好、响应快
   • 缺点：调试困难

案例：制动系统的软件架构

分层架构设计：

应用层（Application Layer）
    ├── 制动控制模块
    │   ├── 压力控制算法
    │   ├── 车轮速度控制
    │   └── 车辆稳定性控制
    │
    ├── 故障诊断模块
    │   ├── 传感器故障诊断
    │   ├── 执行器故障诊断
    │   └── 系统故障诊断
    │
    ├── 安全管理模块
    │   ├── 故障处理逻辑
    │   ├── 安全状态管理
    │   └── 故障记录
    │
    └── 通信模块
        ├── CAN 通信
        └── 诊断服务
    │
中间件层（Middleware Layer）
    ├── 操作系统抽象层（OSAL）
    │   ├── 任务调度
    │   ├── 事件管理
    │   └── 定时器管理
    │
    ├── 通信层（Communication Layer）
    │   ├── CAN 驱动
    │   ├── SPI 驱动
    │   └── LIN 驱动
    │
    └── 存储层（Storage Layer）
        ├── EEPROM 驱动
        └── Flash 驱动
    │
硬件抽象层（HAL）
    ├── ADC 驱动
    ├── GPIO 驱动
    ├── PWM 驱动
    ├── 定时器驱动
    └── 看门狗驱动
    │
硬件层（Hardware Layer）
    ├── MCU
    ├── 传感器
    ├── 执行器
    └── 电源管理

软件模块接口定义：

// 制动控制模块接口
typedef struct {
    float pedal_position;      // 制动踏板位置（0-1）
    float vehicle_speed;       // 车辆速度（km/h）
    float wheel_speeds[4];     // 车轮速度（km/h）
} BrakingControlInput;

typedef struct {
    float target_pressure;     // 目标制动压力（bar）
    float valve_command[4];     // 阀门控制指令（0-1）
} BrakingControlOutput;

// 函数原型
void BrakingControl_Init(void);
void BrakingControl_Run(const BrakingControlInput* input, BrakingControlOutput* output);

// 故障诊断模块接口
typedef enum {
    FAULT_NONE = 0,
    FAULT_SENSOR_OPEN,
    FAULT_SENSOR_SHORT,
    FAULT_SENSOR_DRIFT,
    FAULT_ACTUATOR_STUCK,
    FAULT_WATCHDOG_TIMEOUT
} FaultType;

typedef struct {
    FaultType fault_type;
    uint8_t component_id;
    uint32_t timestamp;
} FaultEvent;

// 函数原型
void FaultDiagnosis_Init(void);
void FaultDiagnosis_Run(void);
bool FaultDiagnosis_GetFault(FaultEvent* event);

硬件/软件集成（HSI）

HSI 的定义和作用

硬件/软件集成（HSI） 是定义硬件和软件接口的过程。

HSI 的内容

1. 内存映射

定义硬件寄存器的内存地址，软件通过读写这些寄存器来控制硬件。

2. 中断向量表

定义硬件中断源和软件中断处理程序的对应关系。

3. 数据结构

定义硬件和软件之间交换数据的格式。

4. 时序约束

定义硬件和软件之间交互的时间要求。

案例：制动系统的 HSI

内存映射

中断向量表

数据结构

// 硬件寄存器定义
#define P1_DATA_REG   (*(volatile uint32_t*)0x40000000)
#define P2_DATA_REG   (*(volatile uint32_t*)0x40000004)
#define VALVE_CMD_REG (*(volatile uint32_t*)0x40000008)
#define WDT_FEED_REG  (*(volatile uint32_t*)0x4000000C)
#define STATUS_REG    (*(volatile uint32_t*)0x40000010)

// 硬件状态定义
typedef struct {
    uint8_t p1_ready      : 1;  // 压力传感器1就绪
    uint8_t p2_ready      : 1;  // 压力传感器2就绪
    uint8_t valve_error   : 1;  // 阀门错误
    uint8_t wdt_timeout   : 1;  // 看门狗超时
    uint8_t reserved      : 4;  // 保留
} HardwareStatus;

时序约束

系统集成和测试

系统集成

系统集成的步骤：

1. 单元测试：测试每个硬件组件和软件模块
2. 集成测试：测试硬件和软件的集成
3. 系统测试：测试整个系统的功能
4. 验收测试：验证系统满足需求

系统测试

测试类型

1. 功能测试：

   • 测试系统是否实现了所有功能
   • 测试各种正常和异常场景

2. 性能测试：

   • 测试系统的响应时间
   • 测试系统的吞吐量

3. 安全测试：

   • 故障注入测试
   • 安全状态切换测试
   • 冗余机制测试

4. 可靠性测试：

   • 长时间运行测试
   • 压力测试

案例：制动系统的系统测试

测试用例 1：压力传感器故障检测

测试步骤：

1. 系统上电初始化
2. 模拟压力传感器1开路故障
3. 等待 30 ms
4. 检查系统是否检测到故障
5. 检查系统是否进入安全状态

预期结果：

• 系统在 30 ms 内检测到传感器1开路故障
• 系统切换到传感器2
• 系统向驾驶员发出报警

测试用例 2：主控制器故障检测

测试步骤：

1. 系统上电初始化
2. 模拟主控制器（MCU1）看门狗超时
3. 等待 60 ms
4. 检查系统是否检测到故障
5. 检查系统是否切换到备份控制器

预期结果：

• 系统在 60 ms 内检测到主控制器故障
• 系统切换到备份控制器
• 制动功能保持正常

测试用例 3：阀门故障容错

测试步骤：

1. 系统上电初始化
2. 模拟阀门卡死故障
3. 施加制动踏板
4. 检查系统是否检测到故障
5. 检查系统是否进入安全状态

预期结果：

• 系统检测到阀门卡死故障
• 系统进入安全状态（机械制动备份）
• 驾驶员可以继续制动

实战案例：自动紧急制动系统（AEB）的系统级开发

让我们以一个实际项目为例，展示系统级开发的完整流程。

项目背景

某汽车厂商正在开发 AEB 系统，用于在检测到碰撞风险时自动施加制动，避免或减轻碰撞。

第一步：分析功能安全概念

来自概念阶段的安全目标（SG）：

“AEB 系统不得在未检测到碰撞风险时误制动，ASIL D”

功能安全需求（FSR）：

“AEB 系统应准确检测碰撞风险，误判率 < 0.001%”

第二步：开发技术安全概念

技术方案选择：

1. 传感器融合：摄像头 + 雷达 + 超声波传感器
2. 冗余架构：双通道 ECU 架构
3. 故障检测：传感器健康监测、数据一致性检查
4. 故障容错：单传感器故障时仍能工作

系统架构设计：

                    ┌─────────┐
                    │  摄像头 │
                    └────┬────┘
                         │
                    ┌────▼────┐
                    │ 前雷达  │
                    └────┬────┘
                         │
                    ┌────▼────┐
                    │ 超声波  │
                    └────┬────┘
                         │
                    ┌────▼──────────────┐
                    │   传感器融合单元   │
                    └────┬──────────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
    主控制器（ECU1）  备份控制器（ECU2）  安全监控器
          │              │              │
          └──────────────┼──────────────┘
                         │
                    制动执行器

第三步：制定系统安全需求

SSyR-1（来自 FSR）：

“AEB 系统应准确检测碰撞风险，误判率 < 0.001%”

SSyR-1.1（功能需求）：

“系统应实现多传感器融合算法，综合判断碰撞风险”

SSyR-1.2（性能需求）：

“碰撞风险检测时间不得大于 50 ms”

SSyR-1.3（功能需求）：

“系统应实现传感器健康监测，检测传感器故障”

SSyR-2（来自 FSR）：

“系统在检测到碰撞风险时，应及时施加制动”

SSyR-2.1（性能需求）：

“从检测到碰撞风险到施加制动的时间不得大于 150 ms”

第四步：制定硬件安全需求

HSR-1.1.1（传感器选型）：

“摄像头应具备车道检测和障碍物检测功能”

具体要求：

• 分辨率：1280 × 720
• 帧率：30 fps
• 视场角：90°

HSR-1.1.2（ECU 选型）：

“ECU 应具备双核处理器，分别运行主/备通道”

具体要求：

• CPU：双核 ARM Cortex-A53 @ 1.5GHz
• 内存：4GB DDR4
• 存储：32GB eMMC

第五步：制定软件安全需求

SSR-1.1.1（传感器融合算法）：

“软件应实现卡尔曼滤波算法，融合多传感器数据”

具体要求：

• 算法类型：扩展卡尔曼滤波（EKF）
• 更新频率：10 Hz
• 预测误差：距离 < 0.5m，速度 < 1km/h

SSR-1.3.1（传感器故障诊断）：

“软件应实现传感器数据一致性检查”

具体要求：

• 检查方法：多传感器数据交叉验证
• 故障判定：连续 5 次数据不一致
• 故障响应：标记传感器为不可用，并报警

第六步：定义硬件/软件接口

内存映射：

中断向量表：

第七步：系统集成和测试

集成测试计划：

常见错误和最佳实践

常见错误

1. 硬件/软件接口定义不清

   • 内存映射混乱
   • 中断配置错误
   • 数据格式不一致

2. 架构设计不合理

   • 模块耦合度过高
   • 缺乏独立性
   • 冗余设计不充分

3. 需求追溯不完整

   • FSR → SSyR → HSR/SSR 追溯断裂
   • 无法验证是否满足需求

4. 集成测试不充分

   • 只测试正常场景，忽视故障场景
   • 未进行故障注入测试

最佳实践

1. 使用 SysML/UML 建模

   • 清晰地表达系统架构
   • 建立完整的追溯关系

2. 建立需求追溯矩阵

   • 确保每个需求都有对应的实现和测试
   • 便于审查和审计

3. 采用模块化设计

   • 高内聚、低耦合
   • 便于维护和升级

4. 充分的测试

   • 覆盖所有需求和场景
   • 特别是故障场景

总结

ISO 26262-4 系统级开发是连接概念阶段和具体实现的桥梁。通过本文的深入解读和丰富的案例实践，我们掌握了：

1. 技术安全概念（TSC）的开发：

   • TSC 的定义和作用
   • TSC 的开发步骤
   • 制动系统的 TSC 实践

2. 系统安全需求（SSyR）的制定：

   • SSyR 的分类
   • SSyR 的制定方法
   • 制动系统的 SSyR 实例

3. 硬件安全需求（HSR）和软件安全需求（SSR）：

   • HSR 和 SSR 的定义和作用
   • HSR 和 SSR 的内容
   • 制动系统的 HSR/SSR 实例

4. 系统架构设计：

   • 硬件架构设计（单通道、双通道、三模冗余）
   • 软件架构设计（分层架构）
   • 三模冗余的可靠性计算

5. 硬件/软件集成（HSI）：

   • HSI 的定义和作用
   • HSI 的内容（内存映射、中断向量表、数据结构、时序约束）
   • 制动系统的 HSI 实例

6. 系统集成和测试：

   • 系统集成的步骤
   • 系统测试的类型
   • 制动系统的测试用例

7. 实战案例：

   • AEB 系统的系统级开发完整实践

核心要点：

• 系统级开发是将概念阶段的安全需求转化为具体技术实现的关键环节
• TSC 是连接概念阶段和系统级开发的桥梁
• HSR 和 SSR 必须追溯到 SSyR，SSyR 必须追溯到 FSR
• 系统架构设计必须考虑独立性、多样性和诊断性
• HSI 是硬件和软件协同工作的基础
• 充分的测试是确保系统安全的关键

在下一篇文章中，我们将深入解读 ISO 26262-5 硬件级开发部分，学习如何设计和开发安全的硬件。

延伸阅读

• ISO 26262-1: 词汇
• ISO 26262-2: 功能安全管理
• ISO 26262-3: 概念阶段
• ISO 26262-5: 硬件级开发
• ISO 26262 整体综述