INTEGRATED AUTOMATION SYSTEM FAULT DETECTION AND DIAGNOSTICS

This article is about general and technical requirements for FAULT DETECTION AND DIAGNOSTICS used in Integrated Automation System or Building Automation System.

INTEGRATED AUTOMATION SYSTEM FAULT DETECTION AND DIAGNOSTICS

•  GENERAL

  • RELATED DOCUMENTS

Retain or delete this article in all Sections of Project Manual.

1. Drawings and general provisions of the Contract, including General and Supplementary Conditions and Division 01 Specification Sections, apply to this Section.
2. Specifications throughout all Divisions of the Project Manual are directly applicable to this Section, and this Section is directly applicable to them.
3. Refer to Divisions 1 through 28 for project related standards pertaining to installations that shall apply to this Division.

• SUMMARY OF WORK

This specification covers how the facility equipment and sub-systems are intended to operate on an integrated Smart Building control basis, and as specified under Division 25. Spec writer should edit this section based upon the scope of their project.

4. Provide a fault detection and diagnostic system (FDD) that is fully integrated with the Tridium Niagara 4.0 <Select One; Supervisor and Supporting JACE controllers; or JACE Controllers> and directly accesses the Niagara database without API’s or intermediate middleware. The FDD work shall be comprised of the following tasks and components:
   1. Tagging Niagara and BACnet Points as part of the N4 basic programming that allows for Niagara N4.x Analytics to take full account of hierarchical relationships.
   2. Create fault algorithms for all systems and equipment types as outlined in Article 3.4.
   3. Create alerts as a response to algorithms to automatically, send a maintenance notification, sound an alarm or trigger a remedy.
   4. Create algorithms that query the Niagara database to look for data trends and patterns that identify pending equipment failures, equipment and system performance degradation; etc.
   5. Create data visualization graphics to present algorithm data in an intuitive manner to aid in the diagnosis of system faults and alarms. Data visualization shall include fault dashboards, charts, graphs, spectrum charts and color-coded equipment icons to visually represent equipment health.
   6. Provide data roll-up and aggregation features that permit data to be combined for improved data analysis
5. Provide related system integration services to import building sub-system data into the Niagara N4 environment that exists in stand-alone installations and is listed as required for FDD in Part 3.0 Execution.

• RELATED WORK SPECIFIED ELESWHERE

Edit Divisions according to the specific details of the project.

1. Division 01 – General Requirements
2. Division 08 – Openings (for windows and security access doors)
3. Division 11 – Equipment (for Food Service Equipment)
4. Division 12 – Furnishings (Shades and blinds)
5. Division 14 – Conveying Equipment (Elevators and Escalators)
6. Division 21 – Fire Suppression
7. Division 22 – Plumbing
8. Division 23 – Heating Ventilating and Air Conditioning
9. Division 25 – Integrated Automation
10. Division 26 – Electrical
11. Division 27 – Communication Systems
12. Division 28 – Electronic Safety and Security

• DEFINITIONS

Edit this section based upon specific details of the project and any terms which need further definition.

