Device Connectivity & Murano IoT-Connectors (Aka Products)
Murano Connectivity functionality provides a centralized control for devices configuration and provisioning. A single connectivity sub-domain is provided per instance of Murano IoT-Connector which usually pairs with a firmware version and a hardware model.
Table of Contents
- Get Started
As is discussed in the Data Flow article, Murano internally represents real-world IoT components as the IoT-Connectors, Applications, and Integrations.
In general, most Murano users want to simply connect a Device to the cloud and start interacting with that Device remotely to create something valuable for end users or for a business process. However, there are many different types of Devices. Each type has a different level of processing/communication/storage capabilities and represents/controls different real-world parameters.
To make “connecting/interacting to a remote Device” a scalable effort for businesses, Murano uses the idea of a Device type (or Device model)—known as a Product—to define how Devices belonging to the IoT-Connector interact. IoT-Connectors, therefore, have multiple Devices associated with them (one IoT-Connector, many Devices). Once the behavior of the general IoT-Connector is defined, it is easy to start “stamping out” thousands of Devices that will interact as required by the IoT-Connector to which they belong. The representation and capabilities in Murano of a given Device are often referred to by the industry as a “Digital Twin,” a “Device Shadow,” or a “Virtual Device.”
Because there are so many different possible IoT-Connectors variants (i.e. ranging from a simple sensor to a very capable gateway - each having varieties of processing, communications, storage, data representation, and control capabilities), each Murano IoT-Connector allows the configuration of its capabilities. Every Device interacts with Murano as defined its IoT-Connector’s configuration of these areas:
- Communications authentication method
- Communications protocol
- Device identities/whitelist pool
- Expected communications behavior
- Expected data schema
- Data & State persistence
- Cloud-assisted processing
- User/Value-Added-Reseller access/control permissions
- Automated external Integrations
It is also often the case that an IoT-Connector will be used to power a variety of End User applications (Applications). For example, a Connected Pump Product may have some specific Pumps that are used in a container truck filling/dispensing application, while other Pumps (belonging to the same IoT-Connector) are used in a maintenance facility fluid transfer application. In Murano, an IoT-Connector is able to be used in a variety of Applications without changes to the underlying Devices – even when the Applications are created and maintained by business partners or customers.
This guide documents the different stages of a device during its time on the Murano platform.
This includes device provisioning, device distribution, customer experience, claiming a device, transferring device ownership, replacing a device, and device end-of-life.
Device Provisioning Process
The Murano platform uses two security methods to authenticate connections. One method uses an automatically generated pre-shared key, and the other method uses client certificates to establish a secure TLS connection. The following sections walk through the process and features of each method.
The pre-shared key process has two methods to add identities and authenticate. Users can make a call that will add an identity, ID=12345, and a user generated key, CIK=40 character hex. This adds a device to the platform and adds the authentication in one effort. The other method is to provide the server an identity, and it will generate a key for authentication. In either case, the pre-shared key will exist on the device in non-volatile memory. The devices uses the key, either user-generated or provided, to write data to the cloud and to read data from it.
In order for Murano to properly process data, it must first understand some information about the type of data it expects from the device. Murano supports three main data types: integer, float, and string. Each resource within a product has what is called an "alias." An alias is the name describing the resource. For instance, a resource with an alias of "temp", and a format of integer will be expecting data to describe it in the following format:
temp=70. The call will be rejected if "temp" is declared equal to a string.
Once a device is provisioned and the data format is defined, the device is prepared for sale to distributors or end users. Murano lets you create a custom API to give access to data and control over a device based on identity. Users can claim their device in a custom application and access the device's data from the custom API. The API uses a Lua scripting environment and gives access to dozens of integrations and core services. These services can be leveraged to allow for maximum flexibility when designing your custom application. After distribution, a device enters standard operating mode. A device will remain this way until deactivation, ideally, but oftentimes devices require maintenance, or debugging, if issues arise.
Use Murano CLI to upload content to the cloud, such as new device firmware, that devices can then access. This capability to update device firmware allows you to change an embedded application after the initial deployment. This lets you fix mistakes, rollout new functionality, and optimize device performance. How to update firmware varies from device to device. Murano provides a flexible platform for providing access to the needed files for your embedded application.
Customers should be able to simply plug in their device and then access the needed functionality from the custom application. Because the key has been pre-shared, and because the device has authenticated, the customer can simply register with your application. They will then have access to the data and can control the device from the cloud. Murano has been designed to be simple and easy for the end users of your device.
Q: Is Murano's Device Connectivity compatible with One Platform?
A: Yes, the OneP api protocol is fully supported in Murano connectivity. See The Device Http API Reference for more details. As requirement your device MUST support TLS encryption with SNI support.
Q: How is Murano's Device Connectivity different than One Platform?
*A: The following high-level features highlight some of the many improvements:
- Using TLS client certificates for authentication support the use of hardware crypto modules, providing an additional layer of security.
- MQTT protocol support
- File uploading cabability
- Logging and debugging features like the ability to see the last device IP address, and a UI that has been written with the device developer in mind.
- Sub-second time resolution. A frequently requested feature for One Platform was the ability to write multiple values within a second. The new Murano device gateway supports this.
- A user interface for content/firmware management for connected devices.*
Now what do you want to do?