WO2024009706A1 - 車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム - Google Patents

車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム Download PDF

Info

Publication number
WO2024009706A1
WO2024009706A1 PCT/JP2023/021939 JP2023021939W WO2024009706A1 WO 2024009706 A1 WO2024009706 A1 WO 2024009706A1 JP 2023021939 W JP2023021939 W JP 2023021939W WO 2024009706 A1 WO2024009706 A1 WO 2024009706A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
update
access authorization
access
authorization policy
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/021939
Other languages
English (en)
French (fr)
Inventor
英之 本谷
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Denso Corp
Original Assignee
Denso Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Denso Corp filed Critical Denso Corp
Priority to JP2024531979A priority Critical patent/JP7708316B2/ja
Priority to DE112023002999.7T priority patent/DE112023002999T5/de
Priority to CN202380051543.3A priority patent/CN119547072A/zh
Publication of WO2024009706A1 publication Critical patent/WO2024009706A1/ja
Priority to US19/006,156 priority patent/US20250181773A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/629—Protecting access to data via a platform, e.g. using keys or access control rules to features or functions of an application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/12—Arrangements for remote connection or disconnection of substations or of equipment thereof
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems

Definitions

  • the present disclosure relates to technology for controlling access to resources and information possessed by a vehicle.
  • Patent Document 1 listed below describes a technology for restricting access using an access authorization policy when detecting access to resources and information owned by the system via a service application in an open platform for mobile terminals. There is.
  • the access authorization policy specifies who is allowed or prohibited from doing what.
  • an unspecified number of third-party service applications will be installed in electronic control systems installed in vehicles (hereinafter referred to as in-vehicle systems). Therefore, it is conceivable to restrict access from these unspecified number of service applications using an access authorization policy.
  • the access authorization policy is set depending on the reliability of the service application that is the source of the access request, the characteristics of the resource or information that is the access destination, etc. Additionally, as service applications are frequently increased, changed, and deleted in order to meet various needs, it is expected that the frequency of updating access authorization policies will increase.
  • the criteria for permitting/prohibiting access will change before and after the update, so depending on the timing of the update, there is a possibility that unexpected operation or non-operation may be induced. there were.
  • One aspect of the present disclosure provides a technique for safely updating an access authorization policy.
  • One aspect of the present disclosure is an in-vehicle system that includes a plurality of functional blocks and a cooperation control unit.
  • Each of the plurality of functional blocks is configured to be installed in one of the plurality of electronic control units connected to the in-vehicle network or an external device remotely connected to the in-vehicle network, and to realize the functions assigned to each. be done.
  • the cooperation control unit is configured to realize cooperation between a plurality of functional blocks.
  • the cooperation control unit includes an access control unit, a necessity determination unit, a status determination unit, and an update execution unit.
  • the access control unit receives an access request from a source block, which is one of the plurality of functional blocks, to a destination block, which is another one of the plurality of functional blocks.
  • the access control unit determines whether the source block has access authority to the destination block using an access authorization policy that defines access authority between functional blocks.
  • the access control unit is configured to transmit an access request to the target block if it is determined that the access authority exists.
  • the necessity determination unit is configured to determine whether or not there is an update-required situation in which it is necessary to update the access authorization policy.
  • the state determination unit is configured to determine whether the vehicle equipped with the in-vehicle network is in a safe state in which access authorization policy can be safely updated.
  • the update execution unit is configured to update the access authorization policy when the necessity determination unit determines that the update is required and the status determination unit determines that the access authorization policy is in a secure state. Ru.
  • the access authorization policy can be updated safely.
  • the electronic control device installed in a vehicle.
  • the electronic control device includes an access control section, a necessity determination section, a state determination section, and an update execution section. That is, the electronic control device has a configuration in which a plurality of functional blocks are removed from the above-mentioned in-vehicle system.
  • the access authorization policy can be updated safely.
  • One aspect of the present disclosure is an access authorization policy update method implemented by an electronic control device installed in a vehicle.
  • the access authorization policy defines access privileges between a plurality of functional blocks, each of which is configured to perform a predetermined process.
  • the access authorization policy update method includes determining whether there is an update-required situation in which it is necessary to update the access authorization policy.
  • the access authorization policy update method includes determining 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 safely updated.
  • the access authorization policy update method includes updating the access authorization policy when it is determined that the update is required and the security state is determined.
  • the access authorization policy can be updated safely.
  • One aspect of the present disclosure is a program for causing a computer to implement the following functions.
  • the functions that the program causes the computer to implement include the function of determining whether or not the access authorization policy needs to be updated.
  • the access authorization policy defines access privileges between a plurality of functional blocks, each of which is configured to perform a predetermined process.
  • the functions that the program causes the computer to implement include a function of determining whether the state of the vehicle is in a safe state in which the access authorization policy can be safely updated.
  • the functions that the program causes the computer to implement include a function of updating the access authorization policy when it is determined that the update is required and that the computer is in a safe state.
  • the access authorization policy update method described above is realized, and as a result, the access authorization policy can be updated safely.
  • FIG. 1 is a block diagram showing the configuration of a mobility service providing system.
  • FIG. 2 is a block diagram showing the configuration of a platform.
  • FIG. 2 is an explanatory diagram showing an outline of an access authorization policy.
  • 3 is a flowchart of access restriction processing executed by an access control unit.
  • 3 is a flowchart of policy update processing executed by a policy update unit. It is a flowchart of update processing during parking. It is a flowchart of update processing while the vehicle is stopped.
  • the mobility service providing system 1 of this embodiment includes an in-vehicle system 100 installed in a vehicle, a cloud server 200, and a user terminal 300.
  • a vehicle may have an automatic driving function in addition to a manual driving function.
  • the vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source.
  • the vehicle is not limited to a vehicle having an automatic driving function or a hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source.
  • a vehicle equipped with the in-vehicle system 100 will be simply referred to as a vehicle.
  • the in-vehicle system 100 includes one electronic control unit (hereinafter referred to as ECU) 2, multiple ECUs 3, multiple ECUs 4, an external communication device 5, and an in-vehicle communication network 6.
  • ECU is an abbreviation for Electronic Control Unit.
  • the ECU 2 realizes coordinated control of the entire vehicle by supervising the multiple ECUs 3.
  • the ECU 3 is provided for each domain divided by function in the vehicle, and mainly controls a plurality of ECUs 4 existing within that domain. Each ECU 3 is connected to a subordinate ECU 4 via an individually provided lower layer network. As the lower layer network, for example, a Controller Area Network (hereinafter referred to as CAN) is used. CAN is a registered trademark.
  • the ECU 3 has a function of centrally managing access authority to the ECU 4 under its control and authenticating users. Examples of domains include powertrain, body, chassis, and cockpit.
  • the ECU 4 connected to the ECU 3 belonging to the power train domain includes, for example, an ECU 4 that controls an engine, an ECU 4 that controls a motor, an ECU 4 that controls a battery, and the like.
  • the ECU 4 connected to the ECU 3 belonging to the body domain includes, for example, an ECU 4 that controls an air conditioner, an ECU 4 that controls a door, and the like.
  • the ECU 4 connected to the ECU 3 belonging to the chassis domain includes, for example, an ECU that controls brakes, an ECU 4 that controls steering, and the like.
  • the ECU 4 connected to the ECU 3 belonging to the cockpit domain includes, for example, an ECU 4 that controls meter and navigation displays, an ECU 4 that controls an HMI device 7 operated by a vehicle occupant, and the like.
  • HMI is an abbreviation for Human Machine Interface.
  • the external communication device 5 performs data communication with external devices such as the cloud server 200 and the user terminal 300 via a wide area wireless communication network.
  • the in-vehicle communication network 6 includes CAN with Flexible Data Rate (hereinafter referred to as CAN FD) and Ethernet.
  • Ethernet is a registered trademark.
  • the CAN FD connects the ECU 2, each ECU 3, and the external communication device 5 via a bus. Ethernet connects the ECU 2 and each ECU 3 and the external communication device 5 individually.
  • the ECU 2 may include an Ethernet switch for switching the Ethernet to be used.
  • the ECU 2 is an electronic control device mainly composed of a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, and the like.
  • Various functions of the microcomputer are realized by the CPU 2a executing programs stored in a non-transitional physical recording medium.
  • the ROM 2b corresponds to a non-transitional physical recording medium that stores a program. Furthermore, by executing this program, a method corresponding to the program is executed.
  • part or all of the functions executed by the CPU 2a may be configured in terms of hardware using one or more ICs.
  • the number of microcomputers configuring the ECU 2 may be one or more.
  • the ECU 3, ECU 4, and external communication device 5 are all electronic control devices mainly configured with a microcomputer including a CPU, ROM, RAM, and the like. Further, the number of microcomputers configuring the ECU 3, the ECU 4, and the external communication device 5 may be one or more.
  • ECU 2, ECU 3, ECU 4, and external communication device 5 will be referred to as in-vehicle devices 2 to 5 unless otherwise distinguished.
  • the software installed in the in-vehicle devices 2 to 5 belonging to the in-vehicle system 100 is constructed in accordance with AUTOSAR, for example.
  • AUTOSAR is an architecture for autonomous driving and stands for AUTomotive Open System Architecture.
  • AUTOSAR not only provides communication between software components (hereinafter referred to as SW-C) implemented to realize various applications, but also provides functions related to connection with the cloud, security, etc.
  • SW-C is software that is made into components to realize a certain function.
  • the application program includes one or more SW-Cs. Note that the software of the mobility service providing system 1 does not necessarily have to be constructed in accordance with AUTSAR.
  • Each of the on-vehicle devices 2 to 5 includes a platform.
  • the platform provides an environment for executing SW-C written in a hardware-independent manner.
  • the platform includes a runtime environment (hereinafter referred to as RTE) and base software (hereinafter referred to as BSW).
  • RTE is an interface that connects SW-Cs and between SW-C and BSW.
  • BSW is a layer that connects hardware and SW-C, and includes an OS, drivers, middleware, and the like.
  • the functionality of the BSW is 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).
  • API Application Programming Interface
  • the in-vehicle devices 2 to 5 include a service-related functional block group 21 as a collection of service applications (hereinafter referred to as service applications) that operate on the platform.
  • a service app is an application that receives requests from clients, processes them, and returns results.
  • Each service application is configured by one or more SW-Cs.
  • the service application may be implemented not only in any of the in-vehicle devices 2 to 5, but also in an external device, such as the cloud server 200, that is remotely connected to the in-vehicle communication network 6 via the out-of-vehicle communication device 5.
  • the service functional block group 21 includes service applications (hereinafter referred to as OEM applications) provided by Original Equipment Manufacturers (hereinafter referred to as OEMs).
  • OEM is the vehicle manufacturer that manufactured the vehicle.
  • OEM apps may include apps developed by the OEM itself and apps developed by other vendors.
  • the service functional block group 21 may include a service application provided by a third party (hereinafter referred to as a 3rd application).
  • Third parties are vehicle owners and third parties other than the OEM. Examples of third parties include data utilization companies that provide services by collecting data from vehicles.
  • the platform includes a control system functional block group 22, a data system functional block group 23, and an API gateway 30.
  • the control system functional block group 22 is a collection of service applications that include an API that receives commands related to vehicle motion, and that integrate the commands received by the API to realize consistent vehicle control.
  • the control system functional block group 22 outputs various commands via the in-vehicle communication network 6 to the in-vehicle devices 3 to 5 in which entities exist that execute control based on the commands.
  • the control system functional block group 22 converts various commands (i.e., API access requests) from the service functional block group 21 that are expressed in a vehicle-independent format to commands that are expressed in a vehicle-dependent format. It may also have a function to convert into .
  • the data system functional block group 23 is a collection of service applications equipped with an API for handling vehicle data possessed by the in-vehicle devices 2 to 5.
  • the data system functional block group 23 has an API that provides a function to abstract vehicle data expressed in a vehicle-dependent format, which is supplied from each in-vehicle device 2 to 5, into a vehicle-independent format and store it. You may.
  • the data system functional block group 23 may have an API that provides a function of uploading accumulated vehicle data to the cloud server 200 via the external communication device 5.
  • the vehicle API may include an API that provides a function of acquiring an access authorization policy, which will be described later, from the cloud server 200 or the like via the external communication device 5.
  • the vehicle API may include an API that provides a function of communicating with the user terminal 300 via the external communication device 5.
  • the vehicle API may include an API that provides a function of providing information to the occupant and accepting input operations by the occupant via the HMI device 7 provided in the vehicle.
  • the vehicle API may include an API that provides a function of acquiring information necessary for determining the presence or absence of an occupant from an occupant recognition sensor 8 provided in the vehicle.
  • the occupant recognition sensor 8 may be a camera that photographs the interior of the vehicle, or may be a pressure sensor that detects the load applied to the seat.
  • the API gateway 30 is configured using the function of a virtual function bus (hereinafter referred to as VBF).
  • VBF is middleware that enables communication between SW-C and communication between SW-C and BSW without being aware of hardware, communication protocols, etc., and is also called a software bus.
  • Communication between SW-Cs is an access from an SW-C to an API provided by another SW-C, which is performed between service applications belonging to the service functional block group 21.
  • Communication between SW-C and BSW is communication between a service application belonging to the service functional block group 21 and a service application belonging to the control system functional block group 22 and the data system functional block group 23. This is access from C to the vehicle API.
  • the service application uses the functions provided by the control system functional block group 22 and the data system functional block group 23, it transmits an API access request that is an access request to the vehicle API.
  • the API access request includes at least the process ID of the service application to be used (hereinafter referred to as the usage source application) and the API-ID, which is information that uniquely identifies the vehicle API to be used (hereinafter referred to as the usage destination API). .
  • the API gateway 30 is provided in the platforms of all the in-vehicle devices 2 to 5 on which any one of the service functional block group 21, the control system functional block group 22, and the data system functional block group 23 may be installed.
  • the API gateway 30 includes an information storage section 31, an access control section 32, a vehicle determination section 33, a riding determination section 34, and a policy update section 35.
  • the information storage unit 31 stores an access authorization policy 311, a correspondence table 312, and user information 313.
  • the correspondence table 312 may be stored in the RAM 2c.
  • the access authorization policy 311 and user information 313 may be stored in the ROM 2b. However, the access authorization policy 311 and user information 313 may be stored in the nonvolatile RAM 2c.
  • the access authorization policy 311 is a collection of information for determining whether the service application has access authority to the vehicle API.
  • the access authorization policy 311 is, for example, downloaded from the cloud server 200 using the function of a service application belonging to the data-related functional block group 23 and stored in the information storage unit 31. As shown in FIG. 3, the access authorization policy is expressed, for example, by a list that defines the presence or absence of access authority from the source application specified by the application ID to the destination API specified by the API-ID. .
  • the access authorization policy 311 includes, for example, S.I., which is an attribute defined as a security protection asset.
  • S.I. is an attribute defined as a security protection asset.
  • F. O. It may be designed considering the viewpoint of P.
  • S is an abbreviation for Safety, which means access restrictions on API access that affect safety.
  • F is an abbreviation for Financial, which refers to access restrictions on API access that affect the assets of companies or individuals.
  • O is an abbreviation for Operational, and means an access restriction on API access that affects the operational performance of the vehicle.
  • P is an abbreviation for Privacy, which means access restrictions on API access that affect privacy information.
  • the correspondence table 312 associates a process ID that is dynamically assigned to a process, which is an execution unit of a program in an operating system (hereinafter referred to as OS), and a unique application ID of a service application executed in that process. Contains information.
  • the correspondence table 312 also includes information that associates the unique API-ID of each vehicle API with the process ID of the process assigned to the service application that is the entity that executes the function of the API.
  • the correspondence table 312 is generated by the OS when a process for each service application is generated at system startup.
  • one table may be generated by combining the access authorization policy 311 and the correspondence table 312. Specifically, by referring to the correspondence between application IDs and process IDs and the correspondence between API-IDs and process IDs shown in the correspondence table 312, from the process ID of the source application to the process ID of the destination API. A table may be generated that indicates whether or not the user has access authority.
  • the user information 313 is information that is arbitrarily set by the vehicle user.
  • the user information 313 stores contact information for the vehicle user, such as the telephone number and e-mail address of a mobile terminal owned by the vehicle user, in association with a user ID that identifies the vehicle user.
  • the vehicle user may be the owner of the vehicle, or may be a user who temporarily uses a vehicle such as a shared car.
  • the access control unit 32 Upon receiving the API access request, the access control unit 32 uses the correspondence table 312 to identify the application ID of the source application from the process ID indicated in the API access request. The access control unit 32 executes access restriction processing to determine the presence or absence of access authority in accordance with the access authorization policy 311 based on the specified application ID and the API-ID of the destination API indicated in the API access request. . Details of the access restriction process will be described later.
  • the vehicle determining unit 33 determines the vehicle status and battery status according to a request from the policy updating unit 35, and provides the determination results to the policy updating unit 35. Specifically, the vehicle determination unit 33 acquires information such as vehicle speed and shift lever position using the API provided by the control system functional block group 22, and determines whether the vehicle status is parked, stopped, or running. Determine which of the following applies. For example, if the shift lever position is in parking, it is determined that the vehicle is parked, and if the shift lever position is in a position other than parking, if the absolute value of the vehicle speed is less than a predetermined value (for example, 1 km/h), the vehicle is stopped. If the value is medium or above a predetermined value, it is determined that the vehicle is running.
  • a predetermined value for example, 1 km/h
  • the vehicle determination unit 33 uses the API provided by the control system functional block group 22 to acquire the battery voltage, thereby determining whether the battery state is in the normal state or in the low voltage state.
  • the low voltage state refers to a voltage range in which the possibility that the microcomputer that executes the process of realizing the function of the API gateway 30 will malfunction exceeds a preset tolerance value.
  • the boarding determining unit 34 determines whether there is a passenger in accordance with a request from the policy updating unit 35, and provides the determination result to the policy updating unit 35. Specifically, the occupancy determining unit 34 uses the API provided by the control system functional block group 22 to obtain the detection results of the occupant recognition sensor 8 and determines whether or not an occupant is present.
  • the policy updating section 35 updates the access authorization policy according to the determination results of the vehicle determination section 33 and the boarding determination section 34.
  • the access control unit 32 determines whether or not an API access request has been received from the service application. If the API access request has been received, the process moves to S120, and if the API access request has not been received, the process proceeds to S120. Wait by repeating.
  • the access control unit 32 refers to the access authorization policy 311 based on the information indicated in the API access request and determines whether the source application that is the source of the API access request has access authority to the destination API. Determine whether or not. Specifically, the access control unit 32 first uses the correspondence table 312 to identify the application ID of the source application from the process ID indicated in the API access request. Then, the access control unit 32 refers to the access authorization policy 311 based on the specified application ID and the API-ID of the destination API indicated in the API access request, and transfers the information from the source application to the destination API. Determine whether or not you have access privileges.
  • the access control unit 32 allows access from the source application to the destination API, that is, transmits the API access request to the destination API, and ends the process.
  • the access control unit 32 denies access from the source application to the destination API, that is, discards the API access request, and ends the process.
  • the access control unit 32 may confirm with the vehicle user whether the access is possible via the HMI device 7.
  • the access control unit 32 receives a permission input indicating that the access is permitted via the HMI device 7, the process moves to S140, and receives a disallowance input indicating that the access is not permitted. If so, the API access request may be discarded.
  • the policy update unit 35 determines whether there is any uninstalled update information. If the policy update unit 35 determines that there is uninstalled update information, it determines that an update is required and moves the process to S240; if it determines that there is no uninstalled update information, the policy updater 35 moves the process to S220. do.
  • the policy update unit 35 determines whether or not there is a request to update the access authorization policy. If there is an update request, it is determined that the update is required and the process moves to S230; if there is no update request, the process proceeds to S230. is returned to S210.
  • the update request may be, for example, a notification from the cloud server 200 indicating that a new access authorization policy to be provided to the in-vehicle system 100 has been uploaded to the cloud server 200.
  • the policy update unit 35 uses an API that provides a function to obtain an access authorization policy via the external communication device 5 to obtain update information for the access authorization policy from the cloud server 200, and the process proceeds to S240. Proceed.
  • the policy update unit 35 obtains the vehicle state via the vehicle determination unit 33.
  • the policy update unit 35 determines whether the acquired vehicle state is parked. If it is determined that the vehicle is parked, the policy update unit 35 determines that the state is in a safe state in which the access authorization policy can be updated safely, and moves the process to S260; if it is determined that the vehicle is not parked, the policy update unit 35 continues the process. The process moves to S270.
  • the policy update unit 35 executes the parking update process and ends the process.
  • 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 determined that the state is in a safe state, and the process proceeds to S280; if it is determined that the vehicle is not parked, that is, if it is running, it is determined that the state is not in a safe state. The process moves to S290.
  • the policy update unit 35 executes the update process while the vehicle is stopped, and ends the process.
  • the policy update unit 35 prohibits the update and ends the process. If updating is prohibited, the update information is not deleted but is retained as uninstalled update information.
  • the policy update unit 35 acquires the riding state via the riding determination unit 34.
  • the policy update unit 35 determines whether or not the vehicle user is in the vehicle based on the acquired riding state, and if the vehicle user is in the vehicle, the process moves to S320 and the vehicle user is in the vehicle. If not, the process moves to S350.
  • the policy update unit 35 determines whether the vehicle user has been notified of the update confirmation, and if the update confirmation has been notified, the process moves to S340, and it is determined that the update confirmation has been notified. If not, the process moves to S330.
  • the policy update unit 35 sends an update confirmation notification via the HMI device 7 using an API that provides a function to confirm whether the access authorization policy can be updated, and ends the process.
  • the policy update unit 35 determines whether or not a permission input to permit updating of the access authorization policy has been received via the HMI device 7, and if the permission input has been received, the process moves to S350 and permission is granted. If no input is accepted, the process ends.
  • the policy update unit 35 obtains the battery status via the vehicle determination unit 33.
  • the policy update unit 35 determines whether the acquired battery state is a low voltage state, and if it is a low voltage state, the process moves to S370, and if it is not a low voltage state, the process is continued. The process moves to S380.
  • the policy update unit 35 updates the access permission policy in a limited manner and ends the process. Specifically, installation is performed only for the portions in the access authorization policy that have been changed from having access privileges to not having access privileges. Update information other than the updated portion is retained as uninstalled update information.
  • the policy update unit 35 may acquire not only the battery status but also the operating status of the application while the vehicle is parked. In this case, for example, in S360, if a diagnostic process or a program update process is being executed while the car is parked, the process moves to S370 and the access authorization policy is changed, as in the case where it is determined that the low voltage state is present. Updates may be performed on a limited basis.
  • the policy update unit 35 installs all of the update information and ends the process. In this case, uninstalled update information does not exist.
  • the policy update unit 35 obtains the riding state via the riding determination unit 34.
  • the policy update unit 35 determines whether or not the vehicle user is in the vehicle based on the acquired riding state, and if the vehicle user is in the vehicle, the process moves to S420 and the vehicle user is in the vehicle. If not, the process moves to S460.
  • the policy update unit 35 determines whether the vehicle user has been notified of the update confirmation, and if the update confirmation has been notified, the process moves to S440, and the update confirmation has been notified. If not, the process moves to S430.
  • the policy update unit 35 sends an update confirmation notification via the API that provides a function to confirm whether the access authorization policy can be updated via the HMI device 7, and ends the process.
  • the policy update unit 35 determines whether or not a permission input to permit updating of the access authorization policy has been received via the HMI device 7, and if the permission input has been received, the process moves to S450 and permission is granted. If no input is accepted, the process ends.
  • the policy update unit 35 installs all of the update information and ends the process. In this case, uninstalled update information does not exist.
  • the policy update unit 35 determines whether the vehicle user has been notified of the update confirmation, and if the update confirmation has been notified, the process moves to S480, and it is determined that the update confirmation has been notified. If not, the process moves to S470.
  • the policy update unit 35 sends an update confirmation notification to the user terminal 300 via the external communication device 5 using an API that provides a function to send a notification to confirm whether or not the access authorization policy can be updated. Then, the process ends.
  • the policy update unit 35 determines whether or not a permission notification permitting update of the access authorization policy has been received from the user terminal 300 via the external communication device 5. If the policy update unit determines that a permission notification has been accepted, the process proceeds to S490, and if it determines that a permission notification has not been received, the policy update unit ends the process.
  • the policy update unit 35 installs all of the update information and ends the process. In this case, uninstalled update information does not exist.
  • the update process while the vehicle is stopped if the vehicle user is on board, the update is confirmed via the HMI device 7, and if the vehicle user is not on board, the pre-registered user terminal 300 is updated. Check whether the update is possible or not. Then, the access permission policy is updated (ie, the update information is installed) only when the update permission is confirmed.
  • the service functional block group 21, the control system functional block group 22, and the data functional block group 23 in this embodiment correspond to a plurality of functional blocks in the present disclosure.
  • the API gateway 30 corresponds to a cooperation control unit in the present disclosure.
  • S210 to S220 correspond to the necessity determining section 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 section in the present disclosure.
  • S340, S440, and S480 correspond to the operation permission section in the present disclosure.
  • S300 to S310 and S400 to S410 correspond to the occupant determination section in the present disclosure.
  • S430 corresponds to the first confirmation section in the present disclosure.
  • S470 corresponds to the second confirmation section in the present disclosure.
  • S350 to S360 correspond to the battery condition monitoring unit in the present disclosure.
  • S370 corresponds to the limited
  • the update request is generated when the update information of the access authorization policy is prepared in the cloud server 200, but the trigger for generating the update request is when the update information is prepared.
  • a request to update the access authorization policy may be generated when an abnormality is detected.
  • an access authorization policy for abnormal times may be prepared in advance in the information storage unit 31, and when an update request occurs due to an abnormality, the access authorization policy may be switched from one for normal times to one for abnormal times. .
  • the HMI device 7 when confirming the vehicle user, if the vehicle user is in the vehicle, the HMI device 7 is used, but as in the case where the vehicle user is not in the vehicle, the user terminal 300 may be used.
  • update information of the access authorization policy is acquired from the cloud server 200.
  • the update information may be automatically downloaded from the cloud server 200 to the in-vehicle system 100, and when the download of the update information is confirmed, an update request notification may be generated within the in-vehicle system 100. In this case, the process of S230 in FIG. 5 is omitted.
  • the access authorization policy is updated according to the vehicle state etc. to all APIs, but access related to the API provided by the control system functional block group 22 that involves the operation of sensors and actuators. It may be applied only to authorization policies.
  • the access authorization policy regarding the API provided by the data system functional block group 23 used for data acquisition etc. may be updated regardless of the vehicle state etc. if there is update information that has not been installed.
  • the in-vehicle devices 2 to 5 and the methods thereof described in the present disclosure are provided by configuring a processor and memory programmed to execute one or more functions embodied by a computer program. It may also be realized by a dedicated computer. Alternatively, the in-vehicle devices 2-5 and techniques thereof described in this disclosure may be implemented by a dedicated computer provided by a processor configured with one or more dedicated hardware logic circuits. Alternatively, the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure include a processor configured with a processor and memory programmed to execute one or more functions, and one or more hardware logic circuits. It may be realized by one or more dedicated computers configured by a combination of the following.
  • the computer program may also be stored as instructions executed by a computer on a computer-readable non-transitory tangible storage medium.
  • the method of realizing the functions of each part included in the in-vehicle devices 2 to 5 does not necessarily need to include software, and all the functions may be realized using one or more pieces of hardware. .
  • a plurality of functional blocks each of which is installed in one of a plurality of electronic control units connected to an in-vehicle network or an external device remotely connected to the in-vehicle network, and each of which is configured to execute a predetermined process. and, a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit includes: When an access request is received from a source block, which is one of the plurality of functional blocks, to a destination block, which is another one of the plurality of functional blocks, an access authorization defining access authority between the functional blocks is received.
  • the system is configured to use a policy to determine whether or not the source block has the access authority to the target block, and to transmit the access request to the target block if it is determined that the user block has the access authority.
  • an access control unit a necessity determination unit configured to determine whether or not there is an update-required situation in which it is necessary to update the access authorization policy; a state determination unit configured to determine whether the state of a vehicle equipped with the in-vehicle network is in a safe state in which the access authorization policy can be safely updated;
  • the access authorization policy is configured to be updated when the necessity determining unit determines that the update is required and the status determining unit determines that the safe state exists.
  • an update execution unit An in-vehicle system equipped with
  • the in-vehicle system described in item 1 includes: a permission checking unit configured to check whether the vehicle user has permission to update the access authorization policy; an operation permission section configured to permit operation of the update execution section when the vehicle user's permission is confirmed by the permission confirmation section; An in-vehicle system further equipped with
  • the in-vehicle system described in item 2 The permission confirmation unit is configured to determine that the vehicle user has permission when the necessity determination unit determines that the update is required and the state determination unit determines that the vehicle is in the safe state.
  • An in-vehicle system configured to determine whether
  • the in-vehicle system includes: further comprising an occupant determination unit configured to determine whether or not there is an occupant riding in the vehicle,
  • the permission confirmation section is a first confirmation unit configured to confirm permission of the vehicle user via an HMI device installed in the vehicle when the occupant determination unit determines that there is an occupant;
  • a second confirmation unit configured to confirm permission of the vehicle user via a pre-registered user terminal when the occupant determination unit determines that there is no occupant;
  • the in-vehicle system includes: a battery condition monitoring unit configured to monitor the condition of a battery mounted on the vehicle; a limited update unit that partially updates the access authorization policy when the battery is in a low voltage state that may cause unstable operation of the update execution unit; An in-vehicle system further equipped with
  • the in-vehicle system according to any one of items 1 to 5,
  • the safe state is a state in which the vehicle is parked or stopped. In-vehicle system.
  • the in-vehicle system according to any one of items 1 to 6,
  • the in-vehicle system is configured such that the necessity determining unit determines that the update is required when update information of the access authorization policy exists.
  • An electronic control device installed in a vehicle, When an access request is received from a user block, which is one of a plurality of functional blocks each configured to execute a predetermined process, to a user block, which is another one of the plurality of functional blocks.
  • An electronic control device comprising:
  • the electronic control device determines that the update is required in a first situation in which update information of the access authorization policy exists and in a second situation in which an abnormality in the vehicle is detected. configured to In the first situation, the update execution unit updates the normal access authorization policy using update information obtained from an external device remotely connected to an in-vehicle network to which the electronic control device is connected. In the second situation, the electronic control device is configured to switch to and use an access authorization policy for abnormal times that is prepared separately from the access authorization policy for normal times.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

要否判定部（Ｓ２１０～Ｓ２２０）は、アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定する。状態判定部（Ｓ２４０，Ｓ２５０，Ｓ２７０）は、車載ネットワークを搭載する車両の状態がアクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定する。更新実行部（Ｓ２６０，Ｓ２８０）は、要否判定部にて要更新状況にあると判定され、かつ、状態判定部により、安全状態にあると判定された場合に、アクセス認可ポリシーの更新を実施する。

Description

車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム 関連出願の相互参照
　本国際出願は、２０２２年７月８日に日本国特許庁に出願された日本国特許出願第２０２２－１１０６４９号に基づく優先権を主張するものであり、日本国特許出願第２０２２－１１０６４９号の全内容を本国際出願に参照により援用する。
　本開示は、車両が持つリソースや情報へのアクセスを制御する技術に関する。
　下記特許文献１には、携帯端末用オープンプラットフォームにおいて、サービスアプリケーションを介してシステムが持つリソースや情報へのアクセスを検出したときに、アクセス認可ポリシーを用いて、アクセスを制限する技術が記載されている。アクセス認可ポリシーは、「誰が」「何に対して」「何をするのか」を許可又は禁止することを規定する。
特許第６１２４６２７号公報
　今後、車両に搭載される電子制御システム（以下、車載システム）において、サードパーティ製サービスアプリケーションが不特定多数搭載されることが想定される。このため、これら不特定多数のサービスアプリケーションからのアクセスを、アクセス認可ポリシーを用いて制限することが考えられる。なお、アクセス認可ポリシーは、アクセスの要求元となるサービスアプリケーションの信頼性、及びアクセス先となるリソースや情報の特性等に応じて設定される。また、様々なニーズに対応すべく、サービスアプリケーションの増加、変更、削除が頻繁に行われるのに伴って、アクセス認可ポリシーの更新頻度が増加することが予想される。
　車載システムにおけるアクセス認可ポリシーが更新されると、更新の前後でアクセスを許可／禁止する基準が変化することになるため、更新のタイミングによっては、予期しない作動又は不作動が誘発される可能性があった。
　本開示の１つの局面では、アクセス認可ポリシーの更新を安全に実施する技術を提供する。
　本開示の一態様は、車載システムであって、複数の機能ブロックと、連携制御部とを備える。複数の機能ブロックは、それぞれが車載ネットワークに接続された複数の電子制御装置のいずれか、又は前記車載ネットワークにリモート接続される外部装置に搭載され、それぞれに割り当てられた機能を実現するように構成される。連携制御部は、複数の機能ブロック間の連携を実現するように構成される。
　連携制御部は、アクセス制御部と、要否判定部と、状態判定部と、更新実行部と、を備える。
　アクセス制御部は、複数の機能ブロックの一つである利用元ブロックから、複数の機能ブロックの他の一つである利用先ブロックへのアクセス要求を受け付ける。アクセス制御部は、機能ブロック間のアクセス権限を規定するアクセス認可ポリシーを用いて、利用先ブロックに対する利用元ブロックのアクセス権限の有無を判定する。アクセス制御部はアクセス権限が有ると判定した場合、アクセス要求を利用先ブロックに伝達するように構成される。
　要否判定部は、アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定するように構成される。状態判定部は、車載ネットワークを搭載する車両の状態がアクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定するように構成される。更新実行部は、要否判定部にて要更新状況にあると判定され、かつ、状態判定部により、安全状態にあると判定された場合に、アクセス認可ポリシーの更新を実施するように構成される。
　このような構成によれば、アクセス認可ポリシーの更新を安全に実施できる。
　本開示の一態様は、車両に搭載される電子制御装置である。電子制御装置は、アクセス制御部と、要否判定部と、状態判定部と、更新実行部とを備える。つまり、電子制御装置は、上記車載システムから複数の機能ブロックを除いた構成を有する。
　このような構成によれば、アクセス認可ポリシーの更新を安全に実施できる。
　本開示の一態様は、車両に搭載された電子制御装置によって実施されるアクセス認可ポリシー更新方法である。アクセス認可ポリシーは、それぞれが決められた処理を実行するように構成された複数の機能ブロック間のアクセス権限を規定する。
　アクセス認可ポリシー更新方法は、アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定することを含む。アクセス認可ポリシー更新方法は、車載ネットワークを搭載する車両の状態がアクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定することを含む。アクセス認可ポリシー更新方法は、要更新状況にあると判定され、かつ、安全状態にあると判定された場合に、アクセス認可ポリシーの更新を実施することを含む。
　このような方法によれば、アクセス認可ポリシーの更新を安全に実施できる。
　本開示の一態様は、以下の機能をコンピュータに実現させるためのプログラムである。
　プログラムがコンピュータに実現させる機能は、アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定する機能を含む。アクセス認可ポリシーは、それぞれが決められた処理を実行するように構成された複数の機能ブロック間のアクセス権限を規定する。プログラムがコンピュータに実現させる機能は、車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定する機能を含む。プログラムがコンピュータに実現させる機能は、要更新状況にあると判定され、かつ、安全状態にあると判定された場合に、アクセス認可ポリシーの更新を実施する機能を含む。
　このようなプログラムを実行することにより、上記アクセス認可ポリシー更新方法が実現され、その結果、アクセス認可ポリシーの更新を安全に実施できる。
モビリティサービス提供システムの構成を示すブロック図である。 プラットフォームの構成を示すブロック図である。 アクセス認可ポリシーの概略を示す説明図である。 アクセス制御部が実行するアクセス制限処理のフローチャートである。 ポリシー更新部が実行するポリシー更新処理のフローチャートである。 駐車中更新処理のフローチャートである。 停車中更新処理のフローチャートである。
　以下、図面を参照しながら、本開示の実施形態を説明する。
　［１．構成］
　図１に示すように、本実施形態のモビリティサービス提供システム１は、車両に搭載される車載システム１００と、クラウドサーバ２００と、利用者端末３００とを備える。車両は、手動運転機能に加えて自動運転機能を有していてもよい。車両は、走行駆動源として、エンジンと電動モータとを有するハイブリッド車両であってもよい。車両は、自動運転機能を有する車両とハイブリッド車両とに限らず、手動運転機能のみを備える車両であってもよいし、走行駆動源としてエンジンのみ又は電動モータのみを有する車両であってもよい。以下では、車載システム１００を搭載する車両を、単に車両という。
　車載システム１００は、一つの電子制御装置（以下、ＥＣＵ）２と、複数のＥＣＵ３と、複数のＥＣＵ４と、車外通信装置５と、車内通信網６とを備える。ＥＣＵは、Electronic Control Unitの略である。
　ＥＣＵ２は、複数のＥＣＵ３を統括することにより、車両全体として連携がとれた制御を実現する。
　ＥＣＵ３は、車両における機能によって区分けしたドメイン毎に設けられ、主として、そのドメイン内に存在する複数のＥＣＵ４の制御を実行する。各ＥＣＵ３は、それぞれ個別に設けられた下層ネットワークを介して配下のＥＣＵ４と接続される。下層ネットワークは、例えば、Ｃｏｎｔｏｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（以下、ＣＡＮ）が用いられる。ＣＡＮは登録商標である。ＥＣＵ３は、配下のＥＣＵ４に対するアクセス権限などを一元的に管理し利用者の認証等を行う機能を有する。ドメインは、例えば、パワートレーン、ボデー、シャシ、及びコックピット等である。
　パワートレーンのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、エンジンを制御するＥＣＵ４、モータを制御するＥＣＵ４、及び、バッテリを制御するＥＣＵ４等を含む。
　ボデーのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、エアコンを制御するＥＣＵ４、及びドアを制御するＥＣＵ４等を含む。
　シャシドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、ブレーキを制御するＥＣＵ、及び、ステアリングを制御するＥＣＵ４等を含む。
　コックピットのドメインに属するＥＣＵ３に接続されるＥＣＵ４は、例えば、メータやナビゲーションの表示を制御するＥＣＵ４、及び車両の乗員によって操作されるＨＭＩ装置７を制御するＥＣＵ４等を含む。ＨＭＩは、Ｈｕｍａｎ　Ｍａｃｈｉｎｅ　Ｉｎｔｅｒｆａｃｅの略である。
　車外通信装置５は、広域無線通信網を介して、クラウドサーバ２００及び利用者端末３００等の車外装置との間でデータ通信を行う。
　車内通信網６は、ＣＡＮ　ｗｉｔｈ　Ｆｌｅｘｉｂｌｅ　Ｄａｔａ　Ｒａｔｅ（以下、ＣＡＮ　ＦＤ）とイーサネットとを備える。イーサネットは登録商標である。ＣＡＮ　ＦＤは、ＥＣＵ２と各ＥＣＵ３及び車外通信装置５とをバス接続する。イーサネットは、ＥＣＵ２と各ＥＣＵ３及び車外通信装置５との間を個別に接続する。ＥＣＵ２は、使用するイーサネットを切り替えるイーサネットスイッチを備えてもよい。
　ＥＣＵ２は、ＣＰＵ２ａ、ＲＯＭ２ｂ、及びＲＡＭ２ｃ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。マイクロコンピュータの各種機能は、ＣＰＵ２ａが非遷移的実体的記録媒体に格納されたプログラムを実行することにより実現される。この例では、ＲＯＭ２ｂが、プログラムを格納した非遷移的実体的記録媒体に該当する。また、このプログラムの実行により、プログラムに対応する方法が実行される。なお、ＣＰＵ２ａが実行する機能の一部又は全部を、一つあるいは複数のＩＣ等によりハードウェア的に構成してもよい。また、ＥＣＵ２を構成するマイクロコンピュータの数は一つでも複数でもよい。
　ＥＣＵ３、ＥＣＵ４、及び車外通信装置５は、いずれも、ＥＣＵ２と同様に、ＣＰＵ、ＲＯＭ、及びＲＡＭ等を備えたマイクロコンピュータを中心に構成された電子制御装置である。また、ＥＣＵ３、ＥＣＵ４、及び車外通信装置５を構成するマイクロコンピュータの数は一つでも複数でもよい。
　以下では、ＥＣＵ２、ＥＣＵ３、ＥＣＵ４、及び車外通信装置５を、特に区別しない場合は、車載装置２～５と称する。
　［２．機能構成］
　車載システム１００に属する車載装置２～５に搭載されるソフトウェアは、例えば、ＡＵＴＯＳＡＲに沿って構築される。ＡＵＴＯＳＡＲは、自動運転用のアーキテクチャであり、AUTomotive Open System Architectureの略である。ＡＵＴＯＳＡＲは、種々のアプリケーションを実現するために実装されるソフトウェアコンポーネント（以下、ＳＷ－Ｃ）間の通信だけでなく、クラウドとの接続やセキュリティ等に関する機能も提供する。ＳＷ－Ｃは、ある機能を実現するために部品化されたソフトウェアである。アプリケーションプログラムは、一つ以上のＳＷ－Ｃを含む。なお、モビリティサービス提供システム１のソフトウェアは、必ずしもＡＵＴＳＡＲに沿って構築される必要はない。
　車載装置２～５は、いずれも、プラットフォームを備える。プラットフォームは、ハードウェアに依存しない形式で記述されたＳＷ－Ｃを実行する環境を提供する。
　プラットフォームは、ランタイム環境（以下、ＲＴＥ）と、基盤ソフトウェア（以下、ＢＳＷ）とを備える。ＲＴＥは、ＳＷ－Ｃ同士、及びＳＷ－ＣとＢＳＷとの間をつなぐインタフェースである。ＢＳＷは、ハードウェアとＳＷ－Ｃとをつなぐ階層であり、ＯＳ、ドライバ、ミドルウェア等を含む。ＢＳＷの機能は、細かいモジュールに分割される。各モジュールの機能は、Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍｍｉｎｇ　Ｉｎｔｅｒｆａｃｅ（以下、ＡＰＩ）を介してＳＷ－Ｃに提供される。
　図２に示すように、車載装置２～５は、プラットフォーム上で動作するサービスアプリケーション（以下、サービスアプリ）の集合として、サービス系機能ブロック群２１を備える。サービスアプリは、クライアントからリクエストを受け、処理し、結果を返すアプリケーションである。個々のサービスアプリは、一つ以上のＳＷ－Ｃによって構成される。サービスアプリは、車載装置２～５のいずれかだけでなく、クラウドサーバ２００等、車外通信装置５を介して車内通信網６にリモート接続される外部装置に実装されてもよい。
　サービス系機能ブロック群２１は、Ｏｒｉｇｉｎａｌ　Ｅｑｕｉｐｍｅｎｔ　Ｍａｎｕｆａｃｔｕｒｅｒ（以下、ＯＥＭ）によって提供されるサービスアプリ（以下、ＯＥＭアプリ）を含む。ＯＥＭは、車両を製造した車両メーカである。ＯＥＭアプリには、ＯＥＭ自身によって開発されたアプリと、他ベンダーによって開発されたアプリとが存在してもよい。サービス系機能ブロック群２１は、サードパーティによって提供されるサービスアプリ（以下、３ｒｄアプリ）を含んでもよい。サードパーティは、車両の所有者、及びＯＥＭ以外の第三者である。サードパーティとして、例えば、車両からデータを収集することによってサービスを提供するデータ活用業者が挙げられる。
　プラットフォームは、制御系機能ブロック群２２と、データ系機能ブロック群２３と、ＡＰＩゲートウェイ３０とを備える。
　制御系機能ブロック群２２は、車両の運動に関わる指令を受け付けるＡＰＩを備え、ＡＰＩが受け付けた指令を統括して、整合のとれた車両制御を実現するサービスアプリの集合である。制御系機能ブロック群２２は、種々の指令を、該指令に基づく制御を実行する実体が存在する車載装置３～５に対して、車内通信網６を介して出力する。なお、制御系機能ブロック群２２は、車両に依存しない形式で表現されているサービス系機能ブロック群２１からの種々の指令（すなわち、ＡＰＩアクセス要求）を、車両に依存した形式で表現された指令に変換する機能を有してもよい。
　データ系機能ブロック群２３は、車載装置２～５が有する車両データを扱うためのＡＰＩを備えたサービスアプリの集合である。データ系機能ブロック群２３は、各車載装置２～５から供給される、車両に依存した形式で表現された車両データを、車両に依存しない形式に抽象化して蓄積する機能を提供するＡＰＩを有してもよい。データ系機能ブロック群２３は、蓄積された車両データを、車外通信装置５を介してクラウドサーバ２００にアップロードする機能を提供するＡＰＩを有してもよい。
　以下では、制御系機能ブロック群２２及びデータ系機能ブロック群２３に属するサービスアプリが提供するＡＰＩを、車両ＡＰＩという。車両ＡＰＩには、車外通信装置５を介してクラウドサーバ２００等から後述するアクセス認可ポリシーを取得する機能を提供するＡＰＩが含まれてもよい。車両ＡＰＩには、車外通信装置５を介して利用者端末３００と通信する機能を提供するＡＰＩが含まれてもよい。車両ＡＰＩには、車両に設けられたＨＭＩ装置７を介して乗員に対する情報提供及び乗員による入力操作の受付を行う機能を提供するＡＰＩが含まれてもよい。車両ＡＰＩには、車両に設けられた乗員認識センサ８から乗員の有無の判定に必要な情報を取得する機能を提供するＡＰＩが含まれてもよい。乗員認識センサ８は、車室内を撮影するカメラであってもよいし、座席に加わる荷重を検出する圧力センサであってもよい。
　ＡＰＩゲートウェイ３０は、仮想機能バス（以下、ＶＢＦ）の機能を利用して構成される。ＶＢＦは、ＳＷ－Ｃ間の通信、及びＳＷ－ＣとＢＳＷとの間の通信を、ハードウェアや通信プロトコル等を意識せず実現できるようにするミドルウェアであり、ソフトウェアバスともいう。ＳＷ－Ｃ間の通信とは、サービス系機能ブロック群２１に属するサービスアプリ間で行う、ＳＷ－Ｃから他のＳＷ－Ｃが提供するＡＰＩへのアクセスである。ＳＷ－ＣとＢＳＷとの間の通信とは、サービス系機能ブロック群２１に属するサービスアプリと、制御系機能ブロック群２２及びデータ系機能ブロック群２３に属するサービスアプリとの間で行う、ＳＷ－Ｃから車両ＡＰＩへのアクセスである。以下では、ＳＷ－Ｃとサービスアプリとが１対１で対応するものとして説明する。
　サービスアプリは、制御系機能ブロック群２２及びデータ系機能ブロック群２３が提供する機能を利用する場合、車両ＡＰＩへのアクセス要求であるＡＰＩアクセス要求を送信する。ＡＰＩアクセス要求は、利用元となるサービスアプリ（以下、利用元アプリ）のプロセスＩＤ、及び利用先となる車両ＡＰＩ（以下、利用先ＡＰＩ）を一意に識別する情報であるＡＰＩ－ＩＤを少なくとも含む。
　［３．アクセス制限機構］
　ＡＰＩゲートウェイ３０は、サービス系機能ブロック群２１、制御系機能ブロック群２２、及びデータ系機能ブロック群２３のいずれかが搭載される可能性がある、すべての車載装置２～５のプラットフォームが備える。
　ＡＰＩゲートウェイ３０は、情報記憶部３１と、アクセス制御部３２と、車両判定部３３と、乗車判定部３４と、ポリシー更新部３５とを備える。
　情報記憶部３１には、アクセス認可ポリシー３１１と、対応テーブル３１２と、利用者情報３１３とが記憶される。対応テーブル３１２は、ＲＡＭ２ｃに記憶されてもよい。アクセス認可ポリシー３１１、利用者情報３１３は、ＲＯＭ２ｂに記憶されてもよい。但し、アクセス認可ポリシー３１１、利用者情報３１３は、不揮発性のＲＡＭ２ｃに記憶されてもよい。
　アクセス認可ポリシー３１１は、サービスアプリから車両ＡＰＩへのアクセス権限の有無を判定するための情報の集合である。アクセス認可ポリシー３１１は、例えば、データ系機能ブロック群２３に属するサービスアプリの機能を用いてクラウドサーバ２００からダウンロードされて、情報記憶部３１に記憶される。アクセス認可ポリシーは、図３に示すように、例えば、アプリＩＤで特定される利用元アプリから、ＡＰＩ－ＩＤで特定される利用先ＡＰＩへのアクセス権限の有無を定義した一覧表によって表される。
　アクセス認可ポリシー３１１は、例えば、セキュリティ保護資産として定義される属性であるＳ．Ｆ．Ｏ．Ｐの観点を考慮して設計されてもよい。Ｓは、Ｓａｆｔｙの略であり、安全性に影響するＡＰＩアクセスに対するアクセス制限を意味する。Ｆは、Ｆｉｎａｎｃｉａｌの略であり、企業もしくは個人の財産に影響するＡＰＩアクセスに対するアクセス制限を意味する。Ｏは、Ｏｐｅｒａｔｉｏｎａｌの略であり、車両の操作性能に影響するＡＰＩアクセスに対するアクセス制限を意味する。Ｐは、Ｐｒｉｖａｃｙの略であり、プライバシー情報に影響するＡＰＩアクセスに対するアクセス制限を意味する。
　対応テーブル３１２は、オペレーティングシステム（以下、ＯＳ）におけるプログラムの実行単位であるプロセスに対して動的に割り当てられるプロセスＩＤと、そのプロセスで実行されるサービスアプリが有する固有のアプリＩＤとを対応づける情報を含む。また、対応テーブル３１２は、個々の車両ＡＰＩが有する固有のＡＰＩ－ＩＤと、ＡＰＩの機能を実行する実体であるサービスアプリに割り当てられたプロセスのプロセスＩＤと、を対応づける情報を含む。対応テーブル３１２は、システムの起動時に、サービスアプリ毎のプロセスが生成されるときに、ＯＳによって生成される。
　なお、アクセス認可ポリシー３１１と対応テーブル３１２とを組み合わせることで、一つのテーブルを生成してもよい。具体的には、対応テーブル３１２に示されるアプリＩＤとプロセスＩＤとの対応づけ、及びＡＰＩ－ＩＤとプロセスＩＤとの対応付けを参照し、利用元アプリのプロセスＩＤから利用先ＡＰＩのプロセスＩＤへのアクセス権限の有無を示すテーブルを生成してもよい。
　利用者情報３１３は、車両利用者によって任意に設定される情報である。例えば、利用者情報３１３は、車両利用者を識別する利用者ＩＤに対応付けて、車両利用者への連絡先、例えば、所持する携帯端末の電話番号、メールアドレス等が記憶される。車両利用者は、車両の所有者であってもよいし、シェアカー等の車両を一時的に利用する利用者であってもよい。
　アクセス制御部３２は、ＡＰＩアクセス要求を受け付けると、ＡＰＩアクセス要求に示されたプロセスＩＤから、対応テーブル３１２を用いて利用元アプリのアプリＩＤを特定する。アクセス制御部３２は、特定されたアプリＩＤと、ＡＰＩアクセス要求に示された利用先ＡＰＩのＡＰＩ－ＩＤとに基づき、アクセス認可ポリシー３１１に従って、アクセス権限の有無を判定するアクセス制限処理を実行する。アクセス制限処理の詳細については後述する。
　車両判定部３３は、ポリシー更新部３５からの要求に従って車両状態及びバッテリ状態を判定して、判定結果をポリシー更新部３５に提供する。具体的には、車両判定部３３は、制御系機能ブロック群２２が提供するＡＰＩを利用して、車速、シフトレバー位置等の情報を取得することによって、車両状態が駐車中、停車中、走行中のいずれに該当するかを判定する。例えば、シフトレバー位置がパーキングである場合は駐車中と判定し、シフトレバー位置がパーキング以外である場合、車速の絶対値が所定値（例えば、１ｋｍ／ｈ）未満であれば以下であれば停車中、所定値以上であれば走行中と判定する。また、車両判定部３３は、制御系機能ブロック群２２が提供するＡＰＩを利用して、バッテリ電圧を取得することによって、バッテリ状態が、通常状態にあるか、低電圧状態にあるかを判定する。低電圧状態は、ＡＰＩゲートウェイ３０としての機能を実現する処理を実行するマイクロコンピュータが、誤作動する可能性が、予め設定された許容値を超えて高くなるような電圧範囲にあることをいう。
　乗車判定部３４は、ポリシー更新部３５からの要求に従って、乗員の有無を判定して、判定結果をポリシー更新部３５に提供する。具体的には、乗車判定部３４は、制御系機能ブロック群２２が提供するＡＰＩを利用して、乗員認識センサ８の検知結果を取得して、乗員の有無を判定する。
　ポリシー更新部３５は、アクセス認可ポリシーの更新が必要な状況が検出された場合に、車両判定部３３及び乗車判定部３４での判定結果に従ってアクセス認可ポリシーの更新を実行する。
　［５．処理］
　［５－１．アクセス制限処理］
　アクセス制御部３２が実行するアクセス制限処理を、図４のフローチャートを用いて説明する。アクセス制限処理は、ＡＰＩゲートウェイ３０が起動すると繰り返し実行される。
　Ｓ１１０では、アクセス制御部３２は、サービスアプリからＡＰＩアクセス要求を受け付けたか否かを判定し、ＡＰＩアクセス要求を受け付けていれば処理をＳ１２０に移行し、ＡＰＩアクセス要求を受け付けていなければ、同ステップを繰り返すことで待機する。
　Ｓ１２０では、アクセス制御部３２は、ＡＰＩアクセス要求に示された情報に基づき、アクセス認可ポリシー３１１を参照して、ＡＰＩアクセス要求の要求元である利用元アプリが利用先ＡＰＩに対するアクセス権限を有するか否かを判定する。具体的には、アクセス制御部３２は、まず、対応テーブル３１２を用いて、ＡＰＩアクセス要求に示されたプロセスＩＤから利用元アプリのアプリＩＤを特定する。そして、アクセス制御部３２は、特定されたアプリＩＤと、ＡＰＩアクセス要求に示された利用先ＡＰＩのＡＰＩ－ＩＤとに基づき、アクセス認可ポリシー３１１を参照して、利用元アプリから利用先ＡＰＩへのアクセス権限の有無を判定する。
　続くＳ１３０では、アクセス制御部３２は、利用元アプリから利用先ＡＰＩへのアクセス権限が有ると判定した場合は、処理をＳ１４０に移行し、アクセス権限が無いと判定した場合は処理をＳ１５０に移行する。
　Ｓ１４０では、アクセス制御部３２は、利用元アプリから利用先ＡＰＩへのアクセスを許可し、すなわち、ＡＰＩアクセス要求を利用先ＡＰＩに伝達して処理を終了する。
　Ｓ１５０では、アクセス制御部３２は、利用元アプリから利用先ＡＰＩへのアクセスを拒否し、すなわち、ＡＰＩアクセス要求を破棄して、処理を終了する。
　なお、Ｓ１５０では、単にＡＰＩアクセス要求を破棄する代わりに、アクセス制御部３２は、ＨＭＩ装置７を介して、車両利用者へ当該アクセスの可否を確認してもよい。そして、アクセス制御部３２は、ＨＭＩ装置７を介して、当該アクセスを許可することを示す許可入力を受け付けた場合、処理をＳ１４０に移行し、当該アクセスを許可しないことを示す不許可入力を受け付けた場合、ＡＰＩアクセス要求を破棄してもよい。
　［５－２．ポリシー更新処理］
　ポリシー更新部３５が実行するポリシー更新処理を、図５のフローチャートを用いて説明する。ポリシー更新処理は、ＡＰＩゲートウェイ３０が起動すると繰り返し実行される。
　Ｓ２１０では、ポリシー更新部３５は、未インストールの更新情報が存在するか否かを判定する。ポリシー更新部３５は、未インストールの更新情報が存在すると判定した場合、要更新状況であるとして、処理をＳ２４０に移行し、未インストールの更新情報が存在しないと判定した場合、処理をＳ２２０に移行する。
　Ｓ２２０では、ポリシー更新部３５は、アクセス認可ポリシーの更新要求が有るか否かを判定し、更新要求が有れば、要更新状況であるとして処理をＳ２３０に移行し、更新要求が無ければ処理をＳ２１０に戻す。更新要求は、例えば、車載システム１００に提供する新たなアクセス認可ポリシーがクラウドサーバ２００にアップロードされていることを示すクラウドサーバ２００から通知であってもよい。
　Ｓ２３０では、ポリシー更新部３５は、車外通信装置５を介してアクセス認可ポリシーを取得する機能を提供するＡＰＩを用いて、クラウドサーバ２００からアクセス認可ポリシーに更新情報を取得して、処理をＳ２４０に進める。
　Ｓ２４０では、ポリシー更新部３５は、車両判定部３３を介して車両状態を取得する。
　続くＳ２５０では、ポリシー更新部３５は、取得した車両状態が駐車中であるか否かを判定する。ポリシー更新部３５は、駐車中であると判定した場合、アクセス認可ポリシーの更新を安全に実行可能な安全状態であるとして、処理をＳ２６０に移行し、駐車中ではないと判定した場合、処理をＳ２７０に移行する。
　Ｓ２６０では、ポリシー更新部３５は、駐車中更新処理を実行して処理を終了する。
　Ｓ２７０では、ポリシー更新部３５は、取得した車両状態が停車中であるか否かを判定する。ポリシー更新部３５は、停車中であると判定した場合、安全状態であるとして処理をＳ２８０に移行し、停車中ではないと判定した場合、すなわち、走行中であれば、安全状態ではないとして、処理をＳ２９０に移行する。
　Ｓ２８０では、ポリシー更新部３５は、停車中更新処理を実行して処理を終了する。
　Ｓ２９０では、ポリシー更新部３５は、更新を禁止して処理を終了する。更新を禁止された場合、更新情報は、削除されることなく、未インストールの更新情報として保持される。
　［５－３．駐車中更新処理］
　ポリシー更新部３５が、Ｓ２６０で実行する駐車中更新処理を、図６のフローチャートを用いて説明する。
　Ｓ３００では、ポリシー更新部３５は、乗車判定部３４を介して乗車状態を取得する。
　続くＳ３１０では、ポリシー更新部３５は、取得した乗車状態から車両利用者が乗車しているか否かを判定し、車両利用者が乗車していれば処理をＳ３２０に移行し、車両利用者が乗車していなければ処理をＳ３５０に移行する。
　Ｓ３２０では、ポリシー更新部３５は、車両利用者に対して更新確認を通知済であるか否かを判定し、更新確認を通知済みであれば、処理をＳ３４０に移行し、更新確認を通知済みでなければ、処理をＳ３３０に移行する。
　Ｓ３３０では、ポリシー更新部３５は、ＨＭＩ装置７を介して、アクセス認可ポリシーの更新の可否を確認する機能を提供するＡＰＩを用いて、更新確認通知を送信して、処理を終了する。
　Ｓ３４０では、ポリシー更新部３５は、ＨＭＩ装置７を介して、アクセス認可ポリシーの更新を許可する許可入力を受け付けたか否かを判定し、許可入力を受け付けていれば処理をＳ３５０に移行し、許可入力を受け付けていなければ処理を終了する。
　Ｓ３５０では、ポリシー更新部３５は、車両判定部３３を介してバッテリ状態を取得する。
　続くＳ３６０では、ポリシー更新部３５は、取得したバッテリ状態が低電圧状態であるか否かを判定し、低電圧状態であれば、処理をＳ３７０に移行し、低電圧状態でなければ、処理をＳ３８０に移行する。
　Ｓ３７０では、ポリシー更新部３５は、アクセス許可ポリシーの更新を限定的に行って処理を終了する。具体的には、アクセス認可ポリシーにおいて、アクセス権限ありからアクセス権限なしに変更されている部分についてのみインストールを実行する。更新された部分以外の更新情報は、未インストールの更新情報として保持される。
　Ｓ３５０では、ポリシー更新部３５は、バッテリ状態だけでなく、駐車中におけるアプリケーションの動作状況を取得してもよい。この場合、例えば、Ｓ３６０では、駐車中に診断処理、又はプログラムの更新処理が実行されている場合は、低電圧状態であると判定された場合と同様に、Ｓ３７０に移行し、アクセス認可ポリシーの更新を限定的に行ってもよい。
　Ｓ３８０では、ポリシー更新部３５は、更新情報の全てについてインストールを実行して、処理を終了する。この場合、未インストールの更新情報は存在しない状態となる。
　［５－４．停車中更新処理］
　ポリシー更新部３５が、Ｓ２８０で実行する停車中更新処理を、図７のフローチャートを用いて説明する。
　Ｓ４００では、ポリシー更新部３５は、乗車判定部３４を介して乗車状態を取得する。
　続くＳ４１０では、ポリシー更新部３５は、取得した乗車状態から車両利用者が乗車しているか否かを判定し、車両利用者が乗車していれば処理をＳ４２０に移行し、車両利用者が乗車していなければ処理をＳ４６０に移行する。
　Ｓ４２０では、ポリシー更新部３５は、車両利用者に対して更新確認を通知済であるか否かを判定し、更新確認を通知済みであれば、処理をＳ４４０に移行し、更新確認を通知済みでなければ、処理をＳ４３０に移行する。
　Ｓ４３０では、ポリシー更新部３５は、ＨＭＩ装置７を介してアクセス認可ポリシーの更新の可否を確認する機能を提供するＡＰＩを介して、更新確認通知を送信して、処理を終了する。
　Ｓ４４０では、ポリシー更新部３５は、ＨＭＩ装置７を介して、アクセス認可ポリシーの更新を許可する許可入力を受け付けたか否かを判定し、許可入力を受け付けていれば処理をＳ４５０に移行し、許可入力を受け付けていなければ処理を終了する。
　Ｓ４５０では、ポリシー更新部３５は、更新情報の全てについてインストールを実行して、処理を終了する。この場合、未インストールの更新情報は存在しない状態となる。
　Ｓ４６０では、ポリシー更新部３５は、車両利用者に対して更新確認を通知済であるか否かを判定し、更新確認を通知済みであれば、処理をＳ４８０に移行し、更新確認を通知済みでなければ、処理をＳ４７０に移行する。
　Ｓ４７０では、ポリシー更新部３５は、車外通信装置５を介して利用者端末３００にアクセス認可ポリシーの更新の可否を確認する通知を行う機能を提供するＡＰＩを利用して、更新確認通知を送信して、処理を終了する。
　Ｓ４８０では、ポリシー更新部３５は、車外通信装置５を介して利用者端末３００から、アクセス認可ポリシーの更新を許可する許可通知を受け付けたか否かを判定する。ポリシー更新部は、許可通知を受け付けていると判定した場合は処理をＳ４９０に移行し、許可通知を受け付けていないと判定した場合は処理を終了する。
　Ｓ４９０では、ポリシー更新部３５は、更新情報の全てについてインストールを実行して、処理を終了する。この場合、未インストールの更新情報は存在しない状態となる。
　つまり、停車中更新処理では、車両利用者が乗車していれば、ＨＭＩ装置７を介して更新の可否を確認し、車両利用者が乗車していなければ、予め登録された利用者端末３００を介して更新の可否を確認する。そして、更新許可の確認が得られた場合にのみアクセス許可ポリシーの更新（すなわち、更新情報のインストール）を実行する。
　［６．用語の対応］
　本実施形態におけるサービス系機能ブロック群２１、制御系機能ブロック群２２、及びデータ系機能ブロック群２３が、本開示における複数の機能ブロックに相当する。ＡＰＩゲートウェイ３０が、本開示における連携制御部に相当する。Ｓ２１０～Ｓ２２０が、本開示における要否判定部に相当する。Ｓ２４０、Ｓ２５０、及びＳ２７０が、本開示における状態判定部に相当する。Ｓ２６０，Ｓ２８０が、本開示における更新実行部に相当する。Ｓ３２０～Ｓ３３０、Ｓ４２０～Ｓ４３０、及びＳ４６０～Ｓ４７０が、本開示における許可確認部に相当する。Ｓ３４０、Ｓ４４０、及びＳ４８０が、本開示における作動許可部に相当する。Ｓ３００～Ｓ３１０、及びＳ４００～Ｓ４１０が、本開示における乗員判定部に相当する。Ｓ４３０が、本開示における第１確認部に相当する。Ｓ４７０が、本開示における第２確認部に相当する。Ｓ３５０～Ｓ３６０が、本開示におけるバッテリ状態監視部に相当する。Ｓ３７０が、本開示における限定更新部に相当する。
　［７．効果］
　以上詳述した実施形態によれば、以下の効果を奏する。
　（ａ）クラウドサーバ２００（すなわち、Ｏｕｔ－Ｃａｒ）側で、アクセス認可ポリシーの更新情報が用意された場合、車載システム１００では、車両状態が駐車中又は停車中のときに、アクセス認可ポリシーの更新を許可する。従って、アクセス認可ポリシーが切り替わることにより車両制御の内容に変化が生じたとしても、その変化が車両の移動中に生じることがないため、安全性を確保できる。
　（ｂ）停車中の場合、車両利用者に対して更新の可否を確認し、更新許可が確認された場合に更新を実施する。つまり、信号待ち等で停車中の場合、直ぐに車両が動き出すことがない状況であるか否か、すなわち、更新に適した状況であるか否かを車両利用者に確認することで、より安全な状況でアクセス認可ポリシーの更新を実施できる。
　（ｃ）停車中の場合、車両利用者への確認を行う際に、車両利用者が乗車していれば、ＨＭＩ装置７を用い、車両利用者が乗車していなければ、予め登録された利用者端末３００を用いる。したがって、車両利用者の乗車状況に応じた的確な手段によって、車両利用者の意図を確認できる。
　（ｄ）駐車中の場合、車両利用者が乗車していれば、車両が動きだす可能性があるため、停車中の場合と同様に車両利用者への確認を行う。また、車両利用者が乗車していなければ、車両が動きだす可能性が低いため、車両利用者への確認を省略して、アクセス認可ポリシーの更新を実行する。このように、車両利用者に対する確認が、確認が必要な状況にのみ行われるため、不必要な確認によって車両利用者を煩わせることを抑制できる。
　（ｅ）駐車中の場合、自動的にバッテリが充電されることがないため、バッテリ状態が低電圧状態にある場合は、更新情報の全部を認可ポリシーの更新に用いるのではなく、安全側に作用する更新情報についてのみ、認可ポリシーの更新に用いる。その後、駐車中以外の状態になり、バッテリの充電が可能な状態になってから、残りの更新情報を、認可ポリシーの更新に用いる。従って、更新による電力消費を必要最小限とすることができ、また、更新中に電圧低下による誤作動（例えば、更新情報のビット誤り等）が生じることを抑制できる。
　［８．他の実施形態］
　以上、本開示の実施形態について説明したが、本開示は上述の実施形態に限定されることなく、種々変形して実施することができる。
　（ａ）上述の実施形態では、更新要求を、クラウドサーバ２００にアクセス認可ポリシーの更新情報が用意されたときに発生させているが、更新要求を発生させる契機は、更新情報が容易されたときに限定されない。例えば、異常が検出されたときに、アクセス認可ポリシーの更新要求を発生させてもよい。この場合、情報記憶部３１に、異常時用のアクセス認可ポリシーを予め用意しておき、異常による更新要求が発生した場合には、アクセス認可ポリシーを正常時用から異常時用に切り替えてもよい。
　（ｂ）上述の実施形態では、車両利用者への確認を行う際に、車両利用者が乗車していればＨＭＩ装置７を用いているが、乗車していない場合と同様に、利用者端末３００を用いてもよい。
　（ｃ）上述の実施形態では、車両状態が駐車中の場合、車両利用者が乗車しているときだけ、車両利用者への確認を行なっているが、車両利用者が乗車しているか否かに関わらず、常に、車両利用者への確認を行ってもよい。
　（ｄ）上述の実施形態では、クラウドサーバ２００から更新要求通知を受信した場合に、クラウドサーバ２００からアクセス認可ポリシーの更新情報を取得している。例えば、クラウドサーバ２００から車載システム１００に更新情報が自動的にダウンロードされ、更新情報のダウンロードが確認されると、車載システム１００の内部で更新要求通知が発生するように構成されてもよい。この場合、図５におけるＳ２３０の処理は省略される。
　（ｅ）上記実施形態では、車両状態等に応じたアクセス認可ポリシーの更新を、全てのＡＰＩに適用しているが、センサやアクチュエータの動作を伴う制御系機能ブロック群２２が提供するＡＰＩに関するアクセス認可ポリシーについてだけ適用してもよい。この場合、データの取得等に用いるデータ系機能ブロック群２３が提供するＡＰＩに関するアクセス認可ポリシーについては、未インストールの更新情報があれば車両状態等に関係なく更新処理をしてもよい。
　（ｆ）本開示に記載の車載装置２～５及びその手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリを構成することによって提供された専用コンピュータにより、実現されてもよい。あるいは、本開示に記載の車載装置２～５及びその手法は、一つ以上の専用ハードウェア論理回路によってプロセッサを構成することによって提供された専用コンピュータにより、実現されてもよい。もしくは、本開示に記載の車載装置２～５及びその手法は、一つ乃至は複数の機能を実行するようにプログラムされたプロセッサ及びメモリと一つ以上のハードウェア論理回路によって構成されたプロセッサとの組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体に記憶されてもよい。車載装置２～５に含まれる各部の機能を実現する手法には、必ずしもソフトウェアが含まれている必要はなく、その全部の機能が、一つあるいは複数のハードウェアを用いて実現されてもよい。
　（ｇ）上記実施形態における１つの構成要素が有する複数の機能を、複数の構成要素によって実現したり、１つの構成要素が有する１つの機能を、複数の構成要素によって実現したりしてもよい。また、複数の構成要素が有する複数の機能を、１つの構成要素によって実現したり、複数の構成要素によって実現される１つの機能を、１つの構成要素によって実現したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加又は置換してもよい。
　（ｈ）上述した車載システム１００の他、当該車載システム１００を構成要素とするシステム、当該車載システム１００としてコンピュータを機能させるためのプログラム、このプログラムを記録した半導体メモリ等の非遷移的実体的記録媒体など、種々の形態で本開示を実現することもできる。
　［９．本明細書が開示する技術思想］
　［項目１］
　それぞれが車載ネットワークに接続された複数の電子制御装置のいずれか、又は前記車載ネットワークにリモート接続される外部装置に搭載され、それぞれが決められた処理を実行するように構成された複数の機能ブロックと、
　前記複数の機能ブロック間の連携を実現するように構成された連携制御部と、
　を備え、
　前記連携制御部は、
　前記複数の機能ブロックの一つである利用元ブロックから、前記複数の機能ブロックの他の一つである利用先ブロックへのアクセス要求を受け付けると、前記機能ブロック間のアクセス権限を規定するアクセス認可ポリシーを用いて、前記利用先ブロックに対する前記利用元ブロックの前記アクセス権限の有無を判定し、前記アクセス権限が有ると判定した場合、前記アクセス要求を前記利用先ブロックに伝達するように構成されたアクセス制御部と、
　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定するように構成された要否判定部と、
　前記車載ネットワークを搭載する車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定するように構成された状態判定部と、
　前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施するように構成された更新実行部と、
　を備える、車載システム。
　［項目２］
　項目１に記載の車載システムであって、
　前記更新実行部は、
　前記アクセス認可ポリシーの更新を実施することについて車両利用者の許可があるか否かを確認するように構成された許可確認部と、
　前記許可確認部により前記車両利用者の許可が確認された場合に、前記更新実行部の作動を許可するように構成された作動許可部と、
　を更に備える、車載システム。
　［項目３］
　項目２に記載の車載システムであって、
　前記許可確認部は、前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により前記安全状態にあると判定された場合に、前記車両利用者の許可があるか否かを確認するように構成された
　車載システム。
　［項目４］
　項目２又は項目３に記載の車載システムであって、
　前記更新実行部は、
　前記車両に乗車している乗員の有無を判定するように構成された乗員判定部を更に備え、
　前記許可確認部は、
　前記乗員判定部にて乗員があると判定された場合、前記車両に装備されたＨＭＩ装置を介して、前記車両利用者の許可を確認するように構成された第１確認部と、
　前記乗員判定部にて乗員がないと判定された場合、予め登録された利用者端末を介して、前記車両利用者の許可を確認するように構成された第２確認部と、
　を備える、車載システム。
　［項目５］
　項目１から項目４までのいずれか１項に記載の車載システムであって、
　前記更新実行部は、
　前記車両に搭載されたバッテリの状態を監視するように構成されたバッテリ状態監視部と、
　前記バッテリの状態が、当該更新実行部の作動が不安定となる可能性がある低電圧状態である場合、前記アクセス認可ポリシーの更新を部分的に実施する限定更新部と、
　を更に備える、車載システム。
　［項目６］
　項目１から項目５までのいずれか１項に記載の車載システムであって、
　前記安全状態は、前記車両が駐車中又は停車中の状態である
　車載システム。
　［項目７］
　項目１から項目６までのいずれか１項に記載の車載システムであって、
　前記要否判定部は、前記アクセス認可ポリシーの更新情報が存在する場合に、前記要更新状況であると判定する
　車載システム。
　［項目８］
　項目１から項目７までのいずれか１項に記載の車載システムであって、
　前記要否判定部は、前記車両の異常を検出した場合に、前記要更新状況であると判定する
　車載システム。
　［項目９］
　車両に搭載される電子制御装置であって、
　それぞれが決められた処理を実行するように構成された複数の機能ブロックの一つである利用元ブロックから、前記複数の機能ブロックの他の一つである利用先ブロックへのアクセス要求を受け付けると、前記複数の機能ブロック間のアクセス権限を規定するアクセス認可ポリシーを用いて、前記利用先ブロックに対する前記利用元ブロックの前記アクセス権限の有無を判定し、前記アクセス権限が有ると判定した場合、前記アクセス要求を前記利用先ブロックに伝達するように構成されたアクセス制御部と、
　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定するように構成された要否判定部と、
　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定するように構成された状態判定部と、
　前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施するように構成された更新実行部と、
　を備える、電子制御装置。
　［項目１０］
　項目９に記載の電子制御装置であって、
　前記要否判定部は、前記アクセス認可ポリシーの更新情報が存在する第１の状況である場合、及び前記車両の異常を検出した第２の状況である場合に、前記要更新状況であると判定するように構成され、
　前記更新実行部は、前記第１の状況である場合、当該電子制御装置が接続された車載ネットワークにリモート接続される外部装置から取得する更新情報を用いて正常時用のアクセス認可ポリシーを更新し、前記第２の状況である場合、前記正常時用のアクセス認可ポリシーとは別に用意されている異常時用のアクセス認可ポリシーに切り替えて使用するように構成された
　電子制御装置。
　［項目１１］
　車両に搭載された電子制御装置によって実施され、それぞれが決められた処理を実行するように構成された複数の機能ブロック間のアクセス権限を規定したアクセス認可ポリシーを更新するアクセス認可ポリシー更新方法であって、
　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定すること、
　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定すること、
　前記要更新状況にあると判定され、かつ、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施すること、
　を含む、アクセス認可ポリシー更新方法。
　［項目１２］
　車両に搭載されたコンピュータに、
　それぞれが決められた処理を実行するように構成された複数の機能ブロック間のアクセス権限を規定したアクセス認可ポリシーについて、前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定する機能、
　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定する機能、
　前記要更新状況にあると判定され、かつ、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施する機能、
　を実現させるためのプログラム。

Claims (12)

  1. 　それぞれが車載ネットワークに接続された複数の電子制御装置（２～５）のいずれか、又は前記車載ネットワークにリモート接続される外部装置（２００）に搭載され、それぞれが決められた処理を実行するように構成された複数の機能ブロック（２１～２３）と、
    　前記複数の機能ブロック間の連携を実現するように構成された連携制御部（３０）と、
    　を備え、
    　前記連携制御部は、
    　前記複数の機能ブロックの一つである利用元ブロックから、前記複数の機能ブロックの他の一つである利用先ブロックへのアクセス要求を受け付けると、前記機能ブロック間のアクセス権限を規定するアクセス認可ポリシーを用いて、前記利用先ブロックに対する前記利用元ブロックの前記アクセス権限の有無を判定し、前記アクセス権限が有ると判定した場合、前記アクセス要求を前記利用先ブロックに伝達するように構成されたアクセス制御部（３２）と、
    　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定するように構成された要否判定部（３５：Ｓ２１０～Ｓ２２０）と、
    　前記車載ネットワークを搭載する車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定するように構成された状態判定部（３５：Ｓ２４０，Ｓ２５０，Ｓ２７０）と、
    　前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施するように構成された更新実行部（３５：Ｓ２６０，Ｓ２８０）と、
    　を備える、車載システム。
  2. 　請求項１に記載の車載システムであって、
    　前記更新実行部は、
    　前記アクセス認可ポリシーの更新を実施することについて車両利用者の許可があるか否かを確認するように構成された許可確認部（３５：Ｓ３２０～Ｓ３３０，Ｓ４２０～Ｓ４３０，Ｓ４６０～Ｓ４７０）と、
    　前記許可確認部により前記車両利用者の許可が確認された場合に、前記更新実行部の作動を許可するように構成された作動許可部（３５：Ｓ３４０，Ｓ４４０，Ｓ４８０）と、
    　を更に備える、車載システム。
  3. 　請求項２に記載の車載システムであって、
    　前記許可確認部は、前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により前記安全状態にあると判定された場合に、前記車両利用者の許可があるか否かを確認するように構成された
    　車載システム。
  4. 　請求項２に記載の車載システムであって、
    　前記更新実行部は、
    　前記車両に乗車している乗員の有無を判定するように構成された乗員判定部（３５：Ｓ３００～Ｓ３１０，Ｓ４００～Ｓ４１０）を更に備え、
    　前記許可確認部は、
    　前記乗員判定部にて乗員があると判定された場合、前記車両に装備されたＨＭＩ装置（７）を介して、前記車両利用者の許可を確認するように構成された第１確認部（３５：Ｓ４３０）と、
    　前記乗員判定部にて乗員がないと判定された場合、予め登録された利用者端末（３００）を介して、前記車両利用者の許可を確認するように構成された第２確認部（３５：Ｓ４７０）と、
    　を備える、車載システム。
  5. 　請求項１に記載の車載システムであって、
    　前記更新実行部は、
    　前記車両に搭載されたバッテリの状態を監視するように構成されたバッテリ状態監視部（３５：Ｓ３５０～Ｓ３６０）と、
    　前記バッテリの状態が、当該更新実行部の作動が不安定となる可能性がある低電圧状態である場合、前記アクセス認可ポリシーの更新を部分的に実施する限定更新部（３５：Ｓ３７０）と、
    　を更に備える、車載システム。
  6. 　請求項１から請求項５までのいずれか１項に記載の車載システムであって、
    　前記安全状態は、前記車両が駐車中又は停車中の状態である
    　車載システム。
  7. 　請求項１から請求項５までのいずれか１項に記載の車載システムであって、
    　前記要否判定部は、前記アクセス認可ポリシーの更新情報が存在する場合に、前記要更新状況であると判定する
    　車載システム。
  8. 　請求項１から請求項５までのいずれか１項に記載の車載システムであって、
    　前記要否判定部は、前記車両の異常を検出した場合に、前記要更新状況であると判定する
    　車載システム。
  9. 　車両に搭載される電子制御装置であって、
    　それぞれが決められた処理を実行するように構成された複数の機能ブロックの一つである利用元ブロックから、前記複数の機能ブロックの他の一つである利用先ブロックへのアクセス要求を受け付けると、前記複数の機能ブロック間のアクセス権限を規定するアクセス認可ポリシーを用いて、前記利用先ブロックに対する前記利用元ブロックの前記アクセス権限の有無を判定し、前記アクセス権限が有ると判定した場合、前記アクセス要求を前記利用先ブロックに伝達するように構成されたアクセス制御部（３２）と、
    　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定するように構成された要否判定部（３５：Ｓ２１０～Ｓ２２０）と、
    　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定するように構成された状態判定部（３５：Ｓ２４０，Ｓ２５０，Ｓ２７０）と、
    　前記要否判定部にて前記要更新状況にあると判定され、かつ、前記状態判定部により、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施するように構成された更新実行部（３５：Ｓ２６０，Ｓ２８０）と、
    　を備える、電子制御装置。
  10. 　請求項９に記載の電子制御装置であって、
    　前記要否判定部は、前記アクセス認可ポリシーの更新情報が存在する第１の状況である場合、及び前記車両の異常を検出した第２の状況である場合に、前記要更新状況であると判定するように構成され、
    　前記更新実行部は、前記第１の状況である場合、当該電子制御装置が接続された車載ネットワークにリモート接続される外部装置（２００）から取得する更新情報を用いて正常時用のアクセス認可ポリシーを更新し、前記第２の状況である場合、前記正常時用のアクセス認可ポリシーとは別に用意されている異常時用のアクセス認可ポリシーに切り替えて使用するように構成された
    　電子制御装置。
  11. 　車両に搭載された電子制御装置によって実施され、それぞれが決められた処理を実行するように構成された複数の機能ブロック（２１～２３）間のアクセス権限を規定したアクセス認可ポリシーを更新するアクセス認可ポリシー更新方法であって、
    　前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定すること（Ｓ２１０～Ｓ２２０）、
    　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定すること（Ｓ２４０，Ｓ２５０，Ｓ２７０）、
    　前記要更新状況にあると判定され、かつ、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施すること（Ｓ２６０，Ｓ２８０）、
    　を含む、アクセス認可ポリシー更新方法。
  12. 　車両に搭載されたコンピュータに、
    　それぞれが決められた処理を実行するように構成された複数の機能ブロック（２１～２３）間のアクセス権限を規定したアクセス認可ポリシーについて、前記アクセス認可ポリシーの更新を実施する必要がある要更新状況にあるか否かを判定する機能（Ｓ２１０～Ｓ２２０）、
    　前記車両の状態が前記アクセス認可ポリシーの更新を安全に実施可能な安全状態にあるか否かを判定する機能（Ｓ２４０，Ｓ２５０，Ｓ２７０）、
    　前記要更新状況にあると判定され、かつ、前記安全状態にあると判定された場合に、前記アクセス認可ポリシーの更新を実施する機能（Ｓ２６０，Ｓ２８０）、
    　を実現させるためのプログラム。
PCT/JP2023/021939 2022-07-08 2023-06-13 車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム Ceased WO2024009706A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2024531979A JP7708316B2 (ja) 2022-07-08 2023-06-13 車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム
DE112023002999.7T DE112023002999T5 (de) 2022-07-08 2023-06-13 Fahrzeugbordsystem, elektronische steuervorrichtung, zugriffsautorisierungsrichtlinienaktualisierungsverfahren und programm
CN202380051543.3A CN119547072A (zh) 2022-07-08 2023-06-13 车载系统、电子控制装置、访问授权策略更新方法以及程序
US19/006,156 US20250181773A1 (en) 2022-07-08 2024-12-30 In-vehicle system, electronic control device, access authorization policy update method, and storage medium storing program

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2022-110649 2022-07-08
JP2022110649 2022-07-08

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US19/006,156 Continuation US20250181773A1 (en) 2022-07-08 2024-12-30 In-vehicle system, electronic control device, access authorization policy update method, and storage medium storing program

Publications (1)

Publication Number Publication Date
WO2024009706A1 true WO2024009706A1 (ja) 2024-01-11

Family

ID=89453211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/021939 Ceased WO2024009706A1 (ja) 2022-07-08 2023-06-13 車載システム、電子制御装置、アクセス認可ポリシー更新方法、及びプログラム

Country Status (5)

Country Link
US (1) US20250181773A1 (ja)
JP (1) JP7708316B2 (ja)
CN (1) CN119547072A (ja)
DE (1) DE112023002999T5 (ja)
WO (1) WO2024009706A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250245374A1 (en) * 2024-01-29 2025-07-31 Snowflake Inc. Differential privacy on database system using stored procedure

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008193572A (ja) * 2007-02-07 2008-08-21 Hitachi Ltd 車載ゲートウェイ装置
JP2014134483A (ja) * 2013-01-11 2014-07-24 Clarion Co Ltd 情報処理装置、音声操作システム、および、情報処理装置の音声操作方法
WO2022069106A1 (en) * 2020-09-30 2022-04-07 Valeo Comfort And Driving Assistance Security network of connected vehicle

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112585905B (zh) * 2019-11-12 2021-11-19 华为技术有限公司 一种设备升级方法及相关设备

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008193572A (ja) * 2007-02-07 2008-08-21 Hitachi Ltd 車載ゲートウェイ装置
JP2014134483A (ja) * 2013-01-11 2014-07-24 Clarion Co Ltd 情報処理装置、音声操作システム、および、情報処理装置の音声操作方法
WO2022069106A1 (en) * 2020-09-30 2022-04-07 Valeo Comfort And Driving Assistance Security network of connected vehicle

