Vehicle Ecosystem

Abstract

The present invention relates to a vehicle ecosystem (3) comprising a central processing unit (1) and a fleet of vehicles (2), characterized in that the central processing unit (1) is configured to: receive a development request or initiate it itself; generate a development data package and distribute it to vehicles (2) of a first set (4.1) of the fleet; control the vehicles (2) of the first set (4.1) of the fleet to execute the development data package, wherein the vehicles (2) are configured to record user interaction information obtained in the course of the interaction procedure and transmit it to the central processing unit (1); process the user interaction information and, depending on the knowledge obtained therefrom, generate a deployment data package; and distribute the deployment data package to vehicles (2) of a second set (4.2) of the fleet and execute them respectively for implementation therein.

Description

[Technical Field]

[0001] The present invention relates to a vehicle ecosystem of the kind defined in the preamble of claim 1. [Background technology]

[0002] While traveling in a vehicle, vehicle occupants may become bored, especially when the vehicle is stuck in a traffic jam or congestion. Furthermore, as the degree of automation increases, boredom situations may occur more frequently because the vehicle driver may need to pay less or no attention to the driving events. Therefore, there is a need to provide recreation and entertainment for vehicle occupants while using the vehicle.

[0003] Platforms that broker microjobs are widely known. People who work on such tasks are also called clickworkers. Providing access to such microjobs via the internet is also called crowdsourcing. The most well-known providers of such platforms are Amazon Web Services, Inc., which operates the Mechanical Turk platform (also known as mturk), and Clickworker.de in German-speaking countries. Relatively simple, short-term jobs such as proofreading, answering surveys, and verifying AI learning data are accepted and processed through such platforms. Workers are compensated not only in money but also, in many cases, in the form of vouchers.

[0004] Furthermore, vehicle manufacturers are constantly working to further develop their vehicles in order to make them even more reliable and, above all, to improve customer satisfaction.

[0005] Patent document 1 discloses an AD manager for a vehicle multimedia system. The AD manager collects context-related data generated during vehicle use and enables advertisements adapted to the corresponding context to be displayed in the vehicle. At this time, a request is made to the user for interaction. Then, a set of further display components is output based on the received user input.

[0006] Furthermore, Patent Document 2 discloses the implementation of a questionnaire inside a vehicle. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] German Patent Application Publication No. 102014204227 [Patent Document 2] U.S. Patent No. 10,636,046 Summary of the Invention [Problem to be solved by the invention]

[0008] The present invention is based on the problem of providing an improved vehicle ecosystem that makes it easier for vehicle manufacturers to further develop their vehicles. [Means for solving the problem]

[0009] According to the invention, this problem is solved by a vehicle ecosystem having the features of claim 1. Advantageous embodiments and developments emerge from the claims dependent on this claim.

[0010] A general vehicle ecosystem comprising a central processing unit and a fleet of vehicles, the vehicles of the fleet being in two-way communication with the central processing unit and configured to receive information from the central processing unit to change the configuration of the vehicles, is further developed in accordance with the present invention by: the central processing unit is configured to receive or initiate development requests, the development requests indicating at least which vehicle components must be further developed; -furthermore, the central processing unit is configured to generate a development data package in response to the development request and distribute it to the first set of vehicles of the fleet, the development data package including at least interaction information and optionally configuration information, the interaction information indicating predefined interaction procedures with vehicle occupants via the human-machine interface, and the configuration information including information regarding the introduction of new software-based vehicle functions and / or modifications to existing vehicle functions; - further, the central processing unit is configured to control a first set of vehicles of the fleet to execute the development data package, wherein in each of the vehicles, at least one vehicle function and interaction procedure is performed in response to the interaction information, and optionally at least one vehicle configuration related to the vehicle function is changed in response to the configuration information, and the vehicles are configured to record and transmit to the central processing unit user interaction information obtained in the course of the interaction procedure; - furthermore, the central processing unit is configured to process user interaction information received from the first set of vehicles of the fleet and to generate, depending on knowledge obtained therefrom, an installation data package, the installation data package including information regarding the installation and / or modification of the vehicle function; The central processing unit is further configured to distribute the deployment data package to a second set of vehicles of the fleet and execute it respectively therein for implementation.

[0011] In other words, the vehicle ecosystem according to the present invention represents a vehicle ecosystem capable of further self-development. To this end, the vehicle ecosystem interacts with vehicle users to obtain their feedback on how well or badly a newly developed feature is perceived. Based on this feedback, the vehicle ecosystem can then automatically adjust the corresponding feature, implement it in the vehicle, and request user feedback again. This iterative process allows for the development of particularly satisfying features.

[0012] In this case, the effort required by the vehicle manufacturer is minimal: they only need to maintain the hardware and software components and initiate development requests themselves as needed. The actual development is automatically handled by the vehicle ecosystem.

[0013] In this case, a first set of vehicles in the fleet functions as "test vehicles". Once new or modified features have been developed satisfactorily in the test vehicles, these features are then deployed to other vehicles in the fleet, i.e., the second set of vehicles. This improves user comfort, since usually not all users of vehicles in the fleet will want to take part in the corresponding tests, and changes made to a feature during development can make it worse (temporarily during testing) and reduce user comfort.

[0014] According to an advantageous development of the vehicle ecosystem, the second set of vehicles is correspondingly more numerous than the first set of vehicles. Users who wish to contribute to the development of vehicles can therefore provide their vehicles as part of the first set of vehicles, while the vehicles of other users can form the second set of vehicles. However, typically the second set of vehicles may be the same number as or less than the first set of vehicles.

[0015] The components of a fleet vehicle can be configured in a variety of ways. Configurations include, for example, the configuration parameters of vehicle subsystems. A control unit, for example, uses the corresponding parameters to control vehicle components. Examples include chassis stiffness or spring deflection, automatic transmission shift timing, air conditioning air temperature, and the front-end design of the operating interface between the vehicle occupants and the vehicle infotainment system, i.e., the graphic design of the user interface, the underlying menu navigation, and the preferred settings for vehicle interior lighting, such as ambient lighting. All of these systems and functions are configurable, allowing their operation to be adapted. Similarly, new features can be incorporated into the vehicle, such as better-trained machine learning models for image recognition (also known as computer vision) or voice dialogue systems for voice-based user interaction. This allows for better recognition of traffic participants and traffic signs, as well as better recognition of the intent of user voice commands, using corresponding AI methods. Vehicles in the fleet receive corresponding updates wirelessly (also known as "over the air") from the central processing unit. For this purpose, the vehicles of the fleet can be equipped with a telecommunications unit which is indirectly communicatively connected via the Internet via mobile radio to a central processing unit, which is a cloud server also called backend.

[0016] Development requests can be initiated by the vehicle manufacturer's developers themselves, i.e., if the vehicle manufacturer wants to further develop a particular vehicle component, the vehicle manufacturer grants a corresponding development request. However, the central processing unit can also initiate development requests itself, as will be described below.

[0017] The development data package contains at least interaction information, which describes predefined interaction procedures. The interaction information is used to generate user interactions that enable the central processing unit to collect relevant information necessary for the development of the corresponding vehicle component. For this purpose, different man-machine interfaces can be used, such as microphones and speakers for acoustic interaction, and display devices and operating elements for visual interaction. For example, questions that the corresponding vehicle user can answer can be displayed via the instrument cluster, head-up display, central display, head unit, or other displays in the vehicle. For interaction, the user's mobile device, which is connected to the vehicle via Bluetooth, can also be used. For example, an app can be run on a smartphone, which is connected to the vehicle via Bluetooth.

[0018] For example, in such a questionnaire, the vehicle user could be shown an image of a traffic situation captured by a vehicle camera. The user could then be asked what is visible in the image, how the user evaluates the mechanical classification of the objects recognized in the image, whether the displayed image matches the surroundings of the vehicle, whether the sound being played matches the displayed surroundings of the vehicle, and whether the situation recognized by the driver assistance system matches the actual situation, i.e., whether traffic signs are correctly recognized, whether the vehicle is actually in the expected driving lane, whether there are available parking spaces to the left or right of the vehicle, whether there are actually emergency transportation routes on the highway, what the nature of the road surface is, and, for example, whether the road surface is correctly classified by the driver assistance system, whether warning lights were activated in a timely manner, etc. Furthermore, the user could be given the opportunity to make appropriate corrections or suggestions to the evaluation of the assistance system. Similarly, the user could be asked to what extent the traffic congestion displayed on his vehicle matches reality and where there are discrepancies. Furthermore, modules can be developed to evaluate the behavior of other traffic participants, for example, to predict their control behavior.

[0019] Software modifications can also be made that affect the vehicle's physical components, such as changing control parameters and / or saving modified characteristic curves. For example, a chassis can be configured according to five different stiffnesses, which the user must rate. The degree of stiffness could also be changed automatically, requiring the user to report any significant changes as soon as they are noticed. The vehicle can also autonomously perform specific maneuvers, such as lane changes, overtaking, braking, accelerating, cornering, and parking, and then be rated. For example, the user can rate how comfortably the corresponding maneuver was performed. This rating can be expressed, for example, as a score from 1 to 10 and / or as a verbal description. For example, the user can indicate whether the maneuver felt sporty, awkward, dangerous, etc. At the same time, the user can rate and / or comment on the infrastructure around the vehicle. The user can also provide feedback to the user interface. For example, the user can be asked which menu navigation felt more intuitive, whether the prompts were too fast or too slow, whether displayed objects were clearly recognizable, etc.

[0020] Regarding acoustic user interaction, the user can be asked, for example, whether the speech of the voice dialogue system was easy to understand, whether the speech was grammatically correct, whether the speech was accented or dialect-free, etc. It is also possible to translate text and request the user to enter the translation acoustically or text-based. The user can also be asked to rate the quality of the machine translation. Furthermore, audio files can be transmitted to the vehicle and played back. For example, sounds classified by AI can be played back, and the user must rate whether the AI ​​correctly assigned the sound (e.g., a police siren). In this case, the user can also rate how accurate the computer system's automatic assignment of the sound was.

[0021] The components and behaviors listed here are merely examples to enhance understanding of the vehicle ecosystem according to the present invention and should not be construed as limiting.

[0022] Using this user interaction, the vehicle ecosystem can find improved, i.e., more reliable and comfortable, settings for vehicle subsystems, further train machine learning models such as AI, and improve the overall user interaction between the user and the vehicle. The generated user interaction information is then recorded by each vehicle itself and sent to a central processing unit for evaluation. The evaluation of the user interaction information is also performed automatically, so no effort is required from the vehicle manufacturer's developers. However, since the developers have access to the analysis process, they can of course see how the central processing unit is operating and adjust its operation method as necessary. For example, the developers can change how the central processing unit evaluates aspects such as whether to classify specific feedback received from the user as overall positive or negative, and to what extent this feedback influences the automated further development of vehicle functions.

[0023] After analyzing the user interaction information and performing the actual component development, the central processing unit generates the deployment data package. This package is then distributed to a second set of vehicles in the fleet and implemented there. This allows for further deployment of the developed vehicle components in the vehicles. In this case, the second set of vehicles may be as large as all vehicles in the fleet. Of course, it is also possible to configure or implement only software-based vehicle components or functions. Operation of physical vehicle components, which in a broad sense includes not only the hardware of the processing unit but also the mechanical components of the vehicle, is possible by adapting control parameters of the vehicle control unit.

[0024] According to a further advantageous embodiment of the vehicle ecosystem, at least a subset of the vehicles in the fleet is configured to collect and transmit usage information to a central processing unit, the usage information indicating a vehicle function procedure, and the central processing unit is further configured to process the usage information and analyze therein that self-initiating a development request is necessary if a comparison of an interaction success included in the vehicle function procedure with an interaction success threshold indicates that the interaction success is less than the interaction success threshold.

[0025] This can be explained as follows: The vehicle functions mainly include a voice dialogue system. Therefore, the vehicle function procedures included in the usage information are conversations between the vehicle occupant and the voice dialogue system. This conversation may be included in the digital data as an audio file and / or a transcript. A successful interaction can be understood as a vehicle occupant giving a voice command, for example, to set a specific radio station, change the volume, activate a seat heater, or change the air conditioning fan setting, which is correctly understood and implemented by the voice dialogue system. In some cases, the voice dialogue system may not be able to understand the corresponding vehicle occupant. The interaction success threshold can be, for example, 80%. If the voice dialogue system correctly understands the vehicle occupant and implements the command that the vehicle occupant actually wants to execute in more than 80% of cases, the interaction success is above the interaction success threshold. Conversely, if this is not the case, it means that the voice dialogue system is not yet functioning well enough. This allows the central processing unit to recognize the need for further development of the voice dialogue system. Based on this, the central processing unit then initiates a development request itself. For example, corresponding parameters can be defined for various vehicle components and vehicle functions, and based on the analysis thereof, the central processing unit can evaluate whether the corresponding system should be further developed.

[0026] In a further advantageous embodiment of the vehicle ecosystem, the central processing unit includes an access interface and is configured to allow third parties to initiate development requests via the access interface. The central processing unit then acts as an intermediary, determining how deeply the third parties are allowed to intervene in the configuration of the respective vehicle. This allows the vehicle manufacturer to grant access to the vehicle to third parties, such as the vehicle manufacturer's parts suppliers, service providers such as insurance, or other companies or workshops, so that each third party can develop its own solution. However, in this case, data protection and cybersecurity must be maintained. Accordingly, the central processing unit acts as an intermediary and determines the extent to which each third party is allowed to intervene in the vehicle. The access interface can be realized, for example, as an API or can use such an API.

[0027] According to a further advantageous embodiment of the vehicle ecosystem, at least some of the vehicles in the fleet are configured to collect vehicle characteristic information and / or user characteristic information and transmit them to a central processing unit. The central processing unit is further configured to determine a first and / or second set of vehicles in the fleet by taking into account the vehicle characteristic information and / or user characteristic information. The vehicle characteristic information is a detailed specification of the vehicle or vehicle components. For example, the vehicle characteristic information indicates whether the vehicle is a pickup, a van, an SUV, a transporter, or a combination truck. Other information is related to the detailed specifications of the vehicle, such as what special equipment is installed, the power of the vehicle's drive mechanism, whether an electric drive motor and / or an internal combustion engine is installed, whether the vehicle is a convertible, etc. For example, a specific development request may only be related to a specific vehicle component or only be suitable for a limited vehicle specification. Taking into account the vehicle characteristic information, the central processing unit can determine the first and / or second set of vehicles, respectively, thereby distributing the development requests to the corresponding vehicles. If, for example, development requires capturing camera images of the vehicle's surroundings using a vehicle camera and evaluating them using machine learning techniques, the corresponding development request and development data package will be allocated only to vehicles equipped with that camera.

[0028] In addition to detailed vehicle specifications, user-related information may also be important for determining who receives each development request. User characteristic information may include demographic information such as age, gender, and hometown, as well as location, income, hobbies, average monthly mileage, driving style, marital status, and number of children. For example, a particular vehicle feature may be evaluated differently by different users. In this case, taking into account user-descriptive information, the central processing unit can provide a particularly differentiated evaluation. For example, a vehicle driver with a sporty driving style may prefer a stiffer chassis than a driver who prioritizes comfort. Another development request may be related only to driving or vehicle use with children as passengers. Correspondingly, these development requests are distributed only to vehicles that frequently carry children. Some development requests may require multiple vehicle occupants to interact together and, for example, complete a survey as a group. For children, such a survey may be designed as a video game, based on gamification.

[0029] Here, the user characteristic information transmitted by the users of the vehicles in the fleet can be weighted by the central processing unit according to various criteria. This allows different users to be trusted to different degrees, which means that the data provided when answering the questionnaire is correct. Therefore, the user characteristic information can include, for example, such a reliability factor. Inputs from users with a high reliability factor are weighted accordingly. However, the weighting can also be based on other information.

[0030] According to a further advantageous embodiment of the vehicle ecosystem, the central processing unit is configured to receive offer time information indicating which time periods each vehicle user offers for using their vehicle. The offer time information can then be taken into account to determine the first set of vehicles in the fleet. This can further improve the comfort of the vehicle users. The vehicle users can fill out the corresponding questionnaires on their mobile terminals, such as smartphones, tablets, or laptops, or even on their desktop computers. This can be done at home during quiet hours. However, it is particularly advantageous to have the user interact with the vehicle while it is in use. For example, this can prevent the vehicle occupants from getting bored and, in addition, allows them to directly experience the vehicle components they are evaluating, thereby providing direct feedback. For this purpose, the central processing unit needs information about the time periods each user uses the vehicle. This offer time information, i.e., information about the date and time each user uses the vehicle, can be directly transmitted to the central processing unit. For example, the vehicle users can inform the central processing unit of the date and time they will be traveling in the vehicle via their mobile terminals or the vehicle's infotainment system. This can include, for example, their daily commute route. The vehicle itself, using a central processing unit or computing unit within the vehicle, can also recognize the corresponding travel patterns.

[0031] In the simplest case, the vehicles in the fleet signal the start of the delivery time when their respective drive machines start, and the delivery time therefore ends when the drive machines are manually turned off.

[0032] According to a further advantageous embodiment of the vehicle ecosystem, at least a subset of the vehicles of the fleet are configured to communicate route information to a central processing unit, which is further configured to process the route information to detect presentation time information, for example, when a driving route has been entered into a navigation system, the vehicles can automatically detect that there are presentation times while traveling along the navigation route.

[0033] According to a further advantageous embodiment of the vehicle ecosystem according to the present invention, the central processing unit is configured to provide each vehicle user with an individual incentive account, and to add incentive credits to the respective incentive account when the respective vehicle user provides user interaction information to the central processing unit as part of a first set of vehicles in the fleet. In other words, vehicle users who participate in the further development of vehicle components are rewarded. The incentive credits can be, for example, money, a voucher, or even an extension of the usage period of a subscribed vehicle function. Each vehicle user can, for example, deposit money into a bank account. The voucher can be used, for example, at a contract workshop for maintenance or repairs. Certain vehicle functions, such as providing heated seats or improved driving performance, can be subscribed to and used for a period of time, such as one year. After the period expires, the function will no longer be available. The incentive credits can be, for example, an extension of the usage period of a function by one month. This increases the motivation of vehicle users to provide corresponding user interaction information. This also increases the certainty of the vehicle ecosystem's further self-development.

[0034] Preferably, the vehicles in the fleet are configured to provide a secure environment for executing development data packages, where access to vehicle resources is restricted for normal operation. This particularly improves cybersecurity. For example, a virtual machine on which the corresponding development package runs can be executed on a computing unit in the vehicle. This can also limit the extent to which the computing unit can access vehicle functions. In particular, this prevents prohibited unauthorized interception or manipulation of security-related configuration parameters when third parties grant development requests.

[0035] The entities of the vehicle ecosystem, i.e. the central processing unit as well as the vehicles of the fleet, are not only configured to provide the process described above but also to further execute this process. Thus, according to the present invention, a method for a vehicle ecosystem is presented, the use of which allows the vehicle ecosystem to further develop on its own.

[0036] Further advantageous embodiments of the vehicle ecosystem according to the invention are evident from the detailed exemplary embodiments which are explained below with reference to the figures. [Brief explanation of the drawings]

[0037] [Figure 1] 1 is a schematic diagram of a vehicle ecosystem according to the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0038] The central processing unit 1 and the multiple vehicles 2 form a vehicle ecosystem 3 according to the present invention. The vehicle ecosystem 3 according to the present invention has the ability to further develop by itself.

[0039] To this end, the central processing unit 1 distributes a development data package to the vehicles 2 of the first set 4.1 of the vehicle fleet shown. The development data package includes interaction information and, optionally, configuration information. The interaction information indicates a predefined interaction procedure with the vehicle occupants. The configuration information provides the respective vehicles 2 with the software-based vehicle function installation and / or modification of existing vehicle functions. The vehicle occupants or vehicle users of the vehicles 2 of the first set 4.1 of the vehicle fleet provide feedback regarding the vehicle components to be further developed according to the predefined interaction procedure. The vehicles 2 or the computing units installed therein collect user feedback in the form of user interaction information and transmit it to the central processing unit 1. The user interaction information is then evaluated, and based on this, the central processing unit 1 generates an implementation data package. The implementation data package includes settings that have been positively evaluated by individual vehicle users or newly developed or adjusted algorithms and / or machine learning models. The implementation data package is then distributed to the vehicles 2 of the second set 4.2 of the vehicle fleet. The first set 4.1 and the second set 4.2 may be of different or equal quantity. The second set 4.2 may be smaller, equal or preferably larger than the first set 4.1. An individual vehicle 2 may not be a member of either set 4.1, 4.2, depending on the execution of the development data package.

[0040] The central processing unit 1 can decide by itself, depending on the circumstances, which vehicles 2 belong to the first and / or second set 4.1, 4.2. For this purpose, the central processing unit 1 takes into account vehicle characteristic information and / or user characteristic information.

[0041] Optionally, the third party 5 may be part of the vehicle ecosystem 3, e.g. a parts supplier of the vehicle manufacturer, a workshop, a navigation software developer, etc. This allows the third party 5 to use the vehicle ecosystem 3 according to the invention to further their own developments in the automotive environment. The operator of the central processing unit 1, e.g. a vehicle manufacturer, may request a fee from the third party 5 for access to the vehicle 2 via the described infrastructure.

