Mobility service provisioning system, in-vehicle system, management server, access control procedure and access control program

Abstract

An authorization policy delivery unit provides the vehicle's in-vehicle system with a static standpoint policy, generated by integrating a multitude of standpoint-specific policies, as an authorization policy. When the access control unit receives an access request, it uses the authorization policy provided by the authorization policy delivery unit and stored in the policy store to determine whether a usage source block has access privileges on the usage target block. If it determines that access privileges exist, the access control unit forwards the access request to the usage target block.

Description

Cross-reference to related applications

[0001] This international application claims priority based on Japanese Patent Application No. 2022-074970, filed on April 28, 2022, the entire contents of which are incorporated herein by reference. Technical area

[0002] The present disclosure relates to a technology for controlling access. State of the art

[0003] The following Patent Literature 1 describes a technology in an open platform for mobile terminals that uses an access authorization policy to restrict access when access to resources or information held by the system is detected via a service application. The access authorization policy specifies who is permitted or prohibited to do what. State-of-the-art literaturePatent literature

[0004] Patent Literature 1: JP 6124627 B Summary of the invention

[0005] It is expected that 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") in the future. When third-party service applications or the like access the vehicle's functions and information, access must be restricted as necessary. In addition, as in-vehicle systems become more sophisticated and a wider variety of service applications are installed, access control will become more complex. It is necessary to control access while ensuring real-time performance and utilizing the limited resources of the in-vehicle system.

[0006] One aspect of the present disclosure provides a technology for simplifying access control using an access authorization policy.

[0007] A mobility service provision system according to one aspect of the present disclosure includes an in-vehicle system and an authorization policy provision unit. The in-vehicle system includes a plurality of electronic control units mounted on a vehicle and connected to an in-vehicle network. The authorization policy provision unit is located outside the vehicle.

[0008] The in-vehicle system includes a plurality of functional blocks and a coordination controller. Each of the plurality of functional blocks is mounted on one of the plurality of electronic control units and is configured to execute a predetermined process. The coordination controller is configured to implement coordination between the plurality of functional blocks.

[0009] The coordination control unit includes a policy storage and an access control unit. The policy storage acquires and stores an authorization policy defining an access privilege between the plurality of functional blocks from the authorization policy provision unit. The access control unit receives an access request from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks. Upon receiving the access request, the access control unit uses the authorization policy stored in the policy storage to determine whether the usage source block has an access privilege to the usage target block. If it is determined that the access privilege exists, the access control unit transmits the access request to the usage target block.

[0010] The authorization policy provision unit provides a static viewpoint policy, generated by integrating a plurality of viewpoint-specific policies, to the in-vehicle system as an authorization policy. In the multiple viewpoint-specific policies, the access privilege is defined for each of multiple viewpoints, focusing on a static attribute of the functional blocks.

[0011] According to this configuration, the in-vehicle system determines the presence or absence of the access privilege from the usage source block to the usage target block using an authorization policy including a static viewpoint policy integrating a plurality of viewpoint-specific policies. Accordingly, the in-vehicle system can easily determine the presence or absence of the access privilege at one time without making a determination for each of a plurality of viewpoint-specific policies individually. Furthermore, the authorization policy is acquired from outside the vehicle. As a result, it is possible to reduce the burden required to determine the access privilege in the in-vehicle system.

[0012] An in-vehicle system according to one aspect of the present disclosure includes a plurality of functional blocks and a coordination controller. Each of the plurality of functional blocks is mounted on one of the plurality of electronic control units connected to an in-vehicle network and is configured to execute a predetermined process. The coordination controller implements coordination between the plurality of functional blocks.

[0013] The coordination controller includes a policy store and an access controller. The policy store stores an authorization policy that specifies access privileges between the functional blocks. The access controller receives an access request from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks. Upon receiving the access request, the access controller uses the authorization policy stored in the policy store to determine whether the usage source block has an access privilege to the usage target block. If it determines that the access privilege exists, the access controller transmits the access request to the usage target block.

[0014] The authorization policy includes a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints focusing on a static attribute of the plurality of functional blocks.

[0015] A management server communicatively connected to a vehicle having an in-vehicle system including a plurality of electronic control units connected to an in-vehicle network. The management server includes an authorization policy storage unit, an authorization policy generation unit, and an authorization policy provision unit.

[0016] The authorization policy memory is mounted in any one of a plurality of electronic control units and stores an authorization policy referenced to control an access privilege to a usage target block from a usage source block. The usage source block is one of the functional blocks, each configured to execute a predetermined process. The usage target block is another of the functional blocks.

[0017] The authorization policy generation unit generates a static viewpoint policy by integrating a plurality of static viewpoint-specific policies based on the plurality of static viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks. Furthermore, the authorization policy generation unit stores the generated static viewpoint policy in the authorization policy storage as the authorization policy.

[0018] The authorization policy provision unit provides the authorization policy stored in the authorization policy storage to the vehicle.

[0019] According to one aspect of the present disclosure, in an access control method, at least one of a plurality of electronic control units connected to an in-vehicle network controls access between a plurality of functional blocks using an authorization policy that defines an access privilege between the functional blocks. Each of the plurality of functional blocks is mounted on one of the plurality of electronic control units and executes a predetermined process.

[0020] The access control method includes: using, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks; when an access request is received from a usage source block that is one of the plurality of functional blocks to a usage target block that is another of the plurality of functional blocks, determining whether the access privilege of the usage source block to the usage target block exists according to the authorization policy; and transmitting the access request to the usage target block when it is determined that the access privilege exists.

[0021] According to one aspect of the present disclosure, a program controls access between a plurality of functional blocks by using an authorization policy that defines an access privilege between the plurality of functional blocks, each of which is mounted on one of a plurality of electronic control units and configured to execute a predetermined process, wherein the at least one of a plurality of electronic control units is connected to an in-vehicle network.

[0022] The access control program is configured to: use, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks; and cause a computer to implement a function of: when an access request is received from a usage source block that is one of the plurality of functional blocks to a usage target block that is another of the plurality of functional blocks, determining whether the usage source block has the access privilege to the usage target block according to the authorization policy;and transmitting the access request to the usage target block if it is determined that the access privilege exists.; Short description of the characters Fig. 1 is a block diagram showing a configuration of a mobility service provision system. Fig. 2 is a block diagram showing a configuration of an ECU. Fig. Figure 3 is a block diagram showing an API gateway configuration. Fig. Figure 4 is an explanatory diagram showing contents of user information. Fig. Figure 5 is an explanatory diagram showing a concept of an authorization policy. Fig. Figure 6 is an explanatory diagram of API access privileges related to security levels. Fig. Figure 7 is an explanatory diagram showing a static viewpoint-specific policy with security as a viewpoint. Fig. Figure 8 is an explanatory diagram illustrating a static viewpoint-specific policy with a company property as a viewpoint. Fig. 9 is an explanatory diagram illustrating a dynamic viewpoint-specific policy with a personal property as a viewpoint, a dynamic viewpoint policy with a privacy as a viewpoint, and a dynamic policy integrating the dynamic viewpoint-specific policies. Fig. Figure 10 is an explanatory diagram illustrating a static policy integrating static viewpoint-specific policies. Fig. 11 is a flowchart of an access restriction process executed by an access control device. Fig. Figure 12 is a block diagram showing a configuration of a cloud server. Fig. 13 is a flowchart of a policy generation deployment process performed by the cloud server. Description of the embodimentsEmbodiments for carrying out the invention

[0023] Hereinafter, an embodiment of the present disclosure will be described with reference to drawings. 1. Configuration

[0024] A mobility service provision system 1 of the present embodiment includes an in-vehicle system 100 mounted in a vehicle and a cloud server 200. The vehicle may have an automated driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an internal combustion engine and an electric motor as a propulsion source. The vehicle is not limited to the vehicle with the automated driving function or the hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an internal combustion engine or only an electric motor as the propulsion source. Hereinafter, the vehicle equipped with the in-vehicle system 100 is simply referred to as a vehicle.

[0025] As it is in Fig. 1, the in-vehicle system 100 includes an ECU 2, a plurality of ECUs 3, a plurality of ECUs 4, a vehicle exterior communication device 5, and a vehicle interior communication network 6. ECU is an abbreviation for Electronic Control Unit.

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

[0027] The ECU 3 is provided for each domain divided by function in the vehicle and primarily controls a plurality of ECUs 4 present within that domain. Each ECU 3 is connected to the ECU 4 according to its control via an individually provided lower-layer network (for example, CAN). CAN is a registered trademark and is an abbreviation for Controller Area Network. The ECU 3 has a function of centrally managing an access privilege of the ECU 4 according to its control and authenticating users. The domain includes, for example, a powertrain, a body, a chassis, a cockpit, and the like.

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

[0029] The ECUs 4 connected to the ECU 3 belonging to the body domain or bodywork domain include, for example, an ECU 4 that controls the air conditioning system and an ECU 4 that controls the doors.

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

[0031] The ECUs 4 connected to the ECU 3 belonging to the cockpit domain include, for example, an ECU 4 that controls the display of display elements and navigation, and an ECU 4 that controls input devices operated by vehicle occupants.

[0032] The vehicle exterior communication device 5 performs data communication with vehicle exterior devices, such as the cloud server 200, via a wide-area wireless communication network.

[0033] The vehicle interior 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 vehicle exterior communication device 5 via a bus. Ethernet connects the ECU 2 and each ECU 3 and the vehicle exterior communication device 5 individually. The ECU 2 is provided with an Ethernet switch 7 for switching the Ethernet to be used, as shown in Fig. 2 can be seen.

[0034] The ECU 2 is an electronic control unit primarily including a microcomputer including a CPU 2a, a ROM 2b, a RAM 2c, and the like. Various functions of the microcomputer are implemented by the CPU 2a executing programs stored in a non-volatile tangible storage medium. In this example, the ROM 2b corresponds to a non-volatile tangible storage medium that stores a program. Further, by executing this program, a process corresponding to the program is executed. Note that some or all of the functions performed by the CPU 2a may be implemented by a hardware circuit such as one or more ICs. Furthermore, the number of microcomputers constituting the ECU 2 may be one or more.

[0035] The ECU 3, the ECU 4, and the vehicle-outside communication device 5 are all electronic control units primarily including a microcomputer provided with a CPU, a ROM, a RAM, and the like, similarly to the ECU 2. Further, the number of microcomputers constituting the ECU 3, the ECU 4, and the vehicle-outside communication device 5 may be one or more.

[0036] Hereinafter, unless otherwise specified, the ECU 2, the ECU 3, the ECU 4 and the vehicle exterior communication device 5 are collectively referred to as in-vehicle devices 2 to 5.

[0037] The ECU 2 has 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 implemented by processes executed by the same CPU or by processes executed by different CPUs.

[0038] The real-time processing unit 10 cooperates with the in-vehicle devices 3 to 5 connected via the CAN FD to execute vehicle control and the like requiring 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) requiring high processing performance.

[0039] The application processing unit 20 has a function of transmitting instructions based on the processes of various applications to the real-time processing unit 10. The real-time processing unit 10 has a function of transmitting information and the like collected from the in-vehicle devices 3 to 5 to the application processing unit 20 via the CAN FD. The real-time processing unit 10 and the application processing unit 20 cooperate with each other to implement various functions.

[0040] As it is in Fig. As can be seen in Figure 12, the cloud server 200 includes a control device 201, a memory 202 and a communication unit 203.

[0041] The controller 201 is an electronic control unit primarily including a microcomputer including a CPU 201a, a ROM 201b, a RAM 201c, and the like. Various functions of the microcomputer are implemented by the CPU 201a executing programs stored in a non-volatile tangible storage medium. In this example, the ROM 201b corresponds to a non-volatile tangible storage medium that stores a program. Further, by executing this program, a process corresponding to the program is executed. The controller 201 executes at least one policy generation and deployment process.

