JP2006191338A

JP2006191338A - バス内のデバイスの故障診断を行うゲートウエイ装置

Info

Publication number: JP2006191338A
Application number: JP2005001121A
Authority: JP
Inventors: Katsutomo Sasakura; 克友笹倉
Original assignee: Denso Ten Ltd
Current assignee: Denso Ten Ltd
Priority date: 2005-01-06
Filing date: 2005-01-06
Publication date: 2006-07-20

Abstract

【課題】ＣＡＮのマルチマスタ方式を維持しながら，故障診断用の専用デバイスを設けることなく，ＣＡＮバス内のデバイスの故障を検出することができるゲートウエイ装置を提供する。
【解決手段】複数のデバイスＥＣＵがそれぞれ接続される複数のバスＢＵＳ−１，２の間に設けられ，バス間のメッセージを転送するゲートウエイ装置１０であって，デバイスＥＣＵは，それぞれがマスタとして，バスがアイドル状態の時に自主的にメッセージ送信を行う。そして，ゲートウエイ装置１０は，複数のバス内の定期的に送信される定期メッセージをそれぞれ監視し，当該定期メッセージの通信状況から故障デバイスを検出し，当該故障デバイスに対してリセットを行わせる。故障デバイスへのリセットは，通常リセット要求メッセージを送信することにより行うリセットと，強制リセット信号を送信することによるリセットとが含まれる。
【選択図】図２

Description

本発明は、バス内のデバイスの故障診断を行うゲートウエイ装置に関し、特に、ＣＡＮ（Controller Area Network）バス間のメッセージの中継を行うと共に，バス内の通信状
態を監視し，通信状態からデバイスの故障診断を行うと共に，故障デバイスをリセットさせるゲートウエイ装置に関する。

ＣＡＮは，ＩＳＯで国際的に標準化されたシリアル通信プロトコルであり，主に，自動車のハードウエアを制御するＥＣＵ（Electric Control Unit）間を接続する車内ＬＡＮ
の通信プロトコルとして広く使用されている。また，最近においては，ＣＡＮの高い性能と信頼性から，用途は自動車からファクトリ・オートメーション，船舶，医療機器，産業機器など多方面に拡がっている。ＣＡＮについて，例えば，以下の非特許文献１，２に記載されている。また，車内ＬＡＮによる車両用制御システムについて，例えば，以下の特許文献１，２に記載されている。
「ＣＡＮ入門書」www.renesas.com 「ＣＡＮとは？」www.toyo.co.jp/car/CAN/CAN_General.htm 特開２００４−１３６８１６号公報特開２００４−１７６７６号公報上記非特許文献１には，複数のＥＣＵがＣＡＮにより接続され，更に，複数のＣＡＮがゲートウエイ装置を介して接続された車内ネットワークシステムが記載されている。例えば，エンジンやトランスミッションを制御するＥＣＵを接続するエンジン系のＣＡＮと，ＶＩＣＳナビなどを制御するＥＣＵを接続する情報系のＣＡＮとが，ゲートウエイ装置を介して接続され，情報系からのメッセージに応じて，エンジン系の制御に反映させることが考えられる。また，上記非特許文献１には，故障診断系のＣＡＮとエンジン系のＣＡＮとがゲートウエイ装置を介して接続され，例えば，故障診断系のＣＡＮの診断ツールから，エンジン系ＣＡＮのエンジン制御ＥＣＵに対して，診断のための制御を可能にすることが考えられる。

このように，ゲートウエイ装置は，異なるＣＡＮバス間のプロトコルの翻訳を行うと共に，一方のＣＡＮバス内のＥＣＵから送信されたメッセージを他方のＣＡＮバス内のＥＣＵに転送する。ＣＡＮの仕様によれば，後述するとおり，メッセージにはバス内の送信権の優先順位を示す識別子が付加され，同時に送信されたメッセージ間の送信権の調停は，この識別子により行われる。一方，ゲートウエイ装置は，一方のバスから受信したメッセージを他方のバスに送信する場合，原則として受信した順番に送信先バスに送信する。また，優先順位を規定する識別子に対応する送信周期で，受信したメッセージを送信先バスに送信する。このように，重要で緊急性を要するメッセージとそれ以外のメッセージとを識別子で区別して，それぞれのメッセージに対応した緊急度でメッセージが転送されるようにされている。

ＣＡＮプロトコルの特徴は，（１）バスが空いていれば全てのデバイス（ＥＣＵ）がメッセージを送信することができるマルチマスタ方式と，（２）全てのデバイスはメッセージを同時に受信し，受信すべきデバイスがメッセージを受信するマルチキャスト方式と，（３）ネットワーク内のデバイスにはアドレスは割り付けられず，メッセージの内容若しくは種類は，メッセージに対応付けられたネットワーク内で固有の識別子（ＩＤ）により定義され，送信メッセージにはこのＩＤが付加され，受信デバイスが受信すべきＩＤのメッセージを自発的に受信するネットワークのフレキシブル性（したがって，このＩＤにより送信元と受信先のデバイスが特定される）と，（４）メッセージに付加されるＩＤがネットワーク上での送信権の優先順位も定義し，複数のデバイスが同時にメッセージを送信
しようとすると，優先順位の高いＩＤのメッセージが優先され送信権を取得し，優先順位の低いＩＤのメッセージは送信を中止する衝突回避方法である。

