(my notes from the Connect(); session)
Enable edge intelligence with Azure IoT Edge by Arjmand Samuel
https://channel9.msdn.com/events/Connect/2017/B114
The cloud provides the ability to monitor your devices, which may be remote, which may be spread around the world. So the cloud gives you a way to bring them all together in one place and manage them. And it also allows you to have a monitoring from these devices and do things like ML in the cloud for which you need near infinite resources in storage in the cloud. Very insightful processes run on top of your data => AI, ML….
Edge --> your operations happening in your own facilities, this operations requires very tight low latency control loops, which you need to execute right there next to your machines. Azure IoT Edge allows you to do that. You maybe also need a protocol translation, imagine you have an modbus (https://es.wikipedia.org/wiki/Modbus) protocol internally and you want to provide translate into other kind of Internet protocols (maybe you have privacy reasons, and you don't want to send it).
IoT Edge allows you to have all the power you have in the cloud and take it all in the Edge.
Symmetry => you have the same programming models that you have in the cloud which you can bring to the edge. Your developers don't need other skills to program the devices.
Protocol Translation: pretty common to have a Modbus or other protocol, and want to translate them into IoT protocols like MQTT.
On-prem data aggregation: Do analysis in the device: save bandwidth = save cost = privacy Intellectual Property (IP). Analyze data and aggregate data on premise.
Offline: Another interesting operational pattern that we've seen is offline. Perhaps its short-term offline or long-term offline. So you might have a device or a few of them, deployed in a ship, and that seals off and then you don't have connection, but you want to still continue doing the same kind of intelligence in kind of Analytics , which you were doing previously with the cloud.
Intelligence at the edge: The scenario where IoT Edge really shines is…. Allowing you to bring the cloud services that we have in the cloud and have that power, that intelligence deployed onto the devices onto your edge devices (like AI or ML from the cloud and deploy it onto a edge device). => Training your models in the cloud (requires a lot of resources) and then you can bring it down to the edge. Stream analytics is another service that we have which you can already run jobs in the cloud and you actually have the same job: you can deploy it onto the edge (including developed in several languages)
Example
Pump to extract oil: All in remote, not a lot of operators are located next to the pump.
Pressure above the plunger and pressure down the plunger (on the axis)
Well site (depósito/hueco)
Next to the well there is a Gateway device, connected over Modbus. It goes up to SCADA controller (monitoring data) When the pump data goes out of any of those operational limits, you have to send the data (over mail, SMS, or… whatever) and send an alert to the operator who is off-site. The operator would look at the data and send somebody down to there (to adjust the pump)
Move data from well site to supervision site is expensive. And once you do that you can actually also upload them to the cloud.
That's how is done today.
If you could take this power of the cloud and bring it down to the edge, right next to this pump.
Same pump, same gateway. Same Modbus.
IoT Hub in the cloud to upload all the data you have.
Modbus module next to the device. This Modbus module is doing the protocol translation.
It is picking up data and bring it up to the cloud, where you can train you ML models, but also you can deploy those models down back on this IoT device and analysis (anomaly detection) and stop the pump, making the decision in the edge, without having to go up to the cloud and wait the latency.
Train in the cloud and run on the edge.
Provides a secure connection to the Azure IoT Edge, update software/firmware/config remotely, collect state and telemetry and monitor security of the device. -> Go and work at the hardware layer from Azure (?)
Enables rich management of Azure IoT Edge from Azure provide a complete solution instead of just an SDK. -> You don't have to compile any code and put it on the device itself. You hosted somewhere and you can manage that device from the cloud.
Enables A IoT Edge to target the most popular edge OS, such Window and Linux. -> We are building an IoT Edge, and we've built it to be cross platform. We support many versions of Linux and Windows on x64, on ARM… whatever gateway device or edge devices you have deployed on your prem.
Enables Dev/Test of edge workloads in the cloud with later deployment to the edge as part of a continuous integration /continuous deployment pipeline. -> Extremely portable. Any workload that you define in the cloud, you can simply bring them down to the edge.
Enables seamless deployment of advanced capabilities such as AI from MS and any third party, today and tomorrow. -> Not only edge services like ML and AI. Also your own code. Innovate extensible fashion,
So that's really some of the design principles that we have for a Azure IoT Edge.
Module: is a unit of compute
It could be parts of services which could be packaged as modules . All this modules are passed in containers and all of these containers are hosted in a repository somewhere.
We support Docker containers.
That is a module instance: when a module comes down and is deployed… let's say two devices: one in Germany, one in China. Those are module instances that are running over there.
All of these module instances are brought down, monitored and controlled in the security provided by a component. We call it the IoT Edge runtime.
Each module has an identity: important for security and authentication reasons. You should be able to address these modules from the cloud.
Each device has one ID. And each module have an address which indicate what modules are deployed into the device.
You could have multiple modules instances deployed on any one device and there's way for us to go in and control an address them though an identity in the cloud
Each module also have a "Twin" in the cloud for the device. You will have module twins and these modules (here you have the runtime status of every module)
Module twins => JSON with the configuration (desired configuration, reported configuration… etc…)
The document pages are similar to the "device twins".
It can be used to get the state of the module, send out data to the module from the cloud, and that gives you the control over the module and monitoring of what is happening on the monitor.
IoT Edge Runtime sits on top of the device.
The device is connected to an IoT Hub and modules are sitting on top of it.
The runtime is the responsible for installing and updating all workloads on the device (heart of the system). It maintains the security so the runtime has access to all security tokens, the certification, the keys… which are in the hardware and it brings them up to each module for authentication….
It also ensures that there are always running so the modules are always running, so when you have a module going up, if there is an issue, runtime knows it and it would try to restart and all that information would be available in the IoT Hub, as the status of the devices and modules.
The runtime reports health and all the communication happening between leaf devices and the edge is going through edge runtime as well.
It is an extension of IoT Hub, sitting on the devices. It also facilitates all communication between these modules, so these modules are talking to each other, they talk though the runtime. The runtime is really responsible for doing that communication or making it happen, and based on our concept of routes so you essentially define routes with the edge runtime from the cloud, and it's implemented on the edge device.
All communication between the edge device and the cloud is done through edge runtime
How we bring these workloads onto the edge device?
There is a telemetry stream going from the device (on the left) to the cloud, and the cloud is sending comands to the IoT Edge. I show two arrows (logical arrows), that are an encrypted channel between IoT device and IoT hub.
Device twins is the core concept here and it enables device management to happen.
Device twins have two properties: desired property and reported property.
The desired property is owned by the cloud and can define what the desire property would be and that goes down to the IoT device, and the IoT device interprets that.
The reported property is owned by the device, and it is send up to the cloud.
Any time the IoT Hub in the cloud has the current state of the device (through the reported property) and any change.
These are the underlying mechanisms that we have in terms of Twins, which can use to configure IoT device today.
Now, this concept, we can apply it to the IoT edge device as well as the IoT Edge modules.
There are some other things also within a device management: they tag their methods, they job in queries -i won't mention here-.. But really this is the core concept that we use for IoT Edge.
The blue rectangle is IoT Edge (device) , with its SO (Windows or Linux). Secure boot.
We have any kind of device, and when we put the IoT Edge Runtime, then it brings down the edge functionality on to this device.
The Operator selects which device is connected and which node in the device.
And then, in the cloud is deciding which workloads are needed to come down into the device (with Twins). Then the Edge runtime interprets the desired properties from the Twin and start pulling down these containers (that could be anything, any container based in workloads - Azure functions as stream analytics edge, ML, your own code…)
The operator defines routes for these devices at these modules.
The routes are essentially when a message comes out from one module and it needs where it has to go.
Those routes are all defined in the cloud, in the device twin, then the routes come down and the edge runtime picks that up and starts the implementation.
Each module also has a twin in the cloud and it brings down to the module (device). If we change a desired property in the twin, it will change in the edge module.
Device => container workloads.
Routes => in the cloud & control how messaging happens in the device
Module twin => control define what kind of modules and parameters, and understanding what the state of each module is.
Define in the cloud, how the edge device behaves (Configuration.)
IP based device: All the trafic can be routed from the edge device to different modules or send up to the cloud.
If the device is not an IP based device, but it has bluetooth, you can put the BT module. It would be listening communication protocols (com port) and it would pick up all the data, and the module will become a proxy for that.
Principles that we have for securing the edge.
-> Developers are abstracted from the details of security.
Identify and secure the device in hardware.
Hardware could be different technologies, but it's all rooted in the hardware.
On top of this hardware we have a secure boot process that allows you to boot or recover de device.
Above that is the secure execution environment. This is part of the OS, which is secured by the hardware and OS, and there will run some components, like secure agents
And then we have the security cypher resources. All the modules running in containers, where you have the edge runtime orchestrating all of these containers (so that's a really high level view).
"Secure processor" => secure root of trust.
Boot process When the device boots up, it boots up the secure runtime, which is our security agent and a common root of trust (http://www.symantec.com/rot/) which is essentially an API layer-2.
The hardware based root of trust in the secure of your OS, and once is booted up, as part of the boot sequence it checks for tendecity (?) of the code, if the code is the correct code it has to be brought up, and then, if is the right code, once is up and running, it makes that the code remains pristine. (Checked though the interface of the secure execution environment)
When this is done, the runtime can be started.
The standard execution environment is being run and then the different modules. Now you have your services put in containers.
The edge runtime is always talking to the cloud, and this is important because is the cloud who knows how the device must be configurated, and here you have the root of trust on the device.
Some of these modules running could need crypto material: keys, certificates… Then they do a call to de secure part of the OS and it provides the right material from the API which is on top of the secure runtime. It is based on secure root of trust and it comes up, and now each module can trust whatever information is being passed to them.
If you want to know more about how this model works, we have already a showcase of this infrastructure with a couple of partners who we signed a partnership agreements (MX chip and ….)
We are very serious about making sure that the edge is secured to the maximum possible level.
-> Sensor Tier: small little sensors, temperature and so on…
-> Gateway class devices: big, powerful devices (allows you to do a lot of processing on them)
We're supporting X64 and ARM and SO that support containers.
The Hardware size depends on the scenario: if you're going down some complex ML, large models in AI which requires a lot of compute, you might go to the right of the spectrum (get a powerful device with CPU, storage and so on…). But if you are running little workloads like little bit of data aggregation, some analytics, and then you're passing that data to de cloud, or store it, you just need devices of "interactive tier", like Raspberry Pi 3 kind devices.
The security model is available for this whole spectrum (Interactive, Industrial and gateway tier) but not for the sensor and constrained tier.
Cloud development skills: one big thing that we're doing with IoT Edge runtime deployed on our devices.
Developers don't need special skills to develop specifically for those devices, they just need to have the skills to develop cloud applications and the we can deploy these applications onto our Edge devices.
Cross platform, familiar tools and tools you can use on any platform.
The developer could develop and test in the cloud or in the device connected to the cloud.
Continuous iteration: with containers the developer would be using the tools that we provide.
Manage large fleet of devices, so they have designed this infrastructure, they envision many thousands of edge devices deployed out there, geographically dispersed, all controlled and configured though IoT Hub.
Operators stage and deploy them at scaled and make sure that the deployment's going to thousands of devices is good (maybe doing a test deployment onto a small set of devices, and then move on to the complete set of devices).
All of this is built into operational workflows, so all we do have graphical user experiences in our portal for doing all this managing it at scale.
But also we understand many business and many enterprises might have their own workflows for deploying the Edge devices and workloads onto edge, so we have an API layer for that, and it is enabling us to build our user interfaces on it, and clients can use their own business process on top of that.
What do you do when you package services in containers?
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent