Access control device and access control method

Abstract

When the access control unit (10) determines that acceptance is possible by the acceptance determination units (211, 212), the access control unit (10) assigns access to the vehicle API that provides the function of the start confirmation unit (222) to the API utilization application (30). When the start intention of the user is confirmed by the start confirmation unit, the access control unit gives access to the vehicle API necessary for providing the target service to the API use application.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This international application claims the priority of Japanese Patent Application No. 2022-156690 filed with the Japan Patent Office on September 29, 2022, the entire contents of which are hereby incorporated by reference. Technical Field

[0003] The present disclosure relates to a technology for providing a service utilizing a vehicle function. Background Art

[0004] Patent Document 1 describes a system including a driving assistance device and an in-vehicle terminal, in which a plurality of vehicles perform platoon driving according to a plan generated by the driving assistance device.

[0005] In the platooning system, the onboard device repeatedly transmits vehicle position information and scheduled travel route information to the central device. The central device generates information for platooning based on information collected from multiple vehicles and transmits it to each vehicle constituting the platoon.

[0006] Patent Document 1: Japanese Patent Application Publication No. 2018-181142

[0007] However, in the case of a platoon of vehicles configured to provide information and functions possessed by the vehicle via an API (hereinafter referred to as a vehicle API), it is necessary to allow access to the vehicle API from an external device (e.g., a center device or another vehicle). However, it is necessary to suppress leakage of personal information unrelated to the provision of services or improper vehicle control not intended by the user due to such access to the vehicle API from an external device. Summary of the invention

[0008] One aspect of the present disclosure is to provide a technique for appropriately limiting access to a vehicle API from outside the vehicle.

[0009] One method of the present disclosure is an access control device, which includes an access control unit, an acceptance determination unit, and a start confirmation unit. The access restriction unit is configured to accept an access request from an API utilization application provided outside the vehicle, and control access to the vehicle API. The vehicle API is an interface for providing vehicle functions possessed by the vehicle. The API utilization application is an application program that implements a service that utilizes the vehicle API. The acceptance determination unit is configured to provide a function of determining whether the vehicle can accept a service based on the API utilization application, that is, an object service, via the vehicle API. The start confirmation unit is configured to provide a function of confirming to a user of the vehicle via the vehicle API whether to start providing the object service.

[0010] The access control unit includes a first granting unit and a second granting unit. The first granting unit is configured to grant the API use application access to the vehicle API that provides the function of the start confirmation unit when the acceptance determination unit determines that the API use application can be accepted. The second granting unit is configured to grant the API use application access to the vehicle API required for providing the target service when the start confirmation unit confirms the user's start intention.

[0011] According to such a configuration, access to the vehicle API from outside the vehicle can be appropriately restricted.

[0012] One method of the present disclosure is an access control method for accepting an access request from a service provider that provides an API utilization service provided outside a vehicle and controlling access to a vehicle API. The vehicle API is an interface for providing vehicle functions that a vehicle has. An API utilization application is an application program that implements a service that utilizes the vehicle API.

[0013] The acceptance determination unit is configured to provide a function of determining whether the vehicle can accept a service based on an API utilization application, that is, an object service, through the vehicle API. When the acceptance determination unit determines that the service can be accepted, the service provider is granted access to the vehicle API for the function of the provision start confirmation unit. The start confirmation unit is configured to provide a function of confirming whether to start provision of the object service to a user of the vehicle through the vehicle API. When the start confirmation unit confirms the user's intention to start, the API utilization application is granted access to the vehicle API required for provision of the object service.

[0014] According to such a method, access to the vehicle API from outside the vehicle can be appropriately restricted. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0016] Figure 2 This is a block diagram showing the functional configuration of the in-vehicle system.

[0017] Figure 3 This is a flowchart showing the processing contents in the authenticator assigning unit.

[0018] Figure 4 This is a flowchart showing the processing contents in the access restriction unit.

[0019] Figure 5 This is a timing chart showing a typical operation example of the vehicle-mounted system.

[0020] Figure 6 This is a timing chart showing a typical operation example of the vehicle-mounted system.

[0021] Figure 7 This is a timing chart showing a typical operation example of the vehicle-mounted system.

[0022] Figure 8 This is a block diagram showing a functional configuration when the API utilization service is a platoon driving service.

[0023] Fig. 9 This is a block diagram showing the functional configuration when the API utilization service is an AVP service.

[0024] Fig.10 This is a sequence diagram showing an example of the operation of the AVP service. DETAILED DESCRIPTION

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

[0026] [1. Composition]

[0027] like Figure 1 As shown, the mobility service providing system 1 of the present embodiment includes an in-vehicle system 100 mounted on a vehicle, an automatic parking (hereinafter referred to as AVP) infrastructure 200 , another vehicle 300 , and a user terminal 400 .

[0028] The vehicle equipped with the vehicle-mounted system 100 may also have an automatic driving function in addition to a manual driving function. The vehicle may also be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function and a hybrid vehicle, and may also 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, the vehicle equipped with the vehicle-mounted system 100 is simply referred to as a vehicle.

[0029] 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 of Electronic Control Unit.

[0030] The ECU 2 realizes coordinated control of the entire vehicle by managing the plurality of ECUs 3. The ECU 2 is connected to an in-vehicle communication network 6 that connects the plurality of ECUs 3, and relays data frames communicated from the ECUs 3 and the in-vehicle communication device 5.

[0031] ECU3 is set up in each domain divided according to the functions in the vehicle, and mainly performs the control of multiple ECU4 existing in the domain. Each ECU3 is connected to the subordinate ECU4 via a lower layer network (for example, CAN) that is independently set up. CAN is the abbreviation of Controller Area Network, which is a registered trademark. ECU3 has the function of centrally managing the access rights to the subordinate ECU4 and authenticating the user. Domains are, for example, powertrain, body, chassis, and cockpit.

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

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

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

[0035] The ECU 4 connected to the ECU 3 belonging to the cockpit domain includes, for example, an ECU 4 for controlling the display of instruments and navigation, and an ECU 4 for controlling the vehicle HMI operated by the vehicle user (hereinafter referred to as the user). HMI is an abbreviation of Human Machine Interface.

[0036] The vehicle-external communication device 5 performs data communication within a relatively narrow range (e.g., within tens of meters) on a point-to-point basis with an external device (i.e., AVP infrastructure 200 or other vehicle 300) that provides API utilization services. The API utilization services will be described later. In addition, the vehicle-external communication device 5 performs data communication with a user terminal 400 held by a user via a wide area wireless communication network.

[0037] The in-vehicle communication network 6 includes, for example, CAN FD and Ethernet. Ethernet is a registered trademark. CAN FD is an abbreviation of CAN with Flexible Data Rate. CAN FD connects the ECU 2 with each ECU 3 and the in-vehicle communication device 5 by bus. Ethernet connects the ECU 2 with each ECU 3 and the in-vehicle communication device 5 independently.

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

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

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

[0041] The AVP infrastructure 200 is an infrastructure installed in a parking lot that provides an AVP service. The AVP service is a service in which a vehicle automatically drives and automatically parks in an empty parking space in a large-scale unmanned parking lot or the like.

[0042] The AVP infrastructure 200 includes a communication unit 201 , an HMI unit 202 , and a control unit 203 .

[0043] The communication unit 201 performs data communication within a relatively narrow range on a point-to-point basis with the in-vehicle system 100 .

[0044] The HMI unit 202 is used to input information and commands required for providing the AVP service. The HMI unit 202 may be configured to input information and commands via the user terminal 400 .

[0045] The control unit 203 is constructed with a microcomputer having a CPU, ROM, and RAM as the center. A service application (hereinafter referred to as a service application) that implements the AVP service is installed in the control unit 203. The service application that implements the AVP service accesses the vehicle API of the vehicle-mounted system 100 via the communication unit 201, and performs vehicle control such as sending and receiving information required for starting the AVP service, steering manipulation, acceleration and deceleration of the vehicle equipped with the vehicle-mounted system 100, etc. Through this vehicle control, the vehicle can enter and exit the warehouse based on automatic driving. API is the abbreviation of Application Programming Interface.

[0046] The vehicle API is used to access functions provided by the vehicle and is standardized as an interface that is not dependent on a specific vehicle model or a specific level. In other words, the vehicle API is structured so that even engineers who are not familiar with the characteristics and limitations of the vehicle can easily develop service applications that utilize the vehicle API.

[0047] The other vehicles 300 are provided with the same vehicle-mounted system as the above-mentioned vehicle-mounted system 100. A service application that implements the platoon driving service is installed in the vehicle-mounted system of the other vehicles 300. The service application installed in the vehicle that becomes the front vehicle of the platoon among the vehicles utilizing the platoon driving service accesses the vehicle API possessed by the vehicle-mounted system 100 of the vehicle that becomes the subsequent vehicle in the platoon. By accessing the vehicle API, the service application of the front vehicle sends and receives the information required for starting the platoon driving service, and performs vehicle control such as steering manipulation and acceleration and deceleration of the subsequent vehicles in a manner to maintain the platoon. Through this vehicle control, platoon driving based on automatic driving is realized.

[0048] The user terminal 400 is, for example, a mobile terminal such as a smartphone or a tablet computer.

[0049] [2. Functional structure]

[0050] The functional configuration of the in-vehicle system 100 will be described.

[0051] like Figure 2 As shown, the vehicle system 100 includes an access control unit 10, a vehicle function unit 20, and a vehicle API unit 50. The access control unit 10 and the vehicle function unit 20 may be disposed in any of the vehicle-mounted devices 2 to 5. For example, the access control unit 10, the vehicle function unit 20, and the vehicle API unit 50 are disposed in the ECU 2.

[0052] [2-1. Vehicle Function Section]

[0053] The vehicle function unit 20 is a collection of modules that subdivide the functions of the vehicle. Each module belonging to the vehicle function unit 20 is installed in any of the vehicle-mounted devices 2 to 5 .

[0054] There are multiple partitions in the module belonging to the vehicle function unit 20, and different access restrictions are set for each partition. The vehicle API with access restrictions accepts and executes the API access request only when the API access request is accompanied by an authenticator associated with the partition to which it belongs.

[0055] The vehicle function unit 20 has four partitions corresponding to the four attributes F, S, O, and P defined as security assets, and one partition without access restrictions. F is the abbreviation of Financial, S is the abbreviation of Safety, O is the abbreviation of Operational, and P is the abbreviation of Privacy.

[0056] The vehicle function unit 20 includes an N-type function block group 21, an O-type function block group 22, a P-type function block group 23, an S-type function block group 24, and an F-type function block group 25 corresponding to each partition. The vehicle function unit 20 also includes a vehicle state database (hereinafter referred to as vehicle state DB) 26.

[0057] The N-series function block group 21 is a collection of modules that provide functions that do not require access to vehicle functions or vehicle information. The O-series function block group 22 is a collection of modules that provide functions related to the operational performance of the vehicle. The P-series function block group 23 is a collection of modules that provide functions related to the privacy information of users stored in the vehicle. The S-series function block group 24 is a collection of modules that provide functions related to security. The F-series function block group 25 is a collection of modules that provide functions related to the property of an enterprise or an individual.

[0058] The vehicle status DB 26 stores vehicle status data indicating the status of the vehicle. The vehicle status data stored in the vehicle status DB 26 is updated successively. The vehicle status data at least includes the position and driving speed of the vehicle. The vehicle status data may also include the operating status of the vehicle, the operating status of the vehicle-mounted equipment, and the detection results of various monitoring sensors that monitor the surroundings of the vehicle and the inside of the vehicle.

[0059] The vehicle API unit 50 is a set of vehicle APIs prepared to access functions provided by the vehicle, that is, modules belonging to the vehicle function unit 20. The vehicle API unit 50 includes an N-series API group 51, an O-series API group 52, a P-series API group 53, an S-series API group 54, and an F-series API group 55.

[0060] The N-type API group 51 is a collection of vehicle APIs (hereinafter referred to as N-type APIs) for accessing each module belonging to the N-type functional block group 21. The N-type API has no access restrictions and accepts access requests even if no authenticator is attached to the access request.

[0061] like Figure 5 as well as Fig.10As shown, the N-series function block group 21 may include, for example, an acceptance determination module 211, a reliability confirmation module 212, and an end determination module 213. The acceptance determination module 211 provides a function of determining whether the vehicle is in a state where it can accept the service provided by the API utilization application, and provides it to the source of the API utilization application. The reliability confirmation module 212 provides a function of determining the reliability of the service provider based on the reliability information provided from the API utilization application, and notifying the access control unit 10 of the determination result. The end determination module 213 provides a function of determining whether the condition for terminating the object service is met, and if so, notifying the access control unit 10 of the subject matter. The O-series API group 52 is a collection of vehicle APIs (hereinafter referred to as O-series APIs) for accessing each module belonging to the O-series function block group 22. The O-series API accepts an access request when an O-series authenticator is attached to the access request.

[0062] The O-series functional block group 22 may include, for example, a provision confirmation module 221 and a start confirmation module 222. The provision confirmation module 221 provides a function of confirming whether there is an intention to receive the provision of the service using the vehicle-mounted HMI of the vehicle. The start confirmation module 222 provides a function of confirming whether the provision of the service can be started using the vehicle-mounted HMI of the vehicle.

[0063] The P-type API group 53 is a collection of vehicle APIs (hereinafter referred to as P-type APIs) for accessing each module belonging to the P-type functional block group 23. The P-type API accepts an access request when a P-type authenticator is attached to the access request.

[0064] The P-series functional block group 23 may include, for example, an information providing module 231 and a getting-off confirmation module 232. The information providing module 231 provides a function of reading out the private information stored in the vehicle. The private information may include route information to the destination set by the user, parking lot reservation information, etc. The getting-off confirmation module 232 provides a function of accessing the private information stored in the vehicle (for example, an image of the interior of the vehicle) and notifying the information obtained from the image (for example, the presence or absence of passengers).

[0065] The S-type API group 54 is a vehicle API (hereinafter referred to as S-type API) for accessing each module belonging to the S-type functional block group 24. The S-type API accepts an access request when an S-type authenticator is attached to the access request.

[0066] The S-type functional block group 23 may include, for example, a vehicle control module 241. The vehicle control module 241 provides a vehicle control function for changing the behavior of the vehicle such as steering, acceleration, and deceleration, and includes different modules depending on the type of vehicle control.

[0067] The F-type API group 55 is a collection of vehicle APIs (hereinafter referred to as F-type APIs) for accessing each module belonging to the F-type functional block group 25. The F-type API accepts an access request when an F-type authenticator is attached to the access request.

[0068] The F-series functional block group 25 may include, for example, an actuarial module 251. The actuarial module 251 provides a function of performing an actuarial calculation of costs related to the provided services.

[0069] [2-2. API Utilization Application]

[0070] The service application 30 that realizes a desired function using the vehicle API is referred to as an API utilization application. The API utilization application realizes a service using vehicle information and vehicle functions by accessing the vehicle API.

[0071] The API utilization application may be installed in the vehicle-mounted system 100 , but here, the case where it is installed in an external device such as the AVP infrastructure 200 or another vehicle 300 will be described.

[0072] API utilization applications can be provided by OEMs or third parties.

[0073] OEM is a vehicle manufacturer that manufactures vehicles. OEM is the abbreviation of Original Equipment Manufacturer. In addition, OEM applications may also include applications developed by the OEM itself and applications developed by other suppliers.

[0074] A third party is the owner of the vehicle and a third party other than the OEM.

[0075] The services provided by the application through the API include, for example, a platoon driving service for realizing platoon driving based on autonomous driving, an AVP service for realizing AVP based on autonomous driving, etc. In addition, in the case of the platoon driving service, the other vehicles 300 traveling at the front of the platoon are equivalent to the external device in the present disclosure. In the case of the AVP service, the AVP infrastructure 200 set in the parking lot is equivalent to the external device in the present disclosure.

[0076] When the API utilization application utilizes the function provided by the vehicle function unit 20, it sends an API access request, which is an access request to the vehicle API belonging to the vehicle API unit 50. The API access request includes at least information identifying a service application that is a utilization source (hereinafter referred to as a utilization source application) and information identifying a vehicle API that is a utilization destination (hereinafter referred to as a utilization destination API). The API access request may also be assigned an authenticator indicating that the user has access rights to a specific API.

[0077] The API access request is transferred to the vehicle API unit 50 via the access control unit 10 , and is further transferred from the vehicle API unit 50 to the vehicle function unit 20 .

[0078] [2-3. Access Control Section]

[0079] The access control unit 10 has a function of controlling access to a vehicle API provided by each module belonging to the vehicle function unit 20 .

[0080] The access control unit 10 includes an authenticator assigning unit 11 , an access restriction unit 12 , and an access management database (hereinafter referred to as access management DB) 13 .

[0081] The authenticator granting unit 11 performs processing for granting the authenticator prepared for each partition to the API using application. Hereinafter, the API using application using the vehicle API of the own vehicle is referred to as the target application 30. There may be a plurality of target applications 30. In addition, the service provided by the target application 30 is referred to as the target service.

[0082] use Figure 3 The flowchart shown in the figure explains the authenticator granting process executed by the authenticator granting unit 11. The authenticator granting process is independently executed for each API using application.

[0083] When the authenticator granting unit 11 starts the authenticator granting process, it determines in S110 whether the vehicle is in a state where the target service can be accepted. This determination is made using the acceptance determination module 211 belonging to the N-series functional block group 21. The acceptance determination module 211 is pre-installed in the vehicle-mounted system 100 of the vehicle, for example, when the target service is used. When the vehicle is in a state where the target service can be accepted, the acceptance determination module 211 notifies the authenticator granting unit 11 of the fact.

[0084] The acceptance determination module 211 receives reliability information from an external device that is a source of target service provision, and determines whether the service provision is from a service provision source desired by the driver based on the provided reliability information.

[0085] When the target service is platooning, the front vehicle of the platoon becomes the service provider, and the position and driving speed of the front vehicle are used as reliability information. In addition, when the target service is automatic parking, the infrastructure that provides the automatic parking service becomes the service provider, and the position and name of the infrastructure are used as reliability information. Moreover, the acceptance determination module 211 determines whether the vehicle is in a position where it can accept the provision of the service by comparing the reliability information provided by the service provider with the position, driving speed and map information of the vehicle stored in the vehicle status DB 26. In addition, the position where the service can be accepted can be, for example, a position where the driver of the vehicle can visually confirm the vehicle or infrastructure that is the service provider.

[0086] If the authenticator granting unit 11 receives the notification from the admission determination module 211, it determines that the service can be accepted and moves the process to S120. If the authenticator granting unit 11 does not receive the notification from the admission determination module 211, it determines that the service cannot be accepted and waits by repeating this step.

[0087] In S120 , the authenticator assigning unit 11 transmits an acceptance notification to the target application 30 installed in the external device.

[0088] Then, in S130, the authenticator assigning unit 11 determines whether the target service has ended. For this determination, when a payment completion notification indicating the completion of the actuarial processing is received from the actuarial module 251, it is determined that the service has ended. In addition, when the actuarial processing is omitted, the authenticator assigning unit 11 may also use the completion determination module 213 belonging to the N-series functional block group 21 to make a determination. The completion determination module 213 is the same as the acceptance determination module 211, and is pre-installed in the vehicle-mounted system 100 of this vehicle when the target service is utilized. When the completion condition for the completion of the service is met, the completion determination module 213 notifies the authenticator assigning unit 11 of the subject matter. The completion determination module 213 may, for example, determine whether the completion condition is met based on the vehicle status data stored in the vehicle status DB26. The authenticator assigning unit 11 may also determine that the service has ended when a notification from the completion determination module 213 is received.

[0089] When the authenticator assigning unit 11 determines that the service has been terminated, the process proceeds to S140 , and when it determines that the service has not been terminated, the process proceeds to S150 .

[0090] In S140 , the authenticator assigning unit 11 invalidates the authenticator assigned to the target application 30 in S160 , S180 , S200 , and S220 described later, and terminates the process.

[0091] In S150 , the authenticator assigning unit 11 determines whether the O-system open condition for permitting access to the O-system API is satisfied, and if so, the process proceeds to S160 ; if not, the process proceeds to S170 .

[0092] In S160 , the authenticator assigning unit 11 assigns the O-based authenticator to the target application 30 installed in the external device, and returns the process to S130 .

[0093] In S170 , the authenticator assigning unit 11 determines whether the P-system open condition for permitting access to the P-system API is satisfied, and if so, the process proceeds to S180 ; if not, the process proceeds to S190 .

[0094] In S180 , the authenticator assigning unit 11 assigns the P-based authenticator to the target application 30 installed in the external device, and returns the process to S130 .

[0095] In S190 , the authenticator granting unit 11 determines whether an S-system open condition for permitting access to the S-system API is satisfied, and if so, the process proceeds to S200 ; if not, the process proceeds to S210 .

[0096] In S200 , the authenticator assigning unit 11 assigns the S-series authenticator to the target application 30 installed in the external device, and returns the process to S130 .

[0097] In S210 , the authenticator granting unit 11 determines whether the F-system open condition for permitting access to the F-system API is satisfied, and if so, the process proceeds to S220 ; if not, the process returns to S130 .

[0098] In S220 , the authenticator assigning unit 11 assigns the F-based authenticator to the target application 30 installed in the external device, and returns the process to S130 .

[0099] The open conditions used in S150, S170, S190, and S210 may include, for example, that the result of the processing executed according to the API access request from the target application 30 is a specified content. In addition, the open conditions may also include the authenticator of another partition that has been assigned to the target application 30. In other words, the order of assigning the authenticator to each partition may be controlled according to the setting method of the open conditions.

[0100] The access restriction unit 12 classifies the authenticators given to the target application 30 in S160, S180, S200, and S220 into the O, P, S, and F partitions and stores them in the access management DB 13. The access restriction unit 12 invalidates the authenticators performed in S140 by deleting the authenticators stored in the access management DB 13.

[0101] The access restriction unit 12 executes access restriction processing for accepting an API access request from the target application 30 (ie, an external device) and determining whether to permit access to the API of the vehicle serving as the access destination.

[0102] Next, use Figure 4 The flowchart shown explains the access restriction process executed by the access restriction unit 12. The access control process is executed commonly for all API-using applications.

[0103] When the access restriction unit 12 starts the access restriction process, it determines in S310 whether an API access request is received from the target application 30 installed in the external device. If it is determined that an API access request is received, the access restriction unit 12 moves the process to S320, and if it is determined that no API access request is received, it waits by repeating this step.

[0104] In S320 , the access restriction unit 12 determines whether the destination API indicated by the API access request is an N-series API without access restriction, and moves the process to S350 if it is an N-series API, and moves the process to S330 if it is not an N-series API.

[0105] In S330 , the access restriction unit 12 determines whether an authenticator is attached to the API access request, and if an authenticator is attached, the process proceeds to S340 , and if no authenticator is attached, the process proceeds to S360 .

[0106] In S340, the access restriction unit 12 determines whether the authenticator attached to the API access request matches the destination API, and if so, the process moves to S350, and if not, the process moves to S360. Specifically, for example, when the destination API is an O-series API, if the authenticator attached to the API access request matches the O-series authenticator stored in the access management DB 13, it can be determined that the API matches.

[0107] In S350 , the access restriction unit 12 regards that the target application 30 has access rights to the utilization destination API, transfers the API access request to the utilization destination API, and terminates the process.

[0108] In S360, the access restriction unit 12 considers that the target application 30 does not have access rights to the destination API, abandons the API access request, and ends the process. At this time, the target application 30 of the utilization source may be notified that the API access request has been abandoned.

[0109] [3. Action Example]

[0110] [3-1. Representative action examples]

[0111] use Figures 5 to 7 The following is a timing diagram of a typical operation example. Figures 5 to 7 In order to make the drawings easier to see, the description of API groups 51 to 55 is omitted. This is because the N-series API group 51 and the N-series function block group 21, the O-series API group 52 and the O-series function block group 22, the P-series API group 53 and the P-series function block group 23, the S-series API group 54 and the S-series function block group 24, and the F-series API group 55 and the F-series function block group 25 are respectively established in a one-to-one correspondence relationship.

[0112] If the vehicle equipped with the vehicle system 100 (hereinafter referred to as the vehicle itself) is started, the vehicle system 100 determines whether the vehicle is in a state where it can accept the target service through the acceptance determination module 211. Figure 5 As shown, the in-vehicle system 100 transmits a result notification M1 indicating the determination result in the admission determination module 211 to the target application 30 installed in the external device.

[0113] The target application 30 that has received the result notification M1 indicating that the service can be accepted sends an API access request M2 to the reliability confirmation module 212. The API access request M2 includes reliability information related to the reliability of the service.

[0114] The access control unit 10 that has received the API access request M2 confirms the destination API indicated by the API access request M2. Here, since it is an access request to the N-series API (i.e., a positive determination is made in S320), the access control unit 10 forwards the API access request M2 to the destination API. The destination API operates the reliability confirmation module 212 as the destination module based on the forwarded API access request M2.

[0115] The reliability confirmation module 212 that has received the transfer of the API access request M2 notifies the access control unit 10 of a reliability notification M3 indicating a result of determining the reliability of the target service based on the reliability information attached to the API access request M2 .

[0116] When the access control unit 10 receives the reliability notification M3 and determines that the target service is sufficiently reliable, it sets the O-series open condition to be satisfied (i.e., makes an affirmative determination in S150), and sends an access permission notification M4 to which the O-series authenticator is attached to the target application 30. For example, the access control unit 10 may determine that the target service in the reliability notification M3 is sufficiently reliable when the reliability of the target service is equal to or greater than a predetermined threshold.

[0117] In addition, when the access control unit 10 receives the reliability notification M3 and determines that the target service is unreliable, Figure 6 As shown, an access denial notification M5 indicating that granting of access rights to the O-based API is denied is sent to the target application 30 .

[0118] Return to Figure 5 The target application 30 that has received the access permission notification M4 sends an API access request M6 to the provision confirmation module 221. The API access request M6 is attached with the O-based authenticator obtained from the access permission notification M4. The provision confirmation module 221 provides a function of confirming the user's intention to provide the target service via the in-vehicle HMI.

[0119] The access control unit 10 that has received the API access request M6 confirms the destination API and the like indicated in the API access request M6. Here, the request is for access to the O-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M6 to the destination API. The destination API causes the provision confirmation module 221, which is the destination module, to operate based on the forwarded API access request M6.

[0120] The provision confirmation module 221 that has operated in response to the API access request M6 sends a provision confirmation request M7 to the ECU that controls the vehicle-mounted HMI.

[0121] The ECU that has received the provision confirmation request M7 displays, via the in-vehicle HMI, a message urging the user to confirm whether provision of the target service is desired. If input is made from the user, a user response M8 indicating the input content is returned to the provision confirmation module 221 .

[0122] The provision confirmation module 221 that has received the user response M8 transmits a provision confirmation notification M9 indicating the user's intention indicated by the user response M8 to the access control unit 10 .

[0123] The access control unit 10 that has received the provision confirmation notification M9 considers that the P-series open condition is satisfied (i.e., makes an affirmative determination in S170) when the provision confirmation notification M9 indicates that the provision of the target service is desired, and sends the access permission notification M10 to the target application 30 with the P-series authenticator attached. In addition, if the provision confirmation notification M9 indicates that the provision of the target service is not desired, the access control unit 10 Figure 7 As shown, an access denial notification M11 indicating that granting of access rights to the P-based API is denied is transmitted to the target application 30 .

[0124] Back to Figure 5 The target application 30 that has received the access permission notification M10 sends an API access request M12 to the information providing module 231. The API access request M12 is attached with the P-based authenticator obtained through the access permission notification M10.

[0125] The access control unit 10 that has received the API access request confirms the destination API and the like indicated in the API access request M12. Here, the request is for access to the P-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M12 to the destination API. The destination API operates the information providing module 231 as the destination module based on the forwarded API access request M12.

[0126] The information providing module 231 that operates according to the API access request M12 acquires the privacy information indicated by the API access request M12 and sends the acquired privacy information to the target application 30 through the information providing notification M13.

[0127] The target application 30 receiving the information provision notification M13 sends an API access request M14 to the start confirmation module 222. The API access request M14 is attached with the O-based authenticator obtained by the access permission notification M4. The start confirmation module 222 provides a function of confirming the user's intention to start the target service via the in-vehicle HMI.

[0128] The access control unit 10 that has received the API access request M14 confirms the destination API and the like indicated by the API access request M14. Here, the request is for access to the O-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M14 to the destination API. The destination API causes the start confirmation module 222, which is the destination module, to operate based on the forwarded API access request M14.

[0129] The start confirmation module 222 that has operated in response to the API access request M14 sends a start confirmation request M15 to the ECU that controls the vehicle-mounted HMI.

[0130] The ECU that has received the start confirmation request M15 displays a message through the in-vehicle MHI prompting the user to confirm whether or not to start the target service. If the user inputs, the ECU returns a user response M16 indicating the input content to the start confirmation module 222 .

[0131] The start confirmation module 222 that has received the user response M16 transmits a start necessity notification M17 indicating the user's intention indicated by the user response M16 to the access control unit 10 .

[0132] The access control unit 10 that has received the start necessity notification M17 considers that the S-series open condition is satisfied (i.e., makes an affirmative determination in S190) when the start necessity notification M17 indicates that the start of the target service is desired, and sends an access permission notification M18 to which the S-series authenticator is attached to the target application 30. In addition, when the start necessity notification M17 indicates that the start of the target service is not desired, the access control unit 10 sends an access rejection notification indicating that the granting of access rights to the S-series API is rejected to the target application 30, although not shown in the figure.

[0133] The target application 30 that has received the access permission notification M18 transmits an API access request M19 to the vehicle control module 241. The S-series authenticator acquired from the access permission notification M18 is attached to the API access request M19.

[0134] The access control unit 10 that has received the API access request M19 confirms the destination API etc. indicated in the API access request M19. Here, it is an access request to the S-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M19 to the destination API. The destination API operates the vehicle control module 241 as the destination module according to the forwarded API access request M19.

[0135] The vehicle control module 241 that operates according to the API access request M19 executes the vehicle control required for the implementation of the object service according to the instruction content shown in the API access request M19. Figure 5 Although only one API access request M19 to the vehicle control module 241 is shown, multiple API access requests M19 may be sent.

[0136] Thereafter, when the target application needs to terminate the service, it sends an API access request M20 to the termination determination module 213 .

[0137] The access control unit 10 that has received the API access request M20 confirms the destination API indicated by the API access request M20. Here, since it is an access request to the N-series API (i.e., a positive determination is made in S320), the access control unit 10 forwards the API access request M20 to the destination API. The destination API operates the termination determination module 213 as the destination module based on the forwarded API access request M20.

[0138] When the vehicle status satisfies a preset termination condition, the termination determination module 213 operating in response to the API access request M20 sends a termination notification M21 to the access control unit 10. The termination condition is not limited to the reception of the API access request M20, but may also include detection of vehicle abnormality.

[0139] The access control unit 10 that has received the end notification M21 regards that the F-based open condition is satisfied (ie, makes an affirmative determination in S210 ), and transmits an access permission notification M22 to which the F-based authenticator is attached to the target application 30 .

[0140] The target application 30 that has received the access permission notification M22 sends an API access request M23 to the calculation module 251. The F-series authenticator acquired through the access permission notification M22 is attached to the API access request M23.

[0141] The access control unit 10 that has received the API access request M23 confirms the destination API indicated by the API access request M23. Here, the request is for access to the F-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 forwards the API access request M23 to the destination API. The destination API operates the actuary module 251 as the destination module according to the forwarded API access request M23.

[0142] The calculation module 251 operating in response to the API access request M23 executes the process of calculating the fee required for the target service, and then transmits a payment completion notification M24 to the access control unit 10 .

[0143] The access control unit 10 that has received the payment completion notification M24 regards the service as completed (ie, makes an affirmative determination in S130 ), invalidates each authenticator given to the target application 30 during the process, and transmits a service completion notification M25 to the target application.

[0144] The target application 30 that has received the service end notification M25 discards each authenticator that has been given by the access control unit 10 during the process and ends provision of the service.

[0145] In addition, without calculating the fees, the access control unit 10 may regard the service as ended when receiving the end notification M21 (i.e., make an affirmative determination in S130), invalidate the authenticator, and send a service end notification M25 to the target application 30.

[0146] [3-2. Example of operation in platooning service]

[0147] Next, an operation example in which a platoon driving service is provided by an API utilization application will be described.

[0148] In this case, if Figure 8 As shown, another vehicle 300 that is the front vehicle of the platoon becomes an external device that provides a service (hereinafter referred to as a service providing vehicle). The service providing vehicle 300 includes a service application (hereinafter referred to as a target application) 30 for providing the platoon service.

[0149] The order of platoon service follows Figure 5 to Figure 7 The general order is shown.

[0150] However, the admission determination module 211 used in the platooning service may include, as a determination condition, that the vehicle is traveling on a road where the platooning service is permitted. The road where the platooning service is permitted may be, for example, a specific road without pedestrians, such as a highway.

[0151] In the reliability confirmation module 212 used in the platoon driving service, the position and speed of the service providing vehicle are obtained as reliability information. The closer the distance between the service providing vehicle and the host vehicle and the smaller the relative speed with the host vehicle, the higher the reliability is calculated. In addition, the reliability being above a threshold value can be used as a determination condition for whether the service providing vehicle is sufficiently reliable. In addition, at least one of the distance to the service providing vehicle and the relative speed being within an allowable range can be used as a determination condition.

[0152] In the information providing module 231 used in the platoon driving service, the route information to the destination may be provided as private information to the target application 30. For example, the route information may be set using a navigation device or the like mounted in the vehicle.

[0153] The end determination module 213 used in the platoon driving service may determine that the end condition is satisfied when the destination is reached, when the service providing vehicle is instructed to leave the queue, or when the user inputs a request to leave the queue via the vehicle-mounted HMI.

[0154] In other words, in the platoon driving service, when the vehicle is in a state where it can accept the service and the service providing vehicle is sufficiently reliable, the vehicle-mounted system 100 of the vehicle assigns an O-series authenticator to the target application 30. The target application 30 accesses the provision confirmation module 221 belonging to the O-series functional block group 22 by using the assigned O-series authenticator, and confirms with the user whether the user has the intention to accept the provision of the service. If the user's intention is confirmed, the vehicle-mounted system 100 assigns a P-series authenticator to the target application 30. The target application 30 accesses the information provision module 231 belonging to the P-series functional block group 23 by using the assigned P-series authenticator, and obtains the path information as personal information. In addition, the target application 30 accesses the start confirmation module 222 belonging to the O-series functional block group 22 by using the previously assigned O-series authenticator, and confirms with the user again whether to start the provision of the service. If the user's intention to start the provision is confirmed, the vehicle-mounted system 100 assigns an S-series authenticator to the target application 30. The target application 30 uses the assigned S-series authenticator to access the vehicle control module 241 belonging to the S-series functional block group 24, and executes vehicle control for realizing platooning. If the vehicle-mounted system 100 confirms that the termination condition of the target application 30 is satisfied, it assigns the F-series authenticator to the target application 30. The target application 30 uses the assigned F-series authenticator to access the actuation module 251 belonging to the F-series functional block group 25, and executes actuation of the service provided by the target application 30. If the actuation is completed, the vehicle-mounted system 100 invalidates each authenticator assigned to the target application 30.

[0155] [3-3. Example of actions in AVP service]

[0156] Next, an operation example in which an API utilization application provides an AVP service will be described.

[0157] In this case, if Fig. 9 As shown, the AVP infrastructure 200 installed in the parking lot is an external device that provides services. The AVP infrastructure 200 includes a service application (hereinafter referred to as a target application) 30 executed to implement the AVP service. In addition, the AVP infrastructure 200 includes a vehicle calling device 40 for calling a parked vehicle.

[0158] Instead of using the vehicle calling device 40 , a configuration may be adopted in which the user terminal 400 is used to call the vehicle.

[0159] The order of AVP services Figure 5 to Figure 7 The service acceptance judgment, service reliability confirmation, service provision need confirmation, service termination / actuation are the same as shown, that is, the order of using M1 to M10, M20 to M25 messages is the same as Figures 5 to 7 The general sequence shown is the same.

[0160] However, the admission determination module 211 used in the AVP service may determine that the vehicle can be admitted when the vehicle is located near a parking lot that receives the AVP service, for example.

[0161] In the reliability confirmation module 212 used in the AVP service, the parking lot location and parking lot name providing the AVP service can be obtained from the object application 30 as reliability information. If the parking lot location and parking lot name are consistent with the pre-stored parking reservation, the AVP infrastructure 200 is determined to be reliable.

[0162] In AVP service, such as Fig.10 As shown, the object application 30 that has received the access permission notification M10 sends an API access request M31 to the get-off confirmation module 232 belonging to the P-series functional block group 23. The P-series authenticator obtained through the access permission notification M10 is attached to the API access request M31. The get-off confirmation module 232 obtains the image captured inside the vehicle, and confirms whether all passengers have got off the vehicle based on the result of image analysis, etc., and sends the confirmation result to the access control unit 10. The processing in the get-off confirmation module 232 includes access to private information (i.e., the image captured inside the vehicle), so the API access request M31 to the get-off confirmation module requires the attachment of the P-series authenticator.

[0163] The access control unit 10 that has received the API access request M31 confirms the destination API and the like indicated by the API access request M31. Here, the access request is for the P-series API (i.e., a negative determination is made in S320), and an authenticator is attached (i.e., a positive determination is made in S330), and the authenticator matches the destination API (i.e., a positive determination is made in S340). Therefore, the access control unit 10 transfers the API access request M31 to the destination API. The destination API causes the alighting confirmation module 232, which is the destination module, to operate according to the API access request M31.

[0164] The getting-off confirmation module 232 operating in response to the API access request M31 transmits a getting-off confirmation notification M32 indicating whether all passengers have gotten off the bus to the access control unit 10 .

[0165] The access control unit 10 that has received the alighting confirmation notification M32 considers that the S-series open condition is satisfied (i.e., makes an affirmative determination in S190) when the alighting confirmation notification M32 indicates that all passengers have alighted, and sends an access permission notification M33 to which the S-series authenticator is attached to the target application 30. In addition, when the alighting confirmation notification M32 indicates that there are passengers who have not alighted, the access control unit 10 sends an access rejection notification indicating rejection of granting access rights to the S-series API to the target application 30, although not shown in the figure.

[0166] The target application 30 that has received the access permission notification M33 transmits an API access request M34 to the vehicle control module 241. The S-series authenticator acquired from the access permission notification M33 is attached to the API access request M34.

[0167] The access control unit 10 that has received the API access request M34 confirms the use destination API and the like, and transfers the API access request M34 to the use destination API. The use destination API operates the vehicle control module 241 in accordance with the API access request M34.

[0168] The vehicle control module 241 that operates according to the API access request M34 executes vehicle control according to the instruction content shown in the API access request M34. The target application 30 repeatedly sends the API access request M34 until the vehicle reaches the parking space. As a result, parking based on automatic driving is realized.

[0169] Thereafter, the target application 30, which has received the call instruction via the vehicle call device 40, transmits an API access request M35 to the vehicle control module 241. The S-series authenticator acquired through the access permission notification M33 is attached to the API access request M35.

[0170] The access control unit 10 that has received the API access request M35 confirms the use destination API, etc., and transfers the API access request M35 to the use destination API. The use destination API operates the vehicle control module 241 as the use destination module based on the API access request M35.

[0171] The vehicle control module 241 that operates according to the API access request M35 executes vehicle control according to the instruction content shown in the API access request M35. The target application 30 repeatedly sends the API access request M34 until the vehicle reaches the designated boarding and alighting space from the parking space. As a result, the automatic driving-based exit is realized.

[0172] If the vehicle is ready to leave the warehouse, the target application 30 sends an API access request M20 to the end determination module 213. Figure 5 The general sequence shown is the same.

[0173] In other words, in the AVP service, when the vehicle is located near a parking lot and the information obtained from the AVP infrastructure of the parking lot indicates that it is a parking lot for scheduled parking, the vehicle-mounted system 100 of the vehicle assigns an O-series authenticator to the target application 30. The target application 30 uses the assigned O-series authenticator to access the provision confirmation module 221 belonging to the O-series functional block group 22 to confirm with the user whether or not the user intends to accept the provision of the service. If the user's intention is confirmed, the vehicle-mounted system 100 assigns a P-series authenticator to the target application 30. The target application 30 uses the assigned P-series authenticator to access the get-off confirmation module 232 belonging to the P-series functional block group 23 to confirm the get-off of all passengers based on the image inside the vehicle. If the get-off of all passengers is confirmed, the vehicle-mounted system 100 assigns an S-series authenticator to the target application 30. The target application 30 uses the assigned S-series authenticator to repeatedly access the vehicle control module 241 belonging to the S-series functional block group 24 to perform vehicle control for realizing parking.

[0174] If a vehicle call instruction is input via the vehicle call device 40, the object application 30 repeatedly accesses the vehicle control module 241 belonging to the S-type functional block group 24 by using the previously assigned S-type authenticator, and executes vehicle control for realizing the departure of the designated vehicle. If the termination condition for ending the service is satisfied due to the completion of the departure, the vehicle-mounted system 100 assigns the F-type authenticator to the object application 30. The object application 30 accesses the actuation module 251 belonging to the F-type functional block group 25 by using the assigned F-type authenticator, and executes actuation related to the AVP service provided by the object application 30. If the actuation is completed, the vehicle-mounted system 100 invalidates each authenticator assigned to the object application 30.

[0175] [4. Correspondence of terms]

[0176] In this embodiment, the vehicle-mounted system 100 is equivalent to the access control device in the present disclosure, and the acceptance determination module 211 and the reliability confirmation module 212 are equivalent to the acceptance determination unit in the present disclosure. The start confirmation module 222 is equivalent to the start confirmation unit in the present disclosure, and the actuarial module 251 is equivalent to the actuarial unit in the present disclosure. The authenticator assignment unit 11 is equivalent to the first to third assignment units in the present disclosure. In particular, the processing of S150 to S160 is equivalent to the first assignment unit in the present disclosure, the processing of S170 to S200 is equivalent to the second assignment unit in the present disclosure, and the processing of S210 to S220 is equivalent to the third assignment unit in the present disclosure.

[0177] [5. Effect]

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

[0179] (a) When accepting the provision of API utilization services, the reliability of the service provider is confirmed, and if it is reliable, access to the vehicle API for vehicle control and acquisition of information required for the provision of services is granted in stages. Therefore, unnecessary access to the vehicle API from outside the vehicle can be appropriately restricted, and the API utilization service can be used safely.

[0180] (b) Since the user's consent is included when granting access rights, it is possible to prevent the leakage of vehicle information or the control of the vehicle against the user's intention even if the conditions for receiving the service are met.

[0181] (c) When the API utilization service is a platooning service, the other vehicle 300 becomes the service provider, and the service is provided through inter-vehicle communication without going through the central device. Therefore, there is no time lag caused by communication through the central device, so it is possible to provide accurate services corresponding to the surrounding conditions of the own vehicle.

[0182] In other words, in the conventional platooning system, since the service is provided via the central device, a time lag occurs depending on the processing status in the central device and the communication status between the central device and the vehicle-mounted system 100. Such a time lag is fatal for a vehicle in motion where the surrounding conditions are constantly changing in real time. In the present embodiment, it is possible to prevent a situation in which a user cannot receive the required service at the required moment due to such a time lag, for example, a situation in which a user misses an opportunity to join or leave a platoon.

[0183] (d) When the API utilization service is an AVP service, after accessing the image information of the interior of the vehicle as personal information and confirming the alighting of all passengers, the AVP infrastructure is granted access to the vehicle API that provides vehicle control. Therefore, it is possible to prevent the vehicle from moving to a parking space while some passengers are confined in the vehicle.

[0184] [6. Other embodiments]

[0185] As mentioned above, although embodiment of this disclosure was described, this disclosure is not limited to the said embodiment, Various deformation|transformation can be made and it can be implemented.

[0186] (a) In the above embodiment, the vehicle API is divided according to the FSOP, and access rights are collectively granted to each partition. However, for example, the stages of granting access rights may be different according to the type of vehicle control in the S partition.

[0187] (b) In the above embodiment, when starting a service, the service sequence is started without authenticating the service provider, and when a user accesses via the HMI device, personal authentication is not performed, but the user's input is accepted. In order to improve security, authentication of the service provider and personal authentication may also be performed.

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

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

[0190] (e) In addition to the access control device described above, the present disclosure may also be implemented in various ways, such as a system that uses the access control device as a component, a program for causing a computer to function as the access control device, a non-migrating physical recording medium such as a semiconductor memory that records the program, an access control method, etc.

[0191] [7. Technical ideas disclosed in this specification]

[0192] [Item 1] An access control device comprising:

[0193] An access control unit (10) is configured to use an interface for providing a vehicle function possessed by the vehicle as a vehicle API, use an application program for implementing a service utilizing the vehicle API as an API utilizing application (30), accept an access request from the API utilizing application disposed outside the vehicle, and control access to the vehicle API;

[0194] An acceptance determination unit (211, 212) is configured to provide a function of determining whether the vehicle can accept a service, namely, a target service, through the vehicle API; and

[0195] A start confirmation unit (222) is configured to provide a function of confirming whether to start providing the target service to the user of the vehicle via the vehicle API,

[0196] The access control unit has:

[0197] a first granting unit (11: S150-S160) configured to grant the API using application access to the vehicle API providing the function of the start confirmation unit when the acceptance determination unit determines that the vehicle can be accepted; and

[0198] The second granting unit (11: S170 to S200) is configured to grant the API using application access rights to the vehicle API required for providing the target service when the start confirmation unit confirms the user's start intention.

[0199] [Item 2] The access control device according to Item 1,

[0200] The API utilization application is provided in an external device (200, 300) that exists within a range where peer-to-peer communication with the vehicle is possible.

[0201] [Item 3] The access control device according to item 1 or item 2, further comprising:

[0202] An actuarial calculation unit (251) is configured to provide a function of performing an actuarial calculation related to the target service via the vehicle API.

[0203] The access control unit also includes:

[0204] The third granting unit (11: S210 to S220) is configured to grant the API using application access rights to the vehicle API providing the function of the actuating unit when the termination of the target service is confirmed.

[0205] [Item 4] An access control device according to any one of items 1 to 3,

[0206] The object service is a platoon driving service for controlling the following vehicles to drive in a queue maintained by the following vehicles according to instructions from the leading vehicle.

[0207] The other vehicle (300) that is the front of the platoon is equipped with the above-mentioned API and uses the application.

[0208] [Item 5] The access control device according to Item 4,

[0209] The admission determination unit may include, as a determination condition, that the vehicle is traveling on a road on which provision of the platoon service is permitted.

[0210] [Item 6] The access control device according to item 4 or item 5,

[0211] The admission determination unit may include, as a determination condition, that at least one of a distance to the other vehicle and a relative speed is within an allowable range.

[0212] [Item 7] An access control device according to any one of Items 4 to 6,

[0213] The vehicle API required for providing the platooning service includes a privacy API that provides a function of acquiring route information to a destination of the vehicle and a safety API that provides a function of controlling the behavior of the vehicle.

[0214] [Item 8] An access control device according to any one of Items 1 to 3,

[0215] The above-mentioned service is an automatic parking service that uses automatic driving to enter and exit a parking lot.

[0216] The API utilization application is provided in an infrastructure device (200) installed in a parking lot for realizing the automatic parking service.

[0217] [Item 9] The access control device according to Item 8,

[0218] The admission determination unit may include, as a determination condition, that the position of the vehicle and a preset parking lot name match information provided by the service provider.

[0219] [Item 10] The access control device according to item 8 or item 9,

[0220] The vehicle API required for providing the automatic parking service includes a privacy API that provides a function of acquiring information required to confirm that a passenger of the vehicle has gotten off, and a safety API that provides a function of controlling the behavior of the vehicle.

Claims

1. An access control device, wherein: have: An access control unit (10) is configured to use an interface for providing a vehicle function possessed by the vehicle as a vehicle API, use an application program for implementing a service utilizing the vehicle API as an API utilizing application (30), accept an access request from the API utilizing application disposed outside the vehicle, and control access to the vehicle API; an acceptance determination unit (211, 212) configured to provide, via the vehicle API, a function of determining whether the vehicle can accept a target service, the target service being a service based on an application utilizing the API; and A start confirmation unit (222) is configured to provide a function of confirming whether to start providing the target service to the user of the vehicle via the vehicle API, The access control unit has: a first granting unit (11: S150-S160) configured to grant the API using application access rights to the vehicle API providing the function of the start confirmation unit when the acceptance determination unit determines that the vehicle can be accepted; and The second granting unit (11: S170 to S200) is configured to grant the API using application access rights to the vehicle API required for providing the target service when the start confirmation unit confirms the user's start intention.

2. The access control device according to claim 1, wherein: The API utilization application is provided in an external device (200, 300) that exists within a range where peer-to-peer communication with the vehicle is possible.

3. The access control device according to claim 1, wherein: Also available: An actuarial calculation unit (251) is configured to provide a function of performing an actuarial calculation related to the target service via the vehicle API. The access control unit also includes: The third granting unit (11: S210 to S220) is configured to grant the API using application access rights to the vehicle API providing the function of the actuating unit when the termination of the target service is confirmed.

4. The access control device according to any one of claims 1 to 3, wherein: The object service is a platoon driving service for controlling the following vehicles to drive in a queue in accordance with instructions from the leading vehicle. The other vehicle (300) that is the front of the platoon is equipped with the above-mentioned API and uses the application.

5. The access control device according to claim 4, wherein: The admission determination unit may include, as a determination condition, that the vehicle is traveling on a road on which provision of the platoon service is permitted.

6. The access control device according to claim 4, wherein: The admission determination unit may include, as a determination condition, that at least one of a distance to the other vehicle and a relative speed is within an allowable range.

7. The access control device according to claim 4, wherein: The vehicle API required for providing the platooning service includes a privacy API that provides a function of acquiring route information to a destination of the vehicle and a safety API that provides a function of controlling the behavior of the vehicle.

8. The access control device according to any one of claims 1 to 3, wherein: The above-mentioned service is an automatic parking service that uses automatic driving to enter and exit a parking lot. The API utilization application is provided in an infrastructure device (200) installed in a parking lot for realizing the automatic parking service.

9. The access control device according to claim 8, wherein: The admission determination unit may include, as a determination condition, that the position of the vehicle and a preset parking lot name match information provided by the service provider.

10. The access control device according to claim 8, wherein: The vehicle API required for providing the automatic parking service includes a privacy API that provides a function of acquiring information required to confirm that a passenger of the vehicle has gotten off, and a safety API that provides a function of controlling the behavior of the vehicle.

11. An access control method, comprising: using an interface for providing vehicle functions of a vehicle as a vehicle API, using an application program for implementing a service utilizing the vehicle API as an API utilizing application (30), accepting an access request from the API utilizing application disposed outside the vehicle, and controlling access to the vehicle API, wherein: When the vehicle is determined to be able to accept the object service by the acceptance determination unit (211, 212) configured to provide a function of determining whether the vehicle can accept the object service via the vehicle API, the API utilization application is granted access rights to the vehicle API providing the function of the start confirmation unit (222) (S150-S160), and the object service is a service based on the API utilization application, When the start confirmation unit, which is configured to provide the function of confirming whether to start provision of the object service to the user of the vehicle via the vehicle API, confirms the user's intention to start, the API utilization application is granted access to the vehicle API required for provision of the object service (S170~S200).

Images