把 OPC UA 连接到 Python pandas / Jupyter

开始之前

• 已安装 asyncua；如果你不喜欢在 notebook 中写 await，还需要同步封装。
• 对服务器的读取权限；如果它要求安全，还需要信任它的证书。
• 一个明确的问题。notebook 非常适合回答一个问题，却不适合长期运行。

配置方法

1. 在 notebook 中使用同步封装from asyncua.sync import Client 提供相同的 API 而不需要 asyncio，它在 Jupyter 自身的事件循环中的表现，远好于尝试嵌套一个事件循环。
2. 先收集到列表，再一次性构建 DataFrame每收到一次通知就向 DataFrame 追加一行很慢，而且不断分配内存。把通知缓冲在一个 dict 列表中，最后再构建 DataFrame。
3. 把状态码和两个时间戳都保留为列你会用到它们。一个悄悄对 UncertainLastUsableValue 取平均的分析会得出无人能为之辩护的数字，而丢弃状态之后你无法把它重建出来。
4. 按 SourceTimestamp 建索引，使用 UTC把它设为带时区的 DatetimeIndex。把来自多台设备的无时区本地时间戳混在一起，正是班次边界偏差一小时的由来。
5. 拉取历史数据，不要干等如果服务器支持历史访问，就读取一段过去的时间窗，而不是在订阅里坐等一小时。如果你需要班次聚合值，就让服务器计算 TimeAverage 或 PercentGood：它算起来比你便宜得多。
6. 可行之后升级为真正的采集器一旦 notebook 能够可重复地回答这个问题，就把逻辑迁移到一个带重连和监控的小型服务中。一台笔记本电脑上一直运行的 notebook，是一起等着合上盖子的生产事故。

地址空间是什么样子

你选中的内容，扁平化为列。如果先加载服务器的数据类型定义，结构化数值会解码为 Python 对象，随后你可以把它们规范化为列。只要你去浏览，伴随规范的结构是可获取的，但 pandas 不会替你保留它。

陷阱

• Jupyter 运行自己的事件循环，因此纯异步客户端在单元格中可能表现异常。同步封装可以完全避开这个问题。
• notebook 中的订阅会在内核重启时静默停止。以这种方式采集的任何数据集都会有缺口，而你直到画出图来才会注意到。
• 在检查状态码之前就重采样，是典型的分析错误：坏值和不确定值会被平均进一条看起来干净的曲线。
• 来自多台服务器的无时区时间戳无法安全比较。请在摄取时归一化为 UTC，而不是在绘图时。
• 对生产历史库发起长时间、无界限的历史读取，会招来一个电话。请给每一次请求设定边界。

从中获取 OEE 数据

适合在把 OEE 计算固化到平台之前做原型验证，也适合应对随之而来的关于定义的争论。用状态持续时间计算可用率，用声明的理想节拍计算性能，用不合格品计数计算质量，并把每一条假设都写在数字旁边的单元格里。它是建模工具，不是监控工具：一旦答案需要每个班次都存在，它就该放进一个服务里。

最后核对日期 2026 年 9 月 7 日，对照 OPC UA 1.05.07。OPC UA Connect 是教育资源，与 OPC Foundation 无隶属关系。