Industrial utility operating modes

A utility can appear to work correctly until someone changes its operating mode. The difficult moment often comes during a test, troubleshooting, a production shutdown or a setpoint change. A pump remains forced after an intervention. Ventilation does not return to its expected schedule. An alarm appears, but no one knows whether it actually blocks the sequence or only informs operations.

These situations are not solved by adding another button to a supervisory screen. They require a readable operating rule: which mode is active, who may change it, which command takes priority and which conditions are needed before automatic operation resumes.

This guide provides a scoping method for industrial utilities such as pump groups, ventilation, refrigeration circuits, air-treatment loops or recovery installations. Setpoints, thresholds and permissions remain specific to the process, the site and its procedures.

Start from an actual operating situation

Start with an event the team already has to handle. A pump is put into manual mode to locate a leak. Ventilation moves to a reduced regime while production is stopped. A sensor becomes inconsistent and the operator needs to know which fallback value or strategy applies. Describing the event separates observation, decision and action.

The initial record can fit on one page. It identifies the equipment, the utility’s purpose, the consequence of incorrect operation, the people who use the installation and the documents that describe its current state. Electrical drawings, P&IDs, I/O lists, program extracts and operator instructions do not always tell the same story. Record inconsistencies before changing logic.

An industrial energy audit helps examine uses and operating periods. This article concerns the rule that controls equipment. A consumption trend can reveal unexpected operation; it does not establish on its own which operating mode is permitted or what change may be applied.

Name modes without making them vague

Manual, automatic and override are familiar terms. They still cover very different behaviours across sites. A specification therefore needs to describe each mode through its observable effect, rather than its label on the HMI alone.

In manual mode, an authorised person generally imposes a command or a defined setpoint. Write down what remains active: electrical protections, process safeguards, timers, blocking faults and pressure or temperature limits. Manual mode never means that safeguards may be bypassed.

In automatic mode, the command follows a defined rule. The rule may include a schedule, a production need, pump sequencing, pressure control or a demand coming from another system. The description needs to state which inputs matter, which fallback values apply and which state results when expected information is lost.

In override mode, an ordinary rule is temporarily replaced by another known rule. The override may concern a schedule, a limit, an energy priority or standby equipment. It needs a reason, an end date or an exit condition. An override with no owner often becomes the actual operating condition by default.

Some sites also use stop, standby, maintenance, test or emergency modes. They do not need the same name everywhere. Avoid giving one state two incompatible behaviours, such as a commanded stop and a fault stop.

Define command priorities

One utility often receives several requests at once. Supervision may request a start. A local program may impose protection. An operator may move to manual mode. A fault may block the equipment. Without an order of priority, the team sees contradictory commands without being able to explain the final result.

The logic should make the order visible. A short table is often enough: safety stop, equipment protections, authorised local command, automatic sequence, supervisory setpoint and monitoring information. The exact order depends on the process. It needs validation from operations, maintenance and authorised site owners.

The table does not replace the program. It provides a control point before programming and during testing. It also makes alarms readable. A message such as “ventilation unavailable” remains insufficient when the operator cannot tell whether the cause is manual control, an interlock, a drive fault or the absence of demand.

For each priority, document the source of the request, the information shown to the operator, any delay, the reset condition and the person who may act. A useful alarm states the required action for the operator.

Treat missing information as an explicit state

A utility does not always receive the information it expects. A measurement may be out of range. Communication with a meter, drive or supervisory system may be unavailable. A production request may arrive too late or no longer be coherent with the local state. These cases should not be confused with a normal value or the absence of demand.

There is no universal rule. Depending on the process, equipment may stop, retain its last state for a limited period, move to a fallback value or require operator action. The choice needs to be visible in the specification and the HMI. It should also state how returning information is recognised, and whether a return to automatic operation is immediate or subject to a check.

This work avoids logic that is hard to diagnose: an old value remains in use without being identified, or a communication fault appears only after it affects the process. The aim is not to multiply alarms. It is to let operations distinguish valid information, missing information and an active fallback strategy, with the associated decision and responsible role visible at the point of use.

Keep setpoints, limits and protections separate

A setpoint defines a target value. A limit bounds an operating range. A protection places equipment in a safe state when defined conditions arise. Keep these three notions separate in records, variables and the HMI.

Consider a pressure loop. The setpoint may vary with site activity. A high limit may reduce or block a command before a damaging condition occurs. A protection may stop the pump because of a motor fault, dry running or a condition defined by the manufacturer. Combining those mechanisms in a single parameter makes tests and later changes hard to review.

The project record should therefore identify units, ranges, setting sources and write permissions. A value displayed in bar, percent or hertz does not establish its meaning. The team also needs to know who calculates it, how often it is read and what behaviour applies when it becomes unavailable or out of range.

