HMIDesigner 是平台唯一的工程「真相源」。它承担的不只是画面绘制，而是「通讯拓扑 + 数据模型 + 人机界面 + 运行策略 + 安全策略」的一体化定义，并把工程以可版本化、可协同、可热更新的形式交付给桌面运行站与 Web 运行站。
2.1 定位、技术架构与技术栈
Designer 与 Player 共享同一套运行时内核，但职责截然不同：Designer 负责定义，Player 负责执行。二者共享内核带来的最大好处是——组态环境中的预览、动画绑定、脚本调试与运行站的行为语义一致，不存在「组态软件里显示正常、运行站上表现不同」的经典问题。
| 技术要素 | 选型 | 选择理由 |
|---|---|---|
| 开发语言 | C++17 | 兼顾性能与工程可维护性；可在嵌入式与 WebAssembly 下编译 |
| 界面框架 | Qt 5.15.2 Widgets | 跨平台成熟、控件完整、授权友好（LGPL 可商用） |
| 图形渲染 | Qt 绘图 + OpenGL | 二维矢量画面与三维场景统一渲染管线 |
| 脚本引擎 | QtScript（ECMAScript） | 与工程数据模型紧耦合，可访问图元与测点对象 |
| 网络协议 | Qt Network / WebSockets + open62541 + MQTT | 覆盖工业协议、OPC UA 与消息总线 |
| 数据库 | SQLite（本地）/ MySQL（站点） | 工程与运行数据落盘，支持信创环境替换 |
| 三维模型 | assimp（含 WASM 端交叉编译） | 支持常见 3D 模型格式导入与场景组织 |
注
Designer 的工程文件与运行时工程是同构的：组态即运行数据模型的超集，发布动作仅做裁剪与索引，不做语义翻译。这是「边组态边调试」能力的技术前提。
2.2 工程组织模型
工程的组织方式决定了大型项目的可维护性。Designer 以工程树为唯一入口，把工程内容划分为六条主线：通讯组态、图形组态、运行服务、操作策略、资产与设备树、协同与治理。
2.2.1 工程树的六条主线
| 主线 | 包含对象 | 解决的问题 |
|---|---|---|
| ① 通讯组态 | 通信通道 → 设备 → 数据块 → 测点（寄存器/地址映射） | 把「哪台设备的哪个地址」变成「一个有名字、有量程、有单位、有质量的测点」 |
| ② 图形组态 | 画面 / 子画面、图元库、自定义图元、动画连接、图表曲线报表、3D 场景 | 把测点变成可读可操作的画面元素 |
| ③ 运行服务 | OPC UA Server/Client、MQTT Bridge/Broker、UCCRealDb、Historian、HTTP 分发 | 定义运行站对外提供与被访问的数据服务 |
| ④ 操作策略 | 写联锁、SBO、双人复核、死区与量程、报警分级、RBAC 权限 | 把「操作规程」变成系统强制执行的技术约束 |
| ⑤ 资产与协同 | ISA-95 设备树、Edge Loop 边缘回路、多用户协同、检出锁、变更审计、工程版本比对 | 让工程与工厂的实际资产结构对应，并支持多人协作 |
| ⑥ 安全策略 | 登录认证、操作授权、审计留痕、工程完整性、通信加密 | 满足等保与工业信息安全的基本要求 |
2.2.2 工程侧车（Sidecar）机制
大型工程的可维护性痛点之一是「画面文件越改越乱、与运行配置耦合在一起」。Designer 采用侧车文件机制：把通道诊断快照、运行策略、安全策略、协同锁等以独立文件随工程发布，不污染画面工程主体，并支持按需热装载。
2.3 通讯组态：从通道到测点
通讯组态采用「通道 → 设备 → 数据块 → 测点」四级模型。这一模型的价值在于：采集的组织方式与数据块的物理连续性对齐，从而把通信效率问题在组态阶段解决，而不是在运行期靠调参。
| 层级 | 组态内容 | 典型工程实践 |
|---|---|---|
| 通道 Channel | 协议类型、接口参数（串口参数/TCP 地址端口）、超时、重试、采集周期 | 按物理链路或协议族划分通道，独立线程采集，互不阻塞 |
| 设备 Device | 站号/节点号、TSAP、单元标识、会话与安全策略、点表偏移 | 同一通道下挂多台设备，共享链路但独立会话与超时 |
| 数据块 DataBlock | 起始地址、长度、字节序、编码方式、批量优化策略 | 把连续寄存器组织为一次读取，减少报文数量 |
| 测点 Tag | 名称、数据类型、量程、单位、死区、报警属性、写权限、描述 | 测点即数据模型的原子单元，被画面、脚本、报警、历史共同引用 |
2.3.1 协议默认值与规范化
不同厂商对同一协议常有细节差异（例如 S7 的 TSAP 约定、三菱/欧姆龙 FINS 的网络号与节点号），这些差异往往导致「驱动对着文档配也连不通」。平台为常用协议内置了规范默认值与辅助函数，把设备键与系统标签名的写法统一规范化，减少现场试错成本。
| 协议 | 内置规范化内容 |
|---|---|
| Siemens S7 | TSAP 默认约定（机架/槽位映射）、连接类型、PDU 协商 |
| Mitsubishi / Omron FINS | 网络号、节点号、单元号的默认取值与组合规则 |
| Modbus | 功能码选择、寄存器区码（线圈/离散/输入/保持）、字节序与字序组合 |
| IEC 60870-5-104 | 公共地址、传送原因、信息对象地址的默认范围与解释 |
| DNP3 | 链路地址、主站地址、对象组与变体默认值 |
| OPC UA | 安全策略、消息安全模式、端点发现与证书信任处理 |
2.3.2 通道诊断
每个通道提供独立的诊断视图，覆盖运行期最关心的信息：
注
上述 KPI 逐台累加在设备对象上，并被运行监控面板聚合为「采集异常累计」，可直接用于验收与运维考核。
2.4 图形组态与图元体系
图形组态的核心目标是「让工程师用最少的操作把数据变成可理解的画面」。Designer 的图形体系由四层构成：
| 层次 | 内容 | 说明 |
|---|---|---|
| 画布层 | 画面 / 子画面 / 弹出画面 / 背景画面 | 支持层级组织与相互调用 |
| 图元层 | 基础图元、行业图元、自定义图元、复合图元 | 可组合、可封装、可复用 |
| 数据绑定层 | 动画连接（颜色/位移/旋转/可见性/闪烁/填充）、图表、曲线、报表 | 绑定即建立图元与测点的数据通路 |
| 交互层 | 按钮动作、输入框、确认对话框、操作确认与权限校验、脚本事件 | 把操作员动作转化为受控的数据写入 |
2.4.1 图元与复用
图元支持封装为可复用组件：把一组图形元素及其数据绑定、脚本行为打包为一个自定义图元，在工程内多处实例化。修改定义即可批量更新所有实例，这是大型工程控制工作量的关键手段。
2.4.2 曲线、报表与 3D
2.5 脚本与表达式
脚本用于表达无法用声明式配置描述的工程逻辑。平台的脚本引擎与数据模型深度集成，可直接访问图元对象与测点对象。
| 能力 | 说明 |
|---|---|
| 图元脚本 | 图元级事件（点击、数值变化、加载、显示）触发，可读写自身与其它图元属性 |
| 画面脚本 | 画面级周期脚本与事件脚本，适合做汇总计算与联动 |
| 数据访问 | 读写测点值、读取质量码与时间戳、查询历史、调用报警操作 |
| 宿主交互 | 调用宿主提供的接口（如弹窗、报警确认、报表导出） |
| 调试 | 脚本错误与异常进入事件日志，可在运行监控面板查看，Web 端脚本缓存条目受限（桌面 256 / Web 48） |
注
权限模型说明：在 Web 运行站中，脚本执行默认受到更严格的限制——任意宿主脚本默认关闭，危险方法调用走白名单机制，且在未登录操作员的情况下不允许写入类操作。这一策略保证了「浏览器端不成为安全短板」。
2.6 运行服务配置
运行服务在工程树中集中配置，一次定义即可在桌面站与 Web 站生效。
| 服务 | 配置内容 | 作用 |
|---|---|---|
| OPC UA Server | 端点、端口（默认 4840）、安全策略、证书与信任列表、命名空间与节点映射、订阅与报警条件 | 把平台数据以标准 OPC UA 形式对外开放 |
| OPC UA Client | 服务器地址、会话参数、订阅周期、断线重连策略 | 从第三方 OPC UA 服务器采集数据 |
| MQTT Bridge / Broker | Broker 地址与端口（1883/8883）、ClientID、主题映射、遗嘱（Will）消息、QoS、TLS | 与物联网平台、云平台或第三方系统交换数据 |
| UCCRealDb | 监听地址与端口（默认 6389）、内存上限、淘汰策略、持久化策略、主从关系、认证与 ACL | 对外提供实时数据的读写与订阅能力 |
| Historian | 存储路径、分片策略、压缩策略、保留周期、WAL 策略 | 长期历史数据的存储与查询 |
| HTTP 分发 | 工程目录、资源目录、访问控制、缓存策略 | 为 WebPlayer 提供工程与资源文件，并支持完整性校验 |
2.7 操作策略与安全
工业现场的事故大多源于「不按规程操作」。平台的策略引擎把操作规程转化为系统强制约束，使违规操作在技术层面就无法完成。
| 策略 | 机制 | 典型场景 |
|---|---|---|
| 写联锁 (Interlock) | 按条件表达式禁止或允许写入，条件可引用其它测点、设备状态、报警状态、时段 | 泵未停不允许关阀；工艺条件不满足不允许修改设定值 |
| SBO 选择-校验-执行 | 先选择对象 → 系统校验条件 → 再执行，选择阶段与执行阶段分离并带超时 | 大批量设备的分步操作，防止误操作相邻设备 |
| 双人复核 / 双岗 | 关键写入需要第二个有权限的用户确认后生效 | 关键参数修改、保护定值修改 |
| 死区与量程处理 | 按测点配置死区过滤、量程钳位、工程量转换与单位换算 | 抑制抖动、防止越量程数据污染历史与报警 |
| 报警分级与延时 | 按优先级分级、按延时确认、按抖动次数抑制 | 避免瞬态扰动产生海量无效报警 |
| RBAC 权限 | 基于角色的访问控制：角色 → 权限 → 对象/操作 | 操作员/班长/工程师/管理员分级授权 |
2.7.1 审计与留痕
2.8 协同开发与工程治理
中大型工程通常由多人并行开发，若缺少治理机制，很快就会退化为「谁也不敢改」的泥团。Designer 提供以下机制：
| 机制 | 说明 |
|---|---|
| 多用户协同 | 支持多人同时打开工程，按对象粒度协作 |
| 检出锁 (Checkout) | 画面/对象被检出后由持有者独占修改，避免覆盖式冲突 |
| 侧车文件分离 | 策略、诊断、安全配置独立存储，减少画面文件的合并冲突 |
| 工程版本比对 | 对工程对象与策略文件做差异比对，评审变更内容 |
| 模板与库 | 工程模板、图元库、策略模板复用，统一企业级工程规范 |
| 完整性校验 | 工程发布时生成清单与哈希，运行端校验，防止被篡改或发布不完整的工程 |
2.9 操作便捷性
组态效率直接决定项目交付周期。平台在以下环节做了针对性的易用性设计：
| 环节 | 易用性设计 | 带来的效率提升 |
|---|---|---|
| 建点 | 批量导入测点表（Excel/CSV）、按规律批量生成、地址自增与偏移规则、命名规范化自动处理 | 把「逐点录入」变为「表驱动生成」，万点级工程从数天缩短到数小时 |
| 建画面 | 画面模板、图元库拖拽、批量属性修改、对齐与分布工具、图层管理 | 常用画面可复用模板，减少重复绘制 |
| 绑定数据 | 数据绑定对话框支持搜索、按设备树浏览、批量绑定与批量替换 | 避免在大量测点中手工查找 |
| 调试 | 在线预览、通道诊断、脚本事件日志、变量监视、增量热更新（不停机） | 现场调试不再需要「改一次、停一次、重启一次」 |
| 协议接入 | 协议默认值内置、连接测试按钮、报文轨迹 | 降低现场协议对接的试错成本 |
| 发布 | 一键发布 + 差异下装 + 热装载 | 工程更新不影响运行，Web 端由清单校验保证一致 |
| 排错 | 工程一致性检查（悬空绑定、重复命名、越界地址、无驱动设备、脚本错误） | 把错误在组态阶段暴露，而不是在运行期 |
2.9.1 与主流组态软件的易用性对比
| 易用性维度 | 国际主流 SCADA | 国产主流组态 | UCanCode 平台 |
|---|---|---|---|
| 工程组织 | 以画面/变量为主体，策略配置分散 | 以画面/变量为主体 | 六条主线分区（通讯/图形/服务/策略/资产/安全） |
| 批量建点 | 提供导入工具，格式要求严格 | 提供导入，规则能力有限 | 表驱动 + 规则生成 + 命名规范化 |
| 在线调试 | 部分产品需重新下装工程 | 多为停机下装 | 增量热更新，桌面与 Web 同步生效 |
| 策略配置 | 以脚本或选件实现，学习成本高 | 以脚本或专用模块实现 | 声明式策略配置 + 脚本兜底 |
| 错误预防 | 编译/检查能力因产品而异 | 检查能力有限 | 工程一致性检查覆盖绑定、命名、地址、驱动、脚本 |
| 多语言与本地化 | 中文化与本地支持依赖区域版本 | 中文原生支持好 | 中文原生 + 可扩展多语言 |
2.10 本章小结
HMIDesigner 的差异化不在「画面编辑器的功能数量」，而在三点：一是工程组织方式的工程化（六条主线 + 侧车分离 + 协同治理）；二是组态即运行的语义一致性（共享内核，桌面与 Web 同源）；三是把操作规程转化为技术约束的能力（联锁、SBO、双人复核、RBAC、审计）。这三点共同决定了大型项目能否在交付后长期可维护。