基于单片机的直流微网远程控制系统设计与实践

“探索基于单片机的直流微网远程控制”这个题目放在眼前，我第一反应不是某某型号的单片机，也不是用什么无线模块，而是“控制对象到底是什么”。把光伏、储能、直流负载通过同一条直流母线接起来，再用单片机去管采样、管开关、管通信，这件事真正做起来，其实把嵌入式控制、电力电子、通信协议和可靠性设计全串在了一起。它解决的实际需求很明确：分布式站点不需要人在柜前守着，运维人员在办公室甚至手机上就能看到母线电压、各支路电流、开关状态，远程下发合闸、分闸和参数修改指令。

这个课题特别适合正在做毕业设计或课程设计的同学，也适合想把手头一套光伏储能模拟装置升级成可监控系统的开发者。它不算难，但坑很密集，踩过了就明白，真正值钱的不是那几行控制代码，而是硬件抗干扰、通信超时处理、保护优先级的整套设计思路。下面按我自己的实现顺序，把这套系统从头拆到尾。

1. 先把课题拆开：直流微网、单片机、远程控制各管什么

1.1 为什么要做直流微网而不是交流微网

直流微网这个词听起来偏学术，实际上落地场景非常朴素。屋顶光伏发出来的是直流电，磷酸铁锂电池充放电本身也是直流，LED灯、USB供电设备、直流风机这类负载同样吃直流。如果非要先逆变成交流再给交流负载供电，对小型分布式系统来说，多一级逆变就多一级损耗，还要额外处理并网同步、频率相位这些复杂问题。而直流母线把光伏、储能、直流负载直接耦合同一张电网，能量只在DC/DC变换器之间流动，控制目标收敛为两个：母线电压稳定和各端口功率平衡。

从控制算法看，直流系统不用管无功功率、频率偏差、功角稳定，反馈量就是电压和电流，逻辑上简单得多。但这里有一个反直觉的认知需要先说清：直流短路比交流短路更难处理。交流电流有自然过零点，断路器断开时电弧能在过零点熄灭；直流电流没有过零，开关触头拉开后电弧持续燃烧，对继电器和断路器的直流分断能力要求非常高。所以这个课题里，远程控制做得再花哨，最后都要落到一个能在直流侧可靠分断的执行器件上。

拿一张表快速对比一下两种母线形式的特点：

设计原则因此变成：保护优先级永远排第一，远程遥控排第二。很多入门项目一上来就做手机App界面，先把控制链路跑通，回过头来才发现开关器件在直流母线下根本不敢带载通断，整个方案推倒重来。我建议开题时就把系统级保护列成一级需求。

1.2 远程控制要解决的不只是“开关能远程”

电力行业对远程监控有一套成熟叫法：遥测、遥控、遥信，再加一个遥调。对应到单片机系统里，遥测是周期性把母线电压、支路电流、电池电压、温度等模拟量传到上位机；遥控是远程下发开关合分、给定限流值或限压值；遥信是开关状态、故障告警、运行模式这类离散事件。

这三者不是并列关系，而是闭环关系：先看到遥测数据，再做出调度决策，下发遥控指令，最后用新的遥信状态确认动作生效。如果只做了“远程点一下就动一下”，那只是一个网络开关，谈不上微网控制。真正的远程控制要包含自动策略的落地，比如上位机检测到光伏出力充足、负荷较低，自动下发储能充电指令；或者收到电池SOC过低告警后，远程把负载支路切掉一段。单片机侧承接这些策略的下发和执行，但不负责策略计算。

这样一来边界就清楚了：单片机始终在本地跑采样、保护、执行，通信只是给系统加了一双远程的眼睛和一只手。网络断开、上位机下线，现场设备仍然按预设策略自动运行，本地急停和硬件保护完全不依赖远程链路。这个原则决定了后面的硬件设计、软件架构，甚至指令协议的超时处理方式。

1.3 单片机的定位：现场控制终端

单片机在这个系统里的角色，可以理解成现场终端的“管家”，它要同时盯住几个方向：采集电压电流并做换算和滤波，根据状态机结果输出继电器或MOSFET驱动信号，接收上位机指令并回执，同时处理本地按钮和故障保护。四个任务里，任何一个都不能被另外三个阻塞掉。

选型时不需要迷信高性能。这个场景的单片机资源要求其实很低：几个ADC通道、两路定时器、两路串口、十几个IO、Flash和RAM能放下通信解析和状态机就够了。真正吃资源的是通信协议栈，但如果我们用串口型通信模块，协议栈已经在模块里跑完，单片机只处理字节流。把通信负担分流出去之后，一颗便宜的主流32位单片机完全跑得动。

单片机的“本地管家”属性还带来一个推论：所有控制指令都应该有设备侧校验。收到远程合闸指令，不能直接吸合主继电器，必须先检查母线电压是否在允许范围、是否有过流告警、远程使能开关是否被拨到允许位置。校验不通过要回错误码，而不是假装执行成功。这些逻辑放在设备端比放在上位机可靠得多。

2. 硬件平台怎么做才能扛住现场环境

2.1 主控选型：资源够用比性能强更重要

主控我习惯选主流32位单片机，最好是内核带硬件除法指令的型号，做直流电压电流换算时不会在除法和浮点上浪费周期；Cortex-M0级别的入门型号也能跑，但如果是运算频繁的调度策略，会明显感觉吃力。另一个硬指标是ADC精度，12位起步，如果有独立参考电压引脚更好。

通信模块走串口型无线模块，这是整套系统抗干扰和可维护性的关键。串口型模块自带协议栈，单片机通过UART收发AT命令或透传数据，模块和单片机之间只有几根线，故障定位非常直观：拿PC串口工具单独给模块发指令，能通说明模块没问题，问题在单片机固件；反过来一样。集成度高的一体化模块虽然省面积，但出问题时分不清是协议栈、射频还是控制逻辑，调试成本反而高。

核心板和底板分离的设计也推荐保留。核心板上放单片机最小系统，底板上放电源转换、采样分压、继电器驱动、通信接口，这样单片机单独调试时不用带着强电部分，强电故障也不会直接烧掉处理器。

2.2 电压采样：分压电阻不是随便选的

直流微网的母线电压随工况浮动很大。以48V系统为例，锂电池充电时母线能到54.6V，如果保护上限不好好设计，打满余量是60V。分压计算就得按这个量程来做。设ADC参考电压为3.3V，下臂电阻R2取10kΩ，则上臂电阻：

R1 = R2 × (Vmax - 3.3V) / 3.3V = 10kΩ × 56.7 / 3.3 ≈ 172kΩ

可以用150kΩ、20kΩ、1kΩ三只串联凑出171kΩ，满量程时采样点电压约3.29V，离钳位电压还有微小的余量。如果直接照搬网上常见分压值，很可能出现量程只用了70%的情况，分辨率白白损失，或者满量程时超过3.3V烧坏ADC引脚。

采样点要并联一只3.3V稳压管做钳位，防止母线瞬时过压打坏引脚；再串一只电阻构成RC低通，电阻取1kΩ到10kΩ，电容取0.1uF时截止频率在160Hz左右，适合低频直流采样。要采集更快的动态电压跌落，电容要减小或去掉，但抗高频干扰会变差，看具体系统的动态要求取舍。

分压电阻选1%金属膜电阻起步。如果对精度要求更高，整套分压网络用0.1%精密电阻，并且在ADC前加一个单电源轨到轨运放做电压跟随。运放的作用是抬高输入阻抗、缓冲驱动能力，避免分压网络被ADC内部采样电容拉偏。

2.3 电流检测与开关执行通道的设计细节

电流采样先想清楚量程和损耗，再选方案。采样电阻方案最简单，但功率限制非常现实：10mΩ采样电阻流过10A电流，功耗是1W，贴片电阻会明显发热；30A母线再用这种方案，9W功耗直接把板子变成加热器。小电流支路（5A内）可以放心用低边采样，采样电阻串在负载低端和GND之间，运放放大后进ADC；但低边采样会把负载的地电位抬高一点，对传感器供电有影响的支路要避开这种接法。高边采样或者霍尔型电流传感器虽然贵一点，但安全性好很多，大电流母线建议直接上隔离式电流检测。

