Content area
Supervisory Control and Data Acquisition (SCADA) systems are essential for the operation of distributed industrial processes owned/operated by utilities i.e. water systems or electrical grids. While the primary function of SCADA is to monitor and control physical processes, SCADA also performs secondary functions that are critical to continuous operation and improvement of the overarching physical processes. SCADA systems contextualize realtime data to inform decision-making, alert stakeholders to potential issues, and mitigate downtime via situational awareness. Beyond contextualization of process data, SCADA systems are a critical component of analysis and utilization of real-time process data for intelligence and optimization. When designed appropriately, SCADA system architecture facilitates comparison of real-time data to historical data and/or process models, enabling capability for dynamic process control changes to optimize system performance in real-time. Additionally, SCADA Systems are composed of many interconnected components commonly organized by geographical regions, process control areas, and/or digital zones. As industrial processes become more complex and technology advances, new challenges and opportunities emerge, necessitating that SCADA systems are designed not only to optimize performance but also to enhance resilience, and safeguard against physical and cyber threats. This paper examines the evolution of SCADA systems, explores current state and future trajectories, and applies a requirements-based system development lifecycle (SDLC) that ensures Verification, Validation, Testing, and Training activities are embedded throughout the SDLC.
Abstract
Supervisory Control and Data Acquisition (SCADA) systems are essential for the operation of distributed industrial processes owned/operated by utilities i.e. water systems or electrical grids. While the primary function of SCADA is to monitor and control physical processes, SCADA also performs secondary functions that are critical to continuous operation and improvement of the overarching physical processes. SCADA systems contextualize realtime data to inform decision-making, alert stakeholders to potential issues, and mitigate downtime via situational awareness. Beyond contextualization of process data, SCADA systems are a critical component of analysis and utilization of real-time process data for intelligence and optimization. When designed appropriately, SCADA system architecture facilitates comparison of real-time data to historical data and/or process models, enabling capability for dynamic process control changes to optimize system performance in real-time. Additionally, SCADA Systems are composed of many interconnected components commonly organized by geographical regions, process control areas, and/or digital zones. As industrial processes become more complex and technology advances, new challenges and opportunities emerge, necessitating that SCADA systems are designed not only to optimize performance but also to enhance resilience, and safeguard against physical and cyber threats. This paper examines the evolution of SCADA systems, explores current state and future trajectories, and applies a requirements-based system development lifecycle (SDLC) that ensures Verification, Validation, Testing, and Training activities are embedded throughout the SDLC.
1. Keywords
SCADA, Automation, Process Control, Industry 5.0, Cybersecurity.
2. Introduction
Supervisory Control and Data Acquisition Systems (commonly abbreviated as SCADA) are a critical tool for industrial organizations since they help to maintain efficiency, process data for smarter decisions, and communicate system issues to appropriate stakeholders to help mitigate downtime. SCADA is one example of an overarching group of systems referred to using the term Operational Technology (ОТ). "ОТ encompasses a broad range of programmable systems and devices that interact with the physical environment. ... These systems and devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events. Examples include industrial control systems, building automation systems, transportation systems, physical access control systems, physical environment monitoring systems, and physical environment measurement systems." [1] Differentiating SCADA from other types of OT is critical - "Supervisory control and data acquisition (SCADA) systems are used to control (geographically) dispersed assets for which centralized data acquisition is as important as control.SCADA systems integrate data acquisition systems with data transmission systems and HMI software to provide a centralized monitoring and control system for numerous process inputs and outputs." [1] SCADA in the utility sector typically comprise of software and hardware elements that have been electronically, physically, and technologically integrated to perform key tasks:
* Collect process data from sensors and other types of process instrumentation.
* Contextualize and display real-time process data in a consistent user interface (commonly graphical).
* Control physical processes at both local and remote facilities.
* Perform process control via interaction with actuators such as motors or solenoids.
* Historize and store process data in a time-series database.
* Contextualize real-time and historical process data to identify abnormal/adverse/undesirable process conditions and notify process stakeholders of present/emergent conditions for corrective action as well as to provide insight to process efficacy and optimization/improvement opportunities.
3. Problem Description
SCADA systems comprise of thousands of individual components grouped into geographical regions, process control areas of responsibility, architectural levels, and digital zones. These subsystems and components are derived from multiple professional disciplines [2], so a Systems focus to the design process is critical to quality. Defining high-level Business Goals, deriving Requirements and Quality Attributes will facilitate discussions around design constraints, identification, and application of compensating controls for design constraints, and subsequent elicitation and classification of requirements. [3] [4] Due to the multidisciplinary systems approach, it is necessary to derive a single project management methodology to SCADA system development that is derived from discipline-specific sources. [5] [6] [7] As each discipline has a unique approach to system Verification / Validation / Testing / Training (VVTT), it is critical to introduce VVTT activities throughout system Initiating, Planning, Designing, Constructing, Commissioning, and Operating activities. [8] [9]. Further, the evolution of SCAD A Systems from heavy reliance on proprietary systems to commercial off-the-shelf (COTS) Information Technology (IT) infrastructure for data transmission/storage/retrieval has created new opportunities and challenges. Termed the Third Industrial Revolution (Industry 3.0), the digitization of process control systems and the use of COTS hardware/software have exposed new vulnerabilities and failure modes in SCAD A systems that were previously uncommon/nonexistent. More specifically, changes in the cybersecurity threat landscape now require additional considerations when designing SCAD A systems. However, use of common IT infrastructure components has opened new avenues for high-performance data acquisition, storage, and analysis. This utilization of common IT infrastructure within industrial systems for collection/storage/access of data accelerated as the Fourth Industrial Revolution (Industry 4.0) began. Now that stakeholders were faced with "big data", they wanted more data and more value. As more data became available via wireless networking and low-cost edge devices (termed the Industrial Internet of Things or IIoT), increased storage mechanisms were introduced via cloud computing and data storage, and increased efficiency in the analysis/consumption of data became realized by introducing cutting edge technologies from the IT space such as Artificial Intelligence and Machine Learning. [10] [11] Moving forward, a new focus has emerged around enhancing societal well-being and ensuring the sustainability of the economy and industrial production. Termed the Fifth Industrial Revolution (Industry 5.0), we are now tasked with how to deliver systems that facilitate the promises of Industry 3.0/4.0 while meeting stakeholder expectations during the advent of Industry 5.0. [12] Unfortunately, critical VVTT activities are often overlooked during system delivery, which leads to a system riddled with unfulfilled requirements and security vulnerabilities. This concern must be addressed to ensure system adoption by stakeholders.
4. Related Research
Developing an effective SCADA system is often difficult for a non-technical set of stakeholders. Rather than initiating design via a casual conversation or jumping into an overly technical deep dive focused on technology selection, a series of formal requirements gathering and recording provides a conduit to ensure stakeholder and domain requirements are met. Requirements act as a 'bridge' between business goals and design efforts, in that "goals are high-level objectives of a business ... but a requirement specifies how a goal should be accomplished by a proposed system." [4] In some cases, stakeholders can express basic types of "functional requirements" i.e. the system should open a valve when a condition is met and subsequently close the valve when the condition alleviates. This is a functional requirement (FRs), which "describe the services the system should provide and how the system will react to its inputs." [4]. Additionally, stakeholders may express "non-functional" expectations such as the level of performance the system must achieve (i.e. must not lose data in transit, must be recoverable in less than a day etc...) or domain-specific adherence (i.e. system must meet NIST SP 800.82 requirements). These nonfunctional requirements (NFRs) are typically "imposed by the environment in which the system is to operate. These kinds of environments include timing constraints, quality properties, (and) standard adherence" [4]. Many non-functional requirements consist of user expectations such as "my system must show me fresh data" or "my system must keep out an unauthorized user", which are difficult to elicit. However, sometimes stakeholders cannot express their requirements easily. Stakeholders may believe that some requirements are 'common sense', creating 'covert contracts' with system providers that can never be fulfilled because they were never identified in the first place. A unique approach to identifying non-functional requirements is using antimodels. Antimodels quickly identify functional requirements in that they "create a cause-and-effect hierarchy for unwanted behaviors leading to system failure .... creating the "shall not" requirements." [4]. An example of an antimodel could be "threat actors can remotely access the system without authorization", where the resulting discussion quickly elicits NFRs. formal Requirements Elicitation process is recommended. Further details on the function and form of these activities, recording/tracking these elicited system requirements via requirements register, and apply ing/translating these requirements into Quality Attributes (QAs) and Q A Scenarios can be found in sources cited in the bibliography. [4] [8] [9]
Once system requirements are defined, the design of the SCADA system can begin. Unfortunately, "use of the term SCADA is not universal. Depending on the industry, the geographic area, and end-user's own internal conventions, SCADA may include all of the control system or only very specific parts." [13] Therefore, it is critical to utilize broadly accepted system architectural models and industry-agnostic standards to define a System Description for SCADA. Established in the 1990s, the Purdue Enterprise Reference Architecture (PERA) is widely accepted as the most complete system architecture and hierarchy for digital/physical assets. [14] Using this framework, the physical and digital assets that comprise a SCADA system are grouped into six primary levels:
* Level 5 - Public Internet
* Level 4 - Business/Enterprise Networks - business systems, enterprise resource planning systems, financial systems, user systems, customer systems.
* Level 3 - IT/OT Enterprise DMZ - management servers, replicate historians, domain controllers, file transfer and data transfer services.
* Level 2 - Regional Supervisory - monitoring and supervisory control of a regional physical process as well as historization of data and alarm and event identification systems.
* Level 1 - Local Controllers - devices/systems to provide monitoring and automated control of a local physical process.
* Level 0 - Field Devices - process instruments and actuators located at the local physical process.
SCADA System design and implementation typically require the documents listed below. Subsequently, utilization of these design documents will provide valuable linkage through requirements traceability and Verification, Validation, Testing, and Training activities. Common design documents:
* Stakeholder Register and Requirements Register - derived from project scoping activities.
* Control Narrative/Description - ANSI/ISA 5.06.01-2007 and/or ANSI/ISA95.
* Piping & Instrumentation Diagram (P&ID) and/or Process Flow Diagram (PFD) - ANSI/ISA-5-1.2022.
* Mechanical and Structural Diagrams - American Institute of Architect's National CAD Standard
* Instrument Schedule - consists of a table that references the P&ID and provides additional detail not included in the P&ID. The Instrumentation Schedule should contain the ISA P&ID Instrument Identifier, a plainlanguage descriptor of the instrument, the electrical or digital signal mechanism used to integrate the instrument into a control system, the measurement states (digital) or range (analog), units of measurement, and space for VVTT activities
* Electrical Wiring Diagrams and/or Electrical One-Line Diagram - NFPA 70 and NFPA 79.
* Alarm and event notification strategy - ANSI/ISA-18.2 and Human-Machine Interface design - ISA101
5. Methodology
Prior to designing SCADA Systems, we will identify system requirements via five initial project scoping activities:
Step #1 - Identify SCADA System stakeholders - common stakeholders for SCADA include the individuals/organizations that operate, analyze, administrate, and regulate the overarching physical process, those who design and construct the SCADA System, and those who are affected by the overarching physical process. A full Stakeholder analysis should include identification of stakeholder Roles, Use Cases, and requirements contributions. This process is discussed briefly in Section 4 with external cited sources providing additional detail.
Step #2 - Document Architectural Drivers (AD) - contextual considerations that must be identified and discussed to understand how the system is relevant within its environment. In other words - the "Ws" of a system. (Othmane, 2024) Architectural Drivers typically transition into additional functional, nonfunctional, and domain requirements. An example of an architectural driver is geography. As the physical process is geographically distributed (facility-level or geographically), the overarching SCADA system must facilitate integration to multiple individual processes i.e. a power grid - not just a single unified process i.e. a power plant as in a Distributed Control System (DCS).
* Draft Quality Attributes (QA) and QA Scenarios - provide a mechanism to capture and document how an architectural driver is critical to quality in the customer's perception while simultaneously providing an example of how to contextualize and quantify success. Above, the AD of Geography states that the SCADA system must accommodate monitoring assets spread across a large geographical region. If the assets were in a single location and performing a single unified task, a DCS or other form of ОТ could be a better fit for the process. As a result, the quality attribute scenario discusses the "System network must collect data at a high enough frequency to fulfill operational and compliance requirements." As the system is geographically distributed, it would likely take a human operator an unacceptable amount of time to physically collect all the data pertinent to operating the system. As a result, the system must provide a mechanism to collect the data pertinent to operating the system punctually (within an acceptable level of chronological relevancy) as well as reliably (within an acceptable level of up-time) and effectively (within an acceptable level of incorrect or inaccurate data).
* Quantify Constraints - specific condition(s) that must be met." [4] Constraints are aspects of project design that must be considered to determine the feasibility of a system. Typically, these include both internal and external "economic, environmental, sustainability, manufacturability, ethical, health and safety, social, political, and time" factors. [15] Additionally, "constraints such as organizational policies, procedures, and task orders; local, federal, state, and international regulations or statutory laws; public opinion" [3] should be considered. Often, constraints define limitations or obstacles to the development of the system.
* Implement Compensating Controls - Compensating Controls is a term used by cybersecurity practitioners that refers to "measures taken to address any weaknesses of existing controls or to compensate for the inability to meet specific ... requirements due to various different constraints." [16] This concept can be extended from cybersecurity practice to general system design.
Transitioning from the initial project scoping activities, we can move forward with traceable system requirements. The seven most common and accepted features (functional requirements) of a SCAD A system are listed in the table below [13]. Additionally, operational stakeholders have an expectation of continuity and consistency of their SCAD A system (often measured in system accessibility, usability, and uptime/availability). Identified below as "X", this nonfunctional qualitative statement of performance requirements must be included to ensure appropriate traceability that nonfunctional requirements identified during previous steps arc accounted for in the next design stages. Next, we will rewrite the SCADA features into functional requirements while adjusting language clarify concepts and increase readability to a non-technical business stakeholder. This reduces domain stakeholder assumptions that may be embedded in domain-specific terminology. Additionally, we will order these requirements to reflect the flow of data from sensor to stakeholder to foster understanding/adoption in subsequent steps._
Now that system requirements are documented, system design and construction can move forward. Previous sections outline what a SCADA system is (and is not), discuss trends in SCADA technology and design, identify components and capabilities of SCADA, provide a common architecture for a SCADA system, and identify typical design documentation associated with SCADA. Next, we must identify the SCADA System Development Lifecycle (SDLC). In previous sections, we discuss the multidisciplinary requirements associated with SCADA - electrical and industrial engineering, information technology, process design, heavy electromechanical construction, and domainspecific knowledge are all required for successful system deployment. SCADA "projects are always a team effort ... (and require) a wide variety of individuals and skillsets ... (coming) together to execute a successful project.The coordination of these efforts is usually undertaken by a group of project managers: one acting for the owner, one acting for the design team, and another acting as part of the construction team." [2] The SCADA SDLC must account for these diverse contributions while simultaneously facilitating coordination during design/construction activities as well as traceability between activities to ensure continuity between requirements and realization. Before proceeding, it is critical to identify these two factors:
* The Project Management Professional (PMP) certification and Project Management Body of Knowledge (PMBOK) are developed and maintained by the Project Management Institute (PMI), which is a cross-domain professional organization. Further, the PMBOK framework is commonly utilized in the IT space.
* As discussed by Nasby, construction of SCADA systems is frequently embedded inside larger construction projects. Further, these projects are designed and specified using the Construction Specification Institute's MasterFormat specification framework. [2]
Additional context:
* The IT infrastructure required for modern SCADA systems should be provided by IT Providers with appropriate domain experience/expertise. Information Technology projects typically utilize the PMI PMBOK framework. This framework comprises 49 processes grouped into five major process groups: Initiation, Planning, Execution, Monitoring and Controlling, and Closure. [6]
* The design and construction of the SC AD A System is coordinated/executed by an external SCADA System Integrator (SI). SCADA System Integrators follow ISA frameworks - where terms Site Acceptance Test are unique to the System Integration space.
* The design and construction of Utility Infrastructure is coordinated by conventional Engineers and the construction is coordinated by a General Contractor and Electrical Contractor. Engineering & Construction Firms typically utilize the six step Construction Project Lifecycle, and terms such as 60% design and Project Control are unique to the construction space. According to the Construction Project Lifecycle (CPL) defined by the Construction Management Association of America (CMAA), a project has six phases: Project Design, Project Procurement, Project Preconstruction, Project Execution, and Project Control. [7]
6. Results
Aligning these three disparate frameworks in a consumable format is critical for success, as SCADA projects are interdisciplinary and rely on professionals from the IT, Electrical/Mechanical Construction, and OT/SCADA space. As individuals in all three areas will be required throughout the project and subsequent system lifecycle, it is critical to align concepts and communications. In the table below, we will align the PMBOK activity groups and the Construction Project Lifecycle with the 7-step format outlined in an emergent/draft standard from the International Society of Automation - ĮSAI 12 - using the new Systems Engineering Management Plan (SEMP) Process._
Building a SCADA system is interdisciplinary, and "projects are always a team effort ... (and require) a wide variety of individuals and skillsets ... (coming) together to execute a successful project." [2] Given this consideration, an appropriate System Development Lifecycle (SDLC) must be selected. Here, we propose using the V-Model, which is dually recognized by PMBOK and IEEE (where substantial institutional ties exist between IEEE and ISA). The VModel adds unique value to this system development effort [3]:
* The V-Model minimizes project risks by improving transparency, specifying standardized methodologies, and attaching the corresponding results to the implementation methodologies with associated stakeholder roles held accountable. This facilitates recognition of implementation deviation (from design) by forcing VVTT activities to occur adjacent or concurrently with value-add design and construction activities.
* The V-Model facilitates concurrent work in activities with common predecessors by introducing common successors, namely VVTT activities and formalized handoffs to subsequent processes. This guides assurance that overarching midstream deliverables arc complete and fulfill quality requirements prior to continuing.
* The V-Model facilitates compressed schedules in that handoffs of isolated deliverables into succeeding integration activities are formalized as part of the project plan.
* The V-Model ensures improved communication between all stakeholders and project teams, in that VVTT activities are enforced both between major stages as well as concurrently within each major stage.
As shown in the V-Model System Development Lifecycle above, activities are grouped into sections (shown as colored polygons) that correspond with the six project phases outlined in the SEMP Process: Phase 1 - Initiating - orange, Phase 2 - Planning - green, Phase 3 - Designing - light blue, Phase 4 - Constructing - dark blue, Phase 5 - Commissioning - red dotted, Phase 6 - Closure - black. It is important to note that Phase 5 - Commissioning has significant overlap between Phase 4 - Constructing and Phase 6 Closure. The dark blue arrows show VVTT activities. It is critical to identify that VVTT is not executing a simple point-in-time test plan or training plan, rather a continuous process that is built into the System Development Lifecycle to ensure successful design, construction, implementation, integration, and operation of a system. More specifically, it is important for all project stakeholders to understand the significant value-add created to all project teams during VVTT activities when distributed across the System Development Lifecycle. To succeed in this goal, we must clearly define Verification, Validation, Testing, and Training activities. Outlined in ISA/ANSI-62381 [5], Factory Acceptance Test (FAT), Site Acceptance Test (SAT), and Site Integration test (SIT) activities include many aspects of Verification and Validation, however others may be overlooked. More specifically, the SIT tests ensure that the overarching SCAD A system and its subsystems successfully integrate with process equipment, adjacent systems, and the surrounding environment. Additionally, the SAT/SIT can be split into multiple smaller SAT/SITs for each subsystem, and when witnessed by stakeholders, these activities can contribute towards subsequent training activities. This coordination can be facilitated by adoption of the SDLC shown above, which will provide the appropriate traceability between initial system requirements and the VVTT activities. Further, adoption of a continuous VVTT approach - identified above in the SDLC - will reduce endstate bottlenecks typically associated with VVTT when left as an end-state trailing deliverable.
7. Conclusions
The rapid emergence and movement through Industry 3.0/4.0/5.0 has caused a decreased focus on system VVTT activities. Calibrating the V-model SDLC to facilitate VVTT activities using applicable industry consensus standards provides a path to increased requirements traceability through VVTT activities. This not only ensures stakeholder acceptance and adoption of a system but also ensures emergent Industry 4.0/5.0 technologies can be leveraged through vetted and accepted SCAD A technologies and architectures that do not introduce additional issues.
Acknowledgements
Many thanks to my academic mentors Dr. Mohammed Darayi and Dr. John Wright for leading me in new directions. Additional thanks to my professional mentors and colleagues Ashok Nangia, Graham Nasby, Roger Sandak, James Barbato, Brian Gresehover, John Childers, and Lee Mace for providing valuable insights that contributed to this paper.
References
[1] NIST SP 800.82 Rev 3, "NIST SP 800.82 Rev 3 Guide to Operational Technology (ОТ) Security," NIST, Gaithersburg, 2023.
[2] G. Nasby, "Managing SCAD A During a Municipal Water/Wastewater Capital Project," ISA INTECH, pp. 5765, 2023.
[3] Wasson, System Engineering Analysis, Design, and Development, New Jersey: Wiley, 2016.
[4] Laplante, Requirements Engineering for Software and Systems, Boca Raton: CRC Press, 2014.
[5] International Society of Automation, "ISA Standards," 24 April 2024. [Online]. Available: https://www.isa.org/standards-and-publications/isa-standards.
[6] Project Management Institute, Project Management Body of Knowledge 7th Edition, Newtown Square: Project Management Institute, 2021.
[7] PROCORE, "6 Phases of Construction Project Management Explained," 6 December 2023. [Online]. Available: https://www.procore.com/library/construction-project-management-phases.
[8] A. Engel, Verification, Validation, and Testing of Engineered Systems, Hoboken: Wiley, 2010.
[9] P. Coady, "The validation of SCAD A systems," Measurement + Control, pp. 14-19, 1998.
[10] J. Kjelsrud, "A Secure Transition from Industry 3.0 to Industry 4.0 for Manufactures," 1 March 2022. [Online]. Available: https://www.duo.uio.nO/bitstream/handle/10852/95669/l/Thesis_Kjelsrud.pdf.
[11] D. A. Zakoldaev, "Industry 4.0 vs Industry 3.0: the role of personnel in production," in IOP Conference Series: Materials Science and Engineering, Saint Petersburg, 2020.
[12] J. Leng, "Industry 5.0: Prospect and retrospect," Journal of Manufacturing Systems, pp. 279-295, 2022.
[13] International Society of Automation, ISA112 SCAD A Systems, Research Triangle Park, NC: International Society of Automation, 2024.
[14] Li, "A formalization and extension of the Purdue enterprise reference architecture and the Purdue methodology," UMI, Ann Arbor, 1994.
[15] EMU, "Design Constraints," 27 April 2024. [Online]. Available: https://tinyurl.com/EMUITOT.
[16] Claroty, "The Importance of Compensating Controls in Cybersecurity," 6 April 2023. [Online]. Available: https://tinyurl.com/ClarotyCompCont.
Copyright Institute of Industrial and Systems Engineers (IISE) 2025