不正常检测规则更新方法、电子控制单元和车载网络系统与流程

本申请是申请日为2015年11月17日、申请号为201580017000.5、发明名称为：“不正常检测规则更新方法、不正常检测电子控制单元以及车载网络系统”的中国专利申请的分案申请。

本公开涉及对于为了检测在电子控制单元进行通信的车载网络等中所发送的不正常帧而使用的不正常检测规则的更新(update)技术。

背景技术：

近年来，在汽车中的系统内，配置有许多称为电子控制单元(ecu：electroniccontrolunit)的装置。连接这些ecu的网络称为车载网络。车载网络存在多种标准。作为其中最主流的车载网络之一，存在由iso11898-1规定的can(controllerareanetwork：控制器局域网络)这一标准。

在can中，通信路径由两条总线构成，与总线连接的ecu称为节点。与总线连接的各节点收发被称为帧的消息。发送帧的发送节点通过在两条总线上施加电压，并在总线间产生电位差，从而发送被称为隐性(recessive)的值“1”和被称为显性(dominant)的值“0”。多个发送节点在完全相同的定时发送了隐性和显性的情况下，优先发送显性。接收节点在接收到的帧的格式存在异常的情况下，发送被称为错误帧(errorframe)的帧。错误帧是通过连续地发送6比特(bit)的显性，从而向发送节点和/或其他接收节点通知帧的异常的帧。

另外，在can中不存在指示发送目的地或发送源的识别符，发送节点在每帧中附加被称为消息id的id并进行发送(也即是，向总线送出信号)，各接收节点仅接收预先确定的消息id(也即是，从总线读取信号)。另外，采用csma/ca(carriersensemultipleaccess/collisionavoidance：载波侦听多址访问/冲突避免)方式，在多个节点的同时发送时，进行利用消息id的仲裁(调停)，优先发送消息id的值小的帧。

以往已知如下技术：在异常消息被发送到了can总线上的情况下，连接总线间的网关装置检测异常消息而不传送给其他总线，由此抑制总线的负荷的上升(参照“专利文献1”)。另外，已知对周期性地发送来的消息的周期进行进行检查并判定不正常帧的技术(参照“非专利文献1”)。

现有技术文献

专利文献

专利文献1：日本特开2007-38904号公报

非专利文献

非专利文献1：大塚敏史、石郷岡祐，“既存ecuを変更不要な車載lan向け侵入検知手法(不需要变更既有ecu的对车载lan的侵入检测方法)”，研究报告嵌入系统(emb)，信息处理学会，2013年3月6日，2013-emb-28卷，6号，1-5页

技术实现要素：

然而，例如伴随构成车载网络系统的ecu的功能的变更(改良等)，可能会产生对用于将消息(帧)判定为不正常(异常)的判定基准即规则进行更新的需要。另外，当规则固定时，例如不正常ecu连接到车载网络并发送避开该规则的消息的风险会变高，因此，规则的变更(更新)能够是有用的。

因此，本公开提供一种能够在车载网络系统中根据需要来对成为用于检测不正常帧的基准的规则进行更新的不正常检测规则更新方法。另外，本公开提供一种能够进行该规则的更新的车载网络系统以及在该车载网络系统中检测不正常帧的不正常检测电子控制单元(不正常检测ecu)。

为了解决上述问题，本公开的一个技术方案涉及的不正常检测规则更新方法是在车载网络系统中使用的不正常检测规则更新方法，所述车载网络系统具备通过经由一条以上的总线的通信来进行消息收发的多个电子控制单元、和与所述总线连接的不正常检测电子控制单元，所述不正常检测规则更新方法包括：在所述不正常检测电子控制单元中，基于不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性；从所述车载网络系统的外部的外部装置接收包含更新用不正常检测规则的发布数据，在满足了预定更新条件的情况下，将所述判定所涉及的所述不正常检测规则更新为该更新用不正常检测规则。

另外，为了解决上述问题，本公开的一个技术方案涉及的不正常检测电子控制单元是与供多个电子控制单元用于通信的总线连接的不正常检测电子控制单元，所述不正常检测电子控制单元具备：保持不正常检测规则的不正常检测规则保持部；不正常检测处理部，其基于所述不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性；以及更新判定部，其接收包含更新用不正常检测规则的发布数据，在满足了预定更新条件的情况下，将所述不正常检测规则保持部保持的所述不正常检测规则更新为该更新用不正常检测规则。

另外，为了解决上述问题，本公开的一个技术方案涉及的车载网络系统是具备通过经由一条以上的总线的通信来进行消息收发的多个电子控制单元、和与所述总线连接的不正常检测电子控制单元的车载网络系统，所述不正常检测电子控制单元基于不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性，所述电子控制单元从所述车载网络系统的外部的外部装置接收包含更新用不正常检测规则的发布数据，经由所述总线发送该更新用不正常检测规则，所述不正常检测电子控制单元从所述总线接收所述更新用不正常检测规则，在满足了预定更新条件的情况下，将与所述判定所涉及的所述不正常检测规则更新为该更新用不正常检测规则。

根据本公开，能够进行成为判定为在车载网络中发送了不正常帧的基准的规则的更新，由此，检测不正常帧的功能能够得以更新。因此，能够应对车载网络系统的变更等，另外，能够降低在车载网络中不正常ecu避开规则发送消息的风险。

附图说明

图1是表示实施方式1涉及的车载网络系统的整体构成的图。

图2是表示由can协议规定的数据帧的格式的图。

图3是实施方式1涉及的ecu的构成图。

图4是表示实施方式1涉及的ecu保持的接收id列表的一例的图。

图5是表示实施方式1涉及的ecu保持的接收id列表的一例的图。

图6是表示实施方式1涉及的ecu保持的接收id列表的一例的图。

图7是表示从与发动机连接的ecu发送的帧中的消息id以及数据的一例的图。

图8是表示从与制动器连接的ecu发送的帧中的消息id以及数据的一例的图。

图9是表示从与门开闭传感器连接的ecu发送的帧中的消息id以及数据的一例的图。

图10是表示从与窗开闭传感器连接的ecu发送的帧中的消息id以及数据的一例的图。

图11是表示从与角部传感器连接的ecu发送的帧中的消息id以及数据的一例的图。

图12是实施方式1涉及的网关的构成图。

图13是表示实施方式1涉及的网关保持的传送规则的一例的图。

图14是实施方式1涉及的不正常检测ecu的构成图。

图15是表示实施方式1涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图16是表示实施方式1涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图17是表示实施方式1涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图18是表示实施方式1涉及的发布数据格式的一例的图。

图19是表示实施方式1涉及的发布数据的一例的图。

图20是表示实施方式1涉及的更新结果数据格式的一例的图。

图21是表示实施方式1涉及的更新结果数据的一例的图。

图22是实施方式1涉及的服务器的构成图。

图23是表示实施方式1涉及的更新结果表的一例的图。

图24是表示实施方式1中的不正常帧的检测以及阻止其执行所涉及的工作例的时序图。

图25是表示实施方式1中的不正常检测规则的更新所涉及的工作例的时序图(后接图26)。

图26是表示实施方式1中的不正常检测规则的更新所涉及的工作例的时序图(前接图25)。

图27是实施方式1的变形例涉及的不正常检测ecu的构成图。

图28是表示实施方式1的变形例中的不正常检测规则的更新所涉及的工作例的时序图(后接图29)。

图29是表示实施方式1的变形例中的不正常检测规则的更新所涉及的工作例的时序图(前接图28)。

图30是表示实施方式2涉及的车载网络系统的整体构成的图。

图31是实施方式2涉及的头单元(headunit)的构成图。

图32是表示实施方式2涉及的头单元保持的接收id列表的一例的图。

图33是表示实施方式2涉及的内部发布数据的一例的图。

图34是表示实施方式2涉及的内部更新结果数据的一例的图。

图35是表示实施方式2涉及的网关保持的传送规则的一例的图。

图36是实施方式2涉及的不正常检测ecu的构成图。

图37是表示实施方式2涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图38是表示实施方式2涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图39是表示实施方式2涉及的不正常检测ecu保持的不正常检测规则以及版本信息的一例的图。

图40是实施方式2涉及的服务器的构成图。

图41是表示实施方式2涉及的内部更新结果表的一例的图。

图42是表示实施方式2中的不正常检测规则的更新所涉及的工作例的时序图(后接图43)。

图43是表示实施方式2中的不正常检测规则的更新所涉及的工作例的时序图(前接图42)。

具体实施方式

本公开的一个技术方案涉及的不正常检测规则更新方法是在车载网络系统中使用的不正常检测规则更新方法，所述车载网络系统具备通过经由一条以上的总线的通信来进行消息收发的多个电子控制单元、和与所述总线连接的不正常检测电子控制单元，所述不正常检测规则更新方法包括：在所述不正常检测电子控制单元中，基于不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性；从所述车载网络系统的外部的外部装置接收包含更新用不正常检测规则的发布数据，在满足了预定更新条件的情况下，将所述判定所涉及的所述不正常检测规则更新为该更新用不正常检测规则。由此，能够进行成为判定为在车载网络中发送了不正常帧的基准的规则的更新。因此，能够应对车载网络系统的变更等，另外，能够降低在车载网络中不正常ecu避开规则发送消息的风险。

另外，也可以为，所述发布数据包含总线类别信息，该总线类别信息表示所述更新用不正常检测规则的适用对象的总线的类别，所述不正常检测电子控制单元在所述总线类别信息表示连接有该不正常检测电子控制单元的所述总线的类别的情况下，认为满足了所述预定更新条件而进行所述更新。由此，能够应对按总线的类别而所需的不正常检测规则不同这一情况。

另外，也可以为，所述发布数据包含多个更新用不正常检测规则，并包含与该多个更新用不正常检测规则分别对应的表示总线的类别的总线类别信息，所述不正常检测电子控制单元通过与所述外部装置通信来进行所述发布数据的所述接收，从所述发布数据中提取与同连接有该不正常检测电子控制单元的所述总线的类别相符的总线类别信息对应的更新用不正常检测规则，将所述判定所涉及的所述不正常检测规则更新为所提取出的该更新用不正常检测规则。由此，能够在发布不正常检测规则的外部装置侧进行一并的发布，能减轻处理负担。

另外，也可以为，所所述发布数据包含多个更新用不正常检测规则，并包含与该多个更新用不正常检测规则分别对应的表示总线的类别的总线类别信息，一个所述电子控制单元进行所述发布数据的所述接收，将该发布数据中的各更新用不正常检测规则包含于与对应的总线类别信息表示的总线的类别相应的、附加有不正常检测规则更新用的消息id的消息中，并经由所述总线进行发送，所述不正常检测电子控制单元从连接有该不正常检测电子控制单元的所述总线接收与该总线的类别相应的、不正常检测规则更新用的消息id的消息，将所述判定所涉及的所述不正常检测规则更新为该消息所包含的更新用不正常检测规则。由此，由于仅一个ecu与外部进行通信，因此能够减轻各个不正常检测ecu的处理负荷。另外，根据该构成，在对通信内容确保安全性的加密处理等的实际配置方面，即使在与外部进行通信的ecu中例如使用处理负荷大的加密方式，也能够在不与外部进行通信的各不正常检测ecu中选择处理负荷小的加密方式。另外，与各个不正常检测ecu进行通信的情况相比，能够减少服务器与车载网络系统之间的通信次数。

另外，也可以为，所述发布数据包含附属信息，所述预定更新条件是与所述附属信息有关的条件，在所接收到的所述发布数据中的所述附属信息满足所述预定更新条件的情况下，进行所述不正常检测规则的所述更新，在所述附属信息不满足所述预定更新条件的情况下，不进行所述不正常检测规则的所述更新。由此，能够基于与更新用不正常检测规则有关的信息来判别是否需要更新。

另外，也可以为，根据对所述附属信息与所述电子控制单元或所述不正常检测电子控制单元保持的信息进行比较而得到的结果，判别是否满足所述预定更新条件。由此，能够进行更新用不正常检测规则的版本是否比既有的不正常检测规则的版本新等的比较判断。

另外，也可以为，所述附属信息表示所述更新用不正常检测规则的版本，所述不正常检测电子控制单元在所述附属信息表示比作为所述判定的基础的所述不正常检测规则的版本新的版本的情况下，判别为满足了所述预定更新条件，进行所述更新。由此，能够针对不正常检测规则的内容变更进行基于版本的管理。

另外，也可以为，所述附属信息表示所述更新用不正常检测规则的适用对象的车辆类别，在所述附属信息表示与搭载所述车载网络系统的车辆相关的车辆类别的情况下，认为满足了所述预定更新条件而进行所述更新。由此，能够按各种车型独立地规定不正常检测规则。

另外，也可以为，所述预定更新条件是搭载所述车载网络系统的车辆的状态处于预定状态这一条件。由此，通过将例如安全性相对较高的状态等设定为预定状态，能够安全地进行不正常检测规则的更新。

另外，也可以为，在接收到所述发布数据时所述车辆的状态不处于所述预定状态的情况下，在所述车辆的状态变化为所述预定状态时，将所述判定所涉及的所述不正常检测规则更新为已经接收到的该发布数据所包含的所述更新用不正常检测规则，或者，从所述外部装置重新接收所述发布数据并将所述不正常检测规则更新为重新接收到的该发布数据所包含的所述更新用不正常检测规则。由此，能够在车辆的状态变化为预定状态时适当地进行不正常检测规则的更新。

另外，也可以为，所述不正常检测规则以及所述更新用不正常检测规则构成为包含用于判定对规则的符合性的程序。由此，能够进行用于不正常检测的程序的更新。

另外，也可以为，对所述发布数据实施加密处理，在所述发布数据的所述接收时实施与所述加密处理呼应的处理。由此，能够对不正常检测规则确保安全性。

另外，也可以为，所述多个电子控制单元遵循can协议即控制器局域网协议，经由所述总线进行通信。由此，能够在遵循can的车载网络系统中进行不正常检测规则的更新。

另外，本公开的一个技术方案涉及的不正常检测电子控制单元是与供多个电子控制单元用于通信的总线连接的不正常检测电子控制单元，所述不正常检测电子控制单元具备：保持不正常检测规则的不正常检测规则保持部；不正常检测处理部，其基于所述不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性；以及更新判定部，其接收包含更新用不正常检测规则的发布数据，在满足了预定更新条件的情况下，将所述不正常检测规则保持部保持的所述不正常检测规则更新为该更新用不正常检测规则。由此，能够进行成为判定为发送了不正常帧的基准的规则的更新。

另外，本公开的一个技术方案涉及的车载网络系统是具备通过经由一条以上的总线的通信来进行消息收发的多个电子控制单元、和与所述总线连接的不正常检测电子控制单元的车载网络系统，所述不正常检测电子控制单元基于不正常检测规则，针对在连接有该不正常检测电子控制单元的所述总线上发送的消息，判定该消息对规则的符合性，所述电子控制单元从所述车载网络系统的外部的外部装置接收包含更新用不正常检测规则的发布数据，经由所述总线发送该更新用不正常检测规则，所述不正常检测电子控制单元从所述总线接收所述更新用不正常检测规则，在满足了预定更新条件的情况下，将与所述判定所涉及的所述不正常检测规则更新为该更新用不正常检测规则。由此，由于能够进行不正常检测规则的更新，因此能够应对车载网络系统的构成的变更等，另外，能够降低在车载网络中不正常ecu避开规则发送消息的风险。

此外，这些总括性或具体的技术方案既可以通过系统、方法、集成电路、计算机程序或者计算机可读取的cd-rom等记录介质来实现，也可以通过系统、方法、集成电路、计算机程序和记录介质的任意组合来实现。

以下，参照附图对使用实施方式涉及的不正常检测规则更新方法的车载网络系统进行说明。在此所示的实施方式均表示本公开的一个具体例子。因此，以下的实施方式中示出的数值、构成要素、构成要素的配置以及连接方式、步骤(工序)以及步骤的顺序等是一个例子，并不是限定本公开的技术方案。关于以下的实施方式中的构成要素中的未记载在独立权利要求中的构成要素，是能够任意附加的构成要素。另外，各图是示意图，不一定是严格图示。

(实施方式1)

以下，作为本公开的实施方式，使用附图对不正常检测规则更新方法进行说明，所述不正常检测规则更新方法是在搭载于车辆并供多个ecu经由总线进行通信的车载网络系统10中，对为了供不正常检测ecu检测送出到总线的不正常帧(消息)而使用的不正常检测规则进行更新的方法。不正常检测ecu针对在用于构成车载网络系统10的ecu间的通信的总线上发送的帧，基于不正常检测规则来进行检查(即对规则的符合性的判定)。通过有效利用了不正常检测ecu的检查(即不正常检测)的结果的处理，例如能够防止因不正常ecu被连接到总线并发送不符合规则的不正常帧等而导致不适当地控制车辆。在本实施方式中，示出如下例子：连接于各条总线的各不正常检测ecu通过与车辆外部的服务器进行通信来更新不正常检测功能(即，更新成为将帧判定为不正常的基准、基础等的不正常检测规则)。

[1.1车载网络系统10的整体构成]

图1是表示车载网络系统10的整体构成的图。车载网络系统10是遵循can协议进行通信的网络通信系统的一例，是搭载有控制装置、传感器等各种设备的汽车中的网络通信系统。车载网络系统10构成为包括总线200a～200c、不正常检测ecu400a～400c、网关300a、300b、以及与各种设备连接的ecu100a～100e等ecu这样的连接于总线的各节点。另外，在图1中，附注有与车载网络系统10中的不正常检测ecu400a～400c进行无线通信的外部的网络600和以能够通信的方式与该网络600连接的服务器500。此外，虽然图1中进行了省略，但车载网络系统10除了ecu100a～100e以外还可以包括很多ecu。在车载网络系统10中各ecu遵循can协议进行帧的收发。ecu例如是包括处理器(微处理器)、存储器等的数字电路、模拟电路、通信线路等的装置。存储器是rom、ram等，能够存储由处理器执行的控制程序(计算机程序)。例如处理器按照控制程序(计算机程序)进行工作，由此ecu会实现各种功能。此外，计算机程序是为了实现预定的功能而组合多个表示对处理器的指令的命令代码而构成的。在总线200a～200c上有可能会连接有发送不正常消息的不正常ecu，不正常检测ecu400a～400c基于不正常检测规则来检测不符合规则的不正常帧出现在总线上的情况和该不正常帧。

不正常检测ecu400a、400b、400c分别是与总线200a、总线200b、总线200c连接的一种ecu，具有如下功能：在监视在连接有本ecu的总线上出现的帧而检测到不正常帧的情况下，发送错误帧。

ecu100a～100e与某一条总线连接，另外，分别与发动机101、制动器102、门开闭传感器103、窗开闭传感器104、角部传感器(cornersensor)105连接。ecu100a～100e分别取得所连接的设备(发动机101等)的状态，定期地将表示状态的帧(后述的数据帧)等发送到网络(即总线)。

网关300a与连接不正常检测ecu400a、ecu100a以及ecu100b的总线200a、连接不正常检测ecu400b、ecu100c以及ecu100d的总线200b连接。网关300b与连接不正常检测ecu400b、ecu100c以及ecu100d的总线200b和连接不正常检测ecu400c以及ecu100e的总线200c连接。网关300a、300b具有将从某总线接收到的帧传送给其他总线的功能。另外，也能够按所连接的各总线间来切换是否传送所接收到的帧。网关300a、300b也是一种ecu。

服务器500具有如下功能：为了对不正常检测ecu400a～400c的不正常检测功能进行更新(update)而发送发布数据。服务器500与不正常检测ecu400a～400c之间的通信方式可以使用任何方式，例如除了无线通信之外也可以使用有线通信。在无线通信中，也可以使用wifi(注册商标)、或便携电话网等所使用的3g(3rdgeneration)线路、4g(lte：longtermevolution)等。

[1.2数据帧格式]

以下，对作为在遵循can协议的网络中使用的帧之一的数据帧进行说明。

图2是表示由can协议规定的数据帧的格式的图。该图示出了由can协议规定的标准id格式的数据帧。数据帧由sof(startofframe，帧起始)、id域(field)、rtr(remotetransmissionrequest，远程发送请求)、ide(identifierextension，标识符扩展)、预约位“r”、dlc(datalengthcode，数据长度码)、数据域、crc(cyclicredundancycheck，循环冗余校验)时序、crc定界符“del”、ack(acknowledgement，应答)间隙(slot)、ack定界符“del”、以及eof(endofframe，帧结束)的各域构成。

sof由1比特的显性构成。总线空闲的状态成为隐性，通过由sof变更为显性，通知帧的发送开始。

id域是由11比特构成的保存表示数据种类的值即id(消息id)的域。在多个节点同时开始了发送的情况下，为了通过该id域进行通信仲裁，设计成使具有id小的值的帧具有高优先级。

rtr是用于识别数据帧和远程帧的值，在数据帧中由1比特的显性构成。

ide和“r”两方都由1比特的显性构成。

dlc由4比特构成，是表示数据域的长度的值。此外，将ide、r以及dlc一起称为控制域。

数据域是最大64由比特构成的表示要发送的数据的内容的值。能够按每8比特来调整长度。所发送的数据的规格不在can协议中规定，而在车载网络系统10中确定。因此，为取决于车型、制造者(制造商)等的规格。

crc序列由15比特构成。根据sof、id域、控制域以及数据域的发送值来算出。

crc定界符是由1比特的隐性构成的表示crc序列的结束的分隔符号。此外，将crc序列和crc定界符一起称为crc域。

ack间隙由1比特构成。发送节点将ack间隙设为隐性并进行发送。如果到crc序列为止能够正常接收，则接收节点将ack间隙设为显性并发送。由于显性比隐性优先，因此，如果在发送后ack间隙为显性，则发送节点能够确认某一个接收节点接收成功。

ack定界符由1比特的隐性构成，是表示ack的结束的分隔符号。

eof由7比特的隐性构成，表示数据帧的结束。

[1.3ecu100a的构成]

图3是ecu100a的构成图。ecu100a构成为包括帧收发部110、帧解释部120、接收id判断部130、接收id列表保持部140、帧处理部150、帧生成部160和数据取得部170。这些各构成要素是功能性的构成要素，该各功能通过ecu100a中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。

帧收发部110相对于总线200a收发遵循can协议的帧。从总线200a逐比特地接收帧，并传送给帧解释部120。另外，将由帧生成部160收到了通知的帧的内容传送给总线200a。

帧解释部120从帧收发部110接收帧的值，并进行解释以使得向由can协议规定的帧格式的各域进行映射。判断为id域的值被传送给接收id判断部130。帧解释部120根据从接收id判断部130通知的判定结果，决定是将id域的值和id域之后出现的数据域传送给帧处理部150、还是在收到该判定结果之后中止帧的接收(即中止作为该帧的解释)。另外，帧解释部120例如在判断为是未遵循can协议的帧的情况下，向帧生成部160进行通知，以使得发送错误帧。另外，帧解释部120在接收到错误帧的情况下，即在根据所接收到的帧的值而解释为成为错误帧的情况下，自此之后丢弃该帧，即中止帧的解释。

接收id判断部130接收从帧解释部120通知的id域的值，按照接收id列表保持部140保持的消息id的列表，进行是否接收该id域之后的帧的各域的判定。接收id判断部130将该判定结果通知给帧解释部120。

接收id列表保持部140保持ecu100a接收的id(消息id)的列表即接收id列表。图4中示出接收id列表的一例。

帧处理部150根据所接收到的帧的数据，进行与按每个ecu不同的功能相关的处理。例如，与发动机101连接的ecu100a具备在时速超过了30km的状态下门开着的状态时鸣响警报声的功能。ecu100a例如具有用于鸣响警报声的扬声器等。并且，ecu100a的帧处理部150管理从其他ecu接收到的数据(例如表示门的状态的信息)，基于从发动机101取得的时速来进行在一定条件下鸣响警报声的处理等。

数据取得部170取得表示与ecu连接的设备、传感器等的状态的数据，并通知给帧生成部160。

帧生成部160按照从帧解释部120通知的指示错误帧发送的通知，构成错误帧，将错误帧通知给帧收发部110并使其发送该错误帧。另外，帧生成部160对从数据取得部170通知的数据的值附加预先确定的消息id来构成帧，并通知给帧收发部110。

此外，ecu100b～100e也具备与上述的ecu100a基本上同样的构成。但是，接收id列表保持部140所保持的接收id列表可能会成为按各个ecu而不同的内容，但也可以是相同内容。另外，帧处理部150的处理内容按各个ecu而不同。例如，ecu100c中的帧处理部150的处理内容包括与在未施加制动的状况下打开门时鸣响警报声的功能相关的处理。例如，ecu100b、ecu100d以及ecu100e中的帧处理部150不进行特别的处理。此外，各ecu也可以具备在此例示的功能以外的功能。此外，关于ecu100a～100e分别发送的帧的内容，在后面使用图7～图1进行说明。

[1.4接收id列表例1]

图4是表示在ecu100a和ecu100b的各ecu中保持的接收id列表的一例的图。该图所例示的接收id列表用于选择性地接收包含id(消息id)的值为“1”、“2”和“3”的某一个的消息id的帧并进行处理。

[1.5接收id列表例2]

图5是表示在ecu100c和ecu100d的各ecu中保持的接收id列表的一例的图。该图所例示的接收id列表用于选择性地接收包含id(消息id)的值为“1”、“2”、“3”和“4”的某一个的消息id的帧并进行处理。

[1.6接收id列表例3]

图6是表示在ecu100e、网关300a和网关300b各自中保持的接收id列表的一例的图。该图所例示的接收id列表用于选择性地接收包含id(消息id)的值为“1”、“2”、“3”、“4”和“5”的某一个的消息id的帧并进行处理。

[1.7与发动机相关的ecu100a的发送帧例]

图7是表示从与发动机101连接的ecu100a发送的帧的id(消息id)以及数据域(数据)的一例的图。ecu100a发送的帧的消息id为“1”。数据表示时速(km/小时)，取最低0(km/小时)～最高180(km/小时)的范围内的值，数据长为1个字节。从图7的上面的行向下面的行例示了与从ecu100a逐次发送的各帧对应的各消息id以及数据，示出了从0km/小时起每次加速1km/小时的情形。

[1.8与制动器相关的ecu100b的发送帧例]

图8是表示从与制动器102连接的ecu100b发送的帧的id(消息id)以及数据域(数据)的一例的图。ecu100b发送的帧的消息id为“2”。数据以比例(％)的方式表示制动的施加情况，数据长为1个字节。对于该比例，将完全没有施加制动的状态设为0(％)，将最大限度地施加制动的状态设为100(％)。从图8的上面的行向下面的行例示了与从ecu100b逐次发送的各帧对应的各消息id以及数据，示出了从100％逐渐减弱制动的情形。

[1.9与门开闭传感器相关的ecu100c的发送帧例]

图9是表示从与门开闭传感器103连接的ecu100c发送的帧的id(消息id)以及数据域(数据)的一例的图。ecu100c发送的帧的消息id为“3”。数据表示门的开关状态，数据长为1个字节。对于数据的值，开着门的状态为“1”，关着门的状态为“0”。从图9的上面的行向下面的行例示了与从ecu100c逐次发送的各帧对应的各消息id以及数据，示出了从开着门的状态接着转变为关闭的状态的情形。

[1.10与窗开闭传感器相关的ecu100d的发送帧例]

图10是表示从与窗开闭传感器104连接的ecu100d发送的帧的id(消息id)以及数据域(数据)的一例的图。ecu100d发送的帧的消息id为“4”。数据以比例(％)的方式表示窗的开关状态，数据长为1个字节。对于该比例，将窗完全关着的状态设为0(％)，将窗完全开着的状态设为100(％)。从图10的上面的行向下面的行例示了与从ecu100d逐次发送的各帧对应的各消息id以及数据，示出了从关着窗的状态逐渐打开的情形。

[1.11与角部传感器相关的ecu100e的发送帧例]

图11是示出从与角部传感器105连接的ecu100e发送的帧中的id(消息id)以及数据域(数据)的一例的图。ecu100e发送的帧的消息id为“5”。数据长度为一个字节，关于数据的值，如果角部传感器105检测到在距车辆的角部一定距离范围内存在障碍物则为“1”，如果未检测到障碍物则为“0”。从图11的上面的行向下面的行例示了与从ecu100e定期地发送的各帧对应的各消息id以及数据，示出了从在车辆的角部未检测到障碍物的状态接着转变为检测到障碍物的状态的情形。

[1.12网关300a的构成]

图12是网关300a的构成图。网关300a构成为包括帧收发部310、帧解释部320、接收id判断部330、接收id列表保持部340、传送处理部351、传送规则保持部352和帧生成部360。此外，网关300b也具有同样的构成。这些各构成要素是功能性的构成要素，该各功能通过网关300a中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。

帧收发部310相对于总线200a、200b、200c分别收发遵循can协议的帧。从总线逐比特地接收帧，并传送给帧解释部320。另外，基于从帧生成部360收到了通知的表示传送目的地的总线的总线信息以及帧，将该帧的内容逐比特地发送到总线200a、200b、200c。

帧解释部320从帧收发部310接收帧的值，进行解释以使得向由can协议规定的帧格式的各域进行映射。判断为id域的值被传送给接收id判断部330。帧解释部320根据从接收id判断部330通知的判定结果，决定是将id域的值和id域之后出现的数据域(数据)传送给传送处理部351、还是在收到了该判定结果之后中止帧的接收(即中止作为该帧的解释)。另外，帧解释部320在判断为是未遵循can协议的帧的情况下，向帧生成部360进行通知，以使得发送错误帧。另外，帧解释部320在接收到错误帧的情况下，即在根据所接收到的帧的值而解释为成为错误帧的情况下，自此之后将该帧废弃，即中止帧的解释。

接收id判断部330接收从帧解释部320通知的id域的值，按照接收id列表保持部340保持的消息id的列表，进行是否接收该id域之后的帧的各域的判定。接收id判断部330将该判定结果通知给帧解释部320。

接收id列表保持部340保持网关300a接收的id(消息id)的列表即接收id列表(参照图6)。

传送处理部351按照传送规则保持部352保持的传送规则，根据接收到的帧的消息id，决定要传送的总线，将表示要传送的总线的总线信息、从帧解释部320通知的消息id和数据通知给帧生成部360。此外，网关300a不将从某总线接收到的错误帧传送到其他总线。

传送规则保持部352保持表示各条总线的关于帧传送的规则的信息即传送规则。图13是示出了传送规则的一例的图。

帧生成部360按照从帧解释部320通知的指示错误帧发送的通知，构成错误帧，将错误帧通知给帧收发部310并使其发送该错误帧。另外，帧生成部360使用从传送处理部351通知的消息id和数据来构成帧，将帧以及总线信息通知给帧收发部310。

[1.13传送规则例]

图13示出网关300a以及网关300b保持的传送规则的一例。该传送规则使传送源的总线、传送目的地的总线和传送对象的id(消息id)相关联。图13中的“*”表示不管消息id如何都进行帧的传送这一情况。另外，图13中的“-”表示没有传送对象的帧这一情况。图13的例子示出了从总线200a接收的帧被设定为不管消息id如何都向总线200b进行传送。另外，示出了从总线200b接收的帧被设定为向总线200c传送全部帧，而向总线200a仅传送消息id为“3”的帧。另外，示出了从总线200c接收的帧被设定为不向总线200b进行传送。

[1.14不正常检测ecu400a的构成]

图14是不正常检测ecu400a的构成图。不正常检测ecu400a构成为包括帧收发部410、帧解释部420、帧生成部460、不正常检测处理部480、不正常检测规则保持部481、外部通信部490、加解密处理部491、mac处理部492、密钥保持部493、更新判定部494、车辆编号保持部495和总线类别保持部496。这些各构成要素是功能性的构成要素，该各功能通过不正常检测ecu400a中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。此外，不正常检测ecu400b以及不正常检测ecu400c也具备基本上同样的构成，但不正常检测规则保持部481的保持内容(不正常检测规则以及版本信息)可能会互不相同。

帧收发部410相对于总线200a收发遵循can协议的帧。即，帧收发部410从总线200a逐比特地接收帧，并传送给帧解释部420。另外，将从帧生成部460收到了通知的帧的内容发送给总线200a。

帧解释部420从帧收发部410接收帧的值，并进行解释以使得向由can协议规定的帧格式的各域进行映射。判断为id域的值被传送给不正常检测处理部480。另外，帧解释部420在判断为是未遵循can协议的帧的情况下，向帧生成部460进行通知，以使得发送错误帧。另外，帧解释部420在接收到错误帧的情况下，即在根据所接收到的帧的值而解释为成为错误帧的情况下，自此之后丢弃该帧，即中止帧的解释。

帧生成部460按照从帧解释部420通知的指示错误帧发送的通知，构成错误帧，将错误帧通知给帧收发部410并使其发送该错误帧。另外，帧生成部460使用从不正常检测处理部480通知的指示错误帧发送的通知，构成错误帧，将错误帧通知给帧收发部410并使其发送该错误帧。

不正常检测处理部480具有如下功能：基于不正常检测规则保持部481保持的不正常检测规则，对从总线200a取得的帧是否不正常进行判定。在本实施方式中，作为不正常检测规则，使用对不是不正常的消息id进行了列举的所谓的白名单(whitelist)。具体而言，不正常检测处理部480接收从帧解释部420通知的id域的值(id)，在该id未记载在作为不正常检测规则的消息id的列表(白名单)中的情况下，向帧生成部460进行通知，以使得发送错误帧。该情况下，在总线200a上，包含未记载在作为不正常检测规则的消息id的列表中的id的帧(不正常帧)的比特值，将会被连续多个优选于隐性的显性而构成的错误帧覆写。

不正常检测规则保持部481保持有对被发送到总线200a上的帧所包含的消息id进行了规定的列表来作为不正常检测规则，并保持有表示关于该不正常检测规则的版本的版本信息(参照图15)。另外，不正常检测规则保持部481根据来自更新判定部494的新的不正常检测规则(也称为更新用不正常检测规则)的通知，通过更新用不正常检测规则来更新先前保持的不正常检测规则，将更新后的结果通知给更新判定部494。

外部通信部490通过经由网络600与服务器500进行通信，取得包含用于更新不正常检测规则的更新用不正常检测规则(新的不正常检测规则)等的发布数据。另外，外部通信部490经由网络600将更新结果数据通知给服务器500。外部通信部490将所取得的发布数据发送给加解密处理部491，并取得解密后的结果。另外，将解密后的发布数据中的作为验证用数据的消息认证码(mac：messageauthenticationcode)通知给mac处理部492，并接收mac的验证结果。外部通信部490从解密后的发布数据中提取更新用不正常检测规则和附属信息(对象车型、总线类别、版本信息等)，并通知给更新判定部494。另外，基于从更新判定部494接收到的不正常检测规则的更新结果等，生成更新结果数据，通知给mac处理部492，并接收包含所生成的mac的更新结果数据。图18中示出发布数据格式的一例，图19中示出发布数据的一例。另外，图20中示出更新结果数据格式的一例，图21中示出更新结果数据的一例。从服务器500发布的发布数据被实施了加密处理。在此，服务器500实施的加密处理例如是加密、验证用数据的附加等。与此相对，加解密处理部491以及mac处理部492对发布数据执行与在服务器500等执行的加密处理呼应的处理(例如与加密呼应的解密、与验证用数据的附加呼应的验证)。

加解密处理部491使用从密钥保持部493取得的密钥对从外部通信部490通知的加密后的发布数据进行解密，将解密后的发布数据通知给外部通信部490。

mac处理部492使用从密钥保持部493取得的密钥，对从外部通信部490通知的发布数据中的mac进行验证，将验证结果通知给外部通信部490。另外，mac处理部492基于从外部通信部490通知的更新结果数据，使用从密钥保持部493取得的密钥来生成mac并使该更新结果数据包含mac而通知给外部通信部490。

密钥保持部493对加解密处理部491和mac处理部492在加密处理中利用的密钥进行管理。

更新判定部494从外部通信部490接收更新用不正常检测规则和附属信息，基于从总线类别保持部496取得的总线类别、车辆编号保持部495保持的车型、和不正常检测规则保持部481保持的与不正常检测规则对应的版本信息，判别是否需要更新不正常检测规则保持部481保持的不正常检测规则。更新判定部494在判别为需要更新的情况下，向不正常检测规则保持部481进行通知，进行不正常检测规则的更新。另外，将更新结果和从车辆编号保持部495取得的车辆编号通知给外部通信部490。

车辆编号保持部495保持有表示搭载有不正常检测ecu400a的车辆的标识符的车辆编号(vehiclenumber)和该车辆的车型(车辆类别)。

总线类别保持部496保持有与不正常检测ecu400a连接的总线的类别。总线的类别例如有“驱动系统”、“车体系统”、“安全系统”等。“驱动系统”例如是供具有与发动机、马达、燃料、电池、传动装置(transmission)等的控制这样的车辆行驶关联的驱动系统功能的ecu连接的总线的类别。“车体系统”例如是供具有与车门锁、空调机、灯、方向指示灯(winker)等这样的车辆装备的控制关联的车体系统功能的ecu连接的总线的类别。“安全系统”例如是供具有自动制动、车道维持功能、车间距离维持功能、防碰撞功能、安全气囊等这样的用于自动且安全地实现舒适驾驶的安全功能的ecu连接的总线的类别。例如与车辆行驶关联的供发动机涉及的ecu100a以及制动器涉及的ecu100b连接的总线200a是“驱动系统”的总线。另外，与车辆装备的控制关联的供门开闭传感器涉及的ecu100c以及窗开闭传感器涉及的ecu100d连接的总线200b是“车体系统”的总线。另外，与防碰撞功能关联的供角部传感器涉及的ecu100e连接的总线200c是“安全系统”的总线。

[1.15不正常检测ecu400a中的不正常检测规则例]

图15示出不正常检测ecu400a保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则(列举了正规的消息id的列表)中，表示为：对于在连接不正常检测ecu400a的总线200a上发送的帧(消息)，若消息id不符合“1”、“2”和“3”的任一方，则为不正常帧。另外，版本信息表示该不正常检测规则的版本(ver.)为1.0。

[1.16不正常检测ecu400b中的不正常检测规则例]

图16示出不正常检测ecu400b保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则中，表示为：对于在连接不正常检测ecu400b的总线200b上发送的帧，若消息id不符合“1”、“2”、“3”和“4”的任一方，则为不正常帧。另外，版本信息表示该不正常检测规则的版本(ver.)为1.0。

[1.17不正常检测ecu400c中的不正常检测规则例]

图17示出不正常检测ecu400c保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则中，表示为：对于在连接不正常检测ecu400c的总线200c上发送的帧，若消息id不符合“1”、“2”、“3”、“4”和“5”的任一方，则为不正常帧。另外，版本信息表示该不正常检测规则的版本(ver.)为1.0。

[1.18发布数据格式例]

图18示出关于从服务器500对不正常检测ecu400a～400c发送的发布数据的格式(发布数据格式)的一例。该图的发布数据格式表示发布数据构成为包括对象车型、不正常检测规则列表、mac。对象车型表示搭载有应该更新发布数据的不正常检测规则列表所包含的更新用不正常检测规则(新的不正常检测规则)的不正常检测ecu的车辆的车型(车辆类别)。不正常检测规则列表包含与对象车型的车辆中的车载网络所包含的总线的各个类别对应的各不正常检测规则(更新用不正常检测规则)。

[1.19发布数据例]

图19示出关于发布数据的内容的一例。在该图的例子中，发布数据是对车型a的发布数据，表示在对象总线类别(总线类别信息)表示的“驱动系统”、“车体系统”和“安全系统”的各条总线上的不正常帧的检测中使用的不正常检测规则(更新用不正常检测规则)和其版本信息(不正常检测规则版本)。如此，发布数据构成为包括一个以上(在图19的例子中为多个)的更新用不正常检测规则和附属信息(对象车型、总线类别、版本信息等)。

[1.20更新结果数据格式例]

图20示出关于从不正常检测ecu400a～400c向服务器500发送的更新结果数据的格式(更新结果数据格式)的一例。该图的更新结果数据格式表示更新结果数据构成为包括对象车型、车辆编号、总线类别、更新后不正常检测规则版本(version)、mac。更新结果数据的对象车型以及车辆编号表示搭载有更新结果数据的发送源的不正常检测ecu的车辆的车型和该车辆的车辆编号。另外，更新结果数据的总线类别表示与更新结果数据的发送源的不正常检测ecu连接的总线的总线类别(即，总线类别保持部496保持的总线类别)。更新结果数据的更新后不正常检测规则版本是与在更新结果数据的发送源的不正常检测ecu中更新后的不正常检测规则对应的版本信息表示的版本。

[1.21更新结果数据例]

图21示出关于更新结果数据的内容的一例。该图的例子表示如下含义：“作为车型a的车辆编号00000001中的与驱动系统的总线连接的不正常检测ecu接收到发布数据的结果，将不正常检测规则更新为版本2.0”。如果作为不正常检测ecu接收到发布数据的结果是没有进行更新，则例如可以使得用“-”(无)表示更新结果数据中的不正常检测规则版本来表现未进行更新的含义。

[1.22服务器500的构成]

图22是服务器500的构成图。服务器500是位于搭载有车载网络系统10的车辆的外部的计算机。服务器500以在多个车辆分别搭载有车载网络系统10作为前提，对各车辆(即车载网络系统)发送包含不正常检测规则(更新用不正常检测规则)的发布数据，管理各车辆中的不正常检测规则的更新的状况。

如图22所示，服务器500构成为包括通信部510、发布数据管理部520、不正常检测规则保持部530、加解密处理部591、mac处理部592、密钥保持部593、更新结果管理部540和更新结果表保持部550。这些各构成要素是功能性的构成要素，该各功能通过服务器500中的硬盘、存储器等存储介质、执行存储器所保存的控制程序的处理器、通信线路等来实现。

通信部510将从发布数据管理部520通知来的发布数据经由网络600发送给不正常检测ecu400a～400c。另外，接收来自不正常检测ecu400a～400c的更新结果数据，并通知给更新结果管理部540。

发布数据管理部520从不正常检测规则保持部530取得最新版本的不正常检测规则和与该不正常检测规则对应的附属信息(对象车型、总线类别、版本信息等)。发布数据管理部520将所取得的不正常检测规则以及附属信息通知给mac处理部592来取得mac，将所取得的不正常检测规则、附属信息以及mac通知给加解密处理部591，取得加密后的发布数据(参照图18、图19)。由此，发布数据成为实施了验证用的mac的附加以及加密这种加密处理的数据。

不正常检测规则保持部530将最新版本的不正常检测规则(即，在各车载网络系统10中用于更新的更新用不正常检测规则)和与该不正常检测规则对应的附属信息保持于记录介质等。此外，不正常检测规则以及附属信息通过服务器500的管理者、运用者等的操作、或者通过从其他计算机接收，从而被保存于不正常检测规则保持部530的记录介质等。此外，制定不正常检测规则的制定者可以随着车辆类别的通信方式的变更来随时进行不正常检测规则的更新。另外，可以生成按特定车辆和/或总线类别而不同的不正常检测规则。

加解密处理部591使用从密钥保持部593取得的密钥对从发布数据管理部520通知的数据进行加密，并向发布数据管理部520通知加密后的发布数据。

mac处理部592使用从密钥保持部593取得的密钥，利用从发布数据管理部520通知的数据来生成mac，将所生成的mac通知给发布数据管理部520。另外，使用从密钥保持部593取得的密钥对从更新结果管理部540通知来的更新结果数据所包含的mac进行验证，将该验证结果通知给更新结果管理部540。

密钥保持部593对加解密处理部591和mac处理部592在加密处理中利用的密钥进行管理。

更新结果管理部540基于从通信部510通知来的更新结果数据(参照图20、图21)以及收到通知的日期时间，对由更新结果表保持部550保持的更新结果表进行更新。

更新结果表保持部550保持不正常检测ecu400a～400c的更新结果表。图23中示出更新结果表的一例。

[1.23更新结果表]

图23示出服务器500保持的更新结果表的一例。在该图所例示的更新结果表中，记载有车型a的车辆编号00000001的车辆中的与各种总线连接的各个不正常检测ecu的不正常检测规则的更新后的版本和最后更新日期时间并进行管理。作为最后更新日期时间，例如可以设定更新结果管理部540收到更新结果数据的通知的日期时间。此外，在该图所例示的更新结果表中，示出了关于车型a的车辆编号00000001的车辆的更新结果所涉及的数据，但通过服务器500向多个车辆的不正常检测ecu发送发布数据，更新结果表可以包含关于车型或车辆编号不同的多个车辆的不正常检测规则的更新结果所涉及的数据。

[1.24不正常帧的检测所涉及的时序]

以下，对在车载网络系统10的总线200a上连接有不正常ecu的情况下的与总线200a连接的不正常检测ecu400a、ecu100a、ecu100b、网关300a等的工作进行说明。

图24是表示不正常检测ecu400a检测不正常帧(消息)，并阻止由其他ecu进行与该不正常帧对应的处理的工作例的时序图。在该图中，示出了不正常ecu向总线200a发送消息id为“4”且数据域(数据)为“255(0xff)”的数据帧的情况下的例子。各时序表示各种装置中的各处理步骤(step)。

首先，不正常ecu开始消息id为“4”且数据为“255(0xff)”的数据帧的发送(步骤s1001)。构成帧的各比特的值按照上述的数据帧格式，按sof、id域(消息id)这样的顺序逐次被送出到总线200a上。

