Tier0 对比 United Manufacturing Hub：开源基础设施还是产品化的 UNS 应用交付平台？
产品
3分钟
United Manufacturing Hub (UMH) 是现代制造数据领域最受关注的开源项目之一。它将一组经过挑选的开源组件（用于数据采集的 Node-RED、MQTT 代理、Kafka、TimescaleDB、Grafana 等）打包，形成构建统一命名空间（Unified Namespace, UNS）的参考架构。对于注重开放基础设施、透明度以及自主托管和扩展技术栈能力的工程主导型团队来说，UMH 是一个强有力的起点。
Tier0 对开放工业数据架构持有相似的信念，其嵌入式技术骨干使用了许多相同的开源技术（Node-RED、EMQX、TimescaleDB、Marimo Notebook）。但 Tier0 以不同的方式将工作流产品化。Tier0 并没有要求客户去组装、运行和扩展多个组件，而是通过 Namespace、SourceFlow、EventFlow、时间序列持久化、Notebook 和 App Builder，提供了一个产品化的 UNS 基础。
两条路径的分歧点
维度 | UMH 风格的方法 | Tier0 方法 |
|---|---|---|
架构 | 开源参考架构；团队负责组装和运行组件。 | 产品化的全栈 UNS 平台；各模块作为一个整体进行集成和运行。 |
集成负责人 | 工程团队通常负责组装和运营。 | 平台将集成过程产品化。 |
UNS 基础 | 由开源组件和工程配置构建而成。 | 通过 Tier0 模块构建：Namespace、SourceFlow、EventFlow、时间序列持久化。 |
应用层 | 通常通过仪表板、自定义应用程序或外部工具来处理。 | App Builder 通过自然语言生成 UNS 原生应用。 |
数据分析 | 通常与外部可视化或分析工具组合使用。 | Notebook 是 Tier0 工作流的一部分。 |
AI / 大语言模型 (LLM) | 不属于核心项目的一部分。 | 应用交付的核心产品机制。 |
首个商业应用落地时间 | 长 — 组装和应用开发是按顺序进行的。 | 短 — 基础架构已预先集成，应用可直接生成。 |
UMH 在何处停止，Tier0 在何处继续前行
UMH 很好地解决了数据基础设施问题。在安装和配置之后，团队就拥有了一个可以工作的 UNS、一个 MQTT 骨干网、一个历史数据库和一个仪表板工具。UMH 没有解决——也未声称要解决——的是应用层。要从“我们有一个 UNS”跨越到“我们有一个停机应用、一个检验应用、一个维护应用”，团队仍然需要编写代码、构建仪表板、设计表单，并按照约定将每个新应用集成回命名空间中。
这正是 Tier0 旨在缩短的差距。Tier0 在底层拥有相同类型的、面向 UNS 的基础设施，但应用层是产品本身的一部分，而不是一个单独的工程项目。工程师用自然语言描述他们想要的东西；App Builder 就会生成一个可以从命名空间读取并写入其中的工作应用。这个新应用不是一个指向时序数据库的 Grafana 仪表板，而是被设计为一个参与到命名空间中的应用程序。
UMH 为您提供了 UNS 的开源碎片。Tier0 则为您提供了一个产品化的 UNS 基础，以及在其上生成 UNS 原生应用程序的 AI。
何时 UMH 可能是更好的选择
对于那些希望拥有并运营堆栈的每一层、具有强大的内部工程能力、计划扩展开源组件或对其做出贡献，并接受应用层是其责任的团队来说，UMH 可能是更合适的选择。对于主要交付成果是参考数据基础设施而不是业务应用程序的组织来说，UMH 的开放和组件化模型具有吸引力。
何时 Tier0 可能是更好的选择
如果团队的主要交付成果是基于 UNS 运行的应用程序，而不是 UNS 基础设施本身，那么 Tier0 可能是更合适的选择。如果团队中包括工艺工程师、质量工程师、工业工程（IE）工程师和维护工程师——这些了解工厂问题但不想编写集成代码的人员，那么 Tier0 的产品化模块和自然语言应用生成功能将极大地缩短实现路径。
关于哲学的一点说明
这并非一场关于开源与商业的辩论。UMH 和 Tier0 在底层使用了相似的开源构建块。真正的问题在于谁拥有集成，以及谁拥有应用层。UMH 的答案是：团队。Tier0 的答案是：平台 —— 并且由 App Builder 生成应用程序。
