VX-Olympus Worked
Let’s start with that, because it matters. VX-Olympus wasn’t a failed product. It connected devices. It ran rule chains. It managed firmware. It handled multi-tenant deployments, white-labeling, and RBAC. Hundreds of customers deployed it. Monitoring programs ran on it for years.
We didn’t rebuild because VX-Olympus was broken.
We rebuilt because five years of deployments taught us what device management alone cannot do — and we reached the point where we could no longer ignore the gap between what the platform provided and what operations teams actually needed.
What We Built VX-Olympus To Do
VX-Olympus was built as an application enablement platform. The design principle: give system integrators and OEM partners the infrastructure to build connected solutions — protocol support, device management, rule engine, dashboards, white-labeling — without building the infrastructure themselves.
It did that well. Protocol support covered MQTT, HTTP, OPC-UA, LoRaWAN, CoAP, Modbus, Kafka. The rule chain engine was flexible enough to handle complex logic. The white-label system let partners deploy under their own brand without platform development.
The platform was a device-first architecture. Device connects → data ingests → rules evaluate → actions fire → dashboard displays. That’s a complete, functional loop.
What it wasn’t: a model of the physical operation.
The Gap We Kept Seeing
Every VX-Olympus deployment went through the same progression.
Phase 1: Connect devices. Map telemetry to dashboards. Configure alerts. Ship. Customer is satisfied — they can see their equipment.
Phase 2 (3–6 months in): The customer starts asking questions the platform can’t answer. Not because the data isn’t there. Because the data lives in the wrong shape.
The questions that operations teams actually need answered don’t look like “what is asset 4712’s current temperature?” They look like:
- “Which of my compressors are showing degradation patterns I should act on this week?”
- “What’s the maintenance cost history on the assets that have been in alert state three or more times in the past year?”
- “If my top-performing technician’s service history is different from my average technician’s service history on the same asset types, what’s the gap?”
- “The FDA auditor arrives Friday. Show me the complete cold chain compliance record for the past 90 days.”
Device management doesn’t answer those questions. A time-series dashboard doesn’t answer those questions. You need a platform where device telemetry, asset identity, maintenance history, alarm history, and spatial context all live in a unified model — and where intelligence layers can query across all of them.
What We Learned From Five Years of Customers
Five years of deployments produced a consistent pattern of customer requests that VX-Olympus couldn’t fulfill without significant custom development on top of the platform:
“We need to know the maintenance history on the asset, not just the device.”
VX-Olympus understood devices. A device had a device ID, credentials, protocol configuration, and telemetry history. It didn’t understand assets — the physical objects devices were attached to. An asset has identity (manufacturer, model, serial number, installation date), service history (every work order ever performed), baseline behavior (what “normal” looks like for this specific unit), and relationships to other assets (this motor belongs to this machine, which is on this production line).
When a customer wanted to see maintenance cost history alongside sensor data, or wanted to correlate failure patterns with asset age and service history, VX-Olympus had no model for it. That data had to live somewhere else — usually a spreadsheet or a separate CMMS — and someone had to manually correlate it.
“We need the alarm system and the work order system to be the same thing.”
Alert fires in VX-Olympus. Someone sees it. They open the CMMS — separate system — and create a work order manually. They type in the alert condition, the asset name, the current readings. All of this information was already in the platform. None of it transferred automatically.
This wasn’t a minor friction point. It was a process that broke regularly. Alerts got missed. Work orders got created without context. The technician arriving on-site didn’t have the full picture of what triggered the dispatch.
“We need to know where our assets are.”
Not the GPS coordinates of devices. The operational location context — which building, which zone, which production line, which shift. VX-Olympus had no spatial model. Adding location required separate RTLS infrastructure and custom integration work for every deployment.
“We need AI to help our operators answer questions.”
This started as a future-looking request. By 2024 it was a present-tense request, and by 2025 it was a competitive requirement. AI queries against operational data — “ask a question, get an answer from your actual data” — require an architecture where the AI can access a structured model of the physical operation. Device telemetry alone isn’t enough context. You need asset identity, location, maintenance history, and alarm history together.
The Architectural Decision
The decision to rebuild rather than extend wasn’t taken lightly. VX-Olympus had hundreds of active deployments. Rebuilding meant migration work for existing customers and a period where engineering resources went into the new platform rather than feature additions to the existing one.
The reason we chose to rebuild rather than extend: the gap wasn’t features. It was architecture.
Adding an asset model to VX-Olympus would have meant a separate asset database, synchronized with the device telemetry database via event bus or periodic sync. Adding CMMS would have meant a separate work order system, integrated via API. Adding RTLS would have meant a separate location system, integrated via API.
The result would have been five separate systems with sync delays and API failures — the exact architecture we were trying to move away from. The sync delays, data model mismatches, and API failures that VX-Olympus customers experienced when they tried to integrate external CMMS or analytics systems — those problems don’t go away by building more integrations. They go away by using one data model.
What Changed in the Rebuild
The Data Model Inversion
VX-Olympus was device-centric — assets were associated with devices.
ArgusIQ is asset-centric. The primary entity is the physical asset — the equipment, infrastructure, or tracked object. Devices are attached to assets and contribute telemetry to the asset’s data record. An asset can have multiple contributing devices. A device can contribute to multiple asset fields.
This inversion changes what the platform can answer. In a device-centric model, you can ask “what is device 4712’s current temperature?” In an asset-centric model, you can query temperature, baseline, and deviation in a single question.
Intelligence as a Core Layer
VX-Olympus’s rule engine evaluated device telemetry against configured thresholds. ArgusIQ’s Alarm Engine evaluates asset conditions — which includes telemetry, but also baseline deviation, health score, maintenance recency, and location context.
Ask Argus — the natural language interface — can only work because the underlying data model is asset-centric and contextually complete. An LLM generating answers from device telemetry alone would produce answers with no operational context. Ask Argus generates answers because the context already exists in the model: every asset has identity, current state, baseline statistics, health score, maintenance history, alarm history, and location.
Maintenance Integration, Not Maintenance Addition
In VX-Olympus, maintenance workflows required external CMMS integration — separate system, separate sync processes. In ArgusIQ, CMMS is a module operating on the same data model. When an alert fires and creates a work order, the work order links directly to alert, asset, and sensor readings — not because of integration, but because they’re all in the same database.
The Migration Path
Existing VX-Olympus customers migrating to ArgusIQ go through a structured transition:
Device provisioning in VX-Olympus carries forward — device credentials, protocol configurations, and decoder functions migrate to IoT Hub. The new work is building the asset model: creating asset records, populating asset identity fields, and configuring health score components. For customers with existing CMMS data, historical maintenance records can be imported.
The transition takes 3–6 months depending on deployment scale. Customers who complete it get the operational intelligence capabilities that VX-Olympus never provided — not as add-ons, but as the baseline.
What This Means for New Deployments
New customers deploying on ArgusIQ don’t experience the Phase 1/Phase 2 gap that VX-Olympus customers experienced. They start with the asset-centric model. Device telemetry contributes to asset records from day one. The maintenance history builds from day one. The baseline statistics develop from day one.
Six months into an ArgusIQ deployment, a customer has health scores, maintenance correlation, and AI answering questions with full context.
The Honest Summary
VX-Olympus did what it was designed to do: connect devices, manage them at scale, and give operations teams visibility they didn’t have before.
What it wasn’t designed to do: turn that device data into operational intelligence. That required a different architecture — one that didn’t exist in 2020 when VX-Olympus was built, and one that required a ground-up rebuild rather than an extension.
ArgusIQ is that rebuild. Not a VX-Olympus with more features. A different platform built on a different premise: that operational intelligence requires a complete model of physical operations, not a collection of device data streams.
Talk to our team about migrating from VX-Olympus to ArgusIQ.