Qualification and Verification of Facility Automation Systems

Purpose and Scope

Qualification and verification of facility automation systems establish documented evidence that computerized control, monitoring, alarming, recording, and reporting functions are suitable for their intended GMP use.

The scope may include:

• Building Management Systems
• Environmental Monitoring Systems
• HVAC control systems
• Utility monitoring and control systems
• Programmable controllers
• Data-acquisition systems
• Historians and databases
• Alarm-notification applications
• Operator and engineering workstations
• Interfaces with external systems
• Supporting network, server, backup, authentication, and time services

Facility automation should not be treated only as an electrical component of HVAC qualification. A BMS or EMS that performs configurable logic, manages users, generates electronic records, communicates alarms, transfers data, or maintains historical information is also a computerized system.

The validation strategy should therefore integrate:

• Facility and HVAC qualification
• Automation engineering
• Computerized-system validation
• Data-integrity controls
• Information-technology controls
• Quality-system governance

The depth of qualification should be based on intended use, GMP impact, functional risk, data criticality, system complexity, configuration, supplier capability, and operating experience.

Position within the Facility-Automation Lifecycle

Facility-automation validation begins before software configuration or panel installation.

The lifecycle normally includes:

1. Intended-use definition
2. System classification and GMP-impact assessment
3. System-boundary definition
4. Supplier assessment
5. Requirements development
6. Functional and design specification
7. Risk assessment
8. Configuration and installation
9. Configuration verification
10. Functional and failure-mode testing
11. Requirements traceability
12. Validation review and release
13. Controlled operation
14. Change control
15. Periodic review
16. Targeted or broader requalification when justified
17. System retirement and record migration

These activities may overlap with design review, commissioning, factory acceptance testing, site acceptance testing, HVAC qualification, and facility qualification. The validation plan should define how evidence from each activity will be used.

Facility-automation validation should follow the complete path from requirements and risk assessment through design, configuration, verification, release, and lifecycle review. Control, monitoring, alarm, and data functions may follow different technical paths, but each must remain traceable to its intended GMP use.

Intended Use and GMP Impact

Qualification scope begins with a clear statement of intended use.

The intended-use description should identify:

• Facilities and areas supported
• Equipment and utilities controlled
• Environmental conditions monitored
• Critical operating modes
• Control functions
• Monitoring functions
• Alarm functions
• Data recorded
• Reports generated
• Decisions supported by the data
• Interfaces with other systems
• Expected users
• Required availability
• Failure and recovery expectations

GMP impact should be assigned according to credible consequences, not merely because a function resides within a validated platform.

A function may have direct GMP impact when it:

• Controls a condition necessary for product protection or containment
• Maintains a classified or controlled environment
• Prevents an unacceptable operating state
• Performs a critical interlock
• Generates a required environmental record
• Generates an alarm relied upon for timely GMP response
• Provides data used for room, process, batch, or product disposition

Indirect-impact functions may support troubleshooting, visualization, maintenance, communication, or infrastructure without directly controlling the critical condition or generating the official record.

Non-GMP functions may include office comfort control or administrative energy reporting when failure has no credible effect on GMP operation or records.

One platform may therefore contain direct-impact, indirect-impact, and non-GMP functions.

Computerized-System and GAMP-Based Assessment

GAMP-based assessment can help determine the validation approach, but it should not replace evaluation of intended use and risk.

Facility-automation platforms may contain a combination of:

• Standard infrastructure software
• Nonconfigured commercial products
• Configured applications
• Custom control logic
• Custom interfaces
• Programmable controllers
• Vendor-developed libraries
• User-developed reports or calculations

A commercial BMS or EMS platform is often highly configurable. Its standard software may be supplier-developed, while the installed application contains site-specific:

• Point databases
• Control sequences
• Alarm limits and delays
• Graphics
• Reports
• Historian rules
• User roles
• Interfaces
• Calculations
• Notification routes

The validation assessment should identify these components separately. Classifying the complete system under one broad software category can obscure the custom or configured elements that create the greatest risk.