[0042] The memory 202 stores a plurality of authorization policies. The authorization policies stored in the memory 202 include a static viewpoint policy and a dynamic viewpoint policy, which are generated by the policy generation / provisioning process executed by the controller 201. The authorization policy may also include a plurality of viewpoint-specific policies used when generating the static viewpoint policy and the dynamic viewpoint policy.

[0043] The communication unit 203 performs data communication with the in-vehicle system 100 installed in each of the plurality of vehicles via a wide-area wireless communication network. 2. Functional configuration

[0044] The software installed in the in-vehicle devices 2 to 5 belonging to the in-vehicle system 100 is constructed in accordance with AUTOSAR. AUTOSAR is an abbreviation for Automotive Open System Architecture. AUTOSAR provides not only communication between software components (hereinafter referred to as SW-C) deployed to implement various applications, but also functions related to cloud connectivity, security, and the like. SW-C is software divided to implement a specific function. The application program includes one or more SW-Cs. Note that the software of the mobility service provision system 1 does not necessarily have to be constructed in accordance with AUTOSAR.

[0045] Each of the in-vehicle devices 2 through 5 contains a platform. The platform provides an environment for executing SW-C written in a hardware-independent format.

[0046] The platform contains a runtime environment (RTE) and underlying software (BSW). The RTE is the interface between the software and the BSW, and between the software and the BSW. The BSW is the hierarchy that connects the hardware and the software, including the OS (operating system), drivers, middleware, etc. The BSW functions are divided into small modules, and the functions of each module are exposed to the software via an API. API is an abbreviation for Application Programming Interface.

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

[0048] As it is in Fig. As can be seen in Figure 2, the real-time processing unit 10 includes a control system functional block group 12 as a collection of service applications (hereinafter referred to as service applications) running on the first PF 11. The service application is an application that receives requests from clients, processes them, and returns results. Each service application includes one or more SW-Cs.

[0049] The control system functional block group 12 is an application for providing an API for accepting instructions related to the movement of the vehicle and for controlling the instructions accepted by the API to implement consistent vehicle control. The control system functional block group 12 outputs various instructions via the CAN FD to the in-vehicle devices 3 to 5, in which there is an embodiment that executes control based on the directive or operation instruction.

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

[0051] 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.

[0052] The application processing unit 20 contains service system function block groups 23, 24 as a collection of service applications running on the second PF 21.

[0053] Service system function block group 23 is a collection of service applications (hereinafter referred to as OEM applications) provided by an OEM. Each OEM application has one or more SW-Cs. The OEM is the vehicle manufacturer that produced the vehicle. OEM is an abbreviation for original equipment manufacturer. Furthermore, the OEM applications can include applications developed by the OEM itself and applications developed by other vendors.

[0054] Service system functional block group 24 is a collection of service applications provided by third-party providers (hereinafter referred to as third-party applications). Each third-party application has one or more SW-Cs. The third-party provider can be any provider other than a vehicle owner and an OEM. For example, the third-party provider includes data usage companies that provide services by collecting data from vehicles.

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

[0056] The control system functional block group 25 is a set of service applications equipped with an API for accepting requests related to vehicle control from the service system functional block groups 23, 24. The control system functional block group 25 converts the API access request expressed in a vehicle-independent format from the service system functional block groups 23, 24 into an API access request expressed in a vehicle-dependent format and provides it to the real-time processing unit 10. The API provided by the control system functional block group 25 includes a motion system API for controlling the movement of the vehicle and a non-motion system API other than the motion system API.The API access request accepted from the motion system API is transmitted to the control system functional block group 12, and is transmitted from the control system functional block group 12 to the in-vehicle devices 3 to 5 and the like, which execute control based on the request, via the in-vehicle communication network 6, such as the CAN FD. The API access request accepted from the non-motion system API is transmitted to the in-vehicle devices 3 to 5 and the like, which execute control based on the request, via the in-vehicle communication network 6, such as the CAN FD.

[0057] The data system functional block group 26 is a set of service applications equipped with an API for handling vehicle data acquired and stored via the real-time processing unit 10. The data system functional block group 26 has a function of abstracting and storing vehicle data expressed in a vehicle-dependent format, which is provided by the real-time processing unit 10, into a vehicle-independent format. The data system functional block group 26 may have an API that provides a function of transmitting designated vehicle data to the in-vehicle device or the like via the in-vehicle communication network 6, such as the Ethernet. Specifically, when the transmission destination is the vehicle-exterior communication device 5, the vehicle-exterior communication device 5 may upload the transmitted vehicle data to the cloud.In addition, the data system functional block group 26 may have an API that provides a function for obtaining data from the cloud server 200.

[0058] It should be noted that communication with other in-vehicle devices 3 to 5 via the control system function block group 25 is not limited to CAN FD, but Ethernet or other communication means may be used. In addition, communication with other in-vehicle devices 3 to 5 via the data system function block group 26 may be performed not only via Ethernet, but also via CAN FD or other communication means.

[0059] Hereinafter, the APIs provided by the service applications belonging to the control system function block group 25 and the data system function block group 26 are referred to as vehicle APIs.

[0060] The API gateway 30 is configured using the functions of the virtual function bus (hereinafter referred to as VFB). VFB is middleware that enables communication between SW-Cs and between SW-C and BSW without knowledge of hardware or a communication protocol, and is also referred to as a software bus. Communication between SW-Cs is performed between service applications belonging to the service system function block groups 23 and 24 and refers to access from one SW-C to an API provided by another SW-C. Communication between SW-C and BSW refers to access from SW-C to the vehicle API between service applications belonging to the service system function block groups 23, 24 and service applications belonging to the control system function block group 25 and the data system function block group 26.In the following description, it is assumed that the SW-C and the service application correspond one-to-one or match one-to-one.

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

[0062] An access restriction mechanism is described. In the access restriction mechanism, the API gateway 30 restricts access to the vehicle API from the service application. The access restriction mechanism is defined in the form of SFOP, which is an attribute defined as a security protection asset. S is an abbreviation for security and denotes access restrictions to API access that compromise security. F is an abbreviation for financial and denotes access restrictions to API access that compromise company assets or personal assets. O is an abbreviation for operational and denotes access restrictions to API access that compromise the operational performance of the vehicle. P is an abbreviation for privacy and denotes access restrictions to API access that compromise privacy information.

[0063] The API gateway 30 is not only provided in the second PF 21 running on the application processing unit 20. The API gateway 30 is provided in the platforms of all in-vehicle devices 2 to 5, which may include any of the service system function block groups 23, 24, control system function block group 25, and data system function block group 26.

[0064] As it is in Fig. As can be seen in Figure 3, the API gateway 30 includes an information store 31, an access control device 32, and a status monitoring unit 33.

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

[0066] The API authorization policy 311 is a collection of information for determining whether the service application has access privileges to the vehicle API. The API authorization policy 311 is downloaded from the cloud server 200, for example, using a function of a service application belonging to the data system functional block group 26, and stored in the information store 31.

[0067] The correspondence table 312 contains information correlating the process ID dynamically assigned to the process that is the execution unit of the program in the operating system (hereinafter referred to as the OS) with the unique application ID possessed by the service application executing in the process. In addition, the correspondence table 312 also contains information linking a unique API ID of each vehicle API with the process ID of a process assigned to a service application, which is an entity that executes the function of the API. The correspondence table 312 is generated by the OS when a process is created for each service application when the system starts.

[0068] The user information 313 is information that is referred to when determining, for example, whether the access privilege is granted using the API authorization policy 311, and is information that is arbitrarily set by the vehicle user. For example, as shown in Fig. As shown in Figure 4, the user information 313 includes content that determines, for each vehicle user identified by a user ID, whether a request for access from a service application to privacy information identified by a privacy information ID should be permitted. The user information 313 may include contact information for the vehicle user.

[0069] When the access control device 32 receives an API access request, the access control device 32 identifies the application ID of the usage source application by using the correspondence table 312 from the process ID specified in the API access request. The access control device 32 executes an access restriction process to determine whether or not an access privilege exists in accordance with the API authorization policy 311 based on the identified application ID and the API ID of the usage target API specified in the API access request. The access restriction process will be described in detail later.

[0070] The status monitoring unit 33 monitors the access status of each service application to each vehicle API and generates status information indicating the access status. The status information is generated, for example, by counting the number of accesses to each vehicle API, the amount of data handled in processing, and the like for each use source application. 4. API Authorization Policy

[0071] A generation method of the API authorization policy 311 distributed by the cloud server 200 will be described.

[0072] As it is in Fig. As can be seen in Figure 5, the cloud server 200 prepares multiple viewpoint-specific policies generated from different viewpoints for each attribute of the SFOP. The viewpoint-specific policies may be generated by the cloud server 200, or those generated outside the cloud server 200 may be collected. The viewpoint-specific policy does not necessarily have to be prepared for all attributes of the SFOP. Furthermore, multiple viewpoint-specific policies may be prepared for one attribute.

[0073] The viewpoint-specific policies include the static viewpoint-specific policy, which is generated from a viewpoint that focuses on static attributes of the service application, and the dynamic viewpoint-specific policy, which is generated from a viewpoint that focuses on dynamic attributes of the service application. The static attributes of the service application are information about characteristics that do not change depending on the usage environment or conditions of the service application and include, for example, information that characterizes the security of the processing performed by the service application and information that characterizes the provider of the service application.The dynamic attributes of a service application are information about characteristics that change depending on the usage environment and usage conditions of the service application, and include, for example, restrictions imposed by the service application provider's billing contract and information arbitrarily set by the vehicle user. 4-1. Security-related authorization policy

[0074] A “security-related authorization policy” is described as an example of a static viewpoint-specific policy that is classified as an S-attribute.

[0075] As a premise, service applications (hereinafter referred to as safety system applications) that perform processes related to vehicle safety are assigned a security level (hereinafter referred to as assurance level) that indicates the reliability of the security of the processes performed by the safety system applications. In addition, an API (hereinafter referred to as safety system API) provided in the safety system application is assigned a security level (hereinafter referred to as request level) required by a source service application that uses the API and requests access to the safety system API.

[0076] For example, the safety level should be the Automotive Safety Integrity Level (hereinafter referred to as ASIL). The ASIL is a risk classification system defined by the ISO 26262 standard for the functional safety of vehicles on the road. The ASIL is determined by three parameters: probability of exposure, controllability, and weighting, and is expressed on a scale from A to D. A is the lowest level and D is the highest level. The non-safety system API is not assigned a requirement level, and the fact that no requirement level is assigned is represented by QM. In other words, the safety level is essentially expressed on a scale from QM, A to D, with QM being the lowest level. The safety level does not necessarily have to use the ASIL, but should be a safety level defined to have multiple levels.Therefore, the security level does not have to have four levels from A to D, but can have three levels or less or five levels or more.

[0077] Fig. Figure 6 shows a list expressing the presence or absence of an access privilege from a service application to an API using a matrix that shows all combinations of the service application's security level and the API's request level. In the table, a circle indicates that the user has an access privilege, and a cross indicates that the user does not have the access privilege. Here, the access privilege is present when the provision level is equal to or higher than the request level, and the access privilege is not present when the provision level is lower than the request level. As shown in the left part in Fig. For example, as shown in Figure 6, a service application with an assurance level of A has access privilege to an API with a requirement level of A, but has no access privilege to an API with a requirement level of D. A service application with an assurance level of D has access privilege to all APIs with a requirement level of D or higher.

[0078] As it is in Fig. As can be seen in Figure 7, the “security-related authorization policy” is created by combining the application information, the API information and the list of access privileges defined in Fig. 6 can be seen.

[0079] The application information is information that maps an application ID to a security level assigned to a service application identified by the application ID. The API information is information that maps an API ID to a request level assigned to the vehicle API identified by the API ID.

[0080] The contents of the “security-related authorization policy” are represented by a list that defines whether the usage source application, identified by an application ID, has the access privilege to the usage target API, identified by an API ID. 4-2. Authorization Policy Related to Company Property

[0081] A “proprietary authorization policy” is described as an example of the static viewpoint-specific policy, which is classified as an F-attribute.

[0082] As a premise, a group attribute is assigned to a service application according to its provider. The group attributes are: GA for an OEM application developed in-house; GB for an OEM application developed by another provider; and GC for a third-party application developed by a third-party provider.

[0083] The “company property-related authorization policy” is generated by combining the group attribute-specific access privilege information and the application information as described in Fig. 8 can be seen.

[0084] The application information is information that maps the application ID of a service application to a group attribute assigned to the service application identified by the application ID.

[0085] The group attribute-specific access privilege information is information that indicates whether a service application with a specific group attribute has access privileges to a vehicle API identified by an API ID, using a matrix that represents all combinations of the vehicle API's API ID and the group attributes. For example, the reliability of service applications with respect to group attributes is GA > GB > GC, and the access privilege to each vehicle API is also determined based on this reliability.

[0086] The contents of the "proprietary authorization policy" such as the "security authorization policy" are represented by a list that defines whether the usage source application identified by an application ID has the access privilege to the usage target API identified by the API ID. 4-3. Personal Property Authorization Policy

[0087] A “personal property authorization policy” is described as an example of a dynamic viewpoint-specific policy classified into the F attribute.

[0088] The “personal property authorization policy” is used to determine whether to grant the access privilege depending on the access status to each vehicle API in accordance with the API billing agreement with the service application provider.

[0089] As shown in the upper left part of Fig. As shown in Figure 9, the “personal property-related authorization policy” is information that associates an API ID with confirmation necessity information, privilege type information, and settlement contract content information set for the vehicle API identified from the API ID.

[0090] The confirmation requirement information is information that indicates whether dynamic privilege confirmation related to personal property is required when determining access privileges to the vehicle API. This specifies that dynamic authorization confirmation is required if the billing contract for accessing the vehicle API exists.

[0091] The privilege type information is information that indicates which attribute of SFOP the information corresponds to, and in the “personal property-related authorization policy,” this is set to F (i.e., financial).

[0092] The billing agreement content information is information that identifies the contents of the billing agreement for the Vehicle API. For example, it specifies the maximum number of times the Vehicle API can be used, limits on per-use fees, and so on. 4-4. Privacy-related authorization policy

[0093] A "privacy-related authorization policy" is described as an example of a dynamic viewpoint-specific policy classified under the P attribute. The privacy information is information stored in the vehicle related to the privacy of the vehicle user.

[0094] Whether a service application should be allowed to access the vehicle user's privacy information and to what extent depends on the vehicle user's mindset. Therefore, access to the privacy information requires the vehicle user's consent for each privacy information content. The consent details regarding the privacy information for each vehicle user are described in the Fig. 4 shown user information 313 can be seen.

[0095] As shown in the lower left part of Fig. As shown in Figure 9, the “privacy-related authorization policy” is information that associates an API ID with confirmation necessity information, privilege type information, and privacy information ID set for the vehicle API identified by this API ID.

[0096] The confirmation requirement information is information that indicates whether confirmation of a dynamic privilege regarding privacy is required when determining access privileges to the vehicle API. Here, it is specified that dynamic privilege confirmation is required if the function provided by the vehicle API includes access to privacy information.

[0097] The privilege type information is information that indicates which attribute of SFOP the information corresponds to, and in the “privacy-related authorization policy” this is set to P (i.e., privacy).

[0098] The privacy information ID lists IDs assigned to the privacy information that is the target of access by the vehicle API function. 4-5. Creating the API authorization policy

[0099] As it is in Fig. As can be seen in Figure 5, API authorization policy 311 contains a static policy and a dynamic policy.

[0100] A static policy is created by integrating several static viewpoint-specific policies into one. This means that, as described in Fig. 7 and Fig. 8, each static viewpoint-specific policy is expressed in a matrix format to indicate whether the service application identified by an application ID has an access privilege to the vehicle API identified by the API ID. Therefore, as stated in Fig. 10 that each square in the matrix representing the static policy has an access privilege if it holds that it has a privilege in all of the multiple viewpoint-specific policies that are integration targets, and it holds that it has no access privilege if it holds that it has no privilege in any of them.

[0101] The dynamic policy is created by integrating several dynamic viewpoint-specific policies into one. This means that, as shown in the left part of Fig. 9, the dynamic viewpoint-specific policy assigns information to each API ID. Therefore, the dynamic policy, as shown in the right part of Fig. 9, the API determines confirmation need information, privilege type information, and confirmation information for each API ID based on the multiple dynamic viewpoint-specific policies that are integration targets.

[0102] The confirmation necessity information is set to "necessary" if any of the pieces of confirmation necessity information of the multiple viewpoint-specific policies that are integration targets is necessary.

[0103] The privilege type information is set to the content specified in the privilege type information of the multiple viewpoint-specific policies that are integration targets.

[0104] The confirmation information is set to a content according to the privilege type information setting. That is, if the privilege type information is set to financial, the billing contract content is set as the confirmation information. If the privilege type information is set to privacy, the privacy information ID is set as the confirmation information.

[0105] With further reference to Fig. 5, the cloud server 200 distributes the API authorization policy generated by integrating a plurality of viewpoint-specific policies in this manner in response to a request from the in-vehicle system 100. The API authorization policy may be distributed in response to a request from the cloud server 200.

[0106] In the in-vehicle system 100, the API authorization policy obtained from the cloud server 200 is stored in the information storage 31 of the API gateway 30 and used for the access restriction process. 5. Process 5-1. Access restriction process

[0107] The access control process performed by the access control device 32 is described using the flowchart in Fig. 11 described.

[0108] In S110, the access controller 32 determines whether it has received the API access request from the service application. If it has received the API access request, the process moves to S120. If the access controller 32 has not received the API access request, it waits by repeating the same process.

[0109] In S120, the access controller 32 determines whether the request source application that issued the API access request has the access privilege based on the information specified in the API access request, using the static policy according to the API authorization policy. Specifically, the access controller 32 first uses the correspondence table 312 to identify the application ID from the process ID specified in the API access request. Next, the access controller 32 refers to a static policy based on the identified application ID and the API ID specified by the API access request, and determines whether the use source application identified from the application ID has the access privilege to the use target API identified from the AP ID.

[0110] If the access control device 32 determines in the next S130 that the use source application has an access privilege to the use target API, the process shifts to S140, and if it determines that the use source application does not have an access privilege, the process shifts to S220.

[0111] In S140, the access controller 32 determines whether dynamic privilege confirmation is required to access the target API by referring to the confirmation requirement information specified in the dynamic policy. If the access controller 32 determines that dynamic privilege confirmation is required, it moves the process to S150.

[0112] If the access controller 32 determines that dynamic privilege confirmation is not necessary, it shifts the process to S220.

[0113] In S150, the access controller 32 refers to the privilege confirmation type specified in the dynamic policy, and if the specified confirmation type is financial, the process moves to S160, and if the specified confirmation type is privacy, the process moves to S180.

[0114] In S160, the access control device 32 refers to the billing contract details specified in the confirmation information of the dynamic policy and obtains from the status monitoring unit 33 status information indicating the access status with respect to the billing contract details.

[0115] In the next step S170, the access controller 32 determines whether the value specified in the access status information is within the range of the billing contract contents. If it is within the range of the billing contract contents, the process shifts to S210, and if it is outside the range of the billing contract contents, the process shifts to S220.

[0116] In S180, the access control device 32 determines whether the usage source application has the access privilege to the privacy information identified by the privacy information ID. This determination is made by referring to the user information 313 using the privacy information ID specified in the dynamic policy confirmation information and the user ID of the vehicle user identified by the usage source application. If the access control device 32 determines that the access privilege to the privacy information exists, the process shifts to S190. If the access control device 32 determines that no access privilege to the privacy information exists, the process shifts to S220.

[0117] In S190, the access control device 32 queries the vehicle user, identified by the user ID, whether the vehicle user consents to access the privacy information. The query is made via email or voice call to the contact information registered in association with the user ID.

[0118] In the next step S200, the access control device 32 determines whether the vehicle user's consent has been obtained as a result of the query in S190. If consent has been obtained, the process shifts to S210, and if consent has not been obtained, the process shifts to S220.

[0119] In S210, the access control device 32 allows access from the usage source application to the usage target API, ie, it transmits an API access request to the usage target API and terminates the process.

[0120] In S220, the access control device 32 denies access from the usage source application to the usage target API, ie, it discards the API access request and terminates the process. 5-2. Policy generation and deployment process

[0121] The policy generation provision process executed by the controller 201 of the cloud server 200 will be described with reference to a flowchart of Fig. 13 described.

[0122] In S310, the controller 201 obtains the viewpoint-specific policy generated individually for each viewpoint. The viewpoint-specific policy may be stored in the memory 202 or may be input from a terminal device or the like connected to the cloud server 200 via a wide area network or the like.

[0123] In the next step S320, the controller 201 generates an API authorization policy 311 by integrating the multiple viewpoint-specific policies obtained in S310. Of the API authorization policies 311, the static policy is generated by integrating multiple static viewpoint-specific policies, as shown in Fig. 10, the dynamic policy is generated by integrating several dynamic viewpoint-specific policies, as shown in Fig. 9 can be seen.

[0124] In the next S330, the controller 201 stores the API authorization policy 311 generated in S320 in the memory 202.

[0125] In the next step S340, if the predetermined deployment conditions are met, the controller 201 transmits the API authorization policy 311 stored in the memory 202 to the in-vehicle system 100 for which the policy is to be deployed, and terminates the process. The deployment conditions may include that there is a request from the in-vehicle system 100, that a new viewpoint-specific policy is stored in the memory 202, and the like. 6. Effects

[0126] According to the embodiment described above, the following effects are achieved.

[0127] The API authorization policy 311, which is generated by the cloud server 200 (i.e., outside the vehicle) and integrates multiple standpoint-specific policies, is distributed to the in-vehicle system 100 (i.e., inside the vehicle). By using the distributed API authorization policy 311, the in-vehicle system 100 can easily determine whether the usage source application has the access privilege to the usage target API without having to make a determination for each standpoint-specific policy individually. As a result, it is possible to reduce the load on the in-vehicle system 100 required for the determination.

[0128] API Authorization Policy 311 includes the dynamic policy for determining whether an access privilege exists based on information that dynamically changes depending on the situation at a given time and the user's intent. Therefore, it is possible to flexibly handle access restrictions that change depending on, for example, the contents of a billing agreement or attitudes toward private information. 7. Correspondence of concepts

[0129] The API gateway 30 in the present embodiment corresponds to the coordination control device in the present disclosure. The service applications belonging to the service system functional block groups 23 and 24, the control system functional block group 25, and the data system functional block group 26 in this disclosure correspond to functional blocks in the present disclosure. The information storage 31 in the present embodiment corresponds to a policy storage in the present disclosure. The API authorization policy in the present embodiment corresponds to an authorization policy in the present disclosure. The cloud server 200 in the present embodiment corresponds to an authorization policy provision unit and a management server in the present disclosure.The in-vehicle devices 2 to 5 in the present embodiment correspond to an electronic control unit in the present disclosure. The memory 202 in the present embodiment corresponds to an authorization policy memory in the present disclosure. The processes S310 to S330 executed by the controller 201 in the present embodiment correspond to an authorization policy generation unit in the present disclosure. The process S340 executed by the controller 201 in the present embodiment corresponds to an authorization policy provision unit in the present disclosure. 8. Technical concepts in this descriptionFirst feature

[0130] A mobility service provision system includes: a vehicle control system including a plurality of electronic control units mounted in a vehicle and connected to an in-vehicle network; and an authorization policy provision unit provided outside the vehicle. The in-vehicle system includes: a plurality of functional blocks, each of which is mounted in one of the plurality of electronic control units and configured to execute a predetermined process; and a coordination controller configured to implement coordination between the plurality of functional blocks.The coordination control device includes: a policy storage configured to acquire and store an authorization policy defining an access privilege between the plurality of functional blocks from the authorization policy provision unit; an access control device configured to, when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, determine, based on the authorization policy stored in the policy storage, whether the usage source block has access privilege to the usage target block, and to transmit the access request to the usage target block if it is determined that the access privilege exists.The authorization policy providing unit is configured to provide, as the authorization policy, to the in-vehicle system a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks. Second feature

