管理中台篇一：它为什么不是 MES

IIoT.CloudPlatform 在这套 IIoT 项目里承担的是上位机管理中台角色，不是 MES。

这个边界需要先立住。MES 面向更上层的制造执行业务，例如生产计划、工单流转、工艺执行和企业既有生产系统集成。管理中台面向的是本项目内部的上位机体系：设备如何被登记，现场程序如何确认自己是哪台设备，配方如何版本化，产能、日志、过站和生产数据上传后在哪里归档查询。

管理中台和 MES 都会出现在产线链路里，但它们处理的不是同一类问题。把管理中台写成 MES，会导致后面的身份、上传、补偿和归档逻辑全部混在一起。

这张设备页对应管理中台的第一层职责：先把设备管起来。设备不是页面上一条名称记录，它后面连接着 ClientCode、bootstrap、DeviceId、配方、产能、设备日志和生产数据。设备注册完成后，现场上位机才能通过云端分配的寻址码完成设备身份确认。

新版前端把设备台账放进统一的生产工作台里。左侧导航按概览、员工、工序、设备、配方、过站、产能、日志和权限组织；右侧设备列表只展示设备 Code，不暴露启动密钥。新增设备仍然是管理员入口，设备 Code 和启动密钥由云端生成，前端只负责把一次性结果安全交给现场配置。

管理中台管什么

当前业务规则里，IIoT.CloudPlatform 的职责集中在几类基础能力：

• 人员、账号、角色和权限。
• 设备档案、设备唯一寻址码、ClientCode。
• 设备 bootstrap 和 DeviceId 返回。
• 配方和配方版本。
• 产能、日志、生产数据、过站数据的统一归档与查询。

这些能力都是上位机体系自己的基础口径。现场程序启动时，需要确认“本机对应哪台设备”；现场程序上传数据时，需要确认“这批数据归到哪个 DeviceId、哪个工序、哪个配方版本”；后台人员查询时，需要能按设备、工序、时间和业务字段找到记录。

MES 不负责替这个项目生成 DeviceId，也不负责维护本项目的 ClientCode。MES 可以接收上位机上传的生产数据，但不能反过来成为本项目设备身份和配方版本的源头。

flowchart LR Device["设备注册"] --> ClientCode["ClientCode"] ClientCode --> Bootstrap["bootstrap 寻址"] Bootstrap --> DeviceId["DeviceId"] DeviceId --> Upload["产能 / 日志 / 生产数据上传"] Upload --> Archive["管理中台归档查询"] Upload --> MES["外部 MES 接收"]

bootstrap 是管理中台的关键分界

业务规则里把 ClientCode 和 DeviceId 分得很清楚。

ClientCode 是云端注册生成后交付给客户端保存的寻址码。现场上位机用它发起 bootstrap。bootstrap 成功后，云端返回正式设备信息，其中核心标识是 DeviceId。后续产能、日志、生产数据和过站数据都依赖 DeviceId 归档。

这条链路的意义在于：现场上位机不能绕过云端身份确认，直接凭设备名称上传数据。设备名称可以作为显示字段调整，但不能作为正式上传身份。ClientCode 也不能直接替代 DeviceId 成为归档主键。

所以管理中台不是单纯保存页面数据。它在云边之间提供一条身份主链路：客户端先通过 ClientCode 找到自己，再通过 DeviceId 上传和归档。

AppHost 里的运行边界

Aspire 运行视图展示的是管理中台的运行结构，而不是一个单体后台。IIoT.AppHost 组织了 PostgreSQL/TimescaleDB、Redis、RabbitMQ、MigrationWorkApp、HttpApi、Gateway、DataWorker 和 Vue 前端。

Gateway 收口 /api/v1/human/*、/api/v1/edge/*、/api/v1/bootstrap/* 等入口。HttpApi 处理业务请求和上传入口。DataWorker 负责后台处理、归档、消息和 Outbox 类任务。MigrationWorkApp 负责初始化和迁移。

这个拆分和业务边界对应：入口先统一，业务在 HttpApi 内处理，异步工作交给 DataWorker，存储使用 PostgreSQL/TimescaleDB，缓存和消息分别由 Redis、RabbitMQ 承担。

和 MES 的关系

MES 是外部系统，Cloud 上传和 MES 上传在上位机里分成两条链路。

管理中台接收项目内部归档数据，MES 接收外部制造执行系统需要的数据。Cloud 上传失败时，影响的是管理中台归档；MES 上传失败时，影响的是外部系统接收。两类失败不能进入同一个补偿语义。

业务规则明确要求：MES 的接口、重试、持久化、补偿不能与云端上传共用同一条业务链路；本地 SQLite 中，云端相关缓存与 MES 相关缓存保持分离。这个规则决定了上位机侧需要同时保留 Cloud 上传通道和 MES 上传通道，不能用一个失败队列把两类业务混在一起。

管理中台的位置可以固定为一句话：它不是 MES，而是上位机体系自己的主数据、设备身份、配方版本和生产归档中心。

这个边界落到现场会发生什么

现场上位机同时面对管理中台和 MES，两个系统看起来都在接收生产相关数据，但它们的职责不一样。管理中台先解决本项目内部的设备身份、配置口径和历史归档，MES 接收的是外部制造执行系统需要的业务结果。上位机把数据发给管理中台，是为了让本项目能追溯设备、工序、配方、产能和日志；把数据发给 MES，是为了让既有制造系统拿到它需要的结果。

如果这两个口径合并，最先出问题的是失败处理。云端 bootstrap 失败时，上位机还没有拿到正式 DeviceId，这时不能继续打普通云端上传接口；MES 心跳失败时，影响的是外部系统接收，不代表云端身份也失效。两条链路的心跳、闸门、SQLite 缓冲和 retry 需要分开，不然现场看到的故障会变得不可解释：到底是云端身份没恢复，还是 MES 不在线，还是本地补偿队列堵住了。

管理中台承接的是项目内账本

人员、权限、设备、配方、产能、日志和过站数据组成的是项目自己的账本。设备注册后生成 ClientCode，ClientCode 交给上位机保存，bootstrap 返回 DeviceId，DeviceId 再进入后续归档。这个链条不依赖 MES 给设备命名，也不让 MES 决定本项目的配方版本。

配方也是同样的逻辑。管理中台保存的是设备和工序下的版本化配方，现场执行过一批数据之后，后台能查到当时对应的是哪台设备、哪道工序、哪一版参数。MES 可以接收生产结果，但管理中台要保留本项目自己的追溯口径。这个口径存在，后续 AI 做规则解释、数据分析和运维协助时才有稳定依据。

工程结构支撑这个定位

IIoT.AppHost 把 Gateway、HttpApi、DataWorker、MigrationWorkApp、Vue 前端、PostgreSQL/TimescaleDB、Redis 和 RabbitMQ 放在同一个编排视图里，不是为了堆组件，而是为了把入口、业务处理、后台归档和部署依赖拆开。Gateway 收口外部访问，HttpApi 接收业务请求，DataWorker 处理异步归档和消息消费，数据库保存主数据和历史数据。前端通过 /api/v1/human/* 进入后台管理能力，不绕过 Gateway，也不承担设备身份判断。

这个结构对应管理中台的定位：它不直接替 MES 做工单执行，也不让现场上位机承担历史中心职责。现场负责运行，管理中台负责主口径和归档，MES 保持外部链路。边界稳定之后，新增工序时只需要把字段、DTO、校验、持久化和查询补进管理中台，不需要重写设备身份、bootstrap、上传幂等和部署主链路。

交付后的判断标准

后续再接新工序时，可以用这条标准判断有没有跑偏：新增内容是否仍然围绕设备身份、配方版本、生产归档和查询扩展；是否保持 MES 外部链路定位；是否没有改动 bootstrap、DeviceId、Outbox、缓存和部署主链路。只要这几个问题能回答清楚，管理中台就还是管理中台。

这个边界对后续维护也有好处。云端团队看管理中台，关注主数据和归档；现场团队看上位机，关注运行和上传；MES 对接只处理外部系统要求的数据格式和节奏。三边不互相吞掉职责，项目后面才不会越改越乱。