Logic and Analytics

This article explains what logic is, how logic modules work, sharing logic, and how this is all managed with Logic Builder.

 

 

 

What is 'Logic'

Logic is one of the fundamental building blocks for any project on the Platform. This is where rule-based fault detection modules are created, shared, and managed. This is managed in the Logic Builder.

 

The general logic creation workflow is:

Build → Share → Install → Reprocess

 

Each of these steps will be covered in this section. Note that the reprocessing step is an optional process - it is not required for the successful creation and deployment of logic. It is performed for the vast majority of logic deployments however.

The outcome of the creation and deployment of logic is ‘alerts’. Alerts are created during periods where the logic modules return a ’TRUE’ result.

 

Logic Example

The figure below shows the discharge temperature of an AHU over time. The point is to find out if the discharge temperature of this equipment is meeting the Discharge Temperature Setpoint (SP) that has been set for this unit. A logic module must be created to do run this enquiry continuously.

There thresholds were set in the logic module:

• Low Severity: when the discharge temperature is 1°C above SP.
  
  
• Medium Severity: when the discharge temperature is 2°C above SP.
  
  
• High Severity: when the discharge temperature is 3°C above SP.

 

The logic module is set to only evaluate the discharge temperature when the equipment point called 'Cooling' is set to ‘ON’. Also, the logic module is set to send an email when a ‘High Severity’ alert is triggered.

According to the image below, 2 Low Severity alerts, 1 Medium Severity and 1 High Severity alert have been generated during this time period. The periods corresponding to when the alerts were triggered are highlighted in the graph.

This logic module will continue to run and evaluate the performance of this device constantly until the module is disabled.

Figure 29. An Example of Fault-detection.

 

The remainder of this section will detail how to build, share, install and reprocess a module like the one in the example above.

 

The GAL, PAL and Local logic

Logic modules are created and managed at a site level, and all logic modules belong to a specific site within a portfolio. For a given portfolio, logic generally lives in one of three places:

 

1. 'Locally' in the site it's being deployed on

   Logic lives within the Logic Builder for an individual site. The logic modules reference site-specific points. Creating logic locally is only recommended for unique, site specific logic modules.
   
   
2. 'Regionally' in a Portfolio Analytics Library (a PAL)
   Logic exists within the Logic Builder of user-created dedicated Portfolio Analytics Library (PAL) sites. This site is simply like any other within the portfolio except it does not have data points posting data. Here users build logic modules using generic templates and share the logic to each site.
   
   
3. 'Globally' in the Global Analytics Library (the GAL)
   Logic lives in a Switch-curated library. Users can pull down these modules from the GAL to their PALs, or deploy directly to their Sites. Users cannot edit the GAL modules directly, but can edit copies of them by pulling them into their PAL. The modules in the GAL use generic templates.

 

Creating the same logic modules locally in each site is generally not the most efficient workflow - the Portfolio Analytics Library is recommended for the majority of your logic development. It is a site dedicated solely to analytics, and it keeps all logic together in one place.

Figure 30. Logic Module Locations.

 

Anatomy of a Logic Module

Logic modules are composed of ‘scenes’ and ‘layers’.

 

Layers

A layer represents a self-contained logical expression (i.e. ‘is x > 5 ?’).

The subject of the layer is a data point (e.g. ‘is AHU-05-HNE Supply Air Temperature > 5 ?’) or a template (e.g. ‘is SupplyAirTemperature > 5 ?’). The target of the layer can be a static value or another data point or template (e.g. is 'SupplyAirTemperature' > 'SupplyAirTemperatureSetpoint' ?). Users can pick from a predefined set of logic operators to use in the logic modules.

 

Scenes

A ‘scene’ is a collection of layers which are combined on evaluation.

Each scene contains a number of combined layers (with ‘AND’), returning a ‘‘TRUE’’ or ‘‘FALSE’’ result upon evaluation. A logic module can contain multiple scenes, each of which may contain multiple layers, with the results of the scenes combined (with 'OR') to return the final logic module, reading either ’TRUE’ or ’FALSE’.

