How Device Self-Tests Detect Failures

How medical equipment checks its own hardware, sensors, memory, communication paths, and safety systems during startup and operation

Medical equipment often checks itself before the user ever presses a clinical function.

Published August 28, 2026 · Revised September 5, 2026

Back to Biomed Basics

What This Page Explains

This page covers:

The Simple Version

During a self-test, the processor checks selected systems by reading status, sending known commands, measuring responses, and comparing those responses with stored limits. Depending on the device, it may test memory, power rails, sensors, motors, valves, alarm outputs, internal communication, or safety interlocks. Most results answer a narrow question: did this subsystem respond the way the software expected under the test conditions?

A passed self-test is useful evidence, but it is not proof that every clinical function works. Some loads, accessories, alarm paths, or performance ranges cannot be exercised internally. A failed self-test is also a symptom rather than a complete diagnosis; the named subsystem, its power, wiring, feedback sensor, mechanical load, configuration, or test conditions may be responsible.

Worked Example: A Valve Self-Test Fails

Suppose a device commands a valve during startup and reports that the expected pressure change did not occur. That does not prove the valve itself is bad. The valve may lack power or drive, a connector may be loose, the pneumatic path may leak or be blocked, the pressure sensor may be offset, or the supply pressure may be missing. The error tells you which response the device failed to observe; the service procedure tells you how to isolate why.

Capture the exact code, text, startup stage, and conditions before cycling power or clearing logs. Check required accessories and consumables, inspect recent service history, and reproduce the test as the manufacturer directs. After repairing the cause, rerun the self-test and perform the external functional or performance verification required for return to service. Clearing the message alone is not verification.

Power-On Self-Test

One of the most common forms is:

Power-On Self-Test, often shortened to POST.

This happens when the device starts.

What POST May Check

Depending on the equipment, startup testing may include:

CPU Test

The processor has to execute code correctly.

If the main processor cannot start or execute the self-test itself, the device may:

Memory Test

The device may test:

for expected behavior.

RAM Failure

RAM is temporary working memory.

A fault may cause:

Flash Memory

Flash may contain:

Corruption can stop startup or create unexpected errors.

EEPROM

EEPROM may store:

If those values are corrupted, the device may fail a checksum or configuration check.

Checksum

A checksum is a way to verify whether stored data changed unexpectedly.

The device calculates a value from the data and compares it to the expected one.

Checksum Failure

Possible causes include:

Configuration Is Not the Same as Hardware

A self-test may fail because configuration data is invalid.

That does not automatically mean a board is physically defective.

Power Rail Checks

The device may monitor internal supply voltages.

Examples:

Power-Good Signal

A power supply may provide a:

Power Good

signal.

The processor uses this to confirm the supply has stabilized.

False Power Failure

Actual voltage:

Correct.

Power-good line:

Missing.

Device may still report a power fault.

Sensor Self-Test

A device may test whether a sensor output is within a plausible range.

Example:

Pressure sensor at zero pressure should read near zero.

If it reports:

50 cmH2O

before use:

Self-test fails.

Plausibility Check

The device may not know exact real-world truth.

It may simply ask:

Is this reading possible under current conditions?

Zero Check

A flow or pressure sensor may be checked while no pressure or flow is expected.

If output is too far from baseline:

Calibration or sensor fault may be reported.

Reference Signal

Some systems apply a known reference to a sensor path.

If the measured response is wrong:

The device knows something in the chain is incorrect.

Internal Test Signal

ECG systems may inject a known electrical test signal.

If the acquisition channel does not measure it correctly:

The device can detect the fault.

Actuator Self-Test

A device may command a component to move.

Examples:

Then verify expected feedback.

Motor Test

Command:

Move drive 10 steps.

Encoder:

Reports 10 steps.

Pass.

Motor Commanded but No Feedback

Possible causes include:

The error may say:

Motor Failure.

But several parts can cause that result.

Valve Test

A ventilator may command a valve open or closed and watch:

Valve Error Does Not Always Mean Valve

Example:

Valve opens correctly.

Flow sensor fails to detect resulting gas movement.

Device reports valve test failure.

The sensor is the actual problem.

Self-Test Often Checks a Chain

This is critical.

A test may involve:

Command → Actuator → Physical Response → Sensor → Processor.

A failure anywhere in that chain can produce the same self-test error.

Fan Self-Test

The device may command a fan and then monitor:

If no RPM feedback appears:

Fan fault.

But possible causes include:

Speaker Self-Test

A device may play a startup tone.

That provides limited evidence that the alarm speaker can generate sound.

Hearing the Tone Proves Something

It proves:

The speaker path produced sound during that test.

It does not prove:

Display Self-Test

Some devices display:

This can help detect:

Touchscreen Self-Test

A touch test may require pressing:

The device compares actual coordinates to expected points.

Battery Self-Test

A battery system may check:

Battery Pass Does Not Prove Capacity

This is important.

A battery may pass a startup check because:

while still having poor runtime.

Capacity Requires Different Testing

A true capacity or runtime test evaluates:

