AWS IoT and Serverless
•Download as PPTX, PDF•
8 likes•1,549 views
Introduction to AWS IoT and how Serverless computing and IoT are made for each other. Reference architecture of connected car platform discussed here.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS IoT and Serverless
Similar to AWS IoT and Serverless (20)
Recently uploaded
Recently uploaded (20)
AWS IoT and Serverless
- 1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Twitter: @madhushekar23 Linkedin: /in/madhusudanshekar IoT Serverless Madhusudan Shekar
- 4. SONOS Trueplay: Smart Speaker Tuning Trueplay measures the acoustics in any room and fine- tunes your speaker Launched in 2015 yet available to devices purchased over 5 years ago Data-driven evaluation and testing
- 5. Cloud-connected devices are constantly smarter « A 10 year old product can do things that hadn't been invented 10 years ago. Most importantly, going forward, people will expect your product to improve, and if it isn't being updated and getting better, you're literally being left behind. »
- 6. Philips HealthSuite stores 15PB of patient data Data gathered from 390 million imaging studies, medical records and patient device inputs Provide doctors overview of long- term patient behavior and symptoms instead of momentary snapshots Philips HealthSuite – Improving patient relationship
- 7. Improve operational efficiency and patient safety in hospital pharmacies RFID tags attached to medical vials to check contents and age of medications in kits Uses AWS to manage information on more than 6 million tagged drugs Kitcheck - Improving patient safety
- 8. Stream, analyze, store and share data collected by 200,000 telematically-enabled machines Provide growers timely and accurate data for optimal growing conditions Help farmers plant more efficiently and improve crop yields John Deere – Plant and grow more efficiently
- 9. BMW – Make the car the sensor! Connected-car application collects sensor data from BMW 7-series Built Car-as-a-sensor (CARASSO) in only 6 months Provide dynamically updated map information
- 10. TATA Motors – Intelligent Fleet management Collects sensor information and monitors truck fleets via AWS Data allows to route fleets more effectively Predict engine failures or mechanical problems and pre- emptively send trucks to repair centers
- 11. “Securely connect billions of devices to AWS and interact with applications, other devices and the AWS platform” AWS IoT
- 12. Serverless
- 13. Going Serverless… Code is all you need Event driven scaling Never pay for idle Availability and fault tolerance built in
- 14. AWS Serverless offerings And more !! Lambda DynamoDB S3 Kinesis
- 15. How Lambda works S3 event notifications DynamoDB Streams Kinesis events Cognito events SNS events Custom events CloudTrail events LambdaDynamoDB Kinesis S3 Any custom Redshift SNS CloudWatch events
- 16. How does a Lambda function looks like? def hello(event, context): return { "message": ”Hello World!", "event": event } 'use strict'; handlermodule.exports.hello = (event, context, cb) => cb(null, { message: ’Hello World!', event } );
- 17. AWS IoT
- 18. Registry Establishes an identity for devices and manages metadata such as the devices’ attributes and capabilities Rules and Actions Match patterns and take actions to send data to other AWS services or republish Shadows Apps and devices can access “RESTful” Shadow (Thing’s State) that is in sync with the device {Thing Name, Sensor Temp, , GetTemp(), Output LED} Rules Engine Shadow Registry Amazon S3, AWS Lambda, Kinesis DynamoDB SNS Elasticsearch Machine Learning Mobile App AWS IoT: Key features
- 19. Secure by Default Connect securely via X509 Certs and TLS v1.2 Client Mutual Auth Multi-protocol Message Gateway Millions of devices and apps can connect over MQTT or HTTP or WebSockets. Elastic Pub Sub Broker Go from 1 to 1-billion long-lived connections with zero provisioning Subscribers Publishers AWS IoT: Key features
- 20. DEVICE SDK Set of client libraries to connect, authenticate and exchange messages DEVICE GATEWAY Communicate with devices via MQTT and HTTP AUTHENTICATION Secure with mutual authentication and encryption RULES ENGINE Transform messages based on rules and route to AWS Services AWS Services - - - - - 3P Services SHADOW Persistent thing state during intermittent connections APPLICATIONS AWS IoT API REGISTRY Identity and Management of your things AWS IoT Platform
- 21. Demo Time Lets Sync a Light Bulb
- 22. Light bulb explained Amazon Cognito AWS IoTIoT shadow MQTT
- 23. IoT with AWS
- 24. IoT with AWS IoT Endpoints IoT Edge IoT Cloud Enterprise Applications Thing s Thing s Thing s Deviceshadow Deviceshadow Greengrass Lambda Functions Deviceshadow Local Comms Edge Users Long-range Comms Device shadow Rules Engine AWS IoT service IoT Users AWS Lambda Amazon Kinesis Amazon DynamoDB AWS Amazon Machine Learning Amazon Redshift IoT Analytics Big Data, Machine Learning, & Integration Real-time viewCorrelationAnalysisArchive Enterprise Users Corp Apps Corp Data Center MQT T MQT T MQT T MQT T MQT T MQT T IoT Partners Operating systems Consulting Wireless operator OEM ISVsSilicon
- 25. Cloud Moving to the Edge Devices
- 26. Local actions Local Lambda Functions Security AWS-grade security Local triggers Local Message Broker Data and state sync Local Device Shadows Features AWS Greengrass
- 27. Respond quickly to local events Operate offline Simplified device programming Reduce the cost of IoT applications AWS-grade security Benefits AWS Greengrass
- 28. Greengrass components Greengrass is software, not hardware (you bring your own) 2 components that work together: • Greengrass Core • IoT Device SDK
- 29. AWS Greengrass Core (GGC) The runtime responsible for Lambda execution, messaging, device shadows, security, and for interacting directly with the cloud
- 30. AWS Greengrass Core (GGC) • Min single-core 1 GHz • Min 128 MB RAM • x86 and ARM • Linux (Ubuntu orAmazon) • The sky is the limit
- 31. IoT device SDK Any device that uses the IoT device SDK can be configured to interact with AWS Greengrass core via the local network Devices can be small or big Starts with the IoT device SDK forC++, more coming soon
- 32. Devices work together locally An AWS Greengrass group is a set of cores and other devices configured to communicate with one another
- 33. Devices work together with the cloud AWS Greengrass works with AWS IoT to maintain long-lived connections and process data via the rules engine Your Lambda functions can also interact directly with other AWS services
- 34. How about a Connected Car
- 35. Connected Car Each Car with a GreenGrass Core with sensors sending data to it
- 36. What features - Connected Car Platform Connected Vehicle Cloud • Secure data consumption • Vehicle health reports • Anomaly detection • Diagnostics alerts • Map Integration • Mobile Companion Application Infotainment / eCommerce • Head Unit AGL Prototype • Alexa Voice Services • Facial recognition • Hands-free accessibility • Location-based offers • Music Integration • Amazon Video Integration
- 37. AWS Components for Connected Vehicle
- 38. Connected Vehicle AWS Connected Vehicle Cloud Reference Architecture
- 39. On the vehicle AWS Connected Vehicle Cloud Reference Architecture
- 40. AWS IoT Ingest AWS Connected Vehicle Cloud Reference Architecture
- 41. Just-in-Time Registration AWS Connected Vehicle Cloud Reference Architecture
- 42. Storage and Delivery AWS Connected Vehicle Cloud Reference Architecture
- 43. Anomaly Detection AWS Connected Vehicle Cloud Reference Architecture
- 44. Aggregated Telemetry Data AWS Connected Vehicle Cloud Reference Architecture
- 45. Drive Score Algorithm AWS Connected Vehicle Cloud Reference Architecture
- 46. DTC Detection AWS Connected Vehicle Cloud Reference Architecture
- 47. Connected Vehicle APIs AWS Connected Vehicle Cloud Reference Architecture
- 48. Authentication and Authorization AWS Connected Vehicle Cloud Reference Architecture
- 49. AWS Connected Vehicle Cloud AWS Connected Vehicle Cloud Reference Architecture
- 50. Demo Time!!
- 51. IoT and Serverless • AWS IoT takes advantage of Serverless Capabilities • Scale on demand • Respond to Events: • Complex Event Processing • Triage through queues • Focus on Benefits • Innovate and Iterate Fast
- 52. IoT Device SDK
- 53. Thank you Twitter: @madhushekar23 Linkedin: /in/madhusudanshekar
Editor's Notes
- Purpose: To show all the parts of AWS IoT and state that it looks complex but it’s actually simple. This is all of AWS IoT. It looks complex but it’s actually quite simple.
- Note: Create a slide like this for Treadstone. That shows the parts of the system and then the following slides show the parts broken out. You need services that can take local actions, keep device data in sync, securely communicate with other local devices – even when not connected to the cloud. And once cloud connection is re-established, device data and state needs to be synchronized automatically. We designed AWS Greengrass to work on almost any device with a general-purpose CPU that runs Ubuntu or Amazon Linux, and supports ARM and x86 architectures. (1 Core, 1 GHz, 128 MB RAM). So that it can run on standard Gateways, PLCs, or 10$ devices like a Raspberry Pi
- AWS Greengrass provides the following features: Local execution of AWS Lambda functions written in Python 2.7 and deployed down from the cloud. Local messaging between functions and peripherals on the device that hosts AWS Greengrass core, and also between the core and other local devices that use the AWS IoT Device SDK. Local device shadows to maintain state for the stateless functions, including sync and conflict resolution. Security of communication between the AWS Greengrass group and the cloud. AWS Greengrass uses the same certificate-based mutual authentication that AWS IoT uses. Local communication within an AWS Greengrass group is also secured by using a unique private CA for every group.
- With AWS Greengrass You can Respond to Local Events in Near Real-time AWS Greengrass devices can act locally on the data they generate, while still using the cloud for management, analytics, and durable storage. Operate Offline AWS Greengrass lets connected devices operate even with intermittent connectivity to the cloud. Once the device reconnects, Greengrass synchronizes the data on the device with AWS IoT, providing seamless functionality regardless of connectivity. Simplified Device Programming with AWS Lambda AWS Greengrass uses the same AWS Lambda programming models you use in the cloud so you can create and test your device software in the cloud first, and then deploy it seamlessly to your devices. Greengrass lets you execute Lambda functions locally, reducing the complexity of developing embedded software. Reduce the Cost of Running IoT Applications With AWS Greengrass you can program the device to filter device data locally and only transmit the data you need for your applications to cloud. This reduces the amount of raw data transmitted to the cloud and lowers cost, and increases the quality of the data you send to the cloud so you can achieve rich insight at a lower cost. Secure Communications AWS Greengrass authenticates and encrypts device data at all points of connection, so that data is never exchanged between devices and the cloud without proven identity. Greengrass uses the same security and access management you are familiar with in AWS, with mutual device authentication and authorization, and secure connectivity to AWS IoT.
- The AWS IoT Device SDK helps you to easily and quickly connect your hardware device to AWS IoT. It provides enhanced features so that your hardware device can seamlessly and securely work with the Device Gateway and Device Shadow provided by AWS IoT. Launched a couple of them along with AWS IoT last year, and now we have 7.
- In response to massive technological changes that are transforming this industry, our team has been is developing a suite of solutions designed to help our customers innovate across all reaches of the automotive industry. Now, I want to be very clear here…I am not the car guy in the room. You guys are the automotive experts. I’m here to show you how the AWS Cloud can be used to fuel your solutions, and demonstrate what is possible on our platform. In order to develop and validate our solutions, we really took a collaborative approach, leveraging experience from across not only AWS, but also Amazon as a whole.
- Greengrass On every car in our ref arch, we’ve installed a greengrass core Sometimes, whether it is for cost, legal, or bandwidth reasons, you don’t want stream all of your data to the Cloud, maybe it makes more sense to aggregate on the vehicle, then send it up Greengrass helps us address this use case. On vehicle processes (CAN or OBD-II) communicate on a telemetry substraight; greengrass will send the real-time sensor data to IoT, greengrass will also grab that sensor data, aggregate it with a Lambda function that actually runs on vehicle and send that data to IoT at pre-defined intervals. This is possible because the GreenGrass core provides Lambda runtimes for python, Node.js and Java on the actual vehicle. This is great for standardizing development environments across vehicle makes and models. This frees up valuable bandwidth, and can lower cost We’ve also looked at OTA update use cases
- IoT When vehicle sensor data data is sent to AWS, it is done so through AWS IoT, specifically, the device gateway Messaging is done in a pub/sub model, so data is transmitted using the MQTT protocol, and messages are published to MQTT channels in IoT Before data can get to the channel, though, it must pass through an authentication stage Our reference architecture employs mutual authentication and encryption at every point throughout communication with AWS IoT, this means that no messages enter our environment without a proven identity Manufacturers must first register a CA cert with IoT Then, each vehicle is issued a unique cert with attached permissions that dictate how the vehicle can interact with IoT Now, messages are authenticated and published to the device gateway, but what happens when our data reaches AWS? Data is routed to backend applications, microservices, and AWS services based on logical rules This data routing is handled by the IoT rules engine. To create a rule, you need three things, a source, logic, and a destination Your source is the MQTT channel your rule will be listening to Your logic is simple SQL code that filters the data according to the data type and other conditions you specify Your destination is the AWS service you want to invoke, using the IoT message as a parameter (Kinesis, Lambda, IoT, SQS, DynamoDB, etc) Now, we’ll walk through the rules we have developed for our reference architecture. Each rule pretty much equates to a different use case we tackled
- Rule 1 – JITR This rule is all about simplifying the vehicle registration process When a new vehicle sends data to our reference architecture for the first time, IoT will see an unrecognized cert, signed by the manufacturer’s CA During this initial TLS handshake, our JITR process is invoked When IoT sees that unrecognized cert, it will trigger a lambda function, and pass the cert; the lambda function will automatically register the vehicle’s certificate and assigns a policy, dictating the vehicle’s permissions Now, the car is automatically registered, and IoT will begin to accept its messages
- Rule 2 – Delivery & Storage This next use case is all about securely and efficiently delivering connected vehicle sensor data from IoT to S3 It is important for manufacturers and third party service providers to have access to raw sensor data because they may want to do larger, batch analytics on the data at a later date, or possibly push the data through applications to replay scenarios Therefore, need an efficient way to get data to S3 We are sending all streaming data to Kinesis Firehose, which is great at delivering massive amounts of data When in Firehose, the data will be encrypted and compressed and sent to S3 at regular intervals Once in S3, it will remain there, encrypted, until it is needed for analytics, or it is archived Data is encrypted in transit and at rest
- Rule 2.5 – Anomaly Detection This part doesn’t have its own IoT rule, instead, its using the same data captured by rule #2 As data flows through Firehose to S3, we an opportunity to analyze all sensor data in real-time, this is the perfect time for us to tackle anomaly detection, specifically, high oil temperatures To do this, we’re using Kinesis analytics, which enables us to build data processing applications to analyze records flowing through Kinesis Firehose in real time First, we filter for all oil temperature records Then we pass those data points to an easy to use unsupervised machine learning algorithm. This algorithm was developed by Amazon data scientists and comes built in as part of the Kinesis Analytics service, it is really good at quickly finding outliers; the algorithm will assign an anomaly score to each record, and for records where we decide the anomaly score is too high, we will label it as an outlier We output those outliers to a Kinesis Stream; this is where we can again leverage the power of the event-based compute model When a record enters the kinesis stream, a lambda function is triggered; the function gets the record, then puts it to dynamodb, and an SNS notification is sent to the user
- Rule 3 – Aggregated Telemetry Data This use case is all about making aggregate data available to applications in near-real time Unlike the previous rule, instead of consuming all data, we are collecting only the data that has been aggregated by Greengrass At a defined interval, Greengrass will send aggregated data to IoT; when the IoT rule detects the aggregated data, it is sent to a lambda function to be processed The lambda function will transform the data, and put it to a dynamodb table. The primary index will be the VIN, and the secondary index will be a unique trip id, enabling you to search and filter based on trips
- Rule 4 – Driver Score Processing This use case enables us to really leverage the aggregated trip data We call this our insurance use case – it focuses on encouraging or rewarding safe and efficient driving performance This use case is triggered by ignition status, when the ignition status switches to off, it triggers a driver score microservice The lambda function will retrieve all aggregated data for the completed trip, and run an algorithm using the aggregated metrics We wrote this algorithm ourselves, but it leverages common practices and patterns used by insurance and fleet management firms The driver score is put back to the trip data table so it can be queried, and the lambda function will send an alert to the user Machine Learning We have also done this with AML When the trip completed, lambda would retrieve the aggregated data, then request a real-time classification prediction from AML AML would run the metrics through a pre-made model, and classify the driver as safe or unsafe Lambda would then put the driver classification to dynamodb, and send the driver an alert
- Rule 5 – DTC Detection Our last use case demystifies the car maintenance and repair process When something goes wrong with your engine, traditionally, a light pops up on your dash. But I never know what the actual problem is, how to fix it, or how severe it is In order to simplify/clarify this, we built a simple microservice that will translate DTCs into plain English When IoT detects a DTC code, it triggers a lambda function that does three things: First, like the anomaly use case, it will put the event to a DTC table so it can be queried by manufacturers and/or owners Second, lambda will them perform a simple look up to a preexisting DTC translation table Third, lambda will send the driver a notification explaining the issue and next steps Simple, but seriously improves the car ownership experience So now… We have preprocessed, and sent vehicle sensor data to AWS The messages have been authenticated, filtered, and sent to their subscribers Our backend microservices have processed the data, sent alerts, and stored data in databases Now, we need a way for users and third party applications to interact with this data, this is the last step
- API Gateway To do this, we built our own custom REST APIs using Amazon API Gateway All we need to do is define a new API, assign it methods, then connect it to a backend lambda microservice in order to perform the task In this way, API Gateway really is like a front door for backend lambda functions When 3rd party applications make a request for data, they make a call to API Gateway which triggers a lambda function. The Lambda function performs a DynamoDB lookup, and returns data back to the application through API Gateway with minimal latency We’ve even built our own connected vehicle API spec that application developers can use as a guide for interacting with our API
- Cognito We also need make sure that users are only viewing the data they’re allowed to access To implement access control, as well as simple sign-in and sign-up capabilities, we use Amazon Cognito We just put users into pools, assign permissions, and Cognito takes care of the rest