In our initial internet of things (IoT) opening post, we said that many of the existing IoT solutions shared a common architecture. This post looks at the challenges in using one of those pieces of the architecture – the ease of use of an “off-shelf” cloud compute platform.
The essentials of an IoT system comprise of a few basic epics/user stories:
- As a system owner, I want to be able to give my individual IoT endpoints their own unique identities so I can discriminate between them.
- As a system owner, I want to be able to secure & restrict access to my IoT system to the endpoints that belong to me (and vice-versa).
- As a system owner, I want to be able to define both individual and bulk policies for what IoT endpoints are allowed to do with their data when they connect.
- As a system owner, I want to be able to define on both an individual and bulk basis what actions are to be taken as a result of IoT endpoint data transactions.
- As a system owner, I want to be able to remotely “maintain” all of my IoT endpoints in terms of configurations and software versions.
In this initial approach to the AWS IoT platform, I concentrated on topics 1-3 and left aside the practical deployment issues for the present.
In summary, I would say that I like the Amazon approach to addressing these issues, as in a way they are the table stakes, with the main IoT value creation around what is being measured/monitored and how the data obtained is being intelligently used and combined to provide benefits.
My experience of the Amazon IoT system has focused on the IoT SDK and backend, specifically the python and embedded C versions and trialling the basic data publish/subscription over MQTT. In terms of positives & negatives:
- No special setup required to start using AWS IoT, provided you already have an AWS account. It is also free to use (at present), provided you don’t go crazy and start using millions of messages per month.
- Good initial impression of the documentation & code samples, but this soured slightly over time as a LOT of the examples & setup are tailored for the AWS IoT button as opposed to e.g. linux desktop for doing a quick test drive.
- Bit of confusion over which “C” SDK to use for the desktop test drive. It seems it should be a separate download of linux_mqttmbedtls2.1.1.tar, which is a shame as I only found this out after downloading the embedded C SDK and discovering it within the readme file.
- Very easy to “create” a new IoT device as well as certificates and keys to associate with the device to enable authenticated access to system.
- Less great in terms of specifying precisely what to use in the header files for the code samples for the device ID and access points for pub/sub testing versus e.g. long identity string for the device shadow.
- Not too well explained IoT policy concept i.e. [3] in the user stories. It is absolutely mandatory to create one of these and associate it with the certificate in order even to get connected to the IoT server.
- IoT policies are poorly documented. I had to create a very permissive policy to enable the basic publish and subscribe examples to work: with ANY of my devices I can connect / publish/ subscribe to anything.
- Calling out on the policies:
- The documentation on identifying *which* specific IoT node in the policy is somewhat lacking. I am not able to make restrictions adequately without affecting something else.
- Also the documentation on *what/where* the IoT device can publish/subscribe to is also lacking. There needs to be a better definition of the vocabulary & syntax for the policy statement.
AWS IoT console
Other than these initial problems, probably due as much to my own specific knowledge base, the AWS offering looks good in terms of getting started fast and providing the basic plumbing for an IoT system. Ian Massingham gave a good presentation on AWS IoT at Hardware pioneers in October.
Naturally AWS are looking to monetise IoT through use of their other cloud assets, storage, processing, machine learning and it will be interesting to compare in another blog against Windows Azure IoT which requires a chargeable server reservation for the right to use IoT.
Jan 2017 – update
I can now take back some of what I said earlier about the difficulty of finding the allowable policy definitions for IoT devices interacting with AWS’s backend. They were there in the documentation if you looked for them.
Excluding the “shadow” (Amazon’s virtual copy of the IoT device to use when e2e connections are broken), there are 4 fundamental actions and 3 different types of resource to query the action against.
|
Action |
Resource query |
| Iot: Connect (enable basic connection from iot device to backend) | Client ID ARN e.g. to enable iot device “clientid1” to connect.
arn:aws:iot:us-east-1:123456789012:client/clientid1
|
| Iot: Receive (permission checked for messages to be sent to the device, essential to enable subscription) | Topic ID ARN e.g. for receiving from foo/bar
arn:aws:iot:us-east-1:123456789012:topic/foo/bar
|
| Iot: Publish (enables the device to send data to a topic, and/or filter allowable topics) | Topic ID ARN e.g. for publishing to foo/bar
arn:aws:iot:us-east-1:123456789012:topic/foo/bar |
| Iot: Subscribe (restricts allowable topics for iot devices to subscribe to) | Topic filter ID ARN e.g. for subscribing to foo/bar
arn:aws:iot:us-east-1:123456789012:topicfilter/foo/bar |
In summary of the policies:
- We can restrict connections according to the IoT device ID.
- We can prevent messages being sent to the IoT device(s) or limit them to certain topic groups.
- In a combined policy statement with connect, we can limit the IoT devices able to receive messages from certain topic groups.
- We can limit the topics where IoT devices are able to publish to.
- In a combined policy with connect, we can link the device id-topic pair publishing combination e.g. a destination specific to each client.
- Ditto for subscriptions.
And there seem to be plenty more policy resource query variations in the documentation available using “variables” for some more advanced use cases.