Menu

IoT

Help Hub Design

, , , ,

In 2017 I delivered design concepts for an improved developer experience using a help hub capability in the Watson IoT Platform.

What is a Help Hub and a Side Panel

When users launch the Watson IoT service and open the IoT Platform web interface they are taken to the IoT platform dashboard. This default behavior is desirable and efficient for existing users of the IoT platform and takes them directly to an overview of the system state. The IoT platform dashboard is a flexible solution that allows users to use default boards, or configure their personal or team boards that present the right IoT system status to every user or team.

However, for new users entering the platform for the first time, this feature may be perceived as confusing. Users are left with the question “Ok, now what? You dropped me here, what do you want me to do?”

To improve the experience for developers exploring the platform we designed a Help Hub that answers just those questions. And, provides a structured journey for developers to quickly get started with the Watson IoT platform.

Design Vision

With the Help Hub design, we want to provide a simple onboarding experience for new users of the platform. The design should create a seamless learning experience within the Watson IoT Platform; gently guiding users toward the key ah-ha moments that allow them to form a mental model of the IoT platform and its resources. This will increase the likelihood that new users achieve their goals, gain satisfaction, continue engaging with key features, and happily refer the service to others.

The design should present a list of actions for the user to take to get started. The tasks should be context-sensitive. That is, actions are presented in a sequence of importance. Once an action is completed, new action(s) are activated and appear to the user. There are conditions that make actions active. For example, if there are no device types created the Help Hub should display a task to create a device type. Or, if there is only one user registered with the IoT platform, the Help Hub should provide an action to add additional team members as users.

Some users may find the pushing of tasks a bit annoying and will turn off such suggestions. Such users will find the Side Panel helpful as a way to, on-demand, see a list of recommended tasks and easy access to documentation.  

User Research

In our research, we identified typical situations here the Help Hub and Side Panel are key to user success and satisfaction. 

Getting started – Devon is an IoT developer in a new team formed to run a POC using IBM Cloud and Watson IoT Platform to build a demo IoT applications for a line of business in a week. The POC will provide new insights and optimizations for existing products or processes.

Devon, needs to

  • Solve a business problem through innovation
  • Build a PoC to secure ongoing funding & support
  • Anticipating production-level requirements: scale, DevOps, security, etc.
  • Needs to integrate with existing systems and processes. 

Hills

“As a Developer with no prior IoT platform experience, I can within 15 minutes set up a new IoT platform organization and start developing and testing my IoT devices and applications.”

Help Hub Design Concept

The design concept for Help Hub identifies that 

  • Developers will set up their development space in IBM Cloud, add a Watson IoT Platform service and launch the IoT Platform Dashboard
  • On the dashboard, the developer will see a clear call to action to get started
  • Enough context and information on the action will be provided directly on the dashboard
  • More detailed, deeper, information is available in the IBM Cloud documentation  
  • Selecting an action will take the user directly to the right section of the IoT Platform
  • A pre-step is presented to the user. This describes the context, the resources, and the options and considerations to be taken.
  • When the action is completed, the user its taken to a post-step that salutes the achievement, and introduces the next action to be taken.

Use-cases

As a developer 

  • I need to connect devices and get data flowing into the IoT Platform
    • I need to create my first Device Type
    • I Need to register my first Device
    • I need to connect my device to the IoT Platform
    • Or, I need to simulate a device
  • I need to enable my team members to access the IoT Platform dashboard
    • I need to add a Member
  • I need to enable my application to access the  IoT Platform APIs
    • I need to add an API Key

UX Designs

Link
Help Hub Design
The initial UX design explored one Getting Started page introducing the new user to the first actions in the IoT Platform.
Link
Help Hub Design

Using the Help Hub.

Final UX for Help Hub

The final user experience design is shown below. 

When launching the Watson IoT Platform for the first time, Devin is welcomed to the platform. The dashboard suggests that he registers a device or simulates a device. He is guided by the IoT platform on how to accomplish the action. New actions follow as he adds members and API keys to the platform.

Using the Help Hub

Final UX for Side Panel

