Traffic event trigger dissemination device, traffic event trigger reception device, and traffic event data collection system

Abstract

An electronic control device (10t) that serves as a traffic event trigger dissemination device is associated with a vehicle (1t) that is a host agent, and disseminates a traffic event trigger to other agents. The electronic control device (10t) comprises a CPU (10a) and an interface (10b) for external communication. The CPU (10a) is configured so as to generate a traffic event trigger on the basis of an event trigger condition, and, in accordance with the generation of the traffic event trigger, issue a message requesting the storage of traffic event-related data to other agents that are present in the vicinity of the CPU via the interface (10b).

Description

Traffic event trigger propagation device, traffic event trigger receiving device, and traffic event data collection system CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-123715 filed in Japan on July 30, 2024, and the contents of the original application are incorporated by reference in their entirety.

[0002] TECHNICAL FIELD This disclosure relates to techniques for recording multiple aspects of traffic events.

[0003] Patent Document 1 discloses that a computing device in a server collects data from an agent in accordance with a data collection policy included in the computing device.

[0004] US Patent Application Publication No. 2022 / 0204010

[0005] Such data is, for example, data related to traffic events. When verifying such traffic events, verification is performed using multifaceted data obtained by multiple agents, rather than using data obtained by a single agent, which can provide more objective and useful verification results. Therefore, there is a need to promote the storage of data related to a single traffic event in more agents, thereby enabling multifaceted verification of traffic events.

[0006] One of the objectives of the disclosure of this specification is to provide a traffic event trigger propagation device, a traffic event trigger receiving device, and a traffic event data collection system that facilitates the verification of traffic events from multiple angles.

[0007] One aspect disclosed herein is a traffic event trigger propagation device associated with a host agent that propagates a traffic event trigger to other agents, the device comprising at least one processing unit and a communication interface for communicating with the outside, wherein the at least one processing unit is configured to: generate a traffic event trigger based on an event trigger condition; and, upon the generation of the traffic event trigger, send a message via the communication interface to other agents in the vicinity of the device requesting the storage of data related to the traffic event.

[0008] According to this aspect, when a traffic event trigger for a traffic event for which multifaceted verification is desired occurs based on the event trigger condition, the host agent issues a message to other agents. By receiving a message requesting data storage related to the traffic event from other agents in the vicinity of the host agent, the other agents can request data storage from a location other than the host agent, using resources other than the host agent. This increases the likelihood of verifying the multifaceted data acquired by multiple agents for a single traffic event.

[0009] Another aspect disclosed herein is a traffic event trigger receiving device associated with a host agent that receives a message generated by a source agent to spread a traffic event trigger, the device comprising at least one processing unit and a communication interface for communicating with the outside, wherein the at least one processing unit is configured to: acquire, via the communication interface, a message requesting the storage of data related to a traffic event; and transition to a traffic event trigger compatible state in which the data related to the traffic event is stored in a storage medium at a higher level than before the message was acquired.

[0010] According to this aspect, the host agent receives a message generated by the source agent requesting the storage of traffic event-related data. In response to this, the host agent transitions to a traffic event trigger-enabled state. In the traffic event trigger-enabled state, the traffic event-related data is stored in a storage medium at a higher level than before the message was received, so the data is stored in a location and using resources different from those of the source agent. This increases the possibility of verifying the multifaceted data collected by multiple agents for a single traffic event.

[0011] Another aspect disclosed herein is a traffic event data collection system for collecting data related to traffic events, including: a first device associated with an agent and configured to propagate a traffic event trigger; one or more second devices associated with one or more other agents and configured to be able to receive a message generated by the first device; and a server wirelessly connected to the first and second devices, wherein the first device is configured to: generate a traffic event trigger based on an event trigger condition; transition to a traffic event trigger response state in which data related to the traffic event is stored in a storage medium at a level higher than before the traffic event trigger was generated; issue a message to other agents present in the vicinity of the first device in response to the generation of the traffic event trigger, requesting that data related to the traffic event be saved; and transmit the data related to the traffic event saved in the traffic event trigger response state to the server; and the second device: acquire the message requesting that data related to the traffic event be saved; and transition to a traffic event trigger response state in which data related to the traffic event is stored in a storage medium at a level higher than before the message was acquired; and transmitting data relating to the traffic event stored in the traffic event trigger enabled state to a server.

[0012] According to this aspect, by spreading a traffic event trigger from an agent associated with a first device to an agent associated with a second device, data related to the traffic event is stored in a storage medium at a high level in each agent. Furthermore, since the various data acquired by multiple agents for one traffic event are collected by a server, it becomes possible to verify the traffic event from various angles.

[0013] Note that the symbols in parentheses included in the claims etc. are intended to exemplify the correspondence with the parts of the embodiments described below, and are not intended to limit the technical scope.

[0014] A diagram explaining an agent in a traffic environment. A diagram schematically showing the hardware configuration of a data collection system. A diagram schematically showing the functional configuration of a data collection system. A flowchart illustrating an example of overall processing related to a data collection function. A diagram schematically showing the functional configuration related to a trigger propagation function and a trigger receiving function. A flowchart illustrating an example of processing on the sending side. A flowchart illustrating an example of processing on the receiving side. A diagram schematically showing the configuration of an agent related to a trigger propagation function and a trigger receiving function. A diagram showing the relationship between sensors mounted on a vehicle and the location where a traffic event occurs. A flowchart illustrating a process for determining a data recording mode.

[0015] In this disclosure and claims, the term "processor" refers to one or more hardware processors configured to load computer program code (i.e., one or more instructions of a computer program) included in a computer program and execute the processing defined by the code. In other words, a "processor" is a hardware device that executes one or more programmed processes. Therefore, computer program code can also be considered software that can define the processing of the processor depending on its content. For example, a "processor" may be a general-purpose or special-purpose processor, such as, but not limited to, a CPU, a microprocessor, a GPU, and a DFP (Data Flow Processor).

[0016] In this disclosure and in the claims, the term "memory" refers to one or more hardware memories that are non-transitory tangible recording media and configured to store computer program code and / or data accessible to a processor. The "memory" may be implemented using memory technologies such as SRAM, SDRAM, non-volatile flash memory, or other types of memory. Computer program code constituting a program may be stored in the memory and executed by a processor to cause the processor to perform the various functions described above.

[0017] In this disclosure and in the claims, the term "circuit" refers to one or more hardware logic circuits configured to perform specific processing based on a pre-designed circuit configuration. In other words (and in contrast to "processor"), a "circuit" in this disclosure and in the claims refers to a hardware device that performs specific processing based on a circuit configuration, rather than a software-based process such as computer program code. For example, a "circuit" may include custom ICs such as application-specific integrated circuits (ASICs) and field-programmable gate arrays (FPGAs) designed using a hardware description language (HDL). In other words, a "circuit" in this disclosure and in the claims includes all hardware circuits except for a processor that executes processing by loading computer program code.

[0018] In this disclosure or in the claims, the phrase "at least one circuit and processor" should be construed as a disjunction (a logical OR), and not as at least one circuit and at least one processor.

[0019] In this disclosure or claims, the term "processing unit" refers to a hardware device that performs processing using a "processor," a "circuit," or a combination thereof. The "processing unit" may refer to the "processor" itself if its function is interpreted as being not achievable by a "circuit" but is achievable by a "processor."

[0020] Hereinafter, several embodiments will be described with reference to the drawings. Note that corresponding components in each embodiment are given the same reference numerals, and redundant description may be omitted. When only a portion of the configuration is described in each embodiment, the configuration of another embodiment described previously can be applied to the remaining portion of the configuration. Furthermore, in addition to the combinations of configurations explicitly stated in the description of each embodiment, configurations of several embodiments can also be partially combined together even if not explicitly stated, as long as there is no particular problem with the combination.

[0021] (First embodiment) The electronic control unit 10v is a device individually associated with an agent. The electronic control unit may be the agent itself. As shown in FIG. 1 , the agent may be, for example, a vehicle 1 (automobile, motorcycle), a roadside unit 5, a pedestrian 6, a bicycle, a police officer, etc., but the first embodiment will be described with reference to an example in which the agent is the vehicle 1. When the agent is the vehicle 1, the electronic control unit 10v may be an on-board device mounted on the vehicle 1.

[0022] The electronic control unit 10v has a function suitable for recording traffic events from multiple angles using multiple agents. For this purpose, the electronic control units 10v associated with each agent can be directly or indirectly connected to each other so that they can communicate with each other. The electronic control unit 10v has at least one of a function for spreading a traffic event trigger to other agents (hereinafter referred to as a trigger spreading function) and a function for receiving a traffic event trigger issued by another agent (hereinafter referred to as a trigger receiving function), but more preferably has both. An electronic control unit 10v having the trigger spreading function corresponds to a traffic event trigger spreading device. An electronic control unit 10v having the trigger receiving function corresponds to a traffic event trigger receiving device. An electronic control unit 10v having both functions corresponds to both a traffic event trigger spreading device and a traffic event trigger receiving device.

[0023] The traffic event data recorded by the traffic event collection system is used in a traffic event data collection system. As shown in FIG. 2 , the traffic event data collection system may be a data collection system DCS that collects not only data related to traffic events but also various types of vehicle data. The data collection system DCS collects data from the vehicle 1 and may also collect data from the roadside unit 5. The collected data is used, for example, for developing the hardware of the vehicle 1 or applications used in the vehicle. The collected data may also be used for urban planning, such as improving traffic signal control and road infrastructure. The collected data may also be used for planning commercial facility openings, etc.

[0024] Vehicle 1 is a vehicle that can participate in public road traffic. Vehicle 1 may be a vehicle that can be manually driven by a driver. Vehicle 1 may be a vehicle that can be automated. The automation level of vehicle 1 is classified into levels 1 to 5 as defined in SAE J3016, for example. Vehicle 1 may be capable of driving at any of the levels.

[0025] At levels 0 to 2, the driver performs some or all of the dynamic driving tasks. Levels 0 to 2 may be classified as so-called manual driving. Level 0 indicates that driving is not automated. Level 1 indicates that the driver is assisted. Level 2 indicates that driving is partially automated. Levels 3 to 5 may be classified as so-called automated driving. Level 3 indicates that driving is conditionally automated. Level 4 indicates that driving is highly automated. Level 5 indicates that driving is fully automated.

[0026] The data collection system DCS is configured to include an electronic control unit 10v mounted on a vehicle 1 and a server 20. The data collection system DCS may further include a development computer 30, and may also include an electronic control unit mounted on a roadside unit 5. Although the following description focuses on one vehicle 1 and its device 10v, the data collection system DCS may also be configured to collect data from multiple vehicles 1. In other words, the data collection system DCS may include multiple electronic control units 10v individually corresponding to each vehicle 1. Similarly, the data collection system DCS may also be configured to collect data from multiple roadside units 5.

[0027] The data collection system DCS is suitable for collecting data on long-tail cases encountered by vehicles 1 that can participate in public road traffic. Long-tail cases are cases that cannot be covered by development in a closed environment. Collecting data on long-tail cases can improve the coverage of applications and their functions in real environments. In addition to the traffic event-related functions described above, the electronic control unit 10v executes processing to acquire vehicle data from various on-board devices of the vehicle 1 and transfer it to the server 20 in order to collect vehicle data in the data collection system DCS. Next, the collection of vehicle data in the data collection system DCS will be described in detail.

[0028] The electronic control device 10v may be, for example, an ECU (Electronic Control Unit) mainly composed of a computer. The computer constituting the electronic control device 10v has at least one CPU (Central Processing Unit) 10a and one memory 10c. The memory 10c non-temporarily stores computer programs and data that can be read by the CPU 10a. The computer may also be provided with a rewritable volatile storage medium such as a RAM (Random Access Memory) 10d. The CPU 10a can execute various processes in accordance with the computer programs stored in the memory 10c. The computer also includes an interface 10b for communicating data with the outside.

[0029] The electronic control unit 10v also includes a storage 10e for recording vehicle data and traffic event-related data. The storage 10e is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 10e has a storage area with a finite storage capacity.

[0030] The vehicle data is data generated by the vehicle 1. The vehicle data may or may not be data related to a traffic event. The vehicle data may be sensor data generated by a sensor mounted on the vehicle 1 detecting the external or internal environment of the vehicle 1. The vehicle data may be data related to a diagnostic code generated to warn of at least one of a fault and an abnormality in the vehicle 1.

[0031] The vehicle data may be data generated during or as a result of an operation performed by an application running on the vehicle 1. The application here may be a software unit that realizes a specific function and is operated by one or more pieces of software. Such an application may be operated by the CPU 10a executing a computer program stored in the memory 10c in the electronic control unit 10v. Alternatively, the application may be operated by a CPU in an on-board device separate from the electronic control unit 10v, which is installed in the vehicle 1, and which executes a computer program stored in the memory.

[0032] The electronic control unit 10v is configured to transmit data stored in the storage 10e to the server 20 using a DCM (Data Communication Module) 11. The DCM 11 is a communication module mounted on the vehicle 1. The DCM 11 transmits and receives radio waves to and from base stations around the vehicle 1 through wireless communication conforming to communication standards such as LTE (Long Term Evolution) and 5G. By mounting the DCM 11, the vehicle 1 becomes a connected car that can connect to the Internet. Furthermore, the DCM 11 cooperates with the electronic control unit 10v to transmit data to the server 20.

[0033] The server 20 is a data collection device installed in the external environment of the vehicle 1. The server 20 is configured to be connected to the Internet, for example, so as to be able to collect data acquired by each agent of the vehicle 1, etc.

[0034] The server 20 may be configured by a single processing device or may be a cloud server, which means a server on a network realized by cloud computing and is realized by multiple processing devices located in remote locations apart from each other.

[0035] The processing device in the server 20 is mainly composed of, for example, a computer. The computer constituting the processing device has at least one CPU 20a and one memory 20c. The memory 20c non-temporarily stores computer programs and data that can be read by the CPU 20a. The computer may also be provided with a rewritable volatile storage medium such as a RAM 15d. The CPU 20a can execute various processes in accordance with the computer programs stored in the memory 20c. The computer also includes an interface 20b for exchanging data with the outside.

[0036] The processing device also includes a storage 20e for recording data. The storage 20e is a rewritable nonvolatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 20e has a limited storage area with a much larger storage capacity than the storage 10e of the electronic control device 10v. The server 20 stores the data collected from each agent in the storage 20e.

[0037] The development computer 30 is a development device provided in the external environment of the vehicle 1. The development computer 30 may be, for example, a personal computer operated by a developer of the vehicle 1 or an application for the vehicle 1. The developer may be, for example, an engineer who is knowledgeable about vehicle control and software.

[0038] The development computer 30 has at least one CPU 30a and one memory 30c. The memory 30c non-temporarily stores computer programs and data that can be read by the CPU 30a. The computer may also be provided with a rewritable volatile storage medium such as a RAM (Random Access Memory) 30d. The CPU 30a can execute various processes in accordance with the computer programs stored in the memory 30c.

[0039] Furthermore, development computer 30 includes interface 30b for exchanging data with the outside. Interface 30b includes a communications interface for connecting development computer 30 to the Internet, and an operation interface for inputting signals and operating devices such as a keyboard and mouse for accepting operations from the developer. Development computer 30 is communicably connected to server 20, and is able to exchange data required for development by the developer.

[0040] Next, an example of a logical architecture for the data collection system DCS to realize the function of collecting data from the vehicle 1 will be shown with reference to FIG.

[0041] The electronic control unit 10v may include a trigger management unit V1, a current application control unit V2, a development application control unit V3, and a storage and transmission unit V4 as functional units whose functions are realized when the CPU 10a executes a computer program stored in the memory 10c. Some of these functional units may be provided in an in-vehicle device separate from the electronic control unit 10v.

[0042] The server 20 may have at least one of a development application distribution unit C1, an instruction setting unit C2, and a data collection unit C3 as functional units whose functions are realized by the CPU 20a executing a computer program stored in the memory 20c.

[0043] The development computer 30 may include at least one of a scene extraction unit D1, a labeling unit D2, a machine learning unit D3, a verification unit D4, and an upload unit D5 as functional units whose functions are realized when the CPU 30a executes a computer program stored in the memory 30c.

[0044] The development computer 30 may include at least one of a scene extraction unit D1, a labeling unit D2, a machine learning unit D3, a verification unit D4, and an upload unit D5 as functional units whose functions are realized when the CPU 30a executes a computer program stored in the memory 30c.

[0045] Each functional unit will be described in detail below. The trigger management unit V1 acquires, from the instruction setting unit C2, acquisition instruction information that indicates the data to be collected in the vehicle 1, using the DCM 11. Based on the acquisition instruction information, the trigger management unit V1 sets a collection trigger condition that serves as a trigger for starting collection of vehicle data. Here, the collection trigger condition may be the condition specified by the acquisition instruction information (hereinafter referred to as the instruction condition), or may be set by the vehicle 1 or the trigger management unit V1 itself.

