JP2018011214A - 演算装置 - Google Patents

Abstract

【課題】周期的でない通信でも通信の異常を検出することができる。
【解決手段】演算装置は、通信データを送受信する演算装置であって、通信データの内容を示す識別子を含む通信データを送受信する通信部と、識別子の規定の順番が記された監視条件が格納される格納部と、通信の異常を検出する検出部とを備え、検出部は、通信部が送受信した複数の通信データの通信順序と、監視条件に記された識別子の規定の順番とに基づき、通信の異常を検出する。
【選択図】図３

Description

本発明は、演算装置に関する。

電子化の進行により車両には多くの演算装置が搭載される。これらの演算装置は車載ネットワークにより接続され、様々な制御情報を交換することで車両の制御が実現されている。演算装置同士の通信に問題が発生すると車両の制御に影響が生じるので、通信に発生する問題の検出が求められる。特許文献１には、複数のノードが１回以上メッセージを送信する略一定時間毎に、複数のノードの通信有無を監視して、前記略一定時間内に通信が検出されないノードを、ノードが検出されない順位情報と共に記録する通信途絶検出手段を有するノード監視方法が開示されている。

特開２０１２−８６６０１号公報

特許文献１に記載されている発明では、周期的でない通信に発生する異常を検出できない。

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

本発明によれば、周期的でない通信の異常を検出することができる。

車載ネットワークの構成を示す図 車両のダッシュボードの一例を示す図 第１ＥＣＵの構成を示すブロック図 監視条件テーブルの一例を示す図 検証テーブルの一例を示す図 検出部が監視部からＣＡＮ−ＩＤを受信した際の動作を表すフローチャート 変形例１における検出部の動作を表すフローチャート 複数のレコードに同一の順序が付された監視条件テーブルの一例を示す図 付加的なフィールドを有する検証テーブルの一例を示す図

以下、図１〜図６を参照して、演算装置である第１ＥＣＵの第１の実施の形態を説明する。ＥＣＵは車両に搭載される。

（ネットワーク構成）
図１は本発明にかかる第１ＥＣＵ１００が接続される車載ネットワーク２の構成を示す図である。車載ネットワーク２は、車両１に搭載される。車載ネットワーク２には、第１ＥＣＵ１００と、第２ＥＣＵ２００と、第３ＥＣＵ３００と、第４ＥＣＵ４００とが接続される。車載ネットワーク２には、不図示の他の装置も接続される。車載ネットワーク２は、通信プロトコルにＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）を使用する、いわゆるＣＡＮネットワークである。第１ＥＣＵ１００、第２ＥＣＵ２００、第３ＥＣＵ３００、および第４ＥＣＵ４００は、ＣＡＮの通信規約に沿った通信を行う。

ＣＡＮネットワークにおいてやり取りされる通信データ、すなわちデータフレームは、ヘッダとペイロードとを含む。ヘッダにはＣＡＮ−ＩＤが含まれる。ＣＡＮ−ＩＤとはペイロードの種類、またはペイロードの内容を表す情報であり、ペイロードとは通信の目的となるデータである。
第１ＥＣＵ１００、第２ＥＣＵ２００、第３ＥＣＵ３００、および第４ＥＣＵ４００はそれぞれ、ＣＡＮに対応する通信インタフェースと、ＣＰＵと、ＲＡＭと、ＲＯＭとを備える。ＣＰＵはＲＯＭに格納された不図示のプログラムをＲＡＭに展開して実行し、後述する動作を行う。

第４ＥＣＵ４００は、異常表示部６１０を含むダッシュボードの表示制御を行う。ダッシュボードは異常表示部６１０に接続される。第４ＥＣＵ４００は異常の検知を示す所定のデータフレームを受信すると、異常表示部６１０に異常の発生を示す表示を表示させる。異常表示部６１０は、図２に示すように車両１のダッシュボード８００の一部であり、たとえば図２に示すように工具のアイコンを点灯させることにより、車両１の運転者に不具合の発生を通知する。

