JP2006502601A - 無線車輌通信管理システムおよび方法 - Google Patents

Abstract

無線車輌通信管理装置および方法が、車輌プロトコル変換システムおよび方法を有する。車輌プロトコル変換システムおよび方法は、車輌バスプロトコルに従って車輌バスコネクタを通じてメッセージを受信することができ、メッセージを解析して、それらが送信されるべきかを判断し、そして、それらが送信されるべき場合は、そのメッセージを無線リンクを通じて送信する。

Description

関連出願

本出願は、２００１年１０月１８日に出願された、米国特許出願番号１０／０２５，３３２、現在の合衆国特許番号 ，無線車輌通信管理システムおよび方法という名称の米国特許出願の一部継続出願であり、２００１年２月８日に出願された米国仮出願番号６０／２６８，２５４、車輌プロトコル変換装置および方法という名称の米国仮出願の利益を主張している。

本発明は、一般には、無線通信システム（ｗｉｒｅｌｅｓｓ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｓｙｓｔｅｍ）に関し、特に、無線車輌通信管理（ｗｉｒｅｌｅｓｓ ｖｅｈｉｃｕｌａｒ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｍａｎａｇｉｎｇ）システムおよび方法に関するものである。

電子コントローラ（ｅｌｅｃｔｒｏｎｉｃ ｃｏｎｔｒｏｌｌｅｒ）は、現在、例えば、エンジン、トランスミッション、そして／またはブレーキといった車輌上の様々な構成要素を制御するのに用いられる。適度に動作することによって、これらのコントローラは車輌の動作そして／または安全性を向上させる。

オペレーションにおいては、その各コントローラは、しばしば、それらのそして／またはその車輌の状態に関するデータをお互いに交換する必要がある。このデータを交換するには、そのコントローラは、通常、データを示す電気信号を伝達するために、典型的には有線または有線の集合であるバスを用いる。このようにして、バス上の信号をモニタできることは、コントローラの動作状態そして／またはその車輌の動作状態が導き出されることから有益である。さらに、多くの電子コントローラが指令を受け、そして／または制御されることから、メッセージをバスに送り出すことは有益である。

残念なことに、車輌バス上のメッセージをモニタ（ｍｏｎｉｔｏｒ）し、そして／または送り出す典型的な装置、例えば、診断コントローラは、通常、車輌バスに直接接続する必要がある。従って、これらの装置の１つがその車輌バス上のメッセージをモニタし、そして／または送り出す毎に、それはそのバスに接続されなければならず、セットアップ時間とコストが増加する。さらに、その車輌中のコネクタは、繰り返される接続によってダメージを受ける。さらに、これらの装置の多くは、大きくなりがちであり、従って、あまり持ち運びできない。従って、その車輌はその装置に接続されるために移動する必要があり、さらに時間とコストが増加する。さらに、様々な装置が様々な機能のために用いられるので、その車輌は、各装置がバス上のメッセージをモニタし、そして／または送り出すことができるようにするために何回か移動される必要があり、さらに時間とコストが増加する。

本発明は、従来の車輌バス上のメッセージを通信するシステムおよび方法に関する少なくともいくつかの問題と欠点を減少させるかそして／または消滅させる。従って、本発明は、車輌バス間でのメッセージの無線通信を管理するシステムおよび方法を提供することにある。

特定の実施例では、車輌プロトコルを変換するシステムは、バスコネクタ、プロトコルトランシーバ、コンピュータ、そして無線通信装置を含む。バスコネクタは、車輌バスに接続でき、プロトコルトランシーバは、バスコネクタに接続する。プロトコルトランシーバは、バスコネクタを通じた通信向けのメッセージを受信し、そのメッセージを車輌バスプロトコルに従ってバスコネクタを通じて送信し、そして、その車輛バスプロトコルに従って、バスコネクタを通じてメッセージを受信することができる。そのコンピュータは、プロトコルトランシーバに接続され、そのバスコネクタを通じて受信されたメッセージを解析して、それらが送信されるべきかを判断し、そのバスコネクタを通じた通信向けのメッセージを受信することができる。無線通信装置は、コンピュータに接続され、そして、無線リンクを用いて、送信されるべきメッセージを送信し、そして、そのバスコネクタを通じた通信向けのメッセージを受信することができる。

いくつかの実施例においては、車輌プロトコルの変換方法は、車輌バスプロトコルに従って、車輌バスコネクタを通じてメッセージを受信し、そのメッセージを解析して、それらが送信されるべきかを判断することを含む。その方法は、また、そのメッセージをもしそれらが送信されるべきなら無線リンクを通じて送信することを含む。

本発明は、いくつかの技術的特徴を提供する。例えば、ある実施例においては、車輌バス上のメッセージをモニタし、そして／または送り出すことを希望する装置は、そのバスに必ずしも物理的に接続される必要はなく、時間とコストが削減される。加えて、持ち運びできない装置に対して、その車輌は、その装置がそのバス上のメッセージをモニタし、そして／または送り出すことができるために移動させられる必要はなく、サービスタイムとコストを減少させる。さらに、様々な装置のそれぞれが、個別にそのバスに接続することなくそのバス上のメッセージをモニタし、そして／または送り出す。従って、その車輌は、そのバスと通信する必要がある場合に、いくつかの異なる装置に接続し、そして／またはそれらに向かって移動する必要がなく、さらに時間とコストが削減される。別の例として、特定の実施例において、装置とバス間の無線通信フォーマットは、そのバス上の全てのデータレートに適応する。従って、バス上のメッセージは、いくらかの潜伏があったとしてもその装置にタイムリーに通信することができる。さらなる例として、いくつかの実施例においては、バス上のメッセージは、その装置に送信される前にフィルタリングされる。従って、その装置は、外部から来たメッセージにおけるリソースを消費する必要はなく、そのバスとその装置の間の無線リンクの帯域は維持される。追加的な例として、ある実施例では、様々な異なる車輌バスプロトコルにおけるメッセージがその装置に対して通信し、そして／またはその装置から通信を受ける。従って、様々なタイプの装置が車輌バスからメッセージを受信し、そして／または、ある装置は、様々なプロトコルを用いるコントローラと通信する。さらなる例として、いくつかの実施例においては、ユーザインタフェースが、ユーザがその車輌と装置との間のメッセージの無線通信を管理するのを助けるために生成される。別の例として、ある実施例においては、ある装置は、バスと、その装置上で走る多数のアプリケーションとの間の通信を管理する。

特定の実施例は、これらの技術的特徴、そして／または追加的な技術的特徴を有さないか、その１つまたはいくつかまたは全てを有している。別の技術的特徴は、以下の図面、説明そしてクレームから、当業者にとって容易に明らかになるであろう。

図１は、本発明の１つの実施例に従った無線車輛通信管理のためのシステム１０を示す。示されるように、システム１０は、車輛２０、プロトコル変換器３０、そして診断システム４０を有する。車輛２０は、各々が車輛２０の構成要素を制御し、そして／またはモニタする、ブレーキコントローラ２２ａ、トランスミッションコントローラ２２ｂ、そしてエンジンコントローラ２２ｃといった様々なコントローラ２２を有する。コントローラ２２は、車輛バス２４によって互いに接続されている。バス２４は、それ自体がバスである様々な部分を有し、各コントローラ２２は、その部分の１または複数を通じて通信する。プロトコル変換器３０もまたバス２４に接続されており、一般に、車輛２０のコントローラ２２そして／またはバス２４と診断システム４０との間の通信を容易にする。コントローラ２２と通信し、そして／またはバス２４上のメッセージをモニタすることを希望する１つのタイプのリモートシステムである診断システム４０は、無線リンク３２によってプロトコル変換器に接続されている。

オペレーションにおいては、コントローラ（ｃｏｎｔｒｏｌｌｅｒ）２２は、バス２４を通じて、電気信号によって示される様々なメッセージを交換する。これらのメッセージは、コントローラそして／またはその車輛に関するデータを含む。プロトコル変換器３０は、バス２４に接続されているおかげで、バス２４上の電気信号を受信することができ、また、メッセージを示す電気信号をバス２４上に送り出すことができる。さらに、無線リンク３２のおかげで、プロトコル変換器３０は、バス２４上のメッセージを無線リンク３２を通じた送信に適したフォーマットに変換することができ、無線リンク３２を通じて受信したメッセージをバス２４上における通信に適したフォーマットに変換することができる。従って、プロトコル変換器３０は、診断システム４０がバス２４上のメッセージを「リスン」（ｌｉｓｔｅｎ）し、メッセージをコントローラ２２に送信し、そして／またはコントローラ２２からメッセージを受信することを可能とする。診断システム４０は、バスから受信したメッセージを表示し、バスから受信したメッセージを解析して、コントローラ２２の１つそして／または車輛２０に関する問題を診断し、コントローラ２２の１つに対するユーザ入力メッセージを受信しそして送信し、そして／またはコントローラ２２の１つに対するメッセージを生成し、送信する。セキュリティのために、プロトコル変換器３０は、そのメッセージを、診断システム４０に送信する前に、任意の様々なよく知られた暗号化アルゴリズムを用いて暗号化する。

特定の実施例においては、プロトコル変換器３０は、バス２４そして／または診断システム４０から受信したメッセージを解析して、そのメッセージを伝達すべきかを判断する。例えば、プロトコル変換器３０はバス２４から受信したメッセージを解析して、それが診断システム４０に対するものかを判断し、もしそうでなければ、そのメッセージの送信を拒否する。もし、例えばメッセージが診断システムに対して主張されたアドレス宛てであるなら、そのメッセージは診断システム４０に対するメッセージである。別の例として、プロトコル変換器３０は、バス２４から受信したメッセージを調べて、それが、診断システム４０によって確立されるある基準を満たすかを判断する。その基準は、コントローラ２２のどれがそのメッセージの送信元となるか、コントローラ２２のどれがそのメッセージを受信するか、メッセージの内容、メッセージの優先度、メッセージのバスプロトコル、そして／または他の任意の適合するタイプの基準を含む。プロトコル変換器３０は、もしそれが特定の基準を満たさないならそのメッセージの送信を拒否することができる。もし基準が全く明示されない場合には、プロトコル変換器３０はバス２４上にメッセージを送信するか、または送信しない。さらなる例として、プロトコル変換器３０は、無線リンク３２を通じて受信したメッセージを解析して、それがバス２４に向けられたものであるかを判断する。そのメッセージが、おそらくプロトコル変換器３０に対するコマンドであって、バス２４に向けられたものでなければ、プロトコル変換器３０はそのメッセージをバス２４に伝達することを拒否する。さらに、プロトコル変換器３０はそのメッセージを解析して、それをバス２４に通信する前に、それが有効であるかを判断し、そのメッセージの追加的フィルタリングを提供する。従って、少なくともこれらの実施例においては、プロトコル変換器３０はバス２４からのそして／またはバス２４へのメッセージのフィルタとして動作する。

ある実施例においては、車輌２０のコントローラ２２は、例えばＣＡＮ２．０Ｂ／Ｊ１９３９、Ｊ１７０８／Ｊ１５８７、Ｃｌａｓｓ ２Ｂ／Ｊ１８５０、またはバス２４を通じてメッセージを通信するのに適した様々な異なるプロトコルを用いる。これらの実施例においては、プロトコル変換器３０は、バス２４上の様々なプロトコルにおけるメッセージを無線リンク３２を通じて診断システム４０に通信するための適切なフォーマットに変換することができる。プロトコル変換器３０はさらに、無線リンク３２を通じて受信されたメッセージを解析し、バス２４上にメッセージを送り出すためにどの車輌バスプロトコルを用いるかを決定することができる。従って、プロトコル変換器３０は、様々な車輌バスプロトコルと診断システム４０との間のメッセージの交換を容易にすることができる。さらに、プロトコル変換器３０は、そのメッセージが向けられているバス２４の部分が活動中であるかを判断する。その部分が活動中でなければ、プロトコル変換器３０は、そのメッセージを伝達することを拒否し、バス２４へのメッセージに対するさらなるフィルタリングを提供する。特定の実施例においては、プロトコル変換器３０は様々な車輌プロトコルと様々なリモートシステムとの間、そして／または、様々な車輌バスプロトコルとリモートシステム上で走る様々なアプリケーションとの間でのメッセージの交換を容易にすることができる。

バス２４上で用いられるプロトコルまたは複数のプロトコルは、無線リンク３２が確立された時に、それが、バス２４からのメッセージの送信とバス２４へのメッセージを受信するために適した帯域を持つように、考慮される。典型的には、それは、無線リンク３２のキャパシティがバス２４上の合成データレートより大きいなら役立つ。例えば、Ｊ１９３９メッセージが毎秒２５０キロバイト（Ｋｂｐｓ）で通信され、Ｊ１７０８メッセージが９．６Ｋｂｐｓで通信される。従って、もしＪ１９３９とＪ１７０８メッセージがバス２４上で用いられているなら、少なくとも数百Ｋｂｐｓのキャパシティが無線リンク３２用として適切である。そのようなレートを処理可能な１つのタイプの無線リンクは、Ｂｌｕｅｔｏｏｔｈ^TMプロトコルに従って動作する無線リンクである。なぜなら、それは、非同期リンクを通じて７００Ｋｂｐｓで通信することを可能とするからである。しかし、Ｂｌｕｅｔｏｏｔｈ^TMにおける無線周波数（ＲＦ）とコントロールオーバヘッドメッセージは、この帯域の相当の部分を使用する。

システム１０の構成要素は、様々な構成を有する。例えば、車輌２０は、車、バス、トラック、またはコントローラを有する他の任意の運搬装置である。車輌２０のコントローラ２２は、マイクロプロセッサ、マイクロコントローラ、アプリケーション特定集積回路（ＡＳＩＣｓ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡｓ）、アトミックコンピュータ、バイオロジカルコンピュータ、または車輌２０の機能そして／または構成要素を制御し、そして／またはモニタするための他の任意のタイプの論理装置を有する。特定の実施例においては、コントローラ２２は、温度センサ、速度センサ、距離センサ、そして／または他の任意の適合するセンサ装置を有する。さらに、いくつかの実施例においては、センサは、バス２４に接続されている。車輌２０は、任意の数のコントローラ２２を有することに注意すべきである。車輌２０のバス２４は、コントローラエリアネットワーク（ＣＡＮ）バス、Ｊ１７０８バス、または複数のコントローラ２２間でメッセージを伝達し得る他の任意の有線または無線のリンクの集合を有する。任意の様々なプロトコルがＣＡＮ、Ｃｌａｓｓ ＩＩ、またはＪ１７０８といったバス２４を通じて信号を送信するのに用いられる。しかし、特定の実施例においては、バス２４は１つのプロトコルのみを処理する。プロトコル変換器３０は、無線リンク３２を通じた診断システム４０とバス２４との間での車輌バスメッセージの交換を容易にし得る任意の装置である。特定の実施例においては、プロトコル変換器は、無線リンク３２を通じて車輌バスメッセージを送信／受信するためのＢｌｕｅｔｏｏｔｈ^TMプロトコルを実行する。診断システム４０は、パーソナルコンピュータ（ＰＣ）、パーソナルデジタルアシスタント（ＰＤＡ）、ワークステーション、または無線リンク３２を通じて車輌バスメッセージを通信し得る他の任意のタイプの論理装置である。リモートシステムの１つのタイプである診断システム４０は、マイクロプロセッサ、マイクロコントローラ、ＡＳＩＣｓ、ＦＰＧＡｓ、アトミックコンピュータ、バイオロジカルコンピュータ、または論理的方法でデータ操作を行う他の任意のタイプの装置を有する。診断システム４０は、車輌２０の内部または外部に配置されている。ある実施例においては、診断システム４０は、無線リンク３２を通じてＢｌｕｅｔｏｏｔｈ^TMプロトコルを用いてプロトコル変換器３０と通信する診断コンピュータである。

プロトコル変換器３０は、システム１０に対して様々な技術的特徴を提供する。例えば、プロトコル変換器３０は、診断システム４０が、物理的にバス２４に接続されることなく車輌２０のバス２４からメッセージを受信し、そして／またはバス２４上にメッセージを送り出すことを可能とする。従って、診断システム４０は、メンテナンスが実行される必要がある時に車輌２０に接続される必要がなく、サービスタイムとコストを減少させる。加えて、この能力によって、診断システム４０は、車輌２０を移動させることなくコントローラ２２と通信することができ、サービスタイムとコストを減少させる。さらに、様々な診断システムは、各々がバス２４に接続されることなくバス２４上のメッセージをモニタし、そして／または送り出し、さらにサービスタイムとコストを減少させる。さらに、プロトコル変換器３０は、車輌２０を製造中または使用中に、コントローラを遠隔にプログラミングするのに役立ち、時間とコストを減少させる。別の例として、少なくともある実施例では、プロトコル変換器３０はバス２４上の様々な車輌バスプロトコルを扱うので、プロトコル変換器３０は様々な車輌タイプ、コントローラ、そして／または診断システムにとって有用である。従って、分離されたプロトコル変換器が、各々の車輌、コントローラ、そして／または診断システムの組み合わせに対して必要とはならない。さらなる例として、少なくともいくつかの実施例においては、プロトコル変換器３０は、診断システム４０が外部メッセージ上のリソースを使用する必要がなく、無線リンク３２の帯域が維持されるように、バス２４からのメッセージをフィルタリングすることができる。さらなる例として、プロトコル変換器３０は、車輌バス２４上の合成データレートを扱うことができる無線リンクを用いる。従って、バス２４上のメッセージは、タイムリーに診断システム４０に通信する。しかし、上記において詳しく説明したように、いくつかの実施例においては、バスメッセージは、それらが送信される前にある期間蓄積されるという事実によって、いくらかの潜伏を経験するということに注意すべきである。様々な他の技術的特徴が、当業者にとって容易に明らかになるであろう。

図２は、システム１０用のプロトコル変換器３０の１つの実施例を示している。この実施例においては、プロトコル変換器３０は、バスコネクタ５０、複数のプロトコルトランシーバ６０、コンピュータ７０、そして無線通信装置８０を有する。バス２４に対して、そしてバス２４から信号を伝達するバスコネクタ５０は、バス２４に接続することができ、プロトコルトランシーバ６０に接続されている。バスコネクタ２４を通じてバス２４から電気信号を受信し、バス２４に対して電気信号を送信し得るプロトコルトランシーバ６０は、各々コンピュータ７０の通信インタフェース７２に接続されている。コンピュータ７０は、また、バス２４からのメッセージを解析し、バス２４にメッセージを送信し得るプロセッサ７４と、プロセッサ７４用のバッファ７８と１セットのロジック７７中に車輌バスメッセージを蓄積し得るメモリ７６と、第２の通信インタフェース７９を有する。通信インタフェース７９は、無線通信装置８０の通信インタフェース８２に接続されている。無線通信装置８０は、また、共にバス２４に関するメッセージを送信しそして受信する、ベースバンドコントローラ８４、トランシーバ８６、そしてアンテナ８８を有する。

オペレーションにおいては、プロトコル変換器３０はバスコネクタ５０を通じてバス２４からのメッセージを示す電気信号を受信し、そのメッセージを無線通信装置８０を通じて診断システム４０に送信する。加えて、プロトコル変換器３０は、無線通信装置８０を通じて診断システム４０からメッセージを受信し、バスコネクタ５０を通じてバス２４へそのメッセージを示す電気信号を送信する。プロトコル変換器３０は、また、プロトコル変換器自身に向けられた、診断システム４０からのメッセージを受信し、診断システム４０に向けられたメッセージを送信する。

あるメッセージがバス２４を通じて送信されたときに、メッセージをバス２４から診断システム４０に送信するために、バスコネクタ５０はそのメッセージを示す電気信号を受信し、それらを、プロトコルトランシーバ６０の適当な１つに伝達し、各プロトコルトランシーバ６０はバス２４上で用いられる様々なプロトコルを扱う。バスコネクタ５０から電気信号を受信すると、プロトコルトランシーバは、その信号をコンピュータ７０に適したフォーマットに変換する。プロトコルトランシーバは、検知動作、フィルタリング、エラー訂正動作、アナログからデジタルへの変換、プロトコル変換、そして／または、その信号を適当なフォーマットに変換するための任意の様々な他の動作を行う。プロトコルトランシーバは、様々なレートでメッセージを受信し、送信することに注意すべきである。例えば、Ｊ１９３９メッセージは、２５０Ｋｂｐｓで送信／受信され、Ｊ１７０８メッセージは９．６Ｋｂｐｓで送信／受信される。通信インタフェース７２は、これらの動作のいくつかを担当することに注意すべきである。メッセージを検知すると、プロセッサ７４は、ロジック７４に従って、メッセージを検査し、それが診断システム４０に送信されるべきかを判断する。例えば、プロセッサ７４は、そのメッセージが診断システム４０に向けられておらず、おそらくコンピュータ７０または別のコントローラ２２に向けられており、またはそれが診断システム４０によって定義された基準を満たさないために診断システム４０に適合しないと判断する。そのメッセージが診断システム４０に向けられ、そして／または診断システムに適合するなら、プロセッサ７４はそのメッセージを診断システム４０用に、そして無線通信装置８０に対する通信用にフォーマットし、そのメッセージを通信インタフェース７９を通じて無線通信装置８０に送信する。制御情報もまた無線通信装置８０とコンピュータ７０との間で交換されることに注意すべきである。無線通信装置８０の通信インタフェース８２は、そのメッセージをベースバンドコントローラ８４に伝達する。ベースバンドコントローラ８４は、そのメッセージを、例えば、そのメッセージに基づいて変調シーケンスを決定し、そのメッセージ用の適合するパッケージングを提供することによって、無線リンク３２を通じた送信に適したフォーマットに変換する。トランシーバ８６は、変換されたメッセージに基づいて、アンテナ８８を用いて、変換されたメッセージを示す電磁的信号を送信する。トランシーバ８６は、変換されたメッセージに基づいてキャリアー信号を周波数変調することによって、変換されたメッセージに基づいてキャリアー信号を振幅変調することによって、または、無線リンクを通じてデータを送信するのに適した他の任意の技術を用いることによって、これを実現する。

一方、無線通信装置８０がアンテナ８８を通じて、あるメッセージを示す信号を受信すると、トランシーバ８６は、例えば、キャリアー周波数を取り出すなどの、その信号処理における最初のステップを実行し、その信号をベースバンドコントローラ８４に送信する。そのメッセージは無線通信フォーマットであり、診断システム４０によって送信されたものである。ベースバンドコントローラ８４は、例えば、変調シーケンスに基づいて、データを決定することによって、その信号を無線リンク３２用に用いられるフォーマットからコンピュータ７０用に適したフォーマットに変換する。ベースバンドコントローラ８４は、また、例えば、エラー訂正、セキュリティ検証、そして配信保証といった、メッセージに対する追加的な処理を行う。さらに、ベースバンドコントローラ８４は、例えば、チャネルホッピングといった、無線リンクの別の局面の処理を行う。無線通信装置８０がＢｌｕｅｔｏｏｔｈ^TMプロトコルを実行する実施例については、ベースバンドコントローラ８４は、典型的には、例えば、論理リンク制御およびアダプテーションプロトコル（Ｌ２ＣＡＰ）またはホストコントローラインタフェース（ＨＣＩ）といった、Ｂｌｕｅｔｏｏｔｈ^TMスタックのあるレイヤを実装する。ベースバンドコントローラ８４は、もちろん、送信動作用の同様のフォーメーションを実行する。そして、そのメッセージは、通信インタフェース８２および通信インタフェース７９を通じてコンピュータ７０に送信され、検索される。そのメッセージがコンピュータ７０に到着すると、プロセッサ７４はそのメッセージを解析する。例えば、プロセッサ７４はそのメッセージがプロセッサ７４用か、１つのコントローラ２２用か、そして／または、バス２４の活動部分用かを決定する。もしそうでなければ、プロセッサ７４は、おそらくそのメッセージを廃棄する。プロセッサ７４は、そのメッセージの宛先アドレス、そのメッセージのプロトコル、そのメッセージ中のフラグまたは他の任意のタイプのインディケータを調べることによって、そのメッセージがコントローラ２２の１つ宛であるかを判断する。プロセッサ７４は、また、セキュリティチェックを行ってそのメッセージを検証する。プロセッサ７４が、そのメッセージがコントローラ２２の１つまたはバス２４の活動部分に対するものであり、有効であれば、プロセッサ７４はそのメッセージをバス２４用にフォーマットし、プロトコルトランシーバ６０の適当な１つを選択し、そのメッセージを関係する通信インタフェース７２を通じて選択されたプロトコルトランシーバ６０に送信する。関係する通信インタフェースからメッセージを受信すると、選択されたプロトコルトランシーバは、そのメッセージに基づいて、車輌プロトコルに従って、バス２４を通じて通信するための電気信号を生成し、その信号をバス２４に伝達するバスコネクタ５０に送信する。

プロセッサ７４が、バス２４からのメッセージが診断システム４０に適合するかを判断すると、プロセッサ７４は、そのメッセージを調べ、その送信元アドレス、宛先アドレス、プロトコル、優先度、コンテンツ、そして／または、適した他の要素に基づいて、診断システム４０への送信するためにそのメッセージを無線通信装置８０に送信すべきかを決定することができる。診断システム４０は、プロセッサ７４に、どんなタイプのメッセージが送信されるべきかを指示する。例えば、診断システム４０は、コントローラ２２の特定の１つから送信され、コントローラ２２の特定の１つ宛に送信され、特定の優先度を有し、特定のプロトコルを用い、そして／またはエンジンコンディション、ブレーキコンディション、トランスミッションコンディションを含む特定のタイプのコンテンツを含むメッセージまたは他の適合するタイプの車輌情報に反応する。そのようなフィルタリングを用いることは、例えば、プロトコル変換器３０がバス２４上の多数のメッセージを受信しているが診断システム４０があるタイプのメッセージしか受信を望んでない場合には有用である。

いくつかの実施例においては、コンピュータ８０は、バス２４用の多数のフィルタリングを実行することができる。これは、診断システム４０が、アプリケーションの様々な部分または様々なアプリケーションであって、例えば、バス２４からの様々なタイプのメッセージを必要とする多数のタスクを実行する場合は、有用である。コンピュータ７０は、例えば、診断システム４０から各々の識別子を受信し、診断システム４０がそのデータがどのタスクに属するかを知るように、そのフィルタリングされたメッセージとともにその識別子を送信することによって、そのフィルタを管理する。しかし、特定の実施例においては、コンピュータ８０は単にそのデータを送信し、診断システム４０がそれがどのタスクに属するかを判断できるようにするだけである。

ある実施例においては、プロトコル変換器３０はデータを診断システム４０に送信する前にデータを長期間蓄積する。例えば、コンピュータ７０のメモリ７６は、診断システム４０がプロトコル変換器３０と通信していない間、プロトコル変換器３０がバス２４から受信した様々なメッセージを蓄積する。そして、診断システム４０への通信リンク３２が確立されると、プロトコル変換器３０はその蓄積されたメッセージを無線通信装置８０を通じて診断システム４０に送信する。別の例として、メモリ７６は、例えば、車輌識別番号（ＶＩＮ）そして／またはサービス履歴といった車輌２０に関する情報を蓄積する。この情報は、また、無線通信装置８０を通じて診断システム４０に送信される。さらなる例として、コンピュータ７０は無線リンク３２の帯域に比べて小さいメッセージを蓄積し、そのようなメッセージをまとめて送信する。これは、特にそれが同期リンクである場合に、無線リンク３２をより活用できるようにする。一般に、他の様々なタイプの情報が後に診断システム４０に送信されるためにプロトコル変換器３０によって蓄積される。その情報の送信は、プロトコル変換器３０そして／または診断システム４０によって開始されることに注意すべきである。また、コンピュータ７０はそれ自身の状態に関する情報を診断システム４０に送信することに注意すべきである。

さらに、プロトコル変換器３０は、例えば、診断システム４０のようなリモートシステムとの通信開始に関する情報を蓄積する。例えば、プロトコル変換器３０は、是認されるリモートシステムのアドレスのリスト、そして／または、是認されるリモートシステムが送信すべきパスコードのリストを蓄積する。別の例として、プロトコル変換器３０はリモートシステムからの開始信号を探索するためにスキャンされるチャネルのリストを蓄積する。当業者によく知られた他の様々な通信開始情報もまた蓄積される。

いくつかの例においては、コンピュータ７０はバス２４上のノードの機能をエミュレートし得る。例えば、コンピュータ７０は、診断システム４０に代わってバス２４上のアドレスを交渉し、請求する動的アドレス設定を実行し得る。特定の実施例においては、コンピュータ７０は、バス２４上の多数のアドレスを請求し得る。これらの実施例のいくつかにおいては、コンピュータ７０は、各アドレスへの様々なフィルタリング要求を実行し得る。コンピュータ７０は、また、バス上の別の装置からの健康状態問い合わせに応答し得る。さらに、コンピュータ７０は、そのバス２０上におけるそのアドレスを防御する。コンピュータ７０はまた、他の任意の様々なノード機能を実行する。

ある実施例においては、リモートシステムからの管理下にあるコンピュータ７０は、バス２４そして／またはコントローラ２２に対するレスポンスを生成し得る。例えば、コンピュータ７０は、バス２４上のアドレスを防御するためのメッセージを生成し得る。別の例として、コンピュータ７０は、Ｒｅｑｕｅｓｔ＿Ｔｏ＿Ｓｅｎｄ（ＲＴＳ）そして／またはＣｌｅａｒ＿Ｔｏ＿Ｓｅｎｄ（ＣＴＳ）メッセージに応答するメッセージを生成し得る。一般に、コンピュータ７０は、バス２４そして／またはコントローラ２２用の任意のタイプのレスポンスメッセージを生成する。

特定の実施例において、コンピュータ７０は、ネットワーク上のサーバとして動作する。例えば、コンピュータ７０は、インターネットプロトコル（ＩＰ）アドレスを有し、そして、無線周波数ローカルエリアネットワーク（ＲＦＬＡＮ）メッセージとしてのメッセージを送信／受信する。従って、プロトコル変換器３０がリモートシステムの範囲内にあったなら、それは、ネットワークアクセスポイントとして動作し得た。

プロトコル変換器３０の構成要素は、様々な形式と組み合わせを有する。例えば、バスコネクタ５０は、１６ピンを有するアセンブリライン診断ライン（ＡＬＤＬ）、通常の車用の構成、９ピンを有するＡＬＤＬ、通常のトラック用の構成、またはバス２４に対してメッセージを送信できるようにし、バス２４からメッセージを受信し得るようにする他の任意の構成である。トラック用の９つのピンは、以下のように割り当てられる。１）パワーそしてグランド用の２つのピン、２）Ｊ１９３９通信用の３つのピン、３）Ｊ１７０８通信用の２つのピン、そして４）専用通信用の２つのピンである。バスコネクタ５０は、典型的には車輌のバスに、直接差し込まれることによって、または仲介ケーブルによって接続される。いくつかの例においては、ケーブルを変更することにより、プロトコル変換器３０は、例えば、トラック、そして車という様々なタイプの車輌上で用いられる。

プロトコルトランシーバ６０は、バスコネクタ５０を通じてメッセージを受信し、それらをコンピュータ７０用にフォーマットし、また、コンピュータ７０からメッセージを受信し、それらをバス２４用にフォーマットする任意のタイプの装置である。特定の実施例においては、プロトコルトランシーバ６０ａは、シーメンス製の８２Ｃ２５１であり、プロトコルトランシーバ６０ｂは、ナショナルセミコンダクター製のＤＳ３６Ｃ２７９であり、プロトコルトランシーバ６０ｚは、モトローラ製のＨＣ９１２Ｄ６０である。ある実施例においては、プロトコルトランシーバ６０はプラグアンドプレイハードウェアトランシーバであり、プロトコルトランシーバ６０がより広範囲の様々なバスそして／またはプロトコルとともに用いられることができるようにする。プロトコル変換器３０は任意の数のプロトコルトランシーバを有する。

コンピュータ７０の構成要素は、また、様々な形式と組み合わせを有する。プロセッサ７０はマイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ、バイオロジカルコンピュータ、アトミックコンピュータ、そして／または論理的手法で情報を操作するための他の任意のタイプの装置である。通信インタフェースは、ネットワークインタフェースカード、媒体アクセスユニット、トランシーバ、ポート、モデムまたはデータをコンピュータに伝達し、コンピュータからデータを伝達する他の任意のタイプの装置である。メモリ７６は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、コンパクトディスクリードオンリーメモリ（ＣＤ−ＲＯＭ）、電気的に消去可能なプログラマブルリードオンリーメモリ（ＥＥＰＲＯＭ）、そして／または他の任意のタイプの揮発性または不揮発性の電磁的または光学的データ蓄積装置である。ある実施例においては、メモリ７６の全てまたは一部は、プロセッサ７４上で符号化される。特定の実施例においては、コンピュータ７０はモトローラ製のＨＣ１２Ｄ６０である。

無線通信装置８０は、コンピュータ７０からメッセージを受信し、そのメッセージに基づいて、赤外線を含む電磁的信号を無線的に送信し得る。特定の実施例においては、無線通信装置８０はおそらく、現実の車輌バスローディングシナリオ用に、ある持続時間全ての車輌バス上で最大データ伝送レートを扱うための、十分な通信帯域と内部メモリストレージを有する。ある実施例においては、無線通信装置８０はエリクソン製のＲＯＫ１０１ ００７／１である。いくつかの実施例においては、プロトコル変換器３０は多数の無線通信装置を有する。これらは、同様の、または異なる無線プロトコルに従って動作する。

プロトコル変換器３０の構成要素は、任意の様々なフォーマットそして／またはリンクを用いることによりお互いに情報を交換する。例えば、その構成要素は、シリアル通信インタフェース（ＳＣＩｓ）、シリアル周辺インタフェース（ＳＰＩｓ）、ユニバーサル非同期レシーバ−トランスミッタ（ＵＡＲＴｓ）、ダイレクトアドレスモードリンク、そして／または他の任意の適合するタイプのプロトコル／リンクを用いて情報を交換する。プロトコルトランシーバ６０のスループットが、その構成要素間の適合するリンクを選択する上で考慮されるべきである。例えば、Ｊ１９３９メッセージは現在、２５０Ｋｂｐｓで通信されることが決められている。従って、５００Ｋｂｐｓまたはそれ以上を処理可能なＵＡＲＴリンクを用いることはおそらく許容される。しかし、より速いバスプロトコルにとって、または、プロトコル変換器３０によって様々なバスプロトコルが同時に処理されるべきである場合は、より速いリンクが必要である。

特定の実施例においては、プロトコル変換器３０は、ユーザ用の他の様々なインタフェースを有する。例えば、それは、その変換器をデバッグできるようにする改良されたインタフェースそして／または、情報を交換するためのＤＢ９／ＲＳ２３２といったフィールドサービスインタフェースそして／または無線装置８０用のフラッシュ更新ソフトウェアを有する。別の例として、プロトコル変換器３０は、コネクション状態のユーザに、診断情報、設定状態、バス動作そして／または他の任意の適切な情報を通知する様々な発光ダイオード（ＬＥＤｓ）を有する。

図３は、例えばプロトコル変換器３０のようなプロトコル変換器と、例えば診断システム４０のようなリモートシステムとの間でデータを伝達するための無線メッセージ２００の１例を示す。示された実施例においては、無線メッセージ２００は、車輌バスメッセージを伝達している。無線メッセージ２００は、そのバスメッセージを含むヘッダ部２１０とペイロード部２２０を有する。

ヘッダ部２１０は、第１のアドレスフィールド２１２と第２のアドレスフィールド２１４を含む。第１のアドレスフィールド２１２は、無線メッセージが向けられる無線装置のアドレスであって、そのプロトコル変換器がそのメッセージを送信していたか、またはリモートシステムがそのメッセージを送信していたかによって異なるアドレスを含む。一方、第２のアドレスフィールド２１４は、そのメッセージを送信する無線装置のアドレスを含む。

ペイロード部２２０は、そのバスメッセージを形成するヘッダ部２３０、ヘッダ部２４０、そしてペイロード部２５０、ヘッダ部２４０、そしてペイロード部２５０を有する。ヘッダ部２３０はメッセージタイプフィールド２３２、メッセージ識別子フィールド２３４、そしてメッセージ長フィールド２３６を含む。メッセージタイプフィールド２３２は、そのメッセージのバスプロトコルを特定し、そのメッセージがプロトコル変換器に対して向けられるのかプロトコル変換器から送信されるものなのかを特定する識別子を有する。示されるように、そのメッセージは、バスプロトコルメッセージを有する。メッセージ識別子フィールド２３４は、そのメッセージが関係するリモートシステムアプリケーションを特定する。従って、そのメッセージがリモートシステムに向けられていたなら、そのバスメッセージがどのアプリケーションと関連するかを知ることができる。メッセージ長フィールド２３６は、後に続くヘッダ部２３０部のメッセージ長を示す。ヘッダ部２４０は、メッセージ優先度フィールド２４２、第１のアドレスフィールド２４４、第２のアドレスフィールド２４６、そしてメッセージタイプフィールド２４８を含む。メッセージ優先度フィールド２４２は、そのバスメッセージの優先度を有する。第１のアドレスフィールド２４４は、そのバスメッセージの宛先アドレスを有する。第２のアドレスフィールド２４４はそのバスメッセージの送信元アドレスを有する。メッセージタイプフィールド２４８は、そのバスメッセージ中のデータタイプを示す。ペイロード部２５０は、そのバスメッセージのデータを含むデータフィールド２５２を有する。

示されるように、無線メッセージ２００は、リモートシステムまたは車輌バス上の１または複数の変換器に対して向けられる。例えば、無線メッセージ２００がリモートシステムに向けられるなら、そのプロトコル変換器はそのバスメッセージを車輌バスから受信し、それがリモートシステムに向けられたものかそして／またはリモートシステムに適合するものかを判断し、それを無線リンクを通じた通信に適したメッセージにフォーマットし、無線メッセージ２００を形成する。無線メッセージ２００を受信すると、リモートシステムは、ヘッダ２１０の第１のアドレスフィールド２１２中の宛先アドレスを調べることにより、無線メッセージ２００がそれに向けたものであるかを判断し、また、ヘッダ２１０の第２のアドレスフィールド２１４中の送信元アドレスを調べることによって、どの無線装置が無線メッセージ２００を送信したかを判断する。無線メッセージ２００がリモートシステムに対するものであり、適当な無線装置からのものである場合は、リモートシステムは、メッセージタイプフィールド２３２を調べることによって、メッセージ２００がプロトコル変換器からかバスからのメッセージを含むかを判断し、もしバスからのメッセージを含むなら、メッセージ識別子フィールドを調べることによって、そのメッセージがどのタスクに関係するかを判断する。そして、リモートシステムは、ヘッダ部２４０そして／またはペイロード部２５０中の情報を調べることによって、その車輌に関する情報を判断する。

一方、無線メッセージ２００が車輌バス上のコントローラに向けられたものなら、リモートシステムはヘッダ部２４０およびペイロード部２５０中にバスメッセージを形成し、プロトコル変換器用のヘッダ２３０を付加し、そして、それを無線リンクを通じた通信に適したメッセージにフォーマットして、無線メッセージ２００を形成する。無線メッセージ２００を受信すると、プロトコル変換器は、第１のアドレスフィールド２１２中の宛先アドレスを調べることにより、無線メッセージがそれに向けたものであるかを判断し、また、第２のアドレスフィールド２１４中の送信元アドレスを調べることによって、どの無線装置が無線メッセージを送信したかを判断する。無線メッセージがプロトコル変換器に対するものであり、適当な無線装置からのものである場合は、プロトコル変換器は、メッセージタイプフィールド２３２を調べることによって、そのメッセージがプロトコル変換器またはバスに向けられたメッセージを含むかを判断する。もしバスに対して向けられたものなら、メッセージタイプフィールドは、また、適当なバスプロトコルを示す。プロトコル変換器は、ヘッダ部２１０およびヘッダ部２３０を取り除いて、ヘッダ部２４０とペイロード部２５０から構成されるバスメッセージを、示されたバスプロトコルを用いて車輌バス上に送り出す。

無線メッセージ２００は、本発明に従った無線メッセージのほんの１例を示すのみである。例えば、Ｊ１９３９、Ｊ１７０８，Ｊ１８５０といった様々な車輛バスプロトコルについては、バスメッセージそしてその結果としてのヘッダ部２４０とペイロード部２５０は、おそらく様々な構成を有する。また、もし無線メッセージ２００がプロトコル変換器用のメッセージを含むなら、ヘッダ部２４０とペイロード部２５０はおそらく極めて異なる構成を有し、ヘッダ部２４０が除外される場合もある。加えて、例えばＢｌｕｅｔｏｏｔｈ^TMまたはＲＦＬＡＮといった様々な無線通信プロトコルに対しては、ヘッダ部２１０は様々な構成を有する。例えば、ヘッダ部２１０は同期ワードフィールド、確認フィールド、エラー訂正フィールド、チャネル識別子フィールド、または、他の任意の適合するタイプの無線プロトコルフィールドを含む。さらに、無線メッセージ２００の全体は、様々な車輌バスプロトコルそして／または無線通信プロトコルに対して様々に構成される。

