DE102022200755A1 - Method for adding and/or managing functions on a computing unit - Google Patents

Abstract

The invention relates to a method for adding and/or managing functions on a computing unit of a vehicle, namely functions with a real-time requirement and functions without a real-time requirement, with a requirement profile of a respective function to be added being recorded and the function only being added if the Requirements profile corresponds to a skills profile.

Description

The invention relates to a method for adding and/or orchestrating functions on a computing unit of a vehicle.

Arithmetic units are used in modern motor vehicles to perform a significantly increasing number of functions. For example, driving assistance functions and convenience functions can be executed on a computing unit. So far, it has proven to be difficult to design a computing unit used in a vehicle so flexibly that functions can be flexibly managed even after the vehicle has been delivered.

It is an object of the invention to provide an alternative or better approach in this regard. This is achieved according to the invention by a method according to claim 1. Advantageous configurations can be found in the dependent claims, for example. The content of the claims is made part of the content of the description by express reference.

• - Erfassen, für eine jeweilige hinzuzufügende Funktion, eines jeweiligen Anforderungsprofils,
• - Erfassen eines Fähigkeitenprofils der Recheneinheit, und
• - Hinzufügen der Funktion nur dann, wenn das Anforderungsprofil zu dem Fähigkeitenprofil korrespondiert.

The invention relates to a method for adding and/or orchestrating functions on a computing unit of a vehicle. These are functions with a real-time requirement and functions without a real-time requirement. The procedure has the following steps:

• - Capture, for a respective function to be added, a respective requirement profile,
• - detecting a capability profile of the processing unit, and
• - Adding the function only if the requirements profile corresponds to the skills profile.

Using such a method, functions can be added and/or orchestrated in a particularly flexible manner. In particular, this can relate both to functions with a real-time requirement and to functions without a real-time requirement. As a result, one computing unit can be used for both types of functions. This significantly increases integration and flexibility. Reference is made to the description of functions with and without a real-time requirement given elsewhere herein.

The arithmetic unit can in particular be a unit in a vehicle which carries out arithmetic operations. For example, it can have one or more hardware components, which can, for example, perform different arithmetic tasks, storage tasks or data transfer tasks. The term computing unit can also be defined more broadly and can include components such as sensors or output devices, for example.

A requirement profile specifies in particular which requirements a particular function has. In this way, it identifies the skills required for a particular function and allows a comparison with the skills actually available, which are represented by the skills profile. Capturing a capability profile can in particular include generating a capability profile, or capturing a capability profile can be generating a capability profile. With regard to the generation of a capability profile, reference is made to the description given elsewhere herein. All described versions and variants can be used. However, capturing a capability profile can also include, for example, reading out a previously generated capability profile from a storage device provided for this purpose.

In particular, the requirement profile can contain one or more requirements. A requirement typically represents what the function under consideration requires in order to be able to function properly. The requirements profile can in particular correspond to the skills profile if all the requirements contained in the requirements profile are also contained in the skills profile.

In particular, the skills profile can contain at least one workload indicator. This can indicate how heavily the components of the computing unit, in particular data processing units, are utilized. The utilization indicator thus indicates how much computing capacity or capacity of communication modules, e.g. bandwidth or cycle time of signals, is still available. In particular, the capacity utilization indicator can be determined over a predetermined period of time. This can be, for example, a predetermined time period in the past from a particular point in time under consideration.

In particular, an event-based scheduler, a capability manager and/or a capability monitor can be considered to determine the capacity utilization indicator. Such components can provide data that can be used to calculate a utilization indicator. This allows a realistic capacity utilization indicator to be generated. Reference is made to the description given elsewhere herein.

In particular, the requirement profile can contain a computing power requirement. In particular, the requirement profile can only correspond to the capability profile if the computing power requirement is assessed as likely to be achievable. For this purpose, in particular the utilization indicator already mentioned can be used, it being possible for a computing power requirement to be compared with the utilization indicator. The capacity utilization indicator can in particular indicate which computing power requirement can probably be met and which cannot. The higher the utilization indicator, the lower the computing power requirement that can typically be met.

Real-time requirements can also allow for redundancy, as functional safety requirements can be met through redundancy when results are communicated in a timely manner.

In particular, the requirements profile can contain one or more real-time requirements. This can be the case in particular for functions with a real-time requirement. In particular, the requirement profile can only correspond to the capability profile if the real-time requirements can be met according to the capability profile. In particular, this can mean that a real-time requirement, such as access to specific functions or hardware components, can be provided by the processing unit within specific time periods or at specific time intervals.

Any access to skills can be guaranteed especially when adding the function. This can include both authorization and authentication. In particular, this can ensure that the required requirements are actually made available at runtime.

In particular, the requirement profile can contain one or more access requirements for vehicle components. In particular, the requirements profile can only correspond to the skills profile if the access requirements can be met according to the skills profile. Such access requests may include, for example, access to components such as certain hardware components. For example, it can be an access request to a rain sensor, to a distance sensor, or to an image or sound-emitting device. The capability profile can typically indicate whether such components are present. Reference is made to the description given elsewhere herein.

