mats

About mats

Posts by :

December 3, 2022

Environmental Profiles and Emission Sources

Environmental Profiles

Operational sustainability data sources are generally heterogeneous and require capabilities to be consolidated for viewing, analytics, and data synchronization.

The objective of environmental profiles, for environmentally critical assets or functional locations, is to provide a single point of overview to environmental performance. Operations can track environmental performance, like the carbon footprint of individual assets, or relative scores across asset types based on emission sources from related assets. With insights into environmental performance, like carbon footprint, operations can make improvements at an actionable level of granularity and start tracking the environmental impact of change.

The addition of a generic emission source data structure can be designed to include the date, emission types, material types, amount and unit of measure, and other metadata into a single common record of consumption and emission. Collected emission data may be continuous, fugitive, or count-based. Collected data needs to be quantified by date, emitted material, amount, and unit of measure.

The asset or functional location page in IBM Maximo Application Suite (MAS) Manage application, can provide an environmental tab with all environmentally related data. Using a tabular view of assets and functional locations, a relative sustainability score can be provided as a sustainability column.
Environmental Profile

An environmental profile can be delivered as a sustainability industry solution extending the view of assets and functional locations. Such an environmental profile presents all environmental emissions related to an asset or a functional location.

Using the environmental profile metadata, the tabular view may be manually filtered and sorted, or automatically queried, to provide insights into the environmental characteristics. Such insights may be any types, trends, and outlier emissions of an asset or location. AI models may use the environmental profile as a feature for asset sustainability scoring and asset maintenance strategies.

As the sustainability reporting tool focuses on emissions at selected site-level locations and monthly data aggregations, the environmental profile provides emission data at the fine-grained actionable source level of assets, parts, locations, and functional sub-locations.

Emission Sources

An emission source is a fine-grained atomic unit of emission data. It unifies the data schema for specific types of emission workflows, like meters, inspections, incidents, and work orders.

An emission source captures the metadata needed to record an emission, such as the type of material, amount, unit of measure, and time-stamp information. Collected data may be continuous, fugitive, or count-based. The emission source data is normalized as CO2e using the emission factor of the material type.

An emission source is generic and is associated with a parent object that defines the context, for example, a meter, incident, or work order. The parent object is related as part of an Enterprise Asset Management (EAM) workflow that relates the emission source to an asset or a functional location. The environmental profile hence becomes the collection of associated emission source objects of an asset or a functional location.

Meters, Inspections, Incidents, Items, and Work Orders are all heterogeneous data sources. Collected data may be continuous, fugitive, or count-based.

Meters

Asset Meters and Location Meters represent instances of meter types with manual or automatic meter readings, for example, gas, water, or power consumption.

Meters may capture the meter reading as an emission source object.

IoT Devices

The IBM MAS Manage application provides high-resolution streaming real-time data from connected devices and control systems. Data is provided in device messages with alphanumeric value types. Device data may be captured as an emission source object.

Inspections

Inspections represent periodic manual asset or functional location inspections performed by technicians. An inspection is performed following a job plan with many inspection steps, including the sampling of asset data. Some sampled data may be of direct environmental significance or may be input to asset health models that provides a sustainability health score. Planning maintenance using health scores may prevent environmental incidents or drive replacement and improvement programs.

Inspections and resulting data are associated with inspected assets. Inspections may result in meter readings. Inspection data may also be captured as an emission source object.

Incidents

Incidents are unexpected and unplanned events with health, safety, and environmental impact. An incident is recorded as one or more incident events each documenting a specific aspect of the incident, such as an environmentally impactful leak.

The type, severity, and classification of the event are documented as an emission source object. Incidents related to an asset or functional location context and the emissions from the incident contribute to the environmental profile.

Work Orders

Work Orders are planned asset maintenance activities across the lifecycle of the asset. Such maintenance includes for example repairs, part replacements, and refilling of consumables. The parts or consumables are referred to as Items.

A Work Order is tracking metadata related to the activity such as transportation and use of items. Replacement and disposal of parts may be used for accounting for the carbon footprint of items. Refilling consumables may be an indicator of abnormal consumption or leak. The environmental impact of the Work Order and Items may be captured as an emission source object.

