Vehicle control system

Abstract

This technology provides the ability for users to use the vehicle even if the control unit loses communication with the authentication device. [Solution] The in-vehicle system 100 includes a first authentication device 11, a zone ECU 13, a CGW 14, a first communication bus 31, and a second communication bus 32. The first communication bus 31 is connected to the first authentication device 11, the zone ECU 13, and the CGW 14. The second communication bus 32 is connected to the zone ECU 13 and the CGW 14, but the first authentication device 11 is not connected to it. When the first authentication device 11 authenticates a portable device wirelessly, it transmits a key discovery report indicating the authentication result to the zone ECU 13 via the first communication bus 31. If the zone ECU 13 is not in a state where it can communicate with the first authentication device 11, the CGW 14, with the permission of the zone ECU 13, transmits the key discovery report sent by the first authentication device 11 to the zone ECU 13 using the second communication bus 32.

Description

Technical Field

[0001] The present disclosure relates to a technology for controlling a vehicle in response to a communication result with an electronic key.

Background Art

[0002] Patent Document 1 discloses a technology that performs ID verification with an electronic key via wireless communication, and unlocks the vehicle or starts the engine on the condition that the ID verification is successful. Patent Document 1 adopts a system configuration in which another ECU is interposed between the ECU (Electronic Control Unit) that performs electronic key verification and the door lock motor or the engine.

[0003] Note that since the electronic key is basically carried by the user, authenticating the electronic key through ID verification can be equivalent to authenticating the user. The verification of the electronic key may be understood as a form of user authentication. The electronic key as referred to herein is a dedicated device that functions as a vehicle key. The term electronic key may also be referred to as a portable device, key fob, smart key, intelligent key, or the like.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of Invention

Problems to be Solved by the Invention

[0005] As in Patent Document 1, a system configuration may be adopted in which a control device is interposed between an authentication device that provides the function of authenticating an electronic key and a control target such as a door lock motor. In such a system configuration, there is a problem that when the control device becomes unable to communicate with the authentication device, the user cannot use the vehicle even though a legitimate electronic key is present near the vehicle.

[0006] This disclosure is based on the above considerations and one of its purposes is to provide a technology that allows the user to use the vehicle even when the control device becomes unable to communicate with the authentication device. [Means for solving the problem]

[0007] The first vehicle control system disclosed herein comprises: an authentication device (11) that authenticates a portable device by wireless communication with the portable device; a control device (13) configured to perform vehicle control, such as unlocking or starting a vehicle, and connected to the authentication device by a first transmission line (31); and a relay device (14) that is wired to the authentication device and connected to the control device by a second transmission line (32), wherein the authentication device, upon authenticating the portable device, transmits authentication data indicating the authentication result to the control device via the first transmission line; the control device performs vehicle control based on having received the authentication data from the authentication device via the first transmission line; and the relay device, if the control device is not in a state to communicate with the authentication device, transmits the authentication data sent by the authentication device to the first transmission line to the control device using a second transmission line; and the control device is configured to perform vehicle control even if it receives authentication data from the relay device via the second transmission line.

[0008] With the above configuration, if the control unit is unable to communicate with the authentication device, the relay device transmits the authentication data to the control unit using a second transmission path. Therefore, even if the control unit becomes unable to communicate with the authentication device, the user can still use the vehicle.

[0009] The second vehicle control system disclosed herein comprises an authentication device (11) that authenticates a portable device by performing wireless communication with the portable device, a control device (13) configured to perform vehicle control, such as unlocking or starting a vehicle, and wired to the authentication device, and a wireless communication device (15) for data communication with a server, wherein the wireless communication device is data-communicable to the control device, the authentication device transmits authentication data indicating the authentication result of the portable device to the control device, the control device performs vehicle control based on the receipt of authentication data from the authentication device, the wireless communication device receives authentication information from the server indicating that a legitimate user is attempting to use the vehicle and provides it to the control device if the control device is not in a state to communicate with the authentication device, and the control device is configured to perform vehicle control even if it receives authentication information from the wireless communication device.

[0010] With the above configuration, if the control unit cannot receive the authentication result from the mobile device, it will perform vehicle control based on the authentication information received via the server. Therefore, even if the control unit loses communication with the authentication device, the user will still be able to use the vehicle.

[0011] The third vehicle control system disclosed herein comprises: an authentication device (11) that authenticates a portable device by wireless communication with the portable device; a control device (13) configured to perform vehicle control, such as unlocking or starting a vehicle, and connected via a wire to the authentication device; and a vehicle operation app (310) which is application software for operating a vehicle and is executed on a portable information processing terminal. The authentication device transmits authentication data indicating the authentication result of the portable device to the control device; the control device performs vehicle control based on the receipt of authentication data from the authentication device; the vehicle operation app communicates with a predetermined server based on user operation, obtains information indicating a specific vehicle operation, and presents it to the user; and the control device is configured to perform vehicle control even when it is not in a state to communicate with the authentication device, if it detects that a specific vehicle operation has been performed based on a signal from an on-board sensor.

[0012] With the above configuration, the control unit performs vehicle control based on the detection that a specific vehicle operation has been performed by the user in a situation where it cannot receive the authentication result from the portable device. Therefore, even if the control unit loses communication with the authentication device, the user can still use the vehicle.

[0013] The reference numerals in parentheses in the claims indicate the correspondence with the specific means described later in the embodiments, and do not limit the technical scope of this disclosure. [Brief explanation of the drawing]

[0014] [Figure 1] This diagram shows an overall view of a vehicle electronic key system. [Figure 2] This is a block diagram showing the configuration of a handheld device. [Figure 3] This is a block diagram showing the configuration of a smartphone. [Figure 4] This block diagram shows the configuration and functions of a zone ECU. [Figure 5] This is a diagram showing the format of a communication frame. [Figure 6] This diagram shows the frame exchange when the Zone ECU is functioning correctly. [Figure 7] This is a sequence diagram showing the operation of the in-vehicle system under normal system conditions. [Figure 8] This is a sequence diagram showing the operation of the in-vehicle system in the event of a system malfunction. [Figure 9] This diagram illustrates the operation of CGW during frame relay. [Figure 10] This diagram illustrates the operation of CGW during frame relay. [Figure 11] This is a diagram illustrating frame relay using encapsulation. [Figure 12] This is a sequence diagram showing an example of system operation when performing user authentication using DCM. [Figure 13]This is a sequence diagram illustrating an example of system operation when performing user authentication without executing DCM and frame relay. [Figure 14] This is a sequence diagram showing the continuation of Figure 13. [Figure 15] This is a flowchart for describing a configuration that selectively uses a plurality of operation patterns according to the state. [Mode for Carrying Out the Invention]

[0015] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. The present disclosure is not limited to the following embodiments. The configurations disclosed below may be implemented with various modifications without departing from the gist thereof. Various modified examples may be appropriately implemented in combination within a range where no technical contradiction occurs. The present disclosure also includes configurations that are not explicitly specified, which are formed by combining a plurality of modified examples. In the following description, members having the same function may be assigned the same reference numerals, and specific descriptions thereof may be omitted. In addition, members having the same function may be assigned the same or similar names, and specific descriptions thereof may be omitted. When only a part of the configuration is mentioned, the descriptions set forth in other portions may be applied to the other parts.

[0016] <Introduction> Figure 1 is a diagram illustrating an example of a schematic configuration of a vehicle electronic key system. As shown in Figure 1, the vehicle electronic key system includes an in-vehicle system 100 and a portable device 200. The vehicle electronic key system also includes one or a plurality of smartphones 300 as an optional element. Furthermore, the vehicle electronic key system includes an authentication server 400, which is a server provided outside the vehicle, as an optional element. The vehicle electronic key system corresponds to the vehicle control system.

[0017] The in-vehicle system 100 is a system mounted on a vehicle. The vehicle referred to below refers to a certain single vehicle on which the in-vehicle system 100 is mounted.

[0018] The portable device 200 is a dedicated device for the user to operate the vehicle. The portable device 200 may be a device provided to the owner along with the vehicle at the time of purchase. The portable device 200 can be understood as one of the vehicle's accessories. The portable device 200 can take on a variety of shapes, such as a flat rectangular prism, a flat ellipsoid (so-called fob type), or a card type. The portable device 200 may be called an electronic key, vehicle portable device, key fob, smart key, or dedicated key.

[0019] The smartphone 300 is a general-purpose information processing terminal carried by the vehicle user. The smartphone 300 may be replaced by other portable, general-purpose information processing terminals such as tablets. The smartphone 300 is equipped with a computer on which application software for operating the vehicle is installed.

[0020] In this example, the vehicle equipped with the in-vehicle system 100 is a vehicle owned by an individual. Therefore, the user of the vehicle refers to the owner or their family. Of course, the vehicle may also be a company car owned by a company or an official vehicle owned by a public institution. If the vehicle is a company car or an official vehicle, the user may be a person belonging to the organization that manages the vehicle. The vehicle is, for example, a gasoline-powered vehicle. In other forms, the vehicle may be an electric vehicle, a hybrid vehicle, or a fuel cell vehicle.

[0021] The in-vehicle system 100 and the portable device 200 are configured to enable wireless communication using the LF-UHF combined method. The LF-UHF combined method is a method of bidirectional communication that uses radio waves in the LF (Low Frequency) band, such as 125 kHz or 134 kHz, and radio waves in the UHF (Ultra High Frequency) band, such as 315 MHz or 920 MHz. For example, in the LF-UHF combined method, radio waves in the LF band may be used to transmit signals from the in-vehicle system 100 to the portable device 200, and radio waves in the UHF band may be used to transmit signals from the portable device 200 to the in-vehicle system 100. The portable device 200 sends response data corresponding to the received LF signal back to the in-vehicle system 100 as a signal in the UHF band. The UHF signal emitted by the portable device 200 is sometimes also called an RF (Radio Frequency) signal. In this disclosure, wireless communication using the LF-UHF combined method is also referred to as smart communication.

[0022] The in-vehicle system 100 and the smartphone 300 are configured to communicate with each other over short distances. Here, short-range communication refers to communication compliant with a predetermined short-range wireless communication standard, where the actual communication range is, for example, 5m to 30m, and at most about 100m. Examples of such short-range communication standards include Bluetooth® Low Energy, Wi-Fi, and UWB-IR (Ultra Wide Band - Impulse Radio). Short-range communication is carried out using high-frequency radio waves, such as 2.4GHz or 5GHz. In a more preferable example, the portable device 200 may also be configured to communicate with the smartphone 300 over short distances.

[0023] The portable device 200 and smartphone 300 hold a key code for using the vehicle and function as an electronic key for the vehicle using this key code. The key code, as used here, is data used in the authentication process described later. The key code is data that proves the legitimacy of the person attempting to access the vehicle; that is, the user's identity. The key code can also be called an authentication key or encryption key. In this disclosure, the portable device 200 and smartphone 300 are collectively referred to as the key device. The following references to the key device can be replaced with either the portable device 200 or the smartphone 300 depending on the context.

[0024] The authentication server 400 is a server that performs the process of authenticating the user by communicating with the smartphone 300. The authentication server 400 and the smartphone 300 are configured to be able to communicate data via cellular communication or the like. Cellular communication refers to wireless communication using mobile phone lines (also called mobile communication networks) provided by mobile communication carriers, such as 4G and 5G.

[0025] The authentication server 400 may be configured to enable cellular communication with the in-vehicle system 100. The authentication server 400 may transmit user authentication information to the vehicle based on signals received from the smartphone 300. The authentication server 400 may maintain data for authenticating the vehicle's user. The authentication server 400 includes a database in which data necessary for user authentication, etc., is stored.

[0026] <About handheld devices> As shown in Figure 2, the portable device 200 includes an operation unit 201, an LF receiver 202, a UHF transmitter 203, an indicator 204, and a key control unit 205. The portable device 200 may also be equipped with a sound output device such as a buzzer.

[0027] The control unit 201 is configured to receive user input to the portable device 200. The control unit 201 may be a push switch or the like. The control unit 201 may have multiple push switches. For example, the control unit 201 may have a lock switch and an unlock switch. The lock switch is a push switch for locking the vehicle doors. The unlock switch is a switch for unlocking the vehicle doors. The portable device 200 is configured to wirelessly transmit remote control signals to the first authentication device 11 in response to switches operated by the user.

[0028] The LF receiver 202 is configured to receive LF signals. The LF receiver 202 is implemented using an antenna for receiving LF signals and a circuit for demodulating the received signal (a so-called demodulation circuit). The LF receiver 202 extracts data contained in the received signal by applying predetermined processing, such as analog-to-digital conversion and demodulation, to the signal received by the antenna. It then provides the extracted data to the key control unit 205. The LF receiver 202 detects the received strength of the LF signal transmitted from the in-vehicle system 100 and outputs it to the key control unit 205. The signal indicating the received strength, or the measured value itself, can also be called RSSI (Received Signal Strength Indicator / Indication).

[0029] The UHF transmitter 203 is a circuit module for transmitting UHF signals. The UHF transmitter 203 includes an antenna and modulation circuit for transmitting UHF signals. The UHF transmitter 203 operates under the control of the key control unit 205. The UHF transmitter 203 transmits a UHF signal corresponding to the signal input from the key control unit 205.

[0030] The indicator 204 is a light-emitting element such as an LED (light-emitting diode). The indicator 204 is used to communicate the status of the portable device 200 to the user by flashing light or the like. In one embodiment, the indicator 204 may also be used to transmit information to the smartphone 300 by a light emission pattern including flashing light. The indicator 204 is controlled by the key control unit 205.

[0031] The key control unit 205 is configured as a microcomputer equipped with a processor, memory, and ROM (Read Only Memory). The key control unit 205 may also be implemented using an IC (Integrated Circuit) or an FPGA (Field-Programmable Gate Array). Key-related information is stored in the ROM. This key-related information includes, for example, a key ID, a key code, and a vehicle ID. The key ID is an identification number used to distinguish it from other portable devices. The vehicle ID is the ID of the vehicle associated with the portable device 200.

[0032] The key control unit 205 is activated when the LF receiver 202 receives a wake signal with an intensity equal to or greater than a predetermined threshold, and it transitions the entire portable device 200 from sleep mode to active mode. In active mode, if the UHF transmitter 203 receives a challenge code, the key control unit 205 generates a response code using a key code stored in memory / ROM and has the UHF transmitter 203 transmit it.

[0033] In addition to receiving a wake signal, the key control unit 205 also switches from sleep mode to active mode when the operation unit 201 is operated, and transmits a control signal corresponding to the operation from the UHF transmission unit 203. The portable device 200 may switch to sleep mode if, in active mode, no acceleration exceeding a predetermined threshold is detected for a certain period of time.

[0034] In addition to the devices described above, the portable device 200 may also be equipped with a communication module for transponder communication. Transponder communication is a type of communication in which a transponder is driven by the received power of electromagnetic waves emitted from a transmitter and transmits a data signal corresponding to the signal received from the transmitter. Transmitters and transponders can be implemented using coils. The portable device 200 may have a transponder module built in as a transponder.

[0035] <About smartphones> As shown in Figure 3, the smartphone 300 comprises a wireless communication unit 301, a display 302, a speaker 303, a touch panel 304, a camera 305, and a computer 306. The wireless communication unit 301, display 302, speaker 303, touch panel 304, and camera 305 are connected to the computer 306. The smartphone 300 also includes hardware necessary to provide the functions required of a smartphone, such as a microphone (not shown).

[0036] The wireless communication unit 301 is a wireless module for short-range communication. The computer 306 uses the wireless communication unit 301 to perform data communication with the in-vehicle system 100. The wireless communication unit 301 may also include a wireless module for cellular communication. The computer 306 uses the wireless communication unit 301 to perform data communication with the authentication server 400.

[0037] The display 302 is a device that displays images corresponding to video signals input from the computer 306. The display 302 may be a liquid crystal display or an organic EL display. The term "image" may be used interchangeably with "video". The speaker 303 is a device that outputs sound corresponding to signals input from the computer 306. The touch panel 304 is a touch panel stacked on the display 302. The touch panel 304 is a device for receiving user input to the smartphone 300. The camera 305 is a device that captures images (video). The camera 305 inputs the captured video to the computer 306.

[0038] The computer 306 includes a processor, memory, storage, and communication circuits. The vehicle operation application 310 is installed on the storage. The vehicle operation application 310 is application software that provides functions related to the use of the vehicle. For example, the vehicle operation application 310, in cooperation with the authentication server 400, provides functions such as remote control of the vehicle and display of the vehicle's status. The vehicle operation application 310 also performs processing to instruct the authentication server 400 to send authentication information to the vehicle based on user operations. Furthermore, when the vehicle operation application 310 is connected to the in-vehicle system 100 via short-range communication, it performs authentication processing via short-range communication and functions as a vehicle key, similar to the portable device 200. The storage may contain key-related information (e.g., key code) to enable the smartphone 300 to function as a vehicle key. The vehicle operation application 310 is not limited to an application that operates the vehicle via the authentication server 400, but may also be an application that operates the vehicle directly via short-range communication.

[0039] <About the configuration of the in-vehicle system> This section describes the configuration and operation of the in-vehicle system 100. As shown in Figure 1, the in-vehicle system 100 includes a first authentication device 11, a second authentication device 12, a zone ECU 13, a central gateway (hereinafter referred to as CGW) 14, and a data communication module (hereinafter referred to as DCM) 15. The in-vehicle system 100 also includes a steering wheel sensor 21, a power switch 22, a relay 23, a lock actuator 24, and an external speaker 25. In the component names, ECU is an abbreviation for Electronic Control Unit, meaning an electronic control unit.

[0040] In addition to the elements described above, the in-vehicle system 100 also includes multiple LF antennas, at least one UHF receiver, at least one TP transmitter, an in-vehicle display, etc. (all not shown in the diagram). The LF antennas are antennas for transmitting LF signals to the portable device 200. The LF antennas may be distributed in multiple locations on the vehicle. The multiple LF antennas include outer LF antennas that transmit LF signals to the outside of the vehicle and inner LF antennas that transmit LF signals to the inside of the vehicle. The outer LF antennas are located on the outer door handles, side mirrors, etc. The inner LF antennas are located on the instrument panel, under the seats, or on the trunk floor, etc.

[0041] The UHF receiver is a communication module for receiving UHF signals emitted from the portable device 200, and includes an antenna. The UHF receiver may be built into the first authentication device 11. The TP transmitter is a vehicle-side device for performing transponder communication with the portable device 200. TP in the component name is an abbreviation for transponder. The TP transmitter may be referred to as an on-board transponder. The TP transmitter acquires authentication data through transponder communication with the portable device 200 and provides it to the first authentication device 11. The on-board display is a display mounted in the vehicle. Transponder communication between the portable device 200 and the vehicle may be understood as a type of Near Field Communication (NFC). Furthermore, the on-board system 100 includes various on-board sensors for detecting user operations on the vehicle, such as an accelerator pedal sensor, a brake pedal sensor, and a hazard switch.

[0042] The handle sensor 21 is a sensor installed on the exterior door handle of the vehicle for detecting user operation related to opening and closing the door. The handle sensor 21 may be a touch sensor. The handle sensor 21 may also be a push switch (also called a door button or lock button). The door button may be installed together with the touch sensor or in place of the touch sensor. The handle sensor 21 may include both a touch sensor and a push switch. The handle sensor 21 outputs an electrical signal corresponding to the user's operation to the first authentication device 11. The handle sensor 21 may be installed on each of the multiple doors of the vehicle. Note that the multiple doors may include the trunk door (also called a back door). The exterior door handle may include the trunk door handle.

[0043] Multiple handle sensors 21 installed on the vehicle are connected to a first authentication device 11. The first authentication device 11 detects the user's unlocking / locking operation based on the output signals of the handle sensors 21. In this embodiment, the detection signals of the handle sensors 21 are also configured to be input to the zone ECU 13. For example, at least one of the multiple handle sensors 21 is also connected to the zone ECU 13.

[0044] The power switch 22 is a push switch for switching the power state of the vehicle. The power switch 22 corresponds to the switch for starting the drive source (e.g., the engine). When the power switch 22 is pressed by the user, it outputs an electrical signal to the zone ECU 13 indicating that it has been pressed. The zone ECU 13 detects the user's power-on operation (or power-off operation) based on the output signal of the power switch 22.

[0045] The steering wheel sensor 21 and the power switch 22 are in-vehicle sensors for detecting user operations on the vehicle. In this disclosure, user operations on the vehicle may also be referred to as user actions. In this disclosure, in-vehicle sensors for detecting user actions, such as the steering wheel sensor 21 and the power switch 22, are also referred to as action sensors.

[0046] Other in-vehicle sensors used as action sensors may include kick sensors, brake pedal sensors, accelerator pedal sensors, hazard switches, wiper switches, turn signal switches, horn switches, etc. The kick sensor may be an infrared sensor, photoelectric sensor, or sonar for detecting the act of placing a foot under the door.

[0047] Relay 23 is a relay used to switch the vehicle's power state. Relay 23 includes a starter relay, an accessory power relay, and an ignition power relay. Relay 23 is connected to the zone ECU 13, and the state of relay 23 is controlled by the zone ECU 13.

[0048] The lock actuator 24 is a motor for switching the locked state of the door. The lock actuator 24 can be understood as a motor that constitutes an electric latch. A lock actuator 24 is provided for each door. The lock actuator 24 may also be a solenoid. The lock actuator 24 is connected to and controlled by the zone ECU 13.

[0049] The external speaker 25 is a speaker that outputs sound towards the outside of the vehicle. The external speaker 25 may be placed at any position on the exterior surface of the vehicle. The external speaker 25 outputs sound in accordance with the signal input from the zone ECU 13.

[0050] The first authentication device 11, the second authentication device 12, the zone ECU 13, and the CGW 14 are interconnected via a first communication bus 31. The first communication bus 31 constitutes a single communication network within the vehicle. The first communication bus 31 may be a bus conforming to any communication standard. Here, as an example, the first communication bus 31 is a bus for CAN (registered trademark) communication. CAN stands for Controller Area Network. The first authentication device 11, the second authentication device 12, the zone ECU 13, and the CGW 14 are connected to the first communication bus 31. In other words, the first authentication device 11 is wired to the second authentication device 12, the zone ECU 13, and the CGW 14. The first authentication device 11, the second authentication device 12, the zone ECU 13, and the CGW 14 each periodically send communication frames to the first communication bus 31 for communication confirmation (in other words, connection confirmation). For convenience, the network formed by the first communication bus 31 will be referred to as the first network, and the network formed by the second communication bus 32 will be referred to as the second network. The first communication bus 31 corresponds to the first transmission path, and the second communication bus 32 corresponds to the second transmission path.

[0051] Furthermore, the zone ECU 13 and CGW 14 are connected to a second communication bus 32, which is different from the first communication bus 31. The second communication bus 32 also constitutes another communication network within the vehicle. The first authentication device 11 and the second authentication device 12 are not connected to the second communication bus 32. Other ECUs (not shown) may be connected to the second communication bus 32.

[0052] The first authentication device 11 is a device that authenticates the portable device 200 by performing wireless communication with the portable device 200. The first authentication device 11 corresponds to the authentication device. Authentication of the portable device 200 refers to the process of verifying whether the communication partner is a device associated with the vehicle using key data (e.g., key code). Successful authentication corresponds to determining that the communication partner is a portable device that has been registered in advance. Since the portable device 200 is associated with a user, successful authentication of the portable device 200 indirectly corresponds to authenticating the user, or in other words, determining that the person attempting to access the vehicle is a legitimate user. Thus, authentication in this disclosure can be understood as verifying whether the user / device is a user / device associated with the vehicle.

[0053] The first authentication device 11 is configured as a computer and includes a processor, memory, and storage. The processor may be a CPU (Central Processing Unit). The memory is a volatile storage medium such as RAM (Random Access Memory). The storage includes a non-volatile storage medium such as flash memory. The storage contains programs executed by the processor. The storage also stores the key data of the portable device 200.

[0054] The key data includes the key ID, key code, and TP-ID. The key ID is the identification number of the portable device 200. The key code is the code used for authentication of the portable device 200 via smart communication. Wireless authentication refers to authentication via wireless communication. The TP-ID corresponds to the code that functions as the key code in wireless authentication via transponder communication. The key data of the portable device 200, including the TP-ID, key ID, and key code, is registered in the storage of the first authentication device 11 at a factory or dealer shop.

[0055] When the first authentication device 11 receives an unlock (or lock) operation from the user via the handle sensor 21, it searches for the portable device 200 by sequentially transmitting predetermined response request signals (so-called wake signals) from multiple LF antennas. If the first authentication device 11 receives a response from the portable device 200, it attempts to authenticate the portable device 200. The authentication method may be a challenge-response method.

[0056] As an example, the first authentication device 11 generates a challenge code in response to user operation and transmits an LF signal (i.e., a challenge signal) containing the challenge code. The challenge code may be a random number of a predetermined length generated using, for example, a pre-prepared random number table, or a random number generated using the current time information as a SEED. When the portable device 200 receives the challenge code, it generates a response code based on the challenge code and the key code and sends it back to the first authentication device 11. Meanwhile, the first authentication device 11 generates a verification code using the key code associated with the portable device 200 stored in its own storage and the challenge code transmitted to the portable device 200 according to a predetermined procedure. The first authentication device 11 authenticates that the communication partner is the legitimate portable device 200 if this verification code matches the received response code or if they have a predetermined relationship.

[0057] Authentication of such a portable device 200 is also called code verification because it involves code matching. In addition to authentication using smart communication, the first authentication device 11 can also perform wireless authentication with the portable device 200 using transponder communication.

[0058] In the process of authenticating the portable device 200 using smart communication, the first authentication device 11 determines the location of the portable device 200 from the position of the LF antenna from which a response is received from the portable device 200. For example, the first authentication device 11 may determine whether the portable device 200 is located in the interior of the vehicle, in front of the driver's side door, in front of the passenger's side door, in front of the right rear seat, in front of the left rear seat, or near the trunk. The areas in front of the driver's side door, in front of the passenger's side door, in front of the right rear seat, in front of the left rear seat, and near the trunk may all be outside the vehicle and within a predetermined distance (e.g., 1.0 m) from the outer door handle.

[0059] In this embodiment, areas outside the vehicle where the in-vehicle system 100 operates, such as in front of the driver's side door, in front of the passenger side door, in front of the right rear seat, in front of the left rear seat, and near the trunk, are also referred to as entry areas. The entry areas and the interior of the vehicle together are referred to as the effective area. The effective area can be understood as the area where the portable device 200 is active, or in other words, the area where vehicle control based on possession of the portable device 200 is performed.

[0060] The portable device 200 may be configured to send back an LF signal including the received strength of the wake signal in response to the wake signal. When the first authentication device 11 receives a response from the portable device 200, it may determine whether the portable device 200 is within the valid area based on the received strength value included in the response. If the received strength deviates from a predetermined normal range, the first authentication device 11 may determine that the portable device 200 is outside the valid area. If the first authentication device 11 determines that the portable device 200 is outside the valid area, it will not perform authentication of the portable device 200. For example, the first authentication device 11 will stop transmitting the challenge signal.

[0061] The first authentication device 11 transmits the result of the authentication process for user operation to the zone ECU 13. For example, if the first authentication device 11 determines that the authentication of the portable device 200 is successful and that the portable device 200 is within the valid area, it transmits a key discovery report to the zone ECU 13 using the first communication bus 31. The key discovery report is a communication frame indicating that a legitimate portable device 200 is within the valid area. The key discovery report corresponds to authentication data indicating the authentication result. The key discovery report may include user information associated with the discovered portable device 200. The key discovery report may include information about the area where the portable device 200 is located (i.e., where the portable device 200 is located). In this embodiment, the communication frame may be understood as a data frame in CAN and has a predetermined frame structure as will be described separately using Figure 5.

[0062] Furthermore, if authentication of the portable device 200 fails, the first authentication device 11 may or may not send a key absence report to the zone ECU 13 using the first communication bus 31. The key absence report is a communication frame indicating that the authentication process has failed, in other words, that no valid portable device 200 has been found.

[0063] The first authentication device 11 includes a communication status determination unit G1, which is implemented by executing a program using a processor or by using dedicated hardware. The communication status determination unit G1 is a functional unit that determines whether the zone ECU 13 is in a state where it can communicate data with the first authentication device 11, that is, whether the zone ECU 13 is connected to the first communication bus 31. The operation of the communication status determination unit G1 will be described separately. The first authentication device 11 corresponds to the authentication device.

[0064] The second authentication device 12 is a device that authenticates the smartphone 300 using short-range communication. The second authentication device 12 is also configured as a computer equipped with a processor, memory, and storage. The second authentication device 12 also has a communication module for short-range communication. If the second authentication device 12 is not connected to the smartphone 300, it periodically performs an advertisement / scan to attempt to connect to the smartphone 300. Based on the successful communication connection with the smartphone 300, the second authentication device 12 may perform authentication processing using short-range communication. Authentication processing using short-range communication may also be performed using a challenge-response method. The second authentication device 12 may have a key code or the like registered for authenticating the smartphone 300.

[0065] If the second authentication device 12 successfully authenticates the smartphone 300, it may additionally perform distance measurement communication or other actions to determine the location of the smartphone 300 relative to the vehicle. If the second authentication device 12 determines that the authentication of the smartphone 300 has been successful and that the smartphone 300 is in the effective area, it transmits a mobile discovery report to the zone ECU 13 using the first communication bus 31. The mobile discovery report may be a communication frame indicating that the smartphone 300 registered in the vehicle is in the effective area. The mobile discovery report may include user information associated with the discovered smartphone 300. The mobile discovery report may include information about the area where the smartphone 300 is located.

[0066] Zone ECU 13 is an ECU that performs vehicle control in response to user operations on the vehicle, provided that a portable device 200 or smartphone 300 (i.e., a key device) is detected within the effective area. The state in which a key device is detected within the effective area will also be referred to as the authentication state below. The authentication state corresponds to the state in which an authenticated key device is present in the entry area or inside the vehicle. Zone ECU 13 transitions to the authentication state upon receiving a key discovery report from the first authentication device 11. Zone ECU 13 also transitions to the authentication state upon receiving a mobile discovery report from the second authentication device 12.

[0067] In the authenticated state, the Zone ECU 13 responds to a push operation of the power switch 22 by controlling the relay 23 to switch the state (on / off) of the driving power supply. The driving power supply is the power supply necessary for the vehicle to run. If the vehicle is an engine-powered vehicle, the driving power supply may be understood as the ignition power supply, and the Zone ECU 13 can start the engine in response to user operation. In addition, the Zone ECU 13 controls the door lock actuator to unlock / lock the doors based on input from the handle sensor 21. The Zone ECU 13 corresponds to the control unit.

[0068] As shown in Figure 4, the Zone ECU 13 comprises a processor 41, memory 42, storage 43, and a communication circuit 44. The storage 43 stores a program executed by the processor 41. The communication circuit 44 is hardware for the Zone ECU 13 to communicate with other in-vehicle devices. The communication circuit 44 may include a circuit suitable for the communication method with other in-vehicle devices. The communication circuit 44 may support any type of wired or wireless communication. The communication circuit 44 includes a first circuit 131 and a second circuit 132.

[0069] The first circuit 131 is a communication circuit for connecting to the first communication bus 31. The first circuit 131 may include a microcontroller and transceiver for CAN communication. The transceiver generates and adjusts the bus transmission voltage, ensures operating current, and protects the wiring. The microcontroller includes a protocol controller that performs bit stuffing, communication arbitration, error handling, CRC checks, etc. The first circuit 131 also includes signal lines (so-called stubs) connecting the transceiver and the communication bus. The second circuit 132 may also include a microcontroller and transceiver for CAN communication, similar to the first circuit 131.

[0070] The Zone ECU 13 includes an authentication management unit F1, a vehicle control unit F2, and a state determination unit F3, which are provided by the processor 41 executing a program stored in the storage 43. The authentication management unit F1 is a functional unit that manages whether or not an authentication state is in place based on data received from the first authentication device 11 and the second authentication device 12. In one embodiment, the authentication management unit F1 can provide a temporary authentication function that temporarily authenticates a user based on a pattern of user operations on the vehicle. The temporary authentication function is an in-vehicle function for realizing the third example of operation described later.

[0071] As described above, the vehicle control unit F2 is a functional unit that performs vehicle control such as unlocking, locking, and powering on (starting the engine). The status determination unit F3 monitors the first communication bus 31 and determines whether the first communication bus 31 is functioning normally. The status determination unit F3 may detect that the zone ECU 13 has disconnected from the first communication bus 31 based on the fact that the first circuit 131 has not received communication frames from other devices connected to the first communication bus 31 for a certain period of time or longer. The status determination unit F3 is also part of the self-diagnosis function and determines whether the first circuit 131 is functioning normally. Whether the first communication bus 31 and the first circuit 131 are functioning normally can be diagnosed by any method. Malfunctions of the first circuit 131 may include circuit element failures, poor contact, and temperature abnormalities, as well as stub disconnections and stub connection failures.

[0072] CGW14 is a device that connects the first communication bus 31 and the second communication bus 32 while ensuring security. CGW14 is connected to both the first communication bus 31 and the second communication bus 32. CGW14 is also connected to DCM15. CGW14 acts as a relay device.

[0073] CGW14 provides functions such as protocol conversion between networks, blocking unauthorized access, and protecting the internal network. For example, CGW14 sends data received from DCM15 to the network corresponding to the destination. More specifically, when it receives data destined for the second authentication device 12 (for example, temporary user key data) from DCM15, it frames the data and sends it to the first communication bus 31. CGW14 may include a communication status determination unit H1. The communication status determination unit H1 of CGW14 may be a hardware or software module that provides the same functions as the communication status determination unit H1 of the first authentication device 11.

[0074] Furthermore, the CGW14 in this embodiment relays data communication between the first authentication device 11 or the second authentication device 12 and the zone ECU 13, with the permission of the zone ECU 13. For example, it receives a communication frame addressed to the zone ECU 13 sent by the first authentication device 11 on the first communication bus 31 and forwards it to the zone ECU 13 using the second communication bus 32. The CGW14 holds data related to communication control, such as routing tables and whitelists.

[0075] DCM15 is a communication module for performing cellular communication. DCM15 performs data communication with a predetermined server. DCM15 transmits data received from CGW14 to the server and transmits data received from the server to CGW14. Note that the external device with which DCM15 performs data communication is not limited to a server. DCM15 may be capable of data communication with any external device. DCM15 may also be configured to perform direct wireless communication with other vehicles, roadside units, or pedestrians via cellular V2X. DCM15 may be understood as one form of V2X in-vehicle unit. DCM15 corresponds to a wireless communication device.

[0076] <Communication frame structure> This section briefly describes the structure of data frames in CAN. In CAN, bus states are categorized into recessive and dominant. When no communication is taking place, the bus is in a recessive state, also known as bus idle. In CAN, if dominant and recessive data are transmitted simultaneously, the dominant data takes precedence, and the bus state becomes dominant.

[0077] As shown in Figure 5, a data frame mainly consists of SOF, ID, RTR, control field, data field, and CRC. SOF (Start Of Frame) is the area that represents the start of communication, or in other words, the beginning of the frame, and is a 1-bit dominant. The receiving node can synchronize when the bus state changes from recessive to dominant at the SOF.

[0078] The ID is an 11-bit (or 18-bit by extension) component used by the receiver to identify the data content and the transmitting node. The ID also plays a role in defining the priority of communication arbitration. When two frames conflict, the communication frame with the higher priority ID becomes valid. The lower priority frame is discarded or invalidated. The ID may also be called the CANID. Each ID is unique to each network, and a certain ID on the first communication bus 31 may mean a different source / data content on the second communication bus 32. In CAN, the transmission and reception of communication frames are performed according to the priority expressed by the ID.

[0079] The RTR (Remote Transmission Request) bit indicates the type of frame, such as whether it is a data frame or a remote frame. In the case of a data frame, the RTR is set to dominant. The control field is an area containing a 4-bit DLC (Data Length Code), and has a total length of 6 bits. The DLC indicates the length of the data field. The data field is the area where the data is stored.

[0080] A data frame consists of a data field followed by a CRC sequence, a CRC delimiter, an ACK slot, an ACK delimiter, an EOF (End of Frame), and an ITM (Initial Time). The CRC (Cyclic Redundancy Check) sequence is a bit sequence used for cyclic redundancy checking. CRC sequences are used for error detection, error correction, etc. The CRC delimiter is a bit that indicates the end of the CRC sequence.

[0081] The ACK (Acknowledgement) slot is a bit that indicates whether the receiving device has successfully received the data up to the CRC delimiter. The transmitting device sends the ACK slot set to recessive. If the receiving device has successfully received the data up to the CRC delimiter, it drives the ACK slot dominantly. If the ACK slot does not change from recessive to dominant, it means that the receiving device (i.e., the destination device) is not properly connected to the network bus. Therefore, the fact that a data frame has not been successfully received by another device can be detected by the fact that the bus state in the ACK slot has not transitioned to dominant.

[0082] The ACK delimiter is a bit that indicates the end of an ACK slot, and EOF (End Of Frame) is a bit sequence that indicates the end of a data frame, and is basically a 7-bit recessive. ITM (Intermission) is a region that creates a break time between the end of a data frame and the transition to a bus idle state.

[0083] In CAN, a unique CANID is assigned according to the source, data type, and priority. For example, as shown in Figure 6, the ID (X) used to send a key discovery report from the first authentication device 11 to the zone ECU 13 and the ID (A) used to send a key search request from the zone ECU 13 to the first authentication device 11 are different values. In the figure, "X" is the ID for the first communication bus 31 used to send a key discovery report from the first authentication device 11 to the zone ECU 13. "B" is the ID for the first communication bus 31 used to send a key discovery report from the first authentication device 11 to the zone ECU 13. "X" and "A" are different values. For the sake of explanation, the SOF, RTR, CRC, etc. are not shown in Figure 6.

[0084] Furthermore, CAN frame IDs are independent for each network. Each device (also called a node) has an ID registered that corresponds to the network it uses, and it uses this ID to perform data communication. CGW14 may use different IDs when sending data to the zone ECU13 via the first communication bus 31 and when sending data to the zone ECU13 via the second communication bus 32.

[0085] <About the communication status determination unit> The communication status determination unit G1 may determine that the zone ECU 13 is not in a state to communicate with the first authentication device 11 based on the fact that a communication frame with a predetermined ID that the zone ECU 13 is supposed to periodically transmit has not arrived for a certain period of time. Not limited to the predetermined communication frame that is supposed to be transmitted periodically, the communication status determination unit G1 may also determine that the zone ECU 13 is not in a state to communicate with the first authentication device 11 based on the fact that it has not received any communication frames from the zone ECU 13 for a certain period of time.

[0086] In addition, the communication status determination unit G1 may determine that the zone ECU 13 is not in a state to communicate with the first authentication device 11 if a predetermined number of consecutive communication frames sent by the unit to the zone ECU 13 are not received properly. A communication frame addressed to the zone ECU 13 may be understood as, for example, a key discovery report, which has an ID that the zone ECU 13 can receive. The first authentication device 11 may be configured to retransmit a key discovery report up to a predetermined number of times (for example, 3 times) if the key discovery report is not received properly. The communication status determination unit G1 may detect a communication interruption of the zone ECU 13 based on the fact that none of the key discovery reports were received properly. A communication interruption of the zone ECU 13 refers to a state in which the zone ECU 13 cannot access the first communication bus 31, in other words, a state in which the zone ECU 13 cannot communicate with the first authentication device 11.

[0087] The communication status determination unit G1 may detect a communication anomaly in Zone ECU 13 based on the fact that no notification of successful reception of the key discovery report is returned from Zone ECU 13. The description of a communication frame addressed to the first authentication device 11 also means a communication frame to which an ID registered as a recipient in the first authentication device 11 has been assigned.

[0088] <Example of system operation under normal conditions> First, we will explain the operation of the portable device 200 and the in-vehicle system 100 when the in-vehicle system 100 is functioning normally, using Figure 7. When the in-vehicle system 100 is functioning normally, it can be understood that at least the zone ECU 13 is properly connected to the first communication bus 31 and is able to receive the key discovery report sent by the first authentication device 11. At the start of the sequence in Figure 7, the vehicle is locked. Figure 7 corresponds to a scenario in which a user carrying the portable device 200 touches the door handle of the vehicle to unlock it, get in, and start the engine.

[0089] First, the first authentication device 11 detects an external action based on the signal from the handle sensor 21 (S101). An external action here refers to an operation on the vehicle by a user outside the vehicle, such as unlocking the doors. Locking the doors is also an example of an external action. Upon detecting the unlocking operation as an external action, the first authentication device 11 attempts to authenticate the portable device 200 using the external LF antenna in S102. That is, the first authentication device 11 transmits an LF signal (i.e., a challenge signal) containing a challenge code from the external LF antenna. Upon receiving the challenge signal, the portable device 200 generates a response code in S103 and sends back a UHF signal (i.e., a response signal) containing the response code.

[0090] Based on receiving a response signal from the portable device 200, the first authentication device 11 performs validity verification in S104. Validity verification includes authenticating the portable device 200 by code matching and confirming that the portable device 200 is within the valid area. Specifically, in S104, the first authentication device 11 compares the response code included in the response signal with a verification code separately generated by the first authentication device 11 to verify the validity (in other words, authenticity) of the portable device 200. It also determines whether the portable device 200 is within the valid area (in this case, the entry area) based on the received strength information of the LF signal received by the portable device 200. If the validity of the portable device 200 is confirmed and it is determined that the portable device 200 is within the valid area, the first authentication device 11 executes the processing from S105 onwards. If authentication of the portable device 200 fails, or if it is determined that the portable device 200 is outside the valid area, the sequence may be terminated, and the in-vehicle system 100 may return to a user operation waiting state.

[0091] S102-S104 correspond to the authentication sequence for the portable device, particularly the authentication sequence for the portable device outside the vehicle. The authentication sequence for the portable device outside the vehicle can be understood as a process of searching for a legitimate portable device 200 in the valid area outside the vehicle (i.e., the entry area). Therefore, below, the authentication sequence for the portable device outside the vehicle will also be referred to as the external key search.

[0092] The authentication sequence for the portable device 200 may include a step in which the first authentication device 11 transmits a wake signal prior to the transmission of a challenge signal. The authentication sequence for the portable device 200 may also include a step in which the portable device 200 returns a response including the received wake signal strength and key ID based on the fact that it has received a wake signal. The response signal issued in S103 may store the value of the received challenge signal strength received by the portable device 200. The first authentication device 11 may determine whether the portable device 200 is within the valid area based on the received challenge signal strength, either in lieu of or in conjunction with the received wake signal strength.

[0093] S105 is the step in which the first authentication device 11 transmits a key discovery report to the first communication bus 31. In the figure, (B1) indicates that the report is transmitted using the first communication bus 31, and (B2) indicates that the report is transmitted using the second communication bus 32. When the zone ECU 13 successfully receives the key discovery report, it outputs a signal to the first communication bus 31 indicating that it has been successfully received (S106). Specifically, it transitions the bus state in the ACK slot to dominant.

[0094] The Zone ECU 13 unlocks the vehicle in S107 based on the fact that an unlocking operation has been performed as an external action and that a valid portable device 200 has been detected within the valid area. Specifically, it sends a control signal for unlocking to the lock actuator 24 and switches the lock mechanism to the unlocked state. This allows the user to enter the vehicle and perform operations related to starting the engine, namely pressing the power switch 22. Hereafter, user operations on operating members provided inside the vehicle, such as pressing the power switch 22, will be collectively referred to as in-vehicle actions.

[0095] Subsequently, when the zone ECU 13 receives a power-on operation as an in-vehicle action (S108), it sends a key search request to the first authentication device 11 in S109. The key search request is a data frame that asks the first authentication device 11 to check if there is a valid portable device 200 inside the vehicle.

[0096] Based on receiving a key search request, the first authentication device 11 executes an authentication sequence for a portable device located inside the vehicle. Specifically, the first authentication device 11 transmits a challenge signal using its internal LF antenna. The portable device 200 located inside the vehicle receives the challenge signal and sends back a response signal. Then, in S112, the first authentication device 11 performs a validity verification.

[0097] Steps S110 to S112 may be substantially identical to steps S102 to S104, except that the LF antenna used for transmitting the LF signal is an internal LF antenna. The authentication sequence for a portable device using an internal LF antenna may be called in-vehicle key retrieval. In-vehicle key retrieval may include a step before S110 in which the first authentication device 11 transmits a wake signal from the internal LF antenna. In-vehicle key retrieval may include determining whether the portable device 200 is inside a vehicle based on the received strength value of the LF signal reported from the portable device 200.

[0098] If, as a result of S112, it is confirmed that a valid portable device 200 is present in the vehicle, the first authentication device 11 transmits a key discovery report to the first communication bus 31 in S113. If the zone ECU 13 successfully receives the key discovery report, it outputs a signal to the first communication bus 31 at a predetermined timing indicating that it has been successfully received (S114). Subsequently, the zone ECU 13 switches the driving power supply from off to on by switching one or more relays 23 to a connected state.

[0099] With the system in place as described above, users can use the vehicle without having to operate any buttons on the portable device 200.

[0100] <Example of operation during system malfunction> Here, we will explain the operation of the in-vehicle system 100 when, although the first communication bus 31 itself is functioning normally, a malfunction in the zone ECU 13 causes the zone ECU 13 to become unable to communicate with the first authentication device 11, using Figure 8. The case in which the zone ECU 13 becomes unable to communicate with the first authentication device 11 due to a malfunction in the zone ECU 13 corresponds to a malfunction in the first circuit 131. Figure 8, like Figure 7, corresponds to a scenario in which a user carrying a portable device 200 unlocks the vehicle and turns on the driving power. However, the premise differs from that when the system is functioning normally in that the zone ECU 13 cannot receive the key discovery report sent from the first authentication device 11.

[0101] Even if the zone ECU 13 is unable to connect to the first communication bus 31 due to a malfunction in the first circuit 131, the user is unaware of this and performs the unlocking operation on the outside door handle as usual. Based on the detection of this outside action (S201), the first authentication device 11 performs the external key search in S202-S204. S202-S204 are identical to S102-S104 above, so their explanation is omitted.

[0102] If the first authentication device 11 confirms that a valid portable device 200 is in the entry area, it sends a key discovery report to the zone ECU 13 using the first communication bus 31 (S205). However, due to a malfunction in the first circuit 131 of the zone ECU 13, the data frame is not received properly, and communication frames originating from the zone ECU 13 do not flow on the first communication bus 31. The communication status determination unit G1 of the first authentication device 11 detects a communication interruption in the zone ECU 13 based on the fact that it has not received a communication frame transmitted from the zone ECU 13 for a certain period of time or longer (S205).

