车载设备、车载设备诊断系统的制作方法

本申请基于2015年1月19日申请的日本申请编号2015－7768号的申请，在这里引用其记载内容。

本公开涉及实施车车间通信的车载设备(in-vehicleunit)以及对该车载设备进行诊断的车载设备诊断系统。

背景技术：

近年来，提出了搭载于多个车辆(也称为主车辆)的每一个车辆的车载设备与距离本设备存在于规定的范围内的其他车载设备实施不经由广域通信网的无线通信的系统。一般地，将这种车载设备彼此实施的通信称为车车间通信。

另外，还提出了像这样实施车车间通信的车载设备通过与提供规定的服务的服务提供终端(例如路侧设备)收发规定的信息，而能够享受该服务提供终端所提供的服务的系统。例如提出有车载设备将当前位置信息等与本设备相关的信息提供给服务提供终端，从而能够享受与当前位置相应的服务的系统。

此外，在专利文献1中公开了通过检测表示与其他车载设备通信时的通信状态的参数，并将该检测出的参数与预先决定出的值进行比较，来检测特定的通信错误的车载设备。另外，该专利文献1的车载设备基于该通信错误的发生次数等，来进行车载设备是否正常动作的诊断。

专利文献1:jp2012－4759a

车载设备为了与服务提供终端实施通信，并享受该服务，需要正常地执行用于享受该服务的软件。

然而，例如在控制车载设备的动作的内部系统(以下，作为控制系统)产生了不良的情况下，有因为该不良，而不能正常执行用于享受该服务的软件的情况。在不能正常执行用于享受服务的软件的情况下，无法享受该服务。因此，优选适当地诊断车载设备的控制系统是否正常动作。

然而，在车载设备的控制系统所产生的不良中，也假定有很难设定用于检测该不良的阈值的种类的不良。

例如，在车载设备的cpu使用率相对较高的状态维持一定时间以上的情况下，有控制系统产生不良的可能性。但是，车载设备的cpu使用率根据所执行的程序的种类而变化、或根据实施车车间通信的车载设备的数量等而变化。因此，维持车载设备的cpu使用率较高的状态的现象是即使在控制系统进行正常的动作的情况下也可以观测的现象。

换句话说，虽说cpu使用率为规定的阈值以上的状态持续一定时间以上，但未必控制系统没有正常地动作。在使用预先设计的(即固定的)阈值判定控制系统是否正常地动作的方式下，尽管控制系统正常地动作，也有误判定为未正常地动作的可能性。换句话也可以说，很难预先对例如cpu使用率这样的表示控制系统的状态的指标值设定用于检测控制系统的不良的适当的阈值。

技术实现要素：

本公开的目的在于提供一种能够判定车载设备的系统是否正常地动作的车载设备以及车载设备诊断系统。

根据用于实现该目的本公开的第一例，以如下的方式提供包含对象车辆和其周边的至少一个周边车辆的多个主车辆的每一个主车辆中所使用的车载设备。各主车辆所使用的车载设备具备：无线通信器，其实施基于车车间通信的信息的收发；系统信息获取部，其获取表示控制车载设备本身的动作的控制系统的状态的信息；以及指标数据生成部，其基于系统信息获取部所获取的信息，生成包含表示控制系统的状态的指标值的指标数据，经由无线通信器发送指标数据生成部生成的指标数据。对象车辆中所使用的车载设备也被称作对象车载设备，具备通信处理部、判定基准决定部、本设备诊断部。通信处理部经由无线通信器获取由作为至少一个周边车辆的车载设备的至少一个周边车载设备发送出的指标数据。判定基准决定部基于由通信处理部获取到的来自至少一个周边车载设备的指标数据，来依次决定用于判定对象车载设备所具备的控制系统是否正常动作的判定基准亦即本设备判定基准。本设备诊断部通过对由判定基准决定部决定出的本设备判定基准和对象车载设备的指标数据进行比较，判定对象车载设备的控制系统是否正常动作。

根据以上的结构，判定基准决定部使用从周边车辆的车载设备(周边车载设备)接收到的指标数据，来依次决定用于判定对象车辆的车载设备(对象车载设备)的控制系统是否正常动作的判定基准。而且，本设备诊断部对由判定基准决定部决定出的判定基准和对象车载设备的指标数据进行比较，判定该控制系统是否正常动作。

这里，提供了作为用于生成判定基准的基础的指标数据的多个周边车载设备均存在于能够与对象车载设备实施车车间通信的范围，换句话说相对较小的范围内。

由于多个周边车载设备均存在于以对象车载设备为中心的相对较小的范围内，所以对象车载设备实施车车间通信的车载设备的数量与周边车载设备分别实施车车间通信的车载设备的数量类似的可能性较高。另外，在对象车载设备与服务提供终端实施用于享受服务的通信的情况下，期待周边车载设备还与同一服务提供终端实施用于享受服务的通信。

换句话说，在对象车载设备和周边车载设备中，共用例如用于享受服务的应用程序这样的由控制系统执行的软件、对控制系统施加的负载的大小(应处理的任务的数量等)的可能性较高。在对象车载设备以及周边车载设备中所执行的软件相同、或应处理的任务的数量等类似的情况下，各车载设备的cpu使用率、存储器使用量的相似性较高。

因此，在对象车载设备正常动作的情况下，该控制系统的状态和周边车载设备的控制系统的状态相类似的可能性较高。因此，对象车载设备的指标数据应该与从周边车载设备获取到的指标数据类似。

另外，由于周边车载设备均未正常动作的可能性相对较低，所以基于从周边车载设备获取到的指标数据动态地决定的本设备判定基准表示该状况下的控制系统的正常的状态。

因此，通过对基于从周边车载设备获取到的指标数据来决定的本设备判定基准和对象车载设备的指标数据进行比较，能够判定对象车载设备的控制系统是否正常动作。

根据用于实现上述目的本公开的第二例，车载设备被包含对象车辆和其周边的至少一个周边车辆的多个主车辆的每一个主车辆使用，并以如下方式被提供。各主车辆所使用的车载设备具备：无线通信器，其实施基于车车间通信的信息的收发；系统信息获取部，其获取表示控制车载设备本身的动作的控制系统的状态的信息；指标数据生成部，其基于系统信息获取部所获取的信息，生成包含表示控制系统的状态的指标值的指标数据，使无线通信器发送指标数据生成部生成的上述指标数据。对象车辆中所使用的车载设备亦即对象车载设备具备通信处理部、判定基准决定部、他设备诊断部。通信处理部经由无线通信器获取由作为至少一个周边车辆的车载设备的至少一个周边车载设备发送出的指标数据。判定基准决定部基于通信处理部获取到的至少一个周边车载设备的指标数据，来依次决定用于判定至少一个周边车载设备中的作为规定的诊断目标的目标周边车载设备的控制系统是否正常动作的判定基准亦即他设备判定基准。他设备诊断部通过对由判定基准决定部决定出的他设备判定基准和通信处理部从目标周边车载设备获取到的指标数据进行比较，来判定目标周边车载设备的控制系统是否正常动作。

在以上的结构中，判定基准决定部使用从周边车辆的车载设备(周边车载设备)接收到的指标数据，来依次决定用于判定周边车载设备中的作为诊断目标的目标周边车辆的车载设备(目标周边车载设备)的控制系统是否正常动作的他设备判定基准。而且，他设备诊断部使用由判定基准决定部决定出的他设备判定基准，来判定作为诊断目标的周边车载设备的控制系统是否正常动作。

根据这样的结构，通过与上述的车载设备的第一例相同的作用，能够判定周边车载设备的控制系统是否正常动作。

进一步，根据用于实现上述目的本公开的第三例，提供一种具备多个车载设备的车载设备诊断系统，上述车载设备搭载于包含对象车辆及其周边的至少一个周边车辆的多个主车辆的每一个主车辆，彼此实施车车间通信。各主车辆所使用的车载设备具备：无线通信器，其实施基于车车间通信的信息的收发；各系统信息获取部，其获取表示控制车载设备本身的动作的控制系统的状态的信息；指标数据生成部，其基于系统信息获取部所获取的信息，生成包含表示控制系统的状态的指标值的指标数据，使无线通信器发送指标数据生成部生成的指标数据。作为对象车辆中所使用的车载设备的对象车载设备具备：通信处理部，其经由无线通信器获取从作为至少一个周边车辆的车载设备的至少一个周边车载设备发送出的指标数据；判定基准决定部，其基于通信处理部获取到的至少一个周边车载设备的指标数据，来依次决定用于判定至少一个周边车载设备中的作为规定的诊断目标的目标周边车载设备的控制系统是否正常动作的判定基准亦即他设备判定基准；以及他设备诊断部，其通过对由判定基准决定部决定出的他设备判定基准和通信处理部从目标周边车载设备获取到的指标数据进行比较，来判定目标周边车载设备的控制系统是否正常动作。

该车载设备诊断系统是通过具备多个作为有关车载设备的第二例具备上述结构的车载设备来实现的系统。换句话说，通过与上述的有关车载设备的第二例相同的作用，该车载设备诊断系统所具备的各车载设备能够判定其他车载设备的控制系统是否正常动作。

附图说明

通过参照附图进行下述详细的描述，有关本公开的上述目的以及其他目的、特征、优点会变得更加明确。

图1是表示本实施方式的车载设备诊断系统的简要结构的框图，

图2是表示本实施方式的车载设备的简要结构的框图，

图3是表示控制器的简要结构的一个例子的框图，

图4是表示指标数据的简要结构的一个例子的图，

图5是用于对控制器所实施的本终端诊断处理进行说明的流程图，

图6是用于对本终端诊断基准决定处理进行说明的流程图，

图7是用于对控制器所实施的其他终端诊断处理进行说明的流程图，

图8是用于对其他终端诊断处理的工作进行说明的图。

具体实施方式

以下，使用附图对本公开的实施方式图进行说明。图1是表示本公开的车载设备诊断系统100的简要结构的一个例子的图。该车载设备诊断系统100具备多个车辆的每一个车辆中各使用一个的车载设备1和设置于各车辆的外部的中心3。中心3与电话线路网、因特网等广域通信网2连接。此外，在本实施方式中，车载设备1为安装(换句话说，搭载)于车辆的结构，但作为其他方式，也可以为带入车辆内并由用户以自由拆装的方式安装于支架等的结构。图1中的用附图标记a、b表示的车辆表示搭载有车载设备1的车辆。

搭载于各车辆的车载设备1使用预先分配的频带的电波，与存在于本终端周边的其他车载设备1进行不经由广域通信网2的无线通信(所谓的车车间通信)。车车间通信所使用的频带例如是700mhz频段的电波、5.8～5.9ghz频段、2.4ghz等。这里的所谓的本终端周边是指能够实施车车间通信的范围。能够进行车车间通信、路车间通信的范围可以适当地设计，多数情况下设计于数十m～数百m。

将车辆a也称为对象(主题)车辆或者第一车辆，将存在于车辆a的周边的至少一台或者多台车辆b也称为周边车辆、其他车辆或者第二车辆，对该车载设备诊断系统100以及车载设备1进行说明。图1所示的周边车辆b是搭载有与搭载于对象车辆a的车载设备1实施车车间通信的车载设备1的车辆。此外，这些对象车辆、周边车辆的关系是相对地确定的，若假设将车辆b设为对象车辆，则当然车辆a为对于车辆b来说的周边车辆。另外，搭载车载设备1的车辆也被称作主车辆，车辆a、车辆b都与此对应。

在区分搭载于对象车辆a的车载设备1和搭载于周边车辆b的车载设备1的情况下，将搭载于对象车辆a的车载设备设为车载设备1a，也称作第一车载设备1a、对象(主题)车载设备1a。另一方面，将搭载于周边车辆b设为车载设备1b(换句话说周边车载设备)，也称作第二车载设备1b、其他车载设备1b。因此，存在至少一个或者多个周边车载设备。另外，在将对象车载设备1a设为本设备的情况下，将周边车载设备1b称作他设备，在将周边车载设备1b设为本设备的情况下，将对象车载设备1a称作他设备。

此外，各车载设备1也可以使用预先分配的频带的电波，与设置于道路上或者沿着道路设置的路侧设备进行不经由广域通信网2的无线通信(所谓的路车间通信)。各车载设备1依据用于进行车车间通信、路车间通信的规定的通信标准，进行车车间通信、路车间通信。例如，车载设备1也可以依据ieee1609.0(guideforwirelessaccessinvehicularenvironment)的标准，来实施车车间通信、路车间通信。以下，在不区分车载设备1和路侧设备的情况下，仅称为通信终端。

车载设备诊断系统100所具备的通信终端的每一个通信终端设定有用于分别识别多个通信终端的识别编码(为终端id)。另外，由各通信终端发送的数据中包含有该发送终端的终端id，接收到数据的通信终端能够根据该数据所包含的终端id来确定发送终端。

而且，车载设备1通过与对车载设备1提供规定的服务的服务提供源所管理的通信终端(为服务提供终端)实施路车间通信或者车车间通信，来进行用于享受该服务提供终端所提供的服务的处理。服务提供终端既可以是路侧设备，也可以是搭载于车辆的车载设备1。作为服务提供终端所提供的服务的一个例子，有“免下车”(drivethrough)时的自动结算、收费停车场中的停车费的自动结算、交叉路口的通行的辅助或交通阻塞信息的提供等。

(有关车载设备1的结构)

接下来，使用图2，对车载设备1的简要结构进行说明。如图2所示，车载设备1具备控制器11、狭域通信器12、广域通信器13以及gnss接收器14。控制器11与狭域通信器12、广域通信器13以及gnss接收器14的每一个以能够相互通信的方式连接。

狭域通信器12具备能够收发车车间通信、路车间通信所使用的频带的电波的天线，经由该天线，与存在于本终端周边的其他通信终端(车载设备1、路侧设备)实施无线通信。更具体而言，狭域通信器12对由天线接收到的信号进行解调并输出至控制器11，并且对从控制器11输入的数据进行调制，进一步转换为电波并发送。该狭域通信器12也被称作无线通信器。

广域通信器13与广域通信网2连接，并实施与中心3的通信。广域通信器13对经由广域通信网2接收到的信号进行解调并提供给控制器11，并且对从控制器11输入的基带信号进行调制，并发送至中心3。

gnss接收器14接收来自gnss(globalnavigationsatellitesystem)中所使用的卫星(为gnss卫星)的电波，从而获取表示gnss接收器14的当前位置的信息。gnss接收器14所获取到的当前位置例如也可以用纬度、经度、高度来表示。高度是表示距离规定的基准面(例如海面)的高度的距离即可。此外，信息不仅为不可数，即使为可数也可使用。