Environmental Profile Information Model

The environmental profile and emission source objects unify the operational sustainability information.

The environmental profile information model.

December 2, 2022

Sustainability Strategic Research

mats Sustainability-Research

Enterprise Importance of Sustainability

Companies

Globally, major corporations to small companies are looking to become more sustainable, to reduce their environmental impact while remaining competitive. Companies are being held responsible for all aspects of their supply chains and operations.

Investors

Sustainability and ESG have also become topics in the trend toward responsible investing. Investors are increasingly using sustainability scores and ESG metrics to evaluate potential investments given the promise of higher returns. This has pressured companies to be responsible with their resource allocation, strategic in their decisions, and transparently report their sustainability disclosures.

Policy and Regulation

Global policies and regulations have increasingly aligned with international commitments toward ESG. The UK has established an environmental and sustainability policy that allocates resources and staff toward the implementation of established measures for ESG practices. The European Union (EU) has been a global leader in enacting ESG regulations, making clear that sustainable development will be an utmost priority in its decisions. It presents a holistic approach to the United Nations (UN’s) 2030 Agenda for Sustainable Development across member states, with clear measures coming from the European Council and European Parliament and budget allocations toward these goals.

Customers

As companies are becoming increasingly customer-centric as part of their competitive strategy, customers are increasingly demanding sustainable products and services. This strengthens the brand and reputation of companies with transparent supply chains that can guarantee fair labor practices and environmentally friendly operations. In an unprecedented way, customers now have a voice that can influence management decisions through their buying power.

International Community

With the global consensus brought about by the UN SDGs and the initiatives they have prompted, the international community becomes a powerful force to mobilize funds and enhances cross-sector agreements for the implementation of cross-cutting ESG initiatives.

Sustainability maturity

Sustainability maturity levels.

Organizations are initially in a Compliance stage, reporting on mandatory regulations using manually collected data, often challenged by data at scale and low quality. Actions are taken to start collecting environmental impact operational data from existing environmental critical assets and operational workflows.

Most organizations move to an Optimization 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. Actions are taken to identify and act on bad environmental actors and start operational change programs to improve carbon footprint through emissions, consumption, sourcing, and waste in operations by environmentally impactful assets and workflows.

Some organizations transition into an Innovation stage, with investments in product and service innovation or a sustainable business transformation. New products are created through a holistic sustainability viewpoint across supply, operations, and product delivery.

Sustainability, Environmental and Operational Processes

Sustainability, Environmental and Operational processes are often to be organized into separate process areas and process owners.

Sustainable enterprise processes, owned by the corporate sustainability function, including definition and management of sustainability goals, metrics, and reporting. Strategies are defined at the corporate level and reported using sustainability disclosures and standards. The granularity of goals and metrics is by year, using a base year, target year, and trends per year. Metrics are decomposed and reported by the significant regions or lines of business. ESG metrics are given in absolute and relative terms often using a coarse-grain classification of emission sources and types significant to the industry.

Environmental processes are owned by Safety and Environmental corporate functions and the Operations business units. In the Safety and Environmental corporate functions, we find process owners as the environmental manager managing environmental policies, goals, impact, permits, consents, and compliance. The environmental manager also manages incident investigations and resulting changes to operational and environmental processes. The focus is set on optimizing the performance of environmentally critical assets and identifying outliers across instances and operational types of locations and assets.

Operations teams are responsible for implementing and complying with environmental policies on incidents with environmental impact, taking corrective actions, and reporting on environmentally impactful operational activities. Such activities may be the consumption of energy and material, emissions through combustion and incidents, and waste generated from maintenance. Asset lifecycle presses involve purchasing, supply, transport, storage, usage, and waste management.

Operational sustainability data is recorded and managed at a fine-grained resolution through the operational workflows. The tracking of ESG metrics enables environmental performance analytics and resulting corrective actions to be taken by the operational team at the scale of asset instances and asset classes.

The fine-grained data managed in operations are synchronized with synchronized management systems and reported through sustainable enterprise processes.

Design Considerations

