Vehicle control system, access control device, and access control method

Abstract

An access control unit (32), upon reception of an access request from one of a plurality of function blocks (23-26), determines in accordance with an authorization policy whether or not to authorize access of the request source block to a request destination interface, and transmits the access request to the request destination interface when access has been authorized. The authorization policy is set using: a provision level that is a safety level indicating the safety of a function ensured by the request source block; and a request level that is a safety level required of the request source block by the request destination interface.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2022-064078 filed with the Japan Patent Office on April 7, 2022, the entire contents of which are incorporated by reference into this international application. [Technical field]

[0002] The present disclosure relates to techniques for protecting vehicle functions. [Background technology]

[0003] The following Patent Document 1 describes a technique in an open platform for mobile terminals, in which when access from an application to a user resource is detected, the access is permitted or not by referring to an access policy. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 6124627 Summary of the Invention

[0005] Meanwhile, platforms that use APIs are beginning to be used in vehicle control systems. An API is an interface prepared to provide vehicle functions, and applications implemented on the platform use the API to realize various functions.

[0006] Platforms applied to vehicle control systems need to realize functions with limited resources while ensuring real-time performance. For this reason, the access policy used to determine whether or not an application has access to each API is set, for example, on an application-by-application basis.

[0007] In this case, even if an access request dynamically generated during application execution contains inappropriate control content, the API will accept the access request and execute the process if it is from an authorized application. In other words, the API cannot eliminate inappropriate access requests from authorized applications. An example of an inappropriate access request is a vehicle control request that causes acceleration beyond the allowable range, to an API that provides a function for controlling the acceleration of a vehicle.

[0008] Furthermore, when third-party applications are introduced in the future, there is a possibility that unexpected and inappropriate access requests caused by the lack of knowledge of the application creators will increase.

[0009] One aspect of the present disclosure provides a technique for restricting inappropriate access requests to an API in a vehicle control system.

[0010] According to an aspect of the present disclosure, there is provided a vehicle control system including a plurality of electronic control units mounted on a vehicle and connected to an in-vehicle network, the plurality of electronic control units including a plurality of function blocks and a cooperation control unit.

[0011] The functional blocks are configured to perform respective predetermined processes, and at least some of the functional blocks are configured to provide a function for controlling the motion of the vehicle. The cooperation control unit realizes cooperation between the functional blocks.

[0012] At least some of the functional blocks include a functional interface configured to provide its own function to other functional blocks.

[0013] The cooperation control unit includes a policy storage unit and an access control unit.

[0014] The policy storage unit is configured to store an authorization policy indicating a rule for authorizing access with respect to an access request from an arbitrary function block to an arbitrary function interface.

[0015] When the access control unit receives an access request from one of a plurality of functional blocks, it determines whether or not to authorize access from the requesting block to the requested interface in accordance with the authorization policy. The requesting block is a functional block that is the source of the access request. The requested interface is a functional interface that is the destination of the access request. The access control unit is configured to transmit the access request to the requested interface if the access is authorized. The authorization policy is set using a provision level, which is a safety level indicating the safety of the function guaranteed by the requesting block, and a request level, which is a safety level that the requested interface requests of the requesting block.

[0016] According to this configuration, only access requests from functional blocks that satisfy the required level of the functional interface can be transmitted to the functional interface of the access destination. Therefore, it is possible to prevent the functional interface that provides a safety-related function from being freely used by a low-reliability functional block or the like, and thus to prevent unexpected control from being executed. In addition, since it is not necessary to include a process for handling requests from functional blocks that do not satisfy the required level in the function provided by the functional interface, the process can be simplified.

[0017] An access control device according to an aspect of the present disclosure includes the above-described multiple functional blocks and a cooperation control unit.

[0018] The access control device can provide the same effects as the vehicle control system.

[0019] In one aspect of the present disclosure, an access control method determines whether to authorize access from a request source block to a destination interface in accordance with an authorization policy for an access request from one of a plurality of function blocks to a function interface. If the access is authorized, the access request is transmitted to the destination interface. The authorization policy is set using a provision level, which is a safety level indicating the safety of the function provided by the request source block, and a request level, which is a safety level requested by the destination interface to the request source block.

[0020] The multiple functional blocks are configured to each execute a predetermined process. The functional interface is an interface that is provided in at least some of the multiple functional blocks and provides the functional blocks with their own functions. The authorization policy indicates a rule for authorizing access to an access request to the functional interface. The requesting block is the functional block that is the source of the access request. The requested interface is the functional interface that is the destination of the access request.

[0021] According to the access control system, it is possible to obtain the same effects as those of the access control device. [Brief description of the drawings]

[0022] [Figure 1] FIG. 2 is a block diagram showing a vehicle control system. [Diagram 2] FIG. 2 is a block diagram showing the configuration of an ECU. [Diagram 3] 1 is a block diagram showing the configuration of an API gateway. [Figure 4] 1 is a table illustrating an example of the contents of an authorization policy. [Diagram 5] FIG. 1 is an explanatory diagram illustrating an example of API access control by an API gateway. [Figure 6] 6 is a table showing an image of an authorization policy resulting from determining whether or not access from SW-C to the API is permitted in the example shown in FIG. 5. [Figure 7]FIG. 1 is an explanatory diagram illustrating an example of API access control by an API gateway. [Figure 8] This is an explanatory diagram showing a method of dividing a service application consisting of multiple microservices into applications that operate independently and assigning them to multiple SW-Cs, and the processing flow in that case. [Figure 9] This is an explanatory diagram showing a method of dividing a service application consisting of multiple microservices into functions for each safety level and allocating them to multiple SW-Cs, and the processing flow in this case. [Figure 10] This is an explanatory diagram showing a method of dividing the functions of a service application composed of multiple microservices into microservices and allocating them to multiple SW-Cs, and the processing flow in that case. [Figure 11] 13 is a flowchart of a process executed by an access control unit. [Figure 12] 13 is a table illustrating the contents of a correspondence table. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0024] [1. Configuration] A first embodiment of the present disclosure will be described below with reference to the drawings.

[0025] The vehicle control system 1 of the present embodiment is mounted on a vehicle. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function and 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. In the following, a vehicle equipped with the vehicle control system 1 is simply referred to as a vehicle.

[0026] 1, the vehicle control system 1 includes one ECU 2, a plurality of ECUs 3, a plurality of ECUs 4, an external communication device 5, and an internal communication network 6. ECU is an abbreviation for Electronic Control Unit.

[0027] The ECU 2 controls a plurality of ECUs 3 to realize coordinated control of the entire vehicle.

[0028] An ECU 3 is provided for each domain divided according to the vehicle's functions, and mainly controls a plurality of ECUs 4 present in that domain. Each ECU 3 is connected to its subordinate ECUs 4 via a lower-layer network (e.g., CAN) provided individually for each ECU 3. CAN is an abbreviation for Controller Area Network and is a registered trademark. An ECU 3 has a function of centrally managing access rights to the subordinate ECUs 4 and authenticating users. The domains are, for example, a powertrain, a body, a chassis, and a cockpit.

[0029] The ECUs 4 connected to the ECU 3 belonging to the powertrain domain include, for example, an ECU 4 that controls an engine, an ECU 4 that controls a motor, and an ECU 4 that controls a battery.

[0030] The ECUs 4 connected to the ECU 3 belonging to the body domain include, for example, an ECU 4 that controls an air conditioner, an ECU 4 that controls doors, and the like.

[0031] The ECUs 4 connected to the ECU 3 belonging to the chassis domain include, for example, an ECU 4 that controls braking, and an ECU 4 that controls steering.

[0032] The ECUs 4 connected to the ECUs 3 belonging to the cockpit domain include, for example, an ECU 4 that controls the display of meters and navigation, and an ECU 4 that controls an input device operated by a vehicle occupant.

[0033] The external vehicle communication device 5 performs data communication with a communication device (eg, a cloud server) outside the vehicle via a wide area wireless communication network.

[0034] The in-vehicle communication network 6 includes CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD is an abbreviation for CAN with Flexible Data Rate. CAN FD connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5 via a bus. Ethernet individually connects the ECU 2 to each ECU 3 and the external-vehicle communication device 5. As shown in FIG. 2, the ECU 2 includes an Ethernet switch 7 that switches the Ethernet to be used.

[0035] The ECU2 is an electronic control device mainly composed of a microcomputer having a CPU2a, a ROM2b, a RAM2c, etc. Various functions of the microcomputer are realized by the CPU2a executing a program stored in a non-transient real recording medium. In this example, the ROM2b corresponds to the non-transient real recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU2a may be configured in hardware using one or more ICs, etc. Also, the number of microcomputers constituting the ECU2 may be one or more.

[0036] The ECU3, ECU4, and exterior communication device 5 are all electronic control devices mainly configured with a microcomputer including a CPU, ROM, RAM, etc., similar to the ECU2. The number of microcomputers constituting the ECU3, ECU4, and exterior communication device 5 may be one or more. The ECU3 is an ECU that controls one or more ECUs 4, and the ECU2 is an ECU that controls one or more ECUs 3 or controls all ECUs 3 and 4 of the entire vehicle including the exterior communication device 5.

[0037] In the following, the ECU 2, the ECU 3, the ECU 4, and the external vehicle communication device 5 will be referred to as the in-vehicle devices 2 to 5 unless otherwise specified.

[0038] The ECU 2 includes a real-time processing unit 10 and an application processing unit 20. When the ECU 2 includes a plurality of CPUs 2a, the real-time processing unit 10 and the application processing unit 20 may be realized by processes executed by the same CPU, or may be realized by processes executed by different CPUs.

[0039] The real-time processing unit 10 cooperates with the in-vehicle devices 3 to 5 connected via CAN FD to execute vehicle control and the like that requires real-time performance. The application processing unit 20 cooperates with the in-vehicle devices 3 to 5 connected via Ethernet to execute various applications (e.g., entertainment applications and the like) that require high processing capabilities.

[0040] The application processing unit 20 has a function of transmitting instructions based on the processing of various applications to the real-time processing unit 10. The real-time processing unit 10 has a function of transmitting information collected from an ECU or the like via CAN FD to the application processing unit 20. The real-time processing unit 10 and the application processing unit 20 cooperate with each other to realize various functions.

[0041] [2. Functional configuration] The software of the vehicle control system 1 is built in accordance with AUTOSAR. 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 functions related to cloud connection and security. SW-C is modularized software to realize a certain function. An application program includes one or more SW-C. Note that the software of the vehicle control system 1 does not necessarily have to be built in accordance with AUTOSAR.

[0042] Each of the devices belonging to the vehicle control system 1, that is, the ECU 2, the ECU 3, the ECU 4, and the external communication device 5, includes a platform. The platform provides an environment for executing SW-C described in a hardware-independent format.

[0043] The platform comprises a runtime environment (hereinafter referred to as RTE) and foundation software (hereinafter referred to as BSW). The RTE is an interface that connects SW-Cs with each other and between SW-C and BSW. The BSW is a layer that connects hardware and SW-C, and includes the OS, drivers, middleware, etc. The functions of the BSW are divided into small modules, and the functions of each module are provided to the SW-C via an API. API stands for Application Programming Interface.

[0044] In the following, the platform in which the real-time processing unit 10 is provided is referred to as a first platform (hereinafter, first PF) 11, and the platform in which the application processing unit 20 is provided is referred to as a second platform (hereinafter, second PF) 21.

