8. Procedure Automation Strategy - Company Resources

The development of a Procedure Automation Strategy depends significantly on having the right resources available from your plant or operating company. These resources serve as your toolkit and reference guide - they provide standardized guidelines for every phase of procedure automation work and give you consistent tools for designing, implementing, and maintaining automated procedures.

Definition: A Procedure Automation Strategy is your systematic approach to determining which manual procedures should be automated, how to automate them, and how to maintain them over time.

Note: Think of these resources as your automation “playbook” - they ensure that whether you’re working on a batch process, continuous control loops, or safety interlocks, you’re following proven methods and using compatible tools that other engineers in your organization can understand and maintain.

The following sections outline the essential resources that should be part of your organization’s automation resource pool. Having these standardized resources available will make your automation projects more efficient and help ensure consistent results across different systems and applications.

8.1 Procedure Automation Philosophy

8.1.1 Introduction

The procedure automation philosophy serves as a technical document designed for project engineers and managers, defining how automated processes should be implemented and maintained within control systems. This philosophy document must align with the organization’s broader business objectives to ensure successful deployment and achieve the expected operational benefits.

Note: A procedure automation philosophy typically outlines standards for alarm management, operator interfaces, control logic design, and safety system integration - essentially serving as the technical roadmap for how your plant’s automation systems should function together.

Key Point: Without proper alignment to business goals (such as improved safety, reduced downtime, or increased throughput), even well-designed automation systems may fail to deliver measurable value to the organization.

The procedure automation philosophy establishes consistent behavior for automated procedures across different lifecycle instances (such as development, testing, and production environments). This consistency is critical for reliable system operation and encompasses several key areas:

Definition: Lifecycle instances refer to the different phases or environments where your control system operates - from initial development and commissioning through normal production operation and maintenance phases.

Note: Maintaining consistency between these instances prevents unexpected behavior when procedures are deployed from testing to production environments, reducing the risk of process upsets or safety incidents.

This consistency manifests in multiple important facets, including:

• Identify and assign ownership of engineering, implementation, maintenance, performance, and auditing of the automated procedure.
• Automation style consistency is important since it reduces:
• The time required for operators to learn how to use new automated procedures
• The opportunity for confusion and errors during operations
• The engineering costs to develop and maintain the automated procedures.
• Behavior from an operator perspective.
• Operator interface.
• The architecture of the hardware and software.
• Software and configuration design.
• Reuse of components and entire procedures.
• Alarm and alert identification, design, and management.

The procedure automation philosophy content is designed to be system-agnostic and equipment-independent (meaning it doesn’t rely on specific hardware or software platforms). This approach allows for broader implementation across different projects, whether you’re working with DCS systems (Distributed Control Systems), PLCs (Programmable Logic Controllers), or other control platforms.

Practical Benefit: By keeping the philosophy separate from specific equipment constraints, you can apply the same fundamental automation principles whether your project uses Honeywell, Emerson, Siemens, or any other control system vendor. This standardized approach reduces project-specific customization and improves consistency across your automation designs.

8.1.2 Requirement

Note

As defined in Table 10, the Executive Sponsor shall ensure that the procedure automation philosophy is documented and periodically updated.

Definition: The procedure automation philosophy is a foundational document that outlines the strategic approach, standards, and guidelines for implementing automated control systems across the facility or organization.

Note: This philosophy document typically includes decision criteria for what processes should be automated, the level of automation desired (manual, semi-automatic, or fully automatic), and the standard practices for control system design and implementation. Regular updates ensure the philosophy stays aligned with evolving technology, safety requirements, and operational goals.

8.1.3 Alignment with Business Goals

The procedure automation philosophy document serves as a foundational guide that aligns automation strategies with overall business objectives. Control engineers and automation specialists responsible for developing and maintaining this document must collaborate closely with business leaders to fully understand the company’s strategic goals and operational priorities.

Definition: A procedure automation philosophy document outlines the systematic approach for automating plant operations, including which procedures to automate, the level of automation, and the rationale behind these decisions.

This philosophy document also functions as a critical input during the business planning phase. It provides essential data that influences major business decisions including facility location selection, process technology choices, staffing requirements for operations and maintenance teams, and overall risk management strategies. By incorporating automation considerations early, companies can better understand how procedure automation will impact both the initial plant design and long-term operational performance.

Note: This collaboration typically involves multiple rounds of review and refinement as business requirements and technical constraints are balanced against each other.

