10. Procedure Automation Lifecycle - Specifications and Design

The specifications and design work process should produce two critical models for each lifecycle instance: the Procedure Specification Model and the Procedure Implementation Model. The Procedure Specification Model defines what the control system needs to accomplish (functional requirements, performance criteria, and operating constraints), while the Procedure Implementation Model details how these requirements will be executed in the actual system (specific control logic, I/O configurations, and hardware assignments).

Note: Think of the Specification Model as the “what we need” blueprint and the Implementation Model as the “how we’ll build it” blueprint.

These models serve as the foundation for the next phase of work - the implementation process. Teams will use these models to develop the actual implementation modules (PLC programs, HMI screens, control algorithms), create comprehensive training materials and system documentation, and establish detailed test plans that verify both individual component functionality and overall system performance.

Industrial Example: For a temperature control loop, the Specification Model would define the setpoint range and response time requirements, while the Implementation Model would specify the PID controller parameters and the exact I/O points used.

10.1 Procedure Specifications and Design

Procedure specifications should be documented in a platform-independent Functional Requirements Specification (FRS) document. The FRS serves as a comprehensive blueprint that defines what the control system must accomplish without specifying the particular hardware or software platform that will implement it.

Definition: A platform-independent FRS describes the required control functions, logic sequences, and performance criteria in generic terms that can be implemented across different control system brands (such as Allen-Bradley, Siemens, or Schneider Electric).

Note: This approach ensures that your control specifications remain valid even if the project switches from one PLC/DCS platform to another during development, and makes future system migrations more manageable.

The Procedure Specification Model should be started by mapping the list of procedures to be automated from the Physical Model (the representation of your actual plant equipment and their relationships). This mapping provides the foundational structure of the Procedure Specification Model.

Note: The Physical Model contains all your field devices, control loops, and equipment - think of it as the digital twin of your physical process.

The model development can be approached in three ways: top-down (starting with high-level operations and breaking them into smaller steps), bottom-up (building from individual device operations upward), or mixed manner (combining both approaches as needed for your specific application).

Industrial Example: In a batch reactor system, top-down would start with “Execute Batch Recipe” and decompose it into phases like heating, reaction, and cooling. Bottom-up would start with individual valve and pump operations and group them into meaningful procedural steps.

The operating staff should be actively involved in creating or reviewing procedure specifications. Their hands-on operating experience provides valuable insights that can supplement the information found in both existing and newly developed procedures.

Why This Matters: Operators work with the control systems daily and often encounter real-world conditions that may not be fully captured in initial procedure documentation. They can identify potential issues with setpoint ranges, alarm limits, or sequence timing that control engineers might miss during the design phase.

Practical Approach: Include operators in procedure review meetings and encourage them to provide feedback on operational feasibility, safety considerations, and any edge cases they’ve encountered during normal plant operations.

An operator’s input is crucial for translating subjective operational descriptions into quantifiable setpoints and operating ranges. For instance, when an operator describes a process as “hot enough” or “running acceptably,” their experience helps define the specific temperature ranges, flow rates, or pressure values that correspond to these qualitative assessments.

Industrial Example: An experienced operator might specify that “hot enough” for a heat exchanger means maintaining outlet temperature between 180-185°C, rather than leaving this as an undefined qualitative target for the control system.

Note: This operator knowledge becomes especially valuable when establishing alarm limits, control deadbands, and acceptable deviation ranges in your control strategy.

The procedure specifications should include a high-level description of the three main work item categories: command (instructions to operators or systems), perform (actual execution steps), and verify (confirmation that actions completed correctly). You’ll also need to document the general logic flow that shows how the procedure moves from step to step, plus any exception conditions (unexpected situations or faults) and how the system should handle them.

Note: Exception handling is critical in control systems since equipment failures or unexpected process conditions can occur at any time during procedure execution.

Industrial Example: An automated procedure requires a pump station to start.

Command: “Start pump station” - This is the high-level instruction sent from the control system (typically from a SCADA system or PLC program).

Perform: “Open discharge valve, then energize pump motor” - The control system executes these steps in sequence. Opening the discharge valve first prevents the pump from starting against a closed system (dead-heading), which could damage the pump or cause excessive pressure buildup.

