检查装置、检查系统以及检查方法与流程

本发明涉及用于检查汽车中搭载的控制装置的动作的检查装置、检查系统以及检查方法，特别适合用于检查与车载网络相连接的控制装置的动作的检查装置、检查系统以及检查方法。

背景技术：

近年来，开发了将汽车中搭载的多个控制装置(Electronic Control Unit:ECU电子控制单元)与车载网络(Controller Area Network:CAN控制器局域网络)相连接，经由该车载网络，使多个控制装置协作地进行动作的技术。

在多个ECU中例如具有进行发动机的控制的发动机ECU、进行换挡控制的变速器ECU以及进行制动器液压的调整的制动器ECU等。而且，在专利文献1公开了在这些多个ECU协作地进行动作的情况下判断协作动作的不良情况，从而确定故障位置的技术。

具体而言，在专利文献1公开了一种故障诊断系统，其具备：基于经由车载网络在ECU之间进行收发的数据判断协作动作的不良情况的产生的不良情况判断单元；当判断为发生了不良情况时，与不良情况对应地取得预先准备的检查诊断程序的程序取得单元；以及执行检查诊断程序从而使ECU执行对应处理，基于通过执行对应处理而从ECU发送的信息来确定故障位置的故障位置确定单元。

现有技术文献

专利文献

专利文献1：日本专利第4622177号公报

技术实现要素：

发明要解决的课题

但是，在专利文献1所记载的故障诊断系统中，使用预先准备的检查诊断程序来确定故障位置，检查诊断程序是基于ECU的设计信息在运用前预先生成的程序，因此当在运用时向ECU发送了在设计阶段未假定的数据的情况下，无法判断ECU是否正常地进行动作。

即，关于故障(功能不全)能够确定该故障，但是无法正确地判断虽然进行动作但该动作是正常还是异常。

本发明是考虑以上的问题点而做出的，提供一种正确地检查运用时的ECU的动作的检查装置、检查系统以及检查方法。

用于解决课题的手段

为了解决上述的课题，本发明的检查装置的特征在于，具备检查执行控制部，该检查执行控制部将为了检查ECU的动作而使用的动作检查用数据以及安全检查用数据这两个数据发送至ECU，并接收从ECU输出的数据，动作检查用数据是基于ECU的设计信息预先生成的数据，安全检查用数据是将动作检查用数据的一部分或者全部置换成随机数据后的数据。

另外，为了解决上述的课题，在本发明的检查系统的特征在于，具备服务提供服务器和网关，服务提供服务器具备：检查计划部，其计划检查ECU的动作的时间表；检查数据生成部，其生成为了检查ECU的动作而使用的动作检查用数据以及安全检查用数据这两个数据；以及检查控制部，其按照计划的时间表将生成的两个数据向外部发送，网关在接收到从服务提供服务器发送的动作检查用数据以及安全检查用数据这两个数据的情况下，将接收到的两个数据发送至ECU，在接收到从ECU输出的数据的情况下，将包含接收到的数据的检查执行结果信息发送至服务提供服务器，动作检查用数据是基于ECU的设计信息而预先生成的数据，安全检查用数据是将动作检查用数据的一部分或者全部置换成随机数据后的数据。

另外，为了解决上述课题，本发明的检查方法的特征在于，具备：检查计划部计划检查ECU的动作的时间表的第一步骤；检查数据生成部生成为了检查ECU的动作而使用的动作检查用数据以及安全检查用数据这两个数据的第二步骤；检查控制部按照计划的时间表，将生成的两个数据向外部发送的第三步骤；以及网关在接收到从服务提供服务器发送的动作检查用数据以及安全检查用数据这两个数据的情况下，将接收到的两个数据发送至ECU，在接收到从ECU输出的数据时，将包含接收到的数据的检查执行结果信息发送至服务提供服务器的第四步骤，动作检查用数据是基于ECU的设计信息而预先生成的数据，安全检查用数据是将动作检查用数据的一部分或者全部置换成随机数据后的数据。

发明效果。

根据本发明，能够正确地检查运用时的ECU的动作。

附图说明

图1是本实施方式的检查系统的整体结构图。

图2是用户信息的逻辑结构图。

图3是检查对象车辆信息的逻辑结构图。

图4是检查对象ECU信息的逻辑结构图。

图5是安全检查用数据信息的逻辑结构图。

图6是动作检查用数据信息的逻辑结构图。

图7是时间表信息的逻辑结构图。

图8是域构造信息的逻辑结构图。

图9是域划分信息的逻辑结构图。

图10是域依赖关系信息的逻辑结构图。

图11是检查结果信息的逻辑结构图。

图12是检查对照结果信息的逻辑结构图。

图13是检查执行数据信息的逻辑结构图。

图14是检查执行结果信息的逻辑结构图。

图15是数据帧构造的结构图。

图16是时间表认可画面的画面结构图。