A comprehensive and well-structured procedure automation philosophy document streamlines this collaborative process by providing clear automation guidelines and technical requirements upfront. This early availability of structured information helps reduce the number of revision cycles needed during business planning, ultimately accelerating project timelines and improving decision-making quality throughout the plant development process.

8.1.4 Requirement

Note

The Executive Sponsor shall ensure that the procedure automation philosophy document supports the business goals.

Definition: A procedure automation philosophy document is a high-level strategic document that defines the company’s approach to automating manual processes, including which procedures should be automated, the level of automation desired, and the standards to be followed.

Note: This document serves as the foundation for all automation projects and helps control engineers understand the business context behind automation decisions, ensuring that technical implementations deliver measurable business value rather than just technical sophistication. Example 1 Typical business drivers include reducing operational costs by X%, minimizing product variability (achieving consistent quality specifications), prioritizing safe operation as the top objective, and maintaining high unit availability (maximizing uptime and production capacity). Automated control procedures can be implemented to help achieve these operational goals.

Note: Unit availability refers to the percentage of time a production unit operates at or above minimum acceptable capacity, directly impacting overall plant efficiency and profitability. When cost is the primary constraint in your control system design, simplicity becomes your best strategy for staying within budget. Complex control architectures with multiple feedback loops, advanced algorithms, or specialized hardware components can quickly drive up both initial implementation costs and long-term maintenance expenses.

Practical Approach: Start with basic PID controllers (proportional-integral-derivative controllers that form the backbone of most industrial control systems) before considering more sophisticated options like model predictive control or adaptive controllers. A well-tuned PID can often achieve acceptable performance at a fraction of the cost.

Cost Considerations: Simple control schemes typically require fewer sensors, less computational power, and more straightforward programming. This translates to lower hardware costs, reduced commissioning time, and easier troubleshooting for plant operators. Additionally, standard control components are more readily available and have established supply chains, avoiding the premium pricing of specialized equipment.

Note: While keeping things simple helps control costs, ensure your simplified design still meets the essential safety and performance requirements. Sometimes a slightly more complex solution upfront can prevent costly process upsets or equipment damage down the line. Safety considerations drive the fundamental philosophy behind automated control procedures in industrial systems. When designing control logic, safety must be the primary concern that shapes every decision about how automated sequences will execute.

Key Principle: Automated procedures should be designed with fail-safe operation as the default behavior. This means that if any component fails or an unexpected condition occurs, the system should automatically move to a safe state rather than continuing operation.

Industrial Example: In a chemical reactor control system, if a temperature sensor fails, the automated procedure should immediately initiate a controlled shutdown rather than assuming the temperature is acceptable. The control logic prioritizes safety over production efficiency.

Note: This safety-first approach influences programming structure, alarm prioritization, and interlock design. Emergency stops, safety interlocks (devices that prevent unsafe operations), and fault detection routines are built into the control architecture from the beginning, not added as afterthoughts.

The automated procedure philosophy ensures that operators can trust the system to make safe decisions even when they cannot directly supervise every aspect of the process.

8.1.5 Selection of Standards and Guidelines

The procedure automation philosophy should incorporate industry, organization, and business unit standards and guidelines. This means aligning your automation strategy with three key layers of requirements: industry-wide standards (such as ISA-88 for batch control or ISA-95 for manufacturing operations management), your company’s internal engineering standards and best practices, and the specific operational requirements of your particular business unit or plant.

Note: A well-defined automation philosophy serves as the foundation for all control system design decisions and ensures consistency across projects while meeting regulatory and operational requirements.

The creation of a procedure automation philosophy involves surveying, studying, and selecting an appropriate list of standards and guidelines to be followed. This philosophy document serves as the foundation for all automation projects throughout their entire lifecycle (from initial design through commissioning and maintenance).

Definition: An automation philosophy is essentially a company’s rulebook that defines how control systems should be designed, implemented, and maintained consistently across all projects.

Typical selection criteria for choosing these standards and guidelines include:

Note: The philosophy document becomes your go-to reference during system design, helping ensure consistency between different projects and engineers. Each new automation project (lifecycle instance) should reference and follow the established philosophy to maintain standardized practices across the organization.

• Constraints like environmental and safety may drive additional automation
• Whether each referenced standard or guideline is mandatory or optional.
• The degree to which a standard or guideline addresses automated procedures.
• The degree to which an automated procedure, or the work processes related to it, impacts the work processes or deliverables addressed in a standard or guideline.

When conducting this activity, control engineers typically need to consider several categories of standards and guidelines that govern industrial automation systems:

