上位机篇五：匀浆插件的当前落地

匀浆是当前 IIoT.EdgeClient 里落地最完整的工序插件。这个结论只描述当前完成度，不改变平台定位。平台仍然按多工序设计，Launcher 里有叠片、注液、匀浆 profile，Shell 也按插件机制加载工序能力。匀浆的价值在于把平台化路径跑通：入口、Shell、插件、页面、数据、上传、诊断、PLC 周期任务都能在同一个工序里看到闭环。

匀浆工序和叠片、注液的模型不同。插件约定里明确写到：匀浆不是多电芯并发过站，不维护电芯条码字典，不把托盘码作为电芯 key。匀浆关注的是投料、搅拌、放行、配方、设备状态、实时数据和过程记录。平台不能为了统一而强行套用别的工序模型。

这张数据页展示的是匀浆当前的数据落地。页面不是单纯做展示，它对应本地运行数据和后续上传链路。匀浆插件提供 HomogenizationCellData、Cloud payload 构建和 MES 场景通道，Shell 提供标准数据页和导航框架。业务字段在插件内定义，页面结构由宿主统一。

匀浆插件接入了哪些能力

匀浆模块位于 src/Modules/IIoT.Edge.Module.Homogenization。从当前代码结构可以看到几类能力：

• DependencyInjection：模块入口和服务注册。
• Presentation：匀浆页面与导航注册。
• Runtime：工序运行工厂和周期任务。
• Integration：Cloud 上传和 MES 上传通道。
• HomogenizationCloudUploader：继承 CloudUploadChannelBase<HomogenizationCellData, object>。
• HomogenizationMesChannel：继承 MesScenarioChannelBase<...>。
• HomogenizationInboundTask、HomogenizationRealtimeTask、HomogenizationRecipeTask、HomogenizationEquipmentStatusTask：对应 MES 入站、实时、配方、设备状态等周期任务。

这些能力说明匀浆不是一个页面样例，而是一个按插件约定接入的工序。它通过 builder 注册视图、服务、任务和上传器，再由 Shell 统一运行。

监控页看运行状态

监控页体现的是现场运行视角。现场人员不只关心一条最终数据是否上传成功，还需要看设备状态、当前批次、工序节拍、关键参数和运行反馈。匀浆插件把这些数据组织成监控页面，宿主负责页面承载和刷新框架。

这类页面适合放在插件内，因为每个工序的监控字段差异很大。匀浆关注搅拌、粘度、温度、配方、放行等字段；叠片和注液关注的字段会不同。把监控字段留在插件里，才能保留工序语义。

配方页连接云端版本规则

配方页不是本地随便填参数。业务规则要求配方属于设备和工序，配方变更要形成版本，初始版本从 V1.0 开始。管理中台维护配方主数据和版本，上位机在现场执行时读取、展示和使用配方参数。

匀浆配方页证明了云端规则和边缘运行之间的连接：云端负责配方版本和设备绑定，边缘负责把当前工序需要的配方呈现在现场运行界面里。配方字段进入匀浆插件，版本和设备身份仍然遵循管理中台规则。

匀浆不是平台边界

匀浆当前完成度高，容易被误读成平台只支持匀浆。实际结构不是这样。scripts/edge-runtime.publish.json 中保留了 StackingLine、InjectionLine、HomogenizationLine，模块目录下也有叠片、注液、匀浆模块。区别在于匀浆当前把页面、任务、上传和诊断跑得更完整。

因此，匀浆适合作为平台样板来讲：它展示了插件如何接入 Shell，如何注册标准页面，如何把工序数据接入 Cloud/MES 双链路，如何在诊断页观察运行状态。后续工序扩展不需要推翻宿主，只需要沿用同一套插件约定。

当前落地结果

匀浆插件把平台化上位机的几个判断落到了代码里：入口由 Launcher 统一，运行由 Shell 承载，工序由插件声明，页面由标准导航挂载，数据由插件模型组织，上传分 Cloud 和 MES 两条链路，诊断由宿主统一收口。

这个落地结果比单独做一个匀浆桌面程序更有价值。它验证的是平台能力：新增工序可以进入同一套入口、宿主、插件和诊断体系，而不是再复制一个独立上位机。

匀浆证明的是平台链路，不代表平台只有匀浆

当前匀浆插件落地最完整，所以截图和运行说明主要围绕匀浆展开。这个事实不能被写成“平台只支持匀浆”。Launcher 里已经有注液、叠片、匀浆的 profile 入口，Shell 和插件合同也不是按匀浆专用方式设计。匀浆只是当前最完整的样板工序。

匀浆插件的意义在于把平台链路打通：Launcher 能启动 profile，Shell 能加载模块，插件能注册页面和服务，现场能看到数据、监控、IO、配方、诊断和产能，上传链路能按 Cloud/MES 分开处理。这条链路跑通后，后续工序就有了可参照的接入方式。

页面背后是插件自己的业务模型

匀浆数据页展示的不是宿主通用字段，而是匀浆自己的运行数据。监控页、IO 页、配方页和诊断页也一样：页面框架可以标准化，字段和数据来源必须属于匀浆插件。这样现场看到的每个状态都有工序语义，不会变成无法解释的通用 key-value。

匀浆当前还有明确边界：它不是多电芯并发模型，没有电芯条码字典，也不把托盘码伪装成电芯 key。注液和叠片涉及多电芯并发时，需要按自己的 Context 和双字典模型扩展。这种差异放在插件边界内，平台才不会为了一个工序牺牲其他工序。

从样板工序沉淀平台能力

匀浆落地后，能反向验证标准页面、任务调度、诊断存储、本地补偿和上传映射是否足够通用。通用的能力留在宿主和共享抽象里，工序特有的能力留在插件里。这个过程比一开始凭空设计平台更可靠，因为每个抽象都能回到真实工序验证。

后续新增工序时，不需要复制匀浆所有业务，只需要复用它验证过的平台接入方式：profile 启动、plugin.json 发现、IEdgeProcessModule 注册、标准页面挂载、任务和上传器按工序实现。

匀浆样板能复用什么

匀浆样板能复用的是接入方式，不是所有业务细节。Launcher profile、plugin.json、IEdgeProcessModule、标准页面注册、任务工厂、Cloud/MES 上传器、诊断存储，这些属于平台链路。匀浆自己的字段、设备点位、配方参数和运行规则，仍然留在匀浆插件里。

这样复用才不会误伤后续工序。注液可能有扫码、前称重、后称重；叠片可能有托盘、电芯绑定和多电芯上下文。它们不应该复制匀浆的数据模型，但可以复用匀浆已经跑通的插件接入路径。

从交付角度看，匀浆截图展示的是当前已落地能力。写文档时要把“当前落地完整”讲清楚，也要把“平台仍然为其他工序预留扩展位”讲清楚。两者缺一项，都会把项目说偏。