基于机器监控应用的架构模式

Prev Next

Tulip 提供了围绕机器构建应用的灵活方式。选择合适的模式取决于您团队的技术成熟度、流程标准化程度以及预算。

模式 1:可组合的机器应用(1:1 模型)

结构:一台机器 → 一个应用程序 → 一个工位 → 一个终端

架构图:Machine Terminal App Pattern 1 - Composable Machine Apps.png

用例

  • 入门级公民开发者构建其首个机器监控应用
  • 在简单性优先于效率的情况下进行快速概念验证部署
  • 针对每台设备实例定制人工流程(例如:设备1需要独特的检查步骤,这些步骤不适用于设备2)
  • 以运维为主导的开发模式,开发人员身兼多职且时间有限

为何这很重要

该模式将软件与硬件进行1:1的物理映射,消除了抽象层。开发人员可以识别车间中的某台机器,并将其映射到专属的应用程序。这种清晰性减少了认知负担,使故障排查变得直观。

示例

场景:某食品饮料制造商拥有3条包装生产线。每条生产线都有独特的停机原因、部件配置和操作员工作流程。

实现

  • 创建机器类型:“包装生产线”
  • 创建 3 台设备:“A 线”、“B 线”、“C 线”
  • 构建 3 个应用程序:“A 线终端”、“B 线终端”、“C 线终端”
  • 将每个应用程序分配给配备固定终端的专用工作站

优势

  • 清晰的数据隔离可防止跨设备数据损坏
  • 易于自定义每台机器的工作流
  • 故障排查简单(问题总是在一个自包含的应用程序中)

局限性

  • 每台机器需要一个物理终端(硬件成本)
  • 全局应用程序更改需要更新3个独立的应用程序
  • 无法扩展至约10台机器以上

模式 2:将机器分配给工作站应用程序

结构:一种机器类型 → 一个应用程序 → 多个工作站(通过工作站映射动态分配机器)

架构图:Machine Terminal App Pattern 2 - Machine Assigned Station.png

用例

  • 在相同机器类型间实现标准化流程
  • 熟悉抽象概念和触发逻辑的全职公民开发者
  • 需要水平扩展(10台及以上同类型机器)
  • 集中式应用维护是首要任务

工作原理

  1. 在**“车间 > 机器”**(“配置”选项卡)中将每台机器分配到一个工位
  2. 在应用中,使用**“在此工位”**触发条件来动态引用已分配的机器
  3. 当应用在第1个工位运行时,它与第1台机器交互;当在第2个工位运行时,它与第2台机器交互

应用触发器示例

当:本工位上的机器输出状态变化时如果:机器输出 / 状态变化 =停机则:在“状态历史记录”表中创建表记录。

Log to Status History when Machine Stopped

示例

场景:一家汽车一级供应商拥有 15 台相同的数控铣床,运行着相同的生产流程。

实现

  • 创建机床类型:“5 轴 CNC 铣床”
  • 创建 15 台机床(CNC-001 至 CNC-015)
  • 构建一个应用程序:“CNC 操作员终端”
  • 创建15个工作站,每个工作站分配一台机床
  • 将该应用程序部署到所有15个工作站

优势

  • 只需维护一个应用程序(全局更新即时同步)
  • 缩短了针对设备群部署的应用程序开发时间
  • 采用“在此工作站”触发逻辑(内置动态机器引用)

局限性

  • 仍需每个站点配备一台终端(硬件成本依然存在)
  • 所有机器必须为同一类型且属性完全一致
  • 针对每台机器的自定义逻辑需要条件分支(增加了复杂性)

模式 3:机器变量应用程序(浮动终端)

结构:一个应用程序 → 多种机器类型 → 基于变量的机器选择 → 共享/浮动终端

架构图:Machine Terminal App Pattern 3 - Machine Variable.png

用例

  • 预算限制:可用终端数量有限
  • 浮动操作员模式:一名操作员携带共享的 iPad 在不同机器之间移动
  • 机器无需持续监控:应用程序仅需在操作进行期间运行

关键限制:不支持无显示器模式

该模式不支持后台/无头监控。如果应用程序被关闭,则不会触发任何机器警报。该模式仅适用于:

  • 人工发起的数据录入(操作员记录缺陷、零件计数)
  • 临时性设备检查
  • 应用未运行时设备不生成数据的场景

工作原理

  1. 在应用中创建一个设备变量(例如:selectedMachine)
  2. 添加下拉菜单控件或二维码扫描功能,以便在运行时填充selectedMachine 变量
  3. 在所有触发器引用中使用selectedMachine

应用触发器示例

当:机器变量“已选机器”输出 {属性}时,则:将“最后一台机器”的输出值存储到变量中

Store Machine Variable Output to Variable

示例

场景:制药实验室有 5 台分析仪器,仅在计划测试期间运行。技术人员使用共享的 iPad 记录测试参数和结果。

实现

  • 创建5台设备(HPLC-1、GC-MS-2等)
  • 构建一个应用程序:“实验室设备日志”
  • 添加下拉菜单:“选择仪器” → 填充selectedMachine变量
  • 技术人员携带iPad在各仪器间移动,选择正在运行的仪器,记录数据

优势

  • 硬件成本极低(仅需一台共享终端)
  • 运行时可灵活选择仪器
  • 非常适合临时/间歇性工作流程

局限性

  • 非无头模式——必须保持应用程序处于运行状态才能执行任何逻辑
  • 应用程序关闭时无法进行后台监控
  • 状态管理复杂(当前哪台机器处于活动状态?)
  • 不适用于全天候(24/7)OEE 跟踪

架构模式决策树

请使用此决策树选择最适合您需求的模式:Machine Terminal App Pattern Architect Options v2.png

延伸阅读