EdgeConnect
The protocol-agnostic edge runtime at the core of the Elpis platform. One service polls every controller on your floor over its native protocol, normalizes every signal to one canonical vocabulary, and delivers it once to every system that needs it — with store-and-forward and three-way diagnostics built in.
FOCAS2 · MTConnect · Brother HTTP · Modbus TCP · OPC UA Client · Siemens S7 — normalized to one canonical vocabulary. FANUC MT-LINKi (REST) on the roadmap. Windows today; Linux on the roadmap. Offline by default.
One runtime in front of every controller on the floor.
EdgeConnect is a Windows service that runs on a small box in your control cabinet. It connects to the controllers you already own — CNCs, PLCs, and instrumentation — over their native protocols, normalizes every reading to a shared canonical vocabulary, and publishes that normalized stream once for every downstream consumer: an MQTT broker, an OPC UA Server, EREMOS V2, your SCADA, your historian.
It is the Connectivity & Edge pillar of the Industrial Intelligence Ecosystem. For the capability story, see the Connectivity & Edge capability. This page is the product detail — the full protocol coverage, deployment model, and licensing.
What the runtime does.
Protocol-agnostic core
The core runtime references no protocol. Adapters plug in and are activated by license at startup — new protocols ship without touching the old ones.
Canonical normalization
Every signal becomes a canonical data point — spindle_rpm, cycle_time, alarm state — before routing, regardless of which vendor produced it.
Per-route store-and-forward
SQLite-backed buffering with per-sink cursors. Connectivity gaps replay in source order on reconnect — queued data is preserved, not dropped.
Three-way diagnostics
Source, pipeline, and sink health surfaced separately, so the OT team sees exactly which leg of the data path broke.
Per-adapter isolation
A failing adapter never affects another adapter, route, or sink. A misbehaving sink never blocks a healthy one.
Connectivity Studio
Web admin for sources, routes, and sinks, with Test Connection probes and a draft → validate → apply → rollback flow before any change reaches the data path.
Hash-chained audit
Every configuration change captured with actor identity and timestamp in a tamper-evident, replay-ready chain.
Fan-out routing
One source fans out to many sinks independently — a failing sink never blocks a healthy one. Delivery mode is configured per route: at-most-once or at-least-once. Exactly-once is not offered.
Every protocol the runtime speaks.
| Protocol | Direction | Status | Coverage / modes |
|---|---|---|---|
| FOCAS2 | Southbound | Available | Fanuc CNCs (0i / 16i / 18i / 21i / 30i / 31i / 32i) — axes, spindle, alarms, tool, production counters, programs. Polled. |
| MTConnect | Southbound | Available | The open-standard CNC streaming protocol; probe-document driven. |
| Brother HTTP | Southbound | Available | Brother CNCs (S700Xd1 and similar) via the built-in web-monitoring interface. |
| Modbus TCP | Southbound | Available | PLCs, drives, energy meters — any Modbus TCP device, including PLCs fronting older CNCs. |
| OPC UA Client | Southbound | Available | OPC UA-native controllers, gateways, and servers across broad industrial equipment. |
| Siemens S7 | Southbound | Available | Native S7 driver for Siemens PLC fleets; manual tag-address mapping. |
| MQTT | Northbound | Available | Any compliant broker (Mosquitto, HiveMQ, EMQX, AWS IoT Core, Azure IoT Hub). Batch or per-tag publish modes. |
| OPC UA Server | Northbound | Available | Exposes signals to SCADA / MES / HMI. Security modes: Sign, SignAndEncrypt, X.509. ISA-95-style browse paths configurable. |
| FANUC MT-LINKi (REST) | Southbound | Roadmap | Fanuc's REST-based machine-data product, via its REST API. |
| HTTP sink | Northbound | Roadmap | Direct delivery to REST endpoints. |
| TCP sink | Northbound | Roadmap | Delivery to legacy TCP listeners. |
This page carries the product-level protocol matrix. Deployment-specific semantic modes, connection-pool sizing, and conformance checks are confirmed during the architecture review against your real controller mix.
How it runs.
| Host platform | Windows service today (.NET 8). Linux is near-term roadmap — it ships on the Edge Gateway appliance as the canonical EdgeConnect appliance. Cross-platform by design. | |
| Deployment shape | Software-only on customer hardware (a small control-cabinet box), or the ruggedized Edge Gateway appliance (DIN-rail, embedded Linux) — an option, not a requirement. | |
| Footprint | One service per plant or per cell, sized to the controller count. Runs offline; no cloud dependency. | |
| Identity | Per-gateway UUID + customer/site binding established at first start. Each plant runs its own runtime; multi-site visibility comes from EREMOS V2 aggregating across per-plant runtimes — never one runtime spanning plants. | |
| Resilience | Per-route store-and-forward (SQLite) survives broker/network outages and replays in source order. Faults isolated per adapter and per sink. | |
| Network + host | Host OS class, firewall / VLAN assumptions, broker endpoints, OPC UA Server exposure + certificate trust, time-sync (NTP / plant source), Connectivity Studio admin access, and SQLite buffer-retention sizing are confirmed during architecture review — no fixed figures published. | |
EdgeConnect in the stack.
ArchitecturePanel.interactive variant.
EdgeConnect sits beside your existing SCADA / historian / MES, not in place of them — they consume canonical signals instead of vendor-specific ones. See the full cross-pillar story → /architecture.
Activate the connectivity you license.
Edition labels are illustrative until commercial packaging is approved; this section describes packaging + licensing mechanics, not pricing.
Starter
Single-protocol, single-site connectivity for a first proof of value.
Professional
Multi-protocol, multi-route connectivity for a production line or cell.
Enterprise
Full protocol set, fleet-scale routing, and the operability surfaces for multi-site operations.
Connectivity modules — FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, Siemens S7, MQTT, OPC UA Server — activate per protocol against your edition. Licensing is an RSA-signed offline license file: fully offline, no phone-home. A lapsed license blocks configuration changes only — your machines keep talking. Contact Elpis for edition feature lists and deployment-scale scoping; detailed pricing is scoped after architecture review.
Built for OT review.
Offline-first, air-gap-ready
EdgeConnect runs offline by default. The license validates locally — no phone-home. Plants on isolated OT VLANs install and run it the same way as connected plants; cloud connectivity is opt-in, not required.
Per-gateway identity + hash-chained audit
Each plant runs its own runtime with a per-gateway UUID. Every configuration change is captured with actor identity and timestamp in a tamper-evident, replay-ready audit chain.
Read the full operational trust posture → /security.
What OT architects ask.
Which protocols ship today vs. roadmap?
Today: FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 (southbound); MQTT and OPC UA Server (northbound). On the roadmap: FANUC MT-LINKi (REST), HTTP and TCP sinks, and Linux host support. See the coverage table above.
Can it run on Linux today?
Today EdgeConnect ships as a Windows service. Linux is near-term roadmap and arrives on the Edge Gateway appliance as the canonical EdgeConnect appliance. The codebase is cross-platform by design; Windows-only APIs are guarded.
Does it replace our SCADA / historian / MES?
No. EdgeConnect sits beside them and publishes canonical signals via MQTT and OPC UA Server. Your existing systems keep their jobs and consume consistent signals instead of vendor-specific ones.
What happens when the broker or network drops?
Per-route store-and-forward queues every signal at the source with its quality code preserved and replays in source order on reconnect. Three-way diagnostics surface which leg was affected during the outage.
Can one EdgeConnect serve multiple plants?
No — that's an anti-pattern. Each plant runs its own EdgeConnect with a per-gateway UUID; multi-site visibility comes from EREMOS V2 aggregating across the per-plant runtimes.
How are certificates, credentials, and secrets handled?
OPC UA certificates, broker credentials, and route secrets are deployment-specific configuration, confirmed during architecture review. The production deployment defines certificate trust, credential storage, rotation responsibility, and access boundaries before the runtime is enabled. (OPC UA Server supports Sign, SignAndEncrypt, and X.509 security modes.)
How is EdgeConnect sized for controller count and tag volume?
Sizing depends on controller count, poll frequency, tag count, route count, and the expected outage-buffer window. The architecture review scopes the host and buffering requirements against your real controller mix; no fixed figures are published.
Bring us your controller mix.
A controller list, a target broker, an existing-systems boundary — that's what we scope an architecture review against. Demos run on real protocols against real signals, not slideware.