Remote Operations Center (ROC)

Principles, Scenarios and Suitability

A remote operations centre combines multi-site status in a shared context, but must not turn missing data into an apparently normal plant state. Actionable events, responsibility and handover matter more than the number of displays or their refresh rate.

Think of a coordination desk where several shifts can see unfinished work. An alarm is an event requiring a defined response; communication loss means the physical state is unknown. No warning message is not evidence of no incident. Show the latest source timestamp and local contact route without requiring users to search several screens.

Escalation means passing responsibility to the next agreed level when defined conditions occur, not simply increasing sound or notifying everyone. Grouping related events reduces duplicate effort but can hide separate causes. Retain source events and ownership history for review. Define what the centre can actually advise on, coordinate or approve; visibility alone does not grant authority.

Illustrative Design Scenario

Illustrative design scenario: central staff distinguish sites with missing data from sites with process alarms. They contact local duty personnel with timestamped evidence and record coordination outcomes without overriding the authority of on-site operators.

Suppose one site loses communication while another reports high tank level. Investigate network health separately from contacting the tank controller. Do not classify the silent site as normal. If contact fails, follow escalation rules approved by the local owner without guessing conditions from readings before the outage.

Routing every event through the centre provides an overview but adds staffing load. Letting sites manage routine events requires the centre still to see unresolved work and escalation. Trial these choices through tabletop exercises and simulated data. Ask duty staff who owns the work after each step; do not create real machinery incidents for rehearsal.

Inputs and Prerequisites

Collect site IDs, time zones, alarm lists, duty contacts and escalation rules. Include communication-system health and identify the people authorised to make decisions at each location.

Separate site identifiers, equipment identifiers and source time from receipt time at the centre. Agree severity definitions together: urgent can mean different things at different locations. The shared contract should make those differences explicit before events enter one queue.

Output should be an event queue with an owner, update time and next action, not just an alarm count. Duty rosters and contact details need access controls and maintenance when responsibilities change. Otherwise a technically delivered event may still reach nobody responsible for taking the next step.

Trial and Integration Workflow

Evaluation and Acceptance Criteria

Check event completeness, time to assigned ownership and the number of unowned outstanding events. Rehearse simultaneous incidents to assess staffing load. Verify missing-data indicators and last-update times, rather than merely confirming that a dashboard can be opened.

Send delayed and duplicate simulated events and check that history remains ordered by occurrence time. Test handover when the previous owner logs out, confirming that unfinished queue items do not disappear during the transfer of duties.

Local and central teams should jointly review rehearsal records. Measure how long people take to understand a situation separately from message travel time. Acceptance must state the event workload tested; it cannot establish suitability for every possible number of sites or simultaneous incidents.

Failure Cases and Limitations

Central staff lack local context such as sounds, smells and physical conditions. A network outage may hide multiple event types together. System availability is not the same as operational-team readiness, and an SLA should not be announced without supporting scope and evidence.

Seeing local information does not give central staff the authority or practical ability to replace the site response. Preserve existing emergency procedures and protection systems, including a way to work when the centre is closed or unreachable.

Cross-site images may contain people or information the site has not authorised for sharing. Limit content to what event coordination needs and set retention periods. A multi-site centre is a design approach, not a claim that a continuously staffed service already exists.

Practical Checklist

• Does every alarm have a local owner?
• Is communication loss distinct from a process alarm?
• Can work continue when the central facility is unavailable?

References and Further Reading

• Google SRE — Monitoring distributed systems
• NIST SP 800-82 Rev. 3 — Guide to OT Security