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:

The Similarity Between Device Master Records & Chocolate Chip Cookies [Video]

The device design once complete, must be adequately transferred to manufacturing. This is typically accomplished through product specifications, standard operating procedures, work instructions and training.

Collection of Documents

Often a product specification is thought of as a document. The reality is the product specifications should be thought of as an association of written documents.

The product specifications typically include:

  • Assembly drawings
  • Component procurement specifications
  • Manufacturing instructions
  • Inspection
  • Test instructions
  • Digital data files
  • Manufacturing fixtures (jigs and molds)
  • Training materials
  • Artwork associated with labels
  • Acceptance criteria
  • Etc

Device Master Record (DMR)

The ultimate document to ensure adequate design transfer is the Device Master Record, or DMR.

The DMR is somewhat theoretical in that it is really a compilation of all the documents which are needed to realize the product.

For that reason, the DMR, is often established as an index which simply lists all of the documents needed to realize the product.

Contents of the DMR

The DMR typically includes the following documents:

  • Product specifications
  • Work instructions for device realization
  • Device history records/Forms to generate device history records
  • Component drawings/Specifications
  • Label artwork/Specifications
  • Test/Inspection methods
  • Software/Firmware
  • Validation Master Plan (VMP)

Since these documents may be revising and changing and may be at various distribution points, the DMR typically is an index of all the documents.

Chocolate Chip Cookie Analogy

One very common analogy is to envision the DMR as a chocolate-chip cookie recipe. If the DMR is complete, by providing the DMR to someone they can make the exact same chocolate-chip cookies.

While this is somewhat simplified, it’s an excellent analogy, but in order to make the perfect chocolate-chip cookie we would want specifications for the grade of flour, chocolate chips, sugar and other components.

We’d also like to know which equipment was validated, how they are tested/inspected, what are the instructions for each processing step, etc.

If we have all the relevant information we can reproduce the cookies exactly.

The DMR is the key to any successful design transfer whether it is an internal transfer to manufacturing or a transfer to a Contract Manufacturing Organization (CMO).


Similar articles:

The Four Phases of Conducting a Laboratory Investigation [Video]

The process which will be described here is based on the process discussed in the MHRA’s guidance on Out of Specifications Investigation.

When an out of specification, atypical or suspect result is obtained, it is particularly important that all solutions and reagents associated with the test are retained, as this will greatly assist the investigation.

The MHRA advocate laboratory investigations should proceed in four phases as follows:

Phase I(a)

Phase I (a) consists of a preliminary review, by the analyst, to determine whether there has been a clear and obvious error or event that caused the OOS, atypical or suspect result.

Phase I(b)

Phase I (b) occurs after phase 1(a) has failed to identify a clear and obvious cause. This is a more detailed investigation by the analyst and supervisor to identify a laboratory assignable cause.

Phase II

Phase II occurs after the phase I investigation has failed to identify a laboratory assignable cause for the OOS, atypical or suspect result and are driven by written and approved instructions in order to test particular hypothesis.

Phase III

In Phase III all the information obtained during Phases I and II of the laboratory investigation, and any manufacturing investigation, is reviewed and assessed, and a decision is made on the disposition of the batch

Learn More About Laboratory Investigations

If you would like to learn more about laboratory investigations click here for an overview of this course.



Similar articles: