Method and system for distributing software components on vehicle

Abstract

The invention relates to a method for distributing at least one software component (11) to at least one vehicle (20, 21). At least one fleet (41) is formed from the entirety of the vehicles (20, 21) having at least one common equipment property, each fleet (41) being associated with at least a fleet type and / or a minimum quality state and / or a prescribed use. At least one software package (51) is formed, each software package comprising at least one software component (11) associated in a fixed version to the software package (51). A quality state is associated for each software package (51) as a function of the result of a quality assurance measure performed next. The software package (51) is associated with at least one fleet (41) in accordance with at least one common equipment attribute of the fleet (41) and the software package (51), in accordance with a quality state of the software package (51), and in accordance with a fleet type and / or a minimum quality state and / or a prescribed use of the corresponding fleet (41). The invention also relates to a software distribution system (1) for distributing at least one software component (11) to at least one vehicle (20, 21).

Description

[0001] The present invention relates to a method and a system for distributing at least one software component to a vehicle.

[0002] Document WO 2022 / 162815 A1 describes a software update device that includes a controller and a storage device, and uses update data to update the software of a vehicle. The storage device stores a general package containing at least the update data and an authentication package. Each authentication package contains package authentication information about the general package and vehicle authentication information, which is associated with the package authentication information and identifies the vehicle. The controller transmits an authentication package containing the vehicle authentication information associated with the target vehicle to the target vehicle that needs to update the software. According to the request of the target vehicle, the controller transmits the general package to it, and the package authentication information contained in the authentication package is related to it.

[0003] Document US 2016 / 0170775 A1 describes a method in which a vehicle receives a software update designed for a control unit of the vehicle. Compatibility with the vehicle control unit is determined based on a token that indicates the corresponding software version status of the control unit. If an allowed configuration of the software version status is determined, the software update is activated. The control unit of the vehicle can receive a token from another control unit of the vehicle, and the token will show the corresponding software version status. The token is used to determine whether the control unit is a control unit with the latest version of the software. In this case, the compatibility of the software version will be determined. Otherwise, the compatibility result determined by the control unit with the latest version of the software will be referred to.

[0004] Document US 2019 / 0139332 A1 describes a method for evaluating the compatibility of a first system component of a vehicle. The method includes the following steps: providing a database containing vehicle platform configuration information, which has configuration information of two or more vehicle models, where each vehicle model contains at least one view, where each view contains at least one system component, where each system component contains configuration information, and where at least two system components of two different vehicle models belong to the same view. Further, the method also includes determining the compatibility between the first system component and another system component of the vehicle platform by comparing the corresponding configuration information, and returning a compatibility result, specifically based on whether the first system component is determined to be compatible with at least one other system component.

[0005] The object of the present invention is to provide an improved method for distributing at least one software component to a vehicle. The object of the present invention is achieved by the method having the features of claim 1. Further, the object of the present invention is to provide an improved system for distributing at least one software component to a vehicle. The object of the present invention is achieved by the system having the features of claim 8.

[0006] Advantageous design solutions of the invention are the subject matter of the dependent claims.

[0007] For a method of distributing at least one software component to at least one vehicle, according to a first aspect of the invention, for vehicles having at least one common equipment property related to the software component, at least one group of vehicles, hereinafter called a fleet, is formed from the totality of such vehicles. Such equipment properties related to the software component (hereinafter also called software-related equipment properties) can for example be one or more properties of a control unit installed in the vehicle, such as a hardware platform, an operating system or a plurality of software components installed thereon, such as drivers or off-the-shelf software.

[0008] In other words: according to the invention, when selecting a fleet, it is ensured that the vehicles of the first fleet are identical in terms of these software-related equipment properties, and there is at least another fleet associated with other vehicles which are identical to each other and to the first fleet in terms of the software-related equipment properties.

[0009] Each fleet is associated with at least one fleet type and / or a minimum quality status and / or a specified use. Optionally, further properties can be associated with the fleet.

[0010] For example, the fleet type can mark the fleet as being for test purposes. As an alternative, the fleet type can mark a fleet that has completed production or is in use, the vehicles of which are in use at the customer's or may be sold to the customer. The fleet type can equally mark a fleet designed for a special purpose, the vehicles of which are for example designed for a specific marketing campaign.

[0011] With the specified use, the fleet can on the one hand for example be marked as being in use at the customer's or delivered to the customer, and on the other hand can be marked as performing tests during the development of the software component. The minimum quality status marks the quality status, that is: the degree of completion of quality assurance measures that the software component must have in order to be able to be distributed to the vehicles of the fleet.

[0012] The basic idea of forming fleets with associated properties is to divide the totality of vehicles that are technically (that is: by means of software-related equipment properties) suitable for installing the software component into non-overlapping subsets, and to design the distribution of the software component according to the association of the vehicles with one of these subsets. Here, the composition of the fleet (that is: the association of individual vehicles) can change dynamically, for example by sales or repurchases, by technical changes. Through new or modified software components, and the aggregation of them into software packages described in more detail below, the division of all vehicles into fleets can also change.

[0013] Form at least one software package, each of which contains at least one software component permanently associated with at least one version. Each software component is compatible with at least one common equipment attribute of at least one vehicle fleet. If a software package contains multiple software components, the selected software components are also compatible with each other.

[0014] For the installation and operation of the software components contained in the software package, the software-related equipment attributes necessary are especially associated with the software package. For example, a specific hardware platform for a control unit, on which at least one software component of the software package is designed to be installed.

[0015] Furthermore, each software package is associated with a quality status, which specifically depends on the results of the quality assurance measures performed on the software package. For example, if the software package is associated with a first software component, the first quality status can be associated as "new". If the overall software package together with its software components has been tested, the quality status "ready for delivery" can be associated. During this period, other quality statuses can be associated according to the progress of the quality assurance measures.

[0016] According to the present invention, the software packages are respectively associated with at least one vehicle fleet according to at least one common equipment attribute of the vehicle fleet and the software package, and according to the vehicle fleet type and / or the minimum quality status and / or the specified use of the corresponding vehicle fleet.

[0017] For example, for a vehicle fleet of the type "customer vehicle" with a minimum quality status of "ready for delivery", when the software package and the vehicle fleet are compatible with the software-related equipment attributes and additionally have the quality status "ready for delivery", the software package is associated with the vehicle fleet and a download task is assigned.

[0018] In this way, the distribution of software components with insufficient quality assurance to critical usage environments is avoided.

[0019] Generally, the complexity of software component distribution will be significantly reduced, because the association problem can be solved with a significantly reduced number of entities compared to the prior art. Specifically, on the one hand, mutually compatible software components are aggregated into software packages, and on the other hand, mutually equivalent vehicles are aggregated into vehicle fleets.

[0020] In particular, software components can be automatically distributed for testing purposes. In this way, an agile software life cycle can be achieved, and the speed and efficiency of software development can be improved.

[0021] In addition, the method according to the present invention can achieve software distribution traceability. In particular, it can be recorded which vehicle fleets obtained which software packages with which quality statuses at what times.

[0022] Furthermore, for the association between software packages and vehicles, it is possible to conveniently simulate their impacts in advance before introducing or changing rules according to fleet grouping. This can avoid conflicts when distributing software components.

[0023] Furthermore, through fleet grouping and its description of the intended uses, it is possible to provide refined services for customer groups. In this way, software function packages can be adjusted for specific customer groups and distributed accordingly.

[0024] In one implementation, at least one first fleet of a fleet type for testing purposes is formed for the overall population of vehicles having at least one common equipment attribute, and at least one second fleet of a fleet type for delivery to customers and / or for use at customers is formed. The first fleet is associated with a minimum quality status different from that of the second fleet, such that software packages designed for testing purposes are associated with at least one vehicle of the first fleet but not with at least one vehicle of the second fleet.

[0025] With this implementation, for software components designed for testing purposes, it is possible to conveniently, especially automatically, achieve distribution in a test environment. At the same time, vehicles in an operational use environment, especially those in use at customers or intended for such use, are protected from using immature software components.

[0026] In one implementation, the quality status associated with the software package and the minimum quality status associated with the fleet are respectively extracted from a list sorted according to quality maturity. The list contains values such as "new", "package creation completed", "integration testing completed", and "quality management testing completed".

[0027] The value "new" will be associated with a newly formed software package, that is: a software package associated with the first software component.

[0028] After all software components are associated, the value "new" will be replaced by the value "package creation completed".

[0029] After the quality assurance measures designed for integration testing are successful, the value "package creation completed" will be replaced by the value "integration testing completed".

[0030] After all the tests designed in the quality assurance measures are successfully completed, the value "integration testing completed" will be replaced by the value "quality management testing completed".

[0031] With this implementation, it is possible to distribute software packages to vehicle fleets particularly finely and in detail, and at the same time automatically. In particular, it is also possible to automatically select a very specific test environment by expanding the quality status values in the list and distribute software packages there.

[0032] In one embodiment, when the quality status associated with the initial software package switches from the value "new" to another value (i.e., when a new value different from "new" is associated), a new version of the software package is generated, and a quality status with the value "new" is associated with the new version. Among them, the software components associated with the initial version of the software package will be associated with the new version of the software package. Here, the software components of the new version of the software package can be associated in a version different from the initial software package, preferably an updated version.

[0033] In this way, the software package can be continuously further developed without affecting the stability in the operating environment, especially the stability of the vehicle put into use at the customer's place or designed for it.

[0034] In one embodiment, a software package is generated (i.e., software components are associated with it). Next, at least one common equipment attribute required for the software package is identified. At least one vehicle fleet is formed according to the number of vehicles compatible with the software package (i.e., having at least one common equipment attribute). Preferably, a first vehicle fleet and a second vehicle fleet are formed, where the fleet type and / or specified use of the first vehicle fleet are determined according to the operating conditions, and the fleet type and / or specified use of the second vehicle fleet are determined according to the quality assurance purposes, especially verification and / or testing purposes.

[0035] The advantage of this embodiment is that the automation of fleet formation can be achieved particularly well in this way.

[0036] In one embodiment, when generating a software package, it is checked whether there is a conflict between at least one required common equipment attribute that is the basis of the software package and at least one required common equipment attribute of another software package. In particular, when the software package to be generated is based on a required equipment attribute or a set of required equipment attributes, and this equipment attribute or this set of equipment attributes is already the basis of another (existing) software package or is associated with it, the generation of the software package is especially rejected.

[0037] In this way, associating multiple software packages with a vehicle is avoided. In this way, when associating software components of different versions with a vehicle, ambiguity can also be avoided.

[0038] According to a second aspect of the present invention, a software distribution system for distributing at least one software component to at least one vehicle has a vehicle configuration database, an application management system, a software package management system, a vehicle fleet management system, and a package distribution component.

[0039] The vehicle configuration database is set up to associate equipment attributes with vehicles. Here, a vehicle can be uniquely identified by a number or string known as the Vehicle Identification Number (VIN). Based on the VIN, a set of equipment attributes can be associated with each vehicle in the vehicle configuration database, such as the hardware platform, development status, system software, and / or software components for other vehicle control units.

[0040] The application management system is set up to manage system components with associated versions, for example, in the form of a software repository.

[0041] The software package management system is set up to collect at least one software package each including at least one software component, and is set up to associate a quality status with the at least one software package.

[0042] The fleet management system is set up to associate vehicles with a fleet, and to associate at least one equipment attribute and the minimum quality status and / or fleet type and / or specified use with the fleet.

[0043] The package distribution component is set up to associate software packages with at least one fleet vehicle based on at least one common equipment attribute of the fleet and the software package, based on the quality status of the software package, and based on the fleet type and / or minimum quality status and / or specified use of the corresponding fleet.

[0044] Optionally, the package distribution component is designed to respond to queries from a vehicle, where the association of the vehicle with a fleet is determined based on the VIN of the vehicle that issued the query, the software packages associated with the fleet are determined and transmitted to the vehicle.

[0045] The advantages of the software distribution system according to the present invention are consistent with the method for distributing software components according to the first aspect of the present invention.

[0046] In one embodiment, the application management system and / or the software package management system and / or the fleet management system and / or the package distribution component and / or the vehicle configuration database are designed as backend systems and provided outside the vehicle. In this way, the software distribution system can be provided with good usability and has particularly good scalability.

[0047] Embodiments of the present invention will be explained in more detail below with reference to the accompanying drawings.

[0048] Wherein:

[0049] Figure 1 Schematically shows a software distribution system according to the prior art, and

[0050] Figure 2 Schematically shows a software distribution system including a package management system and a fleet management system.

[0051] Parts corresponding to each other in all the drawings are denoted by the same reference numerals.

[0052] Figure 1 Schematically shown is a software distribution system 1 according to the prior art, which is configured to distribute software components 11 to vehicles 20, 21. The software components 11 are managed and provided by a software repository 10.

[0053] For example, the software component 11 may have the attributes of a program, an application, a runtime library, a configuration file, or multimedia data, and can generally be understood as a resource, which itself runs on the control units of the vehicles 20, 21 not shown in detail herein, or is accessed by such a program during runtime. Such control units, such as the infotainment control unit called the host, can be applied in large numbers and in different specification variants in the vehicles 20, 21. For example, the specification variants may differ in terms of hardware configuration and / or software configuration. In addition, the same specification variants of the control unit can also be distinguished by versions, that is, they differ in terms of the development status. Figure 1 Vehicles 20, 21 of different vehicle types can be associated with the same, but can also be associated with different software components 11 in a vehicle type-specific manner.

[0054] Vehicles 20, 21 can be of the same type, but can also be of different types of vehicles, where vehicles of the same type can also have different equipment variants and versions. For example, for the control unit not shown in detail herein, two vehicles 20, 21 of the same vehicle type can have different hardware platforms, different hardware versions (that is: different development statuses of the hardware platform) and / or different software versions.

[0055] In addition, multiple applications or programs dependent on the shared software component 11 can be installed on the vehicles 20, 21. When such a shared software component 11 changes, compatibility with all these applications or programs must then be taken into account. Figure 1

[0056]

[0057]

[0058] ​​​Known methods solve the association problem through a central vehicle association component 30, which assigns software components 11 to vehicles 20, 21 or a group of vehicles 20, 21. Specific vehicles 20, 21 can be identified according to an identification number, for example, using a string called the Vehicle Identification Number (VIN). For a software update request, vehicles 20, 21 can transmit such identification numbers, and the central vehicle association component 30 will thereby determine the software components 11 associated with the specific vehicles 20, 21 and transmit them to vehicles 20, 21. However, due to the extremely large number of vehicles 20, 21 and a large number of software components 11, and they may be designed in different ways for different hardware configurations and may exist in different versions respectively, such an association method is very complex.

[0059] For simplification, on the one hand, the known vehicle association component 30 divides vehicles 20, 21 into vehicle groups, such as a test vehicle group and a customer vehicle group for internal testing of software components 11. On the other hand, the known vehicle association component 30 divides software components 11 into packages. Such packages contain multiple software components 11 and are usually associated with one or more groups of vehicles 20, 21.

[0060] Accordingly, for example, new packages can be created for testing purposes and associated with a specific group of vehicles 20, 21. During this method, although the complexity of the association problem is reduced, there is a risk that a package containing a certain number of software components 11 will be distributed to customer vehicles without being tested or insufficiently tested without freezing its corresponding development status.

[0061] For example, such a package can contain three software components 11, simply referred to as "A", "B", and "C". First, the package is associated with a group of test vehicles with the help of the vehicle association component 30. As an alternative or additionally, after successful testing, the package is associated with a group of customer vehicles. Next, the software component 11 named "B" is provided in a new version (new development status).

[0062] This change will take effect directly on all vehicles 20, 21 associated with the package by the vehicle association component 30, so it will take effect not only on test vehicles but also on customer vehicles. In this way, during the production process, but also possibly during the software update process, software components 11 that have not been tested or have not been fully tested will be installed on customer vehicles. This will affect the reliability and operational safety of vehicles 20, 21.

[0063] Furthermore, by grouping vehicles 20, 21, it is possible to associate the first vehicle 21 with multiple such groups, which in turn are each associated with one or more packages with software components 11. In this way, multiple packages assigned to different groups may be related to the first vehicle 21. As a result, it is possible to accidentally install mutually incompatible software components 11 on the first vehicle 21. Additionally, when associating multiple such packages with vehicle 21, if these packages contain different versions of the same software component 11, ambiguity may arise. Subsequently, the behavior of the software installed or updated on vehicle 21 may depend on the application order of these packages and become unpredictable.

[0064] Therefore, a method is needed to avoid these drawbacks and be able to reliably, traceably, and efficiently associate software components 11 with multiple vehicles 20, 21 and install them on these vehicles. In particular, an automated method is needed that does not require the identification of specific vehicles 20, 21.

[0065] Figure 2 Schematically shown is a software distribution system 1 according to the present invention, which includes an Application Management System (AMS) 100, a Software Package Management (SPM) system 50, a package distribution component 300, a Fleet Management (FM) system 40, and a Vehicle Configuration Database (VCD) 60.

[0066] The software package management system 50 generates and manages software packages 51, which are each associated with at least one, but typically with multiple, software components 11 having defined versions. Further, the software packages 51 are associated with a quality status, such as the initial quality status "new", the quality status "ready for testing", or the quality status "ready for production". Additionally, the software packages 51 are associated with a version number. In addition, an expiration period can be associated with the software packages 51, which describes the time period during which the software packages 51 can be distributed to and / or run on vehicles 20, 21.

[0067] The software package management system 50 manages the software packages 51 such that the components 11 are invariantly associated with the software packages 51. For a component 11 associated with a software package 51 in a specific version, if it is to be replaced with another version of the same software package 51, a new incremented version must be assigned to the software package 51 itself, and the initial quality status "new" must be reassigned.

[0068] In this way, it is ensured that the software components 11 contained therein are uniquely and persistently determined by the software package 51 and its version. This can prevent accidental changes to the software package 51 that may threaten its quality.

[0069] Preferably, the software package management system 50 is provided as a backend system on a server outside the vehicles 20, 21 or as a cloud service.

[0070] The application management system 100 is set up for the acquisition, version management and provision of the software components 11. In particular, it is set up to continuously acquire different development states or versions of the software components 11 and the relationship between new and old versions (that is: the version tree), so that, for example, the development state can be identified and restored based on a hash value, a timestamp, or a label made with a string called a "tag".

[0071] Preferably, the fleet management system 40 (Fleet Management, FM) associates the specific vehicles 20, 21 that can be identified with one, or optionally, with multiple fleets 41 respectively by means of vehicle identification codes. The fleets 41 are formed by multiple vehicles 20, 21, which are equivalent at least in terms of software-related equipment attributes, that is, in terms of the installability and executability of the software components 11, that is, their control units related to the software components 11 have at least one identical hardware platform.

[0072] The association between the vehicles 20, 21 and the fleets 41 will be automatically implemented by the fleet management system 40 using the equipment attributes collected in the vehicle configuration database 60 (Vehicle Configuration Dateabase, VCD). As an alternative or additionally, the vehicles 20, 21 can be manually associated with one or more fleets 41.

[0073] Preferably, the fleet management system 40 generates multiple equivalent fleets 41 of the same, common fleet level for the group of software-related equipment attributes. The individual fleets 41 of a fleet level may differ in terms of fleet type. For example, the fleet type can label the fleet 41 as for test purposes. As an alternative, the fleet type can label the fleet 41 for production or in-use, the vehicles 20, 21 contained therein being put into use at the customer's site or potentially sold to customers. The fleet type can also label the fleet 41 designed for special purposes, the vehicles 20, 21 contained therein being designed for specific marketing activities, for example.

[0074] In one embodiment, the fleet management system 40 is provided as a backend system, which is implemented on a server outside the vehicles 20, 21 or in the form of a cloud service.

[0075] In addition, peer fleets 41 (utilizing the same equipment property descriptions related to software) can be processed differently in software updates according to fleet types, for example, in terms of the necessary maturity or the minimum quality status that the software components 11 must have, in order to be associated with the fleets 41 of a specific fleet type.

[0076] Similarly, at least one required quality status, such as the quality status "Delivery Ready", can be associated with the fleets 41 independently of the associated fleet type.

[0077] Furthermore, a specified use can be associated with the fleets 41, such as the specified use "Delivery" or the specified use "Internal Testing". In this way, software updates can be distributed to the fleets 41 more specifically. For example, for the fleets 41 with the specified use of "Delivery", they can be excluded from the software updates performed with the software components 11 that still need to complete component testing. Conversely, for software updates performed with the software components 11 that have completed testing, if relevant satisfaction surveys need to be carried out, such software updates can be distributed to the fleets 41 with the specified use of "Delivery".

[0078] By grouping the software components 11 into software packages 51 and grouping the vehicles 20, 21 (which are peer in terms of compatibility with the software packages 51) into fleets 41, compared with the prior art, the association of the software components 11 to the specific vehicles 20, 21 can be reduced to the association of the software packages 51 to the fleets 41. This association will utilize the equipment properties collected in the vehicle configuration database 60 and is implemented by the package distribution component 300. Compared with the aforementioned vehicle association component 30, the reduced complexity of this association task is Figure 2 shown by a smaller vertical extension (the number of software packages 51 is reduced and / or the number of fleets 41 is reduced compared to the number of software components 11 and the number of vehicles 20, 21, respectively). Preferably, the package distribution component 300 is provided as a backend system, which is implemented on a server outside the vehicles 20, 21 or in the form of a cloud service.

[0079] Furthermore, a Quality Assurance System (QAS) 70 is arranged between the software package management system 50 and the fleet management system 40. Through the quality assurance system 70, according to the results of testing and / or other quality assurance measures, the quality status of the software components 11 of the software packages 51 is determined. The determined quality status will be associated by the software package management system 50 with the versions of the software packages 51, which contain a certain number of software components 11 with determined and unchanged versions.

[0080] Next, the process of performing a software update on the first vehicle 21 with the software distribution system 1 is described.

[0081] Before distribution, the first vehicle 21 requests a suitable software component 11 from the package distribution component 300. Based on the vehicle identification code transferred with this request, the package distribution component 300 queries the fleet management system 40 for the association between the requesting first vehicle 21 and the fleet 41. The fleet management system 40 determines the fleet 41 associated with the first vehicle 21 using the vehicle identification code of the first vehicle 21.

[0082] Next, the package distribution component 300 determines the software package 51 designed for the first vehicle 21 using the associated fleet 41. Here, the package distribution component 300 takes into account the quality status and version of the software package 51. Further, it also takes into account the fleet type, the intended use, and optionally, other attributes assigned to the fleet 41 according to the regulations. This way, for example, the following situation can be prevented: distributing a software package 51 whose version does not have the lowest quality status of "ready for delivery" to a vehicle 21 whose intended use in the affiliated fleet 41 is "delivery" or whose fleet type is "customer fleet".

[0083] After the package distribution component 300 has determined the software package 51 designated for the first vehicle 21, the package distribution component obtains the determined software package 51 from the software package management system 50. The software package management system 50, preferably designed as a backend system, returns a list whose content is the software components 11 included in the requested software package 51 and their respective versions.

[0084] The list of the software components 11 will be returned by the package distribution component 300 to the first vehicle 21 according to the first vehicle's request for the matching software components 11. Next, the first vehicle 21 will download the software components 11 listed in the list from the application management system 100 and install them on the specified control unit or multiple specified control units.

[0085] To create the software package 51, a description is transferred to the software package management system 50, which contains a list of the attributes of the vehicles 20, 21 specified for the software package 51. Based on this description, the software package management system 50 checks the compatibility of the software package 51 with the software packages 51 that have been collected and / or distributed.

[0086] For example, if another software package 51 has been collected and / or distributed for the same group of attributes of the vehicles 20, 21 as the transferred list, the software package management system 50 will reject the request to create the software package 51 to avoid associating multiple software packages 51 with the vehicles 20, 21.

[0087] Furthermore, the software package management system 50 can audit the consistency of the transferred attributes in the list. For example, by comparing with the vehicle configuration database 60, it can be checked whether vehicles 20, 21 are collected there with the transferred combination of attributes (e.g., with the combination of vehicle model and control unit hardware equipment variant).

[0088] Furthermore, the software package management system 50 can audit the uniqueness of the transferred attributes in the list. For example, a certain collected software package 51 may already be associated with a certain vehicle model with a control unit hardware configuration variant HW-A. In the list, if the same vehicle model is combined with an engine type E-A as an attribute, the software package management system 50 will check by comparing with the vehicle configuration database 60 whether vehicles 20, 21 of this vehicle model are collected, which not only have the control unit equipment variant HW-A but also the engine type E-A. If such vehicles 20, 21 are collected, the software package management system 50 will divide these vehicles 20, 21 into non-overlapping subsets. Alternatively, the software package management system 50 rejects the request to create the software package 51 based on the transferred attribute list to prevent different software packages 51 from being associated with these vehicles 20, 21.

[0089] For the new software package 51, the software package management system 50 also creates an initial version (″version 0″) and assigns it a quality status of ″newly added″.

[0090] In addition, the software package management system 50 arranges for the fleet management system 40 to create a fleet 41. Here, the fleet management system 40 first generates a fleet level, that is: an abstract representation of all possible fleets 41 that can be associated with the same software-related equipment attributes. Next, the fleet management system 40 generates at least one fleet, preferably multiple fleets 41, each of which contains at least one vehicle 20, 21, preferably multiple vehicles 20, 21, for such a fleet level.

[0091] The fleet management system 40 saves a list of associated equipment attributes (e.g., specifications variants of the hardware platform including vehicle model, one or more control units, and / or engine type, and development status and other attributes as options) for each fleet level. In addition, each fleet level is associated with and stored with the software package 51.

[0092] Now, after generating the fleet levels, a, preferably multiple, fleets 41 are generated by the fleet management system 40 and associated with the fleet levels. Fleets 41 of the same fleet level will be associated with non - overlapping subsets of vehicles 20, 21 that have equipment attributes associated with the fleet level. This relates to both current (i.e., already produced) and future - produced vehicles 20, 21. However, fleets 41 of the same fleet level may differ in other attributes, such as in the fleet type, in the minimum quality status (required for installing the software package 51 on the vehicles 20, 21 corresponding to the fleet 41) and / or in the intended use.

[0093] As already described, the first fleet 41 of a certain fleet level can have the attributes of a test vehicle fleet 41 for performing tests. The second fleet 41 of the same fleet level can have the attributes of a marketing fleet. The vehicles 20, 21 of this fleet level will be used for marketing activities or roadshows. The third fleet 41 of the same fleet level, as a production fleet, can include vehicles 20, 21 put into use by customers or designed for this purpose.

[0094] Preferably, the fleets 41 are automatically formed by the fleet management system 40. For this purpose, the overall population of vehicles 20, 21 is first called from the vehicle configuration database 60, which has equipment attributes associated with the corresponding fleet level. Next, vehicles 20, 21 are selected from this population and assigned to the fleets 41, which have the intended use (″delivery″ or ″internal test″) associated with the fleet 41 and optionally have other attributes.

[0095] By dividing vehicles 20, 21 that have equivalent (i.e., set for installing the same software package 51) equipment attributes in terms of software into non - overlapping fleets 41, tests can be carried out specifically in a particular application environment. At the same time, vehicles 20, 21 in a critical application environment (typically vehicles 20, 21 associated with the production fleet and / or whose intended use is ″delivery″) will be protected from installing software packages 51 that do not yet have a sufficient quality status for this application environment.

[0096] Newly developed or updated, i.e., provided in a new version, software components 11 will be collected in the application management system 100. During collection, in addition to the software component 11 itself, its unique name, its version, and a list of the equipment attributes of the vehicles 20, 21 required for installation are also collected and stored. These required equipment attributes can be associated as attributes or tags.

[0097] Next, the newly provided or newly - versioned software component 11 is added to the software package 51 by the software package management system 50, the software package

[0098] - Currently associated with the quality status "new", and

[0099] - Associated with the attributes of vehicles 20, 21 that are necessary for the newly provided software component 11.

[0100] In this way, it can be ensured that new and not yet fully tested software components 11 are not distributed to critical operating environments with high quality requirements.

[0101] If a new (or existing as a new version) software component 11 is added, in order to generate a new version of a software package 51, the software package management system 50 will regularly or upon request obtain confirmation from the approval responsible person. If confirmation is given, the quality status of the corresponding software package 51 will be set from "new" to "package generation completed". Thereafter, a new version of the software package 51 will be generated for each relevant software package 51, wherein each included software component 11 will be applied to the new version of the software package 51 and associated with the quality status "new".

[0102] Next, the software package 51 with the quality status "package generation completed" will be verified by the quality assurance system 70. If the quality status changes from "new" to "generation completed", the quality assurance system 70 will be notified. Next, the quality assurance system will request a fleet 41 suitable for the corresponding software package 51 from the fleet management system 40 for verification. Using the attributes associated with the software package 51 and / or using the associated specified uses and / or using the minimum quality status, the fleet management system 40 determines at least one suitable fleet 41.

[0103] The verification can be carried out automatically, for example, by formal verification tools, unit tests or other automated test methods. As an alternative or supplement, the verification can also be carried out manually, for example, by audits or manual tests.

[0104] Only as an example, a smoke test can be performed to test whether the software package 51 is successfully distributed to the control units of the vehicles 20, 21 associated with the fleet 41. Additionally or as an alternative, a functional test can be performed. For example, it can be tested whether the heating control function of the control unit equipped with the software package 51 can correctly control the seat heating device. An integration test can also be performed, for example, transferring points of interest (POIs) from a smartphone to the navigation function of the control unit equipped with the software package 51, or checking the interaction between such a navigation function of the electric vehicles 20, 21 and the vehicle battery charging planning function.

[0105] The exact verification measures will be determined based on the properties of the corresponding software package 51, the fleet 41 of the associated test vehicles, the current quality status, and / or the associated version.

[0106] After successful completion of the verification, the quality status "ready for delivery" is associated with the corresponding software package 51. Here, further quality statuses can be associated between the quality status "generation completed" and the quality status "ready for delivery" according to the process of the verification measures, such as the quality status "completed service integration" or the quality status "completed quality management tests". In the order described, these quality statuses represent an improvement in the quality level.

[0107] The quality status will be associated successively according to the success or failure of the verification and / or quality assurance measures performed.

[0108] During the life cycle, vehicles 20, 21 will regularly (e.g., during each startup process) query the package distribution component 300 for the latest list of software components 11 for the control unit, where the vehicle identification codes of vehicles 20, 21 are submitted.

[0109] Next, the package distribution component 300 determines the latest software package 51 associated with the vehicle 20, 21 as follows: Based on the submitted vehicle identification code, the package distribution component 300 determines the properties of the vehicle 20, 21 by querying the vehicle configuration database 60. Based on these properties, the package distribution component 300 determines the fleet 41 associated with the intended use of the vehicle 20, 21 and having the greatest degree of match with the properties of the vehicle by querying the fleet management system 40.

[0110] The software package 51 thus determined will be obtained by the software package management system 50 with the most recent (latest) version, the validity period of which includes the query moment, and the associated quality status of which conforms to the lowest quality status of the fleet 41 associated with the vehicle 20, 21 that issued the request.

[0111] The software components 11 included in this version of the software package 51 will be transmitted to the vehicle 20, 21 that issued the request and installed on its control unit.

Claims

1. A method for distributing at least one software component (11) to at least one vehicle (20, 21), characterized in that, - at least one vehicle fleet (41) is formed from the totality of the vehicles (20, 21) having at least one common equipment attribute, wherein each vehicle fleet (41) is respectively associated with at least one minimum quality status and / or one fleet type and / or one specified use; - at least one software package (51) is formed, the at least one software package including the at least one software component (11) associated with a fixed version to the software package (51), wherein each software component (11) is compatible with at least one common equipment attribute of the at least one vehicle fleet (41) and is compatible with other software components (11) in the case of multiple software components (11); - a quality status is associated with each software package (51) according to the result of the quality assurance measures to be performed next; and - according to at least one common equipment attribute of the vehicle fleet (41) and the software package (51), according to the quality status of the software package (51), and according to the fleet type and / or the minimum quality status and / or the specified use corresponding to the vehicle fleet (41), the software package (51) is respectively associated with the at least one vehicle fleet (41).

2. The method according to claim 1, characterized in that, for the totality of the vehicles (20, 21) having at least one common equipment attribute, at least one first vehicle fleet (41) of the fleet type for test purposes is formed, and at least one second vehicle fleet (41) of the fleet type for delivery to customers and / or for use at customers is formed, wherein the first vehicle fleet (41) is associated with a minimum quality status different from that of the second vehicle fleet (41), such that the software packages (51) with a quality status designed for test purposes are associated with at least one of the vehicles (20, 21) of the first vehicle fleet (41), but not with at least one of the vehicles (20, 21) of the second vehicle fleet (41).

3. The method according to any one of the preceding claims, characterized in that, the quality status respectively associated with the software package (51) and the minimum quality status respectively associated with the vehicle fleet (41) are extracted from an ordered list.

4. The method according to claim 3, characterized in that, the ordered list contains the values "new", "package generation completed", "integration test completed", and "quality management test completed".

5. The method according to claim 4, characterized in that, when the quality status of the initial software package (51) changes from the value "new" to another value, a new version of the software package (51) is generated and a quality status of "new" is associated therewith, and the software component (11) associated with the initial version of the software package (51) will be associated with the new version of the software package (51).

6. The method according to any one of the preceding claims, characterized in that, Generate the software package (51), and then generate the first fleet and the second fleet (41) according to at least one common equipment attribute of the software package (51).

7. The method according to any one of the preceding claims, wherein, when generating the software package (51), determine at least one equipment attribute associated with the software package (51), and when the at least one equipment attribute has been associated with an existing software package (51), reject generating the software package.

8. A software distribution system (1) for distributing at least one software component (11) to at least one vehicle (20, 21) according to the method described in the preceding claims, wherein, the software distribution system (1) comprises: - a vehicle configuration database (60) configured to associate equipment attributes with the vehicles (20, 21); - an application management system (100) configured to manage the software components (11) with associated versions; - a software package management system (50) configured to collect the at least one software package (51) each including at least one of the software components (11), and configured to associate a quality status with the at least one software package (51); - a fleet management system (40) configured to associate the vehicles (20, 21) with the fleet (41), and to associate at least one equipment attribute and a minimum quality status and a fleet type and / or a specified use with the fleet (41); and - a package distribution component (300) configured to associate the software package (51) with at least one vehicle (20, 21) of the fleet (41) according to at least one common equipment attribute of the fleet (41) and the software package (51), according to the quality status of the software package (51), and according to the fleet type and / or the minimum quality status and / or the specified use of the corresponding fleet (41).

9. The software distribution system (1) according to claim 8, wherein, the application management system (100) and / or the software package management system (50) and / or the fleet management system (40) and / or the package distribution component (300) and / or the vehicle configuration database (60) are designed as backend systems.

Images