Method for providing a service in a vehicle, computer-readable storage medium, release module, insulation module, vehicle, and system

Abstract

The invention relates to the process of providing a service in a vehicle (100). The service is rendered by using at least one vehicle-side service component (160) and an external service component (200), in particular as a cooperative service rendering process. A method for providing the service in the vehicle (100) has the following steps: - receiving a request relating to the process of providing the service in the vehicle (100); - ascertaining an identification code (I_ext) of the external service component (200) and / or an identification code (I_int) of the vehicle-side service component (160); - ascertaining release information (F) for the cooperative service rendering process for the vehicle (100) using a release list (400) and the identification code of the vehicle-side service component (160) and / or the identification code of the external service component (200), and - releasing at least one (vehicle-side) interface for the vehicle-side service component (160) and / or for the external service component (200) in accordance with the release information (F) by means of a release module (110) of the vehicle (100) in order to provide the service.

Description

[0001] Method for providing a service in a vehicle, computer-readable storage medium, enabling module, isolation module, vehicle and system

[0002] Description

[0003] In modern vehicles, networking with external components, such as a passenger's smartphone or cloud services, is becoming increasingly important.

[0004] Thanks to networking, a vehicle's range of functions can be expanded to include services that arise from the interaction of an on-board service component and an external service component. Conversely, the range of functions of an external cloud service or external device can also be expanded through networking and interaction with a service component in the vehicle that provides vehicle functions or data. The interaction of external and on-board service components is referred to as cooperative service provision. For example, the vehicle's range of functions can be expanded to include music streaming, with an external cloud-based service providing the audio streaming data and a corresponding on-board service providing, for example, audio playback and suitable display and control elements in the vehicle. In this way, the music streaming service is provided cooperatively.

[0005] Services such as telephony and music can also be provided cooperatively between the vehicle and a passenger's mobile device by exchanging data between vehicle-side service components and external service components of the mobile device via interfaces and protocols.

[0006] As a further example, a service on a smartphone (e.g., a smartphone application such as the "MyBMW" app from BMW) can inform the user about the charge level of the vehicle battery or enable the control of vehicle functions from the smartphone (e.g., horn, auxiliary heating, door locking), if the vehicle itself provides suitable service components and interfaces for this purpose.

[0007] Reliable and error-free cooperative service provision is particularly important in the automotive sector, especially due to the consequences or risks that can arise from faulty service provision in a vehicle. Reliable and error-free cooperative service provision depends significantly on the compatibility and accuracy of the service components involved, as well as possibly on other aspects that can influence compatibility, such as the nature and configuration of the vehicle.

[0008] However, ensuring compatibility is made more difficult by the fact that the vehicle-side and external service components involved are usually developed independently of one another and have different development and life cycles.

[0009] This is particularly evident in the example of cooperative service provision between a vehicle and a standard smartphone with software and apps: Both systems are designed, developed, and updated independently of each other. Therefore, a one-time compatibility check of both systems may not be sufficient to ensure compatibility throughout the entire life cycle of a vehicle. This applies similarly to cloud services, which are also typically developed and enhanced independently of specific vehicles.

[0010] In addition, a planned cooperative service may not be available at the time of vehicle production, but may only be enabled through the later provision of a cloud service or through a software update of the smartphone or a smartphone app.

[0011] In addition to incompatibilities between the service components involved, there may also be other reasons that require a subsequent (temporary) deactivation of cooperative service provision to ensure error-free and safe operation of the vehicle. The temporary deactivation should last at least until the problem is resolved.

[0012] An example of this is the discovery of a security vulnerability in the external service component, in particular in a cloud service, a smartphone app, or an execution environment thereof (e.g. cloud server, smartphone operating system, communication stack).

[0013] A security vulnerability or incompatibility can also be triggered by a software update on the side of the external service component (i.e. the cloud service, the smartphone or the smartphone app) or the vehicle-side service component (i.e. the vehicle-side software).

[0014] One object of the present invention is to provide a method for the reliable and error-free provision of a service in a vehicle. The service can, in particular, be a service that is provided using at least one vehicle-based service component and one external service component, preferably cooperatively. Furthermore, the object of the invention is to provide corresponding devices for implementing the method.

[0015] In particular, the procedure is intended to prevent malfunctions in the vehicle resulting from incompatibilities or other errors in the service components.

[0016] This object is achieved by a method according to claim 1, a computer-readable storage medium according to claim 11, a release module according to claim 12, an isolation module according to claim 13, a vehicle according to claim 14 and a system according to claim 15.

[0017] In particular, the problem is solved by a method for providing a service in a vehicle. The service is provided using at least one vehicle-side service component and one external service component, in particular as a cooperative service provision. The method comprises the following steps:

[0018] Receiving a request regarding the provision of the service in the vehicle; Determining an identification code of the external service component and / or an identification code of the vehicle-side service component;

[0019] Determining release information for the cooperative service provision for the vehicle, using a release list and the identification code of the vehicle-side service component and / or the identification code of the external service component;

[0020] Releasing at least one (vehicle-side) interface for the vehicle-side service component and / or for the external service component by an enabling module of the vehicle in order to provide the service, in accordance with the enabling information.

[0021] One aspect of the invention is that the release of at least one (vehicle-side) interface for the vehicle-side service component and / or for the external service component only occurs after a check by an in-vehicle release module. In this way, interfaces required to provide a service can remain deactivated unless corresponding release information is available. The vehicle can thus be operated by default in a secure mode—with regard to service provision—and / or revert to such a mode as soon as current or valid release information is no longer available. This protects the vehicle from malfunctions resulting from the cooperative service provision and can thus increase vehicle safety.

[0022] To perform the check, the method first determines identification codes from one or both of the involved service components following a corresponding request in order to identify them. However, according to the invention, the request does not have to be made immediately before the desired provision of the service in the vehicle, but can be made at any time beforehand, for example, when the on-board computer is started, at regular intervals, or during the last change / update. According to the described method, release information for the respective service in the respective vehicle is determined upon the request.

[0023] Release information can be understood as information that indicates the extent to which the service in question is released, i.e., to what extent it may be provided in the vehicle. The invention therefore explicitly provides not only for completely enabling or prohibiting the provision of the service in the vehicle, but also for granting releases at the functional level. This allows the provision of the service in the vehicle to be precisely controlled.

[0024] The release information is determined using the identification code(s) and a release list. The release list can be a database or other data structure.

[0025] The approval list can formulate minimum requirements that the components involved in the service provision, in particular the vehicle-side service component and the external service component, must fulfill in order for the service to be permitted to be provided in the respective vehicle. The requirements can, for example, relate to the vehicle-side service component itself (software version, etc.) as well as its execution environment, i.e. the vehicle (special equipment, software versions, year of manufacture, hardware versions, etc.). The requirements can also relate to the external service component itself (software version of the smartphone app, software version of the cloud service, etc.) as well as its execution environment (e.g. operating system version of the smartphone, server of the cloud service, etc.). In addition, the approval list can contain general requirements for the operating environment (location of the vehicle, time of day, etc.).), for example, to comply with legal requirements.

[0026] In one embodiment, the release information may be determined by the release module and the method may further comprise the following steps: determining characteristics of the cooperative service provision;

[0027] Transmitting the property features to a backend server by means of a mobile terminal and / or by means of a communication module of the vehicle, wherein the release list is stored on the backend server;

[0028] Determining records from the release list using the property attributes;

[0029] Transferring the data records of the release list from the backend server to the vehicle, in particular by means of a mobile terminal and / or by means of a communication module of the vehicle;

[0030] Transferring the data records to a database of the release module.

[0031] The release information is determined by the release module using the data records and the characteristics of the cooperative service provision.

[0032] According to this embodiment, the release information is determined by the release module in the vehicle, with the release list being stored on the backend server. In order to transmit only the data records of the release list relevant to the requested service provision to the vehicle, rather than the entire release list, the characteristics of the cooperative service provision are first determined.

[0033] The property features can in particular include the following information: a set of attributes of vehicle-side service components; a set of attributes of external service components; a set of identification identifiers of services and / or service scopes; a set of attributes of the vehicle, in particular vehicle identification, attributes of hardware and software components (e.g. versions, configurations), vehicle equipment, country of vehicle registration, country of the vehicle user, geographical location of the vehicle.

[0034] A set can be understood as a collection of any number of elements. The set can be described by explicitly enumerating the elements it contains (whitelist), explicitly enumerating the elements it does not contain (blacklist), or implicitly by an expression, possibly using placeholders. An attribute of a (vehicle-side or external) service component can be understood in particular as a software version number or a serial number. An attribute of the vehicle-side service component can also include attributes about the vehicle itself, in particular the chassis number, installed special equipment, country of vehicle registration, etc.

[0035] According to the described embodiment, the determined property features are then transmitted to a backend server. The transmission can take place in particular via a mobile device connected to the vehicle and / or via a communication module of the vehicle. The mobile device can, for example, be connected to a head unit of the vehicle, in particular via Bluetooth or Wi-Fi, and can establish a connection to the backend server via a mobile data connection. The communication module can be connected to the backend server via any wireless technology (e.g., LTE, 5G, Wi-Fi, etc.) or other technologies, such as communication via a charging plug.

[0036] After the property attributes have been transmitted, data records from the approval list are determined using the property attributes. This can, in particular, involve filtering the approval list for data records that are relevant to the request, i.e., that match one or more of the transmitted property attributes. This optional optimization step of transmitting property attributes to the backend server and filtering data records that are currently and possibly also future relevant for this specific vehicle prevents data records from being transmitted back to the vehicle that are not relevant at all, for example, because they refer to a different software version of the vehicle-side service component.In this case, more data can be deliberately transferred from the backend server to the vehicle than is necessary in the current configuration, for example in order to have data records already available in the vehicle for the time after the next software update.

[0037] The transmission of the determined data sets to the vehicle can take place in particular via the communication channels described above, in particular via a communication module or via a mobile device.

[0038] In the vehicle, the received data records are finally transferred to a database of the release module, which then determines the release information based on the received data records. According to this embodiment, the release information is determined in the vehicle. This offers the advantage that additional information that is only available in the vehicle can be included in the determination of the release information. For example, it can be checked whether a vehicle error memory contains an error code, or whether the vehicle is located at a specific geographical location. A further advantage is that the vehicle can react independently and immediately to changes (e.g., software updates of the service components) and can independently generate release information without having to rely on online communication with the backend server. This is particularly possible if a large amount of valid data records (e.g.,validity period not yet exceeded) is already in the vehicle.

[0039] In an alternative embodiment, the release information is determined by a backend server and the method further comprises the following steps:

[0040] Identifying characteristics of cooperative service provision;

[0041] Transmitting the property features to a backend server by means of a mobile terminal and / or by means of a communication module of the vehicle, wherein the release list is stored on the backend server;

[0042] Determining the release information by the backend server, further using the characteristics of the cooperative service provision; transmitting the release information from the backend server to the vehicle, in particular by means of a mobile terminal and / or by means of a communication module of the vehicle;

[0043] Transferring the release information to the release module.

[0044] Optionally, the method may further comprise the following step:

[0045] (One-time or recurring) evaluation of the validity of the release information by the release module, in particular using the current characteristics of the cooperative service provision.

[0046] The key difference from the previously described embodiment is that the release information is determined on the backend server and not in the vehicle. This requires that the backend server has all the information required to determine the release information. An advantage of this embodiment, however, is that only the release information and not data records from the release list need to be transmitted back from the backend server to the vehicle. The release information can have a significantly smaller data volume than the (potentially large) volume of data records. This reduces the load on the communication connection between the vehicle and the backend server, or the vehicle and the mobile device, and allows it to be used more efficiently. Furthermore, the logic for determining the release information in the backend can be updated at any time and, if necessary, supplemented with additional data sources.

[0047] The optional evaluation of the validity of the release information by the release module can be performed either once or recurringly. A recurring evaluation has the advantage that changes to the property characteristics can lead to a new, modified evaluation. The recurring evaluation can be triggered by changes to the property characteristics (e.g., software updates, configuration changes), at specific time intervals, or in connection with a vehicle start-up or sleep process. Furthermore, a recurring evaluation can be performed depending on the request for service provision.

[0048] In one embodiment, releasing the at least one interface according to the release information may comprise at least one of the following steps:

[0049] Activating a software interface, in particular for use by a vehicle-side service component;

[0050] Activating a hardware component of the vehicle;

[0051] Starting a software process in the vehicle;

[0052] Activating a communication interface, in particular an on-board network interface or network port, and / or network connection in the vehicle;

[0053] Activating and / or extending an interface, in particular a communication interface, to the external service component;

[0054] Providing the release information in the vehicle.

[0055] According to this embodiment, the interfaces or (software) processes required to provide the service can be activated in the vehicle. To achieve the greatest possible security, it is preferred that the interfaces or processes in the vehicle be deactivated by default.

[0056] Activating or deactivating interfaces can be done using a mechanism developed according to ISO 26262 (Automotive Functional Safety) and / or ISO 21434 (Automotive Cybersecurity).

[0057] In one embodiment, the service (the cooperative service provision) may be a control of an auxiliary heater, a horn or a locking system of the vehicle.

[0058] In one embodiment, at least one, preferably each data record of the release list comprises one or more of the following data: a set of attributes of vehicle-side service components; a set of attributes of external service components; a set of identification identifiers of services and / or service scopes; a set of attributes of the vehicle, in particular vehicle identification, hardware and software components, vehicle equipment, country of vehicle registration, country of the vehicle user, geographical location of the vehicle; a set of attributes of an execution environment of the external service component, in particular versions of interfaces, hardware, operating system.

[0059] The determination of the release information comprises a comparison with at least one attribute of the vehicle-side service component and / or at least one attribute of the external service component or its execution environment and / or at least one attribute of the vehicle.

[0060] As already described, the quantities can be described in particular in the form of a whitelist or blacklist.

[0061] In one embodiment, at least one data record of the release list may further include a validity period specification. Determining the release information may involve comparing the validity period specification of the data record with a system time of the vehicle and / or a system time of an execution environment of the external service component and / or a system time provided online or via satellite.

[0062] Likewise, release information issued by the backend server may include a validity period.

[0063] Preferably, the service is not provided or is provided with a reduced scope if the system time of the vehicle and / or the system time of the vehicle component is outside the range specified by the validity period. Preferably, the system time used is protected against manipulation, for example, by a protection mechanism against resetting the system time in the vehicle or by comparison with a trusted time server.

[0064] Specifically, in the described embodiment, the data records can be assigned an expiration date, which is set, for example, to 30 days after the data record's publication in the approval list. This allows the service in question to be operated in the vehicle for a maximum of 30 days, unless a newer data record with an extended expiration date is provided. This can prevent a failure to update the data records from resulting in a service being provided that is no longer permitted according to the current approval list.

[0065] The same applies to a validity period specified for release information provided by the backend server.

[0066] In a further embodiment, at least one data record of the release list may further comprise a geographical area specification, and determining the release information may comprise comparing the geographical area specification of the data record with a (geographical) location of the vehicle and / or a (geographical) location of an execution environment of the external service component.

[0067] The geographical area specification can, for example, consist of countries or sets of geo-coordinates that describe areas. Furthermore, the geographical area specification can consist of elements such as road types (e.g., highway, country road, intersection), street names, cities, and geofences around certain categories of points of interest (e.g., gas stations, airports, traffic lights). This embodiment allows a specific service to be permitted or denied exclusively in certain geographical regions, for example, in a specific country.

[0068] In a further embodiment, at least one data record of the release list and / or the release information may be digitally signed and the method may further comprise the following step:

[0069] Verifying at least one digital signature of a data set and / or a digital signature of the release information by the release module.

[0070] Preferably, the approval module does not grant approval for the provision of the service or grants it only to a limited extent if the verification of the digital signature fails.

[0071] This embodiment further increases the security of service provision by verifying the integrity of individual data records. If data records are maliciously altered or the release information is corrupted due to a transmission error, this invalidates the digital signature. By (precautionary) restricting or preventing service provision in such cases, vehicle security is further increased. In a further embodiment, at least one data record of the

[0072] The release list may include at least one test condition. The test condition may, in particular, be the absence of an error code in the vehicle or the validity of a digital signature of a software module of the vehicle. Furthermore, the test condition may relate to properties of current vehicle or operating states, a current state or data of vehicle functions, a current value of sensor measurements of the vehicle, or a current operating state of the external service or its execution environment. Furthermore, the method may further comprise the following step:

[0073] Determine whether the test condition is met in the vehicle.

[0074] Again, it is preferred that the approval module not grant approval for the provision of the service, or only grants it to a limited extent, if the test condition is not met. Determining whether the test condition is met can also be done repeatedly at specific times or events, or continuously.

[0075] Similar advantages arise as in the previously described embodiment.

[0076] The object is further achieved by a computer-readable storage medium. The computer-readable storage medium contains instructions that cause at least one processor to implement a method as described above when the instructions are executed by the at least one processor.

[0077] Furthermore, the object is achieved by a release module in a vehicle. The release module is preferably designed to perform one or more of the following steps:

[0078] Determining characteristics of a cooperative service provision in a vehicle, in particular between a vehicle-side service component and an external service component;

[0079] Receiving and / or sending a request regarding the provision of a service in the vehicle, wherein the request comprises an identification code of an external service component and / or an identification code of a vehicle-side service component;

[0080] Receiving data records of a release list from a mobile terminal and / or a communication module of the vehicle and storing the data records in a database of the release module;

[0081] Determining and / or receiving release information for the cooperative service provision using a release list, in particular using the respective current characteristics of the cooperative service provision;

[0082] Enabling at least one (vehicle-side) interface for the vehicle-side service component and / or for the external service component to provide the service, in accordance with the enabling information, in particular by means of an isolation module as described below;

[0083] Storing determined or received release information, in particular for later use;

[0084] Checking the validity of release information, in particular its temporal validity and / or geographical validity, if necessary followed by a request for new release information;

[0085] Re-determining characteristics of the cooperative service provision and checking whether the validity of previously stored release information with regard to the newly determined characteristics still exists.

[0086] With regard to the release module, similar technical advantages and effects arise as those already described in connection with the method according to the invention.

[0087] Furthermore, the object is achieved by an isolation module in a vehicle. The isolation module can be configured to cause at least one control unit and / or a software component of the vehicle to activate or deactivate an interface for the vehicle-side service component and / or for the external service component, in particular by at least one of the following:

[0088] Allowing or preventing the execution of software, in particular at an operating system level of the vehicle or the vehicle-side service component;

[0089] Forwarding or absorbing data and / or control commands, in particular on a communication path between the vehicle and the vehicle-side service component and / or between the vehicle-side service component and the external service component;

[0090] Sending error codes, in particular on a communication path between the vehicle and the vehicle-side service component and / or between the vehicle-side service component and the external service component, wherein the isolation module is preferably connected to an enabling module, in particular as described above. For example, the isolation module can enable or prevent the software-based execution of the vehicle-side service component at the operating system level (or between the operating system and the vehicle-side service component).

[0091] Furthermore, the isolation module can be implemented as a type of proxy between a vehicle API and the vehicle-side service component, thus ensuring access control between the interfaces provided by the vehicle and the vehicle-side or external service component. Alternatively, the isolation module can be implemented as a type of proxy between the vehicle-side service component and the external service component, thus ensuring access control between the respective interfaces of the vehicle-side or external service component.

[0092] Access control can also be expressed in the form of regulating access by returning default values ​​(e.g. "0") or error values ​​(e.g. "OxFF") or error codes provided in the API.

[0093] Preferably, the isolation module is capable of performing this access control for multiple services individually for each service and each interface.

[0094] With regard to the insulation module, similar technical advantages and effects arise as those already described in connection with the method according to the invention.

[0095] Furthermore, the object is achieved by a vehicle comprising the following: a release module as described above and at least one isolation module as described above, in particular for implementing the method as described above; at least one vehicle-side service component; a communication module.

[0096] The vehicle is designed to provide a service using at least one vehicle-side service component and an external service component, in particular as a cooperative service provision.

[0097] Preferably, the vehicle further comprises a position determination module, in particular a GPS module, and / or a mechanism for determining a system time provided internally or externally to the vehicle. With regard to the vehicle, similar technical advantages and effects arise as those already described in connection with the method according to the invention.

[0098] Furthermore, the object is achieved by a system, in particular for carrying out a method as described above. The system comprises the following: a vehicle as described above; an external service component; and a backend server.

[0099] In a preferred embodiment, the system further comprises a mobile terminal which is designed to

[0100] to transmit characteristics of the cooperative service provision of the vehicle to a backend server; and / or

[0101] Retrieve records of a release list from the backend server and transfer them to a database of the release module; and / or retrieve release information from the backend server and transfer it to the release module.

[0102] This embodiment is advantageous in that mobile devices, in particular commercially available smartphones, support communication via different networks (e.g., mobile network, Wi-Fi, etc.), whereas a vehicle's communication module may, under certain circumstances, be limited to certain radio technologies, such as a mobile network. Furthermore, mobile devices are regularly located in environments where such connections can actually be established (e.g., through sufficient mobile network reception, a Wi-Fi network in the vicinity of the mobile device, etc.). A communication module may not be able to establish a connection to a server if it can only communicate via mobile network and the vehicle is located at a remote location or in an underground car park where reception is insufficient.

[0103] In this context, it can be advantageous to have a time lag between A) the mobile device retrieving data records from the release list from the backend server, after the necessary information has been transferred from the vehicle to the mobile device, and B) the transfer of the data records from the mobile device to the vehicle. For example, the retrieval of data records according to A), for example using a BMW app on a smartphone, can take place at a time and place where the smartphone can establish an internet connection via WLAN. The transfer of the data records to the vehicle according to B) can take place later in the vehicle, for example when the smartphone establishes a Bluetooth or WLAN connection to a head unit in the vehicle, which forwards the received data records to the release module via the vehicle's on-board network.

[0104] In other words, the mobile device can act as a buffer to enable updating of the release module's internal database in situations where the vehicle cannot establish a connection to the backend server via the communication module.

[0105] Furthermore, the system offers similar technical advantages and effects as those already described in connection with the method according to the invention.

[0106] It goes without saying that the features and the advantages that can be achieved thereby, which have been described with reference to the method according to the invention, are applicable or transferable to the devices according to the invention and vice versa.

[0107] Specifically, in the context of the present description of the invention, the components of the devices are designed to perform the method steps according to the invention. Likewise, the functions of the above-described components of the devices according to the invention can be used as method steps of the method according to the invention.

[0108] The invention is described below using an exemplary embodiment, which is explained in more detail with reference to the figures. Herein:

[0109] Figure 1: a system according to the invention;

[0110] Figure 2: the components of the vehicle from Figure 1;

[0111] Figure 3a: a flowchart of the inventive method for providing a service, according to a first embodiment;

[0112] Figure 3b: a flowchart of the inventive method for providing a service, according to a second embodiment;

[0113] Figure 4: the content of the release list on the backend server.

[0114] In the following description, the same reference numbers are used for identical and equivalent parts. Figure 1 shows the components of a system according to the invention, which

[0115] Vehicle 100, a cloud service 200, a backend server 300 and a smartphone 500.

[0116] The vehicle 100 has a parking heater 150 that can be controlled by the cloud service 200. For this purpose, the control unit 160 of the parking heater 150 is configured to receive corresponding commands via the vehicle's electrical system. The cloud service 200 forms the external service component, and the control unit 160 comprises a vehicle-side service component for cooperative service provision.

[0117] Furthermore, the vehicle 100 has a communications module 120. This is designed to establish a communications connection to the cloud service 200 and to the backend server 300. The communications connection can be, for example, an LTE or other mobile network or data connection (e.g., a charging connector). Furthermore, the vehicle 100 has a head unit 170 as the central infotainment system.

[0118] The smartphone 500 is connected to the vehicle 100 via the head unit 170, for example, via Bluetooth or Wi-Fi. Furthermore, the smartphone 500 can establish a connection to the backend server 300, for example, via a cellular network or Wi-Fi.

[0119] In Figure 1, the aforementioned communication connections are shown as dashed lines between two components of the system. Further components of the vehicle 100 are described below in connection with Figure 2.

[0120] Figure 2 shows an overview of all components of the vehicle 100 which are relevant for the description of the embodiment.

[0121] In addition to the components already mentioned, the vehicle 100 has in particular a release module 110 with an integrated database 111, which is designed to store data records of a release list.

[0122] In order to control the communication of the vehicle-side service component on the control unit 160 with the auxiliary heater 150 according to release information determined by the release module 110, the control unit 160 has an integrated isolation module 165.

[0123] Furthermore, the vehicle 100 has a GPS module 130, which can determine a geographical position of the vehicle 100. The control unit 160, the isolation module 165, the head unit 170, the release module 110, the GPS module 130, and the communication module 120 can communicate with each other in the vehicle via the on-board network 105.

[0124] Preferably, the vehicle 100 further comprises a time module (not shown) via which a secure time can be obtained. This can, in particular, be a secure system time of the vehicle 100 or another secure time obtained via the communication module 120 or the GPS module 130.

[0125] The method according to the invention for providing the service, i.e. the control of the auxiliary heater 150 via the cloud service 200, is described with reference to Figures 3a and 3b.

[0126] Figure 3a shows the method according to a first embodiment in which the determination of the release information takes place in the vehicle 100.

[0127] In an initial registration step S1, a request is received from cloud service 200, in which cloud service 200 requests authorization to control auxiliary heater 150 within the framework of cooperative service provision. Subsequently, in step S1, identification identifiers I_ext, I_nt of the participating service components are determined; according to this exemplary embodiment, "HEATER_CONTROL_CLOUD" is used as the identification identifier of cloud service 200 and "HEATER_CONTROL_VEHICLE" is used as the identification identifier of the vehicle-side service component on control unit 160.

[0128] In step S2, property features M of the cooperative service provision are determined from the identification identifiers IJnt and I_ext, wherein the property features M according to the described embodiment contain the following information:

[0129] Software version of the vehicle-side service component on the control unit: 3.2; Software version of the cloud service: 11.0;

[0130] Requested service: Control of the auxiliary heater ("HEATER").

[0131] In step S3, the property features M are transmitted from the vehicle 100 to the backend server 300 via the communication module 120.

[0132] In step S4, the backend server 300 determines the data records 412 and 414 of the approval list that are relevant for the cooperative service provision according to the received property characteristics M. The structure of the approval list and the determination of the relevant data records are explained in more detail below in connection with Figure 4. The determined data records 412, 414 are first transmitted back to the communication module 120 of the vehicle 100 in step S5 by the backend server 300. In the vehicle 100, the received data records 414 and 414 are forwarded via the on-board network 105 to the approval module 110 and stored in the database 111.

[0133] In step S6, the release information F is determined by the release module 110. To do so, the release module queries the contents of the database 111, which contains, in particular, the two data sets 412 and 414. According to the two transmitted data sets 412 and 414, the control of the auxiliary heater 150 is released by the cloud service 200 if at least one of the following conditions (i) or (ii) is met:

[0134] (i) the software version of the vehicle component "HEATER_CONTROL_VEHICLE", i.e., the vehicle-side service component on the control unit 160, is 3.0 or higher; the software version of the external component "HEATER_CONTROL_CLOUD", i.e., the cloud service 200, is 10.0 or higher; the GPS location of the vehicle 100 is in the DE or NL territory; and the service execution takes place until February 1, 2022;

[0135] (ii) the software version of the vehicle component "HEATER_CONTROL_VEHICLE", i.e., the vehicle-side service component on the control unit 160, is 3.0 or higher; the software version of the external component "HEATER_CONTROL_CLOUD", i.e., the cloud service 200, is 11.*; the GPS location of the vehicle 100 is in the SE area; and the service execution takes place until March 1, 2022.

[0136] Condition (i) corresponds to data set 412, and condition (ii) to data set 414. For further verification, the release module 110 retrieves the current GPS location of the vehicle 110 via the GPS module 130, as well as a current time, including the date, from a secure time source. For this exemplary embodiment, it is assumed that the GPS location is in the DE region and that the time is January 1, 2022.

[0137] The release module now checks, based on the attributes M, the GPS location, and the time, whether at least one of conditions (i) or (ii) is met. According to the data described above, this is the case for condition (i). Consequently, the release module 110 creates a release information item F that permits control of the auxiliary heater 150 by the cloud service 200 in the vehicle 100 until February 1, 2022 at the latest.

[0138] Finally, in step S9, the release module 110 provides the determined release information F to the isolation module 165. The isolation module 165 then releases APIs of the communication interface between the vehicle-side service component and the external service component, as well as APIs of the communication interface between the vehicle-side service component and the auxiliary heater 150, for the cooperative service provision according to the determined release information F. The isolation module 165 consequently forwards data and control commands resulting from the cooperative service provision with the cloud service 200 to the auxiliary heater 150 until the specified date.

[0139] Figure 3b shows the method according to a second embodiment, in which the release information is not determined in the vehicle 100, but by the backend server 300.

[0140] Steps S1 to S3 in Figure 3b are identical to the corresponding steps described previously, except that in steps S2 and S3, respectively, the attributes M' are determined and transmitted. The attributes M' contain the attributes M as described in connection with Figure 3a, but additionally the determined GPS position and the time information as described there.

[0141] In step S7, the backend server uses the compatibility list and the determined attributes M' to determine a release information F for the cooperative service provision. In contrast to the embodiment described in Figure 3a, this is possible because the attributes M' here contain all the necessary data required for a complete check according to the release list.

[0142] The determined release information F is first transmitted back to the communication module 120 of the vehicle 100 in step S8 from the backend server 300. In the vehicle 100, the release information is forwarded to the release module 110 via the on-board network 105.

[0143] In step S9, the communication interfaces are again enabled, as described in connection with step S9 of Figure 3a.

[0144] Figure 4 shows the release list 400, which comprises four data records 411-415, each forming tuples of seven components. Each data record 411-415 represents a temporally and spatially limited release of a service for a combination of vehicle component and external service component. Each data record 411-415 contains information about the respective service, identification codes of the vehicle component and the external service component, a software version (SW version) of the vehicle component, a SW version of the external service component, the geographical area, and an expiration date. In the software versions, the relation >= is used to specify the set of all versions equal to or higher than the specified version number. An asterisk represents a placeholder that can be replaced by any number or country code.

[0145] Data record 411 represents a release of the "LOCK" service for the vehicle component "LOCK_CONTROL_VEHICLE" with SW version 2.0 or higher and the external service component "LOCK_CONTROL_APP" of SW version 7.*. The release is valid in the countries DE, NL, PL, and SE and is valid until June 1, 2022.

[0146] Data record 412 represents a release of the "HEATER" service for the vehicle component "HEATER_CONTROL_VEHICLE" with software version 3.0 or higher and the external service component "HEATER_CONTROL_CLOUD" with software version 10.0 or higher. The release is valid in the countries DE and NL and is valid until February 1, 2022.

[0147] Dataset 413 represents a release of the "HORN" service for the vehicle component "HORN_CONTROL_VEHICLE" with software version 3.0 or higher and the external service component "HORN_CONTROL_APP" with software version 8.0 or higher. The release is geographically unlimited and valid until January 1, 2022.

[0148] Data record 414 represents a release of the "HEATER" service for the vehicle component "HEATER_CONTROL_VEHICLE" with SW version 3.0 or higher and the external service component "HEATER_CONTROL_CLOUD" of SW version 11.*. The release is valid in the country SE and until March 1, 2022.

[0149] Dataset 415 represents a release of the "HEATER" service for the vehicle component "HEATER_CONTROL_VEHICLE" with software version 4.0 or higher and the external service component "HEATER_CONTROL_CLOUD" with software version 11.0 or higher. The release is geographically unlimited and valid until April 1, 2022.

[0150] In the embodiment described above, the attributes M, M', which are transmitted to the backend server 300, contain at least the following information:

[0151] Requested service: Control of the auxiliary heater ("HEATER");

[0152] Vehicle component identification code: HEATER_CONTROL_VEHICLE; external service component identification code: HEATER_CONTROL_CLOUD; control unit (=vehicle component) software version: 3.2;

[0153] Software version of the cloud service (=external service component): 11.0.

[0154] In the release list 400, only data records 412, 414, and 415 refer to the specified service. However, the prerequisites formulated by data record 415 do not apply to the property features M, M', since the software version of the vehicle component is lower than 4.0. Therefore, in steps S4 and S5 of Figure 3a, only data records 412 and 414 are determined as relevant and transmitted to the vehicle 100. In the embodiment of Figure 3b, starting from the property features M', a piece of release information F is directly determined based on data record 412, since all prerequisites are met.

[0155] In the exemplary embodiment described above, the data transmission between vehicle 100 and backend server 300 is implemented solely by the communication module 120 of vehicle 100. Alternatively or additionally, smartphone 500 can be used for this purpose. In particular, smartphone 500 can receive attributes M from vehicle 100 and send them to backend server 300. Furthermore, smartphone 500 can receive data records from the approval list and / or determined approval information F from backend server 300 and transmit them to vehicle 100.

[0156] In the exemplary embodiment described in Figure 3a, data records are retrieved once from the backend server 300 and stored in the database 111 of the approval module 110 for further use. According to the invention, an update of the database 111 can also occur regularly or be triggered by other events. For example, the update can be triggered on the vehicle side if, for example, relevant changes to the vehicle configuration have been detected. An update can also be triggered if a service is requested for which no suitable data record is available in the internal database, or if no data record is available that would lead to permitted execution. Finally, the approval module can also be configured to perform updates regularly, for example, weekly.Additionally, certain services may require an update to be performed before each execution and the service will only run when updated release information is available.

[0157] The terms "module," "unit," "component," etc., used in this description describe units that can, in principle, be implemented either in hardware or software, regardless of how this is stated in this description. Likewise, the described units can be implemented in any combination or separately from one another without deviating from the essence of the invention.

[0158] At this point it should be noted that all of the parts described above are to be regarded individually - even without additional features described in the respective context, even if these have not been explicitly identified as optional features in the respective context, e.g. by using: in particular, preferably, for example, e.g., if necessary, round brackets, etc. - and in combination or any sub-combination as independent embodiments or further developments of the invention, as defined in particular in the introduction to the description and the claims. Deviations from this are possible. Specifically, it should be noted that the word in particular or round brackets do not identify any features that are mandatory in the respective context.

[0159] List of reference symbols

[0160] 100 vehicles

[0161] 105 On-board network no release module

[0162] 111 Database

[0163] 120 communication module

[0164] 130 GPS module

[0165] 150 auxiliary heating

[0166] 160 Auxiliary heating control unit

[0167] 165 insulation module

[0168] 170 head unit

[0169] 200 Cloud service

[0170] 300 backend servers

[0171] 400 release list

[0172] 411 - 415 data set

[0173] 500 smartphones

[0174] F Release information

[0175] I_ext Identification identifier of the external service component

[0176] IJ nt Identification code of the vehicle-side service component

[0177] M,M' characteristics

[0178] SI registration step

[0179] S2 Determination of property characteristics

[0180] S3 Transfer of property characteristics

[0181] S4 Determining data sets

[0182] S5 Transfer of data records

[0183] S6 Determination of the release information (by release module)

[0184] S7 Determine the release information (via backend server)

[0185] S8 Transfer of release information

[0186] S9 Releasing an interface

Claims

Claims 1. A method for providing a service in a vehicle (100), wherein the service is provided using at least one vehicle-side service component (160) and one external service component (200), in particular as a cooperative service provision, wherein the method comprises the following steps: Receiving a request regarding the provision of the service in the Vehicle (100); Determining an identification identifier (I_ext) of the external service component (200) and / or an identification identifier (IJnt) of the vehicle-side service component (160); Determining release information (F) for cooperative service provision for the vehicle (100), using a release list (400) and the identification identifier of the vehicle-side service component (160) and / or the identification identifier of the external service component (200); Release at least one (vehicle-side) interface for the vehicle-side service component (160) and / or for the external service component (200) by a release module (110) of the vehicle (100) in order to provide the service, in accordance with the release information (F).

2. The method according to claim 1, characterized in that the determination of the release information (F) is carried out by the release module (110) and that the method further comprises the following steps: Determining characteristics (M) of cooperative service provision; Transfer of the property characteristics (M) to a backend server (300) using a mobile device and / or a communication module (120) of the vehicle (100), wherein the release list (400) is stored on the backend server (300); Retrieving records (411-415) from the release list (400) using the property characteristics (M); Transfer of the data records (411-415) of the release list (400) from the backend server (300) to the vehicle (100), in particular by means of a mobile device (500) and / or by means of a communication module (120) of the vehicle (100); Transferring the data records (411-415) into a database (111) of the Release module (110), wherein the release module (110) further determines the release information (F) using the data records (411-415) and using the property characteristics (M) of the cooperative service provision.

3. Method according to one of the preceding claims, characterized in that the determination of the release information (F) is carried out by a backend server (300) and that the method further comprises the following steps: Determining characteristics (M) of cooperative service provision; Transfer of the property characteristics (M) to a backend server (300) using a mobile device (500) and / or using a communication module (120) of the vehicle (100), wherein the release list (400) is stored on the backend server (300); Determining the release information (F) by the backend server (300), furthermore using the property characteristics (M) of the cooperative service provision; Transfer of the release information (F) from the backend server (300) to the vehicle (100), in particular by means of a mobile device (500) and / or by means of a communication module (120) of the vehicle (100); Transferring the release information (F) to the release module (110), the procedure optionally further comprising the following step: Evaluation of the validity of the release information (F) by the release module (110), in particular using the currently current property characteristics (M) of the cooperative service provision.

4. Method according to one of the preceding claims, characterized in that releasing the at least one interface according to the release information (F) comprises at least one of the following steps: Activating a software interface, in particular for use by a vehicle-side service component (160); Activating a hardware component of the vehicle (100); Starting a software process in the vehicle (100); Activating a communication interface, in particular vehicle network interface or network port, and / or network connection in the vehicle (100); Activating and / or extending an interface, in particular a communication interface, to the external service component (200); Providing the release information (F) in the vehicle (100).

5. Method according to one of the preceding claims, characterized in that the service is a control of a parking heater (150), a horn or a locking system of the vehicle (100).

6. A method according to one of the preceding claims, characterized in that at least one, preferably each, data record (411-415) of the release list (400) comprises one or more of the following data: a set of attributes of vehicle-side service components; a set of attributes of external service components; a set of identification identifiers of services and / or service scopes; a set of attributes of the vehicle (100), in particular vehicle identification, hardware and software components, vehicle equipment, country of vehicle registration, country of vehicle user, geographical location of the vehicle; a set of attributes of an execution environment of the external service component (200), in particular versions of interfaces, hardware, operating system;and determining the release information (F) includes a comparison with at least one attribute of the vehicle-side service component (160) and / or at least one attribute of the external service component (200) or its execution environment and / or at least one attribute of the vehicle (100).

7. Method according to one of the preceding claims, characterized in that at least one data record (411-415) of the release list (400) further comprises a The validity period specification includes and the determination of the release information (F) includes a comparison of the validity period specification of the data record (411-415) with a system time of the vehicle (100) and / or a system time of an execution environment of the external service component (200) and / or a system time provided online or via satellite.

8. Method according to one of the preceding claims, characterized in that at least one data record (411-415) of the release list (400) further comprises a geographical area specification and the determination of the release information (F) comprises a comparison of the geographical area specification of the data record (411-415) with a (geographic) location of the vehicle (100) and / or a (geographic) location of an execution environment of the external service component (200).

9. Method according to one of the preceding claims, characterized in that at least one data record (411-415) of the release list (400) and / or the release information (F) is digitally signed and the method further comprises the following step: Verify at least one digital signature of a data record (411-415) and / or one digital signature of the release information (F) by the release module (110).

10. Method according to one of the preceding claims, characterized in that at least one data record (411-415) of the release list (400) includes at least one test condition, in particular absence of an error code in the vehicle (100) or validity of a digital signature of a software module of the vehicle (100), and the method further comprises the following step: Determine whether the test condition in the vehicle (100) is met.

11. Computer-readable storage medium containing instructions that cause at least one processor to implement a method according to any of the preceding claims when the instructions are executed by the at least one processor.

12. Release module (110) in a vehicle (100), wherein the release module (110) is preferably configured to perform one or more of the following steps: Determining characteristics (M) of a cooperative service provision in a vehicle (100), in particular between a vehicle-side service component (160) and an external service component (200); Receiving and / or sending a request regarding the provision of a service in the vehicle (100), wherein the request includes an identification identifier (I_ext) of an external service component (200) and / or an identification identifier (IJnt) of a vehicle-side service component (160); Receiving data records (411-415) of a release list (400) from a mobile device (500) and / or a communication module (120) of the vehicle (100) and storing the data records (411-415) in a database (111) of the release module (110); Determining and / or receiving release information (F) for cooperative service provision using a release list (400), in particular also using the current characteristics (M) of the cooperative service provision; Releasing at least one (vehicle-side) interface for the vehicle-side service component (160) and / or for the external service component (200) to provide the service, in accordance with the release information (F), in particular by means of an isolation module according to claim 13; Storing any detected or received release information (F), especially for later use; Checking a release information (F) for validity, in particular temporal validity and / or geographical validity, possibly followed by a request for new release information (F); Re-evaluation of the characteristics (M) of the cooperative service provision and checking whether the validity of a previously stored Release information (F) regarding the newly determined property characteristics (M) still exists.

13. Isolation module (165) in a vehicle (100), wherein the isolation module is configured to cause at least one control unit and / or software component of the vehicle (100) to activate or deactivate an interface for the vehicle-side service component (160) and / or for the external service component (200), in particular by at least one of the following: Allowing or preventing the execution of software, in particular at the operating system level of the vehicle (100) or the vehicle-side service component (160); Forwarding or absorbing data and / or control commands, in particular via a communication path (105) between vehicle (100) and vehicle-side service component (160) and / or between vehicle-side service component (160) and external service component (200); Sending fault codes, in particular via a communication path (105) between vehicle (100) and vehicle-side service component (160) and / or between vehicle-side service component (160) and external service component (200), wherein the isolation module (165) is preferably connected to a release module (110), in particular according to claim 12.

14. Vehicle (100) comprising: a release module (110) according to claim 12 and at least one isolation module according to claim 13, in particular for implementing one of the methods according to any one of claims 1 to 10; at least one vehicle-side service component (160); a communication module (120), wherein the vehicle (100) is configured to provide a service using the at least one vehicle-side service component (160) and an external service component (200), in particular as cooperative service provision, wherein the vehicle preferably further comprises: a positioning module (130), in particular a GPS module, and / or a mechanism for determining a system time provided internally or externally to the vehicle.

15. System, in particular for carrying out a method according to any one of claims 1 to 10, comprising: a vehicle (100) according to claim 14; an external service component (200); a backend server (300), wherein the system preferably further comprises a mobile terminal (500) configured to To transfer the characteristics (M) of the cooperative service provision of the vehicle (100) to a backend server (300) and / or to retrieve data records (411-415) of a release list (400) from the backend server (300) and transfer them to a database (111) of the release module (110) and / or to retrieve release information (F) from the backend server (300) and transfer it to the release module (110).

Images