VEHICLE ON-BOARD SYSTEM, ELECTRONIC CONTROL DEVICE, ACCESS AUTHORIZATION POLICY UPDATE PROCEDURES AND PROGRAM

Abstract

Necessity determination units (S210 to S220) determine whether an update necessity state, in which it is necessary to update an access authorization policy, is in effect. State determination units (S240, S250, S270) determine whether a vehicle with an onboard network is in a safe state in which the access authorization policy can be safely updated. If 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 REGISTRATIONS

[0001] The present international application claims priority from Japanese patent application No. 2022-110649, which was filed on July 8, 2022. All disclosures of the above-mentioned applications are incorporated herein by TECHNICAL AREA

[0002] The present disclosure relates to a technology for controlling access to resources and information held by a vehicle. STATE OF THE ART

[0003] The following patent document 1 describes a technology in an open platform for mobile devices that uses an access authorization policy to restrict access when access to resources or information held by the system is captured by a service application. The access authorization policy specifies who is allowed to do what with what, and who is not. LITERATURE ON THE STATE OF TECHNOLOGY PATENT LITERATURE

[0004] Patent document 1: JP 6124627 B OVERVIEW OF THE INVENTION

[0005] In the future, an unspecified number of third-party service applications are expected to be installed in electronic control systems mounted in vehicles (hereinafter referred to as "vehicle onboard systems"). Therefore, it is conceivable to restrict access from these unspecified service applications using an access authorization policy. The access authorization policy will be configured according to the reliability of the service application that is the source of the access request and the characteristics of the resources or information that are the target of the access. Furthermore, to meet various requirements, the frequency of updates to the access authorization policy is expected to increase as service applications are frequently added, modified, or deleted.

[0006] When the access authorization policy in the vehicle's onboard system is updated, the criteria for allowing or denying access change both before and after the update. Therefore, depending on when the update occurs, unexpected operations or non-operations may be induced.

[0007] One aspect of the present disclosure provides a technology for securely implementing updates to the access authorization policy.

[0008] One aspect of the present disclosure is a vehicle onboard system comprising a plurality of functional blocks and a coordination control unit. The plurality of functional blocks are each mounted on one of a plurality of electronic control units connected to a vehicle onboard network, or on an external device remotely connected to the vehicle onboard network, and are configured to implement functions assigned to each of them. The coordination control unit is configured to implement coordination between the plurality of functional blocks.

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

[0010] The access control unit receives an access request from a source block, which is one of the many function blocks, to a target block, which is another of the many function blocks. The access control unit determines whether the source block has permission to access the target block, using an access authorization policy that defines permissions between function blocks. The access control unit is configured to send the access request to the target block if it determines that permission exists.

[0011] The need determination unit is configured to determine if an update need state exists, requiring the implementation of an access authorization policy update. The state determination unit is configured to determine if the vehicle, equipped with the onboard network, is in a safe state where the access authorization policy update can be safely implemented. The update execution unit is configured to implement the access authorization policy update when the need determination unit determines that an update need state exists and the state determination unit determines that the vehicle is in a safe state.

[0012] With such a configuration, the update of the access authorization policy can be implemented securely.

[0013] One aspect of the present disclosure is an electronic control device installed in a vehicle. The electronic control device includes an access control unit, a necessity determination unit, a status determination unit, and an update execution unit. In other words, the electronic control device has a configuration that eliminates the multitude of functional blocks from the aforementioned vehicle onboard system.

[0014] With such a configuration, the update of the access authorization policy can be implemented securely.

[0015] One aspect of the present disclosure is an access authorization policy update procedure implemented by an electronic control device mounted in a vehicle. The access authorization policy defines access permissions between a plurality of functional blocks, each configured to perform a predetermined processing action.

[0016] The access authorization policy update procedure includes determining whether an update is required, i.e., whether an update is necessary, in which there is a need to implement an update to the access authorization policy. The procedure also includes determining whether the vehicle, equipped with the onboard network, is in a safe state in which the access authorization policy update can be safely implemented. Finally, the procedure includes implementing the access authorization policy update when it is determined that an update is required and that the safe state exists.

[0017] According to such a procedure, the update of the access authorization policy can be implemented securely.

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

[0019] The functions that the program executes from the computer include a function to determine whether the system is in an update-needed state, or whether an update-needed state exists in which there is a need to implement an update to the access authorization policy. The access authorization policy defines access permissions between a multitude of function blocks, each configured to perform a predetermined process. The functions that the program executes from the computer include a function to determine whether the vehicle is in a safe state in which the access authorization policy update can be safely implemented.The functions that the program allows the computer to execute include a function to implement the update of the access authorization policy when it is determined that the update requirement state exists and that the secure state exists.

[0020] By executing such a program, the above access authorization policy update procedure is implemented, and as a result, the update of the access authorization policy can be securely implemented. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a block diagram illustrating a configuration of a mobility service provision system. Fig. Figure 2 is a block diagram illustrating a platform configuration. Fig. Figure 3 is an explanatory diagram illustrating a sketch of an access authorization policy. Fig. Figure 4 is a flowchart of an access restriction processing operation performed by an access control unit. Fig. Figure 5 is a flowchart of a policy update process performed by a policy update unit. Fig. Figure 6 is a flowchart of an update processing process during parking. Fig. Figure 7 is a flowchart of an update processing process during stopping. DESCRIPTION OF EXECUTION FORMS

[0021] An embodiment of the present disclosure is described below with reference to the drawings. (1. Configuration)

[0022] As in Fig. As shown in Figure 1, a mobility service provision system 1 of the present embodiment comprises a vehicle onboard system 100 mounted in a vehicle, a cloud server 200, and a user terminal 300. The vehicle may have an automated driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle, having an internal combustion engine and an electric motor as a drive source. The vehicle is not limited to the vehicle having the automated driving function or the hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an internal combustion engine or only an electric motor as the drive source. Hereinafter, the vehicle equipped with the vehicle onboard system 100 is simply referred to as a vehicle.

[0023] The vehicle on-board system 100 includes an electronic control unit (hereinafter: ECU) 2, several ECUs 3, several ECUs 4, a vehicle external communication device 5 and a vehicle internal communication network 6. ECU is an abbreviation for electronic control unit.

[0024] The ECU 2 controls the multitude of ECUs 3 to achieve coordinated control of the entire vehicle.

[0025] The ECU 3 is provided for each domain, which is divided into functions within the vehicle, and primarily controls a multitude of ECUs 4 that exist within that domain. Each ECU 3 is connected to the ECU 4 under its control via an individually provided lower-layer network. This lower-layer network is, for example, a Controller Area Network (hereinafter referred to as CAN). CAN is a registered trademark. The ECU 3 has the function of centrally managing access permissions for the ECU 4 under its control and authenticating users. The domain includes, for example, a powertrain, a body, a chassis, a cockpit, and the like.

[0026] The ECUs 4, which are connected to the ECU 3 belonging to the powertrain domain, include, for example, an ECU 4 that controls the internal combustion engine, an ECU 4 that controls the motor, and an ECU 4 that controls the battery.

[0027] The ECUs 4, which are connected to the ECU 3 belonging to the body domain, include, for example, an ECU 4 that controls the air conditioning and an ECU 4 that controls the doors.

[0028] The ECUs 4, which are connected to the ECU 3 belonging to the chassis domain, include, for example, an ECU that controls the brakes and an ECU that controls the steering.

[0029] The ECUs 4, which are connected to the ECU 3 belonging to the cockpit domain, include, for example, an ECU 4 that controls the display of an instrument and a navigation device, and an ECU 4 that controls an HMI device 7 operated by a vehicle occupant. HMI is an abbreviation for Human Machine Interface.

[0030] The vehicle external communication device 5 performs data communication with a vehicle external device, such as the cloud server 200 and the user terminal 300, via a long-range radio communication network.

[0031] The vehicle's internal communication network 6 includes CAN with flexible data rate (hereinafter: CAN FD) and Ethernet. Ethernet is a registered trademark. The CAN FD connects the ECU 2 to each ECU 3 and the vehicle's external communication device 5 via a bus. The Ethernet connects the ECU 2 and each ECU 3 and the vehicle's external communication device 5 individually. The ECU 2 can be equipped with an Ethernet switch to select the Ethernet connection to be used.

[0032] The ECU 2 is an electronic control device that primarily comprises a microcomputer, including a CPU 2a, a ROM 2b, a RAM 2c, and similar components. Various functions of the microcomputer are implemented by the CPU 2a executing a program stored in a non-volatile tangible memory medium. In this example, the ROM 2b corresponds to the non-volatile tangible memory medium that stores a program. Furthermore, executing this program performs a procedure corresponding to the program. Some or all of the functions performed by the CPU 2a can be implemented by a hardware circuit, such as one or more integrated circuits (ICs). The number of microcomputers comprising the ECU 2 can be one or more.

[0033] The ECU 3, the ECU 4, and the vehicle external communication device 5 are all electronic control units that primarily comprise a microcomputer equipped with a CPU, ROM, RAM, and the like, similar to the ECU 2. Furthermore, the number of microcomputers comprising the ECU 3, the ECU 4, and the vehicle external communication device 5 can be one or more.

[0034] Unless otherwise specified, the ECU 2, the ECU 3, the ECU 4 and the vehicle external communication device 5 shall be referred to collectively as vehicle on-board devices 2 to 5. (2. Functional configuration)

[0035] The software installed in the vehicle onboard devices 2 to 5, which belong to the vehicle onboard system 100, is designed according to AUTOSAR. AUTOSAR is an architecture for autonomous driving and is an abbreviation for Automotive Open System Architecture. AUTOSAR not only provides communication between software components (hereinafter referred to as SW-C) deployed to implement various applications, but also functions related to cloud connectivity, security, and the like. SW-C is shared software used to implement a specific function. The application program includes one or more SW-C. The software of the mobility service delivery system 1 does not necessarily have to be designed together with AUTOSAR.

[0036] Each of the vehicle onboard devices 2 to 5 includes a platform. The platform provides an environment for running SW-C, which is written in a hardware-independent format.

[0037] The platform includes a runtime environment (hereinafter referred to as RTE) and basic software (hereinafter referred to as BSW). The RTE is the interface between SW-C and between SW-C and BSW. The BSW is the layer that connects the hardware and SW-C, including the operating system, drivers, middleware, etc. The functions of the BSW are divided into small modules. The functions of each module are provided to the SW-C via an application programming interface (hereinafter referred to as API).

[0038] As in Fig. As shown in Figure 2, the vehicle onboard devices 2 to 5 include a service system function block group 21 as a collection of service applications (hereinafter referred to as service applications) that operate on the platform. A service application is an application that receives requests from clients, processes them, and returns results. Each service application includes one or more SW-Cs. The service application can be implemented not only in one of the vehicle onboard devices 2 to 5, but also in an external device that is remotely connected to the vehicle's in-vehicle communication network 6 via the vehicle's external communication device 5, such as the cloud server 200.

[0039] Service system function block 21 includes service applications (hereinafter referred to as OEM applications) provided by an original equipment manufacturer (hereinafter referred to as OEM). The OEM is the vehicle manufacturer that produced the vehicle. OEM applications may include applications developed by the OEM itself and applications developed by other vendors. Service system function block 21 may also include service applications provided by third parties (hereinafter referred to as third-party applications). A third party is any party other than the vehicle owner and the OEM. For example, a third party includes data usage companies that provide services by collecting data from vehicles.

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

[0041] The control system function block group 22 is a set of service applications equipped with an API to accept instructions regarding the movement of the vehicle and to integrate and control the instructions accepted by the API to implement consistent vehicle control. The control system function block group 22 issues various instructions via the vehicle's in-vehicle communication network 6 to the vehicle's on-board devices 3 to 5, where there is an embodiment that executes control based on the instruction. The control system function block group 22 may include a function to convert various instructions (i.e., API access requests) from the service system function block group 21, expressed in a vehicle-independent format, into instructions expressed in a vehicle-dependent format.

[0042] Data system function block group 23 is a set of service applications equipped with an API for handling vehicle data held by the vehicle onboard devices 2 to 5. Data system function block group 23 may include an API that provides a function to abstract and accumulate vehicle data, expressed in a vehicle-dependent format and supplied by each vehicle onboard device 2 to 5, into a vehicle-independent format. Data system function block group 23 may also include an API that provides a function to upload the stored vehicle data to the cloud server 200 using the vehicle external communication device 5.

[0043] The APIs provided by the service applications belonging to control system function block group 22 and data system function block group 23 are referred to below as vehicle APIs. The vehicle APIs may include APIs that provide a function for obtaining an access authorization policy, described later, from the cloud server 200 or the like, using the vehicle external communication device 5. The vehicle APIs may include APIs that provide a function for communicating with the user terminal 300 using the vehicle external communication device 5. The vehicle APIs may include APIs that provide a function for delivering information to occupants and accepting input operations from occupants using the HMI device 7 provided in the vehicle.The vehicle APIs may include APIs that provide a function to obtain information necessary to determine the presence or absence of occupants from an occupant detection sensor 8 provided in the vehicle. The occupant detection sensor 8 may be a camera that captures the interior of the vehicle or a pressure sensor that detects the load exerted on the seat.

[0044] The API Gateway 30 is configured using the functions of the virtual function bus (hereinafter referred to as VFB). The VFB is middleware that enables communication between software commands (SW-Cs) and between SW-Cs and vehicle software (BSW) without requiring knowledge of hardware or communication protocols; it is also known as a software bus. Communication between SW-Cs occurs between service applications belonging to service system function block group 21 and refers to access from one SW-C to an API provided by another SW-C. Communication between SW-Cs and BSW refers to access from SW-Cs to the vehicle API between service applications belonging to service system function block group 21 and service applications belonging to control system function block group 22 and data system function block group 23. In the following description, it is assumed that the SW-C and the service application have a one-to-one correspondence.

[0045] When a service application uses a function provided by the control system function block group 22 and the data system function block group 23, the service application transmits an API access request, which is a request to access the vehicle API. The API access request includes at least the processing ID of the service application that is the source of the usage (hereinafter: usage source application) and an API ID, which is information that uniquely identifies the vehicle API that is the target of the usage (hereinafter: usage target API). (3. Access restriction mechanism)

[0046] The API gateway 30 is provided in the platform of all vehicle on-board devices 2 to 5, which may include any of the service system function block group 21, the control system function block group 22 and the data system function block group 23.

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

[0048] Information memory 31 stores an access authorization policy 311, a correspondence table 312, and user information 313. The correspondence table 312 can be stored in RAM 2c. The access authorization policy 311 and the user information 313 can be stored in ROM 2b. The access authorization policy 311 and the user information 313 can be stored in non-volatile RAM 2c.

[0049] Access authorization policy 311 is a collection of information used to determine whether the service application has permission to access the vehicle API. Access authorization policy 311 is downloaded from cloud server 200, for example, using a function of a service application belonging to data system function block group 23, and stored in information store 31. As described in Fig. As shown in Figure 3, the access authorization policy is represented by a list that defines whether the usage source application, identified by an application ID, has permission to access the usage target API, identified by an API ID.

[0050] The 311 access authorization policy can be designed taking into account the SFOP (Safety, Security, and Protection) criteria, which are attributes defined as security protection assets. S stands for Safety and refers to access restrictions on API access that compromise security. F stands for Financial and refers to access restrictions on API access that compromise corporate or personal assets. O stands for Operation and refers to access restrictions on API access that compromise vehicle performance. P stands for Privacy and refers to access restrictions on API access that compromise privacy information.

[0051] Correspondence table 312 contains information that correlates the processing ID, dynamically assigned to the processing unit that is the program's execution unit in the operating system (hereinafter referred to as the OS), with the unique application ID belonging to the service application running in the processing unit. Additionally, correspondence table 312 also contains information that links a unique API ID of each vehicle API with the processing ID of a processing unit assigned to a service application, which is the entity that performs the API's function. Correspondence table 312 is generated by the OS when a processing unit is created for each service application upon system startup.

[0052] A single table can be generated by combining the access authorization policy 311 and the correspondence table 312. Specifically, a table can be generated that indicates the presence or absence of an access permission from the processing ID of the use source application to the processing ID of the use target API by referencing the correlation between the application ID and the processing ID shown in correspondence table 312, and the correlation between the API ID and the processing ID.

[0053] User information (313) is information that is arbitrarily set by the vehicle user. For example, user information (313) stores contact information for the vehicle user, such as the phone number or email address of the mobile device belonging to the vehicle user, in conjunction with the user ID that identifies the vehicle user. The vehicle user can be the owner of the vehicle or a user who is temporarily using a vehicle, such as a shared car.

[0054] When the access control unit 32 receives an API access request, it identifies the application ID of the usage source application using the correspondence table 312 from the processing ID specified in the API access request. The access control unit 32 then performs access restriction processing to determine whether or not access permission exists, according to the access authorization policy 311, based on the identified application ID and the API ID of the usage target API specified in the API access request. Details of the access restriction processing are described later.

[0055] The Vehicle Determination Unit 33 determines the vehicle state and battery state according to a request from the Policy Update Unit 35 and provides the determination results to the Policy Update Unit 35. Specifically, the Vehicle Determination Unit 33 uses an API provided by the Control System Function Block Group 22 to obtain information such as vehicle speed and gear selector position to determine whether the vehicle state is Park, Stop, or Drive. For example, if the gear selector position is Park, it is determined to be Park; if the gear selector position is not Park and the absolute value of the vehicle speed is less than a predetermined value (e.g., less than 1 km / h), it is determined to be Stop; if the absolute value of the vehicle speed is equal to or greater than the predetermined value, it is determined to be Drive.Additionally, the vehicle identification unit 33 uses an API that is defined by the.

[0056] Control system function block group 22 is provided to obtain the battery voltage in order to determine whether the battery is in a normal state or a low-voltage state. The low-voltage state refers to a voltage range in which the microcomputer performing the processing to implement the functions of API gateway 30 has a high probability of malfunctioning beyond a preset allowable value.

[0057] The entry determination unit 34 determines the presence or absence of occupants according to a request from the policy update unit 35 and provides the determination results to the policy update unit 35. Specifically, the entry determination unit 34 uses an API provided by the control system function block group 22 to obtain the acquisition results from the occupant detection sensor 8 and to determine the presence or absence of occupants.

[0058] The policy update unit 35 performs the update of the access authorization policy according to the determination results of the vehicle determination unit 33 and the entry determination unit 34 when a situation is detected that requires the update of the access authorization policy. (5. Processing)(5-1. Access restriction processing)

[0059] The access restriction processing, which is performed by the access control unit 32, is described using the flowchart in Fig. 4 described. Access restriction processing is executed repeatedly when API gateway 30 is activated.

[0060] In S110, the access control unit 32 determines whether it has received an API access request from a service application. If the access control unit 32 has received the API access request, processing switches to S120. If the access control unit 32 has not received the API access request, it waits and repeats the same step.

[0061] In S120, the access control unit 32 determines, based on the information provided in the API access request, whether the source application that issued the API access request has permission to access the target API by referencing the access authorization policy 311. Specifically, the access control unit 32 first uses the correspondence table 312 to identify the application ID of the source application from the processing ID specified in the API access request. Then, the access control unit 32 refers to the access authorization policy 311 based on the identified application ID and the API ID of the target API specified in the API access request to determine whether the source application has permission to access the target API.

[0062] If, at the next S130, the access control unit 32 determines that the usage source application has permission to access the usage target API, processing switches to S140, and if it determines that the usage source application does not have permission, processing switches to S150.

[0063] In S140, the access control unit allows 32 access from the usage source application to the usage target API, i.e., it sends the API access request to the usage target API and completes the processing.

[0064] In S150, the access control unit 32 denies access from the usage source application to the usage target API, i.e., it discards the API access request and terminates processing.

[0065] In S150, instead of simply discarding the API access request, the access control unit 32 can confirm permission to access with the vehicle user via the HMI device 7. If the access control unit 32 receives a permission input indicating that access is allowed via the HMI device 7, processing switches to S140. If the access control unit 32 receives a deny permission input indicating that access is not allowed, it can discard the API access request. (5-2. Policy Update Processing)

[0066] The policy update processing, which is performed by the policy update unit 35, is described using the flowchart in Fig. 5 described. The policy update processing is executed repeatedly when API Gateway 30 is enabled.

[0067] In S210, the policy update unit 35 determines whether any uninstalled or uninstalled update information exists. If policy update unit 35 determines that uninstalled or uninstalled update information exists, it considers this an update requirement state and switches processing to S240. If policy update unit 35 determines that no uninstalled or uninstalled update information exists, it switches processing 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 an update request, it considers this a necessary update state and switches processing to S230. If there is no update request, it returns processing to S210. The update request could be a message from cloud server 200 indicating that a new access authorization policy, to be provided to the vehicle onboard system 100, has been uploaded to cloud server 200.

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

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

[0071] At the next S250, the policy update unit 35 determines whether the acquired vehicle state is parked. If the policy update unit 35 determines that the vehicle is parked, it considers this a safe state in which the access authorization policy update can be safely performed and switches processing to S260. If the policy update unit 35 determines that the vehicle is not parked, it switches processing to S270.

[0072] In S260, the policy update unit 35 performs the update processing during parking and then completes the processing.

[0073] In S270, the policy update unit 35 determines whether the acquired vehicle state is stopped. If the policy update unit 35 determines that the vehicle is stopped, it considers this a safe state and switches processing to S280. If the policy update unit 35 determines that the vehicle is not stopped, i.e., if the vehicle is moving, it considers this an unsafe state and switches processing to S290.

[0074] In S280, the policy update unit 35 performs the update processing during the stop and then terminates the processing.

[0075] In S290, policy update unit 35 prohibits the update and terminates processing. If the update is prohibited, the update information is retained as uninstalled or uninstalled update information without being deleted. (5-3. Update processing during parking)

[0076] The update processing during parking, which is performed by the policy update unit 35 at S260, is described using the flowchart in Fig. 6 described.

[0077] In S300, the policy update unit 35 reaches the entry state by means of the entry determination unit 34.

[0078] At the next S310, the policy update unit 35 determines whether the vehicle user will enter the vehicle based on the acquired entry state. If the vehicle user enters, processing switches to S320. If the vehicle user does not enter, processing switches to S350.

[0079] In S320, the policy update unit 35 determines whether the update confirmation has been communicated to the vehicle user. If the update confirmation has been communicated, processing switches to S340. If the update confirmation has not been communicated, processing switches to S330.

[0080] In S330, the policy update unit 35 sends an update confirmation message using an API that provides a function to confirm the update of the access authorization policy, via the HMI device 7, and terminates processing.

[0081] In S340, the policy update unit 35 determines whether it has received a permission input indicating that updating the access authorization policy is permitted, via HMI device 7. If the policy update unit 35 has received the permission input, processing switches to S350. If the policy update unit 35 has not received the permission input, it terminates processing.

[0082] In the S350, the policy update unit 35 obtains the battery status via the vehicle identification unit 33.

[0083] During the next S360 process, the policy update unit 35 determines whether the obtained battery state is a low-voltage state. If the battery state is a low-voltage state, processing switches to S370. If the battery state is not a low-voltage state, processing switches to S380.

[0084] In S370, policy update unit 35 performs a limited update of the access authorization policy and then terminates processing. Specifically, policy update unit 35 only performs the installation for those parts of the access authorization policy that have changed from "allowed access" to "denied access." Update information for all other updated parts is retained as uninstalled or uninstalled update information.

[0085] In S350, the policy update unit 35 can obtain not only the battery state but also the operational state of applications during parking. In this case, for example, in S360, if diagnostic processing or program update processing is performed during parking, processing can switch to S370, similar to when the battery state is determined to be low, and a limited update of the access authorization policy can be performed.

[0086] In S380, the policy update unit 35 performs the installation for all update information and then completes the processing. In this case, no uninstalled or uninstalled update information will remain. (5-4. Update processing during stop)

[0087] The update processing during stop, which is performed by the policy update unit 35 at S280, is described using the flowchart in Fig. 7 described.

[0088] In S400, the policy update unit 35 reaches the entry state by means of the entry determination unit 34.

[0089] At the next S410 event, the policy update unit 35 determines whether the vehicle user will enter the vehicle based on the acquired entry state. If the vehicle user enters, processing switches to S420. If the vehicle user does not enter, processing switches to S460.

[0090] In S420, the policy update unit 35 determines whether the vehicle user has been notified of the update. If the update confirmation has been communicated, processing switches to S440. If the update confirmation has not been communicated, processing switches to S430.

[0091] In S430, the policy update unit 35 sends an update confirmation message using an API that provides a function to confirm the update of the access authorization policy using the HMI device 7 and terminates processing.

[0092] In S440, the policy update unit 35 determines whether it has received a permission input indicating that updating the access authorization policy is permitted, via HMI device 7. If the policy update unit 35 has received the permission input, processing switches to S450. If the policy update unit 35 has not received the permission input, it terminates processing.

[0093] In S450, the policy update unit 35 performs the installation for all update information and then completes the processing. In this case, no uninstalled or uninstalled update information will remain.

[0094] In S460, the policy update unit 35 determines whether the vehicle user has been notified of the update confirmation. If the update confirmation has been communicated, processing switches to S480. If the update confirmation has not been communicated, processing switches to S470.

[0095] In S470, the policy update unit 35 sends an update confirmation message using an API that provides a function to confirm the update of the access authorization policy, via the user terminal 300 using the vehicle external communication device 5, and terminates processing.

[0096] At S480, the policy update unit 35 determines whether it has received a permission message from the user terminal 300 via the vehicle external communication device 5, indicating that the update of the access authorization policy is permitted. If the policy update unit 35 determines that it has received the permission message, processing switches to S490. If the policy update unit 35 determines that it has not received the permission message, it terminates processing.

[0097] In S490, the policy update unit 35 performs the installation for all update information and then completes the processing. In this case, no uninstalled or uninstalled update information will remain.

[0098] In other words, during update processing while the vehicle is stopped, if the vehicle user enters, the update confirmation is checked using HMI device 7. If the vehicle user does not enter, the update confirmation is checked using the pre-registered user terminal 300. The update of the access authorization policy (i.e., the installation of the update information) is only performed if the update permission confirmation is received. (6. Correspondence of concepts)