According to an advantageous embodiment, after a function has been added, a utilization indicator of the processing unit is monitored for a period of time. In particular, the function or another function can be removed again, moved to another partition, run with less redundancy and/or scaled down if the utilization indicator is at least as great as a threshold value for at least one control time during the period. This allows a suitable mitigation strategy to be used if it is indicated that, despite the previous check, insufficient computing capacity is available for a function. The mitigation strategy can also take into account a signal propagation time, for example from the utilization indicator. It can also mean that the function is executed or placed in another computer system or another computing unit in the vehicle or outside the vehicle (networked cloud/edge). For example, the vehicle may be moving. If location-dependent hardware components (e.g. ITS stations, IST = Intelligent Transport System) are available, the capability can be offered by external hardware, allowing the local software component providing the same capability to be switched off and/or scaled down. The procedures mentioned can in particular be referred to as respective mitigation strategies. The function can then be removed again, for example. However, another function can also be removed, in which case, for example, a prioritization can be provided as to which function is to be removed first in the event of a detected overload or a threshold value being exceeded. This can also mean keeping a recently added feature while removing another feature because the recently added feature is more important. A function can also be moved to another partition where, for example, more computing capacity or more storage space is available. Running with less redundancy can mean, for example, that certain safety precautions in the function, which require computing capacity is dispensed with. It can also be scaled down, ie run with a lower graphics resolution or longer check intervals, for example.

In particular, the processing unit can have a variable number of hardware components. In particular, the capability profile can contain a list of the currently available hardware components. It can thus be ensured that the required hardware units, which a function needs to be executed, are actually available before the function is added. Reference is made to the description given elsewhere herein.

In particular, each function can be abstracted and run independently in its own format, for example in a container, a pod or a web assembly. A hardware instance or a software partition specified by partitioning can be assigned to it by the method. Other partitions can also be assigned accordingly. As a result, for example, hardware and/or a partition can already be assigned when the function is added, so that the function gets the resources it needs. This can be registered accordingly, for example in an event-based scheduler, so that the function can be executed and monitored at runtime by a monitor, for example the capabilities monitor described herein. The computing unit typically provides different hardware instances that have multiple partitions. In particular, these can be real-time capable and non-real-time capable partitions. This allows different requirements of functions to be taken into account.

• - Provisionierung und Deployment
• - Konfiguration und Planung
• - Ressourcenzuweisung
• - Verwalten der Funktions-Verfügbarkeit
• - Skalieren oder Entfernen von Funktionen, um Workloads gleichmäßig über Ihre Infrastruktur zu verteilen
• - Load Balancing und Traffic Routing
• - Überwachen des Funktionszustands
• - Konfigurieren der Funktion basierend auf der Partition oder Hardwareeinheit, auf der sie ausgeführt wird
• - Sichern von Interaktionen zwischen Funktionen.

Orchestration means in particular one or more of the following functionalities:

• - Provisioning and deployment
• - Configuration and planning
• - Resource Allocation
• - Manage feature availability
• - Scale or remove features to evenly distribute workloads across your infrastructure
• - Load balancing and traffic routing
• - Health status monitoring
• - Configure the function based on the partition or hardware unit on which it runs
• - Securing interactions between functions.

In particular, a partition of the processing unit can be selected for a respective function to be added. The function can be assigned to the selected partition for execution. This allows immediate allocation of a partition in which to place and register the function. By registering, for example in an event-based scheduler, monitoring at runtime is made possible.

• - Senden, an eine externe Einheit, einer Rückmeldung darüber, ob die Funktion hinzugefügt wurde oder nicht hinzugefügt wurde.

According to an advantageous embodiment, the method can also have the following step after it has been decided whether a function to be added is to be added or not:

• - Sending, to an external entity, a feedback on whether the function has been added or not.

This gives a function developer feedback as to whether his function was implemented successfully or not. In particular, the decision as to whether or not to add a function can be made separately for each vehicle. This enables, for example, a simple and automated management of vehicle fleets, with functions being able to be provided for the vehicles in the vehicle fleet and an individual decision being made. The feedback just mentioned makes it possible to track whether the respective function is actually operable with a sufficient number of vehicles or not. If, for example, it is only accepted by a small number of vehicles or even by no vehicle at all, it can be assumed that the function was not successfully developed and/or should be adapted. However, will it be accepted by many or all vehicles? ted, it can be assumed that the function will be used successfully. For example, the feature monitor can create a compatibility indicator for the feature. This compatibility indicator contains, for example, a reference to the current capability profile. The skill manager can share this indicator with other managers.

Further possible aspects are described below. These can be viewed as independent aspects of the invention. However, they can also be combined with one another and/or with other aspects described herein as desired.

• - Erfassen eines Zustands der Recheneinheit, und
• - Erzeugen des Fähigkeitenprofils in Abhängigkeit von dem Zustand der Recheneinheit.

The invention relates to a method for generating a capability profile of a computing unit of a vehicle, one or more functions with a real-time requirement and one or more functions without a real-time requirement running on the computing unit. The procedure has the following steps:

• - detecting a state of the processing unit, and
• - Generation of the capability profile depending on the state of the computing unit.

A capability profile can be provided by means of such a method, which can be used to display the current capabilities of the processing unit. In particular, the capability profile can be used to decide whether a new function can be added. In particular, the capability profile can indicate whether specific functions or components are available and/or whether a current computing capacity or an expected computing capacity is sufficient.