かかるマルチマスタ方式では，ＣＡＮバスに接続されるＥＣＵ（以下単にデバイスと称する。）は全てマスタであり，メッセージの送信開始の判断，識別子によるバス調停の判断，メッセージの受信判断などを全て自ら主体的に行うようになっている。かかる方式にすることで，マスタへの登録や設定を不要にして，様々なハードウエアを制御可能な新たなデバイスの開発を容易にし，ＣＡＮシステムの拡張性を高めることができる。

一方で，マルチマスタ方式は，全てのデバイスが平等に設計されることから，バス内の通信状態を監視し，バス内のデバイスの故障を検出しリセットする機能が設けられていない。すなわち，各デバイスは自分自身の故障を検出して自らリセットする機能を有してはいるが，他のデバイスの故障を検出してリセットを要求する機能は有していない。

上記の特許文献１には，バス内の複数の個別デバイスに対してそれらのデバイスの動作を統括する統括デバイスを設け，統括デバイスがバスを介して個別デバイスから取得した情報に基づいて個別デバイスへの動作指令を行うと共に，個別デバイスの異常状態を検出することが提案されている。また，この統括デバイスは，バス間で転送されるべきメッセージを抽出して送信元から送信先のバスにメッセージを転送する機能を有することも記載されている。更に，上記の特許文献２には，バス内に故障診断を行うダイアグマスタデバイスを設け，ダイアグマスタデバイスが，バス内の通信データ，例えば周期的に送信される状態監視用の通信データを監視して，未送信時間から個別デバイスの異常状態を検出し，そのデバイスを再起動させることが記載されている。

上記の特許文献１の方法では，統括デバイスが個別デバイスへの動作指令を行うようになっており，ＣＡＮのマルチマスタ方式と整合せず，現在普及しているＣＡＮのネットワークシステムに採用することはできない。したがって，この統括デバイスを採用すると，個別デバイスの新規開発には統括デバイスの変更を必要とし，マルチマスタ方式のメリットを生かすことができない。

また，特許文献２の方法では，個別デバイスとは別に故障診断用のマスタデバイスを設ける必要があり，ＣＡＮのネットワークシステム内に故障診断用の専用デバイスを設けなければならない。かかる専用デバイスは，ＣＡＮのネットワークシステムにおいて個別デバイスの数が増大する状況においては，バス内のデバイス数の増大につながると共に，ゲートウエイ装置を介して複数のＣＡＮバスが接続されるネットワークにおいては，各ＣＡＮバスにそれぞれ故障診断用の専用デバイスの設置が必要になり，コストアップにつながり好ましくない。

そこで，本発明の目的は，ＣＡＮのマルチマスタ方式を維持しながら，故障診断用の専用デバイスを設けることなく，ＣＡＮバス内のデバイスの故障を検出することができるゲートウエイ装置を提供することにある。

上記の目的を達成するために，本発明の第１の側面では，複数のデバイスがそれぞれ接続される複数のバスの間に設けられ，前記バス間のメッセージを転送するゲートウエイ装置であって，前記デバイスは，それぞれがマスタとして，前記バスがアイドル状態の時に自主的にメッセージ送信を行う。そして，前記ゲートウエイ装置は，前記複数のバス内の定期的に送信される定期メッセージをそれぞれ監視し，当該定期メッセージの通信状況か
ら故障デバイスを検出し，当該故障デバイスに対してリセットを行わせることを特徴とする。

上記の第１の側面において，好ましい実施例によれば，前記デバイスは，バスの通信状況に基づいて自主的にリセットする通常リセット機能を有し，前記ゲートウエイ装置は，故障デバイスに対して前記通常リセットを要求すると共に，当該通常リセット要求が故障デバイスで受け付けられなかった場合に強制リセット信号を供給して前記通常リセット要求とは異なる方法で前記故障デバイスにリセットを行わせることを特徴とする。前記通常リセット要求は，例えば，メッセージとしてゲートウエイ装置が故障デバイスに送信する。また，強制リセット信号は，例えば，メッセージとは異なる信号パターンであり，ゲートウエイ装置が故障デバイスに送信する。

上記の第１の側面において，更に好ましい実施例によれば，ゲートウエイ装置は，前記バス上に送信されるメッセージとは異なるパターンの強制リセット信号を前記バスに送信することで前記通常リセットを要求し，当該強制リセット信号は，前記パターンを検出してリセット割り込み信号を故障デバイスに与える強制リセット信号検出手段を介して前記故障デバイスに供給されることを特徴とする。