Verify: “Pump motor run feedback is confirmed” - The system checks for a digital input signal from the motor starter’s auxiliary contacts or current sensing relay to confirm the motor is actually running, not just that the start command was sent.

Exception condition: “Pump motor fault” - This represents any abnormal condition detected by protective devices such as motor overloads, phase loss monitors, or vibration sensors.

Exception handling: “Pause procedure, generate motor faulted alarm” - When a fault occurs, the automated sequence stops to prevent equipment damage or unsafe conditions. The alarm notifies operators through the HMI (Human Machine Interface) so they can investigate and take corrective action.

Note: This structured approach to automation programming ensures safe, predictable operation and helps troubleshoot issues when they occur.

The automation style for each procedure must be clearly documented before implementation. When using State-Based Control (a method where the system operates in distinct modes with specific steps within each mode), you need to identify three key elements: the individual Steps, the different modes of operation, and which steps belong to each operational mode. Once identified, create a step diagram that shows the transitions between states - this visual representation helps track how the system moves from one state to another based on conditions or events.

For sequential control (where operations follow a predetermined order from start to finish), develop a flow diagram that maps out the entire automated procedure execution path. This flowchart should clearly show the sequence of operations, decision points, and any branching logic.

Note: Both documentation approaches serve as essential references during commissioning, troubleshooting, and future modifications to your control system.

Refer to Chapter 5, “Automation Styles” for detailed guidance on selecting and implementing the appropriate control methodology for your specific application.

Interaction between automated procedures should be documented to prevent operational conflicts. An automated procedure (a sequence of control actions that executes without operator intervention) can successfully progress to completion only if all required resources are available to it without conflict.

Definition: Resource conflicts occur when two or more procedures attempt to use the same equipment, I/O points, or process variables simultaneously.

Industrial Example: If one procedure is controlling a pump’s speed setpoint while another procedure tries to start/stop the same pump, the conflicting commands can cause unpredictable system behavior or equipment damage.

Proper documentation should identify which resources each procedure requires and establish clear priority rules or interlocking logic to manage concurrent procedure execution. This prevents scenarios where procedures interfere with each other’s control logic or compete for the same field devices.

When implementing unit-level procedures, resource conflicts must be managed carefully. Consider a scenario where unit procedure “A” requires access to shared equipment “B” (equipment that serves multiple production units). If equipment “B” can only handle one operation at a time and is currently busy serving a request from unit procedure “C”, then procedure “A” must wait or be rescheduled accordingly.

Industrial Example: A shared centrifuge serving multiple batch reactors can only process one batch at a time. If Reactor 1’s procedure needs the centrifuge while it’s already processing material from Reactor 2, the control system must queue or delay Reactor 1’s request.

Note: This coordination is typically handled through equipment arbitration logic in the control system, which tracks equipment states and manages procedure execution priorities.

The specifications for the human-machine interface (HMI) used in automated control procedures must be thoroughly documented. The HMI serves as the primary interaction point between operators and the control system, so proper documentation ensures consistent operation and maintenance. This documentation should typically include:

Note: HMI documentation is critical for troubleshooting, operator training, and system modifications. Without proper documentation, even simple screen changes or alarm additions can become time-consuming tasks.

Industrial Example: In a typical process control application, HMI documentation might cover everything from the main process overview screen layout to specific alarm acknowledgment procedures and data trending configurations.

• The information available for viewing from the automated procedure, such as current state, mode, timing information, alerts, progress indicators, etc.
• Human data entry inputs, such as operating targets, alarm thresholds, manual test result data entry, etc.
• Operator commands such as start request, stop request, mode change requests, alarm response interactions, etc.
• Notifications generated by the automated procedure and other facets of the system require some level of attention. Some examples are shown below.
  • Alarm banners that provide immediate information for events that require immediate attention.
  • Indicators that identify areas of control outside the scope of the current display that indicates the need for attention.
  • Single display that summarizes conditions that require attention, presented in a prioritized fashion.
• Access control: identify applicable users and groups and determine access requirements and limitations for each.

Current control strategies (the logic and algorithms that govern how your system operates) may need modification to meet the requirements of the new automated procedure. These necessary changes should be identified during the specification development phase and handled through the implementation workflow using a proper Management of Change (MOC) process.

Note: Management of Change is a formal procedure that documents, reviews, and approves any modifications to existing control systems before implementation. This ensures safety, maintains system integrity, and prevents unintended consequences.

Industrial Example: If you’re automating a batch reactor that currently uses manual temperature control, you might need to modify the existing PID controller parameters or add new interlocks to work with the automated sequence.

When implementing automation systems, you may encounter situations where the existing process equipment cannot support your control objectives. This typically happens when the current hardware lacks the necessary sensors, actuators, or processing capabilities required for the automated control strategy.

Examples of equipment upgrades might include:

• Adding flow meters or pressure transmitters for better process feedback
• Installing variable frequency drives (VFDs) for precise motor speed control
• Upgrading to smart field devices that support digital communication protocols

Note: Document these equipment requirements clearly, including technical specifications and justification for why the upgrade is necessary to meet the automation goals. Present this information to your project manager or operations team early in the project timeline, as equipment procurement and installation can significantly impact project schedules and budgets.

The key is identifying these gaps during the design phase rather than discovering them during commissioning when changes become much more costly and time-consuming.

10.2 Requirement

Note

The procedure owner shall ensure that specifications for the human interface for the automated procedure are documented.

Note: This documentation should cover both normal operating conditions and emergency scenarios where manual operator intervention may be required.

Industrial Example: For a batch reactor control procedure, HMI specifications would include screen layouts showing temperature and pressure trends, alarm thresholds and their visual/audible indicators, and manual override capabilities for critical control loops.

10.3 Design Implementation Modules

When designing implementation modules, you should use the Procedure Specification Model as your primary framework to structure the modules, while leveraging the detailed design specification as supporting documentation throughout the process.

Note: The Procedure Specification Model provides a systematic approach for defining how control functions should be implemented, including input/output requirements, processing logic, and interface specifications.

Definition: Implementation modules are the individual software components that execute specific control functions within your overall control system architecture.

This dual-document approach ensures that your modules align with both the high-level procedural requirements and the granular technical specifications needed for proper system integration.

The design of implementation modules should be documented in a platform-dependent Detailed Design Specification. This specification must account for the specific control system you’re working with (whether it’s DeltaV, PlantPAx, Experion, etc.) since different platforms have unique limitations and capabilities that directly impact your design choices.

Note: Platform limitations might include maximum number of I/O points per controller, scan time constraints, or memory limitations that affect how you structure your control logic.

This design process requires integrating your procedure automation specifications into three key areas of the overall BPCS (Basic Process Control System - the main control system managing normal plant operations) architecture:

• Hardware configuration: Ensuring your modules fit within the existing controller capacity, network bandwidth, and I/O distribution
• Security requirements: Implementing proper access controls, change management procedures, and cybersecurity measures as defined by your facility’s security policies
• Overall system architecture: Confirming your implementation aligns with established naming conventions, communication protocols, and integration standards already in place

Industrial Example: If you’re implementing a new reactor control module on a DeltaV system, you’d need to verify the controller has sufficient memory for your control logic, adequate spare I/O for your field devices, and that your security settings align with the plant’s role-based access control matrix.

Multiple departments within the plant, such as operations and engineering teams, should participate in reviewing the design implementation modules (the software blocks or function blocks that contain your control logic and configuration).

Why this matters: Operations staff understand the day-to-day process requirements and can catch practical issues that might be missed during the design phase, while engineering teams verify that the technical implementation meets specifications and safety standards. This cross-functional review helps identify potential problems before commissioning and reduces the likelihood of costly modifications during startup.

Design activities may include:

Note: These activities form the core engineering work when developing control systems, from initial concept through implementation and testing.

• System modeling and simulation (creating mathematical representations of physical processes to predict behavior before building hardware)
• Control algorithm development and tuning (designing PID controllers, state-space controllers, or other control strategies and optimizing their parameters)
• Hardware selection and specification (choosing appropriate sensors, actuators, PLCs, or distributed control systems based on process requirements)
• Human-machine interface (HMI) design (developing operator screens and control panels for system monitoring and manual intervention)
• Safety system design and hazard analysis (implementing fail-safes, emergency stops, and conducting risk assessments like HAZOP studies)
• System integration and commissioning (connecting all components, programming controllers, and conducting startup testing)
• Performance validation and optimization (verifying the system meets specifications and fine-tuning for optimal operation)

