WO2023138721A1 - Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit - Google Patents

Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit Download PDF

Info

Publication number
WO2023138721A1
WO2023138721A1 PCT/DE2022/200308 DE2022200308W WO2023138721A1 WO 2023138721 A1 WO2023138721 A1 WO 2023138721A1 DE 2022200308 W DE2022200308 W DE 2022200308W WO 2023138721 A1 WO2023138721 A1 WO 2023138721A1
Authority
WO
WIPO (PCT)
Prior art keywords
function
capability
functions
profile
real
Prior art date
Application number
PCT/DE2022/200308
Other languages
English (en)
French (fr)
Inventor
Konrad Hilarius
Albert Kos
Original Assignee
Continental Automotive Technologies GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive Technologies GmbH filed Critical Continental Automotive Technologies GmbH
Publication of WO2023138721A1 publication Critical patent/WO2023138721A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/505—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the load
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine

Definitions

  • the invention relates to a method for generating a capability profile of a computing unit in 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. It has hitherto proved 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.
  • 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:
  • 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.
  • the capability profile can be used to decide whether a new function can be added.
  • 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 state 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.
  • the status can be a current status.
  • Conditions can change over time.
  • 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.
  • the computing unit has a variable number of hardware components.
  • 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.
  • 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, a comparison can be made as to whether a specific graphics accelerator unit is present and is required by a graphics-intensive function.
  • 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.
  • 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.
  • adding or removing a hardware component one or more of the following hardware components can be added or removed:
  • Compute component accelerator component, storage component.
  • variable hardware components can be such components.
  • components of this type 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.
  • an accelerator component can be configured to accelerate certain tasks, for example graphical calculations.
  • a memory component can be configured to store data temporarily and/or permanently.
  • one or more sensors and/or actuators can be added or removed.
  • variable hardware components can be sensors and/or actuators.
  • the computing unit can have a variable number of partitions.
  • 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.
  • each function is assigned to a partition or is assigned when a partition is added and registered accordingly.
  • 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.
  • 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.
  • the computing unit can have a variable number of software functions. For example, functions can be added and/or removed again at runtime.
  • 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 including a listing of the currently available software functions in the capability profile, it is possible in particular to ensure that the information required in this regard is available when an addition is made.
  • software functions 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.
  • the method can also have the following steps: determining a requirements profile for a function added to the computing unit,
  • 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.
  • 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:
  • functions can be added and/or orchestrated in a particularly flexible manner.
  • this can relate both to functions with a real-time requirement and to functions without a real-time requirement.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the requirement profile can contain a computing power requirement.
  • the requirement profile can only correspond to the capability profile if the computing power requirement is assessed as likely to be achievable.
  • the utilization indicator already mentioned can be used in particular, with a computing power requirement being able 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 is, 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.
  • 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.
  • 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 request, 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.
  • the requirement profile can contain one or more access requirements for vehicle components.
  • 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.
  • a utilization indicator of the processing unit is monitored for a period of time.
  • 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.
  • 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
  • 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.
  • 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 that require computing capacity are dispensed with. It can also be scaled down, ie run with a lower graphics resolution or longer check intervals, for example.
  • the processing unit can have a variable number of hardware components.
  • 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.
  • 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.
  • 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.
  • Orchestration means in particular one or more of the following functionalities:
  • 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.
  • 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:
  • 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, if it is accepted by many or all vehicles, successful use of the function can be assumed.
  • the feature monitor can create a compatibility indicator for the feature. This compatibility indicator includes a reference, for example to the current skill profile. The skill manager can share this indicator with other managers.
  • Fig. 1 a schematic representation of several components
  • Fig. 2 a flowchart
  • Fig. 5 a relationship between functions and hardware.
  • a computing unit can be, for example, a high-performance control unit (HPC, High Performance Computing).
  • 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 a single function can be added by means of a function update.
  • 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.
  • 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.
  • PCIe plug-in cards
  • SOM scalable computing platforms
  • 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.
  • 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.
  • 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 may indicate that a function needs to access certain components at certain intervals or 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.
  • the capability profile FP is also included in the capability profile FP, for example via 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.
  • a brake B, a temperature sensor T and a motor M are available as capabilities.
  • the ring memories R1, R2 are implemented in the usual way. They can be monitored and specifically controlled by the skill monitor.
  • 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.
  • 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.
  • 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.
  • ring memories represent a fast communication solution.
  • the procedure described here extends in particular existing concepts of orchestrator components to include capability management for real-time capable Provide function management and allocation, especially 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.
  • Procedures for registering a new function and deregistering an existing function are shown in FIG. 2 .
  • a developer first defines the function and required skills.
  • a request for the required capabilities is then made in the target system.
  • 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.
  • the signing can be performed by a function provider, a capability provider and/or a capability manager.
  • the skill monitor finds a new skill in memory.
  • the function is registered in the event-based scheduler, and then the function is executed.
  • a function deletion event is triggered.
  • the capability manager deletes the function's entry in the event-based scheduler.
  • the function manager 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.
  • 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.
  • 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 skills monitor can check the signatures of all participants before notifying the skills 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.
  • 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 as well as 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 can receive a pointer to the buffer that has an action to check the signature required. He typically interacts with the capability manager, which triggers corresponding or suitable mitigation strategies in the event of a conflict.
  • a capability abstraction is described below.
  • a function for determining precipitation serves as an example.
  • a new function for determining precipitation can access the following abilities:
  • 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.
  • These skills can thus be written to a file and stored encrypted and signed by the function provider in the skills store.
  • This can be referred to as a capability matrix or a capability profile.
  • 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.
  • capabilities may specifically be transactions that distribute status or perform other tasks required for the capability's correct outcome.
  • 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.
  • the capability monitor can implement methods for participants to ensure that the last signed, valid state update related to their commitment to the capability can be communicated to the function, thereby guaranteeing the correct result of the capability state and data for all protocol-compliant functions.
  • the capability matrix has the following structure:
  • 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.
  • the function manager allocates ring memory per partition.
  • the function manager can also optionally have several ring buffers per function allocate.
  • 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.
  • 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.
  • 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 processing units by parallel decryption.
  • 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.
  • FIG. 4 shows an exemplary procedure for registering new hardware.
  • 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.
  • 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. In addition, more can be found here Sensors and/or actuators can be connected directly.
  • 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 that can be executed separately using different technologies. 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 mixed critical orchestrator shown in FIG. 5 can be identified in particular with the combination of event-based scheduler, capability manager and capability monitor in FIG.
  • 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 it can be accessed. In addition, due to the known dependencies, a reconfiguration of the Skills related to the partitions are automated and performed securely. Real-time capability for partitions with dynamic allocation is also provided.
  • 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.
  • Exemplary embodiment 1 distance sensor with audio warning
  • the method described with the associated architecture layers is installed in a vehicle system with 4 zone HPCs and a scalable computing platform (SCP).
  • SCP scalable computing platform
  • 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 trajectories prediction
  • 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:
  • 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. More computing power is now available. With renewed allocation, checking the capability matrix shows that the remaining 6 functions can now also be allocated.
  • 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.
  • the method according to the invention can be carried out in such a way that no further steps are carried out. However, it can in principle, further steps can also be carried out, including those which are not mentioned.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit eines Fahrzeugs, wobei auf der Recheneinheit eine oder mehrere Funktionen mit Echtzeitanforderung und eine oder mehrere Funktionen ohne Echtzeitanforderung laufen, wobei ein Zustand der Recheneinheit erfasst und basierend darauf das Fähigkeitenprofil erzeugt wird.

Description

Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit
Die Erfindung betrifft ein Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit eines Fahrzeugs.
Recheneinheiten werden in modernen Kraftfahrzeugen verwendet, um eine deutlich zunehmende Anzahl an Funktionen auszuführen. Beispielsweise können Fahrassistenzfunktionen und Komfortfunktionen auf einer Recheneinheit ausgeführt werden. Als schwierig hat es sich bislang erwiesen, eine in einem Fahrzeug verwendete Recheneinheit so flexibel auszuführen, dass auch nach Auslieferung des Fahrzeugs ein flexibles Verwalten von Funktionen möglich ist.
Es ist eine Aufgabe der Erfindung, diesbezüglich eine alternative oder bessere Vorgehensweise bereitzustellen. Dies wird erfindungsgemäß durch ein Verfahren gemäß Anspruch 1 erreicht. Vorteilhafte Ausgestaltungen können beispielsweise den Unteransprüchen entnommen werden. Der Inhalt der Ansprüche wird durch ausdrückliche Inbezugnahme zum Inhalt der Beschreibung gemacht.
Die Erfindung betrifft ein Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit eines Fahrzeugs, wobei auf der Recheneinheit eine oder mehrere Funktionen mit Echtzeitanforderung und eine oder mehrere Funktionen ohne Echtzeitanforderung laufen. Das Verfahren weist folgende Schritte auf:
Erfassen eines Zustands der Recheneinheit, und
Erzeugen des Fähigkeitenprofils in Abhängigkeit von dem Zustand der Recheneinheit.
Mittels eines solchen Verfahrens kann ein Fähigkeitenprofil bereitgestellt werden, welches dazu dienen kann, die aktuellen Fähigkeiten der Recheneinheit anzuzeigen. Das Fähigkeitenprofil kann insbesondere dazu benutzt werden, um zu entscheiden, ob eine neue Funktion hinzugefügt werden kann. Insbesondere kann das Fähigkeitenprofil hierzu anzeigen, ob bestimmte Funktionen oder Komponenten verfügbar sind und/oder ob eine aktuelle Rechenkapazität oder eine erwartete Rechenkapazität ausreicht. Das Fähigkeitenprofil kann beispielsweise in Form einer Tabelle oder einer Matrix, beispielsweise einer Fähigkeitenmatrix, bereitgestellt werden. Es kann insbesondere im Rahmen eines Verfahrens verwendet werden, welches entscheidet, ob eine Funktion hinzugefügt werden kann oder nicht. Auf die andernorts hierin gegebenen Ausführungen sei verwiesen, wobei auf alle beschriebenen Ausführungen und Varianten zurückgegriffen werden kann.
Unter einer Funktion mit Echtzeitanforderung kann insbesondere eine Funktion verstanden werden, welche in vordefinierten oder bestimmten Zeitabständen Informationen benötigt, bestimmte Zugriffe auf andere Fähigkeiten oder Funktionen oder auch auf Hardwarekomponenten benötigt, oder Informationen an andere Komponenten absenden muss. Dies wird typischerweise von einer jeweiligen Funktion vorgegeben, wobei insbesondere definiert sein kann, welche Echtzeitanforderungen eine bestimmte Funktion hat. Funktionen ohne Echtzeitanforderung haben derartige Anforderungen typischerweise nicht, wobei es bei Funktionen ohne Echtzeitanforderung typischerweise ausreicht, die Funktion dann auszuführen, wenn gerade Rechenkapazität verfügbar ist. In typischen Implementierungen sind Funktionen mit Echtzeitanforderung sicherheitskritische Funktionen, wohingegen Funktionen ohne Echtzeitanforderung nicht sicherheitskritische Funktionen sind. Funktionen mit Echtzeitanforderung können insbesondere in die Fahrt eines Kraftfahrzeugs eingreifen, beispielsweise aufgrund eines überwachten Abstands einen Bremsvorgang auslösen, oder vor einer drohenden Gefahr warnen.
Unter dem Zustand der Recheneinheiten kann insbesondere ein Merkmal oder eine Gesamtheit von Merkmalen verstanden werden, welche die Fähigkeiten der Recheneinheit repräsentieren. Das Fähigkeitenprofil zeigt dies in einer Art und Weise an, wie es für eine Weiterverarbeitung geeignet ist. Der Zustand kann insbesondere ein aktueller Zustand sein. Zustände können sich im Zeitverlauf verändern. Das Fähigkeitenprofil kann insbesondere einen Indikator für eine aktuelle Auslastung beinhalten. Dabei kann es sich insbesondere um eine aktuelle Auslastung von Einheiten handeln, welche Berechnungen ausführen, Daten speichern und/oder Daten übertragen. Es können auch mehrere solche Indikatoren verwendet werden. Beispielsweise kann der Indikator eine CPU-Auslastung anzeigen, wodurch erkennbar wird, ob noch weitere Funktionen ausgeführt werden können.
Gemäß einer vorteilhaften Ausführung weist die Recheneinheit eine variable Anzahl an Hardwarekomponenten auf. Dies kann insbesondere bedeuten, dass es möglich ist, Hardwarekomponenten zur Recheneinheit hinzuzufügen und auch von ihr zu entfernen. Es ist somit nicht während der Lebenszeit eines Kraftfahrzeugs konstant, welche Fähigkeiten die Recheneinheit hat. Das Fähigkeitenprofil kann insbesondere eine Auflistung der aktuell vorhandenen Hardwarekomponenten beinhalten. Dies kann dazu dienen, bei eventuell hinzuzufügenden Funktionen zu ermitteln, ob die zur Ausführung einer Funktion erforderlichen Hardwarekomponenten überhaupt vorhanden sind. Beispielsweise kann abgeglichen werden, ob eine bestimmte Grafikbeschleunigereinheit vorhanden ist, welche von einer grafikintensiven Funktion benötigt wird. Die Auflistung der aktuell vorhandenen Hardwarekomponenten kann auch solche Hardwarekomponenten beinhalten, welche separate Einheiten sein können. Beispielsweise kann sie anzeigen, ob das Fahrzeug Sensoren wie beispielsweise einen Abstandssensor oder einen Regensensor aufweist. Dadurch kann beispielsweise bei einer Funktion, die einen Regensensor benötigt, vorab bereits ermittelt werden, ob ein Regensensor im Fahrzeug überhaupt vorhanden ist.
Beim Hinzufügen oder Entfernen einer Hardwarekomponente kann die Auflistung der aktuell vorhandenen Hardwarekomponenten vorteilhaft aktualisiert werden. Dadurch ist immer der aktuelle Zustand abgebildet, so dass immer aktuell ermittelt werden kann, ob die für eine bestimmte Funktion benötigten Hardwarekomponenten vorhanden sind. Beim Hinzufügen oder Entfernen einer Hardwarekomponente können insbesondere eine oder mehrere der folgenden Hardwarekomponenten hinzugefügt oder entfernt werden:
Rechenkomponente, Beschleunigerkomponente, Speicherkomponente.
Anders ausgedrückt kann es sich bei den variablen Hardwarekomponenten um derartige Komponenten handeln. Gerade bei derartigen Komponenten ist es besonders sinnvoll, eine aktuelle Auflistung darüber zu haben, so dass bei einer eventuell hinzuzufügenden Funktion unmittelbar ermittelt werden kann, ob ein Hinzufügen der Funktion möglich ist oder nicht.
Eine Rechenkomponente kann insbesondere zum Ausführen von Rechenoperationen konfiguriert sein. Eine Beschleunigerkomponente kann insbesondere zum Beschleunigen bestimmter Aufgaben, beispielsweise graphischer Berechnungen, konfiguriert sein. Eine Speicherkomponenten kann beispielsweise zum temporären und/oder zum dauerhaften Speichern von Daten konfiguriert sein.
Beim Hinzufügen oder Entfernen einer Hardwarekomponente können insbesondere ein oder mehrere Sensoren und/oder Aktoren hinzufügt oder entfernt werden.
Anders ausgedrückt kann es sich bei den variablen Hardwarekomponenten oder zumindest einem Teil davon um Sensoren und/oder Aktoren handeln.
Beispielsweise kann es sich um Sensoren wie Regensensor, Abstandssensor, Parksensor, Kamera oder andere Sensoren handeln. Es kann sich um Aktoren wie beispielsweise Motoren für Scheibenwischer oder Fensterheber, oder um Betätiger für Komponenten wie Kofferraumdeckel oder Türen handeln. Auch bei derartigen Komponenten ist es sinnvoll, eine aktuelle Auflistung darüber zu haben, um bei einer eventuell hinzuzufügenden Funktion unmittelbar ermitteln zu können, ob ein Hinzufügen der Funktion möglich ist. Die Recheneinheit kann insbesondere eine variable Anzahl an Partitionen aufweisen. Das Fähigkeitenprofil kann insbesondere eine Auflistung der aktuell vorhandenen Partitionen beinhalten. Unter einer Partition kann dabei insbesondere ein Speicherbereich oder ein anderer Bereich verstanden werden, auf welchem eine Funktion lauffähig ist. Typischerweise ist jede Funktion einer Partition zugewiesen oder wird beim Hinzufügen einer Partition zugewiesen und entsprechend registriert.
Insbesondere können eine Partition oder einige der Partitionen echtzeitfähig sein. Zusätzlich oder alternativ können eine Partition oder einige der Partitionen nicht echtzeitfähig sein. Unter einer echtzeitfähigen Partition versteht man insbesondere eine Partition, bei welcher sichergestellt ist, dass eine darauf laufende Funktion in bestimmten Zeitabständen und/oder zu bestimmten Zeitpunkten auf gewisse andere Einheiten wie beispielsweise Hardwarekomponenten oder andere Funktionen zugreifen kann. Bei nicht echtzeitfähigen Partitionen ist eine derartige Fähigkeit nicht vorhanden. Insbesondere können Funktionen mit Echtzeitanforderung auf echtzeitfähigen Partitionen laufen, und Funktionen ohne Echtzeitanforderung können insbesondere auf nicht echtzeitfähigen Partitionen laufen.
Die Recheneinheit kann insbesondere eine variable Anzahl an Softwarefunktionen aufweisen. Beispielsweise können zur Laufzeit Funktionen hinzugefügt und/oder auch wieder entfernt werden. Das Fähigkeitenprofil kann insbesondere eine Auflistung der aktuell vorhandenen Softwarefunktionen beinhalten. Dies trägt der Tatsache Rechnung, dass manche Funktionen nicht nur auf besondere Hardwarekomponenten zugreifen müssen oder besondere Anforderungen bezüglich der Rechenkapazität haben, sondern dass sie auch auf andere Funktionen zugreifen müssen. Durch die Hinzunahme einer Auflistung der aktuell vorhandenen Softwarefunktionen in das Fähigkeitenprofil kann insbesondere erreicht werden, dass die diesbezüglich benötigte Information beim eventuellen Hinzufügen zur Verfügung steht. Insbesondere ist es möglich, dass Softwarefunktionen aufeinander aufbauen. Eine neu hinzuzufügende Funktion kann also beispielsweise überprüfen, ob bestimmte Funktionen von anderen Softwarekomponenten bereits bereitgestellt werden, und kann dann zur Laufzeit auf diese zugreifen. Ein Entwickler kann sich somit auf die für ihn relevanten technischen Fähigkeiten beschränken.
Gemäß einer Weiterbildung kann das Verfahren ferner folgende Schritte aufweisen: 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.
Dadurch kann sichergestellt werden, dass eine Funktion nur dann hinzugefügt wird, wenn das Anforderungsprofil zu dem Fähigkeitenprofil korrespondiert. Dies kann insbesondere bedeuten, dass das Anforderungsprofil anzeigt, dass alle von der Funktion benötigten Fähigkeiten, wie im Anforderungsprofil angegeben, bereitgestellt werden können. Beispielweise kann dies bedeuten, dass eine ausreichende freie Rechenkapazität vorhanden ist, dass benötigte Hardwarekomponenten vorhanden sind und/oder dass benötigte andere Funktionen, insbesondere Softwarefunktionen, vorhanden sind.
Nachfolgend werden weitere mögliche Aspekte beschrieben. Diese können als eigenständige Erfindungsaspekte betrachtet werden. Sie können jedoch auch beliebig untereinander und/oder mit anderen hierin beschriebenen Aspekten kombiniert werden.
Die Erfindung betrifft ein Verfahren zum Hinzufügen und/oder Orchestrieren von Funktionen auf einer Recheneinheit eines Fahrzeugs. Es handelt sich dabei um Funktionen mit Echtzeitanforderung und um Funktionen ohne Echtzeitanforderung. Das Verfahren weist folgende Schritte auf:
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.
Mittels eines solchen Verfahrens kann ein Hinzufügen und/oder ein Orchestrieren von Funktionen besonders flexibel gestaltet werden. Insbesondere kann sich dies sowohl auf Funktionen mit Echtzeitanforderung wie auch auf Funktionen ohne Echtzeitanforderung beziehen. Dadurch kann eine Recheneinheit für beide Arten von Funktionen verwendet werden. Integration und Flexibilität werden dadurch deutlich erhöht. Auf die andernorts hierin gegebene Beschreibung von Funktionen mit oder ohne Echtzeitanforderung sei verwiesen.
Bei der Recheneinheit kann es sich insbesondere um eine Einheit in einem Fahrzeug handeln, welche Rechenoperationen ausführt. Sie kann beispielsweise eine oder mehrere Hardwarekomponenten aufweisen, welche beispielsweise unterschiedliche Rechenaufgaben, Speicheraufgaben oder Datentransferaufgaben ausführen können. Der Begriff der Recheneinheit kann auch weiter gefasst werden und beispielsweise Komponenten wie Sensoren oder Ausgabegeräte beinhalten.
Ein Anforderungsprofil gibt insbesondere an, welche Anforderungen eine jeweilige Funktion hat. Dadurch identifiziert es für eine jeweilige Funktion die benötigten Fähigkeiten und erlaubt einen Abgleich mit den tatsächlich vorhandenen Fähigkeiten, welche durch das Fähigkeitenprofil repräsentiert werden. Ein Erfassen eines Fähigkeitenprofils kann insbesondere ein Erzeugen eines Fähigkeitenprofils beinhalten, oder das Erfassen eines Fähigkeitenprofils kann ein Erzeugen eines Fähigkeitenprofils sein. Bezüglich des Erzeugens eines Fähigkeitenprofils sei auf die andernorts hierin gegebene Beschreibung verwiesen. Alle beschriebenen Ausführungen und Varianten können angewandt werden. Das Erfassen eines Fähigkeitenprofils kann jedoch auch beispielsweise das Auslesen eines bereits vorher erzeugten Fähigkeitenprofils aus einer dafür vorgesehenen Speichervorrichtung beinhalten. Das Anforderungsprofil kann insbesondere eine oder mehrere Anforderungen beinhalten. Eine Anforderung stellt typischerweise dar, was die jeweils betrachtete Funktion benötigt, um ordnungsgemäß funktionieren zu können. Das Anforderungsprofil kann insbesondere zu dem Fähigkeitenprofil korrespondieren, wenn alle im Anforderungsprofil beinhalteten Anforderungen auch im Fähigkeitenprofil enthalten sind.
Das Fähigkeitenprofil kann insbesondere mindestens einen Auslastungsindikator beinhalten. Dieser kann angeben, wie stark die Komponenten der Recheneinheit, insbesondere datenverarbeitende Einheiten, ausgelastet sind. Der Auslastungsindikator gibt somit an, wieviel Rechenkapazität oder Kapazität von Kommunikationsmodulen, z.B. Bandbreite oder Zykluszeit von Signalen, noch verfügbar ist. Der Auslastungsindikator kann insbesondere über einen vorgegebenen Zeitraum ermittelt werden. Dieser kann beispielsweise ein vorgegebener Zeitraum in der Vergangenheit von einem jeweils betrachteten Zeitpunkt aus sein.
Zur Ermittlung des Auslastungsindikators kann insbesondere ein eventbasierter Scheduler, ein Fähigkeitsmanager und/oder ein Fähigkeitsmonitor betrachtet werden. Derartige Komponenten können Daten liefern, welche zur Berechnung eines Auslastungsindikators herangezogen werden können. Dadurch kann ein realistischer Auslastungsindikator erzeugt werden. Auf die andernorts hierin gegebene Beschreibung sei verwiesen.
Das Anforderungsprofil kann insbesondere eine Rechenleistungsanforderung beinhalten. Das Anforderungsprofil kann insbesondere nur dann zum Fähigkeitenprofil korrespondieren, wenn die Rechenleistungsanforderung als voraussichtlich erfüllbar bewertet wird. Hierzu kann insbesondere der bereits erwähnte Auslastungsindikator herangezogen werden, wobei eine Rechenleistungsanforderung mit dem Auslastungsindikator abgeglichen werden kann. Der Auslastungsindikator kann insbesondere anzeigend dafür sein, welche Rechenleistungsanforderung voraussichtlich erfüllbar ist und welche nicht. Je höher der Auslastungsindikator ist, desto weniger Rechenleistungsanforderung ist typischerweise erfüllbar.
Echtzeitanforderungen können auch Redundanz ermöglichen, da beim rechtzeitigen Übermitteln von Ergebnissen Anforderungen bezüglich funktionaler Sicherheit durch Redundanz gewährleistet werden können.
Das Anforderungsprofil kann insbesondere eine oder mehrere Echtzeitanforderungen beinhalten. Dies kann insbesondere bei Funktionen mit Echtzeitanforderung der Fall sein. Das Anforderungsprofil kann insbesondere nur dann zum Fähigkeitenprofil korrespondieren, wenn die Echtzeitanforderungen laut Fähigkeitenprofil erfüllbar sind. Insbesondere kann dies bedeuten, dass eine Echtzeitanforderung wie beispielsweise der Zugriff auf bestimmte Funktionen oder Hardwarekomponenten innerhalb von bestimmten Zeiträumen oder in bestimmten Zeitabständen von der Recheneinheit bereitgestellt werden kann.
Ein eventueller Zugriff auf Fähigkeiten kann insbesondere beim Hinzufügen der Funktion gewährleistet werden. Dies kann sowohl eine Autorisierung wie auch eine Authentifizierung beinhalten. Dadurch kann insbesondere sichergestellt werden, dass die benötigten Anforderungen dann zur Laufzeit auch tatsächlich zur Verfügung gestellt werden.
Das Anforderungsprofil kann insbesondere eine oder mehrere Zugriffsanforderungen auf Fahrzeugkomponenten beinhalten. Das Anforderungsprofil kann insbesondere nur dann zum Fähigkeitenprofil korrespondieren, wenn die Zugriffsanforderungen laut Fähigkeitenprofil erfüllbar sind. Derartige Zugriffsanforderungen können beispielsweise den Zugriff auf Komponenten wie bestimmte Hardwarekomponenten beinhalten. Beispielsweise kann es sich um eine Zugriffsanforderung auf einen Regensensor, auf einen Abstandssensor oder auf ein bild- oder tonausgebendes Gerät handeln. Das Fähigkeitenprofil kann typischerweise anzeigen, ob derartige Komponenten vorhanden sind. Auf die andernorts hierin gegebene Beschreibung sei verwiesen. Gemäß einer vorteilhaften Ausführung wird nach dem Hinzufügen einer Funktion ein Auslastungsindikator der Recheneinheit für einen Zeitraum überwacht. Die Funktion oder eine andere Funktion können insbesondere wieder entfernt werden, in eine andere Partition verschoben werden, mit einer geringeren Redundanz ausgeführt werden und/oder herunterskaliert werden, wenn der Auslastungsindikator während des Zeitraums für mindestens eine Kontrollzeit mindestens so groß ist wie ein Schwellenwert. Dadurch kann eine geeignete Mitigationsstrategie angewendet werden, wenn angezeigt wird, dass trotz der vorab erfolgten Überprüfung doch keine ausreichende Rechenkapazität für eine Funktion zur Verfügung steht. Die Mitigationsstrategie kann auch eine Signallaufzeit, beispielsweise aus dem Auslastungsindikator, in Betracht ziehen. Sie kann auch beinhalten, dass die Funktion in einem anderen Rechnersystem oder einer anderen Recheneinheit im Fahrzeug oder außerhalb des Fahrzeugs (vernetzte Cloud/Edge) ausgeführt oder platziert wird. Das Fahrzeug kann sich beispielsweise bewegen. Wenn ortsabhängige Hardware-Komponenten (z.B. ITS Stationen, IST = Intelligent Transport System) verfügbar sind, kann die Fähigkeit von einer externen Hardware angeboten werden, damit kann die lokale Softwarekomponente, welche die gleiche Fähigkeit bereitstellt, abgeschaltet und/oder herunterskaliert werden. Die genannten Vorgehensweisen können insbesondere als jeweilige Mitigationsstrategien bezeichnet werden. Die Funktion kann dann beispielsweise wieder entfernt werden. Es kann jedoch auch eine andere Funktion entfernt werden, wobei beispielsweise eine Priorisierung vorgesehen werden kann, welche Funktion im Fall einer erkannten Überlastung bzw. einer Schwellenwertüberschreitung zuerst entfernt werden soll. Dies kann auch bedeuten, dass eine zuletzt hinzugefügte Funktion erhalten bleibt, wohingegen eine andere Funktion entfernt wird, weil die zuletzt hinzugefügte Funktion wichtiger ist. Eine Funktion kann auch in eine andere Partition verschoben werden, in welcher beispielsweise mehr Rechenkapazität oder mehr Speicherplatz verfügbar ist. Das Ausführen mit einer geringeren Redundanz kann beispielsweise bedeuten, dass auf gewisse Sicherheitsvorkehrungen in der Funktion, welche Rechenkapazität benötigen, verzichtet wird. Sie kann auch herunterskaliert werden, d.h. beispielsweise mit einer niedrigeren Grafikauflösung oder mit längeren Überprüfungsintervallen ausgeführt werden. Die Recheneinheit kann insbesondere eine variable Anzahl an Hardwarekomponenten aufweisen. Das Fähigkeitenprofil kann insbesondere eine Auflistung der aktuell vorhandenen Hardwarekomponenten beinhalten. Somit kann sichergestellt werden, dass benötigte Hardwareeinheiten, welche eine Funktion zum Ausführen benötigt, auch tatsächlich vorhanden sind, bevor die Funktion hinzugefügt wird. Auf die andernorts hierin gegebene Beschreibung sei verwiesen.
Insbesondere kann jede Funktion abstrahiert in ihrem eigenen Format, zum Beispiel in einem Container, einem Pod oder einem Web Assembly, unabhängig lauffähig sein. Vom Verfahren kann ihr eine Hardwareinstanz oder eine durch Partitionierung vorgegebene Softwarepartition zugeordnet werden. Auch andere Partitionen können entsprechend zugeordnet werden. Dadurch kann beispielsweise bereits beim Hinzufügen der Funktion eine Hardware und/oder eine Partition zugeordnet werden, so dass die Funktion die benötigten Ressourcen bekommt. Dies kann entsprechend registriert werden, beispielsweise in einem eventbasierten Scheduler, so dass die Funktion ausgeführt und zur Laufzeit vom einem Monitor, beispielsweise dem hierin beschriebenen Fähigkeitenmonitor, überwacht werden kann. Die Recheneinheit stellt typischerweise verschiedene Hardwareinstanzen bereit, die mehrere Partitionen haben. Dabei kann es sich insbesondere um echtzeitfähige und nicht echtzeitfähige Partitionen handeln. Dadurch können unterschiedliche Anforderungen von Funktionen berücksichtigt werden.
Unter einer Orchestrierung werden insbesondere eine oder mehrere der folgenden Funktionalitäten verstanden:
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.
Für eine jeweilige hinzuzufügende Funktion kann insbesondere eine Partition der Recheneinheit ausgewählt werden. Die Funktion kann der ausgewählten Partition zur Ausführung zugewiesen werden. Dies ermöglicht eine unmittelbare Zuweisung einer Partition, in welcher die Funktion platziert und registriert wird. Durch die Registrierung, beispielsweise in einem eventbasierten Scheduler, wird eine Überwachung zur Laufzeit ermöglicht.
Das Verfahren kann gemäß einer vorteilhaften Ausführung ferner folgenden Schritt aufweisen, nachdem bei einer hinzuzufügenden Funktion entschieden wurde, ob diese hinzugefügt wird oder nicht:
Senden, an eine externe Einheit, einer Rückmeldung darüber, ob die Funktion hinzugefügt wurde oder nicht hinzugefügt wurde.
Dadurch wird einem Entwickler von Funktionen eine Rückmeldung gegeben, ob seine Funktion erfolgreich implementiert wurde oder nicht. Die Entscheidung, ob eine Funktion hinzugefügt wird oder nicht, kann insbesondere für jedes Fahrzeug separat getroffen werden. Dies ermöglicht beispielsweise eine einfache und automatisierte Verwaltung von Fahrzeugflotten, wobei Funktionen für die Fahrzeuge der Fahrzeugflotte bereitgestellt werden können und eine individuelle Entscheidung erfolgt. Durch die eben erwähnte Rückmeldung kann nachverfolgt werden, ob die jeweilige Funktion bei ausreichend vielen Fahrzeugen auch tatsächlich lauffähig ist oder nicht. Wird sie beispielsweise nur von einer geringen Anzahl von Fahrzeugen oder auch von gar keinem Fahrzeug akzeptiert, so ist davon auszugehen, dass die Funktion nicht erfolgreich entwickelt wurde und/oder angepasst werden sollte. Wird sie jedoch von vielen oder allen Fahrzeugen akzeptiert, ist von einem erfolgreichen Einsatz der Funktion auszugehen. So kann beispielsweise der Funktionsmonitor einen Kompatibilitätsindikator für die Funktion erstellen. Dieser Kompatibilitätsindikator beinhaltet beispielsweise eine Referenz auf das aktuelle Fähigkeitsprofil. Der Fähigkeitenmanager kann diesen Indikator mit anderen Managern teilen.
Weitere Merkmale und Vorteile wird der Fachmann den nachfolgend mit Bezug auf die beigefügte Zeichnung beschriebenen Ausführungsbeispielen entnehmen. Dabei zeigen:
Fig. 1 : eine schematische Darstellung mehrerer Komponenten,
Fig. 2: ein Ablaufdiagramm,
Fig. 3: ein weiteres Ablaufdiagramm,
Fig. 4: ein weiteres Ablaufdiagramm, und
Fig. 5: einen Zusammenhang zwischen Funktionen und Hardware.
Grundsätzlich kann es sich bei einer Recheneinheit beispielsweise um ein hochperformantes Steuergerät (HPC, High Performance Computing) handeln. Dieses kann in einem Fahrzeug eine Vielzahl von Funktionen bereitstellen. Über den Lebenszyklus des Fahrzeugs können neue Funktionen entwickelt und hinzugefügt werden. Hierbei kann mittels eines Updates die komplette Steuergerätsoftware inklusive der neuen Funktion, oder mittels Funktionsupdate eine einzelne Funktion hinzugefügt werden. Typischerweise werden hierbei die Funktionen statisch allokiert und sind meist in der Softwarearchitektur an eine bestimmte Systempartition, an bestimmte Speicherbereiche und/oder bestimmte CPU-Kerne gebunden.
Bei bekannten Ausführungen wurde typischerweise durch gesamtheitliches Testen sichergestellt, dass die CPU-Kerne nie überlastet werden, um die Rechenoperationen in einer vorgegebenen Zeit rechtzeitig abschließen zu können. Dies ist bei der hierin beschriebenen Vorgehensweise nicht mehr nötig.
Weiterhin können Stecksysteme für Hardware verwendet werden, beispielsweise um einem Basisboard zusätzliche Rechenleistung hinzuzufügen. Dies geschieht beispielsweise über Steckkarten (PCIe) oder eigenständige SOM-Module. Diese modularen und erweiterbaren Hardwarekonzepte können auch als skalierbare Computing-Plattformen (SCP) bezeichnet werden.
Weiterhin können Ringspeicher und zugehörige Schnittstellen verwendet werden, die es beispielsweise ermöglichen, einen Echtzeitspeicherzugriff für mehrere zugreifende und schreibende Funktionen zu lösen.
Es können Hypervisorlösungen verwendet werden, um Ressourcen des Hardware-Zielsystems mittels Virtualisierungstechniken voneinander zu trennen.
Echtzeitbetriebssysteme können verwendet werden, welche die Rechtzeitigkeit bei der Bearbeitung von Daten in einer Laufzeitumgebung gewährleisten.
Orchestrierungssysteme können verwendet werden, welche beispielsweise eine Zuteilung von Ressourcen für abstrahierte Funktionen in Form von Containern ermöglichen, sowie entsprechende Interface-Spezifikationen und Runtimes. Zur Verwaltung von Informationen über Datensätze können unterschiedliche Methoden wie beispielsweise Hashing, Merkle trees etc. verwendet werden.
Bekannten Vorgehensweisen weisen insbesondere die folgenden Nachteile auf, welche mittels der hierin beschriebenen Vorgehensweisen vermieden werden können: 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.
Beispielsweise kann die Frage nicht beantwortet werden, ob alle Anforderungen einer Software zur Laufzeit erfüllt werden. Dies kann nur mit einem hohen Aufwand, beispielsweise durch Simulation, beantwortet werden.
Es existiert kein bekanntes Verfahren, um die Software mit den Fähigkeiten eines Steuergeräts abzugleichen und über die Partitionierung hinweg eine optimierte Allokation der Softwarekomponenten automatisiert zu halten. Dabei spielt nicht nur die Priorisierung der Softwarefunktionen in einer Laufzeitumgebung eine Rolle, sondern auch das Monitoring der Datenflüsse zwischen Aktorik, Sensorik und abstrakten Fähigkeiten, um den Einfluss der Softwarekomponenten untereinander beobachten zu können und gegebenenfalls Einfluss zu nehmen. Insbesondere ist die Verbindung zwischen Funktionen mit ihren abstrakten Fähigkeiten und Fahrzeugaktorik bzw. Sensorik von Bedeutung. Dies ist im bekannten Stand der Technik nicht möglich.
Mithilfe der hierin beschriebenen Vorgehensweise können auch nicht zertifizierte Softwarefunktionen Fahrzeugfunktionen verwenden, ohne sicherheitsrelevante Funktionen beeinflussen zu können. Wird die Rechenleistung in einem SCP erweitert oder ein einziges Modul geändert, wird typischerweise entsprechend auch die Funktionssoftware geändert. Hierbei kann es zu einer neuen Allokation von Software zu einer bestimmten Partition kommen. Eine Speicherverwaltung (zum Beispiel DMA) und Laufzeitverhalten werden typischerweise angepasst. Unbekannte Drittsoftware kann typischerweise nicht genutzt werden, da schädlicher Programmcode Einfluss auf das Laufzeitverhalten anderer Softwaremodule nehmen kann oder Sensor-/Aktor-Daten mitlesen oder ändern kann. Fig. 1 zeigt rein schematisch eine Anordnung mit unterschiedlichen Komponenten. Daran wird eine grundlegende Funktionsweise der hierin beschriebenen Vorgehensweise beschrieben.
Ein Entwickler E hat eine neue Funktion entwickelt und möchte diese auf einer Recheneinheit RE eines ansonsten nicht weiter dargestellten Kraftfahrzeugs implementieren. Hierzu kann zunächst auf ein Fähigkeitenprofil FP zugegriffen werden, welches anzeigt, welche Fähigkeiten die Recheneinheit RE aktuell hat. Das Fähigkeitenprofil FP wird im Zusammenspiel zwischen einem Fähigkeitsmanager, einem Fähigkeitsmonitor sowie einem eventbasierten Scheduler erzeugt. Deren Aufgaben werden nachfolgend beschrieben.
Der eventbasierte Scheduler hat typischerweise eine Liste aller implementierten Funktionen in einer Funktionsregistrierung. Beispielhaft sind hier Funktionen 1 , 2, 3, 4, n dargestellt. Diese werden in einer Laufzeitumgebung („service runtime“) ausgeführt. Sowohl zwischen der Funktionsregistrierung und dem eventbasierten Scheduler wie auch zwischen der Laufzeitumgebung und dem eventbasierten Scheduler werden Daten übertragen.
Der eventbasierte Scheduler sorgt typischerweise dafür, dass die Funktionen mit ihrer jeweiligen Echtzeitanforderung, sofern vorhanden, ausgeführt werden. Beispielsweise kann eine solche Echtzeitanforderung anzeigen, dass eine Funktion in bestimmten Abständen auf bestimmte Komponenten zugreifen muss oder bestimmte Berechnungen durchführen muss. Der eventbasierte Scheduler kann gegebenenfalls weniger wichtige oder weniger zeitkritische Funktionen verzögern oder abschalten, um dies sicherzustellen. Es kann auch eine Mitigationsstrategie angewandt werden, wie dies an anderer Stelle hierin beschrieben wird.
Der Fähigkeitsmanager steht unter anderem mit dem eventbasierten Scheduler in Verbindung und erzeugt aus Daten, welche er vom eventbasierten Scheduler erhält und welche beispielsweise eine aktuelle Auslastung anzeigen, das Fähigkeitenprofil FP. In das Fähigkeitenprofil FP gehen jedoch auch andere Informationen ein, beispielsweise über angeschlossene Komponenten. Hierauf wird weiter unten näher eingegangen werden.
Der Fähigkeitsmanager steht auch in Verbindung mit einem Fähigkeitsmonitor sowie einem Fähigkeitenspeicher. Im Fähigkeitenspeicher werden die aktuell vorhandenen Fähigkeiten gespeichert. Der Fähigkeitsmonitor überwacht die vorhandenen Fähigkeiten und steuert den Zugriff darauf. In der hier vorliegenden Implementierung sind als Fähigkeiten eine Bremse B, ein Temperatursensor T sowie ein Motor M vorhanden. Diese kommunizieren über vorliegend zwei Ringspeicher R1 , R2 mit dem eventbasierten Scheduler und mit ihren jeweils zugeordneten Funktionen, welche auf sie zugreifen. Es können auch mehr oder weniger Ringspeicher verwendet werden. Typischerweise ist jeder Fähigkeit ein jeweils eigener Ringspeicher zugeordnet. Die Ringspeicher R1 , R2 sind in üblicher Weise implementiert. Sie können von dem Fähigkeitsmonitor überwacht und gezielt gesteuert werden. Insbesondere kann der Scheduler den Zugriff für eine Funktion auf den Ringspeicher unterbinden oder erlauben, insbesondere durch Erteilen oder Löschen des zugehörigen Scheib- oder Lesepointers. Auf diese Weise kann gezielt der Zugriff von Funktionen auf die Ringspeicher verwaltet werden. Greift keine Funktion auf den Ringspeicher mehr zu, kann dieser deallokiert werden. Dies kann in einfacher Weise zum Deaktivieren einer Funktion genutzt werden, beispielsweise wenn der eventbasierte Scheduler wie bereits weiter oben erwähnt eine Funktion deaktivieren will, um einer anderen Funktion mehr Rechenkapazität zuzuweisen.
Eine Fähigkeitenabstraktion kann insbesondere dadurch erreicht werden, dass eine Fähigkeit einen Sensor oder einen Aktor zusammen mit zugehöriger Steuerung und Kommunikation abstrahiert. Beispielsweise kann die Fähigkeit „Regenerkennung“ einen Regensensor zusammen mit Steuergerät und Kommunikation abstrahieren. Die hier gezeigten Hardwarekomponenten Bremse B, Temperatursensor T und Motor M werden als Aktorik/Sensorik bezeichnet.
Ringspeicher stellen insbesondere eine schnelle Kommunikationslösung dar. Die hierin beschriebene Vorgehensweise erweitert insbesondere vorhandene Konzepte von Orchestratorkomponenten, um ein Fähigkeitsmanagement für echtzeitfähige Funktionsverwaltung und Allokierung bereitzustellen, insbesondere um die Nachteile vorhandener Automotive-Lösungen zu überwinden. Das intelligente Management durch den Fähigkeitsmanager, der insbesondere in Zusammenarbeit mit dem Fähigkeitsmonitor die Ringspeicher steuert, und mit dem eventbasierten Scheduler bildet eine besonders vorteilhafte Implementierung.
In Fig. 2 werden Vorgehensweisen zum Anmelden einer neuen Funktion und zum Abmelden einer vorhandenen Funktion gezeigt. Zum Anmelden einer neuen Funktion definiert zunächst ein Entwickler die Funktion und benötigte Fähigkeiten. Anschließend erfolgt eine Anfrage der benötigten Fähigkeiten im Zielsystem. Wenn die Fähigkeiten nicht verfügbar sind, kann die Funktion typischerweise nicht hinzugefügt werden. Wenn sie verfügbar sind, wird die Funktion dem Zielsystem in der Funktionsregistrierung hinzugefügt. Eine Fähigkeitsmatrix der Funktion wird signiert und dem Fähigkeitenspeicher hinzugefügt. Das Signieren kann insbesondere durch einen Funktionsanbieter, einen Fähigkeitsanbieter und/oder einen Fähigkeitsmanager erfolgen. Der Fähigkeitsmonitor findet anschließend eine neue Fähigkeit im Speicher. Die Funktion wird im eventbasierten Scheduler registriert, und anschließend wird die Funktion ausgeführt.
Zum Abmelden einer vorhandenen Funktion wird ein Event zum Löschen einer Funktion ausgelöst. Der Fähigkeitsmanager löscht den Eintrag der Funktion im eventbasierten Scheduler. Der Funktionsmanager stoppt anschließend die Funktion. Anschließend löscht der Funktionsmanager die Funktion in der Funktionsregistrierung und er löscht außerdem die zugehörige Fähigkeitsmatrix bzw. das zugehörige Fähigkeitenprofil.
Ein Entwickler kann beispielsweise eine Funktion entwickeln, welche er auf einem Fahrzeugsystem bzw. einer Recheneinheit applizieren möchte. Die Funktion hat typischerweise Abhängigkeiten von vorhandenen Fähigkeiten des Fahrzeugs und ändert bei der Allokation die Gesamtkonfiguration des Fahrzeugs. Im Verfahren kann sichergestellt werden, dass die neue Konfiguration lauffähig ist und alle benötigten Fähigkeiten und Abhängigkeiten vorhanden sind. Zunächst kann insbesondere der Entwickler Fähigkeiten bei dem Fähigkeitsmanager anfordern, beispielsweise über eine mit der Funktions-Software referenzierte Fähigkeitsmatrix anfordern. Das Referenzieren kann beispielsweise über einen Hash erfolgen. Diese Referenz kann die neue Softwarekomponente inklusive ihrer Anforderungen an die Fähigkeiten des Zielsystems identifizieren. Optional kann der Fähigkeitsmanager auch weitere Fähigkeiten durch diese neu bereitgestellte Komponente ermitteln. Anschließend kann die Beschreibung der Funktion mit ihren Fähigkeitsabhängigkeiten im Fähigkeitenspeicher hinterlegt werden, beispielsweise in Form eines merkle tree. Der Programmcode der neuen Funktion kann der Funktionsregistrierung und dem eventbasierten Scheduler zur Ausführung hinzugefügt werden. Der Fähigkeitsmonitor kann den Zugriff aller Funktionen überwachen, und zwar insbesondere auf Fähigkeiten in Echtzeit während der Laufzeit und im Fehlerfall reagieren, beispielsweise wenn ermittelt wird, dass Fähigkeiten nicht rechtzeitig zur Verfügung stehen. Der Fähigkeitsmonitor kann dem Fähigkeitsmanager Laufzeitinformationen der Ringspeicher zur Verfügung stellen, damit der eventbasierte Scheduler die Partitionen der Funktionen gemäß ihrer Echtzeitanforderung triggern kann. Der Fähigkeitsmonitor kann vor der Benachrichtigung des Fähigkeitsmanagers die Signaturen aller Teilnehmer prüfen. Daten und Laufzeit einer Partition werden einer Funktion typischerweise nur zugewiesen, wenn die Funktion die Anforderungen der Fähigkeitsmatrix erfüllt. Die Überwachung der Lese- bzw. Schreibpointer der Ringspeicher ermöglichen die Ermittlung der Rechtzeitigkeit der Funktionsausführung. Weiterhin ermöglicht der Schreib- bzw. Lesepointer dem eventbasierten Scheduler die Ausführungsplanung aller Funktionen und das Teilen von gleichen Fähigkeiten im selben Speicherbereich. Eine Verschlüsselung und Zugriffsberechtigung eines Ringspeichers sowie eine Zuweisung der Zugriffspointer können über die Signaturen der Teilnehmer im Fähigkeitenspeicher über den Fähigkeitsmonitor gesteuert werden.
Die Ringspeicher der Fähigkeitsabstraktion können durch die Echtzeitmechanismen des Hypervisors getriggert werden. Der Fähigkeitsmonitor kann einen Pointer auf den Puffer empfangen, der eine Aktion zur Überprüfung der Signatur erfordert. Er interagiert typischerweise mit dem Fähigkeitsmanager, welcher im Konfliktfall entsprechende bzw. geeignete Mitigationsstrategien auslöst.
Nachfolgend wird eine Fähigkeitsabstraktion beschrieben. Als Beispiel dient hierbei eine Funktion der Niederschlagsermittlung. Eine neue Funktion zur Niederschlagsermittlung kann beispielsweise auf folgende Fähigkeiten zugreifen:
Regensensor lesen, Fahrzeugmodell ermitteln.
Der Regensensor kann beispielsweise einen abstrakten Wert liefern (zum Beispiel 0 = kein Regen, 1 = wenig Regen, 2 = mehr Regen, 3 = viel Regen, usw.). Die neue Softwarefunktion kann anhand des Fahrzeugmodells die tatsächliche Niederschlagsmenge in Liter pro Quadratmeter ermitteln und diese Information als neue Fähigkeit anmelden oder bereitstellen.
Der Fähigkeitsmanager kann anhand der Fähigkeitsmatrix die Echtzeitanforderung der neuen Funktion ermitteln. Beispielsweise kann eine zeitliche Auflistung der Eingangswerte, beispielsweise ein Auslesen des Regensensors mit einer Frequenz von 1 Hz, bzw. der Ausgangswerte, wie beispielsweise der Niederschlagsmenge von 0,5 Hz, ermittelt werden. Weiterhin kann der Fähigkeitsmanager darüber informiert sein, ob eine Funktion von einer anderen benötigt wird und löscht diese gegebenenfalls aus dem Zeitplan des eventbasierten Schedulers. Dies geschieht insbesondere auch im Fehlerfall, zum Beispiel wenn die Funktion nicht rechtzeitig fertig wird. Mit diesem Prinzip können Echtzeitfähigkeiten zwischen Funktionen geteilt werden.
Die Fähigkeitsmatrix kann eine allgemeine Struktur zum Verbinden von Fähigkeiten und Funktionen liefern. Dabei können neue Fähigkeiten angefordert werden und auch angeboten werden. Es sei verstanden, dass die Begriffe Fähigkeitsmatrix und Fähigkeitenprofil hierin synonym verwendet werden. Der Fähigkeitsmanager kann die Konfigurationsdatei mit dem Fähigkeitenspeicher abgleichen. Dabei ist der Schritt zur Prüfung, ob benötigte Fähigkeiten zu den angebotenen Fähigkeiten passend sind, entscheidend.
Für die Vergleichbarkeit der Fähigkeiten sind zwei Lösungsmöglichkeiten vorgesehen: 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).
Diese Fähigkeiten können so in eine Datei geschrieben und vom Funktionsanbieter verschlüsselt und signiert im Fähigkeitenspeicher abgelegt werden. Dies kann als Fähigkeitsmatrix oder als Fähigkeitenprofil bezeichnet werden. Weiterhin kann ein Hash dieser Fähigkeitsspezifikation generiert werden und als Fingerabdruck der Spezifikation dienen. Damit kann der Vertrag zwischen Anbieter und Nutzer beliebigen Inhalt haben und flexibel verwaltet werden (zum Beispiel Commit Hash). Die Vereinbarung kann zwischen dem Fähigkeitsmanager, dem Funktionsanbieter und dem Nutzer bestätigt werden, beispielsweise indem der Hash einer Vereinbarung von allen Parteien digital unterzeichnet wird.
Zur Nutzung von Fähigkeiten können die Teilnehmer kryptografisch signierte Nachrichten über Fähigkeiten austauschen, bei denen es sich insbesondere um Transaktionen handeln kann, die den Status verteilen oder andere Aufgaben ausführen, die für das korrekte Ergebnis der Fähigkeit erforderlich sind. Als nächstes können die Teilnehmer den Status beispielsweise in einer 3-von-3-Multisignatur hinterlegen, auf die die Fähigkeitsmatrix verweisen kann. Neue kryptografisch signierte Zustandsaktualisierungen, die sich auf die ursprünglichen Verpflichtungen der Fähigkeit beziehen, können nun verwendet werden, um den Zustand der Funktion im eventbasierten Scheduler und/oder die Daten im Ringspeicher zu ändern, die von der Multisignatur über den Fähigkeitsmonitor kontrolliert werden. Durch einen Challenge-Response-Mechanismus kann der Fähigkeitsmonitor Methoden implementieren, mit denen die Teilnehmer sicherstellen können, dass die letzte signierte, gültige Zustandsaktualisierung, die sich auf ihre Verpflichtung der Fähigkeit bezieht, an die Funktion übermittelt werden kann, wodurch das korrekte Ergebnis des Zustands und der Daten der Fähigkeit für alle Funktionen, die sich an das Protokoll halten, garantiert wird.
Der Anteil der Kontroll-API zur Anmeldung neuer Funktionen am Fähigkeitsmanager kann beispielsweise folgenden Aufbau haben: melde_service_an(Liste_Hash benötigte_fähigkeiten, Liste_Hash bereitgestellte_fähigkeiten, Anforderungen_Echtzeitfähigkeit) { a = benötigte_fähigkeiten b = bereitgestellte_fähigkeiten opt AE = Anforderungen_Echtzeitfähigkeit if (eventBasedScheduler.registerFunction(opt_AE) == true) bestätig ung = gleiche_fähigkeiten_ab( a, b) if (bestätig ung == fähigkeit_nicht_gefunden) return kontaktiere_service_provider if (bestätigung == keine_erlaubnis_zur_nutzung) return error if (bestätigung == OK) return Liste_Hash benötigte_fähigkeiten + bereitgestellte_fähigkeiten + Signatur des Funktionsmanagers else (return error) }
Die Fähigkeitsmatrix hat gemäß einer möglichen Ausführung folgenden Aufbau:
Figure imgf000024_0001
Figure imgf000025_0001
Der Fähigkeitsmanager kann eine Liste der legitimierten Funktionsanbieter besitzen und neue Funktionen mit der Signatur des Funktionsanbieters im Fähigkeitenspeicher ergänzen.
Fig. 3 zeigt rein schematisch die Vorgehensweise beim Ausführen einer Funktion.
Zunächst allokiert der Funktionsmanager Ringspeicher pro Partition. Der Funktionsmanager kann auch optional mehrere Ringspeicher pro Funktion allokieren. Entsprechende Lese- und Schreibpointer werden initialisiert. Ein Event wird erzeugt, zum Beispiel ein neuer Datensatz an einem Sensor. Der Datensatz wird in den Ringspeicher geschrieben und der Schreibpointer wird auf nächste Position im Ringspeicher gesetzt. Der Fähigkeitsmonitor prüft dann typischerweise Signaturen und überwacht Lesepointer. Sind diese valide, werden Daten von der Funktion gelesen und ausgewertet. Sind diese invalide, werden Lesepointer deinitialisiert.
Wenn das Zielgerät (zum Beispiel HPC eines Fahrzeugs) über die notwendigen Fähigkeiten verfügt und die neue Funktion mitsamt ihren neuen Fähigkeiten akzeptiert wird, wird der Container der neuen Softwarekomponenten dem Zeitplan des eventbasierten Schedulers hinzugefügt. Die Fähigkeitsmatrix einer Drittsoftwarekomponente liefert optional Echtzeitanforderungen zum Zugriff auf Aktoren, Sensoren und/oder Servicedaten, wie zum Beispiel dass die Motortemperatur alle 500 ms aktualisiert werden soll oder dass die Sollgeschwindigkeit alle 100 ms gesendet werden soll. Weiterhin sorgt der eventbasierte Scheduler typischerweise dafür, dass Fremdsoftware genügend Zeit zur Verarbeitung der Daten erhält. Sind keine aktuellen Daten verfügbar, ergibt es typischerweise keinen Sinn, die Drittsoftware zur Verarbeitung auszuführen. Ob Daten für eine Funktion bereitgestellt werden, prüft der Fähigkeitsmonitor über den Zugriffspointer der schreibenden Funktion (Drittsoftware) bzw. Sensor/Aktor. Ob die Drittsoftware mit der Verarbeitung im Zeitplan liegt, prüft der Fähigkeitsmonitor, indem der Schreibpointer des eventbasierten Schedulers überwacht wird. Beispielsweise wird die Sollgeschwindigkeit alle 100 ms geschrieben. Wenn eine Komponente keine Echtzeitanforderungen hat, wird diese vom eventbasierten Scheduler nur ausgeführt, wenn Rechenzeit übrig bleibt. Der Fähigkeitsmanager überwacht die globale Rechenkapazität und meldet neue Funktionen nur an, wenn ein Puffer x existiert. Daten können auf eine sichere Arte und Weise (Verschlüsselung oder separater Speicherbereich) typischerweise nur an die Funktion übertragen werden, welche gerade zur Ausführung im Zeitplan steht. Dies sorgt typischerweise dafür, dass der Systembus durch parallele Übertragung bzw. Recheneinheiten durch parallele Entschlüsselung nicht überlastet wird. Es bietet sich an, den Speicher zwischen Aktorik/Sensorik und Fremdsoftware als Ringspeicher auszulegen, da für ein solches System viele kleine Datenpakete mit hoher Echtzeitanforderung verwendet werden, da ein Fahrzeug viele Sensoren und Aktoren besitzt. Weiterhin kann ein Ringspeicher viele Lese- und Schreibpointer auf dem gleichen Speicherbereich verwalten. Damit wird wiederum der Systembus zwischen Funktion und Aktor/Sensor entlastet.
Die hierin beschriebene Vorgehensweise beschränkt sich nicht nur auf Softwarefunktionen, vielmehr können neue Fähigkeiten damit auch in Form von neuer Hardware hinzugefügt werden.
Eine beispielhafte Vorgehensweise beim Anmelden einer neuen Hardware zeigt Fig. 4. Dabei wird zunächst die neue Hardware physisch dem Gesamtsystem hinzugefügt. Die Hardware startet und liest den Fähigkeitenspeicher aus. Der Fähigkeitsmonitor erkennt die neue Hardware und fügt neue Fähigkeiten dem Fähigkeitenspeicher hinzu. Die Fähigkeiten der neuen Hardware stehen dann im Gesamtsystem zur Verfügung.
Nachfolgend erfolgt eine Beschreibung eines möglichen zugrunde liegenden Gesamtsystems für das hierin beschriebene Verfahren. Diesbezüglich sei auf die Darstellung von Fig. 5 verwiesen.
In der untersten Schicht befindet sich typischerweise die Hardware. Diese sind die SoCs der Steuergeräte, welche typischerweise die Rechenleistung und Speicher, Schnittstellen etc. enthalten. Für das Gesamtsystem werden eine Vielzahl solcher Hardwarekomponenten verbunden, und zwar insbesondere über Kommunikationsbusse (zum Beispiel PCI und/oder Automotive Ethernet). Hardware kann dabei flexibel hinzugefügt oder entfernt werden, um die Rechenleistung zu modifizieren. Jede Hardware kann optional direkt mit Sensoren und/oder Aktoren verbunden sein. Jede Hardware hat typischerweise einen Fähigkeitenspeicher. Dies ist ein spezieller Speicherbereich, in dem die verfügbaren Fähigkeiten abgelegt werden, um bei einem Aufstart eine schnelle Verfügbarkeit zu gewährleisten. Über die Kommunikationsschicht werden die Hardware 1 bis Hardware n miteinander verbunden. Zusätzlich können hier weitere Sensoren und/oder Aktoren direkt angebunden werden. Auf der Hardware kann optional ein Hypervisor (Typ 1 oder Typ 2) laufen, der die sichere Trennung verschiedener Partitionen durchführt. In den Partitionen kann der beschriebene gemischt kritische Orchestrator installiert werden. Der Orchestrator bestimmt dabei typischerweise auch die virtuelle Netzwerkkonfiguration, welche die Kommunikationsmöglichkeiten zwischen verschiedenen Funktionen definiert und kennt, und kennt das Echtzeitverhalten der gesamten Kommunikationskette, mit der eine direkte Kommunikation zwischen den Applikationen ermöglicht werden kann. Funktionen und/oder Applikationen können vom gemischt kritischen Orchestrator gestartet werden. Dabei handelt es sich typischerweise um die abstrahierte Funktionssoftware, die mit verschiedenen Technologien voneinander getrennt ausgeführt werden kann. Beispielsweise kann dies als Pod oder Multicontainer-Applikation, als Single Container-Applikation, als Sandbox, als virtuelle Maschine, als Web Assembly mit entsprechender Runtime, oder als Micro-VM erfolgen. Echtzeitfähige Funktionen können von Applikationen verwendet und angeboten werden, ohne die Sicherheit des Gesamtsystems zu beeinflussen.
Der in Fig. 5 dargestellte gemischt kritische Orchestrator kann insbesondere mit der Kombination aus eventbasiertem Scheduler, Fähigkeitsmanager und Fähigkeitsmonitor in Fig. 1 identifiziert werden.
Die hierin beschriebene Vorgehensweise ermöglicht insbesondere ein gemeinsames Orchestrieren von echtzeitfähigen und unkritischen Inhalten. Eine dynamische Allokation von Funktionen in allen Partitionen wird ermöglicht. Alle Ressourcen des Gesamtsystems können durch den gemischt kritischen Orchestrator genutzt werden. Der Orchestrator weist dabei typischerweise die Funktion einer Partition zu. Damit kann eine optimale Ausnutzung der Ressourcen jeder Partition erzielt werden. Es kann eine Neuzuteilung von Fähigkeiten zu Partitionen erfolgen, und damit einhergehende flexible Zuteilungsmöglichkeiten von Funktionen zu Fähigkeiten sind möglich. Der gemischt kritische Orchestrator kann die Fähigkeiten einer oder mehrerer Partitionen zuteilen und kann die Funktion genau da allokieren, wo ein Zugriff möglich ist, und diesen überwachen. Zudem kann durch die bekannten Abhängigkeiten auch eine Rekonfiguration der Fähigkeiten zu den Partitionen automatisiert und sicher durchgeführt werden. Die Echtzeitfähigkeit für Partitionen mit dynamischer Allokierung wird außerdem bereitgestellt. Durch die Kombination von Fähigkeitsmatrix und Fähigkeitenspeicher sind Anforderungen an die Echtzeitfähigkeit definiert. Der Fähigkeitsmonitor kann so durch den Abgleich der Anforderungen mit den Fähigkeiten prüfen, ob die Echtzeitanforderungen eingehalten werden können und ob weitere Funktionen dynamisch allokiert werden können. Eine partitionsübergreifende Funktionsverwaltung kann durch den gemischt kritischen Orchestrator bereitgestellt werden. Eine Kommunikation von mehreren Orchestratoren untereinander ermöglicht hardware- und partitionsübergreifende Funktionsverwaltung. Es kann auch ein performantes Ausführen durch die Verwendung von Ringspeichern erfolgen.
Nachfolgend werden beispielhaft drei mögliche Ausführungsbeispiele konkreter Implementierungen beschrieben:
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.
Erwähnte Schritte des erfindungsgemäßen Verfahrens können in der angegebenen Reihenfolge ausgeführt werden. Sie können jedoch auch in einer anderen Reihenfolge ausgeführt werden, soweit dies technisch sinnvoll ist. Das erfindungsgemäße Verfahren kann in einer seiner Ausführungen, beispielsweise mit einer bestimmten Zusammenstellung von Schritten, in der Weise ausgeführt werden, dass keine weiteren Schritte ausgeführt werden. Es können jedoch grundsätzlich auch weitere Schritte ausgeführt werden, auch solche welche nicht erwähnt sind.
Es sei darauf hingewiesen, dass in den Ansprüchen und in der Beschreibung Merkmale in Kombination beschrieben sein können, beispielsweise um das Verständnis zu erleichtern, obwohl diese auch separat voneinander verwendet werden können. Der Fachmann erkennt, dass solche Merkmale auch unabhängig voneinander mit anderen Merkmalen oder Merkmalskombinationen kombiniert werden können.
Rückbezüge in Unteransprüchen können bevorzugte Kombinationen der jeweiligen Merkmale kennzeichnen, schließen jedoch andere Merkmalskombinationen nicht aus.