上記の第１の側面によれば，ゲートウエイ装置が複数のバス間のメッセージの転送を行うと共に，それぞれのバス内の定期メッセージを監視し，その定期メッセージの通信状況から故障デバイスを検出し，故障デバイスに対してリセットを行わせる。したがって，マルチマスタ方式を維持したまま，故障監視用の専用デバイスを設けることなく，バス間のメッセージ転送を行うゲートウエイ装置に故障デバイスの検出を行わせて，故障デバイスへのリセットを可能にする。

更に，好ましい実施例によれば，バス内の各デバイスは自主的な通常リセット機能を有し，ゲートウエイ装置は，その通常リセット機能による通常リセット要求を行い，故障デバイスが自己の故障診断結果と照合した上で通常リセットできるようにし，ゲートウエイ装置が，通常リセット要求が故障デバイスにより受け付けられなかった場合の強制リセットの要求を行う。このように，デバイスの故障診断を，デバイス自信で行うと共にゲートウエイ装置によっても客観的に行うことで，デバイスの動作へのリセットによる影響を最小限にしつつ故障回避を可能にすることができる。それにより，ネットワーク内の信頼性を高めることができる。

以下、図面にしたがって本発明の実施の形態について説明する。但し、本発明の技術的範囲はこれらの実施の形態に限定されず、特許請求の範囲に記載された事項とその均等物まで及ぶものである。

図１は，ゲートウエイ装置の構成とメッセージの転送動作を示す図である。図１には，ＣＡＮである第１のバスＢＵＳ−１と第２のバスＢＵＳ−２との間に，バス間でメッセージ転送を行うゲートウエイユニット１０が設けられている。第１のバスＢＵＳ−１には，２つのデバイスＥＣＵ−１，ＥＣＵ−２と，ゲートウエイユニット１０が接続され，第２のバスＢＵＳ−２には，２つのデバイスＥＣＵ−３，ＥＣＵ−４と，ゲートウエイユニット１０が接続される。これらのデバイスＥＣＵは，マイクロプロセッサで構成され，図示しないハードウエアの状態監視とその電子制御を行う。第１及び第２のバスＢＵＳ−１，２は，それぞれ個別のネットワークを構成し，それぞれのプロトコルでネットワーク内のデバイス間でメッセージがやりとりされる。また，各デバイスＥＣＵは，図示しないハードウエアの状態を監視し制御する。そして，ゲートウエイユニット１０は，異なるネット
ワーク間でプロトコルの翻訳とメッセージの転送を行う。

ゲートウエイユニット１０には，第１のバスＢＵＳ−１から第２のバスＢＵＳ−２にメッセージを転送するための，受信バッファＲ−ＢＵＦと，転送コントローラＴＣＯＮと，転送すべき受信メッセージを格納する転送キューバッファＴ−ＱＵＥとを有する。この転送キューバッファＴ−ＱＵＥは，転送すべき受信メッセージ群を転送順に格納する待ち行列である。同様に，逆方向にメッセージを転送するための同様の構成も有する。そして，一方のバスに接続されているデバイスＥＣＵから送信されたメッセージＭＥＳ１が，ゲートウエイユニット１０により他方のバスに接続されているデバイスＥＣＵに転送される。

ＣＡＮプロトコルの特徴は，前述したとおり，（１）マルチマスタ方式と，（２）マルチキャスト方式と，（３）ネットワークのフレキシブル性と，（４）メッセージの衝突回避方法である。

以下，第１のバスＢＵＳ−１のデバイスＥＣＵ−１が第２のバスＢＵＳ−２のデバイスＥＣＵ−３にメッセージＭＥＳ１を送信する場合を例にして，その送信動作を説明する。まず，デバイスＥＣＵ−１は，第１のバスＢＵＳ−１がアイドル状態の時にメッセージＭＥＳ１をバスに送信する。メッセージＭＥＳ１は，簡単にいえば，メッセージの種類を示す識別子ＩＤが付加され，数バイトのデータＤＡＴＡを含むフレームで構成される。そして，第１のバスＢＵＳ−１での送信権は，第１に，アイドル中のバスにメッセージフレームを先に出力したデバイスに与えられ，第２に，同時にメッセージフレームが出力された時は，メッセージに付加される識別子ＩＤに固有に与えられている優先順位が高いほうのメッセージを出力したデバイスに与えられる。つまり，全ての識別子ＩＤは異なる優先順位を有し，デバイスＥＣＵ−１，ＥＣＵ−２が同時にメッセージＭＥＳ１，ＭＥＳ２をバスに出力した場合は，その識別子ＩＤの優先順位により送信権が決定され，優先順位の高い識別子ＩＤを有するメッセージＭＥＳ１の送信が継続され，優先順位の低い識別子ＩＤを有するメッセージＭＥＳ２の送信が停止される。

