系统架构基础：架构的定义、设计原则与安全的关系
各位同学好，今天我们聊聊系统架构的基础。说实话，我在功能安全领域摸爬滚打了十几年，见过太多因为架构设计不合理导致项目返工的案例。架构这东西，说白了就是系统的骨架——骨架歪了，后面再怎么填肉也长不成个人样。
一、什么是系统架构？
系统架构，我习惯把它定义为：系统的结构、行为以及各要素之间的关系描述。它回答三个问题：系统由哪些部分组成？这些部分怎么交互？交互的规则是什么？
举个例子，你设计一个自动驾驶的感知系统。架构就要明确：摄像头模块、雷达模块、融合模块、决策模块各自负责什么，数据怎么流，接口怎么定义。嗯，这里要注意，架构不是代码，不是具体实现，而是顶层设计蓝图。
核心观点：架构是系统的「宪法」，所有后续开发都要遵守它。我在项目中遇到过，团队急着赶进度，跳过架构评审直接写代码，结果三个月后模块之间接口对不上，重构成本比重新写还高。
我个人习惯用一张图来概括架构的核心要素：
二、架构设计三大原则
做架构设计这么多年，我总结出三个最核心的原则：模块化、分层、解耦。你想想看，这三个原则其实都是在解决同一个问题——控制复杂度。
2.1 模块化
模块化就是把系统拆成一个个独立的模块，每个模块有清晰的职责边界。我建议你记住一句话：高内聚、低耦合。
- 高内聚：一个模块内部的功能要紧密相关。比如「摄像头驱动模块」只做图像采集，别把图像处理也塞进去。
- 低耦合：模块之间的依赖要尽量少。改了一个模块，其他模块最好不用动。
我的经验：模块划分的粒度很关键。太粗了，一个模块改起来影响面大；太细了，接口管理成本高。我一般遵循「一个模块解决一个核心问题」的原则。曾经有个项目，把「数据采集」和「数据预处理」放在一个模块里，后来想换采集硬件，结果预处理逻辑也得重写——这就是耦合太紧的教训。
2.2 分层
分层架构，说白了就是给系统划分层级，上层依赖下层，下层为上层提供服务。最经典的就是OSI七层模型和汽车领域的AUTOSAR分层架构。
为什么要分层？我举个例子你就明白了。你开发一个ADAS系统，底层是硬件驱动，中间是算法处理，上层是应用逻辑。如果所有代码混在一起，换一个摄像头型号，整个系统都得改。分层之后，你只需要改驱动层，算法层和应用层完全不受影响。
| 层级 | 职责 | 典型内容 |
|---|---|---|
| 应用层 | 业务逻辑、决策 | 路径规划、行为决策 |
| 算法层 | 数据处理、融合 | 目标检测、传感器融合 |
| 抽象层 | 硬件抽象、接口封装 | 传感器抽象、执行器抽象 |
| 驱动层 | 硬件直接交互 | 摄像头驱动、CAN驱动 |
注意：分层不是越多越好。层数太多会导致性能损耗和调试困难。我曾经见过一个项目分了8层，结果一个数据从底层传到顶层要经过6次接口转换，延迟增加了30%。一般来说，3-5层是比较合理的范围。
2.3 解耦
解耦，就是减少模块之间的直接依赖。你想想看，如果模块A直接调用模块B的内部函数，那B一改，A就得跟着改。解耦的核心手段是定义稳定的接口。
我常用的解耦方式有几种：
- 接口抽象：定义纯虚接口类，模块之间只依赖接口，不依赖实现
- 事件驱动：模块通过发布/订阅机制通信，发送方不知道接收方是谁
- 数据驱动：模块之间通过共享数据总线交互，不直接调用
// 解耦示例：接口抽象
// 不好的设计：直接依赖具体类
class CameraModule {
void process() { /* ... */ }
};
class System {
CameraModule cam; // 强耦合
};
// 好的设计：依赖接口
class ISensor {
virtual void process() = 0;
};
class CameraModule : public ISensor {
void process() override { /* ... */ }
};
class System {
ISensor* sensor; // 松耦合，可替换为雷达、激光雷达
};三、架构与安全的关系
这部分我想重点聊聊。很多人觉得安全是测试阶段的事，其实大错特错。安全是设计出来的，不是测出来的。架构设计直接决定了系统的安全天花板。
为什么会这样？我举几个实际例子：
- 隔离性：如果安全关键功能和非安全功能混在一个模块里，非安全模块出问题就可能拖垮安全功能。架构上必须做隔离——比如把ASIL D的功能单独放在一个安全岛中。
- 冗余设计：单点故障是安全的大敌。架构上要设计冗余路径，比如感知系统同时使用摄像头和雷达，互为备份。
- 故障响应：架构要定义故障时的降级策略。比如转向系统失效时，如何安全地切换到备用模式？这需要在架构层面预留接口和状态机。
关键认知：架构设计决定了系统能承受多大的故障。好的架构，一个模块挂了，系统还能安全降级运行；差的架构，一个小bug就能让整个系统瘫痪。我曾经参与过一个项目，因为架构上没有做电源域隔离，一个非安全模块的短路直接导致安全控制器掉电——这就是架构层面的安全漏洞。
在预期功能安全（SOTIF）中，架构设计还要考虑未知场景。比如自动驾驶系统遇到从未训练过的场景，架构上要有「安全兜底」机制——说白了就是当系统不确定时，自动切换到保守模式。
我个人习惯在架构设计阶段就做安全分析：
- 用FMEA分析每个模块可能的失效模式
- 用FTA分析系统级故障的根因
- 用STPA分析控制交互中的不安全行为
这些分析结果直接反馈到架构设计中，该加冗余的加冗余，该做隔离的做隔离。嗯，这里要强调一点：安全分析不是一次性的，架构迭代一次，安全分析就要跟着更新一次。
避坑指南：我曾经犯过一个错误——在架构设计时只考虑了「正常情况」，没考虑「异常情况」。结果系统在传感器数据丢失时，决策模块直接崩溃了。后来我在架构中增加了「健康监控层」，专门负责检测各模块状态，发现异常就触发降级。这个教训让我养成了一个习惯：设计架构时，先想「如果这个模块坏了怎么办」。
最后总结一下：架构是系统的骨架，模块化、分层、解耦是搭建骨架的三大原则，而安全则是骨架必须承受的载荷。没有好的架构，安全就是空中楼阁。你想想看，一栋楼的地基都没打好，装修得再漂亮有什么用？
公众号:蓝海资料掘金营，微信deep3321