1. Alarms: An alarm is activated when a device fails or a critical set point is exceeded. This warns the user that a device has exceeded or fallen below a certain range around the set point. These usually signal a failure or a process not a performance parameter notification.
2. Alarm and Fault Classes: Alarm and Fault classification is a method for organizing alarms and faults based on common characteristics and requirements (e.g., level (minor, critical, etc.) Category (operational, environmental, etc.) and type (variable, sensor, report, function, etc).
3. AOWS: Automation Operator Work Station.
4. Closed-loop Control Systems. A Closed-loop Control System, also known as a feedback control system is a control system which uses the concept of an open loop system as its forward path but has one or more feedback loops (hence its name) or paths between its output and its input. Therefore, A closed loop control system considers the current output and alters the output based upon the desired condition directly. The control action in these systems is based on the output.
5. DALI: Digital Addressable Lighting Interface.
6. FACLAN: Facility Local Area Network
7. FDD: Fault Detection and Diagnostics.
8. Fault Diagnosis: Follows fault detection. Faults are isolated, identified and recorded. Diagnosis analyses the kind, size, location and time of the faults for the user.
9. Faults: A fault is activated when a parameter deviates from a pre-defined acceptable (usual or standard) condition for a designated period of time.
10. HTTP: HyperText Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.
11. IAS: Integrated Automation System.
12. Tagging: Tagging is used to organize data points for future database analytics. Project Haystack is an open source initiative to develop “tagging” conventions and taxonomies for building equipment and operational data. The community-based effort defines standardized data models for the data points related to energy, HVAC, lighting, and other environmental systems. A simple REST API is defined to facilitate exchange of Haystack data over HTTP.
13. REST: Representational state transfer (REST) or RESTful web services are a way of providing interoperability between computer systems on the Internet.
14. SCMS: Supervisory Control and Monitoring System.

• GENERAL CODE AND DIVISIONAL ADHERENCE

Edit Article A according to the specific details of the project. Check local code requirements.

1. Apply to all state and local codes governing the location of this project identified to be with in the regulating body of the [Location].
2. Adhere to applicable local codes as called out in Article Integrated Automation System (IAS) Concept & Technical Specification.

• REFERENCE STANDARDS

  1. The latest published edition of a reference shall be applicable to this Project unless identified by a specific edition date.
  2. All reference amendments adopted prior to the effective date of this Contract shall be applicable to this Project.
  3. All materials, installation and workmanship shall comply with the applicable requirements and standards addressed within all references.

• GENERAL FUNCTIONAL SPECIFICATIONS DESCRIPTION

  1. Other contractors shall be responsible for providing complete, fully functional and operational systems within their respective scopes of work. They are also responsible for providing the means of integration and associated connections to the IAS. In addition, the contractors are responsible for ensuring the data and information sent to the IAS complies with the IAS tagging standards, is correctly formatted and achieves reliable and consistent data transfer.
  2. The IAS contractor shall be responsible for providing all AOWS configurations, programming and graphics development the installation of the IAS and attain the functionality described herein. The IAS contractor shall provide the FACLAN infrastructure to connect to the network controllers installed through other Divisions, learn the associated data and confirm the tagging and BACnet properties are acceptable.

• PRODUCTS

  • NIAGARA ANALYTICS – GENERAL

Outline the systems which shall be monitored by the IAS fault detection and diagnostics. Systems may be windows, elevators, door access, plumbing, HVAC, Lighting, electrical, fire alarm, communications and others.

Specific projects such as schools, data centers, hospitals and office buildings may have different requirements. Review each project and adjust specification for the specific project.

1. Provide a fault detection and analytic framework that utilizes a high-performance calculation engine. The engine shall permit real-time data to be combined with historical data using a set of wire and property sheets.  The visual programming interface shall be used to define the algorithms (formulas) that analyzes the real-time and trend data collected from the following systems:
2. Sub-system data to be analyzed. [Specifier Note – Select the sub-system data to analyzed]
   • [Automated Blind/Shade Sun Control]
   • [Automated Window Tinting Control]
   • [Vertical Transportation System]
   • [Plumbing System]
   • [Fire Alarm and Detection System]
   • [HVAC Control System]
   • [Lighting and Plug Control System]
   • [Electrical Power Monitoring (Metering)]
   • [Emergency Generator Monitoring]
   • [Access Control System]
   • [Video Surveillance]
   • [Other BAS Systems]
3. The output from the analysis shall be able to be visualized in charts, graphs and dashboards and be used as inputs to standard Niagara logic. Faults shall be prioritized according to the associated system, location and the level of cost avoidance.
4. When applied to historical and real-time data, the framework algorithms shall provide the following analysis features:
   • An open and extensible analytical environment that can easily customized.
   • Analytic tools that apply to any data types available from building sub-systems.
   • The ability to set-up complex analysis without custom programming.
   • Support for third party API visualization application programs.

• SOFTWARE HOSTING PLATFORMS

Specifier Note:  Pick one of the Software Hosting Platforms.  Contact Tridium to verify the SaaS platform requirements.  Pay attention to the N4.x Supervisor hardware specifications and make sure the server deployed has ample resources to support both Niagara 4.x Supervisor and Analytics.  An enterprise class server may be required. Refer to section 230900 for software provided with the JACE.

1. On- Premise Application Server:
2. Software as a Service (SaaS)

• EXECUTION

  • GENERAL FDD INTEGRATION PRE-REQUISTE SERVICES
    • Provide all required system integration.
    • All fault dependencies and associated set points shall be customized according to the specific project requirements and needs of each application, as well as the project’s intended operation. This process shall be conducted as part of final systems commissioning and documented accordingly.
  • DATA CONVENTIONS, FDD TOOLS AND APPLICATIONS
    • The fault detection and diagnostic applications shall employ standardized naming conventions and employ “semantic tagging”, pattern recognition, functional rules processing and other techniques to enable advanced diagnostics and analytics for extended databases. Tags are added to data items as needed to convey definitions and associations. For example, an air handler might have tags that define its location (site, building, floor), fact that it is an electric load, manufacturer, capacity, schedule, associated control parameters, etc. Records can have as many tags as needed and new tags can be added. Solution should follow the (Project Haystack, Niagara, Custom) Project Haystack is an open source initiative to streamline working with data from the Internet of Things. The initiative standardizes semantic data models and web services with the goal of making it easier to unlock value from the vast quantity of data being generated by the smart devices that permeate our homes, buildings, factories, and cities. Applications include automation, control, energy, HVAC, lighting, and other environmental systems.ad hoc whenever needed. Tags provide the hooks that the analytics engine uses to correlate and analyze the data.
    • The Fault Detection and Diagnostic (FDD) solution shall employ closed loop control. The closed loop control shall apply the outputs from the FDD back to the IAS as an input to supervised building sub-systems to alter the control of the devices based upon certain conditions found by the FDD analysis. An example may be that if a power meter is found to be offline, then the FDD shall notify the work order managements system to open a work order to have staff check the status of that meter and correct the issue. Another may be if a certain condition is found which may be critical, the FDD may issue a command to shut down that system to eliminate a more serious result.
    • Alarms and Faults shall be defined in multiple classes for categorization. These classes may be used for many purposes to sort faults for action. Faults shall be monetized (costs associated with each fault) as a way to categorize and compare fault priorities. This will assist the operations team on prioritizing, categorizing and organizing the faults for assignment,
    • The FDD system shall have the ability to notify and message specific types of users based upon the fault classification. Messaging shall be by text, email, phone or GUI alarm.
    • The FDD software and application shall have templates and library models to enable the user to populate standard databases using pre-configured templates and libraries for standard system and equipment.

• IA BUILDING SUBSYSTEMS FUNCTIONAL SPECIFICATION REQUIREMENTS.

  • The following matrix outlines the extent of the fault detection diagnostics and demand response participation associated with each building subsystems as well as providing an indication of each system’s demand response classification. See Article 3.5 through 3.13 for complete descriptions of fault rules as well as associated systems demand response functionality.
    

    Sub-System	Fault Detection and Diagnostics (FDD)
    [Automated Blind/Shade Sun Control]	Yes
    [Automated Window Tinting Control]	Yes
    [Vertical Transportation System]	Yes
    [Plumbing System]	Yes
    [Fire Alarm and Detection System]	Yes
    [HVAC System]	Yes
    [Lighting & Plug Control]	Yes
    [Electrical Power Monitoring (Metering)]	Yes
    [Emergency Generator Monitoring]	Yes
    [Video Surveillance]	Yes
    [Access Control System]	Yes
    [Other BAS Systems]	Yes

GENERAL FAULT DETECTION AND DIAGNOSTICS.

1. 1. All generated fault notifications shall be issued via email, text or through the work order management system
   2. Faults shall be prioritized per the associated system, location and the level of cost avoidance.
   3. The following matrix outlines the specific rules associated with the fault detection diagnostics of the IAS.

The following fault rules are examples of typical fault detection and diagnostics descriptions. The list of these faults will grow in the future but should be written generically to handle multiple systems. Remember faults should apply to multiple systems and equipment in multiple buildings to be beneficial.

• Automated Blind/Shade (Sun) Control System

Fault Rule Name	Fault Rule Short Description
Blind/Shade Closure Failure	Generates a fault when the blinds and/or shades are open and the outside light level is above a threshold as measured by the sun sensor.
Blind/Shade Opening Failure	Generates a fault when the blinds and/or shades are closed and the outside light level is within a threshold as measured by the sun sensor.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• Vertical Transportation System Control

Fault Rule Name	Fault Rule Short Description
Bad Energy Data	Finds periods when data contains values outside of low and high limits or the data is Null for at least a duration of time.
Cab Recall Failure	Generates a fault if an elevator cab fails to recall to a requested floor
Cab Maintenance Failure	Generates a fault when the elevator cabs have been operating without a required maintenance shutdown as measured by an hourly timer.
Double Dipping Data	Finds periods when a point’s history contains two or more data points within a leeway of an interval for at least a duration.
Missing Data	Finds periods when a record’s history contains zero data points within a leeway of an interval for at least a duration.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• Plumbing System Control

Fault Rule Name	Fault Rule Short Description
Hot Water Heater Cycling	Generates a fault when the Hot Water Heater stays on or off for less than a duration.
Hot Water Temperature Setpoint Unreachable	Finds periods when any water heater is on and the HW temperature is unable to reach a pre-specified threshold of the HW supply setpoint for over a duration.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• Fire Alarm and Detection System Control

Fault Rule Name	Fault Rule Short Description
Fire Pump Operation	Generates a fault when the Fire Pump Operates, indicates a leak in the system or a loss of pressure.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• HVAC Control System Fault Definitions

• Lighting Control System

Fault Rule Name	Fault Rule Short Description
Bad Energy Data	Finds periods when data contains values outside of low and high limits or the data is NaN for at least a duration
Double Dipping Data	Finds periods when a point’s history contains two or more data points within a leeway of an interval for at least a duration.
Lights Operating During Unoccupied Hours	Generates a fault when lights are running during unoccupied hours, and an associated occupancy sensor has not detected motion therein.
Lights Not Operating During Occupied Hours	Generates a fault when lights are not running during occupied hours, and an associated occupancy sensor has detected motion therein.
Lights Not Dimming During Daylight Harvesting	Finds periods when the lighting level exceeds the zone setpoint(s) by a threshold for a longer than a duration
Missing Data	Finds periods when a record’s history contains zero data points within a leeway of an interval for at least a duration.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• Electrical Power Monitoring (Metering) System Control

Fault Rule Name	Fault Rule Short Description
Bad Energy Data	Finds periods when data contains values outside of low and high limits or the data is null for at least a duration
Building Running Too Late	Finds periods when the demand of the building does not drop off by at least a percentage or threshold for a duration after occupancy is over.
Building Starting Too Early	Finds periods when the demand increases by a percentage or threshold for a duration before building occupancy.
Double Dipping Data	Finds periods when a point’s history contains two or more data points within a leeway of an interval for at least a duration.
Excessive Energy Usage During Unoccupied Period	Generates a fault when the daily unoccupied energy usage is greater than the daily occupied energy usage by a threshold
Maximum Demand During Un-occupancy	Finds periods when the maximum demand peak for the day occurs during an unoccupied period.
Missing Data	Finds periods when a record’s history contains zero data points within a leeway of an interval for at least a duration.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.
Short Demand Peak	Finds short demand peaks throughout the day.

• Emergency Generator Monitoring System Control

Fault Rule Name	Fault Rule Short Description
Fuel level Fault	Generates a fault when the fuel level falls by a good measure with no generator operation.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

• Video Surveillance System Control

Fault Rule Name	Fault Rule Short Description
Unauthorized Access	Generates a fault when someone who does not have the proper credentials tries to access the CCTV system.
Camera Failure	Finds periods when a camera image does not change by a threshold for a 24-hour period.

• Access Control System

Fault Rule Name	Fault Rule Short Description
Door Blocked Open	Generates a fault when a door is open for more than 2 minutes.
Unauthorized Access	Generates a fault when someone who does not have the proper credentials tries to access the Access Control system.
Sensor Failure	Finds periods when a sensor does not change by a threshold for a 24-hour period.

FAULT DETECTION AND DIAGNOSTICS DETAILS.

The following provides a summarization of the specific descriptions and requirements associated with the fault detection diagnostics of each building sub-system.

Extended Rule Descriptions and Requirements:

Sun Control System Fault Detection and Diagnostic

Vertical Transportation System Fault Detection and Diagnostic

Plumbing and Life Safety System | Fault Detection and Diagnostic

HVAC Control System Fault Detection and Diagnostic

Lighting Control System Fault Detection and Diagnostic

Electrical Power Metering and Generator Control System

Security Control System Fault Detection and Diagnostic | Automation

HVAC System Functional Specification | Integrated Automation System

Water Booster Pump Control System Functional Specification

Building Automation System Functional and Technical Specification