In-vehicle system, electronic control device, access authorization policy update method, and program

Abstract

Necessity determination units (S210-S220) determine whether an update required situation in which it is necessary to update an access authorization policy is in effect. State determination units (S240, S250, S270) determine whether a state of a vehicle on which a vehicle-mounted network is mounted is in a safe state where the access authorization policy can be safely updated. When the necessity determination units determine the necessary update situation and the state determination units determine the safe state, update execution units (S260, S280) update the access authorization policy.

Description

Cross - reference to related applications

[0001] This international application claims priority based on Japanese Patent Application No. 2022 - 110649 filed with the Japan Patent Office on July 8, 2022, and incorporates the entire contents of Japanese Patent Application No. 2022 - 110649 by reference into this international application.

Technical Field

[0002] This disclosure relates to a technology for controlling access to resources and information of a vehicle.

Background Art

[0003] Patent Document 1 below describes a technology for restricting access using an access authorization policy when a system detects access to resources and information of a system via a service application in an open platform for a mobile terminal. The access authorization policy defines what "who", "to what", and "what to do" are permitted or prohibited.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

[0005] In the future, in an electronic control system mounted on a vehicle (hereinafter referred to as an in-vehicle system), it is assumed that an unspecified number of third-party service applications will be mounted. Therefore, it is conceivable to restrict access from these unspecified number of service applications using an access authorization policy. Note that the access authorization policy is set according to the reliability of the service application that is the request source of the access, and the characteristics of the resources and information that are the access destination. In addition, in order to meet various needs, as the increase, change, and deletion of service applications are frequently performed, it is expected that the update frequency of the access authorization policy will increase.

[0006] When the access authorization policy in the in-vehicle system is updated, the criteria for permitting / forbidding access change before and after the update. Therefore, depending on the timing of the update, there is a possibility that unexpected operation or non-operation may be induced.

[0007] In one aspect of the present disclosure, a technique for safely implementing an update of an access authorization policy is provided.

[0008] One aspect of the present disclosure is an in-vehicle system including a plurality of functional blocks and a cooperation control unit. The plurality of functional blocks are each mounted on any of a plurality of electronic control devices connected to an in-vehicle network or an external device remotely connected to the in-vehicle network, and are configured to realize functions assigned to each of them. The cooperation control unit is configured to realize cooperation between the plurality of functional blocks.

[0009] The cooperation control unit includes an access control unit, a necessity determination unit, a state determination unit, and an update execution unit.

[0010] The access control unit receives an access request from a source block, which is one of a plurality of functional blocks, to a destination block, which is another one of the plurality of functional blocks. The access control unit determines whether the source block has the access right to the destination block by using an access authorization policy that defines the access rights between the functional blocks. When the access control unit determines that there is an access right, it is configured to transmit the access request to the destination block.

[0011] The necessity determination unit is configured to determine whether it is in a situation that requires an update of the access authorization policy. The state determination unit is configured to determine whether the state of the vehicle equipped with the in-vehicle network is in a safe state where the update of the access authorization policy can be safely performed. The update execution unit is configured to perform the update of the access authorization policy when the necessity determination unit determines that it is in a situation that requires an update and the state determination unit determines that it is in a safe state.

[0012] According to such a configuration, the update of the access authorization policy can be safely performed.

[0013] One aspect of the present disclosure is an electronic control unit mounted on a vehicle. The electronic control unit includes an access control unit, a necessity determination unit, a state determination unit, and an update execution unit. That is, the electronic control unit has a configuration excluding a plurality of functional blocks from the in-vehicle system.

[0014] According to such a configuration, the update of the access authorization policy can be safely performed.

[0015] One aspect of the present disclosure is an access authorization policy update method implemented by an electronic control unit mounted on a vehicle. The access authorization policy defines the access rights between a plurality of functional blocks configured to execute respective determined processes.

[0016] An access authorization policy update method includes determining whether there is a situation to be updated that requires an update of the access authorization policy. The access authorization policy update method includes determining whether the state of a vehicle equipped with an in-vehicle network is in a safe state where the update of the access authorization policy can be safely performed. The access authorization policy update method includes performing an update of the access authorization policy when it is determined that there is a situation to be updated and it is determined that the state is in a safe state.

[0017] According to such a method, the update of the access authorization policy can be safely performed.

[0018] One aspect of the present disclosure is a program for causing a computer to realize the following functions.

[0019] The functions that the program causes the computer to realize include a function of determining whether there is a situation to be updated that requires an update of the access authorization policy. The access authorization policy defines access rights between a plurality of functional blocks configured to execute respective determined processes. The functions that the program causes the computer to realize include a function of determining whether the state of the vehicle is in a safe state where the update of the access authorization policy can be safely performed. The functions that the program causes the computer to realize include a function of performing an update of the access authorization policy when it is determined that there is a situation to be updated and it is determined that the state is in a safe state.

[0020] By executing such a program, the above access authorization policy update method is realized, and as a result, the update of the access authorization policy can be safely performed.

Brief Description of the Drawings

[0021]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Mode for Carrying Out the Invention

[0022] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0023] [1. Configuration] As shown in FIG. 1, the mobility service providing system 1 of the present embodiment includes an in-vehicle system 100 mounted on a vehicle, a cloud server 200, and a user terminal 300. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving power source. The vehicle is not limited to a vehicle having an automatic driving function and a hybrid vehicle, and may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving power source. Hereinafter, the vehicle on which the in-vehicle system 100 is mounted will be simply referred to as a vehicle.

