iaiops-plcnext · diff
git:20260902.be8ec1d to git:20260902.37050f2
6 added, 0 removed. Audit A to A.
---
name: iaiops-plcnext
description: >-
PLCnext / virtualized-PLC edition of iaiops — Phoenix Contact PLCnext Control
and vPLC (虚拟化 PLC) reached over its built-in OPC-UA server (opc.tcp 4840) and
Modbus-TCP process-data server, plus the cross-protocol brain (dataflow
diagnosis, downtime root cause, PdM, OEE, alarm, baseline). A packaging edition
— no new connector, no PLCnext-vendor SDK: it routes to the standard OPC-UA and
Modbus tools already shipped. Use when the task mentions PLCnext / PLCnext
Control / AXC F / vPLC / virtual PLC / 虚拟 PLC / Phoenix Contact controller over
OPC-UA or Modbus. Read-first; this edition's tool surface is read-only.
---
# iaiops-plcnext — PLCnext / vPLC edition(OPC-UA + Modbus + 脑)
启动:`IAIOPS_MCP=plcnext` / `iaiops-mcp-plcnext`(= opcua + modbus + 脑;等价
`IAIOPS_MCP=opcua,modbus`)。**打包型 edition**:PLCnext Control / vPLC 通过其**内置
OPC-UA server**(opc.tcp 4840)与 **Modbus-TCP 过程数据 server** 读取 —— 不新增 connector、
不依赖 PLCnext 厂商 SDK,直接复用已发布的标准 OPC-UA / Modbus 工具 + 跨协议脑。
## 工具
### OPC-UA(只读;PLCnext 内置 OPC-UA server,opc.tcp 4840)
- `opcua_server_info` / `opcua_browse` / `opcua_read_node` / `opcua_read_many`
- `opcua_subscribe_sample` `opcua_read_alarms` `opcua_alarm_events`(A&C 带时间戳) `opcua_read_history`(HDA)
- `opcua_diagnose_connection` — 连接失败归因(证书/策略/认证/网络/配置)
- `opcua_discover_tags` — 自动发现 + 语义资产建模;`opcua_health_summary` 阈值分类;
`opcua_anomaly_scan` 有界统计异常扫描
### Modbus-TCP(只读;PLCnext 过程数据 server)
- `modbus_read_holding` `modbus_read_input` `modbus_read_coils` `modbus_read_discrete`
- `modbus_detect_byte_order` — 字节/字序自动探测
- `modbus_list_templates` / `modbus_apply_template` — 厂商寄存器模板 → 命名 tag
- `modbus_health_summary` — 寄存器 vs 阈值分类
### 跨协议脑(永远随 server 暴露)
- 诊断:`diagnose_dataflow` `downtime_root_cause` `downtime_root_cause_live` `downtime_triage`
`learn_cause_weights` `rca_corpus_from_maintenance` `historian_health` `alarm_bad_actors` `tag_health`
`subscription_health` `heartbeat_health` `alarm_flood_analysis` `alarm_cascade`
`alarm_rationalization_worksheet`
- 预测维护:`pdm_forecast`
- 告警事件聚类:`alarm_event_clusters` — `alarm_bad_actors` 按**来源**排名,回答的是「哪台仪表最吵」,
不是「哪个故障最吵」;一个把同一条件写成十种说法的厂会得到十个 bad actor。这个按事件**说了什么**分组。
合并规则是**去掉大小写/标点/数字后的精确相等,不是相似度** —— 故意做笨,所以不需要模型、且可核对;
每个簇都列出被合并的原文与来源。**它不主张两条措辞不同的告警是同一个故障**,那由人判断。
- 数据质量:`data_quality_scorecard` `data_quality_fleet_rollup`
- 分析:`oee_compute` `downtime_events` `oee_multidim` `monitor_changes`
- 上下文基线:`baseline_learn_contextual` `baseline_check_in_context` —— 一个位号只学一条带,
在它有不止一个「正常」时就是错的(同一台干燥机 recipe A 走 180 °C、B 走 240 °C,一条带横跨两者,
于是两个工况都不可能出错)。**上下文由人声明,绝不推断**(D16);某个上下文历史太薄就**拒学**,
不借用别的上下文的样本;读数落在没学过的上下文里报 `unknown_context`,**绝不回落到全局带** ——
回落等于把「这个工况从没见过」说成「这个工况正常」。
- 上下游归因:`downtime_attribution` —— RCA 只按**时间**加权,所以一次上游停机会让每台下游设备
各自给出一个自信的本地根因。方向来自**声明的**产线顺序(D25:产线上共现是必然,拿它挖边等于
制造因果),顺序来自时间戳,**两者都要成立**;没声明关系就报 `not_evaluable` 并给出补法。
- 资产:`asset_inventory` `cross_protocol_asset_model` `adopt_alias_map` `diff_alias_map`
+ - 设备公告对照:`device_advisory_check` —— `scan` 早就在读 vendor/model/firmware,却什么都没做。
+ 这条把它接上,并**刻意停在漏洞扫描器会继续往前走的地方**:只报「落在公告声明的版本范围内」,
+ **不说「可利用」、不给严重度** —— 可达性与补偿控制决定那件事,而只读扫描看不见它们。
+ **不内置任何 CVE 库**(过期却看着像最新的库比没有更糟),由现场挂载文件、离线可用,每条必须带来源。
+ 读不出固件报 `version_unknown`,读得出但排不了序报 `version_unparsed` —— 都不算通过;
+ 公告没提到的设备**不出现在结果里**,那是「未知」不是「没有」。
- 基线:`baseline_learn` `baseline_check` `baseline_record_change` `baseline_status`
- 合规/信创:`compliance_mapping` `compliance_frameworks` `compliance_dengbao_levels`
`compliance_report` `compliance_evidence_bundle`
`historian_push` `export_data` `historian_query` `historian_coverage` `stream_publish` `uns_publish`
`stream_publish_event` `rca_narrate` `fleet_status` `fleet_incidents`
- 程序解读:`plc_program_outline` `plc_program_xref` `plc_program_section` `plc_program_visibility`
(解读导出的 ST/AWL/L5X;PLCnext 工程可导出 IEC 61131 ST 文本后离线解读)
- 程序变更基线:`plc_program_snapshot` `plc_program_drift` `plc_program_history` — 把「认可的那一版」
的结构记下来(文件 SHA-256 + 每个 block 的结构指纹:声明/调用/分支条件/定时器,**不含行号、注释、
block 顺序**,所以在文件顶上加一行注释不会把整份程序报成变更),之后问某一次导出**动没动**。
三个判词咬得很紧:`identical` **只**由 SHA-256 相同得出;`logic_changed` 逐 block 指出哪一类变了;
`changed_outside_extracted_structure` = 字节变了而结构指纹全同 —— 多半是注释/排版,但这些 parser
是结构抽取不是文法,**所以它不叫「仅文档」,也不构成放行**。删历史只在 CLI(`iaiops program forget`):
删变更控制证据不该离 agent 只有一次调用。存的是 block 名 + 哈希 + 计数,**不落声明、源码行和注释**。
- 自证:`verify_determinism` — 把「拿掉模型、断网、同一份数据重跑、输出逐字节相同」**跑出来**:
固定数据集过一遍分析层,规范化后取 SHA-256,在本进程跑两遍、再在两个不同 PYTHONHASHSEED 的
全新解释器里各跑一遍(这一臂才抓得到集合/字典迭代顺序渗进结果),全程 socket 抛异常。
给 CSV/验证团队的是一条能写进 IQ/OQ 的测试用例,不是一句形容词。
- 元:`protocols_supported`(产品能做什么)· `site_readiness`(这个站点今天能跑什么、还差什么;零联网)
- 调查层(§13,八步证据闭环):`investigation_readiness` `investigation_open` `investigation_show`
`investigation_list` — 「真出事时这个站能走到第几步、每个缺口还差什么」,以及对一个**已过去的窗口**
逐步走完并留档(不碰设备)。缺口分两种:**你没供**(给命令) 与 **产品供不了**。
- 产线关系与机制库:`line_relation_declare` `line_relations_list` `mechanism_library_check`
`mechanism_library_list` — 上下游由**人声明**(D25:线上下游共现是必然,推不出因果);
机制库按 ISO 14224 分 mode/mechanism/cause,**可排除、绝不确认**,
库里没有这条原因 → `nothing_known`(不是「无异议」)。
## Workflows
1. **Doctor-first**:`protocols_supported` → `iaiops doctor` → `opcua_diagnose_connection`
(先确认 PLCnext 内置 OPC-UA server 4840 可达、证书/策略匹配)。
2. **Read-first**:过程量走 OPC-UA `opcua_read_many` / Modbus `modbus_read_holding`;
"没数据"用 `diagnose_dataflow`,停机用 `downtime_triage` / `downtime_root_cause_live`。
3. **只读**:本 edition 工具表面全只读。若需写(输出/设定值),切到含写工具的 profile 并走统一
MOC:`risk=HIGH` + 默认 `dry_run=True` + 改前值 undo + `iaiops approve` 具名审批双确认。
## 支持版本矩阵(内部 HLD §8,设计文档不随本仓发布;`待核实` 不得当既成事实)
| 协议 | 库(pin) | 规范/版本 | 覆盖 | 传输 | 自测 |
|---|---|---|---|---|---|
| OPC-UA | `asyncua>=2.0,<3` | OPC UA 1.0x(DA+HA+AC 子集) | PLCnext 内置 OPC-UA server | opc.tcp/4840 | ✅ mock+HDA;真 PLCnext 待核实 |
| Modbus-TCP | `pymodbus>=3.5,<4` | App 1.1b3;FC 1/2/3/4/5/6/15/16 | PLCnext 过程数据 server | TCP/502 | ✅;真 PLCnext 待核实 |