mats

About mats

Posts by :

April 17, 2020

Monitor Personas – Bryan, 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 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 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, 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 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

Text content

Key Stakeholders

Bryan depends on the following key stakeholders

Application Administrator
Maintenance Supervisor
Maintenance Engineer / Technician

Monitor Personas

Learn more about the Monitor personas.

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

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

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

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 the asset and prioritize the severity for this type of alert
Trouble-shoot the alert by drilling into the data point, view, zoom and pan the current data in and around the time of the alert and compare to historical trends
Uncover root-causes of the alert by viewing and comparing related data points at system or process levels
Confirm system state on SCADA dashboard(s)
Take action by assigning service request

Configure Use-Cases

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

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

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

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

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

Monitor Use-Cases

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

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

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

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

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

Anomaly Alert Design

Alert Information Model

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

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

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

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

Alert Lifecycle

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

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

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

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

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

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

Alert Presentations

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

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

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

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

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

Alert Dashboard Card Designs

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

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

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

Alert dashboard card.

Custom alert dashboard card.

Line graph dashboard card with alert overlay.

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 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 an external AI tools.

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

Anomaly Models and the Function Catalog

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

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

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

Anomaly model functions in catalog.

Anomaly model configuration.

Alert functions in catalog.

Configuring Maximo Services

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

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

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

Manage Services page.

Creating a new service request in alerts table.

Adding new Maximo Service connection.

Create a new Maximo service request.

Anomaly Monitoring Scenarios

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

Robot Monitor Scenario Design

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

Mastering Dashboards in Maximo Asset Monitor

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

Munich IoT Monitor Scenario Design

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

Maximo Asset Monitor 101

Hands on Lab on IBM Maximo Asset Monitor.

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 fictious operator and facility manager Bryan.

IBM is investing over $3 billion USD into Internet of Things – including $200 million USD 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 every-day experiences and challenges for Operators and Administrators;

Scale of deployment and management
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 fictious 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, noice, 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, and 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, to 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 over view of the building health. He then applies filters to drill into floors and zones that 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 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 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 an over utilization 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 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’s on multiple floors after 3pm 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 look for 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 has 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, and barometric pressure and ambient noise

The devices contains sensors that are individually registered as Device Types and connecting with Maximo Asset Monitor over 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 helps to identify devices of a specific sensor type and its 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 is a sending sensor data reading each every minute. In a total, 500.000 data events 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 to 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 has been configured for all sensor types. These mappings transforms data units from Kelvin temperatures to Fahrenheit, and noise levels to dB. Mappings also computes KPIs like Comfort Levels and Regulatory Compliance levels for temperature, CO2, noise, light, humidity and air pressure. Mappins 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. Lets decompose that statement a bit. Bryan, the Facility Operations Manager, the summary dashboards provides an overview of KPIs across all regions and buildings, including the Munich IoT Center building. And it allows a filtering to a selected building and its floors, zones, workstations and environmental sensors. Summary dashboards presents aggregations by 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 the a Workstation Summary dashboard is presented below.

In the Munich IoT Center demo, three main summary dashboards designs for operational metrics and KPIs; Building overview, Performance and Alerts. All dashboards uses 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 present 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 a 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 dashbaord 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.

March 18, 2020

Maximo Asset Monitor 101

mats Monitor-Conferances

In this lab and workshop you will get an end-to-end overview and hands-on experience to quickly get started with IBM Maximo Asset Monitor and take advantage of operational monitoring using the leading AI and IoT platform for industrial IoT. You will use live sensors from the IBM Munich IoT Center and the Maximo Asset Monitor to gain analytics insights into the environmental conditions, the compliance to regulations and the utilization of the building.

In the first part of this lab, you will explore the types of sensors and events sent from the devices instrumenting the floors, zones and workstations in the IBM Munich IoT Center building. You will explore event data ingestion and the data transformation performed by the Watson IoT Platform Service as sensor data streaming into Maximo Asset Monitor.

In the second part of the lab you will explore monitoring of operational metrics and performance KPIs. You will deep-dive into the analytics capabilities in Maximo Asset Monitor and explore metrics on facility conditions, comfort levels and utilization. You will explore how to configure dashboards for monitoring operational metrics and performance KPIs. These dashboards may display the operational metrics on a single workstation, or KPIs on the building or its floors and zones. you will also explore AI capabilities like analytics and anomaly models to get notifications of abnormal data points and take actions to assign work orders on the alerts.

AI brings asset monitoring to life, resulting in a full operationally-scalable monitoring solution. AI-powered anomaly detection and configurable dashboards ensures 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 dashboard in the lab. You will explore how cards are configured on the dashboard that monitors the current operational metrics of the Munich IoT Center, an image of the floor plan with data drill-in hot-spots, an alert table with detected anomalies in the comfort and compliance data, and finally time-series graphs showing the current and historical operational metrics with alert overlays.

View the lab instructions below, or download for remove reading.

MaximoAssetMonitor101-Lab%20Handbook-v1.0

Download lab handbook

March 17, 2020

Monitor Personas

mats Monitor-Research

Key Stakeholders

This acricale overviews the persona stakeholders in the Maximo Asset Monitor application.
These key stakeholders are:

Bryan – Operator

Oscar – Application Administrator

Ed – Maintenance Supervisor

Eli – Maintenance Engineer / Technician

Key stakeholder interactions in the Monitor user journeys.

Bryan, the Operator

Bryan, the Operator

Learn more about the details of Bryan the Operator persona.

Oscar, the Application Administrator

“I setup and configure the Maximo 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.

Devices

5-7 years of experience

Also known as: Maximo administrator, Maximo Asset Monitor administrator

Computer Science

Maximo Suite, email, sms

Responsibilities

Performs application package installation and maintenance
Configures application and service integrations
Performs access control administration, including Uses, APIs, Groups and Roles
Works with a LOB to define the business process workflows, then translate them into application settings and configurations
Works with Business Analyst to configure application AI models and rules
Configures data source connections and manages data ingest and data transformation
Defines data storage schemas

Needs

I need a reliable and performing IT infrastructure services for my Monitor application
I need to understand the business requirements and the operational and engineering practices to configure the monitor solution
I need to be a bit of a developer to do the tool configurations

Ed, the Maintenance Supervisor

“What are the priorities today…and how often will they change?””

Ed is the Maintenance Supervisor that schedules maintenance tasks based on maintenance schedules, anomalies, or predictions of failure.

Devices

5-7 years of experience

Mechanical Engineering

Also known as: maintenance manager, lead maintenance technician

Maximo

Responsibilities

Respond to urgent and changing maintenance priorities
Plan open work and and match qualifications of team members
Stay updated with team member assignments
Reporting status

Pain Points

Constantly firefighting –moving techs from one hot job to another –leading to cost and schedule inefficiencies
Techs complaining about assigned work
Unqualified labor Inaccurate or incomplete information on work order (send tech to wrong location)
Work being poorly planned

Tasks

Manage ever-changing priorities of work (Approve, Assign, Manage, Close)
Match qualifications of team members to open work.
Knowing where each team member is at all times
Reporting status to his boss, other managers and Brianna (Peer)
1:1 Time with Technicians on Daily Basis (Chat, Coffee)

Eli, the Maintenance Engineer

Eli is the Maintenance Engineer that services equipment based on work orders and job plans.

Devices

1-3 years of experience

Mechanical Engineering

Maximo

Also known as: engineer, technician, maintenance technician, journeyman, craftsman

Responsibilities

Perform incident repairs to resume operations
Asses and act on alerts to minimize downtime, damage, risk
Perform assigned maintenance
(scheduled, preventive or predictive)
Keep my list of assigned work orders down
Improve equipment performance
Improve site productivity

Pain-Points

May not know “What’s wrong? What’s causing this?
Feels responsibility for M$ process disruptions or risk to life
I need access to the equipment to keep my ‘wrench-time’. Have tools and parts available, in time.

Needs

Access to assigned work orders, by priority
Access to production line equipment, documentation, plan drawings
Maintenance description
Access to real-time equipment sensor data
Notifications from equipment control system
Task descriptions to resolve an incident

