WO2022184563A1

WO2022184563A1 - Method for authorizing a software update, electronic control unit, vehicle, authorizing system

Info

Publication number: WO2022184563A1
Application number: PCT/EP2022/054756
Authority: WO
Inventors: Anto Ajisha Shriny MARIATHANISLAUS; Imaduddeen VALATHOOR NIZAMUDDEEN; Kalpana VENKATESAN; Vaisakh VENUGOPAL
Original assignee: Zf Cv Systems Global Gmbh
Priority date: 2021-03-01
Filing date: 2022-02-25
Publication date: 2022-09-09

Abstract

The invention relates to a method (300) for authorizing a software update (600), in particular firmware update (602), in a vehicle (1000), in particular of a memory (200) of an electronic component (204), via a remote connection (800), in particular a wireless connection (802). According to the invention, the steps are proposed: - checking a geographic update requirement (402) in a geographic checking step (S4), - authorizing the update (600) in an authorizing step (S30) when the geographic update requirement (402) is fulfilled wherein - the geographic update requirement (402) is fulfilled, if the vehicle (1000) is present in an authorized area (420) described by a geofence (410).

Description

Method for authorizing a software update, electronic control unit, vehicle, authorizing system

The invention relates to a method for authorizing a software update according to the preamble of claim 1. The invention further relates to an electronic control unit and a vehicle.

Methods for authorizing a software update are generally known. As software products as well as firmware for hardware component are constantly improved, it is beneficial to update such products and components to the newest available state.

Complex systems such as vehicles, in particular cars or commercial vehicles, comprise up to hundreds of electronic components such as electronic control units which require said updating of their firmware.

An advantageous solution is to conduct a software update over the air, in what is known as an over-the-air update, in particular a firmware over-the-air (FOTA) update, in which the software, in particular firmware, to be updated is transferred via a remote, in particular wireless, data connection to the vehicle comprising the component to be updated. For that purpose, the vehicle preferably comprises a telematics gateway for coordinating the data transfer as well as the authorization and execution of software updates. US 10,834,207 B2 describes a system and a method for updating software in a vehicle in which a server sends the update software to one or more electronic devices in the vehicle, wherein the server may receive the capabilities of the electronic devices in the vehicle, such as the memory, computational, security capabilities, or the like, and tailor the sending of the software update based on the capabilities of the electronic devices.

Still an authorization of an available software, in particular firmware, update is problematic. In US 2019/391800 A an over-the-air (OTA) mobility service platform (MSP) is disclosed that provides a variety of OTA services, including but not limited to: updating software OTA (SOTA), updating firmware OTA (FOTA), client connectivity, remote control and operation monitoring. In some exemplary embodiments, the MSP is a distributed computing platform that delivers and/or updates one or more of configuration data, rules, scripts and other services to vehicles and loT devices. In some exemplary embodiments, the MSP optionally provides data ingestion, storage and management, data analytics, real-time data processing, remote control of data retrieving, insurance fraud verification, predictive maintenance and social media support. Therein location data can be used to determine if a mobility client has entered or exited a geofence (a virtual geographic boundary) to trigger a download of a software package or perform some other location-based service.

However, further authorization should not only legitimate a firmware over-the-air (FOTA) update, but also ensure that said software update is executed under safe conditions. In case any problems occur during the software update, in particular the software update is aborted prior to completion, an error state can result and a normal operation of the vehicle can even become impossible.

It is therefore desirable to address at least one of the above problems.

This is where the invention comes in, with the object to specifically improve the authorization of a software update in particular with respect to safety and reliability. In particular, possible errors occurring during the software update should be anticipated.

In accordance with the invention, the object is solved in a first aspect by a method for authorizing a software update as proposed according to claim 1. The invention starts from providing a software via a remote connection, in particular a wireless connection, for a vehicle, in particular for a memory of an electronic component, wherein a geographic requirement is provided.

In accordance with the invention, a method is proposed for authorizing a software update, in particular a firmware update, in a vehicle, in particular of a memory of an electronic component, via a remote connection, in particular a wireless connection.

In accordance with the invention, a software update is authorized, in particular a firmware update is authorized, comprising: checking the geographic requirement as a geographic update requirement in a geographic checking step, authorizing the update in an authorizing step when the geographic update requirement is fulfilled wherein the geographic update requirement is fulfilled, if the vehicle, in particular described by a vehicle position, is present in an authorized area described by a geofence.

The invention is based on the finding that an over-the-air update is generally advantageous, as it significantly reduces the required effort to perform such updates, in particular in light of the amount of electronic components to be updated in modern vehicles.

However, despite these advantages, the invention includes the finding that there still exists a chance of abnormal events such as errors occurring during a software update of an electronic component in a vehicle. Thereby the invention goes beyond a mere legitimation by means of geofencing, i.e. wherein a geographic requirement is provided. In case of such an abnormal event, it is possible that an exceptional error occurs that cannot be solved on the side of the vehicle and/or user, and such an abnormal event can even result in a state where a normal operation of the vehicle is not possible.

Thus, it is provided to check the geographic requirement as a geographic update requirement in a geographic checking step.

By checking a geographic update requirement and authorizing the software update if the geographic update requirement is fulfilled, it can be ensured that the software update will only be performed when the vehicle is in a certain predefined, in particular authorized, geographic area. By meeting the geographic update requirement, the software update can be executed in a safe way, in particular because a geographic proximity to a means of assistance can be assumed, available for providing technical assistance on the site of the vehicle or even towing of the vehicle in case of an abnormal event. Such means of assistance in particular include vehicle service facilities.

By checking the geographic update requirement prior to authorizing the software update, the occurrence of an abnormal event is advantageously anticipated. A geofence describes a virtual perimeter for an actual geographic area, in particular by means of coordinates, such as two-dimensional coordinates, or by other means such as mobile network cell sites. In particular, a geofence describes, contours or outlines an authorized area. In particular, an authorized area is an area in which a vehicle has to be located to perform the software update safely according to the concept of the invention.

Further developments of the invention can be found in the dependent claims and show particularly advantageous possibilities to realize above-described concept in light of the object of the invention and regarding further advantages. In particular, the electronic component is safety critical, in particular for fulfilling a driving function and/or security function of the vehicle. It is preferably suggested that the authorized area is an area near a vehicle service facility, in particular a stationary service facility such as a vehicle repair shop or a mobile service facility such as a service vehicle. In such a preferred development of the invention, the authorized area implies a proximity to such a vehicle service facility, providing a certain degree of safety in case of errors or abnormal events occurring during the software update, because assistance is near, namely within the authorized area. In particular, the vehicle service facility is qualified for a certain kind of electronic component, vehicle type, or software update. A vehicle service facility further implies any facility qualified to handle, in particular repair, the electronic components and/or software products, and is therefore not limited to conventional, mechanical vehicle repair shops.

In a further preferred development of the invention, it is proposed that the authorized area is located, in particular circularly shaped, around the vehicle service facility. Such shape of an authorized area around the vehicle service facility is a suitable approximation for proximity to said vehicle service facility. A circularly shaped geofence is relatively easy to calculate around a center point, in particular a vehicle service facility. Therefore, the computational effort for calculating a geofence, or even a larger amount of geofences, can be advantageously reduced.

In another preferred development of the invention, it is proposed for the authorized area to be defined by a maximum tolerable approach time required to reach the vehicle service facility, wherein in particular the maximum tolerable approach time is calculated by a navigation system or similar routing calculation means, in particular taking into account current traffic conditions. Such a development advantageously considers additional factors such as individual road conditions and/or traffic conditions when estimating the proximity to a vehicle service facility. For example, a vehicle service for the facility that is close to a vehicle in terms of an air-line distance may take longer to reach because of a traffic jam or a necessary detour. By defining a maximum tolerable approach time to the vehicle service facility, a geofence can be created that describes the actual proximity - in terms of approach time - in a more accurate manner. In particular, in such a development, the maximum tolerable approach time and thus, the geofence, can be updated regularly to take into account changing conditions, such as traffic or road conditions.

