★ FEATURED ARTICLE 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排产策略和物联网联动的改动很深这两块功能建议先在一个车间或一条产线做试点验证数据质量和业务匹配度之后再逐步推广到全厂。道理很简单排产策略看着配置简单但排出来的计划是否被车间接受要在现场跑一两周才知道。物联网也是先接一批关键设备跑稳了再扩大接入范围风险会可控得多。升级不是把版本号改一改就会见效的事把它当成一次面向业务的交付来对待才是正解。
阅读完成 · 觉得有帮助？