March 17, 2020

Robot Monitor Scenario Design

mats Design Portfolio, Monitor-Designs

The Robot Scenario Context

The Robot scenario is a rapid design demonstration scenario on the use of Anomaly Monitoring and Monitor Dashboards in Maximo Asset Monitor.

The scenario outlines a fictions manufacturing company ACME with 4 production sites in the US. The sites are located in Alphaville, Betacamp, Charlyton and Deltalake. The production assembly lines at the sites has robots instrumented with sensors connected to the IoT Platform cloud service running as part of the ACME Maximo Asset Monitor tenant. The robots report data metrics from the robot arm on torque, load, speed and acceleration at 5 minute intervals.

Over the last few days one of the robots in Alphaville has been anomalous data values on robot arm torque. Also speed and acceleration of the robot arm seem to be impacted. The alerts from the robot is notified to the operator at the ACME remote operations team. Bryan the operator will start a root-cause investigation and trouble-shoot the abnormal values. Once he has validated the alert he will create a service request for the maintenance engineering team in Alphaville to resolve the issue before the robot breaks and causes a halt to the production line.

Simulating the ACME Robots

The robots in this scenario are simulated on IBM cloud using a NodeRed flow. The simulator sends robot data events every 5 minutes as MQTT messages to the Watson IoT Platform service included and preconfigured in Maximo Asset Monitor. The event contains robot data for load, torque, speed and acceleration using the following MQTT event message schema in JSON format.

    {
       “load”: 375.65,
       “torque”: 10.855,
       “speed”: 2.503,
       “acc”: -0.164
    }

The simulated data is a mainly random values within a set range for each metric. To simulate anomalies, random data spike values are added to the torque data to show reoccurring abnormal data indicating a possible root-cause of a future robot failure.

Anomalous ACME Robot torque values at Alphaville site.

Configuring Anomaly Detection

All ACME Robots in this scenario are of the same type and sending the same torque, load, speed and acceleration sensor data. The robots are monitored as an ACME_Robot entity type with torque, load, speed and acc metrics. Maximo Asset Monitor provides an out of the box catalog of anomaly model function that can configured with data metrics as inputs. The model computes an anomaly model score. The score is a likelihood of an anomalous data within a time windows of data samples. The anomaly function scans the time-series torque data and produces a time graph of anomaly scores. Maximo Asset Monitor provides a predefined set of anomaly models. In the robot scenario demonstrator we are using a saliency based generalized anomaly scoring model. The model employs Saliency and GAM on windowed time series data to compute an anomaly score from the covariance matrix. An alert function in Maximo Asset Monitor can be configured with the anomaly model score as a parameter to compare with a set threshold. If the score is above the threshold an anomaly is detected and an alert is created. In this scenario the torque anomaly alerts is set to trigger alerts at a threshold of 100.

Maximo Asset Monitor analytics function catalog with out-of-the-box anomaly models.

ACME Robot torque score values generated by the anomaly model. Score values above 100 are set to generate anomaly alerts.

Configuring Robot Dashboards

Maximo Asset Monitor provides two types of operational monitor dashboards; Summary Dashboards and Entity Dashboards.

A Summary Dashboard is a dashboard type that presents aggregated KPIs and provides drill-in to aggregated metrics using hierarchical filters. Let’s decompose that statement a bit. For the operators at ACME, the Robot Summary Dashboard presents an overview of KPIs across all ACME sites. And it allows a drill-in to a selected site, a selected line, and a selected robot. Robot data, resulting from the selected filter, is aggregated and presented as statistical units. For example, maximum, minimum and mean values across all robots passing the filter. Data is also aggregated across a time grain. For example by hour, by day, by week, by month. This allows the KPIs to be tracked and compared over various levels of the organization and at shorter or longer time ranges. An screenshot of the Robot Summary Dashboard is given below. The screen shows filtering the KPIs of the robots to an hourly report of the Alphaville manufacturing site.

ACME Robot summary dashboard.

An Entity Dashboard is a dashboard that present operational metrics of a single entity. In this scenario a single robot. Metrics from a single entity can be presented without any aggregation and in near real-time. Robot metric values and anomaly alerts are presented on values cards, tables and graphs on the dashboard. The Robot Entity Dashboard for one of the robots at Alphaville is shown below.

ACME Robot A1 entity dashboard.

Monitoring Alerts

Operators approach the task of monitoring by identifying and prioritizing alerts on the Alerts page, or by identifying ‘assets in trouble’ using Summary Dashboards.

Maximo Asset Monitor provides an Alerts page that summarizes all alerts across all types and entities in the system. An ACME operator may filter the Alerts to identify the most critical alerts on the most critical assets and start root-cause analysis by following the link on the alert to the entity raising the alert. An example of the Robot Alert Page for the ACME robots is presented below.

As shown on the screens above, alert tables may also be included on summary dashboards and entity dashboards.

Alerts page in Maximo Asset Monitor providing a tabular view of all alerts from monitored asses in a system.

Creating Service Requests

Operators validate alerts and trouble-shoot the root-cause of the anomalous data by inspecting the short and long term asset behaviour using historical metric data using the time range picker on the dashboards. Once the anomaly is validated and the root-cause is identified, operators will create a service request for maintenance supervisors to plan the work order for maintenance engineers to resolve the issue.

As shown on the screens above, a service request may be created including reference information of the asset id, job code and links to the alert in Maximo Asset Monitor.

Creating a new service request from an alert in Maximo Asset Monitor.

Get Hands-On with Maximo Asset Monitor Dashboards

Explore the steps to configure the dashboards for ACME robots in the Hands on Lab Mastering Dashboards in Maximo Asset Monitor. In the lab you will start by exploring more in detail the sources of robot data that you will monitor. You will then learn the steps of configuring an operational dashboard for monitoring the metrics, trends and anomaly alerts from the ACME robots. You will use the monitor dashboard presentation techniques of value cards, graph cards, table cards and image cards with hot spots. You will also explore summary dashboards that provide data aggregation and filtering to monitor your performance KPIs.

Mastering Dashboards in Maximo Asset Monitor

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

Mastering Dashboards in Maximo Asset Monitor

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

March 17, 2020

Mastering Dashboards in Maximo Asset Monitor

mats Monitor-Conferances

In this hand-on lab you will get a practical introduction to the use of dashboards in IBM Maximo Asset Monitor.

You will start by exploring the sources of data that you will monitor. In this lab we will use data from simulated industry robots. You will then learn the steps of configuring an operational dashboard for monitoring the metrics, trends and anomaly alerts from your robots. You will use the monitor dashboard presentation techniques of value cards, graph cards, table cards and image cards with hot spots. You will also explore summary dashboards that provide data aggregation and filtering to monitor your performance KPIs.

Mastering Dashboards in Maximo Asset Monitor

The ACME_Robot dashboard above shows the final dashboard state of the lab. You have added cards to the dashboard that monitors the current operational metrics of the robot, an image of the robot with data drill-in hot-spots, an alert table with detected anomalies in the robot data, and finally time-series graphs showing the current and historical operational metrics with alert overlays.

View the lab instructions below, or download for remove reading.

MasteringDashboards-LabHandbook-v1.0

Download lab handbook

Download dashboard JSON files

March 11, 2020

test

mats

Text content

February 24, 2020

Carbon Design System – A Practical Example

mats Articles, Design-Articles, IBM Design

Introduction

Want to get a modem, consistent and great looking sparking user experience and visual design? Why not take a look at the latest version 10 of the Carbon Design System with guidelines and resources from the IBM Design Language.

“Carbon is IBM’s open-source design system for products and experiences. With the IBM Design Language as its foundation, the system consists of working code, design tools and resources, human interface guidelines, and a vibrant community of contributors”

This article presents a practical example of some of the highlights in the Carbon Design System and brings a pragmatical approach to a modernization task. In this example I use my rather simple portfolio website to apply Carbon-styling to an existing interface. I also demonstrate some of the basic elements of Carbon to help you get started.

First we will overview some of the Carbon Design System basics like colors, icons, typography and layouts. We will then look some practical examples of applying the Carbon 10 resources to an existing visual design. The articles also shares a new few links to references and to reusable LESS/CSS and Sketch resources.

Great, let’s look at how Carbon can provide a foundation for a sparking carbonized design.

Carbon Design System and the IBM Design Language

As mentioned above, Carbon is an open-source design system built from the following guiding principles

Open for anyone to use and contribute
Inclusive of all, regardless of ability and situation
Modular and flexible in use
Putting the user first
Builds consistency by ensuring a consistent experience

The Carbon design system includes guidelines on the principles on the design, like color, themes, icons, typography and layout. This article will discuss the application of these principles. Carbon alos provides set rich set of key component building blocks designed and coded for a specific UI problem or purpose. The 30+ components and the principles are designed to seamlessly interact into the bigger consistency of the experience. The components are provided in the Carbon Design Kit, including Sketch libraries and React and Angular UI components. Additionally, Carbon also provides patterns as best practice experiences as combinations of components that address common user objectives with sequences and flows, like dialogs, notifications, filtering and search.

In this article my focus will mainly be on the experience and visual aspects of applying Carbon.
To explore more on the Carbon Design Kit resources, visit www.carbondesignsystem.com.

Colors

The selection of colors creates uniqueness. Carbon provides a balanced and harmonic color anatomy. Colors are provided as base color palettes, themes and as tokens for a consistent user experience.

Let’s start with the color palettes. Carbon defines a natural gray and 7 color families; Green, Teal, Cyan, Blue, Purple and Magenta. Each color family is given as 10 values, ranging from light to dark colors, for example Blue-10, Blue-20, .. Blue-100. Additional single action colors values are provided in Red, Orange, Yellow and Green. The Blue and Grey color palettes and the corresponding HEX color codes in LESS syntax for Blue are shown below.

Carbon Design System – A Practical Example

@blue-100: #051243;
@blue-90: #051b75;
@blue-80: #0530ad;
@blue-70: #054ada;
@blue-60: #0062ff;
@blue-50: #418cff;
@blue-40: #6ea6ff;
@blue-30: #97c1ff;
@blue-20: #c9deff;
@blue-10: #edf4ff;

The visual design discussed in this article mainly uses gray and blue color values. The grey colors in the design comes with the White theme that we will discuss later. The blue colors comes from selected accent colors in the design.

Portfolio home page with Carbon blue colors.

Themes and Tokens

Carbon uses tokens and themes to manage color to achieve a consistent experience and visual design. There are two light themes and two dark themes; White, Gray 10, Gray 90 and Gray 100. The design in this article is using the White theme.

To achieve a consistent experience, Carbon defines tokens as code identifiers for a unique role or set of roles in the design. Tokens are universal and identified by a name consistently used across the themes. For example, a page background is defined by the `@ui-background` value. In my White theme this takes the value `#fffff`. In the dark Gray 100 theme it would take the value `#171717`.

There are multiple other roles defined for the experience. For example primary, secondary, and tertiary buttons. Backgrounds for primary, low and high contrast containers. Primary, secondary and tertiary texts, and texts for error messages and links and hovers. And the list goes on … Check the details on www.carbondesignsystem.com/guidelines/color/usage.

In applying the Carbon White theme I used a LESS stylesheet that defines the colors and tokens, and sets the values for the White theme used in the design. A code snippet of the LESS definitions are exemplified below. The portfolio design example discussed in this article, mainly uses the ‘ui-background’, ‘text-01’, ‘link-01’, ‘ui-01’, ‘ui-03’ and ‘interactive-01’ tokens.

// Core color tokens
@ui-background: @white; // Default page background.
@interactive-01: @blue-60; // Primary interactive color. Primary buttons
@interactive-02: @gray-80; // Secondary interactive color. Secondary button
@interactive-03: @blue-60; // Tertiary button.
@interactive-04: @blue-60; // Selected elements. Active elements. Accent icons.
@danger: @red-60; // Danger button background.
@ui-01: @gray-10; // Container background on @ui-background. Secondary page background.
@ui-02: @white; // Container background on @ui-01. ‘Light’ variant background.
@ui-03: @gray-20; // Subtle border. Tertiary background.
@ui-04: @gray-50; // Medium contrast border.
@ui-05: @gray-100; // High contrast border. Emphasis elements.

Layout and Spacing

Carbon defines a spacing scale useful when laying out individual components. It includes a range of large to small increments to create the appropriate relationships for detail-level layout designs.

@spacing-01: 2px;
@spacing-02: 4px;
@spacing-03: 8px;
@spacing-04: 12px;
@spacing-05: 16px;
@spacing-06: 24px;
@spacing-07: 32px;
@spacing-08: 40px;
@spacing-09: 48px;

#portfolio-headline {
background: @ui-01;
color : @black;
margin-top: @spacing-05;
}

#portfolio-headline-name {
.expressive-heading-05();
margin-bottom : @spacing-05;
}

#portfolio-headline-quote {
.expressive-heading-03();
}

Here I find the that using Sketch with the Carbon library to come handy when creating and testing the carbonized design. The layout can be defined using spacing components that guides the implementation of margins and padding’s on the individual components on the page designs. The design below shows the layout in Sketch of the home portfolio page with inserted Carbon `@spacing-09`, `@spacing-07` and `@spacing-05` spacing’s. The Sketch design guides the final coding of the styling using the LESS stylesheet declarations implementing the component spacing’s.

Typography

Carbon uses type tokens to define the typography. A type token is a pre-set style with typographic elements such as font size, weight, and line height. The typography is calibrated for use with the open source IBM Plex typeface.

Download IBM Plex from the IBM Plex Github Repo. github.com/IBM/plex

IBM Plex is also available directly for use through Google fonts.

Carbon defines typographies for two situations. A Productive typography for product and web designs. The Expressive typography for web, graphic and print usage extends the Productive design with a more dynamic typographic hierarchies and more variety with a fluid Heading scale. My carbonised design portfolio will use the Productive design typography.

The Carbon design kit provides the type tokens in the Sketch library. The type tokens can be defined in LESS to simplify the style coring.

.body-long-01 { 
font-family: 'IBM Plex Sans', sans-serif;
font-size: 14px;
line-height: 20px;
font-weight: 400;
letter-spacing: 0.16px;
}

.body-long-02 { 
font-family: 'IBM Plex Sans', sans-serif;
font-size: 16px;
line-height: 24px;
font-weight: 400;
letter-spacing: 0px;
}

Responsive design

Carbon defines fluid types for headings using 5 breakpoints across screen widths. The LESS definition uses these breakpoints in the header type definitions to implement the fluid types.

@sm: ~"(min-width: 320px)";
@md: ~"(min-width: 672px)";
@lg: ~"(min-width: 1056px)";
@xlg: ~"(min-width: 1312px)";
@max: ~"(min-width: 1584px)";

.expressive-heading-03 {
font-family: 'IBM Plex Sans', sans-serif;
@media @sm {
font-size: 20px;
font-size: 18px;
line-height: 26px;
}
@media @md {
font-size: 20px;
line-height: 26px;
}
@media @lg {
font-size: 20px;
line-height: 26px;
}
@media @xlg {
font-size: 20px;
line-height: 26px;
} 
@media @max {
font-size: 20px;
line-height: 26px;
}
font-weight: 400;
letter-spacing: 0px;
}

Icons

Carbon provides a super-rich set of icons and pictograms for visual design consistency. Check out the icons at www.carbondesignsystem.com/guidelines/icons/library. Using icon library you can view and filter and then download the icons you need directly from the library.

In the Carbon design example I only use a few icons from the library for page browsing, downloads and social media. The Up Right Arrow icon is used to indicate a navigation link to related articles. The Download icon for shared file based material.

Putting it all together

We have now explored some of the fundamental visual elements of the Carbon Design System; Colors, Themes, Spacing, Typography and Icons. Note that Carbon Design System provides many more advanced elements for web, product and digital designs, like Components, Patterns and Data Visualization. View it all on www.carbondesignsystem.com.

