The Challenge

Industry operators are monitoring systems today with hundreds of thousands of IO points, and receive thousands of alarms every day from real-time control systems that were built over decades. When an alarm is raised, the damage might already be done.

Introducing AI to operator workflows can provide valuable early warnings of abnormal states in the system, beyond what a SCADA system is programmed to detect.

Anomaly Monitor Design

Monitor Personas

Anomaly Monitor Design
“I can find the root-cause of an anomaly by prioritizing alerts and trouble-shooting data across multiple systems with 100.000’s of IO points and take early actions to prevent a M$ costly crisis”

Bryan is an Operator in a remote operations control center in an asset intensive industry. He works shifts and is assigned monitor responsibilities on one or more sites with control systems up to 100.000 IO points each. His organization needs to scale operations using a more automated solution designed to find the issues before an alert is triggered in control system so he can mitigate issues and impact before damage occurs or production halts. He needs real-time visibility, root-cause troubleshooting, and AI driven alerts at scale.

Anomaly Monitor Design

Oscar is an Application Administrator in IT Organization. He is responsible for administering the IoT solutions used by his line of businesses. He is installing, configuring and maintaining solutions like Maximo Asset Monitor for the operations team. With Maximo Asset Monitor and Anomaly Monitoring, he is responsible for configuring the asset information model, configuring anomaly models, alerts, and operational dashboards.

Anomaly Monitor Scenarios and Use-Cases

Anomaly Monitor Design

The following anomaly monitoring scenario has been identified and validated with design sponsors and early solution adopters.

Bryan the Operator needs to

  • Select the client systems to be monitored, assigned for the shift
  • Get an overview of current alerts and assets in trouble. Understand the location the asset and prioritize the severity for this type of alert
  • Trouble-shoot the alert by drilling into the data point, view, zoom and pan the current data in and around the time of the alert and compare to historical trends
  • Uncover root-causes of the alert by viewing and comparing related data points at system or process levels
  • Confirm system state on SCADA dashboard(s)
  • Take action by assigning service request

Configure Use-Cases

Oscar, the Application Administrator will perform the following use-cases when configuring the anomaly monitoring solution.

Configure Data Sources – Oscar will configure the connections to the external data sources to me monitored. For IoT Devices, he will register device types and devices in the IoT platform service. He will define the data schemas (interfaces) specifying the data to be stored in the data lake. In other cases, Oscar will configure the data connector to the SCADA control system to establish the data ingestion from selected IO points.

Configure Taxonomy – Oscar will configure the information model taxonomy by assigning classification dimensions and dimension values to the registered entities.

Configure Anomaly Models and Alerts – Oscar will work with the operators to identify normal and abnormal asset data behaviour and select best fit anomaly models for the monitoring case. He will configure the models on the entity types and adjust alert trigger thresholds based on valid alerts and false positives.

Configure Dashboards – Oscar will configure operational and performance dashboards based on the operational metrics and KPIs required by the line of business.

Monitor Use-Cases

Bryan, the Operator will perform the following use-cases when monitoring alerts from assets in trouble.

Monitor Alerts – Bryan will use the Alerts page in Maximo Asset Monitor to get an overview of alerts from the systems he is responsible for monitoring. He filters and sorts to prioritize the most critical alerts on the systems with largest risk and impact. He assign operator or engineering ownership of alerts to validate the root-cause.

Monitor Assets – Bryan will use the operational dashboards to get a summary of state across the systems and identify any assets in trouble. He will drill into the system decomposition by applying filters to the dashboards to discover areas of concern. He will identify alerts from anomalous asset behaviour and assign operator or engineering ownership of alerts to validate the root-cause.

Validating Alerts – Bryan will trouble-shoot the alerts and assets in trouble assigned to him. He will view and compare operational metrics and data from related locational or process assets. If the anomaly alert is proven to be a false positive he discards the alert. If the anomaly alert is validated he notifies the engineering team by creating a service request.

Creating Service Requests – Bryan will create service request in Maximo to initiate the scheduling and creation of a work order to inspect and repair the asset in trouble. The service request will be appended with the impacted asset id, the job plan, job code and links back to the asset. All available for the maintenance planner to be able to assign engineers to the task.

Anomaly Alert Design

Alert Information Model

Introducing anomaly monitoring in Maximo Asset Monitor required a redesign of the Alert / Event information model. In previous version of the analytics service, an alert function generated a time stamped Boolean event value. The previous event model has been deprecated and replace with the new alert model

