跳到主要内容

升级说明

本文档详细列出了升级版本时需要同步修改的集成项以及首次启动时发生的变更。 具体升级步骤(重新执行安装 one-liner)请参阅 升级。 最新版本显示在最上方。

2026.11 — 升级前准备与名称变更​

支持范围

支持范围为 2026.11 之后的最近 3 个版本。2026.10 及以下版本无法直接升级,请重新安装(尝试升级将导致失败并自动回滚至原版本)。请参阅 升级。以下名称变更和集成变更在重新安装时同样适用。

请按以下顺序进行准备。Cassandra 一旦升级则无法回滚,且变更后的名称不具备兼容性 —— 旧路径、旧字段、旧工具名称将在升级瞬间消失,因此必须将集成系统与服务器同步升级。 现场应用 也请同步升级至相同版本。工单数量与名称变更详见 下一节。

1. 备份 — Cassandra r4 无法回滚​

本版本的 Cassandra 主体为 Aster TSDB v6.0.0-r4。

一旦升级至 r4,节点将无法回滚至 r3 及以下版本

由于集群元数据快照格式发生变化,旧版本主体无法读取。如需保留回滚路径,必须在升级前完成备份。

  1. PostgreSQL 全量备份 — ./backup.sh --postgres full
  2. Aster TSDB 全量备份 — ./backup.sh --cassandra full(备份与恢复)
  3. 复制每个节点的 Cassandra 数据目录下的 system_cluster_metadata
  4. 完成上述步骤后,安装新版本

2. 迁移 V121~ — 首次启动时间可能较长​

首次启动时,Flyway 将一次性应用 V121~V152。此阶段包含大规模结构变更,如报警表整理 (V121V124)、五层设备树 (V137V139)、记录表键与维护名称 (V140) 以及外键 (V127~V133) 等。由于 V123 会修改 mm_alarm 的所有行,因此所需时间将随报警行数增加而增长。在此期间服务器将不响应,健康检查可能会先触发 unhealthy —— 请勿重启容器,请等待日志出现 Flyway migration completed.。

如果存在不符合条件的数据,迁移将停止且服务器无法启动。停止步骤的变更将被回滚,而之前的步骤将予以保留。请根据日志中 Platform version update failed 之后的提示修正数据后再次启动,迁移将从该步骤继续。升级前可通过以下 SQL 在数据库中预检:

-- V121: 0 행이어야 합니다 — 숨겨진 채 켜져 있는 알람
SELECT alarm_seq FROM pp.mm_alarm WHERE shelved AND is_on;

-- V121: 0 이어야 합니다 — 숨겨진 알람에 확인 · 라벨이 붙은 행
SELECT count(*) FROM pp.mm_alarm
WHERE shelved AND (is_read IS TRUE OR read_user_id IS NOT NULL OR disposition IS NOT NULL
OR cause_note IS NOT NULL OR labeled_by IS NOT NULL OR labeled_at IS NOT NULL
OR failure_record_id IS NOT NULL);

-- V128: 0 이어야 합니다 — 고장 기록을 가리키지 못하는 알람 연결
SELECT count(*) FROM pp.mm_alarm a
WHERE a.failure_record_id IS NOT NULL
AND (a.failure_record_id !~ '^[0-9]{1,18}$'
OR NOT EXISTS (SELECT 1 FROM pp.mm_ram_failure f WHERE f.failure_id = a.failure_record_id::bigint));

-- V137: 1 행이어야 합니다 — 설치당 기업은 하나
SELECT enterprise_id FROM pp.mm_enterprise;

3. 名称变更 — 不支持旧名称兼容​

系统不再接收也不返回旧名称。旧 V5 路径将返回 404。

维护 «记录» 已改为 维护 «工单»。

位置旧名称新名称
V5 路径/api/v5/maintenance-records…/api/v5/maintenance-orders…
V5 路径/api/v5/asset/{asset_id}/maintenance-records/api/v5/asset/{asset_id}/maintenance-orders
MCP 工具list_maintenance_recordslist_maintenance_orders
字段 · 查询record_idmaintenance_order_id — 数字 → 字符串
字段 · 查询kind · status · cancel_reasonmaintenance_kind_code · status_code · cancel_reason_code
字段failure_idfailure_record_seq
字段plan_id · plan_namemaintenance_plan_id(数字 → 字符串) · maintenance_plan_name
字段 · 查询failure_mode · failure_mechanism · failure_cause · maintainable_item后接 _code。显示名称 *_name 和 cause_code 保持不变
字段checklist_results[].attachment_idchecklist_results[].maintenance_attachment_seq
附件响应attachment_id · record_idmaintenance_attachment_seq · maintenance_order_id
列表 sort 值status · kindstatus_code · maintenance_kind_code
维护计划日历record_id · record_status · open_record_id · open_status · record_idsmaintenance_order_id · maintenance_order_status_code · open_maintenance_order_id · open_status_code · maintenance_order_ids
DB 表mm_maintenance_record · mm_ram_failuremm_maintenance_order · mm_failure_record

