第三章 PCS软件架构设计原则：分层架构、模块化设计、接口隔离原则、高内聚低耦合

各位工程师朋友，咱们今天聊点实在的。PCS软件架构，说白了就是一套「怎么把代码组织好」的规矩。我做了十几年工控系统，见过太多项目因为架构混乱，最后改一个bug要动全身，那叫一个痛苦。今天我把几个核心原则掰开揉碎了讲，你听完就能用上。

3.1 分层架构：别让所有代码挤在一起

先说说分层。我习惯把PCS软件分成三层：驱动层、逻辑层、应用层。为什么这么分？你想想看，如果所有代码都混在一个文件里，改个IO口映射，结果把PID算法也搞崩了，这种事我见过不止一次。

举个例子，驱动层负责读写硬件寄存器，逻辑层做控制算法，应用层处理人机交互。我在一个化工项目中，现场传感器换了型号，驱动层改了几行代码，上层完全没动。这就是分层的好处。

这里我画了一张分层架构的示意图，你看一眼就明白了：

3.2 模块化设计：把大问题拆成小零件

模块化，说白了就是「分而治之」。一个PCS系统可能有几百个控制回路，你不可能写一个巨型函数来处理所有事。我建议按功能拆模块：温度控制模块、压力控制模块、流量控制模块……每个模块独立编译、独立测试。

来看一段简单的模块化代码示例：

// 温度控制模块 - temp_control.c
void TempControl_Init(void) {
    // 初始化PID参数
    pid_params.kp = 2.5;
    pid_params.ki = 0.1;
    pid_params.kd = 0.05;
}

float TempControl_Process(float setpoint, float feedback) {
    // 执行PID计算
    float error = setpoint - feedback;
    float output = pid_params.kp * error 
                 + pid_params.ki * integral 
                 + pid_params.kd * derivative;
    return output;
}

// 主程序只需要调用模块接口
#include "temp_control.h"
#include "pressure_control.h"

void MainLoop(void) {
    float temp_out = TempControl_Process(100.0, temp_sensor);
    float press_out = PressureControl_Process(5.0, press_sensor);
    // ...
}

3.3 接口隔离原则：别让调用者知道太多

这个原则听起来有点绕，其实很简单：你提供给别人的接口，应该只暴露必要的信息。比如一个电机控制模块，对外只提供三个函数：Init()、Start()、Stop()。至于内部是用PWM还是用变频器，调用者不需要知道。

我习惯用结构体指针来封装接口，像这样：

// 接口定义 - motor_interface.h
typedef struct {
    void (*Init)(void);
    void (*Start)(uint8_t speed);
    void (*Stop)(void);
    uint8_t (*GetStatus)(void);
} MotorInterface_t;

// 外部使用
MotorInterface_t motor = {
    .Init = Motor_Init,
    .Start = Motor_Start,
    .Stop = Motor_Stop,
    .GetStatus = Motor_GetStatus
};

motor.Init();
motor.Start(80);  // 调用者不需要知道内部实现

3.4 高内聚低耦合：让模块自己管好自己的事

这两个词是架构设计的灵魂。我解释一下：

• 高内聚：一个模块内部的代码，应该紧密围绕同一个功能。比如PID控制模块，所有代码都跟PID计算相关，别把日志打印、网络通信塞进去。
• 低耦合：模块之间的依赖关系要尽量少。A模块改了，B模块不应该受影响。

我整理了一个对比表格，你一看就明白：

设计质量	高内聚低耦合	低内聚高耦合（反面案例）
模块职责	每个模块只做一件事，且做好	一个模块既做控制，又做显示，还管通信
修改影响	改一个模块，其他模块不受影响	改一行代码，三个模块都要重新测试
测试难度	可以单独测试每个模块	必须搭好整个系统才能测试
复用性	模块可以拿到其他项目直接用	模块跟项目绑死，换个项目重写

3.5 把这些原则串起来用

好了，四个原则都讲完了。实际项目中，它们是配合使用的。我一般这样操作：

1. 先按分层架构把系统分成驱动、逻辑、应用三层
2. 每层内部按功能拆成模块（比如逻辑层拆成PID模块、联锁模块）
3. 每个模块设计接口，只暴露必要的函数
4. 检查模块内部是否高内聚，模块之间是否低耦合

你想想看，如果每个模块都遵循这些原则，改一个传感器驱动，只需要动驱动层的一个模块；加一个新的控制算法，只需要在逻辑层加一个模块。整个系统就像搭积木一样，稳定又灵活。

---

公众号:蓝海资料掘金营，微信deep3321