Safety Standards: These include functional safety requirements like IEC 61508 (overall functional safety) and IEC 61511 (process industry safety), which define how to implement Safety Instrumented Systems (SIS) and calculate Safety Integrity Levels (SIL ratings that indicate the reliability of safety functions).

Communication Protocols: Standards such as Modbus, Ethernet/IP, and PROFINET that define how field devices, controllers, and supervisory systems exchange data across industrial networks.

Equipment and Installation Standards: Guidelines like NEMA (National Electrical Manufacturers Association) enclosure ratings for environmental protection, and NEC (National Electrical Code) requirements for proper electrical installation practices.

Process Industry Standards: Specifications from organizations like ISA (International Society of Automation) that cover instrument symbols, loop diagrams, and control system documentation practices.

Quality and Performance Standards: Requirements for system reliability, response times, and measurement accuracy that ensure the control system meets operational needs.

Note: These standards often overlap and reference each other, so it’s important to verify compatibility when designing systems that must comply with multiple requirements. Local regulations may also impose additional standards beyond international ones.

• Government regulations, industry standards, organization standards, and pre-existing contracts.
• Company philosophy regarding safety and reliability
• Business unit philosophy (more detailed than a Company philosophy) regarding expectations for procedure automation, such as protecting workers from hazards, protecting the facility, and protecting the public.
• Company or business unit procedures for project execution/audit, quality/change management, and system governance.

8.1.6 Process Automation Objective

Within the constraints defined by business goals, a procedure automation philosophy is evaluated based on how well the automated procedures fulfill the philosophy’s Process Automation Objectives. These objectives serve as high-level guidelines and performance metrics (measurable targets for system performance) that must align with the project’s or plant’s operating discipline.

Definition: Process Automation Objectives are strategic targets that define what the automated system should achieve, such as safety targets, production rates, or quality standards.

Note: The operating discipline refers to the established procedures, standards, and practices that govern how the facility operates on a day-to-day basis. Your automation philosophy must work within these existing operational frameworks rather than conflict with them.

Process Automation Objectives should be both specific to each individual process (tailored to the unique requirements, constraints, and performance metrics of that particular system) and applied consistently across a company or business unit basis to ensure standardized approaches and unified performance targets.

Note: This dual approach helps maintain process-specific optimization while enabling enterprise-wide coordination and benchmarking.

Example 1: For example, while a temperature control loop for a reactor might have specific settling time requirements, the overall control strategy should align with company-wide standards for alarm management, operator interfaces, and safety protocols.

At the company level, the expectation is to implement automated startup procedures for fired heaters (furnaces used to heat process streams) and to use automated transitions when switching between different product grades. This means relying on control system logic rather than manual operator interventions for these critical operations.

Note: Automated grade transitions help maintain consistent product quality and reduce the risk of off-specification material during changeovers between different product types or specifications.

Example 2: Use automated procedures to minimize complexity for the operator and associated risks.

Implementing automated control sequences reduces the cognitive load on plant operators while simultaneously decreasing the probability of human error during critical operations. Automated procedures should handle routine tasks, complex multi-step sequences, and safety interlocks without requiring constant operator intervention.

Definition: Cognitive load refers to the mental effort required to process information and make decisions during plant operations.

Industrial Example: Instead of requiring an operator to manually open/close 12 valves in a specific sequence during startup, program the DCS (Distributed Control System) or PLC to execute this sequence automatically with a single operator command, including built-in timing delays and safety checks between each step.

Note: While automation reduces operational complexity, ensure operators maintain situational awareness and can intervene manually when necessary. Include clear status indicators and alarm management to keep operators informed of automated process states.

Example 3 Use automated procedures to achieve consistency of product and operation.

Automated procedures help eliminate variability that comes from manual operations, ensuring that each production cycle follows the exact same sequence of control actions. This is particularly important in process control where small deviations in timing, setpoints, or operating sequences can lead to product quality issues or safety concerns.

Industrial Example: Instead of having operators manually adjust valve positions and temperature setpoints during a batch process, implement programmed logic controller (PLC) sequences that automatically execute these steps at predetermined times with precise values.

Note: Consistency through automation also improves troubleshooting since you can eliminate operator variability as a potential cause when investigating process deviations. This makes root cause analysis more straightforward and data-driven.

Example 4: Use automated procedures to relieve operators from mundane tasks, freeing them up for higher value activities.