（動作の概要）
前述の図１を用いて第１ＥＣＵ１００の動作の概要を説明する。第１ＥＣＵ１００には、ＥＣＵ同士の通信の順番が予め記憶されている。その順番とはたとえば以下のようなものである。まず第１ＥＣＵ１００から第２ＥＣＵ２００および第３ＥＣＵ３００宛ての通信が行われる（図１の“１”）。次に第２ＥＣＵ２００から第１ＥＣＵ１００宛ての通信が行われる（図１の“２”）。次に第３ＥＣＵ３００から第１ＥＣＵ１００宛ての通信が行われる（図１の“３”）。最後に第１ＥＣＵ１００から他の装置宛ての通信が行われる（図１の“４”）。

第１ＥＣＵ１００は、通信が行われる順番を監視し、通信が上述した順番で行われていない場合、すなわち通信の順番が変わっている場合は異常が発生したと判断し、異常の発生を知らせる通信を行う。第４ＥＣＵ４００は、異常の発生を知らせる通信を受信すると異常表示部６１０に異常の発生を示す表示を表示させる。

（第１ＥＣＵの構成）
図３は第１ＥＣＵ１００の構成を示すブロック図である。第１ＥＣＵ１００は、その機能として、通信部１１０と、抽出部１２０と、格納部１３０と、検出部１４０と、出力部１５０と、制御演算部１６０を備える。
通信部１１０は、ＣＡＮに対応する通信インタフェースであり、車載ネットワーク２へのデータフレームの送信、および車載ネットワーク２からのデータフレームの受信を行う。通信部１１０が送信または受信したデータフレームの情報は、抽出部１２０および制御演算部１６０に出力される。
抽出部１２０は、通信部１１０から入力されたデータフレームの情報からＣＡＮ−ＩＤを抽出し、抽出したＣＡＮ−ＩＤを検出部１４０に出力する。

格納部１３０には、監視条件テーブル５００が格納される。格納部１３０は、監視条件テーブル５００を検出部１４０に提供する。監視条件テーブル５００の構成は後に詳述する。検出部１４０は、格納部１３０から監視条件テーブル５００を取得し、抽出部１２０から入力されたＣＡＮ−ＩＤの情報に基づいて、通信部１１０が送信または受信したデータフレームの順番が、監視条件テーブル５００に記載された順番に合致するか検証する。検出部１４０は、この検証に利用する検証テーブル６００を備える。この検証により、通信部１１０が送信または受信したデータフレームの通信順序が監視条件テーブル５００に記載された識別子の順番に合致しないと判断すると、出力部１５０に異常の検知を示す信号を出力する。検出部１４０の動作、および検証テーブル６００の構成は後に詳述する。

出力部１５０は、検出部１４０から異常の検知を示す信号が入力されると、あらかじめ定められたデータフレームを生成して通信部１１０に送信させる。このデータフレームによる他の装置への影響は後述する。
制御演算部１６０は、あらかじめ定められた手順にしたがって、他のＥＣＵや他の装置と通信を行うためのデータフレームを生成し、通信部１１０に送信させる。たとえば制御演算部１６０は、あらかじめ定められた時間の周期でデータフレームを生成して通信部１１０に送信させる。また制御演算部１６０は、受信したデータフレームのペイロードを用いて演算を行い、演算結果をペイロードに含むデータフレームを生成して通信部１１０に送信させる。なお抽出部１２０、格納部１３０、および検出部１４０は連携して動作するが、これらと制御演算部１６０の動作は独立している。

（監視条件テーブル）
図４は、監視条件テーブル５００の一例を示す図である。監視条件テーブル５００は、２以上のレコードから構成される。監視条件テーブル５００の各レコードは、順序、前提フラグ、条件、タイムアウト、および成立時フラグの５つのフィールドを有する。
順序のフィールドには、この監視条件テーブル５００において条件が成立する順番、換言すると正常な通信の順序を示す情報が格納される。順序のフィールドには、たとえば１以上の整数が格納され、少なくとも「１」と「２」が格納される。図４に示す例では４つのレコードにそれぞれ異なる値が格納されているので、４つの条件が１つずつ順番に成立するのが正常であることがわかる。