[0099] The service system function block group 21, the control system function block group 22, and the data system function block group 23 in the present embodiment correspond to the plurality of function blocks in the present disclosure. The API gateway 30 corresponds to the coordination 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 occupant 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 status monitoring unit in the present disclosure. S370 corresponds to the limited update unit in the present disclosure. (7. Effects)

[0100] According to the embodiment described above, the following effects are achieved. (a) When update information for the access authorization policy is being prepared on the side of the cloud server 200 (i.e., outside the vehicle), the vehicle onboard system 100 allows the access authorization policy to be updated when the vehicle is in Park or Stop mode. Therefore, even if the content of the vehicle control changes due to the switching of the access authorization policy, the change does not occur while the vehicle is in motion, thus ensuring security. (b) In the event of a stop, the update is performed after the vehicle user has confirmed permission to perform the update. In other words, if the vehicle is stopped, such as when waiting at a traffic light, the vehicle user is asked whether the situation is suitable for the update, which ensures that the update of the access authorization policy is performed in a more secure situation. (c) In the event of stopping, if the vehicle user confirms that they are boarding, HMI device 7 is used, and if the vehicle user is not boarding, the pre-registered user terminal 300 is used. Therefore, the vehicle user's intention can be confirmed by a suitable means according to the vehicle user's boarding status. (d) In the case of parking, if the vehicle user enters, there is a possibility that the vehicle may start moving, so confirmation with the vehicle user is performed similarly to the case of stopping. If the vehicle user does not enter, there is a small possibility that the vehicle will start moving, so the access authorization policy update is performed without confirmation with the vehicle user. In this way, confirmation with the vehicle user is performed only in situations where confirmation is necessary, thus preventing unnecessary confirmation from bothering the vehicle user. (e) In the case of parking, since the battery is not automatically charged when the battery state is low, only the update information that operates on the safe side is used to update the authorization policy, rather than using all update information. After the vehicle state changes from parking and the battery can be charged, the remaining update information is used to update the authorization policy. Therefore, the power consumption during the update can be minimized, and malfunctions due to voltage drops (e.g., bit errors in the update information) during the update can be prevented. (8. Other embodiments)

[0101] Although the embodiment of the present disclosure has been described above, the present disclosure is not limited to the embodiment described above and can be implemented in various modifications. (a) In the foregoing embodiment, the update request is generated when the update information for the access authorization policy is prepared on cloud server 200. However, the trigger for generating the update request is not limited to when the update information is prepared. For example, an update request for the access authorization policy can be generated when an anomaly is detected. In this case, an anomalous access authorization policy can be pre-prepared in information store 31, and when an update request is generated due to an anomaly, the access authorization policy can be switched from a normal-time access authorization policy to an anomalous-time access authorization policy. (b) In the above embodiment, if confirmed with the vehicle user, the HMI device 7 is used when the vehicle user enters the vehicle, but the user terminal 300 can be used similarly when the vehicle user does not enter the vehicle. (c) In the above embodiment, when the vehicle state is Parked, confirmation with the vehicle user is only carried out if the vehicle user enters the vehicle. However, confirmation with the vehicle user can always be carried out regardless of whether the vehicle user enters the vehicle or not. (d) In the foregoing embodiment, when an update request message is received from the cloud server 200, the update information for the access authorization policy is obtained from the cloud server 200. For example, the update information can be automatically downloaded from the cloud server 200 to the vehicle onboard system 100, and when the download of the update information is confirmed, an update request message can be generated internally in the vehicle onboard system 100. In this case, processing at S230 in Fig. 5 can be omitted. (e) In the foregoing embodiment, the update of the access authorization policy according to the vehicle state and the like is applied to all APIs. However, it can also be applied only to the access authorization policy relating to the APIs provided by the control system function block group 22, which includes the operation of sensors and actuators. In this case, the access authorization policy relating to the APIs provided by the data system function block group 23, which is used for data acquisition and the like, can be updated independently of the vehicle state if there is uninstalled or uninstalled update information. (f) The vehicle on-board devices 2 to 5 and their methods described in this disclosure can be implemented by a dedicated computer provided by forming a processor and memory programmed to perform one or more functions embodied by a computer program. Alternatively, the vehicle on-board devices 2 to 5 and their methods described in this disclosure can be implemented by a dedicated computer provided by forming a processor with one or more dedicated hardware logic circuits.Alternatively, the vehicle on-board devices 2 to 5 and their methods described in this disclosure can be implemented by one or more dedicated computers configured by combinations of processors and memories programmed to perform one or more functions, and processors configured by one or more hardware logic circuits. The computer program can be stored in a computer-readable, non-volatile, tangible storage medium as instructions to be executed by a computer. The technique for implementing the functions of each unit included in the vehicle on-board devices 2 to 5 need not necessarily involve software, and all functions can be implemented using one or a multitude of hardware circuits. A multitude of functions of an element in the foregoing embodiment can be implemented by a multitude of elements, or a single function of an element can be implemented by a multitude of elements. Additionally, multiple functions of multiple components can be implemented by a single component, or a single function implemented by multiple components can be implemented by a single component. Part of the configuration of the foregoing embodiment can be omitted. At least part of the configuration in one embodiment can be added to or replaced by the configuration of another embodiment. (h) In addition to the vehicle on-board system 100 described above, the present disclosure can also be implemented in various forms, such as a system incorporating the vehicle on-board system 100 as a component, a program to cause a computer to function as the vehicle on-board system 100, a non-volatile tangible storage medium, such as a semiconductor memory, in which this program is stored, and an access control method. (9. Technical concepts disclosed in this specification)(Element 1)

[0102] Vehicle on-board system, comprising: a multitude of functional blocks, each of which is mounted on one of a multitude of electronic control units connected to a vehicle on-board network or on an external device connected remotely to the vehicle on-board network and is configured to perform a predetermined processing; a coordination control unit configured to implement coordination between the multitude of functional blocks; where The coordination control unit includes: an access control unit configured to receive an access request from a usage source block, which is one of the plurality of function blocks, to a usage target block, which is another of the plurality of function blocks, and to determine whether the usage source block has access permission to the usage target block, using an access authorization policy that defines access permissions between the function blocks, and to send the access request to the usage target block if it is determined that access permission exists; a needs assessment unit configured to determine whether there is a need to implement an update to the access authorization policy; a state determination unit configured to determine whether the state of the vehicle equipped with the vehicle on-board network is in a safe state in which the update of the access authorization policy can be safely implemented; an update execution unit that is configured to implement the update of the access authorization policy when the need determination unit determines that an update is required and the state determination unit determines that the vehicle is in a safe state. (Element 2)

[0103] Vehicle on-board system according to element 1, wherein The update execution unit also includes: a permission confirmation unit configured to confirm whether there is permission from the vehicle user to implement the access authorization policy update; An operation authorization unit that is configured to allow the operation of the update execution unit when the authorization confirmation unit confirms permission from the vehicle user. (Element 3)

[0104] Vehicle on-board system according to element 2, wherein The permission confirmation unit is configured to confirm whether permission has been granted by the vehicle user when the necessity determination unit determines that an update is required, and the condition determination unit determines that the vehicle is in a safe condition. (Element 4)

[0105] Vehicle on-board system according to element 2 or element 3, wherein The update execution unit also includes: an occupant detection unit configured to determine the presence or absence of occupants in the vehicle; The permit confirmation unit includes: a first confirmation unit configured to confirm permission from the vehicle user via an HMI device installed in the vehicle when the occupant detection unit determines that there are occupants; a second confirmation unit configured to confirm permission from the vehicle user via a pre-registered user terminal device when the occupant determination unit determines that there are no occupants. (Element 5)

[0106] Vehicle on-board system according to one of elements 1 to 4, wherein The update execution unit also includes: a battery health monitoring unit configured to monitor the condition of a battery installed in the vehicle; A restricted update unit configured to partially implement the access authorization policy update when the battery state is a low-voltage state, which may cause the update execution unit's operation to become unstable. (Element 6)

[0107] Vehicle on-board system according to one of elements 1 to 5, wherein The safe state is a state in which the vehicle is parked or stopped. (Element 7)

[0108] Vehicle on-board system according to one of elements 1 to 6, wherein The necessity determination unit determines that an update is required if there is update information for the access authorization policy. (Element 8)

[0109] Vehicle on-board system according to one of elements 1 to 7, wherein The necessity determination unit determines that an update is required when an anomaly is detected in the vehicle. (Element 9)

[0110] Electronic control unit mounted in a vehicle comprising: an access control unit configured to receive an access request from a usage source block, which is one of a plurality of function blocks configured to perform predetermined processing, to a usage target block, which is another of the plurality of function blocks, and to determine whether the usage source block has permission to access the usage target block, using an access authorization policy that defines permissions between the function blocks, and to send the access request to the usage target block if it is determined that permission exists; a needs assessment unit configured to determine whether there is a need to implement an update to the access authorization policy; a state determination unit configured to determine whether the vehicle's state is in a safe condition in which the access authorization policy update can be safely implemented; an update execution unit that is configured to implement the update of the access authorization policy when the need determination unit determines that an update is required and the state determination unit determines that the vehicle is in a safe state. (Element 10)

[0111] Electronic control unit according to element 9, wherein the necessity determination unit is configured to determine that an update is required in a first situation where update information for the access authorization policy is available, and in a second situation where an anomaly is detected in the vehicle; The update execution unit is configured to update the access authorization policy for normal situations using update information obtained from an external device remotely connected to the vehicle's onboard network to which the electronic control unit is connected in the first situation, and in the second situation to switch to and use an access authorization policy for abnormal situations that is prepared separately from the access authorization policy for normal situations. (Element 11)

[0112] Access authorization policy update procedure for updating an access authorization policy that defines access permissions between a plurality of functional blocks configured to perform predetermined processing operations, implemented by an electronic control unit mounted in a vehicle, wherein the procedure comprises: Determine whether there is a need to implement an update to the access authorization policy; Determine whether the vehicle is in a safe state in which the access authorization policy update can be safely implemented; Implement the update of the access authorization policy when it is determined that an update is required and it is determined that the vehicle is in a secure state. (Element 12)

[0113] A program to cause a computer mounted in a vehicle to implement functions for updating an access authorization policy that defines access permissions between a variety of function blocks configured to perform predetermined processing, wherein the program is configured to: Determine whether there is a need to implement an update to the access authorization policy; Determine whether the vehicle is in a safe state in which the access authorization policy update can be safely implemented; Implement the update of the access authorization policy when it is determined that an update is required and it is determined that the vehicle is in a secure state. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] JP 2022-110649

