管理中台篇四：产能、日志、过站数据的归档中心

现场上位机可以显示当天数据，也可以把异常先写在本地。但长期查询不能依赖每台现场电脑。

设备会换机，程序会升级，网络会中断，本地磁盘也会清理。生产系统需要一个稳定的归档中心，把产能、日志、过站和生产数据收回来，并按统一口径查询。IIoT.CloudPlatform 在这条线上承担的是归档与查询中心。

产能查询页对应的是生产结果账。业务规则里明确：历史产能数据以云端查询结果为准，客户端本地只保留当天产能的运行态数据。本地产能文件态或运行态缓存，不是历史产能的最终查询来源。

新版产能页先给出本页总产出、良品、不良品和综合良率，再进入设备和日期筛选。设备详情页还可以按日、月、年切换统计粒度，用图表和明细表一起表达历史产能。这样后台人员不需要知道数据最初来自哪台现场电脑，只需要按云端归档口径查询。

产能：本地看现场，云端看历史

现场上位机需要快速展示当前班次或当天的运行状态，所以本地保留当天产能有价值。操作员可以直接在现场判断设备是否在跑，产出是否异常。

但跨天、跨设备、跨工序的产能查询，要回到管理中台。管理中台用 DeviceId、工序、时间等维度组织历史数据。这样后台能看某台设备一段时间的产出，也能按工序横向比较。

云端代码里有 IHourlyCapacityRecordRepository、HourlyCapacityConsumer 和 PersistHourlyCapacityCommand 这类落点。HttpApi 接收上传事件，DataWorker 消费 HourlyCapacityReceivedEvent 后做持久化。这个拆分把现场上传和后台归档分开。

产能上传失败时，待上传数据进入本地 SQLite 缓冲。bootstrap 恢复并且云端上传闸门就绪后，再进入补传流程。这样网络异常不会直接造成数据丢失。

日志：本地文件和云端归档双份思路

日志页对应的是设备和上位机运行排查入口。业务规则要求日志实行双份归档：一份写入本地文件日志，一份走云端上传链路。本地文件日志不能因为云端不可用而停止；云端日志上传失败时，进入本地 SQLite 缓冲；补传成功后，删除已成功补传的本地缓冲记录。

云端侧有 IDeviceLogRecordRepository、DeviceLogConsumer 和 PersistDeviceLogCommand。现场日志先按设备和时间产生，进入云端后再变成可检索的历史记录。管理中台页面可以按设备、等级、时间和内容查看，不再依赖远程打开现场电脑上的日志文件。

这套设计解决的是现场排查和远程归档之间的平衡。现场故障发生时，本地日志要能立即看；后续复盘时，管理中台也要能按设备和时间查询。

过站和生产数据：过程追溯入口

过站数据页对应的是生产过程追溯。过站数据不只是日志，它描述某个物料、某次扫码、某道工序经过之后留下的业务记录。

新版过站页由后端返回的工序追溯定义驱动字段和查询模式。前端先选择支持追溯的工序，再按“条码 + 工序”“时间 + 工序”“设备 + 条码”“设备 + 时间”“设备最近 200 条”等模式查询，列表字段和详情字段跟随工序 schema 变化。这样新增工序时，页面不需要变成硬编码表格。

工序增加后，这类数据会继续扩展。匀浆、注液、叠片会有不同的采集字段和业务语义，但归档查询不能完全分散在插件里。插件负责采集和上传，管理中台负责把数据按设备、工序、时间和业务字段收进统一查询入口。

当前代码里可以看到 IPassStationWriteModel、StackingWriteModel、InjectionWriteModel、PassStationConsumer<TEvent> 和 PersistPassStationCommand<TEvent>。这说明过站数据采用按工序扩展的写模型，归档入口和后台处理仍然由云端统一承接。

flowchart LR Edge["上位机插件"] --> Api["HttpApi 上传入口"] Api --> Event["ReceivedEvent"] Event --> Rabbit["RabbitMQ"] Rabbit --> Worker["DataWorker Consumer"] Worker --> Db["PostgreSQL / TimescaleDB"] Db --> Query["后台查询页面"]

接收和后台处理拆开

上传入口不能承载太重的后台工作。

HttpApi 更适合做接收、校验、幂等和落库前处理。后续事件派发、归档整理、消息消费和重试类工作，交给 DataWorker。AppHost 中 DataWorker 和 HttpApi 分开运行，也说明了这条边界。

这个拆分对现场有价值。上位机上传时，服务端先把请求接住并完成必要校验，后台慢任务不直接拖住上传入口。后台处理有自己的 worker 节奏，也更容易观察和扩展。

管理中台因此不是简单 CRUD 后台。它接现场数据，处理身份归属，承载历史查询，还把短链路上传和后台异步处理分开。产能、日志、过站数据都能按各自业务模型扩展，同时保持统一归档中心。

归档中心先解决数据可信来源

现场上位机要服务当前生产，管理中台要服务历史查询。当天运行态数据放在本地可以提高现场响应速度，但跨天、跨设备、跨工序的查询必须回到云端。否则每台现场电脑都会慢慢变成自己的历史库，版本升级、磁盘清理和设备更换都会影响追溯。

产能、日志和过站数据进入管理中台后，查询口径统一到 DeviceId、工序、时间和业务字段。后台人员看历史，不需要知道当时是哪台电脑保存了本地文件，也不需要远程到现场机器翻日志目录。现场保连续运行，云端保长期归档。

DataWorker 不是多余后台进程

上传入口直接做所有处理，会让 HttpApi 同时承担接收、校验、业务归档、消息派发和重试压力。DataWorker 把后台处理拆出来后，入口可以先完成必要接收和事件提交，异步消费再按自己的节奏落库。产能、设备日志、过站写模型都能通过对应 consumer 和 command 进入归档。

这个拆分对现场上传很实际。现场机器上传时更关心请求有没有被接住、身份有没有通过、失败是否能进入补偿。后台归档慢一点可以排队处理，但不能让慢任务长期拖住上传入口。RabbitMQ 和 DataWorker 提供的就是这层缓冲和处理节奏。

查询页面不是简单展示

产能页、日志页、过站页分别对应不同类型的追溯问题。产能看产出，日志看运行异常，过站看生产过程。它们都使用管理中台作为长期数据来源，但查询维度不同。把三类数据全部写成一张通用列表，会丢掉业务语义；完全分散成各工序自己的后台，又会失去统一归档入口。

当前做法是在云端保持统一归档中心，同时允许按工序扩展写模型和展示字段。匀浆、注液、叠片可以有不同数据结构，但进入后台后仍然沿着设备、工序、时间和上传身份查询。这是管理中台和插件化上位机之间的配合关系。

归档和补偿怎样闭环

归档中心不是只接成功数据。现场网络、云端服务和外部系统都会出现波动，所以失败数据必须先在上位机本地缓冲，恢复后再补传。补传成功后清理对应记录，失败则保留等待下一轮。这条规则让现场连续性和云端完整性可以同时成立。

云端接收数据后，还需要能被后台查询。产能、日志和过站数据分别对应不同业务问题，但都要能回到 DeviceId、工序和时间。这样一条现场记录从采集、上传、补偿到归档查询形成闭环。

这个闭环也让 AI 端后续有数据基础。RAG 可以解释规则，Text-to-SQL 可以查归档数据，但数据可信来源仍然是管理中台。AI 不能把本地当天运行态当成长期历史，也不能把补偿队列当成正式归档结果。