Industrial Example: For a temperature control loop, this might involve modeling the heat transfer dynamics, tuning a PID controller, selecting RTDs and control valves, designing operator displays, and implementing high-temperature alarms.

• Identify implementation modules and mapping from the Procedure Specification Model.
• Develop architecture and programming guidelines.
• Identify control configuration tools and criteria to best execute the logic

Example: Functional Blocks, Sequential Function Charts (SFCs), etc.

Note: Functional Blocks are reusable program modules that encapsulate specific control logic with defined inputs and outputs, making code more modular and easier to maintain. Sequential Function Charts (also called SFCs or Grafcet) provide a graphical programming method for organizing sequential control processes into steps and transitions - particularly useful for batch operations or state-based control sequences.

Industrial Example: You might use Functional Blocks for PID control routines that can be called multiple times throughout your program, while SFCs are ideal for controlling equipment startup sequences or managing production line operations that follow a specific order of steps.

• Identify existing toolkit/library entities that can be leveraged for automating the procedure.
• Identify procedure specifications that will require coding during implementation because solutions are not already in the toolkit/library. If such an implementation creates a reusable entity, consider making it a part of the toolkit/library.
• Define encapsulation and reuse requirements for all possible scenarios of procedure specifications.

Common Pump Configuration Examples:

Single pump operation without block valve isolation, dual pump operation without block valve isolation, and dual pump operation with block valve isolation.

Note: Block valves (isolation valves) allow individual pumps to be taken offline for maintenance while keeping the system operational. In dual pump setups, block valves provide redundancy and maintenance flexibility that single pump configurations cannot offer.

Industrial Example: A cooling water system might use two pumps with block valves where one pump handles normal load while the second serves as backup, and either can be isolated for service without system shutdown.

• Identify data archival requirements of the automated procedure, including the impact of the individual control strategies involved.
• Consider the impact of the automated procedure on external data repositories: ensure the external resources are sufficiently sized to handle the data load generated by the automated procedure.
• Consider the impact of external data management tasks on the automated procedure. For example, execution timing of set point calculations performed by an external database engine.
• Include capture of metrics as part of the design. For example, save the duration of specific tasks, count the number of times the operator must repeat some task, etc.
• Design implementation modules so execution records and reports can be generated at the level of detail required. For example, recording a setpoint value at the start and end of a step, confirmation from the BPCS that a step was executed.
• Develop a Detailed Design Specification of individual control strategies, complete with data flow diagrams, operational modes, status tags, and interlocks.
  • Identify necessary interactions between the automated procedure and affected control strategies.
  • Identify data values generated by each control strategy used by external resources, such as Key Performance Indicators (KPIs) for Manufacturing Execution Systems, historical trending repositories, etc.
  • Identify communication exchange and receiving requests from the higher level and parallel implementation modules.
• Identify exception conditions and design response mechanisms.
  • Automated response to interlocks.
  • Alarm condition automated response.
  • Resource fault response.
  • Additional automated responses to exception conditions as appropriate.
• Design a consistent operator interface
  • Implement HMI specifications as determined in Section 10.1.
  • Identify how to align logical control objects with the graphical HMI design objects. This allows the reuse of HMI design when control objects are re-used.
  • Design interactive displays with operating targets and application results on the displays to provide situational awareness of the automated procedures.
  • Leverage existing toolkits or library content where possible.
• Develop automation procedural logic design
  • Design the detailed logic for each Control Specification.
  • Leverage existing toolkits or library content where possible.
  • When State-Based Control is used
    • Map the step changes to the predefined mode of operation
    • Design the logic for each Step, including the equipment to be used and pertinent parameter values.
    • Design logic to execute step transitions.
    • Identify step diagrams and transition changes

10.4 Test Plan

A well-conceived test plan ensures that the automated procedures function as specified across different operational states: start-up (initial system energization and sequencing), normal operation (steady-state process control), abnormal operation (fault conditions, alarms, and safety interlocks), and shutdown (controlled process termination and equipment de-energization).

