前言
大家好，我是wacky。上一篇我们聊了PLC扫描周期，PLC凭什么能做到确定性响应，答案藏在"读、算、写"的三步循环里。前两期概念篇聊的都是"时间维度"的东西——实时性和扫描周期。这一期换个角度，聊一个更基础但很多人模糊的概念：下位机和固件。
为什么聊这个？因为我发现很多从纯软件开发转过来的.NET同行，对"下位机"这个词的理解是模糊的。知道PLC是下位机，但单片机算不算？传感器算不算？固件和软件到底什么区别？为什么有时候PLC升级了固件，你的上位机通信代码就突然报错了？
这些问题看起来基础，但如果你搞不清楚，在现场调试时就会被弄得一头雾水——明明代码没改，怎么突然通信不上了？答案可能就藏在下位机的一次固件升级里。
什么是下位机
工控系统里有一个经典的上下结构：上位机在上，下位机在下。上位机是你写的.NET程序跑在PC上，负责管理、监控、存储、展示。下位机是直接和物理设备打交道的那个"东西"，负责执行控制逻辑、采集传感器数据、驱动执行器。
但"下位机"这个词的范围比很多人想象的要宽。它不是特指某一种设备，而是一个角色：只要它是"被上位机管理的、直接控制硬件的"，就是下位机。
最常见的下位机是PLC。你的上位机通过Modbus或OPC UA和PLC通信，PLC控制电机、阀门、加热器。这便是最典型的上下位机架构。汇川EVO系列PLC就是这个角色，你的.NET程序是上位机，汇川PLC是下位机。
但下位机不止PLC。单片机也可以是下位机——很多低成本场景下，不用PLC，直接用STM32之类的MCU做控制核心，上位机通过串口或TCP和它通信。甚至某些智能传感器自身带通信接口，可以直接和上位机对接，这时候传感器本身就是下位机。
还有一种常见的下位机是运动控制器。它和PLC类似，但专门做运动控制，控制伺服电机的位置、速度、扭矩。汇川的EVO系列就集成了运动控制功能，既可以做逻辑控制也可以做运动控制，这时候它既是PLC也是运动控制器。
所以判断一个设备是不是"下位机"，不要看它叫什么名字，要看它在系统架构里的角色。如果它直接控制硬件、被你的上位机管理，那它就是下位机。
下位机和上位机的边界在哪
这个问题看似简单，实际项目里经常模糊。哪些活该下位机干，哪些活该上位机干？
原则很清晰：涉及实时控制的归下位机，涉及信息管理的归上位机。
"温度超过80度就关加热器"——这是实时控制，必须PLC干。因为从传感器读到80度到输出"关闭"信号，必须在毫秒级完成。如果交给上位机，网络一抖动就可能晚几百毫秒，加热器多烧那一会儿可能就出事了。
"记录今天产线生产了多少件产品，生成Excel报表"——这是信息管理，归上位机。PLC只负责计件（每个产品经过时计数器加1），上位机负责把计数器的值读过来、存到数据库、生成报表。
但有些功能落在灰色地带。比如"温度超过80度时发一条报警短信给车间主任"，那么报警判断该谁做？
如果只是"温度>80就报警"，PLC做很简单：一个比较指令加一个输出位。但发短信涉及网络通信、短信网关调用、重试逻辑，这些PLC做不了（或者说做起来很别扭）。所以正确的做法是：PLC负责判断"温度是否超标"并置一个报警标志位，上位机负责读这个标志位，然后发短信、记日志、弹窗提示。
这个分工的本质是：PLC擅长确定性的、重复性的、实时性要求高的控制逻辑；上位机擅长复杂的、灵活的、需要交互的信息处理。越靠近物理设备的功能越往下放，越靠近人的功能越往上放。
固件是什么
聊完下位机，再聊固件。这个词可能是从纯软件开发转工控的人最容易困惑的概念。
固件（Firmware）是写在硬件设备里的程序。它不是跑在操作系统上的应用软件，而是直接控制硬件底层运行的代码，烧录在设备的Flash存储器里。
打个比方。你的电脑上跑Windows，Windows是操作系统。你在Windows上装了Chrome，Chrome是应用软件。而固件相当于电脑的BIOS——它比操作系统更底层，负责在硬件和软件之间做桥接。
对PLC来说，固件就是PLC的"操作系统+运行时"。汇川EVO系列PLC里跑的固件，负责管理PLC的硬件资源（CPU、内存、IO模块）、执行你写的LD(梯形图)/ST程序、处理通信协议栈（Modbus、OPC UA）、维护扫描周期。你用iFA Evolution软件平台写的PLC程序，最终是被PLC固件解释执行的。
固件和你的.NET上位机程序有几个本质区别：
第一，运行环境不同。.NET程序跑在Windows/Linux的通用操作系统上，有进程管理、有内存保护、有.NET运行时。固件跑在设备的嵌入式系统上，通常没有完整的操作系统（或者只有RTOS），直接和硬件打交道。
第二，更新方式不同。你的.NET程序改了代码，重新编译发布就行，一秒钟的事。固件更新叫"烧录"或"刷机"，需要通过专用工具或软件把固件镜像写入设备的Flash，过程更复杂，而且有风险。如果刷到一半断电了，设备可能就变砖了。
第三，稳定性要求不同。你的上位机程序崩了大不了重启，最多丢几秒钟数据。固件崩了意味着整个设备停摆……PLC固件崩溃，整条产线停机。所以固件的测试和发布比应用软件严格得多，版本更新频率也低得多。一般不是几个月一次，可能是几年一次。
为什么上位机开发者要关心固件版本
这是最实际的问题——固件跟你写.NET上位机有什么关系？
关系大了。最常见的是通信协议兼容性。PLC的通信协议栈是固件实现的：Modbus TCP怎么响应、OPC UA的节点地址格式、数据类型编码方式，这些都是固件说了算。如果PLC升级了固件，新固件可能改了某些行为：比如OPC UA的节点命名空间从ns=4变成了ns=3，或者某个参数解析形式改变。
你的上位机代码没改，但PLC固件改了，通信就突然报错。这种bug在现场调试时极其折磨人。因为你会下意识地查自己的代码："我代码没动啊，昨天还好好的，怎么今天就通信不上了？"直到你去问现场工程师"PLC最近动过没有"，才知道昨晚有人升级了PLC固件。
所以一个良好的习惯是：上位机程序里记录PLC的固件版本号，启动时先读取固件版本，如果版本不匹配就给出警告。很多PLC通过OPC UA或系统寄存器可以读到固件版本信息。汇川EVO系列PLC在iFA Evolution软件平台里可以查看当前固件版本，OPC UA的Server节点下也有版本信息。
第二个常见问题是功能差异。新固件可能加了新功能，比如新增了一个OPC UA的方法节点，或者Modbus支持了新的功能码。老固件没有这些功能，你的代码调用了就会报错。反过来，新固件可能废弃了某些旧功能，你原来用的某个寄存器地址在新固件里被移到了别的地方。所以每次PLC固件升级后，上位机程序需要做回归测试，确认通信和功能都正常。
第三个问题是性能变化。固件升级可能影响扫描周期：新固件优化了某些算法，扫描周期变短了；也可能加了新功能，扫描周期变长了。你在上一篇学到的"轮询周期≥2倍PLC扫描周期"的规则就受影响，如果新固件的扫描周期变了，你的轮询频率可能需要跟着调。
一个真实的使用场景
最后讲一个真实的场景，串起前面所有的概念。这里我们以汇川的iFA Evolution为例子。
1、我们在iFA Evolution中新建一个项目，并添加一个EVO 523系列的PLC
这里我们可以看到，它的右侧存在一个"版本"的概念，这个版本实际上就对应了不同的软件功能，以及不同的固件，二者缺一不可。
2、在我们选择了V1.7版本之后，就在软件中增加了一个PLC，这时候iFA Evolution支持把配置的参数以及编写的PLC程序下载到实际的PLC物理设备中，那么，如果实际的物理设备对应的固件与V1.7版本不一致，会发生什么？
直接提示固件版本不一致，或者下载后PLC宕机无法运行。
回到我们上面提到的上位机和固件两个概念中去，如果固件发生了变化，那么我们的上位机程序也必须跟着变化。类似于我们开发Web系统，后端接口发生了变化，那么前端调用接口的函数名或者参数也需要跟着一起变化，否则程序就会出错。
后记
下位机和固件是上位机开发者的"另一半"——你不直接写它们的代码，但你必须理解它们的运行机制。下位机决定了你能读到什么数据、什么时候读到、数据是什么格式。固件决定了下位机的通信行为和能力边界。理解了这两层，你在现场调试时就不是只会查自己代码的"瞎子"，而是能从全局视角定位问题的工程师。
各位看官还有其他什么基础概念想要了解的？可以在评论区进行讨论，我们可以作为后续的科普话题。
至于下一篇，我们先聊聊SCADA、MES、ERP的边界——这三个系统经常被混为一谈，但它们各自负责的业务领域其实泾渭分明。诸君共勉。
本文首发于我的公众号【wacky的碎碎念】，欢迎关注追更！
浙公网安备 33010602011771号