A vibration sensor that alarms every shift gets ignored, and one that never alarms misses the bearing that fails. Agnotic Technologies builds condition monitoring software that matches each machine to the right technique, sets alarm limits that mean something and sends real faults to maintenance.
Trusted by global innovators
Condition monitoring software collects vibration, temperature, oil, ultrasound and motor current readings from machines, checks them against alarm limits and baselines, and tells maintenance which machine is changing and why. Agnotic Technologies builds condition monitoring and equipment monitoring software for plants and machine builders, from sensor ingestion to the work order.
Condition monitoring is the layer that prediction depends on. Failure forecasts and remaining useful life models sit on our predictive maintenance software page; this page is about measuring the machine well and raising the right alarm.
The standards behind it are practical ones: ISO 17359 for setting up a monitoring program, ISO 20816 for judging vibration severity, and ISO 13374 for the processing steps between a raw signal and advice to maintenance.
Decision table
The table each machine's monitoring plan is built from. Your reliability engineer confirms the choice for every asset class.
| Failure mode | Monitoring technique | Sensor | Typical alarm basis |
|---|---|---|---|
| Imbalance | Vibration analysis | Accelerometer or velocity sensor on the bearing housing | Rise at running speed against the machine's baseline and its ISO 20816 zone |
| Misalignment | Vibration analysis and thermography | Accelerometers on both sides of the coupling; thermal camera on the coupling | Rise at running speed and its harmonics, axial vibration, coupling temperature |
| Bearing wear | High-frequency vibration and ultrasound | Accelerometer with envelope analysis; ultrasonic sensor | Bearing defect frequencies in the envelope spectrum, rising ultrasound level |
| Lubrication breakdown | Oil analysis, ultrasound and temperature | Oil samples or inline oil sensors; ultrasonic sensor; RTD | Wear metals, water or viscosity outside limits; ultrasound that stays high after greasing |
| Electrical fault in motors | Motor current analysis and thermography | Current transformers; thermal camera on terminations | Sidebands around line frequency, phase imbalance, hot connections |
| Leaks of air, gas or steam | Airborne ultrasound | Ultrasonic detector or fixed sensor | Ultrasound level above the background for that location |
Bearing defect frequencies come from each bearing's geometry and shaft speed, so the asset register needs bearing part numbers and speeds, not just machine names.
Alarm limits
Four ways to set a limit, used together. The software records which basis raised each alarm, so analysts tune the right one.
Example: Overall vibration on a pump bearing moves from zone B, fine for long-term running, into zone C
Approach: Zone boundaries depend on machine type, size and mounting, so the limit set is chosen per machine class and checked by your reliability engineer
Example: A fan that has always run smoothly doubles its vibration while still inside an acceptable zone
Approach: A baseline is learned from a period of normal running in each operating state, and the alarm fires on change from that baseline
Example: Bearing temperature climbs steadily over several days
Approach: The slope over a set window is checked as well as the level, so a fast change alarms before an absolute limit is crossed
Example: A conveyor stops at a shift change and every sensor drops
Approach: Speed or load signals gate the alarms, and baselines are kept separately for each speed range
Processing chain
We follow the processing blocks of ISO 13374, so each step can be tested on its own and replaced without rebuilding the rest.
Sensor data quality
Sensor analytics fails quietly when the data is wrong. These checks run before any alarm logic does.
Challenge
Sensors drift, so a slow trend is really the sensor ageing.
Agnotic approach
We compare redundant sensors and calibration records, and flag drift that no other signal confirms.
Challenge
Gaps from wireless dropouts look like a machine that stopped.
Agnotic approach
Gaps are stored as missing, never filled with zeros, and alarms wait until enough fresh data arrives.
Challenge
Clocks disagree between gateways, PLCs and the historian.
Agnotic approach
Every reading is stamped at the source and aligned to one time base before signals are compared.
Challenge
Units and scaling differ between sensor models.
Agnotic approach
Units and scale factors are stored with each channel and converted once, at ingestion.
Challenge
A loose magnetic mount produces spikes that look like impacts.
Agnotic approach
Mounting and sensor health checks run first, and suspect channels are marked before analysis.
Sensors and sampling
The measurement decides what the software can see. We plan sensors with your reliability team before any screen is designed.
Alarm to work order
An alarm is only useful if it reaches the right person with the evidence attached.
State detection raises an alarm with the channel, the limit basis and the band that changed.
A vibration analyst or reliability engineer checks the spectrum and trend, then confirms, downgrades or closes the alarm.
A confirmed alarm creates a work request in the CMMS with the machine, the likely fault and the recommended action.
Planners schedule the job into the next suitable window and reserve the parts.
The technician records what was found, such as a worn bearing or a loose base.
Findings return to the monitoring record, so limits and fault rules improve with each repair.
Modules for the monitoring layer, from the sensor to the work request.
Wired and wireless sensors plus existing PLC and historian tags, read through OPC UA or MQTT from edge gateways.
Machines, components, bearings and measurement points, with the speeds and part numbers needed for defect frequencies.
FFT, envelope and waterfall plots beside overall trends, for analysts who need to see the signal and not only a status color.
ISO 20816 zones, baselines and rate of change limits per point, with every change to a limit logged.
Drift, gap, time and unit checks that mark suspect data before alarms run.
Handheld routes for machines without fixed sensors, merged into the same history.
Confirmed alarms posted to your CMMS with fault, priority and the evidence attached.
Gateways that send data outward only, segmented networks and signed firmware, in line with NIST guidance for operational technology.
Standards
The protocols and security guidance the ingestion and alarm layers are built on, each linked to its primary source.
OPC UA Part 1 describes OPC UA as a platform-independent standard that lets systems and devices communicate securely and reliably, using authentication, encryption and integrity checks, with both client-server and publish-subscribe models.
Source: OPC 10000-1, OPC UA Part 1: Overview and Concepts (OPC Foundation)OPC UA Part 9, Alarms and Conditions, defines alarm types that include limit, level, deviation and rate of change alarms, and the states for acknowledging, confirming and shelving an alarm.
Source: OPC 10000-9, OPC UA Part 9: Alarms and Conditions (OPC Foundation)The OASIS MQTT Version 5.0 standard defines MQTT as a client server publish/subscribe messaging transport protocol that is light weight, open and simple, suited to constrained environments such as machine to machine and Internet of Things communication.
Source: MQTT Version 5.0 (OASIS)NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, published in September 2023, gives guidance on securing systems that monitor or control physical devices, processes and events while meeting their performance, reliability and safety requirements.
Source: NIST SP 800-82 Rev. 3 (NIST CSRC)Who it is for
Teams that run, build or service rotating machines.
Pumps, fans, compressors and gearboxes monitored across lines, with one register and one alarm queue.
Monitoring built into the machines you sell, with data shared with your service team under the customer's agreement.
Analyst tools and customer reports for firms that run monitoring programs for other plants.
Remote pumping stations and blowers, where a site visit takes hours and remote diagnosis saves trips.
Scope and cost
We do not publish prices. These are the things that change the size of a build, and we price them on the scoping call.
How many machines, and how many points and techniques each one needs.
New wireless sensors, existing PLC tags or both, and how many vendors' payloads we decode.
Whether spectra are computed at the edge or raw waveforms are sent up.
Full spectrum analysis screens for your analysts, or summary health views for planners.
The maintenance and historian systems that send and receive data.
Your OT network segments, firewall rules and data diodes, if any.
We start on the machines whose failures hurt most.
We go through your critical machines, current routes and sensors, and the failures that took you by surprise.
ScopeA fixed-scope first release on a small set of machines: ingestion, data checks, alarm limits and work requests, reviewed with your analysts.
BuildMore machines and techniques, route data and the hand-off to prediction models, with support after launch.
Scale
