(57)【要約】【課題】受信メッセージを過剰に受信した場合でも送信ノードが故障か否かを正確に判断できる通信装置、及び通信装置による故障判定方法を提供すること。受信メッセージが増大してもシステムの破綻を回避できるようにした通信装置等を提供すること。【解決手段】複数の通信装置とバスを介して接続され、前記複数の通信装置から一通信単位であるフレームを受信する通信装置において、前記フレームを他の通信装置から受信する受信部と、前記フレームを連続して受信した際の受信間隔が所定時間以下であり、かつ、前記連続して受信したフレームが同一の通信装置からのフレームであった場合には、連続したフレームを送信してきた通信装置は故障であると判定する故障判定部とを備える。【選択図】図３
2009171310.tif 000002
【特許請求の範囲】
【請求項１】
複数の通信装置とバスを介して接続され、前記複数の通信装置から一通信単位であるフレームを受信する通信装置において、
前記フレームを他の通信装置から受信する受信部と、
前記フレームを連続して受信した際の受信間隔が所定時間以下であり、かつ、前記連続して受信したフレームが同一の通信装置からのフレームであった場合には、連続したフレームを送信してきた通信装置は故障であると判定する故障判定部と
を備えることを特徴とする通信装置。
【請求項２】
更に、前記故障判定部により故障と判定された前記通信装置からのフレームを廃棄するフェールセーフ処理部を備えることを特徴とする請求項１記載の通信装置。
【請求項３】
前記フレームには、当該フレームを送信する前記通信装置を識別するとともに他のフレームとを識別する識別符号が挿入され、
前記故障判定部は、前記フレームを連続して受信し、かつ、前記識別符号が同一の前記フレームを受信したときに、前記通信装置は故障であると判定することを特徴とする請求項１記載の通信装置。
【請求項４】
前記故障判定部は、前記フレームを連続して受信し、かつ、前記識別符号が同一でないときでも同一の前記通信装置からのフレームを受信したとき、前記通信装置は故障であると判定することを特徴とする請求項３記載の通信装置。
【請求項５】
前記故障判定部は、故障と判断した前記通信装置以外の他の通信装置からのフレームを受信しても、当該通信装置に対する故障判定は行わないことを特徴とする請求項１記載の通信装置。
【請求項６】
前記故障判定部は、前記フレームを連続して受信しても、異なる前記通信装置からの前記フレームを受信したときは仮異常と判定し、当該仮異常の判定回数が閾値を超えたときに当該通信装置は故障であると判定することを特徴とする請求項１記載の通信装置。
【請求項７】
複数の通信装置とバスを介して接続され、前記複数の通信装置から一通信単位であるフレームを受信する通信装置における故障判定方法において、
前記フレームを他の通信装置から受信し、
前記フレームを連続して受信した際の受信間隔が所定時間以下であり、かつ、前記連続して受信したフレームが同一の通信装置からのフレームであった場合には、連続したフレームを送信してきた通信装置は故障であると判定する、
ことを特徴とする故障判定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信装置における故障判定方法に関する。
【背景技術】
【０００２】
昨今、自動車の車載ネットワークとしてＣＡＮ（Controller Area Network）プロトコルが注目されつつある（例えば、以下の非特許文献１及び２）。ＣＡＮは、ＩＳＯ（International Organization for Standardization）で国際的に標準化されたシリアル通信プロトコルである。
【０００３】
ＣＡＮプロトコルの特徴は、バスが空いているときにすべてのノードがフレーム（又はメッセージ、ＣＡＮプロトコルの通信単位）を送信することができるマルチマスタ方式を採用している点や、同時にフレームを送信したときは優先順位の高い識別子（ＩＤ）のフレームを送信するノードが送信権を得る、などがある。
【０００４】
ＣＡＮ通信プロトコルは、マルチマスタ方式を採用するため、時間あたりの受信メッセージ数は送信ノード次第で変化する。送信ノードが故障した場合、例えば、受信ノードではメッセージを多数受信する。受信負荷が増大すると、システムが正常に動作しない場合も考えられる。
【０００５】
したがって、送信ノードの故障を判断することは極めて重要なことである。しかし、かかる判断は困難な場合が多い。受信メッセージを多数受信した場合に、受信ノードの起動時に発生する一時的なメッセージの増大による場合もあるからである。
【０００６】
図６（Ａ）及び同図（Ｂ）はメッセージの送信例を示す図である。すなわち、同図（Ａ）は、受信ノード１００の電源をオンにしたときに、送信ノードＡ１２０〜Ｃ１４０からのメッセージが一時的に受信ノード１００において受信される場合の例を示す。また、同図（Ｂ）は送信ノードＡ１２０の故障により受信ノード１００において大量にメッセージを受信する場合の例である。したがって、この両者を区別して、送信ノードの故障（図６（Ｂ））を正確に判定することが重要である。
【０００７】
従来では、かかるノードの異常検出に関し、異常データの車両ＩＤを記憶部に記憶し、その回数が規定回数以上であればその車両ＩＤを持つ車両の送信装置が異常であると判断する車両用通信装置がある（例えば、以下の特許文献１）。
【０００８】
一方、連続して同一データを受信しても、優先順位の高いＩＤのフレームによる送信があったものとして異常とは判定しない多重通信システムも開示される（例えば、以下の特許文献２）
【非特許文献１】「ＣＡＮ入門書」www.renesas.com
【非特許文献２】「ＣＡＮとは？」www.toyo.co.jp/car/CAN/CAN_General.htm
【特許文献１】特開２００６−２９５８３６号公報
【特許文献２】特開平６−３３４６６３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、上述した特許文献はいずれも受信メッセージを大量に受信したとき、どのように判断するかについては何ら記載されていない。したがって、従来では、過剰に受信するメッセージに対して、送信ノードが故障なのか否かを判断することはできなかった。
【００１０】
このような受信メッセージの増大に対して、受信側ノードでメッセージの受信間隔により故障か否かを判断することも考えられる。
【００１１】
しかし、上述したように起動時による一時的なものによる場合（図６（Ａ）参照）もあり、受信間隔からは両者を区別することはできない。
【００１２】
そこで、本発明は上記問題点に鑑みてなされたもので、その目的は受信メッセージを過剰に受信した場合でも送信ノードが故障か否かを正確に判断できる通信装置、及び通信装置による故障判定方法を提供することである。
【００１３】
また、本発明の他の目的は受信メッセージが増大してもシステムの破綻を回避できるようにした通信装置等を提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するために、本発明の一実施態様によれば、複数の通信装置とバスを介して接続され、前記複数の通信装置から一通信単位であるフレームを受信する通信装置において、前記フレームを他の通信装置から受信する受信部と、前記フレームを連続して受信した際の受信間隔が所定時間以下であり、かつ、前記連続して受信したフレームが同一の通信装置からのフレームであった場合には、連続したフレームを送信してきた通信装置は故障であると判定する故障判定部とを備えることを特徴とする。
【００１５】
また、上記通信装置において、前記故障判定部により故障と判定された前記通信装置からのフレームを廃棄するフェールセーフ処理部を更に備えることを特徴とする。
【００１６】
更に、上記通信装置において、前記フレームには、当該フレームを送信する前記通信装置を識別するとともに他のフレームとを識別する識別符号が挿入され、前記故障判定部は、前記フレームを連続して受信し、かつ、前記識別符号が同一の前記フレームを受信したときに、前記通信装置は故障であると判定することを特徴とする。
【００１７】
更に、上記通信装置において、前記故障判定部は、前記フレームを連続して受信し、かつ、前記識別符号が同一でないときでも同一の前記通信装置からのフレームを受信したとき、前記通信装置は故障であると判定することを特徴とする。
【００１８】
更に、上記通信装置において、前記故障判定部は、故障と判断した前記通信装置以外の他の通信装置からのフレームを受信しても、当該通信装置に対する故障判定は行わないことを特徴とする。
【００１９】
更に、上記通信装置において、前記故障判定部は、前記フレームを連続して受信しても、異なる前記通信装置からの前記フレームを受信したときは仮異常と判定し、当該仮異常の判定回数が閾値を超えたときに当該通信装置は故障であると判定することを特徴とする。
【００２０】
また、上記目的を達成するために、本発明の他の実施態様によれば、複数の通信装置とバスを介して接続され、前記複数の通信装置から一通信単位であるフレームを受信する通信装置における故障判定方法において、前記フレームを他の通信装置から受信し、前記フレームを連続して受信した際の受信間隔が所定時間以下であり、かつ、前記連続して受信したフレームが同一の通信装置からのフレームであった場合には、連続したフレームを送信してきた通信装置は故障であると判定することを特徴とする。
【発明の効果】
【００２１】
本発明によれば、受信メッセージを過剰に受信した場合でも送信ノードが故障か否かを正確に判断できる通信装置、及び通信装置による故障判定方法を提供できる。また、本発明によれば、受信メッセージが増大してもシステムの破綻を回避できるようにした通信装置等を提供できる。
【発明を実施するための最良の形態】
【００２２】
本発明を実施するための最良の形態について、以下図面を参照しながら説明する。図１は、車載ネットワークシステム１の一例である。本車載ネットワークシステム１は複数のノード（以下、ＥＣＵ：Electric Control Unit）１０，２１〜２４がバス３０を介して接続される。バス３０の通信プロトコルはＣＡＮプロトコルである。マルチマスタ方式を採用する他の通信プロトコルでも実施可能である。
【００２３】
尚、各ＥＣＵ１０，２１〜２４が車両用通信装置の一例であり、自動車の各ハードウェアを制御する。ＥＣＵの例として、エンジンやトランスミッション等を制御するエンジン系のＥＣＵや、ＶＩＣＳナビなどを制御する情報系のＥＣＵなどがある。
【００２４】
ここで、各ＥＣＵ１０，２１〜２４は同一構成であり、ＥＣＵ１０を代表して説明する。ＥＣＵ１０は、マイコン１１とＣＡＮトランシーバ１２とを備える。
【００２５】
マイコン１１は、各種処理を行うところであり、ＲＡＭ１１０と、ＲＯＭ１１１と、演算部１１２と、ＣＡＮコントローラ１１３、及びＩ／Ｏ１１４を備える。
【００２６】
ＲＯＭ１１１は後述する故障判定処理やフェールセーフ処理等の各種処理を実行するためのプログラムを記憶する。演算部１１２はＲＯＭ１１１からプログラムを読み出して、実際に各種処理を実行する。ＲＡＭ１１０は演算部１１２の処理による実行データ等が記憶される。
【００２７】
ＣＡＮコントローラ１１３は、ＣＡＮ通信プロトコルによるデータ（フレーム又はメッセージ、ＣＡＮプロトコルの通信単位）を生成してＣＡＮトランシーバ１２に出力したり、ＣＡＮトランシーバ１２からのデータをマイコン１１で処理できるデータに変換等する。Ｉ／Ｏ１１４は、他の外部装置に対するデータの入出力を制御するインターフェースである。
【００２８】
ＣＡＮトランシーバ１２は、バス３０と接続され、他ＥＣＵ２１〜２４からのフレームを受信してＣＡＮコントローラ１１３に出力し、ＣＡＮコントローラ１１３からのフレームを他のＥＣＵ２１〜２４に送信する。
【００２９】
次に、このように構成された車両用通信装置であるＥＣＵ１０の動作について説明する。図２は全体処理の例を示し、図３は異常判定処理の例、図４はフェールセーフ処理の例を示す。
【００３０】
図２に示すように、本処理が開始されると（Ｓ１０）、マイコン１１の演算部１１２は異常処理判定処理を実行する（Ｓ１１）。
【００３１】
異常判定処理に移行すると、演算部１１２は送信側が正常であることを確認し（図３のＳ１１０）、送信完了割込みが発生したか否かを判断する（Ｓ１１１）。つまり、演算部１１２は送信側のＥＣＵ２１〜２４が故障しておらず、送信側のＥＣＵ２１〜２４からメッセージの送信が完了した後で実際に本処理を行う。
【００３２】
送信完了割込みが発生していないと（Ｓ１１１でＮ）、異常判定処理が終了する（Ｓ１１６）。一方、送信完了割込みが発生すると（Ｓ１１１でＹ）、演算部１１２はバスオフが発生していないか否か確認する（Ｓ１１２）。バスオフとは、送信側のＥＣＵ２１〜２４からメッセージの送信が停止している状態のことである。一定のメッセージを他のＥＣＵ２１〜２４から受信することで判断する。
【００３３】
バスオフが発生したときは（Ｓ１１２でＮ）、以後当該送信側ＥＣＵ２１〜２４の送信異常を判定する理由はないため、異常判定処理は終了する（Ｓ１１６）。一方、バスオフが発生していないとき（Ｓ１１２でＹ）は、演算部１１２は受信メッセージの受信間隔が短いか否か、すなわち連続してメッセージを受信したか否かを判断する（Ｓ１１３）。例えば、ＲＡＭ１１０に閾値が記憶され、演算部１１２は閾値と受信間隔とを比較して、受信間隔が閾値より大きいと受信間隔は長いと判断し、その逆のときは短いと判断する。あるいは、一定期間受信間隔を測定し、その間隔と閾値とを比較することで判断してもよい。
【００３４】
通常、各ＥＣＵ２１〜２４は、「１秒」等の長い間隔でメッセージを送信する。従って、メッセージの受信間隔が短いときは送信側ＥＣＵ２１〜２４において何らかの故障が発生していると考えることができる。よって、演算部１１２は受信間隔が長いとき（Ｓ１１３でＮ）、送信先のＥＣＵ２１〜２４は故障と判定することなく処理を終了する（Ｓ１１６）。
【００３５】
一方、受信間隔が短いとき（Ｓ１１３でＹ）、演算部１１２は受信したメッセージが同じＩＤか否かを判断する（Ｓ１１４）。ＣＡＮプロトコルでは、予め各ＥＣＵ１０，２１〜２４から送信される各メッセージにバス送信権獲得のためにＩＤが付与されており、メッセージ内に当該ＩＤ挿入されている。従って、演算部１１２は受信メッセージからＩＤを抽出することで同じＩＤか否かを判断できる。
【００３６】
このように同一ＩＤか否かを判断しているのは、受信間隔の短いメッセージを受信しているときにそのメッセージのＩＤが同一のときは、送信側ＥＣＵ２１〜２４で何らかの故障により同一メッセージを何度も送信していると考えることができるからである。
【００３７】
なお、このＩＤに関し、各ＥＣＵ１０，２１〜２４では使用するＩＤがＥＣＵ１０，２１〜２４ごとに予め決められており、例えば、ＥＣＵ２１は「１」から「１０」、ＥＣＵ２２は「１１」から「２０」等である。
【００３８】
同一ＩＤのとき（Ｓ１１４でＹ）、演算部１１２は当該受信メッセージの送信先のＥＣＵ２１〜２４は故障と判断する（Ｓ１１５）。
【００３９】
一方、同一ＩＤのメッセージを受信していないとき（Ｓ１１４でＮ）、演算部１１２は同じＥＣＵ２１〜２４からの異なるＩＤか否かを判断する（Ｓ１１８）。同じＥＣＵ２１〜２４からの受信メッセージか否かは上述したＩＤから判断できる。例えば、ＩＤが「３」のときＥＣＵ２１からのメッセージ、ＩＤが「２０」のときＥＣＵ２２からのメッセージ等である。
【００４０】
このように同一ＩＤのメッセージでないときに、同じＥＣＵ２１〜２４からのメッセージか否かを判断しているのは、送信側のＥＣＵ２１〜２４で何らかの故障が発生すると短い受信間隔で同一ＩＤのメッセージを送信することのみならず異なるＩＤのメッセージも送信することが考えられるからである。
【００４１】
したがって、演算部１１２は同じＥＣＵ２１〜２４からの異なるＩＤを受信したとき（Ｓ１１８でＹ）、送信先のＥＣＵ２１〜２４は故障と判断する（Ｓ１１９）。
【００４２】
一方、演算部１１２は、同じＥＣＵ２１〜２４からの異なるＩＤを受信しないとき（Ｓ１１８でＮ）、故障と判定することなく故障判定処理を終了する（Ｓ１１６）。つまり、演算部１１２は、受信メッセージの受信間隔が短くても、同一ＩＤのメッセージではなく、異なるＥＣＵ２１〜２４からのメッセージであれば、故障と判定しない。異なるＥＣＵ２１〜２４から順次メッセージが送信されているからである。
【００４３】
より具体的な例で故障判定処理を説明する。図５はかかる例を説明するための図である。ＥＣＵ２１はＩＤが「Ａ１」、「Ａ２」、「Ａ３」のメッセージをそれぞれ送信する。ＥＣＵ２２は、ＩＤが「Ｂ１」、「Ｂ２」、「Ｂ３」のメッセージを送信する。ＥＣＵ２３はＩＤが「Ｃ１」、「Ｃ２」、「Ｃ３」のメッセージを送信する。
【００４４】
例えば、ＥＣＵ１０が「Ａ１」、「Ｂ１」、「Ｃ１」のメッセージを順次受信したときを考える。この場合は、受信間隔が短くても（Ｓ１１３でＹ）、同一ＩＤではなく（Ｓ１１４でＮ）、同じＥＣＵ２１〜２４からのメッセージではない（Ｓ１１８でＮ）ため、故障と判定しない。異なるＥＣＵ２１〜２４からのメッセージを短い受信間隔で受信したためである。
【００４５】
また、ＥＣＵ１０は、「Ａ１」、「Ａ１」、「Ａ１」のメッセージを順次受信したとき、受信間隔が短いと（Ｓ１１３でＹ）、同一ＩＤのため（Ｓ１１４でＹ）、当該メッセージを送信したＥＣＵ２１は故障と判定する（Ｓ１１５）。
【００４６】
さらに、ＥＣＵ１０は、「Ａ１」、「Ａ２」、「Ａ３」のメッセージを順次受信したとき、受信間隔が短いと（Ｓ１１３でＹ）、同じＥＣＵ２１からのメッセージであるため（Ｓ１１８でＹ）、ＥＣＵ２１は故障と判定する。ただし、ＥＣＵ１０は「Ａ１」、「Ａ２」、「Ａ３」のメッセージを受信しても受信間隔が長いとき（Ｓ１１３でＮ）、故障と判定しない。
【００４７】
図３の異常判定処理が終了すると、図２に戻り、演算部１１２は送信側が異常か否かを判断する（Ｓ１２）。演算部１１２は、異常判定処理により、送信側故障と判断したとき（Ｓ１１５、Ｓ１１９）、異常と判断し（Ｓ１２でＹ）、そうでないと異常ではないと判断する（Ｓ１２でＮ）。
【００４８】
送信側が異常のとき（Ｓ１２でＹ）、演算部１１２はフェールセーフ処理を行う（Ｓ１３）。一方、送信側に異常がないとき（Ｓ１２でＮ）、演算部１１２はフェールセーフ処理を行うことなく一連の処理を終了する（Ｓ１４）。
【００４９】
図４はフェールセーフ処理の例を示すフローチャートである。本処理に移行すると、演算部１１２は送信側異常か否かを判断する（Ｓ１３０）。異常でないと（Ｓ１３０でＮ）、フェールセーフ処理は終了する（Ｓ１３４）。
【００５０】
一方、送信側のＥＣＵ２１〜２４が異常のとき（Ｓ１３０でＹ）、演算部１１２は受信フィルタ処理を行う（Ｓ１３１）。受信フィルタ処理とは、故障対象のＥＣＵ２１〜２４からの受信メッセージを廃棄する処理のことである。
【００５１】
次いで、演算部１１２は故障判定した送信先のＥＣＵ２１〜２４の識別情報をＲＡＭ１１０に記憶する（Ｓ１３２）。
【００５２】
次いで、演算部１１２は記憶した情報を外部に通知する（Ｓ１３３）。例えば、ＥＣＵ１０は故障対象のＥＣＵ２１〜２４や故障対象でないＥＣＵ２１〜２４に通知する。故障対象のＥＣＵ２１〜２４に通知するのは、故障対象のＥＣＵであることを当該ＥＣＵ２１〜２４に伝えるためである。また、他のＥＣＵ２１〜２４に通知するのは、故障対象のＥＣＵ２１〜２４からのメッセージに対してフェールセーフ等の何らかの対策を講じさせるためである。
【００５３】
そして、フェールセーフ処理が終了し（Ｓ１３４）、図２に戻り一連の処理が終了する（Ｓ１４）。
【００５４】
このように、本ＥＣＵ１０においては、受信間隔（Ｓ１１３）のみならず、メッセージのＩＤ（Ｓ１１４）や、ノード別の頻度（Ｓ１１８）を加味して故障判定を行うため、受信間隔のみによる場合と比較して、受信メッセージを過剰に受信した場合でも送信ノードが故障か否かを正確に判断できる。
【００５５】
また、本ＥＣＵ１０は、他のＥＣＵ２１〜２４に故障判定したＥＣＵ２１〜２４の情報を通知しているため（Ｓ１３３）、他のＥＣＵ２１〜２４ではその情報に基づいて何らかのフェールセーフ処理を実行でき、受信メッセージ増大による車載ネットワークシステム１の破綻を回避することができる。また、故障判定したＥＣＵ１０においても受信フィルタ処理（Ｓ１３１）によるフェールセーフが実行されるため、受信メッセージの増大によるシステム破綻を回避できる。
【００５６】
上述した例において、さらに以下に示す他の例も実施可能である。すなわち、異常判定処理（Ｓ１３、図３）において、演算部１１２は、受信メッセージの受信間隔が短く（Ｓ１１３でＹ）、受信メッセージが同一ＩＤではなく（Ｓ１１４でＮ）、同じＥＣＵ２１〜２４からのものではないとき（Ｓ１１８でＮ）、故障と判定していない。例えば、短い受信間隔で「Ａ１」、「Ｂ１」、「Ｃ１」のＩＤを持つメッセージを受信したとき等である。この場合に、演算部１１２は「仮異常」と判定し、電源投入時からの発生回数をＲＡＭ１１０に記憶し、所定回数上回ったとき異常と判定してもよい。あるいは、一定回数連続して発生したときに異常と判定してもよい。例えば、「Ａ１」〜「Ｃ１」を受信した後、短い受信間隔で再び「Ａ１」〜「Ｃ１」を受信したとき、何らかの異常の発生が考えられるからである。
【００５７】
また、演算部１１２は、あるＥＣＵ２１〜２４を故障と判定したとき（Ｓ１１５，Ｓ１１９）、故障していない他のＥＣＵ２１〜２４からの受信フレームによる異常判定は行わないようにしてもよい。例えば、演算部１１２はＥＣＵ２１を故障と判定したとき、ＥＣＵ２２からの受信メッセージは正常であるにも拘わらず、故障したＥＣＵ２１からの受信メッセージによりバス３０が占有され正常に受信できず、通信途絶による異常と判定されてしまう可能性があるからである。
【００５８】
さらに、演算部１１２は故障と判定したとき（Ｓ１１５，Ｓ１１９）、制御用に使用されるデータに対してフェールセーフ値を公開するようにしてもよい。
【００５９】
さらに、演算部１１２は故障判定処理（Ｓ１３、図３）において、受信間隔が短いか否かを一定の時間間隔による閾値により判断した（Ｓ１１３）。それ以外にも、受信メッセージのＩＤごと、あるいは、送信ＥＣＵ２１〜２４ごとに、その間隔を異なるようにして判定（Ｓ１１３）してもよい。送信するＥＣＵ２１〜２４によりメッセージの送信間隔が他と比較して短いものがあるからである。また、同一ＩＤか否かの判定（Ｓ１１４）や、同じＥＣＵ２１〜２４からの異なるＩＤか否かの判定（Ｓ１１８）についても、一定時間間隔のみならず、その間隔をＩＤごと、あるいはＥＣＵ２１〜２４ごとに異なる時間間隔で判定してもよい。  
【００６０】
さらに、ＥＣＵ１０は車両用の通信装置に限定されず、車両用以外の通信装置としても実施可能である。
【図面の簡単な説明】
【００６１】
【図１】図１は車載ネットワークシステムの構成例を示す図である。
【図２】図２は全体処理の例を示すフローチャートである。
【図３】図３は異常判定処理の例を示すフローチャートである。
【図４】図４はフェールセーフ処理の例を示すフローチャートである。
【図５】図５は異常判定処理の具体例を説明するための図である。
【図６】図６（Ａ）及び同図（Ｂ）はメッセージの送信例を示す図である。
【符号の説明】
【００６２】
１  車載ネットワークシステム、  １０  ＥＣＵ（Electric Control Unit）、  １１  マイコン、  １２  ＣＡＮトランシーバ、  ２１〜２４  ＥＣＵ、  ３０  バス、  １１０  ＲＡＭ、  １１１  ＲＯＭ、  １１２  演算部、  １１３  ＣＡＮコントローラ、  １１４  Ｉ／Ｏ
【図１】
2009171310.tif 000003
【図２】
2009171310.tif 000004
【図３】
2009171310.tif 000005
【図４】
2009171310.tif 000006
【図５】
2009171310.tif 000007
【図６】
2009171310.tif 000008