How do I set up process control system software for DCS and SCADA integration in a refinery control room?

Setting up process control system software for DCS/SCADA integration in a refinery control room is a high-risk, safety-critical engineering activity. The right approach is to treat it as an operational technology (OT) systems integration program, not just a software install.

Below is a practical, high-level implementation roadmap you can use to plan the work safely.

---

1) Define the control architecture first

Before choosing software or configuring anything, document the intended architecture:

• DCS for closed-loop control, local process interlocks, sequence control, and critical operations
• SCADA for supervisory monitoring, remote assets, tank farms, pipelines, utilities, and noncritical telemetry
• SIS/ESD separated from control where required by safety standards
• Historians for time-series data, trends, reporting, and analytics
• Alarm management layer aligned with operational priorities
• Engineering workstation / operator workstation / domain services separated by role

Key point:
Do not let SCADA and DCS responsibilities overlap without a defined boundary. A refinery usually needs clear separation between control, supervisory monitoring, and safety protection.

---

2) Perform a requirements and risk study

Build the design from process and operations requirements:

• List all unit operations, remote sites, and interfaces
• Identify what must be controlled in the DCS vs monitored in SCADA
• Define required control response times, availability, and fail-safe behavior
• Identify regulatory, cybersecurity, and safety obligations
• Perform:
  • HAZOP / LOPA
  • SIL assessment where applicable
  • Cyber risk assessment
  • Alarm rationalization
  • Cause-and-effect review

This step determines how software should be segmented and what integration is allowed.

---

3) Choose a compatible integration model

Common integration approaches:

A. Native vendor integration

Best when the refinery already uses one main ecosystem. Benefits:

• simpler diagnostics
• better alarm/event propagation
• easier engineering consistency

B. Open standard integration

Use standards such as:

• OPC UA for secure industrial interoperability
• Modbus TCP/RTU for legacy devices
• IEC 60870-5-104 / DNP3 for utility or remote telemetry cases
• MQTT in some modern edge architectures, if approved

C. Middleware / data broker

Useful when connecting multiple plants or vendors, but adds complexity. Ensure:

• timestamp integrity
• data quality flags
• buffering/store-and-forward
• deterministic control paths are not routed through middleware

Important:
Never put a non-deterministic network path in the loop of a critical control action.

---

4) Design the network and segmentation

Refinery control room systems must be network-segmented and hardened.

Typical zones:

• Control network
• Supervisory/SCADA network
• Historians/reporting zone
• Engineering zone
• Enterprise IT zone
• DMZ / jump-host zone for controlled transfers

Best practices:

• firewalls between zones
• no direct internet access from OT
• one-way data flows where feasible
• time synchronization via secure NTP or equivalent
• redundant switches and paths for high availability
• VLANs only as part of a broader security design, not as the sole control boundary

---

5) Specify the software stack

A typical software stack includes:

• DCS controller software
• SCADA server and client software
• OPC UA servers/clients or equivalent drivers
• Alarm/event server
• Historian
• Batch/sequencing or advanced process control modules if needed
• Engineering/configuration tools
• User authentication and directory services
• Backup/restore and version control tools

For each component, define:

• supported OS versions
• patch policy
• redundancy requirements
• licensing
• support lifecycle
• approved interfaces

---

6) Build the tag and data model carefully

Integration succeeds or fails based on the data model.

Create:

• a tag naming standard
• equipment hierarchy
• unit/area naming convention
• alarm class definitions
• data types and scaling rules
• quality/status flags
• timestamp and source-of-truth rules

Also define:

• which system owns each tag
• whether the tag is read-only, writeable, or commandable
• how bad-quality data is handled
• what happens on comms loss

For refinery operations, include:

• valves, pumps, compressors, fired heaters, tanks, analyzers, utilities
• process variables, permissives, trips, and interlocks
• remote package equipment and skids

---

7) Configure alarms and events properly

Poor alarm design is a major operational risk.

Follow these principles:

• alarms must be actionable
• avoid alarm floods
• differentiate alarm, alert, trip, and diagnostic messages
• use priority levels consistently
• suppress nuisance alarms under defined operating states
• record event causality and operator actions

Align with standards such as ISA 18.2 / IEC 62682 for alarm management.

---

8) Ensure cybersecurity from day one

For refinery OT systems, use a defense-in-depth approach:

• least privilege access
• MFA for remote and administrative access
• role-based access control
• application allowlisting where feasible
• removable media control
• patch governance and maintenance windows
• secure remote support via jump servers/VPN with logging
• backups offline or protected from ransomware
• asset inventory and vulnerability management

Follow relevant guidance such as:

• IEC 62443
• NIST OT cybersecurity guidance
• company-specific OT security policies

---

9) Plan redundancy and failover

A refinery control room needs robust availability:

• redundant servers
• redundant controllers where the process requires it
• redundant network paths
• redundant historians if needed
• tested failover and restore procedures
• UPS and power conditioning
• disaster recovery and cold/warm standby strategy

Test:

• controller failover
• server failover
• network loss
• historian recovery
• workstation replacement and restore

---

10) Integrate only through approved interfaces

Set up communication between systems using approved, documented methods:

• DCS to historian
• SCADA to historian
• DCS to package systems
• SCADA to remote telemetry
• DCS/SCADA to MES/ERP via DMZ if necessary

Rules:

• command paths must be explicit and authenticated
• write access must be tightly limited
• use read-only feeds wherever possible
• log all commands, overrides, and operator changes
• validate every interface point during commissioning

---

11) Test in a staging or FAT/SAT environment

Do not deploy directly to the live control room.

Use:

• Factory Acceptance Test (FAT)
• Site Acceptance Test (SAT)
• simulation or process emulation if available
• loop checks and point-to-point testing
• control narrative validation
• alarm and event testing
• operator workflow testing

Test scenarios should include:

• normal operation
• startup/shutdown
• communication loss
• equipment failure
• sensor failure
• alarm flood conditions
• failover and recovery
• cybersecurity event response

---

12) Train operators and maintainers

The best software architecture fails if users aren’t trained.

Provide:

• operator training on normal and abnormal situations
• maintenance training for backups, restore, and diagnostics
• change management procedures
• alarm response playbooks
• cyber hygiene procedures
• emergency manual fallback procedures

---

13) Establish configuration management and change control

Use strict version control for:

• controller logic
• SCADA graphics
• alarm settings
• historian configuration
• user accounts
• network configurations
• interface definitions

Every change should have:

• approval
• testing evidence
• rollback plan
• implementation window
• post-change verification

---

14) Commission in phases

A good rollout is phased:

1. infrastructure and network setup
2. server and workstation deployment
3. core DCS integration
4. SCADA supervisory integration
5. historian and reporting
6. alarm tuning
7. cybersecurity hardening
8. production cutover
9. stabilization and optimization

Avoid trying to bring everything online at once.

---

15) Engage the right disciplines

This should be done by a team including:

• process engineers
• instrumentation/control engineers
• DCS/SCADA integrators
• OT cybersecurity specialists
• operations representatives
• maintenance and reliability staff
• safety instrumented systems specialists
• network/virtualization specialists
• vendor support

---

Suggested deliverables

If you are planning this project, produce these documents:

• Control philosophy
• I/O list and tag database
• Network architecture diagram
• Cybersecurity architecture
• Alarm philosophy
• Cause-and-effect matrix
• Interface control documents
• FAT/SAT procedures
• Backup and recovery plan
• Maintenance and patch strategy
• Operator training plan

---

Bottom line

The safest way to set up refinery DCS/SCADA integration is to:

1. define clear system boundaries,
2. use secure standard interfaces,
3. segment the network,
4. configure alarms and data models carefully,
5. test thoroughly in FAT/SAT,
6. enforce change control and cybersecurity.

If you want, I can also give you one of these next:

• a sample DCS/SCADA architecture diagram
• a step-by-step commissioning checklist
• a refinery OT cybersecurity checklist
• a vendor-neutral tag naming convention example