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

Abstract

A necessity determination unit (S210-S220) determines whether or not there is an update-requiring condition in which an access authorization policy needs to be updated. A state determination unit (S240, S250, S270) determines whether or not the state of a vehicle mounted on an in-vehicle network is a secure state in which an access authorization policy can be securely updated. Update execution units (S260, S280) update the access authorization policy when it is determined by the necessity determination unit that the access authorization policy is in the update necessity state and when it is determined by the state determination unit that the access authorization policy is in the secure state.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present international application claims the priority based on Japanese Patent Application No. 2022-110649 filed with the Japan Patent Office on July 8, 2022, the entire contents of which are hereby incorporated by reference into the present international application. Technical Field

[0003] The present disclosure relates to a technology for controlling access to resources and information possessed by a vehicle. Background Art

[0004] Patent Document 1 below describes a technology for limiting access using access authorization policies when detecting access to system resources and information via service applications in an open platform for mobile terminals. Access authorization policies specify who is allowed or prohibited to do what.

[0005] Patent Document 1: Japanese Patent No. 6124627

[0006] In the future, it is assumed that an unspecified plurality of third-party service applications are installed in an electronic control system (hereinafter referred to as an on-board system) mounted on a vehicle. Therefore, it is considered to use an access authorization policy to restrict access from these unspecified plurality of service applications. In addition, the access authorization policy is set based on the reliability of the service application that is the source of the access request, and the characteristics of the resources and information that are the access destination. In addition, with the frequent addition, change, and deletion of service applications in response to various needs, it is expected that the update frequency of the access authorization policy will increase.

[0007] When the access authorization policy in the vehicle-mounted system is updated, the basis for allowing / disabling access may change before and after the update, so unexpected operation or non-operation may be induced depending on the timing of the update. Summary of the invention

[0008] In one aspect of the present disclosure, techniques are provided for securely enforcing updates to access authorization policies.

[0009] One method disclosed herein is a vehicle-mounted system having a plurality of functional blocks and a cooperative control unit. The plurality of functional blocks are respectively mounted on any one of a plurality of electronic control devices connected to a vehicle-mounted network, or an external device remotely connected to the vehicle-mounted network, and are configured to implement functions assigned to each of them. The cooperative control unit is configured to implement cooperation between the plurality of functional blocks.

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

[0011] The access control unit receives an access request from a source block to a destination block, the source block being one of the plurality of function blocks, and the destination block being another of the plurality of function blocks. The access control unit uses an access authorization policy that specifies access rights between function blocks to determine whether the source block has access rights to the destination block. The access control unit is configured to transfer the access request to the destination block if it is determined that the source block has access rights.

[0012] The necessity determination unit is configured to determine whether the access authorization policy is in an update-required state. 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 in which the access authorization policy can be updated safely. The update execution unit is configured to update the access authorization policy when the necessity determination unit determines that the access authorization policy is in an update-required state and the state determination unit determines that the access authorization policy is in a safe state.

[0013] According to such a structure, the access authorization policy can be updated securely.

[0014] One aspect of the present disclosure is an electronic control device mounted on a vehicle. The electronic control device includes an access control unit, a necessity determination unit, a state determination unit, and an update execution unit. That is, the electronic control device has a structure obtained by removing a plurality of functional blocks from the above-mentioned vehicle-mounted system.

[0015] According to such a structure, the access authorization policy can be updated securely.

[0016] One aspect of the present disclosure is an access authorization policy updating method implemented by an electronic control device mounted on a vehicle. The access authorization policy defines access rights between a plurality of function blocks each configured to execute a determined process.

[0017] The access authorization policy updating method includes determining whether the access authorization policy is in a state requiring update. The access authorization policy updating method includes determining whether the state of a vehicle equipped with an in-vehicle network is in a safe state in which the access authorization policy can be safely updated. The access authorization policy updating method includes updating the access authorization policy when it is determined that the access authorization policy is in a state requiring update and is in a safe state.

[0018] According to such a method, the access authorization policy can be updated securely.

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

[0020] The program causes the computer to implement functions including a function of determining whether the vehicle is in an update-required state where an update of the access authorization policy needs to be implemented. The access authorization policy specifies access rights between a plurality of function blocks that are respectively configured to execute the determined processing. The program causes the computer to implement functions including a function of determining whether the vehicle is in a safe state where the update of the access authorization policy can be safely implemented. The program causes the computer to implement functions including a function of updating the access authorization policy when it is determined that the vehicle is in an update-required state and is in a safe state.

[0021] By executing such a program, the above-mentioned access authorization policy updating method is realized, and as a result, the access authorization policy can be updated securely. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 This is a block diagram showing the structure of a mobility service providing system.

[0023] Figure 2 It is a block diagram showing the structure of the platform.

[0024] Figure 3 This is an explanatory diagram showing an overview of the access authorization policy.

[0025] Figure 4 This is a flowchart of the access restriction process executed by the access control unit.

[0026] Figure 5 This is a flowchart of the policy update process executed by the policy update unit.

[0027] Figure 6 This is a flowchart of the update process during parking.

[0028] Figure 7 This is a flowchart of the update process during stop driving. DETAILED DESCRIPTION

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

[0030] [1.Structure]

