System Implementation Considerations

This chapter includes the following major topics:

Server Sizing and Storage Sizing

Traditionally, SCADA Host software has been the mechanism for viewing graphical displays, alarms, and trends. Control from the SCADA host itself only became available when control elements for remote instruments were developed. These systems, which were isolated from the outside world and were the domain of operators, technicians and engineers, had the responsibility to monitor, maintain, and engineer processes and SCADA elements. With IT advancements, this is no longer the case. Many different stakeholders now take advantage of real-time access to the data that the SCADA host software generates.

Accounting, maintenance management, and material purchasing requirements are performed or partly performed from data derived from the SCADA system. Consequently, the SCADA host is driven to be an enterprise entity providing data to a number of different users and processes. This has encouraged SCADA host software development to adopt standards and mechanisms to support interfacing to these systems. Key to sizing of a SCADA system is the overall quantity of pipeline network assets to be controlled.

  • Servers and storage should be considered
  • Number of devices, points polled per device, polling interval, and the applications on top of SCADA determine the CPU and memory requirements
  • Number of physical domain controllers, virtual hosts, virtual guests, virtual guest backups, and built-in expansion need sizing to determine hard drive requirements
  • Microsoft SQL storage requirements for online data and backups
  • Memory sizing for performance of all virtual guests
  • Number of remote connected users determines resources allocated to the remote access servers

Scalability Considerations

Information retrieval and communications over the network WAN for the SCADA system should not be a major concern; however, how the traffic traverses the Control Center network should be understood. The Primary Production system doesn't just facilitate communications with the pipeline network, but, as described, also requires communications with the enterprise and the Secondary Production system. The communications with the backup Control Center, from a bandwidth utilization perspective, can be very different based on the applications and the type of pipeline. For example, 20Mb/s on a gas pipeline is contrasted with 100 to 200 Mbps for replication on a LNG pipeline driven mainly by software applications running on top of OASyS DNA such as the Liquids Management System (LMS). The ASA as the security device is in line of these flows of data. Therefore, the following should be considered:

  • ASA sizing
  • ASA throughput degrades when enabling IPS/IDS and other computation-intensive features
  • The traffic traversing the different points in the network
  • Gas and liquid pipelines will have differing replication between the Control Center based on the applications
  • The customers' traffic profile
  • Number of devices, points polled per device, polling interval, and the applications on top of SCADA may drive replication data between Primary and Secondary Sites
  • Data replicated to the IDMZ from the Operational environment

To obtain guidance to ASA firewall scalability when comparing models, see the “Compare Models” chapter in Cisco ASA 5500-X Series Firewalls at the following URL: