DynamicPlantMesh
Request a demo

Architecture & Deployment

Six cooperating services around one message bus

DynamicPlantMesh runs as 6 loosely coupled processes around a shared MQTT v5 broker and the historian that ships with the platform. Coupling is by message and API, so each process deploys, restarts and scales on its own.

Request a demoSee connectivity

System architecture

One web front end, five backend services, one shared bus

Browsers, external API consumers and AI agents each get their own entry point. Everything meets at the MQTT v5 broker and the historian data API.

System architecture

  1. Browser → Web app (live updates)
  2. External API consumers → Integration API (REST)
  3. AI agents → AI tool server (MCP over HTTP)
  4. Web app → MQTT v5 broker
  5. Web app → Historian data API
  6. Field gateway service → MQTT v5 broker
  7. Event & expression engine → MQTT v5 broker
  8. Event & expression engine → Historian data API
  9. KPI service → Historian data API
  10. Integration API → Historian data API
  11. AI tool server → Historian data API
  12. Historian data API → Historian database
One web front end and five backend services meet in the middle: a shared MQTT v5 broker for live messaging and the historian served through its data API over its relational database. External systems integrate through the REST integration API, AI agents through the MCP tool server.

Service roster

What each service does

One web front end and five backend services. Each has a single job, its own process and its own restart.

  1. Web app

    Dashboards, trends and timelines in the browser.

    The screen your plant looks at every day. Live values arrive from the broker; history and configuration come from the historian.

    7 panel types · 19 statistics per trace

  2. KPI service

    KPI and event extraction with live progress.

    Recalculates KPIs and extracts events over any period on request, reporting progress live while it runs. A heavy recalculation never touches the web tier.

    15 REST endpoints · 2 live progress hubs

  3. Integration API

    Governed REST access to tags and time-series.

    Gives reporting, MES and data-science teams the same historian data, behind per-user API keys and endpoint allow-lists.

    2 governed endpoints · 4 time-series resolutions

  4. Field gateway service

    Installs as a Windows service

    OPC-UA, OPC classic DA, embedded MQTT v5 broker and monitoring.

    Reads equipment over OPC-UA and OPC classic DA, hosts the embedded MQTT v5 broker and buffers samples to disk when a link drops, replaying them on reconnect, bounded by the configured disk buffer.

    9 worker service roles

  5. Event & expression engine

    Evaluates expressions over live data.

    Subscribes to the broker and evaluates the expressions your engineers author into events, states and KPI logs, written back to the historian for dashboards and timelines.

    40+ expression functions · 0 redeploys to change a KPI

  6. AI tool server

    MCP for external agents.

    Exposes purpose-built historian tools to your own AI agents over MCP, so every answer is grounded in the live historian rather than a copy of it.

    18 MCP tools for external agents

Deployment model

Runs where your plant runs

On-premise, data-sovereign, operated by the team you already have. Nothing here needs a container orchestration team.

  • On-premise Windows hosts

    Every service installs on Windows hosts at the plant, with the historian and its relational database beside them, and your IT/OT team runs it with the tools they already have.

  • Independent restart and scale

    Coupling is by message and API only. Restart the KPI service, upgrade the field gateway or add capacity to one process without touching the others. A heavy KPI recalculation never touches the web tier.

  • No container orchestration required

    Plain Windows services and a web host. There is no cluster to stand up and no container orchestration team to hire.

  • Plant-vs-server time-zone model

    New

    The historian keeps its own clock; every chart and timeline shows plant wall-clock time. The offset is derived from both zones at query time, so daylight-saving transitions are honoured.

  • Console mode for development

    The field gateway runs as a Windows service in production and in console mode on a developer machine, so an integrator can prove a new OPC-UA connection before it goes live.

Multi-site

Shared platform core, per-site deployments

One shared platform core, one production-site deployment per plant. Every site reuses the same UI library and core data model, then adds what is unique to it.

Shared
One UI library and one core data model, reused by every site and upgraded once.
Per site
Its own data library, theme, time zone, authentication and endpoints.
Isolated
Each site is a separate app instance. An upgrade or outage at one never touches another.

Shared-core multi-site model

  1. Shared UI library → Site A app instance
  2. Shared UI library → Site B app instance
  3. Core data model → Site A app instance
  4. Core data model → Site B app instance
  5. Site A data library → Site A app instance
  6. Site B data library → Site B app instance
Shared platform core with per-site deployments: every production-site deployment reuses the same UI library and core data model, then adds its own site data library, theme, authentication and endpoints, and runs fully separately from every other site.

In numbers

What runs behind a single deployment

  • 6cooperating services
  • 43domain entities
  • 2live progress hubs
  • 9worker service roles

Configure a plant solution — don't build one.

See the six services running against live plant data.

Request a demoSecurity model