gnss接收器14所获取到的位置信息被依次(例如每隔100毫秒)提供给控制器11。此外，在该实施方式中，gnss接收器14是任意的要素，也可以不具备。gnss接收器14也被称作位置信息获取器。

控制器11也被称作电子控制单元、控制电路。在本实施方式中，作为一个例子，构成为通常的计算机，具备公知的cpu111、存储器112、储存器113、i/o以及对这些结构进行连接的总线等。存储器112例如可以由ram等临时存储介质来实现，作为公知的主存储装置来发挥功能。储存器113可以由rom、闪存等非易失性的存储介质来实现，作为公知的辅助存储装置来发挥功能。

储存器113中储存有用于执行各种处理的软件、数据、分配给车载设备1的终端id等。这里的所谓的软件例如包含操作系统、用于享受上述的服务提供终端所提供的服务的应用程序软件等。此外，在本实施方式中，各车载设备1中安装有相同的软件。

该控制器11在本实施方式中作为一个例子，为通过上述的软件实现的功能模块，如图3所示，具备系统管理部f1、系统信息获取部f2、指标数据生成部f3、狭域通信控制部f4、指标数据管理部f5、正常范围决定部f6、本终端诊断部f7、其他终端诊断部f8、广域通信控制部f9、本终端异常通知部f10以及其他终端异常通知部f11。此外，控制器11所执行的功能的一部分或者全部也可以通过一个或者多个ic等以硬件的方式构成。该控制器11也被称作控制系统。另外，cpu111也被称作中央处理部。

系统管理部f1对同与控制器11连接的设备的通信进行管理、或在控制器11发生了故障的情况下从该故障状态恢复、或进行数据输入输出的协调。另外，系统管理部f1进行向控制器11供给的电源的管理、系统时刻的修正、执行中的应用程序、工序的管理等。系统时刻基于gnss接收器14接收到的来自gnss卫星的电波来进行修正。

进一步，在产生了预先决定出的异常现象的情况下，将该异常现象作为诊断信息，记录于储存器113。所谓的作为诊断信息记录的异常现象例如相当于同与控制器11连接的设备的通信失败、应连接的设备未连接(或者无法识别)的现象。此外，在储存器113中用于记录诊断信息的区域的尺寸为恒定值，在该存储区域满了的情况下，删除旧的信息。

系统信息获取部f2获取本终端的系统信息。这里的所谓的系统信息相当于系统时刻、存储器112的使用量、cpu111的使用率、储存器113的空闲容量、不良扇区量、诊断信息等。

指标数据生成部f3基于系统信息获取部f2所获取到的系统信息生成包含表示本终端的控制器11的状态(动作状况等)的指标值的指标数据。例如，如图4所示，指标数据作为指标值包含当前的系统时刻、平均存储器使用量、平均cpu使用率、储存器空闲容量、不良扇区量、诊断历史信息。

平均存储器使用量是距离当前时刻过去一定时间(例如数秒等)以内的存储器使用量的平均值。此外，指标数据也可以代替平均存储器使用量，而包含最新的存储器使用量，进一步也可以包含平均存储器使用量和最新的存储器使用量双方。

平均cpu使用率是距离当前时刻过去一定时间以内的cpu使用率的平均值。此外，指标数据也可以代替平均cpu使用率，而包含最新的cpu使用率，进一步也可以包含平均cpu使用率和最新的cpu使用率双方。

储存器空闲容量表示储存器113的空闲容量，所谓的不良扇区量表示在储存器113中不能保存数据的扇区的量。诊断历史信息是距离当前时刻一定时间(例如10秒～数分)以内的诊断信息。诊断历史信息是在一定时间以内，产生规定的异常现象的频率、表示其种类的信息。

当然，以上例示出的指标数据的内容是一个例子，并不限于此。也可以包含上述以外的种类的指标值。另外，无需包含上述所有的种类的指标值。并且，这里例示出将多种指标值包含于指标数据的方式，但指标数据至少包含1种指标值即可。此外，例如，也可以代替各种平均值，而包含在统计学中所使用的中央值、方差、标准偏差等。另外，指标数据也可以包含安装于本终端的软件的版本信息。

对由指标数据生成部f3生成的指标数据赋予表示生成时刻的时间戳并储存于存储器112。另外，若指标数据生成部f3生成指标数据，则将该所生成的指标数据提供给狭域通信控制部f4。

指标数据生成部f3生成指标数据的时机可以适当地设计，例如，可以每隔一定时间生成，也可以是后述的狭域通信控制部f4开始与路侧设备的通信的情况。另外，也可以为从其他车载设备1接收到请求实施将该车载设备1(或者其主车辆)设为诊断目标的后述的其他终端诊断处理的信号的情况。诊断目标的车载设备也被称作目标车载设备，诊断目标的主车辆也被称作目标周边车辆。

狭域通信控制部f4对狭域通信器12的动作进行控制，并且获取狭域通信器12接收到的数据。另外，对狭域通信器12输出、发送应发送至其他车载设备1、路侧设备的数据。换句话说，狭域通信控制部f4也作为实施与其他车载设备1、路侧设备收发数据的接口发挥功能。

例如狭域通信控制部f4在被指标数据生成部f3提供指标数据的情况下，生成包含该指标数据的发送用数据，并使其发送至狭域通信器12。发送用数据根据在车车间通信的通信标准中所采用的数据/格式生成即可，例如，也可以为将包含车载设备1的终端id等的报头赋予给指标数据而成的数据。

另外，狭域通信控制部f4在获取到包含由其他车载设备1发送出的指标数据的数据的情况下，将该指标数据与发送源的终端id建立对应关系并提供给指标数据管理部f5。该狭域通信控制部f4也被称作通信处理部。

指标数据管理部f5按照每个发送源的车载设备1对由狭域通信控制部f4提供的从其他车载设备1发送出的指标数据进行区分并保存于存储器112。每个车载设备1的指标数据例如也可以按照接收顺序排序并保存。另外，也可以依次废弃一定时间以上的过去的数据。

正常范围决定部f6决定用于诊断本终端的诊断基准、用于诊断其他车载设备1的诊断基准。诊断基准规定与规定的多个诊断项目的每一个对应的正常范围。正常范围表示能够视为该诊断项目正常的范围的上限和下限。该正常范围决定部f6也被称作判定基准决定部。

这里，作为一个例子，多个诊断项目与指标数据所包含的项目对应。换句话说，诊断项目为系统时刻、平均存储器使用量、平均cpu使用率、储存器空闲容量、不良扇区量、异常现象的产生频率。异常现象的产生频率基于诊断历史信息来诊断。当然，诊断项目并不限于这里例示出的内容。对于一部分项目，也可以不设为诊断项目。

正常范围决定部f6基于从周边车载设备1b接收到的指标数据来决定上述的诊断基准。另外，在本实施方式中，作为更加优选的方式，基于从作为诊断的对象的车载设备1以外的周边车载设备1b接收到的指标数据来决定。

例如，用于诊断本终端的诊断基准基于从周边车载设备1b接收到的指标数据来决定。另外，在将周边车载设备1b中的任意一个周边车载设备1b(或者其主车辆)设为诊断目标的情况下，其诊断基准基于从作为诊断目标的周边车载设备1b以外的周边车载设备1b接收到的指标数据来决定。

