(57)【要約】【課題】ＩＥバスに接続される複数の機器間で新たなハードウエアを追加することなく、ＵＡＲＴ通信を行う通信制御プログラムを得ること。【解決手段】通信制御プログラムは、ＵＡＲＴ通信における通信プログラムの送信処理の前処理として受信側の機器を待機状態から受信待ち状態に移行させるためにデータ出力端子を“Ｌ”から“Ｈ”に変化させた後に、データ出力端子に送信すべきデータを出力し、送信が終了すると、ＵＡＲＴ通信における通信プログラムの送信処理の後処理としてＩＥバスに定められているアイドル状態としてデータ出力端子を“Ｈ”から“Ｌ”に変化させる。【選択図】        図１
2005236649.tif 000002
【特許請求の範囲】
【請求項１】
衝突検知によってアクセス制御を行うバスに接続される複数の機器同士が、データを送信しない場合にデータ出力端子を前記バスによって定められている極性とは異なる極性にすることが定められていて、かつデータを送信する機器のデータ出力端子の極性の変化をデータ入力端子によって検出して受信を開始する通信方式を用いて通信を行うための通信制御プログラムであって、
データを送信しないアイドル状態では前記データ出力端子を前記バスによって定められている極性にし、送信すべきデータが発生すると前記データ出力端子を前記通信方式に定められているアイドル状態の極性にして前記通信方式に基づいてデータの送信を開始し、送信が終了すると前記データ出力端子を前記通信方式に定められたアイドル状態の極性にした後に、前記データ出力端子を前記バスによって定められた極性にする送信処理ステップと、
前記データ入力端子が前記バスによって定められている極性から前記通信方式に定められているアイドル状態の極性に変化したことを検出すると前記通信方式に基づいてデータの受信を開始する受信処理ステップと、
を備えることを特徴とする通信制御プログラム。
【請求項２】
データを送信しないアイドル状態のときに、衝突検知によってアクセス制御を行うバスに定められている極性とは異なる極性をデータ出力端子に出力する通信方式によって通信を行う機器を前記バスに補助装置を介して接続して通信を行うための通信制御プログラムであって、
前記データを送信しないときには、送信制御端子をアサートにして、前記データ出力端子を前記バスから切断することで前記データ出力端子が前記バスによって定められている極性となるように前記補助装置を動作させ、送信すべきデータが発生すると前記送信制御端子をネゲートにして前記データ出力端子を前記バスに接続して前記通信方式に基づいてデータの送信を開始し、送信が終了すると前記送信制御端子をアサートにして、前記データ出力端子を前記バスから切断する送信処理ステップと、
前記データ入力端子が前記バスによって定められている極性から前記通信方式に定められているアイドル状態の極性に変化したことを検出すると、前記通信方式に基づいてデータの受信を開始する受信処理ステップと、
を備えることを特徴とする通信制御プログラム。
【請求項３】
前記バスにＩＥバスを使用し、前記通信方式にＵＡＲＴを用いることを特徴とする請求項１または２に記載の通信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、バスに接続される複数の機器同士が、データを送信しない場合にデータ出力端子を接続されているバスによって定められている極性とは異なる極性にすることが定められていて、かつデータを送信する機器のデータ出力端子の極性の変化をデータ入力端子によって検出して受信を開始する通信方式を用いて通信をおこなうための通信制御プログラムに関するものである。
【背景技術】
【０００２】
約２０年ほど前から、車載ＬＡＮ（Local Area Network）の検討が本格化してきた。車載ＬＡＮは、各種スイッチ類およびライトの点灯やドアの開閉などのボディ系、エンジンやトランスミッション、ブレーキなどのパワートレイン系、エアバックや衝突センサなどの安全系、および、カーナビケーションシステムやカーオーディオシステムなどの情報系に分類され、その用途に適した通信プロトコルを使用している。情報系の車載ＬＡＮは、音声データや画像データを扱うために高速通信が要求され、ＩＥＢｕｓ（Inter Equipment Bus）（登録商標）やＭＯＳＴ（Media Oriented System Transport）、Ｄ２Ｂ／Ｏｐｔｉｃａｌ（Domestic Digital Bus/Optical）などの通信プロトコルが用いられることが多い。
【０００３】
図６は、ＩＥＢｕｓ（以下、ＩＥバスとする）を用いた車載ＬＡＮのハード構成を示すブロック図である。図６に示した車載ＬＡＮは、たとえば、ＣＤ（Compact Disk）カセットデッキやＣＤチェンジャー、スピーカー、ビデオチューナー、ディスプレーなどの複数（この場合は２台）の機器１０，１２と、バスドライバ２０，２２と、複数のプルダウン抵抗Ｒとで構成される。
【０００４】
機器１０は、本来の機能（たとえば、ＣＤカセットデッキであればＣＤを再生制御する機能）に加えて、ＩＥバスによる通信機能を備えている。機器１０はデータ出力端子Ｔｘの電圧を“Ｌ”または“Ｈ”に変化させて所望のデータを送信するとともに、データ入力端子Ｒｘに入力される電圧が“Ｌ”であるのか“Ｈ”であるのかを識別して、データを受信する。機器１２のＩＥバスによる通信機能も、機器１０と同じ機能である。
【０００５】
バスドライバ２０，２２は、同じ機能を備えている。バスドライバ２０は、ＩＥバスのインターフェース機能を備えている。ＩＥバスは差動バスであるので、バスドライバ２０は、データ入力端子ＳＩから入力されるデータを差動信号に変換して差動入出力端子ＢＵＳ＋，ＢＵＳ−に出力する。また、バスドライバ２０は、差動入出力端子ＢＵＳ＋，ＢＵＳ−に入力される差動信号によるデータを受信して、データ出力端子ＳＯを“Ｌ”または“Ｈ”に変化させて受信したデータを出力する。すなわち、バスドライバ２０は、データ入力端子ＳＩから入力される信号を差動信号に変換して差動入出力端子ＢＵＳ＋，ＢＵＳ−に出力するドライブ処理と、差動入出力端子ＢＵＳ＋，ＢＵＳ−から入力される差動信号を受信して電圧信号に変換してデータ出力端子ＳＯに出力するレシーブ処理とを行う。
【０００６】
図７は、機器１２から機器１０に対してデータを送信するデータ転送の概念図である。図７に示すように、機器１２のデータ出力端子Ｔｘから出力された送信データである信号３０は、バスドライバ２２のデータ入力端子ＳＩに入力される。バスドライバ２２は、データ入力端子ＳＩに入力された信号３０にドライブ処理を施して、差動信号に変換した信号３１を差動入出力端子ＢＵＳ＋，ＢＵＳ−から出力する。
【０００７】
バスドライバ２０は、差動入出力端子ＢＵＳ＋，ＢＵＳ−から入力される信号３１にレシーブ処理を施して、電圧信号に変換した信号３２をデータ出力端子ＳＯから出力する。機器１０は、データ入力端子Ｒｘに入力された信号３２を受信する。
【０００８】
ＩＥバスはＣＳＭＡ／ＣＤ（Carrier Sense Multiple Access with Collision Detection）方式によってアクセス制御を行っている。そのため、機器１２から信号３０を受信したバスドライバ２２は、信号３０にドライブ処理を施して差動信号に変換した信号３１を差動入出力端子ＢＵＳ＋，ＢＵＳ−に出力するとともに、差動入出力端子ＢＵＳ＋，ＢＵＳ−の入力に対してレシーブ処理を施して、電圧信号に変換した信号３３をデータ出力端子ＳＯから出力する。機器１２は、データ入力端子Ｒｘから入力される信号３３およびデータ出力端子Ｔｘから出力した信号３０に基づいて衝突検知を行って、データを送信できたか否かを判断する。
【０００９】
一般的に、衝突検知は、エコーバックされたデータと自機器が送信したデータとが一致しているか否かを判定するため、データ送信を行わない機器のデータ出力端子Ｔｘを固定しておく必要がある。ＩＥバスでは、データ送信を行わない場合にはデータ出力端子Ｔｘを“Ｌ”に固定するように定められている。
【００１０】
一方、従来からパーソナルコンピュータなどでは、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）方式による通信が行われており、機器内にＵＡＲＴのハードウエアおよびソフトウエア（通信プログラム）が内蔵されているものが多い。そのため、ＵＡＲＴ通信によるハード構成は、図８に示すように、機器１４のデータ出力端子Ｔｘと機器１６のデータ入力端子Ｒｘとを伝送媒体４１で接続し、機器１６のデータ出力端子Ｔｘと機器１４のデータ入力端子Ｒｘとを伝送媒体４０で接続すればよい。
【００１１】
図９のフローチャートと、図１０−１〜図１０−４を参照して、機器１６から機器１４にデータを送信する場合を例に挙げて、通信プログラムの動作を説明する。通信プログラムは、送信処理と受信処理とで構成される。ここでは、送信側の機器１６によって送信処理の動作を、受信側の機器１４によって受信処理の動作を説明する。なお、初期状態においては、図１０−１に示すように、送信側の機器１６はアイドル状態（データを送信しない状態）にあってデータ出力端子Ｔｘは“Ｈ”に固定されている。また、受信側の機器１４は受信待ち状態となっているものとする。
【００１２】
機器１６の通信プログラムは、送信すべきデータが発生するとデータ出力端子Ｔｘを“Ｌ”にする（ステップＳ１００，Ｓ１１０）。受信待ち状態において機器１４の通信プログラムは、データ入力端子Ｒｘの状態を常に監視している。機器１４の通信プログラムは、データ入力端子Ｒｘが“Ｈ”から“Ｌ”に変化したことを検出すると、予め定められた通信レートでデータ入力端子Ｒｘの状態を識別するための時間を計測するタイマを起動するなど機器１４内のＵＡＲＴ通信に関するハードウエアを起動して、データの受信を開始する（ステップＳ２００，Ｓ２１０）。すなわち、図１０−２に示すように、機器１６はアイドル状態から送信開始状態に移行してデータ出力端子Ｔｘを “Ｌ”にして、機器１４を受信待ち状態から受信開始状態に移行させる。
【００１３】
機器１６の通信プログラムは、たとえば、送信データが“０”であればデータ出力端子Ｔｘを“Ｌ”にし、送信データが“１”であればデータ出力端子Ｔｘを“Ｈ”にしてデータを送信する動作を、送信するデータがなくなるまで繰り返す（ステップＳ１２０，Ｓ１３０）。
【００１４】
一方、機器１４の通信プログラムは、予め定められた通信レートに基づいてデータ入力端子Ｒｘが“Ｈ”であるのか“Ｌ”であるのかを識別してデータを受信する動作を、コマンド単位やパケット単位などのデータの受信が終了するまで繰り返す（ステップＳ２２０，Ｓ２３０）。たとえば、図１０−３に示すように、機器１６がデータ出力端子Ｔｘから８ビットの送信データ “１０１００１１０”を送信すると、機器１４はデータ入力端子Ｒｘが“Ｈ”であるのか“Ｌ”であるのかを識別して“１０１００１１０”を受信する。
【００１５】
送信するデータがなくなると、機器１６の通信プログラムは、データ出力端子Ｔｘを“Ｈ”にする（ステップＳ１４０）。一方、機器１４の通信プログラムは、全てのデータを受信すると、ＵＡＲＴ通信に関するハードウエアを停止して受信を終了する（ステップＳ２４０）。すなわち、図１０−４に示すように、機器１６は送信開始状態からアイドル状態に移行してデータ出力端子Ｔｘを“Ｈ”にして、機器１４は受信開始状態から受信待ち状態に移行する。
【００１６】
このようにＵＡＲＴ通信の通信プログラムは、データを送信しない時にはデータ出力端子Ｔｘを“Ｈ”にしておき、データを送信するときにデータ出力端子Ｔｘを“Ｈ”から“Ｌ”に変化させて通信相手（受信側）の機器に通信開始を通知するようにしている。すなわち、送信処理においてアイドル状態ではデータ出力端子Ｔｘを“Ｈ”にしておき、データを送信する送信開始状態にデータ出力端子Ｔｘを“Ｌ”にすることで、受信処理における受信待ち状態を受信開始状態に移行させるようにしている。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
以上説明したように、ＵＡＲＴ通信ではアイドル状態の機器はデータ出力端子を“Ｈ”にするのに対して、ＩＥバスではアイドル状態の機器はデータ出力端子を“Ｌ”にしなければならない。すなわち、ＵＡＲＴ通信とＩＥバスとは、アイドル状態において相反する特性を有している。したがって、ＩＥバスを用いた車載ＬＡＮに接続されるＣＤカセットレコーダーやＣＤチェンジャーなどのカーオーディオ機器と、パーソナルコンピュータとを接続することができない。そのため、カーオーディオ機器に不具合が発生した場合などは、機器を分解して、基板を測定器などで触針しなければならないという問題が一例としてあげられる。
【００１８】
この問題は、カーオーディオ機器にＵＡＲＴ通信とＩＥバスによる通信との２つのインターフェースを備えることで解決することができる。しかしながら、ＩＥバスへの物理的な接続は、送信用のデータ出力端子と受信用のデータ入力端子との２端子しか存在しないため、新たに２つの通信を制御する信号を設けることはできない。そのため、ＵＡＲＴ通信およびＩＥバスによる通信の２つのインターフェースを備える場合には、２種類の独立したハードウエアおよびソフトウエアを備えなければならず、機器に搭載する部品数の増加やソフトウエアを記憶するメモリのメモリ量の増加をまねき、機器のコストが高くなってしまうという問題が一例としてあげられる。また、カーオーディオ機器は、設置場所が限られているので機器の大きさが決められており、２種類のハードウエアを備えることはスペース的にも問題がある。
【００１９】
本発明は、上記に鑑みてなされたものであって、ＩＥバスに接続される複数の機器間で新たなハードウエアを追加することなく、ＵＡＲＴ通信を行う通信制御プログラムを得ることを目的とする。
【課題を解決するための手段】
【００２０】
請求項１に記載の発明は、衝突検知によってアクセス制御を行うバスに接続される複数の機器同士が、データを送信しない場合にデータ出力端子を前記バスによって定められている極性とは異なる極性にすることが定められていて、かつデータを送信する機器のデータ出力端子の極性の変化をデータ入力端子によって検出して受信を開始する通信方式を用いて通信を行うための通信制御プログラムであって、データを送信しないアイドル状態では前記データ出力端子を前記バスによって定められている極性にし、送信すべきデータが発生すると前記データ出力端子を前記通信方式に定められているアイドル状態の極性にして前記通信方式に基づいてデータの送信を開始し、送信が終了すると前記データ出力端子を前記通信方式に定められたアイドル状態の極性にした後に、前記データ出力端子を前記バスによって定められた極性にする送信処理ステップと、前記データ入力端子が前記バスによって定められている極性から前記通信方式に定められているアイドル状態の極性に変化したことを検出すると前記通信方式に基づいてデータの受信を開始する受信処理ステップと、を備えることを特徴とする。
【００２１】
また、請求項２に記載の発明は、データを送信しないアイドル状態のときに、衝突検知によってアクセス制御を行うバスに定められている極性とは異なる極性をデータ出力端子に出力する通信方式によって通信を行う機器を前記バスに補助装置を介して接続して通信を行うための通信制御プログラムであって、前記データを送信しないときには、送信制御端子をアサートにして、前記データ出力端子を前記バスから切断することで前記データ出力端子が前記バスによって定められている極性となるように前記補助装置を動作させ、送信すべきデータが発生すると前記送信制御端子をネゲートにして前記データ出力端子を前記バスに接続して前記通信方式に基づいてデータの送信を開始し、送信が終了すると前記送信制御端子をアサートにして、前記データ出力端子を前記バスから切断する送信処理ステップと、前記データ入力端子が前記バスによって定められている極性から前記通信方式に定められているアイドル状態の極性に変化したことを検出すると、前記通信方式に基づいてデータの受信を開始する受信処理ステップと、を備えることを特徴とする。
【発明を実施するための最良の形態】
【００２２】
以下に添付図面を参照して、本発明にかかる通信制御プログラムの好適な実施の形態を詳細に説明する。
【００２３】
［概要および特徴］
この発明における通信制御プログラムは、通信制御プログラムの受信処理に機器が受信に関する処理を何も行わない待機状態を設けるとともに、通信制御プログラムの送信処理のアイドル状態と送信開始状態との間に、受信側の機器を待機状態から受信待ち状態に移行させるための受信要求状態を設ける。そして、通信制御プログラムは、アイドル状態ではＩＥバスに定められるようにデータ出力端子を“Ｌ”にしておき、受信要求状態ではデータ出力端子を“Ｈ”にして受信側の機器を待機状態から受信待ち状態に移行させる。その後、通信制御プログラムは、受信要求状態から受信開始状態に移行してデータ出力端子を“Ｌ”にして受信側の機器を受信待ち状態から受信開始状態に移行させてデータを送信する。
【００２４】
すなわち、この発明における通信制御プログラムは、従来のＵＡＲＴ通信における通信プログラムの送信処理の前処理として受信側の機器を待機状態から受信待ち状態に移行させるためにデータ出力端子を“Ｌ”から“Ｈ”に変化させるステップと、従来のＵＡＲＴ通信における通信プログラムの送信処理の後処理としてＩＥバスに定められているアイドル状態としてデータ出力端子を“Ｈ”から“Ｌ”に変化させるステップとを追加するという簡単なプログラムの変更だけで、２つのハードウエアを備えることなく、ＩＥバスにおいてＵＡＲＴ通信を実現することができる。
【実施例１】
【００２５】
図１および図２（図２−１〜図２−６）を用いて本発明における実施例１を説明する。この発明における実施例１のハード構成は、図６に示した従来のＩＥバスを用いた車載ＬＡＮのハード構成と同様となるのでここではその説明を省略する。
【００２６】
つぎに、図１のフローチャートと図２を参照して、機器１２から機器１０にデータを送信する場合を例に挙げて、この発明における実施例１の通信制御プログラムの動作を説明する。この発明における実施例１の通信制御プログラムは、送信処理と受信処理とで構成される。ここでは、送信側の機器１２によって送信処理部の動作を、受信側の機器１０によって受信処理の動作を説明する。なお、初期状態においては、図２−１に示すように、送信側の機器１２はアイドル状態にあってデータ出力端子Ｔｘは“Ｌ”に固定されており、受信側の機器１０は待機状態になっているものとする。
【００２７】
機器１２の通信制御プログラムは、送信すべきデータが発生するとデータ出力端子Ｔｘを“Ｈ”にする（ステップＳ１０，Ｓ１１）。待機状態において機器１０の通信制御プログラムは、データ入力端子Ｒｘの状態を常に監視している。機器１０の通信制御プログラムは、データ入力端子Ｒｘが“Ｌ”から“Ｈ”に変化したことを検出すると、待機状態から受信待ち状態に移行して、さらにデータ入力端子Ｒｘの状態を監視する（ステップＳ２０）。すなわち、図２−２に示すように、機器１２はアイドル状態から受信要求状態に移行してデータ出力端子Ｔｘを“Ｈ”にして、機器１０を待機状態から受信待ち状態に移行させる。
【００２８】
機器１２の通信制御プログラムは、受信側の機器１０が待機状態から受信待ち状態に移行するために必要な時間をとった後に、データ出力端子Ｔｘを“Ｌ”にする（ステップＳ１２）。機器１０の通信制御プログラムは、データ入力端子Ｒｘが“Ｈ”から“Ｌ”に変化したことを検出すると、予め定められた通信レートでデータ入力端子Ｒｘの状態を識別するための時間を計測するタイマを起動するなど機器１０内のＵＡＲＴ通信に関するハードウエアを起動して、データの受信を開始する（ステップＳ２１，Ｓ２２）。すなわち、図２−３に示すように、機器１２は受信要求状態から送信開始状態に移行してデータ出力端子Ｔｘを “Ｌ”にして、機器１０を受信待ち状態から受信開始状態に移行させる。
【００２９】
機器１２の通信制御プログラムは、たとえば、送信データが“０”であればデータ出力端子Ｔｘを“Ｌ”にし、送信データが“１”であればデータ出力端子Ｔｘを“Ｈ”にしてデータを送信する動作を、送信するデータがなくなるまで繰り返す（ステップＳ１３，Ｓ１４）。
【００３０】
一方、機器１０の通信制御プログラムは、予め定められた通信レートに基づいてデータ入力端子Ｒｘが“Ｈ”であるのか“Ｌ”であるのかを識別してデータを受信する動作を、コマンド単位やパケット単位などのデータの受信が終了するまで繰り返す（ステップＳ２３，Ｓ２４）。たとえば、図２−４に示すように、機器１２がデータ出力端子Ｔｘから８ビットの送信データ “１０１００１１０”を送信すると、機器１０はデータ入力端子Ｒｘが“Ｈ”であるのか“Ｌ”であるのかを識別して“１０１００１１０”を受信する。
【００３１】
送信するデータがなくなると、機器１２の通信制御プログラムは、データ出力端子Ｔｘを“Ｈ”にする（ステップＳ１５）。一方、機器１０の通信制御プログラムは、全てのデータを受信すると、ＵＡＲＴ通信に関するハードウエアを停止して受信を終了する（ステップＳ２５）。すなわち、図２−５に示すように、機器１２は送信開始状態からアイドル状態に移行してデータ出力端子Ｔｘを“Ｈ”にして、機器１０は受信開始状態から待機状態に移行する。
【００３２】
機器１２の通信制御プログラムは、所定の時間をおいた後に、データ出力端子Ｔｘを“Ｌ”にする（ステップＳ１６）。すなわち、図２−６に示すように、機器１２は、データ出力端子Ｔｘを“Ｌ”に固定して、ＩＥバスに定められているアイドル状態となる。
【００３３】
このようにこの実施例１では、従来のＵＡＲＴ通信における通信プログラムの送信処理の前処理として受信側の機器を待機状態から受信待ち状態に移行させるためにデータ出力端子を“Ｌ”から“Ｈ”に変化させるステップと、従来のＵＡＲＴ通信における通信プログラムの送信処理の後処理としてＩＥバスに定められているアイドル状態としてデータ出力端子を“Ｈ”から“Ｌ”に変化させるステップとを追加するという簡単なプログラムの変更だけで、２つのハードウエアを備えることなく、ＩＥバスにおいてＵＡＲＴ通信を実現することができる。すなわち、ＵＡＲＴ通信のためのハードウエアを備える必要がなくなって部品数が増加することがないため、機器のコストを上げることなく、ＩＥバスにおいてＵＡＲＴ通信を行うことができる。
【実施例２】
【００３４】
図３〜図５を用いてこの発明における実施例２を説明する。実施例１では、ＩＥバスに接続される機器のデータ出力端子を制御してＵＡＲＴ通信を行うようにした。しかしながら、一般的に、パーソナルコンピュータや周辺機器、民生機器は、ＴＩＡ／ＥＩＡ−２３２−Ｅ（一般的にはＲＳー２３２）の規格を用いており、ＲＳ−２３２のドライバプログラムを用いて通信を行っているため、データ出力端子を任意に制御することは難しい。この実施例２では、このような問題を解決するために、データ出力端子とバスドライバとの間に補助装置を設け、この補助装置を制御することでＲＳ−２３２の規格に準拠している機器をＩＥバスに接続してＵＡＲＴ通信を行うものである。
【００３５】
図３は、ＲＳ−２３２に準拠する入出力端子を備える機器をＩＥバスによる車載ＬＡＮに接続するハード構成を示す図である。この発明における実施例２のハード構成は、図６に示した機器１０の代わりにパーソナルコンピュータ（以下、パソコンとする）１８を備え、パソコン１８はＲＳ−２３２のラインドライバ５０と補助装置６０を介してバスドライバ２０に接続されている。図６に示したハード構成と同じ機能を持つ構成部分には同一符号を付し、重複する説明は省略する。
【００３６】
パソコン１８は、ＲＳ−２３２に準拠した入力端子を備えている。ＲＳ−２３２には９ピン、２５ピンなどがあるが、一般的に、全ての端子（ピン）が使用されることは少ない。通信で必ず使用する端子（ドライバプログラムによって制御される端子）は、送信時に信号を出力するデータ出力端子ＳＤと、受信時に信号を入力するデータ入力端子ＲＤであり、キャリア検出やデータ・セット・ディレーなどの端子は使用していないことが多い。また、ドライバプログラムによって制御されない端子については、ユーザが変更することは容易であるので、ここでは、データ・セット・ディレーを送信制御端子ＤＲとして使用する。なお、送信制御端子ＤＲとして使用する端子は、これに限るものではない。
【００３７】
パソコン１８には、この発明における実施例２の通信制御プログラムが搭載されており、通信制御プログラムによって送信制御端子ＤＲを制御して、ＵＡＲＴ通信（ＲＳ−２３２に準拠する通信）を行う。
【００３８】
補助装置６０は、トランジスタＴｒと抵抗Ｒ１とで構成される。トランジスタＴｒは、ラインドライバ５０を介して入力されるパソコン１８の送信制御端子ＤＲからの制御信号によってオン／オフされて、ラインドライバ５０を介して入力されるデータ出力端子からの信号をバスドライバのデータ入力端子ＳＩに出力するか、またはデータ出力端子をＩＥバスから切断してバスドライバのデータ入力端子ＳＩを“Ｌ”にする。
【００３９】
つぎに、図４および図５のフローチャートを参照して、この発明における実施例２の通信制御プログラムの動作を説明する。一般的には、図３に示したようなハード構成となるが、この発明における実施例２の通信制御プログラムの送信処理および受信処理を同時に説明するために、図４に示すように、パソコン１８がラインドライバ５０、補助装置６０およびバスドライバ２０を介してＩＥバスに接続され、パソコン１９がラインドライバ５２、補助装置６１およびバスドライバ２２を介してＩＥバスに接続されているものとする。なお、補助装置６１は補助装置６０と同じ機能を備えており、ラインドライバ５２はラインドライバ５０と同じ機能を備えている。また、この発明における実施例２の通信制御プログラムは、送信処理と受信処理とで構成されており、ここでは、パソコン１８からパソコン１９にデータを送信するものとして、送信側のパソコン１８によって送信処理の動作を、受信側のパソコン１９によって受信処理の動作を説明する。
【００４０】
初期状態においては、送信側のパソコン１８はアイドル状態にあってデータ出力端子ＳＤは“Ｈ”に、送信制御端子ＤＲは“Ｌ”に固定されている。パソコン１８の送信制御端子ＤＲが“Ｌ”であるので、補助装置６０のトランジスタＴｒはオフとなりバスドライバ２０のデータ入力端子ＳＩには“Ｌ”が入力され、パソコン１９は待機状態となっている。
【００４１】
パソコン１８の通信制御プログラムは、送信すべきデータが発生するとアイドル状態から受信要求状態に移行して、送信制御端子ＤＲを“Ｈ”にする（ステップＳ３０，Ｓ３１）。これにより、補助装置６０のトランジスタＴｒがオンになり、バスドライバ２０のデータ入力端子ＳＩとパソコン１８のデータ出力端子ＳＤとが接続され、バスドライバ２０のデータ入力端子ＳＩには、“Ｈ”が入力されて、パソコン１９のデータ入力端子ＲＤが“Ｈ”になる。
【００４２】
待機状態においてパソコン１９の通信制御プログラムは、データ入力端子ＲＤの状態を常に監視している。パソコン１９の通信制御プログラムは、データ入力端子ＲＤが“Ｌ”から“Ｈ”に変化したことを検出すると、待機状態から受信待ち状態に移行して、さらにデータ入力端子ＲＤの状態を監視する（ステップＳ４０）。
【００４３】
パソコン１８の通信制御プログラムは、受信側のパソコン１９が待機状態から受信待ち状態に移行するために必要な時間をとった後に、受信要求状態から送信開始状態に移行してデータ出力端子ＳＤを“Ｌ”にする（ステップＳ３２）。パソコン１９の通信制御プログラムは、データ入力端子ＲＤが“Ｈ”から“Ｌ”に変化したことを検出すると、受信待ち状態から受信開始状態に移行して、予め定められた通信レートでデータ入力端子ＲＤの状態を識別するための時間を計測するタイマを起動するなどパソコン１９内のＵＡＲＴ通信に関するハードウエアを起動して、データの受信を開始する（ステップＳ４１，Ｓ４２）。
【００４４】
パソコン１８の通信制御プログラムは、たとえば、送信データが“０”であればデータ出力端子ＳＤを“Ｌ”にし、送信データが“１”であればデータ出力端子ＳＤを“Ｈ”にしてデータを送信する動作を、送信するデータがなくなるまで繰り返す（ステップＳ３３，Ｓ３４）。
【００４５】
一方、パソコン１９の通信制御プログラムは、予め定められた通信レートに基づいてデータ入力端子ＲＤが“Ｈ”であるのか“Ｌ”であるのかを識別してデータを受信する動作を、コマンド単位やパケット単位などのデータの受信が終了するまで繰り返す（ステップＳ４３，Ｓ４４）。
【００４６】
送信するデータがなくなると、パソコン１８の通信制御プログラムは、送信開始状態からアイドル状態に移行して、データ出力端子ＳＤを“Ｈ”にする（ステップＳ３５）。一方、パソコン１９の通信制御プログラムは、全てのデータを受信すると、ＵＡＲＴ通信に関するハードウエアを停止して受信を終了する（ステップＳ４５）。そして、データ入力端子ＲＤが“Ｌ”から“Ｈ”に変化したか否かを検出する待機状態に移行する。
【００４７】
パソコン１８の通信制御プログラムは、所定の時間を置いた後に、送信制御端子ＤＲを“Ｌ”にする（ステップＳ３６）。これにより、補助装置６０のトランジスタＴｒがオフになり、パソコン１８のデータ出力端子ＳＤとバスドライバ２０のデータ入力端子ＳＩとが切断され、バスドライバ２０のデータ入力端子ＳＩに“Ｌ”が入力されて、パソコン１９のデータ入力端子ＲＤが“Ｌ”になる。すなわち、パソコン１８はアイドル状態となり、パソコン１９は待機状態となって、初期状態にもどる。
【００４８】
このようにこの実施例２では、ＲＳ−２３２の規格に準拠する機器をＩＥバスに補助装置を介して接続する。この補助装置は、制御信号がネゲート（この実施例２では“Ｈ”になると機器のデータ出力端子をＩＥバスに接続し、制御信号が アサート(この実施例２では“Ｌ”）になるとデータ出力端子をＩＥバスから切断してＩＥバスに“Ｌ”を出力する。通信制御プログラムは、ドライバソフトの送信処理の前処理として受信側の機器を待機状態から受信待ち状態に移行させるために送信制御端子から出力する制御信号をネゲートにするステップと、ドライバソフトの送信処理の後処理としてＩＥバスに定められている極性をＩＥバスに出力するために送信制御端子から出力する制御信号をアサートにするステップとを追加するという簡単なプログラムの変更だけで、ＲＳ−２３２の規格に準拠する機器をＩＥバスに接続してＵＡＲＴ通信を実現することができる。
【００４９】
また、この実施例２の通信制御プログラムは、データ出力端子を制御するのではなく、ＲＳ−２３２の未使用の端子を送信制御端子として用いて、この送信制御端子によって補助装置を制御してＩＥバスのアイドル状態を実現するようにしているので、従来のドライバプログラムを変更することなく、簡単にＲＳ−２３２の規格に準拠する機器をＩＥバスに接続してＵＡＲＴ通信を実現することができる。
【００５０】
なお、この実施例２ではＲＳ−２３２の規格に準拠する機器としてパーソナルコンピュータを例にあげて説明したが、これに限るものではない。たとえば、オーディオ機器を制御するマイクロコンピュータにフラッシュメモリ内臓マイクロコンピュータを使用している場合に、フラッシュメモリにデータを書き込むフラッシュマイコンライタにこの実施例２の通信制御プログラムを搭載しておき、フラッシュマイコンライタを補助装置を用いてＩＥバスで構成される車載ＬＡＮに接続してもよい。これにより、オーディオ機器を解体することなく、機器内のプログラムを変更することができる。
【００５１】
また、オーディオ機器に不具合が発生した場合でも、機器の状態をモニタするダイアグノーシスモニタにこの実施例２の通信制御プログラムを搭載しておき、ダイアグノーシスモニタを補助装置を用いてＩＥバスで構成させる車載ＬＡＮに接続してもよい。これにより、オーディオ機器を解体することなく不具合発生時の機器内部の状態をモニタすることが可能となり、不具合発生時の原因解析の時間を短縮することができる。
【００５２】
さらに、この実施例２では、補助装置をトランジスタと抵抗とで構成したがこれに限るものではなく、ＩＥバスにデータ出力端子からの信号を出力するのか、“Ｌ”を出力するのかを制御信号によって切り替える機能を実現するものであればよい。
【図面の簡単な説明】
【００５３】
【図１】この発明における実施例１の通信制御プログラムの動作を説明するためのフローチャートである。
【図２−１】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図２−２】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図２−３】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図２−４】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図２−５】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図２−６】この発明における実施例１の通信制御プログラムの動作を説明するための図である。
【図３】この発明における実施例２のハード構成を示すブロック図である。
【図４】この発明における実施例２のハード構成を示すブロック図である。
【図５】この発明における実施例２の通信制御プログラムの動作を説明するためのフローチャートである。
【図６】従来の車載ＬＡＮのハード構成を示すブロック図である。
【図７】従来の車載ＬＡＮにおいてデータを送信するデータ転送の概念図である。
【図８】従来のＵＡＲＴ通信を行う機器の接続を示す図である。
【図９】従来のＵＡＲＴ通信による通信プログラムの動作を説明するためのフローチャートである。
【図１０−１】従来の通信プログラムの動作を説明するための図である。
【図１０−２】従来の通信プログラムの動作を説明するための図である。
【図１０−３】従来の通信プログラムの動作を説明するための図である。
【図１０−４】従来の通信プログラムの動作を説明するための図である。
【符号の説明】
【００５４】
１０，１２，１４，１６  機器
１８，１９  パソコン
２０，２２  バスドライバ
４０，４１  伝送媒体
５０，５２  ラインドライバ
６０，６１  補助装置
【図１】
2005236649.tif 000003
【図２−１】
2005236649.tif 000004
【図２−２】
2005236649.tif 000005
【図２−３】
2005236649.tif 000006
【図２−４】
2005236649.tif 000007
【図２−５】
2005236649.tif 000008
【図２−６】
2005236649.tif 000009
【図３】
2005236649.tif 000010
【図４】
2005236649.tif 000011
【図５】
2005236649.tif 000012
【図６】
2005236649.tif 000013
【図７】
2005236649.tif 000014
【図８】
2005236649.tif 000015
【図９】
2005236649.tif 000016
【図１０−１】
2005236649.tif 000017
【図１０−２】
2005236649.tif 000018
【図１０−３】
2005236649.tif 000019
【図１０−４】
2005236649.tif 000020