Scaling for Complexity – Architecting for Performant Embedded Devices at the Edge – Part 1

The following is a survey paper, published and presented to the Academic Congress of Embedded World 2022 at Nuremberg, Germany on June 21st 2022.

Abstract

Embedded edge devices with multi-sensor data sources are proliferating at an accelerating rate. Devices must be designed, manufactured, installed, connected, and controlled through seven distinct logical layers to securely connect and interact with complementary cloud-based and edge-based components to deliver business value. These Internet of Things (IoT) applications must gather, process, analyze, and act on data generated by the connected devices. In this paper, you will discover how to make informed tradeoffs with end-to-end architecture challenges based upon your business and performance context. We will discuss the best practices and relations between the Design and Manufacturing, Edge, Provisioning, Communication, Ingestion, Analytics, and Application layers and how a properly designed edge architecture allows complex scaling scenarios.

Proliferation of Devices
More companies than ever are integrating connected devices and discovering new ways to use and manage business data. Companies that once looked at IoT as a theoretical concept today have made it a high priority.

Every second, hundreds of devices are being connected to the Internet for the first time. That’s 10 million new devices every day, and a clear signal the demand for IoT is skyrocketing. As reports forecast, the number of IoT connected devices will jump by double digits this year alone. That is nearly double the growth seen in 2021.

Despite the fears that economic slowdown would delay business adoption of IoT solutions, the markets are growing by leaps and bounds. Consider:

• In 2025, as many as 150,000 IoT devices will be connecting to the internet every minute.
• The number of cellular IoT connections is expected to reach 3.5 billion in 2023. Artificial Intelligence (AI), machine learning, and real-time data processes delivered by IoT solutions are driving cellular IoT devices boom.
• Smart factories in North America are expected to be worth more than $500 billion this year. The manufacturing process is being revolutionized with connected devices driving substantial productivity.
• Businesses could spend up to $15 trillion in IoT by 2025. Businesses are well aware of IoT devices’ potential to add value to their business and are investing heavily in technology.

Performant Architecture Model
With this acceleration of growth, it becomes even more important that IoT devices must be designed, manufactured, installed, connected, and controlled through the following seven distinct logical layers to securely connect and interact with complementary cloud and edge based components to deliver business value.

These layers are derived from a best practices outcome of architecting performant workloads, hence a Performant Architecture Model. These layers are very similar to the Open Systems Interconnection (OSI) model Networking Model. The OSI model is a conceptual model that describes the universal standard of communication functions of a telecommunication system or computing system, without any regard to the system’s underlying internal technology and specific protocol suites.

This layered protocol approach can be applied to the IoT architecture stack as well. Where each layer can be modified as needed to achieve a specific level of service to the layer below it. Therefore, the objective is the interoperability of all diverse communication systems containing standard communication protocols, through the encapsulation and de-encapsulation of data, for all networked communication. In the OSI reference model, the communications between a computing system are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. Each intermediate layer serves a class of functionality to the layer above it and is served by the layer below it.

The IoT OSI Model
If there were an IoT OSI model, it may look something like the following, where the ultimate goal is to drive business value through IoT. After all, no customer ever approaches a vendor and asks to buy “IoT”, nor would an IoT provider sell just “IoT”. At AWS, we support our customers business needs by asking them a very fundamental question.

If you knew the state of every thing and could reason on top of that data….  what [business] problems would you solve?

Our mission is to make sure that you can know the state of every thing, all of your devices, and that you CAN reason on top of that data, so that you can truly solve the business problems.

Therefore, if we group the functionalities provided in the Performant Architecture Model and translate it into the OSI Model, what we get is the concept of an IoT OSI Model. With this model we can substitute the layers as necessary to obtain the best business outcomes and value whilst still maintaining a very performant architecture. Further, we can group some of the OSI related layers into larger constructs to aggregate more business value.

At the top we would have People and Processes and the Applications that they use to derive the Business Value in one group. This group would consist of Layer 6 – where custom Applications would need to be created for presenting

specific Thing data. It would also include Layer 7 – where the transformational decisions for the business would be made based on the Thing Applications and Data.

