HB 自动焊接线控制平台

项目概览

HB 自动焊接线控制平台是一套已经投入生产使用的工业自动化软件系统，面向单面和双面焊接线的整线协同、分段设备控制、工艺执行、质量追溯和现场运维。

一条自动线通常由多个独立设备与工位组成。每台设备负责自己的运动、IO、气缸、视觉或扫码动作，但载具需要跨设备持续流转，产品身份、加工状态、安全状态和质量结果也必须在整条线内保持一致。仅把所有逻辑集中到一套 HMI，容易形成难以扩展的单体；完全让设备各自运行，又会失去整线节拍与载具生命周期的统一协调。

项目采用“整线主控 + 分布式设备宿主 + 分段 HMI + 工站插件”的架构：LineMaster 管理整线状态和流转，DeviceHost 在设备侧执行能力，SegmentHMI 面向操作人员提供分段视图，插件封装不同工段的工艺差异。

“已经投入生产使用”描述的是该平台及其核心控制链路已经在真实产线运行。本文基于当前干净源码核对功能实现，但不声称当前源码提交与任意现场安装包完全一致，也不使用未经记录的数字评价性能和稳定性。

匿名化与公开边界

本文可以公开 HB 工艺、单/双面差异以及前中后分段的通用架构，但不会公开：

客户、公司、厂商和产品名称；
控制器、运动卡、视觉系统及扫码设备的品牌和型号；
真实工位编码、设备拓扑、网络地址、端口和路由关系；
IO 点位、寄存器、协议字段、消息样本和厂商 SDK；
运动参数、焊接参数、视觉阈值、配方数据和现场配置；
账号、默认密码、连接字符串、密钥、安装目录和日志样本；
现场截图、产品图片、产量、节拍、良率与停机数据。

下文架构图和流程均使用抽象名称，目的是说明工程设计，不用于还原真实产线。

项目目标

平台需要同时解决设备自治与整线协同之间的边界：

支持单面和双面线共用核心框架，同时允许工艺路线差异；
让前段、焊接段和后段设备独立部署、独立调试和独立恢复；
让 LineMaster 掌握载具与整线状态，但不直接操作运动轴；
把设备动作抽象为可发现、可校验、可组合的能力；
让独立自动和联线自动使用同一套工位状态与安全规则；
在断线、暂停、急停或动作失败后保留可恢复的上下文；
把报警、追溯、配方、MES 和统计能力作为生产系统的一部分；
支持离线现场安装、分段升级、配置保留和仿真调试。

技术栈与职责

层次	技术与组件	主要职责
整线主控	.NET 8、LineMaster、SQLite	整线拓扑、载具生命周期、索引周期、设备会话和集中追溯
分段界面	WPF、MVVM、CommunityToolkit.Mvvm	登录、导航、状态、报警、手动操作、自动模式和参数维护
设备宿主	Generic Host、DeviceHost Runtime/Kernel	生命周期、模式、安全、能力调度、通信和本地持久化
插件系统	DeviceHost PluginSupport、工段插件	工站拓扑、能力、IO 语义、工艺动作和分段差异
自动流	状态机、拓扑编译、协调协议	工位状态、到位确认、载具移动、加工触发和暂停恢复
设备基础设施	Motion、Vision、Scanner	运动控制、视觉/AOI 通信、扫码和现场设备适配
生产功能	Recipe、Alarm、Trace、MES、OEE/SPC	配方、报警、追溯、外部系统集成和生产统计
持久化与日志	EF Core、SQLite、Serilog	用户、审计、运行状态、恢复快照、追溯和文件日志
验证与交付	xUnit、仿真宿主、PowerShell、Inno Setup	自动化测试、无硬件调试、构建和版本化安装包

应用与多数核心库以 .NET 8 为基线，WPF 应用运行于 Windows x64。设备专用实现通过接口和插件接入，公共层不直接依赖某一工段的界面。

总体架构