In a preferred development, it is proposed that the authorized area is a dynamic authorized area described by a dynamic geofence. With a dynamic geofence, the authorized area and/or the geofence can be adapted to changing conditions. Such a dynamic geofence is in particular suitable when the vehicle service facility is a mobile vehicle service facility such as a service vehicle or a service truck or a mobile service technician. In such cases, a dynamic geofence can be recalculated to adapt to the changing location.

In a preferred development, the following step is proposed: display instructions, in particular directions, on how to reach an authorized area in an instruction displaying step. In particular, this instruction displaying step is executed if the vehicle is not in an authorized area. In particular, this instruction displaying step is executed if the geographic update requirement is not fulfilled. In particular, instructions are displayed on how to reach the nearest authorized area. In particular, instructions are displayed on how to reach the authorized area with the smallest detour from an existing, active route of the vehicle.

In a preferred development, the following steps are proposed: requesting a consent of a user in a consent request step, receiving the consent of the user in a consent receipt step.

Preferably, these steps are performed after the geographic update requirement is fulfilled. Such consent is a further means of authorization, confirming the user's, in particular the driver's, approval before proceeding with the execution of the software update.

In a further preferred development, it is proposed for the update to be authorized when one or more further vehicle update requirements are fulfilled, wherein the vehicle update requirement in particular comprises at least one of the following vehicle parameters: vehicle speed, parking brake status, ignition status. Such checking of further vehicle update requirements is a further means of authorization and advantageously increases the safety, as it can be ensured that the vehicle itself is in a safe condition and does not constitute a possible danger to the user or any other traffic participants.

In a preferred development, the following step is proposed: downloading an installation data item for the software update to a temporary memory storage of the vehicle in a download step, in particular prior to requesting a consent and/or prior to checking for the geographic update requirement. Preferably, the installation data item is downloaded automatically beforehand, in particular without any interaction of the user. After completion of the download, the consent request can be prompted to the user, as the installation data item is locally available in the vehicle and ready to install.

In a preferred development, the following step is proposed: upon authorizing the update: executing the update by installing the installation data item to the memory in an update step. Preferably, the update is automatically executed when the update has been authorized.

In a second aspect of the invention, an electronic control unit, in particular a telematics gateway, is proposed, adapted to perform a method according to the first aspect of the invention.

In a third aspect of the invention, a vehicle is proposed, comprising an electronic control unit according to the second aspect of the invention and/or adapted to perform a method according to the first aspect of the invention. The vehicle in particular is a passenger vehicle or a commercial vehicle.

In a fourth aspect of the invention, an authorizing system is proposed, comprising a server, in particular a cloud server, with an administration application and an application database, and further comprising at least one vehicle according to the third aspect of the invention. It shall be understood that the method according to the first aspect of the invention, the electronic control unit according to the second aspect of the invention, the vehicle according to the third aspect of the invention and the authorizing system according to the fourth aspect of the invention comprise identical or similar developments, in particular as described in the dependent claims. Therefore, a development of one aspect of the invention is also applicable to another aspect of the invention.

These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. The embodiments of the invention are described in the following on the basis of the drawings in comparison with the state of the art, which is also partly illustrated. The latter is not necessarily intended to represent the embodiments to scale. Drawings are, where useful for explanation, shown in schematized and/or slightly distorted form. With regard to additions to the lessons immediately recognizable from the drawings, reference is made to the relevant state of the art. It should be borne in mind that numerous modifications and changes can be made to the form and detail of an embodiment without deviating from the general idea of the invention. The features of the invention disclosed in the description, in the drawings and in the claims may be essential for the further development of the invention, either individually or in any combination.

In addition, all combinations of at least two of the features disclosed in the description, drawings and/or claims fall within the scope of the invention. The general idea of the invention is not limited to the exact form or detail of the preferred embodiment shown and described below or to an object which would be limited in comparison to the object claimed in the claims. For specified design ranges, values within the specified limits are also disclosed as limit values and thus arbitrarily applicable and claimable.

Further advantages, features and details of the invention result from the following description of the preferred embodiments as well as from the drawings, which show in: Fig. 1 a schematic illustration of a preferred embodiment of a method according to the concept of the invention,

Fig. 2 a schematic illustration of a vehicle with an electronic control unit, in particular a telematics gateway, adapted to perform a method according to the concept of the invention,

Fig. 3 structural overview of an authorizing system for executing the method according to the concept of the invention Fig. 4 an illustration of the method according to the concept of the invention with a vehicle and a first and second geofence.

Fig. 1 schematically shows a method according to the concept of the invention. Fig. 2 provides a corresponding structural overview of the components performing the method shown in Fig. 1 , in particular an authorizing system hereinafter, reference is made in particular to Fig. 1 and Fig. 2.

In a downloading step S2, an installation data item 902 for a flash update 600 is downloaded from a server 1300, in particular from a cloud server 1302, to a temporary memory 280 of a vehicle 1000. The downloading step S2 is preferably initiated by the electronic control unit 700 upon a notification of the server 1300, in particular when a new version of the installation data item 902 is available. The temporary memory 280 can be part of or, as shown here, connected to, an electronic control unit 700 of the vehicle 1000. The electronic control unit 700 is preferably a telematics gateway 702, as shown here.

Once the installation data item 902 has been downloaded, the data required for performing the update 600 is locally available and therefore ready for installation. Preferably, the installation data item 902 comprises one or more files.

Subsequently, a geographic update requirement 402 is checked in a geographic checking step S4. The checking of the geographic update requirement 402 preferably comprises transmitting a vehicle position 1040 of the vehicle 1000 to the server 1300 and subsequently checking, in particular on the side of the server 1300, whether the vehicle position 1040 is within a geofence 410. In other embodiments, the geographic checking step S4 can also be performed on the side of the vehicle 1000, in particular by the electronic control unit 700.

At a subsequent branch V1 , it is checked whether the geographic update requirement 402 is fulfilled. If the vehicle position 1040 is within a geofence 410, the geographic update requirement 402 is fulfilled. In preferred embodiments, the fulfilled geographic update requirement 402. comprises a corresponding digital token 403. Preferably, the digital token 403 is issued by the server 1300 and transmitted to the vehicle 1000 when the geographic update requirement 402 is considered fulfilled, where it is received by the electronic control unit 700. The digital token 403 can be a digital certificate or similar digital authentication means. In other embodiments that are not shown here, at least one geofence 410 is transmitted to the vehicle 1000 via the remote connection 800 and the geographic update requirement 402 is checked locally in the vehicle 1000, in particular by the electronic control unit 700.

If the geographic update requirement 402 is not fulfilled, in particular if the vehicle position 1040 is not within the geofence 410, an instruction displaying step S6 is performed. In the instruction displaying step S6, instructions 422 are displayed, in particular directions 424, on how to reach an authorized area 420 in order to meet the geographic update requirement 402. Preferably the instructions 422 are displayed to a user 10, in particular on a mobile device 12 of the user 10 or a graphical user interface 16 in the vehicle 1000 or a similar displaying or interface device. The user 10 is in particular the operator of the vehicle 1000. The instructions 422 can preferably comprise directions 424 in the style of instructions of a vehicle navigation system.

In optional embodiments, the method 300 can comprise a cyclical retrial step S7, configured to, in particular repetitively, execute the geographic checking step S4 again after a predefined time interval and/or after a predefined distance traveled by the vehicle 1000. With such a cyclical retrial step S7, a detour of the vehicle 1000 for approaching an authorized area 420 is prevented, which is particularly advantageous in cases were performing the software update 600 is not urgent. In such cases, the method 300 with the cyclical retrial step S7 tries to fulfill the geographic update requirement 402 at a different point in time.

In optional embodiments, the method 300 can comprise a consent request step S10 requesting a consent 472 of the user 10, and a subsequent consent receipt step S12, receiving the consent 472 of the user 10. Preferably, a request 440 for the consent 472 is sent by the server 1300 to the user 10, in particular to the mobile device 12 of the user 10, wherein the consent 472 is issued by the user 10, preferably via the mobile device 12.

In preferred embodiments of the method 300, it is checked whether further vehicle update requirements 460 are fulfilled, in particular by checking one or more vehicle parameters 462, in a vehicle requirement step S24.

The fulfillment of one or more vehicle update requirements 460 can constitute a further requirement to be fulfilled for authorizing the update 600. As an example, one vehicle update requirement 460 can be that a vehicle speed 464 of the vehicle 1000 has to be 0 in order for the software update 600 to be authorized. This way, it is ensured that the car is not moving during the software update 600. As a further example, an alternative or additional further vehicle update requirement is that a parking brake status 466 of a parking brake of the vehicle 1000 has to be "engaged" in order for the updated 600 to be authorized. This way, it is assured that the car is being held in a braked position during the software update 600. As a further example, an alternative or additional further vehicle update requirement 460 is that an ignition status 468 of the vehicle 1000 has to be in the status “on” in order for the software update 600 to be authorized. This way, it is ensured that the electronic systems of the vehicle 1000, in particular the electronic control unit 700, are supplied with electric energy. Preferably, the geographic update requirement 402, the consent 472 and the one or more vehicle update requirements 460 are mandatory, i.e. cumulative, requirements, meaning all of them have to be fulfilled in order for the software update 600 to be authorized. Accordingly, in Fig. 1 , these one or more vehicle update requirements 460 are connected by an AND operator 436 to the geographic update requirement 402, and particularly the consent 472, in the diagram. In case of more than one vehicle update requirement 460, all vehicle update requirements 460 are preferably connected by an AND operator as well, making each vehicle updated requirement 460 a mandatory requirement for the authorization of the update 600.

When the geographic update requirement 402 is fulfilled - and in optional embodiments, when the consent 472 is received and/or the at least one vehicle update requirement 460 is fulfilled - the update 600 is authorized in an authorizing step S30. Subsequently, when the update 600 has been authorized, the update 600 is executed by installing the installation data item 902 to the memory 200 in an update step S40.

Fig. 2 shows a schematic view of a vehicle 1000 comprising an electronic control unit 700, here in the form of a telematics gateway 702, adapted to perform a method for authorizing a software update according to the concept of the invention. The vehicle 1000 is in particular a passenger vehicle 1002 or, as shown here, a commercial vehicle 1004 such as a truck. In the scope of the invention, other vehicles can be used such as agricultural vehicles, construction vehicles, or other. The telematics gateway 702 is connected via a signal line 206 to an electronic component 204, which is to be updated. The electronic component 204 is in particular an electronic control unit and comprises a memory 200, in particular in the form of a flash memory 202. The telematics gateway 702 comprises a or is connected to a temporary memory 280, in particular for temporarily storing an installation data item 902 after downloading from a server 1300 via a remote connection 800 in the form of a wireless connection 802, and prior to installing the software update 600. The telematics gateway 702 is preferably connected to an antenna 208 for establishing the remote connection 800 or the wireless connection 802 with the server 1300, in particular a cloud server 1302. The telematics gateway 702 is further connected to or comprises a GPS sensor 740, adapted to provide the current vehicle position 1040 of the vehicle 1000. In particular, the GPS sensor 740 is part of a navigation system 1380.

Fig. 3 shows an authorizing system 1500 with a server 1300, in particular a cloud server 1302, serving as a communication backbone for executing the method 300 according to the concept of the invention. The server 1300 can be accessed by a manager 20, in particular of an OEM, a supplier company, a fleet management company or the like organization, via an administration application 1360. The manager 20 in particular has administrative rights, in particular the right to define geofences 410 and/or authorized areas 420, or to define new or change existing vehicle service facilities 1400. Preferably, geofences 410 and/or authorized areas 420 and/or vehicle service facilities 1400 and/or user profiles 14 of users 10 can be stored in an application database 1380. The manager 20 in particular has administrative rights to the application database 1380.

