Azure Sphere and Azure Cloud Services for Secure IoT

Update on Oct. 5 2019, Desktop App added.

The.NET application, named Azure Sphere Desktop, is built for message display and feedback control as follows. Please see Section 6.6 for more details.

1. Introduction

With the rapid evolution of the Internet of Things (IoT), more and more network-enabled devices are involved to pave the way for connected vehicle [1], industrial IoT [2, 3], connected healthcare [4, 5], smart city [6] and smart home [7] from an infrastructure perspective. Meanwhile, the considerations for security and privacy in these large-scale systems have become a great challenge that cannot be neglected in face of aggressive assault from network attackers [8]. Currently, there are two main fields of security research in the existing work. The first one is the security schemes and policies study for resource-constrained IoT systems, while the second one is the design and implementation of security solution for IoT applications.

The research on the first one is currently directed at four critical areas including access control schemes, anomaly detection, security model and key management to achieve the high levels of security. Firstly, for access control schemes in IoT, a large and intensive research effort is devoted to the access control architecture, the type of keys used to secure the communication channel, the access control channel, and the access control logic [9]. In addition, such access control schemes are widely used in implantable medical devices [10], body area networks [11], smart gird with renewable energy resources [12], smart home [13], and industrial networked systems [14]. Secondly, in order to achieve the automatic identification of resource depletion and unauthorized access, anomaly detection is proposed, which is generally categorized into three different ways, namely, unsupervised anomaly detection [15], supervised anomaly detection [16] and semi-supervised anomaly detection [17]. Thirdly, security model is a critical enabling factor that should be paid attention to for creating a trustworthy and interoperable IoT system. In this sense, security policies including hardware security, data encryption, secure routing, risk assessment, intrusion detection, anti-malware solution, firewall and trust management are usually considered from the perspectives of perception, transportation and application levels when the practical IoT application is designed [18, 19]. Lastly, key management is of great importance which involves creating, renewing, transferring and accounting for cryptographic items in lightweight, resource constrained IoT devices [20]. Policies and services about generation, renewal, discovery, reporting, escrow, rollover, destruction and revocation for keys and certificates are usually highlighted during the design process [21, 22].

Recently, the research on the IoT solutions have taken security into account in different layers. The security challenges in industrial IoT enabled cyber-physical systems was summarized in [23], which highlighted the security in data mining and big data under Cisco IoT framework. A health care monitoring framework was designed and implemented in [24], where signal enhancement, watermarking and other related analytics were used to avoid identity theft. Authentication, privacy encryption and secure packet forwarding were studied in [25], and several strategies were proposed under three-layer IoT architecture as well. An overview of security principles, security challenges and proposed countermeasures were presented in [26]. A summary of security issues about protocols and applications for IoT was given in [27], which was based on five-layer IoT framework. A comprehensive list of vulnerabilities and countermeasures on the three layers including edge nodes, communication and edge computing were provided in [28]. To some extent, these studies have achieved the security and privacy goals in one specific layer or multiple layers. However, to the best of our knowledge, there still remain two challenging issues in real IoT solutions. The first one is that very few of the existing solutions have considered the security all the way from the device to the cloud. And the second one is that the need to incorporate the high-value security into every low-cost (much cheaper than 10 US dollars) network-connected IoT devices is currently underestimated because of the limited development costs and device capabilities [29, 30]. Motivated by this fact, this project is focused on the security solution from the view of whole system, i.e., from the low-cost IoT device to the applications and services in the cloud.

In order to deal with this challenging problem, a novel class of price-sensitive application platform called Azure Sphere is released by Microsoft which integrates real-time processing capabilities with secure, internet-connected operating system [31]. Along with the Azure Sphere MCU SDK tools for application development, the Azure Sphere Security Service are also included for secure cloud and web connection.

The goal of the Azure Sphere is to enable IoT designers to incorporate the highest levels of security into every low-cost MCU device with network connectivity. Based on the extensive experience in software design for device security, seven necessary properties of highly secure, network-connected devices are identified by Microsoft as hardware-based root of trust, small trusted computing base, defense in depth, compartmentalization, certificate-based authentication, security renewal, and failure reporting [32]. Motivated by the desire to achieve the goal of seven necessary properties in IoT ecosystem, Azure Sphere MCU, Azure Sphere OS and Azure Sphere Security Service are designed to work together in a harmonious whole to reduce risks. The architecture of the Azure Sphere is shown in Figure 1. Firstly, the Azure Sphere MCU is composed of multiple ARM Cortex cores, network connectivity subsystem, multiplexed I/O peripherals, integrated RAM and flash, hardware firewalls, and the Pluton security subsystem, which provide built-in security from a hardware perspective. Secondly, the custom Linux-based kernel, the Security Monitor, and OS services that host the application container add a four-layer defense, in-depth secure environment from a software perspective. Lastly, the Azure Sphere Security Service that merges with certificate-based authentication, timely update and failure reporting renews security to confront with emerging threats from a service perspective [33].

With the help of silicon partner MediaTek, the first Azure Sphere certified MCU MT3620 was released at the end of 2017 [34]. The price of MT3620 is less than 8.65 US dollars, which covers the physical MCU chip, licenses for the chip, the Azure Sphere OS, and the Azure Sphere Security Service. MT3620 includes both ARM Cortex-A7 application processor and ARM Cortex-M4F I/O subsystems, which are designed for running Azure Sphere OS and real-time control requirements of on-chip peripherals respectively. In addition to the high-performance ARM cores, the Pluton security subsystem and the on-board Wi-Fi subsystem are embedded in MT3620 to handle secure boot, secure system operation, and high throughput network connectivity. In May 2019, the Avnet Azure Sphere MT3620 Starter kit was released by Avnet to support rapid prototyping with Azure Sphere technology [35].

Based on the current IoT trend, we propose an integrated solution that includes Azure Sphere devices and Azure cloud services to address the challenges of overall security, cost and device management.

References

1. Kuutti, S.; Fallah, S.; Katsaros, K.; Dianati, M.; Mccullough, F.; Mouzakitis, A. A survey of the state-of-the-art localization techniques and their potentials for autonomous vehicle applications. IEEE Internet of Things Journal 2018, 5, 829-846.

2. Carías, J.F.; Labaka, L.; Sarriegi, J.M.; Hernantes, J. Defining a Cyber Resilience Investment Strategy in an Industrial Internet of Things Context. Sensors 2019, 19, 138.

3. Yan, H.; Zhang, Y.; Pang, Z.; Xu, L.D. Superframe planning and access latency of slotted mac for industrial wsn in iot environment. IEEE Transactions on Industrial Informatics 2014, 10, 1242-1251.

4. Alam, M.M.; Malik, H.; Khan, M.I.; Pardy, T.; Kuusik, A.; Moullec, Y.L. A survey on the roles of communication technologies in iot-based personalized healthcare applications. IEEE Access 2018, 6, 36611-36631.

5. Yang, P.; Stankevicius, D.; Marozas, V.; Deng, Z.; Liu, E.; Lukosevicius, A.; Dong, F.; Xu, L.; Min, G. Lifelogging data validation model for internet of things enabled personalized healthcare. IEEE Transactions on Systems, Man, and Cybernetics: Systems 2018, 48, 50-64.

6. Park, S.; Park, S.H.; Park, L.W.; Park, S.; Lee, S.; Lee, T.; Lee, S.H.; Jang, H.; Kim, S.M.; Chang, H.; Park, S. Design and Implementation of a Smart IoT Based Building and Town Disaster Management System in Smart City Infrastructure. Appl. Sci. 2018, 8, 2239.

7. Vallati C.; Virdis A.; Mingozzi E.; Stea G. MEC come home! Connecting things in future smart homes using LTE D2D communications. IEEE Consumer Electronics Magazine 2016, 5, 77-83.

8. Arias, O.; Wurm, J.; Hoang, K.; Jin, Y. Privacy and security in internet of things and wearable devices. IEEE Transactions on Multi-Scale Computing Systems 2015, 1, 99-109.

9. Wu, L.; Du, X.; Guizani, M.; Mohamed, A. Access control schemes for implantable medical devices: A survey. IEEE Internet of Things Journal 2017, 4, 1272-1283.

10. Altawy, R.; Youssef, A.M. Security tradeoffs in cyber physical systems: A case study survey on implantable medical devices. IEEE Access 2016, 4, 959-979.

11. Xiaojiang, D.; Dapeng, W. Adaptive cell relay routing protocol for mobile ad hoc networks. IEEE Transactions on Vehicular Technology 2006, 55, 278-285.

12. Guan, Z.; Li, J.; Zhu, L.; Zhang, Z.; Du, X.; Guizani, M. Toward delay-tolerant flexible data access control for smart grid with renewable energy resources. IEEE Transactions on Industrial Informatics 2017, 13, 3216-3225.

13. Rath A.T.; Colin J. Strengthening access control in case of compromised accounts in smart home. In Proceedings of the WiMob 2017 IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, Rome, Italy, 9-11 October 2017.

14. Cheminod, M.; Durante, L.; Seno, L.; Valenzano, A. Semiautomated verification of access control implementation in industrial networked systems. IEEE Transactions on Industrial Informatics 2015, 11, 1388-1399.

15. Munir, M.; Siddiqui, S.A.; Dengel, A.; Ahmed, S. Deepant: A deep learning approach for unsupervised anomaly detection in time series. IEEE Access 2018, 1-1.

16. Gaddam, S.R.; Phoha, V.V.; Balagani, K.S. K-means+id3: A novel method for supervised anomaly detection by cascading k-means clustering and id3 decision tree learning methods. IEEE Transactions on Knowledge and Data Engineering 2007, 19, 345-354.

17. Hussain, B.; Du, Q.; Ren, P. Semi-supervised learning based big data-driven anomaly detection in mobile wireless networks. China Communications 2018, 15, 41-57.

18. Frustaci, M.; Pace, P.; Aloi, G.; Fortino, G. Evaluating critical security issues of the iot world: present and future challenges. IEEE Internet of Things Journal 2018, 5, 2483-2495.

19. Ali, B.; Awad, A.I. Cyber and Physical Security Vulnerability Assessment for IoT-Based Smart Homes. Sensors 2018, 18, 817.

20. Cui Z.; Lv H.; Chao Y.; Gao G.; Zhou C. Efficient key management for IoT owner in the cloud. In Proceedings of the 2015 IEEE International Conference on Big Data & Cloud Computing, Dalian, China, 26-28 August 2015.

21. Naoui S.; Elhdhili M. E.; Saidane L. A. Security analysis of existing IoT key management protocols. In Proceedings of the 2016 IEEE/ACS International Conference of Computer Systems and Applications, Agadir, Morocco, 29 November-2 December 2016.

22. Zhou, J.; Cao, Z.; Dong, X.; Vasilakos, A.V. Security and privacy for cloud-based iot: Challenges. IEEE Communications Magazine 2017, 55, 26-33.

23. He H.; Maple C.; Watson T. The security challenges in the IoT enabled cyber-physical systems and opportunities for evolutionary computing & other computational intelligence. In Proceedings of the 2016 IEEE Congress on Evolutionary Computation, Vancouver, Canada, 24-29 July, 2016.

24. Hossain, M.S.; Muhammad, G. Cloud-assisted industrial internet of things (iiot)–enabled framework for health monitoring. Computer Networks 2016, 101, 192-202.

25. Zhou, J.; Cao, Z.; Dong, X.; Vasilakos, A.V. Security and privacy for cloud-based iot: challenges. IEEE Communications Magazine 2017, 55, 26-33.

26. Mahmoud, R.; Yousuf, T.; Aloul, F.; Zualkernan, I. Internet of things (iot) security: current status, challenges and prospective measures. In Proceedings of the 2015 10th International Conference for Internet Technology and Secured Transactions, London, U.K., 14-16 December, 2015.

27. Al-Fuqaha, A.; Guizani, M.; Mohammadi, M.; Aledhari, M.; Ayyash, M. Internet of things: a survey on enabling technologies, protocols, and applications. IEEE Communications Surveys & Tutorials 2015, 17, 2347-2376.

28. Mosenia, A.; Jha, N.K. A comprehensive study of security of internet-of-things. IEEE Transactions on Emerging Topics in Computing 2017, 5, 586-602.

29. Wang, N.; Jiang, T.; Li, W.; Lv, S. Physical-layer security in internet of things based on compressed sensing and frequency selection. IET Communications 2017, 11, 1431-1437.

30. Jing, Q.; Vasilakos, A.V.; Wan, J.; Lu, J.; Qiu, D. Security of the internet of things: Perspectives and challenges. Wireless Networks 2014, 20, 2481-2501.

31. Azure Sphere Documentation. Available online: https://docs.microsoft.com/en-us/azure-sphere/.

32. Hunt G.; Letey G.; Nightingale E. The seven properties of highly secure devices. Tech. Report MSR-TR-2017-16. Available online: https://www.microsoft.com/en-us/research/publication/seven-properties-highly-secure-devices.

33. Azure Sphere architecture. Available online: https://docs.microsoft.com/en-us/azure-sphere/product-overview/architecture/.

34. MT 3620 product information. Available online: https://www.mediatek.com/products/azureSphere/mt3620.

35. Azure Sphere Starter Kits. https://www.element14.com/community/community/designcenter/azure-sphere-starter-kits/.

2. System Design

2.1. Overview

The entire system is shown in Figure 2, which can be divided into three different layers including device layer, cloud layer and application layer. Firstly, a ZigBee WSN including ZigBee End Device and ZigBee Coordinator, as well as Arduino devices stand for the legacy IoT system. Secondly, MT3620 starter kits are used as substitutions for Azure Sphere device and gateway. Thirdly, Azure IoT Hub, Azure Stream Analytics, Azure Device Provisioning Service, Azure Storage Table and other storage services are utilized as the data processing and management unit. Lastly, Power BI and Native App are used as UX solution and business integration, respectively.

2.2. Hardware Design

According to the designed solution, Avnet Azure Sphere MT3620 Starter Kit is the essential component of the proposed system. MT3620 is the first Azure Sphere certified MCU, which is embedded with tri-core microcontroller, one ARM Cortex-A7 core runs at up to 500 MHz as application processor and two ARM Cortex-M4F cores run at up to 200 MHz as general-purpose processor. In the proposed system, the MT3620 kit is used as Azure Sphere device to support real-time and security requirements when interfacing with UART, I2C, SPI and ADC on-chip peripherals. The MT3620 starter kit, powered by rechargeable lithium-ion batteries, is designed to perform as direct connected device or gateway for legacy nodes. For the former scenario, on-board sensors including 3-Axis accelerometer, gyro and temperature sensor (LSM6DSO), Pressure/Barometric sensor (LPS22HH) and Ambient light sensor are well enough for ordinary IoT scenarios. And message transmission with Azure IoT Hub can be achieved with 2.4/5 GHz dual-band Wi-Fi module. For the latter scenario, resorting to the UART interface, the legacy IoT systems such as ZigBee, Arduino and other network devices can be connected to the MT3620 gateway for message processing before it is uploaded to the Azure IoT Hub. In this project, a ZigBee wireless sensor network (WSN), as well as Arduino devices are established as legacy IoT system for environmental perception. ZigBee End Device is equipped with temperature and humidity sensor, light sensor, gas sensor, and passive infrared (PIR) sensor.

2.3 Security Design

In order to ensure security through all layers of the IoT system, the security policies and rules were divided into four categories as shown in Table 1, i.e., device security, connection security, cloud security and application security.

For device security, the MT3620 MCU used in this system is identified as a critical component that is designed according to the seven highest levels of security properties. Meanwhile, certificate-based authentication, instead of passwords, is utilized to prove identities when communicating with the cloud servers. Furthermore, to ensure the security of the application and its data, four strategies including limited access to external resources, application capabilities, signing images and device capabilities are implemented.

For connection security, the communications between MT3620 and the cloud gateway are secured by the wolfSSL, which is an industry-standard Transport Layer Security (TLS) library targeted at IoT, embedded and RTOS environments. Specifically, HTTP Secure (HTTPS) and Message Queuing Telemetry Transport (MQTT) protocols are used not only for efficient resource usage but also for reliable message delivery.

For cloud security, Azure Active Directory (AAD) is used for user authentication and authorization. Azure Stream Analytics is ISO 27001 and ISO 27018 certified, which means that information security management and personal data protection in the cloud is ensured. All data written to the Azure Table Storage is encrypted with 256-bit Advanced Encryption Standard (AES) encryption, which is considered as one of the strongest block ciphers available.

For application security, the designed solution achieves 128-bit AES algorithm for data encryption between the CC2530 ZigBee nodes. Specifically, the CC2530 chipset takes advantage of AES-CCM (Counter with CBC-MAC) mode to encrypt and decrypt data. The global variables zgPreConfigKeys and DSECURE in the configuration file “f8wConfig.cfg” are set to TRUE and 1, respectively, to enable AES security. Secondly, application capabilities, device capabilities and signing deployment are introduced to ensure the application security running on MT3620. Specifically, application capabilities are defined in application manifest file to declare the authorized use of resources that a given application requires. Device capabilities of the Azure Sphere device are granted by the Azure Sphere Security Service and are stored in flash memory. All image packages deployed to an Azure Sphere device must be signed with an SDK signing key. Before the application is uploaded to the chip by sideloading or over-the-air (OTA) method, the packages should be signed to ensure its security.

3. Hardware Setup

3.1 Hardware Items Required

• Avnet Azure Sphere MT3620 Starter Kit
• 128x64 Yellow Blue SSD1306 I2C OLED Display [optional]
• CC2530 ZigBee Board
• Arduino UNO
• PIR Motion Sensor
• DHT11 Temperature & Humidity Sensor
• MQ2 gas sensor
• Photo resistor

3.2 Connect an OLED Display to Azure Sphere Starter Kit

Interface for optional OLED 128x64 display (I2C) is left empty on the board. The pinout of the OLED DISPLAY connector on this Starter Kit is tabled below in Figure 3.

We can solder four 2.54mm Pins on the board to help connecting with OLED display as shown in Figure 4.

3.3 Connect Sensors to the CC2530 ZigBee End Devices

MQ2 gas sensor and photo resistor will give the analog signal to the P0.7 and P0.6 of CC2530, and CC2530 will do Analog-to-Digital convert and send digital signals. DHT11 is a one-wire temperature sensor, and we connect its signal wire to P1.1 of CC2530. PIR motion sensor is connect to P0.5 of CC2530. All the sensors are powered by 5V DC voltage on the module. It is shown in Figure 5.

3.4 Connect CC2530 ZigBee Coordinator to Avnet Azure Sphere Kit

In this project, we use Uart0 of CC2530 ZigBee Coordinator. So, P0.2, P0.3 and GND are used as Rx, Tx and GND for Uart communication. For Avnet Azure Sphere Kit, Uart0 on “Mikrobus Click 1” is used as follows.

Please make sure that the Rx of ZigBee Coordinator is connect with Tx of Avnet Azure Sphere Kit, and the Tx of ZigBee Coordinator is connect with Rx of Avnet Azure Sphere Kit.

3.5 Connect Sensors to the Arduino Uno Devices

MQ2 gas sensor and photo resistor will give the analog signal to the A0 and A1 of Arduino Uno, and the Analog-to-Digital convert will be done and digital signals will be sent by serial port. DHT11 is a one-wire temperature sensor, and we connect its signal wire to digital pin 2 of Arduino. PIR motion sensor is connect to digital pin 3. All the sensors are powered by 5V DC voltage on the module. It is shown in Figure 7.

3.6 Connect Arduino Uno to Avnet Azure Sphere Kit

In this project, we use Uart0 of Arduino Uno. So, Pin 0, Pin 1 and GND are used as Rx, Tx and GND for Uart communication. For Avnet Azure Sphere Kit, Uart1 on “Mikrobus Click 1” is used as follows.

Please make sure that the Rx of Arduino is connect with Tx of Avnet Azure Sphere Kit, and the Tx of Arduino is connect with Rx of Avnet Azure Sphere Kit.

4. Software Design

4.1 Software Required

As shown in Table 2, a Windows 10 PC with IAR Embedded Workbench for 8051, Visual Studio 2017 Community or Visual Studio 2019 Community, and Arduino IDE are leveraged to develop applications for CC2530 ZigBee nodes, MT3260 Starter kits and Arduino Uno respectively. Azure Sphere software development kit (SDK) Version 19.05 is also installed as indispensable extensions for Visual Studio Community.

4.2 Software for ZigBee Wireless Sensor Network

In this project, Z-Stack is used for wireless sensor nodes management and data transmission. The program running in the CC2530 ZigBee node with Z-Stack executes as follows. After the initialization process, the Operating System Layer executes the main loop in which the task list will be accessed and checked in order. As soon as the condition is met, the specified task will be carried out immediately. For ZigBee Coordinators in this project, there are two main tasks, which are UART message handler task and ZigBee wireless network incoming package handler task. On the one hand, the UART message handler task deals with the incoming data from MT3620 and then relays the message to ZigBee End Device via Z-Stack protocol message. On the other hand, the wireless network incoming package handler task is responsible for processing with the Z-Stack protocol message from ZigBee End Device and transmitting the valid data to MT3620 via UART interface. For ZigBee End Device equipped with different kind of sensors, there are two main tasks as well. Firstly, reading data from sensors and transmitting message to ZigBee Coordinator are completed in the Data Send Handler event within a user defined interval. Secondly, the downlink messages from ZigBee Coordinator through Z-Stack protocol are handled in the Message Process event.

