车辆用数据保存方法、车辆用数据保存系统与流程

车辆用数据保存方法、车辆用数据保存系统
1.相关申请的交叉引用
2.本技术以2020年11月9日在日本技术的日本专利申请第2020-186669号为基础，通过参照将基础申请的内容整体上引用至本技术。
技术领域
3.本公开涉及使用区块链技术来保存车辆的数据的技术。


背景技术：

4.在专利文献1中，研究了将车辆的数据保存在云上的技术。另外，近年来，如专利文献2等所公开的那样使用区块链技术来保证保存数据的可信性的系统受到关注。
5.作为区块链的代表性的一致性算法，已知有pow(proof of work：工作量证明)。pow等一致性算法规定新连结至区块链的区块的条件。
6.在pow型的区块链中，基于上一次的区块的哈希值、例如交易数据等事务、以及作为变量的随机数值(nonce值)而决定的哈希值满足规定的条件的区块被承认为与区块链连结的区块。此外，在pow型的区块链中，为以下结构：被称为矿工的多个终端循环式地搜索哈希值满足上述特定的条件的随机数值(以下，称为适当随机数值)，对最初发现该随机数值的矿工支付报酬。
7.在pow型的区块链中，在同时生成两个具有适当随机数值的区块的情况下，可能产生区块链分支的被称为分叉的现象。由于区块链以一条路径为前提，因此在产生分叉的情况下，相对较短的一方的链被无效化。其结果是，属于较短的链的区块被废弃。一般而言，在pow型的区块链中，为了抑制分叉的产生，发现适当随机数值的作业的难易度被设定得较高。其结果是，在pow型的区块链中，用于随机数值的搜索的计算量庞大，运算负荷以及功耗成为瓶颈。
8.针对这样的课题，在专利文献2中，公开了以下结构：代替随机数值的发掘，而通过导入赋予了特权的节点来保证数据的可信性，并且抑制链的分支(所谓的分叉)的产生。具体而言，特权节点生成赋予了使用了私钥的签名的区块并发送至网络。连接于网络的通常节点具有与上述私钥对应的公钥，以通过该公钥确认了从特权节点分发的区块的签名值的合法性为条件，来使该区块连结于区块链。
9.专利文献1：日本特开2019-117446号公报
10.专利文献2：日本特开2020-88864号公报
11.在如专利文献1那样将车辆的数据上传至云上的结构中，需要保证上传的数据未被篡改。这是因为若直接采用被篡改的数据，则存在使用了该车辆数据的系统/服务不能正常发挥功能的担忧。此外，不限于将车辆数据设在云上的情况，在将车辆数据本地保存在配置于车辆内的存储介质的情况下，也相同地需要保证保存数据未被篡改。
12.针对这样的课题，根据使用区块链技术在将车辆数据区块化的基础上保存的结构，能够期待提高上传至云或者本地保存于车辆内的数据的可信性。然而，在pow型的区块
链中，由于计算量庞大，因此保存处理耗费时间。若使用高性能的处理器等运算资源则能够起到计算时间的缩短效果，但成本增加。
13.另外，在pow型的区块链中，若假设几乎同时生成多个区块，则产生分叉，而相对较短的一方的链被无效化。较短的链的无效化意味着废弃一部分的车辆数据。即，本来应当保存的车辆数据被废弃。因此，需要尽可能地抑制分叉的产生。
14.根据如专利文献2所公开的那样设置了特权节点的结构，能够减轻运算时间、分叉的产生等问题，但若在特权节点产生不良情况，则存在系统变得无法动作的担忧。另外，由于设想在特权节点中需要与通常节点相比高性能并且安全的硬件，因此可能导致成本提高。


技术实现要素：

15.本公开是基于该情况而完成的，其目的在于，提供抑制导入成本，并且能够保证保存数据的可信性的车辆用数据保存方法、车辆用数据保存系统。
16.作为一个例子，用于实现该目的的车辆用数据保存方法是包含构成为能够在车辆中相互通信且具有作为共同的秘钥信息的公共密钥的多个节点，使用区块链来保存在节点中收集的数据的车辆用数据保存方法，其中，连接至区块链的区块包含签名值和事务，上述签名值是使用前一个区块的一部分和公共密钥生成的，上述事务是作为保存对象的数据，上述车辆用数据保存方法包含由多个节点的每一个节点进行以下处理：生成包含基于位于区块链的末尾的最终区块的一部分和公共密钥生成的新的签名值的区块，作为用于连结至区块链的新区块；基于生成了新区块，来对多个其它的节点分发新区块，并请求多个其它的节点对该新区块进行验证；在被从其它的节点请求了新区块的验证的情况下，使用公共密钥验证该新区块的合法性，并且将验证的结果至少发送至相当于新区块的生成源的节点；基于多个节点的过半数判定为新区块合法，来将新区块连接至区块链；以及在同一时期产生了各自生成源不同的两个新区块的验证请求的情况下，各个生成源中的至少任意一方在经过了随机或者规定的等待时间后的定时再发送新区块的验证请求。
17.根据以上的方法，将通过多数决定的原理而承认了合法性的区块连结至区块链。由于能够通过多个节点判断新创建的区块的可信性(换句话说合法性)，因此能够提高被作为连接于区块链的区块而保存的数据的可信性。另外，在同一时期产生两个新区块，验证定时重叠的情况下，由于至少任意一方的节点在随机或者规定时间后重新发送验证请求，因此能够抑制区块链分支。即，能够减少产生伴随分叉的产生的数据的消失的担忧。
18.另外，根据上述结构，各节点不需要搜索哈希值满足特定的条件的随机数值。由此，处理负荷较小，能够使用相对性能较低的廉价运算资源来实现。即，能够抑制导入成本，并且保证保存数据的可信性。
19.另外，用于实现上述目的的车辆用数据保存系统是包含构成为能够在车辆中相互通信且具有作为共同的秘钥信息的公共密钥的多个节点，使用区块链来保存在节点中收集的数据的车辆用数据保存系统，其中，连接至区块链的区块包含签名值和事务，上述签名值是使用前一个区块的一部分和公共密钥生成的，上述事务是作为保存对象的数据，多个节点的每一个节点包含：区块生成部，生成包含基于位于区块链的末尾的最终区块的一部分和公共密钥生成的新的签名值的区块，作为用于连结至区块链的新区块；验证请求部，基于
生成了新区块，来对多个其它的节点分发新区块，并请求多个其它的节点对该新区块进行验证；区块验证部，在被从其它的节点请求了新区块的验证的情况下，使用公共密钥验证该新区块的合法性，并且将验证的结果至少发送至相当于新区块的生成源的节点；区块链更新部，基于多个节点的过半数判定为新区块合法，来将新区块连接至区块链；以及仲裁部，在验证请求的定时与其它的节点重叠的情况下，在经过了随机或者规定的等待时间后的定时再发送新区块的验证请求。
20.上述的车辆用数据保存系统是执行上述的车辆用数据保存方法的系统，起到与上述方法相同的效果。
21.此外，权利要求书中记载的括弧内的附图标记表示与在作为一个例子而后述的实施方式中记载的具体元件的对应关系，并不限定本公开的技术范围。
附图说明
22.图1是表示车辆用数据保存系统的整体像的一个例子的图。
23.图2是表示ecu的结构的框图。
24.图3是用于对区块链中包含的区块的结构进行说明的图。
25.图4是区块生成相关处理的流程图。
26.图5是表示从生成区块到连结至区块链bc为止的各ecu1的工作的时序图。
27.图6是表示检测区块的碰撞的处理的一个例子的流程图。
28.图7是用于对区块的结构的变形例进行说明的图。
具体实施方式
29.以下，使用附图，对本公开的实施方式进行说明。另外，存在通过对在各实施方式中对应的构成要素标记相同的附图标记，来省略重复的说明的情况。在各实施方式中仅说明结构的一部分的情况下，关于该结构的其它的部分，能够应用先前说明的其它的实施方式的结构。另外，不仅是在各实施方式的说明中明确示出的结构的组合，只要组合上不特别产生妨碍，则即使未明确示出也能够将多个实施方式的结构彼此部分组合。而且，在多个实施方式以及变形例中描述的结构彼此的未明确示出的组合也通过以下的说明来公开。
30.图1是表示本公开所涉及的车辆用数据保存系统sys的概略性结构的一个例子的图。如图1所示，车辆用数据保存系统sys具备作为节点的多个ecu1。ecu是electronic control unit(电子控制单元)的缩写，是指电子控制装置。此处作为一个例子，对包含六个ecu1的情况进行说明，但构建系统的ecu的数量不限于此。构建系统的ecu1为三个以上即可，也可以为四个、八个等。以下，在区分六个ecu1的每一个的情况下，记载为ecu1a～1f。
31.各ecu1分别经由通信电缆连接为能够相互通信。例如各ecu1与其它的ecu1执行按照以太网(注册商标)的通信协议的数据的收发。ecu1a～1e例如以ecu1f为集线器连接为星型。此外，此处作为一个例子，假设网络构成为星型，但不限于此。作为网络拓扑，能够采用网格型、环型、总线型等多种形状。另外，也可以在某ecu1与其它的ecu1之间夹有中继装置(所谓的路由器)。并且，作为ecu1彼此的通信标准，也能够采用controller area network(控制器局域网，can是注册商标)、flexray(注册商标)等多种标准。
32.各ecu1例如能够设为构成域架构的域ecu。域ecu是统一控制从属于一个功能领域
(即，域)的多个ecu的ecu，也能够称为域控制器。例如ecu1a是车身系统的域ecu。ecu1b是ad(autonomous driving：自动驾驶)/adas(advanced driver-assistance systems：先进驾驶辅助系统)系统的域ecu。ecu1c是动力传动系统的域ecu。ecu1d是信息娱乐系统的域ecu。ecu1e是外部通信系统的域ecu。ecu1f是承担作为域间的网关的作用的ecu。此外，作为其它的方式，作为网关的作用也可以由作为外部通信系统的域ecu的ecu1e承担。对某ecu而言，也将该ecu管理的域记载为负责域。
33.以上叙述的各ecu1的作用是一个例子，能够适当地变更。多个ecu1的任一个也可以是用于保存获取数据的专用ecu。另外，多个ecu1的任一个也可以是使用dsm(driver status monitor：驾驶员状态监视器)等来监视驾驶席乘员的状态的ecu。dsm是通过对由红外线照相机等拍摄的驾驶席乘员的面部图像进行图像识别来检测眼睑的张开度等的设备。
34.另外，在本实施方式中作为一个例子，ecu1e与通信机2连接，构成为能够与配置于车辆外部的服务器sv经由广域通信网进行数据通信。通信机2是用于本车辆与其它的装置实施无线通信的装置。通信机2是用于实施符合规定的广域无线通信标准的无线通信的通信模块。作为此处的广域无线通信标准，例如能够采用lte(long term evolution：长期演进)、4g、5g等多种标准。作为通信机2，例如能够采用dcm(data communication module：数据通信模块)。本车辆通过搭载通信机2而成为能够连接于互联网的联网汽车。例如，ecu1e可以通过与通信机2的配合，向设置于云上的服务器sv发送保存于ecu1的数据的备份。
35.此外，通信机2也可以构成为通过符合广域无线通信标准的方式与其它的装置直接地，换句话说不经由基站地实施无线通信。即，广域通信部也可以构成为实施蜂窝v2x。另外，通信机2也可以构成为能够以符合规定的狭域通信标准的方式，与存在于本车辆周边的其它的移动体、路侧机直接地实施无线通信。作为狭域通信标准，能够采用ieee1609中公开的wave(wireless access in vehicular environment：车载环境中的无线访问)标准、dsrc(dedicated short range communications：专用短距离通讯)标准等任意的标准。在本公开中，也将通信距离限定在几百m以内的通信称为狭域通信。作为其它的移动体，并不仅限定于车辆，能够包含行人、自行车等。即，通信机2也可以构成为作为v2x车载器发挥功能。v2x是vehicle to x的缩写，是指将车与各种事物连接的通信技术。此外，v2x的第一个字「v」是指作为本车辆的汽车，「x」可以指行人、其他车辆、道路设备、网络、服务器等本车辆以外的多种存在。「x」能够解释为everything/something。
36.各ecu1构成为获取在负责域内产生的数据，将该获取数据通过与其它的ecu1的配合以难以篡改的状态保存。以下，对ecu1的结构进行说明。此外，数据的保存所涉及的各ecu1的结构相同。即，以下的ecu1的说明可应用于ecu1a～1f的每一个。构成为通过在各ecu1间交换的消息中附加使用了公共密钥ky的电子签名来确保消息的合法性。
37.＜关于ecu1的结构＞
38.ecu1执行收集并保存数据的记录器处理、将通过记录器处理而积累的数据区块化并与区块链bc连接的区块登记处理等。如图2所示，ecu1以包含处理器11、ram12、存储器13以及输入输出接口14(图中io)等的控制电路为主体构成。
39.处理器11是用于与ram12结合的运算处理的硬件，能够通过对ram12的访问处理来执行各种程序。存储器13是包含非易失性的存储介质的结构，储存由处理器11执行的各种程序。在存储器13中，至少存储与在负责域产生的数据的收集、提供以及监视相关的数据保
存程序。处理器11执行数据保存程序相当于执行与数据保存程序对应的车辆用数据保存方法。输入输出接口14是用于ecu1与搭载于车辆的其它的装置(包含传感器、ecu)通信的电路模块。
40.此外，此处作为一个例子，ecu1构成为使用trustzone(注册商标)技术，能够并用常规世界以及安全世界这至少两个不同的处理区域。常规世界是执行操作系统以及应用程序的通常的区域。安全世界是与常规世界隔离的区域。在安全世界中，执行用于被要求了安全的处理的安全的操作系统以及应用程序。从常规世界向安全世界的访问被处理器11的功能限制。因此，无法从常规世界识别安全世界的存在，确保了在安全世界执行的处理以及保存于安全世界的信息等的安全性。
41.在常规世界中保存数据的存储器区域(untrusted storage)能够称为常规存储器。另外，在安全世界中用于数据的保存的存储器区域(trusted storage)能够称为安全存储器。常规世界以及安全世界也可以在硬件上物理地分离，或者也可以通过硬件以及软件的协作而虚拟地分离。ecu1利用上下文切换等功能，使应用程序的执行所需的资源分离至常规世界以及安全世界。
42.＜关于ecu1的功能＞
43.ecu1具备图2所示的各种功能单元，作为例如处理器11执行保存于存储器13的数据保存程序而实现的功能单元。即，ecu1具备记录器f1、区块生成部f2、验证请求部f3、验证结果接收部f4、区块接收部f5、区块验证部f6、区块链更新部(以下，称为bc更新部)f7、仲裁部f8、以及上传器f9作为功能单元。另外，ecu1具备临时保存部m1、公共密钥存储部m2、以及区块链储存部(以下，称为bc储存部)m3，作为用途、安全等级分别不同的数据的保存区域。
44.临时保存部m1是积累作为记录器f1获取的数据且应当区块化并保存的数据的事务txn的存储区域。临时保存部m1例如使用ram12的存储区域的一部分来实现。临时保存部m1能够在常规世界内构建。
45.公共密钥存储部m2是保存有公共密钥ky的记录区域，公共密钥ky是各ecu1共同拥有的加密秘钥。公共密钥ky用于后述的区块生成处理以及接收区块的验证处理。公共密钥ky例如是预先设定的固定值。此外，作为其它的方式，各ecu1也可以构成为通过加密通信共享以规定的算法动态地生成的公共密钥ky。公共密钥存储部m2例如能够使用存储器13的存储区域的一部分来实现。公共密钥存储部m2例如能够在安全世界内构建。公共密钥ky保存于确保一定等级的安全的存储介质即可。
46.bc储存部m3是存储区块链bc的区域。本公开的区块链bc相当于通过在下一区块中包含使用前一个区块的规定部分和公共密钥ky生成的签名值，而多个区块按生成时刻的顺序连结为直链状的数据的集合。关于各区块的生成方法以及区块等，另外后述。bc储存部m3例如能够使用ram12或者存储器13的存储区域的一部分来实现。bc储存部m3例如能够在常规世界内构建。另外，图2中的bl是区块的缩写，bl1表示区块链bc的开头的区块。另外，bl2表示从开头起第二个区块。
47.记录器f1是将在包含ecu1自身的负责域内产生的各种数据保存于临时保存部m1的功能单元。记录器f1例如电连接于在负责域内构建的车载通信网络的通信总线。记录器f1经过通信总线获取在构成负责域的ecu、传感器等产生的各种数据。例如记录器f1从由构成负责域的车载传感器、ecu依次输出至通信总线的数据中选择性地提取预先设定的数据，
并将该数据作为事务txn保存于临时保存部m1。记录器f1相当于收集应当区块化并保存的数据的结构。记录器f1例如能够为在常规世界进行动作的应用程序。
48.区块生成部f2基于在临时保存部m1积累的事务txn，生成用于连结至区块链bc的区块。区块是将规定尺寸、规定数量或者规定时间以内的数据汇总储存的保存数据的单位。区块也能够称为数据区块。区块生成部f2基于已满足规定的区块生成条件，来根据保存于临时保存部m1的事务txn创建一个区块。
49.例如，如图3所示，各个区块包含区块头hd和事务txn。区块头hd例如包含区块编号和签名值。区块编号是表示是区块链bc中的第几个区块的信息。区块编号也被称为区块高度。各区块中包含的签名值是通过公共密钥ky加密哈希值而得的值(字符串)，该哈希值将该区块的事务txn与前一个区块的签名值作为原始数据。
50.此外，区块头hd除了签名值、区块编号以外，也可以包含表示成为生成源的ecu1的生成源信息、表示生成时刻的时间戳等。此外，区块头hd也可以包含在另外后述的验证处理中保证该区块的合法性的ecu1的识别信息。图中所示的区块bln表示在当前时刻位于区块链bc的末尾的区块亦即最终区块bln。另外，区块bln+1表示新创建的区块(即，新区块)。区块头hd例如能够解释为在区块中收容事务txn以外的数据的数据域。
51.区块生成部f2具有使用公共密钥ky计算签名值的功能。区块生成部f2在新生成区块时，参照保存于bc储存部m3的最终区块bln，获取该最终区块的bln的签名值作为上一次签名值。接下来，通过利用公共密钥ky对通过将上一次签名值和作为保存对象的事务txn输入至规定的哈希函数而获得的哈希值进行加密，来生成新区块的签名值亦即新签名值。这样的签名值在一个方面能够解释为电子签名。
52.以下，为方便起见，也将通过将上一次签名值和作为保存对象的事务txn输入至规定的哈希函数而获得的哈希值称为原始数据哈希值。作为哈希函数，能够采用sha256、sha-1、sha-512、sha-3、md-5、ripemd160等多种函数。sha是secure hash algorithm(安全哈希算法)的缩写。md是message digest algorithm(消息摘要算法)的缩写。ripemd是race integrity primitive evaluation integrity primitives evaluation message digest(race原始完整性校验讯息摘要)的缩写。各ecu1构成为使用共同的哈希函数来进行签名值的生成以及验证。
53.另外，区块生成部f2将使最终区块bln的区块编号增加1后的值设定为该新生成的区块编号。而且，生成将新签名值和这次的区块编号记述于区块头hd的区块。以下，也将作为由区块生成部f2生成的新的区块且还未获得连接于区块链的共识的区块记载为验证对象区块。
54.此外，区块中包含的签名值也可以是利用公共密钥ky加密上一次签名值和作为保存对象的事务txn而得的值。即，成为签名值的基础的数据亦即原始数据(换句话说源数据)也可以是上一次签名值和作为保存对象的事务txn本身。并且，在签名值的原始数据中也可以包含最终区块bln的事务txn。另外，区块生成部f2也可以不使用上一次或者新的事务txn的全部，而使用事务txn的规定位置的位串和上一次签名值来生成新签名值。例如区块生成部f2也可以基于事务txn的开头或者末尾的5～10位来创建签名值。另外，签名值的原始数据也可以仅是上一次签名值。另外，原始数据也可以仅是事务txn的规定位置的位串。但是，从事务txn的耐篡改性的观点来看，在原始数据中，优选直接或间接地包含最终区块或者新
区块中包含的事务txn的至少一部分，更优选直接或间接地包含全部的要素。此外，区块编号等区块中包含的其它的项目也可以包含于原始数据。各ecu1构成为以共同的过程来生成签名值。
55.这样的区块生成部f2基于规定的区块生成条件已成立，来生成区块。作为区块生成条件，能够采用从上一次生成区块的时刻起经过了一定的时间、在临时保存部m1积累了规定量的事务txn、产生了规定的车辆事件等。作为车辆事件，包含行驶用电源切换至接通状态以及断开状态、自动驾驶开始、以及实施部件更换等。此外，也可以将接收来自服务器sv的上传指示作为触发来生成区块。另外，区块生成部f2也可以基于被从特定的其它的ecu1指示生成区块来生成区块。例如，区块生成部f2在行驶用电源接通期间定期地创建区块。此外，此处的行驶用电源是用于车辆行驶的电源，在本车辆为汽油车的情况下是指点火电源。在本车辆为电动汽车、混合动力车的情况下，行驶用电源是指系统主继电器。
56.验证请求部f3是实施验证请求处理的结构，该验证请求处理是向其它的ecu1请求验证区块生成部f2生成的区块的处理。验证请求部f3基于区块生成部f2生成了区块，来将包含上述的新签名值的验证对象区块发送至其它的ecu1。此外，验证请求部f3也可以无前兆地向各ecu1发送验证对象区块，也可以预先与各ecu1进行规定的消息交换，在得到接下来发送验证对象区块的同意后发送验证对象区块。以下，也将请求对验证对象区块进行验证简化记载为验证请求。发送验证请求也包含发送作为验证对象区块的新区块。
57.验证结果接收部f4是从其它的ecu1接收对验证对象区块进行验证而得的结果的结构。验证结果接收部f4接收到的验证结果被输出至bc更新部f7。
58.区块接收部f5是接收从其它的ecu1发送的验证对象区块的结构。区块接收部f5将接收到的验证对象区块输出至区块验证部f6。这样的区块接收部f5相当于受理来自其它的ecu的验证请求的结构。此外，验证对象区块由于是还未决定是否连结至区块链bc的区块，因此能够称为未决区块(pending block)。各ecu1将从其它的ecu1接收到的验证对象区块、或者自身生成而来自其它的ecu1的验证结果的接收还未完成的区块登记至未决区块。
59.此外，验证请求部f3在存在未决区块的情况下，为了抑制区块链bc的分支(所谓的分叉)的产生，而不发送验证请求。但是，从其它的ecu1生成区块至接收该区块的验证请求期间，可能存在因通信处理等引起的微小的时间差。因此，例如在多个ecu1几乎同时(即，同一时期)生成新区块的情况下，未决区块可能为两个以上。在这样的情况下，由后述的仲裁部f8进行仲裁，使得未决区块为一个以下。
60.区块验证部f6根据来自其它的ecu1的验证请求，使用公共密钥ky验证区块接收部f5接收到的验证对象区块。例如区块验证部f6使用公共密钥ky对接收到的区块的签名值进行解密，提取原始数据哈希值。另外，参照保存于自身的bc储存部m3的最终区块bln，获取该最终区块的bln的签名值作为上一次签名值。接下来，通过将该上一次签名值和包含于验证对象区块的事务txn输入至哈希函数，来生成验证用的原始数据哈希值。而且，在该验证用的原始数据哈希值与从验证对象区块提取的原始数据哈希值一致的情况下，判定为是合法的(换句话说适当的)区块。另一方面，在验证用的原始数据哈希值与从验证对象区块提取的原始数据哈希值不一致的情况下，判定为是非法的(换句话说不适当的)区块。
61.以上的验证处理相当于确认电子签名、区块的匹配性的处理。具体而言，相当于判断区块编号与上一次签名值是否没有矛盾。此外，对验证对象区块的合法性进行验证的方
法不限于上述的方法。例如也可以根据通过公共密钥ky对已加密的区块进行解密而获得的位串是否与上一次签名值具有规定的对应关系，来判断区块的合法性。
62.区块验证部f6在判定为接收到的验证对象区块是合法的区块的情况下，对验证请求源的ecu1发送以承认将该区块连结于区块链bc为主旨的消息亦即承认消息。此处，也将承认消息记载为ack。另一方面，区块验证部f6在判定为验证对象区块是非法的区块的情况下，对验证请求源的ecu1发送以不承认将该区块连结于区块链bc为主旨的消息亦即否认消息。在本实施例中，也将否认消息记载为nack。ack、nack优选包含表示是关于哪个区块的验证结果的对象信息、表示进行了验证处理的ecu1(即，验证结果的发送源)的验证者信息等。
63.bc更新部f7是基于区块验证部f6中的验证结果、通过验证结果接收部f4接收到的验证结果信息，更新区块链bc的结构。bc更新部f7将由构成系统的多个ecu1的过半数(51％以上)承认了合法性的区块连结于区块链bc。bc更新部f7的详细内容另外后述。
64.仲裁部f8是检测区块的碰撞，并且在检测到区块的碰撞的情况下进行用于防止分叉的产生的仲裁的结构。此处的区块的碰撞是指从多个ecu1几乎同时发送验证对象区块。或者，区块的碰撞是指在存在验证中的区块的状况下新生成其它的区块的现象。区块碰撞能够说是验证请求的碰撞。另外，区块碰撞也能够说是区块的多重产生。
65.例如仲裁部f8在存在未决区块的状况下其它的验证对象区块到达的情况下，判定为产生区块碰撞。另外，在ecu1彼此共享未决区块的概要的结构中，也可以在各ecu1中的未决区块不一致的情况下判断为产生区块碰撞。或者，仲裁部f8也可以基于关于与自身拥有的未决区块不同的区块的ack或者nack被从其它的ecu1发送，来检测区块碰撞。
66.仲裁部f8在检测到区块碰撞的情况下，对其它的全部的ecu1或者相当于碰撞的区块的生成源的ecu1，发送表示产生了区块碰撞的消息亦即碰撞检测消息。此外，碰撞检测消息由多个ecu1中的最初检测到区块碰撞的ecu1发送即可。另外，作为其它的方式，各ecu1也可以不进行基于碰撞检测消息的发送的状况的共享，而构成为各ecu1独自判断区块碰撞的有无。
67.但是，设想由于通信延迟、处理延迟而能够检测产生了区块碰撞的定时对每个ecu1不同的情况。鉴于这样的情况，各ecu1优选构成为通过碰撞检测消息的广播等来与其它的ecu1共享产生了区块碰撞的情况。这是由于，若作为验证请求源的ecu1能够在早期识别区块碰撞的产生，则能够迅速地进行再发送控制等，而能够缩短从区块的生成到向区块链bc的连结的处理时间。
68.在检测到区块碰撞的情况下，例如各ecu1暂时废弃未决区块。另外，在各ecu1废弃了未决区块的情况下，也可以将以此为主旨的内容通知给未决区块的生成源。在本实施方式中，相当于碰撞的区块的生成源的ecu1在经过了随机的等待时间的定时对验证请求进行再发送。等待时间使用随机数来决定，将碰撞的反复的可能性抑制到最小限度。这样的等待时间也能够称为退避时间。例如等待时间可以通过随机选定多个等待时间的候选值的任意一个来决定。此外，等待时间也可以对每个ecu1预先设定。在该情况下，各ecu1的等待时间设定为各自不同的值。另外，各ecu1优选在再发送的等待期间新的区块被追加至区块链bc的情况下，根据更新后的最终区块bln的信息重新制作新区块。
69.等待时间的候选值彼此的间隔可以设定得比设想验证所需时间长，该设想验证所需时间是一个验证对象区块的验证，具体而言从验证请求的发送到获得多数决定共识为止
所需时间的设想值。例如，在设想验证所需时间为600毫秒的情况下，等待时间的候选值的集合能够设为0毫秒、1000毫秒、2000毫秒、3000毫秒、4000毫秒。当然，上述的值是一个例子，能够根据设想验证所需时间而适当地变更。例如在设想验证所需时间为300毫秒左右的情况下，等待时间的候选值的集合能够设为0毫秒、500毫秒、1000毫秒、1500毫秒、2000毫秒等。
70.上传器f9是定期地或者在产生了规定的事件的情况下，将连结于区块链bc的各区块上传至服务器sv的结构。区块的上传通过与通信机2的配合来实施。不需要全部的ecu1具备上传器f9，也可以仅一部分的ecu1具备上传器f9。例如也可以仅与通信机2连接的ecu1e具有作为上传器f9的功能。另外，也可以构成为作为网关的ecu1f进行上传。作为上传区块链bc的数据的事件，例如能够采用接收来自服务器sv的上传指示的情况、能够连接至wi-fi(注册商标)等无线lan的情况等。此外，向服务器sv的区块链bc的上传是任意的要素，也可以不实施。
71.＜关于区块生成相关处理＞
72.此处，使用图4所示的流程图，对ecu1执行的区块生成相关处理进行说明。区块生成相关处理相当于从生成区块到连接至区块链bc的一系列的处理。该说明也能够应用于任意的ecu1。图4所示的流程图在满足区块生成条件的情况下开始。例如，图4所示的流程图可以每隔一定时间执行。此处，作为一个例子，区块生成相关处理具备步骤s101～s109，但不限于此。区块生成相关处理具备的处理步骤的数量、执行顺序等能够适当地变更。此外，记录器f1对数据的收集可以与图4所示的处理流程独立地，换句话说并行地依次执行。
73.首先，在步骤s101中，区块生成部f2读取在临时保存部m1积累的事务txn，移至步骤s102。该步骤s101能够称为数据获取步骤。在步骤s102中，区块生成部f2参照位于区块链的末尾的区块亦即最终区块bln来获取上一次签名值，移至步骤s103。该步骤s102能够称为上一次签名值获取步骤。
74.在步骤s103中，区块生成部f2通过将在步骤s102中获取的上一次签名值和在步骤s101中获取的事务txn输入至规定的哈希函数来生成原始数据哈希值。然后，通过利用公共密钥ky对该原始数据哈希值进行加密，来创建用于新创建的区块的签名值(即，新签名值)。若该步骤s103的处理完成，则移至步骤s104。此外，步骤s103能够称为签名生成步骤。
75.在步骤s104中，区块生成部f2生成包含在步骤s103中生成的新签名值和在步骤s101中获取的事务txn的区块作为新区块，移至步骤s105。该步骤s104能够称为区块生成步骤。
76.在步骤s105中，验证请求部f3向连接于网络的多个其它的ecu1发送在步骤s104中生成的区块作为验证对象区块，并请求多个其它的ecu1进行验证。此外，验证对象区块的发送也可以对多个ecu1分别独立地发送，也可以一齐发送。即，验证请求部f3既可以通过单播发送验证请求，也可以通过组播或者广播来分发。步骤s105能够称为验证请求步骤或者承认请求步骤。若步骤s105完成，则移至步骤s106。
77.在步骤s106中，从发送了验证请求的ecu1接收验证结果。此外，验证结果例如可以作为表示肯定意见的ack、或者表示否定意见的nack而返回。在从发送了验证请求的全部的ecu1接收到验证结果的情况、或者从步骤s105发送起经过了规定的等待时间的情况下，移至步骤s107。除此以外，也可以在从发送了验证请求的ecu1的过半数(换句话说51％以上)
接收到ack的时刻、从发送了验证请求的ecu1的过半数接收到nack的时刻等已确定多数决定的结论的定时，移至步骤s107。该步骤s106能够称为验证结果接收步骤。
78.在步骤s107中，判断是否从发送了验证请求的ecu1的过半数接收ack。该步骤s107相当于判定是否由连接于网络的ecu1的过半数承认了新创建的区块的合法性的步骤。在从发送了验证请求的ecu1的过半数接收ack的情况下对步骤s107进行肯定判定，移至步骤s108。另一方面，在未从发送了验证请求的ecu1的过半数获得ack的情况下，对步骤s107进行否定判定，移至步骤s109。该步骤s107能够称为多数决定判定步骤。
79.在步骤s108中，bc更新部f7使在步骤s104中新创建的区块连结至区块链bc并保存于bc储存部m3，结束本流程。在步骤s109中，ecu1执行规定的错误处理。例如ecu1也可以再执行步骤s101及以后的处理作为错误处理。
80.此外，ecu1也可以在尝试一定次数步骤s101及以后的处理而在任何情况下都未获得来自过半数的承认的情况下，判定为自身中产生异常，并向外部输出规定的错误信号。另外，连接于通信机2的ecu1e也可以基于输入了错误信号，而向服务器sv报告在系统中产生异常。ecu1也可以在新区块的登记连续失败规定次数(例如3次)的情况下，将自身拥有的事务txn提供给其它的ecu1，向该其它的ecu1委托创建收容该事务txn的区块。根据这样由其它的ecu1代理创建区块的方式，即使在某ecu1中产生异常的情况下，也能够减少该ecu1的数据从记录泄漏的担忧。
81.＜关于ecu1彼此的相互作用＞
82.接下来，使用图5所示的时序图，对ecu1彼此的相互作用进行说明。图5所示的ecu-a、ecu-b、ecu-c、ecu-d是分别不同的ecu1。例如ecu-a、ecu-b、ecu-c、ecu-d能够按顺序设为ecu1a～1d。在图5中，由于纸面大小的关系而仅示出四个ecu1，但如图1所示，连接于网络的ecu1可以存在5个以上。在图5所示的例子中，ecu-a是新生成了区块的ecu1，相当于作为发出验证请求的ecu1的验证请求者、或者新区块的生成源。ecu-b～d相当于作为验证ecu-a生成的区块的ecu1的验证者。
83.首先，ecu-a若生成区块(t1)，则对各ecu-b～d分发该区块，请求进行验证(t2)。此外，在图5所示的例子中，例示了广播/组播验证对象区块的方式，但也可以对每个ecu1分别独立地收发验证对象区块。另外，ecu-a将在步骤t1中生成的区块登记至未决区块。
84.各ecu-b～d若接收来自ecu-a的区块(t3b、t3c、t3d)，则分别将接收到的区块登记至未决区块，并且执行该区块的验证处理(t4b、t4c、t4d)。然后，一旦接收区块的验证结束，就向ecu-a返回作为验证结果的ack/nack(t5b、t5c、t5d)。此外，在图5中从图的可视性的观点来看，将各ecu-b～d返回验证结果的定时较大地错开地表示。
85.此处作为一个例子，例示了作为验证者的ecu-b～d分别将验证结果仅发送至ecu-a的方式，但不限于此。各ecu1也可以将新区块的验证结果也发送至验证请求源以外的其它的ecu1。即，各ecu1也可以构成为将验证结果广播/组播至其它的全部的ecu1。根据这样全部的ecu1共享各ecu1的验证结果的结构，生成源以外的ecu1也能够在同一时期判断未决区块的合法性。其结果是，容易维持各ecu1保持的区块链bc匹配的状态。
86.ecu-a若从各ecu-b～d接收验证结果(t6)，则根据是否过半数承认了新创建区块的合法性，来判断是否连结至区块链bc。此处作为一个例子，设为从ecu-b～d的任意一个都返回ack。在该情况下，ecu-a使在步骤t1中生成的区块连结至区块链bc的末尾并保存(t7)。
87.此外，作为之后的处理，例如，ecu-a也可以将基于在步骤t6中接收到的多个验证结果的新创建区块的处置展开至其它的ecu-b～d(t8)。例如ecu-a将根据多数决定保证了合法性、或者根据多数决定未保证合法性展开至各ecu-b～d。根据该结构，各ecu-b～d能够迅速地判断是否应当使设定为未决区块的从ecu-a发送的区块连结至自身拥有的区块链bc的末尾。
88.另外，作为其它的方式，在各ecu-b～d构成为将验证对象区块的验证结果也发送至生成源以外的ecu的情况下，也能够如下那样工作。即，作为验证者的各ecu1也可以也分别通过将其它的ecu的验证结果以及自身的验证结果设为总体的多数决定来最终判定验证对象区块的合法性。在通过多数决定判断为验证对象区块是合法的区块的情况下，在各ecu-b～d中，该验证对象区块连结至各自拥有的区块链bc。根据这样的结构，也能够迅速地更新各ecu1的区块链。
89.＜关于碰撞仲裁处理＞
90.图6是表示仲裁部f8的工作的一个例子的流程图。图6所示的作为碰撞仲裁处理的处理流程具备步骤s201～s203。当然，碰撞仲裁处理具备的处理步骤的数量、执行顺序等能够适当地变更。图6所示的流程图例如由各ecu1的仲裁部f8执行。各仲裁部f8以规定的碰撞监视间隔依次开始图6所示的处理流程。碰撞监视间隔例如设定为50毫秒等与设想验证所需时间相比充分短的时间。这是因为，若碰撞监视间隔较长，则尽管产生区块碰撞，也进行关于各区块的验证，而可能产生区块链的分支(所谓的分叉)。此外，ecu1也可以构成为仅在登记了未决区块的情况下依次执行碰撞仲裁处理。
91.首先，在步骤s201中，仲裁部f8判定该仲裁部f8所属的ecu1是否拥有未决区块。在不存在未决区块的情况下对步骤s201进行否定判定，本流程结束。另一方面，在存在未决区块的情况下对步骤s201进行肯定判定，移至步骤s202。
92.在步骤s202中，判定是否从未决区块的生成源以外的ecu1接收到验证请求。例如在从未决区块的生成源以外的ecu1接收到验证对象区块的情况下，视作产生区块碰撞，移至步骤s203。另一方面，在未从未决区块的生成源以外的ecu1接收验证对象区块的情况下，视作区块碰撞未产生，结束本流程。步骤s202能够解释为判断是否接收到与未决区块不同的新的验证对象区块的处理。
93.在步骤s203中，执行用于使由区块碰撞导致的分叉不产生的处理。例如，仲裁部f8通过对各ecu1发送碰撞检测消息，来使执行中的验证处理中止。另外，仲裁部f8也可以对相当于碰撞的区块的生成源的ecu1请求再发送区块。碰撞的区块的生成源根据来自其它的ecu1的碰撞检测消息的接收、来自其它的ecu1的再发送请求、或者自身中的区块碰撞的检测，来在经过了随机的等待时间的定时发送验证请求。
94.＜关于上述结构的效果＞
95.在以上的结构中，根据作为能够信赖的节点的多个ecu1的多数决定，来判断是否使新创建的区块连结至区块链bc。由此，通过多个ecu1判断新创建的区块的可信性(换句话说合法性)，所此能够提高作为连接于区块链的区块而保存的数据的可信性。
96.另外，本公开的车辆用数据保存系统sys不是pow型的区块链。即，在本公开的结构中，各ecu1不需要实施循环式地搜索哈希值满足特定的条件的随机数值的处理(所谓的挖矿)。因此，能够抑制处理器11中的处理负荷。由此，作为处理器11、ram12等运算资源，能够
使用相对性能较低的廉价电子部件来实现。
97.此外，作为使用了不需要挖矿的区块链的其它的结构(以下，称为比较结构)，考虑如专利文献1中公开的系统那样，仅一个特权节点生成区块的中心化的结构。然而，在这样的比较结构中，若在特权节点产生不良情况，则存在保存数据的系统陷入功能不全的担忧。另外，在比较结构中，设想作为特权节点的结构，需要与通常节点相比高性能并且安全的硬件，由此可能导致成本提高。
98.相对于这样的比较结构，本公开的结构不是中心化的结构，关于区块的生成各ecu1具有大致同等的权利。具体而言，是以下结构：作为节点的多个ecu1的每一个具有独自生成区块的权限，某ecu1生成的区块基于多个其它的ecu1的验证结果而被承认向区块链bc的连结。根据这样的结构，即使在一部分的ecu1产生故障，也能够继续执行基于其它的ecu1的数据保存。由此，根据本公开的结构，与比较结构相比能够提高对故障的鲁棒性。
99.并且，在上述结构中，各ecu1构成为在检测到区块的碰撞的情况下，碰撞的区块的生成源在经过了随机的等待时间的定时重新发送区块的承认请求。由此，能够不设置特权节点就抑制分叉的产生。即，能够兼顾对故障等的鲁棒性的提高、和分叉的产生的抑制。
100.此外，生成区块的验证可以使用公共密钥ky在相对较短时间内完成。例如设想验证所需时间能够抑制为不足1秒。根据本公开的结构，由于能够高频度地生成区块，因此也能够期待抑制一个区块中包含的事务的大小增大的效果。
101.另外，根据上述实施方式的结构，将各个域的车辆数据在各ecu1分散保存。例如某ecu1的负责域的数据也被区块化而由其它的ecu1保持。由此，能够期待即使在某ecu1故障而无法提取该ecu1的保存数据的情况下，也能够从其它的ecu1获取所需的数据。
102.此外，以上，公开了使用ack/nack来决定是否使新区块连结至区块链bc的方式，但用于决定是否使新区块连结至区块链bc的判断材料不限定于此。例如，各ecu1也可以构成为将通过验证处理确认了合法性的区块分发至其它的ecu。而且，也可以构成为各ecu1在从过半数的ecu1接收到相同的区块的情况下，设为获得了多数决定共识而使该区块连结至区块链bc。各ecu1在从其它的ecu1接收到区块的情况下，优选根据该区块的区块编号、生成源信息、事务的内容等，判定是否与已接收的区块相同。
103.以上，如图3等所示，公开了将新区块中包含的签名值设为通过公共密钥ky加密以新区块的事务txn和前一个区块的签名值作为原始数据的哈希值而得的值(字符串)的方式，但不限于此。例如如图7所示，签名值也可以是将包含上一次签名值、公共密钥ky、以及新区块的事务txn的原始数据输入至规定的哈希函数而获得的哈希值。即，新签名值的生成中也可以不包含使用了公共密钥的加密这一工序。
104.在上述的情况下，作为验证处理，各ecu1将使用自身保持的最终区块的签名值、公共密钥ky、以及验证对象区块中包含的事务txn构成的数据集输入至哈希函数，由此生成验证用的哈希值。然后，在该验证用的哈希值与验证对象区块中包含的签名值相当的哈希值一致的情况下，判定为是合法的(换句话说适当的)区块即可。即，在新签名值的生成时不包含使用了公共密钥的加密这一工序的情况下，不需要将使用了公共密钥的解密这一工序包含于验证处理。
105.此外，作为签名值的原始数据的数据集例如能够设为使上一次签名值、新区块的事务txn、以及公共密钥ky以规定的顺序结合后的数据。另外，原始数据也可以是通过公共
密钥ky加密上一次签名值和新区块的事务txn而得的数据。在原始数据中，只要以某种形式与公共密钥ky相关即可，例如数据串的结合、位串的乘法/加法等。作为验证者的ecu1构成为通过与生成作为新签名值的哈希值的方法相同的方法来使用接收到的区块的事务txn等生成验证用的哈希值，并比较两者即可。
106.另外，区块生成条件不限定于上述的条件。例如各ecu1也可以构成为在车辆停车的定时起经过了随机的等待时间的定时生成区块。车辆停车的定时相对于驾驶场景的转折点，并且预计ecu1的处理负荷也与行驶中相比较低。因此，适合作为将此前的数据保存为区块的状况。另一方面，若将车辆停车的定时本身设为区块的生成触发，则由于多个ecu1一齐生成区块，因此区块碰撞的可能性提高。针对这样的担心，根据各ecu1在从车辆的停车定时起进一步经过了随机的等待时间的定时生成区块的结构，各ecu1生成区块的定时被分散。其结果是，能够将车辆的停车这样的驾驶场景的转折点设为区块的生成定时，并且能够减少产生区块碰撞的担忧。此外，车辆停车的情况能够根据车速传感器等多种车载传感器的输出信号来判断。
107.另外，以上，公开了在用于决定是否将新区块连结至区块链bc的多数决定中，生成新区块的ecu1不具有投票权的方式。换句话说，公开了在判断新区块的合法性的多数决定的总体中不包含生成源的方式。然而，作为其它的方式，生成新区块的ecu自身可以具有向保证新创建区块的合法性的一方投1票的权利。换句话说，也可以在用于决定是否也可以连结于区块链bc的多数决定的总体中包含作为生成源的ecu1。
108.另外，也可以根据连接于网络的ecu1的数量，来变更是否对新区块的生成源赋予投票权。例如在连接于网络的ecu1的数量为偶数的情况下，由于除生成源以外的ecu1的数量为奇数，因此在多数决定的原理上来说比较方便。由此，也可以构成为在连接于网络的ecu1的数量为偶数的情况下，不向生成源赋予投票权，或者使生成源的投票无效化。另一方面，在连接于网络的ecu1的数量为奇数的情况下，由于除生成源以外的ecu1的数量为偶数，因此意见可能为各一半。鉴于这样的情况，也可以在连接于网络的ecu1的数量为奇数的情况下，也向生成源赋予投票权。
109.此外，区块生成源的验证请求部f3也可以不对连接于网络的其它的全部的ecu1发送验证请求。验证请求部f3也可以构成为以规定的规则或者随机地从连接于网络的多个ecu1中选择作为验证请求目的地的ecu1。例如，验证请求部f3也可以构成为调整发送验证请求的ecu1的数量，使得进行验证对象区块的验证的ecu1的数量为奇数。
110.并且，各ecu1也可以构成为仅对连接于网络的ecu1中的能够确认是合法的终端(即能够确认身份)的ecu1发送验证请求。各ecu1也可以在车辆的行驶电源成为接通的定时，通过与其它的ecu1例如进行质询-响应方式的认证处理来识别是否是合法的终端。此外，作为身份的确认材料，也可以使用白名单等。例如，构成为登记于白名单的ecu1视为已确认身份的节点，而采用为验证请求的发送目的地。白名单例如可以由制造工厂、经销商店的作业员等登记。此外，白名单是允许通信的终端的列表，包含关于允许通信的终端的mac地址、ip地址、端口编号等信息。白名单可以包含于访问控制列表(acl：access control list)的概念。
111.以上，例示了在使用trustzone技术确保了安全的存储区域保存公共密钥ky的方式，但不限于此。能够采用通过其它的方法确保安全的存储介质作为公共密钥ky的保存目
的地。例如公共密钥ky也可以保存于nor型或者nand型的安全闪存等。另外，公共密钥ky只要是作为在各ecu1间共享的秘钥信息的符号即可，能够设为任意的字符串、数值串、或者函数。公共密钥ky相当于用于ecu1判断其它的ecu1或者区块的合法性的数据。公共密钥ky既可以是能够用于加密和解密双方的具有可逆性的秘钥，也可以是具有不可逆性的秘钥。各ecu1也可以共享加密用的私钥和解密用的公钥两种秘钥作为公共密钥ky。
112.以上，公开了针对区块碰撞的产生，使用随机的等待时间来抑制再碰撞的方式，但不限于此。作为其它的方式，也可以对每个ecu1设定优先顺序，在检测到区块碰撞的情况下，选择来自优先顺序相对较高的ecu1的验证请求，而废弃优先顺序较低的一方的验证请求。另外，也可以构成为在产生了区块碰撞的情况下，在暂时在全部ecu1中废弃未决区块的基础上，从优先顺序较高的ecu1起按顺序再发送新生成的区块的验证请求。每个ecu1的优先顺序优选鉴于ecu1处理的数据的种类来适当地设定。例如ad/adas系统的ecu1的数据由于是在产生了事故等的情况的验证中有用的数据，因此也可以使优先顺序最高。对每个ecu1的优先顺序而言，越是处理为了分析产生事故等的情况的经过、责任的所在而所需的数据的ecu，则设定得越高即可。
113.以上，公开了将构成区块链网络的各ecu1设为域ecu的方式，但不限于此。各ecu1也可以是域内的子ecu。即，本公开的车辆用数据保存系统sys也可以在域内构建。另外，本公开的车辆用数据保存系统sys也能够应用于未采用域架构的车辆，例如未导入域的概念的现有的车辆、采用区域架构的车辆。并且，连接于区块链网络的节点不限于ecu，能够采用多种计算机。也可以引用服务器sv作为节点。
114.＜附言＞
115.本公开所记载的装置、系统、以及它们的方法也可以由专用计算机实现，该专用计算机包括被编程为通过计算机程序执行一个或更多个功能的处理器。另外，本公开所记载的装置以及其方法也可以使用专用硬件逻辑电路来实现。并且，本公开所记载的装置以及其方法可以由一个或更多个专用计算机来实现，该专用计算机由执行计算机程序的处理器和一个或更多个硬件逻辑电路的组合构成。另外，计算机程序可以作为要由计算机执行的指令存储在有形非暂态计算机可读存储介质中。即，处理器11等提供的器件和/或功能可以由记录在实体存储装置的软件和执行该软件的计算机、仅软件、仅硬件或它们的组合来提供。例如处理器11具备的功能的一部分或者全部也可以实现为硬件。在将某功能实现为硬件的方式中，包含使用一个或者多个ic等来实现的方式。处理器11也可以代替cpu，而使用mpu、gpu、dfp(data flow processor：数据流处理器)来实现。处理器11也可以将cpu、mpu，gpu等多个种类的运算处理装置组合来实现。处理器11也可以实现为片上系统(soc：system-on-chip)。并且，各种处理部也可以使用fpga(field-programmable gate array：现场可编程门阵列)、asic(application specific integrated circuit：专用集成电路)来实现。各种程序储存于非迁移的实体的记录介质(non-transitory tangible storage medium)即可。作为程序的保存介质，能够采用hdd(hard-disk drive：硬盘驱动器)、ssd(solid state drive：固态硬盘)、闪存、sd(secure digital：安全数字)卡等多种存储介质。

技术特征：
1.一种车辆用数据保存方法，是包含构成为能够在车辆中相互通信且具有作为共同的秘钥信息的公共密钥的多个节点(1、1a～1f)，使用区块链来保存在上述节点中收集的数据的车辆用数据保存方法，其中，连接至上述区块链的区块包含签名值和事务，上述签名值是使用前一个上述区块的一部分和上述公共密钥生成的，上述事务是作为保存对象的数据，上述车辆用数据保存方法包含由多个上述节点的每一个节点进行以下处理：生成包含基于位于上述区块链的末尾的最终区块的一部分和上述公共密钥生成的新的签名值的上述区块，作为用于连结至上述区块链的新区块(s104、t1)；基于生成了上述新区块，来对多个其它的上述节点分发上述新区块，并请求多个其它的上述节点对该新区块进行验证(s105、t2)；在被从其它的上述节点请求了上述新区块的验证的情况下，使用上述公共密钥验证该新区块的合法性，并且将验证的结果至少发送至相当于上述新区块的生成源的上述节点(t3b～t3d)；基于多个上述节点的过半数判定为上述新区块合法，来将上述新区块连接至上述区块链(s108、t7)；以及在同一时期产生了各自生成源不同的两个上述新区块的验证请求的情况下，各个生成源中的至少任意一方在经过了随机或者规定的等待时间后的定时再发送上述新区块的验证请求(s203)。2.根据权利要求1所述的车辆用数据保存方法，其中，包含：在同时产生了各自生成源不同的两个上述新区块的验证请求的情况下，两方的生成源分别在等待随机的时间后，再发送上述新区块的验证请求。3.根据权利要求1或2所述的车辆用数据保存方法，其中，对多个上述节点分别设定优先顺序，上述车辆用数据保存方法包含：在同时产生了各自生成源不同的两个上述新区块的验证请求的情况下，两个上述新区块的生成源中的优先顺序高的上述节点生成的上述新区块被验证，另一方面，优先顺序低的上述节点生成的上述新区块被拒绝。4.根据权利要求1～3中任一项所述的车辆用数据保存方法，其中，上述新区块的上述签名值是使用上述公共密钥加密哈希值而得的值，上述哈希值通过将上述最终区块中包含的上述签名值和上述新区块中包含的上述事务输入至规定的哈希函数而获得。5.根据权利要求1～4中任一项所述的车辆用数据保存方法，其中，包含：多个上述节点分别至少在从车辆停车的定时起经过随机的等待时间后的定时，生成上述新区块。6.根据权利要求1～5中任一项所述的车辆用数据保存方法，其中，包含：上述节点在生成了上述新区块的情况下，对奇数的其它的上述节点请求对上述新区块进行验证。7.根据权利要求1～6中任一项所述的车辆用数据保存方法，其中，包含：多个节点中的任意节点经由用于实施无线通信的通信机(2)，将连结于上述区块链的上述区块上传至配置于上述车辆的外部的服务器。
8.一种车辆用数据保存系统，是包含构成为能够在车辆中相互通信且具有作为共同的秘钥信息的公共密钥的多个节点(1、1a～1f)，使用区块链来保存在上述节点中收集的数据的车辆用数据保存系统，其中，连接至上述区块链的区块包含签名值和事务，上述签名值是使用前一个上述区块的一部分和上述公共密钥生成的，上述事务是作为保存对象的数据，多个上述节点的每一个节点包含：区块生成部(f2)，生成包含基于位于上述区块链的末尾的最终区块的一部分和上述公共密钥生成的新的签名值的上述区块，作为用于连结至上述区块链的新区块；验证请求部(f3)，基于生成了上述新区块，来对多个其它的上述节点分发上述新区块，并请求多个其它的上述节点对该新区块进行验证；区块验证部(f6)，在被从其它的上述节点请求了上述新区块的验证的情况下，使用上述公共密钥验证该新区块的合法性，并且将验证的结果至少发送至相当于上述新区块的生成源的上述节点；区块链更新部(f7)，基于多个上述节点的过半数判定为上述新区块合法，来将上述新区块连接至上述区块链；以及仲裁部(f8)，在验证请求的定时与其它的上述节点重叠的情况下，在经过了随机或者规定的等待时间后的定时再发送上述新区块的验证请求。

技术总结
本发明涉及车辆用数据保存方法、车辆用数据保存系统。多个ECU(1)的每一个具有公共密钥(Ky)。各ECU(1)例如以一定时间间隔生成区块。通过区块包含利用公共密钥加密原始数据而得的签名值，该原始数据包含作为最终区块的签名值的上一次签名值和事务，从而前后的区块建立相关。各ECU(1)若生成区块则分发至各ECU(1)，请求进行验证。ECU(1)若接收其它的ECU(1)生成的区块，则使用公共密钥验证合法性，并发送验证的结果。各ECU(1)使由过半数的ECU(1)承认了合法性的区块连结至区块链。在通过多个ECU(1)同时生成区块的情况下，各ECU(1)分别在等待随机时间后发出验证请求。机时间后发出验证请求。机时间后发出验证请求。


技术研发人员：徐昕 坂本快矢统
受保护的技术使用者：株式会社电装
技术研发日：2021.10.25
技术公布日：2023/7/12