开关执行通道是整个硬件设计里最容易被低估的部分。直流母线带载分断时电弧非常厉害，普通交流继电器直接拿来用，大概率拉弧后触点烧黑。要选标注了直流额定值的继电器，并且尽量只做检修性质的分闸，不做频繁带载投切。为了降低浪涌冲击，主回路可以加预充设计：先吸合预充继电器的电阻支路给母线电容充电，母线电压抬升后再吸合主继电器。不要省这一步，它同时保护了继电器触点和电源侧电容。

驱动电路上有几个强制要求：继电器线圈两端必须反向并联续流二极管，二极管引脚尽量贴近线圈，否则关断瞬间的反电动势照样能干扰单片机；MOSFET栅极不能直接由单片机IO推，中间加光耦隔离和专用栅极驱动芯片，防止高压串进控制侧。

2.4 电源、地与硬件保护的取舍

微网设备的电源环境很差，母线电压波动、继电器吸合、电机负载启停都会在地线上砸出毛刺。电源拓扑尽量按“隔离再线性”的思路做：外部电源先过隔离DC/DC降到5V，再分别对单片机、通信模块、模拟采样各用一路LDO供电。三路供电的来源相同，但稳压和退耦独立，这样无线模块射频发射导致3.3V瞬降时，单片机不会跟着复位。

地线处理上，模拟地、数字地、功率地在PCB上分开铺铜，最后在电源负极处单点连接。通信模块和单片机之间如果距离稍远，可以在串口上加磁珠或隔离芯片；RS485场景就上真正带隔离的收发器。

输入级保护基本属于必选项：保险丝放最前面，额定电流取系统最大工作电流的1.25倍左右；极性反接保护用PMOS管方案，压降比肖特基二极管还小；母线入口并联TVS瞬态抑制管，吸收雷击浪涌和感性负载关断的尖峰。现场返修案例里，七成问题出在供电和输入端，而不是单片机逻辑。

3. 远程通信和指令协议：把“远方”变成可靠链路

3.1 通信方式先按约束条件选，不要跟风

远程通信方式的选择，需要先回答几个问题：站点离主控室多远，现场有没有局域网覆盖，数据量多大，功耗受不受限制，环境有没有金属屏蔽干扰。这四个问题直接决定选型方向。

课程设计或小范围验证，Wi-Fi是最省事的选择。具体用串口型Wi-Fi模块，单片机只管收发字节流，TCP和MQTT协议栈都在模块里跑，出了问题可以用PC工具单独验模块，边界非常清楚。如果以后要扩展到多站点，在通信层加一个数据汇聚网关，把各站点的RS485数据汇总后统一走以太网或4G，会比每台设备都插一张SIM卡划算。

功率消耗对通信方案的影响也常被忽略。Wi-Fi模块待机时电流仍有几十mA，如果系统需要靠电池长期运行，通信的功耗占比会很吓人。要么把上行数据周期拉长，要么换低功耗无线方案。这一点在选型阶段就要定好，否则硬件做完再改很痛苦。

3.2 MQTT连接参数和掉线检测机制

远程系统我优先选MQTT协议，原因很简单：发布订阅模式天然适合一对多的数据上报和指令下发，一个站点几十个数据点用Topic分开管理，上位机订阅感兴趣的主题就行，不需要维护大量TCP连接。

Topic规划要统一。比如每个站点一个根路径，下面分四类：遥测数据 /site/A/telemetry，遥控指令 /site/A/cmd，事件上报 /site/A/event，指令回执 /site/A/ack。这样上位机只订阅cmd、event、ack三个主题，telemetry按需订阅或直接接入数据库，多个站点之间不会串数据。

设备在线检测直接利用MQTT的KeepAlive机制，不要自己造一套心跳。比如设备正常上报周期是10秒一次，KeepAlive设30秒，Broker在约45秒收不到任何报文后会判定设备离线；再配合遗嘱消息，设备异常掉电时Broker立刻向订阅方发布离线事件。上位机收到离线事件后再决定要不要发告警，比等下一轮查询超时快得多。

KeepAlive不是设得越长越好。设备重启或移动到新的网络后，重新连接需要时间，如果上层平台对在线状态很敏感，Broker判定离线的时间就是告警响应时间的下限。这里要按现场网络质量的真实水平去调，不要照抄示例参数。