Each scene is evaluated over a user-specified time period, only returning ’TRUE’ when all the layers return ’TRUE’ over the entire time period. Scenes can also be configured to evaluate only under certain conditions, to raise different severities of alerts, or to operate on schedules.

The final component of a logic module is an 'action' scene within each logic scene. The 'action' scene is activated when the logic scene it is attached to returns ’TRUE’. The action scene contains layers that dictate what action the logic scene should perform when it is ’TRUE’, ranging from raising an alert to sending an email to the entire facilities management team.

Figure 31. Anatomy of a Logic Module.

 

Overview of the Logic Builder

Logic is created, shared, installed, reprocessed and managed in the Logic Builder. Logic modules are created and managed at a site level, in other words, all logic modules belong to a particular site within a portfolio.

 

Navigate to Logic Builder through:

 → Logic Builder

 

The Logic Builder interface is split into three sections:

1. Timeline View	where logic modules are built.
2. Sharing View	where logic modules are shared and installed.
3. Reprocess View	where installed logic modules are reprocessed.

 

The view can be changed by using the three large icons on the left-hand side of the page. Logic modules can be selected by using the drop down at the top of the page. The state of any processes the logic module is undergoing are shown at the top of the page. More detail on each view is covered below.

Figure 32. Logic Builder Timeline View.

 

Sharing and Installing Logic

Overview

The second step in the logic creation process is sharing. Sharing logic is the key operation in this entire process, and understanding sharing is understanding logic, templating and tagging.

Sharing is the process of linking a logic module to the building equipment that has been imported onto Platform.

Installing is the process of enabling shared logic modules to run.

 

How Sharing Works

Sharing logic involves leveraging tags and templates.

As explained above, a logic module consists of scenes and layers, with each module including a number of scenes. Each scene contains a number of layers, with each layer referencing a data point or template.

 

Data Point vs. Template

The distinction between a data point and a template is crucial in the context of logic. The 'GAL, PAL and Local Logic' section above described how users can make logic locally using site-specific data points, or 'regionally' using templates; but what is the difference between modules made in these ways?

To summarize, there is essentially no difference, except in the way that module component layer names are displayed. All logic module layers referencing point data use templates.

Users apply object templates to every point that they import into the platform.

Figure 33. VAV 01 Points with Object Templates.

 

As mentioned, logic modules are site-based items, using points within the site to construct their logic, in the form of layers. If users want to create a logic module for the 'VAV_01' equipment above that checked whether the zone temperature was above the daytime zone temperature setpoint, they would use the following points:

• VAV_01 - ZoneTemp
• VAV_01 - DaySP

 

Using the terminology defined earlier, the subject of the logic layer is ‘VAV_01 – ZoneTemp’ and the target is ‘VAV_01 – DaySP’. The logic layer reads:

VAV_01 - ZoneTemp > VAV_01 - DaySP

 

The logic appears as the following layer:

The Platform processes logic based on the object templates used in the layers, not the display names. Since an object template was applied to each data point when they were imported, the point names can be simply swapped for their respective object templates to show what the Platform ‘sees’. The object templates used are:

• SpaceTemperature
• OccupiedCoolingSetpoint

 

The new logic layer view would read:

SpaceTemperature > OccupiedCoolingSetpoint

 

This is how the user-created logic module built with data-points appears to the Platform. If this logic module was built on the platform using these object templates directly, it would appear as shown below.

 

So, to summarize again:

All logic modules are a collection of object template references

Logic modules built using site-specific data points simply have a 'display name' hiding the object template, for example 'VAV_01 - Space Temperature' instead of ‘SpaceTemperature’. It is therefore recommended that users use PAL when building logic that will be shared to multiple sites. By using the object templates directly, it is much easier for users to understand what is going on with the logic module when it has been shared to a different device, since it does not have the original point name (i.e. VAV_01) attached to it.

What follows is a description of how object templates enable the sharing of logic modules.

 

The Sharing Process

As established above, each logic module is a collection of object template references. In order to apply each logic module to a piece of equipment on the Platform, each of the object templates in the logic module must connect to reciprocal object templates in the equipment data points - otherwise the logic module will not pull in data.