[0046] While the vehicle 1 is in use, the trigger management unit V1 successively determines whether the collection trigger condition is currently satisfied. As a result, if the state transitions from a state in which the collection trigger condition is not satisfied to a state in which the collection trigger condition is satisfied, the trigger management unit V1 requests the current application control unit V2 and the development application control unit V3 to start acquiring and recording data. As a result, if the state transitions from a state in which the collection trigger condition is satisfied to a state in which the collection trigger condition is not satisfied, the trigger management unit V1 requests the current application control unit V2 and the development application control unit V3 to stop acquiring and recording data. Note that the collection trigger condition here may basically be the same for both the current application control unit V2 and the development application control unit V3. However, different conditions may also be set.

[0047] The current application control unit V2 controls the current application, which is an application that is currently being used officially to control the vehicle 1 in the vehicle 1. The current application control unit V2 starts and operates the current application based on an operation by a driver or other occupant to enable the current application.

[0048] The current application control unit V2 also receives a request to record data from the trigger management unit V1. If a recording request has been received, the current application control unit V2 acquires the data requested to be recorded and related to the operation of the current application, and requests that the data be recorded in the storage and transmission unit V4.

[0049] The development application control unit V3 controls a development application, which is an application under development and distributed from the server 20. The development application may be an application that is an improvement of a current application having similar functions, or may be an application with more advanced functions than the current application.

[0050] The development application control unit V3 operates the development application in a special mode, such as a shadow mode, a ghost mode, etc. In other words, the development application is tested under the special mode operation.

[0051] Shadow mode is a mode in which a development application runs in parallel with the current application behind the scenes, for example, during autonomous driving. Shadow mode runs the development application in such a way that data related to the operation of the development application can be obtained in real time without activating the actual vehicle control function of the development application. Shadow mode makes it possible to evaluate the performance and behavior of the development application while restricting the impact on actual vehicle control and the driver.

[0052] Ghost mode is a mode in which a development application runs in parallel behind the scenes while, for example, a driver is actually driving. The development application here is an application that provides an automated driving function with an automation level of 3 or higher. In ghost mode, the driver's actions and the behavior of the vehicle 1 are tracked, and information on the performance of the development application can be collected by comparing the driver's driving with the behavior of the automated driving function. In ghost mode, differences between the driver's driving and the behavior of the automated driving function are evaluated, and improvements to the development application can be identified.

[0053] If the development application is an improved version of the current application, the development application control unit V3 may start and operate the development application so as to link with the current application based on an operation by a driver or other occupant to enable the current application, etc. However, as described above, unlike the current application, the output of the development application is not directly reflected in the actuators and HMI (Human Machine Interface) device of the vehicle 1.

[0054] The HMI device 13 of the vehicle 1 may be, for example, an in-vehicle information notification device that notifies information to occupants such as the driver inside the vehicle, or may be an operation device operated by the driver. The information notification device may be a meter display, a head-up display, a center information display (CID), or the like. The CID is, for example, an in-vehicle display device disposed in the center of the instrument panel of the vehicle 1. The CID is equipped with a display and a touch panel, and allows the driver to input operations using the touch panel, so it also serves as an operation device.

[0055] The development application control unit V3 may monitor the operation of the development application and diagnose any abnormalities in the development application. However, because the output of the development application does not affect vehicle control, the development application control unit V3 may not forcibly terminate the development application when it detects an abnormality, and may decide not to warn the driver of the abnormality.

[0056] The development application control unit V3 also receives a request to record vehicle data from the trigger management unit V1. If a recording request has been received, the development application control unit V3 acquires the vehicle data requested to be recorded and that is related to the operation of the development application, and requests that the data be recorded in the storage and transmission unit V4.

[0057] The storage and transmission unit V4 sequentially records the requested vehicle data in the storage 10e in response to recording requests from the current application control unit V2 and the development application control unit V3. This recording may be temporary storage until the vehicle data is transmitted.

[0058] Before recording data in the storage 10e, the storage transmission unit V4 checks the remaining storage capacity of the storage 10e (hereinafter referred to as the remaining storage capacity). If the remaining storage capacity is greater than a preset threshold, the storage transmission unit V4 records the requested vehicle data. If the remaining storage capacity is equal to or less than the preset threshold, the storage transmission unit V4 deletes some or all of the data already stored in the storage 10e in order to record the requested vehicle data.

[0059] Furthermore, the storage transmission unit V4 transmits the data recorded in the storage 10e to the server 20 via the DCM 11. The data transmission may be performed at a timing that depends on the storage capacity, the communication environment of the vehicle 1, etc. The storage transmission unit V4 deletes the vehicle data that has been transmitted to the server 20 from the storage 10e.

[0060] In the server 20, the data collection unit C3 manages the vehicle data transmitted from the vehicle 1. Specifically, the data collection unit C3 sequentially stores in the storage 20e the vehicle data transmitted from the storage transmission unit V4 of the vehicle 1. When the server 20 is communicably connected to a plurality of vehicles 1 and collects vehicle data from the plurality of vehicles 1, the vehicle data transmitted from the plurality of vehicles 1 may be sequentially stored in a mixed state in the same storage 20e.

[0061] Furthermore, in response to a download request from development computer 30, data collection unit C3 transmits vehicle data stored in storage 20e to development computer 30. The vehicle data transmitted at this time may be data corresponding to the download request, or may be all or a portion of the data stored in storage 20e.

[0062] In the development computer 30, at least one of the scene extraction unit D1 and the labeling unit D2 requests a download from the server 20. When the server 20 provides vehicle data in response to the download request, the scene extraction unit D1 and the labeling unit D2 classify the large amount of vehicle data. The scene extraction unit D1 extracts, from the vehicle data, vehicle data related to scenes required for verifying the development application. The extracted scenes may be scenes specified by the developer through input operations on the interface 30b, etc. The scenes here may be replaced with scenarios represented by a sequence of scenes that define a situation at a given moment.

[0063] The labeling unit D2 labels the downloaded vehicle data. The labeling here may be adding or associating information about the scene extracted based on the processing by the scene extraction unit D1 to the corresponding vehicle data. The labeling here may also be labeling of other information.

[0064] The vehicle data classified by the scene extraction unit D1 and the labeling unit D2 in this manner is used by the machine learning unit D3. The machine learning unit D3 performs machine learning using the vehicle data. The machine learning here may be optimization of a model used in the development application and configured mainly using a neural network or the like, using the vehicle data, with a technique such as deep learning. The optimization here may be optimization of various parameters used in the development application. The development application can be further improved by the machine learning unit D3.

[0065] The verification unit D4 executes a process for verifying the improved developed application. The verification process here may be offline or online. The verification process here may be autonomous verification without the involvement of the developer, in which a conclusion is reached as to whether the developed application has any defects through processing of a verification program stored in memory 30c. The verification here may involve outputting verification data required for the developer to perform the verification through processing of the verification program stored in memory 30c.

[0066] Based on the results of the verification using the verification unit D4, the developer may decide to use the tested developed application as is, or may decide to improve the developed application and test it again. In the latter case, the developer uses the function of the upload unit D5.

[0067] The upload unit D5 uploads a development application created by a developer to the server 20. The upload unit D5 may also upload a data collection plan associated with the development application. The data collection plan may include the type of vehicle data to be collected in testing the development application and the scale of the vehicle data. The scale may include the number of vehicles from which vehicle data is to be collected, or the total number of specific vehicle data required to be acquired. The data collection plan may also include information for identifying the vehicles 1 from which data is to be collected. This information may, for example, directly and individually specify the vehicles from which data is to be collected, or may be specified by setting conditions such as vehicle type. When the vehicles from which data is to be collected are individually specified, the data collection plan may include the instruction information itself, as described below. The data collection plan may be set by the developer through input operations on the interface 30b, or may be generated by the upload unit D5.

[0068] The development application distribution unit C1 in the server 20 identifies the vehicles 1 from which data will be collected based on the data collection plan. The development application distribution unit C1 distributes the development application received from the development computer 30 to the identified vehicles 1.

[0069] In the server 20, the instruction setting unit C2 sets collection instructions for each vehicle 1 that is a target for data collection and that is identified by the development application distribution unit C1 based on the data collection plan, and generates acquisition instruction information for sharing the instructions. The instruction setting unit C2 distributes the generated acquisition instruction information to each vehicle 1. The distribution of the development application and the acquisition instruction information may be performed at the same time or at different times.

[0070] Next, an example of a processing method for implementing the function of collecting data from the vehicle 1 using the data collection system DCS will be described using the flowchart in Figure 4. Steps S1 to S8 in this flowchart outline the overall processing flow for the data collection function. The series of processes in S1 to S8 may be implemented, for example, by the CPUs 10a, 20a, and 30a of the electronic control unit 10v, the server 20, and the development computer 30 executing computer programs stored in the memories 10c, 20c, and 30c.

[0071] In S1, the development computer 30 uploads the development application and data collection plan to the server 20.

