A fault is a period of time in which a specified condition is true on a specific device.
For example, this is a fault:
@8:00am AHU-1 Could not maintain discharge temperature within setpoint for 5 hours.
To break this fault down to illustrate the definition…
There are a number of terms used within the industry to identify this concept, and their uses are not always consistent between parties so it is important to understand when these terms are used within the KODE Labs platform, what they mean in that context.
Alarms are the lowest and simplest level of condition checking. It is usually a check programmed within the BMS or available off of the device and use only one or two points of data to detect the condition. These are most commonly an error or failure condition detected within the device and outputted as such, or a check for exceeding prescribed limits, such as a temperature out of range. They are calculated and communicated instantaneously and do not have a need to exist outside the bounds of that evaluation.
What they are good at
Alarms are great at providing a way to identify, and immediately notify necessary parties of, critical events.
What they are not good at
As alarms are not meant to have meaning outside of the block of time in which they are triggered they are not the best inputs to extract holistic and actionable big-picture insights.
Zone Temperature Exceeds Maximum
Discharge Fan has Failed (error from device)
Freeze Status is in Alarm
Fire Alarm is Active
Events are the next level of condition checking. Events are used to identify a specific device condition that will usually require a check of several different inputs and or devices. Events should be set up to detect a wide array of conditions across varying levels of importance. Because of this, a proper Events module must contain several ways to filter and sort the data to help the user weed through the noise.
What they are good at
An Event can be useful as an instantaneous indicator and analyzed over a period of time to derive insights from any patterns that may arise.
What they are not good at
By themselves, Events can be very powerful. However, due to the excessive output that may arise from such condition coverage, significant effort is required from the user to sort through it to derive larger insights and/or diagnose issues.
Heating Not Active when Heating Required
Discharge Air Flow Lower than Expected
Simultaneous Heating and Cooling
Incidents are the highest level of condition checking within the KODE Labs FDD platform. Incidents are created by finding commonalities between groups of events through a number of different criteria.
Reference Based Grouping. For this grouping type, the program looks for events along ontology relationships.
For example, if it is detected that a VAV is not able to meet its room temperature setpoint, the incident engine will look to see if there is a problem on the AHU associated with that VAV and also look for issues amongst that VAV’s siblings. If any additional events have occurred along those relationships, they are all grouped together under a single incident.
The benefit of this feature is that it performs some of that root-cause analysis that nobody has time to do — ultimately reducing the number of identified conditions down to a manageable number that guides the user to understanding the real problem.
What they are good at
Bottom line: Incidents minimize time needed for troubleshooting and investigation, and maximize the effectiveness of maintenance operations.
What they are not good at
As Incidents are designed to make lives easier, the truth of the matter is no engine like this can catch 100% of all issues. There is still a need for engineers to sort through events and derive their own insights using their experience and knowledge. For this type of analysis, you are better served by Events.
Navigate to the FDD Events page by following these steps:
Access KODE OS and select a site.
From the main left side bar select FDD.
Select the “All” window where you can see all Events and Incidents
This page offers four key data views: Active, Historical, Stream, and All. These windows give you a comprehensive way to monitor live data, examine historical trends, track real-time activity, and view all data in one place.
Click on the “Filters” button to activate filter options.
Export: Clicking this button will enable you to export the filtered table as either .csv or .pdf format. Within that dialogue, you are also able to choose the columns in the table you wish to export.
On the Stream window, you can view a list of events and incidents. By clicking the Live button in the top right corner, you can access real-time data. Above the table, there’s a summary line showing the total number of events, along with counts for Life Safety, Critical, and Warning events.
Entering text into the search box will look for matches within the following fields
Event ID
Name (Routine)
Sortable columns: Columns with up-and-down arrows next to the column name are sortable. The icon updates to indicate if the column is being sorted ascending or descending.
Customizable column visibility & order: Clicking on the icon in the upper right of the table enables the user to hide and reorder columns.
Pagination: At the bottom of the table, see information regarding the size of the table and page. Change the setting for “Lines per page” by clicking the blue number range, next to that text on the right.
View the Event report: Click on a row to see the full details regarding that incident.
Selecting an Event from the list will redirect you to the event report page.
This section shows only the points that are referenced when evaluating the device for the stated condition. The red-shaded area indicates the duration of the event.
When a fault is detected, you'll now see recommended solutions to help you resolve it more quickly. Each FDD routine includes a set of possible fixes, allowing users to address issues efficiently. The solution library is fully customizable for each building and can be accessed via web, email, or mobile, providing flexibility in fault management from any location.
Block Diagram Sequence: This is the programming sequence that was utilized in discovering this incident. In KODE OS, this is referred to as a “Routine” and is selected for evaluation based on the device type.
Time Window Logic Block: A logic block that outputs true/false values based on predefined days and times. This allows users to trigger events exclusively during specified hours or dynamically adjust thresholds depending on the time of day. It’s particularly useful for automating actions or refining controls based on time-sensitive conditions.
At this page you have the option to select week days and hours when you want to have the routine active.
Customizable Priority Levels
Administrators now have the ability to configure between 3 to 5 customizable priority levels, each with unique names and colors. This enhancement offers greater flexibility in managing fault events, allowing for more tailored responses and improved prioritization based on specific operational needs.
After selecting the Priorities option, you'll see five categories: Life Safety, Critical, Warning, Alert, and Info. You can edit these categories and customize them to better fit your needs.
You can also add a new color according to your preferences. Please see the screenshot below for reference.
The row data for this event is from the Event table in the Event Landing Page.
Through this window, you can push external data sources.
The logged activity of changes regarding this event.
Here you can type any thoughts or comments regarding this event. Use the comments to take note of what you have discovered or what the next steps should be taken to resolve it.
Navigate to the FDD Incidents page by following these steps:
Access KODE OS and select a site.
From the main left side bar select FDD.
Select the “All” tab at the top of the page and select Incidents.
On this page, the default view is to see all of the open incidents, for the selected site.
This page is divided into three main components.
Click on the “Filters” button to activate filter options.
Export: Clicking this button will enable you to export the filtered table as either .csv or .pdf format. Within that dialogue, you are also able to choose the columns in the table you wish to export.
Entering text into the search box will look for matches within the following fields:
Incident ID
Building
Routines
For example, entering “Damper” will list all incidents that have a component routine that uses the word “Damper”.
Sortable columns: Columns with up-and-down arrows next to the column name are sortable. The icon updates to indicate if column is being sorted ascending or descending.
Customizable column visibility & order: Clicking on the icon in the upper right of the table enables the user to hide and reorder columns.
Incident summary reveal: On the right side of each row, there is an expand icon that when clicked, will reveal high-level details related to that incident.
Pagination: At the bottom of the table, see information regarding the size of the table and page. Change the setting for “Lines per page” by clicking the blue number range, next to that text on the right.
View incident report: Click on a row to see the full details regarding that incident.
Selecting an Incident from the list will redirect you to the event report page.
Incidents are visually represented using these two widgets, enabling us to gain a graphical understanding of where the event or events occurred.
Additionally, they display the average event duration. For more comprehensive event information, please refer to the Table View.
The Domain widget displays the domain in which the issue or failure has occurred. By hovering over the chart, you can view the specific number of failures within that particular domain. Meanwhile, the Device Types widget indicates the number of devices impacted by the incident. You can gain insight into the quantity of these
affected devices by hovering over this widget.
This is a timeline view of the same data provided in the Status & Areas widgets.
In this visualization, the number of devices affected are represented by the color value; the darker the color, the greater the number of devices affected.
This enables the user to identify insights and patterns along the time dimension.
This is the list of all Events that contributed to this Incident. Here you can do some preliminary analysis by sorting columns and looking for commonalities.
Click on a row to open up that Event Report.
Click on the device to go to its Device Details page.
If you want to be able to look at point trends across multiple devices, click on this button to open up a dialogue that will enable you to choose any combination of points across all devices impacted by this incident.
Once points are selected and applied, a new component will appear below the table containing that information.
This window provides information about the incident, including the building where it occurred, its priority level, start and end dates, its current status, duration, and acknowledgment status.
The logged activity of changes regarding this incident.
The individuals to whom this incident has been assigned are listed here. You can easily filter the Incidents Table on the Incident Landing Page to display only those assigned to you by selecting the checkbox labeled “show only assigned to me”.
In this section, you can enter any thoughts or comments related to this incident. Utilize these comments to communicate your findings or specify the next steps you would like the assigned person to take in order to resolve the issue.