Patent Application
20250036466
The disclosure is concerned with a computer implemented method for organizing access to a shared memory of a vehicle. The disclosure is furthermore concerned with a vehicle, a computer program product and a processing device configured to provide such a method.
A vehicle typically provides multiple vehicle functions, such as a driver assistance system and/or a sensor of the vehicle configured to provide sensor data. In order to execute an application of such a vehicle function of the vehicle, it is often necessary for the vehicle function to store data on a memory device and/or to access data stored on the memory device.
It is the object of the disclosure to provide well-organized access to a memory of a vehicle.
Advantageous embodiments of the disclosure are specified in the following description, the claims, and the figures.
A first aspect of the disclosure is concerned with a computer implemented method for organizing access to a shared memory of a vehicle. Multiple vehicle functions of the vehicle are each configured to execute an application in a memory portion of the shared memory. The shared memory is preferably a centralized storage unit of the vehicle. The multiple vehicle functions are for example, at least one driver assistance system, at least one sensor providing sensor data, a remote locking and unlocking function of the vehicle, a connection service to an external device to, for example, stream music in the vehicle and/or an air conditioning system of the vehicle. All these vehicle functions are based on a software. The respective may be carried out by a processing device of the vehicle. The processing device may comprise the multiple vehicle functions and/or at least one of the multiple vehicle functions.
The application of the vehicle function is, for example, the function provided by the vehicle function. This mean that, for example, in case of a driver assistance system as a vehicle function the application may comprise generating operating commands for the vehicle to provide the driver assistance system. In case of a lane assist as a vehicle function, the application may generate operating commands for the vehicle, more precisely for a steering system of the vehicle, so that when the generated operating command is executed by, for example, a control unit of the vehicle, the vehicle is guided along a current lane. In case of a sensor as a vehicle function, data collection or capturing by the sensor can be the application of this vehicle function. The captured sensor data provided by the sensor are stored in a memory portion of the shared memory. The application can hence be understood as a storing function of the collected or captured data by the sensor. In case of the connection service to stream music as a vehicle function, the application might be providing the communication connection to an external server unit that provides the music. The software and/or a setting required to provide the communication connection may be stored in the shared memory. In other words, there are preferably multiple different applications of the vehicle that require access and preferably reading and/or writing rights for the shared memory.
To prevent that each vehicle function choses a random and possibly overlapping part of the shared memory to, for example, write data to the shared memory, a portion of the shared memory is preferably assigned to each vehicle function and particularly to each application of each vehicle function. There is preferably only one memory for all vehicle functions which is the shared memory. In other words, the shared memory is a memory that may be simultaneously accessed by multiple computer programs, meaning by multiple applications.
The computer implemented method comprises the following steps for each of the vehicle functions: registering the vehicle function for a memory allocation service; determining a location and size of the memory portion of the shared memory for the registered vehicle function by applying an allocation algorithm; executing the application of the vehicle function on the determined memory portion; after execution, disconnecting the vehicle function from the memory allocation service. In other words, the vehicle function requests the memory portion of the shared memory. The memory allocation service is, in other words, a computer program that receives and processes the request of the vehicle function, wherein the vehicle function requests allocation of a memory portion of the shared memory.
The allocation algorithm comprises, for example, instructions which, when executed by a computer, allow, for example, to determine and/or define the memory portion of the shared memory. Defining of the memory portion comprises determining the location and the size of the memory portion. The memory portion is, in other words, an allocated memory section of the shared memory. The location of the memory portion may be its address on the shared memory. The location can be any chosen location on the shared memory. The size of the memory portion may be an amount of memory assigned to the application and/or the vehicle function. The size of a memory portion depends typically on the vehicle function itself, more precisely on its application. The allocation algorithm can, for example, consider negotiations of two vehicle functions which try to execute the application simultaneously. If, for example, the vehicle provides a broker, meaning a computer program that is configured to allocate the memory portion of the shared memory to each vehicle function, the allocation algorithm is preferably executed by the broker so that the broker determines the location and size of the memory portion of the shared memory for each of the currently registered vehicle functions.
Executing the application means running the application. For example, the sensor as a vehicle function writes sensor data captured or collected by the sensor to the determined memory portion of the shared memory while being executed. The sensor may be a front camera, a rear camera, a side camera, a Lidar device, an infrared sensor, a velocity sensor, an accelerations sensor, a temperature sensor and/or any other sensor device of the vehicle. The driver assistance system as a vehicle function, for example, reads the sensor data provided by the sensor and/or writes data to its memory portion of the shared memory while being executed. In case the vehicle function comprises multiple applications, each application may be executed. Preferably, the allocation algorithm determines an individual memory portion for each application of the multiple applications of the vehicle function.
In the last described step, the memory allocation service is disconnected. In other words, the memory allocation service is terminated, meaning that the vehicle function locks-off from the memory allocation service after the application of the vehicle function has been executed. Afterwards, the described process may be closed, meaning that the computer implemented method is terminated.
The disclosure is based on the observation that existing shared memory concepts typically do not provide a dynamic framework for multiple clients, meaning for multiple requesting vehicle functions, to provide and/or subscribe to various data sources with a sufficient management interface. However, the shared memory concept may be improved by allocating the memory portion of the shared memory dynamically.
The applied allocation algorithm hence allocates dynamically the memory portion. Dynamic allocation means that an amount of shared memory allocated to a vehicle function can change dependent on the vehicle function itself. In other words, the amount of shared memory is not necessarily a compile-time constant. In other words, the vehicle is a dynamic shared memory. The advantage of the dynamic allocation is an improved organization of access to the shared memory of the vehicle.
An embodiment comprises that all vehicle functions are configured to send a request concerning the shared memory. In other words, each vehicle function can act as a client. The client is configured to, for example, request data that is stored on a memory portion of the shared memory. Alternatively or additionally, the client can write data to the memory portion of the shared memory. If the sensor as a vehicle function acts a client, it requests an allocated memory portion so that it can write its captured sensor data to its memory portion of the shared memory. This means that at least one possible role is dedicated to each vehicle function which can be the role of the client. In the following, the expression “client” is used to describe a vehicle function that is configured to send a request concerning the shared memory.
In an additional embodiment, at least one of the vehicle functions is configured to allocate the memory portion by applying the allocation algorithm. This means that the at least one vehicle function can act as a daemon. A daemon is a computer program that runs as a background process. The daemon can provide a service such as the memory allocation service. This means that the vehicle function that acts as the daemon can allocates the memory portion for itself but as well for at least one other vehicle function. The vehicle function that acts as the daemon comprises software and/or instructions which, when executed by a computer, provide the allocation algorithm. In other words, the at least one vehicle function that is configured to allocate the memory portion is the vehicle function that determines the location and size of the memory portion of the shared memory for preferably all registered vehicle functions. In the following, the expression “daemon” is used to describe a vehicle function that is configured to allocate the memory portion by applying the allocation algorithm.
If, for example, a first vehicle function acts both as a client and as a daemon, while a second vehicle function, which registers simultaneously for the memory allocation service, acts only as a client, the first vehicle function provides the memory portion allocation for the second vehicle function so that the first vehicle function alone determines for both vehicle functions the location and size of the respective memory portion of the shared memory. The first vehicle function may be referred to as first process and the second vehicle function as second process. In other words, the vehicle function that can be both a client as well as a daemon determines the location and size of the memory portion 5 of the shared memory for all vehicle functions, even for those that are not configured as a daemon but only as client. Such an implementation of a shared memory in a vehicle can alternatively be referred to as hybrid distributed dynamic shared memory concept. As no additional broker is required to provide the memory allocation service, this is a particularly reasonable way to organize access to the shared memory.
According to another embodiment, only the at least one vehicle function configured to allocate the memory portion provides a full shared memory implementation. In other words, only the vehicle functions that can act as daemons provide a complete shared memory implementation. All vehicle functions that are only configured to send the request concerning the shared memory, meaning all vehicle function that act only as clients, do not provide a full shared memory implementation. A full implementation comprises that the respective vehicle function is configured to negotiate the allocation of memory portions between multiple vehicle functions that request simultaneously the memory allocation service. This enables scalability of the organization of access to the shared memory without an extensive growth of required connections within the vehicle.
Particularly, related vehicle functions may be grouped around different vehicle functions acting as daemons to save extra resources. Alternatively or additionally, related vehicle functions may be grouped around a common daemon, meaning around a common vehicle function that may also act as daemon. Related vehicle functions are, for example, vehicle functions of a common kind or type of vehicle function. For example, different sensors of the vehicle that are configured to monitor the environment of the vehicle as vehicle functions may be related vehicle functions and/or driver assistance systems as vehicle functions may as well be related to one another. If the related vehicle functions are grouped around different daemons, the memory allocation service for each vehicle function of the related vehicle functions is provided by an individual daemon. Hence, no two related vehicle functions share a common daemon. If the related vehicle functions are grouped around a common daemon, one of the related vehicle functions acts as daemon for itself and for all other related vehicle functions. Preferably, multiple vehicle functions are configured to act both as client and as daemon.
Another embodiment comprises that the vehicle function configured only to send the request registers for the memory allocation service with the vehicle function configured to allocate the memory portion. This means a vehicle function that can act only as a client sends its registering for the memory allocation service directly to the vehicle function that acts as the daemon. The method hence comprises registering the vehicle function that acts as the daemon as well as at least one vehicle function that acts as a client only for the memory allocation service, wherein the memory allocation service is provided by the vehicle function that acts as the daemon. In another step, the location and the size of the memory portion of the shared memory for the vehicle function that acts only as a client is determined by the vehicle function that acts as the daemon. It also determines the location and size of its own memory portion on the shared memory. This means that one of the two vehicle functions determines the shared memory portions for both vehicle functions. The vehicle function that acts as the daemon provides information representing at least the determined location and size of the memory portion for the vehicle function that acts only as a client. Both vehicle functions can then execute their applications on the determined memory portions. Afterwards, the vehicle function that acts as a client only sends a disconnecting signal to the vehicle function that acts as the daemon to disconnect the vehicle function that acts as a client only from the memory allocation service. The vehicle function that acts as the daemon may disconnect itself from the memory allocation service and hence, for example, withdraw from the described method so that, for example, another vehicle function that can act as a daemon, may take over the daemon role. Preferably, the role of the daemon is only a temporary function of the vehicle function. In case of simultaneously active vehicle functions, the negotiations for an allocated memory portion between the active vehicle functions are organized efficiently due to a clear distribution of roles between the active vehicle functions.
So far, the hybrid distributed dynamic shared memory concept was presented. Possible advantages of this concept are: Features of a daemon and a client are merged in individual vehicle functions without extensive growth of connection links between the vehicle functions; not every vehicle function needs a full shared memory implementation; relating processes, meaning related vehicle functions, can be grouped around different other vehicle functions that can act as daemons; no extra process is required for managing the shared memory because the daemon role is comprised by individual vehicle functions.
An additional embodiment comprises that all vehicle functions are configured to allocate the memory portion. The vehicle functions all provide a full shared memory-implementation. This concept can be referred to as distributed dynamic shared memory concept. In other words, each vehicle function provided in this embodiment can act both as a client as well as a daemon. This means that each vehicle function is fully implemented in the shared memory.
An advantage of this embodiment is that there overhead communication is reduced. Overhead is, for example, data, particularly representing additional information regarding transmittance and/or storage of data. As all vehicle functions may act as daemons, less overhead communication is necessary compared to daemon communication.
More precisely, only one vehicle function of the multiple vehicle functions actually acts as daemon but every vehicle function is able to act as daemon. Therefore, it is useful to decide which of the multiple vehicle functions actually takes over the role of the daemon.
Therefore, according to an embodiment, the method comprises, if multiple vehicle functions are registered simultaneously and each of them is configured to allocate the memory portion, applying a prioritizing algorithm to determine a single dominating vehicle function that applies the allocation algorithm. The prioritizing algorithm comprises preferably instructions to decide which vehicle function acts as the daemon. The prioritizing algorithm may be applied in any situation in which two vehicle functions that can act as daemon register simultaneously for the memory allocation service. The prioritizing algorithm is applicable to both the hybrid distributed dynamic shared memory concept and the distributed dynamic shared memory concept. The prioritizing algorithm can comprise, for example, a list of all vehicle functions of the vehicle ranked in order of, for example, importance. For example, the first vehicle function out of this list is chosen automatically as dominating vehicle function, if it is currently registered for the memory allocation service. If the first vehicle function of the list is currently not registering for the memory allocation service, the vehicle function that is highest in the list and currently registered for the memory allocation service is determined as dominating vehicle function. Therefore, a clear hierarchy is provided according to which the vehicle function that has to act as a daemon for all or at least a part of the registered vehicle functions can be chosen.
Particularly, in case of the distributed dynamic shared memory concept according to which all vehicle functions are configured to allocate the memory portion no additional centralized daemon process is necessary because all vehicle functions can provide the daemon function. Therefore, resources can be saved.
According to another embodiment regarding the prioritizing algorithm, the prioritizing algorithm comprises a ranking of the multiple vehicle functions, starting with the vehicle function most relevant for vehicle safety and/or security. This means vehicle functions particularly relevant are predefined. If, for example, two vehicle functions are registered that can both act as daemon of which one is safety-relevant and/or security-relevant and the other one is not, the safety-relevant and/or security-relevant vehicle function is the dominating vehicle function. The safety-relevant and/or security-relevant vehicle function may be a front camera of the vehicle whereas the vehicle function providing the communication connection to stream music is not considered safety-relevant and/or security-relevant. In this example, the vehicle function of the front camera is ranked higher than the other vehicle function. This is based on the observation that especially front camera data is particularly important to provide, for example, a safety-relevant and/or security-relevant emergency stop system of the vehicle that is based, for example, on obstacle recognition derived from the camera data. On the other hand, the communication connection for streaming music has little impact on safety and security of the vehicle, particularly the passengers of the vehicle, so that in this example the vehicle function of the front camera will act as daemon whereas the vehicle function regarding the communication connection to stream music acts as a client only. Therefore, hierarchy of vehicle functions is well defined and hence a centrally organized access to the shared memory is provided easily.
Besides, an embodiment comprises that the ranking ends with at least one vehicle function that is a pure convenience function. Such a function that is a pure convenience function is, for example, the vehicle function that provides the communication connection to the external device for streaming music. This is because the convenience function is defined as a function that only provides comfort for, for example, a passenger of the vehicle but has no significant and/or recognizable effect on vehicle safety and/or security. Alternatively, the convenience function may have only small impact on safety and/or security of the vehicle. The convenience function is a function mainly or even completely configured for convenience of the passenger of the vehicle. In other words, the vehicle functions may be ranked according to safety and/or security and their relation to convenience and comfort, whereas convenience and comfort is ranked lower than safety and/or security. This allows for a particularly optimized prioritization and determination of the dominating vehicle function.
Furthermore, an embodiment comprises a centralized software separated from the vehicle functions. The centralized software applies the allocation algorithm. The centralized software may be a centralized daemon. The centralized software may be an application of software running on an electronic control unit. A common device can execute the centralized software and at least one of the multiple vehicle functions. The common device may be, example, the processing device of the vehicle and/or the electronic control unit.
In this embodiment, the shared memory is governed by the central unit, meaning the centralized software, which allows for abstraction for shared memory logic for vehicle functions that, for example, only act as clients.
According to another embodiment, the centralized software determines non-continuous locations of the determined memory portions. This shared memory concept may be referred to as centralized dynamic shared memory concept. According to this concept, individual applications may abstract data in modular access controllable units. No explicit memory management is necessary and therefore each vehicle function may have its own dynamic shared memory region, meaning its own dynamic memory portion of the shared memory. The vehicle function only accesses the shared memory via permission limited references provided by the centralized software. In other words, the shared memory is hidden in the centralized software that acts as daemon. There is hence one centralized daemon for all vehicle functions of the vehicle that is configured to divide the shared memory into multiple memory portions that are not necessarily connected to one another. The memory portion may be referred to as shared memory block or shared memory region. The individual memory portions are preferably individual entities. Between the individual memory portions gaps in memory may remain. As an advantage, each application of the vehicle function may have its own dynamic shared memory portion determined by only one the centralized software.
An alternative embodiment comprises that the centralized software determines continuous locations of the determined memory portions. This shared memory concept may be referred to as statically allocated dynamic resizable shared memory concept. According to this concept, full low-level control of the memory portions is provided. The centralized software may determine a first memory portion for a first vehicle function and allocates a second memory portion for a second vehicle function directly next to the first memory portion. The first and second memory portion are thus located adjacent to each other. Hence, there is no gap between the different memory portions. This means that shared memory is filled up continuously with memory portions for different vehicle functions and/or applications of vehicle functions according to a timeline in which they register for the memory allocation service. The advantage of this concept is, for example, the full low-level control of memory portions.
Another embodiment comprises that the size of the determined memory portion is determined dynamically based on the respective vehicle function. This means that there is always enough amount of memory provided for each vehicle function. In particular, the application and/or particularly multiple applications of each vehicle function are all considered. The centralized software hence always chooses the size of the memory portion according to the application and/or the applications of the respective vehicle function. This means that, for example, the sensor data provided by a sensor as a vehicle function is allocated to a memory portion that fits in size the expected amount of sensor data. It is hence possible that, for example, a camera of the vehicle as a vehicle function receives a larger size of allocated memory portion compared to a temperature sensor. The size of the memory portion is hence determined proactively.
Besides, an embodiment comprises removing the allocation to the determined memory portion of the shared memory after disconnecting the vehicle function from the memory allocation service. Removing the allocation to the determined memory portion is in other words releasing the determined memory portion of the shared memory for further vehicle functions. This means that the location and size of the memory portion is now available for, for example, another vehicle function that registers for the memory allocation service. There is hence typically always enough space on the shared memory for all currently registered vehicle functions because the vehicle functions which are already disconnected from the memory allocation service are not allocated to their determined memory portions anymore due to the removing of the allocation.
According to another embodiment, the method comprises erasing all data stored in the memory portion. In other words, a clean-up is performed, preferably after disconnecting the vehicle function from the memory allocation service as well as after removing the allocation to the determined memory portion of the shared memory. The erasing of the data is not necessarily automatic. It is possible to set a time interval, for example of 5 minutes, starting preferably at the end of execution of the application of the vehicle function. After the time interval, all data stored in the memory portion of the vehicle function are deleted automatically. It is, for example, possible to erase camera data of the front camera of the vehicle every 5 minutes after its capture automatically. Alternatively or additionally, the data can be erased directly after disconnecting and/or, as described above, after removing the allocation for the vehicle function. Therefore, memory space is generated easily and quickly for a further vehicle function.
Another aspect of the disclosure is concerned with a vehicle. The vehicle may be a motor vehicle, such as a passenger vehicle, a truck, a bus and/or a motorcycle. The vehicle comprises a shared memory. The vehicle is configured to carry out the above-described method.
Another aspect of the disclosure is concerned with a non-transitory computer-readable medium. The computer readable medium stores a computer program. The computer program product is stored in a storage unit or data storage of, for example, a processing device of a vehicle. The vehicle comprises a shared memory. The computer program product comprises instructions which, when the program is executed by, for example, the processing device or by a computer, cause the processing device or the computer, respectively, to carry out the method as described above.
Another aspect comprises a processing device configured to carry out the described method. The processing device may be a processor. The processing device may comprise at least one microcontroller and/or microprocessor. The processing device may comprise program code that is designed to perform the method when executed by the processing device. The program code may be stored in a data storage of the processing unit.
An embodiment or a combination of embodiments of the above-described method are considered as an embodiment of the inventive vehicle, the inventive computer program product as well as the inventive processing device, if applicable.
The disclosure also comprises embodiments that provide features which afford additional technical advantages.
The disclosure also comprises the combinations of the features of the different embodiments.
In the following an exemplary implementation of the disclosure is described.
The embodiment explained in the following is an advantageous embodiment of the disclosure. However, in the embodiment, the described components of the embodiment each represent individual features of the disclosure which are to be considered independently of each other and which each develop the disclosure also independently of each other and thereby are also to be regarded as a component of the disclosure in individual manner or in another than the shown combination. Furthermore, the described embodiment can also be supplemented by further features of the disclosure already described.
In the figures identical reference signs indicate elements that provide the same function.
In this example, four possible vehicle functions 3 are sketched of which one is a sensor, in this example a front camera 4 of the vehicle 1. The front camera 4 can collect or capture sensor data that is stored on the shared memory 2. The other the vehicle functions 3 may be the lane assist, the remote locking and unlocking function and the function to provide streaming of music. The named vehicle functions 3 are purely illustrative. Less (for example only two) or more and/or other vehicle functions 3 are possible.
Each vehicle function 3 is configured to execute an application in the shared memory. Therefore, data transmission 5 between each vehicle function 3 and the shared memory 2 is provided. This data transmission 5 is sketched with two headed arrows in
The vehicle 1 comprises a processing device 6, which may be a processor and/or a combination of multiple processors. The processing device 6 may comprise at least one microcontroller and/or microprocessor. The processing device 6 can alternatively be referred to as a computer of the vehicle 1. The shared memory 2 as well as the vehicle functions 3 may be comprised by the processing device 6. The processing device 6 may provide a storage unit 7. The storage unit 7 is alternatively only a component of the vehicle 1 and not of the processing device 6. In the storage unit 7 a computer program product is stored. The computer program product is a computer program and hence comprises program code to be carried out by the processing device 6.
In a step S2, an allocation algorithm 9 is applied in order to determine a location 10 and a size 11 of the memory portion 12 of the shared memory 2. This memory portion 12 is allocated to the registered vehicle function 3. The allocation algorithm 9 comprises instructions that allow to determine the location 10 and the size 11 of the memory portion 12.
In a step S3, the method comprises executing the application of the vehicle function 3 on the determined memory portion 12. In other words, the application of the vehicle function 3 is actually run. In case of the front camera 4 as a vehicle function 3, for example, captured sensor data of the front camera 4 are stored in the determined memory portion 12 when the application of the front camera 4 as a vehicle function 3 is executed.
Another step S4, which is preferably performed after execution of the application of the vehicle function 3 in step S3, comprises disconnecting the vehicle function 3 from the memory allocation service 8. This means that after the application was performed, the memory allocation service 8 is no longer needed so that the respective vehicle function 3 signs off from this memory allocation service 8.
A step S5 comprises removing the allocation from the determined memory portion 12 of the shared memory 2. In other words, the allocation, meaning the determined location 10 and the size 11 of the memory portion 12, is no longer allocated to the respective vehicle function 3. In a step S6, the method comprises erasing all data stored in the memory portion 12. In other words, a clean up of the used memory portion 12 is performed. Afterwards, in a step S7 the described method is terminated.
In
Out of the two vehicle functions 3a, 3b, the vehicle function 3a is as well configured to allocate the memory portion 12 by applying the allocation algorithm 8. This means that the vehicle function 3a may act as a daemon. In other words, the vehicle function 3a can perform the above-described step S2 of the method. In this example, the vehicle function 3b is configured only to act as a client. In step S1 the vehicle function 3b hence registers to the vehicle function 3a. The vehicle function 3a that is configured to allocate the memory portion 12 provides a full shared memory implementation. This means that the vehicle function 3a determines the location 10 and size 11 of the memory portion 12 for the vehicle function 3a as well as the location 10 and size 11 of the memory portion 12 for the vehicle function 3b.
In this example, the vehicle function 3a comprises two different applications. Therefore, vehicle function 3a is split up into vehicle function 3a′ and vehicle function 3a″. The two different applications are, for example, capturing camera data and providing obstacle data, preferably determined based on the captured sensor data by applying methods of digital imaging on the captured sensor data. The obstacle data may represent at least one obstacle in the environment of the vehicle 1 such as another vehicle 1 and/or a pedestrian crossing the road on which the vehicle 1 is driving. In this example, vehicle function 3b comprises only one application. For all applications, a respective memory portion 12 may be determined.
First, a prioritizing algorithm 14 can be applied in order to determine a single dominating vehicle function 15 that applies the allocation algorithm 9. In other words, the vehicle function 3 that actually acts as the daemon is the dominating vehicle function 15. In this example, the dominating vehicle function 15 is vehicle function 3c. The prioritizing algorithm 14 comprises a ranking of the multiple vehicle functions 3 starting with the vehicle functions 3 most relevant for vehicle safety and/or security and ending with at least one vehicle function 3 that is a pure convenience function. If the vehicle function 3c is, for example, the front camera 4 of the vehicle whereas the vehicle function 3d is the communication connection to the external device for streaming music, the vehicle function 3d is a pure convenience function whereas the vehicle function 3c is most likely important for vehicle safety and/or security. In this example, the vehicle function 3c is chosen as the dominating vehicle function 15. Therefore, the vehicle function 3d acts as daemon and determines the respective location 10 and size 11 of the memory portions 12 for all applications of the vehicle functions 3c and 3d. In this example, there are again two applications for the vehicle function 3c, which are referred to as vehicle functions 3c′, 3c″ (analogous to vehicle functions 3a′ and 3a″).
The vehicle functions 3g and 3h of this embodiment may be analogous to vehicle functions 3a and 3b or 3c and 3d or 3e and 3f. The vehicle function 3g is split up into vehicle function 3g′ and vehicle function 3g″.
In the embodiments shown in
Overall, the examples show that the computer implemented method is based on sharing of the centralized shared memory 2 to which, for example applications of the vehicle functions 3 can rely on in order to run themselves.
Each vehicle function 3 wishes to use one of the available services, meaning requires a location of the memory portion 12 on the shared memory 2. By doing this, negotiating the usage and the amount of the memory portion 12 is performed by a centralized instance which is typically the vehicle function 3 that is configured to allocate the memory portion 12 by applying the allocation algorithm 9. Once the vehicle function 3 or more precisely its application has completed its task, the memory portion 12 is freed again for further usage by other vehicle functions 3. The four concepts presented provide main advantages, which are: less communication overhead than daemon; the daemon process is not necessary which saves resources; the vehicle function 3 can take either a dedicated role such as the role of a client that requests to read and/or writes data to the shared memory 2. Multiple vehicle distributed shared memory servers can be set up easily thus allowing scalability of resources.
Currently there are different possible embodiments which are presented here, meaning the four different concepts. In
In
The distributed dynamic shared memory concept shown in
Aspects of the various embodiments described above can be combined to provide further embodiments. In general, in the following claims, the terms used should not be construed to limit the claims to the specific embodiments disclosed in the specification and the claims, but should be construed to include all possible embodiments along with the full scope of equivalents to which such claims are entitled.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/082882 | 11/24/2021 | WO |
