Manage and Auto-scale your IoT solution with a predictable IoT Cloud
As companies continue to fully roll out their IoT projects, management of the various components of the solution becomes a critical part of their operations. The flexibility of Azure IoT Hub to enable customers to start small, paying only for the amount of IoT Hub capacity needed at any point along the device deployment curve, helps drive predictability in the cost of an IoT solution. However, the potentially irregular rate of device and message growth in an IoT solution does add a unique challenge for operations. When the number of messages ingested from devices in a given day exceeds the limit of the chosen IoT Hub capacity, the IoT Hub will begin to reject messages until either the IoT Hub is scaled-up, or the time rolls over into the next day (UTC time). Wouldn’t it be nice to have IoT Hub just automatically scale up to a higher capacity when a certain threshold of messages is met, before this limit is reached? Read about it in the Azure blog.
Andruino R2, a cloud robots using Azure iot (ROS to Azure iot interface)
Andruino R2 using Azure iot hub to collect and publish robot's sensor data on a Web. Datas sensor come from a ROS topic. Video: https://www.youtube.com/watch?v=fxeoljZsCfo Andruino R2 is an open educational low-cost (components about 35€/USD) modular and extendable mobile robot based on Android and Arduino, integrated in the cloud, to be used as an educational tool in labs and classrooms of STEM, ICT vocational training or engineering courses, as well as in e-learning or MOOC courses as an alternative or, complementary, to virtual labs and soft robotics simulation. It is a first step introducing what we call “BYOR: Bring Your Own Robot” education policy equivalent to “BYOD: Bring your own devices”. Andruino it is powerful but easy to construct and extremely low cost, as it is based in the student's smartphone. Andruino R2 is compatible with ROS (Robot Operating System) and with iot clouds and try to bring deep learning and other advanced techniques to the STEM's and VET's classrooms. Author: @andruinos License: CC-BY-SA https://creativecommons.org/licenses/by-sa/2.0/How to build a simple IoT Edge Version 2 Heartbeat Module
Recently, the Microsoft Azure IoT Edge platform was updated with more features, better documentation and lots of goodies. Yes, the learning curve of this new version is steep, especially if you are new (like me) to Docker. But once you just have started building your own Edge solution, things seem to fall into place. A logical flow seems to be described in the Microsoft documentation: Simulate an IoT Edge device in Windows Simulate an IoT Edge device in Linux Develop and deploy a C# module Deploy Azure Stream Analytics as a module Deploy Azure Machine Learning as a module Deploy Azure Functions as a module Looks easy, doesn't it? But reading the comments, people are still confused. First of all: DO NOT MIX VERSION ONE AND VERSION TWO DOCUMENTATION. Version one is based on one executable (gw.exe) which injects classes from DLL's (a configuration file has to be supplied). Modules are just classes in the DLL's. Version two is based on Docker Containers, each module is a separate container and therefore each module is a separate executable. These modules share the same logic to connect to a message bus which provides the routing. This 'runtime' has to be installed on the Edge machine, next to/outside the Docker containers. Note: the good thing is that the architecture still stands, multiple modules on top of a messagebus and messages are routed. The better thing is that the routing is now far more intelligent. And Microsoft has provided some guidance for migration After that, work your way through the documentation provided above, and check out my recent blogs: Deploy an Azure StreamAnalytics Job on the IotEdge Introduction to the Microsoft Azure IoTEdge Modbus-tcp-iotedge module Better property roundtrip for Azure IoIEdge Module Twin OK, I know, the learning curve is still steep. How about a full example of a simple module? The full article can be found here The source code of this module is available on Github The module is available for download as a Docker imageDeploy an Azure StreamAnalytics Job on the IoTEdge
The second version of the Microsoft IoTEdge solution is now available as Public Preview. In this version, you can run predefined modules like Modbus, build your own modules, deploy Azure Machine Learning modules, deploy Azure Functions and you can deploy Azure StreamAnalytics jobs. The concept is pretty simple, as always you have to create an ASA job, define inputs, outputs and a query. But this time the ASA will run on a local device: Microsoft provides documentation here and here explaining how to deploy your ASA modules. Let's dig a bit deeper into it. Read the full blog hereIntroduction to the microsoft/azureiotedge-modbus-tcp IoTEdge Module
The newest version of the Azure IoTEdge solution is a very promising platform. The combination of remote provisioning the modules, the power of twin configuration and the new routing is interesting. But the learning curve is pretty steep. The first version was based on programming an application. The new version is based on docker images, each being a separate application, which has to be stored in the container registry of your choice (like Docker Hub or your own container registry in Azure. So once you have learned how to build and deploy your own modules, you can check out the modules Microsoft already supplies. One of these modules is a Modbus module. It's available at the Docker Hub of Microsoft. Modbus is a great protocol for highspeed communication over TCP and I have already blogged about it, using the previous IoTEdge SDK version. Let's check out how we get some telemetry from it. Read the full article hereBetter property roundtrip for Azure IoTEdge Module Twins
The newest version of the Azure IoT Edge is still in public preview but this one makes the Edge truly intelligent! We are now able to both distribute and manage logic on-premise. Version one of the IoT Edge was and still is based on running an executable. And each module (ingest, transform, distribute) is a class in a dynamic library. And all modules are connected using a broker serving the role as MessageBus. Messages between modules are exchanged using configurable routes. This first version is still available for download. But the new version is fundamentally different. Modules hosted as a container In the new version, we still see modules connected by and exchanging messages using a local MessageBus. But Microsoft has redefined the modules into separate executables, each running is a different container. The containers are hosted in Docker and can run on Linux or Windows. Microsoft already provided a lot of modules in the Docker Hub, for OPC UA support, for Modbus support, etc. And you can deploy your own modules too! There are multiple examples available on the Microsoft website which explain how to get started. In this blog, I show how tweaking some example code leads to even better management and a better understanding of what's happening on the Edge using the Module Twins properties. Read the full article in my blogAzure IoT Hub Device Provisioning Service is generally available
The Azure IoT Hub Device Provisioning Service is now available with the same great support you've come to know and expect from Azure IoT services. The Device Provisioning Service enables customers to configure zero-touch device provisioning to Azure IoT Hub, and it brings the scalability of the cloud to what was once a laborious one-at-a-time process. The Device Provisioning Process was designed with the challenges of the supply chain in mind, providing the infrastructure needed to provision millions of devices in a secure and scalable manner. With general availability support comes expanded protocol support. Automatic device provisioning with the Device Provisioning Service now supports all protocols that IoT Hub supports including HTTP, AMQP, MQTT, AMQP over websockets, and MQTT over websockets. This release also corresponds to expanded SDK language support for both the device and client side. We now support SDKs in the following languages including C, C#, Java, Node (service for now, device coming soon), and Python (device for now, service coming soon). Get started with the Device Provisioning Service with the quick start tutorials. Read about it in the Azure blog.Device provisioning: A manufacturing timeline for TPM devices
A lot of folks using the IoT Hub Device Provisioning Service are starting to use hardware security modules (HSMs) in their devices because of how easy it is to use an HSM with the provisioning service. This is great, and the team loves hearing about customers increasing the security of their solutions. However, since a lot of customers are new to HSMs, particularly Trusted Platform Modules (TPMs), we've received a couple of questions about how TPMs specifically fit into the existing manufacturing process. This blog post should help clarify things. This article is only relevant for devices using TPM 2.0 with HMAC key support and their endorsement keys and not for devices using X.509 certificates for authentication. Check out this blog post to learn more about secure hardware with the Device Provisioning Service using X.509 certificates. TPM is an industry-wide, ISO standard from the Trusted Computing Group, and you can read more about TPM at the complete TPM 2.0 spec or the ISO/IEC 11889 spec. Read about it in the Azure blog.Device provisioning: Identity attestation with TPM
Folks using the IoT Hub Device Provisioning Service to securely provision their devices are taking the opportunity to start using hardware security modules (HSM) to store the keys on their devices. Hardware security modules protect cryptographic keys and operations. HSMs provide high levels of protection against key compromise by device software and firmware bugs, and usually provide good protection against hardware attacks. Hardware-based security can reduce the risk of device cloning, can improve supply-chain security, and can bootstrap secure and reliable device enrollment using the Device Provisioning Service. Some of you might be new to using HSMs and are wondering exactly how the Device Provisioning Service validates a device’s identity, especially when using TPMs, and why it’s so secure. This post describes the identity attestation process when using a TPM. TPM stands for Trusted Platform Module and is a type of HSM. This blog post assumes you’re using a discrete, firmware, or integrated TPM. Software emulated TPMs are well-suited for prototyping or testing, but they do not provide the same level of security as discrete, firmware, or integrated TPMs do. Please don’t use software TPMs in production. Learn more about the types of TPMs. Read about it in the Azure blog.Direct methods support in the IoT Hub Connected Service
The Visual Studio 2017 Connected Service for Azure IoT Hub has received an update a couple of months ago. This update had some visual updates and now supports a Singleton pattern for the Device client too. But it also included support for both Device twins and Direct Methods. The latter feature looks a lot like the Commands method but there are some fundamental changes. Yes, both solutions (Command and Direct Method) can execute code on a remote IoT Hub client. But the remote method just passes a message to the client. The Direct method can pass a message in a certain context. It calls a specific method (a client can have multiple methods registered) and passes the JSON parameter. If you execute a Command, it feels like fire-and-forget. There is no descriptive response. But the caller of a Direct Method can wait until a response is accepted and a JSON value is returned. Let’s check out Direct Methods. It all starts with that Connected Service extension in Visual Studio 2017. Read the full story here