Also Published As

Publication number Publication date
DE112023002999T5 (de) 2025-05-08
CN119547072A (zh) 2025-02-28
JP7708316B2 (ja) 2025-07-15
US20250181773A1 (en) 2025-06-05
JPWO2024009706A1 (ja) 2024-01-11

Similar Documents

Publication Publication Date Title
CN104823165B (zh) 车载程序更新装置
US20200215930A1 (en) Control apparatus, control method, and computer program
US20200283004A1 (en) Method and system for overriding vehicle systems based on special conditions
KR102259596B1 (ko) 제어 장치, 제어 장치용 프로그램을 기록한 컴퓨터 판독 가능한 기록 매체 및 제어 방법
JP5472466B2 (ja) 車両用電子制御装置
JP7605251B2 (ja) モビリティ制御システム、方法、および、プログラム
CN111788810B (zh) 用于机动车的控制系统、用于运行控制系统的方法以及具有这种控制系统的机动车
WO2012105215A1 (ja) 車両用制御装置
KR101960400B1 (ko) 제동 시스템
US20250181773A1 (en) In-vehicle system, electronic control device, access authorization policy update method, and storage medium storing program
US20200156579A1 (en) In-vehicle system
JP2025172889A (ja) ソフトウェア更新装置、ソフトウェア更新方法及びソフトウェア更新処理プログラム
CN117321567A (zh) 车辆用电子控制装置、车辆用电子控制系统以及更新后结构信息判定程序
JP7619524B2 (ja) 車両制御システム、アクセス制御装置、アクセス制御方法
JP7794299B2 (ja) 車両制御装置、及び車両制御システム
US12487813B2 (en) Vehicular electronic control device and update program
US20240101054A1 (en) In-vehicle device and method for starting the same
JP7650573B2 (ja) 情報処理装置、車両システム、および、情報処理方法
CN109600732B (zh) 交通工具中的服务质量
US20260014871A1 (en) Vehicle control device and vehicle control method
JP7760973B2 (ja) 車載装置、プログラム及び情報処理方法
US20260062011A1 (en) Vehicle control system
WO2025047831A1 (ja) アクセス制御装置、アクセス制御方法、及びプログラム
CN119096243A (zh) 移动性服务提供系统、车载系统、管理服务器、访问控制方法以及程序
US20240394396A1 (en) Authentication system and relay device

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23835242

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2024531979

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 202380051543.3

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 112023002999

Country of ref document: DE

WWP Wipo information: published in national office

Ref document number: 202380051543.3

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 112023002999

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 23835242

Country of ref document: EP

Kind code of ref document: A1