mats
About mats
Posts by :
Sustainability Personas
Evolution of the Sustainability Officer Role
The role of the sustainability officer has significantly changed over the last few years. Looking 20+ years back, the sustainability officer was funding and overseeing profile corporate projects on sustainability and social responsibilities.
Over the last years, the role has evolved, significantly, at a wildfire pace. The sustainability officer has become strategic to the corporate, to the corporate value, being externally exposed through transparency to corporate sustainability strategies, objectives and disclosed key results.
This article is overviewing recent design research on the sustainability officer/manager persona for IBM AI Applications sustainability offering.
Sustainability Organisation
The sustainability officer is leading a corporate function with an inner core team of up to 10 team members.
Team members are
- Manager of sustainability
- Data analysts
- Experts in reporting
- Experts in environmental, social, and governance topics
- Experts in industry-specific sustainability topics
The team is supported by other corporate functions, increasing the extended team to 10s to 100s of contributors
- Finance and Marketing
- Data and IT
- Technology and Engineering
- Health, Risk, Safety, Environmental, and Compliance
- Procurement and Distribution
- Operations
Organizational Maturity
Corporations are currently at a range of maturity levels.
Some organizations are in a Compliance stage, reporting on mandatory regulations using manually collected data, often challenged by data at scale and low quality.
Most other organizations are in an Optimisation stage, with a defined sustainability strategy, and started taking optimizing actions by defining goals, monitoring targets, running conservation projects, and acting on KPIs based on data analytic insights.
Some organizations have transitioned into an Innovation stage, with investments in product and service innovation for a sustainable business transformation.
The Sustainability Officer
The sustainability officer is responsible for
- Leading the sustainability mission and team
- Translating the corporate business strategy to a sustainability strategy
- Establishing principles and goals implementing the sustainability strategy
- Gathering, defining, and implementing sustainability best practices
- Reporting on sustainability KPIs monthly to executive boards
- Reporting through mandatory sustainability disclosures
- Reporting on broad areas of corporate, environmental, conservation, innovation, people, and society goals
- Reporting to investors, analysts, and sustainability rating agencies
- Engaging other supporting corporate functions
- Engaging operations on sustainability projects
The sustainability officer is performing the following tasks
- Managing day-to-day sustainability operations
- Educate board of directors on sustainability
- Work with internal business stakeholders
- Work with investor relations team and investors.
- Build skills, engagement, and momentum in the organization
- Facilitate strategy meetings, target setting, and LOB conversations
- Facilitate corporate sustainability improvement programs
- Perform data collection, processing, and analytics
- Assemble sustainability KPIs for disclosures
- Ensure audits on sustainability disclosures
- Keeping tabs on sustainability issues
- Perform risk scenario analysis
The sustainability officer is experiencing the following pain-points
- The scale of data and data quality. Often up to 2000+ metrics and associated data sources.
- Lots and lots of reporting. Often 20+ assessments and frameworks
- Frequency of changing regulations and standards
- Manual data collection across the corporate, supply chain, and service providers
- Lag of data availability for steering and reporting
- Accessibility to data in (some) global regions
- Difficulties to trace scope 3 emissions back through the chain of suppliers
- Data quality controls to avoid audit failures
- Sustainability auditing as strong as financial auditing
- Ownership and monitoring of improvement programs
- Understand the investor scoring KPIs
- Ability to backcast and forecast KPIs
Monitor SPARK 2021 Award
IBM Maximo Monitor design team was awarded GOLD WINNER in the 2021 Spark Pro Design Award for Digital Design.
See the Pro Design Award categories and the IBM Maximo Monitor entry page.
See the submission video below, or view it on YouTube.
Monitor Design Personas
Learn more about Bryan, the Operator persona targeted in the 2021 Spark Pro Design Award.
Monitor Personas – Bryan, Operator
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.
Devices
5-7 years of experience
Master’s degree in Engineering
Control system consoles, Maximo Suite, Email / SMS
Soft skills
Communication
Interpersonal
Detail-oriented
Customer-centric
Responsibilities
- Monitors assigned systems
- Prioritizes and Validates alerts
- Notifies and Escalates
- Documents incidents
Pain Points
- Overflow of alerts from multiple co-occurring critical situations
- Visibility to data
- Structure, organization, and navigation to related data in a hierarchically decomposed system
- Analyze expected vs actual data trends
- Work effectively with remote engineers
Needs
- Access to system and asset state, through control systems, and equipment sensors
- Data analytics notifying me of abnormalities in equipment sensors data
- Access to historical data and alerts to analyze trends and root causes and access to historical incidents and the root causes, actions, and resolutions
- Collaboration with my engineers acting as my hands and eye on the facility floor
Tasks
- Monitors one or more systems
- Prioritizes alerts and notifications
- Validates alerts and root-causes
- Assesses risks and impact
- Takes actions
- Learns and improves
Goals
- Manage my 10+ industry systems
- Keep my list of alerts down
- Assess severity, criticality, and risks to
- production
- Minimize downtime, damage, the risk to personnel
- Notify and engage others early
Pain-Points / Frustrations (current tools)
- Lack of data to stay ahead of problems
- Lack of notifications on anomalies and trends
- Depends on the control system and control system alerts
- Depends on engineers on the floor to validate issues and root causes
- Access to operational instructions
- Understand operational risks and impact
Monitor personas Learn about the Monitor personas
Key Stakeholders
Bryan depends on the following key stakeholders
- Application Administrator
- Maintenance Supervisor
- Maintenance Engineer / Technician
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.
Munich IoT Monitor Scenario Design
About this Scenario
The Munich IoT Center scenario is a live design demonstration scenario on the use of operational, performance, and anomaly monitor dashboards using Maximo Asset Monitor. The scenario outlines the monitoring and reporting tasks over a typical day at the Munich IoT Center for the fictitious operator and facility manager Bryan.
IBM is investing over USD 3 billion into Internet of Things – including USD 200 million to the Munich IoT Center. In Munich, the Internet of Things comes of age with advanced Watson cognitive computing technologies and the world’s first state-of-the-art client ‘collaboratories’. Take a virtual tour of the Watson IoT Center in Munich.
The floor plan of the Munich Twin Tower building, hosting the IBM IoT Center, is sectioned into East- and West-wing workspaces and meeting rooms. The wings are separated by the central elevator section, conference rooms, hallways, and utility spaces.
The IBM IoT Center in Munich has been instrumented with devices and sensors from many IBM IoT business partners. In this design scenario, we are using the 800+ devices from Yanzi Networks deployed to most of the IoT Center floors of the building.
The Munich IoT Center scenario has played a major role in the design and development of the Watson IoT Platform and Maximo Asset Monitor solutions. It demonstrates the everyday experiences and challenges for Operators and Administrators;
- The scale of deployment and management
- The scale of data ingest and storage
- Variability in sensor types, abstraction of sensor data, and normalization of measured units
- Configuration of operational and performance metrics
- Configuration of data analytics like data anomaly models and alerts
- Configuration of dashboards
- Use of dashboards for monitoring w/ search, filter, navigate and compare building data
This article overviews and demonstrates the design outcome of Maximo Asset Monitor in eyes of Bryan, the Facility Operations Manager.
Mastering Dashboards in Maximo Asset Monitor
Hands on Lab for a practical introduction to the use of Maximo Asset Monitor.
Monitor Scenario Personas
Bryan is a fictitious Operator and Facility Manager at the Munich IoT building. He relies on the Maximo Asset Monitor solution for his operational and engineering roles. He depends on building KPIs like utilization, compliance, and comfort to ensure tenant satisfaction. He depends on operational metrics like CO2, temperature, noise, light, and humidity levels to monitor comfort. He depends on AI anomaly models to notify of abnormalities in the building sensor data, operational metrics, and KPIs. He depends on dashboards to present summary and drill-in to operational metrics and KPIs, allowing him to prioritize the alerts, validate the root causes, take action and assign service requests to his facility engineers.
Munich IoT Monitor Scenario Storyline
Starting the day
Bryan starts his day at the office by getting an overview of the facility. He logs into the Maximo Asset Monitor tenant and selects the ‘View Dashboards’ option to pick the Munich IoT Center summary dashboard. He opens the summary and alert dashboards from the Dashboards page to get an update on the state and the building, the floors, and the zones. He looks for critical alerts he needs to prioritize. He will then start validating the alert, find the root cause and take action.
Getting an overview
Brian focuses, in order of urgency, on the following tasks supported by Maximo Asset Monitor dashboards.
Building overview – He explores the Munich IoT Center Summary dashboard to confirm the overall state of the building and identify any abnormalities. He looks at the alerts table for a quick overview of the building’s health. He then applies filters to drill into floors and zones that look suspicious.
What’s broken – He looks for ‘assets in trouble’ and alerts and correlates these to the floors and zones in the building using the Alerts Summary dashboard. He applies filters to only see alerts on floors and zones that look suspicious.
What are the trends – He views the performance and compliance indicators for the last day(s) and looks for any abnormalities in the trends using the Performance dashboard. He applies filters to only see KPIs on floors and zones that look suspicious.
Using the monitor dashboards in Maximo Asset Monitor, Bryan identifies three issues he needs to follow up on and investigate root-cause.
Looking for root-causes
Carbon Dioxide (CO2) alerts at Floor 27, Zone 3 –
Bryan first prioritizes the CO2 alerts in the Floor 27 Zone 3 meeting room. He follows the link from the critical CO2 alert to the workstation dashboard displaying the room conditions and trends. He validates that the CO2 levels are above the compliance level of 800 PPM and that the abnormal levels seem to be occurring in the afternoons. He suspects this to be due to telephone conferences in the room with several participants. He suspects overutilization of the room and that air quality is impacted. He needs to ensure that the root cause is not related to a failing air conditioning unit. During the day he plans to follow up with the project members on Floor 27 west wing, to validate his suspicions and look for options. He will also follow up with the facility engineer regarding the HVAC unit.
Temperature alerts in Zone 1 on multiple floors after 3 pm local time – Bryan inspects the temperature alerts in Zone 1 on multiple floors. Zone 1 is located in the west wing of the building and Bryan suspects that afternoon sunlight might cause this high-temperature abnormality. He proceeds and validates any correlation between workstation temperature alerts, operations of the automatic building blinds, and the sunlight radiation level from weather data.
Utilization of the meeting rooms – Bryan notices a drop in the utilization of the meeting rooms on some of the floors. He is concerned if this is related to tenant satisfaction, or changes in the project staffing. He follows up with the projects on the suspicious floor and looks for the best options to improve the performance and efficiency of the space.
After prioritizing the alerts, and analyzing the root causes using the data provided by the Maximo Asset Monitor dashboards, he can start to take actions to resolve the issues.
Scenario Configuration
The Munich IoT Center scenario is running on a live monitor configuration. This section discusses some of the steps performed by an Application Administrator to configure the solution.
Registering the IoT Devices
The IBM IoT Center in Munich has been instrumented with devices from Yanzi Networks deployed to most of the IoT Center floors of the building. See deployment on the floor plan below. Three types of devices have been deployed.
- Yanzi Motion devices (blue) for monitoring motion and temperature.
- Yanzi Motion+ devices (red) for monitoring motion as well as temperature, humidity, ambient light, and sampled ambient noise.
- Yanzi Comfort devices (green) for monitoring air quality by measuring levels of carbon dioxide (CO2) and volatile organic compounds, as well as temperature, humidity, barometric pressure, and ambient noise
The devices contain sensors that are individually registered as Device Types and connect with Maximo Asset Monitor over the internet.
The IoT Platform Service in Maximo Asset Monitor provides views to the device types, devices, the ingested device events, the event data, and the transformation of data performed prior to storing data in the Maximo Asset Monitor data lake. Device types and Devices are presented in tabular form.
Devices may be assigned metadata in Watson IoT Platform service, for example, a Region, Building, Floor, Zone, and Workstation. This metadata information is used to logically associate the device with its location and use it later for analytics and reporting purposes. As an example, as shown in the illustration below, the workstations in zone 1 are instrumented with Motion and Motion+ type devices with temperature sensors. Column filters help to identify devices of a specific sensor type and their location. Details on devices are presented on the device details page, for example, the connection state, recent data events, and the latest sensor state values.
Processing Munich IoT Center Sensor Data in IoT Platform
Events are the mechanism by which devices publish data at a regular heartbeat to Maximo Asset Monitor. The frequency is set by the device, for example, every second, every minute, every hour, or once a day. The 800+ devices instrumenting the Munich IoT Center are sending sensor data reading every minute. In total, 500.000 data events are to be stored every month in the Maximo Asset Monitor data lake.
The device sends the sensor data as a payload in the event. Data from devices of the same device type share the same payload data structure defined by an Event Type schema. By default, the IoT Platform expects events in JSON format specified by a JSON schema. The device detail page presents the connection state, the data events, and the event payloads.
Maximo Asset Monitor provides capabilities to create shared abstractions of device data so that devices of various brands all confirm a common schema definition of data, independent of the device type. The device data abstractor is specified using a Logical Interface. The logical interface may also normalize and transform data using JSONata mapping expressions. In the Munich IoT Center demo configuration, interfaces have been configured for all sensor types. These mappings transform data units from Kelvin temperatures to Fahrenheit, and noise levels to dB. Mappings also compute KPIs like Comfort Levels and Regulatory Compliance levels for temperature, CO2, noise, light, humidity, and air pressure. Mapping on the motion sensor data computes occupancy and utilization KPIs using.
Classifying, Aggregating, and Analyzing Munich IoT Center Data in Maximo Asset Monitor
Maximo Asset Monitor adds a concept of Dimensions. A dimension is a name/value pair used for asset classification and metadata. Dimension values are static or slow-changing. In the Munich IoT Center configuration, dimensions are used to classify the devices using their location expressed as REGION, BUILDING, FLOOR, ZONE, WORKSTATION, and DEVICE dimensions. Dimensions are automatically set by metadata values set in the devices.
The values are simple mappings to the Munich building instrumentation; Building: Munich, Floor:27, Zone:3, Workstation:1-2, Device:809646_EUI64-0080E103000226A9. Using aggregation functions and classification dimensions, Maximo Asset Monitor can compute aggregations across the building, a floor, a zone, and down to a workstation. For example, filtering all sensors on a floor the average across the isOccupied metric across sensors over an hour can be computed resulting in a metric of floor Utilization expressed as a 0.0 – 1.0 percentage value. This aggregation design is used across all of the KPIs in the demo design.
Designing the Munich IoT Center Operational Dashboards
Maximo Asset Monitor provides two types of dashboards; Summary Dashboards and Entity Dashboards.
A Summary Dashboard is a dashboard that presents aggregated KPIs and provides drill-in to the metrics using hierarchical filters. Let’s decompose that statement a bit. Bryan, the Facility Operations Manager, the summary dashboards provide an overview of KPIs across all regions and buildings, including the Munich IoT Center building. And it allows filtering to a selected building and its floors, zones, workstations, and environmental sensors. Summary dashboards present aggregations by the hour, by day, by week, by month. This allows the KPIs to be tracked and compared over shorter and longer time ranges. An example of a Workstation Summary dashboard is presented below.
In the Munich IoT Center demo, three main summary dashboards were designed for operational metrics and KPIs; Building overview, Performance, and Alerts. All dashboards use Region, Building, Floor, Zone, Workstation dimensional filters.
An Entity Dashboard is a dashboard that presents the operational metrics of a single entity. In this scenario a single workstation. Metrics from a single entity can be presented without any aggregation and in near real-time. Workstation sensor values and anomaly alerts are presented on value cards, tables, and graphs on the dashboard. The Workstation Entity Dashboard for the meeting rum at Floor 27 Zone 3 is shown below.
The dashboards use cards and layout designs:
- Value cards of SMALL size to present current metric values.
- Time-series graphs cards of MEDIUM size to present a thumbnail metric view.
- Full-size graphs cards of LARGEWIDE size to present Mean, Max, Min aggregated data for metric trends.
- Alert card in LARGE and LARGEWIDE size to present any alerts on the filtered level.
- Image card with hot-spot overlays presenting data metrics, and alert thresholds.
- Cards are presented in an 8 column layout.
The definition of a dashboard is encoded in a JSON file that may be uploaded and downloaded using the Maximo Asset Monitor dashboard editor.
Get Hands-On with the Munich IoT Center Demo and Maximo Asset Monitor
Explore all the steps outlined above to configure the devices, sensors, data processing, data storage, analytics, and dashboard configurations in the hands-on lab ‘Maximo Asset Monitor 101’.
In the lab, you will start by exploring more in detail the device, data, analytics, and dashboard configurations in the Munich IoT Center scenario. You will use the monitor dashboards to explore the live state of the Munich building. View the hands-on lab material for ‘Maximo Asset Monitor 101’ for more details on the scenario configuration.
Mastering Dashboards in Maximo Asset Monitor
Hands on Lab for a practical introduction to the use of Maximo Asset Monitor.
Maximo Asset Monitor 101
In this lab and workshop, you will get an end-to-end overview and hands-on experience to quickly get started with IBM Maximo Asset Monitor and take advantage of operational monitoring using the leading AI and IoT platform for industrial IoT. You will use live sensors from the IBM Munich IoT Center and the Maximo Asset Monitor to gain analytics insights into the environmental conditions, the compliance to regulations, and the utilization of the building.
In the first part of this lab, you will explore the types of sensors and events sent from the devices instrumenting the floors, zones, and workstations in the IBM Munich IoT Center building. You will explore event data ingestion and the data transformation performed by the Watson IoT Platform Service as sensor data streaming into Maximo Asset Monitor.
In the second part of the lab, you will explore monitoring of operational metrics and performance KPIs. You will deep-dive into the analytics capabilities in Maximo Asset Monitor and explore metrics on facility conditions, comfort levels, and utilization. You will explore how to configure dashboards for monitoring operational metrics and performance KPIs. These dashboards may display the operational metrics on a single workstation, or KPIs on the building or its floors and zones. you will also explore AI capabilities like analytics and anomaly models to get notifications of abnormal data points and take actions to assign work orders on the alerts.
AI brings asset monitoring to life, resulting in a full operationally-scalable monitoring solution. AI-powered anomaly detection and configurable dashboards ensure only the right alerts are identified while helping you understand complex relationships between factors causing failures. This empowers your OT and IT teams to act with confidence to understand when something has changed, explore root cause variables and drive digital re-invention.
The Workstation dashboard above shows one of the operational dashboards in the lab. You will explore how cards are configured on the dashboard that monitors the current operational metrics of the Munich IoT Center, an image of the floor plan with data drill-in hot-spots, an alert table with detected anomalies in the comfort and compliance data, and finally time-series graphs showing the current and historical operational metrics with alert overlays.
View the lab instructions below, or download for remove reading.
http://design.gothe.se/download/monitor101-labhandbook/
Download lab handbook
Monitor Personas
Key Stakeholders
This article overviews the persona stakeholders in the Maximo Asset Monitor application.
These key stakeholders are:
Figure: Key stakeholder interactions in the Monitor user journeys.
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 analog and digital Input- and Output-points (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.
Bryan, the Operator
Learn more about the details of Bryan the Operator persona.
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.
Devices
5-7 years of experience
Also known as: Maximo administrator, Maximo Asset Monitor administrator
Computer Science
Maximo Suite, email, SMS
Responsibilities
Needs
Ed, the Maintenance Supervisor
Ed is the
Devices
5-7 years of experience
Mechanical Engineering
Also known as: maintenance manager, lead maintenance technician
Maximo
Responsibilities
- Respond to urgent and changing maintenance priorities
- Plan open work and match qualifications of team members
- Stay updated with team member assignments
- Reporting status
Pain Points
- Constantly firefighting –moving techs from one hot job to another –leading to cost and schedule inefficiencies
- Techs complaining about assigned work
- Unqualified labor Inaccurate or incomplete information on Work Orders
- Work being poorly planned
Tasks
- Manage ever-changing priorities of work (Approve, Assign, Manage, Close)
- Match qualifications of team members to open work.
- Knowing where each team member is at all times
- Reporting status to his boss, other managers, and Brianna (Peer)
- 1:1 Time with Technicians on Daily Basis (Chat, Coffee)
Eli, the Maintenance Engineer
Eli is the Maintenance Engineer
Devices
1-3 years of experience
Mechanical Engineering
Maximo
Also known as: engineer, technician, maintenance technician, journeyman, craftsman
Responsibilities
- Perform incident repairs to resume operations
- Assess and act on alerts to minimize downtime, damage, risk
- Perform assigned maintenance
(scheduled, preventive or predictive) - Keep my list of assigned work orders down
- Improve equipment performance
- Improve site productivity
Needs
Robot Monitor Scenario Design
The Robot Scenario Context
The Robot scenario is a rapid design demonstration scenario on the use of Anomaly Monitoring and Monitor Dashboards in Maximo Asset Monitor.
The scenario outlines a fictitious manufacturing company ACME with 4 production sites in the US. The sites are located in Alphaville, Betacamp, Charlyton and Deltalake. The production assembly lines at the sites have robots instrumented with sensors connected to the IoT Platform cloud service running as part of the ACME Maximo Asset Monitor tenant. The robots report data metrics from the robot arm on torque, load, speed, and acceleration at 5- minute intervals.
Over the last few days, one of the robots in Alphaville has been anomalous data values on robot arm torque. Also, the speed and acceleration of the robot arm seem to be impacted. The alerts from the robot are notified to the operator at the ACME remote operations team. Bryan the operator will start a root-cause investigation and troubleshoot the abnormal values. Once he has validated the alert he will create a service request for the maintenance engineering team in Alphaville to resolve the issue before the robot breaks and causes a halt to the production line.
Simulating the ACME Robots
The robots in this scenario are simulated on the IBM cloud using a NodeRed flow. The simulator sends robot data events every 5 minutes as MQTT messages to the Watson IoT Platform service included and preconfigured in Maximo Asset Monitor. The event contains robot data for load, torque, speed, and acceleration using the following MQTT event message schema in JSON format.
{
“load”: 375.65,
“torque”: 10.855,
“speed”: 2.503,
“acc”: -0.164
}
The simulated data is mainly random values within a set range for each metric. To simulate anomalies, random data spike values are added to the torque data to show reoccurring abnormal data indicating a possible root cause of a future robot failure.
Configuring Anomaly Detection
All ACME Robots in this scenario is of the same type and send the same torque, load, speed, and acceleration sensor data. The robots are monitored as an ACME_Robot entity type with torque, load, speed, and acc metrics. Maximo Asset Monitor provides an out-of-the-box catalog of anomaly model functions that can be configured with data metrics as inputs. The model computes an anomaly model score. The score is a likelihood of anomalous data within a time window of data samples. The anomaly function scans the time-series torque data and produces a time graph of anomaly scores. Maximo Asset Monitor provides a predefined set of anomaly models. In the robot scenario demonstrator, we are using a saliency-based generalized anomaly scoring model. The model employs Saliency and GAM on windowed time series data to compute an anomaly score from the covariance matrix. An alert function in Maximo Asset Monitor can be configured with the anomaly model score as a parameter to compare with a set threshold. If the score is above the threshold an anomaly is detected and an alert is created. In this scenario, the torque anomaly alerts are set to trigger alerts at a threshold of 100.
Configuring Robot Dashboards
Maximo Asset Monitor provides two types of operational monitor dashboards; Summary Dashboards and Entity Dashboards.
A Summary Dashboard is a dashboard-type that presents aggregated KPIs and provides drill-in to aggregated metrics using hierarchical filters. Let’s decompose that statement a bit. For the operators at ACME, the Robot Summary Dashboard presents an overview of KPIs across all ACME sites. And it allows a drill-in to a selected site, a selected line, and a selected robot. Robot data, resulting from the selected filter, is aggregated and presented as statistical units. For example, maximum, minimum, and mean values across all robots passing the filter. Data is also aggregated across a time grain. For example by the hour, by day, by week, by month. This allows the KPIs to be tracked and compared over various levels of the organization and at shorter or longer time ranges. A screenshot of the Robot Summary Dashboard is given below. The screen shows filtering the KPIs of the robots to an hourly report of the Alphaville manufacturing site.
An Entity Dashboard is a dashboard that presents the operational metrics of a single entity. In this scenario a single robot. Metrics from a single entity can be presented without any aggregation and in near real-time. Robot metric values and anomaly alerts are presented on values cards, tables, and graphs on the dashboard. The Robot Entity Dashboard for one of the robots at Alphaville is shown below.
Monitoring Alerts
Operators approach the task of monitoring by identifying and prioritizing alerts on the Alerts page, or by identifying ‘assets in trouble’ using Summary Dashboards.
Maximo Asset Monitor provides an Alerts page that summarizes all alerts across all types and entities in the system. An ACME operator may filter the Alerts to identify the most critical alerts on the most critical assets and start the root cause analysis by following the link on the alert to the entity raising the alert. An example of the Robot Alert Page for the ACME robots is presented below.
As shown on the screens above, alert tables may also be included on summary dashboards and entity dashboards.
Creating Service Requests
Operators validate alerts and troubleshoot the root cause of the anomalous data by inspecting the short and long-term asset behavior using historical metric data using the time range picker on the dashboards. Once the anomaly is validated and the root cause is identified, operators will create a service request for maintenance supervisors to plan the work order for maintenance engineers to resolve the issue.
As shown on the screens above, a service request may be created including reference information of the asset id, job code, and links to the alert in Maximo Asset Monitor.
Get Hands-On with Maximo Asset Monitor Dashboards
Explore the steps to configure the dashboards for ACME robots in the Hands-on Lab Mastering Dashboards in Maximo Asset Monitor. In the lab, you will start by exploring more in detail the sources of robot data that you will monitor. You will then learn the steps of configuring an operational dashboard for monitoring the metrics, trends, and anomaly alerts from the ACME robots. You will use the monitor dashboard presentation techniques of value cards, graph cards, table cards, and image cards with hot spots. You will also explore summary dashboards that provide data aggregation and filtering to monitor your performance KPIs.
Mastering Dashboards in Maximo Asset Monitor
Hands on Lab for a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.
Mastering Dashboards in Maximo Asset Monitor
Hands on Lab for a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.