Building Management System (BMS) – Validation Overview

Building Management System (BMS) is a wide range of applications which covers Heating Ventilation Air Conditioning (HVAC), Environmental monitoring, Fire Protection system, Alarms & Surveillance System, Lift Management System, Smart Building Technologies and Energy Conservations.

Why We Need to Validate a BMS?

The objective to conduct validation is to produce documents evident which ensure high level of confidence, ensuring system compliance, reduce risk of failures, and assurance that will improve operational efficiency to process. Validation is conducted to prove system functionality and consistently measure as per design specification.

Building Monitoring System (BMS) covers computerize system, network architecture, software as source code programming and instrumentations/ devices as controller (Input/output) whereas it is monitoring for GMP elements and Non-GMP elements. As parts of Code of Federal regulation, GMP elements/ critical areas are mandatory to VALIDATE. There has to be segregation physically and logically between GMP and Non-GMP elements to avoid conflict of I/O.

Regulatory Frame

EU Directive 2003/94/EC (Good Manufacturing Practice) – Article 8

“Premises and equipment to be used for manufacturing operations, which are critical to the quality of the products, shall be subjected to appropriate qualification and validation.”

Chapter 21 Part 11 Of the Code of Federal Regulation § 11.10 Controls for closed systems.

“Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.”

Chapter 21 Part 211 of the Code of Federal Regulations § 211.68 Automatic, mechanical, and electronic equipment.

“Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy. The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system.”

System Evaluation

System evaluation is very crucial, evaluating the system against standards including GxP, evaluating the system against established requirements, evaluating the needs of system and environment configuration, evaluating the requirements for installation and training requirements.

Risk Assessment

Risk Management should apply throughout life cycle of computer system. Identifies the Critical Control Point to be defined, justified and documented. They key of risk assessment is in understanding of critical parameters that have high probability of affecting product attributes if deviate from ranges standard for a defined period of time.
Regulated Company must be able to justify their in-house standard, protocol, operation procedures, and records, acceptance criteria based on analysis and risk assessment into consideration.

Testing, Verification and Commissioning

Perform a commissioning procedure consisting of field I/O testing, sequential test phase test and commissioning and integrated system program commissioning for entire system.
Document all commissioning information on commissioning data sheets that shall be submitted prior to acceptance testing.

Prior to system program commissioning, verify that each control panel has been installed according to plans, specifications and approved shop drawings. Test, calibrate and bring on line each control sensor and device.

Some of Tests have to be conduct before/ during Factory Acceptance Test and or Site Acceptance Test, not limited to:

BMS Unit P&ID Verification

The objective of this verification is to ensure that all the system instrument and equipment have been properly connected, tagged, and identified, in accordance with the process and instrumentation diagram.

System Components Verification and Installation

The objective of this verification is to ensure that for each component required for the system, all of the as-found conditions comply with the specifications, and that the components required for this system are installed as specified.

Wiring and Cabling Verification

The objective of this verification is to ensure that all wiring and cabling to the system has been properly connected, tagged, identified, and is in accordance with manufacturers specifications and/or engineering drawings. During execution of this section ensure that equipment visually checked to ensure that all component and wiring securely mounted.

Input and Output Verification/ Test

The objective of this verification is to ensure that all input/output points are addressed properly and connected to the field devices as per manufacturer specifications.

System Sequence Test/ Phase Test

The objective of this system sequence test/ phase test is to ensure that all system schematic running as process flow which has been designed.

Software Functionality, Backup, Archiving, and Version Verification

The objective of this verification is to determine that the installed software is perfectly functioning as determined in this URS. Scope also includes verification of ladder logic program name, version number, archiving capability and ensuring availability of the backups.

Software Structure Verification

The objective of this verification is to verify integration of software and hardware as a complete system. Scope includes system setups (hardware and software), to align with user requirements. User would require full simulation and In Circuit Test for the BMS System.

IT Infrastructure Verification

The objective of this verification is to verify integration of software, hardware and networking as a complete system. Scope includes system setups, configuration of network, remote accessibilities and remote notification.

Validation Approach