[0031] like Figure 1As shown, the mobility service providing system 1 of this embodiment includes an in-vehicle system 100 mounted on a vehicle, a cloud server 200, and a user terminal 300. The vehicle may also have an automatic driving function in addition to a manual driving function. The vehicle may also be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle with an automatic driving function and a hybrid vehicle, and may also be a vehicle with only a manual driving function, or a vehicle with only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the in-vehicle system 100 is referred to as a vehicle.

[0032] The vehicle-mounted system 100 includes an electronic control device (hereinafter referred to as ECU) 2, a plurality of ECUs 3, a plurality of ECUs 4, an external vehicle communication device 5, and an internal vehicle communication network 6. ECU is an abbreviation of Electronic Control Unit.

[0033] The ECU 2 realizes coordinated control of the entire vehicle by collectively managing the plurality of ECUs 3 .

[0034] ECU3 is set up in each domain divided by the functions in the vehicle, and mainly performs the control of multiple ECU4 existing in the domain. Each ECU3 is connected to the subordinate ECU4 via a lower-level network that is independently set up. The lower-level network uses, for example, a controller area network (controller area network, hereinafter referred to as CAN). CAN is a registered trademark. ECU3 has the function of centrally managing the access rights to the subordinate ECU4 and authenticating the user. Domains are, for example, powertrain, body, chassis, and cockpit.

[0035] The ECU 4 connected to the ECU 3 belonging to the powertrain domain includes, for example, an ECU 4 for controlling an engine, an ECU 4 for controlling a motor, and an ECU 4 for controlling a battery.

[0036] The ECU 4 connected to the ECU 3 belonging to the vehicle body domain includes, for example, an ECU 4 for controlling an air conditioner and an ECU 4 for controlling vehicle doors.

[0037] The ECU 4 connected to the ECU 3 belonging to the chassis domain includes, for example, an ECU for controlling brakes and an ECU 4 for controlling steering.

[0038] The ECU 4 connected to the ECU 3 belonging to the cockpit domain includes, for example, an ECU 4 for controlling the display of instruments and navigation, and an ECU 4 for controlling an HMI device 7 operated by a vehicle occupant. HMI is an abbreviation of Human Machine Interface.

[0039] The vehicle external communication device 5 performs data communication with the cloud server 200 , the user terminal 300 and other vehicle external devices via the wide area wireless communication network.

[0040] The in-vehicle communication network 6 includes CAN with Flexible Data Rate (CAN with variable data rate, hereinafter referred to as CANFD) and Ethernet. Ethernet is a registered trademark. CAN FD connects ECU2 with each ECU3 and the external communication device 5 via a bus. Ethernet independently connects ECU2 with each ECU3 and the external communication device 5. ECU2 may also include an Ethernet switch for switching the Ethernet to be used.

[0041] ECU2 is an electronic control device centered on a microcomputer having CPU2a, ROM2b, and RAM2c. Various functions of the microcomputer are realized by CPU2a executing a program stored in a non-transitional physical recording medium. In this example, ROM2b is equivalent to a non-transitional physical recording medium storing a program. In addition, by executing the program, a method corresponding to the program is executed. In addition, a part or all of the functions executed by CPU2a may be constituted in hardware by one or more ICs, etc. In addition, the number of microcomputers constituting ECU2 may be one or more.

[0042] ECU3, ECU4, and the vehicle exterior communication device 5 are all electronic control devices composed mainly of a microcomputer including a CPU, ROM, RAM, etc., similarly to ECU2. The number of microcomputers constituting ECU3, ECU4, and the vehicle exterior communication device 5 may be one or more.

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

[0044] [2. Functional structure]

[0045] For example, the software installed in the vehicle-mounted devices 2 to 5 belonging to the vehicle-mounted system 100 is constructed according to AUTOSAR. AUTOSAR is an architecture for autonomous driving and is the abbreviation of AUTomotive Open System Architecture. AUTOSAR not only provides communication between software components (hereinafter referred to as SW-C) installed to implement various applications, but also provides functions related to connection with the cloud, security, etc. SW-C is componentized software to achieve a certain function. An application contains one or more SW-C. In addition, the software of the mobility service providing system 1 does not necessarily need to be built according to AUTSAR.

[0046] The in-vehicle devices 2 to 5 are each provided with a platform. The platform provides an environment for executing SW-Cs described in a format that does not depend on hardware.

[0047] The platform has an operating environment (hereinafter referred to as RTE) and basic software (hereinafter referred to as BSW). RTE is an interface that connects SW-Cs to each other and between SW-C and BSW. BSW is a layer that connects hardware to SW-C, including OS, drivers, middleware, etc. The functions of BSW are divided into small modules. The functions of each module are provided to SW-C via Application Programming Interface (hereinafter referred to as API).

[0048] like Figure 2 As shown, the vehicle-mounted devices 2 to 5 have a service system functional block group 21, which is 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 a client, processes them, and returns results. Each service application is composed of one or more SW-Cs. The service application can also be installed not only on any of the vehicle-mounted devices 2 to 5, but also on an external device such as a cloud server 200 that is remotely connected to the in-vehicle communication network 6 via an off-vehicle communication device 5.

[0049] The service system functional block group 21 includes service applications (hereinafter referred to as OEM applications) provided by the Original Equipment Manufacturer (hereinafter referred to as OEM). OEM is the vehicle manufacturer that manufactures the vehicle. The OEM applications may also include applications developed by the OEM itself and applications developed by other suppliers. The service system functional block group 21 may also include service applications (hereinafter referred to as 3rd applications) provided by a third party. The third party is a third party other than the owner of the vehicle and the OEM. As a third party, for example, a data user who provides services by collecting data from the vehicle can be cited.

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

[0051] The control system function block group 22 is a set of service applications that have an API for receiving commands related to the movement of the vehicle and integrate the commands received by the API to achieve matched vehicle control. The control system function block group 22 outputs various commands to the vehicle-mounted devices 3 to 5 that are entities that execute control based on the commands via the in-vehicle communication network 6. In addition, the control system function block group 22 may also have a function of converting various commands (i.e., API access requests) from the service system function block group 21 that are expressed in a form that does not depend on the vehicle into commands that are expressed in a form that depends on the vehicle.

[0052] The data system functional block group 23 is a collection of service applications having an API for processing vehicle data held by the vehicle-mounted devices 2 to 5. The data system functional block group 23 may also have an API for providing a function of abstracting and accumulating vehicle data expressed in a vehicle-dependent form supplied from each vehicle-mounted device 2 to 5 into a vehicle-independent form. The data system functional block group 23 may also have an API for providing a function of uploading the accumulated vehicle data to the cloud server 200 via the off-vehicle communication device 5.

[0053] Hereinafter, the API provided by the service application belonging to the control system function block group 22 and the data system function block group 23 is referred to as the vehicle API. The vehicle API may also include an API that provides a function of obtaining the access authorization policy described later from the cloud server 200 or the like via the external vehicle communication device 5. The vehicle API may also include an API that provides a function of communicating with the user terminal 300 via the external vehicle communication device 5. The vehicle API may also include an API that provides a function of providing information to the occupant and accepting input operations from the occupant via the HMI device 7 provided in the vehicle. The vehicle API may also include an API that provides a function of obtaining the information required for determining the presence or absence of an occupant from the occupant identification sensor 8 provided in the vehicle. The occupant identification sensor 8 may be either a camera that takes pictures of the interior of the vehicle or a pressure sensor that detects the load applied to the seat.

[0054] The API gateway 30 is constructed using the function of the virtual function bus (hereinafter referred to as VBF). VBF is a middleware that can realize communication between SW-Cs and communication between SW-Cs and BSWs without considering hardware, communication protocols, etc., and is also called a software bus. Communication between SW-Cs refers to the access from SW-C to the API provided by other SW-Cs between service applications belonging to the service system function block group 21. The communication between SW-C and BSW is the access from SW-C to the vehicle API between the service application belonging to the service system function block group 21 and the service application belonging to the control system function block group 22 and the data system function block group 23. In the following, it is assumed that there is a one-to-one correspondence between SW-C and service application for explanation.

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

[0056] [3. Access restriction mechanism]

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

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

[0059] The information storage unit 31 stores an access authorization policy 311, a correspondence table 312, and user information 313. The correspondence table 312 may also be stored in the RAM 2c. The access authorization policy 311 and user information 313 may also be stored in the ROM 2b. However, the access authorization policy 311 and user information 313 may also be stored in the nonvolatile RAM 2c.

[0060] The access authorization policy 311 is a collection of information used to determine whether the service application has access rights to the vehicle API. The access authorization policy 311 is downloaded from the cloud server 200 using the function of the service application belonging to the data system functional block group 23, for example, and stored in the information storage unit 31. Figure 3 As shown, for example, the access authorization policy is expressed by a list that defines whether a utilization source application identified by an application ID has access rights to a utilization destination API identified by an API ID.

[0061] For example, the access authorization policy 311 may be designed from the perspective of SFOP, which is defined as the attribute of a security-protected asset. S is the abbreviation of Safety, which means access restrictions on API access that affects safety. F is the abbreviation of Financial, which means access restrictions on API access that affects the property of a company or an individual. O is the abbreviation of Operational, which means access restrictions on API access that affects the operational performance of a vehicle. P is the abbreviation of Privacy, which means access restrictions on API access that affects privacy information.

[0062] The correspondence table 312 includes information for establishing correspondence between a process ID dynamically assigned to a process, which is an execution unit of a program in an operating system (hereinafter referred to as an OS), and an inherent application ID of a service application executed in the process. In addition, the correspondence table 312 includes information for establishing correspondence between an inherent API-ID of each vehicle API and a process ID of a process assigned to an entity that executes the API function, that is, a service application. The correspondence table 312 is generated by the OS when a process for each service application is generated at system startup.

[0063] In addition, a table may be generated by combining the access authorization policy 311 and the correspondence table 312. Specifically, by referring to the correspondence between the application ID and the process ID and the correspondence between the API-ID and the process ID shown in the correspondence table 312, a table indicating whether the process ID of the source application has access rights to the process ID of the destination API may be generated.

[0064] The user information 313 is information arbitrarily set by the vehicle user. For example, the user information 313 stores the contact information of the vehicle user, such as the phone number and email address of the mobile terminal held by the vehicle user, in correspondence with the user ID identifying the vehicle user. The vehicle user can be the owner of the vehicle or a user who temporarily uses a shared car or other vehicle.

