WO2017119246A1 - 異常検知方法、異常検知装置及び異常検知システム - Google Patents

異常検知方法、異常検知装置及び異常検知システム Download PDF

Info

Publication number
WO2017119246A1
WO2017119246A1 PCT/JP2016/087134 JP2016087134W WO2017119246A1 WO 2017119246 A1 WO2017119246 A1 WO 2017119246A1 JP 2016087134 W JP2016087134 W JP 2016087134W WO 2017119246 A1 WO2017119246 A1 WO 2017119246A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
unit
abnormality detection
bus
feature information
Prior art date
Application number
PCT/JP2016/087134
Other languages
English (en)
French (fr)
Inventor
良浩 氏家
芳賀　智之
前田　学
松島　秀樹
剛 岸川
淳一 鶴見
久嗣 鹿島
雪乃 鳥海
拓也 桑原
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2016212574A external-priority patent/JP6839963B2/ja
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to EP20168399.2A priority Critical patent/EP3697031B1/en
Priority to CN202110213461.7A priority patent/CN113014464B/zh
Priority to EP16883746.6A priority patent/EP3402128B1/en
Priority to CN201680051251.XA priority patent/CN108028790B/zh
Publication of WO2017119246A1 publication Critical patent/WO2017119246A1/ja
Priority to US16/026,040 priority patent/US10986008B2/en
Priority to US17/201,839 priority patent/US11296965B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/82—Protecting input, output or interconnection devices
    • G06F21/85—Protecting input, output or interconnection devices interconnection devices, e.g. bus-connected or in-line devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle

Definitions

  • This disclosure relates to a technique for detecting an abnormality in a message transmitted in an in-vehicle network.
  • ECUs electronice control units
  • in-vehicle network A network connecting these ECUs.
  • ISO11898-1 A network connecting these ECUs.
  • CAN Controller Area Network
  • the communication path is a bus composed of two wires (CAN bus), and the ECU connected to the bus is called a node.
  • Each node connected to the CAN bus transmits and receives a frame (message).
  • the transmission node transmits an ID called a message ID for each frame (that is, broadcasts by sending a signal to the bus) and receives each reception.
  • the node receives only a predetermined message ID (ie reads a signal from the bus).
  • each of a large number of ECUs exchanges various frames.
  • the attack frame is a frame transmitted to the CAN bus by an unauthorized attacker, and is a frame (abnormal message) that is not originally transmitted in a normal state of the in-vehicle network.
  • Patent Document 1 a technique for determining whether or not a frame transmitted on the CAN bus is an abnormal frame using a statistical method.
  • Patent Documents 1 and 2 For the detection of attack frames (that is, detection of anomalies) in an in-vehicle network, the techniques of Patent Documents 1 and 2 are not necessarily sufficient, and research and development of further techniques for anomaly detection are desired.
  • the present disclosure provides an anomaly detection method useful for detecting an anomalous message (attack frame) that can be transmitted in an in-vehicle network of a vehicle such as an automobile.
  • an abnormality detection method in an in-vehicle network system including a plurality of electronic control units that exchange messages via a bus in a vehicle according to a CAN (Controller Area Network) protocol.
  • An anomaly detection method for anomaly detection wherein unit time is determined, feature information based on the number of messages received from the bus within the determined unit time, and a criterion relating to the appearance frequency of messages.
  • This is an abnormality detection method that performs an arithmetic process using a predetermined model representing, and determines whether there is an abnormality according to the result of the arithmetic process.
  • a recording medium such as an apparatus, a system, an integrated circuit, a computer program, or a computer-readable CD-ROM.
  • the apparatus, system, method, computer program, and You may implement
  • the number of messages per unit time determined by the in-vehicle network system may be different from the standard. obtain.
  • FIG. It is a figure which shows the whole structure of the abnormality detection system which concerns on Embodiment 1.
  • FIG. It is a figure which shows the format of the data frame prescribed
  • ECU electronice control unit
  • FIG. 2 is a configuration diagram of a gateway according to Embodiment 1.
  • FIG. It is a figure which shows an example of the vehicle identification information which the gateway which concerns on Embodiment 1 hold
  • 2 is a configuration diagram of a server according to Embodiment 1.
  • FIG. It is a figure which shows an example of the table for detection window size specification which the server which concerns on Embodiment 1 hold
  • FIG. 6 is a diagram showing an example of a frame transfer processing sequence in the gateway according to Embodiment 1.
  • FIG. It is a figure which shows an example of the detection window size determination processing sequence in the gateway and server which concern on Embodiment 1.
  • FIG. It is a figure which shows an example of the learning process sequence in the gateway and server which concern on Embodiment 1.
  • FIG. It is a figure for explanation of a detection window which a gateway concerning Embodiment 1 uses.
  • It is a figure which shows an example of the model update process sequence in the gateway and server which concern on Embodiment 1.
  • FIG. It is a figure which shows an example of the abnormality detection process sequence in the gateway and server which concern on Embodiment 1.
  • FIG. 6 is a configuration diagram of an in-vehicle network system for a vehicle according to Embodiment 2.
  • FIG. 6 is a configuration diagram of a gateway according to Embodiment 2.
  • FIG. It is a figure which shows an example of the detection window size determination processing sequence in the gateway which concerns on Embodiment 2.
  • FIG. 10 is a diagram illustrating an example of a learning process sequence in a gateway according to Embodiment 2. It is a figure which shows an example of the abnormality detection process sequence in the gateway which concerns on Embodiment 2.
  • FIG. It is a figure which shows an example of the detection window which concerns on the modification of embodiment.
  • the number of frames received from the bus in a unit time indicates the appearance frequency of the frame in the unit time in a normal state (model) If it is different from that, an abnormality can be detected. This is because the frequency of appearance of frames on the bus in a unit time in a normal state can be limited depending on the configuration, specifications, etc. of the in-vehicle network system (organization of ECUs connected via the bus, specifications, etc.). At this time, whether or not the unit time is appropriate affects the detection accuracy of the abnormality.
  • an abnormality detection method that can determine (select) a unit time such as 10 ms from various time widths and detect an abnormality using the determined unit time in a vehicle in-vehicle network system. Since the configuration, specifications, and the like of the in-vehicle network system may be different for each vehicle or each vehicle type, for example, in the in-vehicle network system of the vehicle, the unit is based on the vehicle identification information for identifying the vehicle, the vehicle type, etc. Time can be determined.
  • a method of detecting an abnormality after determining a unit time can be useful. For example, it is useful to determine a unit time to be used for detecting an abnormality based on the latest analysis result of information related to a frame accumulated from a plurality of vehicles of the same vehicle type.
  • An abnormality detection method includes an abnormality for detecting an abnormality in an in-vehicle network system including a plurality of electronic control units that exchange messages via a bus in a vehicle according to a CAN (Controller Area Network) protocol.
  • a detection method wherein unit time is determined, and feature information based on the number of messages received from the bus within the determined unit time and a predetermined model representing a criterion related to the appearance frequency of messages are used.
  • This is an abnormality detection method for performing a calculation process that determines whether there is an abnormality according to the result of the calculation process.
  • the number of messages in a unit time (for example, 10 ms) determined by the in-vehicle network system may be different from the standard. An anomaly can be detected.
  • the message includes a message ID indicating a message type
  • the abnormality detection method receives the determination from the bus within the unit time determined in the determination step and the determination step of determining the unit time.
  • a specifying step that specifies, as the feature information, a feature vector whose component is the number of messages for each message ID, and the arithmetic processing using the feature information specified in the specifying step and the predetermined model, It is good also as including the determination step which performs the said determination according to the result of the said arithmetic processing.
  • the unit time may be determined based on vehicle identification information for identifying the vehicle. Thereby, it is possible to detect an abnormality with high accuracy corresponding to the in-vehicle network system identified by the vehicle identification information.
  • the vehicle identification information may indicate a manufacturer of the vehicle. Therefore, since the unit time used for abnormality detection can be determined corresponding to the feature of the vehicle-mounted network for each vehicle manufacturer, it is possible to detect abnormality with high accuracy.
  • the vehicle identification information may indicate the vehicle type of the vehicle. Therefore, since the unit time used for abnormality detection can be determined corresponding to the feature of the vehicle-mounted network for each vehicle type, it is possible to detect abnormality with high accuracy.
  • the vehicle identification information may be information for distinguishing the vehicle from other vehicles. Thereby, it may be possible to detect an abnormality adapted to the characteristics of the in-vehicle network system for each individual vehicle.
  • the determination step among a plurality of different types of messages to be transmitted in a normal state to a bus in the vehicle in the vehicle-mounted network system of each vehicle in the set of vehicles identified by the vehicle identification information.
  • the determination may be performed so that the transmission period of one type of message having the shortest transmission period is set as a unit time. Thereby, it is possible to detect an abnormality with high accuracy.
  • the calculation process may be performed using the predetermined model corresponding to the vehicle identification information.
  • an abnormality is detected based on the predetermined model corresponding to the unit time determined in the in-vehicle network system and the number of messages received in the unit time in the in-vehicle network, so that an appropriate abnormality can be detected.
  • the feature information based on the number of messages received from the bus within the unit time is sequentially specified for each unit time determined in the determining step.
  • the determining step For each of the feature information sequentially specified in the specifying step, the calculation process is performed using the feature information and the predetermined model, and the abnormality detection method further includes a plurality of the specification information sequentially specified in the specifying step.
  • An update step of sequentially updating the predetermined model based on the feature information may be included.
  • the unit time is determined in the vehicle based on information defined when the vehicle is manufactured, and in the specifying step, the feature information is specified in the vehicle. It is also good.
  • the unit time used as the basis for generating characteristic information used for detecting an abnormality in the vehicle can be determined based on information (for example, chassis number) defined at the time of manufacture of the vehicle. Appropriate abnormality detection may be possible.
  • the unit time may be determined in the vehicle when the engine of the vehicle is started or an accessory is turned on.
  • the feature information may be specified in the vehicle. good.
  • the unit time is determined every predetermined time, and in the specifying step, the latest unit time determined in the determining step is received from the bus within the unit time.
  • the feature information based on the number of received messages is sequentially identified, and in the determination step, the calculation process is performed on the feature information sequentially identified in the identification step using the feature information and the predetermined model. It's also good.
  • an abnormality detection apparatus is connected to the bus in an in-vehicle network system including a plurality of electronic control units that exchange messages via a bus in the vehicle according to a CAN (Controller Area Network) protocol.
  • CAN Controller Area Network
  • An anomaly detection device that detects an anomaly, a receiving unit that receives a message from the bus, a determining unit that determines a unit time, and is received by the receiving unit within a unit time determined by the determining unit Depending on the result of the arithmetic processing using the specifying unit that specifies the feature information based on the number of messages and the predetermined model that represents the feature information specified by the specifying unit and the standard related to the appearance frequency of the message, It is an abnormality detection apparatus provided with the determination part which determines whether or not.
  • the arithmetic processing may be performed by, for example, an abnormality detection device or an external device (server), and determination may be performed by a determination unit of the abnormality detection device according to the result.
  • the abnormality detection device may transmit, for example, the feature information specified by the specifying unit to the server and receive the result of the arithmetic processing from the server.
  • the number of messages in a unit time for example, 10 ms
  • An abnormality detection system is an abnormality detection system including one vehicle and a server, and the one vehicle is a bus in the one vehicle according to a CAN (Controller Area Network) protocol.
  • a vehicle-mounted network system comprising a plurality of electronic control units that exchange messages via an abnormality detection device connected to the bus, the abnormality detection device receiving a message from the bus;
  • a determination unit configured to transmit vehicle identification information for identifying the one vehicle to the server and determine a unit time based on a response from the server; and the reception unit within the unit time determined by the determination unit
  • a specifying unit that specifies feature information based on the number of messages received by the device, and a base on the feature information and message appearance frequency specified by the specifying unit.
  • a determination unit that determines whether or not there is an abnormality in accordance with a result of an arithmetic processing using a predetermined model that represents a quasi, the server receives the vehicle identification information from the one vehicle, and the vehicle identification It is an abnormality detection system provided with the communication part which transmits the information which shows the unit time specified based on information to the said one vehicle.
  • the determination unit transmits the feature information specified by the specifying unit to the server, and determines whether or not there is an abnormality according to a response from the server (for example, information indicating whether or not there is an abnormality). Also good.
  • the server may perform arithmetic processing related to a predetermined model using the received feature information and transmit information based on the result to the vehicle as a response to the received feature information.
  • the unit time is determined corresponding to the vehicle identification information of the vehicle, it can be appropriately determined whether or not there is an abnormality related to the in-vehicle network of the vehicle.
  • the server further mounts one or more vehicles in a set of vehicles identified by the vehicle identification information within a unit time specified based on the vehicle identification information received from the one vehicle.
  • a learning unit that obtains predetermined information based on the number of messages received from the bus in the vehicle in the network system, and updates a reference model that represents a reference related to the appearance frequency of the message based on the predetermined information
  • the communication unit transmits information indicating the reference model updated by the learning unit to the one vehicle
  • the abnormality detection device determines the predetermined model based on the information indicating the reference model received from the server.
  • the determination unit performs an arithmetic process using the feature information and the updated predetermined model, and performs different processing according to the result of the arithmetic process.
  • the server uses predetermined information (for example, information similar to feature information) based on the number of messages received in the in-vehicle network in a set of vehicles (for example, vehicles of the same vehicle type) identified by the vehicle identification information.
  • the reference model is updated by learning.
  • the predetermined model can be updated based on the reference model, for example, so as to match, and can be used to determine whether there is an abnormality. Therefore, in the abnormality detection device, it is possible to perform appropriate abnormality detection (judgment) suitable for a vehicle (vehicle identified by vehicle identification information) on which the device is mounted.
  • the detection system will be described with reference to the drawings.
  • the abnormality detection apparatus determines the detection window size used for abnormality detection by notifying the server of vehicle identification information of the vehicle on which the apparatus is mounted and obtaining a response.
  • FIG. 1 is a diagram illustrating an overall configuration of an abnormality detection system 10 according to the first embodiment.
  • the anomaly detection system 10 includes a vehicle having an in-vehicle network system and a server 400 that can communicate with each other. Although the abnormality detection system 10 may include a plurality of vehicles that can communicate with the server 400, FIG. 1 shows only one vehicle for convenience.
  • This in-vehicle network system includes an ECU 100a (engine ECU), an ECU 100b (brake ECU), an ECU 100c (door opening / closing sensor ECU), an ECU 100d (window opening / closing sensor ECU), a bus 200a, 200b and a gateway 300 (an example of an abnormality detection device).
  • the in-vehicle network system may include a number of ECUs in addition to the gateway 300 and the ECUs 100a to 100d, but here, the description will be given focusing on the gateway 300 and the ECUs 100a to 100d for convenience.
  • the ECU is a device including, for example, a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like.
  • the memory is ROM, RAM, or the like, and can store a control program (computer program as software) executed by the processor.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the processor in order to achieve a predetermined function.
  • the ECU can exchange frames via the buses 200a and 200b in the vehicle according to the CAN protocol.
  • the ECUs 100a to 100d are connected to devices such as the engine 101, the brake 102, the door open / close sensor 103, and the window open / close sensor 104, respectively, acquire the state of the devices, and periodically display a frame (data frame) that represents the state. Are transmitted to an in-vehicle network including the bus 200a and the bus 200b.
  • the gateway 300 is connected to a bus 200a to which the ECU 100a and the ECU 100b are connected and a bus 200b to which the ECU 100c and the ECU 100d are connected, and has a function of transferring a frame received from one bus to the other bus. ECU. Further, the gateway 300 detects the abnormality by determining whether or not there is an abnormality based on the frame received from the bus (for example, determining whether or not the attack frame is in an abnormal state flowing through the bus), The abnormality detection apparatus has a function of notifying the server 400 of the detection result (abnormality detection result).
  • Anomaly detection in the gateway 300 as an anomaly detection device generally involves data frames received from the buses 200a and 200b associated with the in-vehicle network in each detection window, which is a period having a time length of the detection window size. This is done by determining whether or not there is an abnormality according to the result of arithmetic processing such as comparison using feature information based on the number of (messages) and a predetermined model that represents a standard related to the appearance frequency of messages. Further, the gateway 300 communicates with the server 400 via the network 40 to use information for detecting an abnormality (determining whether or not there is an abnormality) (for example, parameters such as a detection window size and information indicating a predetermined model). It has a function to determine.
  • the server 400 is a computer outside the vehicle, communicates with the gateway 300 in each vehicle via the network 40, and receives abnormality detection information (information indicating the detection window size, etc.) based on the received vehicle identification information. It has a function of responding (replying) to the gateway 300. Further, the server 400 has a function of storing the abnormality detection result notified from the gateway 300. In addition, the server 400 may have a function of communicating with the gateway 300 in each vehicle and accumulating, analyzing, and the like information related to frames received by the in-vehicle network in each vehicle. Note that any communication protocol of wireless communication or wired communication may be applied to the communication in the network 40.
  • SOF is composed of 1-bit dominant. When the bus is idle, it is recessive, and the start of frame transmission is notified by changing to dominant by SOF.
  • the ID field is a field for storing an ID (message ID) that is a value indicating the type of data, which is composed of 11 bits.
  • ID message ID
  • a frame having a small ID is designed to have a high priority in order to perform communication arbitration in this ID field.
  • RTR is a value for identifying a data frame and a remote frame, and is composed of a dominant 1 bit in the data frame.
  • IDE and “r” are both composed of dominant 1 bit.
  • DLC is composed of 4 bits and is a value indicating the length of the data field. IDE, “r”, and DLC are collectively referred to as a control field.
  • the data field is a value indicating the content of data to be transmitted composed of a maximum of 64 bits.
  • the length can be adjusted every 8 bits.
  • the specification of data to be sent is not defined by the CAN protocol, but is defined in the in-vehicle network system. Therefore, the specification depends on the vehicle type, manufacturer (manufacturer), and the like.
  • CRC sequence consists of 15 bits. It is calculated from the transmission values of the SOF, ID field, control field and data field.
  • ACK slot consists of 1 bit.
  • the transmitting node performs transmission with the ACK slot being recessive.
  • the receiving node transmits an ACK slot as a dominant if reception is successful up to the CRC sequence. Since dominant is given priority over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that any receiving node has received successfully.
  • ACK delimiter is a delimiter representing the end of ACK composed of 1-bit recessive.
  • EOF is composed of 7 bits recessive and indicates the end of the data frame.
  • FIG. 3 is a configuration diagram of the ECU 100a.
  • the ECU 100a includes a frame transmission / reception unit 110, a frame interpretation unit 120, a reception ID determination unit 130, a reception ID list holding unit 140, a frame processing unit 150, a data acquisition unit 160, and a frame generation unit 170. Composed. Each function of these components is realized by, for example, a communication circuit in the ECU 100a, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the ECUs 100b to 100d also have the same configuration as the ECU 100a.
  • the frame transmission / reception unit 110 transmits / receives a frame according to the CAN protocol to / from the bus 200a.
  • a frame is received bit by bit from the bus 200a and transferred to the frame interpreter 120. Further, the content of the frame notified from the frame generation unit is transmitted to the bus 200a.
  • the frame interpretation unit 120 receives a frame value from the frame transmission / reception unit 110, and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the value determined as the ID field is transferred to the reception ID determination unit 130.
  • the frame interpretation unit 120 transfers the value of the ID field and the data field appearing after the ID field to the frame processing unit 150 according to the determination result notified from the reception ID determination unit 130, or determines the determination result. After receiving the frame, it is determined whether to stop receiving the frame (that is, stop the interpretation as the frame). If the frame interpretation unit 120 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 120 notifies the frame generation unit 170 to transmit an error frame. In addition, when the frame interpretation unit 120 receives an error frame, that is, when it interprets that the value in the received frame is an error frame, the frame interpretation unit 120 discards the frame thereafter, that is, stops the interpretation of the frame. To do.
  • the reception ID determination unit 130 receives the value of the ID field notified from the frame interpretation unit 120, and receives each field of the frame after the ID field according to the list of message IDs held by the reception ID list holding unit 140. Judge whether to do. The reception ID determination unit 130 notifies the frame interpretation unit 120 of the determination result.
  • the reception ID list holding unit 140 holds a reception ID list that is a list of IDs (message IDs) received by the ECU 100a.
  • FIG. 4 shows an example of the reception ID list.
  • the frame processing unit 150 performs processing related to different functions for each ECU according to the received frame data.
  • the ECU 100a connected to the engine 101 has a function of sounding an alarm sound when the door is open with a speed exceeding 30 km / h.
  • the ECU 100a has, for example, a speaker for sounding an alarm sound.
  • the frame processing unit 150 of the ECU 100a manages data (for example, information indicating the state of the door) received from another ECU, and performs processing for sounding an alarm sound under a certain condition based on the speed obtained from the engine 101, etc. I do.
  • the frame processing unit 150 may perform processing relating to data of frames other than those exemplified here.
  • the data acquisition unit 160 acquires data indicating the state of devices, sensors, and the like connected to the ECU, and notifies the frame generation unit 170 of the data.
  • the frame generation unit 170 configures an error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 120, and notifies the frame transmission / reception unit 110 to transmit the error frame. Further, the frame generation unit 170 forms a frame (data frame) by adding a predetermined message ID to the data value notified from the data acquisition unit 160 and notifies the frame transmission / reception unit 110 of the frame.
  • the contents of the frame transmitted by each of ECUs 100a to 100d will be described later with reference to FIGS.
  • FIG. 4 is a diagram showing an example of the reception ID list held in each of the ECUs 100a to 100d.
  • the reception ID list illustrated in FIG. 11 selectively selects a frame (message) including a message ID whose ID (message ID) value is “1”, “2”, “3”, or “4”. Used to receive and process. For example, when the reception ID list shown in FIG. 4 is held in the reception ID list holding unit 140 of the ECU 100a, for frames whose message IDs are not “1”, “2”, “3”, and “4”, Interpretation of frames after the ID field in the frame interpretation unit 120 is stopped.
  • FIG. 5 is a diagram illustrating an example of an ID (message ID) and a data field (data) in a frame transmitted from the ECU 100 a connected to the engine 101.
  • the message ID of the frame transmitted by the ECU 100a is “1”.
  • the data represents a speed per hour (km / hour), takes a value ranging from a minimum of 0 (km / hour) to a maximum of 180 (km / hour), and the data length is 1 byte.
  • FIG. 5 illustrates the message ID and data corresponding to each frame sequentially transmitted from the ECU 100a from the upper row to the lower row, and shows a state where the vehicle is accelerated from 0 km / hour to 1 km / hour.
  • FIG. 6 is a diagram illustrating an example of an ID (message ID) and a data field (data) in a frame transmitted from the ECU 100 b connected to the brake 102.
  • the message ID of the frame transmitted by the ECU 100b is “2”.
  • the data represents the degree of brake application as a percentage (%), and the data length is 1 byte. This ratio is 0 (%) when no brake is applied and 100 (%) when the brake is applied to the maximum.
  • FIG. 6 illustrates the message ID and data corresponding to each frame sequentially transmitted from the ECU 100b from the upper row to the lower row, and shows a state where the brake is gradually weakened from 100%.
  • FIG. 7 is a diagram illustrating an example of an ID (message ID) and a data field (data) in a frame transmitted from the ECU 100 c connected to the door opening / closing sensor 103.
  • the message ID of the frame transmitted by the ECU 100c is “3”.
  • the data represents the open / closed state of the door, and the data length is 1 byte.
  • the data value is “1” when the door is open and “0” when the door is closed.
  • FIG. 7 illustrates, from the upper row to the lower row, each message ID and data corresponding to each frame sequentially transmitted from the ECU 100c, and shows a state in which the door has gradually moved from the open state to the closed state. ing.
  • FIG. 9 is a configuration diagram of the gateway 300.
  • the gateway 300 includes a frame transmission / reception unit 310, a frame interpretation unit 320, a reception ID determination unit 330, a reception ID list holding unit 340, a processing unit 350, an external communication unit 360, and a vehicle identification information holding unit 361.
  • Each function of these components is realized by, for example, a communication circuit in the gateway 300, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the frame transmission / reception unit 310 transmits / receives a frame according to the CAN protocol to each of the buses 200a, 200b.
  • the frame transmission / reception unit 310 functions as a reception unit that receives a frame from the bus bit by bit, and transfers the received frame to the frame interpretation unit 320. Further, based on the bus information and the frame indicating the transfer destination bus notified from the frame generation unit 390, the contents of the frame are transmitted to the buses 200a and 200b one bit at a time.
  • the frame interpretation unit 320 receives the frame value from the frame transmission / reception unit 310, and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the value determined as the ID field is transferred to the reception ID determination unit 330.
  • the frame interpretation unit 320 transfers the value of the ID field and the data field (data) appearing after the ID field to the transfer processing unit 380 according to the determination result notified from the reception ID determination unit 330, or After receiving the determination result, it is determined whether to stop receiving the frame.
  • the frame interpretation unit 320 notifies the processing unit 350 of the value of the ID field. If the frame interpretation unit 320 determines that the frame does not conform to the CAN protocol, the frame interpretation unit 320 notifies the frame generation unit 390 to transmit an error frame. If the frame interpreter 320 receives an error frame, that is, if it interprets that the value in the received frame is an error frame, the frame interpreter 320 discards the frame thereafter, that is, stops interpreting the frame. To do.
  • the reception ID determination unit 330 receives the value of the ID field notified from the frame interpretation unit 320, and receives each field of the frame after the ID field according to the list of message IDs held by the reception ID list holding unit 340. Judge whether to do. The reception ID determination unit 330 notifies the frame interpretation unit 320 of this determination result.
  • the reception ID list holding unit 340 holds a reception ID list (see FIG. 4) that is a list of IDs (message IDs) received by the gateway 300.
  • the processing unit 350 determines the detection window size based on the information indicating the detection window size notified from the server 400 and holds the detection window size. That is, the processing unit 350 functions as a determination unit that determines the detection window size. Based on the value of the ID field notified from the frame interpretation unit 320, the processing unit 350 sets a set of frames received sequentially from the buses 200a and 200b for each detection window having a detection window size time length. ID field value set) indicates the number of frames received by ID (message ID) in the detection window (the number obtained by counting the reception of frames by ID within the detection window of the detection window size). The feature information is converted to feature information and the feature information is notified to the external communication unit 360.
  • the processing unit 350 also functions as a specifying unit that specifies feature information. Further, the processing processing unit 350 sequentially notifies the abnormality detection processing unit 370 of the feature information based on the number of frames sequentially received from the buses 200a and 200b within the detection window of the detection window size.
  • the external communication unit 360 notifies (transmits) the vehicle identification information held by the vehicle identification information holding unit 361 to the server 400 via the network 40, and processes information indicating the detection window size notified from the server 400 as a response. Notify the processing unit 350.
  • the external communication unit 360 notifies (transmits) the feature information notified from the processing unit 350 to the server 400.
  • the external communication unit 360 notifies the abnormality detection processing unit 370 of the model information notified from the server 400 (information indicating the reference model indicating the reference related to the appearance frequency of the data frame). Further, the external communication unit 360 notifies (transmits) the abnormality detection result notified from the abnormality detection processing unit 370 to the server 400.
  • the vehicle identification information holding unit 361 holds vehicle identification information for vehicle identification.
  • FIG. 10 shows an example of the vehicle identification information.
  • the anomaly detection processing unit 370 acquires the model information notified from the server 400 via the external communication unit 360, and stores the predetermined model (a reference related to the appearance frequency of the data frame) held by the model holding unit 371 according to the model information. Update model). For example, the abnormality detection processing unit 370 can update the predetermined model so as to match the reference model indicated by the model information. Further, the abnormality detection processing unit 370 receives the feature information converted by the processing processing unit 350 based on the value of the ID field notified from the frame interpretation unit 320, and a predetermined model held by the model holding unit 371, It performs a calculation process using the feature information and functions as a determination unit that determines whether there is an abnormality according to the result of the calculation process.
  • the abnormality detection processing unit 370 determines whether or not the feature information related to the set of frames received from the bus conforms to the standard represented by the predetermined model by the arithmetic processing using the feature information and the predetermined model. .
  • a predetermined model for example, a standard indicating the appearance frequency of data frames in a normal state. It is determined to be normal if it is normal and does not conform to the standard (that is, deviates from the standard). In order to make such a determination, an arithmetic process is defined.
  • the arithmetic process is a combination of one or more of various processes such as a comparison between a predetermined model and feature information, an arithmetic operation, a logical operation, a condition determination, and the like.
  • the abnormality detection processing unit 370 notifies the external communication unit 360 of a determination result (that is, an abnormality detection result) as to whether there is an abnormality due to the arithmetic processing.
  • the model holding unit 371 holds a predetermined model notified from the abnormality detection processing unit 370.
  • the transfer processing unit 380 determines a bus (transfer destination bus) to be transferred according to the ID (message ID) of the received frame according to the transfer rule held by the transfer rule holding unit 381, and indicates the bus to be transferred.
  • the information and the message ID and data notified from the frame interpretation unit 320 are notified to the frame generation unit 390.
  • the transfer rule holding unit 381 holds a transfer rule that is information indicating a rule for frame transfer for each bus.
  • FIG. 11 shows an example of the transfer rule.
  • the frame generation unit 390 configures an error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 320, and notifies the frame transmission / reception unit 310 to transmit the error frame. In addition, the frame generation unit 390 configures a frame using the message ID and data notified from the transfer processing unit 380 and notifies the frame transmission / reception unit 310 of the frame and bus information.
  • FIG. 10 shows an example of vehicle identification information held by the gateway 300.
  • the vehicle identification information is information for identifying the vehicle
  • FIG. 10 shows an example in which the vehicle identification information indicates a car manufacturer (vehicle manufacturer), a vehicle type, and a chassis number.
  • the chassis number is information for distinguishing each vehicle from other vehicles (information for identifying each vehicle), and includes a model (vehicle type) and a manufacturing number.
  • the vehicles of the same vehicle type have the same configuration of the in-vehicle network, and the specifications regarding the use of data frames (messages) flowing through the CAN bus of the in-vehicle network (such as the definition of the contents of the data field for each message ID) are as follows.
  • vehicle identification information is not restricted to this example, For example, a vehicle identification number (VIN: Vehicle Identification Number) etc. may be sufficient.
  • vehicles having the same digit value from the beginning of the vehicle identification number to the front of the serial number are vehicles of the same vehicle type.
  • vehicle identification information is not necessarily information that enables individual vehicles to be identified by themselves.
  • the vehicle identification information may be information indicating only the vehicle type of the vehicle, information indicating only the vehicle manufacturer, information indicating only the chassis number, or these It may be information combining any one of the information and other information.
  • FIG. 11 shows an example of a transfer rule held by the transfer rule holding unit 381 of the gateway 300.
  • This transfer rule associates a transfer source bus, a transfer destination bus, and a transfer target ID (message ID).
  • “*” In FIG. 11 indicates that the frame is transferred regardless of the message ID.
  • the example of FIG. 11 indicates that the frame received from the bus 200a is set to be transferred to the bus 200b regardless of the message ID. Further, it is shown that only the frame having the message ID “3” among the frames received from the bus 200b is set to be transferred to the bus 200a.
  • the server 400 is a computer located outside the vehicle and capable of managing a plurality of vehicles, for example, and includes a storage medium such as a memory and a hard disk, a processor, a communication circuit, and the like.
  • FIG. 12 is a configuration diagram of the server 400.
  • the server 400 includes a communication unit 410, a data storage unit 420, a learning unit 430, a detection window size specifying unit 440, a detection window size specifying table holding unit 450, and an abnormality detection result holding as shown in FIG. Part 460.
  • Each of these components is realized by a communication circuit in the server 400, a processor that executes a control program stored in a memory, and the like.
  • the communication unit 410 communicates with the gateway 300 of each vehicle via the network 40. Further, the communication unit 410 accumulates in the data storage unit 420 the feature information reflecting the count number for each ID per detection window size sequentially notified from the gateway 300 for each vehicle. In addition, the communication unit 410 notifies (transmits) the model information indicating the reference model notified from the learning unit 430 to the gateway 300. Further, the communication unit 410 notifies the detection window size specifying unit 440 of the vehicle identification information notified from the gateway 300, and notifies the gateway 300 of information indicating the detection window size notified from the detection window size specifying unit 440 ( Send. Further, the communication unit 410 causes the abnormality detection result holding unit 460 to hold the abnormality detection result notified from the gateway 300.
  • the data storage unit 420 accumulates (holds) the feature information notified from the communication unit 410 for each vehicle.
  • the learning unit 430 is based on the feature information for each vehicle stored in the data storage unit 420, and is a reference model corresponding to each vehicle (a model representing a reference related to the appearance frequency of data frames appearing on a bus of an in-vehicle network of the vehicle). Is constructed and maintained, and the reference model is updated as necessary based on the feature information.
  • the learning unit 430 sequentially updates the held reference model, for example, by machine learning based on the feature information sequentially collected by the communication unit 410 and the data storage unit 420, for example.
  • the detection window size specifying unit 440 specifies the detection window size according to the vehicle identification information notified from the communication unit 410 with reference to the detection window size specifying table held by the detection window size specifying table holding unit 450.
  • the communication unit 410 is notified of information indicating the specified detection window size.
  • the detection window size specifying table holding unit 450 holds a detection window size specifying table used for specifying the detection window size according to the vehicle identification information.
  • An example of the detection window size specifying table is shown in FIG.
  • the abnormality detection result holding unit 460 holds the abnormality detection result notified from the communication unit 410 as a log for each vehicle.
  • the information from each vehicle may be classified and managed based on the vehicle identification information received from the vehicle. Even when the feature information or the abnormality detection result is transmitted to the server 400, all or part of the vehicle identification information may be added and transmitted.
  • FIG. 13 shows an example of a detection window size specifying table held by the server 400.
  • the detection window size specifying table shown in FIG. 13 is a table in which vehicle identification information and detection window sizes are associated with each other.
  • the vehicle identification information of the detection window size specifying table illustrated in FIG. 13 includes the car manufacturer, the vehicle type, and the chassis number, as in the example of FIG.
  • This detection window size is, for example, a plurality of types of data frames (that is, a plurality of different message IDs) to be transmitted to the CAN bus in a normal state in the in-vehicle network system of each vehicle in the set of vehicles identified by the vehicle identification information.
  • the transmission cycle may be determined to coincide with the transmission cycle of one type of the shortest data frame.
  • the specification of the in-vehicle network system or the analysis result of the actual state of the in-vehicle network system can be referred to. For example, if the vehicle identification information identifies only a vehicle type, not an individual vehicle, the shortest of the transmission periods of a plurality of ID frames transmitted in a normal state in an in-vehicle network system in each vehicle of that vehicle type The detection window size can be determined so as to coincide with that of the period. Another method may be used to determine the detection window size in the detection window size specifying table. As a result, the vehicle abnormality detection device (gateway 300) can appropriately distinguish between a normal state and an attacked state. Thus, it is useful to determine the detection window size.
  • FIG. 14 shows an example of a frame transmission processing sequence in the ECU 100a.
  • the frame transmission process by the ECU 100a will be described with reference to FIG.
  • ECU100a acquires data (for example, vehicle speed measured with a sensor in connection with engine 101) from a sensor by data acquisition part 160 (Step S1101).
  • the ECU 100a generates a frame (data frame) to be transmitted by the frame generation unit 170 based on the acquired sensor data (step S1102).
  • step S1103 the ECU 100a transmits (broadcasts) the generated frame to the bus 200a (step S1103).
  • the processing from step S1101 to S1103 can be repeated periodically with a substantially constant cycle.
  • the frame transmission process can be performed in the same procedure as the ECU 100a.
  • the transmission cycle may be different for each ECU.
  • the gateway 300 receives a frame transmitted (broadcast) to the bus 200a (step S1201).
  • the gateway 300 confirms the transfer rule (see FIG. 11) (step S1202).
  • the gateway 300 determines that the received frame is a frame to be transferred based on the transfer rule, the gateway 300 generates a transfer frame based on the content of the frame (step S1203).
  • the gateway 300 transmits (broadcasts) the transfer frame to the bus 200b, and ends the frame transfer process (step S1204). If it is determined that the received frame is not a frame to be transferred based on the transfer rule confirmed in step S1202, the gateway 300 ends the frame transfer process without transferring the frame.
  • FIG. 16 shows an example of a detection window size determination processing sequence in cooperation with the gateway 300 and the server 400.
  • the detection window size determination processing sequence will be described with reference to FIG.
  • the gateway 300 transmits the vehicle identification information acquired in step S1301 to the server 400 (step S1302a). Thereby, the server 400 receives vehicle identification information (step S1302b).
  • the gateway 300 transmits the vehicle identification information to the server 400, for example, when the gateway 300 is mounted on the vehicle (for example, when the vehicle is manufactured).
  • the timing the timing at which the gateway 300 transmits the vehicle identification information to the server 400
  • every time the vehicle is used such as when the vehicle starts running (for example, when the vehicle engine is started, the accessory-on ( ACC-ON), etc.) and every predetermined time (for example, one day).
  • the entire detection window size determination processing sequence shown in FIG. 16 can be executed in accordance with the arrival of the timing at which gateway 300 transmits vehicle identification information to server 400.
  • the gateway 300 determines the detection window size in the processing unit 350 according to the received detection window size information, and holds the detection window size (step S1305).
  • FIG. 17 shows an example of a learning process sequence based on cooperation between the gateway 300 and the server 400.
  • the learning processing sequence feature information obtained by performing processing on a set of frames received by the gateway 300 in the in-vehicle network of the vehicle is transmitted to the server 400, and the server 400 reflects the feature information on the reference model.
  • the learning process sequence will be described below with reference to FIG.
  • the gateway 300 identifies the ID in the detection window. (Message ID) The number of reception of another frame is counted (step S1402).
  • the processing unit 350 determines the elapse of time corresponding to the detection window size (that is, the arrival of the end of one detection window) (step S1403), and when the end of the detection window arrives, the number of received frames (count) by ID.
  • the feature information is generated by processing based on the number (step S1404).
  • the gateway 300 transmits the feature information generated by the processing unit 350 to the server 400 (step S1405a), the processing unit 350 clears the count (step S1406), and performs processing for the next detection window. Return (that is, return to the processing in step S1401). If it is determined in step S1403 that the end of the detection window has not arrived, the gateway 300 returns to the process in step S1401.
  • the reference model is determined for each vehicle identification information acquired from the vehicle, for example.
  • the reference model is determined for each vehicle, for example, but may be common for vehicles of the same vehicle type, for example. That is, there is a reference model corresponding to the destination vehicle to which the server 400 has transmitted information indicating the detection window size in accordance with the vehicle identification information from the vehicle, and the model information indicating the reference model is described later. It is transmitted to the vehicle in the model update processing sequence. Note that the reflection of the feature information on the reference model may be performed by, for example, updating the reference model by machine learning using the feature information.
  • the processing unit 350 of the gateway 300 identifies feature information based on the number of frames received from the bus in the detection window in each period (each detection window T1, T2, T3) of the detection window size.
  • FIG. 18 shows an example in which a feature vector whose component is the number of frames for each received message ID is specified as feature information.
  • a frame whose ID is 1 is expressed as ID1
  • a frame whose ID is 2 is expressed as ID2, and the like.
  • the feature vector is, for example, a vector having, as components, the number of ID1 receptions (count number), the number of ID2 receptions, the number of ID3 receptions, and the number of ID4 receptions within the detection window.
  • the number of vector components is, for example, the number of all message IDs that appear on the bus.
  • the feature vector in the detection window T3 is [1, 0, 1, 0,. ing.
  • the sharing of processing (processing, etc.) between the gateway 300 and the server 400 until the number of received frames for each ID counted in the detection window size period in the gateway 300 is reflected in the reference model of the server 400 is as follows. Anything can be used. Further, the number of dimensions (number of components) of feature vectors as feature information may be reduced by using principal component analysis or the like in the processing.
  • FIG. 19 shows an example of a model update processing sequence based on cooperation between the gateway 300 and the server 400.
  • the reference model updated in the server 400 is reflected in a predetermined model held by the gateway 300 of the vehicle.
  • the model update processing sequence will be described below with reference to FIG.
  • the model update processing sequence is executed at an arbitrary timing (for example, every day).
  • the server 400 determines whether or not the reference model has been updated (change in the content of the reference model) as a result of the above-described learning processing sequence (step S1501).
  • the server 400 transmits model information indicating the updated reference model to the gateway 300 (step S1502a).
  • the gateway 300 receives model information indicating the reference model (step S1502b).
  • the anomaly detection processing unit 370 updates the predetermined model held by the model holding unit 371 according to the model information (step S1503).
  • the predetermined model is the same as the reference model in the server 400, for example.
  • FIG. 20 shows an example of an abnormality detection processing sequence by cooperation of the gateway 300 and the server 400.
  • the abnormality detection processing sequence is executed, for example, when the vehicle is used.
  • the gateway 300 monitors the frames flowing through the buses 200a and 200b of the in-vehicle network of the vehicle, and includes a process of detecting an abnormality by determining whether or not an abnormal state has occurred using a predetermined model.
  • the predetermined model is configured to be the same as the reference model updated in the learning processing sequence described above by the model updating processing sequence described above.
  • the learning process sequence described above can be performed before the abnormality detection process sequence (for example, before use of the vehicle, that is, at the manufacturing or inspection stage), but in parallel with the abnormality detection process sequence when the vehicle is used. It may be done.
  • the abnormality detection processing sequence will be described with reference to FIG.
  • step S1601 when the frame is received (step S1601), the processing unit 350 counts the number of received frames for each ID within the detection window of the detection window size (step S1602). Is generated (step S1603).
  • the processing in steps S1601 to S1602 is repeatedly performed in one detection window, and feature information is generated in step S1603 at the end of the detection window, and the counter for counting the number of received frames for each ID is cleared. .
  • the gateway 300 receives the feature information generated by the processing unit 350 by the abnormality detection processing unit 370, and whether the feature information conforms to the standard indicated by the predetermined model held by the model holding unit 371. Then, it is determined whether or not the standard is deviated (step S1604).
  • the abnormality detection processing unit 370 performs arithmetic processing using the feature information and the predetermined model, and according to the result of the arithmetic processing, whether or not the characteristic information deviates from the standard represented by the predetermined model (that is, Or not).
  • a reference for example, a feature vector in a normal state
  • a predetermined model represented by a data structure such as a kd tree of a feature vector (see FIG. 18) as feature information received from the processing processing unit 350
  • a process of calculating the nearest neighbor distance to the threshold value and comparing it with a threshold value For example, assuming that the nearest neighbor distance follows a normal distribution, an abnormality is determined when the distance deviates from a range defined by a threshold value within a range of a certain standard deviation (for example, three times) of the standard deviation.
  • step S1604 determines that the feature information does not deviate from the standard indicated by the predetermined model (conforms to the standard).
  • step S1605 determines that the characteristic information is normal
  • step S1605 determines that the characteristic information is normal
  • step S1606 determines whether the feature information deviates from the standard indicated by the predetermined model.
  • step S1607a the abnormality detection result is transmitted to the server 400.
  • the server 400 When the server 400 receives the abnormality detection result (step S1607b), it stores the abnormality detection result as a log (step S1608).
  • the gateway 300 as the abnormality detection device mounted on the vehicle transmits vehicle identification information for identifying the vehicle to the server 400, and based on a response from the server 400.
  • the detection window size unit time for counting the number of received frames for abnormality detection.
  • the detection window size unit time for counting the number of received frames for abnormality detection.
  • a processing process for generating a feature vector related to a frame received on the gateway 300 side is performed. The amount of communication with the server 400 can be reduced.
  • the dimension of the feature vector can be reduced by principal component analysis, etc., so that it is possible to further reduce the amount of communication, and as a result, for abnormality determination based on the model It may be possible to reduce the amount of computation.
  • the server 400 accumulates data (feature information received from the vehicle) and constructs a model that reflects the feature information (update of the reference model, etc.), thereby limiting by the limited resources of the in-vehicle gateway 300.
  • the optimal model can be constructed without receiving it.
  • the gateway 300 acquires the reference model constructed (updated) by the server 400 and uses it for the determination (detection) of the abnormality, thereby quickly determining whether the vehicle is abnormal (that is, detecting the abnormality).
  • the server 400 can store the abnormality detection result as a log and manage the vehicle, and more appropriate based on the abnormality detection result. It may be possible to build a reference model or the like. Further, for example, in the case where the vehicle type is indicated by the vehicle identification information, the server 400 is attacked with the vehicle type by referring to the reference model corresponding to the vehicle type by collecting feature information from a plurality of vehicles of the same vehicle type. It is possible to properly construct the situation and the normal state so that they can be distinguished.
  • the server 400 transmits model information indicating the reference model to the gateway 300 of the vehicle of the same vehicle type, so that each vehicle of the same vehicle type is appropriately abnormal based on a predetermined model similar to the reference model. Can be detected. It should be noted that the detection of an abnormality may enable various measures against the abnormality (notification of warning, travel control for safety and other processes).
  • the gateway 300 of the vehicle determines the detection window size by communicating with the server 400 outside the vehicle, and learns the reference model that is the basis of the predetermined model used for detecting an abnormality in the in-vehicle network.
  • feature information based on the number of received frames by ID in the time corresponding to the detection window size is transmitted to the server 400.
  • an abnormality detection device in an in-vehicle network system of a vehicle independently determines a detection window size used for abnormality detection without depending on a server outside the vehicle. explain.
  • FIG. 21 shows the configuration of a vehicle-mounted network system according to the present embodiment.
  • symbol same as FIG. 1 is attached
  • the in-vehicle network system in the vehicle shown in FIG. 21 includes an ECU 100a, an ECU 100b, an ECU 100c and an ECU 100d, buses 200a and 200b, and a gateway 1300 (an example of an abnormality detection device).
  • Each ECU can exchange frames via the buses 200a and 200b in the vehicle according to the CAN protocol.
  • the gateway 1300 is connected to the bus 200a and the bus 200b, has a function of transferring a frame received from one bus to the other bus, and determines whether there is an abnormality based on the frame received from the bus (for example, It has a function of detecting an abnormality by determining whether or not the attack frame is in an abnormal state flowing through the bus.
  • the gateway 1300 is received by the in-vehicle network in a detection window that is a function of determining a detection window size for use in abnormality detection (determination of whether or not there is an abnormality), a time length of the detection window size. Based on the feature information related to the number of frames, it has a function of updating a predetermined model for use in abnormality detection.
  • Each function of these components is realized by, for example, a communication circuit in the gateway 1300, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • a communication circuit in the gateway 1300 a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • symbol is attached
  • the detection window size determination unit 1440 functions as a determination unit that determines the detection window size.
  • the detection window size determining unit 1440 uses the detection window size specifying table (see FIG. 13) held by the detection window size specifying table holding unit 450 according to the vehicle identification information held by the vehicle identification information holding unit 361.
  • the detection window size is determined and notified to the processing unit 1350.
  • the processing unit 1350 is a modification of part of the processing unit 350 shown in the first embodiment, holds the detection window size notified from the detection window size determination unit 1440, and notifies the frame interpretation unit 320 of the detection window size. For each detection window having a detection window size time length, a set of frames sequentially received from the buses 200a and 200b (a set of ID field values notified in sequence) Is converted into feature information indicating the number of frames received by ID (message ID) (count number obtained by counting frame reception by ID within the detection window of the detection window size) and periodically converting the feature information.
  • the learning unit 1430 is notified. That is, the processing unit 1350 functions as a specifying unit that specifies feature information. Further, the processing unit 1350 sequentially notifies the abnormality detection processing unit 1370 of the feature information based on the number of frames sequentially received from the buses 200a and 200b within the detection window of the detection window size.
  • the model holding unit 1371 holds a predetermined model (a model representing a standard related to the appearance frequency of data frames appearing on a bus of an in-vehicle network of a vehicle).
  • the learning unit 1430 builds a predetermined model based on the feature information notified from the processing unit 1350 and causes the model holding unit 1371 to hold it. That is, the learning unit 1430 updates the predetermined model held by the model holding unit 1371 based on the feature information.
  • the updating of the predetermined model by the learning unit 1430 can be performed by the same method as the updating of the reference model by the learning unit 430 described in the first embodiment.
  • the learning unit 1430 can sequentially update the predetermined model, for example, by machine learning based on the feature information notified sequentially.
  • the abnormality detection processing unit 1370 receives the feature information generated by the processing processing unit 1350 based on the value of the ID field notified from the frame interpretation unit 320, and the predetermined model held by the model holding unit 1371 and its features An arithmetic process using the information is performed, and whether or not there is an abnormality is determined according to the result of the arithmetic process. That is, the abnormality detection processing unit 1370 determines whether or not the feature information related to the set of frames received from the bus conforms to the standard represented by the predetermined model, by an arithmetic process using the feature information and the predetermined model. Functions as a determination unit.
  • the abnormality detection processing unit 370 stores the determination result (that is, the abnormality detection result) as to whether or not the abnormality is caused by the arithmetic processing in the abnormality detection result holding unit 1460 as a log.
  • FIG. 23 shows an example of a detection window size determination processing sequence in the gateway 1300.
  • the timing at which the detection window size determination processing sequence is executed is, for example, when the gateway 1300 is mounted on the vehicle (for example, at the time of manufacturing the vehicle), but may be other timings. There may be a plurality of timings. Examples of other timings include every time the vehicle is used (for example, when the vehicle engine is started, when accessories are turned on (ACC-ON), etc.), every predetermined time (for example, one day), and the like. Note that steps similar to those in FIG. 16 are denoted by the same reference numerals in FIG. 23, and description thereof will be omitted as appropriate.
  • the gateway 1300 acquires vehicle identification information (step S1301).
  • the gateway 1300 determines the detection window size using the detection window size specifying table (see FIG. 13) according to the vehicle identification information acquired in step S1301 (step S2303).
  • the gateway 1300 holds the determined detection window size and uses the detection window size when the processing unit 1350 executes the processing.
  • the gateway 1300 may have a communication function with the outside of the vehicle.
  • the detection window size specifying table may be acquired from the outside of the vehicle by communication, or may be detected from a recording medium or the like. It may be acquired by reading the window size specifying table.
  • FIG. 24 shows an example of a learning process sequence in the gateway 1300.
  • the gateway 1300 updates a predetermined model held by the model holding unit 1371 by learning based on feature information obtained by performing processing on a set of frames received from the buses 200a and 200b.
  • the learning process sequence will be described below with reference to FIG. Note that steps similar to those in FIG. 17 are denoted by the same reference numerals in FIG. 24, and description thereof will be omitted as appropriate.
  • the gateway 1300 When the gateway 1300 receives a frame from the bus 200a and the bus 200b for each detection window having a detection window size time length (step S1401), the gateway 1300 counts the number of received frames by ID in the detection window (step S1402).
  • the processing unit 1350 When the time corresponding to the detection window size has elapsed (the end of the detection window has arrived), the processing unit 1350 generates feature information by processing based on the number of received frames (count number) for each ID (step S1404).
  • the gateway 1300 reflects the feature information generated by the processing unit 1350 on the predetermined model held by the model holding unit 1371 by the learning unit 1430 (step S2407).
  • This learning processing sequence reflects the feature information related to the frame received in the normal state in the in-vehicle network in the predetermined model, so that the predetermined model becomes a reference for the appearance frequency of the frame appearing on the bus of the in-vehicle network. Is assumed.
  • the reflection of the feature information on the predetermined model may be performed, for example, by updating the predetermined model by machine learning using the feature information.
  • the processing unit 1350 may use a feature vector whose component is the number of frames for each message ID received in the detection window as the feature information.
  • the number of dimensions of the feature vector may be reduced by using principal component analysis or the like.
  • the learning unit 1430 may perform, for example, processing for efficiently detecting an abnormality using the predetermined model.
  • the learning unit 1430 reflects a set of feature vectors in a predetermined model by making a data structure suitable for calculating the nearest neighbor distance such as a kd tree.
  • the gateway 1300 clears the count (step S1406) and returns to the process in step S1401.
  • FIG. 25 shows an example of an abnormality detection processing sequence in the gateway 1300.
  • the abnormality detection processing sequence is executed, for example, when the vehicle is used.
  • the gateway 1300 detects the abnormality by monitoring the frames flowing through the buses 200a and 200b of the in-vehicle network of the vehicle and determining whether an abnormal state has occurred using a predetermined model.
  • the learning process sequence described above can be performed before the abnormality detection process sequence (for example, before use of the vehicle, that is, at the manufacturing or inspection stage), but in parallel with the abnormality detection process sequence when the vehicle is used. It may be done.
  • the abnormality detection processing sequence will be described with reference to FIG. Note that steps similar to those in FIG. 20 are denoted by the same reference numerals in FIG. 25, and description thereof will be omitted as appropriate.
  • the gateway 1300 receives the feature information generated by the processing processing unit 1350 by the abnormality detection processing unit 1370, and the feature information conforms to the standard indicated by the predetermined model held by the model holding unit 1371. Then, it is determined whether or not the standard is deviated (step S1604).
  • the gateway 1300 determines that the feature information is normal (step S1605). However, when it determines with having deviated from the reference
  • the gateway 1300 may update the predetermined model by machine learning (for example, supervised learning) using the determination result.
  • the abnormality detection device (gateway 1300) acquires vehicle identification information for identifying the vehicle on which the device itself is mounted without communicating with a server or the like, and uses the vehicle identification information as the vehicle identification information. Accordingly, the detection window size (unit time for counting the number of received frames for abnormality detection) can be determined. Thereby, the gateway 1300 may be able to accurately detect an abnormality in the in-vehicle network using a detection window size appropriate for the vehicle in which the gateway 1300 is mounted.
  • the gateway 1300 constructs a predetermined model (updates the predetermined model, etc.) reflecting the feature information generated based on the monitoring of the in-vehicle network, and performs an abnormality determination (detection) using the predetermined model. It may be possible to quickly determine whether there is an abnormality in (i.e., detect an abnormality). Further, the gateway 1300 can store a determination result as to whether or not there is an abnormality as a log, and can use the determination result.
  • Embodiments 1 and 2 have been described as examples of the technology according to the present disclosure.
  • the technology according to the present disclosure is not limited to this, and can also be applied to embodiments in which changes, replacements, additions, omissions, and the like are appropriately performed.
  • the following modifications are also included in one embodiment of the present disclosure.
  • the gateway (abnormality detection device) counts the number of frames received from the bus for each ID even in the detection window TA that partially overlaps the detection window T1, whereby the number of receptions for each ID.
  • a feature vector having (count number) as a component may be generated as feature information.
  • the gateway includes, in the feature information, information indicating an offset time that is a difference between the start time of the detection window TA and the reference start time (for example, the start time of the preceding detection window T1). It is good also as sending to.
  • the start time point of each detection window corresponding to the detection window size (for example, 10 ms) may be determined as every certain time (for example, 1 ms).
  • the timing at which a frame having a specific ID is received from the bus may be set as the detection window start time.
  • the gateways 300 and 1300 having a data frame (message) transfer function are shown as an example of an abnormality detection device that detects an abnormality.
  • the abnormality detection device includes one or more buses. As long as it is a device connected to the network, it is not always necessary to have a transfer function.
  • the abnormality detection device may be an ECU having a function other than the function of detecting an abnormality. Further, for example, the abnormality detection device may omit one or more components in the gateways 300 and 1300, and may move the one or more components to another ECU.
  • the extended ID format may be used, and the message ID is in the extended ID format.
  • the extended ID may be used.
  • the CAN protocol described in the above embodiment may have a broad meaning including derivative protocols such as TTCAN (Time-Triggered) CAN) and CANFD (CAN with Flexible Data Rate).
  • the gateway 300 includes the external communication unit 360. However, the gateway 300 passes through a head unit connected to the in-vehicle network or another ECU (device having a function of communicating with the outside of the vehicle). May communicate with each other.
  • the head unit is an ECU having a communication function with the outside of the vehicle, for example, for functions such as multimedia playback and car navigation.
  • OBD2 On-Board Diagnostics 2
  • the gateway 300 uses the diagnostic tool. It is good also as communicating with server 400 via.
  • the gateways 300 and 1300 determine that the feature information based on the number of received frames by ID during the detection window size period deviates from the standard indicated by the predetermined model. However, for example, by reversing the content indicated by the predetermined model, it may be determined that the case where it conforms to the predetermined model (when it does not deviate) is abnormal, and the case where it deviates is determined as normal.
  • the gateway 300 transmits the abnormality detection result to the server 400 and stores the abnormality detection result in the server 400. The abnormality detection result may be saved.
  • the gateways 300 and 1300 count the number of data frames received from the bus in the detection window, which is a period corresponding to the detection window size, based on the received number (count number).
  • An example of generating feature information is shown.
  • the feature information may be generated based on the total number of counts counted for each ID (the total number of data frames of all received IDs).
  • the number of received data frames may be counted regardless of the ID, and the reference model or the predetermined model has a similar configuration (that is, an ID so that it can be compared with the feature information. Is a structure showing the reference of the appearance frequency of frames without distinguishing between them.
  • the predetermined model can be compared with the feature information based on the number of frames received from the bus during the detection window size in the gateways 300 and 1300 (the reference to which the feature information should be adapted) An example is shown.
  • the predetermined model may be configured to represent a reference that can be compared with a frame received from the bus. In this case, steps S1602 and S1603 in FIGS. 20 and 25 are omitted, and in step S1604, it is determined whether or not the frame received from the bus meets (departs from) the standard indicated by the predetermined model. It is also good.
  • the gateway 300 generates the feature information by performing the processing, and transmits it to the server 400 (for example, steps S1404 and S1405a).
  • the server 400 may perform processing by transmitting the ID and reception time of the frame to the server 400.
  • the log related to the abnormality detection result shown in the above embodiment may be stored in a device other than the server 400 and the gateway 1300 (for example, a device dedicated to data storage in a vehicle, a head unit with abundant storage, etc.). good. Log information can be read out as necessary and used for vehicle management or model design, construction, etc. used for abnormality detection.
  • a part or all of the components constituting each device in the above embodiment may be configured by one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip.
  • the system LSI is a computer system including a microprocessor, a ROM, a RAM, and the like. .
  • a computer program is recorded in the RAM.
  • the system LSI achieves its functions by the microprocessor operating according to the computer program.
  • each part of the constituent elements constituting each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or the whole.
  • the system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. Biotechnology can be applied as a possibility.
  • a part or all of the constituent elements constituting each of the above devices may be constituted by an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system including a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the super multifunctional LSI described above.
  • the IC card or the module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.
  • an abnormality detection method including all or part of the processing procedures illustrated in FIGS. 14 to 17, 19, 19, 20, 23, and 25 may be used.
  • the abnormality detection method is an abnormality detection method for detecting an abnormality in an in-vehicle network system including a plurality of ECUs that exchange messages via a bus in a vehicle according to a CAN protocol. (Time for size) is determined, and calculation processing is performed using feature information based on the number of messages received from the bus within the determined unit time, and a predetermined model representing a standard related to the appearance frequency of messages. Whether or not there is an abnormality is determined according to the result of the arithmetic processing.
  • the unit time can be determined based on, for example, vehicle identification information, identification information of persons related to the vehicle, other information, and the like.
  • the message includes a message ID indicating the type of message
  • the abnormality detection method includes, for example, a determination step (for example, steps S1305 and S2303) for determining a unit time based on vehicle identification information for vehicle identification,
  • a feature vector whose component is the number of messages for each message ID received from the bus within the unit time determined in the determination step (for example, the latest unit time when determination is made a plurality of times) is specified as feature information.
  • a determination step for example, step S1404) and a determination step (for example, step S1404) for performing arithmetic processing using the feature information specified in the specific step and a predetermined model and determining whether or not there is an abnormality according to the result of the arithmetic processing S1604 etc.).
  • the abnormality detection method further includes an update step (for example, steps S1503, S2407, etc.) for sequentially updating the predetermined model based on the plurality of feature information sequentially specified in the specifying step.
  • a computer program that realizes the processing related to the abnormality detection method by a computer may be used, or a digital signal that includes the computer program may be used.
  • an aspect of the present disclosure may be a computer system including a microprocessor and a memory, the memory recording the computer program, and the microprocessor operating according to the computer program. Also, by recording and transferring the program or the digital signal on the recording medium, or by transferring the program or the digital signal via the network or the like, by another independent computer system It may be carried out.
  • This disclosure can be used to detect attacks on the in-vehicle network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

ＣＡＮプロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムでバスに送信され得る異常なメッセージの検知のために有用な異常検知方法を提供する。 異常検知方法では、例えばゲートウェイが車両識別情報をサーバに送信して応答を受信すること等により、検出窓サイズの決定を行い、決定された単位時間内にバスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する。

Description

異常検知方法、異常検知装置及び異常検知システム
　本開示は、車載ネットワークにおいて送信されるメッセージについての異常を検知する技術に関する。
　近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークは車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの一つに、ＩＳＯ１１８９８－１で規定されているＣＡＮ（Controller Area Network）という規格が存在する。
　ＣＡＮでは、通信路は２本のワイヤで構成されたバス（ＣＡＮバス）であり、バスに接続されているＥＣＵはノードと呼ばれる。ＣＡＮバスに接続されている各ノードは、フレーム（メッセージ）を送受信する。またＣＡＮでは、送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎に、メッセージＩＤと呼ばれるＩＤを付けて送信し（つまりバスに信号を送出することでブロードキャストし）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。自動車の中のシステムにおいては、多数のＥＣＵそれぞれは、様々なフレームの授受を行う。
　ＣＡＮバスに不正なノードを接続すること、或いは、携帯情報端末、車外の通信装置等と通信する機能を有するＥＣＵ等を攻撃して不正なノードに変化させること等により、攻撃者が、攻撃フレームをＣＡＮバスに送信して、自動車を不正にコントロールする可能性がある。攻撃フレームは、不正な攻撃者によってＣＡＮバスに送信されたフレームであり、車載ネットワークの正常状態において本来は送信されないフレーム（異常なメッセージ）である。
　このような攻撃フレームを検知するための技術として、ＣＡＮのバス上に送信されたフレームが異常なフレームか否かを統計的な手法を用いて判定する技術が知られている（特許文献１、特許文献２参照）。
特開２０１５－０２６２５２号公報 特開２０１５－１７０１２１号公報
　車載ネットワークでの攻撃フレームの検知（つまり異常の検知）のためには、特許文献１、２の技術で十分とは限らず、異常検知のための更なる技術の研究開発が望まれている。
　そこで、本開示は、自動車等の車両の車載ネットワークで送信され得る異常なメッセージ（攻撃フレーム）の検知のために有用な異常検知方法を提供する。
　上記課題を解決するために本開示の一態様に係る異常検知方法は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間の決定を行い、前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する異常検知方法である。
　なお、これらの全般的または具体的な態様は、装置、システム、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ－ＲＯＭなどの記録媒体で実現されてもよく、装置、システム、方法、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
　本開示によれば、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、車載ネットワークシステムで決定された単位時間におけるメッセージの数が基準と相違することとなり得るので、異常を検知し得る。
　なお、本開示の更なる効果及び利点は、本明細書及び図面の開示内容から明らかとなるであろう。上記更なる効果及び利点は、本明細書及び図面に開示されている様々な実施の形態及び特徴によって個別に提供されてもよく、必ずしもすべての効果及び利点が提供される必要はない。
実施の形態１に係る異常検知システムの全体構成を示す図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 電子制御ユニット（ＥＣＵ）の構成図である。 受信ＩＤリストの一例を示す図である。 エンジンＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ブレーキＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ドア開閉センサＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 ウィンドウ開閉センサＥＣＵが送信するフレームにおけるＩＤ及びデータフィールドの一例を示す図である。 実施の形態１に係るゲートウェイの構成図である。 実施の形態１に係るゲートウェイが保持する車両識別情報の一例を示す図である。 実施の形態１に係るゲートウェイが用いる転送ルールの一例を示す図である。 実施の形態１に係るサーバの構成図である。 実施の形態１に係るサーバが保持する検出窓サイズ特定用テーブルの一例を示す図である。 ＥＣＵにおけるフレーム送信処理シーケンスの一例を示す図である。 実施の形態１に係るゲートウェイにおけるフレーム転送処理シーケンスの一例を示す図である。 実施の形態１に係るゲートウェイ及びサーバにおける検出窓サイズ決定処理シーケンスの一例を示す図である。 実施の形態１に係るゲートウェイ及びサーバにおける学習処理シーケンスの一例を示す図である。 実施の形態１に係るゲートウェイが用いる検出窓の説明のための図である。 実施の形態１に係るゲートウェイ及びサーバにおけるモデル更新処理シーケンスの一例を示す図である。 実施の形態１に係るゲートウェイ及びサーバにおける異常検知処理シーケンスの一例を示す図である。 実施の形態２に係る車両の車載ネットワークシステムの構成図である。 実施の形態２に係るゲートウェイの構成図である。 実施の形態２に係るゲートウェイにおける検出窓サイズ決定処理シーケンスの一例を示す図である。 実施の形態２に係るゲートウェイにおける学習処理シーケンスの一例を示す図である。 実施の形態２に係るゲートウェイにおける異常検知処理シーケンスの一例を示す図である。 実施の形態の変形例に係る検出窓の一例を示す図である。
　（本開示の基礎となった知見等）
　攻撃者により攻撃フレーム（メッセージ）が車載ネットワークのバスに流された場合に、単位時間においてバスから受信されたフレームの数が、正常状態においてその単位時間におけるフレームの出現頻度を示す基準（モデル）と相違することとなれば、異常を検知し得る。車載ネットワークシステムの構成、仕様等（バスで接続されたＥＣＵの編成、仕様等）によって正常状態における単位時間におけるバスへのフレームの出現頻度は限定的となり得るためである。このとき単位時間が適切であるか否かは、異常の検知精度に影響を及ぼす。そこで、車両の車載ネットワークシステムで、多様な時間幅の中から例えば１０ｍｓ等と単位時間を決定（選定）し、決定した単位時間を用いて異常を検知し得る異常検知方法に想到した。車載ネットワークシステムの構成、仕様等は、例えば車両毎或いは車種毎等に異なり得るので、一例としては、車両の車載ネットワークシステムにおいて、その車両、車種等の識別のための車両識別情報に基づいて単位時間を決定し得る。また、攻撃手法の変化、多様化等により、攻撃された状態と正常状態とを区別するために適した単位時間が過去から不変とは限らないので、車両の車載ネットワークシステムにおいて異常の検知のために、単位時間を決定してから異常を検知する方法は有用となり得る。例えば、同一車種の複数車両から集積した、フレームに係る情報の最新の解析結果等に基づいて、異常の検知のために用いる単位時間を決定すること等が有用となる。
　本開示の一態様に係る異常検知方法は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間の決定を行い、前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する異常検知方法である。これにより、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、車載ネットワークシステムで決定された単位時間（例えば１０ｍｓ等）におけるメッセージの数が基準と相違することとなり得るので、適切に異常が検知され得る。
　また、例えば、前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、前記異常検知方法は、単位時間の前記決定を行う決定ステップと、前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含むこととしても良い。これにより、車載ネットワークシステムにおいてメッセージの種類別の受信数に基づきメッセージの出現状況を適切に表す特徴ベクトルが定められることとなり、適切な異常の検知が可能となり得る。
　また、例えば、前記決定ステップでは、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行うこととしても良い。これにより、車両識別情報で識別される車載ネットワークシステムに対応して精度良い異常の検知が可能となり得る。
　また、例えば、前記車両識別情報は、前記車両の製造事業者を示すこととしても良い。これにより、車両製造事業者毎の車載ネットワークの特徴に対応して、異常の検知に用いる単位時間を定め得るので、精度良い異常の検知が可能となり得る。
　また、例えば、前記車両識別情報は、前記車両の車種を示すこととしても良い。これにより、車種毎の車載ネットワークの特徴に対応して、異常の検知に用いる単位時間を定め得るので、精度良い異常の検知が可能となり得る。
　また、例えば、前記車両識別情報は、前記車両を他の車両と区別する情報であることとしても良い。これにより、個々の車両毎の車載ネットワークシステムの特徴に適応した異常の検知が可能となり得る。
　また、例えば、前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行うこととしても良い。これにより、精度良い異常の検知が可能となり得る。
　また、例えば、前記判定ステップでは、前記車両識別情報に対応した前記所定モデルを用いて前記演算処理を行うこととしても良い。これにより、車載ネットワークシステムにおいて決定した単位時間に対応した所定モデルと、車載ネットワークで単位時間において受信したメッセージの数とによって異常を検知することになるので、適切な異常の検知が可能となる。
　また、例えば、前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含むこととしても良い。これにより、異常の検知に用いる所定モデルを逐次更新するので、例えば、車載ネットワークの最近の状況（例えば車両の最近の使用状況等）に対応して、適切に異常の検知を行うことが可能となり得る。
　また、例えば、前記決定ステップでは、前記車両の製造の際に規定された情報に基づいて、前記車両において単位時間の前記決定を行い、前記特定ステップでは、前記車両において前記特徴情報を特定することとしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、車両の製造の際に規定された情報（例えば車台番号等）に基づいて決定し得るので、車両に適応した適切な異常の検知が可能となり得る。
　また、例えば、前記決定ステップでは、前記車両のエンジン始動又はアクセサリ－オンの際に、前記車両において単位時間の前記決定を行い、前記特定ステップでは、前記車両において前記特徴情報を特定することとしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、車両の使用開始の際（走行開始の際等）に決定し得るので、例えば最近の状況に適応して、適切な異常の検知が可能となり得る。
　また、例えば、前記決定ステップでは、所定時間毎に単位時間の前記決定を行い、前記特定ステップでは、前記決定ステップで決定された最新の単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行うこととしても良い。これにより、車両において異常の検知に用いる特徴情報の生成の基礎となる単位時間を、所定時間毎に決定するので、例えば最近の状況に適応して、適切な異常の検知が可能となり得る。
　また、例えば、前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、前記特徴情報は、前記決定された単位時間内に前記バスから受信された、全てのメッセージＩＤのメッセージの総数を示すこととしても良い。これにより、ＩＤを区別しないことで効率的に異常の検知を行うことが可能となり得る。
　また、本開示の一態様に係る異常検知装置は、ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、前記バスからメッセージを受信する受信部と、単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える異常検知装置である。演算処理は、例えば、異常検知装置で行っても、外部の装置（サーバ）で行っても良く、その結果に応じて、異常検知装置の判定部で判定を行えば良い。演算処理をサーバで行う場合においては、異常検知装置は、例えば、特定部で特定された特徴情報をサーバに送信し、演算処理の結果をサーバから受信することとしても良い。これにより、攻撃者により攻撃フレーム（メッセージ）がバスに流された場合に、異常検知装置で決定された単位時間（例えば１０ｍｓ等）におけるメッセージの数が基準と相違することとなり得るので、適切に異常が検知され得る。
　また、本開示の一態様に係る異常検知システムは、一の車両とサーバとを備える異常検知システムであって、前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、前記異常検知装置は、前記バスからメッセージを受信する受信部と、前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える異常検知システムである。例えば、判定部は、特定部で特定された特徴情報をサーバに送信し、サーバからの応答（例えば、異常か否かを示す情報等）に応じて異常か否かを判定するものであっても良い。この場合にはサーバは、例えば、受信した特徴情報を用いて、所定モデルに係る演算処理を行ってその結果に基づく情報を、受信した特徴情報に対する応答として車両に送信し得る。これにより、車両の車両識別情報に対応して単位時間が決定されるので、車両の車載ネットワークに係る異常か否かの判定が適切に行われ得る。
　また、例えば、前記サーバは、更に、前記一の車両から受信した前記車両識別情報に基づいて特定した単位時間内に、当該車両識別情報により識別される車両の集合における１つ以上の車両の車載ネットワークシステムで当該車両内のバスから受信されたメッセージの数に基づく所定情報を取得し、当該所定情報に基づいて、メッセージの出現頻度に係る基準を表す基準モデルを更新する学習部を備え、前記通信部は、前記学習部により更新した前記基準モデルを示す情報を前記一の車両に送信し、前記異常検知装置は、前記サーバから受信した前記基準モデルを示す情報に基づいて、前記所定モデルを更新し、前記判定部は、前記特徴情報と、前記更新された前記所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて、異常か否かの前記判定を行うこととしても良い。これにより、サーバでは、車両識別情報により識別される車両の集合（例えば同一車種の車両等）における車載ネットワークで受信されたメッセージの数に基づく所定情報（例えば特徴情報と同様の情報）を用いた学習により基準モデルを更新する。そして、車両の異常検知装置では、基準モデルに基づいて、例えば一致させるように、所定モデルを更新して異常か否かの判定に利用できる。従って、異常検知装置では、自装置を搭載する車両（車両識別情報で識別される車両）に適応した、適切な異常の検知（判定）の実行が可能となり得る。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
　以下、実施の形態に係る異常検知方法を用いる異常検知システム、異常検知装置等について、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　以下、本開示の実施の一態様として、車両において車載ネットワークの異常を検知する異常検知装置が、異常の検知に用いる検出窓サイズ（単位時間）を、車両外部のサーバとの連携により決定する異常検知システムについて、図面を用いて説明する。この異常検知システムにおいては、異常検知装置は、自装置を搭載している車両の車両識別情報をサーバに通知して応答を得ることで、異常の検知に用いる検出窓サイズを決定する。
　［１．１　異常検知システム１０の全体構成］
　図１は、実施の形態１に係る異常検知システム１０の全体構成を示す図である。
　異常検知システム１０は、車載ネットワークシステムを有する車両と、相互に通信可能なサーバ４００とを備える。異常検知システム１０は、サーバ４００と通信可能な複数台の車両を備えても良いが、図１では、便宜上、一台の車両について示している。
　図１に示す車両における車載ネットワークシステムは、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ、アクチュエータ、ユーザインタフェース装置等の各種機器が搭載された車両におけるネットワーク通信システムである。この車載ネットワークシステムは、車両に搭載され各種機器に接続されたＥＣＵ１００ａ（エンジンＥＣＵ）、ＥＣＵ１００ｂ（ブレーキＥＣＵ）、ＥＣＵ１００ｃ（ドア開閉センサＥＣＵ）、及び、ＥＣＵ１００ｄ（ウィンドウ開閉センサＥＣＵ）と、バス２００ａ、２００ｂと、ゲートウェイ３００（異常検知装置の一例）とを含んで構成される。なお、車載ネットワークシステムには、ゲートウェイ３００、ＥＣＵ１００ａ～１００ｄ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上ゲートウェイ３００及びＥＣＵ１００ａ～１００ｄに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（ソフトウェアとしてのコンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラム（コンピュータプログラム）に従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。ＥＣＵは、ＣＡＮプロトコルに従って車両内のバス２００ａ、２００ｂを介してフレームの授受を行い得る。
　ＥＣＵ１００ａ～１００ｄは、それぞれ、エンジン１０１、ブレーキ１０２、ドア開閉センサ１０３、ウィンドウ開閉センサ１０４といった機器に接続されており、その機器の状態を取得し、周期的に状態を表すフレーム（データフレーム）を、バス２００ａ、バス２００ｂ等で構成される車載ネットワークに送信している。
　ゲートウェイ３００は、ＥＣＵ１００ａとＥＣＵ１００ｂとが接続されたバス２００ａ、及び、ＥＣＵ１００ｃとＥＣＵ１００ｄとが接続されたバス２００ｂと接続され、一方のバスから受信したフレームを他方のバスに転送する機能を有する一種のＥＣＵである。また、ゲートウェイ３００は、バスから受信したフレームに基づいて異常か否かを判定すること（例えば攻撃フレームがバスに流れている異常状態であるか否かを判定すること）で異常を検知し、その検知結果（異常検知結果）をサーバ４００に通知する機能を有する異常検知装置である。異常検知装置としてのゲートウェイ３００における異常の検知は、概ね、検出窓サイズの時間長を有する期間である検出窓毎に、その検出窓内に車載ネットワークに係るバス２００ａ、２００ｂから受信されたデータフレーム（メッセージ）の数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた比較等の演算処理の結果に応じて異常か否かを判定することで、行われる。また、ゲートウェイ３００は、ネットワーク４０を介してサーバ４００と通信することで、異常検知（異常か否かの判定）に用いるための情報（例えば検出窓サイズ、所定モデルを表す情報等のパラメータ等）を決定する機能を有する。
　サーバ４００は、車両外部のコンピュータであり、ネットワーク４０を介して、各車両におけるゲートウェイ３００と通信し、受信した車両識別情報に基づいて、異常検知用の情報（検出窓サイズを示す情報等）をゲートウェイ３００に応答（返信）する機能を有する。また、サーバ４００は、ゲートウェイ３００より通知された異常検知結果を保存する機能を有する。また、サーバ４００は、各車両におけるゲートウェイ３００と通信し、各車両における車載ネットワークで受信されたフレームに係る情報を集積、解析等を行う機能を有しても良い。なお、ネットワーク４０における通信には、無線通信、或いは、有線通信のいかなる通信プロトコルを適用しても良い。
　［１．２　データフレームフォーマット］
　以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレーム（メッセージ）について説明する。
　図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。
　ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
　ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（メッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
　ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
　ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
　ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
　データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステムにおいて定められる。従って、車種、製造者（製造メーカ）等に依存した仕様となる。
　ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
　ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
　ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
　ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
　ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
　［１．３　ＥＣＵ１００ａの構成］
　図３は、ＥＣＵ１００ａの構成図である。ＥＣＵ１００ａは、フレーム送受信部１１０と、フレーム解釈部１２０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１５０と、データ取得部１６０と、フレーム生成部１７０とを含んで構成される。これらの各構成要素の各機能は、例えばＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ１００ｂ～１００ｄも、ＥＣＵ１００ａと同様の構成を備える。
　フレーム送受信部１１０は、バス２００ａに対して、ＣＡＮのプロトコルに従ったフレームを送受信する。バス２００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部１２０に転送する。また、フレーム生成部より通知を受けたフレームの内容をバス２００ａに送信する。
　フレーム解釈部１２０は、フレーム送受信部１１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部１３０へ転送する。フレーム解釈部１２０は、受信ＩＤ判断部１３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部１５０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、フレーム解釈部１２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部１７０へ通知する。また、フレーム解釈部１２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部１３０は、フレーム解釈部１２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１３０は、フレーム解釈部１２０へ通知する。
　受信ＩＤリスト保持部１４０は、ＥＣＵ１００ａが受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。図４に、受信ＩＤリストの一例を示す。
　フレーム処理部１５０は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン１０１に接続されたＥＣＵ１００ａは、時速が３０ｋｍを超えた状態でドアが開いている状態だと、アラーム音を鳴らす機能を備える。ＥＣＵ１００ａは、例えばアラーム音を鳴らすためのスピーカ等を有している。そして、ＥＣＵ１００ａのフレーム処理部１５０は、他のＥＣＵから受信したデータ（例えばドアの状態を示す情報）を管理し、エンジン１０１から取得された時速に基づいて一定条件下でアラーム音を鳴らす処理等を行う。なお、フレーム処理部１５０は、ここで例示した以外のフレームのデータに係る処理を行っても良い。
　データ取得部１６０は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１７０に通知する。
　フレーム生成部１７０は、フレーム解釈部１２０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１１０へ通知して送信させる。また、フレーム生成部１７０は、データ取得部１６０より通知されたデータの値に対して、予め定められたメッセージＩＤをつけてフレーム（データフレーム）を構成し、フレーム送受信部１１０へ通知する。なお、ＥＣＵ１００ａ～１００ｄのそれぞれが送信するフレームの内容については後に図５～図８を用いて説明する。
　［１．４　受信ＩＤリスト例］
　図４は、ＥＣＵ１００ａ～１００ｄのそれぞれにおいて保持される受信ＩＤリストの一例を示す図である。同図に例示する受信ＩＤリストは、ＩＤ（メッセージＩＤ）の値が「１」、「２」、「３」及び「４」のいずれかであるメッセージＩＤを含むフレーム（メッセージ）を選択的に受信して処理するために用いられる。例えば、ＥＣＵ１００ａの受信ＩＤリスト保持部１４０に図４の受信ＩＤリストが保持されていると、メッセージＩＤが「１」、「２」、「３」及び「４」のいずれでもないフレームについては、フレーム解釈部１２０でのＩＤフィールド以後のフレームの解釈が中止される。
　［１．５　エンジンＥＣＵ１００ａの送信フレーム例］
　図５は、エンジン１０１に接続されたＥＣＵ１００ａから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ａが送信するフレームのメッセージＩＤは「１」である。データは、時速（ｋｍ／時）を表し、最低０（ｋｍ／時）～最高１８０（ｋｍ／時）までの範囲の値を取り、データ長は１ｂｙｔｅである。図５の上行から下行へと、ＥＣＵ１００ａから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、０ｋｍ／時から１ｋｍ／時ずつ加速されている様子を表している。
　［１．６　ブレーキＥＣＵ１００ｂの送信フレーム例］
　図６は、ブレーキ１０２に接続されたＥＣＵ１００ｂから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｂが送信するフレームのメッセージＩＤは「２」である。データは、ブレーキのかかり具合を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、ブレーキを全くかけていない状態を０（％）、ブレーキを最大限かけている状態を１００（％）としたものである。図６の上行から下行へと、ＥＣＵ１００ｂから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、１００％から徐々にブレーキを弱めている様子を表している。
　［１．７　ドア開閉センサＥＣＵ１００ｃの送信フレーム例］
　図７は、ドア開閉センサ１０３に接続されたＥＣＵ１００ｃから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｃが送信するフレームのメッセージＩＤは「３」である。データは、ドアの開閉状態を表し、データ長は１ｂｙｔｅである。データの値は、ドアが開いている状態が「１」、ドアが閉まっている状態が「０」である。図７の上行から下行へと、ＥＣＵ１００ｃから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、ドアが開いている状態から次第に閉められた状態へと移った様子を表している。
　［１．８　ウィンドウ開閉センサＥＣＵ１００ｄの送信フレーム例］
　図８は、ウィンドウ開閉センサ１０４に接続されたＥＣＵ１００ｄから送信されるフレームにおけるＩＤ（メッセージＩＤ）及びデータフィールド（データ）の一例を示す図である。ＥＣＵ１００ｄが送信するフレームのメッセージＩＤは「４」である。データは、窓（ウィンドウ）の開閉状態を割合（％）で表し、データ長は１ｂｙｔｅである。この割合は、窓が完全に閉まっている状態を０（％）、窓が全開の状態を１００（％）としたものである。図８の上行から下行へと、ＥＣＵ１００ｄから逐次送信される各フレームに対応する各メッセージＩＤ及びデータを例示しており、窓が閉まっている状態から徐々に開いていく様子を表している。
　［１．９　ゲートウェイ３００の構成］
　図９は、ゲートウェイ３００の構成図である。ゲートウェイ３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、加工処理部３５０と、外部通信部３６０と、車両識別情報保持部３６１と、異常検知処理部３７０と、モデル保持部３７１と、転送処理部３８０と、転送ルール保持部３８１と、フレーム生成部３９０とを含んで構成される。これらの各構成要素の各機能は、例えばゲートウェイ３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　フレーム送受信部３１０は、バス２００ａ、２００ｂそれぞれに対して、ＣＡＮプロトコルに従ったフレームを送受信する。フレーム送受信部３１０は、バスからフレームを１ｂｉｔずつ受信する受信部として機能し、受信したフレームをフレーム解釈部３２０に転送する。また、フレーム生成部３９０より通知を受けた転送先のバスを示すバス情報及びフレームに基づいて、そのフレームの内容をバス２００ａ、２００ｂに１ｂｉｔずつ送信する。
　フレーム解釈部３２０は、フレーム送受信部３１０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部３３０へ転送する。フレーム解釈部３２０は、受信ＩＤ判断部３３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールド（データ）とを、転送処理部３８０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止するかを決定する。また、フレーム解釈部３２０は、ＩＤフィールドの値を、加工処理部３５０に通知する。また、フレーム解釈部３２０は、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するようにフレーム生成部３９０へ通知する。また、フレーム解釈部３２０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部３３０は、フレーム解釈部３２０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部３４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部３３０は、フレーム解釈部３２０へ通知する。
　受信ＩＤリスト保持部３４０は、ゲートウェイ３００が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリスト（図４参照）を保持する。
　加工処理部３５０は、サーバ４００から通知された検出窓サイズを示す情報に基づいて検出窓サイズを決定してその検出窓サイズを保持する。つまり加工処理部３５０は、検出窓サイズを決定する決定部として機能する。加工処理部３５０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて、検出窓サイズの時間長の検出窓毎に、バス２００ａ、２００ｂから逐次受信されたフレームの集合（逐次通知されたＩＤフィールドの値の集合）を、検出窓におけるＩＤ（メッセージＩＤ）別のフレームの受信数（検出窓サイズの検出窓内でフレームの受信をＩＤ別にカウントして得られたカウント数）を示す特徴情報に変換して特徴情報を外部通信部３６０へ通知する。つまり加工処理部３５０は、特徴情報を特定する特定部としても機能する。また、加工処理部３５０は、バス２００ａ、２００ｂから検出窓サイズの検出窓内に逐次受信されたフレームの数に基づくその特徴情報を異常検知処理部３７０へ逐次通知する。
　外部通信部３６０は、車両識別情報保持部３６１が保持する車両識別情報を、ネットワーク４０を介してサーバ４００へ通知（送信）し、応答としてサーバ４００から通知された検出窓サイズを示す情報を加工処理部３５０へ通知する。また、外部通信部３６０は、加工処理部３５０から通知された特徴情報をサーバ４００に通知（送信）する。また、外部通信部３６０は、サーバ４００から通知されたモデル情報（データフレームの出現頻度に係る基準を表す基準モデルを示す情報）を異常検知処理部３７０へと通知する。また、外部通信部３６０は、異常検知処理部３７０から通知された異常検知結果をサーバ４００へ通知（送信）する。
　車両識別情報保持部３６１は、車両の識別のための車両識別情報を保持する。図１０に、車両識別情報の一例を示す。
　異常検知処理部３７０は、サーバ４００から通知されたモデル情報を、外部通信部３６０を介して取得し、モデル情報に従ってモデル保持部３７１が保持している所定モデル（データフレームの出現頻度に係る基準を表すモデル）を更新する。例えば、異常検知処理部３７０は、モデル情報が示す基準モデルと一致させるように所定モデルを更新し得る。また、異常検知処理部３７０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて加工処理部３５０で変換された特徴情報を受け取り、モデル保持部３７１が保持している所定モデルと、その特徴情報とを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する判定部として機能する。即ち、異常検知処理部３７０は、バスから受信されたフレームの集合に係る特徴情報が、所定モデルが表す基準に適合しているか否かを、特徴情報及び所定モデルを用いた演算処理により判定する。この判定では、特徴情報に反映された検出窓サイズでのＩＤ別のデータフレームの受信数が、所定モデルが表す基準（例えば正常状態におけるデータフレームの出現頻度を示す基準）に適合していると正常であり、基準に適合していない（つまり基準を逸脱している）と異常であると判定される。このように判定するために演算処理は定められており、演算処理は、例えば所定モデルと特徴情報との比較、算術演算、論理演算、条件判断等といった各種処理の１つ以上の組み合わせである。異常検知処理部３７０は、その演算処理による異常か否かの判定結果（つまり異常検知結果）を、外部通信部３６０へ通知する。
　モデル保持部３７１は、異常検知処理部３７０から通知された所定モデルを保持する。
　転送処理部３８０は、転送ルール保持部３８１が保持する転送ルールに従って、受信したフレームのＩＤ（メッセージＩＤ）に応じて、転送するバス（転送先のバス）を決定し、転送するバスを示すバス情報とフレーム解釈部３２０より通知されたメッセージＩＤとデータとをフレーム生成部３９０へ通知する。
　転送ルール保持部３８１は、バス毎のフレームの転送についてのルールを表す情報である転送ルールを保持する。図１１に、転送ルールの一例を示す。
　フレーム生成部３９０は、フレーム解釈部３２０から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部３１０へ通知して送信させる。また、フレーム生成部３９０は、転送処理部３８０より通知されたメッセージＩＤとデータとを使ってフレームを構成し、そのフレーム及びバス情報をフレーム送受信部３１０へ通知する。
　［１．１０　車両識別情報］
　図１０は、ゲートウェイ３００が保持する車両識別情報の一例を示す。車両識別情報は、車両の識別のための情報であり、図１０では、車両識別情報が、カーメーカ（車両の製造事業者）、車種、及び、車台番号を示す例を示している。この例では、例えば、車台番号は、個々の車両を他の車両と区別する情報（各車両を識別する情報）であり、型式（車両形式）と製造番号とから構成される。ここで、車種が同一の車両同士は、車載ネットワークの構成が同一であり、車載ネットワークのＣＡＮバスに流れるデータフレーム（メッセージ）の利用に関する仕様（メッセージＩＤ毎のデータフィールドの内容の規定等）は同じである。即ち、ここでの車種が同一の車両は、例えば、車両型式が同一の車両である。なお、車両識別情報は、この例に限られず、例えば、車両識別番号（ＶＩＮ：Vehicle Identification Number）等であっても良い。例えば、車両識別番号における先頭からシリアル番号の前までの桁の値が同一の車両は、同一車種の車両である。なお、車両識別情報は、必ずしも、それだけで個々の車両が識別可能となる情報である必要はない。例えば、車両識別情報は、車両の車種のみを示す情報であっても良く、車両の製造事業者のみを示す情報であっても良く、車台番号のみを示す情報であっても良く、或いはこれらのいずれかと他の情報とを組み合わせた情報等であっても良い。
　［１．１１　転送ルール］
　図１１は、ゲートウェイ３００の転送ルール保持部３８１が保持する転送ルールの一例を示す。
　この転送ルールは、転送元のバスと転送先のバスと転送対象のＩＤ（メッセージＩＤ）とを対応付けている。図１１中の「＊」はメッセージＩＤにかかわらずフレームの転送がなされることを表している。図１１の例は、バス２００ａから受信されるフレームはメッセージＩＤにかかわらず、バス２００ｂに転送するように設定されていることを示している。また、バス２００ｂから受信されるフレームのうちメッセージＩＤが「３」であるフレームのみがバス２００ａに転送されるように設定されていることを示している。
　［１．１２　サーバ４００の構成］
　サーバ４００は、車両外部に所在し、例えば複数の車両を管理し得るコンピュータであり、メモリ、ハードディスク等の記憶媒体、プロセッサ、通信回路等を含む。
　図１２は、サーバ４００の構成図である。サーバ４００は、同図に示すように、通信部４１０と、データ蓄積部４２０と、学習部４３０と、検出窓サイズ特定部４４０と、検出窓サイズ特定用テーブル保持部４５０と、異常検知結果保持部４６０とを含んで構成される。これらの各構成要素は、サーバ４００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ等により実現される。
　通信部４１０は、ネットワーク４０を介して各車両のゲートウェイ３００と通信する。また、通信部４１０は、ゲートウェイ３００から逐次通知される、検出窓サイズ当たりのＩＤ別のカウント数を反映した特徴情報を、車両毎に区別して、データ蓄積部４２０に蓄積する。また、通信部４１０は、学習部４３０から通知された基準モデルを示すモデル情報を、ゲートウェイ３００へ通知（送信）する。また、通信部４１０は、ゲートウェイ３００から通知された車両識別情報を検出窓サイズ特定部４４０に通知して、検出窓サイズ特定部４４０から通知された検出窓サイズを示す情報をゲートウェイ３００に通知（送信）する。また、通信部４１０は、ゲートウェイ３００から通知された異常検知結果を異常検知結果保持部４６０に保持させる。
　データ蓄積部４２０は、通信部４１０から通知された特徴情報を車両毎に区別して蓄積（保持）する。
　学習部４３０は、データ蓄積部４２０に蓄積された車両毎の特徴情報に基づいて、車両毎に対応する基準モデル（車両の車載ネットワークのバスに現れるデータフレームの出現頻度に係る基準を表すモデル）を構築し保持し、特徴情報に基づいて必要に応じて基準モデルを更新する。学習部４３０は、例えば、通信部４１０及びデータ蓄積部４２０によって逐次収集される特徴情報に基づいて、例えば機械学習により、保持している基準モデルを逐次更新する。
　検出窓サイズ特定部４４０は、検出窓サイズ特定用テーブル保持部４５０が保持する検出窓サイズ特定用テーブルを参照して、通信部４１０から通知された車両識別情報に応じて検出窓サイズを特定し、特定した検出窓サイズを示す情報を通信部４１０へと通知する。
　検出窓サイズ特定用テーブル保持部４５０は、車両識別情報に応じて検出窓サイズを特定するために用いられる検出窓サイズ特定用テーブルを保持する。検出窓サイズ特定用テーブルの一例を図１３に示す。
　異常検知結果保持部４６０は、通信部４１０から通知された異常検知結果を、車両毎にログとして保持する。なお、サーバ４００が複数の車両を管理する場合においては、例えば、車両から受信した車両識別情報に基づいて各車両からの情報を類別して管理しても良く、例えば、車両のゲートウェイ３００は、特徴情報或いは異常検知結果をサーバ４００へ送信する際にも車両識別情報の全部或いは一部を付して送信することとしても良い。
　［１．１３　検出窓サイズ特定用テーブル］
　図１３は、サーバ４００で保持する検出窓サイズ特定用テーブルの一例を示す。図１３に示す検出窓サイズ特定用テーブルは、車両識別情報と検出窓サイズとを対応付けたテーブルである。図１３に例示する検出窓サイズ特定用テーブルの車両識別情報は、図１０の例と同様に、カーメーカ、車種、及び、車台番号を含む。この検出窓サイズは、例えば、車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムでＣＡＮバスに正常状態で送信されるべき、複数種類のデータフレーム（つまりメッセージＩＤが互いに異なる複数のデータフレーム）のうち、送信周期が最短の一種類のデータフレームのその送信周期と一致するように定められ得る。この検出窓サイズを定めるために、車載ネットワークシステムの仕様、或いは、車載ネットワークシステムの正常状態の実情の分析結果等が参照され得る。例えば、車両識別情報が、個々の車両ではなく車種のみを識別するものであれば、その車種の各車両における車載ネットワークシステムで、正常状態で送信される複数のＩＤのフレームの送信周期のうち最短の周期のものと一致するように、検出窓サイズが定められ得る。検出窓サイズ特定用テーブルにおける検出窓サイズの定め方は、この他の方法によっても良く、結果的に車両の異常検知装置（ゲートウェイ３００）において、正常状態と攻撃された状態とを適切に区別できるように、検出窓サイズを定めておくことが有用である。
　［１．１４　ＥＣＵ１００ａのフレーム送信処理］
　図１４は、ＥＣＵ１００ａにおけるフレーム送信処理シーケンスの一例を示す。以下、同図に即してＥＣＵ１００ａによるフレーム送信処理について説明する。
　ＥＣＵ１００ａは、データ取得部１６０により、センサからデータ（例えばエンジン１０１に関連してセンサで測定された車速）を取得する（ステップＳ１１０１）。
　次にＥＣＵ１００ａは、取得したセンサのデータに基づいて、フレーム生成部１７０により、送信すべきフレーム（データフレーム）を生成する（ステップＳ１１０２）。
　次にＥＣＵ１００ａは、生成したフレームをバス２００ａに対して送信（ブロードキャスト）する（ステップＳ１１０３）。このステップＳ１１０１からＳ１１０３までの処理は、概ね一定の周期で、周期的に繰り返され得る。
　ＥＣＵ１００ｂ～１００ｄにおいても、ＥＣＵ１００ａと同様な手順でフレーム送信処理が行われ得る。但し、送信の周期は、ＥＣＵ毎に異なり得る。
　［１．１５　ゲートウェイ３００のフレーム転送処理］
　図１５は、ゲートウェイ３００におけるフレーム転送処理シーケンスの一例を示す。以下、同図に即してゲートウェイ３００によるフレーム転送処理について説明する。ゲートウェイ３００は、バス２００ａ及びバス２００ｂのいずれかからフレーム（データフレーム）を受信する度にこのフレーム転送処理を行う。ここでは、ゲートウェイ３００が、バス２００ａから受信したフレームをバス２００ｂに転送する例を用いて説明する。
　ゲートウェイ３００は、バス２００ａに送信（ブロードキャスト）されたフレームを受信する（ステップＳ１２０１）。
　次に、ゲートウェイ３００は、転送ルール（図１１参照）を確認する（ステップＳ１２０２）。
　ゲートウェイ３００は、転送ルールに基づいて、受信したフレームが転送されるべきフレームであると判定した場合には、そのフレームの内容に基づいて転送用フレームを生成する（ステップＳ１２０３）。
　次に、ゲートウェイ３００は、転送用フレームをバス２００ｂに送信（ブロードキャスト）して、フレーム転送処理を終える（ステップＳ１２０４）。なお、ステップＳ１２０２で確認した転送ルールに基づいて、受信したフレームが転送されるべきフレームでないと判定した場合には、ゲートウェイ３００は、フレームの転送を行わずにフレーム転送処理を終える。
　［１．１６　検出窓サイズ決定処理シーケンス］
　図１６は、ゲートウェイ３００及びサーバ４００の連携による検出窓サイズ決定処理シーケンスの一例を示す。以下、同図に即して検出窓サイズ決定処理シーケンスについて説明する。
　ゲートウェイ３００は、車両識別情報を取得する（ステップＳ１３０１）。ゲートウェイ３００は、車両識別情報を車両識別情報保持部３６１から取得する。車両識別情報保持部３６１には、例えば、ゲートウェイ３００が車両に搭載された際（例えば車両の製造の際等）において車両識別情報が保持されていても良いし、予め記録された車両識別情報を保持する車両内のＥＣＵからゲートウェイ３００がその車両識別情報を受信することで、車両識別情報保持部３６１に保持させることとしても良い。
　ゲートウェイ３００は、ステップＳ１３０１で取得した車両識別情報を、サーバ４００に送信する（ステップＳ１３０２ａ）。これにより、サーバ４００は、車両識別情報を受信する（ステップＳ１３０２ｂ）。なお、ゲートウェイ３００が、サーバ４００に車両識別情報を送信するタイミングは、例えば、ゲートウェイ３００が車両に搭載された際（例えば車両の製造の際等）であるが、この他のタイミングであっても良いし、そのタイミングは複数であっても良い。この他のタイミング（ゲートウェイ３００がサーバ４００に車両識別情報を送信するタイミング）の例としては、車両の走行開始時等といった車両を使用する際毎（例えば車両のエンジン始動の際、アクセサリ－オン（ＡＣＣ－ＯＮ）の際等）、所定時間（例えば１日）毎等が挙げられる。そして、ゲートウェイ３００が、サーバ４００に車両識別情報を送信するタイミングの到来に合わせて図１６に示す検出窓サイズ決定処理シーケンスの全体が実行され得る。
　サーバ４００では、ステップＳ１３０２ｂで受信した車両識別情報に応じて、検出窓サイズ特定部４４０により検出窓サイズを特定し（ステップＳ１３０３）、特定した検出窓サイズを示す情報（検出窓サイズ情報）を、車両識別情報に対する応答として、ゲートウェイ３００に送信する（ステップＳ１３０４ａ）。これにより、ゲートウェイ３００は、検出窓サイズ情報を受信する（ステップＳ１３０４ｂ）。
　ゲートウェイ３００は、受信した検出窓サイズ情報に従って、加工処理部３５０において検出窓サイズを決定して、検出窓サイズを保持する（ステップＳ１３０５）。
　［１．１７　学習処理シーケンス］
　図１７は、ゲートウェイ３００及びサーバ４００の連携による学習処理シーケンスの一例を示す。学習処理シーケンスでは、車両の車載ネットワークにおいてゲートウェイ３００が受信したフレームの集合に加工処理を加えてなる特徴情報をサーバ４００に送信し、サーバ４００では特徴情報を基準モデルへ反映する。以下、図１７に即して学習処理シーケンスについて説明する。
　ゲートウェイ３００は、加工処理部３５０において、保持している検出窓サイズの時間長の検出窓毎に、バス２００ａ及びバス２００ｂからフレーム（データフレーム）を受信すると（ステップＳ１４０１）、検出窓内におけるＩＤ（メッセージＩＤ）別のフレームの受信数をカウントする（ステップＳ１４０２）。
　加工処理部３５０は、検出窓サイズ分の時間の経過（つまり１つの検出窓の終期の到来）を判定し（ステップＳ１４０３）、検出窓の終期が到来したら、ＩＤ別のフレームの受信数（カウント数）に基づき加工処理により特徴情報を生成する（ステップＳ１４０４）。続いてゲートウェイ３００は、加工処理部３５０で生成した特徴情報をサーバ４００に送信し（ステップＳ１４０５ａ）、加工処理部３５０ではカウント数をクリアして（ステップＳ１４０６）、次の検出窓についての処理に戻る（つまりステップＳ１４０１での処理へ戻る）。なお、ゲートウェイ３００は、ステップＳ１４０３で、検出窓の終期が到来していないと判定された場合には、ステップＳ１４０１での処理に戻る。
　ステップＳ１４０５ａでのゲートウェイ３００による特徴情報の送信に呼応して、サーバ４００では、特徴情報を受信し（ステップＳ１４０５ｂ）、学習部４３０で、受信した特徴情報を基準モデルに反映する（ステップＳ１４０７）。なお、サーバ４００は、特徴情報を受信する毎に基準モデルへの反映を行うこととしても良いし、複数の特徴情報を受信してからデータ蓄積部４２０に蓄積し、複数の特徴情報をまとめて学習部４３０で特徴情報の基準モデルへの反映を行うこととしても良い。この学習処理シーケンスは、車両の車載ネットワークにおいて正常状態で受信されたフレームに係る特徴情報を基準モデルに反映することで、基準モデルが、その車両の車載ネットワークのバスに現れるフレームの出現頻度に係る基準となることを想定している。基準モデルは、例えば、車両から取得した車両識別情報毎に定められる。基準モデルは、例えば車両毎に定められるが、例えば、同一車種の車両においては共通にすることとしても良い。即ち、サーバ４００が車両からの車両識別情報に応じて検出窓サイズを示す情報を送信したその送信先の車両に対応して、基準モデルが存在し、その基準モデルを示すモデル情報が、後述のモデル更新処理シーケンスでその車両に送信される。なお、特徴情報の基準モデルへの反映は、例えば、特徴情報を用いた機械学習により基準モデルを更新することで行われるようにしても良い。
　以下、学習処理シーケンスで用いた検出窓サイズの時間長の検出窓と加工処理により生成された特徴情報との一例について、図１８を用いて説明する。
　ゲートウェイ３００の加工処理部３５０では、検出窓サイズの時間長の各期間（各検出窓Ｔ１、Ｔ２、Ｔ３）において、検出窓内にバスから受信されたフレームの数に基づく特徴情報を特定する。図１８では、特徴情報として、受信されたメッセージＩＤ毎のフレームの数を成分とする特徴ベクトルを特徴情報として特定する例を示している。図１８では、ＩＤが１であるフレームをＩＤ１、ＩＤが２であるフレームをＩＤ２等と表現している。特徴ベクトルは、例えば、検出窓内におけるＩＤ１の受信数（カウント数）、ＩＤ２の受信数、ＩＤ３の受信数、ＩＤ４の受信数のそれぞれを成分とするベクトルである。ベクトルの成分数は、例えば、バスに出現する全てのメッセージＩＤの数である。図１８の例では、ＩＤ１、ＩＤ２、ＩＤ３、ＩＤ４の各受信数をこの順に並べた成分を有する特徴ベクトルを示している。検出窓Ｔ１においてＩＤ１、ＩＤ２、ＩＤ３の受信数は１でありＩＤ４の受信数は０であるので、検出窓Ｔ１における特徴ベクトルは［１，１，１，０，・・・］となっている。また、検出窓Ｔ２においてＩＤ１、ＩＤ２、ＩＤ４の受信数は１でありＩＤ３の受信数は０であるので、検出窓Ｔ２における特徴ベクトルは［１，１，０，１，・・・］となっている。また、検出窓Ｔ３においてＩＤ１、ＩＤ３の受信数は１でありＩＤ２、ＩＤ４の受信数は０であるので、検出窓Ｔ３における特徴ベクトルは［１，０，１，０，・・・］となっている。なお、ゲートウェイ３００で検出窓サイズの期間においてカウントしたＩＤ毎の受信したフレームの数を、サーバ４００の基準モデルへ反映するまでにおける、ゲートウェイ３００とサーバ４００との処理（加工処理等）の分担は、いかなるものでも良い。また、加工処理において、主成分分析等を用いることで、特徴情報としての特徴ベクトルの次元数（成分の数）を削減しても良い。
　サーバ４００では、特徴情報を基準モデルに反映する際に、例えば、その基準モデルと同様の所定モデルを用いたゲートウェイ３００での異常の検知を効率的に行えるようにするための加工等を施しても良い。一例としては、サーバ４００は、ゲートウェイ３００から逐次取得した特徴情報としての、上述の次元数を削減等した特徴ベクトルの集合を、ｋｄ木（k-dimensional tree）等の最近傍距離の計算に適したデータ構造にすることをもって基準モデルへの反映を行う。
　［１．１８　モデル更新処理シーケンス］
　図１９は、ゲートウェイ３００及びサーバ４００の連携によるモデル更新処理シーケンスの一例を示す。モデル更新処理シーケンスでは、サーバ４００において更新された基準モデルを、車両のゲートウェイ３００が保持する所定モデルに反映する。以下、図１９に即してモデル更新処理シーケンスについて説明する。モデル更新処理シーケンスは、任意のタイミング（例えば１日毎）に実行される。
　サーバ４００は、上述の学習処理シーケンスの結果として基準モデルの更新（基準モデルの内容の変化）があったか否かを判定する（ステップＳ１５０１）。基準モデルの更新があった場合には、サーバ４００は、更新後の基準モデルを示すモデル情報を、ゲートウェイ３００に送信する（ステップＳ１５０２ａ）。これに呼応してゲートウェイ３００は、基準モデルを示すモデル情報を受信する（ステップＳ１５０２ｂ）。
　ゲートウェイ３００は、モデル情報を受信すると、異常検知処理部３７０で、モデル情報に従ってモデル保持部３７１が保持している所定モデルを更新する（ステップＳ１５０３）。これにより、所定モデルは、例えばサーバ４００における基準モデルと同様となる。
　［１．１９　異常検知処理シーケンス］
　図２０は、ゲートウェイ３００及びサーバ４００の連携による異常検知処理シーケンスの一例を示す。異常検知処理シーケンスは、例えば車両が使用される段階において実行される。ゲートウェイ３００が車両の車載ネットワークのバス２００ａ、２００ｂを流れるフレームを監視して、所定モデルを用いて異常状態が生じているか否かを判定することで異常を検知する処理を含む。所定モデルは、上述のモデル更新処理シーケンスにより、上述の学習処理シーケンスで更新された基準モデルと同様となるように構成されている。なお、上述の学習処理シーケンスは、この異常検知処理シーケンスより前（例えば、車両の使用前、つまり製造或いは検査段階等）に行われ得るが、車両が使用される段階で異常検知処理シーケンスと並行して行われても良い。以下、図２０に即して異常検知処理シーケンスについて説明する。
　ゲートウェイ３００では、フレームが受信されると（ステップＳ１６０１）、加工処理部３５０で、検出窓サイズの検出窓内におけるＩＤ別のフレームの受信数をカウントし（ステップＳ１６０２）、加工処理によって例えば特徴ベクトルである特徴情報を生成する（ステップＳ１６０３）。１つの検出窓においてステップＳ１６０１～ステップＳ１６０２での処理が繰り返し行われ、検出窓の終期においてステップＳ１６０３での特徴情報の生成が行われてＩＤ別のフレームの受信数をカウントするカウンタがクリアされる。
　次にゲートウェイ３００は、異常検知処理部３７０により、加工処理部３５０で生成された特徴情報を受け取り、その特徴情報が、モデル保持部３７１が保持している所定モデルが示す基準に適合しているか、その基準を逸脱しているかを判定する（ステップＳ１６０４）。即ち、異常検知処理部３７０は、特徴情報と所定モデルとを用いた演算処理を行い、その演算処理の結果に応じて、特徴情報が、所定モデルが表す基準を逸脱しているか否か（つまり異常か否か）を判定する。演算処理の一例としては、加工処理部３５０から受け取った特徴情報としての特徴ベクトル（図１８参照）の、ｋｄ木等のデータ構造で表された所定モデルが示す基準（例えば正常状態での特徴ベクトルの分布）に対する最近傍距離を計算して、閾値と比較する処理が、挙げられる。例えば、最近傍距離が正規分布に従うとして、閾値で定めた、平均から標準偏差の一定倍（例えば３倍）の範囲内を逸脱した場合に、異常と判定される。
　ゲートウェイ３００は、ステップＳ１６０４で特徴情報が、所定モデルが示す基準を逸脱していない（基準に適合している）と判定した場合には、正常と判定して（ステップＳ１６０５）、特にサーバ４００への送信を行わない。一方、特徴情報が、所定モデルが示す基準を逸脱していると判定した場合には、異常と判定して（ステップＳ１６０６）、異常検知結果をサーバ４００に送信する（ステップＳ１６０７ａ）。
　サーバ４００は、異常検知結果を受信すると（ステップＳ１６０７ｂ）、異常検知結果をログとして保存する（ステップＳ１６０８）。
　［１．２０　実施の形態１の効果］
　実施の形態１に係る異常検知システム１０では、車両に搭載された異常検知装置としてのゲートウェイ３００が、その車両の識別のための車両識別情報をサーバ４００に送信し、サーバ４００からの応答に基づいて検出窓サイズ（異常検知のためにフレームの受信数をカウントするための単位時間）を決定する。これにより、車両毎に適切な検出窓サイズを用いて車載ネットワークの異常の検知を精度良く行うことが可能となり得る。また、異常検知システム１０では、異常の判定（検知）に用いるモデル（所定モデル或いは基準モデル）の学習のために、ゲートウェイ３００側で受信したフレームに係る特徴ベクトルを生成する加工処理を行うことで、サーバ４００との間の通信量の削減が可能となる。また、加工処理では、主成分分析等による特徴ベクトルの次元の削減等も行い得るので、これにより更に通信量を削減することが可能となり、また、結果的にモデルに基づく異常の判定のための演算量を削減することが可能となり得る。また、サーバ４００が、データ（車両から受信した特徴情報）の蓄積、特徴情報を反映したモデルの構築（基準モデルの更新等）を行うことで、車載のゲートウェイ３００の限られたリソースにより制限を受けることなく、最適なモデルを構築し得る。また、サーバ４００で構築（更新）した基準モデルをゲートウェイ３００が取得して、異常の判定（検知）のために用いることで、車両において迅速に異常か否かの判定（つまり異常の検知）を行うことが可能となり得る。そして、ゲートウェイ３００は、異常検知結果をサーバ４００に通知するので、サーバ４００では異常検知結果をログとして保存し、車両を管理することができ、また、その異常検知結果に基づいて、より適切な基準モデルを構築する等が可能となり得る。また、例えば、車両識別情報で車種を示すようにした場合においては、サーバ４００は、同一車種の複数の車両から特徴情報を収集することでその車種に対応する基準モデルを、その車種で攻撃された状況と正常状態を区別可能に適切に構築することが可能となる。そして、サーバ４００が、その同一車種の車両のゲートウェイ３００に対して、基準モデルを示すモデル情報を送信することで、同一車種の各車両は、基準モデルと同様の所定モデルに基づいて適切に異常を検知し得る。なお、異常の検知により、異常に対する各種対処（警告の報知、安全のための走行制御その他の処理）が可能となり得る。
　（実施の形態２）
　以下、実施の形態１で示した異常検知システムにおける車両の車載ネットワークシステムを変形した実施態様について説明する。
　実施の形態１では、車両のゲートウェイ３００が、車両外部のサーバ４００と通信することで検出窓サイズを決定し、車載ネットワークの異常の検知のために用いる所定モデルの基礎となる基準モデルを学習により更新するために、検出窓サイズ分の時間におけるＩＤ別のフレームの受信数に基づく特徴情報をサーバ４００に送信した。これに対して、本実施の形態では、車両の車載ネットワークシステムにおける異常検知装置が独立して（つまり車両外部のサーバに依存せずに）、異常の検知に用いる検出窓サイズを決定する例について説明する。
　［２．１　車載ネットワークシステムの構成］
　図２１は、本実施の形態に係る車両の車載ネットワークシステムの構成を示す。なお、実施の形態１（図１参照）と同様の構成については、図２１において図１と同一の符号を付しており、説明を省略する。
　図２１に示す車両における車載ネットワークシステムは、ＥＣＵ１００ａ、ＥＣＵ１００ｂ、ＥＣＵ１００ｃ及びＥＣＵ１００ｄと、バス２００ａ、２００ｂと、ゲートウェイ１３００（異常検知装置の一例）とを含んで構成される。各ＥＣＵは、ＣＡＮプロトコルに従って車両内のバス２００ａ、２００ｂを介してフレームの授受を行い得る。
　ゲートウェイ１３００は、実施の形態１で示したゲートウェイ３００を部分的に変形した異常検知装置であり、ここで特に示さない点についてはゲートウェイ３００と同様である。
　ゲートウェイ１３００は、バス２００ａ及びバス２００ｂと接続され、一方のバスから受信したフレームを他方のバスに転送する機能を有し、バスから受信したフレームに基づいて異常か否かを判定すること（例えば攻撃フレームがバスに流れている異常状態であるか否かを判定すること）で異常を検知する機能を有する。また、ゲートウェイ１３００は、異常検知（異常か否かの判定）等に用いるための検出窓サイズを決定する機能、検出窓サイズの時間長の期間である検出窓内に、車載ネットワークで受信されたフレームの数に係る特徴情報に基づいて、異常検知に用いるための所定モデルを更新する機能を有する。
　［２．２　ゲートウェイ１３００の構成］
　図２２は、ゲートウェイ１３００の構成図である。ゲートウェイ１３００は、フレーム送受信部３１０と、フレーム解釈部３２０と、受信ＩＤ判断部３３０と、受信ＩＤリスト保持部３４０と、加工処理部１３５０と、車両識別情報保持部３６１と、異常検知処理部１３７０と、モデル保持部１３７１と、転送処理部３８０と、転送ルール保持部３８１と、フレーム生成部３９０と、検出窓サイズ決定部１４４０と、検出窓サイズ特定用テーブル保持部４５０と、学習部１４３０と、異常検知結果保持部１４６０とを含んで構成される。これらの各構成要素の各機能は、例えばゲートウェイ１３００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、図９に示したゲートウェイ３００と同様の構成、或いは、図１２に示したサーバ４００と同様の構成については、図２２において同一の符号を付しており、説明を省略する。
　検出窓サイズ決定部１４４０は、検出窓サイズを決定する決定部として機能する。検出窓サイズ決定部１４４０は、車両識別情報保持部３６１が保持する車両識別情報に応じて、検出窓サイズ特定用テーブル保持部４５０が保持する検出窓サイズ特定用テーブル（図１３参照）を用いて検出窓サイズを決定し、加工処理部１３５０へと通知する。
　加工処理部１３５０は、実施の形態１で示した加工処理部３５０の一部を変形したものであり、検出窓サイズ決定部１４４０から通知された検出窓サイズを保持し、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて、検出窓サイズの時間長の検出窓毎に、バス２００ａ、２００ｂから逐次受信されたフレームの集合（逐次通知されたＩＤフィールドの値の集合）を、検出窓におけるＩＤ（メッセージＩＤ）別のフレームの受信数（検出窓サイズの検出窓内でフレームの受信をＩＤ別にカウントして得られたカウント数）を示す特徴情報に変換して特徴情報を定期的に学習部１４３０へ通知する。つまり加工処理部１３５０は、特徴情報を特定する特定部として機能する。また、加工処理部１３５０は、バス２００ａ、２００ｂから検出窓サイズの検出窓内に逐次受信されたフレームの数に基づくその特徴情報を異常検知処理部１３７０へ逐次通知する。
　モデル保持部１３７１は、所定モデル（車両の車載ネットワークのバスに現れるデータフレームの出現頻度に係る基準を表すモデル）を保持する。
　学習部１４３０は、加工処理部１３５０から通知された特徴情報に基づいて、所定モデルを構築して、モデル保持部１３７１に保持させる。即ち、学習部１４３０は、モデル保持部１３７１が保持する所定モデルを、特徴情報に基づいて更新する。学習部１４３０による所定モデルの更新は、実施の形態１で示した学習部４３０による基準モデルの更新と同様の方法で行われ得る。学習部１４３０は、例えば、逐次通知される特徴情報に基づいて、例えば機械学習により、所定モデルを逐次更新し得る。
　異常検知処理部１３７０は、フレーム解釈部３２０から通知されるＩＤフィールドの値に基づいて加工処理部１３５０で生成された特徴情報を受け取り、モデル保持部１３７１が保持している所定モデルと、その特徴情報とを用いた演算処理を行い、その演算処理の結果に応じて異常か否かを判定する。即ち、異常検知処理部１３７０は、バスから受信されたフレームの集合に係る特徴情報が、所定モデルが表す基準に適合しているか否かを、特徴情報及び所定モデルを用いた演算処理により判定する判定部として機能する。この判定では、特徴情報に反映された検出窓サイズでのＩＤ別のデータフレームの受信数が、所定モデルが表す基準（例えば正常状態におけるデータフレームの出現頻度を示す基準）に適合していると正常であり、基準に適合していない（つまり基準を逸脱している）と異常であると判定される。また、異常検知処理部３７０は、その演算処理による異常か否かの判定結果（つまり異常検知結果）を、異常検知結果保持部１４６０にログとして保存する。
　［２．３　検出窓サイズ決定処理シーケンス］
　図２３は、ゲートウェイ１３００における検出窓サイズ決定処理シーケンスの一例を示す。以下、同図に即して検出窓サイズ決定処理シーケンスについて説明する。この検出窓サイズ決定処理シーケンスが実行されるタイミングは、例えば、ゲートウェイ１３００が車両に搭載された際（例えば車両の製造の際等）であるが、この他のタイミングであっても良いし、そのタイミングは複数であっても良い。この他のタイミングの例としては、車両を使用する際毎（例えば車両のエンジン始動の際、アクセサリ－オン（ＡＣＣ－ＯＮ）の際等）、所定時間（例えば１日）毎等が挙げられる。なお、図１６と同様のステップについては、図２３において同一の符号を付しており、説明を適宜省略する。
　ゲートウェイ１３００は、車両識別情報を取得する（ステップＳ１３０１）。
　次にゲートウェイ１３００は、ステップＳ１３０１で取得した車両識別情報に応じて、検出窓サイズ特定用テーブル（図１３参照）を用いて検出窓サイズを決定する（ステップＳ２３０３）。ゲートウェイ１３００は、決定した検出窓サイズを保持し、加工処理部１３５０で加工処理を実行する際に検出窓サイズを用いる。なお、ゲートウェイ１３００は、車両外部との通信機能を有していても良く、その場合に、検出窓サイズ特定用テーブルを通信により、車両外部から取得することとしても良いし、記録媒体等から検出窓サイズ特定用テーブルを読み出すことで取得することとしても良い。
　［２．４　学習処理シーケンス］
　図２４は、ゲートウェイ１３００における学習処理シーケンスの一例を示す。学習処理シーケンスでは、ゲートウェイ１３００が、バス２００ａ、２００ｂから受信したフレームの集合に加工処理を加えてなる特徴情報に基づく学習により、モデル保持部１３７１が保持する所定モデルを更新する。以下、図２４に即して学習処理シーケンスについて説明する。なお、図１７と同様のステップについては、図２４において同一の符号を付しており、説明を適宜省略する。
　ゲートウェイ１３００は、検出窓サイズの時間長の検出窓毎に、バス２００ａ及びバス２００ｂからフレームを受信すると（ステップＳ１４０１）、検出窓内におけるＩＤ別のフレームの受信数をカウントする（ステップＳ１４０２）。
　加工処理部１３５０は、検出窓サイズ分の時間が経過（検出窓の終期が到来）したら、ＩＤ別のフレームの受信数（カウント数）に基づき加工処理により特徴情報を生成する（ステップＳ１４０４）。
　ゲートウェイ１３００は、加工処理部１３５０で生成した特徴情報を、学習部１４３０で、モデル保持部１３７１が保持する所定モデルに反映する（ステップＳ２４０７）。この学習処理シーケンスは、車載ネットワークにおいて正常状態で受信されたフレームに係る特徴情報を所定モデルに反映することで、所定モデルが、この車載ネットワークのバスに現れるフレームの出現頻度に係る基準となることを想定している。特徴情報の所定モデルへの反映は、例えば、特徴情報を用いた機械学習により所定モデルを更新することで行われるようにしても良い。なお、加工処理部１３５０は、実施の形態１で示した加工処理部３５０と同様に、検出窓において受信されたメッセージＩＤ毎のフレームの数を成分とする特徴ベクトルを特徴情報としても良く、加工処理において、主成分分析等を用いることで、特徴ベクトルの次元数を削減しても良い。また、学習部１４３０は、特徴情報を所定モデルに反映する際に、例えば、その所定モデルを用いた異常の検知を効率的に行えるようにするための加工等を施しても良い。一例としては、学習部１４３０は、特徴ベクトルの集合を、ｋｄ木等の最近傍距離の計算に適したデータ構造にすることをもって所定モデルへの反映を行う。
　ステップＳ２４０７での処理に続いて、ゲートウェイ１３００は、カウント数をクリアして（ステップＳ１４０６）、ステップＳ１４０１での処理に戻る。
　［２．５　異常検知処理シーケンス］
　図２５は、ゲートウェイ１３００における異常検知処理シーケンスの一例を示す。異常検知処理シーケンスは、例えば車両が使用される段階において実行される。異常検知処理シーケンスでは、ゲートウェイ１３００が、車両の車載ネットワークのバス２００ａ、２００ｂを流れるフレームを監視して、所定モデルを用いて異常状態が生じているか否かを判定することで異常を検知する。なお、上述の学習処理シーケンスは、この異常検知処理シーケンスより前（例えば、車両の使用前、つまり製造或いは検査段階等）に行われ得るが、車両が使用される段階で異常検知処理シーケンスと並行して行われても良い。以下、図２５に即して異常検知処理シーケンスについて説明する。なお、図２０と同様のステップについては、図２５において同一の符号を付しており、説明を適宜省略する。
　ゲートウェイ１３００では、フレームが受信されると（ステップＳ１６０１）、加工処理部１３５０で、検出窓サイズの検出窓内におけるＩＤ別のフレームの受信数をカウントし（ステップＳ１６０２）、加工処理によって例えば特徴ベクトルである特徴情報を生成する（ステップＳ１６０３）。１つの検出窓においてステップＳ１６０１～ステップＳ１６０２での処理が繰り返し行われ、検出窓の終期においてステップＳ１６０３での特徴情報の生成が行われてＩＤ別のフレームの受信数をカウントするカウンタがクリアされる。
　次にゲートウェイ１３００は、異常検知処理部１３７０により、加工処理部１３５０で生成された特徴情報を受け取り、その特徴情報が、モデル保持部１３７１が保持している所定モデルが示す基準に適合しているか、その基準を逸脱しているかを判定する（ステップＳ１６０４）。
　ゲートウェイ１３００は、ステップＳ１６０４で、特徴情報が、所定モデルが示す基準を逸脱していない（基準に適合している）と判定した場合には、正常と判定し（ステップＳ１６０５）、一方、特徴情報が、所定モデルが示す基準を逸脱していると判定した場合には、異常と判定して（ステップＳ１６０６）、その判定結果をログとして保存する（ステップＳ２６０８）。なお、ゲートウェイ１３００は、この判定結果を用いて機械学習（例えば教師有り学習）等により所定モデルを更新しても良い。
　［２．６　実施の形態２の効果］
　実施の形態２に係る異常検知装置（ゲートウェイ１３００）は、サーバ等と通信しなくても、自ら自装置が搭載されている車両の識別のための車両識別情報を取得してその車両識別情報に応じて検出窓サイズ（異常検知のためにフレームの受信数をカウントするための単位時間）を決定し得る。これにより、ゲートウェイ１３００は、自装置を搭載した車両に適切な検出窓サイズを用いて車載ネットワークの異常の検知を精度良く行うことが可能となり得る。また、ゲートウェイ１３００は、車載ネットワークの監視に基づいて生成した特徴情報を反映した所定モデルの構築（所定モデルの更新等）を行い、所定モデルを用いて異常の判定（検知）を行うので、車両において迅速に異常か否かの判定（つまり異常の検知）を行うことが可能となり得る。また、ゲートウェイ１３００は、異常か否かの判定結果をログとして保存でき、その判定結果を活用し得る。
　（その他変形例）
　以上のように、本開示に係る技術の例示として実施の形態１、２を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
　（１）上記実施の形態では、決定された検出窓サイズの時間長の検出窓が重複なく連続する例を示したが（図１８参照）、検出窓サイズ分の期間である各検出窓は、重複なく連続するものに限られない。図２６に示すように、ゲートウェイ（異常検知装置）が、検出窓Ｔ１と一部重複する検出窓ＴＡ内においてもバスから受信されるフレームの数をＩＤ別にカウントすることで、ＩＤ別の受信数（カウント数）を成分とする特徴ベクトルを生成して特徴情報としても良い。この場合において、例えば、ゲートウェイは、検出窓ＴＡの開始時点と基準となる開始時点（例えば先行する検出窓Ｔ１の開始時点）との差であるオフセット時間を示す情報を特徴情報に含ませてサーバに送信することとしても良い。また、例えば、検出窓サイズ（例えば１０ｍｓ）分の各検出窓の開始時点を一定時間（例えば１ｍｓ）毎等と定めることとしても良い。また、バスから特定のＩＤのフレームを受信したタイミング等を検出窓の開始時点とすることとしても良い。
　（２）上記の実施の形態では、データフレーム（メッセージ）の転送機能を有するゲートウェイ３００、１３００を、異常を検知する異常検知装置の一例として示したが、異常検知装置は、１つ以上のバスに接続された装置であれば良く、必ずしも転送機能を有する必要はない。異常検知装置は、異常を検知する機能以外の機能を併せ持つＥＣＵであっても良い。また、例えば、異常検知装置は、ゲートウェイ３００、１３００における１つ以上の構成要素を省略し得るし、その１つ以上の構成要素を他のＥＣＵに移動させても良い。
　（３）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレーム（メッセージ）を標準ＩＤフォーマット（図２参照）で記述しているが、拡張ＩＤフォーマットであっても良く、メッセージＩＤは、拡張ＩＤフォーマットでの拡張ＩＤ等であっても良い。また、上記実施の形態で示したＣＡＮプロトコルは、ＴＴＣＡＮ（Time-Triggered CAN）、ＣＡＮＦＤ（CAN with Flexible Data Rate）等の派生的なプロトコルも包含する広義の意味のものとしても良い。
　（４）上記実施の形態１では、ゲートウェイ３００が外部通信部３６０を有する例を示したが、車載ネットワークに接続されたヘッドユニット或いは他のＥＣＵ（車外と通信する機能を有する装置）を経由して通信するとしても良い。ヘッドユニットは、例えば、マルチメディア再生、カーナビゲーション等の機能のために、車両外部との通信機能を有しているＥＣＵである。また、車載ネットワークにおいて、ＯＢＤ２（On-Board Diagnostics２）等の診断ポートに接続される診断ツール（故障診断ツール）等が、サーバ４００との通信機能を有する場合において、ゲートウェイ３００は、その診断ツールを経由してサーバ４００と通信することとしても良い。
　（５）上記実施の形態では、ゲートウェイ３００、１３００は、検出窓サイズの期間でのＩＤ別のフレームの受信数に基づく特徴情報が、所定モデルが示す基準から逸脱する場合に異常と判定しているが、例えば所定モデルの示す内容を逆にすることで、所定モデルに適合する場合（逸脱しない場合）を異常と判定し、逸脱する場合を正常と判定しても良い。また、実施の形態１では、異常検知結果が異常である場合のみ、ゲートウェイ３００がサーバ４００へ異常検知結果を送信してサーバ４００で異常検知結果を保存することとしたが、正常な場合にも異常検知結果を保存するとしても良い。
　（６）上記実施の形態では、ゲートウェイ３００、１３００が検出窓サイズ分の期間である検出窓内にバスから受信したデータフレームの数をＩＤ別にカウントすることでその受信数（カウント数）に基づいて特徴情報を生成する例を示した。しかし、特徴情報は、ＩＤ別にカウントしたカウント数の総数（受信した全てのＩＤのデータフレームの総数）に基づいて、特徴情報を生成するようにしても良い。なお、この場合においては、ＩＤを問わずに受信したデータフレームの数をカウントすることとしても良く、また、基準モデル或いは所定モデルは、その特徴情報と対比し得るように同様の構成（つまりＩＤを区別せずにフレームの出現頻度の基準を示す構成）とする。
　（７）上記実施の形態では、所定モデルが、ゲートウェイ３００、１３００で検出窓サイズの期間にバスから受信されたフレームの数に基づく特徴情報と対比可能な基準（特徴情報が適合すべき基準）を表す例を示した。この他に、所定モデルを、バスから受信されたフレームと対比可能な基準を表すように構成することとしても良い。この場合には、図２０及び図２５におけるステップＳ１６０２、Ｓ１６０３を省略し、ステップＳ１６０４において、バスから受信されたフレームが、所定モデルが示す基準に適合するか否（逸脱する）かを判定することとしても良い。また、上記実施の形態１では、ゲートウェイ３００で加工処理を行うことで特徴情報を生成してサーバ４００に送信することとしたが（例えばステップＳ１４０４、Ｓ１４０５ａ）、ゲートウェイ３００では、バスから受信した各フレームについてのＩＤ及び受信時刻をサーバ４００に送信するようにして、サーバ４００で加工処理を行うこととしても良い。
　（８）上記実施の形態で示した異常検知結果に係るログは、サーバ４００及びゲートウェイ１３００以外の装置（例えば車内のデータ保存専用の装置、ストレージの豊富なヘッドユニット等）に保存することとしても良い。ログの情報は、必要に応じて読み出して、車両の管理、或いは、異常の検知に用いるモデルの設計、構築等に活用し得る。
　（９）上記実施の形態におけるゲートウェイその他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等のハードウェア構成要素を含んでいても良い。また、上記実施の形態で示した各装置は、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
　（１０）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（１１）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしても良い。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしても良い。
　（１２）本開示の一態様としては、例えば図１４～図１７、図１９、図２０、図２３～図２５等に示す処理手順の全部又は一部を含む異常検知方法であるとしても良い。例えば、異常検知方法は、ＣＡＮプロトコルに従って車両内のバスを介してメッセージの授受を行う複数のＥＣＵを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、単位時間（例えば検出窓サイズ分の時間）の決定を行い、決定された単位時間内にバスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、演算処理の結果に応じて異常か否かを判定する。単位時間の決定は、例えば車両識別情報、車両に関連する者等の識別情報、その他の情報等に基づいて行い得る。メッセージは、メッセージの種類を示すメッセージＩＤを含み、異常検知方法は、例えば、車両の識別のための車両識別情報に基づいて単位時間の決定を行う決定ステップ（例えばステップＳ１３０５、Ｓ２３０３等）と、決定ステップで決定された単位時間（決定が複数回行われる場合においては例えば最新の単位時間）内にバスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを特徴情報として特定する特定ステップ（例えばステップＳ１４０４等）と、特定ステップで特定された特徴情報と所定モデルとを用いて演算処理を行い、演算処理の結果に応じて異常か否かの判定を行う判定ステップ（例えばステップＳ１６０４等）とを含む。また、例えば、異常検知方法は更に、特定ステップで逐次特定された複数の特徴情報に基づいて所定モデルを逐次更新する更新ステップ（例えばステップＳ１５０３、Ｓ２４０７等）を含む。また、本開示の一態様としては、この異常検知方法に係る処理をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本開示の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を、前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
　（１３）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示は、車載ネットワークに対する攻撃を検知するために利用可能である。
　１０　異常検知システム
　４０　ネットワーク
　１００ａ　エンジンＥＣＵ
　１００ｂ　ブレーキＥＣＵ
　１００ｃ　ドア開閉センサＥＣＵ
　１００ｄ　ウィンドウ開閉センサＥＣＵ
　１０１　エンジン
　１０２　ブレーキ
　１０３　ドア開閉センサ
　１０４　ウィンドウ開閉センサ
　１１０，３１０　フレーム送受信部
　１２０，３２０　フレーム解釈部
　１３０，３３０　受信ＩＤ判断部
　１４０，３４０　受信ＩＤリスト保持部
　１５０　フレーム処理部
　１６０　データ取得部
　１７０，３９０　フレーム生成部
　２００ａ，２００ｂ　バス
　３００，１３００　ゲートウェイ（異常検知装置）
　３５０，１３５０　加工処理部
　３６０　外部通信部
　３６１　車両識別情報保持部
　３７０，１３７０　異常検知処理部
　３７１，１３７１　モデル保持部
　３８０　転送処理部
　３８１　転送ルール保持部
　４００　サーバ
　４１０　通信部
　４２０　データ蓄積部
　４３０，１４３０　学習部
　４４０　検出窓サイズ特定部
　４５０　検出窓サイズ特定用テーブル保持部
　４６０，１４６０　異常検知結果保持部
　１４４０　検出窓サイズ決定部

Claims (16)

  1. 　ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおける異常の検知のための異常検知方法であって、
    　単位時間の決定を行い、
    　前記決定された単位時間内に前記バスから受信されたメッセージの数に基づく特徴情報と、メッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて異常か否かを判定する
    　異常検知方法。
  2. 　前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    　前記異常検知方法は、
    　単位時間の前記決定を行う決定ステップと、
    　前記決定ステップで決定された単位時間内に前記バスから受信されたメッセージＩＤ毎のメッセージの数を成分とする特徴ベクトルを前記特徴情報として特定する特定ステップと、
    　前記特定ステップで特定された前記特徴情報と前記所定モデルとを用いて前記演算処理を行い、当該演算処理の結果に応じて前記判定を行う判定ステップとを含む
    　請求項１記載の異常検知方法。
  3. 　前記決定ステップでは、前記車両の識別のための車両識別情報に基づいて単位時間の前記決定を行う
    　請求項２記載の異常検知方法。
  4. 　前記車両識別情報は、前記車両の製造事業者を示す
    　請求項３記載の異常検知方法。
  5. 　前記車両識別情報は、前記車両の車種を示す
    　請求項３記載の異常検知方法。
  6. 　前記車両識別情報は、前記車両を他の車両と区別する情報である
    　請求項３記載の異常検知方法。
  7. 　前記決定ステップでは、前記車両識別情報により識別される車両の集合における各車両の車載ネットワークシステムで当該車両内のバスに正常状態で送信されるべき、互いに異なる複数種類のメッセージのうち、送信周期が最短の一種類のメッセージの当該送信周期を、単位時間とするように前記決定を行う
    　請求項３～６のいずれか一項に記載の異常検知方法。
  8. 　前記判定ステップでは、前記車両識別情報に対応した前記所定モデルを用いて前記演算処理を行う
    　請求項３～７のいずれか一項に記載の異常検知方法。
  9. 　前記特定ステップでは、前記決定ステップで決定された単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
    　前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行い、
    　前記異常検知方法は更に、前記特定ステップで逐次特定された複数の前記特徴情報に基づいて前記所定モデルを逐次更新する更新ステップを含む
    　請求項２～８のいずれか一項に記載の異常検知方法。
  10. 　前記決定ステップでは、前記車両の製造の際に規定された情報に基づいて、前記車両において単位時間の前記決定を行い、
    　前記特定ステップでは、前記車両において前記特徴情報を特定する
    　請求項２～９のいずれか一項に記載の異常検知方法。
  11. 　前記決定ステップでは、前記車両のエンジン始動又はアクセサリ－オンの際に、前記車両において単位時間の前記決定を行い、
    　前記特定ステップでは、前記車両において前記特徴情報を特定する
    　請求項２～９のいずれか一項に記載の異常検知方法。
  12. 　前記決定ステップでは、所定時間毎に単位時間の前記決定を行い、
    　前記特定ステップでは、前記決定ステップで決定された最新の単位時間毎に、当該単位時間内で前記バスから受信されたメッセージの数に基づく前記特徴情報を、逐次特定し、
    　前記判定ステップでは、前記特定ステップで逐次特定された各前記特徴情報について、当該特徴情報と前記所定モデルとを用いて前記演算処理を行う
    　請求項２～９のいずれか一項に記載の異常検知方法。
  13. 　前記メッセージは、メッセージの種類を示すメッセージＩＤを含み、
    　前記特徴情報は、前記決定された単位時間内に前記バスから受信された、全てのメッセージＩＤのメッセージの総数を示す
    　請求項１記載の異常検知方法。
  14. 　ＣＡＮ（Controller Area Network）プロトコルに従って車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて、前記バスに接続されて異常を検知する異常検知装置であって、
    　前記バスからメッセージを受信する受信部と、
    　単位時間を決定する決定部と、
    　前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
    　前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備える
    　異常検知装置。
  15. 　一の車両とサーバとを備える異常検知システムであって、
    　前記一の車両は、ＣＡＮ（Controller Area Network）プロトコルに従って前記一の車両内のバスを介してメッセージの授受を行う複数の電子制御ユニットと当該バスに接続された異常検知装置とを備える車載ネットワークシステムを有し、
    　前記異常検知装置は、
    　前記バスからメッセージを受信する受信部と、
    　前記一の車両の識別のための車両識別情報を前記サーバに送信し、前記サーバからの応答に基づいて単位時間を決定する決定部と、
    　前記決定部により決定された単位時間内に前記受信部により受信されたメッセージの数に基づく特徴情報を特定する特定部と、
    　前記特定部で特定された前記特徴情報とメッセージの出現頻度に係る基準を表す所定モデルとを用いた演算処理の結果に応じて、異常か否かを判定する判定部とを備え、
    　前記サーバは、前記一の車両から前記車両識別情報を受信し、当該車両識別情報に基づいて特定した単位時間を示す情報を、前記一の車両に送信する通信部を備える
    　異常検知システム。
  16. 　前記サーバは、更に、前記一の車両から受信した前記車両識別情報に基づいて特定した単位時間内に、当該車両識別情報により識別される車両の集合における１つ以上の車両の車載ネットワークシステムで当該車両内のバスから受信されたメッセージの数に基づく所定情報を取得し、当該所定情報に基づいて、メッセージの出現頻度に係る基準を表す基準モデルを更新する学習部を備え、
    　前記通信部は、前記学習部により更新した前記基準モデルを示す情報を前記一の車両に送信し、
    　前記異常検知装置は、前記サーバから受信した前記基準モデルを示す情報に基づいて、前記所定モデルを更新し、
    　前記判定部は、前記特徴情報と、前記更新された前記所定モデルとを用いた演算処理を行い、当該演算処理の結果に応じて、異常か否かの前記判定を行う
    　請求項１５記載の異常検知システム。
PCT/JP2016/087134 2016-01-08 2016-12-14 異常検知方法、異常検知装置及び異常検知システム WO2017119246A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP20168399.2A EP3697031B1 (en) 2016-01-08 2016-12-14 Abnormality detection method, abnormality detection device, and abnormality detection system in a vehicle network
CN202110213461.7A CN113014464B (zh) 2016-01-08 2016-12-14 异常检测方法、异常检测装置及异常检测***
EP16883746.6A EP3402128B1 (en) 2016-01-08 2016-12-14 Abnormality detection method, abnormality detection device, and abnormality detection system
CN201680051251.XA CN108028790B (zh) 2016-01-08 2016-12-14 异常检测方法、异常检测装置及异常检测***
US16/026,040 US10986008B2 (en) 2016-01-08 2018-07-02 Abnormality detection in an on-board network system
US17/201,839 US11296965B2 (en) 2016-01-08 2021-03-15 Abnormality detection in an on-board network system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2016-003035 2016-01-08
JP2016003035 2016-01-08
JP2016212574A JP6839963B2 (ja) 2016-01-08 2016-10-31 異常検知方法、異常検知装置及び異常検知システム
JP2016-212574 2016-10-31

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/026,040 Continuation US10986008B2 (en) 2016-01-08 2018-07-02 Abnormality detection in an on-board network system

Publications (1)

Publication Number Publication Date
WO2017119246A1 true WO2017119246A1 (ja) 2017-07-13

Family

ID=59273554

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/087134 WO2017119246A1 (ja) 2016-01-08 2016-12-14 異常検知方法、異常検知装置及び異常検知システム

Country Status (3)

Country Link
US (1) US11296965B2 (ja)
CN (1) CN113014464B (ja)
WO (1) WO2017119246A1 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110098989A (zh) * 2018-01-30 2019-08-06 上海融聂电子科技有限公司 一种基于canfd总线的多路can仿真***及测试方法
CN111338318A (zh) * 2020-03-02 2020-06-26 北京百度网讯科技有限公司 用于检测异常的方法和装置
CN111373701A (zh) * 2018-05-23 2020-07-03 松下电器（美国）知识产权公司 异常检测装置、异常检测***以及控制方法
CN115277051A (zh) * 2022-06-01 2022-11-01 北京邮电大学 一种控制器局域网总线攻击检测方法和设备
US11575538B2 (en) * 2018-05-23 2023-02-07 Panasonic Intellectual Property Corporation Of America Anomaly detection device, anomaly detection method, and recording medium
JP7230147B1 (ja) 2021-09-24 2023-02-28 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6761793B2 (ja) * 2017-10-13 2020-09-30 日立オートモティブシステムズ株式会社 車両用制御装置
CN111434077B (zh) * 2018-05-23 2023-02-24 松下电器（美国）知识产权公司 通信控制装置、移动网络***、通信控制方法以及存储介质
US11394733B2 (en) * 2019-11-12 2022-07-19 Bank Of America Corporation System for generation and implementation of resiliency controls for securing technology resources
JP7247905B2 (ja) * 2020-01-22 2023-03-29 トヨタ自動車株式会社 第１中継装置、第２中継装置、第１中継方法、第２中継方法、第１中継プログラム、第２中継プログラム、及び中継システム
CN113691421B (zh) * 2021-08-27 2022-08-02 烽火通信科技股份有限公司 一种报文生成方法和装置
CN114143114A (zh) * 2022-01-12 2022-03-04 福建省海峡信息技术有限公司 一种基于智能终端的网络安全通信方法
CN115412370B (zh) * 2022-10-31 2023-03-21 广汽埃安新能源汽车股份有限公司 车辆通信数据检测方法、装置、电子设备和可读介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006287739A (ja) * 2005-04-01 2006-10-19 Fujitsu Ten Ltd ゲートウェイ装置
JP2009035237A (ja) * 2007-08-03 2009-02-19 Mitsubishi Fuso Truck & Bus Corp 故障診断装置及び故障診断方法
JP2009253557A (ja) * 2008-04-03 2009-10-29 Autonetworks Technologies Ltd 車載用の中継接続ユニット
JP2015026252A (ja) 2013-07-26 2015-02-05 株式会社豊田中央研究所 異常検知装置及びプログラム
JP2015170121A (ja) 2014-03-06 2015-09-28 株式会社豊田中央研究所 異常診断装置及びプログラム
WO2015159520A1 (ja) * 2014-04-17 2015-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、不正検知電子制御ユニット及び不正検知方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7174482B2 (en) * 2001-05-04 2007-02-06 Honeywell International Inc. Process control bus monitoring and analysis
FR2942363B1 (fr) * 2009-02-13 2016-11-25 Continental Automotive France Procede de communication entre deux calculateurs electroniques automobiles et dispositif associe
EP2415242B1 (de) * 2009-04-03 2019-05-08 Continental Teves AG & Co. OHG Datensicherheit für die kommunikation mit gleichgestellten teilnehmern
CN102546216B (zh) * 2010-12-30 2015-03-11 ***通信集团山东有限公司 网络管理***中的告警消息处理方法及网络管理***
US9225544B2 (en) * 2011-12-22 2015-12-29 Toyota Jidosha Kabushiki Kaisha Communication system and communication method
JP5919205B2 (ja) * 2013-01-28 2016-05-18 日立オートモティブシステムズ株式会社 ネットワーク装置およびデータ送受信システム
CN104660565B (zh) * 2013-11-22 2018-07-20 华为技术有限公司 恶意攻击的检测方法和装置
JP6314517B2 (ja) * 2014-02-10 2018-04-25 富士通株式会社 状態通知方法、装置、およびプログラム
JP2015199444A (ja) * 2014-04-09 2015-11-12 株式会社デンソー 電子制御装置
US8955130B1 (en) * 2014-04-10 2015-02-10 Zephyr Technology Co., Limited Method for protecting vehicle data transmission system from intrusions
CN104301177B (zh) * 2014-10-08 2018-08-03 清华大学 Can报文异常检测方法及***
US10798114B2 (en) 2015-06-29 2020-10-06 Argus Cyber Security Ltd. System and method for consistency based anomaly detection in an in-vehicle communication network

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006287739A (ja) * 2005-04-01 2006-10-19 Fujitsu Ten Ltd ゲートウェイ装置
JP2009035237A (ja) * 2007-08-03 2009-02-19 Mitsubishi Fuso Truck & Bus Corp 故障診断装置及び故障診断方法
JP2009253557A (ja) * 2008-04-03 2009-10-29 Autonetworks Technologies Ltd 車載用の中継接続ユニット
JP2015026252A (ja) 2013-07-26 2015-02-05 株式会社豊田中央研究所 異常検知装置及びプログラム
JP2015170121A (ja) 2014-03-06 2015-09-28 株式会社豊田中央研究所 異常診断装置及びプログラム
WO2015159520A1 (ja) * 2014-04-17 2015-10-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、不正検知電子制御ユニット及び不正検知方法

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110098989A (zh) * 2018-01-30 2019-08-06 上海融聂电子科技有限公司 一种基于canfd总线的多路can仿真***及测试方法
CN111373701A (zh) * 2018-05-23 2020-07-03 松下电器（美国）知识产权公司 异常检测装置、异常检测***以及控制方法
EP3799359A4 (en) * 2018-05-23 2021-07-14 Panasonic Intellectual Property Corporation of America ANOMALY DETECTION DEVICE, ANOMALY DETECTION SYSTEM AND CONTROL PROCESS
US11575538B2 (en) * 2018-05-23 2023-02-07 Panasonic Intellectual Property Corporation Of America Anomaly detection device, anomaly detection method, and recording medium
US11848755B2 (en) 2018-05-23 2023-12-19 Panasonic Intellectual Property Corporation Of America Anomaly detection device, anomaly detection method, and recording medium
CN111338318A (zh) * 2020-03-02 2020-06-26 北京百度网讯科技有限公司 用于检测异常的方法和装置
JP7230147B1 (ja) 2021-09-24 2023-02-28 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023048187A1 (ja) * 2021-09-24 2023-03-30 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
JP2023046938A (ja) * 2021-09-24 2023-04-05 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
CN115277051A (zh) * 2022-06-01 2022-11-01 北京邮电大学 一种控制器局域网总线攻击检测方法和设备
CN115277051B (zh) * 2022-06-01 2024-06-07 北京邮电大学 一种控制器局域网总线攻击检测方法和设备

Also Published As

Publication number Publication date
US20210226872A1 (en) 2021-07-22
CN113014464B (zh) 2022-07-26
US11296965B2 (en) 2022-04-05
CN113014464A (zh) 2021-06-22

Similar Documents

Publication Publication Date Title
JP7013603B2 (ja) 異常検知方法、異常検知装置及び異常検知システム
WO2017119246A1 (ja) 異常検知方法、異常検知装置及び異常検知システム
US11570184B2 (en) In-vehicle network system, fraud-detection electronic control unit, and fraud-detection method
US11569984B2 (en) Key management method used in encryption processing for safely transmitting and receiving messages
JP7008100B2 (ja) 不正対処方法、不正検知電子制御ユニットおよびネットワーク通信システム
US11356475B2 (en) Frame transmission prevention apparatus, frame transmission prevention method, and in-vehicle network system
JP6539363B2 (ja) 不正通信検知方法、不正通信検知システム及びプログラム
US11113382B2 (en) Vehicle network system whose security is improved using message authentication code
CN110546921B (zh) 不正当检测方法、不正当检测装置以及程序
US20240031199A1 (en) Anomaly determination method, anomaly determination device, and recording medium
CN115580471A (zh) 不正当检测方法、不正当检测装置以及存储介质
WO2018020833A1 (ja) フレーム伝送阻止装置、フレーム伝送阻止方法及び車載ネットワークシステム

Legal Events

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

Ref document number: 16883746

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016883746

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016883746

Country of ref document: EP

Effective date: 20180808