图17是时间表登录处理的流程图。

图18是附带通信功能的终端侧的时间表登录处理的流程图。

图19是服务提供服务器侧的时间表登录处理的流程图。

图20是ECU检查处理的流程图。

图21是附带通信功能的终端侧的ECU检查处理的流程图。

图22是服务提供服务器侧的ECU检查处理的流程图。

图23是汽车的网关侧的ECU检查处理的流程图。

图24是安全检查用数据生成处理的流程图。

图25是网关解析检查结果时的ECU检查处理的流程图。

具体实施方式

以下，针对附图详述本发明的一实施方式。

(1)整体结构

图1表示本实施方式的检查系统5的整体结构。检查系统5构成为具备汽车1、服务提供服务器2以及附带通信功能的终端3。另外，将这些汽车1、服务提供服务器2以及附带通信功能的终端3经由通信网4可相互通信地进行连接。通信网4例如是移动电话网或无线LAN(Local Area Network局域网络)。

汽车1构成为具备网关11以及多个ECU(Electronic Control Unit电子控制器单元)12。网关11与各ECU12之间通过被称为CAN(Controller Area Network控制器局域网络)的车载网络连接。

在此，网关11是作为检查装置发挥功能的终端，构成为具备检查执行控制部111、检查信息取得部112、检查执行部113、检查监视部114、通信部115以及检查信息管理部116。

检查执行控制部111将经由通信部115接收到的检查执行数据信息1161储存在检查信息管理部116中，另外，取得储存在检查信息管理部116中的检查执行数据信息1161，并发送至ECU12。在检查执行数据信息1161中具有动作检查用数据以及安全检查用数据。

动作检查用数据是基于设计信息，在设计阶段预先生成的ECU12的测试用的数据。将在后面详细进行叙述(图6)。另外，安全检查用数据是在实际的运用时用于检查以及诊断ECU12的动作是正常还是异常的测试用数据。将在后面详细进行叙述(图5)。此外，有时将它们集中称为检查用数据。

检查信息取得部112取得储存在检查信息管理部116中的检查执行结果信息1162，经由通信部115，将该检查执行结果信息1162发送至服务提供服务器2。检查执行部113基于来自检查执行控制部111的检查执行要求，将动作检查用数据以及安全检查用数据发送至ECU12。

检查监视部114基于动作检查用数据以及安全检查用数据来监视以及取得从ECU12输出的数据，将取得的数据作为检查执行结果信息1162储存在检查信息管理部116中。

ECU12是对汽车1具备的各种设备进行控制的控制装置。在ECU12中例如具有：进行发动机的控制的发动机ECU、进行换挡的控制的变速器ECU以及进行制动器液压的调整的制动器ECU等。

服务提供服务器2构成为具备检查计划部21、检查控制部22、检查数据生成部23、依赖关系解析部231、域构造解析部232、检查数据分配部233、检查数据投入部24、检查结果回收部25、检查结果解析部26以及检查服务信息管理部27。

检查计划部21计划针对ECU12执行的检查的时间表，将计划的时间表发送至汽车1的用户所具有的附带通信功能的终端3，接收在附带通信功能的终端3中被认可的时间表，将该时间表储存在检查服务信息管理部27。

检查控制部22对检查数据生成部23、检查数据投入部24、检查结果回收部25以及检查结果解析部26的动作进行综合控制。

检查数据生成部23使用依赖关系解析部231、域构造解析部232以及检查数据分配部233生成安全检查用数据，并将生成的安全检查用数据储存在检查服务信息管理部27。

检查数据投入部24将用于通知执行检查的通知发送至汽车1的用户所具有的附带通信功能的终端3，并从检查服务信息管理部27取得安全检查用数据以及动作检查用数据，发送至检查对象的汽车1。

检查结果回收部25当从网关11接收到检查完成通知时，将检查执行结果信息1162的回收请求发送至网关11，并将从网关11回收的检查执行结果信息1162储存在检查服务信息管理部27中。

检查结果解析部26从检查服务信息管理部27取得检查结果信息280以及检查对照结果信息281，将两者进行比较来解析从ECU12输出的信号是否是异常。

检查服务信息管理部27具备服务提供服务器2的动作所需的各种信息(271～281)。将在后面对各种信息进行详细叙述(图2～图14)。

附带通信功能的终端3构成为具备画面显示部31、服务执行确认部32以及通信部33。画面显示部31在显示画面中显示通过服务提供服务器2计划的检查的时间表，另外，在显示画面中显示由服务提供服务器2解析的检查结果。服务执行确认部32针对在显示画面中显示的检查的时间表，执行编辑以及认可的处理。

(2)表的结构

以下，参照图2～图12对服务提供服务器2的检查服务信息管理部27中存储的各种信息进行说明。

图2表示用户信息271的逻辑结构。用户信息271由用户ID栏2711、用户密码栏2712以及用户名栏2713构成。在用户ID栏2711中储存使用检查系统5的用户的识别信息，在用户密码栏2712中储存用户的密码。另外，在用户名栏2713中储存用户名。

图3表示检查对象车辆信息272的逻辑结构。检查对象车辆信息272由用户ID栏2721、VIN(Vehicle Identification Number车辆识别号码)栏2722、制造商栏2723、车辆类型栏2724、车辆颜色栏2725以及车辆号码栏2726构成。

在用户ID栏2721中储存用户的识别信息，在VIN栏2722中储存用于识别检查对象的汽车1的识别信息。另外，在制造商栏2723中储存汽车1的制造商名，在车辆类型栏2724中储存汽车1的车辆类型，在车辆颜色栏2725中储存汽车1的颜色。另外，在车辆号码栏2726中存储汽车1的车辆号码。

图4表示检查对象ECU信息273的逻辑结构。检查对象ECU信息273由车辆类型栏2731、ECU－ID栏2732、ECU名栏2733、检查对象标志栏2734、检查期限栏2735以及CAN－ID栏2736构成。

在车辆类型栏2731中存储检查对象的汽车1的车辆类型，在ECU－ID栏2732中存储用于识别检查对象的ECU12的识别信息。另外，在ECU名栏2733中存储ECU名，在检查对象标志栏2734中存储是否为检查对象的信息，例如储存“对象”或者“非对象”。

另外，在检查期限栏2735中存储检查的期限，在CAN－ID栏2736中存储连接了检查对象的ECU12的CAN的识别信息。

图5表示安全检查用数据信息274的逻辑结构。安全检查用数据信息274由检查ID栏2741、ECU－ID栏2742、CAN－ID栏2743以及检查数据栏2744构成。

在检查ID栏2741中存储识别信息，该识别信息用于识别使用了针对检查对象的每个ECU12分配的安全检查用数据的检查，在ECU－ID栏2742中存储识别信息，该识别信息用于识别成为使用了安全检查用数据的检查的对象的ECU12。

另外，在CAN－ID栏2743中存储连接了检查对象的ECU12的CAN的识别信息，在检查数据栏2744中存储检查用数据，例如储存相当于CAN协议的数据域的数据。

图6表示动作检查用数据信息275的逻辑结构。动作检查用数据信息275与安全检查用数据信息274相同地，由检查ID栏2751、ECU－ID栏2752、CAN－ID栏2753以及检查数据栏2754构成。

在检查ID栏2751中存储识别信息，该识别信息用于识别使用了针对检查对象的每个ECU12分配的动作检查用数据的检查，在ECU－ID栏2752中存储识别信息，该识别信息用于识别成为使用了动作检查用数据的检查的对象的ECU12。

另外，在CAN－ID栏2753中存储连接了检查对象的ECU12的CAN的识别信息，在检查数据栏2754中存储检查用数据，例如储存相当于CAN协议的数据域的数据。

图7表示时间表信息276的逻辑结构。时间表信息276由VIN栏2761、日期时间栏2762以及检查ID栏2763构成。在VIN栏2761中存储用于识别检查对象的汽车1的识别信息。

在日期时间栏2762中存储检查对象的汽车1的用户认可的检查日期时间，在检查ID栏2763中存储用于识别对汽车1执行的检查的识别信息。

图8表示域构造信息277的逻辑结构。域构造信息277由车辆类型栏2771、CAN－ID栏2772、详细域ID栏2773、划分ID栏2774以及比特数栏2775构成。

在车辆类型栏2771中存储检查对象的汽车1的车辆类型，在CAN－ID栏2772中存储连接了检查对象的ECU12的CAN的识别信息。

另外，在详细域ID栏2773中，基于ECU12的应用的设计信息，存储识别信息，该识别信息用于识别具有将CAN协议的数据域更加详细地进行分类后的含义的划分，在划分ID栏2774中基于ECU12的应用的设计信息存储用于识别数据具有的含义的识别信息。

例如，在划分ID栏2774中存储用于识别“有效位、可变数据、预约数据、伪数据、检验和等”划分的固有值。在比特数栏2775中存储向详细域ID分配的比特数。

图9表示域划分信息278的逻辑结构。域划分信息278由划分ID栏2781以及划分名称栏2782构成。在划分ID栏2781中存储用于识别在CAN协议的数据域中使用的数据的种类的识别信息。

另外，在划分名称栏2782中存储在与划分ID对应的CAN协议的数据域中使用的数据的种类的名称。例如，可以将数据的种类的名称划分为“有效位、可变数据、预约数据、伪数据、检验和等”那样。

图10表示域依赖关系信息279的逻辑结构。域依赖关系信息279由车辆类型栏2791、CAN－ID栏2792以及详细域的依赖关系栏2793构成。在车辆类型栏2791中存储检查对象的汽车1的识别信息，在CAN－ID栏2792中存储连接了检查对象的ECU12连接的CAN的识别信息。

在详细域的依赖关系栏2793中，基于ECU12的应用的设计信息中的分支处理的条件、作为函数调用的自变量的使用方法等，存储用于表示ECU12的应用中的详细域ID(图8)的处理依赖关系的信息，例如在详细域ID(图8)的A1与A2存在依赖关系的情况下，使用“&”储存“A1&A2”。

图11表示检查结果信息280的逻辑结构。检查结果信息280由VIN栏2801、检查结果栏2802以及实施检查ID栏2803构成。在VIN栏2801中存储用于识别检查对象的汽车1的识别信息，在检查结果栏2802中作为日志文件储存执行的检查的结果。另外，在实施检查ID栏2803中存储用于识别对汽车1执行的检查的识别信息。

图12表示检查对照结果信息281的逻辑结构。检查对照结果信息281由车辆类型栏2811、CAN－ID栏2812、实施检查数据栏2813、预想输出数据栏2814以及判定结果栏2815构成。

在车辆类型栏2811中存储检查对象的汽车1的车辆类型，在CAN－ID栏2812中存储连接了检查对象的ECU12的CAN的识别信息。

另外，在实施检查数据栏2813中存储已发送给ECU12的检查用数据，在预想输出数据栏2814中存储将实施的检查用数据发送给ECU12后的结果，即存储预想ECU12进行输出的数据。

另外，在判定结果栏2815中存储将预想输出数据与检查结果(图11)的日志文件中存储的输出数据进行比较来进行判定的结果，例如在输出数据在预想输出数据的范围内的情况下，储存“无异常”，在为范围外的情况下，储存“有异常”。

接下来，参照图13以及图14对汽车1的检查信息管理部116中存储的各种信息进行说明。

图13表示检查执行数据信息1161的逻辑结构。检查执行数据信息1161由执行顺序栏11611、检查ID栏11612、CAN－ID栏11613、检查数据栏11614以及进展状况栏11615构成。

在执行顺序栏11611中存储将检查数据栏11614中存储的检查用数据发送给ECU12的顺序，在检查ID栏11612中存储用于识别针对每个ECU12附带的动作检查用数据或安全检查用数据的识别信息。

另外，在CAN－ID栏11613中存储连接了检查对象的ECU12的CAN的识别信息，在检查数据栏11614中存储发送给ECU12的检查用数据(动作检查用数据或安全检查用数据)。

另外，在进展状况栏11615中存储使用在检查数据栏11614中存储的检查用数据进行的检查是否已完成的信息，例如将检查用数据发送给ECU12，在取得了从ECU12输出的数据的定时，储存“完成”。

图14表示检查执行结果信息1162的逻辑结构。检查执行结果信息1162由检查ID栏11621以及检查结果栏11622构成。在检查ID栏11621中存储用于识别针对每个ECU附带的动作检查用数据或安全检查用数据的识别信息。

另外，在检查结果栏11622中存储检查执行部113将检查数据栏11614中存储的检查用数据发送给ECU12，从ECU12输出的数据，例如储存记录了“日期、发送至ECU12的检查用数据、从ECU12输出的数据”等的日志文件。

(3)数据结构

图15表示数据帧结构。该数据帧结构由国际标准化组织的ISO15031规定。

SOF(Start Of Frame帧起始)域是表示数据帧的开始的域，仲裁域由表示发送目的地的ID(Identifier识别符)以及RTR(Remote Transmission Request远程发送请求)构成，是表示帧的优先顺序的域。控制域是表示预留比特以及数据的字节数的域。

此外，构成仲裁域的ID在本实施方式中是CAN－ID，通过CAN－ID决定了后述的数据域的构造(划分)。

数据域是储存数据主体的域。在本实施方式中，在该数据域的一部分或全部中储存随机数据，从而生成安全检查用数据。此外，安全检查用数据由服务提供服务器2的检查数据生成部23生成。

将在后面详细叙述安全检查用数据的生成处理(图24)，在此进行简单的说明，通过检查数据生成部23，首先解析数据域的构造(划分)，例如获得划分成四个的解析结果。接下来，解析各划分的依赖关系，最后基于依赖关系，在检查效率良好的某个划分中储存随机数据从而生成安全检查用数据。

另外，CRC域是检查数据帧的错误的域。另外，ACK域是表示正常地接收到的确认的信号的域，EOF(End Of Frame帧结束)域是表示数据帧的结束的域。

(4)画面结构

图16表示由附带通信功能的终端3的画面显示部31显示的画面结构。该画面是在将检查的时间表从服务提供服务器2发送至附带通信功能的终端3时，在附带通信功能的终端3中进行编辑或者认可时的画面。