SwissEnergy guidance on operating technical installations highlights comparing settings before and after a measure. For an industrial utility, that comparison also needs to include process constraints, safeguards and genuinely comparable periods. A setpoint change does not establish energy savings on its own.

Plan the exit from manual or override mode

Returning to automatic operation needs as much precision as entering an override. Moving a selector back to “auto” is not enough. The team needs to know which requests remain pending, which timers restart, which setpoint takes control and whether acknowledgement is needed.

A poorly specified transition can cause an unexpected start, control oscillation or late recovery. It can also hide an inconsistency: the operator believes the equipment has returned to the sequence while a force remains active in the PLC or supervisory system.

For each transition, define four elements: the event that requests it, preconditions, the expected state after transition and the confirmation shown to the operator. If the transition is refused, the HMI needs to state an actionable reason. “Conditions not met” does not prepare an intervention; an active-fault or interlock list does.

A temporary override should leave a record as well. The site may use a manual log, a supervisory entry or a maintenance record. The mechanism depends on the organisation. The need remains the same: recover why the mode changed, who requested it, what was checked and when expected operation was restored.

Use a scenario matrix to review the rule

A scenario matrix lets the team review the logic before programming starts. Each row describes a concrete situation: an emergency stop is active, a local command is authorised, a sensor is missing, an automatic request is present or an override is ending. Columns identify the mode, entry conditions, applicable priorities, expected state, operator information and the related test.

The matrix is not intended to reproduce every line of code. It exposes decisions that are missing, vague language and responsibilities that have not been assigned. It is especially useful when several disciplines work on the same installation. Operations can confirm expected behaviour. Maintenance can assess test feasibility. The automation engineer can translate the rule into the program and identify what needs site validation.

A dated version of the matrix can accompany tests and the handover record. When a behaviour changes, the change is reviewed as an operating decision, not merely as a variable edit. This reduces the risk of finding an override or interlock months later with no one able to explain its purpose.

Prepare tests before changing logic

A useful test checks an observable situation. For a pump, it may confirm that manual control remains subject to intended protections, that the fault is clearly displayed and that returning to automatic mode restarts the sequence with its timers. For ventilation, it may test recovery after a schedule, fault stopping and behaviour when the reference measurement is absent.

Tests need a known initial state. Record the program version, starting values, access used, expected result and observed result. Equipment starting once does not establish that modes, alarms and recovery have been checked in the selected cases.

The energy integration project guide describes items to agree across measurement, automation, supervision, testing and maintenance. Each test’s scope depends on the project. A simulator scenario does not validate field wiring. A site test must not compromise safeguards, production or authorised procedures.

Put the right information into supervision

Supervision should help users understand the utility’s state, not merely issue a command. Show the active mode, the request actually controlling the equipment, current inhibitions, the setpoint in use, active faults and the last mode change when those data are available.

Keep this display proportionate. A page saturated with internal states makes useful information difficult to find. Conversely, a red or green icon alone cannot distinguish automatic running, manual command, deliberate stop or fault unavailability.

Histories complement the operating screen. They help relate a consumption variation, setpoint change or alarm to the mode that was actually active. The energy metering plan explains the care needed around units, periods and missing data. The same discipline applies to mode-change history.

Prepare a handover record

The handover record needs to describe the version actually in service. At minimum, it gathers the mode list, priority matrix, editable setpoints, protections, important parameters, backups and tests performed. A screenshot or a program export does not replace this overview.

Maintenance also needs to know the limits of its intervention. Some changes belong to the site team, an integrator, an electrician or the machine manufacturer. Access rights, licences, required tools and change procedures should be agreed before an emergency, not while equipment is unavailable.

An industrial maintenance service can organise takeover of an agreed scope. Response times, on-call cover, parts, remote access and OEM escalation remain contractual. They do not follow from automation documentation alone.

Measure after return to service

An operating-mode change can affect availability, comfort, the process or consumption. Observe these effects separately. Acceptance confirms the agreed functions. Energy effects require a comparison over relevant periods and conditions.

Public SwissEnergy tools can estimate and document certain measures on technical building installations. For an industrial utility, the site needs its own comparison conditions: production, weather where relevant, required quality, other loads and changes made during the period. A reduction in consumption needs explanation before it is attributed to a new setpoint or operating mode.

Vanguard Systems works on energy, PLC/SCADA automation and maintenance in French-speaking Switzerland. An initial scope can gather available records, identify modes that need clarification and prepare tests with operations. Describe the utility concerned to define scope, responsibilities and takeover conditions.

Sources: SwissEnergy, operational energy optimisation ; SwissEnergy, operational optimisation tool.