Detect failure signatures before downtime — not after.

Does this replace our CMMS?

No. EREMOS V2's incident workflows are operational — alarm triage, assigned-to, resolution. Your CMMS stays as the system of record for work-order management, spare-parts inventory, maintenance scheduling, and labor tracking. EREMOS V2 publishes incident records that your CMMS can ingest via API or webhook — the maintenance team works in the CMMS they already use, with a better-triggered incident stream feeding it.

What does "predictive" actually mean here?

Threshold-based detection on real condition signatures — vibration spectra crossing failure-mode thresholds, particle contamination counts exceeding ISO 4406 cleanliness limits, water saturation passing the equipment-class limit. The maintenance team defines the thresholds; the platform monitors continuously and triggers when the signature crosses. This is not "AI predicts what will fail" — it's "the asset is telling you the bearing is degrading, here's the threshold you set, here's the alert." Honest framing matters: predictive vs reactive is a workflow improvement, not a machine-learning claim.

How do we onboard an AMC provider into this?

Customer-controlled routing. You define which assets the AMC provider sees signals from, which thresholds they can configure, and which incident workflows they can act on. Per-tenant isolation in EREMOS V2 means the AMC provider sees only what you authorize — not your full operations. The AMC provider deploys VAS + E-IDOS on the assets under their contract, signals route into a scope you control, and the AMC team uses the same EREMOS V2 incident workflows your in-house team would.

What if our hydraulic system uses sensors that aren't HYDAC?

E-IDOS is sensor-agnostic on the contamination input side — HYDAC, Parker, MP Filter, and Argo-Hytos are all supported today. The hardware reads the sensor; the analytics happen in E-IDOS regardless of the sensor brand. If you have a sensor that isn't on the supported list, scope that with engineering during the architecture review — the integration pattern is well-understood and additions are common. Where existing sensors don't support the failure modes you need to detect, the scoping call covers a sensor-fitness review — adding accelerometers on critical bearings, or installing an in-line particle counter on a hydraulic return-line, is a small mechanical project we can scope alongside the analytics deployment.

Can we run this on assets in plants without internet?

Yes. Same offline-first posture as the rest of the platform. VAS runs on mDAQ hardware with optional battery backup; condition data buffers locally and forwards when connectivity returns. E-IDOS is a standalone appliance — its offline capability is built into the appliance itself: the built-in HMI and on-board thermal printer mean the maintenance technician can read condition data and print a report without any network at all, and the BLE Android app + email reports cover signal delivery patterns when network is partially available. Plants on isolated OT VLANs install both products the same way as plants with internet.

How should we roll this out — bottom-up by asset, or top-down by plant?

Bottom-up by asset, sized to criticality. Start with the assets where unscheduled downtime hurts most — the critical pump, the high-utilization gearbox, the hydraulic system that takes a production line down when it loses cleanliness. Instrument those first, build the threshold + incident workflow discipline on a small number of assets the team trusts, then scale out. Top-down rollouts (instrument every asset in the plant at once) usually generate alert noise the maintenance team learns to ignore — and that's the failure mode that kills predictive programs.