[0024] The in-vehicle system 100 includes one electronic control unit (hereinafter, ECU) 2, a plurality of ECUs 3, a plurality of ECUs 4, an in-vehicle communication device 5, and an in-vehicle communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0025] The ECU 2 realizes coordinated control as a whole vehicle by integrating a plurality of ECUs 3.

[0026] The ECU3 is provided for each domain classified by the functions in the vehicle, and mainly executes the control of a plurality of ECUs4 existing within that domain. Each ECU3 is connected to the subordinate ECU4 via a separately provided lower-layer network. For the lower-layer network, for example, Controller Area Network (hereinafter referred to as CAN) is used. CAN is a registered trademark. The ECU3 has a function of centrally managing access rights to subordinate ECUs4 and performing user authentication and the like. The domains are, for example, power train, body, chassis, and cockpit, etc.

[0027] The ECUs4 connected to the ECU3 belonging to the power train domain include, for example, the ECU4 that controls the engine, the ECU4 that controls the motor, and the ECU4 that controls the battery, etc.

[0028] The ECUs4 connected to the ECU3 belonging to the body domain include, for example, the ECU4 that controls the air conditioner and the ECU4 that controls the door, etc.

[0029] The ECUs4 connected to the ECU3 belonging to the chassis domain include, for example, the ECU that controls the brake and the ECU4 that controls the steering, etc.

[0030] The ECUs4 connected to the ECU3 belonging to the cockpit domain include, for example, the ECU4 that controls the display of the meter and navigation, and the ECU4 that controls the HMI device7 operated by the vehicle occupants. HMI is the abbreviation of Human Machine Interface.

[0031] The vehicle external communication device5 performs data communication with vehicle external devices such as the cloud server200 and the user terminal300 via a wide area wireless communication network.

[0032] The in-vehicle communication network 6 includes CAN with Flexible Data Rate (hereinafter referred to as CAN FD) and Ethernet. Ethernet is a registered trademark. CAN FD bus-connects the ECU 2 with each ECU 3 and the vehicle exterior communication device 5. Ethernet individually connects between the ECU 2, each ECU 3, and the vehicle exterior communication device 5. The ECU 2 may include an Ethernet switch for switching the Ethernet to be used.

[0033] The ECU 2 is an electronic control device mainly configured around a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, etc. Various functions of the microcomputer are realized by the CPU 2a executing a program stored in a non-transitory tangible recording medium. In this example, the ROM 2b corresponds to the non-transitory tangible recording medium storing the program. Further, by executing this program, a method corresponding to the program is executed. Note that part or all of the functions executed by the CPU 2a may be configured hardware-wise by one or a plurality of ICs or the like. Also, the number of microcomputers constituting the ECU 2 may be one or plural.

[0034] Each of the ECU 3, the ECU 4, and the vehicle exterior communication device 5 is also an electronic control device mainly configured around a microcomputer including a CPU, a ROM, a RAM, etc. Also, the number of microcomputers constituting the ECU 3, the ECU 4, and the vehicle exterior communication device 5 may be one or plural.

[0035] Hereinafter, when the ECU 2, the ECU 3, the ECU 4, and the vehicle exterior communication device 5 are not particularly distinguished, they are referred to as in-vehicle devices 2 to 5.

[0036] [2. Functional Configuration] The software installed in in-vehicle devices 2 to 5 belonging to the in-vehicle system 100 is constructed, for example, in accordance with AUTOSAR. AUTOSAR is an architecture for autonomous driving and is the abbreviation of AUTomotive Open System Architecture. AUTOSAR provides functions not only for communication between software components (hereinafter referred to as SW-C) implemented to realize various applications, but also for connection to the cloud and security, etc. SW-C is software that is componentized to realize a certain function. An application program includes one or more SW-C. Note that the software of the mobility service providing system 1 does not necessarily have to be constructed in accordance with AUTSAR.

[0037] Each of the in-vehicle devices 2 to 5 includes a platform. The platform provides an environment for executing SW-C described in a hardware-independent format.

[0038] The platform includes a runtime environment (hereinafter referred to as RTE) and basic software (hereinafter referred to as BSW). RTE is an interface that connects SW-C to each other and between SW-C and BSW. BSW is a layer that connects hardware and SW-C and includes an OS, driver, middleware, etc. The functions of BSW are divided into fine-grained modules. The functions of each module are provided to SW-C via an Application Programming Interface (hereinafter referred to as API).

[0039] As shown in FIG. 2, the in-vehicle devices 2 to 5 include a service function block group 21 as a set of service applications (hereinafter referred to as service apps) that operate on the platform. A service app is an application that receives a request from a client, processes it, and returns a result. Each individual service app is composed of one or more SW-C. The service app may be implemented not only in any of the in-vehicle devices 2 to 5, but also in an external device that is remotely connected to the in-vehicle communication network 6 via an out-of-vehicle communication device 5 such as a cloud server 200.

[0040] The service function block group 21 includes service apps (hereinafter referred to as OEM apps) provided by an Original Equipment Manufacturer (hereinafter referred to as OEM). The OEM is a vehicle manufacturer that manufactures vehicles. The OEM apps may include apps developed by the OEM itself and apps developed by other vendors. The service function block group 21 may include service apps (hereinafter referred to as 3rd apps) provided by a third party. The third party is the owner of the vehicle and a third party other than the OEM. Examples of the third party include data utilization operators that provide services by collecting data from the vehicle.