请勿将 maintenance_order_id · maintenance_plan_id 视为数字进行读取或比较。旧行是保留编号的字符串("12"),新行为 MAINTENANCE_ORDER_000013 格式。

CMMS Webhook 键(PP_MAINTENANCE_WEBHOOK_URL) — 请先修改接收端。

旧键新键值
record_idmaintenance_order_id字符串
kindmaintenance_kind_code相同
statusstatus_code相同
failure_modefailure_mode_code相同
cancel_reasoncancel_reason_code相同
plan_idmaintenance_plan_id字符串
checklist_results[].attachment_idchecklist_results[].maintenance_attachment_seq相同

text · event · asset_id · asset_name · description · requested_by · accepted_by · assignee_employee_id · external_system · external_id · owner · anomaly_found · plan_due_at · at · version 保持不变 — CMMS Webhook。

其他记录键与 ID 字段。

位置旧名称新名称
/ram/failures…failure_id · asset_class · equipment_class · code_statusfailure_record_seq · asset_class_code · equipment_class_code · raw_code_status_code
/ram/failures…failure_mode · mechanism · iso_cause · maintainable_itemfailure_mode_code · failure_mechanism_code · failure_cause_code · maintainable_item_code
故障 · 维护代码映射map_id(数字)fault_code_map_id · maintenance_code_map_id(字符串)
/defects…defect_iddefect_record_seq
/order/{id}/notes · /progressnote_id · progress_idorder_note_seq · order_progress_seq
/alarm/config/{id}/revisionsrevision_idalarm_config_revision_seq
班计划区间generation_idasset_plan_generation_seq
报警 labelfailure_idfailure_record_seq

设备 · 站点。

旧名称新名称备注
table_typeasset_class_code界面术语为 «设备分类»。表 mm_asset_class 的代码字段为 code
站点 statusoperational_status_codeACTIVE → IN_OPERATION, INACTIVE → OUT_OF_SERVICE, CLOSED → DECOMMISSIONED。所有层级的公共字段
树结构仅限 区域·线路·设备企业 → 站点 → 区域 → 线路 → 设备asset_type 中新增 E · S。统计设备数量时请过滤掉

ID 格式。 新创建的 ID 为 域全名 + 6位数字。现有 ID 依然有效且不变更。请勿通过 ID 前缀判断层级或类型,请读取 asset_type。

域旧格式(继续有效)新格式
区域 · 线路 · 设备ASSET_…AREA_000001 · LINE_000001 · EQUIPMENT_000001
工单ORD_…ORDER_000001
日历 · 班次异常CAL_… · OV_…CALENDAR_000001 · SHIFT_OVERRIDE_000001
设备关系 · 工序段REL_… · SEG_…ASSET_RELATION_000001 · PROCESS_SEGMENT_000001
命令区域 · 设备命令CMDAREA_… · CMD_…COMMAND_AREA_000001 · ASSET_COMMAND_000001
图像IMG_…IMAGE_000001
员工EMP_…EMPLOYEE_…
报警设置ALARM_CONFIG_00375 · ALARM_CONFIG_<태그 ID>ALARM_CONFIG_000376

编号可能为空,超过 999999 后位数将增加。详情请参阅 域 ID 规则。

报警设置。

  • 在 POST /alarm/config 中输入自定义 ID 将触发 422 alarm.invalid.alarm_config_id。新 ID 通过 GET /alarm/config/new-id 接收。旧格式 ID 仅支持修改。
  • 频带报警设置每个标签仅限一个。第二个将触发 409。EQL 报警设置数量无限制。
  • 请勿尝试使用 ALARM_CONFIG_<태그 ID> 定义频带报警设置 ID 进行查找。新设置不存在该名称。请在 GET /alarm/config/list/by-tag?tag_id=… 中查找 alarm_config_priority 为 BAND 的项。

语句必填字段​

保存时将根据类型检查必填输出字段。缺失时将以 422 asset_statement.eql.missing_columns 拒绝,并告知缺失字段。

