Overview

The specifications and design work process produces two critical models for each lifecycle instance:

• Procedure Specification Model — defines what the control system needs to accomplish (functional requirements, performance criteria, operating constraints)
• Procedure Implementation Model — details how requirements will be executed (specific control logic, I/O configurations, hardware assignments)

Procedure Specifications (FRS)

Procedure specifications are documented in a platform-independent FRS. Key points:

• Start by mapping procedures to automate from the Physical Model
• Development approach: top-down, bottom-up, or mixed
• Operating staff must be actively involved in creation and review
• Operator knowledge converts subjective descriptions ("hot enough") into quantifiable setpoints and ranges

Specifications must include: high-level description of command/perform/verify work categories, general logic flow, exception conditions, and exception handling responses.

Design Implementation Modules (DDS)

Implementation modules are designed using the Specification Model as framework and the detailed design specification as supporting documentation. The DDS must be platform-dependent — accounting for the specific control system (DeltaV, PlantPAx, Experion, etc.) since different platforms have unique limitations and capabilities.

Key design activities include:

• Identify implementation modules and mapping from Specification Model
• Develop architecture and programming guidelines
• Identify control configuration tools (Functional Blocks, SFCs, etc.)
• Leverage existing toolkit/library entities
• Define data archival requirements and external data repository impacts
• Include metrics capture in the design (step durations, operator interaction counts)
• Design consistent operator interface aligned with HMI specifications
• Design exception handling: interlock responses, alarm automated responses, resource fault responses

HMI Specifications

HMI documentation must include:

• Information available for viewing: current state, mode, timing information, alerts, progress indicators
• Human data entry inputs: operating targets, alarm thresholds, manual test result data
• Operator commands: start/stop requests, mode changes, alarm response interactions
• Notifications: alarm banners, attention indicators, prioritized summary displays
• Access control: applicable users and groups with access requirements and limitations

Resource Conflict Management

Interactions between automated procedures must be documented to prevent operational conflicts. An automated procedure can only progress if all required resources are available without conflict. Document which resources each procedure requires and establish priority rules or interlocking logic for concurrent procedure execution.

Test Plan

A well-conceived test plan ensures procedures function correctly across all operational states: start-up, normal operation, abnormal operation, and shutdown. The test plan must include:

• Scope Definition: Which control loops, devices, and systems will be tested
• Test Objectives: Measurable success criteria for each
• Test Procedures: Step-by-step instructions with initial conditions and data collection requirements
• Safety Considerations: Hazards during testing and safety protocols
• Pass/Fail Criteria: Quantitative benchmarks
• Personnel Requirements: Independent of Procedure Developer
• Test Environment: Live production system or simulated environment