在用户名区域311中显示作为检查对象的汽车1的用户而登录的用户名。该用户名从用户名栏2713中存储的用户名来取得。在制造商区域312中显示检查对象的汽车1的制造商名。该制造商名从制造商栏2723中存储的制造商名来取得。

另外，在车辆类型区域313中显示检查对象的汽车1的车辆类型。该车辆类型从车辆类型栏2724中存储的车辆类型来取得。在车辆颜色区域314中显示检查对象的汽车1的车辆颜色。该车辆颜色从车辆颜色栏2725中存储的车辆颜色来取得。在车辆号码区域315中显示检查对象的汽车1的车辆号码。该车辆号码从车辆号码栏2726中存储的车辆号码来取得。

另外，在检查日期时间区域316中以能够编辑的方式显示检查计划部21作成的时间表。在实施期限区域317中显示检查的期限。该检查的期限从检查期限栏2735中存储的检查的期限来取得。另外，登录认可按钮318是用于在认可通过检查日期时间区域316中显示的检查日期时间来执行检查时按下的按钮。

(5)流程图

图17表示时间表登录处理的处理顺序。该时间表登录处理由服务提供服务器2以及附带通信功能的终端3来执行。

首先，服务提供服务器2的检查计划部21发送检查的认可委托的通知(SP1)。该检查的认可委托的通知是请求发送ID以及密码的通知。附带通信功能的终端3的服务执行确认部32当接收到该检查的认可委托的通知时，将用户输入的ID以及密码发送至服务提供服务器2(SP2)。

接下来，检查计划部21当接收到ID以及密码时，参照用户信息271，执行ID以及密码的认证处理(SP3)。然后，检查计划部21当通过认证处理认证了ID以及密码时，参照检查对象车辆信息272以及检查对象ECU信息273，生成一个或多个检查的时间表，将生成的时间表的认可委托的通知发送至附带通信功能的终端3(SP4)。

该时间表的认可委托的通知是用于指示将时间表与用户信息271、检查对象车辆信息272以及检查对象ECU信息273中包含的各种信息一同进行显示的通知。画面显示部31当接收到时间表的认可委托的通知时，将时间表与该通知中包含的各种信息一同显示在显示画面中(SP5)。此处显示的显示画面是在图16中说明的显示画面。

服务执行确认部32在根据需要编辑了时间表后(SP6)，通过按下登录认可按钮318来认可时间表(SP7)。然后，服务执行确认部32将认可的时间表发送至服务提供服务器2(SP8)。检查计划部21当接收到来自附带通信功能的终端3的时间表时，将该时间表储存在时间表信息276(SP9)。

然后，检查计划部21发送用于通知储存了时间表登录完成的登录完成通知(SP10)。画面显示部31当接收到登录完成通知时，显示表示登录已完成的登录完成画面(SP11)，并结束该时间表登录处理。

图18表示附带通信功能的终端3侧的时间表登录处理的详细的处理顺序。此处，对在图17的时间表登录处理中由附带通信功能的终端3执行的处理的详细处理顺序进行说明。

附带通信功能的终端3的服务执行确认部32在等待检查认可委托的状态下(SP101)，判断是否接收到从服务提供服务器2发送的检查的认可委托的通知(SP102)。服务执行确认部32当在步骤SP102的判断中获得否定结果时，转移至步骤SP101成为待机状态。

与此相对，服务执行确认部32当在步骤SP102的判断中获得肯定结果时，将ID以及密码发送至服务提供服务器2，然后，当接收到来自服务提供服务器2的时间表的认可委托的通知时，将时间表与各种信息一同显示在显示画面中(SP103)。

服务执行确认部32判断是否通过用户的编辑操作指示了时间表的编辑(SP104)。服务执行确认部32当在步骤SP104的判断中获得否定结果时，转移至步骤SP106，当获得肯定结果时，编辑时间表(SP105)。

接下来，服务执行确认部32在实施期限区域317中显示的实施期限的范围内编辑时间表，通过按下登录认可按钮318来认可时间表。然后，服务执行确认部32将认可的时间表发送至服务提供服务器2(SP106)。

服务执行确认部32在等待时间表的登录完成的状态下(SP107)，判断是否接收到登录完成通知(SP108)。服务执行确认部32当在步骤SP108的判断中获得否定结果时，转移至步骤SP107。与此相对，服务执行确认部32当在步骤SP108的判断中获得肯定结果时，将登录完成画面显示在显示画面中(SP109)，并结束该时间表登录处理。

图19表示服务提供服务器2侧的时间表登录处理的详细的处理顺序。此处，对在图17的时间表登录处理中由服务提供服务器2执行的处理的详细的处理顺序进行说明。

服务提供服务器2的检查计划部21当结束从附带通信功能的终端3发送的ID以及密码的认证处理时，参照检查对象ECU信息273在“检查期限”内生成一个或多个时间表(SP111)。

接下来，检查计划部21取得用户信息271以及检查对象车辆信息272(SP112)，将用户信息271等与生成的时间表一同发送至附带通信功能的终端3(SP113)。接下来，检查计划部21在等待接收在附带通信功能的终端3中认可的时间表的状态下(SP114)，判断是否接收到认可的时间表(SP115)。

检查计划部21当在步骤SP115的判断中获得否定结果时，转移至步骤SP114。与此相对，检查计划部21当在步骤SP115的判断中获得肯定结果时，将接收到的时间表储存在时间表信息276中(SP116)。然后，检查计划部21将登录完成通知发送至附带通信功能的终端3(SP117)，并结束该时间表登录处理。

图20表示ECU检查处理的一连串的处理顺序。该ECU检查处理由汽车1的网关11、服务提供服务器2以及附带通信功能的终端3执行。

首先，服务提供服务器2的检查控制部22定期或者不定期地参照时间表信息276来取得检查预定的“日期时间”，由此来核对时间表(SP21)。接下来，检查控制部22判断是否存在成为对象的检查(SP22)，当获得否定结果时，返回步骤SP21，当获得肯定结果时，转移至步骤SP23。

接下来，检查控制部22通过检查数据投入部24将检查实施通知发送至附带通信功能的终端3(SP23)。画面显示部31当接收到检查实施通知时，显示提醒画面(SP24)。另一方面，检查数据投入部24从安全检查用数据信息274以及动作检查用数据信息275取得检查用数据，并将取得的检查用数据发送至检查对象的汽车1的网关11(SP25)。

网关11的检查执行控制部111当接收到检查数据时，将接收到的检查用数据储存在检查执行数据信息1161中(SP26)。接下来，检查执行控制部111确认汽车1的车辆状态(SP27)，在汽车1不是待机状态的情况下(SP28：否)，判断为不是能够检查的状态，转移至步骤SP27。

此外，待机状态是指汽车1为停止状态，并且是经过了一定时间后的状态。检查执行控制部111在汽车1为待机状态的情况下(SP28：是)，取得在检查执行数据信息1161中存储的检查用数据，并将检查执行部113取得的检查用数据发送至ECU12(SP29)。

接下来，检查执行控制部111通过检查监视部114取得从ECU114输出的数据，具体而言，捕获分组(SP30)，将捕捉到的分组储存在检查执行结果信息1162中。

接下来，检查执行控制部111确认在检查执行数据信息1161中是否未剩余应该发送至ECU12的检查用数据(SP31)，在剩余的情况下，转移至步骤SP28，在未剩余的情况下，转移至步骤SP32。此外，在即使经过一定期间检查也未完成的情况下，可以向服务提供服务器2通知警告。

检查执行控制部111在未剩余应该发送至ECU12的检查用数据的情况下，将表示检查完成的检查结果完成通知发送至服务提供服务器2(SP32)。服务提供服务器2的检查控制部22当接收到检查结果完成通知时，通过检查结果回收部25将检查结果回收委托的通知发送至网关11(SP33)。

网关11的检查信息取得部112当接收到检查结果回收委托的通知时，取得检查执行结果信息1162(SP34)，将取得的检查执行结果信息1162发送至服务提供服务器2(SP35)。服务提供服务器2的检查结果回收部25当接收到检查执行结果信息1162时，将其储存在检查结果信息280中(SP36)。

接下来，检查结果解析部26参照检查结果信息280以及检查对照结果信息281，将从ECU12实际输出的输出结果与预测的输出结果进行比较，从而解析检查结果信息(SP37)，判定解析结果(SP38)，将判定结果储存在检查对照结果信息281中。

然后，检查控制部22将判定结果发送至附带通信功能的终端3(SP39)。此外，除了发送给附带通信功能的终端3以外，还可以将判定结果发送至经销商或汽车制造商等。附带通信功能的终端3的画面显示部31当接收到判定结果时，将其作为检查结果显示在显示画面中(SP40)。通过以上，ECU检查处理的一连串的处理结束。

图21表示附带通信功能的终端3侧的ECU检查处理的详细的处理顺序。此处，对在图20的ECU检查处理中附带通信功能的终端3执行的处理的详细的处理顺序进行说明。

附带通信功能的终端3的服务执行确认部32在等待检查实施通知的状态下(SP201)，判断是否接收到从服务提供服务器2发送的检查实施通知(SP202)。服务执行确认部32当在步骤SP202的判断中获得否定结果时，转移至步骤SP201。

与此相对，服务执行确认部32当在步骤SP202的判断中获得肯定结果时，将提醒画面显示在显示画面中(SP203)。接下来，服务执行确认部32判断是否接收到从服务提供服务器2发送的判定结果(SP204)。服务执行确认部32当在步骤SP204的判断中获得否定结果时，进行待机直至接收到判定结果。