このように，ＣＡＮバスではマルチマスタ方式であるので，各デバイスは，バスがアイドル状態であればバスの送信権を獲得することなく自主的にメッセージを送信することができる。そして，送信権のアービトレーションは，メッセージに付加される識別子により各デバイスにより判定される。

デバイスＥＣＵ−１がメッセージＭＥＳ１を出力しようとする時に，同時にデバイスＥＣＵ−２がメッセージＭＥＳ２を出力しても，メッセージＭＥＳ１の識別子ＩＤがより高い優先順位を有していれば，デバイスＥＣＵ−２はメッセージＭＥＳ２の出力を停止し，結局，デバイスＥＣＵ−１だけがメッセージＭＥＳ１をバスＢＵＳ−１に出力することができる。もちろん，デバイスＥＣＵ−１が先にメッセージＭＥＳ１の出力を開始した場合は，他のデバイスＥＣＵ−２はメッセージの出力を開始しない。

そして，バスＢＵＳ−１に出力されたメッセージＭＥＳ１は，ゲートウエイユニット１０の受信バッファＲ−ＢＵＦに格納される。ゲートウエイユニット１０には，第２のバスＢＵＳ−２に転送すべき識別子があらかじめ設定されており，その設定された識別子のメッセージのみを受信バッファＲ−ＢＵＦに格納する。

ゲートウエイユニット１０内の転送コントローラＴＣＯＮは，受信したメッセージＭＥＳ１を，転送キューバッファＴ−ＱＵＥの最後尾に格納すると共に，所定の送信周期毎に転送キューバッファＴ−ＱＵＥ内に格納された受信済みメッセージを，受信順に，第２のバスＢＵＳ−２に出力する。第２のバスＢＵＳ−２においても，第１のバスＢＵＳ−１内でのアービトレーション方法と同様の方法で，送信権のアービトレーションが行われる。
そして，第２のバスＢＵＳ−２に送信されたメッセージＭＥＳ１は，そのメッセージを受信すべきデバイスＥＣＵ−３が受信する。すなわち，マルチキャスト方式により，第２のバスＢＵＳ−２に接続されるデバイスＥＣＵ−３，ＥＣＵ−４は，どの識別子のメッセージを受信すべきかがあらかじめ設定されており，その設定された識別子のメッセージＭＥＳ１を，バス上に出力されるメッセージから判別し，該当する場合にはそれを受信する。

第２のバスＢＵＳ−２に接続されたデバイスから第１のバスＢＵＳ−１に接続されたデバイスへのメッセージの送信も，上記と同様に，バス上でのアービトレーションと，ゲートウエイユニット１０での転送制御とにより行われる。

図２は，本実施の形態におけるゲートウエイユニットとの詳細構成を示す図である。図２に示されたゲートウエイユニット１０は，図１に示した受信バッファＲ−Ｂｕｆと，転送コントローラＴＣＯＮと，転送キューバッファＴ−ＱＵＥとからなるメッセージ転送手段に加えて，デバイスの故障診断手段１２を有する。各バスＢＵＳ−１，２に接続されるデバイスＥＣＵ−１〜４は，図１で説明したとおり，ゲートウエイユニット１０を介して異なるバスのデバイス間でメッセージの送受信を行う。それと共に，各バス内のデバイス間でもメッセージの送受信を行う。図２には，破線で示すように，第１のバスＢＵＳ−１において，デバイスＥＣＵ−１が送信したメッセージＭＥＳ１１がデバイスＥＣＵ−２により受信され，デバイスＥＣＵ−２が送信したメッセージＭＥＳ１２が図示しないデバイスにより受信されている。更に，第２のバスＢＵＳ−２において，デバイスＥＣＵ−３が送信したメッセージＭＥＳ１３がデバイスＥＣＵ−４により受信され，デバイスＥＣＵ−４が送信したメッセージＭＥＳ１４が図示しないデバイスにより受信されている。これらのバス内のメッセージの通信は，前述と同様にマルチマスタ方式で送信され，マルチキャスト方式で受信される。

ゲートウエイユニット１０では，デバイス故障診断手段１２により，一点鎖線で示すように，これらのバス内に送信された全てのまたは所定のメッセージを監視し，メッセージの送信状況からデバイスの故障診断を行う。特に，デバイスＥＣＵは，制御対象のハードウエアの状態を定期的に他のデバイスに伝えるために，少なくとも何らかのメッセージを定期的に送信している。そこで，デバイス故障診断手段１２は，バス内に送信される上記の定期メッセージを監視し，定期メッセージがその周期内に送信されなかった場合や，定期メッセージがその周期内で過剰回数送信された場合などを監視し，そのような場合に，定期メッセージを送信するデバイスと受信するデバイスを故障と疑って，そのデバイスに通常リセットを要求する。更に，デバイス故障診断手段１２は，通常リセットを要求したにもかかわらず通常リセットが実行されたことを確認できない場合は，通常リセットとは異なる強制リセット信号を故障デバイスに送信して，強制的に通常リセットを実行させる。

