从 2023 年开始，配电网的招标文件里陆续出现“终端应具备边缘计算能力”这样的条款。三年过去，装了边缘计算模块的终端不算少，但真正把这项能力用起来的不多。原因不在技术，在于大多数人一开始就把这件事理解成“给终端加算力”，而它实际上是一个带宽与责任的问题。
这篇文章不讨论芯片型号，只算三笔账：带宽账、责任账、成本账。算完这三笔，边缘计算该不该上、上到什么程度，基本就有答案了。
一、第一笔账：不就地算，数据根本传不上去
配电终端的原始数据量，比很多人以为的大得多。一台 DTU 按每周波 80 点采样三相电压三相电流，就是 6 个通道、每秒 4000 个采样点。哪怕只做有效值计算，中间过程的瞬时值也是要过的。
假设一个最保守的场景：不做波形上传，只按 100ms 一次上传三相电流电压的有效值（约 60 字节一帧）。一条线路 100 台终端：
单台：10 帧/s × 60 B = 600 B/s
全线：600 B/s × 100 台 = 60 000 B/s ≈ 60 KB/s
每天：60 KB/s × 86 400 s ≈ 5.2 GB
一年：约 1.9 TB
1.9TB 是什么概念？按 4G 物联网卡 1GB/月的套餐算，这个量级完全不可能。就算走光纤专网，主站侧的存储与实时库压力也会被这个数据量压垮。所以“把数据都传上去，在云端算”这条路，从带宽上就被堵死了。
反过来，如果终端就地算出 15 分钟统计值（有效值、最大值、最小值、谐波含量、不平衡度，约 200 字节一帧）：
单台：96 帧/天 × 200 B = 19.2 KB/天
全线：19.2 KB × 100 台 = 1.92 MB/天
一年：约 700 MB
从 1.9TB 降到 700MB，降了三个数量级。所以边缘计算在这件事上的第一个价值，不是“算得快”，是“把带宽问题变成了算力问题”。这也是它最扎实、最没有争议的用途。
二、第二笔账：断网之后，终端还能不能干活
配电终端装在杆上、箱变里、开闭所，通信条件并不好。光纤到不了的地方用 4G，4G 信号弱的地方用中压载波，山区还有靠北斗短报文的。这些通道的共同特点是：会断，而且断的时候往往正是故障的时候。
集中式馈线自动化的逻辑在主站：终端上报故障信号，主站判断故障区段，下发遥控命令。这个链路在通信正常时很好用，通信一断就完全失效——故障还在，主站看不见，终端不敢动，最后还是要靠人。
智能分布式 FA 把判断下放到终端之间：相邻终端通过光纤或对等通信交换故障方向信息，各自判断自己是否在故障区段内，直接跳闸。这个过程不需要主站参与，通信中断也不影响，因为终端之间是点对点直连的。
这才是边缘计算在配电里最有价值的用法——不是“就地做数据分析”，是“就地做决定”。判断逻辑不复杂（故障方向、过流标志、时限配合），算力需求很低，但对可靠性的价值很高：故障隔离时间从分钟级压到秒级，且不依赖主站和通道。
三种模式没有优劣，只有匹配。真正的问题是很多项目在招标时要求“具备分布式 FA 功能”，实际只配了单向通信通道，功能永远开不起来。
三、第三笔账：就地跳闸的责任归谁
这是最少被讨论、但最影响落地的一条。
集中式 FA 里，跳闸命令是主站发的，主站有调度值班员、有录音、有操作票。责任链清楚。智能分布式 FA 里，跳闸是终端自己判的，两台终端在 1 秒内完成信息交换并动作，事后追责时，你面对的是两台设备的日志，没有人签过字。
于是就出现一种很典型的僵局：技术上做得到，管理上不敢用。很多装了分布式 FA 的项目，功能调试完就退出运行，只留集中式。这不是保守，是责任边界没定。
要破这个局，需要三样东西，而且都不是技术：
- 动作逻辑要写入运行规程，明确什么条件下终端可以自己跳闸，谁批准投入。
- 终端要有完整的动作记录（故障前 5 个周波到故障后 10 个周波的录波、判据中间量、通信报文时间戳），能复盘。
- 要有退出机制：一旦出现误动，能在不改变定值的前提下快速退出该功能，而不是整条线退运。
这三样东西做到了，边缘计算才从“演示功能”变成“运行功能”。做不到，它就只是个演示。
四、成本账：三万块的投入，换回什么
按一条 100 台终端的线路算，加装边缘计算模块（更高算力的主控、更大存储、容器化运行环境），单台增量成本按 300 元估，总额 3 万元。加上调试与算法部署的人工，按 20 人天、每人天 800 元算，1.6 万元。合计约 4.6 万元。
收益侧很难算得漂亮。省流量省不下多少钱（一年几百块的卡费），省主站存储也不值这个钱。真正的收益在故障处理：
假设这条线年故障 6 次，每次平均影响 800 户、持续 50 分钟
年停电量 ≈ 6 × 800 × 50 / 60 ≈ 4 000 户·小时
若分布式 FA 把持续时间压到 3 分钟：
年停电量 ≈ 6 × 800 × 3 / 60 = 240 户·小时
减少约 3 760 户·小时
按供电可靠性的考核口径折算，这个改善对 SAIDI 指标的贡献是可观的。但它不会变成现金，只会变成考核排名和用户投诉量的下降。所以在纯财务口径下，边缘计算的投资回收期算不出来；在可靠性口径下，它是划算的。
这也是为什么这类投入总是“该做但难推”——付钱的人和受益的人不是同一个。
五、三个绕不过去的现实约束
1. 功耗与散热
柱上终端的供电预算很紧：PT 取电或太阳能加蓄电池，整机功耗要控制在 10W 量级。加算力意味着加功耗，而柱上控制箱在夏天箱内温度能到 65℃ 以上，工业级芯片的余量也不宽裕。所以“把服务器搬到杆上”这个思路在配电里走不通，只能做轻量化。
2. 算法与固件的运维
一台终端的算法升级是小事，一千台就是工程。版本管理、灰度发布、升级失败回滚、升级过程中的保护退出——这些能力比算法本身更难做。见过不少项目，算法在实验室跑得很好，现场部署时因为版本不一致，同一个故障在两种终端上判出两种结果。
3. 安全
终端能就地跳闸，意味着它是一个有物理动作能力的网络节点。一旦被入侵，后果不是数据泄露，是停电。所以远程升级通道、调试口、通信加密这三块的安全设计，必须和功能一起做，不能事后补。
六、如果现在要上，价值排序应该是这样
这个排序和很多宣传材料的排序恰好相反。宣传里讲得最多的是最下面那一行，因为它听起来最先进；实际落地最多的是最上面那一行，因为它最省钱。
七、结语
边缘计算在配电自动化里不是一个新概念，它只是把一件本来就该在本地做的事，重新说了一遍。终端的本职工作从来都是“就地采集、就地判断、就地动作”，只是过去算力不够，很多判断被推到主站去了。现在算力够了，把它推回来而已。
所以判断一个项目该不该上边缘计算，不用问“我们的算力够不够”，问三个更朴素的问题：数据传得上去吗？通道断了还能干活吗？终端自己跳了闸，谁签字？
三个问题里有两个答不上来，那这项投入大概率会变成一个演示功能。三个都答得上来，它才真的开始产生价值。
