Anomaly Monitor Design
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.
Monitor Personas
Bryan the Operator
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 the 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.
Oscar, the Application Administrator
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
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 of 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 be 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 behavior 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 the largest risk and impact. He assigns operator or engineering ownership of alerts to validate the root cause.
Monitor Assets – Bryan will use the operational dashboards to get a summary of the 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 behavior and assign operator or engineering ownership of alerts to validate the root cause.
Validating Alerts – Bryan will troubleshoot 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 a 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 are 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 the previous version of the analytics service, an alert function generated a time-stamped Boolean event value. The previous event model has been deprecated and replaced with the new alert model
A new alert information model was designed 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, others 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 the time of creation. The design of the alert function proposes that the administrator can set the default status value in the function configuration panel.
The alert design does not enforce a formal alert state model with state transitions and actions. Maximo Asset Monitor is a monitor service for the 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 is 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 the section below. As the root cause of the anomalous condition is resolved the alert can 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 views 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 designed to present alert information in the context of an entity scope. In a scope, multiple entities are 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.
{
“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 filter like any computed metric on summary dashboards and present the count graph or list scope provided by the filter. Alerts may also be presented as annotations line graphs.
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.
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 external AI tools.
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 provides a user experience starting the alignment with the common Marketplace design pattern. Users can browse, search and filter and select the function to use. And then move to configure the selected function. A short description text guide 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 depend on a single input variable and a data window size. The models generate a score that expresses 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 help monitor the anomaly model performance and health.
Configuring Maximo Services
As discussed above, action can be taken on an alert to create a new service request 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 the 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 Monitoring Scenarios
A few anomaly monitor design scenarios have been developed to design, playback, socialize and demonstrate the designs. Learn more about the use of anomaly monitoring designs in these design scenarios and hands-on labs.
Robot Monitor Scenario DesignDesign 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.