GAMP classification is an industry tool, not an FDA regulatory classification. It should be used only where it improves planning, supplier leverage, specification, testing, and lifecycle control.

System Boundary and Architecture Review

The qualified boundary should be based on the complete technical path required to achieve intended function and reliable records.

The boundary may include:

• Sensors and transmitters
• Signal wiring
• Input/output modules
• Controllers
• Controller programs
• Actuators and drives
• Local panels
• BMS and EMS applications
• Servers and virtual machines
• Databases and historians
• Operator workstations
• Engineering workstations
• Network components
• Gateways and protocol converters
• Alarm-notification services
• Interfaces
• Time services
• Directory and authentication services
• Backup infrastructure
• Remote-access components
• Supporting procedures

Architecture review should confirm:

• Where control logic resides
• Where limits and alarms are evaluated
• Where electronic records originate
• Which repository retains the official record
• How time stamps are assigned
• Which functions continue after network or server loss
• Which dependencies are shared
• Whether claimed monitoring independence is technically justified
• How manual operation is performed
• How configuration and data are recovered

A high-level vendor drawing may support the review but does not by itself define the qualified boundary.

Supplier Assessment and Use of Supplier Evidence

Supplier assessment determines how much confidence can be placed in supplier documentation, development practices, testing, and support.

Assessment should be proportionate to:

• System GMP impact
• Software and configuration complexity
• Degree of customization
• Data criticality
• Supplier involvement
• Availability of development evidence
• Product maturity
• Installed-base experience
• Cybersecurity and support model
• Dependence on proprietary tools or services

Relevant supplier capabilities may include:

• Quality-management practices
• Software-development lifecycle
• Configuration management
• Testing practices
• Defect management
• Release control
• Cybersecurity management
• Data-integrity controls
• Backup and recovery provisions
• Remote-support controls
• Documentation quality
• Long-term support
• Obsolescence management

Supplier evidence may include:

• Design documentation
• Product specifications
• Development testing
• Factory acceptance testing
• Certificates
• Installation records
• Configuration documentation
• Cybersecurity information
• Release notes
• Known-defect lists

Supplier evidence may be leveraged after documented assessment and acceptance. Supplier testing does not automatically replace user verification of intended use, site-specific configuration, interfaces, alarms, records, security, and operating procedures.

User Requirements

User requirements should define what the facility-automation system must accomplish without prematurely prescribing every technical solution.

Requirements may address:

Control

• Control sequences
• Setpoints
• operating modes
• Interlocks
• Permissives
• Equipment lead-lag operation
• Fail-safe responses
• Local and automatic control
• Restart after power interruption

Monitoring

• Parameters monitored
• Measurement range and accuracy
• Sampling or scan frequency
• Recording interval
• Data-quality indication
• Missing-data representation
• Trending
• Reports
• Retention

Alarms

• Alarm conditions
• Thresholds
• Delays
• Deadbands
• Priorities
• Notification
• Escalation
• Acknowledgment
• Alarm retention
• Communication-failure detection

Data and Records

• Official GMP record
• Required metadata
• Time-stamp source
• Calculations
• Reports
• Record review
• Retrieval
• Archival
• Backup
• Retention

Security

• User roles
• Privileged access
• Configuration authority
• Remote access
• Session controls
• Account management
• Audit trails
• Electronic signatures where applicable

Requirements should be:

• Unique
• Clear
• Testable
• Risk-assessed
• Approved
• Traceable
• Controlled through change management

Functional, Design, and Configuration Specifications

Specifications translate approved requirements into an implementable technical design.

They may include:

• System architecture
• Hardware design
• Software versions
• Point definitions
• Control sequences
• Mode logic
• Setpoints
• Alarm limits and delays
• Interlocks
• Calculations
• Graphics
• Reports
• User roles
• Audit-trail behavior
• Interface mappings
• Historian configuration
• Backup configuration
• Failure behavior
• Time synchronization
• Network and cybersecurity controls

The documentation structure may vary. Information may be distributed among a functional design specification, sequence of operation, point list, alarm matrix, configuration specification, interface specification, security specification, and controlled drawings.

Regardless of document names, the approved set should provide enough information to:

• Build the intended configuration
• Review critical design decisions
• Verify the installed baseline
• Develop meaningful tests
• Maintain the system under change control
• Reconstruct the qualified configuration

Functional and Data-Risk Assessment

Risk assessment should identify what can fail, how failure can be detected, and what consequences may result.

Assessment should consider:

• Loss of environmental control
• Incorrect sensor scaling
• Incorrect point mapping
• Incorrect control logic
• Incorrect setpoint
• Incorrect alarm limit or delay
• Disabled alarm
• Stale or invalid data displayed as current
• Failure to record required data
• Incorrect calculation
• Incorrect time stamp
• Unauthorized configuration change
• Unauthorized record change
• Loss of audit-trail information
• Interface failure
• Network interruption
• Data corruption
• Incomplete backup
• Failed restoration
• Failure of redundant equipment
• Uncontrolled manual override
• Cybersecurity event

Risk controls may include:

• Design controls
• Independent monitoring
• Calibrated instruments
• Restricted access
• Configuration review
• Automated diagnostics
• Failure alarms
• Procedural checks
• Preventive maintenance
• Backup and restoration
• Verification testing
• Periodic review

Testing depth should be driven by residual risk after considering the effectiveness and detectability of these controls.

Part 11 and Electronic-Record Assessment

Part 11 applicability depends on how electronic records and electronic signatures are used. It does not depend on whether the application is called a BMS, EMS, controller, historian, or reporting system.

The assessment should determine:

• Which records are required by predicate rules
• Whether electronic or paper records are official
• Whether electronic data are relied upon in place of paper records
• Whether electronic signatures are used
• Where original data are generated
• Where official records are retained
• Which metadata are necessary
• Whether records can be modified or deleted
• Whether audit trails are required
• How records are reviewed
• How accurate and complete copies are produced
• How records are retained and retrieved

Applicable controls may include:

• Validated intended use
• Unique user identification
• Role-based access
• Authority checks
• Secure time-stamped audit trails
• Protection of original records
• Controlled configuration changes
• Accurate and complete record copies
• Backup and recovery
• Record retention
• Time synchronization
• Electronic-signature controls
• Signature-to-record linking

A system without electronic signatures is not automatically outside Part 11. Conversely, not every electronic BMS value is automatically a Part 11 record.

Audit-Trail Assessment and Verification

Audit trails should be evaluated according to the ability of users or administrators to create, modify, or delete GMP-relevant data or configuration.

Audit-trail coverage may be required for changes to:

• Setpoints
• Alarm thresholds
• Alarm delays
• Control parameters
• Point scaling
• Calculations
• Historian settings
• Report configurations
• User roles
• Interfaces
• Manual data entries
• Record status
• Electronic approvals

Verification should determine whether the audit trail:

• Is automatically generated
• Includes user identity
• Includes date and time
• Identifies the affected item
• Records the previous and new values
• Records required reasons for change
• Cannot be modified by ordinary users
• Remains linked to the applicable record
• Can be searched, reviewed, exported, and retained
• Uses reliable synchronized time

The organization should define which audit trails are reviewed, by whom, under what circumstances, and at what frequency.

Installation and Configuration Verification

Installation verification establishes the approved technical and configuration baseline.

Verification may include:

• Hardware and panel installation
• Controller identification
• Server and workstation installation
• Virtual-machine configuration
• Software and firmware versions
• Licenses
• Network addresses
• Communication paths
• Installed services
• Database configuration
• Historian configuration
• Backup agents
• Time services
• Security software
• Remote-access provisions
• Approved drawings and manuals
• Calibration status
• Preventive-maintenance requirements

Configuration verification should address site-specific elements such as:

• Point identifiers
• Input and output assignments
• Scaling
• Engineering units
• Ranges
• Setpoints
• Operating modes
• Alarm thresholds
• Delays
• Deadbands
• Control sequences
• Interlocks
• Trend intervals
• Historian rules
• User roles
• Graphics
• Reports
• Interfaces
• Notification recipients

Verification may use documented review, comparison tools, configuration exports, checksums, controlled screenshots, database queries, or direct functional testing.

Screenshots alone are generally weak baseline evidence when machine-readable configuration records are available.

Commissioning, FAT, and SAT Evidence

Commissioning, FAT, and SAT can provide valuable qualification evidence when they are planned, controlled, reviewed, and traceable.

Before leveraging the evidence, confirm:

• Approved test objectives
• Defined acceptance criteria
• Controlled test procedures
• Identified test configuration
• Qualified or suitable test instruments
• Traceability to requirements
• Complete results
• Recorded deviations
• Review and approval
• Relevance to the final installed configuration

FAT is particularly useful for:

• Control-panel verification
• Logic testing
• Graphic review
• Alarm configuration
• Simulated point testing
• Report review
• User-role review

SAT is useful for:

• Installed communication
• Field-device signals
• Site interfaces
• Actual sensors and actuators
• Network integration
• Alarm notification
• Site recovery functions

A FAT completed before final configuration changes cannot demonstrate the unchanged validity of affected functions. The validation assessment should identify what must be repeated or confirmed at the installed site.

Functional Qualification

Functional qualification should demonstrate correct operation under normal, boundary, failure, recovery, and unauthorized-use conditions where applicable.

Testing may include:

Control Functions

• Automatic control sequences
• Manual and local modes
• Startup and shutdown
• Occupied and unoccupied modes
• Setpoint changes
• Lead-lag operation
• Interlocks and permissives
• Actuator response
• Feedback confirmation
• Fail-safe behavior
• Restart after power loss

Monitoring Functions

• Point accuracy
• Engineering units
• Scaling
• Recording frequency
• Trend display
• Data-quality indication
• Missing or stale data
• Calculated values
• Reports
• Record retrieval

Alarm Functions

• Alarm threshold
• Delay
• Deadband
• Priority
• Local indication
• Remote notification
• Escalation
• Acknowledgment
• Return to normal
• Alarm history
• Communication failure
• Notification failure

Security and Data Integrity

• Unique accounts
• User roles
• Privileged functions
• Unauthorized actions
• Password and session controls
• Configuration restrictions
• Audit trails
• Electronic signatures where applicable
• Time synchronization
• Accurate and complete copies

Failure and Recovery

• Sensor failure
• Controller failure
• Server failure
• Network interruption
• Interface loss
• Database interruption
• Historian failure
• Notification failure
• Power interruption
• Time-service failure
• Backup restoration
• Buffered-data reconciliation

Positive-path testing alone is insufficient for functions whose failure can affect environmental control, critical alarms, or regulated records.

Interface and End-to-End Data Verification

Interface testing should verify the complete data path, not merely confirm that a value appears at the destination.

Testing should challenge:

• Source-point identity
• Destination-point identity
• Point mapping
• Data type
• Engineering unit
• Scaling
• Precision
• Values across the operating range
• Alarm-state transfer
• Data-quality flags
• Time stamps
• Transfer latency
• Communication loss
• Data buffering
• Retry behavior
• Duplicate handling
• Missing-data handling
• Recovery after outage
• Data reconciliation
• Unauthorized interface changes

Where data support GMP decisions, verification should follow the value from the field measurement through signal processing, controller, gateway, database, historian, report, and final review.

Backup, Restore, and Recovery Verification

Backup verification should establish that required records and configuration are included in the backup scope.

The scope may include:

• Controller programs
• Point databases
• Control sequences
• Alarm configurations
• Graphics
• Historian records
• Application databases
• Audit trails
• Reports
• User and role configurations
• Interface mappings
• Server configurations
• Virtual-machine images
• Certificates or encryption materials

