Internet of Things 101: Difference between revisions

Line 96: Line 96:


Once both apps are installed (the one on the smart phone, and the one on the car), the user can use the apps as one seamlessly integrated app. For example, this could be a new app similiar to the Dog Mode app recently introduced by Tesla, which allows a user to control certain features in the car (e.g. opening the windows a little) for a dog in the car via his smart phone.
Once both apps are installed (the one on the smart phone, and the one on the car), the user can use the apps as one seamlessly integrated app. For example, this could be a new app similiar to the Dog Mode app recently introduced by Tesla, which allows a user to control certain features in the car (e.g. opening the windows a little) for a dog in the car via his smart phone.
In this scenario, protection of the car against potentially malicious behavior from the app on the car is not required, since the OEM has full control over the QA (Quality Assurance) cycle of the app. This will become highly relevant in the next example.


[[File:0.3.1 OTA OEM AppStore.png|800px|frameless|center|OEM with closed AppStore for vehicle apps]]
[[File:0.3.1 OTA OEM AppStore.png|800px|frameless|center|OEM with closed AppStore for vehicle apps]]

Revision as of 23:33, 11 September 2021

More...More...More...More...More...More...IoT 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.

Introduction

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 directly between physical objects, or between physical objects and a back-end data center (cloud or on-premises). Surprisingly often, this connectivity will make use of Internet protocols (IP, UDP, etc.), but use protected enterprise networks instead of the open Internet. 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 the field-based compute 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 which are embedded with physical objects in the field. Other types of edge equipment can be independent of physical assets, e.g. local data centers.

IoT Architecture

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 deals with issues such as power supply, ruggedization, antenna positioning, etc.

On - or close to - the asset, the IoT architecture is usually positioning 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. pre-processing 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 the assets in the field. This is often suported 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 Architecture

IoT Sensors and Actuators

Most IoT system benefit from the use of sensors and actuators to acquire data from the field, and control the behavior of the 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 Sensors and Actuators

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 on the business level. Lower-level transport protocol layers are responsible for the transfer of anonymous data packages (business level data is often split into smaller packages for transportation purposed, and then re-assembled on the receiver side). The most well-known such protocol is TCP/IP, which is the standard protocol in 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.

IoT Protocol Layers

IoT Connectivity

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 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 the wide-area connectivity.

AIoT Network Architecture

Over-the-Air Updates

Another key capability of modern IoT systems is to perform updates Over-the-Air (OTA). OTA allows 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 smart phones, tablets, and similar devices. In automotive, some early adopters like Tesla have been pioneering OTA. Currently most other OEMs have started to adopt OTA updates as well.

A great example for the use of OTA in automotive is the introduction of the Tesla 'Dog Mode', which aims to keep owners' pets at a comfortable temperature when left unattended. This feature is made available to Tesla owners on demand via OTA.

OTA Updates are a key capability of any AIoT product, since they allow to evolve the software deployed on the asset over time, gradually rolling out new functionality. If combined with an app store, OTA updates allow to tap into a rich developer community, which can add new functionalities and apps in many creative ways which sometimes have not been foreseen by the asset manufacturer and platform operator.

OTA Updates - Overview

The figure above 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, the 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 describe specifically how to implement delta-updates for firmware, thus dramatically reducing the amount of data to be transferred to each device individually.

Distribution

The distribution component of an OTA platform must 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 ensuring 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, etc.).

OTA Updates - Distribution

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

Deployment

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.

OTA Updates - Deployment

The local distribution from the update agent to the final target system can happen via a number of different local bus systems, including CAN, LIN, MOST, FlexRay, Ethernet, etc.

The actual target compute node can either be a lower-level controller (e.g. an ECU or TCU), or a high-end edge computer with own local storage, etc. For lower-level controllers, FOTA (firmware-over-the-air) is managing the process of updating the combined embedded OS and 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) is supporting more targeted updates of individual applications.

AIoT AppStores

A particularly interesting application of OTA are AppStores. Pioneered by Apple and Google in the Smart Phone 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 smart phone platform for external development partners. AppStores for smart phone have unlocked the huge creative potential from millions of developers who are now developing apps for these AppStores, sharing revenues with the 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, these examples have significantly lower number of physical products in the field than the smart phone companies. This means that the potential for profit via AppStore sales for the development partners are potentially significantly smaller. Second, with complex -- and potentially dangerous -- actuators like Electric Vehicles, being able to protect them from abuse by potentially malicious external applications is key, and this is not an easy feat.

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 for own vehicle apps

Probably the first step towards an AppStore for physical products is to use the concept for applications developed and quality managed by the Digital OEM himself. In the example shown below, a car manufacturer is using an AppStore to allow on-demand deployment of new application component to the car. This OEM AppStore us used in combination with the smart phone AppStores of Apple, Google, and the likes. This is necessary, since modern apps will be actually distributed apps, which 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 smart phone 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. This can 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 use the apps as one seamlessly integrated app. For example, this could be a new app similiar to the Dog Mode app recently introduced by Tesla, which allows a user to control certain features in the car (e.g. opening the windows a little) for a dog in the car via his smart phone.

In this scenario, protection of the car against potentially malicious behavior from the app on the car is not required, since the OEM has full control over the QA (Quality Assurance) cycle of the app. This will become highly relevant in the next example.

OEM with closed AppStore for vehicle apps

Example 2: OEM with open AppStore for partner vehicle apps

OEM with open AppStore for partner vehicle apps

Authors and Contributors

Kai Hackbarth.jpg
KAI HACKBARTH, BOSCH.IO
AUTHOR
Kai Hackbarth is Business Owner Industrial at Bosch.IO, and also co-chair of the OTA SIG at the Industrial Internet Consortium. Kai has many years experience with IoT applications and architectures. He also has served as a Director of the OSGi Alliance for many years.


Dirk Slama.jpeg
DIRK SLAMA
(Editor-in-Chief)

CONTRIBUTOR
Dirk Slama is VP and Chief Alliance Officer at Bosch Software Innovations (SI). Bosch SI is spearheading the Internet of Things (IoT) activities of Bosch, the global manufacturing and services group. Dirk has over 20 years experience in very large-scale distributed application projects and system integration, including SOA, BPM, M2M and most recently IoT. He is representing Bosch at the Industrial Internet Consortium and is active in the Industry 4.0 community. He holds an MBA from IMD Lausanne as well as a Diploma Degree in Computer Science from TU Berlin.