Let’s close this article with a few conclusions, examples and references on how to get this all together into a carbonized design. I find that Sketch and the Sketch library available with Carbon provides a great help in expressing, specifying, and testing the design. Down to a pixel perfect implementation. The Carbon library provides direct selection of the design elements like colors and components directly in the Sketch tool. Using a LESS stylesheet, in combination with an any existing CSS / LESS stylesheet from an earlier design is a great way to incrementally lay the carbon design over en existing implementation. Then drive additional style changes or redesigns from there. All in all, the experience becomes guided, practical and productive. And providing a consistent experience.

Portfolio project page design using the Carbon library with theme tokens. Carbon layout and spacings included in the visual design.

A few simple examples of designs of portfolio, project, article and session pages are provided below. These designs use Sketch and combines the definition of LESS/CSS and Carbon theme style classes for each design element. It also defines the layout using the Carbon spacing sizes in units of 48, 32 and 16 px.

Portfolio page design using the Carbon library, theme tokens and LESS styles.

Projects page design using the Carbon library, theme tokens and LESS styles.

Article page design using the Carbon library, theme tokens and LESS styles.

Carbon Design System at and across enterprise scale

Carbon is IBM’s official design system and serves a wide range of designers and developers building digital products and experiences. View examples of applying the Carbon Design System to enterprise scale product, digital and event designs at IBM on carbondesignsystem.com.

Carbon is the foundation and design language for product design of AI application and Internet of Things at IBM. The two examples below exemplifies the use of the principles discussed above, and the use of components and patterns from Carbon Design System in IBM Maximo Asset Monitor product designs.

Example design of a resource page using Data Table, Pagination, Buttons, Breadcrumb, Date Picker, Search, and the UI Shell components from Carbon 10.

Example of a dashboard page design using Carbon data visualizations.

Visit my portfolio at design.gothe.se for additional exemplifies in the use of Carbon in our product design of AI applications and Internet of Things at IBM. And look luck in creating web and product designs using Carbon.

Mats Göthe, PhD
STSM, Senior Design Lead
Maximo Asset Monitor
AI Applications, IBM

Download Carbon 10 LESS stylesheet

Download Sketch file

January 8, 2020

Device Simulator with CSV Data

mats Design Portfolio, Designs, Internet of Things, IoT-Designs Designs, IoT

In 2019 I delivered a design to integrate the IoT platform Device Simulator with IoT platform Connection and Analytics Services.

The objective of this design is to improve the customisation of simulated device data and by automation of Data Management configurations enabling data to be stored in the DB2 data lake by the Connection Service.

This design would hence deliver the following hill:
”A LOB engineer running a POC can use out-of-the-box simulated device data and in a minute with no other actions required start exploring simulated entities and apply analytics functions to the simulated entity data”

Design Requirements

The requirements on this design
Device simulator shall by default be Activated
The Device Simulator editor shall provide a setting to “Save device events to the data lake”
The Device Simulator shall automatically generate and activate a physical and logical interface for a simulated device if the “Save device events” property is selected
The Device Simulator editor shall optionally allow a CSV file to be uploaded containing a simulated time series of data.
The Device Simulator shall construct an event payload schema from CSV file column names and data types.
The Device Simulator shall, by rows in the CSV file, send data events with column values as event payload.
The Device Simulator editor shall run (as-is) in the client browser. Closing the browser will terminate simulation and ingest of simulated data
The Device Simulator shall support export / import of the simulator configuration.
Limitation: A user shall not be allowed to edit the simulated device type and the event payload schema after the physical and logical interface has been defined.

Production Design

The final production design is shown below.

Device Simulator Design.

Chris Devon

Meet Chris is the Application Developer and Devon is the Edge Device Developer.

Chris and Devon are the most frequently used personas in the developer experience design across the platform capabilities.

Simulated Devices Design

The Device Simulator design in Watson IoT Platform enables developers to build and test the IoT applications without deploying physical devices beforehand.