类型必填字段
EVENTtimestamp · plugin · name · color · from_timestamp · to_timestamp · value
CONTEXT · AGGREGATION · COMMANDtimestamp · plugin · key · value

已保存的语句不会因升级而被删除或停止,将在启动时原样部署。但缺失必填字段的语句此前且现在均无法记录结果 — 每项事件将标记为失败,并开启诊断 diagnostic.asset.statement_failing。此类语句在修改并保存时会触发上述检查,必须填充字段后方可保存。升级后请在诊断界面查找该代码进行修正。

4. 诊断 — CEP 死信队列仅保留 24 小时 · 256 MiB​

CEP 无法处理的事件死信队列(PP:CEP-DEAD-LETTER)现在设有时间与字节上限。超过 24 小时 或总计超过 256 MiB 时,将从最旧项开始删除。仅包含投递三次后仍未处理的事件。若要调查失败事件,请在该范围内查看 — 数据保留。

5. CEP — 不再提供 Esper 后端与单条语句 CPU 指标​

cep.backend 的值为 aster · flink 之一,未设置则默认为 aster。标准部署模板为 cep.backend=aster,未手动修改安装的用户无需操作。

设置为 cep.backend=esper 将导致 CEP 无法启动

启动将因值不匹配(如拼写错误)而停止。升级前请在 plantpulse-cep.properties 中将该行改为 aster 或将其删除。

  • 使用 Esper 运行的安装,请在升级前通过 GET /api/v1/eql/portability 确认 Aster CEP 无法接收的语句。无法接收的语句将不被删除,并作为 REJECTED 保留 — 限制与拒绝令牌。
  • GET /api/v1/eql/{name}/metrics 已移除。单条语句 CPU · 墙钟时间将不再提供 Gauge · REST · 控制台面板 · 存储支持。语句指标请参考 GET /api/v1/eql/metrics/snapshot 的匹配率 · 输出率。PlantPulse Dashboard 的 EQL_CPU_TIME 面板将不再有数值。
  • 已移除的配置读取代码:cep.ha.* · cep.monitor.statement_metrics_enabled · cep.monitor.cpu_estimate_max_error · cep.performance.cpu_warn_threshold_ns · cep.performance.wall_warn_threshold_ns · cep.storage.max_inflight_writes。规则状态保留为 cep.aster.state.* — 属性参考。

6. 升级后操作​

  • 在设置界面填写 PP_UI_CONSOLE_URL。若为空,报警邮件将无链接,且无法创建 QR 标签。若使用现场应用,还需填写 PP_UI_FRONTLINE_URL。
  • 所有站点的 QR 公开页面默认为 关闭 状态。
  • 修复了设置界面 MAIL_SMTP_* 值不生效于发送的问题,以及 STARTTLS 因 «No appropriate protocol» 而失败的问题。邮件可能会实际发送,请核对设置 — 邮件设置。

在 2026-11-05 之前的 2026.11 版本中应用的插件 — RAM_FAILURE_CODE_TAG 和 OEE_PRODUCT_BAD_COUNT_CODED 仍保留旧语句,监听的是不存在的标签(<标签>_CODE、<标签>_CAUSE)。仅重新应用时会显示«已存在(跳过)»,语句不会改变。请先删除这些语句(DELETE /api/v5/asset/{asset_id}/statement/{statement_name}),再重新应用插件并选择代码标签和不良原因标签。其他语句保持不变。重新应用之前发生的故障仍然没有代码。如果代码标签确实以 <故障标签 ID>_CODE 存在且一直运行正常,则无需处理。

2026.11 — 工单数量与名称改为 ISA-95 / B2MML​

工单数量已从 «单一数字» 更改为 数值 + 单位对象(ISA-95 / B2MML QuantityValueType)。 字段名称也更改为 ISO 22400 术语,不良品分为报废与返工。同一版本的工单、日历、客户、产品字段名称同步更改为 ISA-95 / B2MML 名称(title → order_name, fix_start_timestamp → planned_start_timestamp …,详见下方 名称变更)。 不支持兼容字段·兼容路径·别名 — 读取或发送旧名称的集成系统必须随升级同步修改。

基准: V5 API 5.0 · 数量协议 2026-10-30 · 名称波段 2026-10-31 · server-web 974891b4(数量波段从 30b7d9af 起) · Flyway V99·V100·V103 · core 迁移 V12V16·V21V23 · 事件模式 plantpulse.order.*·plantpulse.calendar.* major 2, plantpulse.kpi.oee.finalized major 1。

