DE102021123358B3 - Control device, control method and computer program for distributing computing function blocks to computing units in a vehicle - Google Patents

Abstract

The present disclosure relates to a control device, a control method and a corresponding computer program for distributing a plurality of computing function blocks to a plurality of computing units of a vehicle. The control device (10) comprises at least one interface (12) designed for communication with the plurality of computing units (30). The control device also includes one or more processors (14). The one or more processors are designed to determine the computing function blocks of the vehicle that are currently to be executed. The one or more processors are designed to select which arithmetic function block is to be executed on which arithmetic unit (30). The one or more processors are designed to transfer the execution of an arithmetic function block from a first arithmetic unit of the plurality of arithmetic units to a second arithmetic unit of the plurality of arithmetic units, if this is indicated by the selection of which arithmetic function block is to be executed on which arithmetic unit .

Description

The present invention relates to a control device, to a control method and to a corresponding computer program for distributing a plurality of computing function blocks to a plurality of computing units of a vehicle.

In modern vehicles, an ever-increasing number of functions are provided by software. These functions are usually implemented by services that are executed on the vehicle's computing units. The computational demands of services running on a platform like a vehicle tend to grow over time, for example due to the increasing flow of data from sensors and actuators. In addition, the number of services is increasing. It is foreseeable that more computing resources will be required than are available locally.

The communication between vehicles and backend servers makes it possible to shift computing tasks from a vehicle to a server and to transfer the required information to the backend (e.g. sensor information from the vehicle). The calculations can also be transferred to another vehicle that implements the same services (e.g. when parked cars are available that are not burdened with other services).

In the current implementations, the vehicle and backend implementations differ. They use the same data, but it's not yet possible to take an implementation and run it unmodified on the vehicle or the server.

Using other vehicles, in which the services are also implemented, for the outsourcing of calculations and services does not represent a universal, always available solution. It may be that these other resources are not available because not all vehicles are compatible with each other.

Out of US 2018/0136931 A1 a system is known which is based on so-called microservice containers. The concept of software containers is disclosed, which include all necessary components to be able to run the container device-independently, such as the program code, software libraries, a configuration, files, a runtime environment, and other tools. However, neither the use of these containers in vehicles nor an approach to absorbing peak loads is discussed.

Out of U.S. 2018/137306 a system for updating containers is known. The use of containers is also disclosed here. However, neither the use of these containers across multiple computing devices in vehicles nor an approach to absorbing peak loads within a vehicle is discussed. Also in U.S. 2021/0044647 the use of portable containers is discussed, but here too neither the use of these containers across several computing devices in vehicles nor an approach to absorbing peak loads within a vehicle is discussed.

the US 2019/0 042 321 A1 describes an Elastic Container Management System (ECMS) that manages the lifecycle of containers by creating, deleting, starting, and stopping containers. The ECMS monitors the containers and adjusts or adjusts the resource allocation of the containers depending on resource utilization. The ECMS also performs garbage collection, removing the containers from the host and storing their images and configurations in a repository that can be retrieved. The ECMS also performs the migration of containers between hosts on a network when the host running the container runs out of resources.

the U.S. 2021/0 117 242 A1 relates to an infrastructure processing unit comprising: interface circuitry to provide communicative coupling with a platform; network interface circuitry to provide communicative coupling with a network medium; and circuits to expose infrastructure services that can be accessed by microservices for function composition.

the DE 11 2020 000 558 T5 describes a method for dynamically changing isolation of a containerized workload, an apparatus and a computer program product in response to detection of a triggering factor. In some embodiments, workload is containerized using a standard container runtime that creates one or more cgroup-based containers on a compute node by using resource-limiting capabilities of the compute node's host kernel, which includes cgroups and namespaces. In some embodiments, in response to a triggering factor, such as a host kernel vulnerability, at least a portion of the containerized workload is migrated from execution in the one or more containers on a cgroup basis to one or more virtual machines run by a standby container runtime has been started. In some embodiments, the cgroups and namespaces of the one or more containers are live migrated to the one or more VMs on a cgroup basis non-disruptively to one or more VM runtimes using CRIU - Checkpoint/Restore in Userspace.

However, none of these references provide a concept to meet the increasing and varying computational needs in modern vehicles.

There is a need to provide an improved concept for providing software-based functionalities in vehicles.

This need is met by the subject matter of the independent claims.

The present invention is based on the finding that the frequently used approach of executing software applications tailored specifically to certain vehicles on the vehicle's specifically designed computing devices seems unsuitable for reacting to additional computing requirements within the vehicle. The only remaining approach is to provide for appropriate over-provisioning so that all functionalities that are available in the vehicle can be used at the same time, or certain combinations of functionalities exclude each other. This limitation can be overcome by providing the individual software-based functionalities in a standardized, portable format as computing function blocks that can be executed on different computing devices in the vehicle (or even outside the vehicle). The present invention therefore strives for an abstraction of runtime environments. The effort for the development and maintenance of services is considerable, so it is advantageous to reduce the number of implementation variants as much as possible and ideally to maintain only one implementation, in the form of a calculation function block. In various examples of the present disclosure, the services execute in a standardized runtime environment, regardless of the hardware and software basis of the device on which they execute.

