Turn every reading and test into reliability evidence
Record operating hours, demands and proof tests against the tag, and let a failed test become a failure event
Readings and failures on one record
A counter reading, a proof test and a vibration alarm are three ways of learning the same thing about one installed unit. Magnus Reactor models them as surveillance periods, test records and detection methods on the tag, so the operating time you accumulate and the failures you detect sit on one record and divide cleanly into a failure rate.
Each period records operating hours from a counter or an estimate, and counts periodic-test demands and operational demands as they happen. Each test records what was tested, against which acceptance criterion, and whether it passed. A failed test raises a failure event with its detection method already set, and the corrective work order follows from it.
See corrective work ordersBenefits
Record operating time you can trust
Log operating hours per surveillance period from a counter reading or a documented estimate, with the source recorded, so every reliability figure rests on a known exposure time rather than calendar days.
Prove each test against its criterion
Capture the test type, the function or leakage criterion, the acceptance criterion and the result for every periodic and proof test, and let the record increment the demand counters for you.
Compute KPIs on exposure, not guesses
Failure rate with confidence intervals, MTTF and availability are computed on read from recorded operating time and failure events, and every figure breaks down to the next level of the taxonomy.
Connect sensors to the same record
Continuous condition monitoring is a coded detection method, so a reading from a sensor is recorded the same way as a reading from a technician: against the installed unit, in its surveillance period, feeding the same KPIs.
Surveillance capabilities
Record operating time per installed unit
Open a surveillance period for each installed unit and record its operating hours as a counter reading or an estimate, with the source kept on the reading. The period is bound to the installed unit, not just the tag, so a change-out opens a fresh period and the equipment class decides whether replacement resets the reliability clock. Periods that end without a failure are never discarded. They are censored data and carry real information about how long the unit ran without fault.
- Counter reading or estimate, source recorded
- One period per installed unit
- Zero-failure periods retained as censored data
- Reset behavior set per equipment class
Count demands as they happen
Safety and control equipment fails on demand more often than it fails while running, so each surveillance period carries two counters alongside its operating hours: periodic-test demands and operational demands. Every recorded test increments the periodic-test counter automatically, and operational demands are recorded when a shutdown valve, relief valve or fire pump is called on for real. With demands counted, on-demand failure modes get a proper denominator and the failure fraction is reported for what it is.
- Periodic-test demands incremented by each test record
- Operational demands recorded per period
- On-demand failure modes given their own denominator
Capture proof tests with their acceptance criteria
Record each periodic and proof test against the installed unit: when it was tested, the test type, whether the criterion is a function or a leakage check, the acceptance criterion drawn from the safety-instrumented-function reference, and whether the unit passed. Because a test is a demand, the record updates the period's counters as it is saved. When the unit fails, the same record raises a failure event with the detection method already set, so nothing is reported twice and nothing is lost between the test sheet and the register.
- Tested at, test type, criterion kind, acceptance criterion, passed
- Counters updated on save
- Failed test raises the failure event
Code how each failure was found
Detection method is a coded field on every failure event, drawn from a seeded list rather than a free-text box: periodic maintenance, functional testing, inspection, periodic condition monitoring, continuous condition monitoring, production interference, casual observation, corrective maintenance and on demand, among others. The method is derived from the work that found the fault whenever it can be, so a fault found on a PM task or a proof test is coded without the technician choosing anything. Filter your failures by how they were detected and see which surveillance actually catches faults.
- Seeded code list, extendable per organization
- Derived from the PM task or test that found the fault
- Continuous condition monitoring is a first-class method
Feed connected readings into the record
A sensor is another source of the same three facts: how long the unit has run, how many times it has been demanded, and whether it is now in a failed state. Sensor integration points deliver counter readings into the surveillance period and demand counts into the demand counters, and when a person confirms a failed state the monitoring system reported, the failure event is raised with continuous condition monitoring as its detection method. The result lands where a technician's own reading would, on the installed unit under its tag, and feeds the same corrective work order and the same KPIs.
- Counter readings into surveillance periods
- Reported failed states, confirmed by a person, into coded failure events
- Same record, same work order, same KPIs
From reading to record
Every step writes to the tag and its installed unit, so the KPI at the end is computed from exactly what was recorded along the way.
Open a surveillance period
Start a period for the installed unit under its tag. The period follows the unit, not the tag, so it ends when the unit is changed out.
Record operating hours and demands
Log operating hours from a counter reading or an estimate, with the source noted, and count periodic-test demands and operational demands as they occur.
Source of hours recorded
Record the periodic or proof test
Capture tested at, test type, function or leakage criterion, acceptance criterion and the result. Saving the test increments the period's demand counter.
Raise the failure event
A failed test creates the failure event on the same unit with the detection method already set. Severity and consequence classes are left for whoever knows to complete.
Test result recorded as failed
Plan the corrective work order
The failure event links to its corrective work order. The event moves to corrected when the work completes, and closes only when a different person verifies the coding.
Corrective work order linked to the event
Read the reliability KPIs
Failure rate, MTTF and availability come straight from the periods and events you recorded, with the confidence intervals the data supports and a breakdown to the next taxonomy level.
Part of one record
Readings, tests and sensor alarms land on the same installed unit that carries its work orders, its change-out history and its people.
Work Orders
Turn a failed test into corrective work
A failed test record opens the failure event; Work Orders raises the corrective job against it, and completing that job moves the event to corrected without a second entry.
Asset Management
Follow the installed unit through change-outs
Each surveillance period belongs to the installed unit at a tag. A change-out in the Asset Management installation history closes one period and opens the next, and the equipment class says whether the reliability clock resets.
Collaboration
Name who recorded every reading
Operating hours, test results and failure events carry who recorded them and when. Roles in Collaboration decide who may record them, so a reliability engineer can trace any figure back to a person.
Test results, not time series
Magnus Reactor models what a reliability engineer needs from surveillance: operating time, demands, test outcomes and how each failure was detected, coded so they can be compared across plants and sites. It does not become a historian. Sensor time series stay in the monitoring system that is built for them, and integration points bring across the facts that change the record: a counter value, a demand, a confirmed failed state.
This keeps the reliability record small, coded and losslessly derivable, in line with ISO 14224, and it keeps your existing condition-monitoring tools where they are. The KPI you read at the end is computed from records a person or a sensor actually wrote, never from a stored number nobody can trace.
See how access and tenancy are enforced