┌────────────────────────────── 整线层 ──────────────────────────────┐
│ LineMaster                                                        │
│ 路线拓扑 / 载具状态 / 索引周期 / 工单 / 追溯 / 报警 / MES 集成    │
└───────────────────────────────┬────────────────────────────────────┘
                                │ 受控 TCP 协调协议
             ┌──────────────────┼──────────────────┐
             ▼                  ▼                  ▼
┌────────────────────┐ ┌────────────────────┐ ┌────────────────────┐
│ 前段 DeviceHost    │ │ 焊接段 DeviceHost  │ │ 后段 DeviceHost    │
│ Front Plugin       │ │ Welding Plugin     │ │ Rear Plugin        │
└─────────┬──────────┘ └─────────┬──────────┘ └─────────┬──────────┘
          │                      │                      │
          ▼                      ▼                      ▼
  运动 / IO / 扫码       焊接 / 运动 / 安全       视觉 / IO / 执行机构
          ▲                      ▲                      ▲
          │                      │                      │
┌─────────┴──────────────────────┴──────────────────────┴───────────┐
│ SegmentHMI：分段状态、手动调试、自动运行、报警、配方、审计       │
└──────────────────────────────────────────────────────────────────┘

LineMaster 只发送业务级或位置级命令，不直接写运动轴和 IO。DeviceHost 对本机硬件、安全联锁和动作结果负责，SegmentHMI 则通过设备服务展示状态并发出经过权限和模式校验的操作请求。

解决方案分层

应用层

LineMaster.App：整线主控进程和集中运行界面；
SegmentHMI.App：可按分段配置启动的统一 WPF 操作端；
DeviceHost.App：加载生产配置和工站插件的设备宿主；
DeviceDebugHost.App：面向开发和调试的仿真入口。

DeviceHost 核心层

Abstractions 与 Contracts 定义插件、能力、设备状态和通信契约；
Kernel 管理设备上下文、LineMaster 网关、追溯和恢复代理；
Runtime 完成模式切换、能力调度、安全后台服务和设备生命周期；
PluginSupport 提供拓扑、语义 IO、气缸、自动流和插件装配；
Persistence 保存报警、追溯、恢复快照和状态历史；
UIShell 提供设备界面复用组件；
Simulation 为无硬件开发提供替代实现。

工厂与业务功能层

Factory Contracts、Domain 和 Framework 提供通用领域模型、配置与状态机；Recipe、Alarm、Trace、MES Integration 和 OEE/SPC 以独立功能项目接入 LineMaster 与 DeviceHost。

工站插件与基础设施层

前段、焊接段和后段分别拥有运行插件与界面插件。Motion、Vision 和 Scanner 只处理技术协议与设备访问，不包含整线流转决策。

这种分层让公共框架可以独立演进，也让工艺差异留在插件中，避免通过大量设备名称和条件分支污染核心代码。

能力驱动的设备执行

设备动作统一注册为能力，而不是让 HMI 直接调用具体控制器：

操作或自动流命令
  → CapabilityCommandDispatcher
  → CapabilityRegistry 查找匹配能力
  → 校验 Scope、工站、位置、模式和参数
  → 插件能力执行
  → Motion / IO / Vision / Scanner 服务
  → 返回结构化结果并记录追溯

能力分为设备级、工站级和位置级。原子能力完成单个硬件动作，组合能力负责一段工艺顺序。能力目录可以在运行时查询，SegmentHMI 据此展示当前设备实际可执行的能力，而不是只依赖静态菜单。

新增工站时，插件负责提供：

工站与位置拓扑；
能力提供者及命令参数；
语义 IO 和气缸映射；
自动流进入、加工和离开处理器；
安全状态与恢复规则；
对应的界面组件和配置校验。

核心调度器只面向接口，不需要了解具体设备品牌或现场点位。

自动流拓扑与状态所有权

自动流启动时首先编译插件提供的拓扑，检查工站、位置、移动通道和能力引用是否完整。配置错误会在宿主启动阶段失败，而不是等到生产中才发现某个动作无法执行。

平台明确划分状态所有权：

状态	主要所有者	说明
设备硬件与安全状态	DeviceHost	由本机采集并判定是否允许动作
工位占用与加工状态	DeviceHost 自动流	根据传感器、动作和工艺结果更新
整线载具位置	LineMaster	聚合设备确认后的物理位置，不提前假设移动成功
整线索引周期	LineMaster 协调器	规划相关通道并等待设备确认
操作显示状态	SegmentHMI	订阅真实状态，不自行创造生产事实

这能避免主控和设备同时修改同一状态，也避免界面把“命令已发送”误显示为“动作已完成”。

独立自动与联线自动

独立自动

单台设备可以在不参与整线索引时完成本段自动加工。DeviceHost 根据本机拓扑等待载具到位，执行加工能力，记录结果，再按配置完成段内移动或等待人工确认。

联线自动

联线自动由 LineMaster 规划索引周期：

读取整线快照
  → 计算本周期允许移动的通道
  → 向相关 DeviceHost 发送 Prepare
  → 各设备校验工位、安全、模式和资源
  → 全部准备后下发执行命令
  → 设备执行实际移动并等待到位
  → 按关联标识上报结果
  → LineMaster 更新载具物理位置
  → 到达加工位的设备启动加工

Prepare 阶段把“是否可以开始移动”和“开始物理动作”分开，减少某一段已经移动、另一段却在启动前失败的情况。

载具生命周期与幂等协调

载具进入首站时获得整线范围内的标识。它随物理移动在工位之间流转，直到末站完成后结束生命周期。每次跨设备移动都会关联请求、索引周期、源位置和目标位置。

协调协议使用关联标识匹配命令与结果，并对重复、乱序或重放消息进行幂等处理。LineMaster 只在收到设备的物理确认后更新位置；网络中断时保留未完成上下文，重连后通过状态快照进行对账。

协议幂等解决的是重复消息和状态一致性问题，并不等于身份认证或加密。当前通信安全边界仍依赖受控工业网络。

工位状态机与加工触发

每个位置通过状态机表达空闲、等待、移动、到位、加工、完成、暂停和故障等状态。状态迁移可以配置守卫条件、进入/退出处理器与超时动作：

载具到位
  → 校验当前工位、工艺上下文和安全状态
  → 创建 ProcessContext
  → 分发工位组合能力
  → 等待运动、IO、视觉或扫码结果
  → 写入追溯与加工状态
  → 标记完成并允许后续移动

ProcessContext 携带载具、设备、工站、位置和工艺上下文，使插件不必依赖界面全局变量传递生产身份。

HB 焊接段设计

焊接段插件把准备、夹紧、支撑、焊接触发、结果确认和复位组织为组合能力。执行前检查载具、工装、安全输入和执行机构状态，任一步失败都应停止后续焊接触发并保留故障原因。

单面和双面线共享能力调度与状态机，但通过拓扑、位置声明和配方决定实际加工路径。这样可以复用公共执行框架，又不把某一条线的点位或动作硬编码进整线主控。

本文不展示实际动作序列、IO 名称、时间参数和焊接条件。软件顺序控制也不能替代设备侧的硬件安全和工艺保护。

安全联锁、暂停与恢复

平台把安全处理分为多层：

设备急停协调器持续监听急停状态并阻断运动；
插件安全服务聚合安全门、光栅及工站专用联锁；
运动命令联锁在执行轴和气缸动作前再次检查；
自动安全协调器根据策略执行暂停或急停；
信号恢复后保持恢复锁存，要求满足稳定时间和人工确认；
状态机超时、取消和异常统一进入失败或恢复路径。

暂停不会立即丢弃已准备的周期。恢复时重新检查模式、安全和设备状态，只有条件仍然成立才继续。急停与安全跳闸则要求设备动作停止、清理未完成任务，并在人工复位后重新对账。

软件联锁只是附加保护，不能替代硬件急停、安全继电器、驱动器限位和 PLC 安全逻辑。

视觉、扫码与运动基础设施

基础设施项目为上层提供一致接口：

