Mobility service providing system, in-vehicle system, management server, access control method, and program

Abstract

In this invention, an authorization policy provision unit provides an in-vehicle system with a static viewpoint policy, which is generated by integrating a plurality of viewpoint-specific policies, as an authorization policy. An access control unit, upon receiving an access request, uses the authorization policy provided by the authorization policy provision unit and stored in a policy storage unit to determine whether or not there is a right of access from a usage requesting block to a usage requested block. If it is determined that there is an access right, the access control unit forwards the access request to the usage requested block.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0002] The present disclosure relates to techniques for controlling access. [Background technology]

[0003] The following Patent Document 1 describes a technology that uses an access authorization policy to restrict access when an access to system resources or information via a service application is detected in an open platform for mobile terminals. The access authorization policy specifies whether "who," "to what," and "what to do" are permitted or prohibited. [Prior art documents] [Patent documents]

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

[0005] It is expected that in the future, an unspecified number of third-party service applications will be installed in electronic control systems (hereinafter referred to as in-vehicle systems) installed in vehicles. When third-party service applications access vehicle functions and information, it will be necessary to restrict access as necessary. Furthermore, as in-vehicle systems become more sophisticated and a wide variety of service applications are installed, access control will also become more complex. Access control that ensures real-time performance while utilizing the limited resources of in-vehicle systems will be required.

[0006] One aspect of the present disclosure provides a technique for simplifying access control using access authorization policies.

[0007] A mobility service providing system according to an aspect of the present disclosure includes an in-vehicle system and an authorization policy provider. 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 provider is provided external to the vehicle.

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

[0009] The cooperation control unit includes a policy storage unit and an access control unit. The policy storage unit is configured to acquire and store an authorization policy that defines access permissions between functional blocks from the authorization policy providing unit. The access control unit receives an access request from a source block that is one of the multiple functional blocks to a destination block that is another of the multiple functional blocks. Upon receiving the access request, the access control unit determines whether the source block has access permission to the destination block using the authorization policy stored in the policy storage unit. If it is determined that access permission exists, the access control unit is configured to transmit the access request to the destination block.

[0010] The authorization policy providing unit is configured to provide the in-vehicle system with a static viewpoint policy generated by integrating the viewpoint policies as an authorization policy. The viewpoint policies define access rights for each of a plurality of viewpoints focusing on static attributes of the functional blocks.

[0011] According to this configuration, the in-vehicle system determines whether or not the source block has access permission to the destination block by using an authorization policy including a static viewpoint policy that integrates multiple viewpoint-specific policies. Therefore, the in-vehicle system can easily determine whether or not the source block has access permission all at once, without individually determining whether or not the destination block has access permission for each of the multiple viewpoint-specific policies. Furthermore, the authorization policy is acquired from outside the vehicle. As a result, the load required for determining access permission in the in-vehicle system can be reduced.

[0012] According to one aspect of the present disclosure, an in-vehicle system includes a plurality of functional blocks and a cooperation control unit. Each of the functional blocks is mounted on one of a plurality of electronic control units connected to an in-vehicle network, and each is configured to execute a predetermined process. The cooperation control unit is configured to realize cooperation between the plurality of functional blocks.

[0013] The cooperation control unit includes a policy storage unit and an access control unit. The policy storage unit is configured to store an authorization policy that defines access permissions between functional blocks. The access control unit receives an access request from a source block, which is one of the multiple functional blocks, to a destination block, which is another of the multiple functional blocks. Upon receiving the access request, the access control unit determines whether the source block has access permission to the destination block, using the authorization policy stored in the policy storage unit. If it is determined that access permission exists, the access control unit is configured to transmit the access request to the destination block.

[0014] The authorization policy is configured to include a static viewpoint policy that is generated by integrating multiple viewpoint-specific policies based on multiple viewpoint-specific policies that specify access rights for each of multiple viewpoints focusing on static attributes possessed by the functional block.

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

[0016] The authorization policy storage unit is mounted in one of the electronic control devices and is configured to store an authorization policy referenced to control access authority from the source block to the destination block. The source block is one of the multiple function blocks configured to execute a predetermined function. The destination block is another of the multiple function blocks.

[0017] The authorization policy generation unit is configured to generate a static viewpoint policy by integrating a plurality of static viewpoint-specific policies based on a plurality of static viewpoint-specific policies that define access rights for each of a plurality of viewpoints focusing on static attributes of the function block. The authorization policy generation unit is also configured to store the generated static viewpoint policy in the authorization policy storage unit as an authorization policy.

[0018] The authorization policy providing unit is configured to provide the authorization policy stored in the authorization policy storage unit to the vehicle.

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

[0020] In the access control method, a static viewpoint policy is generated by integrating a plurality of viewpoint-specific policies, each of which defines access rights for each of a plurality of viewpoints focusing on static attributes of a functional block, and the static viewpoint policy is used as the authorization policy. When an access request is received from a source block, which is one of the plurality of functional blocks, to a destination block, which is another of the plurality of functional blocks, the presence or absence of the source block's access authority to the destination block is determined in accordance with the authorization policy, and if it is determined that the access authority exists, the access request is transmitted to the destination block.

[0021] A program according to one aspect of the present disclosure realizes an access control method that controls access between multiple functional blocks, each of which is installed in one of multiple electronic control devices connected to an in-vehicle network and configured to perform a predetermined process, using an authorization policy that specifies access rights between the functional blocks.

[0022] The program uses, as an authorization policy, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies, each of which defines access rights for each of a plurality of viewpoints focusing on static attributes of a functional block. Furthermore, the program causes a computer to realize a function of, upon receiving an access request from a source block, which is one of the plurality of functional blocks, to a destination block, which is another of the plurality of functional blocks, determining whether the source block has access authority to the destination block in accordance with the authorization policy, and, if it is determined that the access authority exists, transmitting the access request to the destination block. [Brief explanation of the drawings]

[0023] [Figure 1] 1 is a block diagram showing the configuration of a mobility service providing system. [Figure 2] FIG. 2 is a block diagram showing the configuration of an ECU. [Figure 3] FIG. 1 is a block diagram illustrating the configuration of an API gateway. [Figure 4] FIG. 2 is an explanatory diagram showing the contents of user information. [Figure 5] FIG. 10 is an explanatory diagram showing an outline of an authorization policy. [Figure 6] FIG. 10 is an explanatory diagram of API access rights related to security levels. [Figure 7] FIG. 10 is an explanatory diagram illustrating a static viewpoint-specific policy with security as a viewpoint; [Figure 8] FIG. 10 is an explanatory diagram illustrating a static viewpoint-specific policy with corporate assets as a viewpoint; [Figure 9] 10 is an explanatory diagram illustrating a dynamic viewpoint-based policy that uses personal property as a viewpoint, a dynamic viewpoint-based policy that uses privacy as a viewpoint, and a dynamic policy that integrates the dynamic viewpoint-based policies; FIG. [Figure 10] FIG. 10 is an explanatory diagram illustrating a static policy that integrates static viewpoint-specific policies. [Figure 11] 10 is a flowchart of an access restriction process executed by an access control unit. [Figure 12] FIG. 2 is a block diagram showing the configuration of a cloud server. [Figure 13] 10 is a flowchart of a policy generation and provision process executed by a cloud server. DETAILED DESCRIPTION OF THE INVENTION

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

[0025] [1. Configuration] The mobility service providing system 1 of this embodiment includes an in-vehicle system 100 mounted on a vehicle, and a cloud server 200. 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 or a hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. Hereinafter, a vehicle equipped with the in-vehicle system 100 will be simply referred to as a vehicle.

[0026] 1, the in-vehicle system 100 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, which is divided according to the vehicle's functions, and mainly controls the multiple ECUs 4 present within that domain. Each ECU 3 is connected to its subordinate ECUs 4 via a lower-level network (e.g., CAN) provided individually. CAN is an abbreviation for Controller Area Network and is a registered trademark. The ECU 3 has the function of centrally managing access rights to the subordinate ECUs 4 and authenticating users. The domains are, for example, the powertrain, body, chassis, and cockpit.

[0029] The ECUs 4 connected to the ECUs 3 belonging to the powertrain domain include, for example, an ECU 4 that controls the engine, an ECU 4 that controls the motor, and an ECU 4 that controls the 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 ECUs 3 belonging to the chassis domain include, for example, an ECU that controls braking and an ECU 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 meters and navigation displays, and an ECU 4 that controls input devices operated by vehicle occupants.

[0033] The external vehicle communication device 5 performs data communication with external vehicle devices such as the cloud server 200 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 including a CPU2a, a ROM2b, a RAM2c, etc. Various functions of the microcomputer are realized by the CPU2a executing a program stored in a non-transitory storage medium. In this example, the ROM2b corresponds to the non-transitory storage 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 as hardware using one or more ICs, etc. Furthermore, the number of microcomputers constituting the ECU2 may be one or more.

[0036] Like the ECU 2, the ECU 3, the ECU 4, and the exterior communication device 5 are all electronic control devices mainly configured with a microcomputer including a CPU, a ROM, a RAM, etc. Furthermore, the number of microcomputers configuring the ECU 3, the ECU 4, and the exterior communication device 5 may be one or more.

[0037] In the following description, the ECU 2, ECU 3, ECU 4, and the external vehicle communication device 5 will be referred to as the on-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 multiple 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 other tasks that require 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) that require high processing power.

[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 the in-vehicle devices 3 to 5 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] As shown in FIG. 12, the cloud server 200 includes a control unit 201, a storage unit 202, and a communication unit 203. The control unit 201 is an electronic control device mainly configured with a microcomputer including a CPU 201a, a ROM 201b, a RAM 201c, etc. Various functions of the microcomputer are realized by the CPU 201a executing a program stored in a non-transitory physical recording medium. In this example, the ROM 201b corresponds to the non-transitory physical recording medium storing the program. Furthermore, by executing this program, a method corresponding to the program is executed. The control unit 201 executes at least a policy generation and provision process.

[0042] The storage unit 202 stores a plurality of authorization policies. The authorization policies stored in the storage unit 202 include static-perspective policies and dynamic-perspective policies generated by a policy generation and provision process executed by the control unit 201. The authorization policies may also include a plurality of viewpoint-specific policies used when generating the static-perspective policies and the dynamic-perspective policies.

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

[0044] [2. Functional configuration] The software installed in the in-vehicle devices 2 to 5 belonging to the in-vehicle system 100 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 mobility service providing system 1 does not necessarily have to be built in accordance with AUTSAR.

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

[0046] The platform comprises a runtime environment (hereafter referred to as RTE) and platform software (hereafter referred to as BSW). The RTE is the interface that connects SW-Cs with each other and between SW-Cs and BSW. The BSW is the layer that connects hardware and SW-Cs 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-Cs via an API. API stands for Application Programming Interface.

[0047] In the following, 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] 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 apps) that run on the first PF 11. A service app is an application that receives a request from a client, processes the request, and returns the result. Each service app is composed of one or more SW-Cs.

[0049] The control system functional block group 12 is an application that has an API that receives commands related to vehicle movement and manages the commands received by the API to achieve consistent vehicle control. The control system functional block group 12 outputs various commands via CAN FD to the in-vehicle devices 3 to 5 that execute control based on the commands.

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

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

[0052] The application processing unit 20 includes service function block groups 23 and 24 as a group of service applications that run on the second PF 21.

[0053] The service function block group 23 is a collection of service applications (hereinafter referred to as OEM applications) provided by the OEM. Each OEM application has one or more SW-Cs. The OEM is the vehicle manufacturer that produced the vehicle. OEM stands for Original Equipment Manufacturer. The OEM applications may include applications developed by the OEM itself and applications developed by other vendors.

[0054] The service function block group 24 is a collection of service applications (hereinafter referred to as "3rd applications") provided by third parties. Each 3rd application includes one or more SW-Cs. The third parties are parties other than the vehicle owner and the OEM. For example, a data utilization company that provides services by collecting data from the vehicle can be cited as a third party.

[0055] The second PF 21 includes 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 collection of service applications equipped with APIs for receiving requests related to vehicle control from the service system functional block groups 23 and 24. The control system functional block group 25 converts API access requests from the service system functional block groups 23 and 24, which are expressed in a vehicle-independent format, into API access requests expressed in a vehicle-dependent format and provides the APIs to the real-time processing unit 10. The APIs provided in the control system functional block group 25 include motor system APIs that control the vehicle's motion and non-motor system APIs other than the motor system APIs. The API access requests received by the motor system APIs are forwarded to the control system functional block group 12, and then forwarded from the control system functional block group 12 to the on-board devices 3 to 5 that execute control based on the requests via the in-vehicle communication network 6, such as CAN FD. The API access requests received by the non-motor system APIs are forwarded to the on-board devices 3 to 5 that execute control based on the requests via the in-vehicle communication network 6, such as CAN FD.

[0057] The data-related functional block group 26 is a collection of service applications 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 vehicle data, which is supplied from the real-time processing unit 10 and expressed in a vehicle-dependent format, into a vehicle-independent format and accumulating the data. The data-related functional block group 26 may have an API that provides a function of transmitting specified vehicle data to an in-vehicle device or the like via an in-vehicle communication network 6 such as Ethernet. In particular, when the destination is an external communication device 5, the external communication device 5 may upload the transmitted vehicle data to the cloud. The data-related functional block group 26 may also have an API that provides a function of acquiring data from the cloud server 200.

[0058] Note that communication with the other on-board devices 3 to 5 via the control system functional block group 25 is not limited to CAN FD, and Ethernet or other communication means may be used. Also, communication with the other on-board devices 3 to 5 via the data system functional block group 26 is not limited to Ethernet, and CAN FD or other communication means may be used.

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

[0060] The API gateway 30 is configured using the functions of a virtual function bus (hereinafter referred to as VBF). The VBF is middleware, also called a software bus, that enables communication between SW-Cs and between SW-Cs and BSWs without regard to hardware, communication protocols, etc. Communication between SW-Cs is performed between service apps belonging to the service function block groups 23 and 24, and refers to access from an SW-C to an API provided by another SW-C. Communication between an SW-C and a BSW is performed between a service app belonging to the service function block groups 23 and 24 and a service app belonging to the control function block group 25 and the data function block group 26, and refers to access from an SW-C to a vehicle API. In the following description, it is assumed that there is a one-to-one correspondence between an SW-C and a service app.

[0061] When a service application uses a function provided by the control system functional block group 25 and the data system functional block group 26, the service application transmits an API access request, which is a request for access to the vehicle API. The API access request includes at least the process ID of the service application that is the source of use (hereinafter referred to as the source application) and an API-ID, which is information that uniquely identifies the vehicle API that is the destination of use (hereinafter referred to as the destination API).

[0062] [3. Access Restriction Mechanism] The following describes an access restriction mechanism in which the API gateway 30 restricts access from service apps to vehicle APIs. The access restriction mechanism is set from the perspective of SFOP, an attribute defined as a security-protected asset. S stands for Safety, and refers to access restrictions on API access that affect safety. F stands for Financial, and refers to access restrictions on API access that affect the assets of a company or individual. O stands for Operational, and refers to access restrictions on API access that affect the operational performance of the vehicle. P stands for Privacy, and refers to access restrictions on API access that affect privacy information.

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

[0064] As shown in FIG. 3, the API gateway 30 includes an information storage unit 31, an access control unit 32, and a status monitoring unit 33.

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

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

[0067] The correspondence table 312 includes information that associates a process ID dynamically assigned to a process, which is a unit of program execution in an operating system (hereinafter referred to as OS), with a unique application ID of a service app executed by that process. The correspondence table 312 also includes information that associates a unique API-ID assigned to each vehicle API with a process ID of a process assigned to a service app, which is an entity that executes the API function. The correspondence table 312 is generated by the OS when a process for each service app is generated at system startup.

[0068] The user information 313 is information that is referenced when determining whether or not an access right 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. 4, the user information 313 has content that sets, for each vehicle user identified by a user ID, whether or not to permit an access request from a service app to privacy information identified by a privacy information ID. The user information 313 may also include contact information for the vehicle user.

[0069] When the access control unit 32 receives an API access request, it identifies the application ID of the source application from the process ID indicated in the API access request using the correspondence table 312. The access control unit 32 executes access restriction processing to determine whether or not access is authorized, based on the identified application ID and the API-ID of the destination API indicated in the API access request, in accordance with the API authorization policy 311. The access restriction processing will be described in detail later.

[0070] The status monitoring unit 33 monitors the access status from each service app to each vehicle API and generates status information that indicates the access status. The status information is generated by, for example, tallying up the number of accesses to each vehicle API and the amount of data handled in processing for each use source app.

[0071] [4.API Authorization Policy] A method for generating the API authorization policy 311 distributed by the cloud server 200 will be described.

[0072] 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 policies generated outside the cloud server 200 may be collected. A viewpoint-specific policy does not necessarily have to be prepared for all attributes of the SFOP. Also, multiple viewpoint-specific policies may be prepared for one attribute.

[0073] The viewpoint-specific policies include static viewpoint-specific policies generated from a viewpoint focusing on static attributes of the service app, and dynamic viewpoint-specific policies generated from a viewpoint focusing on dynamic attributes of the service app. The static attributes of the service app are information about characteristics that do not change depending on the usage environment, usage situation, etc. of the service app, and include, for example, information indicating the safety of the processing performed by the service app and information indicating the provider of the service app. The dynamic attributes of the service app are information about characteristics that change depending on the usage environment, usage situation, etc. of the service app, and include, for example, restrictions imposed by the billing contract of the service app provider and information arbitrarily set by the vehicle user.

[0074] [4-1. Safety Approval Policy] We will explain the "safety authorization policy," which is an example of a static viewpoint-based policy classified as an S attribute.

[0075] As a premise, service apps that execute processes related to vehicle safety (hereinafter referred to as safety apps) are assigned a safety level (hereinafter referred to as assurance level) that indicates the reliability of the safety of the processes executed by the safety apps. In addition, APIs provided by safety apps (hereinafter referred to as safety APIs) are assigned a safety level (hereinafter referred to as required level) that is required of service apps that use the safety APIs and request access to them.

[0076] The safety level is, for example, the Automotive Safety Integrity Level (hereinafter referred to as ASIL). ASIL is a risk classification system defined in the ISO26262 standard for the functional safety of road vehicles. ASIL is determined by three parameters: probability of exposure, controllability, and severity, and is expressed in four levels, A to D. A is the lowest level and D is the highest level. No required level is assigned to non-safety system APIs, and the absence of a required level is represented by QM. In other words, the safety level is essentially expressed in five levels, QM, A to D, with QM being the lowest level. The safety level does not necessarily have to use ASIL; it can be any safety level defined to have multiple levels. Therefore, the safety level does not have to be four levels, A to D, but can be three levels or less, or five levels or more.

[0077] Figure 6 shows a list indicating whether a service app has access rights to APIs, using a matrix that shows all combinations of the service app's assurance level and the API's required level. In the list, a circle indicates that access rights are available, and an x ​​indicates that access rights are not available. In this example, access rights are available when the assurance level is equal to or higher than the required level, and access rights are not available when the assurance level is lower than the required level. As shown in the left diagram in Figure 6, for example, a service app with assurance level A has access rights to APIs with required level A, but does not have access rights to APIs with required level D. A service app with assurance level D has access rights to all APIs with required level D and above.

[0078] As shown in FIG. 7, the "security authorization policy" is generated by combining the application information, API information, and the list of access permissions shown in FIG.

[0079] The application information is information that associates an application ID with an assurance level assigned to a service application identified by the application ID. The API information is information that associates an API-ID with a requirement level assigned to a vehicle API identified by the API-ID.

[0080] The "security authorization policy" is represented by a list that defines whether a source application identified by an application ID has access rights to a destination API identified by an API-ID.

[0081] [4-2. Corporate Property Authorization Policy] An example of a static viewpoint-based policy classified as an F attribute, "authorization policy regarding corporate assets," will be described below.

[0082] As a premise, service apps are assigned group attributes according to their provider. The group attributes are: GA for OEM apps developed in-house, GB for OEM apps developed by other vendors, and GC for 3rd party apps developed by third parties.

[0083] As shown in FIG. 8, the "authorization policy for corporate assets" is generated by combining access right information by group attribute and application information.

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

[0085] The access right information by group attribute is information indicating whether a service app having a certain group attribute has access rights to a vehicle API identified by the API-ID, using a matrix that represents all combinations of the API-ID of the vehicle API and the group attribute. The reliability of service apps viewed from the group attribute is, for example, GA>GB>GC, and access rights to each vehicle API are also set based on this reliability.

[0086] The content of the "authorization policy for corporate assets," like the "authorization policy for safety," is expressed as a list that defines whether or not a source application, identified by an application ID, has access rights to a destination API, identified by an API-ID.

[0087] [4-3. Personal Property Authorization Policy] We will now explain the "personal property authorization policy," which is an example of a dynamic viewpoint-based policy classified as an F attribute.

[0088] The "personal property authorization policy" is used to determine whether or not access is authorized depending on the access status of each vehicle API in accordance with the API billing agreement of the service app provider.

[0089] As shown in the upper left section of Figure 9, the "authorization policy for personal property" is information that associates an API-ID with confirmation requirement information, authority type information, and billing contract content information set for the vehicle API identified by that API-ID.

[0090] The verification necessity information indicates whether or not dynamic authorization verification for personal property is required when determining access authorization to the vehicle API. In this case, it is set to require dynamic authorization verification if a billing contract exists for access to the vehicle API.

[0091] The authority type information is information indicating which attribute of the SFOP the information corresponds to, and is set to F (that is, Financial) in the "authorization policy for personal property."

[0092] The billing contract content information is information indicating the contents of the billing contract for the vehicle API, such as the upper limit on the number of times the vehicle API can be used and restrictions on pay-per-use billing.

[0093] [4-4. Privacy Policy] The following describes an "authorization policy regarding privacy," which is an example of a dynamic viewpoint-based policy classified into the attribute P. Privacy information is information stored in a vehicle that relates to the privacy of a vehicle user.

[0094] Whether or not to allow a service app to access the vehicle user's privacy information and to what extent the access is permitted depends on the vehicle user's way of thinking. Therefore, access to privacy information requires the vehicle user's consent for each piece of privacy information. The consent content regarding the privacy information for each vehicle user is shown in the user information 313 shown in FIG. 4.

[0095] As shown in the lower left section of Figure 9, the "privacy authorization policy" is information that associates an API-ID with confirmation requirement information, authority type information, and privacy information ID set for the vehicle API identified by that API-ID.

[0096] The confirmation necessity information indicates whether or not dynamic permission confirmation regarding privacy is required when determining access permission to the vehicle API. Here, it is set to require dynamic permission confirmation when the function provided by the vehicle API includes access to privacy information.

[0097] The authority type information is information indicating which attribute of the SFOP the information corresponds to, and is set to P (that is, Privacy) in the "privacy authorization policy."

[0098] The privacy information ID lists IDs assigned to the privacy information that is the target of access by the vehicle API function.

[0099] [4-5. Creating API Authorization Policy] As shown in FIG. 5, the API authorization policy 311 includes a static policy and a dynamic policy.

[0100] A static policy is generated by integrating multiple static perspective-based policies into one. That is, as shown in Figures 7 and 8, each static perspective-based policy is expressed in a matrix format, indicating whether or not a service application identified by an application ID has access permission to a vehicle API identified by an API-ID. Therefore, as shown in Figure 10, each square in the matrix representing the static policy indicates that access permission is granted if all of the multiple perspective-based policies to be integrated indicate that access permission is granted, and indicates that access permission is denied if any one of the policies indicates that access permission is denied.

[0101] A dynamic policy is generated by integrating multiple dynamic viewpoint-based policies into one. That is, as shown on the left side of Fig. 9, a dynamic viewpoint-based policy has information associated with each API-ID. Therefore, as shown on the right side of Fig. 9, the dynamic policy sets confirmation necessity information, authority type information, and confirmation information for each API-ID based on the multiple dynamic viewpoint-based policies to be integrated.

[0102] The confirmation necessity information is set to "necessary" if any one of the pieces of confirmation necessity information of the multiple viewpoint-specific policies to be integrated is necessary.

[0103] The authority type information is set to the same content as that set in the authority type information of the multiple viewpoint-specific policies to be integrated.

[0104] The confirmation information is set to content according to the setting of the authority type information. That is, if the authority type information is set to Financial, the billing contract content is set as the confirmation information, and if the authority type information is set to Privacy, the privacy information ID is set as the confirmation information.

[0105] 5 , the cloud server 200 distributes the API authorization policy generated by integrating the multiple 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 acquired from the cloud server 200 is stored in the information storage unit 31 of the API gateway 30 and used for access restriction processing.

[0107] [5. Processing] [5-1. Access restriction processing] The access control process executed by the access control unit 32 will be described with reference to the flowchart of FIG.

[0108] In S110, the access control unit 32 determines whether or not an API access request has been received from the service app, 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.

[0109] At S120, the access control unit 32 uses a static policy among the API authorization policies based on the information indicated in the API access request to determine whether the requesting application that is the requestor of the API access request has access permission. Specifically, the access control unit 32 first identifies an application ID from the process ID indicated in the API access request using the correspondence table 312. Next, the access control unit 32 refers to the static policy based on the identified application ID and the API-ID indicated in the API access request to determine whether the source application identified from the application ID has access permission to the destination API identified from the AP-ID.

[0110] In the following S130, if the access control unit 32 determines that the source application has access authority to the destination API, it proceeds to S140, and if it determines that the source application does not have access authority, it proceeds to S220.

[0111] In S140, the access control unit 32 determines whether dynamic authorization confirmation is required for access to the destination API by referring to the confirmation necessity information indicated in the dynamic policy. If the access control unit 32 determines that dynamic authorization confirmation is required, the process proceeds to S150, and if the access control unit 32 determines that dynamic authorization confirmation is not required, the process proceeds to S220.

[0112] In S150, the access control unit 32 refers to the authority confirmation type indicated in the dynamic policy, and if the indicated confirmation type is Financial, it proceeds to S160, and if the indicated confirmation type is Privacy, it proceeds to S180.

[0113] In S160, the access control unit 32 refers to the billing contract details indicated in the confirmation information of the dynamic policy, and acquires from the status monitoring unit 33 status information indicating the access status related to the billing contract details.

[0114] In the next step S170, the access control unit 32 determines whether the value indicated in the access status information is within the range of the billing contract content, and if it is within the range of the billing contract content, proceeds to step S210, and if it is outside the range of the billing contract content, proceeds to step S220.

[0115] In S180, the access control unit 32 determines whether the source application has access authority to the privacy information identified by the privacy information ID. This determination is made by referencing the user information 313 using the privacy information ID indicated in the confirmation information of the dynamic policy and the user ID of the vehicle user identified from the source application. If the access control unit 32 determines that the source application has access authority to the privacy information, the process proceeds to S190. If the access control unit 32 determines that the source application does not have access authority to the privacy information, the process proceeds to S220.

[0116] In S190, the access control unit 32 inquires of the vehicle user identified by the user ID whether or not the user agrees to access the privacy information. The inquiry is made by email or voice call to a contact registered in association with the user ID.

[0117] In the next step S200, the access control unit 32 determines whether or not the vehicle user's consent has been obtained as a result of the inquiry in step S190. If consent has been obtained, the process proceeds to step S210; if consent has not been obtained, the process proceeds to step S220.

[0118] In S210, the access control unit 32 permits access from the use-source application to the use-destination API, that is, transmits an API access request to the use-destination API, and then ends the process.

[0119] In S220, the access control unit 32 denies access from the source application to the destination API, that is, discards the API access request, and ends the process.

[0120] [5-2. Policy generation and provision process] The policy generation and provision process executed by the control unit 201 of the cloud server 200 will be described with reference to the flowchart of FIG.

[0121] In S310, the control unit 201 acquires viewpoint-specific policies that are individually generated for each viewpoint. The viewpoint-specific policies may be stored in the storage unit 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.

[0122] In the following S320, the control unit 201 integrates the multiple viewpoint-based policies acquired in S310 to generate an API authorization policy 311. Of the API authorization policies 311, a static policy is generated by integrating multiple static viewpoint-based policies as shown in Fig. 10, and a dynamic policy is generated by integrating multiple dynamic viewpoint policies as shown in Fig. 9.

[0123] In the following S330, the control unit 201 stores the API authorization policy 311 generated in S320 in the storage unit 202.

[0124] In the next step S340, if predetermined provision conditions are met, the control unit 201 transmits the API authorization policy 311 stored in the storage unit 202 to the in-vehicle system 100 to which the policy is to be provided, and then ends the process. The provision conditions may include the presence of a request from the in-vehicle system 100, the storage of a new viewpoint-specific policy in the storage unit 202, and the like.

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

[0126] (1) The API authorization policy 311, which is generated by the cloud server 200 (i.e., Out-Car) and integrates multiple viewpoint-specific policies, is distributed to the in-car system 100 (i.e., In-Car). By using the distributed API authorization policy 311, the in-car system 100 can easily determine whether the source application has access permission to the destination API without having to determine each viewpoint-specific policy individually. As a result, the load on the in-car system 100 required for the determination can be reduced.

[0127] (2) The API authorization policy 311 includes a dynamic policy for determining whether or not access is permitted based on information that changes dynamically depending on the situation and the user's intentions at any given time. Therefore, it is possible to flexibly respond to access restrictions that change depending on, for example, the contents of a billing contract or the user's attitude toward private information.

[0128] [7. Terminology] The API gateway 30 in this embodiment corresponds to the cooperation control unit in this disclosure. The multiple service applications belonging to the service function block groups 23 and 24, the control function block group 25, and the data function block group 26 in this disclosure correspond to the multiple function blocks in this disclosure. The information storage unit 31 in this embodiment corresponds to the policy storage unit in this disclosure. The API authorization policy in this embodiment corresponds to the authorization policy in this disclosure. The cloud server 200 in this embodiment corresponds to the authorization policy providing unit and the management server in this disclosure. The in-vehicle devices 2 to 5 in this embodiment correspond to the electronic control units in this disclosure. The storage unit 202 in this embodiment corresponds to the authorization policy storage unit in this disclosure. Steps S310 to S330 of the processing executed by the control unit 201 in this embodiment correspond to the authorization policy generating unit in this disclosure. Step S340 of the processing executed by the control unit 201 in this embodiment corresponds to the authorization policy providing unit in this disclosure.

[0129] [8. Technical Ideas Disclosed in This Specification] [Item 1] an in-vehicle system including a plurality of electronic control units mounted on a vehicle and connected to an in-vehicle network; an authorization policy providing unit provided outside the vehicle; Equipped with The in-vehicle system includes: a plurality of functional blocks, each of which is mounted on one of the plurality of electronic control devices and configured to execute a predetermined process; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to acquire and store an authorization policy that defines access rights between the functional blocks from the authorization policy providing unit; an access control unit configured, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, to determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and if it is determined that the access authority exists, to transmit the access request to the destination block; Equipped with The authorization policy providing unit and providing the in-vehicle system with a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies, the static viewpoint policy defining the access authority for each of a plurality of viewpoints focusing on static attributes of the functional block, as the authorization policy. Mobility service provision system.

[0130] [Item 2] The mobility service providing system according to item 1, one of the viewpoint-specific policies is based on the safety of the function provided by the functional block; Mobility service provision system.

[0131] [Item 3] The mobility service providing system according to item 1 or 2, One of the viewpoint-specific policies is based on the reliability of a provider of the function block. Mobility service provision system.

[0132] [Item 4] A mobility service providing system according to any one of items 1 to 3, The authorization policy includes, in addition to the static viewpoint policy, one or more dynamic viewpoint policies that define the access authority for each of one or more viewpoints focusing on dynamic attributes of the function block. Mobility service provision system.

[0133] [Item 5] Item 4. A mobility service providing system according to item 4, One of the dynamic viewpoint policies is based on the presence or absence of consent from the vehicle user. Mobility service provision system.

[0134] [Item 6] The mobility service providing system according to item 4 or 5, one of the dynamic viewpoint policies is an access status between the functional blocks as a viewpoint; Mobility service provision system.

[0135] [Item 7] A mobility service providing system according to any one of items 1 to 6, The authorization policy is generated from at least one of the viewpoints of safety, finance, operation, and privacy, which are classified as security protection assets. Mobility service provision system.

[0136] [Item 8] 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; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to store an authorization policy that defines access rights between the functional blocks; an access control unit (32) configured to, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and, if it is determined that the access authority exists, transmit the access request to the destination block; Equipped with the authorization policy includes a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies, the static viewpoint policy defining the access authority for each of a plurality of viewpoints focusing on static attributes of the functional block; In-vehicle systems.

[0137] [Item 9] A management server communicably connected to a vehicle having an in-vehicle system having a plurality of electronic control units connected to an in-vehicle network, an authorization policy storage unit that is mounted in any one of the plurality of electronic control devices and is configured to store an authorization policy that is referenced to control access authority from a source block that is one of a plurality of functional blocks configured to execute predetermined processing to a destination block that is another one of the plurality of functional blocks; an authorization policy generating unit configured to generate a static viewpoint policy by integrating a plurality of static viewpoint-specific policies, each of which defines the access authority for each of a plurality of viewpoints focusing on static attributes of the function block, and to store the static viewpoint policy in the authorization policy storage unit as the authorization policy; an authorization policy providing unit configured to provide the authorization policy stored in the authorization policy storage unit to the vehicle; Equipped with Management server.

[0138] [Item 10] Item 9. The management server according to item 9, The authorization policy generation unit is configured to generate a dynamic viewpoint policy by integrating a plurality of dynamic viewpoint policies, each of which defines the access authority for each of a plurality of viewpoints focusing on dynamic attributes of the functional block, and to store the dynamic viewpoint policy in the authorization policy storage unit as the authorization policy. Management server.

[0139] [Item 11] An access control method in which at least one of a plurality of electronic control devices connected to an in-vehicle network controls access between a plurality of function blocks, each of which is configured to execute a predetermined process, using an authorization policy that defines access rights between the function blocks, the method comprising: a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies, the static viewpoint policy defining the access authority for each of a plurality of viewpoints focusing on static attributes of the functional block, is used as the authorization policy; When an access request is received from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, the authorization policy is used to determine whether the source block has access authority to the destination block, and if it is determined that the access authority exists, the access request is transmitted to the destination block. Access control methods.

[0140] [Item 12] In order to realize an access control method that controls access between a plurality of functional blocks, each of which is mounted in one of a plurality of electronic control devices connected to an in-vehicle network and configured to execute a predetermined process, using an authorization policy that defines access rights between the functional blocks, a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies, the static viewpoint policy defining the access authority for each of a plurality of viewpoints focusing on static attributes of the functional block, is used as the authorization policy; A program for causing a computer to realize the function of, when an access request is received from a source block, which is one of the plurality of functional blocks, to a destination block, which is another of the plurality of functional blocks, determining whether the source block has access authority to the destination block in accordance with the authorization policy, and if it is determined that the access authority exists, transmitting the access request to the destination block.

[0141] In addition, in items 8 to 12, content equivalent to the description of items 2 to 7 may be added.

[0142] 9. 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.

[0143] (a) In the above-described embodiment, no example is given for the O attribute, but it is possible to use attribute-specific policies created with the same idea as for the S attribute. For example, in controlling an air conditioner, it is conceivable to set a policy so that the setting is not changed from AUTO to an uncomfortable setting. While the S attribute targets life-threatening events, the O attribute also targets comfort and convenience.

[0144] (b) In the above embodiment, the ECU 2 includes both the real-time processing unit 10 and the application processing unit 20, but may include only one of them.

[0145] (c) In the above embodiment, the ECU 2 includes the service function block groups 23 and 24, the control function block group 25, and the data function block group 26, but the other in-vehicle devices 3 to 5 may include at least some of the function block groups 23 to 26. Furthermore, the function block groups 23 to 26 may be centrally arranged in one of the in-vehicle devices 2 to 5, or may be distributed across multiple in-vehicle devices 2 to 5.

[0146] (d) The in-vehicle device and the method described herein may be implemented by a special-purpose computer configured by configuring a processor and memory programmed to execute one or more functions embodied in a computer program. Alternatively, the in-vehicle device and the method described herein may be implemented by a special-purpose computer configured by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the in-vehicle device and the method described herein may be implemented by one or more special-purpose computers configured by combining a processor and memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. Furthermore, the computer program may be stored on a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer. The method for implementing the functions of each unit included in the in-vehicle device does not necessarily need to include software; all of the functions may be implemented using one or more hardware components.

[0147] (e) 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.

[0148] (f) In addition to the above-mentioned mobility service providing system 1, the in-vehicle system 100, the cloud server 200 as the authorization policy providing unit and management server, the present disclosure can also be realized in various forms, such as a program for causing a computer to function as the in-vehicle system 100 and the authorization policy providing unit, a non-transient physical recording medium such as a semiconductor memory on which this program is recorded, an access control method, etc.

Claims

1. an in-vehicle system including a plurality of electronic control units mounted on a vehicle and connected to an in-vehicle network; an authorization policy providing unit provided outside the vehicle; Equipped with The in-vehicle system includes: a plurality of functional blocks, each of which is mounted on one of the plurality of electronic control devices and configured to execute a predetermined process; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to acquire and store an authorization policy that defines access rights between the functional blocks from the authorization policy providing unit; an access control unit configured to, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and if it is determined that the access authority exists, transmit the access request to the destination block; Equipped with The authorization policy providing unit and providing the in-vehicle system with a static viewpoint policy generated by integrating a plurality of viewpoint-specific policies that define the access authority for each of a plurality of viewpoints focusing on static attributes of the functional blocks, so that one access authority that satisfies the plurality of viewpoints is indicated for each combination of the source block and the destination block, as the authorization policy. Mobility service provision system.

2. an in-vehicle system including a plurality of electronic control units mounted on a vehicle and connected to an in-vehicle network; an authorization policy providing unit provided outside the vehicle; Equipped with The in-vehicle system includes: a plurality of functional blocks, each of which is mounted on one of the plurality of electronic control devices and configured to execute a predetermined process; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to acquire and store an authorization policy that defines access rights between the functional blocks from the authorization policy providing unit; an access control unit configured to, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and if it is determined that the access authority exists, transmit the access request to the destination block; Equipped with A viewpoint-specific policy is prepared for each of a plurality of viewpoints focusing on static attributes of the functional blocks, and the viewpoint-specific policy defines the access authority from the source block to the destination block for each combination of the source block and the destination block; The authorization policy providing unit and providing the in-vehicle system with a static viewpoint policy generated by integrating the access rights into one for each combination of the source block and the destination block for the plurality of viewpoint-specific policies as the authorization policy. Mobility service provision system.

3. 3. The mobility service providing system according to claim 1 or 2, one of the viewpoint-specific policies is based on the safety of the function provided by the functional block; Mobility service provision system.

4. 3. The mobility service providing system according to claim 1 or 2, One of the viewpoint-specific policies is based on the reliability of a provider of the function block. Mobility service provision system.

5. 3. The mobility service providing system according to claim 1 or 2, the authorization policy includes, in addition to the static viewpoint policy, one or more dynamic viewpoint policies that define the access authority for each of one or more viewpoints focusing on dynamic attributes of the function block; Mobility service provision system.

6. A mobility service providing system according to claim 5, One of the dynamic viewpoint policies is based on the presence or absence of consent from the vehicle user. Mobility service provision system.

7. A mobility service providing system according to claim 5, one of the dynamic viewpoint policies is an access status between the functional blocks as a viewpoint; Mobility service provision system.

8. 3. The mobility service providing system according to claim 1 or 2, The authorization policy is generated from at least one of the viewpoints of safety, finance, operation, and privacy, which are classified as security protection assets. Mobility service provision system.

9. 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; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to store an authorization policy that defines access rights between the functional blocks; an access control unit configured to, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and if it is determined that the access authority exists, transmit the access request to the destination block; Equipped with The authorization policy includes a static viewpoint policy that is generated by integrating a plurality of viewpoint-specific policies that define the access authority for each of a plurality of viewpoints focusing on static attributes of the functional blocks, so that one access authority that satisfies the plurality of viewpoints is indicated for each combination of the source block and the destination block. In-vehicle systems.

10. 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; a cooperation control unit configured to realize cooperation between the plurality of functional blocks; Equipped with The cooperation control unit a policy storage unit configured to store an authorization policy that defines access rights between the functional blocks; an access control unit configured to, when receiving an access request from a source block that is one of the plurality of functional blocks to a destination block that is another of the plurality of functional blocks, determine whether or not the source block has access authority to the destination block using the authorization policy stored in the policy storage unit, and if it is determined that the access authority exists, transmit the access request to the destination block; Equipped with A viewpoint-specific policy is prepared for each of a plurality of viewpoints focusing on static attributes of the functional blocks, and the viewpoint-specific policy defines the access authority from the source block to the destination block for each combination of the source block and the destination block; The authorization policy includes a static viewpoint policy that is generated by integrating the access rights for each combination of the source block and the destination block for the plurality of viewpoint-specific policies into one. In-vehicle systems.

