WO2018012322A1 - 演算装置 - Google Patents

演算装置 Download PDF

Info

Publication number
WO2018012322A1
WO2018012322A1 PCT/JP2017/024153 JP2017024153W WO2018012322A1 WO 2018012322 A1 WO2018012322 A1 WO 2018012322A1 JP 2017024153 W JP2017024153 W JP 2017024153W WO 2018012322 A1 WO2018012322 A1 WO 2018012322A1
Authority
WO
WIPO (PCT)
Prior art keywords
communication
unit
identifier
monitoring
communication data
Prior art date
Application number
PCT/JP2017/024153
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
Application filed by 日立オートモティブシステムズ株式会社 filed Critical 日立オートモティブシステムズ株式会社
Publication of WO2018012322A1 publication Critical patent/WO2018012322A1/ja

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • 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]

Definitions

  • the present invention relates to an arithmetic device.
  • a plurality of nodes send a message at least once and monitor the presence / absence of communication of the plurality of nodes at a substantially fixed time, and the node detects a node for which communication is not detected within the substantially fixed time.
  • a node monitoring method having communication interruption detection means for recording together with rank information that is not performed.
  • Patent Document 1 cannot detect an abnormality that occurs in non-periodic communication.
  • An arithmetic device is an arithmetic device that transmits and receives communication data, wherein a communication unit that transmits and receives the communication data including an identifier indicating the content of the communication data, and the order in which the identifiers are defined
  • a storage unit that stores the monitoring conditions described above, and a detection unit that detects a communication abnormality, wherein the detection unit includes a communication order of the plurality of communication data transmitted and received by the communication unit, and the monitoring conditions.
  • a communication abnormality is detected based on the specified order of the identifiers described.
  • the figure which shows an example of a verification table Flow chart showing operation when detecting unit receives CAN-ID from monitoring unit
  • the ECU is mounted on the vehicle.
  • FIG. 1 is a diagram showing a configuration of an in-vehicle network 2 to which a first ECU 100 according to the present invention is connected.
  • the in-vehicle network 2 is mounted on the vehicle 1.
  • the in-vehicle network 2 is connected to a first ECU 100, a second ECU 200, a third ECU 300, and a fourth ECU 400.
  • Other devices (not shown) are also connected to the in-vehicle network 2.
  • the in-vehicle network 2 is a so-called CAN network that uses CAN (Controller Area Network) as a communication protocol.
  • the first ECU 100, the second ECU 200, the third ECU 300, and the fourth ECU 400 perform communication in accordance with the CAN communication protocol.
  • CAN Controller Area Network
  • Communication data exchanged in the CAN network that is, a data frame includes a header and a payload.
  • the header includes a CAN-ID.
  • the CAN-ID is information indicating the type of payload or the contents of the payload.
  • the payload is data for communication purposes.
  • Each of the first ECU 100, the second ECU 200, the third ECU 300, and the fourth ECU 400 includes a communication interface corresponding to CAN, a CPU, a RAM, and a ROM.
  • the CPU expands and executes a program (not shown) stored in the ROM on the RAM, and performs operations described later.
  • the fourth ECU 400 performs display control of the dashboard including the abnormality display unit 610.
  • the dashboard is connected to the abnormality display unit 610.
  • the fourth ECU 400 receives a predetermined data frame indicating abnormality detection, the fourth ECU 400 causes the abnormality display unit 610 to display a display indicating the occurrence of the abnormality.
  • the abnormality display unit 610 is a part of the dashboard 800 of the vehicle 1 as shown in FIG. 2. For example, by turning on the icon of the tool as shown in FIG. Notice.
  • the first ECU 100 stores in advance the order of communication between ECUs.
  • the order is, for example, as follows. First, communication from the first ECU 100 to the second ECU 200 and the third ECU 300 is performed (“1” in FIG. 1). Next, communication from the second ECU 200 to the first ECU 100 is performed (“2” in FIG. 1). Next, communication from the third ECU 300 to the first ECU 100 is performed (“3” in FIG. 1). Finally, communication addressed to another device is performed from the first ECU 100 (“4” in FIG. 1).
  • the first ECU 100 monitors the order in which communication is performed, and when communication is not performed in the order described above, that is, when the order of communication has changed, it determines that an abnormality has occurred and performs communication notifying the occurrence of the abnormality. Do.
  • the fourth ECU 400 receives the communication notifying the occurrence of the abnormality, the fourth ECU 400 causes the abnormality display unit 610 to display a display indicating the occurrence of the abnormality.
  • FIG. 3 is a block diagram showing the configuration of the first ECU 100.
  • the first ECU 100 includes a communication unit 110, an extraction unit 120, a storage unit 130, a detection unit 140, an output unit 150, and a control calculation unit 160 as functions thereof.
  • the communication unit 110 is a communication interface corresponding to CAN, and transmits a data frame to the in-vehicle network 2 and receives a data frame from the in-vehicle network 2. Information on the data frame transmitted or received by the communication unit 110 is output to the extraction unit 120 and the control calculation unit 160.
  • the extraction unit 120 extracts the CAN-ID from the data frame information input from the communication unit 110 and outputs the extracted CAN-ID to the detection unit 140.
  • the monitoring condition table 500 is stored in the storage unit 130.
  • the storage unit 130 provides the monitoring condition table 500 to the detection unit 140.
  • the configuration of the monitoring condition table 500 will be described in detail later.
  • the detection unit 140 acquires the monitoring condition table 500 from the storage unit 130, and based on the CAN-ID information input from the extraction unit 120, the order of the data frames transmitted or received by the communication unit 110 is determined according to the monitoring condition table. It is verified whether it matches the order described in 500.
  • the detection unit 140 includes a verification table 600 used for this verification. If it is determined by this verification that the communication order of the data frames transmitted or received by the communication unit 110 does not match the order of the identifiers described in the monitoring condition table 500, a signal indicating abnormality detection is output to the output unit 150.
  • the operation of the detection unit 140 and the configuration of the verification table 600 will be described in detail later.
  • the control calculation unit 160 When a signal indicating abnormality detection is input from the detection unit 140, the output unit 150 generates a predetermined data frame and transmits the data frame to the communication unit 110. The influence of this data frame on other devices will be described later.
  • the control calculation unit 160 generates a data frame for communicating with other ECUs and other devices according to a predetermined procedure, and causes the communication unit 110 to transmit the data frame. For example, the control calculation unit 160 generates a data frame at a predetermined time period and causes the communication unit 110 to transmit the data frame. In addition, the control calculation unit 160 performs a calculation using the payload of the received data frame, generates a data frame including the calculation result in the payload, and causes the communication unit 110 to transmit the data frame.
  • the extraction unit 120, the storage unit 130, and the detection unit 140 operate in cooperation with each other, but the operation of the control calculation unit 160 is independent of these.
  • FIG. 4 is a diagram illustrating an example of the monitoring condition table 500.
  • the monitoring condition table 500 is composed of two or more records. Each record in the monitoring condition table 500 has five fields: order, premise flag, condition, timeout, and established flag.
  • the order field stores information indicating the order in which conditions are established in the monitoring condition table 500, in other words, the order of normal communication. For example, an integer of 1 or more is stored in the order field, and at least “1” and “2” are stored. In the example shown in FIG. 4, since different values are stored in the four records, it is normal that the four conditions are satisfied one by one.
  • the premise flag field a precondition that the record is valid is described.
  • the first record in FIG. 4 indicates that the premise flag is unnecessary and is always valid.
  • the second record in FIG. 4 indicates that it becomes effective when the flag “CD1” is set.
  • a condition evaluated in the record is stored.
  • the condition in the present embodiment is that the CAN-ID of the detected data frame matches a specific value.
  • the condition of the first record in FIG. 4 indicates that the CAN-ID of the data frame transmitted or received by the communication unit 110 is “0x01”.
  • a timeout time is stored in the timeout field.
  • processing is performed in the same manner as when the communication unit 110 transmits or receives a data frame that does not satisfy the condition.
  • a record in which infinity is stored in the timeout field is treated as no timeout.
  • “200 microseconds” is stored in the timeout field, so when the condition of the first record, which is the previous condition, is satisfied, that is, the CAN-ID is “0x11”.
  • a time-out is determined when 200 microseconds have elapsed since the communication unit 110 transmitted or received the data frame.
  • the established flag field stores a flag that is set when the condition described in the condition field of the record is established. For example, when the condition described in the first record in FIG. 4 is satisfied, the flag “CD1” is set.
  • FIG. 5 is a diagram illustrating an example of the verification table 600.
  • the verification table 600 is composed of one or more records.
  • Each record of the verification table 600 has three fields: table number, establishment time, and monitoring number.
  • the number of records constituting the verification table 600 is the same as the number of monitoring condition tables 500 stored in the storage unit 130.
  • the verification table 600 is edited by the detection unit 140.
  • the table number field stores an identifier for identifying each monitoring condition table, that is, a table number.
  • the establishment time field the time when the latest condition is established is stored.
  • the monitoring number field a number representing the “order” of the currently valid record is stored.
  • the initial value of the monitoring number field is “1”.
  • the verification table 600 illustrated in FIG. 5 represents the following. However, here, the table number “1” corresponds to the monitoring condition table 500 shown in FIG. Since the field of the monitoring number in the verification table 600 illustrated in FIG. 5 is “2”, a record with the order “2” in the monitoring condition table 500 is valid. Further, it is indicated that the latest condition is satisfied at “0: 01: 23.456” stored in the establishment time field, that is, the condition of the record having the order “1” is satisfied. In other words, the time when the communication unit 110 transmits or receives the data frame including the CAN-ID of 0x01 in the header is “0: 01: 23.456”.
  • the detection unit 140 refers to the verification table 600 and the monitoring number in each monitoring condition table 500, that is, a valid record. Specify the value of the order.
  • the detection unit 140 refers to the monitoring condition table 500 stored in the storage unit 130 and identifies the OK determination ID and the NG determination ID.
  • the OK determination ID is a CAN-ID that the communication unit 110 is expected to transmit or receive next, and is a CAN-ID described in a trigger condition field in a valid record.
  • the NG determination ID is a CAN-ID that the communication unit 110 is expected to transmit or receive from the next time onward.
  • the CAN-ID described in the condition field in the record after the valid record in the monitoring condition table 500 is ID.
  • the OK determination ID and the NG determination ID in the examples shown in FIGS. 4 to 5 are specified as follows.
  • the verification table 600 shown in FIG. 5 since “2” is stored in the monitoring number field, the second record is valid, and “0x02” described in the second record in the monitoring condition table 500 is the OK determination ID.
  • “0x03, 0x04” described in the records after the second record, that is, the third and fourth records are specified as the NG determination ID.
  • the detection unit 140 determines whether the CAN-ID input from the extraction unit 120 matches the OK determination ID or whether it matches the NG determination ID. If it is determined that the ID matches the OK determination ID, the verification table 600 is updated. When it is determined that it matches the NG determination ID, a signal indicating abnormality detection that the communication order is different is output to the output unit 150. If it is determined that they do not match any of them, no processing is performed. However, if the time obtained by adding the time of the timeout field of the monitoring condition table 500 to the time of the establishment time field of the verification table 600 is past compared to the current time, a signal indicating detection of an abnormality that a timeout has occurred is generated. Output to the output unit 150.
  • the update of the verification table 600 by the detection unit 140 is as follows. That is, the value of the establishment time field is updated to the current time, and the value of the monitoring number field is updated to a value increased by one.
  • the details of updating the value of the monitoring number field are as follows. When the condition of the second record in the monitoring condition table 500 is satisfied, the flag “CD2” described in the field of the established flag on the second line is set. Then, since the third record whose premise flag field value is “CD2” is validated in the monitoring condition table 500, the monitoring number field value of the verification table 600 is updated to “3”.
  • FIG. 6 is a flowchart showing an operation when the detection unit 140 receives a CAN-ID from the extraction unit 120.
  • the execution subject of each step described below is the CPU of the first ECU 100.
  • step S11 the value of the monitoring number field in the verification table 600, that is, the number of a valid record in the monitoring condition table 500 is specified.
  • step S12 the OK determination ID and the NG determination ID are specified by referring to the valid record in the monitoring condition table 500 and the subsequent records.
  • a succeeding step S13 it is determined whether or not a timeout has occurred. If it is determined that a timeout has occurred, the process proceeds to step S18. If it is determined that a timeout has not occurred, the process proceeds to step S14.
  • step S14 it is determined whether or not the input CAN-ID matches the OK determination ID. If it is determined that the ID matches the OK determination ID, the process proceeds to step S17, and if it does not match, the process proceeds to step S15. In step S15, it is determined whether or not the input CAN-ID matches the NG determination ID. If it is determined that it matches the NG determination ID, the process proceeds to step S16, and if it does not match, the flowchart of FIG. 7 ends. In step S16, a signal indicating abnormality detection that the communication order is different is output to the output unit 150, and the flowchart of FIG. 6 ends. In step S17, the verification table 600 is updated, and the flowchart of FIG. In step S18, a signal indicating a time-out error, that is, detection of an abnormality that a time-out has occurred is output to the output unit 150, and the flowchart of FIG. 6 ends.
  • the arithmetic unit that is, the first ECU 100, includes a communication unit 110 that receives communication data including an identifier indicating the content of communication data, that is, CAN-ID, in the header, and a monitoring condition table 500 in which the order in which the identifiers are defined is written. Is stored, and a detection unit 140 that detects a communication abnormality.
  • the detection unit 140 detects a communication abnormality based on the communication order of the plurality of communication data transmitted and received by the communication unit 110 and the prescribed order of the identifiers described in the monitoring condition table 500.
  • the first ECU 100 focuses on the CAN-ID stored in the header of the data frame, and the CAN-ID order corresponding to the communication order of the data frame to be transmitted / received does not match the order of the identifiers described in the monitoring condition table 500 An abnormal communication is detected. Therefore, the first ECU 100 can detect a communication abnormality even in non-periodic communication.
  • the detection unit 140 determines that the communication data including the identifiers included in the monitoring condition table 500, for example, CAN-IDs “0x01”, “0x02”, “0x03”, and “0x04” in the example of FIG. If it is determined that the communication unit 110 transmits / receives data in a communication order different from the order described in the table 500, for example, “0x01, 0x02, 0x04, 0x03”, it is determined that a communication abnormality has been detected. Therefore, communication abnormality can be quickly detected when the order of communication data is changed and received.
  • the detection unit 140 receives the second identifier described next to the first identifier in the monitoring condition table 500. It is determined that a communication abnormality has been detected when communication data including “” is not transmitted / received by the communication unit 110 by a predetermined timeout time. Therefore, it is possible to detect a communication abnormality not only when the communication order is changed but also when the communication interval is longer than the predetermined time.
  • the communication data is a data frame according to the CAN protocol, and the identifier is a CAN-ID. Since CAN employs a bus-type network topology, the first ECU 100 can receive all communications within the same network. Therefore, it is possible to grasp all the order in which the communication data is transmitted.
  • FIG. 7 is a flowchart showing the operation of the detection unit 140 in the first modification. Processing steps that perform the same operations as in FIG. 6 are given the same step numbers. The execution subject of each step described below is the CPU of the first ECU 100.
  • Detecting unit 140 starts operating when first ECU 100 is activated.
  • step S 21 it is determined whether or not the CAN-ID described in the trigger condition field is input from the extraction unit 120 in the record whose order is “1” in the monitoring condition table 500. If it is determined that it has been input, the process proceeds to step S17. If it is determined that it has not been input, the process remains in step S21.
  • step S17 the verification table 600 is updated based on the description of the current verification table 600 and the received CAN-ID, and the process proceeds to step S11.
  • step S11 based on the description of the verification table 600, a valid record number in the monitoring condition table 500 is specified.
  • an OK determination ID is specified.
  • step S14A it is determined whether or not an OK determination ID has been input. If it is determined that it has been input, the process proceeds to step S22. If it is determined that it has not been input, the process proceeds to step S13.
  • the negative determination in step S14A is a case where the communication unit 110 has not received anything, and a case where a data frame having a CAN-ID other than the OK determination ID has been received.
  • step S22 it is determined whether the currently valid record is the last record. If it is determined that the record is the last record, the process proceeds to step S23. If it is determined that the record is not the last record, the process returns to step S17. .
  • step S23 the verification table 600 is initialized, that is, the establishment time is deleted and the monitoring number is changed to “1”, and the flowchart of FIG. 7 is ended.
  • step S13 which is executed when a negative determination is made in step S14A, it is determined whether or not a timeout has occurred. If it is determined that a timeout has occurred, the process proceeds to step S18. If it is determined that a timeout has not occurred, the process returns to step S14A. In step S18, a time-out error, that is, a signal indicating detection of an abnormality that a time-out has occurred is output to the output unit 150, and the flowchart of FIG. 7 ends. When the execution of the flowchart of FIG. 7 ends, the CPU of the first ECU 100 executes the flowchart of FIG. 7 again.
  • the communication unit 110 transmits a data frame of “0x01” that is a CAN-ID of a record whose order is “1”, and this CAN-ID is input to the detection unit 140 (S21 in FIG. 7: YES). ), The monitoring number of the verification table 600 is updated to “2” (S17). Therefore, “0x02” described in the record whose order is “2” is specified as the OK determination ID (S11, S12A). Then, the loop of S14A and S13 is continued until the CAN-ID of “0x02” is input to the detection unit 140 or a timeout occurs.
  • the detection unit 140 includes a monitoring unit (S17, S11, S12A, S14A, S13 in FIG. 7), a monitoring start unit (S21 in FIG. 7), and a monitoring end unit (S22 in FIG. 7).
  • the monitoring unit transmits the first identifier described next to the first identifier in the monitoring condition table 500 by a predetermined timeout time.
  • communication data including two identifiers is not transmitted / received by the communication unit 110, it is determined that a communication abnormality has been detected.
  • the monitoring start unit starts the operation of the monitoring unit when communication data including the first identifier written in the monitoring condition table 500 is transmitted / received by the communication unit 110.
  • the monitoring end unit ends the operation of the monitoring unit.
  • the detection unit 140 may determine whether or not the received CAN-ID matches one CAN-ID (step S14A in FIG. 7), and a plurality of CAN-IDs as in the first embodiment. Therefore, the CPU processing load can be reduced. Note that the detection unit 140 may be able to select which of the method shown in the embodiment and the method in the first modification is adopted. The detection unit 140 selects the method shown in the embodiment when it is important to allow a point with a high processing load and quickly detect an abnormality, and to allow a point that requires time to detect the abnormality and to reduce the processing load. If importance is attached to this, the method shown in the first modification is selected.
  • FIG. 8 is a diagram illustrating an example of the monitoring condition table 500 in which the same order is assigned to a plurality of records.
  • the same order “2” is assigned to the second and third records.
  • the flag “CD5” is established, so the second and third records are valid.
  • a CAN-ID of “0x12” is input, a “CD6” flag is set.
  • a CAN-ID of “0x13” is input, a “CD7” flag is set. Since the trigger setting of the fourth record in FIG. 8 is “CD6 + CD7”, the fourth record is valid when both of these two flags are set. Note that whichever of these two flags may be enabled first.
  • FIG. 9 is a diagram illustrating an example of a verification table 600A having additional fields.
  • the verification table 600A has optional parameter fields in addition to the table number, establishment time, and monitoring number.
  • information indicating an established flag is stored when a plurality of records are specified from the description of the monitoring number field. For example, as shown in FIG. 8, when there are two records having the same order and the CD2 flag and the CD3 flag are set when the conditions of the respective records are satisfied, the following values are displayed in the option parameter field: Stored. That is, if no flag is set, “0x0000” is stored.
  • the trigger condition field of the monitoring condition table 500 may include a value condition included in the payload in addition to the CAN-ID value.
  • the monitoring condition table 500 also describes a combination of an identifier and a value condition stored in the payload of communication data and the identifier.
  • the detection unit 140 determines that a communication abnormality has been detected when the value stored in the payload of the communication data does not satisfy the conditions described in the monitoring condition table 500 in combination with the identifier included in the communication data. Therefore, the value stored in the payload can also be a monitoring target.
  • the storage unit 130 may include a plurality of monitoring condition tables 500.
  • the verification table 600 of the detection unit 140 has the same number of records as the monitoring condition table 500. Differences from the first embodiment in the operation of the detection unit 140 will be described for each step number in FIG.
  • step S14 it is determined whether or not the received ID matches an OK determination ID in any of the monitoring condition tables 500. If it is determined that it matches the OK determination ID of any monitoring condition table 500, the process proceeds to step S17. If it is determined that it does not match the OK determination ID of any monitoring condition table 500, the process proceeds to step S15. In step S15, it is determined whether or not the received ID matches the NG determination ID in any of the monitoring condition tables 500. When it is determined that it matches the NG determination ID of any of the monitoring condition tables 500, the process proceeds to step S16, and when it is determined that it does not match the OK determination ID of any of the monitoring condition tables 500, the flowchart of FIG.
  • the first embodiment described above may be further modified as follows.
  • the first ECU 100 may not include the control calculation unit 160. That is, the first ECU 100 may be an ECU that performs only monitoring.
  • the detection unit 140 may output without distinguishing between an error due to timeout and an error because the received CAN-ID is not in the prescribed order.
  • the first ECU 100 may include a fault mode for handling when an error is detected, and the fault mode may be validated when the detection unit 140 outputs an order error (step S16 in FIG. 6).
  • the fourth ECU 400 may accumulate a data frame indicating detection of the received abnormality and be readable from the outside. In this case, for example, a service person can communicate with the fourth ECU 400 to collect information on the abnormality.
  • the present invention may be applied to a network using a communication protocol other than CAN.
  • the present invention may be applied to a network that uses FlexRay as a communication protocol. In that case, the data frame ID in FlexRay corresponds to the CAN-ID in CAN.
  • the monitoring condition information stored in the storage unit 130 is not limited to the table format shown in FIGS. Further, the information for verification stored in the detection unit 140 is not limited to the table format as shown in FIGS. Any type of information may be stored in the storage unit 130 or the detection unit 140 as long as information necessary for the processing of the detection unit 140 is appropriately expressed.
  • the program is stored in a ROM (not shown) of the first ECU 100
  • the program may be stored in the storage unit 130.
  • the first ECU 100 may include an input / output interface (not shown), and a program may be read from another device via an input / output interface and a medium that can be used by the first ECU 100 when necessary.
  • the medium refers to, for example, a storage medium that can be attached to and detached from the input / output interface, or a communication medium, that is, a wired, wireless, or optical network, or a carrier wave or digital signal that propagates through the network.
  • part or all of the functions realized by the program may be realized by a hardware circuit or FPGA.
  • In-vehicle network 100 ... 1st ECU 110 . Communication unit 120 . Extraction unit 130 . Storage unit 140 . Detection unit 150 ... Output unit 500 ... Monitoring condition table

Abstract

演算装置は、通信データを送受信する演算装置であって、通信データの内容を示す識別子を含む通信データを送受信する通信部と、識別子の規定の順番が記された監視条件が格納される格納部と、通信の異常を検出する検出部とを備え、検出部は、通信部が送受信した複数の通信データの通信順序と、監視条件に記された識別子の規定の順番とに基づき、通信の異常を検出する。

Description

演算装置
　本発明は、演算装置に関する。
　電子化の進行により車両には多くの演算装置が搭載される。これらの演算装置は車載ネットワークにより接続され、様々な制御情報を交換することで車両の制御が実現されている。演算装置同士の通信に問題が発生すると車両の制御に影響が生じるので、通信に発生する問題の検出が求められる。特許文献１には、複数のノードが１回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、ノードが検出されない順位情報と共に記録する通信途絶検出手段を有するノード監視方法が開示されている。
日本国特開２０１２－８６６０１号公報
　特許文献１に記載されている発明では、周期的でない通信に発生する異常を検出できない。
　本発明の第１の態様による演算装置は、通信データを送受信する演算装置であって、前記通信データの内容を示す識別子を含む前記通信データを送受信する通信部と、前記識別子の規定の順番が記された監視条件が格納される格納部と、通信の異常を検出する検出部とを備え、前記検出部は、前記通信部が送受信した複数の前記通信データの通信順序と、前記監視条件に記された前記識別子の規定の順番とに基づき、通信の異常を検出する。
　本発明によれば、周期的でない通信の異常を検出することができる。
車載ネットワークの構成を示す図 車両のダッシュボードの一例を示す図 第１ＥＣＵの構成を示すブロック図 監視条件テーブルの一例を示す図 検証テーブルの一例を示す図 検出部が監視部からＣＡＮ－ＩＤを受信した際の動作を表すフローチャート 変形例１における検出部の動作を表すフローチャート 複数のレコードに同一の順序が付された監視条件テーブルの一例を示す図 付加的なフィールドを有する検証テーブルの一例を示す図
　以下、図１～図６を参照して、演算装置である第１ＥＣＵの第１の実施の形態を説明する。ＥＣＵは車両に搭載される。
（ネットワーク構成）
　図１は本発明にかかる第１ＥＣＵ１００が接続される車載ネットワーク２の構成を示す図である。車載ネットワーク２は、車両１に搭載される。車載ネットワーク２には、第１ＥＣＵ１００と、第２ＥＣＵ２００と、第３ＥＣＵ３００と、第４ＥＣＵ４００とが接続される。車載ネットワーク２には、不図示の他の装置も接続される。車載ネットワーク２は、通信プロトコルにＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）を使用する、いわゆるＣＡＮネットワークである。第１ＥＣＵ１００、第２ＥＣＵ２００、第３ＥＣＵ３００、および第４ＥＣＵ４００は、ＣＡＮの通信規約に沿った通信を行う。
　ＣＡＮネットワークにおいてやり取りされる通信データ、すなわちデータフレームは、ヘッダとペイロードとを含む。ヘッダにはＣＡＮ－ＩＤが含まれる。ＣＡＮ－ＩＤとはペイロードの種類、またはペイロードの内容を表す情報であり、ペイロードとは通信の目的となるデータである。
　第１ＥＣＵ１００、第２ＥＣＵ２００、第３ＥＣＵ３００、および第４ＥＣＵ４００はそれぞれ、ＣＡＮに対応する通信インタフェースと、ＣＰＵと、ＲＡＭと、ＲＯＭとを備える。ＣＰＵはＲＯＭに格納された不図示のプログラムをＲＡＭに展開して実行し、後述する動作を行う。
　第４ＥＣＵ４００は、異常表示部６１０を含むダッシュボードの表示制御を行う。ダッシュボードは異常表示部６１０に接続される。第４ＥＣＵ４００は異常の検知を示す所定のデータフレームを受信すると、異常表示部６１０に異常の発生を示す表示を表示させる。異常表示部６１０は、図２に示すように車両１のダッシュボード８００の一部であり、たとえば図２に示すように工具のアイコンを点灯させることにより、車両１の運転者に不具合の発生を通知する。
（動作の概要）
　前述の図１を用いて第１ＥＣＵ１００の動作の概要を説明する。第１ＥＣＵ１００には、ＥＣＵ同士の通信の順番が予め記憶されている。その順番とはたとえば以下のようなものである。まず第１ＥＣＵ１００から第２ＥＣＵ２００および第３ＥＣＵ３００宛ての通信が行われる（図１の“１”）。次に第２ＥＣＵ２００から第１ＥＣＵ１００宛ての通信が行われる（図１の“２”）。次に第３ＥＣＵ３００から第１ＥＣＵ１００宛ての通信が行われる（図１の“３”）。最後に第１ＥＣＵ１００から他の装置宛ての通信が行われる（図１の“４”）。
　第１ＥＣＵ１００は、通信が行われる順番を監視し、通信が上述した順番で行われていない場合、すなわち通信の順番が変わっている場合は異常が発生したと判断し、異常の発生を知らせる通信を行う。第４ＥＣＵ４００は、異常の発生を知らせる通信を受信すると異常表示部６１０に異常の発生を示す表示を表示させる。
（第１ＥＣＵの構成）
　図３は第１ＥＣＵ１００の構成を示すブロック図である。第１ＥＣＵ１００は、その機能として、通信部１１０と、抽出部１２０と、格納部１３０と、検出部１４０と、出力部１５０と、制御演算部１６０を備える。
　通信部１１０は、ＣＡＮに対応する通信インタフェースであり、車載ネットワーク２へのデータフレームの送信、および車載ネットワーク２からのデータフレームの受信を行う。通信部１１０が送信または受信したデータフレームの情報は、抽出部１２０および制御演算部１６０に出力される。
　抽出部１２０は、通信部１１０から入力されたデータフレームの情報からＣＡＮ－ＩＤを抽出し、抽出したＣＡＮ－ＩＤを検出部１４０に出力する。
　格納部１３０には、監視条件テーブル５００が格納される。格納部１３０は、監視条件テーブル５００を検出部１４０に提供する。監視条件テーブル５００の構成は後に詳述する。検出部１４０は、格納部１３０から監視条件テーブル５００を取得し、抽出部１２０から入力されたＣＡＮ－ＩＤの情報に基づいて、通信部１１０が送信または受信したデータフレームの順番が、監視条件テーブル５００に記載された順番に合致するか検証する。検出部１４０は、この検証に利用する検証テーブル６００を備える。この検証により、通信部１１０が送信または受信したデータフレームの通信順序が監視条件テーブル５００に記載された識別子の順番に合致しないと判断すると、出力部１５０に異常の検知を示す信号を出力する。検出部１４０の動作、および検証テーブル６００の構成は後に詳述する。
　出力部１５０は、検出部１４０から異常の検知を示す信号が入力されると、あらかじめ定められたデータフレームを生成して通信部１１０に送信させる。このデータフレームによる他の装置への影響は後述する。
　制御演算部１６０は、あらかじめ定められた手順にしたがって、他のＥＣＵや他の装置と通信を行うためのデータフレームを生成し、通信部１１０に送信させる。たとえば制御演算部１６０は、あらかじめ定められた時間の周期でデータフレームを生成して通信部１１０に送信させる。また制御演算部１６０は、受信したデータフレームのペイロードを用いて演算を行い、演算結果をペイロードに含むデータフレームを生成して通信部１１０に送信させる。なお抽出部１２０、格納部１３０、および検出部１４０は連携して動作するが、これらと制御演算部１６０の動作は独立している。
（監視条件テーブル）
　図４は、監視条件テーブル５００の一例を示す図である。監視条件テーブル５００は、２以上のレコードから構成される。監視条件テーブル５００の各レコードは、順序、前提フラグ、条件、タイムアウト、および成立時フラグの５つのフィールドを有する。
　順序のフィールドには、この監視条件テーブル５００において条件が成立する順番、換言すると正常な通信の順序を示す情報が格納される。順序のフィールドには、たとえば１以上の整数が格納され、少なくとも「１」と「２」が格納される。図４に示す例では４つのレコードにそれぞれ異なる値が格納されているので、４つの条件が１つずつ順番に成立するのが正常であることがわかる。
　前提フラグのフィールドには、当該レコードが有効になる前提となるフラグが記載される。たとえば図４の１番目のレコードは前提フラグが不要であり常時有効であることを示している。また図４の２番目のレコードは「ＣＤ１」というフラグが設定された際に有効になることを示している。
　条件のフィールドには、当該レコードにおいて評価される条件が格納される。本実施の形態における条件は、検知したデータフレームのＣＡＮ－ＩＤが特定の値と一致することである。たとえば図４の１番目のレコードの条件は、通信部１１０が送信または受信したデータフレームのＣＡＮ－ＩＤが「０ｘ０１」であることを示している。
　タイムアウトのフィールドには、タイムアウト時間が格納される。当該フィールドが有効になってからタイムアウトのフィールドに記載された時間が経過すると、通信部１１０が条件を満たさないデータフレームを送信または受信した場合と同様に処理される。ただし図４の１番目のレコードのように、タイムアウトのフィールドに無限大が格納されているレコードについては、タイムアウトは発生しないものとして扱われる。図４の２番目のレコードでは、タイムアウトのフィールドに「２００マイクロ秒」が格納されているので、直前の条件である１番目のレコードの条件が成立したとき、すなわちＣＡＮ－ＩＤが「０ｘ１１」のデータフレームを通信部１１０が送信または受信したときから、２００マイクロ秒経過するとタイムアウトと判断される。
　成立時フラグのフィールドには、当該レコードの条件のフィールドに記載された条件が成立した際に設定されるフラグが格納される。たとえば図４の１番目のレコードに記載の条件が成立すると、「ＣＤ１」のフラグが設定される。
（検証テーブル）
　図５は、検証テーブル６００の一例を示す図である。検証テーブル６００は、１以上のレコードから構成される。検証テーブル６００の各レコードは、テーブル番号、成立時刻、監視番号、の３つのフィールドを有する。検証テーブル６００を構成するレコード数は、格納部１３０に格納される監視条件テーブル５００の数と同一である。検証テーブル６００は検出部１４０により編集される。
　テーブル番号のフィールドには、それぞれの監視条件テーブルを識別する識別子、すなわちテーブル番号が格納される。成立時刻のフィールドには、最新の条件が成立した時刻が格納される。監視番号のフィールドには、現在有効なレコードの「順序」を表す番号が格納される。監視番号のフィールドの初期値は「１」である。
　以上の説明をまとめると、図５に例示した検証テーブル６００は以下のことを表している。ただしここでは、テーブル番号「１」が図４に示した監視条件テーブル５００に対応することとする。
　図５に例示した検証テーブル６００の監視番号のフィールドが「２」なので、監視条件テーブル５００の順序が「２」のレコードが有効である。また成立時刻のフィールドに格納された「０：０１：２３．４５６」に最新の条件が成立した、すなわち順序が「１」のレコードの条件が成立したことが示されている。換言すると通信部１１０が０ｘ０１のＣＡＮ－ＩＤをヘッダに含むデータフレームを送信または受信した時刻が「０：０１：２３．４５６」である。
（検出部の動作）
　検出部１４０は、通信部１１０が送信または受信したデータフレームのＣＡＮ－ＩＤが抽出部１２０から入力されると、検証テーブル６００を参照してそれぞれの監視条件テーブル５００における監視番号、すなわち有効なレコードの順序の値を特定する。次に検出部１４０は、格納部１３０に格納される監視条件テーブル５００を参照し、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定する。ＯＫ判断ＩＤとは通信部１１０が次に送信または受信することが期待されるＣＡＮ－ＩＤであり、有効なレコードにおいてトリガ条件のフィールドに記載されるＣＡＮ－ＩＤである。ＮＧ判断ＩＤとは通信部１１０が次回以降に送信または受信することが期待されるＣＡＮ－ＩＤであり、監視条件テーブル５００における有効なレコードの次以降のレコードにおいて条件のフィールドに記載されるＣＡＮ－ＩＤである。
　たとえば図４～図５に示す例におけるＯＫ判断ＩＤとＮＧ判断ＩＤは以下のように特定される。図５に示す検証テーブル６００では監視番号のフィールドに「２」が格納されているので２番目のレコードが有効であり、監視条件テーブル５００における２番目のレコードに記載の「０ｘ０２」がＯＫ判断ＩＤとして特定される。また、２番目のレコードの次以降のレコード、すなわち３番目と４番目のレコードに記載の「０ｘ０３、０ｘ０４」がＮＧ判断ＩＤとして特定される。
　検出部１４０は、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定すると、抽出部１２０から入力されたＣＡＮ－ＩＤがＯＫ判断ＩＤと一致するか否か、ＮＧ判断ＩＤと一致するか否かを判断する。ＯＫ判断ＩＤと一致すると判断する場合は、検証テーブル６００を更新する。ＮＧ判断ＩＤと一致すると判断する場合は、通信の順序が異なるという異常の検知を示す信号を出力部１５０に出力する。いずれにも一致しないと判断する場合は、何も処理を行わない。ただし検証テーブル６００の成立時刻のフィールドの時刻に監視条件テーブル５００のタイムアウトのフィールドの時間を加えた時刻が現在時刻と比較して過去であれば、タイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力する。
　検出部１４０による検証テーブル６００の更新は以下のとおりである。すなわち、成立時刻のフィールドの値が現在時刻に更新され、監視番号のフィールドの値が１増加した値に更新される。なお、監視番号のフィールドの値の更新の詳細は次のとおりである。監視条件テーブル５００の２番目のレコードの条件が成立した場合は、２行目の成立時フラグのフィールドに記載されたフラグ「ＣＤ２」が設定される。そして監視条件テーブル５００において前提フラグのフィールドの値が「ＣＤ２」である３番目のレコードが有効化されるので、検証テーブル６００の監視番号のフィールドの値が「３」に更新される。
（検出部のフローチャート）
　図６は検出部１４０が抽出部１２０からＣＡＮ－ＩＤを入力された際の動作を表すフローチャートである。以下に説明する各ステップの実行主体は第１ＥＣＵ１００のＣＰＵである。
　ステップＳ１１では、検証テーブル６００の監視番号のフィールドの値、すなわち監視条件テーブル５００における有効なレコードの番号を特定する。続くステップＳ１２では、監視条件テーブル５００における有効なレコード、および次以降のレコードを参照し、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定する。続くステップＳ１３では、タイムアウトが発生しているか否かを判断する。タイムアウトが発生していると判断する場合はステップＳ１８に進み、タイムアウトが発生していないと判断する場合はステップＳ１４に進む。
　ステップＳ１４では、入力されたＣＡＮ－ＩＤがＯＫ判断ＩＤと一致するか否かを判断する。ＯＫ判断ＩＤと一致すると判断する場合はステップＳ１７に進み、一致しないと判断する場合はステップＳ１５に進む。
　ステップＳ１５では、入力されたＣＡＮ－ＩＤがＮＧ判断ＩＤと一致するか否かを判断する。ＮＧ判断ＩＤと一致すると判断する場合はステップＳ１６に進み、一致しないと判断する場合は図７のフローチャートを終了する。
　ステップＳ１６では、通信の順序が異なるという異常の検知を示す信号を出力部１５０に出力し、図６のフローチャートを終了する。ステップＳ１７では、検証テーブル６００を更新し、図６のフローチャートを終了する。ステップＳ１８では、タイムアウトのエラー、すなわちタイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力して、図６のフローチャートを終了する。
　上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）演算装置、すなわち第１ＥＣＵ１００は、ヘッダに通信データの内容を示す識別子、すなわちＣＡＮ－ＩＤを含む通信データを受信する通信部１１０と、識別子の規定の順番が記された監視条件テーブル５００が格納される格納部１３０と、通信の異常を検出する検出部１４０とを備える。検出部１４０は、通信部１１０が送受信した複数の通信データの通信順序と、監視条件テーブル５００に記された識別子の規定の順番とに基づき、通信の異常を検出する。
　第１ＥＣＵ１００は、データフレームのヘッダに格納されるＣＡＮ－ＩＤに着目し、送受信するデータフレームの通信順序に応じたＣＡＮ－ＩＤの順番が監視条件テーブル５００に記された識別子の順番と一致しない場合に通信の異常を検出する。そのため第１ＥＣＵ１００は、周期的でない通信でも通信の異常を検出することができる。
（２）検出部１４０は、監視条件テーブル５００に含まれる識別子、たとえば図４の例におけるＣＡＮ－ＩＤ「０ｘ０１」、「０ｘ０２」、「０ｘ０３」、「０ｘ０４」をそれぞれ含む通信データが、監視条件テーブル５００に記された順番とは異なる通信順序、たとえば「０ｘ０１，０ｘ０２，０ｘ０４，０ｘ０３」の順で通信部１１０に送受信されたと判断すると通信の異常を検出したと判断する。そのため、通信データの順番が入れ替わって受信した場合に迅速に通信の異常を検出することができる。
（３）検出部１４０は、監視条件テーブル５００に記された第１識別子を含む通信データが通信部１１０により送受信されると、監視条件テーブル５００における第１識別子の次に記載された第２識別子を含む通信データが既定のタイムアウト時間までに通信部１１０により送受信されない場合に通信の異常を検出したと判断する。そのため、通信の順序が入れ替わった場合だけでなく、既定の時間よりも通信の間隔が長い場合に通信の異常として検出することができる。
（４）通信データはＣＡＮプロトコルにしたがったデータフレームであり、識別子はＣＡＮ－ＩＤである。ＣＡＮではバス型のネットワークトポロジが採用されているので、第１ＥＣＵ１００は同一ネットワーク内の通信をすべて受信することができる。したがって、通信データが送信された順序をもれなく把握することができる。
（変形例１）
　上述した実施の形態における検出部１４０の動作を以下のように変更してもよい。
　図７は、変形例１における検出部１４０の動作を表すフローチャートである。図６と同一の動作を行う処理ステップには同一のステップ番号を付している。以下に説明する各ステップの実行主体は第１ＥＣＵ１００のＣＰＵである。
　検出部１４０は、第１ＥＣＵ１００が起動すると動作を開始する。ステップＳ２１では、監視条件テーブル５００における順序が「１」のレコードにおいてトリガ条件のフィールドに記載されるＣＡＮ－ＩＤが抽出部１２０から入力されたか否かを判断する。入力されたと判断する場合はステップＳ１７に進み、入力されていないと判断する場合はステップＳ２１に留まる。
　ステップＳ１７では、現状の検証テーブル６００の記述と、受信したＣＡＮ－ＩＤに基づき検証テーブル６００を更新し、ステップＳ１１に進む。ステップＳ１１では検証テーブル６００の記述に基づき、監視条件テーブル５００において有効なレコードの番号を特定する。続くステップＳ１２Ａでは、ＯＫ判断ＩＤを特定する。続くステップＳ１４Ａでは、ＯＫ判断ＩＤが入力されたか否かを判断し、入力されたと判断する場合はステップＳ２２に進み、入力されていないと判断する場合はステップＳ１３に進む。ステップＳ１４Ａにおいて否定判断される場合は、通信部１１０が何も受信していない場合、およびＯＫ判断ＩＤ以外のＣＡＮ－ＩＤを有するデータフレームを受信した場合である。
　ステップＳ２２では、現在有効なレコードが最後のレコードであるか否かを判断し、最後のレコードであると判断する場合はステップＳ２３に進み、最後のレコードではないと判断する場合はステップＳ１７に戻る。ステップＳ２３では、検証テーブル６００の初期化、すなわち成立時刻の削除および監視番号の「１」への変更を行い、図７のフローチャートを終了する。
　ステップＳ１４Ａにおいて否定判断されると実行されるステップＳ１３では、タイムアウトが発生したか否かを判断する。タイムアウトが発生したと判断する場合はステップＳ１８に進み、タイムアウトが発生していないと判断する場合はステップＳ１４Ａに戻る。ステップＳ１８ではタイムアウトのエラー、すなわちタイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力して、図７のフローチャートを終了する。
　第１ＥＣＵ１００のＣＰＵは、図７のフローチャートの実行が終了すると、再び図７のフローチャートを実行する。
（動作例）
　監視条件テーブル５００が図４に示すものである場合に、「０ｘ０２」と「０ｘ０３」のＣＡＮ－ＩＤの通信の順番が入れ替わり、通信部１１０が送受信したデータフレームのＣＡＮ－ＩＤの順番が「０ｘ０１，０ｘ０３，０ｘ０２，０ｘ０４」である場合に以下のようにエラーが検出される。
　まず通信部１１０により、順序が「１」であるレコードのＣＡＮ－ＩＤである「０ｘ０１」のデータフレームが送信され、このＣＡＮ－ＩＤが検出部１４０に入力されると（図７のＳ２１：ＹＥＳ）、検証テーブル６００の監視番号が「２」に更新される（Ｓ１７）。したがって順序が「２」であるレコードに記載された「０ｘ０２」がＯＫ判断ＩＤとして特定される（Ｓ１１，Ｓ１２Ａ）。すると、「０ｘ０２」のＣＡＮ－ＩＤが検出部１４０に入力されるかタイムアウトが発生するまで、Ｓ１４ＡとＳ１３のループが継続される。
　そのため通信部１１０が「０ｘ０３」のＣＡＮ－ＩＤのデータフレームを受信し、このＣＡＮ－ＩＤが検出部１４０に入力されると、Ｓ１４Ａで否定判断される。その次に通信部１１０が「０ｘ０２」のＣＡＮ－ＩＤのデータフレームを受信すると、Ｓ１４Ａで肯定判断され最後のレコードではないのでＳ１７に戻り、検証テーブル６００の監視番号が「３」に更新される。そのため次は「０ｘ０３」がＯＫ判断ＩＤとして特定され（Ｓ１１，Ｓ１２Ａ）、Ｓ１４Ａでは「０ｘ０３」のＣＡＮ－ＩＤが検出部１４０に入力されるのを待ち続ける。しかし、次に通信部１１０が送信するデータフレームのＣＡＮ－ＩＤは最後の「０ｘ０４」なので、検出部１４０に「０ｘ０３」のＣＡＮ－ＩＤが入力されることはなく、タイムアウトエラーが出力される（Ｓ１３：ＹＥＳ，Ｓ１８）。
　この変形例１によれば、次の作用効果が得られる。
（１）検出部１４０は、監視部（図７のＳ１７，Ｓ１１，Ｓ１２Ａ，Ｓ１４Ａ，Ｓ１３）と監視開始部（図７のＳ２１）と監視終了部（図７のＳ２２）とを含む。監視部は、監視条件テーブル５００に記された第１識別子を含む通信データが通信部１１０により送受信されると、既定のタイムアウト時間までに監視条件テーブル５００における第１識別子の次に記載された第２識別子を含む通信データが通信部１１０により送受信されない場合に通信の異常を検出したと判断する。監視開始部は、監視条件テーブル５００に記された先頭の識別子を含む通信データが通信部１１０により送受信されると監視部の動作を開始させる。監視終了部は、監視条件テーブル５００に記された末尾の識別子を含む通信データが通信部１１０により送受信されると監視部の動作を終了させる。
　検出部１４０は、受信するＣＡＮ－ＩＤかある１つのＣＡＮ－ＩＤと一致するか否かを判断すればよく（図７のステップＳ１４Ａ）、第１の実施の形態のように複数のＣＡＮ－ＩＤとの一致を判断する必要がないので、ＣＰＵの処理負荷を軽くすることができる。
　なお検出部１４０は、実施の形態に示した手法と変形例１における方法とのいずれの方法を採用するかを選択可能であってもよい。検出部１４０は、処理負荷が高い点を許容し迅速に異常を検出することを重視する場合は実施の形態に示した手法を選択し、異常検出に時間を要する点を許容し処理負荷が低いことを重視する場合は変形例１に示した手法を選択する。
（変形例２）
　監視条件テーブル５００の複数のレコードに、同一の順序が付与されてもよい。
　図８は、複数のレコードに同一の順序が付された監視条件テーブル５００の一例を示す図である。図８に示す例では、２番目と３番目のレコードに同一の「２」の順序が付されている。検出部１４０に「０ｘ１１」のＣＡＮ－ＩＤが入力されると、「ＣＤ５」のフラグが成立するので、２番目と３番目のレコードが有効となる。そして「０ｘ１２」のＣＡＮ－ＩＤが入力されると「ＣＤ６」のフラグが設定され、「０ｘ１３」のＣＡＮ－ＩＤが入力されると「ＣＤ７」のフラグが設定される。
　図８の４番目のレコードはトリガ設定が「ＣＤ６＋ＣＤ７」なので、これら２つのフラグが両方とも設定されている場合に４番目のレコードが有効となる。なおこの２つのフラグはどちらが先に有効にされてもかまわない。
　また監視条件テーブル５００の複数のレコードに同一の順序が付与されている場合は、検証テーブルが付加的なフィールドを有する。
　図９は、付加的なフィールドを有する検証テーブル６００Ａの一例を示す図である。検証テーブル６００Ａは、テーブル番号、成立時刻、監視番号に加えて、オプションパラメータのフィールドを有する。オプションパラメータのフィールドには、監視番号のフィールドの記載から複数のレコードが特定される場合に、成立済みのフラグを示す情報が格納される。たとえば図８に示すように同一の順序を有する２つのレコードがあり、それぞれのレコードの条件が成立するとＣＤ２のフラグとＣＤ３のフラグが設定される場合に、オプションパラメータのフィールドには以下の値が格納される。すなわち、いずれのフラグも設定されていない場合は「０ｘ００００」が格納され、ＣＤ２のフラグのみが設定されると「０ｘ０００２」が格納され、さらにＣＤ３のフラグも設定されると次のフィールドが有効になるので「０ｘ００００」が格納される。
　この変形例２によれば、通信の順序の入れ替わりを許容する柔軟な監視条件を設定することができる。
（変形例３）
　監視条件テーブル５００のトリガ条件のフィールドには、ＣＡＮ－ＩＤの値に加えてペイロードに含まれる値の条件が含まれてもよい。データフラグのペイロードには各種の値、たとえばエンジン回転数や排気ガスの温度が含まれる。それらの値はそれぞれ通常とりうる値の範囲が想定されるので、その範囲を条件としてトリガ条件のフィールドに含める。たとえばＣＡＮ－ＩＤが「０ｘ３０」のデータフラグのペイロードにはエンジン回転数Ｒの情報が格納され、その値がＲ１からＲ２の間であることを条件とする場合にトリガ条件のフィールドには「ＣＡＮ－ＩＤ＝０ｘ３０、Ｒ１＜Ｒ＜Ｒ２」という情報が格納される。
　この変形例３によれば、次の作用効果が得られる。
（１）監視条件テーブル５００には、識別子と通信データのペイロードに格納される値の条件と識別子との組み合わせも記載される。検出部１４０は、通信データのペイロードに格納される値が、当該通信データに含まれる識別子と組み合わせて監視条件テーブル５００に記載される条件を満たさない場合に通信の異常を検出したと判断する。
　そのため、ペイロードに格納された値も監視対象とすることができる。
（変形例４）
　格納部１３０には、複数の監視条件テーブル５００が備えられてもよい。この場合、検出部１４０の検証テーブル６００は、監視条件テーブル５００と同数のレコードを有する。検出部１４０の動作における第１の実施の形態との相違点を図６のステップ番号ごとに説明する。
　図６のステップＳ１１およびＳ１２では、検出部１４０はそれぞれの監視条件テーブル５００を対象として処理を行う。ステップＳ１３、Ｓ１６、およびＳ１８の処理は第１の実施の形態と同様である。ステップＳ１４では、受信したＩＤがいずれかの監視条件テーブル５００のＯＫ判断ＩＤと一致するか否かを判断する。いずれかの監視条件テーブル５００のＯＫ判断ＩＤと一致すると判断する場合はステップＳ１７に進み、いずれの監視条件テーブル５００のＯＫ判断ＩＤとも一致しないと判断する場合はステップＳ１５に進む。ステップＳ１５では、受信したＩＤがいずれかの監視条件テーブル５００のＮＧ判断ＩＤと一致するか否かを判断する。いずれかの監視条件テーブル５００のＮＧ判断ＩＤと一致すると判断する場合はステップＳ１６に進み、いずれの監視条件テーブル５００のＯＫ判断ＩＤとも一致しないと判断する場合は図６のフローチャートを終了する。
（変形例）
　上述した第１の実施の形態をさらに以下のように変形してもよい。
（１）第１ＥＣＵ１００は、制御演算部１６０を備えなくてもよい。すなわち第１ＥＣＵ１００は、監視のみを行うＥＣＵでもよい。
（２）検出部１４０は、タイムアウトによるエラーと、受信したＣＡＮ－ＩＤが規定されていた順番ではないためのエラーとを区別せずに出力してもよい。
（３）第１ＥＣＵ１００はエラーが検出された際の対応を行うフォルトモードを備え、検出部１４０が順序のエラーを出力した場合（図６のステップＳ１６）に、フォルトモードを有効にしてもよい。
（４）第４ＥＣＵ４００は、受信した異常の検知を示すデータフレームを蓄積し、外部から読出し可能であってもよい。この場合は、たとえばサービスマンなどが第４ＥＣＵ４００と通信を行い異常に関する情報を収集することができる。
（５）本発明を通信プロトコルにＣＡＮ以外を使用するネットワークに適用してもよい。たとえば通信プロトコルにＦｌｅｘＲａｙを使用するネットワークに適用してもよい。その場合は、ＦｌｅｘＲａｙにおけるデータフレームＩＤがＣＡＮにおけるＣＡＮ－ＩＤに相当する。
（６）格納部１３０に格納される監視条件の情報は、図４や図８に示したようなテーブル形式のものに限らない。また、検出部１４０に格納される検証のための情報も、図５や図９に示したようなテーブル形式のものに限らない。検出部１４０の処理において必要な情報が適切に表されていれば、格納部１３０や検出部１４０にどのような形式の情報を格納してもよい。
　プログラムは第１ＥＣＵ１００の不図示のＲＯＭに格納されるとしたが、プログラムは格納部１３０に格納されていてもよい。また、第１ＥＣＵ１００が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースと第１ＥＣＵ１００が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。
　上述した実施の形態および変形例は、それぞれ組み合わせてもよい。
　上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。
　次の優先権基礎出願の開示内容は引用文としてここに組み込まれる。
　日本国特許出願２０１６年第１３９２１０号（２０１６年７月１４日出願）
　　　２　…　車載ネットワーク
　１００　…　第１ＥＣＵ
　１１０　…　通信部
　１２０　…　抽出部
　１３０　…　格納部　
　１４０　…　検出部
　１５０　…　出力部
　５００　…　監視条件テーブル

Claims (6)

  1. 　通信データを送受信する演算装置であって、
    　前記通信データの内容を示す識別子を含む前記通信データを送受信する通信部と、
    　前記識別子の規定の順番が記された監視条件が格納される格納部と、
    　通信の異常を検出する検出部とを備え、
    　前記検出部は、前記通信部が送受信した複数の前記通信データの通信順序と、前記監視条件に記された前記識別子の規定の順番とに基づき、通信の異常を検出する演算装置。
  2. 　請求項１に記載の演算装置において、
    　前記検出部は、前記識別子をそれぞれ含む複数の前記通信データが、前記規定の順番とは異なる通信順序で前記通信部に送受信された場合に通信の異常を検出したと判断する演算装置。
  3. 　請求項２に記載の演算装置において、
    　前記識別子は、第１識別子と、前記規定の順番が前記第１識別子の次である第２識別子とを含み、
    　前記検出部は、前記第１識別子を含む前記通信データが前記通信部により送受信されると、前記第２識別子を含む前記通信データが既定のタイムアウト時間までに前記通信部により送受信されない場合に通信の異常を検出したと判断する演算装置。
  4. 　請求項１に記載の演算装置において、
    　前記検出部は、監視部と監視開始部と監視終了部とを含み、
    　前記識別子は、第１識別子と、前記規定の順番が前記第１識別子の次である第２識別子とを含み、
    　前記監視部は、前記第１識別子を含む前記通信データが前記通信部により送受信されると、前記第２識別子を含む前記通信データが既定のタイムアウト時間までに前記通信部により送受信されない場合に通信の異常を検出したと判断し、
    　前記監視開始部は、前記規定の順番が先頭の前記識別子を含む前記通信データが前記通信部により送受信されると前記監視部の動作を開始させ、
    　前記監視終了部は、前記規定の順番が末尾の前記識別子を含む前記通信データが前記通信部により送受信されると前記監視部の動作を終了させる演算装置。
  5. 　請求項１に記載の演算装置において、
    　前記監視条件には、前記識別子と前記通信データのペイロードに格納される値の条件との組み合わせも記載され、
    　前記検出部は、前記通信データのペイロードに格納される値が、当該通信データに含まれる前記識別子と組み合わせて前記監視条件に記載される前記条件を満たさない場合に通信の異常を検出したと判断する演算装置。
  6. 　請求項１に記載の演算装置において、
    　前記通信データはＣＡＮプロトコルにしたがったデータフレームであり、
    　前記識別子はＣＡＮ－ＩＤである演算装置。
     
PCT/JP2017/024153 2016-07-14 2017-06-30 演算装置 WO2018012322A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016139210A JP6674854B2 (ja) 2016-07-14 2016-07-14 演算装置
JP2016-139210 2016-07-14

Publications (1)

Publication Number Publication Date
WO2018012322A1 true WO2018012322A1 (ja) 2018-01-18

Family

ID=60952036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/024153 WO2018012322A1 (ja) 2016-07-14 2017-06-30 演算装置

Country Status (2)

Country Link
JP (1) JP6674854B2 (ja)
WO (1) WO2018012322A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020162075A1 (ja) * 2019-02-08 2020-08-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常判定方法、異常判定装置およびプログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7011983B2 (ja) * 2018-07-11 2022-01-27 日立Astemo株式会社 演算システム、演算装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6080338A (ja) * 1983-10-07 1985-05-08 Fujitsu Ltd バス監視回路
JP2013187555A (ja) * 2012-03-05 2013-09-19 Auto Network Gijutsu Kenkyusho:Kk 通信システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6080338A (ja) * 1983-10-07 1985-05-08 Fujitsu Ltd バス監視回路
JP2013187555A (ja) * 2012-03-05 2013-09-19 Auto Network Gijutsu Kenkyusho:Kk 通信システム

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020162075A1 (ja) * 2019-02-08 2020-08-13 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 異常判定方法、異常判定装置およびプログラム
CN112889246A (zh) * 2019-02-08 2021-06-01 松下电器（美国）知识产权公司 异常判定方法、异常判定装置以及程序
US11516045B2 (en) 2019-02-08 2022-11-29 Panasonic Intellectual Property Corporation Of America Anomaly determination method, anomaly determination device, and recording medium
CN112889246B (zh) * 2019-02-08 2023-09-22 松下电器（美国）知识产权公司 异常判定方法、异常判定装置以及程序
US11843477B2 (en) 2019-02-08 2023-12-12 Panasonic Intellectual Property Corporation Of America Anomaly determination method, anomaly determination device, and recording medium

Also Published As

Publication number Publication date
JP2018011214A (ja) 2018-01-18
JP6674854B2 (ja) 2020-04-01

Similar Documents

Publication Publication Date Title
JP7008100B2 (ja) 不正対処方法、不正検知電子制御ユニットおよびネットワーク通信システム
EP3358788B1 (en) Illegality detection electronic control unit, vehicle onboard network system, and communication method
JP5637190B2 (ja) 通信システム及び通信方法
US11838303B2 (en) Log generation method, log generation device, and recording medium
JP2008028801A (ja) 運用管理システム、ノード、運用管理方法及びプログラム
JPWO2019093098A1 (ja) 情報処理装置、移動装置、および方法、並びにプログラム
WO2018012322A1 (ja) 演算装置
EP3799364A1 (en) Communication control device, unauthorized access-detecting electronic control unit, mobility network system, communication control method, unauthorized access detection method and program
WO2016080417A1 (ja) ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）通信システム及びエラー情報記録装置
JP6115148B2 (ja) 警報管理装置、通信装置、警報制御装置、警報管理方法、通信方法、警報制御方法、警報管理プログラム、通信プログラム、及び警報制御プログラム
JP6508092B2 (ja) 車両用ゲートウェイ装置及びプログラム
JP2020092379A (ja) 監視装置
JP4624443B2 (ja) ネットワーク機器設定方法
JP4808187B2 (ja) 経路切替方法及び装置
JP6294741B2 (ja) 制御システム、中継装置、および制御方法
US10459816B2 (en) Communication setting notification apparatus
US10862759B2 (en) Communication network determination apparatus, communication network determination method, and recording medium having communication network determination program recorded therein
KR20180058537A (ko) 차량 내 통신 보안 제공 방법 및 장치
JP6497142B2 (ja) 通信監視装置、通信監視プログラム、および通信監視方法
WO2018101070A1 (ja) 異常判定装置、異常判定方法、及び異常判定プログラムが記録された記憶媒体
JP2020150442A (ja) ゲートウェイ装置
JPWO2010098300A1 (ja) 通信ネットワーク管理システム、方法、及び管理計算機
EP3461102B1 (en) Notification control device, notification control system, notification control method, and storage medium
JP4760745B2 (ja) ネットワーク管理装置及びプログラム
US20040213236A1 (en) Data transmission system, data transmission method, and data transmission aparatus

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: 17827452

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17827452

Country of ref document: EP

Kind code of ref document: A1