Claims

Patentansprüche
1 . Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit (RE) eines Fahrzeugs, wobei auf der Recheneinheit (RE) eine oder mehrere Funktionen mit Echtzeitanforderung und eine oder mehrere Funktionen ohne Echtzeitanforderung laufen, wobei das Verfahren folgende Schritte aufweist: Erfassen eines Zustands der Recheneinheit (RE) , und
Erzeugen des Fähigkeitenprofils in Abhängigkeit von dem Zustand der Recheneinheit (RE).
2. Verfahren nach Anspruch 1 , wobei das Fähigkeitenprofil einen Indikator für eine aktuelle Auslastung beinhaltet.
3. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Recheneinheit (RE) eine variable Anzahl an Hardwarekomponenten aufweist, und wobei das Fähigkeitenprofil eine Auflistung der aktuell vorhandenen Hardwarekomponenten beinhaltet.
4. Verfahren nach Anspruch 3, wobei beim Hinzufügen oder Entfernen einer Hardwarekomponente die Auflistung der aktuell vorhandenen Hardwarekomponenten aktualisiert wird.
5. Verfahren nach einem der Ansprüche 3 oder 4, wobei beim Hinzufügen oder Entfernen einer Hardwarekomponente eine oder mehrere der folgenden Hardwarekomponenten hinzugefügt oder entfernt werden:
Rechenkomponente,
Beschleunigerkomponente, Speicherkomponente.
6. Verfahren nach einem der Ansprüche 3 bis 5, wobei beim Hinzufügen oder Entfernen einer Hardwarekomponente ein oder mehrere Sensoren und/oder Aktoren hinzugefügt oder entfernt werden.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Recheneinheit (RE) eine variable Anzahl an Partitionen aufweist, und wobei das Fähigkeitenprofil eine Auflistung der aktuell vorhandenen Partitionen beinhaltet.
8. Verfahren nach Anspruch 7, wobei eine oder einige der Partitionen echtzeitfähig sind, und wobei eine oder einiger der Partitionen nicht echtzeitfähig sind.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Recheneinheit (RE) eine variable Anzahl an Softwarefunktionen aufweist, und wobei das Fähigkeitenprofil eine Auflistung der aktuell vorhandenen Softwarefunktionen beinhaltet.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Verfahren ferner folgende Schritte aufweist:
Ermitteln eines Anforderungsprofils einer zur Recheneinheit (RE) hinzuzufügenden Funktion,
Vergleichen des Anforderungsprofils mit dem Fähigkeitenprofil, und Hinzufügen des Anforderungsprofils nur dann, wenn das Anforderungsprofil zu dem Fähigkeitenprofil korrespondiert.
PCT/DE2022/200308 2022-01-24 2022-12-20 Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit WO2023138721A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102022200754.9A DE102022200754A1 (de) 2022-01-24 2022-01-24 Verfahren zum Erzeugen eines Fähigkeitenprofils einer Recheneinheit
DE102022200754.9 2022-01-24

