11. Procedure Automation Lifecycle - Implementation

The implementation work process includes activities for:

Note: Implementation refers to the actual deployment and commissioning of control systems in the field, moving from design phase to operational status. This phase involves translating control logic designs into functioning systems that operators can use to manage industrial processes.

Definition: The work process encompasses all structured activities required to install, configure, test, and validate control systems before they go into production operation.

To achieve a successful implementation, training is required to ensure all applicable personnel are familiar with procedure automation concepts (automated sequences that control industrial processes without manual intervention), the toolkits used for development, developer testing requirements, and applicable programming guidelines. Additionally, the developers should understand the documentation requirements, operations testing plan (testing performed by plant operators to verify system functionality under normal operating conditions), acceptance test requirements (formal tests that must pass before the system is approved for production use), and the installation and commissioning strategy (the planned approach for deploying and starting up the control system).

Note: This comprehensive training approach helps prevent common implementation issues like inadequate testing, poor documentation, or misalignment between development and operations teams.

11.1 Create Implementation Modules

The design documents serve as the technical foundation for implementing your control system. These documents typically include P&IDs (piping and instrumentation diagrams), control logic diagrams, HMI layouts, and equipment specifications that define exactly how the system will function.

Important: All identified stakeholders must formally approve these design documents before any implementation work begins. This approval process ensures that operations personnel, maintenance teams, safety engineers, and project managers all agree on the design approach and requirements.

Why this matters: Starting implementation without proper approvals often leads to costly rework, safety issues, or systems that don’t meet operational needs. The approval step catches potential problems while they’re still easy and inexpensive to fix on paper rather than in the field.

Components from the toolkit are used to streamline the development of implementation modules (the actual control logic that runs on your PLCs or DCS systems). These pre-built tools incorporate proven engineering practices and significantly reduce the amount of custom application code you need to write from scratch.

Benefits include:

  • Reduced costs through faster development cycles
  • Greater consistency across different control systems and projects
  • Improved quality of automated procedures since the toolkit components have been tested and validated
  • Better documentation as standardized components come with established documentation templates
  • Enhanced traceability making it easier to track changes and troubleshoot issues during commissioning and operation

Note: Think of these toolkit components as standardized building blocks - instead of programming a PID controller from scratch every time, you use a pre-tested PID function block that’s been optimized and documented.

This activity encompasses the complete software development lifecycle for automated control systems. It includes writing and configuring code for implementation modules (the core logic that executes control strategies), developing the engineer interface (HMI screens and tools used by control engineers for system configuration and monitoring), creating the operator interface (the primary HMI that plant operators use for day-to-day system control), and implementing version control systems to track changes across all software components.

Definition: Implementation modules are the software components that contain the actual control algorithms, interlocks, and automated sequences that run on the control system hardware (such as PLCs or DCS controllers).

The scope also covers all supporting elements necessary for automated procedures to function properly, including alarm management, data historians, communication drivers, and system diagnostics. Version control ensures that all software changes are tracked, documented, and can be rolled back if issues arise during commissioning or operation.

Testing occurs at two critical levels: individual automated procedure testing (validating each control sequence, interlock, or algorithm independently) and integrated system testing (verifying that all automated procedures work together correctly without conflicts or unexpected interactions). This comprehensive testing approach helps identify issues before the system goes live in production.

The deliverables of this activity are implementation modules that are ready for factory acceptance testing (FAT).

Definition: Factory acceptance testing is the final verification process where control system modules are tested at the vendor’s facility before shipment to ensure they meet all specified requirements and function correctly.

Note: At this stage, the modules should include all programmed logic, configured HMI screens, communication protocols, and safety interlocks as specified in the functional design specification.

11.2 Test Environment Implementation

The test environment can be developed at the same time as the programming and setup of the control system modules (PLCs, HMIs, SCADA components, etc.). This parallel development approach helps reduce overall project timeline. The test environment must be fully completed and validated before any testing activities begin.

Note: The test environment typically includes simulation software, hardware-in-the-loop setups, or scaled physical models that replicate actual plant conditions without risking production equipment.

Test environment implementation is built according to the specific test requirements outlined in the work plan and serves as the foundation for executing all test procedures defined in the test plan. The test environment essentially creates a controlled setting where you can validate system performance, safety interlocks, and control logic without risking production equipment.

Note: The test environment should mirror your actual process conditions as closely as possible, including I/O configurations, communication protocols, and timing constraints that your control system will encounter in the field.

Test environments can differ significantly depending on what resources are available for your specific project. In many cases, you’ll work within the existing plant infrastructure and control systems that are already in place - this means using the same network architecture, hardware platforms, and software versions that the facility currently operates with. However, some projects have the advantage of dedicated test environments that are completely separate from the production systems.

