mats
About mats
Posts by :
Sustainability Personas
In 2021 and 2022 I performed strategic, user, and persona research on climate and sustainability for operational sustainability capabilities in IBM sustainability solutions.
This article overviews the design research insights on the sustainability and operations manager 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 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. The role is now important to corporate finances, investors, and shareholders. And more externally exposed through transparency to corporate sustainability strategies, objectives, and disclosed key results.
The sustainability role is now integrated with the executive team and part of the inner executive board, and working alongside the CEO, CFO, COO, CIO, CDO. Sustainability responsibilities are aligned 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.
- Experts in physical climate risks and transitional 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, and Investments.
The Sustainability Officer
Devices
10+ years of experience
Also known as: Chief Sustainability Officer, CSO, Sustainability Manager
Master degree – Sustainable Resource Management, Biochemistry, Chemical engineering
Sustainability reporting systems and Financial systems, Email, SMS
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.
“I want to stop reporting and start acting.” “I’m overwhelmed with investor and analyst questions on our sustainability assessments.” “I have stopped using the word CLIMATE – Too existential and scary.” “Regulators and investors are asking for it, customers are demanding it, and employees are expecting it.”Operations Officer
Greg, the Operations Manager persona.
Devices
5-10 years of experience
Graduate or Bachelor degree. Engineering
Maximo Suite, Business Operations systems and Financial systems, Email, SMS
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 operational 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.
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.
Pain-points
- Unplanned downtime and losses in productivity.
- 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.
“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.”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.
Asset Data Experience Patterns
In 2021 I performed design visioning to achieve Asset Data Unification in the Maximo Application Suite and drive a common terminology, asset data dictionary, and UX experience strategy for the Maximo suite applications integration use-cases.
Objective
The objective of this user experience design aimed to identify common integration use cases across the applications on the Maximo site and to unify the integration experience.
Maximo application suite
Maximo application suite provides intelligent asset management through a set of applications for asset monitoring, asset management, predictive maintenance, and reliability planning.
The suite is a single, integrated cloud-based platform that uses AI, IoT, and analytics to optimize performance, extend asset lifecycles, and reduce operational downtime and costs.
The suite includes Manage, Monitor, Health, Predict, and Mobile applications.
Learn more about the IBM Maximo Application Suite on IBM.com.
Asset Data User Experience
A Maximo data dictionary provides a knowledge graph of the suite data and links to the application data. The Maximo data dictionary may also provide shared UX components for common use cases on the suite data and relation in the semantic graph.
The Maximo data dictionary would provide for the user experience and the backend data resulting in a common source of truth for all Maximo suite applications. Hence, an asset may appear in multiple applications, providing unique application use cases, but always reference the same asset identity in the data dictionary.
A common source of truth.
Maximo Data Unification Use-cases
Maximo suite use-cases
The common role-based use cases were identified in discovery sessions with each Maximo suite application team.
Operation Manager scenarios in Maximo Monitor
- An operations manager using Monitor can create, update, and view assets and locations in a hierarchy in order to construct logical relationships and associate operational data derived from sensors when Manage is not present.
- An operations manager using Monitor can view assets and locations in a hierarchy in order to construct logical relationships and associate operational data derived from sensors when Manage is present.
- An operations manager using Monitor can immediately identify an existing asset in the Manage database when creating workflow automation to generate a service request.
Maintenance Manager scenarios in Maximo Manage
- A maintenance manager reviewing a service request that was generated as a result of workflow automation in Monitor, can access operational data and alerts (e.g., sensor) to gain insight into impacted assets and classification of failure.
- A maintenance manager can map an asset to a summarized/calculated value to be used for condition monitoring.
Reliability Manager scenarios in Maximo Health
- A reliability engineer using Maximo Health can view the historical time-series data related to a health score of an asset generated from operational data in Maximo Monitor in order to gain insights into trends and anomalies.
- A reliability engineer can define a health score for an asset or location using summarized/calculated values from Maximo Monitor, and/or populated values from a manual inspection.
- A reliability engineer can view the condition monitoring rules for an asset based on summarized/calculated values, and/or populated values from a manual inspection.
- A data scientist using Maximo Predict can view additional time-series data, add as contributors to predictive models, and evaluate improved model quality.
Data Dictionary experience requirements
From the use cases above we can derive data dictionary user experience requirements.
Maximo Manage
- Link measured and calculated data to asset and location meters.
- Create and link calculated data to asset and location meters.
- Access linked measured and calculated data.
Maximo Monitor
- Add | View | Update assets and locations.
- Add | View | Update asset and location types.
- Add | View | Update asset and location attributes.
- Add | View | Update asset and location relations.
- Add | View systems.
- Add | View | Update | Delete data items..
- Add | View a work order.
Maximo Visual Inspection
- Add | View | Update | Delete inspection record
- Traceability from inspection data to inspection artifacts
- Add an inspection result to an asset
- View model quality data
- View model feedback data
Maximo Mobile
- View asset data
- Traceability from a work order to view alert and failure class
- Traceability from a work order to view asset data
- Traceability from a work order to view anomaly data
Maximo Health and Predict
- View asset and location data
- Create calculated data
- Create | Update | Delete prediction group
- Create | Delete prediction model
- Create | Update model with asset and location data
Data Dictionary experience design patterns
From the use cases above we can make a few conceptual assumptions. The artifact in the use cases can be generalized using the data dictionary abstract information model. We derived the core data dictionary UX patterns.
- View artifacts
- Select (and link) one or more artifacts
- Navigate to an artifacts
- Add (and link) an artifact
To achieve these generalizations the UX components of the data dictionary need to delegate the implementation to the provider of an artifact. The data provider of the artifact can be generalized using the data dictionary application extensions.
- Maximo Manage will be a provider for assets and workorders. Maximo Monitor will be a provider of data items.
- The data dictionary should provide a default implementation to support the UX patterns for abstract model artifacts. Such an implementation will use available application-specific APIs to achieve the use case.
- Each artifact provider may (optionally) support the core UX use cases for its artifacts and deliver a richer (delegated) experience based on the application’s richer data model and semantics.
- UX components are provided as dialogs and pages for web and mobile screen sizes.
UX Patterns
View Artifacts
The VIEW use-case provides a dialog or page
- List artifacts in a tabular form
- Apply column filters
- Apply search filter
- Show artifacts with metadata in Detail mode
- Cancel and close the page
UX pattern for viewing a list of artifacts.
UX pattern for viewing a list of artifacts.
UX pattern for viewing a hierarchy of artifacts.
Select Artifacts
The SELECT use-case provides a dialog or page
- Extends the VIEW design
- List artifacts in a tabular form
- Apply column filters
- Apply search filter
- Add row selection to the list view
- Show artifacts with metadata in Detail mode
- Add action to close the page and return the selection.
- Cancel and close the page.
UX pattern for selecting one or more artifacts.
Optional UX pattern to view artifact details when selecting.
UX pattern for selecting in a hierarchy of artifacts.
Add Artifacts
The ADD use-case provides a dialog or page
- Action on VIEW and SELECT page
- Default, form-based add operation, based on Data Dictionary artifact schema
- Single- or multi-page
- Add action to closes the page, delegates creation, and returns the new artifact
- Cancel and close the page
Example of delegated dialog in Maximo Monitor for adding a new data artifact
Example of delegated dialog In Maximo Monitor for adding details to a new data artifact
Work order examples
VIEW, SELECT and ADD examples for using the UX patterns with Work orders.
Asset Data Terminology
In 2021 I performed design visioning to achieve Asset Data Unification in the Maximo Application Suite, and drive a common terminology, asset data dictionary, and UX experience strategy for the Maximo suite applications integration use-cases.
Objective
The objective of this research and design aimed to identify a common Terminology that unifies the information model, user experience, and content designs, across the applications in the Maximo suite.
The research method used identified the conceptual and related variant terms and defined the scope and definitions required to achieve unification for the Maximo suite across the Maximo suite Design, Product Management, and Development teams.
The terminology
- Defined a single source of truth that aligns the application teams.
- Aligned IBM, industry, and dictionary definitions of terms
- Derived input requirements to a conceptual data model.
Maximo Application Suite
Maximo application suite provides intelligent asset management through a set of applications for asset monitoring, asset management, predictive maintenance, and reliability planning.
The suite is a single, integrated cloud-based platform that uses AI, IoT, and analytics to optimize performance, extend asset lifecycles, and reduce operational downtime and costs.
The suite includes Manage, Monitor, Health, Predict, and Mobile applications.
Learn more about the IBM Maximo Application Suite on IBM.com
Terminology
Asset
A manageable object that is either deployed or intended to be deployed in an operational environment.
Assets are often used when referring to both large assets like facilities and buildings, down to more granular assets like a pump or a compressor. In the Maximo suite, the term is more strictly used to represent managed assets and parts that are individually identified and managed.
Variants
- Rotating asset. An asset that may be replaced for repair or refurbishment.
- Fixed asset. An asset that remains in its installed location throughout its lifespan.
- Point asset. An asset where maintenance does not depend on its length or measure.
- Linear asset. An asset that is maintained in segments, such as a road, pipeline, or railroad track.
- Asset template. A record that specifies common asset information that is shared by multiple assets.
Related terms
- Item. Part of an asset, as a consumable or replacement part, manages an inventory but is not strictly monitored.
Location
A place where assets are operated, stored, or repaired.
Locations are used in several different ways. While a location intuitively is considered a geographic point, like a BEDFORD site, it can also be interpreted as a functional location, like a BOILER ROOM or one of its BOILERs.
Functional locations are hierarchical, often following system-subsystem decomposition, like a plant, building, process, equipment, down to the related asset. Geographic locations may take different shapes, like a point position, a linear location like a power line, or an area like a production plant.
Variants
- Functional location. A location type that indicates the equipment or process location of an asset.
- Physical location. A location type that indicates the geographic location of an asset.
- System location. A location type that indicates the top tier in a location hierarchy.
- Process or Equipment location. A location type that indicates the mid-tier in a location hierarchy.
- Operating location. A location type that indicates the presence of operating assets as opposed to a storage or repair location.
Related items
- System. Systems are logical location hierarchies that represent functional areas.
- Site. A business location where assets are co-located.
Work order
A record that contains information about work that must be performed.
Variant
- Service request – A request from a user for work on an asset.
- Ticket – A record, such as a service request, incident, or problem report, that can be routed and assigned a status.
- Inspection – A record that schedules, executes, and documents asset inspection activities, using a checklist.
Device
A device is a physical object with sensors, software, and communication technologies that enable it to connect and exchange data with other devices or systems over the internet.
Devices range across complex SCADA systems for asset control, to simple units that use sensors to measure asset operational metrics. Devices may use full MQTT IoT protocol networking, or simpler wireless protocols to connect using a dedicated gateway.
Variants
- Thing. As in IoT Internet of THINGS.
- Managed device. Devices that contain a device management agent.
- Unmanaged device – Devices without a device management agent.
- Gateway – Gateways are specialized devices that have the combined capabilities of a device and serve as access points for other devices.
Related terms
- Device Type. Device type is a definition of devices that share characteristics or behaviors.
- Smart Device. A device that connects to other devices or networks via different protocols such as Bluetooth, Zigbee, NFC, Wi-Fi, LiFi, and 5G.
Meter
A record that is used to record measurements.
Variants
- Continuous meter. Meter readings that increment over time.
- Gauge meter. Meter readings fluctuate over time.
- Characteristic meter. Meter readings from a list of possible values.
Related terms
- Tag, IO point – A tag represents a number or text data in a control system.
- Sensor. Measures signals from the physical environment.
- Metric. Time-series device data as the raw sensor or computed function values.
Data
Data is a generalization of a time-series of data value samples.
Data may be Integers, Numbers, Boolean, Strings, Enumerated values, and Arrays.
Data is periodic and has time-stamps.
Data representing numeric samples may have a unit of measure.
Variants
- Raw data. Single data value with time-stamp, or group of data values with common time-stamp.
- Computed data. Time-series of computed output data values from related input data.
- Aggregated data. Statistically aggregated output data values from related input data using statistical functions like Max, Min, Mean, Count, Sum, First, and Last. Often by a defined grain.
- Predicted data. Predictions on future data values based on AI models and related historical data.
- Failure data. Raw or prediction data that indicates an absolute or relative time of failure.
Data is aggregated to a grain. Grain may be time-based, data-source-based, or custom-based.
- Time-based grains. Defined by the time period used when applying a statistical method, such as Monte, Hour, Day, Week, Month, or Year.
- Data-source grains. Defined by a scope of data sources and by a time-train, like the average of all pumps of a model.
- Custom grains. Non-common time-period grains, such as shifts, work hours, work days, or seasons.
Anomaly
A data value that deviates significantly from normal operational value patterns or is outside of the predicted value range.
An anomaly is a suspect to an abnormal behavior in the system. The detection of an anomaly may raise an alert. Several approaches may be taken when defining the deviation. A deviation may be identified as
- Raw data is outside of the predicted confidence band
- The distance of raw data outside of the predicted confidence band. The distance may be defined statistically using a sigma value (aka standard deviation) from the confidence band. A larger distance may indicate higher anomaly severity.
- The velocity of raw data values departing the predicted confidence band. Higher velocity may indicate higher anomaly severity.
- The end-to-end time window with values outside of the predicted confidence band. A time window may reduce the # of individual anomalies.
- The heat map with clusters of values outside of the predicted confidence band. A distribution of anomalies in a time window will present a deeper understanding of the end-to-end dynamics of the anomaly.
Related terms
- Prediction. The use of historical data and statistical or machine learning techniques to forecast future values.
Alert
Notification of a data condition.
An alert is a mechanism for notifying and recognizing an abnormal state, sharing the urgency of such a state with others, tracking the state and an incident, and the actions taken to mitigate the impact of that abnormal state.
Terminology references
Other terminology sources in
- Product knowledge centers
- Reference architectures
- Standard
Glossary in Maximo knowledge center
Concepts in Maximo Monitor knowledge center
IBM IoT Reference Architecture
Semantic Sensor Network Ontology (SSNO)
Asset Data Dictionary
In 2021 I performed design visioning to achieve Asset Data Unification in the Maximo Application Suite and drive a common terminology, asset data dictionary, and UX experience strategy for the Maximo suite applications integration use-cases.
Objective
We were a collection of applications loosely integrated and intently focused on addressing an aspect of optimizing an asset. We are now a unified solution that optimizes an asset using the data you have and makes that available everywhere across the asset lifecycle. We are a Maximo application suite.
The objective of this information modeling aimed to identify the key data integration use cases across the applications on the Maximo site.
The outcome of the discovery was driving the information model schema for a Data Dictionary backend service, using the KITT semantic graph service. The discovery also defined concepts for unifying a common integration experience.
Maximo application suite
Maximo application suite provides intelligent asset management through a set of applications for asset monitoring, asset management, predictive maintenance, and reliability planning.
The suite is a single, integrated cloud-based platform that uses AI, IoT, and analytics to optimize performance, extend asset lifecycles, and reduce operational downtime and costs.
The suite includes Manage, Monitor, Health, Predict, and Mobile applications.
Learn more about the IBM Maximo Application Suite on IBM.com.
Maximo application information models
The application information model, defining the foundational objects and their relations was identified in discovery sessions with each Maximo suite application team. Key objects, their workflows, and use cases were discussed to define common suite-level object types, dependencies, and integration requirements.
Maximo Manage
Maximo Manage, also known as Maximo EAM, has a rich information model. The core model defined for a data dictionary includes sites, systems, locations, assets, meters, work orders, and failure code objects.
The Maximo Manage information model.
- A production Site has operational Systems.
- A System has a hierarchy of functional Locations.
- An Asset, and its Asset and Item parts, are installed at a functional Location.
- Assets and Locations have Meters.
- Meter readings are provided as Data from Devices.
- A Work order is related to an Asset and may be classified by a Failure code.
The Maximo Manage object relationship model.
Maximo Monitor
Maximo Monitor, also including the IoT platform, has a rich device, data, function, and alert model. The Monitor model also associates devices with the assets as data sources. In Maximo Manage, the IoT Platform registers and connects devices, and ingests time-series device data. Maximo Monitor provides a streaming architecture that processes ingested time-series data using statistical functions and AI models.
The Maximo Monitor information model.
- An Asset is of an Asset Type.
- An Asset is installed at a Location.
- An Asset has Data metrics that may be Raw, Computed, or Alerts.
- Raw metrics are ingested from physically connected devices.
- Computed metrics use KPI Functions to Transform, Aggregate, or detect Alerts, using raw metrics data as parameters.
- Asset data is monitored on Dashboards.
- Assets of a common asset type may share a common Dashboard instance layout.
IoT Platform information model.
- A Device is of a Device Type
- Data from a connected device is received as Events of an Event Type.
- A Device has private data Properties in the Physical Interface that mapped to Events
- A Device as public data Properties in the Logical Interface that is mapped to the Physical Interface Properties.
- A Raw Metric in an Asset receives data from a Device Property.
Integration points
- Assets are logically equivalent to Assets in Manage.
- Locations are logically equivalent to Locations in Manage.
- Alerts are logically related to Service Requests and Work orders in Manage.
The Maximo Monitor object relationship model.
Maximo Health and Predict
Maximo Health and Predict is providing conditional, preventive, and predictive maintenance data for Assets. The current condition of an asset is defined by the asset’s historical data, computed as a health score. A future asset condition is defined by failure predictions and recommended maintenance actions.
Maximo Health and Predict information model.
- An Asset may be part of a Health Scoring Group, and a Predict Group.
- A Health Score is computed by a Health Scoring Function that uses Asset Mater Data and Asset Metadata.
- A prediction is computed by a Prediction Model, that provides predicted Asset Details and recommended Actions, such as creating a Work order, a Service request, or a Replacement plan.
Integration points
- Recommended actions are Manage work order actions.
- Prediction models use Asset Meter data in Manage, and Asset Device data in Monitor.
The Maximo Health and Predict object relationship model.
Maximo suite model
A common Maximo suite model was derived from the abstract Maximo suite terminology and common object types from the Maximo suite application information models.
- System
- Location
- Asset | Asset Group
- Data
- Function
- Alert
- Work order
In the diagram below, the abstract object types, shown in grey, and the relationships to concrete application object types.
- Assets are defined as a parts hierarchy.
- Assets are related to the system location hierarchy.
- Data is unifying multiple types and sources.
- Functions unify computational formulas and AI models.
- Assets are grouped for comparative health scores and predictions.
- Alerts on abnormal asset Data generate maintenance Work orders.
The Maximo Application Suite object relationship model.
Maximo Data Dictionary
Digital Twin Semantic Knowledge Graph
The Digital Twin Semantic Knowledge Graph technologies, developed for Industry 4.0 by IBM Research, is implementing a Maximo Data Dictionary service in the Maximo suite.
The Semantic Knowledge Graph service is designed to address many problems in data integration and management.
- Providing a semantic model that simplifies data modeling by implementing a semantic representation, easily extended and refined to specific industry use case requirements.
- Allows users and developers to view and filter data to their needs.
- Enables AI and machine learning at scale by providing machine learning algorithms good understanding of the context of the analytic subject.
- Join data from different services, multi-cloud, and multi-tenant sources.
- Optimized for performance around solving complex relational queries on data to enable powerful queries in real time.
Semantic graph models describing industry data are more expressive and flexible than traditional data models. The Semantic Knowledge Graph service is a cloud solution that combines an extensible semantic model, with a data platform to enable easy access to data and to drive analytics at scale. It’s neither a graph database nor a relational database. It uses a graph to semantically describe and connect data that may be stored in relational databases, NoSQL databases, object stores, or data lakes. The Maximo suite creates a unified suite access layer that provides search and queries to common data and links to each application data store for object data details.
The Maximo Data Dictionary consists of a semantic core model. The model is kept simple and abstract to model the core of data that should be exchanged by the applications. Applications can specify extensions to the model to map and extend this core model to their application data models.
Learn more about IBM Digital Twin Semantic Knowledge Graph technologies and the Maximo Data Dictionary.
Scaling Knowledge Graphs for Automating AI of Digital Twins.
Maximo Data Dictionary schema
The Data Dictionary schema.
- Node elements. The asset and location hierarchy is designed using a semantic graph and is defined using a generic super-type Node representing Location and Asset. A node can contain other nodes using the hasPart relationship and relate via relates to other nodes.
- Data elements. Data represents time-series data associated with assets or locations. Data may have relations to other data sets such as cleaned data may refer to raw data.
- Task elements. A task represents work such as a work order, ticket, or service request.
- Organization elements. An organization is a record that identifies a unique legal entity. The data set for an organization includes information that companies or other distinct legal entities might share, such as calendars, vendors, and financial information. An organization can contain one or more sites.
- UI elements represent Dashboards and Cards on dashboards.
The data dictionary core schema is extended and mapped to specific application object types.
Data Dictionary Asset mappings.
Data Dictionary Location mappings.
Data Dictionary Data mappings.
Data Dictionary Work Order mappings.
Data Dictionary Function mappings.
Data Dictionary Organization mappings.
Data Dictionary Dashboard mappings.
Maximo Data Dictionary integrations
The Asset Data Dictionary is installed with the Maximo suite and manages a repository of data and metadata that facilitates data sharing and integration between Maximo Manage and other applications. Using pre-defined artifacts in the Maximo Manage integration framework, data in Maximo Manage can be synchronized with the Asset Data Dictionary, which in turn integrates the data into other applications, such as Maximo Monitor.
Pre-defined artifacts are available for integrating data about organizations, sites, assets, asset hierarchies, operating locations, location systems, and location hierarchies.
The Asset Data Dictionary provides seamless adoption across Maximo Manage and Maximo Monitor and allows organizations to adopt paths.
Manage first. Many customers are using Maximo EAM in operations and have established use of location and assets. When adopting Maximo Monitor, the data dictionary synchronizes the system hierarchy and provides assets and meters as integration points for instrumented devices and real-time sensor data.
Monitor first. Customers starting to use Monitor can create a system hierarchy with devices, assets, locations, and dashboards. When adopting formal enterprise asset management, the location hierarchy and assets and created in Maximo Manager as managed objects.
The Maximo Monitor to Maximo Manage integration is a one-time process. The data synchronization can be performed manually when needed, at regularly scheduled intervals, or as event-based updates when data changes.
Learn more about Integrating with Asset Data Dictionary.
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
Lab Introduction
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 with 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.
Lab Introduction
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 with 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.
Lab Introduction
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 with 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.
Lab Material
View the lab instructions below, or download for remove reading.
https://design.gothe.se/download/monitor101-labhandbook/
Download lab handbook