The payload of the uplink message is shown in Figure 9. The payload is prefixed with two-byte Sensor ID, which is closely followed by two-byte temperature data, two-byte humidity data, two-byte light data, two-byte gas data and one-byte PIR sensor data.

4.3 Software for Arduino Uno

In this project, Arduino Uno is acted as a kind of legacy IoT system, which is secured by Avnet Azure Sphere Start kit to achieve message transceiver.

In the initialization of the program, the input and output pins are set. And the baud rate of the serial port is configured as 9600. In the main loop, the sensor values are collected and converted to build an 11-byte message, which has the same order as shown in Figure 9. The reading and transmitting of the sensors will be performed every 5 seconds.

4.4 Software for Avnet Azure Sphere Start Kit

Thanks to Peter Fenn and Brian Willess, the program for Avnet Azure Sphere Start Kit is built on the basis of their work "Avnet Azure Sphere Starter-Kit: Advanced Tutorial." The MT3620 can be configured as a gateway to allow legacy IoT systems to connect to the Internet and to the Azure IoT Hub. The UART interface of the Azure Sphere device is used to communicate with the ZigBee wireless sensor network, i.e., the legacy IoT system. Meanwhile, the UART peripheral should be included in the application manifest file, in which all the resources that the application requires are listed. It is noted that the application manifest will be accessed by Azure Sphere runtime to determine which capabilities are allowed to use as soon as the application is sideloaded or deployed to the device. Any attempt to access resources that are not described in the manifest will be denied by the runtime. Hence, two UARTs and Allowed Connections to Azure cloud services are added as essential capabilities. It is shown in Figure 10.

It should be noted that the “AllowedConnections” should be changed to your own Azure IoTHub.

The flowchart of the application that is running in the MT3620 as gateway is depicted in Figure 11. Basically, the initialization process for the application is pretty much the same as that in the MT3620 as direct connected device, except that the UART peripheral is configured and opened for communication with ZigBee Coordinator and Arduino Uno. In the main loop, the UART event handler is called for inbound message receiving, data validity checking and local parameters updating.

5. Azure Cloud Integration

The services provided by Azure cloud, play a key role in data collecting, data processing, data storage and data visualization. This subsection contains all the services running on Azure cloud.

5.1 Azure IoT Hub

The Azure IoT Hub plays a central role. It acts as a bridge between the Azure Sphere devices and the Azure cloud services. On one hand, not only the device-to-cloud messages are collected by Azure IoT Hub to understand the real-time state of the MT3620 devices, but also the cloud-to-device commands and notifications are sent reliably to update the policies of sensor data collecting that are stored in the MT3620 device. On the other hand, a zero-touch, just-in-time provisioning is achieved with the help of Device Provisioning Service, which means that millions of devices can be provisioned in a secure and scalable way with no human intervention.

