半导体设备多协议上位机稳定性优化与 Windows 交付案例

项目概述

本项目面向半导体工艺设备的 Windows 上位机软件。系统基于 Qt/C++，连接多路温控器、针阀、真空计、挡板控制器和工业相机，并使用 SQLite 保存设备样本、命令事件和相机帧元数据。任务目标不是替换硬件控制逻辑，而是在不打断现场旧程序的前提下定位数据断续、命令确认不足、相机帧率回退和存储静默停止等问题。

交付采用两条隔离路径：一条对既有运行版本做可回滚修复并生成 Windows x64 安装包；另一条在独立目录和独立 AppId 下构建 v2 架构测试线，用于验证串口、数据库、相机和脚本的职责边界。两条路径均保留现场配置和历史数据，不在无人确认时启动可能连接设备的程序。

系统范围与技术栈

基于现场证据的问题定位

只读分析覆盖约 8.89 小时的历史日志和数据库。COM5 日志出现 5168 次“缓冲区超过 128 字节，清空”，10 台温控器的有效更新时间明显低于配置的 2 秒周期。代码进一步显示，高频轮询每台设备读取约 35 个寄存器，典型响应约 75 字节；GUI 调度、数据库慢批次和 150 ms 等待窗口共同增加了旧响应与新请求串帧的概率。

同机历史相机记录还显示：旧基线实际 JPG 写入为 8.006 FPS，回退版本为 3.919 FPS，两组样本均未发现相邻 JPG 内容完全相同。根因是原始帧 ACK 被排队到相机工作线程，下一次阻塞取帧可能先执行，导致新帧在“上一帧仍待消费”状态下规律跳过。该对比用于定位回退，不代表修复版已经完成现场帧率验收。

既有版本的稳定性修复

既有版本的改动以缩小风险面为原则，保持原有 UI、设备配置、数据目录和工艺脚本入口。修改文件在客户机覆盖前备份，补丁归档和安装包均生成 SHA-256 记录。安装器保留既有 MBE_Data、Scriptfile 和设备配置，且安装完成后不自动启动上位机。

• 温控高频读取只覆盖 PV、SP 和 Working SP，典型响应由约 75 字节减少到约 15 字节。
• Sub 设定温度写入匹配 Modbus 0x06 应答，再定向读取 SP；应答或回读不一致时返回失败。
• 相机采用工作线程自驱动和最新帧语义，预览与原始存储分别限制为一个在途帧。
• 温度工程值不再被状态栏和旧控制路径二次除以 10。

Ramp Rate 硬件回读

Ramp Rate 启动值由软件伪造的固定值改为 --，随后读取设备寄存器 0x0023。稳定运行后每 3 秒读取一台设备，10 台温控器约 30 秒完成一轮。Ramp Rate 不并入 PV/SP 高频连续读帧，避免扩大每次响应和占用 9600 baud 总线。

这项实现解决的是“显示值来源”问题：UI 只在收到设备数据后显示数值。现场修改设备参数后的同步效果仍需在 1.0.3 实机运行时核对，页面不把代码实现写成已完成验收。

相机采集与存储链路

预览和存储均采用最新帧策略：GUI 或 JPEG 编码暂时跟不上时，中间帧可以被替换，不允许事件队列持续增长。原始帧 ACK 直接释放原子标志，不再等待相机工作线程完成下一次阻塞取帧。文件名和数据库字段记录真实采集时间，保存开始和完成时间单独记录，避免用合成时间戳推算帧率。

1.0.3 增加两类看门狗：相机已打开但连续 3 秒没有原始帧时关闭并重新打开，重启请求设置 10 秒冷却；存储任务占用或最后持久化超过 3 秒时解除卡死状态并使用最新帧重试。看门狗用于恢复静默停顿，不替代对驱动、USB 链路、磁盘吞吐和数据库错误的现场诊断。

独立 v2 架构测试线