Note: A dedicated test environment allows you to simulate process conditions and test control logic without any risk to ongoing plant operations, which is particularly valuable when implementing new control strategies or testing complex interlocks.

The type of test environment you’ll use often depends on factors like project budget, criticality of the systems being modified, and whether the plant can afford downtime for testing on live equipment.

Test environments can incorporate various simulation approaches depending on your testing needs and available resources. At the most basic level, you might test with no simulation at all using actual hardware. Loop-back testing connects outputs directly back to inputs, allowing you to verify signal paths and basic controller logic without involving the actual process.

Low fidelity simulation uses simplified mathematical models that capture basic process behavior - think of a first-order lag representing a temperature control loop where you’re mainly concerned with timing and general response characteristics. High fidelity process simulators replicate complex plant dynamics with detailed mathematical models that closely mirror real-world behavior, including nonlinearities, delays, and disturbances.

Note: The choice between simulation levels typically depends on what you’re testing - basic I/O verification might only need loop-back, while validating advanced control strategies often requires high fidelity simulation to catch issues before commissioning.

When your test environment includes a simulation model (a mathematical representation of the physical process), a Model Acceptance Test (MAT) is used to verify that this simulation accurately represents the real-world process behavior and meets all the requirements specified in the process design.

Note: The MAT is essentially a validation step that ensures your simulation will behave like the actual plant before you rely on it for testing your control strategies.

The result of this activity is a test environment and infrastructure that meets the requirements for testing the automated procedures as outlined in the project work plan.

Definition: A test environment in this context refers to the hardware and software setup that simulates real-world operating conditions where control systems can be safely validated before deployment.

Note: This infrastructure typically includes simulation software, hardware-in-the-loop (HIL) systems, or scaled process models that allow you to verify your automated sequences without risking actual production equipment or processes.

11.3 Implementation Documentation and Training

Implementation documentation and operations training materials should be produced as part of the implementation work process (not as an afterthought once the control system is already deployed).

Note: This documentation typically includes system architecture diagrams, control logic explanations, HMI screen descriptions, alarm response procedures, and troubleshooting guides. The training materials should cover both normal operations and emergency shutdown procedures.

Industrial Example: For a new PID loop controlling reactor temperature, documentation would include the tuning parameters used, safety interlocks, and step-by-step operator instructions for setpoint changes and manual override procedures.

The documentation and training materials are developed to satisfy the specific requirements outlined in the project work plan. These materials draw from three key sources: the procedure specifications (which define step-by-step operational methods), design documents (including P&IDs, control logic diagrams, and system architecture), and the actual implemented system as built in the field.

Note: This approach ensures that training content reflects both the intended design and any field modifications or deviations that occurred during implementation, providing operators with accurate, real-world guidance for system operation and maintenance.

Training the relevant operations personnel before acceptance testing or installation and commissioning can be conducted using the project test environment. This approach allows operations staff to become familiar with the new control systems, interfaces, and procedures in a controlled setting before the actual equipment goes live.

Benefits: When operations personnel receive hands-on training in the test environment first, they can participate more effectively in acceptance testing (verifying the system meets specifications) and commissioning activities (bringing the system online and validating performance). This pre-training reduces the learning curve during critical project phases and helps identify potential operational issues early.

Note: The test environment should mirror the actual production system as closely as possible, including HMI screens, alarm configurations, and control logic, to maximize training effectiveness.

11.4 Requirement

Note

The procedure owner shall ensure that Implementation documentation and operations training materials will be produced as part of the implementation work process.

Definition: Implementation documentation includes technical specifications, system configurations, wiring diagrams, and commissioning records that document how the control system was installed and configured.

Note: Operations training materials should cover normal operating procedures, alarm responses, maintenance requirements, and troubleshooting steps that plant operators will need to safely and effectively run the system after commissioning.

Both deliverables are critical for successful system handover and long-term operational success, as they provide the technical foundation for ongoing operations and maintenance activities.

11.5 Acceptance Test Execution

Acceptance tests are formal, witnessed evaluations that verify automated procedures work correctly when integrated with the Basic Process Control System (BPCS - the main control system that manages normal plant operations). These tests follow standardized procedures defined in ANSI/ISA-62381-2011, which covers three key testing phases: Factory Acceptance Test (FAT - testing done at the vendor’s facility before shipment), Site Acceptance Test (SAT - testing performed at the actual plant site), and Site Integration Test (SIT - testing that verifies all systems work together properly in the final installation).

