Ship connected equipment. Diagnose remotely. Cut truck rolls.
EdgeConnect deploys with your machine; EREMOS V2 aggregates your installed base. Native FOCAS2, MTConnect, Brother HTTP, and Modbus TCP — plus OPC UA Client and Siemens S7 for whatever else you spec. Your customer controls their data; you get the service visibility you need.
Connected on FOCAS2 · MTConnect · Brother HTTP · Modbus TCP · OPC UA Client · Siemens S7 — with an OPC UA Server sink for customer-side SCADA. FANUC MT-LINKi REST on the roadmap. Customer-controlled. OEM-aware. Field-ready.
Your service organization is blind until a customer calls.
Your service organization is blind until a customer calls. By the time the call comes, the machine has already been down. Your engineer arrives at the customer's site — sometimes hours later, sometimes overnight — to diagnose a fault that, on a connected machine, could have been identified before the customer noticed.
Every dispatch costs in engineer time, travel, parts inventory, and customer goodwill. Every dispatch that turns out to be a remote-diagnosable issue is pure margin loss. Meanwhile your product engineering team is starved for field data — they're improving the next-generation machine on six-month-old anecdotes from the service team's whiteboard.
The instinct is to build a connected-equipment platform yourself: an embedded gateway, a cloud back-end, a dashboard, a ticketing integration. Then you meet the customer's IT department. Some customers won't allow always-on connectivity. Some require complete data sovereignty. Some don't want your machine on their network at all. The connectivity story that was supposed to differentiate your equipment becomes the friction that kills its sale.
"Your monitoring platform becomes the reason the deal stalls."
How this differs from closed connected-equipment platforms. The usual connected-equipment model is a closed loop: the machine phones home to the OEM's own cloud, the OEM holds the telemetry, and the customer is asked to trust a black box on their network. That model is exactly what stalls at the customer's IT department. Elpis inverts it. EdgeConnect runs locally on the equipment, and the customer configures — by route — which signals flow back to you and which stay on their floor. Customer-controlled telemetry is the differentiator. You get the service visibility you need without asking the customer to surrender data sovereignty, and the connectivity story becomes a reason to buy the machine instead of a reason to hesitate. The customer's own systems stay where they are; Elpis layers into the relationship instead of overriding it.
For Your Machine (EdgeConnect, embedded with your equipment)
- Native protocol coverage for whatever controllers you spec — FOCAS2 (every Fanuc generation), MTConnect, Brother HTTP, Modbus TCP, plus OPC UA Client and Siemens S7. Mix and match across product lines. On the roadmap: FANUC MT-LINKi REST. For the full protocol matrix with semantic modes, see /edgeconnect.
- One tag map, deployed across your installed base — authored once for your machine, replicated across every unit you ship; tag-map updates flow to existing machines via standard configuration deployment.
- Route-based data control — the customer configures which signals route where: service telemetry to the OEM, operational data stays local, nothing leaves the customer's network without an explicit route.
- OPC UA Server sink (optional) — exposes machine data natively to the customer's own SCADA / MES if they want it. Beside, not replacing. Co-existence by design.
- Per-route store-and-forward — a customer-network outage doesn't lose machine telemetry; signals buffer locally and replay in source order on reconnect.
- Per-gateway UUID + customer/site binding — established at first start. Each shipped unit carries permanent identity for warranty, SLA, and service-history attribution.
- Hash-chained audit log — a tamper-evident record of every configuration change on the machine; useful for warranty claims and regulated-industry deployments.
- Offline-capable — no cloud, internet, or always-on connectivity required for the machine to operate.
EdgeConnect ships as a Windows service today; embed it on a small box inside your equipment, or run it on a customer-supplied box adjacent to the machine. A Linux runtime is near-term roadmap, arriving on the Edge Gateway appliance for OEMs who prefer a turnkey embedded module. The appliance is an option, not a requirement.
For Your Service Organization (EREMOS V2, aggregating the installed base)
- Installed-base view — every shipped machine in one operational dashboard, organized by customer site.
- Per-customer fleet drill-down — a specific customer's machines, their alarm history, their service patterns.
- Persistent alarm tracking with incident grouping — proactive identification of fault patterns across the installed base, not isolated tickets.
- Tool-life and consumable telemetry — flag wear ahead of failure to drive proactive service campaigns.
- Multi-tenant by design — your installed-base view is your tenant; your customer's own view (if they run EREMOS V2 themselves) is theirs. No data leakage between tenants.
- Service-history reporting — exportable per-customer or per-machine for SLA reviews, warranty claims, and contract renewals.
What OEM service and product teams ask before scoping.
Can our customers say no to monitoring?
Yes — and that's the point. The customer controls the route configuration; if they don't want service telemetry flowing to you, none does. The platform is designed to respect customer choice, not coerce it, because trust is the durable commercial position. An OEM that respects data sovereignty becomes the vendor the customer's IT department signs off on, not the one they block.
Can our customer use the same platform for their own operational view?
Yes. The customer can run EREMOS V2 themselves in their own tenant, build their own dashboards, and route some of the same machine signals to both their view and yours. One platform, two tenants, separate data control — co-existence by design. It also sits beside their existing SCADA, MES, or historian; the optional OPC UA Server sink exposes machine data to those systems rather than replacing them.
What about customers with strict no-cloud or air-gap policies?
Supported. EdgeConnect runs offline. Telemetry exports on the customer's schedule via approved channels — scheduled or manual exports — instead of always-on connections, so strict data-sovereignty customers stay addressable. The machine itself never needs connectivity to operate.
How do we handle a customer who buys the machine and then refuses connectivity?
The machine works either way. Connectivity is a layered capability, not a precondition for operation. If the customer changes their mind later, connectivity activates through a configuration change — no service call required.
Can we white-label the operator-facing parts, and how does an OEM partnership work?
Co-branding options are available for OEM partnerships at appropriate scale, and OEM licensing is structured differently from per-plant deployments — we scope it against your product economics in a partner conversation rather than publishing it here. Bring your installed-base size, the controllers you spec, and your packaging strategy to an OEM scoping call and we'll scope the licensing and any white-label path together.
What about feeding service data back to product engineering?
The installed-base view includes alarm patterns, run hours, and operational telemetry your product-engineering team can analyze for next-generation decisions — so the field-data feedback loop runs on continuous installed-base data instead of six-month-old service anecdotes. The same per-gateway identity that supports warranty and service-hours billing keeps that field data attributable per machine and per customer.
What changes when OEMs deploy.
- Cut truck rolls on remote-diagnosable issues — the service team identifies the problem before the customer calls; some dispatches become phone-resolved
- Diagnose before the customer notices — alarm patterns trigger proactive service campaigns instead of reactive emergency dispatches
- Field data flows continuously to product engineering — next-generation decisions backed by real installed-base data, not six-month-old service anecdotes
- Warranty disputes resolve on data, not memory — service history, run hours, and operational telemetry available per machine
- Connected equipment becomes a differentiated SKU — your RFP responses can promise connectivity that doesn't violate the customer's IT policy
- Customer relationships strengthen, not weaken — the platform respects customer data sovereignty; you become the OEM that didn't try to force always-on access
How it fits together for connected equipment.
Customer-controlled, offline by default. EdgeConnect runs offline — the license validates locally, with no phone-home — and the customer's route configuration, not the OEM's, gates what telemetry flows back. If the customer network drops, per-route store-and-forward buffers locally and replays in source order on reconnect. Cloud connectivity is opt-in, never required for the machine to run.
Per-machine identity + hash-chained configuration audit. Each shipped machine runs its own EdgeConnect with a per-gateway UUID and customer/site binding established at installation — there is no single OEM-side runtime reaching into customer plants. Every configuration change is captured with actor identity and timestamp in a tamper-evident, replay-ready audit chain, which is what makes warranty claims and regulated-industry deployments defensible on data rather than memory.
Read the full operational trust posture → /security
Looking for the same thing from another angle?
Bring us your installed base.
Tell us about your equipment — how many machines you've shipped, what controllers you spec, what your service organization needs to see. We'll scope an embedded deployment for your next product release and a path to retrofitting existing units as customers opt in. No multi-year platform commitment required to prove the connectivity stack works.