The DMT RideGuard integration connects DMT's sensor-based ride condition monitoring to Mobaro, so that when RideGuard detects an anomaly in how a ride is behaving, Mobaro automatically raises an Assignment for your maintenance team to follow up, document, and resolve. Ride condition data stops living in a separate monitoring system and becomes part of the maintenance workflow your team already uses.
Why this matters: Real-time ride data only creates value when someone can act on it. RideGuard is the early-warning layer that spots a deviation; Mobaro is where that finding becomes an assigned, tracked, documented action — so a signal turns into a fix with a clear owner and an audit trail.
Availability: DMT RideGuard is a separate product from DMT Group and requires its own subscription and installed sensors. To enable the integration in Mobaro, contact your Mobaro representative or [email protected].
What's covered:
How the integration works
DMT RideGuard uses IoT sensors installed on a ride to monitor how it behaves during operation, and AI-supported analysis to flag deviations from normal behaviour — irregular movement, vibration, or shock patterns that may warrant a closer look. That detection and analysis all happen on DMT's side.
The integration is one-directional: DMT RideGuard is the source, and Mobaro consumes its findings. When RideGuard raises an anomaly for a ride you've mapped, Mobaro creates an Assignment for the matching Location so the maintenance team can act on it.
Note: RideGuard's own monitoring dashboard and its email/SMS alerts stay on DMT's side. What the Mobaro integration adds is the maintenance workflow — turning a detected anomaly into a tracked, documented Assignment. The two are complementary.
Before you start
You'll need the following in place:
An active DMT RideGuard subscription with sensors installed on the rides you want to monitor.
A DMT RideGuard API key for your account, provided by DMT. Mobaro does not generate this.
The Mobaro Locations for those rides already created, so you have something to map RideGuard's attractions to.
Users must be Super Users or have a Role with permission to manage Configuration to set up this integration.
Connecting your organization
1. Open the integrations configuration
In the Mobaro Backend, go to Configuration and open the Integrations tab, then find DMT RideGuard.
2. Enter your DMT RideGuard API key
Paste the API key provided by DMT and save. This connects your Mobaro organization to your RideGuard account so Mobaro can see the attractions RideGuard is monitoring.
Best practice: Store the API key somewhere secure (a password manager or secrets vault) as well as in Mobaro. If it's ever rotated on the DMT side, you'll need to update it here to keep the connection live.
Mapping rides to RideGuard attractions
Once the organization is connected, tell Mobaro which ride is which by mapping each Mobaro Location to its corresponding RideGuard attraction. This is what lets Mobaro raise the Assignment against the right ride.
1. Select the RideGuard attraction for a Location
For each ride Location you want monitored, choose the matching RideGuard attraction from the list Mobaro pulls from your connected RideGuard account.
2. Choose who receives the Assignments
Set the User Group that should receive the Assignments raised for this ride — typically the maintenance or technical team responsible for it. Anomalies on this Location will land with that group.
Heads-up: Map only the Locations that have RideGuard sensors installed. A Location with no corresponding RideGuard attraction has nothing to receive anomalies from.
What happens when an anomaly is detected
Once a ride is mapped, the workflow runs on its own:
RideGuard detects a deviation from the ride's normal behaviour.
Mobaro raises an Assignment on the mapped Location in real time, routed to the User Group you set.
The team follows up on the Assignment — investigating, acting, and recording what they found and did.
The Assignment is resolved and stays on the record, giving you a documented trail from detection to action.
Best practice: Treat a RideGuard Assignment like any other maintenance finding — document what was checked and why the ride is safe to continue operating (or not). That record is what turns predictive monitoring into a defensible safety and maintenance history.
Related
Frequently asked questions
Q: Where do the RideGuard sensors and API key come from?
A: From DMT. RideGuard is a separate product with its own hardware and subscription; Mobaro connects to it using the API key DMT provides. Mobaro doesn't supply the sensors or generate the key.
Q: Is the integration two-way?
A: No. It's one-directional — RideGuard detects, Mobaro creates the Assignment. Nothing is sent from Mobaro back to RideGuard.
Q: Do I still need RideGuard's own dashboard?
A: RideGuard's monitoring views and its own alerts remain available on DMT's side. The Mobaro integration adds the maintenance workflow — the Assignment, follow-up, and documentation — on top of the detection.
Q: What if a ride doesn't have RideGuard sensors?
A: Only map Locations that have RideGuard installed. Un-instrumented rides simply aren't part of the integration and continue to rely on your scheduled checks and Checklists.
Q: Can I change which team receives the Assignments?
A: Yes. Update the User Group on the Location's mapping, and future anomalies for that ride will route to the new group.