Introduction

This document explains how Enum Mappings impact the rules used by our Fault Detection and Diagnostics (FDD) and Functional Testing Tool (FTT) within the platform. It highlights the importance of correctly configuring enumMappings to ensure these rules work as intended.

What Are Enum Mappings?

Enum mappings play a vital role in our platform. They define how specific data points are understood and processed by FDD and FTT rules. Simply put, they link raw data values to their intended meanings, enabling accurate fault detection and diagnostics.

How Enum Mappings Impact FDD & FTT Rules

Example Scenario

Imagine a case where Enum Mapping Blocks are used in FDD rules to process data points from different sources. One common challenge arises when setting up enumMappings for a particular group of enumerated values.

Common Issue

When processing data points with enumerated values, the system may receive a range of possible values from the API. For example, enums like the following might be included:

• "Disconnected"

• "Connected"

• "Factory_Default"

• "Long_Failed"

• "Initializing"

Enum Mappings and Their Importance

If only two values, such as "Connected" and "Disconnected", are mapped correctly, these are the only ones recognized as valid "Enum Values." Other values, like "Factory_Default" or "Long_Failed", will not be identified as enums unless they are explicitly defined. When unmapped, their status defaults to "Unknown" (an example is provided later in the document).

In programming terms, this means enum values are processed like this:

"pointEnum": [

"Disconnected",

"Connected",

"Factory_Default",

"Long_Failed",

"Initializing"

],

"readMap": [

{

"key": "Connected",

"value": "Connected"

},

{

"key": "Disconnected",

"value": "Disconnected"

}

],

On KODE OS, mappings like the following apply:

• "Connected" → "Connected"

• "Disconnected" → "Disconnected"

Mappings can also group multiple related values under one interpreted category. For example:

"Fan Only" => translates to  "Cooling"

"Cool_Stage_1" => translates to  "Cooling"

"Cool_Stage_2" => translates to "Cooling"

"Economizer Cooling" => translates to "Cooling"

"Emergency_Heat" => translates to "Heating"

"Heat_Stage_1" => translates to "Heating"

"Hot_Gas_Reheat" => translates to "Heating"

... and so on

Why Accurate Enum Mappings Matter

It is critical to configure enumMappings precisely within the platform (e.g., BMS).

Misconfigured or missing mappings can lead to:

• False interpretations of data.

• Incorrect fault detection, affecting the reliability of FDD rules.

Important Note: Enumerated values are case-sensitive.

Case Sensitivity Example

If the expected enum value is "Disconnected", but the system receives "DISCONNECTED" or "LONG_FAILED", it will not match any predefined mappings.

For example:

Expected enum values:

• "Disconnected"

• "Long_Failed"

Reported values:

• "DISCONNECTED"

• "LONG_FAILED"

When values don't match, the system assigns a status of "Unknown", which disrupts fault generation in FDD rules.

Example output:

{

"curStatus": "ok",

"curVal": "DISCONNECTED",

"mappedValue": "Unknown",

"time": "2024-05-06T18:56:46.360+0000",

"changelog": "CHANGE"

}

Scenario 2: Enum Mappings Not Configured Correctly

If the Ontology Report shows unexpected results, it indicates that the readMap values are not configured properly.

This misconfiguration prevents the generation of events because required mappedValues like "Normal" and "Alarm" are missing. These values are essential for the FDD and FTT systems to function correctly and trigger events as expected.

Without these mappings, the system cannot interpret the data points properly, leading to errors and missed event generation.

Key takeaway: Ensure all required enumMappings, such as "Normal" and "Alarm", are accurately defined to avoid disruptions in event processing.