Sustainability, Environmental and Operational processes have specific objectives. The outcomes of these processes are coupled. Workflows are connected, and workflow data is shared.

Operational data at the asset level is required for operational sustainability workflows to be actionable.
Operational processes generate rich, diverse, high-speed, and high-resolution data.
Only environmentally significant operational data needs to be selected for sustainability analytics and reporting workflows.
Granularity of operational data can, should, and will be lost as data is aggregated and synthesized moving into sustainability workflows.

November 24, 2022

Visioning design practice

mats Design-Methods, IBM Design

Visioning is a time-boxed design activity answering questions on strategy, approach, and experience and coming to a shared understanding of strategic objectives.

Introduction

Visioning projects are identified in a roadmap backlog and define the WHY and WHAT to build, but not HOW to build it. Visioning should define the strategy, ask and answer questions, and explore possibilities. Visioning ensures a shared understanding across stakeholders and sponsors.

Visioning precedes concepting and implementation, with the objective to produce hills and epics for the product roadmap backlog.

Visioning projects are led by a senior designer or strategist, working in a core team across leaders of design, product, development, and research. A wider team of stakeholders, sponsors, and SMEs are providing guidance, and feedback, continuously or at playbacks.

Visioning uses market and user research, competitive analysis, ideation, and alignment workshops. Visioning also makes the strategy tangible through conceptual prototypes. Information and data architectures are ways to structure workflow experiences.

The vision projects preferably use agility, by working in sprints or workflow models, addressing objectives and questions in order. The team engages sponsors continuously, or through sprint playbacks.

Smaller vision projects may run for 3 sprints, larger projects may run for a quarter or two. The project ends with a Playback Zero stating the unity of the core team and sponsors on the resulting Hills and Epics in the roadmap.

Vision backlog

Visioning is a part of the product and portfolio roadmapping process.

Product initiatives are created by product management and form the bridge between our strategy and work as a ranked backlog. Some initiatives may require strategic research or visioning, and are tracked as a visioning activity in the backlog. These initiatives may lack clarity or alignment of intent and strategy in the evolution of the product or portfolio.

During monthly reviews, the vision backlog is reviewed, prioritized, and vision projects are initiated based on size, scope, and available resources.

Figure. Vision backlog process.

Types of vision project

There are different kinds of Visioning projects. Here are a few example types:

Exploratory vision projects take a more strategic research perspective with activities on competitive research, user research, concept testing and hill writing. The outcomes may be a strategic North Star vision, and demonstrations of key experiences.
Strategy and alignment vision projects take a more collaborative perspective with alignment workshops that unify the team around the roadmap direction. The outcomes may be more informative with hills, storyboards, and delighter and satisfier experiences.
Experience definition vision projects take a more concepting perspective that drives end-to-end flows and MVP experiences. The outcome is the product-level personas, hills, to-be storyboards, and resulting information architectures.

Defining a vision project

A good practice is to ‘Start with the end in mind’.

Start by understanding the objectives to meet and the questions to answer. The product management function is responsible for the roadmap strategy and defines the vision project. Make sure the vision definition is well-formed and has a clear ‘done criteria’. If the vision definition is not well-formed, use a Sprint 0 and an alignment workshop to get input from multiple sources for the definition. Use voting or prioritization methods to resolve conflicts.

Use a vision project template to ensure well-formed definitions.

Team

Exploration Lead: [Name of sponsor/main owner]
PM: [Name]
Design: [Name]
Development: [Name]

Timeline

Visioning and research: [Target date]
Estimated date for concepting: [Target date, likely at the quarter level]
Estimated date for delivery: [Target date, likely at the quarter or half level]

Problem Framing

[Short 1-2 paragraph ‘setting the scene’ statement that provides context for the problem this project will solve.]

Problem description

[List the problems that our customers and their users are facing that this vision project would seek to better understand and set a direction for solving.]

Visioning Goal

A visioning cycle would help us understand:
[List]

Desired Deliverables

[Eg: Competitive design analysis, Finalize persona research for X, As-is flow including screenshots, User research with X type of users to understand pain points and needs when Y, Design led workshop with X users, Prioritization of goals that X users are trying to solve, To-be story-boarding of UX journey, etc]