Publications (1)

Publication Number Publication Date
WO2023138721A1 true WO2023138721A1 (de) 2023-07-27

Family

ID=84981314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2022/200308 WO2023138721A1 (de) 2022-01-24 2022-12-20 Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit

Country Status (2)

Country Link
DE (1) DE102022200754A1 (de)
WO (1) WO2023138721A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020210729A1 (en) * 2019-04-12 2020-10-15 Harman International Industries, Incorporated Elastic computing for in-vehicle computing systems

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE282231T1 (de) 2000-04-11 2004-11-15 Visa Int Service Ass Integriertes verfahren zur herstellung von chipkarten
US7609650B2 (en) 2004-07-08 2009-10-27 Carrier Iq, Inc. Collection of data at target wireless devices using data collection profiles
US20060294515A1 (en) 2005-06-23 2006-12-28 International Business Machines Corporation Common operating system install method
US8219983B1 (en) 2008-03-31 2012-07-10 Symantec Corporation Systems and methods for providing guidance on the potential impact of application and operating-system changes on a computing system
GB2517195A (en) 2013-08-15 2015-02-18 Ibm Computer system productivity monitoring
US10353858B2 (en) 2017-12-18 2019-07-16 GM Global Technology Operations LLC System and method for managing system memory integrity in suspended electronic control units
US10599538B2 (en) 2018-05-31 2020-03-24 Dell Products L.P. Usage profile based recommendations

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020210729A1 (en) * 2019-04-12 2020-10-15 Harman International Industries, Incorporated Elastic computing for in-vehicle computing systems