[0041] The platform includes a control function block group 22, a data function block group 23, and an API gateway 30.

[0042] The control function block group 22 includes an API that receives commands related to the movement of the vehicle, and is a set of service apps that overall control the commands received by the API to achieve coordinated vehicle control. The control function block group 22 outputs various commands to in-vehicle devices 3 to 5 where entities that execute control based on the commands exist via an in-vehicle communication network 6. Note that the control function block group 22 may have a function of converting various commands (i.e., API access requests) from the service function block group 21 expressed in a vehicle-independent format into commands expressed in a vehicle-dependent format.

[0043] The data function block group 23 is a set of service apps including an API for handling vehicle data of the in-vehicle devices 2 to 5. The data function block group 23 may have an API that provides a function of abstracting and accumulating vehicle data expressed in a vehicle-dependent format supplied from each of the in-vehicle devices 2 to 5 into a vehicle-independent format. The data function block group 23 may have an API that provides a function of uploading the accumulated vehicle data to a cloud server 200 via an out-of-vehicle communication device 5.

[0044] Hereinafter, the APIs provided by the service applications belonging to the control function block group 22 and the data function block group 23 are referred to as vehicle APIs. The vehicle APIs may include an API that provides a function of acquiring an access authorization policy, which will be described later, from a cloud server 200 or the like via the vehicle external communication device 5. The vehicle APIs may include an API that provides a function of communicating with the user terminal 300 via the vehicle external communication device 5. The vehicle APIs may include an API that provides a function of providing information to the occupant and receiving an input operation by the occupant via the HMI device 7 provided in the vehicle. The vehicle APIs may include an API that provides a function of acquiring information necessary for determining the presence or absence of an occupant from the occupant recognition sensor 8 provided in the vehicle. The occupant recognition sensor 8 may be a camera that captures the interior of the vehicle compartment, or may be a pressure sensor that detects the load applied to the seat.

[0045] The API gateway 30 is configured by using the function of a virtual function bus (hereinafter, VBF). The VBF is middleware that enables communication between SW-Cs and communication between an SW-C and the BSW without being aware of hardware, communication protocols, etc., and is also referred to as a software bus. Communication between SW-Cs refers to access from an SW-C to an API provided by another SW-C, which is performed between service applications belonging to the service function block group 21. Communication between an SW-C and the BSW refers to access from an SW-C to a vehicle API, which is performed between a service application belonging to the service function block group 21 and a service application belonging to the control function block group 22 and the data function block group 23. Hereinafter, it will be described assuming that an SW-C and a service application have a one-to-one correspondence.

[0046] When a service application uses the functions provided by the control function block group 22 and the data function block group 23, it transmits an API access request, which is an access request to the vehicle API. The API access request includes at least a process ID of the service application that is the source (hereinafter, source application) and an API-ID, which is information that uniquely identifies the vehicle API that is the destination (hereinafter, destination API).

[0047] [3. Access Restriction Mechanism] The API gateway 30 is provided in the platforms of all in-vehicle devices 2 to 5 where any of the service function block group 21, the control function block group 22, and the data function block group 23 may be installed.

[0048] The API gateway 30 includes an information storage unit 31, an access control unit 32, a vehicle determination unit 33, a boarding determination unit 34, and a policy update unit 35.

[0049] Stored in the information storage unit 31 are an access authorization policy 311, a correspondence table 312, and user information 313. The correspondence table 312 may be stored in the RAM 2c. The access authorization policy 311 and the user information 313 may be stored in the ROM 2b. However, the access authorization policy 311 and the user information 313 may be stored in the non-volatile RAM 2c.

[0050] The access authorization policy 311 is a set of information for determining the presence or absence of access rights from a service application to a vehicle API. The access authorization policy 311 is, for example, downloaded from the cloud server 200 using the function of a service application belonging to the data function block group 23 and stored in the information storage unit 31. As shown in FIG. 3, the access authorization policy is represented by, for example, a list defining the presence or absence of access rights from a source application specified by an app ID to a destination API specified by an API-ID.

[0051] The access authorization policy 311 may be designed, for example, in consideration of the perspective of S.F.O.P., which is an attribute defined as a security-protected asset. S is an abbreviation for Safety and means access restrictions on API access that affect safety. F is an abbreviation for Financial and means access restrictions on API access that affect the property of a company or an individual. O is an abbreviation for Operational and means access restrictions on API access that affect the operating performance of a vehicle. P is an abbreviation for Privacy and means access restrictions on API access that affect privacy information.

[0052] The correspondence table 312 includes information that associates a process ID dynamically assigned to a process, which is an execution unit of a program in an operating system (hereinafter referred to as OS), with a unique app ID that a service app executed by the process has. Further, the correspondence table 312 includes information that associates a unique API-ID that each vehicle API has with the process ID of a process assigned to a service app that is an entity that executes the function of the API. The correspondence table 312 is generated by the OS when a process for each service app is generated at the startup of the system.

[0053] Note that by combining the access authorization policy 311 and the correspondence table 312, one table may be generated. Specifically, referring to the association between the app ID and the process ID shown in the correspondence table 312 and the association between the API-ID and the process ID, a table indicating the presence or absence of access authority from the process ID of the source app to the process ID of the destination API may be generated.

[0054] The user information 313 is information arbitrarily set by a vehicle user. For example, the user information 313 stores a contact information for the vehicle user, such as the phone number or email address of the mobile terminal the user possesses, in association with a user ID that identifies the vehicle user. The vehicle user may be the owner of the vehicle or a user who temporarily uses a vehicle such as a shared car.