Claims

1. A vehicle ecosystem (3) comprising a central processing unit (1) and a fleet of vehicles, wherein the vehicles (2) of the fleet communicate with the central processing unit (1) bidirectionally and are configured to change the configuration of the vehicles (2) by receiving information from the central processing unit (1), - said central processing unit (1) is configured to receive or initiate development requests, said development requests indicating at least which vehicle components must be further developed; - furthermore, said central processing unit (1) is configured to generate a development data package in response to said development request and distribute it to said vehicles (2) of a first set (4.1) of said fleet of vehicles, said development data package including at least interaction information and optionally configuration information, said interaction information indicating predefined interaction procedures with vehicle occupants via a human-machine interface, said configuration information including information regarding the introduction of new software-based vehicle functions and / or modifications to existing vehicle functions; - furthermore, said central processing unit (1) is configured to control said vehicles (2) of said first set (4.1) of said fleet of vehicles to execute said development data package, wherein in each of said vehicles (2) at least one vehicle function and said interaction procedure is executed in response to said interaction information, and optionally at least one vehicle configuration related to said vehicle function is changed in response to said configuration information, said vehicles (2) being configured to record and transmit to said central processing unit (1) user interaction information obtained in the course of said interaction procedure, - the central processing unit (1) is further configured to process the user interaction information obtained from the vehicles (2) of the first set (4.1) of the fleet and to generate an installation data package depending on the knowledge obtained therefrom, the installation data package containing information on the installation and / or modification of the mentioned vehicle functions, Furthermore, the central processing unit (1) is configured to distribute the installation data package to the vehicles (2) of a second set (4.2) of the fleet of vehicles and execute it therein for installation. A vehicle ecosystem (3).

2. 2. The vehicle ecosystem (3) according to claim 1, characterized in that the vehicles (2) of the second set (4.2) are more numerous than the vehicles (2) of the first set (4.1).

3. 3. The vehicle ecosystem (3) of claim 1 or 2, characterized in that at least some of the vehicles (2) of the fleet are configured to obtain and transmit usage information to the central processing unit (1), the usage information indicating a vehicle function procedure, and the central processing unit (1) is further configured to process the usage information and recognize that self-initiation of the development request is necessary if a comparison of an interaction success included in the vehicle function procedure with an interaction success threshold indicates that the interaction success is less than the interaction success threshold.

4. 4. The vehicle ecosystem (3) of claim 1, wherein the central processing unit (1) comprises an access interface and is further configured to allow a third party (5) to initiate the development request from the access interface, and wherein the central processing unit (1) acts as an intermediary that determines how deeply the third party (5) is allowed to intervene in the configuration of each vehicle (2).

5. 5. A vehicle ecosystem (3) according to any one of claims 1 to 4, characterized in that at least some of the vehicles (2) of the fleet are configured to collect vehicle characteristic information and / or user characteristic information and transmit them to the central processing unit (1), and further characterized in that the central processing unit (1) is configured to determine the vehicles (2) of the first and / or second sets (4.1, 4.2) of the fleet taking into account the vehicle characteristic information and / or the user characteristic information.

6. 6. The vehicle ecosystem (3) according to any one of claims 1 to 5, characterized in that the central processing unit (1) is configured to receive offering time information indicating which time periods each vehicle user offers to use his / her vehicle (2), so that the vehicles (2) of the first set (4.1) of the fleet can be determined taking into account the offering time information.

7. 7. The vehicle ecosystem (3) of claim 6, wherein at least some of the vehicles (2) of the fleet are configured to transmit route information to the central processing unit (1), and the central processing unit (1) is further configured to process the route information to detect the delivery time information.

8. 8. The vehicle ecosystem (3) of any one of claims 1 to 7, further characterized in that the central processing unit (1) is configured to provide each of the vehicle users with an individual incentive account, and to add incentive credits to each of the incentive accounts when each of the vehicle users provides user interaction information to the central processing unit (1) as part of the vehicle (2) of the first set (4.1) of the fleet of vehicles.

9. 9. A vehicle ecosystem (3) according to any one of claims 1 to 8, characterized in that the vehicles (2) of the fleet are configured to provide a secure environment for executing development data packages, and access to vehicle resources in the secure environment is restricted for normal operation.

Images