3.4这个版本，说大不大，说小也不小。没有搞那种推倒重来的大重构，倒是把这段时间客户现场反馈最集中的几个问题，ABC各个方向都动了一遍。这篇更新日志，我打算把APS排产、物联网、逻辑编排、企业计划这几个模块在3.4里的改动逻辑、实际操作建议、以及我在这段时间出差调试过程中踩过的坑一起写出来。如果你正在评估要不要升级，或者是升级完不知道怎么用，这篇应该能帮上忙。
1. 3.4版本的整体思路：把业务闭环上的缺口补上
1.1 为什么这次把重心放在这四个模块上
很多企业看更新日志，第一反应是“我用的模块有没有变化”，但平台型产品好不好用，关键看模块之间能不能串起来。JVS 3.4这版的核心思路，一句话就能概括：把数字化主链路里的断点打通。
我们内部复盘过很多次实施交付的项目，发现最常见的落地路径就是一条主线：企业计划定方向，APS把方向变成可执行的生产计划，物联网把设备状态实时搬进系统，逻辑编排再把各环节的动作自动连接起来。这条链路任何一个环节有缺口，整个数字化项目就会变成“一个模块一个数据孤岛”。
所以3.4版本没有盲目堆新功能，而是把火力集中在这四个高频模块上。APS解决“计划排得准不准”，物联网解决“设备数据上不上得来”，逻辑编排解决“系统间动作为什么不能自动跑”，企业计划解决“目标怎么落到执行层”。这四块补完，整体业务流才算真正闭环。
1.2 更新清单速览
先给一个整体表格，方便大家按图索骥，后面再逐块拆开讲。
| 模块 | 3.4主要变化 | 直接受益角色 |
|---|---|---|
| APS排产 | 排产策略可配置、甘特图交互增强、手工拖拽与冲突检测 | 生产计划员、车间调度员 |
| 物联网 | 新增协议支持、物模型模板可复用、告警与消息通道扩展 | 设备管理员、IT运维 |
| 逻辑编排 | 新增定时触发器和HTTP节点、单节点调试、执行日志 | 业务人员、实施顾问 |
| 企业计划 | 计划模板库、审批留痕、目标拆解与执行跟踪看板 | 部门负责人、经营分析岗 |
| 底层能力 | 数据权限细化、开放API鉴权增强、列表批量操作优化 | 系统管理员、开发人员 |
一眼扫下来，你会发现这次的动作基本都集中在“让系统更贴近真实业务场景”上。接下来就按表格里的顺序，逐个模块说清楚。
2. APS排产：从固定规则到可配置策略
2.1 排产引擎的核心变化
先说APS排产。以前不少实施伙伴反馈，排产模块“排是能排，但规则一旦跟实际业务对不上，就要找开发改代码”。比如有的客户是订单驱动型，希望按交期从早到晚排；有的客户车间里有瓶颈工序，希望先卡瓶颈设备，再往前倒排；还有的客户客户经常临时插单，希望有一套优先级能随时调整的方案。
3.4版本把排产引擎的规则拆分成了可配置的策略集，规则不再写死在代码里，而是在界面上就能切换和组合。目前支持的核心策略包括：
- 按交期正排：适合订单稳定、产能相对充裕的车间，从当前时间开始，尽量往前排，确保订单早交付。
- 按瓶颈工序倒排：从交期倒推最晚开工时间，优先卡住瓶颈设备的排产负荷，前道工序向后排，后道工序能顺排就顺排。
- 优先级加插单策略：订单上可以设优先级，插单场景下不用全局重排，选择局部范围内的任务调整即可。
举个例子，某机加车间的情况是设备磨床是瓶颈，经常有急单插进来。原来用固定规则，计划员只能手动改来改去，还要防着漏改。现在是倒排策略配合优先级，把磨床负荷先算清楚，再推其他工序，插单也能快速算出对现有订单的影响，效率差得不是一点半点。
2.2 排产前必须维护好的基础数据
这里我必须唠一句实在话：排产质量不取决于算法，取决于基础数据质量。你工艺路线没建全，标准工时是拍脑袋填的，设备忙闲状态不同步，再好的排产策略排出来的计划也没法执行。车间不认，最后模块就会被弃用。
所以想用好APS，这类数据一定要提前捋清楚，建议按清单逐项核对：
- 产品工艺路线：每道工序的顺序、工作中心、是否有替代工艺。
- 标准工时：不要估算，最好是现场实测，哪怕是粗略的秒表测，也比凭空填准。
- 设备与班次：设备归属哪个工作中心、设备日历、每班有效工时、保养停机时间。
- 物料齐套：库存、在途量、采购周期，排产前要保证物料是“可承诺”状态。
- 订单状态：只有“已释放”的订单才会参与排产，之前有客户折腾半天发现订单还在草稿态。
有个细节特别值得提醒：设备编码不要乱起。什么1号机、2号机，换个人就不认识是哪个车间哪条产线的设备了。设备编码一旦混乱，产能统计、设备利用率全都会跟着错，这种基础问题到了排产阶段会被无限放大。
2.3 插单与重排的操作要点
重排是APS最常用也最让人担心的功能。全量重排一旦订单多，会导致很多在制的任务被挪来挪去，车间反而无所适从。3.4版本里针对这个问题做了两个交互上的改进：一是甘特图支持直接拖拽任务，计划员可以手工调整某一道工序的开始时间；二是拖拽调整后系统会做冲突检测，设备超负荷会标红并给出提示。
我建议生产计划部门把排产的操作习惯定成这个流程顺序：
- 先给订单设置优先级，把紧急插单和普通单分开。
- 排产时先锁定已开工/已领料的任务，避免被后续重排影响。
- 对未开工任务做局部重排，而不是全局无脑刷新。
- 手工调整后一定要看冲突检测的标红提示，确认没有新瓶颈再发布计划。
3. 物联网：把设备数据变成业务数据
3.1 新增协议支持与物模型设计
工业现场的设备接入，永远是物联网模块最头疼的事。这次3.4重点补了协议接入的覆盖面，Modbus RTU/TCP、OPC UA、MQTT网关、以及一批常见设备厂家的私有协议都可以直接对接。对实施项目来说，少写一个驱动就能省几天时间。
和协议配套的是物模型机制。老项目的同名设备，每个项目都要重新配一遍点位、属性、报警参数，费时费力。3.4的物模型把设备抽象成三类要素：属性（状态、温度、转速这类量）、事件（开关机、报警、故障）、服务（远程启停、参数下发）。同一型号的设备，物模型做一次，在多个项目里可以直接引用复用。
这个功能的实际价值要放到多厂区、多项目场景里才能体现出来。比如集团下面三个工厂都有同型号的空压机，老方案是每个工厂各配一遍点位表，新版本只要在总部维护好标准物模型，几个工厂一键就能用上，维护成本大幅下降。
3.2 点位表规范与采集链路
点位表的规范性，直接决定物联网项目交付是三天还是三周。我在现场帮客户排查数据采集问题时，有相当一部分原因是点位表混乱造成的：位号命名不统一，同一个温度点在A车间叫T-101，在B车间叫温度1，数据对不上也没法排查。
一个合格的点位表至少要包含这些字段：设备编号、点位名称、寄存器地址、数据类型、采集周期、单位、报警上下限、是否启用。采集链路大致是设备→网关→平台→应用，每个环节都要有日志，否则出了问题很难定位。
另外有个特别想提醒的点：采集周期不是越短越好。有客户上来就要1秒采集一次，结果数据量爆炸、数据库压力巨大，真正需要高频采集的场景少之又少。温度、液位这类过程量，1分钟采集一次完全够了；只有振动分析、瞬态电流这类特殊场景才需要毫秒级采样。点位周期设置逻辑，建议按数据用途来区分，不要一刀切。
3.3 告警与消息推送的进化
3.4在告警配置上做了不少细化，现在可以设置“持续确认时间”。比如某设备的温度超过80度，如果只闪了一下就恢复，就不触发；持续超过5分钟才确认是真正的高温告警。这个逻辑能过滤掉大量无意义的抖动告警，让报警真正变得可处理。
消息推送通道方面，企业微信、钉钉、短信、邮件都是现成的。但我要给个不太中听但实用的建议：告警通知一定要做分组和分级，不是所有设备报警都要推到所有人。第一时间的推送，只发给当班负责人；超过一定时间没确认，再升级到上一层管理岗。不然告警群会变成“信息轰炸群”，真出了事反而没人看。
4. 逻辑编排：把复杂场景拼成自动化
4.1 编排能力的实质增强
逻辑编排模块这次提升比较大。老版本里触发器类型有限，跨系统调用HTTP接口需要写脚本，实施顾问上手门槛不低。3.4重点补了几类高频节点：
- 定时触发器：支持Cron表达式，可以按业务节奏定时执行。
- HTTP请求节点：支持GET/POST，可以配置Header鉴权、超时时间、失败重试。
- 消息队列节点：支持常见消息队列收发，适合对接外部系统的事件流。
- 条件分支、循环节点：可视化配置，不用写代码。
这几个节点补齐之后，逻辑编排真正可以承担跨系统的自动化任务了。以前要写后端脚本才能完成的系统间动作，现在拖拖拉拉就能拼出来，而且每一步的入参出参都留得下来。
4.2 最典型的联动场景：设备报警自动建单
光说节点可能不够直观，我举一个在实际项目中跑通的场景，你就明白逻辑编排的价值了。
车间里一台温控设备发出高温告警，原来的处理方式是：设备管理员收到消息，登录工单系统人工创建维修单，再在微信群里喊人处理。这套流程看着简单，但在大车间里每天发生几次甚至十几次，重复劳动量不小。
用3.4的逻辑编排，把这个流程做成自动化：
- 触发节点：监听物联网模块的设备告警事件。
- 条件判断：温度超过阈值，并且持续5分钟未恢复。
- HTTP节点：调用工单系统的创建工单接口，把设备编号、告警内容、发生时间自动填入。
- 消息节点：企业微信推送消息给值班工程师，附带工单链接。
- 更新节点：把设备台账的状态字段更新为“待维修”。
整个编排跑起来，人工只需要处理最终生成的工单，前面全部由系统自动完成。这个场景已经帮客户省了不少事，而且因为每一步都有日志，出了问题追溯也方便。
4.3 编排调试中的经验
逻辑编排用得越多，越能体会调试能力的重要性。3.4版本支持单节点调试，这个功能很实用。以前全链路跑一遍，报错之后不知道是哪个节点出的问题，现在可以单独选中一个节点，手动填参数测试，确定没问题再放回流程里。
另外几个经验，是在现场趟过坑之后总结出来的：
- 循环节点一定要设置最大循环次数，否则数据异常时容易死循环，把编排服务拖垮。
- HTTP节点的超时时间要合理设置，别用默认值，外部系统慢的时候会大量堆积等待线程。
- 失败重试次数不要贪多，重试个两三次就够了，不然下游系统可能收到大量重复请求。
- 日志里要把关键节点的入参和出参都打出来，只看成功失败的标识排查不了问题。
5. 企业计划：让计划不锁在文件柜里
5.1 计划模板库与审批流转
企业计划模块在3.4之前，更多承担的是“计划表格线上化”的角色，离真正指导业务还有距离。这次更新先把模板库做起来了，市场类、研发类、生产类、供应链类的常见计划模板都有预置，企业可以基于模板快速搭建自己的计划体系，不用从空白表格开始一点点画。
计划编制完，审批流直接对接平台自带的流程引擎。什么意思呢？就是计划从草稿、到部门审核、再到分管领导审批、最后发布，整个过程在系统里全程留痕。以往用邮件传附件的方式审批，改来改去版本混乱，现在审批流把“谁改的、什么时候改的、审批意见是什么”全记录得清清楚楚。
5.2 目标拆解与执行跟踪
企业计划如果只是写个计划表，那价值几乎为零。3.4版本把计划指标做成了可拆解、可跟踪的结构。比如公司今年定的目标是“某产品线产能提升20%”，这个指标可以一级一级拆到车间产能目标、设备OEE提升目标、人员排班效率目标。指标拆下去之后，每个层级都有对应的执行看板，看板上展示的数据来源是各个业务模块的实际运行数据。
这种拆解最大的价值，是让目标和执行对得上号。很多人做计划是在年初写一份报告，然后一整年没人看。现在把计划指标和业务数据挂上钩，月底复盘时一眼能看出哪项指标没完成、卡在哪个环节、是哪个月开始偏离的，这就让计划真正变成了可以管理的对象。
5.3 企业计划与APS的衔接逻辑
3.4里还有一条隐线特别值得关注：企业计划模块里的生产计划，可以直接衔接APS排产。过去很多企业出现“办公室计划”和“车间排产”两张皮的现象，公司级计划做一套，车间实际排产又做一套，中间全靠人工翻译。
现在逻辑是：企业计划定的是“在什么时间点完成多少产量”的框架性目标，APS在这个框架下结合设备产能、物料齐套、工序约束排出可执行的生产任务。计划负责框定方向和边界，排产负责把计划转换成具体的开工指令，两层数据打通之后，管理口径和执行口径终于能对上了。
6. 容易被忽略的底层增强
6.1 数据权限细化
除了四个显眼的大模块，3.4版本在底层还有一些不那么显眼但很要命的增强。最值得一提的是数据权限。
以前平台的权限主要是功能权限，意思是有权限的人能打开某个菜单，但打开菜单之后能看到哪些数据，往往不好控制。3.4版本引入了行级的数据权限，比如可以配置“A车间的用户只能看到A车间的订单和工单”、“销售部门只能看到自己团队成员负责的客户数据”。这个功能对多组织、多法人、多厂区的集团型客户特别关键，直接决定了系统能不能在更复杂的组织架构里用起来。
6.2 开放接口与集成能力
另外，开放API这套东西在3.4里做了统一加固。新增了签名鉴权机制、调用频率控制、操作审计日志。如果你所在的团队经常要跟其他系统做集成对接，建议升级后重点测试这部分。API调用日志一定要留存一段时间，排查问题的时候没有日志寸步难行。
从开发角度看，这版接口文档的完整度也提升了不少，各模块的API示例都补齐了。给第三方便于调用，也给系统未来的集成留下了扩展空间。
7. 升级3.4前的准备与回退预案
7.1 升级前检查清单
关于升级，我强烈建议不要拿到安装包就直接在生产环境开干。升级前把准备工作做扎实，后面能少掉很多头发。
最基本的检查项：
- 备份数据库，备份配置文件，备份旧版本应用包，三者缺一不可。
- 检查服务器环境和依赖组件版本，确认和3.4的要求匹配。
- 浏览器建议用Chrome或Edge的较新版本，老浏览器可能会遇到页面兼容问题。
- 如果有基于旧API做的二次开发，提前看接口变更说明，避免上线后才能发现接口调不通。
7.2 功能回归重点
升级完成后别急着宣布完事，回归测试才是重头戏。按我的经验，至少要把这几条主链路跑一遍：
- 登录、权限分配、数据权限校验。
- 表单增删改查，尤其是常用单据。
- 流程审批是否可以正常流转，审批人能看到待办。
- APS排产是否可以正常输出排产结果，甘特图是否正常显示。
- 物联网设备是否还在正常上报数据，告警消息是否正常推送。
- 逻辑编排是否按旧的触发条件正常执行。
7.3 升级失败回退策略
再补一句回退的事。如果升级后发现问题要回退，新旧版本的数据结构往往不兼容，简单替换程序文件不够，还需要恢复升级前的数据库备份。所以升级窗口一定要选在业务低峰期，给回退留出足够操作空间，不要在工作日白天人多的时候搞升级。
8. 常见问题排查与避坑实录
这节把我在现场和社群里遇到的高频问题整理成一个速查表，希望帮你少走点弯路。
| 问题现象 | 可能原因 | 处理建议 |
|---|---|---|
| APS排产后没有结果，甘特图空白 | 订单未释放、工艺路线不完整、设备不可用 | 检查订单状态、工艺路线、设备日历，查看排产日志 |
| 物联网设备采集不上来 | 网络不通、协议参数错误、点位地址填错 | 先确认设备与网关连通，用调试工具读取数据，再配置点位 |
| 逻辑编排触发了一次但没执行完 | 某个节点超时，或配置了失败重试但重试也失败 | 打开执行日志定位失败节点，用单节点调试复现 |
| 企业计划审批流程卡住 | 审批人被禁用，或审批人未设置代理 | 检查审批人账号状态，查看流程节点日志 |
| 升级后页面白屏 | 浏览器缓存了旧静态资源 | 强制刷新清理缓存，或用无痕窗口确认 |
| 编排出现重复执行任务 | 重试次数设置过多，或消费端未做幂等 | 减少重试次数，并把下游接口处理逻辑改成幂等 |
8.1 别忽略现场验证
最后再补一个容易被忽略的经验。版本升级这件事，别全指望开发者的测试用例，也不要全指望实施方的“手工点点点”，最靠谱的是拿一条真实的业务数据链路，在一台测试环境里完整跑一遍旧版本能做的事情。
我在多个项目上验证下来，凡是升级前认真做回归的，上线后问题都少很多。凡是想着“改动不大，直接升吧”的，后面大多要花几倍时间补救。
8.2 先小范围试点，再全面推广
还有一点想特别强调：3.4版本里，APS排产策略和物联网联动的改动很深，这两块功能建议先在一个车间或一条产线做试点，验证数据质量和业务匹配度之后，再逐步推广到全厂。道理很简单：排产策略看着配置简单，但排出来的计划是否被车间接受，要在现场跑一两周才知道。物联网也是，先接一批关键设备跑稳了，再扩大接入范围，风险会可控得多。
升级不是把版本号改一改就会见效的事，把它当成一次面向业务的交付来对待，才是正解。