[0065] When receiving an API access request, the access control unit 32 determines the application ID of the source application using the corresponding table 312 according to the process ID indicated in the API access request. The access control unit 32 performs access restriction processing to determine whether access rights exist according to the access authorization policy 311 based on the determined application ID and the API-ID of the destination API indicated in the API access request. The details of the access restriction processing will be described later.

[0066] 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 API provided by the control system function block group 22 to obtain information such as the vehicle speed and the gear lever position, so as to determine whether the vehicle state corresponds to parking, stopping, or driving. For example, when the gear lever position is in the parking position, it is determined to be parking. When the gear lever position is not in the parking position, if the absolute value of the vehicle speed is lower than the specified value (for example, 1 km / h), it is determined to be stopping. If it is above the specified value, it is determined to be driving. In addition, the vehicle determination unit 33 obtains the battery voltage by using the API provided by the control system function block group 22, so as to determine whether the battery state is in a normal state or in a low voltage state. The low voltage state refers to a voltage range in which the microcomputer executing the processing that realizes the function of the API gateway 30 is likely to be in an erroneous operation so high that it exceeds the preset allowable value.

[0067] The occupancy determination unit 34 determines the presence of an occupant based on a request from the policy update unit 35 and provides the determination result to the policy update unit 35. Specifically, the occupancy determination unit 34 obtains the detection result of the occupant recognition sensor 8 using the API provided by the control system function block group 22 to determine the presence of an occupant.

[0068] When detecting a situation requiring updating of the access authorization policy, the policy updating unit 35 executes updating of the access authorization policy based on the determination results of the vehicle determination unit 33 and the vehicle riding determination unit 34 .

[0069] [5. Processing]

[0070] [5-1. Access restriction processing]

[0071] use Figure 4 The flowchart of FIG. 3 illustrates the access restriction process performed by the access control unit 32. When the API gateway 30 is started, the access restriction process is repeatedly performed.

[0072] In S110 , the access control unit 32 determines whether an API access request is received from the service application. If an API access request is received, the process proceeds to S120 . If no API access request is received, the process waits by repeating this step.

[0073] In S120, the access control unit 32 refers to the access authorization policy 311 to determine whether the source application that is the source of the API access request has access rights to the destination API based on the information indicated in the API access request. Specifically, the access control unit 32 first uses the corresponding table 312 to determine the application ID of the source application based on the process ID indicated in the API access request. Then, based on the determined 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 the source application has access rights to the destination API.

[0074] In the next S130 , when the access control unit 32 determines that the utilization source application has access authority to the utilization destination API, the process proceeds to S140 , and when it determines that the access source application does not have access authority, the process proceeds to S150 .

[0075] In S140 , the access control section 32 permits access from the utilization source application to the utilization destination API, that is, passes the API access request to the utilization destination API and ends the processing.

[0076] In S150 , the access control section 32 denies access from the utilization source application to the utilization destination API, that is, abandons the API access request, and ends the process.

[0077] In addition, in S150, instead of simply abandoning the API access request, the access control unit 32 may confirm with the vehicle user whether the access is allowed via the HMI device 7. Then, the access control unit 32 may move the process to S140 when receiving a permission input indicating that the access is allowed via the HMI device 7, and abandon the API access request when receiving a non-permission input indicating that the access is not allowed.

[0078] [5-2. Policy update process]

[0079] use Figure 5 The flowchart of FIG. 1 illustrates the policy update process performed by the policy update unit 35. When the API gateway 30 is activated, the policy update process is repeatedly performed.

[0080] In S210, the policy update unit 35 determines whether there is any uninstalled update information. If it is determined that there is any uninstalled update information, the policy update unit 35 determines that the update is required and moves the process to S240. If it is determined that there is no uninstalled update information, the process moves to S220.

[0081] 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 is determined that an update is required and the process moves to S230. If there is no update request, the process returns to S210. The update request may also be a notification from the cloud server 200 indicating that a new access authorization policy provided to the vehicle-mounted system 100 is uploaded to the cloud server 200.

[0082] In S230 , the policy updating unit 35 acquires update information on the access authorization policy from the cloud server 200 using an API that provides a function of acquiring the access authorization policy via the external vehicle communication device 5 , and the process proceeds to S240 .

[0083] In S240 , the policy updating unit 35 acquires the vehicle state via the vehicle determination unit 33 .

[0084] In 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 is set to a safe state in which the access authorization policy can be updated safely and the process moves to S260. If the policy update unit 35 determines that the vehicle is not parked, the process moves to S270.

[0085] In S260 , the policy updating unit 35 executes the parking update process and ends the process.

[0086] 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 is set as a safe state and the process moves to S280. If the policy update unit 35 determines that the vehicle is not stopped, that is, if the vehicle is running, it is set as an unsafe state and the process moves to S290.

[0087] In S280 , the strategy updating unit 35 executes the updating process during stop driving and ends the process.

[0088] In S290, the policy update unit 35 prohibits the update and ends the process. When the update is prohibited, the update information is not deleted and is held as uninstalled update information.

[0089] [5-3. Update process during parking]