[0045] 2, the real-time processing unit 10 includes a control system functional block group 12 as a collection of service applications (hereinafter, service apps) that run on the first PF 11. A service app is an application that receives a request from a client, processes it, and returns the result.

[0046] The control system functional block group 12 is a group of applications that have an API that receives commands related to the vehicle motion and that integrates the commands received by the API to realize consistent vehicle control. The control system functional block group 12 outputs various commands via the in-vehicle communication network 6 to the in-vehicle devices 3 to 5 that have entities that execute control based on the commands.

[0047] The first PF 11 includes a conversion gateway 111. The conversion gateway 111 has a function of converting a communication frame received by the real-time processing unit 10 via CAN FD into an Ethernet format and providing the frame to the application processing unit 20. The conversion gateway 111 also has a function of converting a communication frame in the Ethernet format provided from the application processing unit 20 into a CAN FD format.

[0048] The application processing unit 20 includes a hypervisor 22 and executes software on a plurality of virtual machines. Note that the hypervisor 22 may be omitted.

[0049] The application processing unit 20 includes a service function block group 23 as a collection of service applications that operate on the second PF 21.

[0050] The service function block group 23 is a collection of service applications. Each service application includes one or more SW-Cs. Service applications are provided not only by the vehicle manufacturer that manufactured the vehicle, but also by third parties. As a third party that provides a service application, for example, there is a data utilization company that provides a service by collecting data from the vehicle.

[0051] The second PF 21 includes a control system function block group 25, a data system function block group 26, and an API gateway 30.

[0052] The control system functional block group 25 is a set of programs equipped with an API for receiving requests related to vehicle control from the service system functional block group 23. The control system functional block group 25 converts an API access request from the service system functional block group 23, which is expressed in a vehicle-independent format, into an API access request expressed in a vehicle-dependent format and provides it to the real-time processing unit 10. The APIs equipped in the control system functional block group 25 include a motion system API that controls the motion of the vehicle and a non-motion system API other than the motion system API. The API access request received by the motion system API is transferred to the control system functional block group 12, and is transferred from the control system functional block group 12 via the in-vehicle communication network 6 to the in-vehicle devices 3 to 5 that execute control based on the request. The API access request received by the non-motion system API is transferred via the in-vehicle communication network 6 to the in-vehicle devices 3 to 5 that execute control based on the request.

[0053] The data-related functional block group 26 is a set of programs equipped with an API for handling vehicle data acquired and accumulated via the real-time processing unit 10. The data-related functional block group 26 has a function of abstracting the vehicle data, which is expressed in a vehicle-dependent format and is supplied from the real-time processing unit 10, into a vehicle-independent format and accumulating the abstracted vehicle data. The data-related functional block group 26 may have an API that provides a function of transmitting specified vehicle data to an ECU or the like via Ethernet. In particular, when the destination is the exterior communication device 5, the exterior communication device 5 may upload the transmitted vehicle data to the cloud.

[0054] Note that communication with the other in-vehicle devices 3 to 5 via the control system functional block group 25 is not limited to CAN FD, and may use Ethernet or other communication means. Also, communication with the other in-vehicle devices 3 to 5 via the data system functional block group 26 is not limited to Ethernet, and may use CAN FD or other communication means.

[0055] The API gateway 30 is configured using the functions of a virtual function bus (hereinafter, VFB). The VFB is middleware that enables communication between SW-Cs and between SW-Cs and BSWs without being aware of hardware or communication protocols, and is also called a software bus. Communication between SW-Cs refers to access from a SW-C to an API provided by another SW-C, and communication between a SW-C and BSW refers to access from a SW-C to an API provided by the control system function block group 25 and the data system function block group 26.

[0056] That is, the SW-C accesses various APIs via the API gateway 30 and realizes desired functions by using functions provided by the accessed APIs.

[0057] When using an API, the SW-C transmits an API access request, which includes at least the process ID of the SW-C that is the request source, and an API-ID that is information indicating the API that is the request destination.

[0058] [3. Access restriction mechanism] The following describes an access restriction mechanism that restricts access from SW-C to the API by the API gateway 30. The access restriction mechanism is set from the viewpoint of ensuring safety so that a service app with a low safety level among the service apps belonging to the service function block group 23 is executed, thereby preventing danger to vehicle occupants.

[0059] The API gateway 30 is not only provided in the second PF 21 that operates on the application processing unit 20, but is also provided in the platforms of all in-vehicle devices 2 to 5 that may be equipped with any of the service system function block group 23, the control system function block group 25, and the data system function block group 26.

[0060] As shown in FIG. 3, the API gateway 30 includes an information storage unit 31 and an access control unit 32.

[0061] The information storage unit 31 stores a correspondence table 311, API information 312, application information 313, and authorization policy 314. The correspondence table 311 is stored in the RAM 2c, and the API information 312, application information 313, and authorization policy 314 are stored in the ROM 2b. However, the API information 312, application information 313, and authorization policy 314 may be stored in the non-volatile RAM 2c.

[0062] The correspondence table 311 is information that associates a process ID dynamically assigned to a process, which is an execution unit of a program in an operating system (hereinafter, OS), with a unique application ID of the SW-C executed by that process. The correspondence table 311 is also information that associates a unique API-ID of each API with a process ID of a process that executes the SW-C that executes the API. The correspondence table 311 is generated by the OS when a process for each SW-C is generated at system startup. The correspondence table 311 is stored in the RAM 2c.

[0063] The API information 312 indicates information about the API identified by the API-ID. In particular, the API information 312 for an API that provides a function related to safety (hereinafter, safety-related API) includes a safety level (hereinafter, required level) required for SW-C that is the request source of the API access request. The safety-related API includes, for example, an API that provides a function to control an actuator related to the motion of the vehicle (e.g., longitudinal acceleration and steering), an API that provides a function to control the illumination of lights, etc.

[0064] The application information 313 indicates information about the SW-C identified by the application ID. In particular, the application information 313 about an SW-C that executes safety-related processing (hereinafter, safety-related SW-C) includes a safety level (hereinafter, provision level) that indicates the reliability of the safety of the processing executed by the SW-C. If the SW-C has an additional API, the application information 313 includes the required level of the additional API. The additional API is an API prepared so that the SW-C can provide its own functions to other SW-Cs.

[0065] The safety level is, for example, the Automotive Safety Level (hereinafter, referred to as ASIL). ASIL is a risk classification system defined in the ISO26262 standard for the functional safety of road-driving vehicles. ASIL is determined by three parameters, namely, probability of exposure, controllability, and severity, and is expressed in four levels, A to D. A corresponds to the lowest level, and D corresponds to the highest level. The required level of non-safety system API is expressed as QM. In other words, the safety level is practically expressed in five levels, QM, A to D, with QM being the lowest level. The safety level does not necessarily need to use ASIL, and may be any safety level defined to have multiple levels. Therefore, the safety level does not need to be four levels, AD, and may be three levels or less, or five levels or more.

[0066] As shown in FIG. 4, the authorization policy 314 expresses whether or not SW-C can access the API by using a matrix that represents all combinations of the provision level of SW-C and the required level of API. The provision level of SW-C represents the safety level of the caller. The required level of API represents the safety level of the callee. In the figure, a circle indicates that access is permitted, and a cross indicates that access is not permitted. Here, the access is permitted when the provision level is equal to or higher than the required level, and is not permitted when the provision level is lower than the required level. For example, an access request to an API whose required level is QM is permitted regardless of the provision level of the requester SW-C. Also, an access request to an API whose required level is C is permitted when the provision level of the requester SW-C is C or D, and is not permitted when the provision level of the requester SW-C is QM, A, or B.

[0067] 4 is a table showing a universal policy that is applied to all SW-Cs and all APIs. Alternatively, a table showing a policy adapted to an individual vehicle (hereinafter, a correspondence table) may be used, which is created by combining the information of the authorization policy 314 and the correspondence table 311.

[0068] 12, in the correspondence table, instead of the provision levels that SW-C can take, the provision levels of each SW-C that actually operates on the second PF 21 are listed. The provision level of each SW-C may be associated with a process ID corresponding to the SW-C. In addition, in the adaptive authorization policy, instead of the requirement levels that APIs can take, the requirement levels of each API actually provided on the second PF 21 are listed. The requirement levels of each API may be associated with a process ID corresponding to the API.

[0069] That is, in the correspondence table, the access permission from each SW-C to each API is expressed by a matrix showing all combinations of one or more SW-Cs, each having some provision level, and one or more APIs, each having some required level. The access permission is set according to the contents of the authorization policy 314 so that the access is permitted if the provision level is equal to or higher than the required level, and is not permitted if the provision level is lower than the required level.

[0070] The correspondence table has the result of access permission based on the permission policy 341 already incorporated in it, but the correspondence table may only show the correspondence between each SW-C and the provision level and the correspondence between each API and the required level. In this case, the correspondence table is referenced based on the requesting SW-C and the requested API extracted from the access request, and the provision level of the SW-C and the required level of the API are extracted. Then, based on the extracted provision level and required level, it is determined whether the requesting SW-C can access the requested API according to the authorization policy 341. In other words, each time an access request is generated, the permission policy 314 may be used to determine whether access can be granted.

[0071] In addition, the number of SW-Cs operating on the second PF 21 and the number of APIs provided in the second PF 21 may increase or decrease, and the definitions of the provision level and the requirement level may also change. Therefore, the authorization policy 314 and the correspondence table may be updated every time the software is updated.

[0072] An SW-C that has been assigned a service level is designed to meet the assigned service level. The service level of the SW-C and the required level of the API that the SW-C has may or may not be the same.

[0073] The access control unit 32 receives an API access request from an SW-C, the request including a process ID indicating the request source and an API-ID indicating the access destination. The access control unit 32 receives not only API access requests from SW-C belonging to the service function block group 23, but also API access requests from all SW-Cs operating on a platform equipped with the API gateway 30.

[0074] The process executed by the access control unit 32 will be described with reference to the flowchart of FIG.

[0075] In S110, the access control unit 32 determines whether or not an API access request has been received from SW-C, and if an API access request has been received, the process proceeds to S120, and if an API access request has not been received, the access control unit 32 waits by repeating the same step.

[0076] In S120, the access control unit 32 uses the authorization policy 314 based on the information indicated in the API access request to determine whether or not to permit access according to the API access request. Specifically, the access control unit 32 uses the correspondence table 311 to identify an application ID from the process ID indicated in the received API access request. The access control unit 32 identifies the provision level of the SW-C (hereinafter, requester SW-C) that is the source of the access request from the application information 313 associated with the identified application ID. The access control unit 32 identifies the requirement level of the API identified by the API-ID from the API information associated with the API-ID indicated in the received API access request. Then, the access control unit 32 uses the authorization policy 314 to determine whether or not to permit access from the requester SW-C to the access destination API based on the provision level identified from the process ID and the requirement level identified from the API-ID. Note that the authorization policy does not necessarily need to be defined for all APIs. When the API access request is directed to an API that is not defined in the authorization policy, S140 may be performed without performing S120 and S130.

[0077] In the next S130, the access control unit 32 determines whether or not the determination result in S120 is that access is permitted, and if access is permitted, the process proceeds to S140, and if access is not permitted, the process proceeds to S150.

[0078] In S140, the access control unit 32 transmits the API access request received in S110 to the API to be accessed, and ends the process. For example, the API access request is transmitted to the ECU 4 that performs engine control and brake control by CAN-FD or Ethernet communication via the control system functional block group 25.

[0079] In S150, the access control unit 32 discards the API access request accepted in S110 and ends the process. At this time, the request source SW-C may be notified that the access has been denied.

[0080] [4. Use Cases] [Case 1] As shown in FIG. 5, the case of implementing the functional block F1 and the functional block F2 will be described. The functional block F1 is a service-based functional block that realizes a collision safety function. The functional block F2 is a service-based functional block that realizes a function for reducing collision damage during low-speed driving. However, it is assumed that each of the functional block F1 and the functional block F2 is realized by one SW-C.

[0081] For example, when the functional block F1 detects an obstacle ahead while traveling at a speed of 80 km / h or less, it executes a process of decelerating. When the functional block F1 decelerates due to a malfunction while traveling at a speed of 80 km / h, it poses a life risk to the occupants, so the provided level is set to the highest level D.

[0082] For example, when the functional block F2 detects obstacles in front and behind while decelerating at 15 km / h or less, it decelerates. When the functional block F2 decelerates due to a malfunction while traveling at 15 km / h, it poses a minor to moderate obstacle to the occupants, so the provided level is set to B.

[0083] The control system functional block group 25 provides an API for controlling the accelerator and brakes in response to acceleration / deceleration requests from the functional blocks F1 and F2. The required level of the deceleration API (hereinafter referred to as the high-speed range API) used in the high vehicle speed range is set to D. The required level of the deceleration API (hereinafter referred to as the low-speed range API) used in the low vehicle speed range is set to B. The high vehicle speed range is set to, for example, 15 km / h < V ≤ 80 km, and the low vehicle speed range is set to, for example, V ≥ 15 km / h.

[0084] In this case, an image representing the result of determining whether access to each API (that is, the high-speed range API and the low-speed range API) provided by the control system functional block group 25 from each of the functional blocks F1 and F2 is permitted according to the authorization policy 314 is as shown in FIG. 6.

[0085] In other words, access from function block F1, whose provision level is D, to a high-speed area API, whose requirement level is D, is permitted. Access from function block F2, whose provision level is B, to a high-speed area API, whose requirement level is D, is denied. An access request from function block F2, whose provision level is B, to a low-speed area API, whose requirement level is B, is permitted.

[0086] For example, if a service system functional block for which a safety level is not set (i.e., the provision level is QM) is implemented, all access requests from this service system functional block to the API of the control system functional block group 25 for which a safety level is set (i.e., the required level is A to D) will be denied.

[0087] [4-2. Second case] A case will be described where function block F3 and function block F4 are implemented as shown in Fig. 7. Function block F3 is a service-related function block that realizes adaptive cruise control (hereinafter, ACC) using AI. Function block F4 is a service-related function block that realizes an acceleration / deceleration arbitration function and a collision safety function in an advanced driver assistance system (hereinafter, ADAS). However, function block F3 and function block F4 are each realized by one SW-C.

[0088] Function block F3 uses AI to determine the vehicle situation and executes processing to realize acceleration / deceleration control close to the sense of human operation. Function block F3 is designed so that the upper limit of the required acceleration / deceleration is less than the first threshold. In function block F3, insufficient deceleration or inoperation due to a malfunction can cause minor to moderate injury to the occupants, so the provision level is set to B.

[0089] The function block F4 arbitrates the acceleration / deceleration required by the ADAS functions, and requests the control system function block group 12 to accelerate or decelerate after arbitration. In addition, when there is a risk of a front-vehicle collision when the deceleration request from the ADAS functions is insufficient or there is no deceleration request, the function block F4 executes a process to reduce the impact of the collision. The function block F4 is designed so that the upper limit of the requested acceleration / deceleration is equal to or greater than the second threshold. The second threshold is set to a value greater than the first threshold. In the case of insufficient deceleration due to a malfunction or inoperation of the function block F4, the provision level is set to D because the lives of the occupants are endangered.

[0090] The function block F4 includes an arbitration API for receiving an acceleration / deceleration request from the function block F3. The request level of the arbitration API is set to B.

[0091] The control system functional block group 25 provides an acceleration / deceleration API for controlling the accelerator and the brake in response to an acceleration / deceleration request from the service system functional block group 23 .

[0092] Since the acceleration / deceleration API is used in all speed ranges from low to high vehicle speeds, the required level is set to D.

[0093] In this case, the function block F3 requests the API gateway 30 to access the arbitration API of the function block F4. The API gateway 30 determines whether or not to allow access in accordance with the authorization policy. In this case, since the provision level and the request level are both B, the API gateway 30 determines that access is allowed and transmits the API access request from the function block F3 to the arbitration API of the function block F4.

[0094] After arbitrating the acceleration / deceleration requests received by the arbitration API, the function block F4 requests the API gateway 30 to access the acceleration / deceleration API provided by the control system function block group 25. The API gateway 30 determines whether access is permitted in accordance with the authorization policy. In this case, since the provision level and the request level are both D, the API gateway 30 determines that access is permitted and transmits the API access request from the function block F4 to the acceleration / deceleration API of the control system function block group 25.

[0095] [5. Implementation form] This paper describes a software architecture that shows how to divide the functions of a service application, which is composed of multiple microservices, and assign them to multiple SW-Cs (i.e., service-related functional blocks).

[0096] The service app is realized by four microservices: "ACC," "Collision Safety," "Acceleration / Deceleration Mediation," and "Acceleration / Deceleration API."

[0097] "ACC" executes a process that uses AI to determine the vehicle situation and realizes auto cruise control with acceleration and deceleration close to the sense of human operation. The provision level is set to B. "Collision Safety" executes a process to decelerate if an obstacle that may cause a collision is detected. "Acceleration / Deceleration Arbitration" executes a process to arbitrate the acceleration / deceleration requests made by "ACC" and "Collision Safety". "Acceleration / Deceleration API" executes a process to generate an API access request to access the acceleration / deceleration API provided by the control system functional block group 12.

[0098] The provision level of "ACC" is B, and the provision levels of "collision safety" and "acceleration / deceleration arbitration" are D. "Acceleration / deceleration API" is not a safety-related process.

[0099] [5-1. Dividing functions by application] A case will be described where a service application is divided into processes and functions so that the ACC function and the collision safety function operate independently.

[0100] As shown in Figure 8, multiple pieces of software "ACC", "Acceleration / Deceleration Arbitration", and "Acceleration / Deceleration API" are realized in one SW-C called the ACC application (hereafter, ACC process). Multiple pieces of software "Collision Safety", "Acceleration / Deceleration Arbitration", and "Acceleration / Deceleration API" are realized in another SW-C called the Collision Safety application (hereafter, Collision Safety process). The process provision level of both the ACC process and the Collision Safety process is set to D so that it matches the highest provision level of the microservices contained in the process itself.

[0101] In this case, the ACC process and the collision safety process can both operate independently, as shown by the process flow indicated by the thin line with an arrow in Fig. 8. In addition, the ACC process and the collision safety process can each access the acceleration / deceleration API provided by the control system function block group 25 via the API gateway 30.

[0102] However, when the ACC process and the collision safety process are running at the same time, a function for coordinating between the "acceleration / deceleration arbitration" microservices present in both processes is required in addition to the API gateway 30 that coordinates between the processes. Also, the API access request to the control system function block group 25 based on the arbitration result must be configured to be made from one of the processes (e.g., the collision safety process). The process flow in this case is shown by the bold line with an arrow in Figure 8.

[0103] With this division method, it is difficult to guarantee the provision level of the ACC process as a whole when microservices with different provision levels are mixed. Also, with this division method, a separate mechanism is required to ensure coordination between "acceleration / deceleration arbitration", which makes the configuration complicated.

[0104] [5-2. Dividing functions by provision level] This section explains how to split a service application's functions (i.e., process) based on the level of microservice provision.

[0105] As shown in Figure 9, the software "ACC" with a provision level of B is realized in one SW-C (hereafter, ACC process), and the software "collision safety" and "acceleration / deceleration arbitration" with a provision level of D are realized in another SW-C (hereafter, collision safety process). The "acceleration / deceleration API" is included in the collision safety process because it is processed after "acceleration / deceleration arbitration". By dividing the functions and processes in this way, the provision level of the ACC process can be set to B, and the provision level of the collision safety process to D.

[0106] The collision safety process must have an API (i.e., arbitration API) to provide the "acceleration / deceleration arbitration" function to other processes. The required level of the arbitration API is set to B in accordance with the provision level of "ACC".

[0107] 9, an access request from the ACC process to an arbitration API provided by the collision safety process is executed via the API gateway 30. Also, an access request from the collision safety process to an acceleration / deceleration API provided by the control system functional block group 25 is executed via the API gateway 30.

[0108] In this division method, each process is divided by function so that microservices with the same provision level are included in the same process, and microservices with different provision levels are not mixed in one process. Therefore, it is easy to guarantee the provision level of each process. In addition, the collision safety process including "acceleration / deceleration arbitration" needs to have an arbitration API, which makes the configuration of the collision safety process complicated.

[0109] This division method corresponds to the use case shown in FIG.

[0110] [5-3. Divide functions into microservices] This section explains the case where a service application is divided into microservices.

[0111] As shown in Figure 10, one SW-C (hereafter, ACC process) is assigned to the software "ACC". Another SW-C (hereafter, collision safety process) is assigned to the software "crash safety". Another SW-C (hereafter, arbitration process) is assigned to the software "acceleration / deceleration arbitration". Another SW-C (hereafter, API process) is assigned to the software "acceleration / deceleration API".

[0112] By dividing the functions and processes in this way, the provision level of the ACC process can be set to B, and the provision levels of the collision safety process and the arbitration process can be set to D. The provision level of the API process is set to D in accordance with the required level of the acceleration / deceleration API provided by the control system function block group 25.

[0113] The arbitration process has an API (i.e., an arbitration API) for providing the ACC process and the collision safety process with the function of "acceleration / deceleration arbitration." The API process has an API (hereinafter, a request generation API) for providing the function of "acceleration / deceleration API" to the arbitration process. The request level of the arbitration API that accepts requests from the ACC process is set to B to match the provision level of the ACC process, and the request level of the arbitration API that accepts requests from the collision safety process is set to D. The request level of the request generation API is conveniently set to D to match the provision level of the arbitration process.

[0114] 10, an access request from the ACC process and the collision safety process to the arbitration process is made via the API gateway 30. Also, an access request from the arbitration process to the API process is made via the API gateway 30. Furthermore, an access request from the API process to the control system function block group 25 is made via the API gateway 30.

[0115] In this division method, each process is divided by function so that each microservice is included in a separate process, and microservices with different service levels are not mixed in one process, making it easier to guarantee the service level of each process. Also, although the structure of each process is simple, the amount of communication between processes via the API gateway 30 increases.

[0116] [6. Terminology] The API gateway 30 in the above embodiment corresponds to the access control device and the cooperation control unit in this disclosure. The in-vehicle communication network 6 corresponds to the in-vehicle network in this disclosure. The SW-C constituting the service system function block group 23, the control system function block group 25, and the data system function block group 26 correspond to the function blocks in this disclosure. The API corresponds to the function interface in this disclosure. The information storage unit 31 that stores the authorization policy 314 corresponds to the policy storage unit in this disclosure. The microservices correspond to the micro function blocks in this disclosure.

[0117] [7. Effects] According to the embodiment described above in detail, the following effects are achieved.

[0118] (1) The API gateway 30 permits access from SW-C, which is the source of an API access request, to the API, which is the destination, when the provision level, which is the safety level guaranteed by SW-C, meets the required level, which is the safety level required by the API. In other words, only API access requests from SW-C that meet the required level of the API are transmitted to the destination API. Therefore, it is possible to prevent unexpected operation control from being performed due to the API providing a safety-related function being freely used by a service-related function block or the like that does not have a safety level. In addition, since it is not necessary to include processing for dealing with requests from SW-C that do not meet the required level in the functions provided by the API, the processing can be simplified.

[0119] (2) When a service application that includes multiple microservices is realized using multiple SW-Cs, the level of service provided by the microservices is considered, and the functions are divided so that microservices with the same level of service are included in the same SW-C (i.e., process). Such a functional division can reduce the processing load and improve development efficiency at the same time.

[0120] 8. Other Embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0121] (a) In the present disclosure, access restrictions are imposed on safety-related APIs. However, if the SW-C that is the source of an API access request is fixed and there is no possibility that another SW-C will be the source of the request, the API may be excluded from the access restrictions in the API gateway 30 even if it is a safety-related API.

[0122] (b) In this disclosure, the authorization policy is expressed by a matrix showing all combinations of provision levels and requirement levels, but it may be expressed by a matrix showing combinations of application IDs and APIs, as in the authorization policy image shown in Fig. 6. In this case, it is possible to more easily determine whether access is permitted or not from the information shown in the API access request.

[0123] (c) In the present disclosure, the ECU 2 includes both the real-time processing unit 10 and the application processing unit 20, but may include only one of them.

[0124] (d) In the present disclosure, the ECU 2 includes the service system functional block group 23, the control system functional block group 25, and the data system functional block group 26, but the other in-vehicle devices 3 to 5 may include at least a part of the functional block groups 23 to 26. In addition, the functional block groups 23 to 26 may be centrally arranged in one of the in-vehicle devices 2 to 5, or may be distributed across the multiple in-vehicle devices 2 to 5.

[0125] (e) The in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program. Alternatively, the in-vehicle devices 2 to 5 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the ECU etc. and the method thereof described in the present disclosure may be realized by one or more dedicated computers configured by combining a processor and a memory programmed to execute one or more functions and a processor configured with one or more hardware logic circuits. In addition, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executed by the computer.

[0126] (f) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0127] (g) In addition to the vehicle control system and access control device described above, the present disclosure can also be realized in various forms, such as a program for causing a computer to function as the access control device, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, and an access control method.

[0128] [10. Technical Concepts Disclosed in This Specification] [Item 1] The vehicle includes a plurality of electronic control units mounted on the vehicle and connected to an in-vehicle network, The plurality of electronic control devices include A plurality of functional blocks, each configured to execute a predetermined process, at least a part of which is configured to provide a function for controlling the movement of the vehicle; A cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with At least some of the plurality of functional blocks include a functional interface that is an interface configured to provide its own function to other functional blocks; The cooperation control unit is A policy storage unit configured to store an authorization policy indicating a rule for authorizing access to an access request from any of the function blocks to any of the function interfaces; an access control unit configured to, when receiving the access request from any one of the plurality of functional blocks, determine, in accordance with the authorization policy, whether or not to authorize access from a request source block, which is the functional block that is the source of the access request, to a request destination interface, which is the functional interface that is the destination of the access request, and to transmit the access request to the request destination interface if the access is authorized; Equipped with The authorization policy is set using a provision level, which is a safety level indicating the safety of the function guaranteed by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Vehicle control system.

[0129] [Item 2] Item 1. A vehicle control system comprising: The authorization policy is set to authorize access when the provision level is equal to or higher than the request level, and to deny access when the provision level is lower than the request level. Vehicle control system.

[0130] [Item 3] The vehicle control system according to item 1 or 2, The safety level is the automobile safety level. Vehicle control system.

[0131] [Item 4] A vehicle control system according to any one of items 1 to 3, The function block comprises one or more micro function blocks; The provision level of the functional block is configured to realize the highest level of the safety levels required for each of the micro functional blocks. Vehicle control system.

[0132] [Item 5] A vehicle control system according to any one of items 1 to 4, a correspondence table indicating the provision level of the request source block and the request level of the request destination interface, The access control unit is configured to extract the provision level of the request source block and the requirement level of the request destination interface by referring to the correspondence table according to the request source block and the request destination interface extracted from the access request, and to determine whether to authorize access from the request source block to the request destination interface based on the extracted provision level and requirement level by using the authorization policy. Vehicle control system.

[0133] [Item 6] A vehicle control system according to any one of items 1 to 4, a correspondence table indicating the provision level of the request source block and the request level of the request destination interface, and indicating whether access is permitted or not in accordance with the authorization policy for all combination patterns of the request source block and the request destination interface; The access control unit is configured to determine whether or not to authorize access from the request source block to the request destination interface by referring to the correspondence table according to the request source block and the request destination interface extracted from the access request. Vehicle control system.

[0134] [Item 7] The vehicle control system according to item 5 or 6, The functional blocks and the functional interfaces are identified by process IDs that are assigned by an operating system when the vehicle control system is started; The correspondence table is generated by the operating system after the process ID is assigned, and is configured such that the request source block and the request destination interface are identified by the process ID. Vehicle control system.

[0135] [Item 8] A plurality of functional blocks configured to execute a predetermined process; A cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with At least some of the plurality of functional blocks include a functional interface that is an interface configured to provide its own function to other functional blocks; The cooperation control unit is A policy storage unit configured to store an authorization policy indicating a rule for authorizing access to an access request from any of the function blocks to any of the function interfaces; an access control unit configured to, when receiving the access request from any one of the plurality of functional blocks, determine, in accordance with the authorization policy, whether or not to authorize access from a request source block, which is the functional block that is the source of the access request, to a request destination interface, which is the functional interface that is the destination of the access request, and to transmit the access request to the request destination interface if the access is authorized; Equipped with The authorization policy is set using a provision level, which is a safety level indicating the safety of the function provided by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Access control device.

[0136] [Item 9] determining whether or not to authorize access from a request source block, which is the functional block that is the source of the access request, to a request destination interface, which is the functional interface that is the destination of the access request, in accordance with an authorization policy in which a rule for authorizing access is indicated, for an access request from any one of a plurality of functional blocks that are configured to execute a predetermined process, to a functional interface that is an interface provided in at least a portion of the plurality of functional blocks and that provides the other functional blocks with their own functions; If the access is granted, communicating the access request to the requested interface; The authorization policy is set using a provision level, which is a safety level indicating the safety of the function provided by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Access control methods.

Claims

1. The vehicle is equipped with a plurality of electronic control devices (2 to 5) mounted on a vehicle and connected to an in-vehicle network, The plurality of electronic control devices include A plurality of functional blocks (23 to 26), each configured to execute a predetermined process, at least a part of which is configured to provide a function for controlling the movement of the vehicle; A cooperation control unit (30) configured to realize cooperation between the plurality of functional blocks; Equipped with At least some of the plurality of functional blocks include a functional interface that is an interface configured to provide its own function to other functional blocks; The cooperation control unit is a policy storage unit (31) configured to store an authorization policy indicating a rule for authorizing access for an access request from any of the function blocks to any of the function interfaces; an access control unit (32) configured to, when receiving the access request from any one of the plurality of functional blocks, determine, in accordance with the authorization policy, whether or not to authorize access from the request source block, which is the functional block that is the source of the access request, to the request destination interface, which is the functional interface that is the destination of the access request, and, if the access is authorized, transmit the access request to the request destination interface; Equipped with The authorization policy is set using a provision level, which is a safety level indicating the safety of the function guaranteed by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Vehicle control system.

2. 2. The vehicle control system according to claim 1, The authorization policy is set to authorize access when the provision level is equal to or higher than the request level, and to deny access when the provision level is lower than the request level. Vehicle control system.

3. 3. A vehicle control system according to claim 1, further comprising: The safety level is the automobile safety level. Vehicle control system.

4. 3. A vehicle control system according to claim 1, further comprising: The function block comprises one or more micro function blocks; The provision level of the functional block is configured to realize the highest level of the safety levels required for each of the micro functional blocks. Vehicle control system.

5. 2. The vehicle control system according to claim 1, a correspondence table indicating the provision level of the request source block and the request level of the request destination interface, The access control unit is configured to extract the provision level of the request source block and the requirement level of the request destination interface by referring to the correspondence table according to the request source block and the request destination interface extracted from the access request, and to determine whether to authorize access from the request source block to the request destination interface based on the extracted provision level and requirement level by using the authorization policy. Vehicle control system.

6. 2. The vehicle control system according to claim 1, a correspondence table indicating the provision level of the request source block and the request level of the request destination interface, and indicating whether access is permitted or not in accordance with the authorization policy for all combination patterns of the request source block and the request destination interface; The access control unit is configured to determine whether or not to authorize access from the request source block to the request destination interface by referring to the correspondence table according to the request source block and the request destination interface extracted from the access request. Vehicle control system.

7. 7. A vehicle control system according to claim 5, further comprising: the functional blocks and the functional interfaces are identified by process IDs that are assigned by an operating system when the vehicle control system is started; The correspondence table is generated by the operating system after the process ID is assigned, and is configured such that the request source block and the request destination interface are identified by the process ID. Vehicle control system.

8. A plurality of functional blocks (23-26) configured to execute a predetermined process; A cooperation control unit (30) configured to realize cooperation between the plurality of functional blocks; Equipped with At least some of the plurality of functional blocks include a functional interface that is an interface configured to provide its own function to other functional blocks; The cooperation control unit is a policy storage unit (31) configured to store an authorization policy indicating a rule for authorizing access for an access request from any of the function blocks to any of the function interfaces; an access control unit (32) configured to, when receiving the access request from any one of the plurality of functional blocks, determine, in accordance with the authorization policy, whether or not to authorize access from the request source block, which is the functional block that is the source of the access request, to the request destination interface, which is the functional interface that is the destination of the access request, and, if the access is authorized, transmit the access request to the request destination interface; Equipped with The authorization policy is set using a provision level, which is a safety level indicating the safety of the function provided by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Access control device.

9. In a vehicle control system having a plurality of electronic control devices (2-5) mounted on a vehicle and connected to an in-vehicle network, an access control method is executed by a cooperation control unit (30) configured to realize cooperation between a plurality of function blocks (23-26) provided in the plurality of electronic control devices, each of which performs a predetermined process and at least a portion of which is configured to provide a function of controlling the movement of the vehicle, the method comprising: an interface provided in at least a portion of the plurality of functional blocks and used to provide a function of the functional block to the other functional blocks is defined as a functional interface; Regarding an access request from any one of the plurality of functional blocks to the functional interface, the functional block that is a request source of the access request is defined as a request source block, and the functional interface that is a request destination of the access request is defined as a request destination interface, the cooperation control unit determines whether to authorize access from the request source block to the request destination interface in accordance with an authorization policy in which a rule for authorizing access is indicated; If the access is authorized, the cooperation control unit transmits the access request to the requested interface; The authorization policy is set using a provision level, which is a safety level indicating the safety of the function provided by the request source block, and a request level, which is the safety level that the request destination interface requests from the request source block. Access control methods.

Images