Perform a complete set of Validation after completion of Site Acceptance Test (SAT) for the critical system which Direct Impact to the process quality.

Validation consist of Installation Qualification (P&ID check, instrument check, wiring check, safety check and instruments calibration as well), Operational Qualification consists of System Operational test verification comparing with Functional Specification of the system as define in the System Design Specification.

Document all Validations and information on Validation data sheets that shall be submitted prior to Validation testing.

Implementation of BMS

Nowadays, modern technology makes everything easily. Everything can be reach in hand. Building Management System (BMS) using Real time monitoring will be displaying process status, generate Reports (includes trends, graph), sensor calibration expiry, generate alarm & warning according pre-set value in the system and event recording.

Perform the Facility Management (Generate reports, graph and annunciate alarms) when there is a problem and to ensure that monitored data is securely stored and have not been altered for future reference (audit/ investigation).

User/ client responsibility to provide proper procedure on the Data Recovery and Software Back-up Procedure and manage the stored data location as per company policy.

Defining of BMS Alarms

Correct strategy has to carefully implement to comply with regulatory requirements for BMS system itself. During conducting Risk Assessment and measurement studies should be assess for critical elements on the software features which derive as alarms, reporting, data historical tabular in total point of view to avoid unnecessary alarms, eg. Sometime in the Operation mode, door open by operator and it will be immediately trigger an alarms due to differential pressure out of ranges. It is very difficult if we have to acknowledge alarms and answer in the event of OOS/ CAPA raise by QA.

Statistical Process Control/ Conditioning Alarms should be implement and access through Risk Management, Validated and Documented as evidence.

Review of Electronic Records and Electronic Signatures

BMS system continuously records data in real time monitoring with certain define period of data collection. When BMS system consider and define as “critical” in the GMP environment, assessment of direct impact to the system should be made. Relevant parties should be manage, control on the reviewing of the electronic records, applies signatures and by proper procedure.

Electronic records and signatures should be define clearly during generate the User Requirement Specification (URS) and it is verify during design review and testing/ validation.


  • GAMP 5: Risk Based Approach to Compliant GxP Computerized System.
  • Title 21 Code of Federal Regulation, 21 CFR Part 11: Electronic Records, Electronic Signatures.
  • ISPE Pharmaceutical Engineering Guide, Commissioning and Qualification.


  • Zoher

    I am looking for guidance on BMS Computer software Validation for the FDA Regulated Industry. Can anyone suggest how to proceed.

  • From experience in order to full comply with FDA requirements Honeywell have a “bolt on” to their BMS operator work station.
    Having reviewed this some time ago it appeared certified (at the time).

    I have no doubt that to acquire a full FDA certified system you will need to talk to a product manufacturer (like Honeywell) and not just a system installer.

  • Risk Assessment for BMS is the key to validation, but you just put forward the problem and provided no clues on that. In fact, GMP and GEP issues may be combined to make a GMP and GEP compliant BMS by developing a CMP (commissioning master plan).

  • sandeep

    i m looking for help to certified my BMS software 21cfr validated to comply USFDA requirement

Similar articles:

An Alternative View of the ICH Q10 Pharmaceutical Quality System (PQS)

The image below is that depicted by the International Conference of Harmonisation (ICH) Q10, Annex 2, and is supposed to depict a PQS or Pharmaceutical Quality System.

Typically, I really love the ICH. When we have to deal with outdated regulations from different global organizations it becomes a real nightmare trying to keep track of the nuances and the ICH has done a pretty good job of bringing several of the key organizations together and aligning them on how best to organize and meet the expected requirements.

That being said the diagram below and the depiction in Q10 of what a PQS should look like is greatly lacking.

Development Phases

In section 1.8 under the Quality Manual the ICH Q10 guidance states, “The description of the PQS should include: …(c) Identification of the pharmaceutical quality system processes, as well as their sequences, linkages and interdependencies.

Process maps and flow charts can be useful tools to facilitate depicting the pharmaceutical quality system processes in a visual manner”.

I completely agree.

The problem is using the graphical depiction they present in Annex 2 is completely worthless.

