vehicle-mounted unit

Abstract

To provide an on-vehicle device, a roadside unit, and a road-vehicle communication system that allow the on-vehicle device to easily recognize in advance whether or not the roadside unit in front is operating normally.SOLUTION: When an on-vehicle device 2 receives a message from an RSU 1, the on-vehicle device compares time information indicated in the received message and time information held by the own on-vehicle device. Then, the on-vehicle device determines that a problem has occurred in the RSU 1 corresponding to a distribution source, based on a fact that a difference between the two pieces of time information is greater than or equal to a predetermined value. Also, the on-vehicle device 2 determines whether or not the RSU 1 that has been determined to have the problem is a stand-alone type RSU 1 based on the message received from the RSU 1, map data, or the like. When the on-vehicle device 2 detects that there is the problem with the stand-alone type RSU 1, the on-vehicle device notifies a management server and other on-vehicle devices around the own vehicle of the problem.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] This disclosure relates to in-vehicle devices that perform vehicle-to-vehicle communication. Taking the opportunity

Background Art

[0002] Patent Document 1 discloses a vehicle-to-vehicle communication system in which a roadside unit distributes support information related to passing through an intersection to an in-vehicle device. Here, the roadside unit is communication equipment arranged along a road for performing vehicle-to-vehicle communication, and may also be called an RSU (Roadside Unit). The support information related to passing through an intersection includes information regarding the presence of oncoming vehicles and information indicating the shape of the intersection. Based on entering the service area (communication area) of the roadside unit, the in-vehicle device can receive support information from the roadside unit and perform driving support control such as providing information to the driver and automatic acceleration / deceleration / steering.

[0003] In addition, in 3GPP (registered trademark), communication control methods for realizing cellular V2X have been studied (Non-Patent Document 1).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Non-Patent Documents

[0005]

Non-Patent Document 1

[0006] Roadside units are often configured to communicate with a management center via a wide-area communication network. Roadside units connected to the management center can be monitored by the management center to determine whether they are operating normally. If the management center is aware of an issue with a roadside unit, it can notify each in-vehicle unit of the roadside unit's operating status. Based on the notification from the management center, the in-vehicle unit can determine whether the roadside unit ahead is operating normally. The roadside unit ahead corresponds to the roadside unit installed in the section of road that the in-vehicle unit will pass through within a predetermined time.

[0007] On the other hand, in recent years, the introduction of standalone roadside units that do not communicate with a management center is also being considered. Standalone roadside units have advantages such as reduced costs and maintenance expenses, as well as easy installation and removal, but it is difficult for administrators to recognize when a malfunction occurs. Also, if the management center is unaware that a problem has occurred with a roadside unit, the management center cannot notify each vehicle-mounted unit of this fact. From the perspective of a vehicle-mounted unit, it cannot recognize that a problem has occurred with the roadside unit ahead until it enters the communication range of that unit.

[0008] This disclosure is based on the above considerations or points of focus, and one of its purposes is to make it easier for the in-vehicle unit to recognize in advance whether the forward roadside unit is functioning normally. OpportunityThe purpose is to provide. [Means for solving the problem]

[0009] The in-vehicle unit disclosed herein is an in-vehicle unit configured to perform vehicle-to-infrastructure communication and comprises: a roadside unit detection unit (G31) that detects a forward roadside unit which is a roadside unit located in front of the vehicle; a malfunction detection unit (G3) that detects a malfunction in the forward roadside unit based on the data received from the forward roadside unit or the reception status of signals from the forward roadside unit; and a notification processing unit (G4) that performs a notification process, which is a process for notifying other in-vehicle units located around the vehicle of the malfunction in the forward roadside unit, based on the malfunction detection unit's detection of a malfunction in the forward roadside unit. The notification processing unit determines whether the roadside unit ahead is a standalone roadside unit 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 roadside unit ahead. Based on the fact that the roadside unit ahead from which the malfunction detection unit has detected a malfunction is a standalone roadside unit, the notification processing is performed. . Furthermore, other disclosures relating to an in-vehicle unit include an in-vehicle unit configured to enable vehicle-to-infrastructure communication, comprising: a roadside unit detection unit (G31) that detects a forward roadside unit which is a roadside unit located in front of the vehicle; a malfunction detection unit (G3) that detects a malfunction in the forward roadside unit based on data received from the forward roadside unit or the reception status of signals from the forward roadside unit; and a notification processing unit (G4) that performs a notification process to notify other in-vehicle units located around the vehicle of the malfunction of the forward roadside unit based on the malfunction detection unit's detection of a malfunction in the forward roadside unit, and a storage unit (113) that stores data indicating the range in which signals from the forward roadside unit can be received, wherein the malfunction detection unit determines that a malfunction has occurred in the forward roadside unit based on the fact that it cannot receive a signal from the forward roadside unit despite being in a position where it can receive signals from the forward roadside unit, and if the presence of a large vehicle is detected in front of the vehicle, it is configured to either cancel the determination process based on the reception status of signals from the forward roadside unit or invalidate the result of the determination process based on the reception status of signals from the forward roadside unit.

[0010] With the above configuration, even if a standalone roadside unit malfunctions, the malfunction will be detected by the on-board unit and notified to other on-board units in the vicinity of the vehicle. Therefore, each on-board unit will be more likely to recognize that a malfunction has occurred in the roadside unit ahead based on the notification from the on-board unit installed in the preceding vehicle.

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

[0016] [Figure 1] This diagram illustrates the overall structure of the vehicle-to-infrastructure communication system. [Figure 2] This figure shows examples of code assignments for various RSU states. [Figure 3] This block diagram shows an example of a standalone RSU configuration. [Figure 4] This is a functional block diagram of the RSU control unit. [Figure 5] This diagram illustrates the structure of an RSU message. [Figure 6]It is a flowchart of the reference image registration process. [Figure 7] It is a flowchart of the image-based diagnosis process. [Figure 8] It is a flowchart of the time-based diagnosis process. [Figure 9] It is a block diagram showing the configuration of the in-vehicle system. [Figure 10] It is a functional block diagram of the control module. [Figure 11] It is a diagram for explaining the operation of the recording processing unit G2. [Figure 12] It is a diagram showing an example of the content of the RSU data. [Figure 13] It is a diagram for explaining the configuration of the defect detection message. [Figure 14] It is a flowchart for explaining the operation of the in-vehicle device regarding the reporting of defects to the management server. [Figure 15] It is a flowchart of the GNSS-based diagnosis process. [Figure 16] It is a flowchart of the wireless function diagnosis process.

Mode for Carrying Out the Invention

[0017] Hereinafter, one embodiment of the vehicle-to-vehicle communication system Sys of the present disclosure will be described with reference to the drawings. As shown in FIG. 1, the vehicle-to-vehicle communication system Sys includes a plurality of RSUs (Roadside Units) 1, a plurality of in-vehicle devices 2, and a management server 3.

[0018] The RSU 1 is wireless communication equipment arranged along the road and is configured to be able to perform short-range communication. The short-range communication in the present disclosure refers to communication directly performed between devices. The short-range communication refers to communication conforming to a predetermined wireless communication standard where the substantial communication distance is, for example, about 150 m or 250 m.

[0019] For short-range communication standards, any of the following can be adopted: DSRC (Dedicated Short Range Communications) which conforms to the IEEE 802.11p standard, WAVE (Wireless Access in Vehicular Environment), or Cellular V2X (PC5 / SideLink). IEEE (registered trademark) is an abbreviation for the Institute of Electrical and Electronics Engineers, referring to the American Institute of Electrical and Electronics Engineers.

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

[0021] RSU1 is sometimes referred to as a roadside unit. Communication between RSU1 and the in-vehicle unit 2 can also be called vehicle-to-infrastructure communication or V2I communication. The "I" in V2I stands for Infrastructure and refers to RSU1. In this disclosure, messages (radio signals) that conform to the narrow-range communication standard are referred to as V2X messages. V2X messages from RSU1 to the in-vehicle unit 2 are also referred to as RSU messages.

[0022] RSU1 distributes support data, which is information to assist with driving operations / autonomous driving, to the in-vehicle unit 2. Support data is a dataset that shows, for example, information on moving objects / obstacles within a predetermined distance from an intersection, and road surface conditions. Since this support data shows traffic conditions near the intersection where RSU1 is installed, it can also be called intersection-related data. The support data may also be a dataset showing traffic conditions near highway merging / diverging points. The content of the support data may vary depending on the installation location of RSU1. In this disclosure, a collection of data on multiple items is referred to as a dataset. The term dataset can also be replaced with data unit / package / message / packet / frame, etc.

[0023] Among the multiple RSU1 units, there may be RSU1 units that are connected to the management server 3 and RSU1 units that are not connected to the management server 3, so-called standalone (SA) type RSU1 units. In this disclosure, RSU1 units that are connected to the management server 3 are referred to as connected RSU1B units, and RSU1 units that cannot communicate with the management server 3 are also referred to as independent RSU1A units. Independent RSU1A units can also be called standalone RSU units or standalone roadside units. Independent RSU1A units may include RSU1 units that are temporarily / accidentally out of communication with the management server 3 due to a communication line malfunction.

[0024] A connected RSU1B communicates with the management server 3, for example, via a WAN (Wide Area Network) 9. The WAN 9 is a TCP (Transmission Control Protocol) / IP (Internet Protocol) network, such as the Internet. The WAN 9 may be any other type of communication network. The connected RSU1B may also be connected to the management server 3 via a virtual / physical private network / dedicated line. In addition, some RSU1s may be configured to communicate indirectly with the management server 3 via road-to-road communication. Road-to-road communication refers to narrow-area communication between RSU1s. A connected RSU1B is equivalent to a network-attached roadside unit.