Testing should demonstrate:

• Backup execution
• Backup monitoring
• Protection from unauthorized alteration
• Retention
• Availability of the correct backup
• Restoration of configuration
• Restoration of records
• Application restart
• Interface restoration
• Record completeness
• Time and sequence preservation
• Reconciliation after recovery

A successful backup status does not demonstrate that the backup can be restored or that the restored system can support its intended GMP use.

Requirements Traceability

Traceability should connect:

1. Intended use
2. User requirements
3. Functional and configuration specifications
4. Risk controls
5. Design elements
6. Configuration items
7. Verification tests
8. Deviations
9. Final acceptance and release

The traceability matrix should identify:

• Requirement identifier
• Requirement description
• GMP or data significance
• Applicable risk
• Design or configuration reference
• Test reference
• Test result
• Deviation reference
• Final status

Traceability should demonstrate both:

• Every approved requirement was implemented and verified.
• Every configured GMP-relevant function has an approved requirement or documented design basis.

Traceability is also a lifecycle tool. It supports impact assessment when points, logic, alarms, reports, interfaces, or infrastructure are changed.

Deviations and Test Evidence

Test discrepancies should be documented when the observed result differs from the approved expected result.

The assessment should determine:

• What occurred
• Which requirement or function was affected
• Whether the problem was procedural, configuration-related, design-related, or environmental
• Whether other tests or records were affected
• Whether correction changed the qualified configuration
• What regression testing is required
• Whether risk remains acceptable
• Whether release is affected

Repeating a failed test without documenting the original result weakens the integrity of the validation record.

Test evidence should be attributable, contemporaneous, complete, accurate, and sufficiently detailed to reconstruct execution.

Integration with HVAC and Facility Qualification

Automation qualification and HVAC qualification should be coordinated but should not be treated as interchangeable.

Automation qualification demonstrates that:

• Sensors are correctly represented
• Logic operates as specified
• Commands reach the intended devices
• Alarms function correctly
• Data are recorded and retained
• Users are properly restricted
• Interfaces and recovery functions operate correctly

HVAC qualification demonstrates that the integrated mechanical and control system achieves required environmental performance.

A correctly operating control loop may still fail to maintain acceptable room conditions because of mechanical capacity, balancing, leakage, load, or airflow-distribution problems.

Conversely, acceptable room performance during one HVAC test does not verify access control, alarm delays, audit trails, historian configuration, backup, or failure recovery.

Performance Qualification and Operational Scenarios

Performance qualification may be appropriate when routine users, actual workflows, integrated equipment, reporting, or operational conditions must be demonstrated.

Representative scenarios may include:

• Normal production operation
• Startup following shutdown
• Transition between occupied and unoccupied modes
• Room-pressure recovery after door opening
• Changeover between duty and standby equipment
• Response to environmental alarm
• Alarm acknowledgment and escalation
• Review of environmental trends
• Generation of an approved report
• Investigation of an excursion
• Temporary manual monitoring during system outage
• Restoration after communication failure

Not every facility-automation system requires a separately named PQ protocol. The validation plan should define where routine-use confirmation is necessary and how it will be documented.

Release to GMP Operation

Release should occur only after documented confirmation that the system is suitable for its approved intended use.

Release readiness should verify:

• Approved intended use
• Approved system boundary
• Completed supplier assessment
• Approved requirements and specifications
• Completed risk assessment
• Verified installation and configuration baseline
• Completed required testing
• Acceptable deviations
• Completed traceability
• Approved Part 11 assessment
• Approved data-integrity assessment
• Established user accounts and roles
• Approved procedures
• Completed training
• Active calibration and maintenance
• Active backup and monitoring
• Available recovery procedures
• Defined support responsibilities
• Approved validation summary or release record

Conditional release should identify the remaining item, associated risk, compensating control, responsible owner, due date, and approval authority.

Controlled Operation

Following release, the system should remain under defined lifecycle controls.

These may include:

• User administration
• Configuration management
• Change control
• Incident and deviation management
• Alarm review
• Audit-trail review
• Access review
• Calibration
• Preventive maintenance
• Backup monitoring
• Restoration testing
• Cybersecurity management
• Vendor management
• Periodic review
• Requalification
• Obsolescence planning

The validated state depends on both technical configuration and supporting procedures. A technically unchanged system can lose control through weak access management, failed backups, obsolete documentation, ineffective alarm response, or unmanaged infrastructure changes.

Periodic Verification and Review

Periodic review should determine whether the system remains:

• Suitable for its intended use
• Consistent with the approved configuration
• Qualified
• Secure
• Supportable
• Capable of reliable control and monitoring
• Capable of generating complete and reliable records

Review inputs may include:

• Current intended use
• System and point criticality
• Configuration changes
• Software and firmware changes
• Infrastructure changes
• User access
• Privileged accounts
• Alarm performance
• Recurring alarms
• Notification failures
• Sensor and calibration history
• Data gaps
• Interface failures
• Audit-trail events
• Backup evidence
• Restoration testing
• Cybersecurity events
• Deviations and investigations
• Maintenance history
• Open corrective actions
• Vendor support
• Obsolescence
• Continued Part 11 applicability

Periodic review is evidence-based assessment. It is not automatic repetition of the original qualification.

Change Impact and Requalification

Changes should be assessed according to their effect on requirements, risks, configuration, interfaces, records, and the qualified state.

Relevant changes may include:

• Sensor replacement
• Point addition or deletion
• Point remapping
• Scaling changes
• Setpoint changes
• Alarm-limit or delay changes
• Logic changes
• Controller replacement
• Software or firmware upgrade
• Server migration
• Network redesign
• Historian changes
• Interface changes
• User-role changes
• Backup changes
• Time-service changes
• Cybersecurity changes
• Notification-platform changes
• Report changes

The resulting action may range from documented review to targeted configuration verification, regression testing, interface testing, restore testing, operational confirmation, or broader requalification.

Not every change requires full requalification. Unchanged functions may remain covered when their lack of impact is technically justified and documented.

Common Qualification Weaknesses

Common weaknesses include:

• Treating automation qualification only as part of HVAC OQ
• Qualifying screens without testing underlying controllers
• Classifying the complete platform uniformly
• Failing to identify configured and custom elements
• Undefined intended use
• Incomplete system boundary
• Weak or untestable requirements
• Missing requirements traceability
• Unassessed supplier evidence
• Uncontrolled configuration records
• Relying only on screenshots
• Verifying only positive-path operation
• Failing to test alarm delays and notification failure
• Failing to identify the official GMP record
• Assuming Part 11 applicability from the system name
• Shared user accounts
• Unrestricted engineering access
• Missing audit trails for critical configuration changes
• Verifying destination displays without testing the complete interface
• Ignoring time synchronization
• Assuming successful backup means successful restoration
• Failing to reconcile buffered data after recovery
• Using FAT results after unassessed configuration changes
• Repeating failed tests without documenting the original result
• Releasing the system without established procedures, training, backup, and support
• Performing periodic review as a checklist without evaluating actual performance

Maintaining a Defensible Qualified State

A defensible facility-automation validation strategy should establish:

• What the system is intended to do
• Which functions and records have GMP significance
• Where the qualified boundary begins and ends
• How software and configuration are classified
• Which supplier evidence can be relied upon
• How requirements are translated into design and configuration
• How critical risks are controlled
• Where Part 11 applies
• How access, audit trails, records, interfaces, and recovery are verified
• How commissioning evidence is leveraged
• How requirements remain traceable through testing and release
• How changes are assessed
• How continued performance is periodically reviewed
• When targeted or broader requalification is necessary

The objective is not to test every available software function. The objective is to establish documented confidence that every GMP-relevant control, monitoring, alarm, record, interface, security, and recovery function is correctly specified, configured, verified, released, and maintained throughout its operational lifecycle.