図３は，デバイスの詳細構成図である。デバイスＥＣＵ１は，内部バス２０を介して，ＣＰＵと，制御プログラムを格納するプログラムメモリＰＲＯＭと，内部メモリＲＡＭと，被制御ハードウエア（図示せず）へのインターフェースＩＦとが接続されている。更に，デバイスＥＣＵ１は，ＣＡＮバスＢＵＳ−１を介しての通信手順を制御する通信コントローラ２２と，送信時にＣＰＵによりオンされる送信フラグレジスタ２４と，送信メッセージが格納されるメッセージレジスタ２６と，ＣＡＮバスＢＵＳ−１からメッセージを受信し，バスＢＵＳ−１の電圧を検出する受信インターフェース２８とを有する。ＣＰＵは，制御プログラムを実行して図示しない被制御ハードウエアを制御し，送信すべきメッセージの作成と，受信したメッセージに対する必要な制御を行う。通信コントローラ２２は，ハードウエアマクロであり，ＣＰＵにより指示されたメッセージの送信制御と，他のデバイスからのメッセージの受信制御を行う。更に，デバイスには，強制リセットのためのリセットポートＲＰＯＲＴを，通常のメッセージポート（メッセージレジスタと受信イン
ターフェースのポート）とは別に有する。

ＣＰＵは，制御プログラムにしたがい，被制御ハードウエアの状態を監視し，その状態を定期的にメッセージとして他のデバイスに送信する。また，他のデバイスから受信したメッセージに応答して必要な制御を被制御ハードウエアに行う。他のデバイスにメッセージを送信する場合は，ＣＰＵは，送信メッセージをメッセージレジスタ２６に格納すると共に，送信フラグレジスタ２４の送信フラグをオンにする。通信コントローラ２２は，送信フラグレジスタ２４を監視し，送信フラグがオンにされた時に，メッセージレジスタ２８内のメッセージをバスＢＵＳ−１に送信する。メッセージの送信制御では，前述したとおり，バスＢＵＳ−１がアイドル状態の時に識別子を付加したメッセージの送出を行い，識別子に対するアービトレーション制御を行う。識別子により送信権を取得した場合のみ，データを含むメッセージの送出を継続し，識別子により送信権を取得できなかった場合は，メッセージの送出を停止する。そして，通信コントローラ２２は，メッセージの送信の後に送信先デバイスからのアクノリッジ信号の受信に応答して，ＣＰＵに対してメッセージ送信完了を通知する。これにより，ＣＰＵはメッセージの通信が無事に完了したことを確認する。

また，通信コントローラ２２は，バスＢＵＳ−１の電圧を受信インターフェース２８を介して監視し，上記の通信権のアービトレーション処理，エラー監視などを行う。アービトレーション処理は，メッセージの識別子が格納されているアービトレーションフィールドを送出した時のバスの状態を監視することで，他のデバイスからの同時メッセージ送信が存在していても自己の識別子が最も優先順位が高いか否かをチェックする。そして，優先順位が低ければ，メッセージの送信を停止する。また，エラー監視は，例えば，バスＢＵＳ−１のショートや，送信したメッセージに対するアクノリッジ信号の受信の確認などである。特に，メッセージ送信制御において，メッセージ送信開始からアクノリッジ信号受信までの時間をタイマーにより監視し，タイマー値が所定の閾値に達してもアクノリッジ信号を受信しない場合に，送信失敗を検出する。また，他のデバイスからのメッセージに対しては，その識別子が受信インターフェース２８に受信され，ＣＰＵにより自分宛のメッセージであることが検出されたときは，通信コントローラ２２は，そのメッセージを受信インターフェース２８に受信させ，受信完了時にアクノリッジ信号を返信する。

通信コントローラ２２は，メッセージの送信失敗を検出した時は，ＣＰＵに送信失敗を通知する。ＣＰＵは，その送信失敗に応答して，自ら通常リセット割り込みをかけて，ＣＰＵによるソフトウエアリセットを実行し，メモリやレジスタ類の初期化を行う。このように，デバイスが自ら通信状態を監視し，通信エラーが検出された時に，ＣＰＵに割り込みをかけてソフトウエアリセットを実行して故障状態をリセットする。かかるソフトウエアリセットを，本明細書では通常リセットと称する。

デバイスＥＣＵ２も，デバイスＥＣＵ１と同様の内部構成を有する。したがって，デバイスＥＣＵ２も，内蔵する通信コントローラにより，バスがアイドル状態の時に自発的にメッセージの送信を開始し，送信権のアービトレーション処理を行う。また通信の状態を監視して，通信エラー時に通常リセットを実行する。