When launching the Watson IoT Platform, Chris is presented with actions to connect devices and to register members and API keys. He clicks a button, indicating that he is not interested in any guidance. Later, Chris opens the Side Panel to view suggested actions and product documentation. 

Using the Side Panel

Final Product Design

The final production design

Related Designs


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

ChrisDevon

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.


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

Design Research on IoT Edge

, , ,

In 2017 I delivered design research for an improved IoT Edge developer experience in the Watson IoT Platform.

What is IoT Edge?

Edge devices generally live on the edge of the network within an enterprise. They are specific hardware sensors, industrial controllers, or other industrial devices residing on private or potentially proprietary networks at a physical location.

Edge devices are creating quite a challenge for systems integrators since most are generally building cloud-based applications which rely on receiving information from IoT devices to accomplish the business goal.

There are many challenges that exist in developing a path for this information flow, including message/network protocols, bandwidth requirements, redundant data reporting, and data routing/orchestration

IoT Edge Challenges

Our design research summarises the insights of main challenges with IoT at the Edge 

Latency and Time

  • Time to response – Can not wait for a real-time cloud control response to a system state that may already have changed
  • Loss of cloud connectivity – Loss of cloud-based control may block instrumented operations

Quality and Time

  • Time to insight – It may be better to get less qualitative insights rapidly from a local computation, than wait for deep data insight from a cloud analytics service.

Bandwidth and Cost

  • It may be expensive to transfer and store all data from connected devices
  • Large IoT data traffic may choke the available bandwidth for other business solutions
  • Data gravity plays in favor of IoT cloud vendors rather than the customer

Security and Vulnerability

  • With more types of devices directly connected the vulnerability and risk of data loss increases

Compliance

  • Laws, regulations, confidentiality, and privacy may limit data to be shared or cross over borders
  • Depersonalization and masking may be required at the edge before sending to the cloud

Maintenance and Operations

  • The effort to manage instrumented assets at the edge at scale is generally underestimated
  • Managing configuration upgrades and scheduling rollouts of updates
  • Centralized management of distributed device and gateway status and health

User Research on IoT Edge Development

Based on our research we find that 

  • IoT Edge is today on the agenda for Solution Architects / Application and Device Developers / Executives / Operators
  • Organizations today have already, or are planning, an IoT Edge strategy and are developing code for devices and gateways mostly in Python and Node JS
  • Development teams are building new firmware and applications for IoT devices at the edge. They care about Remote updates / Edge analytics / Local messaging. 
  • They use ARM / Linux / MQTT / IP / Bluetooth

Devon the IoT Edge Device Developer

Devon develops and tests code for a device type that integrates sensors, actuators with analytics and control capability on the edge device. He reuses core IoT device capabilities for device security provided by the chip manufacturer, MQTT messaging, and device management. He develops his custom device behavior and protocols on the device.

He packages the device type configuration of capabilities and uploads to the IoT Platform for provisioning to devices of the type.

Role

  • Develops code for devices and gateways
  • Tests and troubleshoots networking protocols
  • Makes use of highly secure and scalable protocols for developing clients to talk to the platform
  • Makes sure that the device passes tests on connection, data transfer, device management, and security use/test-cases

Goals

  • Connects devices to the cloud to transmit data and perform tests
  • Code, test, debug and maintain firmware for devices and gateways
  • Optimizes device performance by edge capabilities
  • Monitors and reports on the performance and health of devices
  • Simulates and analyzes device data to verify features

Chris the IoT Application Developer 

Chris is developing services and applications in an IoT solution based on a cloud and edge service architecture in Bluemix that integrates with the IoT Platform.

He develops microservices that respond to state and conditional events and implement the business workflows and applications.

Role

  • Develops cloud applications and services that depend on data and events from the Watson IoT platform
  • Uses IoT platform and database APIs to access device data
  • Responsible for system architecture, technology selection, code development and validation, and system integration testing

Goals

  • Minimum set up for the new environment
  • Implement data models
  • Connect simulated devices and play with the data
  • Create and test applications, micro-services and exposing APIs
  • Use client libraries to code productively

IoT Edge Developer Journey

The developer journey for Chris and Devon

  • Create or Join new Bluemix developer space(s)
    • Select a Bluemix Starter Kit with Cloud and Edge services included and configured
    • Configure local developer tools and shared team environments
    • Configure build and stage delivery toolchains
  • Define IoT solution architecture and components
    • Develop micro-services containers
    • Develop functions and packages
    • Develop IoT Data Management resources
    • Develop message routing and actions
  • Distribute cloud components to the edge
    • Distribute micro-services containers to the edge
    • Distribute function packages to the edge
    • Develop message routing and actions at the edge
    • Distribute IoT Data Management resources to the edge
  • Deploy and Operator in production
    • Stage IoT solution (updates) to production
    • Provision (updates) to devices and gateways at the edge

Related Designs

New designs are emerging in the Watson IoT Platform for IoT Edge.

Getting Started with IoT Edge
DevZone Lab at Think 2018 on IoT Edge using Preview 2 Beta.

ChrisDevon

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.


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

Getting Started with IoT Edge
DevZone Lab at Think 2018 on IoT Edge using Preview 2 Beta.

What the heck is a THING – Device abstractions and thing aggregation for Internet of Things

, , , ,

Abstract

Make and model of products from a single manufacturer include a lot of variability in the underlying components and sensors. When you are building IoT solutions to work with a range of connected THINGS from many suppliers, you start to realize the huge challenge you face managing the interaction with this broad and complex device ecosystem. Wouldn’t it be better if the IoT application developer could just interact with a standard resource model and the underlying IoT platform managed the relationship between the model and the real-world devices? Come and learn more about the latest innovations in the Watson IoT Platform.

This session presents the new Information Management capabilities in the Watson IoT Platform for device abstractions and things aggregation that is the basis for the Digital Twin work for IoT.

 

TLE2017StockholmOct5.Things.public

 



Download presentation

Simulated Devices Design

, , , ,

In 2017 I delivered design concepts for an improved developer experience using simulated devices in the Watson IoT Platform.

What is a Simulated Device

Devices are smart sensors that instrument equipment at the edge. They connect to the IBM Cloud through the Watson IoT Platform. Devices send messages, using the MQTT messaging protocol, to the IoT platform. The messages contain sensor readings formatted as JSON payloads.

To connect a device to the IoT platform developers need an actual physical device. Most IoT developer has devices ready to connect. But in some cases, a lack of an available device may become a delay in exploring the IoT Platform and start developing IoT applications. The IoT Platform should support developers to get started even without a physical device to connect. This blog describes the design of a new flexible capability to set up simulated devices in the Watson IoT Platform.

Design Vision

With Simulated Devices, we want to improve the getting started experience for device and application developers.

The design vision is to allow users to create simulated virtual devices of a new or an existing device type. Users should be allowed to define the messages that the device should send, set up a schedule for the frequency of messages to be sent, and then turn on the device. Directly in the IoT Platform. As simple as that!

We want to deliver this capability independently of the IoT Platform backend and make the simulator run in the client browser. We also want to be conservative about the number of messages and data volume sent to avoid choking the IoT platform with high volume data or spending the free data plan for trial IoT Platform clients.

User Research

In our research, we identify two developer personas.

Devon, a Device Developer. Devon develops and tests code for a device that integrates sensors and actuators with the OS and CPU board capabilities. He integrates MQTT and device management protocols on the device. He uses SDKs provided by chip manufacturers and applies security by design principles.

Chris, an Application Developer. Chris is developing applications and services in a connected product IoT solution based on a cloud service architecture in IBM Cloud that integrates with the IoT Platform. He develops and tests his components locally and deploys to a team development space in the cloud configured with an IoT Platform using live or simulated device data.

In most cases, Chris may have a device delivered by Devon to use for application development and testing. In other cases, Chris needs a simulator to proceed with exploring the IoT Platform APIs, Data Management interfaces and transformation, State change events, and other aspects of the integration of his IoT Application with devices and data on the IoT Platform.

In this design, we primarily focus on Chris the application developer and his first steps in exploring and getting started with the IoT Platform. We want Chris to quickly get live devices and data. Secondarily we support Devon in his everyday use of the platform to develop new device firmware. Using the simulator, Devon can test and deliver new message schemas to Chris and early validate new firmware specifications with Chris applications running with the IoT Platform.

Hills

We defined the following hill for Chris the application developer

“As a Developer with no prior IoT platform experience, I can within 15 minutes set up a new IoT platform organization and start developing and testing my IoT devices and applications using simulated devices”
“As a Developer creating a new Device Type, I can choose to register a new physical device, or simulate a device of the new type”

Device Simulator Design Concept

The design concept for Simulated Devices identifies that 

  • Simulated devices are a core part of the platform experience
  • As a developer you opt-in for this capability in IoT platform settings
  • The simulator is driven by a floating panel easily available from any screen in the IoT platform  
  • Simulated devices act as any other device on the platform; they are of a device type, they have an identity, they send messages to the platform, like any physical device.
  • Messages from simulated devices act as any message on the platform; they are received on a topic, they are of a message type, they are put into the last message cache, they are passed to applications, like any message from any physical device.
  • There may be multiple simulated devices of a single device type
  • There may be simulated devices of multiple device types
  • There may be both simulated and physical devices of the same device types
  • Simulated devices may mimic physical devices and send events that are already the last message cache. (So if I once had a device connected that sent a message I have to use a simulator to act as that device and continue to send messages.)
  • I can set up variability in messages so data randomize between two end-points.
  • I can set up variability in messages so different simulated devices, of the same type, send different data messages.

 

The design should also provide shortcuts in other parts of the IoT platform to provide hints to developers to use simulated devices to make progress. 

  • Shortcuts put on IoT platform panels, can set up simulations with one click.
  • Rather than pulling simulators out in the developer experience and out of context, they are integrated into the development flow

Use-cases

As a developer 

  • I can opt-in and enable simulated devices and get a ‘Simulated” device type added to my organization
  • I can add (one or more) simulated devices and give them a name (pattern) “MyDevice” or “MyDevice#” and get a default event/payload sent to a topic, alternating over these instances.
  • I can browse the list of devices on the platform and view real and simulated device and their state (raw data)
  • I can specify the JSON payload schema for devices
  • I can specify a data range for simulated element values
  • I can add (one or more) additional simulated devices by id
  • I can specify a different JSON payload schema for different devices

UX Designs

The initial UX design explored two major screens in the IoT Platform.

The main simulator page for devices of a selected type. On this page, users can add new simulated devices, or select an existing registered device to be simulated. Users can also turn on/off the simulation.

Link
Simulated Devices Design
Link
Simulated Devices Design

Final Production Design

The final production design is shown below.

In the first user journey below, Chris is entering the IoT platform. He enables Simulated devices on the settings page. When opening the simulator he is informed that he needs to create a device type. He switches to the Device Type section and creates a new temperatureSensor type. He then returns to the simulator, modifies the default message to send a temperature value. He creates a device that is given the default name TemperatureSensor-1. The simulator starts to send 20.0 C values. Chris modifies the message schema to send temperature values in a range between 15.0 and 20.0 C. 

Configure a new simulated device.

 

In the second user journey below, Chris is using an existing device type TiSensorTag and an already registered device TiSensorTag-1. The device has previously been connected to the IoT Platform and an event exists in the last event cache. Chris configures the message to match the registered device. 

Simulate a registered device.

 

The configuration of types, events, and devices in IoT Platform Device Simulator simulator can be Exported and Imported across sessions, users, and test cases. 

Use the Import/Export tab to manage simulations using a JSON definition of the simulator configuration.

Link
Simulated Devices Design

Related Designs


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

Getting Started with Simulated Devices
DevZone Quick Lab at Think 2018 on Simulated Devices.

“All IoT Platform Design Partners strongly agree with the importance of simulated devices to their organisations and that the design meets their needs.”

ChrisDevon

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.


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

Getting Started with Simulated Devices
DevZone Quick Lab at Think 2018 on Simulated Devices.

Design Research on IoT Developer Experience

, , , ,

In 2017 I delivered design research for an improved developer experience in the Watson IoT Platform.

User Research – IoT Developers

In our developer experience research, we gained insights from multiple sources

  • Roles – Device and Application Developers, Architects, Product Leads, and Operators
  • Organizations – IBM IoT developer teams, Individual developers, Startups, System integrators, Global enterprises 

We found that a majority is developing or researching IoT products and solutions for their companies. We also found that a majority of the companies are developing IoT products and solutions today.

In our research we focused on two developer roles; the IoT Device Developer and the IoT Application Developers. Both depend on the Watson IoT Platform as a service for connecting their devices or integrating with their applications. 

We found that developers use the following tools and technologies 

  • HTTP and MQTT (>50%)
  • Eclipse or Device manufacturer IDEs (>50%)
  • Device development: C / C++ (>50%)
  • Gateway development: Java (40%), C / C++ / Python (30%)
  • Cloud development: Java (50%) but also Javascript, Node.js, Python (25%), and NodeRed 
  • Devices integrate sensors (>85%) or actuators (>50%)
  • Devices act as network gateways (>50%)
  • Applications perform analytics (>50%) and are mobile (50%)

Devon the IoT Device Developer

Devon the device developer, develops and tests code for a device that integrates sensors and actuators with the OS and CPU board capabilities. He integrates MQTT and device management protocols on the device. He uses SDKs provided by chip manufacturers and applies security by design principles.

He uses a team development space and connects the device to an IoT Platform to test connections, data transfers, device management, and security use- and test-cases.

Role

  • Develops code for devices and gateways
  • Downloads his code to a testbed with devices that connect to an IoT Platform
  • Makes sure that the device passes tests on connection, data transfer, device management, and security use/test-cases

 

Goals

  • Connect devices to the cloud to transmit data and perform tests
  • Code, test, debug and maintain firmware for devices and gateways
  • Optimize device performance by edge capabilities
  • Monitor and report on the performance and health of devices
  • Simulate and analyze device data to verify features 

Chris the IoT Application Developer 

Chris the application developer, is developing applications and services in a connected product IoT solution based on a cloud service architecture in IBM Cloud that integrates with the IoT Platform.

He develops and tests his components locally and deploys to a team development space in the cloud configured with an IoT Platform using live or simulated device data.

Role

  • Develops cloud applications and services that depend on data and events from the Watson IoT platform
  • Uses IoT platform and database APIs to access device data
  • Delivers new code and fixes in his IBM Cloud space that is staged into production

 

Goals

  • Minimum set up for the new environment
  • Implement data models
  • Connect simulated devices and play with the data
  • Create and test applications, microservices and expose APIs
  • Use client libraries to code productively

Developer Experience Scenarios

The introduction of an IoT development environment involves multiple stages, teams, and team roles.  

  • The buying LOB organization forms a POC team
  • The LOB and IT teams then harden the development environment and start developing, testing, deploying, and maintaining the IoT solutions.
Link
Design Research on IoT Developer Experience
IoT Application Development Lifecycle

We can generalize these into two major scenarios

 

My Personal IoT Developer Experience – Delivering an IoT POC

For Devon and Chris, teaming up to deliver an IoT POC, the developer experience can be described as:

“We are a small group of device and application developers, with various skills on Bluemix, Cloud development and IoT, delivering a connected product POC”

“We need self-served material that gets us started with an IoT development environment to build our skills on IoT devices, IoT applications and an IoT solution that shapes a successful POC outcome in a week”

 

My IoT Solution Developer Experience – Hardening the IoT Development Environment

For the LOB development team, the developer experience can be described as:

“We are a product team transitioning from a POC into a hardened IoT solution cloud development environment, delivering at speed and scale.”

“We need to grow and mature by applying production scale IBM Cloud services and toolchains and leverage our POC IoT starter code and architecture.”

Link
Design Research on IoT Developer Experience
IoT Developer Experience stages for Delivering an IoT POC and Hardening the IoT Development Environment.

Design Vision

Our research guides us on a design vision for a successful developer experience:

  • Guides and supports the developer throughout their journey
  • Provides interactive and viable features over comprehensive documentation
  • Supports mainstream IDE/languages for developers to work in the best-supported manner

Hills

We defined the following hill for the IoT developer:

 

“As a Developer with no prior IoT platform experience, I can within 15 minutes set up a new IoT platform organization and start developing and testing my IoT devices and applications”

Related Designs

Several designs deliver on these hills 


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. Developers can simulate the existing registered devices or whole new devices. The Device Simulator allows developers to customize the schedules and payloads.

Help Hub Design
The Help Hub design provides a simple onboarding experience for new users of the IoT platform. The design creates a seamless learning experience, guiding users and allowing them to form a mental model of the IoT platform and its resources.

 

ChrisDevon

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. Developers can simulate the existing registered devices or whole new devices. The Device Simulator allows developers to customize the schedules and payloads.

Help Hub Design
The Help Hub design provides a simple on-boarding experience for new users of the IoT platform. The design creates a seamless learning experience, guiding users and allowing them to form a mental model of the IoT platform and its resources.

Compliance Reporting Design

, , ,

In 2017 I contributed to the design concepts for Compliance Reporting for Risk and Security Management in the Watson IoT Platform.

What is Risk Management?

Businesses with IoT deployments have the challenge of ensuring that the entire IoT landscape operates within acceptable and expected boundaries. The consequences of IoT devices operating outside of defined criteria, or policies, could have a major impact on the security of the overall IoT deployment, the safe operation of connected devices, and business impact. 

What is a Risk and Security Risk Management Policy?

The Watson IoT Platform allows the configuration of specific policies in relation to connection security. 

Compliance reporting provides dashboard cards and drill-in reports on the policies configured in a Watson IoT Platform organization.  

Personas

Risk and Security Management is primarily targeting two of the IoT personas

  • Sally is an IoT System Operator. She handles the day to day system operations on the LOB and client IoT organization. She makes sure that new device types and devices are registered, are behaving, and are up to date with recent secure firmware. She defines policies, creates and runs actions on policy alerts that act on misbehaving devices.
  • Adam is an IoT Security Operator. He ensures security and compliance by specifying policies that detect abnormalities and prevents devices to be compromised. He reports to audits on compliance with regulations and policy coverage on devices.

Hills

“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”

Use-Cases

As a systems operator, I need to:

    • See the high-level security status of the devices so I can quickly identify potential risks.
    • Drill down from a general view to more specific reports to identify problems
    • Drill into the current state and history of devices to analyze root-cause
    • Download, filter, and sort the report

UX Design

View Policy Compliance from Dashboard

The Watson IoT Platform Risk and Security dashboard provides an instant overview of the current security position and provides drilling to find more compliance-related information.

  1. The dashboard has a collection of cards that can be used to monitor security-related KPIs.
  2. Sally sees that the Connection Security policy has the most violation. She drills down to find out more information. She clicks on Connection Security
  3. The compliance report shows overall compliance with the Connection Security policy and the current compliance for each rule. Sally clicks on a custom rule defined for TemperatureSensor device type to drill down to see all the devices that fail the default policy.
  4. The next report presents a list of devices that fail the rule and the causes of failure.

 

Using the Watson IoT Platform Dashboard to view compliance.

View Policy Compliance from Policies Page

The Policies page in the Security section of the Watson IoT Platform provides an overview of Risk And Security Management policies.

  1. Access the compliance report by clicking the “View Compliance” button.
  2. The compliance report shows overall compliance with the policy and the current compliance for each rule
  3. The next level of drill-down shows all the non-compliant devices that violated the rule. Search/filter/download the report.

 

Using the Watson IoT Platform Security Policy Editor to view compliance.

Final Production Design

Viewing compliance reports using the Dashboard in the Watson IoT Platform.

 

Viewing compliance reports using the Risk And Security Policies in the Watson IoT Platform.

Related Designs


Risk and Security Management Design
The Watson IoT Platform Risk and Security Management provides an overview of compliance on policies and risks so that security administrators and operations personnel can quickly understand the security posture of their IoT deployment according to policies that they have configured within the Platform.

Watson IoT Platform Risk and Security Management Lab. 
DevZone Quick Lab at Think 2018 on Risk and Security Management.

Sally

Meet Sally the IoT System Operator. 

Sally is one of the most frequently used operator personas in the design across the platform capabilities.

Adam

Also meet Adam the IoT Security Operator. 



Risk and Security Management Design. 
Read more about the design of the Watson IoT Platform Risk and Security Management policies.


