Radar Level Alarms and Interlocks: Approval and Proof Testing

A radar level reading becomes an alarm or interlock only after measurement uncertainty, process rate, signal delay, logic and final equipment are considered together. A stable display does not prove that a high-high trip will act before overflow or that a low-level permissive will protect a pump. Approval should start from the consequence and required independence, then verify setpoint margins, end-to-end response, failure behavior and bypass control. Process control alarms and independent protective functions should not be treated as equivalent simply because they use similar level technology.

Define the hazardous event

State overflow, dry running, loss of containment, contamination or equipment damage and the credible initiating causes. Record maximum filling or emptying rate, available volume and operator response. Identify existing safeguards and the risk reduction expected from each alarm or interlock. This basis determines independence, testing and reliability requirements.

Set levels from physical margins

Use one datum for sensor, tank, alarm and shutdown points. Include measurement uncertainty, foam or surface variation, blocking distance, control delay and maximum overshoot. Confirm adequate separation between normal control, alarm and trip. A convenient round setpoint is not acceptable if remaining response time is insufficient.

Assess independence

Review shared sensor, nozzle, power, wiring, PLC, software, communication and final element. If the risk assessment requires an independent high-high switch, avoid common failures that defeat both routes. A cloud notification or control-system alarm may support operations but does not automatically meet a protective function's independence.

Define measurement failure behavior

Specify lost echo, device fault, over-range, open circuit, stale communication and maintenance-mode responses. Ensure the control system distinguishes invalid data from a real process extreme. Decide whether the safe action is hold, alarm, stop or another state based on consequence. Do not let a last-good value remain a healthy permissive indefinitely.

Engineer logic and final action

Document setpoint, hysteresis, delay, voting, latching, reset, priority and permissive conditions. Include radar damping, input filtering, scan time, network delay and valve, pump or conveyor stopping time. Verify that the final element can achieve the required state and that failure feedback is visible.

Control bypasses and changes

Restrict setpoint, range, damping and logic changes by role. Record reason, approver, time and restoration. Make bypass status visible and time-limited with compensating controls. Review alarm shelving separately from protective bypass. Configuration convenience should not create an untracked path around the safety decision.

Proof-test end to end

Use physical level where practical and controlled simulation for inaccessible points, clearly distinguishing coverage. Verify pickup, final action, annunciation, acknowledgement, reset, fault states and recovery. Measure response time. Inspect the sensor and independent route separately. Record all test values and restore forces under independent check.

Review performance

Track demands, nuisance alarms, bypass duration, failures and proof-test findings. Investigate repeated alarms rather than widening limits without evidence. Revalidate after product, fill rate, geometry, sensor, firmware, PLC or final-element changes. Retain the risk basis and test history for future approval.

Engineering checklist

• Define consequence and required risk reduction.
• Calculate setpoint and response margins.
• Assess common-cause independence.
• Map every invalid measurement state.
• Control changes and bypasses.
• Proof-test through the final element.

Frequently asked questions

Can one radar provide control and high-high trip?

Only when the risk assessment accepts the shared failure path; many duties require independent protection.

Does software simulation prove the sensor?

No. It proves downstream logic and must be combined with appropriate field tests.

When should alarm settings be reviewed?

After process-rate, geometry, measurement, logic or final-element changes and after significant demands.

Decision record

Keep a concise approval record that states the operating case, assumptions, accepted limits, responsible owner and evidence reviewed. Attach the relevant drawing, configuration, test results and unresolved deviations. Define what process, mechanical, electrical or software change requires reassessment. This record prevents a technically sound decision from becoming an unsupported setting after staff, equipment or operating conditions change.

Related measurement solutions

80 GHz radar level meters · Guided-wave radar level meters