前提フラグのフィールドには、当該レコードが有効になる前提となるフラグが記載される。たとえば図４の１番目のレコードは前提フラグが不要であり常時有効であることを示している。また図４の２番目のレコードは「ＣＤ１」というフラグが設定された際に有効になることを示している。
条件のフィールドには、当該レコードにおいて評価される条件が格納される。本実施の形態における条件は、検知したデータフレームのＣＡＮ−ＩＤが特定の値と一致することである。たとえば図４の１番目のレコードの条件は、通信部１１０が送信または受信したデータフレームのＣＡＮ−ＩＤが「０ｘ０１」であることを示している。

タイムアウトのフィールドには、タイムアウト時間が格納される。当該フィールドが有効になってからタイムアウトのフィールドに記載された時間が経過すると、通信部１１０が条件を満たさないデータフレームを送信または受信した場合と同様に処理される。ただし図４の１番目のレコードのように、タイムアウトのフィールドに無限大が格納されているレコードについては、タイムアウトは発生しないものとして扱われる。図４の２番目のレコードでは、タイムアウトのフィールドに「２００マイクロ秒」が格納されているので、直前の条件である１番目のレコードの条件が成立したとき、すなわちＣＡＮ−ＩＤが「０ｘ１１」のデータフレームを通信部１１０が送信または受信したときから、２００マイクロ秒経過するとタイムアウトと判断される。
成立時フラグのフィールドには、当該レコードの条件のフィールドに記載された条件が成立した際に設定されるフラグが格納される。たとえば図４の１番目のレコードに記載の条件が成立すると、「ＣＤ１」のフラグが設定される。

（検証テーブル）
図５は、検証テーブル６００の一例を示す図である。検証テーブル６００は、１以上のレコードから構成される。検証テーブル６００の各レコードは、テーブル番号、成立時刻、監視番号、の３つのフィールドを有する。検証テーブル６００を構成するレコード数は、格納部１３０に格納される監視条件テーブル５００の数と同一である。検証テーブル６００は検出部１４０により編集される。
テーブル番号のフィールドには、それぞれの監視条件テーブルを識別する識別子、すなわちテーブル番号が格納される。成立時刻のフィールドには、最新の条件が成立した時刻が格納される。監視番号のフィールドには、現在有効なレコードの「順序」を表す番号が格納される。監視番号のフィールドの初期値は「１」である。

以上の説明をまとめると、図５に例示した検証テーブル６００は以下のことを表している。ただしここでは、テーブル番号「１」が図４に示した監視条件テーブル５００に対応することとする。
図５に例示した検証テーブル６００の監視番号のフィールドが「２」なので、監視条件テーブル５００の順序が「２」のレコードが有効である。また成立時刻のフィールドに格納された「０：０１：２３．４５６」に最新の条件が成立した、すなわち順序が「１」のレコードの条件が成立したことが示されている。換言すると通信部１１０が０ｘ０１のＣＡＮ−ＩＤをヘッダに含むデータフレームを送信または受信した時刻が「０：０１：２３．４５６」である。

（検出部の動作）
検出部１４０は、通信部１１０が送信または受信したデータフレームのＣＡＮ−ＩＤが抽出部１２０から入力されると、検証テーブル６００を参照してそれぞれの監視条件テーブル５００における監視番号、すなわち有効なレコードの順序の値を特定する。次に検出部１４０は、格納部１３０に格納される監視条件テーブル５００を参照し、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定する。ＯＫ判断ＩＤとは通信部１１０が次に送信または受信することが期待されるＣＡＮ−ＩＤであり、有効なレコードにおいてトリガ条件のフィールドに記載されるＣＡＮ−ＩＤである。ＮＧ判断ＩＤとは通信部１１０が次回以降に送信または受信することが期待されるＣＡＮ−ＩＤであり、監視条件テーブル５００における有効なレコードの次以降のレコードにおいて条件のフィールドに記載されるＣＡＮ−ＩＤである。

たとえば図４〜図５に示す例におけるＯＫ判断ＩＤとＮＧ判断ＩＤは以下のように特定される。図５に示す検証テーブル６００では監視番号のフィールドに「２」が格納されているので２番目のレコードが有効であり、監視条件テーブル５００における２番目のレコードに記載の「０ｘ０２」がＯＫ判断ＩＤとして特定される。また、２番目のレコードの次以降のレコード、すなわち３番目と４番目のレコードに記載の「０ｘ０３、０ｘ０４」がＮＧ判断ＩＤとして特定される。

検出部１４０は、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定すると、抽出部１２０から入力されたＣＡＮ−ＩＤがＯＫ判断ＩＤと一致するか否か、ＮＧ判断ＩＤと一致するか否かを判断する。ＯＫ判断ＩＤと一致すると判断する場合は、検証テーブル６００を更新する。ＮＧ判断ＩＤと一致すると判断する場合は、通信の順序が異なるという異常の検知を示す信号を出力部１５０に出力する。いずれにも一致しないと判断する場合は、何も処理を行わない。ただし検証テーブル６００の成立時刻のフィールドの時刻に監視条件テーブル５００のタイムアウトのフィールドの時間を加えた時刻が現在時刻と比較して過去であれば、タイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力する。

検出部１４０による検証テーブル６００の更新は以下のとおりである。すなわち、成立時刻のフィールドの値が現在時刻に更新され、監視番号のフィールドの値が１増加した値に更新される。なお、監視番号のフィールドの値の更新の詳細は次のとおりである。監視条件テーブル５００の２番目のレコードの条件が成立した場合は、２行目の成立時フラグのフィールドに記載されたフラグ「ＣＤ２」が設定される。そして監視条件テーブル５００において前提フラグのフィールドの値が「ＣＤ２」である３番目のレコードが有効化されるので、検証テーブル６００の監視番号のフィールドの値が「３」に更新される。

（検出部のフローチャート）
図６は検出部１４０が抽出部１２０からＣＡＮ−ＩＤを入力された際の動作を表すフローチャートである。以下に説明する各ステップの実行主体は第１ＥＣＵ１００のＣＰＵである。
ステップＳ１１では、検証テーブル６００の監視番号のフィールドの値、すなわち監視条件テーブル５００における有効なレコードの番号を特定する。続くステップＳ１２では、監視条件テーブル５００における有効なレコード、および次以降のレコードを参照し、ＯＫ判断ＩＤとＮＧ判断ＩＤを特定する。続くステップＳ１３では、タイムアウトが発生しているか否かを判断する。タイムアウトが発生していると判断する場合はステップＳ１８に進み、タイムアウトが発生していないと判断する場合はステップＳ１４に進む。

ステップＳ１４では、入力されたＣＡＮ−ＩＤがＯＫ判断ＩＤと一致するか否かを判断する。ＯＫ判断ＩＤと一致すると判断する場合はステップＳ１７に進み、一致しないと判断する場合はステップＳ１５に進む。
ステップＳ１５では、入力されたＣＡＮ−ＩＤがＮＧ判断ＩＤと一致するか否かを判断する。ＮＧ判断ＩＤと一致すると判断する場合はステップＳ１６に進み、一致しないと判断する場合は図７のフローチャートを終了する。
ステップＳ１６では、通信の順序が異なるという異常の検知を示す信号を出力部１５０に出力し、図６のフローチャートを終了する。ステップＳ１７では、検証テーブル６００を更新し、図６のフローチャートを終了する。ステップＳ１８では、タイムアウトのエラー、すなわちタイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力して、図６のフローチャートを終了する。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）演算装置、すなわち第１ＥＣＵ１００は、ヘッダに通信データの内容を示す識別子、すなわちＣＡＮ−ＩＤを含む通信データを受信する通信部１１０と、識別子の規定の順番が記された監視条件テーブル５００が格納される格納部１３０と、通信の異常を検出する検出部１４０とを備える。検出部１４０は、通信部１１０が送受信した複数の通信データの通信順序と、監視条件テーブル５００に記された識別子の規定の順番とに基づき、通信の異常を検出する。
第１ＥＣＵ１００は、データフレームのヘッダに格納されるＣＡＮ−ＩＤに着目し、送受信するデータフレームの通信順序に応じたＣＡＮ−ＩＤの順番が監視条件テーブル５００に記された識別子の順番と一致しない場合に通信の異常を検出する。そのため第１ＥＣＵ１００は、周期的でない通信でも通信の異常を検出することができる。

（２）検出部１４０は、監視条件テーブル５００に含まれる識別子、たとえば図４の例におけるＣＡＮ−ＩＤ「０ｘ０１」、「０ｘ０２」、「０ｘ０３」、「０ｘ０４」をそれぞれ含む通信データが、監視条件テーブル５００に記された順番とは異なる通信順序、たとえば「０ｘ０１，０ｘ０２，０ｘ０４，０ｘ０３」の順で通信部１１０に送受信されたと判断すると通信の異常を検出したと判断する。そのため、通信データの順番が入れ替わって受信した場合に迅速に通信の異常を検出することができる。

（３）検出部１４０は、監視条件テーブル５００に記された第１識別子を含む通信データが通信部１１０により送受信されると、監視条件テーブル５００における第１識別子の次に記載された第２識別子を含む通信データが既定のタイムアウト時間までに通信部１１０により送受信されない場合に通信の異常を検出したと判断する。そのため、通信の順序が入れ替わった場合だけでなく、既定の時間よりも通信の間隔が長い場合に通信の異常として検出することができる。

（４）通信データはＣＡＮプロトコルにしたがったデータフレームであり、識別子はＣＡＮ−ＩＤである。ＣＡＮではバス型のネットワークトポロジが採用されているので、第１ＥＣＵ１００は同一ネットワーク内の通信をすべて受信することができる。したがって、通信データが送信された順序をもれなく把握することができる。

（変形例１）
上述した実施の形態における検出部１４０の動作を以下のように変更してもよい。
図７は、変形例１における検出部１４０の動作を表すフローチャートである。図６と同一の動作を行う処理ステップには同一のステップ番号を付している。以下に説明する各ステップの実行主体は第１ＥＣＵ１００のＣＰＵである。

検出部１４０は、第１ＥＣＵ１００が起動すると動作を開始する。ステップＳ２１では、監視条件テーブル５００における順序が「１」のレコードにおいてトリガ条件のフィールドに記載されるＣＡＮ−ＩＤが抽出部１２０から入力されたか否かを判断する。入力されたと判断する場合はステップＳ１７に進み、入力されていないと判断する場合はステップＳ２１に留まる。

ステップＳ１７では、現状の検証テーブル６００の記述と、受信したＣＡＮ−ＩＤに基づき検証テーブル６００を更新し、ステップＳ１１に進む。ステップＳ１１では検証テーブル６００の記述に基づき、監視条件テーブル５００において有効なレコードの番号を特定する。続くステップＳ１２Ａでは、ＯＫ判断ＩＤを特定する。続くステップＳ１４Ａでは、ＯＫ判断ＩＤが入力されたか否かを判断し、入力されたと判断する場合はステップＳ２２に進み、入力されていないと判断する場合はステップＳ１３に進む。ステップＳ１４Ａにおいて否定判断される場合は、通信部１１０が何も受信していない場合、およびＯＫ判断ＩＤ以外のＣＡＮ−ＩＤを有するデータフレームを受信した場合である。

ステップＳ２２では、現在有効なレコードが最後のレコードであるか否かを判断し、最後のレコードであると判断する場合はステップＳ２３に進み、最後のレコードではないと判断する場合はステップＳ１７に戻る。ステップＳ２３では、検証テーブル６００の初期化、すなわち成立時刻の削除および監視番号の「１」への変更を行い、図７のフローチャートを終了する。

ステップＳ１４Ａにおいて否定判断されると実行されるステップＳ１３では、タイムアウトが発生したか否かを判断する。タイムアウトが発生したと判断する場合はステップＳ１８に進み、タイムアウトが発生していないと判断する場合はステップＳ１４Ａに戻る。ステップＳ１８ではタイムアウトのエラー、すなわちタイムアウトが発生したという異常の検知を示す信号を出力部１５０に出力して、図７のフローチャートを終了する。
第１ＥＣＵ１００のＣＰＵは、図７のフローチャートの実行が終了すると、再び図７のフローチャートを実行する。

（動作例）
監視条件テーブル５００が図４に示すものである場合に、「０ｘ０２」と「０ｘ０３」のＣＡＮ−ＩＤの通信の順番が入れ替わり、通信部１１０が送受信したデータフレームのＣＡＮ−ＩＤの順番が「０ｘ０１，０ｘ０３，０ｘ０２，０ｘ０４」である場合に以下のようにエラーが検出される。

まず通信部１１０により、順序が「１」であるレコードのＣＡＮ−ＩＤである「０ｘ０１」のデータフレームが送信され、このＣＡＮ−ＩＤが検出部１４０に入力されると（図７のＳ２１：ＹＥＳ）、検証テーブル６００の監視番号が「２」に更新される（Ｓ１７）。したがって順序が「２」であるレコードに記載された「０ｘ０２」がＯＫ判断ＩＤとして特定される（Ｓ１１，Ｓ１２Ａ）。すると、「０ｘ０２」のＣＡＮ−ＩＤが検出部１４０に入力されるかタイムアウトが発生するまで、Ｓ１４ＡとＳ１３のループが継続される。

そのため通信部１１０が「０ｘ０３」のＣＡＮ−ＩＤのデータフレームを受信し、このＣＡＮ−ＩＤが検出部１４０に入力されると、Ｓ１４Ａで否定判断される。その次に通信部１１０が「０ｘ０２」のＣＡＮ−ＩＤのデータフレームを受信すると、Ｓ１４Ａで肯定判断され最後のレコードではないのでＳ１７に戻り、検証テーブル６００の監視番号が「３」に更新される。そのため次は「０ｘ０３」がＯＫ判断ＩＤとして特定され（Ｓ１１，Ｓ１２Ａ）、Ｓ１４Ａでは「０ｘ０３」のＣＡＮ−ＩＤが検出部１４０に入力されるのを待ち続ける。しかし、次に通信部１１０が送信するデータフレームのＣＡＮ−ＩＤは最後の「０ｘ０４」なので、検出部１４０に「０ｘ０３」のＣＡＮ−ＩＤが入力されることはなく、タイムアウトエラーが出力される（Ｓ１３：ＹＥＳ，Ｓ１８）。

この変形例１によれば、次の作用効果が得られる。
（１）検出部１４０は、監視部（図７のＳ１７，Ｓ１１，Ｓ１２Ａ，Ｓ１４Ａ，Ｓ１３）と監視開始部（図７のＳ２１）と監視終了部（図７のＳ２２）とを含む。監視部は、監視条件テーブル５００に記された第１識別子を含む通信データが通信部１１０により送受信されると、既定のタイムアウト時間までに監視条件テーブル５００における第１識別子の次に記載された第２識別子を含む通信データが通信部１１０により送受信されない場合に通信の異常を検出したと判断する。監視開始部は、監視条件テーブル５００に記された先頭の識別子を含む通信データが通信部１１０により送受信されると監視部の動作を開始させる。監視終了部は、監視条件テーブル５００に記された末尾の識別子を含む通信データが通信部１１０により送受信されると監視部の動作を終了させる。

検出部１４０は、受信するＣＡＮ−ＩＤかある１つのＣＡＮ−ＩＤと一致するか否かを判断すればよく（図７のステップＳ１４Ａ）、第１の実施の形態のように複数のＣＡＮ−ＩＤとの一致を判断する必要がないので、ＣＰＵの処理負荷を軽くすることができる。
なお検出部１４０は、実施の形態に示した手法と変形例１における方法とのいずれの方法を採用するかを選択可能であってもよい。検出部１４０は、処理負荷が高い点を許容し迅速に異常を検出することを重視する場合は実施の形態に示した手法を選択し、異常検出に時間を要する点を許容し処理負荷が低いことを重視する場合は変形例１に示した手法を選択する。

（変形例２）
監視条件テーブル５００の複数のレコードに、同一の順序が付与されてもよい。
図８は、複数のレコードに同一の順序が付された監視条件テーブル５００の一例を示す図である。図８に示す例では、２番目と３番目のレコードに同一の「２」の順序が付されている。検出部１４０に「０ｘ１１」のＣＡＮ−ＩＤが入力されると、「ＣＤ５」のフラグが成立するので、２番目と３番目のレコードが有効となる。そして「０ｘ１２」のＣＡＮ−ＩＤが入力されると「ＣＤ６」のフラグが設定され、「０ｘ１３」のＣＡＮ−ＩＤが入力されると「ＣＤ７」のフラグが設定される。
図８の４番目のレコードはトリガ設定が「ＣＤ６＋ＣＤ７」なので、これら２つのフラグが両方とも設定されている場合に４番目のレコードが有効となる。なおこの２つのフラグはどちらが先に有効にされてもかまわない。

また監視条件テーブル５００の複数のレコードに同一の順序が付与されている場合は、検証テーブルが付加的なフィールドを有する。
図９は、付加的なフィールドを有する検証テーブル６００Ａの一例を示す図である。検証テーブル６００Ａは、テーブル番号、成立時刻、監視番号に加えて、オプションパラメータのフィールドを有する。オプションパラメータのフィールドには、監視番号のフィールドの記載から複数のレコードが特定される場合に、成立済みのフラグを示す情報が格納される。たとえば図８に示すように同一の順序を有する２つのレコードがあり、それぞれのレコードの条件が成立するとＣＤ２のフラグとＣＤ３のフラグが設定される場合に、オプションパラメータのフィールドには以下の値が格納される。すなわち、いずれのフラグも設定されていない場合は「０ｘ００００」が格納され、ＣＤ２のフラグのみが設定されると「０ｘ０００２」が格納され、さらにＣＤ３のフラグも設定されると次のフィールドが有効になるので「０ｘ００００」が格納される。
この変形例２によれば、通信の順序の入れ替わりを許容する柔軟な監視条件を設定することができる。

（変形例３）
監視条件テーブル５００のトリガ条件のフィールドには、ＣＡＮ−ＩＤの値に加えてペイロードに含まれる値の条件が含まれてもよい。データフラグのペイロードには各種の値、たとえばエンジン回転数や排気ガスの温度が含まれる。それらの値はそれぞれ通常とりうる値の範囲が想定されるので、その範囲を条件としてトリガ条件のフィールドに含める。たとえばＣＡＮ−ＩＤが「０ｘ３０」のデータフラグのペイロードにはエンジン回転数Ｒの情報が格納され、その値がＲ１からＲ２の間であることを条件とする場合にトリガ条件のフィールドには「ＣＡＮ−ＩＤ＝０ｘ３０、Ｒ１＜Ｒ＜Ｒ２」という情報が格納される。

この変形例３によれば、次の作用効果が得られる。
（１）監視条件テーブル５００には、識別子と通信データのペイロードに格納される値の条件と識別子との組み合わせも記載される。検出部１４０は、通信データのペイロードに格納される値が、当該通信データに含まれる識別子と組み合わせて監視条件テーブル５００に記載される条件を満たさない場合に通信の異常を検出したと判断する。
そのため、ペイロードに格納された値も監視対象とすることができる。

（変形例４）
格納部１３０には、複数の監視条件テーブル５００が備えられてもよい。この場合、検出部１４０の検証テーブル６００は、監視条件テーブル５００と同数のレコードを有する。検出部１４０の動作における第１の実施の形態との相違点を図６のステップ番号ごとに説明する。

図６のステップＳ１１およびＳ１２では、検出部１４０はそれぞれの監視条件テーブル５００を対象として処理を行う。ステップＳ１３、Ｓ１６、およびＳ１８の処理は第１の実施の形態と同様である。ステップＳ１４では、受信したＩＤがいずれかの監視条件テーブル５００のＯＫ判断ＩＤと一致するか否かを判断する。いずれかの監視条件テーブル５００のＯＫ判断ＩＤと一致すると判断する場合はステップＳ１７に進み、いずれの監視条件テーブル５００のＯＫ判断ＩＤとも一致しないと判断する場合はステップＳ１５に進む。ステップＳ１５では、受信したＩＤがいずれかの監視条件テーブル５００のＮＧ判断ＩＤと一致するか否かを判断する。いずれかの監視条件テーブル５００のＮＧ判断ＩＤと一致すると判断する場合はステップＳ１６に進み、いずれの監視条件テーブル５００のＯＫ判断ＩＤとも一致しないと判断する場合は図６のフローチャートを終了する。

（変形例）
上述した第１の実施の形態をさらに以下のように変形してもよい。
（１）第１ＥＣＵ１００は、制御演算部１６０を備えなくてもよい。すなわち第１ＥＣＵ１００は、監視のみを行うＥＣＵでもよい。
（２）検出部１４０は、タイムアウトによるエラーと、受信したＣＡＮ−ＩＤが規定されていた順番ではないためのエラーとを区別せずに出力してもよい。
（３）第１ＥＣＵ１００はエラーが検出された際の対応を行うフォルトモードを備え、検出部１４０が順序のエラーを出力した場合（図６のステップＳ１６）に、フォルトモードを有効にしてもよい。

（４）第４ＥＣＵ４００は、受信した異常の検知を示すデータフレームを蓄積し、外部から読出し可能であってもよい。この場合は、たとえばサービスマンなどが第４ＥＣＵ４００と通信を行い異常に関する情報を収集することができる。
（５）本発明を通信プロトコルにＣＡＮ以外を使用するネットワークに適用してもよい。たとえば通信プロトコルにＦｌｅｘＲａｙを使用するネットワークに適用してもよい。その場合は、ＦｌｅｘＲａｙにおけるデータフレームＩＤがＣＡＮにおけるＣＡＮ−ＩＤに相当する。
（６）格納部１３０に格納される監視条件の情報は、図４や図８に示したようなテーブル形式のものに限らない。また、検出部１４０に格納される検証のための情報も、図５や図９に示したようなテーブル形式のものに限らない。検出部１４０の処理において必要な情報が適切に表されていれば、格納部１３０や検出部１４０にどのような形式の情報を格納してもよい。

プログラムは第１ＥＣＵ１００の不図示のＲＯＭに格納されるとしたが、プログラムは格納部１３０に格納されていてもよい。また、第１ＥＣＵ１００が不図示の入出力インタフェースを備え、必要なときに入出力インタフェースと第１ＥＣＵ１００が利用可能な媒体を介して、他の装置からプログラムが読み込まれてもよい。ここで媒体とは、例えば入出力インタフェースに着脱可能な記憶媒体、または通信媒体、すなわち有線、無線、光などのネットワーク、または当該ネットワークを伝搬する搬送波やディジタル信号、を指す。また、プログラムにより実現される機能の一部または全部がハードウエア回路やＦＰＧＡにより実現されてもよい。
上述した実施の形態および変形例は、それぞれ組み合わせてもよい。
上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

２ … 車載ネットワーク
１００ … 第１ＥＣＵ
１１０ … 通信部
１２０ … 抽出部
１３０ … 格納部
１４０ … 検出部
１５０ … 出力部
５００ … 監視条件テーブル

Claims (6)

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

Images