Implementing automation through programmed control sequences can handle repetitive, routine operations that would otherwise require constant operator attention. This includes tasks like routine valve cycling, scheduled equipment starts/stops, or periodic data logging. By automating these mundane functions using PLC logic or DCS automation blocks (distributed control system programming modules), operators can focus their expertise on more critical activities such as process optimization, troubleshooting abnormal conditions, or strategic decision-making.

Industrial Example: Instead of having an operator manually start cooling pumps every hour, a timer-based automation sequence can handle this task while the operator monitors overall plant performance and responds to alarms.

Note: The key is identifying which tasks are truly routine and predictable versus those requiring human judgment and situational awareness.

Example 5: Requirements for operational resiliency to, and recovery from, abnormal events by using automated procedures.

This example focuses on designing control systems that can maintain stable operation during unexpected disturbances and automatically return to normal operation afterward. Operational resiliency refers to the system’s ability to continue functioning safely even when facing equipment failures, process upsets, or external disturbances that fall outside normal operating conditions.

Key Components:

Automated Recovery Procedures: Pre-programmed control logic that executes predetermined response sequences when abnormal conditions are detected. These procedures should be designed to stabilize the process without requiring immediate operator intervention.

Abnormal Event Detection: Implementation of monitoring systems that can identify deviations from normal operation through alarm management, statistical process monitoring, or model-based fault detection techniques.

Graceful Degradation: The control system should be capable of maintaining essential functions even when some components fail, potentially operating at reduced capacity rather than complete shutdown.

Industrial Example: In a distillation column, if the main temperature sensor fails, the control system automatically switches to a backup sensor or uses inferential control based on pressure and flow measurements to maintain product quality until maintenance can replace the failed sensor.

Note: Recovery procedures must be thoroughly tested during commissioning and should include clear escalation paths to operators when automated recovery is insufficient or fails.

Example 6: Portability of procedure automation to other similar process units within the enterprise.

When developing automated control procedures, design them so they can be easily transferred and implemented across multiple similar process units throughout your facility or company. This means writing code and configuring logic that isn’t hardcoded to specific equipment tags or unit-specific parameters.

Key Considerations: - Use standardized naming conventions for instruments and equipment across units - Create modular code blocks that can accept different input/output assignments - Develop template-based approaches for common control sequences - Document equipment differences between units that may require procedure modifications

Industrial Example: If you develop a reactor startup sequence for Unit 1, structure it so the same logic can be applied to Units 2 and 3 by simply changing the instrument tag references and unit-specific setpoints, rather than rewriting the entire procedure from scratch.

This approach reduces engineering time, minimizes errors during implementation, and ensures consistent operation across your plant’s similar process units.

Maintain the unit’s safety envelope (the defined operational boundaries and protective limits) to ensure safe facility operation under all operating conditions. The safety envelope encompasses critical parameters such as pressure limits, temperature ranges, flow boundaries, and emergency shutdown thresholds that must never be exceeded.

Control Engineering Context: As a control engineer, you’ll typically implement this through configured safety interlocks, alarm setpoints, and protective control logic in your DCS (Distributed Control System) or safety instrumented systems. These systems continuously monitor process variables and automatically take corrective action when approaching safety limits.

Note: Safety envelope maintenance requires regular validation of trip points, functional testing of safety systems, and verification that all protective devices respond within acceptable time limits during routine safety system testing.

8.1.7 Roles and Responsibilities

Building an effective process automation strategy requires collaboration between multiple organizational roles, each with distinct responsibilities for different aspects of the implementation. While Table 10 provides detailed role descriptions (reference appears to be missing from this document), the key principle is that organizations have flexibility in how they assign these responsibilities. Depending on the project scope and available resources, a single experienced individual may handle multiple roles, or dedicated teams can be assigned to each function.

Note: The procedure automation philosophy document should clearly define which roles are involved in your specific project and establish guidelines for how these roles will coordinate and communicate throughout the automation lifecycle.

Industrial Example: In a smaller facility, a senior controls engineer might serve as both the system architect and commissioning lead, while larger plants typically assign separate teams for design, implementation, testing, and maintenance phases.

The success of any automation strategy depends on having clear role definitions upfront and ensuring all participants understand their responsibilities and interfaces with other team members.

The personnel assigned to each role in the automation project should be identified and documented before the project begins. These team members need to participate from the initial design phase through commissioning and operation to maintain consistency throughout the entire automated procedure’s development and implementation.

Note: This continuity is critical because automated procedures often require iterative refinement based on real-world performance, and having the same engineers involved ensures that design intent and operational knowledge are preserved across all project phases.

