How a major manufacturer manages and monitors industrial devices and vehicles with AWS IoT

Introduction

At AWS, we help customers from all industries—from home appliance producers to automakers—effectively manage and monitor their devices at scale. In this blog, I describe a device distribution (selling and reselling) approach commonly used by business owners of IoT device management solutions called “tight coupling,” that the devices have to be customized produced and distributed to certain clients, highlight a few of its drawbacks, and introduce an alternative decoupled approach that unlocks device distribution. Then, I demonstrate how an AWS customer who manufactures industrial devices and vehicles uses the decoupled approach to more effectively manage and monitor vehicles with AWS IoT.

With a vehicle management and monitoring solution built on AWS, customers can quickly connect large fleets of devices, organize them into groups and control access based on group hierarchy, and quickly search for and find any device across their fleet in real time.

Tight coupling process and drawbacks

Today, the way many device manufacturers and device management service providers distribute and resell devices is customized for each of their clients, even when device hardware and firmware are identical. This limits the device maker’s flexibility of device distribution, increases the cost of device reselling, and subsequently can reduce their scope and ROI. Often, these challenges are caused by tight-coupling that the devices have to be customized produced and distributed to certain clients.

In tight-coupling process as below, we will consider a manufacturer of vehicles and devices with distributors and resellers that lease vehicles with GPS sensors and engine locks to the clients.

Figure 1: Tight coupling process between devices and their distributors

First, let’s introduce the three main roles in the tight-coupling process; each role can be users of the device management and monitoring solution outlined in this blog post.

• Clients purchase or rent industrial vehicles with devices such as GPS and engine lock for their own business such as mining and construction. A client might have multiple end users like vehicle drivers and operators of vehicle fleet monitoring and management.
• Distributors and resellers place purchase orders from clients to manufacturers. They collect client-specific information, such as client name and list of sensors connected to client’s device, and ask manufacturers to burn the information into the devices (write the information into firmware of the devices).
• Manufacturers produce industrial vehicles and devices, and burn client-specific information, such as client name and sensor list, into devices. The same type of vehicle is equipped with the same type of sensor, but can carry different types of devices. For example, vehicle type A with GPS sensor and engine lock sensor installed, and client A purchases both GPS and engine lock services and client B orders only GPS service. Then the manufacturer needs to offer 2 types of devices, one type enables GPS and engine sensor for client A and another for client B enables only GPS sensor. Tight-coupling process only impacts devices, not the vehicle directly.

When using the tight coupling process, a manufacturer burns client-specific information, such as different runtime models required by different clients on devices, into a device before rolling them out to market. The process is:

1. The distributor places an order to purchase vehicles with devices, and provides client-specific information, such as client name and a list of sensors connected to the client’s device.
2. The manufacturer initializes the devices according to the client-specific information from the distributor, and supplies them to the distributor.
3. The distributor delivers ordered vehicles and devices to the client (mining). The client assigns vehicles to drivers.
4. The client returns some vehicles because the rental was contract completed or they sold them back to the distributor.
5. The distributor returns devices to the manufacturer, provides specific information for another client, and asks the manufacturer to reinitialize those returned devices.
6. The manufacturer erases returned devices and burns new client information into them, and supplies them to the distributor.
7. The distributor resells or rents those vehicles with devices for another client to the client (construction).

A new approach to decouple devices from distributors

The root cause of the disadvantages of the tight-coupling pattern is static relationship between devices and device distributors, which is usually caused by storing the distributor’s identification information or their clients’ information on the devices. To operate a device management solution, the distributors need to authenticate and track the devices they sold or rented based on the identification information, so the linkage between the devices and the distributors is necessary. However, this linkage does not need to be static, but can be dynamically generated and removable. Dynamic tying and untying can be integrated into the device registration process in a device management platform.

Figure 2: Decoupled process for devices and their distributors

The manufacturer can provide unified devices to distributors. Device distributors can decide what models can be used on the devices they distributed.

In this decoupled approach, there are three modeling concepts we see our customers use: device model, working condition data model, and device control model. These models can be combined and/or separated dynamically to leverage the same devices to deliver different behaviors to device users to improve the adaptability of devices to enable them to support more business scenarios.

• The device model based on the device hardware and firmware is the model closest to a device’s own attributes, such as device outputs and data types of those outputs. For example, output TSW (self-weight of truck carrying cement mixer) is 8000kg, output CMSW (self-weight of cement mixer) is 3000kg and output CW (weight of cement filled into the cement mixer) is 1500kg. Please note, not all outputs from devices can be understood directly by a human, many outputs from device are just a string of numbers and characters, especially in industrial manufacturing.
• The working condition data model is a data model that users of IoT platforms or systems can directly understand. It uses predefined algorithms to transform and calculate the data from the device model, and outputs results. For example, we can get several weight values from the device model, but sometimes only the vehicle bearing ratio, i.e. (CMSW + CW)/(TSW + CMSW + CW)=0.36, has practical significance from business point of view.
• The device control model is the model in which the device management platform issues instructions to the devices to control the operation state of the devices. Usually, it needs to interpret an instruction into a series of operations that can be directly understood and completed by the devices. For example, the device management platform issues an instruction to prohibit start-up of an industrial vehicle, the device control model will decompose the instruction into an operation to lock engine start and another operation to allow the circuit to be turned on. These two operations are commands that can be completed directly by the vehicle.

The selected models are pushed to devices once the devices are registered to the device management solution, and data exchanged between devices and device management solution is determined by these models. Using a decoupled approach, a manufacturer can plan their device production capacity and schedule according to total market demand. They do not have to plan device producing for each distributor. Distributors only need to pay attention to the models that the ordered devices can support, rather than spend time and money reinitializing returned devices.

In the next section, I outline how the device model, working condition data model, and device control model each play a role in a manufacturer’s vehicle management solution. The solution architecture is composed of edge devices (devices installed on vehicles), and the cloud-based device management and monitoring platform used for vehicle fleet management at scale. The local computing capacity of AWS IoT Greengrass software simplifies implementation of the models introduced in this blog, and the scalability of AWS IoT Core ensures the customer does not need to care about peak payload from the edge side.

Use case, challenges, and solution overview

We worked with a global manufacturer of industrial devices and vehicles to implement this decoupled solution. Their vehicle management and monitoring solution is in production in China, Europe, and India, and securely monitors and manages millions of industrial vehicles and devices.

In this use case, the customer first validates their devices with serial numbers. Once the device is started and connected to the internet, it sends a request containing its own serial number to AWS IoT Core. AWS IoT Core verifies the serial number of the device and generates a unique certificate for the device. The device can use this certificate to download the models (device models, working condition data model and device control model) which usually are grouped and managed per device distributor. At this point, the process of model distribution to devices completes.

The models usually contain description files, such as JSON files, which define data structure of the models. In addition to the data structure, the working condition data model also include logic definitions, such as algorithms. The easiest way to implement logic definition in this model is programming. AWS IoT Greengrass’s local Lambda function hosts and completes those logics from this model. AWS IoT Core in the backend pushes the data structure and logic definition in the models to AWS IoT Greengrass software installed in the devices. AWS IoT Greengrass software saves the data structure in the device and the logic definition in local Lambda functions.

Once the model is activated to run, the local Lambda function of AWS IoT Greengrass will follow the data structure in device model to accept data sent by the devices, perform logics defined in working condition data model, and use device control model to breakdown operation instruction issued by device controller, such as device user or admin, to commands the devices can execute.

Edge devices

AWS IoT Greengrass, an IoT open source edge runtime and cloud service that helps you build, deploy, and manage device software, supports the distribution and implementation of the device model, working condition data model and device control model in a device management platform. The devices with AWS IoT Greengrass only need to carry a unified certificate including permissions to register the device in AWS IoT Core.

In the major manufacturer’s solution, a black box is installed on an industrial vehicle, and many sensors are installed on the vehicle and the specific devices the vehicle carries. The data collected by the sensors are centralized on the black box, which transmits the data to a backend vehicle management platform. The platform issues instructions to the black box to control the vehicle and the devices carried by the vehicle, and the black box decomposes the instructions to commands and asks sensors on the vehicle and devices to initiate the commands.

AWS IoT Greengrass software is installed on the black box. Because the black box (G-Box in short) communicates with the sensors through a Controller Area Network (CAN) bus, AWS IoT Greengrass Core does not need to directly communicate with the sensors. The CAN application on the G-Box sends data collected by the sensors to AWS IoT Greengrass Core, and sends commands from the vehicle management platform to sensors. AWS IoT Greengrass Core uses local Lambda functions to operate the device model, working condition data model and device control model, and interacts with AWS IoT Core through MQTT protocol.

Cloud-based device management and monitoring platform

 Figure 3: Vehicle management solution architecture on AWS

As shown in Figure 3, the solution implementation is:

1. Once a G-box on a vehicle is powered on and connected to the internet, the G-box uses AWS IoT Greengrass Core and the built-in unified certificate to connect to AWS IoT Core, and requests to establish an AWS IoT Greengrass group in AWS IoT Core. The vehicle management platform also verifies whether the device serial number is valid. If it is invalid, the request will be rejected. If the serial number is valid, AWS IoT Core will use the serial number as the name of the AWS IoT Greengrass group. Then the AWS IoT Greengrass group sets one-to-one pairing between AWS IoT Greengrass Core and the G-box. The Shadow in AWS IoT Greengrass Core records the state of the G-box, such as storage space utilization, health information, etc. After that, the vehicle management platform will return the certificate specific for the G-Box. The certificate is generated when the AWS IoT Greengrass group is established. From that point on, the G-box will use its specific certificate to interact with the vehicle management platform built on AWS.
2.  The vehicle management platform records the G-Box metadata such as serial number, box type and firmware version in Amazon Relational Database Service (RDS) MySQL. This database also manages all vehicle information such as vehicle configuration and state, G-Box, and the devices carried by the vehicles. Device distributors and clients of the distributors, device models, working condition data models, and device control models used by the clients are stored in this database as well. The major manufacturer is now also assessing Amazon Aurora and Amazon DynamoDB for certain use cases.
3. The vehicle management platform responds to the request to retrieve models from the G-Box. The platform confirms the device model, working condition data model and control model that the G-box needs to use, and includes an Amazon Simple Storage Service (S3) presigned URL in the response for the G-box to download the data structure and logic definition for these models. AWS IoT Greengrass Core downloads these models to the G-Box, and loads data structures and logics to local Lambda functions. The modeling team can be composed of manufacturers, or distributors/resellers, or both of them, and is responsible for building and updating models. When new models are ready to release, the modeling team first uploads the data structure and logic definition to Amazon S3, and then defines the application scope of the models in the Amazon RDS MySQL database. The team operating the vehicle management platform assigns the models to certain distributors, or certain clients of the distributors.
4. After retrieving and loading the models, AWS IoT Greengrass Core on the G-box uses the device model to receive raw data from the CAN application, and, according to the working condition data model, filters and transforms the raw data into the data that can be accepted by the backend system. It then packages the data into JSON files and sends them to the topic of AWS IoT Core dedicated for the G-box. The message in the topic will trigger the AWS IoT Core Rule Engine to filter and accumulate the data. This step is usually used to remove duplicated data and supplement default values for invalid data. The Rule Engine will call an AWS Lambda function to push the data to Apache Kafka. All working condition data of all the devices on all of the vehicles in this vehicle management solution is pushed to Kafka for use by other systems and platforms. The major manufacturer is assessing Amazon Kinesis as a replacement for managed services.
5. The device control in the vehicle management solution is divided into two levels:
   1. The control to the G-box and the control to the vehicle and devices in the vehicle. The state of the G-box is directly synchronized with its shadow in AWS IoT Core; the state change in the shadow will be synchronized to the G-box, and according to the changes the local Lambda functions in AWS IoT Greengrass Core on the G-Box will change its state.
   2. The G-Box communicating with the sensors on devices through CAN bus voids direct communication between AWS IoT Greengrass Core and the sensors. As such, AWS IoT Greengrass Core only needs to interpret the instructions from AWS IoT Core into the commands, which can be recognized by the CAN application according to the device control model.

The instructions are sent by AWS IoT Core via MQTT topics. The interpretation takes place on the G-box side and is completed by AWS IoT Greengrass Core’s local Lambda functions. The CAN application in the G-Box will command the sensors to control the vehicles and their devices, and return the operation results to vehicle management platform.

This vehicle management and monitoring platform provides three main interfaces for open integration: 1/ device control API, 2/ MySQL database to provide customers, models and devices information, 3/ and Kafka to hold working condition data. These interfaces can be used and integrated with a web portal, mobile app, and third-party platforms. Through these interfaces, the data can be presented to vehicle management service providers, vehicle manufacturers and distributors, vehicle owners and users.

Summary

By leveraging the approach introduced in this blog, instead of returning unused devices to a manufacturer, device distributors and resellers can first confirm device behaviors required by clients, then define the most-suitable device behaviors, and finally remotely refresh those definitions if the clients request to change device behaviors. This helps increase device reusability since the device behavior models can be used by the clients with the same requirements for device behavior. By avoiding device returns and removing predefined device ownership, customers benefit by saving costs on device operations and accelerating device distribution.

Get started with AWS IoT by going to the AWS Management Console and navigating to AWS IoT Core and AWS IoT Greengrass.

About the author

Shi Yin is a Senior IoT consultant from AWS Professional Services, based in California. Shi works with many enterprise customers to leverage AWS IoT services to build IoT platforms and connect sensors and devices to those platforms.