srv408 deep dive on aws iot

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Daniel Austin, Principal Solutions Architect

April 19, 2017

Deep Dive on AWS IoT Shadows, Rules, and More

AWS IoT

Data storage & analytics

Administration

Sensors

Actuators

Connected Farm

Control automation

Agenda

• Introduction to AWS IoT • Telemetry & analytics • Cloud control • Mobile control • Lifecycle management • Wrap up • Appendix: Managing software updates

AWS IoT

DEVICE SDK Set of client libraries to

connect, authenticate and exchange messages

DEVICE GATEWAY Communicate with devices via

MQTT and HTTP

AUTHENTICATION AUTHORIZATION

Secure with mutual authentication and encryption

RULES ENGINE Transform messages based on rules and

route to AWS services

AWS services - - - - -

3P services

DEVICE SHADOW Persistent thing state

during intermittent connections

APPLICATIONS

AWS IoT API

DEVICE REGISTRY Identity and management of

your things

Key takeaways

• Messaging • Be careful with wide fan out • No message ordering guarantees • Avoid large fan in • WebSockets for Cognito authentication

• Rules • Send data to multiple data stores at the same time • Manage device lifecycle events

• Shadows • Designed for the real world: poor connectivity, out of order messages • Fine-grained control over software rollouts • Not ideal for storing time-series analytics data

• Security • One cert per device • Set fine-grained permissions for devices and Cognito users • Naming conventions can simplify policy management

Telemetry & Analytics

Administration Actuators

Control automation

AWS IoT


Sensors

Connected Farm

AWS IoT Telemetry & Analytics

1. Connect devices 2. Send data 3. Collect & store the data 4. Do something with the data

AWS IoT Telemetry & Analytics


MQTT and HTTP






3P Services

1) Connect the devices

1. Provision a certificate

2. Attach policy

3. Connect over MQTT

2) Send data

PUBLISH macdonald/sensors/123 (qos: 0)

{

"timestamp": "2016-01-29T10:00:00",

"temperature": 55

"humidity": 39,

"ph": 6.7

}

3) Collect the data

AWS IoT Data storage & analytics

Sensors ?

Single consumer (don’t do this)

AWS IoT instance database

PUBLISH sensors/123

PUBLISH sensors/456

SUBSCRIBE sensors/+

PUBLISH sensors/789

Don’t do this: scalability

AWS IoT instance

SUBSCRIBE #

Don’t do this: availability

AWS IoT instance

Don’t do this: maintainability

AWS IoT

Store it in the device shadow (don’t do this)

Sensors

DEVICE SHADOWS

1. AWS Services (Direct Integration)

Rules Engine

Actions

AWS IoT Rules Engine

Lambda SNS SQS

S3 Amazon Kinesis DynamoDB RDS

Amazon Redshift

Amazon Glacier

EC2

3. External Endpoints (via Lambda and SNS)

Rules Engine connects AWS IoT to external endpoints and AWS services.

2. Rest of AWS (via Amazon Kinesis, Lambda, S3, and more)