Definition: Automated procedure lifecycle refers to the complete development process from initial design and programming through testing, commissioning, operation, and eventual system updates or decommissioning.

Control System Roles and Responsibilities

This table outlines the key roles involved in control system projects and their primary responsibilities. Understanding these roles is essential for effective project coordination and communication.

System Integrator: Responsible for combining individual control components, devices, and subsystems into a unified, functional control system. They handle hardware integration, software configuration, and ensure all components communicate properly through field networks (like Ethernet/IP or Profibus).

Control Engineer: Designs and implements control strategies, develops control logic, performs loop tuning (adjusting PID parameters for optimal performance), and creates functional specifications. Also responsible for HMI (Human Machine Interface) design and alarm management.

Project Manager: Oversees the entire control system project from initiation to completion, manages resources, timelines, and budgets. Coordinates between different engineering disciplines and maintains communication with stakeholders.

Commissioning Engineer: Validates that the installed control system operates according to design specifications through systematic testing. Performs loop checks, functional testing, and system performance verification before handover to operations.

Maintenance Technician: Handles routine maintenance, troubleshooting, and repair of control system components. Performs calibration of field instruments, replaces faulty devices, and ensures system reliability during operation.

Operations Personnel: End users who interact with the control system daily through operator stations and HMIs. They monitor process variables, respond to alarms, and make operational adjustments within defined parameters.

Note: In smaller projects, one person may fulfill multiple roles, while larger projects typically require dedicated specialists for each function.

Role Name	Responsibilities	Example Job Titles in Industry
Executive Sponsor	Responsible to authorize the scope of procedure automation activities.	Offshore Installation Manager Refinery Manager Plant Manager Building Manager
Technical Reviewer	Responsible to ensure that procedures reflect the true and complete scope of the applicable technical, management control, and design basis the procedure is designed to implement. Technical reviewers often serve in other roles, such as Operating Staff, Trainer, Procedure Writer and Procedure Developer.	Process Engineer Process Control Engineer Process Specialist
Procedure Owner	Responsible to have a controlled production system that ensures procedures are correct, usable, and available when needed. The Procedure Owner has the ultimate responsibility for procedure development, revision, review, validation, and approval of the procedures assigned to the team. The Procedure Owner is responsible for leading the procedure team, setting priorities, and effectively interfacing with Executive Sponsor to provide high quality procedures for the Operations Staff. A Procedure Owner has operations experience.	Technical Advisor Run Plant Engineer Operations Support Supervisor
Procedure Writer	Responsible to develop procedures that provide specific instructions for task performance and to use the facility’s procedure writer’s guide to present those instructions in an easy-to-follow manner. Responsible for formatting, wording, consistency, and structure of a procedure.	Process Specialist Operations SME Senior Operator on Special Assignment Operations Specialist
Operating Staff	Responsible to use procedures appropriately and to understand their significance in maintaining a disciplined, safe operation. Responsible for procedure validation, for performing the procedure as it is automated and ensuring procedures are executed correctly. If the procedure cannot or should not be performed as automated, then the user has the responsibility to stop procedure execution and initiate changes to the procedure. The Operating Staff individual is the subject matter expert on using the procedure and is the first line of defense to ensure procedure quality and usability. The valuable insight in the tasks being performed by the Operating Staff ranges widely, covering operating experience and operational data that are needed to develop best practice procedures. Their perspective is needed for walk-downs, walk-throughs, and identifying obstacles and cautions. They may have access to extraordinary documentation beyond the unit’s engineering documentation. They bring accuracy to any detailed procedure planning documents, for example, Process Step transition diagramming.	Process Operator Safety Personnel Mechanic Operation Foreman Operations Supervisor
Application Developer	Responsible to provide automated procedures. This includes: Review of procedures with procedure writer to ensure it can be automated as written (e.g., sufficient details are provided so a BPCS can accurately make decisions in lieu of an operator). Interface with other specialists, e.g., safety system engineers, equipment specialists, to develop associated automation functions. Automate and test automated procedures. Maintain procedure automation toolkits.	Control Systems Engineer (CSE) Automation Engineer Application Engineer Automation Professional (CAP)
Independent Engineering Reviewer	Responsible for participating in design, test plan, load plan and load test plan reviews.	Process control engineer Project Engineer Process specialist Quality Assurance Engineer
Independent Tester	Responsible to execute the test plan, load plan and load test plan for a procedure or procedure system. It is important that the Independent Tester role not be performed by someone involved with the design and implementation of the procedure to provide an independent test of the procedure. Trainers are a good source of independent testers. An Independent Tester should be assigned considering: a. Risks, demands, & complexities of the task(s) b. Skills, qualifications, proficiency, experience, fitness, and attitude c. Opportunity for assigned individuals to review processes and procedures before the testing.	Operator on Special Assignment Operating Staff
Trainer	Responsible to develop training tools around the unit’s procedures and execute procedures for training purposes. A trainer can be a valuable source of feedback during procedure development.	Technical Advisor Operations Specialist