[0131] In a mobility service provision system according to the first feature, one of the viewpoint-specific policies has a security of a function provided by the function block as the viewpoint. Third feature

[0132] In the mobility service provision system according to the first feature or the second feature, one of the plurality of viewpoint-specific policies has a viewpoint of a reliability of a provider of the plurality of functional blocks. Fourth feature

[0133] In the mobility service provision system according to any one of the first to third features, the authorization policy includes, in addition to the static viewpoint policy, at least one dynamic viewpoint policy that defines the access privilege for each of at least one viewpoint focusing on a dynamic attribute of the plurality of functional blocks. Fifth characteristic

[0134] In the mobility service provision system according to the fourth feature, one of the at least one dynamic viewpoint policy has, as the viewpoint, the presence or absence of a consent of a vehicle user. Sixth characteristic

[0135] In the mobility service provision system according to the fourth feature or the fifth feature, one of the at least one dynamic viewpoint policy has, as the viewpoint, an access status between the plurality of functional blocks. Seventh characteristic

[0136] In the mobility service provision system according to any one of the first to sixth features, the authorization policy is generated to have, as the viewpoint, at least one of the areas of security, finance, operation, or privacy, and the security, finance, operation, and privacy are classified as a security protection asset. Eighth characteristic

[0137] An in-vehicle system includes: a plurality of functional blocks, each of which is mounted in one of a plurality of electronic control units connected to an in-vehicle network and configured to execute a predetermined process; and a coordination controller configured to implement coordination between the plurality of functional blocks.The coordination control device includes: a policy storage configured to store an authorization policy defining an access privilege between the plurality of functional blocks; an access control device (32) configured to, when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, determine, based on the authorization policy stored in the policy storage, whether the usage source block has access privilege to the usage target block, and to transmit the access request to the usage target block if it is determined that the access privilege exists.The authorization policy includes a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints focusing on a static attribute of the plurality of functional blocks. Ninth characteristic

[0138] A management server communicatively connected to a vehicle having an in-vehicle system including a plurality of electronic control units connected to an in-vehicle network. The management server includes: an authorization policy storage mounted in any one of the plurality of electronic control units and configured to store an authorization policy referenced for controlling an access privilege from a use source block, which is one of the plurality of functional blocks configured to execute a predetermined process, to a use target block, which is another of the plurality of functional blocks;an authorization policy generation unit configured to generate a static viewpoint policy by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks, and to cause the authorization policy storage to store the static viewpoint policy as the authorization policy; and an authorization policy provision unit configured to provide the authorization policy stored in the authorization policy storage to the vehicle. Tenth characteristic

[0139] In the management server according to the ninth feature, the authorization policy generation unit is configured to generate a dynamic viewpoint policy by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a dynamic attribute of the plurality of functional blocks, and to cause the authorization policy storage to store the dynamic viewpoint policy as the authorization policy. Eleventh characteristic

[0140] An access control method controls access between a plurality of functional blocks by at least one of a plurality of electronic control units using an authorization policy that defines an access privilege between the plurality of functional blocks, each of which is mounted on any one of the plurality of electronic control units and configured to execute a predetermined process, wherein the at least one of a plurality of electronic control units is connected to an in-vehicle network.The access control method includes: using, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks; when an access request is received from a usage source block that is one of the plurality of functional blocks to a usage target block that is another of the plurality of functional blocks, determining whether the usage source block has access privilege to the usage target block according to the authorization policy; and transmitting the access request to the usage target block when it is determined that the access privilege exists. Twelfth characteristic

[0141] A program controls access between a plurality of functional blocks by using an authorization policy that defines an access privilege between the plurality of functional blocks, each of which is mounted on one of a plurality of electronic control units and configured to execute a predetermined process, wherein the at least one of a plurality of electronic control units is connected to an in-vehicle network. The program is configured to: use, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks;and causing a computer to implement a function of: when receiving an access request from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, determining whether the usage source block has access privilege to the usage target block according to the authorization policy; and transmitting the access request to the usage target block if it is determined that the access privilege exists.

[0142] In the eighth to twelfth characteristics, content equivalent to the description in the second to seventh characteristics can be added. 8. Other embodiments

[0143] Although the embodiment of the present disclosure has been described above, the present disclosure is not limited to the above-described embodiment, and various modifications may be made to implement the present disclosure. (a) In the above embodiment, no example is given for the O attribute, however, it is possible to use an attribute-based policy generated with the same idea as in the case of the S attribute. For example, when controlling an air conditioner, a policy can be set such that the AUTO setting is not changed to an uncomfortable setting. While the S attribute targets important issues that are life-threatening, the O attribute also targets comfort and convenience. (b) In the above embodiment, the ECU 2 includes both the real-time processing unit 10 and the application processing unit 20, but it may include only one of them. (c) In the above embodiment, although the ECU 2 is equipped with the service system functional block groups 23, 24, a control system functional block group 25, and a data system functional block group 26, other in-vehicle devices 3 to 5 may be equipped with at least part of the functional block groups 23 to 26. In addition, the functional block groups 23 to 26 may be centrally arranged in any one of the in-vehicle devices 2 to 5, or may be distributed among a plurality of in-vehicle devices 2 to 5. (d) The in-vehicle devices 2 to 5 and the like and the methods according to the present disclosure can be achieved by a dedicated computer provided by forming a processor and a memory programmed to perform one or more functions embodied by a computer program. Alternatively, the in-vehicle devices and the like and the methods according to the present disclosure can be achieved by a dedicated computer provided by forming a processor with one or more dedicated hardware logic circuits.Alternatively, the in-vehicle devices and the like and the methods described in the present disclosure may be achieved by one or more dedicated computers configured by combinations of processors and memories programmed to perform one or more functions, and processors configured by one or more hardware logic circuits. The computer program may be stored in a computer-readable non-transitory tangible storage medium as instructions to be executed by a computer. The technology for implementing the functions of each unit included in the in-vehicle devices and the like does not necessarily have to include software, and all functions may be implemented using one or a plurality of hardware circuits. (e) A plurality of functions of an element in the above embodiment may be implemented by a plurality of elements, or one function of an element may be implemented by a plurality of elements. In addition, multiple functions of multiple components may be realized by one component, or a single function realized by multiple components may be realized by one component. Part of the configuration of the above embodiment may be omitted. At least part of the configuration in one embodiment may be added to or replaced by the configuration of another embodiment. (f) In addition to the above-described mobility service provision system 1, the in-vehicle system 100, and the cloud server 200 as the authorization policy provision unit and the management server, the present disclosure may also be implemented in various forms such as a program for causing a computer to function as the in-vehicle system 100 and the authorization policy provision unit, a non-volatile tangible storage medium such as a semiconductor memory in which this program is stored, and an access control method. QUOTES CONTAINED IN THE DESCRIPTION

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