A controller is used to perform load sharing, i.e. to allocate the computing function blocks to the existing computing devices.

One aspect of the present disclosure relates to a control device for a distribution of a plurality of computing function blocks to a plurality of computing units of a vehicle. The control device includes at least one interface designed for communication with the plurality of computing units. The controller also includes one or more processors. The one or more processors are designed to determine the computing function blocks of the vehicle that are currently to be executed. The one or more processors are configured to select which computing function block is to be executed on which computing unit. The one or more processors are designed to transfer the execution of an arithmetic function block from a first arithmetic unit of the plurality of arithmetic units to a second arithmetic unit of the plurality of arithmetic units, if this is indicated by the selection of which arithmetic function block is to be executed on which arithmetic unit . The arithmetic function blocks can consequently be transferred between the arithmetic units of the vehicle by the control device, which enables a higher efficiency of the use of the arithmetic units. This is made possible by designing the arithmetic function blocks in such a way that they can be executed on the various arithmetic units.

Furthermore, the arithmetic function blocks depend on which vehicle functions are active at that time, and in addition, respective arithmetic function blocks to be executed come from other vehicles or from other arithmetic units outside the vehicle, these arithmetic function blocks in addition to the arithmetic function blocks that Provide vehicle functions that are currently active are taken into account.

For example, each computing function block can be designed to be executed as a container within a runtime environment. The design as a container makes it possible to use the runtime environment of the computing unit instead of integrating the runtime environment into the computing function block. This reduces overhead when running multiple containers in a runtime environment of each compute unit.

The transfer of the execution of a computing function block can include, for example, the transfer of the execution of the container from a runtime environment of the first processing unit to a runtime environment of the second processing unit. The containers can thus be transferred with less effort, for example in cases where there is no communication between the containers.

Alternatively, transferring the execution of a computational function block may use the transfer ration of the runtime environment with the container from the first processing unit to the second processing unit. Here, the runtime environment to be transferred can include several containers to be executed. This reduces the overhead when transferring multiple arithmetic function blocks, and functionalities that are to be made available to all containers in the runtime environment can be made available once by the runtime environment. A so-called software-defined network between the containers in the runtime environment can also be used in this way and transferred to the second processing unit.

Selecting which computing function block is to be executed on which computing unit can aim at load balancing, for example. In other words, the selection can be made in such a way that the resulting computing load is distributed appropriately across the available computing units, for example so that no computing unit is overloaded and all computing function blocks have sufficient computing and other resources (memory, input/output, etc. ) available (as far as possible).

In some cases, transferring execution of the computational function block may include transferring run-time data of the computational function block. A state of the arithmetic function block can thus be retained over the transfer.

The plurality of computing devices may, in some examples, further include one or more computing devices located outside of the vehicle. As a result of the concept of the portable arithmetic function blocks coupled with the control device for assigning the arithmetic function blocks, additional resources of the external arithmetic units can be used.

One aspect of the present disclosure relates to a system for a vehicle. The system includes the previously presented control device and the plurality of computing units of the vehicle. The arithmetic function blocks can be transferred between the arithmetic units of the vehicle by the control device, which enables a higher efficiency of the use of the arithmetic units.

Each arithmetic function block can be designed to be executed as a container within a runtime environment. Each computing unit can also be designed to provide a runtime environment for executing containers. The design as a container makes it possible to use the runtime environment of the computing unit instead of integrating the runtime environment into the computing function block. This reduces overhead when running multiple containers in a runtime environment of each compute unit.

In order for the containers to be portable, the computing units can offer the runtime environments standardized interfaces to communicate with other components of the vehicle and thus make them usable from all computing units. For example, each processing unit can be designed to provide the runtime environment with at least one first interface for communication with sensors and actuators. This can enable the analysis of sensor data and/or the actuation of the actuators by the computing function blocks.

For example, each computing unit can be designed to also provide the runtime environment with a second interface for communication via a communication network and/or a third interface for accessing resources of the computing unit. The second interface can be used, for example, to communicate with computing function blocks that are running on other computing units inside and/or outside the vehicle, or to access a mobile communication system. The third interface can be used to access specific resources of the processing unit, such as accelerator cards or memory.

For example, a first arithmetic unit can be designed to provide the communication with sensors and actuators, which is provided via the first interface of the first arithmetic unit, to a second arithmetic unit via the second interface, so that the runtime environment of the second arithmetic unit can access the sensors and actuators, which is provided via the first interface of the first computing unit receives. In this way, arithmetic function blocks can also be transferred to arithmetic units that do not have direct access to the sensors and actuators of the original (first) arithmetic unit. This is the case in particular with computing units that are arranged outside the vehicle.

The first interface, the second interface and/or the third interface can provide an abstraction of the physical interfaces of the respective computing unit, so that the first interface, the second interface and/or the third interface can be addressed uniformly for the runtime environment on each computing unit. Thus, the computing functional units, and the respective runtime environments, independently depends on the computing unit that uses the respective interfaces.

In one example, each computational function block is configured to execute as a container within a runtime environment. Transferring the execution of a computing function block may include transferring the runtime environment with the container from the first computing unit to the second computing unit, with the second computing unit providing at least 10% more or less computing capacity than the first computing unit. In other words, entire runtime environments can be moved according to the resource requirements of the containers in the runtime environment.

One aspect of the present disclosure is directed to a vehicle including the system presented above. Through the controller of the system, the vehicle's computing function blocks can be transferred between the vehicle's computing units, enabling higher efficiency of utilization of the vehicle's computing units.

An aspect of the present disclosure is directed to a corresponding control method for the distribution of a plurality of computing function blocks to a plurality of computing units of a vehicle. The method includes determining the computing function blocks of the vehicle that are currently to be executed. The method further includes selecting which computing function block is to be executed on which computing unit. The method further includes transferring the execution of a computing function block from a first computing unit of the plurality of computing units to a second computing unit of the plurality of computing units if this is indicated by the selection of which computing function block is to be executed on which computing unit.

One aspect of the present disclosure is directed to a program having program code for performing the method when the program code is executed on a computer, a processor, a control module or a programmable hardware component.

• 1a zeigt ein Blockdiagramm eines Beispiels einer Steuervorrichtung für eine Verteilung von einer Mehrzahl von Rechen-Funktionsblöcken auf eine Mehrzahl von Recheneinheiten eines Fahrzeugs;
• 1b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit einer Steuervorrichtung für eine Verteilung von einer Mehrzahl von Rechen-Funktionsblöcken auf eine Mehrzahl von Recheneinheiten eines Fahrzeugs und der Mehrzahl von Recheneinheiten;
• 1c zeigt ein Flussdiagramm eines Beispiels eines Steuerverfahrens für eine Verteilung von einer Mehrzahl von Rechen-Funktionsblöcken auf eine Mehrzahl von Recheneinheiten eines Fahrzeugs;
• 1d und 1e zeigen Beispiele eines Transfers einer Ausführung eines Rechen-Funktionsblocks;
• 2 zeigt ein schematisches Diagrammes eines Beispiels einer Recheneinheit mit einer Laufzeitumgebung und Rechen-Funktionsblöcken;
• 3 zeigt ein schematisches Diagramm eines Systems mit mehreren Recheneinheiten; und
• 4a und 4b zeigen Beispiele eines Transfers einer Ausführung eines Rechen-Funktionsblocks zwischen Fahrzeugen und externen Recheneinheiten.

Some examples of devices and/or methods are explained in more detail below with reference to the accompanying figures, merely by way of example. Show it:

• 1a 12 shows a block diagram of an example of a control device for a distribution of a plurality of calculation function blocks to a plurality of calculation units of a vehicle;
• 1b shows a schematic diagram of an example of a vehicle with a control device for a distribution of a plurality of calculation function blocks to a plurality of calculation units of a vehicle and the plurality of calculation units;
• 1c shows a flow chart of an example of a control method for a distribution of a plurality of computing function blocks to a plurality of computing units of a vehicle;
• 1d and 1e Figure 12 shows examples of transfer of execution of a computational function block;
• 2 Figure 12 shows a schematic diagram of an example of a computing unit with a runtime environment and computing function blocks;
• 3 Figure 12 shows a schematic diagram of a system with multiple computing units; and
• 4a and 4b show examples of a transfer of an execution of a computing function block between vehicles and external computing units.

Some examples will now be described in more detail with reference to the accompanying figures. However, other possible examples are not limited to the features of these detailed described embodiments. These may include modifications of the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe particular examples is not intended to be limiting of other possible examples.

Throughout the description of the figures, the same or similar reference symbols refer to the same or similar elements or features, which can each be implemented identically or in a modified form, while providing the same or a similar function. Also, in the figures, the thicknesses of lines, layers, and/or areas may be exaggerated for clarity.

When two elements A and B are combined using an "or", it is to be understood that all possible combinations are disclosed, i. H. only A, only B and A and B, unless expressly defined otherwise in individual cases. "At least one of A and B" or "A and/or B" can be used as alternative wording for the same combinations. The equivalent applies to combinations of more than two elements.

If a singular form, e.g. For example, where "a, an" and "the" are used and the use of a single element is not explicitly or implicitly required, other examples may use multiple elements to implement the same function. Where a function is described below as being implemented using multiple elements, other examples may implement the same function using a single element or processing entity. It is further understood that the terms "comprises,""comprising,""comprises," and/or "having," when used, imply the presence of the specified feature, integer, step, operation, process, element, component, and/or group describe the same, but does not exclude the presence or addition of any other feature, integer, step, operation, process, element, component and/or group thereof.

The present disclosure addresses the portability of computational function blocks. One area where such portability exists is on desktop platforms such as Windows or mobile platforms such as iOS or Android, where an application or service can run on any device compatible with the platform based on standard APIs and SDKs are compatible. However, this type of portability is not applicable to the present scenario because it does not allow scaling of computing resources by using multiple devices.

Instead, a technology is used in which services that provide the vehicle's software functionalities are packaged in so-called computing function blocks. These arithmetic function blocks can in turn be implemented by so-called software containers or correspond to them. One or more services can be encapsulated with all their dependencies in a software container. These containers are known in particular for use on servers and developer devices. For example, such containers can be provided by different container engines (Docker, Podman, Crio, ...). The present disclosure goes beyond the already known containers by making the container concept portable, so that the containers, and thus the computing function blocks, can be dynamically transferred between the computing units of the vehicle. The present disclosure provides means to create portable containers that can run dynamically on different platforms, or to port a complete runtime (consisting of the container engine and the service containers) to other platforms on the fly.

1a 12 shows a block diagram of an example of a control device 10 for distribution (allocation) of a plurality of arithmetic function blocks 20 to a plurality of arithmetic units 30 of a vehicle. The device 10 includes at least one interface 12, designed for communication with the plurality of computing units. The device 10 further includes one or more processors 14 coupled to the at least one interface 12 . Optionally, the controller 10 further includes one or more memory devices 16 that are also coupled to the one or more processors. The one or more processors are basically designed to provide the functionality of the control device with the help of the at least one interface (for communication and for exchanging data) and/or with the help of the one or more storage devices (for storing and retrieving data. The one or more processors are designed to determine the computing function blocks of the vehicle that are currently to be executed. The one or more processors are designed to select which computing function block is to be executed on which computing unit. The one or more processors are designed to transfer the execution of a Arithmetic function blocks from a first arithmetic unit 30a of the plurality of arithmetic units to a second arithmetic unit 30b of the plurality of arithmetic units, provided this is indicated by the selection of which arithmetic function block is to be executed on which arithmetic unit amen with the computing units 30 are considered as a system.

The control device 10 can be integrated into a vehicle together with the computing units 30 . 1b 10 shows a schematic diagram of an example of a vehicle 100 with the control device 10 and the plurality of computing units 30. Alternatively, the control device can be arranged externally to the vehicle, for example in a backend server.

1c FIG. 12 shows a flow chart of an example of a corresponding control method for a distribution (allocation) of the plurality of computing function blocks to the plurality of computing units of the vehicle. The method includes determining 110 the computing function blocks of the vehicle currently to be executed. The method also includes selecting 120 which computing function block is to be executed on which computing unit. The method also includes transferring 130 the execution of a computing function block from a first computing unit of the plurality of computing units to a second computing unit of the plurality of computing units, provided this is done by selecting which Arithmetic function block to be executed on which arithmetic unit is displayed.

The concept within the framework of the control device is presented below. However, features of the control device can also be included in the corresponding control method.

The present disclosure deals with a concept for a distribution of a plurality of computing function blocks 20 to a plurality of computing units 30 of a vehicle. Each computing function block stands for a vehicle functionality that is provided by software and is encapsulated as a computing function block. In other words, each arithmetic function block is designed to provide vehicle functionality of the vehicle. Each calculation function block is also encapsulated, i.e. it includes all program code and all dependencies in order to be able to be executed within a runtime environment. In particular, each computing function block represents a software-implemented vehicle functionality. In this way, through the proposed concept, the arithmetic function block can be given access to sensors and/or actuators of the vehicle, regardless of which arithmetic unit it is executed on. For example, the computing function blocks can therefore provide vehicle functionalities that are based on access to sensors and/or actuators of the vehicle.

Furthermore, the concept of the arithmetic function blocks is used to enable the vehicle functionality to be executed by different arithmetic units. For this purpose, the arithmetic function blocks can be implemented, for example, as software containers that are used in runtime environments that provide standardized and abstract interfaces for the containers. Each arithmetic function block can be designed to be executed as a container within a runtime environment. Each processing unit can in turn be designed to provide a runtime environment for the execution of containers

So that the computing function blocks can be operated in the runtime environments of the different computing units without losing functionality, the computing units in some examples of the present disclosure are designed to provide corresponding interfaces. For example, such as in the 2 and 3 is shown, each computing unit can be designed to provide the runtime environment with at least one first interface (34 in 2 ) for communication with sensors and actuators, for example with one or more sensors of the vehicle and/or one or more actuators of the vehicle. Each computing unit can also be designed to provide the runtime environment with a second interface for communication via a communication network (37 in 2 ) and/or a third interface for accessing resources of the processing unit (35 in 2 ) to provide. The respective interfaces can be used to access the respective resources, independently of the processing unit. If certain resources are not available in a computing unit, access can be virtualized by the accesses being forwarded between the different computing units via the respective second interfaces of the computing units. For example, a first computing unit can be designed to provide communication with sensors and actuators, which is provided via the first interface of the first computing unit, to a second computing unit via the second interface, so that the runtime environment of the second computing unit can access the sensors and actuators , which is provided via the first interface of the first processing unit, receives. This can happen in particular if the second processing unit does not have direct access to the corresponding sensor system and/or because the corresponding sensor system/actuator system can only be addressed locally by the first processing unit, or because the second processing unit is arranged outside the vehicle.

In order to support the portability of the arithmetic function blocks, the respective interfaces can be designed in such a way that access to the interfaces is as identical as possible, regardless of which arithmetic unit or in which runtime environment the respective arithmetic function block is executed. The first interface, the second interface and/or the third interface can therefore provide an abstraction of the physical interfaces of the respective computing unit, so that the first interface, the second interface and/or the third interface can be addressed uniformly for the runtime environment on each computing unit. In other words, the respective interfaces can offer abstract and standardized access, regardless of the physical design of the respective interfaces in the processing units.

The distribution of the arithmetic function blocks is based on which arithmetic function blocks are being executed at any given time. The control device is therefore designed to determine the computing function blocks of the vehicle that are currently to be executed. The computing function blocks currently to be executed by the vehicle depend on which vehicle functions are active at that time, e.g. implicitly through the operation of the vehicle, or explicitly because they have been activated by a passenger of the vehicle. For example, the computing function blocks currently to be executed by the vehicle can be determined based on which vehicle functions are activated at this point in time, implicitly or explicitly. In addition, some computing function blocks to be executed can originate from other vehicles or from other computing units outside the vehicle. These computational function blocks may be considered in addition to the computational function blocks that provide vehicle functions that are currently active.

In addition, a (determined, expected or estimated) resource requirement of the vehicle's computing function blocks currently to be executed can be determined, for example based on a current resource consumption of the respective computing function blocks, or based on an estimate based on a resource consumption of the respective computing function blocks in based on the past. A resource monitor can be used for this, for example, as described in 2 (33) is shown.

Based on the vehicle's computing function blocks that are currently to be executed, it can now be selected which computing function block is to be executed on which computing unit. In other words, an assignment of arithmetic function blocks to arithmetic units is determined. Various criteria can be taken into account. On the one hand, it can be taken into account that, depending on the selection, each computing function block has sufficient resources (such as computing resources or memory resources) available. In other words, the selection of which arithmetic function block is to be executed on which arithmetic unit can be carried out based on a resource requirement of the arithmetic function blocks and on available resources of the arithmetic units such that each arithmetic function block has sufficient resources available. The available resources of the computing units can in turn be monitored via resource monitoring, as described in 2 (33) can be determined. In this way, a load distribution can be aimed at (also known as “load balancing”). In other words, selecting which computational function block to execute on which computational unit may strive for load balancing. For example, the selection of which arithmetic function block is to be executed on which arithmetic unit can be carried out in such a way that a resource requirement of the arithmetic function blocks is distributed to the arithmetic units according to the available resources. The aim can be that the different processing units have a similarly high percentage of free resources according to the selection. A maximum resource requirement of the respective arithmetic function blocks can also be taken into account, so that the arithmetic function blocks are distributed in such a way that sufficient resources are available so that the maximum resource requirement of the respective arithmetic function blocks can also be covered.

In addition to the required and available resources, other factors can also be taken into account, such as access by the computing function blocks to the sensors/actuators of the respective computing units. If such access is only possible indirectly, i.e. via forwarding via the respective second interfaces of the processing units, this can speak against a selection of such a processing unit for an accessing processing function block. If arithmetic function blocks communicate with one another, this can be taken into account, for example by assigning the arithmetic function blocks to the same arithmetic unit and/or the same runtime environment. Depending on the functionality of the arithmetic function blocks, other factors can also be taken into account.

Based on the assignment of arithmetic function blocks to arithmetic units, the execution of the arithmetic function blocks is now transferred between the arithmetic units, if necessary. In this context, one speaks of a transfer of the execution because, in some examples, the arithmetic function blocks can already be present in different arithmetic units. What is transferred is the execution, i.e. which arithmetic unit executes which arithmetic function block. In other words, transferring the execution of a computational function block corresponds to or includes changing on which computational unit the computational function block is executed. In addition to the pure execution of the arithmetic function block, runtime data of the arithmetic function block can also be transferred. Correspondingly, transferring the execution of the computing function block may include transferring runtime data of the computing function block. In this case, the runtime data can be data that is stored by the first processing unit in the processing function block or in a storage resource of the first processing unit. Additionally or alternatively, the content of a volatile main memory, which is used by the arithmetic function block on the first arithmetic unit, can be transferred to the second arithmetic unit.

The control device is designed to transfer the execution of the arithmetic function block from the first to the second rake unit 30b of the plurality of computing units, provided this is indicated by the selection of which computing function block is to be executed on which computing unit. There are two variants to consider in the 1d and 1e are shown. 1d and 1e Figure 12 shows examples of a transfer of execution of a computational function block.

In 1d the arithmetic function block 20a is transferred from the runtime environment 32a of the first arithmetic unit 30a to the runtime environment 32b of the second arithmetic unit 30b. Correspondingly, transferring the execution of a computing function block may include transferring the execution of the container from a runtime environment 32a of the first computing unit to a runtime environment 32b of the second computing unit. A further arithmetic function block 20b can remain in the runtime environment 32a of the first arithmetic unit. The runtime environment 32b can also already include a further arithmetic function block 20c.

Alternatively, as in 1e , the entire runtime environment is transferred from the first processing unit to the second processing unit. In other words, the transfer of the execution of a computing function block can include the transfer of the runtime environment 32 with the container (or multiple containers) from the first computing unit to the second computing unit. As in 1e is shown, the runtime environment to be transferred may include multiple containers to be executed, both of which are transferred. This approach can be chosen if it is foreseeable that the first processing unit has either too few or too many resources for the execution of the processing function blocks/containers of the runtime environment. For example, transferring the execution of a computing function block can include transferring the runtime environment with the container from the first computing unit to the second computing unit, for example if the second computing unit provides at least 10% more or less computing capacity than the first computing unit. This can be factored into the allocation of computational functional units to computational units.

As already indicated, the proposed concept can also be used in scenarios in which processing units outside the vehicle are included, such as processing units from other vehicles, processing units in a parking garage or processing units in a charging station. Consequently, the plurality of computing units may further include one or more computing units located outside of the vehicle. Such a scenario is, for example, in connection with the 4a and 4b shown. The proposed control device, the control method and the computer program can also be used to distribute arithmetic function blocks from outside the vehicle to arithmetic units in the vehicle.

The at least one interface 12 may correspond, for example, to one or more inputs and/or one or more outputs for receiving and/or transmitting information, such as in digital bit values, based on a code, within a module, between modules, or between modules of different entities .

In example embodiments, the one or more processors 14 may correspond to any controller or processor or programmable hardware component. For example, the functionality of the one or more processors 14 can also be implemented as software that is programmed for a corresponding hardware component. In this respect, the one or more processors 14 can be implemented as programmable hardware with correspondingly adapted software. Any processors, such as digital signal processors (DSPs) can be used. Exemplary embodiments are not limited to a specific type of processor. Any processors or even multiple processors are conceivable for the implementation.

The one or more storage devices 16 can be, for example, at least one element from the group of computer-readable storage medium, magnetic storage medium, optical storage medium, hard drive, flash memory, floppy disk, random access memory (also engl. Random Access Memory), programmable read only memory (PROM), erasable include programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), and network storage.

The vehicle 100 may correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, an all-terrain vehicle, a motor vehicle, or a truck.

More details and aspects of the control device, the control method, the computer program, the system and the vehicle are mentioned in connection with the concept or examples given before or after (e.g 2 until 4b ) to be discribed. The control device, the control method, the computer program, the system and the vehicle can/can a or comprise several additional optional features corresponding to one or more aspects of the proposed concept or the described examples as described before or after.

To create a unified service container across platforms, the device running the services can be abstracted to hide differences in hardware architectures or low-level data formats. An example of the design of a computing unit is given below.

The details of such an implementation are given below 2 to find. 2 Figure 12 shows a schematic diagram of an example of a computing unit with a runtime environment and computing function blocks. 2 shows the runtime environment 32 embedded in an (abstract) device 30, ie a computing unit. The runtime environment runs on the runtime infrastructure 31 . The physical device 30 (e.g., an in-vehicle controller, a backend server, a personal device such as a smartphone) generally provides three types of interfaces to the outside world: An interface to the physical environment with sensors 34a and actuators 34b driven by the environmental Connector (engl. Environment Connector) 34 can be abstracted, an interface to connected devices, via input channels 39 and output channels 38, with an abstraction called communication connector (engl. Communication Connector) 37 and an interface to the resources 36 of the device (host), host connector (engl. Host connector) 35 called (e.g. access to mass storage, special computing units, ...). The arithmetic block 30 from 2 also includes a resource monitor 33 to monitor the resources used by the runtime environment 32 and pass them on via the communication connector 33 of the control device. The communication connector 37, as in 3 shown, be arranged outside of the computing units/device (e.g. in a modem) and addressed via a communication multiplexer. In many cases, the sensors/actuators 34a/34b can also be arranged outside the computing units/the device.

The runtime environment receives or sends data (exclusively) via the abstracted interfaces (environment / communication / host connector) and is therefore independent of the physical device. The runtime environment can be instantiated on various devices, such as one or more vehicle control units/computing units of the vehicle, on a backend server, a personal computer or other personal devices such as a smartphone or a wearable.

An important new concept is the ability to move computing function blocks, and thus services, from one runtime environment to another and also to perform load balancing between the runtime environments.

Communication between the runtime environments can be encrypted to prevent a "man in the middle" from eavesdropping on messages and also modifying data traffic. Isolated (SW) containers, i.e. the computational function blocks, can be moved to different platforms for execution. A complete runtime environment (base system) can also be moved to another system. The virtualization of the HW interfaces enables the runtime to be implemented independently of the device architecture. Traffic (input/output) between runtimes can be done over an encrypted channel. In addition, vehicle SW can be transferred to personal devices (e.g. PC, smartphone, ...) for development/testing or other purposes.

The following 3 shows the benefits of an abstracted runtime in a distributed, multi-device environment: 3 Figure 12 shows a schematic diagram of a system with multiple processing units. 3 illustrates the concept of distributed runtime environments with load balancing

The devices 30a, 30b (1 to n) (i.e. the plurality of computing units) can be integrated into a vehicle as control units, for example; it can also be a mixture of a few devices within a vehicle and one or more (backend) servers or an ad hoc integration of personal devices into a vehicle environment.