Next would be the Data Ingestion and Analysis, which is traditionally referred to as Big Data. This would consist of Layer 4 – which is responsible for the ingestion of the Thing data and harvesting specific trends. These trends are further evaluated at Layer 5 – which is responsible for various reporting, mining and extraction, and even running Machine Learning models against the stored data.

Below that construct is the Global Infrastructure of the business, also known as Layer 3. For simplicity we consider that to be the Cloud. That cloud infrastructure can be in the form of a public cloud, a private cloud, a hybrid, or managed. It can even be in the form of on-premise infrastructure.

Lastly, we have the Edge construct, consisting of the Connectivity and Edge Computing at Layer 2, and the actual Things at Layer 1, which includes various devices, sensors, controllers, etc.

Together these four constructs help to balance a Well Architected Framework for IoT implementations. The framework consists of Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization “pillars”

The Pillars of the AWS Well Architected Framework
The AWS Well Architected Framework helps you understand the pros and cons of the decisions you make when building systems on AWS. Using the Framework allows you to learn architectural best practices for designing and operating reliable, secure, efficient, and cost-effective systems in the cloud. The Framework provides a way for you to consistently measure your architectures against best practices and identify areas for improvement. We believe that having well-architected systems greatly increases the likelihood of business success.

In the context of IoT, we focus on how to design, deploy, and architect your IoT workloads in the AWS Cloud. To implement a well-architected IoT application, you must follow well-architected principles, starting from the procurement of connected physical assets (Things) to the eventual decommissioning of those same assets in a secure, reliable, and automated fashion. In addition to AWS Cloud best practices, the framework also articulates the impact, considerations, and recommendations for connecting physical assets to the internet.

When architecting technology solutions, you must make informed tradeoffs between pillars based upon your business context. For IoT workloads, AWS provides multiple services that allow you to design robust architectures for your applications. Internet of Things (IoT) applications are composed of many devices (or things) that securely connect and interact with complementary edge-based and cloud-based components to deliver business value. IoT applications

gather, process, analyze, and act on data generated by connected devices. As mentioned before, there are seven distinct logical layers to consider when building an IoT workload.

Design and Manufacturing Layer
The design and manufacturing layer consists of product conceptualization, business and technical requirements gathering, prototyping, module and product layout and design, component sourcing, and manufacturing. Decisions made in each phase impact the next logical layers of the IoT workload described below. For example, some IoT device creators prefer to have a common firmware image burned and tested by the contract manufacturer. This decision will partly determine what steps are required during the Provisioning layer.

You may go a step further and write a unique certificate and private key to each device during manufacturing. This decision can impact the Communications layer, since the type of credential can impact the subsequent selection of network protocols. If the credential never expires it can simplify the Communications and Provisioning layers at the possible expense of increased data loss risk due to compromise of the issuing Certificate Authority.

Edge Layer
The edge layer of your IoT workload consists of the physical hardware of your devices, the embedded operating system that manages the processes on your device, and the device firmware, which is the software and instructions programmed onto your IoT devices. The edge is responsible for sensing and acting on other peripheral devices. Common use cases are reading sensors connected to an edge device, or changing the state of a peripheral based on a user action, such as turning on a light when a motion sensor is activated.

AWS IoT Device SDKs simplify using AWS IoT Core with your devices and applications with an API compatible to your programming language or platform.

Amazon FreeRTOS is a real time operating system for microcontrollers that lets you program small, low power, edge devices while leveraging memory-efficient, secure, embedded libraries.

AWS IoT Greengrass is a software component that runs on the Linux or Windows Operating System on your IoT devices. AWS IoT Greengrass allows you to run MQTT local routing between devices, data caching, AWS IoT shadow sync, local AWS Lambda functions, and machine learning algorithms.

Part 2 – Scaling for Complexity – Architecting for Performant Embedded Devices at the Edge – Part 2

About the author

Channa Samynathan

Channa is a Specialist Solutions Architect, working on IoT and Robotics at Amazon Web Services (AWS) and part of the internal Technical Field Community for Telecom and IoT. Prior to AWS Channa has had an extensive career in Telecom, working with Tier 1 carriers around the world implementing various voice and messaging products for their SS7 networks. At AWS Channa works with Enterprise customers, and has built and presented IoT projects for re:Invent (2019/2020/2021), re:Inforce(2021/2022), Embedded World (2021/2022), and Hannover Messe (2021).