[0072] In S2 after the processing of S1, the server 20 generates acquisition instruction information for each vehicle 1 based on the data collection plan. In S3 after the processing of S2, the server 20 distributes the developed application and the acquisition instruction information to each vehicle.

[0073] In S4 after processing S3, the electronic control unit 10v in each vehicle 1 sets a collection trigger condition, which is a condition that triggers starting to acquire and record vehicle data, based on the acquisition instruction information. In S5 after processing S4, the electronic control unit 10v acquires and records vehicle data based on the collection trigger condition. In S6 after processing S5, the electronic control unit 10v uploads the vehicle data to the server 20.

[0074] In S7 after the processing of S6, the development computer 30 downloads the vehicle data uploaded to the server 20 and executes processing to classify the vehicle data. In S8 after the processing of S7, the development computer 30 executes processing to verify the development application based on the classified vehicle data. The series of processes ends with S8.

[0075] Next, the trigger propagation function and the trigger receiving function will be described in detail with reference to FIG. 5. Here, for convenience, the transmitting electronic control unit 10v that performs the trigger propagation function for a certain traffic event is the electronic control unit 10t mounted on the vehicle 1t, and the receiving electronic control unit 10v that performs the trigger receiving function is the electronic control unit 10t mounted on the vehicle 1r. Note that the transmitting and receiving sides may be interchanged for different traffic events. As described above, in the first embodiment, the electronic control units 10t and 10v each have the hardware configuration and functions of the electronic control unit 10v described above.

[0076] The electronic control device 10t may include an event trigger generation unit VT1, a message issuing unit VT2, and a state change unit VT3 as functional units that realize a trigger propagation function when the CPU 10a executes a computer program stored in the memory 10c. The electronic control device 10r may include a message receiving unit VR1 and a state change unit VR2 as functional units that realize a trigger reception function when the CPU 10a executes a computer program stored in the memory 10c.

[0077] In addition, in order to make it possible to switch the sending and receiving sides as described above, it is preferable that the electronic control device 10t further includes a message receiving unit VR1 and a state change unit VR2, and the electronic control device 10r further includes an event trigger generation unit VT1 and a message issuance unit VT2.

[0078] On the transmitting side, the event trigger generation unit VT1 generates a traffic event trigger based on the event trigger condition. The traffic event may be an event for which multifaceted recording is desirable. The traffic event trigger may indicate the occurrence of such an event or may be a trigger for starting multifaceted recording. The traffic event trigger may be data expressed in the form of an electronic flag, an electronic certificate, or the like. The traffic event trigger may or may not include information for identifying the traffic event that caused the trigger to be generated. The traffic event trigger may be generated by the event trigger generation unit VT1, or may be generated by another device at the request of the event trigger generation unit VT1.

[0079] The event trigger condition here may be the collection trigger condition itself set in the trigger management unit V1. In this case, the occurrence condition of the traffic event trigger is linked to the data collection function. On the other hand, the event trigger condition may be a condition different from the collection trigger condition set in the trigger management unit V1.

[0080] Here, examples of traffic events are shown. The traffic event may be the occurrence of a collision. Here, the collision may be a collision between the vehicle 1t and another moving or stationary object, or a collision between other objects. The traffic event may be the occurrence of a vehicle malfunction on a road. The vehicle may be the vehicle 1t or another vehicle. The traffic event may be the occurrence of a sudden movement (a jark). The sudden movement may be, for example, a sudden acceleration, a sudden deceleration, or a sudden steering. The sudden movement may be a sudden movement of the vehicle 1 equipped with the electronic control device 10t, or a sudden movement of another vehicle. The event trigger generation unit VT1 may detect the occurrence of these traffic events by acquiring the operation status of an in-vehicle application that operates in response to the occurrence of a collision or a sudden movement. For example, the event trigger conditions may include the operation of a driving assistance application for risk avoidance, such as AEB (Autonomous Emergency Braking), the operation of an airbag, or the operation of an automatic reporting system that automatically reports an accident to a center when a collision occurs.

[0081] A traffic event may be the occurrence of a violation of a safety envelope, which may be a set of limits and conditions within which a driving system of a vehicle is designed to operate, subject to constraints or controls, in order to maintain operation within an acceptable level of risk. A safety envelope may be a general concept that can be used to accommodate all principles to which a driving policy can adhere, whereby an ego-vehicle operated by its driving system may have one or more boundaries around it.

[0082] The safety envelope may be, for example, a safety distance adopted in the RSS (Responsibility Sensitive Safety) model. For example, the longitudinal safety distance may be the distance at which a rear-end collision does not occur even if a leading vehicle brakes at maximum deceleration while traveling at a predetermined speed and stops, and a following vehicle accelerates at maximum acceleration for a predetermined response time and then brakes at minimum deceleration to stop. The lateral safety distance may be the minimum distance at which a collision does not occur even if two vehicles, traveling side by side at predetermined lateral speeds, accelerate laterally at maximum acceleration for a predetermined response time and then decelerate laterally at maximum deceleration.

[0083] When such a traffic event is recognized by the recognition module, the event trigger generation unit VT1 determines that the event trigger condition is met and generates a traffic event trigger.

[0084] The recognition module 12 may be an external environment sensor that detects the external environment of the vehicle it. Examples of the external environment sensor include a camera, LiDAR (Light Detection and Ranging / Laser Imaging Detection and Ranging), laser radar, millimeter-wave radar, and ultrasonic sonar. The recognition module 12 may be a sensor fusion device that fuses the detection results of multiple external environment sensors. The recognition module 12 may also be a behavior prediction device that recognizes road users around the vehicle it and predicts the behavior of these road users.

[0085] The recognition module 12 may also be an internal environment sensor that detects the internal environment of the vehicle 1t. The internal environment sensor may be, for example, a speed sensor, an acceleration sensor, a gyro sensor, an actuator sensor, a driver status monitor, a biological sensor, a seating sensor, or a tire pressure sensor.

[0086] The recognition module 12 may also be a risk identification device that identifies the collision risk of the vehicle 1t or surrounding road users, and may be a device that calculates the above-mentioned safety envelope, safety distance, time to collision, etc.

[0087] The event trigger condition may also include the driver of the vehicle it executing an input operation to generate a traffic event trigger on the HMI device 13 mounted on the vehicle it. In other words, the event trigger condition may include a manual trigger. When the event trigger generation unit VT1 recognizes that the driver has executed an input operation to generate a traffic event trigger, it determines that the event trigger condition is satisfied and generates a traffic event trigger.

[0088] In response to the occurrence of a traffic event trigger, the message issuing unit VT2 outputs a command to issue a message to other agents present in the vicinity of the vehicle it equipped with the electronic control unit 10t via the interface 10b. Here, it is preferable that the message is issued immediately or as soon as possible when a traffic event trigger occurs. The message here is a message for spreading the traffic event trigger to other agents and a message requesting the storage of data related to the traffic event.

[0089] The message may be issued using at least one of the DCM 11, the light-emitting device 14, and the speaker 15. When the DCM 11 is used, the message issuing unit VT2 generates a message to be sent to another agent and outputs the message to the DCM 11 together with an instruction to transmit the message via V2X communication. Alternatively, the message issuing unit VT2 may output an instruction to generate a message and an instruction to transmit the message via V2X communication to the DCM 11, causing the DCM 11 to generate the message. The message here is data generated according to a predetermined format used for V2X.

[0090] The light-emitting device 14 mounted on the vehicle 1t is, for example, a lighting device or an exterior display device. The lighting device is, for example, a headlight unit, a hazard lamp unit, a turn signal unit, a backlight unit, a welcome lamp unit, or the like. These lighting devices are capable of issuing optical signals to the exterior of the vehicle using flashing patterns. The exterior display device is a device primarily consisting of a display that can display images facing the exterior of the vehicle. The exterior display device may be, for example, a destination guide board provided on a bus as the vehicle 1, a device for displaying to the exterior whether a vehicle capable of achieving autonomous driving at automation level 3 or higher is operating automatically or manually, or a device that provides a more general-purpose display.

[0091] When the light-emitting device 14 is used, the message issuing unit VT2 generates a message to be sent to other agents and outputs the message to the light-emitting device 14 together with an instruction to transmit the message by light signal. This light signal may be a display such as text or a graphic that can be read by humans, such as drivers of other vehicles or pedestrians, or may be a code, two-dimensional code, or the like that is unreadable by ordinary humans. The light signal is intended to be read by the recognition module 12 (e.g., an on-board camera) of the vehicle 1r. The message may be converted into a light signal by the message issuing unit VT2 or by the light-emitting device 14.

[0092] The speaker 15 mounted on the vehicle it is a device for outputting sound to the outside of the vehicle. The speaker 15 may be a device for sounding an alarm (horn). When the speaker 15 is used, the message issuing unit VT2 generates a message to be transmitted to other agents and outputs the message to the speaker 15 together with an instruction to transmit the message by sound signal. This sound signal may be a verbal voice or a siren. The sound signal may be intended to be read by the recognition module 12 (e.g., an acoustic sensor) of the vehicle in which the electronic control unit 10r is mounted. The message may be converted into a sound signal by the message issuing unit VT2 or by the speaker 15.

[0093] In this way, the electrical signals, optical signals, and sound signals generated by V2X communication are transmitted to the vicinity of vehicle it without specifying a target. The transmission range is the range within which these signals can reach. On the other hand, the target for which data storage is requested may or may not be specified. When specifying a target for which data storage is requested, the message transmission unit VT2 adds information specifying the target for which data storage is requested to the message. For example, the target for which data storage is requested may be limited to vehicle 1r traveling in the same lane as vehicle it. The message transmission unit VT2 can narrow down the limited range of targets by referring to a high-precision map database provided in vehicle it.

[0094] Next, on the receiving side, the message receiving unit VR1 acquires the message issued based on the processing of the electronic control unit 10t through the interface 10b. The message receiving unit VR1 acquires the message received by the DCM 11 through V2X communication.

[0095] Furthermore, the message receiving unit VR1 acquires the recognition result of the recognition module 12 of the vehicle 1r in preparation for the case where a message is issued using an optical signal or a speaker. The message receiving unit VR1 may acquire video captured by an on-board camera and decode a message from the video. The message receiving unit VR1 may acquire the analysis result of the video captured by the on-board camera and extract a message from the analysis result. The message receiving unit VR1 may acquire sound data detected by an acoustic sensor and decode a message from the sound data. The message receiving unit VR1 may acquire the analysis result of the sound data detected by the acoustic sensor and extract a message from the analysis result.

[0096] If the electronic control device 10r also has a trigger propagation function, the message receiving unit VR1 may stop the trigger propagation function when it receives a message requesting the storage of traffic event data. This prevents agents in the vicinity of a traffic event from simultaneously issuing an alert when a traffic event occurs, thereby preventing the communication environment in the vicinity of the traffic event from becoming chaotic.

[0097] Based on the request in the received message, the state change unit VR2 changes the data recording state of the vehicle 1r or the electronic control unit 10r from the normal state to a traffic event trigger-enabled state, in which data related to the traffic event is stored in a storage medium (e.g., the storage 10e) at a higher level than before the message was received.

[0098] Here, storing at a high level may mean changing the data that was not stored before the message was acquired so that it is stored.

[0099] Furthermore, storing at a high level may mean expanding the types of data to be stored. Expanding the types of data may mean increasing the number of types of data to be stored. For example, if only the speed of the vehicle 1r was periodically stored before the message was acquired, in the traffic event trigger response state, the acceleration, heading, and yaw rate of the vehicle 1r may be periodically stored in addition to the speed of the vehicle 1r.

[0100] Furthermore, high-level storage may mean expanding the range of data to be stored. For example, if, before receiving the message, only the image from the front camera capturing the area in front of the vehicle 1r among the images from the multiple onboard cameras of the vehicle 1r is stored, in addition to the image from the front camera, in the traffic event trigger response state, the image from the rear camera capturing the area behind the vehicle 1r may also be stored.

[0101] Furthermore, storing at a high level may mean increasing the level of detail of the stored data. For example, the frame rate (particularly the sampling rate of the stored data) of the dashcam footage stored before the message is acquired may be increased in the event-trigger-enabled state. Also, for example, the resolution of the dashcam footage stored before the message is acquired may be increased in the event-trigger-enabled state.

[0102] The state change unit VR2 also sets a finite period for which the traffic event trigger-enabled state is maintained. This period may have a predetermined fixed length. The fixed length here may be set to, for example, 10 seconds, 30 seconds, 1 minute, or 3 minutes.

[0103] Furthermore, the state change unit VR2 may estimate the degree of association between the traffic event associated with the traffic event trigger and the vehicle 1r, and set a period for maintaining the traffic event trigger-responsive state based on the degree of association. For example, the higher the degree of association, the longer the period may be set, and conversely, the lower the degree of association, the shorter the period may be set. The degree of association may also be estimated based on whether the vehicle 1r is a party involved in the traffic event. For example, if the traffic event is an event that increases the collision risk between the vehicle 1t and the vehicle 1r, the degree of association is determined to be high because the vehicle 1r is a party involved in the traffic event. If the traffic event is an event that increases the collision risk between the vehicle 1t and the pedestrian 6, the degree of association is determined to be low because the vehicle 1r is a third party.

[0104] The traffic event-related data stored in this manner may be transmitted to the server 20 together with vehicle data by, for example, the storage / transmission unit V4 included in the electronic control unit 10r, and collected by the server 20. Here, the data transmitted to the server 20 may include not only data from the period in which the vehicle is in the traffic event trigger-responsive state, but also data from before that period, to the extent that such data has been collected as vehicle data. The data from before the period in which the vehicle is in the traffic event trigger-responsive state may be data from a period (hereinafter referred to as the previous period) preset by the state change unit VR3. For example, the previous period may be a period shorter than the period in which the vehicle is in the traffic event trigger-responsive state, such as 5 seconds or 10 seconds. In this way, traffic event-related data from the time period required for the traffic event trigger to propagate after the start of the traffic event can also be collected to the extent that such data has been recorded. The storage / transmission unit V4 may delete the traffic event-related data that has been transmitted to the server 20 from the storage 10e, similar to the vehicle data.

[0105] On the other hand, the state change unit VT3 executes the same process as the state change unit VR2 in the transmitting electronic control unit 10t. That is, the state change unit VT3 changes the data recording state in the vehicle 1t or the electronic control unit 10t from the normal state to a traffic event trigger-compatible state based on the traffic event trigger generated by the state change unit VT3 itself.

[0106] Next, an example of a processing method by the transmitting electronic control unit 10t will be described using the flowchart of Figure 6. Steps S101 to S108 of this flowchart may be realized by the CPU 10a of the electronic control unit 10t executing a computer program stored in the memory 10c.

[0107] In S101, the event trigger generation unit VT1 determines whether the event trigger condition is met. If Yes, the process proceeds to S102. If No, the process repeats S101 after a predetermined time.

[0108] In S102, the event trigger generation unit VT1 generates a traffic event trigger. In S103 after the processing of S102, the message issuing unit VT2 generates a message requesting the storage of data related to the traffic event, and outputs the message to a device for issuing a message (e.g., DCM 11) via the interface 10b, causing the message to be issued.

[0109] In S104 after the process of S103, the state change unit VT3 changes the data recording state from the normal state to the traffic event trigger compatible state. Furthermore, the state change unit VT3 sets a period for maintaining the traffic event trigger compatible state. The process of S104 may be performed after the process of S102. For example, the process of S104 may be executed with priority over S103, or the processes of S103 and S104 may be executed in parallel by multiple CPUs 10a, etc.

[0110] In S105 after the processing of S104, based on a request from the state change unit VT3, the storage transmission unit V4 stores data related to the traffic event in the storage 10e at a higher level than before the message was acquired. In S106 after the processing of S105, the state change unit VT3 determines whether the period set in S104 for maintaining the traffic event trigger compatible state has elapsed. If the answer is Yes, proceed to S107. If the answer is No, return to S105.

[0111] In S107, the state change unit VT3 ends the traffic event trigger response state and returns to the normal state. The state change unit VT3 notifies the storage transmission unit V4 that the traffic event trigger response state has ended. This stops high-level data storage. In S108 after processing S107, the storage transmission unit V4 causes the DCM 11 to upload data related to the traffic event to the server 20. The series of processes ends with S108.

[0112] Next, an example of a processing method by the receiving electronic control unit 10r will be described using the flowchart of Figure 7. Steps S201 to S206 of this flowchart may be realized by the CPU 10a of the electronic control unit 10r executing a computer program stored in the memory 10c.

[0113] In S201, the message receiving unit VR1 determines whether a message requesting data storage related to a traffic event has been received, for example, in the DCM 11. If the determination is Yes, the process proceeds to S202. If the determination is No, the determination in S201 is executed again after a predetermined time.

[0114] In S202, the state change unit VR2 changes the data recording state from the normal state to the traffic event trigger compatible state. Furthermore, the state change unit VR2 sets the period for maintaining the traffic event trigger compatible state. After processing S202, S203 to S206 are the same as S105 to S108. The series of processes ends with S206.

[0115] Here, an application example of the trigger propagation function and the trigger reception function will be described with reference to FIG. 1. For example, suppose that a preceding vehicle, vehicle 1a, is approached by a motorcycle vehicle 1d traveling in the same lane and is attempting to overtake vehicle 1a within the lane. At this time, an event trigger generation unit VT1 in an electronic control unit 10v mounted on vehicle 1a generates a traffic event trigger due to an increased risk of collision between vehicle 1a and vehicle 1d, and a message is issued using V2X communication. In this case, vehicle 1a becomes vehicle 1t mounted with an electronic control unit 10t that performs the trigger propagation function.

[0116] Vehicles 1b and 1c then become vehicle 1r equipped with electronic control units 10r that perform trigger reception functions. By transitioning to a traffic event trigger-enabled state, vehicles 1b and 1c can detect vehicles 1a and 1d from positions different from vehicle 1a and record their data. Because vehicle 1a is quite close to vehicle 1d, it can be difficult to capture and sense vehicle 1d in its entirety. However, because vehicles 1b and 1c maintain a certain distance from vehicles 1a and 1d, it may be possible to capture and sense the overall situation of the traffic event more objectively. Furthermore, it may be possible to sense areas that are blind spots due to vehicle 1a. In this way, cooperation with passing agents enables the recording and verification of accidental traffic events from multiple perspectives.

[0117] According to the first embodiment described above, a sending agent (host agent from the sending perspective) issues a message to other agents when a traffic event trigger occurs for a traffic event for which multifaceted verification is desired based on the event trigger condition. When other agents in the vicinity of the sending agent receive a message requesting data storage related to the traffic event, they can request data storage from a location other than the sending agent, using a different resource. This increases the possibility of verifying the multifaceted data acquired by multiple agents for a single traffic event.

[0118] Furthermore, according to the first embodiment, a traffic event trigger is generated when at least one of the following events is recognized by the recognition module 12: a collision, a vehicle malfunction, a sudden movement, and a safety envelope violation. In this way, a message is issued by an agent that quickly recognizes a traffic event that requires multifaceted verification, so that multifaceted data storage can be started quickly.

[0119] According to the first embodiment, the message is issued by wirelessly transmitting the message to the DCM 11 as a communication device. Since data is transmitted and received via wireless communication, the traffic event trigger can be propagated accurately and quickly.

[0120] Furthermore, according to the first embodiment, the message is issued by outputting a light signal from the light-emitting device 14 as an output device, outputting a sound signal from the speaker 15 as an output device, etc. By using light or sound, the traffic event trigger can be spread to various agents.

[0121] Furthermore, the electronic control device 10t as a traffic event trigger propagation device is mounted on the vehicle 1. By being referenced integrally with the vehicle 1 as an agent, it becomes possible to utilize the hardware resources of the vehicle 1 to record data.

[0122] Furthermore, according to the first embodiment, the receiving agent (the host agent from the receiving perspective) receives a message generated by the source agent requesting the storage of traffic event data. In response to this, the receiving agent transitions to a traffic event trigger-enabled state. In the traffic event trigger-enabled state, the traffic event data is stored in the storage 10e as a storage medium at a higher level than before the message was received, so the data is stored in a location separate from the source agent and using separate resources. This increases the possibility of verifying the multifaceted data collected by multiple agents for a single traffic event.

[0123] Furthermore, according to the first embodiment, the degree of association between the receiving agent and the traffic event is estimated. Then, a period for maintaining the traffic event trigger response state is set based on the degree of association. By appropriately setting the period in this manner, it is possible to prevent the recording of less necessary data from increasing the amount of data to be stored, which puts a strain on hardware resources, and to prevent excessive noise during verification from reducing the ease of verification.

[0124] Furthermore, according to the data collection system DCS of the first embodiment, a traffic event trigger is propagated from an agent associated with a first device (the transmitting electronic control device 10t) to an agent associated with a second device (the receiving electronic control device 10r), so that data related to the traffic event is stored in a storage medium at a high level in each agent. Furthermore, since the server 20 collects the multifaceted data acquired by multiple agents for one traffic event, it becomes possible to verify the traffic event from multiple angles.

[0125] Second Embodiment As shown in Fig. 8, the second embodiment is a modification of the first embodiment. The second embodiment will be described, focusing on the differences from the first embodiment.

[0126] In the second embodiment, an example in which an agent other than a vehicle performs the trigger issuing function and the trigger receiving function will be described in detail. When the agent is a roadside unit 5 (see also FIG. 1), the electronic control device 50 associated with the agent may be mounted on the roadside unit 5. When the agent is a pedestrian 6 (see also FIG. 1), the electronic control device associated with the agent may be a mobile terminal such as a smartphone 60 carried by the pedestrian 6. When the agent is a bicycle, the electronic control device associated with the agent may be a mobile terminal such as a smartphone carried by the bicycle driver. When the agent is a police officer, the electronic control device associated with the agent may be a dedicated terminal loaned to the police officer by the police organization.

[0127] The roadside unit 5 is installed on the road frame and includes sensors for monitoring the road and road users, a communication device, and an electronic control unit 50 for controlling these. The sensor is, for example, a camera. The electronic control unit 50 is mainly composed of, for example, a computer. The computer constituting the electronic control unit 50 has at least one CPU 50a and one memory 50c. The memory 50c non-temporarily stores computer programs and data that can be read by the CPU 50a. The computer may also be provided with a rewritable volatile storage medium such as a RAM 50d. The CPU 50a can execute various processes in accordance with the computer programs stored in the memory 50c.

[0128] The computer further includes an interface 50b for communicating data with the outside. Thus, the electronic control unit 50 is connected to the electronic control unit 10v associated with various agents, the smartphone 60, or the server 20 via the interface 50b and the communication device so as to be able to communicate wirelessly.

[0129] The electronic control unit 50 also includes a storage 50e for recording data related to traffic events. The storage 50e is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 50e has a storage area with a finite storage capacity.

[0130] The electronic control unit 50 has both a trigger propagation function and a trigger receiving function. That is, the electronic control unit 50 may have the event trigger generation unit VT1, message issuing unit VT2, and state change unit VT3, which are similar to those in the first embodiment, as functional units that realize the trigger propagation function when the CPU 50a executes a computer program stored in the memory 50c. Here, the event trigger generation unit VT1 can acquire sensor data from sensors included in the roadside unit 5 and recognize a traffic event that should generate a traffic event trigger.

[0131] The electronic control device 50 may be equipped with a message receiving unit VR1 and a state change unit VR2 similar to those in the first embodiment, as functional units in which the trigger receiving function is realized by the CPU 50a executing a computer program stored in the memory 50c.

[0132] Furthermore, the electronic control device 50 may include a functional unit similar to the storage / transmission unit V4 of the first embodiment. The stored traffic event-related data may be stored in the storage 50e by a functional unit similar to the storage / transmission unit V4, and may also be transmitted to the server 20 and collected by the server 20. The functional unit similar to the storage / transmission unit V4 may delete the traffic event-related data that has been transmitted to the server 20 from the storage 50e.

[0133] The smartphone 60 carried by the pedestrian 6 is a mobile terminal that includes a computer, a display, a touch panel, a speaker, a communication device, etc., is configured to be easily portable, and is connected to a communication base station so that it can communicate with the Internet. Here, the roadside unit 5 may also function as a communication base station.

[0134] The computer in the smartphone 60 has at least one CPU 60a and one memory 60c. The memory 60c non-temporarily stores computer programs and data that can be read by the CPU 60a. The computer may also be provided with a rewritable volatile storage medium such as a RAM 60d. The CPU 60a can execute various processes in accordance with the computer programs stored in the memory 60c. The computer also includes an interface 60b for communicating data with the outside.

[0135] The smartphone 60 has the trigger propagation function, which is one of the trigger propagation function and the trigger receiving function. That is, the smartphone 60 may have the event trigger generation unit VT1 and the message transmission unit VT2, similar to those in the first embodiment, as functional units in which the trigger propagation function is realized by the CPU 60a executing a computer program stored in the memory 60c. Here, the event trigger condition adopted by the event trigger generation unit VT1 of the smartphone 60 is only that the pedestrian 6 executes an input operation on the touch panel to generate a traffic event trigger. That is, the pedestrian 6 needs to launch an application for transmitting a message and transmit a message requesting data saving. Since it is desirable for the pedestrian 6 to be able to transmit a message immediately when he or she discovers a traffic event that should generate a traffic event trigger, it is preferable for the message to be transmitted by a one-touch operation on the touch panel while the application is running. Alternatively, the message may be transmitted automatically in conjunction with a telephone call by the user of the smartphone 60 to a fire department, police station, or the like (in Japan, calling 119 or 110). Furthermore, the message may be automatically issued in response to a strong impact that generates gravitational acceleration equal to or greater than a preset threshold, as detected by an acceleration sensor included in the smartphone 60. It is preferable that the user of the smartphone 60 can set in advance whether or not to issue such an automatic message.

[0136] Furthermore, in the second embodiment, the vehicle 1 does not need to include a DCM 11 capable of performing V2X communication, but only needs to be connected to a smartphone USF carried by the driver of the vehicle 1 so as to be capable of wireless short-range communication. The wireless short-range communication here may be communication such as Bluetooth (registered trademark) or Wi-Fi (registered trademark). The smartphone USF may have the same hardware configuration as the smartphone 60. When the electronic control unit 10v mounted on the vehicle 1 transmits or receives a message related to a traffic event trigger, the message may be transmitted or received by wireless communication via the smartphone USF.

[0137] According to the second embodiment described above, the electronic control unit 50 that performs the trigger propagation function is installed as road infrastructure. In this way, even if there happens to be no vehicle or the like that can issue a message near the point where a traffic event occurs, the message can be issued from the road infrastructure to prompt vehicles or the like that are planning to approach the point of occurrence to save data.

[0138] According to the second embodiment, the smartphone 60 that performs the trigger propagation function is a portable terminal that can be carried by a user. In this way, even if there happens to be no vehicle or the like that can issue a message near the location where a traffic event occurred, the pedestrian 6 can issue a message to prompt vehicles or the like that are planning to approach the location of the event to save the data.

[0139] 9 and 10, the third embodiment is a modification of the first embodiment. The third embodiment will be described, focusing on the differences from the first embodiment.

[0140] In the third embodiment, a vehicle 1r equipped with an electronic control device 10r is provided with a plurality of on-board cameras 12a-d as a recognition module 12. The plurality of cameras 12a-d includes a camera 12a whose detection range is in front of the vehicle 1r, a camera 12b whose detection range is behind the vehicle 1r, a camera 12c whose detection range is on the left side, and a camera 12d whose detection range is on the right side.

[0141] When the data recording state transitions to the traffic event trigger-enabled state, the state change unit VR2 determines a mode for storing data at a high level. Specifically, the state change unit VR2 identifies the traffic event occurrence point Pev based on the message and information acquired from the recognition module 12. Then, during the traffic event trigger-enabled state, the state change unit VR2 determines to store in the storage 10e, at a high frame rate and high resolution, images from cameras 12a-d whose detection ranges are directed toward the occurrence point Pev.

[0142] 8, for example, the camera whose detection range includes the direction facing the occurrence point Pev is camera 12c, whose detection range is to the left, and therefore the video from camera 12c is saved at a high frame rate and high resolution. The state change unit VR2 may switch the target camera as vehicle 1r moves during the traffic event trigger response state. For example, if vehicle 1r moves forward and the camera whose detection range includes the direction facing the occurrence point Pev becomes camera 12b, whose detection range is to the rear, the video from camera 12c may be saved again at a normal frame rate and resolution, and the video from camera 12d may be saved at a high frame rate and high resolution.

[0143] The state change unit VR2 may associate sensor data such as camera footage with environmental information at the occurrence point Pev and store the associated data in the storage 10e. The environmental information may include information about the weather at the time of the traffic event, information about landmarks located near the occurrence point Pev, and the like. The landmarks may be those that are not captured in the camera footage and are located outside the camera's detection range. This allows for the combination of camera footage and environmental information in subsequent verification of a traffic event.

[0144] Next, an example of a method for determining a mode for storing data at a high level among the processing methods performed by the transmitting electronic control unit 10r will be described using the flowchart of Figure 10. Steps S301 to S304 of this flowchart may be implemented by the CPU 10a of the electronic control unit 10r executing a computer program stored in the memory 10c.

[0145] In S301, the state change unit VR2 determines whether or not the vehicle is in a traffic event trigger compatible state. If the result is Yes, the process proceeds to S301. If the result is No, the process repeats the determination in S301 after a predetermined time has elapsed.

[0146] In S302, the state change unit VR2 identifies the traffic event that caused the current traffic event trigger and its occurrence point Pev. After processing S302, in S303, the state change unit VR2 identifies a sensor whose detection range includes the direction facing the occurrence point Pev. After processing S303, in S304, the state change unit VR2 changes the recording mode of the identified sensor to a higher-level mode (e.g., high-accuracy mode). The series of processes ends with S304.

[0147] According to the third embodiment described above, the occurrence point Pev of a traffic event is identified. Then, among the cameras 12a-d serving as multiple sensors, sensor data (camera images) from a camera whose detection range includes the direction facing the occurrence point Pev is stored at a high level in the storage 10e serving as a storage medium. By selectively storing appropriate information as a record of the traffic event, it is possible to reduce the amount of data to be verified while enabling multifaceted verification.

[0148] According to the third embodiment, environmental information at the point Pev where the traffic event occurred is stored in the storage 10e in association with data related to the traffic event. This makes it easy to understand the environment in which the traffic event occurred during verification, thereby improving the ease of verification.

[0149] (Other Embodiments) Although multiple embodiments have been described above, the present disclosure should not be construed as being limited to those embodiments, and can be applied to various embodiments and combinations within the scope that does not deviate from the gist of the present disclosure.

[0150] In another embodiment, a traffic event trigger may be generated and a message may be sent to another agent in an agent that is a human with official authority related to at least one of land development, traffic safety, and public order maintenance, or in an agent controlled by such a human, based on an operational input by the human. The official with official authority may be, for example, a police officer, a firefighter, a soldier, a civil servant, an administrative official, or a contractor commissioned or approved by the public. For example, if the agent is a police officer and the electronic control device associated with the agent is a dedicated terminal loaned to the police officer by a police organization, a traffic event trigger may be generated and a message may be sent to another agent based on an operational input by the police officer to an operating device of the dedicated terminal.

[0151] In another embodiment, the smartphone 60 of the pedestrian 6 may have a trigger receiving function. Even if the smartphone 60 has a camera, it is difficult to save data related to a traffic event unless the pedestrian 6 intentionally points the camera at the location where the traffic event occurs. However, in a traffic event trigger-enabled state, it is possible to save acceleration data acquired from a gyro sensor included in the smartphone 60, and to save pedestrian position data acquired from a GPS (Global Positioning System) system.

[0152] In another embodiment, in the trigger issuance function, after the message issuance unit VT2 issues a message, the event trigger generation unit VT1 may re-determine, based on more detailed information, whether the traffic event associated with the message truly requires multifaceted data storage. If the re-determination determines that data storage is not necessary, the event trigger generation unit VT1 may cancel the traffic event trigger. Accordingly, the message issuance unit VT2 may issue a message canceling the data storage request to another agent. In another agent, when the message receiving unit VR1 receives a message canceling the data storage request, the state change unit VR2 may immediately cancel the traffic event trigger response state, or may determine a response based on the result of determining the authenticity of the message. If the authenticity cannot be determined, the state change unit VR2 may maintain the traffic event trigger response state.

[0153] In another embodiment, the vehicle 1 may be a right-hand drive vehicle or a left-hand drive vehicle. Furthermore, the traffic environment in which the vehicle 1 travels may be a traffic environment where traffic is assumed to be on the left side of the road, or a traffic environment where traffic is assumed to be on the right side of the road. The vehicle 1 and the server 20 according to the present disclosure may be optimized as appropriate, taking into account the road traffic laws, customs, data (protection) laws, etc. of each country and region.

[0154] In another embodiment, at least one of the computers constituting the electronic control devices 10v, 10t, 10r, 50 and the computers constituting the smartphone 60 may be equipped with another type of processor (e.g., a GPU) instead of or in addition to a CPU.

[0155] In another embodiment, at least one of the computers constituting the electronic control devices 10v, 10t, 10r, and 50 and the computer constituting the smartphone 60 may be a SoC (System on a Chip) that integrates a processor such as a CPU, a memory, an interface, and the like on a single chip, or may have at least one SoC as a component of the computer. Also, a circuit such as an FPGA may be incorporated into part of the above-mentioned SoC, and in this case, the processor may control the circuit.

[0156] Furthermore, at least one of the electronic control devices 10v, 10t, 10r, 50, the server 20, and the development computer 30 may be configured to execute processing by a circuit rather than by a processor such as a CPU.

[0157] In this disclosure or claims, "at least one of the circuit and the processor performs the function of generating a traffic event trigger" includes the case where only the circuit performs that function. Also, "at least one of the circuit and the processor performs the function of generating a traffic event trigger" includes the case where only the processor performs that function. Furthermore, "at least one of the circuit and the processor performs the function of generating a traffic event trigger" includes the case where the circuit performs some of the function and the processor performs the remaining function.

[0158] In this disclosure or claims, "at least one of the circuit and the processor performs the function of issuing a message" includes the case where only the circuit performs that function. Also, "at least one of the circuit and the processor performs the function of issuing a message" includes the case where only the processor performs that function. Furthermore, "at least one of the circuit and the processor performs the function of issuing a message" includes the case where the circuit performs some of the function and the processor performs the remaining function.

[0159] In this disclosure or claims, "at least one of the circuit and the processor performs the function of receiving a message" includes the case where only the circuit performs that function. Also, "at least one of the circuit and the processor performs the function of receiving a message" includes the case where only the processor performs that function. Furthermore, "at least one of the circuit and the processor performs the function of receiving a message" includes the case where the circuit performs some of the function and the processor performs the remaining function.

[0160] In this disclosure or claims, "at least one of the circuit and the processor executes the function of transitioning to a traffic event trigger response state" includes the case where only the circuit executes that function. Also, "at least one of the circuit and the processor executes the function of transitioning to a traffic event trigger response state" includes the case where only the processor executes that function. Furthermore, "at least one of the circuit and the processor executes the function of transitioning to a traffic event trigger response state" includes the case where the circuit executes some of the functions and the processor executes the remaining functions.

[0161] (Disclosure of Technical Ideas) This specification discloses multiple technical ideas described in the following multiple clauses. Some clauses may be described in a multiple dependent form, where the subsequent clause alternatively cites the preceding clause. These multiple dependent clauses define multiple technical ideas.

[0162] <Technical Idea 1> A traffic event trigger spreading device that is associated with a host agent and spreads a traffic event trigger to other agents, the traffic event trigger spreading device comprising: at least one processing unit (10a, 50a, 60a) and a communication interface (10b, 50b, 60b) for communicating with the outside, wherein the at least one processing unit is configured to: generate the traffic event trigger based on an event trigger condition; and, upon the generation of the traffic event trigger, send a message via the communication interface to the other agents present in the vicinity of the traffic event trigger, requesting the storage of data related to the traffic event.

[0163] <Technical Idea 2> A traffic event trigger propagation device according to Technical Idea 1, which is communicatively connected to a recognition module (12) capable of recognizing the traffic event, wherein the at least one processing unit generates the traffic event trigger based on at least one of the following being recognized by the recognition module: an occurrence of a collision; an occurrence of a vehicle malfunction; an occurrence of a sudden movement; and an occurrence of a safety envelope violation.

[0164] <Technical Idea 3> A traffic event trigger spreading device according to Technical Idea 1 or 2, wherein the communication interface is communicatively connected to a communication device (11, USF) configured to be capable of wireless communication with the other agent, and the at least one processing unit, in issuing the alert, includes causing the communication device to transmit the message via the wireless communication.

[0165] <Technical Idea 4> A traffic event trigger spreading device according to any one of Technical Ideas 1 to 3, wherein the communication interface is communicatively connected to an output device (14, 15) capable of outputting at least one of light and sound to the other agent, and the at least one processing unit, in issuing the alert, includes outputting the message to the output device.

[0166] <Technical Concept 5> A traffic event trigger propagation device according to any one of Technical Concepts 1 to 4, which is mounted on a vehicle (1).

[0167] <Technical Concept 6> A traffic event trigger propagation device according to any one of Technical Concepts 1 to 4, which is installed as road infrastructure.

[0168] <Technical Concept 7> The traffic event trigger spreading device according to any one of Technical Concepts 1 to 4, which is a mobile terminal (60) that can be carried by a user.

[0169] <Technical Idea 8> A traffic event trigger receiving device associated with a host agent and receiving a message generated by a source agent to spread a traffic event trigger, the traffic event trigger receiving device comprising: at least one processing unit (10a, 50a); and a communication interface (10b, 50b) for communicating with the outside, wherein the at least one processing unit is configured to: acquire, via the communication interface, the message requesting storage of data related to a traffic event; and transition to a traffic event trigger compatible state in which the data related to the traffic event is stored in a storage medium (10e, 50e) at a higher level than before the message was acquired.

[0170] <Technical Idea 9> A traffic event trigger receiving device according to Technical Idea 8, wherein the at least one processing unit is configured to: estimate a degree of relevance of the host agent to the traffic event; and set a period for maintaining the traffic event trigger compatible state based on the degree of relevance.

[0171] <Technical Idea 10> A traffic event trigger receiving device according to Technical Idea 8 or 9, which is communicatively connected to a plurality of sensors (12a-d) having detection ranges in different directions, wherein the at least one processing unit is further configured to identify the point of occurrence (Pev) of the traffic event, and in the transition, the traffic event trigger receiving device transitions to a state in which sensor data of a sensor of the plurality of sensors whose detection range includes a direction facing the point of occurrence is stored in the storage medium at the high level.

[0172] <Technical Idea 11> The traffic event trigger receiving device according to any one of Technical Ideas 8 to 10, further configured to store environmental information at a location where the traffic event occurs in the storage medium in association with data related to the traffic event.

Claims

1. A traffic event trigger spreading device associated with a host agent that spreads a traffic event trigger to other agents, comprising at least one processing unit (10a, 50a, 60a) and a communication interface (10b, 50b, 60b) for communicating with the outside, wherein the at least one processing unit is configured to: generate the traffic event trigger based on an event trigger condition; and, upon the generation of the traffic event trigger, send a message via the communication interface to the other agents in the vicinity of the traffic event trigger, requesting that data related to the traffic event be saved.

2. A traffic event trigger propagation device according to claim 1, which is communicatively connected to a recognition module (12) capable of recognizing the traffic event, wherein the at least one processing unit generates the traffic event trigger based on at least one of the following being recognized by the recognition module: a collision has occurred, a vehicle malfunction has occurred, a sudden movement has occurred, and a safety envelope violation has occurred.

3. A traffic event trigger propagation device as described in claim 1, wherein the communication interface is communicatively connected to a communication device (11, USF) configured to be capable of wireless communication with the other agent, and wherein the at least one processing unit, in issuing the alert, includes causing the communication device to transmit the message via the wireless communication.

4. A traffic event trigger propagation device as described in claim 1, wherein the communication interface is communicatively connected to an output device (14, 15) capable of outputting at least one of light and sound to the other agent, and wherein the at least one processing unit, in issuing the alert, includes outputting the message to the output device.

5. A traffic event trigger propagation device according to claim 1, mounted on a vehicle (1).

6. The traffic event trigger propagation device according to claim 1, which is installed as road infrastructure.

7. The traffic event trigger propagation device according to claim 1, which is a mobile terminal (60) that can be carried by a user.

8. A traffic event trigger receiving device associated with a host agent and configured to receive a message generated by a source agent to propagate a traffic event trigger, the traffic event trigger receiving device comprising at least one processing unit (10a, 50a) and a communication interface (10b, 50b) for communicating with the outside, wherein the at least one processing unit is configured to: acquire the message requesting storage of data related to a traffic event through the communication interface; and transition to a traffic event trigger compatible state in which the data related to the traffic event is stored in a storage medium (10e, 50e) at a higher level than before the message was acquired.

9. A traffic event trigger receiving device according to claim 8, wherein the at least one processing unit is configured to: estimate a degree of association of the host agent with the traffic event; and set a period for maintaining the traffic event trigger compatible state based on the degree of association.

10. A traffic event trigger receiving device as described in claim 8, which is communicatively connected to a plurality of sensors (12a-d) having detection ranges in different directions, wherein the at least one processing unit is further configured to identify the point of occurrence (Pev) of the traffic event, and in the transition, the traffic event trigger receiving device transitions to a state in which sensor data of a sensor among the plurality of sensors whose detection range includes the direction facing the occurrence point is stored in the storage medium at the high level.

11. A traffic event trigger receiving device according to claim 8, further configured to link environmental information at the location where the traffic event occurs to data relating to the traffic event and store the information in the storage medium.

12. A traffic event data collection system (DCS) for collecting data related to traffic events, comprising: a first device associated with an agent and configured to propagate a traffic event trigger; one or more second devices associated with one or more other agents and configured to be able to receive messages generated by the first device; and a server (20) wirelessly connected to the first device and the second device, wherein the first device is configured to: generate the traffic event trigger based on an event trigger condition; transition to a traffic event trigger response state in which data related to the traffic event is stored in a storage medium (10e, 50e) at a level higher than before the traffic event trigger was generated; issue the message requesting storage of data related to the traffic event to the other agents present in the vicinity of the first device upon the generation of the traffic event trigger; and transmit the data related to the traffic event stored in the traffic event trigger response state to the server; and the second device is configured to: receive the message requesting storage of data related to the traffic event; transitioning to a traffic event trigger ready state in which data relating to the traffic event is stored in a storage medium (10e, 50e) at a higher level than before the message was acquired; and transmitting the data relating to the traffic event stored in the traffic event trigger ready state to the server.

Images