Skip to content
CAPABILITY · CONNECTIVITY & EDGE

One operational data layer for every controller on your floor — without ripping out what you already have.

"How do I get my controllers' data into one operational view, on-premise and offline-capable?"

PRODUCTS IN THIS PILLAR

One capability, two deployment surfaces.

This pillar combines the software runtime that understands industrial protocols (EdgeConnect) with the appliance that deploys and hosts industrial connectivity in the field (Edge Gateway).

EDGE RUNTIME

EdgeConnect — Protocol-agnostic industrial data layer

One service that polls every controller on your floor over its native protocol — FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, S7. Normalizes signals into a canonical vocabulary. Publishes to MQTT, OPC UA Server, or HTTP/TCP. Store-and-forward buffering means no lost cycles during broker outages. Three-way diagnostics show source / pipeline / sink health. Hash-chained configuration audit. Per-tag quality codes. Runs Windows today; Linux on the roadmap (deploys then on Edge Gateway). FANUC MT-LINKi REST integration is on the roadmap.

SOFTWARE · WINDOWS SERVICE TODAY · LINUX ROADMAP

See the EdgeConnect product page →

INDUSTRIAL APPLIANCE

Edge Gateway — Ruggedized PLC-to-network appliance

Ruggedized industrial gateway running embedded Linux. Built-in Modbus TCP server/client, 4G/Wi-Fi/Ethernet, web-configurable, USB firmware updates. 256 MB RAM / 2 GB Flash, 24 V DC, 200 × 150 × 75 mm rugged enclosure. Dual strategic identity: today it ships as a standalone PLC-to-network gateway with built-in Modbus TCP and cellular publish. Tomorrow — once EdgeConnect Linux ships — it becomes the canonical EdgeConnect appliance. Buy it today for what it does today; it grows into the broader platform path on the same hardware.

HARDWARE APPLIANCE · EMBEDDED LINUX · 24 V DC · RUGGEDIZED

See the Edge Gateway product page →

WHAT THIS PILLAR ELIMINATES FROM YOUR BOM

Connectivity & Edge consolidates what would otherwise be a stack of separate products.

  • Per-vendor monitoring tools (one for Fanuc, one for Brother, one for Mazak — each with its own dashboard and reporting cadence)
  • A separate industrial PC for hosting edge software
  • A separate Linux gateway for protocol bridging
  • A separate cellular modem for remote sites without wired connectivity
  • The need to host EdgeConnect on customer-owned Windows infrastructure (Edge Gateway, when EdgeConnect Linux ships, eliminates this)
  • In-house engineering effort to maintain custom protocol drivers across firmware updates
  • The per-machine custom-mapping tax that drifts when controllers change
WHO IT'S FOR · WHERE IT DEPLOYS

Buyers

  • OT Architect / SCADA engineer — designs the integration; owns protocol decisions
  • Plant engineer (retrofit / greenfield) — sizes the deployment; selects Edge Gateway hardware
  • Industrial IT lead — evaluates the edge runtime against existing SCADA / historian / MES

Industries

  • Manufacturing — discrete (CNC, machining, automotive parts)
  • Manufacturing — process (flow / temperature / pressure)
  • Oil & Gas (pipeline, surface + downhole hydraulics)
  • Power & Energy (substation + generation telemetry)
  • Water & Utilities (pump-station, flow + pressure)
  • OEM machine monitoring (service-hours, warranty, fleet)

Deployment footprint

  • Operating across India and the Middle East
  • Offline-capable; air-gapped factories are first-class
  • Multi-site: one Edge Gateway + one Edge runtime per plant; per-gateway identity from first start
WHERE IT FITS

Connectivity & Edge is the connectivity layer of the Industrial Intelligence Stack.

How this differs from a general-purpose IoT gateway. EdgeConnect + Edge Gateway normalize signals to canonical CNC vocabulary at the edge — every signal arrives at every sink in the same shape, regardless of which controller produced it. Most IoT gateways pass protocol bytes through to the cloud, which forces every downstream sink to re-interpret the same vendor encoding. Per-route store-and-forward survives connectivity gaps without losing source ordering. Three-way diagnostics (source / pipeline / sink) tell you immediately where the data path broke.

Pillars 2–4 (Data Acquisition, Asset Intelligence, Condition Monitoring) capture field signals from sensors, mobile assets, and condition-monitoring instruments. Pillar 1 (Connectivity & Edge) integrates those signals — plus everything coming from existing PLCs and controllers — into one canonical data layer. From there, signals flow to Pillar 5 (Operational Intelligence) for OEE / alarms / reports, to external SCADA / MES / cloud via OPC UA Server / MQTT / HTTP, or stay local for offline operation.

Floor controllers CNC · PLC · meters EdgeConnect · Edge Gateway canonical vocabulary · store-and-forward three-way diagnostics MQTT · OPC UA Server publish once, fan out EREMOS V2 + SCADA / MES / cloud
Pillar 1 is the data-layer foundation. See the full Industrial Intelligence Stack → /architecture
TRUST POSTURE

Offline-first. No phone-home.

EdgeConnect and Edge Gateway both run 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. Hash-chained configuration audit captures every change to the gateway with actor identity and timestamp — tamper-evident, replay-ready. Per-tag quality codes propagate end-to-end so downstream consumers can distinguish a real signal from a stale one.

Read the full operational trust posture → /security

NEXT STEP

Talk to an engineer about your specific controller mix.

Whether you're scoping a retrofit, a greenfield install, or a multi-site standardization — bring us the controller mix and we'll scope the deployment shape. Demos run on real protocols against real signals, not slideware.