A new alert information model was designs for anomalies specifically, and alerts generally. The new alert model consists of the following information elements.

  • Name – The name of the alert
  • Type – The alert function name
  • Timestamp – Time of triggering
  • Entity ID – The triggering entity id
  • Severity – Critical, High, Medium, Low, Undefined
  • Status – New, Validated, Acknowledged, Resolved, Dismissed
  • Owner – The assigned owner of the alert
  • Service Request – The ID of the Maximo service request generated

Some of the alert properties are configured on the alert function, other are generated at the time of triggering.

Alert Lifecycle

An alert in Maximo Asset Monitor has a lifecycle model defined by the alert Status property. The default status values are New, Validated, Acknowledged, Resolved, Dismissed. Status values may be extended by custom values.

The status value of a new alert is set by the alert function or API at time of creation. The design of the alert function proposes that the administrator can set the default status value in the function configuration panel.

Anomaly Monitor Design

The alert design do not enforce a formal alert state model with state transitions and actions. Maximo Asset Monitor is a monitor service for operator, not a work management service for maintenance teams. Hence, operators can freely set the status of an anomaly alert to any state value. It is assumed that formal Work Order management is performed by Maximo, or as an integrated workflow in a future Maximo Application Suite service.

To support the alerts state model, other alert properties like Owner and Service Request support the lifecycle model with additional state attributes. As a new alert has been triaged, i.e. inspected and prioritized, it may be set to a selected Owner assigned to perform the root-cause analysis on the alert. The design suggests that the owner is picked from the list of Maximo Asset Monitor users with the current user as the first name in the list.

As a root-cause analysis concludes the alert to be valid the status us set to Validated. Alternatively, the status is set to Discarded. The anomaly status information provided by validating or discarding an alert may optionally be used as quality input on the anomaly model. Manually, administrators may explore valid vs discarded alerts and time the model score thresholds. The AI model may also perform self-training by gathering data from alert status attributes.

Validated alerts may be used to formally or informally notify engineering teams to perform service on the asset. An operator may take action on an alert and create a Maximo Service Request. The design suggests that the action to create a service request should only be available to operators if a Maximo Service has been configured. The design to manage Maximo connections is discussed in a section below. As the root-cause of the anomalous condition is resolved the alert an be set to its final resting state of Resolved.

Alert Presentations

It should be noted that there is a bi-directional dependency between the alert and the entity. The alert is triggered on the condition of the metric data on an entity. And also, an entity has alerts triggering on its metric data conditions. This bi-directional dependency drives the presentation views of alerts. That is, presenting the alerts with entities as secondary sortable and browsable information. Or, presenting alerts in the filtered context of an entity on an entity dashboard. The two view are presented below.

The Alerts page is designed as a top level page for all, or filtered, alerts at the system level. It addresses one of the two main operator use-cases; Monitor Alerts.

The Dashboards are designs to present alerts information in the context of an entity scope. In a scope multiple entities filtered by a Summary Dashboard, or in a singular scope of an Instance Dashboard. In now dashboard cases, an alerts card can be added to the dashboard that automatically filters the presented alerts to the scope of the dashboard. The JSON definition of the dashboard card is short and simple with few options.

Anomaly Monitor Design

Alert table using column filters to display alerts by Severity, Status, Owner attribute.

    {
           “id”: “alerts”,
           “size”: “LARGE”,
           “title”: “Robot alerts from the last 3 hours”,
           “type”: “ALERT”,
           “dataSource”: {
                   “range”: {
                   “count”: -3,
                   “interval”: “hour”
                },
           “timeGrain”: “input”,
           “type”: “alert”
           }
    }

Alert Dashboard Card Designs

As Alerts in Maximo Asset Monitor is a time stamped computed metric. General dashboard presentation formats for computed metrics also apply to alerts.

  • Alert count metric on value cards
  • Alter count used in threshold conditional setting on cards
  • Alert count as time series values on a line or bar graph
  • Alerts grouped by entity id, or time grain in a page
  • Alerts listed by time stamp on a data table

Dashboard cards with alert information filters like any computed metric on summary dashboards and presents the count graph or list scope provided by the filter. Alerts may also be presented as annotations line graphs.

Anomaly Monitor Design
Alert dashboard card.
Anomaly Monitor Design
Custom alert dashboard card.
Anomaly Monitor Design
Line graph dashboard card with alert overlay.
Anomaly Monitor Design
Full size line graph dashboard card with alert overlay

