Onboard device and program

Abstract

A data management device (10) serving as an onboard device is mounted in a vehicle (1) that can participate in public road traffic, the data management device (10) comprising at least one processor (10b). The at least one processor (10b) is configured to detect an abnormality of the vehicle (1) by using a data collection function for collecting vehicle data in a server (20) outside the vehicle, and determine an abnormality notification mode corresponding to the influence of the abnormality on the driver of the vehicle (1).

Description

In-vehicle device and program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Patent Application No. 2024-93096 filed in Japan on June 7, 2024, the contents of which are incorporated by reference in their entirety.

[0002] TECHNICAL FIELD The disclosure herein relates to techniques for collecting data from vehicles that may participate in public road traffic.

[0003] Patent Literature 1 discloses that a computing device in a server collects vehicle data from vehicles that can participate in public road traffic in accordance with a data collection policy included in the computing device, and then generates an autonomous driving model based on the collected data.

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

[0005] There is a demand for the above-mentioned vehicle data collection system to realize useful functions.

[0006] One of the objectives of this disclosure is to provide useful functionality in vehicle data collection systems.

[0007] One aspect disclosed herein is an on-board device that is mounted on a vehicle capable of participating in public road traffic and has at least one processor, wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data on a server outside the vehicle; and determine a notification mode for the abnormality depending on the impact that the abnormality will have on the driver of the vehicle.

[0008] Another aspect disclosed herein is a program used in an on-board device mounted on a vehicle capable of participating in public road traffic, which causes at least one processor to: detect an abnormality in the vehicle using a data collection function that collects vehicle data on a server outside the vehicle; and determine a notification mode for the abnormality depending on the impact that the abnormality will have on the driver of the vehicle.

[0009] According to this aspect, a vehicle abnormality is notified in a manner appropriate to the impact on the driver of the vehicle. By notifying the driver of the abnormality in an appropriate manner, the notified person who recognizes the notification can take appropriate action against the abnormality. Furthermore, since this abnormality detection is realized by utilizing the data collection function, a useful function can be provided in the vehicle data collection system.

[0010] Another disclosed aspect is an on-board device that is mounted on a vehicle capable of participating in public road traffic and has at least one processor, wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data on a server outside the vehicle; and determine a notification mode for the abnormality depending on whether the abnormality is a hardware abnormality or a software abnormality.

[0011] According to this aspect, a vehicle abnormality is notified in a manner that corresponds to whether it is a hardware abnormality or a software abnormality. By notifying the abnormality in a manner that corresponds to the type of abnormality, the notified party who recognizes the notification can take appropriate action against the abnormality. Furthermore, since this abnormality detection is realized by utilizing the data collection function, a useful function can be provided in the vehicle data collection system.

[0012] 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.

[0013] A diagram schematically showing the hardware configuration of a vehicle data collection system. A diagram schematically showing the functional configuration of a vehicle data collection system. A flowchart illustrating processing related to a data collection function. A diagram schematically showing the functional configuration of a system that detects and notifies an abnormality. A flowchart illustrating processing for detecting and notifying an abnormality. A flowchart illustrating processing for detecting and notifying an abnormality.

[0014] 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.

[0015] (First Embodiment) A vehicle data collection system DCS of a first embodiment shown in Fig. 1 collects data from a vehicle 1. The collected data is used, for example, to develop the hardware of the vehicle 1 or applications used in the vehicle 1. The collected data may be used for urban planning, such as improving traffic signal control and road infrastructure. The collected data may also be used for planning the opening of commercial facilities, etc.

[0016] Vehicle 1 is a vehicle capable of participating in public road traffic. Vehicle 1 may be, for example, a four-wheeled automobile, truck, or other vehicle that can be manually driven by a driver. Vehicle 1 may also be capable of automated driving. The automation level of vehicle 1 is classified into levels 1 to 5, for example, as defined in SAE J3016. Vehicle 1 may be capable of driving at any of these levels.

[0017] 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.

[0018] The vehicle data collection system DCS includes a data management device 10 and a server 20. The vehicle data collection system DCS may further include a development computer 30. Although the following description focuses on one vehicle 1 and its data management device 10, the vehicle data collection system DCS may also be configured to collect data from multiple vehicles 1. In other words, the vehicle data collection system DCS may include multiple data management devices 10 that individually correspond to each vehicle 1.

[0019] The vehicle data collection system DCS is suitable for collecting vehicle data in 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 vehicle data in long-tail cases can improve the coverage of applications and their functions in real environments.

[0020] The data management device 10 is an in-vehicle device that is installed in the vehicle 1 and manages vehicle data. The data management device 10 acquires vehicle data from the vehicle 1 and executes processing for transferring the vehicle data to the server 20.

[0021] The data management device 10 may be, for example, an ECU (Electronic Control Unit) primarily composed of a computer. The computer constituting the data management device 10 has at least one memory 10a and one processor 10b. The memory 10a may be at least one type of non-transient physical storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 10b. Furthermore, the memory 10a may be provided with a rewritable volatile storage medium, such as a RAM (Random Access Memory). The processor 10b may include at least one type of core, such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a RISC (Reduced Instruction Set Computer)-CPU. Furthermore, the computer includes an interface 10c for exchanging data with the outside.

[0022] The computer constituting the data management device 10 may be a SoC (System on a Chip) that integrates the memory 10a, processor 10b, and interface 10c into a single chip, or may have at least one SoC as a component of the computer.

[0023] The data management device 10 also includes a storage 10d for recording data of the vehicle 1 (hereinafter referred to as vehicle data). The storage 10d is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 10d has a storage area with a finite storage capacity.

[0024] The vehicle data is data generated by the vehicle 1. 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 failure and an abnormality in the vehicle 1.

[0025] 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 processor 10b in the data management device 10 executing a computer program stored in the memory 10a.

[0026] The application may be operated by the processor 13b executing a computer program stored in the memory 13a in an idle resource 13 other than the data management device 10. The application may be operated by the processor 14b executing a computer program stored in the memory 14a in an operating resource 14 other than the data management device 10.

[0027] The operating resource 14 is a hardware resource that is installed in the vehicle 1 and is in an operating state to realize the functions of the vehicle 1. The operating resource 14 may be, for example, an ECU that is mainly configured with a computer.

[0028] The computer constituting the idle resource 13 has at least one memory 13a and one processor 13b. The memory 13a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 13b. Furthermore, the memory 13a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 13b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU. Furthermore, the computer includes an interface 13c for exchanging data with the outside.

[0029] The computer constituting the idle resource 13 may be a SoC (System on a Chip) in which the memory 13a, processor 13b, and interface 13c are integrated into a single chip, or may have at least one SoC as a component of the computer. Also, if one ECU is equipped with multiple SoCs and some of the SoCs are idle, only some of the ECUs may correspond to the idle resource 13.

[0030] The idle resource 13 is a hardware resource that is installed in the vehicle 1 and is idle and not in operation. The idle resource 13 may be, for example, an ECU that is mainly composed of a computer.

[0031] The computer constituting the operating resource 14 has at least one memory 14a and one processor 14b. The memory 14a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 14b. Furthermore, the memory 14a may be a rewritable volatile storage medium, such as a random access memory (RAM). The processor 14b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU. Furthermore, the computer includes an interface 14c for exchanging data with the outside.

[0032] The computer constituting the operating resource 14 may be a SoC (System on a Chip) that integrates the memory 14a, processor 14b, and interface 14c into a single chip, or may have at least one SoC as a component of the computer.

[0033] In vehicle 1, idle resources 13 and working resources 14 may be interchanged depending on their status. For example, an autonomous driving ECU that realizes an autonomous driving function of level 3 or higher may be an idle resource 13 when the autonomous driving function is disabled in vehicle 1, but may change to a working resource 14 when the autonomous driving function is enabled by the driver. Furthermore, if idle resources 13 are redundant and configured to be used only in emergencies, the idle resources 13 may be idle under normal circumstances but may become working in an emergency and change to a working resource 14.

[0034] The data management device 10 is configured to transmit the vehicle data stored in the storage 10d 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 data management device 10 to transmit the vehicle data to the server 20.

[0035] The server 20 is installed in an external environment relative to the vehicle 1. The server 20 is configured to be able to collect the vehicle data generated by the data management device 10 by being connected to, for example, the Internet.

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

[0037] The processing device of the server 20 is primarily composed of a computer. The computer constituting the processing device has at least one memory 20a and one processor 20b. The memory 20a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 20b. Furthermore, the memory 20a may be provided with a rewritable volatile storage medium, such as a random access memory (RAM). The processor 20b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU. Furthermore, the computer includes an interface 20c for exchanging data with the outside world, and storage 20d.

[0038] The storage 20d is a rewritable non-volatile storage medium such as a semiconductor memory, a magnetic medium, or an optical medium. The storage 20d has a limited storage area with a much larger storage capacity than the storage 20d of the data management device 10. The server 20 stores the vehicle data collected from the vehicle 1 in the storage 20d.

[0039] The development computer 30 is a development device provided in the external environment of the vehicle 1. The development computer 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.

[0040] The development computer 30 has at least one memory 30a and one processor 30b. The memory 30a may be at least one type of non-transient tangible storage medium, such as a semiconductor memory, a magnetic medium, or an optical medium, that non-temporarily stores computer programs and data that can be read by the processor 30b. Furthermore, the memory 10a may be a rewritable volatile storage medium, such as a random access memory (RAM). The processor 10b may include at least one type of core, such as a central processing unit (CPU), a graphics processing unit (GPU), or a reduced instruction set computer (RISC)-CPU.

[0041] Furthermore, development computer 30 includes interface 30c for exchanging data with the outside. Interface 30c 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.

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

[0043] The data management device 10 may include a trigger management unit V1 and a storage and transmission unit V4 as processing units realized by the processor 10b executing a computer program stored in the memory 10a. Of the data management device 10, the idle resource 13, and the operating resource 14, the device that is the main operating entity of the application may include at least one of a current application control unit V2 and a development application control unit V3 as processing units realized by the processor 10b, 13b, or 14b executing a computer program stored in the memory 10a, 13a, or 14a.

