一条汽车总装线每小时几十台整车下线背后往往是几百台PLC在各自工位上以几十毫秒到几秒的周期刷新着成千上万个数据点。很多人以为数据采集项目就是把PLC里的变量用上位机读出来存进数据库实际到现场走一圈就会发现真正麻烦的不是“读变量”这个动作而是搞清楚哪些数据值得采、用什么协议去读、读完之后怎么存、存下来之后怎么保证它是对的。这篇实录记录的就是我从零搭建一套汽车生产线数据采集系统的完整过程重点放在PLC与C#之间的通信架构设计、采集引擎的代码组织以及现场联调时踩过的几类坑。适合正在做上位机开发、准备接工业数采项目或者想把手里的PLC数据用起来的技术人员参考。1. 先想清楚采什么总装线、焊装线背后的数据源头1.1 生产线的三类数据工艺参数、设备状态、质量结果汽车生产线通常分成冲压、焊装、涂装、总装四大工艺区每一段的数据特征完全不一样。焊装线机器人工作站里的PLC主要存焊接参数和机器人状态比如焊接电流、电压、报警代码、节拍时间涂装车间更在意烘房温度、槽液温度、喷房湿度这些连续变化的模拟量总装线则大量涉及拧紧枪扭矩、检测设备的测量结果、输送线的到位信号和防错信号。站在数据采集系统的角度看这些点位可以归成三类第一类是工艺参数决定“这台车是怎么做出来的”第二类是设备状态决定“设备和产线运行得顺不顺”第三类是质量结果决定“这台车能不能合格流转到下一工位”。三类数据的用途不同采集周期和存储策略也不同。工艺参数通常要求高频率记录尤其是扭矩、压力这种瞬态量几秒一条甚至更密都不嫌多设备状态可以放慢到30秒甚至1分钟一条质量结果则必须和车型、VIN码、工位、时间戳绑定方便后续追溯。1.2 点位从哪来和电气工程师一起“过点表”点位是整个系统的地基点位定义错了后面协议写得再漂亮也没用。我的做法是开工第一天就找电气工程师要两份东西一份是PLC程序里的符号表或变量表另一份是电气原理图里的I/O清单。这两份材料往往对不上因为变量表里很多中间变量是程序内部用的和物理信号没有直接关系I/O清单则只有硬接线点不含程序算出来的结果。所以第一步不是写代码而是拉着电气工程师把所有工位过一遍逐条确认点位含义、数据类型、访问路径和采集用途。真实场景中一张点表长这样所属工位变量名数据类型访问地址采集周期用途分类总装-拧紧机1号轴Tighten_TorqueREALDB10.DBD4100ms工艺参数总装-输送线Conveyor_RunBOOLI0.01s设备状态焊装-机器人3#Weld_CurrentINTMW10500ms工艺参数涂装-烘房Oven_TempREALDB20.DBD1210s工艺参数总装-检测台Leak_ResultBOOLM10.5事件触发质量结果这张表后期会成为程序里配置文件的母版。我见过很多项目跳过这一步上来就“把DB块全读回来”结果数据量爆炸、字段含义不明、业务部门根本不知道怎么用。点位表看起来是文档工作实际上决定了整个系统能不能交付。1.3 采全量还是采必要两个原则“PLC里有的变量我都想要”是需求方最常说的话但全量采集在工业现场往往是一个陷阱。真实PLC里会有大量中间运算变量、临时缓存、定时器计数器状态这些变量变化极快、语义不稳定采回来既占用网络带宽和数据库空间又很难解释。我给自己定过两条原则一条是“看得到结果的就不要采过程”比如拧紧机已经给出了最终扭矩值就没必要去采它内部逐步逼近的中间值另一条是“能被数据库算出来的就不要采原始值”比如设备OEE需要的是运行时间、故障时间、节拍数这些原料让程序在入库时计算就好而不是在PLC里拼命堆累积量。点位表最终控制在必要范围后系统负担会小一个量级。一条两三百个工位的总装线真正值得采的点位通常在几千个而不是几万个。把点位数压下来后面的通信压力、存储压力和运维压力都会明显降低。2. 通信链路怎么做先定协议再谈“对话”2.1 常见PLC通信方式的适用边界PLC和C#之间的“对话”不是像调用本地函数那样直接中间要经过工业通信协议。目前现场最常见的几种方式各有各的适用范围。第一类是公开的纯工业以太网协议比如Modbus TCP。它最大的优势是跨品牌、跨设备通用几乎所有PLC和仪表都支持报文结构公开透明用C#实现起来不复杂。缺点是数据模型比较简单基本围绕线圈和寄存器展开碰上PLC里的DB块、字符串、时间类型数据时映射起来比较绕需要自己拼偏移地址。第二类是部分PLC自带的私有以太网协议功能通常比Modbus TCP强支持按符号名寻址、支持复杂数据类型、还能一次读一大批连续数据报文效率高。缺点是只能针对单一品牌设备换了厂商协议就作废了而且协议文档不一定对外完全公开开发起来多少有些摸黑。第三类是OPC UA这种统一架构协议。它相当于在设备和上层软件之间加了一层语义丰富的“翻译层”把各家PLC的差异屏蔽掉数据类型、对象模型、订阅推送都做得很好。问题在于老一代PLC往往没有原生OPC UA能力需要加网关或中间转换软件整体链路变长调试成本也不低。2.2 我的选择主协议辅助协议的组合方案这套系统面对的设备比较杂既有支持私有以太网协议的PLC也有一些老设备只有Modbus TCP接口。我最终没有押注单一协议而是采用了“主协议辅助协议”的组合对数量占多数的同品牌PLC用它们的以太网协议做采集性能高、能按符号名读对老设备、仪表和其他品牌设备统一走Modbus TCP。上层对这两种协议封装了同一个接口采集任务根本不用关心底层是哪种协议只要拿到点位表和访问路径就能发起读取。这里有一个设计细节值得展开不要把协议解析代码和点位配置混在一起。我在项目里定义了一个抽象层里面只有“连接”“读点位”“批量读”三个动作具体协议实现全部放在独立的类中。点表配的地址是类似“DB20.DBD12”或者“4x0001”这样的逻辑描述由各协议实现自己解析。这样以后新增第三种协议比如换成支持OPC UA的网关只需要再写一个类采集引擎本身一行不改。2.3 网络规划三件套网段隔离、固定IP、访问白名单协议选好了物理网络也经常出幺蛾子。工业现场的网络环境和办公室完全两个世界交换机可能是用了十年的百兆设备网线走线跟着桥架绕来绕去电磁干扰也不可忽略。我做网络规划时固定了三件事。第一件是单独划一个数采管理网段把PLC、网关、数采服务器放在同一个二层网络里和生产管理网、办公网隔离开。这样既不干扰现场设备的调试网段也避免办公网的大流量把PLC通信拖垮。第二件是给所有设备固定IP并且IP物理位置要和工位编号有对应关系。比如总装1号工位PLC定义为192.168.20.112号工位192.168.20.12看到IP就知道是哪个区域哪台设备排查问题速度快很多。第三件是端口和访问白名单。数采服务器到PLC只放开需要的端口反过来PLC侧不需要访问服务器所以服务器上不开任何入站服务。整个数采网络的访问关系尽量做成单向PLC是数据源服务器是消费方这样即使上层网络被攻破也不至于直接进到PLC控制网。3. C#采集引擎的骨架轮询节奏、队列缓冲和批量入库3.1 采集引擎的分层设计C#采集引擎我习惯分成四层连接层、调度层、数据管道层、存储层。连接层负责维护PLC连接对象包括建立连接、断线检测、自动重连调度层按照点位表的采集周期生成任务决定什么时刻去读哪些点位数据管道层把读到的原始数据做解析、加时间戳、统一成中间模型再交给存储层存储层负责批量写入数据库。这样分层的核心原因是让每一层都能独立测试。连接层可以单独写个控制台程序测重连调度层可以脱离真实PLC用一个模拟数据源验证节奏存储层则用生产环境的数据库表结构做压测。如果所有逻辑揉在一起出问题的时候根本分不清是通信不稳还是入库太慢。3.2 连接管理和调度一个简单的连接对象在C#里实现一个PLC连接对象核心是要保证“并发读同一个连接”是有序的。很多PLC的通信接口同一时间只能处理一个请求多个线程同时对同一个连接发读请求轻则超时重则直接把PLC的通信处理器搞死。所以连接对象内部必须有一个锁。public class PlcConnection { private readonly object _syncRoot new object(); private bool _connected; public bool Connect(string ip, int port) { lock (_syncRoot) { // 建立TCP连接、协议握手 _connected true; return _connected; } } public ReadResult Read(PointAddress address) { lock (_syncRoot) { if (!_connected) return ReadResult.Failed(连接不可用); // 发送读取请求等待响应带超时控制 // 解析返回值并附带时间戳 } } }调度层做的事情更像一个节拍器。每个工位有一批点位和自己的采集周期调度器把这些点位按周期分组比如100ms一组、500ms一组、1s一组然后用定时器依次触发。这里不建议用一个线程无限循环去Sleep而是用System.Threading.Timer或者更直观的Channel配合异步任务按周期批量读取避免周期叠加后线程数失控。3.3 队列缓冲和背压处理数据管道层最容易被忽略的问题是“背压”。当PLC通信慢、数据库写入慢或者网络瞬间抖动时采集端还在不停地产生数据如果直接同步写库写入失败就会导致采集循环卡死如果无限制地往内存队列塞服务器内存又会涨上去最后进程直接挂掉。我用了一个有界队列采集任务把数据扔进队列如果队列满了说明下游处理不过来这时候不是盲目丢弃而是记录积压数量并触发告警。队列采用BlockingCollection 容量按实测峰值乘两倍来设超过容量就阻塞采集线程让上游自然减速。积压告警放在生产环境里特别有价值。有一次现场反映数据库磁盘快满了存储层写入开始频繁超时幸好队列积压监控提前报了警避免了大量未入库数据悄悄丢失。这件事让我意识到采集系统不仅要保证“正常情况下不漏数”更要保证“异常情况下可知情”。3.4 数据库写入合并小事务别让磁盘成为瓶颈工业数据量看起来不大但仔细算下来很可观。假设采集2000个点位平均每秒产生200条记录一天就是1700多万条。如果每条记录都单独执行一条INSERT数据库压力非常大。我的方案是先把数据在内存里按批次积累比如每500条或者每2秒批量写入一次用SqlBulkCopy或者等效的批量插入接口吞吐量能提升一个数量级。存储选型上关系型数据库适合点位相对固定、查询条件简单的场景如果后续要做大量时序分析可以引入时序数据库。我在这套系统里用的是混合方案热数据先写入关系库的实时表定时任务再把超过一天的冷数据迁移到时序分区表。这样报表查询和归档存储各司其职不会因为一个慢查询拖垮生产库。4. 现场踩坑实录大小端、地址漂移、断线重连与性能瓶颈4.1 大小端问题一个让首版数据全乱的坑第一次联调时我读回来的整型和浮点数看起来都怪怪的比如扭矩值应该是25.8上位机读出来却是某个完全不合常理的大数。排查到最后问题出在字节序上。工业以太网协议绝大多数是按大端模式高位在前传输数据的而C#在Windows平台上处理字节序时用的是小端模式。换句话说同一个4字节的浮点数PLC和上位机理解的排列顺序刚好相反。解决方式不算复杂读取后做一次字节反转再转换public static float ReadSingleBigEndian(byte[] buffer, int offset) { byte[] bytes new byte[4]; bytes[3] buffer[offset]; bytes[2] buffer[offset 1]; bytes[1] buffer[offset 2]; bytes[0] buffer[offset 3]; return BitConverter.ToSingle(bytes, 0); }这个坑之所以值得写是因为它不是必现的。部分PLC对某些数据类型可能已经做了大小端转换或者协议封装库内部已经处理过。结果就是同一个项目里有的点位读得对、有的点位读得不对排查起来极其费劲。我的建议是联调第一天先设计一组“端点测试值”把PLC里写死一个整数1、2、3和一个浮点数1.0、2.5专门验证解析逻辑千万别拿现场的真实运行参数当验证基准。4.2 地址漂移程序一更新点表就“跑偏”第二个坑发生在PLC程序更新之后。现场电气工程师为了调整某个逻辑把程序重新下载到PLC里结果第二天数据采集系统里一大批点位全部读到无效值。初步怀疑是通信协议有问题翻日志发现很多点位返回“地址不存在”。后来一查才知道PLC程序下载后DB块内的变量顺序或偏移发生了变化旧点位表里的物理地址已经对不上新程序了。这个问题在本地方案里非常常见。规避办法有两个层面一是在PLC侧尽量使用符号寻址而不是绝对地址这样程序结构不变时符号名对应的地址由通信协议自动解析二是在上位机侧把点位表和PLC程序版本号绑定每次PLC程序变更后重新导出一份点表替换配置文件时登记版本号和变更时间。很多团队吃过亏之后才会老老实实维护“程序版本-点表版本”的对应关系。4.3 断线重连TCP的假连接骗了你还有一次看似通信正常但数据就是不更新的情况。上位机日志显示连接一直是ESTABLISHED状态没有任何异常但PLC侧已经因为网络波动中断了会话。这就是TCP连接的一个经典陷阱拔掉网线后操作系统不会立刻感知对端消失连接在底层看起来仍然是通的直到真正发送数据才知道已经断了。处理方式是在连接层增加应用层心跳。每隔一段时间发送一个轻量级的读取请求比如读一个固定为0的变量如果在规定时间没收到响应就把连接标记为失效并主动重连。重连要加指数退避不能失败后立即疯狂重试否则PLC和网络会被重连风暴拖垮。实际参数我常用的是连接超时3秒心跳间隔5秒重连退避从1秒开始倍增最多到60秒封顶。4.4 性能实测一轮扫描到底要多久最后说性能。很多人担心C#做工业采集会不会性能不够其实瓶颈通常不在语言而在通信模型。以我当时的实测数据一个批量读取请求从发出到拿到响应典型耗时在20到40毫秒之间。按一个PLC每轮读64个连续点位计算单连接轮询10个工位轮询周期压到200毫秒以内完全可行。真正让性能崩掉的往往是不合理的全量扫描。比如把所有点位都设成100毫秒采集调度器就会在一台PLC上同时积压大量请求每个请求都要排队等锁最终平均响应时间反而大幅上升。所以我在调度层加了一个简单约束单个PLC的总请求频率不超过它无故障响应频率的70%剩下的余量留给心跳和临时人工点读。这样系统整体稳定性和公平性都比“每个点位都要最快”好很多。5. 上线前的“最后一公里”点表核对、仿真联调与运维细节5.1 点表核对会把所有点位贴到墙上看我始终坚持在联调前开一次点表核对会参与的人包含工艺、电气、IT、质量几个角色。做法很朴素把整理好的点位表打印成A3纸贴在会议室的墙上一列一列过每一项都要回答一个问题这个数据采集之后谁来用用在哪张报表如果没人用现场直接划线删掉如果有人用但说不清用途就标记为“待确认”等确认后再决定要不要采。这个过程看起来很笨但价值巨大。它逼着业务方把需求落实到具体点位层面也逼着我提前发现协议不支持、数据不在PLC里之类的问题。很多项目失败不是因为技术做不到而是因为一直到上线都没搞清楚“采来干什么”。5.2 离线仿真先让数据“自己跑起来”没有生产环境可供调试的阶段可以搭建一套离线仿真环境。我的做法是写一个模拟PLC服务监听真实的通信端口按点位表周期返回预设的模拟数据。数据可以是正弦波、阶梯值或者固定死值重点是让整套采集引擎跑起来验证调度节奏、入库吞吐量和积压告警。仿真阶段最容易发现的是点表里访问路径写错、数据类型不匹配之类的低级问题。等到仿真环境下连续运行48小时不报错、数据完整率接近100%之后再去现场联调效率会高得多。否则直接上现场一边要应付生产节拍一边还要对着报错日志猜问题压力完全不同。5.3 现场联调按工位分批放开采集现场联调不能一股脑把所有PLC接上我习惯按工艺区逐个放开。第一批先接一个工位验证通信、点位解析、数据库写入全链路后观察至少半天再扩展到一个工艺段最后才全线上量。这样即使出现问题影响面可控也能快速定位是本工位点位问题还是公共链路问题。联调时一定要给PLC侧留“安全开关”。很多采集系统部署时需要在PLC里加一段数据发送逻辑如果这段逻辑影响了PLC原有控制扫描周期就可能影响生产。我的做法是在PLC里放一个手动总开关默认关闭只有确认上位机链路稳定后才打开。开关本身既是一个操作习惯也是一个责任边界数据采集系统永远不能反过来干扰生产控制系统。5.4 上线后的运维细节配置外置、日志分级、积压对账上线不意味着结束运维设计决定这套系统能活多久。点位表配置必须外置在数据库或JSON文件里不能写死在代码中否则每次增减点位都要改程序重新发布。日志至少要分两级采集引擎的详细调试日志写在本地按天轮转关键节点日志比如连接断开、点位读取失败、队列积压则以结构化方式写入日志库方便告警和事后排查。我还习惯每天做一个“积压对账”统计每个工位实际采集到的记录数和理论记录数偏差超过一定比例就自动告警。这个机制能捕捉到很多隐蔽问题比如某个PLC每天固定时段掉线、某个点位周期性超时。数据采集系统的底线是数据可信如果连“有没有采全”都无法回答那采下来的数据也很难让人放心使用。回到开头那句话PLC和C#的“对话”看起来是个技术问题实际上是一个系统问题。协议、线程、点位、存储、运维每一环都会在某个深夜给你惊喜。我在这套系统的开发过程中学到最深刻的一点是先保证数据可信再追求数据丰富。把点表核对清楚、把断线重连做扎实、把积压监控跑起来比多引入一个花哨的技术框架管用得多。下次如果还有人问“C#和PLC通信有什么难的”我会建议他先回答一个问题你采上来的数据敢不敢拿给质量部门当成追溯依据。想清楚这一句很多设计决策自然就有答案了。