[0055] When the access control unit 32 receives an API access request, it identifies the application ID of the source application from the process ID indicated in the API access request using the correspondence table 312. Based on the identified application ID and the API-ID of the destination API indicated in the API access request, the access control unit 32 executes an access restriction process to determine the presence or absence of access authority according to the access authorization policy 311. Details of the access restriction process will be described later.

[0056] The vehicle determination unit 33 determines the vehicle state and the battery state according to the request from the policy update unit 35, and provides the determination result to the policy update unit 35. Specifically, the vehicle determination unit 33 uses the APIs provided by the control system function block group 22 to obtain information such as the vehicle speed and the shift lever position, and determines which of the parked, stopped, and running states the vehicle state corresponds to. For example, if the shift lever position is in parking, it is determined that the vehicle is parked. If the shift lever position is other than parking and the absolute value of the vehicle speed is less than a predetermined value (for example, 1 km / h), it is determined that the vehicle is stopped, and if the absolute value of the vehicle speed is greater than or equal to the predetermined value, it is determined that the vehicle is running. In addition, the vehicle determination unit 33 uses the APIs provided by the control system function block group 22 to obtain the battery voltage, and determines whether the battery state is in a normal state or a low voltage state. The low voltage state means that the voltage range is such that the microcomputer that executes the process to realize the function as the API gateway 30 has a possibility of malfunctioning that exceeds a preset allowable value.

[0057] The occupancy determination unit 34 determines the presence or absence of an occupant according to the request from the policy update unit 35, and provides the determination result to the policy update unit 35. Specifically, the occupancy determination unit 34 uses the APIs provided by the control system function block group 22 to obtain the detection result of the occupant recognition sensor 8 and determines the presence or absence of an occupant.

[0058] When a situation where the update of the access authorization policy is necessary is detected, the policy update unit 35 executes the update of the access authorization policy according to the determination results of the vehicle determination unit 33 and the boarding determination unit 34.

[0059] [5. Process] [5-1. Access Restriction Process] The access restriction process executed by the access control unit 32 will be described using the flowchart of FIG. 4. The access restriction process is repeatedly executed when the API gateway 30 is activated.

[0060] In S110, the access control unit 32 determines whether it has received an API access request from the service application. If it has received the API access request, the process proceeds to S120. If it has not received the API access request, it waits by repeating the same step.

[0061] In S120, based on the information indicated in the API access request, the access control unit 32 refers to the access authorization policy 311 to determine whether the source application of the API access request, the source application, has the access right to the destination API. Specifically, first, the access control unit 32 uses the correspondence table 312 to identify the application ID of the source application from the process ID indicated in the API access request. Then, based on the identified application ID and the API-ID of the destination API indicated in the API access request, the access control unit 32 refers to the access authorization policy 311 to determine whether there is an access right from the source application to the destination API.

[0062] In the subsequent S130, if the access control unit 32 determines that the source application has the access right to the destination API, the process proceeds to S140. If it determines that there is no access right, the process proceeds to S150.

[0063] In S140, the access control unit 32 permits the access from the source application to the destination API, that is, transmits the API access request to the destination API and ends the process.

[0064] In S150, the access control unit 32 rejects the access from the source application to the destination API, that is, discards the API access request and ends the process.

[0065] Note that in S150, instead of simply discarding the API access request, the access control unit 32 may confirm with the vehicle user whether the access is allowed or not via the HMI device 7. Then, when the access control unit 32 receives a permission input indicating that the access is permitted via the HMI device 7, the process proceeds to S140. When the access control unit 32 receives a non - permission input indicating that the access is not permitted, the API access request may be discarded.

[0066] [5 - 2. Policy update process] The policy update process executed by the policy update unit 35 will be described using the flowchart of FIG. 5. The policy update process is repeatedly executed when the API gateway 30 is started.

[0067] In S210, the policy update unit 35 determines whether there is un - installed update information. If the policy update unit 35 determines that there is un - installed update information, it assumes that it is a situation requiring update and proceeds to S240. If it determines that there is no un - installed update information, it proceeds to S220.

[0068] In S220, the policy update unit 35 determines whether there is a request to update the access authorization policy. If there is a request to update, it assumes that it is a situation requiring update and proceeds to S230. If there is no request to update, it returns to S210. The update request may be, for example, a notification from the cloud server 200 indicating that a new access authorization policy provided to the in - vehicle system 100 has been uploaded to the cloud server 200.

[0069] In S230, the policy update unit 35 uses an API that provides a function to obtain an access authorization policy via the vehicle external communication device 5 to obtain update information for the access authorization policy from the cloud server 200, and advances the process to S240.

[0070] In S240, the policy update unit 35 obtains the vehicle state via the vehicle determination unit 33.

[0071] In the subsequent S250, the policy update unit 35 determines whether the obtained vehicle state is parking. If the policy update unit 35 determines that it is parking, it shifts the process to S260 on the assumption that it is in a safe state where the update of the access authorization policy can be safely executed, and if it determines that it is not parking, it shifts the process to S270.

[0072] In S260, the policy update unit 35 executes the in-parking update process and ends the process.

[0073] In S270, the policy update unit 35 determines whether the obtained vehicle state is stopped. If the policy update unit 35 determines that it is stopped, it shifts the process to S280 on the assumption that it is in a safe state, and if it determines that it is not stopped, that is, if it is running, it shifts the process to S290 on the assumption that it is not in a safe state.

[0074] In S280, the policy update unit 35 executes the in-stopped update process and ends the process.

[0075] In S290, the policy update unit 35 prohibits the update and ends the process. When the update is prohibited, the update information is retained as uninstalled update information without being deleted.

[0076] [5-3. In-Parking Update Process] The in-parking update process executed by the policy update unit 35 in S260 will be described using the flowchart of FIG. 6.

[0077] In S300, the policy update unit 35 acquires the boarding state via the boarding determination unit 34.

[0078] In the subsequent S310, the policy update unit 35 determines whether the vehicle user is boarding based on the acquired boarding state. If the vehicle user is boarding, the process proceeds to S320; if not, the process proceeds to S350.

[0079] In S320, the policy update unit 35 determines whether a confirmation notice for update has been notified to the vehicle user. If it has been notified, the process proceeds to S340; if not, the process proceeds to S330.

[0080] In S330, the policy update unit 35 uses an API that provides a function to confirm the possibility of updating the access authorization policy via the HMI device 7 to send a confirmation notice for update and ends the process.

[0081] In S340, the policy update unit 35 determines whether a permission input to permit the update of the access authorization policy has been received via the HMI device 7. If the permission input has been received, the process proceeds to S350; if not, the process ends.

[0082] In S350, the policy update unit 35 acquires the battery state via the vehicle determination unit 33.

[0083] In the subsequent S360, the policy update unit 35 determines whether the acquired battery state is a low voltage state. If it is a low voltage state, the process proceeds to S370; if not, the process proceeds to S380.

[0084] In S370, the policy update unit 35 performs a limited update of the access permission policy and ends the process. Specifically, in the access authorization policy, installation is only executed for the part that has been changed from having access rights to having no access rights. The update information other than the updated part is retained as un-installed update information.

[0085] In S350, the policy update unit 35 may obtain not only the battery state but also the operation status of the application during parking. In this case, for example, in S360, when a diagnostic process or a program update process is being executed during parking, if it is determined that the voltage is in a low state, similar to the case where it is determined to be in a low voltage state, the process proceeds to S370, and the update of the access authorization policy may be limitedly performed.

[0086] In S380, the policy update unit 35 executes the installation for all the update information and ends the process. In this case, there is no un-installed update information.

[0087] [5-4. Update Process During Parking] The update process during parking that the policy update unit 35 executes in S280 will be described using the flowchart of FIG. 7.

[0088] In S400, the policy update unit 35 obtains the boarding state via the boarding determination unit 34.

[0089] In the subsequent S410, the policy update unit 35 determines whether the vehicle user is boarding based on the obtained boarding state. If the vehicle user is boarding, the process proceeds to S420. If the vehicle user is not boarding, the process proceeds to S460.

[0090] In S420, the policy update unit 35 determines whether an update confirmation has been notified to the vehicle user. If the update confirmation has been notified, the process proceeds to S440. If the update confirmation has not been notified, the process proceeds to S430.

[0091] In S430, the policy update unit 35 transmits an update confirmation notification via an API that provides a function to confirm the possibility of updating the access authorization policy via the HMI device 7 and ends the process.

[0092] In S440, the policy update unit 35 determines whether it has received a permission input to permit the update of the access authorization policy via the HMI device 7. If it has received the permission input, the process proceeds to S450; if not, the process ends.

[0093] In S450, the policy update unit 35 executes the installation for all of the update information and ends the process. In this case, there is no update information that remains uninstalled.

[0094] In S460, the policy update unit 35 determines whether it has already notified the vehicle user of the update confirmation. If it has already notified the update confirmation, the process proceeds to S480; if not, the process proceeds to S470.

[0095] In S470, the policy update unit 35 uses an API that provides a function to send a notification to confirm the possibility of updating the access authorization policy to the user terminal 300 via the vehicle external communication device 5, sends the update confirmation notification, and ends the process.

[0096] In S480, the policy update unit 35 determines whether it has received a permission notification to permit the update of the access authorization policy from the user terminal 300 via the vehicle external communication device 5. If the policy update unit determines that it has received the permission notification, the process proceeds to S490; if it determines that it has not received the permission notification, the process ends.

[0097] In S490, the policy update unit 35 executes the installation for all of the update information and ends the process. In this case, there is no update information that remains uninstalled.

[0098] That is, in the update process during parking, if the vehicle user is in the vehicle, the vehicle checks whether to update via the HMI device 7. If the vehicle user is not in the vehicle, the vehicle checks whether to update via the pre-registered user terminal 300. Then, the update of the access permission policy (i.e., the installation of update information) is executed only when the confirmation of update permission is obtained.

[0099] [6. Term Correspondence] The service function block group 21, the control function block group 22, and the data function block group 23 in this embodiment correspond to a plurality of function blocks in the present disclosure. The API gateway 30 corresponds to the cooperation control unit in the present disclosure. S210 to S220 correspond to the necessity determination unit in the present disclosure. S240, S250, and S270 correspond to the state determination unit in the present disclosure. S260 and S280 correspond to the update execution unit in the present disclosure. S320 to S330, S420 to S430, and S460 to S470 correspond to the permission confirmation unit in the present disclosure. S340, S440, and S480 correspond to the operation permission unit in the present disclosure. S300 to S310 and S400 to S410 correspond to the passenger determination unit in the present disclosure. S430 corresponds to the first confirmation unit in the present disclosure. S470 corresponds to the second confirmation unit in the present disclosure. S350 to S360 correspond to the battery state monitoring unit in the present disclosure. S370 corresponds to the limited update unit in the present disclosure.

