WO2019206502A1 - Fahrzeugbetriebssystem - Google Patents

Fahrzeugbetriebssystem Download PDF

Info

Publication number
WO2019206502A1
WO2019206502A1 PCT/EP2019/055564 EP2019055564W WO2019206502A1 WO 2019206502 A1 WO2019206502 A1 WO 2019206502A1 EP 2019055564 W EP2019055564 W EP 2019055564W WO 2019206502 A1 WO2019206502 A1 WO 2019206502A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
functions
applications
interface
operating system
Prior art date
Application number
PCT/EP2019/055564
Other languages
English (en)
French (fr)
Inventor
Carsten Gut
Original Assignee
Daimler Ag
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Daimler Ag filed Critical Daimler Ag
Priority to US17/049,704 priority Critical patent/US11926269B2/en
Priority to CN201980027493.9A priority patent/CN112004722B/zh
Publication of WO2019206502A1 publication Critical patent/WO2019206502A1/de

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/037—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for occupant comfort, e.g. for automatic adjustment of appliances according to personal settings, e.g. seats, mirrors, steering wheel
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
    • B60Q1/00—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor
    • B60Q1/02—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments
    • B60Q1/04—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
    • B60Q1/00—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor
    • B60Q1/02—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments
    • B60Q1/04—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights
    • B60Q1/06—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights adjustable, e.g. remotely-controlled from inside vehicle
    • B60Q1/08—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights adjustable, e.g. remotely-controlled from inside vehicle automatically
    • B60Q1/085—Arrangement of optical signalling or lighting devices, the mounting or supporting thereof or circuits therefor the devices being primarily intended to illuminate the way ahead or to illuminate other areas of way or environments the devices being headlights adjustable, e.g. remotely-controlled from inside vehicle automatically due to special conditions, e.g. adverse weather, type of road, badly illuminated road signs or potential dangers
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/0098—Details of control systems ensuring comfort, safety or stability not otherwise provided for
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
    • B60Q11/00—Arrangement of monitoring devices for devices provided for in groups B60Q1/00 - B60Q9/00
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60Q—ARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
    • B60Q2900/00—Features of lamps not covered by other groups in B60Q
    • B60Q2900/30—Lamps commanded by wireless transmissions
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0002—Automatic control, details of type of controller or control system architecture
    • B60W2050/0004—In digital systems, e.g. discrete-time systems involving sampling
    • B60W2050/0006—Digital architecture hierarchy
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0062—Adapting control system settings
    • B60W2050/0075—Automatic parameter input, automatic initialising or calibrating means
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2540/00—Input parameters relating to occupants
    • B60W2540/043—Identity of occupants
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle

Definitions

  • the invention relates to a vehicle operating system according to the closer defined in the preamble of claim 1. Art Furthermore, the invention relates to a method for operating a vehicle operating system according to the closer defined in the preamble of claim 5 Art.
  • Vehicle operating systems are basically known in the art. These vehicle operating systems generally have a function memory
  • Vehicle model so that customer requests are often fulfilled late or by another vehicle model.
  • comfort functions, functions for influencing a multimedia system and the like are so accessible only for the buyers of the latest generation of vehicles in their latest version.
  • DE 10 201 1 109 720 A1 describes a method and a system which comprises the user-dependent use of a vehicle via a communication device. It is the case that control data and control commands are transmitted to the vehicle via a communication device such as a smartphone in order to adapt vehicle functions to the wishes and needs of the user. This can thus individualize the vehicle by passing it over the communication device.
  • Communication device controls. If the user brings along this communication device, each vehicle used by him, for example as part of a car sharing, will adapt to his pre-programmed wishes.
  • the problem can be here This is because only certain functionalities, such as
  • the object of the present invention is therefore to provide a vehicle operating system and a method for operating such a vehicle operating system, which simply and efficiently supports the rapid development of functions while ensuring safe and reliable vehicle functionality.
  • sensor data determined with an interface and preferably fused are sent to a function or application in the
  • This interface can be realized as a defined open interface, in addition to the vehicle manufacturer and third party providers to enable the development and programming of functions and applications for the vehicle. As a result, a much faster development of new features and applications can be expected, which can then be distributed much faster than before to different vehicles and their users, so that the possibilities of Use increased and customization of each vehicle is possible. This ultimately improves customer satisfaction and tangible customer benefit.
  • a further-preferably open-interface-control commands generated by the function or application in the vehicle operating system are passed on to actuators of the vehicle, which thus control the corresponding functions. It is such that a memory is provided, in which vehicle side, by the
  • defined permissible value ranges are stored for the control commands, and that the interface for passing on the control commands only transmits them within the defined and stored value ranges.
  • the permissible value ranges can each be defined. Nevertheless, in order to guarantee the required safety by the vehicle manufacturer, which lies within his area of responsibility for the product, it is ensured via the memory for each conceivable control command which can be specified, for example, in a documentation of the open interface and with an admissible value range this permissible range of values, which may possibly also be influenced by parameters relating to the current state of the vehicle, is not exceeded.
  • Function storage is provided with a backend server.
  • Communication module such as a GSM module can be at least temporarily connect the vehicle or its operating system to a back-end server, in particular to achieve a back-end server of the vehicle manufacturer.
  • a GSM module can be at least temporarily connect the vehicle or its operating system to a back-end server, in particular to achieve a back-end server of the vehicle manufacturer.
  • Personalization memory may be provided, which is connected to the function memory and the communication module, and is stored in which functions or applications are available in the function memory of a person stored in the personalization memory person. This makes personalization possible.
  • the person identifies himself to the vehicle operating system, be it by specific values that can be detected by a sensor, such as weight, size, appearance, which can be optically detected or the like. It is also conceivable to use a corresponding vehicle key with personalized features for identification purposes or a mobile device, such as a smartphone or a
  • the vehicle operating system is then able to retrieve the corresponding data in the personalization memory, which functions and possibly which parameterization of the functions may be used by the respective person and whether corresponding personalized settings of
  • the vehicle operating system can then unlock the corresponding individual functions assigned to the respective person and thus enable an individually adapted vehicle.
  • This is particularly advantageous when different people use one and the same vehicle or especially when different people use different vehicles, for example in the context of car sharing, so for example when opening the vehicle via a personalized key, which in particular in a smartphone or a wearable can be integrated, immediately the corresponding functions assigned to that person are available.
  • a single person can license different functions they use in the vehicle
  • Vehicle operating system may include various functions, For example, navigation functions, autonomous vehicle functions, comfort functions such as the adjustment of seat, mirror, heater or the like., And
  • Multimedia functions via which, for example, volume, preferred radio stations, etc. can be preselected. Beside these are further functions for the
  • Vehicle operation conceivable, for example, user-adapted switching programs to drive with the vehicle depending on user preferences and wishes.
  • Vehicle operating system the functions now include in particular light functions. For this purpose, it is accordingly provided that the functions for outputting control commands to a headlight control are formed. In such
  • DE 10 2016 008 981 A1 may in particular be functions such as a partial high-beam light or the like, which can be realized correspondingly with high-resolution pixel headlamps.
  • such functionality which provides a great advantage to the customer, may be a major application aspect for such an open interface.
  • Different providers can develop and offer competing lighting concepts. Rapid development in this area guarantees a very fast implementation of new functions in vehicles with such open interfaces. In this way, based on the overall traffic, a higher level of security is possible because innovative lighting concepts very quickly available to many people and, for example, sophisticated functionalities in terms of a partial high beam, a cornering light and the like
  • the interfaces may again be available as open appropriately documented interfaces so as to enable development of functions and applications not only by the vehicle manufacturer but also by third parties in the positive sense described above.
  • the inventive method limits, comparable to the vehicle operating system according to the invention, on the vehicle side, the range of values of the control commands to a respective permissible value range, so as to prevent misuse or malfunction and to ensure the safety of the vehicle.
  • the method provides that the data interface provides data in accordance with predefined models of sensor fusions which are subject to the control of the vehicle manufacturer.
  • the sensor data are therefore in particular fused according to predetermined models, which can be adjusted accordingly and if necessary, changed, and made available in this way. For an open interface, this is documented accordingly.
  • predetermined models for the fusion of the sensor data, which in particular
  • Lighting functions are tailored, so from the environmental sensors of the
  • Vehicle detected data for example, need to drive ahead, subsequent and oncoming other road users.
  • Other features and applications that do not need this complex data can be data
  • a very advantageous development of the method according to the invention provides that the functions and applications are created by the vehicle manufacturer and / or by third-party providers. You can then have a backend server and a Communication module loaded in the vehicle operating system or its function memory and used accordingly. As a result, third-party vendors can use the open interfaces in the form of the data interface on the one hand and the
  • control interfaces develop and provide suitable functions.
  • the user can then load them via a backend server of the vehicle manufacturer in his operating system or the vehicle manufacturer can, for example, automatically load updates to existing functions in the operating system, if there is a connection to the back-end server via the communication module.
  • a very advantageous development of the method according to the invention also provides that the release of loaded functions or applications takes place on the basis of user data and / or as a function of vehicle-specific data.
  • Applications are thus adapted and released according to user data, for example from the above-mentioned personalization memory.
  • user data for example from the above-mentioned personalization memory.
  • a user in the same vehicle more functions for
  • Vehicle-specific data are therefore also taken into account during release. If the user has, for example, loaded autonomous driving functions and uses them regularly in his first vehicle, then it may be that his second vehicle, for example, does not have all the necessary sensors of surroundings detection, such as stereo cameras, lidar or the like, because the vehicle has the Vehicle is a smaller vehicle class or because this vehicle is older. The corresponding functions are then blocked as technically not executable, even if the user could in principle use them on the basis of a valid license.
  • An advantageous development of the method according to the invention provides that a payment function is integrated into the interface between the communication module and the back-end server.
  • a payment function is integrated into the interface between the communication module and the back-end server.
  • Such a payment function makes it extremely easy possible to obtain an update or to license or purchase additional features or applications licensed for use. Thanks to the integrated payment function, payment can be made when downloading the corresponding functions or
  • the functions may include vehicle-specific basic functions and in particular a user assigned, advanced functions or applications.
  • the basic functions for the vehicle are typically programmed by the vehicle manufacturer and provided with the vehicle, for example when it is delivered. Here further updates can also be made during the operating period of the vehicle.
  • the extended functions which are preferably no longer the vehicle, but now assigned to a user, are practically functions of an "optional equipment". These functions can be purchased by the user, for example, at the vehicle manufacturer or by any third party. This allows the user to customize the vehicle to his individual needs and, for example, benefit from faster development cycles by integrating third-party providers. For example, he can also upgrade an older vehicle, if it allows it technically and with regard to its sensor data, with newer functions or the like.
  • a further very advantageous embodiment of the idea also provides that vehicle data is anonymized via the
  • Communication module transferred to the back-end server and processed in the back-end server.
  • vehicle data can be collected in the back-end server and used, for example, for the further development of functionalities.
  • This data can then be provided via the back-end server and a suitable interface to third-party providers of functions, for example.
  • third-party providers of functions for example.
  • authorities for example, which can use them for statistical purposes and for the planning of transport projects.
  • Another application would be, for example, the provision of such data, preferably for a fee, to commercial companies, such as insurance or the like, which calculate on this basis with high statistical reliability type classes, regional classes or the like. And thus the possible adjusted insurance rates available to their customers can make.
  • Fig. 1 is a schematic representation of a vehicle, a vehicle operating system and necessary and useful for the inventive method
  • FIG. 2 shows a schematic representation of the situation when a user changes from a vehicle of the vehicle class I to a vehicle of the vehicle class II;
  • Fig. 3 is the reverse scenario for illustration in Fig. 2;
  • Fig. 4 schematic representation for testing the range of functions as a function of vehicle-specific data.
  • a schematically indicated vehicle 1 is shown with a vehicle operating system second part of this vehicle operating system 2 is a
  • Function memory 3 for storing functions or applications, which are identified here by way of example with A to F.
  • the function memory 3 is connected to an interface 4 as a data interface for the output of sensor data, which originate from a sensor function 5 in combination.
  • Another interface 6 is the output from control commands to a vehicle gateway 7, so that corresponding actuators of the vehicle implement the control commands of the functions or applications A to F accordingly.
  • Decisive here is a memory designated by 8 for the permissible value range of the control commands output via the interface 6.
  • Vehicle operating system 2 receives from this memory 8, the corresponding permissible value ranges. If these are not adhered to by the function A to F, they are limited to the permissible value range via the vehicle operating system 2, so that neither due to a programming error nor abusive the permissible value range can be exceeded.
  • a communication module 9 is available in the vehicle 1.
  • it can be used via the path designated by 10 to download new functions by communicating bidirectionally with a back-end server 11, preferably a back-end server of the vehicle manufacturer.
  • the operating system 2 can also provide via a designated 12 upload via the communication module 9 vehicle data for the back-end server available there
  • the backend server 1 1 has an interface designated by 13, via which such anonymized
  • vehicle data may be sold to commercial users or made available to authorities.
  • the back-end server 1 1 receives new functions, function modules, updates or via another interface designated with 14
  • Sensor function 5 is provided, which then provides the interface 4 via the interface also according to these new fusion models as an alternative or in addition to the previous fusion models.
  • Communication module 9 and the back-end server 1 1 can also be a schematically indicated payment function 27 integrate so as to download, for example, paid functions or applications A to F immediately and pay for it.
  • a personalization memory 16 is available which, on the one hand, is connected to the function memory 3 and, on the other hand, at least indirectly, for example via a user interface 17 to the vehicle operating system 2. About this personalization memory 16 different functionalities through the
  • Vehicle operating system 2 are queried, for example, which functions or applications A to F are assigned to a specific person and therefore, if this person uses the vehicle 1, to be unlocked.
  • Information about the licensing of individual functions A to F so as not to inadvertently provide them to persons who have not licensed or purchased them can also be stored in the personalization memory 16.
  • interface 4 is designed as a defined open interface, which offers the possibility of the functions and
  • Data interface 4 essentially the fused sensor data from the
  • Control commands to the vehicle gateway 7 and thus to the actuators of the vehicle this being defined in a by the vehicle manufacturer and by the
  • Vehicle operating system 2 and stored in the memory 8 ranges of values is monitored to the risk of misuse or accidental
  • the vehicle gateway 7 stands with a
  • Headlight control unit 28 in conjunction, which controls the indicated headlight 30 of the vehicle 1 accordingly.
  • the vehicle 1 is also connected to the backend server 1 1 accordingly, so quickly redeveloped functions A to F, such as light functions for controlling the headlight control unit 28, on the vehicle 1 and in its Function memory 3 can be loaded.
  • functions A to F such as light functions for controlling the headlight control unit 28, on the vehicle 1 and in its Function memory 3 can be loaded.
  • personalized settings can be correspondingly transferred via the backend server 1 1, in order to different vehicles To be able to individually adapt the same user or a vehicle to different users.
  • Personalization memory 16 the user interface 17 and further, even if this is not marked hatched, the operating system 2 of the vehicle. 1
  • the maintenance of the same is monitored via the vehicle operating system 2 in order to be able to reliably rule out malfunctions.
  • the use of the open interfaces 4, 6 allows the individual functions and applications A to F not necessarily to be developed exclusively by the vehicle manufacturer, but also that third-party providers can provide such functions A to F.
  • Applications A to F can be offered by the respective software specialists, for example for different vehicle users, not as contracted service providers, but as independent service companies. As a result, a very fast development cycle is possible and new functions and applications A to F can be made available very quickly to the user of the vehicle 1 as an end customer.
  • the back-end server 1 1 can then provide this data via the already mentioned defined interface 13 accordingly. This allows, for example, that anonymous data for statistical purposes to authorities or transport institutes can be issued, which then, for example, in the preferred application of lighting functionalities are able to evaluate how often and how long a glare-free high beam has been activated. This can also be used as a basis to make future improvements to the functions and applications A to F.
  • the access to the interface 13 can thereby by the
  • Vehicle manufacturers are controlled so that the data are made available, for example, for a corresponding fee to various extent different user groups.
  • new functions or applications A to F and possibly a request for new sensor fusion models are created and transmitted to the vehicle manufacturer.
  • Certain third-party companies certainly have different interests. Some companies are interested in providing the user of the vehicle with functions or applications A to F, for example, to sell or license, which control the functions in the vehicle. For example, providers of multimedia equipment installed in the vehicle may also provide corresponding applications or functions A through F that directly interfere with the system they provide
  • Vehicle interact.
  • Other companies are interested in providing improvements, such as enhanced high-beam functions, to provide the driver with additional compensation and allow him to travel more comfortably and safely at night.
  • other companies may also be primarily interested in the data of the vehicle 1.
  • an insurance company wants access to the speed data.
  • the user of the vehicle can accordingly install a function or application A to F of the insurance via the back-end server 11 and the communication module 9.
  • the insurance can then interrogate via the interface 13 between the function or application A to F and the backend 1 1 exchanged data again and can evaluate on this basis type classes, regional classes or the like statistically.
  • Approval of the vehicle owner can also be personal or vehicle-related data, such as speed profiles and the like are recorded to thereby influence the insurance premiums, which by the
  • Vehicle users are to pay to take. This can be particularly advantageous for a driver with a primarily defensive driving style, so that he can benefit from a cheaper insurance tariff.
  • a further aspect provides that, in particular, the functions A to F are subdivided into basic functions, for example A, B, C and extended functions or applications, for example D, E, F.
  • the basic functions are already included in the delivery of the vehicle 1.
  • the advanced features can be downloaded and, for example, unlocked or purchased through an appropriate license.
  • Vehicle finds its personal vehicle environment and always the same functions and applications A to F, as long as the vehicle is able to implement this.
  • a preferred application here may be fleet vehicles of companies or vehicles in car-sharing operation.
  • the vehicle 1 belongs to a first vehicle class I and the second vehicle 1 'to a second vehicle class
  • Vehicle class II In the field designated 18 is found in each case the
  • Vehicle class I has all three according to the box marked 19
  • Vehicle class II includes only the functions A and B, so only these functions can be used accordingly. In both cases, the extended functions and applications D, E, F have been downloaded via a subsequent download 20 in both vehicles 1, 1 '. The user of the vehicle 1 of Vehicle class I has now additionally licensed the function E, as indicated in the box designated 21. If he uses the vehicle 1, he is now the
  • Licensing is indicated in the figures 2 and 3 arrow, certain functions, in the example of Figures 2 and 3, for example, the functions D and F, are not available for this reason.
  • About the arrow 25 is queried whether the corresponding functionality in the user interface 17 and the
  • Personalization memory 16 is stored for the corresponding user. In the last arrow indicated by 26, it is then checked whether the available sensor data and thus in fact the quality of the available sensor data allow the corresponding function A to F to be used. Thus, for example, in the case of correspondingly bad weather conditions, certain functionalities can not be fully utilized, for example autonomous driving functions or other functionalities, which also depend on the environmental conditions, such as the weather or the like, with regard to the quality of the detected sensor data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Automation & Control Theory (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Transportation (AREA)
  • Human Computer Interaction (AREA)
  • Traffic Control Systems (AREA)
  • Lock And Its Accessories (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung betrifft ein Fahrzeugbetriebssystem (2) mit einem Funktionsspeicher (3) zum Speichern von Funktionen oder Anwendungen (A, B,..., F) mit einer Schnittstelle (4) zur Ausgabe von festgelegten Sensordaten an die Funktionen oder Anwendungen (A, B,..., F) und mit einer Schnittstelle (6) zur Weitergabe von durch die Funktionen oder Anwendungen (A, B,..., F) generierten Steuerbefehlen an Aktuatoren des Fahrzeugs (1). Erfindungsgemäß ist es vorgesehen, dass ein Speicher (8) vorgesehen ist, in welchem fahrzeugseitig festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, wobei die Schnittstelle (6) zur Weitergabe der Steuerbefehle die Steuerbefehle nur im Rahmen der in dem Speicher (8) hinterlegten Wertebereiche weitergibt.

Description

Fahrzeugbetriebssystem
Die Erfindung betrifft ein Fahrzeugbetriebssystem nach der im Oberbegriff von Anspruch 1 näher definierten Art. Außerdem betrifft die Erfindung ein Verfahren zum Betreiben eines Fahrzeugbetriebssystems nach der im Oberbegriff von Anspruch 5 näher definierten Art.
Fahrzeugbetriebssysteme und Verfahren zum Betreiben derartiger
Fahrzeugbetriebssysteme sind grundlegend aus dem Stand der Technik bekannt. Diese Fahrzeugbetriebssysteme weisen im Allgemeinen einen Funktionsspeicher zum
Speichern von Funktionen oder Anwendungen auf, welche ihrerseits entsprechende Funktionalitäten in dem Fahrzeug steuern. Dabei ist es so, dass diese Funktionen, welche häufig komfort- und/oder sicherheitsrelevante Aspekte des Fahrzeugs betreffen, alleine vom Fahrzeughersteller programmiert werden, um die geforderten Sicherheitsaspekte zuverlässig unter der Maßgabe des Fahrzeugherstellers einzuhalten. In der Praxis führt dies zu relativ starren Fahrzeugbetriebssystemen, deren Funktionen sich häufig nur sehr langsam verändern, beispielsweise mit der Markteinführung eines neuen
Fahrzeugmodells, sodass Kundenwünsche häufig erst spät oder durch ein anderes Fahrzeugmodell erfüllt werden. Insbesondere Komfortfunktionen, Funktionen zur Beeinflussung einer Multimediaanlage und dgl. sind so jeweils nur für die Käufer der neuesten Fahrzeuggeneration in ihrer neuesten Version zugänglich.
Die DE 10 201 1 109 720 A1 beschreibt ein Verfahren und ein System, welches die benutzerabhängige Nutzung eines Fahrzeugs über ein Kommunikationsgerät umfasst. Dabei ist es so, dass über ein Kommunikationsgerät wie beispielsweise ein Smartphone Steuerungsdaten und Steuerungsbefehle an das Fahrzeug übermittelt werden, um Fahrzeugfunktionen den Wünschen und den Bedürfnissen des Benutzers anzupassen. Dieser kann somit das Fahrzeug individualisieren, indem er es über das
Kommunikationsgerät steuert. Führt der Nutzer dieses Kommunikationsgerät mit, wird sich jedes von ihm genutzte Fahrzeug, beispielsweise im Rahmen eines Car-Sharings, entsprechend seiner vorprogrammierten Wünsche anpassen. Das Problem kann hier darin liegen, dass nur bestimmte Funktionalitäten, wie beispielsweise
Komforteinstellungen in dem Fahrzeug bezüglich einer Multimediaanlage, eines
Navigationsgeräts, Position von Sitzen und Spiegeln etc. über die Steuerung erfasst werden können. Für den eigentlichen Fährbetrieb und die Fahrsicherheit relevante Funktionalitäten können hier nicht freigegeben werden, da prinzipiell die Gefahr besteht, dass die Steuerungsbefehle missbräuchlich genutzt werden, was ein erhebliches
Sicherheitsrisiko darstellt.
Aus der DE 10 2016 008 981 A1 ist es ferner bekannt, dass die Einstellung der
Lichtverteilung eines Scheinwerfers mit einer Vielzahl von Lichtquellen, beispielsweise eines Pixelscheinwerfers, anhand von Nutzervorgaben erfolgt, wofür eine vergleichsweise aufwändige Sicherheitsabfrage mit einer Nutzerauthentifizierung realisiert wird, um der Gefahr eines Missbrauchs vorzugreifen.
Die Aufgabe der vorliegenden Erfindung besteht nun darin, ein Fahrzeugbetriebssystem sowie ein Verfahren zum Betreiben eines derartigen Fahrzeugbetriebssystems anzugeben, welches einfach und effizient die schnelle Weiterentwicklung von Funktionen unterstützt und dabei eine sichere und zuverlässige Fahrzeugfunktionalität gewährleistet.
Erfindungsgemäß wird diese Aufgabe durch ein Fahrzeugbetriebssystem mit den
Merkmalen im Anspruch 1 , und hier insbesondere im kennzeichnenden Teil des
Anspruchs 1 gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Unteransprüchen. Außerdem löst ein Verfahren mit den
Merkmalen im Anspruch 5, und auch hier insbesondere wieder im kennzeichnenden Teil des Anspruchs 5, die Aufgabe. Auch bezüglich des Verfahrens ergeben sich vorteilhafte Ausgestaltungen und Weiterbildungen aus den abhängigen Verfahrensansprüchen.
Über das Fahrzeugbetriebssystem werden mit einer Schnittstelle festgelegte und vorzugsweise fusionierte Sensordaten an eine Funktion oder Anwendung in dem
Funktionsspeicher ausgegeben. Diese Schnittstelle kann dabei als definierte offene Schnittstelle realisiert werden, um neben dem Fahrzeughersteller auch Drittanbietern die Entwicklung und Programmierung von Funktionen und Anwendungen für das Fahrzeug zu ermöglichen. Hierdurch ist eine sehr viel schnellere Entwicklung von neuen Funktionen und Anwendungen zu erwarten, welche sich dann sehr viel schneller als bisher an verschiedene Fahrzeuge und deren Nutzer verteilen lassen, sodass die Möglichkeiten der Nutzung erhöht und eine kundenspezifische Anpassung jedes Fahrzeugs möglich wird. Dies verbessert letztlich die Zufriedenheit des Kunden und den erlebbaren Kundennutzen.
Über eine weitere -vorzugsweise offene- Schnittstelle werden von der Funktion oder Anwendung generierte Steuerbefehle in dem Fahrzeugbetriebssystem an Aktuatoren des Fahrzeugs weitergegeben, welche so die entsprechenden Funktionen steuern. Dabei ist es so, dass ein Speicher vorgesehen ist, in welchem fahrzeugseitig, durch den
Fahrzeughersteller, festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, und dass die Schnittstelle zur Weitergabe der Steuerbefehle diese nur im Rahmen der festgelegten und gespeicherten Wertebereiche weitergibt. Ergänzend zur definierten offenen Schnittstelle können auch die zulässigen Wertebereiche jeder definiert werden. Um dennoch durch den Fahrzeughersteller die erforderliche Sicherheit zu gewährleisten, welche in seinem Verantwortungsbereich für das Produkt liegt, wird über den Speicher für jeden denkbaren Steuerbefehl, welcher beispielsweise in einer Dokumentation der offenen Schnittstelle beschrieben und mit einem zulässigen Wertebereich angegeben sein kann, sichergestellt, dass dieser zulässige Wertebereich, welcher gegebenenfalls auch durch Parameter bezüglich des aktuellen Zustands des Fahrzeugs beeinflusst werden kann, nicht überschritten wird. Sollte also die Anwendung oder Funktion einen unzulässigen Wertebereich für die Steuerbefehle nutzen wollen, sei es durch einen Programmierfehler oder um dem Fahrzeughersteller bzw. seinem Endkunden mutwillig zu schaden, dann wird dies durch das erfindungsgemäße Betriebssystem verhindert, indem die Wertebereiche für jeden der Steuerbefehle bei Bedarf auf den zulässigen
Wertebereich beschnitten werden. Damit können durch die Funktionen weder
versehentlich noch mutwillig sicherheitskritische Situationen durch fehlerhafte oder manipulierte Steuerbefehle ausgelöst werden.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Fahrzeugbetriebssystems sieht es dabei vor, dass ein Kommunikationsmodul zur Verbindung des
Funktionsspeichers mit einem Backend-Server vorgesehen ist. Über ein solches
Kommunikationsmodul, beispielsweise ein GSM- Modul lässt sich eine zumindest zeitweise Anbindung des Fahrzeugs bzw. seines Betriebssystems an einen Backend- Server, insbesondere einen Backend-Server des Fahrzeugherstellers erreichen. Über diesen Weg können beispielsweise von dem Fahrzeughersteller entsprechend
freigegebene Funktionen oder Anwendungen in den Funktionsspeicher des Betriebssystems heruntergeladen und durch den Nutzer des Fahrzeugs entsprechend genutzt werden.
Dabei kann gemäß einer vorteilhaften Weiterbildung der Idee ein
Personalisierungsspeicher vorgesehen sein, welcher mit dem Funktionsspeicher und dem Kommunikationsmodul verbunden ist, und in welchem gespeichert ist, welche Funktionen oder Anwendungen in dem Funktionsspeicher einer in dem Personalisierungsspeicher hinterlegten Person zur Verfügung stehen. Hierdurch ist eine Personalisierung möglich. Die Person gibt sich dem Fahrzeugbetriebssystem zu erkennen, sei es durch spezifische über einen Sensor erfassbare Werte, wie beispielsweise Gewicht, Größe, Aussehen, welches entsprechend optisch erfasst werden kann oder dgl. Ebenso ist es denkbar, zur Identifizierung einen entsprechenden Fahrzeugschlüssel mit personalisierten Merkmalen einzusetzen oder ein mobiles Gerät, wie beispielsweise ein Smartphone oder ein
Wearable derjenigen Person zu erkennen, welches zuvor in dem Fahrzeug bzw. dem Backend-Server registriert worden ist. Das Fahrzeugbetriebssystem ist dann in der Lage, im Personalisierungsspeicher die entsprechenden Daten abzurufen, welche Funktionen und gegebenenfalls welche Parametrisierung der Funktionen von der jeweiligen Person genutzt werden dürfen und ob entsprechende personalisierte Einstellungen von
Parametern der Funktionen vorliegen. Das Fahrzeugbetriebssystem kann dann den entsprechenden der jeweiligen Person zugeordneten individuellen Funktionsumfang freischalten und so ein individuell angepasstes Fahrzeug zu ermöglichen. Dies ist insbesondere dann von Vorteil, wenn verschiedene Personen ein und dasselbe Fahrzeug nutzen oder insbesondere auch, wenn verschiedene Personen verschiedene Fahrzeuge nutzen, beispielsweise im Rahmen eines Car-Sharings, sodass beispielsweise beim Öffnen des Fahrzeugs über einen personalisierten Schlüssel, welcher insbesondere in ein Smartphone oder ein Wearable integriert sein kann, sofort die entsprechenden dieser Person zugeordneten Funktionen zur Verfügung stehen. So kann eine einzelne Person beispielsweise verschiedene Funktionen lizenzieren, welche sie im Fahrzeug zur
Verfügung haben möchte. Dasselbe Fahrzeug kann dann einen gänzlich anderen Funktions- und Komfortumfang für die eine Person zur Verfügung stellen, wie für die andere Person, welche lieber sparsam ist und auf die Lizenzierung von zusätzlichen Komfortfunktionen lieber verzichten möchte.
Die Funktionen oder Anwendungen in dem Funktionsspeicher des
Fahrzeugbetriebssystems können dabei verschiedenartige Funktionen umfassen, beispielsweise Navigationsfunktionen, autonome Fahrzeugfunktionen, Komfortfunktionen wie beispielsweise das Einstellen von Sitz, Spiegel, Heizung oder dgl. sowie
Multimediafunktionen, über welche beispielsweise Lautstärke, bevorzugte Radiosender etc. vorgewählt werden können. Daneben sind weitere Funktionen für den
Fahrzeugbetrieb denkbar, beispielsweise nutzeradaptierte Schaltprogramme, um mit dem Fahrzeug je nach Nutzervorgaben und Wünschen zu fahren.
Gemäß einer besonders günstigen Ausgestaltung des erfindungsgemäßen
Fahrzeugbetriebssystems können die Funktionen nun insbesondere Lichtfunktionen umfassen. Dazu ist es entsprechend vorgesehen, dass die Funktionen zur Ausgabe von Steuerbefehlen an eine Scheinwerfersteuerung ausgebildet sind. Bei derartigen
Lichtfunktionen, wie sie beispielsweise in der eingangs genannten
DE 10 2016 008 981 A1 erwähnt sind, kann es sich insbesondere um Funktionen wie ein Teilfernlicht oder dgl. handeln, welches mit hochauflösenden Pixelscheinwerfern entsprechend realisiert werden kann. Vor allem eine derartige Funktionalität, welche einen großen Vorteil für den Kunden ermöglicht, kann ein Hauptanwendungsaspekt für eine derartige offene Schnittstelle sein. Verschiedene Anbieter können hier konkurrierend Beleuchtungskonzepte entwickeln und anbieten. Eine schnelle Entwicklung in diesem Gebiet garantiert eine sehr schnelle Umsetzung von neuen Funktionen in Fahrzeugen mit derartigen offenen Schnittstellen. Hierdurch ist, bezogen auf den Gesamtverkehr, eine höhere Sicherheit möglich, da innovative Beleuchtungskonzepte sehr schnell sehr vielen Personen zur Verfügung stehen und beispielsweise ausgefeilte Funktionalitäten hinsichtlich eines Teilfernlichts, eines Kurvenlichts und dgl. nachweislich zu einer
Erhöhung der Fahrsicherheit im Verkehr führen. Einerseits weiter gesehen und andererseits wird dennoch die Gefahr einer Blendung des Gegenverkehrs entsprechend reduziert. Diese Art der Funktionen bietet sich deshalb als bevorzugte Anwendung an. Sie bietet darüber hinaus ein Anwendungsfeld, in welchem die Gefahr eines Missbrauchs relativ klein ist, da von einem potenziellen Missbrauch keine unmittelbare Gefahr für den Nutzer des Fahrzeugs ausgeht und da ein solcher für den Nutzer des Fahrzeugs eher leicht zu erkennen ist.
Neben einer Individualisierung von Komforteinstellungen und dgl. stellt diese Anwendung also eine besonders günstige und effiziente Nutzung für das erfindungsgemäße
Betriebssystem dar. Das erfindungsgemäße Verfahren zum Betreiben eines Fahrzeugbetriebssystems kann nun insbesondere mit einem Betriebssystem im oben beschriebenen Sinne
Zusammenwirken, ist jedoch nicht zwingend auf ein solches angewiesen. Bei dem erfindungsgemäßen Verfahren ist es vorgesehen, dass Funktionen oder Anwendungen in das Fahrzeugbetriebssystem geladen werden, welche auf Basis von Daten einer
Datenschnittstelle Steuerungsfunktionen in dem Fahrzeug ausführen, indem sie
Steuerbefehle an eine Fahrzeugschnittstelle senden. Auch hier können die Schnittstellen wieder, wie oben bereits erwähnt, als offene entsprechend dokumentierte Schnittstellen verfügbar sein, um so eine Entwicklung von Funktionen und Anwendungen nicht nur durch den Fahrzeughersteller, sondern in dem oben beschriebenen positiven Sinn auch durch Dritte zu ermöglichen. Das erfindungsgemäße Verfahren begrenzt, vergleichbar wie das Fahrzeugbetriebssystem gemäß der Erfindung, fahrzeugseitig den Wertebereich der Steuerbefehle auf einen jeweils zulässigen Wertebereich, um so einem Missbrauch oder einer Fehlfunktion vorzubeugen und die Sicherheit des Fahrzeugs gewährleisten zu können.
Das Verfahren sieht es dabei gemäß einer vorteilhaften Weiterbildung vor, dass die Datenschnittstelle Daten gemäß vorgegebener Modelle von Sensorfusionen bereitstellt, welche der Kontrolle des Fahrzeugherstellers unterliegen. Die Sensordaten werden also insbesondere nach vorgegebenen Modellen, welche sich entsprechend anpassen und bei Bedarf verändern lassen, fusioniert und in dieser Art zur Verfügung gestellt. Bei einer offenen Schnittstelle ist dies entsprechend dokumentiert. Dabei kann es beispielsweise Fusionsmodelle für die Fusion der Sensordaten geben, welche insbesondere auf
Beleuchtungsfunktionen zugeschnitten sind, also von den Umfeldsensoren des
Fahrzeugs erfasste Daten beispielsweise über vorausfahrende, nachfolgende und entgegenkommende weitere Verkehrsteilnehmer benötigen. Andere Funktionen und Anwendungen, welche diese komplexen Daten nicht benötigen, können Daten
alternativer Modelle der Sensorfusion entsprechend abfragen, um so beispielsweise Einstellungen hinsichtlich der gewünschten Temperatur einer Heiz- oder Klimaanlage, der aktuell eingestellten Lautstärke eines Multimediageräts oder dgl. zur Verfügung zu stellen.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es dabei vor, dass die Funktionen und Anwendungen vom Fahrzeughersteller und/oder von Drittanbietern erstellt werden. Sie können dann über einen Backend-Server und ein Kommunikationsmodul in das Fahrzeugbetriebssystem bzw. seinen Funktionsspeicher geladen und entsprechend genutzt werden. Dadurch können Drittanbieter über die offenen Schnittstellen in Form der Datenschnittstelle einerseits und der
Steuerschnittstelle andererseits geeignete Funktionen entwickeln und zur Verfügung stellen. Der Nutzer kann diese dann über einen Backend-Server des Fahrzeugherstellers in sein Betriebssystem laden oder der Fahrzeughersteller kann beispielsweise Updates zu bestehenden Funktionen automatisiert in das Betriebssystem laden, wenn über das Kommunikationsmodul eine Verbindung zum Backend-Server besteht.
Eine sehr vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es ferner vor, dass die Freigabe von geladenen Funktionen oder Anwendungen anhand von Nutzerdaten und/oder in Abhängigkeit von fahrzeugspezifischen Daten erfolgt. Die in dem Funktionsspeicher des Fahrzeugbetriebssystems vorhandenen Funktionen und
Anwendungen werden also entsprechend von Benutzerdaten, beispielsweise aus dem oben bereits genannten Personalisierungsspeicher angepasst und freigegeben. So kann beispielsweise ein Nutzer in ein und demselben Fahrzeug mehr Funktionen zur
Verfügung haben, da er mehr Funktionen lizenziert hat, als beispielsweise ein anderer Nutzer, welcher in demselben Fahrzeug weniger Funktionsumfang nutzen kann. Darüber hinaus können bestimmte Funktionen nur in eingeschränktem Rahmen oder
gegebenenfalls gar nicht von bestimmten Fahrzeugen ausgeführt werden. Nutzt ein Nutzer beispielsweise verschiedene Fahrzeuge und hat sich verschiedene Funktionen lizenziert, so kann es nun sein, dass nicht alle Funktionen in allen Fahrzeugen
funktionieren. Fahrzeugspezifische Daten werden deshalb bei der Freigabe ebenfalls berücksichtigt. Hat der Nutzer beispielsweise autonome Fahrfunktionen geladen und nutzt diese in seinem ersten Fahrzeug regelmäßig, dann kann es sein, dass sein zweites Fahrzeug beispielsweise nicht alle notwendigen Sensoren der Umfelderfassung, wie beispielsweise Stereokameras, Lidar oder dgl. zur Verfügung hat, da das Fahrzeug beispielsweise das Fahrzeug einer kleineren Fahrzeugklasse ist oder da dieses Fahrzeug schon älter ist. Die entsprechenden Funktionen werden dann als technisch nicht ausführbar blockiert, auch wenn der Nutzer diese prinzipiell aufgrund einer gültigen Lizenz nutzen könnte.
Eine vorteilhafte Weiterbildung des erfindungsgemäßen Verfahrens sieht es vor, dass in die Schnittstelle zwischen dem Kommunikationsmodul und dem Backend-Server eine Bezahlfunktion integriert ist. Eine solche Bezahlfunktion macht es außerordentlich einfach möglich, ein Update zu beziehen oder lizenzpflichtige zusätzliche Funktionen oder Anwendungen zu lizenzieren oder zu kaufen. Durch die integrierte Bezahlfunktion lässt sich die Bezahlung beim Herunterladen der entsprechenden Funktionen oder
Anwendungen in das Fahrzeug mit abwickeln, sodass ein außerordentlich einfaches und effizient zu nutzendes System entsteht.
Dabei können die Funktionen fahrzeugspezifische Basisfunktionen umfassen und insbesondere einem Nutzer zugeordnete, erweiterte Funktionen oder Anwendungen. Die Basisfunktionen für das Fahrzeug werden typischerweise vom Fahrzeughersteller entsprechend programmiert und mit dem Fahrzeug bereitgestellt, beispielsweise bei dessen Auslieferung. Hier können weitere Updates auch während der Betriebsdauer des Fahrzeugs erfolgen. Die erweiterten Funktionen, welche bevorzugt eben nicht mehr dem Fahrzeug, sondern nun einem Nutzer zugeordnet werden, sind praktisch Funktionen einer "Sonderausstattung". Diese Funktionen können von dem Nutzer entsprechend erworben werden, beispielsweise beim Fahrzeughersteller oder auch von beliebigen Drittanbietern. Über diese kann der Nutzer das Fahrzeug seinen individuellen Bedürfnissen anpassen und kann beispielsweise von schnelleren Entwicklungszyklen durch das Einbinden von Drittanbietern profitieren. Er kann so beispielsweise auch ein älteres Fahrzeug, sofern dieses es technisch und bezüglich seiner Sensordaten zulässt, mit neueren Funktionen aufwerten oder Ähnliches.
Diese erweiterten Funktionen oder Anwendungen können nun in Abhängigkeit des jeweiligen Nutzers des Fahrzeugs über das Kommunikationsmodul in das Fahrzeug geladen werden. Eine solche dem Nutzer erfolgte Zuordnung der Funktionen ermöglicht, wie es oben bereits erwähnt worden ist, dass der Nutzer mit den von ihm genutzten und insbesondere gekauften oder lizenzierten Funktionen verschiedene Fahrzeuge nutzen kann und das Funktions- und Anwendungsumfeld immer in der gleichen Art und Weise vorfindet. Insbesondere bei der Nutzung von Fahrzeugen durch verschiedene Personen, beispielsweise im Rahmen eines Car-Sharings oder auch bei der Nutzung einer Flotte von Firmenfahrzeugen kann dies ein ganz entscheidender Vorteil sein, da jeder Nutzer sein ihm bekanntes Umfeld in jedem Fahrzeug vorfindet, egal, wer das Fahrzeug zuvor gefahren hat, und, sofern sich hier keine Beschränkungen durch die verfügbaren
Sensoren in dem Fahrzeug ergeben, auch unabhängig vom Typ des Fahrzeugs selbst. Eine weitere sehr vorteilhafte Ausgestaltung der Idee sieht es dabei ferner vor, dass Fahrzeugdaten in Abhängigkeit einer Nutzerzustimmung anonymisiert über das
Kommunikationsmodul an den Backend-Server übertragen und in dem Backend-Server verarbeitet werden. Hierdurch lassen sich Fahrzeugdaten in dem Backend-Server sammeln und beispielsweise für die Weiterentwicklung von Funktionalitäten nutzen. Diese Daten können dann über den Backend-Server und eine geeignete Schnittstelle auch Drittanbietern beispielsweise von Funktionen zur Verfügung gestellt werden. Auch das Zur- Verfügung-Stellen derartiger Daten beispielsweise an Behörden, welche diese zu statistischen Zwecken und zur Planung von Verkehrsprojekten nutzen können, ist denkbar. Ein weiterer Anwendungsfall wäre beispielsweise die Bereitstellung derartiger Daten, vorzugsweise gegen Entgelt, an kommerzielle Unternehmen, wie beispielsweise Versicherungen oder dgl., welche auf dieser Basis mit hoher statistischer Zuverlässigkeit Typklassen, Regionalklassen oder dgl. berechnen und die damit möglichen angepassten Versicherungstarife ihren Kunden zur Verfügung stellen können.
Weitere vorteilhafte Ausgestaltungen des Fahrzeugbetriebssystems sowie des
Verfahrens ergeben sich ferner aus dem Ausführungsbeispiel, welches nachfolgend unter Bezugnahme auf die Figur näher beschrieben ist.
Dabei zeigen:
Fig. 1 schematische Darstellung eines Fahrzeugs, eines Fahrzeugbetriebssystems und der für das erfindungsgemäße Verfahren notwendigen und sinnvollen
Schnittstellen;
Fig. 2 schematische Darstellung der Situation, wenn ein Nutzer von einem Fahrzeug der Fahrzeugklasse I zu einem Fahrzeug der Fahrzeugklasse II wechselt;
Fig. 3 das umgekehrte Szenario zur Darstellung in Fig. 2; und
Fig. 4 schematische Darstellung zur Prüfung des Funktionsumfangs in Abhängigkeit von fahrzeugspezifischen Daten.
In der Darstellung der Fig. 1 ist ein schematisch angedeutetes Fahrzeug 1 dargestellt, mit einem Fahrzeugbetriebssystem 2. Teil dieses Fahrzeugbetriebssystems 2 ist ein
Funktionsspeicher 3 zum Speichern von Funktionen oder Anwendungen, welche hier beispielhaft mit A bis F gekennzeichnet sind. Der Funktionsspeicher 3 steht mit einer Schnittstelle 4 als Datenschnittstelle für die Ausgabe von Sensordaten, welche aus einer Sensorfunktion 5 stammen, in Verbindung. Eine weitere Schnittstelle 6 dient der Ausgabe von Steuerbefehlen an ein Fahrzeug-Gateway 7, sodass entsprechende Aktuatoren des Fahrzeugs die Steuerbefehle der Funktionen oder Anwendungen A bis F entsprechend umsetzen. Entscheidend ist dabei ein mit 8 bezeichneter Speicher für den zulässigen Wertebereich der über die Schnittstelle 6 ausgegebenen Steuerbefehle. Das
Fahrzeugbetriebssystem 2 erhält aus diesem Speicher 8 die entsprechenden zulässigen Wertebereiche. Sollten diese von der Funktion A bis F nicht eingehalten werden, so werden sie über das Fahrzeugbetriebssystem 2 auf den zulässigen Wertebereich begrenzt, sodass weder aufgrund eines Programmierungsfehlers noch missbräuchlich der zulässige Wertebereich überschritten werden kann.
Ein Kommunikationsmodul 9 steht in dem Fahrzeug 1 zur Verfügung. Es kann insbesondere über den mit 10 bezeichneten Weg zum Download neuer Funktionen eingesetzt werden, indem es bidirektional mit einem Backend-Server 1 1 , vorzugsweise einem Backend-Server des Fahrzeugherstellers kommuniziert. Das Betriebssystem 2 kann außerdem über einen mit 12 bezeichneten Upload über das Kommunikationsmodul 9 Fahrzeugdaten für den Backend-Server zur Verfügung stellen, welche dort
beispielsweise zur Weiterentwicklung von Funktionen oder Anwendungen A bis F, für Zwecke der Statistik oder dgl. Anwendung finden können. Der Backend-Server 1 1 hat dazu eine mit 13 bezeichnete Schnittstelle, über welche derartige anonymisierte
Fahrzeugdaten beispielsweise an kommerzielle Anwender verkauft oder Behörden zur Verfügung gestellt werden können. Über eine weitere mit 14 bezeichnete Schnittstelle erhält der Backend-Server 1 1 neue Funktionen, Funktionsmodule, Updates oder
Anwendungen A bis F, welche über den Backend-Server und das Kommunikationsmodul 9 als Download 10 in den Funktionsspeicher 3 des Betriebssystems 2 geladen werden können. Bei Bedarf können über den Backend-Server 1 1 auch neue Fusionsmodelle initiiert werden. Über das Kommunikationsmodul 9 können diese zu dem Fahrzeug heruntergeladen werden und werden über den mit 15 bezeichneten Weg der
Sensorfunktion 5 zur Verfügung gestellt, welche über die Schnittstelle 4 dann die Daten auch gemäß dieser neuen Fusionsmodelle alternativ oder ergänzend zu den bisherigen Fusionsmodellen zur Verfügung stellt. In die Datenschnittstelle zwischen dem
Kommunikationsmodul 9 und dem Backend-Server 1 1 lässt sich dabei außerdem eine schematisch angedeutete Bezahlfunktion 27 integrieren, um so beispielsweise kostenpflichtige Funktionen oder Anwendungen A bis F unmittelbar herunterladen und dabei bezahlen zu können. Ergänzend steht ein Personalisierungsspeicher 16 zur Verfügung, welcher einerseits mit dem Funktionsspeicher 3 und andererseits zumindest mittelbar, beispielsweise über ein User- Interface 17 mit dem Fahrzeugbetriebssystem 2 verbunden ist. Über diesen Personalisierungsspeicher 16 können verschiedene Funktionalitäten durch das
Fahrzeugbetriebssystem 2 abgefragt werden, beispielsweise welche Funktionen oder Anwendungen A bis F einer bestimmten Person zugeordnet sind und deshalb, wenn diese Person das Fahrzeug 1 nutzt, freigeschaltet werden sollen. Auch Informationen über die Lizenzierung einzelner Funktionen A bis F, um diese nicht versehentlich Personen bereitzustellen, welche diese nicht lizenziert oder gekauft haben, können in dem Personalisierungsspeicher 16 entsprechend hinterlegt sein.
Ein wesentlicher Bestandteil ist es nun, dass die Schnittstelle 4 als definierte offene Schnittstelle konzipiert ist, wodurch die Möglichkeit besteht, die Funktionen und
Anwendungen A bis F zu partitionieren. Die offene Schnittstelle stellt als
Datenschnittstelle 4 im Wesentlichen die fusionierten Sensordaten aus der
Sensorfunktion 5 bereit. Über die Schnittstelle 6 erfolgt dann die Ausgabe der
Steuerbefehle an das Fahrzeug-Gateway 7 und damit an die Aktuatoren des Fahrzeugs, wobei dies in einem vom Fahrzeughersteller definierten und durch das
Fahrzeugbetriebssystem 2 und die in dem Speicher 8 hinterlegten Wertebereiche überwacht wird, um die Gefahr eines Missbrauchs oder einer versehentlichen
Fehlprogrammierung auszuschließen. Die eingangs bereits genannte bevorzugte Anwendung von zumindest einer der Funktionen A bis F zur Steuerung eines
Scheinwerfers 30, insbesondere eines hochauflösenden Pixelscheinwerfers zum
Erzeugen einer individuell angepassten Lichtverteilung ist dabei in der Darstellung der Fig. 1 ebenso angedeutet. Das Fahrzeug-Gateway 7 steht dazu mit einem
Scheinwerfersteuergerät 28 in Verbindung, welches den angedeuteten Scheinwerfer 30 des Fahrzeugs 1 entsprechend ansteuert.
Über das Kommunikationsmodul 9, beispielsweise ein GSM-Modul wird das Fahrzeug 1 außerdem an den Backend-Server 1 1 entsprechend angebunden, sodass schnell neu entwickelte Funktionen A bis F, beispielsweise Lichtfunktionen zur Steuerung des Scheinwerfersteuergeräts 28, auf das Fahrzeug 1 bzw. in dessen Funktionsspeicher 3 geladen werden können. Zusätzlich können personalisierte Einstellungen über den Backend-Server 1 1 entsprechend transferiert werden, um so verschiedene Fahrzeuge an denselben Nutzer oder ein Fahrzeug an verschiedene Nutzer jeweils individuell anpassen zu können.
Die schraffierten Blöcke in der Darstellung der Fig. 1 unterliegen dabei dem
Verantwortungsbereich des Fahrzeugherstellers. Dieser hat also die Verantwortung über beispielsweise das Kommunikationsmodul 9, die Sensorfusion 5, den Backend-Server 1 1 und insbesondere über den Speicher 8 und das Fahrzeug-Gateway 7, den
Personalisierungsspeicher 16 das Userinterface 17 sowie ferner, auch wenn dieses nicht schraffiert markiert ist, das Betriebssystem 2 des Fahrzeugs 1 .
Die Qualität der angebotenen Funktionen und Anwendungen A bis F hängt dabei maßgeblich von der Qualität der Sensorfusion 5 ab. Dieser Block wird deshalb auch weiterhin vom Fahrzeughersteller erarbeitet und im Rahmen einer Dokumentation der offenen Schnittstellen 4, 6 zur Verfügung gestellt. Wie bereits erwähnt, wird in dem Speicher 8 dabei ein fest definierter Wertebereich für jeden denkbaren Steuerbefehl, welcher auch Teil der Dokumentation der offenen Schnittstellen 4 und 6 ist, hinterlegt.
Das Einhalten desselben wird über das Fahrzeugbetriebssystem 2 überwacht, um Fehlfunktionen sicher ausschließen zu können. Ansonsten erlaubt die Verwendung der offenen Schnittstellen 4, 6, dass die einzelnen Funktionen und Anwendungen A bis F nicht zwingend ausschließlich vom Fahrzeughersteller entwickelt werden müssen, sondern dass auch Drittanbieter derartige Funktionen A bis F zur Verfügung stellen können. Dies hat den Vorteil, dass neue Funktionen und Anwendungen A bis F beispielsweise durch Zulieferfirmen, durch Tochterunternehmen oder spezialisierte Softwareunternehmen bereitgestellt werden können. Diese müssen dabei nicht zwingend aus dem Automotive-Bereich kommen, da die Sensordaten ja bereits fusioniert aus der Sensorfusion 5 in vordefinierter Art an der Schnittstelle 4 vorliegen. Somit wird ein sehr hohes Maß an Flexibilität geschaffen. Neue auch sehr komplexe Funktionen und
Anwendungen A bis F lassen sich dabei durch die jeweiligen Softwarespezialisten, beispielsweise für verschiedene Fahrzeuganwender, nicht als vertraglich verpflichtete Dienstleister, sondern als eigenständige Serviceunternehmen, anbieten. Hierdurch ist ein sehr schneller Entwicklungszyklus möglich und neue Funktionen und Anwendungen A bis F lassen sich dem Nutzer des Fahrzeugs 1 als Endkunden sehr schnell zur Verfügung stellen. Durch die offenen Schnittstellen 4,6 lassen sich dabei durch die Funktionen oder Anwendungen A bis F auch Informationen über den Upload 12 zu dem Backend-Server 1 1 hochladen. Der Backend-Server 1 1 kann dann über die bereits angesprochene definierte Schnittstelle 13 diese Daten entsprechend zur Verfügung stellen. Dies ermöglicht beispielsweise, dass anonymisierte Daten für Statistikzwecke an Behörden oder Verkehrsinstitute herausgegeben werden können, welche dann beispielsweise bei der bevorzugten Anwendung von Lichtfunktionalitäten in der Lage sind auszuwerten, wie oft und wie lange ein blendfreies Fernlicht aktiviert wurde. Dies kann auch als Basis genutzt werden, um zukünftige Verbesserungen der Funktionen und Anwendungen A bis F vorzunehmen. Der Zugang zu der Schnittstelle 13 kann dabei durch den
Fahrzeughersteller kontrolliert werden, sodass die Daten beispielsweise gegen entsprechendes Entgelt in verschiedenem Umfang verschiedenen Nutzergruppen verfügbar gemacht werden.
Ferner ist es auch möglich, dass neue Funktionen oder Anwendungen A bis F und gegebenenfalls eine Anfrage hinsichtlich neuer Sensorfusionsmodelle erstellt und an den Fahrzeughersteller übermittelt werden. Verschiedene Drittunternehmen haben dabei sicherlich unterschiedliches Interesse. Einige Unternehmen sind daran interessiert, dem Nutzer des Fahrzeugs Funktionen oder Anwendungen A bis F zur Verfügung zu stellen, beispielsweise zu verkaufen oder zu lizenzieren, welche die Funktionen in dem Fahrzeug steuern. Beispielsweise können Anbieter von Multimedia-Equipment, welches in dem Fahrzeug installiert ist, auch entsprechende Anwendungen oder Funktionen A bis F zur Verfügung stellen, welche unmittelbar mit dem von ihnen gelieferten System des
Fahrzeugs interagieren. Andere Unternehmen sind daran interessiert, Verbesserungen zur Verfügung zu stellen, beispielsweise verbesserte Fernlichtfunktionen, um dem Fahrer gegen Entgelt diese zur Verfügung zu stellen und ihm ein komfortableres und sichereres Fahren bei Nacht zu ermöglichen. Wieder andere Unternehmen können beispielsweise auch primär an den Daten des Fahrzeugs 1 interessiert sein. Eine Versicherung möchte beispielsweise Zugang zu den Geschwindigkeitsdaten haben. Der Nutzer des Fahrzeugs kann hierzu eine Funktion bzw. Anwendung A bis F der Versicherung über den Backend- Server 1 1 und das Kommunikationsmodul 9 entsprechend installieren. Die Versicherung kann dann über die Schnittstelle 13 zwischen der Funktion oder Anwendung A bis F und dem Backend 1 1 ausgetauschte Daten wiederum abfragen und kann auf dieser Basis Typklassen, Regionalklassen oder dgl. statistisch bewerten. Mit entsprechender
Zustimmung des Fahrzeuginhabers können beispielsweise auch personenbezogene oder fahrzeugbezogene Daten, wie beispielsweise Geschwindigkeitsprofile und dgl. erfasst werden, um hiermit Einfluss auf die Versicherungsprämien, welche durch den
Fahrzeugnutzer zu zahlen sind, zu nehmen. Dies kann insbesondere bei einem Fahrer mit primär defensiver Fahrweise von Vorteil sein, sodass dieser von einem günstigeren Versicherungstarif profitieren kann.
Ein weiterer Aspekt sieht es dabei vor, dass insbesondere die Funktionen A bis F in Basisfunktionen, beispielsweise A, B, C und erweiterte Funktionen oder Anwendungen, beispielsweise D, E, F unterteilt sind. Die Basisfunktionen sind dabei bei der Auslieferung des Fahrzeugs 1 bereits inkludiert. Die erweiterten Funktionen können heruntergeladen und beispielsweise durch eine entsprechende Lizenz freigeschaltet oder käuflich erworben werden.
Über die Anbindung des Fahrzeugs 1 über das Kommunikationsmodul 9 an dem
Backend-Server 1 1 und insbesondere über die Möglichkeit der Personalisierung, wozu letztlich der Personalisierungsspeicher 16 Verwendung finden kann, ist es dabei möglich, dass die Funktionen und Anwendungen A bis F einem Nutzer zugeordnet werden. Dies bedeutet, dass er diese Funktionen und Anwendungen A bis F nicht nur in einem, sondern in verschiedenen Fahrzeugen nutzen kann, sodass er faktisch in jedem
Fahrzeug seine persönliche Fahrzeugumgebung und immer dieselben Funktionen und Anwendungen A bis F vorfindet, solange das Fahrzeug in der Lage ist, diese umzusetzen. Eine bevorzugte Anwendung können hier Flottenfahrzeuge von Firmen oder Fahrzeuge im Car-Sharing-Betrieb sein.
In der Darstellung der Fig. 2 sind zwei Fahrzeuge 1 und 1 ' angedeutet. Das Fahrzeug 1 gehört einer ersten Fahrzeugklasse I und das zweite Fahrzeug 1 ' einer zweiten
Fahrzeugklasse II an. In dem mit 18 bezeichneten Feld findet sich jeweils die
Grundausstattung an Basisfunktionen A, B, C, welche in den Funktionsspeicher 3 geladen sind, wenn das Fahrzeug ausgeliefert wird. Das Fahrzeug 1 in der
Fahrzeugklasse I hat dabei entsprechend der mit 19 bezeichneten Box alle drei
Funktionen A, B, C freigeschaltet. Die Freischaltung 19 beim Fahrzeug 1 ' der
Fahrzeugklasse II beinhaltet nur die Funktionen A und B, sodass nur diese Funktionen entsprechend genutzt werden können. In beiden Fällen ist es so, dass über einen nachträglichen Download 20 in beiden Fahrzeugen 1 , 1 ' die erweiterten Funktionen und Anwendungen D, E, F heruntergeladen worden sind. Der Nutzer des Fahrzeugs 1 der Fahrzeugklasse I hat sich nun die Funktion E zusätzlich lizenziert, wie es in der mit 21 bezeichneten Box angedeutet ist. Nutzt er das Fahrzeug 1 , stehen ihm nun die
Funktionen A, B, C und E zur Verfügung. Dies ist in der mit 22 bezeichneten Box entsprechend angedeutet. Wechselt ein Nutzer des Fahrzeugs 1 der Fahrzeugklasse I nun, wie es durch den Pfeil 23 symbolisiert ist, das Fahrzeug und nutzt nun das Fahrzeug 1 ' der Fahrzeugklasse II, dann liegen in diesem Fahrzeug dieselben Funktionen in der Grundausstattung 18 und im Download 20 zur Verfügung. Er kann also in der Box 22 über dieselben Funktionen A, B zusätzlich dazu die Basisfunktion C, welche in dem Fahrzeug der Typklasse II typischerweise nicht zur Verfügung steht, sowie über die von ihm lizenzierte Funktion E verfügen. Der Nutzer hat damit unabhängig vom Fahrzeug, sofern das Fahrzeug technisch in der Lage ist, die jeweiligen Funktionen umzusetzen, "seine" Funktionen A, B, C und E zur Verfügung.
In der Darstellung der Fig. 3 ist das umgekehrte Szenario dargestellt. Diesmal betrachten wir den Fahrer oder Nutzer des Fahrzeugs 1 ' der Fahrzeugtypklasse II. Dieser hat ebenfalls die Funktion E zusätzlich lizenziert, ansonsten ist das Szenario dasselbe wie in der Darstellung der Fig. 3. Bei dem Fahrzeug T der Typklasse II stehen dabei nur die Basisfunktionen A und B zur Verfügung. Außerdem hat der Nutzer die von ihm lizenzierte Funktion E zur Verfügung. Wechselt er nun in ein Fahrzeug der Fahrzeugklasse I, würden prinzipiell mehr Basisfunktionen zur Verfügung stehen, wie es in der Box 19 entsprechend angedeutet ist. Da er aber als registrierter Nutzer der Fahrzeugklasse II das Fahrzeug 1 der Fahrzeugklasse I nutzt, stehen für ihn nur die Funktionen A, B und E zur Verfügung, wie er dies von seinem Fahrzeug entsprechend gewohnt ist.
Ob eine Funktion oder Anwendung A bis F für den Nutzer eines Fahrzeugs 1 , 1 ' also tatsächlich verfügbar und freigegeben ist, hängt nicht, wie bisher, von dem Fahrzeug 1 , 1 ' ab, sondern von dem Nutzer selbst. Ob nun alle von dem Nutzer gewünschten und ihm zustehenden Funktionalitäten tatsächlich auch genutzt werden können, hängt jedoch auch von weiteren Parametern ab, welche im Sinne der hier vorliegenden Anmeldung unter dem Begriff fahrzeugspezifische Parameter zusammengefasst sind.
In Fig. 4 zeigt die obere mit 19, 20 bezeichnete Box alle prinzipiell verfügbaren
Funktionen und Anwendungen A bis F, welche entsprechend in dem Fahrzeug vorhanden sind oder heruntergeladen worden sind, analog zu den Szenarien in den Figuren 2 und 3. .Ein Nutzer könnte also über alle Funktionen A bis F verfügen. Ob er dies nun tatsächlich kann oder nicht, hängt neben seinen Lizenzen auch von den fahrzeugspezifischen Bedingungen ab. In einem ersten mit 29 bezeichneten Pfeil wird überprüft, ob die Hardware des Fahrzeugs 1 , 1 ' in der Lage ist, die Funktionen alle darzustellen. Der mit 24 bezeichnete Pfeil prüft eine entsprechende lokale Funktionalität, ob beispielsweise die entsprechende Funktion A bis F in dem jeweiligen Land, in welchem sich das Fahrzeug befindet, zulässig ist. Ein weiterer Aspekt hat mit der Lizenzierung zu tun. Hat der Nutzer nicht alle verfügbaren Funktionen lizenziert, wie es über den mit 21 analog zur
Lizenzierung in den Figuren 2 und 3 bezeichneten Pfeil angedeutet ist, stehen ihm bestimmte Funktionen, im Beispiel der Figuren 2 und 3 beispielsweise die Funktionen D und F, aus diesem Grund nicht zur Verfügung. Über den Pfeil 25 wird abgefragt, ob die entsprechende Funktionalität in dem User- Interface 17 bzw. dem
Personalisierungsspeicher 16 für den entsprechenden Nutzer hinterlegt ist. Im letzten mit 26 bezeichneten Pfeil wird dann überprüft, ob die verfügbaren Sensordaten und damit faktisch die Qualität der verfügbaren Sensordaten eine Nutzung der entsprechenden Funktion A bis F zulassen. So können beispielsweise bei entsprechend schlechten Witterungsbedingungen bestimmte Funktionalitäten nicht oder nicht in vollem Umfang genutzt werden, beispielsweise Funktionalitäten des autonomen Fahrens oder andere Funktionalitäten, welche hinsichtlich der Qualität der erfassten Sensordaten auch von den Umgebungsbedingungen, wie beispielsweise der Witterung oder Ähnlichem, abhängen.
Sind all diese Punkte überprüft, werden dem Nutzer analog zur Darstellung in den Figuren 2 und 3 verschiedene Funktionen und Anwendungen A bis F zur Verfügung gestellt. Dies ist auch hier wieder in der mit 22 bezeichneten Box entsprechend angedeutet. Im hier dargestellten Ausführungsbeispiel sind dabei lediglich die Funktionen B und E verfügbar, weil beispielsweise die Funktion C analog zu dem Szenario in Fig. 3 für den jeweiligen Nutzer nicht zur Verfügung steht, weil die Funktionen D und F nicht lizenziert wurden und weil die Funktion A beispielsweise aufgrund lokaler Vorschriften oder der nicht ausreichenden Qualität von Sensordaten nicht verfügbar gemacht werden darf bzw. kann.

Claims

Patentansprüche
1. Fahrzeugbetriebssystem (2) mit einem Funktionsspeicher (3) zum Speichern von Funktionen oder Anwendungen (A, B, F) mit einer Schnittstelle (4) zur Ausgabe von festgelegten Sensordaten an die Funktionen oder Anwendungen (A, B, F) und mit einer Schnittstelle (6) zur Weitergabe von durch die Funktionen oder Anwendungen (A, B, F) generierten Steuerbefehlen an Aktuatoren des Fahrzeugs (1 ),
dadurch gekennzeichnet, dass
ein Speicher (8) vorgesehen ist, in welchem fahrzeugseitig festgelegte zulässige Wertebereiche für die Steuerbefehle hinterlegt sind, wobei die Schnittstelle (6) zur Weitergabe der Steuerbefehle die Steuerbefehle nur im Rahmen der in dem Speicher (8) hinterlegten Wertebereiche weitergibt.
2. Fahrzeugbetriebssystem (2) nach Anspruch 1 ,
dadurch gekennzeichnet, dass
ein Kommunikationsmodul (9) zur Verbindung zumindest des Funktionsspeichers (3) mit einem Backend-Server (1 1 ) vorgesehen ist.
3. Fahrzeugbetriebssystem (2) nach Anspruch 2,
dadurch gekennzeichnet, dass
ein Personalisierungsspeicher (16) vorgesehen ist, welcher mit dem
Funktionsspeicher (3) und dem Kommunikationsmodul (9) verbunden ist, und in welchem gespeichert ist, welche der Funktionen oder Anwendungen (A, B, ..., F) einem Nutzer zur Verfügung stehen.
4. Fahrzeugbetriebssystem (2) nach Anspruch 1 , 2 oder 3,
dadurch gekennzeichnet, dass
wenigstens eine der Funktionen (A, B, ..., F) zur Ausgabe von Steuerbefehlen an eine Scheinwerfersteuerung ausgebildet ist.
5. Verfahren zum Betreiben eines Fahrzeugbetriebssystems (2), bei welchem
Funktionen oder Anwendungen (A, B, F) in einen Funktionsspeicher (3) geladen werden, welche auf Basis von Daten einer Datenschnittstelle (4)
Steuerungsfunktionen in dem Fahrzeug (1 ) ausführen, indem sie Steuerbefehle über eine Schnittstelle (6) an das Fahrzeug (1 ) senden,
dadurch gekennzeichnet, dass
fahrzeugseitig ein Wertebereich der Steuerbefehle auf einen jeweils zulässigen Wertebereich begrenzt wird.
6. Verfahren nach Anspruch 5,
dadurch gekennzeichnet, dass
über die Datenschnittstelle (4) Daten gemäß vorgegebener Modelle von einer Sensorfunktion (5) bereitgestellt werden, welche der Kontrolle des
Fahrzeugherstellers unterliegen.
7. Verfahren nach Anspruch 5 oder 6,
dadurch gekennzeichnet, dass
die Funktionen und Anwendungen (A, B, ..., F) vom Fahrzeughersteller und/oder von Drittanbietern erstellt und über einen Backend-Server (1 1 ) und ein
Kommunikationsmodul (9) in den Funktionsspeicher (3) des
Fahrzeugbetriebssystems (2) geladen werden.
8. Verfahren nach Anspruch 7,
dadurch gekennzeichnet, dass
die Freigabe der geladenen Funktionen oder Anwendungen (A, B, ..., F) anhand von Nutzerdaten und/oder in Abhängigkeit von fahrzeugspezifischen Daten erfolgt.
9. Verfahren nach Anspruch 7 oder 8,
dadurch gekennzeichnet, dass
in eine Schnittstelle zwischen dem Kommunikationsmodul (9) und dem Backend- Server (1 1 ) eine Bezahlfunktion integriert ist.
10. Verfahren nach einem der Ansprüche 5 bis 9,
dadurch gekennzeichnet, dass
die Funktionen oder Anwendungen (A, B, ..., F) fahrzeugspezifische Basisfunktionen (A, B, C) und, insbesondere einem Nutzer zugeordnete, erweiterte Funktionen oder Anwendungen (D, E, F) umfassen.
1 1. Verfahren nach Anspruch 10,
dadurch gekennzeichnet, dass
die erweiterten Funktionen oder Anwendungen (D, E, F) in Abhängigkeit des Nutzers des Fahrzeugs (1 , 1 ') über das Kommunikationsmodul (9) in das Fahrzeug (1 , 1 ') geladen werden.
12. Verfahren nach einem der Ansprüche 7 bis 1 1 ,
dadurch gekennzeichnet, dass
Fahrzeugdaten in Abhängigkeit einer Nutzerzustimmung anonymisiert über das Kommunikationsmodul (9) an den Backend-Server (1 1 ) übertragen und in dem Backend-Server verarbeitet und gegebenenfalls weiterverteilt werden.
PCT/EP2019/055564 2018-04-23 2019-03-06 Fahrzeugbetriebssystem WO2019206502A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/049,704 US11926269B2 (en) 2018-04-23 2019-03-06 Vehicle operating system
CN201980027493.9A CN112004722B (zh) 2018-04-23 2019-03-06 车辆操作系统

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102018003281.8 2018-04-23
DE102018003281.8A DE102018003281B4 (de) 2018-04-23 2018-04-23 Fahrzeugbetriebssystem

Publications (1)

Publication Number Publication Date
WO2019206502A1 true WO2019206502A1 (de) 2019-10-31

Family

ID=65724388

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/055564 WO2019206502A1 (de) 2018-04-23 2019-03-06 Fahrzeugbetriebssystem

Country Status (4)

Country Link
US (1) US11926269B2 (de)
CN (1) CN112004722B (de)
DE (1) DE102018003281B4 (de)
WO (1) WO2019206502A1 (de)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018214419B4 (de) * 2018-08-27 2020-03-19 Volkswagen Aktiengesellschaft Verfahren und Vorrichtung zum automatisierten Fahren eines Fahrzeugs
DE102020101510A1 (de) 2020-01-23 2021-07-29 Bayerische Motoren Werke Aktiengesellschaft Bereitstellung einer auf ein Kraftfahrzeug bezogenen Funktion
US20230303102A1 (en) * 2020-07-21 2023-09-28 Ningbo Geely Automobile Research AND Development Co., Ltd. Vehicle integrated control method and apparatus, device, and storage medium
CN114103848B (zh) * 2021-11-11 2024-03-08 上汽通用五菱汽车股份有限公司 车辆控制方法、车辆控制装置、车辆及存储介质
DE102021005678B4 (de) 2021-11-16 2023-07-06 Mercedes-Benz Group AG Bezahlsystem in einer Hard- und Softwareumgebung in einem Fahrzeug
KR20230156609A (ko) * 2022-05-06 2023-11-14 비플랫 유한회사 이송수단의 광 발산부를 이용한 인증 시스템 및 이에 의한 인증정보 처리 방법
DE102023005085A1 (de) 2023-12-09 2024-05-08 Mercedes-Benz Group AG Verfahren zum Freischalten einer Fahrzeugfunktion und informationstechnisches System

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100222939A1 (en) * 2009-02-27 2010-09-02 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and Systems for Remotely Managing A Vehicle
DE102011109720A1 (de) 2011-08-06 2013-02-07 Daimler Ag Verfahren und System zur benutzerabhängigen Nutzung eines Fahrzeuges
US20150003087A1 (en) * 2011-06-08 2015-01-01 Denso Corporation Vehicular headlight apparatus
US20150045988A1 (en) * 2013-08-09 2015-02-12 Ford Global Technologies, Llc Multi-vehicle settings
US20150197205A1 (en) * 2014-01-10 2015-07-16 Sony Network Entertainment International Llc Apparatus and method for use in configuring an environment of an automobile
US9707913B1 (en) * 2016-03-23 2017-07-18 Toyota Motor Enegineering & Manufacturing North America, Inc. System and method for determining optimal vehicle component settings
DE102016008981A1 (de) 2016-07-23 2018-01-25 Daimler Ag Vorrichtung und Verfahren zur Einstellung einer Lichtverteilung eines Scheinwerfers
DE102017009725A1 (de) * 2017-10-19 2018-03-29 Daimler Ag Verfahren zur Nutzungsfreigabe von Fahrzeugfunktionen

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10022423A1 (de) 2000-05-09 2001-11-15 Bosch Gmbh Robert Verfahren zur Steuerung von Geräten und Gerät in einem Kommunikationsnetz in einem Kraftfahrzeug
US7092803B2 (en) * 2000-08-18 2006-08-15 Idsc Holdings, Llc Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
WO2003019309A1 (en) * 2001-08-23 2003-03-06 General Motors Corporation Vehicle chassis having programmable operating characteristics and method for using same
US20040001593A1 (en) * 2002-06-28 2004-01-01 Jurgen Reinold Method and system for component obtainment of vehicle authentication
WO2005003936A1 (de) * 2003-07-04 2005-01-13 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten
DE102004023128B4 (de) * 2004-05-03 2018-07-12 Volkswagen Ag Vorrichtung und Verfahren zur Kontrolle von Diensten in einem Fahrzeug
US20060036356A1 (en) * 2004-08-12 2006-02-16 Vladimir Rasin System and method of vehicle policy control
DE102013006176A1 (de) * 2013-04-10 2014-10-16 Audi Ag Verfahren zum Betrieb einer einstellbaren Kombinationsanzeigeeinrichtung und Kombinationsanzeigeeinrichtung
US20180012197A1 (en) * 2016-07-07 2018-01-11 NextEv USA, Inc. Battery exchange licensing program based on state of charge of battery pack
US11059494B1 (en) * 2018-02-15 2021-07-13 State Farm Mutual Automobile Insurance Company System and method for transferring preferences for autonomous driving

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100222939A1 (en) * 2009-02-27 2010-09-02 Toyota Motor Engineering & Manufacturing North America, Inc. Methods and Systems for Remotely Managing A Vehicle
US20150003087A1 (en) * 2011-06-08 2015-01-01 Denso Corporation Vehicular headlight apparatus
DE102011109720A1 (de) 2011-08-06 2013-02-07 Daimler Ag Verfahren und System zur benutzerabhängigen Nutzung eines Fahrzeuges
US20150045988A1 (en) * 2013-08-09 2015-02-12 Ford Global Technologies, Llc Multi-vehicle settings
US20150197205A1 (en) * 2014-01-10 2015-07-16 Sony Network Entertainment International Llc Apparatus and method for use in configuring an environment of an automobile
US9707913B1 (en) * 2016-03-23 2017-07-18 Toyota Motor Enegineering & Manufacturing North America, Inc. System and method for determining optimal vehicle component settings
DE102016008981A1 (de) 2016-07-23 2018-01-25 Daimler Ag Vorrichtung und Verfahren zur Einstellung einer Lichtverteilung eines Scheinwerfers
DE102017009725A1 (de) * 2017-10-19 2018-03-29 Daimler Ag Verfahren zur Nutzungsfreigabe von Fahrzeugfunktionen

Also Published As

Publication number Publication date
US11926269B2 (en) 2024-03-12
DE102018003281B4 (de) 2019-12-05
CN112004722A (zh) 2020-11-27
US20210237664A1 (en) 2021-08-05
DE102018003281A1 (de) 2019-10-24
CN112004722B (zh) 2024-02-13

Similar Documents

Publication Publication Date Title
DE102018003281B4 (de) Fahrzeugbetriebssystem
DE102017211748B4 (de) Verfahren zum Betreiben einer Ausgabeeinrichtung eines Kraftfahrzeugs, Fahrerassistenzeinrichtung, und Kraftfahrzeug
DE102007010763A1 (de) Verfahren zur adaptiven Konfigurationserkennung
EP3746344B1 (de) Steuerungssystem für ein kraftfahrzeug zum koordinieren und ausführen von kundenfunktionen, verfahren zum betreiben eines derartigen steuerungssystems sowie kraftfahrzeug mit einem derartigen steuerungssystem
EP3821627B1 (de) Verfahren zum kontrollieren eines datenaustauschs zwischen einer steuereinrichtung eines kraftfahrzeugs und einer externen einrichtung, steuereinrichtung für ein kraftfahrzeug sowie kraftfahrzeug mit einer derartigen steuereinrichtung
EP1870302A1 (de) Remote-Personalisierung einer On-Board-Unit
DE102016216746B3 (de) Elektrofahrrad
DE102006026653A1 (de) Vorrichtung und Verfahren zum Steuern eines Fahrzeugs
WO2020115145A1 (de) Fahrerassistenzsystem und verfahren zum assistierten betreiben eines kraftfahrzeugs
DE202015104711U1 (de) Fahrzeug mit einer Benutzerrealausprägung
DE102018214234A1 (de) Fahrzeug sowie Verfahren zum Betrieb eines Fahrzeugs
DE102018212266A1 (de) Anpassung eines auswertbaren Abtastbereichs von Sensoren und angepasste Auswertung von Sensordaten
DE102005009640A1 (de) Vorrichtung und Verfahren zur Steuerung einer Fuktion in einem Kraftfahrzeug
WO2021058177A1 (de) Verfahren zum zumindest assistierten durchfahren eines kreisverkehrs durch ein kraftfahrzeug
EP4025439A1 (de) Parametrierbares steuergerät für eine anhängekupplung
DE102017101803B4 (de) Vorrichtung zum wenigstens teilweisen Unterbrechen einer Kommunikationsleitung eines Fahrzeugs
DE102015213185A1 (de) Längsführendes Fahrerassistenzsystem in einem Kraftfahrzeug
EP2822829B1 (de) Fahrerassistenzsystem für ein kraftfahrzeug
DE102016216747A1 (de) Elektrofahrrad
DE102019127245A1 (de) Fahrsystem und Verfahren zum zumindest teilweise automatisierten Fahren
DE102019130318A1 (de) Verfahren zum Betrieb eines Kraftfahrzeugs
DE102022134641B3 (de) Datenverarbeitungseinrichtung für Kraftfahrzeuganwendungen, Kraftfahrzeug, sowie Verfahren zum Vorgeben einer Gruppe von Steuerbefehlen für ein Kraftfahrzeug
WO2024061758A1 (de) Verfahren für die steuerung mehrerer funktionen an einem fahrzeug über ein zumindest teilweise in einer steuereinheit implementiertes steuerungsprogramm einer elektronischen steuereinrichtung, steuerungssystem und computerprogrammprodukt
WO2024061750A1 (de) Verfahren für die fahrzeugübergreifende nutzung eines benutzerprofils, steuerungssystem und computerprogrammprodukt
DE102017201022A1 (de) Kommunikation einer Fahrzeugapplikation mit einem Kraftfahrzeug

Legal Events

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

Ref document number: 19709888

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19709888

Country of ref document: EP

Kind code of ref document: A1