v2 在独立目录和独立安装标识下构建，不覆盖旧版源码、安装目录或运行进程。默认不自动连接串口、不启动监控、不打开相机，也不在启动时发送挡板命令。其核心约束是一个物理串口只由一个 PortWorker 持有，轮询、人工命令和脚本命令进入同一优先级事务队列。

SQLite 只保留一个写连接，设备样本与相机元数据按时间或批量阈值统一提交；历史查询使用独立只读连接。相机采集、预览和 JPEG 记录分线程。脚本由短步骤状态机推进，实际设备命令经统一控制总线执行，任一应答或目标值回读失败即停止。

构建、封装与数据保留

维护版 1.0.3 使用 CMake、MSVC Release x64 和 Inno Setup 6.7.3 构建。Release 可执行文件为 1,727,488 字节；安装暂存目录包含 78 个文件、总计 66,292,772 字节。Galaxy SDK、Qt、SQLite 驱动、VC Runtime 和设备配置均存在，未包含 Qt Debug DLL。

安装包版本为 1.0.3.20260728，大小 19,884,961 字节。安装包及补丁归档均保留完整 SHA-256。安装包未做 Authenticode 签名，Windows 可能显示未知发布者提示；这属于当前交付限制。

验证证据与边界

现场安全与验收计划

上位机启动后可能连接串口、相机并控制设备，因此远程构建期间没有在无人确认的交互桌面启动新程序，也没有停止现场旧进程。建议先由现场人员确认设备处于安全状态，再按“只监控、单设备命令、相机、针阀与挡板、脚本、联合运行”的顺序执行。

• 监控 30 分钟，统计每台温控器的采样间隔、超时率和最大间断。
• 使用安全目标多次写入 Sub，逐次核对 0x06 应答、SP 回读、设备面板和 PV。
• 固定曝光、分辨率和磁盘目录，记录采集 FPS、保存 FPS、跳帧和端到端延迟。
• 断开并恢复相机链路，核对看门狗日志及预览、存储恢复。
• 完成 8 小时联合记录后，再决定是否替换旧版程序。

可复用的工程方法

该方法适用于需要在既有工业 Windows 软件上进行“保运行、可回滚”改造的项目，包括半导体设备、真空系统、温控设备、工业相机、多串口采集、实验设备和工艺脚本控制。关键不是先重写全部代码，而是先用日志、数据库和协议路径建立可复现证据，再区分可小范围修复的问题与需要独立架构验证的问题。

类似项目的前期输入

技术评估通常需要设备协议、串口拓扑、寄存器表、相机 SDK 与样例、现有源码和构建环境、历史日志与数据库、现场安全边界、当前版本回滚方式，以及可量化的采样周期、命令成功条件、帧率、延迟和连续运行指标。缺少实机窗口时，可以先完成静态诊断、无硬件测试、安装包校验和验收方案，但不能替代现场验收。

常见问题

这是全新开发还是既有系统维护？

两者都有。维护线对现有软件做有限修复并生成 1.0.3 安装包；v2 是独立测试线，用于验证更清晰的线程、事务和数据边界，不直接覆盖现场旧版。

为什么不通过远程 SSH 直接启动新版本？

程序启动后会连接设备并可能发送控制命令。没有现场人员确认安全状态时启动，会占用相机或串口并带来设备动作风险，因此只完成构建、封装和静态检查。

页面中的 8.006 FPS 是修复后的结果吗？

不是。它是同机旧基线记录；3.919 FPS 是回退版本记录。两组数据用于定位 ACK 调度问题，修复版的现场帧率仍需按固定条件重新测试。

测试是否覆盖全部设备功能？

没有。既有版本没有注册自动化测试；v2 的一个测试程序覆盖 11 类无硬件协议、状态、脚本和存储检查。真实温控、针阀、挡板、相机和长时间运行仍待现场验收。

交付如何保护现场数据和配置？

修改前保留源码备份和补丁归档，安装器保留数据目录、脚本和已有设备配置，v2 使用独立 AppId 和安装目录。是否切换版本由现场验收结果决定。