AWS Greengrass brings autonomous control and compute to the edge where as
AWS Step Functions makes it easy to coordinate the components of distributed applications
In this post I will look at how to leverage these services to coordinate components of distributed IoT applications.
In this ever shrinking globalised world, margins are being squeezed tighter than ever
Businesses are often are extending the life cycle of their investments, prolonging and sweating out refresh cycles.
There is an ever increasing amount of rules and regulations for compliance that need to be adhered to.
And we have a plethora of disconnected systems that we struggle to extract value from
This is a standard maintenance maturity model, as its important in framing this session that everyone has a base understanding.
At the bottom of the model we have re-active or run to fail. Prety self explanitory. This may be the correct method of maintenance for some assets as the cost of failure is less than the cost of performing maintenance.
The next level is preventive, think of you car. You might service your car every 10,000 kms. Still not a great place to be. Over service, it costs you money, under service, risk breakdown.
Condition-based maintenance represents the initial stage of a more proactive maintenance approach. Condition-based take in to account sensor and usage data with algorithmic logic.
And the nirvana of maintenance maturity is Predictive. Using a combination of known rules plus ML we can model and identify either a performance issue or an impending failure days, weeks or months before failure will occur.
Lets look at this problem through the lens of something very common, elevators. They are everywhere and for the better part, most systems operate autonomously. An induvial presses a button, an elevator is requested.
Its 8am in the morning and people are arriving to work. Are the elevators relocating the ground floor to save idle time? Or when a VIP scans in, is their elevator being prioritized?
And lets talk about remote overrides.
A few years ago I was once stuck in a lift in a modern building in Melbourne during a deployment. 3 hours later a technician came on-site in and pressed a button in a panel. Why couldn’t this be done remotely?
With limited system visibility to what is occurring this translates to a higher than optimal total cost of ownership
e spoke to our customers and looked at how they were working with connected devices and discovered 3 intractable problems.
The Law of Physics.
Latency can be a problem for some applications, think crash avoidance system and medical alerts. So some decision-making must continue to be executed locally on the device. High-value and safety-critical processes must always continue working.
Then there is the Law of Economics.
The cost of bandwidth is not falling as fast as the cost of storage and compute.
We might act on low value data locally and upload high value and aggregate data to the cloud for analytics and storage.
And finally, the Law of the Land: For legal or compliance reasons, and concerns around privacy, some industries prefer to store data locally moreso, some governments impose data sovereignty restrictions on where data may be stored.
AWS Greengrass brings local compute, messaging, data caching, and sync to connected devices even when they are not connected to the internet
Greengrass is a software platform for running Lambda functions and IoT functionality locally against virtually any connected device.
With Greengrass, connected devices can run Lambda functions, keep device data in sync, and communicate with other devices securely, even when not connected to the Internet
Previously Building cloud-enabled devices that work offline required maintaining separate code bases for local and cloud execution. As a developer you can use the same programming model that you use in your existing AWS environments, Lambda.
This means you can create and test your device software in the cloud, and then seamlessly deploy it to all of your devices.
1m20sec
The Greengrass Core is the heart of Greengrass group and is responsible for local Lambda execution, messaging, device shadows, security and for interacting directly with the AWS Cloud.
Its requirements are modest, it needs a single core with 1Ghz and works on both x86 and ARM architectures. We list validated reference architecture in our documentation and you can use a Raspberry Pi3 to get started. Whilst today I have raspberry Pi 3’s with me, you can use ruggedized industrial compute in your environment.
The Greengrass Core takes advantage of your devices compute, memory, storage and peripherals. So if you have have IO, be it Digital or Analogue, serial and so on, you can leverage these using Greengrass.
On the security front it supports Mutual auth, both locally and also with the cloud.
Certificates on your devices can be associated to SigV4 credentials in the cloud
Any device that uses the IoT Device SDK can be configured to interact with the Greengrass Core via the local network.
And my favourite part, Greengrass runs Lambda. This means you can write Lambda functions in the cloud and deploy them locally to your Greengrass Core
With local lambda running you can, Command and Control, Perform offline operations, aggregate and filter data aswell as perform iterative learning
I’ll shortly illustrate a few of these in our demo
But this is only half of the picture, we want to to shift the dial on our elevators.
We need state co-ordination.
Step Functions is part of the AWS Serverless Platform, and makes it simple to orchestrate Lambda functions for serverless applications
If you look at your portfolio of apps today, I bet there aren’t that many apps with only one function, one entry point, one module, one component.
In fact, it’ll be common to have LOTS of functions, lots of them talking to each other.
And this is where step functions comes in
Step Functions is a reliable way to coordinate components and step through the functions of your application.
.Step Functions automatically triggers and tracks each step, so your application executes in order and as expected. Step Functions logs the state of each step, so when things do go wrong, you can diagnose and debug problems quickly. You can change and add steps without even writing code, so you can easily evolve your application and innovate faster.
Use the JSON-based Amazon States Language to write your state machine. As you construct your JSON , it will be visualised in the console
You define your workflow as a series of steps and transitions between each step.
When you start a state machine, you pass it input in the form of JSON, and each state changes or adds to this JSON blob as output, which becomes input to the next state.
The console and CLI provide visualization of the status of you state machine execution.
Step Functions supports the following states today and we will have more states in the future.
When you combine these states, you can build really interesting state machines.
Lets quickly talk through a use case.
Imagine your stream is dependent on a service developed by another stream in your organisation and it fails every now and then, but if you keep calling their service it eventually works.
How do you catch and manage failure today, what is the impact to your business? Are you having to engineer a solution?
With Step Functions we can easily catch and retry
This sample code is for a task state and this is all the code you would need in your task state to solve the problem and deliver a successful outcome. You have just increased the reliability of your application whilst reducing heavy lifting of handling error conditions
Enough theory lets switch in to a demonstration.
We are going to walk through evolving the architecture of The Snowy Unicorn Elevator Company. It could be said initially, that their architecture and methods were preventive at best. Lets see how we can help them.
Instantly we have our Greengrass Core with Local Lambda. I am using Local Lambda with long running Lambda functions for each of our IOT devices, which are our elevators.
With local Lambda we have smarts!
With elevators containing hundreds of sensors we can monitor everything from motor temperature to cab speed and we can feed this in to our Lambda functions to elevate the TSUEC to ’condition’ based maintenance.
Before we switch in to our demo I would like to talk about what I have on stage with me today. As mentioned prior, the GreenGrass core can run on both X86 and ARM architectures. The GreenGrass Core is in the middle here. It is running on a Raspberry Pi 3 with Raspbian OS.
We also have two Raspberry Pi’s with Raspberry Pi SenseHats acting as our IOT enhanced elevators.
These devices and the GreenGrass Core are connected on the the same VLAN together. The router I am using has 5 ports. 3 Ethernet connections for the PI’s, one uplink to the internet which I am NAT’ing.
Whilst out system is connected to the internet, in theory it should function autonomously without connection to the AWS Cloud. I think we might have to test this claim shortly
INSERT MOVIE
I didn’t invite you here today to focus on building a better candle, I want to focus on building a better light bulb and with that lets look at our enhanced elevator architecture
Devices in Greengrass synchronise to a Greengrass Core, but they can also Synchronise with the IOT service. This opens up a world of possibility.
CloudWatch can now subscribe to specific MQTT topics so we can have Cloudwatch read the data being feed from our devices in the field.
And with the tightknit integration of AWS services we can send this data to multiple places. I am going to use a Machine Learning Model.
This is not a ML session, for more information on ML , I suggest you see Olivier Klein’s session on AI,ML and IOT later this afternoon.
But lets just say I have ‘created’ a ML algorithm to predict motor failure based on motor temperature, motor speed and vibration.
We are now moving in to predictive territory.
Our operations centre has detected an impending failure.
A CloudWatch alert has triggered, which has resulted in notification via SNS and the execution of our Step Function
Our step function being is invoked with payload of JSON data.
It will start at ‘Maintenance Required’ and the JSON payload will be modified as is it progresses through the state machine.
Is the maintenance disruptive, yes or no?
If it is send an email to the building supervisor, wait for acknowledgement of approval and then book the job in to the ERP system for completion
During this process we can monitor the status of the step function through the CLI, Console and SDK
Lets switch back to the demo
INSERT DEMO
So we just saw this in action but lets talk about our manual approval process.
With any step function, you need an invocation method. This could be a scheduled event or could be the result of an event occurring in your environment.
We are a Cloudwatch Alarm with SNS to fan out to Lambda which is invoking our Step Function which pushes back to lambda using a ‘long-poll’ task. The GetActivityTask is used by workers to retrieve a task which has been scheduled for execution by the running state machine. This initiates a long poll, where the service holds the HTTP connection open and responds as soon as a task becomes available
The TaskToken which identifies the scheduled task, is embedded in to our email. The token must be included in subsequent calls in order to update the task
Once the user approves or denies the request by clicking on the link hosted by API GW, it will send back to our StepFunction either SendTaskSuccess or SendTaskFailrue
I quickly want to leave you with some tips on Greengrass device registration as registering your device to Greengrass is a little bit different to using the IOT service
As per normal you will need to create your device in AWS IOT, but here is how things differ.
Your device security policy will need to allow Greengrass Discovery for your device and then you must use the Greengrass Discovery python class in your device code.
Upon initial execution and then every 30 days thereafter, the IOT service will provide you the local endpoint of your Greengrass Core aswell as a valid root certificate for the Greengrass Core
With this information in hand, your device will connect and validate its certificates against the Greengrass Core endpoint and if all checks out it will connect to and consume messages on the local MQTT device topic
But what about local lambda?
Yes it is a blue icon when running on Greengrass
Firstly, local lambda is free which is great.
As mentioned prior, we support Python 2.7 only at this stage. Lambda can be invoked on Greengrass either from shadow updates or as a subscriber to a local MQTT Topic.
In summary of this session
Greengrass brings compute to the edge, allowing you to respond to local event quickly,
It uses a Lambda programming model which helps reduce the cost of developing IOT applications
I illustrated how the use of step functions can enable you to quickly build and coordinate microservices to create applications
And lastly, you can use Greengrass at the edge, coupled with Step Functions, together to drive increased maturity in your business, saving you time and money.
Providing compute at the edge
AWS Greengrass is software that provides local compute, messaging, data caching, and sync capabilities for connected devices in a secure way. With AWS Greengrass, connected devices can run AWS Lambda functions, keep device data in sync, and communicate with other devices securely, even when not connected to the internet. Using Lambda, Greengrass ensures your IoT devices can respond quickly to local events, operate with intermittent connections, and minimize the cost of transmitting IoT data to the cloud.
Most elevator systems operate autonomously. They provide limited device-to-device interaction. Because the maintenance operator has no or limited visibility into the system, the total cost of ownership (TCO) is higher than optimal.
In this example, we use Greengrass to control IoT things, our elevators. The Greengrass core is the heart of Greengrass. It runs on both x86 and ARM architectures and has modest requirements. The core provides command and control of our elevators through local long-running Lambda functions. It also aggregates and filters data and performs iterative learning. Because elevators contain hundreds of sensors, we can use Greengrass to monitor everything from motor temperature to cab speed and we can feed this information into local Lambda functions to drive maturity in our maintenance practices.
For the purpose of this blog post, we use Raspberry Pi 3 to simulate Greengrass control of the elevators. The Greengrass core is running on a Raspberry Pi 3. Our two elevators are simulated by using Rapsberry Pi 3 with a combination of Raspberry Pi Sense HAT, local Lambda functions, and device code.
Let’s look at our physical architecture:
Key elevator elements
-
- Greengrass core
The core is responsible for local Lambda execution, messaging, device shadows, and security, and for interacting directly with the AWS Cloud. It controls our elevators through local MQTT messages and local Lambda functions. It also sends elevator-specific metrics to the AWS Cloud.You can invoke a Lambda function on the Greengrass core through device shadow updates or as a subscriber to a local MQTT topic. We are using a Lambda function for the following:- To publish elevator telemetry to a local MQTT topic. The Greengrass core aggregates the telemetry before it is streamed back to the AWS Cloud for more processing and aggregation.
- To evaluate sensor data locally. This can result in an action being performed on the elevator. For example, if the elevator motor overheats, the elevator is taken out of service and placed into maintenance.
- Elevator floor status and availability is tracked by device shadow updates. The device shadow updates are being consumed by a custom web interface which provides a means to visualize our elevators.
- To determine, based on the local device shadow, if the elevators are available for use. If available, the Lambda function sends the elevators to a random floor by setting the desired state. Because a Lambda function can run for an unlimited amount of time on Greengrass, this Lambda function sleeps for 30 seconds before it sends the elevators to another random floor.
- Device-specific codeOn initial startup, the elevators use the Greengrass Discovery API to locate and connect securely to the Greengrass core. Our device-specific code publishes to the local MQTT queue elevator-specific data, such as motor temperature, shaft vibration, door speed, current floor, and availability. The device-specific code can also receive messages from the local MQTT queue, which provides a channel for duplex messaging.
- Greengrass core
Providing local visualization
We can consume the MQTT device shadows to visualize the status of our elevators in a web application. We can also perform remote command and control by updating the desired state of the device shadows. This, in turn, synchronizes the AWS IoT device shadow with the Greengrass device shadow which is then interpreted by our device-specific code to provide command and control.
Using this pattern of remote command and control, we can optimize the morning rush so that the elevators are relocated to the ground floor to minimize waiting. Or we can take inputs from a building control system so that when a VIP uses a key card to enter the parking garage, an elevator is prioritized and dispatched.
This pattern also allows us to provide remote command and control to an operations center to remotely move stuck elevators or take elevators in and out of service during maintenance events.
All of these scenarios are accomplished by reading the reported state of the device in AWS IoT and setting the desired state. Changes set to the desired state flow through AWS IoT to the Greengrass core and to the elevators.
Increasing our capability maturity
By using multiple AWS services, we can build an architecture that will help us achieve PdM maturity
Step 1: Providing detective capabilities
Synchronizing elevator telemetry with AWS IoT opens up a world of possibility. The service has a rules engine that has a predict function that can evaluate IoT messages against an Amazon Machine Learning (Amazon ML) model.
As an example, we can create a model to predict motor reliability and evaluate data from messages being synchronized with AWS IoT against this model.
{
”sql": "SELECT * FROM 'elevator/#/motor_temperature'",
"ruleDisabled": false,
"actions": [{
"cloudwatchMetric": {
"roleArn": "arn:aws:iam::XXXXXXXXXXXX:role/iam_role",
"metricName": "maintenance-status",
"metricNamespace": "pm-metrics",
"metricValue": "${machinelearning_predict
('motor_reliability',
'arn:aws:iam::XXXXXXXXXXXX:role/iam_role', *)
.predictedLabel}",
"metricUnit": "None"
}
}]
}
JSON
We are now moving into predictive territory.
Step 2: Notifying and orchestrating
Let’s assume the AWS IoT rules engine used a predict function against an Amazon Machine Learning model and an anomaly or leading indicator for failure has been detected. This information can be used to orchestrate a workflow that will get the elevator repaired.
By using Amazon CloudWatch alarms and Amazon Simple Notification Service (Amazon SNS), you can use an approach like the one described in the “Fanout” section of Common Amazon SNS Scenarios in the Amazon SNS Developer Guide. In this approach, you publish a message to an SNS topic not only to provide notification, but to start a workflow through a Lambda function
Step 3: Providing state coordination
We can use AWS Step Functions, a service that is part of the AWS serverless platform, to provide branch logic and coordination. Step Functions makes it simple to orchestrate Lambda functions for serverless applications.
Using Step Functions, we can construct a state machine that can take input in the form of JSON from our Lambda function. Our state machine consists of steps and transitions between each step that, depending on the issue detected, take a different path for resolution.
Each step correlates to a Lambda function. A step could be performing a manual approval process and waiting for the building supervisor to approve the work or booking the job in the ERP platform. Step Functions logs the state of each step, so if things go wrong, you can diagnose and debug problems quickly.
This example uses a manual approval process. The state machine is waiting for approval of the maintenance request. For more information about the manual approval process used in this example, see the Implementing Serverless Manual Approval Steps in AWS Step Functions and Amazon API Gateway blog post.
Summary
In this post, we described a pattern that you can use to advance PdM in your organization. AWS Greengrass brings compute to the edge, allowing you to respond to local events quickly and provide operational intelligence to your devices, even without access to the internet. Greengrass uses a Lambda programming model, which helps reduce the cost of developing IoT applications.
With local Lambda functions and the ability to use services such as Amazon Machine Learning and AWS Step Functions, you can drive maturity in your business, climb the PdM maturity curve, and ultimately save your organization time and money.
For video of the content included in this post, see the AWS Developer Day video.
If you have questions or other feedback, please leave it in the comments below.