These roles are recommended for developing and maintaining accurate control procedures throughout the system lifecycle. Complete and accessible documentation of fundamental system information (including P&IDs, control logic diagrams, and equipment specifications) must be readily available to the entire team, with the Procedure Writer requiring primary access to ensure consistency and accuracy.

Note: The Procedure Writer typically needs access to baseline documents like loop sheets, instrument datasheets, and operational parameters to create effective step-by-step procedures that operators can safely follow during normal and emergency conditions.

8.1.8 Review Cycles

The procedure automation philosophy establishes a structured review process that aligns with your organization’s engineering standards and addresses every phase of an automated procedure’s development lifecycle (from initial concept through implementation and maintenance). Each work process within this lifecycle requires its own dedicated review cycle that examines both high-level system concepts and detailed technical implementation.

Definition: The lifecycle typically includes phases like requirements gathering, design, programming, testing, commissioning, and ongoing maintenance.

Note: Review cycles should be proportional to complexity - simple interlocks might need basic peer review, while complex batch sequences require multi-disciplinary design reviews involving process, control, and safety engineers.

Review definitions should clearly specify which team members will participate in the review (such as lead engineers, operations staff, safety personnel, and project managers), state the specific purpose of each review phase, and provide concrete examples of what needs to be checked during that review. Review milestones should be established at regular intervals throughout the project lifecycle to catch potential issues early before they become costly problems.

Note: Early detection of issues through structured reviews is especially critical in control system projects, where problems discovered during commissioning or startup can lead to significant delays and safety concerns.

Example: A P&ID review might involve process engineers checking flow logic, control engineers verifying instrument specifications, and safety engineers confirming interlock sequences are properly represented.

Just like in general software development, finding and fixing problems early in a control system project will save both time and money. When issues are caught during the design or simulation phase, they typically require only software changes or minor hardware adjustments. However, problems discovered after commissioning (when the system is already installed and running) can be extremely costly to resolve.

Industrial Example: Discovering a PID tuning issue during offline simulation might take a few hours to correct, but finding the same problem during plant startup could mean days of production downtime while engineers troubleshoot and retune the controllers on-site.

The cost escalation follows a predictable pattern - design phase corrections might cost hundreds of dollars, while field modifications during commissioning can cost thousands, and post-startup fixes can reach tens of thousands when factoring in lost production time.

8.1.9 Requirement

Note

The Executive Sponsor shall ensure that the procedure automation philosophy defines a review process that follows the organization’s standards and covers each part of an automated procedure’s lifecycle.

Definition: The procedure automation philosophy is the organization’s formal framework that defines how automated control procedures are developed, implemented, and maintained throughout their operational life.

Note: The lifecycle typically includes phases such as design specification, programming/configuration, testing and validation, commissioning, operation, and eventual decommissioning or modification of automated procedures.

Industrial Example: In a manufacturing plant, this might involve automated startup sequences for equipment where each phase (from initial programming through final operator training) follows documented review checkpoints to ensure safety and reliability standards are met.

8.1.10 Definition of Metrics

The procedure automation philosophy establishes specific metrics that operators and engineers use during day-to-day operations to verify whether each automated procedure is meeting its intended goals. These metrics act as measurable indicators of system performance and should be defined with sufficient detail and specificity to ensure consistent calculation across different shifts, operators, and time periods.

Definition: Metrics in this context are quantifiable measurements such as cycle times, throughput rates, error frequencies, or deviation from setpoints that directly reflect how well an automated procedure is performing.

Note: Clear metric definitions are crucial because they eliminate ambiguity in performance evaluation and enable reliable trending and comparison of automation effectiveness over time. Without this specificity, different personnel might calculate the same metric differently, leading to inconsistent performance assessments.

Metrics serve as key performance indicators (KPIs) to evaluate how well your automated control procedures are functioning during plant operations. These measurements help you track both utilization rates (how often the automation is actually being used) and effectiveness (how well it’s achieving the desired control objectives).

Best Practice: Establish target values for each metric during the project implementation phase, before the system goes live. This gives you clear benchmarks to measure against once operations begin.