与此相对，服务执行确认部32当在步骤SP204的判断中获得肯定结果时，通过画面显示部31将检查结果显示在显示画面中(SP205)，并结束该ECU检查处理。

图22表示服务提供服务器2侧的ECU检查处理的详细的处理顺序。在此，对在图20的ECU检查处理中由服务提供服务器2执行的处理的详细的处理顺序进行说明。

服务提供服务器2的检查数据投入部24根据来自检查控制部22的指示定期或者不定期地参照时间表信息276，来取得检查预定的“日期时间”，由此核对时间表(SP211)。然后，检查数据投入部24判断是否存在应该实施的检查(SP212)。

检查数据投入部24当在步骤SP212的判断中获得否定结果时，移至步骤SP211。与此相对，检查数据投入部24当在步骤SP212的判断中获得肯定结果时，将检查实施通知发送至附带通信功能的终端3(SP213)。

接下来，检查数据投入部24从安全检查用数据信息274以及动作检查用数据信息275取得检查用数据，并将该检查用数据发送至检查对象的汽车1的网关11(SP214)。

接下来，检查控制部22在等待检查结果完成通知的状态下(SP215)，判断是否接收到从网关11发送的检查结果完成通知(SP216)。检查控制部22当在步骤SP216的判断中获得否定结果时，转移至步骤SP215。

与此相对，检查控制部22当在步骤SP216的判断中获得否定结果时，通过检查结果回收部25将检查结果回收委托的通知发送至网关11(SP217)。接下来，检查结果回收部25在等待检查结果回收的状态下(SP218)，判断是否接收到从网关11发送的检查执行结果信息1162(SP219)。

检查结果回收部25当在步骤SP219的判断中获得否定结果时，转移至步骤SP218。与此相对，检查结果回收部25当在步骤SP219的判断中获得肯定结果时，将接收到的检查执行结果信息1162储存在检查结果信息280中。

然后，检查结果解析部26参照检查结果信息280以及检查对照结果信息281，将从ECU12实际输出的输出结果与预想的输出结果进行比较，由此来解析检查结果(SP220)，在为如预想的输出结果时判定为无异常，在不是如预想的输出结果时，判定为存在异常(SP221)。

然后，检查控制部22将判定结果发送至附带通信功能的终端3(SP222)，并结束该ECU检查处理。

图23表示汽车1的网关11侧的ECU检查处理的详细的处理顺序。在此，对在图20的ECU检查处理中网关11执行的处理的详细的处理顺序进行说明。

网关11的检查执行控制部111在等待来自服务提供服务器2的处理委托的状态下(SP231)，判断是否存在处理委托(SP232)。检查执行控制部111当在步骤SP232的判断中获得否定结果时，转移至步骤SP231，当获得肯定结果时，判定处理内容(SP233)。

检查执行控制部111在处理内容为检查实施委托的情况下，即在从服务提供服务器2接收到检查用数据的情况下，将接收的检查用数据储存在检查执行数据信息1161中(SP234)。接下来，检查执行控制部111确认汽车1的车辆状态(SP235)，判断汽车1是否为待机状态(SP236)。

检查执行控制部111在汽车1为待机状态的情况下(SP236：是)，通过检查执行部113，基于检查执行数据信息1161的“CAN－ID”和“检查数据”生成与CAN协议相符的消息，并将生成的消息发送至ECU12(SP237)。

接下来，检查执行控制部111通过检查监视部114取得从ECU12输出的数据，具体而言，捕捉分组，并将其储存在检查执行结果信息1162中(SP238)。接下来，检查执行控制部111将检查执行数据信息1161的“进展状况”更新成“完成”(SP239)。

接下来，检查执行控制部111参照检查执行数据信息1161的“进展状况”来确认是否存在未成为“完成”的项目，由此来确认在检查执行数据信息1161中是否未剩余应该发送至ECU12的检查用数据(SP240)。

检查执行控制部111当在步骤SP240的判断中获得否定结果时，转移至步骤SP236，当获得肯定结果时，将检查结果完成通知发送至服务提供服务器2(SP243)，并结束该ECU检查处理。

返回到步骤SP236，在汽车1不是待机状态的情况下(SP236：否)，可以待机直至成为待机状态为止，但是在此处，暂时停止检查(SP241)，将表示已停止的暂时停止通知发送至服务提供服务器2(SP243)，并结束该ECU检查处理。

返回到步骤SP233，检查执行控制部111在处理内容为检查结果回收委托的情况下，即在从服务提供服务器2接收到检查结果回收委托的通知的情况下，通过检查信息取得部112取得检查执行结果信息1162(SP242)，并将该检查执行结果信息1162发送至服务提供服务器2(SP243)，结束该ECU检查处理。

图24表示安全检查用数据生成处理的处理顺序。在ECU检查处理时(图20)或者ECU检查处理前的任意的定时，由服务提供服务器2执行该安全检查用数据生成处理。