3.3 一份可以直接套用的指令与回执协议

指令消息设计成JSON结构，字段要稳定、可扩展。下面这份结构我用过好几轮，毕业设计或小工程都够用：

{ "version": 1, "msg_id": "2025010112000001", "type": "cmd", "target": "switch_out", "action": "set", "param": { "on": 1 }, "expire_ms": 5000 }

字段含义：msg_id是全局唯一消息ID，设备回执时原样返回，上位机靠它确认某条指令的结果；target指定控制对象；action是操作类型，set表示写参数，query表示查状态；param里是具体参数；expire_ms表示这条指令的有效期，超过这个时间设备端丢弃指令。为什么需要expire_ms？因为执行一条合闸指令前，设备可能要等待母线电压确认，如果等太久，现场工况早已变化，过期作废比盲目执行安全得多。

设备收到指令后的处理顺序是固定的：先解析JSON，校验字段完整性，检查target是否存在，检查param取值范围，再根据控制权状态决定执行或拒绝。每一步都往调试日志里写一行，比如parse ok, target=switch_out, action=set, on=1或reject: remote not enable，这样远程问题排查时能直接对上。

回执消息也是JSON，带上msg_id、执行结果、拒绝原因，以及执行后的关键状态字和母线电压电流值：

{ "msg_id": "2025010112000001", "result": "ok", "code": 0, "data": { "switch_out": 1, "bus_v": 52.3, "bus_i": 4.2 } }

指令如果走的是RS485或裸串口链路，JSON外面再套一层帧头、设备地址、长度、CRC16校验；走TCP/MQTT链路时链路层已经提供了可靠传输和校验，JSON本身足够，不需要再做一层CRC。大小写和字段名的一致性要在协议文档里锁死，我见过太多“上位机发了SwitchOn，单片机解析switch_on”导致半天查不出问题的案例。

3.4 控制权的定义：就地优先还是远程优先

“就地/远程”两组控制源同时存在时，必须定义清楚谁说了算。最稳妥的设计是在硬件上做一个“远程允许”拨码开关或跳线：拨到LOCAL时，远程指令进来直接被设备丢弃并回错误码；拨到REMOTE后，普通本地按钮失效，只有急停按钮保持直通。

急停回路要独立于单片机。我的做法是急停按钮串在接触器或断路器的分离脱扣回路上，按下后硬件直接切掉功率通路，完全不依赖固件是否卡死。这样可以保证单片机死机时，急停仍然有效。

多个上位机同时操作时，设备侧的职责只是根据msg_id回执结果，并发冲突由策略层判断。更好的做法是在回执和遥测里都带上本设备最后一条指令的生效时间，上位机上看到设备实际状态后，再决定是否覆盖。设备端不做复杂的仲裁，只做事实记录，能减少很多一致性bug。

4. 单片机端软件架构：越简单的控制逻辑越可靠

4.1 裸机状态机还是小型RTOS

这个场景我建议裸机+状态机，不上RTOS。虽然RTOS听起来高级，但十几路采样、一路通信、几个开关量，实时性要求并不苛刻，控制周期几十毫秒完全可接受。裸机状态机代码路径清晰、好调试，不需要考虑任务优先级反转、信号量超时这些额外复杂度。

程序结构用一个时基调度表维护。SysTick中断里每1ms置一个标志，主循环根据标志执行不同节拍的任务：1ms任务做ADC采样和快速保护判断，10ms任务做滤波和状态机扫描，100ms任务处理串口接收缓冲区和通信指令解析，1000ms任务做周期遥测上报。串口接收完全靠中断往环形缓冲区里放数据，主循环负责解析。这样哪怕Wi-Fi模块一时阻塞，采样和保护仍然按节拍运行，不会因为通信卡住而失去保护能力。

4.2 状态机设计与控制优先级

设备状态至少需要这几态：待机、本地控制、远程控制、故障、急停。状态定义和迁移条件要提前写清楚：

控制优先级从高到低是：硬件急停、硬件保护、软件保护、远程指令、本地普通指令。比如在远程控制状态下，软件检测到输入电压超过上限，设备要立刻转入故障状态分断开关，而不是继续等待远程指令。状态转移里还有一个硬约束：转入故障状态时，先做分断动作再上报事件。上报通信可能失败，但分断动作不能依赖通信。

故障复位有两种方案：手动复位，或者等待故障条件消失后自动复位。微网现场我推荐手动复位为主，自动复位要加冷却时间和次数限制，否则反复故障、反复自动重合，对开关器件伤害很大。

4.3 采样定标、滤波和参数校准

ADC原始值换算成真实电压电流时，公式要按实际电阻值算，不能拿标称值硬套。母线电压换算公式：

Vbus = ADC值 × 3.3V / 4095 × (R1 + R2) / R2

这里分母写成4095是因为12位ADC满码值是4095，很多例程写成4096，细算会有0.02%左右的偏差。在要求不高的场景可以忽略，但如果要做SOC估算这类需要长期积分的数据，这一点偏差会随时间放大。

电阻标称值和实际值之间的偏差，靠软件两点校准解决。用可调电源给母线加一个接近0V的低压点，再用高精度万用表记录实际电压和ADC码，然后在接近满量程的位置再采一点，两点做线性插值得到增益和偏置系数。实测下来，1%电阻配两点校准，系统精度能到0.5%以内，对微网监控已经足够。

滤波方面，直流母线的电压信号本身比较平缓，但继电器动作带来的瞬态尖峰很容易让ADC采到坏值。我的处理是：先做一次中值滤波剔除坏点，再做一阶低通平滑。一阶低通公式：

y[n] = α × x[n] + (1 - α) × y[n-1]

α在0.2左右比较适合50Hz左右的采样率，太低会拖慢对真实电压跌落的响应。保护判断必须用滤波前的原始值，遥测上报用滤波后的平滑值，这个细节要分开。

4.4 看门狗、异常兜底和远程升级预留

独立看门狗建议开启，复位周期定在1.6秒左右比较稳。喂狗语句放到主循环最末尾，不要放在中断里。放在中断里的喂狗有一个很经典的坑：主程序死循环时中断照样触发、照样喂狗，看门狗永远不复位，异常状态就一直带着运行，比不复位更危险。

通信阻塞是喂狗最容易踩的雷。如果代码里写了同步等待Wi-Fi模块应答的逻辑，等待超时时间超过看门狗周期，程序会被看门狗咬复位。我的原则是：所有通信操作都改成非阻塞或带超时状态机，每次调用最多阻塞几十毫秒，主循环始终能转起来。

远程升级（OTA）在“远程控制”课题里是加分项。预留一片外部SPI Flash作为固件备份区，升级时先把新固件完整下载到备份区并校验CRC，再修改启动标志，重启后由Bootloader跳转到新固件；如果新固件启动后没能在规定时间内完成握手，自动回滚到旧区。这个设计能防止无线升级失败变砖。纯课程阶段不做OTA不影响主体功能，但软件架构里要把Flash区划好，免得后面想加时没有预留空间。

5. 联调实测问题与排查实录

5.1 继电器吸合瞬间单片机复位：电源先行崩溃

第一次联调遇到的现象很典型：上位机下发合闸指令，继电器“啪”一声吸合，单片机立刻黑屏重启。最初怀疑是继电器触点拉弧干扰，后来用示波器抓电源轨才看清，是吸合瞬间线圈电流远大于保持电流，驱动继电器的那路电源被瞬间拉低，MCU的VDD跌到复位门限以下。

解法分两步。硬件上，继电器供电必须和单片机供电分开，继电器用12V或24V电源，通过光耦加达林顿管驱动，线圈两端加续流二极管，驱动电源入口加足够的电解电容和TVS；单片机供电侧加LDO和储能电容，保证干扰时VDD纹波在可接受范围。软件上再补一道防线：继电器吸合后延迟一小段时间，等电源稳定了再继续执行后续动作。

排查这类问题，用示波器同时抓继电器线圈驱动信号、MCU VDD、地平面毛刺三条线，比猜原因快得多。没有示波器时，可以在故障复现时反复试，观察复位是否总发生在继电器动作的同一瞬间，基本也能锁定方向。

5.2 ADC读数漂移：硬件精度和软件校准都得动

