Today I will build on top of my previous post - the concept of a digital twin.
I will explain how to:
- represent a physical device (like a temperature sensor) in AWS IoT Thing Registry
- manage the metadata of IoT Devices in a consistent and scalable way
- organize IoT Devices in Logical Groups (for instance to efficiently manage all IoT Devices attached to the same piece of factory equipment)
- create the x509 Certificate and attach it to the IoT Thing as a proof of an identity
After reading this post, you will understand the core concepts of the AWS IoT Thing Registry. In my next post, we will leverage this knowledge to connect the IoT Device to the AWS IoT Core via MQTT.
Video
AWS IoT Core
IoT Core is the main AWS service related to the Internet of Things (IoT).
To represent our physical IoT Device (Temp Sensor) in AWS, we need to create an IoT Thing.
The IoT Thing is a virtual representation of a physical device or logical entity (for instance an application).
To organize our Thing Registry we will create a dedicated Thing Type to describe our Temp Sensor.
Thing Type ensures that all IoT Things of this type have a common set of attributes (metadata). That is crucial to effectively manage a huge fleet of IoT Devices.
In our simulated factory, we have many virtual Temp Sensors described by similar metadata:
- serial number
- vendor
- range of measured values
Thing Type
We will create a dedicated Thing Type to make sure that all Temp Sensors are described by the same set of attributes.
Thing Attributes represent the metadata we want to store for every IoT Thing of this Thing Type.
The same Thing Type can be used to define multiple devices on the production line.
We will ignore Tags this time; resource tagging is a very important topic that I will cover in the future. For now, let’s focus on IoT Things.
IoT Thing
We are ready to create our first IoT Thing (a virtual representation of a physical Temp Sensor).
Let’s use the create a single thing option.
We need to give our IoT Thing a unique Name.
Thing Type is optional, but it is a good design practice to use it.
Fill metadata for this IoT Thing. Attribute keys are already populated from the Thing Type. You can add extra metadata attributes if that is needed for a specific device.
Thing Group
Let’s imagine that a maintenance window is scheduled for specific factory equipment. During that time, the firmware of all related IoT Devices must be upgraded.
In that factory, we monitor tens of machines using hundreds of sensors. How can we find all IoT Things representing the IoT Devices related to specific equipment under maintenance?
To efficiently manage a huge fleet of IoT Devices and prepare our deployment to meet the above requirement, we should use the Thing Group.
Thing Group allows managing several IoT Things at once by joining them into a logical group.
We could create a dedicated Thing Group for every piece of factory equipment and add all IoT Things connected to specific equipment into the appropriate group.
Then we could start an IoT Job to upgrade the firmware of all IoT Devices in Thing Group corresponding to the factory equipment under maintenance.
I will cover IoT Device maintenance and IoT Jobs in the future - I hope that you have a high-level understanding of the concept of Thing Groups.
For simplicity, I will not assign our IoT Thing to the Thing Group.
Certificate
The x509 Certificate is a proof of identity of an IoT Device.
IoT Device use the Private Key and associated Certificate to identify itself during connection to the AWS IoT Core.
For demonstration purposes, I will create a Certificate for IoT Thing using the one-click option.
⚠️That approach is not recommended for production deployments - I will cover production-ready device deployment in the future.
AWS IoT Core will create credentials for our IoT Thing.
Download for future use (I’ll describe details in my next post):
- private key
- certificate and public key (associated with the above private key)
Activate certificate - when you create a certificate, it is in the Inactive state; you need to activate it so the corresponding device can use it to connect to the AWS IoT Core.
Download the root CA certificate - IoT Device should use this certificate to verify if it is connecting to a legitimate AWS IoT endpoint.
Click Done on AWS IoT console (we will attach the Policy in my next post, where I cover the connectivity between IoT Device and AWS IoT Core).
IoT Thing review
We registered an IoT Thing named TempSensor1 uniquely identified by the Amazon Resource Name (ARN).
💡Note: ARN uniquely identifies every AWS resource, not only IoT Things.
Our IoT Thing is described by the Thing Type (TempSensor), which defines its Attributes (Metadata).
The identity of our IoT Thing is proven by the x509 Certificate attached to it:
Click on this certificate to review details.
Certificate review
We used one-click certificate creation so our certificate was issued by the Amazon Web Services.
It has a default Common Name (CN): AWS IoT Certificate.
This certificate is valid for 29 years - that is fine for PoC but for production deployment you should use short expiration date and implement certificate rotation policy (I will cover that in one of my future posts).
We can verify that the Certificate is attached to our IoT Thing.
It is possible to attach the same Certificate to multiple IoT Things, but that is not a good security practice ⚠️.
Let’s say that we attached the same Certificate to 1000 IoT Things and one of those Things got compromised. The recommended response to that incident is to Revoke the Certificate attached to the compromised Thing. But we can not do that because that would impact another 999 valid IoT Things.
💡Please remember: Certificate is a proof of identity of an IoT Thing - you should always use a dedicated Certificate for every IoT Thing.
Currently, we do not have any Policies attached to our Certificate. I will cover Policies in my next post.
Summary
Next topic
In my next post, I will cover how to connect the IoT Device (represented by IoT Thing) to the AWS IoT Core in a secure way.