The skills profile can be provided, for example, in the form of a table or a matrix, for example a skills matrix. In particular, it can be used as part of a procedure that decides whether a function can be added or not. Reference is made to the statements given elsewhere herein, it being possible to fall back on all the variants and variants described.

A function with a real-time requirement can be understood in particular as a function that requires information at predefined or specific time intervals, requires specific access to other capabilities or functions or to hardware components, or has to send information to other components. This is typically specified by a respective function, it being possible in particular to define which real-time requirements a specific function has. Functions without a real-time requirement typically do not have such requirements, with functions without a real-time requirement typically being sufficient to execute the function when computing capacity is available. In typical implementations, real-time requirement functions are safety-critical functions, while non-real-time requirement functions are non-safety-critical functions. Functions with a real-time requirement can in particular intervene in the driving of a motor vehicle, for example triggering a braking process based on a monitored distance, or warn of an imminent danger.

The status of the processing units can be understood in particular as a feature or a set of features that represent the capabilities of the processing unit. The capability profile indicates this in a way that is suitable for further processing. In particular, the status can be a current status. Conditions can change over time.

In particular, the skills profile can contain an indicator for a current workload. This can in particular be a current utilization of units that perform calculations, store data and/or transmit data. Several such indicators can also be used. For example, the indicator can show CPU usage, which shows whether other functions can be executed.

According to an advantageous embodiment, the computing unit has a variable number of hardware components. In particular, this can mean that it is possible to add hardware components to the computing unit and also to remove them from it. It is therefore not constant during the lifetime of a motor vehicle which capabilities the processing unit has. In particular, the capability profile can contain a list of the currently available hardware components. This can be used to determine whether the hardware components required to execute a function are actually available for functions that may need to be added. For example, it can be matched whether a specific graphics accelerator unit is present, which is required by a graphics-intensive function becomes. The list of currently available hardware components can also include hardware components that can be separate units. For example, it can indicate whether the vehicle has sensors such as a distance sensor or a rain sensor. In this way, for example, in the case of a function that requires a rain sensor, it can be determined in advance whether there is a rain sensor in the vehicle at all.

When adding or removing a hardware component, the listing of the currently available hardware components can be advantageously updated. As a result, the current status is always displayed, so that it can always be determined up-to-date whether the hardware components required for a specific function are available.

• - Rechenkomponente,
• - Beschleunigerkomponente,
• - Speicherkomponente.

When adding or removing a hardware component, one or more of the following hardware components can be added or removed:

• - computing component,
• - accelerator component,
• - Storage component.

In other words, the variable hardware components can be such components. With components of this type in particular, it makes particular sense to have an up-to-date list of them, so that if a function needs to be added, it can be determined immediately whether it is possible to add the function or not.

A computing component can be configured in particular to perform computing operations. In particular, an accelerator component can be configured to accelerate certain tasks, for example graphical calculations. For example, a storage component can be configured to store data temporarily and/or permanently.

When adding or removing a hardware component, in particular one or more sensors and/or actuators can be added or removed. In other words, the variable hardware components or at least some of them can be sensors and/or actuators.

For example, it can be a matter of sensors such as a rain sensor, distance sensor, parking sensor, camera or other sensors. It can be actuators such as motors for windscreen wipers or window regulators, or actuators for components such as trunk lids or doors. With such components, too, it makes sense to have an up-to-date list of them, so that if a function needs to be added, it can be determined immediately whether it is possible to add the function.

In particular, the computing unit can have a variable number of partitions. In particular, the capability profile can contain a list of the currently available partitions. A partition can be understood in particular as a memory area or another area on which a function can run. Typically, each function is assigned to a partition or is assigned when a partition is added and registered accordingly.

In particular, a partition or some of the partitions can be real-time capable. Additionally or alternatively, a partition or some of the partitions may not be real-time capable. A partition capable of real-time means, in particular, a partition in which it is ensured that a function running on it can access certain other units, such as hardware components or other functions, at certain time intervals and/or at certain times. Such a capability does not exist with non-real-time capable partitions. In particular, functions with a real-time requirement can run on real-time-capable partitions, and functions without a real-time requirement can run on non-real-time-capable partitions in particular.

In particular, the computing unit can have a variable number of software functions. For example, functions can be added and/or removed again at runtime. In particular, the capability profile can contain a list of the currently available software functions. This takes into account the fact that some functions not only have to access special hardware components or have special requirements in terms of computing capacity, but that they also have to access other functions. By adding a listing of the currently available NEN software functions in the skills profile can be achieved in particular that the information required in this regard is available when adding any.

In particular, it is possible for software functions to build on one another. A new function to be added can, for example, check whether certain functions are already provided by other software components and can then access them at runtime. A developer can thus limit himself to the technical skills relevant to him.

• - Ermitteln eines Anforderungsprofils einer zur Recheneinheit hinzugefügten Funktion,
• - Vergleichen des Anforderungsprofils mit dem Fähigkeitenprofil, und
• - Hinzufügen des Anforderungsprofils nur dann, wenn das Anforderungsprofil zu dem Fähigkeitenprofil korrespondiert.

According to a development, the method can also have the following steps:

• - Determination of a requirements profile of a function added to the processing unit,
• - comparing the requirements profile with the skills profile, and
• - Adding the requirements profile only if the requirements profile corresponds to the skills profile.

This can ensure that a function is only added if the requirements profile corresponds to the skills profile. In particular, this can mean that the requirements profile indicates that all the skills required by the function can be provided as specified in the requirements profile. For example, this can mean that sufficient free computing capacity is available, that required hardware components are present and/or that other functions, in particular software functions, are required.

• 1: eine schematische Darstellung mehrerer Komponenten,
• 2: ein Ablaufdiagramm,
• 3: ein weiteres Ablaufdiagramm,
• 4: ein weiteres Ablaufdiagramm, und
• 5: einen Zusammenhang zwischen Funktionen und Hardware.

The person skilled in the art will find further features and advantages in the exemplary embodiments described below with reference to the attached drawing. show:

• 1 : a schematic representation of several components,
• 2 : a flowchart,
• 3 : another flowchart,
• 4 : another flowchart, and
• 5 : a link between features and hardware.

In principle, a computing unit can be, for example, a high-performance control unit (HPC, High Performance Computing). This can provide a variety of functions in a vehicle. New functions can be developed and added over the life cycle of the vehicle. The complete control unit software including the new function can be added by means of an update, or an individual function can be added by means of a function update. Typically, the functions are allocated statically and are usually tied to a specific system partition, specific memory areas and/or specific CPU cores in the software architecture.

In known designs, it was typically ensured by comprehensive testing that the CPU cores are never overloaded in order to be able to complete the arithmetic operations in good time within a specified time. This is no longer necessary with the procedure described here.

Furthermore, plug-in systems for hardware can be used, for example to add additional computing power to a base board. This is done, for example, via plug-in cards (PCIe) or independent SOM modules. These modular and expandable hardware concepts can also be referred to as scalable computing platforms (SCP).

Ring memories and associated interfaces can also be used, which make it possible, for example, to solve real-time memory access for a number of accessing and writing functions.

Hypervisor solutions can be used to separate resources of the hardware target system from each other using virtualization techniques.

Real-time operating systems can be used, which ensure timeliness when processing data in a runtime environment.

Orchestration systems can be used which, for example, allow allocation of resources for abstract functions in the form of containers, as well as corresponding interface specifications and runtimes. Various methods such as hashing, Merkle trees, etc. can be used to manage information about data sets.

• - dynamisches Allokieren von Ressourcen (CPU, Speicher, GPU-Zugriff, etc.) ist nicht möglich,
• - abstrakte Definition von Fähigkeiten des Zielsystems (zum Beispiel Steuerung einer Sitzheizung) ist partitionsgebunden und kann nur mit großem Aufwand für neue Softwarefunktionen freigegeben oder geändert werden,
• - keine dynamische Neuzuteilung von Ressourcen und Fähigkeiten zu Funktionen,
• - keine Echtzeitfähigkeit für Partitionen für ein dynamisches Allokieren möglich (da eine Zertifizierung verschiedener Funktionskonfigurationen aufgrund der hohen Komplexität nicht möglich ist),
• - keine partitionsübergreifende Funktions- und Fähigkeitsverwaltung,
• - hohe Komplexität bei der Zuteilung von Funktionen zum Beispiel durch manuelles Testen der maximalen Auslastung in verschiedenen Szenarien.

Known procedures have the following disadvantages in particular, which can be avoided using the procedures described herein:

• - dynamic allocation of resources (CPU, memory, GPU access, etc.) is not possible,
• - abstract definition of capabilities of the target system (e.g. controlling a seat heater) is partition-bound and can only be released or changed for new software functions with great effort,
• - no dynamic reallocation of resources and skills to functions,
• - No real-time capability for partitions for dynamic allocation possible (because certification of different function configurations is not possible due to the high complexity),
• - no cross-partition function and capability management,
• - high complexity in the allocation of functions, for example by manually testing the maximum utilization in different scenarios.

For example, the question of whether all the requirements of a software are met at runtime cannot be answered. This can only be answered with great effort, for example by simulation.

There is no known method to match the software with the capabilities of a control unit and to keep an optimized allocation of the software components automated beyond the partitioning. Not only the prioritization of the software functions in a runtime environment plays a role, but also the monitoring of the data flows between actuators, sensors and abstract capabilities in order to be able to observe the influence of the software components on each other and to take influence if necessary. In particular, the connection between functions with their abstract capabilities and vehicle actuators or sensors is important. This is not possible in the prior art.

Using the procedure described here, non-certified software functions can also use vehicle functions without being able to influence safety-related functions. If the computing power in an SCP is expanded or a single module is changed, the functional software is typically also changed accordingly. This can lead to a new allocation of software to a specific partition. Memory management (e.g. DMA) and runtime behavior are typically adjusted. Unknown third-party software typically cannot be used because harmful program code can influence the runtime behavior of other software modules or read or change sensor/actuator data.

1 shows purely schematically an arrangement with different components. This describes a basic mode of operation of the procedure described here.

A developer E has developed a new function and would like to implement it on a computing unit RE of a motor vehicle that is otherwise not shown in more detail. For this purpose, a capability profile FP can first be accessed, which indicates which capabilities the processing unit RE currently has. The capability profile FP is generated in the interaction between a capability manager, a capability monitor and an event-based scheduler. Their tasks are described below.

The event-based scheduler typically has a list of all implemented functions in a function registry. Functions 1, 2, 3, 4, n are shown here as examples. These are executed in a runtime environment (“service runtime”). Data is transferred both between the function registration and the event-based scheduler and between the runtime environment and the event-based scheduler.

The event-based scheduler typically ensures that the functions are executed with their respective real-time requirements, if any. For example, such a real-time requirement can indicate that a function needs to access certain components at certain intervals or needs to perform certain calculations. The event-based scheduler can, if necessary, delay or switch off less important or less time-critical functions in order to ensure this. A mitigation strategy can also be used, as described elsewhere herein.

The capability manager is connected to the event-based scheduler, among other things, and generates the capability profile FP from data which it receives from the event-based scheduler and which, for example, indicate a current workload. However, other information is also included in the capability profile FP, for example about connected components. This will be discussed in more detail below.

The skill manager is also in communication with a skill monitor as well as a skill store. The currently available skills are stored in the skill memory. The skill monitor monitors the existing skills and controls access to them. In the present implementation, a brake B, a temperature sensor T and a motor M are available as capabilities. These communicate via the present two ring memories R1, R2 with the event-based scheduler and with their respectively assigned functions which access them. More or fewer ring buffers can also be used. Each ability is typically assigned its own ring buffer. The ring memories R1, R2 are implemented in the usual way. They can be monitored and specifically controlled by the skill monitor. In particular, the scheduler can prevent or permit access for a function to the ring memory, in particular by issuing or deleting the associated write or read pointer. In this way, the access of functions to the ring memory can be managed in a targeted manner. If no function accesses the ring memory, it can be reallocated. This can be used in a simple way to deactivate a function, for example if the event-based scheduler, as already mentioned above, wants to deactivate a function in order to allocate more computing capacity to another function.

A capability abstraction can be achieved in particular by a capability abstracting a sensor or an actor together with associated control and communication. For example, the Rain Detection ability can abstract a rain sensor along with controller and communications. The hardware components brake B, temperature sensor T and motor M shown here are referred to as actuators/sensors.

In particular, ring memories represent a fast communication solution. The procedure described here extends in particular existing concepts of orchestrator components in order to provide capability management for real-time capable function management and allocation, in particular in order to overcome the disadvantages of existing automotive solutions. The intelligent management by the capability manager, which controls the ring memory in particular in cooperation with the capability monitor, and with the event-based scheduler forms a particularly advantageous implementation.

In 2 shows procedures for registering a new role and deregistering an existing role. To register a new function, a developer first defines the function and required skills. A request for the required capabilities is then made in the target system. Typically, if the capabilities are not available, the feature cannot be added. If they are available, the feature is added to the target system in the feature registry. A capability matrix of the function is signed and added to the capability store. In particular, the signing can be performed by a function provider, a capability provider and/or a capability manager. The skill monitor then finds a new skill in memory. The function is registered in the event-based scheduler, and then the function is executed.

To deregister an existing function, a function deletion event is triggered. The capability manager deletes the function's entry in the event-based scheduler. The function manager then stops the function. The role manager then deletes the role from the role registry and also deletes the associated skill matrix or skill profile.

A developer can, for example, develop a function that he would like to apply to a vehicle system or a computing unit. The function typically depends on the vehicle's existing capabilities and changes the overall configuration of the vehicle during allocation. The procedure can ensure that the new configuration is executable and that all required capabilities and dependencies are present.

First of all, the developer in particular can request skills from the skills manager, for example via a skills matrix referenced with the function software. The referencing can take place via a hash, for example. This reference can identify the new software component including its requirements for the capabilities of the target system. Optionally, the skills manager can also determine other skills through this newly provided component. The description of the function with its ability dependencies can then be stored in the ability memory, for example in the form of a merkle tree. The code of the new function can be added to the function registry and the event-based scheduler for execution. The capability monitor can monitor access to all functions, specifically capabilities in real-time during runtime and respond in the event of an error, such as determining that capabilities are not available on time. The capability monitor can provide runtime information of the ring buffers to the capability manager so that the event-based scheduler can trigger the partitions of the functions according to their real-time demand. The skill monitor can check the signatures of all participants before notifying the skill manager. A partition's data and runtime are typically only assigned to a function if the function meets the requirements of the capability matrix. The monitoring of the read and write pointers of the ring memory enables the timeliness of the function execution to be determined. Furthermore, the write or read pointer enables the event-based scheduler to plan the execution of all functions and to share the same capabilities in the same memory area. Encryption and access authorization of a ring memory and assignment of the access pointers can be controlled via the capability monitor via the signatures of the participants in the capability memory.

Capability abstraction ring buffers can be triggered by the hypervisor's real-time mechanisms. The capability monitor may receive a pointer to the buffer that requires a signature verification action. He typically interacts with the capability manager, which triggers corresponding or suitable mitigation strategies in the event of a conflict.

• - Regensensor lesen,
• - Fahrzeugmodell ermitteln.

A capability abstraction is described below. A function for determining precipitation serves as an example. For example, a new function for determining precipitation can access the following abilities:

• - read rain sensor,
• - Determine vehicle model.

For example, the rain sensor can provide an abstract value (e.g. 0=no rain, 1=little rain, 2=more rain, 3=a lot of rain, etc.). The new software function can use the vehicle model to determine the actual amount of precipitation in liters per square meter and register or provide this information as a new capability.

The capability manager can use the capability matrix to determine the real-time requirement of the new function. For example, a chronological listing of the input values, for example a reading of the rain sensor with a frequency of 1 Hz, or of the output values, such as the amount of precipitation of 0.5 Hz, can be determined. Furthermore, the capability manager can be informed whether a function is required by another and, if necessary, deletes this from the schedule of the event-based scheduler. This also happens in particular in the event of an error, for example if the function is not completed on time. With this principle, real-time capabilities can be shared between functions.

The skills matrix can provide a general structure for connecting skills and functions. New skills can be requested and also offered. It should be understood that the terms capability matrix and capability profile are used interchangeably herein.

The skill manager can validate the configuration file against the skill store. The step of checking whether the required skills match the skills offered is crucial.

• - fest definiert: eine im System bekannte festgelegte Liste definierter Fähigkeiten (zum Beispiel als String),
• - formlos und eindeutig: ein automatisch aus den Daten einer Fähigkeit erzeugter eindeutig identifizierbarer Wert (Hash).

There are two possible solutions for comparability of skills:

• - firmly defined: a fixed list of defined capabilities known in the system (e.g. as a string),
• - informal and unique: a uniquely identifiable value (hash) generated automatically from the data of a capability.

These capabilities can thus be written to a file and stored encrypted and signed by the function provider in the capability store. This can be referred to as a capability matrix or a capability profile. Furthermore, a hash of this capability specification can be generated and used as a fingerprint of the specification. This means that the contract between provider and user can have any content and be managed flexibly (e.g. commit hash). The agreement can be confirmed between the capability manager, the function provider and the user, for example by digitally signing the hash of an agreement by all parties.

To use capabilities, participants may exchange cryptographically signed messages about capabilities, which may specifically be transactions that distribute status or perform other tasks required for the capability's correct outcome. Next, the participants can deposit the status in a 3-of-3 multi-signature, for example, which the capability matrix can refer to. New cryptographically signed state updates related to the capability's original commitments can now be used to change the state of the function in the event-based scheduler and/or the data in the ring memory controlled by the multi-signature via the capability monitor.

Through a challenge-response mechanism, the capability monitor can implement methods for participants to ensure that the last signed, valid state update related to their commitment of the capability can be communicated to the function, resulting in the correct state result and data of capability for all functions that adhere to the protocol is guaranteed.

The part of the control API for registering new functions in the capability manager can have the following structure, for example:

According to a possible embodiment, the capability matrix has the following structure: identifier value example ID function provider ID as hash ID generation via public key procedure: Elliptic Curve Digital Signature Algorithm (ECDSA) Elliptic curve Diffie-Hellman(ECDH) Ed25519andEd448(EdDSA) X25519andX448(ECDH/EdDH) 0xA80b27e52a96778596F575f27A7E0A53aCEa88B3 List of required skills List of required skills as a hash Rain sensor read engine control List of Skills Offered (Optional) List of skills offered as a hash rainfall Real-time requirements RX (optional) Time in ms until required skills are executed eg rain sensor <= 1000 ms Real-time requirements TX (optional) Time in ms until the function has to be executed Eg time until rainfall in I/s is available <= 2000 ms multisignature Signature of Participants (Function Providers, Capability Providers, Capability Managers) Is created after a successful check Example: ECDSA, ECGDSA or Nyberg-Rueppel signatures signECDSAsecp256k1 (msg. privKey)

The capability manager may maintain a list of legitimate capability providers and add new capabilities with the capability provider's signature in the capability store.

3 shows the procedure for executing a function purely schematically. First, the function manager allocates ring memory per partition. The function manager can also optionally allocate several ring buffers per function. Corresponding read and write pointers are initialized. An event is generated, for example a new data record on a sensor. The data record is written to the ring buffer and the write pointer is set to the next position in the ring buffer. The capability monitor then typically checks signatures and monitors reading pointers. If these are valid, the data is read and evaluated by the function. If these are invalid, reading pointers are de-initialized.

If the target device (e.g. HPC of a vehicle) has the necessary capabilities and the new function is accepted along with its new capabilities, the container of the new software components is added to the schedule of the event-based scheduler. The ability matrix of a third-party software component optionally provides real-time requests for access to actuators, sensors and/or service data, such as that the motor temperature should be updated every 500 ms or that the target speed should be sent every 100 ms. Furthermore, the event-based scheduler typically ensures that third-party software has enough time to process the data. If no current data is available, it typically makes no sense to run the third-party software for processing. The capability monitor uses the access pointer of the writing function (third-party software) or sensor/actuator to check whether data is provided for a function. The capability monitor checks whether the third-party software is on schedule with the processing by monitoring the write pointer of the event-based scheduler. For example, the target speed is written every 100 ms. If a component has no real-time requirements, the event-based scheduler will only run it if there is computing time left. The capability manager monitors the global computing capacity and only registers new functions if a buffer x exists. Data can typically only be transferred in a secure manner (encryption or separate storage area) to the function that is currently scheduled to run. This typically ensures that the system bus is not overloaded by parallel transmission or arithmetic units by parallel decryption. It makes sense to design the memory between actuators/sensors and third-party software as a ring memory, since many small data packets with high real-time requirements are used for such a system, since a vehicle has many sensors and actuators. Furthermore, a ring memory can manage many read and write pointers in the same memory area. This in turn relieves the system bus between function and actuator/sensor.

The approach described here is not only limited to software functions, rather new capabilities can also be added in the form of new hardware.

An example procedure for registering new hardware is shown 4 . First, the new hardware is physically added to the overall system. The hardware starts and reads the skill memory. The skill monitor detects the new hardware and adds new skills to the skill store. The capabilities of the new hardware are then available in the overall system.

A possible underlying overall system for the method described herein is described below. In this regard, reference is made to the presentation of 5 referred.

The hardware is typically found in the lowest layer. These are the SoCs of the control units, which typically contain the computing power and memory, interfaces, etc. A large number of such hardware components are connected for the overall system, in particular via communication buses (for example PCI and/or Automotive Ethernet). Hardware can be flexibly added or removed to modify computing power. Any hardware can optionally be connected directly to sensors and/or actuators. Each piece of hardware typically has a capability store. This is a special memory area in which the available capabilities are stored in order to ensure quick availability when starting up. Hardware 1 to hardware n are connected to one another via the communication layer. Additional sensors and/or actuators can also be directly connected here. A hypervisor (type 1 or type 2) can optionally run on the hardware, which performs the secure separation of different partitions. The described mixed-critical orchestrator can be installed in the partitions. The orchestrator typically also determines the virtual network configuration, which defines and knows the communication options between different functions, and knows the real-time behavior of the entire communication chain, with which direct communication between the applications can be made possible. Functions and/or applications can be launched from the mixed-critical orchestrator. This is typically the abstracted functional software, which is executed separately from one another using different technologies can be. For example, this can be done as a pod or multi-container application, as a single container application, as a sandbox, as a virtual machine, as a web assembly with the appropriate runtime, or as a micro-VM. Real-time-capable functions can be used and offered by applications without affecting the security of the overall system.

the inside 5 The mixed critical orchestrator shown can be used in particular with the combination of event-based scheduler, skill manager and skill monitor in 1 be identified.

The procedure described here enables in particular a joint orchestration of real-time capable and non-critical content. A dynamic allocation of functions in all partitions is made possible. All resources of the overall system can be used by the mixed-critical orchestrator. The orchestrator typically assigns the function of a partition. This allows optimal utilization of the resources of each partition to be achieved. Reassignment of capabilities to partitions can occur, and concomitant flexible capability-to-ability assignments are possible. The mixed-critical orchestrator can allocate the capabilities of one or more partitions and can allocate and monitor the capability exactly where access is possible. In addition, thanks to the known dependencies, a reconfiguration of the capabilities for the partitions can also be carried out automatically and securely. Real-time capability for partitions with dynamic allocation is also provided. The combination of capability matrix and capability memory defines requirements for real-time capability. By comparing the requirements with the capabilities, the capability monitor can check whether the real-time requirements can be met and whether additional functions can be dynamically allocated. Cross-partition feature management can be provided by the mixed-critical orchestrator. Communication between several orchestrators enables function management across hardware and partitions. A high-performance execution can also take place through the use of ring memories.

• Ausführungsbeispiel 1: Abstandssensor mit Audiowarnung In einem Fahrzeugsystem mit 4 Zonen-HPCs und einer skalierbaren Computing Plattform (SCP) ist das beschriebene Verfahren mit den zugehörigen Architektur-Schichten installiert. Der Entwickler fügt nun eine Funktion zur Erkennung von Abständen mit zugehöriger Audiowarnung dem System hinzu. Dazu beschreibt er die benötigen Fähigkeiten in der Fähigkeitsmatrix (Abstandsensoren lesen, Audiowarnung ausgeben, Anforderungen an die Echtzeitfähigkeit des Ausgangsignals = 150 ms). Die Zonen-HPCs stellen jeweils für ihren Bereich die Fähigkeit Abstandsensoren und Audioausgabe bereit und die SCP entsprechende Rechenleistung auf einem Echtzeitfähigen CPU Kern. Der Fähigkeitsmonitor erkennt diese Fähigkeiten. Der Entwickler übergibt die Fähigkeitsmatrix an den Fähigkeitsmanager und dieser gibt die Rückmeldung, dass alle Anforderungen erfüllt werden können. Die Funktion wird dem Fahrzeug hinzugefügt.
• Ausführungsbeispiel 2: ADAS-Trajektorien Prädiktion Für eine Sicherheitsfunktion soll dem Fahrzeug eine Funktion zur Prädiktion der Trajektorie hinzugefügt werden. Diese muss in Echtzeit die Position des Fahrzeugs vorhersagen. Die Fähigkeitsmatrix ist wie folgt:
  • (Künstliche Intelligenz Hardware Beschleuniger, Umfeldmodell lesen, Telemetriedaten lesen, prädiktive Trajektorie ausgeben, Anforderung an die Echtzeitfähigkeit des Ausgangssignals = 20 ms). Nach der Überprüfung des Fähigkeitsmanagers wird festgestellt, dass eine solche Berechnung nur auf einer Hardware zur Verfügung steht. Die Funktion wird entsprechend dort allokiert, wo der Hardwarebeschleuniger zur Verfügung steht und entsprechend ausgeführt. Die Trajektorienprädiktion steht nun als neue Fähigkeit z.B. für ein Warnsystem zur Verfügung.
