Ten-plus plants on one operational view.
EdgeConnect deploys at every plant — its own runtime, its own identity, its own offline resilience. One EREMOS V2 tenant aggregates the fleet. Consistent OEE definitions, alarm semantics, and shift reports across every site you operate.
Per-gateway UUID · Customer/site binding · Multi-tenant aggregation · Offline-resilient at every site · Same southbound stack everywhere: FOCAS2 · MTConnect · Brother HTTP · Modbus TCP · OPC UA Client · Siemens S7 (MT-LINKi REST on the roadmap).
A fleet view that doesn't actually view the fleet.
Every plant in your fleet has its own monitoring story. Plant A runs an old vendor SCADA. Plant B has a custom monitoring stack a previous IT director built. Plant C just joined the group through an acquisition, and you haven't even surveyed its floor yet. Each one produces its own OEE number, its own alarm list, its own shift report. The numbers don't reconcile. The semantics don't match. The reports arrive in different formats on different cadences.
Corporate operations gets the worst of every world: a fleet view that doesn't actually view the fleet. Someone in the central office stitches plant-level reports into a quarterly board deck and labels the math "approximate." Performance comparisons across sites stay aspirational. Acquiring a new plant means another long integration project before the new site even shows up in the corporate view.
The trap is treating fleet visibility as an aggregation problem — building a central data warehouse that pulls from each plant's existing tools. That works until the next plant's tools change, or the next acquisition brings a system you've never seen. The real answer is the inverse: standardize the data layer at the edge, plant by plant, and the fleet view becomes a subscription, not an integration project.
"A fleet view that doesn't actually view the fleet."
How this differs from single-plant monitoring scaled by hand. The usual path to a fleet view is to keep each plant's monitoring tool and reconcile centrally — a data warehouse pulling per-plant exports, or a central team re-keying numbers into a board deck. It holds together until the next plant's tools change, or an acquisition arrives with a system nobody has seen. Elpis takes the inverse path: standardize the data layer at the edge of every plant, so each site emits the same canonical signals in the same shape, and the fleet view becomes a subscription to a consistent stream instead of a reconciliation project. The per-plant tools stay where they are; Elpis adds the consistent cross-fleet layer beside them.
The numbers reconcile because the definitions are platform-level, not plant-level.
From EdgeConnect (at every site — Windows service today)
- Per-site runtime — a Windows service on a small box in the control cabinet, sized to that plant's controller count. Every plant uses the same installer and the same onboarding flow.
- Same southbound stack at every plant — FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 all ship today, so a brownfield site and a newer plant collect through the same protocol coverage regardless of vendor mix. On the roadmap: FANUC MT-LINKi REST. For the full protocol matrix with semantic modes, see /edgeconnect.
- Per-gateway UUID and customer/site binding — established at first start. Plant identity is clean from day one and survives reorganizations and acquisitions.
- Per-route store-and-forward — local SQLite buffering with per-sink cursors. A plant disconnected from the central broker keeps collecting and replays in source order on reconnect.
- Three-way diagnostics per site — source / pipeline / sink. Central ops can see which site's data flow broke, and on which leg.
- Connectivity Studio per site — local plant teams manage their own sources, sinks, and tag maps without routing every change through corporate IT.
- Hash-chained audit log per site — tamper-evident change history at every plant, available for corporate audit review.
EdgeConnect ships as a Windows service today; fleets typically run it on a small box in each plant's control cabinet. A Linux runtime is near-term roadmap, arriving on the Edge Gateway appliance for plants that prefer a turnkey DIN-rail box. The appliance is a per-site option, not a requirement, and there is no single appliance that spans plants — each plant runs its own.
From EREMOS V2 (central — aggregating across the per-site runtimes)
- Multi-tenant aggregation — one deployment, many sites or business units, aggregating across the per-plant runtimes. Plant data is isolated per tenant.
- Fleet-wide asset model — PLANT → AREA → LINE → EQUIPMENT → SUB_EQUIPMENT, with each plant slotting into the corporate hierarchy.
- Consistent OEE Segments across sites — RUNNING, PLANNED_STOP, UNPLANNED_STOP, IDLE, SETUP. Same definitions, same math, every site.
- Cross-site dashboards — fleet-level views with drill-down into any plant, any line, any machine.
- Per-site alerting routes — corporate alerts go to corporate channels; plant-level alerts go to plant channels.
- Reporting templates that scale — the same shift-report template applied to every site against each site's actual schedule.
- Per-tenant access control — corporate ops sees the fleet; plant teams see their plant; business-unit leads see their BU.
What corporate operations ask before scoping a fleet.
How do we standardize OEE across plants that currently calculate it differently?
EREMOS V2 computes OEE Segments centrally from edge-collected signals using one consistent definition, configured to how your group defines OEE. Each plant's existing calculation becomes legacy; the platform's calculation becomes the number you defend in a board review or a customer audit. Because every plant's signals arrive in the same canonical shape, the math is the same at every site — so a cross-site comparison is defensible rather than "approximate."
Does one EdgeConnect serve all our plants?
No — and that's deliberate. Each plant runs its own EdgeConnect runtime with its own 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. That's what keeps each plant isolated, identifiable, and able to keep collecting when its network drops — and it's why one plant disconnecting never affects the others.
What happens when a plant's internet drops?
That plant's EdgeConnect buffers locally with per-route store-and-forward and replays in source order on reconnect. No fleet outage, no lost production data — the plant keeps collecting, and only the central view for that one site lags until connectivity returns. Three-way diagnostics surface immediately during the outage, so central ops sees exactly which site and which leg were affected. Plants on isolated networks operate the same way; cloud connectivity is opt-in, not required.
How does this scale when we acquire a new plant?
Install EdgeConnect at the new site, point it at the central broker, register the gateway in the EREMOS V2 tenant — and the new plant shows up in the fleet view. Same installer, same protocol coverage, same canonical vocabulary, same tag-mapping playbook. There is no per-plant integration project, which is what turns acquisition onboarding from a quarters-long effort into a weeks-long one.
Who owns the platform at each site versus centrally?
Plant teams manage their site's EdgeConnect configuration — sources, sinks, tag maps — through the local Connectivity Studio, because the per-gateway runtime model gives each site its own administrable instance. Corporate ops manages the EREMOS V2 tenant, the cross-site dashboards, the reports, and the cross-site policies. Both layers have their own access control. Local autonomy and central visibility coexist by design, rather than one being traded for the other.
Can different business units keep their data walled off?
Yes. Each business unit can be its own EREMOS V2 tenant with its own users, dashboards, and reports, with plant data isolated per tenant. Corporate ops can hold an aggregate view across BUs if the org chart calls for it. And none of it replaces your SCADA, MES, or historian — those keep their jobs at each plant and consume canonical signals instead of vendor-specific ones.
What changes when this lands across the fleet.
- Fleet visibility that actually views the fleet — one operational dashboard across every plant, every shift, every machine
- OEE numbers that reconcile across sites — consistent definitions, consistent math, no more "approximate" board-deck footnotes
- Per-site outage resilience — one plant disconnecting never affects the others; buffered data replays in source order on reconnect
- Acquisition onboarding in weeks, not quarters — a new plant onboards with the same architecture, not a custom integration project
- Local plant autonomy preserved — plant teams manage their site's configuration without a corporate-IT bottleneck
- Cut the manual fleet-report reconciliation — cross-site rollups built from canonical signals, not re-keyed spreadsheets
- Cross-site benchmarking made defensible — same OEE definitions, same alarm semantics, same reporting templates across the fleet
How multi-site fleets typically roll this out.
Pick the plant that's most representative of the fleet, or the most painful one. A standard single-site engagement at that plant — proof of value in the first week, cell expansion over the next few weeks, full-plant rollout over the following weeks. The pilot proves the platform against your actual production reality at one site, on its real protocols.
Once the pilot is operational, the second plant goes faster: same architecture, same protocols, same canonical vocabulary, plant teams trained from the pilot's playbook. The central EREMOS V2 tenant is configured to aggregate both sites, and the cross-site view comes alive.
Remaining plants are brought online in parallel where plant capacity allows. Each plant uses the same EdgeConnect installer, the same gateway-registration flow, the same tag-mapping playbook. Cross-site dashboards activate as each plant comes online. Pace tracks plant capacity for tag-map authoring and acceptance testing, not a vendor-promised number.
New acquisitions, new lines at existing plants, new business units — all onboard through the same architecture, each new plant getting its own per-gateway runtime. The protocol coverage is already there: FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 all ship today; FANUC MT-LINKi REST is on the roadmap. Fleet visibility scales with the fleet, not with the integration team.
How the pieces fit together across the fleet — every plant works on its own, the fleet works as a whole.
Nothing depends on the cloud — per site. Each plant's EdgeConnect runs offline by default — license validates locally, no phone-home. If a plant's network or the central broker drops, that site's per-route store-and-forward buffers locally and replays in source order on reconnect. Plants on isolated networks install and run the platform the same way as connected ones; cloud connectivity is opt-in, not required.
Per-gateway identity + hash-chained configuration audit, at every plant. Each plant runs its own EdgeConnect runtime with a per-gateway UUID and customer/site binding established at first start — so the fleet view is unambiguous and survives reorganizations and acquisitions. Every change at every site — a new machine added, a tag-map edit, a threshold change — is captured with actor identity and timestamp in a tamper-evident, replay-ready audit chain, available for corporate audit review.
Read the full operational trust posture → /security
Looking for the same thing from another angle?
Bring us your fleet.
Tell us about your plants — how many, where, what controllers, what your current monitoring looks like. We'll scope a pilot at one site and a path to fleet rollout against your actual operational reality. No multi-year platform commitment required to prove the architecture works.