OEE you can defend, on the cells you actually run.
Native FOCAS2, MTConnect, and Brother HTTP — plus Modbus TCP for the PLC-fronted older CNCs — across high-mix, mixed-vendor production cells. Every input — cycle time, parts count, alarm state, tool wear — collected at the controller and timestamped at the edge. Designed for environments operating under strict customer quality and audit requirements.
Live integrations on Fanuc 0i / 16i / 18i / 21i / 30i / 31i / 32i (FOCAS2) · Brother S700Xd1 (Brother HTTP) · MTConnect · Modbus TCP — and OPC UA Client and Siemens S7 for the rest of the floor. FANUC MT-LINKi REST on the roadmap. Canonical CNC vocabulary across vendors.
Stitched OEE numbers don't survive an audit.
A precision-manufacturing shop runs more product families in a week than most general CNC shops run in a month. Setup changes are constant. Tooling lifetimes are tracked to fractions of a percent. Tolerances are measured in microns. Every part has a customer attached to it, and every customer expects OEE numbers their auditor will accept.
The floor that produces those parts is rarely uniform. A Fanuc 30i from 2022 runs alongside an 18i from 2011. A Brother S700Xd1 handles one product family; a Mazak Integrex handles another. Each machine's vendor-supplied dashboard reports OEE differently. Tool-life tracking lives in one system, parts counts in another, alarm history on a third. The numbers don't reconcile. The customer asks "what's the OEE for the cell that machines our part?" — and the answer takes a week to stitch together.
The trap is treating OEE as a reporting problem — a spreadsheet that pulls from each system's quarterly export. That works until the customer audit team asks for the underlying signal data, the timestamp of every cycle, and proof that the math is consistent with the contract. Defensible OEE isn't an analytics layer bolted on after the fact; it requires the signals to be collected at the controller, normalized at the edge, and computed centrally with one consistent definition.
"Stitched OEE numbers don't survive that level of scrutiny."
How this differs from spreadsheet OEE reporting. Most precision shops already produce OEE — by exporting each system's quarterly numbers into a spreadsheet and reconciling by hand. It works until an auditor asks for the signal behind the number. A spreadsheet can show you a figure; it can't trace that figure back to the cycle that produced it, prove the math is consistent across cells, or tell you whether a reading was Good, Uncertain, or Stale when it was taken. Elpis computes OEE on canonical signals collected at the controller and timestamped at the edge — one definition, the same math across every cell and shift, traceable end to end. The spreadsheet was reporting; this is provenance.
spindle_rpm; cycle time, parts count, tool number, alarm code, and axis positions collapse the same way — the inputs already speak the same language.The signals trace back to the iron; the numbers trace back to the signals.
From EdgeConnect (edge runtime, Windows service today)
- FOCAS2 collector across every Fanuc generation — 0i, 16i, 18i, 21i, 30i, 31i, 32i. Axes, spindle, alarms, tool, production counters, programs. The protocol coverage doesn't quietly drop your oldest iron next to your newest.
- MTConnect collector — the industry-standard CNC streaming protocol; covers the newer multi-vendor machines in the cell.
- Brother HTTP collector — Brother S700Xd1 and similar models via the built-in web-monitoring interface.
- Modbus TCP collector — for older CNCs fronted by a PLC gateway, and for inspection equipment that publishes over Modbus.
- Also today: OPC UA Client and Siemens S7 for the rest of the floor. On the roadmap: FANUC MT-LINKi REST. For the full protocol matrix with semantic modes, see /edgeconnect.
- Canonical CNC vocabulary —
running,spindle_rpm,feed_rate,parts_count,cycle_time, axis positions, tool numbers and offsets, alarm codes. Same names, every vendor, every generation. - Per-tag quality codes — every signal carries a quality state (Good / Uncertain / Bad / Stale) end to end. Downstream consumers can tell a real value from a stale one — the foundation of an audit-defensible number.
- Per-route store-and-forward buffering — never lose a cycle or a parts-count update because the broker was down.
- Three-way diagnostics — source / pipeline / sink. When data quality looks off, operators see exactly where it broke.
- Connectivity Studio — web admin to add machines, configure tag maps, and run Test Connection probes before anything goes live.
EdgeConnect ships as a Windows service today; precision shops typically run it on a small box in the control cabinet. A Linux runtime is near-term roadmap, arriving on the Edge Gateway appliance for shops that prefer a turnkey DIN-rail box. The appliance is an option, not a requirement.
From EREMOS V2 (intelligence layer, consuming the canonical stream)
- OEE Segments with one consistent definition — Availability × Performance × Quality computed centrally from edge-collected signals; auditable; exportable. Configured to your shop's OEE definition, not one of ours.
- Per-cell aggregation — OEE rollups at the cell level for high-mix shops where cells matter more than individual machines.
- Tool-life tracking per tool family — wear trended across every tool in use, per cell and per product; surfaced ahead of failure.
- Cycle-time variance per machine, per shift, per part run — root-cause analysis becomes possible when every cycle is on the record.
- Persistent alarm tracking with incident grouping — alarm patterns visible across days and weeks, not just within one shift or one machine's HMI.
- Route-based customer-data sharing — publish exactly the signals a Tier-1 customer is contracted to see, for their parts only, without exposing other customers' production data or the shop's full operational picture.
- Shift reports in PDF and Excel — the reports customer-quality teams want, in the formats they accept, built from edge-collected signals.
- Multi-tenant by design — one platform, multiple sites or business units; per-customer dashboards for shops reporting to multiple Tier-1 customers, no data leakage.
What production and quality managers ask before scoping a cell.
Can we trace OEE numbers back to specific part runs?
Yes — that's the point of computing OEE on canonical signals. Every signal is timestamped at the edge and retained, and OEE Segments link back to the cycle-level data that produced them. A customer asking "show me the OEE for this batch" can be answered with the underlying signal history, not a hand-reconciled spreadsheet export. And the OEE definition stays yours — segment classification, shift schedule, and targets are configured to how your shop already defines OEE; the platform computes against your definition, not one of ours.
Which controllers do you collect from today, including our oldest Fanuc next to our newest Mazak?
Today: Fanuc over FOCAS2 across every generation (0i, 16i, 18i, 21i, 30i, 31i, 32i), the newer multi-vendor machines over MTConnect, Brother over Brother HTTP, and older CNCs fronted by a PLC over Modbus TCP. OPC UA Client and Siemens S7 cover the rest of the floor. FANUC MT-LINKi REST integration is on the roadmap. Your oldest Fanuc and your newest Mazak are handled identically — the canonical vocabulary normalizes both to the same names, so the dashboard doesn't know (or care) which vendor produced which reading. For the full protocol matrix, see /edgeconnect; the exact controller mix is confirmed during the scoping call.
Do we still have to maintain separate quality records?
The platform handles production-signal OEE inputs. Inspection-equipment data can flow in via Modbus TCP or MQTT if your quality systems publish that way; otherwise quality data stays in your existing system. Elpis sits beside your quality system, SCADA, MES, and historian — it doesn't replace them; they keep their jobs and consume canonical signals instead of vendor-specific ones. Less duplication, fewer fragmented records.
How do we handle small-batch / high-mix production where every cell is different?
OEE Segments are configured per cell against that cell's actual shift schedule and product mix. The platform doesn't impose a one-size-fits-all OEE model on a high-mix shop. Per-cell aggregation means each cell reports against the reality it runs, while the math stays consistent across the floor.
Can we share OEE data with a Tier-1 customer without exposing other production data?
Yes. Route-based architecture lets you publish exactly the data a customer is contracted to see — alarm state, cycle time, parts count for their parts only — without exposing other customers' production data or your shop's full operational picture. This is the most important commercial moment for a Tier-2 supplier serving several Tier-1 customers under different data-sharing contracts.
What happens when the network or the broker drops?
Per-route store-and-forward. Every signal queues at the source with its quality code preserved, and replays in source order when connectivity returns — no lost cycles, no missing parts counts. Three-way diagnostics (source / pipeline / sink) surface immediately during the outage, so the OT team sees exactly which leg was affected. Shops on an isolated network operate the same way; cloud connectivity is opt-in, not required.
What changes when this lands.
- OEE you can defend to corporate, customers, and auditors — one consistent definition, edge-collected signals, traceable back to the controller
- High-mix cells behave as one production system — the canonical vocabulary normalizes mixed-vendor, mixed-generation controllers
- Tool wear trended ahead of failure — tool-life telemetry across every tool in use surfaces wear before a tool fails mid-cycle, instead of discovering it after a scrapped part
- Cycle-time variance becomes diagnosable — per-machine, per-shift, per-part-run history makes root-cause analysis possible
- Customer-data sharing without exposing the whole shop — route-based architecture publishes only what each customer is contracted to see
- Cut the quarterly report-stitching — OEE numbers come from edge-collected signals, not a spreadsheet reconciled from each system's export
- Audit-ready data layer from day one — hash-chained config history, per-tag quality codes, full signal retention; OEE traces back to real signals
How precision shops typically roll this out.
Pick the cell that produces parts for your most demanding customer — or the one whose OEE numbers you're least sure of defending. EdgeConnect installed on a small Windows box in your control cabinet, polling that cell's controllers over FOCAS2 or Brother HTTP. EREMOS V2 displaying real cycle-time, parts-count, and alarm data, typically within the first few days.
Add the rest of the machines in that cell, or the cells that handle related product families. Tag maps authored together with your team — your operators know the names that matter. OEE Segments configured against your actual shift schedule and product mix.
Remaining cells onboarded. Cell-level and shop-level OEE aggregation in EREMOS V2. Per-customer dashboards if your shop reports to multiple Tier-1 customers separately. Audit-export workflows configured.
New cells, new product families, new customers — all onboard through the same architecture. FOCAS2, MTConnect, Brother HTTP, Modbus TCP, OPC UA Client, and Siemens S7 all ship today; FANUC MT-LINKi REST is on the roadmap. The OEE numbers you defend next year are computed the same way as the numbers you defend this week.
How it fits together for precision production.
Audit-ready by architecture, and nothing depends on the cloud. Per-tag quality codes propagate end to end so a downstream consumer can tell a real reading from a stale one, and every signal is timestamped at the edge and retained — the data layer is built for the audit before the auditor asks. EdgeConnect runs offline by default: license validates locally, no phone-home. If your network or broker drops, per-route store-and-forward buffers locally and replays in source order on reconnect. Shops on an isolated network install and run the platform the same way; cloud connectivity is opt-in, not required.
Per-gateway identity + hash-chained configuration audit. Each plant runs its own EdgeConnect runtime with a per-gateway UUID established at first start. Every change — a new machine added, a tag-map edit, an OEE-target change — is captured with actor identity and timestamp in a tamper-evident, replay-ready audit chain. The configuration history is as defensible as the OEE numbers it produces.
Read the full operational trust posture → /security
Looking for the same thing from another angle?
Bring us your most demanding cell.
Pick the cell whose OEE numbers you're least confident in defending. We will scope a proof of value against that cell specifically, including the audit-ready data trail. We run demos on real protocols against your real production cells — no canned data, no polished demo bench, no vague promises.