Fault Detection and Diagnostics (FDD) plays an important role in ensuring smooth and uninterrupted operation of a commercial building. FDD has emerged as a powerful tool for O&M teams to proactively identify “blind spots” in maintenance and contextualize the operating patterns of building assets to detect faults. It’s time to explore the evaluation criteria of an ideal FDD solution for your facility.    

Through this article, we will try to answer two major questions that come to mind while considering FDD for a facility

1)  How one can evaluate the performance of an FDD algorithm/ application?

2) How to select an Ideal FDD package that aligns with your facility’s needs?

One of them focuses on the capabilities and accuracy of the FDD tool while the other helps you construct a decision-making framework from the available options in the market.

The Importance of Evaluation Criteria

Till now most of the efforts from the individual startups and research organizations have been spent on developing FDD algorithms and methodologies rather than developing a performance assessment framework. Evidently, there are no such standards available to evaluate FDD algorithms. However, we are sharing a mostly followed systematic approach published in NREL’s whitepaper for evaluating the performance of FDD algorithms that leverages and unifies prior work in FDD evaluation. 

How to define a Fault?

A commercial Fault Detection and Diagnostics (FDD) tool categorizes three different types of faults: condition-based, behavior-based, or outcome-based fault. 

A condition-based fault is the presence of an improper or undesired physical condition in a system or piece of equipment. These can be called physical faults. The behavior-based fault is the presence of improper or undesired behavior during the operation of a system. Behaviors that break certain rules or operational logic. While the quantifiable outcome of the process deviates from the ideal or reference value then it can be categorized as an outcome-based fault.   

It is ideal to have an Fault Detection and Diagnostics software that incorporates all three categories of fault detections. 

Input Data Requirements for Fault Detection and Diagnostics

What type of data is required for an FDD to process and produce the outcome is also an important criterion of evaluation. Broadly there are 2 different types of input data samples are used 

1. A single instant of time: A single set of simultaneous measurements of the system variables, representing a snapshot of system parameters under a certain condition.
2. A regular slice of time: a continuous set of system variables and parameters under a certain condition. 

Based on the data frequency one can determine the accuracy and processing infrastructure required for the FDD.

Performance metrics for FDD algorithms

Fault Detection and Diagnostics performance metrics are divided into two categories temporal and static. By definition, temporal metrics quantify an FDD algorithm’s evolving response to a time-varying fault signal, while static metrics quantify an FDD algorithm’s performance with respect to a collection of samples independent of their ordering in time.

Temporal metrics evaluate the time series component of the FDD while static metrics describe the time-independent performance of an FDD algorithm. Based on how the FDD output is reviewed one can depend on temporal or static metrics for the evaluation.

Once the FM technical team has enough idea on how they are going to utilize the FDD and what metrics they are going to evaluate it, they can move to available delivery mechanisms for their facility. In some cases, both questions can be simultaneously evaluated to reach a conclusion. Let’s examine them one by one.

1. Cloud-based or On-premises:

Just like any other FM application, there are multiple possibilities and limitations with each option, hence the decision has to be aligned with the facility’s available tech stack and future roadmap. 

Cloud application comes with multiple advantages such as scalability, security, speed and most of all SaaS modeling, making it a highly affordable option. There are a couple of On-premise applications available in the market which caters the institutional customers who prefer local data hosting for technical and policy reasons.    

2. Integration Capabilities:

Users should have a clear understanding of how the new FDD application/Platform will interact with existing data sources and applications. The use of Data communication protocols, Software connectors and Application Programming Interfaces (API) have to be clearly defined before selecting a service provider or an application. 

3. Data Ownership: 

Ownership of the data comes as an important criterion to select an FDD application or services. While you choose the FDD application or service from the 3rd party technical team you have to be clear on who owns the raw data as well as the insights. Will you have the freedom to cross-validate the FDD data with other parameters and what are other ways your FM team can use it further optimize the performance.

Besides these three main deciding factors there are other elements your FM team should consider, such as flexibility to switch from exiting application to a new one, capability building and training required for technicians and operators to get familiar with the FDD application, etc.

If you are already using an FDD application then share us your experience of evaluating your FDD application. If you think there is something one should also consider besides the points mentioned in this article then let us know.