Vehicle control system, vehicle control program, position confirmation device

Abstract

To provide a vehicle control system, a vehicle control program, and a position confirmation device that can flexibly adapt to changes in the position confirmation device installed in a vehicle.SOLUTION: A supervising ECU 41 transmits to each authentication ECU 6x an authentication request packet containing a code indicating that all key devices / users are search targets, when the supervising ECU 41 detects that the locking operation has been performed by the user, in two areas: near the outside of the vehicle and inside the cabin, as search target areas. Each authentication ECU 6x searches for a target in a manner according to the own authentication method and position determination method based on the content of the received request, and returns the result to the supervising ECU 41.SELECTED DRAWING: Figure 15

Description

[Technical Field]

[0001] The present disclosure relates to a technology for performing vehicle control such as locking and unlocking a vehicle on the condition that it is confirmed that a user or a key device is present in a predetermined area of ​​the vehicle. [Background technology]

[0002] In addition to electronic keys, some in-vehicle systems can use general-purpose mobile devices such as smartphones as key devices. The electronic key here refers to a dedicated device that functions as a vehicle key and may be called a key fob, smart key, or key card. The key device functions as a vehicle key and is used to verify the legitimacy of the person attempting to use the vehicle. The in-vehicle system can lock and unlock the vehicle only if it can confirm the presence of the key device in a specified area.

[0003] The process of confirming that the smart key is in a specified area is often achieved by communicating with the electronic key using low frequency (LF) antennas installed in multiple locations on the vehicle, as disclosed in Patent Document 1. Furthermore, the location of the portable device may be confirmed by wireless communication compliant with Bluetooth (registered trademark), for example. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2020-100994 Summary of the Invention [Problem to be solved by the invention]

[0005] The specific configuration of a location confirmation device, which is a device for confirming the location of a key device or a user relative to a vehicle, is becoming more diverse. For example, in recent years, configurations for confirming the location of a key device using UWB (Ultra Wide Band) in addition to LF signals and Bluetooth (registered trademark) are being considered. In addition, there is a possibility that a device that confirms the presence of a user at a predetermined location using facial recognition or fingerprint recognition will be installed in a vehicle. Furthermore, the devices that can be used as a key device are also becoming more diverse.

[0006] When a vehicle is equipped with multiple types of location confirmation devices, each with different search targets and determination methods, it may be preferable from the perspectives of security, power consumption, usability, or other factors to have a single control device control them all together.

[0007] However, variations and models of the installed position confirmation devices may differ depending on the vehicle model. In addition, the combination of the position confirmation devices connected to the control device may change after the vehicle is shipped, for example, if some of the position confirmation devices are upgraded or if a position confirmation device is added to the vehicle.

[0008] Given these circumstances, it is desirable for a system that manages and operates multiple location confirmation devices in an integrated manner to be flexible enough to accommodate differences in location confirmation devices between vehicle models and to accommodate replacement / functional changes of location confirmation devices over time.

[0009] The present disclosure has been made based on the above considerations, and one of its purposes is to provide a vehicle control system, a vehicle control program, and a position confirmation device that can flexibly adapt to changes in the position confirmation device installed in the vehicle. [Means for solving the problem]

[0010] The vehicle control system disclosed herein is a vehicle control system including a plurality of position confirmation devices (6x) that each confirm the position of a target registered in advance for each device using a different method, and a central control device (41) that executes an application related to vehicle control based on signals from the plurality of position confirmation devices, wherein the central control device detects the occurrence of a predetermined confirmation event based on signals from an on-board sensor, and based on the detection of the confirmation event, sends a common confirmation request message indicating the requested requirements to the plurality of position confirmation devices, and the position confirmation devices receive the confirmation request message sent from the central control device, converts the request content indicated in the received confirmation request message into content corresponding to the functions of their own device, and then performs position confirmation in a manner corresponding to the requested content, and returns a result notification message indicating the result of the position confirmation to the central control device, and the central control device is configured to determine whether or not to execute vehicle control based on the result notification message returned from the position confirmation device.

[0011] In the above configuration, the central control device transmits a common confirmation request message to any party requesting execution of processing related to target location confirmation. Each location confirmation device converts the content of the confirmation request message into content appropriate to its own capabilities, then performs target location confirmation in a manner appropriate to the requested content, and returns the results to the central control device.

[0012] With this configuration, the central control device does not need to output individual instructions to each position confirmation device, making it possible to realize a vehicle control system that is flexible in accommodating differences in position confirmation devices between vehicle models and in accommodating replacements / function changes of position confirmation devices over time.

[0013] In addition, the vehicle control program disclosed herein includes instructions to cause a computer connected to a plurality of position confirmation devices (6x), each of which uses a different method to confirm the position of a target pre-registered for each device, to detect the occurrence of a predetermined confirmation event based on a signal from an on-board sensor, send a common confirmation request message indicating desired requirements to the plurality of position confirmation devices based on the detection of the confirmation event, receive a result notification message from the position confirmation device indicating the result of the position confirmation based on the confirmation request message, and determine whether or not to execute vehicle control corresponding to the detected confirmation event based on the result notification message returned from the position confirmation device.

[0014] The vehicle control program is a program for causing a computer to function as a central control device included in the vehicle control system. By including the instructions, the computer can be made to operate as a central control device, thereby achieving the same effects as the vehicle control system.

[0015] The position confirmation device disclosed herein is a position confirmation device that performs position confirmation of a pre-registered target based on an instruction signal from a central control device that executes an application related to vehicle control, and is configured to receive a confirmation request message from the central control device indicating requirements for position confirmation, convert the request content indicated in the received confirmation request message into content that corresponds to the functions of the device, perform position confirmation in a manner that corresponds to the request content, and return a result notification message that indicates the result of the position confirmation to the central control device.

[0016] The device is a position confirmation device included in the vehicle control system. The device can achieve the same effects as the vehicle control system by cooperating with the overall control device.

[0017] Note that the symbols in parentheses in the claims indicate a correspondence with the specific means described in the embodiments described below as one aspect, and do not limit the technical scope of the present disclosure. [Brief explanation of the drawings]

[0018] [Figure 1] 1 is a diagram showing an overall view of a vehicle electronic key system; [Figure 2] FIG. 2 is a diagram illustrating an example of an installation position of a communication device. [Figure 3] FIG. 2 is a diagram showing an example of the installation positions of a camera and a fingerprint reader. [Figure 4] 10 is a flowchart showing the flow of a position confirmation process. [Figure 5] FIG. 10 is a diagram illustrating an example of area setting. [Figure 6] FIG. 2 is a functional block diagram of a control ECU. [Figure 7] FIG. 10 is a diagram illustrating an example of a format of a payload contained in a confirmation request packet. [Figure 8] FIG. 10 is a diagram illustrating an example of a value definition in a device field. [Figure 9] FIG. 10 is a diagram illustrating an example of value definition in a range field. [Figure 10] FIG. 10 is a diagram illustrating an example of value definition in an area field. [Figure 11] FIG. 10 is a diagram showing an example of setting areas in which the outside of a vehicle is subdivided. [Figure 12] FIG. 10 is a diagram illustrating an example of a definition of a value in a target field. [Figure 13] FIG. 10 is a diagram illustrating an example of a value definition in a security field. [Figure 14] FIG. 10 is a diagram illustrating an example of a definition of a value in a means field. [Figure 15] FIG. 10 is a sequence diagram illustrating the operation of the system when an unlocking operation is received. [Figure 16] 10 is a diagram showing an example of a confirmation request packet transmitted by a supervisory ECU in response to an unlocking operation. FIG. [Figure 17]10 is a diagram illustrating an example of a payload of a result notification packet transmitted by the smart key authentication ECU. FIG. [Figure 18] FIG. 10 is a diagram illustrating an example of a payload of a result notification packet transmitted by the mobile authentication ECU. [Figure 19] FIG. 10 is a diagram illustrating an example of a confirmation request packet transmitted by a supervisory ECU in response to a locking operation. [Figure 20] 10 is a diagram illustrating an example of a payload of a result notification packet transmitted by the smart key authentication ECU. FIG. [Figure 21] FIG. 10 is a diagram illustrating an example of a payload of a result notification packet transmitted by the mobile authentication ECU. [Figure 22] FIG. 10 is a block diagram showing another example of the configuration of the in-vehicle system. DETAILED DESCRIPTION OF THE INVENTION

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

[0020] <Preface> FIG. 1 is a diagram showing an example of the schematic configuration of a vehicle electronic key system Sys. As shown in FIG. 1, the vehicle electronic key system Sys includes an in-vehicle system 1, multiple smart keys 2, and multiple portable devices 3. The in-vehicle system 1 is a system installed in a vehicle Hv. The smart key 2 is a dedicated device serving as an electronic key for the vehicle Hv. The portable device 3 is a general-purpose information processing terminal carried by the user of the vehicle Hv.

[0021] The vehicle Hv is, for example, an electric vehicle, more specifically, a hybrid vehicle that can be externally charged, a so-called plug-in hybrid vehicle. The concept of an electric vehicle includes not only electric vehicles, but also hybrid vehicles and fuel cell vehicles. A hybrid vehicle is a vehicle equipped with an engine and a motor as power sources. In another embodiment, the vehicle Hv may be an engine vehicle. The vehicle Hv can be used by multiple users.

[0022] The vehicle Hv has a driver's seat on the right side. In another embodiment, the vehicle Hv may have a driver's seat on the left side. In the following description, the front-to-back, left-to-right, and up-to-down directions are defined based on the vehicle Hv unless there is a note regarding the reference direction (i.e., basically). The following description can be modified as needed to conform to the laws, regulations, and customs of the region in which the vehicle Hv is used.

[0023] The in-vehicle system 1 and smart key 2 are configured to be able to wirelessly communicate using radio waves in the LF (Low Frequency) band and RF band. The LF band refers to a frequency band below 300 kHz, such as 125 kHz or 134 kHz, and may also include frequencies between 20 kHz and 30 kHz. In the technical field of vehicle electronic keys, the RF band essentially refers to the UHF (Ultra High Frequency) band, such as 315 MHz or 920 MHz.

[0024] The in-vehicle system 1 is configured to transmit LF signals and receive RF signals. LF signals are radio signals with a predetermined frequency in the LF band. RF signals are radio signals with a predetermined frequency in the RF band. LF signals include a wake signal containing a code for transitioning the smart key 2 to active mode and a challenge signal requesting the return of a response code for authentication. The challenge signal contains a challenge code that is a random number. The smart key 2 returns response data corresponding to the received LF signal to the in-vehicle system 1 using radio waves in the RF band. In this disclosure, bidirectional communication using LF signals and RF signals is also referred to as LF-RF communication.

[0025] The in-vehicle system 1 and the portable device 3 are each configured to be capable of short-distance communication. Here, short-distance communication refers to communication conforming to a predetermined short-distance wireless communication standard in which the actual communication distance is, for example, 5 m to 30 m, and at most about 100 m. Examples of the short-distance communication standard that can be adopted here include Bluetooth (registered trademark) and Wi-Fi (registered trademark). The Bluetooth standard may be Bluetooth Classic or BLE (Bluetooth Low Energy).

[0026] The operation of each part will be described below using as an example a case where the in-vehicle system 1 and the portable device 3 perform wireless communication conforming to the BLE standard (hereinafter referred to as BLE communication) as short-range communication. The in-vehicle system 1 is configured to act as the master in communication with the portable device 3, and the portable device 3 is configured to act as the slave. In another embodiment, the portable device 3 may be configured to operate as the master in communication with the in-vehicle system 1. In the present disclosure, wireless signals transmitted and received in BLE communication are also referred to as BLE signals. BLE signals transmitted from the smart key 2 or the portable device 3 to the in-vehicle system 1 include a device ID as information indicating the sender.

[0027] The smart key 2 and the portable device 3 are devices that hold a key code for using the vehicle Hv and function as an electronic key for the vehicle Hv using the key code. The key code here is data used in the authentication process described below. The key code is data used to verify that the person attempting to access the vehicle Hv is a user, that is, to verify the legitimacy of the person attempting to access the vehicle Hv. In this disclosure, the smart key 2 and the portable device 3 are also collectively referred to as key devices. The key code may be different for each key device.

[0028] It is anticipated that the smart key 2 will continue to be sold / distributed as an accessory to the vehicle even in the in-vehicle system 1 configured to allow the portable device 3 to be used as a key device as in the present disclosure. It is also anticipated that some users will continue to use the smart key 2 as a vehicle key rather than the portable device 3 due to their preferences. In other words, the in-vehicle system 1 may be configured to be capable of communicating with both the smart key 2 and the portable device 3.

[0029] <About Smart Key 2> The smart key 2 is a dedicated device for the user to operate the vehicle hybrid. The smart key 2 may be distributed to the owner along with the vehicle hybrid when the vehicle hybrid is purchased. The smart key 2 may have a variety of shapes, such as a flat rectangular parallelepiped shape, a flat ellipsoid shape (a so-called fob type), or a card shape. The smart key 2 may be called a vehicle portable device, a key fob, a key card, an access key, or the like. The smart key 2 may also be called an accessory key because it is an accessory to the vehicle hybrid.

[0030] The smart key 2 includes an LF receiver for receiving LF signals, an RF transmitter for transmitting RF signals, and a key controller for controlling these. The LF receiver includes an antenna for receiving LF signals and a circuit for demodulating the received signal (a so-called demodulation circuit). The RF transmitter includes an antenna for transmitting RF signals and a modulation circuit for modulating the baseband signal input from the key controller.

[0031] The key control unit is configured as a microcomputer equipped with a CPU (Central Processing Unit), RAM (Random Access Memory), and ROM (Read Only Memory). The key control unit may be realized using an IC (Integrated Circuit) or FPGA (Field-Programmable Gate Array). The ROM stores the key ID, the vehicle ID of the vehicle Hv that can be locked and unlocked with the smart key 2, the key code, and the smart key control program. The key ID is an ID that the in-vehicle system 1 uses to identify the smart key 2, and a different value is assigned to each smart key 2. The vehicle ID is a value unique to each vehicle.

[0032] The key control unit is activated when the LF receiving unit receives a wake signal with a strength equal to or greater than a predetermined threshold, and transitions the entire smart key 2 from sleep mode to active mode. Active mode is an operating mode in which the key control unit and RF transmitting unit are active. Sleep mode is an operating mode in which power consumption is reduced by limiting the executable functions compared to active mode. Sleep mode corresponds to an operating mode in which most of the key control unit and the RF communication unit are stopped.

[0033] In the active mode, when the LF receiving unit receives a challenge code, the key control unit generates a response code using the key code stored in the ROM and causes the RF transmitting unit to wirelessly transmit the response code.

[0034] In a more preferred embodiment, the smart key 2 includes a transponder as a backup means for communication with the in-vehicle system 1. The transponder operates using power supplied wirelessly from a TP station 47 included in the in-vehicle system 1, and returns a response code corresponding to a challenge code transmitted from the TP station 47 to the in-vehicle system 1. In other words, the smart key 2 is configured to be able to perform wireless communication for authentication with the in-vehicle system 1 using the transponder.

[0035] <About Mobile Device 3> The mobile device 3 is a portable, general-purpose information processing terminal equipped with a BLE communication function. Various communication terminals, such as a smartphone or a wearable device, can be used as the mobile device 3. A wearable device is a device worn on the user's body and can take various forms, such as a wristband, a watch, a ring, glasses, or earphones.

[0036] The portable device 3 includes a BLE communication unit, an NFC communication unit, and a device control unit. The BLE communication unit is a communication module for performing BLE communication. The NFC communication unit is a communication module for performing NFC communication, which is wireless communication conforming to the NFC (Near Field Communication) standard. NFC communication here refers to communication over a communication distance of several centimeters to several tens of centimeters. NFC communication can also be called near-field communication or touch communication. Near-field communication corresponds to a communication method in which the communication distance is much shorter than that of BLE communication.

[0037] The device control unit is configured as a computer including, for example, a processor, memory, storage, etc. A digital key app, which is an application that causes the portable device 3 to function as an electronic key for the vehicle HV, is installed in the storage. The storage also stores a key code. The device control unit establishes a communication connection with the in-vehicle system 1 and performs processes related to authentication.

[0038] The portable device 3 periodically transmits an advertising signal from its BLE communication unit. When the portable device 3 receives a challenge code through BLE communication with the in-vehicle system 1, it generates a response code using a key code stored in storage and returns the response code to the in-vehicle system 1. The portable device 3 also generates a response code when it receives a challenge code from the in-vehicle system 1 through NFC communication. The portable device 3 then returns the generated response code to the in-vehicle system 1 through NFC communication.

[0039] <Configuration of In-Vehicle System 1> As shown in FIG. 1 , the in-vehicle system 1 includes a master ECU 41, a lock / unlock sensor 42, a start switch 43, a control target 44, an LF transmitter 45, an RF receiver 46, a TP station 47, a BLE communication device 48, an NFC communication device 49, a camera 50, and a fingerprint reader 51. In addition to the above devices, the in-vehicle system 1 also includes a smart key authentication ECU 61, a mobile authentication ECU 62, a face authentication ECU 63, and a fingerprint authentication ECU 64. The "ECU" in the component names stands for Electronic Control Unit and refers to an electronic control device. The "TP" in the TP station 47 refers to a transponder. The "mobile" in the component names refers to a portable device 3, but the portable device 3 does not necessarily have a calling function.

[0040] The central ECU 41 is connected to each of the lock / unlock sensor 42, the start switch 43, the controlled object 44, the smart key authentication ECU 61, the mobile authentication ECU 62, the face authentication ECU 63, and the fingerprint authentication ECU 64 via an in-vehicle network Nw so as to be able to communicate with each other. The in-vehicle network Nw is a communication network established within the vehicle Hv. Various standards can be adopted as the standard for the in-vehicle network Nw. The smart key authentication ECU 61 is connected to each of the LF transmitter 45, the RF receiver 46, and the TP station 47, for example, by dedicated communication cables. The mobile authentication ECU 62 is connected to each of the BLE communication device 48 and the NFC communication device 49, so as to be able to communicate with each other, by communication cables. The face authentication ECU 63 is connected to the camera 50 by a video signal line. The fingerprint authentication ECU 64 is connected to the fingerprint reader 51 by a wired connection. The connection configuration between the devices shown in FIG. 1 is an example, and the specific connection configuration between the devices can be changed as appropriate.

[0041] The in-vehicle system 1 includes multiple subsystems (hereinafter referred to as authentication systems) related to confirming the location of a user or a key device. For example, the smart key authentication ECU 61, together with the LF transmitter 45, RF receiver 46, and TP station 47, constitutes a smart key search system Sb1, which is a subsystem that confirms the location of the smart key 2. The mobile authentication ECU 62, together with the BLE communication device 48 and NFC communication device 49, constitutes a mobile search system Sb2, which is a subsystem that confirms the location of the portable device 3. The face authentication ECU 63 constitutes a face authentication system Sb3 that authenticates a user based on an image captured by the camera 50. The fingerprint authentication ECU 64 constitutes a fingerprint authentication system Sb4 that authenticates a user based on a fingerprint pattern read by the fingerprint reader 51.

[0042] Hereinafter, the smart key authentication ECU 61, the mobile authentication ECU 62, the face authentication ECU 63, and the fingerprint authentication ECU 64 will also be collectively referred to as the authentication ECU 6x. The authentication ECU 6x corresponds to a location confirmation device. Location confirmation in this disclosure basically includes not only determining the location but also verifying the legitimacy of the device / person being determined (i.e., authenticating). Whether or not authentication processing is included in location confirmation can be determined by instructions from the master ECU 41, in other words, by the situation in which location confirmation is performed. Furthermore, authenticating a target also involves determining its location. In the following, the term "authentication" can be read as "location confirmation" or "search."

[0043] The supervisory ECU 41 is an ECU that controls the overall operation of multiple authentication systems. The supervisory ECU 41 corresponds to a supervisory control device. The supervisory ECU 41 is realized using a computer. That is, the supervisory ECU 41 includes a processor E1, a memory E2, a storage E3, an input / output circuit E4 (I / O in the figure), and bus lines connecting these components. Note that ECUs other than the supervisory ECU 41, such as the smart key authentication ECU 61, the mobile authentication ECU 62, the face authentication ECU 63, and the fingerprint authentication ECU 64, are also realized using processors, memories, storages, etc.

[0044] The processor E1 is hardware (in other words, an arithmetic core) for arithmetic processing coupled with the memory E2. The processor E1 executes various processes by accessing the memory E2. The memory E2 is a volatile storage medium such as RAM. The storage E3 includes a non-volatile storage medium such as flash memory. The storage E3 stores a vehicle control program executed by the processor E1. The execution of the vehicle control program by the processor E1 corresponds to the execution of a vehicle control method corresponding to the vehicle control program. The input / output circuit E4 is a circuit module for communicating with other devices.

[0045] In the storage E3 of the supervisory ECU 41, a user ID, which is identification information unique to each user, is linked to a management ID. The management ID is an identification number that is held by each authentication ECU 6x and is used to link and manage authentication data for the same user. The management ID may have a one-to-one correspondence with the user ID. Here, as an example, management IDs 1 to 4 are used. Note that the user ID itself may also be used as the management ID.

[0046] The master ECU 41 is configured to be able to execute multiple application software (hereinafter referred to as apps). An app is a program that runs on the ECU. In this disclosure, the terms "application" and "app" can be interpreted as a device / computing core that executes an application. The computing core corresponds to the processor E1. The master ECU 41 executes an authentication control app Ap1 and a vehicle control app Ap2.

[0047] The authentication control application Ap1 is an application that controls each authentication system, or more specifically, each authentication ECU 6x. The vehicle control application Ap2 is an application that executes predetermined vehicle control based on the authentication result. Here, vehicle control refers to at least one of unlocking, locking, on / off control of the driving power supply, welcome control, remote parking, remote leaving the vehicle, etc. Welcome control refers to control such as turning on the vehicle lighting equipment or operating the air conditioning when the user approaches the vehicle Hv. The functions of the authentication control application Ap1 and the vehicle control application Ap2 will be described in detail later.