首先，服务提供服务器2的检查数据生成部23参照检查对象ECU信息273，取得“检查对象标志”为“对象”的“ECU－ID”来作为检查对象的ECU－ID(SP31)。接下来，检查数据生成部23取得与作为检查对象而确定的ECU－ID对应的“CAN－ID”(SP32)。

接下来，检查数据生成部23通过域构造解析部232，参照域构造信息277，取得与在步骤SP32中取得的CAN－ID对应的“详细域ID”以及“比特数”，由此解析数据域(图15)的域构造(SP33)。

例如，域构造解析部232参照域构造信息277，当在步骤SP32中取得的CAN－ID为“0×7E0”的情况下，取得与“0×7E0”的CAN－ID对应的“A1”、“A2”、“A3”、“A4”的详细域ID。

另外，域构造解析部232取得与这些“A1”～“A4”的详细域ID对应的“8bit”、“8bit”、“16bit”、“32bit”的各比特数。结果，域构造解析部232能够取得将数据域的构造划分成“A1”～“A4”的四个，各划分分别为“8bit”、“8bit”、“16bit”、“32bit”的解析结果。

此外，域构造解析部232参照域构造信息277，取得与“A1”～“A4”的详细域ID对应的“D1”、“D2”、“D2”、“D4”的划分ID，并参照域划分信息278，取得与“D1”、“D2”、“D4”对应的“有效位”、“可变数据”、“伪”的划分名称，由此能够解析在“A1”～“A4”中存储的数据表示的含义。

接下来，检查数据生成部23通过依赖关系解析部231，参照域依赖关系信息279，取得与在步骤SP32中取得的CAN－ID对应的“详细域的依赖关系”(SP34)。

例如，依赖关系解析部231参照域依赖关系信息279，当在步骤SP32中取得的CAN－ID为“0×7E0”的情况下，取得与“0×7E0”的CAN－ID对应的{A1、(A2&A3)、A4}这样的依赖关系。在该情况下，储存在“A2”的划分中的数据与储存在“A3”的划分中的数据之间存在依赖关系。

接下来，检查数据生成部23通过检查数据分配部233，基于在步骤SP33中取得的“比特数”以及在步骤SP34中取得的“详细域的依赖关系”，决定随机数据的分配数(SP35)。

例如，检查数据生成部23并非向全部具有64比特的全部数据域分配随机的数据，而是从检查效率的观点出发，向在数据域中能够实现更有效的检查的位置分配随机数据。在此，因为在“A2”以及“A3”之间存在依赖关系，“A2”以及“A3”分别是“8bit”以及“16bit”，因此检查数据生成部23将随机数据的分配数决定为24bit。

此外，检查数据生成部23可以如上所述，以依赖关系单位决定随机数据的分配数，也可以与域划分信息278的“划分ID”的特征相符地根据优先度来决定随机数据的分配数。例如，可以对“A1”分配随机数据，对“A2”～“A4”分配固定数据。

接下来，检查数据生成部23通过检查数据分配部233，并基于在步骤SP35中决定的数据的分配数，决定使用随机数据的范围，生成检查用数据(SP36)。然后，检查数据生成部23将生成的数据储存在安全检查用数据信息274中(SP37)。

接下来，检查数据生成部23判断是否未剩余在步骤SP34中取得的依赖关系中的、未生成检查用数据的依赖关系(SP38)。检查数据生成部23当在步骤SP38的判断中获得否定结果时，转移至步骤SP36，当获得肯定结果时，结束该安全检查用数据生成处理。

(6)本实施方式的效果

如以上那样，根据本实施方式的检查系统5，除了在ECU12的设计阶段预先准备的动作检查用数据之外，向ECU12还发送在ECU12的设计阶段未假想ECU12会接收的安全检查用数据，判断从ECU12输出的数据是否在正常的范围内，因此能够正确地检查运用时的ECU12的动作。

(7)其他的实施方式

在上述说明的本实施方式中，服务提供服务器2的检查结果解析部26参照检查结果信息280以及检查对照结果信息281，解析检查结果信息280，判定解析结果(图20：SP37以及SP38)，但不限于此，可以使汽车1的网关11具备检查结果解析部26以及检查对照结果信息281，网关11通过检查结果解析部26参照检查执行数据信息1161以及检查对照结果信息281，来解析检查执行数据信息1161，判定解析结果。

图25表示其他的实施方式的ECU检查处理的处理顺序。关于其他的实施方式的ECU检查处理，在网关11解析检查结果(SP31A)，判定解析结果(SP32A)这一点以及网关11取得判定结果(SP36A)，并向服务提供服务器2(或者附带直接通信功能的终端3)进行发送(SP37A)这一点上，与上述说明的本实施方式的ECU检查处理(图20)不同。

符号说明

1 汽车；

2 服务提供服务器；

3 附带通信功能的终端；

4 通信网；

5 检查系统。