How much energy the battery can actually deliver.

Communication Self-Test

Modular equipment may check whether expected modules respond.

Example:

Host sends query.

Module replies.

Pass.

Module Missing

No reply.

Possible causes:

Bus Loopback

Some communication interfaces can perform loopback testing.

The device sends data and verifies it returns correctly.

Network Self-Test

Some devices may check:

These are different layers.

Link Pass Is Not Server Pass

A network cable can be connected while application communication still fails.

Again:

Know what the self-test checked.

Watchdog Timer

A watchdog is a hardware or software safety mechanism that monitors whether the processor is still operating normally.

Basic Watchdog Concept

Processor must periodically tell watchdog:

I am alive.

If it stops:

Watchdog may reset the system.

Watchdog Reset

A log entry such as:

Watchdog Reset

suggests the processor stopped responding long enough to trigger recovery.

It does not automatically tell you why.

Possible Causes

Background Self-Tests

Some checks run while the device is operating.

They may continuously monitor:

Continuous Monitoring

A ventilator may constantly compare:

If they disagree too much:

Fault is generated.

Redundant Sensors

Safety-critical equipment may use two sensors measuring the same thing.

The device compares them.

Sensor Disagreement

Sensor A:

20 cmH2O.

Sensor B:

5 cmH2O.

The device may not know which one is correct.

But it knows:

They should not disagree this much.

Redundancy Detects Failure

This is powerful because the device does not need an external reference to detect inconsistency.

Dual Processor Systems

Some devices use independent processors that monitor each other.

One may handle primary control.

Another may supervise safety.

Safety Processor

If the safety processor sees something inconsistent:

It may:

Self-Test Before Therapy

Some equipment performs additional checks before delivering therapy.

Example:

Defibrillator may verify:

Therapy Inhibited

If a safety check fails:

Therapy may be blocked.

That is intentional.

Calibration Verification

Some devices compare current sensor behavior to stored calibration limits.

If the sensor falls outside allowable offset:

The device may request calibration.

Calibration Error Does Not Always Mean “Calibrate It”

Possible causes include:

Correct the physical problem first.

Leak Test as Self-Test

An anesthesia machine automated checkout is a type of self-test.

It may use:

to evaluate system integrity.

Failed Leak Test Is a Calculated Result

The machine detects:

It does not directly see:

Absorber gasket is bad.

Error Codes

Self-test failures often generate error codes.

The code usually describes:

What the device detected.

Not necessarily:

What part to replace.

Example

Error:

Fan Speed Low.

The device detected low tachometer feedback.

Possible causes:

Another Example

Error:

Flow Sensor Calibration Failed.

Possible causes:

Error Message Is the Starting Point

Not the final diagnosis.

False Self-Test Failure

A device can fail self-test even when major hardware is fine.

Possible causes include:

Example: Ventilator Flow Sensor

Flow sensor installed backward.

Self-test fails.

Sensor itself may be completely functional.

Example: Anesthesia Circuit

Y-piece not occluded during checkout.

Leak test fails.

Machine is not necessarily leaking.

Accessories Can Be Part of Self-Test

Some startup checks assume:

If the setup is wrong, test result can be wrong.

False Pass

Self-tests also have limits.

A device may pass startup and still fail clinically.

Why?

The self-test cannot reproduce every:

Example: Weak Battery

Startup:

Pass.

Battery voltage acceptable.

Twenty minutes later:

Device shuts down.

Self-test did not perform a full capacity test.

Example: Intermittent Cable

Startup:

Pass.

Cable stationary.

During patient movement:

Signal drops out.

Example: Thermal Failure

Cold startup:

Pass.

After one hour:

Power supply overheats.

Startup self-test never saw the warm condition.

Self-Test Coverage

Think of a self-test as:

A specific set of controlled checks.

It does not prove functions it never tested.

Internal Test vs External Verification

A self-test uses the device's own:

An external analyzer gives you an independent measurement.

Why Independence Matters

Suppose the ventilator pressure sensor is wrong.

The device may use that same sensor during self-test.

Depending on architecture, it may not detect its own error.

An external pressure analyzer can.

Self-Test Pass + External Test Fail

This is possible.

Example:

Defibrillator internal check:

Pass.

External analyzer:

Delivered energy low.

Now you know the internal test did not fully verify output accuracy.

External Test Pass + Self-Test Fail

Also possible.

Example:

Ventilator output pressure:

Accurate externally.

Machine self-test:

Pressure sensor communication fault.

Maybe the device has a redundant sensor or internal communication problem.

Service Mode

Service menus often provide more detailed diagnostics than user-facing self-tests.

Possible information includes:

Raw Values Are Useful

Example:

Pressure should be zero.

Raw sensor:

Large offset.

That helps separate sensor from control behavior.

Event Logs

A self-test failure may be stored with:

Use the log before clearing anything.

Repeated Error

Same error appears:

20 times.

That is stronger evidence than one isolated startup glitch.

Different Errors Together

Several errors occurring simultaneously may point toward a shared problem.

