Amazon Web Services Feed
How TensorIoT Reduced Delays and the Initial Cost of Deploying Smart City IoT Solutions
By Arlie Moore, Software Engineer at TensorIoT
By Philip Karcher, Software Engineer at TensorIoT
By Nicholas Burden, Senior Technical Evangelist at TensorIoT
By Rohit Rangnekar, Principal IoT Architect at AWS Professional Services
 |
 |
 |
The Internet of Things (IoT) is made up of devices connected to the internet that do not require any human input or interaction to send and receive data over the network. IoT continues to grow and expand as smart technology becomes more involved in our day-to-day life.
One company that has been leveraging IoT devices for decades is Itron Idea Labs. Founded in 1977 by a group of engineers searching for a more efficient way to read meters, Itron Idea Labs was built to enable utilities and cities to better manage their resources by using technology in innovative ways.
Itron Idea Labs has faced two major problems in developing solutions for public sector organizations: project delays, and large up-front costs.
Project delays were caused by third-party device manufacturers taking too long to integrate devices into their on-premises management system. The large up-front costs to provision resources were often due to the lack of easy scaling for their on-premises data centers.
To overcome these challenges, Itron Idea Labs created a new route to integration in the form of the Itron Manhattan Software Developer Kit (SDK).
To take their business to the next level of innovation, Itron Idea Labs teamed up with TensorIoT and AWS Professional Services.
TensorIoT is an AWS Advanced Consulting Partner with AWS Competencies in IoT, Machine Learning, Industrial Software, Retail, and Travel and Hospitality. TensorIoT also has AWS an service validation for AWS IoT Core.
What is the Itron Manhattan SDK?
The Itron Manhattan SDK gives IoT device manufacturers the ability to integrate their devices into the Itron Idea Labs Cloud, communicating with Amazon Web Services (AWS) using both the Lightweight M2M (LwM2M) protocol and AWS IoT Core MQTT protocol.
Itron Manhattan SDK uses the LwM2M protocol for bootstrapping and control commands that interface with AWS IoT Core. For data ingestion, the Itron Manhattan SDK interfaces directly with AWS IoT Core MQTT protocol.
The SDK reduces the time needed for device manufactures to get their product to market, and ensures seamless integration into their cloud management system, thereby solving the time of integration problem.
TensorIoT and AWS Professional Services collaborated to provide Itron Idea Labs with a cloud solution to support the Itron Manhattan SDK. This software solution was the first time LwM2M protocol bridged into AWS IoT Core.
Lightweight M2M Protocol (LwM2M)
The Lightweight M2M (LwM2M) protocol was created by the Open Mobile Alliance standards body, an organization that develops open standards for a variety of industries, but specializes in the mobile phone industry.
The LwM2M protocol was designed for machine-to-machine communications or IoT device management. Devices using this protocol are defined using the IPSO object specification, which identifies the resources the device has and the operations that can be performed on those resources.
How AWS Reduced Up-Front Costs
Previously, new Itron Idea Labs customers had to plan for the estimated number of new devices they would deploy in the future, and provision the system accordingly. This led to high up-front costs and underutilized resources. AWS brought significant value to Itron Idea Labs through economies of scale and pay-as-you-go pricing.
AWS enabled Itron customers to easily scale up their infrastructure at any time. If a customer wanted to begin with a smaller deployment to determine the advantages of using Smart City devices, for example, the AWS approach would be enticing. It keeps startup costs to a minimum, but also leaves the door open to increase the number of devices managed by their system in the future.
This new integration enabled by the Itron Manhattan SDK opens a lot of doors for devices that use the LwM2M protocol and would also like to have their data sent into AWS IoT Core.
The Solution
There are three major components to the system created for Itron Idea Labs:
- Device provisioning and bootstrapping
- Device commands
- Data ingestion
These three major components are key to providing a minimum viable product that Itron can market to their customers.
Device Provisioning and Bootstrapping
Device provisioning involves two primary steps: bulk provisioning and device bootstrap. Provisioning a device occurs over LwM2M, and is responsible for providing MQTT credentials to the device so it can communicate with AWS IoT.
Figure 1 – Bulk provisioning.
First, a list of devices that have been physically installed and ready to communicate is obtained and imported into the platform. The installer signs into the dashboard and uploads a manifest file containing device identifiers such as serial numbers, GPS locations, and other device attributes.
This invokes a provisioning import API to create new AWS IoT certificates, things, policies, and group membership according to the manifest. Certificates are stored securely in Amazon Simple Storage Service (Amazon S3) with individual files for each device; these are the MQTT bootstrap credentials.
Things are created in AWS IoT and additionally represented in a Neo4J graph database. This allows APIs to efficiently find and search for devices and relationships with entities such as tenants, geo-locations, and other device attributes. The device is now ready to connect via LwM2M and start the bootstrap process.
Figure 2 – Bootstrap process.
Next, the device initially connects over LwM2M to the IOWA server and sends a DeviceRegister COAP message. The LwM2M-to-MQTT bridge receives this message and publishes it on a well-known MQTT topic.
An AWS IoT rule registered to a well-known device register topic invokes an AWS Lambda function, which is responsible for obtaining the associated bootstrap credentials from Amazon S3 and returning them to the device over LwM2M. This process occurs via an MQTT publish operation to a well-known response topic.
The LwM2M-to-MQTT bridge is listening on that topic and relays messages to its connected devices. If the device has not been registered on AWS, or if no credentials are found, the DeviceRegister message is ignored.
The device has now completed its bootstrapping process and is in possession of MQTT credentials, which allow direct communication with the AWS IoT Device Gateway via MQTT.
Device Control
IoT devices are controlled through the LwM2M protocol. This device control needed to be integrated into AWS IoT Core, and we did this using Amazon API Gateway, AWS Lambda, Amazon IoT Core MQTT, and the LwM2M bridge.
Figure 3 – Device control. Click to view larger image.
First, a POST request is sent to Amazon API Gateway through the REST protocol. This request is passed to a backend Lambda function, which takes the request and translates it into a custom JSON format the LwM2M IOWA server requires to be passed to the device.
After the Lambda function has this JSON request, it sends it to AWS IoT Core using MQTT on a well-defined topic on which the bridge is always listening. The LwM2M bridge has an internal registry of the devices connected to its corresponding LwM2M IOWA server.
If the target device it sees on the MQTT command topic corresponds to one of the devices connected to its server, it passes the command to the LwM2M server, which is then forwarded to the device. All commands that do not map to one of the devices connected to its LwM2M server are ignored by the bridge.
This system is horizontally scalable and allows for any number of LwM2M bridges and servers to be deployed and takes advantage of AWS IoT Core’s high scalability. Integrating into AWS IoT Core also allows the ability to easily audit all commands sent to the device.
By using AWS IoT rules, any command messages sent over MQTT are pushed to Amazon Kinesis Data Firehose and Amazon S3 for long-term storage and auditing.
Data Ingestion
The IoT devices generate two kinds of data payload. The first type of data is about the device’s state, and the second type of data is alarms that the device generates.
Figure 4 – Data ingestion.
All information that’s sent from the device interacts directly with AWS IoT Core using the MQTT protocol. When this data is sent, it’s sent using the CBOR + SenML specification. This format allows for efficient transfer of the data between the devices and the cloud.
Once the payload is sent to MQTT, it’s picked up by an AWS IoT rule and sent to Kinesis Data Firehose. It buffers these messages and performs a data transformation using Lambda. This data transformation takes the CBOR + SenML payload and translates it into human-readable data that is then inserted into Amazon DynamoDB.
The Lambda function then sends the decoded payload back to Kinesis Data Firehose to be inserted into S3 for long-term storage and auditing.
What is the LwM2M Bridge?
The LwM2M bridge is what allows the solution described in this post to easily scale up and integrate into AWS IoT Core. The LwM2M-to-MQTT bridge acts as a two-way relay for devices communicating over LwM2M/COAP to an IOWA Server and back over MQTT to AWS IoT.
The bridge does not directly communicate with devices, but instead commands the IOWA Server to do so. The bridge is closely integrated with IOWA’s LwM2M WebSocket data interface, which allows it to receive events from IOWA and push commands to LwM2M devices.
On the MQTT interface, the LwM2M bridge acts as an IoT client with elevated permissions to send and receive messages on several well-defined MQTT topics.
The bridge is a novel approach for devices connected over the LwM2M/COAP protocol to be managed, administered, and controlled via AWS IoT MQTT messages. Itron Idea Labs believes this is the first such implementation of its kind and brings in advantages of LwM2M/COAP to AWS IoT that are not natively supported at this point.
Securing the Solution
AWS provides a flexible way to control authentication and authorization on their system. To interact directly with the services, you are required to authenticate and be authorized through AWS Identity and Access Management (IAM) and AWS Security Token Service (STS). However, Amazon API Gateway allows a window into the system for potentially unauthenticated users.
The API developed allowed very powerful commands to be issued, such as capabilities to provision or de-provision devices, view the data payload and device metrics, and send commands to devices.
Security is important to ensure no unauthorized access is given at the API level, and Itron Idea Labs defined three roles given to operators each performing different API operations.
By using Amazon Cognito user pools to define different groups, we were able to give specific IAM roles to each group of users. Itron operators then authenticate against Amazon Cognito to acquire IAM credentials that are passed to Amazon API Gateway during API calls.
Summary
Issues with slow integrations and high up-front costs can have a detrimental impact on a company’s ability to do business with their clients. Itron Idea Labs was able to solve two major problems they had been facing thanks to the benefits of running on AWS.
Overall, the solution created by TensorIoT and AWS Professional Services for Itron Idea Labs was robust and highly scalable. It’s an excellent use case of how leveraging IoT can reap large benefits for modern businesses.
To learn more about how your company can benefit from working with TensorIoT and AWS, set up a demonstration by emailing sales@tensoriot.com.
.
.
TensorIoT – AWS Partner Spotlight
TensorIoT is an AWS IoT Competency Partner that was founded on the instinct that the majority of compute is moving to the edge and all things are becoming smarter.
Contact TensorIoT | Partner Overview
*Already worked with TensorIoT? Rate the Partner
*To review an AWS Partner, you must be a customer that has worked with them directly on a project.