Basically they listed some of the PQS elements in a bar and then said they all apply to the entire product lifecycle, which simply isn’t true.

When we are in the development phase of our product lifecycle why would we do that under the change management system, or monitor process performance?


Controlling Change – No Value Add

There is no point in controlling changes for a product that is purposely being changed, nor does it offer any value to monitor the process performance for a process that has yet to be developed.

This isn’t a graphic depiction of the PQS, but rather a graphic of how they depict the lifecycle management (which also has some issues).

The PQS is the quality system and its subsystems and how they interrelate.

While it’s useful to look at how the PQS and product Lifecycle Management overlap and what elements of the PQS system are relevant at each lifecycle stage, it is not the point of the PQS, and even if that’s the end goal it’s not depicted here at all.

This image offers almost no value.

A Better Approach

So, what should this graphic look like?

While this is not a perfect view of a PQS, I would propose that the image below is a much better depiction of how the PQS should be visualized and a good place to start.

At the core of any quality system should be management. This goes back to Deming, who said, “Quality begins with the intent that is fixed by Management”.

Quality has to be rooted in the executive management team.

Define Core Quality Systems

Core quality systems then need to be defined. These are systems that impact all aspects of the business and include a Risk Management Policy, Resource Management, Document Control and CAPA systems.

All of the other subsystems, Deviations, Supplier Management, Equipment Qualifications, Validation, Material Management, etc, etc. all should be risk based or involve risk assessment, they all require resources and training, they call require documents (procedures, policies, records), and the CAPA system of course drives for process improvement regardless of the process.


All subsystems feed back into the main Management module. The subsystems listed, all are interconnected, with the exception of Post Market Systems.

The subsystems are important too, but they are farmed out to different groups and have different levels of importance depending on the stage of the product lifecycle.

Post Market Systems

The one exception is the Post Market Systems. This includes complaint management, product reviews, recall processes and other systems to support marketed products.

These generally do not interact with the other subsystems unless it is through the CAPA system or other management functions, but still utilizes all the systems under the management umbrella.

Alternate View

The PQS presented here, isn’t intended to be perfect, but I thought it was worth presenting an alternate view to the one presented by the ICH.

The ICH concept is a good one, and the ideas are fairly well laid out in the ICH, but the graphical representation of the PQS leaves a lot to be desired.

When establishing a PQS, it is better to start with something to what we’ve depicted here, and customize it as needed for the organization.


Similar articles:

How 21 CFR Part 11.3(7) Applies to Electronic Batch Records [Video]

When dealing with Part 11 it’s important to understand what an electronic signature actually means

The definition of electronic signatures or e-sigs can be found in 21 CFR Part 11.3(7).

Electronic Signature

An electronic signature or e-sig means a computer data compilation of any symbol or series of symbols executed, adopted, or authorized by an individual to be the legally binding equivalent of the individual’s handwritten signature.

Handwritten Signatures

We also need to understand what a handwritten signature means in the context of Part 11.
The definition of handwritten signatures can be found in 21 CFR Part 11.3(8).

Handwritten signature means the scripted name or legal mark of an individual handwritten by that individual and executed or adopted with the present intention to authenticate a writing in a permanent form.

The act of signing with a writing or marking instrument such as a pen or stylus is preserved. The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark.

Electronic Batch Records

Eric works in a Pharmaceutical company and he is responsible for the filling process of the batch been manufactured.

Each time Eric performs the filling process he has to populate a batch record with the appropriate details

After each step Eric must also fill in his signature and date to verify that he actually performed each task.

Eric is manually handwriting these details and they are legally binding to Eric.

21 CFR Part 11.3(8)

This is when 21 CFR Part 11.3(8) applies.

Fast forward 12 months and Eric’s company has implemented a brand new Manufacturing Execution System (MES) where all details around the batch manufacturing process are recorded electronically.

21 CFR Part 11.3(7)

Now when Eric performs the filling process he now populates everything electronically and signs with his username and password combination to verify that he has performed those tasks.

This is when 21 CFR Part 11.3 (7) applies.



Similar articles: