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.
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-premise 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:
- 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). Or, 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 smart phone 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 towards an AppStore for vehicles and other physical assets is to only allow apps which 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 smart phone 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 likes. This type of composite app architecture is required especially for cases where the app will run partly on the smart phone, 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 customers car as well. This could be done automatically and in the background so that the customer is not aware that he is actually dealing with two AppStores.
Once both apps are installed (the one on the smart phone, 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 are not relying on smart phones, since this means losing control over the user. This is why platforms like Android Automotive are becoming popular, which are supporting native apps in the car, only integrating with the car`s head unit, but not the smart phone. 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 being shopping.
Second, control over the apps in the car app store is critical - from a business, but as well as 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 which 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.
Authors and Contributors