JP2024017805A - On-vehicle device and notification control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an on-vehicle device and a notification control method that can reduce a possibility of causing trouble to a driver when notifying of an operating status of a roadside unit.

SOLUTION: Every time an on-vehicle device receives assistance data distributed from an RSU, the on-vehicle device records a transmission source of reception data as the RSU that has been used by an own vehicle. Also, the on-vehicle device determines whether or not the RSU exiting in front of the own vehicle is functioning normally based on data received from the RSU or the like. When detecting that a problem occurs in the RSU existing in front of the own vehicle, the on-vehicle device changes a way to notify a driver of the occurrence of the problem in the RSU in a conspicuous manner, in a subtle manner, or by omitting the notification, based on a utilization history of the RSU.

SELECTED DRAWING: Figure 10

COPYRIGHT: (C)2024,JPO&INPIT

Description

The present disclosure relates to an in-vehicle device and a notification control method for implementing driving assistance based on information distributed from a roadside device.

Patent Document 1 discloses a system including a roadside device that distributes support information related to passing through an intersection to a vehicle/in-vehicle device. The roadside device here is communication equipment that is placed along the road and performs road-to-vehicle communication. The roadside unit may also be called an RSU (Roadside Unit). The roadside device may include a monitoring sensor for detecting a moving object in addition to wireless equipment for communicating with the on-vehicle device.

The support information related to passing through an intersection includes information related to the presence of an oncoming vehicle, information indicating the shape of the intersection, and the like. Based on entering the service area (communication area) of the roadside device, the on-vehicle device receives support information from the roadside device and performs driving support control such as providing information to the driver and automatic acceleration/deceleration/steering. I can do it. According to the configuration, safety and convenience for the driver can be improved.

Japanese Patent Application Publication No. 2002-269699

When a roadside device is installed at an intersection that drivers frequently pass, it may be common for the driver to receive support services from the roadside device. Furthermore, as a result, when passing through the intersection, the driver may perform driving operations that depend on the support service provided by the roadside device.

In the above assumed situation, if a problem occurs in the wireless system of the roadside device, the on-vehicle device will be unable to receive support information and will be unable to provide driving support based on the received information. From the driver's perspective, it may feel as if the support services that he or she always uses are suddenly no longer available. When a malfunction occurs in a certain roadside machine in this way, there is a possibility that the driver who uses the roadside machine on a daily basis is confused.

Under such circumstances, from one viewpoint, when it is detected that a problem has occurred in the roadside device in front of the vehicle, it is preferable that the in-vehicle device notifies the driver of this fact. On the other hand, even if a problem occurs in a roadside device, the effect is small from the perspective of a driver who does not normally use the roadside device. From a driver's perspective, it is expected that it would be bothersome to be notified of a malfunction in a road measuring device that is not normally used.

The present disclosure has been made based on the above considerations and points of view, and one of its purposes is to provide an in-vehicle device that can reduce the risk of causing trouble to the driver when notifying the operating status of the roadside device. , an object of the present invention is to provide a notification control method.

The in-vehicle device disclosed herein is an in-vehicle device configured to be able to receive support data, which is data for supporting the driving of a vehicle, distributed from each of a plurality of roadside devices installed along the road. The roadside device detection unit (G31) detects the forward roadside device, which is the roadside device existing in front of the own vehicle, and the content of the signal received from the forward roadside device, the reception status of the signal from the forward roadside device, or the forward roadside device. A roadside unit diagnosis unit (G3) that determines whether or not there is a problem with the roadside unit in front based on data received from an external device that is a device other than the roadside unit, and data about the roadside unit that has been used. a recording processing unit (G2) that performs a process of storing usage history data in a history storage unit (M1); and a notification control unit (G5) that controls notification to the driver regarding a malfunction of the roadside unit ahead. In preparation, the notification control unit changes the notification mode to the driver regarding the malfunction of the forward roadside machine, depending on whether or not the forward roadside machine in which the malfunction has occurred has been used in the past.

According to the above configuration, when it is detected that a problem has occurred in the forward roadside device, a notification regarding the problem in the forward roadside device is carried out in a manner according to the usage history of the forward roadside device. Therefore, it is possible to reduce the risk of bothering the driver when notifying the operating state of the roadside device.

Further, the notification control method of the present disclosure is a notification control method performed by at least one processor for notifying a driver of the operating state of a roadside device that distributes support data that is data for supporting driving of a vehicle. In this case, the processor detects a forward roadside device that is a roadside device that exists in front of the own vehicle that is the vehicle used (S21), and usage history data that is data about roadside devices that have been used. (S12), the content of the signal received from the roadside machine in front, the reception status of the signal from the roadside machine in front, or a device other than the roadside machine in front. Based on the data received from the external device, it is determined whether or not there is a problem in the roadside machine in front (S22), and whether or not the roadside machine in front with the problem has been used in the past is determined. Accordingly, the method includes changing the manner in which the driver is notified of the malfunction of the roadside machine ahead (S24 to S28, S34 to S39).

The above-mentioned notification control method is a method corresponding to the above-described on-vehicle device, and has the same effect as the above-described on-vehicle device.

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

1 is a diagram for explaining the overall image of a road-to-vehicle communication system. FIG. 2 is a block diagram showing an example of the configuration of an RSU. FIG. 3 is a functional block diagram of an RSU control unit. FIG. 1 is a block diagram showing the configuration of an in-vehicle system. FIG. 3 is a functional block diagram of a control module. It is a figure which shows an example of a warning image. FIG. 3 is a diagram for explaining the operation of a recording processing section G2. It is a figure which shows an example of the content of RSU data. FIG. 3 is a diagram for explaining the configuration of a defect detection message. It is a flowchart of notification control processing. It is a figure which shows an example of a modest notification image. It is a figure which shows an example of an emphasis notification image. 12 is a flowchart for explaining another example of notification control processing. FIG. 3 is a block diagram showing another example configuration of the in-vehicle system.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The status of the RSU 1 may be divided into categories such as "sonar malfunction" indicating a sonar malfunction, and "jamming radio wave detected" indicating that radio wave interference is occurring. Furthermore, if various types of cameras are assumed as cameras, such as color cameras, infrared cameras, and ToF cameras, "camera malfunctions" may be subdivided according to the types. The status of RSU1 may be evaluated in two stages: normal/failure. The status of RSU1 can be expressed by a predetermined number of bit strings/codes.

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

<About RSU configuration and functions>
Here, the configuration and functions of the RSU 1 will be explained. As shown in FIG. 2, the RSU 1 includes an RSU control section 11, a wireless section 12, a GNSS receiver 13, a millimeter wave radar 14, a camera 15, an image analysis section 16, and a WAN module 17.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The status message only needs to include at least the RSU-ID, transmission time, and status code in the header or payload. RSU-ID is an identification number (ID) of RSU1 as a transmission source. The transmission time indicates the transmission time of the message. The status code is a code representing the status of the sender. Note that the status message may include information such as the installation location, target area, and message size. The target area indicates the area to which the RSU 1 provides services, that is, the distribution area. The target area can be expressed, for example, by the position coordinates of the center of the area and the radius of the area. The target area may be expressed only by the distance (radius) from the RSU installation position.

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

Note that the RSU 1 in this embodiment not only simply indicates that a malfunction has occurred, but also transmits a message indicating the content of the malfunction, that is, the location where the malfunction has occurred, as a malfunction notification message. As another aspect, the malfunction notification message may be a message indicating that some kind of malfunction has occurred in the RSU 1. The malfunction notification message may be a message simply indicating that the service is being stopped. The status notification unit F3 can transmit self-diagnosis results and data regarding moving objects/obstacles in the monitoring area to the management server 3 periodically/in response to inquiries from the management server 3.

<About image-based diagnosis processing>
The image-based diagnosis process is a process that determines the operating state of the camera 15 by comparing the current camera image and camera images taken in the past. The image-based diagnosis process requires a reference image registration process as a preparatory process. The reference image registration process is a process for generating a reference image as a judgment material for verifying whether the camera 15 (for example, an image sensor) is functioning normally, and registering it in the storage 113.

The reference image is image data of a fixed object/stationary object obtained by removing moving objects such as cars and pedestrians from the captured image generated by the camera 15. The reference image can also be called a fixed image. The reference image may be generated by combining a plurality of camera images taken at different times. According to the configuration in which a comparison image is generated based on a plurality of images captured at different times (frames), a road surface image in an area in which a moving object was captured in a certain frame is also complemented by images in other frames. sell. Such reference image registration processing can be performed when the RSU 1 is installed, triggered by a specific operation by the installer, such as pressing a record button. Note that the reference image registration process may be performed periodically, such as every month.

The image-based diagnosis process includes the step of generating a comparison image based on the current image, which is the latest image generated by the camera 15. The comparison image is an image obtained by removing the moving object from the current image, in other words, an image obtained by extracting a region in which a fixed object/stationary object is shown from the current image. The comparison image may also be generated by combining a plurality of images taken within a predetermined period of time in the immediate vicinity. The self-diagnosis unit F2 compares the comparison image with the reference image registered in the storage 113, and if the difference between them is greater than a predetermined value, the self-diagnosis unit F2 determines that a malfunction has occurred in the camera 15/own unit. It is determined that the

The time-based diagnostic process is a process that determines whether the GNSS receiver 13 is operating normally by comparing the time information received from the on-vehicle device 2 and the time information held by the own unit. . Time-based diagnostic processing may be performed at regular time intervals. Note that if a problem occurs in the GNSS receiver 13, the error between the internal time, which is the time information held by the RSU control unit 11, and the actual time may exceed a predetermined value. The internal time of RSU1 can also be called RSU time.

The time-based diagnosis process may include a step of calculating an average time, which is the average value, using vehicle time information included in messages from the in-vehicle device 2 received within a nearby predetermined time (for example, 200 milliseconds) as a population. . The vehicle time information is time information included in the message received from the vehicle-mounted device 2. The average time corresponds to the average value of times held by a plurality of on-vehicle devices 2 existing within the communication area of the RSU 1. The self-diagnosis unit F2 determines that a problem has occurred in the GNSS receiver 13/own unit when the difference between the internal time and the average time is a predetermined value or more.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Notification of the assistance information to the driver can be realized by displaying an image on the display 45, outputting an audio message/warning sound from the speaker 46, lighting an indicator, applying vibration, and the like. The device that generates vibrations may be installed at a location that comes into contact with the driver's body, such as the seat, seatbelt, or steering wheel.

For example, the support processing unit G1 displays a warning image Im1 on the display 45 along with a warning sound when another moving object that may come into contact with the host vehicle is detected based on a message from the RSU1. FIG. 6 shows an example of the warning image Im1. 45a in the figure indicates a display screen/display area of the display.

Note that when the on-vehicle device 2 is able to receive the signal from the RSU 1, the notification control unit G5 displays the service-in image Im2 at a predetermined position on the display 45. The service-in image Im2 is an icon image indicating that data from the RSU1 can be received. The service-in image Im2 can be, for example, an image in which a radio wave icon, which is an element simulating a radio wave, is placed near an RSU icon, which is an element simulating RSU1.

Note that the driving support processing performed by the support processing unit G1 is not limited to notifying the driver, but may also perform control that intervenes in driving operations such as braking and steering. The driver in this disclosure refers to a person seated in a driver's seat, that is, a driver's seat occupant. The concept of a driver can include a person who remotely controls a vehicle.

As shown in FIG. 7, when the recording processing unit G2 receives the RSU message (S11), it stores data regarding the sending source RSU1 in the history storage unit M1 of the storage 223 (S12). In this disclosure, the list of RSUs 1 that have received messages is referred to as usage history data. The history storage unit M1 is a storage area for storing usage history data. The storage area as the history storage section M1 may be dynamically secured, or may be secured in advance with a predetermined size. The history storage unit M1 may be realized using a storage device independent from the storage 223.

The usage history data includes RSU data that is detailed data for each RSU1. For example, as shown in FIG. 8, each RSU data can include installation location, RSU-ID, number of uses, number of warnings, number of interventions, distribution area, and the like. The usage count may include a usage count that is the number of times the service provided by the RSU 1 has been used. The number of uses may correspond to the number of times the delivery area has been passed through. The number of times of use can also be expressed as the number of times of passing through an area or the number of times of receiving support messages. Utilizing RSU1 may correspond to receiving assistance messages distributed from RSU1.

The number of warnings refers to the number of times that warning processing based on the received support message has been performed. The warning process corresponds to, for example, a process of notifying the user of the presence of a moving object that may come into contact with the vehicle using the display 45, speaker 46, vibrator, or the like. Conditions for executing the warning process may be designed as appropriate.

The number of times of intervention refers to the number of times that the operation intervention process based on the received support message has been performed. The operation intervention process refers to automatic vehicle control by the system, for example, to avoid contact between the own vehicle and a moving object/to reduce damage from a collision. The operation intervention process is, for example, automatic braking. The operation intervention process may include steering control in a direction to avoid a collision. The operation intervention process can also be called collision damage reduction control/collision avoidance control. Conditions for implementing the operation intervention process may be designed as appropriate. For example, this can be carried out when there is a moving object whose time to collision (TTC) is less than or equal to a predetermined value.

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

Note that even if the recording processing unit G2 receives an RSU message from the same RSU 1 multiple times within a predetermined period of time (for example, 5 minutes), it is preferable that the increase value of the number of uses of the RSU 1 is set to 1. According to this control, even if a message from the same RSU 1 is received multiple times while waiting at a traffic light or the like, it is possible to reduce the possibility that the value of the number of times of use will increase by two or more.

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

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

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

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

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

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

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

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

The RSU diagnosis unit G3 may determine that a problem has occurred in the target RSU based on receiving the failure notification message from the target RSU. This configuration also corresponds to a configuration in which a malfunction in the front RSU is detected based on data received from the front RSU.

Furthermore, the RSU diagnosis unit G3 determines that a problem has occurred in the front RSU based on receiving data indicating that a problem has occurred in the front RSU from an external device such as another onboard device 2 or the management server 3. You may judge. If the RSU diagnostic unit G3 receives a notification that a malfunction is occurring from the target RSU itself, and the RSU diagnostic unit G3 itself also determines that a malfunction has occurred in the target RSU, the RSU diagnostic unit G3 determines that a malfunction has occurred in the target RSU. It is also possible to confirm the determination that the As the RSU diagnosis method using the on-vehicle device 2, one or more of the various methods described above can be adopted.

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

As shown in FIG. 9, the malfunction detection report includes transmission source information, the identification number (RSU-ID) of the RSU 1 to be reported, and the malfunction detection time. Further, the malfunction detection report may include part or all of the installation position of the RSU 1 to be reported, the status code, and the environment code. Each piece of data may be written in the header, or some or all of the data may be stored in the payload section. Note that the transmission source information can be expressed by, for example, the vehicle ID/MAC address of the on-vehicle device 2/IP address. The environment code is information indicating the surrounding environment when the status of the RSU 1 is determined, and refers to the presence or absence of a preceding vehicle, the classification of the preceding vehicle (whether it is a large vehicle or not), the weather, etc. D21 to D26 shown in FIG. 9 each represent data fields in which various data are placed in a message/communication packet as a defect detection report.

Transmission of the malfunction detection report to the management server 3 may be performed by cellular communication. Further, the malfunction detection report may be transmitted to the management server 3 via the RSU 1. Each RSU 1 may transfer the malfunction detection report received from the on-vehicle device 2 to the management server 3.

Further, the communication processing unit G4 may transmit a malfunction detection message, which is a V2X message containing the same content as the malfunction detection report, to another device via short-range communication. The communication processing unit G4 may add information about the RSU in which a malfunction has been detected to the header/payload of the vehicle status message that is periodically transmitted. That is, the communication processing unit G4 may function the own vehicle status message as a malfunction detection message.

According to the configuration in which the diagnosis results of the front RSU are shared through inter-vehicle communication, the on-vehicle unit 2 detects the possibility that the front RSU 1 is not functioning properly before entering the communication area of the target RSU based on the notification from the preceding vehicle. It may be possible to implement a considered response (eg, driver notification). Furthermore, according to the configuration in which the diagnosis results of the RSU diagnostic unit G3 are shared between the on-vehicle units 2 through vehicle-to-vehicle communication, the RSU diagnosis unit G3 can integrate the diagnosis results from multiple on-vehicle units 2 to detect a problem in the target RSU. It may be possible to determine with higher accuracy whether or not this has occurred. For example, the RSU diagnostic unit G3 may determine whether or not the target RSU is operating normally by majority vote. Not only when it is determined that the target RSU is malfunctioning, but also when it is determined that the target RSU is operating normally, the communication processing unit G4 transmits a data set indicating this to other machines and manages the target RSU. It may also be sent to server 3. The message indicating the determination result of the RSU diagnosis unit G3 can also be called a diagnosis result report.

The notification control unit G5 performs a malfunction notification process, which is a process of notifying the driver of the fact, based on the fact that the RSU diagnosis unit G3 has detected that a malfunction has occurred in the front RSU (target RSU). The front RSU malfunction notification may be performed using one or more of displaying an image on the display 45, outputting a warning sound, lighting an indicator, applying vibration, and applying a steering reaction force. Hereinafter, an RSU in which a defect has been detected will also be referred to as an error RSU.

For example, when the error RSU is RSU1 that has been used in the past, the notification control unit G5 displays a predetermined malfunction notification image as malfunction notification processing. The RSU 1 that has been used in the past is the RSU 1 that has received a support message from the RSU 1 in a past trip. A trip here refers to a series of trips from when the power source for traveling is turned on until it is turned off. The number of times an error RSU has been used is determined by referring to usage history data stored in the storage 113. An RSU1 that is not registered in the usage history data, in other words, an RSU1 that has been used 0 times, corresponds to an RSU1 that has not been used by the own vehicle in the past.

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

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

Note that the notification control unit G5 displays the service-in image Im2 at a predetermined position on the display 45 when the RSU message has been received and the source of the received message is functioning normally. The notification control unit G5 may be included in the support processing unit G1 as a function of the support processing unit G1. Further, the notification control unit G5 may be provided as an HMI control unit that controls an HMI (Human Machine Interface) such as the display 45.

<Supplementary information on the operation of the notification control unit>
The notification control unit G5 can perform notification control processing based on the fact that the RSU diagnostic unit G3 detects a malfunction in the front RSU. In one aspect, the notification control process is a process for notifying the driver of a malfunction in the front RSU. For example, the notification control process may include steps S21 to S28 as shown in FIG.

Step S21 is a step in which the RSU detection unit G31 searches for a forward RSU. For example, the RSU detection unit G31 searches for a forward RSU based on map data indicating the installation position of the RSU 1 or usage history data. Step S61 may be a process of transmitting a message requesting the RSU 1 to return a response signal. The in-vehicle device 2/RSU diagnostic unit G3 serving as the RSU detection unit G31 may perform an active scan as step S61. If no forward RSU is found, this flow is ended. On the other hand, if the forward RSU is found, step S22 is executed.

Step S22 is a step in which the RSU diagnostic unit G3 determines whether or not a problem has occurred in the front RSU. As mentioned above, it can be determined by various methods whether or not a problem has occurred in the front RSU. Further, various information can be used as a basis for determining whether or not a problem has occurred in the front RSU. The RSU diagnostic unit G3 uses the content of the signal received from the front RSU, the reception status of the signal from the front RSU, and the data received from the management server 3 or other equipment to determine if a malfunction has occurred in the front RSU. It can be determined whether the

If no malfunction is detected in the front RSU (S22 NO), this flow ends. Note that if no malfunction is detected in the front RSU, the support processing unit G1 appropriately performs driving support processing using the support message received from the front RSU. On the other hand, if it is determined that there is a problem with the front RSU (S22 YES), the vehicle-mounted device 2 executes step S23.

Step S23 is a step in which the notification control unit G5 refers to usage history data stored in the storage 113 and obtains the number of times the forward RSU is used as an error RSU. The number of times an error RSU has been used can be determined by searching usage history data using the RSU-ID/installation position of the error RSU as a search key. Nu in the figure indicates the number of times the error RSU is used.

Step S24 is a step of determining whether the number of times the error RSU has been used is zero. Step S24 corresponds to a step of determining whether an error RSU has been used in the past. The notification control unit G5 can specify that the number of times the error RSU has been used is 0 based on the fact that information regarding the error RSU is not registered in the usage history data. Further, the notification control unit G5 can specify that the number of times the error RSU has been used is one or more based on the fact that information regarding the error RSU is registered in the usage history data.

If the number of times the error RSU has been used is 0 (S24 YES), the notification control unit G5 hides the service-in image (S25). Further, in accordance with this, the support processing unit G1 changes the operation settings so as not to execute the driving support process based on the message from the error RSU. Step S25 corresponds to control to ignore the existence of the RSU 1 in which the defect has been detected when the RSU 1 has not been used before.

On the other hand, if the number of uses of the error RSU is not 0 (S24 NO), the notification control unit G5 determines whether the number of uses is less than a predetermined switching threshold (Th) in step S26. The switching threshold is a threshold for switching between notification of a malfunction in the front RSU in a subtle manner and in a relatively conspicuous manner. The switching threshold is set to a value that indicates that the driver is aware of the existence of the RSU 1 and is expecting assistance from the RSU 1 based on past usage history. For example, the switching threshold may be set to 5 times, 10 times, etc.

Notification in a conspicuous manner refers to notification in a manner intended to make the driver firmly aware that a problem has occurred in the front RSU. Notification in a conspicuous manner involves outputting a voice message/sound effect at a volume higher than a predetermined value or applying vibration. The conspicuous aspect corresponds to outputting a stimulus of sufficient intensity to attract the driver's interest. On the other hand, notification in a subtle manner refers to notification in a manner that is relatively less stimulating than notification in a conspicuous manner. The unobtrusive mode refers to a notification mode that is aimed at not bothering the occupants. Notification in a modest manner refers to notification in a manner in which image display is the main feature, in which vibrations are not applied to the driver, and the output volume is set to a predetermined value or less. Setting the output volume to a predetermined value or less includes not outputting any sound.

A modest mode can also be referred to as an inconspicuous mode. The notification control unit G5 of this embodiment is configured to be able to control the notification mode in two stages: a conspicuous mode and a discreet mode. Of course, the notification control unit G5 may be configured to be able to select a notification mode from three or more notification modes, each having a different stimulation intensity, according to the content of the problem/the driver's dependence on the support of the RSU 1/the number of times of use. . The malfunction notification process can be divided into a modest notification process and an emphasized notification process depending on the intensity of the notification mode (stimulus).

If the number of times the error RSU has been used is less than the switching threshold (S26 YES), the notification control unit G5 performs a modest notification process (S27). The discreet notification process is a process of discreetly notifying that the front RSU is experiencing a problem. The discreet notification process includes displaying the discreet notification image Im3 at a predetermined position on the display 45. The modest notification image Im3 is a defect notification image formed in a modest manner. The malfunction notification image is an image indicating that a malfunction has occurred in the front RSU. This configuration corresponds to a configuration that displays a defect notification image in a modest manner.

For example, as shown in FIG. 11, the discreet notification image Im3 is an image in which a cross mark (x) is added to the side of the RSU icon, and text Tx3 indicating that the system is out of order is placed near it. I can do it. A combined image in which a cross mark is added to the side of the RSU icon is also referred to as an RSU pause icon. In one aspect, the modest notification image Im3 shown in FIG. 11 can be interpreted as an image in which text Tx3 is placed on the side of the RSU pause icon. Note that the display position of the modest notification image Im3 can be the same position as the service-in image Im2. For example, the modest notification image Im3 may be displayed such that the RSU icon is in the same position as the service-in image Im2.

In this disclosure, the display position of the service-in image Im2 and the modest notification image Im3 is referred to as a basic display position. The basic display position may be set at a relatively inconspicuous location such as the upper end/lower end/right end/left end of the display area of the display 45. Note that the RSU icon color of the service-in image Im2 may be set to white/blue/green, while the RSU icon color of the modest notification image Im3 may be set to gray/yellow/red, etc. The status of the front RSU may be expressed by different colors of the RSU icon.

The notification control unit G5 of this embodiment does not output a warning sound (notification sound) as a modest notification process. That is, when the number of times the error RSU is used is less than the switching threshold, the notification control unit G5 does not output the warning sound (notification sound). According to the configuration in which the notification regarding the malfunction of the RSU 1 whose number of times of use is equal to or less than a predetermined value is limited to the display of an icon image, it is possible to reduce the possibility of bothering the driver. In addition, since the malfunction notification image is displayed although there is no sound output, the driver who notices that support by the RSU 1 is not being executed can recognize the operating state of the system by visually checking the basic display position. As another aspect, the modest notification process may be accompanied by the output of a sound effect at a volume that does not cause annoyance.

Furthermore, if the number of times the error RSU has been used is equal to or greater than the switching threshold (S26 NO), the notification control unit G5 performs emphasis notification processing (S28). The emphasis notification process corresponds to a process of notifying in a conspicuous manner that a problem has occurred in the front RSU. The emphasis notification process includes displaying an emphasis notification image Im4, which is a defect notification image formed in a conspicuous manner, at a predetermined position on the display 45. Furthermore, the emphasized notification process includes outputting a warning sound (notification sound) from the speaker 46 simultaneously with/prior to/after a predetermined period of time the highlighted notification image is displayed.

For example, as shown in FIG. 12, the notification control unit G5 displays an image including text directly/indirectly indicating that the front RSU is out of order in the center of the display screen of the display 45 as an emphasized notification image Im4. Display as . This configuration corresponds to a configuration in which a defect notification image is displayed in a conspicuous manner. The display position of the highlighted notification image is referred to as a temporary display position. The temporary display position may be any position that is more easily visible to the driver who is facing forward of the vehicle than the basic display position. The size of the emphasized notification image Im4 is larger than that of the modest notification image Im3. Note that the notification control unit G5 may display an RSU inactive icon Im4a at the basic display position in parallel with the emphasized notification image Im4. Further, if the in-vehicle system VS includes a meter display and a HUD as the display 45, the display destination of the emphasized notification image Im4 may be set to the HUD.

<About effects, etc.>
Drivers tend to become familiar with the support services provided by the RSU 1 on frequently traveled routes. Furthermore, when the driver passes through a frequently used service spot of the RSU 1, he or she may tend to perform driving operations thinking that he or she will receive support services from the RSU 1. However, due to the occurrence of some kind of malfunction in the RSU 1, the service may be completely stopped or the service quality (for example, object detection accuracy) may be degraded. From the driver's perspective, whether or not the RSU 1 that has been used many times is operating normally can be important information.

On the other hand, it is highly likely that the fact that the RSU 1, which has never been used before, has a problem is not important to the driver. This is because the driver does not expect/expect to enjoy the support service provided by the RSU 1, which he has never used. In addition, from the driver's point of view, it is difficult for the driver to perceive that the RSU 1 is installed on the road he/she passes for the first time. A notification of a malfunction in the RSU 1 that has never been used is of little importance to the driver, and may even cause trouble to the driver.

In other words, the importance/degree of influence of a problem occurring in the front RSU may vary depending on the number of times the driver uses the RSU 1. The present disclosure was created based on this idea, and when the vehicle-mounted device 2 detects that a malfunction has occurred in the RSU 1 located in front of the own vehicle, the vehicle-mounted device 2 Change the notification mode to the driver. Note that changing the notification mode here also includes canceling the notification.

For example, when the above-mentioned vehicle-mounted device 2 detects that a malfunction has occurred in the RSU 1 that has not been used before, it does not issue a notification regarding the malfunction of the RSU 1. According to the above control mode, it is possible to reduce the risk of bothering the driver.

In addition, when the vehicle-mounted device 2 recognizes that a problem has occurred in the RSU 1 whose number of times of use is more than a predetermined value, it is more noticeable than when it recognizes that a problem has occurred in the RSU 1 whose number of times of use is more than a predetermined value. In this manner, the driver is notified that a problem is occurring in the front RSU. With respect to the RSU 1 that is used frequently, the driver is highly likely to depend on the support service of the RSU 1, and the impact of the occurrence of a problem may be large. According to the above configuration, the driver can easily recognize in advance any malfunctions in the RSU 1 that he or she uses on a daily basis. As a result, it can be expected that the driver will perform driving operations more carefully than usual without relying on the support of the RSU 1.

Further, notification regarding a malfunction of the RSU 1 whose number of times of use is less than a predetermined value is limited to display of an icon image only. According to this configuration, it is possible to reduce the risk of bothering the driver. Furthermore, since the malfunction notification image is displayed, the driver who notices that the RSU 1 is not providing support can recognize the operating state of the front RSU based on the image display.

By the way, as one possible configuration, if the in-vehicle device 2 is able to receive a signal from the RSU 1, a configuration can be assumed in which a predetermined reception icon is displayed on the meter display. The reception icon is an icon image indicating that the service of RSU1 is available/that radio waves from the roadside device can be received, and may correspond to the service-in image Im2. The display of the reception icon can be used as a basis for determining whether the roadside machine in front is operating normally.

However, it is difficult for the driver to recognize whether or not the front RSU is operating normally based only on whether or not the reception icon is displayed. Outside the distribution area of RSU1, the reception icon is hidden even if RSU1 is operating normally. In other words, there are two patterns in which the reception icon is hidden: when the receiving icon is outside the distribution area, and when the RSU 1 is out of order. Therefore, it is difficult for the driver to recognize the status of the forward RSU just by displaying/hiding the reception icon. Further, the driver does not always pay attention to the display position of the reception icon.

In response to the above problem, the vehicle-mounted device 2 displays a malfunction notification image, which is an image different from the service-in image, based on the detection of a malfunction in the front RSU. According to this configuration, when the driver cannot enjoy the service of the RSU 1, it becomes possible to distinguish whether the cause is due to the location (outside the distribution area) or a malfunction of the RSU 1.

Furthermore, in the assumed configuration, even if the area monitoring sensor is malfunctioning, if the wireless equipment is functioning normally, the reception icon itself can be displayed normally. Therefore, the driver does not notice that the area monitoring sensor is malfunctioning or that the RSU 1's ability to recognize objects has deteriorated. Note that even if the wireless equipment of the RSU 1 is normal, if a problem occurs in the monitoring sensor, the driver may not be notified of a moving object (for example, an oncoming vehicle or a pedestrian crossing the road) that should be notified.

In response to this problem, the vehicle-mounted device 2 can also detect malfunctions in parts other than the wireless section 12. The in-vehicle device 2 also displays a malfunction notification image when detecting that a malfunction has occurred in a part other than the wireless unit 12. Therefore, according to the above configuration, even if a malfunction occurs in a part other than the communication function, the driver can recognize that fact.

Note that, unlike traffic lights and electronic bulletin boards, the operating status of the RSU 1 cannot often be visually recognized. In the first place, the driver may not recognize the position of RSU1. Therefore, it is difficult for the driver to recognize whether or not the RSU installed at the intersection, etc. that he or she will pass from now on is operating normally. In order to solve such a problem, according to the configuration of the vehicle-mounted device 2 described above, information about the RSU 1 in which the problem has occurred is notified to the driver by image/audio. This makes it easier for the driver to recognize whether or not the RSU installed at the intersection, etc. that he or she will pass from now on is operating normally.

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

<Modification (1)>
In the above embodiment, a configuration has been described in which the malfunction notification processing mode (notification mode) is changed depending on the number of times the error RSU is used, but the vehicle-mounted device 2 may change the notification mode depending on the number of warnings. For example, if the number of executions of the warning process based on the support message received from the error RSU is zero, the failure notification process is canceled, while if the number of past warnings is one or more, the failure notification process is executed. . In addition, similar to the number of uses mentioned above, if the number of warnings is more than a predetermined value (for example, three times), an emphasized notification process is performed, while if the number of warnings is less than a predetermined value, a modest notification process is performed. , the intensity may be changed in conjunction with the number of warnings. This configuration also produces effects similar to those of the above embodiment. Furthermore, it is assumed that some drivers have the warning function based on the support message of the RSU 1 set to OFF. Drivers who routinely turn off the warning function based on support messages have little interest in the operating state of the RSU 1, and there is a high possibility that malfunction notification processing is unnecessary. According to the configuration in which the mode of malfunction notification processing is determined based on the number of warnings, it is possible to reduce the risk of bothering a driver who routinely turns off the warning function based on support messages.

As another example, the in-vehicle device 2 may change the notification mode using both the number of uses and the number of warnings. For example, the notification control process may be configured as shown in FIG. The notification control process shown in FIG. 13 includes steps S33 to S39. Steps S31 to S35 are similar to steps S21 to S25.

Step S36 is a step of determining whether the number of times of use is less than a predetermined first switching threshold (Th1). The first switching threshold may be set to 5 times, 10 times, 15 times, etc. Step S37 is a step of determining whether the number of warnings is less than a predetermined second switching threshold (Th2). The second switching threshold may be set to 1 time, 3 times, 5 times, etc. The second switching threshold is set to a smaller value than the first switching threshold. Steps S38 to S39 are similar to steps S27 to S28. Each step may be executed in the order indicated by the arrows in FIG.

According to the flow shown in FIG. 13, even if the number of uses is less than the first switching threshold, the vehicle-mounted device 2 performs the emphasis notification process if the number of warnings is equal to or greater than the second switching threshold. It is highly likely that the driver is aware that the RSU 1 is installed and that support services are available at the location where the warning process was performed. There is also an increased possibility that the driver expects to be able to enjoy similar support services again. In this way, if a problem occurs in the RSU 1 that has been used a few times but has previously performed warning processing, safety can be improved by performing emphasized notification processing instead of modest notification processing.

In addition, the notification control unit G5 may change the notification mode depending on the number of interventions. For example, if the number of times the intervention process has been performed based on the support message received from the error RSU is zero, the failure notification process is canceled, while if the number of past interventions is one or more, the failure notification process is performed. . Also, similar to the number of uses mentioned above, if the number of interventions is more than a predetermined value (for example, 2 times), an emphasized notification process is performed, while if the number of warnings is less than a predetermined value, a modest notification process is performed. , the intensity may be changed in conjunction with the number of interventions. The in-vehicle device 2 may be configured to perform the emphasis notification process when the number of times of intervention is one or more even if the number of times of use/the number of warnings is less than a predetermined value. The on-vehicle device 2 may change the notification mode regarding the malfunction of the RSU 1 by appropriately combining the number of times of use, the number of warnings, and the number of interventions of the RSU 1 in which the malfunction has been detected.

<Modification (2)>
The on-vehicle device 2 may notify the location/cause of the malfunction. For example, if an abnormality in the camera 15 is detected, a malfunction notification image including text/icon indicating that the camera 15 of the RSU 1 is malfunctioning may be displayed. Furthermore, the on-vehicle device 2 may determine whether the type of malfunction of the RSU 1 is one that will lead to service suspension. The defect types can be classified into service outage types, quality (reliability) decline types, and the like. The service stop type includes a malfunction in all/more than a predetermined number of area monitoring sensors, a malfunction in the wireless section 12, a malfunction in the RSU control section 11, and the like. The defects that fall under the quality deterioration type include failures in some area monitoring sensors, failures in the GNSS receiver 13, and the like.

If the problem occurring in the front RSU corresponds to the service outage type, the on-vehicle device 2 may display an out-of-service image that is a out-of-service notification image indicating that the service is out of service. Moreover, the vehicle-mounted device 2 may display a quality-degraded image when the problem occurring in the front RSU is of a quality-degraded type. The quality degraded image is a defect degraded image indicating that the service quality is being degraded (functionality is being degraded).

Furthermore, the on-vehicle device 2 may change the image to be displayed depending on whether the RSU in which the problem has occurred has stopped distributing support messages or continues distributing support messages. If the RSU 1 in which a defect has been detected continues to deliver support messages, a degraded quality image is displayed. On the other hand, if the RSU 1 in which a problem has been detected has stopped distributing support messages, an inactive image is displayed. Whether or not the support message is being continued to be distributed can be determined based on the reception status of the support message from the RSU 1 or notifications from the RSU 1/management server 3/other vehicle-mounted devices 2.

<Modification (3)>
Although the embodiment in which both the RSU 1 and the vehicle-mounted device 2 each have a function of diagnosing the RSU 1 has been described above, the present invention is not limited to this. The on-vehicle device 2 does not need to include the RSU diagnosis section G3. Furthermore, the RSU1 does not need to include the self-diagnosis section F2. Any one of the RSU 1, the in-vehicle device 2, and the management server 3 may have a function of diagnosing the RSU 1.

<Modification (4)>
The on-vehicle device 2 may display a bad environment icon when the presence of a large vehicle within a predetermined distance in front of the vehicle is detected by a front camera or the like. The bad environment icon is an icon image that indicates that the environment is bad for road-to-vehicle communication, and that there is a possibility that road-to-vehicle communication may fail/support from road-to-vehicle communication may not be received. It is. According to the configuration, an effect of urging the driver to perform more careful driving operations can be expected.

<Modification (5)>
The content of support data/services of RSU1 can be changed as appropriate. The support data may be traffic light-related data indicating the lighting state of the traffic light. In addition to the current lighting state, the traffic light related data may include lighting cycle information such as the remaining time for which the current lighting state will be maintained, the next lighting state, and the like. The message/communication packet/communication frame indicating the support data may correspond to a SPaT (Signal Phase and Timing) message. The RSU 1 may be provided integrally with the traffic light.

Further, the support data may be control data for supporting automatic driving of a vehicle within an intersection. The support service provided by the RSU 1 may be provided for implementation/continuation of automatic driving. For example, the support data transmitted by the RSU 1 may be data related to driving control such as stopping/starting/target speed/steering angle of the self-driving vehicle. The support data may be camera image data, map data showing the shape of intersections, etc.

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

<Modification (7)>
As shown in FIG. 14, the in-vehicle system VS may include an automatic driving ECU 48. Further, the on-vehicle device 2 may be configured to be able to communicate with the automatic driving ECU 48 via the in-vehicle network VN or directly with a dedicated cable. The automatic driving ECU 48 is an ECU that causes the own vehicle to travel automatically by controlling the drive system 47 based on the detection results of the surrounding monitoring sensor 42 and map data. The automatic operation ECU 48 is also referred to as an automatic operation device.

In a configuration in which the on-vehicle device 2 is connected to the automatic driving ECU 48, an error signal may be transmitted to the automatic driving ECU 48 based on the detection of a malfunction in the front RSU. The error signal is a signal indicating that a problem has occurred in the front RSU. ErrSg in FIG. 14 represents an error signal.

According to this configuration, the automatic driving ECU 48 can perform temporary controls such as speed reduction, execution of a handover request, route change, and start of MRM (Minimal Risk Maneuver) based on receiving an error signal. becomes. In other words, the automatic driving ECU 48 can plan/execute a response according to the operating state of the front RSU with plenty of time. According to the configuration, it is possible to improve the safety of the automatic driving system. Note that the handover request is a process for requesting the driver to take over the driving operation, and may also be called a driving change request/takeover request.

<Modification (8)>
The management server 3 may determine that a malfunction has occurred in one RSU 1 based on receiving malfunction detection reports from a plurality of in-vehicle devices 2 within a certain period of time. According to the configuration in which the status of the RSU 1 is determined based on reports from a plurality of on-vehicle units 2, it is possible to reduce the risk of erroneously determining the status of the RSU 1.

Further, information on the RSU 1 in which a malfunction is detected may be distributed in advance from the management server 3 to the on-vehicle device 2. According to this configuration, it becomes possible to carry out processing such as early execution of the malfunction notification process and proposal/selection of a travel route that avoids the RSU 1 in which the malfunction has occurred. In particular, if the RSU 1 in which the problem has occurred is the RSU 1 that provides information essential for implementing/continuing automated driving, the automated driving ECU 48 may select another route or request a handover based on the notification from the management server 3. It may be possible to implement such things as soon as possible.

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

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

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

<Additional note (2)>
The present disclosure also includes the following technical ideas. Further, the following technical idea can also be applied to a communication control method.

[Technical philosophy 1]
An on-vehicle device configured to be able to receive support data, which is data for supporting the running of a vehicle, distributed from each of a plurality of roadside devices installed along a road,
a roadside device detection unit (G31) that detects a forward roadside device that is the roadside device that is present in front of the host vehicle;
There is a malfunction in the forward roadside device based on the content of the signal received from the forward roadside device, the reception status of the signal from the forward roadside device, or the data received from an external device that is a device other than the forward roadside device. a roadside machine diagnosis unit (G3) that determines whether or not a problem has occurred;
a recording processing unit (G2) that performs a process of storing usage history data, which is data about the roadside machine that has been used, in a history storage unit (M1);
comprising a notification control unit (G5) that controls notification to the driver regarding a malfunction of the forward roadside machine,
The notification control unit includes:
An in-vehicle device that changes a notification mode to a driver regarding a malfunction in the front roadside unit depending on whether or not the front roadside unit in which the malfunction has occurred has been used in the past.

[Technical thought 2]
The in-vehicle device described in Technical Idea 1,
The recording processing unit records the number of times each roadside machine is used,
The notification control unit is an in-vehicle device that changes the notification mode according to the number of times the roadside device in front of the roadside in which the problem occurs is used.

[Technical philosophy 3]
The in-vehicle device according to technical idea 1 or 2,
The notification control unit is an in-vehicle device that makes the notification mode more conspicuous as the number of uses of the roadside in front where the problem occurs increases.

[Technical thought 4]
The in-vehicle device according to any one of technical ideas 1 to 3,
The recording processing unit is an in-vehicle device that stores data of the roadside device as a transmission source of the received support data as the usage history data.

[Technical philosophy 5]
The in-vehicle device according to any one of technical ideas 1 to 4,
The recording processing unit stores, as the usage history data for each roadside device, whether or not a warning process has been performed based on the support data received from the roadside device;
The notification control unit is an in-vehicle device that changes the notification mode depending on whether or not the warning process using the support data from the forward roadside device in which a problem has occurred has been performed.

[Technical philosophy 6]
The in-vehicle device described in Technical Idea 5,
If the notification control unit has performed the warning process using the support data from the forward roadside machine in which a problem has occurred, the notification control unit may perform the notification more efficiently than if the warning process had never been performed. An on-vehicle device that makes your appearance stand out.

[Technical Thought 7]
The in-vehicle device described in Technical Idea 5,
The recording processing unit records a number of warnings, which is the number of times the warning processing was performed,
The notification control unit is an in-vehicle device that makes the notification mode more conspicuous as the number of warnings using the support data from the roadside device in front in which a problem occurs increases.

[Technical Thought 8]
The in-vehicle device according to any one of technical ideas 1 to 7,
The recording processing unit stores, as the usage history data for each roadside machine, whether or not an operation intervention process has been performed based on the support data received from the roadside machine;
The notification control unit is an in-vehicle device that changes the notification mode depending on whether or not the operation intervention process using the support data from the forward roadside device in which the problem has occurred has been performed.

[Technical philosophy 9]
The in-vehicle device described in Technical Idea 8,
If the notification control unit has performed the operation intervention process using the support data from the forward roadside machine in which a problem has occurred, the notification control unit may perform the operation intervention process more efficiently than when the operation intervention process has never been performed. An in-vehicle device that makes the notification mode conspicuous.

[Technical Thought 10]
An in-vehicle device according to any one of technical ideas 1 to 9, which is used in connection with an automatic operation device,
When the notification control unit determines that a malfunction has occurred in the forward roadside machine, the notification control unit transmits an error signal indicating that a malfunction has occurred in the forward roadside machine to the automatic operation device. An in-vehicle device configured with.

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

1 RSU (roadside unit), 2 on-vehicle unit, 3 management server (external device), 11 RSU control unit, F1 support information distribution unit, F2 self-diagnosis unit, F3 status notification unit, 22 control module, 223 storage, M1 history storage G1 Support processing unit, G2 Recording processing unit, G3 RSU diagnosis unit (roadside unit diagnosis unit), G31 RSU detection unit (roadside unit detection unit), G4 Communication processing unit, G5 Notification control unit

Claims (11)

An on-vehicle device configured to be able to receive support data, which is data for supporting the running of a vehicle, distributed from each of a plurality of roadside devices installed along a road,
a roadside device detection unit (G31) that detects a forward roadside device that is the roadside device that is present in front of the host vehicle;
There is a malfunction in the forward roadside device based on the content of the signal received from the forward roadside device, the reception status of the signal from the forward roadside device, or the data received from an external device that is a device other than the forward roadside device. a roadside machine diagnosis unit (G3) that determines whether or not a problem has occurred;
a recording processing unit (G2) that performs a process of storing usage history data, which is data about the roadside machine that has been used, in a history storage unit (M1);
comprising a notification control unit (G5) that controls notification to the driver regarding a malfunction of the forward roadside machine,
The notification control unit includes:
An in-vehicle device that changes a notification mode to a driver regarding a malfunction in the front roadside unit depending on whether or not the front roadside unit in which the malfunction has occurred has been used in the past. The in-vehicle device according to claim 1,
The recording processing unit records the number of times each roadside machine is used,
The notification control unit is an in-vehicle device that changes the notification mode according to the number of times of use of the roadside device in front in which a problem has occurred. The in-vehicle device according to claim 2,
The notification control unit is an in-vehicle device that makes the notification mode more conspicuous as the number of times the forward roadside device in which the problem occurs is used is greater. The in-vehicle device according to claim 1 or 2,
The recording processing unit is an in-vehicle device that stores data of the roadside device as a transmission source of the received support data as the usage history data. The in-vehicle device according to claim 1 or 2,
The recording processing unit stores, as the usage history data for each roadside device, whether or not a warning process has been performed based on the support data received from the roadside device;
The notification control unit is an in-vehicle device that changes the notification mode depending on whether or not the warning process using the support data from the forward roadside device in which a problem has occurred has been performed. The in-vehicle device according to claim 5,
If the notification control unit has performed the warning process using the support data from the forward roadside machine in which a problem has occurred, the notification control unit may perform the notification more efficiently than if the warning process had never been performed. An on-vehicle device that makes your appearance stand out. The in-vehicle device according to claim 5,
The recording processing unit records a number of warnings, which is the number of times the warning processing was performed,
The notification control unit is an in-vehicle device that makes the notification mode more conspicuous as the number of warnings using the support data from the roadside device in front in which a problem occurs increases. The in-vehicle device according to claim 1 or 2,
The recording processing unit stores, as the usage history data for each roadside machine, whether or not an operation intervention process, which is automatic braking or steering, has been performed based on the support data received from the roadside machine. death,
The notification control unit is an in-vehicle device that changes the notification mode depending on whether or not the operation intervention process using the support data from the forward roadside device in which the problem has occurred has been performed. The in-vehicle device according to claim 8,
If the notification control unit has performed the operation intervention process using the support data from the forward roadside machine in which a problem has occurred, the notification control unit may perform the operation intervention process more efficiently than when the operation intervention process has never been performed. An in-vehicle device that makes the notification mode conspicuous. The in-vehicle device according to claim 1 or 2, which is used in connection with an automatic operation device,
The notification control unit is configured to notify the automatic operation device that a malfunction has occurred in the forward roadside machine based on the fact that the roadside machine diagnosis unit has determined that a malfunction has occurred in the forward roadside machine. The on-vehicle device is configured to send an error signal indicating that. A notification control method implemented by at least one processor for notifying a driver of the operating state of a roadside device that distributes support data that is data for supporting driving of a vehicle, the method comprising:
Detecting a front roadside machine, which is the roadside machine, that is present in front of the own vehicle, which is the vehicle in which the processor is used (S21);
performing a process of storing usage history data, which is data about the roadside machine that has been used, in a history storage unit (M1) (S12);
There is a malfunction in the forward roadside device based on the content of the signal received from the forward roadside device, the reception status of the signal from the forward roadside device, or the data received from an external device that is a device other than the forward roadside device. determining whether or not it has occurred (S22);
Changing the manner of notification to the driver regarding the malfunction of the forward roadside machine depending on whether or not the forward roadside machine in which the malfunction has occurred has been used in the past (S24 to S28, S34 to S39). and a notification control method including.

Images