One operational view across every controller on your floor — without ripping out what you already have.
Protocol-agnostic edge runtime for FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and S7. Canonical CNC vocabulary at the edge. Deploy software-only on your Windows infrastructure today, or on the Edge Gateway appliance — and standardize across plants when you scale.
Live integrations: FOCAS2 · MTConnect · Brother HTTP · Modbus TCP · OPC UA Client · Siemens S7. FANUC MT-LINKi REST on the roadmap.
Three or four vendors, three or four monitoring tools, one operations team reconciling by hand.
Most factory floors have controllers from three or four vendors. A FANUC cell beside a Mazak machining center beside a Brother tapper beside a Siemens S7 line. Each vendor ships a native monitoring tool — FANUC NCStudio, Mazak SmartBox, Brother BCMS, Siemens TIA. Each tool speaks its own vocabulary, has its own UI, its own alarm thresholds, its own reporting cadence. Operations teams that want one operational view across every machine end up either using all the per-vendor tools (and reconciling reports manually), or building custom integration scripts that break every time a vendor pushes a firmware update.
The teams that try to consolidate usually face the same three problems: (1) per-protocol custom scripting is expensive to write, expensive to maintain, and expensive to extend when a new controller shows up on the floor, (2) the SCADA / historian / MES already running on the floor doesn't speak the same canonical vocabulary as the integration layer that gets built around it, so reports drift across systems, (3) when the team finally has signals consolidated, the integration is hosted on a single industrial PC that becomes the new single point of failure — and the operations team has to learn yet another piece of infrastructure to maintain.
The teams that succeed do something different. They put a protocol-agnostic edge runtime in front of every controller — one runtime that speaks every native protocol the floor uses today, normalizes signals to a canonical vocabulary at the edge, and publishes the normalized stream once for every downstream system that wants it. The SCADA stays. The historian stays. The MES stays. The integration tax goes down. That's what this page is about.
"The SCADA stays. The historian stays. The MES stays. The integration tax goes down."
How this differs from per-vendor monitoring tools. Per-vendor monitoring tools (FANUC NCStudio, Mazak SmartBox, Brother BCMS, Siemens TIA, etc.) each work — for the vendor they ship with. They each speak vendor-specific vocabulary, have their own UI conventions, and report on their own schedule. Edge Connectivity puts a protocol-agnostic edge runtime in front of every vendor at once, normalizes signals to canonical CNC vocabulary at the edge, and publishes that normalized stream once for every downstream system that needs it. Same FANUC, same Mazak, same Brother, same S7. Same operations team. One canonical vocabulary across them all. The per-vendor tools stay where they are; Elpis adds the cross-vendor layer.
The next controller added to your floor should not require a new monitoring stack.
Choose the deployment shape that fits each plant.
Software-only
- WHEN IT FITS
- Sites with existing Windows infrastructure where running EdgeConnect on customer-owned hardware fits the operations team's preferences.
- WHAT'S DEPLOYED
- EdgeConnect runtime on customer Windows + EREMOS V2.
- EDGECONNECT TODAY
- Windows service running on customer-owned infrastructure.
- HARDWARE FOOTPRINT
- Software-only.
Edge Gateway appliance
- WHEN IT FITS
- Sites that prefer a ruggedized turnkey appliance — DIN-rail mount, embedded Linux, built-in 4G + Wi-Fi + Ethernet, USB firmware updates.
- WHAT'S DEPLOYED
- Edge Gateway appliance (standalone PLC-to-cloud today; canonical EdgeConnect appliance once Linux ships) + EREMOS V2.
- EDGECONNECT TODAY
- Edge Gateway ships standalone today with built-in Modbus TCP + cellular publish. EdgeConnect Linux is near-term roadmap — when it ships, it deploys on Edge Gateway as the canonical EdgeConnect appliance, same hardware.
- HARDWARE FOOTPRINT
- Appliance per plant (200 × 150 × 75 mm rugged enclosure, 24 V DC).
Hybrid (multi-site)
- WHEN IT FITS
- Multi-plant operators standardizing across diverse plant topologies — software-only on some plants, appliance on others, all per-plant runtimes feeding one EREMOS V2 tenant.
- WHAT'S DEPLOYED
- Per-plant mix: EdgeConnect (Windows) or Edge Gateway (appliance), each with its own per-gateway identity.
- EDGECONNECT TODAY
- Whichever runtime fits each plant; multi-site identity reconciled in EREMOS V2.
- HARDWARE FOOTPRINT
- Per-plant choice.
The deployment shape is decided per plant, not per fleet. A multi-site operator can run software-only EdgeConnect in one plant, the Edge Gateway appliance in another, and either in a third — all reporting into one EREMOS V2 instance with consistent canonical vocabulary, OEE definitions, and alarm semantics across every site. The shape changes per plant; the operational story stays the same. And the Edge Gateway's dual identity matters at procurement time: the same hardware that solves today's standalone PLC-to-cloud need becomes tomorrow's canonical EdgeConnect appliance once Linux ships — reducing platform migration friction as deployments evolve, and reducing the need to maintain customer-owned Windows infrastructure on plants that prefer a turnkey appliance.
From the Edge Layer
EdgeConnect (the protocol-agnostic edge runtime, Windows today)
- Protocol coverage today: FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, S7. On the roadmap: FANUC MT-LINKi REST integration. For the full protocol matrix with semantic modes + security profiles, see /edgeconnect.
- Canonical CNC vocabulary at the edge — every signal arrives at every sink in the same shape regardless of which controller produced it.
- Publishes to MQTT, exposes via OPC UA Server, publishes to HTTP/TCP — multiple downstream consumers from one normalized stream.
- Per-route store-and-forward buffering — no lost cycles during broker outages or maintenance windows.
- Three-way diagnostics — source / pipeline / sink health surfaced separately, so the OT team knows which leg failed before production feels the symptom.
- Hash-chained configuration audit — every change captured with actor identity and timestamp; tamper-evident, replay-ready.
EdgeConnect ships as a Windows service today. The Linux runtime is near-term roadmap; when it ships, it deploys on the Edge Gateway appliance as the canonical EdgeConnect appliance. The Edge Gateway appliance ships today standalone with built-in Modbus TCP + cellular publish — it grows into the broader EdgeConnect platform path on the same hardware once Linux ships.
Edge Gateway (ruggedized appliance, optional — software-only is fully supported)
- Ruggedized industrial gateway running embedded Linux — 256 MB RAM, 2 GB Flash, 24 V DC, 200 × 150 × 75 mm rugged enclosure.
- Built-in Modbus TCP server/client (today, standalone).
- 4G + Wi-Fi + Ethernet connectivity with USB firmware updates.
- Web-configurable — DIN-rail mount, no separate industrial PC required.
- Dual identity: today a standalone PLC-to-cloud gateway. Tomorrow, once EdgeConnect Linux ships, the canonical EdgeConnect appliance — same hardware, two lifecycles.
From EREMOS V2 (consuming the canonical stream)
- Multi-tenant analytics — per-plant signals arrive at per-tenant scope; multi-site visibility from one EREMOS V2 instance across per-plant EdgeConnect runtimes.
- OEE computed on canonical signals — same OEE math across every plant + every shift + every vendor controller.
- Persistent alarms with incident workflows — alarm → triage → assigned-to → resolution → closure, with operator notes at each step.
- Customer-controlled cloud connectivity — opt-in, not required. Plants on isolated OT VLANs install and run the platform the same way as plants with internet.
What OT Architects ask before scoping a brownfield consolidation.
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-vendor canonical-vocabulary layer and consolidates protocol coverage so your downstream systems (SCADA, historian, MES) receive consistent canonical signals regardless of which controller produced them.
Can EdgeConnect run on Linux today?
Today, EdgeConnect ships as a Windows service. Linux is near-term roadmap — when it ships, it deploys on the Edge Gateway appliance as the canonical EdgeConnect appliance. For Linux-required customers today, the Edge Gateway hardware handles the most common protocol bridging via its embedded Linux runtime — but in standalone PLC-to-cloud mode (built-in Modbus TCP + cellular publish), not yet as an EdgeConnect runtime (which arrives when EdgeConnect Linux ships). Both paths are supported; neither is a prerequisite for the other.
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 (Windows service or 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.
What protocols are covered today vs roadmap?
Today: FOCAS2 (FANUC CNCs), MTConnect (CNC standard), Brother HTTP (Brother CNCs), Modbus TCP (general industrial), OPC UA Client (broad industrial), and S7 (Siemens). On the roadmap: FANUC MT-LINKi REST integration (FANUC robotics / line-monitoring via MT-LINKi's REST API on port 3000). Each shipped protocol ships with semantic-mode coverage appropriate to the controller class — for the full matrix (semantic modes, security profiles, integration test patterns, OPC UA Server security mode detail), see /edgeconnect. Roadmap protocols are scoped during the architecture review based on the controller mix you bring.
How do we integrate with our existing historian or MES?
EdgeConnect publishes to MQTT and exposes signals via OPC UA Server. EREMOS V2 publishes incident records and OEE rollups via REST API. Your historian (whether time-series database like InfluxDB / TimescaleDB or enterprise historian) consumes from the OPC UA Server or the MQTT stream. Your MES consumes EREMOS V2's rollups via API or webhook. Beside, not replacing — both your historian and your MES stay where they are; they consume canonical signals instead of vendor-specific ones. For the full integration-patterns walkthrough, see /architecture §3.6.
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 the OT team can see exactly which path was affected. Plants on isolated OT VLANs operate the same way; the cloud connectivity is opt-in, not required.
What changes when this lands.
- One operational view across every controller on your floor — FANUC, Mazak, Brother, Siemens, generic Modbus, OPC UA endpoints — speaking the same canonical CNC vocabulary at every downstream system
- Cut per-vendor monitoring tool sprawl — the per-vendor tools stay where they are; Elpis adds the cross-vendor layer so the operations team works against one consistent view, not three or four reconciled-by-hand reports
- Cut custom protocol scripting and the firmware-update tax — the protocol-agnostic edge runtime owns the protocol drivers; operations doesn't rewrite scripts every time a vendor pushes a firmware update
- Multi-site canonical consistency — every plant's EdgeConnect runtime produces signals in the same canonical CNC shape; cross-site reports stop drifting because every site reads the same vocabulary
- Per-gateway identity from day one — multi-site fleets have unambiguous per-plant identity from first start; acquisitions, divestitures, plant transfers, name changes survive the identity model unchanged
- No new monitoring stack for SCADA-running plants — your SCADA, historian, and MES stay where they are; they consume canonical signals via OPC UA Server / MQTT / API instead of vendor-specific ones
- Audit-ready configuration history — every protocol-driver enable, every routing change, every threshold edit captured with actor identity and timestamp; tamper-evident, replay-ready
How the pieces compose for edge connectivity.
Offline-first operation, including air-gapped plants. EdgeConnect runs offline by default. License validates locally — no phone-home. Cloud connectivity is opt-in, not required. Plants on isolated OT VLANs install and run the platform the same way as plants with internet access. Per-route store-and-forward survives connectivity gaps without losing source ordering.
Per-gateway identity + hash-chained configuration audit. Each plant runs its own EdgeConnect runtime with a per-gateway UUID established at first start. Hash-chained configuration audit captures every change (protocol-driver enables, routing changes, threshold edits) with actor identity and timestamp — tamper-evident, replay-ready. Acquisitions, divestitures, plant transfers, name changes — the identity model survives them all.
Read the full operational trust posture → /security
Looking for the same thing from another angle?
Bring us your controller mix. We'll scope the deployment shape.
Whether you're scoping a brownfield CNC retrofit, a mixed-vendor consolidation, a greenfield install with existing PLC infrastructure, or a multi-site standardization across diverse plant topologies — bring us the controller list, the existing-systems boundary (SCADA / historian / MES coexistence), and the per-plant deployment-shape preferences. Architecture review runs against real protocols and real integration patterns, not slideware.