図４は，デバイスＥＣＵ１，２間のメッセージの送受信状態を示す図である。デバイスＥＣＵ１がメッセージ１を送信し，デバイスＥＣＵ２が受信すると，デバイスＥＣＵ２は，それに応答してアクノリッジ信号ＡＣＫを送信する。メッセージを構成するフレームは，例えば図示されるように，フレームの開始を示すスタートオブフレームＳＯＦ，識別子のアービトレーションフィールドＡＢＦ，メッセージの内容が格納されるデータフィールドＤＡＴＡＦ，送信先からアサートされるアクノリッジフィールドＡＣＫ，そしてフレームの終了を示すエンドオブフレームＥＯＦの順に構成されている。そして，送信元デバイ
スは，バスがアイドル状態の時に，スタートオブフレームをバスに出力して送信開始を他のデバイスに宣言し，その後，アービトレーションフィールドやデータフィールドを送信する。それに応答して，送信先デバイスはアクノリッジフィールドのアクノリッジ信号を返信し，送信元デバイスがそのアクノリッジ信号を確認すると，エンドオブフレームをバスに出力して，送信終了を他のデバイスに宣言する。以上の送受信が正常に行われた時に，送信元デバイスは正常送信を確認する。

このようにエンドオブフレームの直前に設けられたアクノリッジフィールドを利用して，受信したデバイスＥＣＵ２が上記アクノリッジ信号ＡＣＫを送信する。このアクノリッジ信号ＡＣＫを確認することにより，送信元のデバイスＥＣＵ１は，そのフレームが無事に送信され受信されたことを確認することができる。

各デバイスは，少なくとも定期的に送信するメッセージを有し，あらかじめ定められた周期で当該定期メッセージを送信する。したがって，この定期メッセージが定められた周期で送信されている間は，その送信元デバイスは正常状態であることを確認することができる。一方，定期メッセージが定められた周期で送信されなくなると，その送信元デバイスに異常が発生したと推測することができる。

更に，各デバイスは，定期メッセージ以外の通常メッセージを，対応するイベント発生時に送信する。したがって，ある一定の期間なにも通常メッセージが送信されていない場合も，その通常メッセージを送信するデバイスに異常が発生したと推測することができる。例えば，図４中のメッセージ１が一例である。

図４では，デバイスＥＣＵ１がメッセージ２に対応するアクノリッジ信号ＡＣＫを受信することができずに，同じメッセージ２を繰り返し送信したことが示されている。このように，同じメッセージが繰り返し送信された場合は，その原因として，第１に，送信元デバイスによるメッセージの送出に原因がある，第２に，送信先デバイスによるメッセージの受信に原因がある，第３に，送信先デバイスによるアクノリッジ信号ＡＣＫの送出に原因がある，そして，第４に，送信元デバイスによるアクノリッジ信号ＡＣＫの受信に原因がある，が考えられる。したがって，同じメッセージが繰り返し送信された場合は，送信元デバイスか送信先デバイスに異常が発生したと推測することができる。

そこで，図２のゲートウエイユニット内のデバイス故障診断手段１２は，バスＢＵＳ−１上に送信される定期メッセージやその他の通常メッセージを常時監視し，定期メッセージが送信されなくなった場合や，通常メッセージが全く送信されなくなった場合や，同じメッセージが異常な回数繰り返し送信される場合などを検出した場合は，それに対応する送信元デバイスや送信先デバイスに異常が発生したものと推測し，通常リセット要求のメッセージをその異常デバイスに送信する。この通常リセット要求メッセージに対して，各デバイスの通信コントローラ２２は，そのメッセージを受信制御し，各デバイスのＣＰＵが，通常リセット要求メッセージに応答して，ソフトウエアリセットすべきか否かを，自己のデバイスによる通信エラー監視結果と比較するなどして再チェックする。その結果，通常リセットすべき場合に限り，ＣＰＵは，ソフトウエアリセットを実行し，当該通常リセットを実行したことを示すメッセージをゲートウエイユニット１０に返信する。ソフトウエアリセットすべきでない場合は，ＣＰＵは，通常リセットを拒否するメッセージをゲートウエイユニット１０に返信する。

このように，ゲートウエイユニット１０は，バス間のメッセージの転送機能に加えて，デバイス故障診断機能を有し，そのデバイス故障診断機能によれば，バス内のメッセージの送信状況を監視して，異常が発生したと推測されるデバイスに対して通常リセット要求のメッセージを送信する。この通常リセット要求のメッセージに対して，各デバイスは，
通常リセットを実施するか否かを自分で再度判断する。これにより，無用のデバイスのソフトウエアリセットを回避することができ，ネットワークシステムの信頼性を高めることができる。また，ゲートウエイユニット１０は，通常リセット要求が受け入れられない場合など，異常の蓋然性が高い場合は，通常リセット要求メッセージとは異なる強制リセット信号を故障デバイスのＣＰＵに直接送信し，デバイス内の通信コントローラ２２を経由することなく，ＣＰＵにリセット割り込みをかけて，ソフトウエアリセットを実行させる。