Watson IoT Platform Risk and Security Management Lab. 
DevZone Quick Lab at Think 2018 on Risk and Security Management.

Design Research on IoT Device Activity

, , , ,

In 2017 I performed design research on device health and activity for compliance policies and reporting in the Watson IoT Platform.

What is Device Activity

Businesses with IoT deployments have the challenge of ensuring that the entire IoT landscape operates within acceptable and expected boundaries. The consequences of IoT devices operating outside of defined criteria, or policies, could have a major impact on the security and operations of the overall IoT deployment.

The Watson IoT Platform allows the configuration of specific policies in relation to connection security. Device Activity is an indicator of device health. A device activity policy defines the expected behavior of devices and monitors for anomalies. This research identifies types of common device behavior and assesses the feasibility of various metrics for such behaviors.

Types of Device Activity

Device Activity events are

  • A device connects to the IoT platform
  • A device disconnects from the IoT platform
  • A device submits a message to the IoT platform
  • A device responds to a command from the IoT platform

 

Device connection events are

  • Devices connecting/disconnecting directly over MQTT
  • Devices connecting/disconnecting directly over HTTP REST calls*
  • Devices connecting/disconnecting through a Gateway*

 

* Only connections over MQTT are managed by the platform with a connection state. HTTP REST API calls do not keep a connection state. A Gateway keeps a connection state for its connection, but devices connected to the platform through the Gateway do not manage their individual connection states.  

Connection Use-Cases

For devices connecting to the platform, we identify four typical kinds of behaviors

  • Online connection mode
  • Low power connection mode
  • Heartbeat connection mode
  • Gateways connection mode

 

For each kind above we assess the feasibility of three device activity metics

  • Time since last connected 
  • Time since the last message 
  • Service level

Online connection mode

The most common connection mode is the continuous online mode. This connection mode applies to devices directly instrumenting equipment to monitor and report on state. Devices continuously perform sensor readiness and send sensor data to the cloud.

Examples of such devices are sensors on the Factory floor, Medical, and Environmental applications. Such devices connect to the cloud and stay continuously connected to transfer new data. When disconnected, for example by a network disruption, the device seeks to re-establish the cloud connection when the network is restored. In summary, 

  • Device types – Sensors for continuous state monitoring. 
  • Device behavior – Online, periodic state events, instant reconnect.

Three metrics can be used to determine device activity and health.

  • Time since last connected 
  • Time since the last message 
  • Service level

The time since the last connected metric does not well capture the device behavior. A well-working device would in an ideal situation have infinite time since last connected, as the device never disconnects. 

The time since the last message is a more meaningful metric. If the network connectivity is lost, messages will not be received by the cloud, hence indicating a device fault. If the device does not store and forward messages, there is a risk that messages will be lost in case the sample interval coincides with a network failure.

A metric of a service level, as the relation of connected time vs time, can be used as a metric of the reliability over time of the device and hence its health. The service level metric will catch reoccurring network failures.

Comparing messaging behavior and metrics for healthy and unhealthy devices that use an online connection mode.

Link
Design Research on IoT Device Activity

Low power connection mode

In applications using battery-powered devices a more conservative power consumption design have to be applied. Devices will be challenged to stay online due to limitations in battery capacity, power consumption, and radio signal strength. Examples are battery-powered devices for Sigfox / LoRa networks. Such devices only connect, send a short state event message, and disconnect. In summary

  • Device types – Sensors for low-energy, low-frequency state monitoring. 
  • Device behavior – Connect, send state event, disconnect.

Three metrics can be used to determine device activity and health.

  • Time since last connected
  • Time since the last message

The time since the last connected metric works well to detect missing messages from devices. Likewise, the time since last message metric is more meaningful. A service level metric is not applicable as the device behavior is mainly to stay disconnected.

Comparing messaging behavior and metrics for healthy and unhealthy devices that use an off-line low power connection mode.

Link
Design Research on IoT Device Activity

Heartbeat connection mode

Devices used for monitoring might be designed to send Alert messages only when some exceptional condition is met. For example, Leak sensors, Panic buttons, Door alarms, Sensors in appliances. To improve reliability, such devices often send heartbeat messages indicating that the device/appliance is healthy. Some devices are designed to be online, others are constrained to conservative power or network use and only connect on-demand to send a heartbeat or an alert. In summary

  • Device types – Leak sensor, Panic button, Door alarms, Appliances
  • Device behavior – Continuous Online / Offline (low power) monitoring and event-based alerts. Edge analytics device.

Three metrics can be used to determine device activity and health.

  • Time since last connected
  • Time since the last message

The time since last connected metric works well for offline device behavior (as above). Time since the last message/heartbeat is more meaningful. A service level metric is not applicable as the device behavior may be to stay disconnected.

Link
Design Research on IoT Device Activity

Gateways

Gateways are network devices that connect a variety of devices to the cloud. Gateways are used in many connection scenarios. For example, connecting devices over a range of protocols, implementing a bridge from the edge to the cloud, or even a bridge across IoT platforms. Gateways may also add messaging capabilities to improve reliability, like storing messages in a buffer if the gateway is disconnected and forwards buffered messages once the gateway reconnects. A gateway both improves device reliability, but also skews metrics on device activity and health. 

A Gateway is a device that connects to the platform. It hence uses the three connection modes discussed above. The most common cause is the online connection mode. The gateway will hence have (be given) a device activity policy that is different from the devices that the gateway acts on behalf of.

Also, as discussed above, a Gateway keeps a connection state for its connection, but devices connected to the platform through the Gateway do not manage their individual connection states. This makes a device’s health metrics based on time since last connected problematic.

A device activity metric based on time since the last message is more valuable as applied to individual devices as well as the gateway itself. Such policies should be set individually for the gateway and the devices that connect through the gateway. Her devices may have a short time interval between messages, others may have longer time intervals, as indicated in the figure below.

Comparing messaging behavior and metrics for healthy and unhealthy devices that connect to the cloud using a gateway.

Link
Design Research on IoT Device Activity

User research 

In our design research, we find the following consensus among our design partners

  • Importance of a Device Activity policy: Very Important
  • Most important device activity to measure: Time since last message
  • Minimum time window set for this policy; Set by type or instance. Minimally 1h time interval.
  • Importance to support devices connecting through a Gateway: Important
  • Most common device behavior: Always connected, periodic messages | disconnected in energy save mode | other protocols

Related Designs


Risk and Security Management Design. 
Read more about the design of the Watson IoT Platform Risk and Security Management policies.

Device Activity Policy Design. 
Read more about the design of the Device Activity Policy design for the Watson IoT Platform Risk and Security Management policies.


Device Activity Policy Design. 
Read more about the design of the Device Activity Policy design for the Watson IoT Platform Risk and Security Management policies.


Risk and Security Management Design. 
Read more about the design of the Watson IoT Platform Risk and Security Management policies.

Design Round-Table – Internet of Things Information Management Design

, , , ,

Abstract

The Watson IoT Platform design puts users first in researching their usage patterns, use cases, and needs. This round-table session will present and discuss the IoT Platform Information Management experience. Share your insights, needs, wants, and requests for managing the information and programming model on devices and things in the IBM Watson Internet of Things Platform!

Interconnect2017-IWT4736

 



Download presentation

Design Round-Table – Internet of Things Risk and Security Design

, , , ,

Abstract

The Watson IoT Platform design puts users first in researching their usage patterns, use cases, and needs. This roundtable session will present and discuss the IoT Platform Risk and Security Management experience. Share your insights, needs, wants, and requests for managing risk and security on devices and things in the IBM Watson Internet of Things Platform!

Interconnect2017-IWT4734

 



Download presentation

Design Round-Table – Internet of Things Platform Design

,

Watson Internet of Things
Design Round-Table – Internet of Things Platform Design
IBM Interconnect 2017 Conference Session IWT-2501
Design Round-Table – Internet of Things Platform Design

Abstract

The IBM Watson Internet of Things design team is continuously researching usage patterns, use- cases and experiences with the Watson IoT Platform. This round table session will present and discuss the IoT Platform capabilities and the design roadmap for 2017. Attendees will share their feedback and experiences with the IoT platform and discuss needs and requests for design enhancements.

Interconnect2017-IWT2501


Download presentation

Load More