JP2020071594A - History storage device and history storage program - Google Patents

Abstract

To provide a history preservation device or the like capable of storing history information suitable for a subsequent use by another person concerning an individual vehicle.SOLUTION: An on-vehicle ECU 100 is used in a vehicle A including an on-vehicle sensor 30 to be used in an operation support or an automatic operation, and stores history information of the vehicle A. The on-vehicle ECU 100 acquires detection information of the on-vehicle sensor 30, and specifies that the vehicle A has been damaged with the use of the detection information. Then, the on-vehicle ECU 100 preserves history information of damage occurrence in a state in which the information cannot be altered by a user of the vehicle A based on specification of damage occurrence.SELECTED DRAWING: Figure 1

Description

  The disclosure of this specification relates to a technique of accumulating vehicle history information.

  Conventionally, for example, Patent Document 1 describes that the history of past traffic violations and accidents of a driver holding a driver's license is stored in a database in association with the driver ID of the driver. .. The driving support system of Patent Document 1 identifies a driver who has repeatedly caused traffic violations and accidents in the past based on history information, and sets a recommended route that bypasses the place where such a driver is traveling.

Japanese Patent No. 4802942

  In Patent Document 1, the history information such as the accident is only stored in association with the driver ID, and is not stored in association with the vehicle. Therefore, a purchaser who purchases a vehicle as a used car, a person in charge of an insurance company, or the like, who is not a user, cannot know information such as being damaged by a small accident. Against this background, we believe that there is a strong need for technology that accumulates the history information of individual vehicles assuming use by others.

  The present disclosure aims to provide a history storage device and a history storage program capable of accumulating history information suitable for later use by others for each vehicle.

  In order to achieve the above object, one aspect disclosed is a history storage device that stores history information of a vehicle (A) including an in-vehicle sensor (30) used for driving assistance or automatic driving. An information acquisition unit (51) for acquiring detection information of an in-vehicle sensor, a damage identification unit (53) for identifying that a vehicle has been damaged using the detection information, and an identification of damage occurrence by the damage identification unit. Based on this, the history storage device is provided with a history storage unit (55) that stores the history information of the damage occurrence in a state where it cannot be modified by the vehicle user.

  In addition, one aspect disclosed is a history accumulation program that is used in a vehicle (A) including an on-vehicle sensor (30) used for driving assistance or automatic driving, and that accumulates history information of the vehicle. The processing unit (61) is an information acquisition unit (51) that acquires detection information from an in-vehicle sensor, a damage identification unit (53) that identifies that damage has occurred in the vehicle using the detection information, and damage by the damage identification unit. Based on the identification of the occurrence, it is a history storage program that functions as a history storage unit (55) that stores the history information of the damage occurrence in a state in which it cannot be modified by the user of the vehicle.

  In these aspects, by using the detection information of the vehicle-mounted sensor used for driving assistance or automatic driving, the history of damages that have occurred in the vehicle is stored in a state that cannot be modified by the user of the vehicle. According to the above, even history information of damage caused by a small accident or the like that is not notified to the outside can be automatically accumulated and stored without being modified, without depending on the operation of the vehicle user. .. As a result, it becomes possible to store history information suitable for post-use by others for each vehicle.

  It should be noted that the reference numbers in the above parentheses merely show an example of a correspondence relationship with a specific configuration in the embodiment described later, and do not limit the technical scope at all.

FIG. 1 is a diagram showing an overview of a system for history storage including an in-vehicle ECU according to an embodiment of the present disclosure. It is a flow chart which shows the details of vehicle history accumulation processing carried out by in-vehicle ECU. 6 is a flowchart showing details of occupant abnormality accumulation processing executed by the vehicle-mounted ECU. It is a flow chart which shows the details of the outside-of-vehicle notification processing carried out by in-vehicle ECU. It is a flow chart which shows the details of information offer processing carried out in in-vehicle ECU.

  The function of the history storage device according to the embodiment of the present disclosure shown in FIG. 1 is implemented in an in-vehicle ECU (Electronic Control Unit) 100. The vehicle A is a so-called owner car that is personally owned by a specific owner and is supposed to be used by the owner or the like. The vehicle-mounted ECU 100 is one of a plurality of electronic control units mounted on the vehicle A, and is, for example, a body-system integrated ECU. The vehicle-mounted ECU 100 stores the history information of the vehicle A in a history database (hereinafter referred to as “history DB”) 59 provided in the vehicle A and a history DB 130 provided in the cloud CLD. The vehicle-mounted ECU 100 is directly or indirectly electrically connected to the DCM 41, the V2X communication device 43, the bus of the vehicle-mounted network 45, the plurality of vehicle-mounted sensors 30, and the like.

  The DCM (Data Communication Module) 41 is a communication module mounted on the vehicle A. The DCM 41 transmits and receives radio waves to and from base stations around the vehicle A by wireless communication according to communication standards such as LTE (Long Term Evolution) and 5G. The DCM 41 enables cooperation (Cloud to Car) between the cloud CLD and the in-vehicle device. By mounting the DCM 41, the vehicle A becomes a connected car that can be connected to the Internet. The DCM 41 enables sharing of history information about the vehicle A and the like with the history DB 130 installed on the cloud CLD.

  The V2X (Vehicle to Everything) communication device 43 is an in-vehicle communication device that realizes vehicle-to-vehicle communication, road-to-vehicle communication, pedestrian-to-vehicle communication, and the like. When the V2X communication device 43 includes an in-vehicle device 110 mounted on another vehicle As, a roadside device installed on a road, a mobile terminal 120 owned by a pedestrian Ps, and the like in the communication range, both of them are provided. Communication is possible. The V2X communication device 43 can notify the risk information (described later) of the vehicle A to other vehicles As and pedestrians Ps in the vicinity of the own vehicle by performing the vehicle-to-vehicle communication and the pedestrian-to-vehicle communication. When the vehicle-mounted device 110 receives the risk information from the V2X communication device 43, the vehicle-mounted device 110 alerts the driver or the like about the vehicle A by using the display and the sound. Similarly, when the mobile terminal 120 receives the risk information from the V2X communication device 43, the mobile terminal 120 alerts the pedestrian Ps or the like about the vehicle A using the display, voice, vibration, and the like.

  A large number of in-vehicle devices are electrically connected to the communication bus of the in-vehicle network 45 directly or indirectly. The vehicle-mounted network 45 can provide various vehicle information output to the communication bus to the vehicle-mounted ECU 100, and can also provide signals output from the vehicle-mounted ECU 100 to other vehicle-mounted devices.

  A travel control ECU, a biosensor, and the like are connected to the vehicle-mounted network 45. The travel control ECU is an electronic control unit that integrally controls the travel of the vehicle A. The travel control ECU partially restricts the travel of the vehicle A based on the driving operation of the driver according to the restriction signal received from the vehicle-mounted ECU 100. The biometric sensor is provided, for example, on the steering wheel or the seat surface of the driver's seat so that it can be contacted by the driver. The biometric sensor measures the pulse rate (heart rate) of the driver and outputs the measurement result to the vehicle-mounted ECU 100. The biometric sensor may be able to measure other biometric information such as blood pressure, brain waves, body temperature, and sweat rate. Further, the biometric information measured by the wearable device may be provided to the vehicle-mounted ECU 100 instead of the biometric information of the biometric sensor as the vehicle-mounted sensor 30.

  A dedicated terminal for maintenance and inspection is connected to the vehicle-mounted network 45 or the vehicle-mounted ECU 100 in a dealer, a factory, or the like. Such a dedicated terminal requests the vehicle-mounted ECU 100 to provide history information. As will be described later, the vehicle-mounted ECU 100 can provide the dedicated terminal with the history information accumulated in the history DB 59 in response to the provision request acquired from the dedicated terminal.

  The on-vehicle sensor 30 is a detection configuration that is mounted on the vehicle A and acquires various information used for (advanced) driving assistance or automatic driving. The in-vehicle sensor 30 includes an in-vehicle camera 31, an IMU 32, a millimeter wave radar 34 as an external sensor 33, a lidar 35, a front camera 36, a sonar 37, and the like.

  The in-vehicle camera 31 is a sensor that monitors the passenger compartment of the vehicle A and grasps the state of the occupant in the passenger compartment. The in-vehicle camera 31 has, for example, a near infrared light source and a near infrared camera, and a control unit that controls these. The in-vehicle camera 31 may include a visible light camera instead of the near infrared camera or together with the near infrared camera. The in-vehicle camera 31 is installed in the vehicle interior in the form of, for example, a driver status monitor (hereinafter, “DSM”) and a passenger room monitoring camera.

  The DSM is installed, for example, on the top surface of the cover of the steering column or the like with the near infrared camera facing the driver's seat. The DSM takes an image around the driver's face with a near infrared camera. The DSM sequentially outputs the captured face image to the vehicle-mounted ECU 100 as detection information indicating the driver's state.

  A plurality of cabin surveillance cameras are installed on the ceiling or the like of the cabin so that no blind spots are formed in the cabin. The cabin monitoring camera captures an image of equipment and passengers inside the vehicle with a near infrared camera or a visible light camera. The passenger compartment monitoring camera sequentially outputs the captured in-vehicle image to the vehicle-mounted ECU 100 as detection information indicating the state of the vehicle interior.

  The IMU 32 is composed of, for example, a triaxial gyro sensor, a triaxial acceleration sensor, and the like, and measures the inertial force acting on the vehicle A. The measurement result of the IMU 32 is mainly used in combination with a positioning signal received by a GNSS (Global Navigation Satellite System) receiver to identify the current position of the vehicle A. The IMU 32 sequentially outputs the measurement results of each gyro sensor and each acceleration sensor to the vehicle-mounted ECU 100 as detection information indicating the action of the external force on the vehicle A.

  The external sensor 33 is an autonomous sensor that recognizes the surrounding environment of the vehicle A. The external sensor 33 detects moving objects such as other vehicles As and pedestrians Ps, and stationary objects such as traffic signals, road signs, and road markings. Each detection configuration which is the external sensor 33 sequentially outputs detection information including detection results of a moving object and a stationary object to the vehicle-mounted ECU 100. At least a part of the external sensor 33 (for example, the front camera 36) includes the outside of the vehicle A in the detection range (imaging range). It should be noted that each of the detection configurations serving as the external sensor 33 may be plural. In addition, some detection configurations may be omitted.

  The millimeter wave radar 34 irradiates the millimeter wave toward the traveling direction of the vehicle A, and acquires the detection information by the processing of receiving the millimeter wave reflected by the moving object and the stationary object existing in the traveling direction. The lidar 35 irradiates the laser light toward the traveling direction of the vehicle A or to the front left and right, and acquires the detection information by a process of receiving the laser light reflected by a moving object, a stationary object, and the like existing in the irradiation direction. The lidar 35 may be a scanning type such as a rotating mirror type, a MEMS type, and a phased array type, or a non-scanning type such as a flash type. The front camera 36 acquires, as detection information, a front image of the front area of the vehicle A or an analysis result of the front image. The sonar 37 irradiates ultrasonic waves to the surroundings of the vehicle A, and acquires the detection information by a process of receiving ultrasonic waves reflected by a moving object, a stationary object, and the like existing in the irradiation direction.

  The vehicle-mounted ECU 100 is a vehicle-mounted computer that can automatically identify damage that has occurred in the vehicle A and accumulate history information of damage occurrence without depending on the operation of a user such as a driver. The vehicle-mounted ECU 100 mainly includes a control circuit including a processor 61, a RAM 62, a memory device 63, an input / output interface 64, and the like.

  The processor 61 is hardware for arithmetic processing combined with the RAM 62 and is capable of executing various programs. The memory device 63 has a configuration including a non-volatile storage medium, and stores various programs executed by the processor 61. The memory device 63 stores at least a history storage program for storing history information.

  The vehicle-mounted ECU 100 executes vehicle history accumulation processing (see FIG. 2), occupant abnormality accumulation processing (see FIG. 3), vehicle outside notification processing (see FIG. 4), information provision processing (see FIG. 5), and the like. Among these processes, the vehicle history accumulation process, the occupant abnormality accumulation process, and the vehicle exterior notification process are started based on the start of the power supply to the vehicle-mounted ECU 100 and are continuously executed until the end of the power supply. The vehicle-mounted ECU 100 is a functional unit that executes the above processes by the execution of the history storage program by the processor 61, and is an information acquisition unit 51, an abnormality identification unit 52, a damage identification unit 53, a history storage unit 55, and a notification execution unit 56. The restriction execution unit 57 and the information providing unit 58 are provided.

  The information acquisition unit 51 acquires detection information from each of the vehicle-mounted sensors 30 (see S101 in FIG. 2). Specifically, the information acquisition unit 51 acquires the face image and the in-vehicle image from the in-vehicle camera 31. Further, the information acquisition unit 51 acquires the detection information of the IMU 32 indicating the input of the external force, the detection information of the external sensor 33 indicating the recognition result of the external world, the biometric information of the driver by the biosensor, and the like. The information acquisition unit 51 can acquire information from the in-vehicle sensor 30 as well as the cloud CLD and the in-vehicle device 110 of the other vehicle As.

  The abnormality specifying unit 52 uses the detection information of the in-vehicle camera 31, the IMU 32, and the biometric sensor acquired by the information acquisition unit 51 to specify that the driver of the vehicle A has an abnormality. Specifically, the abnormality identifying unit 52 refers to the face image, which is the detection information of the in-vehicle camera 31, the heartbeat information measured by the biometric sensor, and the like (see S111 in FIG. 3), and analyzes the information. , The abnormality of the driver is specified (see S112 in FIG. 3). The abnormalities to be specified include a so-called dead man's posture collapse, loss of consciousness, long-time inattentiveness that disturbs driving, operation of a mobile terminal, and the like. Further, the abnormality specifying unit 52 uses the detection information of the IMU 32 to specify a high-risk driving operation such as sudden start, sudden braking, and sharp turn as an abnormality of the driver.

  The damage identifying unit 53 uses the detection information acquired by the information acquiring unit 51 to identify that the vehicle A has been damaged (see S102 in FIG. 2). Specifically, the damage identifying unit 53 identifies the occurrence of damage to the equipment inside the vehicle by analyzing the in-vehicle image of the in-vehicle camera 31. For example, damage to the seat and the interior, excessive dirt, etc. correspond to damage to the equipment inside the vehicle.

  In addition, the damage identifying unit 53 identifies the occurrence of damage outside the vehicle A by analyzing the detection information of the IMU 32 and the external sensor 33. For example, scratches, dents, and the like caused by the contact between the vehicle A and another object correspond to damage to the outside of the vehicle. The damage identification unit 53 can identify contact with another object by combining the recognition result of the external sensor 33 with the acceleration detected by the IMU 32. In addition, the damage identifying unit 53 identifies, as damage on the outside of the vehicle, severe dirt that may damage the coating of the vehicle A, for example, excessive adhesion of yellow sand, volcanic ash, salt, and the like. The damage identifying unit 53 can identify the stain on the exterior from the image of the front camera 36 including the outside of the vehicle A in the detection range (imaging range). Furthermore, the damage identifying unit 53 identifies a failure of a component other than a consumable item as damage to the vehicle A. The damage identifying unit 53 can identify the failure of the specific component from the abnormality information output to the vehicle-mounted network 45.

  The history storage unit 55 stores the history information of the damage occurrence based on the damage occurrence identification by the damage specifying unit 53. When the damage is identified by the damage identifying unit 53 (see S103 in FIG. 2), the history storage unit 55 generates history information by extracting the specific information from the detection information or the like (see S104 in FIG. 2). The history storage unit 55 generates, as a set of history information, a date and time of damage occurrence, an estimated damage occurrence location, a driver ID indicating a driver at the time of damage occurrence, a damage type and degree, and the like. The history storage unit 55 stores the generated history information in the history DB 59 of the vehicle A (see S105 in FIG. 2). In addition, the history storage unit 55 can store (upload) history information in the history DB 130 on the cloud CLD via the DCM 41.

  The history storage unit 55 further stores the abnormality information that has occurred in the driver or the like based on the abnormality occurrence identification by the abnormality identification unit 52. When the abnormality identifying unit 52 identifies an abnormality (see S113 in FIG. 3), the history storage unit 55 generates abnormality information by extracting the specific information from the detection information and the like (see S114 in FIG. 3). The history storage unit 55 generates a date and time of occurrence of an abnormality, a driver ID indicating a driver at the time of occurrence of the abnormality, a type and a degree of the abnormality, etc. as a set of abnormality information. The history storage unit 55 stores the generated abnormality information in the history DB 59 together with the history information (see S115 in FIG. 3).

  The history storage unit 55 can store the abnormality information and the history information in a state in which they cannot be modified by the user. The state in which the modification by the user is impossible is a state in which the contents cannot be changed or erased by a normal method disclosed to the public such as described in the manual of the vehicle A. More specifically, the abnormality information is stored in a state in which it cannot be modified by a normal method. On the other hand, the abnormality information may be erasable at the dealer or the like at the timing when the vehicle A is transferred, for example. On the other hand, the history information is stored in a state where it cannot be modified not only in the usual method but also in a specific facility such as a dealer. Specifically, the history information is stored as a transaction in chronological order in each block BL forming the block chain BC.

  When the history information to be included as a transaction in one block BL is accumulated, the history storage unit 55 requests the management server 140 on the cloud CLD for approval. As an example of such approval, the history storage unit 55 transmits some of the information stored in the block BL to the management server 140, for example. The management server 140 uses the transmitted information to generate a unique value that approves the block BL, and returns the generated unique value to the vehicle A that is the transmission source.

  Specifically, each block BL has a data structure including a block number, vehicle A identification information, transaction history information, management server 140 identification information, and a block header. The block header of each block BL includes the hash value of the block header of the immediately previous block BL, the Merkle root of the transaction, the unique value received from the management server 140, and the like.

  The block chain BC has a nested structure in which the block header of each block BL is hashed and incorporated into the next block header. Therefore, when the transaction or the like of one block BL is changed, the header hash value of the subsequent block BL also has a chained different value. Therefore, by confirming the header hash value, it is possible to verify the damage or modification of the transaction or the like. In other words, the history information is stored in an unmodifiable state.

  The history DB 130 on the cloud CLD may store a backup of the vehicle-mounted history DB 59, or may store history information and abnormality information by a storage method different from that of the vehicle-mounted history DB 59. For example, the history DB 130 may store history information provided from the vehicle-mounted ECUs 100 of the plurality of vehicles A so as to be included in one block chain. Furthermore, when an abnormality occurs in the block chain BC of the history DB 59, the history storage unit 55 receives necessary information from the history DB 130 and restores the block chain BC of the history DB 59.

  The notification execution unit 56 executes the outside-vehicle notification process in a state where the vehicle A can travel. The notification execution unit 56 refers to the history information and the abnormality information stored in the history DB 59 in the outside-vehicle notification process, and determines the current risk of the vehicle A based on the contents of these accumulated information. The risk of the car is set in 5 steps (see S121 in FIG. 4). The notification execution unit 56 identifies the current driver and then extracts the history information and the abnormality information associated with the driver from the history DBs 59 and 130. The notification execution unit 56 sets the own vehicle risk to be higher for a driver who has a history of past accidents and abnormal driving operations, or a driver who is suspected of being ill.

  Further, the notification execution unit 56 uses the detection information of the in-vehicle camera 31 as the DSM and the biometric sensor to set the own vehicle risk. For example, when a physical or mental abnormal state, specifically, a state such as fatigue, drowsiness, aimlessness, and impatience is estimated from the face image and heartbeat information, the notification execution unit 56 sets the value based on the accumulated information. Therefore, the vehicle risk is corrected to a high level.

  The notification execution unit 56 searches for other vehicles As and pedestrians Ps located in the communication range of the V2X communication device 43 in the vicinity of the vehicle A, and when the other vehicles As and pedestrians Ps exist in the communication range. Are set as notification targets (see S122 in FIG. 4). Then, the notification execution unit 56 notifies the current vehicle risk (risk information) to the in-vehicle device 110 or the mobile terminal 120 to be notified (see S123 in FIG. 4). As a result, the in-vehicle device 110 and the mobile terminal 120 call for attention.

  As a specific example, when a user (driver) of another vehicle As approaches a vehicle A having an external damage history (accident history), the risk information of the vehicle A is acquired. As a result, the user of the other vehicle As can take preventive measures such as traveling while avoiding the vehicle A that frequently causes an accident, or avoiding the area next to the vehicle A and parking. According to such notification, the damage reduction of the tilting operation can be realized. Similarly, the pedestrian Ps and the like can take preventive measures such as not approaching the vehicle A that often causes an accident, by referring to the notification received by the mobile terminal 120.

  The restriction execution unit 57 refers to the own-vehicle risk set by the notification execution unit 56 to determine whether or not the travel restriction is necessary based on the contents of the history information and the abnormality information stored in the history DBs 59 and 130. To do. When the current own-vehicle risk is higher than a predetermined threshold value, the restriction execution unit 57 outputs a restriction signal instructing the travel restriction to the travel control ECU through the in-vehicle network 45. As a result, the travel control ECU validates the travel restriction. As an example, when a plurality of pieces of history information indicating damage history are accumulated, the restriction execution unit 57 cooperates with the travel control ECU to enable travel restriction that prevents sudden start.

  When the own vehicle risk set by the notification execution unit 56 is at the highest level (level 5), the restriction execution unit 57 may make the current use of the driver substantially impossible. For example, the restriction execution unit 57 maintains the engine or the motor, which is the power source, in a stopped state by the restriction signal output to the travel control ECU. In such a scene, the restriction execution unit 57 may cause a preset contact address, for example, a mobile terminal of a family member, a dealer, a hospital, a security company, a police officer, or the like to transmit the notification.

  The information providing unit 58 performs the outside-vehicle notification process based on, for example, the connection of the dedicated terminal or the like to the in-vehicle network 45. The information providing unit 58 provides at least a part of the history information stored in the history DBs 59 and 130 to the request source in response to a request for provision from the outside such as a dedicated terminal. Specifically, the information providing unit 58 acquires a provision request from a dedicated terminal or the like through the vehicle-mounted network 45 or the like (see S131 in FIG. 5). The information providing unit 58 extracts the history information requested by the provision request from the history DBs 59 and 130 (see S132 in FIG. 5) and transmits the extracted history information to the requesting dedicated terminal or the like (S133 in FIG. 5). reference). As a result, the history information can be referred to by using the dedicated terminal. The assumed reference person of the history information is a person different from the owner of the vehicle A, and specifically, a person in charge of the insurance company, a purchaser who purchases the vehicle A as a used vehicle, and the like. The referrer can know, for example, repair information not using insurance from the history information.

  In the present embodiment described thus far, by using the detection information of the vehicle-mounted sensor 30, the history of damage that has occurred in the vehicle A is stored in a state that cannot be modified by the user. According to the above, even history information of damage caused by a small accident or the like that is not notified to the outside can be automatically accumulated without being operated by the user and stored without being modified. As a result, it becomes possible to store history information about each vehicle A suitable for later use by others.

  In addition, the vehicle-mounted sensor 30 of the present embodiment includes an in-vehicle camera 31 that monitors the interior of the vehicle A. Then, not only the history information of the damage occurring outside the vehicle but also the history information of the damage occurring inside the vehicle is stored in the history DBs 59 and 130. Therefore, for example, information such as severe stain on the sheet can be stored in the history DBs 59 and 130. Therefore, when trading the vehicle A later, the asymmetry of the information between the transferor and the purchaser can be reduced. According to the above, since the vehicle A can be smoothly transferred, the history information can be useful for both parties.

  Further, in the present embodiment, the abnormality that has occurred in the driver is specified, and not only the history information but also the abnormality information is stored. In this way, if the abnormality information is stored in association with the driver, the degree of risk of each vehicle A viewed from others can be set more appropriately.

  Then, in the present embodiment, the risk information of the own vehicle is notified to the notification target around the vehicle A, for example, the other vehicle As and the pedestrian Ps based on the content of the abnormality information. Therefore, the driver of the other vehicle As and the pedestrian Ps can act proactively so as to avoid trouble with the high-risk vehicle A. As described above, the automatically stored abnormality information can be utilized so as to be useful to others.

  Furthermore, in the present embodiment, the travel limitation of the vehicle A is implemented based on the content of the history information or the abnormality information. By executing the above-mentioned forced travel restriction, the trouble caused by the abnormal condition of the driver can be effectively reduced.

  In addition, the vehicle-mounted ECU 100 of the present embodiment can provide at least a part of the history information to the request source in response to a provision request from the outside such as a dedicated terminal. As described above, if the accumulated history information can be easily retrieved, the possibility of utilizing the history information can be further expanded.

  Further, in the present embodiment, the history information is stored in the block BL that constitutes the block chain BC. If the history is stored using the blockchain technology, it is virtually impossible for the user or the like to modify the history information. As a result, the history information becomes highly transparent information suitable for later use.

  Further, in the present embodiment, the outside of the vehicle A is included in the detection range of the front camera 36 and the like, and such damage to the outside of the vehicle A is also stored as history information. As described above, if the vehicle-mounted sensor 30 can directly detect the external state of the vehicle A, the reliability of damage detection can be improved. As a result, not only damage information due to contact or the like but also damage information due to excessive dirt or the like can be accurately accumulated.

  In the above embodiment, the processor 61 corresponds to a “processing unit”, the vehicle-mounted ECU 100 corresponds to a “history storage device”, and the vehicle-mounted device 110 and the mobile terminal 120 correspond to “notification targets”.

(Other embodiments)
Although one embodiment of the present disclosure has been described above, the present disclosure is not construed as being limited to the above embodiment, and is applied to various embodiments and combinations without departing from the scope of the present disclosure. be able to.

  In the first modification of the above embodiment, the abnormality information is stored in each block BL of the block chain BC together with the history information. In the modified example 1, not only the history information but also the abnormality information cannot be erased or modified.

  In the second modification of the above embodiment, the history information is stored in a form different from that of the block chain BC. The history information is stored in a state in which it cannot be erased or modified by a normal method. In the second modification, the history information may be deleted by a special facility or a special method at a specific facility such as a dealer.

  In Modification 3 of the above-described embodiment, the vehicle-mounted ECU 100 is mounted on the vehicle A that is supposed to be used in a rental car. Further, in the modified example 4 of the above-described embodiment, the vehicle-mounted ECU 100 is mounted on the vehicle A used for ride sharing. Further, in the fifth modified example of the above-described embodiment, the vehicle-mounted ECU 100 is mounted on the vehicle A used as a taxi or the vehicle A that transports freight and passengers. Further, in the sixth modified example of the above-described embodiment, the vehicle-mounted ECU 100 is mounted in the vehicle A dedicated to unmanned driving used for the mobility service.

  In Modifications 3 to 6 described above, the service user can use the user terminal 150 to acquire history information accumulated in the history DB 130, specifically, an accident history and a failure history. Further, in Modifications 4 and 5 described above, not only history information but also abnormality information can be provided to the service user. In addition, in Modification 5 described above, not only the service user but also the operation manager or the like can acquire the history information and the abnormality information. The user terminal 150 may be, for example, a mobile terminal of a service user or a communication terminal dedicated to reservation.

  Furthermore, the notification execution unit 56 of the modified example 6 may transmit the notification that the vehicle is traveling in the absence of a driver to the vehicle-mounted device 110 of the other vehicle As and the mobile terminal 120 of the pedestrian Ps. Such notification of unmanned driving may be useful for drivers and pedestrians Ps who are uneasy about automatic driving. In addition, the abnormality identifying unit 52 of Modification 6 can identify an abnormality that has occurred in the user (passenger) of the mobility service from the image of the in-vehicle camera 31.

  The configuration of the vehicle-mounted sensor 30 in the above embodiment can be changed as appropriate. For example, in the seventh modification of the above-described embodiment, a plurality of outside cameras capable of monitoring the entire circumference of the vehicle A are provided instead of the front camera 36 or together with the front camera 36. Further, in the modified example 8 of the above embodiment, the in-vehicle camera 31 is omitted, and the occurrence of damage occurring in the vehicle interior is not accumulated. Further, in the modified example 9 of the above-described embodiment, only the damage in the vehicle interior specified from the in-vehicle image of the in-vehicle camera 31 is accumulated as the history information.

  In the tenth modification of the above embodiment, the abnormality identifying unit 52 is omitted. Further, in the eleventh modified example of the above embodiment, the notification execution unit 56 is omitted. Furthermore, in the twelfth modified example of the above-described embodiment, the restriction execution unit 57 is omitted. Then, in the modified example 13 of the above embodiment, the information providing unit 58 is omitted.

  In Modification Example 14 of the above-described embodiment, a dedicated ECU for accumulating history information is installed in vehicle A as a history accumulation device. Further, in the fifteenth modification of the above-described embodiment, the function of accumulating history information is implemented in the ECU for automatic driving, the ECU for HMI control, or the like. Furthermore, in the sixteenth modification of the above-described embodiment, a plurality of vehicle-mounted ECUs perform distributed processing of calculations related to history accumulation. In the modification 17 of the above-described embodiment, the management server 140 mainly executes the process of accumulating the history information of each vehicle A.

  As described above, each function provided by the vehicle-mounted ECU 100 in the above-described embodiment can be provided by software and hardware that executes the software, only software, only hardware, or a combination thereof. .. Further, when such a function is provided by an electronic circuit that is hardware, each function can also be provided by a digital circuit including a large number of logic circuits or an analog circuit.

  In addition, the specific configuration of the data processing related to the history storage program and the like, and the specific configuration of the “processing unit” that executes the instruction and the code can be appropriately changed. The processing unit may be configured to include a GPU (Graphics Processing Unit) in addition to a CPU (Central Processing Unit). Further, the processor may include an FPGA (Field-Programmable Gate Array) and an accelerator (for example, DSP (Digital Signal Processor)) specialized for learning and inference of AI. Furthermore, the processor may be configured to be mounted on an ASIC (Application Specific Integrated Circuit), an FPGA, or the like.

  Various non-transitory tangible storage media such as a flash memory and a hard disk can be used as the memory device 63 as a configuration for storing the history storage program and the like. The form of such a storage medium may be appropriately changed. For example, the storage medium may be in the form of a memory card or the like, and may be configured to be inserted into the slot portion and electrically connected to the control circuit of the vehicle-mounted ECU 100. Further, the storage medium is not limited to the memory device 63 of the vehicle-mounted ECU 100 as described above, and may be an optical disk serving as a base for copying the program to the memory device 63, a hard disk drive of a general-purpose computer, or the like.

A vehicle, BC block chain, BL block, 30 vehicle-mounted sensor, 31 vehicle-mounted camera, 33 external sensor, 51 information acquisition unit, 52 abnormality identification unit, 53 damage identification unit, 55 history storage unit, 56 notification execution unit, 57 restricted execution Section, 58 information providing section, 61 processor (processing section), 100 vehicle-mounted ECU (history storage device), 110 vehicle-mounted device (report target), 120 mobile terminal (report target)

Claims (9)

In a vehicle (A) including an on-vehicle sensor (30) used for driving assistance or automatic driving, a history storage device for storing history information of the vehicle,
An information acquisition unit (51) for acquiring detection information of the in-vehicle sensor,
A damage identifying unit (53) that identifies that damage has occurred in the vehicle using the detection information;
A history storage unit (55) which stores history information of the damage occurrence based on the damage occurrence identification by the damage specifying unit in a state in which the damage cannot be changed by a user of the vehicle;
History storage device. The vehicle-mounted sensor includes an in-vehicle camera (31) for monitoring the interior of the vehicle,
The history storage device according to claim 1, wherein the history storage unit stores history information of damage that has occurred in the vehicle interior. An abnormality specifying unit (52) for specifying that an abnormality has occurred in a driver who drives the vehicle using the detection information from the in-vehicle camera,
The history storage device according to claim 2, wherein the history storage unit stores the abnormality information generated in the driver in addition to the history information of the damage occurrence based on the abnormality occurrence identification by the abnormality identification unit.   A notification execution unit (56) for notifying risk information of the own vehicle to the notification targets (110, 120) located around the vehicle based on the content of the abnormality information stored by the history storage unit. The history storage device according to claim 3.   The history storage device according to claim 3 or 4, further comprising: a restriction execution unit (57) that restricts the travel of the vehicle based on the content of the history information or the abnormality information stored by the history storage unit.   The information providing unit (58) for providing at least a part of the history information that is unalterably stored to a request source in response to a request from the outside of the vehicle. The history storage device according to item.   The history storage device according to any one of claims 1 to 6, wherein the history storage unit stores the history information of the damage occurrence in a block (BL) forming a block chain (BC). The vehicle-mounted sensor includes an external sensor (33) including the outside of the vehicle in a detection range,
The history storage device according to any one of claims 1 to 7, wherein the history storage unit stores history information of damage that has occurred outside the vehicle. A history accumulation program for accumulating history information of a vehicle (A) including an on-vehicle sensor (30) used for driving support or automatic driving,
At least one processing unit (61),
An information acquisition unit (51) for acquiring the detection information of the in-vehicle sensor,
A damage identification unit (53) that identifies that damage has occurred in the vehicle using the detection information;
A history storage unit (55) that stores history information of the damage occurrence based on the damage occurrence identification by the damage specifying unit in a state in which it cannot be modified by the user of the vehicle,
History accumulation program that functions as.

Images