Note: During ongoing operations, expect to adjust both your metrics and target values as part of regular operational audits. Real-world performance data often reveals the need to fine-tune what you’re measuring and what constitutes acceptable performance levels.

Industrial Example: If you’re measuring the effectiveness of an automated temperature control loop, you might track metrics like settling time, overshoot percentage, and steady-state error, with targets based on process requirements and initial commissioning results.

These performance metrics can be used to quantify the effectiveness of manual operations and provide data-driven justification for implementing automated control systems.

Note: When evaluating manual procedures, focus on metrics like cycle time, error rates, operator workload, and consistency. These baseline measurements help build a business case by demonstrating where automation can reduce variability, improve throughput, or enhance safety compared to human-operated processes.

Annex A contains examples of using metrics (quantitative performance measurements like response time, overshoot, and steady-state error) with automated procedures. These examples demonstrate how to integrate measurement data into your control system’s automated sequences for better process monitoring and decision-making.

Note: These metrics are typically collected from your HMI, SCADA system, or directly from controller memory to evaluate how well your automated procedures are performing in real-time.

8.1.11 Procedure Execution Data Collection

The procedure automation philosophy should guide how we handle process data logging, archival, and maintenance activities. Key topics to address include identifying which data points to capture from the process, determining how frequently to collect this data (sampling rates), establishing storage duration requirements, defining data access security protocols, and selecting appropriate data warehouse locations.

Definition: A procedure automation philosophy is the overarching strategy that defines how automated systems will be implemented and managed across your facility.

Additional considerations should be included based on your specific process requirements and regulatory environment. Common applications for this stored process data include verifying that your automation systems are performing as designed, creating historical trends for troubleshooting equipment issues or implementing predictive maintenance strategies, and generating reports to meet regulatory compliance requirements.

Industrial Example: In a chemical plant, you might log reactor temperature every 30 seconds for real-time control, but only archive hourly averages for long-term trending while maintaining critical alarm data indefinitely for regulatory audits.

Note: Consider your plant’s data infrastructure capacity when determining sampling rates and storage requirements, as high-frequency data collection can quickly consume storage resources.

8.1.12 Operational Audit Guidelines

The procedure automation philosophy should establish clear audit guidelines that specify which roles are responsible for conducting operational audit work processes. Operational audits serve as an objective evaluation tool to assess whether automated procedures are achieving their intended business goals and Process Automation Objectives (PAOs - the measurable targets set for automation performance like improved efficiency, reduced downtime, or enhanced safety). These audits also help determine how operations staff are actually utilizing the automated procedures in practice, or identifying cases where they may be bypassing or underutilizing them.

Note: Process Automation Objectives typically include metrics such as cycle time reduction, error rate minimization, or throughput improvement that were established during the initial automation design phase.

Industrial Example: An audit might reveal that operators are manually overriding an automated startup sequence because they lack confidence in the system, indicating a need for additional training or system refinement rather than a technical failure.

Effective procedure automation operational audits use both metrics and targeted questions to understand how automated procedures are actually being used and perceived by different teams involved in the operational workflow. Metrics provide the quantitative data (measurable numbers like cycle times, error rates, downtime frequency), while audit questions gather qualitative insights (opinions, experiences, and subjective feedback) that give you a completely different perspective on system performance.

Key Distinction: Quantitative metrics tell you what is happening in your automated systems, but qualitative questions reveal why it’s happening and how operators and stakeholders actually feel about the automation’s effectiveness.

Industrial Example: Your HMI (Human-Machine Interface) logs might show 95% uptime, but operator interviews could reveal that the remaining 5% downtime always occurs during critical production shifts, making the impact much more significant than the metric alone suggests.

This dual approach ensures you’re not just looking at system data in isolation, but also understanding the human factors and organizational dynamics that affect how well your automation actually serves the operation.

The operational audit guidelines within the procedure automation philosophy should specify how often audits need to be conducted (frequency), what systems and processes will be examined (scope), and provide a detailed checklist of required inspection items and investigation points.

Note: These guidelines ensure consistent evaluation of your automated control systems and help identify potential issues before they impact plant operations.

Typical audit items include: verification of control loop performance, safety system functionality, operator interface accuracy, and compliance with standard operating procedures.

8.2 Toolkit Library

Toolkits are collections of documents, techniques, tools, and other building blocks that are used by different work processes within a lifecycle instance (the complete span of a project from initial design through commissioning and operation). The reuse of toolkit contents is a key factor in reducing the cost and time required to automate procedures, provides more consistent implementation, and can lead to a reduction in both project and operating risk.