此外，在将周边车载设备1b中的任意一个周边车载设备1b设为诊断目标的情况下，除了从作为诊断目标的周边车载设备1b以外的周边车载设备1b接收到的指标数据以外，也可以使用本终端的指标数据来决定诊断基准。

对于该正常范围决定部f6的工作另外后述。以下，用于诊断本终端的诊断基准也称为本终端诊断基准，用于诊断其他车载设备1的传感器的诊断基准也称为其他终端诊断基准。本终端诊断基准也被称作本设备判定基准或者主题设备判定基准，其他终端诊断基准也被称作他设备判定基准。

本终端诊断部f7通过对由正常范围决定部f6决定出的本终端诊断基准所示的每个诊断项目的正常范围和本终端的指标数据进行比较，来判定本终端的控制器11是否正常动作。有关该本终端诊断部f7的详细内容，另外在图5所示的流程图的说明中提及。本终端诊断部也被称作本设备诊断部或者主题设备诊断部。

其他终端诊断部f8通过对由正常范围决定部f6决定出的其他终端诊断基准所示的每个诊断项目的正常范围和从作为诊断目标的周边车载设备1b获取到的指标数据进行比较，来判断作为诊断目标的周边车载设备1b的控制部是否正常动作。有关该其他终端诊断部f8的详细内容，另外在图7所示的流程图的说明中提及。其他终端诊断部f8也被称作他设备诊断部。

广域通信控制部f9对广域通信器13的动作进行控制，并且获取广域通信器13接收到的数据。另外，使应发送给中心3的数据输出并发送至广域通信器13。

在本终端诊断部f7判定为本终端的控制器11未正常动作的情况下，本终端异常通知部f10请求广域通信控制部f9将本终端的控制器11未正常动作的意思的消息(为本终端异常通知)发送给中心3。广域通信控制部f9基于来自本终端异常通知部f10的请求，将本终端异常通知发送给中心3。本终端异常通知也可以包含有本终端的终端id，另外，作为更优选的方式，包含诊断为未正常动作的依据(诊断项目等)的信息等。本终端异常通知部f10也被称作本设备异常通知部或者主题设备异常通知部。

在其他终端诊断部f8判定为作为诊断目标的周边车载设备1b的控制部未正常动作的情况下，其他终端异常通知部f11请求广域通信控制部f9将表示其周边车载设备1b的控制部未正常动作的意思的消息(为其他终端异常通知)发送给中心3。广域通信控制部f9基于来自其他终端异常通知部f11的请求将其他终端异常通知发送给中心3。其他终端异常通知也可以包含作为诊断目标的周边车载设备1b的终端id，作为更为优选的方式，包含诊断为未正常动作的依据等。其他终端异常通知部f11也被称作他设备异常通知部。

(关于中心3)

中心3构成为与广域通信网2连接，并能够经由广域通信网2与车载设备诊断系统100所具备的各车载设备1相互通信。中心3既可以是由一个服务器装置构成，也可以由多个服务器装置构成。

中心3在从某个车载设备1接收到本终端异常通知的情况下，例如，对该车载设备1进行用于进行维护的人员的安排。另外，在预先具备对车载设备1的终端id和用户的联络地址(例如邮件地址)建立有对应关系的数据的情况下，也可以对该联络地址通知车载设备1未正常动作的意思。

在接收到其他终端异常通知的情况下也同样地、对产生异常的车载设备1安排用于进行维护的人员、或对该产生了异常的车载设备1的用户通知利用中的车载设备1的传感器产生了异常的意思。

(关于本终端诊断处理)

接下来，使用图5所示的流程图，对车载设备1的控制器11诊断本终端的处理(为本终端诊断处理)进行说明。为了方便，为了区分进行该处理的车载设备1和其他车载设备1，将车载设备1a作为该处理的主体来进行说明。

所记载的流程图包含多个部分(或者称作步骤)，各部分例如被表示为s10。并且，各部分能够分割为多个子部分，另一方面，多个部分也能够组合而成为一个部分。各部分能够作为设备、模块、单元或者固有名(例：探测器)来提及。另外，部分不仅作为(i)与硬件单元(例如，计算机)组合的软件的部分，还能够作为(ii)硬件(例如，集成电路、布线逻辑电路)的部分，包含或者不包含相关的装置的功能地实现。进一步，硬件的部分也能够包含于微型计算机的内部。

该流程图例如也可以以车载设备1a的指标数据生成部f3生成指标数据为触发而开始。当然，也可以适当地设计开始本终端诊断处理的条件，例如也可以是从周边车载设备1b获取指标数据的情况。另外，在车载设备1a与规定数量以上的周边车载设备1b实施车车间通信的情况下，也可以在指标数据生成部f3生成指标数据的情况下开始。其他，也可以在车载设备1a与未图示的路侧设备开始路车间通信的情况下开始。

首先，在s10中正常范围决定部f6实施本终端诊断基准决定处理并移至s11。该s10中的本终端诊断基准决定处理是基于从周边车载设备1b接收到的指标数据，来决定每个规定的诊断项目的正常范围，换句话说本终端诊断基准的处理。

将该本终端诊断基准决定处理的更为具体的处理过程的一个例子示于图6的流程图。首先，在s101中，提取储存于存储器112的从周边车载设备1b接收到的指标数据中的作为用于生成本终端诊断基准的母集的指标数据，并移至s102。

这里，作为一个例子，作为用于决定本终端诊断基准的母集，提取从周边车载设备1b接收到的指标数据中的在比指标数据生成部f3生成指标数据的时刻过去一定时间以内接收到的指标数据。

这里的一定时间，从诊断精度的观点来考虑，例如优选为发送指标数据的周期、数秒～数十秒左右的相对较短的时间。这是因为本车载设备诊断系统100是基于某个车载设备1(这里是本终端)的控制器11的状态与存在于其周边的车载设备1的控制器11的状态相类似的可能性较高这样的假定，来对车载设备1的控制器11进行诊断的。

具体而言如下所述。控制器11的状态例如cpu111的使用率、存储器112的使用量根据由cpu111执行的应用程序、工序而不同。更具体而言，本终端实施车车间通信的车载设备1b的数量越多，应处理的事件的数量越增加，并且由于因临时储存的数据的数量增加，所以cpu111的使用率、存储器112的使用量增加。

另外，在本终端与服务提供终端实施用于享受服务的通信的情况下，cpu111的使用率、存储器112的使用量受到为了享受该服务而执行的应用程序的影响。假定为了享受服务提供终端所提供的服务，而由cpu111执行的应用程序、工序根据所享受的服务的种类而不同。

然而，这意味着在假设多个车载设备1与同一服务提供终端通信的情况下，在这些车载设备1中所执行的应用程序、工序共用的可能性较高。在各车载设备1中所执行的应用程序、工序相同的情况下，各车载设备1的cpu使用率、存储器使用量的相似性升高。

然而，周边车载设备1b是对本终端来说存在于能够进行车车间通信的范围内的车载设备1。因此，本终端实施车车间通信的车载设备1的数量与周边车载设备1b实施车车间通信的车载设备1的数量相类似的可能性较高。另外，在本终端与服务提供终端实施用于享受服务的通信的情况下，期待周边车载设备1b还与同一服务提供终端实施用于享受服务的通信。