11. A management server communicably connected to a vehicle having an in-vehicle system having a plurality of electronic control units connected to an in-vehicle network, an authorization policy storage unit that is mounted in any of the plurality of electronic control devices and is configured to store an authorization policy that is referenced to control access authority from a source block that is one of a plurality of functional blocks configured to execute predetermined processes to a destination block that is another one of the plurality of functional blocks; an authorization policy generating unit configured to generate a static viewpoint policy by integrating a plurality of static viewpoint policies that define the access authority for each of a plurality of viewpoints focusing on static attributes of the functional blocks, so that one access authority that satisfies the plurality of viewpoints is indicated for each combination of the source block and the destination block, and to store the static viewpoint policy in the authorization policy storage unit as the authorization policy; an authorization policy providing unit configured to provide the authorization policy stored in the authorization policy storage unit to the vehicle; Equipped with Management server.

12. A management server communicably connected to a vehicle having an in-vehicle system having a plurality of electronic control units connected to an in-vehicle network, an authorization policy storage unit that is mounted in any of the plurality of electronic control devices and is configured to store an authorization policy that is referenced to control access authority from a source block that is one of a plurality of functional blocks configured to execute predetermined processes to a destination block that is another one of the plurality of functional blocks; an authorization policy generating unit configured to prepare a viewpoint-specific policy for each of a plurality of viewpoints focusing on static attributes of the functional blocks, the viewpoint-specific policy defining the access authority from the source block to the destination block for each combination of the source block and the destination block, integrate the access authorities for the plurality of viewpoint-specific policies into one for each combination of the source block and the destination block to generate a static viewpoint policy, and store the static viewpoint policy in the authorization policy storage unit as the authorization policy; an authorization policy providing unit configured to provide the authorization policy stored in the authorization policy storage unit to the vehicle; Equipped with Management server.

13. The management server according to claim 11 or claim 12, The authorization policy generation unit is configured to generate a dynamic viewpoint policy by integrating a plurality of dynamic viewpoint policies, each of which defines the access authority for each of a plurality of viewpoints focusing on dynamic attributes of the functional block, and to store the dynamic viewpoint policy in the authorization policy storage unit as the authorization policy. Management server.

14. An access control method in which at least one of a plurality of electronic control devices connected to an in-vehicle network controls access between a plurality of function blocks, each of which is configured to execute a predetermined process, using an authorization policy that defines access rights between the function blocks, the method comprising: a static viewpoint policy is used as the authorization policy, which is generated by integrating a plurality of viewpoint-specific policies that define the access authority for each of a plurality of viewpoints focusing on static attributes of the functional blocks, so that one access authority that satisfies the plurality of viewpoints is indicated for each combination of a source block that is one of the plurality of functional blocks and a destination block that is another of the plurality of functional blocks; When an access request to the destination block is received from the source block, the presence or absence of access authority of the source block to the destination block is determined in accordance with the authorization policy, and if it is determined that the access authority exists, the access request is transmitted to the destination block. Access control methods.

15. An access control method in which at least one of a plurality of electronic control devices connected to an in-vehicle network controls access between a plurality of function blocks, each of which is configured to execute a predetermined process, using an authorization policy that defines access rights between the function blocks, the method comprising: A viewpoint-specific policy is prepared for each of a plurality of viewpoints focusing on static attributes of the functional blocks, and the viewpoint-specific policy specifies the access authority from the source block to the destination block for each combination of a source block that is one of the plurality of functional blocks and a destination block that is another of the plurality of functional blocks, and a static viewpoint policy generated by integrating the access authorities for each combination of the source block and the destination block for the plurality of viewpoint-specific policies into one is used as the authorization policy, When an access request to the destination block is received from the source block, the presence or absence of access authority of the source block to the destination block is determined in accordance with the authorization policy, and if it is determined that the access authority exists, the access request is transmitted to the destination block. Access control methods.

16. In order to realize an access control method that controls access between a plurality of functional blocks, each of which is mounted in one of a plurality of electronic control devices connected to an in-vehicle network and configured to execute a predetermined process, using an authorization policy that defines access rights between the functional blocks, a static viewpoint policy is used as the authorization policy, which is generated by integrating a plurality of viewpoint-specific policies that define the access authority for each of a plurality of viewpoints focusing on static attributes of the functional blocks, so that one access authority that satisfies the plurality of viewpoints is indicated for each combination of a source block that is one of the plurality of functional blocks and a destination block that is another of the plurality of functional blocks; A program for causing a computer to realize the function of, when an access request to the destination block is received from the source block, determining whether the source block has access authority to the destination block in accordance with the authorization policy, and if it is determined that the access authority exists, transmitting the access request to the destination block.

17. In order to realize an access control method that controls access between a plurality of functional blocks, each of which is mounted in one of a plurality of electronic control devices connected to an in-vehicle network and configured to execute a predetermined process, using an authorization policy that defines access rights between the functional blocks, A viewpoint-specific policy is prepared for each of a plurality of viewpoints focusing on static attributes of the functional blocks, and the viewpoint-specific policy specifies the access authority from the source block to the destination block for each combination of a source block that is one of the plurality of functional blocks and a destination block that is another of the plurality of functional blocks, and a static viewpoint policy generated by integrating the access authorities for each combination of the source block and the destination block for the plurality of viewpoint-specific policies into one is used as the authorization policy, A program for causing a computer to realize the function of, when an access request to the destination block is received from the source block, determining whether the source block has access authority to the destination block in accordance with the authorization policy, and if it is determined that the access authority exists, transmitting the access request to the destination block.

Images