Method and device for providing an individualized software configuration for a vehicle and a heterogeneous vehicle fleet

Abstract

The invention relates to a computer-implemented method for providing a complete software configuration for a vehicle, comprising the following steps: - Providing (S1) attributes for a vehicle in a digital twin; - Providing (S2) filter rules, wherein each filter rule is associated with a software configuration; - Determining (S3) software configurations for the vehicle based on the filter rules depending on the attributes of the specific vehicle, wherein a software configuration for the vehicle associated with the filter rule is determined when a filter rule is satisfied depending on the attribute; - Aggregating (S4) the determined software configurations to determine the complete software configuration; - Implementing (S5) the complete software configuration in the vehicle.

Description

Technical field The invention relates generally to the provision of an individualized software configuration for a vehicle and a heterogeneous vehicle fleet. State of the art Today's systems for managing software configurations in vehicles are capable of deploying predefined packages to a large number of vehicles based on dynamic criteria. However, the consistency of the distributed packages must be ensured by the user. Furthermore, any interactions between included software components as well as between separately deployed packages must be considered. To address these challenges, currently, the variants in use are primarily managed manually, and the variety of variants is limited by using configurations that are as static as possible. The industry's growing trend towards software-defined vehicles (VVs) – vehicles whose characteristics and functions are primarily defined by software – is expected to lead to an explosive increase in the number of software components and the functional dependencies between them. An additional challenge arises from managing functionalities that span components in various runtime environments (e.g., Android Automotive, AUTOSAR [Adaptive], etc.). Furthermore, the increased demands of end users to personalize their vehicle software, similar to smartphones (e.g., by independently acquiring apps), significantly increases the complexity of software management. Disclosure of the invention According to a first aspect, a procedure for providing a complete software configuration for a vehicle is provided, comprising the following steps: - Providing attributes for a vehicle in a digital twin; - Providing filter rules, with each filter rule associated with a software configuration; - Determining software configurations for the vehicle based on the filter rules depending on the attributes of the specific vehicle, whereby a software configuration for the vehicle associated with the filter rule is determined if a filter rule is satisfied depending on the attribute; - Aggregating the determined software configurations to determine the complete software configuration; - Implementing the complete software configuration in the vehicle. It may be provided that, if it is determined that an attribute has changed, the digital twin is updated specifically with regard to the new attribute. Furthermore, if it is determined that an attribute has changed, the filter rule that affects the attribute can be executed and one or more new software configurations can be provided for the vehicle in question. In particular, one or more new software configurations can be aggregated to obtain the updated overall software configuration. One goal of the above method is to create a way to provide vehicle-specific software configurations, taking into account the requirements arising from the compatibility of software components within each configuration. This should enable the operation of particularly large (several million vehicles) and heterogeneous (from two-wheelers to trucks) vehicle fleets with low latency and minimal resource consumption. The context of a vehicle is defined by its static attributes, such as manufacturer, model series, model year, and equipment package, as well as by dynamic properties like geolocation or driver-acquired applications. These attributes are aggregated and stored as a so-called digital shadow in a digital representation of the vehicle, the digital twin. Using filter rules that refer to the attributes, subsets of the software components of a vehicle's software configuration can be assigned to such a context. The process determines the total set of suitable filter rules for the current and specific context of a particular vehicle—that is, the entirety of its assigned attributes—and uses this to create the necessary vehicle-specific software configuration. This mechanism allows for individualization of the software configuration down to the individual vehicle level, if required. However, this highly individualized determination of the software configuration, if implemented naively, results in very high runtime complexity and thus high resource consumption and low efficiency, which becomes impractical even for manageable fleet sizes. The above method significantly mitigates this scaling problem, thus making the management of individual software configurations for vehicles economical. Efficient data structures enable resource-saving determination of the software configuration for a vehicle. Managing software configurations and their compilation in a software-defined vehicle (SDN) therefore becomes realistic even for large vehicle fleets. At the heart of the process is a digital twin, which stores and maintains a digital representation of all physical attributes of a vehicle. Each vehicle regularly sends changes to its essential attributes as a so-called digital shadow to the digital twin, which then records them. Using a filter unit, groups of vehicles can be identified by comparing the attributes specified in the filter with the attributes of the respective group of vehicles stored in the digital twin. Individual vehicles can also be selected by more than one filter simultaneously. The software configuration unit allows the definition of software configurations and their assignment to the filters created in the filter unit. A software configuration represents a set of software modules, each with one or more versions, that are to be implemented and operated together in a vehicle. The configuration calculation unit forms the core of the system. Here, all software configurations, which can originate from multiple filters and are assigned to a specific vehicle via those filters, are aggregated, and mutual dependencies with other software modules or software configurations are automatically resolved. This results in a complete software configuration. The software configuration is expressed using Boolean algebra and solved with the aid of a "SAT solver". The resulting overall software configuration, which is individually tailored to each vehicle depending on the existing hardware and already installed software, is delivered to the vehicles concerned using a distribution unit. The non-optimized (conventional) approach is characterized by the fact that the relevant information is always retrieved directly from its source and processed in its raw form. This includes, for example, the software configurations from the software configuration unit, the filters from the filter unit, and the information about which vehicles are selected by a filter, all provided by the digital twin. In contrast, the optimized approach avoids these costly accesses as much as possible. Instead, it uses special data structures and algorithms built upon them for their management. These essentially consist of three mapping structures that reflect the system state at any given time and thus represent different, needs-based optimized views of the same data. As a result, these data structures already contain all the information required for efficient access in a pre-processed form. For this reason, it is very important to maintain consistency between the mapping structures and with external data sources (digital twin, filters, and software configurations). Internally, this is achieved through a transactional modification pattern; externally, through continuous synchronization with the respective data sources. The filter unit stores the vehicles selected by each existing filter. This eliminates the time-consuming process of manually selecting vehicles from the database containing the digital twin. For each newly added vehicle, the system immediately checks which filters select it and then adds the vehicle to this allocation structure, meaning the vehicle is added to the corresponding filters. A filter refers to one or more attributes that specify a vehicle's context. The mapping structure stores the filters relevant to each existing vehicle attribute. This mapping structure allows for efficient inferences about potentially applicable filters based on an attribute change, without having to search through the entire list of all filters. The software configuration unit stores the assigned software modules or combinations of software modules for each vehicle as a software configuration, as well as the filters that resulted in each assignment. This assignment structure represents the individual overall software configuration for each vehicle and allows direct inference of the filters whose application led to this configuration. Brief description of the drawings Preferred embodiments of the present invention are explained in more detail below with reference to the accompanying drawings. Figure 1 shows a diagram illustrating a system for providing a software configuration; Figure 2 shows a flowchart illustrating a method for operating the system for providing a software configuration. Description of embodiments Fig. 1 shows, using a block diagram, a system 1 for providing a software configuration for a large number of individually configured vehicles 2. A software configuration is characterized by one or a combination of software components. The system includes a digital twin 3, which represents a cloud storage location where the configurations of each vehicle are stored. The vehicle configurations encompass the contexts of the vehicles 2, each of which has several attributes. If a vehicle's attribute changes, the digital twin 3 is updated. The context of a vehicle in which it is located is defined by its static attributes, such as manufacturer, series, model year and equipment package, as well as by dynamic properties such as geolocation or applications acquired by the driver. Using filter rules that refer to the attributes, subsets of the software components of a vehicle's software configuration can be assigned to such a context. Filter unit 4 contains filter rules that relate to the attributes, with each filter rule being assigned to a specific software configuration with one or more software modules, possibly in different versions. Furthermore, groups of vehicles can be identified in the filter unit by comparing the attributes processed by the filter with the attributes of the respective group of vehicles stored in the digital twin. Individual vehicles can also be selected by more than one filter rule / filter simultaneously. A software configuration unit 5 enables the definition of software configurations and their assignment to the filter rules that were created in the filter unit 4. In a configuration calculation unit 6, all software configurations, which can originate from multiple filters and are assigned to a specific vehicle 2 via the filters, are aggregated, as well as mutual dependencies to other software modules or software configurations. The resulting overall software configuration, which is individually tailored to each vehicle depending on the existing hardware and already installed software, is delivered to the affected vehicles 2 using a distribution unit 7 and implemented there. This makes it easy to create a suitable software configuration for each individual vehicle with its assigned context, provided that the assignment structures are kept consistent with each other and with the external data sources (digital twin, filters and software configurations). Fig. 2 shows, using a flowchart, the procedure for deploying and updating a software configuration. In step S1, attributes for a vehicle are first made available in the digital twin. In step S2, filter rules are defined, with each filter rule being assigned a software configuration. In step S3, the attributes of a specific vehicle are analyzed using the filter rules to determine software configurations for the vehicle that are associated with the filter rule if a filter rule is satisfied depending on the attribute. In step S4, the specific software configurations are aggregated to determine an overall software configuration. The complete software configuration is implemented in the vehicle in step S5. In step S6, the system checks whether an attribute has changed. If so (alternative: Yes), the filter rule relevant to the attribute is executed in step S7, determining one or more new software configurations for the vehicle in question. The process then continues with step S4. If the filter rule has changed, the software configuration corresponding to the changed attribute is removed. Otherwise (alternative: No), the process returns to step S6. The following table compares three use cases with respect to their runtime complexity in Big O notation for the conventional and the optimized implementation approach described in this invention disclosure: a) A vehicle attribute of a specific vehicle changes (e.g., geolocation or subscription to a premium package). b) The filter criteria of a specific filter change (e.g., a change in a geofence). c) A software configuration mapping change. The following variables are considered: a: Number of affected vehicle attributes; f: Number of affected filters; k: Number of vehicles selected by a filter; Number of vehicles in a total fleet a) For each vehicle attribute, it must be checked in all filters whether they select the vehicle. Only the remaining attributes need to be considered. The remaining steps can be performed in a non-constant timeframe by looking up the relevant data structures and are therefore negligible. (b) The entire vehicle fleet, as well as each selected vehicle, must be checked to determine which filter rules and therefore which assigned software configurations are currently valid. (n) Only a single iteration of all vehicles is required. The remaining steps can be performed in constant time by looking up the relevant data structures and are therefore negligible. c) Changing the assignment of a software configuration to a filter rule. Comparable to b) in terms of complexity. When changing a software configuration assignment, the set of all vehicles only needs to be processed once. The remaining steps can be performed in a non-constant time by looking up the relevant data structures and are therefore negligible.

Claims

A computer-implemented method for providing an overall software configuration for a vehicle (7), comprising the following steps: - Providing (S1) attributes for a vehicle in a digital twin; - Providing (S2) filter rules, each associated with a software configuration; - Determining (S3) software configurations for the vehicle based on the filter rules depending on the attributes of the specified vehicle, whereby one of the software configurations for the vehicle associated with the filter rule is determined when a filter rule depending on the attribute is satisfied; - Aggregating (S4) the determined software configurations to determine the overall software configuration; - Implementing (S5) the overall software configuration in the vehicle. Method according to claim 1, wherein, when it is determined that an attribute has changed, the digital twin is updated (S7). Method according to claim 1 or 2, wherein, when it is determined that an attribute has changed, the filter rule relating to the attribute is executed and one or more new software configurations are provided for the vehicle in question. Method according to claim 3, wherein the one or more new software configurations are aggregated to obtain the updated overall software configuration. Method according to claim 4, wherein the aggregation of the software configurations comprises linking the software components associated with the software configurations by Boolean algebra. Method according to any one of claims 1 to 5, wherein the attributes specify a manufacturer, a series, a model year, an equipment package, a geolocation and / or applications acquired by the driver. Device for carrying out one of the methods according to one of claims 1 to 6. Computer program product comprising instructions which, when the program is executed by at least one data processing device, cause it to execute the steps of the method according to any one of claims 1 to 6. Machine-readable storage medium comprising instructions which, when executed by at least one data processing device, cause it to execute the steps of the method according to any one of claims 1 to 6.

Images