产线上有检测数据、LOT 信息、CPK 报表，但散在各自的 SQLite 里。Online 做一件事：把这些数据自动收拢到工厂服务器，统一查询、统一分析、统一对外输出。
产线越多，数据越散
一条产线时，Excel 还能管。三条产线时，开始出现版本混乱——A 线用 V2.1 规格，B 线还在 V1.8。五条产线时，想查一个 LOT 的生产记录，要登录三四个系统翻半天。
这不是"信息化不够"，是"信息化的方式不对"——每个系统都在管自己的数据，没有人管数据之间的关系。
Online 的定位很简单：工厂的数据总账。不用替代任何已有系统，而是在所有产线之上加一层聚合层——数据还是从 mes-line 来，但汇总、关联、追溯、分析、对外输出全部在 Online 完成。
集团品正系统通过 API 拉数据 → Online 工厂服务器汇聚分析 → mes-line 产线端实时执行 → 检测设备信号采集
十个模块，串起一条数据链
品目和规格是数据基座——全厂统一的 CODE 库和版本化的规格管理，改一次、批量下发，不再逐线贴 Excel。LOT 和生产明细是追溯核心——从客诉逆向查到具体批次和检测记录，五分钟定位。CPK 和 OEE 是分析引擎——过程能力和设备效率实时监控，偏移即时告警。数据接口和权限管理是安全底座——对外标准 API，对内三级角色。
十大模块覆盖数据基座→追溯核心→分析引擎→对外通道→安全底座的全链路
品目+规格：别小看版本管理
一个品目从试产到量产，规格至少改三四版。如果版本靠文件名区分（"规格表V3_final_最终版.xlsx"），迟早出问题。Online 的做法：规格按版本号管理，哪个版本下发了哪些产线、什么时候生效——全部留痕。批量下发一键到位，所有产线同步切换。
CPK 和 OEE：知道一个数没用，知道趋势才有用
CPK 不是报一个数字就完了——要看 X-bar 控制图上样本均值是不是在往控制限飘。OEE 不是看 85% 就满意了——要拆成 A（可用率）×P（性能率）×Q（良品率），看清楚是哪一项在拖累整体。
当 PHM 把设备健康度 A[H(t)] 上报后，OEE 的 A 因子会自动降权——设备亚健康时，实际可用率不再是 100%，OEE 能真实反映"健康感知的效率"而不只是"时间统计的效率"。
权限：不是谁都能看到所有数据
操作员看自己产线的生产明细，工程师能导出和分析，管理员管品目规格。多产线工厂天然需要数据隔离——看得到 A 线不代表应该看到 B 线。三级角色+产线授权，最小权限原则。
Online 处于云层：← 接收 mes-line/监测/PHM 数据，→ 下发品目规格，→ 对品正/客户 MES 输出 API
技术快照
| 维度 | 规格 |
|---|---|
| 后端 | Python+Flask+SQLAlchemy，SQLite 或 PostgreSQL |
| 前端 | Jinja2+Vanilla JS+ECharts |
| 服务器 | Xeon Silver 4310+32GB+1TB SSD，Ubuntu 20.04 |
| 通信 | TCP/IP 局域网、RESTful API、MQTT |
| 部署 | Docker 或裸机，systemd 守护 |
工厂应该有一本"数据总账"
产线的数据，产线自己最清楚。但工厂需要的是全局视角——哪条线 Cpk 偏低、哪个 LOT 出了问题、哪些品目的规格需要更新。Online 的意义不是"又多了一个系统"，而是把散落在各条产线的数据整理成一本可查、可算、可追溯的总账。