[0090] use Figure 6 The following describes the parking update process performed by the policy update unit 35 in S260.

[0091] In S300 , the policy updating unit 35 acquires the vehicle riding state via the vehicle riding determination unit 34 .

[0092] In the next S310 , the policy updating unit 35 determines whether the vehicle user is riding the vehicle based on the acquired riding status, and moves the process to S320 if the vehicle user is riding the vehicle, and moves the process to S350 if the vehicle user is not riding the vehicle.

[0093] In S320 , the policy updating unit 35 determines whether the vehicle user has been notified of the update confirmation, and if so, the process proceeds to S340 , and if not, the process proceeds to S330 .

[0094] In S330 , the policy updating unit 35 transmits an update confirmation notification using an API that provides a function of confirming whether the access authorization policy can be updated via the HMI device 7 , and ends the process.

[0095] In S340 , the policy update unit 35 determines whether a permission input for allowing update of the access authorization policy is received via the HMI device 7 , and moves the process to S350 if the permission input is received, and terminates the process if the permission input is not received.

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

[0097] In the next S360 , the policy updating unit 35 determines whether the acquired battery state is a low voltage state, and if so, the process moves to S370 , and if not, the process moves to S380 .

[0098] In S370, the policy update unit 35 performs limited update of the access permission policy and ends the process. Specifically, only the portion of the access authorization policy that has been changed from having access rights to having no access rights is installed. Update information other than the updated portion is retained as not-installed update information.

[0099] In S350, the policy update unit 35 may acquire not only the battery status but also the operation status of the application program during parking. In this case, for example, in S360, when the diagnostic process or program update process is executed during parking, the process may proceed to S370 in the same manner as when the low voltage state is determined, and the access authorization policy may be updated in a limited manner.

[0100] In S380, the policy update unit 35 installs all the update information and ends the process. In this case, there is no update information that has not been installed.

[0101] [5-4. Update process during stop driving]

[0102] use Figure 7 The following describes the update process during stop driving executed by the strategy update unit 35 in S280 .

[0103] In S400 , the policy updating unit 35 acquires the vehicle riding state via the vehicle riding determination unit 34 .

[0104] In the next S410 , the policy updating unit 35 determines whether the vehicle user is riding the vehicle based on the acquired riding status, and moves the process to S420 if the vehicle user is riding the vehicle, and moves the process to S460 if the vehicle user is not riding the vehicle.

[0105] In S420 , the policy updating unit 35 determines whether the vehicle user has been notified of the update confirmation, and if so, the process proceeds to S440 , and if not, the process proceeds to S430 .

[0106] In S430 , the policy updating unit 35 transmits an update confirmation notification via an API that provides a function of confirming whether the access authorization policy can be updated via the HMI device 7 , and ends the process.

[0107] In S440 , the policy updating unit 35 determines whether a permission input for allowing update of the access authorization policy is received via the HMI device 7 , and moves the process to S450 if the permission input is received, and terminates the process if the permission input is not received.

[0108] In S450, the policy update unit 35 installs all the update information and ends the process. In this case, there is no update information that has not been installed.

[0109] In S460 , the policy updating unit 35 determines whether the vehicle user has been notified of the update confirmation, and if so, the process proceeds to S480 , and if not, the process proceeds to S470 .

[0110] In S470 , the policy updating unit 35 transmits an update confirmation notification using an API that provides a function of notifying the user terminal 300 via the external vehicle communication device 5 to confirm whether the access authorization policy can be updated, and ends the process.

[0111] In S480, the policy update unit 35 determines whether a permission notification for updating the access authorization policy is received from the user terminal 300 via the external communication device 5. If the policy update unit determines that the permission notification is received, the process proceeds to S490, and if the policy update unit determines that the permission notification is not received, the process ends.

[0112] In S490, the policy update unit 35 installs all the update information and ends the process. In this case, there is no update information that has not been installed.

[0113] That is, in the update process while stopped, if the vehicle user is in the vehicle, whether the update is allowed is confirmed via the HMI device 7, and if the vehicle user is not in the vehicle, whether the update is allowed is confirmed via the pre-registered user terminal 300. Then, the access permission policy is updated (i.e., the update information is installed) only when the update is confirmed to be allowed.

[0114] [6. Correspondence of terms]

[0115] The service system function block group 21, the control system function block group 22, and the data system function block group 23 in this embodiment are equivalent to the multiple function blocks in the present disclosure. The API gateway 30 is equivalent to the collaborative control unit in the present disclosure. S210 to S220 are equivalent to the necessity determination unit in the present disclosure. S240, S250, and S270 are equivalent to the state determination unit in the present disclosure. S260 and S280 are equivalent to the update execution unit in the present disclosure. S320 to S330, S420 to S430, and S460 to S470 are equivalent to the permission confirmation unit in the present disclosure. S340, S440, and S480 are equivalent to the work permission unit in the present disclosure. S300 to S310, and S400 to S410 are equivalent to the occupant determination unit in the present disclosure. S430 is equivalent to the first confirmation unit in the present disclosure. S470 is equivalent to the second confirmation unit in the present disclosure. S350 to S360 are equivalent to the battery state monitoring unit in the present disclosure. S370 is equivalent to the limitation updating unit in the present disclosure.

[0116] [7. Effect]

[0117] According to the above-described detailed embodiments, the following effects are achieved.

[0118] (a) When the cloud server 200 (i.e., Out-Car) has prepared update information of the access authorization policy, in the vehicle-mounted system 100, when the vehicle is parked or stopped, the update of the access authorization policy is allowed. Therefore, even if the content of vehicle control changes due to the access authorization policy switching, the change will not occur during the movement of the vehicle, so safety can be ensured.

[0119] (b) When the vehicle is stopped, the user of the vehicle is confirmed whether the update is allowed, and the update is implemented if the update is confirmed to be allowed. That is, when the vehicle is stopped due to waiting for a traffic light, the user of the vehicle is confirmed whether the vehicle will not start moving immediately, that is, whether the condition is suitable for updating, so that the access authorization policy can be updated in a safer condition.

[0120] (c) When the vehicle is stopped, when confirming with the vehicle user, if the vehicle user is on the vehicle, the HMI device 7 is used, and if the vehicle user is not on the vehicle, the pre-registered user terminal 300 is used. Therefore, the intention of the vehicle user can be confirmed by an appropriate method corresponding to the vehicle user's riding status.

[0121] (d) When the vehicle is parked, if the vehicle user is on board, the vehicle may start to move, so confirmation with the vehicle user is performed in the same manner as when the vehicle is stopped. On the other hand, if the vehicle user is not on board, the vehicle is less likely to start to move, so confirmation with the vehicle user is omitted and the access authorization policy is updated. In this way, confirmation with the vehicle user is performed only when confirmation is required, so unnecessary confirmation can be prevented from causing trouble to the vehicle user.

[0122] (e) When the vehicle is parked, the battery is not automatically charged. Therefore, when the battery is in a low voltage state, not all update information is used to update the authorization policy, but only update information that works on the safety side is used to update the authorization policy. After that, when the vehicle enters a state other than being parked and the battery can be charged, the remaining update information is used to update the authorization policy. Therefore, the power consumption caused by the update can be set to the minimum required, and the occurrence of erroneous operations (for example, bit errors in the update information, etc.) caused by voltage drop during the update can be suppressed.

[0123] [8. Other embodiments]

[0124] As mentioned above, although embodiment of this disclosure was described, this disclosure is not limited to the said embodiment, Various deformation|transformation and implementation are possible.

[0125] (a) In the above-mentioned embodiment, an update request is generated when update information of the access authorization policy is prepared in the cloud server 200, but the opportunity to generate an update request is not limited to when the update information is prepared. For example, an update request of the access authorization policy may be generated when an abnormality is detected. In this case, an access authorization policy for abnormality may be prepared in advance in the information storage unit 31, and when an update request based on the abnormality is generated, the access authorization policy is switched from the normal access policy to the abnormal access policy.

[0126] (b) In the above embodiment, when confirming the vehicle user, the HMI device 7 is used when the vehicle user is in the vehicle, but the user terminal 300 may be used in the same manner as when the vehicle user is not in the vehicle.

[0127] (c) In the above embodiment, when the vehicle state is parked, confirmation with the vehicle user is performed only when the vehicle user is on board. However, confirmation with the vehicle user may be performed at all times regardless of whether the vehicle user is on board.

[0128] (d) In the above-mentioned embodiment, when an update request notification is received from the cloud server 200, update information of the access authorization policy is obtained from the cloud server 200. For example, it is also possible to configure the update information to be automatically downloaded from the cloud server 200 to the vehicle-mounted system 100, and when the download of the update information is confirmed, an update request notification is generated inside the vehicle-mounted system 100. In this case, the update request notification is omitted. Figure 5 Processing of S230 in.

[0129] (e) In the above embodiment, the update of the access authorization policy corresponding to the vehicle state is applied to all APIs, but it is also possible to apply the access authorization policy only to the API provided by the control system function block group 22 accompanying the operation of sensors and actuators. In this case, the access authorization policy related to the API provided by the data system function block group 23 for data acquisition, etc. can also be updated regardless of the vehicle state, etc. if there is uninstalled update information.

[0130] (f) The vehicle-mounted devices 2 to 5 and methods thereof described in the present disclosure may also be implemented by a special-purpose computer, which is provided by a processor and a memory programmed to execute one or more functions embodied by a computer program. Alternatively, the vehicle-mounted devices 2 to 5 and methods thereof described in the present disclosure may also be implemented by a special-purpose computer, which is provided by a processor composed of one or more special-purpose hardware logic circuits. Alternatively, the vehicle-mounted devices 2 to 5 and methods thereof described in the present disclosure may also be implemented by one or more special-purpose computers, which are composed of a combination of a processor and a memory programmed to execute one or more functions and a processor composed of one or more hardware logic circuits. In addition, a computer program may also be stored as an instruction executed by a computer in a non-transitional tangible recording medium that can be read by a computer. The method for implementing the functions of each part included in the vehicle-mounted devices 2 to 5 does not necessarily include software, and all of its functions may be implemented using one or more hardware.