变更详情​

领域变更内容详细说明
V5 数量字段target_units+unit → planned_quantity, total_good_count → good_quantity, total_bad_count → scrap_quantity, total_production_count → produced_quantity 等。值为 {quantity_string, data_type, unit_of_measure} 对象Order 服务 — 数量
报废 · 返工scrap_quantity 仅指报废(ISO 22400 SQ),返工为新字段 rework_quantity(RQ)。旧 total_bad_count 为不良品合计 — 如需合计,请将两者相加。界面中仅报废位置显示 «报废»,合计位置显示 «不良»Order 服务 — 报废与返工
单位允许 UN/ECE Rec 20 中的 13 个单位(EA·H87·C62·BX·SET·KGM·GRM·TNE·LTR·MLT·MTQ·MTR·MTK)。业绩仅接收工单单位(不进行换算)。拒绝时返回 422 E1002 + reason(quantity.unit_mismatch·quantity.not_integer …)Order 服务 — 请求规则与拒绝
产品默认单位产品的 unit_of_measure 成为新工单的默认单位。旧值迁移至代码(BOX→BX, KG→KGM, PCS·개→EA …),未知值为 «无单位»(该产品的新工单为 EA)生产管理 — 数量与单位
优先级priority 改为 B2MML Priority 整数(1 紧急·2 高·3 普通·4 低, 数值越小优先级越高)。旧 URGENT·HIGH·NORMAL·LOW 迁移至 1~4
期间 KPI单一单位时保留数值 + unit_of_measure, 混合单位则不合并且显示 quantities_by_unit同上
EMS 单位值energy_per_unit_kwh·co2_per_unit_kg 旁增加分母单位 unit_of_measure同上
名称 (工单·日历·客户·产品)title → order_name, fix_start_timestamp/fix_end_timestamp → 工单为 planned_start_timestamp/planned_end_timestamp, 日历为 start_timestamp/end_timestamp, external_order_id → external_id, external_po_id → customer_po_id, 客户·产品的 external_customer_id/external_product_id → external_id(+ external_system)。涵盖 V5·SDK·事件·MCP·流节点·DB 字段。无别名名称变更
外部工单标识(external_system, external_id) 对。V5 POST·PUT·PATCH /order 同时接收并载入响应·业绩文档。将 GET /order/performance/by-external/{external_order_id} 删除并改为 …/by-external/{external_system}/{external_id}。单个工单为 GET /order/by-external/{system}/{external_id}MES 集成
事件plantpulse.order.* 中增加 planned_quantity_unit_of_measure·external_system, plantpulse.kpi.oee.finalized 中增加 *_quantity + 正本 unit_of_measure 及返工 rq·rq_quantity。在末尾追加,不变更类型。因名称变更,plantpulse.order.*·plantpulse.calendar.* 为 模式 major 2(dataschema 末尾为 :2)Order 服务 — 数量
流 (Flow)OEE_EVENT 的数量改为 Quantity 对象(新增 rework_quantity)。flow_create_work_order 单位值为必填(路径 unit_of_measure_field, 默认 data.unit_of_measure)。该节点的路径设置名称同步变更(title_field → order_name_field …)流
界面每个数量后随附单位符号(与语言无关 — EA, kg, L, m² …)。工单表单增加单位字段生产管理 — 数量与单位

数值本身不发生变化。升级前的工单全部迁移至 EA,由于整数数量不变,OEE·可用性·性能·质量及数量合计在升级前后保持一致。返工量通过现有 REWORK 不良记录之和填充(若无则为 0),对应的 scrap_quantity 将比旧 total_bad_count 减少相应数值。

名称变更 — 旧名称与新名称​

工单与日历的字段名称已统一为 ISA-95 / B2MML 名称。Wire·SDK·事件·DB 字段均使用相同的新名称,不支持旧名称别名·兼容视图或双写(server-web 974891b4, Flyway V103 order_calendar_names_isa95)。

