伺服压机控制系统架构：上位机与下位机分工及通信实现

1. 伺服压机控制系统架构总览1.1 为什么伺服压机需要上位机与下位机分工伺服压机这个东西跟普通液压机、气动压机最大的区别就在于“可控”。压装力、压装速度、保压时间、位移曲线这些参数在精密装配场景里比如轴承压装、电机转子压装、连接器插针压入都是要精确到小数点后几位的。你不可能靠一个PLC的梯形图就把整条压力-位移曲线跑出来更不可能在HMI上画一条实时曲线给工艺工程师看。所以行业里几乎默认的做法就是下位机负责硬实时控制上位机负责人机交互和数据管理。这个分工不是谁拍脑袋定的而是被物理条件逼出来的。伺服压机的控制周期通常在1ms甚至更短位置环、速度环、电流环三环嵌套每个周期都要完成编码器采样、PID运算、PWM输出。这种活儿必须跑在实时内核上比如DSP、FPGA或者带RT-Preempt补丁的Linux。你让Windows去干这个一个系统调度抖动就是几百微秒压装力直接飞了。上位机就不一样了。它要干的事情是显示实时曲线、存储历史数据、管理配方、对接MES系统、生成报表、做用户权限管理。这些事情对实时性要求不高但对界面友好度、数据库能力、网络通信能力要求很高。Windows或者桌面Linux跑Qt、C#、LabVIEW都行开发效率高生态成熟。我见过一些团队为了省成本试图用一块工控板同时跑HMI和运动控制结果就是曲线刷新一卡压装力就超差。后来还是老老实实拆成上下位机。这个教训值得每个新入行的人记住实时任务和非实时任务必须物理隔离或者至少用实时内核做严格分区。1.2 典型三层架构HMI层、控制层、驱动层如果把伺服压机控制系统拆开看从顶到底大致是这么三层第一层是HMI/上位机层。这一层跑在工控机或者触摸屏上操作系统一般是Windows或者Linux桌面版。它负责跟操作工打交道显示压装曲线、报警信息、生产计数同时把配方参数下发给下位机。通信方式常见的有Modbus TCP、EtherCAT、OPC UA、TCP/IP自定义协议。这一层不参与任何闭环控制它发指令然后等结果。第二层是控制层/下位机层。这一层是核心通常是一块运动控制卡、一个PLC比如西门子S1200、三菱FX5U或者一个专用的伺服压机控制器。它跑实时任务周期性地读编码器、算PID、出力矩指令。同时它要处理逻辑互锁比如上模下行前必须确认工件到位、安全门关闭、气压正常。这一层通常用IEC 61131-3编程梯形图、ST语言或者C语言在DSP上开发。第三层是驱动层/执行层。伺服驱动器、伺服电机、编码器、力传感器、比例阀这些。驱动器接收控制层的位置/速度/力矩指令驱动电机动作同时把编码器反馈和力传感器信号传回去。这一层通常是买现成的伺服系统比如松下、安川、台达、汇川通过EtherCAT或者模拟量脉冲跟控制层对接。这三层之间的边界不是死的。有些小型伺服压机把控制层和驱动层合并了用一体化的伺服压机控制器。有些大型多工位压机则会在控制层和驱动层之间再加一个运动控制器。但不管怎么变上位机不碰实时控制、下位机不碰数据库这个原则基本不变。1.3 上位机与下位机的职责边界划分具体到职责我列一个表更清楚职责项上位机下位机实时闭环控制不参与核心职责周期1ms以内压装曲线显示实时刷新从下位机读数据采集原始数据缓存后上传配方管理存储、编辑、下发接收并执行掉电保存报警处理显示、记录、推送检测、触发急停安全逻辑不参与硬线软件双重互锁数据存储数据库、报表、追溯只做短期缓存通信协议Modbus TCP/OPC UA主站Modbus RTU/TCP从站用户权限完整管理只认使能信号这个边界划清楚之后开发的时候就不会互相甩锅。我见过一个项目上位机工程师抱怨下位机上传数据太慢导致曲线卡顿下位机工程师说“我1ms周期哪有空给你传曲线”。后来改成下位机每10个周期打包一帧数据上位机用环形缓冲区接收问题就解决了。边界清晰不等于不沟通恰恰相反边界清晰之后沟通才有焦点。2. 上位机软件架构拆解2.1 上位机核心功能模块划分上位机软件不管用什么语言写功能模块基本跑不出这几块通信模块。这是上位机的命根子。它要跟下位机建立连接、维持心跳、收发数据。常见协议是Modbus TCP因为简单、通用、几乎所有PLC都支持。也有用OPC UA的适合跟MES对接。自定义TCP协议也有效率高但兼容性差。通信模块的设计要点是异步非阻塞、断线重连、数据校验、超时处理。我习惯用状态机来管理连接状态断开、连接中、已连接、错误、重连中。数据解析与缓存模块。下位机传上来的是一堆字节流上位机要按协议解析成有意义的物理量。比如Modbus寄存器里存的是整数要除以比例因子才是实际压力值。解析完的数据要放进环形缓冲区供曲线控件和数据库线程消费。这里要注意线程安全生产者-消费者模式是标配。曲线显示模块。这是操作工最关心的部分。压力-位移曲线、压力-时间曲线要实时刷新刷新率一般20-50Hz就够了太高反而占CPU。曲线控件可以用Qt的QCustomPlot、C#的Chart、LabVIEW的Waveform Graph。关键是要支持缩放、游标测量、多曲线叠加对比。配方管理模块。每个产品型号对应一套压装参数目标压力、目标位移、速度、保压时间、上下限公差。配方要能新建、复制、编辑、导入导出。存储一般用SQLite或者Access轻量够用。配方下发时要校验下位机是否接受成功不能发完就不管。数据库与追溯模块。每个压装循环的结果都要存时间戳、产品序列号、最终压力、最终位移、曲线数据、判定结果。数据库用MySQL、SQL Server、PostgreSQL都行小规模用SQLite也能扛。追溯查询要支持按时间、序列号、结果筛选。用户权限模块。操作工只能看和启动工艺工程师能改配方管理员能改系统参数。权限设计要简单实用别搞太复杂。常见做法是用户名密码角色角色对应权限位。报警与日志模块。报警要分级提示、警告、故障。故障要触发停机。日志要记录操作记录、参数修改记录、报警记录方便事后追责。2.2 通信层设计Modbus TCP在伺服压机中的落地Modbus TCP在伺服压机上位机里用得最多原因就三个简单、开放、PLC都支持。但简单不代表随便用有几个坑我踩过。寄存器地址规划。下位机那边要先把寄存器地图定好。比如40001-40010控制字启动、停止、复位、使能40011-40020状态字就绪、运行、故障、到位40021-40030配方参数目标压力、速度、保压时间40031-40100实时数据当前压力、当前位移、当前速度40101-41000曲线数据缓冲区这个地图一旦定了上位机下位机各自开发最后联调。最怕的就是中途改地址所以前期一定要把需求捋清楚。数据格式。Modbus寄存器是16位的但压力值可能是32位浮点数。常见做法是用两个连续寄存器拼成一个32位整数然后除以比例因子。比如压力范围0-100kN比例因子100那么实际值寄存器值/100。浮点数也可以直接传IEEE 754格式但要注意大小端。我一般建议用整数比例因子简单可靠。通信周期。上位机读实时数据的周期一般100-200ms就够了曲线数据可以攒一批再读。写配方参数是事件触发的不占周期。要注意Modbus TCP的并发连接数限制有些PLC只支持2-3个主站连接上位机别开太多线程去连。断线重连。工业现场网络抖动是常态。通信模块必须能检测断线并自动重连重连后要重新同步状态。我一般会加一个心跳寄存器上位机每隔1秒写一个递增值下位机如果发现心跳停了就报警。# 一个简化的Modbus TCP通信状态机示例 import socket import struct import time class ModbusTCPClient: def __init__(self, ip, port502): self.ip ip self.port port self.sock None self.connected False self.heartbeat 0 def connect(self): try: self.sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.settimeout(2.0) self.sock.connect((self.ip, self.port)) self.connected True return True except Exception as e: self.connected False return False def read_registers(self, addr, count): if not self.connected: return None # Modbus TCP帧: 事务ID(2) 协议ID(2) 长度(2) 单元ID(1) 功能码(1) 起始地址(2) 数量(2) frame struct.pack(HHHBBHH, 1, 0, 6, 1, 3, addr, count) try: self.sock.send(frame) resp self.sock.recv(1024) # 解析响应... return resp except Exception: self.connected False return None def write_register(self, addr, value): if not self.connected: return False frame struct.pack(HHHBBHH, 1, 0, 6, 1, 6, addr, value) try: self.sock.send(frame) resp self.sock.recv(1024) return True except Exception: self.connected False return False上面这段代码只是示意实际项目里要用成熟的Modbus库比如pymodbus、libmodbus、NModbus。自己写协议解析容易在异常处理上翻车。2.3 数据可视化与曲线渲染的工程实现曲线显示是上位机最吃性能的部分。我见过一个项目操作工抱怨曲线刷新时界面卡死查下来是因为每次收到新数据都重绘整个曲线控件而且数据点没有做降采样。后来改成环形缓冲区定时刷新抽点显示CPU占用从40%降到5%。环形缓冲区设计。下位机上传的曲线数据是连续流上位机用一个固定大小的数组做环形缓冲。写指针不断前进读指针跟着刷新周期走。缓冲区大小要能存下最长一次压装周期的数据比如压装10秒下位机每1ms上传一个点那就是10000个点。每个点包含压力、位移、时间用结构体数组存。定时刷新。不要每来一个数据就刷新界面。用一个定时器比如50ms触发一次把缓冲区里最新的数据批量更新到曲线控件。这样界面刷新频率稳定CPU占用可控。抽点显示。如果一次压装有一万个点屏幕上像素宽度可能只有一千那一万个点画上去也是重叠的。可以根据当前缩放级别做抽点比如每10个点取一个最大值和最小值画成包络线。这样既保留了曲线特征又减少了绘制量。多曲线对比。工艺工程师经常要把当前曲线和历史合格曲线叠在一起看。实现上就是维护多个数据序列用不同颜色画。注意历史曲线要预先降采样不然内存吃不消。2.4 配方管理与数据库持久化方案配方管理看起来简单但实际项目里最容易出问题。我总结几个要点配方版本控制。同一个产品型号工艺参数可能会优化。每次修改要生成新版本旧版本保留。生产时记录用了哪个版本方便追溯。数据库表设计配方主表型号、版本、创建时间、创建人、配方参数表配方ID、参数名、参数值。配方下发校验。上位机把配方写给下位机后要回读校验。有些PLC写进去之后会做范围检查超范围会拒绝。上位机要处理这种拒绝给操作工明确提示。数据库选型。单机版用SQLite最省事不用装服务文件拷走就能备份。网络版用MySQL或者PostgreSQL支持多客户端并发。SQL Server在工控行业也常见但授权费用高。我一般推荐SQLite起步产量大了再换。数据表设计。压装结果表至少包含ID、时间戳、产品序列号、配方型号、配方版本、最终压力、最终位移、保压时间、判定结果、曲线数据BLOB或者单独文件。曲线数据如果存数据库建议压缩后存不然数据库膨胀很快。也可以存文件系统数据库只存路径。-- 压装结果表简化设计 CREATE TABLE press_results ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, serial_number VARCHAR(64), recipe_model VARCHAR(64), recipe_version INTEGER, final_force REAL, final_position REAL, hold_time REAL, result VARCHAR(16), curve_file_path VARCHAR(256) ); -- 配方参数表 CREATE TABLE recipe_params ( id INTEGER PRIMARY KEY AUTOINCREMENT, recipe_id INTEGER, param_name VARCHAR(64), param_value REAL, param_unit VARCHAR(16), FOREIGN KEY (recipe_id) REFERENCES recipes(id) );2.5 上位机技术栈选型对比Qt、C#、LabVIEW这个选题在热词里也出现了我结合实际项目经验说一下。技术栈优势劣势适用场景Qt/C跨平台、性能好、控件丰富学习曲线陡、开发效率低大型项目、需要跨平台C#/WinForms/WPF开发快、生态好、上手容易主要限Windows、性能一般中小型项目、Windows工控机LabVIEW图形化编程、测试测量强授权贵、代码难维护实验室、快速原型Python/PyQt开发快、库多打包麻烦、性能一般内部工具、小批量C/MFC性能好、底层控制强开发慢、界面丑老项目维护我个人经验如果团队是电气工程师为主LabVIEW上手最快。如果是软件工程师为主C# WPF开发效率最高。如果要跨平台或者对接LinuxQt是首选。Python适合做辅助工具做主控上位机在长期运行稳定性上要谨慎。热词里有人问“上位机软件有没有比Qt还好用的”我的看法是没有绝对更好只有更合适。Qt的强项是跨平台和性能C#的强项是开发效率和Windows生态。选型要看团队背景和项目需求别盲目追新。3. 下位机软件架构拆解3.1 下位机实时控制任务调度下位机的核心是一个硬实时任务通常跑在1ms甚至更短的周期上。这个任务要完成读编码器位置读力传感器值执行位置环PID执行速度环PID输出力矩指令给驱动器更新状态字检查安全互锁这些动作必须在每个周期内全部完成不能有任何一个周期漏掉。所以下位机的软件架构通常是前后台系统或者RTOS任务调度。前后台系统主循环里轮询各个任务中断处理紧急事件。简单但实时性靠中断保证。适合功能单一的小型控制器。RTOS任务调度用FreeRTOS、RT-Thread、VxWorks等把控制任务设为最高优先级通信任务、显示任务设低优先级。控制任务用定时器触发保证周期稳定。这是主流做法。中断驱动编码器采样、PWM输出用中断控制算法在主循环或者定时器中断里跑。要注意中断嵌套和临界区保护。我个人的经验是控制周期1ms以下用RTOS1ms以上可以用前后台定时器中断。但不管哪种控制任务里绝对不能有阻塞操作不能等通信、不能等文件IO、不能动态分配内存。3.2 运动控制算法与PID闭环实现伺服压机的控制算法核心是位置环速度环电流环三环控制。下位机通常只做位置环和速度环电流环在驱动器内部完成。位置环输入是目标位置反馈是编码器位置输出是速度指令。PID参数整定要看机械刚性和负载惯量。压装过程中负载变化大所以位置环增益不能太高否则会振荡。速度环输入是速度指令反馈是编码器微分得到的速度输出是力矩指令。速度环增益影响响应快慢。压力控制模式有些压装工艺要求恒压力保压这时候要切换到压力环。压力环的反馈是力传感器输出是位置修正量。压力环响应慢但精度高。前馈补偿为了减小跟随误差可以加前馈。速度前馈和加速度前馈。前馈系数要根据机械特性调。PID参数整定步骤先把积分和微分置零只加比例逐渐增大比例直到系统开始振荡减小比例到振荡消失取80%作为最终值加积分从小往大调消除稳态误差加微分抑制超调实际压装测试微调这个过程说起来简单实际调起来可能要半天。我一般会写一个自动整定的小工具让下位机跑阶跃响应上位机记录曲线然后离线分析。3.3 安全逻辑与硬实时互锁设计安全逻辑是下位机的底线不能有任何侥幸。我总结几条铁律急停必须走硬线。急停按钮直接切断驱动器使能不能只靠软件。软件急停是第二道防线。安全门、光幕、气压检测。这些信号要同时进PLC的普通IO和专用安全模块。安全模块负责切断动力普通IO负责逻辑判断。上下位机互锁。上位机发启动指令前下位机要检查所有安全条件。条件不满足拒绝启动并返回错误码。看门狗。下位机要有硬件看门狗程序跑飞了自动复位。复位后要进入安全状态不能自动恢复运行。通信超时处理。上位机跟下位机通信中断超过一定时间下位机要自动停机。这个时间一般设3-5秒。参数范围校验。上位机下发的配方参数下位机要二次校验。比如目标压力超过传感器量程直接拒绝。3.4 下位机通信从站实现与寄存器映射下位机作为Modbus从站要维护一张寄存器表。这张表的设计直接影响通信效率。寄存器分区线圈区控制位可读可写离散输入区状态位只读保持寄存器区参数和实时数据可读可写输入寄存器区只读数据地址映射示例地址类型名称说明00001线圈启动写1启动00002线圈停止写1停止00003线圈复位写1复位10001离散输入就绪1就绪10002离散输入运行1运行10003离散输入故障1故障40001保持寄存器目标压力单位0.01kN40002保持寄存器目标位移单位0.01mm40003保持寄存器速度单位0.1mm/s40004保持寄存器保压时间单位ms40011保持寄存器当前压力单位0.01kN40012保持寄存器当前位移单位0.01mm40013保持寄存器当前速度单位0.1mm/s40014保持寄存器状态字位定义通信任务优先级。Modbus从站任务优先级要低于控制任务高于显示任务。通信处理不能阻塞控制循环。我一般用DMA中断收数据主循环里解析。数据一致性。实时数据区可能被控制任务和通信任务同时访问。要用双缓冲或者临界区保护。比如控制任务更新数据到缓冲区A通信任务从缓冲区B读定时交换。4. 上下位机协同与联调实战4.1 通信协议设计与数据帧格式约定上下位机联调之前协议文档必须先定死。我一般会写一份《通信协议说明书》包含物理层RS485还是以太网波特率、IP地址、端口号。数据链路层Modbus RTU还是TCP从站地址超时时间。应用层寄存器地图数据类型比例因子读写权限。异常处理错误码定义重试策略超时处理。数据帧格式如果自定义协议帧头(2B) 命令(1B) 长度(2B) 数据(NB) 校验(2B) 帧尾(2B)命令集0x01读实时数据0x02写配方参数0x03启动压装0x04停止压装0x05读曲线数据0x06读状态字0x07心跳协议定好之后双方各自开发最后联调。联调时用Modbus Poll、Modbus Slave这类工具先验证寄存器读写再跑实际程序。4.2 联调步骤与常见通信故障排查联调我一般按这个顺序物理连接检查。网线通不通IP能不能ping通RS485 A/B有没有接反。通信参数确认。波特率、数据位、停止位、校验位、从站地址。寄存器读写测试。用Modbus Poll读保持寄存器看有没有响应。单点功能测试。写一个启动线圈看下位机有没有动作。数据一致性测试。上位机写配方下位机回读对比是否一致。实时数据测试。下位机跑起来上位机读实时数据看刷新是否正常。曲线传输测试。跑一次完整压装上位机接收曲线数据看是否完整。异常测试。拔网线、断电、急停看双方是否正确处理。常见故障排查表现象可能原因排查方法通信超时IP错误、端口占用、防火墙ping测试、telnet端口数据错乱大小端、寄存器地址偏移用Modbus Poll对比写不进去寄存器只读、权限不足查寄存器地图曲线卡顿通信周期太短、数据量太大降低刷新率、分批传输断线不重连重连逻辑缺陷检查状态机数据跳变浮点数解析错误检查IEEE 754格式4.3 压装曲线数据上传的优化策略曲线数据是上下位机通信里数据量最大的部分。一次压装10秒1ms一个点就是10000个点。每个点压力位移时间至少12字节总共120KB。用Modbus TCP传一次读125个寄存器要读几百次效率很低。优化策略下位机缓存压缩。下位机在压装过程中把曲线数据存到RAM缓冲区压装结束后压缩。压缩算法可以用简单的差分编码第一个点存原始值后续点存与前一个点的差值。差值通常很小用16位甚至8位就能存。分批上传。上位机发命令读曲线下位机分批次返回。每批返回一定数量的点上位机确认后再读下一批。这样不会阻塞通信。文件传输。如果下位机有文件系统可以把曲线写成CSV文件上位机用FTP或者自定义文件传输协议拉取。这样效率最高但下位机要有足够的存储空间。实时曲线降采样。如果上位机只需要实时显示不需要每个点都传可以下位机做降采样。比如每10个点取一个最大值和最小值上传包络线。这样数据量减少到1/5曲线形状还能保留。我实际项目里用的是实时降采样结束后完整上传的组合。实时显示用降采样数据保证流畅压装结束后把完整曲线传到上位机存数据库保证追溯精度。4.4 系统联调中的时序问题与解决方案时序问题是联调中最头疼的。我举几个实际例子启动时序。上位机发启动命令下位机收到后要检查安全条件然后使能驱动器等待驱动器就绪再开始运动。这个过程中上位机要轮询状态字不能发完命令就认为启动了。我一般会设计一个状态机上位机跟着下位机的状态走。停止时序。正常停止和急停的时序不一样。正常停止是减速到零再断使能急停是直接断使能。上位机要能区分这两种停止并显示不同的报警信息。配方切换时序。生产过程中切换配方必须等当前压装循环结束。上位机要禁止在运行中下发新配方或者下位机收到新配方后缓存等循环结束再生效。数据上传时序。压装结束后下位机要先保存曲线数据再置“数据就绪”标志。上位机看到标志后再读数据。如果上位机读得慢下位机要保留数据直到被读走。通信心跳时序。上位机每隔1秒写心跳寄存器下位机如果3秒没收到心跳判定通信中断自动停机。这个时间不能太短否则网络抖动就停机也不能太长否则真断线了还在跑。5. 实战避坑与经验总结5.1 上下位机职责划分的常见误区误区一上位机做逻辑判断。有些工程师图省事把安全逻辑放在上位机。比如上位机判断“压力到了就停止”下位机只负责执行。这是大忌。上位机死机、通信中断压机就失控了。安全逻辑必须在下位机。误区二下位机做数据存储。下位机存储空间有限频繁写Flash会缩短寿命。历史数据存储是上位机的活儿。下位机只做短期缓存。误区三通信协议频繁改。联调时发现协议不合适改来改去双方代码都要动。所以协议设计阶段要多花时间考虑周全。误区四上位机直接控制驱动器。有些方案让上位机通过EtherCAT直接控制伺服驱动器跳过下位机。这在简单点位控制里可行但在压装这种需要实时闭环的场景里Windows的实时性根本不够。误区五忽略掉电保存。配方参数、系统配置这些要掉电保存。下位机用EEPROM或者FRAM上位机用数据库。掉电后要能恢复到掉电前的状态。5.2 通信稳定性与抗干扰实战技巧工业现场电磁干扰大通信稳定性是永恒的话题。我总结几条RS485要加终端电阻。120欧姆接在总线两端。不加的话长距离通信误码率很高。网线要用屏蔽线。伺服驱动器、变频器附近尤其要注意。屏蔽层单端接地。通信线远离动力线。至少20cm以上不能走同一个线槽。Modbus TCP加事务ID。每次请求事务ID递增响应里带回事务ID防止响应错位。超时重试。通信超时后重试2-3次还失败就报断线。重试间隔要短比如100ms。数据校验。关键数据加CRC或者校验和。Modbus本身有CRC自定义协议要自己加。看门狗。上位机通信线程要有看门狗卡死了要能自动重启线程。日志记录。通信异常要记日志包括时间、错误码、重试次数。排查问题时全靠日志。5.3 从项目落地角度谈架构扩展性伺服压机控制系统不是做完一个项目就完了后面还要复制到其他型号、其他产线。所以架构要有扩展性。通信协议要支持多从站。一条产线可能有多台压机上位机要能同时跟多台下位机通信。Modbus TCP支持多连接但要注意PLC的连接数限制。配方要支持导入导出。不同产线之间要能共享配方。用Excel或者JSON格式方便人工编辑。数据库要支持多产线。表里加产线ID字段查询时按产线筛选。界面要支持多语言。出口项目需要英文界面。Qt和C#都支持国际化提前做好字符串资源分离。报警要支持远程推送。对接MES或者企业微信设备故障时自动通知维修人员。曲线数据要支持导出。工艺工程师要拿数据做分析支持导出CSV或者Excel。权限要支持LDAP/AD。大厂里员工账号统一管理上位机要能对接域认证。5.4 个人实操心得与后续优化方向做了这么多年伺服压机控制系统我最大的体会是架构设计阶段多花一周联调阶段少花一个月。上下位机的边界、通信协议、寄存器地图、数据格式这些定清楚了后面就是按部就班实现。定不清楚后面就是无休止的扯皮和返工。另一个体会是日志和诊断功能要一开始就做。不要等出了问题再加。通信日志、操作日志、报警日志、参数修改日志这些在排查问题时价值巨大。我习惯在通信模块里加一个“原始报文记录”开关联调时打开记录所有收发报文事后分析。后续优化方向我觉得有几个边缘计算。下位机做初步的数据分析比如压装曲线特征提取只把特征值上传减少通信量。AI质量判定。用历史曲线训练模型实时判定压装质量替代简单的上下限判定。数字孪生。上位机建立压机的数字模型实时映射物理状态做预测性维护。无线通信。有些产线移动工位用无线但工业无线稳定性还要验证。云平台对接。多工厂数据汇总到云平台做全局OEE分析。这些方向不是每个项目都要上但架构设计时留好接口后面扩展就方便。比如通信模块抽象成接口底层换Modbus还是OPC UA都不影响上层。数据库抽象成DAO层换数据库只改DAO实现。这样项目才能持续演进而不是做完就锁死。