收到我这就按照项目标题“【JVS更新日志】APS排产、物联网、逻辑编排、企业计划等3.4更新说明”以及相关热搜词以资深博主的角度输出一篇高质量博文。拿到JVS 3.4版本的更新说明我的第一反应是——这次终于不只是单调地堆功能了。APS排产、物联网接入、逻辑编排、企业计划这四大块被放到同一个版本里发布其实是一个很明确的信号JVS开始从“单个功能模块的完善”往“业务闭环的协同”方向走了。这三个词放在一起意味着制造型企业的计划、排产、执行、反馈这条链路终于可以在一个平台里完整跑通而不是靠Excel加微信来回传。这篇更新日志我会按模块拆开讲。不是简单复述“改了什么”而是把每个改动背后的业务场景、技术逻辑、使用价值以及实际落地时需要注意的坑都尽量说透。如果你是做实施交付的项目经理、企业内部的信息化负责人或者正在研究低代码/中台方案的开发这篇内容应该能帮你少走不少弯路。1. APS排产模块的实质性升级从“能排”到“排得合理”先说APS排产。3.4版本里这块的改动是最重的也是制造型企业最关心的。前几个版本的APS已经能把订单拆成工序、把工序分配到资源上但说实话那会儿的排产结果更多是“能用”离“能用得顺”还有差距。这次更新核心就一句话排产逻辑从“顺序优先”变成了“约束优先”。1.1 排产算法调整顺序依赖与并行工序的处理逻辑老版本里多工序订单默认按顺序排前一道工序结束后一道才能开始。这在单件流或者简单流水线场景下没问题但一到离散制造就露馅了。比如一个订单分加工和装配两大段加工段里有几个零件可以并行做老版本直接给串成一条线导致资源闲着、交期还拉长。3.4版本把并行工序的支持做进去了。系统现在会根据工艺路线里的工序关系识别哪些工序是并行关系、哪些是严格的先后依赖。实际排产时并行工序可以跨资源、跨设备同时开工只有真正存在前后置关系的工序才做时间上的强制约束。这里有个参数值得关注并行度阈值。默认配置是允许同一订单下最多3道并行工序同时排产如果实际车间里并行数量更大比如一道装配要等5个零件都加工完那可以在排产策略里调高这个值。调整路径是“生产管理—排产策略—并行参数”3.4之后这个配置从全局级下放到了订单级也就是说不同订单可以有不同的并行度设置灵活性比之前高了不少。1.2 资源日历与排产约束的联动另一个让我比较满意的改动是资源日历和排产约束真正打通了。以前资源日历更多是摆设设备保养、节假日、班次休息这些信息录进去排产引擎却不怎么理会经常出现“排产显示今天能做实际设备在保养”的尴尬。3.4版本中资源日历被纳入了排产的硬约束条件。系统在计算每道工序的可排时间窗口时会先扣除设备日历里的不可用时段再结合班次模型确定每天的可开工区间。同时模具、工装这类辅助资源也支持了独立的日历维护不再跟设备日历强行绑定。做过多品种小批量生产的朋友应该能立刻get到这一点模具切换时间往往比加工时间还长如果模具日历算不清排产结果根本没有参考价值。我实际测试了一个场景一条产线三台设备其中一台周五全天保养另一台周六加班半天。老版本会把订单排到周五的保养设备上造成实作业与排产表脱节新版本会自动把这台设备的可用时间窗口切到周六同时把周五的负荷分摊到另外两台设备上。这个效果是实打实的不是改了个表面的界面。1.3 排产结果的可视化对比与手工微调排产引擎跑完之后结果是否可调整决定了这个APS能不能被车间老师傅接受。3.4版本在排产结果的交互上做了两个关键更新一是支持了多版本排产方案的对比二是手工微调后的差异高亮。多版本对比这个功能很有用。比如计划员想比较“交期优先”的排产方案和“成本优先”的排产方案以前得分别跑两次再截图对比现在系统会保留每次排产的结果快照同一订单在不同方案下的开工时间、完工时间、设备负荷率、拖期天数都可以放到一张表里对比。这个功能特别适合每周末做下周排产计划时的方案评审场景。手工微调和差异高亮则解决“人和系统打架”的问题。系统排出来的方案老师傅觉得不合理可以直接拖拽工序到别的设备上。关键点是3.4版本会把人工调整过的工序打上标记下次重新排产时如果新方案和人工调整的结果有冲突系统会弹出冲突提示而不是默默覆盖掉人工选择。这个细节做APS项目的朋友应该懂它的含金量——不然每次排产一刷新老师傅的调整全没了信任感瞬间崩塌。2. 物联网接入层重构网关通信与设备建模的底层变化JVS的物联网模块在3.4之前的定位更偏向“设备数据上云”就是设备连上来、数据传上来、在页面上画个曲线。这次更新终于对底层架构动了刀设备接入的通信架构、网关与传感器的网络关系、数据上行的方式全部重新梳理了一遍。2.1 物联网三层架构中“中间层”的升级聊物联网必然会聊到三层架构感知层、网络层、应用层。感知层是传感器、表计、PLC这些物理设备网络层是网关、网络传输协议应用层是JVS里的设备管理、数据展示、规则告警。3.4版本重点改的是“网络层”和“应用层”的衔接——网关接入规范。以前接入网关的走的是比较原始的TCP透传。设备厂商给个IP和端口JVS端开放一个监听端口数据发过来就解析、入库。这种模式开发最快但问题也最明显设备量一大连接管理混乱设备厂商换网段或改端口现场得跟着改而且IT和OT的网络边界很难做隔离。3.4版本把网关接入调整成了边缘网关主动上报模式主推MQTT over TLS。简单说网关不再是“把数据推给平台开的端口”而是“作为MQTT客户端主动连接到平台的MQTT Broker”。这个改动的好处是平台端不再需要对外暴露大量监听端口只需要开放一个MQTT接入点所有网关统一走这里上行数据。从网络安全的角度看暴露面小了很多。2.2 网关与传感器的IP关系处理优化热词里有“物联网网关与传感器的ip关系”这个在3.4版本里确实有对应的处理优化。以前设备实例的标识逻辑比较粗糙传感器换IP、换网段之后JVS里很容易出现“设备离线但实际上在传数据”的错觉或者同一个传感器重复注册成两台设备。3.4版本引入了网关-子设备拓扑模型。现在设备接入流程是先建网关节点再在网关节点下挂子设备每个子设备用“网关ID通道号传感器唯一标识”三元组来定义。传感器的IP变成了一种运行时属性而不是设备身份的一部分。换句话说IP变了设备还是那台设备只是网关侧的连接信息需要同步更新只要三元组不变数据依然能对上号、入对库。这一点对现场维护来说价值很大。产线上的传感器更换IP、或者因为交换机调整被分配了新地址段以前得去JVS里重新编辑设备的通讯参数现在只需要保证网关侧的映射关系正确平台里基本不用动。配合3.4版本新增的“网关在线率”和“子设备数据新鲜度”两个监测指标故障定位会快很多——到底是网关掉线、还是某个传感器停了看这两个指标就能判断。2.3 无源物联网/低功耗设备的数据上报策略热词里频繁出现“无源物联网”这是最近行业里讨论度很高的方向。所谓无源指的是设备没有传统的供电线路靠环境取能太阳能、射频能量、振动能量或者依靠极低功耗的电池工作。这类设备的特点是供电不稳定、上报频率低、数据包小但对数据完整性反而要求很高。3.4版本针对这类设备做了两个适配。第一是支持了非周期数据上报的模式网关不再是按固定频率轮询而是“有事件才上报按需上传”。第二是在协议解析层增加了一个QoS分级无源设备上传的数据可以在边缘网关侧缓存等网络恢复或设备有足够能量时再补传。这样既不至于因为设备断电导致数据长时间空白又不会因为强制实时在线把设备那点可怜的电量耗尽。从实际场景看仓库里的温湿度标签、管道上的振动监测贴片、户外井盖的状态监测器都是无源物联网的典型应用。这类项目过去在JVS里很难做数据建模因为设备时在线时离线。3.4之后设备状态字段里多了一档“间歇在线”配合数据补传机制终于能把这些“神出鬼没”的设备管起来了。3. 逻辑编排引擎增强扩展节点与调试效率逻辑编排一直是JVS的差异化能力。它本质上是一个轻量级的可视化规则引擎让实施人员不用写代码就能把业务规则、接口调用、数据转换串起来。3.4版本在这个模块上的改动方向很明确一是节点类型扩充二是调试体验优化三是和APS、物联网的串联能力增强。3.1 新增节点类型与应用场景这次新增的节点里个人最看好的是“定时触发节点”和“事件订阅节点”。定时触发节点解决的是调度类场景。以前要在JVS里做每天凌晨同步一次ERP数据、每小时汇总一次设备产量这种事得写一个定时任务脚本或者依赖外部调度平台。现在直接在逻辑编排里拖一个定时触发节点配置cron表达式后面接数据同步的流程编排一个可视化定时任务就成了。对于MQTT数据本身就是异步的——物联网设备不会在你需要的时候正好发数据来。编排调试器在3.4版本里增加了断点执行和变量快照功能。节点上可以打断点运行到断点处暂停此时可以查看所有上下文变量的当前值然后单步往下走。老版本只能看到最终结果对错中间过程是一片黑盒现在每一步的输入输出都摆在明面上定位问题快了很多。还有一个细节编排实例的执行日志里会记录每个节点的耗时毫秒数一眼就能看出整个链路里的性能瓶颈在哪。3.3 编排与APS、物联网的串联实践能把编排引擎和APS、物联网模块串起来是我认为这次版本最有价值的一点。一个典型的串联场景车间里的自动导引车AGV和加工设备上都装了传感器通过物联网模块实时上报状态。当某台设备故障停机时物联网模块的告警规则触发一条消息进入逻辑编排引擎编排流程里先调APS的“插单重排”接口把原本排在这台设备上的后续工序重新分配给别的可用设备然后调企业计划模块的“计划变更”接口生成一条计划调整记录最后通过工作流通知计划员确认。这套流程在3.4之前不是不能做但需要写一堆胶水代码还要考虑接口鉴权、数据格式转换、失败重试。现在全部在编排画布里用节点拖出来实施周期从按周算缩短到按天算。对做项目交付的兄弟来说这个变化最实际——少加班才是真的升级。4. 企业计划模块的联动能力提升企业计划模块在JVS里承担的是偏管理层的职能年度经营计划、月度产销计划、物料需求计划这些。以前这个模块相对独立计划做完就完了跟APS排产和生产执行之间的联动很弱。3.4版本着重要解决的就是这个断点。4.1 计划编制、执行、反馈闭环的完善这次更新把企业计划从“静态编制工具”往“动态闭环管理”拉了一大步。计划编制完成后会自动下发到APS排产模块——这个“下发”不是简单复制一份数据过去而是带着版本号的正式传递。APS排产完成后实际产出数据又会回流到企业计划模块形成“计划-排产-执行-达成反馈”的闭环。在界面上企业计划模块新增了“达成率看板”。每个计划条目后面会实时显示当前的达成进度。比如月生产计划是1000件截至今天APS里已经排产了700件实际完工入库了400件那达成率就是40%。这个数据不是人工填的是从APS和车间执行数据里自动汇总上来的口径能对得上——这对制造业的朋友来说应该很有共鸣以前开生产调度会最大的争议就是各部门报的数字对不上。4.2 与APS排产的衔接逻辑企业计划和APS的衔接关键在“需求分解”这一层。《APS排产和MES的关联》之前写过相关文章这次不重复讲原理只说3.4版本的具体变化。现在企业计划模块里可以定义“计划BOM”一个计划项对应多个排产工单。比如月度计划里有一条“生产A产品500台”它会自动分解成“壳体加工若干件”“电机装配若干件”“整机测试若干件”这些分解出来的需求才是APS真正拿去做排产的输入。分解规则在计划模板里维护可以按BOM比例、按历史产出比例、或者按计划的明细行手工指定。这个分解动作在3.4之前是半手工的计划员要自己去APS里建工单然后再关联回计划。现在变成自动化的以后计划员可以集中精力做例外管理哪些计划项分解得不对、哪些物料交期可能有问题而不用把时间花在重复建档上。另外一个变化是多版本计划对比。企业计划支持同时保留多个版本的计划草案比如“乐观版”“保守版”“平衡版”每个版本都可以单独下发到APS跑一轮排产看排产结果和资源负荷然后再回过来调整计划的优先级。这个能力和APS模块的多方案排产正好对应上形成了从计划到排产再回到计划的决策闭环。4.3 多版本计划对比与审批流多版本计划的管理细节上做得还行。每个版本的差异数据会标亮调整过数量的计划行、新增的计划行、删除的计划行在对比视图里一眼可见。审批方面企业计划支持了按金额、按数量、按计划类型的多层审批流配置并且审批通过后的版本会自动加锁不允许直接修改只能走变更流程。我比较满意的是版本间数据的追溯能力。任意两个已审批的计划版本系统可以生成一张差异清单具体到每一个物料、每一个计划日期、每一个需求数量。这个在月底复盘月度计划达成情况时特别有用——找出“为什么计划没达成”之前先搞清楚“计划本身改了多少版”。5. 平台级更新与升级注意事项除了上面四个重点模块3.4版本还有一些平台级的改动值得关注。权限模型、数据权限、消息中心、移动端适配这些都有调整。但相比之下我觉得更值得聊的是升级落地的注意事项。5.1 权限模型与数据权限细粒度调整3.4版本对权限模型做了一次比较大的重构这个改动如果不提前了解升级后大概率会遭遇“用户突然看不到数据了”的反馈。老版本的数据权限主要是按部门维度控制你是哪个部门的就只能看哪个部门的业务数据。3.4版本把数据权限拆成了“基础数据范围数据行级规则”两层。基础数据范围还是按组织架构走但行级规则可以基于业务字段动态过滤。比如一个销售员既能看到自己客户的历史订单又能看到所有客户的“可售库存”字段但看不到其他客户的价格信息——这在老版本里是没法实现的。对实施顾问来说升级前务必做一次数据权限规则的梳理。因为新旧模型的映射关系不是完全自动的有些部门数据权限会自动迁移但如果之前配置过自定义的字段级权限升级后需要手工转换成新的数据行规则。我建议的做法是先在测试环境完整跑一遍权限映射找几个不同角色的账号各登录一次确认菜单、按钮、数据范围都能正常匹配再动生产环境。5.2 版本升级的前置检查与兼容性说明在升级到3.4之前有几项前置检查必须做否则升级过程容易出幺蛾子。首当其冲是数据库版本的兼容性。3.4版本对底层数据结构做了调整尤其是物联网设备表、排产工单表和企业计划表都加了字段。数据库版本低于MySQL 5.7或者PostgreSQL 12的建议先把数据库升级到位再执行JVS的版本升级脚本。第二个是历史数据的清洗。物联网模块从TCP透传切换到MQTT主动接入后老的网关连接信息在升级后会标记为“已废弃”如果现场还有老网关在跑需要先完成网关侧的接入协议升级再执行JVS侧的切换步骤。否则设备数据会断流。这块强烈建议做一个停机窗口期的规划网关协议切换和JVS升级在同一天做前后两小时完成然后立刻验证第一台设备的数据上行。第三个是逻辑编排的兼容性。老版本里已经发布上线了的编排实例升级后规则引擎的底层执行方式变了但是编排内容本身兼容。需要注意的有两个点一是老编排里的自研扩展点如果用了3.4之前的SPI机制需要重新编译包二是编排里用到HTTP调用节点的地方升级后默认超时时间从30秒降到了10秒如果有些外部接口本来就慢需要在节点上单独调大超时时间。5.3 更新后首批验证清单每次版本升级完我方都是按一个验证清单走一遍确认无误后才算收工。这个清单是多年项目实战攒下来的分享出来你可以直接用。验证项具体操作期望结果用户登录与权限用管理员和普通用户账号分别登录菜单、按钮、数据范围均正常APS排产选择一张历史订单重新排产能识别并行工序并按新约束排产资源日历维护一条设备保养记录重新排产排产结果避开保养时段物联网接入新增一个MQTT网关并绑定子设备设备上线、数据正常入库展示逻辑编排运行一条旧的编排实例正常执行且日志清晰可追踪企业计划将一个新计划下发至APS自动生成排产工单并关联计划号这个清单不求全但求稳。每一项都是升级后最容易暴露问题的模块。第一周先用少量真实业务跑确认稳定后再逐步放开完整业务量。别一上来就把所有用户都切过去万一有条编排链路有问题影响面会非常大。另外升级包里的部署脚本这一次做了比较大的调整不再是一个简单的war包覆盖就完事而是支持了解耦部署APS排产引擎、物联网接入网关、逻辑编排运行时可以分别部署到不同的服务节点上。对大中型的制造企业来说这意味着可以把生产排产服务和办公端的应用拆开跑车间侧的网络抖动不会影响到办公端的使用反过来也一样。部署架构上更灵活但相应地运维上也要求更多一些——至少你得清楚每个服务节点是干什么的、日志去哪儿看、配置中心里每个服务的开关对应什么功能。结尾把3.4版本的更新拆完最想说的是这次升级的完整体验感明显超过前几个小版本。四大模块的联动APS排产、物联网、逻辑编排、企业计划说明JVS团队开始想“全链路协同”这件事了而不只是为了多几个卖点去堆功能。特别是APS排产的约束优化和物联网的MQTT接入重构这两块改动有底层深度不是表面功夫。如果你正在用JVS做制造业数字化转型项目我建议第一批试点就从“设备数据上报—编排触发—APS动态重排—计划调整通知”这条链路开始跑不用追求大而全先把一个车间、一条产线打通看到实际效果后巩固扩大。在具体实施中如果遇到3.4版本的新功能配置或者升级细节上的问题也欢迎随时找我聊。一点点经验之谈收尾升级这种事永远不要在周五下午做。留足一个完整的验证周期比你赶进度重要得多。