図４は、本発明に従った、例えばプロトコル変換器３０のようなプロトコル変換器の動作方法の一例を示すフローチャート３００である。判断ブロック３０４において、プロトコル変換器は、それが、例えばバス２４といった車輌バスとの通信を確立する要求を検知したかを判断する。そのような要求は、例えば、診断システム４０といった適当なリモートシステムから発せられる。車輌バスとの通信を確立する要求を検知すると、そのプロトコル変換器は、機能ブロック３０８において、要求しているリモートシステムとの通信リンクを確立する。通信リンクの確立は、そのプロトコル変換器の無線アドレスを応答し、メッセージを交換するためにどのチャネルを用いるべきかを決定し、クロックを同期させ、タイミングとメッセージタイプを設定し、そのリモートシステムがバス上のメッセージにアクセスすることが許されているかを決定し、内部メモリとキューをチェックすることを含み、そして／または任意の様々な他のリンク開始問題を含む。機能ブロック３１０において、プロトコル変換器は、バス上のアドレスを請求する。バス上のアドレスの請求は、自動的に、またはそのリモートシステムからの要求に応えることにより実行される。プロトコル変換器は、また、そのアドレスを防御する。判断ブロック３１２において、プロトコル変換器はバスからメッセージを送信する際のプロトコル変換器の設定に関するメッセージの受信を待つ。そのようなメッセージは、そのリモートシステムが、そのバスからどんなタイプのデータそして／またはメッセージを受信することを望んでいるか、そして／または、そのバスのどの部分が起動し、起動しないかを含む。そのようなメッセージを受信した後に、機能ブロック３１４において、プロトコル変換器は、自身を適当なデータそして／またはメッセージを送信するために設定する。判断ブロック３１６において、プロトコル変換器は、通信セッションの終了を示すメッセージを検知したかを判断する。そのプロトコル変換器が通信セッションの終了を示すメッセージを検知した場合は、その通信セッションは停止される。しかし、そのプロトコル変換器が通信セッションの終了を示すメッセージを検知しない場合は、そのプロトコル変換器は判断ブロック３１８を続ける。

判断ブロック３１８において、プロトコル変換器は、車輌バス向けのメッセージを検知したかを判断する。プロトコル変換器は、そのメッセージ中の識別子、そのメッセージの宛先アドレス、そのメッセージのプロトコル、または他の任意の適合するインディケータを調べることによって、そのメッセージがそのバスに向けられたものかを判断する。そのプロトコル変換器がそのメッセージがそのバスに向けられたと検知した場合は、判断ブロック３２０において、プロトコル変換器は、そのメッセージは有効かを判断する。この有効性の判断は、そのメッセージの優先度、メッセージタイプ、そして／または不適合なメッセージが車輌バスに置かれないようにするのに役立つ他の任意の適合する要素に基づく。そのメッセージが有効な場合、機能ブロック３２２において、プロトコル変換器は、その車輌バスプロトコルがそのバス上にメッセージを送り出すのに用いられることを決定する。機能ブロック３２４において、プロトコル変換器は、そのメッセージをそのバス上の通信のためにフォーマットする。これは、無線通信フォーマット用の、そしてプロトコル変換器用のヘッダを取り除き、そのメッセージのプロトコルを変更することを含み、または、様々な通信フォーマット／プロトコル間の通信の際に要求される他の任意の様々なフォーマット動作を含む。機能ブロック３３２において、そのプロトコル変換器は、そのメッセージを送信するための、例えば、プロトコルトランシーバ６０ａといった適当なプロトコルトランシーバを選択し、機能ブロック３３２において、そのメッセージをバスコネクタを通じて送信する。

判断ブロック３１８において、そのプロトコル変換器がバスに対するメッセージを検知しなければ、または、判断ブロック３２０において、プロトコル変換器が、メッセージが有効でないと判断した場合、または、機能ブロック３３２において、そのプロトコル変換器がバスコネクタを通じてメッセージを送信した場合は、判断ブロック３３６において、プロトコル変換器は、それがバスからのメッセージを検知したかを判断する。そのプロトコル変換器がバスからのメッセージを検知しない場合には、プロトコル変換器は、判断ブロック３１６に戻る。しかし、そのプロトコル変換器がバスからのメッセージを検知した場合は、機能ブロック３４０において、プロトコル変換器は、そのメッセージを解析して、それが予め決められた基準を満たすかを判断する。上述したように、その予め決められた基準は、送信元コントローラのアドレス、そのメッセージの宛先アドレス、そのメッセージに対して用いられるプロトコル、そのメッセージの優先度、そのメッセージのコンテンツ、そして／または他の任意の適当な要素を含む。特定の実施例においては、その基準は、そのメッセージが防御されたアドレスに向けられているか、そして／または、パケット化が可能であるかを含む。その基準は、リモートシステムからのコマンドによって実現され、プロトコル変換器によってローカルに蓄積される。判断ブロック３４４において、プロトコル変換器が、そのメッセージがその予め決められた基準を満たさないと判断すると、プロトコル変換器は、判断ブロック３１６に戻る。しかし、そのメッセージがその予め決められた基準を満たすなら、機能ブロック３４８において、そのプロトコル変換器は、そのメッセージを無線通信システムフォーマットにフォーマットし、機能ブロック３５２において、そのメッセージを送信する。そして、そのプロトコル変換器は、判断ブロック３１６に戻る。

フローチャート３００は、本発明に従ったプロトコル変換器の様々な動作を示すが、他の動作方法は、より少ないかより多いか、そして／または異なる動作の組み合わせを有する。例えば、いくつかの実施例においては、プロトコル変換器は、バスとの通信確立要求を検知する前に通信リンクを確立する。さらなる例として、特定の実施例においては、プロトコル変換器は、そのメッセージを無線リンクを通じて送信する前に、予め決められた基準を満たすかを判断するためにメッセージを解析することはしない。別の例として、ある実施例においては、プロトコル変換器は、関連する車輌に関する情報を蓄積し、一旦通信リンクが確立されると、この情報を送信し得る。さらなる例として、いくつかの実施例においては、プロトコル変換器は、バス上のデータ用の多数のフィルタを実装する。プロトコル変換器はその各フィルタに関する識別子を有していないが、いくつかの実施例においては、各フィルタは、そのプロトコル変換器がそのバス上で請求したアドレスに関連している。別の例として、いくつかの実施例においては、プロトコル変換器は、そのバスからのメッセージの、無線リンクを通じた通信を管理する。追加的な例として、ある実施例においては、プロトコル変換器は、そのバス上のアドレスを請求せず、または、メッセージが有効かを判断しない。さらなる例として、いくつかの実施例においては、プロトコル変換器は、特に、もしそのプロトコル変換器が、リモートシステムによってもたらされたデフォルト設定を有している場合は、受信した無線メッセージをバスに送信し、そして／または受信したバスメッセージを無線リンクを通じて送信する前に設定メッセージの受信を待たない。別の例として、いくつかの実施例においては、プロトコル変換器は、バスの一部を起動させるか不起動状態にし、追加的そして／または適合するフィルタを実現し、アドレスを請求し、そして／または、車輌バスデータを受信しそして／または送信中の他の任意の適合する機能を実行するコマンドを受信し、実行する。他の様々なオプションが存在する。

図５Ａは、本発明のある実施例に従った、プロトコル変換器によって無線リンクを通じて送信されるメッセージの管理方法を示すフローチャート５００である。その方法は、プロトコル変換器がリモートシステムへの無線リンクを確立し、そして、そのリモートシステムによってメッセージを送信するように設定されているか設定されていない開始ブロック５０４において開始する。判断ブロック５０６において、プロトコル変換器は、それがバスメッセージを受信したかを判断する。プロトコル変換器がバスメッセージを受信した場合は、機能ブロック５０８において、それは、バスタイマーを開始する。バスタイマーは車輌バス上の活動時間間隔に関連する。判断ブロック５１０において、プロトコル変換器は、そのメッセージが送信に適しているかを判断する。プロトコル変換器は、例えば、上述したフィルタリング基準に基づいてこの判断を行う。このメッセージが送信に適しているなら、機能ブロック５１２において、そのプロトコル変換器は、そのメッセージを、例えば、バッファ７８などのバッファ中に置く。判断ブロック５２０において、プロトコル変換器は、その受信されたメッセージは、そのバッファ中の唯一のメッセージであるかを判断する。そのメッセージがそのバッファ中の唯一のメッセージである場合は、機能ブロック５２４において、プロトコル変換器は、バッファタイマーを開始する。そのバッファタイマーは、そのバッファ中にメッセージの配置を開始し始めてからの間隔に関係する。そして、判断ブロック５０８において、プロトコル変換器は、追加のメッセージをチェックする。

判断ブロック５０８において、メッセージが存在せず、または、判断ブロック５１０において、受信されたメッセージが送信に適していない場合は、判断ブロック５２８において、プロトコル変換器は、バッファ中に何らかのメッセージが存在しないかを判断する。そのバッファ中にメッセージがない場合は、判断ブロック５０８において、プロトコル変換器は、再度、何らかのメッセージが受信されたかを判断する。しかし、バッファ中にメッセージが存在する場合は、判断ブロック５３２において、プロトコル変換器は、そのバッファは、十分満たされているかを判断する。判断ブロック５２０において、もしバッファ中にメッセージが存在するなら、そのプロトコル変換器は、また、判断ブロック５３２に行き着くことに注意すべきである。そのバッファは、例えば、その中のメッセージが無線リンク上のスロットの相当な部分を占める場合は、十分に満たされている。例えば、Ｊ１９３９メッセージは、通常、９６ビットを有し、Ｂｌｕｅｔｏｏｔｈ^TMリンク上のスロットは、通常、６２５ビットを含み、従って、いくつかのＪ１９３９メッセージは、１つのスロット中で送信される。しかし、いくつかの実施例においては、３個の連続するスロットが、より多くのメッセージのグループ化を可能にするように用いられる。もちろん、別の無線プロトコルとバスプロトコルを用いれば、スロット中に送信されるバスメッセージの数は、もし無線プロトコルがスロットを有している場合は、極めて異なったものとなり得る。そのバッファが十分満たされたものなら、機能ブロック５３６において、プロトコル変換器は、そのメッセージを送信する。そのメッセージの送信は、それらを送信装置用に適したフォーマットに配置することを含むことに注意すべきである。判断ブロック５０８において、プロトコル変換器は別の受信されたメッセージをチェックする。

判断ブロック５３２に戻って、そのバッファが十分満たされていない場合は、プロトコル変換器は、バッファタイムアウトが生じたかを判断する。前述したように、そのバッファタイマーは、最初のメッセージがそのバッファ中に配置されてからの時間の量に関係する。従って、リモートシステムの動作に影響することなくメッセージが送信前に保持される期間が存在する。特定の実施例においては、そのバッファタイムアウトは、そのバッファを満たすのにどれだけの時間かかったかに基づいており、そのバッファのサイズは、そのバッファを満たす時間を通じて計算される平均の最大サポートバス負荷を考慮して、その無線リンク上の１または複数のスロットをサポートするために選択される。例えば、ある実施例においては、５０％のバス利用率において、メッセージは、十分長いサンプル時間を通じて、平均１／ミリ秒で到着する。従って、１２個のバッファが存在するなら、そのバッファタイムアウトは、おそらく約１２ミリ秒であり、そして、おそらく、そのバッファを満たすために幾分低いバス利用率でよいようにするために少しだけ速く、１５ミリ秒近辺である。バッファタイムアウトが生じると、機能ブロック５３６において、プロトコル変換器は、そのバッファ中のメッセージを送信する。

しかし、バッファタイムアウトが生じなければ、判断ブロック５４４において、プロトコル変換器は、バスタイムアウトが生じたかを判断する。前述したように、バスタイマーは何らかの車輌バス活動があってからの時間の量に関係している。従って、ある期間何らバス活動がなければ、その蓄積されたメッセージは、送信される必要がある。バスタイムアウトは、最大利用率におけるメッセージ開始からメッセージ開始までの平均遊休時間に基づく。特定の実施例においては、これは、約１ミリ秒後のタイムアウトに等しく、それは、より低い利用率を可能とするために、１＋４分の１ミリ秒の近辺に調整される。バスタイムアウトが生じると、機能ブロック５３６において、プロトコル変換器は、そのメッセージを送信する。バスタイムアウトが生じなければ、プロトコル変換器は判断ブロック５０８に戻って、さらなるメッセージが受信されたかを判断する。

フローチャート５００により示される方法は、無線リンクのリソースを維持するのに役立つ。例えば、メッセージがスロットに対して小さければ、各メッセージを送信するのにオーバヘッドを消費する。別の例として、使用されない各スロットの部分があり、帯域を消費する。

フローチャート５００は、プロトコル変換器によって無線リンクを通じて送信されるメッセージを管理する方法の１つを示しているが、別の実施例は、プロトコル変換器が無線リンクを通じて送信されるメッセージを管理し得る、より少ない、より多いそして／または異なる動作の組み合わせを有する。例えば、いくつかの方法は、バスタイムアウトを用いない。別の例として、いくつかの方法は、メッセージが送信に適しているかを判断しない。追加的な例として、いくつかの方法は、メッセージの優先度に基づいて様々な送信を要求する。さらなる例として、いくつかの方法は、イベントに基づいてメッセージが受信されたかをチェックすることを要求する。さらなる実施例として、いくつかの方法は、タイムアウト用にタイマーを使用せず、例えば、タイムスタンプに頼る。様々な他の例が存在する。

図５Ｂは、本発明のある実施例に従った、プロトコル変換器によって無線リンクを通じて送信されるメッセージを管理する別の方法を示すフローチャート５５０である。その方法は、プロトコル変換器がリモートシステムへの無線リンクを確立し、そして、そのリモートシステムによって設定されているか設定されていない開始ブロック５５４において開始する。判断ブロック５５８において、プロトコル変換器は、パケット内において送信されるべきメッセージに関するメッセージを受信したかを判断する。典型的には、そのようなメッセージは、例えば、スロットまたは無線メッセージフォーマットといった無線リンクのいくつかのパラメータに対して大きく、従って、いくつかの場合、多数のスロットが用いられるにもかかわらず、プロトコル変換器による特別な処理を有する。そのようなメッセージの例は、Ｊ１９３９中のＲｅｑｕｅｓｔ＿Ｔｏ＿Ｓｅｎｄメッセージである。プロトコル変換器がそのようなメッセージを受信しなければ、その方法における更なる動作を進める前にそのようなメッセージの受信を待つ。一旦プロトコル変換器がそのようなメッセージを受信すると、判断ブロック５６２において、それは、十分なリソースが利用できるかを判断する。十分なリソースが利用できるかの判断は、プロトコル変換器によって処理されている現在の動作の判断、無線リンクのキャパシティに対して送信されるべきメッセージの大きさの判断、プロトコル変換器において利用できるメモリ、そして／または他の適当な要素を必要とする。十分なリソースが利用可能でない場合は、機能ブロック５６６において、プロトコル変換器は、否定的な確認メッセージを生成し、判断ブロック５５８において別のメッセージを待つ。

しかし、十分なリソースが利用可能な場合は、機能ブロック５７０において、プロトコル変換器は肯定的な確認メッセージを生成する。このメッセージは車輌バスを通じて送信される。判断ブロック５７４において、プロトコル変換器はパケット化が可能かを判断する。プロトコル変換器は、リモートシステムがパケット化されたメッセージを処理可能かを判断することによって、また、そのリモートシステムからパケットし得るコマンドを受信することによって、そして／または他の任意の技術によって、この判断をする。パケット化が可能でないなら、機能ブロック５７８において、プロトコル変換器は入力されるメッセージを管理する。入力されるメッセージの管理は、メッセージがパケット化されることなく車輌バスから受信された時にそのメッセージの部分を送信することを伴う。一旦そのメッセージが送信されると、プロトコル変換器は判断ブロック５５８に戻り、他のメッセージをチェックする。

判断ブロック５７４に戻って、パケット化が可能なら、機能ブロック５８２において、プロトコル変換器は送信されるメッセージに関する開始メッセージを生成する。そして、このメッセージは、リモートシステムに送信される。このメッセージは、メッセージが送信されること、メッセージのサイズ、どのようにしてそのメッセージが送信されるかを含む。機能ブロック５８６において、プロトコル変換器は、入力されるメッセージを管理する。そのメッセージの管理は、そのメッセージの部分をパケット化し、そのパケットを無線リンクを通じた送信用そして／またはリモートシステム用にフォーマットし、そのメッセージセグメントが順に送信されることを保証し、エラー訂正を行い、そして／または他の任意の適合する機能を伴う。パケットを集めて１つのメッセージにすることは、リモートシステムによることに注意すべきである。一旦メッセージが完成すると、機能ブロック５９０において、プロトコル変換器は、そのメッセージが送信されたことを示すリモートシステム用のメッセージを生成する。そして、プロトコル変換器は、このメッセージを送信する。

フローチャート５５０は、プロトコル変換器によって、無線リンクを通じて送信されるメッセージの管理方法の１つを示しているが、別の実施例は、プロトコル変換器が無線リンクを通じて送信されるメッセージを管理する動作の、より少ない、またはより多い、そして／または異なる組み合わせを有する。例えば、いくつかの実施例においては、無線リンクを通じた送信、そして／またはそのメッセージのパケット化は、そのメッセージがそのバスを通じて送信されてからそのメッセージがリモートシステムによって受信される間の許容できない遅延を生じさせる。従って、プロトコル変換器は、例えば、メッセージ受信確認のような、メッセージに対するレスポンスを生成し、そのレスポンスをそのバス上に置く。従って、送信元のコントローラは、エラーが生じたことを感じない。別の例として、ある実施例においては、プロトコル変換器は、あるメッセージがプロトコル変換器にバスを通じて送信されることを示す、メッセージに対する確認を送信しない。これは、そのメッセージがブロードキャストアナウンスメッセージ（ＢＡＭ）である場合に起こる。

図６は、システム１０用の診断システム４０の一例を示す。この実施例においては、診断システム４０は、無線通信装置９０、コンピュータ１００、ディスプレイ１２０そして入力装置１３０を有する。一般に、無線通信装置９０は、無線リンク３２を用いてプロトコル変換器３０にデータを送信し、プロトコル変換器３０からデータを受信する。加えて、無線通信装置９０は、プロトコル変換器３０に送信されるメッセージをコンピュータ１００から受信し、コンピュータ１００に対して、プロトコル変換器３０から無線リンクを通じて受信されたメッセージを提供する。コンピュータ１００は、無線リンクを通じてプロトコル変換器３０に対して送信されるメッセージを生成し、その無線リンクを通じてプロトコル変換器３０から受信されたメッセージを処理する。ディスプレイ１２０には、データが診断システム４０のユーザに表示されるように、コンピュータ１００によって生成されたユーザインタフェースを表示し得る。入力装置１３０は、診断システム４０のユーザがコンピュータ１００に対してコマンドそして／またはデータを入力することができるようにし得る。

さらに詳細には、コンピュータ１００は、メモリ１０２、プロセッサ１０４、そして、互いに接続された通信インタフェース１０６を有する。メモリ１０２は、無線リンクを通じて送信されるメッセージを蓄積し、その無線リンクを通じて送信されるメッセージそして／またはプロセッサ１０４用の１セットのロジック１０３を蓄積し得る。プロセッサ１０４は、メモリ１０２中のロジック１０３に従って、プロトコル変換器３０に対するメッセージを生成し、また、プロトコル変換器３０から受信されたメッセージを解析し得る。例えば、プロセッサ１０４は、バス２４上のメッセージをフィルタリングし、そして／またはバス２４上のアドレスを請求するための、プロトコル変換器３０用のコマンドを生成する。プロセッサ１０４は、生成されたメッセージを、プロトコル変換器３０に送信するために、通信インタフェース１０６Ｃを通じて無線通信装置９０に対して送信し、そして、プロトコル変換器３０からのメッセージを、通信インタフェース１０６Ｃを通じて無線通信装置９０から受信する。加えて、プロセッサ１０４は、ディスプレイ１２０によって示されるユーザインタフェース１２２を生成し得る。プロセッサ１０４は、通信インタフェース１０６ａを通じてディスプレイ１２０と通信する。さらに、プロセッサ１０４は、入力装置１３０を通じてユーザからコマンドを受信する。プロセッサ１０４は、通信インタフェース１０６ｂを通じて入力装置１３０と通信する。

無線通信装置９０は、通信インタフェース９２、ベースバンドコントローラ９４、トランシーバ９６そして、アンテナ９８を有する。無線通信装置９０は、通信インタフェース９２を通じてコンピュータ１００と通信し、そして、無線リンク３２を通じて送信されるメッセージを受信し、無線リンク３２を通じて受信されたメッセージを通信インタフェース９２を通じて送信する。無線通信装置９０は、また、コンピュータ１００と制御メッセージを交換することに注意すべきである。ベースバンドコントローラ９４は、通信インタフェース９２と接続され、コンピュータ１００からのメッセージを無線リンク３２を通じた送信用にフォーマットし、また、無線リンク３２を通じて受信されたメッセージをコンピュータ１００用にフォーマットする。例えば、ベースバンドコントローラ９２は、送信されるメッセージを、無線リンク３２に適合するプロトコルに変換し、無線リンク３２を通じて受信されたメッセージをコンピュータ１００に適合するプロトコルフォーマットに変換する。加えて、ベースバンドコントローラ９２は、そのフォーマットされたメッセージの変調シーケンスを決定し、エラー訂正を実行し、チャネルホッピングシーケンスにおいて、どのチャネルが用いられるかを決定し、受信されたメッセージ上のセキュリティチェックを行い、そして／または他の任意の適合する動作を行う。特定の実施例においては、ベースバンドコントローラ９４は、例えば、Ｌ２ＣＡＰまたはＨＣＩといった、無線プロトコルスタックのあるレイヤを実装する。トランシーバ９６は、ベースバンドコントローラ９４に接続され、ベースバンドコントローラ９４によってフォーマットされたメッセージを、アンテナ９８を用いて無線リンク３２を通じて送信し、アンテナ９８を介して、無線リンク３２を通じてメッセージを受信し、それらをベースバンドコントローラ９４に提供する。例えば、トランシーバ９６は、ベースバンドコントローラ９４からのフォーマットされたメッセージに基づいて、キャリア周波数を変調することによって、メッセージを無線リンク３２を通じて送信し、キャリア周波数を取り出すことによって、無線リンクを通じて受信されたメッセージを提供する。

オペレーションにおいては、プロセッサ１０４が、ユーザそして／またはアプリケーションが車輌バス２４と通信を開始したいと判断した時には、プロセッサ１０４は、プロトコル変換器との通信に用いる無線装置を決定する。示された実施例では、プロセッサ１０４は、無線通信装置９０を１回選択できるのみであるが、他の実施例においては、プロセッサ１０４は、任意の回数選択できる。プロセッサ１０４は、これを、ローカル無線装置についてのメモリ１０２中に蓄積されたデータを調べることによって、また、ローカル無線装置に対する質問を開始することによって、また、他の任意の処理によって実現する。一旦プロセッサ１０４が、どのローカル無線装置が利用できるかを決定すると、プロセッサ１０４は、利用可能なローカル無線装置を示すユーザインタフェースを生成する。このユーザインタフェースは、ディスプレイ１２０に対して通信され、それがユーザに対してそのユーザインタフェースを表示するようにする。プロセッサ１０４は、ローカルな無線装置の選択の検知を待つ。プロセッサ１０４が、おそらく入力装置１０３からコマンドを受信することによってローカル無線装置の選択を検知すると、プロセッサ１０４は、その選択されたローカル無線装置に対して、例えば、プロトコル変換器３０のような、付近のプロトコル変換器に質問するよう指示する。示された実施例においては、無線通信装置９０のベースバンドコントローラ９４はこのタスクを実現できた。ベースバンドコントローラ９４はその質問を生成し、トランシーバ９６がそれをアンテナ９８を通じて送信する。プロトコル変換器からのレスポンスは、アンテナ９８を通じてトランシーバ９６によって受信される。トランシーバ９６がそのレスポンスを無線フォーマットから変換するための初動動作を実行した後、トランシーバ９６はそのレスポンスを、そのメッセージを無線フォーマットから変換するための更なる処理を実行するベースバンドコントローラ９４に対して通信する。そのレスポンスは、プロセッサ１０４が、利用できるプロトコル変換器を示すユーザインタフェースを生成するように、無線通信装置９０からコンピュータ１００に伝達される。ユーザインタフェースは、ディスプレイ１２０上に示される。そして、プロセッサ１０４はプロトコル変換器の選択の検知を待つ。その選択は、例えば、ユーザの入力装置１３０からのコマンドの検知によってなされる。一旦プロセッサ１０４が、どのプロトコル変換器に対してそれが通信するつもりかを理解すると、無線通信装置９０に、選択されたプロトコル変換器との通信リンクを確立するよう指示する。

そして、プロセッサ１０４は、プロトコル変換器を設定するコマンドの受信を待つ。例えば、プロセッサ１０４は、バス２４の一部を起動させるための、バス２４上のアドレスを請求するための、バス２４用のフィルタを実現するための、そして／または他の任意の適当な設定動作を実行するためのコマンドを待つ。そして、プロセッサ１０４は、プロトコル変換器用のコマンドを生成し、そのコマンドを、プロトコル変換器に対して送信するために、無線装置９０に対して送信する。そして、プロセッサ１０４は、その車輌バスに関するメッセージの受信を待つ。プロセッサ１０４は、また、プロトコル変換器に対する要求を生成し、そして／または受信する。例えば、プロセッサ１０４はプロトコル変換器３０がそれ自身に関する情報を診断システム４０に送信することを希望する。プロセッサ１０４は、プロトコル変換器３０に対して、そのような要求を実現するよう指示する。

プロセッサ１０４が車輌バスに関するメッセージを検知すると、そのプロセッサは、そのメッセージがプロトコル変換器が実行できるコマンドか、車輌バスに対する現行のメッセージかを判断する。そのメッセージは、診断システム４０のユーザからのものか、または、ユーザからのコマンドに対応してメッセージを生成するロジック１０３に従ってプロセッサ１０４によって生成されたものである。そのメッセージが、例えば、バスメッセージフィルタを実現するためにプロトコル変換器が実行できるコマンドなら、プロセッサ１０４は、プロトコル変換器用のコマンドを生成し、そのコマンドをプロトコル変換器に送信するために無線装置９０に送信する。しかし、そのメッセージがプロトコル変換器が実行できるコマンドでなければ、プロセッサ１０４は、そのメッセージを車輌バス用に適したフォーマットに変換し、メッセージを車輌バスに送出するプロトコル変換器へ伝達するために、そのメッセージを無線通信装置９０に送信する。

診断システム４０は、また、車輌バスからデータを受信する。このデータは、無線通信装置９０を通じて受信され、車輌バスデータを含むユーザインタフェースを生成するコンピュータ１００に送信される。ディスプレイ１２０は、ユーザインタフェースを表示する。また、プロセッサ１０４は、例えば、確認やコマンドなどの、車輌バスからのメッセージに対するレスポンスを生成し、そして／または、そのメッセージを解析して車輌２０に関する情報を決定する。診断システム４０は、車輌バスからのメッセージの受信を続行し、車輌バスに対して伝達されるメッセージを生成する。

診断システム４０の構成要素は、様々な形式そして／または組み合わせを有する。例えば、プロセッサ１０４は、マイクロプロセッサ、マイクロコントローラ、ＡＳＩＣ、ＦＰＧＡ、バイオロジカルコンピュータ、アトミックコンピュータ、そして／または論理的手法で情報を操作するための他の任意のタイプの装置である。別の実施例として、メモリ１０２は、ＲＡＭ、ＲＯＭ、ＣＤ−ＲＯＭ、ＥＥＰＲＯＭ、そして／または他の任意のタイプの揮発性または不揮発性の電磁的または光学的データ蓄積装置である。いくつかの実施例においては、メモリ１０３のいくつかまたは全ては、プロセッサ１０４上でエンコードされる。さらなる実施例においては、通信インタフェース１０６は、トランシーバ、ネットワークインタフェースカード、モデム、ポート、そして／またはデータが伝達される他の任意のタイプの装置である。特定の実施例においては、コンピュータ１００は、ＩＢＭ製のＴｈｉｎｋｐａｄ ６００Ｅである。更なる実施例として、ディスプレイ１２０は、カソードレイチューブディスプレイ、液晶ディスプレイ、ガスプラズマディスプレイ、または、ユーザに対する映像情報を生成するための任意の他のタイプの装置である。別の例として、ユーザインタフェース１２２は、グラフィカルユーザインタフェース、テキストベースユーザインタフェース、そして／または映像情報をユーザに伝達するための他の任意の構成である。さらなる例として、入力装置１３０は、キーボード、マウス、マイクロフォン、そして／または、ユーザから入力を受信し、それをプロセッサ１０４が理解できるデータに変換する他の任意のタイプの装置である。さらなる実施例においては、無線通信装置９０は、コンピュータ１００からメッセージを受信し、そのメッセージに基づく電磁信号を送信し得る任意のタイプの装置である。特定の実施例においては、無線通信装置９０は、ＤｉｇｉＡｎｓｗｅｒ製のＢｌｕｅｔｏｏｔｈ^TM無線機である。

診断システム４０の構成要素は、任意の様々なフォーマットそして／またはリンクを用いることによって、互いに情報を交換する。例えば、その構成要素は、シリアル通信インタフェース、シリアル周辺インタフェース、ユニバーサル非同期レシーバトランスミッタ、ダイレクトアドレスモードリンク、そして／または他の任意の適合するタイプのプロトコルまたはリンクを用いて情報を交換する。

特定の実施例においては、診断システム４０は、複数のローカル無線装置を有する。従って、コンピュータ１００が車輌バスとの通信を確立するためのコマンドを検知すると、コンピュータ１００は、どの通信装置が用いられるかを決定する必要がある。通信装置は、工業標準アーキテクチャ（ＩＳＡ）バス、周辺コンポーネント接続（ＰＣＩ）バス、ＵＡＲＴ、そして／または、他の任意のタイプのパラレルまたはシリアルのリンクを通じてコンピュータ１００に接続される。しかし、ある実施例においては、コンピュータ１００は、１つのローカル無線装置を有するのみであって、従って、このタスクを実行する必要がない。

ある実施例においては、診断システム４０は、少なくともあるモードでは自律的に動作する。従って、診断システム４０は、連続的に、定期的に、そして／または任意の他の適当な方法でコントローラ２２そして／または車輌２０の状態をモニタする。メッセージそして／または状態は、診断システム４０によって、後に検索されるように、ローカルに蓄積され、そして／または外部装置に通信される。

図７は、本発明の１つの実施例に従ったメモリ１０２中のロジック１０３の構成６００を示す。示されるように、構成６００は、複数のアプリケーション６１０、アプリケーションプログラムインタフェース（ＡＰＩ）６２０、そして無線マネジャ６３０を含む。一般に、アプリケーション６１０は、例えば、コントローラ２２などの、車輌バス上の１または複数のコントローラと情報交換し、そして／または車輌バス上のメッセージをモニタし得る。ＡＰＩ６２０は、アプリケーション６１０からのメッセージを車輌バスに適したメッセージに変換し、車輌バスからのメッセージをアプリケーション６１０に適したフォーマットに変換し得る。無線マネジャ６３０は、ＡＰＩ６２０から変換されたメッセージを受信し、それらを無線的に車輌バスに対して通信させ得る。無線マネジャ６３０は、また、車輌バスに関係する無線メッセージを受信し、それらをＡＰＩ６２０に送出し得る。

特定の実施例においては、ＡＰＩ６２０は、アプリケーション６１０からのメッセージを翻訳して、それらが、プロトコル変換器が実行し得る機能を示すかを判断する。例えば、アプリケーション６１０の１つからのメッセージは、その車輌バス上の１つのアドレスが請求されるように指示する。前述のように、これは、プロトコル変換器３０が実現できる機能である。従って、ＡＰＩ６２０は、プロトコル変換器に対するコマンドを形成し、このコマンドを、その動作を実行するプロトコル変換器に対して通信させる。そのようなメッセージの別の例は、車輌バス上のデータに対して実行されるフィルタリングを指定するものである。様々な別の例が存在する。

加えて、特定の実施例においては、１以上のアプリケーション６１０がＡＰＩ６２０を通じて車輌バスにメッセージを送信しており、そして／または車輌バスからメッセージを受信している。従って、ＡＰＩは、各アプリケーションからのメッセージと、各アプリケーションに対するメッセージの調整を担当する。この実現のために、ＡＰＩ６２０は、現在走っている各アプリケーション６１０に対して１つの識別子を割り当て、その識別子を、そのアプリケーションに対するフィルタとともに、プロトコル変換器に通信する。従って、ＡＰＩ６２０が車輌バスデータとともに識別子を受信すると、それは、その車輌バスデータをどこに向けるべきかを知ることができる。特定の実施例においては、その識別子は、車輌バス上のアドレスである。加えて、そのフィルタは、任意のタイプの基準を用い、全てのメッセージを通すことさえする。

構成６００の要素は、様々な形式そして／または組み合わせを有する。例えば、アプリケーション６１０は、例えば、ブレーキコントローラ、トランスミッションコントローラ、またはエンジンコントローラなどの、車輌バス２４上の特定のコントローラ用の診断プログラムである。このタイプのアプリケーションの例は、アリソントランスミッション製のＴｒａｎｓＰｒｏや、ナビスター／インターナショナル製のＭａｓｔｅｒ Ｄｉａｇｎｏｓｔｉｃｓである。さらなる例として、１または複数のアプリケーション６１０は、車輌についての問題を診断する。別の例として、ＡＰＩ６２０は、１または複数のアプリケーション６１０と車輌バス上で用いられるプロトコルとの間の翻訳を行う任意のタイプのアプリケーションである。特定の実施例においては、ＡＰＩ６２０は、メインテナンスカウンシル（ＴＭＣ）によって広められたＲＰ１２１０ａを用いてコンパイルを行う。従って、構成６００は、ＲＰ１２１０Ａを用いる現存の車輌バスアプリケーションが、そのアプリケーションに対して少しの修正を加えるか、全く修正を加えることなく無線的に実行されることを可能とする。さらなる実施例として、無線マネジャ６３０は、ＡＰＩ６２０からの通信を管理し、スタンドアロン診断ツールとして動作し、または双方の組み合わせとして動作する。ＡＰＩ６２０そして無線マネジャ６３０の機能は、様々な手法でそれらの間に分配される。

図８から１０は、本発明の１つの実施例に従った無線マネジャ用のユーザインタフェースを示す。示されるように、そのユーザインタフェースは、複数のスクリーン８００を有する。そのユーザインタフェースは、無線マネジャをスタンドアロン診断システムとして用いる時、そして／または、その無線マネジャを１または複数のアプリケーションからの通信を管理するために用いる時に、有用である。そのユーザインタフェースは、前者に関して詳細に説明される。

スクリーン８００ａは、典型的には、無線マネジャの起動時に出現する最初のスクリーンである。示されるように、スクリーン８００ａは、選択タブ８１０、無線装置セクション８２０、そしてプロトコル変換器セクション８３０を有する。機能選択タブ８１０は、ユーザが無線マネジャの様々な機能を選択できるようにする。タブ８１２の選択は、スクリーン８００ａを表示し、通信セッション用のローカル無線装置とプロトコル変換器の選択を可能にする。タブ８１４の選択は、車輌バスに送信され、車輌バスから受信されるメッセージを表示する。タブ８１６の選択は、現在無線マネジャを使用しているアプリケーションを表示する。タブ８１８の選択は、選択されたプロトコル変換器の設定を可能にするスクリーンを表示し、以下により詳細に説明される。無線装置セクション８２０は、例えば、無線通信装置９０のような、無線マネジャに対してローカルに利用可能な無線装置を示す。示されるように、無線装置セクション８２０は、無線マネジャが利用可能な無線装置を列挙するプルダウンメニュー８２２を有する。無線装置セクション８２０は、また、その動作によって無線装置の選択と不選択を可能とするボタン８２４を有する。示されるように、「Ｗｉｄｃｏｍｍ Ｄｏｎｇｌｅ」という名前の無線装置は、無線マネジャによって使用されている現在の無線装置である。プロトコル変換器セクション８３０は、例えば、プロトコル変換器３０のような、通信されるプロトコル変換器の選択を可能とする。示されるように、プロトコル変換器セクション８３０は、無線マネジャが通信するプロトコル変換器を列挙するウインドウ８３２を有する。利用可能なプロトコル変換器は、典型的には、付近のプロトコル変換器を決定するために質問を送信する無線マネジャによって特定される。示されるように、ウインドウ８３２は、３つのプロトコル変換器がリモートシステムとの通信に利用でき、「Ｕｎｎａｍｅｄ ＰＵＣ」という名前のプロトコル変換器が、現在選択されたプロトコル変換器であることを示している。プロトコル変換器セクション８３０は、また、ボタン８３４、８３６、そして８３８を有する。ボタン８３６の動作によって、プロトコル変換器セクション８３０がリセットされる。ボタン８３６の動作によって、無線マネジャに対して、付近のプロトコル変換器の探索を行うよう指示がなされる。しかし、ある実施例においては、無線装置セクション８２０における無線装置の選択は、自動的に付近のプロトコル変換器の探索を実行する。ボタン８３８の動作は、無線マネジャに対して、選択されたプロトコル変換器と無線リンクを確立し、またはその無線リンクを切るよう指示する。従って、無線マネジャの動作中において、通信されるプロトコル変換器は変更される。

スクリーン８００ｂは、機能選択タブ８１０のタブ８１８が選択されると生成される。示されるように、スクリーン８００ｂは、また、プロトコルセクション８４０、プロトコル変換器パラメータセクション８５０、そしてプロトコル変換器設定セクション８６０を有する。プロトコルセクション８４０は、ユーザが車輌バスから通信されるメッセージのプロトコルを特定することを可能とするボタン８４２、８４４、８４６を有する。従って、ボタン８４２の動作は、車輌バスからＪ１７０８プロトコルを用いてメッセージを送信し、ボタン８４４の動作は、車輌バスからＪ１９３９プロトコルを用いてメッセージを送信し、ボタン８４６の動作は、車輌バスから専用のプロトコルを用いてメッセージを送信する。従って、ボタン８４２、８４４、そして８４６の動作は、その車輌バス上のデータに対する１つのタイプのフィルタを特定する。ボタン８４２、８４４、そして８４６の動作を検知すると、無線マネジャは、プロトコル変換器が適当なフィルタを実行するように、選択されたプロトコル変換器に対して、選択されたプロトコルを特定するメッセージを送信する。プロトコル変換器パラメータセクション８５０は、選択されたプロトコル変換器のパラメータが表示されるウインドウ８５２を有する。無線マネジャは、ボタン８５４の動作を検知すると、これらのパラメータを検索するためのメッセージを生成する。プロトコル変換器用のいくつかのパラメータが、ウインドウ８５２内に示されるが、別の実施例は、より少ない、より多い、そして／または異なるプロトコル変換器用のパラメータを有する。プロトコル変換器設定セクション８６０は、プロトコル変換器の詳細設定にアクセスするためのパスコードが入力されるウインドウ８６２を有する。パスコードを入力した後、ボタン８６４の動作により、無線マネジャに対してそのパスコードが適当かを判断するように指示する。その無線マネジャは、例えば、そのパスコードを含むメッセージを形成し、そのメッセージをプロトコル変換器に送信し、プロトコル変換器から許容確認を受信することによってこれを実現する。許容確認を受信すると、無線マネジャは、スクリーン８００ｃに関して以下に詳細に説明されるプロトコル変換器のさらなる設定を可能とする。

スクリーン８００ｂは、また、様々な他の機能を有する。例えば、ボタン８７２の動作は、プロトコル変換器の原名称の指定を可能とする。典型的には、プロトコル変換器のアドレスは、例えば、メディアアクセスコントロール（ＭＡＣ）アドレスのような一連の番号である。従って、プロトコル変換器の原名称の指定は、ユーザにとって、特定のプロトコル変換器の識別を容易とする。プロトコル変換器の原名称は、無線マネジャを用いてローカル的に、また、プロトコル変換器上に遠隔的に、そして／または、ローカル的かつ遠隔的に蓄積される。設定セクション８７４は、ユーザが、その無線リンクが切れた場合に自動的にプロトコル変換器に再接続をするかの指定をすることを可能とする。ボタン８７６の動作は、選択されたプロトコル変換器上のソフトウェアそして／またはロジックに関する情報の検索を可能とする。

上述したように、無線マネジャは、許容されるパスワードがスクリーン８００ｂのプロトコル変換器設定セクション８６０に入力された時に、スクリーン８００ｃを生成する。示されるように、スクリーン８００ｃは、バスタイミングセクション８８０、バスフィルタセクション８９０、無線リンクパワーセクション９００、そしてプログラミングセクション９１０を有する。

バスタイミングセクション８８０は、車輌バス上で用いられている現在のタイミングの表示、そして／または、その車輌バス上で用いられるべきタイミングの指定を可能とする。示されるように、バスタイミングセクション８８０は、バスタイミングパラメータを表示するフィールド８８２、ボタン８８４、８８６、そして８８８を有する。ボタン８８４の動作は、無線マネジャに対して車輌バス上で用いられている現在のタイミングを検索するよう指示する。ボタン８８４の動作を検知すると、無線マネジャは、プロトコル変換器に対するメッセージを生成して、そのメッセージを無線リンクを通じて送信させる。あるレスポンスが受信されると、無線マネジャは、フィールド８８２中にそのデータを表示する。ボタン８８８の動作は、無線マネジャに対して、フィールド８８２中のタイミングが車輌バス上で用いられることを示すメッセージを作るよう指示する。特定の実施例においては、プロトコル変換器は、その車輌バス上のタイミングに順応する。

バスフィルタセクション８９０は、車輌バス上のメッセージ用のフィルタの指示を可能とする。示されるように、バスフィルタセクション８９０は、フィールド８９２、８９４、８９６そしてボタン８９８を含む。フィールド８９２の最初の部分は、その車輌バス上のメッセージの優先度に関連する。従って、フィールド８９２の最初の部分は、車輌バスから送信されるべきメッセージの優先度を特定する。フィールド８９２の第２の部分は、その車輌バス上のメッセージ中のデータタイプに関連する。従って、フィールド８９２中の第２の部分の値は、車輌バスから送信されるべきメッセージのデータコンテンツを特定する。フィールド８９２の第３の部分は、車輌バス上にメッセージを発するコントローラのアドレスに関連する。従って、フィールド８９２の第３の部分の値は、メッセージの送信元となるコントローラを特定する。フィールド８９２の第４の部分は、その車輌バス上のメッセージの宛先アドレスに関連する。従って、フィールド８９２の第４の部分の値は、メッセージの宛先となるコントローラを特定する。フィールド８９２の１または複数の部分が特定されることに注意すべきである。フィールド８９４は、フィールド８９２に対してどのビットが重要であるかを特定することを可能とする。フィールと８９６は、フィルタに関するアプリケーションの特定を可能とする。ボタン８９８の動作は、無線マネジャに対して、フィールド８９２そして８９４において特定されたフィルタデータを実行するためのメッセージを生成し、選択されたプロトコル変換器に対してメッセージを送信するよう指示する。特定の実施例においては、例えば、３２個を上限としたいくつかのフィルタが、プロトコル変換器によって実行される。前述したように、これらのフィルタは、プロトコル変換器がバス上において請求したアドレスや、無線マネジャによって特定され、または他の適合する方法で特定された識別子に関係している。別の実施例においては、より少ない、より多いそして異なるフィルタリング基準が実行され得る。

無線リンクパワーセクション９００は、無線リンクのパワーに関連するパラメータの表示を可能とする。セクション９００は、パワーに関連するパラメータを有するフィールド９０２とボタン９０４を有する。示されるように、フィールド９０２は、プロトコル変換器からの送信パワーレベル、プロトコル変換器によって実現される最大パワーレベル、そしてプロトコル変換器によって用いられている現在のパワーレベルを表示している。ボタン９０４の動作は、ウインドウ９０２中のデータのリフレッシュを可能とする。従って、無線リンクパワーセクション９００は、プロトコル変換器が、選択された無線装置に対して有利に配置されているかを判断するのに有用である。

プログラミングセクション９１０は、その動作がプロトコル変換器上のソフトウェアを再プログラミング／更新するボタン９１２を有する。有線の物理的なコネクションもまた、この機能のために用いられることに注意すべきである。

スクリーン８００によって示されるユーザインタフェースは、特に、その無線マネジャがスタンドアロンの診断ツールとして動作している時に有用である。従って、その無線を通じて、ユーザは、プロトコル変換器を選択し、そのプロトコル変換器に対するフィルタを特定し、その車輌バスを通じて送信されるメッセージをオブザーブする。加えて、ユーザは、プロトコル変換器が無線マネジャによって用いられている無線装置に対して有利に配置されているかを判断し、そして、そのプロトコル変換器に関するパラメータを検索する。無線マネジャの全ての実施例がこれらの機能の全てを有する必要はないことに注意すべきである。

加えて、いくつかの実施例においては、スクリーン８００ａは、メッセージをオブザーブし、そして／または車輌バス上にメッセージを配置する、例えば、アプリケーション６１０の１つのようなアプリケーションとともに用いられる。例えば、アプリケーション６１０の１つが開始されると、無線マネジャ６３０は、アプリケーションのユーザが、コネクトするプロトコル変換器を選択するようにスクリーン８００ａを生成する。例えば、システム１０が様々な車輌を含むサービス設備において用いられているなら、ブレーキ診断アプリケーションのユーザは、特定の車輌のプロトコル変換器にコネクトしようとする。加えて、無線マネジャ６３０は、前述した様々な他の機能と同様に、そのアプリケーションとバス２４との間に送信されるデータを示すスクリーンを生成し、ユーザがそのバス２４用のデータに用いられるフィルタを特定できるようにする。

スクリーン８００は、無線マネジャ用のユーザインタフェースのほんの１例を示していることが理解されるべきである。加えて、別の実施例は、より多い、より少ないそして／または異なるデータおよび機能の組み合わせを有する。

図１１は、本発明の１つの実施例に従った診断システムの動作を示すフローチャート１１００を示す図である。その方法は、無線マネジャの開始、または、例えばバス上のコントローラ用の診断アプリケーションのような、車輌バスと情報を交換しようとするアプリケーションの開始に対応する開始ブロック１１０４において開始する。機能ブロック１１０８において、診断システムは、例えばプロトコル変換器３０といった、プロトコル変換器と無線リンクを確立するのに役立つローカル無線装置を示すユーザインタフェースを生成する。そのユーザインタフェースは、例えば、ディスプレイ１２０といったディスプレイ上に示される。判断ブロック１１１２において、診断システムは、ローカル無線装置の選択の検知を待つ。そのような選択の検知は、例えば、スクリーン８００ａの無線装置セクション８２０中のボタン８２４の動作の検知によって実現される。機能ブロック１１１６において、診断システムは、付近のプロトコル変換器を見つけるための質問を生成し、送信する。その質問は、選択されたローカル無線装置によって送信される。機能ブロック１１２０において、診断システムは、その質問に対するレスポンスを受信する。機能ブロック１１２４において、これらのレスポンスを用いて、診断システムは、利用できるプロトコル変換器を示すユーザインタフェースを生成する。そのユーザインタフェースは、また、ディスプレイ上に示される。判断ブロック１１２８において、診断システムは、示されたプロトコル変換器の１つの選択の検知を待つ。その診断システムは、例えばスクリーン８００ａのプロトコル変換器セクション８３０中のボタン８３８の動作を検知することによって、あるプロトコル変換器が選択されたことを判断する。プロトコル変換器の選択を検知すると、機能ブロック１１３２において、診断システムは、選択されたプロトコル変換器との通信リンクを確立する。診断システムがＢｌｕｅｔｏｏｔｈ^TMプロトコルを用いる実施例においては、その診断システムは、選択されたプロトコル変換器との非同期リンクを確立することによってこれを実現する。

判断ブロック１１３６において、診断システムは、車輌バスに関するメッセージの検知を待つ。そのメッセージは、その車輌バス上のコントローラ用のメッセージ、そのプロトコル変換器用のコマンド、または、任意の他の適当なタイプのメッセージであり、ユーザから受信されるか、内部的に生成される。その車輌バスに関するメッセージを検知すると、判断ブロック１１４０において、その診断システムは、そのメッセージが、選択されたプロトコル変換器が実行できるコマンドであるかを判断する。そのようなメッセージの１つの例は、その車輌バス上のメッセージに対するフィルタである。そのメッセージが、そのプロトコル変換器が実施できるコマンドである場合、機能ブロック１１４４において、その診断システムは、プロトコル変換器用のコマンドを生成する。そして、機能ブロック１１４８において、その診断システムは、そのコマンドを含む無線メッセージを形成し、機能ブロック１１５２において、その無線メッセージを送信する。しかし、そのメッセージが、例えばバス２４上のコントローラに対するメッセージであって、そのプロトコル変換器が実行できないコマンドである場合は、機能ブロック１１５６において、診断システムは、そのメッセージをその車輌バスに適したフォーマットに変換し、機能ブロック１１６０において、例えば、メッセージ２００のような、その変換されたメッセージを含む無線メッセージを形成する。そして、機能ブロック１１５２において、その診断システムは、その無線メッセージを送信する。

機能ブロック１１６８において、その診断システムは、車輌バスデータを受信したかを判断する。そして、もし受信した場合は、機能ブロック１１７２において、その車輌バスデータを含むユーザインタフェースを生成する。そのユーザインタフェースの生成後、または、車輌バスを含むメッセージが全く受信されてない場合には、判断ブロック１１８０において、その診断システムは、そのプロトコル変換器との通信セッションを終了するためのコマンドを検知したかを判断する。その診断システムが、そのセッションを終了するためのコマンドを検知した場合は、機能ブロック１１８４において、その診断システムは、そのプロトコル変換器とのリンクを終了する。しかし、その診断システムが、そのセッションを終了するためのコマンドを検知しない場合は、判断ブロック１１８８において、その診断システムは、その車輌バスに関するメッセージを検知したかを判断する。その診断システムがその車輌バスに関するメッセージを検知すると、その診断システムは、判断ブロック１１４０に戻る。しかし、その診断システムがその車輌バスに関するメッセージを検知しない場合は、機能ブロック１１９２において、その診断システムは、プロトコル変換器を変更する要求を検知したかを判断する。その診断システムがプロトコル変換器を変更する要求を検知しない場合は、その診断システムは、判断ブロック１１６８に戻る。しかし、その診断システムがプロトコル変換器を変更する要求を検知した場合は、機能ブロック１１９６において、その診断システムはそのプロトコル変換器とのリンクを終了し、機能ブロック１１１６において、プロトコル変換器のイニシエーション処理を再び開始する。

フローチャート１１００は、本発明の１つの実施例に従った診断システムの様々な動作を示すが、本発明に従った診断システムの別の実施例は、より少ない、より多いそして／または異なる動作の組み合わせを有する。例えば、特定の実施例においては、診断システムは、１つのローカル無線装置だけが利用可能な場合は、利用可能なローカル無線装置を示すユーザインタフェースを生成せず、また、ローカル無線装置の選択の検知を待たない。別の実施例として、いくつかの実施例においては、診断システムは、車輌バスデータを含むユーザインタフェースを生成しない。さらなる例として、ある実施例においては、診断システムは、質問に対するレスポンスを受信すると、そのプロトコル変換器との通信リンクを確立する。追加的な例として、いくつかの実施例においては、診断システムは、特に、そのプロトコル変換器が、前の通信セッション中に、リモートシステムによって予め設定されていた場合は、その車輌バスに関するメッセージを検知する前に車輌バスデータの受信を開始し、そして／または送信する。さらなる例として、特定の実施例においては、診断システムは、車輌バスにデータを送信しそして／または車輌バスからデータを受信する前にそのプロトコル変換器を設定する。様々な他の例が存在する。

本発明は、主に車輌診断システムに関して説明されてきたが、その発明は、その車輌バスにアクセスする必要のある別のシステムに適合し得る。例えば、１または複数のコントローラ、または車輌バスに接続する別の要素は、リモートシステムが検索する車輌バスに関する情報を蓄積し、そして／または検知する。本発明は、その情報を検索するのに役立つ。別の例として、例えばエンジンコントローラ用のスパークアルゴリズムのような改良されたアプリケーションを有するリモートシステムは、その車輌バスから情報を受信しようとする。従って、一般に、本発明は、車輌バスが伝達するデータ、そのバスに関する現行のデータ、または車輌バスに関する他の任意のデータをリモートシステムに送信するのに役立つ。そのリモートシステムは、その車輌の内部にあっても外部にあってもよい。

様々な実施例が本発明に関して記述されたが、様々な追加、削除、修正そして／または変形が、当業者に直ちに示される。従って、以下のクレームはこのような追加、削除、修正そして／または変形を包含する。

添付図面は、特に以下の詳細な説明を考慮したときに、本発明のより完全な理解をもたらし、そして、その技術的特徴を示す。
本発明の１つの実施例に従った無線車輌通信管理システムを示す。 本発明に従ったプロトコル変換器の一例を示す。 プロトコル変換器とリモートシステムとの間にデータを伝達する無線メッセージの一例を示す。 本発明に従ったプロトコル変換器の動作方法の一例を示すフローチャートである。 本発明のある実施例に従った、プロトコル変換器によって無線リンクを通じて送信されるメッセージの管理方法を示すフローチャートである。 本発明のある実施例に従った、プロトコル変換器によって無線リンクを通じて送信されるメッセージの管理方法を示すフローチャートである。 本発明に従った診断システムの１例を示す。 本発明の１つの実施例に従った図６の診断システムのロジックの構成を示す図である。 本発明の１つの実施例に従った診断システム用のユーザインタフェースを示す。 本発明の１つの実施例に従った診断システム用のユーザインタフェースを示す。 本発明の１つの実施例に従った診断システム用のユーザインタフェースを示す。 本発明の１つの実施例に従った診断システムの動作方法を示すフローチャートである。