Example:

Fan fault Sensor communication fault Module reset

all at same time.

Think:

Common Cause

Do not assume three components failed independently at the exact same moment.

Power Cycle Clears Error

A reboot may allow self-test to pass.

That proves:

The condition is not currently present.

It does not prove:

The root cause is fixed.

Intermittent Self-Test Failure

If the device sometimes passes and sometimes fails:

Look for variables such as:

Self-Test After Repair

Many devices require a self-test after:

This verifies part of the repair.

Self-Test Is Not Always Final Verification

Depending on repair, you may still need:

Self-Test and PM

A PM procedure may include:

That does not mean PM is finished.

The PM may also require independent verification.

Example

Infusion pump self-test:

Pass.

Flow accuracy:

Fail.

Self-test did not measure actual delivered volume over time.

Self-Test and Alarm Verification

Startup tone:

Pass.

You may still need to verify clinical alarm behavior under defined conditions.

Hardware Presence Check

Some devices simply check whether a component responds electrically.

Example:

Battery recognized.

That does not verify its full performance.

Plausibility vs Accuracy

This is a major distinction.

A sensor reading:

5 cmH2O

when expected near zero may be plausible enough to pass.

But if required accuracy is:

±1 cmH2O,

it may still fail formal calibration.

Self-Test Limit Can Be Broader Than Service Specification

The device may only need to know:

Sensor is functioning enough to operate.

PM may require tighter verification.

Safety Margin

Self-tests often use limits designed around:

They are not necessarily the same as calibration tolerances.

Real-World Example: Flow Sensor Error

Ventilator self-test reports:

Flow Sensor Failure.

Sensor replaced.

Error remains.

Internal sensor tubing found blocked.

The error identified the failed function, not the failed part.

Real-World Example: Motor Error

Syringe pump reports:

Drive Motor Failure.

Motor receives correct power and rotates.

Lead screw jam prevents movement.

Position feedback never changes.

Motor was not the actual cause.

Real-World Example: Battery Passes Startup

Monitor startup:

Battery OK.

Runtime:

Ten minutes.

Battery fails capacity test.

Self-test only verified presence, voltage, and communication.

Real-World Example: False Leak Test Failure

Anesthesia machine automated checkout fails.

Machine tested with wrong circuit configuration.

Correct setup:

Pass.

No hardware repair needed.

Real-World Example: Repeated Watchdog Resets

Device bench-tests normally.

Logs show repeated watchdog resets around reported failures.

Long-duration test reproduces processor freeze.

Logs preserved evidence that a quick startup test missed.

Real-World Example: Fan Failure Message

Fan visibly spins.

Device reports:

Fan Failure.

Service diagnostics:

0 RPM.

Tach wire open.

Motor and fan blades were fine.

Common Mistakes

Treating a Self-Test Error as a Parts List

The error usually identifies a failed check, not necessarily the defective component.

Assuming Self-Test Pass Means Entire Device Is Good

Know the test coverage.

Calibrating Every Sensor That Fails Self-Test

Check setup, leaks, and contamination first.

Ignoring Accessories During Self-Test

They may be part of the test boundary.

Rebooting Until the Device Passes and Calling It Fixed

Intermittent faults can temporarily disappear.

Ignoring Logs

They can reveal what failed before the device recovered.

Using Internal Self-Test Instead of Required External Verification

They answer different questions.

A Useful Troubleshooting Framework

When a self-test fails, ask:

What exact test failed?

Then:

What components and signals are involved in that test?

Then:

What command did the device issue?

Then:

What response did it expect?

Then:

What response did it actually receive?

Then:

Can an independent measurement confirm the condition?

That turns:

Self-Test Failed

into an actual troubleshooting path.

Another Useful Question

Ask:

What chain of components had to work for this self-test to pass?

That is usually more useful than asking:

Which part does this error code mean?

What Did You Actually Prove?

If the device reports:

Self-Test Passed

you proved:

The device completed the internal checks included in that self-test without detecting a condition outside its acceptance limits.

You did not prove:

If the self-test fails:

You proved:

One of the expected internal responses did not meet the test's criteria.

You have not automatically proven which physical component caused it.

Final Thoughts for Biomeds

A self-test is basically the device troubleshooting itself.

It sends commands.

It watches responses.

It compares those responses to expected limits.

Think:

Command → Component → Physical Response → Sensor → Software Decision.

If the test fails, find where that chain broke.

And if the test passes, remember what it did not test.

A self-test is valuable evidence.

It is not magic.

The best approach is to combine:

Internal diagnostics

with:

External verification

and always ask:

What did the self-test actually prove?

— Jake

Important Note

Self-test coverage, startup diagnostics, redundant monitoring, error-code logic, watchdog behavior, calibration checks, and service-mode diagnostics vary widely by medical-device manufacturer and model. Follow current manufacturer service documentation, use approved external test equipment where required, and complete all applicable functional, alarm, performance, and safety verification before returning equipment to clinical use.

Related Biomed Basics

Back to Biomed Basics