联调时发现单片机读到的母线电压和万用表实测值对不上，而且不是固定差，是随输入电压升高的偏差越来越大。第一反应查分压电阻，用万用表一量，标称1%的电阻实际偏差超过2%，两只分压电阻一起误差叠加，读数自然偏。

重新计算实际阻值后，偏差仍然存在一点，这时怀疑到ADC参考电压。很多单片机内部参考电压并不稳定，3.3V LDO的输入电压波动会直接改变ADC满量程值。我把LDO输出引脚加了大容量储能电容和0.1uF高频旁路，再做了软件两点校准：用可调电源给一个精确的低压点和一个接近满量程的点，反推offset和gain，实测校准之后精度明显改善。

这个坑给我的教训是：采样精度问题很少只有一个原因，往往是电阻精度、参考电压、PCB走线噪声叠加的结果。排查顺序固定为：先查硬件分压实测值，再查参考电压稳定性，最后做软件校准，不要一上来就怀疑代码算法。

5.3 WiFi反复断连：别一上来就怀疑网络

Wi-Fi模块上线之后反复掉线重连，看MQTT日志是“连接丢失，正在重连”，持续几个小时都没有稳定。先把锅甩给现场网络，拿手机测了下信号很好，于是回到模块供电上查。

Wi-Fi模块发射瞬间的电流脉冲非常大，能冲到300mA甚至更高。如果供电线路长、线径细，又没有足够容量的储能电容，电流脉冲一过来电压就瞬降，模块觉得自己供电不足就重启，重启后重新连网，连上又发射，又重启，形成了一个稳定循环。解决办法是给模块单独配一路LDO，并在模块电源引脚附近就近放置大容量电容，我实测用100uF电解加0.1uF陶瓷基本打住。

如果做了这些还断，那就得抓模块串口日志，区分是command timeout还是TCP disconnect还是MQTT层断开，三个层面的排查方向完全不同。无线问题的排查顺序：电源、天线位置、射频干扰、网络环境，不要上来就改KeepAlive参数，改了也不一定对症。

5.4 指令已下发但设备不动：从回执链路找问题

联调中最磨人的问题是：上位机界面显示指令发送成功，但设备没有任何反应。MqTT的QoS机制只能保证消息到了Broker，保证不了设备正确解析。我先在设备串口上打印收到的原始payload，发现设备压根没收到这条消息，于是查Topic——上位机发的主题是/site/a/cmd，设备订阅的是/site/A/cmd，大小写一差，全部消息被过滤掉。

修改统一小写之后，设备能收到消息但仍然不执行，继续看日志发现JSON解析失败。上位机发送的param字段里数值是整数，设备端代码按浮点数解析，类型不匹配就返回解析错误。这类问题在协议联调里太常见了，所以协议文档里要明确每个字段的类型和取值范围，设备端解析失败的日志必须带错误码，帮助两端快速对齐。

这里最有效的工具是设备上的调试串口和上位机消息日志一起打开，两头对时间戳。不要一上来就怀疑代码逻辑，先确认消息是否到达、解析是否通过、控制权是否允许执行。

5.5 多设备状态不同步：设备端要能做状态仲裁

一套系统里挂了几台设备后，发现上位机显示的开关状态偶尔和现场不一致，尤其是设备重启之后，上位机还保持着重启前的旧状态。

核心原则是设备状态以设备侧为准，上位机缓存永远可能过期。设备上电初始化完成后，必须主动上报一次全量状态，让上位机覆盖本地缓存；任何自发状态变化（比如保护动作导致开关断开）都要主动发布事件，不能等上位机来查询；远程指令执行后的回执要在100ms内发出，并在回执里带上最新的状态字。三个动作做到，状态不一致的概率会明显下降。

还有一个细节：设备要区分“指令执行成功”和“指令已经收到但执行失败”，回执里的result字段要能表达拒绝原因，不能让上位机把拒正当成成功。

整套系统做下来，我最深的体会是：远程控制项目的难度其实不在“远程”，而在“本地稳不稳”。通信链路随时可能抖动，上位机策略也可能写错，但只要设备端的保护逻辑、状态机、控制权设计够硬，远程出问题时就只是“暂时无法操作”，而不是“设备失控”。这套框架跑顺以后，往上加能量调度、策略下发，都只是往参数表里填内容的问题，主干不需要再动。