Questions to Answer

[Eg: What tools are X users using today to make decisions? and how closely are these tied together? and where are there gaps?]

Target Users

[Eg: Administrators, Operators, Technicians]

Example Customers/BPs

[List customers and partners that the team can use as examples, and/or perform validation & research on for this project].

Risks

[Outline risks faced if this visioning does not happen or is not successful]

Suggested/Expected Activities

[Eg: Visioning kickoff with stakeholders to align Opportunity challenge & Visioning mission, Research with X users from target customers identified by PM, etc]

Resources

[List any helpful resources or reading that may support or inform the vision project.]

Competitors

[List]

Reference Materials

[List any helpful resources or reference materials that may support or inform the vision project.]

Leading a vision project

Vision project are advised to use agile principles. By working in sprints the core team addresses objectives and questions in order and stay focused on a smaller set of questions while continuously making process and receive feedback to validate outcomes. Plan the sprint with clear objectives. End the sprint with a playback to sponsors. Declare the objectives for next sprint. And end the vision project with a Playback Zero stating the unity of the core team and sponsors. Set an expectation on project end date and playback zero.

Agree at start of the meeting cadence of core team meeting and playbacks. Work continuously in the core team, by meeting every or every second day. No less than weekly. Be sensitive to core team workload and other responsibilities. As a vision lead, manage the team calendar and invitations. Keep a backlog list of meeting topics from the sprint objectives. Plan 3-5 meetings ahead, minimally for next meeting.

Forming the vision team

Establish a core team from product PM, design, development, and key Subject mater experts (SMEs), to minimize knowledge transfer and enable rapid decisions. Work close in a 3-in-a-box.

Form a sponsor team with related Product Managers, Design leads, Development leads, and Architects, Technical and User Research, SMEs, and Executive sponsors.

Start the project with a 30 min Vision Project Kick-off with the core and extended team focusing on the project objectives and expected outcome. On indications that the objective is not well-formed or agreed, add a Sprint 0 to reach unity on the definition. Use a vision project kick-off template to guide at the first visioning team meeting, including Objectives, Preliminary hill, Questions, Project plan dates, Vision team and Stakeholders.

Perform competitive analysis

At the start, create an understanding of the bigger business context by analyzing the market and competitors. In cases where the market is less understood, start with a Strategic Research project.

In the competitive analysis

Research competitive solutions.
Compare solution capabilities.
Identify, list, and rank gaps.
Align insights with strategy.
Identify requirements and epics.

Running the vision project

Be artifact driven

Collect and share visioning artifacts

Quickly pull together information from multiple sources to feed innovation
Use collaboration tools for quick information collection, discussions, and documentation
Accelerate team sharing and learning
Accelerate decisions to a shared direction

Be design experience driven

Collect, classify and organize product screens by comparative capabilities

Analyze common patterns
List and rank experiences
Identify opportunities for reuse
Add to requirements, strategy and epics

Use scrapbooking

Use Mural for rapid design and scrapbooking

Quickly pull together page designs from existing and new concepts and patterns in bits and pieces
Playback purpose, scenario, concept, ideas, and experience
Capture quick feedback for the next iteration

Use information modeling

Model artifacts and relationships

Explore data and workflows in scenarios
Create information models with artifacts and relationships
Extend models across products and portfolios
Identify system or record
Prototype experiences and points of integration
Add to strategy and epics

Be test driven

Test early and often. In vision projects, one decision leads to next decisions in a dependency chain. Early testing at playbacks allows for early validation and changing of direction before spending too much time in a chain of decision dependencies.

Seek continuous feedback
Use rapid prototyping, like scrapbooking, for rapid daily validation
Use scenario flow prototypes for sprint playback

Manage the vision content

Be document driven. Document the strategy through hills, concepts, prototypes, and epics in the backlog. Express vision in the staged release plan.

Be formal in the management of content. The material assembled and produced will be your legacy to any following concepting and implementation workstreams. Do not leave all insights only in the head of the core team. Document the details of the vision outcome for new teams concepting and implementing the vision.