図５は，本実施の形態におけるデバイス故障診断制御のフローチャート図である。このデバイス故障診断制御は，ゲートウエイユニット１０内のデバイス故障診断手段１２が，監視対象のデバイスに対してそれぞれ行う診断制御である。また，破線の工程は，デバイス故障診断手段による処理ではなく，架空の処理またはデバイスによる処理を意味する。

まず，後述する不要応答回数Ｎを初期化する（Ｓ１０）。そして，デバイス故障診断手段１２は，バス上に送信される転送対象のメッセージに加えて，バス内で送信されるメッセージも受信して監視する。そのために，ゲートウエイユニット１０では，転送対象メッセージの識別子に加えて，故障診断のために監視すべきメッセージの識別子も登録されている。まず，デバイス故障診断手段１２は，監視対象のデバイスが所定の周期で送信する定期メッセージの受信周期を監視する（Ｓ１２）。定期メッセージの受信周期を監視し，所定の周期で受信している場合は正常状態と見なされ（Ｓ１２のＹＥＳ），所定の周期で受信していない場合は異常状態と見なされる（Ｓ１２のＮＯ）。また，監視対象デバイスからのメッセージを連続して異常な回数受信しているか否かを監視する（Ｓ１４）。この異常な回数とは，通常の通信制御ではありえないような大きな回数であり，メッセージの送信とアクノリッジ信号の受信などが正常に行われずに，メッセージが繰り返し送信されている場合の回数である。連続して異常回数受信していなければ，そのデバイスは正常とみなされる（Ｓ１６）。更に，デバイス故障診断手段１２は，監視対象のデバイスから通常メッセージを長い期間全く受信していないかも監視する（Ｓ１８）。全く受信していない場合も（Ｓ１８のＮＯ），故障の可能性が疑われる。

図５では，定期メッセージを所定の周期で受信していない場合（Ｓ１２のＮＯ）と，通常メッセージを一定期間全く受信していない場合（Ｓ１８のＮＯ）とのＡＮＤ条件で，工程Ｓ２０以下の異常復帰処理が行われるが，これらのＯＲ条件で工程Ｓ２０以下の異常復帰処理が行われても良い。

次に，工程Ｓ２０以下の異常復帰処理について説明する。定期メッセージの所定周期での受信がない場合（Ｓ１２のＮＯ），通常メッセージの所定期間にわたる受信が全くない場合（Ｓ１８のＮＯ），または，同じメッセージを連続して受信する場合（Ｓ１３のＹＥＳ），デバイス故障診断手段１２は，監視デバイスの故障を認定する（Ｓ２０）。そして，監視デバイスに対して，通常リセット処理要求のメッセージを送信する（Ｓ２２）。この通常リセット処理要求のメッセージは，ＣＡＮバスプロトコルに準拠したものであり，監視デバイスは，このメッセージを通信コントローラ２２により受信することができ，それに応答して，監視デバイスのＣＰＵは，ソフトウエアリセットを実行すべきか否かをチェックし，必要であればソフトウエアリセットを実行し（Ｓ３６），通常リセット実行完のメッセージをゲートウエイユニット１０に返信する（Ｓ２４）。したがって，単にゲートウエイユニット１０のデバイス故障診断手段１２が，監視対象デバイスの異常または故障を検出しても，監視対象デバイスのＣＰＵによりそのリセットの必要性がチェックされ，必要な場合のみソフトウエアリセットが行われるので，故障診断の信頼性を高めることができる。

監視対象デバイスは，通常リセット要求メッセージに対して，ソフトウエアリセット不
要と判断する場合は，ゲートウエイユニット１０に通常リセット不要のメッセージを返信する（Ｓ２６）。そのような返信があった場合は（Ｓ２６のＹＥＳ），不要応答回数Ｎをインクリメントする（Ｓ３０）。そして，その回数Ｎが所定の閾値回数Ｖｔｈを超える場合は（Ｓ３２のＹＥＳ），強制リセット信号を出力する（Ｓ３４）。また，監視対象のデバイスから，通常リセット実行完の応答も，通常リセット不要の応答も受信しない場合には（Ｓ２４のＮＯとＳ２６のＮＯ），監視対象デバイスの故障の蓋然性が高いので，その場合も強制リセット信号を出力する（Ｓ３４）。

この強制リセット信号は，通常のＣＡＮプロトコルに準拠されていないリセット信号であり，メッセージではない。例えば，図４に示されるとおり，通常のメッセージフレームでは使用されないデータパターンの信号からなる。かかる強制リセット信号は，バスＢＵＳ−１に出力され，図３に示した強制リセット検出回路ＲＳＴにより検出され，リセットポートＲＰＯＲＴを介して，監視対象デバイスのＣＰＵに対し，ソフトウエアリセットの割り込み信号として与えられる。つまり，通常リセット要求メッセージのようにデバイスの通信コントローラによるメッセージ受信を経ることなく，別の特別のリセットポートＲＰＯＲＴからＣＰＵに対してリセット割り込みをかけるものである。これにより，ＣＰＵは，故障の再確認をすることなく強制的にソフトウエアリセットを実行し，メモリやレジスタ類の初期化を行う。

