企业官网建设流程全解析

收到，我这就按照项目标题“【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 更新后首批验证清单

每次版本升级完，我方都是按一个验证清单走一遍，确认无误后才算收工。这个清单是多年项目实战攒下来的，分享出来你可以直接用。

这个清单不求全，但求稳。每一项都是升级后最容易暴露问题的模块。第一周先用少量真实业务跑，确认稳定后再逐步放开完整业务量。别一上来就把所有用户都切过去，万一有条编排链路有问题，影响面会非常大。

另外，升级包里的部署脚本这一次做了比较大的调整，不再是一个简单的war包覆盖就完事，而是支持了解耦部署：APS排产引擎、物联网接入网关、逻辑编排运行时可以分别部署到不同的服务节点上。对大中型的制造企业来说，这意味着可以把生产排产服务和办公端的应用拆开跑，车间侧的网络抖动不会影响到办公端的使用，反过来也一样。部署架构上更灵活，但相应地，运维上也要求更多一些——至少你得清楚每个服务节点是干什么的、日志去哪儿看、配置中心里每个服务的开关对应什么功能。

结尾

把3.4版本的更新拆完，最想说的是：这次升级的完整体验感明显超过前几个小版本。四大模块的联动（APS排产、物联网、逻辑编排、企业计划）说明JVS团队开始想“全链路协同”这件事了，而不只是为了多几个卖点去堆功能。特别是APS排产的约束优化和物联网的MQTT接入重构，这两块改动有底层深度，不是表面功夫。

如果你正在用JVS做制造业数字化转型项目，我建议第一批试点就从“设备数据上报—编排触发—APS动态重排—计划调整通知”这条链路开始跑，不用追求大而全，先把一个车间、一条产线打通，看到实际效果后巩固扩大。在具体实施中，如果遇到3.4版本的新功能配置或者升级细节上的问题，也欢迎随时找我聊。

一点点经验之谈收尾：升级这种事，永远不要在周五下午做。留足一个完整的验证周期，比你赶进度重要得多。