In the Azure Portal (https://portal.azure.com), click the on the "New" icon along the left to see all the services, then click the "Internet of Things" item and choose “IoT Hub”.

Complete the fields of “Name”, “Pricing Tier”, “IoT Hub Units”, “Device-to-Cloud Partitions”, “Resource group” and “location”, then click the "Create" button. It should be noted that “F1 Free” Pricing is enough for this project. And we’d better choose the local location of the service.

Wait for the new IoT hub to show as "Online". When it is ready, open the blade of the new IoT hub, take note of the URI and select the key icon at the top to access to the shared access policy settings.

Select the Shared access policy called iothubowner, and take note of the Primary key and connection string in the right blade. We may copy these into a text file for future use.

For more information, we can refer to this doc online: Create an IoT hub using the Azure portal (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-create-through-portal).

5.2 Authenticate the Avnet Start Kit with Device Explorer

Communication between Azure IoTHub and devices is secured. On Windows, we can use Device Explorer app to complete this Authentication process. A pre-built version of the Device Explorer application for Windows can be downloaded by clicking on this link: https://github.com/Azure/azure-iot-sdk-csharp/releases/tag/2019-1-4(Scroll down for SetupDeviceExplorer.msi). The default installation directory for this application is "C:\Program Files (x86)\Microsoft\DeviceExplorer".

Open the Device Explorer app and fill the IoT Hub Connection String field with the connection string of the IoT Hub that we created and click on Update. Go to the Management tab and click on the Create button. The Create Device popup will be displayed. Fill the Device ID field with a new Id for your device (AvnetStarterKit for example) and click on Create as follows.

When the device identity is created, it will be displayed in the grid. Right click on the identity we created, select Copy connection string for selected device and save the value by copying to clipboard, since it will be required to connect the hardware with the IoT Hub.

5.3 Update Azure IoTHub connection string

Download the source code from GitHub repository (https://github.com/shijiong/AzureSphereSecurityGateway). Open the solution with Visual Studio, navigate to “connection_strings.h”, update the connetion string.

5.4 Create Azure Storage Account and Azure Storage Table

In this project, we will need Azure Storage Table to store the data from sensor devices. So, we can create it as follows. In the Azure Portal, click the on the "STORAGE" icon along the left to view your existing storage accounts (if any), then click the "+NEW" button in the lower left corner. In the "NEW" panel, select "STORAGE" | " STORAGE ACCOUNT" button. Wait for the new storage account's status to show as "Online". Select the newly created Storage account, and then click MANAGE ACCESS KEYS at the bottom of the page. Copy the Storage account name and one of the access keys.

We use Microsoft Azure Storage Explorer (https://azure.microsoft.com/en-us/features/storage-explorer/) to create the Azure Storage Table “AvnetAzureSphere”.

5.5 Create Azure Stream Analytics Job

Azure Stream Analytics is used in this project to filter the sensor data that gathered by IoTHub, and stream the data to PowerBI and Azure Storage Table. The new Stream Analytics is created as follows.

In the Azure Portal (https://portal.azure.com), click the on the "New" icon along the left to see all the services, then click the "Internet of Things" item and choose “Stream Analytics job”.

Complete the fields of “Job Name”, “Resource group” and “location”, then click the "Create" button. Wait for the new Stream Analytics to show as "Online".

Now, it’s time to config the Stream Analytics Job. First, in the Inputs window, we choose IoT Hub, and in the IoT Hub Settings screen, we complete the following information:

• Input Alias: AvnetData
• Subscription: Use IoT Hub from Current Subscription
• Choose an IoT Hub: input the name used during the IoT Hub creation
• IoT Hub Shared Access Policy Name: iothubowner
• IoT Hub Consumer Group: powerbi

Click Next, and then Complete (leave the Serialization settings as they are).

To set up the output, go to the Stream Analytics Job's OUTPUTS tab, and click the ADD AN OUTPUT link. In the Add an output to your job popup, select the POWER BI option and the click the Next button. In the following screen you will setup the credentials of your Power BI account to allow the job to connect and send data to it. Click the Authorize Now link.

To set up the Query configuration, go to the Stream Analytics Job QUERY tab and replace the query with the following statement:

SELECT
*
INTO
[AvnetStartKit]
FROM
[MT3620]

SELECT
*
INTO
[AvnetAzureSphere]
FROM
[MT3620]

It should be noticed that we just select all the data from IoTHub to PowerBI and Azure Storage Table. Click on the SAVE button and YES in the confirmation dialog. Now that the job is configured, the START button is enabled. Click the button to start the job and then select the JOB START TIME option in the START OUTPUT popup. After clicking OK the job will be started. Once the job starts it creates the Power BI datasource associated with the given subscription.

5.6 Config PowerBI Dashboard

Now that the datasource is created, go back to Power BI session, and find My Workspace by clicking the Power BI link. After some minutes of the job running you will see that the dataset that you configured as an output for the Job, is now displayed in the Power BI workspace Datasets section.

Please note that the Power BI dataset will only be created if the job is running and if it is receiving data from the IoT Hub input, so check that the hardware is working and sending data to Azure to ensure that the dataset be created. To check if the Stream Analytics job is receiving and processing data you can check the Azure Management Stream Analytics monitor.

Once the datasource becomes available you can start creating reports. To create a new Report, click on the Power BI datasource.

The Report designer will be opened showing the list of fields available for the selected datasource and the different visualizations supported by the tool. Here we choose real-time sensor date and the processing time. Now the report is almost ready. Click the SAVE button and set Campus Environment as the name for the report as follows.

5.7 Browse environment data anywhere anytime you want

With Power BI Desktop (https://powerbi.microsoft.com/en-us/desktop/), we can get the data from Power BI Web and display the data report that we create above on desktop PC.

With Power BI application on iOS or Android, we can get the data from Power BI Web and display the data report on mobile phone.

6. Appendix

6.1 Build and Monitor the application

Download the source project from Github: https://github.com/shijiong/AzureSphereSecurityGateway/tree/master/AvnetAzureSphereSK_OLED. Thanks to Peter Fenn and Brian Willess, the program for Avnet Azure Sphere Start Kit is built on the basis of their work "Avnet Azure Sphere Starter-Kit: Advanced Tutorial." Make sure the following configurations.

1. Open the build_options.h file in this IDE's editor and check:

Line #5: must be commented-out (ie. remove comment characters if present at line start of //#define IOT_CENTRAL_APPLICATION ).

Line #8: must be enabled (ie. #define IOT_HUB_APPLICATION )

2. The connection string in connection_strings.h should be replaced with your own device connection string.

3. In app_manifest.json file, "ISU0", "ISU1" should be set in “Uart” section and "****.azure-devices.net" (your own IoTHub) should be configured in “AllowedConnections” section.

6.2 Monitor the output of the Visual Studio IDE

The debug information will be displayed in the output windows of Visual Studio. The raw UART information will be shown as in Figure 17.

6.3 Monitor the messages with Device Explorer

Once the messages are sent successfully to Azure IoTHub by Avnet Start Kit, the information can be monitored by Device Explorer. The raw messages are shown as in Figure 18.

6.4 OLED Display Screens for Uart information

As soon as the application runs, the information will be shown on OLED display. Four screens are added on the basis of “Avnet Azure Sphere Starter-Kit: Advanced Tutorial”. The source code can be found in oled.c, including the method of update_uart_data1 and update_uart_data2. The information will be extracted from the raw message and displayed on the OLED as shown in Figure 19.

6.5 Azure Table Storage

Getting access to Azure Table storage is not only fast but also cost-effective for user applications. The entities of the table are shown in Table 3, which contain multiple properties including partition key, row key, time stamp, device ID, event enqueued UTC time, event processed UTC time, gas, humidity, light, PIR and temperature. The partition key, row key and time stamp are automatically generated for every entity in the table, which are representative of the first part of an entity’s primary key, the second part of an entity’s primary key and the time that the entity was last modified.

In order to evaluate the performance of Azure Table Storage, the average end-to-end latency (AverageE2ELatency) of successful requests and the average server latency (AverageServerLatency) are provided by Azure. AverageE2ELatency includes the required processing time within Azure Table Storage to read the request, send the response and receive acknowledgement of the response. AverageServerLatency stands for the average latency used by Azure Table Storage to process a request, excluding failed requests. This value does not include the network latency which is included in AverageE2ELatency. Latency evaluation for Azure Table Storage is shown in Figure 20.

According to the curves in Figure 20, the values of AverageServerLatency and AverageE2ELatency are 11.25 ms and 77.27 ms respectively, which means that the average entire latency is less than 100 ms. It is acceptable for most of IoT applications.

6.6.NET Application

Download the application from the Github and copy the necessary connection string information from your Azure IoT Hub portal. This connection string is not device specific and it is IoT Hub unit specific. Please see Figure 21 for more detail.

Using this connection string you can access all the devices created in this IoT Hub unit. Paste the connection string as shown in Figure 22.

7. Summary

In this project, we investigated the integration for IoT solutions with large-scale, low-cost and secure end devices. We focused on the following three aspects. Firstly, featured by Azure Sphere device and Azure cloud services, an integration of hardware, software and services was designed, deployed and tested. Secondly, the hardware prototypes including Avnet Azure Sphere Starter Kit direct connect device and gateway device were designed and implemented. Thirdly, the programs for hardware devices, the configurations for cloud services as well as the PowerBI applications were designed and tested.

Special Thanks

Thanks to Peter Fenn and Brian Willess, the program for Avnet Azure Sphere Start Kit is built on the basis of their work "Avnet Azure Sphere Starter-Kit: Advanced Tutorial."

Thanks to Avnet and Microsoft, you provided me with the Azure Sphere Starter Kit to help making this project into reality!