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
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.
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.
Related Designs
IoT Platform Developer ExperienceDesign research on the developer experience in the Watson IoT Platform.
Getting Started with Simulated DevicesDevZone 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.”
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 ExperienceDesign research on the developer experience in the Watson IoT Platform.
Getting Started with Simulated DevicesDevZone Quick Lab at Think 2018 on Simulated Devices.