Communication between the different runtime environments can use abstracted data (as opposed to raw data) to avoid time and resource consuming conversions. When information leaves the scope of the abstracted runtime environments, the respective interfaces (environmental connector, communication connector, host connector) can convert the data back to the formats in these connected systems.

Another aspect that is considered is load balancing, ie where should a service run when multiple compute units/runtimes are available? To solve this challenge, two elements can be used. Resource monitors 33 (see 3 ) can be used on the respective computing units to report the load and the resources still available on each device to the control device 10 so that a decision can be made as to whether services can be run on this particular device. A load balancer, such as controller 10, is used to decide where to place and run a service based on the load of the various devices.

In 3 the communication is shifted via the communication connector into a modem 310, with a communication multiplexer remaining in the individual devices for communication with the communication connector.

While resource monitoring can be performed on all devices, the load balancer can be an independent software component that collects the reports from all resource monitors to make a central decision on where to run the services.

Alternatively, load balancing could be done in a distributed manner. Here, the various devices offer free resources to a service provider (e.g. in the backend) in order to take over a service if resources are available on the device. However, the central load balancer has the advantage that the decision as to where a service should run is made at one point (e.g. in the backend or in a central control device) and no time-consuming negotiations of the decentralized resource monitors in the individual devices are required.

The abstracted distributed runtime environment allows a system to be scaled by adding new runtime environments as needed. In the vehicle context, this allows to keep a vehicle updated with new services and to shift overly demanding services to alternative devices connected to the vehicle.

The abstraction of runtime environments is also useful for loT / M2M / B2B (Internet of Things/Internet of Things, machine-to-machine/machine-to-machine, business-to-business/business transactions) applications and standards. The invention can be used in vehicles and other mobility products (e.g. wall boxes, charging stations, infrastructure). The distributed runtime environments can also be used in other environments (smart home, smart city, smart offices, ...).

Various examples of the present invention may help to eliminate the boundary between backend and vehicle (e.g. moving tasks to vehicles that have no other tasks - parked vehicles) - middleware or network operating system. This enables a trade-off between local resources (in the vehicle) and remote resources (other vehicles, servers).

As already explained above, it is possible to also transfer the computing function blocks to computing units outside the vehicle. 4a and 4b show examples of a transfer of an execution of a computing function block between vehicles and external computing units. In the 4a and 4b a transfer of computing function blocks from a vehicle 410 to another vehicle 420, a charging station 430 or a parking garage 440 is shown schematically. In 4a individual computing function blocks 20 are transferred from the runtime environment 30 of the vehicle 410 to the runtime environment 30 of a computing unit of another device 420; 430; 440 transferred. In 4b the entire runtime environment 30 of the vehicle 410, together with the function blocks 20, is transferred to the computing unit of another device 420; 430; 440 transferred.

This allows, for example, using parked cars as computing and network resources, or using computing units in one garage with moving charging robots, another garage with a robotic arm reaching for the vehicle. It is possible to create more than one runtime environment per vehicle/processing unit, for example in order to better match the transferred processing function blocks of different vehicles. Various (new) environments are also created for a runtime solution (e.g. by using external devices such as loading robots). The interfaces, as previously in connection with the 1a until 3 carried out, standardized and abstracted between the various devices (e.g. car and charging robot), so that hardware independence of the interfaces can be achieved.

The transfer of a service, i.e. a calculation function block (algorithm) to another instance (e.g. from the vehicle to the workshop) may have been carried out due to a lack of resources, for example. For this purpose, the garage can provide a compatible runtime environment in order to be able to run the service.

To ensure data security when applications/services are transferred to other instances/computing units, encryption can be used so that the computing function blocks and/or the runtime environments do not pass on any confidential data. Thereby can a two-part implementation can be chosen by handling the functional logic and the data (which may be private) separately.

The concept presented can be used for combined services, for example. In the example of a parking garage, the parking garage can provide electrical energy for charging the vehicle, for example. In addition, the parking garage can provide computing resources for executing computing function blocks of the vehicle, or use the computing capacity of the computing function block of the vehicle. When using computing power (with payments), a discount for electrical power can be granted. This allows you to offer your own resources (e.g. computing power when not in use) and get something in return

Also apart from the scenario of a parking garage, the computing resources of one's own vehicle can be offered when the state of charge is sufficient and it is not used, on the basis of reciprocity

The aspects and features described in connection with a certain of the previous examples can also be combined with one or more of the further examples in order to replace an identical or similar feature of this further example or to additionally introduce the feature into the further example .

Examples may further include or relate to a (computer) program having program code for performing one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations, or processes of various methods described above may also be performed by programmed computers, processors, or other programmable hardware components. Examples may also include program storage devices, e.g. digital data storage media, which is machine, processor or computer readable and which encodes or incorporates machine executable, processor executable or computer executable programs and instructions. The program storage devices may e.g. B. include or be digital storage, magnetic storage media such as magnetic disks and magnetic tapes, hard drives or optically readable digital data storage media. Further examples can also be computers, processors, control units, (field) programmable logic arrays ((F)PLAs = (Field) Programmable Logic Arrays), (field) programmable gate arrays ((F)PGA = (Field) Programmable Gate arrays), graphics processors (GPU = graphics processor unit), application-specific integrated circuits (ASIC = application-specific integrated circuit), integrated circuits (IC = integrated circuit) or single-chip systems (SoC = system-on-a-chip). ) that are programmed to perform the steps of the above procedures.