[0000] JP 2022-074970

[0001] JP 6124627 B

[0004]

Claims

[1] Mobility service provision system, comprising: an in-vehicle system including a plurality of electronic control units mounted in a vehicle and connected to an in-vehicle network; an authorization policy provisioning unit provided outside the vehicle, where The in-vehicle system contains: a plurality of functional blocks, each of which is mounted in one of the plurality of electronic control units and configured to perform a predetermined process; and a coordination control device configured to implement coordination between the plurality of functional blocks, wherein the coordination control device includes: a policy store configured to obtain and store an authorization policy defining an access privilege between the plurality of functional blocks from the authorization policy provision unit; and an access control device configured to when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, to determine, based on the authorization policy stored in the policy storage, whether the access privilege of the usage source block to the usage target block exists, and to transmit the access request to the usage target block if it determines that the access privilege exists, and the authorization policy providing unit is configured to provide, as the authorization policy, to the in-vehicle system a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints centered on a static attribute of the plurality of functional blocks. [2] The mobility service provision system according to claim 1, wherein one of the plurality of viewpoint-specific policies has, as a viewpoint, the security of a function provided by the plurality of function blocks. [3] The mobility service provisioning system according to claim 1, wherein one of the plurality of viewpoint-specific policies has a viewpoint of reliability of a provider of the plurality of functional blocks. [4] The mobility service provision system according to any one of claims 1 to 3, wherein the authorization policy includes, in addition to the static viewpoint policy, at least one dynamic viewpoint policy that defines the access privilege for each of at least one viewpoint focusing on a dynamic attribute of the plurality of functional blocks. [5] The mobility service provision system according to claim 4, wherein one of the at least one dynamic viewpoint policy has, as the viewpoint, the presence or absence of a consent of a vehicle user. [6] The mobility service provision system according to claim 4, wherein one of the at least one dynamic viewpoint policy has, as the viewpoint, an access status between the plurality of functional blocks. [7] The mobility service provision system according to claim 1, wherein the authorization policy is generated to have, as the viewpoint, at least one of security, finance, operation, or privacy, and the security, finance, operation, and privacy are classified as a security protection asset. [8] In-vehicle system comprising: a plurality of functional blocks, each of which is mounted in one of a plurality of electronic control units connected to an in-vehicle network and configured to execute a predetermined process; and a coordination control device configured to implement coordination between the plurality of functional blocks, where the coordination control device contains: a policy store configured to store an authorization policy defining an access privilege between the plurality of functional blocks; an access control device configured to when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, to determine, based on the authorization policy stored in the policy storage, whether the access privilege of the usage source block to the usage target block exists, and to transmit the access request to the target block if it is determined that the access privilege exists, and the authorization policy includes a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints that focus on a static attribute of the plurality of functional blocks. [9] A management server communicatively connected to a vehicle having an in-vehicle system including a plurality of electronic control units connected to an in-vehicle network, the management server comprising: an authorization policy storage mounted in any one of the plurality of electronic control units and configured to store an authorization policy referred to for controlling an access privilege from a use source block, which is one of a plurality of functional blocks configured to execute a predetermined process, to a use target block, which is another of the plurality of functional blocks; an authorization policy generation unit configured to generate a static viewpoint policy by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints that focus on a static attribute of the plurality of functional blocks, and cause the authorization policy store to store the static viewpoint policy as the authorization policy; and an authorization policy provision unit configured to provide the authorization policy stored in the authorization policy storage to the vehicle. [10] The management server according to claim 9, wherein the authorization policy generation unit is configured to generate a dynamic viewpoint policy by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints that focus on a dynamic attribute of the plurality of functional blocks, and to cause the authorization policy store to store the dynamic viewpoint policy as the authorization policy. [11] An access control method for controlling access between a plurality of functional blocks by at least one of a plurality of electronic control units using an authorization policy defining an access privilege between the plurality of functional blocks, each of which is mounted on any one of the plurality of electronic control units and configured to execute a predetermined process, wherein the at least one of a plurality of electronic control units is connected to an in-vehicle network, the access control method comprising: Using, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints focusing on a static attribute of the plurality of functional blocks; when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, determining according to the authorization policy whether the usage source block has the access privilege to the usage target block; and Transfer the access request to the target block if it is determined that the access privilege exists. [12] A program for controlling access between a plurality of functional blocks by using an authorization policy defining an access privilege between the plurality of functional blocks, each of which is mounted on one of a plurality of electronic control units and configured to execute a predetermined process, wherein at least one of the plurality of electronic control units is connected to an in-vehicle network, the program being configured to: Using, as the authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies based on the plurality of viewpoint-specific policies that define the access privilege for each of a plurality of viewpoints that focus on a static attribute of the plurality of functional blocks; and Causing a computer to implement a function to: when an access request is received from a usage source block, which is one of the plurality of functional blocks, to a usage target block, which is another of the plurality of functional blocks, determining according to the authorization policy whether the usage source block has the access privilege to the usage target block; and Transfer the access request to the target block if it is determined that the access privilege exists.

Images