4、顶层架构设计：系统上下文图、主要功能模块识别（传感器接口、执行器控制、逻辑处理、诊断）、模块间接口定义

好，我们进入第四章。这一章讲的是顶层架构设计，说白了就是先画个大框架，看看整个制动控制软件到底长什么样。

我刚开始做制动软件那会儿，上来就埋头写代码，结果写到一半发现模块之间耦合得乱七八糟。后来被一个老前辈教育了——「你连地图都没看，就敢开车上路？」嗯，从那以后，我养成了一个习惯：先画系统上下文图，再拆功能模块，最后定义接口。今天就把这套方法分享给你。

4.1 系统上下文图：先看清边界

系统上下文图，英文叫 System Context Diagram。它的作用很简单——告诉你软件系统跟外界怎么打交道。

我个人习惯用一张图把整个制动控制软件放在中间，外面画一圈「邻居」。这些邻居包括：

• 传感器：轮速传感器、制动踏板位移传感器、压力传感器、横摆角速度传感器等
• 执行器：电磁阀、电机泵、制动卡钳、液压控制单元
• 其他ECU：VCU（整车控制器）、ESC（电子稳定控制）、ADAS（高级驾驶辅助系统）
• 诊断工具：OBD接口、CANoe、上位机
• 电源管理：12V/24V供电、唤醒/休眠信号

为什么要画这个图？因为你要搞清楚：哪些东西是你的软件要管的，哪些是别人的事。边界不清，后面全是坑。

4.2 主要功能模块识别

好，边界清楚了，接下来拆模块。我一般把制动控制软件拆成四大块：传感器接口、执行器控制、逻辑处理、诊断。你想想看，这四块是不是刚好覆盖了「感知-决策-执行-监控」这条链路？

4.2.1 传感器接口模块

这个模块负责跟所有传感器打交道。它的核心职责是：

• 信号采集：把模拟信号、数字信号、PWM信号转成软件能用的数值
• 信号调理：滤波、去抖、归一化处理
• 故障检测：判断传感器是否开路、短路、信号超范围
• 数据分发：把处理好的传感器数据发给逻辑处理模块

我在项目中遇到过一个问题：轮速传感器的信号在低速时抖动特别厉害，如果不做滤波，逻辑处理模块会误判为车轮抱死。后来我们在传感器接口层加了一个自适应低通滤波器，才把这个问题解决掉。

4.2.2 执行器控制模块

这个模块是「动手」的。它接收逻辑处理模块的指令，然后驱动电磁阀、电机泵这些硬件干活。

它的主要功能包括：

• 驱动控制：PWM占空比计算、电流闭环控制、开关逻辑
• 状态监控：执行器是否响应、电流是否正常、动作时间是否超时
• 安全保护：过流保护、过温保护、看门狗喂狗
• 回读校验：执行器动作后，通过传感器回读实际状态，确认执行到位

嗯，这里要注意：执行器控制模块是跟硬件最贴近的一层，所以它的实时性要求最高。我建议把这部分代码放在中断服务函数或者高优先级任务里跑。

4.2.3 逻辑处理模块

这是整个软件的大脑。它负责：

• 状态机管理：正常制动、紧急制动、ABS介入、ESC介入、失效降级等状态切换
• 控制算法：PID控制、滑移率计算、制动力分配、防抱死逻辑
• 仲裁决策：当多个来源（驾驶员、ADAS、ESC）同时请求制动时，谁优先级更高
• 故障响应：检测到故障后，决定是降级、报警还是安全停机

逻辑处理模块最怕什么？最怕「状态爆炸」。我曾经在一个项目里看到状态机有30多个状态，互相跳转的箭头画都画不清楚。后来我强制要求：状态数量不超过10个，每个状态只做一件事。

4.2.4 诊断模块

诊断模块是「监工」。它不参与正常制动控制，但一旦出问题，它要第一时间发现并上报。

它的核心功能：

• 故障检测：传感器故障、执行器故障、通信故障、电源故障
• 故障存储：把故障码、故障时间、故障环境数据存到EEPROM或Flash里
• 故障上报：通过CAN总线把故障信息发给诊断仪或VCU
• 恢复管理：故障消失后，清除故障码或标记为历史故障

诊断模块的设计有个原则：不能因为诊断本身导致系统失效。比如，诊断模块在读写EEPROM时，不能阻塞主控制任务的执行。我一般会给诊断模块分配一个低优先级任务，让它慢慢跑。

4.3 模块间接口定义

模块拆好了，接下来要定义它们之间怎么通信。接口定义不清晰，后面联调的时候就是一场灾难。

我习惯用结构体来定义模块间的接口。举个例子：

/* 传感器接口模块输出给逻辑处理模块的数据结构 */
typedef struct {
    float wheelSpeed_FL;        // 左前轮速，单位 km/h
    float wheelSpeed_FR;        // 右前轮速
    float wheelSpeed_RL;        // 左后轮速
    float wheelSpeed_RR;        // 右后轮速
    float brakePedalPosition;   // 制动踏板位置，0~100%
    float masterCylinderPressure; // 主缸压力，单位 bar
    uint8_t sensorStatus;       // 传感器状态位，bit0=轮速故障，bit1=踏板故障...
} SensorData_t;

/* 逻辑处理模块输出给执行器控制模块的数据结构 */
typedef struct {
    float targetPressure_FL;    // 左前轮目标压力
    float targetPressure_FR;    // 右前轮目标压力
    float targetPressure_RL;    // 左后轮目标压力
    float targetPressure_RR;    // 右后轮目标压力
    uint8_t controlMode;        // 0=正常，1=ABS，2=ESC，3=失效降级
    uint8_t actuatorCmd;        // 执行器命令，bit0=增压，bit1=保压，bit2=减压
} ActuatorCmd_t;

接口定义有几个要点：

• 单向传递：尽量让数据流是单向的，避免循环依赖
• 明确所有权：每个数据结构只有一个「生产者」，其他模块都是「消费者」
• 版本控制：接口结构体变更时，要通知所有相关模块同步更新
• 预留扩展位：比如状态字里留几个bit，方便以后加功能

4.4 小结

这一章我们讲了顶层架构设计的三个步骤：

1. 画系统上下文图：搞清楚软件跟外界怎么交互
2. 拆功能模块：传感器接口、执行器控制、逻辑处理、诊断，各司其职
3. 定义接口：用结构体把模块间的数据流固定下来

说实话，顶层架构设计花的时间越多，后面写代码、联调、测试就越省心。我见过太多项目因为架构没想清楚，后期改得面目全非。所以，别急着写代码，先把架构画清楚。

下一章我们会深入逻辑处理模块，讲讲状态机和控制算法的具体设计。到时候见。