Note: The witnessed aspect means that both the vendor and customer representatives must be present to observe and approve the test results, ensuring accountability and proper documentation for regulatory compliance.

The testing of automated procedure exception handling should be performed as part of the FAT (Factory Acceptance Test - the testing phase conducted at the manufacturer’s facility before equipment shipment). The FAT should ensure that the interactions between the automated procedure being tested and other procedures or equipment are validated under both normal operating conditions and upset conditions (abnormal situations like equipment failures, process deviations, or emergency scenarios).

Note: Exception handling refers to how the control system responds when something goes wrong or outside normal parameters - for example, what happens when a sensor fails, a valve doesn’t respond, or process variables exceed their setpoints during an automated sequence.

Testing Focus: Verify that your automated procedure can properly communicate with other control loops, safety systems, and equipment packages, and that it fails safely or transfers control appropriately when exceptions occur.

During testing, the relevant operations personnel should walk through procedures using a test environment (a controlled setup that mimics the actual process without affecting production) to ensure the procedures provide the expected operation. This walkthrough allows operators to verify that each step in the control sequence functions as intended and helps identify any gaps or unclear instructions before implementation on the live system.

Note: Testing procedures in a simulated environment is critical for validating control logic and operator interfaces without risking equipment damage or production downtime.

11.6 Installation

The installation consists of loading the automated procedures into the BPCS (Basic Process Control System - the main control system that manages normal plant operations) at the plant site. This may be part of a new BPCS installation or an addition to an existing BPCS.

Note: The loading process typically involves downloading control logic, operator displays, and alarm configurations from the engineering workstation to the plant’s distributed control system or PLC platform.

The SAT (Site Acceptance Test) should validate that the new automated procedures will successfully communicate with the plant BPCS (Basic Process Control System - the main control system managing your plant’s processes) and integrate properly with both the core system and all connected peripherals.

Note: This communication validation typically includes testing data exchange protocols, alarm handling, and command execution between the automated procedures and your existing control infrastructure. The peripheral integration testing should cover field devices like sensors, actuators, and HMI (Human Machine Interface) stations that operators interact with daily.

The System Integration Testing (SIT) should validate that the new automated procedures integrate successfully with the overall control program (the main PLC/DCS logic that coordinates all plant operations). Parts of the SIT can be done in parallel with the Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT).

Note: During SIT, you’re essentially testing how well your new automation communicates with existing systems - checking data exchange, interlocks, alarm handling, and sequence coordination between the new and existing control logic.

11.7 Commissioning

The commissioning activity is performed or overseen by the operating organization (the end user who will run the system day-to-day) and includes verification that the automated procedures work correctly according to the project requirements and specifications. This verification process ensures that all control logic, interlocks, and automated sequences function as intended before system handover.

Note: Project team members who are familiar with the automated procedures—including control engineers, programmers, and system integrators—should be available during commissioning to provide technical support, troubleshoot issues, and answer questions about the control system design and implementation.

Industrial Example: During a new batch reactor commissioning, the operating organization would verify that automated startup sequences, safety interlocks, and process control loops all perform according to the original project scope before accepting the system for production use.

11.8 Procedure Audit

A procedure audit examines the management systems and work processes that support automated procedures used to achieve Process Automation Objectives (the specific goals defined for automating plant operations). This audit evaluates whether these work processes are adequate to properly implement the automation system by reviewing how procedures are executed and checking them against their specifications.

Definition: Process Automation Objectives are the measurable goals set for an automation project, such as improving safety, reducing operator workload, or increasing process efficiency.

The procedure audit also compares the actual automation work processes against the standards outlined in the procedure automation philosophy document (the high-level strategy document that defines how automation should be approached for this specific project lifecycle). This comparison helps identify gaps between what was planned and what is actually being implemented in the field.

Note: This type of audit is particularly important during commissioning and startup phases when you need to verify that your automated procedures work as designed before full production begins.

A procedure audit is typically conducted following project completion to evaluate whether the original business case for automating control procedures has been met or surpassed. This audit serves as a performance validation step, comparing actual results against the projected benefits outlined during the initial justification phase.

Note: The business justification usually includes metrics like reduced operator workload, improved process consistency, decreased response times, or enhanced safety performance.

The procedure audit should also generate actionable feedback for the Procedure Automation Strategy work process. This feedback loop enables continuous improvement of both the overall automation strategy and the associated tools and methodologies used in future projects.

Definition: The Procedure Automation Strategy work process refers to the systematic approach an organization uses to identify, prioritize, and implement automated control procedures across their operations.

By analyzing what worked well and what didn’t during implementation, control engineers can refine their approach for subsequent automation projects, leading to more effective procedure designs and better alignment with operational objectives.