[0001] JP 6124627 B

[0004]

Claims

[1] Vehicle on-board system, comprising: a plurality of functional blocks (21 to 23), each mounted on one of a plurality of electronic control units (2-5) connected to a vehicle on-board network or on an external device (200) remotely connected to the vehicle on-board network, each configured to execute predetermined processing; and a coordination control unit (30) configured to implement coordination between the plurality of functional blocks; where the coordination control unit includes: an access control unit (32) configured to determine, upon receipt of an access request from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, whether the usage source block has access permission to the usage target block using an access authorization policy that defines access permissions between the functional blocks, and to send the access request to the usage target block if it is determined that the access permission exists; a necessity determination unit (35: S210 to S220) configured to determine whether an update necessity state exists in which there is a need to implement an update of the access authorization policy; a state determination unit (35: S240, S250, S270) configured to determine whether a state of the vehicle equipped with the on-vehicle network is in a secure state in which the update of the access authorization policy is securely implemented; and an update execution unit (35: S260, S280) configured to implement the update of the access authorization policy when the necessity determination unit determines that an update necessity state exists and the state determination unit determines that the vehicle is in the safe state. [2] The on-vehicle system according to claim 1, wherein the update execution unit further includes: a permission confirmation unit (35: S320-S330, S420-S430, S460-S470) configured to confirm whether there is permission from a vehicle user to implement the update of the access authorization policy; and an operation permission unit (35: S340, S440, S480) configured to permit the operation of the update execution unit when the permission confirmation unit confirms the permission from the vehicle user. [3] Vehicle on-board system according to claim 2, wherein the permission confirmation unit is configured to confirm whether there is permission from the vehicle user when the necessity determination unit determines that an update necessity state exists and the state determination unit determines that the safe state exists. [4] Vehicle on-board system according to claim 2, wherein the update execution unit further includes: an occupant determination unit (35: S300-S310, S400-S410) configured to determine a presence or absence of an occupant in the vehicle, and The permit confirmation unit includes: a first confirmation unit (35: S430) configured to confirm the permission from the vehicle user by means of an HMI device (7) provided in the vehicle when the occupant determination unit determines that there is an occupant; and a second confirmation unit (35: S470) configured to confirm the permission from the vehicle user by means of a pre-registered user terminal (300) when the occupant determination unit determines that there is no occupant. [5] The on-vehicle system according to claim 1, wherein the update execution unit further includes: a battery condition monitoring unit (35: S350 to S360) configured to monitor a condition of a battery mounted in the vehicle, and a limited update unit (35: S370) configured to partially implement the update of the access authorization policy when the battery state is a low voltage state in which an operation of the update execution unit may become unstable. [6] The on-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. [7] The on-vehicle system according to any one of claims 1 to 5, wherein the necessity determining unit determines that the update necessity state exists when there is update information for the access authorization policy. [8] The on-vehicle system according to any one of claims 1 to 5, wherein the necessity determining unit determines that the update necessity state exists when an abnormality of the vehicle is detected. [9] Electronic control device mounted on a vehicle, comprising: an access control unit (32) configured to, upon receiving an access request from a use source block, which is one of a plurality of functional blocks each configured to execute predetermined processing, to a use target block, which is another of the plurality of functional blocks, determine whether the use source block has access permission to the use target block using an access authorization policy that defines access permissions between the functional blocks, and to send the access request to the use target block if it is determined that the access permission exists; a necessity determination unit (35: S210 to S220) configured to determine whether an update necessity state exists in which there is a need to implement an update of the access authorization policy; a state determination unit (35: S240, S250, S270) configured to determine whether a state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented; and an update execution unit (35: S260, S280) configured to implement the update of the access authorization policy when the necessity determination unit determines that the update necessity state exists and the state determination unit determines that the secure state exists. [10] Electronic control device according to claim 9, wherein the necessity determination unit is configured to determine that the update necessity state exists when there is a first situation in which update information for the access authorization policy exists and when there is a second situation in which an abnormality of the vehicle is detected; and the update execution unit is configured to update, in the first situation, an access authorization policy for a normal time using the update information acquired from an external device (200) remotely connected to an on-vehicle network to which the electronic control device is connected, and to switch to and use an access authorization policy for an abnormal time prepared separately from the normal time access authorization policy in the second situation. [11] An access authorization policy updating method implemented by an electronic control device mounted in a vehicle for updating an access authorization policy defining access permissions between a plurality of functional blocks (21 to 23) each configured to perform predetermined processing, the method comprising: Determining whether an update necessity state exists in which there is a need to implement an update to the access authorization policy (S210 to S220); Determining whether a state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented (S240, S250, S270); and Implementing the update of the access authorization policy when it is determined that the update necessity state exists and it is determined that the secure state exists (S260, S280). [12] Program for causing a computer mounted in a vehicle to implement: a function for determining whether an update necessity state exists in which there is a need to implement an update of an access authorization policy (S210 to S220) with respect to an access authorization policy that defines access permissions between a plurality of functional blocks (21 to 23) each configured to execute predetermined processing; a function for determining whether a state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented (S240, S250, S270); and a function for implementing the update of the access authorization policy when it is determined that the update necessity state exists and it is determined that the secure state exists (S260, S280).

Images