Use corporate collaboration tools.

Create a Slack channel for team collaboration. Start with the core team and grow to the extended team after sprint 0.
Create a Mural room for visioning activities. Consider a private Mural room or sub-folders to control open and confidential material.
Create a Box project folder for all project files.

Suggested box folder structure:

/vision-name
   /PLAN
   /MEETINGS
   /PLAYBACKS
   /DESIGN
   /MURAL
   /PROTOTYPES
   /RESEARCH
   /REQUIREMENTS
   /CONCEPTS
   /RELATED

Conclusions on best practices for visioning

Best of luck with your vision projects!

Remember to

Manage a backlog of visioning projects
Start with well-formed visioning questions to answer
Establish a core team from product PM, design, development
Use agility and work in sprints with playbacks
Prototype and show, don’t tell
Look for reusable patterns
Validate early and often with stakeholders and sponsors
Conclude with a Playback 0 unifying the team on hills and epics, and concepts.

January 17, 2022

IBM Design kicks off the New Year with Three Spark Design Awards

mats Awards, Monitor-Awards

January 1, 2022

Lig

mats Design Portfolio

IoTEdge-GwType_1

Image 1 of 6

IoT Platform Developer Experience
Design research on the developer experience in the Watson IoT Platform.

November 26, 2021

Sustainability Personas

mats Sustainability-Research

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 few years, the role has evolved, significantly, at a wildfire pace. The sustainability officer is no longer an environmentalist, and a ‘tree-hugger’. The sustainability officer has become a strategic executive at the corporate level.
More important to corporate finances, investors, and shareholders. Being externally exposed through transparency to corporate sustainability strategies, objectives, and disclosed key results.

The sustainability role is more integrated with the executive team. Part of the inner circle. Work alongside the CEO, CFO, COO, CIO, CDO. Align with finance, money, market share, corporate survival, and business (re-)innovation

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
Experts in data acquisition, data analytics, and sustainability reporting
Experts in environmental, social, and governance topics
Experts in governmental regulations
Physical climate risks and Transition business risks.
Experts in industry-specific sustainability topics like; emissions, circularity, forestry, mining, and energy production.

The team is supported by other corporate functions, increasing the extended team to 10s to 100s contributors

Finance and Marketing
Data and IT
Technology and Engineering
Health, Risk, Safety, Environmental, and Compliance
Procurement and Distribution
Operations
And industry-specific functions like Finance; Mortgage, Residential, Commercial, Loans, Investments

The Sustainability Officer

Kristina, the Sustainability Officer persona

Responsibilities

The sustainability officer is responsible for

Leading the sustainability mission and team.
Translating the corporate business strategy to a sustainability strategy.
Establishing principles and targets for implementing the sustainability strategy.
Gathering, defining, and implementing sustainability best practices.
Gathering data for mandatory sustainability disclosures.
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.
Engage other corporate functions, like operations, environment, and safety.
Engaging operations on sustainability projects implementing corporate targets.

Tasks

The sustainability officer is performing the following tasks

Managing day-to-day sustainability operations.
Educate the board of directors on sustainability.
Educate the organization on corporate sustainability strategies and targets.
Work with internal business stakeholders.
Work with the 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.
Work with operations stakeholders on data collection, processing, and analytics.
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.

Pain-points

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.

“Regulators and investors are asking for it, customers are demanding it, and employees are expecting it.”

“I have stopped using the word CLIMATE – Too existential and scary.”

“I’m overwhelmed with investor and analyst questions on our sustainability assessments.”

“I want to stop reporting and start acting.”

Operations Officer

Greg, the Operations Manager persona.

Greg, the Operations Manager persona

Safety first

Operations have the responsibility to not put the plant, staff, and operations at risk. Balance demand, capacity, and risks to operations.

Priorities are

Safety first.
- Always prioritizing the safety of employees, the local community, and equipment.
Deliver on operational target.
- Optimize performance to deliver on production plan.
- Assess the impact of risk factors on shift operations.
- Mitigate risks to ensure safety.
Ensure rules and regulations are followed
- Record production losses, incidents, and emissions.
- Monitors to stay within emission rights and certificates.
- Tracking emissions down to assets.
- Request new licenses or request production to move to other plants.
- Identify and analyze defects and perform root-cause analysis.
Maintain operational resources
- Predicts consumption demands and maintenance windows for units to go offline.
- Plan and schedule maintenance.
- Plan and schedule operational changes.

