Skip to content

案例 B:设备试验类 WPF 上位机界面与流程

内容类型:重构教学案例难度:进阶适合:正在做 WPF 设备试验类界面的工程师阅读时间:约 15 分钟前置:已了解界面原型到 WPF 开发流程

案例 B 从一张效果图开始,但没有停在“看起来像工控软件”。后续修改围绕操作员任务、窗口伸缩、共享样式、曲线和试验状态展开。

V10 重读原则: 效果图只能证明视觉目标;按钮存在不等于业务动作已经定义;报警显示不等于必须停机;UI 禁用也不能替代后端联锁。

本案例已记录阶段

阶段覆盖情况说明
原始输入已记录效果图和多轮修改意见
用户流程部分记录从页面区域和操作意见恢复,不补造完整需求
页面职责已记录主界面、状态区、曲线区、日志区
状态机已记录运行/停机窗口和事件后果结构
UI 详细设计已记录布局、控件、状态显示和图表取舍
WPF 实现已记录页面骨架、样式、图表和 UI 细节
模拟验证部分记录不等同于真机验证
真机验证未完整覆盖保持 HardwarePending

按当前 V10 看这组案例

从效果图到可实现骨架

效果图可以说明:

  • 信息密度;
  • 大致分区;
  • 视觉层级;
  • 某些高频信息的位置偏好。

但不能直接证明:

  • 数据来自哪里;
  • 按钮何时可用;
  • 点击按钮是否真的下发设备;
  • 通信异常是否停机;
  • 哪些字段是操作员信息、哪些是维护诊断;
  • 哪些动作需要 HITL。

因此新页面/重设计先确认业务结构,而纯文案/样式修改直接走 UI MicroPatch。

页面职责按操作员任务划分

案例中页面逐步收敛成:

区域操作员需要什么不应该默认放什么
顶部状态当前设备/任务是否可继续PID、线程、内部服务名
参数区当前任务真正要修改的参数所有驱动/协议细节
观测区关键值、趋势、当前阶段原始协议堆栈
操作区高频动作及明确后果隐式改变配置的按钮
维护诊断原始错误、报文、版本、时间线占用主操作空间

对应方法:操作员界面与维护诊断

布局修改按问题逐层推进

第一层:信息归属

先确认哪些信息属于主任务,哪些只是辅助。

第二层:伸缩与密度

使用 Grid/自适应布局解决窗口尺寸、DPI 和曲线空间,不用大量固定像素“复刻截图”。

第三层:视觉一致性

颜色、间距、圆角、字体和状态色最后统一。

如果只是一个页面需要特殊宽度,局部覆盖即可;只有多个页面出现同一问题时才修改共享样式。

共享资源改动也不需要机械“全站逐页检查”。先查引用范围,按受影响页面做代表性 V1 验证;只有共享基础样式变化很大时才扩大范围。

UI 状态与真实安全要分开

例如:

text
启动按钮禁用

只能说明 UI 不允许点击,并不能证明底层 Service/API/快捷键/自动流程一定无法启动设备。

真实安全条件应在业务/设备边界再次检查。

同理:

text
页面显示红色报警

也不能直接推出:

text
必须 FaultStop

事件后果要明确分类:

text
Information
Advisory
AlarmOnly
InterlockFault

Testing / Resting 只描述项目业务窗口

案例中存在运行窗口和停机窗口,但不要把“Resting 必须关闭所有危险输出”抄成所有项目通用规则。

应写成:

text
Testing:
当前窗口允许哪些动作、采集和检查?

Resting:
哪些动作必须停止?
哪些监视仍继续?
哪些检查只在这一窗口运行?

具体设备后果由项目安全规则决定。

图表和日志只是页面能力,不是业务 Source of Truth

  • 曲线可以限频、抽样、截断显示;正式数据保存不能被 UI 窗口裁剪。
  • 日志摘要可以去重、中文化;维护日志仍保留原始错误和时间线。
  • UI 的“已连接”应来自设备/通信状态,不用固定演示值冒充真机。

本案例能证明什么

现有记录可以支持:

  • 效果图被转成有职责边界的 WPF 页面结构;
  • 页面布局从固定尺寸向可伸缩结构推进;
  • 共享样式与局部覆盖边界被明确;
  • 曲线和日志有独立接口边界;
  • 试验动作不再只是按钮事件,而进入状态/行为设计。

不能据此自动写:

  • 真机试验已通过;
  • 所有 DPI/分辨率已验收;
  • 联锁已通过现场验证;
  • 图表性能已经达到某个指标。

缺少对应证据时保持 Unverified / HardwarePending

相关方法

下一步

别来无恙 · C# 上位机 AI 实战站 · 从零到交付 · QQ 群:1016188499