It is further understood that disclosure of a plurality of steps, processes, operations, or functions disclosed in the specification or claims should not be construed as necessarily being in the order described, unless expressly stated in an individual case or is compellingly necessary for technical reasons . Therefore, the foregoing description is not intended to limit the performance of any number of steps or functions to any particular order. Further, in other examples, a single step, function, process, or operation may include and/or be broken into multiple sub-steps, functions, processes, or operations.

If some aspects have been described in the preceding paragraphs in the context of a device or a system, these aspects are also to be understood as a description of the corresponding method. For example, a block, a device or a functional aspect of the device or the system can correspond to a feature, such as a method step, of the corresponding method. Correspondingly, aspects described in connection with a method are also to be understood as a description of a corresponding block, element, property or functional feature of a corresponding device or system.

The following claims are hereby incorporated into the Detailed Description, with each claim being able to stand on its own as a separate example. It should also be noted that although a dependent claim in the claims refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject-matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in individual cases that a specific combination is not intended. Furthermore, features of a claim are also intended to be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims (15)

Control device (10) for a distribution of a plurality of computing function blocks (20) to a plurality of computing units (30) of a vehicle, the control device comprising: At least one interface (12) designed for communication with the plurality of computing units; and One or more processors (14) configured to: Determining the computing function blocks of the vehicle currently to be executed, selecting which computing function block is to be executed on which computing unit, and Transferring the execution of a computing function block from a first computing unit (30a) of the plurality of computing units to a second computing unit (30b) of the plurality of computing units, if this is indicated by the selection of which computing function block is to be executed on which computing unit, wherein the arithmetic function blocks depend on which vehicle functions are active at this point in time, and in addition respective arithmetic function blocks to be executed come from other vehicles or from other arithmetic units outside the vehicle, these arithmetic function blocks in addition to the arithmetic function blocks, the vehicle functions, that are currently active, provide, are taken into account. The control device according to claim 1 , wherein each computing function block is designed to be executed as a container within a runtime environment (32). The control device according to claim 2 , wherein transferring the execution of a computing function block comprises transferring the execution of the container from a runtime environment (32a) of the first computing unit to a runtime environment (32b) of the second computing unit. The control device according to claim 2 , wherein transferring the execution of a computing function block comprises transferring the runtime environment (32) with the container from the first computing unit to the second computing unit. The control device according to claim 4 , where the runtime environment to be transferred comprises several containers to be executed. The control device according to one of Claims 1 until 5 , wherein the selection of which computing function block is to be executed on which computing unit strives for load balancing. The control device according to one of Claims 1 until 6 , wherein transferring execution of the computing function block comprises transferring runtime data of the computing function block. The system according to one of Claims 1 until 7 , wherein the plurality of computing units further comprises one or more computing units located outside of the vehicle. A system for a vehicle, the system comprising the control device (10) according to any one of the preceding claims and the plurality of computing units (30) of the vehicle. The system according to claim 9 , each computing function block being designed to be executed as a container within a runtime environment, each computing unit being designed to provide a runtime environment for running containers. The system according to claim 10 , with each processing unit being designed to provide the runtime environment with at least a first interface for communication with sensors and actuators, and/or with each processing unit being designed to provide the runtime environment with a second interface for communication via a communication network and/or a third interface for accessing Provide resources of the computing unit. The system according to claim 11 , wherein a first arithmetic unit is designed to provide the communication with sensors and actuators, which is provided via the first interface of the first arithmetic unit, to a second arithmetic unit via the second interface, so that the runtime environment of the second arithmetic unit has access to the sensors and actuators, which is provided via the first interface of the first computing unit receives. The system according to one of claims 9 until 12 , wherein the first interface, the second interface and/or the third interface provide an abstraction of the physical interfaces of the respective computing unit, so that the first interface, the second interface and/or the third interface can be addressed uniformly for the runtime environment on each computing unit. Control method for the distribution of a plurality of computing function blocks to a plurality of computing units of a vehicle, the method comprising: determining (110) the computational function blocks of the vehicle currently to be executed; selecting (120) which computational function block is to be executed on which computational unit; and transferring (130) the execution of a computing function block from a first computing unit of the plurality of computing units to a second computing unit of the plurality of computing units if this is indicated by the selection of which computing function block is to be executed on which computing unit, the computing -Function blocks depend on which vehicle functions are active at this time, and in addition, respective calculation function blocks to be executed come from other vehicles or from other calculation units outside the vehicle, these calculation function blocks in addition to the calculation function blocks, the vehicle functions that are currently are active, provide, are taken into account. Program with a program code for performing the method according to Claim 14 , when the program code is executed on a computer, processor, control module or programmable hardware component.

Images