[0025] RSU1 can be placed at any location along the road. This includes not only the sides of the road but also the area above the road surface. RSU1 may also be embedded in the road surface as a marker.

[0026] RSU1 may be implemented as a multi-functional utility pole equipped with devices such as cameras, sensors, and communication equipment to detect vehicles and pedestrians around an intersection. In one embodiment, RSU1 detects pedestrians and vehicles approaching the intersection in real time and transmits data indicating the location of the detected objects to the in-vehicle unit 2.

[0027] A pole-type RSU1 can also be called a smart pole or ITS (Intelligent Transport Systems) pole. Of course, the shape of the RSU1 is not limited to a pole; it can also be box-shaped, signboard-shaped, etc. The RSU1 can be installed as an add-on to a utility pole, etc. The RSU1 can also be portable.

[0028] Each RSU1 has a monitoring area, which is the range in which objects are to be detected, and a distribution area, which is the range in which support data is to be distributed. The distribution area can also be called the service area or service spot. RSU1 uses cameras 15, etc., as described later, to identify the position, speed, direction of movement, type, etc. of moving objects within the monitoring area. Moving objects include pedestrians, kick scooters, vehicles, etc. Vehicles also include bicycles, mopeds, electric kick scooters, and motorcycles.

[0029] The monitoring area and the distribution area may or may not coincide. The monitoring area of ​​an RSU1 placed at an intersection may be designed appropriately considering the shape of the intersection where the RSU1 is installed. Similarly, the distribution area may be designed according to the characteristics of the location where the RSU1 is installed. For example, an RSU1 placed at an intersection may detect moving objects within a predetermined distance from the intersection and distribute information about the detected moving objects to an in-vehicle unit 2 within a predetermined distance from the intersection.

[0030] The on-board unit 2 is a communication device that performs wireless communication with other vehicles and RSU 1. The on-board unit 2 is installed and used in each of multiple vehicles. The on-board unit 2 is configured to enable short-range communication with other on-board units 2 and RSU 1. Although only one vehicle equipped with an on-board unit 2 is shown in Figure 1, the system as a whole may actually consist of two or more units. In this disclosure, for a given on-board unit 2, the vehicle in which that on-board unit 2 is installed is referred to as "its own vehicle," and other vehicles are referred to as "other vehicles."

[0031] Furthermore, in this disclosure, the in-vehicle unit 2 itself may be referred to as "its own unit" to distinguish it from other in-vehicle units 2, and an in-vehicle unit 2 used in another vehicle may be referred to as "another unit." Since there is a one-to-one relationship between a vehicle and an in-vehicle unit 2, the expression "vehicle" as the source / destination of wireless signals / data / packets can be read as "in-vehicle unit." Therefore, the terms "its own unit" and "another unit" in the following explanation may be interpreted as "its own vehicle" and "another vehicle."

[0032] Each in-vehicle unit 2 periodically transmits a vehicle status message via narrow-range communication, indicating information about its own vehicle. For example, each in-vehicle unit 2 may periodically transmit a message indicating the source information, transmission time, current location, direction of travel, driving speed, acceleration, steering angle, and turn signal / wiper operation status as a vehicle status message. The messages transmitted by the in-vehicle unit 2 may be a CAM (Cooperative Awareness Message) as defined in ETSI standard TS 102 637-2 or a BSM (Basic Safety Message) as defined in SAE standard J 2735. Each message may include information indicating the transmission time.

[0033] Furthermore, each in-vehicle unit 2 may transmit a message indicating information about the surrounding environment when a predetermined event is detected. The message transmitted by the in-vehicle unit 2 may be an event message such as a DENM (Decentralized Environmental Notification Message) as defined in the ETSI standard TS 102 637-3.

[0034] Management Server 3 is the equipment that manages RSU1. Management Server 3 corresponds to the management device. Management Server 3 can diagnose whether the connected RSU1B is operating normally by communicating bidirectionally with the connected RSU1B, for example, via WAN9. Diagnostic methods include the watchdog timer method and the homework answer method. The watchdog timer method is a method in which a malfunction is determined in the monitored device if the watchdog timer on the monitoring device expires without being cleared by a watchdog pulse input from the monitored device. The homework answer method is a method in which the monitoring device sends a predetermined monitoring signal to the monitored device, and the monitoring device determines whether it is operating normally based on whether the answer sent back from the monitored device is correct or not. In the homework answer method, the monitored device generates a response signal corresponding to the monitoring signal input from the monitoring device and sends it back to the monitoring device. Here, Management Server 3 corresponds to the monitoring device, and connected RSU1B corresponds to the monitored device.

[0035] Each RSU1 may be equipped with a self-diagnostic function, as described later. The management server 3 may recognize the status of the reporting source for connected RSU1B by receiving the self-diagnostic results reported from the RSU1. In addition, the management server 3 may recognize the status of standalone RSU1A based on reports from the in-vehicle unit 2, as described later.

[0036] The RSU1 status indicates whether it is operating normally or if some functions are malfunctioning. The RSU1 status can be categorized into five patterns, for example: (A) Normal, (B) Camera malfunction, (C) GNSS malfunction, (D) Radar malfunction, and (E) Other malfunction. Here, a malfunction refers to a state that is not normal. A malfunction can be rephrased as a failure, fault, or abnormality.

[0037] "Camera malfunction" means that there is a malfunction in the camera installed in RSU1. "GNSS malfunction" means that there is a malfunction in the GNSS receiver installed in RSU1. GNSS stands for Global Navigation Satellite System, which means a global positioning satellite system. GNSS systems such as GPS (Global Positioning System), GLONASS, Galileo, IRNSS, QZSS, and Beidou can be used.

[0038] "Radar malfunction" means that there is a malfunction in the millimeter-wave radar / LiDAR installed in RSU1. LiDAR is an abbreviation for Light Detection and Ranging or Laser Imaging Detection and Ranging. The concept of LiDAR can include ToF (Time of Flight) cameras that generate distance images using the round-trip time of light. Note that malfunctions of ToF cameras may be classified as camera malfunctions. "Other malfunctions" indicates malfunctions in areas other than those mentioned above, or malfunctions with an unknown cause. In addition to "Other malfunctions," there may also be a category for "Cause Unknown."

[0039] The status of RSU1 can be represented by a predetermined number of bit sequences / codes. In this embodiment, the status code is represented by 4 bits as an example. For example, as shown in Figure 2, "normal" corresponds to 0000, "camera malfunction" to 0001, "GNSS malfunction" to 0010, "radar malfunction" to 0100, and "other malfunction" to 1000. The above setting example (assignment example) corresponds to a configuration in which each bit is assigned to a malfunction location. That is, the position of the bit set to "1" indicates the location where the malfunction occurred. In the above example, the camera is assigned to the 4th bit (rightmost), the GNSS receiver to the 3rd bit, the millimeter-wave radar to the 2nd bit, and other parts to the 1st bit. Of course, the status code may also consist of 6 bits or 8 bits.

[0040] If malfunctions are detected in multiple locations on the RSU1, the status code may have multiple bits corresponding to the malfunctions set to 1. For example, if there are malfunctions in the camera and GNSS receiver, the status code may be set to 0011. The status code may also be expressed as the logical OR of the status codes for each malfunction location. A backup code (e.g., 1000) may be provided as a status code.

[0041] The RSU1 status codes may include codes corresponding to sonar malfunctions, such as "sonar malfunction," and radio interference detection. Furthermore, if various types of cameras are expected, such as color cameras, infrared cameras, and ToF cameras, the "camera malfunction" code may be further subdivided according to the camera type. The RSU1 status may also be evaluated in two stages: normal / malfunction.

[0042] In addition, when the management server 3 detects a problem 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 the staff engaged in the operations related to the OAM (Operation Administration and Maintenance) of the RSU 1. Further, the management server 3 distributes the information of the RSU 1 in which the problem has occurred to the in-vehicle unit 2 moving toward the RSU 1. The information distribution to the in-vehicle unit 2 may be carried out by vehicle-to-roadside communication using another RSU 1 or by cellular communication. The in-vehicle unit 2 may acquire the information of the RSU 1 in which the problem has occurred from the management server 3. In addition, the management server 3 may distribute to each in-vehicle unit 2 not only the data of the RSU 1 in which the problem has occurred but also the data indicating whether the RSU 1 is operating normally.

[0043] <Regarding the Configuration and Function of the RSU> Here, taking the independent type RSU 1A as an example, the configuration and function of the RSU 1 will be described. As shown in FIG. 3, the independent type RSU 1A includes an RSU control unit 11, a wireless unit 12, a GNSS receiver 13, a millimeter-wave radar 14, a camera 15, and an image analysis unit 16.

[0044] 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 communicate with each of the components, such as the wireless unit 12. The RSU control unit 11 is configured as a computer, for example, equipped with a processor 111, memory 112, storage 113, input / output circuit (I / O) 114, etc. The processor 111 is, for example, a CPU (Central Processing Unit). The memory 112 is, for example, a volatile storage medium such as RAM (Random Access Memory). The processor 111 performs various processes to realize the functions of each functional unit, which will be described later, by accessing the memory 112. The storage 113 is configured to include a non-volatile storage medium such as flash memory. The storage 113 stores RSU programs, which are programs for realizing various functions / services. The input / output circuit 114 is a circuit module for the RSU control unit 11 to send and receive signals with other devices.

[0045] In this disclosure, the RSU1 in which the RSU control unit 11 contains itself will be referred to as its own unit / affiliated unit. RSU1 other than the affiliated unit will be referred to as other units. The functions of the RSU control unit 11 will be described later.

[0046] The wireless unit 12 is a communication module for performing narrow-area communication. The wireless unit 12 comprises an antenna, a transmission processing unit, and a reception processing unit. The antenna is for transmitting and receiving radio waves in the frequency band used for narrow-area communication. The transmission processing unit modulates the data input from the RSU control unit 11 and outputs it to the antenna for wireless transmission. The reception processing unit is configured to demodulate the signal received by the antenna and output it to the RSU control unit 11.

[0047] The GNSS receiver 13 is a device that receives navigation signals transmitted from positioning satellites that constitute the GNSS and sequentially calculates its current position (for example, every 100 milliseconds). The current position data can be expressed as latitude, longitude, altitude, etc. The GNSS receiver 13 transmits the calculated position data to the RSU control unit 11.

[0048] Furthermore, the GNSS receiver 13 determines 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 the time error information identified during position calculation and output it to the RSU control unit 11.

[0049] The millimeter-wave radar 14 acquires information about objects present in the monitoring area by transmitting and receiving millimeter waves or sub-millimeter waves. Specifically, it detects objects present in the monitoring area and estimates the direction, distance, relative velocity, and type of the detected objects. The millimeter-wave radar 14 outputs radar detection data to the RSU 11, indicating the position, type, direction of movement, and speed of movement for each detected object.

[0050] Camera 15 is an optical camera configured to include the monitoring area in its imaging range. Camera 15 may also be an infrared camera or the like. The image data generated by camera 15 is input to the image analysis unit 16. The term "image data" here may be interpreted as "video signal".

[0051] The image analysis unit 16 detects moving objects within the monitoring area by analyzing the images generated by the camera 15. The image analysis unit 16 may also be configured to detect obstacles that affect vehicle movement, in addition to moving objects. Obstacles include, for example, road construction signs, cones, puddles, snow-covered areas, and fallen objects. The image analysis unit 16 outputs camera detection data, which is a dataset showing the location of the detected moving objects / obstacles, to the RSU 11. The camera detection data may include the location, type, direction of movement, and speed of movement for each detected object. The functions of the image analysis unit 16 may be built into the camera 16 / RSU control unit 11.

[0052] The millimeter-wave radar 14 and camera 15 are examples of area monitoring sensors for detecting traffic conditions within the monitoring area. RSU1 may be equipped with multiple millimeter-wave radars 14 and cameras 15. RSU1 may also be equipped with sonar, LiDAR, or other area monitoring sensors. The millimeter-wave radar 14 and camera 15 are not essential elements for RSU1 and may be omitted. The combination of area monitoring sensors equipped in RSU1 can be changed as appropriate.

[0053] As shown in Figure 4, the RSU control unit 11 includes a support information distribution unit F1, a self-diagnosis unit F2, and a status notification unit F3, which are functional units that are activated when the processor 111 executes the RSU program stored in the storage 113.

[0054] The support information distribution unit F1 generates support data indicating traffic conditions within the monitoring area based on the output data from the area monitoring sensors. The output data from the area monitoring sensors includes radar detection data, camera detection data, and image data. The support information distribution unit F1 may also combine the output data from multiple area monitoring sensors to detect traffic conditions within the monitoring area.

[0055] Furthermore, the support information distribution unit F1, in cooperation with the wireless unit 12, wirelessly transmits support data generated from the area monitoring sensor to the in-vehicle unit 2. In this disclosure, the wireless / electrical signals corresponding to the communication packets containing the support data are also referred to as support messages. In this disclosure, the term "support data" can be appropriately replaced with "support message" in the interpretation. The support message corresponds to a MAP message, which is one of the RSU messages.

[0056] RSU1 distributes support messages via broadcast. The generation / transmission cycle of support messages by the support information distribution unit F1 may be limited to approximately once every 100 milliseconds to 1 second.

[0057] RSU1 may also deliver support messages in the form of unicast, multicast, or geocast. Geocast is a flooding-type communication method that specifies the destination using location information. With geocast, in-vehicle devices 2 located within the area designated as the geocast area can receive the message. Geocast allows data to be delivered without specifying the identification information of in-vehicle devices 2 located within the area to which the information is to be delivered.

[0058] In addition, RSU1 may be configured to periodically send advertisement messages separate from support messages. The advertisement message is a message to notify the in-vehicle unit 2 of the presence of the unit and includes information such as the RSU-ID, installation location, transmission time, service type, and RSU type. The advertisement message may be a simple message that focuses on the contents of the header described above. The advertisement message can also be called a service announcement, which is a message to notify the surroundings of the services that the unit provides.

[0059] The self-diagnosis unit F2 is a functional unit that diagnoses whether or not the unit to which it belongs is functioning normally. The self-diagnosis unit F2 is configured to perform either image-based diagnostic processing or time-based diagnostic processing, or both, as part of its self-diagnosis process.

[0060] Image-based diagnostic processing determines the operating status of camera 15 by comparing the current camera image with previously captured camera images. Time-based diagnostic processing determines whether the GNSS receiver 13 is operating normally by comparing the time information received from the in-vehicle unit 2 with the time information held by the unit itself. If there is a malfunction 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 the RSU time. Details of the image / time-based diagnostic processing will be described separately.

[0061] In addition, the self-diagnosis unit F2 may diagnose the millimeter-wave radar 14 by comparing the detection results from the millimeter-wave radar 14 with the moving object / obstacle information within the intersection received from the in-vehicle unit 2. Alternatively, the camera 15 or the millimeter-wave radar 14 may be diagnosed by comparing the camera detection data with the 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 something 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 something detected by the millimeter-wave radar 14 is not detected by the camera 15.

[0062] Furthermore, the self-diagnosis unit F2 may detect a malfunction in the radio unit 12 based on the fact that the noise level observed by the radio unit 12 remains above a predetermined value for a predetermined period of time or longer. Note that a malfunction in the radio unit 12 may include not only a malfunction in the radio unit 12 itself, but also the reception of interfering radio waves.

[0063] The self-diagnostic unit F2 may detect a malfunction in the GNSS receiver 13 by comparing the registered installation location, which is the installation location coordinates registered in advance by the administrator / installer, with the latest positioning calculation result input from the GNSS receiver 13. For example, if the difference between the registered installation location and the positioning calculation result is greater than or equal to a predetermined value, it may be determined that there is a malfunction in the GNSS receiver 13. Alternatively, it may be determined that there is a malfunction in the GNSS receiver 13 based on the fact that no current location data has been input from the GNSS receiver 13 for a certain period of time (for example, 1 hour).

[0064] Furthermore, the self-diagnosis unit F2 may also detect malfunctions in the RSU control unit 11 / communication partner by performing bidirectional communication with the microcomputers provided in the wireless unit 12 and the image analysis unit 16. Methods for detecting malfunctions through bidirectional communication include watchdog timer methods and homework answering methods.

[0065] If the self-diagnostic unit F2 determines that a malfunction has occurred in its own unit, it may identify the location of the malfunction. The self-diagnostic unit F2 may be configured to identify, for example, whether the malfunction is in the wireless unit 12, the GNSS receiver 13, the millimeter-wave radar 14, the camera 15, or the RSU control unit 11. In other words, the self-diagnostic unit F2 may also determine whether each of the devices constituting its own unit is functioning normally.

[0066] The status notification unit F3 is configured to notify an external device of the diagnostic results of the self-diagnosis unit F2. This external device may include the in-vehicle unit 2, the management server 3, or other RSU1s. For example, the status notification unit F3 periodically transmits a support message from the wireless unit 12, which contains a status code corresponding to the diagnostic result in the V2X header. This allows the in-vehicle unit 2 to recognize the status of the sending RSU1 based on the received support message.

[0067] The support message comprises a V2X header and a payload section, as shown in Figure 5, for example. The status code may be inserted into the V2X header. The payload section is the area where the support data is contained. The V2I header includes the 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 specification the message conforms to. The message set corresponds to a so-called data format that defines the order of information contained in the message.

[0068] The message version is data indicating the version of the message set's definition specification. The service type is data indicating the type of service provided by RSU1 as the sender. The RSU-ID is the identification number (ID) of RSU1. The installation location indicates the coordinates of the RSU1's installation location. The target area indicates the area to which RSU1 provides its service, i.e., the distribution area. The target area can be expressed, for example, by the coordinates of the center of the area and the area radius. The target area may also be expressed only by the distance (radius) from the RSU installation location. For example, if the target area value is set to 25m, the target area may be within 25m from the RSU installation location / specified reference point.

[0069] The transmission time indicates the transmission time of the message. The RSU type indicates whether RSU1, as the sender, is connected or isolated. The RSU type can also be represented by a single bit (0 / 1) or a multi-bit code. For example, isolated can be represented by "0" and connected by "1". The RSU type can also be called an RSU attribute or network type. The data indicating the RSU type corresponds to data indicating whether or not the message sender RSU1 is connected to WAN9 in a given situation, and can therefore also be called network connection information. The status can be represented by the status code mentioned above. D11 to D19 in Figure 5 represent data fields where various types of data are placed. For example, data field D11 indicates the area where the bit sequence indicating the message set ID is placed.

[0070] In addition, RSU1 may send a dedicated message to notify the status of its own unit, separate from support messages. In this disclosure, an RSU message containing data indicating the status of RSU1 is also referred to as a status message. Among the status messages, an RSU message containing a code indicating a malfunction is also referred to as a malfunction notification message, and an RSU message containing a code indicating normal operation is also referred to as a normal notification message. A malfunction notification message may also be called an error message. RSU1 may make an advertised message function as a status message by inserting a status code into a predetermined area of ​​the advertised message, such as the options area.

[0071] Furthermore, the status notification unit F3 may omit sending a status message if it is functioning normally. The status notification unit F3 may also be configured to send a malfunction notification message to the in-vehicle unit 2 only when a malfunction is detected in its own unit. This configuration reduces the risk of unintentionally consuming narrow-area communication resources.

[0072] In this embodiment, the status code includes information indicating the location of the malfunction. Therefore, the malfunction notification message not only indicates that a malfunction has occurred in RSU1, but also indicates the details of the malfunction, i.e., the location of the malfunction. Thus, RSU1 may send a message containing a status code corresponding to the detected malfunction as a malfunction notification message. In other embodiments, the malfunction notification message may be a message indicating that some kind of malfunction has occurred in RSU1. The malfunction notification message may also be a message simply indicating that the service is stopped.

[0073] <Supplementary information on the configuration of connected RSUs> The connected RSU1B differs from the standalone RSU1A in that it includes a WAN module, but its other configurations can be the same as those of the standalone RSU1A. The WAN module is a communication module for RSU1 to connect to WAN9. The WAN module receives data from the management server 3 and outputs it to the RSU control unit 11, and modulates the data input from the RSU control unit 11 and transmits it to the management server 3. RSU1 may be connected to WAN9 via a wired connection or via a wireless connection. In other words, the WAN module 17 may be a signal processing module including a connector for wired connection, or it may be a wireless module for cellular communication. Cellular communication in this disclosure refers to wireless communication using mobile phone lines provided by mobile communication carriers, such as LTE (Long Term Evolution) / 4G, 5G, etc.

[0074] The self-diagnostic unit F2 of the connected RSU1B may be configured to diagnose whether the WAN module is functioning correctly. The status notification unit F3 of the connected RSU1B may periodically send the self-diagnostic results and data on moving objects / obstacles within the monitoring area to the management server 3 in response to inquiries from the management server 3.

[0075] <About image-based diagnostic processing> This section describes image-based diagnostic processing. Image-based diagnostic processing requires a reference image registration process as a preparatory step.

[0076] The reference image registration process is a process for generating a reference image to be used as a basis for determining whether the camera 15 (e.g., image sensor) is functioning correctly, and registering it in the storage 113. The reference image registration process includes, for example, the steps of acquiring an image captured by the camera 15 (S11), generating a reference image based on the acquired image (S12), and saving the generated reference image to the storage 113 or the like (S13), as shown in Figure 6.

[0077] The reference image is image data of stationary objects, obtained by removing moving objects such as cars and pedestrians from the captured image generated by camera 15. The reference image can also be called a fixed image. The reference image may be generated by combining multiple camera images taken at different times. With a configuration that generates a comparison image based on multiple images taken at different times (frames), the road surface image of an area where a moving object was captured in one frame can be supplemented by images from other frames.

[0078] Such reference image registration processing can be triggered by a specific operation performed by the installer during the installation of RSU1, such as pressing the record button. The reference image registration processing may also be performed periodically, such as monthly. Furthermore, the self-diagnosis unit F2 may generate reference images for each time period / weather and save them in storage 113.

[0079] Image-based diagnostic processing can be performed periodically, for example, at intervals of 10 seconds, 1 minute, or 10 minutes. As shown in Figure 7, image-based diagnostic processing includes steps S21 to S26. Step S21 is the step of acquiring the current image. The current image is the latest image generated by camera 15. Step S22 is the step of generating a comparison image based on the current image acquired in step S21. The comparison image is an image obtained by removing moving objects from the current image, or an image obtained by extracting the region in which a fixed / still object is captured from the current image. The comparison image may also be generated by combining multiple images captured within a short period of time. Step S23 calculates the difference between the reference image registered in 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 inverse of the similarity between the images. If the similarity is expressed as a percentage, the degree of mismatch can be obtained by subtracting the similarity from 100. Image comparison may also be performed by comparing features such as edges.

[0080] If the difference between the two images is less than a predetermined value (S24 NO), the self-diagnosis unit F2 determines that the camera 15 is normal (S25). 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 a predetermined value, the self-diagnosis unit F2 determines that there is a malfunction in the camera 15 / self unit (S26).

[0081] The image-based diagnostic process described above makes it possible to verify whether or not camera 15 is functioning correctly. Note that the image-based diagnostic process may be omitted during rainy or snowy weather. It is preferable to perform the image-based diagnostic process when the weather and time of day coincide to some extent with the time of reference image generation.

[0082] <About time-based diagnostic processing> This section explains time-based diagnostic processing.

[0083] The time-based diagnostic process comprises steps S31 to S39, as shown in Figure 8. Step S31 is the step of receiving a message transmitted from the in-vehicle unit 2 via narrow-range communication. Step S32 is the step of extracting vehicle time information contained in the received message and storing it in memory 112. The vehicle time information is the time information contained in the message received from the in-vehicle unit 2.

[0084] Steps S31 to S32 described above are performed as needed. Steps S31 to S32 may also be performed in parallel while processing from step S33 onwards is being carried out. If multiple in-vehicle devices 2 are present around RSU1, RSU1 may receive messages from multiple in-vehicle devices 2 within a certain time (250 milliseconds / 500 milliseconds). Accordingly, it can be expected that vehicle time information from multiple in-vehicle devices 2 will be accumulated in memory 112.

[0085] Step S33 calculates the mean (μ) and standard deviation (σ) of multiple vehicle time information acquired within a fixed time interval (e.g., 200 milliseconds) stored in memory 112, using this information as a population. Statistical indicators such as variance or range can also be used instead of standard deviation. Range, as a statistical indicator, 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 the average time. The average time corresponds to the average value of the times held by multiple in-vehicle devices 2 located within the communication area of ​​RSU 1. If the number of elements in the population is less than a predetermined value (e.g., 5 or 10), the execution of subsequent processing may be stopped, and steps S33 and beyond may be performed after a predetermined time interval. Step S33 may be performed at regular time intervals.

[0086] If the standard deviation calculated in step S33 is greater than or equal to a predetermined value (S34 NO), the self-diagnosis unit F2 adjusts the population. For example, it generates a population from which vehicle time information that deviates from the mean by more than a predetermined value is removed, and then recalculates the mean and standard deviation using this adjusted population. By repeating steps S33 to S34, a highly accurate current time is identified.

[0087] On the other hand, if the standard deviation calculated in step S33 is less than a predetermined value (S34 YES), the self-diagnostic 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 RSU1 and is an element that can be corrected at any time by the GNSS receiver 13.

[0088] The self-diagnosis unit F2 determines that the GNSS receiver 13 is functioning normally if the difference between the internal time and the average time is less than a predetermined value (S37 YES). On the other hand, the self-diagnosis unit F2 determines that there is a malfunction in the GNSS receiver 13 / self unit if the difference between the internal time and the average time is greater than or equal to a predetermined value (S37 YES).

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

[0090] The V2X module 21 is a communication module for performing narrow-area communication. Similar to the radio unit 12, the V2X module 21 is equipped with an antenna, a transmission processing unit, and a reception processing unit for performing narrow-area communication. The V2X module 21 is connected to the control module 22. The V2X module 21 transmits a radio signal that has undergone signal processing such as modulation on the baseband signal input from the control module 22. The V2X module 21 also outputs received data obtained by performing signal processing such as demodulation on the signal received via the antenna to the control module 22. For example, the V2X module 21 receives support messages / data distributed from the RSU1 and inputs them to the control module 22.

[0091] The control module 22 is configured as a computer, equipped with a processor 221, memory 222, storage 223, input / output (I / O) circuit 224, etc. The processor 221 is, for example, a CPU. The memory 222 is, for example, a volatile storage medium such as RAM. The processor 221 performs various processes to realize the functions of each functional unit, which will be described later, by accessing the memory 222. The storage 223 is configured to include a non-volatile storage medium such as flash memory. The vehicle program, which is a program for the in-vehicle unit 2, is stored in the storage 223. The storage 223 corresponds to the storage unit. The input / output circuit 224 is a circuit module for the in-vehicle unit 2 to send and receive signals with other devices. The functions of the control module 22, in other words, the functions of the in-vehicle unit 2, will be described separately.

[0092] In this embodiment, the V2X module 21 and the control module 22 are implemented as a single device (ECU: Electronic Control Unit), but this is not limited to this configuration. The V2X module 21 and the control module 22 may be implemented as separate devices. For example, the V2X module 21 may be implemented as a V2X in-vehicle unit, and the control module 22 may be implemented as a driver assistance ECU, each separately.

[0093] The locator 41 is a device that calculates and outputs the vehicle's position coordinates using navigation signals transmitted from positioning satellites that constitute a GNSS. The locator 41 includes, for example, a GNSS receiver, an inertial sensor, and map memory. The inertial sensor is, for example, a gyroscope or an accelerometer. The map memory is a storage medium in which map data is stored. The locator 41 sequentially determines the position (hereinafter referred to as "vehicle position") and direction of movement of the vehicle equipped with the locator 41 by combining the positioning signals received by the GNSS receiver, the detected values ​​from the inertial sensor, and the road shape shown in the map data. The vehicle position is represented, for example, by three-dimensional coordinates of latitude, longitude, and altitude. The vehicle position data detected by the locator 41 is input to the in-vehicle unit 2. The locator 41 may also be a navigation device.

[0094] The surrounding monitoring sensor 42 is a sensor that outputs signals indicating the surrounding environment of the vehicle. Cameras that image the outside of the vehicle, millimeter-wave radar, LiDAR, and sonar are examples of surrounding monitoring sensors 42. The surrounding monitoring sensor 42 detects objects within its detection range around the vehicle and inputs data indicating the position, speed, and type of the detected objects to the in-vehicle unit 2. For example, the in-vehicle system VS is equipped with a front camera and a front radar as surrounding monitoring sensors 42. The front camera is, for example, an optical / infrared camera positioned to image the area 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 interior side of the vehicle, or on the front grille, rooftop, etc. The front radar is a millimeter-wave radar installed on the front of the vehicle, such as the front grille or front bumper. The front radar detects the distance, relative speed, and relative position of objects in front of the vehicle, such as a preceding vehicle.

[0095] The vehicle sensor 43 is a group of sensors that detect information about the state of the vehicle. The vehicle sensor 43 includes a vehicle speed sensor, a steering angle sensor, an acceleration sensor, a yaw rate sensor, etc. The vehicle speed sensor detects the vehicle's speed. The steering angle sensor detects the steering angle. The acceleration sensor detects acceleration such as longitudinal acceleration and lateral acceleration of the vehicle. The yaw rate sensor detects the vehicle's angular velocity. The vehicle sensor 43 inputs data indicating the current value (i.e., detection result) of the physical state quantity to be detected to the on-board unit 2. The types of vehicle sensors connected to the on-board unit 2 can be designed as appropriate, and it is not necessary to have all of the above-mentioned sensors. Signals indicating the shift position and signals indicating the operation status of the turn signals may also be input to the on-board unit 2.

[0096] The cellular communication unit 44 is a communication module for performing cellular communication. For example, the cellular communication unit 44 transmits and receives radio waves to and from base stations around the vehicle using wireless communication in accordance with cellular communication standards such as 5G. The cellular communication unit 44 transmits data input from the in-vehicle unit 2 to the management server 3. The cellular communication unit 44 also receives data from the management server 3 destined for the in-vehicle unit 2 and inputs it to the in-vehicle unit 2.

[0097] The display 45 is, for example, a liquid crystal display or an organic EL display. The display 45 may also be a head-up display. The display 45 displays an image corresponding to an input signal from the in-vehicle unit 2. The speaker 46 is a device that converts electrical signals into sound and outputs it. The speaker 46 outputs sound corresponding to the electrical signal input from the in-vehicle unit 2. The sounds in this disclosure include voice messages, notification sounds, warning sounds, sound effects, music, etc.

[0098] The drive system 47 is a system that includes actuators for driving the vehicle and an ECU for controlling them. The components of the drive system 47 may include some or all of the following: a power unit ECU that controls the drive source such as the engine or the drive motor, a brake actuator, a brake ECU, an EPS (Electric Power Steering) motor, and a steering ECU.

[0099] As shown in Figure 10, the control module 22 includes a support processing unit G1, a recording processing unit G2, an RSU diagnostic unit G3, a communication processing unit G4, and a notification control unit G5, which are functional units realized by the execution of a vehicle program by the processor 221. The RSU diagnostic unit G3 includes an RSU detection unit G31 as a sub-functional unit.

[0100] The support processing unit G1 performs driving assistance based on the support data received from the RSU1. For example, the support processing unit G1 notifies the driver of other moving objects approaching the vehicle within an intersection. More specific examples include notifying the driver of the presence of oncoming vehicles when turning right, or notifying the driver of the presence of pedestrians / cyclists who may be in danger of colliding with the vehicle.

[0101] Notifications to the driver can be implemented through methods such as displaying an image on the display 45, outputting an audio message / warning sound from the speaker 46, illuminating an indicator, or applying vibration. The support processing unit G1 may also perform vehicle control such as braking or steering, in addition to notifying the driver, as part of its driving support processing. In this disclosure, "driver" refers to a person seated in the driver's seat, i.e., the driver's seat occupant. The concept of a driver may also include a person remotely operating the vehicle.

[0102] As shown in Figure 11, when the recording processing unit G2 receives an RSU message (S41), it records data about the sending RSU1 in the storage 223 (S42). In this disclosure, the list of RSU1s that have previously received messages is referred to as usage history data.

[0103] The usage history data includes RSU data, which is detailed data for each RSU1. For example, each RSU data may include installation location, RSU-ID, distribution area, RSU type, service type, etc., as shown in Figure 12. The RSU data may also include the usage count, which is the number of times the service of that RSU1 has been used. The usage count may correspond to the number of times the distribution area has been passed through. The usage count can also be rephrased as the number of times the area has been passed through, or the number of times the service has been received.

[0104] The RSU data may include data showing observed reception strength values ​​corresponding to the distance from RSU1. For example, the recording processing unit G2 may record reception strength at points where the remaining distance to RSU1 is 25m, 15m, and 5m. The usage history data may also include information on the furthest reception location. The furthest reception location information is the coordinates of the location where a message from RSU1 was received at the furthest distance.

[0105] The usage history data described above corresponds to data mapping RSU1s that the in-vehicle unit 2 has used. The recording processing unit G2 updates the usage history data upon receiving an RSU message. For example, if it receives an RSU message from an RSU1 that has not been used before, it adds the information of that RSU1 to the usage history data. If the size of the usage history data exceeds a predetermined value, the recording processing unit G2 prioritizes retaining data for RSU1s that have been used frequently. In other words, if the storage capacity becomes full, the recording processing unit G2 prioritizes deleting data for RSU1s that have been used infrequently.

[0106] The RSU diagnostic unit G3 determines whether the RSU1 located in front of the vehicle is functioning correctly. The RSU1 located in front of the vehicle refers to the RSU1 located in front of the vehicle, in other words, the RSU1 installed in the section of road that the vehicle will pass through within a predetermined time. Hereafter, the RSU1 that the RSU diagnostic unit G3 diagnoses will also be referred to as the target RSU. The target RSU can also be called the forward RSU (forward roadside unit) or the communication partner. For example, the RSU1 installed at the intersection in front of the vehicle corresponds to the target RSU. The forward RSU / target RSU can also be understood as the RSU1 located in a position where it can communicate with the vehicle in a narrow range, or the RSU1 located within a predetermined distance from the vehicle.

[0107] The RSU diagnostic unit G3 may recognize the presence of the target RSU by receiving an RSU message. Alternatively, the RSU diagnostic unit G3 may detect the target RSU based on map data indicating the installation location of the RSU1. The RSU diagnostic unit G3 may also detect the target RSU based on usage history data. A configuration that detects the forward RSU as a target for diagnosis based on map data / reception of V2I messages / usage history data corresponds to the RSU detection unit G31 (roadside unit detection unit). The RSU diagnostic unit G3 also corresponds to the malfunction detection unit.

[0108] The RSU diagnostic unit G3 can diagnose the target RSU in various ways. The RSU diagnostic unit G3 may diagnose the target RSU based on data contained in a message received from the target RSU. For example, the RSU diagnostic unit G3 may determine that there is a malfunction in the target RSU based on the fact that the difference between the time information contained in the message received from the target RSU and the time held by the unit is greater than or equal to a predetermined value. This diagnosis based on the difference in time information corresponds to the time-based diagnostic process described above. The RSU diagnostic unit G3 may also determine that there is a malfunction in the target RSU based on the fact that the difference between the installation location information contained in the message received from the target RSU and the location of the target RSU recognized by the unit is greater than or equal to a predetermined value. Furthermore, the RSU diagnostic unit G3 may determine that there is a malfunction in the target RSU if the security information in the received RSU message is inappropriate. Inappropriate security information includes cases where an electronic certificate has not been assigned or where the electronic certificate has expired.

[0109] Furthermore, the RSU diagnostic unit G3 may determine whether the target RSU is functioning correctly by comparing past reception status with the current reception status for RSU1, which has a usage history. For example, the RSU diagnostic unit G3 estimates the communication area of ​​the target RSU based on a set of locations where messages from the target RSU have been received in the past. Then, if the vehicle is within that communication area but cannot receive messages from the target RSU, it may determine that there is a problem with the target RSU.

[0110] Furthermore, for RSU1 with a usage history, the RSU diagnostic unit G3 determines whether the vehicle is within the target RSU's distribution area based on the distribution area information obtained during past use. If the vehicle is within the target RSU's distribution area but cannot receive messages from the target RSU, it may determine that there is a problem with the target RSU. These are equivalent to reception status-based diagnostic processing (determination processing), which diagnoses the target RSU based on the message reception status from the target RSU.

[0111] Incidentally, if a large vehicle such as a truck is present in front of the vehicle, it may be difficult to receive messages from the target RSU. Therefore, if the RSU diagnostic unit G3 detects the presence of a large vehicle within a predetermined distance in front of the vehicle using a front camera or the like, it may cancel the execution of the reception status-based diagnostic process. In other words, it is preferable that the reception status-based diagnostic process be performed on the condition that there is no large vehicle within a predetermined distance in front of the vehicle. With this configuration, the risk of mistakenly determining that a normally functioning RSU1 is malfunctioning can be reduced. Furthermore, if the RSU diagnostic unit G3 detects the presence of a large vehicle within a predetermined distance in front of the vehicle using a front camera or the like, it may invalidate the reception status-based diagnostic result. Invalidating the diagnostic result may be achieved by discarding the diagnostic result or by not reporting it to the management server 3. Note that a large vehicle can be a vehicle with a height of a predetermined value (e.g., 3m) or more. Whether or not a vehicle is a large vehicle may be defined by the vehicle classification stipulated by law.

[0112] In addition, the RSU diagnostic unit G3 may determine whether the target RSU is functioning normally by comparing the detection results of the vehicle's surrounding monitoring sensors 42 with the location information of moving objects notified by the target RSU. The RSU diagnostic unit G3 may also determine that there is a malfunction in the target RSU based on the detection of moving objects by the vehicle's surrounding monitoring sensors 42 that have not been notified by the target RSU. Furthermore, the RSU diagnostic unit G3 may determine whether the target RSU is functioning normally by comparing the location information of moving objects obtained from other vehicles via vehicle-to-vehicle communication with the location information of moving objects obtained from the target RSU.

[0113] The RSU diagnostic unit G3 may determine that a malfunction has occurred in the target RSU based on receiving a malfunction notification message from the target RSU. This configuration is also equivalent to a configuration that detects a malfunction in the forward RSU based on data received from the forward RSU. The RSU diagnostic unit G3 may also detect that a malfunction has occurred in the forward RSU based on receiving a signal from another in-vehicle device 2 or management server 3 indicating that a malfunction has occurred in the forward RSU.

[0114] The RSU diagnostic unit G3 may confirm that the target RSU is malfunctioning if it receives a notification from the target RSU itself that a malfunction is occurring, and if the RSU diagnostic unit G3 itself also determines that a malfunction has occurred in the target RSU. In other words, the in-vehicle unit 2 may determine the status of the target RSU by combining the self-report from RSU1 and the diagnostic result of the RSU diagnostic unit G3. With this configuration, the accuracy of determining the status of RSU1 can be improved. The in-vehicle unit 2 can employ one or more of the above-described methods for RSU diagnosis.

[0115] The communication processing unit G4 controls data communication with the management server 3, RSU1, and other in-vehicle devices 2. For example, based on the detection of a malfunction in RSU1 by the RSU diagnostic unit G3, the communication processing unit G4 sends a malfunction detection report to the management server 3 as a notification process. The malfunction detection report is a communication packet indicating that the target RSU may not be functioning properly. The communication processing unit G4 corresponds to the notification processing unit.

[0116] As shown in Figure 13, a malfunction detection report includes source information, the identification number (RSU-ID) of the RSU1 being reported, and the time of malfunction detection. The malfunction detection report may also include the installation location, RSU type, status code, message set ID, message version, and some or all of the environment code of the RSU1 being reported. Each piece of data may be written in the header, or some or all of the data may be stored in the payload. Source information can be represented, for example, by vehicle ID / MAC address / IP address of onboard unit 2. The environment code is information indicating the surrounding environment when the status of RSU1 was determined, and refers to the presence or absence of a preceding vehicle, the type of preceding vehicle (whether it is a large vehicle or not), weather, etc.

[0117] Figure 13 shows D21 to D26, which represent data fields in a message / communication packet used as a fault detection report, where various types of data are placed. For example, data field D22 is the target number field, which is the area where a bit sequence indicating the ID of the RSU1 being reported is placed. Data field D23 is the detection time field, which is the area where a bit sequence indicating the fault detection time (in other words, the judgment time) is placed. Data field D26 is the status field, which is the area where the status code is placed.

[0118] The transmission of the malfunction detection report to the management server 3 may be performed via cellular communication. Alternatively, the malfunction detection report may be transmitted to the management server 3 via the connected RSU1B. The connected RSU1B can be responsible for forwarding the malfunction detection report received from the in-vehicle unit 2 to the management server 3.

[0119] Furthermore, if the communication processing unit G4 detects a malfunction in the target RSU, it may send a malfunction detection message, which is a V2X message containing the same information as the malfunction detection report, to other units or other RSU1s via narrow-range communication. The communication processing unit G4 may also add information about the RSU1 that detected the malfunction to the header / payload of the vehicle status message that is sent periodically and send it. The communication processing unit G4 may also make the vehicle status message function as a malfunction detection message. If the in-vehicle unit 2 notifies surrounding vehicles of the malfunction of RSU1 via vehicle-to-vehicle communication, confusion among surrounding vehicles can be reduced, and safety can be further enhanced. Note that notification of a malfunction in the forward RSU to other in-vehicle units 2 in the vicinity of the unit may be carried out via the management server 3. That is, if the in-vehicle unit 2 detects a malfunction in the forward RSU, it may report it to the management server 3, and the management server 3 may distribute information about the RSU1 that has reported the malfunction to each in-vehicle unit 2.

[0120] With this configuration, the in-vehicle unit 2 can determine whether the RSU 1 is functioning normally based on a notification from the preceding vehicle, even before entering the communication range of the RSU ahead. Furthermore, if the in-vehicle unit 2 receives a notification from the preceding vehicle indicating a malfunction in the RSU ahead, it can implement a response (e.g., notification to the driver) appropriate for a malfunction in the RSU ahead before entering the communication range of the RSU ahead. Moreover, with a configuration in which the diagnostic results of the RSU diagnostic unit G3 are shared among the in-vehicle units 2 via vehicle-to-vehicle communication, the RSU diagnostic unit G3 can determine with higher accuracy whether a malfunction has occurred in the target RSU by integrating the diagnostic results from multiple in-vehicle units 2. For example, the RSU diagnostic unit G3 may determine whether the target RSU is functioning normally by majority vote. The communication processing unit G4 may send a dataset indicating this to other units or the management server 3 not only when it has determined that a malfunction has occurred in the target RSU, but also when it has determined that the target RSU is functioning normally. The message indicating the determination result of the RSU diagnostic unit G3 can also be called a diagnostic result report. If the communication processing unit G4 receives a malfunction notification message from RSU1 via narrow-area communication, it may send a message to the management server 3 via cellular communication indicating that a malfunction has occurred in RSU1, the source of the message.

[0121] The communication processing unit G4 may change whether or not to report to the management server 3 depending on the type of RSU1 in which a malfunction has been detected. For example, if the RSU1 in which a malfunction has been detected is a connected type, reporting to the management server 3 may be omitted. This is because a connected type RSU1B can report the occurrence of a malfunction to the management server 3 itself. If the communication processing unit G4 detects that a malfunction has occurred in a forward RSU (S51 YES), as shown in Figure 14, for example, it determines the type of the RSU1 (S52). Then, only if a malfunction in an independent type RSU1 is detected (S52 YES), it may report to the management server 3 (S53).

[0122] The type of RSU1 to be reported can be determined based on map data, data received from the target RSU, or usage history data. In this disclosure, the configuration of the control module 22 that determines the type of RSU1 is also referred to as the type determination unit.

[0123] The notification control unit G5 notifies the driver based on its detection of a malfunction in the forward RSU (target RSU). Hereafter, the RSU in which a malfunction has been detected will also be referred to as the error RSU. For example, if the error RSU is an RSU1 that has been used in the past, the notification control unit G5 displays a predetermined malfunction notification image. An RSU1 that has been used in the past is an RSU1 from which a support message was received during a past trip. A trip here refers to a series of drives from when the driving power is turned on until when it is turned off. The number of times the error RSU has been used is determined by referring to the usage history data stored in the storage 113. An RSU1 that is not registered in the usage history data, in other words, an RSU1 with a usage count of 0, corresponds to an RSU1 that the vehicle has never used in the past.

[0124] Furthermore, if the error RSU is an RSU1 that has never been used before, the notification control unit G5 does not need to notify the driver that there is a problem with that RSU1. In addition, if the error RSU is an RSU1 that has been used more than a predetermined number of times in the past, the notification control unit G5 may notify the driver of the problem with that RSU1 in a stronger manner than when the number of uses is less than a predetermined number. The notification control unit G5 may change the notification manner regarding the problem with the RSU1 depending on the number of past uses. Elements that constitute the manner of notification using images include the display position, display size, whether or not it flashes, and color. Elements that constitute the manner of notification using sound include the volume, the interval between output of the warning sound, and the frequency (pitch).

[0125] When a defect is detected in the RSU1 with a high usage frequency, the notification control unit G5 preferably notifies in a more prominent (stronger) manner than when a defect is detected in the RSU1 with a low usage frequency. According to this configuration, when the RSU1 along the road that the driver normally travels is not functioning properly, it becomes easier for the driver to recognize this. As a result, it becomes easier for the driver to take actions such as driving more carefully / checking the surroundings than usual. In other words, the risk that the driver will overly rely on an RSU1 that is not functioning properly can be reduced. Conversely, when a defect is detected in the RSU1 with a low usage frequency / without a usage history, the notification control unit G5 may weaken the notification intensity or omit the notification compared to when a defect is detected in the RSU1 that is used daily. According to this configuration, the risk of bothering the driver can be reduced.

[0126] <Supplement to the operation of the RSU diagnosis unit> Here, the operation example of the in-vehicle unit 2 as the RSU diagnosis unit G3 will be described using several flowcharts. For example, the in-vehicle unit 2 performs the GNSS system diagnosis process shown in FIG. 15 as a process for determining whether the GNSS receiver 13 of the target RSU is functioning properly. The GNSS system diagnosis process may include steps S61 to S66. Note that the in-vehicle unit 2 may set the transmission source of the message as the target RSU based on receiving the RSU message and perform the processes after step S62.

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

[0128] Step S63 is the step of acquiring (reading) the vehicle's own GNSS system information. Step S64 is the step of comparing the GNSS system information of RSU1 acquired in step S62 with the vehicle's own GNSS system information acquired in step S63. The type of information to be compared may be time information or position coordinates. For example, if the difference between the vehicle's time information and the target RSU's time information is greater than or equal to a predetermined value (S65 YES), the RSU diagnostic unit G3 determines that there is a malfunction in the target RSU's GNSS receiver 13 (S66).

[0129] Furthermore, for example, the in-vehicle unit 2 performs the wireless function diagnostic process shown in Figure 16 to determine whether the wireless unit 12 of the target RSU is functioning correctly. The wireless function diagnostic process may include steps S71 to S75. The in-vehicle unit 2 performs the wireless function diagnostic process at a predetermined interval, for example.

[0130] Step S71 is a step in which the RSU detection unit G31 searches for the RSU ahead. For example, the RSU detection unit G31 searches for the RSU ahead based on map data indicating the installation location of the RSU1 or usage history data. Alternatively, step S71 may be a process of sending a message to the RSU1 requesting the return of a response signal. The in-vehicle unit 2 / RSU diagnostic unit G3, acting as the RSU detection unit G31, may also perform an active scan as step S71.

[0131] Step S72 is a step to determine whether a message from RSU1 has been received within a predetermined time (e.g., 400 milliseconds) from the present. If a message from RSU1 has been received within the predetermined time (S72 YES), the radio function of the forward RSU itself is considered to be working normally, and this flow is terminated.

[0132] Meanwhile, if the RSU diagnostic unit G3 has not received a message from RSU1 within a predetermined time (S72 NO), it obtains the current location (S73). The RSU diagnostic unit G3 then refers to the usage history data and determines whether the current location is within the distribution area of ​​an RSU1 that has been used in the past (S74). If the current location is within the distribution area but has not received an RSU message (S74 YES), the RSU diagnostic unit G3 determines that there is a problem with RSU1 that forms the above distribution area (S75).

[0133] Step S74 may also be a step to determine whether or not an RSU message has been received at the current location in the past. The RSU diagnostic unit G3 may determine that there is a malfunction in the RSU1 corresponding to the current location based on the fact that it has not received an RSU message at a location where an 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. Information on the distribution area, information on the reception strength according to the distance, or the furthest reception location information stored in the storage 113 as usage history data corresponds to data indicating the range in which a signal from the forward RSU can be received. The above configuration may correspond to a configuration in which it is determined that there is a malfunction in the forward RSU based on the fact that it cannot receive a signal from the forward RSU even though the machine is in a position where it can receive a signal from the forward RSU.

[0134] Furthermore, even if the RSU diagnostic unit G3 has received an RSU message, it may determine that there is a problem with the source of the received message based on the fact that the currently observed reception strength is lower than or equal to a predetermined value compared to the reception strength previously observed at the same location. The RSU diagnostic unit G3 may also diagnose RSU1 based on a comparison of the current and past observed reception strength values ​​at the same location.

[0135] <Effects of the above configuration> In the above configuration, if the in-vehicle unit 2 detects a malfunction in the forward RSU, it notifies other units in its vicinity of the malfunction in the forward RSU. With this configuration, these other units can recognize that the RSU is malfunctioning even before reaching the communication range of the forward RSU. Specifically, the in-vehicle unit 2 of a following vehicle that has been notified of a malfunction in the forward RSU by the preceding vehicle can implement temporary control even before reaching the communication range of the forward RSU. Temporary control is implemented when a malfunction occurs in the forward roadside unit. Temporary control may include notifying the driver of a malfunction in the forward roadside unit, changing the planned route, reducing vehicle speed, and activating surrounding monitoring sensors. Activating surrounding monitoring sensors may include activating sensors that were previously stopped, as well as shortening the execution interval of object detection processing.

[0136] Furthermore, in one of the above configurations, the in-vehicle unit 2 reports to the management server 3 that it has received a message from RSU1 indicating that a malfunction has occurred. With this configuration, even if a malfunction occurs in the standalone RSU1A, the management server 3 will be able to recognize it more easily. Accordingly, the management server 3 will be able to notify the in-vehicle unit 2 of the information about the malfunctioning RSU1, and the in-vehicle unit 2 will be able to recognize that a malfunction has occurred in the forward RSU based on the notification from the management server 3, even before approaching the forward RSU.

[0137] Furthermore, in one embodiment, the in-vehicle unit 2 may send a malfunction detection report to the management server 3 if it detects a malfunction in the standalone RSU1A, while omitting sending the malfunction detection report to the management server 3 if the RSU1 that detected the malfunction is a connected RSU1B. This configuration makes it possible to reduce the frequency of communication between the in-vehicle unit 2 and the management server 3.

[0138] Furthermore, in one embodiment, the in-vehicle unit 2 may send a message to the management server 3 indicating that RSU1 is functioning normally, even when RSU1 is functioning normally as a communication partner. With this configuration, the management server 3 can more easily recognize that RSU1 is functioning normally or that RSU1, which had been reported to be malfunctioning, has returned to a normal state. Consequently, the system management costs for the service provider can be reduced.

[0139] While embodiments of the present disclosure have been described above, the present disclosure is not limited to the embodiments described above. Various modifications described below are also included within the technical scope of the present disclosure, and further modifications can be made in various ways without departing from the gist of the invention. For example, the various supplements and modifications described below can be combined as appropriate without causing any technical inconsistencies. In addition, components having the same function as those described above may be denoted by the same reference numerals, and their descriptions may be omitted. Also, if only a part of the configuration is referred to, the above description may be applied to the other parts.

[0140] <Example (1)> The above describes an embodiment in which both RSU1 and the in-vehicle unit 2 have functions to diagnose RSU1, but it is not limited to this. The in-vehicle unit 2 does not need to have an RSU diagnostic unit G3. Also, RSU1 does not need to have a self-diagnosis unit F2. As long as either the in-vehicle unit 2 or RSU1 has a function to diagnose RSU1, the in-vehicle unit 2 can be realized to transmit information about the malfunctioning independent RSU1A to the management server 3.

[0141] For example, if the in-vehicle unit 2 does not have an RSU diagnostic unit G3, the standalone RSU 1A and the in-vehicle unit 2 may operate as follows. First, if the standalone RSU 1A detects a malfunction in its self-diagnostic unit F2, it notifies the in-vehicle unit 2 of the malfunction via narrow-range communication. Based on receiving the malfunction notification from the standalone RSU 1A, the in-vehicle unit 2 sends a malfunction detection report to the management server 3 via cellular communication. Note that the in-vehicle unit 2 does not necessarily need to use cellular communication; it may also indirectly notify the management server 3 of the standalone RSU 1A's malfunction by sending a malfunction detection message to the connected RSU 1B.

[0142] Furthermore, if RSU1 does not have a self-diagnostic unit F2, any malfunction in the standalone RSU1A will be detected by the RSU diagnostic unit G3 of the in-vehicle unit 2 and reported to the management server 3. In other words, RSU1 does not need to have a self-diagnostic unit F2.

[0143] <Example (2)> The management server 3 may determine that a malfunction has occurred in a single standalone RSU1A based on the fact that it has received malfunction detection reports from multiple in-vehicle devices 2 within a certain period of time. The above process may be performed not only on standalone RSU1A but also on connected RSU1B. By using a configuration that determines the status of RSU1 based on reports from multiple in-vehicle devices 2, the risk of misjudging the status of RSU1 can be reduced.

[0144] <Variation (3)> When a malfunction occurs, RSU1 may send a malfunction notification message indicating various information / that the reliability of RSU1 itself has decreased. The reliability can be expressed as a value between 0 and 100, with 100 representing the case where no malfunction has been detected. If the basic format of the RSU message includes a field for describing the reliability, RSU1 may set the value of that field to a predetermined value (e.g., 50) or less when a malfunction is detected and send the message.

[0145] <Example (4)> The above example illustrates a case where the support data is data indicating traffic conditions near an intersection, but the content of the support data is not limited to this. In other forms, the support data may be signal-related data indicating the lighting status of a traffic light. Signal-related data may include lighting cycle information such as the current lighting status, the remaining time the current lighting status will be maintained, and the next lighting status, in addition to the current lighting status. The message / communication packet / communication frame indicating such support data may correspond to an SPaT (Signal Phase and Timing) message. RSU1 may be installed integrally with the traffic light.

[0146] Furthermore, the support data may also be control data to assist the automated driving of a vehicle within an intersection. The support data may also include camera video data or map data showing the shape of the intersection, etc.

[0147] <Variation (5)> The above explanation of the operation of each part assumes that RSU1 is installed at an intersection, but RSU1 can be installed in places other than intersections. RSU1 may also be placed at merging / diverging points on highways. Such RSU1 can deliver a dataset as support data showing traffic conditions near the merging / diverging point, such as the position and speed of vehicles within the monitoring area. RSU1 may also be placed near the exit of a tunnel, in which case RSU1 can deliver a dataset as support data showing wind speed, rainfall, road surface conditions, and the presence or absence of congestion near the tunnel exit. RSU1 installed on a road section with poor visibility can deliver a dataset notifying of moving objects and road shape within the monitoring area. The content of the support data may differ for each RSU1. Note that road sections with poor visibility refer to intersections with walls, trees, or buildings at corners, points where the gradient changes from an uphill to a downhill slope, and sharp curves where the curvature exceeds a predetermined value. The monitoring area can be set to cover areas that are likely to be blind spots for vehicle drivers / cameras.

[0148] <Differentiation (6)> RSU1 does not necessarily need to be equipped with area monitoring sensors such as camera 15. RSU1 for traffic signal-related data distribution only needs to be connected to a lighting control unit that controls the lighting status of the traffic signals, and area monitoring sensors can be an optional element. The hardware / functions of RSU1 may be changed as appropriate depending on the service of RSU1.

[0149] <Example (7)> Vehicle-to-infrastructure communication can be implemented using technologies such as Bluetooth®, Wi-Fi®, ZigBee®, UWB-IR (Ultra Wide Band - Impulse Radio), EnOcean®, and Wi-SUN®. Bluetooth standards include BLE (Bluetooth Low Energy) and Bluetooth Classic. Similarly, various Wi-Fi standards can be adopted, such as IEEE 802.11n, IEEE 802.11ac, and IEEE 802.11ax (so-called Wi-Fi 6).

[0150] <Additional remark (1)> The above-described in-vehicle device 2 can be used in a variety of vehicles that travel on roads. The in-vehicle device 2 of this disclosure can be mounted on a variety of vehicles that can travel on roads, including four-wheeled vehicles, two-wheeled vehicles, three-wheeled vehicles, etc. Motorized bicycles can also be included in the category of two-wheeled vehicles. The in-vehicle device 2 may be used in robot taxis, unmanned buses, vehicles as unmanned delivery robots, and patrol cars that automatically travel predetermined routes for road equipment inspection / security. The in-vehicle device 2 may be configured to be detachable by the user. The in-vehicle device 2 may also be a smartphone, tablet, laptop, etc. equipped with the above-described narrow-range communication function, brought into the vehicle by the user.

[0151] <Additional remarks (2)> This disclosure also includes the following technical concepts. Furthermore, these technical concepts are applicable to roadside units and vehicle-to-infrastructure communication systems.

[0152] [Technical thought 1] An in-vehicle device configured to enable vehicle-to-infrastructure communication, A roadside unit detection unit (G31) detects a roadside unit located in front of the vehicle, A malfunction detection unit (G3) detects a malfunction in the forward roadside unit based on the data received from the forward roadside unit or the reception status of signals from the forward roadside unit, An in-vehicle unit comprising: a notification processing unit (G4) that performs a notification process, which is a process for notifying other in-vehicle units of the malfunction of the forward roadside unit, based on the malfunction detection unit detecting a malfunction of the forward roadside unit.

[0153] [Technical thought 2] The in-vehicle device described in Technical Concept 1, The notification processing unit determines, based on map data describing the installation location and type of the roadside unit, or data received from the roadside unit ahead, whether the roadside unit ahead is a standalone roadside unit that cannot communicate with the management device. An in-vehicle device that performs the notification process based on the fact that the forward roadside unit from which the malfunction detection unit has detected a malfunction is the standalone type roadside unit.

[0154] [Technical thought 3] The in-vehicle device described in Technical Concept 2, The notification processing unit is an in-vehicle unit that, based on the fact that the forward roadside unit from which the malfunction detection unit has detected a malfunction is a network-connected roadside unit capable of communicating with the management device, omits the execution of the notification processing.

[0155] [Technical thought 4] An in-vehicle device as described in Technical Concept 2 or 3, An in-vehicle device is configured to send to the management device a dataset comprising, as part of the notification process, a target number field in which the identification number of the standalone roadside unit in which a malfunction has been detected is stored, a detection time field in which the detection time is stored, and a status field in which a status code indicating the nature of the malfunction is stored.

[0156] [Technical thought 5] An in-vehicle device described in any one of Technical Ideas 2 to 4, The notification processing unit is configured to transmit information about the standalone roadside unit in which a malfunction has been detected to the network-connected roadside unit when it establishes a communication connection with the management device as part of the notification processing.

[0157] [Technical Thought 6] An in-vehicle device described in any one of Technical Ideas 1 to 5, The malfunction detection unit is an in-vehicle device that determines that a malfunction has occurred in the forward roadside device based on the fact that the difference between the time information contained in the message received from the forward roadside device and the time information held by the device itself is greater than or equal to a predetermined value.

[0158] [Technical Thought 7] An in-vehicle device described in any one of the technical concepts 1 to 6, The system includes a storage unit (113) which stores data indicating the range in which signals from the roadside unit ahead can be received, The malfunction detection unit is an in-vehicle device that determines that a malfunction has occurred in the forward roadside unit, based on the fact that it is unable to receive a signal from the forward roadside unit, even though it is in a position where it can receive a signal from the forward roadside unit.

[0159] [Technical Thought 8] The in-vehicle device described in Technical Concept 7, An in-vehicle device is configured to either cancel the determination process based on the signal reception status from the roadside unit ahead, or invalidate the result of the determination process based on the signal reception status from the roadside unit ahead, if the presence of a large vehicle in front of the vehicle is detected.

[0160] [Technical Thought 9] An in-vehicle device configured to enable vehicle-to-infrastructure communication, A roadside unit detection unit (G31) detects a roadside unit located in front of the vehicle, A malfunction detection unit (G3) detects a malfunction in the forward roadside unit based on the data received from the forward roadside unit or the reception status of signals from the forward roadside unit, An in-vehicle unit comprising: a notification processing unit (G4) that performs a notification process, which is a process for notifying a predetermined management device of a malfunction of the roadside unit ahead, based on the malfunction detection unit detecting a malfunction of the roadside unit ahead. With this configuration, the management device can more easily recognize malfunctions of standalone roadside units as well.

[0161] <Additional remarks (3)> The various flowcharts shown in this disclosure are all examples, and the number of steps constituting the flowchart and the execution order of the processes can be changed as appropriate. Furthermore, the devices, systems, and methods described in this disclosure may be implemented by a dedicated computer comprising a processor programmed to execute one or more functions embodied by a computer program. The devices and methods described in this disclosure may be implemented using dedicated hardware logic circuits. The devices and methods described in this disclosure may be implemented by one or more dedicated computers comprising a combination of a processor that executes a computer program and one or more hardware logic circuits. As the processor (processing core), a CPU, MPU, GPU, DFP (Data Flow Processor), etc., can be used. Some or all of the functions of this disclosure may be implemented using a system-on-a-chip (SoC), integrated circuit (IC), or field-programmable gate array (FPGA). The concept of IC also includes application-specific integrated circuit (ASIC). Furthermore, the computer program only needs to be stored on a computer-readable non-transitory tangible storage medium as instructions executed by the computer. HDDs (Hard-disk drives), SSDs (Solid State Drives), flash memory, etc., can be used as the program's storage medium. The scope of this disclosure also includes the form of the program for causing the computer to function as an RSU control unit 11 / control module 22 / management server 3, and the non-transitory tangible storage medium such as semiconductor memory on which this program is stored. [Explanation of symbols]

[0162] 1 RSU (Roadside Unit), 1A Standalone RSU, 1B Network-Connected RSU, 2 In-vehicle Unit, 3 Management Server (Management Device), 11 RSU Control Unit, F1 Support Information Distribution Unit, F2 Self-Diagnosis Unit, F3 Status Notification Unit, 22 Control Module, 223 Storage Unit, G1 Support Processing Unit, G2 Recording Processing Unit, G3 RSU Diagnosis Unit (Malfunction Detection Unit), G31 RSU Detection Unit (Roadside Unit Detection Unit), G4 Communication Processing Unit (Notification Processing Unit), G5 Notification Control Unit

Claims

1. An in-vehicle device configured to enable vehicle-to-infrastructure communication, A roadside unit detection unit (G31) detects a roadside unit located in front of the vehicle, A malfunction detection unit (G3) detects a malfunction in the forward roadside unit based on the data received from the forward roadside unit or the reception status of signals from the forward roadside unit, The system includes a notification processing unit (G4) that performs a notification process to notify other in-vehicle units in the vicinity of the vehicle of the malfunction of the forward roadside unit, based on the malfunction detection unit detecting a malfunction of the forward roadside unit. The notification processing unit determines, based on map data describing the installation location and type of the roadside unit, or data received from the roadside unit ahead, whether the roadside unit ahead is a standalone roadside unit that cannot communicate with the management device. An in-vehicle device that performs the notification process based on the fact that the forward roadside unit from which the malfunction detection unit has detected a malfunction is the standalone type roadside unit.

2. The in-vehicle device according to claim 1, The notification processing unit does not perform the notification process if the forward roadside unit from which the malfunction detection unit has detected a malfunction is a network-connected roadside unit capable of communicating with the management device.

3. An in-vehicle device according to claim 1 or 2, An in-vehicle device is configured to send to the management device a dataset comprising, as part of the notification process, a target number field in which the identification number of the standalone roadside unit in which a malfunction has been detected is stored, a detection time field in which the detection time is stored, and a status field in which a status code indicating the nature of the malfunction is stored.

4. An in-vehicle device according to claim 1 or 2, The notification processing unit is configured to transmit information about the standalone roadside unit in which a malfunction has been detected to the network-connected roadside unit when it establishes a communication connection with the management device as part of the notification processing.

5. The in-vehicle device according to claim 1, The malfunction detection unit is an in-vehicle device that determines that a malfunction has occurred in the forward roadside device based on the fact that the difference between the time information contained in the message received from the forward roadside device and the time information held by the device itself is greater than or equal to a predetermined value.

6. The in-vehicle device according to claim 1, It includes a storage unit (113) which stores data indicating the range in which signals from the roadside unit ahead can be received, The malfunction detection unit is an in-vehicle device that determines that a malfunction has occurred in the forward roadside unit, based on the fact that it is unable to receive a signal from the forward roadside unit, even though it is in a position where it can receive a signal from the forward roadside unit.

7. The in-vehicle device according to claim 6, An in-vehicle device is configured to either cancel the determination process based on the signal reception status from the roadside unit ahead, or invalidate the result of the determination process based on the signal reception status from the roadside unit ahead, if the presence of a large vehicle in front of the vehicle is detected.

8. An in-vehicle device configured to enable vehicle-to-infrastructure communication, A roadside unit detection unit (G31) detects a roadside unit located in front of the vehicle, A malfunction detection unit (G3) detects a malfunction in the forward roadside unit based on the data received from the forward roadside unit or the reception status of signals from the forward roadside unit, The system includes a notification processing unit (G4) that performs a notification process to notify other in-vehicle units in the vicinity of the vehicle of the malfunction of the forward roadside unit, based on the malfunction detection unit detecting a malfunction of the forward roadside unit. It includes a storage unit (113) which stores data indicating the range in which signals from the roadside unit ahead can be received, The malfunction detection unit determines that a malfunction has occurred in the forward roadside unit based on the fact that it is unable to receive a signal from the forward roadside unit, even though it is in a position where it can receive a signal from the forward roadside unit. An in-vehicle device is configured to either cancel the determination process based on the signal reception status from the roadside unit ahead, or invalidate the result of the determination process based on the signal reception status from the roadside unit ahead, if the presence of a large vehicle in front of the vehicle is detected.

Images