Claims (46)

1. 車輌プロトコル変換システムであって、
   車輌バスに接続され得るバスコネクタと、
   バスコネクタに接続されるプロトコルトランシーバであって、バスコネクタを通じた通信向けのメッセージを受信し、車輌バスプロトコルに従ってそのメッセージをそのバスコネクタを通じて送信することができ、その車輌バスプロトコルに従ってそのバスコネクタを通じてメッセージを受信し得るプロトコルトランシーバと、
   そのプロトコルトランシーバに接続されるコンピュータであって、そのバスコネクタを通じて受信されたメッセージを解析してそれらが送信されるべきかを決定することができ、そのバスコネクタを通じた通信向けのメッセージを受信し得るコンピュータと、
   そのコンピュータに接続される無線通信装置であって、無線リンクを用いて、送信されるべきメッセージを送信することができ、そのバスコネクタを通じた通信向けのメッセージを受信し得る無線通信装置とを備える
   ことを特徴とする車輌プロトコル変換システム。
2. 請求項１に記載のシステムにおいて、
   そのコンピュータは、さらに、
   そのメッセージをその無線通信装置への送信用にフォーマットし、
   そのバスコネクタを通じた通信向けのメッセージをそのプロトコルトランシーバ用にフォーマットし得る
   ことを特徴とする車輌プロトコル変換システム。
3. 請求項１に記載のシステムにおいて、
   そのコンピュータは、
   そのバスコネクタを通じて受信されたメッセージが、それらが送信されるべきかを判断するための予め決められた基準を満たすかを判断する
   ことを特徴とする車輌プロトコル変換システム。
4. 請求項３に記載のシステムにおいて、
   そのコンピュータは、
   そのメッセージが予め決められた基準を満たすかを判断するために、そのメッセージの宛先アドレスを調べる
   ことを特徴とする車輌プロトコル変換システム。
5. 請求項３に記載のシステムにおいて、
   そのコンピュータは、
   複数の予め決められた基準のセットを備える
   ことを特徴とする車輌プロトコル変換システム。
6. 請求項１に記載のシステムにおいて、
   そのコンピュータは、さらに、
   そのバスコネクタを通じた通信向けのメッセージを解析して、それらがそのバスコネクタを通じて送信されるべきかを判断する
   ことを特徴とする車輌プロトコル変換システム。
7. 請求項１に記載のシステムにおいて、
   その無線通信装置は、さらに、
   そのコンピュータに向けられたメッセージを受信することができ、
   そのコンピュータは、さらに、
   そのメッセージがそれに向けられているかを判断し得る
   ことを特徴とする車輌プロトコル変換システム。
8. 請求項７記載のシステムにおいて、
   そのコンピュータに向けられたメッセージの少なくともいくつかは、そのバスコネクタを通じて受信されたメッセージが送信されるべきかを判断するための基準を示す
   ことを特徴とする車輌プロトコル変換システム。
9. 請求項１に記載のシステムにおいて、さらに、
   そのバスコネクタとそのコンピュータに接続された第２のプロトコルトランシーバを備え、
   その第２のプロトコルトランシーバは、
   そのバスコネクタを通じた通信向けのメッセージを受信し、第２の車輌バスプロトコルに従って、そのメッセージをそのバスコネクタを通じて送信し、
   その第２の車輌バスプロトコルに従って、そのバスコネクタを通じてメッセージを受信し得る
   ことを特徴とする車輌プロトコル変換システム。
10. 請求項９に記載のシステムにおいて、
    そのコンピュータは、さらに、
    そのバスコネクタを通じた通信向けのメッセージについて、どのプロトコルトランシーバがそのメッセージを送信するかを選択し得る
    ことを特徴とする車輌プロトコル変換システム。
11. 請求項９に記載のシステムにおいて、
    第１のプロトコルトランシーバは、
    Ｊ１９３９に従ってそのバスコネクタを通じてメッセージを送信および受信し、
    第２のプロトコルトランシーバは、
    Ｊ１５８７に従ってそのバスコネクタを通じてメッセージを送信および受信する
    ことを特徴とする車輌プロトコル変換システム。
12. 請求項１に記載のシステムにおいて、
    そのコンピュータは、
    無線リンクが確立されるときの送信用として、そのバスコネクタを通じて受信されたメッセージを蓄積し得るメモリを備える
    ことを特徴とする車輌プロトコル変換システム。
13. 請求項１に記載のシステムにおいて、
    そのコンピュータは、
    関連する車輌に関する情報を蓄積し得るメモリを備える
    ことを特徴とする車輌プロトコル変換システム。
14. 請求項１３に記載のシステムにおいて、
    その情報は、車輌識別番号からなる
    ことを特徴とする車輌プロトコル変換システム。
15. 請求項１に記載のシステムにおいて、
    そのコンピュータは、さらに、
    車輌バス上のノードの動作を実行し得る
    ことを特徴とする車輌プロトコル変換システム。
16. 請求項１に記載のシステムにおいて、
    そのコネクタは、
    １６個のピンを備えるアセンブリライン診断リンクコネクタからなる
    ことを特徴とする車輌プロトコル変換システム。
17. 請求項１に記載のシステムにおいて、
    そのコンピュータは、さらに、
    その無線リンクを通じて送信されるメッセ−ジを管理し得る
    ことを特徴とする車輌プロトコル変換システム。
18. 請求項１７に記載のシステムにおいて、
    そのコンピュータは、
    バッファ中にメッセージを蓄積し、
    十分な数のそのようなメッセージがそのバッファ中に存在するかを判断し、
    十分な数のそのようなメッセージがそのバッファ中に存在する場合は、そのメッセージを、その無線リンクを通じて送信されるメッセージを管理するために送信する
    ことを特徴とする車輌プロトコル変換システム。
19. 請求項１に記載のシステムにおいて、
    そのコンピュータは、さらに、
    そのバス上の複数のアドレスを請求し得る
    ことを特徴とする車輌プロトコル変換システム。
20. 請求項１に記載のシステムにおいて、
    その無線通信装置は、
    高速、ショートレンジの無線通信装置である
    ことを特徴とする車輌プロトコル変換システム。
21. 車輌プロトコル変換方法であって、
    車輌バスプロトコルに従って、車輛バスコネクタを通じてメッセージを受信し、
    そのメッセージを解析して、それらが送信されるべきかを判断し、
    それらが送信されるべきなら、そのメッセージを無線リンクを通じて送信する
    ことを特徴とする車輌プロトコル変換方法。
22. 請求項２１に記載の方法において、さらに、
    その無線リンクを通じて、その車輌バスコネクタを通じた通信向けのメッセージを受信し、
    車輌バスプロトコルに従って、そのバスコネクタを通じてそのメッセージを送信する
    ことを特徴とする車輌プロトコル変換方法。
23. 請求項２２に記載の方法において、さらに、
    その車輌バスを通じた通信向けのメッセージを解析して、それらがその車輌バスコネクタを通じて送信されるべきかを判断する
    ことを特徴とする車輌プロトコル変換方法。
24. 請求項２２に記載の方法において、さらに、
    送信されるメッセージをその無線リンクを通じた送信用にフォーマットし、
    そのバスコネクタを通じた通信向けのメッセージを、そのバスコネクタを通じた通信用にフォーマットし得る
    ことを特徴とする車輌プロトコル変換方法。
25. 請求項２１に記載の方法において、さらに、
    複数のプロトコルトランシーバのどれが車輌バスプロトコルに従ってバスコネクタを通じてメッセージを送信するかを選択する
    ことを特徴とする車輌プロトコル変換方法。
26. 請求項２１に記載の方法において、
    そのメッセージの解析は、
    そのメッセージが予め決められた基準を満たすかを判断する
    ことを特徴とする車輌プロトコル変換方法。
27. 請求項２６に記載の方法において、
    解析される複数の予め決められた基準が存在する
    ことを特徴とする車輌プロトコル変換方法。
28. 請求項２１に記載の方法において、さらに、
    その無線リンクを通じて、予め決められた基準を有するメッセージを受信し、
    そのメッセージを識別し、
    その基準を実行する
    ことを特徴とする車輌プロトコル変換方法。
29. 請求項２１に記載の方法において、
    その車輌バスプロトコルは、Ｊ１９３９からなる
    ことを特徴とする車輌プロトコル変換方法。
30. 請求項２１に記載の方法において、さらに、
    そのバスコネクタを通じて受信されたメッセージを蓄積し、
    無線リンクが確立された時にそのメッセージを送信する
    ことを特徴とする車輌プロトコル変換方法。
31. 請求項２１に記載の方法において、さらに、
    関連する車輌に関する情報を蓄積する
    ことを特徴とする車輌プロトコル変換方法。
32. 請求項２１に記載の方法において、
    その無線リンクは、
    高速、ショートレンジの無線リンクからなる
    ことを特徴とする車輌プロトコル変換方法。
33. 請求項２１に記載の方法において、
    その無線リンクを通じて送信されるメッセージを管理する
    ことを特徴とする車輌プロトコル変換方法。
34. 請求項３３に記載の方法において、
    その無線リンクを通じて送信されるメッセージの管理は、
    バッファ中にメッセージを蓄積し、
    十分な数のそのようなメッセ−ジがそのバッファ内に存在するかを判断し、
    十分な数のメッセージが存在する場合に、そのメッセージを送信する
    ことを特徴とする車輌プロトコル変換方法。
35. 車輌プロトコル変換システムであって、
    車輌バスプロトコルに従って、バスコネクタを通じてメッセージを受信するための手段と、
    そのメッセージを解析して、それらが送信されるべきかを判断するための手段と、
    それらが送信されるべきなら、そのメッセージを無線リンクを通じて送信するための手段とを備える
    ことを特徴とする車輌プロトコル変換システム。
36. 請求項３５に記載のシステムにおいて、さらに、
    その無線リンクを通じて、その車輌バスコネクタを通じた通信向けのメッセージを受信するための手段と、
    そのメッセージを解析して、それらがその車輌バスコネクタを通じて送信されるべきかを判断するための手段と、
    それらがその車輌バスコネクタを通じて送信されるべきなら、車輌バスプロトコルに従って、その車輛バスコネクタを通じてそのメッセージを送信するための手段とを備える
    ことを特徴とする車輌プロトコル変換システム。
37. 請求項３５に記載のシステムにおいて、さらに、
    複数のプロトコルトランシーバのどれが車輌バスプロトコルに従ってそのバスコネクタを通じてメッセージを送信するかを選択するための手段を備える
    ことを特徴とする車輌プロトコル変換システム。
38. 請求項３５に記載のシステムにおいて、
    そのメッセージの解析は、
    そのメッセージが予め決められた基準を満たすかを判断する
    ことを特徴とする車輌プロトコル変換システム。
39. 請求項３５に記載のシステムにおいて、
    その無線リンクを通じて、予め決められた基準を有するメッセージを受信するための手段と、
    そのメッセージを識別するための手段と、
    その基準を実行するための手段とを備える
    ことを特徴とする車輌プロトコル変換システム。
40. 請求項３５に記載のシステムにおいて、
    その無線リンクを通じて送信される情報を蓄積するための手段を備える
    ことを特徴とする車輌プロトコル変換システム。
41. 請求項３５に記載のシステムにおいて、
    その無線リンクは、高速、ショートレンジの無線リンクからなる
    ことを特徴とする車輌プロトコル変換システム。
42. 請求項３５に記載のシステムにおいて、さらに、
    その無線リンクを通じて送信されるメッセージを管理するための手段を備える
    ことを特徴とする車輌プロトコル変換システム。
43. 車輌プロトコル変換システムであって、
    車輌バスに接続され得るバスコネクタと、
    バスコネクタに接続される複数のプロトコルトランシーバであって、各プロトコルトランシーバは、バスコネクタを通じた通信向けのメッセージを受信し、車輌バスプロトコルに従ってそのメッセージをそのバスコネクタを通じて送信し、その車輌バスプロトコルに従ってそのバスコネクタを通じてメッセージを受信し得る複数のプロトコルトランシーバと、
    そのプロトコルトランシーバに接続されるコンピュータであって、そのバスコネクタを通じて受信されたメッセージを受信して、それらが送信されるべきかを決定し、そのバスコネクタを通じた通信向けのメッセージを受信し、それらがそのバスコネクタを通じて送信されるべきかを判断し、そのプロトコルトランシーバの中から、そのバスコネクタを通じてそのメッセージを送信するプロトコルトランシーバを選択し、受信されたメッセージがそれに向けられたものかを判断し得るコンピュータと、
    そのコンピュータに接続される無線通信装置であって、無線リンクを用いて、送信されるべきメッセージを送信し、そのバスコネクタを通じた通信向けのメッセージを受信し、また、そのコンピュータに向けられたメッセージを受信し得る無線通信装置とを備える
    ことを特徴とする車輌プロトコル変換システム。
44. 請求項４３に記載のシステムにおいて、
    そのコンピュータは、
    そのバスコネクタを通じて受信されたメッセージが送信されるべきかを判断するための複数の予め決められた基準セットを備える
    ことを特徴とする車輌プロトコル変換システム。
45. 請求項４３に記載のシステムにおいて、
    そのコンピュータに向けられた少なくともいくつかのメッセージは、そのバスコネクタを通じて受信されたメッセージが送信されるべきかを判断するための基準を示す
    ことを特徴とする車輌プロトコル変換システム。
46. 請求項４３に記載のシステムにおいて、
    その無線通信装置は、高速、ショートレンジの無線通信装置である
    ことを特徴とする車輌プロトコル変換システム。

Images