Note: Each operational state presents unique challenges for your control system - start-up sequences must handle equipment initialization in the correct order, normal operation requires maintaining setpoints within acceptable tolerances, abnormal conditions test your alarm logic and safety systems, and shutdown procedures ensure safe process termination without equipment damage.

Test plan development can occur at multiple phases throughout the control system design process, including during the initial specifications identification phase or later during detailed design activities. The test plan uses procedure specifications and testing requirements defined in the project work plan as its foundation for determining what and how to test.

Note: Procedure specifications typically outline the step-by-step operational sequences your control system must execute, while testing requirements define the performance criteria and validation methods needed to verify system functionality.

Industrial Example: For a temperature control loop, your test plan might reference procedure specs that detail the heating/cooling sequence and testing requirements that specify acceptable response times and steady-state accuracy tolerances.

The test plan serves as both a roadmap for testing activities and a record of what was actually tested, including all results and observations. This document should match the level of technical detail found in your system specifications and design documentation - if you have detailed P&IDs (piping and instrumentation diagrams) and control narratives, your test plan should reflect that same level of specificity.

Key Components: Document the specific control loops, interlocks, and sequences being tested, along with expected versus actual performance data. For example, if testing a PID controller, record setpoint tracking accuracy, overshoot percentages, and settling times rather than just “controller works.”

Note: The test plan acts as your audit trail and troubleshooting reference, so include enough detail that another engineer could understand what was tested and why certain results were obtained.

An effective test plan covers:

Scope Definition: Clearly identify which control loops, devices, and systems will be tested. This includes specifying the boundaries of your test (what’s included and what’s not) and any dependencies between different control elements.

Test Objectives: Define what you’re trying to validate - whether it’s verifying setpoint tracking performance, disturbance rejection capabilities, or safety interlock functionality. Each objective should have measurable success criteria.

Test Procedures: Document step-by-step instructions for each test scenario, including initial conditions, input changes to apply, and data collection requirements. This ensures repeatability and consistency across different test runs.

Safety Considerations: Identify potential hazards during testing and establish safety protocols. This is especially critical when testing involves bypassing normal control logic or operating equipment outside normal parameters.

Resource Requirements: List the personnel, equipment, and time needed for testing. Include any special test equipment like signal generators, data loggers, or portable calibrators that may be required.

Pass/Fail Criteria: Establish quantitative benchmarks for evaluating test results, such as acceptable settling times, overshoot limits, or steady-state error tolerances.

Documentation Standards: Specify how test data will be recorded, analyzed, and reported. This includes data formats, calculation methods, and reporting templates to ensure consistent documentation across all tests.

Contingency Plans: Prepare backup procedures for when tests don’t go as planned, including how to safely return systems to normal operation if issues arise during testing.

• How testing will be performed, including identification of personnel performing testing.
  • Personnel performing testing should be independent of Procedure Developer.
  • Personnel skills and training level expected of testers
• Clear articulation of pass/fail criteria for each test performed
  • Document testing failures
  • Determine root cause of failure – procedure specification, coding error, or testing protocol – and appropriate resolution
• Test environment
  • Software platform requirements
  • Live production system
• Consider changing process conditions and how they impact testing results.
• Consider how testing impacts the running process directly and indirectly. - Simulated production system
• Definition of the level of accuracy, or fidelity, of the simulation model
• A detailed plan for developing and using the simulation.
  • Test case examples
    • Execution only by a knowledgeable user (may also have constraints for who can perform certain reviews)
    • The rigor of testing should be commensurate with the potential risks associated with the procedure being tested.
    • Test for unanticipated behavior or interaction (make sure it doesn’t do what it’s NOT supposed to do)
    • Test data entry within the acceptable range and outside the acceptable range.
    • Test boundary conditions and failure modes for appropriate responses.
    • Test abnormal condition handlers.
  • Identification of interactions with other automated procedures and external resources.
    • Identify and test normal procedural dependencies such as modes, states, and data interactions.
    • Identify and test prerequisite and interlock conditions from external resources.
    • Identify and test the impact of the procedure under test on the greater control system.