EREMOS V2
The multi-tenant operational-intelligence platform at the top of the Elpis stack. EREMOS V2 consumes the canonical signal stream, computes OEE you can audit, tracks every alarm as a persistent incident, and produces the reports and alerts your operations team runs on — across many sites, with per-tenant isolation.
Multi-tenant · tenant-scoped data boundaries · OEE on canonical signals · customer-controlled cloud (opt-in) · offline-capable · per-tag quality codes end to end.
Canonical signals in. Operational decisions out.
EREMOS V2 is a multi-tenant analytics platform that turns the canonical signal stream — the normalized output of EdgeConnect and the acquisition pillars — into the things operations runs on: OEE Segments, persistent alarms and incident workflows, alerts on your channels, and reports your team will actually read. It models your plant as a real industrial hierarchy and computes against the same canonical vocabulary every source already speaks.
It is the Operational Intelligence pillar of the Industrial Intelligence Ecosystem. For the capability story, see the Operational Intelligence capability. This page is the product detail — the integration model, asset model + OEE math, multi-tenancy, deployment, and licensing.
What the platform does.
A real industrial asset model
PLANT → AREA → LINE → EQUIPMENT → SUB_EQUIPMENT, with first-class Devices and Tags, units, engineering ranges, and quality codes.
OEE you can audit
Availability × Performance × Quality, computed from time-bounded Segments on edge-collected signals. The OEE definition stays yours — segments, shift schedule, and targets are configured to how your plant already defines OEE.
Persistent alarms + incidents
Inbound alarms become tracked records with open/close state and incident grouping — triage, assignment, resolution, closure, with operator notes at each step.
Alerts on your channels
Notifications routed to email, chat, and ticketing webhooks your operations team already uses.
Reports the team will read
Shift reports, OEE summaries, downtime breakdowns, tool-life trends — PDF and Excel export.
Tool-life tracking
Dedicated ingestion for tool-wear and remaining-life telemetry, so maintenance happens before failures.
Multi-tenant by design
One deployment serves many sites or business units with per-tenant isolation — tenant data is isolated by tenant boundary; no cross-tenant blending by design.
Dashboards for mixed fleets
Panes split automatically by device class — CNC, PLC, DAQ, asset tracker, meter.
What it consumes, what it exposes.
| Interface | Direction | Status | What |
|---|---|---|---|
| Canonical MQTT stream | Inbound | Available | The normalized stream from EdgeConnect (+ mDAQ, mTracker, VAS) per the canonical per-tag MQTT contract. Per-tag quality codes (Good / Uncertain / Bad / Stale) carried end to end. |
| Tool-life ingestion | Inbound | Available | Dedicated path for tool-wear / remaining-life telemetry. |
| E-IDOS streaming | Inbound | Roadmap | Oil-health alarms / dashboards / incidents into the same stack. Near-term roadmap; until it ships, E-IDOS is a standalone instrument. |
| REST API | Outbound | Available | OEE rollups + incident records for MES / ERP / BI consumers. |
| Alert webhooks | Outbound | Available | Email, chat, and ticketing webhooks. |
| Report export | Outbound | Available | Shift / OEE / downtime / tool-life reports — PDF and Excel. |
Asset model: PLANT → AREA → LINE → EQUIPMENT → SUB_EQUIPMENT, with Devices + Tags (units, engineering ranges, quality codes). OEE Segments: RUNNING, PLANNED_STOP, UNPLANNED_STOP, IDLE, SETUP — time-bounded, computed from cycle-time + parts-count signals. Quality inputs — good count, reject count, scrap reason, or a customer-approved quality source — are configured per deployment; when Quality data isn't available directly from the controller, the customer-approved source is mapped during architecture review.
Roadmap — decision-support layer. Diagnostic, Configuration, Tag Mapping, and Intelligent Alerting agents (Phase 4.5). Decision-support only — they propose actions for a human to confirm, never autonomously change state; local-LLM support is mandatory, cloud LLMs optional. (Not an inbound/outbound interface — kept out of the matrix above.)
This page carries the product-level integration model. Deployment-specific schemas, integration-contract versioning, retention, and API detail are confirmed during the architecture review.
How it runs.
| Deployment | In your data center, a private cloud, or as a managed service. Multi-tenant by design — one deployment, many sites / business units. |
| Connectivity | Consumes the canonical stream over standard MQTT (any compliant broker); the platform does not require Elpis to provide the broker. Cloud connectivity is opt-in, not required. |
| Tenancy + isolation | Per-tenant data isolation — tenant-scoped data boundaries; no cross-tenant blending by design. |
| Identity + access | RBAC, SSO / identity integration, user roles, tenant boundaries, incident ownership, and service-account responsibilities are confirmed during architecture review. |
| Network + host | Host / runtime class, database + storage sizing, broker endpoints, and certificate handling are confirmed during architecture review against tenant count, site count, and tag volume. No fixed figures published. |
| Data retention + backup | Retention windows for operational, report, and alarm + incident history, plus backup / restore and disaster-recovery expectations, are scoped during architecture review against site count, tag volume, and customer policy. |
| API + webhook security | API authentication, the webhook security model (delivery / retry behavior), payload-schema + integration-contract versioning, and integration ownership are confirmed during architecture review. |
| Versioning + support | Released as a versioned platform; configuration changes are audited. Support boundary spans EREMOS V2, its ingestion of the canonical stream, and the EdgeConnect integration. |
EREMOS V2 in the stack.
ArchitecturePanel.interactive variant.
EREMOS V2 aggregates across per-plant EdgeConnect runtimes; multi-site visibility comes from the platform, not from one runtime spanning plants. See the full cross-pillar story → /architecture.
License the tenants, sites, and capabilities you operate.
Edition labels are illustrative until commercial packaging is approved; this section describes packaging + licensing mechanics, not pricing.
Starter
Single-tenant, single-site operational intelligence.
Professional
Multi-tenant analytics for a plant or a small fleet.
Enterprise
Fleet-scale multi-tenant operations across many sites + business units.
EREMOS V2 deploys in your data center, a private cloud, or as a managed service. Tenancy and site scale are licensed per edition. Contact Elpis for edition feature lists and deployment-scale scoping; detailed pricing is scoped after architecture review.
Built for OT review.
Multi-tenant isolation, customer-controlled data
One deployment serves many tenants with tenant-scoped data boundaries, role separation, and customer-controlled routing — no cross-tenant blending by design. Cloud connectivity is opt-in, not required; sensitive plant data stays where you choose.
Auditable + role-separated
Configuration changes are audited; role separation is supported. AI features, when they ship, propose actions for humans to confirm — they never autonomously alter the data path (local-LLM-capable; cloud LLMs optional).
Read the full operational trust posture → /security.
What technical evaluators ask.
What does EREMOS V2 consume, and from where?
The canonical MQTT signal stream — the normalized output of EdgeConnect and the acquisition pillars (mDAQ, mTracker, VAS) — per the canonical per-tag MQTT contract, with per-tag quality codes carried end to end. E-IDOS streaming into EREMOS V2 is near-term roadmap; until it ships, E-IDOS is a standalone oil-health instrument.
How is OEE computed, and can we defend it?
OEE Segments (RUNNING, PLANNED_STOP, UNPLANNED_STOP, IDLE, SETUP) are computed from edge-collected cycle-time and parts-count signals, timestamped at the edge and retained. The OEE definition stays yours — segment classification, shift schedule, and targets are configured to how your plant already defines OEE; the platform computes against your definition, not one of ours.
How does multi-tenancy isolate our data?
One deployment serves many sites or business units with per-tenant data isolation — tenant-scoped data boundaries; no cross-tenant blending by design. Role separation is supported. Tenant and site scale are confirmed during architecture review.
Can we run it on-prem / air-gapped, or must it be cloud?
EREMOS V2 deploys in your data center, a private cloud, or as a managed service. Cloud connectivity is opt-in, not required — sensitive plant data stays on premise; filtered rollups flow out only on your terms.
How do downstream systems (MES / ERP / BI) consume it?
Via the REST API (OEE rollups + incident records) and alert webhooks (email / chat / ticketing). Reports export to PDF and Excel. EREMOS V2 sits beside your existing systems — they consume its rollups, it doesn't replace them.
What AI is in it, and does it change anything automatically?
AI operations agents (Diagnostic, Configuration, Tag Mapping, Intelligent Alerting) are on the roadmap (Phase 4.5). They are decision-support: they propose actions for a human to confirm and never autonomously alter the data path. Local-LLM support is mandatory; cloud LLMs are optional.
How is EREMOS V2 sized for sites and tag volume?
Sizing depends on tenant count, site count, tag volume, publish frequency, and retention window. The architecture review scopes the host, database, and storage requirements against your real fleet; no fixed figures are published.
How long is operational history retained?
Retention depends on tenant count, site count, tag volume, report history, and customer policy. Retention windows and archive / export requirements are scoped during architecture review.
How are roles and approvals handled?
RBAC with tenant admins, incident ownership, and audit permissions; SSO / identity integration is confirmed during architecture review. Role separation is supported, and configuration changes are audited.
Bring us your fleet and your OEE definition.
A site list, a tenancy model, the canonical stream from your floor, and the OEE definition you already run — that's what we scope an architecture review against. Demos run on real signals, not slideware.