[0103] When the first authentication device 11 detects a communication interruption in the zone ECU 13, it sends a bypass request to the CGW 14 using the first communication bus 31 in S206. The bypass request is a communication frame that requests the CGW 14 to perform relaying (also called forwarding or bypassing) of the communication frame. In the diagram, BP means bypass, and the notation (BP) indicates that it is transmitted via the bypass path.

[0104] Here, relaying by CGW14 corresponds to enabling communication between the first authentication device 11 and the zone ECU 13 using the second communication bus 32. Relaying by CGW14 includes receiving a communication frame addressed to the zone ECU 13 that has been transmitted from the first authentication device 11 to the first communication bus 31 and transmitting it to the zone ECU 13 using the second communication bus 32. The communication frame addressed to the zone ECU 13 that has been transmitted from the first authentication device 11 to the first communication bus 31 is a communication frame with a predetermined ID, such as a key discovery report. Furthermore, relaying by CGW14 also includes CGW14 receiving a communication frame with a predetermined ID flowing on the second communication bus 32 and transmitting it to the zone ECU 13 using the second communication bus 32. Here, the communication frame with a predetermined ID flowing on the second communication bus 32 means a communication frame for the first authentication device 11 that the zone ECU 13 has sent to the second communication bus 32 (for example, a key search request). CGW14 should have the IDs of the communication frames to be relayed registered.

[0105] The relaying of communication frames may be achieved by reassigning IDs, for example, as shown in Figure 9. Figure 9 shows an embodiment of relaying frames from the first authentication device 11 to the zone ECU 13. In Figure 9, "X" is the ID for the first communication bus 31 used to transmit key discovery reports from the first authentication device 11 to the zone ECU 13, similar to Figure 6. "Y" is an alternative ID used by the CGW 14 for forwarding. The CGW 14 reassigns the ID of the frame received from the first authentication device 11 to a predetermined uplink forwarding ID and sends it to the second communication bus 32. The uplink forwarding ID ("Y") may be assigned in advance. The uplink forwarding ID may be set to a low priority value so as not to interfere with frames flowing to the original second communication bus 32.

[0106] The relay of communication frames from Zone ECU 13 to the first authentication device 11 may also be achieved by reassigning IDs. That is, as shown in Figure 10, CGW 14 receives a communication frame assigned a downlink / uplink forwarding ID ("B") prepared for the second network, replaces the downlink / uplink forwarding ID with the original ID ("A"), and sends it to the first communication bus 31. The original ID here refers to the ID used for frames that Zone ECU 13 transmits to the first authentication device 11 using the first communication bus 31. The downlink forwarding ID is the ID assigned to communication frames addressed to the first authentication device 11 that Zone ECU 13 sends to the second communication bus 32. The downlink forwarding ID ("B") may also be pre-set to a low priority value so as not to interfere with the original communication using the second communication bus 32.

[0107] The ID "Y" for uplink transfer and the ID "B" for downlink uplink transfer only need to be IDs with lower priority than the IDs used for communication using the original second communication bus 32. In other words, the uplink transfer ID and downlink uplink transfer ID may be IDs with lower priority than a predetermined reference ID. The reference ID is the ID with the lowest priority among the IDs that can be used in the second network (i.e., the assigned IDs). The uplink transfer ID and downlink uplink transfer ID may be the ID with the lowest priority and the ID with the second lowest priority. The CGW14 and zone ECU13 may each have an uplink transfer ID and a downlink uplink transfer ID registered.

[0108] In other embodiments, when the zone ECU 13 transmits a communication frame to the CGW 14 for the first authentication device 11, it may transmit the frame using an ID that is originally provided for the CGW 14. When the CGW 14 receives a communication frame from the zone ECU 13, it may determine whether the data is intended for the first authentication device 11 based on the contents of the data field. If the CGW 14 determines that the data is intended for the first authentication device 11, it may send a communication frame to the first communication bus 31 with an ID that can be received by the first authentication device 11 attached to the received data.

[0109] When CGW14 receives a bypass request from the first authentication device 11, it sends a bypass approval request to the zone ECU 13 using the second communication bus 32. The bypass approval request is a communication frame that inquires with the zone ECU 13 whether it is permissible to perform relaying by CGW14.

[0110] In this embodiment, the zone ECU 13 is configured to determine whether or not to allow relaying by the CGW 14 from the standpoint of application requirements. Application requirements refer to security requirements for the network on which the application operates. Here, the application can be understood as an application that primarily provides functions for unlocking and starting the engine based on the presence of a key device (hereinafter referred to as smart functions). Hereafter, an application that provides smart functions will also be referred to as a smart application.

[0111] Zone ECU 13 may be configured to reject relaying by CGW 14 if the security level of the second communication bus 32 does not meet the security level required by the smart application. More specifically, it may be configured to reject relaying by CGW 14 if an unknown node or a node with a low security level is connected to the second communication bus 32. Zone ECU 13 permits relaying by CGW 14 if the security level of the second communication bus 32 meets the security level required by the smart application (in other words, if the predetermined criteria are met).

[0112] The security level of the network may be evaluated in consideration of the characteristics of the nodes connected to the network. Zone ECU 13 may decide whether or not to allow relaying by CGW 14, taking into consideration the network requirements requested by the smart application and the characteristics of the second network. In addition, whether or not to allow relaying by CGW 14 may be pre-registered in Zone ECU 13. In this embodiment, it is assumed that Zone ECU 13 is pre-registered to allow relaying by CGW 14.

[0113] Furthermore, the zone ECU may be configured to switch whether or not to allow relaying depending on the content of the information being transmitted. For example, it may be configured to refuse relaying if the communication frame to be relayed contains the user's personal information (e.g., username), while allowing relaying if the communication frame to be relayed does not contain personal or confidential information.

[0114] If Zone ECU 13 permits relaying by CGW 13, it sends a bypass permission notification to CGW 14 using the second communication bus 32 in S208. The bypass permission notification is a communication frame indicating that relaying is permitted. The bypass permission notification may include the uplink and downlink IDs used for relaying. The uplink / downlink IDs are not fixed and may be dynamically determined or changed depending on the usage status of the second communication bus 32. If Zone ECU 13 does not permit relaying by CGW 13, it sends a bypass denial notification to CGW 14 using the second communication bus 32 in S208. The bypass permission notification and bypass denial notification correspond to signals that specify whether or not authentication data will be received via the relay device.

[0115] Upon receiving the bypass permission notification, CGW14 transmits a bypass start notification to the first authentication device 11 using the first communication bus 31 in S209. The bypass start notification is a communication frame that notifies CGW14 that it has started relaying.

[0116] Upon receiving the bypass start notification, the first authentication device 11 sends a key discovery report again. The ID of the key discovery report sent here may be the original ID (in other words, the ID addressed to the zone ECU 13). In other embodiments, it may be a different ID (for example, a specific ID that the CGW can receive). The CGW 14 receives the key discovery report sent from the first authentication device 11 to the first communication bus 31, changes the ID, and sends it to the zone ECU 13 via the second communication bus 32.

[0117] In this manner, the key discovery report transmitted by the first authentication device 11 is transmitted to the zone ECU 13 via a bypass route if there is a malfunction in the first circuit 131 of the zone ECU 13. The bypass route is a path that goes through the first communication bus 31, CGW 14, and the second communication bus 32.

[0118] Based on receiving the key discovery report, Zone ECU 13 unlocks the vehicle (S211). Subsequently, based on detecting user in-vehicle action (S212), Zone ECU 13 sends a key search request to the first authentication device 11 using the bypass route (S213). The process from S213 onward is the same as S110-S115, except that a bypass route is used for communication between the first authentication device 11 and Zone ECU 13.

[0119] With the above configuration, even if the zone ECU 13 is temporarily or permanently unable to access the first communication bus 31, the key discovery report is transmitted to the zone ECU 13 via a bypass route. Therefore, the user can unlock the vehicle and start the engine using normal vehicle operation. Even if the zone ECU 13 is unable to communicate directly with the first authentication device 11, the user can operate the vehicle in degraded mode, eliminating the need to arrange for a tow truck or request on-site maintenance. In short, the introduction of relay via CGW 14 improves user convenience.

[0120] Furthermore, in the above embodiment, the zone ECU 13 determines whether or not relaying by CGW14 is possible. As a comparative example of another possible configuration, a configuration in which CGW14 itself determines whether or not relaying is possible can be considered. However, CGW14 cannot recognize the confidentiality of the data it handles or the network requirements demanded by the smart application. In a configuration in which CGW14 determines whether or not relaying is possible, there is a risk that confidential information output by the first authentication device 11 may pass through a transmission path with a low security level.

[0121] In contrast to such comparative examples, according to the above embodiment, if a node with a low security level or an unknown node is connected to the second communication bus 32 used for bypassing, the zone ECU 13 can refuse relaying. With the above configuration, the zone ECU 13 can only permit relaying if the bypass route meets the security level required by the software that provides functions such as unlocking. This prevents the CGW 14 from arbitrarily starting to relay communications, thus maintaining the security level of the in-vehicle system 100. In other words, according to the above embodiment, the concerns of the comparative examples can be eliminated or mitigated.

[0122] Furthermore, the ID used for transferring communication frames will be an ID with a lower priority than the ID normally used on the second communication bus 32. This reduces the risk of affecting the original (in other words, existing) communication using the second communication bus 32.

[0123] The above describes a method of relaying communication frames by changing IDs, but the method of implementing relay (also called forwarding) is not limited to this. CGW14 may also implement relaying communication frames by encapsulating the communication frames. Encapsulation means storing the original communication frame in the data field of a communication frame adapted to another network and transmitting it. For example, as shown in Figure 11, CGW14 may encapsulate and forward the communication frame from the first authentication device 11 to the zone ECU 13. When relaying by encapsulation is performed, the zone ECU 13 may also encapsulate the communication frame destined for the first authentication device 11 and send it to the second communication bus 32.

[0124] With relaying via encapsulation, only one ID is needed for each source-destination combination, regardless of the content of the data being relayed. Therefore, the increase in IDs associated with relaying can be suppressed. However, encapsulation increases the frame length. Bus occupancy or utilization may increase. In cases where the second communication bus 32 is congested or where urgent communications are taking place, the zone ECU 13 may be configured to refuse relaying by the CGW 14.

[0125] Incidentally, the ID used for key discovery reports may be used for other purposes on the second communication bus 32. Therefore, if CGW14 sends the key discovery report to the second communication bus 32 as is without changing the ID or encapsulating it, there is a risk that the key discovery report may be received by an unintended device. Also, there is a possibility that the zone ECU 13 may not be able to receive the key discovery report. If the communication frame flowing on the first communication bus 31 is output to the second communication bus 32 as is without changing the ID or other means, it may affect existing (original) communication using the second communication bus 32. From the standpoint of the stability of existing communication and information security, it is preferable that CGW14 is configured to perform communication frame transfer by changing the ID or encapsulating it.

[0126] The above describes a configuration in which the communication status determination unit G1 of the first authentication device 11 detects that the zone ECU 13 is not in a state where it can communicate with the first authentication device 11 and issues a bypass request. However, the source of the bypass request is not limited to this. The CGW 14 may have a function equivalent to the communication status determination unit G1 and may be configured to issue a bypass request to the zone ECU 13.

[0127] The state determination unit F3 of the zone ECU 13 may be configured to periodically or at predetermined events determine whether it is in a state where it can communicate with the first authentication device 11 via the first communication bus 31. The zone ECU 13 may be configured to spontaneously send a bypass request to the CGW 14 if it determines that it is in a state where it cannot communicate with the first authentication device 11 via the first communication bus 31. The state where it is in a state where it cannot communicate with the first authentication device 11 may be detected by any method. The zone ECU 13 may determine that it is unable to communicate with the first authentication device 11 if it detects a malfunction in the first circuit 131 through its self-diagnostic function.

[0128] <Second example of operation during system malfunction> In a system configuration equipped with DCM15, if the zone ECU13 is not properly connected to the first communication bus 31, the zone ECU13 may perform user authentication via DCM15.

[0129] Figure 12 illustrates the operation of the in-vehicle system 100 in a pattern where the zone ECU 13 performs user authentication via the DCM 15 because the zone ECU 13 is unable to connect to the first communication bus 31. Figure 12 may correspond to a situation where a user possessing a portable device 200 attempts to unlock the vehicle by operating the outer door handle. That is, it may correspond to a situation where the first authentication device 11 performs an external key search and confirms that a valid portable device 200 is present in the entry area.

[0130] The sequence shown in Figure 12 may, as an example, be replaced with a step in S301 in which CGW14 detects that the key discovery report has not been successfully received by the zone ECU13. In S301, CGW14, upon learning that the key discovery report has not been successfully received by the zone ECU13, notifies the zone ECU13 of the unresponsive state using the second communication bus 32 in S302. The unresponsive state is a state in which the zone ECU13 is unresponsive to an unlocking operation by a legitimate user. In substance, the unresponsive state corresponds to a state in which the zone ECU13 fails to receive the key discovery report even though it has been transmitted.

[0131] Since Zone ECU 13 itself is not connected to the first communication bus 31, it cannot detect that a key discovery report is being sent to the first communication bus 31. Therefore, in this case, CGW 14 will notify Zone ECU 13 of an error in receiving the key discovery report. Of course, this is not the only way for Zone ECU 13 to recognize that it is unresponsive; various other methods, as described later, may be used.

[0132] When Zone ECU13 receives notification from CGW14 that it is unresponsive, it activates degraded mode in S303. Degraded mode is a mode that allows driving with restrictions. Degraded mode may also be called limp home mode or limp mode. The distance that can be driven in degraded mode may be limited. The distance that can be driven in degraded mode may be set to a value that allows the vehicle to be driven to home or a repair shop. The driving speed in degraded mode is limited to a predetermined value or less. When degraded mode is activated, Zone ECU13 allows user authentication in a way that is not normally permitted. Normal state is when degraded mode is not activated. Enabling / disabling degraded mode may be managed by a flag or similar.

[0133] When degraded mode is enabled, Zone ECU13 sends a malfunction notification to smartphone 300 at S304. The malfunction notification is a message that informs smartphone 300 that authentication information for unlocking cannot be obtained. The malfunction notification can also be referred to as an unlocking failure notification or an unlocking failure notification.

[0134] The malfunction notification may be sent to the smartphone 300 via short-range communication, or it may be transmitted to the smartphone 300 via cellular communication. Transmission via short-range communication may be achieved in cooperation with the second authentication device 12 using a bypass route. Transmission using cellular communication may be carried out using the DCM 15.

[0135] Upon receiving a malfunction notification from the vehicle, the vehicle operation application 310 on the smartphone 300 sends a status inquiry to the authentication server 400 in S305. The status inquiry is a message requesting confirmation of the vehicle's status. The status inquiry may be transmitted via cellular communication.

[0136] Upon receiving a status inquiry from the vehicle operation application 310, the authentication server 400 sends a code inquiry to the in-vehicle system 100 in S306. The code inquiry may be a signal requesting a vehicle status code. Here, the vehicle status code is a code that indicates the status of the vehicle. The vehicle status code may be, for example, a diagnostic trouble code (DTC). The code inquiry sent by the authentication server 400 is received by the DCM 15.

[0137] When DCM15 receives a code query, it returns a vehicle status code to the authentication server 400 in S307. DCM15 may also obtain network monitoring results from CGW14 to determine the vehicle status before sending the vehicle status code. Furthermore, DCM15 may be configured to share information equivalent to a DTC with zone ECU13 or CGW14 as needed.

[0138] Based on the receipt of the vehicle status code, the authentication server 400 verifies whether the vehicle is in a state where it can be driven, i.e., its safety for driving. If the zone ECU 13 is simply unable to communicate with the first authentication device 11, the vehicle may be judged to be in a state where it can be driven. Once it is confirmed that the vehicle is in a state where it can be driven, the authentication server 400 sends a confirmation message to the vehicle operation application 310 in S308. The confirmation message is a message to confirm with the user whether they wish to use the vehicle (unlock / start the engine).

[0139] Furthermore, if the authentication server 400 determines that the vehicle is not in a drivable condition, it may send a message to the vehicle operation application 310 indicating that the vehicle is unavailable. Alternatively, if the authentication server 400 determines that the vehicle is not in a drivable condition, it may arrange for a tow truck or on-site maintenance.

[0140] When the vehicle operation application 310 receives a confirmation message, it displays an input screen for the user to enter whether or not they wish to use the vehicle, and waits for user input. Subsequently, when the vehicle operation application 310 receives a response in S309 indicating that the user wishes to use the vehicle, it sends a response message indicating that the user wishes to use the vehicle to the authentication server 400 in S310. However, if the vehicle operation application 310 receives a response in S309 indicating that the user does not wish to use the vehicle, or if the user does not enter any input after a certain period of time has elapsed since the input screen was displayed (i.e., a timeout occurs), it may send a response message indicating that the user does not wish to use the vehicle to the authentication server 400 in S310 and terminate the sequence.

[0141] When the authentication server 400 receives a message from the vehicle operation application 310 indicating a desire to use the vehicle, it sends authentication information to the vehicle in S311. This authentication information is received and processed by the DCM 15 and transmitted to the zone ECU 13 via the CGW 14 and the second communication bus 32 (S312). The authentication information may be information that proves that a legitimate user is attempting to access the vehicle. The response message indicating a desire to use the vehicle or the status inquiry described above corresponds to a predetermined message that triggers the authentication server 400 to send the authentication information.

[0142] The Zone ECU 13 unlocks the vehicle and starts the engine based on the authentication information issued by the authentication server 400 (S313). Since the degraded mode is enabled, driving after the engine starts will be restricted. When the Zone ECU 13 detects that a user is seated in the driver's seat from signals such as the seat occupancy sensor, courtesy switch, seat belt sensor, and shift position sensor, it may display a screen on the in-vehicle display that directs the user to a nearby dealer or repair shop.

[0143] The above describes an example in which the vehicle operation application 310 receives a malfunction notification wirelessly and sends a status inquiry to the authentication server 400. However, the triggers for the vehicle operation application 310 to send a status inquiry are not limited to this. The first authentication device 11, the second authentication device 12, or the zone ECU 13 may display a malfunction notification image on the in-vehicle display if the key discovery report sent by the first authentication device 11 is not successfully received by the zone ECU 13. The malfunction notification image may be an image indicating that the unlocking function using the portable device 200 is unavailable due to a malfunction. Users outside the vehicle can often also see the screen displayed on the in-vehicle display. By displaying a malfunction notification image on the in-vehicle display, the user can be prompted to input a status inquiry via the vehicle operation application 310. Thus, the vehicle operation application 310 may be configured to send a status inquiry in S305 based on user operation.

[0144] When issuing authentication information for S311, the authentication server 400 may implement two-factor authentication using a mobile phone number, such as sending a password via Short Message Service (SMS) to a pre-registered mobile phone number. The authentication server 400 may also be configured to issue authentication information only after successful two-factor authentication.

[0145] Even with the above configuration, the user can still use the vehicle even if the zone ECU 13 is unable to communicate with the first authentication device 11. Furthermore, this example can handle not only malfunctions in the first circuit 131, but also malfunctions in the bus itself that provides the first communication bus 31 (e.g., open circuit or ground fault). This example is useful when the communication path from the DCM 15 to the zone ECU 13 is functioning normally.

[0146] Furthermore, detection of the failure to successfully receive the key discovery report in S301 may be performed by the first authentication device 11 or the second authentication device 12. S301 to S302 may be performed by the first authentication device 11 or the second authentication device 12. Failure to successfully receive the key discovery report by the zone ECU 13 may be detected by any device other than the zone ECU 13 connected to the first communication bus 31.

[0147] S304 may be replaced by the following operation by the second authentication device 12. That is, upon detecting that the key discovery report sent by the first authentication device 11 to the first communication bus 31 has not been properly received, the second authentication device 12 may send a malfunction notification to the smartphone 300 via short-range communication. Alternatively, S304 may include the process by which the CGW 14, upon detecting that the key discovery report has not been properly received by the zone ECU 13, sends a malfunction notification to the smartphone 300 via cellular communication using the DCM 15.

[0148] The above describes patterns in which the Zone ECU 13 recognizes an unresponsive state based on notifications from CGW 14, etc., but it is not limited to these. The Zone ECU 13 may use its self-diagnostic function to detect that it is unable to respond to the operator's input. For example, if the Zone ECU 13 detects a malfunction in the first circuit 131 using its self-diagnostic function, it will determine that it is in a first network disconnection state. The first network disconnection state is a state in which it cannot connect to the first communication bus 31, and can also be described as a disconnection state. The occurrence of the first network disconnection state may be detected by any method. The Zone ECU 13 may also determine that it is in a first network disconnection state if it detects that it cannot communicate normally with any device connected to the first communication bus 31. The first network disconnection state is not limited to malfunctions in the first circuit 131, but can also occur due to malfunctions in the first communication bus 31 itself.

[0149] When Zone ECU 13 detects that it is disconnected from the first network, it retains this information as an internal state. Whether or not it is disconnected from the first network may be managed by a flag or similar. For convenience, the flag indicating whether or not it is disconnected from the first network will be called the disconnection flag. When the disconnection flag is on, it means that it is disconnected from the first network, and when the disconnection flag is off, it means that it is not disconnected from the first network. If the disconnection from the first network is temporary, such as due to a poor contact in the stub, and Zone ECU 13 is able to reconnect to the first communication bus 31, the disconnection flag may be set to off.

[0150] Furthermore, if the zone ECU 13 detects that an unlocking operation has been performed while it is disconnected from the first network, it may activate degraded mode in S303. The zone ECU 13 may indirectly detect that an unlocking operation has been performed via the first authentication device 11 and CGW 14. In a configuration in which the zone ECU 13 can directly receive the output signal from the handle sensor 21, the zone ECU 13 may detect the unlocking operation based on the signal from the handle sensor 21. As described above, the sequence in Figure 12 may begin with the detection that the zone ECU 13 is in a state where it cannot connect to the first communication bus 31.

[0151] <Third example of operation during system malfunction> The second operational example requires the presence of a DCM15. However, depending on the vehicle specifications, a DCM15 may not be present. Furthermore, even in a system configuration with a DCM15, if the DCM15 itself malfunctions, the zone ECU13 will not be able to obtain the authentication information issued by the authentication server 400, and unlocking or engine starting will not be possible.

[0152] For these reasons, the in-vehicle system 100 may be configured to unlock (and subsequently start the engine) only when an error in receiving a key discovery report is observed, and only after the user has performed a specific pattern of operations on the vehicle. An example of the operation of an electronic key system for vehicles corresponding to this technical concept will be explained using Figures 13 and 14.

[0153] Figure 13 may also correspond to a situation where a user possessing the portable device 200 attempts to unlock the vehicle by operating the exterior door handle. In other words, it may correspond to a situation where the first authentication device 11 performs an external key search, and the first authentication device 11 itself has confirmed that a valid portable device 200 is present in the entry area.

[0154] The sequence shown in Figure 12 may begin, for example, with the CGW 14 detecting in S401 that the key discovery report transmitted by the first authentication device 11 has not been received and processed by the zone ECU 13 (hereinafter also referred to as a key discovery report reception error). When the CGW 14 detects a key discovery report reception error, it notifies the zone ECU 13 of this fact using the second communication bus 32. Note that S401 may be replaced with S301 to S302 mentioned above.

[0155] Based on receiving notification of a key discovery report reception error from CGW14, Zone ECU13 transitions to the degraded mode activation standby state in S402. The activation standby state corresponds to a state where the system awaits a predetermined operation by the user.

[0156] The user, upon discovering that the vehicle is not unlocked despite attempting to unlock it, voluntarily launches the vehicle operation application 310 and performs an operation to query the authentication server 400. When the vehicle operation application 310 receives the user's predetermined operation, it sends a query message via cellular communication in S404. The query message sent here may be a different message signal from the status query mentioned in the second operation example above. For example, the query message may be a message signal intended to inquire about the operation method. Of course, the query message may also be a message inquiring about the vehicle's status, similar to a status query.

[0157] Furthermore, upon detecting an error in receiving the key discovery report, the second authentication device 12 may send a malfunction notification to the smartphone 300 via short-range communication (S403). Based on receiving the malfunction notification via short-range communication, the vehicle operation application 310 may send a push notification of the malfunction, or it may display a pop-up screen for sending an inquiry message to the authentication server 400. In addition, upon detecting an error in receiving the key discovery report, the first authentication device 11, etc., may perform a process to display a malfunction notification image on the in-vehicle display. The malfunction notification image displayed here may include an image that guides the user through the operation of the vehicle operation application 310. This guides the user to launch the vehicle operation application 310.

[0158] In this example, when the authentication server 400 receives an inquiry message from the vehicle operation application 310, it sends a key operation guidance message back to the vehicle operation application 310 in S405. The key operation guidance message is a message indicating how to operate the portable device 200 to obtain vehicle status information. Vehicle status information is information indicating the status of the vehicle. The key operation guidance message includes information on a specific operation method for the portable device 200 to obtain vehicle status information. The operation method for the portable device to obtain vehicle status information corresponds to the zero-level key for the user to use the vehicle in an emergency.

[0159] When the vehicle operation application 310 receives a key operation guidance message from the authentication server 400, it displays the operation method for the portable device indicated in the message in S406. The operation method for the portable device to obtain vehicle status information may be pressing the unlock button and the lock button simultaneously. The operation method for the portable device to obtain vehicle status information may be pressing the unlock button and the lock button alternately a predetermined number of times, or holding both the unlock button and the lock button down for 5 seconds. For security reasons, the operation method for the portable device to obtain vehicle status information may differ for each vehicle model or for each individual vehicle. The operation method for the portable device to obtain vehicle status information may be registerable / changeable at a dealer shop, etc.

[0160] When the portable device 200 receives the above-mentioned specific operation for acquiring vehicle status information in S407, it transmits an information request signal, which is a specific command signal, to the first authentication device 11 via smart communication in S408. The information request signal is a UHF signal requesting the return of vehicle status information.

[0161] When the first authentication device 11 receives an information request signal transmitted from the portable device 200, it returns an LF signal indicating vehicle status information in S409. The vehicle status information may be expressed using a code (e.g., DTC) that describes the nature of the malfunction and the circumstances under which it occurred.

[0162] Regarding S409, the first authentication device 11 may be restricted to returning vehicle status information only when there is a system failure and the authentication of the portable device 200 has been successful. This reduces the risk of vehicle information leakage. When the first authentication device 11 receives an information request signal, if a certain amount of time has elapsed since the previous authentication, it may re-authenticate the portable device 200 upon receiving the information request signal. A system failure may mainly be a malfunction of the first communication bus 31 or a malfunction of the first circuit 131. In addition, to prevent information divergence, the first authentication device 11 may be configured to transmit an LF signal indicating vehicle status information only from the LF antenna that has received a response from the portable device 200 among multiple LF antennas.

[0163] When the portable device 200 receives vehicle status information transmitted from the in-vehicle system 100, it inputs the vehicle status information to the vehicle operation application 310 in S410 using a predetermined transmission method. Input of vehicle status information from the portable device 200 to the vehicle operation application 310 may be achieved, for example, by illuminating the indicator 204 with a flashing pattern corresponding to the content of the information. The flashing pattern for information transmission may be a combination of long flashes with a relatively long illumination duration and short flashes with a relatively short illumination duration, similar to Morse code. The flashing of light for information transmission may also be called a light signal. The vehicle operation application 310 may acquire vehicle status information by reading the flashing pattern using the camera 305. If the indicator 204 is configured to output light of multiple colors, the information may be represented (i.e., encoded) by a combination of the length of the illumination state and the color of the light.

[0164] Furthermore, if the portable device 200 is equipped with a speaker or buzzer and is configured to output sound, the input of vehicle status information from the portable device 200 to the vehicle operation application 310 may be achieved by beeping sounds with output patterns corresponding to the information content. The vehicle operation application 310 may decode the beeping sound pattern output from the portable device 200 using a microphone and acquire the vehicle status information. The information may be expressed by the length of the beeping sound.

[0165] In addition, if the portable device 200 is equipped with a short-range communication function, the portable device 200 may input vehicle status information to the vehicle operation application 310 via short-range communication. Furthermore, if the portable device 200 is equipped with a Near Field Communication (NFC) function, the portable device 200 may input vehicle status information to the vehicle operation application 310 via Near Field Communication. Near Field Communication here refers to communication with a communication range of several centimeters to 10 centimeters or less. From the perspective of the communication range, Near Field Communication can be understood as a different (different) communication method from short-range communication. As a similar concept, if the smartphone 300 is equipped with a TP transmitter, the vehicle operation application 310 may acquire vehicle status information from the portable device 200 via transponder communication.

[0166] When the vehicle operation application 310 obtains vehicle status information from the handheld device 200, it sends a status report message, which is a message indicating the vehicle status information, to the authentication server 400. Upon receiving the status report message, the authentication server 400 determines that a legitimate user is near the vehicle and determines that user authentication has been successful.

[0167] S404 to S411 can be understood as a sequence in which the authentication server 400 verifies that the user is in the vicinity of the vehicle in one phase. In addition, the authentication server 400 may perform additional authentication using a smartphone 300 or other device in S412. Additional authentication may be a two-factor authentication procedure using a phone number, such as sending a password via SMS and requesting the user to enter the password.

[0168] Furthermore, the authentication server 400 verifies whether the vehicle is in a drivable state based on the status report message received from the vehicle operation application 310. As mentioned above, if the zone ECU 13 is simply unable to communicate with the first authentication device 11, it may be judged as being in a drivable state. S404 to S411 are also sequences for verifying that the vehicle is in a safe drivable state.

[0169] Once user authentication and vehicle status verification are complete, the authentication server 400 sends a first operation guidance message to the vehicle operation application 310 at S420, as shown in Figure 14. The first operation guidance message is a message indicating how to operate the vehicle to activate degraded mode (also called the first vehicle operation). The first operation guidance message includes information on the first vehicle operation. This information on the first vehicle operation corresponds to the primary key for the user to use the vehicle in an emergency. If the authentication server 400 determines that the vehicle is not in a drivable state, it sends a message to the vehicle operation application 310 indicating that the vehicle is unavailable, or arranges for a tow truck or on-site maintenance.

[0170] When the vehicle operation application 310 receives a first operation guidance message from the authentication server 400, it displays the vehicle operation method indicated in the message (i.e., the first vehicle operation) in S421. The first vehicle operation includes multiple user actions. The first vehicle operation may be repeatedly pressing and releasing the outside door handle in accordance with the display on the smartphone 300 screen. The first operation method may be repeatedly pressing and releasing the outside door handle in accordance with the sound output from the smartphone 300.

[0171] Here, hands-on operation may involve placing a hand on the touch sensor that constitutes the handle sensor 21 (i.e., activating the sensor). Instead of hands-on operation, a push button provided on the outer door handle may be pressed. The first operation method may be a combination of external actions detectable by the Zone ECU 13, such as touching the touch sensor, pressing the push button, or placing a foot over the kick sensor. The first vehicle operation may, for example, involve gripping the driver's side outer door handle for 3 seconds or more, then gripping the right rear passenger's outer door handle for about 1 second, and then gripping the driver's side outer door handle again for 3 seconds or more. The parts being operated on may be different. Alternatively, external actions may be distinguished by the length of time hands-on operation is maintained. The Zone ECU 13 detects user operations on the vehicle based on signals from various in-vehicle sensors, such as the handle sensor 21.

[0172] When Zone ECU 13 begins accepting user input to the vehicle in S422, it determines in S423 whether the vehicle operations entered by the user match a first vehicle operation (also called the correct pattern) that has been pre-registered for the vehicle. If the series of vehicle operations entered by the user matches the first vehicle operation that has been pre-registered, Zone ECU 13 activates degraded mode in S424.

[0173] On the other hand, if a series of vehicle operations entered by the user does not match the first vehicle operations, the zone ECU 13 may return to the state before S402, or to a state where it can accept the first vehicle operations again. Considering the possibility of user errors, the input of the first vehicle operations may be configured to allow a certain number of attempts (e.g., 3 times). The success or failure of the input may be displayed on the in-vehicle display. If the user's operation pattern does not match the correct pattern, the zone ECU 13 may display a message on the in-vehicle display prompting the user to try again from the beginning. Notification of success / failure of input from the vehicle to the user may also be achieved by outputting a predetermined voice message / sound effect from the external speaker 25.

[0174] Furthermore, the Zone ECU 13 and the authentication server 400 have multiple operation patterns registered as correct patterns, and the authentication server 400 may randomly select one of the multiple operation patterns and send it to the vehicle operation application 310. The Zone ECU 13 may activate degraded mode based on whether the operation pattern entered by the user matches one of the multiple correct patterns.

[0175] When the Zone ECU 13 activates degenerate mode based on the first vehicle operation, it generates a random number, encodes the value of this random number, and outputs a sound code corresponding to the random value from the external speaker 25. The sound code may be a combination of long tones with a relatively long output time and short tones with a relatively short output time, like Morse code. In other words, the sound code may activate an external buzzer in a pattern corresponding to the random number. If the external speaker 25 is configured to output a variety of sounds, the sound code may be a combination of sounds with different lengths, pitches, and volumes.

[0176] The Zone ECU 13 may, prior to outputting the sound code, use the in-vehicle display or external speaker 25 to guide the user to enable the recording function of the vehicle operation application 310. The vehicle operation application 310 may automatically enable the recording function after displaying the first vehicle operation, or it may display a screen instructing the user to enable the recording function. The output of the sound code by the Zone ECU 13 may be repeated about three times at regular intervals to ensure that recording can begin in time.

[0177] If the vehicle operation application 310 successfully records the sound code in S426, it sends the recorded sound code data to the authentication server 400 in S427. When the authentication server 400 receives the sound code data from the vehicle operation application 310, it converts the sound code into a second vehicle operation, which is a combination of multiple operations, using a predetermined conversion logic (S428). It then sends a second operation guidance message indicating the second vehicle operation to the vehicle operation application 310 (S429). The second operation guidance message contains information about the second vehicle operation. This information about the second vehicle operation corresponds to a secondary key for the user to use the vehicle in an emergency.

[0178] When the vehicle operation app 310 receives a second operation guidance message from the authentication server 400, S430 displays the vehicle operation method indicated in the message. The second operation method may be the same as the first vehicle operation, involving performing multiple external actions in accordance with the display / voice guidance on the smartphone 300 screen.

[0179] Meanwhile, in parallel with the output of the sound code, the Zone ECU 13 uses the same conversion logic as the authentication server 400 to identify the operation pattern corresponding to the random value (or sound code) that was the source of the sound code. The operation pattern corresponding to the random value is the correct pattern corresponding to the second vehicle operation. The identification of the operation pattern may be performed after the output of the sound code.

[0180] When Zone ECU13 begins accepting user input to the vehicle in S431, it determines in S432 whether the vehicle operations entered by the user match the second vehicle operation, which is the correct pattern. If the series of vehicle operations entered by the user matches the second vehicle operation, Zone ECU13 enters an authenticated state in S433. Once Zone ECU13 transitions to the authenticated state, it responds to subsequent user operations by unlocking the vehicle and starting the engine. This allows the user to drive to a nearby dealership, repair shop, or their home.

[0181] According to this third operational example, even if the in-vehicle system 100 does not have a DCM 15 or if the DCM 15 malfunctions, the user can operate in degraded mode, eliminating the need to arrange for a tow truck or request on-site maintenance. In other words, maintenance costs can be reduced. Furthermore, if the smartphone 300 supports satellite communication, it can offer the advantage of allowing the user to operate in degraded mode even in situations where the DCM 15 is out of range and cannot connect to the authentication server 400 (for example, in a remote mountainous area).

[0182] Furthermore, when activating degraded mode, the authentication server 400 confirms whether the vehicle is in a drivable state and then sends the first vehicle operation guidance to the vehicle operation application 310. This reduces the risk of degraded mode being activated when the vehicle's driving safety cannot be guaranteed.

[0183] Furthermore, the in-vehicle system 100 confirms that a legitimate user is attempting to board the vehicle through communication with the handheld device 200, communication between the handheld device 200 and the vehicle operation application 310, and communication between the vehicle operation application 310 and the authentication server 400. This prevents anyone other than the user from boarding the vehicle.

[0184] If the series of vehicle operations input by the user in S431 does not match the second vehicle operation, the zone ECU 13 may return to a state where it can accept the second vehicle operation again. Considering the possibility of user errors, the input of the second vehicle operation may be configured to allow a certain number of attempts. The success or failure of the input may be displayed on the in-vehicle display. If the user's operation pattern does not match the correct pattern, the zone ECU 13 may display a message on the in-vehicle display prompting the user to input again from the beginning. If the input of the second vehicle operation fails more than a predetermined number of times, the zone ECU 13 may switch to warning mode and perform alarm processing such as outputting a buzzer as a warning sound. Note that S420 to S434 may be executed as additional authentication of S412 in a single phase.

[0185] The first and second vehicle operations correspond to specific vehicle operations. Note that the second vehicle operation is not mandatory, and the in-vehicle system 100 may transition to an authenticated state upon receiving input for the first vehicle operation. S425 to S432 may be omitted.

[0186] <Supplement (1)> The vehicle electronic key system does not need to be configured to perform all the operation patterns described in the first, second, and third operation examples. The vehicle electronic key system may be configured to perform one or two of the first, second, and third operation examples. Furthermore, if the vehicle electronic key system is configured to perform all of the first, second, and third operations, the procedure shown in Figure 15 may be used to determine which pattern to operate in. That is, if the zone ECU 13 is not in a state to receive a key discovery report normally, S501 may be used to determine whether relaying by CGW 14 is permissible, considering the application requirements. If relaying by CGW 14 is permissible (S501 YES), S502 may be used to perform control according to the first operation example.

[0187] If relaying by CGW14 is not permitted (S501 NO), it may be determined in S503 whether DCM14 is available. The state in which DCM14 is available essentially corresponds to a state in which the zone ECU13 can communicate data with the authentication server 400 using DCM14. The state in which DCM14 is available may be that DCM14 is installed in the vehicle and is operating normally. If DCM14 is not installed in the vehicle or if DCM14 is unable to communicate with the authentication server 400, DCM14 may be determined to be unavailable. The state in which DCM14 is unavailable may include not only cases where DCM14 is faulty, but also cases in which DCM14 and the authentication server 400 cannot communicate due to a cellular network anomaly or being out of range.

[0188] If DCM14 is available (S503 YES), control according to the second operating example may be performed in S504. On the other hand, if DCM14 is unavailable, control according to the third operating example may be performed in S505. Various decisions may be made by any device mounted on the in-vehicle system 100. For example, the zone ECU 13 may make the decisions in S501 and S503.

[0189] With the above configuration, it becomes possible to handle a variety of situations, potentially increasing user convenience. Furthermore, by prioritizing the application of the first operational example as much as possible, the effort required from the user can be reduced, potentially increasing user convenience.

[0190] <Supplement (2)> The communication methods of the first communication bus 31 and the second communication bus 32 are not limited to CAN and may be other communication methods. The first authentication device 11, the second authentication device 12, or the CGW 14 may detect that the zone ECU 13 is not in a state to communicate with the first authentication device 11 via the first communication bus 31 if the zone ECU 13 does not return a reception response after the first authentication device 11 has sent a key discovery report, or by periodic connectivity checks.

[0191] Furthermore, the CGW14, as a relay device, may be configured to relay communication frames in a manner compatible with the communication methods of the first communication bus 31 and the second communication bus 32. For example, the CGW14 may forward the communication frame transmitted by the first authentication device 11 to the second communication bus 32 using header addition / replacement, protocol conversion, etc. The CGW14, as a relay device, may be directly connected to the first authentication device 11 by a cable for one-to-one communication, rather than via the first communication bus 31. The term "communication frame" may be replaced with "message," "signal," "packet," "dataset," "data unit," etc.

[0192] Functional units (hereinafter also referred to as determination units) that detect whether the zone ECU 13 is not in a state where it can communicate with the first authentication device 11, such as the communication status determination unit G1, the communication status determination unit H1, and the status determination unit F3, may be provided in any of the in-vehicle devices. The in-vehicle system 100 only needs to have at least one in-vehicle device that functions as a determination unit. For example, one or two of the communication status determination unit G1, the communication status determination unit H1, and the status determination unit F3 may be omitted.

[0193] <Additional Note> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowchart and the order of execution of processes can be changed as appropriate. The controls shown in each flowchart may be combined and executed in parallel to the extent that they do not contradict each other. Expressions such as acquisition, determination, detection, generation, and calculation may be used interchangeably. When a device acquires certain data, it may also include the device generating that data based on signals input from other devices / sensors. [Explanation of Symbols]

[0194] 100 In-vehicle system, 200 Handheld device, 300 Smartphone, 310 Vehicle operation app, 400 Authentication server (server), 11 First authentication device (authentication device), 13 Zone ECU (control unit), 14 CGW (relay device), 15 DCM (wireless communication device), 31 First communication bus (first transmission path), 32 Second communication bus (second transmission path)

Claims

1. An authentication device (11) that authenticates a portable device by communicating wirelessly with the portable device, A device configured to perform vehicle control, such as unlocking or starting a vehicle, comprising a control device (13) connected to the authentication device by a first transmission line (31), A vehicle control system comprising a relay device (14) which is wiredly connected to the authentication device and connected to the control device by a second transmission line (32), When the authentication device authenticates the portable device, it transmits authentication data indicating the authentication result to the control device via the first transmission path. The control device performs the vehicle control based on receiving the authentication data from the authentication device via the first transmission line. If the control device is not in a state where it can communicate with the authentication device, the relay device transmits the authentication data sent by the authentication device to the first transmission path to the control device using the second transmission path. A vehicle control system configured such that the control device also performs the vehicle control when it receives the authentication data from the relay device via the second transmission line.

2. The control device includes a determination unit (G1, H1, F3) that determines whether it is in a state where it can communicate with the authentication device. The vehicle control system according to claim 1, wherein the relay device is configured to relay the authentication data based on the determination unit's determination that the control device is not in a state to communicate with the authentication device.

3. The vehicle control system according to claim 2, wherein the determination unit is configured to monitor the first transmission path and determine that the control device is not in a state to communicate with the authentication device based on the fact that the communication frame corresponding to the authentication data is not properly received or that the state of not receiving the communication frame transmitted from the control device continues for a certain period of time or longer.

4. The vehicle control system according to claim 1, wherein, if the control device is not in a state where it can communicate with the authentication device, the control device is configured to transmit a signal to the relay device indicating whether or not to receive the authentication data via the relay device.

5. The communication using the second transmission path is a communication method in which communication frames are sent and received according to the priority set in the communication frame. The relay device is, The vehicle control system according to any one of claims 1 to 4, wherein when the authentication data is output to the second transmission path, the communication frame corresponding to the authentication data is configured to have a lower priority than other communication frames flowing through the second transmission path.

6. An authentication device (11) that authenticates a portable device by communicating wirelessly with the portable device, A device configured to perform vehicle control, such as unlocking or starting a vehicle, comprising a control device (13) wired to the authentication device, A vehicle control system comprising a wireless communication device (15) for data communication with a server, The wireless communication device is connected to the control device in a manner that enables data communication. The authentication device transmits authentication data indicating the authentication result of the portable device to the control device. The control device performs the vehicle control based on the receipt of the authentication data from the authentication device. If the control device is not in a state where it can communicate with the authentication device, the wireless communication device receives authentication information from the server indicating that a legitimate user is trying to use the vehicle and provides it to the control device. The control device is configured to perform the vehicle control even when it receives the authentication information from the wireless communication device.

7. The control device further comprises determination units (G1, H1, F3) that determine whether the control device is in a state where it can communicate with the authentication device. The determination unit monitors the communication frames flowing through the transmission path used for communication between the authentication device and the control device, and determines that the control device is not in a state where it can communicate with the authentication device if a predetermined communication frame corresponding to the authentication data is not properly received, or if the state of not receiving communication frames transmitted from the control device continues for a certain period of time or longer. The vehicle control system according to claim 6, wherein the wireless communication device is configured to relay the authentication data based on the determination unit's determination that the control device is not in a state where it can communicate with the authentication device.

8. The system further includes a vehicle operation app (310), which is application software for operating the vehicle and is executed on a portable information processing terminal. When the vehicle operation application receives input indicating that the vehicle cannot be unlocked, it sends a predetermined message to the server. The vehicle control system according to claim 6 or 7, wherein the server is configured to transmit the authentication information to the wireless communication device based on the receipt of the predetermined message from the vehicle operation application.

9. An authentication device (11) that authenticates a portable device by communicating wirelessly with the portable device, A device configured to perform vehicle control, such as unlocking or starting a vehicle, comprising a control device (13) wired to the authentication device, A vehicle control system comprising a vehicle operation app (310), which is application software for operating the vehicle and is executed on a portable information processing terminal, The authentication device transmits authentication data indicating the authentication result of the portable device to the control device. The control device performs the vehicle control based on the receipt of the authentication data from the authentication device. The aforementioned vehicle operation application communicates with a predetermined server based on user operations, obtains information indicating a specific vehicle operation, and presents it to the user. A vehicle control system configured such that the control device also performs the vehicle control when it detects that a specific vehicle operation has been performed based on a signal from an on-board sensor, even when it is not in a state where it can communicate with the authentication device.

10. When the vehicle operation application receives input indicating that the vehicle cannot be unlocked, it communicates with a predetermined server to obtain information indicating a first vehicle operation for using the vehicle and presents it to the user. When the control device is not in a state where it can communicate with the authentication device, and detects that the first vehicle operation has been performed based on a signal from an on-board sensor, it executes a process to input a predetermined code into the vehicle operation application. When the vehicle operation application obtains the code, it transmits the code to the server, thereby obtaining information indicating a second vehicle operation corresponding to the code and presenting it to the user. The vehicle control system according to claim 9, wherein the control device is configured to perform the vehicle control based on detection that the second vehicle operation has been performed based on a signal from the on-board sensor.

11. When the vehicle operation application receives input indicating that the vehicle cannot be unlocked, it sends a predetermined message to the server, thereby receiving a specific operation method for the portable device to obtain vehicle status information from the server and presenting it to the user. The portable device, when an operation is performed according to the specific operating method, transmits a signal to the authentication device requesting the transmission of the vehicle status information. Based on receiving a request from the portable device, the authentication device transmits the vehicle status information to the portable device. When the portable device receives the vehicle status information from the authentication device, it inputs the vehicle status information into the vehicle operation application using a predetermined transmission method. The vehicle control system according to claim 9, wherein the vehicle operation application is configured to transmit the vehicle status information to the server, receive information indicating the specific vehicle operation from the server, and present it to the user.

12. The vehicle control system according to claim 11, wherein the authentication device is configured to transmit the vehicle status information in response to a request from the portable device only when it is unable to communicate with the control device.

13. The vehicle control system according to claim 11, wherein the predetermined transmission method is one that uses flashing lights, one that uses sound output patterns, or one that uses wireless communication.

Images