Reduce Risk, Time to Market, and Cost During IoT Hardware Development

By Vanitha Ramaswami and David Walters, Partner Solutions Architects, IoT – AWS
By Tom Inoue, Business Development Engineer – Murata Electronics
By Gonzague Fraval, Product Marketing Connectivity Modules – Murata Electronics
By Matthew Salmanpour, Staff Product Marketing Engineer – Infineon/Cypress

Building Internet of Things (IoT) device hardware is complex, and development often exceeds 18 months from concept to production. Hardware developers are looking for guidance on design considerations and development trade-offs to decrease hardware design time and increase the value their connected devices can bring.

Every choice a hardware developer makes impacts the cost and time to market of an IoT device. Considerations include local and cloud connectivity, protocols, security, and software ecosystem. Hardware developers must choose a combination of hardware and software to address these considerations while optimizing for cost, decreasing time to market, and ultimately decreasing risk in an IoT project.

Amazon Web Services (AWS) works with IoT hardware and software ecosystem partners to simplify, accelerate, and optimize the IoT device development journey for hardware developers.

In this post, we will explore these hardware considerations and solutions offered by AWS Partners to address and minimize risk, time to market, and cost of IoT device development.

Figure 1 – The IoT device hardware and software ecosystem.

Getting Started

The primary purpose of an IoT device is to collect data, transform the data into useful information, and take action based on that information.

When starting a new IoT project, you should do a top-down analysis of what information is most important for your business and what decisions can be made with that information. After this value proposition is established, hardware developers should dive deep into how to collect the right data, and the technology stack necessary to collect that data.

Figure 2 – The IoT product value chain.

Design Considerations in Choosing a Processor

The first step to enable connectivity in an IoT device is to select the best fit microcontroller unit (MCU), system on chip (SoC), or module.

Processor choice is driven by the value proposition for the IoT project. A processor or MCU must have the IO, power optimization, and security to meet the requirements for the device to achieve its value proposition. For example, a device that must collect sensor data and is intended to be deployed in an agricultural field must have the ability to interface with sensors and run for long periods on battery power.

Selection is often influenced by design or business constraints, such as existing supplier and procurement relationships, code base, and engineering expertise. MCU vendors provide application middleware, libraries, and code examples to abstract complex functions. This includes power optimization, capacitive sensing, machine learning, and application protocol stacks that can be leveraged to decrease time to market.

Power optimization and battery lifetime must be considered for battery-operated IoT devices. Poor power optimization can leave battery-powered devices offline and require frequent battery changes by device operators.

Security is a critical aspect in IoT device design and must be designed in from the early stages of an IoT project. Security component decisions are based on the level of security required and the deployment model of the IoT device.

One of the most important security considerations is storing the cloud credentials. Options range from storing the credentials on a dedicated secure element chip, a Trusted Platform Module (TPM), or using a trusted execution environment (TEE).

Connectivity

IoT devices typically connect to the cloud using wireless technologies. Developers seek to balance wireless radio frequency (RF) requirements like power consumption, link budget, size, and cost with the available network infrastructure in deployed conditions.

The connectivity of choice may be predetermined based on business requirements and availability, such as adding Wi-Fi to a smart home device due to its ubiquity in customers’ homes. In cases where Wi-Fi is not desirable due to limited range of network infrastructure, hardware developers may need to choose between long range communication protocols such as LoRa, NB-IoT, LTE, or LTE CAT-M1.

Adding RF to any device is a complex task and requires consideration of:

• Component selection.
• Component tolerances and on-board parasitics impacting RF and power performance.
• Antenna selection, matching, and placement to avoid interference issues.
• Form factor.
• Engineering resources for design and testing.
• Production management and yield ratio consideration.
• Obtaining regulatory certifications such as FCC or CE.

RF module makers provide off-the-shelf solutions that have industry-standard interfaces, shielding, antennas, and regulatory approval. These solutions range from standalone transceivers to a full SoC.

Below are some of the wireless radio implementation options that are commonly used in IoT device design.

Figure 3 – Common wireless module design and implementations.

1. Standalone RF Transceiver: The RF transceiver is a separate chip, and the wireless software stack runs on the host processor along with the application code.
2. Wireless Network Processor: In this configuration, the wireless software stack, including TCP/IP, protocols, and TLS runs on a dedicated network processor that’s separate from the application processor.
3. Fully Integrated Wireless SoC: This architecture has the application and wireless radio subsystems integrated in a single SoC.

In the preceding figure, Standalone RF Transceivers and Wireless Network Processors require a host processor to host the user application. The host communicates with the Wireless Module through standard interfaces such as UART, SPI, SDIO, I2C or I2S.

This architecture is commonly known as “hosted” because a host processor is required to run the application and wireless drivers. Fully Integrated Wireless SoCs are commonly known as “hostless” because they run both the application and wireless stack, so a host application processor is not needed.

Murata and Infineon’s Wireless Solutions

Module makers provide undifferentiated heavy lifting with hardware accelerators such as connectivity modules. Murata is an AWS Partner that accelerates IoT hardware development by providing pre-certified wireless connectivity modules. These modules have various form factors, a broad range of microcontrollers, and different wireless interfaces such as Wi-Fi, Bluetooth, cellular, and LoRa.

Murata builds modules using the AIROC Wi-Fi/Bluetooth connectivity chipset from AWS Partner Infineon. The Murata 1DX hosts Infineon’s CYW4343W Single-Band Wi-Fi 4 (802.11n) + Dual-Mode Bluetooth 5.2 Combo SoC and the Murata 1GC hosts Infineon’s CYW43907 Wi-Fi 4 (802.11a/b/g/n) Connectivity Processor integrating an Arm Cortex-R4.

Murata builds hosted and hostless modules that meet the needs of both new IoT device designs and add connectivity to existing devices. For example, a new device design may implement a hostless module to reduce component selection and simplify the device’s design.

Hosted modules may be suited towards existing devices such as PLCs on a production process line that are now being connected to the cloud, or a device design that requires more flexibility. More information regarding Murata’s Wireless Connectivity modules can be found on the Murata website.

The following figures illustrate the pros and cons for both hosted and hostless modules from Murata.

Figure 4 – Murata’s 1GC is an example of a hostless module.

Murata 1LD is a fully integrated wireless SoC and is best fit for simple IoT applications that can fit within the resource requirements of STM32F412. If an IoT application requires more resources, then the 1LD module can be extended to use an external application processor as shown in Figure 5.

Figure 5 – Murata 1LD is an example of a hosted module.

Murata 1DX is a standalone RF transceiver module and supports a hosted configuration mode. This configuration provides great flexibility in terms of supporting a wide range of IoT applications. It can be used in both microcontroller-based IoT devices and microprocessor-based IoT devices (for example, high performance IoT applications).

Figure 6 – Murata 1DX integrates with a wide range of MPUs and MCUs and is designed for low-powered devices.

Security, Device Management, and Messaging

Design Considerations in IoT Firmware

Secure IoT device firmware implementation requires a combination of hardware and firmware capabilities.

Below are some of the key security components required in IoT device firmware:

Root of Trust (RoT)

The root-of-trust (RoT) provides an immutable identity. This involves providing secure storage for keys, code, and system data. There are various ways to implement a RoT that involve tradeoffs between risk and cost.

IoT device developers may choose a software-based RoT to reduce cost in the bill of materials. Developers may choose to use a hardware-based security solution when accounting for the risk and loss of customer trust that could arise from an insecure IoT device.

Secure Boot

This is a series of boot steps for a device that ensures the IoT device comes up in a known secure state. Secure boot requires a hardware-based RoT. In order to achieve secure boot, the device must first boot into a secure, immutable area in ROM.

The hash and signature of the application bootloader is first verified against a code-signing certificate, and then control is transferred over to the application bootloader. The application bootloader then performs another signature verification of the application before handing control over to the application.

Secure Provisioning and Onboarding to Cloud

Provisioning is a one-time setup to give IoT devices their identity and register them to the cloud. Trusted onboarding should be simple and efficient for end customers, and should enable large numbers of devices to be quickly provisioned with unique credentials.

Security attributes of the onboarding process assure the network is not put at risk as new IoT devices are added to it. For example, secure provisioning of PSoC 64 MCUs from Infineon are provided through Arrow Electronics’ secure programming and provisioning services. Alternatively, for pre-provisioned, secure element-based design, AWS IoT Multi Account Registration, Just in Time Provisioning, or Just in Time Registration can be used.

Remote Monitoring

The firmware on the device needs to report metrics to the cloud so the cloud can monitor devices for abnormal behavior. A device administrator can define a device’s normal behavior (security profile) in the cloud and the thresholds for reporting a security issue. For example, the device monitoring service will report an issue if a device sends more than X bytes of data to an endpoint or connects using an unknown IP address.

AWS IoT Device Defender continuously audits your IoT configurations and monitors your IoT devices to make sure they aren’t deviating from security best practices defined by the device administrator.

Remote Attestation

Attestation is the process in which the software state of an IoT device is cryptographically recorded and provided to a remote endpoint. The attestation server can use this cryptographic measure to prove the device is running in a known secure state.

Remote attestation can be performed after the remote monitoring service detects some kind of anomaly in the device’s security profile. If the attestation fails, the device can be put into a “normal” operating state, put into a “quarantined” state for further evaluation and remediation, or removed from the network and not allowed to connect.

Over-the-air (OTA) and Device Management

IoT devices in the field require patching for security vulnerabilities. Customers expect new features to be enabled on their connected devices. Over-the-air (OTA) updates are a critical feature in an IoT device firmware implementation and cloud management solution. With AWS IoT Device Management, you can securely register, organize, monitor, and remotely manage IoT devices at scale.

AWS IoT Device Management allows you to register your connected devices individually or in bulk, and manage permissions so devices remain secure. You can also organize your devices, monitor, and troubleshoot device functionality, query the state of any IoT device in your fleet, and send firmware updates OTA.

AWS IoT Message Security

IoT device connections to AWS IoT use X.509 certificates and AWS Signature Version 4 for authentication. Device communications are secured by TLS version 1.2. Depending on the IoT device application profile, there are many different options for storing the AWS credentials, ranging from software-based solutions to tamper-proof, hardware-based secure elements. A custom authentication workflow simplifies connecting brownfield devices to the IoT core.

Why AWS for IoT Product Development

An effective IoT platform should reduce the complexities in deployment, connectivity, and implementation of IoT solutions. They must deliver capabilities to orchestrate the movement of data between IoT devices and IoT applications.

Developing and maintaining the infrastructure for a scalable IoT platform is a challenge for any organization building it from scratch. AWS IoT addresses this challenge by providing fully managed services that can scale to billions of devices and trillions of messages, and provides a defined connectivity and data interface for IoT devices.

For a successful IoT system implementation, organizations must manage and control a wide variety of standards for connectivity such as Wi-Fi, Bluetooth Low Energy (BLE), Low Power Wide Area Network (LPWAN) that includes LoRa, NBIoT, LTE-M, and Sigfox, and even satellite communications.

In today’s fragmented IoT connectivity environment, the ability to manage multi-protocol, multi-layer, and multi-network connection is critical for a successful IoT system implementation. AWS IoT and the AWS Partner ecosystem simplifies the IoT device developer journey by bringing together these elements.

Figure 7 – Essential IoT platform capabilities.

AWS IoT Reference Integrations

At the core of the AWS IoT device software infrastructure for MCUs is FreeRTOS, the market leading, real-time operating system for microcontrollers. AWS began stewarding FreeRTOS in 2017, and has since performed pre-integrations of IoT libraries with RTOS and made them available on a wide range of silicon platforms.

FreeRTOS IoT libraries provide connectivity, security, MQTT messaging, and OTA update functionality suitable for building microcontroller-based IoT devices.

AWS Reference Integrations are “pre-integrated” FreeRTOS projects for a specific hardware configuration outlined in a development kit or reference design kit and are available for a wide range of silicon chipsets. With AWS support for FreeRTOS kernel ports for next-generation hardware architectures, a simplified MIT licensing model with long-term support (LTS) for IoT libraries, no lock-in, and professional incidence response, customers can reduce the development cost, time, complexity and risk in selecting an RTOS for next-generation connected products.

The AWS Reference Integrations are qualified by AWS Partners and listed in the AWS Partner Device Catalog to make it is easier to find qualified IoT device hardware that works with AWS IoT services.

Figure 8 – AWS Reference Integrations and AWS IoT services.

Two of the evaluation kits that Infineon qualified for FreeRTOS are shown in Figure 9 below, including the PSoC-64 Standard Secure Wi-Fi Bluetooth Pioneer Kit for AWS and CYW943907AEVAL1F Kit.

Devices qualified by AWS Partners work with AWS IoT out-of-the-box, allowing IoT hardware developers to focus on delivering the value proposition that is important to their business.

Figure 9 – AWS IoT Reference Integrations from Infineon that are qualified for FreeRTOS.

Conclusion

Getting started building an IoT device can be a daunting task as developers grapple with wireless radio frequency, microcontrollers, connectivity, protocol stacks, security, and device management. All of these considerations can affect cost, both non-recurring engineering and bill of materials, time to market, manufacturability, quality, and maintainability.

AWS, Infineon, and Murata have worked together to make IoT device development easier on developers, so they can concentrate on creating engaging and compelling solutions and applications that change how people interact with devices.

The AWS IoT device ecosystem is rapidly evolving and all stakeholders are working to simplify the technical complexity necessary to deliver IoT solutions. To learn more about AWS IoT Reference Integrations, see the AWS Partner Device Catalog.

* AWS works with leading silicon partners to integrate the IoT device software stack (FreeRTOS and IoT libraries). The design choices on wireless connectivity and MCUs are silicon partner agnostic, and the partner names mentioned in this post are for illustration purposes only. These partners also helped us write the post.

Additional References

1. Smart Product Solutions to accelerate connected products development using AWS IoT services.
2. Murata’s AWS IoT Core Solutions site for more information about Murata’s AWS qualified modules.
3. FreeRTOS and AWS IoT libraries.