Example rule { "rule": { "sql": "SELECT * AS message FROM 'sensors/#'", "description": "Store all sensor data into dynamodb and firehose", "actions": [{ "dynamoDB": { "tableName": "sensor_data", "roleArn": "arn:aws:iam::123456789012:role/aws_iot_dynamoDB", "hashKeyField": "sensor_id", "hashKeyValue": "${topic(2)}", "rangeKeyField": "timestamp“ "rangeKeyValue": "${timestamp()}", } }, { "firehose": { "roleArn": "arn:aws:iam::123456789012:role/aws_iot_firehose", "deliveryStreamName": "my_firehose_stream" } }] } }

Different Data Scenarios

Want to run a lot of queries constantly? Use Amazon Kinesis Firehose to write into Amazon Redshift Need fast lookups, e.g. in Rules or Lambda functions? Write into DynamoDB, add indexes if necessary Have a need for heavy queries but not always-on? Use Firehose & S3, process with Amazon EMR.

Takeaways

• Avoid single “firehose” MQTT consumer architecture

• Rules scalably route data into the rest of AWS

• Fork data into multiple data stores simultaneously

• Avoid the device shadow for analytics

Cloud Control

Administration

AWS IoT


Sensors

Connected Farm

Actuators

Control automation

Automated Sprinkler Service

Amazon Kinesis

Amazon Machine Learning

Amazon Redshift

Rules Engine

Device Gateway

Sensor

Sprinkler

Amazon Kinesis– enabled app

Talking back to the sprinklers

Amazon Kinesis

Amazon Machine Learning

Amazon Redshift

Rules Engine

Sensor

Device Gateway

Sprinkler

Amazon Kinesis– enabled app

Publish on/off to the sprinkler (don’t do this)

Device Gateway

Sprinkler Control

logic

SUBSCRIBE macdonald/sprinkler-456

Publish on/off to the sprinkler (don’t do this)

Device Gateway

Sprinkler Control

logic

PUBLISH macdonald/sprinkler-456 { "water": "on" }

Direct publishing: why not?

Device Gateway

Sprinkler (offline) Control

logic

PUBLISH macdonald/sprinkler-456 { "water": "on" }


Sprinkler

Control logic

on

off

Device Gateway

off

on


• Messages aren’t ordered

• Connection blips

So then what?

Device Shadows

Shadow State

Apps

offline

Device Shadows

Device Controller

reported state

desired state

Device Shadows

Device Controller

reported state

desired state

HTTP/REST WebSockets

MQTT

AWS IoT Shadow - Simple Yet Powerful

{ "state" : { “desired" : { "lights": { "color": "RED" }, "engine" : "ON" }, "reported" : { "lights" : { "color": "GREEN" }, "engine" : "ON" }, "delta" : { "lights" : { "color": "RED" } } }, "version" : 10

}

Thing

Report its current state to one or multiple shadows Retrieve its desired state from shadow

Mobile App

Set the desired state of a device Get the last reported state of the device Delete the shadow

Shadow

Shadow reports delta, desired and reported states along with metadata and version

Device Shadows and versioning

Sprinkler

Control logic

on (version=1)

off (version=2)

Device Gateway

off (version=2)

on (version=1)

(old message ignored by device)

Takeaways

• Plan for devices losing connectivity

• Send devices commands through shadows

• Query device state through shadows

• Version numbers control concurrency

Mobile Control


Sensors

Talking back to the sprinklers: manual override

Control automation

AWS IoT


AWS IoT



APPLICATIONS

Using Cognito with IoT



APPLICATIONS

AMAZON COGNITO PERMISSIONS APIs

Configure device and Cognito User permissions

end-user (farmer)

end-user (farmer)

Using Cognito with IoT



APPLICATIONS

AMAZON COGNITO PERMISSIONS APIs

Configure device and Cognito User permissions

Policy for Cognito with IoT

Cognito identity pool policy: { "Effect": "Allow", "Action": "iot:UpdateThingShadow", "Resource": "*" } Specific policy for Old Macdonald Cognito user: { "Effect": "Allow", "Action": "iot:UpdateThingShadow", "Resource": "arn:aws:iot:…:thing/macdonald-sprinkler123" }

Overall Cognito “pairing” workflow

1. Create a Cognito identity pool 2. Customer signs in using mobile app 3. Associate their user with their “farm” 4. Create a scope-down policy in IoT for their user 5. Attach that policy to their Cognito user in IoT

Managing fine-grained permissions

• One “farm owner” needs permissions to many shadows • "arn:aws:iot:…:thing/sprinkler123abc" • "arn:aws:iot:…:thing/sprinkler456def" • …

• Listing each is tedious

Best practice: Thing name prefixing

• Prefix thing name with logical owner • sensor123abc -> macdonald-sensor123abc

• Aspen policy supports wildcards

• "arn:aws:iot:…:thing/sensor123abc"

• "arn:aws:iot:…:thing/sensor123abc"

• "arn:aws:iot:…:thing/sensor456def"

• …

• "arn:aws:iot:…:thing/macdonald-*"

Takeaways: Cognito authorization

• Cognito enables secure human control over IoT devices

• IoT scope-down policy supports fine-grained control

• Naming conventions simplify policy management

Lifecycle Management

Actuators


Device lifecycle management

Control automation

AWS IoT

Sensors

Maintenance

1

Lifecycle workflow

Notify operator

1

Connected Disconnected Still disconnected?

AWS IoT Rules Engine & Amazon SNS

Push Notifications Apple APNS Endpoint, Google GCM Endpoint, Amazon ADM Endpoint, Windows WNS Amazon SNS -> HTTP Endpoint (or SMS or email) Call HTTP based 3rd party endpoints through SNS with subscription and retry support

SNS

2

Detecting disconnects

Disconnected Connected

Graceful disconnect

Crash

Back online

Lifecycle events

• Connect • PUBLISH lifecycle/sensor-123

{"status": "online"}

• Disconnect (graceful) • PUBLISH lifecycle/sensor-123

{"status": "offline"}

• Disconnect (crash) • PUBLISH lifecycle/sensor-123

{"status": "offline", "isCrash": true}

AWS IoT Rules Engine’s Flexibility

SELECT *, clientId() as MQTTClientId FROM 'one/rule' WHERE startsWith(topic(2), 'IME33') AND (state = 'INIT' OR hydro_temp > surface_temp)", "actions": [{ "republish": { "topic": "controllers/${substring(topic(3), 3, 5)}", }]

Handling lifecycle events

SELECT

status,

topic(2) as deviceId,

timestamp() as time,

isCrash

FROM lifecycle/#

WHERE status='offline'

- Look up mobile push ID for device owner - Send SNS mobile push

AWS Lambda Function

Delayed lifecycle events

SELECT

status,

topic(2) as deviceId,

timestamp() as time,

isCrash

FROM lifecycle/#

Device Status Time sensor-123 connected 11:30 …

- Double-check the status in DynamoDB - Send SNS push notification if still offline

- Store update device status in DynamoDB - If offline: enqueue an SQS message with

DelaySeconds

AWS Lambda Function

SQS Message (15 minutes later)

Amazon DynamoDB

Generating lifecycle events

• Connect • PUBLISH lifecycle/sensor-123

{"status": "online"}

• Disconnect (graceful) • PUBLISH lifecycle/sensor-123

{"status": "offline"}

• Disconnect (crash) • PUBLISH lifecycle/sensor-123

{"status": "offline", "isCrash": true}

Lifecycle events: connecting

1. CONNECT 2. PUBLISH lifecycle/sensor-123 {"state": "online"}

Lifecycle events: disconnecting

1. PUBLISH lifecycle/sensor-123 {“state”: “offline”} 2. DISCONNECT

Last Will and Testament

CONNECT message parts:

Protocol: MQTT 3.1.1

ClientId: abc

KeepAlive: 60 seconds

LastWill PUBLISH message:

Topic: foo/bar

QoS: 1

Payload: {"foo": "bar"}

Lifecycle events: connecting

1. CONNECT with LWT: PUBLISH lifecycle/sensor-123

{“crash”: true, “state”: “offline”}

2. PUBLISH lifecycle/sensor-123 {“state”:”online”}

Lifecycle events: simplified

• Automatic lifecycle PUBLISH messages PUBLISH $aws/events/presence/connected/abc123

{

"ClientId": "abc123",

"Principal": "arn:aws:...",

"Timestamp": "2016-01-31T11:30",

"Status": "disconnected",

“GracefulDisconnect": true

}

Takeaways: lifecycle management

• Publish messages, use LWT for lifecycle events

• SQS delayed messages and DynamoDB can reduce false positives

• Automatic lifecycle events

Wrap-up

AWS IoT


Administration

Sensors

Actuators

Connected Farm

Control automation

AWS IoT

DEVICE SDK Set of client libraries to

connect, authenticate, and exchange messages


MQTT and HTTP






3P services



APPLICATIONS

AWS IoT API

DEVICE REGISTRY Identity and management of

your things

Key takeaways

• Messaging • Be careful with wide fan out • No message ordering guarantees • Avoid large fan-in • WebSockets for Cognito authentication

• Rules • Send data to multiple data stores at the same time • Manage device lifecycle events

• Shadows • Designed for the real world: poor connectivity, out of order messages • Fine-grained control over software rollouts • Not ideal for storing time-series analytics data

• Security • One cert per device • Set fine-grained permissions for devices and Cognito users • Naming conventions can simplify policy management

Thank you! Kudos to Brett Frantzis, Olewale Oladehin,

and especially David Yanacek!

Appendix: Managing Software Updates


Managing software updates

Control automation

AWS IoT


Sensors

Firmware topic (don’t do this)

• Have all devices subscribe to a topic • Publish updated binaries to this topic

SUBSCRIBE sensor/firmware



PUBLISH sensor/firmware 01100100 01101111 00100000 01101110 01101111 01110100 00100000 01100100 01101111 00100000 01110100 01101000 01101001 01110011

Firmware topic (don’t do this)

Pros: • Sending an update is easy

Cons: • Large messages not supported • Offline devices miss updates • No control over rollout

Firmware version shadow (don’t do this)

• One thing shadow for the current firmware version • All devices subscribe to shadow updates • Messages include a CloudFront download URL

SUBSCRIBE $aws/shadow/firmware-thing

PUBLISH $aws/shadow/firmware-thing { "desired": { "version": “123.45" "url": “https://abc123.cloudfront.net/newversion" } }

SUBSCRIBE $aws/shadow/firmware-thing

Firmware version shadow (don’t do this)

Pros: • Sending an update is easy • Offline devices eventually see updates • Bulk download happens through CloudFront

Cons: • No control over rollout • Shadow protocol is chatty

Firmware in device shadows

• Set each device’s shadow to its desired firmware version • Devices subscribe to their own shadow • Messages include a CloudFront download URL


SUBSCRIBE $aws/shadow/sensor-abc123

PUBLISH $aws/shadow/sensor-abc123 { "desired": { "version": “123.45" "url": "https://abc123.cloudfront.net/newversion" } }

SUBSCRIBE $aws/shadow/sensor-def456

PUBLISH $aws/shadow/sensor-def456 { "desired": { "version": “123.45" "url": "https://abc123.cloudfront.net/newversion" } }


Pros: • Full control over rollout / rollback • Offline devices eventually see updates • Bulk download happens through CloudFront

Cons: • Sending updates requires sending multiple messages

Takeaway

• Be careful with wide fan out to millions of devices

• Wide fan out is supported, but slow

• Encourage safe device management

srv408 deep dive on aws iot

Technology