USD

Rapidly Deploy a Secure Cloud-Connected IoT Device Network Complete with Edge Computing Capabilities

By Stephen Evanczuk

Contributed By Digi-Key's North American Editors

Though much in demand, the deployment of an Internet of Things (IoT) network with edge computing resources can be a daunting undertaking with multiple requirements for endpoint devices, edge computing systems, and secure cloud connectivity. Although discrete elements of the required solution are readily available, integrating them all into a seamless, efficient IoT application requires immersion in the complex tasks of implementing not only the endpoint and edge hardware platforms, but also the service interfaces, communications methods, and security protocols required by IoT cloud providers.

Recently, a steady stream of more highly integrated IoT solutions has emerged to help developers get to market more quickly. For example, a set of cloud-ready endpoint and edge computing products from Microchip Technology provides an off-the-shelf solution designed to connect easily with Amazon Web Services (AWS) IoT services and the AWS IoT Greengrass edge computing service.

This article will briefly discuss why intelligence should be deployed at the edge. It will then introduce Microchip's AWS-qualified boards that serve as cloud-ready sensor endpoint systems. The article will then show how those endpoints can be combined with an edge computing platform based on a wireless system-on-module (SOM) preloaded with AWS credentials and service software to provide near transparent connectivity to the AWS cloud.

Combining endpoint and edge system

Ready availability of low-cost, low-power systems has simplified implementation of so-called endpoint systems, which are the sensor and actuator devices that make up the farthest reaches of the IoT application periphery. Although these endpoint systems connect directly with the cloud in many IoT applications, more complex applications often require deployment of so-called edge systems, which lie functionally positioned between endpoints and the IoT cloud.

By providing local processing capabilities in close proximity to a set of IoT endpoints, edge systems can reduce latency in tight feedback loops, or meet timing requirements for industrial process controls. Edge systems provide local resources needed to process more complex algorithms such as machine learning inference, or sophisticated preprocessing routines used to clean data and reduce the volume and velocity of data driven to the cloud. This local processing capability proves critical in supporting advanced security policies and privacy requirements such as data minimization prior to transfer across the public Internet.

Enhancing IoT applications with AWS IoT Greengrass

Amazon Web Services (AWS) formalizes edge processing capabilities with its AWS IoT Greengrass service, which provides a portion of its cloud services running as Greengrass Core on the edge device. Designed to work closely with cloud services running on scalable AWS cloud resources, Greengrass provides a relatively straightforward path for deploying and updating machine learning inference models built with tools such as the AWS SageMaker fully managed machine learning platform (Figure 1).

Diagram of AWS IoT GreengrassFigure 1: AWS IoT Greengrass simplifies local processing and edge deployment of advanced functionality including machine learning models trained in the AWS SageMaker machine learning environment. (Image source: Amazon Web Services)

Local processing is only one of the benefits of an edge service such as AWS Greengrass. In providing a sort of interface buffer between endpoint systems and cloud resources, edge systems also play a key role in meeting IoT application requirements for reduced latency, for enhanced privacy and security, and for enhanced availability. AWS Greengrass provides the foundation for delivering these capabilities.

In the AWS Greengrass model, after a one-time discovery phase with cloud services, endpoint devices within a defined Greengrass group interact with each other using MQ Telemetry Transport (MQTT) messaging managed by a Greengrass Core device (Figure 2).

Diagram of AWS IoT Greengrass group, endpoint devices can communicate with each otherFigure 2: Within an AWS IoT Greengrass group, endpoint devices can communicate with each other and the cloud using MQTT messaging managed by a Greengrass Core device. (Image source: Amazon Web Services)

Once deployed in a Greengrass group, devices can cooperate to avoid lengthy roundtrip delays found in IoT deployments using IoT devices that communicate directly with the cloud. Instead, devices can signal each other directly through MQTT channels mediated by the local processing capabilities of the Greengrass Core device.

If connectivity to the cloud is lost, devices can continue to function under management of the Greengrass core device. Conversely, if a device goes offline, other devices and the cloud-based application can continue to function using data maintained by a virtual device shadow associated with each physical device (Figure 3).

Diagram of Edge computing service architectures like AWS IoT GreengrassFigure 3: Edge computing service architectures like AWS IoT Greengrass help maintain availability by providing shadow devices that can maintain the latest device state data, allowing IoT applications to continue to function even if the associated physical device goes offline. (Image source: Amazon Web Services)

Although straightforward in concept, implementing this coordination among a set of IoT devices can be challenging. For a typical IoT developer, taking full advantage of this edge computing capability presents a daunting combination of hardware, software, and systems administration challenges. At the hardware level, a network of suitable endpoint and edge computing devices needs to be built and deployed. Software needs to be written to implement secure communications within the local network of IoT endpoints and edge devices, as well as with cloud services. Finally, those devices need to be appropriately configured, provisioned with suitable private keys and certifications, and authenticated with each other and the IoT cloud service.

To simplify the process, a set of Microchip boards provide AWS-qualified drop-in solutions for both endpoint and edge devices able to connect simply and securely to the AWS Greengrass Core locally, and to the AWS IoT Core in the cloud.

Cloud-ready endpoint systems

Designed for rapid deployment as endpoint systems, Microchip's PIC-IoT WA and AVR-IoT WA boards are designed to provide out-of-the-box connectivity with AWS IoT Core. The two boards offer the same overall functionality but are designed to provide familiar platforms for developers accustomed to working with the Microchip PIC microcontroller family, and to those working with the Microchip AVR ATmega microcontroller family. Based on the Microchip ATMEGA4808 8-bit microcontroller, the AVR-IoT WA board uses the same set of components as the PIC-IoT WA (Figure 4), which is based on the Microchip PIC24FJ128GA705 16-bit microcontroller.

Image of Microchip AVR-IoT WA and PIC-IoT WA boardsFigure 4: The Microchip AVR-IoT WA and PIC-IoT WA boards provide cloud-ready endpoint systems that include the same complement of support devices built around different Microchip microcontrollers, including a 16-bit PIC microcontroller for the PIC-IoT WA board shown here. (Image source: Microchip Technology)

For connectivity, the boards each include a Microchip ATWINC1510-MR210PB certified Wi-Fi module designed specifically for low-power IoT devices. The module integrates 8 megabits (Mbits) of flash and a complete transmission and receiver radio frequency (RF) signal chain including power amplifier (PA), low-noise amplifier (LNA), RF switch, power management, and printed antenna. Along with integrated boot read-only memory (ROM) for rapid firmware boot capability, the built-in network stack supports standard Internet protocols using hardware accelerators to speed Transport Layer Security (TLS) and Wi-Fi security protocols.

Besides a Microchip MCP9808 precision digital temperature sensor and a Vishay TEMT6000X01 photodiode sensor, each board includes a mikroBUS connector. Using this connector, developers can easily expand the hardware base by selecting add-on boards from the broad selection of available Mikroe Click boards. For power and battery management, the boards each include a Microchip MCP73871T-2CCI/ML device, which provides both system power and lithium-ion battery charging from a USB power source or wall adapter.

For security, each board includes a Microchip ATECC608A secure element. For these boards, this device comes pre-provisioned with keys and certificates to provide out-of-the-box support for AWS IoT authentication and security mechanisms.

Using their collection of on-board hardware components and pre-loaded firmware, the boards are designed to connect with minimal effort to AWS IoT Core. Developers need only power up the board using a micro USB cable connected to their personal computer. After the board connects to a local Wi-Fi access point using its own credentials or the developer's, it automatically establishes an MQTT connection with AWS IoT Core using the Wi-Fi module's built-in TCP/IP stack and pre-provisioned security credentials. After establishing that MQTT connection, the board immediately begins transmitting data from its temperature and light sensors. Developers can view the results on a device-specific page in a Microchip sandbox account.

Microchip provides this baseline application in separate repositories for PIC-IoT WA code and AVR-IoT WA code. By examining this code, developers can gain a quick understanding of the basic design patterns, such as the use of MQTT connections when communicating with the cloud to send sensor data and to receive commands or data (Listing 1).

Copy
// This will get called every 1 second only while we have a valid Cloud connection
static void sendToCloud(void)
{
    static char json[PAYLOAD_SIZE];
    static char publishMqttTopic[PUBLISH_TOPIC_SIZE];
    ledTickState_t ledState;
    int rawTemperature = 0;
    int light = 0;
    int len = 0;    
    memset((void*)publishMqttTopic, 0, sizeof(publishMqttTopic));
    sprintf(publishMqttTopic, "%s/sensors", cid);
    // This part runs every CFG_SEND_INTERVAL seconds
    if (shared_networking_params.haveAPConnection)
    {
        rawTemperature = SENSORS_getTempValue();
        light = SENSORS_getLightValue();
        len = sprintf(json,"{\"Light\":%d,\"Temp\":%d.%02d}", light,rawTemperature/100,abs(rawTemperature)%100);
    }
    if (len >0) 
    {
        CLOUD_publishData((uint8_t*)publishMqttTopic ,(uint8_t*)json, len);        
        if (holdCount)
        {
            holdCount--;
        }
        else
        {
            ledState.Full2Sec = LED_BLIP;
            LED_modeYellow(ledState);
        }
        
    }
}
 
//This handles messages published from the MQTT server when subscribed
static void receivedFromCloud(uint8_t *topic, uint8_t *payload)
{
    char *toggleToken = "\"toggle\":";
    char *subString;
    ledTickState_t ledState;
   sprintf(mqttSubscribeTopic, "$aws/things/%s/shadow/update/delta", cid);
    if (strncmp((void*) mqttSubscribeTopic, (void*) topic, strlen(mqttSubscribeTopic)) == 0) 
    {
        if ((subString = strstr((char*)payload, toggleToken)))
        {
            if (subString[strlen(toggleToken)] == '1')
            {   
                setToggleState(TOGGLE_ON);
                ledState.Full2Sec = LED_ON_STATIC;
                LED_modeYellow(ledState);
            }
            else
            {
                setToggleState(TOGGLE_OFF);
                ledState.Full2Sec = LED_OFF_STATIC;
                LED_modeYellow(ledState);
            }
            holdCount = 2;
        }
    }
    debug_printer(SEVERITY_NONE, LEVEL_NORMAL, "topic: %s", topic);
    debug_printer(SEVERITY_NONE, LEVEL_NORMAL, "payload: %s", payload);
    updateDeviceShadow();
}

Listing 1: Developers can examine code samples in Microchip's software repositories to a gain better understanding of key design patterns such as exchanging MQTT messages with cloud services as shown in these two functions. (Code source: Microchip Technology)

Developers can extend this code using a variety of development resources. Microchip supports custom software development with its MPLAB X integrated development environment (IDE), cloud-based MPLAB Xpress IDE, and free MPLAB XC compilers. For debugging, each board includes the Microchip PICkit On-Board (PKOB) nano debugger, which eliminates the need for an additional debugging hardware interface. Developers access the PKOB debugger through the USB connection to their personal computer while working in the MPLAB X IDE.

AWS Greengrass-ready solution

Microchip makes augmenting their IoT network with edge computing resources based on AWS Greengrass nearly as simple as deploying cloud-connected endpoints.

For the edge computing platform, Microchip provides its ATSAMA5D27-WLSOM1 wireless (WL) system-on-module (SoM) with AWS qualified AWS Greengrass support. As with the Microchip endpoint boards, the ATSAMA5D27-WLSOM1 provides a comprehensive hardware platform designed to connect easily to AWS IoT Core services (Figure 5).

Diagram of Microchip ATSAMA5D27-WLSOM1 (click to enlarge)Figure 5: The Microchip ATSAMA5D27-WLSOM1 integrates a full complement of devices required to deliver an AWS IoT Greengrass qualified edge computing system. (Image source: Microchip Technology)

For its host processor, the WLSOM1 uses the low-power SAMA5D27 system-in-package (SiP) ATSAMA5D27C-LD2G-CU, which integrates Microchip's high-performance Arm Cortex-A5 processor-based SAMA5D27, which contains two gigabits (Gbits) of low-power double data rate 2 synchronous dynamic random-access memory (LPDDR2-SDRAM).

As with its endpoint boards, Microchip’s WLSOM1 includes a certified wireless module. In this case, Microchip uses its ATWILC3000, which supports both Wi-Fi and Bluetooth connectivity with coexistence using a combination of integrated hardware accelerators, integrated processors, and stack firmware. The WLSOM1 also offers wired connectivity managed by a Microchip KSZ8081RNAIA Ethernet transceiver. Microchip includes its 64 Mbit SST26VF064BEUI flash, which comes pre-provisioned with an IEEE allocated 6-byte extended unique identifier (EUI-48) and 8-byte EUI-64. This ensures a globally unique MAC address in order to reliably connect to the public Internet. (See "Flash Memory with a Built-In MAC Address Can Really Help During Development".)