図５において，通常リセット不要のメッセージを受信した場合（Ｓ２６のＹＥＳ），デバイス故障診断手段１２は，送信先デバイスの故障を検出し，そのデバイスの監視制御による異常復帰処理を促してもよい（Ｓ２８）。これに応答して，送信先デバイスを監視対象とするデバイス故障診断制御において，構成Ｓ２２〜Ｓ３６からなる通常リセット処理要求メッセージと強制リセット信号出力とからなる異常復帰処理が行われる。これは，同一のメッセージを連続して受信した場合は，送信先デバイスが異常状態になっている可能性があるからである。

デバイス故障診断手段１２は，通常リセット実行完のメッセージを受信した場合と，強制リセット信号を出力した場合は，不要応答回数Ｎを初期化する（Ｓ１０）。

以上のとおり，ゲートウエイユニット１０のデバイス故障診断手段１２は，バス上のメッセージを監視し，所定の状況を検出したらそのメッセージを送信すべき監視対象デバイスに異常が発生したものとして，通常リセット要求メッセージを送信し，ソフトウエアリセットを促す。そして，通常リセット要求メッセージに対して何ら応答がない場合は，通常リセット要求を何回も拒否する場合は，通常リセット要求メッセージとは異なるルートで，強制リセット信号を監視対象デバイスに与える。それにより，より信頼性の高い故障診断と，より安全な故障復帰処理とを実現することができる。しかも，マルチマスタ方式に変更を加えることなく，専用の故障診断用ＥＣＵを設ける必要もなく，バス内のメッセージを監視する機能を有するゲートウエイ装置によりデバイス故障診断を行わせることができる。

ゲートウエイ装置の構成とメッセージの転送動作を示す図である。本実施の形態におけるゲートウエイユニットの詳細構成を示す図である。デバイスの詳細構成図である。デバイスＥＣＵ１，２間のメッセージの送受信状態を示す図である。本実施の形態におけるデバイス故障診断制御のフローチャート図である。

符号の説明

ＥＣＵ１〜４：デバイス，ＢＵＳ−１，２：ＣＡＮバス
１０：ゲートウエイ装置（ゲートウエイユニット）
１２：デバイス故障診断手段ＴＣＯＮ：転送コントローラ（転送制御手段）
Ｔ−ＱＵＥ：送信キューバッファＭＥＳ１，２：メッセージ

Claims

複数のデバイスがそれぞれ接続される複数のバスの間に設けられ，前記バス間のメッセージを転送するゲートウエイ装置であって，
前記デバイスは，それぞれがマスタとして，前記バスがアイドル状態の時に自主的にメッセージ送信を行い，
前記ゲートウエイ装置は，前記複数のバス内の定期的に送信される定期メッセージをそれぞれ監視し，当該定期メッセージの通信状況から故障デバイスを検出し，当該故障デバイスに対してリセットを行わせることを特徴とするゲートウエイ装置。
請求項１において，
監視対象のデバイスが連続して同一のメッセージをバス上に送信を繰り返すか否かを監視し，当該連続送信を検出した時は，前記監視対象のデバイスに前記リセットを行わせることを特徴とするゲートウエイ装置。
請求項１において，
監視対象のデバイスからメッセージを所定の期間受信しているか否かを監視し，当該メッセージを受信していないことを検出した時は，前記監視対象のデバイスに前記リセットを行わせることを特徴とするゲートウエイ装置。
請求項１乃至３のいずれかにおいて，
前記デバイスは，バスの通信状況に基づいて自主的にリセットする通常リセット機能を有し，前記ゲートウエイ装置は，故障デバイスに対して前記通常リセットを要求すると共に，当該通常リセット要求が故障デバイスで受け付けられなかった場合に強制リセット信号を供給して前記通常リセット要求とは異なるルートで前記故障デバイスにリセットを行わせることを特徴とするゲートウエイ装置。
請求項４において，
前記通常リセット要求は，メッセージとしてゲートウエイ装置が故障デバイスに送信し，前記強制リセット信号は，前記メッセージとは異なる信号パターンであり，ゲートウエイ装置が故障デバイスに送信することを特徴とするゲートウエイ装置。
請求項４において，
前記ゲートウエイ装置は，前記バス上に送信されるメッセージとは異なるパターンの強制リセット信号を前記バスに送信することで前記通常リセットを要求し，
当該強制リセット信号は，前記パターンを検出してリセット割り込み信号を故障デバイスに与える強制リセット信号検出手段を介して前記故障デバイスに供給されることを特徴とするゲートウエイ装置。