How do I know when a machine goes into fault?
Machines rarely choose a convenient moment to fail.
It usually happens:
During active work
Under time pressure
When delays become expensive
And by the time someone calls you, you are already reacting instead of preventing.
Fault monitoring is not about checking dashboards.
It is about knowing immediately when a machine enters an alarm or fault state.
By configuring fault notifications correctly, you:
Are informed as soon as a machine reports a fault
Reduce downtime
Improve response time
Stay in control instead of reacting too late
Below, we explain how fault monitoring works and how to ensure notifications are set up correctly in the portal.
Notification flow
Notifications are built from four components that work together:
Event definition: determines when something becomes a warning, error, or critical event
Notification preset: determines how you are informed (portal, email, SMS, etc.)
Notification role: groups notification presets for specific users or teams
Subscription: links users to specific assets using a notification role
If you are unfamiliar with these concepts, see How notifications are configured in the portal.
1. How fault monitoring works
Fault signals are not standardised across machines.
Different manufacturers use different controllers, naming conventions and data structures. There is no single universal “fault sensor” that applies to all machines.
Depending on the asset type, fault signals may appear under different paths.
Because of this variation, selecting the correct alarm signals is an important step when configuring notifications.
In many cases, fault signals include the word “alarm” in their name, such as:
engine.alarm
hydraulic_alarm
fault_alarm
machine_alarm_state
Searching for “alarm” is often the fastest way to identify relevant fault signals.
Some machines also use System Defined Events. These are predefined event definitions that represent meaningful machine states.
If such an event definition clearly indicates a fault condition, it can be used in your notification preset.
Which event definition to use in a preset
Always verify that the selected event definition represents a true fault condition and not a non-critical warning.
Using the standard preset (if available)
For some asset types, Calculus provides a standard preset named: “storingen”.
This preset contains alarm signals that are known to put the machine into a fault state.
If this preset is available for your asset type:
You do not need to create a new preset
You can simply use the existing one
This is the recommended approach, as it is based on known machine behaviour.
2. How you are notified
There is a difference between:
When a machine enters a fault state
How you are informed about it
The first part depends on the selected alarm path or System Defined Event.
The second part is controlled by a Notification Preset.
The level you select in your notification preset determines how early you want to be notified.
This depends on how the fault monitoring Event Definition is configured.
If a suitable preset already exists, you can simply use it. There is no need to create a new one.
3. Link the preset to a notification role
A notification preset by itself does not send anything.
Think of it like this:
The preset defines how notifications are sent.
The notification role defines who should receive them.
The preset must be linked to a notification role, otherwise no one will be informed, even if a machine enters a fault state.
If a suitable notification role already exists, you only need to make sure the correct preset is linked to it.
If no role exists yet, you can create one and connect it to the appropriate preset.
4. Subscribe users to machines
Even if everything else is configured correctly, notifications will only be sent when users are subscribed to specific machines.
A subscription connects:
The user
The machine (asset)
The notification role
If a user is not subscribed to a machine, they will not receive notifications for that machine, regardless of how well everything else is set up.
It’s always worth double-checking subscriptions if notifications are not coming through.
How fault notifications work – Overview
Fault notifications consist of four building blocks:
Alarm path or System Defined Event: Determines when a machine enters a fault state.
Notification preset: Determines how you are informed (portal, email, etc.).
Notification role: Bundles notification presets
Subscription: Links specific users to specific machines with a specific role.
If one of these elements is missing, notifications will not be delivered.