面向 3C 无线通信模组（WiFi/BT，如高通 QCC2072 系列）的产线制造场景。
立项原因：这类模组的出厂流程（镭雕刻码 → 产测 → 抽检）长期依赖原厂封闭 MES，费用高、不开放二次开发；中小代工厂/ODM 只能靠产测软件本地 txt 台账 + 人工 Excel 汇总，由此暴露三个典型问题：
① 同一 MAC 被重复发给两片模组，出厂后设备 MAC 冲突，往往出货后才被发现；
② 漏工序、跳站无人拦截（如未镭雕就直接进产测）；
③ 良率、不良项、节拍工时全靠人肉统计，口径不统一（一条记录 = 一次过站，并不等于一片）。
本项目即为此立项：用一套轻量、可离线部署、可二次开发的自研 MES 承接产测客户端，把「取号—防呆—在测占位—结果上传—追溯—汇总」整条链路收口到统一数据源，做到现场异常停线可见、每个 MAC 有据可查。
系统分产线客户端接口与 Web 管理台两大块。
一、产线客户端接口（HTTP 200 + 统一业务码）：QueryPassRecd 扫码防呆（查上游工站是否已有良品记录，未过上游即拦截）；GetLDList 按工单取 MAC 号（含占用标记防重发）；AcquireTest / ReleaseTest 开测占位与释放（多夹具并行，仪器口冲突返回 409）；GetStationConfig 配置下发（料号、线体、上游工站、log 目录、NAS 凭据由 MES 统一下发，客户端零配置漂移）；UploadData 结果上传（写记录子表 + 回写工单计数与状态）；UploadLogFile 预留（log 文件走 NAS，库内只存文件名）。
二、Web 管理台：首页看板（按「片」口径的完成/良率/在制/不良 + 近 7 天趋势 + 各工站 + 不良项 TOP）；工单与 MAC 池（Excel 建池导入、取号分配与手工释放回池、计数对账）；全链追溯（按 MAC 查工单状态 + 各工站明细）；报表（工站良率/首测直通率/复测率/节拍工时/治具·端口·机台失败率，支持导出 Excel）；用户与工站权限；基础配置（工站/仪器/端口/机台/治具/字段字典）；系统参数在线配置（改完即时生效）；操作日志审计留痕。
关键业务机制：免镭雕批次混线跳过工序、MAC 每片占两个连续地址（BT = WiFi + 1）、复测分级与 Fail 回池策略。
我负责：现场需求调研与口径确认 → 数据模型设计（14 张表 / 33+ 条索引）→ 客户端接口与协议适配层设计 → 后端与 Web 管理台开发 → 离线部署包与接入文档。
技术栈：Python 3.9+/3.12 + FastAPI + Pydantic v2 + SQLAlchemy 2.0 + Jinja2 + Bootstrap/Axios；数据库开发用 SQLite、部署用 MariaDB/MySQL（pymysql）；JWT + bcrypt 认证；openpyxl 处理 Excel 导入导出；uvicorn 承载；wheels 离线依赖包 + start.bat 一键启动，产线机器无需联网。
架构：分层为 routers（客户端接口 / 管理接口 / 页面）→ services（14 个业务服务：取号、门禁、占位、上传、权限、追溯、报表、审计各司其职）→ adapters 协议适配层（base + registry 注册，可挂接不同厂商客户端协议，新增一家不动主流程）→ models。
难点与亮点：
① 并行防冲突：瞬态表 +「机台+仪器口」互斥键 + 行锁，多夹具并发开测不撞车，超时占用自动回收；
② 数据一致性：工单计数列一律视为「可重算缓存」，唯一事实来源是四张记录子表，另提供 recount 对账接口随时校正；
③ 客户端零改造扩展：门禁对某批次不适用时，只在响应里「增加」字段，老版客户端不重发版即兼容；
④ 统一响应信封 + 全局异常处理器，异常同样返回业务码，客户端不会拿到纯文本 500；
⑤ 老库兼容：init_db 内置轻量加列迁移，模型新增字段不会让现场库运行时报错；
⑥ 现场口径落地：统计主数字按「片」而非「记录」，免镭雕一个标记同时管门禁、取号工站与资产状态，且 fail-closed（填错照旧要求镭雕，不会误放开整条门禁）。
评论