[0048] The locking / unlocking sensor 42 is a touch sensor that allows the user to lock and unlock the doors of the vehicle Hv. The locking / unlocking sensor 42 is provided on an outer door handle provided on each door. The outer door handle refers to a gripping member provided on the outer surface of the door for opening and closing the door. The locking / unlocking sensor 42 detects that it has been touched by the user from a change in capacitance or a change in pressure, and outputs an electrical signal indicating this to the mobile authentication ECU 62. Note that a button-type switch may be used as a configuration for receiving at least one of the user's unlocking instruction and locking instruction. The button-type switch may be provided on each door handle instead of the locking / unlocking sensor 42 or together with the locking / unlocking sensor 42.

[0049] The start switch 43 is a push switch that the user uses to turn the running power supply on and off. The running power supply is the power supply for running the vehicle Hv, and refers to the system main relay. If the vehicle Hv is an engine vehicle, the ignition power supply corresponds to the running power supply. When the start switch 43 is pushed by the user, it outputs an electrical signal indicating this to the mobile authentication ECU 62. The lock / unlock sensor 42 and the start switch 43 correspond to examples of on-board sensors.

[0050] Controlled objects 44 are actuators and electrical equipment that can be controlled by the central ECU 41. The central ECU 41 is connected with controlled objects 44, such as a door lock motor, a power supply ECU, a speaker, on-board lighting devices, an air conditioning system, and a display. The door lock motor is a motor that switches the state (locked / unlocked) of the locking mechanism of each door. The power supply ECU is an ECU that controls the on / off state of the running power supply installed in the vehicle HV. The power supply ECU switches the running power supply from off to on based on a command signal from the central ECU 41. On-board lighting devices include headlights, interior lights, and welcome lamps. Displays include LCD / organic EL displays installed in the vehicle, and projectors that project images onto the vehicle's side windows or the road surface.

[0051] The LF transmitter 45 is a device that transmits LF signals such as a wake signal and a challenge signal based on instructions from the mobile authentication ECU 62. The LF transmitter 45 includes an LF transmission circuit and an LF transmission antenna. The LF transmission circuit is a circuit that performs predetermined signal processing such as digital-to-analog conversion, frequency conversion, modulation, etc.

[0052] As shown in FIG. 2, the in-vehicle system 1 of this embodiment includes LF transmitters 45a, 45b, 45c, 45d, 45e, 45p, and 45q. The LF transmitter 45a is an LF transmitter 45 provided on the outer door handle for the driver's seat. The LF transmitter 45b is an LF transmitter 45 provided on the outer door handle for the passenger's seat. The LF transmitter 45c is an LF transmitter 45 provided near the trunk door. The LF transmitter 45p is an LF transmitter 45 provided inside the cabin. The LF transmitter 45p is an LF transmitter 45 provided inside the trunk. The LF transmitter 45p is located, for example, in the center of the instrument panel in the vehicle width direction or in front of the driver's seat. The LF transmitter 45q is located, for example, near the seating surface or foot area of ​​the rear seat.

[0053] The communication range of LF transmitter 45a is limited to the vicinity of the driver's door outside the vehicle, the communication range of LF transmitter 45b is limited to the vicinity of the passenger door outside the vehicle, the communication range of LF transmitter 45c is limited to the vicinity of the rear bumper outside the vehicle, the communication range of LF transmitter 45p is limited to the cabin, and the communication range of LF transmitter 45q is limited to the trunk.

[0054] In a more preferred embodiment, the exterior LF transmitters such as the LF transmitters 45a, 45b, and 45c are configured to be able to switch the transmission power between a basic search level and an extended search level. The basic search level is set to a power value that provides a communication range of up to 1 meter from the antenna. The extended search level is set to a power value that provides a communication range of up to 6 meters from the antenna. The extended search level is used to determine whether the smart key 2 is present in a distant area outside the vehicle, which will be described later. The communication ranges (transmission power) of the LF transmitters 45a to 45c are controlled by the smart key authentication ECU 61.

[0055] The RF receiver 46 is a module for receiving an RF signal, i.e., a response signal from the smart key 2. The RF receiver 46 outputs data corresponding to the received signal to the smart key authentication ECU 61. The RF receiver 46 is provided on the ceiling or instrument panel inside the vehicle. The RF receiver 46 may also be built into the smart key authentication ECU 61.

[0056] The TP station 47 is configured to communicate with the transponder of the smart key 2 and is realized using a loop antenna or a coil. The TP station 47 is located near the start switch 43, on the outer door handle of the driver's seat, on the outer door handle of the trunk, etc. Each TP station 47 operates based on instructions from the smart key authentication ECU 61.

[0057] The BLE communicator 48 is a communication module for performing BLE communication with the portable device 3. At least one BLE communicator 48 is provided in the vehicle Hv. As an example, as shown in FIG. 2, the in-vehicle system 1 of this embodiment includes BLE communicators 48a, 48b, 48c, 48p, and 48q as the BLE communicators 48. The BLE communicator 48a is disposed on the B-pillar on the driver's seat side, the BLE communicator 48b is disposed on the B-pillar on the passenger's seat side, and the BLE communicator 48c is disposed near the rear bumper. In the present disclosure, the BLE communicators 48a to 48c are also collectively referred to as exterior BLE communicators. The exterior BLE communicators are BLE communicators 48 disposed on the exterior surfaces (side surfaces or rear surfaces) of the vehicle Hv. The BLE communicator 48p is disposed near the start switch 43, and the BLE communicator 48q is disposed in the trunk. In the present disclosure, the BLE communicators 48 disposed inside the vehicle, such as the BLE communicators 48p and 48q, are also referred to as in-vehicle BLE communicators.

[0058] While being driven, each BLE communication device 48 outputs data indicating the reception status of a signal from the portable device 3 registered as a key device to the mobile authentication ECU 62. The reception status includes whether or not a signal is being received and the reception strength (Received Signal Strength Indicator / Indication). The operating state (driven / stopped) of each BLE communication device 48 is controlled by the mobile authentication ECU 62.

[0059] The mobile authentication ECU 62 of this embodiment uses only one of the multiple BLE communicators 48 for data communication with the portable device 3, and uses the other BLE communicators 48 as communicators for determining the position of the portable device 3. In one aspect, the BLE communicator 48 for position determination is a communicator for measuring the reception strength of a signal from the portable device 3, etc. In this disclosure, the BLE communicator 48 used for data communication with the portable device 3 is also referred to as a representative device. In addition, in this disclosure, the BLE communicator 48 for position determination is also referred to as an observation device. As an example, the mobile authentication ECU 62 of this embodiment operates the BLE communicator 48p as a representative device and the others as observation devices. The setting of the representative device may be dynamically changed by the mobile authentication ECU 62.

[0060] In BLE communication, once a communication connection between devices is established, data is sent and received while successively switching between multiple channels. In other words, frequency hopping is performed during data communication after the connection is established. Therefore, normally, only the representative device can capture the data signal from the mobile device 3. The observation device will not be able to observe the device signal.

[0061] To address such circumstances, the mobile authentication ECU 62 of this embodiment distributes information indicating the channel used for communication with the portable device 3 (hereinafter, referred to as channel information) and the device ID from the master device to each observation device as reference information. Each observation device can recognize, based on the channel information indicated in the reference information, which of the many channels available for BLE it should use to receive a signal from a connected device. As a result, the observation device can detect and report the reception strength and other information of the device signal without establishing a communication connection. Of course, in another aspect, each BLE communication device 48 may be configured to individually perform bidirectional communication with the portable device 3 and transmit information such as reception strength and distance measurements to the mobile authentication ECU 62.

[0062] The NFC communication device 49 is a module for performing near-field communication. The in-vehicle system 1 includes, as the NFC communication devices 49, an NFC communication device 49a disposed on the outer surface of the vehicle Hv, for example, on the right C-pillar, and an NFC communication device 49p disposed inside the vehicle near the driver's seat. The operating state of each NFC communication device 49 is controlled by the mobile authentication ECU 62.

[0063] The camera 50 is a device that generates an image used for facial authentication of a user. For example, the in-vehicle system 1 includes cameras 50a, 52b, 52c, 52p, and 52q as the cameras 50. The operation of each camera 50 is driven based on a signal from the facial authentication ECU 63.

[0064] Camera 50a is a camera 50 capable of capturing an image of the user's face located outside the vehicle on the driver's seat side, and is located, for example, on the B-pillar on the driver's seat side, the roof edge, or the side mirror. Camera 50b is a camera 50 capable of capturing an image of the user's face located outside the vehicle on the passenger's seat side, and is located, for example, on the B-pillar on the passenger's seat side, the roof edge, or the side mirror. Camera 50c is a camera 50 capable of capturing an image of the user's face located in front of the trunk, and is located, for example, near the upper or lower edge of the rear window, the trunk door, or the rear bumper. Cameras 50a to 50c may be cameras for monitoring the surroundings, which are also used to control driving assistance / autonomous driving. Camera 50p is a camera capable of capturing an image of the face of a passenger sitting in the driver's seat, and is installed, for example, on the steering column cover or the upper edge of the windshield with its optical axis facing the direction of the driver's seat headrest. Camera 50p may also be a camera for a driver status monitor that detects the driver's state (drowsiness, etc.). Each camera 50 may be an optical camera or an infrared camera.

[0065] The fingerprint reader 51 is a device that reads fingerprint information. The fingerprint reader 51 outputs data indicating, for example, a capacitance distribution pattern formed by a plurality of electrodes, or a feature point distribution pattern determined based on the capacitance distribution pattern. The fingerprint reader 51 may be an optical type or an ultrasonic type. The in-vehicle system 1 includes fingerprint readers 51a and 51p as shown in FIG. 3.

[0066] The fingerprint reader 51a is provided on the exterior of the vehicle Hv, for example, on the outer door handle for the driver's seat. The fingerprint reader 51a is provided to allow a user outside the vehicle to lock and unlock the vehicle Hv. The fingerprint reader 51p is provided inside the vehicle, for example, on a steering wheel or instrument panel, around the driver's seat. The fingerprint reader 51p is provided to allow the user as the driver to switch the driving power from off to on, etc.

[0067] The smart key authentication ECU 61 is an ECU that performs a process to search for the smart key 2 based on instructions from the master ECU 41. The key ID for each smart key 2 is associated with a user ID and an administration ID and registered in the storage of the smart key authentication ECU 61. The process of searching for the smart key 2 will be described separately later.

[0068] The mobile authentication ECU 62 is an ECU that determines the position of the portable device 3 relative to the vehicle Hv in cooperation with the BLE communication device 48 and the like. The storage of the mobile authentication ECU 62 stores a device ID for each portable device 3, linked to an administration ID and a user ID. The storage E3 also stores communication device setting data indicating the installation position of each BLE communication device 48 in the vehicle Hv. The installation position of each BLE communication device 48 can be expressed as a point on a vehicle coordinate system, which is a two-dimensional coordinate system centered at an arbitrary position on the vehicle Hv and parallel to both the width direction and the front-rear direction of the vehicle Hv. The x-axis forming the vehicle coordinate system can be set parallel to the width direction of the vehicle, and the y-axis can be set parallel to the front-rear direction of the vehicle. The center of the coordinate system is, for example, the center of the vehicle body. The vehicle coordinate system may also be a three-dimensional coordinate system including a z-axis parallel to the height direction. Details of the operation of the mobile authentication ECU 62 will be described later.

[0069] The face authentication ECU 63 is an ECU that authenticates a user by analyzing a facial image included in an image captured by the camera 50. The facial feature data and user ID for each user are stored in the storage of the face authentication ECU 63 in a state linked to an administration ID. Based on a request from the supervisory ECU 41, the face authentication ECU 63 selectively operates the multiple cameras 50 and authenticates the user based on the facial feature data included in the image captured by the camera 50.

[0070] For example, when the facial authentication ECU 63 is instructed by the supervisory ECU 41 to check whether a user is present in the vicinity of the vehicle exterior, the facial authentication ECU 63 attempts to acquire a facial image of the user using the cameras 50a, 50b, and 50c. A state in which user authentication is successful using one of the cameras 50a, 50b, and 50c corresponds to a state in which it is confirmed that the user is present in the vicinity of the vehicle exterior. Furthermore, when the facial authentication ECU 63 is instructed by the supervisory ECU 41 to check whether a user is present inside the cabin, the facial authentication ECU 63 attempts to acquire a facial image of the user using the camera 50p.

[0071] The fingerprint authentication ECU 64 is an ECU that authenticates users based on fingerprint information read by the fingerprint reader 51. The fingerprint authentication ECU 64 stores fingerprint feature data and user IDs for each user in a state linked to a management ID. Based on a request from the supervisory ECU 41, the fingerprint authentication ECU 64 selectively operates multiple fingerprint readers 51 and identifies the user based on the fingerprint information read by the fingerprint reader 51.

[0072] For example, when the fingerprint authentication ECU 64 is instructed by the supervisory ECU 41 to check whether a user is present in the vicinity of the vehicle exterior, the fingerprint authentication ECU 64 attempts to acquire the user's fingerprint information using the fingerprint reader 51a. Also, when the fingerprint authentication ECU 64 is instructed by the supervisory ECU 41 to check whether a user is present in the cabin, the fingerprint authentication ECU 64 attempts to acquire the user's fingerprint information using the fingerprint reader 51p. A state in which user authentication is successful using the fingerprint reader 51p corresponds to a state in which it is confirmed that the user is present in the cabin.

[0073] As described above, data indicating the correspondence between the management ID and authentication data is registered in the storage of each authentication ECU 6x. Each authentication ECU 6x is configured to be able to read out a key code or biometric information corresponding to a management ID designated by the supervisory ECU 41 and perform location confirmation of a target. The target here refers to a person / thing, such as a user or a key device, whose location is to be confirmed. Note that the association between the key device / user and the management ID is established by two-way communication between the authentication ECU 6x and the supervisory ECU 41, for example, when new user information / key device information is registered in the authentication ECU 6x.

[0074] In addition to the above-mentioned sensors / switches / ECUs, various other devices are directly or indirectly connected to the central ECU 41. For example, output signals from a courtesy switch, seat occupancy sensor, seat belt sensor, brake sensor, shift position sensor, etc. may be input to the central ECU 41. The courtesy switch is a switch that outputs a signal indicating the open / closed state of a door. The seat occupancy sensor is a sensor that outputs a signal indicating the seat occupancy state, and is realized using, for example, a pressure sensor disposed on the seat surface. The shift position sensor is a sensor that outputs a signal indicating the current shift position.

[0075] The supervisory ECU 41 and each authentication ECU 6x acquire various vehicle information indicating the state of the vehicle Hv and user operations on the vehicle Hv via the in-vehicle network Nw. For example, the supervisory ECU 41 acquires the state (on / off) of the running power source, the open / closed state of each door, the locked / unlocked state of each door, the output of the lock / unlock sensor 42, the output of the start switch 43, etc. The supervisory ECU 41 may also receive an output value of a brake sensor that detects the amount / force of depression of the brake pedal and a signal indicating the operation state of the parking brake.

[0076] <About smart key authentication> Here, an example of a smart key authentication method will be described. The smart key authentication ECU 61 determines the location of the smart key 2 based on whether or not there is a response from the smart key 2 to the transmitted wake signal. For example, if the smart key authentication ECU 61 receives a response from the smart key 2 as a result of transmitting a wake signal from the LF transmitter 45a at the basic search level, the smart key authentication ECU 61 tentatively determines that the smart key 2 is located in the area outside the driver's seat. The area outside the driver's seat is within the communication area of ​​the LF transmitter 45a, and when the transmission power of the LF transmitter 45a is set to the basic search level, for example, it refers to the area outside the vehicle within 1 meter of the outer door handle for the driver's seat.

[0077] The smart key authentication ECU 61 also performs code matching with the responding smart key 2 that has returned a response to the wake signal. If the code matching is successful, the smart key authentication ECU 61 determines that the smart key 2 is located in a response acquisition area. The response acquisition area is the communication area of ​​the LF transmitter 45 that transmitted the wake signal that triggered the smart key 2 to return a response signal. In the above example, the area outside the driver's seat corresponds to the response acquisition area.

[0078] The code verification process refers to the process of authenticating a communication partner using a challenge-response method. Code verification includes the steps of transmitting a challenge code from the authentication device to the authentication target, the authentication device generating a verification code, the authentication target returning a response code, and the authentication device determining whether the verification code and the response code match. Here, the smart key authentication ECU 61 corresponds to the authentication device, and the response key corresponds to the authentication target. The challenge code itself is a code that is generated using a random number table or a random function and is different for each verification.

[0079] When the smart key authentication ECU 61 receives a response to the wake signal transmitted from a certain LF transmitter 45, it transmits a challenge signal from the LF transmitter 45 to the responding key as the first step of the code verification process. Then, as the second step of the code verification process, the smart key authentication ECU 61 generates a verification code using the challenge code and a key code corresponding to the communication partner according to a predetermined procedure. Then, as the third step of the code verification process, the smart key authentication ECU 61 compares the response code returned from the communication partner with the verification code. If the verification code matches the received response code, the smart key authentication ECU 61 determines that authentication is successful.

[0080] As described above, authentication of the smart key 2 includes a step of determining the location of the LF transmitter 45 from which the response was received, based on the installation location, and a step of authenticating the communication partner through code matching. Alternatively, authentication of the smart key 2 may include a step of verifying relaying using the reception strength of the LF signal observed by the smart key 2 or the reception strength of the response signal returned from the smart key 2. The relay verification step is a step for determining whether communication between the in-vehicle system 1 and the smart key 2 is being relayed unauthorizedly. For example, the smart key authentication ECU 61 determines that communication between the in-vehicle system 1 and the smart key 2 is being relayed based on the observed reception strength being equal to or greater than a predetermined value.

[0081] The smart key authentication ECU 61 selects the LF transmitter 45 to transmit a wake signal from depending on the search target area requested by the supervisory ECU 41. If the supervisory ECU 41 specifies an area near the vehicle exterior as the search target area, the smart key authentication ECU 61 causes the LF transmitters 45a to 45c to transmit wake signals in order. If the supervisory ECU 41 specifies the vehicle interior as the search target area, the smart key authentication ECU 61 causes the LF transmitters 45p to transmit wake signals in order.

[0082] Additionally, the smart key authentication ECU 61 activates the TP station 47 corresponding to the area designated as a search target area by the master ECU 41 to attempt authentication of the smart key 2. Hereinafter, authentication processing using LF-RF communication will be referred to as LF authentication. Also, authentication processing of the smart key 2 using the TP station 47 will be referred to as transponder authentication.

[0083] <About mobile device authentication> Here, an example of a method for authenticating the portable device 3 will be described. As a preparatory operation for determining the location of the portable device 3, the mobile authentication ECU 62 recognizes that the portable device 3 (and therefore the user) is present around the vehicle Hv based on receiving a BLE signal transmitted from the portable device 3. The mobile authentication ECU 62 detects the portable device 3 present around the vehicle Hv using a passive scanning method.

[0084] The mobile authentication ECU 62 may search for the portable device 3 using an active scan method that involves transmitting a scan request. The two types of scan methods may be used depending on the situation. For example, the passive scan method may be used when waiting while the vehicle is parked, while the active scan method may be used when a predetermined confirmation event, such as pressing the start switch 43, is detected. The mobile authentication ECU 62 obtains the device ID of the portable device 3 that is connected for communication from the BLE communication device 48.

[0085] As with the authentication of the smart key 2, the authentication method for the portable device 3 also includes a position determination step (S01), a code matching step (S02), and a relay verification step (S03) as shown in Fig. 4. The position determination step is a step of determining the relative position of the portable device 3 with respect to the vehicle Hv. The code matching step is a step of performing a matching process using a challenge code. The relay verification step is a step of verifying whether wireless communication between the in-vehicle system 1 and the portable device 3 is being performed fraudulently using a repeater.

[0086] For example, in the position determination step, the mobile authentication ECU 62 determines the position of the connected device relative to the vehicle Hv based on the reception strength observed by each BLE communication device 48. A connected device refers to a portable device 3 that is actually communicatively connected to the mobile authentication ECU 62 among the portable devices 3 registered in the supervisory ECU 41. For example, the mobile authentication ECU 62 determines in which area shown in FIG. 5 the connected device is located: inside the cabin, inside the trunk, a nearby outside-vehicle area, a distant outside-vehicle area, or an invalid area, based on the reception strength of the connected device observed by each BLE communication device 48. In FIG. 5, A1 indicates inside the cabin, A2 indicates inside the trunk, A3 indicates the nearby outside-vehicle area, A4 indicates the distant outside-vehicle area, and A5 indicates the invalid area, respectively.

[0087] The cabin interior refers to the space inside the vehicle where the driver's seat and other areas are located. The cabin interior may be subdivided into a front seat area, a rear seat area, and the like. The trunk interior refers to the space inside the trunk. In this disclosure, the cabin interior and the trunk interior are collectively referred to as the vehicle interior.

[0088] The exterior vicinity area refers to the area outside the vehicle that can be considered to be near the vehicle Hv, for example, an area outside the vehicle that is within 1 meter of the vehicle Hv. The exterior vicinity area can also be called a passive entry area or a lock / unlock area. The first distance, which is a distance parameter that is considered to be near the vehicle Hv, may be 0.75 meters, 1.5 meters, or the like, instead of 1 meter. The first distance corresponds to the size of the communication area when transmitting from the exterior LF transmitter at the basic search level.

[0089] The outside-vehicle far area refers to the area outside the vehicle that is within 6 m of the vehicle Hv and outside the outside-vehicle near area. The invalid area refers to an area outside the outside-vehicle far area, i.e., an area that is more than 6 m away from the vehicle Hv. The second distance, which is a distance parameter that defines the outer boundary of the outside-vehicle far area, may be 5 m or 8 m instead of 6 m. The outside-vehicle far area can also be considered a welcome area, which is an area for starting welcome control.

[0090] The mobile authentication ECU 62 may consider a portable device 3 that is not connected for communication to be in an invalid area. Also, when the mobile authentication ECU 62 determines that a portable device 3 that is connected for communication is not located inside the vehicle, in a nearby area outside the vehicle, or in a far area outside the vehicle, the mobile authentication ECU 62 may determine that the portable device 3 is located in an invalid area.

[0091] The flow of the code matching process executed by the mobile authentication ECU 62 can be the same as that executed by the smart key authentication ECU 61, except for the communication partner and communication means. The timing at which the mobile authentication ECU 62 executes the code matching process can be the timing at which an authentication request is received from the master ECU 41. In another aspect, the mobile authentication ECU 62 may execute code matching with the connected device when a communication connection between the BLE communicator 48 and the portable device 3 is established. The mobile authentication ECU 62 may be configured to execute the code matching process at a predetermined cycle while the mobile authentication ECU 62 is communicatively connected to the portable device 3.

[0092] The relay verification step may be, for example, a step of determining whether a distance measurement value determined by having the master device communicate with the connected device for distance measurement is within a predetermined range. If the distance measurement value is equal to or greater than a predetermined value (for example, 6 m), the mobile authentication ECU 62 determines that relaying is being performed.

[0093] The distance measurement value here is a parameter indicating the time of flight (ToF) of a signal transmitted from the portable device 3 until it is received by the BLE communication device 48. The distance measurement value is a parameter different from the reception strength. Specifically, the distance measurement value is the round-trip time (RTT) or the two-frequency phase difference. Ranging communication can be rephrased as communication for measuring the RTT or the two-frequency phase difference. The distance measurement value indicates the ToF for one way or a round trip, and therefore can be called a ToF-related value. The mobile authentication ECU 62 may treat the observed two-frequency phase difference or RTT as the distance measurement value as it is. The distance measurement value corresponds to a parameter obtained by converting the two-frequency phase difference or RTT into a distance dimension.

[0094] Additionally, the mobile authentication ECU 62 drives the NFC communication device 49 corresponding to the area designated as the search target area by the supervisory ECU 41, and attempts to authenticate the portable device 3. Hereinafter, the process of authenticating the portable device 3 using BLE communication will be referred to as BLE authentication. Also, the process of authenticating the portable device 3 using NFC communication will be referred to as NFC authentication.

[0095] The aforementioned LF authentication and BLE authentication are wireless authentication processes that can be performed while the user has the key device in their bag or clothing pocket. In this disclosure, wireless authentication that can be performed without the user having to hold the key device in their hand, such as LF authentication and BLE authentication, is referred to as smart authentication. On the other hand, transponder authentication and NFC authentication are wireless authentication processes that require an action such as holding (approximately contacting) the key device over a scanner such as the TP station 47 or the NFC communication device 49. In this disclosure, transponder authentication and NFC authentication are referred to as approximate contactless authentication.

[0096] <Functions of the Supervisory ECU 41> Here, the functions and operations of the supervisory ECU 41 will be described. The supervisory ECU 41 provides functions corresponding to the various functional blocks shown in Fig. 6 by executing programs stored in the storage E3. That is, the supervisory ECU 41 includes, as functional units, a confirmation event detection unit F1, an authentication request unit F2, and a vehicle control unit F3. The confirmation event detection unit F1 and the authentication request unit F2 are functional blocks belonging to the authentication control application Ap1, and the vehicle control unit F3 is a functional block belonging to the vehicle control application Ap2.

[0097] The confirmation event detection unit F1 detects the occurrence of a confirmation event based on various data / signals input from the in-vehicle network Nw. For example, confirmation events include an unlocking operation and a locking operation. An unlocking operation is a user operation for unlocking the vehicle Hv. For example, a touch operation on the locking / unlocking sensor 42 when the vehicle Hv is locked corresponds to an unlocking operation. A locking operation is a user operation for locking the vehicle Hv. For example, a touch operation on the locking / unlocking sensor 42 when the vehicle Hv is unlocked and the driving power source is set to off corresponds to a locking operation. The confirmation event detection unit F1 can detect an unlocking operation or a locking operation as a confirmation event based on a combination of the state of the vehicle Hv and the output signal from the locking / unlocking sensor 42.

[0098] The confirmation event detection unit F1 may detect a start operation as a confirmation event. A start operation is, for example, pressing the start switch 43 while the brake pedal is depressed. The confirmation event detection unit F1 may also detect the closure of an open door as a confirmation event. More specifically, the closure of all doors in a state where a locking operation of the vehicle Hv has been received may be registered as a confirmation event. Alternatively, the confirmation event detection unit F1 may detect the input of a signal from a brake pedal sensor indicating that the brake pedal has been depressed as a confirmation event.

[0099] Alternatively, the in-vehicle system 1 may be configured to detect a user's unlocking operation based on an output signal from an infrared sensor that forms a detection area under the door. In this case, the confirmation event detection unit F1 may determine that a confirmation event has occurred when a signal indicating that the user has placed their foot over the detection area is input from the infrared sensor.

[0100] When the confirmation event detection unit F1 detects a confirmation event, the authentication request unit F2 outputs a confirmation request packet corresponding to the content of the detected confirmation event and the state of the vehicle Hv to each authentication ECU 6x. The authentication request unit F2 of this embodiment multicasts a confirmation request packet with the same content to each authentication ECU 6x. Of course, the confirmation request packet may be transmitted by unicast instead of multicast. The authentication request unit F2 may unicast confirmation request packets with the same payload (content) to each of the multiple authentication ECUs 6x in turn. The configuration of the confirmation request packet will be described separately later. The authentication request unit F2 obtains a result notification packet indicating the result of the location confirmation process from each authentication ECU 6x designated as the destination of the location confirmation request. The confirmation request packet corresponds to a confirmation request message. The result notification packet corresponds to a result notification message.

[0101] The vehicle control unit F3 is configured to execute vehicle control according to the content of the confirmation event, the location where the presence of the device / user has been confirmed, and the state of the vehicle Hv. When the vehicle control unit F3 confirms that the portable device 3 is not present inside the vehicle and that the key device is present in the vicinity of the vehicle exterior as a result of the location confirmation triggered by the reception of a locking operation, the vehicle control unit F3 locks the vehicle Hv. When the vehicle control unit F3 determines that the portable device 3 is present in the vicinity of the vehicle exterior as a result of the location confirmation triggered by the reception of an unlocking operation, the vehicle control unit F3 cooperates with the body ECU 56 to unlock the door. When the vehicle control unit F3 determines that the portable device 3 is present inside the vehicle as a result of the location confirmation triggered by the reception of a locking operation, the vehicle control unit F3 may use a speaker or a display to warn that the key device is locked out.

[0102] In addition, even if the vehicle control unit F3 cannot confirm the presence of a key device inside the vehicle or in the area near the outside of the vehicle, if the face authentication ECU 63 or fingerprint authentication ECU 64 confirms the presence of the user at a specified location, it will perform vehicle control based on the user's location and vehicle status.

[0103] <Example of confirmation request packet configuration> The payload of a communication packet transmitted and received as an authentication request between the supervisory ECU 41 and the authentication ECU 6x has a fixed format. The authentication request packet has a format that abstracts the instruction content (requests) to a level that is independent of the specifications, functions, and characteristics of each authentication ECU 6x. This configuration is expected to reduce the effort required to modify the program of the supervisory ECU 41 in response to changes in the combination or functions of the authentication ECUs 6x included in the in-vehicle system 1.

[0104] For example, the payloads of the confirmation request packet and the result notification packet include a device field Fd1, a range field Fd2, a first request field Fq1, and a second request field Fq2, as shown in Fig. 7. The first request field Fq1 and the second request field Fq2 have the same configuration. The first request field Fq1 and the second request field Fq2 each include an area field Fd3, a target field Fd4, a security field Fd5, and a means field Fd6.

[0105] About the equipment field The device field Fd1 in the verification request packet is a field that specifies the request target. The request target refers to the device (authentication ECU 6x) that will execute the authentication process. Here, as an example, the device field Fd1 is set to 4 bits, and a different authentication ECU 6x is assigned to each bit. For example, the smart key authentication ECU 61 is assigned to the first bit, the mobile authentication ECU 62 is assigned to the second bit, the face authentication ECU 63 is assigned to the third bit, and the fingerprint authentication ECU 64 is assigned to the fourth bit. The supervisory ECU 41 transmits a verification request packet in which the bit corresponding to the authentication ECU 6x that is to execute the authentication process is set to "1." For example, when the supervisory ECU 41 requests the smart key authentication ECU 61 and the mobile authentication ECU 62 to execute the authentication process, it transmits a verification request packet in which the device field Fd1 is set to "0011." FIG. 8 shows an example of the correspondence relationship between the combinations of request targets for each setting value in the device field Fd1.

[0106] In the above example, it becomes necessary to expand the number of bits in the device field Fd1 in proportion to an increase in the number of authenticated ECUs 6x. As another aspect, the device field Fd1 may be a field into which a bit string indicating an identification number (hereinafter referred to as ECU-ID) of an ECU indicating the request destination / report source of the authentication process is inserted. The length of the device field Fd1 may be variable. Multiple ECU-IDs to be requested may be inserted into the device field Fd1.

[0107] Furthermore, the destination of the communication packet can be specified by the destination address information indicated in the header. The destination of the authentication process request or the source of the report can be identified by the destination address or the source address, so the device field Fd1 may be omitted. The confirmation request packet does not need to have the device field Fd1. The supervisory ECU 41 may be configured to transmit confirmation request packets having the same contents to multiple authentication ECUs 6x that are the target of the request.

[0108] About Range Field The range field Fd2 is a field into which a bit value specifying the distance range for searching for a key device / user outside the vehicle is inserted. Here, as an example, the length of the range field Fd2 is set to 2 bits. When the supervisory ECU 41 specifies, for example, only the nearby area as the search range outside the vehicle, it transmits a confirmation request packet in which the range field Fd2 is set to "01". When the supervisory ECU 41 specifies a range including the outside nearby area and the outside nearby area as the search range outside the vehicle, it transmits a confirmation request packet in which the range field Fd2 is set to "11". Figure 9 shows an example of the definition of the value of the range field Fd2. A code indicating a specific distance value, such as 1 m or 6 m, may be inserted into the range field Fd2.

[0109] About Area Field The area field Fd3 is a field into which a bit value specifying the search area of ​​the key device / user is inserted. Here, as an example, the length of the area field Fd3 is set to 4 bits. For example, when the supervisory ECU 41 specifies the outside of the vehicle as the search area, it transmits a confirmation request packet in which the range field Fd2 is set to "0001." The extent of the search range outside the vehicle can be determined by the setting value of the range field Fd2 described above. Furthermore, when the supervisory ECU 41 specifies the inside of the vehicle as the search area, it transmits a confirmation request packet in which the range field Fd2 is set to "1000." Figure 10 shows an example of the definition of the value of the area field Fd3. Note that, in Figure 10, "outside the trunk" refers to the area outside the vehicle that is within a predetermined distance (e.g., 1 m / 6 m) from the trunk. "outside the hood" refers to the area outside the vehicle that is within a predetermined distance from the front end of the vehicle.

[0110] In another aspect, the range field Fd2 may be integrated into the area field Fd3. If the area outside the vehicle is divided into subareas A31 to A36 and A41 to A46 based on a combination of direction and distance as shown in FIG. 11, the range field Fd2 can be omitted. A code corresponding to the subarea to be set as the search target area may be inserted into the area field Fd3. The example of setting the search target area shown in FIG. 10 is merely an example. The search target area may be divided into only two categories: outside the vehicle and inside the vehicle. Alternatively, the search target area may be divided into four categories: inside the cabin, inside the trunk, an area near the outside of the vehicle, and outside the vehicle. Alternatively, the length of the area field Fd3 may be variable. If the length of the area field Fd3 can be variably set, the supervisor ECU 41 may transmit a confirmation request packet in which a code for each area to be searched is inserted into the area field Fd3.

[0111] About Target Field The target field Fd4 is a field into which a bit value is inserted to specify the key device / user to be targeted for location confirmation (search). The target is specified using a management ID. As an example, the length of the target field Fd4 is set to 5 bits, and a management ID is assigned to each bit. For example, the first bit is assigned management ID = 1, the second bit is assigned management ID = 2, the third bit is assigned management ID = 3, and the fourth bit is assigned management ID = 4. The most significant bit (leftmost bit) is unassigned. Figure 12 shows an example of the definition of each setting value of the target field Fd4.

[0112] When the supervisory ECU 41 designates a device / user corresponding to management ID=1 as the search target, it transmits a confirmation request packet with the target field Fd4 set to "00001." When the supervisory ECU 41 designates a device / user corresponding to management ID=1 to 2 as the search target, it transmits a confirmation request packet with the target field Fd4 set to "00011." In this embodiment, since only management IDs up to number 4 are used, a confirmation request packet with "01111" set in the target field Fd4 corresponds to a confirmation request packet that designates all devices / users as the search target.

[0113] In the above example, the maximum number of management IDs depends on the number of bits in the target field Fd4. Therefore, there may be an upper limit to the number of users that can be registered. To increase the number of users that can be registered, the number of bits in the target field Fd4 needs to be extended. To solve this problem, the length of the target field Fd4 may be variable. Alternatively, the target field Fd4 may be a field into which a management ID indicating the authentication target is inserted. In this case, the target field Fd4 has a number of bits corresponding to the bit length of the management ID. Furthermore, the verification request packet may include multiple target fields Fd4 so that multiple authentication targets can be specified. The supervisor ECU 41 may be configured to use an all-specifying code, which is a code that specifies all management IDs. The all-specifying code may be, for example, a code with all bits set to 1 (11111) or a code with a specific control bit set to 1 (10000).

[0114] Each authentication ECU 6x converts the management ID specified in the target field Fd4 into a target identification number corresponding to the function of the authentication ECU 6x before operating. For example, when the smart key authentication ECU 61 receives a confirmation request packet with management ID=1 set, it searches for a smart key 2 having a key ID associated with management ID=1. When the mobile authentication ECU 62 receives a confirmation request packet with management ID=1 set, it searches for a portable device 3 having a device ID associated with management ID=1. When the face authentication ECU 63 or the fingerprint authentication ECU 64 receives a confirmation request packet with management ID=1 set, it executes processing to authenticate the user associated with management ID=1. In this way, each authentication ECU 6x interprets the common instruction content related to the search target individually according to the function of the authentication ECU 6x and operates accordingly.

[0115] About the security field The security field Fd5 is a field into which a bit value specifying a security level indicating the reliability (safety) of the position confirmation is inserted. Here, as an example, the supervisory ECU 41 is configured to be able to specify three security levels, 1 to 3. Accordingly, the length of the target field Fd4 is set to 2 bits. When specifying level 1 as the security level, the supervisory ECU 41 transmits a confirmation request packet in which the security field Fd5 is set to "01." When specifying level 2 as the security level, the supervisory ECU 41 transmits a confirmation request packet in which the security field Fd5 is set to "10." When specifying level 3 as the security level, the supervisory ECU 41 transmits a confirmation request packet in which the security field Fd5 is set to "11." FIG. 13 shows an example of definitions for each value of the security field Fd5.

[0116] Each authentication ECU 6x interprets (operates) the security level setting differently. For example, security level 2 for wireless authentication ECUs such as the smart key authentication ECU 61 and the mobile authentication ECU 62 corresponds to a level where code matching is performed but relay verification processing is omitted. For the smart key authentication ECU 61 and the mobile authentication ECU 62, security level 3 corresponds to a level where code matching and relay verification processing are performed. Security level 1 corresponds to a level where even code matching is not performed, for example, a level where only identification of the communication partner and location determination are performed using a device ID / key ID. For a wireless authentication ECU, the security level corresponds to information indicating the necessity of code matching or relay determination. Furthermore, biometric authentication ECUs such as the face authentication ECU 63 and the fingerprint authentication ECU 64 can perform identification processing with higher accuracy using more feature quantities as the security level increases. In this way, each authentication ECU 6x interprets and operates in accordance with the functions of its own device in response to common instructions related to the security level.

[0117] About the instrument field The means field Fd6 is a field into which a bit value specifying an authentication means / authentication method is inserted. Here, as an example, the length of the means field Fd6 is set to 2 bits. When specifying the first means as the authentication means, the supervisory ECU 41 transmits a confirmation request packet in which the means field Fd6 is set to "01". When specifying the second means as the authentication means, the supervisory ECU 41 transmits a confirmation request packet in which the means field Fd6 is set to "10". When specifying that both the first means and the second means are to be used as authentication means, the supervisory ECU 41 transmits a confirmation request packet in which the means field Fd6 is set to "11". Figure 14 is a diagram showing an example of definitions for each value of the means field Fd6.

[0118] The first means may correspond to the main (normal) authentication means, and the second means may correspond to the sub (backup) authentication means. For example, for the smart key authentication ECU 61, the first means refers to LF authentication, and the second means refers to transponder authentication. For the mobile authentication ECU 62, the first means refers to BLE authentication, and the second means refers to NFC authentication. For an authentication ECU 6x having only one authentication means, that authentication means is applied regardless of the value of the means field Fd6. For example, the face authentication ECU 63 and the fingerprint authentication ECU 64 perform authentication processing using face image / fingerprint information regardless of the value of the means field Fd6. In this way, each authentication ECU 6x interprets the common instructions related to the authentication means individually according to the functions of its own device and operates accordingly. The search means can be rephrased as a search method.

[0119] The second request field Fq2 is a field for requesting a search for a target in an area different from the area specified in the first request field Fq1. The configuration of the second request field Fq2 is the same as that of the first request field Fq1. Note that if the content specified in the first request field Fq1 is sufficient, all bits of the second request field Fq2 can be set to 0.

[0120] <System operation related to unlocking control> Here, the operation of the supervisory ECU 41 and each authentication ECU 6x when the supervisory ECU 41 receives an unlocking operation will be described using the sequence diagram shown in Figure 15. It is assumed that the vehicle Hv is locked. Also, it is assumed that the user who performed the unlocking operation is holding the smart key 2 but not the portable device 3, and is standing within 1 meter of the driver's door. It is assumed that the key ID of the smart key 2 held by the user is 1, and the corresponding management ID is also set to 1.

[0121] First, when the supervisory ECU 41 detects an unlocking operation by the user based on an input signal from the lock / unlock sensor 42 or the like (S11), the supervisory ECU 41 transmits a confirmation request packet to each authentication ECU 6x. As described above, the supervisory ECU 41 may sequentially unicast the confirmation request packet to each authentication ECU 6x, or may transmit the confirmation request packet simultaneously in a multicast manner. Here, as an example, in response to the user's unlocking operation, the supervisory ECU 41 transmits a confirmation request packet in which the smart key authentication ECU 61 and the mobile authentication ECU 62 are set as request targets, as shown in FIG. 16 . That is, the supervisory ECU 41 transmits a confirmation request packet in which “0011” is set in the device field Fd1. Note that the combination of authentication ECUs 6x designated as request targets can be changed as appropriate by a designer or user setting. In response to the user's unlocking operation, the supervisory ECU 41 may transmit a confirmation request packet in which all authentication ECUs 6x are set as request targets. Furthermore, the request targets may be dynamically changed depending on the state of the vehicle Hv or the result of the smart authentication processing. For example, if there is a history of LF authentication or BLE authentication failure within a predetermined time (one minute), the supervisory ECU 41 may transmit a confirmation request packet that adds the biometric authentication ECU to the request targets.

[0122] When the supervisory ECU 41 detects a user's unlocking operation, it basically specifies the area near the vehicle exterior as the search target area and transmits a confirmation request packet with all key devices / users as targets. Specifically, it transmits a confirmation request packet with the range field Fd2 set to "01," the area field Fd3 set to "0001," and the target field Fd4 set to "01111." Note that the search target area when receiving an unlocking operation need only be the area near the vehicle exterior. In other words, there is no need to search other areas. Therefore, the second request field Fq2 can be left blank.

[0123] The supervisory ECU 41 selects a security level depending on the situation. For example, the supervisory ECU 41 sets the security level to the highest level, 3 ("11"), when performing authentication related to the start of use, such as unlocking the vehicle hybrid or turning on the power for driving. On the other hand, the supervisory ECU 41 sets the security level to 2 ("10") when performing authentication related to the end of use, such as locking the vehicle hybrid or turning off the power for driving. As another aspect, the supervisory ECU 41 may always set the security level to 3 ("11").

[0124] The supervisory ECU 41 of this embodiment always sets the means field Fd6 to "11." Of course, the supervisory ECU 41 may set the means field Fd6 to "10" or "01" in specific situations.

[0125] When each authentication ECU 6x receives the confirmation request packet (S12B), it determines whether or not its own device is designated as a request target. An authentication ECU 6x that is not designated as a request target will not operate and will remain in a standby / sleep state even if it receives a confirmation request packet. Note that the supervisory ECU 41 may transmit a confirmation request packet only to a request target. An authentication ECU 6x that receives a confirmation request packet that designates its own device as a request target searches for a target in a manner according to the request content.

[0126] Here, the smart key authentication ECU 61 and the mobile authentication ECU 62 respond to the confirmation request packet transmitted in S11, but the face authentication ECU 63 and the fingerprint authentication ECU 64 do not respond to the confirmation request packet. Note that the authentication ECUs 6x other than the request target, such as the face authentication ECU 63 and the fingerprint authentication ECU 64, may be configured to return a response (Ack / Nack) indicating that the confirmation request packet has been received, although they do not perform authentication themselves.

[0127] The smart key authentication ECU 61 executes a search process for the smart key 2 based on the received confirmation request packet (S13). That is, the smart key authentication ECU 61 sequentially transmits LF signals from each LF transmitter 45 that forms a communication area outside the vehicle, performs code matching using the LF transmitter 45 from which a response is received, and executes relay verification. The smart key 2 to be searched for is determined based on the setting value of the target field Fd4. In this step, all smart keys 2 linked to the vehicle Hv are searched for.

[0128] The mobile authentication ECU 62 also executes a search process for the portable device 3 based on the received confirmation request packet (S14). That is, the mobile authentication ECU 62 sequentially performs location determination, code matching, and relay determination for all portable devices 3 registered in the mobile authentication ECU 62.

[0129] Upon completion of the search process, the authentication ECU 6x designated as the target of the request returns a result notification packet indicating the result to the control ECU 41. In this example, upon completion of a series of search processes, the smart key authentication ECU 61 and the mobile authentication ECU 62 each return a result notification packet indicating the result to the control ECU 41 (S15a, S16a).

[0130] The payload of the result notification packet also has the same format as the verification request packet, as shown in Figures 17 and 18. That is, the result notification packet has a device field Fd1, a range field Fd2, an area field Fd3, a target field Fd4, a security field Fd5, and a means field Fd6. Note that Figure 17 shows an example of the payload of the result notification packet transmitted by the smart key authentication ECU 61, and Figure 18 shows an example of the payload of the result notification packet transmitted by the mobile authentication ECU 62.

[0131] The device field Fd1 in the result notification packet indicates the report source. For example, the device field Fd1 of the result notification packet output by the smart key authentication ECU 61 is set to "0001." The range field Fd2 and area field Fd3 of the result notification packet are set to the range in which the target was actually searched, i.e., the same values ​​as the range field Fd2 and area field Fd3 of the confirmation request packet. As an alternative, a bit string (code) indicating the area in which the target was actually found within the specified search area may be inserted into the area field Fd3. For example, if the smart key authentication ECU 61 finds the smart key 2 outside the driver's seat, it may transmit a result notification packet with the area field Fd3 set to "0010."

[0132] A value corresponding to the management ID of the discovered target is inserted into the target field Fd4 of the result notification packet. For example, if the authentication ECU 6x discovers a target corresponding to management ID=2, it transmits a result notification packet with "00010" set in the target field Fd4. On the other hand, if the authentication ECU 6x does not discover any targets, it transmits a result notification packet with "00000" set in the target field Fd4.

[0133] In this example, the smart key authentication ECU 61 detects the smart key 2 with management ID = 1 and sends a result notification packet with "00001" set in the target field Fd4. On the other hand, the mobile authentication ECU 62 cannot detect the portable device 3 and sends a result notification packet with "00000" set in the target field Fd4.

[0134] The security field Fd5 in the result notification packet is set to the same value as the security field Fd5 in the confirmation request packet. The means field Fd6 in the result notification packet is set to a value corresponding to the means used to discover the target. For example, if the smart key authentication ECU 61 discovers the smart key 2 using LF authentication as the first means, it sets "01" in the means field Fd6. Note that if the authentication ECU 6x cannot discover any targets using the means specified by the supervisory ECU 41, it sets the means field Fd6 to the same value (e.g., "11") as the means field Fd6 in the confirmation request packet.

[0135] After transmitting the confirmation request packet, the supervisory ECU 41 receives result notification packets from each authentication ECU 6x in sequence as needed. In this example, the supervisory ECU 41 receives result notification packets from each of the smart key authentication ECU 61 and the mobile authentication ECU 62 (S15B, S16B). The supervisory ECU 41 then integrates the search results from each authentication ECU 6x (S17). Integrating the search results here corresponds to consolidating the locations where the presence of the key device / user of the vehicle Hv has been confirmed.

[0136] As described above, in this example, the result notification packet from the smart key authentication ECU 61 contains data indicating that the smart key 2 associated with management ID=1 is located in the vicinity of the vehicle exterior. The result notification packet from the mobile authentication ECU 62 contains data indicating that none of the portable devices 3 were found. The integrated search results contain data indicating that the smart key 2 is located in the vicinity of the vehicle exterior. The central ECU 41, based on the fact that the verified smart key 2 is located in the vicinity of the vehicle exterior, controls the door lock motors to unlock each door. That is, the central ECU 41 sets the vehicle Hv to an unlocked state (S18).

[0137] <About the system operation related to lock control> Next, the operation of the supervisory ECU 41 and each authentication ECU 6x when the supervisory ECU 41 receives a locking operation will be described. As a prerequisite, the vehicle Hv is in an unlocked state. Also, it is assumed that the user who performed the locking operation is holding the portable device 3 corresponding to management ID=2 but is not holding the smart key 2, and is standing within 1 meter of the driver's door. It is assumed that the smart key 2 or portable device 3 has not been left behind inside the vehicle.

[0138] The operational sequence when a locking operation is accepted is generally the same as when an unlocking operation is accepted. When the supervisory ECU 41 detects a locking operation by the user based on an input signal from the locking / unlocking sensor 42 or the like, it transmits a confirmation request packet to each authentication ECU 6x. Here, as an example, in response to the user's locking operation, the supervisory ECU 41 transmits a confirmation request packet in which the smart key authentication ECU 61 and the mobile authentication ECU 62 are set as request targets, as shown in FIG. 19. Of course, the combination of authentication ECUs 6x designated as request targets can be changed as appropriate by the designer or user settings. As an example, the set value of the range field Fd2 is set to "01," but the set value of the range field Fd2 may also be set to "11."

[0139] In an authentication request for lock control, it is preferable to search not only the area near the vehicle exterior but also the inside of the cabin to warn of the key device being left inside the cabin. For this reason, the central ECU 41 of this embodiment uses the first request field Fq1 as a field for specifying the area near the vehicle exterior as the search target area, and the second request field Fq2 as a field for specifying the inside of the cabin as the search target area.

[0140] Specifically, a confirmation request packet is sent with the first area field Fd3 set to "0001" and the second area field Fd3 set to "1001." The first area field refers to the area field Fd3 of the first request field Fq1. The second area field refers to the area field Fd3 of the second request field Fq2. The search target can be a code (such as "01111") that means all key devices / users in both the first and second request fields.

[0141] During authentication for locking, there is little need to perform relay verification processing. Therefore, the supervisory ECU 41 can set the security level to 2 ("10") in the confirmation request packet that is sent in response to a locking operation. For authentication outside the vehicle, the means field Fd6 is set to "11" to include not only smart authentication but also near-contact authentication. On the other hand, since it is assumed that there are no occupants in the cabin when locking, the second means, which corresponds to near-contact authentication, can be excluded. Therefore, the means field Fd6 of the second request field Fq2 is set to "01".

[0142] When each authentication ECU 6x receives a confirmation request packet specifying itself as the request target, it searches for the target in a manner corresponding to the request. For example, the smart key authentication ECU 61 uses an exterior LF transmitter to determine whether the smart key 2 is present in the vicinity of the vehicle, and then uses the LF transmitter 45p to determine whether the smart key 2 is present inside the cabin. The mobile authentication ECU 62 performs location determination based on reception strength, and then performs code verification of the connected device.

[0143] When the authentication ECU 6x designated as the request target completes the search process, it returns a result notification packet indicating the results to the master ECU 41. In this example, the smart key authentication ECU 61 transmits a result notification packet in which the target fields Fd4 of the first request field Fq1 and the second request field Fq2 are set to "00000," as shown in Figure 20. In other words, the smart key authentication ECU 61 returns a result notification packet with a code indicating that no key device was found in either of the two designated target fields Fd4.

[0144] 21, the mobile authentication ECU 62 transmits a result notification packet in which the target field Fd4 of the first request field Fq1 is set to "00010" and the target field Fd4 of the second request field Fq2 is set to "00000." In other words, the mobile authentication ECU 62 returns a code indicating that a key device corresponding to management ID=2 has been found in the first target field Fd4.

[0145] When the supervisory ECU 41 receives the result notification packets from each authentication ECU 6x, it integrates these search results and performs control according to the integrated result. In this example, the supervisory ECU 41 determines that the portable device 3 is located in the vicinity of the vehicle exterior and that no key device is located inside the cabin, and controls the door lock motors to lock each door. In other words, the supervisory ECU 41 sets the vehicle Hv to a locked state.

[0146] If a key device is detected as remaining inside the vehicle as a result of the search performed when locking the vehicle, the central ECU 41 may execute a locked-in warning process. The locked-in warning process refers to a process of notifying the user that a key device is remaining inside the vehicle using a speaker or a display. Furthermore, if a key device is detected as remaining inside the vehicle as a result of the search performed when locking the vehicle, the central ECU 41 may execute a remaining device invalidation process, provided that authentication outside the vehicle is successful. The remaining device invalidation process is a process of invalidating a key device left inside the vehicle. "Invalidation" means that the key device is temporarily prevented from functioning as a key for locking and unlocking the vehicle hybrid. "Invalidation" can be achieved by excluding the key device from communication partners or by setting it as an exception to the wireless authentication process. By invalidating the remaining device, the risk of a third party unauthorizedly unlocking the vehicle hybrid can be reduced.

[0147] <Effects> According to the above configuration, the supervisory ECU 41 only needs to output a common instruction to each authentication ECU 6x. In other words, there is no need to output an individual instruction signal to each authentication ECU 6x according to the function of each authentication ECU 6x. This is because each authentication ECU 6x converts the common instruction input from the supervisory ECU 41 into instruction content according to its own function and then operates.

[0148] Therefore, with the above system configuration, the processing load of the supervisory ECU 41 can be reduced. Furthermore, even when a new authentication ECU 6x is added, it is only necessary to add a candidate request target to the supervisory ECU 41. There is no need to significantly modify the program of the supervisory ECU 41 when changing or adding an authentication ECU 6x. In other words, with the above configuration, flexibility can be increased to accommodate differences in authentication devices for each vehicle model and replacement / function changes of authentication devices over time.

[0149] Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and various modifications described below are also included within the technical scope of the present disclosure. Furthermore, various modifications other than those described below can be implemented without departing from the gist of the present disclosure. For example, the various supplements and modifications described below can be implemented in appropriate combinations as long as no technical contradictions arise. Note that components having the same functions as the components described above are given the same reference numerals, and their description may be omitted. Furthermore, when only a portion of the configuration is mentioned, the above description can be applied to the other portions.

[0150] <Additional information on the installation locations of various communication devices> The arrangement of the LF transmitter 45, TP station 47, BLE communication device 48, NFC communication device 49, camera 50, and fingerprint reader 51 is an example, and the number and locations of the devices can be changed as appropriate. The LF transmitter 45 may also be arranged on the outer door handle for the rear seats or at the front end of the vehicle. The BLE communication device 48 may also be arranged on the C-pillar, the interior ceiling, or the driver's foot area.

[0151] <Modification of the method for determining the location of a mobile device> The mobile authentication ECU 62 may identify the position coordinates of the portable device 3 relative to the vehicle Hv by combining the distance measurement values ​​of the multiple BLE communicators 48 and the mounting positions of each BLE communicator 48 in the vehicle Hv. Since the installation positions of each BLE communicator 48 are known, if the distances from three or more BLE communicators 48 to the portable device 3 can be obtained, the position coordinates of the portable device 3 can be calculated by three-point positioning / multipoint positioning. The position coordinates of the portable device 3 can be expressed in a vehicle coordinate system, for example. Then, the mobile authentication ECU 62 may determine the area in which the portable device 3 is located based on the device position coordinates calculated using the distance measurement values.

[0152] <Modification of the communication method between the portable device and the in-vehicle system> Wi-Fi (registered trademark), EnOcean (registered trademark), Wi-SUN (Wireless Smart Utility Network), etc. can be adopted as a communication standard between the in-vehicle system 1 and the mobile device 3. Various Wi-Fi standards can also be adopted, such as IEEE802.11n and IEEE802.11ax. IEEE (registered trademark) is an abbreviation for the Institute of Electrical and Electronics Engineers, which refers to the Institute of Electrical and Electronics Engineers.

[0153] Alternatively, a communication method between the in-vehicle system 1 and the portable device 3, in other words, a short-range communication method, may be UWB-IR (Ultra Wide Band - Impulse Radio), which uses a frequency band of 3 GHz or higher. Short-range communication is performed using high-frequency radio waves. In this disclosure, high-frequency radio waves refer to radio waves of 900 MHz or higher, such as 2.4 GHz. High-frequency radio waves are not limited to radio waves of 1 GHz or higher, but also include radio waves in the sub-gigahertz band, such as 920 GHz.

[0154] <Additional information on the division of roles for certified ECUs> The in-vehicle system 1 may include an authentication ECU 6x for each communication method or for each authentication means, rather than for each device type. For example, as shown in FIG. 22, the in-vehicle system 1 may include an authentication ECU 6x for each communication method. The LF authentication ECU 6A shown in FIG. 22 is an ECU that performs LF authentication, and the BLE authentication ECU 6B is an ECU that performs BLE authentication. The NFC authentication ECU 6C is an ECU that performs NFC authentication, and the transponder authentication ECU 6D is an ECU that performs transponder authentication. The UWB authentication ECU 6E is an ECU that searches for key devices using UWB communication. The face authentication ECU 6F and the fingerprint authentication ECU 6G correspond to the face authentication ECU 63 and the fingerprint authentication ECU 64 described above. The combination and functional arrangement of the authentication ECUs 6x included in the in-vehicle system 1 can be changed as appropriate.

[0155] <Additional information on distance measurement calculation method> The RTT is the time from when a response request signal is transmitted to a communication partner until when a response signal is received from the communication partner. The BLE communication device 48 may use, as the RTT, a value obtained by performing a predetermined correction process on the elapsed time from when a signal is actually transmitted until when it is received. Possible correction processes include subtracting an estimated value of the response processing time that occurs in the mobile device 3, subtracting an estimated value of the delay time that may occur in the BLE communication device 48, and the like. The two-frequency phase difference is a parameter determined by the BLE communication device 48 and the mobile device 3 transmitting and receiving continuous wave (CW) signals, and is the difference between the transmission and reception phase differences observed at each of the two frequencies. The two-frequency phase difference corresponds to the amount of change in the transmission and reception phase difference due to a change in frequency.

[0156] The BLE communication device 48 may calculate and output a two-frequency phase difference for each combination of frequencies used in BLE communication. The function of generating (calculating) a distance measurement value may be built into the BLE communication device 48 or may be provided in the mobile authentication ECU 62. The division of functions between the BLE communication device 48 and the mobile authentication ECU 62 can be changed as appropriate.

[0157] <Applicable vehicle variations> In the above description, the vehicle Hv is, as an example, a four-wheeled vehicle owned by an individual. The user of the vehicle Hv refers to the owner, their family, etc. The vehicle Hv may be a company car owned by a company organization or an official car owned by a public institution. If the vehicle Hv is a company car or official car, the user may be a person belonging to the organization that manages the vehicle Hv. The vehicle Hv may be a vehicle provided for a rental service (a so-called rental car) or a vehicle provided for a car sharing service (a so-called shared car). If the vehicle Hv is a vehicle provided for the above services, the user may be a person who has signed a service contract for those services and has the authority to temporarily use the vehicle Hv based on a service reservation, etc.

[0158] <Additional remarks (1)> This specification discloses the following technical ideas and their combinations. The scope of this disclosure also includes a position confirmation device and a position confirmation method corresponding to the vehicle control system described below, a program including instructions for causing a computer to execute the processes described below, and a storage medium on which the program is recorded.

[0159] [Technical thought 1] A plurality of location confirmation devices (6x) each of which confirms the location of a target registered in advance in a different manner; and an integrated control device (41) that executes an application related to vehicle control based on signals from a plurality of position confirmation devices, The overall control device is Detecting the occurrence of a predetermined confirmation event based on a signal from an on-board sensor; transmitting a common confirmation request message indicating a request to the plurality of location confirmation devices based on the detected confirmation event; The location confirmation device receiving a confirmation request message sent from the overall control device; converting the request content indicated in the received confirmation request message into content corresponding to the functions of the own device, and then performing location confirmation in a manner corresponding to the request content; and returning a result notification message indicating the result of the location confirmation to the central control device; The vehicle control system is configured such that the central control device determines whether or not to execute vehicle control based on the result notification message returned from the position confirmation device.

[0160] [Technical thought 2] A vehicle control system according to Technical Idea 1, in which a plurality of targets are registered, The confirmation request message includes a code that specifies a target to be searched for among multiple targets, The location confirmation device searches for the target specified in the confirmation request message.

[0161] [Technical thought 3] A vehicle control system according to Technical Idea 1 or 2, The confirmation request message includes a code of a search area, which is an area in which the target is searched; The location confirmation device determines whether the target is present in the search area specified in the confirmation request message. A vehicle control system.

[0162] [Technical thought 4] A vehicle control system according to Technical Concept 3, A vehicle control system configured such that the confirmation request message can set two or more search areas and can specify a target for each search area.

[0163] [Technical thought 5] A vehicle control system according to any one of technical concepts 1 to 4, the confirmation request message includes a code specifying a security level for the location confirmation; The location confirmation device is a vehicle control system that performs location confirmation in a manner according to a specified security level.

[0164] [Technical Thought 6] A vehicle control system according to any one of Technical Ideas 1 to 5, including a position confirmation device configured to be able to search for a target using a plurality of search methods, The confirmation request message includes information specifying how to search for the target.

[0165] [Technical Thought 7] A vehicle control system according to any one of technical concepts 1 to 6, The confirmation request message includes a code specifying a request target, which is a location confirmation device to be operated, among a plurality of location confirmation devices; The location confirmation device designated as the request target in the confirmation request message executes location confirmation according to the contents indicated in the confirmation request message, A vehicle control system in which a location confirmation device that is not specified as a request target in the confirmation request message does not perform location confirmation.

[0166] [Technical Thought 8] A vehicle control system according to any one of technical concepts 1 to 7, configured to be able to register a smart key and a portable device as a key device that functions as a vehicle key through wireless communication with a communication device mounted on the vehicle, The confirmation request message includes a code specifying the type of key device to be searched for, A location confirmation device capable of searching for a key device of the type specified in the confirmation request message performs location confirmation according to the contents indicated in the confirmation request message, while A vehicle control system in which a location confirmation device that cannot find a key device of the type specified in the confirmation request message does not perform location confirmation.

[0167] [Technical Thought 9] A vehicle control system according to any one of technical concepts 1 to 8, The result notification message includes information of the discovered target to the vehicle control system.

[0168] [Technical Thought 10] A vehicle control system according to any one of technical concepts 1 to 9, The result notification message includes information about the area in which the target was found, to the vehicle control system.

[0169] <Additional remarks (2)> The various flowcharts shown in this disclosure are merely examples, and the number of steps in the flowcharts and the execution order of the processes can be modified as appropriate. The apparatus, system, and method described in this disclosure may be implemented by a special-purpose computer comprising a processor programmed to execute one or more functions embodied in a computer program. The apparatus and method described in this disclosure may be implemented using dedicated hardware logic circuits. The apparatus and method described in this disclosure may be implemented by one or more special-purpose computers configured by combining a processor that executes a computer program with one or more hardware logic circuits. Examples of processors (computing cores) include CPUs, MPUs, GPUs, and data flow processors (DFPs). The computer described in this disclosure may be implemented using a system-on-chip (SoC), an IC, or an FPGA. The concept of an IC also includes an application-specific integrated circuit (ASIC). The computer program may be stored as instructions executed by a computer on a computer-readable, non-transitory tangible storage medium. As a recording medium for the program, a hard-disk drive (HDD), a solid-state drive (SSD), a flash memory, or the like can be used. [Explanation of symbols]

[0170] 1 In-vehicle system, 2 Smart key (target), 3 Portable device (target), 6x Authentication ECU (location confirmation device), 41 General ECU (general control device), 42 Lock / unlock sensor (in-vehicle sensor), 43 Start switch (in-vehicle sensor) Fd1 Device field, Fd2 Range field, Fd3 Area field, Fd4 Target field, Fd5 Security field, Fd6 Means field

Claims

1. a plurality of position confirmation devices (6x) for confirming the positions of targets registered in advance for each device in different ways; and an integrated control device (41) that executes an application related to vehicle control based on signals from the plurality of position confirmation devices, The overall control device Detecting the occurrence of a predetermined confirmation event based on a signal from an on-board sensor; transmitting a common confirmation request message indicating a request to the plurality of location confirmation devices based on the detection of the confirmation event; The position confirmation device receiving the confirmation request message sent from the overall control device; converting the request content indicated in the received confirmation request message into content corresponding to the function of the own device, and then performing the location confirmation in a manner corresponding to the request content; and returning a result notification message indicating the result of the location confirmation to the overall control device; The vehicle control system is configured such that the central control device determines whether or not to execute the vehicle control based on the result notification message returned from the position confirmation device.

2. 2. The vehicle control system according to claim 1, wherein a plurality of the targets are registered, the confirmation request message includes a code that specifies the target to be searched for among the plurality of targets, The vehicle control system, wherein the location confirmation device searches for the target specified in the confirmation request message.

3. 3. The vehicle control system according to claim 1 or 2, the confirmation request message includes a code of a search target area, which is an area in which the target is searched; The position confirmation device determines whether the target is present in the search area specified in the confirmation request message.

4. 3. The vehicle control system according to claim 1 or 2, the confirmation request message includes a code specifying a security level for the location confirmation; A vehicle control system, wherein the location confirmation device performs the location confirmation in a manner according to the specified security level.

5. 3. The vehicle control system according to claim 1, further comprising the position confirmation device configured to be able to search for the target using a plurality of search methods, The vehicle control system, wherein the confirmation request message includes information specifying how to search for the target.

6. 2. The vehicle control system according to claim 1, the confirmation request message includes a code specifying a request target that is the location confirmation device to be operated among the plurality of location confirmation devices; The location confirmation device designated as the request target in the confirmation request message executes the location confirmation according to the content indicated in the confirmation request message, while A vehicle control system, wherein the location confirmation device that is not designated as the request target in the confirmation request message does not perform the location confirmation.

7. 3. The vehicle control system according to claim 1, wherein a smart key and a portable device can be registered as key devices that function as keys for the vehicle through wireless communication with a communication device mounted on the vehicle, the confirmation request message includes a code specifying the type of the key device to be searched for, The location confirmation device capable of searching for the key device of the type specified in the confirmation request message performs the location confirmation according to the content indicated in the confirmation request message, while A vehicle control system, wherein the location confirmation device that cannot find the key device of the type specified in the confirmation request message does not perform the location confirmation.

8. 3. The vehicle control system according to claim 1 or 2, The result notification message includes information about the discovered target.

9. 3. The vehicle control system according to claim 1 or 2, The result notification message includes information about the area in which the target was found.

10. 4. The vehicle control system according to claim 3, A vehicle control system configured such that the confirmation request message can set two or more search target areas and can specify the target for each of the search target areas.

11. A computer is connected to a plurality of location confirmation devices (6x) that each confirm the location of a target registered in advance for each device using a different method. Detecting the occurrence of a predetermined confirmation event based on a signal from an on-board sensor; transmitting a common confirmation request message indicating a desired request to a plurality of the location confirmation devices based on the detection of the confirmation event; receiving a result notification message indicating a result of the location confirmation based on the confirmation request message from the location confirmation device; A vehicle control program including instructions for determining whether or not to execute vehicle control corresponding to the detected confirmation event based on the result notification message returned from the location confirmation device.

12. A position confirmation device that confirms the position of a pre-registered target based on an instruction signal from an integrated control device that executes an application related to vehicle control, receiving a confirmation request message from the central control device indicating a requirement for the location confirmation; converting the request content indicated in the received confirmation request message into content corresponding to the function of the own device, and then performing the location confirmation in a manner corresponding to the request content; and returning a result notification message to the overall controller indicating a result of the location confirmation.

Images