Finally, the WLSOM1 includes the ATECC608A secure element for hardware-based security. Thanks to its high level of integration, the WLSOM1 requires relatively few components beyond decoupling capacitors and pullup resistors to implement the hardware interface in a board design.

Bringing up a WLSOM1-based board on AWS IoT Greengrass requires very little effort. In fact, most of the effort involves setting up AWS services for its use. Microchip provides developers with step-by-step guides for this, including how to create an AWS account and how to define a Greengrass group of Greengrass core and endpoint devices. After building the target system on a Linux development system, developers upload the target image, Greengrass Core software, and certificates to the WLSOM1, typically using a secure digital card (SDCard) flash drive.

Authentication and secure communications operate transparently to the developer thanks to the hardware-based security provided by the ATECC608A secure element. For Greengrass edge systems, however, the ATECC608A plays a deeper role in protecting the private keys underlying secure communications between the Greengrass Core running on the edge system and the AWS cloud.

Devices in a Greengrass group rely on digital certificates to authenticate each other and their messages within the group and with cloud-based AWS services (Figure 6). If the underlying security mechanisms and protocols are compromised due to exposed private keys or fraudulent certificates, the group and even cloud-based resources can be compromised in turn.

Diagram of multiple certificates backed by private keys stored in endpointsFigure 6: To ensure secure communications transactions, AWS cloud services and AWS IoT Greengrass groups rely on multiple certificates backed by private keys stored in endpoints and the Greengrass Core device. (Image source: Amazon Web Service

AWS protects itself and its users' applications by permitting interactions only with trusted devices that incorporate a hardware secure element able to protect the private keys used for secure communications between the Greengrass Core device and the AWS IoT Core, and between the Greengrass Core device and endpoints (Figure 7).

Diagram of Greengrass Core device relies on secure storage of private keysFigure 7: A Greengrass Core device relies on secure storage of private keys using secure elements such as the ATECC608A device integrated in the Microchip ATSAMA5D27-WLSOM1 wireless SOM. (Image source: Amazon Web Services)

AWS has identified the WLSOM1 as well as the ATECC608A secure element as Greengrass qualified solutions able to meet its security requirements. In fact, the ATECC608A supports AWS' enhanced security capability provided in IoT Greengrass Hardware Security Integration (HSI). HSI uses the Public Key Cryptography Standards #11, which defines an industry standard application programming interface (API) for communications between a processor and a hardware security module (HSM) used to store private keys. In the WLSOM1, the ATECC608A is designated as an AWS Greengrass qualified HSM Support for this standard security interface is particularly important for Linux-based systems used in edge systems in general, and in Greengrass Core devices in particular

Using this secure software foundation, developers can safely extend their Greengrass Core edge systems with local processing capabilities using AWS Lambda functions, which provide a relatively simple event-driven programming model. While custom code running on the Greengrass Core device can support specific application requirements, AWS Lambda functions allow these devices to interact directly with AWS cloud services. For example, developers can easily implement Lambda functions that connect endpoints with AWS services, such as Amazon's NoSQL DynamoDB database management system for data storage or other services in the extensive set of AWS offerings (Figure 8).

Diagram of AWS IoT Greengrass enables edge systems to provide local processingFigure 8: AWS IoT Greengrass enables edge systems to provide local processing including use of AWS Lambda functions for simple integration with AWS cloud services for data storage, machine learning, and other capabilities. (Image source: Amazon Web Services)

Conclusion

Deployment of an IoT network with edge computing resources can prove a daunting enterprise with multiple requirements for endpoint devices, edge computing systems, and secure cloud connectivity. Individual pieces of the required solution exist but integrating them into a coordinated IoT application has left developers to face the complex tasks of implementing the service interfaces, communications methods, and security protocols required by IoT cloud providers.

As shown, a set of cloud-ready endpoint and edge computing products from Microchip Technology provides an off-the-shelf solution designed to connect easily with AWS IoT services and the AWS IoT Greengrass edge computing service. Developers can use Microchip's AWS qualified endpoint boards and a wireless system-on-module edge computing platform to provide near transparent connectivity to the AWS cloud and accelerate IoT network deployment.

Further reading

  1. Flash Memory with a Built-In MAC Address Can Really Help During Development

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

About this publisher

Digi-Key's North American Editors