旧名称新名称变更位置
titleorder_name工单 — V5 请求·响应·/order/query 行, SDK setOrder_name, 事件 plantpulse.order.*(附加至所有类型, 含 deleted), MCP list_work_orders·get_work_order_kpi, DB mm_order·mm_order_revision, Cassandra tm_asset_order
fix_start_timestamp / fix_end_timestampplanned_start_timestamp / planned_end_timestamp工单 — 同上。MCP 的 fix_start_at/fix_end_at 为 planned_start_at/planned_end_at
fix_start_timestamp / fix_end_timestampstart_timestamp / end_timestamp日历 — V5 请求·响应·修订历史, SDK setStart_timestamp/setEnd_timestamp, 事件 plantpulse.calendar.created·updated·entry.*, DB mm_calendar·mm_calendar_revision·mm_shift
target_unitsplanned_quantityDB 字段 mm_order·mm_order_revision·mm_order_oee。V5·SDK·事件已改为 planned_quantity
external_order_idexternal_id工单 — V5 请求·响应·业绩文档·/order/query 过滤器, SDK setExternal_id·OrderQuery.externalId(..), 事件, MCP get_work_order_kpi, DB
external_po_idcustomer_po_id工单 — V5 请求·响应·业绩文档, SDK setCustomer_po_id, 迁移事件(started~aborted), MCP, DB
external_customer_id / external_product_idexternal_id + 新字段 external_system客户·产品 — V5 请求·响应, SDK, DB。新增双向查找 GET /customer/by-external/{system}/{external_id}·/product/by-external/…
baseline_fix_start / baseline_fix_endbaseline_planned_start_timestamp / baseline_planned_end_timestamp工单 deviation 对象(V5·SDK·MCP)
排序 fix_start_desc / fix_start_ascplanned_start_desc / planned_start_asc/order/query 的 sort
流 title_field · target_units_field · external_order_id_field · external_po_id_fieldorder_name_field · planned_quantity_field · external_id_field · customer_po_id_fieldflow_create_work_order 节点设置。默认路径同步改为 data.order_name · data.planned_quantity · data.planned_start_timestamp · data.planned_end_timestamp · data.external_id · data.customer_po_id

系统不再接收旧名称 — 部分位置会被静默忽略,请优先修改集成项。

  • 在 POST·PUT /order 中发送旧名称将导致该字段无法被读取。由于 order_name 为空,将触发验证错误而被拒绝(order_name 为必填且不可为空 — order.name.required),计划时间也将变为数值空。混合发送新旧名称虽可保存,但 PUT 会替换整个请求字段,因此以旧名称发送的 external_order_id·external_po_id 将被删除。
  • 在 PATCH /order 中发送旧名称将返回 422 «not patchable」。
  • /order/query?external_order_id=… 不会被忽略,将直接以 422 拒绝 — 请使用 external_id 和 external_system。
  • 事件仅以 major 2 发出。major 1 模式文件仅保留用于回放,新发出的事件载入新名称。
  • /kpi/* 响应与 plantpulse.kpi.oee.finalized 的字段名称不在此次变更范围内(保持不变)。

升级前 — 外部标识对重复校验​

新版本将对外部标识对均不为空的工单建立唯一性索引(Flyway V100, ux_mm_order_external_pair)。 若存在两个及以上工单具有相同标识对,升级步骤将失败,请在升级前校验。 以下 SQL 应在升级前的数据库中运行,因此使用旧字段名称 external_order_id (V103 将在随后将其改为 external_id)。

SELECT external_system, external_order_id, count(*)
FROM pp.mm_order
WHERE external_system <> '' AND external_order_id <> ''
GROUP BY 1, 2
HAVING count(*) > 1;

结果应为 0 行。若出现行,请修正其中一方的 external_system 或 external_order_id 后再升级。 仅有 external_order_id 而 external_system 为空的工单不构成标识对,不在此校验范围内(保持原样)。

首次启动流程​

存储库时间点变更内容
PostgreSQLserver-web 启动(Flyway V99 order_quantity_isa95 · V100 order_external_id_pair_unique)将数量字段改为 numeric(18,4),并将每个工单的 unit_of_measure 填充为 'EA'。累加 mm_order_oee.total_rework_count 并填充为 REWORK 不良记录合计。将产品单位迁移至代码并将 priority 改为整数
PostgreSQL随后的 Flyway V103 order_calendar_names_isa95将上述 名称变更 表中的 DB 字段改为 RENAME COLUMN — 随之迁移数据·索引·约束·视图。客户·产品增加 external_system 字段与双唯一索引(现有行的系统项留空)。若工单 status 在 WAIT·START·PAUSED·END·ABORTED 之外则停止。通过触发器确保状态变更仅与修订行同步发生
Cassandra · 存储 EQL平台首次启动(core V21~V23)在 tm_asset_order 中增加 order_name·planned_start_timestamp·planned_end_timestamp 并迁移旧字段值(V21·V22, 耗时数秒, 不删除旧字段)。将存储的设备语句(EQL)中的旧属性名称改为新名称(V23, SYSTEM 修订) — 未能修正的语句保留为诊断 diagnostic.asset.statement_not_renamed
Cassandra平台首次启动版本迁移在小表(OEE·EMS 的 current·order, tm_asset_order)中增加新 decimal 数量字段与 unit_of_measure 并填充现有行('EA') — 耗时数秒。大表(OEE·EMS 的 rolling·rollup·history, tm_kpi_oee_count)将在启动后的后台执行迁移。启动过程与平时一致
  • 在大表迁移期间,历史 KPI 将以相同数值从旧字段读取。各表迁移完成后自动读取新字段。进度可见于 server-web 启动日志中以 «Cassandra migration» 开头的行(docker logs plantpulse-server-web | grep 'Cassandra migration')。
  • 旧整数字段(target_units·total_production_count·total_good_count·total_bad_count)在迁移结束后将不再被读写。删除字段将在后续版本中进行。 新安装的集群中不包含这些字段。

集成项修改清单​

  • SDK — 将 plantpulse-api 升级至新版本。setTarget_units(…)/setUnit(…) 已移除 → setPlanned_quantity(Quantity.of("500", "EA"))。
  • V5 响应读取代码 — 将旧字段名称(target_units, total_good_count, total_bad_count, total_production_count, good_count/bad_count(数量记录), out_of_plan_*_count …)改为新名称。数值不再是数字,而是 quantity_string 字符串 — 请勿转换为 double,应以 10 进制类型读取。
  • 不良合计使用点 — 若仅将旧 total_bad_count 改为 scrap_quantity,则会缺失返工量。如需不良合计,请计算 scrap_quantity + rework_quantity。
  • 拒绝处理 — 数量拒绝返回 422 E1002, 分支通过响应的 reason(quantity.*)判定。在数量字段直接输入数字将触发 400 E1000。
  • 业绩·校正输入 — 按工单单位发送。在计数单位(EA·H87·C62·BX·SET)发送小数将触发 422 quantity.not_integer。
  • 期间 KPI 合并界面·报表 — 若 good_count 等为空,则查看 quantities_by_unit。不得合并单位不同的数量。
  • 名称变更 — 在处理 V5 请求·响应的代码中,将 title·fix_start_timestamp·fix_end_timestamp·external_order_id·external_po_id(工单), fix_start_timestamp·fix_end_timestamp(日历), external_customer_id·external_product_id(客户·产品) 改为新名称。因无别名,必须与服务器同步升级。
  • SDK Setter 名称 — setTitle→setOrder_name, setFix_start_timestamp→setPlanned_start_timestamp(日历为 setStart_timestamp), setExternal_order_id→setExternal_id, setExternal_po_id→setCustomer_po_id, OrderQuery.externalOrderId(..)→externalId(..)。
  • MES 业绩采集 — 将通过外部编号查找的调用改为 by-external/{external_system}/{external_id}。创建工单时同步填入 external_system。
  • 直接读取 PostgreSQL 的 SQL — 计划数量为 mm_order.planned_quantity(旧 target_units),且在字符串中变为 numeric (读取为字符串呈现 '1200.0000' 格式)。mm_order_oee 的数量字段从 bigint 变为 numeric(18,4)。单位为新字段 unit_of_measure。此外,上述 名称变更 表中的 DB 字段名称均已变更。
  • 流 (Flow) — 读取 OEE_EVENT 的脚本改为 data.payload.good_quantity.quantity_string。在 flow_create_work_order 节点中填充单位路径。在上述节点中直接填写 title_field·target_units_field·external_order_id_field·external_po_id_field 的流将无法读取该配置并使用新默认路径(data.order_name …),请使用新配置名称重新填写。读取工单·日历事件旧键的脚本亦需改为新名称。
  • 设备语句(EQL) — 升级后若诊断界面出现 diagnostic.asset.statement_not_renamed,请手动修正该语句的旧名称(fix_start_timestamp·title·external_order_id …)。
  • 事件消费者 — plantpulse.order.*·plantpulse.calendar.* 读取 major 2 的新键(planned_start_timestamp·external_id·order_name …, 日历为 start_timestamp·end_timestamp)。plantpulse.kpi.oee.finalized 读取 *_quantity 字段。sq 仅指报废,返工为 rq。整数 gq·sq·rq·pq 在小数单位中不再携带,并将在下一 major 版本中移除。