Configuring Anomaly Models and Alerts

Data Panel Organization

Anomaly models and alerts are analytics functions that are managed in the entity data view.

With the introduction of monitor dashboards in Maximo Asset Monitor the existing design of the Analytics Service Data view started to become overpopulated with calculated and derived metric functions generated by dashboard configurations. Each dashboard requires a specific set of functions using the dimension grains selected for the dimension filters. A new design that better organize the metics by type was suggested. Metrics now group under Metrics, Metrics (Calculated) and Alerts (Calculated). This provides a better designed user experience to locate the input metrics and any anomaly models and alerts.

Anomaly Monitor Design
New Data Panel organization with expandable section for Metrics, Dimension and Alerts.

 

A further elaborated design has been proposed that group related functions under a logical section. For example, an anomaly model may be grouped under a single section with its input metrics, its model score and any alerts triggering on the model score. A section panel would provide scope and insight into the parts of the anomaly configuration.

A further elaborated design has been proposed that group related functions under a logical section. For example, an anomaly model may be grouped under a single section with its input metrics, its model score and any alerts triggering on the model score. A section panel would provide scope and insight into the parts of the anomaly configuration.

Data View, Graphs and Tables

One of the shortcomings in the previous designs of the Data View is the graph presentation and tabular data of a selected metric.

A new design for the data view was proposed adding consistency with dashboard presentation style and capabilities. First, the graphing technology was replaced with the Carbon Graph components used on the monitor dashboards. Secondly, a full table view with column filters, sort and CSV file explore was added. This provides more use-cases for exploration of data in the graph, or export of data to an external AI tools.

Anomaly Monitor Design
Data View with graphical presentation of metric and tabular view of data points.

Anomaly Models and the Function Catalog

As the scale and use of analytics functions are growing it was the right time to improve the overview, search and selection use-cases of analytics function, like anomaly models and alerts.

The new function catalog provide a user experience starting the alignment with the common Marketplace design pattern. User can browse, search and filter and select the function to use. And then move to configuring the selected function. A short description text provide guidance on the usage and considerations. A further elaborated design explored the use of a drill-in page to view details before selecting the function.

Maximo Asset Monitor ships with a set of out-of-the-box anomaly functions general or optimized for various data behaviors and anomaly types. Most functions depends on a single input variable and a data window size. The models generate a score that express the likelihood of an anomaly detected in the time window of data points. The anomaly model lets window scan the time series data points and generates a time series score metric. The score is configured as an input to an alert function that triggers on a score threshold. The threshold is set to a default value and modified from empirical analysis of known anomalies and computed model scores, vs false positive alerts. The data view of the anomaly scores and the alerts are helpful in monitoring the monomials model performance and health.

Anomaly Monitor Design
Anomaly model functions in catalog.
Anomaly Monitor Design
Anomaly model configuration.
Anomaly Monitor Design
Alert functions in catalog.

Configuring Maximo Services

As discussed above, an action can be taken on an alert to create a new service requests in Maximo. The Create Service Request action is only available to operators if a Maximo Service has been created.

The new design for Maximo Asset Monitor suggests that he purpose of the previous Usage section should be extended and renamed to Manage Services. This would make the administration sections in Maximo Asset Monitor more consistent across Manage Users, Manage Services and new asset hierarchical designs suggesting a Manage Taxonomy section.

The Manage Services provides a new design for creating and configuring a Maximo Service connection. With a Maximo Service configured, operators can create new Maximo service requests directly and consistently from any alert page, alert function or alert card on dashboards. In the service request dialog, one of the Maximo services is selected.

Anomaly Monitor Design
Manage Services page.
Anomaly Monitor Design
Creating a new service request in alerts table.
Anomaly Monitor Design
Adding new Maximo Service connection.
Anomaly Monitor Design
Create a new Maximo service request.

Anomaly Monitoring Scenarios

A few anomaly monitor design scenarios has been developed to design, playback, socialize and demonstrate the designs. Lean more about the use of anomaly monitoring designs in these design scenarios and hands-on labs.


Robot Monitor Scenario Design

Design of an Asset Monitor Anomaly and Dashboard scenario using simulated robots.


Mastering Dashboards in Maximo Asset Monitor

Hands on Lab for a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.


Munich IoT Monitor Scenario Design

Design of an Asset Monitor Facility, Anomaly and Dashboard scenario using live sensors at the Munich IoT Center.


Maximo Asset Monitor 101

Hands on Lab  on IBM Maximo Asset Monitor.