Your UV Lamp Is On. Why Doesn’t That Prove Disinfection?

A controller reports that a UV lamp is running. Your application receives the signal and displays a green badge:

Disinfection: OK

It is a small interface decision with a large assumption behind it.

The controller reported a component state. The application turned it into a claim about treatment performance.

For developers working with physical equipment, UV water treatment offers a useful example of why those two things must remain separate.

A Running Lamp Is Only One Part of the Process

Effective UV treatment depends on sufficient ultraviolet exposure under the conditions the reactor was designed and validated to handle.

Lamp output, water flow, and water’s UV transmittance all influence that exposure. Sleeve fouling and lamp ageing also matter. Public-water guidance therefore calls for monitoring several operating parameters, including flow, lamp status, and UV intensity.

A lamp-running signal cannot answer all those questions.

Even visible light is misleading: ASHRAE notes that UV lamps can continue emitting blue visible light after their useful germicidal life has passed.

Name the Signal Before Naming the Badge

Before implementing a status indicator, ask what the source actually reports.

Is it a command to switch the lamp on? Electrical operating feedback? A sensor measurement? A controller assessment based on multiple inputs?

These represent different levels of information.

This mapping is an illustrative interface design. The actual labels must follow the equipment’s documented signal definitions.

The important step is preserving meaning as data moves from hardware to API to screen.

Keep Measurements and Assessments Separate

A useful data model distinguishes observations from conclusions.

An observation might be a flow measurement with a timestamp and quality flag. An assessment might be the controller reporting operation outside its configured limits.

Store both when available. Include the source of the assessment so that users can distinguish an equipment-generated alarm from an application-generated communication warning.

Do not invent a universal “safe UV intensity” threshold in the frontend. Relevant operating limits depend on the reactor and its validated conditions.

Handle Missing Data Explicitly

Suppose the lamp status updates normally, but flow measurements stop arriving.

Keeping the previous overall green badge would hide the uncertainty. Replacing missing flow with zero would introduce a different error.

Instead, show which information is unavailable and when it last updated. The appropriate response belongs in the system’s agreed monitoring requirements.

A browser dashboard also should not become the accidental implementation of a protective shutdown function. Equipment controls and protective functions need their own engineered requirements.

Test the Meaning, Not Just the Colour

Test combinations that challenge the interface:

• Lamp running, but a process alarm is active.
• Lamp running, but required measurements are stale.
• Start command accepted, but running feedback never arrives.
• Alarm acknowledged, but its triggering condition remains.

For each case, check whether the display says more than the evidence supports.

A good industrial interface makes a precise promise. “Lamp reported running” is useful information. Turning it into “disinfection confirmed” requires evidence that a single status bit cannot provide.

*Disclosure: This article was generated with AI assistance. The software examples are illustrative and do not describe a deployed system.*