Also Published As

Publication number Publication date
DE102022200754A1 (de) 2023-07-27

Similar Documents

Publication Publication Date Title
DE102017201789B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
DE112010003554B4 (de) Symmetrische Direktmigration von Virtuellen Maschinen
DE112012000946T5 (de) Versehsagbares Rechnen in virtualisierten verteilten Computersystemen basierend auf der Partitionierung von Rechenleistung und Kommunikationsleistung
WO2013171122A2 (de) Funktional erweiterbares fahrzeugsteuergerät und verfahren zum ergänzen der funktionalität eines fahrzeugsteuergeräts
EP3704573B1 (de) Verfahren zum durchführen eines softwareupdates in einem steuergerät eines kraftfahrzeugs sowie entsprechend eingerichtetes kraftfahrzeug
EP3125056A1 (de) System und verfahren zur steuerung und/oder analytik eines industriellen prozesses
EP3929740A1 (de) Verfahren zur orchestrierung einer container-basierten anwendung auf einem endgerät
EP1634176B1 (de) Clusteranordnung für dezentrale lastverteilung
DE102013108924A1 (de) Verfahren zur Zuteilung von Netzwerkressourcen in einem Operationsnetzwerk für eine ausgewählte Umgebung
US20070174437A1 (en) Method for managing and monitoring the operation of a plurality of distributed hardware and/or software systems that are integrated into at least one communications network, and system for carrying out the method
WO2021089310A1 (de) Verfahren und vorrichtung zum verwalten von zugriffen mehrerer softwarekomponenten auf softwareschnittstellen
WO2023138721A1 (de) Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit
DE102022200755A1 (de) Verfahren zum Hinzufügen und/oder Verwalten von Funktionen auf einer Recheneinheit
DE102015207570A1 (de) Ressourcen-Optimierer für Software-Ökosysteme
DE102019213562A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug
LU101163B1 (de) Verfahren und Vorrichtungen für eine Lastzuweisung und Überwachung für eine zuzuweisende versorgungssicherheitskritische Ressource in einem Netzwerk
DE102021204757A1 (de) Verwaltung von Laufzeitcontainern für ein industrielles Automatisierungssystem
WO2020188082A1 (de) Verfahren und vorrichtungen für eine lastzuweisung und überwachung für eine zuzuweisende versorgungssicherheitskritische ressource in einem netzwerk
DE112020007654T5 (de) Servereinrichtung, Steuerschaltung, Speichermedium und Verkehrsunterstützungsverfahren
DE202022104275U1 (de) System für intelligentes Ressourcenmanagement für verteilte Maschinenlernaufgaben
DE102019213563A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug
DE102021204789A1 (de) Verfahren und system zur zusicherung garantierter dienstgüte in fahrzeugen
DE102021131275A1 (de) Dynamische Planung und Weiterleitung für TDM-Betriebsnetzwerke
EP2597570B1 (de) Clusteranordnung für Dezentrale Lastverteilung
DE102019213561A1 (de) Verfahren zur Berechnung einer Funktion für ein Fahrzeug

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22843633

Country of ref document: EP

Kind code of ref document: A1