[0131] (g) It is also possible to realize multiple functions of one component in the above-mentioned embodiment by multiple components, or to realize one function of one component by multiple components. In addition, it is also possible to realize multiple functions of multiple components by one component, or to realize one function realized by multiple components by one component. In addition, it is also possible to omit a part of the structure of the above-mentioned embodiment. In addition, it is also possible to add or replace at least a part of the structure of the above-mentioned embodiment with the structure of other above-mentioned embodiments.

[0132] (h) In addition to the above-mentioned vehicle-mounted system 100, the present disclosure may be implemented in various forms, such as a system that uses the vehicle-mounted system 100 as a component, a program that enables a computer to function as the vehicle-mounted system 100, and a non-transitional physical recording medium such as a semiconductor memory that records the program.

[0133] [9. Technical ideas disclosed in this specification]

[0134] [Project 1]

[0135] A vehicle-mounted system, comprising:

[0136] A plurality of functional blocks are respectively mounted on any one of a plurality of electronic control devices connected to the vehicle network, or an external device remotely connected to the vehicle network, and are respectively configured to execute the determined processing; and

[0137] A cooperation control unit is configured to realize cooperation among the plurality of functional blocks.

[0138] The above-mentioned cooperative control unit has:

[0139] an access control unit configured to, when receiving an access request from a utilization source block to a utilization destination block, determine whether the utilization source block has the access permission to the utilization destination block using an access authorization policy that specifies access permission between the functional blocks, and, if it is determined that the utilization source block has the access permission, transmit the access request to the utilization destination block, wherein the utilization source block is one of the plurality of functional blocks and the utilization destination block is another of the plurality of functional blocks;

[0140] A necessity determination unit configured to determine whether an update is required to implement the access authorization policy;

[0141] a state determination unit configured to determine whether the state of the vehicle equipped with the in-vehicle network is in a safe state in which the update of the access authorization policy can be safely implemented; and

[0142] The update execution unit is configured to execute the update of the access authorization policy when the necessity determination unit determines that the update-needed state is present and the state determination unit determines that the state is in the secure state.

[0143] [Project 2]

[0144] The vehicle-mounted system according to item 1, wherein:

[0145] The above-mentioned update execution unit also has:

[0146] a permission confirmation unit configured to confirm whether the vehicle user has permitted the implementation of the update of the access authorization policy; and

[0147] The operation permitting unit is configured to permit the operation of the update executing unit when the permission of the vehicle user is confirmed by the permission confirming unit.

[0148] [Item 3]

[0149] The vehicle-mounted system according to item 2, wherein:

[0150] The permission confirmation unit is configured to confirm whether the vehicle user has given permission when the necessity determination unit determines that the vehicle is in the update-needed state and the state determination unit determines that the vehicle is in the safe state.

[0151] [Item 4]

[0152] The vehicle-mounted system according to item 2 or item 3, wherein:

[0153] The update execution unit further includes an occupant determination unit configured to determine whether there is an occupant riding in the vehicle.

[0154] The permission confirmation unit mentioned above shall have:

[0155] a first confirmation unit configured to confirm the consent of the vehicle user via an HMI device installed in the vehicle when the occupant determination unit determines that there is an occupant; and

[0156] The second confirmation unit is 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.

[0157] [Item 5]

[0158] The vehicle-mounted system according to any one of items 1 to 4, wherein:

[0159] The above-mentioned update execution unit also has:

[0160] a battery state monitoring unit configured to monitor a state of a battery mounted on the vehicle; and

[0161] The limited update unit partially performs the update of the access authorization policy when the battery is in a low voltage state, and the low voltage state is a state in which the operation of the update execution unit may become unstable.

[0162] [Item 6]

[0163] The vehicle-mounted system according to any one of items 1 to 5, wherein:

[0164] The safe state is a state in which the vehicle is parked or stopped.

[0165] [Item 7]

[0166] The vehicle-mounted system according to any one of items 1 to 6, wherein:

[0167] When there is update information of the access authorization policy, the necessity determination unit determines that the update is necessary.

[0168] [Item 8]

[0169] The vehicle-mounted system according to any one of items 1 to 7, wherein:

[0170] The necessity determination unit determines that the update-needed state is present when an abnormality of the vehicle is detected.

[0171] [Item 9]

[0172] An electronic control device is an electronic control device mounted on a vehicle, comprising:

[0173] an access control unit configured to, when receiving an access request from a utilization source block to a utilization destination block, determine whether the utilization source block has the access permission to the utilization destination block using an access authorization policy that specifies access permission between a plurality of functional blocks, and, if it is determined that the access permission is granted, transmit the access request to the utilization destination block, wherein the plurality of functional blocks are respectively configured to execute the determined processing, the utilization source block is one of the plurality of functional blocks, and the utilization destination block is another of the plurality of functional blocks;

[0174] A necessity determination unit configured to determine whether an update is required to implement the access authorization policy;

[0175] a state determination unit configured to determine whether the state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented; and

[0176] The update execution unit is configured to execute the update of the access authorization policy when the necessity determination unit determines that the update-needed state is present and the state determination unit determines that the state is in the secure state.

[0177] [Item 10]

[0178] An electronic control device according to item 9, wherein:

[0179] The necessity determination unit is configured to determine that the update is required in the first situation in which update information of the access authorization policy exists and in the second situation in which an abnormality of the vehicle is detected,

