FactorySemantics MES 于 2026 年 10 月 13 日发布 v0.3.0。仓库把自身标为 pre-alpha，明确说明至今只运行过仿真工厂，没有真实工厂或真实工厂 PC 的运行验证。这次发布补上了一个直接影响试用的环节：六工位装瓶线的 plant pack 进入安装 wheel，Python 3.12 及以上环境可用 pipx install factorysemantics-mes 和 fsmes demo bottling 启动模拟班次、真实运行的 OPC UA 服务器及操作员页面；先前 0.2.0 的 PyPI 包没有打进这些 pack。[1][2]
这里的“真实 OPC UA 服务器”指协议端点由实际软件实现，生产数字来自确定性脚本，而非从真实生产线采集。0.3.0 能在普通计算机上重放 MES 数据链并核对出处。生产环境仍无验收记录。[1][1]
沿着一个瓶子的生产记录看数据怎样走
仓库架构文档给出车间设备/OPC UA 服务器、连接服务、内核和可选模块、数据库、API/操作界面、ERP 边界的逻辑图。应注意该文件自述初稿写于编码之前，某些图中的目录和进程划分是设计意图；实际源码以 src/fsmes/domain/、services/ 与 modules.py 的模块注册为准，不能照着图宣称每个模块已经独立部署。0.3.0 的笔记本模式是单进程配 SQLite，CI 另以 PostgreSQL 16.15 跑迁移和测试。[2][3][4]
一次采集可从 machine tag map 开始：OPC UA 客户端订阅设备状态、良品/废品计数和模拟量；映射文件把设备地址、状态枚举与业务名称联系起来。连接层读入通知，内核关联订单、工艺路线、工位和班次；生产模块只对正向计数增量记账，计数器归零时重新取基准而不凭空补产。随后质量检查、停机区间、批次消耗及维修工单进入同一数据库与审核记录，操作者在浏览器的时间轴或 SPC 图上可以下钻到原始读数、量具、机器状态和相邻事件。数据输入、推断关联、人员确认要分别保存，避免把脚本内预置的因果答案当作软件自动发现的事实。[1][2][3]
装瓶演示重放八小时：灌装机换线，冷却机维修单未执行，出口温度爬升，产品到灌装机的温度变化落后，后来灌装高度样本下降、低液位缺陷增加。发布说明说这条链是脚本刻意植入的测试，且灌装机自身没有越限。验收时分别找到工单状态、温度趋势、样本点和批次缺陷，记录时间差及关联证据。灌装机没有越限，质量问题仍可能出现；脚本设定的因果链不能直接套到现场。[1][1]
0.3.0 的质量层具体增加了什么
SPC 页提供单值—移动极差图、成组测量的 X̄/R 图和按批次不良件数计算的 p 图；规则 1—5 的触发按窗口留记录，规则 1—4 默认可引发 hold，移动极差规则默认不引发，以免历史测量突然淹没待处理队列。p 图仅画规则 1。一个点的详情包含该读数、触发规则、量具、当时机器状态及相关生产上下文。非符合项由 open 经 under review、dispositioned 到 closed，处置类型须写明 use_as_is、rework、scrap 或 return，并附理由。[1]
这套图表仍取决于样本定义：单值还是子组，子组大小是否稳定，不良“件数”与缺陷“次数”是否混淆，量具是否在校准周期内，批次与班次边界如何裁切。0.3.0 给生产记账、状态区间、质量检查和非符合项加上班次关联；无班次覆盖的时刻不会硬塞给邻近班次。比较两个班次的失控率前，先把采样频次、产量分母和缺测区间并列展示。[1]
OEE 也依赖明确的时间和产量口径。项目强调计数器复位不记账、停机原因未标注时维持未标注；当机器记账工作量与运行时间矛盾，0.3.0 会把性能/OEE 标为未知并附原因，而非继续显示大于 100% 的数字。工程试用应保存开停机时刻、计划停机、理想节拍、良品/废品计数的原始序列，再逐项复算可用率、性能与质量率；不同班制或排除规则下的 OEE 不能简单排名。[1][2]
连接器、代理和权限：读写边界在哪里
ERPNext 有订单级往返的证据：兼容性表记录针对 v15.120.0 的干净 CI 容器测试；Job Card 确认仍未实现。B2MML-lite 文件交换由本地测试覆盖；REST 测试对端是项目自带 mock ERP。Odoo、SAP、Oracle、NetSuite 连接器尚不存在。MQTT 双向功能在测试中使用假传输，没有真实 broker 跑过，故不能把“模块可见”写成与常见工业平台已互通。[1][4]
产品另有 MCP 工具界面，仓库称注册了 95 个工具，启用的模块和权限决定客户端实际能看到哪些。它把读工具与带幂等、dry-run/审批门槛的命令分开，操作可追到人员身份及审计记录。这里也要按证据等级阅读：兼容性表说真实模型对 live tool surface 的运行是一条人工命令，不是 CI 门禁；Claude Desktop 等客户端尚未测试。AI 图表问答需要 ANTHROPIC_API_KEY，项目给出的每问约 0.12 美元只是自身使用记录；另一位本地操作辅助依赖 Ollama。没有这些服务，工厂仿真核心照常运行。接入外部模型前，须审核工艺、人员和质量数据的出域合同、留存与脱敏策略。[1][2][4]
PLC 写回目前是受控建议队列，并非控制闭环。对候选真实工厂，项目的“first plant”指南建议旁路 shadow mode：IT 提供只读 OPC UA 身份和证书，工程人员给每台设备整理标签地址、状态含义与额定节拍，MES 与现有系统并行观察；指南自身尚未在真实工厂执行。项目推荐通过只读账户让服务器强制限制写入，并把 ERP 与 MQTT 模式保持关闭，避免把测试示例账号及明文演示 pack 带入现场。[1][5]
可在本机做的五项检查
先在独立 PC/VM 上准备 Python 3.12 或 3.13，用发布说明记录的安装命令安装 0.3.0；随后运行 fsmes demo bottling，查看 CLI 给出的 http://127.0.0.1:8010/dashboard，用演示输出的账号登录，结束后运行 fsmes demo bottling stop。这是演示账号与 loopback 地址，仅适合隔离测试。首次启动会在用户数据目录复制 pack、生成种子班次；Linux 通常在 ~/.local/share/fsmes，Windows 在 %LOCALAPPDATA%\fsmes，也可通过 FSMES_HOME 指定，便于测试结束后核对数据库、日志和生成数据的去向。[1][2][5]
第二，按页面逐条追踪灌装高度点、停机块和 p 图批次：记录原始读数、时间戳、量具、缺陷分母、维修状态与班次。第三，向仿真输入设计一张核算清单，检查计数器回退是否没有新增产量、缺失节拍是否返回 unknown、计划维护是否不被误报为故障。第四，把 pack 中的模块开关与 fsmes pack check 结果、实际显示的功能对应起来，避免把关闭的功能当系统故障。第五，在本地安全边界内尝试断开 OPC 连接和重新启动实例，比较采集空窗与审计记录。后面这些是建议的人工验收项目，并非发布说明列出的自动通过结果。[1][2][5]
如果要继续做现场旁路试验，应先由控制、IT、质量三方确定只读节点与服务器负载预算，启用 OPC UA 适当的签名和加密，安排证书信任、吊销和账号轮换。只将经批准的标签映射到最小数据集，并隔离演示默认密码；存储与备份须包含迁移前快照。0.2.0→0.3.0 需要 15 个迁移，含班次回填与量具预警窗口；项目仅证明一种 SQLite pack 形态的升级，没有在已装载数据的 PostgreSQL 工厂上验证升级。把可回滚的迁移演练列为下一个关口，比立刻接订单或写回 PLC 更可控。[1][4]
从仿真转向真实数据前的验收表
第一个表是“标签—含义—时间”。每个设备至少记录 OPC UA endpoint、namespace/NodeId、数据类型、采样或订阅频率、机器状态映射、计数器是否累计、复位条件、源时间戳与服务器时间戳的优先级。工程人员用真实设备清单签字确认这些信息，质量人员再决定一条样本属于哪个批次和班次。某个温度标签读数正常，并不足以推断产品温度正常；要给测点位置、输送滞后和量具校准建立映射。仿真故事中的 8.4→6.4 °C 与后续低灌装高度有脚本答案，真实现场则需排除传感器漂移、换料、速度变化和人为操作等竞争解释。[1][3][5]
第二个表是“事件—业务动作—权限”。订单释放、计数记账、质量 hold、非符合项处置、维修派工和班次修正各由谁发起、谁审批、如何撤回？只读影子实例的身份应无法写 OPC UA 节点，演示系统的操作员账号也不应被复用作业务账号。MCP 代理的工具权限要按与页面相同的角色和审计链验证：用无权限账号分别测试读取、dry-run、重复命令和实际提交，检查拒绝的动作同样留下可追查记录。对所谓“幂等”，还要界定客户端超时重试后的同一业务键，避免重复登记同一批次产量。项目提供设计与功能面，现场权限矩阵和威胁建模依旧由试用方承担。[2][3]
第三个表是“计算—分母—未知”。将原始计数和状态区间导出，由独立脚本人工抽查一个停机跨班次的样本、一个计数器复位样本、一个缺少理想节拍的样本和一个不良数量接近批次总量的样本。每个 KPI 旁保留观察区间、覆盖率与不可计算原因；若采集断线，先填数据缺口，再讨论生产损失。SPC 规则触发与是否发 hold 分开核查，并为处置理由和最终物料去向留出追溯字段。验收结果应能从页面一路返回原始样本，而不能只截图一张看似合理的 OEE 仪表盘。[1][2]
网络层还有专门的中止条件：只读账号被授予写权限、证书无法按期更新、采集客户端让现有 OPC 服务器出现明显负载异常、时区配置与厂区班次不一致，任一发生都暂停旁路接入。这些情况要有可执行的暂停和恢复流程。正式接入前，还需按项目升级文档对数据库备份、迁移和回退逐项演练；模拟线的成功启动只证明 wheel 和脚本在实验条件下能组成一套系统。[1][4][5]
演示数据、CI、模拟 ERP 和实验室 OPC UA 测试，可用于评估生产计数、设备状态、质量与维修记录能否沿同一时间轴对齐。正式生产数据的可靠性、网络与证书管理、操作权限、量具管理以及实际班次复算仍待现场证据，现阶段应维持 pre-alpha 与仿真工厂的准确表述。
参考资料
[1] FactorySemantics MES，v0.3.0 发布说明（2026-10-13）：https://github.com/factorysemantics/factorysemantics-mes/releases/tag/v0.3.0
[2] 项目固定版本 README：https://github.com/factorysemantics/factorysemantics-mes/blob/v0.3.0/README.md
[3] 项目架构文档（含设计与实际目录差异）：https://github.com/factorysemantics/factorysemantics-mes/blob/v0.3.0/docs/ARCHITECTURE.md
[4] 项目兼容性矩阵：https://github.com/factorysemantics/factorysemantics-mes/blob/v0.3.0/docs/operate/compatibility.md
[5] 项目首个工厂旁路试验指南：https://github.com/factorysemantics/factorysemantics-mes/blob/v0.3.0/docs/operate/first-plant.md