WO2020040000A1 - サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法 - Google Patents

サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法 Download PDF

Info

Publication number
WO2020040000A1
WO2020040000A1 PCT/JP2019/031842 JP2019031842W WO2020040000A1 WO 2020040000 A1 WO2020040000 A1 WO 2020040000A1 JP 2019031842 W JP2019031842 W JP 2019031842W WO 2020040000 A1 WO2020040000 A1 WO 2020040000A1
Authority
WO
WIPO (PCT)
Prior art keywords
inspection
vehicle
vehicles
target vehicle
transaction
Prior art date
Application number
PCT/JP2019/031842
Other languages
English (en)
French (fr)
Inventor
孝尚 矢野
信浩 福田
睦 日向
紀彦 小林
Original Assignee
パナソニックIpマネジメント株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニックIpマネジメント株式会社 filed Critical パナソニックIpマネジメント株式会社
Priority to CN201980054667.0A priority Critical patent/CN112585629A/zh
Priority to DE112019004199.1T priority patent/DE112019004199B4/de
Publication of WO2020040000A1 publication Critical patent/WO2020040000A1/ja
Priority to US17/178,933 priority patent/US12025463B2/en

Links

Images

Classifications

    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804Creation or updating of map data
    • G01C21/3833Creation or updating of map data characterised by the source of data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/20Administration of product repair or maintenance
    • GPHYSICS
    • G01MEASURING; TESTING
    • G01CMEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/38Electronic maps specially adapted for navigation; Updating thereof
    • G01C21/3804Creation or updating of map data
    • G01C21/3807Creation or updating of map data characterised by the type of data
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/02Control of position or course in two dimensions
    • G05D1/021Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0212Control of position or course in two dimensions specially adapted to land vehicles with means for defining a desired trajectory
    • G05D1/0214Control of position or course in two dimensions specially adapted to land vehicles with means for defining a desired trajectory in accordance with safety or protection criteria, e.g. avoiding hazardous areas
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/02Control of position or course in two dimensions
    • G05D1/021Control of position or course in two dimensions specially adapted to land vehicles
    • G05D1/0276Control of position or course in two dimensions specially adapted to land vehicles using signals provided by a source external to the vehicle
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/20Control system inputs
    • G05D1/24Arrangements for determining position or orientation
    • G05D1/247Arrangements for determining position or orientation using signals provided by artificial sources external to the vehicle, e.g. navigation beacons
    • GPHYSICS
    • G05CONTROLLING; REGULATING
    • G05DSYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/60Intended control result
    • G05D1/617Safety or protection, e.g. defining protection zones around obstacles or avoiding hazards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/1734Details of monitoring file system events, e.g. by the use of hooks, filter drivers, logs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40Business processes related to the transportation industry
    • GPHYSICS
    • G08SIGNALLING
    • G08GTRAFFIC CONTROL SYSTEMS
    • G08G1/00Traffic control systems for road vehicles
    • G08G1/09Arrangements for giving variable traffic instructions
    • G08G1/0962Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096775Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is a central station
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2554/00Input parameters relating to objects
    • B60W2554/40Dynamic objects, e.g. animals, windblown objects
    • B60W2554/404Characteristics
    • B60W2554/4048Field of view, e.g. obstructed view or direction of gaze
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00Input parameters relating to data
    • B60W2556/45External transmission of data to or from the vehicle
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60WCONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00Input parameters relating to data
    • B60W2556/45External transmission of data to or from the vehicle
    • B60W2556/65Data transmitted between vehicles
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07CTIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00Registering or indicating the working of vehicles
    • G07C5/08Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0816Indicating performance data, e.g. occurrence of a malfunction

Definitions

  • the present disclosure relates to a server, a vehicle, a distributed transaction certification system, and a distributed transaction certification method.
  • Such self-driving vehicles are equipped with a plurality of sensors in order to measure surrounding external environment information in real time during autonomous driving.
  • the sensors are, for example, cameras, millimeter-wave radars, LiDAR (Light Detection and Ranging, Laser Imaging and Detection and Ranging), and GNSS (Global Navigation Satellite System) sensors.
  • LiDAR Light Detection and Ranging
  • GNSS Global Navigation Satellite System
  • the control of the autonomous driving is executed based on the measurement results obtained by detecting the various sensors described above. Therefore, for example, if a failure occurs in the sensor during automatic driving, the possibility of a traffic violation or a traffic accident increases.
  • vehicle inspection system for example, a regular passenger car has a vehicle inspection period set every three or two years. It is difficult.
  • a malfunction occurs in the sensor or the like, it takes time to move or inspect the self-driving vehicle to the vehicle inspection site, and during that time, the self-driving vehicle cannot be used, and there is a problem that the use efficiency is deteriorated.
  • the present disclosure is devised in view of the above-described conventional circumstances, manages the execution result of a transaction related to inspection of a failure of a sensor mounted on each of a plurality of familiar vehicles and a detection result of the presence or absence of a failure of the sensor, It is an object of the present invention to provide a server, a vehicle, a distributed transaction proof system, and a distributed transaction proof method that accurately ensure the validity of a transaction executed in each vehicle.
  • the present disclosure is a server configuring a distributed transaction certification system including a plurality of vehicles, and a memory holding a block chain that sequentially records transaction information on inspections of the plurality of vehicles;
  • a processor for selecting a vehicle to be inspected from the vehicles and adding transaction information relating to the inspection of the selected vehicle to the blockchain;
  • a communication circuit for sending an instruction to execute a transaction relating to the inspection to the target vehicle;
  • the processor has added an inspection result based on an execution result of the transaction related to the inspection in the target vehicle based on the execution instruction and an execution result of the transaction related to the inspection in a peripheral vehicle other than the target vehicle. Inspection of the target vehicle It is registered in the transaction information, to provide a server.
  • the present disclosure relates to a vehicle that constitutes a distributed transaction certification system including a server, and a communication circuit that communicates with the server that holds a block chain that sequentially records transaction information related to inspection of the vehicle.
  • a control unit that controls an operation including driving of the own vehicle, and when the own vehicle is selected as a target vehicle for inspection, the communication circuit receives an instruction to execute a transaction related to the inspection, The control unit controls execution of a transaction relating to the inspection based on the execution instruction, and based on an inspection result based on an execution result of the transaction relating to the inspection in the own vehicle and an execution result of the transaction relating to the inspection in another vehicle,
  • a vehicle that controls an operation including driving of the own vehicle.
  • the present disclosure is a distributed transaction certification system in which a server and a plurality of vehicles are communicably connected to each other, wherein the server sequentially records transaction information on inspections of the plurality of vehicles. Holding a chain, selecting a target vehicle for inspection from among the plurality of vehicles, creating transaction information relating to inspection of the selected target vehicle in the blockchain, and issuing an instruction to execute a transaction relating to inspection to the target vehicle.
  • the target vehicle executes the transaction related to the inspection based on the execution instruction, and sends an execution instruction of the transaction related to the inspection to peripheral vehicles other than the target vehicle.
  • the above-mentioned inspections for each of the surrounding vehicles The inspection result based on the execution result of Nzakushon, registers the transaction information regarding inspection of the subject vehicle that were created to provide a distributed transaction verification system.
  • the present disclosure is a distributed transaction certification method using a distributed transaction certification system in which a server and a plurality of vehicles are communicably connected, wherein transaction information relating to inspection of each of the plurality of vehicles is linked. Holding a blockchain to be recorded in the vehicle, selecting a vehicle to be inspected from among the plurality of vehicles, and creating transaction information on the inspection of the selected target vehicle in the blockchain, Sending a transaction execution instruction to the target vehicle; executing a transaction relating to the inspection based on the execution instruction; and transmitting an execution instruction of the transaction relating to the inspection to peripheral vehicles other than the target vehicle; Vehicle and said The inspection results based on the transaction execution results for each of the inspection side vehicle, and a step of registering the transaction information regarding inspection of the subject vehicle that were created to provide a distributed transaction Certification Procedure.
  • any combination of the above-described components and any conversion of the expression of the present disclosure between a method, an apparatus, a system, a recording medium, a computer program, and the like are also effective as an embodiment of the present disclosure.
  • Explanatory diagram showing an operation example of the first use case of the distributed transaction certification system Diagram showing a system configuration example of the distributed transaction certification system Block diagram showing an example of the internal configuration of a server and a terminal Block diagram showing an example of the internal configuration of a vehicle Diagram showing a first configuration example of a block chain Diagram showing a second configuration example of the block chain Example of the data structure of the blocks that make up the blockchain
  • Flow chart showing an example of a server operation procedure corresponding to the first use case in a time series
  • Flowchart showing an example of the operation procedure of the target vehicle (vehicle) in chronological order Flowchart showing an operation procedure example of a peripheral vehicle (vehicle) in chronological order
  • Sequence diagram showing an operation procedure example of external environment measurement in a peripheral vehicle in time series
  • Sequence diagram showing the operation procedure example of external environment measurement in server or terminal in chronological order
  • Explanatory diagram showing an operation example of the second use case of the distributed transaction certification
  • the distributed transaction certification system holds and manages a block chain that sequentially records transaction information on inspections of a plurality of vehicles, and based on the block chain, manages a plurality of vehicles. Select the vehicle to be inspected from The distributed transaction certification system uses blockchain technology to determine inspection results based on execution results of transactions related to inspections in a target vehicle and other surrounding vehicles, and registers the determination results in the blockchain. As a result, according to the distributed transaction certification system, it becomes possible to prevent the target vehicle selected from the plurality of familiar vehicles based on the blockchain from performing tampering with the result of executing the transaction related to the inspection. The validity of the inspection result for the target vehicle is ensured.
  • the distributed transaction certification system holds and manages a block chain that sequentially records transaction information on inspections of a plurality of vehicles.
  • the distributed transaction certification system inquires whether other vehicles can detect the same event, and obtains a majority of normal detection results. In this case, data corresponding to the event is newly registered and registered in the block chain.
  • the distributed transaction certification system selects a vehicle that cannot be detected normally as a vehicle to be inspected. Processing after selection is the same as in the first use case.
  • the credibility of the detection result can be confirmed using a plurality of familiar vehicles in response to the detection of the event. Unregistered data that is not known before detection can be registered properly.
  • the validity of the inspection result on the target vehicle is secured.
  • FIG. 1 is an explanatory diagram showing an operation outline of a first use case of the distributed transaction certification system 100.
  • FIG. 2 is a diagram illustrating a system configuration example of the distributed transaction certification system 100.
  • a plurality of vehicles 31,..., 3m participate in the distributed transaction certification system 100 according to the first embodiment.
  • Each of the vehicles 31 to 3m is a vehicle capable of automatic driving, and has at least one sensor (see FIG. 4) capable of measuring external environment information around the own vehicle in order to perform automatic driving.
  • a fault such as a fault
  • vehicle inspection system for example, a regular passenger car has a vehicle inspection period set every three or two years. It is difficult.
  • the vehicle cannot be used during that time because it takes time to move or inspect the vehicle to a vehicle inspection site when a failure occurs in the sensor, and the use efficiency is deteriorated.
  • each of the plurality of vehicles 31 to 3 m (an example of a plurality of familiar vehicles) participating in the distributed transaction certification system 100 is subjected to a public inspection such as the above-described vehicle inspection.
  • the vehicle can be a target of the inspection so that the inspection can be performed more easily.
  • the inspection target is, for example, a sensor mounted on a vehicle.
  • the inspection target vehicle is one vehicle out of the total m vehicles.
  • the remaining (m-1) vehicles are peripheral vehicles that have a role to assist in checking the target vehicle.
  • FIG. 1 shows an example in which a total of four vehicles CR1, CR2, CR3, and CR4 participate in the distributed transaction certification system 100, and the vehicle CR2 is selected as a target vehicle.
  • the target vehicle that is, the vehicle CR2 travels on the same travel route in the same area as a transaction related to the inspection, and measures surrounding external environment information during the travel by a sensor mounted on the own vehicle ( St1). Further, the target vehicle (that is, the vehicle CR2) sends the external environment measurement result information of its own vehicle to the surrounding vehicles (that is, the vehicles CR1, CR3, and CR4), and determines whether the external environment measurement result information is correct.
  • the target vehicle that is, the vehicle CR2 makes an inquiry such as "Do you recognize me?"
  • the vehicles CR1 to CR4 can communicate with each other by, for example, V2V (Vehicle to Vehicle).
  • Each of the surrounding vehicles responds to the inquiry from the target vehicle (that is, the vehicle CR2) as a transaction related to the inspection, and performs the same traveling in the same area as the target vehicle (that is, the vehicle CR2) While traveling on the route, the surrounding external environment information is measured by a sensor mounted on each vehicle during the traveling (St2).
  • Each of the surrounding vehicles includes the external environment measurement result information received from the target vehicle (that is, the vehicle CR2) and the external environment measurement result information obtained by measuring the own vehicle. May be compared and the result may be returned.
  • the surrounding vehicles that is, the vehicles CR1 and CR4 respond with “measured but fit”.
  • the surrounding vehicle that is, the vehicle CR3) replies, "Measured but wrong.”
  • Each of the surrounding vehicles reports the comparison result of each own vehicle to the server 1 (see FIG. 2) (St3).
  • the server 1 receives the report of the comparison result from each of the surrounding vehicles (that is, the vehicles CR1, CR3, and CR4), and receives the consent of the majority (that is, the majority of (m-1)), and the target vehicle (that is, the vehicle CR2) Recognizes that the external environment measurement result information is correct.
  • the server 1 registers information indicating that the inspection of the target vehicle (that is, the vehicle CR2) was normal on the blockchains BKC1 and BKC2 (St3).
  • the server 1 sends a notification (that is, an inspection certificate notification) to the target vehicle (that is, the vehicle CR2) to prove that the inspection of the target vehicle (that is, the vehicle CR2) is normal (St3).
  • a notification that is, an inspection certificate notification
  • the target vehicle that is, the vehicle CR2
  • the target vehicle can easily obtain the proof that the inspection of the own vehicle is normal by the server 1, and the use of the sensor targeted for the inspection can be continued. .
  • Peripheral vehicles that is, peripheral environment measurement result information that matches the external environment measurement result information of the target vehicle (that is, vehicle CR2)) of the respective peripheral vehicles (that is, vehicles CR1, CR3, and CR4) from the server 1
  • a predetermined reward is given to the vehicles CR1, CR4) (St4).
  • the server 1 registers the transaction information on the inspection of each of the surrounding vehicles (that is, the vehicles CR1, CR3, and CR4) in the block chains BKC1 and BKC2 (St4).
  • the surrounding vehicle (that is, the vehicle CR3), for which the external environment measurement result information that matches the external environment measurement result information of the target vehicle (that is, the vehicle CR2) cannot be obtained, is, for example, the server 1 as the target vehicle for the next inspection. (St4).
  • the processing of steps St2, St3, and St4 in FIG. 1 is repeated.
  • the distributed transaction certification system 100 includes a server 1, terminals 21,..., 2n (n: an integer of 2 or more), and vehicles 31,. It is a configuration including.
  • the m vehicles 31 to 3m participate in the distributed transaction certification system 100 having the server 1 or the terminals 21 to 2n that manage the block chains BKC1 and BKC2.
  • the server 1, the terminals 21 to 2n, and the vehicles 31 to 3m are communicably connected to each other via the network NW1.
  • the network NW1 is formed as a wireless network such as a wireless LAN (Local Area Network) or a wired network such as a wired LAN.
  • the server 1 is configured using an information processing apparatus such as a desktop PC (Personal Computer), a notebook PC, a smartphone or a tablet terminal having high-speed information processing capability, for example.
  • the internal configuration of the server 1 is the same as that of each of the terminals 21 to 2n (see FIG. 3).
  • the server 1 includes a part or all of blockchains BKC1 and BKC2 (see FIGS. 5 and 6) that sequentially record (register) transaction information (see FIG. 7) relating to inspections of a plurality of vehicles 31 to 3m. Data can be held, and blocks (see FIG. 7) can be newly created and added to the block chains BKC1 and BKC2.
  • the server 1 comprehensively controls the execution of a transaction related to inspection performed by each of the plurality of vehicles 31 to 3m in cooperation with each of the terminals 21 to 2n. Details of the internal configuration of the server 1 will be described later with reference to FIG.
  • Each of the terminals 21 to 2n is configured using an information processing device such as, for example, a desktop PC, a notebook PC, a smartphone or a tablet terminal having high-speed information processing capability.
  • the internal configuration of each of the terminals 21 to 2n is the same as that of the server 1 (see FIG. 3).
  • Each of the terminals 21 to 2n is one of block chains BKC1 and BKC2 (see FIGS. 5 and 6) that sequentially record (register) transaction information (see FIG. 7) relating to the inspection of each of the plurality of vehicles 31 to 3m. Part or all of the data is held, and a block (see FIG. 7) can be newly created and added to the block chains BKC1 and BKC2.
  • each of the terminals 21 to 2n supplementarily controls the execution of the transaction relating to the inspection performed by each of the plurality of vehicles 31 to 3m in cooperation with the server 1. Details of the internal configuration of the terminals 21 to 2n will be described later with reference to FIG.
  • Each of the vehicles 31 to 3 m is a vehicle capable of automatic driving, and has at least one sensor (see FIG. 4) capable of measuring external environment information around the own vehicle in order to perform automatic driving.
  • each of the vehicles 31 to 3m is equipped with a camera 41, a LiDAR 42, a millimeter-wave radar 43, and other sensor groups 44 as sensors, and performs automatic driving using these sensors. Execute.
  • each of the vehicles 31 to 3 m can be a target vehicle for inspection of the sensor or a peripheral vehicle for supporting the inspection of the target vehicle.
  • Each of the vehicles 31 to 3m executes a transaction related to inspection (see above) based on an execution instruction (see below) from the server 1 or a vehicle that has become a target vehicle, and executes the transaction (ie, external environment measurement result information). ). Details of the internal configuration of the vehicles 31 to 3m will be described later with reference to FIG.
  • the data entities of the blockchains BKC1 and BKC2 are recorded and stored in, for example, the server 1 and the terminals 21 to 2n, respectively. Since the server 1 and the terminals 21 to 2n are connected to the network NW1, From the viewpoint of 31 to 3 m, it can be considered that the data is virtually recorded and held in the network NW1.
  • FIG. 3 is a block diagram showing an example of the internal configuration of the server 1 and the terminals 21 to 2n.
  • the server 1 includes an operation unit 11, a memory 12, a data storage unit 13, a communication circuit 14, and a processor 15.
  • the operation unit 11 is configured by an input device that receives an operation of a user of the distributed transaction certification system 100 (for example, an operator or an administrator of the distributed transaction certification system 100; the same applies hereinafter).
  • the operation unit 11 includes, for example, a mouse, a keyboard, and a touch panel.
  • the configuration of the operation unit 11 used by the user may be omitted from the server 1 by using a function according to the smart contract function in the blockchain technology. That is, the processor 15 records and holds the pre-defined information for executing the predetermined processing in the memory 12 or the data storage unit 13 in order to use the function according to the smart contract function.
  • the processor 15 may automatically execute the predetermined process.
  • the predetermined process is, for example, creation and transmission of an inspection certificate notification described later, but is not limited to this.
  • the memory 12 is configured using, for example, a RAM (Random Access Memory) and a ROM (Read Only Memory), and programs and data necessary for executing the operation of the server 1, and data or information generated during the operation. Temporarily.
  • the RAM is, for example, a work memory used when the server 1 operates.
  • the ROM previously stores and holds, for example, a program and data for controlling the server 1.
  • the data storage unit 13 is configured using, for example, a hard disk drive (HDD) or a solid state drive (SSD), and records and holds data or information generated by the processor 15.
  • the data storage unit 13 records and holds, for example, part or all of the data of the block chains BKC1 and BKC2. Details of a data structure example of the block chains BKC1 and BKC2 will be described later with reference to FIGS.
  • the communication circuit 14 is constituted by a communication circuit capable of transmitting and receiving data or information to and from each of the terminals 21 to 2n or each of the vehicles 31 to 3m.
  • the communication circuit 14 sends the data or information to a communication partner (for example, each of the terminals 21 to 2n or each of the vehicles 31 to 3m). Further, the communication circuit 14 receives data or information sent from a communication partner (see above) and sends the data or information to the processor 15.
  • the processor 15 is configured using, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or an FPGA (Field Programmable Gate Array).
  • the processor 15 functions as a controller that controls the overall operation of the server 1, performs control processing for controlling the operation of each unit of the server 1, input / output processing of data with each unit of the server 1, and calculation of data ( Calculation) and data storage processing.
  • the processor 15 operates according to programs and data stored in the memory 12.
  • the processor 15 uses the memory 12 during operation, and temporarily stores data or information generated or obtained by the processor 15 in the memory 12 or records the data or information in the data storage unit 13. Details of an operation example of the processor 15 will be described later with reference to FIG.
  • the terminals 21 to 2n each include an operation unit 11a, a memory 12a, a data storage unit 13a, a communication circuit 14a, and a processor 15a.
  • the operation unit 11a is configured by an input device that receives an operation of a user of the distributed transaction certification system 100.
  • the operation unit 11a includes, for example, a mouse, a keyboard, and a touch panel.
  • the configuration of the operation unit 11a used by the user may be omitted from each of the terminals 21 to 2n. That is, the processor 15a records and holds the pre-defined information for executing the predetermined process in the memory 12a or the data storage unit 13a in order to use the function according to the smart contract function.
  • the processor 15a may automatically execute the predetermined process.
  • the predetermined process is, for example, creation and transmission of an inspection certificate notification described later, but is not limited to this.
  • the memory 12a is configured using, for example, a RAM and a ROM, and temporarily stores programs and data necessary for executing the respective operations of the terminals 21 to 2n, as well as data or information generated during the operation.
  • the RAM is, for example, a work memory used when each of the terminals 21 to 2n operates.
  • the ROM previously stores and holds, for example, programs and data for controlling each of the terminals 21 to 2n.
  • the data storage unit 13a is configured using, for example, an HDD or SSD, and records and holds data or information generated by the processor 15a.
  • the data storage unit 13a records and holds, for example, part or all of the data of the block chains BKC1 and BKC2.
  • the communication circuit 14a is configured by a communication circuit capable of transmitting and receiving data or information to and from the server 1 or each of the vehicles 31 to 3m.
  • the communication circuit 14a sends the data or information to a communication partner (for example, the server 1 or each of the vehicles 31 to 3m).
  • the communication circuit 14a receives data or information sent from a communication partner (see above) and sends it to the processor 15a.
  • the processor 15a is configured using, for example, a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or an FPGA (Field Programmable Gate Array).
  • the processor 15a functions as a controller that controls the overall operation of each of the terminals 21 to 2n, performs control processing for controlling the operation of each of the terminals 21 to 2n, and controls the operation of each of the terminals 21 to 2n. It performs data input / output processing, data calculation (calculation) processing, and data storage processing.
  • Processor 15a operates according to programs and data stored in memory 12a.
  • the processor 15a uses the memory 12a during operation, and temporarily stores data or information generated or obtained by the processor 15a in the memory 12a or records the data or information in the data storage unit 13a. Details of an operation example of the processor 15a will be described later with reference to FIG.
  • FIG. 4 is a block diagram showing an example of the internal configuration of the vehicles 31 to 3m.
  • Each of the vehicles 31 to 3m includes a control unit 40, a camera 41, a LiDAR 42, a millimeter wave radar 43, a group of other sensors 44, a communication circuit 45, and a memory 46.
  • the camera 41, the LiDAR 42, the millimeter-wave radar 43, and the other sensor group 44 are provided for each of the vehicles 31 to 3m for three years or two years as in a vehicle inspection.
  • This is a sensor that is an object of an inspection execution request sent from the server 1 in order to perform an inspection that can be easily performed whenever necessary, instead of performing an inspection every time.
  • Each of the vehicles 31 to 3 m is, for example, a vehicle having an automatic driving level of 1 or more.
  • the camera 41, the LiDAR 42, the millimeter wave radar 43, the other sensor group 44, the communication circuit 45, and the control unit 40 mutually input and output data or information via a vehicle-mounted network such as a CAN (Controller Area Network). Can be connected.
  • a vehicle-mounted network such as a CAN (Controller Area Network). Can be connected.
  • Vehicles 31 to 3m are equipped with a control unit 40 as an example of a controller for controlling automatic driving.
  • the control unit 40 is configured using, for example, an ECU (Electronic Control Unit).
  • the control unit 40 may be configured using a single or a plurality of ECUs.
  • the control unit 40 operates according to the programs and data stored in the memory 46. Specifically, the control unit 40 generates route information in automatic driving based on detection outputs of various sensors (specifically, the camera 41, the LiDAR 42, the millimeter wave radar 43, and the other sensor group 44).
  • the control unit 40 performs automatic operation while controlling equipment to be controlled (see below) according to the generated route information.
  • the automatic driving of each of the vehicles 31 to 3 m is likely to collide with an obstacle (for example, a hole existing on the road, another vehicle, a motorcycle such as a motorcycle, a pedestrian, a guardrail, a telephone pole, a pole, a store or the like).
  • an obstacle for example, a hole existing on the road, another vehicle, a motorcycle such as a motorcycle, a pedestrian, a guardrail, a telephone pole, a pole, a store or the like.
  • a function of operating the brake to stop each of the vehicles 31 to 3 m is included.
  • the automatic driving of each of the vehicles 31 to 3 m includes a function of following the other vehicle running ahead while maintaining a constant interval.
  • the automatic driving of each of the vehicles 31 to 3 m includes a function of controlling the steering of each of the vehicles 31 to 3 m so as not to protrude from the lane.
  • the camera 41 as an example of the sensor is a so-called in-vehicle camera, and has an image sensor such as a CCD (Charge Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor).
  • the camera 41 is installed, for example, at the center of the front of the vehicle body of each of the vehicles 31 to 3 m, and captures an image in a front center range as a detection range.
  • the camera 41 detects an obstacle (see above) or a traffic light existing in front of the host vehicle.
  • the camera 41 can execute image processing using the data of the captured image, and information indicating the relationship between the obstacle detected by the image processing and the own vehicle (for example, the speed of the obstacle based on the own vehicle). And position information), and the position and size of the traffic light and the color of the traffic light.
  • the camera 41 sends the captured image or an image processing result for the captured image to the control unit 40.
  • the LiDAR 42 as an example of the sensor emits a light beam (for example, an infrared laser) around each of the vehicles 31 to 3m, receives a reflected signal thereof, and detects an object existing around the vehicle based on the received reflected signal. The distance from the object (for example, the above-described obstacle), the size of the object, and the composition of the object are measured. The LiDAR 42 sends the measurement result to the control unit 40.
  • a light beam for example, an infrared laser
  • the millimeter wave radar 43 as an example of the sensor radiates radio waves (for example, millimeter waves) around each of the vehicles 31 to 3m, receives a reflected signal thereof, and exists around the vehicle based on the received reflected signal. Measure the distance to the object. The millimeter wave radar 43 sends this measurement result to the control unit 40. The millimeter-wave radar 43 can detect a farther object that is difficult to detect with the LiDAR 42.
  • radio waves for example, millimeter waves
  • the other sensor group 44 is a plurality of sensors mounted in addition to the camera 41, the LiDAR 42, and the millimeter wave radar 43 described above.
  • sensors mounted in addition to the camera 41, the LiDAR 42, and the millimeter wave radar 43 described above.
  • an around-view camera, a GNSS sensor, and a laser range finder correspond.
  • Around view cameras as an example of sensors include a plurality of cameras (for example, two at the front of the vehicle, two at the rear of the vehicle, two at the front of the vehicle, two at the rear of the vehicle, It is configured using two cameras (two on the side).
  • the around-view camera detects a white line near each of the vehicles 31 to 3 m, an adjacent lane, another vehicle, and the like.
  • a GNSS sensor as an example of a sensor receives a plurality of signals indicating times transmitted from a plurality of GPS satellites and a position (coordinate) of each GPS satellite, and based on the received plurality of signals, a GPS receiver. (That is, the respective positions of the vehicles 31 to 3 m) are calculated.
  • the GNSS sensor sends the position information (calculation result) of each of the vehicles 31 to 3 m to the control unit 40.
  • the laser range finder as an example of the sensor is installed on the vehicle front right side, vehicle front left side, vehicle side right side, vehicle side left side, vehicle rear right side, and vehicle rear left side of each of the vehicles 31 to 3 m.
  • the laser range finder detects obstacles (see above) and the like present on the front right, front left, side right, side left, rear right, and rear left of the vehicles 31 to 3 m.
  • the laser range finder irradiates the laser light while scanning it in a certain wide angle range, receives the reflected light, and detects the time difference between the irradiation start time and the reflected light reception time.
  • the distance between the host vehicle and the obstacle and the direction of the obstacle viewed from the host vehicle are detected.
  • the other sensor group 44 is not limited to the above-described around view camera, GNSS sensor, and laser range finder, and includes, for example, a gyro sensor, an acceleration sensor, a geomagnetic sensor, a tilt sensor, a temperature sensor, a pressure sensor, a humidity sensor, and an illuminance sensor. May have. Further, each of the vehicles 31 to 3m does not need to include all of the various sensors described above, and may appropriately include the sensors according to the automatic driving level assigned to each of the vehicles 31 to 3m.
  • the communication circuit 45 is constituted by a communication circuit capable of transmitting and receiving data or information to and from the server 1 or each of the terminals 21 to 2n.
  • the communication circuit 45 sends the data or information generated or obtained by the control unit 40 to the server 1 or each of the terminals 21 to 2n.
  • the communication circuit 45 receives data or information sent from the server 1 or each of the terminals 21 to 2n and sends the data or information to the control unit 40.
  • the memory 46 is configured using, for example, a RAM and a ROM, and temporarily stores programs and data necessary for executing the operation of the control unit 40, and data or information generated during the operation.
  • the RAM is a work memory used when the control unit 40 operates, for example.
  • the ROM previously stores and holds a program and data for controlling the control unit 40, for example.
  • control unit 40 controls equipment to be controlled necessary for automatic driving, such as the accelerator throttle opening of each of the vehicles 31 to 3 m, the braking force of each of the vehicles 31 to 3 m, the steering angle, and the blinking timing of the turn signal.
  • Calculate the control value for The control value is calculated so that the vehicle travels according to the route information generated by the control unit 40, for example.
  • the control unit 40 transmits the calculated control value to an actuator (that is, a steering actuator, an accelerator pedal actuator, a brake actuator, or the like) for driving each device to be controlled (for example, a steering, an accelerator pedal, a brake, a direction indicator).
  • an actuator that is, a steering actuator, an accelerator pedal actuator, a brake actuator, or the like
  • Control target equipment is equipment that is provided in each of the vehicles 31 to 3 m, and is controlled to operate by the control unit 40 during automatic driving of each of the vehicles 31 to 3 m.
  • the control target equipment is, for example, a steering actuator, an accelerator pedal actuator, a brake actuator, and a blinker blinking controller, but is not limited thereto.
  • the steering actuator is connected to the steering arranged in each of the vehicles 31 to 3m, and operates the steering during automatic driving (in other words, the vehicle 31 to 3) according to a steering (not shown) control signal input from the control unit 40. 3m of each traveling direction).
  • the accelerator pedal actuator is connected to an accelerator pedal disposed in each of the vehicles 31 to 3m, and operates the accelerator pedal during automatic driving (in other words, according to a control signal of an accelerator pedal (not shown) input from the control unit 40). , Maintaining or increasing or decreasing the vehicle speed of each of the vehicles 31 to 3 m.
  • the brake actuator is connected to brakes arranged in each of the vehicles 31 to 3m, and operates the brakes during automatic driving (in other words, the vehicles 31 to 3m) according to a brake (not shown) control signal input from the control unit 40. (Maintenance or change of braking) for each 3 m of travel.
  • the blinker blinking controller is connected to a blinker blinking mechanism arranged in each of the vehicles 31 to 3 m, and operates the direction indicator during automatic driving according to a control signal of the blinker blinking mechanism (not shown) input from the control unit 40. (In other words, the blinking of the direction indicator for informing that each of the vehicles 31 to 3m turns left or right) is controlled.
  • FIG. 5 is a diagram illustrating a first configuration example of the block chain.
  • FIG. 6 is a diagram illustrating a second configuration example of the block chain.
  • the block chains BKC1 and BKC2 in FIGS. 5 and 6 have a data structure corresponding to the first use case shown in FIG. 1, and are not limited to the data structure examples shown in FIGS.
  • the block chain BKC1 shown in FIG. 5 links the transaction information relating to the inspection of each of the plurality of vehicles CR1 to CR4 so that the respective transaction information has a chronological relationship (like a daisy chain). Record.
  • the block chain BKC1 has a configuration in which blocks created each time a transaction relating to inspection is performed by each of the plurality of vehicles CR1 to CR4 are connected in chronological order like a chain.
  • a vehicle CR2 block MBL1 having a relation of being created after the previous block PBL1 is created with respect to the previously created previous block PBL1, and the vehicle is vertically moved. Connected (that is, connected). More specifically, a hash value (so-called digest) which is an output of a one-way function (so-called hash function) of the previous block PBL1 created immediately before is held in the vehicle CR2 block MBL1 (see FIG. 7).
  • the vertical direction indicates a time-series direction in which blocks corresponding to vehicles selected as inspection target vehicles in the distributed transaction certification system 100 are connected.
  • the vehicle CR2 block MBL1 relates to the inspection performed by the vehicle CR2 selected as the inspection certificate target vehicle (that is, the sensor inspection target vehicle) in the distributed transaction certification system 100.
  • This is a block having transaction information corresponding to the transaction.
  • a side block having transaction information corresponding to a transaction related to inspection performed by peripheral vehicles other than the inspection target vehicle that is, the vehicles CR1, CR3, and CR4 that support the inspection certification of the vehicle CR2).
  • BL11, BL12, and BL13 are connected in association with each other in the horizontal direction (that is, connected).
  • the side blocks BL11, BL12, BL13 correspond to the vehicle CR1 block, the vehicle CR3 block, and the vehicle CR4 block, respectively.
  • the lateral direction indicates a direction in which blocks corresponding to vehicles selected as peripheral vehicles that support inspection certification of a target vehicle in the distributed transaction certification system 100 are connected.
  • the vehicle CR3 block MBL2 relates to the inspection performed by the vehicle CR3 selected as the target vehicle of the inspection certification (that is, the target vehicle of the sensor inspection) in the distributed transaction certification system 100.
  • This is a block having transaction information corresponding to the transaction.
  • a side block having transaction information corresponding to a transaction related to inspection performed by peripheral vehicles other than the inspection target vehicle that is, the vehicles CR1, CR2, and CR4 that support the inspection certification of the vehicle CR3.
  • BL21, BL22, and BL23 are connected to each other in a horizontal direction (that is, connected).
  • the block chain BKC2 shown in FIG. 6 is similar to the block chain BKC1 shown in FIG. 5 in that the transaction information relating to the inspection of each of the plurality of vehicles CR1 to CR4 is set so that each transaction information has a chronological relationship. Record in a chain (like a rosary).
  • the block chain BKC2 has a configuration in which blocks created each time a transaction relating to inspection is executed by each of the plurality of vehicles CR1 to CR4 are connected in chronological order like a chain.
  • a vehicle CR2 block MBL1a having a relationship of being created after the previous block PBL1a is created with respect to the previously created previous block PBL1a, and the vehicle is vertically moved. Connected (that is, connected). More specifically, a hash value (so-called digest) which is an output of a one-way function (so-called hash function) of the previous block PBL1 created immediately before is held in the vehicle CR2 block MBL1 (see FIG. 7).
  • the vehicle CR2 block MBL1a is a block corresponding to the vehicle CR2 selected as the inspection target vehicle among the plurality of vehicles CR1 to CR4, as in FIG.
  • the vehicle CR2 block MBL1a relates to an inspection performed by peripheral vehicles other than the inspection target vehicle (that is, the vehicles CR1, CR3, and CR4 that support the inspection certificate of the vehicle CR2).
  • the side blocks SBL11, SBL12, and SBL13 having transaction information corresponding to the transaction are held so as to include them.
  • a vehicle CR3 block MBL2a having a relation of being created after the vehicle CR2 block MBL1a is created with respect to the vehicle CR2 block MBL1a and is connected in the vertical direction (that is, connected). More specifically, a hash value (so-called digest) which is an output of a one-way function (so-called hash function) of the vehicle CR2 block MBL1a created immediately before is held in the vehicle CR3 block MBL2a (see FIG. 7). .
  • the vehicle CR3 block MBL2a is a block corresponding to the vehicle CR3 selected as the inspection target vehicle among the plurality of vehicles CR1 to CR4, as in FIG.
  • the vehicle CR3 block MBL2a includes a side block SBL21 having transaction information corresponding to a transaction related to inspection performed by a peripheral vehicle other than the inspection target vehicle (that is, the vehicles CR1, CR2, and CR4 that support the inspection certification of the vehicle CR3). , SBL22, SBL23.
  • FIG. 7 is a diagram showing an example of a data structure of a block constituting a block chain.
  • the vehicle CR2 block MBL1 (see FIG. 5) will be described as an example, but the data structure example in each block is the same.
  • the vehicle CR2 block MBL1 is configured to include a hash value HS1 of the immediately preceding block, a nonce value NS1, and at least one transaction information TR1.
  • the hash value HS1 of the immediately preceding block has a time-series relationship that the vehicle CR2 block MBL1 is created after the block created immediately before (for example, the previous block PBL1 shown in FIG. 5). Show. In other words, the hash value HS1 indicates which block is the block created immediately before the own block.
  • the nonce value NS1 is adjusted so that the hash value HS1 is adjusted to a value smaller than a predetermined value (so-called difficulty @ target) when one of the server 1 and the terminals 21 to 2n newly creates a block. 1 or adjustment data written by any of the terminals 21 to 2n.
  • a predetermined value so-called difficulty @ target
  • the transaction information TR1 includes pre-defined information DF1, target vehicle information TRG1, peripheral vehicle information ASS1, external environment measurement result information SEN1, inspection result information IPE1, and attached information AT1.
  • the pre-defined information DF1 includes information on sensors to be inspected among sensors included in the target vehicle, the number of peripheral vehicles other than the target vehicle, execution contents of transactions related to inspection, and transactions related to inspections performed by the target vehicle and peripheral vehicles. It includes an instruction to compare execution results, and the like.
  • the pre-defined information DF1 is described by the server 1 or each of the terminals 21 to 2n.
  • the target vehicle information TRG1 indicates information (including identification information) on the target vehicle to be inspected selected by the server 1 among the plurality of vehicles 31 to 3m.
  • the target vehicle information TRG1 is described by the server 1 or each of the terminals 21 to 2n.
  • the peripheral vehicle information ASS1 indicates information (including identification information) on peripheral vehicles other than the inspection target vehicle selected by the server 1 among the plurality of vehicles 31 to 3m.
  • the peripheral vehicle information ASS1 is described by the server 1 or each of the terminals 21 to 2n.
  • the external environment measurement result information SEN1 is obtained by measuring a vehicle corresponding to the own block (in the example of FIG. 7, a vehicle CR2 selected as a vehicle to be inspected) as a result of executing a transaction related to the inspection by a sensor provided in the vehicle. Indicates data or information.
  • the external environment measurement result information SEN1 corresponds to terrain information, sign recognition result information, and traffic signal color identification result information existing on the same traveling route in the same area where the target vehicle and surrounding vehicles travel.
  • the external environment measurement result information SEN1 is not limited to terrain information, sign recognition result information, and traffic signal color identification result information.
  • the external environment measurement result information SEN1 is described by each of the server 1 or the terminals 21 to 2n that has received the external environment measurement result information transmitted from the vehicle corresponding to the own block.
  • Inspection result information IPE1 indicates an inspection result that is determined based on a comparison between the execution results of the transactions related to the inspection of the target vehicle and the surrounding vehicles and that indicates the presence or absence of a failure (for example, a failure) of a sensor included in the target vehicle.
  • the inspection result information IPE1 is described by the server 1 or each of the terminals 21 to 2n that determines whether or not there is a failure (for example, a failure) of a sensor included in the target vehicle.
  • the attached information AT1 includes, for example, execution date and time information of a transaction related to inspection, area information, traveling route information, and other block information that is related to the own block.
  • the attached information AT1 may have information (including identification information) on the side block only when the own block includes the side block.
  • FIG. 8 is a flowchart illustrating an example of an operation procedure of the server 1 corresponding to the first use case in a time-series manner. Each process illustrated in FIG. 8 is executed by the processor 15 of the server 1.
  • the server 1 selects a sensor inspection target vehicle from a plurality of vehicles 31 to 3m participating in the distributed transaction certification system 100 (St11). After step St11, the server 1 newly creates a block corresponding to the target vehicle and the surrounding vehicle (see FIG. 5) or the target vehicle (see FIG. 6) and adds (registers) it to the block chains BKC1 and BKC2.
  • the server 1 describes the predefined information DF1, including the inspection details, the target vehicle information TRG1, and the surrounding vehicle information ASS1 in the blocks added on the block chains BKC1, BKC2, or writes the predefined information DF1, the target vehicle information TRG1.
  • one of the terminals 21 to 2n is instructed to describe the surrounding vehicle information ASS1 (St12).
  • the server 1 inquires directly via the network NW1 whether the target vehicle selected in step St11 is activated (for example, ignition is on) or indirectly with other peripheral vehicles. (St13). When the server 1 determines that the target vehicle has not been activated as a response to the inquiry (St13, NO), the server 1 newly adds (registers) a block corresponding to the new target vehicle on the block chains BKC1 and BKC2. It is determined whether or not it is permissible (St14).
  • the server 1 has allowable value information indicating the number of retained unfinished blocks in which the inspection result of the target vehicle corresponding to the once created block is not described (in other words, the inspection certificate is not issued). I have. This permissible value information may be stored in the memory 12, for example.
  • the server 1 adds a new block to the block chains BKC1 and BKC2. Since creation is not possible, the operation of the processor 15 is in a standby state until the target vehicle is started (St14, NO).
  • step St13 when the number of held blocks corresponding to the target vehicle determined not to be activated in step St13 is less than the allowable value corresponding to the allowable value information (St14, YES), the server 1 corresponds to the inspection target. Block is newly created and added (registered) to the block chains BKC1 and BKC2. That is, the process of the server 1 returns to Step St11. In this case, another vehicle is selected as the target vehicle.
  • the server 1 determines that the target vehicle is activated (St13, YES)
  • the server 1 creates an inspection execution request including the predefined information DF1, the target vehicle information TRG1, and the surrounding vehicle information ASS1, and generates an inspection execution request for the target vehicle.
  • Notify (St15).
  • the inspection execution request indicates an instruction to execute a transaction related to the inspection described by the predefined information DF1, which is executed by the target vehicle specified by the target vehicle information TRG1.
  • the target vehicle issues a transaction related to the inspection to the peripheral vehicle based on the peripheral vehicle information ASS1. Is sent (St32).
  • the server 1 receives the external environment measurement result information as the execution result of the transaction related to the inspection from each of the target vehicle and the surrounding vehicles (St16), and stores each external environment measurement result information in the corresponding target of the blockchains BKC1 and BKC2. It is described on the block of the vehicle or surrounding vehicles. As will be described later, the external environment measurement result information for the block may be described not by the server 1 but by any of the terminals 21 to 2n that have received the respective external environment measurement result information (see FIG. 11). ).
  • the server 1 recognizes that the description of the external environment measurement result information has been correctly written on the block chains BKC1 and BKC2 (St17).
  • the server 1 determines whether the inspection of the target vehicle was normal based on the external environment measurement result information described in the blocks corresponding to the target vehicle and the surrounding vehicles of the block chains BKC1 and BKC2 in Step St17 ( St18).
  • the server 1 writes the determination result of Step St18 as the inspection result information IPE1 in the block corresponding to the target vehicle.
  • the server 1 determines that the inspection of the target vehicle is normal. It is determined (St18, YES). In this case, the server 1 issues (creates) an inspection certificate notification as an example of the inspection result information IPE1 and sends it to the target vehicle (St19).
  • the inspection certificate notification indicates the validity that the inspection of the target vehicle was normal due to the consent of the majority of the peripheral vehicles participating in the distributed transaction certification system 100 according to the first embodiment. This is information to be secured.
  • the distributed transaction certification system 100 it is possible to easily and easily issue an inspection certificate of a sensor included in the vehicle between the target vehicle and the surrounding vehicles.
  • a decentralized type that can issue an inspection certificate according to the vehicle inspection certificate as a service of an individual or a private company.
  • the abnormality of the vehicle can be executed in a short cycle, and it can be proved that the vehicle is a normal vehicle (for example, an automatic driving vehicle).
  • the server 1 determines that the number of peripheral vehicles that have obtained the external environment measurement result information that matches the external environment measurement result information of the target vehicle is not the majority of the number of the peripheral vehicles (St18, NO)
  • the server 1 It is determined that the inspection is abnormal.
  • the server 1 creates an abnormality notification as an example of the inspection result information IPE1 (that is, an information notification indicating that the inspection of the target vehicle is abnormal) and sends the notification to the target vehicle.
  • a command that is, a control restriction command for restricting the function (control) of the part or all the sensors is created and sent to the target vehicle (St20).
  • the target vehicle When the target vehicle receives the control restriction command from the server 1, the target vehicle restricts the use of the sensor specified by the control restriction command.
  • a brake assist function for example, a function of operating a brake by detecting a red signal
  • the target vehicle is turned off.
  • the server 1 pays a predetermined reward to some or all of the peripheral vehicles that have obtained the external environment measurement result information that matches the external environment measurement result information of the target vehicle (St21).
  • the predetermined reward is, for example, a virtual currency of a prescribed fee or a prescribed point value.
  • FIG. 9 is a flowchart showing an example of an operation procedure of the target vehicle (vehicle) in a time series. Each process shown in FIG. 9 is executed by the control unit 40 of the target vehicle (that is, one of the vehicles 31 to 3m).
  • FIG. 10 is a flowchart illustrating an example of an operation procedure of a surrounding vehicle (that is, a vehicle) in chronological order. Each process illustrated in FIG. 10 is executed by the control unit 40 of a peripheral vehicle other than the target vehicle.
  • FIG. 11 is a flowchart illustrating an example of an operation procedure of the terminals 21 to 2n in a time series. Each process shown in FIG. 11 is executed by the processor 15a of at least one of the terminals 21 to 2n.
  • FIG. 10 is a flowchart showing an example of an operation procedure of the target vehicle (vehicle) in a time series. Each process shown in FIG. 9 is executed by the control unit 40 of the target vehicle (that is, one of the vehicles 31 to 3m).
  • FIG. 10
  • FIG. 12 is a sequence diagram illustrating, in a time series, an operation procedure example of the external environment measurement in the surrounding vehicles.
  • FIG. 13 is a sequence diagram showing, in chronological order, an operation procedure example of the external environment measurement in the server 1 or the terminals 21 to 2n.
  • the comparison of the external environment measurement result information measured by the target vehicle and the surrounding vehicle is based on a pattern executed by the surrounding vehicle (see FIG. 12) and each of the server 1 or the terminals 21 to 2n (see FIG. 13). There is a pattern to be executed (see FIG. 13). For this reason, an example described with reference to FIGS. 9 and 10 as appropriate in the description of FIG. 12 and an example described with reference to FIGS. 9 and 10 as appropriate in the description of FIG. 13 will be given.
  • the server 1 creates an inspection execution request and notifies the target vehicle (St15).
  • the target vehicle receives the inspection execution request (see FIG. 8) sent from the server 1 (St31).
  • the target vehicle notifies the nearby vehicle of the acquired information comparison request, and sends the external environment measurement result information measured by the sensor included in the own vehicle to the nearby vehicle (St32).
  • the acquisition information comparison request instructs comparison between the external environment measurement result information obtained by the target vehicle and the external environment measurement result information obtained by the surrounding vehicles.
  • the surrounding vehicle executes a transaction related to inspection based on the acquired information comparison request to measure external environment information (St61).
  • the surrounding vehicle can obtain the external environment measurement result information, and can compare the external environment measurement result information obtained by the own vehicle (that is, the surrounding vehicle) with the external environment measurement result information obtained by the target vehicle ( St62).
  • the surrounding vehicle sends the comparison result to each of the server 1 and the terminals 21 to 2n (St42).
  • the server 1 creates an inspection certificate notification, an abnormality notification, or a control restriction command and sends it to the target vehicle as an inspection result notification (St63).
  • the target vehicle receives the inspection certificate notification or the abnormality notification sent from the server 1 or the command (that is, the control restriction command) for restricting the function (control) of some or all of the sensors included in the target vehicle (that is, the control restriction command). St33). After step St33, the processing of the target vehicle returns to step St31, and the processing of steps St31 to St33 is repeated.
  • the server 1 pays a predetermined reward to some or all of the peripheral vehicles that have obtained the external environment measurement result information that matches the external environment measurement result information of the target vehicle (St21).
  • the surrounding vehicle receives a predetermined reward from the server 1 when obtaining the external environment measurement result information that matches the external environment measurement result information of the target vehicle (St43).
  • the server 1 creates an inspection execution request and notifies the target vehicle (St15).
  • the target vehicle receives the inspection execution request (see FIG. 8) sent from the server 1 (St31).
  • the target vehicle notifies the surrounding vehicle of the acquired information comparison request and sends the external environment measurement result information measured by the sensor included in the own vehicle to each of the server 1 and the terminals 21 to 2n (St32).
  • the surrounding vehicle When the surrounding vehicle receives the acquired information comparison request sent from the target vehicle (St41), the surrounding vehicle executes a transaction related to inspection based on the acquired information comparison request to measure external environment information (St61). The surrounding vehicle sends the external environment measurement result information measured in step St61 to each of the server 1 and the terminals 21 to 2n (St42).
  • the server 1 When the server 1 receives the external environment measurement result information sent from each of the target vehicle and the surrounding vehicles, the server 1 compares them to determine the inspection result of the target vehicle by comparing them (St62a). The server 1 creates an inspection certificate notification, an abnormality notification, or a control restriction command and sends it to the target vehicle as an inspection result notification (St63). The target vehicle receives the inspection certificate notification or the abnormality notification sent from the server 1 or the command (that is, the control restriction command) for restricting the function (control) of some or all of the sensors included in the target vehicle (that is, the control restriction command). St33). After step St33, the processing of the target vehicle returns to step St31, and the processing of steps St31 to St33 is repeated.
  • the server 1 pays a predetermined reward to some or all of the peripheral vehicles that have obtained the external environment measurement result information that matches the external environment measurement result information of the target vehicle (St21).
  • the surrounding vehicle receives a predetermined reward from the server 1 when obtaining the external environment measurement result information that matches the external environment measurement result information of the target vehicle (St43).
  • At least one of the terminals 21 to 2n receives the predefined information DF1 sent from the server 1 (St51). At least one of the terminals 21 to 2n receives the external environment measurement result information transmitted from the target vehicle and the surrounding vehicles and measured respectively (St52).
  • one of the terminals 21 to 2n that can be described in the block chains BKC1 and BKC2 is the external environment measurement result information transmitted from the target vehicle and the surrounding vehicles received in step St52, respectively. Is described in the corresponding block of the block chains BKC1 and BKC2 (St53). Alternatively, one of the terminals 21 to 2n that can be described in the block chains BKC1 and BKC2 creates a block to be added to the block chains BKC1 and BKC2 as necessary (St53).
  • One of the terminals 21 to 2n which can be described in the block chains BKC1 and BKC2, receives a predetermined reward sent from the server 1 when creating a block to be added to the block chains BKC1 and BKC2 in step St53. (St54).
  • the server 1 and each of the plurality of vehicles 31 to 3m are communicably connected.
  • the server 1 holds block chains BKC1 and BKC2 that record transaction information on inspections of a plurality of vehicles in a chain.
  • the server 1 selects a vehicle to be inspected from a plurality of vehicles, creates transaction information relating to the inspection of the selected target vehicle in the blockchain, and sends an instruction to execute the transaction relating to the inspection to the target vehicle.
  • the target vehicle executes a transaction relating to the inspection based on the execution instruction, and sends an instruction to execute the transaction relating to the inspection to peripheral vehicles other than the target vehicle.
  • the server 1 registers the inspection result based on the execution result of the transaction relating to the inspection of each of the target vehicle and the surrounding vehicle in the created transaction information relating to the inspection of the target vehicle.
  • the distributed transaction certification system 100 can manage the execution result of the transaction relating to the inspection of the failure of the sensor mounted on each of a plurality of familiar vehicles and the detection result of the presence or absence of the failure of the sensor in the blockchains BKC1 and BKC2. . Therefore, according to the distributed transaction certification system 100, the validity of the transaction executed in each vehicle participating in the distributed transaction certification system 100 can be ensured accurately. Further, since transaction information related to inspection is recorded in the block chains BKC1 and BKC2, a target vehicle selected based on the block chains BKC1 and BKC2 from a plurality of familiar vehicles executes a transaction related to inspection. Tampering can be prevented, and the validity of the inspection results for the target vehicle can be ensured. Further, transaction information on inspections performed by not only the target vehicle but also peripheral vehicles is recorded on the blockchains BKC1 and BKC2, so that the inspection result of the target vehicle can be prevented from being falsified.
  • the processor 15 of the server 1 selects a target vehicle based on the block chains BKC1 and BKC2.
  • the server 1 can select, for example, vehicles that have not been inspected for a certain period of time and select them as target vehicles based on the block chains BKC and BKC2 in which the execution histories of the transactions related to the previous inspections are recorded in a chain. .
  • the processor 15 of the server 1 creates information indicating that the inspection result is normal as a result of the inspection when the majority of the peripheral vehicles whose execution results coincide with the execution result of the transaction relating to the inspection of the target vehicle are measured.
  • the majority of the surrounding vehicles other than the target vehicle agree (that is, the same external environment measurement result information is obtained). The validity of the inspection certificate for the target vehicle is easily ensured.
  • the processor 15 of the server 1 receives the execution result of the transaction related to the inspection of the target vehicle and the surrounding vehicle, and based on the comparison of the execution results, determines the execution result that matches the execution result of the transaction related to the inspection of the target vehicle. It is determined whether or not the number of the peripheral vehicles measured is a majority. As a result, the server 1 determines whether the external environment measurement result information obtained by the majority of the peripheral vehicles among the (m-1) peripheral vehicles participating in the distributed transaction certification system 100 is the same. By simply doing so, the effectiveness of the inspection of the target vehicle can be easily ensured.
  • the processor 15 of the server 1 receives the comparison result of the transaction execution results related to the respective inspections of the target vehicle and the surrounding vehicles, and measures the execution result that matches the transaction execution result related to the target vehicle inspection based on the comparison result. It is determined whether or not the number of peripheral vehicles that have been made is a majority. As a result, the server 1 compares whether the external environment measurement result information obtained by the majority of the peripheral vehicles among the (m-1) peripheral vehicles participating in the distributed transaction certification system 100 is the same. Just by judging the result, the effectiveness of the inspection of the target vehicle can be easily ensured.
  • the processor 15 of the server 1 creates information indicating that the inspection result is abnormal. As a result, the server 1 merely determines that the external environment measurement result information obtained by the majority of the peripheral vehicles among the (m-1) peripheral vehicles participating in the distributed transaction certification system 100 is not the same. Thus, it can be easily determined that the inspection of the target vehicle is abnormal.
  • the processor 15 of the server 1 sends a command to restrict the use of the function of the target vehicle relating to the abnormality to the target vehicle via the communication circuit 14. Thereby, the server 1 makes the target vehicle refrain from using the sensor specified by the control restriction command during the automatic driving, for example, so that the probability that the target vehicle causes a traffic violation or a traffic accident can be reduced.
  • the processor 15 of the server 1 gives a predetermined reward to a majority of the peripheral vehicles whose execution results coincide with the execution results of the transaction relating to the inspection of the target vehicle. As a result, incentives for surrounding vehicles are guaranteed, so that the significance of the vehicle participating in the distributed transaction certification system 100 is appropriately improved.
  • Each of the vehicles 31 to 3m is a vehicle constituting the distributed transaction certification system 100 including the server 1, and the server 1 holding block chains BKC1 and BKC2 for sequentially recording transaction information related to vehicle inspection. And a communication circuit 45 that communicates with.
  • Each of the vehicles 31 to 3m has a control unit 40 for controlling operations including driving of the own vehicle.
  • the communication circuit 45 receives an instruction to execute a transaction related to the check.
  • the control unit 40 controls the execution of the transaction related to the inspection based on the execution instruction, and outputs the execution result of the transaction related to the inspection in the own vehicle and the execution result of the transaction related to the inspection in another vehicle (that is, a plurality of peripheral vehicles). Based on the result of the inspection, the operation including the operation of the own vehicle is controlled.
  • a centralized type that issues a certificate of vehicle inspection completion at the existing vehicle inspection area to a decentralized type that can issue an inspection certificate according to the vehicle inspection certificate as a service of an individual or a private company.
  • the abnormality of the vehicle can be executed in a short cycle, and it can be proved that the vehicle is a normal vehicle (for example, an automatic driving vehicle).
  • Each of the vehicles 31 to 3m further has at least one sensor to be checked.
  • the control unit 40 receives the measurement result of the surrounding external environment information by the sensor during the traveling of the predetermined traveling route as a transaction related to the inspection.
  • each of the vehicles 31 to 3m measures the same surrounding external environment information on the same traveling route in both the target vehicle and the surrounding vehicles, so that the target vehicle can be easily inspected.
  • FIG. 14 is an explanatory diagram showing an example of an operation outline of the second use case of the distributed transaction certification system 100.
  • FIG. 15 is a flowchart illustrating an example of an operation procedure of the server corresponding to the second use case in chronological order.
  • FIG. 16 is an explanatory diagram illustrating an example of updating map data.
  • the other use case is changed to another peripheral vehicle.
  • An inquiry is made as to whether a similar event can be detected.
  • An example of the event is detection of an obstacle that does not exist in the map data (that is, is not registered as data), but is not limited thereto. If it is found that a majority of the surrounding vehicles have detected a similar event, information on the obstacle is additionally registered on the map data, and a series of transaction information is stored in the blockchain as in the first use case. Registered in BKC1 and BKC2.
  • each of the vehicles 31 to 3m participating in the distributed transaction certification system 100 records and retains the above-described map data in the memory 46.
  • the vehicle CR1 detects an obstacle that does not exist in the map data (that is, is not registered as data) (for example, a hole OB1 generated on a road) (St71).
  • the vehicle CR1 is traveling ahead of the other vehicles CR2, CR3, CR4, and the traveling state of the vehicles CR1 to CR4 is recognized by the server 1.
  • Vehicle CR1 reports to server 1 that an obstacle (for example, hole OB1) has been detected.
  • the server 1 inquires the vehicles following the vehicle CR1 (that is, the vehicles CR2 to CR4) about the authenticity of the detection report of the obstacle from the vehicle CR1 based on the report from the vehicle CR1. (St72).
  • Each of the vehicles CR2 to CR4 detects the presence or absence of an obstacle (for example, a hole OB1) in response to an inquiry request from the server 1, and reports the detection result to the server 1. For example, it is assumed that vehicles CR2 and CR4 can detect hole OB1, while vehicle CR3 cannot detect hole OB1.
  • an obstacle for example, a hole OB1
  • the server 1 obtains a majority of normal detection results based on the reports of the vehicles CR1 to CR4 (in other words, a case in which the majority of vehicles have obtained detection results that match the detection results of the vehicle CR1).
  • the vehicle CR1 registers the information in the block chains BKC1 and BKC2 (St74) and updates the map data for newly adding information on an obstacle (for example, the hole OB1).
  • the map data MPD1 before the update holds the obstacle data MP1 and MP2 of the obstacles existing on the map.
  • Step St73 the obstacle data newly detected at Step St71.
  • Obstacle data MP3 relating to an object is newly added.
  • the obstacle data MP3 added to the updated map data MPD1a includes, for example, point information (that is, position information) of the hole OB1, an obstacle type, and area information indicating the size of the obstacle.
  • the server 1 may temporarily suspend updating of map data (see above) for the vehicle CR3 for which a detection result matching the detection result of the vehicle CR1 cannot be obtained.
  • the server 1 recognizes the possibility that a failure (for example, a failure) has occurred in a sensor mounted on the vehicle CR3 (St73).
  • the server 1 or each of the terminals 21 to 2n creates transaction information corresponding to each transaction of the vehicles CR1 to CR4 (that is, detection and confirmation of the hole OB1 that does not exist in the map data) and generates the block chain BKC1. , BKC2 (St74).
  • the server 1 pays a predetermined reward to the vehicles (specifically, the vehicles CR2 and CR4) that can detect the obstacle (for example, the hole OB1) (St74).
  • the server 1 After recognizing the possibility that a failure (for example, a failure) has occurred in a sensor mounted on the vehicle CR3, the server 1 sends a control restriction command to refrain from using the vehicle CR3 to the vehicle CR3, and As in the use case, the vehicle CR3 is selected as a vehicle to be checked (St74). When receiving the control restriction command from the server 1, the vehicle CR 3 creates an inspection request and sends it to the server 1. Note that the processing when the vehicle CR3 is selected as the inspection target vehicle is the same as in the first use case described above, and a description thereof will be omitted.
  • FIG. 15 Each process shown in FIG. 15 is executed by the processor 15 of the server 1.
  • the description of the operations of the target vehicle, the surrounding vehicles, and the terminals 21 to 2n according to the second use case the description of the same contents as in the first use case will be simplified or omitted, and different contents will be described.
  • the same processing as the operation of the server 1 according to the first use case is assigned the same step number, and the description will be simplified or omitted, and different contents will be described.
  • the server 1 determines whether a vehicle inspection request has been received from a plurality of vehicles 31 to 3m participating in the distributed transaction certification system 100 (St81). In the example illustrated in FIG. 14, an inspection request is sent to the server 1 from the vehicle CR3 that has failed to detect the hole OB1. When the server 1 does not receive the inspection request for the vehicle (St81, NO), the server 1 selects the inspection target vehicle based on the block chains BKC1 and BKC2 as in the first use case (St11).
  • the server 1 when the server 1 receives the vehicle inspection request (St81, YES), the server 1 requests the inspection (vehicle CR3 in the example of FIG. 14) and other peripheral vehicles (vehicles CR1 and CR2 in the example of FIG. 14). , CR4) are newly created and added (registered) to the block chains BKC1 and BKC2.
  • the server 1 describes, in the block added on the block chains BKC1 and BKC2, the pre-defined information DF1, the target vehicle information TRG1, and the surrounding vehicle information ASS1 including the request contents of the sensors to be inspected, or the like.
  • One of the terminals 21 to 2n is instructed to describe the definition information DF1, the target vehicle information TRG1, and the surrounding vehicle information ASS1 (St82). After step St82, the process of server 1 proceeds to step St13.
  • step St13 if the number of blocks held in the block corresponding to the target vehicle, which is determined not to be activated in step St13, does not reach the allowable value corresponding to the allowable value information (St14, YES), the server 1 performs the other operations. It is determined whether an inspection request has been received from the vehicle (St81).
  • the processor 15 of the server 1 determines whether any one of a plurality of vehicles detects an event. An inquiry is made to surrounding vehicles other than the vehicle via the communication circuit 14 as to whether or not the event can be detected. The processor 15 sends an instruction to register data corresponding to the event to each of the plurality of vehicles via the communication circuit 14 based on the normal detection notification of the majority of the events.
  • the credibility of the detection result can be confirmed using a plurality of familiar vehicles upon detection of the event, and when the credibility is obtained, Unregistered data that is not known until before the detection of is detected can be properly registered.
  • the validity of the inspection result on the target vehicle is secured.
  • the processor 15 of the server 1 selects a vehicle that cannot detect an event as a target vehicle.
  • a sensor failure for example, a failure
  • the server 1 early sets a vehicle suspected of having a failure as a target vehicle for inspection. it can.
  • the event is to detect an obstacle that does not exist in the map data held by each of the plurality of vehicles.
  • the processor 15 of the server 1 receives the information on the obstacle that does not exist in the map data, and sends an instruction to update the information on the obstacle to the map data to each of the plurality of vehicles via the communication circuit 14.
  • the distributed transaction certification system 100 when an obstacle that does not exist in the map data is found, information on the obstacle is promptly registered.
  • the shape of the road and the like can be grasped safely, and the probability of occurrence of a traffic accident or a traffic violation can be adaptively reduced.
  • the server 1 and the terminals 21 to 2n constituting the distributed transaction certification system 100 are described to have different roles.
  • the server 1 and the terminals 21 to 2n have the same role.
  • the server 1 may be operated as a terminal similar to the terminals 21 to 2n, and any one of the terminals 21 to 2n may be operated similarly to the server 1.
  • there is no device having a special authority (role) like the server 1 and the server 1 and the terminals 21 to 2n that constitute the distributed transaction certification system 100 have the same authority, so that equality is achieved.
  • a distributed transaction certification system 100 can be configured.
  • the present disclosure manages, with a blockchain, the execution result of a transaction related to inspection of a failure of a sensor mounted on each of a plurality of familiar vehicles and the detection result of the presence / absence of a failure of a sensor.
  • the present invention is useful as a server, a vehicle, a distributed transaction proof system, and a distributed transaction proof method that properly guarantee the validity.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Atmospheric Sciences (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Traffic Control Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

サーバは、複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持し、複数の車両の中から点検の対象車両を選定し、選定された対象車両の点検に関するトランザクション情報をブロックチェーンに追加し、点検に関するトランザクションの実行指示を対象車両に送る。サーバは、実行指示に基づく対象車両における点検に関するトランザクションの実行結果と、対象車両以外の周辺車両における点検に関するトランザクションの実行結果とに基づく点検結果を、追加された対象車両の点検に関するトランザクション情報に登録する。

Description

サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法
 本開示は、サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法に関する。
 近年、自動運転が可能な自動運転車両が普及しつつある。このような自動運転車両には、自動運転中に周囲の外部環境情報をリアルタイムに測定するために、複数のセンサが搭載されている。センサは、例えば、カメラ、ミリ波レーダ、LiDAR(Light Detection and Ranging, Laser Imaging Detection and Ranging)、GNSS(Global Navigation Satellite System)センサ等である。このようなセンサを用いて外部環境情報を判定する技術も各種提案されている。
日本国特開2016-105081号公報 日本国特開2018-017103号公報
 自動運転車両では、上述した各種のセンサが検知して得た測定結果に基づいて自動運転の制御が実行される。このため、例えば自動運転中にセンサに不具合が発生すると、交通違反あるいは交通事故が発生する可能性が高まる。ところが、現状の自動車検査登録制度(いわゆる車検制度)の下では、例えば通常の乗用車では3年あるいは2年ごとの車検期間が設定されているので、この車検期間が早まるような対応は現時点で見込むことは難しい。また、センサに不具合が発生した場合等において自動運転車両の車検場への移動や検査には時間がかかるので、その間に自動運転車両が使用できず、使用効率が悪くなるという課題もある。
 本開示は、上述した従来の事情に鑑みて案出され、身近な複数の車両のそれぞれに搭載されたセンサの不具合の点検に関するトランザクションの実行結果およびセンサの不具合の有無の検出結果を管理し、それぞれの車両で実行されたトランザクションの有効性を的確に担保するサーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法を提供することを目的とする。
 本開示は、複数の車両を含む分散型トランザクション証明システムを構成するサーバであって、前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持するメモリと、前記複数の車両の中から点検の対象車両を選定し、選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに追加するプロセッサと、前記点検に関するトランザクションの実行指示を前記対象車両に送る通信回路と、を備え、前記プロセッサは、前記実行指示に基づく前記対象車両における前記点検に関するトランザクションの実行結果と、前記対象車両以外の周辺車両における前記点検に関するトランザクションの実行結果とに基づく点検結果を、追加された前記対象車両の点検に関するトランザクション情報に登録する、サーバを提供する。
 また、本開示は、サーバを含む分散型トランザクション証明システムを構成する車両であって、前記車両の点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持する前記サーバとの間で通信する通信回路と、自車両の運転を含む動作を制御する制御部と、を備え、前記自車両が点検の対象車両として選定された場合に、前記通信回路は、前記点検に関するトランザクションの実行指示を受け取り、前記制御部は、前記実行指示に基づく前記点検に関するトランザクションの実行を制御し、前記自車両における前記点検に関するトランザクションの実行結果と他車両における前記点検に関するトランザクションの実行結果とに基づく点検結果に基づき、前記自車両の運転を含む動作を制御する、車両を提供する。
 また、本開示は、サーバと複数の車両とが通信可能に接続された分散型トランザクション証明システムであって、前記サーバは、前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持し、前記複数の車両の中から点検の対象車両を選定し、選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに作成するとともに、点検に関するトランザクションの実行指示を前記対象車両に送り、前記対象車両は、前記実行指示に基づいて前記点検に関するトランザクションを実行するとともに、前記点検に関するトランザクションの実行指示を前記対象車両以外の周辺車両に送り、前記サーバは、前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果に基づく点検結果を、作成された前記対象車両の点検に関するトランザクション情報に登録する、分散型トランザクション証明システムを提供する。
 また、本開示は、サーバと複数の車両とが通信可能に接続された分散型トランザクション証明システムを用いた分散型トランザクション証明方法であって、前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持するステップと、前記複数の車両の中から点検の対象車両を選定するステップと、選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに作成するとともに、点検に関するトランザクションの実行指示を前記対象車両に送るステップと、前記実行指示に基づいて前記点検に関するトランザクションを実行するとともに、前記点検に関するトランザクションの実行指示を前記対象車両以外の周辺車両に送るステップと、前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果に基づく点検結果を、作成された前記対象車両の点検に関するトランザクション情報に登録するステップと、を有する、分散型トランザクション証明方法を提供する。
 なお、以上の構成要素の任意の組合せ、本開示の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本開示の態様として有効である。
 本開示によれば、身近な複数の車両のそれぞれに搭載されたセンサの不具合の点検に関するトランザクションの実行結果およびセンサの不具合の有無の検出結果を管理でき、それぞれの車両で実行されたトランザクションの有効性を的確に担保できる。
分散型トランザクション証明システムの第1ユースケースの動作概要例を示す説明図 分散型トランザクション証明システムのシステム構成例を示す図 サーバおよび端末の内部構成例を示すブロック図 車両の内部構成例を示すブロック図 ブロックチェーンの第1構成例を示す図 ブロックチェーンの第2構成例を示す図 ブロックチェーンを構成するブロックのデータ構造例 第1ユースケースに対応したサーバの動作手順例を時系列に示すフローチャート 対象車両(車両)の動作手順例を時系列に示すフローチャート 周辺車両(車両)の動作手順例を時系列に示すフローチャート 端末の動作手順例を時系列に示すフローチャート 周辺車両における外部環境測定の動作手順例を時系列に示すシーケンス図 サーバあるいは端末における外部環境測定の動作手順例を時系列に示すシーケンス図 分散型トランザクション証明システムの第2ユースケースの動作概要例を示す説明図 第2ユースケースに対応したサーバの動作手順例を時系列に示すフローチャート 地図データの更新例を示す説明図
 以下、添付図面を適宜参照しながら、本開示に係るサーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法の構成および作用を具体的に開示した実施の形態を詳細に説明する。但し、必要以上に詳細な説明は省略する場合がある。例えば、既によく知られた事項の詳細説明や実質的に同一の構成に対する重複説明を省略する場合がある。これは、以下の説明が不必要に冗長になることを避け、当業者の理解を容易にするためである。なお、添付図面及び以下の説明は、当業者が本開示を十分に理解するために提供されるものであって、これらにより特許請求の範囲に記載の主題を限定することは意図されていない。
 実施の形態1では、分散型トランザクション証明システムのユースケースとして、2つのユースケースを例示して説明する。
 第1ユースケースでは、分散型トランザクション証明システムは、複数台の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持して管理し、このブロックチェーンに基づいて、複数台の車両の中から点検の対象車両を選定する。分散型トランザクション証明システムは、ブロックチェーン技術を用いて、対象車両ならびに他の周辺車両における点検に関するトランザクションのそれぞれの実行結果に基づく点検結果を判定し、その判定結果をブロックチェーンに登録する。これにより、分散型トランザクション証明システムによれば、身近な複数台の車両の中からブロックチェーンに基づいて選定された対象車両が点検に関するトランザクションを実行した結果に対して改ざん防止が可能となるので、対象車両における点検結果の有効性が担保される。
 第2ユースケースでは、分散型トランザクション証明システムは、第1ユースケースと同様に、複数台の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持して管理する。分散型トランザクション証明システムは、いずれかの車両がイベント(後述参照)を検知したことを契機に、他の周辺車両に同様なイベントの検知ができるか否かを問い合わせ、過半数の正常検知結果を得た場合に、そのイベントに対応するデータを新たに登録するとともにブロックチェーンに登録する。分散型トランザクション証明システムは、正常に検知できなかった車両を点検の対象車両として選定する。選定以降の処理は、第1ユースケースと同様である。これにより、分散型トランザクション証明システムによれば、イベントの検知を契機としてその検知結果の信憑性を身近な複数台の車両を用いて確認でき、信憑性の存在が得られた場合に、イベントの検知前まで知られていない未登録データを適正に登録できる。また、対象車両における点検に関するトランザクションの実行結果の改ざん防止が可能となるので、対象車両における点検結果の有効性が担保される。
(第1ユースケース)
 図1は、分散型トランザクション証明システム100の第1ユースケースの動作概要を示す説明図である。図2は、分散型トランザクション証明システム100のシステム構成例を示す図である。
 図2を参照して後述するが、実施の形態1に係る分散型トランザクション証明システム100には、複数台の車両31,…,3m(m:3以上の整数)が参加している。それぞれの車両31~3mは、自動運転が可能な車両であり、自動運転を行うために自車両の周囲の外部環境情報を測定可能な少なくとも1つのセンサ(図4参照)を搭載している。
 このようなセンサに不具合(例えば故障等の異常)が存在していると、自動運転中に車両が交通違反あるいは交通事故を起こす可能性が高まる。ところが、現状の自動車検査登録制度(いわゆる車検制度)の下では、例えば通常の乗用車では3年あるいは2年ごとの車検期間が設定されているので、この車検期間が早まるような対応は現時点で見込むことは難しい。また、センサに不具合が発生した場合等において車両の車検場への移動や検査には時間がかかるので、その間に車両が使用できず、使用効率が悪くなるという課題もある。
 そこで、実施の形態1では、分散型トランザクション証明システム100に参加している複数台の車両31~3m(身近な複数台の車両の一例)のそれぞれは、上述した車検のような公的な検査に比べて手軽な点検を受けられるように、点検の対象車両となることができる。具体的に、点検の対象は、例えば車両に搭載されるセンサである。点検の対象車両は、合計m台の車両のうち1台である。残りの(m-1)台の車両は、対象車両の点検を支援するための役割を有する周辺車両である。
 図1において、先ず、点検の対象車両が選定される(St1)。図1では、合計4台の車両CR1,CR2,CR3,CR4が分散型トランザクション証明システム100に参加している例が示され、対象車両として車両CR2が選定されている。対象車両(つまり、車両CR2)は、点検に関するトランザクションとして、同一エリアの同一走行ルート上を走行するとともに、その走行中に周囲の外部環境情報を、自車両に搭載されているセンサにより測定する(St1)。また、対象車両(つまり、車両CR2)は、前後の周辺車両(つまり、車両CR1,CR3,CR4)に、自車両の外部環境測定結果情報を送り、その外部環境測定結果情報が正しいか否かを問いかける。例えば、対象車両(つまり、車両CR2)は、「私の認識合っていますか?」等の問いかけを行う。なお、車両CR1~CR4は、例えばV2V(Vehicle to Vehicle)により互いに通信可能である。
 それぞれの周辺車両(つまり、車両CR1,CR3,CR4)は、対象車両(つまり、車両CR2)からの問いかけに応じて、点検に関するトランザクションとして、対象車両(つまり、車両CR2)と同一エリアの同一走行ルート上を走行するとともに、その走行中に周囲の外部環境情報を、それぞれの自車両に搭載されているセンサにより測定する(St2)。なお、それぞれの周辺車両(つまり、車両CR1,CR3,CR4)は、対象車両(つまり、車両CR2)から受け取った外部環境測定結果情報と、それぞれ自車両の測定により得た外部環境測定結果情報とを比較し、その結果を応答してよい。例えば、周辺車両(つまり、車両CR1,CR4)は、「測定したけど合っているよ」と応答する。一方、周辺車両(つまり、車両CR3)は、「測定したけど間違っているよ」と応答する。
 それぞれの周辺車両(つまり、車両CR1,CR3,CR4)は、それぞれの自車両における比較結果をサーバ1(図2参照)に報告する(St3)。サーバ1は、周辺車両(つまり、車両CR1,CR3,CR4)のそれぞれからの比較結果の報告を受け取り、過半数(つまり、(m-1)の過半数)の同意から対象車両(つまり、車両CR2)の外部環境測定結果情報が正しいことを認識する。サーバ1は、対象車両(つまり、車両CR2)の点検は正常であった旨の情報をブロックチェーンBKC1,BKC2上に登録する(St3)。また、サーバ1は、対象車両(つまり、車両CR2)に対し、対象車両(つまり、車両CR2)の点検が正常である旨を証明するための通知(つまり、点検証明通知)を送る(St3)。これにより、対象車両(つまり、車両CR2)は、サーバ1により自車両の点検が正常であることの証明を手軽に得たことになり、点検の対象となったセンサの使用継続が可能となる。
 サーバ1から、それぞれの周辺車両(つまり、車両CR1,CR3,CR4)のうち対象車両(つまり、車両CR2)の外部環境測定結果情報と一致する外部環境測定結果情報を得た周辺車両(つまり、車両CR1,CR4)に対し、所定の報酬が渡される(St4)。また、例えばサーバ1により、それぞれの周辺車両(つまり、車両CR1,CR3,CR4)の点検に関するトランザクション情報がブロックチェーンBKC1,BKC2に登録される(St4)。対象車両(つまり、車両CR2)の外部環境測定結果情報と一致する外部環境測定結果情報を得ることができなかった周辺車両(つまり、車両CR3)は、例えば、次回の点検の対象車両としてサーバ1により選定される(St4)。点検の対象車両が選定されると、図1のステップSt2,St3,St4の処理が繰り返される。
 次に、図2を参照して分散型トランザクション証明システム100の構成について説明する。実施の形態1に係る分散型トランザクション証明システム100は、サーバ1と、端末21,…,2n(n:2以上の整数)と、車両31,…,3m(m:3以上の整数)とを含む構成である。言い換えると、m台の車両31~3mは、ブロックチェーンBKC1,BKC2を管理するサーバ1あるいは端末21~2nを有する、分散型トランザクション証明システム100に参加している。
 サーバ1と、端末21~2nと、車両31~3mとは、互いにネットワーク網NW1を介して通信可能に接続される。ネットワーク網NW1は、無線LAN(Local Area Network)等の無線ネットワーク、あるいは有線LAN等の有線ネットワークとして形成される。
 サーバ1は、例えばデスクトップ型PC(Personal Computer)、ノートPC、高速な情報処理能力を有するスマートフォンあるいはタブレット端末等、のような情報処理装置を用いて構成される。サーバ1の内部構成は端末21~2nのそれぞれと同様である(図3参照)。サーバ1は、複数の車両31~3mのそれぞれの点検に関するトランザクション情報(図7参照)を連鎖的に記録(登録)するブロックチェーンBKC1,BKC2(図5,図6参照)の一部あるいは全部のデータを保持し、このブロックチェーンBKC1,BKC2にブロック(図7参照)を新たに作成して追加することができる。また、サーバ1は、複数の車両31~3mのそれぞれが行う、点検に関するトランザクションの実行を、端末21~2nのそれぞれと連携して統括的に制御する。サーバ1の内部構成の詳細については、図3を参照して後述する。
 端末21~2nのそれぞれは、例えばデスクトップ型PC、ノートPC、高速な情報処理能力を有するスマートフォンあるいはタブレット端末等、のような情報処理装置を用いて構成される。端末21~2nのそれぞれの内部構成はサーバ1と同様である(図3参照)。端末21~2nのそれぞれは、複数の車両31~3mのそれぞれの点検に関するトランザクション情報(図7参照)を連鎖的に記録(登録)するブロックチェーンBKC1,BKC2(図5,図6参照)の一部あるいは全部のデータを保持し、このブロックチェーンBKC1,BKC2にブロック(図7参照)を新たに作成して追加することができる。また、端末21~2nのそれぞれは、複数の車両31~3mのそれぞれが行う、点検に関するトランザクションの実行を、サーバ1と連携して補足的に制御する。端末21~2nの内部構成の詳細については、図3を参照して後述する。
 車両31~3mのそれぞれは、自動運転が可能な車両であり、自動運転を行うために自車両の周囲の外部環境情報を測定可能な少なくとも1つのセンサ(図4参照)を搭載している。詳細は図4を参照して説明するが、車両31~3mのそれぞれは、センサとして、カメラ41、LiDAR42、ミリ波レーダ43、その他センサ群44を搭載し、これらのセンサを用いて自動運転を実行する。上述したように、車両31~3mのそれぞれは、センサの点検の対象車両となったり、その対象車両の点検を支援するための周辺車両となったりできる。車両31~3mのそれぞれは、サーバ1あるいは対象車両となった車両からの実行指示(後述参照)に基づいて、点検に関するトランザクション(上述参照)を実行し、実行結果(つまり、外部環境測定結果情報)を報告する。車両31~3mの内部構成の詳細については、図4を参照して後述する。
 なお、ブロックチェーンBKC1,BKC2のデータ実体は、例えばサーバ1、端末21~2nにそれぞれ記録して保存されているが、サーバ1、端末21~2nはネットワーク網NW1に接続されているので、車両31~3mから見ればネットワーク網NW1に仮想的に記録保持されていると考えることもできる。
 図3は、サーバ1および端末21~2nの内部構成例を示すブロック図である。サーバ1は、操作部11と、メモリ12と、データ蓄積部13と、通信回路14と、プロセッサ15とを含む構成である。
 操作部11は、分散型トランザクション証明システム100のユーザ(例えば分散型トランザクション証明システム100の運営者あるいは管理者。以下同様。)の操作を受け付ける入力デバイスにより構成される。操作部11は、例えばマウス、キーボード、タッチパネルにより構成される。なお、ブロックチェーン技術におけるスマートコントラクト機能に準じた機能を用いることで、ユーザが使用する操作部11の構成はサーバ1から省略されてよい。つまり、プロセッサ15は、スマートコントラクト機能に準じた機能を用いるために、所定の処理を実行するための事前定義情報をメモリ12あるいはデータ蓄積部13に記録して保持する。プロセッサ15は、上述した事前定義情報により記載されているイベントの発生を検知すると、その所定の処理を自動的に実行してよい。所定の処理は、例えば、後述する点検証明通知の作成および送信であるが、これに限定されない。
 メモリ12は、例えばRAM(Random Access Memory)とROM(Read Only Memory)とを用いて構成され、サーバ1の動作の実行に必要なプログラムおよびデータ、さらには、動作中に生成されたデータもしくは情報を一時的に保持する。RAMは、例えば、サーバ1の動作時に使用されるワークメモリである。ROMは、例えば、サーバ1を制御するためのプログラムおよびデータを予め記憶して保持する。
 データ蓄積部13は、例えばHDD(Hard Disk Drive)もしくはSSD(Solid State Drive)を用いて構成され、プロセッサ15により生成されるデータもしくは情報を記録して保持する。データ蓄積部13は、例えばブロックチェーンBKC1,BKC2の一部あるいは全部のデータを記録して保持する。ブロックチェーンBKC1,BKC2のデータ構造例の詳細については、図5および図6を参照して後述する。
 通信回路14は、端末21~2nのそれぞれ、あるいは車両31~3mのそれぞれとの間のデータもしくは情報の送受信が可能な通信回路により構成される。通信回路14は、プロセッサ15により生成されたデータもしくは情報を受け取ると、通信相手(例えば、端末21~2nのそれぞれ、あるいは車両31~3mのそれぞれ)にそのデータもしくは情報を送る。また、通信回路14は、通信相手(上述参照)から送られるデータもしくは情報を受信してプロセッサ15に送る。
 プロセッサ15は、例えばCPU(Central Processing Unit)、DSP(Digital Signal Processor)もしくはFPGA(Field Programmable Gate Array)を用いて構成される。プロセッサ15は、サーバ1の全体的な動作を司るコントローラとして機能し、サーバ1の各部の動作を統括するための制御処理、サーバ1の各部との間のデータの入出力処理、データの演算(計算)処理およびデータの記憶処理を行う。プロセッサ15は、メモリ12に記憶されたプログラムおよびデータに従って動作する。プロセッサ15は、動作時にメモリ12を使用し、プロセッサ15が生成または取得したデータもしくは情報をメモリ12に一時的に保存したり、データ蓄積部13に記録したりする。プロセッサ15の動作例の詳細については、図8を参照して後述する。
 端末21~2nは、操作部11aと、メモリ12aと、データ蓄積部13aと、通信回路14aと、プロセッサ15aとを含む構成である。
 操作部11aは、分散型トランザクション証明システム100のユーザの操作を受け付ける入力デバイスにより構成される。操作部11aは、例えばマウス、キーボード、タッチパネルにより構成される。なお、ブロックチェーン技術におけるスマートコントラクト機能に準じた機能を用いることで、ユーザが使用する操作部11aの構成は端末21~2nのそれぞれから省略されてよい。つまり、プロセッサ15aは、スマートコントラクト機能に準じた機能を用いるために、所定の処理を実行するための事前定義情報をメモリ12aあるいはデータ蓄積部13aに記録して保持する。プロセッサ15aは、上述した事前定義情報により記載されているイベントの発生を検知すると、その所定の処理を自動的に実行してよい。所定の処理は、例えば、後述する点検証明通知の作成および送信であるが、これに限定されない。
 メモリ12aは、例えばRAMとROMとを用いて構成され、端末21~2nのそれぞれの動作の実行に必要なプログラムおよびデータ、さらには、動作中に生成されたデータもしくは情報を一時的に保持する。RAMは、例えば、端末21~2nのそれぞれの動作時に使用されるワークメモリである。ROMは、例えば、端末21~2nのそれぞれを制御するためのプログラムおよびデータを予め記憶して保持する。
 データ蓄積部13aは、例えばHDDもしくはSSDを用いて構成され、プロセッサ15aにより生成されるデータもしくは情報を記録して保持する。データ蓄積部13aは、例えばブロックチェーンBKC1,BKC2の一部あるいは全部のデータを記録して保持する。
 通信回路14aは、サーバ1、あるいは車両31~3mのそれぞれとの間のデータもしくは情報の送受信が可能な通信回路により構成される。通信回路14aは、プロセッサ15aにより生成されたデータもしくは情報を受け取ると、通信相手(例えば、サーバ1、あるいは車両31~3mのそれぞれ)にそのデータもしくは情報を送る。また、通信回路14aは、通信相手(上述参照)から送られるデータもしくは情報を受信してプロセッサ15aに送る。
 プロセッサ15aは、例えばCPU(Central Processing Unit)、DSP(Digital Signal Processor)もしくはFPGA(Field Programmable Gate Array)を用いて構成される。プロセッサ15aは、端末21~2nのそれぞれの全体的な動作を司るコントローラとして機能し、端末21~2nのそれぞれの各部の動作を統括するための制御処理、端末21~2nのそれぞれの各部との間のデータの入出力処理、データの演算(計算)処理およびデータの記憶処理を行う。プロセッサ15aは、メモリ12aに記憶されたプログラムおよびデータに従って動作する。プロセッサ15aは、動作時にメモリ12aを使用し、プロセッサ15aが生成または取得したデータもしくは情報をメモリ12aに一時的に保存したり、データ蓄積部13aに記録したりする。プロセッサ15aの動作例の詳細については、図11を参照して後述する。
 図4は、車両31~3mの内部構成例を示すブロック図である。車両31~3mのそれぞれは、制御部40と、カメラ41と、LiDAR42と、ミリ波レーダ43と、その他センサ群44と、通信回路45と、メモリ46とを含む構成である。実施の形態1に係る分散型トランザクション証明システム100において、カメラ41と、LiDAR42と、ミリ波レーダ43と、その他センサ群44とは、車両31~3mのそれぞれを車検のような3年あるいは2年ごとの検査ではなく、必要な時に都度手軽に行える点検を行うために、サーバ1より送られる点検実施要求の対象となるセンサである。
 車両31~3mのそれぞれは、例えば自動運転レベル1以上の車両であり、以下、自動運転レベル3の車両を例示して説明する。カメラ41と、LiDAR42と、ミリ波レーダ43と、その他センサ群44と、通信回路45と、制御部40とは、CAN(Controller Area Network)等の車載ネットワークを介して互いにデータもしくは情報の入出力が可能に接続される。
 車両31~3mは、自動運転を制御するためのコントローラの一例としての制御部40を搭載する。制御部40は、例えばECU(Electronic Control Unit)を用いて構成される。制御部40は単一あるいは複数のECUを用いて構成されてよい。制御部40は、メモリ46に記憶されたプログラムおよびデータに従って動作する。具体的には、制御部40は、各種のセンサ(具体的には、カメラ41、LiDAR42、ミリ波レーダ43、その他センサ群44)の検知出力に基づき、自動運転における経路情報を生成する。
 制御部40は、生成された経路情報に従い、制御対象装備(後述参照)を制御しながら自動運転する。車両31~3mのそれぞれの自動運転は、障害物(例えば、道路上に存在する穴、他車両、バイク等の二輪車、歩行者、ガードレール、電柱、ポール、店舗等の施設等)に衝突しそうになる直前にブレーキを作動させて車両31~3mのそれぞれを停止させる機能を含む。車両31~3mのそれぞれの自動運転は、前方を走る他車両との間で一定の間隔を保ったまま追従する機能を含む。車両31~3mのそれぞれの自動運転は、車線からはみ出さないように車両31~3mのそれぞれのステアリングを制御する機能を含むが、上述した各機能は自動運転の一例であり、これらの機能に限定されない。
 センサの一例としてのカメラ41は、いわゆる車載カメラであり、CCD(Charge Coupled Device)もしくはCMOS(Complementary Metal Oxide Semiconductor)等の撮像素子を有する。カメラ41は、例えば車両31~3mのそれぞれの車体前部の中央に設置され、前方中央の範囲を検知範囲として撮像する。例えば、カメラ41は、自車両の前方に存在する障害物(上述参照)あるいは信号機を検知する。カメラ41は、撮像画像のデータを用いた画像処理を実行可能であり、その画像処理によって検知された障害物と自車両との関係を示す情報(例えば、自車両を基準とした障害物の速度や位置の情報)を検知したり、信号機の位置、大きさ、信号灯の色を検知したりできる。カメラ41は、撮像画像、あるいは撮像画像に対する画像処理結果を制御部40に送る。
 センサの一例としてのLiDAR42は、車両31~3mのそれぞれの周囲に光線(例えば、赤外線レーザ)を放射してその反射信号を受信し、受信された反射信号を基にして周囲に存在する対象物(例えば上述した障害物)との距離、対象物の大きさ、および対象物の組成を測定する。LiDAR42は、この測定結果を制御部40に送る。
 センサの一例としてのミリ波レーダ43は、車両31~3mのそれぞれの周囲に電波(例えばミリ波)を放射してその反射信号を受信し、受信された反射信号を基にして周囲に存在する対象物までの距離を測定する。ミリ波レーダ43は、この測定結果を制御部40に送る。なお、ミリ波レーダ43は、LiDAR42で検出困難な、より遠方の対象物を検出可能である。
 その他センサ群44は、上述したカメラ41、LiDAR42、ミリ波レーダ43以外に搭載される複数のセンサである。例えば、アラウンドビューカメラ、GNSSセンサ、レーザレンジファインダが該当する。
 センサの一例としてのアラウンドビューカメラは、車両31~3mのそれぞれの車体前方と車体後方と車体側方とにそれぞれ設置される複数台(例えば、車体前方に2台、車体後方に2台、車体側方に2台の計6台)のカメラを用いて構成される。アラウンドビューカメラは、車両31~3mのそれぞれの近傍の白線や隣接する車線の他車両等を検知する。
 センサの一例としてのGNSSセンサは、複数のGPS衛星から発信された時刻および各GPS衛星の位置(座標)を示す複数の信号を受信し、その受信された複数の信号に基づいて、GPS受信機の位置(つまり、車両31~3mのそれぞれの位置)を算出する。GNSSセンサは、車両31~3mのそれぞれの位置情報(算出結果)を制御部40に送る。
 センサの一例としてのレーザレンジファインダは、車両31~3mのそれぞれの車体前方右側、車体前方左側、車体側方右側、車体側方左側、車体後方右側、車体後方左側に設置される。レーザレンジファインダは、車両31~3mのそれぞれの前方右側、前方左側、側方右側、側方左側、後方右側、後方左側に存在する障害物(上述参照)等を検知する。具体的には、レーザレンジファインダは、それぞれレーザ光を一定の広角な角度範囲で走査しながら照射し、その反射光を受光して照射の開始時点と反射光の受光時点との時間差を検知することで、自車両と障害物と距離、更には、自車両から見た障害物の方向を検知する。
 なお、その他センサ群44は、上述したアラウンドビューカメラ、GNSSセンサ、レーザレンジファインダに限定されず、例えばジャイロセンサ、加速度センサ、地磁気センサ、傾斜センサ、気温センサ、気圧センサ、湿度センサ、照度センサを有してよい。さらに、車両31~3mのそれぞれは、上述した各種のセンサを全て備える必要は無く、車両31~3mのそれぞれに割り当てられる自動運転レベルに準じて適宜備えてよい。
 通信回路45は、サーバ1、あるいは端末21~2nのそれぞれとの間のデータもしくは情報の送受信が可能な通信回路により構成される。通信回路45は、制御部40により生成または取得されたデータもしくは情報を、サーバ1、あるいは端末21~2nのそれぞれに送る。通信回路45は、サーバ1、あるいは端末21~2nのそれぞれから送られたデータもしくは情報を受信して制御部40に送る。
 メモリ46は、例えばRAMとROMとを用いて構成され、制御部40の動作の実行に必要なプログラムやデータ、更には、動作中に生成されたデータもしくは情報を一時的に保持する。RAMは、例えば制御部40の動作時に使用されるワークメモリである。ROMは、例えば制御部40を制御するためのプログラムおよびデータを予め記憶して保持する。
 また、制御部40は、車両31~3mのそれぞれのアクセルスロットル開度、車両31~3mのそれぞれのブレーキ力、ステアリング舵角、ウインカーの点滅タイミング等の自動運転に必要な制御対象装備を制御するための制御値を計算する。制御値は、例えば制御部40により生成される経路情報に従って走行するように計算される。制御部40は、計算された制御値を、それぞれの制御対象装備(例えば、ステアリング、アクセルペダル、ブレーキ、方向指示器)を駆動するためのアクチュエータ(つまり、ステアリングアクチュエータ、アクセルペダルアクチュエータ、ブレーキアクチュエータ、ウインカー点滅コントローラ)に伝達する。
 制御対象装備は、車両31~3mのそれぞれに配備される装備物であり、車両31~3mのそれぞれの自動運転中に制御部40により作動の制御を受ける。制御対象装備は、例えばステアリングアクチュエータ、アクセルペダルアクチュエータ、ブレーキアクチュエータ、ウインカー点滅コントローラであるが、これらに限定されない。
 ステアリングアクチュエータは、車両31~3mのそれぞれに配置されるステアリングと接続され、制御部40から入力されるステアリング(図示略)の制御信号に従って、自動運転中におけるステアリングの作動(言い換えると、車両31~3mのそれぞれの進行方向の維持または変更)を制御する。
 アクセルペダルアクチュエータは、車両31~3mのそれぞれに配置されるアクセルペダルと接続され、制御部40から入力されるアクセルペダル(図示略)の制御信号に従って、自動運転中におけるアクセルペダルの作動(言い換えると、車両31~3mのそれぞれの車速の維持または増減)を制御する。
 ブレーキアクチュエータは、車両31~3mのそれぞれに配置されるブレーキと接続され、制御部40から入力されるブレーキ(図示略)の制御信号に従って、自動運転中におけるブレーキの作動(言い換えると、車両31~3mのそれぞれの進行に対する制動の維持または変更)を制御する。
 ウインカー点滅コントローラは、車両31~3mのそれぞれに配置されるウインカー点滅機構と接続され、制御部40から入力されるウインカー点滅機構(図示略)の制御信号に従って、自動運転中における方向指示器の作動(言い換えると、車両31~3mのそれぞれが左折または右折することを報知するための方向指示器の点滅)を制御する。
 次に、サーバ1、端末21~2nのそれぞれにより作成および記録されるブロックチェーンBKC1,BKC2の構造例について、図5および図6を参照して説明する。図5は、ブロックチェーンの第1構成例を示す図である。図6は、ブロックチェーンの第2構成例を示す図である。図5および図6のブロックチェーンBKC1,BKC2は、図1に示す第1ユースケースに対応したデータ構造を有しており、図5および図6に示すデータ構造例に限定されない。
 図5に示すブロックチェーンBKC1は、複数の車両CR1~CR4のそれぞれの点検に関するトランザクション情報を、それぞれのトランザクション情報が時系列的な関連性を有するように連鎖的に(まるで数珠つなぎのように)記録する。具体的には、ブロックチェーンBKC1は、複数の車両CR1~CR4のそれぞれにより点検に関するトランザクションが実行される度に作成されるブロックを鎖(チェーン)のように時系列に繋げた構成である。
 具体的には、図5に示すブロックチェーンBKC1では、以前に作成された以前ブロックPBL1に対し、その以前ブロックPBL1の後に作成されたという関連性を有する車両CR2ブロックMBL1が作成されて縦方向に繋がれている(つまり、連接されている)。より具体的には、直前に作成された以前ブロックPBL1の一方向性関数(いわゆるハッシュ関数)の出力であるハッシュ値(いわゆるダイジェスト)が車両CR2ブロックMBL1内に保持される(図7参照)。ここでいう縦方向とは、分散型トランザクション証明システム100において、点検証明の対象車両として選定された車両に対応するブロックが繋がれる時系列の方向を示している。
 車両CR2ブロックMBL1は、図1を参照して説明したように、分散型トランザクション証明システム100における点検証明の対象車両(つまり、センサの点検の対象車両)として選定された車両CR2が行う、点検に関するトランザクションに対応するトランザクション情報を有するブロックである。また、車両CR2ブロックMBL1には、点検の対象車両以外の周辺車両(つまり、車両CR2の点検証明を支援する車両CR1,CR3,CR4)が行う、点検に関するトランザクションに対応するトランザクション情報を有するサイドブロックBL11,BL12,BL13がそれぞれ横方向に対応付けて繋げられている(つまり、連接されている)。サイドブロックBL11,BL12,BL13は、それぞれ車両CR1ブロック,車両CR3ブロック,車両CR4ブロックに対応する。ここでいう横方向とは、分散型トランザクション証明システム100において、対象車両の点検証明を支援する周辺車両として選定された車両に対応するブロックが繋がれる方向を示している。
 また、車両CR2ブロックMBL1に対し、その車両CR2ブロックMBL1の後に作成されたという関連性を有する車両CR3ブロックMBL2が作成されて縦方向に繋がれている(つまり、連接されている)。より具体的には、直前に作成された車両CR2ブロックMBL1の一方向性関数(いわゆるハッシュ関数)の出力であるハッシュ値(いわゆるダイジェスト)が車両CR3ブロックMBL2内に保持される(図7参照)。
 車両CR3ブロックMBL2は、図1を参照して説明したように、分散型トランザクション証明システム100における点検証明の対象車両(つまり、センサの点検の対象車両)として選定された車両CR3が行う、点検に関するトランザクションに対応するトランザクション情報を有するブロックである。また、車両CR3ブロックMBL2には、点検の対象車両以外の周辺車両(つまり、車両CR3の点検証明を支援する車両CR1,CR2,CR4)が行う、点検に関するトランザクションに対応するトランザクション情報を有するサイドブロックBL21,BL22,BL23がそれぞれ横方向に対応付けて繋げられている(つまり、連接されている)。
 図6に示すブロックチェーンBKC2は、図5に示すブロックチェーンBKC1と同様に、複数の車両CR1~CR4のそれぞれの点検に関するトランザクション情報を、それぞれのトランザクション情報が時系列的な関連性を有するように連鎖的に(まるで数珠つなぎのように)記録する。具体的には、ブロックチェーンBKC2は、複数の車両CR1~CR4のそれぞれにより点検に関するトランザクションが実行される度に作成されるブロックを鎖(チェーン)のように時系列に繋げた構成である。
 具体的には、図6に示すブロックチェーンBKC2では、以前に作成された以前ブロックPBL1aに対し、その以前ブロックPBL1aの後に作成されたという関連性を有する車両CR2ブロックMBL1aが作成されて縦方向に繋がれている(つまり、連接されている)。より具体的には、直前に作成された以前ブロックPBL1の一方向性関数(いわゆるハッシュ関数)の出力であるハッシュ値(いわゆるダイジェスト)が車両CR2ブロックMBL1内に保持される(図7参照)。車両CR2ブロックMBL1aは、図5と同様に、複数の車両CR1~CR4のうち点検の対象車両として選定された車両CR2に対応するブロックである。また、車両CR2ブロックMBL1aは、図5に示す車両CR2ブロックMBL1と異なり、点検の対象車両以外の周辺車両(つまり、車両CR2の点検証明を支援する車両CR1,CR3,CR4)が行う、点検に関するトランザクションに対応するトランザクション情報を有するサイドブロックSBL11,SBL12,SBL13を含むように保持する。
 また、車両CR2ブロックMBL1aに対し、その車両CR2ブロックMBL1aの後に作成されたという関連性を有する車両CR3ブロックMBL2aが作成されて縦方向に繋がれている(つまり、連接されている)。より具体的には、直前に作成された車両CR2ブロックMBL1aの一方向性関数(いわゆるハッシュ関数)の出力であるハッシュ値(いわゆるダイジェスト)が車両CR3ブロックMBL2a内に保持される(図7参照)。車両CR3ブロックMBL2aは、図5と同様に、複数の車両CR1~CR4のうち点検の対象車両として選定された車両CR3に対応するブロックである。また、車両CR3ブロックMBL2aは、点検の対象車両以外の周辺車両(つまり、車両CR3の点検証明を支援する車両CR1,CR2,CR4)が行う、点検に関するトランザクションに対応するトランザクション情報を有するサイドブロックSBL21,SBL22,SBL23を含むように保持する。
 図7は、ブロックチェーンを構成するブロックのデータ構造例を示す図である。図7では、例えば車両CR2ブロックMBL1(図5参照)を例示して説明するが、個々のブロック内のデータ構造例は同様である。車両CR2ブロックMBL1は、直前ブロックのハッシュ値HS1と、ナンス値NS1と、少なくとも1つのトランザクション情報TR1とを含む構成である。
 直前ブロックのハッシュ値HS1は、上述したように、車両CR2ブロックMBL1が直前に作成されたブロック(例えば図5に示す以前ブロックPBL1)の後に作成されたという時系列的な関連性を有することを示す。言い換えると、ハッシュ値HS1は、自ブロックの直前に作成されたブロックがどのブロックであるかを示す。
 ナンス値NS1は、サーバ1あるいは端末21~2nのうちいずれかがブロックを新たに作成する際、ハッシュ値HS1が所定の値(いわゆる、difficulty target)よりも小さい数に調整されるように、サーバ1あるいは端末21~2nのうちいずれかにより書き込まれる調整用データである。
 トランザクション情報TR1は、事前定義情報DF1と、対象車両情報TRG1と、周辺車両情報ASS1と、外部環境測定結果情報SEN1と、点検結果情報IPE1と、付属情報AT1とを含む構成である。
 事前定義情報DF1は、対象車両が備えるセンサのうち点検の対象となるセンサの情報、対象車両以外の周辺車両の台数、点検に関するトランザクションの実行内容、対象車両および周辺車両がそれぞれ行う点検に関するトランザクションの実行結果の比較指示、等を含む。事前定義情報DF1は、サーバ1あるいは端末21~2nのそれぞれにより記載される。
 対象車両情報TRG1は、複数の車両31~3mの中でサーバ1により選定される点検の対象車両に関する情報(識別情報を含む)を示す。対象車両情報TRG1は、サーバ1あるいは端末21~2nのそれぞれにより記載される。
 周辺車両情報ASS1は、複数の車両31~3mの中でサーバ1により選定される点検の対象車両以外の周辺車両に関する情報(識別情報を含む)を示す。周辺車両情報ASS1は、サーバ1あるいは端末21~2nのそれぞれにより記載される。
 外部環境測定結果情報SEN1は、自ブロックに対応する車両(図7の例では、点検の対象車両として選定される車両CR2)が点検に関するトランザクションの実行結果として、その車両が備えるセンサにより測定されたデータもしくは情報を示す。例えば、外部環境測定結果情報SEN1は、対象車両および周辺車両が走行する同一エリアの同一走行ルート上に存在する、地形情報、標識認識結果情報、信号機の色識別結果情報が該当する。但し、外部環境測定結果情報SEN1は、地形情報、標識認識結果情報、信号機の色識別結果情報に限定されない。外部環境測定結果情報SEN1は、自ブロックに対応する車両から送られた外部環境測定結果情報を受け取ったサーバ1あるいは端末21~2nのそれぞれにより記載される。
 点検結果情報IPE1は、対象車両および周辺車両の点検に関するトランザクションのそれぞれの実行結果の比較に基づいて判定された、対象車両が備えるセンサの不具合(例えば故障)の有無を示す点検結果を示す。点検結果情報IPE1は、対象車両が備えるセンサの不具合(例えば故障)の有無を判断するサーバ1あるいは端末21~2nのそれぞれにより記載される。
 付属情報AT1は、例えば点検に関するトランザクションの実施日時情報、エリア情報、走行ルート情報、自ブロックと関連性を有する他のブロック情報を有する。なお、付属情報AT1は、自ブロックがサイドブロックを含むように保持する場合に限って、そのサイドブロックに関する情報(識別情報を含む)を有してもよい。
 次に、第1ユースケースに係る分散型トランザクション証明システム100のサーバ1、対象車両、周辺車両、端末21~2nの動作手順について、図8、図9、図10、図11、図12および図13をそれぞれ参照して説明する。図8は、第1ユースケースに対応したサーバ1の動作手順例を時系列に示すフローチャートである。図8に示す各処理は、サーバ1のプロセッサ15により実行される。
 図8において、サーバ1は、分散型トランザクション証明システム100に参加している複数台の車両31~3mの中から、センサの点検の対象車両を選定する(St11)。サーバ1は、ステップSt11の後、対象車両および周辺車両(図5参照)、あるいは対象車両(図6参照)に対応するブロックを新たに作成してブロックチェーンBKC1,BKC2に追加(登録)する。サーバ1は、ブロックチェーンBKC1,BKC2上に追加されたブロックに、点検内容を含む事前定義情報DF1、対象車両情報TRG1および周辺車両情報ASS1を記載し、または、事前定義情報DF1、対象車両情報TRG1および周辺車両情報ASS1の記載を端末21~2nのうちいずれかを選定して指示する(St12)。
 サーバ1は、ネットワーク網NW1を介して、ステップSt11において選定された対象車両が起動(例えば、イグニッションがオン)しているか否かをその対象車両に直接的に問い合わせ、あるいは他の周辺車両に間接的に問い合わせる(St13)。サーバ1は、その問い合わせに対する応答結果として対象車両が起動していないことを判定した場合(St13、NO)、ブロックチェーンBKC1,BKC2上に新たな対象車両に対応するブロックを新たに追加(登録)してよいか否かを判定する(St14)。
 サーバ1は、一旦作成されたブロックに対応する対象車両の点検結果が記載されていない(言い換えると、点検証明がされていない)未完成状態のブロックの保持数を示す許容値情報を有している。この許容値情報は、例えばメモリ12内に保持されてよい。サーバ1は、ステップSt13において起動していないことが判定された対象車両に対応するブロックの保持数が許容値情報に対応する許容値と一致した場合、ブロックチェーンBKC1,BKC2上に新たなブロックの作成ができないため、対象車両が起動するまでプロセッサ15の動作は待機状態となる(St14、NO)。
 一方、サーバ1は、ステップSt13において起動していないことが判定された対象車両に対応するブロックの保持数が許容値情報に対応する許容値まで満たない場合(St14、YES)、点検対象に対応するブロックを新たに作成してブロックチェーンBKC1,BKC2に追加(登録)する。つまり、サーバ1の処理はステップSt11に戻る。この場合には、他の車両が対象車両として選定されることになる。
 一方、サーバ1は、対象車両が起動していることを判定した場合(St13、YES)、事前定義情報DF1、対象車両情報TRG1および周辺車両情報ASS1を含む点検実施要求を作成し、対象車両に通知する(St15)。点検実施要求は、対象車両情報TRG1により特定される対象車両が実行する、事前定義情報DF1により記載された点検に関するトランザクションの実行指示を示す。また、図9、図12および図13を参照して後述するが、対象車両は、ステップSt15の点検実施要求の通知を受け取ると、周辺車両情報ASS1に基づいて、周辺車両に対し、点検に関するトランザクションの実行指示を送る(St32)。
 サーバ1は、対象車両および周辺車両のそれぞれから、点検に関するトランザクションの実行結果としての外部環境測定結果情報を受信し(St16)、それぞれの外部環境測定結果情報をブロックチェーンBKC1,BKC2の対応する対象車両あるいは周辺車両のブロックに記載する。なお、後述するように、ブロックへの外部環境測定結果情報は、サーバ1ではなく、それぞれの外部環境測定結果情報を受信した端末21~2nのうちいずれかにより記載されてもよい(図11参照)。
 サーバ1は、ブロックチェーンBKC1,BKC2上に、不正なく外部環境測定結果情報の記載が完了したことを認識する(St17)。
 サーバ1は、ステップSt17においてブロックチェーンBKC1,BKC2の対象車両および周辺車両のそれぞれ対応するブロックに記載された外部環境測定結果情報に基づいて、対象車両の点検が正常であったか否かを判定する(St18)。サーバ1は、ステップSt18の判定結果を点検結果情報IPE1として、対象車両に対応するブロックに記載する。
 サーバ1は、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た周辺車両の数が周辺車両の台数の過半数であると判定した場合、対象車両の点検が正常であると判定する(St18、YES)。この場合、サーバ1は、点検結果情報IPE1の一例としての点検証明通知を発行(作成)して対象車両に送る(St19)。点検証明通知は、実施の形態1に係る分散型トランザクション証明システム100に参加している周辺車両のうち過半数の同意が得られたことで、対象車両の点検が正常であったことの有効性を担保する情報である。これにより、分散型トランザクション証明システム100において、対象車両および周辺車両の間で、車両が備えるセンサの点検証明を簡易かつ気軽に発行可能となる。上述したように、既存の車検場で車検完了の証明書を発行する中央集権型から個人あるいは民間業者のサービスとして車検証明に準じた点検証明を発行可能な分散型にすることで、従来よりも車両の異常を短周期に実行でき、かつ正常な車両(例えば、自動運転車両)であることの証明が可能となる。
 一方、サーバ1は、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た周辺車両の数が周辺車両の台数の過半数でなかったと判定した場合(St18、NO)、対象車両の点検が異常であると判定する。この場合、サーバ1は、点検結果情報IPE1の一例としての異常通知(つまり、対象車両の点検が異常であった旨の情報通知)を作成して対象車両に送る、または、対象車両が備える一部あるいは全部のセンサの機能(制御)を制限する旨の命令(つまり、制御制限命令)を作成して対象車両に送る(St20)。
 なお、対象車両は、サーバ1から制御制限命令を受信した場合、その制御制限命令により特定されるセンサの使用を制限する。例えば、対象車両におけるブレーキアシスト機能(例えば、赤信号の検知によりブレーキが作動する機能)がオフになる。これにより、例えば自動運転中に制御制限命令により特定されるセンサの使用を控えるので、対象車両が交通違反あるいは交通事故を起こす確率を低減できる。
 サーバ1は、ステップSt19あるいはステップSt20の後、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た一部あるいは全部の周辺車両に対し、所定の報酬を支払う(St21)。所定の報酬は、例えば規定料の仮想通貨、あるいは規定のポイント値である。
 図9は、対象車両(車両)の動作手順例を時系列に示すフローチャートである。図9に示す各処理は、対象車両(つまり、車両31~3mのうちいずれか1台の車両)の制御部40により実行される。図10は、周辺車両(つまり、車両)の動作手順例を時系列に示すフローチャートである。図10に示す各処理は、対象車両以外の周辺車両の制御部40により実行される。図11は、端末21~2nの動作手順例を時系列に示すフローチャートである。図11に示す各処理は、端末21~2nのうちの少なくとも1台の端末のプロセッサ15aにより実行される。図12は、周辺車両における外部環境測定の動作手順例を時系列に示すシーケンス図である。図13は、サーバ1あるいは端末21~2nにおける外部環境測定の動作手順例を時系列に示すシーケンス図である。
 以下では、対象車両および周辺車両がそれぞれ測定した外部環境測定結果情報の比較は、周辺車両により実行されるパターン(図12参照)と、サーバ1あるいは端末21~2nのそれぞれ(図13参照)により実行されるパターン(図13参照)とがある。このため、図12の説明において適宜図9および図10を参照して説明する例、図13の説明において適宜図9および図10を参照して説明する例の順に説明する。
 図12、図9および図10において、サーバ1は、点検実施要求を作成し、対象車両に通知する(St15)。対象車両は、サーバ1から送られた点検実施要求(図8参照)を受信する(St31)。対象車両は、取得情報比較要求を周辺車両に通知するとともに、自車両が備えるセンサにより測定された外部環境測定結果情報を周辺車両に送る(St32)。取得情報比較要求は、対象車両が得た外部環境測定結果情報と周辺車両が得た外部環境測定結果情報との比較を指示する。
 周辺車両は、対象車両から送られた取得情報比較要求を受信すると(St41)、この取得情報比較要求に基づいて、点検に関するトランザクションを実行することで、外部環境情報を測定する(St61)。これにより、周辺車両は、外部環境測定結果情報を得ることができ、自車両(つまり、周辺車両)が得た外部環境測定結果情報と対象車両が得た外部環境測定結果情報とを比較できる(St62)。周辺車両は、比較結果をサーバ1および端末21~2nのそれぞれに送る(St42)。
 サーバ1は、点検証明通知、異常通知、または制御制限命令を作成し、点検結果通知として対象車両に送る(St63)。対象車両は、サーバ1から送られた点検証明通知あるいは異常通知、もしくは対象車両が備える一部あるいは全部のセンサの機能(制御)を制限する旨の命令(つまり、制御制限命令)を受信する(St33)。ステップSt33の後、対象車両の処理はステップSt31に戻り、ステップSt31~St33の処理が繰り返される。
 サーバ1は、ステップSt19あるいはステップSt20の後、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た一部あるいは全部の周辺車両に対し、所定の報酬を支払う(St21)。周辺車両は、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た場合には、サーバ1から所定の報酬を受信する(St43)。
 図13、図9および図10において、サーバ1は、点検実施要求を作成し、対象車両に通知する(St15)。対象車両は、サーバ1から送られた点検実施要求(図8参照)を受信する(St31)。対象車両は、取得情報比較要求を周辺車両に通知するとともに、自車両が備えるセンサにより測定された外部環境測定結果情報をサーバ1および端末21~2nのそれぞれに送る(St32)。
 周辺車両は、対象車両から送られた取得情報比較要求を受信すると(St41)、この取得情報比較要求に基づいて、点検に関するトランザクションを実行することで、外部環境情報を測定する(St61)。周辺車両は、ステップSt61で測定された外部環境測定結果情報をサーバ1および端末21~2nのそれぞれに送る(St42)。
 サーバ1は、対象車両および周辺車両のそれぞれから送られた外部環境測定結果情報を受信した場合、それらを比較することで(St62a)、対象車両の点検結果を判定する。サーバ1は、点検証明通知、異常通知、または制御制限命令を作成し、点検結果通知として対象車両に送る(St63)。対象車両は、サーバ1から送られた点検証明通知あるいは異常通知、もしくは対象車両が備える一部あるいは全部のセンサの機能(制御)を制限する旨の命令(つまり、制御制限命令)を受信する(St33)。ステップSt33の後、対象車両の処理はステップSt31に戻り、ステップSt31~St33の処理が繰り返される。
 サーバ1は、ステップSt19あるいはステップSt20の後、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た一部あるいは全部の周辺車両に対し、所定の報酬を支払う(St21)。周辺車両は、対象車両の外部環境測定結果情報と一致する外部環境測定結果情報を得た場合には、サーバ1から所定の報酬を受信する(St43)。
 図11において、端末21~2nのうち少なくとも1台の端末は、サーバ1から送られた事前定義情報DF1を受信する(St51)。端末21~2nのうち少なくとも1台の端末は、対象車両および周辺車両から送られたそれぞれが測定した外部環境測定結果情報を受信する(St52)。
 ステップSt52の後、端末21~2nのうちブロックチェーンBKC1,BKC2に記載可能な1台の端末は、ステップSt52において受信された対象車両および周辺車両から送られたそれぞれが測定した外部環境測定結果情報をブロックチェーンBKC1,BKC2の対応するブロックに記載する(St53)。または、端末21~2nのうちブロックチェーンBKC1,BKC2に記載可能な1台の端末は、必要に応じて、ブロックチェーンBKC1,BKC2に追加するブロックを作成する(St53)。
 端末21~2nのうちブロックチェーンBKC1,BKC2に記載可能な1台の端末は、ステップSt53においてブロックチェーンBKC1,BKC2に追加するブロックを作成した場合には、サーバ1から送られる所定の報酬を受け取る(St54)。
 以上により、実施の形態1に係る第1ユースケースでは、分散型トランザクション証明システム100は、サーバ1と複数の車両31~3mのそれぞれとが通信可能に接続される。サーバ1は、複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンBKC1,BKC2を保持する。サーバ1は、複数の車両の中から点検の対象車両を選定し、選定された対象車両の点検に関するトランザクション情報をブロックチェーンに作成するとともに、点検に関するトランザクションの実行指示を対象車両に送る。対象車両は、実行指示に基づいて点検に関するトランザクションを実行するとともに、点検に関するトランザクションの実行指示を対象車両以外の周辺車両に送る。サーバ1は、対象車両および周辺車両のそれぞれの点検に関するトランザクションの実行結果に基づく点検結果を、作成された対象車両の点検に関するトランザクション情報に登録する。
 これにより、分散型トランザクション証明システム100は、身近な複数の車両のそれぞれに搭載されたセンサの不具合の点検に関するトランザクションの実行結果およびセンサの不具合の有無の検出結果をブロックチェーンBKC1,BKC2で管理できる。従って、分散型トランザクション証明システム100によれば、分散型トランザクション証明システム100に参加しているそれぞれの車両で実行されたトランザクションの有効性を的確に担保できる。さらに、点検に関するトランザクション情報がブロックチェーンBKC1,BKC2において記録されるので、身近な複数台の車両の中からブロックチェーンBKC1,BKC2に基づいて選定された対象車両が点検に関するトランザクションを実行した結果に対して改ざん防止が可能となり、対象車両における点検結果の有効性が担保される。さらに、対象車両だけでなく周辺車両が実行する点検に関するトランザクション情報もブロックチェーンBKC1,BKC2上に記録されるので、対象車両の点検結果の改ざんの防止が可能となる。
 また、サーバ1のプロセッサ15は、ブロックチェーンBKC1,BKC2に基づいて、対象車両を選定する。これにより、サーバ1は、従前の点検に関するトランザクションの実行履歴が連鎖的に記録されているブロックチェーンBKC,BKC2に基づいて、例えば一定期間点検がなされていない車両を抽出して対象車両に選定できる。
 また、サーバ1のプロセッサ15は、対象車両の点検に関するトランザクションの実行結果と一致する実行結果を測定した周辺車両が過半数である場合に、点検結果として正常である旨の情報を作成する。これにより、分散型トランザクション証明システム100に参加している複数台の車両31~3mのうち対象車両以外の周辺車両の過半数の同意(つまり、同一の外部環境測定結果情報が得られた)により、手軽に対象車両の点検証明の有効性が担保される。
 また、サーバ1のプロセッサ15は、対象車両および周辺車両のそれぞれの点検に関するトランザクションの実行結果を受け取り、それぞれの実行結果の比較に基づき、対象車両の点検に関するトランザクションの実行結果と一致する実行結果を測定した周辺車両が過半数であるか否かを判定する。これにより、サーバ1は、分散型トランザクション証明システム100に参加している合計(m-1)台の周辺車両のうち過半数の周辺車両が得た外部環境測定結果情報が同一であるかどうかを判定するだけで、簡易に対象車両の点検の有効性を担保できる。
 また、サーバ1のプロセッサ15は、対象車両および周辺車両のそれぞれの点検に関するトランザクションの実行結果の比較結果を受け取り、比較結果に基づき、対象車両の点検に関するトランザクションの実行結果と一致する実行結果を測定した周辺車両が過半数であるか否かを判定する。これにより、サーバ1は、分散型トランザクション証明システム100に参加している合計(m-1)台の周辺車両のうち過半数の周辺車両が得た外部環境測定結果情報が同一であるかどうかの比較結果を判定するだけで、簡易に対象車両の点検の有効性を担保できる。
 また、サーバ1のプロセッサ15は、対象車両の点検に関するトランザクションの実行結果と一致する実行結果を測定した周辺車両が過半数に満たない場合に、点検結果として異常である旨の情報を作成する。これにより、サーバ1は、分散型トランザクション証明システム100に参加している合計(m-1)台の周辺車両のうち過半数の周辺車両が得た外部環境測定結果情報が同一でないと判定するだけで、対象車両の点検が異常であった旨を簡易に判定できる。
 また、サーバ1のプロセッサ15は、異常に係る対象車両の機能の使用制限命令を、通信回路14を介して、対象車両に送る。これにより、サーバ1は、例えば自動運転中に制御制限命令により特定されるセンサの使用を対象車両に控えさせるので、対象車両が交通違反あるいは交通事故を起こす確率を低減できる。
 また、サーバ1のプロセッサ15は、対象車両の点検に関するトランザクションの実行結果と一致する実行結果を測定した過半数の周辺車両に所定の報酬を付与する。これにより、周辺車両へのインセンティブが保証されるので、車両が分散型トランザクション証明システム100に参加することの意義が的確に向上する。
 また、車両31~3mのそれぞれは、サーバ1を含む分散型トランザクション証明システム100を構成する車両であって、車両の点検に関するトランザクション情報を連鎖的に記録するブロックチェーンBKC1,BKC2を保持するサーバ1との間で通信する通信回路45を有する。車両31~3mのそれぞれは、自車両の運転を含む動作を制御する制御部40を有する。自車両が点検の対象車両として選定された場合、通信回路45は、点検に関するトランザクションの実行指示を受け取る。また、制御部40は、実行指示に基づく点検に関するトランザクションの実行を制御し、自車両における点検に関するトランザクションの実行結果と他車両(つまり、複数台の周辺車両)における点検に関するトランザクションの実行結果とに基づく点検結果に基づき、自車両の運転を含む動作を制御する。
 これにより、分散型トランザクション証明システム100において、対象車両および周辺車両の間で、車両が備えるセンサの点検証明を簡易かつ気軽に発行可能となる。上述したように、既存の車検場で車検完了の証明書を発行する中央集権型から個人あるいは民間業者のサービスとして車検証明に準じた点検証明を発行可能な分散型にすることで、従来よりも車両の異常を短周期に実行でき、かつ正常な車両(例えば、自動運転車両)であることの証明が可能となる。
 また、車両31~3mのそれぞれは、点検の対象となる少なくとも1つのセンサをさらに有する。制御部40は、点検に関するトランザクションとして、所定の走行ルートの走行中にセンサによる周辺の外部環境情報の測定結果を受け取る。これにより、車両31~3mのそれぞれは、対象車両あるいは周辺車両のいずれにおいても同一の走行ルートで同様な周囲の外部環境情報の測定を行うので、対象車両の点検を容易に実現可能となる。
(第2ユースケース)
 図14は、分散型トランザクション証明システム100の第2ユースケースの動作概要例を示す説明図である。図15は、第2ユースケースに対応したサーバの動作手順例を時系列に示すフローチャートである。図16は、地図データの更新例を示す説明図である。
 第2ユースケースでは、例えば第1ユースケースにおける対象車両の選定のために、分散型トランザクション証明システム100に参加しているいずれかの車両がイベントを検知したことを契機に、他の周辺車両に同様なイベントの検知ができるか否かが問い合わせされる。イベントの一例として、地図データに存在していない(つまり、データとして登録されていない)障害物が検知されることであるが、これに限定されない。過半数の周辺車両が同様なイベントを検知したことが判明した場合に、その障害物に関する情報が地図データ上に追加して登録されるとともに、第1ユースケースと同様に一連のトランザクション情報がブロックチェーンBKC1,BKC2に登録される。なお、第2ユースケースにおいて、分散型トランザクション証明システム100に参加している車両31~3mのそれぞれは、上述した地図データをメモリ46に記録して保持している。
 図14において、先ず、車両CR1は、地図データに存在していない(つまり、データとして登録されていない)障害物(例えば、道路上に発生した穴OB1)を検知する(St71)。車両CR1は、他の車両CR2,CR3,CR4よりも先行して走行しており、車両CR1~CR4の走行状態はサーバ1において認識されている。車両CR1は、障害物(例えば穴OB1)を検知した旨をサーバ1に報告する。分散型トランザクション証明システム100において、サーバ1は、車両CR1からの報告に基づいて、車両CR1の後続車両(つまり、車両CR2~CR4)に、車両CR1からの障害物の検知報告の信憑性を問い合わせる(St72)。車両CR2~CR4のそれぞれは、サーバ1からの問い合わせ要求に応じて、障害物(例えば穴OB1)の有無を検知し、検知結果をサーバ1に報告する。例えば、車両CR2,CR4は、穴OB1を検知でき、一方で、車両CR3は、穴OB1を検知できなかったとする。
 サーバ1は、車両CR1~CR4のそれぞれの報告に基づいて、過半数の正常検知結果を得た場合(言い換えると、車両CR1の検知結果と一致する検知結果を得た車両が過半数であった場合)、車両CR1の検知報告の有効性を担保するために、ブロックチェーンBKC1,BKC2に登録するとともに(St74)、障害物(例えば穴OB1)に関する情報を新しく追加するための地図データの更新を車両CR1~CR4のそれぞれに指示する(St73)。例えば図16に示すように、更新前の地図データMPD1は地図上に存在している障害物の障害物データMP1,MP2を保持しているが、ステップSt73により、ステップSt71において新しく検知された障害物(例えば穴OB1)に関する障害物データMP3が新しく追加される。更新後の地図データMPD1aに追加された障害物データMP3は、例えば、穴OB1の地点情報(つまり、位置情報)と、障害物の種別と、障害物の大きさを示す面積情報とを有する。
 なお、サーバ1は、車両CR1の検知結果と一致する検知結果を得ることができなかった車両CR3に対し、地図データの更新(上述参照)を一時的に保留してもよい。サーバ1は、車両CR3に搭載されているセンサに不具合(例えば故障)が生じている可能性を認識する(St73)。
 サーバ1あるいは端末21~2nのそれぞれは、上述したように、車両CR1~CR4のそれぞれのトランザクション(つまり、地図データに存在しない穴OB1の検知確認)に対応するトランザクション情報を作成してブロックチェーンBKC1,BKC2に登録する(St74)。サーバ1は、障害物(例えば穴OB1)を検知できた車両(具体的には、車両CR2,CR4)には所定の報酬を支払う(St74)。サーバ1は、車両CR3に搭載されているセンサに不具合(例えば故障)が生じている可能性を認識した後、その車両CR3の使用を控えるための制御制限命令を車両CR3に送るとともに、第1ユースケースと同様に車両CR3を点検の対象車両として選定する(St74)。車両CR3は、サーバ1からの制御制限命令を受信すると、点検依頼を作成してサーバ1に送る。なお、車両CR3が点検の対象車両として選定された場合の処理については、上述した第1ユースケースと同様であるため、説明を省略する。
 次に、第2ユースケースに係る分散型トランザクション証明システム100のサーバ1の動作手順について、図15をそれぞれ参照して説明する。図15に示す各処理は、サーバ1のプロセッサ15により実行される。第2ユースケースに係る対象車両、周辺車両および端末21~2nのそれぞれの動作に説明において、第1のユースケースと同一の内容の説明は簡略化あるいは省略し、異なる内容について説明する。また、図15の説明において、第1ユースケースに係るサーバ1の動作と同一の処理については同一のステップ番号を付与して説明を簡略化あるいは省略し、異なる内容について説明する。
 図15において、サーバ1は、分散型トランザクション証明システム100に参加している複数台の車両31~3mの中から、車両の点検依頼を受信したか否かを判断する(St81)。図14に示す例では、穴OB1を検知できなかった車両CR3からサーバ1に対し、点検依頼が送られる。サーバ1は、車両の点検依頼を受信しなかった場合(St81、NO)、第1ユースケースと同様にブロックチェーンBKC1,BKC2に基づいて、点検の対象車両を選定する(St11)。
 一方、サーバ1は、車両の点検依頼を受信した場合(St81、YES)、点検依頼をした対象車両(図14の例では車両CR3)およびその他の周辺車両(図14の例では車両CR1,CR2,CR4)に対応するブロックを新たに作成してブロックチェーンBKC1,BKC2に追加(登録)する。サーバ1は、ブロックチェーンBKC1,BKC2上に追加されたブロックに、点検の対象となるセンサ等の依頼内容を含む事前定義情報DF1、対象車両情報TRG1および周辺車両情報ASS1を記載し、または、事前定義情報DF1、対象車両情報TRG1および周辺車両情報ASS1の記載を端末21~2nのうちいずれかを選定して指示する(St82)。ステップSt82の後、サーバ1の処理はステップSt13に進む。
 また図15では、サーバ1は、ステップSt13において起動していないことが判定された対象車両に対応するブロックの保持数が許容値情報に対応する許容値まで満たない場合(St14、YES)、他の車両から点検依頼を受信したか否かを判断する(St81)。
 以上により、実施の形態1に係る第2ユースケースでは、分散型トランザクション証明システム100では、サーバ1のプロセッサ15は、複数の車両のうちいずれかの車両によるイベントの検知に基づいて、いずれかの車両以外の周辺車両にイベントの検知の可否を、通信回路14を介して問い合わせる。プロセッサ15は、過半数のイベントの正常検知通知に基づいて、イベントに対応するデータの登録指示を、通信回路14を介して複数の車両のそれぞれに送る。これにより、分散型トランザクション証明システム100によれば、イベントの検知を契機としてその検知結果の信憑性を身近な複数台の車両を用いて確認でき、信憑性の存在が得られた場合に、イベントの検知前まで知られていない未登録データを適正に登録できる。また、対象車両における点検に関するトランザクションの実行結果の改ざん防止が可能となるので、対象車両における点検結果の有効性が担保される。
 また、サーバ1のプロセッサ15は、イベントの検知が不可な車両を、対象車両として選定する。これにより、イベントの検知ができなかった車両はセンサの不具合(例えば故障)が発生している可能性があるので、サーバ1は、故障の疑いが生じた車両を点検の対象車両として早期に設定できる。
 また、イベントは、複数の車両のそれぞれが保持する地図データに存在していない障害物を検知することである。サーバ1のプロセッサ15は、地図データに存在していない障害物に関する情報を受け取り、障害物に関する情報の地図データへの更新指示を、通信回路14を介して複数の車両のそれぞれに送る。これにより、分散型トランザクション証明システム100によれば、地図データに存在していない障害物が発見された場合に、迅速にその障害物に関する情報が登録されるようになるので、車両31~3mのそれぞれが自動運転している際に、安全に道路の形状等を把握でき、交通事故あるいは交通違反の発生確率を適応的に低減可能となる。
 以上、図面を参照しながら各種の実施の形態について説明したが、本開示はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例、修正例、置換例、付加例、削除例、均等例に想到し得ることは明らかであり、それらについても当然に本開示の技術的範囲に属するものと了解される。また、発明の趣旨を逸脱しない範囲において、上述した各種の実施の形態における各構成要素を任意に組み合わせてもよい。
 なお、上述した実施の形態1では、分散型トランザクション証明システム100を構成するサーバ1、端末21~2nのそれぞれで役割を異なるように説明したが、サーバ1も端末21~2nのそれぞれも同様な構成を有するので、例えばサーバ1を端末21~2nと同様な端末として動作させ、かつ端末21~2nのうちいずれかをサーバ1と同様に動作させてもよい。これにより、サーバ1のように特別な権限(役割)を持つ装置が存在しなく、分散型トランザクション証明システム100を構成するサーバ1および端末21~2nのそれぞれが同様な権限を有することで、平等な分散型トランザクション証明システム100を構成できる。
 なお、本出願は、2018年8月22日出願の日本特許出願(特願2018-155600)に基づくものであり、その内容は本出願の中に参照として援用される。
 本開示は、身近な複数の車両のそれぞれに搭載されたセンサの不具合の点検に関するトランザクションの実行結果およびセンサの不具合の有無の検出結果をブロックチェーンで管理し、それぞれの車両で実行されたトランザクションの有効性を的確に担保するサーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法として有用である。
1 サーバ
11 操作部
12、46 メモリ
13 データ蓄積部
14、45 通信回路
15 プロセッサ
21、2n 端末
31、3m 車両
40 制御部
41 カメラ
42 LiDAR
43 ミリ波レーダ
44 その他センサ群
100 分散型トランザクション証明システム
BKC1,BKC2 ブロックチェーン
NW1 ネットワーク網

Claims (15)

  1.  複数の車両を含む分散型トランザクション証明システムを構成するサーバであって、
     前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持するメモリと、
     前記複数の車両の中から点検の対象車両を選定し、選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに追加するプロセッサと、
     前記点検に関するトランザクションの実行指示を前記対象車両に送る通信回路と、を備え、
     前記プロセッサは、前記実行指示に基づく前記対象車両における前記点検に関するトランザクションの実行結果と、前記対象車両以外の周辺車両における前記点検に関するトランザクションの実行結果とに基づく点検結果を、追加された前記対象車両の点検に関するトランザクション情報に登録する、
     サーバ。
  2.  前記プロセッサは、前記ブロックチェーンに基づいて、前記対象車両を選定する、
     請求項1に記載のサーバ。
  3.  前記プロセッサは、前記対象車両の前記点検に関するトランザクションの実行結果と一致する前記実行結果を測定した前記周辺車両が過半数である場合に、前記点検結果として正常である旨の情報を作成する、
     請求項1に記載のサーバ。
  4.  前記プロセッサは、前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果を受け取り、それぞれの前記実行結果の比較に基づき、前記対象車両の前記点検に関するトランザクションの実行結果と一致する前記実行結果を測定した前記周辺車両が過半数であるか否かを判定する、
     請求項3に記載のサーバ。
  5.  前記プロセッサは、前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果の比較結果を受け取り、前記比較結果に基づき、前記対象車両の前記点検に関するトランザクションの実行結果と一致する前記実行結果を測定した前記周辺車両が過半数であるか否かを判定する、
     請求項3に記載のサーバ。
  6.  前記プロセッサは、前記対象車両の前記点検に関するトランザクションの実行結果と一致する前記実行結果を測定した前記周辺車両が過半数に満たない場合に、前記点検結果として異常である旨の情報を作成する、
     請求項1に記載のサーバ。
  7.  前記プロセッサは、前記異常に係る前記対象車両の機能の使用制限命令を、前記通信回路を介して、前記対象車両に送る、
     請求項6に記載のサーバ。
  8.  前記プロセッサは、前記対象車両の前記点検に関するトランザクションの実行結果と一致する前記実行結果を測定した過半数の前記周辺車両に所定の報酬を付与する、
     請求項1に記載のサーバ。
  9.  前記プロセッサは、前記複数の車両のうちいずれかの車両によるイベントの検知に基づいて、前記いずれかの車両以外の周辺車両に前記イベントの検知の可否を、前記通信回路を介して問い合わせ、過半数の前記イベントの正常検知通知に基づいて、前記イベントに対応するデータの登録指示を、前記通信回路を介して前記複数の車両のそれぞれに送る、
     請求項1に記載のサーバ。
  10.  前記プロセッサは、前記イベントの検知が不可な車両を、前記対象車両として選定する、
     請求項9に記載のサーバ。
  11.  前記イベントは、前記複数の車両のそれぞれが保持する地図データに存在していない障害物の検知であり、
     前記プロセッサは、前記地図データに存在していない障害物に関する情報を受け取り、前記障害物に関する情報の前記地図データへの更新指示を、前記通信回路を介して前記複数の車両のそれぞれに送る、
     請求項9に記載のサーバ。
  12.  サーバを含む分散型トランザクション証明システムを構成する車両であって、
     前記車両の点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持する前記サーバとの間で通信する通信回路と、
     自車両の運転を含む動作を制御する制御部と、を備え、
     前記自車両が点検の対象車両として選定された場合に、
     前記通信回路は、前記点検に関するトランザクションの実行指示を受け取り、
     前記制御部は、前記実行指示に基づく前記点検に関するトランザクションの実行を制御し、前記自車両における前記点検に関するトランザクションの実行結果と他車両における前記点検に関するトランザクションの実行結果とに基づく点検結果に基づき、前記自車両の運転を含む動作を制御する、
     車両。
  13.  点検の対象となる少なくとも1つのセンサをさらに有し、
     前記制御部は、前記点検に関するトランザクションとして、所定の走行ルートの走行中に前記センサによる周辺の外部環境情報の測定結果を受け取る、
     請求項12に記載の車両。
  14.  サーバと複数の車両とが通信可能に接続された分散型トランザクション証明システムであって、
     前記サーバは、
     前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持し、
     前記複数の車両の中から点検の対象車両を選定し、選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに作成するとともに、点検に関するトランザクションの実行指示を前記対象車両に送り、
     前記対象車両は、
     前記実行指示に基づいて前記点検に関するトランザクションを実行するとともに、前記点検に関するトランザクションの実行指示を前記対象車両以外の周辺車両に送り、
     前記サーバは、
     前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果に基づく点検結果を、作成された前記対象車両の点検に関するトランザクション情報に登録する、
     分散型トランザクション証明システム。
  15.  サーバと複数の車両とが通信可能に接続された分散型トランザクション証明システムを用いた分散型トランザクション証明方法であって、
     前記複数の車両のそれぞれの点検に関するトランザクション情報を連鎖的に記録するブロックチェーンを保持するステップと、
     前記複数の車両の中から点検の対象車両を選定するステップと、
     選定された前記対象車両の点検に関するトランザクション情報を前記ブロックチェーンに作成するとともに、点検に関するトランザクションの実行指示を前記対象車両に送るステップと、
     前記実行指示に基づいて前記点検に関するトランザクションを実行するとともに、前記点検に関するトランザクションの実行指示を前記対象車両以外の周辺車両に送るステップと、
     前記対象車両および前記周辺車両のそれぞれの前記点検に関するトランザクションの実行結果に基づく点検結果を、作成された前記対象車両の点検に関するトランザクション情報に登録するステップと、を有する、
     分散型トランザクション証明方法。
PCT/JP2019/031842 2018-08-22 2019-08-13 サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法 WO2020040000A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201980054667.0A CN112585629A (zh) 2018-08-22 2019-08-13 服务器、车辆、分布式事务证明系统以及分布式事务证明方法
DE112019004199.1T DE112019004199B4 (de) 2018-08-22 2019-08-13 Server, Fahrzeug, dezentrales Transaktionsverifikationssystem und dezentrales Transaktionsverifikationsverfahren
US17/178,933 US12025463B2 (en) 2018-08-22 2021-02-18 Server, vehicle, distributed transaction verification system, and distributed transaction verification method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018155600A JP7033731B2 (ja) 2018-08-22 2018-08-22 サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法
JP2018-155600 2018-08-22

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/178,933 Continuation US12025463B2 (en) 2018-08-22 2021-02-18 Server, vehicle, distributed transaction verification system, and distributed transaction verification method

Publications (1)

Publication Number Publication Date
WO2020040000A1 true WO2020040000A1 (ja) 2020-02-27

Family

ID=69592012

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/031842 WO2020040000A1 (ja) 2018-08-22 2019-08-13 サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法

Country Status (5)

Country Link
US (1) US12025463B2 (ja)
JP (1) JP7033731B2 (ja)
CN (1) CN112585629A (ja)
DE (1) DE112019004199B4 (ja)
WO (1) WO2020040000A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6923734B1 (ja) * 2020-10-30 2021-08-25 株式会社 日立産業制御ソリューションズ 車両が行う検出を支援するシステム及び方法

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10663303B2 (en) * 2017-06-12 2020-05-26 Panasonic Intellectual Property Management Co., Ltd. System and method for dynamically authenticating map data using blockchains
CN114245915A (zh) * 2021-10-27 2022-03-25 京东方科技集团股份有限公司 交通信息处理方法、装置、电子设备、服务器和存储介质
US11979463B2 (en) * 2022-06-30 2024-05-07 Gm Cruise Holdings Llc Secure wireless update during vehicle transport

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015230665A (ja) * 2014-06-06 2015-12-21 日立オートモティブシステムズ株式会社 障害物情報管理装置
US20170075352A1 (en) * 2015-09-11 2017-03-16 Robert Bosch Gmbh Method and system for operating a motor vehicle
JP2017520815A (ja) * 2014-04-04 2017-07-27 フィリップス ライティング ホールディング ビー ヴィ 環境認知、センサの較正、及び検証によって自律型車両をサポートするシステム並びに方法
WO2017214713A1 (en) * 2016-06-16 2017-12-21 Moj.Io Inc. Analyzing telematics data within heterogeneous vehicle populations
US20180091596A1 (en) * 2016-09-27 2018-03-29 Intel Corporation Trusted vehicle telematics using blockchain data analytics
JP2019091168A (ja) * 2017-11-13 2019-06-13 トヨタ自動車株式会社 車両情報通信システムおよび環境改善システム、ならびにそれに用いられるサーバ

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004287500A (ja) * 2003-03-19 2004-10-14 Nippon Telegr & Teleph Corp <Ntt> 道路情報提供システムおよびその方法
JP2007066217A (ja) * 2005-09-02 2007-03-15 Assist Plan Kk 情報管理システム
US20170098371A1 (en) 2014-03-27 2017-04-06 Mitsubishi Electric Corporation Driving assistance information generation system, driving assistance information provision apparatus, driving assistance information generation method, and computer readable medium
JP6590653B2 (ja) 2014-11-19 2019-10-16 首都高技術株式会社 点群データ利用システム
JP6298021B2 (ja) 2015-07-30 2018-03-20 トヨタ自動車株式会社 攻撃検知システムおよび攻撃検知方法
JP6615066B2 (ja) 2016-07-29 2019-12-04 エヌ・ティ・ティ・コムウェア株式会社 情報処理装置、情報処理方法、及びプログラム
JP6533771B2 (ja) 2016-11-15 2019-06-19 富士通株式会社 通信方法、装置、及びプログラム
JP2018155600A (ja) 2017-03-17 2018-10-04 東レエンジニアリング株式会社 外観検査装置
US10663303B2 (en) 2017-06-12 2020-05-26 Panasonic Intellectual Property Management Co., Ltd. System and method for dynamically authenticating map data using blockchains

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017520815A (ja) * 2014-04-04 2017-07-27 フィリップス ライティング ホールディング ビー ヴィ 環境認知、センサの較正、及び検証によって自律型車両をサポートするシステム並びに方法
JP2015230665A (ja) * 2014-06-06 2015-12-21 日立オートモティブシステムズ株式会社 障害物情報管理装置
US20170075352A1 (en) * 2015-09-11 2017-03-16 Robert Bosch Gmbh Method and system for operating a motor vehicle
WO2017214713A1 (en) * 2016-06-16 2017-12-21 Moj.Io Inc. Analyzing telematics data within heterogeneous vehicle populations
US20180091596A1 (en) * 2016-09-27 2018-03-29 Intel Corporation Trusted vehicle telematics using blockchain data analytics
JP2019091168A (ja) * 2017-11-13 2019-06-13 トヨタ自動車株式会社 車両情報通信システムおよび環境改善システム、ならびにそれに用いられるサーバ

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6923734B1 (ja) * 2020-10-30 2021-08-25 株式会社 日立産業制御ソリューションズ 車両が行う検出を支援するシステム及び方法
JP2022072641A (ja) * 2020-10-30 2022-05-17 株式会社 日立産業制御ソリューションズ 車両が行う検出を支援するシステム及び方法

Also Published As

Publication number Publication date
DE112019004199T5 (de) 2021-05-27
US12025463B2 (en) 2024-07-02
CN112585629A (zh) 2021-03-30
DE112019004199B4 (de) 2024-08-01
JP2020030596A (ja) 2020-02-27
US20210239492A1 (en) 2021-08-05
JP7033731B2 (ja) 2022-03-11

Similar Documents

Publication Publication Date Title
WO2020040000A1 (ja) サーバ、車両、分散型トランザクション証明システムおよび分散型トランザクション証明方法
CN114270887A (zh) 车辆传感器数据获取和分发
JP2020525916A (ja) 運転中の自動運転車による非行行動を検出するシステムおよび方法
JP7035204B2 (ja) 車両制御装置、自動運転車開発システム、車両制御方法、およびプログラム
US11651632B2 (en) Diagnosis of transport-related issues
CN114724364B (zh) 车辆管控方法、装置、设备、存储介质和程序产品
US20200341485A1 (en) System and Method for Performing Differential Analysis of Vehicles
WO2021010396A1 (ja) 走行記憶システム、潜在事故責任決定装置、走行記憶方法、潜在事故責任決定方法、映像記録システム、自動運転システム、および映像記録方法
JP7379424B2 (ja) 状況固有の輸送手段パワー割り当て
JP7350814B2 (ja) 経路データに基づく輸送手段への無線エネルギー転送
JP2024505138A (ja) 輸送機関に対する外部機能のプロビジョニング
US20230356751A1 (en) Malicious event detection for autonomous vehicles
WO2024020234A1 (en) Providing recorded data related to an event
WO2020121627A1 (ja) 車両制御装置、車両、車両制御方法およびプログラム
US20240182038A1 (en) Vehicle functionality based on road segments
WO2023091722A1 (en) Robust over the air reprogramming
US11608030B2 (en) Vehicle surveillance system and early vehicle warning of potential threat
US20230074898A1 (en) Transport limitation for data reads
US20220274593A1 (en) Transport-related object avoidance
JP2024504090A (ja) セキュアなコントローラエリアネットワーク(can)トランシーバ
WO2024111389A1 (ja) 処理システム
JP2022500737A (ja) センサの画像区間の選択方法
US11794764B2 (en) Approximating a time of an issue
US12004118B2 (en) Detection of aberration on transport
US20240217508A1 (en) Micromobility detection and avoidance

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19852707

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 19852707

Country of ref document: EP

Kind code of ref document: A1