Enabling Fleet Management of Non Margo Devices through a Gateway Service #80

Activity

1. Phil6706

   assigned

   abbottjd

   and

   bnieuwborg

   on Mar 31, 2026
2. Phil6706

   added

   PM - Requirement in Draft

   on Mar 31, 2026
3. ajcraig

   added a sub-issue on Jun 10, 2026

   • Define the Margo "Gateway" capability Requirements specification#137
4. abbottjd

   added the

   Epic (Child)

   issue type on Aug 3, 2026
5. abbottjd

   added this to the PR2 milestone on Aug 3, 2026
6. abbottjd

   added this to product managementon Aug 3, 2026
7. github-project-automation

   moved this to PM - Requirement in Draft in product managementon Aug 3, 2026
8. abbottjd

   removed

   PM - Requirement in Draft

   on Aug 3, 2026
9. abbottjd

   added a parent issue on Aug 3, 2026

   • Parent Epic 5: Build a Margo compatible edge device #41
10. abbottjd commented on Aug 10, 2026

    

    abbottjd

    on Aug 10, 2026

    Collaborator

    More actions

    For discussion:

    • References to device management
    • Assess scope
    • Correctness
    • Use of term "Margo Service Gateway"
11. Phil6706 commented on Oct 5, 2026

    

    Phil6706

    on Oct 5, 2026

    ContributorAuthor

    More actions

    Publication of a new version of the child EPIC : Opaque and See-Through gateway types have been replaced by Minimum Transparency and optional Enhanced Transparency. This improves the gateway visibility model but does not address the broader requirement of automatic application-to-device matching, which should be handled separately. A supporting document has also been added to clarify the resource reporting approach and the use of gateway service commitments.

    Opaque-Gateway-Resource-Reporting.pdf

    ---

    Title: Enabling Fleet Management of Non Margo Devices through a Gateway Service

    ---

    Requirement Summary
    This requirement proposes introducing a Service Gateway based Device Management capability to Margo, enabling a significant ecosystem expansion into supporting a wider range of industrial deployment architectures, where for some reasons, the margo-specified fleet management clients (workload fleet management client and device fleet management client) reside not directly on the device being managed, but as a gateway service somewhere else.
    An Extension to Margo PR1 (Product Release 1) Specification
    This requirement is additional to Margo PR1specifications providing an explicit gateway representation. It is already possible, based on the Margo PR1 specification, for a gateway to act as if it were a device and expose functions in that role. However, this new requirement makes the gateway appear as its own separate entity to the fleet manager. As a result, the fleet manager gains a clearer view of the real system setup because it can now distinguish the gateway from the actual device.
    However, device management not being today part of the margo specification, unified OS firmware and Edge application update management for gateway connected Devices, should be in a separate requirement. The intent of this requirement for a gateway service, is to have device management work seamlessly for all devices, regardless of whether they host their own margo client or are behind such a gateway.

    Requirement Description (Functional Perspective)
    Business Need
    Many industrial devices in the field (including legacy equipment, constrained devices, and highly isolated devices) cannot run a native Margo client. The lack of compatibility results in barriers to adoption for device manufacturers, system integrators, and end customers who want a unified fleet management experience across diverse device types.

    Functional Requirement
    Margo shall allow deployment and lifecycle management of applications on devices that do not implement the Margo interface (workload and device fleet management clients), by introducing the concept of a Margo Service Gateway.
    The gateway acts as a bridge between the Workload Fleet Manager and one or multiple devices, enabling:
    • Consolidated device onboarding through a single gateway
    • Unified visibility of heterogeneous device capabilities (either through gateway-level deployment capabilities and commitments or through individual device capabilities, according to the level of gateway transparency).
    • Application deployment across mixed environments (gateway itself, specific sub devices, or autonomous placement chosen by the gateway)
    • Status and error reporting at gateway or sub device level
    • Support for devices requiring high network isolation, where only the gateway communicates with the outside world
    • Future readiness for constrained OT/embedded device categories

    Gateway Transparency
    Margo Service Gateway may expose different levels of transparency for the devices it manages, depending on implementation objectives, security constraints, and operational requirements.

    Minimum Transparency
    The Workload Fleet Manager sees only the gateway as a managed entity.
    The gateway exposes deployable service capabilities and commitments rather than aggregated resource inventories. The gateway remains responsible for workload placement, admission control, resource allocation, and device selection within its managed domain.
    The Workload Fleet Manager owns the deployment intent; the gateway owns the execution.
    Suitable for proprietary, constrained, isolated, or autonomous downstream environments where the internal topology should remain hidden.
    Examples:
    • A machine builder exposes a complete production cell through a gateway. The Workload Fleet Manager can deploy a Quality Inspection application without knowing on which internal IPC, controller, or compute node the application ultimately runs.
    • A gateway manages two devices:
    o Device A: 2 CPU, 5 GiB RAM
    o Device B: 2 CPU, 5 GiB RAM
    Although the gateway owns a total of 4 CPU and 10 GiB RAM, advertising these aggregated resources could be misleading because no individual device may be capable of hosting a workload requiring 8 GiB RAM. Instead, the gateway advertises only the deployment capabilities it commits to deliver, for example:
    • Supported deployment types:

    • Helm
    • Compose
      • Deployment commitments:
    • Up to 10 Vision Inference deployments
    • Up to 20 Asset Monitoring deployments
    • Up to 5 Historian and Data Collection deployments
      The Workload Fleet Manager deploys against these advertised capabilities and commitments, while the gateway determines internally where workloads execute and how resources are allocated. The Workload Fleet Manager owns the deployment intent; the gateway owns the execution.

    Enhanced Transparency (Optional)
    The gateway may additionally expose managed devices and selected device-level capabilities to the Workload Fleet Manager.
    Individual device characteristics, capabilities, health, and workload status may be reported separately.
    This enables workload placement targeting specific managed devices when supported by the gateway implementation.
    Suitable for environments requiring advanced orchestration, workload affinity rules, operational troubleshooting, or device-level visibility.
    Examples:
    • A gateway managing three IPCs exposes each device individually, allowing the Workload Fleet Manager to deploy an AI Vision application on a GPU-equipped IPC while deploying a historian workload on another device.
    • A gateway managing a mix of Linux and RTOS devices exposes device-specific capabilities, enabling operators to select the most appropriate execution target for each workload.
    The minimum transparency model provides the simplest onboarding experience and strongest implementation autonomy for gateway providers. The enhanced transparency model delivers additional operational value where device-level visibility, reporting, and placement control are required.

    Non Functional Requirements
    The introduction of a Margo Service Gateway requires a set of non functional expectations to ensure predictable, secure, and robust behavior across diverse industrial environments. These characteristics guide engineering decisions and ensure suitability for OT critical deployments. It specifically supports:
    • Security Requirements
    • The gateway shall enforce secure communication channels between itself, the Workload Fleet Manager, and all connected sub devices.
    • Authentication and authorization mechanisms must ensure that only trusted components can onboard or manage sub devices.
    • The gateway shall isolate sub devices from direct external exposure and act as a controlled access point for all management traffic.
    • Performance Requirements
    • The gateway shall support management of multiple sub devices without degrading responsiveness of Workload Fleet Manager operations.
    • Latency for state reporting and control commands shall remain within acceptable industrial limits depending on deployment scenarios.
    • Throughput shall support repetitive application deployments and capability queries without creating bottlenecks.
    • Scalability Requirements
    • The gateway shall support a varying number of sub devices, from a minimal footprint up to a large downstream network, based on hardware capacity.
    • Resource allocation shall prevent a single sub device from blocking command processing or telemetry reporting.
    • Reliability & Failover Requirements
    • The gateway shall maintain management continuity during temporary network disconnects or sub device unavailability.
    • After a restart or software update, the gateway shall automatically re establish communication with all sub devices and restore last known states.
    • The system shall detect and report unreachable sub devices without impacting management of the remaining fleet.
    • Network Topology Constraints
    • The gateway shall operate correctly across segmented, firewalled, and restricted egress industrial networks.
    • Communication patterns shall remain compatible with regulated OT zones and constrained network policies.
    • Resource Footprint Requirements
    • CPU, memory, and storage consumption of the gateway shall remain compatible with typical industrial gateway hardware and when possible, directly embedded into a Edge device.
    • The gateway shall adapt its resource usage dynamically based on the number of active sub-devices and workloads being managed.

    ---

    Product Management insights
    This Service Gateway design significantly broadens Margo’s addressable market, facilitates adoption by vendors who cannot directly implement the Margo specification, and strengthens Margo’s positioning as a flexible, vendor friendly Edge interoperability standard capable of scaling across diverse hardware categories.

    It specifically supports:
    • Market Expansion: Further reduces the entry barrier for device vendors who cannot or prefer not to embed a full Margo client, enabling participation from a wider range of device manufacturers.
    • Ecosystem Growth: Extends Margo’s reach to heterogeneous fleets, including constrained, legacy, or isolated devices commonly found across industrial IoT environments.
    • Users Value: Delivers a unified management experience across the entire fleet (native and non native devices) while adding visibility and operational control of the gateway itself through the Margo fleet manager.
    • Alignment with Margo Strategy: Reinforces strategic objectives related to modular workload distribution, hybrid OT/IT integration, and reduced friction during system onboarding and modernization efforts.
    • Roadmap Leverage: Provides a scalable architectural foundation that allows incremental introduction of advanced features without requiring changes to existing device implementations.

    ---

    Related User Journey (Marketing View)
    Persona: Workload Fleet Manager (Industrial Automation System Integrator, OT Fleet Operations Manager…)

    1. Fleet Onboarding Phase
       User Goal: Bring both Margo-native devices and legacy/non Margo devices into a single management system.
       Journey Steps:

    2. User deploys one or several Margo Gateways in the network segment containing non Margo devices.

    3. Gateway automatically registers itself to the Workload Fleet Manager.

    4. Depending on the transparency level supported by the gateway:
       • Minimum Transparency: User sees "Gateway X" as a managed entity exposing deployment capabilities and service commitments.
       • Enhanced Transparency: User sees "Gateway X" together with managed devices and their individual capabilities. [Sce gatewa...V2_261002 | Word]
       Outcome: Both native Margo devices and gateway-managed environments are onboarded into a single fleet management experience.

    5. Capability Discovery Phase
       User Goal: Understand what workloads can be deployed either through a gateway-managed environment or on individual devices.
       Journey Steps:

    6. Gateway reports available computing roles (cluster, standalone, etc.).

    7. In Minimum Transparency mode, the user sees the deployment capabilities and service commitments exposed by the gateway.

    8. In Enhanced Transparency mode, the user browses each sub-device's individual capabilities.
       Outcome: User can plan workload placement with full visibility.

    9. Application Deployment Phase
       User Goal: Deploy an application on a mixed fleet.
       Journey Steps:

    10. User selects an application (whatever the technology Compose or Helm) in the Workload Fleet Manager.

    11. User chooses deployment strategy:
        o Direct placement on Gateway or Device A/B.
        o Autonomous placement where the gateway chooses the optimal sub device.

    12. Workload Fleet Manager sends desired state including the correct device IDs.
        Outcome: Workloads are deployed successfully even on devices that cannot run the Margo client.

    13. Monitoring Phase during operations
        User Goal: Understand which app is running where and detect issues quickly.
        Journey Steps:

    14. Gateway reports status updates for itself or the sub-devices.

    15. On error (sub-device unreachable, no resources, etc.), Workload Fleet Manager shows clear messages.

    16. User can reassign workload or troubleshoot accordingly.
        Outcome: Operational clarity across complex mixed environments.

    17. Fleet Evolution Phase
        User Goal: Add or remove devices from the setup without reconfiguration.
        Journey Steps:

    18. Gateway automatically updates the Workload Fleet Manager when a sub-device is added or removed.

    19. Workload Fleet Manager continually reflects the real footprint of the gateway-managed fleet.
        Outcome: Effortless lifecycle management of changing device landscapes.

    20. Update of the Gateway Service
        User Goal: Ensure the gateway can be updated and maintained like any other Margo managed entity.
        Journey Steps:

    21. Workload Fleet Manager identifies the gateway as an updatable component.

    22. User selects the new gateway version or package in the Workload Fleet Manager.

    23. Workload Fleet Manager deploys the update to the gateway service (container, package, or binary).

    24. Gateway restarts its service modules and re-establishes sub-device communication.

    25. Workload Fleet Manager displays updated version and status, with rollback available in case of failure.
        Outcome: The gateway remains secure, up to date, and fully functional, without disrupting management of connected sub devices.