The architecture of an industrial intelligence ecosystem — how the 5 pillars compose into one operational data layer.
Four columns. Two peer entry points into the intelligence layer. Three deployment shapes. Designed to sit beside the SCADA / MES / historian infrastructure you already run — not to replace it.
- What runs where — the column structure of the Industrial Intelligence Stack
- Which deployment path fits — your floor topology, per plant
- How Elpis coexists with SCADA / MES / historian — sits beside, doesn't replace
- What changes when the network drops — store-and-forward + three-way diagnostics
One operational data layer with two peer entry points.
One operational data layer with two peer entry points. Hover any column to inspect what runs there. Click a column to zoom in.
About this mockup. The shipping page renders this as an interactive panel — hover any column to inspect what runs there, and click a column to zoom into the Connectivity-Edge or Acquisition detail. Progressive hover / zoom / click-to-focus interactivity is an engineering deliverable; this static mockup presents the same eight inspection annotations as labeled cards below, grouped by their three zoom levels.
Floor (Col 1)
PLCs, controllers, sensors. Brownfield or greenfield. Elpis reads what's there — doesn't require ripping anything out.
Col 2 — EdgeConnect peer
Polls existing controllers over native protocols (FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, S7). Normalizes to canonical CNC vocabulary. MT-LINKi REST integration on the roadmap.
Col 2 — Acquisition peer
mDAQ + mTracker + VAS + E-IDOS. Direct sensor reads where no PLC exists, where the PLC is locked, or where adding a PLC layer would be more expensive than acquiring the signal directly.
EREMOS V2 (Col 3)
OEE, alarms, incidents, reports. Models the real PLANT → AREA → LINE → EQUIPMENT hierarchy. Per-tenant isolation by design.
EdgeConnect runtime
Source / pipeline / sink health surfaced separately. Tells you immediately where the data path broke.
Edge Gateway hardware
Today: standalone PLC-to-cloud gateway. Tomorrow (when EdgeConnect Linux ships): the canonical EdgeConnect appliance. Same hardware, two lifecycles.
mDAQ direct-sensor row
4 analog channels (0-10 V or 4-20 mA), 16-bit, 860 S/s. 8 DI + 8 DO. Operates at remote and unmanned sites with battery + 4G.
EdgeConnect ↔ Acquisition arrow
When both peers deploy, Acquisition can feed EdgeConnect for normalization / routing. EdgeConnect can orchestrate Acquisition devices. Optional, not required.
Four columns, left to right.
Floor
Your existing PLCs, controllers, sensors, instrumentation, and machine assets. Mixed-vendor: FANUC + Brother + Mazak on one floor; Modbus PLCs beside Siemens S7 beside OPC UA endpoints. Greenfield installs where there's no controller yet, with the sensors connected directly. Brownfield retrofits where the controller is locked behind a vendor's proprietary boundary. The Floor is whatever you already have — Elpis reads it, doesn't replace it.
EdgeConnect + Acquisition (the two peer entry points)
The Elpis-owned layer where signals become canonical operational data. Two stacked peers that cooperate bi-directionally when both are deployed:
EdgeConnect (top peer) — the protocol-agnostic edge runtime. Polls existing controllers over their native protocols, normalizes signals to canonical CNC vocabulary, publishes to EREMOS V2 via MQTT and exposes signals via OPC UA Server. Runs Windows today; Linux on the roadmap.
Acquisition (bottom peer) — the direct-sensor hardware layer. mDAQ for general-purpose industrial signals (flow / pressure / temperature / vibration). mTracker for utilization + OEE telemetry on assets that don't speak a controller protocol. VAS + E-IDOS for vibration analysis and condition monitoring. Publishes to EREMOS V2 via MQTT / HTTPS direct.
See /capabilities/connectivity-edge for the EdgeConnect / Edge Gateway capability story. See /capabilities/data-acquisition, /capabilities/asset-intelligence, and /capabilities/condition-monitoring for the Acquisition-layer pillars.
EREMOS V2
The multi-tenant analytics platform that turns collected signals into operational decisions. Models the real industrial hierarchy — PLANT → AREA → LINE → EQUIPMENT → SUB_EQUIPMENT. Computes OEE via Segments (RUNNING / PLANNED_STOP / UNPLANNED_STOP / IDLE / SETUP) on the signals delivered from Col 2. Persistent alarms with incident workflows. Per-tenant isolation by design.
See /capabilities/operational-intelligence for the EREMOS V2 capability story.
Your Enterprise
Your existing SCADA, MES, historian, ERP, IT analytics, BI dashboards, data lake. EREMOS V2 publishes to your enterprise systems via the integration patterns described in the Integration patterns section below. Elpis doesn't replace these layers — it feeds them.
Choose EdgeConnect. Choose Acquisition. Choose both.
SOFTWARE ENTRY POINT · ACQUISITION ENTRY POINT · BOTH OPTIONAL
EdgeConnect and Acquisition are peers, not parent and child. They are two independent entry points into the intelligence layer. Customer deploys one, the other, or both.
Earlier architecture revisions implied that Acquisition feeds EdgeConnect, which then feeds EREMOS V2. That was wrong. mDAQ publishes to EREMOS V2 directly via MQTT / HTTPS — no EdgeConnect required. mTracker publishes directly. VAS / E-IDOS publish directly. EdgeConnect handles the existing-controller side of the floor; Acquisition handles the sensor-direct side.
When both peers are deployed, they cooperate bi-directionally: Acquisition signals can route through EdgeConnect for canonical normalization (useful when you want every signal — whether from a PLC or directly from a sensor — to arrive at EREMOS V2 in the same canonical shape). EdgeConnect can orchestrate Acquisition devices when deployed in the same plant (useful for device-management consolidation). Both forms of cooperation are optional. Neither is required.
This peer relationship is unique to the Elpis stack. It's why the same platform serves a CNC shop with mixed-vendor controllers, an oil-and-gas pipeline with no controllers at all, and a multi-site plant manager with both — without forcing any of them through a deployment shape that doesn't fit.
Choose the deployment path that fits each plant.
↓ The "When it fits" row is the self-selection mechanism — find your floor, pick your path.
The deployment shape is decided per plant, not per fleet. A multi-site operator can run brownfield-direct in one plant, Elpis-acquisition-only in another, and hybrid in a third — all reporting into one EREMOS V2 instance with consistent canonical vocabulary, OEE definitions, and alarm semantics across every site.
Designed to feed your enterprise, not replace it.
SCADA coexistence
EdgeConnect publishes to MQTT and exposes signals via OPC UA Server. Your existing SCADA system can subscribe to either. Elpis doesn't take over operator HMIs, doesn't take over control logic, doesn't take over alarm acknowledgment in the SCADA. EREMOS V2 provides the cross-site analytics layer; SCADA stays where it is, with its existing operator interfaces and operational responsibilities.
Historian integration
EREMOS V2 supports historian and time-series integration patterns through customer-approved export, API, MQTT, or database integration paths. The customer's historian remains the long-term archive of record if that's the operational policy; EREMOS V2 surfaces analytics-grade views on top of the same signals. Specific historian destinations are validated per deployment during architecture review.
MES / ERP integration
EREMOS V2 exposes OEE rollups, downtime breakdowns, incident records, and shift reports via REST API. MES / ERP systems consume those rollups for production planning, maintenance scheduling, or service-hours billing. EREMOS V2 does not push transactions into MES / ERP — it provides the operational signal layer that those systems can read.
IT analytics / data lake
For organizations operating an enterprise data lake, EREMOS V2 can provide scoped operational exports through customer-approved integration paths — anonymized, scoped to operational signals, on a customer-controlled schedule. Specific cloud destinations are validated during architecture review.
Every integration pattern is opt-in per plant. No integration is required for Elpis to deliver value on the floor. The integration patterns become relevant when the customer wants Elpis's operational signals to inform their broader enterprise systems — which is typical for multi-site operators and uncommon for single-plant deployments.
What OT Architects ask before scoping an engagement.
Q1. Does this replace our SCADA?
No. EdgeConnect and EREMOS V2 sit beside your SCADA — they don't take over operator HMIs, control logic, or alarm acknowledgment workflows. SCADA stays where it is; Elpis adds the cross-site analytics layer and consolidates protocol coverage so your enterprise systems receive consistent canonical signals regardless of which controller produced them.
Q2. Can EdgeConnect run on Linux today?
Today, EdgeConnect ships as a Windows service. Linux is on the roadmap — when it ships, it will deploy on the Edge Gateway appliance as the canonical Linux footprint. For Linux-required customers today, the Edge Gateway hardware (standalone PLC-to-cloud gateway today, future canonical EdgeConnect appliance) handles the most common protocol bridging via its embedded Linux runtime.
Q3. What happens when the network drops?
Per-route store-and-forward. Every signal queues at the source with its quality code preserved. When connectivity returns, signals replay in source order — no lost cycles, no manual recovery step. Three-way diagnostics (source / pipeline / sink) surface immediately during the outage so you can see exactly which path was affected.
Q4. How do we integrate with our existing historian?
EREMOS V2 supports time-series database and enterprise historian integration patterns through customer-approved export, API, MQTT, or database integration paths. The historian stays the long-term archive of record if that's your operational policy. EREMOS V2 provides the analytics layer on top of the same signals — you don't have to choose between them. Specific historian destinations are validated per deployment during architecture review.
Q5. What's the security boundary between OT and IT?
EdgeConnect runs entirely on the OT side. License validates locally — no phone-home. Cloud connectivity is opt-in, not required. Plants on isolated OT VLANs install the same way as plants with internet access. Hash-chained configuration audit captures every change with actor identity and timestamp — tamper-evident, replay-ready. Full operational trust posture: see /security.
Q6. Can one EdgeConnect deployment serve multiple plants?
No — that's an anti-pattern, and Elpis explicitly doesn't recommend it. Each plant runs its own EdgeConnect (typically on the Edge Gateway appliance) with a per-gateway UUID established at first start. Multi-site visibility comes from EREMOS V2 aggregating across the per-plant runtimes — not from a single multi-plant EdgeConnect runtime. This protects plant-level isolation, per-site identity, and offline operability per plant.
Q7. Where does EdgeConnect run?
EdgeConnect runs per plant, typically on customer-owned Windows infrastructure today, or on the Edge Gateway appliance when the Linux runtime ships. The deployment choice is made per plant based on network topology, security posture, and hardware preference. Single-plant deployments often start software-only on existing Windows infrastructure; multi-site standardizations typically converge on the Edge Gateway appliance once EdgeConnect Linux is available, for hardware consistency across sites. Either path is supported — neither is a prerequisite for the other.
Looking for the same thing from another angle?
Bring us your floor topology. We'll scope the architecture.
Whether you're scoping a brownfield retrofit, a greenfield install, a multi-site standardization, or a SCADA-coexistence integration — bring us the controller mix, sensor inventory, and existing-systems boundary. Architecture review runs against real protocols and real integration patterns, not slideware.