Internet of Things 101
This section provides an Internet of Things 101, including a brief overview, a discussion of IoT Sensors and Actuators, IoT Architecture, IoT Protocol Layers, and IoT Connectivity.
- 1 Introduction
- 2 IoT Architecture
- 3 IoT Sensors and Actuators
- 4 IoT Protocol Layers
- 5 IoT Connectivity
- 6 Over-the-Air Updates
- 7 AIoT AppStores
- 8 Expert Opinion: Nik Willetts, President & CEO of TM Forum
- 9 Authors and Contributors
The Internet of Things (IoT) describes the concept of connecting physical objects (a.k.a. the "Things"), which are embedded with sensors and actuators over the Internet. This connection can either be direct between physical objects or between physical objects and a back-end data center (cloud or on-premises). Surprisingly, this connectivity will often make use of Internet protocols (IP, UDP, etc.) but use protected enterprise networks instead of the open Internet. The IoT has emerged as a concept following earlier approaches such as M2M (Machine-to-Machine communication) and Telematics, usually adding a richer set of digital services. Industrial Internet of Things (IIoT) refers to industrial IoT applications. Edge computing is quickly emerging as field-based computing capacity closer to the physical objects and as a counterpart to centralized cloud computing. The boundaries between Edge computing, IoT, and embedded computing can sometimes be blurry. The term IoT Edge Node is usually used to refer to compute nodes that are embedded with physical objects in the field. Other types of edge equipment can be independent of physical assets, e.g., local data centers.
An IoT architecture must support the creation of a bridge between physical assets in the field and a cloud or on-premises backend. This first challenge is the integration of the actual physical asset (or product, appliance, equipment, etc.). This can usually be done either as part of a line-fit process during manufacturing or as a retrofit process (especially for legacy assets). Asset integration addresses issues such as power supply, ruggedization, antenna positioning, etc.
On - or close to - the asset, the IoT architecture usually positions an edge layer. The first elements here are sensors or actuators (some might argue that this is part of the asset, not part of the edge, which can also be a valid design). In addition, we often find edge applications (e.g., preprocessing of sensor data) and edge AI/Asset Intelligence (e.g., sensor data fusion and autonomous control). Modern edge platforms provide a runtime for local compute resources, as well as a gateway functionality for remote communication.
In the backend, AIoT backend applications and backend AI/swarm intelligence operate on the data received from assets in the field. This is often supported by IoT/IIoT-specific middleware, provided as Platform-as-a-Service (PaaS). Normal Cloud-PaaS services as well as Infrastructure-as-a-Service (IaaS) are required as the foundation.
Not to be underestimated is the need to integrate with existing Enterprise Applications: most IoT projects also have an EAI element (Enterprise Application Integration).
IoT Sensors and Actuators
Most IoT systems benefit from the use of sensors and actuators to acquire data from the field and control the behavior of assets in the field. Typical sensor categories include image and video, acoustics and noise, temperature, moisture, light, presence and proximity, motion, gyroscope (rotation and velocity), water level, and chemicals. Typical actuators include motors (servo, stepper, DC), linear actuators, relays (electric switches), and solenoids (electromagnets).
IoT Protocol Layers
Connectivity between the IoT edge nodes and the backend requires different protocol layers. Similar to the postal services with letters and parcels, these protocol layers are responsible for packaging, addressing and routing data in various forms. At the top layers, application-specific protocols are responsible for supporting information exchange at the business level. Lower-level transport protocol layers are responsible for the transfer of anonymous data packages (business-level data are often split into smaller packages for transportation purposes, and then reassembled on the receiver side). The most well-known protocol is TCP/IP, which is the standard protocol on the Internet. IoT communication networks must establish a physical data link between the different nodes involved. This happens using a variety of standardized and proprietary protocols, especially for wireless communication.
Especially for mobile physical assets, it is important to find suitable connectivity solutions. These solutions usually differ greatly by a number of factors, including cost, regional availability and range, bandwidth and latency, energy efficiency
Different services, including cellular, short-range and long-range services are available and can also be combined. A typical pattern is to use a short-range protocol to connect mobile edge nodes with a central (mobile or stationary) gateway, which then establishes wide-area connectivity.
Another key capability of modern IoT systems is to perform updates Over-the-Air (OTA). OTA allows us to update Software (SOTA) or Firmware (FOTA) on a remote asset, e.g., via WLAN or mobile networks. OTA update mechanisms are now a common feature for almost all smartphones, tablets, and similar devices. In automotive systems, some early adopters, such as Tesla, have been pioneering OTA. Currently, most other OEMs have started to adopt OTA updates as well.
OTA Updates are a key capability of any AIoT product since they allow software deployed on the asset to evolve over time, gradually rolling out new functionality. If combined with an app store, OTA updates allow tapping into a rich developer community, which can add new functionalities and apps in many creative ways that sometimes have not been foreseen by the asset manufacturer and platform operator.
The figure preceding shows a typical OTA architecture for AIoT products. It all starts with the authoring (1) of new versions of software or firmware. This process can include deliveries from suppliers and sub-suppliers, which need to be integrated, tested and bundled. Next, the distribution component (2) is responsible for making the updates available in different regions, and coordinating the update campaigns. Finally, on-asset deployment (3) is responsible for ensuring that the update is reaching its target.
Because OTA is becoming such an important feature of IoT and AIoT systems, a number of standards are emerging in this space. ISO 24089 aims to provide a standard architecture for OTA updates for road vehicles. The OMA DM protocol provides an integrated and extensible framework for OTA management. A number of existing standards specifically describe how to implement delta updates for firmware, thus dramatically reducing the amount of data to be transferred to each device individually.
The distribution component of an OTA platform is typically responsible for package preparation and campaign management, as well as tracking and reporting. Campaign management can rely on complex rules to control updates to large amounts of devices or assets. For example, rules can help ensure that assets such as road vehicles are not updated in critical situations (e.g., prevent updates while driving, or require the asset to not be in a remote area in case of update problems).
The typical components of the distribution tier include:
- Repository for firmware/software packages and planning data
- Asset inventory and update tracking/reporting
- Certificate & Signature Management
Most OTA platforms include a dedicated update agent, which receives software/firmware updates from the remote distribution tier in the backend. Key functionality of the update agent typically include Download Management, Security Management (including management and validation of security certificates and signatures), and distribution of the incoming updates to the target compute nodes.
The local distribution from the update agent to the final target system can occur via a number of different local bus systems, including CAN, LIN, MOST, FlexRay, Ethernet, etc.
The actual target compute node can be a lower-level controller, e.g., an embedded system such as an Engine Control Unit (ECU) or a Transmission Control Unit (TCU) in automotive or any other kind of embedded microcontroller (MCU) or microprocessor (MPU). Alternatively, it can be a high-end edge computer with its own local storage, full operating systems, etc. For lower-level controllers, FOTA (firmware-over-the-air) manages the process of updating the combined embedded OS and embedded applications as a single image (or applying a delta-update strategy to minimize bandwidth), while for higher-level edge computers, SOTA (software-over-the-air) supports more targeted updates of individual applications.
A particularly interesting application of OTA are AppStores. Pioneered by Apple and Google in the smartphone space, they have proven to offer tremendous value not only in terms of easy-to-use application management, but also with regards to opening up the smartphone platform for external development partners. AppStores for smartphones have unlocked the huge creative potential of millions of developers who are now developing apps for these AppStores, sharing revenues with platform operators.
It seems logical to apply the same principle to other areas, be it AppStores for smart kitchen appliances or electric vehicles. However, there are also some limiting factors. First, with complex and safety-critical systems such as vehicles or heavy equipment, being able to protect them from abuse by potentially malicious external applications is key, and this is not an easy feat. Second, these products usually have a significantly lower number of instances in the field than the smartphone companies. If we are looking at automotive specifically, there is a very high level of fragmentation because almost every vehicle platform is different. This fragmentation means that developers would have an even smaller installed base and high integration costs, making it harder to innovate and create profits.
Achim Nonnenmacher, expert for Software-defined Vehicle at Bosch knows: In order to significantly accelerate innovation cycles in vehicles from “many years” today to “days or weeks” in the future, vehicle manufacturers and tier 1s need to collaborate on open, non-differentiating software and APIs. This collaboration will help reduce fragmentation, will lower the very high integration effort we see today, and free software engineers to work on differentiating and innovative new features without fearing lock-ins.
The following is looking at two examples. First, an OEM with closed AppStore for his own vehicle apps. Second, an OEM with an open AppStore for partner vehicle apps.
Example 1: OEM with Closed AppStore
A first step toward an AppStore for vehicles and other physical assets is to only allow apps that are developed directly by the OEM and tier 1 suppliers. Here, we have to differentiate between pure in-car apps (e.g., a new mood control for interior lighting) vs. composite apps with external components, e.g., a smartphone integration.
In the example shown below, a car manufacturer provides a composite app, combining his own AppStore with the smartphone AppStores of Apple, Google, and the like. This type of composite app architecture is required, especially for cases where the app will run partly on the smartphone, partly on the car, and partly in the cloud backend of the OEM.
For example, a user might download a new car app in the smartphone app store. The first time this app is contacting the cloud backend of the OEM, it will determine that a new app component must be installed on the customer's car as well. This could be done automatically and in the background so that the customer is not aware that they are actually dealing with two AppStores.
Once both apps are installed (the one on the smartphone, and the one on the car), the user can then use the apps as one seamlessly integrated app. For example, this could be a new app similar to the Dog Mode app recently introduced by Tesla, which allows a user to control certain features for a dog in the car via his smartphone, e.g., controlling windows and cooling remotely.
This is an interesting scenario for a number of reasons. First, OEMs typically tend to prefer solutions which do not rely on smartphones, since this means losing control over the user. This is why platforms such as Android Automotive are becoming popular, supporting native apps in the car and integrating only with the car's head unit, and not the smartphone. However, by focusing only on on-car apps, the OEM loses the opportunity for a new customer experience, e.g., by enabling the customer to remotely interact with the car and the dog in it while shopping.
Second, control over the apps in the car app store is critical -- from a business -- but also from a security perspective. In this scenario, the assumption is that apps in the vehicle app store can only be provided by the OEM or tier 1s. This means that the requirements for the tightness of the sandbox running the applications are not as high, since the OEM has full control over the QA (Quality Assurance) cycle of the app.
Example 2: OEM with Open AppStore
In this second example, the OEM is actually opening up the car AppStore for external development partners. Let us say the relatively unknown start-up ACME AppDeveloper wants to develop an advanced Dog Mode app, which is utilizing the in-vehicle camera and advanced AI to monitor the dog in the car. Depending on the learning of the AI about the mood and behavior of the dog, different actions can be taken, e.g., modifying the window position, changing the ambient environment in the car, or notifying the owner. Since the OEM does not have an active development partnership with ACME AppDeveloper and similar developers, he has to ensure the following:
- Provide a protected sandbox into which partner applications can be deployed
- The OEM has to ensure that apps in the sandbox only interact with the car environment via a well-defined set of APIs.
- Establish a corresponding safety system that ensures that the car is always in a safe state.
- Provide development partners with APIs for sensors such as the in-vehicle camera, as well as selected actuators such as car window control or car ambient control
- Provide OTA-based deployment capabilities for partner apps
- Ensure that development partners can not only deploy specific software but also AI-enabled components
In this scenario, this has been ensured. Therefore the ACME AppDeveloper can register his app with the OEM, which in turn will ensure that it is made available to car owners. Once installed, the new app will not communicate with the OEM cloud backend but rather with the ACME cloud backend, which might also use swarm intelligence to further enhance the advanced Dog Mode app.
Expert Opinion: Nik Willetts, President & CEO of TM Forum
In the following interview with Nik Willetts, President & CEO of TM Forum, different aspects of IoT connectivity and related topics are addressed from the perspective of the telecommunications industry.
Dirk: Nick, thanks for joining us. Tell us a little bit more about TM Forum. What are you doing? Where are your members, and why is it relevant for AIoT?
Nik: Thanks, Dirk. TM Forum is a global consortium of over 800 companies all around the world, largely in the telecoms industry. And that includes the world's leading service providers, software vendors, hyperscalers, system integrators, consultants, and start-up companies. Our purpose is to drive the industry forward through collaboration. Right now, we're focused on transforming the industry’s software and operating models to help deliver the agility, time to market and customer experience to unlock growth, at the right cost point. The telcos need to survive in a hypercompetitive market and they foresee huge growth opportunities emerging over the next decade.
We have been at the forefront for over 30 years of different waves of industry transformation. The current wave is the most fundamental yet, because for connectivity service providers to thrive in the decade ahead they need to digitally transform their business model, operating model and technology stacks. Through our innovation programs, such as our Catalyst projects, we have been exploring the applications of the IoT and combining that with new forms of connectivity. Most recently, we’ve focused on the application of IoT in combination with AI, edge computation and 5G connectivity in those contexts as well.
So why do we have an interest in AIoT? We believe the next wave of this digital revolution depends on a combination of technologies: elastic connectivity, edge computing, AI, and IoT. This perfect storm of technologies can unleash the true potential of Industry 4.0 and underpin the next wave of digital revolution for society. We know that Machine Learning and Artificial Intelligence will become ubiquitous across those technologies down to the device level. These technologies are going to come from an ecosystem of partners, with expectations over ease of integration, interoperability, and support for new levels of flexibility, agility and new business models. We see that as TM Forum's core competency, in driving collaboration, developing standards, and ensuring that the telecom industry shows up with the right solutions and products, and we want to contribute to making the AIoT vision a reality.
Dirk: The IoT part in this is not new to telcos. We had M2M, we had telematics, we had IoT, and now we have AIoT. So in the bigger scheme of things, how important is this to the telcos compared to normal communication and the telephone networks, and what are the key market trends?
Nik: You're right that mobile technology has been an important element in the first generation of IoT for some time. Today the global market for IoT connectivity is worth approximately $8 billion – not significant when you consider that the services market for telecoms is about $1.6 trillion. However, we see growth both in connectivity revenues for IoT - somewhere between 5% and 7% per annum, and expect the pandemic to accelerate that growth as enterprises bring forward their digital transformation plans.
I think it is fair to say that the telecom industry has been, at best, a distant partner so far on the IoT journey. We only see a handful of telecom providers with significant IoT divisions, and the immaturity of devices and connectivity technologies have held back deployments. We see significant opportunities for collaboration, between device manufacturers, connectivity providers and end-users. For telecoms providers, the 5G enterprise market is worth at least $700 billion in additional revenue, and much of that will come from use cases which leverage Ml/AI and IoT. It is now critical for connectivity providers to recognize and work much more closely with end customers, OEMs and software companies. It is not just a case of providing standalone connectivity anymore – we need an ecosystem of technologies to unlock this value.
Dirk: If I put myself in the shoes of an OEM building new, smart, connected products, what can I expect from a telco in terms of support for my AIoT deployment, and what do I have to look out for?
Nik: With 5G, many leading telco companies are already experimenting with customers. We see pilot projects that span every industry, from fish farming in the Nordics through to health care in the UK. Almost every sizable telecom operator now has deployments and real-world proof of concept projects underway, looking at what's needed from their capabilities and technologies. TM Forum is involved in many of those, including an ongoing project in the manufacturing sector deploying our IoT toolkit and common data model to help manage the friction between Telco, IoT, Cloud and vertical applications. Through these pilots, we see several challenges to navigate.
The first challenge is what we call Connectivity-as-a-Service — recognizing that for more sophisticated uses of IoT and more advanced devices, you have different connectivity needs at different times and in different locations, and will need to adjust to the available connectivity technologies in that location e.g., 4G, 5G or WiFi. New IoT devices also need to be managed and updated with new software over the air. Those updates, as we already see increasingly more software on cars, have greater bandwidth requirements for short periods of time, along with special requirements over security, latency and privacy. Connectivity has to be flexible and autonomous to support the needs of the IoT device and the required experience.
The second challenge concerns the combination of connectivity with edge computing in regard to rapid AI decision-making. We see AIoT solutions as utilising a combination of intelligence on the device, nearby (at the edge), and centrally in the cloud. Addressing this with a secure, low-latency solution will be key.
The final piece, which we also see as an opportunity, is that security needs and risks are growing. As a regulated industry with substantial cybersecurity experience and control of local networks, telecom operators can provide unique security capabilities, particularly where the processing and use of data can be controlled within a telecom provider's network environment, such as through to an edge computing solution.
Beyond these services, it is also important to note what telcos can offer AIoT use cases. As a global subscription service industry, experience and capabilities such as billing right down to micro-transactions, localization, local market knowledge and skilled workforces, and handling of regulations in local markets are all potentially valuable capabilities. It is important to remember that telcos have global-scale experience delivering complex services and as we have seen in the last 18 months, they are exceptionally resilient to even exceptional levels of demand.
Dirk: You once said that we need interoperable, autonomous, and open digital ecosystems. So what will need to happen in the telecoms industry to actually achieve this?
Nik: We believe that a new level of complexity is now coming into play as we combine and leverage new technologies for more sophisticated and critical use cases. The first and perhaps the easiest path to manage this is what we call closed ecosystems. That is where you have a dominant player doing a lot of the complexity and handling a lot of the integration. We have seen that in our consumer businesses through the evolution of devices from companies such as Apple, for example, which bring you into a comfortable ecosystem, but ultimately with significant lock-ins as a consumer.
Lock-in does not work when we get to the complexities of industrial applications based on IoT – indeed it can directly block innovation, prohibiting you from embracing newer technologies, experimenting with others, and raising concerns of customers being held to ransom or, as we have seen in the telecoms industry, being impacted overnight by costly geopolitical decisions.
So we fundamentally believe that the healthy, sustainable path when it comes to the next generation of industrial applications, is to build open ecosystems. But that comes with its own set of challenges compared to closed ecosystems. Integration, interoperability and transparency are some of the most significant barriers, and to address those barriers we need open standards. If you don't have the right standards, if you don't have a common language, definitions, metrics, data models APIs and so on, building open solutions becomes very difficult. That is why our members are creating Open Digital Architecture to help provide the foundation for open, interoperable and autonomous ecosystems.
So interoperability is key. Fortunately, that is much, much easier today than ever before. Thanks to advances in software engineering, and the recognition across industries of the importance of collaboration and standards, it’s becoming practical to deliver the level of interoperability and resilience required for open ecosystems to thrive.
All of this becomes even more important when we think about the use of AI across those ecosystems. There's the initial integration of AI across a complex ecosystem of technologies. Then there's the complexity and cost of operating those technologies. And that's where AI really has a role to play again, not just at the device level or at a single technology level but actually across devices and technologies to ensure that the right outcome is achieved for the customer. To do that, we need to design standards today that are ready for AI use cases of tomorrow. That will only be possible if all embrace collaboration to deliver the required standards faster than ever.
Authors and Contributors