[0180] The update execution unit is configured to, in the case of the first situation, update the access authorization policy used in normal times using update information obtained from an external device remotely connected to the vehicle network to which the electronic control unit is connected, and, in the case of the second situation, switch to use an access authorization policy for abnormal times that is prepared separately from the access authorization policy used in normal times.

[0181] [Item 11]

[0182] An access authorization policy updating method is implemented by an electronic control device mounted on a vehicle and updates an access authorization policy that specifies access rights between a plurality of functional blocks, wherein the plurality of functional blocks are respectively configured to execute a determined process, and the access authorization policy updating method comprises:

[0183] Determine whether it is in a state where an update of the access authorization policy needs to be implemented;

[0184] Determining whether the state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented; and

[0185] When it is determined that the above-mentioned update-required state is in place and it is determined that the above-mentioned safe state is in place, the access authorization policy is updated.

[0186] [Item 12]

[0187] A program for enabling a computer mounted on a vehicle to perform the following functions:

[0188] For an access authorization policy that specifies access rights between a plurality of functional blocks, determining whether an update-required state is in which the access authorization policy needs to be updated, wherein the plurality of functional blocks are respectively configured to execute the determined processing;

[0189] Determining whether the state of the vehicle is in a safe state in which the update of the access authorization policy can be safely implemented; and

[0190] When it is determined that the above-mentioned update-required state is in place and it is determined that the above-mentioned safe state is in place, the access authorization policy is updated.

Claims

1. A vehicle-mounted system comprising: A plurality of function blocks (21-23) are respectively mounted on any one of a plurality of electronic control devices (2-5) connected to the vehicle network, or an external device (200) remotely connected to the vehicle network, and are respectively configured to execute a determined process; and A cooperation control unit (30) is configured to realize cooperation among the plurality of functional blocks. The above-mentioned cooperative control unit has: The access control unit (32) is configured to, when receiving an access request from a source block to a destination block, determine whether the source block has the access permission to the destination block using an access authorization policy that specifies access permission between the functional blocks, and transmit the access request to the destination block if it is determined that the source block has the access permission, wherein: The utilization source block is one of the plurality of functional blocks, and the utilization destination block is another functional block of the plurality of functional blocks; A necessity determination unit (35: S210-S220) is configured to determine whether 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 above-mentioned in-vehicle network is in a safe state in which the update of the above-mentioned access authorization policy can be safely implemented; and The update execution unit (35: S260, S280) is configured to execute the update of the access authorization policy when the necessity determination unit determines that the update is required and the state determination unit determines that the security state is the security state.

2. The vehicle-mounted system according to claim 1, wherein: The above-mentioned update execution unit also has: a permission confirmation unit (35: S320-S330, S420-S430, S460-S470) configured to confirm whether the vehicle user has permitted the update of the access authorization policy; and The operation permission unit (35: S340, S440, S480) is configured to permit the operation of the update execution unit when the permission of the vehicle user is confirmed by the permission confirmation unit.

3. The vehicle-mounted system according to claim 2, wherein: The permission confirmation unit is configured to confirm whether the vehicle user has given permission when the necessity determination unit determines that the vehicle is in the update-needed state and the state determination unit determines that the vehicle is in the safe state.

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

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

6. The vehicle-mounted 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 vehicle-mounted system according to any one of claims 1 to 5, wherein: When there is update information of the access authorization policy, the necessity determination unit determines that the update is necessary.

8. The vehicle-mounted system according to any one of claims 1 to 5, wherein: The necessity determination unit determines that the update-needed state is present when an abnormality of the vehicle is detected.

9. An electronic control device, which is an electronic control device mounted on a vehicle, comprising: The access control unit (32) is configured to, when receiving an access request from a source block to a destination block, determine whether the source block has the access permission to the destination block using an access authorization policy that specifies access permission between a plurality of function blocks, and transmit the access request to the destination block if it is determined that the source block has the access permission, wherein: The plurality of functional blocks are respectively configured to execute determined processing, the utilization source block is one of the plurality of functional blocks, and the utilization destination block is another of the plurality of functional blocks; A necessity determination unit (35: S210-S220) is configured to determine whether 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 is in a safe state in which the update of the access authorization policy can be safely implemented; and The update execution unit (35: S260, S280) is configured to execute the update of the access authorization policy when the necessity determination unit determines that the update is required and the state determination unit determines that the security state is the security state.

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

11. An access authorization policy updating method, which is implemented by an electronic control device mounted on a vehicle and updates an access authorization policy that specifies access rights between a plurality of function blocks (21 to 23), wherein: The plurality of functional blocks are respectively configured to execute the determined processing, and the access authorization policy updating method includes: Determine whether it is in a state where the access authorization policy needs to be updated (S210-S220); Determining whether the 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); as well as When it is determined that the update-required state is present and the security state is present, the access authorization policy is updated (S260, S280).

12. A program for causing a computer mounted on a vehicle to implement the following functions: For an access authorization policy that specifies access rights between a plurality of function blocks (21 to 23), it is determined whether an update-required state (S210 to S220) is required in which the access authorization policy needs to be updated, wherein: The plurality of functional blocks are respectively configured to execute the determined processing; Determining whether the 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); as well as When it is determined that the update-required state is present and the security state is present, the access authorization policy is updated (S260, S280).

Images