换句话说，在本终端的控制器11正常动作的情况下，本终端的控制器11的状态与周边车载设备1b的状态相类似的可能性较高。换句话说，在本终端的控制器11的状态与周边车载设备1b的状态不类似的情况下，提示存在本终端的控制器11未正常动作的可能性。因此，通过对本终端的控制器11的状态和周边车载设备1b的状态进行比较，能够判定本终端的控制器11是否正常动作。

然而，各终端中的控制器11的状态时时刻刻发生变化。因此，与诊断目标从车载设备1的指标数据的生成时刻偏离了一定时间以上的时刻接收到的指标数据是不适合作为本终端的控制器11是否正常动作的判断材料的数据的可能性较高。

因此，优选作为从储存于存储器112的指标数据中选定作为用于决定本终端诊断基准的母集的指标数据的条件来使用的一定时间尽可能短。当然，若该一定时间过短，则作为母集提取的指标数据的数量变少。母集采用时间也可以鉴于上述的折衷选择适当地决定。

此外，在该一定时间以内存在多个从同一车载设备1接收到的指标数据的情况下，采用接收时刻最新的指标数据。另外，这里，采用在比指标数据生成部f3生成指标数据的时刻过去一定时间以内接收到的指标数据，作为用于决定本终端诊断基准的母集，但并不限定于此。也可以采用从指标数据生成部f3生成指标数据的时刻开始经过母集采用时间为止接收到的指标数据，作为母集。另外，也可以采用在指标数据生成部f3生成指标数据的时刻的前后母集采用时间以内接收到的指标数据作为母集。

在s102中，判定在s101中提取出的指标数据的数量是否存在规定的数量以上。这里的规定的数量意味着尽量设定具有充分的信赖度的诊断基准的数量。例如，在基于较少的指标数据来决定诊断基准的情况下、且假设该指标数据中包含有来自未正常动作的车载设备的指标数据的情况下，存在所决定出的诊断基准也相对较强地受到了其影响，而成为不适当的基准的可能性。

因此，优选诊断基准基于尽量设定具有充分的信赖度的诊断基准的数量以上的指标数据来决定。尽量设定具有充分的信赖度的诊断基准的数量可以适当地设计，这里为5个。此外，作为其他方式，规定的数量也可以是一个。

在提取出的指标数据的数量存在规定的数量以上的情况下，移至s103。另一方面，在提取出的指标数据的数量不足规定量的情况下，移至s104。

在s103中，基于在s101中提取出的多个指标数据，来决定每个诊断项目的正常范围。首先，基于在s101中提取出的多个指标数据，对指标数据所包含的每个项目，计算其代表值。由于多个指标数据均是从不同的周边车载设备1b接收到的数据，所以当然假定即使是有关相同的项目的值，其值也按照每个指标数据而不同(偏移)。所谓的某个项目的代表值是代表性地表示多个指标数据的每一个指标数据中的该项目的值的值。

某个项目的代表值也可以是将多个指标数据的每一个指标数据中的该项目的值决定为母集的统计学等中所使用的平均值，也可以是中央值。另外，也可以是对平均值加上标准偏差所得的值，进一步也可以是对平均值加上2倍的标准偏差所得的值。对每个项目，将什么样的值设为代表值可以适当地设计。这里，作为一个例子，对于所有项目，都为将各指标数据中的该项目的值决定为母集的平均值。

而且，各项目的正常范围的下限为对该项目的平均值减去2倍的标准偏差的值所得的值，上限为对平均值加上2倍的标准偏差的值所得的值。当然，各项目的正常范围的决定方法并不局限于上述，可以适当地设计。

例如，也可以为某个项目的正常范围的上限为对该项目的代表值加上规定的值后所得的值，下限为对该项目的代表值减去规定的值后所得的值。另外，某个项目的正常范围的上限和下限的某一方也可以不依赖代表值而为固定的值。

进一步，也可以为某个项目的正常范围的上限为对该项目的代表值乘以规定的上限用系数后所得的值，下限为对该项目的代表值乘以规定的下限用系数后所得的值。也可以适当地设计为上限用系数为1以上的值，下限用系数为小于1的值。例如，在将某个项目的上限用系数设为1.3、将下限用系数设为0.7的情况下，该项目的正常范围为成为代表值的±30％的范围。

如以上那样，若决定每个诊断项目的正常范围(换句话说本终端诊断基准)，则返回到作为调出源的处理的本终端诊断处理(图5)，移至s11。

在s104中，结束该本终端诊断基准决定处理以及作为本流程的调出源的本终端诊断处理。

在图5的s11中，本终端诊断部f7判定指标数据生成部f3所生成的(换句话说，本终端的)指标数据中所包含的各项目的值是否收敛于在s10中决定出的每个诊断项目的正常范围。

例如，本终端诊断部f7判定本终端的系统时刻是否收敛于由正常范围决定部f6对系统时刻决定出的正常范围。本终端诊断部f7判定本终端的平均存储器使用量是否收敛于对平均存储器使用量决定出的正常范围。对于其他项目，也同样地对有关本终端的信息和正常范围进行比较，来判定是否收敛于其正常范围。

这里，各种正常范围基于存在于本终端周边的车载设备1b的指标数据来决定。因此，所谓的判定本终端的某个项目的值(例如平均存储器使用量)是否收敛于对该项目决定出的正常范围，换句话说，相当于判定本终端中的该项目的值是否为与周边车载设备1b相同的值。例如，本终端的系统时刻是否收敛于对系统时刻决定出的正常范围的判定相当于判定本终端的系统时刻与周边车载设备1b的系统时刻的偏离程度是否处于规定的允许范围内。

而且，本终端的某个项目的值未收敛于对该项目决定出的正常范围意味着关于该项目，本终端进行与周边车载设备1b不同的举动。本终端进行与周边车载设备1b不同的举动提示存在本终端产生不良的可能性。

在该s11中，若对于指标数据生成部f3所生成的指标数据所包含的全部的项目，完成该项目的值是否收敛于在对应的正常范围内定义的范围的判定，则移至s12。

在s12中，判定s11的判定的结果即本终端的控制器11是否正常动作。判定是否正常动作的条件(异常判定条件)可以适当地设定。例如，也可以在多个诊断项目中，哪怕只有一个脱离正常范围的项目的情况下，也判定为本终端的控制器11未正常动作。另外，也可以在多个诊断项目中，脱离正常范围的项目的数量为规定的数量(例如3个)以上的情况下，判定为本终端的控制器11未正常动作。

这里，作为一个例子，在多个诊断项目中，哪怕只有一个脱离正常范围的项目的情况下，就判定为控制器11未正常动作。对于因各诊断项目脱离正常范围，而判定为控制器11未正常动作的理由，简单提及。

例如，所谓的本终端的系统时刻脱离对系统时刻决定出的正常范围的情况意味着本终端的系统时刻较大地偏离周边车载设备1b的系统时刻。本终端的系统时刻偏离周边车载设备1b的系统时刻意味着本终端无法获取用于修正系统时刻的数据(即，来自gnss卫星的信号)。

换句话说，存在与gnss接收器14的物理的通信接口部分产生不良、或用于控制gnss接收器14的设备驱动器产生不良的可能性。因此，也可以在本终端的系统时刻脱离正常范围的情况下，判定为本终端的控制器11未正常动作。