Motion 封装轴初始化、点位、运动命令和状态查询；
Vision 管理视觉/AOI 的 TCP 请求、触发和结果；
Scanner 支持配置化连接、触发、超时和运行时测试；
语义 IO 把现场点位转换为插件可以理解的输入输出名称；
气缸服务组合输出、反馈、超时和安全条件。

设备参数由配置加载并在运行时校验，公开案例不包含真实地址、点位或报文。

追溯、配方、报警与统计

DeviceHost 在本地保存报警、追溯、流程状态、恢复快照和设备状态历史。追溯记录写入缓冲后上传 LineMaster，LineMaster 再以整线载具和工单上下文聚合数据。

扫码 / 自动流 / 工艺能力
  → ProcessContext
  → 本地 Trace 与流程状态记录
  → DeviceHost SQLite
  → TCP 上传 LineMaster
  → 整线载具与工单关联
  → MES / 报表 / OEE-SPC

Recipe 管理运行配方及其选择，Alarm 统一设备和整线报警语义，MesIntegration 封装外部工单与结果接口，OeeSpc 提供生产统计扩展点。外部系统不可用时，现场设备控制与本地证据应保持清晰边界，不能把网络失败误判为硬件动作成功。

恢复快照保存设备和自动流的关键上下文，用于进程重启后的诊断与恢复。它不是无条件自动续跑依据，恢复前仍需核对物理设备、载具位置和安全状态。

SegmentHMI 与本地权限

SegmentHMI 使用统一 WPF/MVVM 框架，根据分段配置发现设备、工站、位置和运行时能力。主要界面覆盖：

登录、用户管理和角色权限；
设备总览、状态、模式和连接指示；
手动操作、自动模式、配方和参数；
报警确认、历史与流程状态；
运动、IO、视觉和扫码调试；
图片预览、帮助文档和多语言切换；
配置维护与运行时能力查询。

用户和审计数据使用独立 SQLite 数据库。密码保存为带随机盐的 PBKDF2-SHA256 哈希，不存储明文；关键界面操作写入审计记录。初始账户仍需要在现场交付时强制改密，并纳入账号停用和权限复核流程。

仿真与无硬件开发

DeviceDebugHost 和 Simulation 项目允许在没有真实控制器时加载宿主、插件、状态机和部分设备替代实现。它适合：

验证插件发现、依赖注入和拓扑编译；
演练能力命令与状态迁移；
开发 SegmentHMI 页面；
构造扫码、视觉和设备状态场景；
重现不依赖真实运动的协调问题。

仿真不能验证真实 IO 电气行为、运动参数、焊接结果、安全回路和现场时序，因此不能替代硬件在环与整线验收。

版本化安装与现场交付

项目提供四类 Windows x64 安装包：整线主控、前段、焊接段和后段。构建脚本发布对应应用、DeviceHost、插件和配置模板，再由 Inno Setup 生成带版本号的安装程序。

分段安装包会区分程序文件与现场配置。升级时保留设备配置、配方、IO 映射和运行数据，避免新版本覆盖已验收参数。

源码与依赖检查
  → Release 构建与自动化测试
  → 分段应用发布
  → 插件和配置完整性检查
  → 生成版本化安装包
  → 备份现场配置与数据库
  → 安装或升级
  → 单机验证
  → 联线自动与安全验收

现有脚本和安装工程形成了可重复交付基础，但父仓库源码指针、安装包版本、提交 SHA、配置版本和验收记录仍需建立统一清单。

构建与测试基线

案例编写前在当前干净源码 HEAD 上执行了 Release 构建和测试：

验证项	当前结果
.NET Release 构建	48 个解析项目，0 error、76 warning
xUnit 测试	1242 通过、12 失败、0 跳过
源码仓库	当前工作区干净
父仓库源码指针	仍固定在更早提交，和当前源码 HEAD 不一致
GitHub CI	尚无实际工作流

十二个失败测试主要涉及：

焊接工站气缸与 IO 配置和测试预期不一致；
焊接支撑动作顺序及失败分支断言；
部分能力注册测试使用同步方式释放仅支持异步释放的服务；
一条权限提示的多语言文本断言。