Definition: Think of toolkits as standardized libraries containing proven control strategies, documentation templates, and testing procedures that can be applied across multiple automation projects.

Industrial Example: A toolkit might include standard PID tuning procedures, pre-configured HMI templates, alarm management guidelines, and commissioning checklists that can be reused across different control system implementations.

The consistency gained from using established toolkit components helps avoid reinventing solutions for common control problems and reduces the likelihood of errors that could impact system performance or safety.

Toolkits may consist of:

Note: In control systems engineering, toolkits refer to integrated software packages that provide the essential functions and algorithms needed for designing, analyzing, and implementing control systems. These typically include mathematical modeling tools, simulation environments, and code generation capabilities that streamline the development process from initial design concepts to deployed control algorithms.

Common Components: Most control engineering toolkits include signal processing functions (for filtering and conditioning sensor data), system identification tools (to determine mathematical models from experimental data), controller design algorithms (PID, state-space, robust control methods), and real-time simulation capabilities for testing before hardware implementation.

• Documents
  • Procedure specification templates
  • Workflow
  • List of typical deliverables
  • Design documents showing how procedure specifications are mapped to procedure implementation modules
  • Documents showing how procedure implementation modules have been implemented in the past.
  • Documentation of automation styles currently in use.
• Best Practices and Conventions
  • Recommended methodologies
  • Naming conventions
• Typicals
  • Existing procedure specifications for typical procedures used with process equipment from the Physical Model.
• Tools
  • Programming/design environments and supporting tools.
  • Programs or scripts for automatically documenting procedure designs.
• Building Blocks
  • Code and configuration documentation of commonly used automated procedures.
  • Typical user-interface elements used for automated procedures.
  • Priority should be given to reusable code modules.
• Test procedure examples.
• Installation and commissioning checklists
• Operational audit checklists and procedures.

Organizing control system toolkits and code examples in searchable libraries significantly improves efficiency when developing new control strategies. This approach allows engineers to quickly locate and reuse proven control algorithms, tuning parameters, and implementation templates rather than rebuilding solutions from scratch.

Note: Modern control software platforms like MATLAB/Simulink, TIA Portal, or Studio 5000 typically include library functions where you can store custom function blocks, PID configurations, and tested control loops for future projects.

Practical Benefit: Instead of recreating a cascade control loop or motor control sequence each time, you can search your library for similar applications and adapt existing, validated code - reducing development time and minimizing the risk of introducing errors.

The toolkits may be updated which will require formal test plans, testing, and management of change (MOC).

Note: Management of change refers to the systematic process of reviewing, approving, and documenting any modifications to control systems or processes before implementation. This ensures safety and maintains system integrity.

Industrial Example: When updating a DCS (Distributed Control System) toolkit, you’ll need to create test procedures that verify all control loops, interlocks, and operator interfaces function correctly in a test environment before deploying to production systems.

Some challenges regarding toolkits’ management of change are:

Note: Change management in control system toolkits refers to how software handles modifications to control logic, configuration parameters, or system architecture while maintaining system integrity and traceability.

Common Issues:

Version control complications often arise when multiple engineers work on the same control project simultaneously. Without proper branching strategies (methods for managing parallel development), conflicts can occur when merging changes back into the main project.

Documentation synchronization becomes problematic when control logic changes aren’t automatically reflected in system documentation. This creates discrepancies between what’s actually running in the field and what’s documented in maintenance manuals.

Impact analysis limitations make it difficult to predict how a change in one part of the control system will affect downstream processes or safety interlocks. Many toolkits lack robust dependency tracking features.

Industrial Example: Modifying a PLC program’s timer value might seem straightforward, but without proper change management, you could inadvertently affect safety shutdown sequences or production cycle timing.

Testing and validation workflows often lack integration with the development environment, making it challenging to verify that changes work correctly before deployment to production systems. This is particularly critical in safety-rated applications where changes must be thoroughly validated.

Rollback capabilities vary significantly between platforms, with some toolkits offering limited ability to quickly revert to previous working configurations during commissioning or troubleshooting scenarios.

• Version management and compatibility/conflict between versions.
• An organization such that developers understand what tools are available for use
• have their purpose identified
• be clearly labeled as to whether the tool is already tested, awaiting test, or under development
• be capable of being updated and have the availability status (under development/awaiting test) re-labeled while unavailable
• be tracked to identify what procedures they are used in, should a problem with the tool be discovered and all related procedures need updating