• Ausführungsbeispiel 3: ADAS-Funktionspaket Der Fahrer eines Fahrzeugs hat ein neues Funktionspaket mit 10 verschiedenen Funktionen gebucht. Die Funktionen sollen nun nachträglich seinem Fahrzeug hinzugefügt werden. Die zugehörigen Funktionsmatrizen werden geprüft vom Fähigkeitenmanager und es wird festgestellt, dass die Anforderungen an die Echtzeitfähigkeiten der Ausgangssignale nicht eingehalten werden können. Es können lediglich 4 von 10 Funktionen allokiert werden. In der skalierbaren Computing Plattform wird nun ein Hardware Modul hinzugefügt, welches sich entsprechend dem Verfahren im System anmeldet. Es steht nun mehr Rechenleistung zur Verfügung. Bei erneuter Allokation ergibt die Prüfung der Fähigkeitsmatrix, dass nun auch die restlichen 6 Funktionen allokiert werden können.

Three possible exemplary embodiments of specific implementations are described below as examples:

• Exemplary embodiment 1 distance sensor with audio warning The described method with the associated architecture layers is installed in a vehicle system with 4 zone HPCs and a scalable computing platform (SCP). The developer is now adding a distance detection function with associated audio warning to the system. To do this, he describes the required capabilities in the capability matrix (reading distance sensors, outputting an audio warning, requirements for the real-time capability of the output signal = 150 ms). The zone HPCs each provide the capability of distance sensors and audio output for their area and the SCP provide the corresponding computing power on a real-time capable CPU core. The skill monitor recognizes these skills. The developer passes the capability matrix to the capability manager, who gives feedback that all requirements can be met. The function is added to the vehicle.
• Exemplary embodiment 2 ADAS trajectory prediction For a safety function, a function for predicting the trajectory is to be added to the vehicle. This must predict the position of the vehicle in real time. The skill matrix is as follows:
  • (Artificial intelligence hardware accelerator, read environment model, read telemetry data, output predictive trajectory, requirement for real-time capability of the output signal = 20 ms). After reviewing the capability manager, it is determined that such a calculation is only available on one piece of hardware. The function is allocated accordingly where the hardware accelerator is available and executed accordingly. Trajectory prediction is now available as a new ability, for example for a warning system.
• Exemplary embodiment 3: ADAS function package The driver of a vehicle has booked a new function package with 10 different functions. The functions are now to be added later to his vehicle. The associated function matrices are checked by the capabilities manager and it is determined that the requirements for the real-time capabilities of the output signals cannot be met. Only 4 out of 10 functions can be allocated. A hardware module is now added to the scalable computing platform, which registers itself in the system according to the procedure. It is now more computing power available. With renewed allocation, checking the capability matrix shows that the remaining 6 functions can now also be allocated.

Mentioned steps of the method according to the invention can be carried out in the order given. However, they can also be executed in a different order, as far as this is technically reasonable. In one of its implementations, for example with a specific combination of steps, the method according to the invention can be carried out in such a way that no further steps are carried out. In principle, however, further steps can also be carried out, including those which are not mentioned.

It should be noted that in the claims and in the description features can be described in combination, for example to facilitate understanding, although they can also be used separately. The person skilled in the art recognizes that such features can also be combined independently of one another with other features or combinations of features.

Back-references in dependent claims can identify preferred combinations of the respective features, but do not exclude other combinations of features.

Claims (10)

Method for adding and/or managing functions on a computing unit (RE) of a vehicle, namely functions with a real-time requirement and functions without a real-time requirement, the method having the following steps: - Capture, for a respective function to be added, a respective requirement profile, - Recording a capability profile of the processing unit (RE), and - Adding the function only if the requirements profile corresponds to the skills profile. procedure after claim 1 , - wherein the requirements profile contains one or more requirements, and - wherein the requirements profile corresponds to the skills profile if all the requirements contained in the requirements profile are also contained in the skills profile. Method according to one of the preceding claims, - wherein the skills profile includes at least one capacity utilization indicator. procedure after claim 3 , - wherein the requirement profile contains a computing power requirement, and - wherein the requirement profile only corresponds to the capability profile if the computing power requirement is assessed as likely to be achievable. Method according to one of the preceding claims, - wherein the requirements profile includes one or more real-time requirements, and - where the requirement profile only corresponds to the capability profile if the real-time requirements can be met according to the capability profile. Method according to one of the preceding claims, - wherein the requirements profile includes one or more access requirements to vehicle components, and - The requirements profile only corresponds to the skills profile if the access requirements can be met according to the skills profile. Method according to one of the preceding claims, - wherein, after adding a function, a utilization indicator of the computing unit (RE) is monitored for a period of time, and - where the function or another function is removed again, moved to another partition, executed with less redundancy, scaled down, and/or executed on another computing unit in the vehicle or outside the vehicle if the utilization indicator during the Period for at least one control time is at least as large as a threshold. Method according to one of the preceding claims, - wherein the computing unit (RE) has a variable number of hardware components, and - wherein the capability profile contains a listing of the currently available hardware components. Method according to one of the preceding claims, - a partition of the computing unit (RE) being selected for a respective function to be added, and - where the function is assigned to the selected partition for execution. A method according to any one of the preceding claims, further comprising the step of, after a function to be added has been decided to be added or not: - Sending, to an external entity, a feedback on whether the function has been added or not.

Images