这些失败不能被“生产已经使用”所掩盖，也不能描述为测试全绿。76 条警告主要包括可空引用、过期接口和测试事件未使用等问题，需要按运行风险分级处理。

生产使用结果

根据已经确认的生产事实，可以做出以下定性描述：

单/双面 HB 自动焊接线的软件平台已经投入生产运行；
LineMaster、分段 DeviceHost 与 SegmentHMI 形成了整线协同链路；
前中后分段可以独立运行、调试并参与联线自动；
载具流转、工位加工、报警和追溯使用统一状态与事件模型；
插件化能力支持不同工段复用公共框架；
版本化安装包用于现场分段交付和升级。

本文不披露客户与设备信息，也不虚构轴数、节拍、产量、良率或稳定性指标。源码中存在的能力不代表每项功能都在所有生产线型中启用。

已知边界与风险

构建与版本治理

父仓库记录的源码 Gitlink 仍停留在较早提交，而当前源码仓库已经前进，发布来源无法只靠父仓库 HEAD 复现；
MotionControl 使用相邻源码引用，脱离当前开发目录后不能独立还原依赖；
当前测试存在十二项失败，尚不能作为严格的合并门禁；
编译警告数量较多，容易淹没新增的高风险告警；
仓库只有静态分析配置，没有实际 GitHub Actions 持续集成流程。

通信与网络安全

LineMaster 协调服务当前监听所有网卡；
DeviceHost 与 LineMaster 的 TCP 协议没有应用层身份认证、TLS 或消息签名；
关联标识和幂等处理只能防止业务重复，不能证明连接方身份；
当前生产安全依赖工业网络隔离、防火墙和受控主机，后续需要收敛监听地址、来源白名单和加密认证。

设备、安全与恢复

软件暂停、急停协调和安全联锁不能替代硬件安全回路；
动作失败、取消、网络中断和进程退出后的信号清理需要持续通过硬件测试验证；
恢复快照只能提供软件上下文，不能自动证明物理载具位置正确；
安装升级保留现场配置，但数据库、配置和安装包之间仍缺少统一版本清单与自动回滚。

账号与数据

默认账户必须在交付后立即轮换密码并最小化权限；
现场配置、日志和追溯可能包含产品或设备敏感信息，需要明确保留周期和访问权限；
SQLite 适合单机持久化，但备份必须与应用写入、安装升级和恢复演练协调。

后续路线

修复当前十二个失败测试并建立必须全绿的质量门禁；
分类清理可空性和过期接口警告，防止新增风险被告警噪声掩盖；
将父仓库 Gitlink、安装包版本、提交 SHA 和配置版本统一到发布 manifest；
把 MotionControl 从相邻源码引用迁移为可锁定、可复现的包或仓库依赖；
建立包含构建、测试、静态分析和安装包验证的 CI；
为协调 TCP 增加绑定收敛、双向身份认证、加密和来源控制；
补齐动作取消、急停、断线与异常退出时的统一清理测试；
建立设备仿真、协议集成、硬件在环和整线验收的分层回归；
为 SQLite、配置、配方和日志建立一致备份与恢复流程；
形成可演练的分段升级、健康检查和版本回退机制。

项目复盘

这个项目最重要的经验不是把多台设备连接起来，而是明确每一层应当拥有什么状态和责任：

LineMaster 负责协调，不越过 DeviceHost 直接控制硬件；
DeviceHost 对本机动作、安全和物理确认负责；
插件表达工艺差异，公共框架只提供稳定契约；
SegmentHMI 展示并操作真实运行状态，不成为生产事实来源；
载具位置只有经过设备确认后才能更新；
仿真、单元测试、协议测试与硬件验收各自解决不同风险；
生产使用证明系统产生了业务价值，但测试、网络安全和发布追溯仍需持续建设。

下一阶段应优先让当前能力拥有可信的自动化门禁、可复现的发布来源和更强的工业网络安全边界，而不是继续扩大功能数量。