Any Internet of Things (IoT) deployment is particularly hard to secure because of three main impetuses: a green-field market which means speed is crucial (the antithesis of a slow and steady security approach); custom solutions which require specialized security considerations across hardware, software and firmware; as well as resources that often get spent in design and development, leaving little left over for security.
However, security is one of the main reasons why end users will be reticent to explore the possibilities of a new IoT application. With more hacks every day, it’s easy to see why users would shy away from a well built, but less than secure product, thwarting the very reason we worked hard to be a first mover to market.
The only problem? Whipping up an IoT security solution is much more easily said than done. Or it was until now.
The Avnet Azure Sphere Starter Kit and Azure Sphere developer resources allowed me to quickly develop a no-compromise secure IoT application. Using available resources, it was easy to add a GPIO controlled relay and access the UART signals that were used to establish communication to a MCP39F511A power monitor development kit. A working sample project and Azure connectivity details provided by the “Add Connected Service” wizard in Visual Studio even helped me to securely connect my starter kit and application to Azure, allowing me send telemetry messages and receive Device Twin updates.
Here’s how I did it.
Azure Sphere basics
As background, Microsoft is partnering with silicon vendors to design, develop and manufacture Azure Sphere MCUs. The first device available is the MT3620. The MT3620 is a secure, connected (Wi-Fi), crossover MCU that allows engineering organizations to quickly and easily develop, deploy and maintain highly secure IoT implementations.
The Azure Sphere Solution includes a secure connected MCU, a secure OS, and the Azure Sphere Security Service. The secure MCU piece is fulfilled by the MT3620. The secure OS is a Linux kernel modified and maintained by Microsoft.
The Azure Sphere Security Service runs in the cloud and provides critical functionality including a Public Key Infrastructure (PKI), over-the-air (OTA) updates and error reporting. Microsoft provides and maintains all of this infrastructure for you so that you can focus on adding differentiating features to your product design while giving you the flexibility to securely deploy software updates to your product at any point in time.
Having all this functionality and infrastructure provided by the Azure Sphere Solution means that your organization does not need PKI, OS, or OTA update engineers involved. In addition, Microsoft has provided a complete SDK that integrates with Visual Studio 2017 or 2019 and publishes working Azure Sphere projects on GitHub. The Azure Sphere SDK provides real-time debugging, Azure connectivity, and hardware APIs. For more details about the Azure Sphere Solution I recommend visiting the Azure Sphere product page.
To help developers bring Azure Sphere to life, Avnet developed a pre-certified, commercial-off-the-shelf (COTS) Azure Sphere Module that development teams can include in their hardware designs to reduce engineering efforts and non-recurring engineering (NRE) costs in an Azure Sphere Starter Kit that can be used for development and proof of concept efforts.
The Starter Kit includes on-board sensors (3D accelerometer/gyro, temperature, pressure, and ambient light), user LEDs and buttons as well as common interfaces for Click Modules and Grove Sensors. Additionally, MT3620 interfaces are accessible including GPIOs, UART, I2C, SPI, ADC, PWM, as well as a header for an I2C OLED display and a PMOD device. The Starter Kit makes it easy to prototype and create proof of concept (POC) systems to reduce overall system risks before you commit to building any of your own printed-circuit boards and hardware designs.
Example project: Power Monitor
Overview: The Power Monitor IoT solution is a hardware/software solution that can be used to collect power data from any device that plugs into a standard 120V outlet. We use a UART to send register read commands to a MCP39F511A power monitor device and parse the response to capture voltage, current, and frequency measurements. We send this power telemetry data to an IoT Hub in Azure. Additionally, we use Device Twins in Azure to control a relay on the Starter Kit from the cloud. A Device Twin is a digital representation of the IoT device properties that lives in the cloud and allows you to view and request device property changes from the cloud.
Development environment: For my development environment, I need a Windows 10 computer, Visual Studio 2017, and the Azure Sphere SDK.
Wiring: The wiring for this solution is very simple. Basically, we just need to wire the UART and 3.3V power between the boards (see the wiring specifics table). Note that the wiring for the Click Relay is achieved by just plugging the Click module into click socket #1. In addition to the signal wiring between the boards, I modify the MCP39F511A board by creating an open circuit on the neutral trace for the 120V load. I solder wires to either side of this open circuit and wire them to the Click Relay. When the relay is open, the device plugged into the solution will be powered off. When the relay is closed, the circuit will be closed and the device will be powered on.
|Signal||Avnet Starter Kit||MCP39F511A|
|UART TX||Click Socket #2: TX||J5: TX|
|UART RX||Click Socket #2: RX||J5: RX|
|3.3 V||Click Socket #2: +3.3V||J5: 5V|
|Ground||Click Socket #2: GND||J5: GND|
Software: To help me get a jumpstart on the software I start with one of the Azure Sphere example projects provided by Microsoft on the Azure Sphere GitHub repository. This sample implementation includes code that sends data over one of the UARTs and receives data from the same UART, just what I needed. Additionally, the project uses GPIO signals to drive LEDs and I need to drive the Click Relay using GPIO, so I have a working example.
Next, I use the “Add Connected Service” wizard in Visual Studio to include all the software I need to securely connect my device to Azure and to send/receive messages to/from Azure. This wizard uses my Azure credentials to pull down and include all the details my application needs to securely connect to my Device Provisioning Service (DPS) and IoT Hub in Azure.
I have an application that connects to my DPS and IoT hub in Azure and sends/receives data using the ISU0 UART as well as working examples on how to drive GPIO signals—and it took me all of 10 minutes to get to this point. Next, I just need to send and receive messages to/from the MCP39F511A device, send power telemetry to my IoT hub, and process the Device Twin message to control the state of my relay. Keep in mind, all the code below was mostly all there for me. I just had to make minor modifications for my specific application.
Interacting with the MCP39F511 took some additional software to read all of the relevant measurement information out of the device into my application. However, once I have the data, it can be used to make decisions at the edge and then sent to Azure for further processing. I hard-coded the MCP39F511A register read message including a static checksum byte. This message is sent to the MCP39F511A every ½ second from my main() function. On the UART receive side, a callback method gets invoked when new data is received, I add code to validate the data and parse out the measurements.
To send/receive data to/from the UART I use the included write() and read() functions. I used epoll to get notified when there is data to read from the UART.
Sending data to my IoT Hub is accomplished by constructing a JSON object with key value pairs and simply calling the void AzureIoT_SendMessage(const char *messagePayload ) function that was included in the example application. I don’t have to add any additional code to connect to Azure, or to monitor my connection to Azure, or to reconnect to Azure when needed. All this functionality is included and it works!
Next, I need to catch and process Device Twin messages. There’s a callback routine that’s instantiated whenever my device receives a Device Twin message from Azure. The routine void MCU_DeviceTwinChangedHandler(JSON_Object * desiredProperties ) is called with a JSON object that includes the device twin desired properties. I add code to parse out the key value pairs and look for the device twin property my application expects “enabled.” The code then toggles the GPIO pin that controls the relay on the Click Module based on the Boolean value of the “enabled” key value pair.
The code below looks for a key called “enabled”. If the key exists in the desired properties JSON object, then the value is extracted using the json_object_get_boolean() routine and the bEnabled variable is updated. Next we call GPIO_SetValue() to actually change the GPIO signal that controls the relay.
Finally, we call the checkAndUpdateDeviceTwin() routine that will send a reported properties JSON object back to Azure with our new reported property value for the “enabled” key.
What I learned
I am very pleased with the Azure Sphere solution and the Avnet Azure Sphere Starter Kit. The Starter kit can be ordered here. The kit includes the MT3620 device on an Avnet designed, pre-certified module. The kit can be used for IoT development and/or proof of concept projects. After you’ve proven out your project, you can use the Avnet Azure Sphere Module in your own design and lift and shift your POC software application to your design.
Brian Willess works for Avnet as a Technical Solutions Engineer where he is an Azure Sphere technical expert and educates development teams on Azure Sphere Secure MCUs and also develops Azure Sphere prototypes and demos to accelerate Azure Sphere projects. Most of his career background has been in low-level firmware development as well as management of firmware teams and projects. He holds a Bachelor’s degree in Computer Systems Engineering from Arizona State University.