An exemplified fleet 1100 of vehicles 1000, namely a first vehicle 1000.1 , a second vehicle 1000.2 and a third vehicle 1000.3, is shown wherein these vehicles are connectable to the server 1300 via a remote connection 800, in particular a wireless connection 802 such as a mobile network connection as used in a mobile phone.

The user 10 can communicate with the server 1300, in particular via a mobile device 12. Here, a first user 10.1 as the driver of the first vehicle 1000.1 , with a first mobile device 12.1 of the first user 10.1 , is shown as an example. In particular, the user 10 can receive instructions 422, in particular directions 424, or other relevant information from the server 1300, in particular in the context of authorizing the software update 600. Fig. 4 illustrates the concept of the invention by means of a vehicle 1000. A first authorized area 420.1 defined by a first geofence 410.1 is shown. The first authorized area 420.1 and the first geofence 410.1 respectively, is arranged circular with a radius R around a vehicle service facility 1400, here with a first radius R1 around a first vehicle service facility 1400.1. The first vehicle service facility 1400.1 is a mobile service facility 1406 in the form of a service vehicle 1408. Furthermore, a second authorized area 420.2 defined by a second geofence 410.2 is shown. The second authorized area 420.2 and the second geofence 410.2, respectively, is arranged circularly with a second radius R2 around a second vehicle service facility 1400.2. The second vehicle service facility 1400.2 is a stationary service facility 1402 in the form of a vehicle repair shop 1404.

At a first point in time T1 , the vehicle 1000 is not within an authorized area 420 and its vehicle position 1040, namely a first vehicle position 1040.1 , is not within a geofence 410 defining an authorized area 420. The vehicle 1000 is traveling along the route RT, in particular because it is approaching a destination, for example transporting cargo, or because the user 10 as the driver is following instructions 422, for example after an unsuccessful previous attempt to fulfill the geographic update requirement 402.

At a second point in time T2, the vehicle 1000 is at a second vehicle position 1040.2, which is within the first geofence 410.1. At this second vehicle position 1040.2, the geographic update requirement 402 is fulfilled, so if a geographic checking step S4 was to performed at this vehicle position 1040.2, a software update 600 would be authorized (given that a consent 472 and/or further vehicle update requirements 460 were fulfilled or not necessary).

When a geofence 410 is arranged around a mobile service facility 1406, such as shown here with the first geofence 410.1 , the geofence is preferably configured as a dynamic geofence 416, adapted to change its position and/or shape over time. In particular, a dynamic geofence 416 is adapted to moved together with the mobile service facility 1406 located in its center. Several geofences 420 can overlap, as shown here, to form one larger, composite geofence 420. In other embodiments, several geofences 420 are single geofences 420, not overlapping.

In optional embodiments, a further geofence 420' can be generated on the basis of a maximum tolerable approach time MMT. In particular, for a number of possible positions of a vehicle, and an approximate approach time to a vehicle service facility is calculated. Such approximate approach time can be calculated by a navigation system or similar routing algorithm. Those positions with an approach time less than the maximum tolerable approach time MMT are considered to be inside the geofence. In particular, such a further geofence 420' can be provided alternatively or in addition to the geofences 420 described above.

List of reference signs (part of the description)

10 user

10.1 first user

12 mobile device

12.1 first mobile device

14 user profile

16 graphical user interface

20 manager

200 memory

202 flash memory

204 electronic component

206 signal line

208 antenna

280 temporary memory

300 method

402 geographic update requirement

403 digital token

410 geofence

410.1.410.2 first, second geofence

416 dynamic geofence

420 authorized area

420.1. 420.2 first, second authorized area