[0044] The server 20 may include a development application distribution unit C1, an instruction setting unit C2, and a data collection unit C3 as processing units realized by the processor 20b executing a computer program stored in the memory 20a.

[0045] The development computer 30 may include a scene extraction unit D1, a labeling unit D2, a machine learning unit D3, a verification unit D4, and an upload unit D5 as processing units realized by the processor 30b executing a computer program stored in the memory 30a.

[0046] Each processing 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 vehicle 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 trigger condition that serves as a trigger for recording and transmitting the vehicle data. The trigger condition may be the condition specified by the acquisition instruction information (hereinafter referred to as the instruction condition), or may be a changed condition that has been changed by a review process of the instruction condition.

[0047] While the vehicle 1 is in use, the trigger management unit V1 successively determines whether the trigger condition is currently satisfied. As a result, if the state transitions from a state in which the trigger condition is not satisfied to a state in which the 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 vehicle data. As a result, if the state transitions from a state in which the trigger condition is satisfied to a state in which the 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 vehicle data. Note that the 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.

[0048] 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.

[0049] The current application control unit V2 also receives a request to record vehicle data from the trigger management unit V1. If a recording request has been received, the current application control unit V2 acquires the vehicle 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.

[0050] 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.

[0051] 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.

[0052] Shadow mode is a mode in which a development application runs in parallel with the current application behind the scenes, for example, when autonomous driving is in operation. Shadow mode runs the development application so that vehicle 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.

[0053] 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.

[0054] 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 reflected in the actuators and HMI (Human Machine Interface) of the vehicle 1.

[0055] The HMI of the vehicle 1 may be, for example, an information notification device 12 that notifies information to an occupant such as a driver inside the vehicle, or may be an operation device that allows the driver to operate the vehicle 1. The information notification device 12 may be a meter display, a center information display, a head-up display, or the like.

[0056] 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 using the information notification device 12.

[0057] 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.

[0058] The storage and transmission unit V4 sequentially records the requested vehicle data in the storage 10d 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.

[0059] Before recording data to the storage 10d, the storage transmission unit V4 checks the remaining storage capacity of the storage 10d (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 10d in order to record the requested vehicle data.

[0060] Furthermore, the storage transmission unit V4 transmits the data recorded in the storage 10d 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 10d.

[0061] 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 20d 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 20d.

[0062] Furthermore, in response to a download request from development computer 30, data collection unit C3 transmits vehicle data stored in storage 20d 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 20d.

[0063] 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 30c, etc. The scenes here may be replaced with scenarios represented by a sequence of scenes that define a situation at a given moment.

[0064] 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.

[0065] 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 involve optimizing a model used in the development application and configured mainly using a neural network or the like, using the vehicle data. The development application can be further improved by the machine learning unit D3.

[0066] 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 an autonomous verification without the involvement of the developer, in which a conclusion is reached as to whether the developed application has any defects through the processing of a verification program stored in memory 30a. The verification here may involve outputting verification data required for the developer to perform the verification through the processing of the verification program stored in memory 30a.

[0067] 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.

[0068] The upload unit D5 uploads the development application created by the developer to the server 20. The upload unit D5 may further 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 further 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.

[0069] The data collection plan may be set by the developer through input operations into the interface 30c, or may be generated by the upload unit D5.

[0070] 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.

[0071] 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.

[0072] Next, an example of a processing method for implementing the data collection function using the vehicle data collection system DCS will be described using the flowchart in Figure 3. Steps S1 to S8 in this flowchart outline the overall processing flow for the data collection function. The series of steps S1 to S8 may be implemented, for example, by the processors 10b, 20b, and 30b of the data management device 10, server 20, and development computer 30 executing computer programs stored in memories 10a, 20a, and 30a.

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

[0074] 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.

[0075] In S4 after processing S3, the data management device 10 in each vehicle 1 sets a 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 data management device 10 acquires and records vehicle data based on the trigger condition. In S6 after processing S5, the data management device 10 uploads the vehicle data to the server 20.

[0076] 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.

[0077] Next, the abnormality detection function of the data management device 10, which uses the data collection function to detect and notify an abnormality in the vehicle 1, will be described in detail with reference to FIG.

[0078] The data management device 10 may include an abnormality detection unit V5 and a notification mode determination unit V6 as processing units realized by the processor 10b executing a computer program stored in the memory 10a. The abnormality detection unit V5 uses a data collection function to detect abnormalities in the vehicle 1. The abnormalities here include hardware abnormalities and software abnormalities.

[0079] A hardware abnormality is, for example, an abnormality in the idle resource 13 that is attempting to run a development application. A hardware abnormality may include a failure of the processor 13b, memory 13a, etc. due to a physical impact on the vehicle 1. A hardware abnormality may include a failure of the processor 13b, memory 13a, etc. due to a rise in temperature caused by driving the vehicle 1 in the hot sun or dust accumulation. A hardware abnormality may also be a failure to recognize a component due to poor contact or breakage in wiring, etc.

[0080] The idle resources 13 may remain unused for a long period of time, and are more likely to be left undetected with a hardware abnormality than the operating resources 14. Therefore, the abnormality detection unit V5 checks for hardware abnormalities in the idle resources 13 by taking advantage of the fact that the idle resources 13 are utilized in the data collection function.

[0081] Specifically, if installation of the developed application into the idle resource 13 fails, the abnormality detection unit V5 may analyze the cause and detect a hardware abnormality. If an unexpected abnormality occurs during operation of the developed application, the abnormality detection unit V5 may analyze the cause and detect a hardware abnormality.

[0082] The software abnormality may be a so-called bug such as a syntax error or a runtime error in a computer program used in the process of acquiring, recording, and transmitting vehicle data to the server 20. When any of the acquisition, recording, and transmission of vehicle data fails, the abnormality detection unit V5 may analyze the cause and detect a software abnormality.

[0083] A hardware abnormality in the DCM 11 may also be a possible cause of an abnormality during transmission to the server 20. However, the DCM 11 is a module that is used for general purposes, including other communications in the vehicle 1. Therefore, the abnormality may be detected by the abnormality detection unit V5 of the data management device 10, or may be detected by other means.

[0084] Furthermore, the abnormality detection unit V5 may detect that a special mode such as shadow mode or ghost mode cannot be executed normally, and analyze the cause. When a special mode cannot be executed normally, there is a possibility that the cause is a hardware abnormality or a software abnormality.

[0085] Possible causes for a special mode not being able to be executed normally include a hardware abnormality in the idle resource 13, a software abnormality in the development application, an abnormality in the instruction conditions for acquiring vehicle data, or a software abnormality related to the process of executing the special mode.

[0086] A hardware abnormality of the idle resource 13 can be detected by triggering an installation failure on the idle resource 13 as described above or an abnormality during operation of an application using the idle resource 13. A software abnormality of a development application is a bug in the computer program of the development application, and can be detected by triggering an abnormality during operation of the development application.

[0087] An abnormality in the instruction conditions for acquiring vehicle data is a data abnormality, and a software abnormality in a broad sense. The abnormality in the instruction conditions may be an abnormality in the acquisition instruction information itself generated by the server 20, or may be an abnormality in the instruction conditions for starting the acquisition of vehicle data generated by the trigger management unit V1 based on appropriate acquisition instruction information. A software abnormality related to the process of executing a special mode is a bug in the computer program related to the process for operating the developed application in a special mode for collecting vehicle data.

[0088] The abnormality detection unit V5 provides the abnormality detection result to the notification mode determination unit V6. The notification mode determination unit V6 acquires the abnormality detection result by the abnormality detection unit V5 and determines the notification mode of the abnormality. Determining the notification mode includes determining the notification target and the notification level. In determining the notification target, the notification mode determination unit V6 determines whether the notification target should be the inside of the vehicle or the outside of the vehicle. The notification to the inside of the vehicle may be intended to be a notification to the driver of the vehicle 1 using the information notification device 12. The notification to the outside of the vehicle may be a notification to the development computer 30 intended to notify the developer. The notification to the outside of the vehicle may be realized by sending a message using the DCM 11.

[0089] The notification level indicates the degree of notification (for example, the strength of the notification, the level of detail of the notification). In determining the notification level, the notification mode determination unit V6 determines whether the notification level should be a caution level or a warning level. The caution level is a level at which the notification target is recommended to take action in response to an abnormality, or a level at which information is shared with the notification target. The warning level is a level at which the notification target is required to take necessary action in response to an abnormality.

[0090] The notification mode determination unit V6 determines the notification mode of the abnormality according to the impact that the abnormality acquired as a detection result will have on the driver. This determination may be made by predicting the impact that the abnormality will have on the driver and determining whether the impact level, which is expressed numerically, is greater than a preset threshold. This determination may be made based on a result of linking the abnormality with the notification mode, which is preset based on the impact that the abnormality will have on the driver.

[0091] In detail, if a hardware abnormality of the idle resource 13 is left unaddressed, there is a possibility that the vehicle 1 will not function normally when the need arises to use the hardware. Therefore, a hardware abnormality is a type of abnormality that substantially affects the driver. Therefore, when the detected abnormality is a hardware abnormality of the idle resource 13, the notification mode determination unit V6 sets the driver in the vehicle as the notification target.

[0092] On the other hand, even if a hardware abnormality in the DCM 11 is left unattended, it has little effect on the driver's driving itself. Therefore, when the detected abnormality is a hardware abnormality in the DCM 11, the notification mode determination unit V6 determines whether or not to notify the driver in the vehicle according to the notification level. For example, when the notification level is a warning level, the driver in the vehicle is notified, and when the notification level is a caution level, the driver in the vehicle is excluded from the notification targets.

[0093] The notification mode determination unit V6 may determine whether to notify a developer outside the vehicle about a hardware abnormality, regardless of whether the driver inside the vehicle is the notification target.

[0094] On the other hand, software abnormalities related to at least one of the data collection function and the special mode only affect processes executed behind the scenes. Therefore, these software abnormalities are classified as abnormalities that do not substantially affect the driver. Furthermore, since these software abnormalities can be resolved by updating computer programs using over-the-air (OTA) technology, the abnormality should be notified to the developer. Furthermore, when the notified abnormality is a software abnormality, the notification mode determination unit V6 notifies developers outside the vehicle.

[0095] Furthermore, the notification mode determination unit V6 determines the notification level according to the degree of abnormality. For example, if it is determined that the memory 13a of the idle resource 13 cannot be recognized at all, the notification level is set to the warning level. If it is determined that a portion of the memory area of ​​the memory 13a of the idle resource 13 is damaged (for example, 5% or less of the RAM area is damaged) and it is determined that the degree of damage is such that the idle resource 13 can still perform the functions assumed in its design, the notification level is set to the caution level.

[0096] Furthermore, the notification mode determination unit V6 determines the content of the notification (hereinafter, notification content) based on the abnormality type, the determined notification target, and the notification level. The notification content may be determined, for example, as shown in Table 1 below. For example, data showing the correspondence in Table 1 may be stored in advance in the memory 10a, and the notification mode determination unit V6 may determine the notification content by referring to the data.

[0097] Here, the situation includes at least one of the location where the abnormality occurred, the type of abnormality, and the specific content of the abnormality. The content of the restriction is the specific content of the function restriction that is notified when the occurrence of an abnormality causes a restriction on the function used by the driver. The restriction here may be equivalent to so-called degeneration in driving, such as a speed limit or an acceleration limit in an autonomous driving function of level 3 or higher.

[0098] The recommended action (to the driver) indicates an action recommended to the driver to deal with the abnormality. For example, the recommended action may be to perform at least one of inspection, maintenance, and repair of the hardware or software that is the target of the abnormality in the vehicle 1. For example, the recommended action may be an operation that should be avoided until the abnormality is resolved.

[0099] The required action (of the driver) indicates an action that the driver needs to take to deal with the abnormality. For example, the required action may be to stop driving the vehicle 1. The required action may be to arrange for a towing service.

[0100] The recommended action (to the developer) may be to check the computer program in the case of a software anomaly. The recommended action (to the developer) may be to modify the computer program to eliminate the bug in the case of a software anomaly.

[0101] The action required (for the developer) may be to correct the computer program and eliminate the bug in the case of a software abnormality. The action required (for the developer) may be to consider a recall response for the vehicle 1.

[0102] 5, an example of a processing method for detecting and notifying an abnormality in the vehicle 1 using the data collection function will be described. The series of processes in S101 to S106 may be realized, for example, by the processor 10b of the data management device 10 executing a computer program stored in the memory 10a.

[0103] In S101, processing related to the data collection function is executed in the vehicle 1. In S102 after processing S101, the abnormality detection unit V5 in the data management device 10 analyzes processing related to the data collection function in the vehicle 1 and detects an abnormality in the vehicle 1. The detection of an abnormality here includes identifying the hardware or software that is the target of the abnormality and identifying the type of abnormality. In S103 after processing S102, the abnormality detection unit V5 determines whether an abnormality has occurred. If Yes, proceed to S104. If No, the series of processes ends.

[0104] In S104, the notification mode determination unit V6 determines the notification target and notification level of the abnormality based on the information identified in S102. In S105 after processing of S104, the notification mode determination unit V6 determines notification content based on the notification target and notification level determined in S104. If there are multiple notification targets, the notification content may be different between the notification targets.

[0105] In S106 after processing S105, the notification mode determination unit V6 outputs a request to notify the notification target determined in S104 of the notification content determined in S105. Specifically, if the driver inside the vehicle is the notification target, the notification mode determination unit V6 requests the information notification device 12 to notify the driver or other passengers of the notification content. If the developer outside the vehicle is the notification target, the notification mode determination unit V6 requests the DCM 11 to send the notification content to the development computer 30. The series of processes ends with S106.

[0106] According to the first embodiment described above, an abnormality in the vehicle 1 is notified in a manner appropriate for the impact it will have on the driver of the vehicle 1. By notifying the driver of the abnormality in an appropriate manner, the notified person who recognizes the notification can take appropriate action against the abnormality. Furthermore, since this abnormality detection is realized by utilizing the data collection function, a useful function can be provided in the vehicle data collection mechanism.

[0107] Furthermore, according to the first embodiment, an abnormality in the vehicle 1 is notified in a manner that corresponds to whether it is a hardware abnormality or a software abnormality. By notifying the abnormality in a manner that corresponds to the type of abnormality, the notified party who recognizes the notification can take appropriate action against the abnormality. Furthermore, since this abnormality detection is realized by utilizing the data collection function, a useful function can be provided in the vehicle data collection mechanism.

[0108] Furthermore, according to the first embodiment, when it is determined that an abnormality will affect the driver, the driver is notified of the abnormality through the information notification device 12 of the vehicle 1. This allows the driver to deal with the effect on themselves, thereby providing a useful function.

[0109] Furthermore, according to the first embodiment, when it is determined that the abnormality will not affect the driver, the abnormality is notified to the outside of the vehicle through the DCM 11, which is a communication module of the vehicle 1. When the abnormality will not directly affect the driver, the burden on the driver at the scene can be reduced by responding to the abnormality from outside the vehicle.

[0110] Furthermore, according to the first embodiment, when an abnormality occurs in the idle resource 13, which is an idle hardware resource of the vehicle 1, the abnormality is notified to the driver of the vehicle 1 via the information notification device 12 of the vehicle 1. This allows the driver to voluntarily refrain from enabling a function that uses the idle resource 13, or to consider repairing the idle resource 13.

[0111] Furthermore, according to the first embodiment, the data collection function is executed in the vehicle 1 by operating an application under development in a special mode in which reflection of the application in the actual vehicle control function is prohibited. If an abnormality is a software abnormality that is a process for operating the application in the special mode, the abnormality is notified to the outside of the vehicle through the DCM 11, which serves as a communication module of the vehicle 1. By resolving the software abnormality from outside the vehicle using OTA technology or the like, it becomes possible to execute the data collection function normally.

[0112] Furthermore, according to the first embodiment, an application is installed on the idle resource 13, which is an idle hardware resource of the vehicle 1, and the application is operated. Then, vehicle data related to the operation of the application is acquired and transmitted to the server 20. In this configuration, an abnormality in the idle resource 13 is detected by analyzing at least one of the installation, operation, and vehicle data. By detecting an abnormality in the idle resource 13 using the data collection function, it becomes possible to address the abnormality before the idle resource 13 is activated for use in an actual vehicle control function.

[0113] Furthermore, according to the first embodiment, the abnormality notification mode includes a notification target, a notification level indicating the degree of notification for the notification target, and notification content determined according to the notification target and the notification level. By optimizing these, the abnormality notification becomes an even more useful function.

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

[0115] In the second embodiment, when an abnormality occurs, the notification mode determination unit V6 determines whether the abnormality has been detected and notified in a process of detecting and notifying an abnormality in the vehicle 1 previously or previously. If the abnormality has not been notified, the notification mode determination unit V6 may determine the notification target and notification level for the first notification in the same manner as in the first embodiment. If the abnormality has already been notified, notifying the same content as in a previous notification is less effective, so the notification mode determination unit V6 selects a notification target or notification level different from those in the previous notification.

[0116] Furthermore, the notification mode determination unit V6 determines whether the developer can detect the current abnormality based on the vehicle data collected by the data collection function used for abnormality detection. If the abnormality can be detected, the developer can take action without being notified of the recommended actions and the actions required by the developer. For this reason, the notification mode determination unit V6 may decide to exclude the recommended actions and the actions required by the developer from the notification content for the developer.

[0117] Furthermore, the notification mode determination unit V6 determines whether the vehicle 1 is capable of providing detailed information about the abnormality. Detailed information about the abnormality is more detailed information than whether the abnormality has occurred, such as information about the cause of the abnormality and information about the impact of the abnormality on the driver. If the detailed information cannot be provided, for example, if there is a privacy issue. If the detailed information cannot be provided, even if the developer is notified of the measures to be taken, there is a high possibility that the developer will not be able to intervene in the measures. For this reason, the notification mode determination unit V6 may decide to exclude measures recommended to the developer and measures required by the developer from the notification content for the developer.

[0118] 6, an example of a processing method for detecting and notifying an abnormality in the vehicle 1 using the data collection function will be described. The series of processes in S201 to S210 may be realized, for example, by the processor 10b of the data management device 10 executing a computer program stored in the memory 10a.

[0119] S201 to S203 are the same as S101 to S103 in Fig. 5. If the answer is No in S203, the series of processes ends. If the answer is Yes in S203, the process proceeds to S204.

[0120] In S204, the notification mode determination unit V6 determines whether the abnormality detected in S202 has been detected and notified in the process of detecting and notifying an abnormality in the vehicle 1 at a previous time or earlier. If the determination is Yes, the process proceeds to S205. If the determination is No, the process proceeds to S207.

[0121] In S205, the notification mode determination unit V6 determines the notification target and notification level of the abnormality for the current notification based on the information identified in S202. However, the notification target or notification level is changed from that of the previous notification. For example, if the developer was the notification target in the previous notification but the driver was not the notification target, the notification mode determination unit V6 will newly set the driver as the notification target for the current notification.

[0122] In S206 after processing S205, the notification mode determination unit V6 determines notification content based on the notification target and notification level determined in S204, without excluding recommended and required actions for the developer. For example, the notification mode determination unit V6 determines notification content based on Table 1 of the first embodiment. After processing S206, the process proceeds to S211.

[0123] If the result of S204 is No, in S207, the notification mode determination unit V6 determines the notification target and notification level of the abnormality for this notification based on the information specified in S202. Since this is the first notification, the notification mode determination unit V6 may determine the notification target and notification level in the same way as in the first embodiment, for example.

[0124] In S208 after processing S207, the notification mode determination unit V6 determines whether the developer can discover the current abnormality based on the vehicle data. If Yes, proceed to S210. If No, proceed to S209. In S209, the notification mode determination unit V6 determines whether the vehicle 1 can provide detailed information about the abnormality. If Yes, proceed to S210. If No, proceed to S206.

[0125] In S210, the notification mode determination unit V6 determines notification content based on the notification target and notification level determined in S204, excluding recommended and required actions for the developer. For example, the notification mode determination unit V6 provisionally determines notification content based on Table 1 of the first embodiment, and then, if the notification content includes either the recommended or required action for the developer, excludes that action. After processing S210, the process proceeds to S211.

[0126] S210 is the same as S106 in the first embodiment. After S210, the series of processes ends.

[0127] According to the second embodiment described above, if an abnormality has been notified in the past, at least one of the notification target and the notification level is changed from the previous notification. This makes it easier to resolve a situation where an abnormality notified in the past has not been addressed, and also makes it possible to avoid the hassle of repeatedly sending the same notification.

[0128] Furthermore, according to the second embodiment, when the notification target is the developer of the vehicle 1 or an application used in the vehicle 1, the notification content includes recommended or required measures for the developer to deal with the abnormality. In this way, the developer can recognize the abnormality and quickly take measures.

[0129] Furthermore, according to the second embodiment, when the notification target is the developer of the vehicle 1 or an application used in the vehicle 1, and it is determined that the developer can discover an abnormality from the vehicle data, the content of the notification is determined by excluding recommended or necessary measures for the developer to deal with the abnormality. Because the developer can discover an abnormality from the collected vehicle data, the complexity of notifications can be reduced by restricting notifications more than necessary.

[0130] Furthermore, according to the second embodiment, when the notification target is the vehicle 1 or a developer of an application used in the vehicle 1, and the vehicle 1 is unable to provide detailed information about the abnormality to the outside of the vehicle, the notification content is determined by excluding recommended or necessary actions for the developer to deal with the abnormality. Since the developer is unable to analyze and deal with the abnormality, unnecessary notifications are restricted, thereby reducing the complexity of notifications.

[0131] (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.

[0132] In another embodiment, when the notification target is outside the vehicle, the notification mode determination unit V6 may temporarily transmit a notification request to the server 20 in the processing of S106, S210. Then, the server 20 may transmit a notification to the terminal associated with the notification target.

[0133] In another embodiment, the notification recipient may be a person other than the driver or the developer, such as a person in charge of an operation management company, a person in charge of a dealer, a person in charge of an insurance company, etc. In this case, the notification may be sent via the DCM 11 to a terminal of each company, which corresponds to the other device 90.

[0134] In another embodiment, the data management device 10 may have a configuration having multiple functions by adding a data management function to a device having other functions. For example, the data management device 10 may be an automatic driving device that realizes an automatic driving function for planning the vehicle 1 in automatic driving. The data management device 10 may be an ADAS (Advanced Driver-Assistance Systems) application driving assistance device for assisting the driver in driving. The data management device 10 may be an information notification control device that controls the information notification device 12.

[0135] 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 data management device 10 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.

[0136] The controller and methods described herein may be implemented by a special-purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the apparatus and methods described herein may be implemented by special-purpose hardware logic circuitry. Alternatively, the apparatus and methods described herein may be implemented by one or more special-purpose computers comprising a processor executing a computer program in combination with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium.

[0137] (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.

[0138] <Technical Idea 1> An on-board device that is mounted on a vehicle (1) capable of participating in public road traffic and includes at least one processor (10b), wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data in an external server (20); and determine a notification mode for the abnormality depending on the impact that the abnormality will have on the driver of the vehicle.

[0139] <Technical Idea 2> The in-vehicle device according to Technical Idea 1, wherein, in the determining, if it is determined that the abnormality will affect the driver, the at least one processor determines to notify the driver of the abnormality through an information notification device (12) of the vehicle.

[0140] <Technical Idea 3> The in-vehicle device according to Technical Idea 1 or 2, wherein, in the determination, the at least one processor determines to notify the outside of the vehicle of the abnormality through a communication module (11) of the vehicle if it is determined that the abnormality will not affect the driver.

[0141] <Technical Idea 4> An on-board device that is mounted on a vehicle (1) capable of participating in public road traffic and includes at least one processor (10b), wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data in a server (20) outside the vehicle; and determine a notification mode for the abnormality depending on whether the abnormality is a hardware abnormality or a software abnormality.

[0142] <Technical Idea 5> The in-vehicle device according to any one of Technical Ideas 1 to 4, wherein, in the determining, if the abnormality is an abnormality in an idle hardware resource (13) of the vehicle, the at least one processor determines to notify the driver of the vehicle of the abnormality through an information notification device (12) of the vehicle.

[0143] <Technical Idea 6> The data collection function is executed by operating an application under development in the vehicle in a special mode in which reflection in actual vehicle control functions is prohibited, and the at least one processor, in determining, decides to notify the abnormality to the outside of the vehicle through a communication module (11) of the vehicle if the abnormality is a software abnormality that is processing for operating the application in the special mode.

[0144] <Technical Idea 7> The in-vehicle device described in any one of Technical Ideas 1 to 6, wherein the at least one processor: installs an application on idle hardware resources (13) of the vehicle, runs the application; acquires the vehicle data related to the operation of the application and transmits it to the server; and further executes the process; and in detecting the abnormality, analyzes at least one of the installation, the operation, and the vehicle data to detect an abnormality in the hardware resources.

[0145] <Technical Idea 8> The in-vehicle device described in any one of Technical Ideas 1 to 7, wherein the at least one processor, in determining the notification mode of the abnormality, includes: determining a notification target; determining a notification level indicating the degree of notification for the notification target; and determining the content of the notification depending on the notification target and the notification level.

[0146] <Technical Idea 9> The in-vehicle device according to Technical Idea 8, wherein, in determining the notification mode of the abnormality, if the abnormality has been notified in the past, the at least one processor changes at least one of the notification target and the notification level from the previous notification.

[0147] <Technical Idea 10> The in-vehicle device according to Technical Idea 8 or 9, wherein, in determining the manner of notification of the abnormality, the at least one processor determines that, if the notification target is the vehicle or a developer of an application used in the vehicle, the notification content should include recommended or required measures for the developer to deal with the abnormality.

[0148] <Technical Idea 11> The in-vehicle device according to Technical Idea 8 or 9, wherein, in determining the manner of notification of the abnormality, if the notification target is the vehicle or a developer of an application used in the vehicle, and if it is determined that the developer can discover the abnormality from the vehicle data, the at least one processor determines the content of the notification by excluding recommended or necessary measures for the developer to deal with the abnormality.

[0149] <Technical Idea 12> The in-vehicle device according to Technical Idea 8, 9 or 11, wherein, in determining the manner of notification of the abnormality, if the notification target is the vehicle or a developer of an application used in the vehicle and the vehicle is unable to provide detailed information about the abnormality to the outside of the vehicle, the at least one processor determines the content to be notified by excluding recommended or necessary measures for the developer to deal with the abnormality.

Claims

1. An on-board device mounted on a vehicle (1) capable of participating in public road traffic and having at least one processor (10b), wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data at an external server (20); and determine a notification mode for the abnormality depending on the impact of the abnormality on the driver of the vehicle.

2. The in-vehicle device according to claim 1, wherein, in the determining step, if it is determined that the abnormality will affect the driver, the at least one processor determines to notify the driver of the abnormality through an information notification device (12) of the vehicle.

3. The in-vehicle device according to claim 1, wherein the at least one processor, when determining that the abnormality will not affect the driver, decides to notify the outside of the vehicle of the abnormality through a communication module (11) of the vehicle.

4. An on-board device mounted on a vehicle (1) capable of participating in public road traffic and having at least one processor (10b), wherein the at least one processor is configured to: detect an abnormality in the vehicle using a data collection function that collects vehicle data on a server (20) outside the vehicle; and determine a notification mode for the abnormality depending on whether the abnormality is a hardware abnormality or a software abnormality.

5. The in-vehicle device according to claim 2 or 4, wherein, in the determining, if the abnormality is an abnormality in an idle hardware resource (13) of the vehicle, the at least one processor determines to notify the driver of the vehicle of the abnormality through an information notification device (12) of the vehicle.

6. The in-vehicle device according to claim 3 or 4, wherein the data collection function is executed by operating an application under development in the vehicle in a special mode in which reflection in actual vehicle control functions is prohibited, and wherein the at least one processor, in determining, if the abnormality is a software abnormality that is processing for operating the application in the special mode, determines to notify the abnormality to the outside of the vehicle via a communication module (11) of the vehicle.

7. The in-vehicle device according to claim 1 or 4, wherein the at least one processor: installs an application on idle hardware resources (13) of the vehicle, runs the application, acquires vehicle data related to the operation of the application and transmits it to the server, and further executes the above; and in detecting the abnormality, analyzes at least one of the installation, the operation, and the vehicle data to detect an abnormality in the hardware resources.

8. The in-vehicle device of claim 1 or 4, wherein the at least one processor, in determining the notification mode of the abnormality, includes determining a notification target, determining a notification level indicating the degree of notification for the notification target, and determining the content of the notification depending on the notification target and the notification level.

9. The in-vehicle device according to claim 8, wherein, in determining the notification mode of the abnormality, if the abnormality has been notified in the past, the at least one processor changes at least one of the notification target and the notification level from the previous notification.

10. The in-vehicle device according to claim 8, wherein, in determining the manner of notification of the abnormality, the at least one processor determines that, if the notification recipient is the developer of the vehicle or an application used in the vehicle, the notification content should include recommended or required measures for the developer to deal with the abnormality.

11. The in-vehicle device according to claim 8, wherein, in determining the manner of notification of the abnormality, if the notification target is the developer of the vehicle or an application used in the vehicle and it is determined that the developer is able to discover the abnormality from the vehicle data, the at least one processor determines the content of the notification by excluding recommended or necessary measures for the developer to deal with the abnormality.

12. The in-vehicle device of claim 8, wherein, in determining the manner of notification of the abnormality, the at least one processor determines the content of the notification by excluding recommended or necessary measures for the developer to deal with the abnormality when the notification target is the vehicle or a developer of an application used in the vehicle and the vehicle is unable to provide detailed information about the abnormality to the outside of the vehicle.

13. A program used in an on-board device (10) mounted on a vehicle (1) capable of participating in public road traffic, the program causing at least one processor (10b) to: detect an abnormality in the vehicle using a data collection function that collects vehicle data in an external server (20); and determine a notification mode for the abnormality depending on the impact of the abnormality on the driver of the vehicle.

Images