Article Type: Concept
Audience: Solution Architects, Enterprise Administrators, Partners
Module: Fuuz Gateway, Fuuz Enterprise
Applies to Versions: 2025.12

1. Overview

Fuuz is the first industrial operations platform to offer a true cloud-to-edge architecture that fundamentally transforms how manufacturing and industrial organizations deploy operational technology (OT) solutions. Unlike traditional on-premise-only MES/WMS systems that require extensive local infrastructure, or pure cloud platforms that depend on VPNs and complex network configurations, Fuuz provides a secure, scalable architecture where the cloud and on-premise worlds seamlessly converge.

The Fuuz architecture consists of three distinct layers:

• Fuuz Enterprise (Hub): The central platform providing infrastructure, scalability, and cross-app visibility
• Fuuz Apps (Cloud Edge): The IT/OT convergence point where business logic meets plant operations—previously called "tenants"
• Fuuz Gateways (On-Prem Edge): Secure tunnels connecting physical plant assets to their respective Fuuz Apps
  
• Fuuz Gateways (On-Prem Node): Deployed at the extreme edge at the machine.

This architecture enables organizations to run full facility MES/WMS solutions on a single App, or deploy isolated point solutions for specific work cells, lines, or processes—all within the same Enterprise. The critical mass and infrastructure is handled by Fuuz in the cloud, while gateways serve as secure conduits to the physical site.

2. Architecture & Core Concepts

Fuuz Enterprise (Hub)

Fuuz Enterprise serves as the central hub for all industrial operations. A single customer Enterprise can consist of many Apps, regardless of how many physical locations exist. Enterprise can be deployed in three configurations:

• Fuuz Cloud (SaaS): Hosted and managed by Fuuz—the most common deployment
• Private Cloud: Customer-hosted in their own cloud infrastructure (AWS, Azure, GCP)
• Full On-Premise: Complete Fuuz stack deployed within customer facilities

Fuuz Apps (Cloud Edge)

Each Fuuz App (previously called "tenant") serves as the cloud edge—the critical convergence point between IT (Red) and OT (Blue) data domains. This is where:

• Logical and physical world mapping occurs
• Business logic for plant-level scenarios is implemented
• Enterprise data (Red) blends with operational data (Blue)
• Cross-system integrations are orchestrated

Apps can be scoped based on organizational needs:

Cross-App Communication

Apps within an Enterprise can communicate and share data through several patterns:

• Shared Enterprise Data Sets: Common master data (products, materials, customers) accessible across Apps
• Split Business Processes: Workflows spanning multiple Apps (e.g., MES hands off to WMS)
• Data Flow Integration: Apps communicate directly via Data Flows for real-time data exchange
• Aggregation Apps: Dedicated Apps that pull and consolidate data from multiple source Apps

Fuuz Gateway (On-Prem Edge)

The Fuuz Gateway operates exclusively in the Blue (OT) data domain, serving as a secure tunnel between physical plant assets and the Fuuz App in the cloud. Key characteristics:

• One-to-One Relationship: Each gateway connects to exactly one Fuuz App
• Secure WSS Tunnel: Outbound-only WebSocket connection—no inbound ports required
• OT Data Only: Interacts with plant/factory assets, machines, databases, and on-premise systems
• IT/OT Blend at App: The gateway delivers Blue data to the App where it blends with Red (IT) data

[Illustration: Data domain diagram showing Blue (OT) data flowing from Gateway through WSS tunnel to App where it blends with Red (IT) data]

Architecture Hierarchy

The following diagram illustrates the Fuuz Enterprise architecture with multiple Apps and Gateways:

[Illustration: Visual architecture diagram showing Enterprise hub with multiple Apps as cloud edges, each with their respective gateways as on-prem edges connecting to plant floor assets]

Full On-Premise Deployment

When the complete Fuuz stack is deployed on-premise, Fuuz connects directly to machine assets via Edge Connectors without requiring gateways. However, gateways may still be recommended in certain scenarios:

• Internal Network Reliability: When internal networking is unreliable, gateways provide Store and Forward capabilities
• Network Segmentation: When assets exist on isolated network segments that cannot reach the Fuuz server directly
• Distributed Edge Screens: When HMI applications require local gateway presence for optimal latency
• Redundancy Requirements: When individual cell/line isolation is required for high availability