422 instructions

424 directions

436 AND-operator

440 request for consent

460 vehicle update requirement

462 vehicle parameters

464 vehicle speed

466 parking brake status

468 ignition status

472 consent 600 flash update 700 electronic control unit 702 telematics gateway 740 GPS sensor 800 remote connection 802 wireless connection 902 installation data item 1000 vehicle

1000.1 , 1000.2, 1000.3 first to third vehicle 1002 passenger vehicle

1004 commercial vehicle 1040 vehicle position

1040.1 , 1040.2 first, second vehicle position 1100 fleet

1300 server 1302 cloud server 1360 administration application 1380 navigation system 1400 radius

1400.1 , 1400.2 first, second vehicle service facility 1402 stationary service facility

1404 vehicle repair shop 1406 mobile service facility 1408 service vehicle 1500 authorizing system

MMT maximum tolerable approach time R radius

RT route S2 download step S4 geographic checking step

56 instruction displaying step

57 cyclical retrial step S10 consent request step S12 consent receipt step S24 vehicle requirement step S30 authorizing step S40 update step

Claims

1. Method (300) for providing a software via a remote connection (800), in particular a wireless connection (802), for a vehicle (1000), in particular for a memory (200) of an electronic component (204), wherein a geographic requirement is provided, characterized in that, a software update (600) is authorized, in particular a firmware update (602) is authorized, comprising: checking a geographic requirement as a geographic update requirement (402) in a geographic checking step (S4), authorizing the update (600) in an authorizing step (S30) when the geographic update requirement (402) is fulfilled, wherein the geographic update requirement (402) is fulfilled if the vehicle (1000) is present in an authorized area (420) described by a geofence (410).

2. Method (300) according to claim 1 , characterized in that the authorized area (420) is an area near a vehicle service facility (1400), in particular a stationary service facility (1402) such as a vehicle repair shop (1404) or a mobile service facility (1406) such as a service vehicle (1408).

3. Method (300) according to claim 1 or 2, characterized in that the authorized area (420) is located, in particular circularly shaped, around the vehicle service facility (1400), or the authorized area (420) is defined by a maximum tolerable approach time (TTM) required to reach the vehicle service facility (1400), wherein the maximum tolerable approach time (TTM) is calculated by a navigation system (1380), in particular taking into account current traffic conditions (1510).

4. Method (300) according to one of the preceding claims, characterized in that the authorized area (420) is a dynamic authorized area (426) described by a dynamic geofence (416).

5. Method (300) according to one of the preceding claims, characterized by the step: displaying instructions (422), in particular directions (424), on how to reach an authorized area (420) in an instruction displaying step (S6).

6. Method (300) according to one of the preceding claims, further comprising the steps: requesting a consent (402) of a user (10) in a consent request step

(S10), receiving the consent (402) of the user (10) in a consent receipt step

(S12).

7. Method (300) according to one of the preceding claims, characterized in that the update (600) is authorized when one or more further vehicle update requirements (460) are fulfilled, wherein the vehicle update requirement (460) in particular comprises at least one of the following vehicle parameters (462): vehicle speed (464), parking brake status (466), ignition status (468).

8. Method (300) according to one of the preceding claims, further comprising the step: downloading an installation data item (902) for the flash update (600) to a temporary memory storage (280) of the vehicle (1000) in a download step (S2), in particular prior to requesting a consent (402) and/or prior to checking a geographic update requirement (402).

9. Method (300) according to one of the preceding claims, further comprising the step: upon authorizing the update (600): executing the update (600) by installing the installation data item (902) to the memory (200) in an update step (S40).

10. Electronic control unit (700), in particular a telematics gateway (702), adapted to perform a method (300) according to one of the preceding claims.

11. Vehicle (1000), comprising an electronic control unit (700) according to claim 10.

12. Authorizing system (1500), comprising a server (1300), in particular a cloud server (1302), with an administration application (1360) and an application database (1380), and further comprising at least one vehicle (1000) according to claim 11.