Best Practices for Building a ROCC in Utilities

Utilities across the country are entering a period of significant new plant construction. Rising power demand is pushing companies to bring new generating plants online in waves, not just one-offs.

As utility fleets grow more geographically dispersed, many companies are turning to Remote Operations Control Centers (ROCCs) to centralize oversight of their generating assets. Think of it like the Navy building every ship to the same specifications, so any engineer can move between them and know how to fix what's broken.

Here's what utility companies need to know to build a ROCC that works.

What a ROCC Is and Isn’t

A ROCC is an organizational strategy and operating model that centralizes management, data, and decision-making for geographically scattered assets. It's a centralized hub used to monitor, manage, and control dispersed sites from one location.

Importantly, a ROCC doesn't eliminate local expertise. It shifts routine fleet supervision and coordination to the center while preserving on-site capability for physical tasks, emergencies, and situations requiring direct observation. The most important operational principle is deciding what the ROCC may observe, advise on, or directly control.

The ROCC Operating Model

The ROCC operating model defines how a company organizes its people, processes, and culture to manage remote sites. A useful operating model has three levels:

1. Monitor: The ROCC sees telemetry, alarms, trends, work orders, and equipment status, but does not issue commands.
2. Supervise: The ROCC recommends actions, coordinates plant teams, and may issue low-risk commands with plant acknowledgement.
3. Control: The ROCC can directly execute defined operating actions, subject to procedures and technical safeguards.

The guiding principle across all three levels is local fail-safe behavior: if communications with the ROCC are lost, the plant must be able to operate safely or transition to a safe state based on pre-established design and procedure.

For a fleet of new generating plants, a ROCC succeeds when it's designed as a standardized operating system for the fleet, not a separate entity that simply receives plant data. Certain foundational work described below must occur before the first unit enters service.

Best Practices for Implementing a ROCC

A ROCC becomes exponentially more effective when plants share common naming conventions, alarm priorities, operating modes, procedures, logbooks, KPIs, and screen philosophies. Complete hardware uniformity is rarely realistic, especially after acquisitions, but operational standardization is often achievable. It's what makes fleet-wide visibility meaningful. For a new-build fleet, the ROCC should be part of the plant program from the earliest design phase, not a control room added after individual sites are commissioned.

In practice, standardization comes down to several disciplines:

• Implement a "Single Source of Truth" for naming. Enforce a fleet-wide tagging and naming convention (e.g., KKS or a similar standard) in new-build contracts. If it's "Pump A" in the SCADA, it should be "Pump A" in the maintenance system and on the physical label.
• Follow the 3-alarm rule. Avoid “alarm bloat” by limiting alarms to three actionable categories: Critical (immediate safety/trip risk), Warning (action required to prevent trip), and Advisory (maintenance needed). If an alarm doesn't require an action, it shouldn't be an alarm.
• Adopt a gray HMI. Use high-performance HMI design. Most screens should be shades of gray and muted tones. Reserve bright colors like red and yellow exclusively for abnormal conditions or alarms so they stand out instantly.
• Standardize operating modes, not just settings. Define exactly what "Ready," "Starting," "Online," and "Tripped" mean across the fleet. This allows the ROCC to see a fleet-wide availability dashboard that compares apples to apples.
• Establish one version of each KPI. Document the exact math for "Availability" and "Performance" once. If plants use different exclusion rules for outages, fleet-wide benchmarking data will become unreliable.
• Use Core and Annex procedures. Create a “Fleet Core” procedure for the ROCC workflow, then attach “Site-Specific Annexes” to each plant's unique hardware. This keeps how the fleet works consistent while respecting what each site runs.

Even when several plants are new and similar, don't roll all of this out at once. Activate the ROCC in deliberate waves:

1. Commission the ROCC systems and operator team.
2. Connect one pilot plant, or a limited subset of plant functions.
3. Operate in monitoring and coordination mode.
4. Introduce defined remote controls once acceptance criteria are met.
5. Capture lessons learned and update the standard design.
6. Roll the revised standard out to the next plants or operating wave.

This phased approach lets the organization validate assumptions, build trust in the model, and refine the standard before scaling it across the fleet.

ROCC Governance Principles

A ROCC can be perfectly designed but still fail without proper governance. Governance is not just a formality. It’s what turns a centralized control room into a centralized decision-making system.

An effective operating model makes four things clear: who is accountable, who can make which decisions, what information and controls each role receives, and how teams coordinate during normal, abnormal, and emergency conditions.

However, a generic org. chart doesn't answer any of this with the precision a ROCC requires. The answers need to live in a decision-rights matrix built around actual operating activities. For each key activity, the matrix should document:

• Who initiates the action
• Who approves it
• Who executes it
• Who must be notified
• Who has authority to stop or override it
• What record must be created
• What happens if communications are lost

The most challenging part of that matrix is usually remote-control authority. In other words, which actions the ROCC can execute vs. which stay in the hands of people on-site. Remote-control authority itself should be assigned based on consequences of an error, whether the task requires physical observation, how mature the procedure is, and how good the telemetry is. A simple four-category framework makes the distinction concrete:

• Category A: Observe only – Information is visible at the ROCC, but no remote command is permitted.
• Category B: Remote command with site awareness – Low-risk, routine, repeatable action; the site is informed or confirms readiness.
• Category C: Remote command with dual authorization – A central operator executes the command only after site or supervisory approval.
• Category D: Local authority only – Physical verification, safety-critical tasks, electrical switching, maintenance isolation, emergency actions, or other high-consequence activities.

Governance needs to be established before the ROCC goes live. Don’t wait to figure it out later. A clear matrix and a shared understanding of the categories mean operators know exactly what they can act on and site teams know exactly when they'll be looped in.

Lasting Decisions

A power plant is intended to last for generations, and the early decisions during design and construction shape how it runs for the rest of its life. A ROCC is one of those decisions. It gives utilities a single, real-time view of an entire fleet in order to bring new plants online faster, keep teams moving efficiently, and make operational excellence the standard. It’s so much more than a control room. It’s how a utility positions itself to keep building and keep growing without operations becoming the bottleneck.

At Trenegy, we helputilities modernize the systems, processes, and cross-functional alignment needed to keep up with rising demand, a more complex grid, and growing regulatory and customer expectations. To chat more about this, emailinfo@trenegy.com.