In 2015 I delivered design concepts and a user experience design for gateway support in the Watson IoT Platform.
What is a Gateway
An IoT Gateway is an intermediary network device between one or more devices, the internet, and the IoT platform.
Devices comes in many forms and purposes. Some are complex assets with rich capabilities and networking functions. Others have a less to none functions to connect directly to the internet and need an IoT Gateway to translate communication of a non-IP network to an MQTT connection with the IoT platform. In other cases a gateway may act as a bridge between an external IoT platform of devices and the Watson IoT Platform.
A gateway gets involved in the identification, connection and registration of devices, and transferring the data from the devcie to the IoT Platform over the internet if the device is not IP enabled, like a Bluetooth, ZigBee or LPWAN device.
Design Vision
The vision of the design for IoT Getaways is
- A Gateway is a device. It can act as a device and a Gateway. Hence, unify the way types or devices and gateways are defined.
- A Device is a device, regardless of its networking capabilities, connection protocol, or if its directly connected to the IoT platform, or connected though a gateway.
- The design should unify the way devices and gateways are searched, listed and filtered in the IoT Platform UI.
- Devices connecting though a gateway appears as any directly connected devcie in the IoT Platform user interface. The design should use device attributes and icons to visually distinguish devices and gateways in the IoT Platform UI.
- The IoT Platform should simplify the provisioning of managed devices. IoT Gateways may be granted permissions to auto-register its managed devices.
- The IoT platform should simplify device management for managed devices. IoT Gateway should transparently manage device management operations on its managed devices.
User Research
In my research I found three types of connection patterns between a gateway and its managed devices
- Static. Devices are statically associated with one gateway.
- Nomadic. Devices are associated with a gateway for a reasonable period of time. It then stops connecting to that gateway and at some later time it starts connecting to a different gateway and then uses that exclusively for a period. An option might be given to assign new metadata when it reconnects.
- Mobile. A device that moves more rapidly between many different gateways. Metadata, like the associated gateway and location, is changed automatically.
Client report the Static type to be the dominant case, followed by the Nomadic case. The Mobile case is less frequent but may be a more prominent case as roaming volume devices become smarter and establish hotspot connections using local gateways.
Gateway Design Concepts
The IoT Gateway concept design
- An IoT Gateway a new class of device in the APIs
- A new MQTT message payload schema is defined for IoT Gateways
- A consistent UX is design all devices, regardless if connected directly to the platform or managed by a gateway
- A consistent browsing and filtering UX is designed for all devices in the existing single device list in the Devices > Browse section
- Navigation is supported in the UX across a gateway and its managed devices
- Navigation is supported in the UX from a managed device to its connected gateway
- Enhancements to the data model and the device-management protocol
- MQTT connectivity to support gateways
- API changes to support gateways
Hills
- IoT Gateways Hill 1 – Sally, a system operator, can connect a gateway to the IoTF to allow a range of (not so smart) devices to connect to the platform, be administered in the same way as other devices, and allow them to interact with other devices
- Subhill 1 – Sally can set policies which allow a gateway to publish on behalf of devices associated with the gateway
- Subhill 2 – Sally can be sure that each device has a unique identifier that ensure unique connectivity when moving or roaming through any available gateway
- Subhill 3 – Sally can initiate device management actions against a gateway to be performed against it’s associated devices
Use-Cases
As an Operator I need to
- Create a device type for a gateway and set policies
- Register a gateway and attached devices
- View, search and filter gateways
- View, search and filter attached devices
- Perform management actions on a type of devices connected through gateways
- Perform device management actions on a gateway and its attached devices
As a Device Developer I need to
- Find a IoT Recipe that provides docs, libraries and sample on developing a gateway
UX Design
Low resolution design mock-ups below as additions to the existing Devices UX design.
Create a device type for an IoT Gateway
As an Operator I need to
- Create a new device type
- Select a ‘Gateway’ role
- Enter device properties
- Enter gateway policies
- Save the new device type
Register an IoT Gateway and attached devices
As an Operator I need to
- Create a new device using a Gateway device type
- Enter device identity properties
- (Wait for the gateway to connect and publish attached devices)
- Filter on new devices attached to a registered gateway
- Register, or confirm registration, of attached devices
View, search and filter gateways and attached devices
As an Operator I need to
- Open dashboard
- View gateways
- Filter on gateway type or id
- View device information
and perform actions
- View devices
- Add a Gateway column
Filter on device type - View gateway information
- Add a Gateway column
Perform management actions on a type of devices connected through gateways
As an Operator I need to
- Open a view with gateways and devices
- Select a management action from a list of available actions
- Switch to the view to track running actions
- Monitor progress on the actions
Final Production Design
Examples of UX design in the IoT Platform
- Users can query for all devices with Class Id = Gateway. In this organisation we see 4 gateways are connected.
- Opening one of the gateways in Munich we can see all devices that are connected though that gateway.
- Opening a managed devcie we can see the gateway the devcie is connecting though.
- Filter on gateway and the devcie type to see all motion sensors connecting though the Munich Yanzi gateway.
- Another example using the Enocean gateway and its connected sensors
- Looking at the details of one of the Enocean sensors we see the device events and data sent to the IoT Platform.
Performing management actions on a type of devices connected through gateways. [/su_panel]
In 2017 a new Devcie Table design is released. This new design will simplify the query / filter and user access to element information. In the screen below we are selecting all gateways by the Class ID = Gateway filter.
New production design for Devcie Tables in 2017.
Related Designs
The gateway design has enabled other related designs in 2016
- Edge gateways – Edge analytics is based on edge gateways to connect edge devices and run delegated edge rules. The Edge Gateways are using the gateway design to manage gateway types and instances.
- Platform of Platform – External cloud platforms are implementing the Gateway integration to register and connect devices in the external platform to the Watson IoT Platform. The external cloud platform is connected as a gateway and acting as a proxy by routing events and commend across the two platforms.
- Trusted and untrusted gateways – Improvements and restrictions by by applying resource level access control and permissions to gateways limiting capabilities for auto-registration and the devices a gateway can act on behalf of.
Most of our gateways are statically deployed. They are today deployed in lamp posts and traffic lights. There are some case where the gateway is deployed into a bus connecting over GPRS. But not as a mobile case where mobile devices are roaming across multiple gateways. – Watson IoT Platform partner.