The Edge Device

This section provides an overview on the internal architecture of Industrial Edge Devices (IEDs) and the environment in which Edge Devices are typically deployed in. For specific details on how to integrate Industrial Edge functionality in Edge Devices or how to customize the Industrial Edge environment, navigate to the respective sections.

Network Environment

The Industrial Edge Runtime is optimized for building devices that should run in an industrial automation network, as shown in the figure above. Noteworthy assumptions respectively design goals derived from this environment are described in the following.

Multiple Network Interfaces

The Industrial Edge Runtime can be connected to multiple networks at once while still maintaining a clear separation between these networks. A typical setup is a connection to both, a machine internal network and the factory network.

Proxy/NAT/Firewall Compatibility

The Industrial Edge Runtime can be operated in an environment with highly controlled network access. The runtime itself only communicates with a single target system: the Industrial Edge Management.

The primary communication channel used between the IED and the IEM is based on HTTPS, the IED serves as client and initiates the HTTPS calls. You can deploy a NAT router between the IED and the IEM. The IED also allows the configuration of an HTTP(S) proxy and can route all traffic targeting the IEM through that proxy. It is also possible to directly link the IED and the IEM which means the proxy is placed only between the factory network and the Internet.

That same proxy is also used to provide network access for apps that require access to other systems on the factory network or the Internet. To simplify the task for the App Developer, the Industrial Edge Runtime supports transparent forward proxy that will automatically redirect outgoing HTTPS calls from apps to the configured proxy.

Edge Device architecture

Industrial Edge Runtime/Host System Integration

The Industrial Edge Runtime is provided as a *.deb package. It comprises 2 main components: the "Edge Core" which is running as a container in Docker and the "Host Daemon" which is running natively on the host system. The Edge Core is the core of the runtime and is responsible for managing apps as well as for communicating with the Industrial Edge Management that is responsible for this specific Edge Device.

The Host Daemon is used to perform configurations on the Docker environment which are difficult to configure within a container (or deliberately not done in a container due to security concerns). An example is the creation and management of the (container) network infrastructure on the host to ensure that apps are provided with the requested network access. Another example is modification of firewall rules.

The Host Daemon functionality is deliberately kept as small as possible. The Host Daemon can currently not be modified respectively customized by the Device Builder and has to be installed as it is on the host system. The Host Daemon uses a very small set of APIs from the underlying operating system (primarly the docker API) and should thus run on various operating systems without modification. The Host Daemon uses an internal API to communicate with the Edge Core which is currently not documented for the community as it is constantly in development. A design goal of Industrial Edge is to move as many APIs as possible to the Device Kit API (see below) to allow customization by the Device Builder.

The majority of the communication between the Edge Core and the host system is done via the IE Device Kit API. This is a publicly documented API which the Device Builder must provide on the Edge Device. The IE Device Kit API provides the following flexibility:

• Collect data requested by the Edge Core in a device specific manner (such as the currently installed firmware version or resource usage statistics)
• Choose the most suitable implementation for the Edge Device (such as which reverse proxy to use)
• Hide differences betweeen Linux distributions from the Edge Core (such as what tools to use for network configuration)
• Hook into Industrial Edge related workflows and perform Edge Device specific tasks, for example during onboarding, hard reset and so on.

Industrial Edge is responsible for defining the IE Device Kit API and providing the client side implementation inside the Edge Core. Device Builders are responsible for providing the server side implementation and for correctly integrating and installing this side in the operating system. The IE Device Kit API is designed with extensibility in mind. It is possible to improve respectively extend the IE Device Kit API if needed. Contact the Industrial Edge team through your partner manager in this case.

Industrial Edge offers reference implementations of the server side implementation. These implementations are currently used on the IPC product family. These implementations are developed for Debian based systems and can optionally be directly used by the Device Builder, given that no customization is wanted and the new Edge Device provides the required system packages used by these implementations.

The IE Device Kit API is based on gRPC running through unix domain sockets. For more details on the technology as well as a detailed explanation of how to develop a customized Device Kit implementation refer to the IE Device Kit API section.

Outside Communication and Proxy Setup

A simplified overview of the Edge Device internal network setup is shown in the figure above. The figure focuses on the communication channels from the Edge Device to the outside and the proxies involved hereby. The Industrial Edge Runtime also has a network setup for facilitating communication between its components as well as for communication with and between installed apps.

Reverse Proxy & TLS Termination

The Industrial Edge Runtime expects a reverse proxy to run on the host (currently based on nginx). This reverse proxy receives all incoming calls from the IEM UI respectively APIs of the IE Runtime as well as all calls directed to apps running on the Edge Device. The proxy terminates the TLS connection (2) and then forwards the calls to the appropriate target (3).

Configuration settings required by the runtime are communicated through the IE Device Kit API, for example to provide certificates to the proxy or to add forwarding rules for new apps.

Directly Exposed Apps

It is possible for apps to directly expose ports on the Edge Device. These ports are accessible from the outside. In this case, the network traffic bypasses all proxies and is routed directly to the app (5). This is possible by selecting the corresponding option in the Industrial Edge App Publisher during the creation of the app.

NOTICE

This option should only be used as a last resort if using proxies is not possible at all. It bypasses all networking related security measures provided by the platform. The app itself is responsible for providing proper authentication and authorization of incoming calls as well as hosting its own TLS certificate (if TLS is used).

The App Developer is responsible for picking a port that does not conflict with any other apps that are using this feature as well as any other services running on the Edge Device. Currently, it is not possible to remap the app ports during the installation.

Token Injection for Host Components

Components running on the host system that need to communicate with the IEM can use nginx to automatically inject an appropriate authentication token into the outgoing calls. Currently, the software update component, which is responsible for performing firmware updates, uses this functionality when checking for firmware update jobs in the IEM (1).

NOTICE

This functionality is only available for components running directly on the host.

Outgoing Traffic

It is common that a proxy must be used to access Internet resources or, in some cases, to serve in the factory network. To simplify the task for developers, the Industrial Edge Runtime provides a platform feature that handles proxies based on redsocks transparently. Apps can open connections by default without specifying proxy settings. The redsocks proxy intercepts the outgoing calls and transparently redirects them to the proxy (4).

Co-hosting of Industrial Edge Runtime

The Industrial Edge Runtime can be run in parallel with other apps on the host system. It performs changes on the Docker environment though which might interfere with other apps using Docker. Running other Docker apps in parallel would have to be investigated in detail. In any case, it is up to the Device Builder to appropriately partition up system resources in a way that avoids unwanted interference.

The Industrial Edge Runtime itself can ensure some limitations using mechanisms provided by Docker, for example limit the number of concurrently running apps or their memory consumption. These limits can be configured using the IE Device Kit API.

To achieve a strong partitioning of the Edge Device and contain the resource consumption of the Industrial Edge Runtime to a fixed limit, additional measures have to be taken on the operating system level, such as creating an appropriated sized disk partition for the Industrial Edge Runtime to use or create groups slices to manage CPU consumptions.