当然，虽说本终端的系统时刻与周围偏离，也未必会产生上述的不良。因为例如本终端存在于隧道、立体停车场等来自gnss卫星的电波到达不了的环境的情况下，无法获取来自gnss卫星的信号，而系统时刻偏离。对于防止这样的误判定的方式，另外在变形例中后述。

另外，在本终端的平均存储器使用量偏离正常范围的情况下，换句话说较大地偏离周边车载设备1b的平均存储器使用量的情况下，只有本终端存在应执行的应用程序的起动失败、或者执行不适当的应用程序、或存储器112的释放失败的可能性。因此，也可以在本终端的平均存储器使用量偏离正常范围的情况下，判定为本终端的控制器11未正常动作。

在平均cpu使用率脱离正常范围的情况下，也可以根据与平均存储器使用量脱离其正常范围的情况相同的理由，判定为本终端的控制器11未正常动作。

由于安装于各车载设备1的软件相同，所以在储存器113中储存有程序的数据的大小也应该相同。另外，由于储存器113本身的存储容量也相同，所以车载设备1彼此的储存器空闲容量也应该相等。

换句话说，所谓的储存器空闲容量脱离正常范围的情况提示存在本终端的储存器113中保存有本来不应该保存的程序的可能性。因此，在储存器空闲容量脱离正常范围的情况下，判定为控制器11未正常动作。此外，这里，指标数据包含储存器空闲容量，也可以包含储存器113的使用量。

所谓的不良扇区量脱离正常范围的情况存在储存器113的初始不良等可能性。因此，也可以在不良扇区量脱离正常范围的情况下，判定为控制器11未正常动作。

诊断历史信息也可说是表示一定时间以内的规定的异常现象的产生频率的信息。正常范围决定部f6根据诊断历史信息决定的正常范围是每一定时间内的异常现象的产生频率的允许范围。此外，这里的所谓的异常现象如上所述，是同与控制器11连接的设备的通信错误等能够观测的现象，是预先决定出的种类。

在本终端的控制器11未正常动作的情况下，假定一定时间以内的异常现象的产生频率比周边车载设备1b的控制器11大。因此，也可以在本终端的诊断历史信息所示的异常现象的产生频率脱离正常范围的情况下，判定为本终端的控制器11未正常动作。

此外，例如，也有因车载设备1所处的外部环境，即使控制器11正常动作，也频发异常现象的情况。例如，在作为异常现象定义有gnss接收器14无法接受gnss电波的情况下，在隧道行驶时等，记录表示无法接收gnss电波的意思的诊断信息。

但是，在本终端存在于隧道等本身就无法接收gnss电波的环境下的情况下，多次记录表示无法接收gnss电波的意思的诊断信息是正常的工作。因此，在根据异常现象的产生频率是否为规定的阈值以上来判定控制器11是否正常动作的方式下，存在因外部环境的影响而进行误判定的可能性。

然而，在本终端存在于无法接收gnss电波的环境下的情况下，周边车载设备1b也存在于无法接收gnss电波的环境下的可能性较高。换句话说，在周边车载设备1b中与本终端相同地记录表示无法接收gnss电波的意思的诊断信息。其结果，基于从周边车载设备1b获取到的诊断历史信息设定的正常范围为反映外部环境的影响的范围。

因此，根据本实施方式的方式，能够减少尽管正常动作，也判定为未正常动作的可能性。

对于s12的判定处理的结果，在异常判定条件充足的情况下，s12为“是”，并移至s13。另一方面，对于s12的判定处理的结果，在异常判定条件不充足的情况下，s12为“是”，并结束本流程。

在s13中，本终端异常通知部f10请求广域通信控制部f9将本终端异常通知发送至中心3。而且，广域通信控制部f9基于来自本终端异常通知部f10的请求将本终端异常通知发送至中心3，并结束本流程。

(关于其他终端诊断处理)

接下来，使用图7所示的流程图，对控制器11诊断任意的周边车载设备1b的处理(为其他终端诊断处理)进行说明。该流程图也可以以从任意的周边车载设备1b获取到指标数据为触发而开始。当然，开始本终端诊断处理的条件可以适当地设计，例如也可以是指标数据生成部f3生成指标数据的情况。

另外，也可以在从某个周边车载设备1b请求了实施将该周边车载设备1b设为诊断目标的其他终端诊断处理的情况下开始。其他，也可以在与未图示的路侧设备开始路车间通信的情况下开始。

为了方便，以下，将周边车载设备1b中的作为诊断目标的周边车载设备1b表示为诊断目标设备1bb(也称作目标周边车载设备)，将周边车载设备1b中的诊断目标设备1bb以外的周边车载设备1b表示为周边车载设备1ba(参照图8)。作为搭载诊断目标设备1bb的主车辆的周边车辆也能够称作目标周边车辆。图8的车载设备1a如开头叙述的那样，是相当于本终端的车载设备1。执行该其他终端诊断处理的主体是车载设备1a。

首先，在s20中，正常范围决定部f6实施其他终端诊断基准决定处理并移至s21。该s20中的其他终端诊断基准决定处理是基于从周边车载设备1ba接收到的指标数据，来决定每个诊断项目的正常范围的处理。

该其他终端诊断基准决定处理的处理过程除了可能成为用于决定诊断基准的母集的指标数据不同的点以外，与上述的本终端诊断基准决定处理的处理过程相同。更具体而言，在上述的本终端诊断基准决定处理中，使用从周边车载设备1b获取到的指标数据中的满足规定的条件的指标数据来决定诊断基准。

在该其他终端诊断基准决定处理中，使用从周边车载设备1ba(即诊断目标设备1bb以外的车载设备1)获取到的指标数据中的满足规定的条件的指标数据来决定诊断基准。换句话说，采用从周边车载设备1ba接收到的指标数据中的在接收到来自诊断目标设备1bb的指标数据时刻的过去一定时间以内从周边车载设备1ba接收到的指标数据作为母集。另外，在比接收到来自诊断目标设备1bb的指标数据的时刻过去一定时间以内，生成了本终端的指标数据的情况下，也采用该指标数据来作为母集。

由于该其他终端诊断基准处理除了上述不同点以外，与上述的本终端诊断基准决定处理的处理过程相同，所以省略有关详细的处理过程的说明。

此外，在本实施方式中，为作为用于决定其他终端诊断基准的母集未采用从诊断目标设备1bb获取到的指标数据的方式，但并不限于此。作为其他方式，正常范围决定部f6也可以使用从诊断目标设备1bb获取到的指标数据，来决定其他终端诊断基准。

在s21中，其他终端诊断部f8判定从诊断目标设备1bb接收到的指标数据所包含的各项目的值是否收敛于在s20中决定为其他终端诊断基准的每个诊断项目的正常范围。

例如，其他终端诊断部f8判定诊断目标设备1bb的系统时刻是否收敛于由正常范围决定部f6对系统时刻决定出的正常范围。对于平均存储器使用量、平均cpu使用率、储存器空闲容量这样的其他项目也同样地对与该项目对应的正常范围和该项目的本终端的信息进行比较，来判定是否收敛于正常范围。

这里，各种正常范围基于周边车载设备1ba、本终端的指标数据来确定。因此，判定诊断目标设备1bb的某个项目的值(例如平均存储器使用量)是否收敛于对该项目决定出的正常范围，换句话说，相当于判定诊断目标设备1bb的该项目的值是否为与周边车载设备1ba、本终端相同的值。

而且，诊断目标设备1bb的某个项目的值未收敛于对该项目决定出的正常范围意味着关于该项目，诊断目标设备1bb进行与周边车载设备1ba、本终端不同的举动。诊断目标设备1bb进行与周边车载设备1ba、本终端进行不同的举动提示存在诊断目标设备1bb产生不良的可能性。

在该s21中，若对于从诊断目标设备1bb获取到的指标数据所包含的所有项目，完成该项目的值是否收敛于由对应的正常范围定义的范围的判定，则移至s22。

在s22中，其他终端诊断部f8判定s21的判定的结果，即诊断目标设备1bb的控制器是否正常动作。判定诊断目标设备1bb的控制器是否正常动作的条件(换句话说，异常判定条件)与上述的本终端诊断处理相同，可以适当地设计。

在s22的判定处理的结果为满足异常判定条件的情况下，s22为“是”移至s23。另一方面，在s22的判定处理的结果为不满足异常判定条件的情况下，s22为“否”，并结束本流程。

在s23中，其他终端异常通知部f11请求广域通信控制部f9将其他终端异常通知发送至中心3。而且，广域通信控制部f9基于来自其他终端异常通知部f11的请求将其他终端异常通知发送至中心3，并结束本流程。

此外，以上为正常范围决定部f6除了使用从周边车载设备1ba获取到的指标数据来决定其他终端诊断基准以外，还使用本终端的指标数据来决定其他终端诊断基准的方式，但并不限定于此。也可以为不使用本终端的指标数据，而基于周边车载设备1ba的指标数据来决定其他终端诊断基准的方式。

(实施方式的总结)

在以上的结构中，通过对表示作为诊断目标的车载设备1的控制器11的状态的指标值和基于表示除了诊断目标以外的周边车载设备1b的控制器11的状态的指标值确定的诊断基准进行比较，来判定作为诊断目标的车载设备1的控制器11是否正常动作。

更具体而言，在对本终端的控制器11进行诊断的情况下，正常范围决定部f6基于表示周边车载设备1b的控制器11的状态的指标值，来决定每个指标值的正常范围(s10)。而且，本终端诊断部f7判定表示本终端的控制器11的状态的指标值是否收敛于该正常范围。

这里，在未收敛于正常范围的指标值的数量、种类满足规定的异常判定条件的情况下，判定为本终端的控制器11未正常动作(s12)。在本终端诊断部f7判定为本终端的控制器11未正常动作的情况下，本终端异常通知部f10将该意思通知给中心3。

这里，提供用于诊断本终端的每个指标值的正常范围，即作为用于生成本终端诊断基准的基础的指标数据的多个周边车载设备1b均存在于能够与本终端实施车车间通信的范围，换句话说相对较小的范围内。

由于多个周边车载设备1b均存在于相对较小的范围内，所以本终端实施车车间通信的车载设备1的数量和周边车载设备1b分别实施车车间通信的车载设备1的数量相类似的可能性较高。另外，在本终端与服务提供终端实施用于享受服务的通信的情况下，期待周边车载设备1b也与同一服务提供终端实施用于享受服务的通信。

换句话说，本终端和周边车载设备1b共用控制器11(特别是cpu111)所执行的软件(例如用于享受服务的应用程序)、对cpu111施加的负载(应处理的任务的数量等)的可能性较高。在本终端以及周边车载设备1b中执行的软件等相同的情况下，各车载设备1的cpu使用率、存储器使用量的相似性升高。

另外，多个周边车载设备1b均未正常动作的可能性相对较低。因此，基于从周边车载设备1b获取到的指标数据确定的本终端诊断基准表示能够视为当前的状况下的控制器11正常动作的范围。

由于在本终端本来正常动作的情况下，本终端的控制器11的状态与周边车载设备1b的控制器11的状态相类似的可能性较高，所以本终端的指标数据应该与从与周边车载设备1b获取到的指标数据相类似。换句话说，本终端的控制器11的指标数据所包含的各项目的值应该收敛于与该项目对应的正常范围。换句话说，在本终端的控制器11的指标数据所包含的各项目的值未收敛于与该项目对应的正常范围的情况下，提示存在本终端的控制器11未正常动作的可能性。

换句话说，通过对基于从周边车载设备1b获取到的指标数据确定的本终端诊断基准和本终端的指标数据进行比较，能够更高精度地判定本终端的控制器11是否正常动作。

另外，在将多个周边车载设备1b中的任意的周边车载设备1b设为诊断目标的情况下，正常范围决定部f6基于表示除了该诊断目标设备1bb以外的周边车载设备1ba的控制器11的状态的指标值来决定每个指标值的正常范围(s20)。而且，其他终端诊断部f8判定表示诊断目标设备1bb的控制器11的状态的指标值是否收敛于其正常范围。

在未收敛于正常范围的指标值的数量、种类满足规定的异常判定条件的情况下，判定为诊断目标设备1bb的控制器11未正常动作(s22)。在其他终端诊断部f8判定为诊断目标设备1bb的控制器11未正常动作的情况下，其他终端异常通知部f11将该意思通知给中心3。

这里，由于诊断目标设备1bb和周边车载设备1ba均是存在于能够与本终端进行车车间通信的范围内的车载设备1，所以均存在于相对较小的范围内。因此，根据与对本终端进行诊断时相同的工作，由正常范围决定部f6决定的其他终端诊断基准表示能够视为当前的状况下的正常的控制器11正常动作的范围。

而且，其他终端诊断部f8通过对该其他终端诊断基准和从诊断目标设备1bb获取到的指标数据进行比较，能够更高精度地判定诊断目标设备1bb的控制器11是否正常动作。

以上，对本公开的实施方式进行了说明，但本公开并不限定于上述的实施方式，以下的实施方式也包含于本公开的技术的范围，进一步，能够在下述以外的不脱离主旨的范围内进行各种变更并实施。

＜变形例1＞

在上述的实施方式中，示出了车载设备1具备其他终端诊断部f8和其他终端异常通知部f11的结构，但未必限定于此。例如，车载设备1也可以不具备其他终端诊断部f8，也可以不具备其他终端异常通知部f11。

＜变形例2＞

在上述的实施方式中，示出了车载设备1具备本终端诊断部f7和本终端异常通知部f10的结构，但未必限定于此。例如，车载设备1也可以不具备本终端诊断部f7，也可以不具备本终端异常通知部f10。

另外，在为不具备本终端异常通知部f10以及其他终端异常通知部f11的结构的情况下，还可以不具备广域通信器13以及广域通信控制部f9。

＜变形例3＞

以上，为使车载设备诊断系统100所具备的车载设备1均具备相同的功能的结构，但并不限定于此。在被诊断侧的车载设备1和进行诊断侧的车载设备1中，应具备的功能不同。而且，在车载设备诊断系统100所具备的车载设备1中也可以存在仅具备用于被诊断的功能的车载设备1。

被诊断侧的车载设备1至少具备系统信息获取部f2、指标数据生成部f3以及具有发送本终端的指标数据的功能的狭域通信控制部f4即可。

另外，进行诊断侧的车载设备1至少具备具有获取从被诊断侧的车载设备1发送出的指标数据的功能的狭域通信控制部f4、指标数据管理部f5、正常范围决定部f6以及其他终端诊断部f8即可。