Key Definitions

• Edge Connector: The specific connector used to communicate with an asset (e.g., Ethernet/IP PLC, Modbus TCP, OPC-UA Client, MQTT Client, Native Printer)
• Edge Connector Type: The base connector category sharing common functionality (e.g., PLC, Printer, MQTT, Server, Modbus)
• Edge Connection: A configured connection to a specific asset using an Edge Connector
• Edge Subscription: A configuration that defines what data to collect from an Edge Connection and how to handle it (including Store and Forward options)
• Edge Gateway: The Fuuz Gateway instance that hosts Edge Connections and communicates with a Fuuz App
• Gateway Flow (Edge Flow): A Data Flow that runs on the gateway to collect, transform, and forward data from on-premise assets
• Store and Forward: A feature that locally buffers data when cloud connectivity is lost and automatically syncs when connectivity is restored

3. Edge Connector Types

Supported Connector Types

Supported Edge Connectors

4. Gateway Deployment Options

Windows Application or Service

The Fuuz Gateway is available as a Windows application or Windows service. This deployment method is suitable for:

• Small-scale deployments with limited functionality requirements
• Single gateway per physical or virtual machine
• Environments where containerization is not feasible

Container Deployment (Recommended)

For large-scale deployments, container deployment using Docker with Portainer.io templates is strongly recommended. Benefits include:

• Multiple gateways per host machine
• Simplified management of Build, QA, and Production environments
• Easier scaling and orchestration
• Consistent deployment across environments
• Centralized update management and version tracking
• Reduced infrastructure overhead compared to multiple Windows VMs

Best Practice: Gateways should generally be deployed using a container approach with Docker and Portainer.io for the best management experience—enabling easy tracking of updates, version control, and multi-environment management. During implementation and continued development, organizations typically require Build, QA, and Production gateway installations.

5. Capacity Planning & Sizing

The primary factor determining gateway requirements is data volume and throughput, not simply asset count. The following tables provide guidance for sizing gateway deployments based on common scenarios.

Data Collection Scenarios

These scenarios assume data collection and monitoring use cases (read operations to Fuuz App):

Ultra Hybrid HMI Scenarios

For distributed manufacturing environments with bi-directional HMI requirements, a gateway-per-workstation model ensures optimal performance, redundancy, and availability:

[Illustration: Assembly line floor plan showing gateway placement at each cell with PLC connections and edge screen terminals]

6. Deployment Scenarios

Small-Scale Deployments

A single Fuuz Gateway connecting to a single App is appropriate for:

• Plant-wide label printing from a centralized queue
• Asset monitoring with 50 or fewer assets at moderate data volumes
• Monitoring 1,000+ assets with single data points collected at low frequency (e.g., one point per second)
• Limited bi-directional communication requirements

Centralized Gateway Deployments

Deploy gateways centrally (like a primary gateway server) when:

• Data collection is the primary use case (minimal bi-directional control)
• Internal network reliability is high
• Centralized IT management is preferred
• Network-based printing or file folder monitoring is required

Distributed Gateway Deployments

Distribute gateways throughout the plant for redundancy, availability, and isolation when:

• HMI applications require bi-directional PLC communication
• Edge Screens must remain operational during network disruptions
• Individual cell/line isolation is required for high availability
• Internal network reliability is questionable

Large Distributed Installations

For hybrid MES, WMS, or HMI solutions at scale:

• Deploy one Fuuz Gateway per HMI workstation
• Use Docker/Portainer to manage Build, QA, and Production gateways at each node
• Consider local databases (SQLite, PostgreSQL) alongside edge gateways for ultra-high availability
• Store critical data locally (work orders, bill of materials, recipes) for operation during internet outages
  

7. High Availability & Store and Forward

Store and Forward

Store and Forward provides data resilience during connectivity interruptions between the gateway (On-Prem Edge) and the App (Cloud Edge):

• Data is first stored/logged locally on the gateway
• Data is then pushed to the Fuuz App when internet access is available
• During outages, data buffers locally and syncs automatically when connectivity resumes
• Typically supports 2-6 hours of buffering depending on data volume
• Available for most subscription types including Tag Values, OPC-UA Nodes, MQTT Topics, and TCP Sockets

Continuous Values Option

When Store and Forward is enabled, the Continuous Values setting controls data transmission behavior:

• Enabled (default): All value updates are pushed to Fuuz
• Disabled: Only the most recent value for each data point is pushed to Fuuz

[Screenshot: Edge Subscription configuration showing Store and Forward and Continuous Values options]

Enhanced High Availability

For more robust high availability beyond Store and Forward's capabilities:

• Install a local SQL Server, Oracle database, or historian alongside the gateway
• Use a Gateway Flow to pre-process and publish data to the local historian
• Create a second Gateway Flow to query the historian and push data to Fuuz App
• Mark successfully synced data points with timestamps for auditing
• The Fuuz App supports this pattern via Flows, API calls, and Webhooks

8. Distributed Gateway Communication

While Fuuz Gateways connect directly to their respective Fuuz Apps, some deployments require real-time data sharing between gateways—for example, when one gateway processing machine data needs to share information directly with another gateway controlling downstream equipment.

MQTT Broker Architecture

To enable gateway-to-gateway communication, implement a centralized MQTT broker pattern using pub/sub messaging:

[Illustration: Distributed gateway architecture showing central MQTT broker with multiple gateways as clients, demonstrating pub/sub message flow for machine-to-machine communication]

Fuuz Gateway as MQTT Broker

A Fuuz Gateway can function as an MQTT broker using the mqttBroker Edge Connector:

• Deploy one gateway configured as an MQTT broker on your local network
• Configure other gateways as MQTT clients (mqttClient) connecting to the broker gateway
• Use MQTT topics to route data between gateways in real-time
• Gateway Flows can publish and subscribe to topics for data exchange

Third-Party MQTT Brokers

For enterprise-scale deployments or advanced messaging requirements, consider third-party MQTT brokers:

Configuration Pattern

To set up distributed gateway communication:

1. Deploy MQTT Broker: Either configure a Fuuz Gateway with the mqttBroker Edge Connector or deploy a third-party broker on your network
2. Configure Client Gateways: Add mqttClient Edge Connectors on each gateway that needs to participate in distributed messaging
3. Define Topic Structure: Establish a topic hierarchy for your data (e.g., plant/line1/cell3/status)
4. Create Gateway Flows: Build flows that publish data to topics and/or subscribe to topics from other gateways
5. Optional - Sparkplug B: For standardized industrial messaging, use the mqttSparkplugB Edge Connector

9. Alternative Infrastructure

The Fuuz Gateway is the preferred choice for most deployments. However, if your organization has existing industrial infrastructure, direct integration may be possible:

Compatible Systems

When Fuuz Gateway Is Required

• Existing infrastructure cannot publish data to cloud endpoints
• Existing infrastructure is fragile and you want to avoid additional load
• Hybrid solutions requiring Fuuz Edge Screens (HMIs)
• Bi-directional control from the Fuuz App
• Project requirements favor centralized gateway management

10. Architecture Decision Guide

Deployment architecture depends on several factors unique to each implementation:

11. Limitations & Considerations

While the Fuuz architecture is highly flexible, certain limitations should be considered during planning:

• Gateway is not a server: The gateway is a client application without unlimited scaling capabilities
• One gateway to one App: Each gateway connects to exactly one Fuuz App
• High-volume/high-fidelity data: Sub-second frequencies with high data volumes may require multiple gateways or pre-processing
• Single instance per Windows VM: Container deployment recommended for multi-gateway scenarios
• Store and Forward capacity: Typically 2-6 hours depending on data volume; extended outages require local database solutions

12. Resources

• Fuuz Industrial Operations Platform
• IIoT Nodes Reference
• Event Nodes (Edge Subscription)
• Portainer.io - Container Management
• HiveMQ - Enterprise MQTT Platform
• EMQX - Scalable MQTT Broker
• Eclipse Mosquitto - Open Source MQTT Broker

13. Troubleshooting

14. Revision History