[0100] [7. Effects] According to the embodiment described in detail above, the following effects can be obtained.

[0101] (a) When the update information of the access authorization policy is prepared on the cloud server 200 (i.e., Out-Car) side, in the in-vehicle system 100, when the vehicle state is parked or stopped, the update of the access authorization policy is permitted. Therefore, even if the content of vehicle control changes due to the switching of the access authorization policy, since the change does not occur during the movement of the vehicle, safety can be ensured.

[0102] (b) When the vehicle is stopped, confirm with the vehicle user whether to update, and perform the update when the update permission is confirmed. That is, when the vehicle is stopped, such as waiting for a signal, confirm with the vehicle user whether the vehicle will not start immediately, that is, whether it is a situation suitable for update, so that the update of the access authorization policy can be performed in a safer situation.

[0103] (c) When the vehicle is stopped and confirming with the vehicle user, if the vehicle user is in the vehicle, use the HMI device 7, and if the vehicle user is not in the vehicle, use the pre-registered user terminal 300. Therefore, the intention of the vehicle user can be confirmed by appropriate means according to the boarding situation of the vehicle user.

[0104] (d) When the vehicle is parked, if the vehicle user is in the vehicle, since the vehicle may start moving, confirm with the vehicle user in the same way as when the vehicle is stopped. Also, if the vehicle user is not in the vehicle, since the possibility of the vehicle starting to move is low, omit the confirmation with the vehicle user and execute the update of the access authorization policy. In this way, the confirmation of the vehicle user is only performed in situations where confirmation is necessary, so it is possible to prevent annoying the vehicle user by unnecessary confirmation.

[0105] (e) When the vehicle is parked, the battery is not automatically charged. Therefore, when the battery state is in a low voltage state, not all of the update information is used for the update of the authorization policy, but only the update information that acts on the safe side is used for the update of the authorization policy. After that, when the vehicle is in a state other than parked and the battery can be charged, the remaining update information is used for the update of the authorization policy. Therefore, the power consumption due to the update can be minimized, and it is possible to suppress the occurrence of malfunction (for example, bit error of the update information, etc.) due to voltage drop during the update.

[0106] [8. Other Embodiments] As described above, the embodiments of the present disclosure have been described. However, the present disclosure is not limited to the above-described embodiments and can be implemented with various modifications.

[0107] (a) In the above-described embodiment, the update request is generated when the update information of the access authorization policy is prepared in the cloud server 200. However, the trigger for generating the update request is not limited to when the update information is ready. For example, when an abnormality is detected, an update request for the access authorization policy may be generated. In this case, an access authorization policy for abnormal situations may be prepared in advance in the information storage unit 31, and when an update request due to an abnormality occurs, the access authorization policy may be switched from the normal-time policy to the abnormal-time policy.

[0108] (b) In the above-described embodiment, when confirming with the vehicle user, the HMI device 7 is used if the vehicle user is in the vehicle. However, the user terminal 300 may also be used in the same way when the user is not in the vehicle.

[0109] (c) In the above-described embodiment, when the vehicle state is parked, the confirmation with the vehicle user is performed only when the vehicle user is in the vehicle. However, the confirmation with the vehicle user may be performed always, regardless of whether the vehicle user is in the vehicle or not.

[0110] (d) In the above-described embodiment, when receiving an update request notification from the cloud server 200, the update information of the access authorization policy is acquired from the cloud server 200. For example, the update information may be automatically downloaded from the cloud server 200 to the in-vehicle system 100, and when the download of the update information is confirmed, an update request notification may be generated inside the in-vehicle system 100. In this case, the process of S230 in FIG. 5 is omitted.

[0111] (e) In the above embodiment, the update of the access authorization policy according to the vehicle state, etc. is applied to all APIs. However, it may be applied only to the access authorization policy regarding the APIs provided by the control system function block group 22 involving the operations of sensors and actuators. In this case, regarding the access authorization policy regarding the APIs provided by the data system function block group 23 used for data acquisition, etc., if there is uninstalled update information, the update process may be performed regardless of the vehicle state, etc.

[0112] (f) The in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied by a computer program. Alternatively, the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be implemented by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Or, the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be implemented by one or more dedicated computers configured by a combination of a processor and a memory programmed to execute one or more functions and a processor configured by one or more hardware logic circuits. Further, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executable by a computer. The method for realizing the functions of each part included in the in-vehicle devices 2 to 5 does not necessarily include software, and all of its functions may be realized using one or more hardware.

[0113] (g) A plurality of functions of one component in the above embodiment may be realized by a plurality of components, or one function of one component may be realized by a plurality of components. Also, a plurality of functions of a plurality of components may be realized by one component, or one function realized by a plurality of components may be realized by one component. Also, a part of the configuration of the above embodiment may be omitted. Also, at least a part of the configuration of the above embodiment may be added to or replaced with the configuration of another above embodiment.

[0114] (h) In addition to the in-vehicle system 100 described above, the present disclosure can also be realized in various forms such as a system having the in-vehicle system 100 as a component, a program for causing a computer to function as the in-vehicle system 100, and a non-transitory physical recording medium such as a semiconductor memory storing this program.