Climate

Operational impacts

Production parameters and forecast accuracy; Solar, Cloud coverage, Wind, Hydro.
Impact on demand, price, production load, capacity, transmission, delivery, and plant availability.
Weather forecasts lack integration with operational systems.
Increasing climate-related incidents causing increasing costs.
Unpredictable weather impacts operations from; Hurricanes, Storms, Thunderstorms, Long periods of cold, Floods, Landslides, and Erosion.
Risk of staff safety and disruptions to production.
Lack of interest in unquantified weather risks and proactive risk planning.
Damage to assets, impact to 3rd party, fines, claims, and corporate reputation.
Cost of maintenance, repair, and replacement.
Costs of hardening or moving assets.
Cost and funding for climate scenario analysis.
Climate impact on asset replacement strategies.

Sustainability

Manage operational targets; # emissions, # incidents, # worker injuries.
Manage emission certificates.
Manage carbon performance reporting and audits.
Sustainability reporting of carbon footprint is generally uncommon.
Sustainability data can/is based on operational data in SCADA systems.
Evidence of carbon improvement programs is anecdotal and fragmented.

Pain-points

Unplanned downtime and losses in productio.
Many information sources; views and lack of correlation across production, plan, work orders, operator logs, assets, and risk.
Worker awareness of safety and reporting.
Ensure compliance with regulations and reporting.
Lack of integrated weather risk forecasts.
Too many operator-level alerts and notifications.

Needs

Operationalize identification, assessment, and management of climate risks.
Business impact and attention to the weather, environment, and climate conditions as part of existing operational workflows.
Short-term weekly forecasts.
Longer quarterly seasonal predictions.
AI-supported decisions for reliable and predictive operations.

“Safety first!”

“Climate conditions can cost us a lot of money and loss of customer satisfaction.”

“Sustainability happens at some other place with some other people.”

November 26, 2021

Monitor SPARK 2021 Award

mats Awards, Monitor-Awards Awards, Monitor

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.

April 17, 2020

Monitor Personas – Bryan, Operator

mats Monitor-Research

“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 costly M$ crisis”

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

March 22, 2020

Anomaly Monitor Design

mats Monitor-Designs

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

“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 anM$ 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 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

“I setup and configure the Maximo Suite applications for the end-users”

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.

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 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.

Alert dashboard card.

Line graph dashboard card with alert overlay.

Custom alert dashboard card.

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.

New Data Panel organization with an 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.

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.

Data View with a graphical presentation of the 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 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.

Anomaly model functions in the catalog.

Anomaly model configuration.

Alert functions in the catalog.

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.

Manage Services page.

Creating a new service request in alert table.

Adding a new Maximo Service connection.

Create a new Maximo service request.

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 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.

March 19, 2020

Munich IoT Monitor Scenario Design

mats Monitor-Designs

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.

A floor plan of the IBM Munich IoT Center.

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

”As a line-of-business Operations Manager, I can in a single view explore my fleet of assets, see current KPIs, trends and quickly identify operational issues, using a dashboard that was created for me using best practice visualization for my asset data.”

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.

Munich IoT Center dashboards

Munich IoT Center Summary dashboard.

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.

CO2 levels at floor 27, zone 3 meeting room

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.

Device Temperature comfort levels at floor 27, zone 1

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.

Deployment of Yanzi Monition, Monition+ and Comfort IoT sensors on the floors, zones and workstations in the Munich IoT Center.

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.

Device page in IoT Platform Service using column filters to manage devices at scale.

Device Details page showing recent event messages from the sensor and the sensor state properties.

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.

Logical Interface for temperatures with data mappings and transformations.

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.

Summary dashboard presenting the KPIs of aggregated environmental conditions of buildings, floors, zones and workstations.

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.

Workstation dashboard presenting the environmental conditions of a single workplace.

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.