但是，根据上述结构，尽管进行诊断侧的车载设备1能够对被诊断侧的车载设备1进行诊断，但无法对自己本身进行诊断，或获得诊断。因此，优选进行诊断侧的车载设备1除了上述所需最低限度的结构以外，还具备系统信息获取部f2和指标数据生成部f3，进一步狭域通信控制部f4具备发送本终端的指标数据的功能。

此外，即使不具备本终端诊断部f7，也能够通过对其他进行诊断侧的车载设备1发送自身的指标数据来获得诊断。因此，也可以不具备本终端诊断部f7。换句话说，本终端诊断部f7是任意的要素。

＜变形例4＞

以上，提到了基于本终端的系统时刻是否与周边车载设备1b的系统时刻偏离，来判定本终端的控制器11是否正常动作的方式。

然而，例如在本终端存在于隧道、立体停车场等来自gnss卫星的电波到达不了的环境的情况下，无法获取来自gnss卫星的信号，而系统时刻偏离。

因此，在基于系统时刻的偏离，来判定控制器11是否正常动作时，优选考虑通过gnss接收器14进行的来自gnss卫星的信号的接收状况、本终端所存在的环境。

例如，也可以为在gnss接收器14无法接收来自gnss卫星的信号的情况下，不实施基于系统时刻的判定的结构。也可以为不管gnss接收器14是否能够接收来自gnss卫星的信号，gnss接收器14都将表示来自gnss卫星的信号的接收状况(捕捉卫星数量等)的信息依次输出至控制器11的结构。

此外，以上，提到了本终端诊断部f7基于系统时刻的偏离，来诊断本终端的控制器11是否正常动作的方式，对于其他终端诊断部f8也相同。换句话说，也可以为在从诊断目标设备1bb获取到的指标数据的诊断历史信息中示有gnss接收器14无法获取来自gnss卫星的信号的意思的情况下，不进行基于系统时刻的判定的方式。

＜变形例5＞

在通过本终端诊断部f7判定为本终端未正常动作的情况下，本终端异常通知部f10也可以生成包含在该时刻gnss接收器14所输出的位置信息的本终端异常通知，并使广域通信控制部f9发送至中心3。

根据这样的方式，中心3能够把握未正常动作的车载设备1所存在的地点、车载设备1的控制器11未正常动作的地点。由此，能够容易地实施车载设备1未正常动作的地点的解析等。

另外，也可以为在本终端异常通知所示的位置例如是立体停车场等来自gnss卫星的信号难以到达的位置，并且，判定为该本终端的控制器11未正常动作的理由是系统时刻的偏离的情况下，中心3不进行伴随该本终端异常通知的维护的安排等处理的方式。因为假定在来自gnss卫星的信号难以到达的位置，即使控制器11正常，系统时刻也偏离。

＜变形例6＞

也可以为在通过其他终端诊断部f8判定为诊断目标设备1bb未正常动作的情况下，其他终端异常通知部f11生成包含在该时刻gnss接收器14所输出的位置信息的其他终端异常通知的方式。在该情况下，广域通信控制部f9将包含位置信息的其他终端异常通知发送至中心3。

根据这样的方式，与变形例5相同，中心3能够把握未正常动作的车载设备1所存在的地点、车载设备1的控制器11未正常动作的地点。由此，能够容易地实施车载设备1未正常动作的地点的解析等。

另外，在其他终端异常通知所示的位置是来自gnss卫星的信号难以到达的位置，并且，判定为控制器11未正常动作的理由是系统时刻的偏离的情况下，也可以不进行伴随该其他终端异常通知的维护的安排等处理。

＜变形例7＞

然而，对于车载设备1中所使用的软件而言，随时都有新的版本被公开，伴随于此，假定在各车载设备1中所使用的软件也随时被版本升级。然而，未必所有的车载设备1同时更新软件。其结果，假定使用旧版本的软件的车载设备1和利用新版本的软件的车载设备1混合存在。

当然，假定在旧版本的软件和新版本的软件中，储存器113中的数据尺寸、cpu使用率、存储器使用量等不同。

因此，在使用旧版本的软件的车载设备1的控制器11和利用新版本的软件的车载设备1的控制器11中，其状态不同的可能性较高。假设基于从利用新版本的软件的车载设备1获取到的指标数据来生成用于对利用旧版本的软件的车载设备1的控制器11进行诊断的诊断基准，则存在进行误判定的可能性。

换句话说，优选正常范围决定部f6基于从利用与作为诊断目标的车载设备1所利用的软件相同的版本的软件的车载设备1获取到的指标数据，来决定诊断基准。

该变形例例如也可以为如下结构。首先，各车载设备1的狭域通信控制部f4将对该指标数据赋予了包含终端id和当前所利用的软件的版本信息的报头的发送用数据发送至周边车载设备1b。另外，狭域通信控制部f4在获取到由周边车载设备1b发送出的包含指标数据的数据的情况下，对该指标数据、终端id以及软件的版本信息建立对应关系并提供给指标数据管理部f5。指标数据管理部f5将每个车载设备1的指标数据与该车载设备1所利用的软件的版本信息建立对应关系并保存至存储器112。

而且，正常范围决定部f6基于从利用与作为诊断目标的车载设备1所利用的软件相同的版本的软件的车载设备1获取到的指标数据，来决定诊断基准。

具体而言，正常范围决定部f6在决定本终端诊断基准时，基于从利用与本终端所利用的软件相同的版本的软件的周边车载设备1b获取到的指标数据来决定本终端诊断基准。当然，此时，与上述的实施方式相同，作为用于选定用来决定本终端诊断基准的指标数据的条件，也可以使用时间性的条件。

另外，正常范围决定部f6在决定其他终端诊断基准时，基于从利用与诊断目标设备1bb所利用的软件相同的版本的软件的周边车载设备1ba获取到的指标数据来决定其他终端诊断基准。当然，此时，也可以与上述的实施方式相同，作为用于选定用来决定其他终端诊断基准的指标数据的条件，使用时间性的条件。另外，也可以在本终端所利用的软件的版本与诊断目标设备1bb所利用的软件的版本相同的情况下，使用本终端的指标数据来决定其他终端诊断基准。

此外，这里为将当前所利用的软件的版本信息以与终端id等相同的方式赋予在指标数据的外部(例如发送用数据的报头部分)来发送的方式，但并不限定于此。例如，软件的版本信息也可以包含于指标数据。发送源的车载设备1当前所利用的软件的版本信息能够被接收侧的车载设备1确定即可。

＜变形例8＞

以上，为本终端异常通知部f10、其他终端异常通知部f11将本终端或者作为诊断目标的周边车载设备1b未正常动作的意思通过广域通信通知给中心3的结构，但未必限定于此。例如，也可以为本终端异常通知部f10将本终端的控制器11未正常动作的意思通过显示、声音报告给用户的结构。

另外，其他终端异常通知部f11也可以通过车车间通信对作为诊断目标的周边车载设备1b通知该控制器11未正常动作的情况。伴随于此，车载设备1也可以具备在从周边的车载设备1获取到通知本终端的控制器11未正常动作的情况的信号的情况下，通过显示、声音来报告该意思的结构。

本公开以实施例为基准进行了描述，但能够理解为本公开并不限定于该实施例、构造。本公开也包含各种变形例、等同范围内的变形。其中，各种组合、方式、进一步仅包含它们中一个要素、一个以上或一个以下的其他组合、方式也纳入到本公开的范畴、思想范围。