[0115] [Technical idea disclosed in this specification] [Item 1] A plurality of functional blocks, each of which is mounted on any one of a plurality of electronic control units respectively connected to an in-vehicle network or an external device remotely connected to the in-vehicle network, and each of which is configured to execute a determined process; A cooperation control unit configured to realize cooperation between the plurality of functional blocks; Comprising; The cooperation control unit: When receiving an access request from a source block, which is one of the plurality of functional blocks, to a destination block, which is another one of the plurality of functional blocks, using an access authorization policy that defines access rights between the functional blocks, determines whether the source block has the access right to the destination block, and when it is determined that the source block has the access right, is configured to transmit the access request to the destination block, an access control unit; A necessity determination unit configured to determine whether there is a situation where it is necessary to update the access authorization policy; A state determination unit configured to determine whether the state of a vehicle equipped with the in-vehicle network is in a safe state where the update of the access authorization policy can be safely performed; An update execution unit configured to update the access authorization policy when it is determined by the necessity determination unit that there is a situation where it is necessary to update, and when it is determined by the state determination unit that the vehicle is in the safe state; An in-vehicle system comprising.

[0116] [Item 2] The in-vehicle system according to Item 1, The update execution unit: A permission confirmation unit configured to confirm whether there is permission from a vehicle user to perform the update of the access authorization policy; An operation permission unit configured to permit the operation of the update execution unit when the permission of the vehicle user is confirmed by the permission confirmation unit; An in-vehicle system further comprising

[0117] [Item 3] The in-vehicle system according to Item 2, wherein the permission confirmation unit is configured to confirm whether there is permission from the vehicle user when it is determined by the necessity determination unit that the system is in the update-required state and it is determined by the state determination unit that the system is in the safe state. An in-vehicle system.

[0118] [Item 4] The in-vehicle system according to Item 2 or Item 3, wherein the update execution unit further comprises an occupant determination unit configured to determine whether there is an occupant in the vehicle, and the permission confirmation unit comprises a first confirmation unit configured to confirm the permission of the vehicle user via an HMI device installed in the vehicle when the occupant determination unit determines that there is an occupant, and a second confirmation unit configured to confirm the permission of the vehicle user via a pre-registered user terminal when the occupant determination unit determines that there is no occupant. An in-vehicle system comprising

[0119] [Item 5] The in-vehicle system according to any one of Items 1 to 4, wherein the update execution unit further comprises a battery state monitoring unit configured to monitor the state of a battery mounted on the vehicle, and a limited update unit configured to partially perform the update of the access authorization policy when the state of the battery is in a low voltage state in which the operation of the update execution unit may become unstable. An in-vehicle system further comprising

[0120] [Item 6] The in-vehicle system according to any one of items 1 to 5, wherein the safe state is a state in which the vehicle is parked or stopped In-vehicle system.

[0121] [Item 7] The in-vehicle system according to any one of items 1 to 6, wherein when there is update information of the access authorization policy, the necessity determination unit determines that it is a situation to be updated In-vehicle system.

[0122] [Item 8] The in-vehicle system according to any one of items 1 to 7, wherein when the necessity determination unit detects an abnormality in the vehicle, the necessity determination unit determines that it is a situation to be updated In-vehicle system.

[0123] [Item 9] An electronic control device mounted on a vehicle, when receiving an access request from a source block, which is one of a plurality of functional blocks configured to execute respective determined processes, to a destination block, which is another one of the plurality of functional blocks, determines the presence or absence of the access authority of the source block with respect to the destination block using an access authorization policy that defines access authorities between the plurality of functional blocks, and when it is determined that the access authority exists, an access control unit configured to transmit the access request to the destination block; a necessity determination unit configured to determine whether or not it is in a situation to be updated that requires updating the access authorization policy; a state determination unit configured to determine whether or not the state of the vehicle is in a safe state in which the update of the access authorization policy can be safely performed; an update execution unit configured to perform the update of the access authorization policy when it is determined by the necessity determination unit that it is in a situation to be updated and it is determined by the state determination unit that it is in a safe state; An electronic control unit comprising

[0124] [Item 10] The electronic control unit according to Item 9, wherein the necessity determination unit is configured to determine that it is a situation to be updated when it is a first situation where update information of the access authorization policy exists and when it is a second situation where an abnormality of the vehicle is detected; the update execution unit is configured to update the access authorization policy for normal use using update information obtained from an external device remotely connected to an in-vehicle network to which the electronic control unit is connected when it is the first situation, and to switch to and use an access authorization policy for abnormal use prepared separately from the access authorization policy for normal use when it is the second situation Electronic control unit.

[0125] [Item 11] An access authorization policy update method for updating an access authorization policy that defines access rights between a plurality of functional blocks configured to execute respective determined processes, which is implemented by an electronic control unit mounted on a vehicle, determining whether or not it is in a situation to be updated where it is necessary to update the access authorization policy; determining whether or not the state of the vehicle is in a safe state where the access authorization policy can be updated safely; when it is determined that it is in the situation to be updated and it is determined that it is in the safe state, updating the access authorization policy; An access authorization policy update method including

[0126] [Item 12] A function for determining whether or not it is in a situation to be updated where it is necessary to update an access authorization policy that defines access rights between a plurality of functional blocks configured to execute respective determined processes, in a computer mounted on a vehicle, A function for determining whether the state of the vehicle is in a safe state where the update of the access authorization policy can be safely implemented; A function for implementing the update of the access authorization policy when it is determined that the state is in the situation to be updated and it is determined that the state is in the safe state; A program for realizing the above.

Claims

1. Any one of a plurality of electronic control units (2 to 5) each connected to an in-vehicle network, or an external device (200) remotely connected to the in-vehicle network, and a plurality of function blocks (21 to 23) each configured to execute a determined process; A cooperation control unit (30) configured to realize cooperation between the plurality of function blocks; Comprising: The cooperation control unit: When receiving an access request from a source block, which is one of the plurality of function blocks, to a destination block, which is another one of the plurality of function blocks, it uses an access authorization policy that defines access rights between the function blocks to determine whether the source block has the access right to the destination block. If it is determined that the access right exists, it is configured as an access control unit (32) to transmit the access request to the destination block; A necessity determination unit (35: S210 to S220) configured to determine whether it is in a situation where the access authorization policy needs to be updated; A state determination unit (35: S240, S250, S270) configured to determine whether the state of the vehicle equipped with the in-vehicle network is in a safe state where the update of the access authorization policy can be safely implemented; An update execution unit (35: S260, S280) configured to update the access authorization policy when it is determined by the necessity determination unit that it is in the situation where update is required and it is determined by the state determination unit that it is in the safe state; An in-vehicle system comprising.

2. The in-vehicle system according to Claim 1, The update execution unit: A permission confirmation unit (35: S320 to S330, S420 to S430, S460 to S470) configured to confirm whether there is permission from the vehicle user for the update of the access authorization policy; An operation permission unit (35: S340, S440, S480) configured to permit the operation of the update execution unit when the permission of the vehicle user is confirmed by the permission confirmation unit; An in-vehicle system further comprising.

3. The in-vehicle system according to Claim 2, The permission confirmation unit is configured to confirm whether there is permission from the vehicle user when it is determined by the necessity determination unit that the system is in the update required state and it is determined by the state determination unit that the system is in the safe state. In-vehicle system.

4. The in-vehicle system according to claim 2, wherein the update execution unit further includes an occupant determination unit (35: S300 to S310, S400 to S410) configured to determine whether there is an occupant in the vehicle, and the permission confirmation unit when the occupant determination unit determines that there is an occupant, a first confirmation unit (35: S430) configured to confirm the permission of the vehicle user via the HMI device (7) installed in the vehicle; when the occupant determination unit determines that there is no occupant, a second confirmation unit (35: S470) configured to confirm the permission of the vehicle user via a pre-registered user terminal (300); An in-vehicle system comprising.

5. The in-vehicle system according to claim 1, wherein the update execution unit includes a battery state monitoring unit (35: S350 to S360) configured to monitor the state of the battery mounted on the vehicle, and a limited update unit (35: S370) configured to partially perform the update of the access authorization policy when the state of the battery is in a low voltage state in which the operation of the update execution unit may become unstable; An in-vehicle system further comprising.

6. The in-vehicle system according to any one of claims 1 to 5, wherein the safe state is a state in which the vehicle is parked or stopped In-vehicle system.

7. The in-vehicle system according to any one of claims 1 to 5, wherein the necessity determination unit determines that it is in the update required state when there is update information of the access authorization policy In-vehicle system.

8. The in-vehicle system according to any one of claims 1 to 5, wherein the necessity determination unit determines that it is in the update required state when an abnormality of the vehicle is detected In-vehicle system.

9. An electronic control device mounted on a vehicle, When an access request from a source block, which is one of a plurality of functional blocks configured to execute determined processes, to a destination block, which is another one of the plurality of functional blocks, is received, an access control unit (32) configured to use an access authorization policy that defines access rights between the plurality of functional blocks to determine whether the source block has access rights to the destination block, and if it is determined that the access rights exist, transmit the access request to the destination block; A necessity determination unit (35: S210 to S220) configured to determine whether there is a situation where it is necessary to update the access authorization policy; A state determination unit (35: S240, S250, S270) configured to determine whether the state of the vehicle is in a safe state where the update of the access authorization policy can be safely performed; An update execution unit (35: S260, S280) configured to update the access authorization policy when it is determined by the necessity determination unit that there is a situation where update is necessary and it is determined by the state determination unit that the vehicle is in the safe state; An electronic control device comprising the above.

10. The electronic control device according to claim 9, wherein the necessity determination unit is configured to determine that there is a situation where update is necessary in a first situation where update information of the access authorization policy exists and in a second situation where an abnormality of the vehicle is detected; wherein the update execution unit, in the first situation, updates the normal-time access authorization policy using update information obtained from an external device (200) remotely connected to an in-vehicle network to which the electronic control device is connected, and in the second situation, is configured to switch to and use an abnormal-time access authorization policy prepared separately from the normal-time access authorization policy An electronic control device.

11. An access authorization policy update method for updating an access authorization policy that defines access rights between a plurality of functional blocks (21 to 23) each configured to execute determined processes, the method being implemented by an electronic control device mounted on a vehicle, determining whether there is a situation where it is necessary to update the access authorization policy (S210 to S220), Determining whether the state of the vehicle is in a safe state where the update of the access authorization policy can be safely performed (S240, S250, S270), When it is determined that the state is in the update required situation and it is determined that the state is in the safe state, performing the update of the access authorization policy (S260, S280), An access authorization policy update method including the above.

12. In a computer mounted on a vehicle, Regarding an access authorization policy that defines access rights between a plurality of functional blocks (21 to 23) each configured to execute a determined process, a function for determining whether there is a situation where the update of the access authorization policy needs to be performed (S210 to S220), A function for determining whether the state of the vehicle is in a safe state where the update of the access authorization policy can be safely performed (S240, S250, S270), A function for performing the update of the access authorization policy when it is determined that the state is in the update required situation and it is determined that the state is in the safe state (S260, S280), A program for realizing the above.

Images