JP2024017804A - In-vehicle equipment, roadside equipment, road-to-vehicle communication systems - Google Patents

Abstract

The present invention provides an on-vehicle device, a roadside device, and a road-to-vehicle communication system that allows an on-vehicle device to easily recognize in advance whether or not a roadside device ahead is operating normally. SOLUTION: When an on-vehicle device 2 receives a message from an RSU 1, it compares time information indicated in the received message with time information held by itself. Then, based on the fact that the difference between the two pieces of time information is greater than or equal to a predetermined value, the in-vehicle device determines that a problem has occurred in the RSU 1 corresponding to the distribution source. Furthermore, the vehicle-mounted device 2 determines whether the RSU 1 determined to have a problem is a stand-alone RSU 1 based on a message received from the RSU 1, map data, or the like. When the in-vehicle device 2 detects that a problem has occurred in the stand-alone RSU 1, it notifies the management server and in-vehicle devices around the own vehicle of this fact. [Selection diagram] Figure 1

Description

The present disclosure relates to an in-vehicle device, a roadside device, and a road-to-vehicle communication system that performs road-to-vehicle communication.

Patent Document 1 discloses a road-to-vehicle communication system in which a roadside device distributes support information related to crossing an intersection to an on-vehicle device. The roadside device here is communication equipment that is placed along the road and performs road-to-vehicle communication. The roadside unit may also be called an RSU (Roadside Unit). The support information related to passing through an intersection includes information related to the presence of an oncoming vehicle, information indicating the shape of the intersection, and the like. Based on entering the service area (communication area) of the roadside device, the on-vehicle device receives support information from the roadside device, provides information to the driver, and performs driving support control such as automatic acceleration/deceleration/steering. I can do it.

In addition, in 3GPP (registered trademark), a communication control method for realizing cellular V2X is being studied (Non-Patent Document 1).

Japanese Patent Application Publication No. 2002-269699

3GPP TS 36.000 V16.7.0 (2021-12) 3rd Generation Partnership Project, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 16)”

Roadside machines are often configured to be able to communicate data with a management center via a wide area communication network. The roadside machines that are communicatively connected to the management center can be monitored by the management center to see if they are operating normally. If the management center knows what is happening with the roadside device, the management center can notify each vehicle-mounted device of the operating state of the roadside device. The on-vehicle device may be able to recognize whether or not the roadside device in front is operating normally based on the notification from the management center. The forward roadside device corresponds to a roadside device installed in a road section that the vehicle-mounted device will pass within a predetermined period of time.

On the other hand, in recent years, consideration has been given to introducing stand-alone roadside devices that do not communicate with a management center. While stand-alone roadside devices have the advantage of being able to reduce costs and maintenance costs and are easy to install/remove, it is difficult for administrators to recognize that a malfunction has occurred. Furthermore, if the management center is unable to grasp what is occurring in the roadside device, the management center cannot notify each vehicle-mounted device of the fact. From the on-vehicle device's perspective, it cannot recognize that a problem has occurred in the roadside device in front of it until it comes within the communication range of the roadside device in front of it.

The present disclosure has been made based on the above considerations and points of view, and one of its purposes is to provide an on-vehicle device that allows the on-vehicle device to easily recognize in advance whether or not the roadside device in front is operating normally. , roadside units, and road-to-vehicle communication systems.

The in-vehicle device disclosed herein is an in-vehicle device configured to be able to perform road-to-vehicle communication, and includes a roadside device detection unit (G31) that detects a roadside device that is a roadside device located in front of the own vehicle; A malfunction detection unit (G3) detects a malfunction in the forward roadside machine based on the data received from the forward roadside machine or the reception status of the signal from the forward roadside machine, and the malfunction detection unit detects a malfunction in the forward roadside machine. The present invention further includes a notification processing unit (G4) that performs notification processing that is processing for notifying other on-vehicle devices existing around the host vehicle of a malfunction in the roadside device ahead based on the fact that the roadside device has failed.

According to the above configuration, even if a problem occurs in a standalone roadside device, the occurrence of the problem will be detected by the on-vehicle device and notified to other on-vehicle devices around the own vehicle. . Therefore, each vehicle-mounted device can easily recognize that a problem has occurred in the roadside device ahead based on the notification from the vehicle-mounted device mounted on the preceding vehicle.

Further, the roadside device of the present disclosure is a roadside device that is a communication equipment installed along a road and is configured to be able to directly perform wireless communication with an in-vehicle device using a predetermined method, and receives information from the in-vehicle device. A self-diagnosis unit (F2) determines whether or not the unit itself is operating normally based on the content of the data, and based on the self-diagnosis unit detecting a malfunction, it sends a message to the in-vehicle device to detect the malfunction. It includes a status notification unit (F3) that transmits a failure notification message that is a message indicating that a failure has occurred.

According to the above roadside device, the roadside device sends the self-diagnosis results to the onboard device, so the onboard device can check whether the roadside device as the communication partner is operating normally or if there is a problem. becomes recognizable.

The road-to-vehicle communication system of the present disclosure includes a roadside device (1) that is communication equipment installed along a road, and an on-vehicle device (2) that is configured to be able to directly perform wireless communication with the roadside device in a predetermined manner. A road-to-vehicle communication system comprising: a self-diagnosis unit (F2) in which the roadside device determines whether or not it is operating normally based on the content of data received from the on-vehicle device; The in-vehicle device includes a status notification unit (F3) that transmits a malfunction notification message, which is a message indicating that a malfunction has occurred, to the in-vehicle device based on the detection of a malfunction by the self-diagnosis unit; , a notification processing unit that executes notification processing, which is processing for notifying other in-vehicle devices around the own vehicle that a problem has occurred in the roadside device, based on receiving the problem notification message ( G4).

According to the above road-vehicle communication system, the on-vehicle device can easily recognize that a problem has occurred in the roadside device ahead.

Note that the numerals in parentheses described in the claims indicate correspondence with specific means described in the embodiments described later as one aspect, and limit the technical scope of the present disclosure. isn't it.

1 is a diagram for explaining the overall image of a road-to-vehicle communication system. FIG. 6 is a diagram illustrating an example of assigning codes to various states of an RSU. FIG. 2 is a block diagram showing an example of the configuration of an independent RSU. FIG. 3 is a functional block diagram of an RSU control unit. FIG. 3 is a diagram for explaining the structure of an RSU message. 7 is a flowchart regarding reference image registration processing. It is a flowchart of image-based diagnosis processing. It is a flowchart of time-based diagnosis processing. FIG. 1 is a block diagram showing the configuration of an in-vehicle system. FIG. 3 is a functional block diagram of a control module. FIG. 3 is a diagram for explaining the operation of a recording processing section G2. It is a figure which shows an example of the content of RSU data. FIG. 3 is a diagram for explaining the configuration of a defect detection message. FIG. 2 is a flowchart for explaining the operation of the on-vehicle device for reporting a malfunction to the management server. FIG. It is a flowchart of GNSS system diagnosis processing. It is a flowchart of wireless function diagnosis processing.

Hereinafter, one embodiment of the road-to-vehicle communication system Sys of the present disclosure will be described using figures. The road-to-vehicle communication system Sys includes a plurality of RSUs (Roadside Units) 1, a plurality of on-vehicle devices 2, and a management server 3, as shown in FIG.

The RSU 1 is a wireless communication facility placed along a road, and is configured to be able to perform short-range communication. Short range communication in the present disclosure refers to communication directly performed between devices. Short-range communication refers to communication based on a predetermined wireless communication standard in which the actual communication distance is, for example, about 150 m or 250 m.

Any short range communication standard can be adopted, such as DSRC (Dedicated Short Range Communications) that supports the IEEE802.11p standard, WAVE (Wireless Access in Vehicular Environment), and cellular V2X (PC5/SideLink). . IEEE (registered trademark) is an abbreviation for Institute of Electrical and Electronics Engineers and refers to the Institute of Electrical and Electronics Engineers.

Short range communication may be implemented in accordance with communication standards for V2X. V2X is an abbreviation for Vehicle to X, and refers to communication technology that connects vehicles to various things. The first letter "V" in V2X refers to the vehicle/in-vehicle device 2 as the own vehicle, and "X" refers to various entities other than the vehicle, such as pedestrians, other vehicles, RSU 1, networks, servers, etc. I can point to it. "X" can be interpreted as Everything/Something.

RSU1 is sometimes called a roadside unit. Communication between the RSU 1 and the vehicle-mounted device 2 can also be called road-to-vehicle communication or V2I communication. "I" in V2I is an abbreviation for Infrastructure and refers to RSU1. In this disclosure, a message (wireless signal) compliant with the short range communication standard is referred to as a V2X message. Further, the V2X message directed from the RSU 1 to the on-vehicle device 2 will also be referred to as an RSU message.

The RSU 1 distributes support data, which is information for supporting driving operation/automatic driving, to the on-vehicle device 2. The support data is, for example, a data set indicating information on moving objects/obstacles existing within a predetermined distance from an intersection, road surface conditions, and the like. Since the support data is data indicating the traffic situation near the intersection where the RSU 1 is installed, it can also be called intersection-related data. The support data may be a data set indicating the traffic situation near the merging/branching point of the expressway. The contents of the support data may differ depending on the installation location of the RSU 1. Note that in this disclosure, a collection of data regarding a plurality of items is referred to as a data set. The description of data set can also be replaced with data unit/package/message/packet/frame, etc.

Among the plurality of RSUs 1, there may be an RSU 1 that is communicatively connected to the management server 3, and a so-called stand-alone (SA: stand-alone) type RSU 1 that is not connected to the management server 3. In this disclosure, the RSU 1 that is communicatively connected to the management server 3 will be referred to as a connected RSU 1B, and the RSU 1 that cannot communicate with the management server 3 will also be referred to as an independent RSU 1A. The independent RSU 1A can also be called a stand-alone RSU/stand-alone roadside unit. The independent RSU 1A can include an RSU 1 that is temporarily/accidentally out of communication with the management server 3 due to a communication line malfunction.

The connection type RSU 1B communicates with the management server 3 via a WAN (Wide Area Network) 9, for example. The WAN 9 is, for example, a TCP (Transmission Control Protocol)/IP (Internet Protocol) network such as the Internet. WAN 9 may also be other types of communication networks. The connection type RSU 1B may be connected to the management server 3 via a virtual/substantive private network/dedicated line. Further, some of the RSUs 1 may be configured to be able to communicate indirectly with the management server 3 through road-to-road communication. Road-to-road communication refers to short-range communication between RSUs 1. The connected RSU 1B corresponds to a network connected roadside unit.

RSU1 can be placed at any location along the road. Along the road here includes not only the sides of the road but also the sky above the road surface. Further, the RSU 1 may be installed as a marker buried in the road surface.

The RSU 1 may be realized, for example, as a multifunctional utility pole equipped with devices such as cameras, sensors, and communication equipment for detecting vehicles and pedestrians around intersections. In one embodiment, the RSU 1 detects pedestrians and vehicles approaching an intersection in real time, and transmits data indicating the position of the detected object to the on-vehicle device 2.

The pole-shaped RSU 1 may also be called a smart pole, an ITS (Intelligent Transport Systems) pole, or the like. Of course, the shape of the RSU 1 is not limited to the pole shape, but may be a box shape, a signboard shape, or the like. The RSU 1 may be additionally installed on a utility pole or the like. RSU1 may be portable.

Each RSU 1 is set with a monitoring area, which is a range to which objects are detected, and a distribution area, which is a range to which support data is to be distributed. The distribution area can also be called a service target area, a service spot, or the like. The RSU 1 uses a camera 15, etc., which will be described later, to identify the position, speed, moving direction, type, etc. of a moving object within the monitoring area. The moving objects include pedestrians, kickboards, vehicles, and the like. Vehicles include bicycles, motorized bicycles, electric scooters, motorcycles, etc.

The monitoring area and the distribution area may be the same or different. The monitoring area of the RSU 1 placed at an intersection can be designed as appropriate, taking into account the shape of the intersection where the RSU 1 is installed. Similarly, the distribution area can be designed according to the characteristics of the location where the RSU 1 is installed. For example, the RSU 1 located at an intersection detects a moving object existing within a predetermined distance from the intersection, and delivers information on the detected moving object to the on-vehicle device 2 within a predetermined distance from the intersection.

The on-vehicle device 2 is a communication device that performs wireless communication with other vehicles and the RSU 1. The on-vehicle device 2 is installed and used in each of a plurality of vehicles. The vehicle-mounted device 2 is configured to be capable of short-range communication with other vehicle-mounted devices 2 and the RSU 1. Although FIG. 1 shows only one vehicle equipped with the on-vehicle device 2, two or more vehicles may actually exist in the entire system. In this disclosure, for a certain in-vehicle device 2, the vehicle in which the in-vehicle device 2 is mounted is also referred to as the own vehicle, and the vehicles other than the own vehicle are also referred to as other vehicles.

In addition, in the present disclosure, in order to distinguish the in-vehicle device 2 from other in-vehicle devices 2, the in-vehicle device 2 may be referred to as its own device, and the in-vehicle device 2 used in another vehicle may also be referred to as another device. be. Since the vehicle and the on-vehicle device 2 have a one-to-one relationship, the expression "vehicle" as a source/destination of wireless signals/data/packets, etc. can be read as "on-vehicle device". Therefore, the description of own vehicle/other vehicle in the following description may be interpreted as self vehicle/other vehicle.

Each vehicle-mounted device 2 periodically transmits a vehicle status message indicating information about the vehicle through short-range communication. For example, each vehicle-mounted device 2 can periodically transmit messages indicating transmission source information, transmission time, current position, traveling direction, traveling speed, acceleration, steering angle, turn signal/wiper operating state, etc. as own vehicle status messages. The message transmitted by the onboard device 2 may be a CAM (Cooperative Awareness Message) defined in the ETSI standard TS 102 637-2 or a BSM (Basic Safety Message) defined in the SAE standard J 2735. Each message may include information indicating the time of transmission.

Furthermore, each vehicle-mounted device 2 may transmit a message indicating information regarding the surrounding environment using detection of a predetermined event as a trigger. The message transmitted by the on-vehicle device 2 may be an event message such as DENM (Decentralized Environmental Notification Message) defined in the ETSI standard TS 102 637-3.

The management server 3 is a facility that manages the RSU 1. The management server 3 corresponds to a management device. The management server 3 can diagnose whether or not the connected RSU 1B is operating normally by bidirectionally communicating with the connected RSU 1B via the WAN 9, for example. Examples of diagnostic methods include the watchdog timer method and the homework answer method. The watchdog timer method means that if the watchdog timer of the monitoring device expires without being cleared by the watchdog pulse input from the monitored device, a malfunction will occur in the monitored device. This method determines that In the homework answer method, the monitoring device sends a predetermined monitoring signal to the monitored device, and the monitoring device determines whether the answer returned from the monitored device is correct or not. This method determines whether or not the system is operating properly. In the homework response method, the monitored device generates a response signal according to the monitoring signal input from the monitoring device and sends it back to the monitoring device. Here, the management server 3 corresponds to a monitoring side device, and the connection type RSU 1B corresponds to a monitored side device.

Note that each RSU 1 may be provided with a self-diagnosis function, which will be described later. Regarding the connected RSU 1B, the management server 3 may recognize the status of the reporting source by receiving the self-diagnosis results reported from the RSU 1. Furthermore, the management server 3 can recognize the status of the independent RSU 1A based on a report from the on-vehicle device 2, as described later.

The status of the RSU 1 indicates whether it is operating normally or whether some functions are malfunctioning. The status of the RSU 1 can be classified into five patterns, for example, (A) normal, (B) camera malfunction, (C) GNSS malfunction, (D) radar malfunction, and (E) other malfunction. Note that a defect here refers to a state that is not normal. A malfunction can be expressed as a failure, a failure, or an abnormality.

"Camera malfunction" means that a malfunction has occurred in the camera included in the RSU 1. "GNSS malfunction" means that a malfunction has occurred in the GNSS receiver included in the RSU 1. GNSS is an abbreviation for Global Navigation Satellite System, which means a global positioning satellite system. As the GNSS, GPS (Global Positioning System), GLONASS, Galileo, IRNSS, QZSS, Beidou, etc. can be adopted.

"Radar malfunction" means that a malfunction has occurred in the millimeter wave radar/LiDAR included in the RSU 1. LiDAR is an abbreviation for Light Detection and Ranging or Laser Imaging Detection and Ranging. The LiDAR concept can include Time of Flight (ToF) cameras that use the round trip time of light to generate distance images. Note that a ToF camera malfunction may be classified as a camera malfunction. "Other defects" indicates a defect in a location other than the above, or the cause is unknown. In addition to "other malfunctions," a category of "unknown cause" may be provided.

The status of RSU1 can be expressed by a predetermined number of bit strings/codes. In this embodiment, as an example, the status code is expressed in 4 bits. For example, as shown in FIG. 2, "normal" is associated with 0000, "camera malfunction" with 0001, "GNSS malfunction" with 0010, "radar malfunction" with 0100, "other malfunction" with 1000, etc. The above setting example (assignment example) corresponds to a configuration in which defect points are assigned to each bit. That is, the position of the bit where "1" is set indicates the location where the problem occurs. In the above example, the camera is assigned to the fourth bit (right end), the GNSS receiver is assigned to the third bit, the millimeter wave radar is assigned to the second bit, and the other parts are assigned to the first bit. Of course, the status code may be composed of 6 bits or 8 bits.

If a malfunction is detected at multiple locations in the RSU 1, multiple bits corresponding to the malfunction locations may be set to 1 in the status code. For example, the status code may be set to 0011 when there is a problem with the camera and GNSS receiver. The status code may be expressed as a logical sum of status codes for each location where the problem occurs. A preliminary code (for example, 1000) may be prepared as a status code.

As the status code of the RSU 1, codes corresponding to "sonar malfunction" indicating a sonar malfunction, "jamming radio wave detected" indicating that radio wave interference is being received, etc. may be prepared. Furthermore, if various types of cameras are assumed as cameras, such as color cameras, infrared cameras, and ToF cameras, "camera malfunctions" may be subdivided according to the types. The status of RSU1 may be evaluated in two stages: normal/failure.

Note that when the management server 3 detects a malfunction in a certain RSU 1, it may perform a process of notifying the operator using a display, a speaker, or the like. The operator refers to a staff member who is engaged in operations related to OAM (Operation Administration and Maintenance) of the RSU1. Furthermore, the management server 3 distributes information about the RSU 1 in which a problem has occurred to the on-vehicle device 2 that is moving toward the RSU 1. Information distribution to the on-vehicle device 2 may be carried out by road-to-vehicle communication using another RSU 1, or may be carried out by cellular communication. The on-vehicle device 2 may obtain information about the RSU 1 in which the problem is occurring from the management server 3. Moreover, the management server 3 may distribute not only the data of the RSU 1 in which the problem has occurred, but also data indicating whether the RSU 1 is operating normally or not to each vehicle-mounted device 2.

<About RSU configuration and functions>
Here, the configuration and functions of the RSU 1 will be explained using the independent RSU 1A as an example. As shown in FIG. 3, the independent RSU 1A includes an RSU control section 11, a radio section 12, a GNSS receiver 13, a millimeter wave radar 14, a camera 15, and an image analysis section 16.

The RSU control unit 11 is a module that controls the operation of the entire RSU 1. The RSU control unit 11 is configured to be able to communicate with each of the wireless units 12 and the like. The RSU control unit 11 is configured as a computer including, for example, a processor 111, a memory 112, a storage 113, an input/output circuit (I/O) 114, and the like. The processor 111 is, for example, a CPU (Central Processing Unit). The memory 112 is, for example, a volatile storage medium such as a RAM (Random Access Memory). By accessing the memory 112, the processor 111 executes various processes for realizing the functions of each functional unit, which will be described later. The storage 113 includes a nonvolatile storage medium such as a flash memory. The storage 113 stores RSU programs that are programs for realizing various functions/services. The input/output circuit 114 is a circuit module through which the RSU control unit 11 transmits and receives signals to and from other devices.

In this disclosure, for the RSU control unit 11, the RSU 1 that accommodates itself is also referred to as its own unit/affiliate unit. Further, RSU1 other than the affiliated unit is also referred to as other unit. The functions of the RSU control unit 11 will be described later.

The wireless unit 12 is a communication module for implementing short range communication. The radio section 12 includes an antenna, a transmission processing section, and a reception processing section. The antenna is an antenna for transmitting and receiving radio waves in a frequency band used for short-range communication. The transmission processing unit modulates the data input from the RSU control unit 11, outputs the modulated data to the antenna, and causes wireless transmission. The reception processing section is configured to demodulate the signal received by the antenna and output it to the RSU control section 11.

The GNSS receiver 13 is a device that sequentially calculates the current position of the GNSS receiver 13 (for example, every 100 milliseconds) by receiving navigation signals transmitted from positioning satellites that constitute GNSS. Current position data may be expressed in terms of latitude, longitude, altitude, etc. The GNSS receiver 13 transmits the calculated position data to the RSU control unit 11.

Furthermore, the GNSS receiver 13 identifies the current time based on the time information included in the navigation signal, and outputs it to the RSU control unit 11. For example, the GNSS receiver 13 may calculate the current time based on time error information specified at the time of position calculation and output it to the RSU control unit 11.

The millimeter wave radar 14 acquires information about objects existing in the monitoring area by transmitting and receiving millimeter waves or quasi-millimeter waves. Specifically, it detects objects existing within the monitoring area, and estimates the direction, distance, relative speed, type, etc. of the detected objects. The millimeter wave radar 14 outputs radar detection data indicating the position, type, moving direction, moving speed, etc. of each detected object to the RSU 11.

The camera 15 is an optical camera configured to include the surveillance area in its imaging range. The camera 15 may be an infrared camera or the like. Image data generated by the camera 15 is input to the image analysis section 16. The description of "image data" here may be interpreted as a video signal.

The image analysis unit 16 detects a moving object existing within the monitoring area by analyzing the image generated by the camera 15. Note that the image analysis unit 16 may be configured to be able to detect not only moving objects but also obstacles that affect the running of the vehicle. Obstacles include, for example, road construction signs, cones, puddles, snowy areas, fallen objects, and the like. The image analysis unit 16 outputs to the RSU 11 camera detection data, which is a data set indicating the position of a moving object/obstacle detected by analyzing the camera image. The camera detection data may include the position, type, moving direction, moving speed, etc. of each detected object. The function as the image analysis section 16 may be built into the camera 16/RSU control section 11.

Note that the millimeter wave radar 14 and camera 15 correspond to an example of an area monitoring sensor for detecting traffic conditions within the monitoring area. The RSU 1 may include a plurality of millimeter wave radars 14 and a plurality of cameras 15. The RSU 1 may include sonar, LiDAR, or the like as an area monitoring sensor. The millimeter wave radar 14 and camera 15 are not essential elements for the RSU 1 and may be omitted. The combination of area monitoring sensors included in the RSU 1 can be changed as appropriate.

The RSU control unit 11 includes a support information distribution unit F1, a self-diagnosis unit F2, and a status notification unit, as shown in FIG. A section F3 is provided.

The support information distribution unit F1 generates support data indicating the traffic situation within the monitoring area based on the output data of the area monitoring sensor. The output data of the area monitoring sensor includes radar detection data, camera detection data, image data, and the like. The support information distribution unit F1 may combine output data from a plurality of area monitoring sensors to detect the traffic situation within the monitoring area.

Further, the support information distribution unit F1 wirelessly transmits support data generated based on data from the area monitoring sensor to the in-vehicle device 2 in cooperation with the wireless unit 12. In this disclosure, a wireless signal/electrical signal corresponding to a communication packet containing support data is also referred to as a support message. The description of support data in the present disclosure can be interpreted by replacing it with a support message as appropriate. The support message corresponds to a MAP message, which is one of the RSU messages.

RSU1 broadcasts the support message. The generation/transmission cycle of the support message by the support information distribution unit F1 may be limited to approximately once every 100 milliseconds to one second.

Note that the RSU 1 may distribute the support message in a unicast/multicast/geocast manner. Geocasting is a flooding communication mode that specifies a destination using location information. In geocasting, vehicle-mounted devices 2 existing within a range designated as a geocasting area can receive the message. According to geocasting, data can be distributed without specifying the identification information of the vehicle-mounted devices 2 existing in the area to which information is to be distributed.

Note that the RSU 1 may be configured to periodically transmit an advertisement message in addition to the support message. The advertisement message is a message for notifying the on-vehicle device 2 of the existence of its own unit, and is a message indicating the RSU-ID, installation position, transmission time, service type, RSU type, and the like. The advertisement message may be a simple message specialized for the contents described in the header described above. The advertisement message can also be called a service announcement, which is a message for notifying the surroundings of the service provided by the own unit.

The self-diagnosis unit F2 is a functional unit that diagnoses whether the unit to which it belongs is functioning normally.The self-diagnosis unit F2 performs either image-based diagnosis processing or time-based diagnosis processing as processing related to self-diagnosis. It is configured to be able to implement one or both.

The image-based diagnosis process is a process that determines the operating state of the camera 15 by comparing the current camera image and camera images taken in the past. The time-based diagnostic process is a process that determines whether the GNSS receiver 13 is operating normally by comparing the time information received from the on-vehicle device 2 and the time information held by the own unit. . Note that if a problem occurs in the GNSS receiver 13, the error between the internal time, which is the time information held by the RSU control unit 11, and the actual time may exceed a predetermined value. The internal time of RSU1 can also be called RSU time. Details of the image/time-based diagnosis processing will be described separately later.

In addition, the self-diagnosis unit F2 may diagnose the millimeter-wave radar 14 by comparing the detection results of the millimeter-wave radar 14 with the moving object/obstacle information in the intersection received from the on-vehicle device 2. . Furthermore, the camera 15 or the millimeter wave radar 14 may be diagnosed by comparing camera detection data and radar detection data. For example, the self-diagnosis unit F2 may detect a malfunction in the millimeter wave radar 14 based on the fact that what is detected by the camera 15 is not detected by the millimeter wave radar 14. Similarly, the self-diagnosis unit F2 may detect a malfunction in the camera 15 based on the fact that what is detected by the millimeter wave radar 14 is not detected by the camera 15.

The self-diagnosis unit F2 also detects a malfunction in the radio unit 12 based on the fact that the level of noise observed in the radio unit 12 continues to be higher than a predetermined value for a predetermined period of time or more. good. Note that the malfunction of the wireless unit 12 can include not only a malfunction in the wireless unit 12 itself but also a case where jamming radio waves are being received.

The self-diagnosis unit F2 compares the registered installation position, which is the installation position coordinates registered in advance by the administrator/installer, with the latest positioning calculation result input from the GNSS receiver 13. 13 defects may be detected. For example, if the difference between the registered installation position and the positioning calculation result is greater than or equal to a predetermined value, it may be determined that the GNSS receiver 13 is malfunctioning. Alternatively, it may be determined that the GNSS receiver 13 is malfunctioning based on the fact that current position data is not input from the GNSS receiver 13 for a certain period of time (for example, one hour).

Further, the self-diagnosis section F2 may detect a malfunction in the RSU control section 11/communication partner by performing bidirectional communication with the microcomputer included in the radio section 12 and the image analysis section 16. As a fault detection method using two-way communication, a watchdog timer method, a homework answer method, etc. can be adopted.

When the self-diagnosis section F2 determines that a malfunction has occurred in its own unit, it may identify the location where the malfunction has occurred. The self-diagnosis unit F2 may be configured to specify, for example, which of the radio unit 12, the GNSS receiver 13, the millimeter wave radar 14, the camera 15, and the RSU control unit 11 is malfunctioning. In other words, the self-diagnosis section F2 may determine whether each of the devices constituting its own unit is functioning normally.

The status notification unit F3 is configured to notify an external device of the diagnosis result of the self-diagnosis unit F2. The external devices here may include the in-vehicle device 2, the management server 3, and other RSUs 1. For example, the status notification unit F3 causes the wireless unit 12 to periodically transmit a support message in which a status code corresponding to the diagnosis result is written in a V2X header. Thereby, the vehicle-mounted device 2 may be able to recognize the status of the sending source RSU 1 based on the received support message.

Note that the support message includes a V2X header and a payload part, as shown in FIG. 5, for example. The status code may be inserted into the V2X header. The payload section is an area in which support data is accommodated. The V2I header includes a message set ID, message version, service type, RSU-ID, installation location, target area, transmission time, RSU type, and status. The message set ID indicates which message set specifications the message conforms to. A message set corresponds to a so-called data format that defines the order of information contained in a message.

The message version is data indicating the version of the definition specification of the message set. The service type is data indicating the type of service provided by the RSU 1 as a transmission source. RSU-ID is the identification number (ID) of RSU1. The installation position indicates the installation position coordinates of the RSU1. The target area indicates the area to which the RSU 1 provides services, that is, the distribution area. The target area can be expressed, for example, by the position coordinates of the center of the area and the radius of the area. The target area may be expressed only by the distance (radius) from the RSU installation position. For example, if the value of the target area is set to 25 m, the target area may be within 25 m from the RSU installation position/designated reference point.

The transmission time indicates the transmission time of the message. The RSU type indicates whether the RSU 1 as a transmission source is a connected type or an independent type. The RSU type may also be expressed as a 1-bit (0/1) or multiple-bit code. For example, an independent type can be represented by "0" and a connected type can be represented by "1". The RSU type can also be referred to as an RSU attribute or a network type. In one aspect, the data indicating the RSU type corresponds to data indicating whether or not the message sending source RSU 1 is connected to the WAN 9, so it can also be referred to as network connection information. The status may be expressed by the status code described above. D11 to D19 shown in FIG. 5 each represent data fields in which various data are placed. For example, the data field D11 indicates an area where a bit string indicating a message set ID is placed.

Note that, in addition to the support message, the RSU 1 may also transmit a dedicated message for notifying the status of its own unit. In this disclosure, an RSU message including data indicating the status of RSU1 is also referred to as a status message. Further, among the status messages, an RSU message including a code indicating that a defect has occurred is also referred to as a defect notification message, and an RSU message including a code indicating that the status is normal is also referred to as a normal notification message. A defect notification message can also be called an error message. The RSU 1 may cause the advertisement message to function as a status message by inserting a status code into a predetermined area of the advertisement message, for example, an option area.

Furthermore, the status notification unit F3 may omit sending the status message when the status is normal. The status notification unit F3 may be configured to transmit a malfunction notification message to the vehicle-mounted device 2 only when a malfunction is detected in its own unit. According to this configuration, it is possible to reduce the risk of inadvertently consuming short-range communication resources.

Note that the status code in this embodiment includes information indicating the location where the problem has occurred. Therefore, the malfunction notification message does not simply indicate that a malfunction has occurred in the RSU 1, but also indicates the content of the malfunction, that is, the location where the malfunction has occurred. In this manner, the RSU 1 may transmit a message including a status code corresponding to the content of the detected malfunction as a malfunction notification message. As another aspect, the malfunction notification message may be a message indicating that some kind of malfunction has occurred in the RSU 1. The malfunction notification message may be a message simply indicating that the service is being stopped.

<Supplementary information regarding the configuration of connected RSU>
Although the connected RSU 1B differs from the independent RSU 1A in that it includes a WAN module, the other configurations can be the same as the independent RSU 1A. The WAN module is a communication module for connecting the RSU 1 to the WAN 9. The WAN module receives data from the management server 3 and outputs it to the RSU control unit 11, and also modulates data input from the RSU control unit 11 and transmits the modulated data to the management server 3. The RSU 1 may be connected to the WAN 9 by wire or wirelessly. That is, the WAN module 17 may be a signal processing module including a connector for wired connection, or may be a wireless module for cellular communication. Cellular communication in the present disclosure refers to wireless communication using a mobile phone line provided by a mobile communication carrier, such as LTE (Long Term Evolution)/4G, 5G, etc.

The self-diagnosis unit F2 of the connected RSU 1B may be configured to diagnose whether the WAN module is operating normally. The status notification unit F3 of the connected RSU 1B sends self-diagnosis results and data regarding moving objects/obstacles within the monitoring area to the management server 3 periodically/in response to inquiries from the management server 3. sell.

<About image-based diagnosis processing>
Here, image-based diagnosis processing will be explained. The image-based diagnosis process requires a reference image registration process as a preparatory process.

The reference image registration process is a process for generating a reference image as a judgment material for verifying whether the camera 15 (for example, an image sensor) is functioning normally, and registering it in the storage 113. For example, as shown in FIG. 6, the reference image registration process includes a step (S11) of acquiring an image taken by the camera 15, a step (S12) of generating a reference image based on the acquired image, and a step (S12) of generating a reference image based on the acquired image. (S13).

The reference image is image data of a fixed object/stationary object obtained by removing moving objects such as cars and pedestrians from the captured image generated by the camera 15. The reference image can also be called a fixed image. The reference image may be generated by combining a plurality of camera images taken at different times. According to the configuration in which a comparison image is generated based on a plurality of images captured at different times (frames), a road surface image in an area in which a moving object was captured in a certain frame is also complemented by images in other frames. sell.

Such reference image registration processing can be performed when the RSU 1 is installed, triggered by a specific operation by the installer, such as pressing a record button. Note that the reference image registration process may be performed periodically, such as every month. Further, the self-diagnosis unit F2 may generate a reference image for each time period/weather and store it in the storage 113.

Image-based diagnostic processing may be performed periodically, for example, every 10 seconds, 1 minute, or 10 minutes. As shown in FIG. 7, the image-based diagnosis process includes, for example, steps S21 to S26. Step S21 is a step of acquiring a current image. The current image is the latest image generated by the camera 15. Step S22 is a step of generating a comparison image based on the current image acquired in step S21. The comparison image is an image obtained by removing a moving object from the current image, or an image obtained by extracting a region in which a fixed object/stationary object appears from the current image. The comparison image may also be generated by combining a plurality of images taken within a predetermined period of time in the immediate vicinity. Step S23 calculates the difference between the reference image registered in the storage 113 and the comparison image generated in step S22. The difference here corresponds to the degree of mismatch between the two images. The degree of mismatch corresponds to the opposite of the degree of similarity between images. If the degree of similarity is expressed as a percentage, the degree of mismatch can be determined by subtracting the degree of similarity from 100. Comparison of images may be performed by comparing feature amounts such as edges.

If the difference between the two images is less than the predetermined value (S24 NO), the self-diagnosis unit F2 determines that the camera 15 is normal (S25). Note that if the difference between the two images is less than a predetermined value, the comparison image generated in step S22 may be registered in the storage 113 as the latest reference image. On the other hand, if the difference between the two images is greater than or equal to the predetermined value, the self-diagnosis section F2 determines that there is a problem with the camera 15/its own unit (S26).

According to the image-based diagnostic processing described above, it is possible to verify whether the camera 15 is functioning normally. Note that the image-based diagnosis processing may be omitted during rainy weather or snowfall. It is preferable that the image-based diagnosis process is performed when the weather and time match to some extent with the reference image generation time.

<About time-based diagnostic processing>
Here, time-based diagnosis processing will be explained.

The time-based diagnosis process includes steps S31 to S39 as shown in FIG. Step S31 is a step of receiving a message transmitted from the vehicle-mounted device 2 through short-range communication. Step S32 is a step in which vehicle time information included in the received message is extracted and stored in the memory 112. The vehicle time information is time information included in the message received from the vehicle-mounted device 2.

The above steps S31 to S32 are performed at any time. Steps S31 to S32 can be performed in parallel even while the processing after step S33 is being performed. When a plurality of on-vehicle devices 2 exist around the RSU 1, the RSU 1 can receive messages from the plurality of on-vehicle devices 2 within a certain period of time (250 milliseconds/500 milliseconds). Accordingly, it can be expected that vehicle time information of a plurality of on-vehicle devices 2 will be stored in the memory 112.

Step S33 calculates the average (μ) and standard deviation (σ) of a plurality of vehicle time information acquired within the nearest fixed time (for example, 200 milliseconds) stored in the memory 112 as a population. Note that statistical indicators such as variance and range can also be used instead of standard deviation. As a statistical indicator, the range is the difference between the maximum and minimum values included in the population. In this disclosure, the time calculated in step S33 is also referred to as average time. The average time corresponds to the average value of times held by a plurality of on-vehicle devices 2 existing within the communication area of the RSU 1. Note that if the number of elements in the population is less than a predetermined value (for example, 5 or 10), execution of subsequent processing may be stopped and steps S33 and subsequent steps may be performed after a predetermined period of time. Step S33 may be performed at regular time intervals.

If the standard deviation calculated in step S33 is greater than or equal to the predetermined value (S34 NO), the self-diagnosis unit F2 adjusts the population. For example, a population is generated by removing vehicle time information that deviates from the average by a predetermined value or more, and the average and standard deviation are recalculated using the adjusted population. By repeating steps S33 and S34, a highly accurate current time is specified.

On the other hand, if the standard deviation calculated in step S33 is less than the predetermined value (S34 YES), the self-diagnosis unit F2 calculates the difference between the internal time and the average time. The internal time used in this step is time information held by the RSU 1 and is an element that can be corrected by the GNSS receiver 13 at any time.

If the difference between the internal time and the average time is less than a predetermined value (S37 YES), the self-diagnosis unit F2 determines that the GNSS receiver 13 is functioning normally (S38). On the other hand, if the difference between the internal time and the average time is greater than or equal to the predetermined value (S37 YES), the self-diagnosis unit F2 determines that a problem has occurred in the GNSS receiver 13/its own unit (S39).

<About the configuration and functions of the on-vehicle device>
As shown in FIG. 9, the in-vehicle device 2 communicates with each of a locator 41, a surrounding monitoring sensor 42, a vehicle sensor 43, a cellular communication unit 44, a display 45, a speaker 46, and a drive system 47 via an in-vehicle network VN. Connected for communication. Various standards such as Controller Area Network (CAN (registered trademark)), Ethernet (registered trademark), and FlexRay (registered trademark) can be adopted as standards for the in-vehicle network VN. Note that some of the devices may be directly connected to the on-vehicle device 2 via a dedicated cable. The connection mode between the devices described in this disclosure is an example, and the specific connection mode between the devices can be changed as appropriate. In this disclosure, a system including various devices mounted on a vehicle, including the on-vehicle device 2, is also referred to as an on-vehicle system VS. The on-vehicle device 2 includes a V2X module 21 and a control module 22.

The V2X module 21 is a communication module for implementing short range communication. Like the radio section 12, the V2X module 21 includes an antenna for implementing short-range communication, a transmission processing section, and a reception processing section. The V2X module 21 is connected to a control module 22. The V2X module 21 performs signal processing such as modulation on the baseband signal input from the control module 22 and transmits a wireless signal. Further, the V2X module 21 performs signal processing such as demodulation on the signal received via the antenna and outputs received data to the control module 22 . For example, the V2X module 21 receives support messages/data distributed from the RSU 1 and inputs them to the control module 22 .

The control module 22 is configured as a computer including a processor 221, a memory 222, a storage 223, an input/output circuit (I/O) 224, and the like. Processor 221 is, for example, a CPU. Memory 222 is, for example, a volatile storage medium such as RAM. By accessing the memory 222, the processor 221 executes various processes for realizing the functions of each functional unit, which will be described later. The storage 223 includes a nonvolatile storage medium such as a flash memory. The storage 223 stores a vehicle program that is a program for the vehicle-mounted device 2. The storage 223 corresponds to a storage unit. The input/output circuit 224 is a circuit module for the vehicle-mounted device 2 to transmit and receive signals with other devices. The functions of the control module 22, in other words, the functions of the vehicle-mounted device 2, will be described separately later.

Note that in this embodiment, the V2X module 21 and the control module 22 are realized as one device (ECU: Electronic Control Unit), but the present invention is not limited to this. The V2X module 21 and the control module 22 may be realized separately as separate devices. For example, the V2X module 21 may be realized as a V2X vehicle-mounted device, and the control module 22 may be realized as a driving support ECU, respectively.

The locator 41 is a device that calculates and outputs the position coordinates of the own vehicle using navigation signals transmitted from positioning satellites that constitute GNSS. The locator 41 includes, for example, a GNSS receiver, an inertial sensor, and a map memory. The inertial sensor is, for example, a gyro sensor or an acceleration sensor. The map memory is a storage medium in which map data is stored. The locator 41 determines the position of the own vehicle equipped with the locator 41 (hereinafter referred to as the own vehicle position) and the moving direction by combining the positioning signal received by the GNSS receiver, the detection value of the inertial sensor, and the road shape shown in the map data. positioning sequentially. The vehicle position is expressed, for example, in three-dimensional coordinates of latitude, longitude, and altitude. The own vehicle position data detected by the locator 41 is input to the on-vehicle device 2. Locator 41 may be a navigation device.

The surroundings monitoring sensor 42 is a sensor that outputs a signal indicating the surrounding environment of the own vehicle. A camera that images the outside of the vehicle, a millimeter wave radar, LiDAR, sonar, etc. correspond to the surrounding monitoring sensor 42. The surroundings monitoring sensor 42 detects an object existing in a detection range around the own vehicle, and inputs data indicating the position, moving speed, type, etc. of the detected object to the on-vehicle device 2. For example, the in-vehicle system VS includes a front camera, a front radar, etc. as the surrounding monitoring sensor 42. The front camera is, for example, an optical/infrared camera arranged to capture an image in front of the vehicle at a predetermined angle of view. The front camera is located at the upper end of the windshield on the inside of the vehicle, on the front grille, on the roof top, etc. The forward radar is a millimeter wave radar installed at the front of the vehicle, such as the front grill or front bumper. The forward radar detects the distance, relative speed, and relative position of objects in front of the vehicle, such as a preceding vehicle.

The vehicle sensor 43 is a sensor group that detects information regarding the state of the own vehicle. Vehicle sensors 43 include a vehicle speed sensor, a steering angle sensor, an acceleration sensor, a yaw rate sensor, and the like. The vehicle speed sensor detects the vehicle speed of the own vehicle. A steering angle sensor detects a steering angle. The acceleration sensor detects acceleration such as longitudinal acceleration and lateral acceleration of the own vehicle. The yaw rate sensor detects the angular velocity of the own vehicle. The vehicle sensor 43 inputs data indicating the current value (that is, the detection result) of the physical state quantity to be detected to the on-vehicle device 2. The types of vehicle sensors connected to the on-vehicle device 2 may be designed as appropriate, and it is not necessary to include all the sensors described above. A signal indicating a shift position or a signal indicating an operating state of a turn signal may be input to the on-vehicle device 2.

The cellular communication unit 44 is a communication module for implementing cellular communication. For example, the cellular communication unit 44 transmits and receives radio waves to and from base stations around the vehicle through wireless communication in accordance with cellular communication standards such as 5G. The cellular communication unit 44 transmits data input from the on-vehicle device 2 to the management server 3. Furthermore, the cellular communication unit 44 receives data addressed to the on-vehicle device 2 from the management server 3 and inputs it to the on-vehicle device 2.

The display 45 is, for example, a liquid crystal display or an organic EL display. Display 45 may be a head-up display. The display 45 displays an image according to an input signal from the on-vehicle device 2. The speaker 46 is a device that converts an electrical signal into sound and outputs it. The speaker 46 outputs sound according to the electrical signal input from the on-vehicle device 2. Sounds in this disclosure include voice messages, notification sounds, warning sounds, sound effects, music, and the like.

The drive system 47 is a system including an actuator for driving the vehicle and an ECU for controlling the actuator. Components of the drive system 47 can include part or all of a power unit ECU that controls a drive source such as an engine or a travel motor, a brake actuator, a brake ECU, an EPS (Electric Power Steering) motor, a steering ECU, etc. .

As shown in FIG. 10, the control module 22 includes a support processing section G1, a recording processing section G2, an RSU diagnosis section G3, a communication processing section G4, and a communication processing section G4, as shown in FIG. It includes a notification control section G5. The RSU diagnosis section G3 includes an RSU detection section G31 as a sub-functional section.

The support processing unit G1 implements driving support based on the support data received from the RSU1. For example, the support processing unit G1 notifies the vehicle of another moving object that is approaching the vehicle within the intersection. More specific examples include notifying the presence or absence of an oncoming vehicle when making a right turn, or notifying the presence of pedestrians/cyclists who may come into contact with the own vehicle.

The notification to the driver can be realized by displaying an image on the display 45, outputting an audio message/warning sound from the speaker 46, lighting an indicator, applying vibration, etc. Note that the support processing unit G1 may perform vehicle control such as braking and steering in addition to notifying the driver as driving support processing. The driver in this disclosure refers to a person seated in a driver's seat, that is, a driver's seat occupant. The concept of a driver can include a person who remotely controls a vehicle.

As shown in FIG. 11, when the recording processing unit G2 receives the RSU message (S41), it records data regarding the sending source RSU1 in the storage 223 (S42). In this disclosure, the list of RSUs 1 that have received messages is referred to as usage history data.

The usage history data includes RSU data that is detailed data for each RSU1. For example, each RSU data can include an installation location, an RSU-ID, a distribution area, an RSU type, a service type, etc., as shown in FIG. Note that the RSU data may include the number of times the service of the RSU 1 has been used. The number of uses may correspond to the number of times the delivery area has been passed through. The number of times of use can also be expressed as the number of times of passing through the area or the number of times of reception.

The RSU data may include data indicating the observed value of reception strength according to the distance from the RSU 1. For example, the recording processing unit G2 can record the reception strength at each of the points where the remaining distance to the RSU1 is 25 m, 15 m, and 5 m. Note that the usage history data may include information on the farthest reception position. The farthest receiving position information is the coordinates of the farthest position where the message from RSU1 could be received.

The usage history data described above may correspond to data mapping RSUs 1 that have been used by the in-vehicle device 2. The recording processing unit G2 updates the usage history data upon receiving the RSU message. For example, when receiving an RSU message from an RSU 1 that has not been used before, information about the RSU 1 is added to the usage history data. When the size of usage history data exceeds a predetermined value, the recording processing unit G2 preferentially leaves data regarding RSU1 that has been used more frequently. In other words, when the storage capacity becomes full, the recording processing unit G2 deletes data from the RSU1 that has been used less frequently first.

The RSU diagnostic unit G3 determines whether the RSU 1 located in front of the vehicle is operating normally. The RSU 1 existing in front of the own vehicle refers to the RSU 1 located in front of the own vehicle, in other words, the RSU 1 installed in a road section that the own vehicle will pass within a predetermined time. Hereinafter, the RSU1 to be diagnosed by the RSU diagnostic unit G3 will also be referred to as a target RSU. The target RSU can also be called a forward RSU (front roadside unit) or a communication partner. For example, the RSU 1 installed at an intersection in front of the vehicle corresponds to the target RSU. The forward RSU/target RSU can also be understood as the RSU 1 existing in a position where short-range communication is possible with the own aircraft, or the RSU 1 existing within a predetermined distance from the own aircraft.

The RSU diagnostic unit G3 may recognize the existence of the target RSU by receiving the RSU message. Further, the RSU diagnostic unit G3 may detect the target RSU based on map data showing the installation location of the RSU 1. The RSU diagnostic unit G3 may detect the target RSU based on usage history data. The configuration that detects the forward RSU as a diagnosis target based on the map data/V2I message reception/use history data corresponds to the RSU detection unit G31 (roadside unit detection unit). Further, the RSU diagnosis section G3 corresponds to a malfunction detection section.

The RSU diagnostic unit G3 may diagnose the target RSU in various ways. The RSU diagnostic unit G3 may diagnose the target RSU based on data included in the message received from the target RSU. For example, the RSU diagnostic unit G3 determines that a problem has occurred in the target RSU based on the fact that the difference between the time information included in the message received from the target RSU and the time held by the own device is a predetermined value or more. It may be determined that Diagnosis based on the difference in time information corresponds to the time-based diagnosis process described above. In addition, the RSU diagnostic unit G3 detects a problem in the target RSU based on the fact that the difference between the installation position information included in the message received from the target RSU and the position of the target RSU recognized by the own vehicle is a predetermined value or more. It may be determined that this has occurred. Furthermore, if the security information of the received RSU message is inappropriate, it may be determined that a problem has occurred in the target RSU. Examples of cases where the security information is inappropriate include cases where an electronic certificate has not been granted, or cases where the electronic certificate has expired.

Furthermore, with respect to the RSU 1 that has a usage history, the RSU diagnostic unit G3 may determine whether the target RSU is functioning normally by comparing the past reception status and the current reception status. For example, the RSU diagnostic unit G3 estimates the communication area of the target RSU based on a set of points that have received messages from the target RSU in the past. If a message from the target RSU cannot be received even though the own vehicle exists within the communication area, it may be determined that the target RSU is malfunctioning.

Furthermore, with respect to the RSU 1 that has a usage history, the RSU diagnostic unit G3 determines whether or not the own vehicle exists within the distribution area of the target RSU, based on distribution area information acquired during past usage. If a message from the target RSU cannot be received even though the own vehicle exists within the distribution area of the target RSU, it may be determined that the target RSU is malfunctioning. These correspond to reception status-based diagnostic processing (judgment processing) that diagnoses the target RSU based on the reception status of messages from the target RSU.

By the way, if there is a large vehicle such as a truck in front of the host vehicle, it may be difficult to receive a message from the target RSU. Therefore, if the presence of a large vehicle within a predetermined distance in front of the host vehicle is detected by a front camera or the like, the RSU diagnostic unit G3 may cancel implementation of the reception status-based diagnostic process. In other words, it is preferable that the reception status-based diagnosis process be performed on the condition that there is no large vehicle within a predetermined distance in front of the host vehicle. According to this configuration, it is possible to reduce the possibility of incorrectly determining that a malfunction has occurred in the RSU 1 that is operating normally. Further, the RSU diagnosis unit G3 may invalidate the reception status-based diagnosis result when the presence of a large vehicle within a predetermined distance in front of the host vehicle is detected by a front camera or the like. Invalidating the diagnosis result may be achieved by discarding the diagnosis result or by not reporting it to the management server 3. Note that the large vehicle can be a vehicle with a height of a predetermined value (for example, 3 m) or more. Whether a vehicle is a large vehicle or not may be defined by vehicle classification stipulated by law.

In addition, the RSU diagnostic unit G3 determines whether or not the target RSU is operating normally by comparing the detection results of the own vehicle's surrounding monitoring sensor 42 and the position information of the moving object notified from the target RSU. You may do so. The RSU diagnostic unit G3 may determine that a problem has occurred in the target RSU based on the fact that the surrounding monitoring sensor 42 of the own vehicle has detected a moving object that has not been notified by the target RSU. In addition, the RSU diagnostic unit G3 determines whether the target RSU is operating normally by comparing the position information of the mobile body acquired from another vehicle through vehicle-to-vehicle communication with the position information of the mobile body acquired from the target RSU. It may also be determined whether or not there is one.

The RSU diagnostic unit G3 may determine that a problem has occurred in the target RSU based on receiving the malfunction notification message from the target RSU. This configuration also corresponds to a configuration in which a malfunction in the front RSU is detected based on data received from the front RSU. The RSU diagnostic unit G3 detects that a malfunction has occurred in the front RSU based on receiving a signal indicating that a malfunction has occurred in the front RSU from another onboard device 2 or the management server 3. Good too.

If the RSU diagnostic unit G3 receives a notification that a malfunction is occurring from the target RSU itself, and the RSU diagnostic unit G3 itself also determines that a malfunction has occurred in the target RSU, the RSU diagnostic unit G3 determines that a malfunction has occurred in the target RSU. It is also possible to confirm the determination that the That is, the vehicle-mounted device 2 may determine the status of the target RSU by combining the self-report from the RSU 1 and the diagnosis result of the RSU diagnosis unit G3. According to such a configuration, the accuracy of determining the status of the RSU 1 can be improved. As the RSU diagnosis method using the on-vehicle device 2, one or more of the various methods described above can be adopted.

The communication processing unit G4 controls data communication with the management server 3, the RSU 1, and other in-vehicle devices 2. For example, the communication processing unit G4 transmits a failure detection report to the management server 3 as a notification process based on the fact that the RSU diagnosis unit G3 detects a failure in the RSU1. The malfunction detection report is a communication packet indicating that the target RSU may not be functioning normally. The communication processing unit G4 corresponds to a notification processing unit.

As shown in FIG. 13, the malfunction detection report includes transmission source information, the identification number (RSU-ID) of the RSU 1 to be reported, and the malfunction detection time. Furthermore, the malfunction detection report may include part or all of the installation location, RSU type, status code, message set ID, message version, and environment code of the RSU 1 to be reported. Each piece of data may be written in the header, or some or all of the data may be stored in the payload section. The source information can be expressed, for example, as a vehicle ID/MAC address of the on-vehicle device 2/IP address. The environment code is information indicating the surrounding environment when the status of the RSU 1 is determined, and refers to the presence or absence of a preceding vehicle, the classification of the preceding vehicle (whether it is a large vehicle or not), the weather, etc.

D21 to D26 shown in FIG. 13 each represent data fields in which various data are placed in a message/communication packet as a defect detection report. For example, the data field D22 indicates a target number field, which is an area in which a bit string indicating the ID of RSU1 to be reported is arranged. Further, the data field D23 indicates a detection time field, which is an area in which a bit string indicating a malfunction detection time (in other words, a determination time) is arranged. Data field D26 indicates a status field, which is an area where a status code is placed.

Transmission of the malfunction detection report to the management server 3 may be performed by cellular communication. Further, the malfunction detection report may be transmitted to the management server 3 via the connection type RSU 1B. The connected RSU 1B can play the role of transferring a malfunction detection report received from the on-vehicle device 2 to the management server 3.

In addition, when the communication processing unit G4 detects a malfunction in the target RSU, it transmits a malfunction detection message, which is a V2X message containing the same contents as the malfunction detection report, to other machines or other RSUs 1 through short-range communication. Good too. The communication processing unit G4 may add information about the RSU 1 that has detected the malfunction to the header/payload of the own vehicle status message that is periodically transmitted. The communication processing unit G4 may function the own vehicle status message as a malfunction detection message. If the on-vehicle device 2 notifies surrounding vehicles of a malfunction in the RSU 1 through vehicle-to-vehicle communication, confusion among surrounding vehicles can be reduced and safety can be further improved. Note that notification of the malfunction of the front RSU to other vehicle-mounted devices 2 existing around the vehicle may be performed via the management server 3. That is, when the on-vehicle device 2 detects a malfunction in the front RSU, it may report it to the management server 3, and the management server 3 may distribute information about the RSU 1 for which the malfunction has been reported to each on-vehicle device 2.

According to this configuration, the vehicle-mounted device 2 may be able to determine whether or not the RSU 1 is functioning normally, based on the notification from the preceding vehicle, even before entering the communication range of the preceding RSU. In addition, if the on-vehicle device 2 receives a notification from the preceding vehicle indicating that there is a problem with the front RSU, the on-vehicle device 2 automatically detects a problem with the front RSU before entering the communication range of the front RSU. It may be possible to implement a response (for example, a notification to the driver). Furthermore, according to the configuration in which the diagnosis results of the RSU diagnosis unit G3 are shared between the on-vehicle units 2 through inter-vehicle communication, the RSU diagnosis unit G3 can integrate the diagnosis results from multiple on-vehicle units 2 to detect a problem in the target RSU. It may be possible to determine with higher accuracy whether or not this has occurred. For example, the RSU diagnostic unit G3 may determine whether or not the target RSU is operating normally by majority vote. Not only when it is determined that the target RSU is malfunctioning, but also when it is determined that the target RSU is operating normally, the communication processing unit G4 transmits a data set indicating this to other machines and manages the target RSU. It may also be sent to server 3. The message indicating the determination result of the RSU diagnosis unit G3 can also be called a diagnosis result report. When the communication processing unit G4 receives a malfunction notification message from the RSU 1 via short-range communication, it sends a message to the management server 3 via cellular communication indicating that a malfunction has occurred in the RSU 1 as the source of the message. You may.

The communication processing unit G4 may change whether or not to report to the management server 3 depending on the type of RSU 1 in which a malfunction has been detected. For example, if the RSU 1 that detected the problem is a connection type, the report to the management server 3 may be omitted. This is because the connected RSU 1B can report the occurrence of a problem to the management server 3 by itself. For example, as shown in FIG. 14, when the communication processing unit G4 detects that a problem has occurred in the front RSU (S51 YES), the communication processing unit G4 determines the type of the RSU 1 (S52). Then, only when a malfunction in the independent RSU 1 is detected (S52 YES), a report may be made to the management server 3 (S53).

The type of RSU 1 to be reported can be determined based on any one of map data, data received from the target RSU, and usage history data. Among the functions included in the control module 22, the configuration for determining the type of the RSU 1 is also referred to as a type determination unit in this disclosure.

The notification control unit G5 notifies the driver based on detecting that a problem has occurred in the front RSU (target RSU). Hereinafter, an RSU in which a defect has been detected will also be referred to as an error RSU. For example, if the error RSU is RSU1 that has been used in the past, the notification control unit G5 displays a predetermined malfunction notification image. The RSU 1 that has been used in the past is the RSU 1 that has received a support message from the RSU 1 in a past trip. A trip here refers to a series of trips from when the power source for traveling is turned on until it is turned off. The number of times an error RSU has been used is determined by referring to usage history data stored in the storage 113. An RSU1 that is not registered in the usage history data, in other words, an RSU1 that has been used 0 times, corresponds to an RSU1 that has not been used by the own vehicle in the past.

Moreover, when the error RSU is an RSU 1 that has not been used in the past, the notification control unit G5 does not need to notify the driver that a problem has occurred in the RSU 1. Furthermore, if the error RSU is an RSU 1 that has been used more than a predetermined number of times in the past, the notification control unit G5 reports the malfunction of the RSU 1 to the driver in a stronger manner than when the number of uses is less than a predetermined number of times. You may notify. The notification control unit G5 may change the notification mode regarding the malfunction of the RSU1 according to the past number of times of use. Elements that make up the form of notification using images include display position, display size, presence or absence of blinking, and color. Furthermore, the elements constituting the mode of notification using sound include volume, output interval of warning sound, frequency (pitch of sound), and the like.

When a malfunction is detected in the RSU 1 that is used frequently, the notification control unit G5 preferably provides notification in a more conspicuous (stronger) manner than when a malfunction is detected in the RSU 1 that is used less frequently. According to this configuration, if the RSU 1 along the road that the driver travels on a daily basis is not functioning properly, it becomes easier to recognize that fact. As a result, it becomes easier for drivers to take measures such as driving more carefully than usual or checking their surroundings. In other words, it is possible to reduce the risk that the driver will place too much trust in the RSU 1 that is not functioning properly. Paradoxically, when a malfunction is detected in an RSU1 that is used infrequently/has no usage history, the notification control unit G5 increases the strength of the notification more than when a malfunction is detected in an RSU1 that is used on a daily basis. You may weaken the notification or omit the notification. According to the configuration, it is possible to reduce the risk of bothering the driver.

<Supplementary information on the operation of the RSU diagnostic unit>
Here, an example of the operation of the on-vehicle device 2 as the RSU diagnosis section G3 will be explained using several flowcharts. For example, the vehicle-mounted device 2 executes the GNSS-based diagnostic process shown in FIG. 15 as a process for determining whether the GNSS receiver 13 of the target RSU is functioning normally. The GNSS-based diagnostic process may include steps S61 to S66. In addition, based on having received the RSU message, the vehicle-mounted device 2 may set the transmission source of the message to the target RSU, and perform the processing from step S62 onwards.

Step S61 is a step of receiving an RSU message. The received message may be a support message or another message such as an advertisement message. Step S62 is a step of extracting the GNSS information from the received message and storing it in the memory 222. The GNSS information here refers to either or both of time information and position information. The position information of the RSU 1 corresponds to the installation position.

Step S63 is a step of acquiring (reading) GNSS information of the own vehicle. Step S64 is a step in which the GNSS information of the RSU 1 obtained in step S62 is compared with the GNSS information of the own vehicle obtained in step S63. The type of information to be compared may be time information or position coordinates. For example, when the difference between the time information of the own vehicle and the time information of the target RSU is greater than or equal to a predetermined value (S65 YES), the RSU diagnostic unit G3 determines that a problem has occurred in the GNSS receiver 13 of the target RSU. (S66).

Further, for example, the vehicle-mounted device 2 executes the wireless function diagnosis process shown in FIG. 16 as a process for determining whether the wireless unit 12 of the target RSU is functioning normally. The wireless function diagnosis process may include steps S71 to S75. The on-vehicle device 2 executes a wireless function diagnosis process, for example, at a predetermined cycle.

Step S71 is a step in which the RSU detection unit G31 searches for a forward RSU. For example, the RSU detection unit G31 searches for a forward RSU based on map data indicating the installation position of the RSU 1 or usage history data. Further, step S71 may be a process of transmitting a message requesting the RSU 1 to return a response signal. The on-vehicle device 2/RSU diagnostic unit G3 serving as the RSU detection unit G31 may perform an active scan as step S71.

Step S72 is a step of determining whether a message from RSU1 has been received within a predetermined time (for example, 400 milliseconds) from now. If a message has been received from RSU 1 within the predetermined time (S72 YES), it is assumed that the wireless function itself of the forward RSU is operating normally, and this flow ends.

On the other hand, if the RSU diagnosis unit G3 has not received the message from the RSU1 within the predetermined time (S72 NO), it acquires the current position (S73). Then, the RSU diagnostic unit G3 refers to the usage history data and determines whether the current location is within the distribution area of the RSU 1 that has been used in the past (S74). If the RSU message cannot be received even though the current position is within the distribution area (S74 YES), the RSU diagnostic unit G3 determines that a problem has occurred in the RSU1 forming the above distribution area (S75 ).

Note that step S74 may be a step of determining whether an RSU message has been received at the current location in the past. The RSU diagnostic unit G3 may determine that a problem has occurred in the RSU 1 corresponding to the current location, based on the fact that the RSU message cannot be received this time at a location where the RSU message has been received in the past. The RSU1 corresponding to the current location refers to the RSU1 with which communication has been made in the past at the current location. Distribution area information stored in the storage 113 as usage history data, information on reception strength according to distance, information on the farthest reception position, etc. are used as data indicating the range in which signals from the front RSU can be received. Equivalent to. The above configuration is a configuration in which it is determined that a malfunction has occurred in the forward RSU based on the fact that the own aircraft cannot receive a signal from the forward RSU even though it is in a position where it can receive the signal from the forward RSU. It can be equivalent.

Furthermore, even if the RSU message can be received, the RSU diagnostic unit G3 determines whether the received message is correct based on the fact that the currently observed received strength is lower than a predetermined value compared to the received strength observed in the past at the same point. It may be determined that there is a problem with the transmission source. The RSU diagnostic unit G3 may diagnose the RSU 1 based on a comparison of observed values of current and past reception strengths at the same point.

<Effects of the above configuration>
In one of the configurations described above, when the vehicle-mounted device 2 detects that a problem has occurred in the front RSU, it notifies other devices around the vehicle that there is a problem in the front RSU. According to this configuration, it becomes possible for those other aircraft to recognize that a problem has occurred in the front RSU before reaching the communication range of the front RSU. Specifically, the on-vehicle device 2 of the following vehicle, which has been notified of the malfunction of the front RSU by the preceding vehicle, can perform temporary control even before reaching the communication range of the front RSU. The temporary control is control performed when a problem occurs in the roadside machine ahead. Temporary controls are expected to include notifying the driver that there is a problem with the roadside unit ahead, changing the planned driving route to another route, reducing vehicle speed, and activating surrounding monitoring sensors. . Activation of the surrounding monitoring sensor includes not only activating the stopped surrounding monitoring sensor but also shortening the execution interval of object detection processing.

Furthermore, in the above-mentioned one configuration, based on having received a message indicating that a problem has occurred from the RSU 1, the in-vehicle device 2 reports the fact to the management server 3. According to this configuration, even if a problem occurs in the independent RSU 1A, the management server 3 can easily recognize the problem. Accordingly, the management server 3 can notify the on-vehicle device 2 of the information about the RSU 1 in which the problem has occurred, and the on-vehicle device 2 can notify the vehicle-mounted device 2 of the fact that the front RSU has a problem based on the notification from the management server 3. It can be recognized even before approaching the RSU.

Further, in one embodiment, when the in-vehicle unit 2 detects a malfunction in the independent RSU 1A, it sends a malfunction detection report to the management server 3, while when the RSU 1 that has detected the malfunction is the connected RSU 1B, Transmission of the defect detection report to the management server 3 can be omitted. According to the configuration, the frequency of communication between the on-vehicle device 2 and the management server 3 can be suppressed.

Further, as one embodiment, even when the RSU 1 as a communication partner is operating normally, the on-vehicle device 2 can send a message to the management server 3 indicating that the RSU 1 is operating normally. . According to this configuration, the management server 3 can easily recognize that the RSU 1 is functioning normally/that the RSU 1 for which a malfunction has been reported has returned to a normal state. Accordingly, the cost required for system management at the service provider can be reduced.

Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments, and various modifications described below are also included within the technical scope of the present disclosure. Various modifications and changes can be made without departing from the scope of the invention. For example, the following various supplements and modifications can be implemented in appropriate combinations within the scope that does not cause technical contradiction. Note that members having the same functions as the members described above are given the same reference numerals, and their explanations may be omitted. Further, when only a part of the configuration is mentioned, the above description can be applied to other parts.

<Modification (1)>
Although the embodiment in which both the RSU 1 and the vehicle-mounted device 2 each have a function of diagnosing the RSU 1 has been described above, the present invention is not limited to this. The on-vehicle device 2 does not need to include the RSU diagnosis section G3. Furthermore, the RSU1 does not need to include the self-diagnosis section F2. If either the on-vehicle device 2 or the RSU 1 has a function of diagnosing the RSU 1, it is possible to realize the on-vehicle device 2 that transmits information about the independent RSU 1A in which a problem has occurred to the management server 3.

For example, when the on-vehicle device 2 does not include the RSU diagnosis section G3, the independent RSU 1A and the on-vehicle device 2 can operate as follows. First, when the independent RSU 1A detects its own malfunction in the self-diagnosis unit F2, it notifies the vehicle-mounted unit 2 of its own malfunction through short-range communication. Based on receiving the notification of the occurrence of a malfunction from the independent RSU 1A, the on-vehicle device 2 transmits a malfunction detection report to the management server 3 via cellular communication. Note that the in-vehicle device 2 does not necessarily need to use cellular communication, and may indirectly notify the management server 3 of a malfunction in the independent RSU 1A by transmitting a malfunction detection message to the connected RSU 1B.

Further, if the RSU 1 does not include the self-diagnosis section F2, a malfunction in the independent RSU 1A is detected by the RSU diagnosis section G3 of the on-vehicle device 2 and reported to the management server 3. In other words, the RSU1 does not need to include the self-diagnosis section F2.

<Modification (2)>
The management server 3 may determine that a malfunction has occurred in one independent RSU 1A based on the fact that malfunction detection reports have been received from a plurality of in-vehicle devices 2 within a certain period of time. The above processing may be performed not only for the independent RSU 1A but also for the connected RSU 1B. According to the configuration in which the status of the RSU 1 is determined based on reports from a plurality of on-vehicle units 2, it is possible to reduce the risk of erroneously determining the status of the RSU 1.

<Modification (3)>
When a malfunction occurs, the RSU 1 may transmit various information/an RSU message indicating that the reliability of the RSU 1 itself has decreased as a malfunction notification message. The reliability can be expressed as a value between 0 and 100, with 100 representing no defects detected. If the RSU message includes an area describing reliability in the basic format, the RSU 1 may set the setting value of the area to a predetermined value (for example, 50) or less and transmit the message when a failure is detected.

<Modification (4)>
Although the case where the support data is data indicating the traffic situation near an intersection has been exemplified above, the content of the support data is not limited to this. As another aspect, the support data may be traffic light related data indicating the lighting state of the traffic light. In addition to the current lighting state, the traffic light related data may include lighting cycle information such as the remaining time for which the current lighting state will be maintained, the next lighting state, and the like. The message/communication packet/communication frame indicating the support data may correspond to a SPaT (Signal Phase and Timing) message. The RSU 1 may be provided integrally with the traffic light.

Further, the support data may be control data for supporting automatic driving of a vehicle within an intersection. The support data may be camera image data, map data showing the shape of intersections, etc.

<Modification (5)>
Although the operation of each part has been described above assuming that the RSU 1 is installed at an intersection, the RSU 1 can also be installed at locations other than intersections. The RSU 1 may be located at a merging/branching point on a highway. The RSU 1 can distribute, as support data, a data set indicating the traffic situation near the merging/diverging point, for example, the position and speed of vehicles existing within the monitoring area. Further, the RSU 1 may be placed near the exit of the tunnel, and in that case, the RSU 1 can deliver a dataset indicating the wind speed, rainfall amount, road surface condition, and presence or absence of traffic congestion near the tunnel exit as support data. The RSU 1 installed in a road section with poor visibility can distribute a data set that notifies moving objects and road shapes existing within the monitoring area. The contents of the support data may be different for each RSU1. Road sections with poor visibility include intersections with walls, trees, or buildings at the corners, slope change points where the slope changes from an uphill slope to a downhill slope, and sharp curved points where the curvature is greater than a predetermined value. Point. The monitoring area may be set to cover areas that are likely to be blind spots for the vehicle driver/camera.

<Modification (6)>
The RSU 1 does not need to include an area monitoring sensor such as the camera 15. The RSU 1 for distributing traffic light-related data only needs to be connected to a lighting control unit that controls the lighting state of the traffic light, and the area monitoring sensor can be an arbitrary element. The hardware/functions provided by the RSU 1 may be changed as appropriate depending on the service of the RSU 1.

<Modified example (7)>
Road-to-vehicle communication uses, for example, Bluetooth (registered trademark), Wi-Fi (registered trademark), ZigBee (registered trademark), UWB-IR (Ultra Wide Band - Impulse Radio), EnOcean (registered trademark), and Wi-SUN (registered trademark). trademark), etc. Bluetooth standards include BLE (Bluetooth Low Energy), Bluetooth Classic, etc. Various standards can be adopted as Wi-Fi standards, such as IEEE802.11n, IEEE802.11ac, and IEEE802.11ax (so-called Wi-Fi6).

<Additional remarks (1)>
The above-described vehicle-mounted device 2 can be used in various vehicles running on roads. The on-vehicle device 2 of the present disclosure can be mounted on various vehicles that can run on roads, such as four-wheeled vehicles, two-wheeled vehicles, and three-wheeled vehicles. Motorized bicycles can also be included in two-wheeled vehicles. The on-vehicle device 2 may be used in a robot taxi, an unmanned bus, a vehicle as an unmanned delivery robot, and a patrol car that automatically travels along a predetermined route for inspection/crime prevention of road equipment. The vehicle-mounted device 2 may be configured to be detachable by the user. The in-vehicle device 2 may be a smartphone, tablet, laptop, or the like that is equipped with the above-mentioned short range communication function and brought into the vehicle by the user.

<Additional note (2)>
The present disclosure also includes the following technical ideas. Further, the following technical idea can also be applied to roadside devices and road-to-vehicle communication systems.

[Technical thought 1]
An in-vehicle device configured to perform road-to-vehicle communication,
a roadside device detection unit (G31) that detects a forward roadside device that is a roadside device existing in front of the own vehicle;
a malfunction detection unit (G3) that detects a malfunction of the front roadside machine based on data received from the front roadside machine or a reception status of a signal from the front roadside machine;
a notification processing unit (G4) that performs a notification process that is a process for notifying other vehicle-mounted devices of a malfunction in the forward roadside device based on the malfunction detection unit detecting a malfunction in the forward roadside device; An on-vehicle device equipped with .

[Technical philosophy 2]
The in-vehicle device described in Technical Idea 1,
The notification processing unit is configured to determine whether the front roadside unit is a stand-alone type that cannot communicate with the management device, based on map data describing the installation location and type of the roadside unit, or data received from the front roadside unit. Determine whether it is a roadside unit,
An in-vehicle device that performs the notification process based on the fact that the preceding roadside device in which the defect detection unit has detected a defect is the stand-alone roadside device.

[Technical philosophy 3]
The in-vehicle device described in Technical Idea 2,
The notification processing unit is an in-vehicle device that omits implementation of the notification process based on the fact that the roadside machine ahead of which the failure detection unit detected a failure is a network-connected roadside unit that can communicate with the management device. .

[Technical thought 4]
The in-vehicle device according to technical idea 2 or 3,
As the notification process, a target number field in which an identification number of the stand-alone roadside unit in which a malfunction has been detected is stored, a detection time field in which a detection time is stored, and a status code indicating the content of the malfunction are stored. An on-vehicle device configured to transmit a data set comprising a status field and a status field to the management device.

[Technical philosophy 5]
The in-vehicle device according to any one of technical ideas 2 to 4,
As the notification processing, the notification processing unit may perform the notification processing when the network connection type roadside machine that is capable of communicating with the management device is connected for communication, and a malfunction has been detected in the network connection type roadside machine. An on-vehicle device configured to transmit information for a standalone roadside device.

[Technical philosophy 6]
The in-vehicle device according to any one of technical ideas 1 to 5,
The malfunction detection unit detects a malfunction in the forward roadside machine based on the fact that the difference between the time information included in the message received from the forward roadside machine and the time information held by the own machine is greater than or equal to a predetermined value. An on-vehicle device that determines that a problem has occurred.

[Technical Thought 7]
The in-vehicle device according to any one of technical ideas 1 to 6,
comprising a storage unit (113) storing data indicating a range in which signals from the forward roadside machine can be received;
The malfunction detection unit detects that there is a malfunction in the forward roadside machine based on the fact that the own machine cannot receive the signal from the forward roadside machine, even though the own machine is in a position where it can receive the signal from the forward roadside machine. An on-vehicle device that determines that a problem has occurred.

[Technical Thought 8]
The in-vehicle device described in Technical Idea 7,
If it is detected that a large vehicle is present in front of the own vehicle, the determination process based on the reception status of the signal from the roadside machine in front is canceled, or the determination process based on the reception status of the signal from the roadside machine in front of the vehicle is stopped. An on-vehicle device configured to invalidate the results of determination processing based on .

[Technical philosophy 9]
An in-vehicle device configured to perform road-to-vehicle communication,
a roadside device detection unit (G31) that detects a forward roadside device that is a roadside device existing in front of the own vehicle;
a malfunction detection unit (G3) that detects a malfunction of the front roadside machine based on data received from the front roadside machine or a reception status of a signal from the front roadside machine;
a notification processing unit (G4) that performs a notification process that is a process for notifying a predetermined management device of a malfunction in the forward roadside machine based on the malfunction detection unit detecting a malfunction in the forward roadside machine; An on-vehicle device equipped with . According to this configuration, the management device can easily recognize malfunctions in stand-alone roadside devices.

<Additional remark (3)>
The various flowcharts shown in the present disclosure are all examples, and the number of steps constituting the flowcharts and the order of execution of processes can be changed as appropriate. Additionally, the devices, systems, and techniques described in this disclosure may be implemented by a dedicated computer comprising a processor programmed to perform one or more functions embodied by a computer program. Good too. The apparatus and techniques described in this disclosure may be implemented using dedicated hardware logic circuits. The apparatus and techniques described in this disclosure may be implemented by one or more special purpose computers comprised of a combination of a processor executing a computer program and one or more hardware logic circuits. As the processor (computation core), a CPU, MPU, GPU, DFP (Data Flow Processor), etc. can be employed. Part or all of the functions of the present disclosure may be realized using any of a system-on-chip (SoC), an integrated circuit (IC), and a field-programmable gate array (FPGA). good. The concept of IC also includes ASIC (Application Specific Integrated Circuit). Further, the computer program may be stored as instructions executed by a computer in a computer-readable non-transitive tangible storage medium. As a recording medium for the program, an HDD (Hard-disk Drive), an SSD (Solid State Drive), a flash memory, etc. can be used. The scope of the present disclosure also includes a program for causing a computer to function as the RSU control unit 11/control module 22/management server 3, and a form of a non-transitional physical recording medium such as a semiconductor memory in which this program is recorded.

1 RSU (roadside unit), 1A independent RSU (stand-alone RSU), 1B connected RSU (network-connected RSU), 2 onboard unit, 3 management server (management device), 11 RSU control unit, F1 support information distribution section, F2 self-diagnosis section, F3 status notification section, 22 control module, 223 storage (storage section), G1 support processing section, G2 recording processing section, G3 RSU diagnosis section (malfunction detection section), G31 RSU detection section (roadside unit detection unit), G4 communication processing unit (notification processing unit), G5 notification control unit

Claims (10)

An in-vehicle device configured to perform road-to-vehicle communication,
a roadside device detection unit (G31) that detects a forward roadside device that is a roadside device existing in front of the own vehicle;
a malfunction detection unit (G3) that detects a malfunction of the front roadside machine based on data received from the front roadside machine or a reception status of a signal from the front roadside machine;
A notification for performing a notification process that is a process for notifying other in-vehicle devices existing around the host vehicle of a malfunction in the forward roadside device based on the malfunction detection unit detecting a malfunction in the forward roadside device. An on-vehicle device comprising a processing section (G4). The in-vehicle device according to claim 1,
The notification processing unit is configured to determine whether the front roadside unit is a stand-alone type that cannot communicate with the management device, based on map data describing the installation location and type of the roadside unit, or data received from the front roadside unit. Determine whether it is a roadside unit,
An in-vehicle device that performs the notification process based on the fact that the preceding roadside device in which the defect detection unit has detected a defect is the stand-alone roadside device. The in-vehicle device according to claim 2,
The notification processing unit is an in-vehicle device that does not perform the notification process when the roadside machine ahead of which the failure detection unit detected a failure is a network-connected roadside unit that can communicate with the management device. The in-vehicle device according to claim 2 or 3,
As the notification process, a target number field in which an identification number of the stand-alone roadside unit in which a malfunction has been detected is stored, a detection time field in which a detection time is stored, and a status code indicating the content of the malfunction are stored. An on-vehicle device configured to transmit a data set comprising a status field and a status field to the management device. The in-vehicle device according to claim 2 or 3,
As the notification processing, the notification processing unit may perform the notification processing when the network connection type roadside machine that is capable of communicating with the management device is connected for communication, and a malfunction has been detected in the network connection type roadside machine. An on-vehicle device configured to transmit information for a standalone roadside device. The in-vehicle device according to claim 1 or 2,
The malfunction detection unit detects a malfunction in the forward roadside machine based on the fact that the difference between the time information included in the message received from the forward roadside machine and the time information held by the own machine is greater than or equal to a predetermined value. An on-vehicle device that determines that a problem has occurred. The in-vehicle device according to claim 1 or 2,
comprising a storage unit (113) storing data indicating a range in which signals from the forward roadside machine can be received;
The malfunction detection unit detects that there is a malfunction in the forward roadside machine based on the fact that the own machine cannot receive the signal from the forward roadside machine, even though the own machine is in a position where it can receive the signal from the forward roadside machine. An on-vehicle device that determines that a problem has occurred. The in-vehicle device according to claim 7,
If it is detected that a large vehicle is present in front of the own vehicle, the determination process based on the reception status of the signal from the roadside machine in front is canceled, or the determination process based on the reception status of the signal from the roadside machine in front of the vehicle is stopped. An on-vehicle device configured to invalidate the results of determination processing based on . A roadside device that is a communication facility installed along a road and configured to be able to directly communicate wirelessly with an on-vehicle device using a predetermined method,
a self-diagnosis unit (F2) that determines whether or not the self-diagnosis unit is operating normally based on the content of data received from the on-vehicle device;
A roadside device comprising: a status notification section (F3) that transmits a malfunction notification message, which is a message indicating that a malfunction has occurred, to the in-vehicle device based on the detection of a malfunction by the self-diagnosis section. . A roadside unit (1), which is a communication equipment installed along the road,
A road-to-vehicle communication system including an on-vehicle device (2) configured to be able to directly communicate wirelessly with the roadside device in a predetermined manner,
The roadside machine is
a self-diagnosis unit (F2) that determines whether or not the self-diagnosis unit is operating normally based on the content of data received from the on-vehicle device;
a status notification unit (F3) that transmits a malfunction notification message, which is a message indicating that a malfunction has occurred, to the in-vehicle device based on the self-diagnosis unit detecting a malfunction;
Based on receiving the malfunction notification message, the in-vehicle device performs a notification process that is a process for notifying other in-vehicle devices around the vehicle that a malfunction has occurred in the roadside device. A road-to-vehicle communication system including a notification processing unit (G4) that performs the following.

Images