3、系统架构基础：系统架构的定义与层次、架构设计原则、架构与安全的关系、架构分析方法简介

大家好，我是老张。今天咱们聊聊系统架构基础。说实话，很多做功能安全的朋友，一上来就扎进HARA分析里，结果发现分析到一半，连系统到底长什么样都没搞清楚。我见过太多这样的案例了——分析结果要么漏项，要么重复，最后评审会上被怼得哑口无言。

为什么会这样？说白了，HARA分析不是凭空想象的。你得先知道系统是怎么搭起来的，才能知道哪里会出问题。所以今天这一章，我带你打好这个基础。

3.1 系统架构的定义与层次

先问个问题：什么是系统架构？

我个人习惯这样定义：系统架构是系统的骨架和血脉。骨架决定了系统由哪些部件组成，血脉决定了这些部件之间怎么通信、怎么协作。

在功能安全领域，我们通常把系统架构分成三个层次：

• 系统级架构：这是最高层。它描述整个系统由哪些子系统组成，子系统之间怎么交互。比如一个自动驾驶系统，包含感知子系统、决策子系统、执行子系统。
• 子系统级架构：往下拆一层。每个子系统内部又由哪些模块组成。比如感知子系统里，有摄像头模块、雷达模块、融合模块。
• 组件级架构：这是最底层。描述具体的硬件或软件组件，比如一个MCU、一个传感器、一段算法代码。

我记得有一次做ADAS项目的HARA分析，团队花了两周时间，结果发现分析范围错了——他们把子系统级当成了系统级，漏掉了好几个关键交互场景。嗯，从那以后，我要求团队必须先画出三层架构图，再开始分析。

3.2 架构设计原则

架构设计不是拍脑袋。我总结了几个核心原则，你在做HARA分析前一定要心里有数：

1. 模块化原则：每个模块职责单一，接口清晰。说白了，就是"各司其职"。这样做HARA分析时，你能清楚地知道每个模块可能出什么故障。
2. 分层原则：上层依赖下层，下层不依赖上层。这能帮你理清故障传播路径。我曾经遇到一个项目，因为分层没做好，一个传感器故障直接导致了整个系统崩溃——这就是典型的"牵一发而动全身"。
3. 冗余原则：关键功能要有备份。这是功能安全的老本行。比如制动系统，通常会有两套独立的制动回路。
4. 隔离原则：故障不能随意传播。你想想看，如果电源模块短路了，结果把整个控制器的电都拉没了，那还怎么玩？

3.3 架构与安全的关系

架构和安全是什么关系？我打个比方你就明白了。

系统架构就像一栋楼的承重结构，功能安全就是这栋楼的消防系统。承重结构设计得不好，消防系统再牛也白搭。反过来，消防系统的设计也会影响承重结构——比如你得预留消防通道的位置。

具体来说，架构和安全的关系体现在三个方面：

• 架构决定了安全机制的部署位置：比如故障检测模块放在哪里？冗余通道怎么走？这些都得在架构层面定下来。
• 架构影响故障传播路径：模块之间的耦合度越高，故障传播得越快。我在项目中遇到过，一个简单的通信故障，因为架构设计不合理，最后演变成了系统级的安全事故。
• 架构决定了安全分析的复杂度：架构越复杂，HARA分析的工作量越大。你想想看，一个模块化清晰的架构，分析起来多轻松？

3.4 架构分析方法简介

好了，前面讲了架构是什么、怎么设计、和安全的关系。那具体怎么分析架构呢？我介绍几种常用的方法：

方法名称	适用场景	我的评价
架构框图分析	系统级、子系统级	最基础的方法，但容易漏掉细节
数据流分析	数据密集型系统	能帮你理清数据依赖关系
故障树分析（FTA）	安全关键系统	从顶向下，适合找根因
失效模式与影响分析（FMEA）	组件级	从底向上，适合找故障模式

我个人习惯这样用：先画架构框图，把系统结构搞清楚。然后做数据流分析，看看数据怎么走。最后根据安全目标，选择FTA或FMEA做深入分析。

举个例子，我之前做的一个线控制动项目：

1. 先画出系统级架构框图
   - 制动踏板模块
   - 控制器模块
   - 执行器模块
   - 电源模块

2. 做数据流分析
   - 踏板信号 -> 控制器 -> 执行器
   - 电源 -> 控制器 -> 执行器

3. 针对"制动失效"这个安全目标
   - 用FTA分析根因
   - 用FMEA分析每个组件的故障模式

好了，这一章的内容就到这里。下一章我们开始正式进入HARA分析的核心流程。到时候我会结合一个实际案例，带你一步步走完整个过程。嗯，期待一下。