The image below shows the logic module we created above ('Hot Space Temperature') being shared with the equipment we imported (VAV_01). The logic module consists of two object templates that match with the corresponding points assigned to those object templates in VAV_01: 'Zone Temp' and 'DaySP'.

Figure 34. Successfully Sharing a Logic Module to VAV_01.

 

In other examples, points on the Platform were logically grouped into 'equipment', and any other desired groupings, by the user using tags. Therefore in order to share to 'equipment', we share to tags.

Figure 35. The Sharing Process.

 

At a high level, the operations performed by the platform when sharing are as follows:

1. Share the logic module to the tag group.
   
   
2. Share the logic module to all tags under the tag group.
   
   
3. For each tagcheck that every object template used in the logic module can be found in the points under that 

Next is the previous example for reference. Below shows VAV_01 and the tags we have assigned to each point. We have also added a second VAV to the site called VAV_02. Please note that tag groups are the column headers in the 'TAGS' section of the table.

Figure 36. VAV_01 and VAV_02 with Tags.

 

1. Share the logic module to a tag group
   Logic modules are shared to tag groups. As a reminder, tag groups are containers in which tags can be collected. For example, a tag group of 'VAV' may have the tags 'VAV01', 'VAV02', and 'VAV03' within it.
   
   
   When a user shares a logic module to a tag group, the platform will determine the number of 'collections of points' under that tag group that need to be evaluated. The number of 'collections of points' is represented by the unique number of tags.
   
   In this example, if the user shares the logic module to the tag group 'VAV', the Platform will determine that there are two collections of points that need to be evaluated, represented by the Tags 'VAV01' and 'VAV02'.
   
   
   
2. Share the logic module to all tags under the tag group
   For each tag, the platform gathers all the points that feature that tag from within the tag group.
   
   Using this example, for the tag 'VAV01', all points shown under device VAV_01 would be gathered, as they all have the tag 'VAV01'. The same applies for tag 'VAV02' - all points shown under VAV_02 would be gathered.
   
   
   
3. For each 'collection of points', users should verify the presence of the logic module’s object templates
   Each logic module is a collection of object template references. For the logic module to successfully share to a tag, each of the object templates in the logic module must match to a point under the tag with the same object template.
   
   In this example, the logic module 'Hot Space Temperature' contains the object templates 'SpaceTemperature' and 'OccupiedCoolingSetpoint'.
   
   When a user shares the logic module to the tag 'VAV01', each object template in the logic module search through the 'collection of points' under the tag, searching for a point with the same object template. In this case those points are 'VAV_01 - DaySP', and '_VAV_01 – ZoneTemp.'
   
   When a user shares the logic module to the tag 'VAV02', the same processes occurs, with the logic module matching to the points 'VAV_02 - DaySP', and 'VAV_02 – ZoneTemp.'
   
   
   If the logic module fails to match one of its object templates to a point under the tag, the logic share will fail for that tag and the logic module will not run on that tag. The following section shows what this looks like on platform.

 

Installing

Once a logic module is shared, the user must then confirm the tags the module has been matched to and that the logic module should start running. This step is called ‘installing’. It includes selecting the tags to which the logic module was successfully shared and clicking the 'Install' button. Only successful shares can be installed. The in-platform process is detailed in the workflow section below.

Most logic modules for BACnet/IP Sites run on the gateway itself. That is why this process is called 'installing' - the logic modules exist on the Platform and are downloaded and installed on the physical gateway on-site.

 

Sharing flowchart

An example of the sharing process for the 'Hot Space Temperature' logic module defined earlier to the AHU tag group is shown below. In this case, the sharing process fails for the tag 'AHU-03' because the collection of points under that tag does not have the object template 'OccupiedCoolingSetpoint' assigned to any of the points.

Figure 37. The Sharing Process.

 

How to Share and Install a Module on Platform

Now that we understand how the sharing process works, we can effectively share logic modules. Before exploring logic module creation, the following will feature a completed logic module that needs to be shared out to site equipment. Users can manage logic sharing in the sharing view of the logic builder.

 

The Sharing View

Figure 38. Sharing View in Logic Builder.

 

The sharing view comprises of three distinct sections:

 

Sharing Settings

This is at the top of the view. Here users select the logic module they want to share, the tag group this logic module should be shared to, and whether the logic module should be shared to all sites in the Portfolio ('Share to Portfolio'). This final option allows logic modules built in a PAL or any other site to be shared to any site within the portfolio.

 

Sharing Results

This is the main portion of the view. Here a list of all tags under the tag group is shown, with each tag showing whether the logic module was able to match its object templates with the points under that tag. The success of the matching process is shown under the 'Matched' and 'Status' columns in this view.

 

Individual Sharing status summary

The share status summary window is on the left-hand side of the view. If the user selects a tag (row) from the sharing results view, a breakdown of the individual object template share statuses shows.

Figure 39. Logic Module Tag-sharing Status Summary.

 

The object templates that comprise the logic module appear in the left-hand column, and the corresponding points under the tag are in the right-hand column.

In the example shown, the logic module has three object templates: 'Space Temperature,' 'MechanicalVAVCommand', and 'AirSpaceAirTemperatureSetpoint'. These successfully match to the points 'VAV - L28 - C10-RMT', 'VAV - L28 - C10-OCC-CMD', and 'VAV - L28 - C10-ACT-RMT-SP' under the tag 'VAV-L28-C10.'

 

Workflow

To share a logic module:

1. Navigate to logic builder.
   
   
2. Select the 'Sharing' view.
   
   
3. Select the logic module to be shared from the drop-down list.
   
   
4. Select the tag group the logic module is to be shared to from the drop-down list.
   
   
5. Select whether the logic module should be shared only within the site it belongs to, or to all the sites in the portfolio.
   
   
6. In the top-right corner of the view, click the ‘Share’ button.
   
   
7. Wait for the sharing process to run.
   
   
8. Once the logic module shares, the sharing results section of the view populates, displaying the sharing status for all tags under the tag group. Users can filter by successful shares using the pre-built filter buttons.
   
   
9. If the logic module fails to share to certain tags, users can investigate by clicking on the failed rows and analyzing the information in the individual Sharing status summary window.

Figure 40. Some Successful Shares.

 

To install the logic modules, perform the following steps – note this process follows on directly from the share process above):

Installing Logic Modules

1. From the list of successful shares, select the equipment (tags). The logic should run on by clicking the selection box on the left-hand side of the row.
   
   
2. Click the  button in the top right-hand corner of the sharing results area.
   
   
3. Wait for the installation process to run.
   
   
4. If the installation is successful, the 'Installed' column will display a tick for each row.

Figure 41. Install Successful Shares.

 

A logic module has now been successfully shared and installed.

 

Creating Logic

Overview

Logic can be added to a site by:

1. Creating it from scratch.
   
   
2. Copying it from an existing module.
   
   
3. Importing it from another site or portfolio.

All of these processes are covered below.

Creating and building logic does not mean that the logic is running on a site.

For logic to run, it must be shared and installed to each site. Building logic is entirely separate to the sharing and installation step.

Figure 42. Adding Modules in Logic Builder.

 

Creating New Logic

New logic is created in the timeline view of logic builder.

Figure 43. Timeline View of Logic Builder.

 

Figure 44. Creating a new logic module.

 

Add a New Module

To add a new blank logic module:

1. Click the 'Add' button and select 'New Conditions + Actions'.
   
   
2. Name the new logic module.
   
   
3. Name the new scene.

Once this process is complete, the logic module can be saved.

Figure 45. Adding Layers.

 

Add Layers

Layers can now be added to the scene. To add a layer:

1. Click on the library icon on the left-hand side menu.
   
   
2. Use the search bar to find the subject of interest. This will either be a pointfor local logic or a template for PAL logic.
   
   
3. Click and drag the search result item from the library into the scene, as pictured.

Users can add as many layers as needed to the scene.

Figure 46. Setting Layer Parameters.

 

Set Layer Parameters

Once the layer subject row is added, the logical expression can then be set:

1. Click on the layer.
   
   
2. Click on the ‘Properties’ icon in the left-hand side menu.
   
   
3. In the resulting window, can choose the logic operator and target value. The target value of the logic expression is referred to as the [FrameValue] in Logic Builder.

Figure 47. Setting Window Length.

 

Set the Scene Time Period

Once the logic scene has been set-up, users can set the 'Window Type'. This is the period of time over which the layers must evaluate to ’TRUE’ for the entire scene to return ’TRUE’. Users have two window types to choose from:

1. No window: the scene will return ’TRUE’  whenever all the layers return ’TRUE.’
   
   
2. Sliding Window: the scene will return ’TRUE’ when the layers have all returned ’TRUE’ for the entire window length.

 

An example of a sliding window:

Figure 48. Adding an Action Layer.

 

Add an Action Scene

The action scene already exists for each logic module, and users can add layers. The process for adding an action layer is the same is adding a logic layer:

1. Click on the ‘Library’ icon in the left-hand side menu.
   
   
2. Select 'Actions' from the drop-down type list.
   
   
3. Click and drag the desired action item from the library into the scene, as shown.
   
   
4. Set the layer parameters in the same way as for a logic layer.

Figure 49. Adding a Scene.

 

Add another Scene

Users can add another scene to a logic module in one of two ways:

 

Creating a New Blank Scene

Clicking the  button will create a new blank scene within the logic module.

 

Copying the Existing Scene

Clicking the  button next to a scene’s name will duplicate that scene within the logic module. Users can then rename and edit the new scene as required.

 

Saving Changes

Please note that changes to logic modules will not be stored in the Platform if users navigate away from the logic builder timeline view without saving.

This can be useful if users make changes but ultimately want to reset the module to its save state. Doing a browser refresh will revert logic modules to their last saved state.

 

Importing from Existing Local Logic

Because continuously recreating logic modules is not a practical workflow, the Platform permits users to copy any of their logic modules between, or within, any sites and portfolios they have access to. As with all other logic creation operations, the process begins in the timeline view of the Logic Builder.

Figure 50. Creating a New Logic Module.

 

To add a copy of a logic module to a site:

1. Click the 'Add' button and select 'From Existing'.
   
   
2. Select the portfolio and site of interest in the pop-up that appears.
   
   
3. Select the logic modulesto be copied. Please note that multiple selections are permitted.

Figure 51. Edit Before Duplicating.

 

Once the logic modules are selected, the pop-up will progress to a view similar to the one shown on the left.

Here users can rename the copied logic module and change the subject of each logic layer. This is shown under the 'Devices' heading in the image. Note that the current subject of each logic layer is shown in the left column and the new subject of each layer is shown in the right column. If users choose not to make any changes here, the logic module will be copied exactly as it is defined in the source site. Users are free to edit the module later in the timeline view after it has been duplicated.

This view is presented for every logic module being copied.

 

Using a PAL

A PAL is a site within a portfolio dedicated to housing logic modules, and a portfolio can include multiple PALs. It is recommended that users build logic modules once and store them within a PAL for use across their entire portfolios.

 

Creating a PAL

The process for creating a PAL is the same as for creating any other site, since the PAL is a normal site that is only being used for logic module storage. However, instead of discovering and importing real points into the site, users simply import lists of templates as the 'points' for their sites. This means templates are used as layers in Logic Builder for site.

The steps to create a PAL are as follows:

1. Navigate to the ‘Admin’
   
   Navigate to Admin through:
   → Admin

2. Follow the standard process to add a site.
   At Switch, PALs are generally named 'Alerts Library' or 'Analytics Library'.
   
   It is recommended to set the PAL site status to 'demo'. This prevents it from being included in the map overview page and any other portfolio summary pages.

3. Once the site has been created, navigate to Site Builder.
   Navigate to Site Builder through:
   → Site Builder

5. Add a BACnet/IP block to the diagram for the site.
   In this example, the BACnet/IP block is in use for the PAL as it allows for importing a set of points that can be used in Logic Builder. In this case, the set of points will be a list of templates. The PAL is not a live site and does not use the full BACnet/IP block functionality.
   
   In the future, the Platform will feature a dedicated method for creating a PAL that does not require a creative work-around.
6. Right-click the 'ethernet' node and select 'Import Devices'.
   
   
7. Drag and drop the PAL Template 'Device List' into the pop-up.
   The PAL template 'Device List' is a list of all object templates in the platform formatted in such a way as they are read in as points.
   
   
8. Click ‘Import’.

 

Creating Logic in the PAL

Logic modules can be created in the PAL in the same way they are created on any other site. The only notable difference is that instead of referencing equipment points, the logic modules built in the PAL will reference the raw object templates. This difference does not affect the creation process.

 

Importing from the GAL

The GAL contains a multitude of Switch-curated logic modules and scores. Importing from the GAL is straight-forward, and as with all other logic creation operations, the process begins in the timeline view of the Logic Builder.

Figure 52. Creating a New Logic Module.

 

To import from the GAL to a site:

1. Click the 'Add' button and select 'From Global Analytics Library'.
   
   
2. Select the logic modules to be copied in the pop-up that appears, bearing in mind that multiple selections are permitted.

Figure 53. Edit Before Duplicating.

 

Once the logic modules are selected, the pop-up will progress to a view similar to the one shown on the left.

Here users have the opportunity to rename the imported logic module and change the subject of each logic layer. This is shown under the 'Devices' heading in the image. Please note that the current subject of each logic layer appears in the left column, and the new subject of each layer is in the right column. If no changes are made here, the logic module will be copied exactly as it is defined in the GAL. Users can always edit modules later in the timeline view after it has been duplicated.

This view is presented for every logic module that is being imported.

 

Scene Conditions

In the ‘Creating Logic’ workflow, layer parameters, window parameters and action scene parameters were all discussed. There is one additional set of parameters that are useful when creating logic modules called ‘scene parameters’.

Users can access scene parameters by clicking the  button in the ‘Logic Scene’ name tab.

Scene parameters enable users to set behaviors around how many times within the time period layers must return ’TRUE’ readings before the scene will return ’TRUE’. For example, users may require a count of the number of times the scene is been triggered within a time period. This can be useful, for instance, if a point has changed value a certain number of times within a given time period.

 

An Example of Scene Parameters

A user wishes to know if the operating mode of a VAV switches between heating and cooling too frequently over the course of a day. To do this, the user builds a logic module that leverages scene parameters options. The layer logic for this scene is:

‘VAVMode hasChanged’

The layer will return ’TRUE’ whenever the point with the ‘VAVMode’ object template changes value in an interval.

The user is not concerned with the VAV changing mode only once in a day though, as that would be normal behavior for such equipment. The user therefore sets a limit of 5 mode changes per 6-hour period as their threshold for excessive mode changes.

In the scene parameters settings, the user sets the scene condition to trigger only when the layer returns a ’TRUE’ reading more than 6 times over the course of 6 hours.

Now this logic module will only return ’TRUE’ when the layer has returned ’TRUE’ more than 5 different times over the course of the window length.

Figure 54. Logic Module with Scene Conditions Enabled.

 

Modifying Logic

Users can edit any logic module at any time. If a given logic module has already been shared and installed, a user will need to run a ‘Merge’ operation to ensure the updated logic is still valid for the equipment it has been previously shared to. Merging after changes is a straightforward process, detailed below:

1. If users edit a logic module that was already shared to onsite equipment, this warning will display in the top right-hand side of the Logic Builder:
   
   
   
2. To remove this warning, users must 're-share and install' the logic module. This is a process called merging.
   
   
3. Navigate to the sharing view of Logic Builder.
   
   
4. Select the updated logic module from the drop-down list.
   
   
5. Click the  button in the top right-hand corner of the page.
   
   
6. Wait for the Merge operation to run.
   
   
7. Select successful merges (or ‘shares’) from the Sharing Results window and install as per normal (click ).

This process is identical to the share and install process detailed in the Sharing section of this article, we simply refer to it as 'merging' when the logic module has been shared and installed before.

This entire process can be conducted in one-click if users desire, simply by selecting the 'Merge and Install' option when clicking on the  button. This method ensures the logic module is automatically installed to all tags where sharing is successful.

 

Deleting Logic

It is important to follow the steps below when deleting logic. In the future, this process will be automated; for now, it is users’ responsibility to ensure logic is deleted correctly.

 

Deleting Logic

In some cases, logic is installed on the physical onsite gateway. When a logic module is deleted, users must ensure it is removed from the gateway at the same time, or else the logic module will continue to run on the gateway and users will not have access to it through Logic Builder. To delete a module:

1. Navigate to Logic Builder’s sharing view.
   
   
2. Select the desired module from the drop-down list.
   
   
3. Select all rows and click .
   
   
4. Wait for the process to complete.
5. Now that the logic moduleis now removed from the gateway, users can now click  to unlink the module from any site.
6. Wait for the process to complete.
   
   
7. The logic moduleis now completely standalone, just like when it was first created. Either leave the module sitting in Logic Builder for future use, or delete it by clicking .

 

It is imperative to uninstall the logic module from the gateway before deleting it. 

 

Reprocessing Logic

Overview

As described above, logic is typically processed on a local gateway as the data is received, before then being posted to the cloud. This works well for live data, but if users create new logic modules several months after a site has been connected, it’s crucial to establish whether or not months of data have collected triggers for this new alert.

‘Reprocessing’ allows users to evaluate a logic module against a site’s historical data and post the generated alerts and scores data to the Platform.

Reprocessing takes place on Platform cloud servers rather than gateways, because the reprocessing requires access to historical data, and can be a computationally demanding depending on the logic module, the number of tags it has been shared to and the period of time it is being reprocessed over.

 

Process

The reprocessing feature is the third control button in the Logic Builder workspace:

Figure 55. Reprocessing in Logic Builder.

 

To Reprocess a module:

1. Select the desired module from the drop-down list.
   
   
2. Click the 'Start' button.
   
   
3. Select the date range the reprocessing should occur over.
   
   
4. Choose whether any generated alert or score data should be written to the platform. For example, populate Alerts Analysis or the Scores Dashboard with results.
   
   

Reprocessing time is contingent on the nature of the logic module, the number of devices it is installed on, and the time period reprocessing occurs over. Once it starts, users can monitor the reprocessing progress in the main window.

 

Appendix: Logic Operators

Logic Operators

The table below details the logic operators currently available in the Platform. Some important in-platform terminology is also defined below.

The ‘DevicePropertyValue’ represents the live data of the selected point in Logic Builder.

The ‘[Frame Value]’ represents another data point, virtual meter or static value that users may want to compare.

Logic Operators
Operator	Name	Description
==	“equal to”	triggers if the DevicePropertyValue is equal to the [Frame Value].
≠≠	“not equal to”	triggers if the DevicePropertyValue is not equal to the [Frame Value].
<<	“less than”	triggers if the DevicePropertyValue is less than the [Frame Value].
≤≤	“less than or equal to”	triggers if the DevicePropertyValue is less than or equal to the [Frame Value].
>>	“greater than”	triggers if the DevicePropertyValue is greater than the [Frame Value].
≥≥	“greater than or equal to”	triggers if the DevicePropertyValue is greater than or equal to the [Frame Value].
(a,b)(a,b)	“between”	triggers if the DevicePropertyValue is between a and b (exclusive).
!(a,b)!(a,b)	“not between”	triggers if the DevicePropertyValue is not between a and b (exclusive).
[a,b][a,b]	“in range”	triggers if the DevicePropertyValue is between a and b (inclusive).
![a,b]![a,b]	“not in range”	triggers if the DevicePropertyValue is not between a and b (inclusive).
Δ	‘hasChanged’	triggers if the DevicePropertyValue has changed value in any interval.
a0=aia0=ai for i=1→ni=1→n	‘hasNotChanged’	triggers if the DevicePropertyValue has not changed value in any interval.
Δ	‘hasChangedBy’	triggers if the DevicePropertyValue has changed from the [Frame Value] by a user-specified amount in one interval.