在不正常ecu向总线200a送完了到id域(消息id)为止的数据时，不正常检测ecu400a、ecu100a、ecu100b以及网关300a分别接收消息id(步骤s1002)。

ecu100a、ecu100b以及网关300a分别使用所保持的接收id列表来检查消息id(步骤s1003)。此时，不正常检测ecu400a使用所保持的作为不正常检测列表的消息id的列表(白名单)来检查消息id(步骤s1004)。即，不正常检测ecu400a以不正常检测规则作为基准，进行所发送的帧中的id域的内容是否符合规则的判定。在该判定中，在未记载在作为不正常检测规则的消息id的列表中的情况下，判定为不符合规则(即，是不正常的消息id，所发送的帧是不正常帧)。

在步骤s1003中，ecu100a以及ecu100b由于分别保持的接收id列表中不包含“4”(参照图4)，所以结束接收。也即是，不再进行不正常ecu继续发送的帧的解释，不再进行应对帧的处理。另外，在步骤s1003中，网关300a由于所保持的接收id列表中包含“4”(参照图6)，所以继续接收。另外，在步骤s1004中，不正常检测ecu400a由于所保持的作为不正常检测列的消息id的列表(参照图15)中不包含“4”，所以判断为是不正常的消息id，接着开始错误帧的发布准备(步骤s1005)。

接着步骤s1003，网关300a继续帧的接收。例如，在不正常检测ecu400a正在进行错误帧的发布准备的期间，从不正常ecu向总线200a上逐次送出id域之后的部分即rtr、控制域(ide、r、dlc)，接着逐比特地送出数据域。网关300a接收该rtr、控制域(ide、r、dlc)，接着开始数据域的接收(步骤s1006)。

接着，错误帧的发布准备结束，不正常检测ecu400a发送错误帧(步骤s1007)。该错误帧的发送在不正常帧的最末尾被发送之前(例如crc序列的最末尾被发送之前等)进行。在该工作例中，在数据域的中途进行。通过开始该错误帧的发送，在总线200a上，正在从不正常ecu发送的帧的数据域的中途部分会被错误帧(优先的显性的位串)覆写。

接收到在步骤s1007中发送的错误帧的网关300a，在数据域的接收中途中止不正常ecu发送出的帧的接收(步骤s1008)。也即，网关300a因为来自不正常ecu的数据域被错误帧覆写而检测到错误帧，所以不继续不正常ecu发送出的帧的接收。

[1.25不正常检测规则的更新所涉及的时序]

图25以及图26是表示不正常检测规则的更新(update)所涉及的工作例的时序图。服务器500可以对各车辆的各车载网络系统10中的各不正常检测ecu发送包含更新用不正常检测规则的发布数据，但在此着眼于不正常检测ecu400a保持的不正常检测规则的更新来进行说明。

首先，在服务器500中，取得最新的不正常检测规则(即，用于车载网络系统10的不正常检测ecu中的更新的不正常检测规则)以及附属信息(步骤s1101)。

服务器500对所取得的不正常检测规则以及附属信息生成用于附加的mac(步骤s1102)。

服务器500按照预定的发布数据格式，通过不正常检测规则、附属信息以及mac来构成发布数据，对发布数据进行加密(步骤s1103)。

接着，服务器500将加密后的发布数据发送给不正常检测ecu400a(步骤s1104a)。与此呼应，不正常检测ecu400a通过外部通信部490接收发布数据(更详细而言是加密后的发布数据)(步骤s1104b)。

不正常检测ecu400a的外部通信部490使加解密处理部491对加密后的发布数据进行解密(步骤s1105)。

接着，不正常检测ecu400a的外部通信部490使mac处理部492对发布数据所包含的mac进行验证(步骤s1106)。在该mac的验证成功了的情况下，不正常检测ecu400a的外部通信部490将接收到的发布数据的内容即不正常检测规则(更新用不正常检测规则)和附属信息(对象车型、总线类别、版本信息等)传送给更新判定部494。

在步骤s1106中的mac的验证成功了的情况下，不正常检测ecu400a的更新判定部494从总线类别保持部496取得连接有不正常检测ecu400a的总线200a所涉及的总线类别(步骤s1107)。另外，更新判定部494从车辆编号保持部495取得车型。

接着，不正常检测ecu400a的更新判定部494取得不正常检测规则保持部481保持的与不正常检测规则对应的版本信息(步骤s1108)。

接着，不正常检测ecu400a的更新判定部494根据发布数据来判定是否需要更新不正常检测规则(步骤s1109)。具体而言，更新判定部494通过对从总线类别保持部496取得的总线类别、从车辆编号保持部495取得的车型、以及从不正常检测规则保持部481取得的版本信息表示的版本与发布数据所包含的附属信息表示的总线类别、车型以及版本(即图19的对象车型、总线类别、不正常检测规则版本)分别进行比较，由此进行所述判别。更新判定部494只有在车型以及总线类别一致、且作为发布数据的内容的更新用不正常检测规则的版本为比不正常检测ecu400a已在使用的不正常检测规则的版本新的版本的情况下，才判别为需要进行更新。

在步骤s1109中判别为需要进行更新的情况下，不正常检测ecu400a的更新判定部494将不正常检测规则保持部481所保持的不正常检测规则更新为发布数据所包含的不正常检测规则(更新用不正常检测规则)(步骤s1110)。即，不正常检测ecu400a从自服务器500接收到的发布数据中提取与同所连接的总线的类别相符的总线类别信息(对象总线类别)对应的更新用不正常检测规则，将不正常检测规则保持部481保持的不正常检测规则更新为所提取出的更新用不正常检测规则。

在步骤s1110中进行了更新的情况下、在步骤s1106中mac的验证失败了的情况下、或者在步骤s1109中判别为不需要进行更新的情况下，更新判定部494从车辆编号保持部495取得车辆编号(步骤s1111)，将所取得的车辆编号和表示更新结果的更新结果数据传送给外部通信部490。更新结果数据(参照图21)例如在通过不正常检测规则版本进行了更新的情况下表示更新后的不正常检测规则的版本，在未进行更新的情况下表示无更新之意。

接着，在外部通信部490中，基于更新结果生成更新结果数据，基于该更新结果数据使mac处理部492生成mac，并将mac包含于更新结果数据(步骤s1112)。然后，外部通信部490将更新结果数据发送给服务器500(步骤s1113a)。

在服务器500中，接收更新结果数据(步骤s1113b)，进行更新结果数据中的mac的验证(步骤s1114)。

服务器500在mac的验证成功了的情况下，基于更新结果数据对更新结果表进行更新(参照图23)(步骤s1115)。在步骤s1114中mac的验证失败了的情况下，服务器500不进行更新结果表的更新。

[1.26实施方式1的效果]

在实施方式1涉及的车载网络系统10中，判别是否对成为在不正常检测ecu中判定在总线上发送的帧是否不正常的基准的不正常检测规则进行更新，因此能够根据需要来更新不正常检测规则。另外，根据连接有不正常检测ecu的总线的类别来判别是否进行更新，因此能够实现按总线的类别独立地进行不正常检测规则的更新。另外，发布成为更新用的不正常检测规则的服务器能够以同样的对待方式发布与各总线类别对应的最新版本的不正常检测规则，因此与单独选定更新内容来发送相比，能够降低处理负荷。另外，因为将更新结果数据通知给服务器，所以能够在服务器中管理更新结果并根据需要来进行再次发送发布数据等的控制。

[1.27实施方式1的变形例]

以下，对在上述的车载网络系统10中将不正常检测ecu400a～c替换为对该不正常检测ecu400a～c进行部分变形而得到的不正常检测ecu1400a～c的例子进行说明。

在对不正常检测ecu400a进行部分变形而得到的不正常检测ecu1400a中，在是否更新不正常检测规则的判别中，进一步参照关于搭载有不正常检测ecu1400a的车辆的车辆状态(例如行驶期间、停车期间等这样的行驶状态等)。由此，如果车辆状态例如不处于安全性高的预定状态(例如停车(日语：停車)期间或者驻车(日语：駐車)期间等)，则不正常检测ecu1400a不进行不正常检测规则的更新。

[1.28不正常检测ecu1400a的构成]

图27是不正常检测ecu1400a的构成图。不正常检测ecu1400a构成为包括帧收发部410、帧解释部420、帧生成部460、不正常检测处理部480、不正常检测规则保持部481、外部通信部490、加解密处理部491、mac处理部492、密钥保持部493、更新判定部1494、车辆编号保持部495、总线类别保持部496、车辆状态保持部1497和车辆状态判定部1498。这些各构成要素是功能性的构成要素，该各功能通过不正常检测ecu1400a中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。此外，替换不正常检测ecu400b的不正常检测ecu1400b以及替换不正常检测ecu400c的不正常检测ecu1400c也具备基本上同样的构成，但不正常检测规则保持部481的保持内容(不正常检测规则以及版本信息)可能会互不相同。对与实施方式1(图14)相同的构成要素标注相同的标号而省略说明。

更新判定部1494从外部通信部490接收更新用不正常检测规则和附属信息，基于从总线类别保持部496取得的总线类别、车辆编号保持部495保持的车型、不正常检测规则保持部481保持的与不正常检测规则对应的版本信息、以及车辆状态保持部1497保持的车辆状态，判别是否需要对不正常检测规则保持部481保持的不正常检测规则进行更新。更新判定部1494在判别为需要进行更新的情况下，向不正常检测规则保持部481进行通知，进行不正常检测规则的更新。另外，将更新结果和从车辆编号保持部495取得的车辆编号通知给外部通信部490。

车辆状态保持部1497从车辆状态判定部1498接收车辆状态并进行保持。作为车辆状态，除了与车辆的行驶关联的状态之外，还可以使用在车辆中能够通过测定等而确定的各种状态。在此，车辆状态作为“行驶期间”和“停车期间”的任一方来进行说明。

车辆状态判定部1498通过取得由车速传感器等传感器(未图示)测定出的测定值等来判定当前的车辆状态，将作为判定结果的车辆状态传送给车辆状态保持部1497。此外，车辆状态判定部1498既可以构成为包括车速传感器等传感器，也可以通过专用的通信线路与外部的车速传感器等传感器进行通信，还可以经由总线200a从与其外部的传感器连接的ecu接收测定值等。

[1.29不正常检测规则的更新所涉及的时序]

图28以及图29是表示不正常检测规则的更新(update)所涉及的工作例的时序图。服务器500可以对各车辆的各车载网络系统10中的各不正常检测ecu发送包含更新用不正常检测规则的发布数据，但在此着眼于不正常检测ecu1400a保持的不正常检测规则的更新来进行说明。另外，对与实施方式1中示出的步骤(参照图25、图26)相同的步骤，标注相同的标号，适当省略在此的说明。

服务器500将发布数据发送给不正常检测ecu1400a(步骤s1101～s1104a)，不正常检测ecu1400a中，从外部通信部490向更新判定部1494传送作为mac的验证成功了的发布数据的内容的不正常检测规则(更新用不正常检测规则)和附属信息(对象车型、总线类别、版本信息等)(步骤s1104b～s1106)。

接着，不正常检测ecu1400a的更新判定部1494从总线类别保持部496取得连接有不正常检测ecu1400a的总线200a所涉及的总线类别，从车辆编号保持部495取得车型，从不正常检测规则保持部481取得与不正常检测规则对应的版本信息(步骤s1107，s1108)。然后，更新判定部1494从车辆状态保持部1497取得车辆状态(步骤s1208)。

接着，不正常检测ecu1400a的更新判定部1494根据发布数据来判别是否需要更新不正常检测规则(步骤s1209)。具体而言，更新判定部1494通过对从总线类别保持部496取得的总线类别、从车辆编号保持部495取得的车型、以及从不正常检测规则保持部481取得的版本信息表示的版本与发布数据所包含的附属信息表示的总线类别、车型以及版本分别进行比较，并进一步确认从车辆状态保持部1497取得的车辆状态是否为预定状态(在此设为停车期间)，由此进行所述判别。更新判定部1494只有在车型以及总线类别一致、作为发布数据的内容的更新用不正常检测规则的版本为比不正常检测ecu1400a已在使用的不正常检测规则的版本新的版本、且车辆状态处于停车期间的情况下，才判别为需要进行更新。此外，也可以根据总线类别来使关于车辆状态的成为更新要件的预定状态不同，以使得：在连接于与行驶关联的驱动系统的总线的不正常检测ecu中，若处于停车期间则不进行不正常检测规则的更新，在连接于驱动系统以外的总线的不正常检测ecu中，能够在行驶期间进行不正常检测规则的更新。

在步骤s1209中判别为需要进行更新的情况下，不正常检测ecu1400a的更新判定部1494将不正常检测规则保持部481所保持的不正常检测规则更新为发布数据所包含的不正常检测规则(更新用不正常检测规则)(步骤s1110)。

[1.30实施方式1的变形例的效果]

在实施方式1的变形例1涉及的车载网络系统10中，根据连接有不正常检测ecu的总线的类别、搭载不正常检测ecu的车辆的车辆状态等，判定是否对不正常检测规则进行更新，该不正常检测规则为在不正常检测ecu中判定在总线上发送的帧是否不正常的基准。因此，能够仅在车辆状态处于例如安全性高的预定状态的情况下才进行不正常检测规则的更新等。

(实施方式2)

以下，对将实施方式1中示出的车载网络系统10进行部分变形而得到的车载网络系统20进行说明。

在实施方式1涉及的车载网络系统10中，不正常检测ecu400a～400c分别具有如下功能：通过与服务器500进行通信来取得更新用不正常检测规则等，对用于总线上的不正常帧的检查的不正常检测规则进行更新。与此相对，在本实施方式涉及的车载网络系统20中，头单元这一种ecu负责与外部的服务器500通信的通信功能，各不正常检测ecu经由头单元取得更新用不正常检测规则等，由此对不正常检测功能进行更新。

[2.1车载网络系统20的整体构成]

图30是表示车载网络系统20的整体构成的图。车载网络系统20是遵循can协议进行通信的网络通信系统的一例，是搭载有控制装置、传感器等各种设备的汽车中的网络通信系统。车载网络系统20构成为包括总线200a～200d、不正常检测ecu2400a～2400c、网关2300a、2300b、头单元800以及与各种设备连接的ecu100a～100e等ecu这种连接于总线的各节点。另外，在图30中，附注有与车载网络系统20中的头单元800进行无线通信的外部的网络600和以能够通信的方式与该网络600连接的服务器2500。对与实施方式1涉及的车载网络系统10(参照图1)相同的构成要素，标注相同的标号，省略在此的说明。另外，对于未在此特别说明之处，车载网络系统20与车载网络系统10是同样的。

网关2300a与连接不正常检测ecu2400a、ecu100a以及ecu100b的总线200a、连接不正常检测ecu2400b、ecu100c以及ecu100d的总线200b、连接头单元800的总线200d连接。网关2300b与连接不正常检测ecu2400b、ecu100c以及ecu100d的总线200b、连接不正常检测ecu2400c以及ecu100e的总线200c连接。网关2300a、2300b具有将从某总线接收到的帧传送给其他总线的功能。另外，另外，也能够按所连接的各总线间来切换是否传送所接收到的帧。网关2300a、2300b也是一种ecu。

不正常检测ecu2400a～2400c是对实施方式1中示出的不正常检测ecu400a～400c进行了部分变形而得到的，具有如下功能：在监视在连接有本ecu的总线上出现的帧而检测到不正常帧的情况下，发送错误帧(参照图24)。因此，不正常检测ecu2400a～2400c与不正常检测ecu400a～400c同样地，在不正常帧被发送到了总线上的情况下，阻止由其他ecu进行与该不正常帧对应的处理。

头单元800是车辆用通信装置，例如设置于汽车的仪表板等，是具备显示用于供驾驶员(用户)视觉辨认的信息的液晶显示器(lcd：liquidcrystaldisplay)等显示装置、受理驾驶员的操作的输入单元等的一种ecu。

服务器2500具有如下功能：为了对成为车载网络系统20中的不正常检测ecu2400a～2400c的不正常检测功能的基础的不正常检测规则进行更新，将发布数据经由网络600发送给头单元800。服务器2500与头单元800之间的通信方式可以使用任何方式。

[2.2头单元800的构成]

图31是头单元800的构成图。头单元800构成为包括帧收发部810、帧解释部820、接收id判断部830、接收id列表保持部840、帧处理部850、帧生成部860、显示控制部853、更新管理部854、更新结果表保持部855、外部通信部890、加解密处理部891、mac处理部892和密钥保持部893。这些各构成要素是功能性的构成要素，该各功能通过头单元800中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。

帧收发部810相对于总线200d收发遵循can的协议的帧。即，帧收发部810从总线200d逐比特地接收帧，并传送给帧解释部820。另外，将从帧生成部860收到了通知的帧的内容发送给总线200d。

帧解释部820从帧收发部810接收帧的值，并进行解释以使得向由can协议规定的帧格式的各域进行映射。判断为id域的值被传送给接收id判断部830。另外，帧解释部820根据从接收id判断部830通知的判定结果，决定是将id域的值和id域之后出现的数据域传送给帧处理部850、还是在收到该判定结果之后中止帧的接收(即中止作为该帧的解释)。另外，帧解释部820例如在判断为是未遵循can协议的帧的情况下，向帧生成部860进行通知，以使得发送错误帧。另外，帧解释部820在接收到错误帧的情况下，即在根据所接收到的帧的值而解释为成为错误帧的情况下，自此之后丢弃该帧，即中止帧的解释。

接收id判断部830接收从帧解释部820通知的id域的值，按照接收id列表保持部840保持的消息id的列表，进行是否接收该id域之后的帧的各域的判定。接收id判断部830将该判定结果通知给帧解释部820。

接收id列表保持部840保持头单元800接收的id(消息id)的列表即接收id列表。图32中示出头单元800中的接收id列表的一例。

帧处理部850将从各ecu发送而接收到的帧的数据(例如从与发动机相关的ecu100a得到的时速等)转换成能够显示的形式，并通知给显示控制部853。另外，帧处理部850将从不正常检测ecu2400a～2400c发送来的帧所包含的内部更新结果数据(后述)通知给更新管理部854。

显示控制部853对从帧处理部850通知来的数据进行显示。

帧生成部860按照来自帧解释部820的指示错误帧发送的通知，构成错误帧并通知给帧收发部810。另外，按照来自更新管理部854的指示，构成数据帧并通知给帧收发部810。

更新管理部854将从外部通信部890接收到的发布数据所包含的不正常检测规则(更新用不正常检测规则)以及附属信息(总线类别信息、版本信息等)转换成遵循can协议的形式，并交给帧生成部860，由此使帧生成部860生成数据帧。此外，对于发布数据所包含的附属信息中的对象车型的信息，例如更新管理部854将其与搭载有头单元800的车辆的车型进行比较，在不一致的情况下可以丢弃发布数据。在此，将头单元800经由车载网络系统20中的总线向不正常检测ecu2400a～2400c发布的数据帧称为内部发布数据。内部发布数据包含更新用不正常检测规则、总线类别以及版本信息(参照图33)。在此，作为内部发布数据，设为如下数据：对以使与“驱动系统”的总线类别的总线200a连接的不正常检测ecu2400a能够接收的方式发布的数据帧，附加“0x0e0”这一不正常检测规则更新用的消息id，对以使与“车体系统”的总线类别的总线200b连接的不正常检测ecu2400b能够接收的方式发布的数据帧，附加“0x0e1”这一不正常检测规则更新用的消息id，对以使与“安全系统”的总线类别的总线200c连接的不正常检测ecu2400c能够接收的方式发布的数据帧，附加“0x0e2”这一不正常检测规则更新用的消息id。此外，不正常检测ecu2400a～2400c分别接收对应的不正常检测规则更新用的消息id的数据帧，取得内部发布数据，由此判别是否更新不正常检测规则并根据需要进行更新。另外，更新管理部854基于从帧处理部850接收到的内部更新结果数据，对由更新结果表保持部855保持的内部更新结果表进行更新。

更新结果表保持部855将由来自不正常检测ecu2400a～2400c的内部更新结果数据(参照图34)构成的内部更新结果表保持于存储介质等。此外，也可以是通过更新管理部854基于内部更新结果表从发布数据所包含的各种总线用的各不正常检测规则中根据版本信息这一点选择需要更新的不正常检测规则，由此进行从头单元800发送与特定的不正常检测规则相关的内部发布数据，另外，也可以是同样地在更新失败时进行内部发布数据的再次发送。

外部通信部890通过经由网络600与服务器2500进行通信，取得包含用于更新不正常检测ecu2400a～2400c中的不正常检测规则的更新用不正常检测规则(新的不正常检测规则)等的发布数据。外部通信部890将所取得的发布数据发送给加解密处理部891，并取得解密后的结果。另外，将解密后的发布数据中的作为验证用数据的mac通知给mac处理部892，接收mac的验证结果。外部通信部890从解密后的发布数据中提取更新用不正常检测规则和附属信息(对象车型、总线类别信息、版本信息等)，并通知给更新管理部854。从服务器2500发布的发布数据被实施了加密处理。在此，服务器2500实施的加密处理例如是加密、验证用数据的附加等。与此相对，加解密处理部891以及mac处理部892对发布数据执行与在服务器2500等执行的加密处理呼应的处理(例如与加密呼应的解密、与验证用数据的附加呼应的验证)。

加解密处理部891使用从密钥保持部893取得的密钥，对从外部通信部890通知的加密后的发布数据进行解密，将解密后的发布数据通知给外部通信部890。

mac处理部892使用从密钥保持部893取得的密钥，对从外部通信部890通知的发布数据中的mac进行验证，将验证结果通知给外部通信部890。

密钥保持部893对加解密处理部891和mac处理部892在加密处理中利用的密钥进行管理。

[2.3头单元800中的接收id列表例]

图32是表示头单元800的接收id列表保持部840保持的接收id列表的一例的图。该图所例示的接收id列表用于选择性地接收除包含id(消息id)的值为“1”、“2”、“3”、“4”以及“5”之外还包含“0x0f0”、“0x0f1”以及“0x0f2”的某一个的消息id的帧并进行处理。在此，为了与连接于各条总线的不正常检测ecu2400a～2400c进行通信而区分了id。例如“0x0f0”这一消息id被用于接收包含来自与总线类别为“驱动系统”的总线200a连接的不正常检测ecu2400a的内部更新结果数据在内的数据帧。另外，“0x0f1”这一消息id被用于接收包含来自与总线类别为“车体系统”的总线200b连接的不正常检测ecu2400b的内部更新结果数据在内的数据帧。另外，“0x0f2”这一消息id被用于接收包含来自与总线类别为“安全系统”的总线200c连接的不正常检测ecu2400c的内部更新结果数据在内的数据帧。

[2.4头单元800发送的内部发布数据]

图33示出从头单元800以使不正常检测ecu2400a能够接收的方式发送的内部发布数据的一例。该图示出了如下例子：使数据帧的id(消息id)为“0x0e0”，在数据域内包含不正常检测规则(更新用不正常检测规则)和版本信息。在该例中，版本信息表示的版本是指“2.0”，不正常检测规则示出作为消息id记载有“1”、“2”、“3”以及“4”这4个的白名单，表示包含这4个id以外的id的帧会被判定为不正常帧。

[2.5头单元800接收的内部更新结果数据]

图34示出从不正常检测ecu2400a向头单元800通知的内部更新结果数据的一例。该图所例示的内部更新结果数据表示如下意思：作为与驱动系统的总线连接的不正常检测ecu接收到内部发布数据的结果，将不正常检测规则更新为版本2.0。

[2.6网关2300a、2300b的构成]

网关2300a在具有与实施方式1中示出的网关300a(参照图12)基本上同样的功能之外，还与总线200d连接，传送规则保持部352保持的传送规则的内容也不同。网关2300b具有与实施方式1中示出的网关300b基本上同样的功能，但传送规则保持部352保持的传送规则的内容不同。网关2300a、2300b中的传送规则被设定成从头单元800发送的内部发布数据被传递到应该接收的不正常检测ecu，另外，被设定成来自各不正常检测ecu的内部更新结果数据被传递到头单元800。

[2.7传送规则例]

图35示出网关2300a保持的传送规则的一例。该传送规则使传送源的总线、传送目的地的总线和传送对象的id(消息id)相关联。图35中的“*”表示不管消息id如何都进行帧的传送。图35的例子示出了：从总线200a接收的帧被设定为不管消息id如何都向总线200b以及总线200d进行传送。另外，示出了从总线200b接收的帧被设定为向总线200d传送全部帧，而向总线200a仅传送消息id为“3”的帧。另外，示出了：从总线200d接收的帧被设定为向“驱动系统”的总线200a传送消息id为“0xe0”的帧(内部发布数据)，向也成为经由网关2300b向“安全系统”的总线200c的传递路径的“车体系统”的总线200b传送消息id为“0xe1”以及“0xe2”的帧(内部发布数据)。

[2.8不正常检测ecu2400a的构成]

图36是不正常检测ecu2400a的构成图。不正常检测ecu2400a构成为包括帧收发部410、帧解释部2420、帧处理部2450、帧生成部2460、不正常检测处理部480、不正常检测规则保持部481、更新判定部2494和总线类别保持部496。这些各构成要素是功能性的构成要素，该各功能通过不正常检测ecu2400a中的通信线路、执行存储器所保存的控制程序的处理器或数字电路等来实现。此外，不正常检测ecu2400b以及不正常检测ecu2400c也具有基本上同样的构成，但不正常检测规则保持部481的保持内容(不正常检测规则以及版本信息)、帧生成部2460生成的作为内部更新结果数据的数据帧中包含的消息id、用于将帧解释部2420向帧处理部2450通知的内部发布数据与其他数据帧进行区分的消息id可能会互不相同。对不正常检测ecu2400a的构成要素中的与实施方式1中示出的不正常检测ecu400a相同的构成要素，标注相同的标号而省略说明。

帧解释部2420从帧收发部410接收帧的值，进行解释以使得向can协议中的各域进行映射。判断为id域的值被传送给不正常检测处理部480。另外，将关于内部发布数据的包含不正常检测规则更新用的消息id“0x0e0”的帧的数据内容，向帧处理部2450进行通知。另外，帧解释部2420在判断为是未遵循can协议的帧的情况下，向帧生成部2460进行通知，以使得发送错误帧。另外，帧解释部2420在接收到错误帧的情况下，对于正在接收的帧，自此之后丢弃该帧，即中止帧的解释。

帧生成部2460按照从帧解释部2420或者不正常检测处理部480通知的指示错误帧发送的通知，构成错误帧，将错误帧通知给帧收发部410并使其发送该错误帧。另外，帧生成部2460在被从更新判定部2494通知了不正常检测规则的更新结果的情况下，根据该更新结果来构成作为内部更新结果数据的消息id为“0xf0”的数据帧，将该数据帧通知给帧收发部410并使其发送该数据帧。

帧处理部2450从接收到的内部发布数据中提取不正常检测规则(更新用不正常检测规则)和附属信息(表示总线类别的总线类别信息以及版本信息)，并通知给更新判定部2494。

不正常检测规则保持部481保持有对被发送到总线200a上的帧所包含的消息id进行了规定的列表来作为不正常检测规则，并保持有表示关于该不正常检测规则的版本的版本信息(参照图37)。另外，不正常检测规则保持部481根据来自更新判定部2494的新的不正常检测规则(更新用不正常检测规则。)的通知，通过更新用不正常检测规则来更新先前保持的不正常检测规则，将更新后的结果通知给更新判定部2494。

更新判定部2494从帧处理部2450接收更新用不正常检测规则、表示总线类别的总线类别信息以及版本信息，基于从总线类别保持部496取得的总线类别、和不正常检测规则保持部481保持的与不正常检测规则对应的版本信息，判别是否需要更新不正常检测规则保持部481保持的不正常检测规则。更新判定部2494在判别为需要更新的情况下，向不正常检测规则保持部481进行通知，进行不正常检测规则的更新。另外，将更新结果通知给帧生成部2460。

[2.9不正常检测ecu2400a中的不正常检测规则例]

图37示出不正常检测ecu2400a保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则(列举了正规的消息id的列表)中，表示为：对于在连接不正常检测ecu2400a的总线200a上发送的帧(消息)，若消息id不符合“1”、“2”、“3”、“0x0e0”和“0x0f0”的任一方，则为不正常帧。另外，图37所示的版本信息表示该不正常检测规则的版本(ver.)为1.0。

[2.10不正常检测ecu2400中的不正常检测规则例]

图38示出不正常检测ecu2400b保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则中，表示为：对于在连接不正常检测ecu2400b的总线200b上发送的帧，若消息id不符合“1”、“2”、“3”、“4”、“0x0e1”、“0x0e2”、“0x0f1”和“0x0f2”的任一方，则为不正常帧。另外，版本信息表示该不正常检测规则的版本(ver.)为1.0。

[2.11不正常检测ecu2400c中的不正常检测规则例]

图39示出不正常检测ecu2400c保持的不正常检测规则以及版本信息的一例。在该图所示的不正常检测规则中，表示为：对于在连接不正常检测ecu2400c的总线200c上发送的帧，若消息id不符合“1”、“2”、“3”、“4”、“5”、“0x0e2”和“0x0f2”的任一方，则为不正常帧。另外，版本信息表示该不正常检测规则的版本(ver.)为1.0。

[2.12服务器2500的构成]

图40表示服务器2500的构成图。服务器2500是对实施方式1中示出的服务器500(参照图22)进行了部分变形而得到的，是位于搭载有车载网络系统20的车辆的外部的计算机。服务器2500构成为包括通信部2510、发布数据管理部520、不正常检测规则保持部530、加解密处理部591、mac处理部592和密钥保持部593。这些各构成要素是功能性的构成要素，该各功能通过服务器2500中的硬盘、存储器等存储介质、执行存储器所保存的控制程序的处理器、通信线路等来实现。此外，对服务器2500的构成要素中的与实施方式1中示出的服务器500同等的构成要素，标注相同的符号而省略说明。

通信部2510将从发布数据管理部520通知来的发布数据(参照图18、图19)经由网络600通知给头单元800。此外，服务器2500可以对一台以上的各车辆的各车载网络系统20中的头单元800发送包含更新用不正常检测规则的发布数据。

[2.13内部更新结果表]

图41示出头单元800保持的内部更新结果表的一例。在该图所例示的内部更新结果表中，按各个总线类别，记载有关于最后更新后的不正常检测规则的版本并对其进行管理。

[2.14不正常检测规则的更新所涉及的时序]

图42以及图43是表示不正常检测规则的更新(升级)所涉及的工作例的时序图。对于与实施方式1中的不正常检测规则的更新所涉及的时序(参照图25、图26参照)同样的步骤，标注相同的标号，适当省略说明。此外，实施方式1涉及的服务器500发送发布数据的地址为不正常检测ecu400a～400c，但服务器2500发送发布数据的地址为头单元800，在车载网络系统20中头单元800将基于发布数据的内部发布数据经由总线发送给不正常检测ecu2400a～2400c。在此，着眼于头单元800以及不正常检测ecu2400a来进行说明。

首先，服务器2500构成发布数据并进行加密(步骤s1101～s1103)，向头单元800进行发送(步骤s2104a)。与此呼应，头单元800通过外部通信部890接收发布数据(更详细而言是加密后的发布数据)(步骤s2104b)。

头单元800的外部通信部890使加解密处理部891对加密后的发布数据进行解密(步骤s2105)。

接着，头单元800的外部通信部890使mac处理部892对发布数据所包含的mac进行验证(步骤s2106)。在该mac的验证失败了的情况下结束处理，在该mac的验证成功了的情况下，头单元800的外部通信部890将所到接收的发布数据的内容即不正常检测规则(更新用不正常检测规则)和附属信息(对象车型、总线类别、版本信息等)传送给更新管理部854。

头单元800的更新管理部854将发布数据所包含的不正常检测规则(更新用不正常检测规则)以及附属信息(总线类别，版本信息等)转换成遵循can协议的形式的内部发布数据，由此，头单元800经由总线200d对内部发布数据进行发送(广播)(步骤s2107a)。包含更新用不正常检测规则、总线类别以及版本信息的内部发布数据经由网关2300a被与总线200a连接的不正常检测ecu2400a接收(步骤s2107b)。

接着，不正常检测ecu2400a的更新判定部2494从总线类别保持部496取得与不正常检测ecu2400a连接的总线200a所涉及的总线类别，从不正常检测规则保持部481取得与不正常检测规则对应的版本信息(步骤s1107、s1108)。

接着，不正常检测ecu2400a的更新判定部2494根据内部发布数据来判别是否需要更新不正常检测规则(步骤s1109)。具体而言，更新判定部2494通过对从总线类别保持部496取得的总线类别以及从不正常检测规则保持部481取得的版本信息与内部发布数据所包含的总线类别以及版本信息分别进行比较，由此来进行所述判别。更新判定部1494只有在总线类别一致、且作为内部发布数据的内容的更新用不正常检测规则的版本为比不正常检测ecu2400a已在使用的不正常检测规则的版本新的版本的情况下，判别为需要进行更新。

在步骤s1109中判别为需要进行更新的情况下，不正常检测ecu2400a的更新判定部2494将不正常检测规则保持部481所保持的不正常检测规则更新为内部发布数据所包含的不正常检测规则(更新用不正常检测规则)(步骤s1110)。

在步骤s1110中进行了更新的情况下、或者在步骤s1109中判别为不需要更新的情况下，通过更新判定部2494向帧生成部2460通知更新结果，不正常检测ecu2400a根据更新结果经由总线200a发送(广播)作为内部更新结果数据的消息id为“0xf0”的数据帧(步骤s2110a)。内部更新结果数据经由网关2300a被连接于总线200d的头单元800接收(步骤s2110b)。

接着，头单元800基于所接收到的内部更新结果数据来更新内部更新结果表(步骤s2115)。

[2.15实施方式2的效果]

在实施方式2涉及的车载网络系统20中，经由头单元取得不正常检测ecu中的不正常检测规则，根据连接不正常检测ecu的总线的类别来切换是否进行不正常检测规则的更新，因此，更新失败时的不正常检测规则的再送控制等相对容易。另外，与实施方式1的情况相比，能削减服务器中关于不正常检测规则的更新状态的应管理的数据。另外，在车载网络系统20中，因为仅一个头单元800进行与外部的通信以及加密处理，所以能削减各个不正常检测ecu的处理负荷，因此，能够以比较少的资源来构成不正常检测ecu。

(其他实施方式)

如上所述，作为本公开涉及的技术的例示，说明了实施方式1、2。然而，本公开涉及的技术不限定于此，在适当进行了变更、替换、附加、省略等的实施方式中也能够加以适用。例如，以下的变形例也包含在本公开的一个实施方式中。

(1)在上述实施方式中，示出了作为发送用于更新(update)不正常检测功能的发布数据的外部装置的服务器，但也可以从与车载网络中的被称为obd2(on-boarddiagnostics2，车载诊断)的诊断端口(外部工具连接用的接口)连接的外部装置即外部工具(所谓的诊断工具等)发送与该发布数据相当的信息。另外，也可以将外部工具连接于各个不正常检测ecu来从外部工具输入与发布数据相当的信息。另外，也可以使得与诊断端口连接的外部工具能够取得实施方式2中示出的头单元800中的内部更新结果表的内容。此外，头单元800也可以根据用户操作来显示内部更新结果表的内容。

(2)在上述实施方式中，示出了使用列举了正规id的白名单作为不正常检测规则来进行帧是否不正常的判定的例子，但也可以在帧的检查(是否不正常的判定)中使用其他的制定了判定基准的不正常检测规则。例如，也可以使用由不正规的id构成的黑名单来进行判定，还可以进行使用了dlc的判定、使用了发送消息的周期时间的判定、使用了一定时间内的发送频度的判定、或者使用了表示合理数据的数据域的判定。无论使用哪种检查(帧是否不正常判定)方法，对成为该判定基准的规则进行表示的事物就是不正常检测规则。不正常检测规则可以是作为成为判定出现在总线上的帧是否不正常(即是否符合规则)的基准的规则的信息、用于判定对该规则的符合性的程序(实现判定算法的程序等)、或者包含信息和程序的固件等。固件例如包括ecu内的程序等软件、由程序使用的数据，例如可以包含ecu内的处理器中的微代码、或者在ecu包含plc(programmablelogicdevice，可编程逻辑器件)或fpga(fieldprogrammablegatearray，现场可编程门阵列)的情况下可以包含该plc或fpga中的电路构成用的数据等。此外，例如，在不正常检测规则可以区分为作为成为判定基准的规则的信息和实现用于进行判定的算法的程序的情况下，也可以在发送发布规则时分别实施使用了单独密钥的加密处理(加密、mac的附加等)。另外，也可以使与加密处理呼应的处理(解密、mac的验证等)所使用的密钥按总线类别、各个不正常检测ecu而分开使用。

(3)在上述实施方式中，以标准id格式记述了can协议中的数据帧，但也可以是扩展id格式。在扩展id格式的情况下，用标准id格式中的id位置的基础id和扩展id共29位(bit)来表示数据帧的id(消息id)。此外，车载网络系统也可以不必是完全遵循can协议的系统。

(4)在上述实施方式中，从作为外部装置的服务器推送发布数据，但也可以是从头单元或不正常检测ecu询问是否存在用于更新不正常检测规则的发布数据。作为进行询问的定时，除了定期地询问之外，也可以设为车辆状态发生变化的定时(例如发动机启动时、点火钥匙被插入点火钥匙孔时)等。

(5)在上述实施方式中，在发布数据中将不正常检测规则和版本信息以组(set)的形式从服务器进行推送，但也可以是在只发送了版本信息之后根据需要来发送发布数据。另外，对于发送发布数据的定时，也可以在服务器中考虑车辆状态来进行发送。该情况下，服务器从不正常检测ecu或头单元取得车辆状态来进行判定。

(6)在上述实施方式2中，使从头单元向不正常检测ecu进行的内部发布数据的发布经由总线遵循can协议来进行，但也可以通过除此以外的方法来进行发布。例如，也可以使用连接头单元与不正常检测ecu的专用通信线路。

(7)上述实施方式1的变形例中示出的不正常检测ecu，在步骤s1209中由于车辆状态不处于预定状态而判定为不应该进行不正常检测规则的更新的情况下，也可以暂时保持所取得的发布数据所包含的更新用不正常检测规则，等到车辆状态变更为预定状态时再进行不正常检测规则保持部481所保持的不正常检测规则的更新(向更新用不正常检测规则的更新)。另外，也可以在等到车辆状态变更为预定状态之后向服务器(外部装置)请求发布数据的再送，重新接收发布数据并将不正常检测规则更新为重新接收到的该发布数据所包含的更新用不正常检测规则。

(8)关于上述实施方式中示出的对发布数据附加的mac，既可以是共用密钥，也可以是能够由公钥进行验证的署名。另外，在实施方式2中，仅服务器与头单元进行了加密处理(加密、mac生成、mac验证)，但也可以是在头单元与不正常检测ecu之间的通信中事先也进行密钥共用，对通信内容进行加密处理。此外，加密以及解密所使用的密钥和mac的生成以及验证所使用的密钥既可以是相同的密钥也可以是不同的密钥。

(9)在上述实施方式2中，不正常检测ecu经由与外部连接的头单元来接收不正常检测规则等，但头单元只不过是一个例子，也可以经由与外部连接的其他ecu来进行接收。与外部连接的ecu例如也可以是与基于多个协议的通信总线连接的中心网关、控制诊断端口的网关等。

(10)在上述实施方式中，作为连接不正常检测ecu的总线的种类例示了“驱动系统”、“车体系统”、“安全系统”，但也可以根据任何体系来区分总线的类别，其区分的个数可以是任何个数。

(11)在上述实施方式中，示出了根据车型、总线类别、版本信息、车辆状态等来判别是否需要更新不正常检测规则的例子，但作为成为该判别的条件的预定更新条件，也可以使用该例示的条件(车型、总线类别、版本信息、车辆状态等)的仅一部分，另外，也可以添加例示条件以外的条件。预定更新条件也可以只是与对应于不正常检测规则而确定的附属信息(车型、总线类别、版本信息等)有关的条件，也可以包含与独立于附属信息的车辆状态等有关的条件。另外，对于是否满足这样的预定更新条件的判别，既可以由不正常检测ecu和其他的ecu(头单元等)的任一方来进行，也可以分担来进行。只要构成为当满足预定更新条件时，不正常检测ecu将用于不正常帧的判定的不正常检测规则更新为新的不正常检测规则(更新用不正常检测规则)即可。例如，在预定更新条件仅为与附属信息有关的条件的情况下，不正常检测ecu在不正常检测ecu接收到的发布数据或者内部发布数据中的附属信息满足预定更新条件的情况下，进行不正常检测规则的更新，在附属信息不满足预定更新条件的情况下，不进行不正常检测规则的更新。另外，在包含作为附属信息的车型的情况下，在该附属信息的车型表示搭载车载网络系统的车辆的车型的情况下，可以认为在该车载网络系统中满足了预定更新条件的情况，进行不正常检测规则的更新。

(12)上述实施方式中的不正常检测ecu以及其他ecu，例如是包括处理器、存储器等的数字电路、模拟电路、通信线路等的装置，但也可以包括硬盘装置、显示器、键盘、鼠标等其他的硬件构成要素。另外，也可以取代由处理器执行存储器所存储的控制程序并以软件方式来实现功能，而是通过专用的硬件(数字电路等)来实现其功能。

(13)上述实施方式中的构成各装置的构成要素的一部分或者全部也可以由一个系统lsi(largescaleintegration：大规模集成电路)构成。系统lsi是将多个构成部集成于一个芯片上而制造出的超多功能lsi，具体而言，是包含微处理器、rom、ram等而构成的计算机系统。所述ram中存储有计算机程序。所述微处理器按照所述计算机程序进行工作，由此系统lsi实现其功能。另外，构成上述各装置的构成要素的各部既可以单独地单芯片化，也可以以包含一部分或全部的方式单芯片化。另外，虽然此处设为lsi，但根据集成度不同，也可以称为ic、lsi、超大lsi(superlsi)、特大lsi(ultralsi)。另外，集成电路化的方法不限于lsi，也可以通过专用电路或者通用处理器实现。也可以在lsi制造后利用fpga(fieldprogrammablegatearray；现场可编程门阵列)或者可以对lsi内部的电路单元的连接和/或设定进行重构的可重构处理器(reconfigurableprocessor)。进而，随着半导体技术的发展或者派生的其他技术的出现，如果出现能够替代lsi的集成电路化的技术，当然也可以利用该技术进行功能块的集成化。也存在适用生物技术的可能性。

(14)构成上述各装置的构成要素的一部分或者全部也可以由能够装卸于各装置的ic卡或者单体模块构成。所述ic卡或者所述模块是由微处理器、rom、ram等构成的计算机系统。所述ic卡或者所述模块也可以包含上述超多功能lsi。微处理器按照计算机程序进行工作，由此所述ic卡或者所述模块实现其功能。该ic卡或者该模块也可以具有抗篡改性。

(15)作为本公开的一个实施方式，例如也可以是图25、图26、图28、图29、图42、图43等所示的不正常检测规则更新方法。另外，也可以是通过计算机实现上述的方法的计算机程序，还可以是通过所述计算机程序形成的数字信号。另外，作为本公开的一个技术方案，也可以将所述计算机程序或者所述数字信号记录于计算机可读取的记录介质例如软盘、硬盘、cd-rom、mo、dvd、dvd-rom、dvd-ram、bd(blu-ray(注册商标)disc)、半导体存储器等。另外，也可以是记录在上述的记录介质中的所述数字信号。另外，作为本公开的一个技术方案，也可以将所述计算机程序或所述数字信号经由电通信线路、无线或有线通信线路、以因特网为代表的网络、数据广播等进行传送。另外，作为本公开的一个技术方案，也可以是具有微处理器和存储器的计算机系统，所述存储器记录有上述计算机程序，所述微处理器可以按照所述计算机程序进行工作。另外，也可以通过将所述程序或所述数字信号记录在所述记录介质中转移、或经由所述网络等将所述程序或所述数字信号进行转移，通过独立的其他的计算机系统来实施。

(16)通过将上述实施方式以及上述变形例中示出的各构成要素以及功能进行任意组合而实现的实施方式也包含在本公开的范围中。

产业上的可利用性

本公开的一个实施方式能够用于对在车载网络中成为检测向总线上发送的不正常帧的基准的规则进行更新。

标号的说明

10、20车载网络系统；100a～100e电子控制单元(ecu)；101发动机；102制动器；103门开闭传感器；104窗开闭传感器；105角部传感器；110、310、410、810帧收发部；120、320、420、820、2420帧解释部；130、330、830接收id判断部；140、340、840接收id列表保持部；150、850、2450帧处理部；160、360、460、860、2460帧生成部；170数据取得部；200a～200d总线；300a、300b、2300a、2300b网关；351传送处理部；352传送规则保持部；400a～400c、1400a、2400a～2400c不正常检测电子控制单元(不正常检测ecu)；480不正常检测处理部；481、530不正常检测规则保持部；490、890外部通信部；491、591、891加解密处理部；492、592、892mac处理部；493、593、893密钥保持部；494、1494、2494更新判定部；495车辆编号保持部；496总线类别保持部；500、2500服务器；510、2510通信部；520发布数据管理部；540更新结果管理部；550、855更新结果表保持部；600网络；800头单元；853显示控制部；854更新管理部；1497车辆状态保持部；1498车辆状态判定部。