JP2017019501A - 遠隔車両プログラミングシステムおよび方法 - Google Patents

Abstract

【課題】車両を遠隔でプログラミングする改良されたシステムおよび方法を提供する。【解決手段】一つ以上の車両サブシステムまたはモジュールと関連する複数のピンを有する車両コネクタと、車両コネクタに接続される車両通信装置と、車両通信装置と遠隔通信装置との間の双方向通信リンクと、遠隔通信装置に接続されるコンピュータシステムとを含む車両を遠隔でプログラミングするシステムおよび方法が提供される。車両通信装置は、ピンからの信号を受信し、その信号をネットワーク対応データパケットに変換するように構成される。該データパケットはその後、遠隔通信装置に送信され、その信号は車両走査ツールなどのコンピューティングシステムによって読み取り可能なピン信号に再変換される。遠隔通信装置と車両通信装置との間の双方向通信リンク上で、走査ツールから車両にプログラミング指示を送信することができる。【選択図】 図３

Description

本発明は車両プログラミングシステム、特に車両を遠隔でプログラミングするシステムおよび方法に関する。

車内搭載診断（「ＯＢＤ」）システムにより、車両所有者または技術者は車両内の各種モジュールおよびサブシステムに関する重要な情報にアクセスすることができる。長年の間、製造業者は、車両に複雑なＯＢＤシステムを組み込んできた。このようなＯＢＤシステムは通常、車両のダッシュボード下に配置されるデータリンクコネクタ（「ＤＬＣ」）を通じてアクセス可能である。従来の修理環境では、技術者が、車両のＤＬＣ上で所与の車両のＯＢＤシステムとインタフェースをとるように構成される特別な走査ツールを利用する。走査ツールは、所望に応じてサブシステムの再プログラミングを可能にしつつ、診断のために車両のサブシステムからのデータを読み取ることができる。通常、これらの走査ツールは独立型の携帯コンピューティング装置であるが、当該技術において既知であるパーソナルコンピュータベースの走査ツールもいくつかある。

現在、ＯＢＤ−Ｉとして知られる第１のＯＢＤシステムは当初、法定上の目的で車両排気制御システムを監視するために実装された。しかしながら、ＯＢＤ−Ｉは、車両内のＯＢＤの配置、ＤＬＣの構成、およびデータフォーマットに関する規格がないために不首尾に終わった。

ＯＢＤ−Ｉに付随する課題に答えて、ＯＢＤ−ＩＩが開発された。ＯＢＤ−ＩＩは、機能と標準化の両面でＯＢＤ−Ｉを大きく改善させた。ＯＢＤ−ＩＩ規格は診断コネクタおよびそのピン配列、利用可能な電気信号生成プロトコル、およびメッセージ通信フォーマットの種類を明記している。さらに、ＯＢＤ−ＩＩは、プログラムする車両パラメータの候補リストを、それぞれのデータの暗号化方法と共に提供する。ＯＢＤ−ＩＩは、図１に示すように、規格化されたＤＬＣ−雌１６−ピン（２ｘ８）Ｊ１９６２コネクタも導入した。車両のボンネットの下に配置されることがあるＯＢＤ−Ｉコネクタと異なり、ＯＢＤ−ＩＩコネクタはハンドルから２フィート（０．６１ｍ）内になくてはならないため、通常はダッシュボードの下に配置される。ＯＢＤ−ＩＩは車両のバッテリから走査ツールに電力を供給するピンもコネクタ内に設けるため、走査ツールを別個の電源に接続する必要がない。最後に、ＯＢＤ−ＩＩ規格は、標準化された診断トラブルコードの詳細リストも提供する。

ＳＡＥ Ｊ１９６２は、ＯＢＤコネクタの位置（すなわち、ハンドルから２フィート以内）とそのピン配列構造を以下のように定義する。
１．製造業者の自由裁量
２．バスポジティブライン（ＳＡＥ−Ｊ１８５０ＰＷＭおよびＳＡＥ−１８５０ＶＰＷプロトコル用）
３．Ｆｏｒｄ ＤＣＬ（＋）アルゼンチン、ブラジル（ＯＢＤ−ＩＩ前）１９９７〜２０００、米国、欧州等。クライスラー（Ｃｈｒｙｓｌｅｒ） ＣＣＤバス（＋）
４．シャーシ接地
５．信号接地
６．ＣＡＮ（高）（ＩＳＯ １５７６５−４およびＳＡＥ−Ｊ２２８４プロトコル用）
７．Ｋライン（ＩＳＯ ９１４１−２およびＩＳＯ １４２３０−４）
８．−
９．−１０．バスネガティブライン（ＳＡＥ−Ｊ１８５０ ＰＷＭプロトコル用）
１１．Ｆｏｒｄ ＤＣＬ（−）アルゼンチン、ブラジル（ＯＢＤ−ＩＩ前）１９９７〜２０００、米国、欧州等。クライスラー ＣＣＤバス（−）
１２．−
１３．−
１４．ＣＡＮ（低）（ＩＳＯ １５７６５−４およびＳＡＥ−Ｊ２２８４プロトコル用）１５．Ｌライン（ＩＳＯ ９１４１−２およびＩＳＯ １４２３０−４プロトコル用）
１６．バッテリ電圧
ＯＢＤ−ＩＩは多数の車両製造業者全体にわたって有利な規格化を提供するものの、いまだに製造業者は自身の特定のＯＢＤシステム毎に異なる通信プロトコル、すなわち、信号フォーマットを採用することを選択している。このようなプロトコルは、たとえばＳＡＥ Ｊ１８５０ＰＷＭ、ＳＡＥ ＶＰＭ、ＩＳＯ ９１４１−２、ＩＳＯ １４２３０、およびＩＳＯ １５７６５などである。これらのプロトコルはそれぞれ、ピン配列構造と信号特徴が異なる。

たとえば、ＳＡＥ Ｊ１８５０ＰＷＭ（パルス幅変調−４１．６ｋＢ／秒、Ｆｏｒｄ Ｍｏｔｏｒ社の規格）は以下の特徴を備える。
・ピン２：バス＋
・ピン１０：バス−
・高電圧は＋５Ｖである。
・メッセージ長はＣＲＣを含めて１２バイトに制限される。
・「非破壊仲裁を有する搬送波感知多重アクセス」（ＣＳＭＡ／ＮＤＡ）と称されるマルチマスタ仲裁スキームを使用する。

ＳＡＥ Ｊ１８５０ＶＰＷ（可変パルス幅−１０．４／４１．６ｋＢ／秒、ゼネラルモーターズ（Ｇｅｎｅｒａｌ Ｍｏｔｏｒｓ）社規格）は以下の特徴を備える。
・ピン２：バス＋
・バスがローでアイドリングする。
・高電圧は＋７Ｖである。
・決定点は＋３．５Ｖである。
・メッセージ長はＣＲＣを含めて１２バイトに制限される。
・ＣＳＭＡ／ＮＤＡを採用する。

ＩＳＯ ９１４１−２プロトコルは１０．４ｋＢａｕｄの非同期シリアルデータ転送速度を有し、主にクライスラー、欧州、アジア車で使用されており、以下の特徴を備える。・ピン７：Ｋ−ライン
・ピン１５：Ｌ−ライン（任意）
・ＵＡＲＴ信号生成（非ＲＳ−２３２電圧レベルを通じて）
・Ｋラインがハイでアイドリングする。
・高電圧はＶｂａｔｔである、
・メッセージ長はＣＲＣを含めて１２バイトに制限される。

ＩＳＯ １４２３０ＫＷＰ２０００（キーワードプロトコル２０００）は以下の特徴を備える。
・ピン７：Ｋ−ライン
・ピン１５：Ｌ−ライン（任意）
・物理層はＩＳＯ ９１４１−２と同一である。
・データ転送速度は１．２〜１０．４ｋＢａｕｄである。
・メッセージはデータフィールド内で最大２５５バイトを含むことができる。

ＩＳＯ １５７６５ＣＡＮ（コントローラエリアネットワーク車両バス）（２５０ｋＢｉｔ／秒または５００ｋＢｉｔ／秒）プロトコルは米国自動車業界以外では一般的な規格であり、ＯＢＤ−ＩＩ市場シェアにおいて著しく増加しつつある。２００８年の時点で、米国で販売される車両はすべてＣＡＮの実装を要求されるため、既存の５つの信号生成プロトコルの曖昧さが排除されている。
・ピン６：ＣＡＮ（高）
・ピン１４：ＣＡＮ（低）
したがって、様々な通信プロトコルのため、技術者は、それぞれが特定のＯＢＤ−ＩＩ信号プロトコルに対応する複数の異なる走査ツールを購入する必要がある場合が多い。たとえば、技術者は、フォードモーター（Ｆｏｒｄ Ｍｏｔｏｒ）社製自動車のための走査ツールと、ゼネラルモーターズ製自動車のための別の走査ツールを購入する必要があるかもしれない。よって、技術者が広範な車両の型やモデルにサービスを提供しようと思う場合、走査ツールに相当額を投資しなければならない。さらに、大半の走査ツールは車両のＤＬＣに直接接続される携帯型装置であるため、技術者は車両自体に隣接して、あるいは車両内でサービスを実行しなければならず、標準的な「修理工場」環境では厄介または危険である。

当該技術において、２種類の走査ツールが一般的に既知である。代表的な「アフターマーケット」走査ツールは機能が限られており、適切な燃料効率と排出を維持するため、エンジン制御モジュールやトランスミッション制御モジュールなどの特定のモジュールおよびサブシステムとインタフェースをとることができるだけである。これらのアフターマーケット走査ツールは、ＳＡＥ Ｊ２５３４に規定されるようなシステムとインタフェースをとることに限定される場合が多い。これらのアフターマーケット走査ツールは普通、後述するその他多数の車両モジュールおよびサブシステムを読み取る、解析する、操作する、および再プログラミングする機能を備えていない。一方、製造業者特有の走査ツールは、車両内のモジュールおよびサブシステムすべてとインタフェースをとるように設計される走査ツールであり、上記モジュールおよびサブシステムを読み取る、解析する、操作する、プログラミングする、および再プログラミングする機能を提供する。当然のことながら、製造業者特有の走査ツールを所有および保持するには、限定的なアフターマーケット走査ツールよりもずっとコストがかかる。１つに、走査ツールハードウェア自体が高額なのだが、それよりも重要なことに、製造業者特有の走査ツールは、最新のプログラミングソフトウェアを活用するために、毎日、毎週、または毎月、ソフトウェアを更新する必要がある。したがって、技術者が特定の車両製造業者に対して全範囲のサービスを提供しようと思う場合、最新のソフトウェア更新を得られるように高額な製造業者特有の走査ツールを購入し、定期契約を結ばなければならない。

車両のＯＢＤシステムとインタフェースをとる各種システムおよび方法は当該技術において既知である。
たとえば、キットソン（Ｋｉｔｓｏｎ）の米国特許第６９５６５０１号明細書には、車両に近接する端末、すなわち、ガソリンスタンドに車両情報を送信する無線通信リンクを含む、車両の性能を測定する高度な車両監視システムが記載されている。ローカル端末は情報を処理し、処理した情報をディスプレイやその他の手段を通じて車両のオペレータに通信する。しかしながら、キットソンに記載のシステムは少なくとも２つの理由から望ましくない。第１に、システムが診断および監視、すなわち、データを「読み取る」ことだけに対応しており、車両プログラミング、すなわち、車両サブシステムの変更には不十分である。第２に、キットソンは、車両に近接する、すなわち車両の隣の位置に車両データを送信できるだけである。キットソンは、技術者が車両位置から遠く離れた位置から車両のシステムをプログラミングするシステムまたは方法を提供できない。

バックレイ（Ｂｕｃｋｌｅｙ）の米国特許第７５１９４５８号明細書には、車両から取得した、選択した車両データを取得し解析するシステム、装置、および方法が記載されている。該システムは、車両に通信可能に接続され、車両の動作に関連する車両データを取得するインタフェースを含む。次に、車両データを適切に解析するための必須情報を取得するため、システムはネットワークを介して遠隔ノードと通信する。いったん必要な情報を取得したら、車両データは診断と監視のために解析される。しかしながら、バックレイは、遠隔位置から双方向車両プログラミングタスクを実行することのできるシステムを提供していない。

カンチェラーラ（Ｃａｎｃｅｌｌａｒａ）らの米国特許出願公開第２００５／０２５１３０４号明細書には現地車両診断と遠隔車両診断の両方を実行するシステムが記載されており、該システムは、接続される車両との高度インタフェースとしての役割を果たし、自立車両診断および通信機能を実行することのできる車両通信ユニットを備える。カンチェラーラのシステムは、遠隔診断のためだけに設計されており、車両をプログラミングするシステムおよび方法について述べていない。さらに、カンチェラーラは、車両サブシステムのプログラミングまたは操作ではなく、リアルタイム診断、すなわち、動作中に車両を「読み取ること」を企図している。

ロウリー（Ｌｏｗｒｅｙ）らの米国特許第７５３２９６２号明細書には、通信ソフトウェアをサポートしてコンピュータからの診断データを収集するデータ収集構成要素と、データ収集構成要素と通信し、診断データを含む出力データパケットをネットワーク上で送信し、通信ソフトウェアを修正する入力データパケットを同じネットワーク上で受信するように構成されるデータ伝送構成要素と、を有する車内コンピュータと接触して、車両の動作特徴を監視し無線機器を有するシステムが記載されている。従来技術の大半と同様、ロウリーは車両動作特徴を診断するシステムを提供しているが、車両を遠隔プログラミングするシステムまたは方法を提供していない。

ギリース（Ｇｉｌｌｉｅｓ）の米国特許出願公開第２００９／０２６５０５５号明細書には、修理対象の車両内の無線ＯＢＤ装置と無線通信するように構成される携帯型インタフェース装置が記載されている。ネットワークアクセスポイントおよびその他の無線装置は、車両情報、修理指示、診断情報調査情報、遠隔専門家アドバイス、遠隔データベースおよびアプリケーション、およびインタフェース装置からのその他の修理および診断情報にアクセスするために使用することができる。ギリースのシステムは実質上、車両情報を取得し、その情報をサーバに中継し、サーバは車両情報に基づき技術者に支援情報を提供する。しかしながら、システムはサーバから車両への遠隔プログラミングを提供することができない。

グラハム（Ｇｒａｈａｍ）の米国特許第７５８４０３０号明細書には、車両テスト機器と車両のＯＢＤコンピュータとの間の無線接続を備える取外し可能なコネクタを記載しており、データリンクケーブルが相互に通信するようにあらかじめプログラミング済みの２つのコネクタに置き換えられている。グラハムの装置は、装置によって確立された無線リンクを通じて車両のＯＢＤと走査ツール間の局地無線通信に関する。グラハムはデータネットワーク上でデータをプログラミングする遠隔送信も、同ネットワーク上での車両の遠隔プログラミングも企図していない。

したがって、当該技術では、技術者がＯＤＢインタフェースを通じて遠隔位置から車両にサービスを提供しプログラミングすることができるシステムおよび方法が必要とされる。さらに、当該技術においては、店舗または修理工場が特定の車両の型およびモデルのうちの少なくとも一方毎に多数の高額な走査ツールを購入しなくてもよい、車両をプログラミングするシステムおよび方法も必要とされる。また、広範なＯＢＤ通信プロトコルを実装する様々な車両をプログラムする機能を備えた、遠隔コールセンターから車両をプログラミングするシステムおよび方法も必要とされる。さらに、当該技術では、広範な車両製造業者およびモデル年にとって最新の走査ツールソフトウェアを常に装備する機能を備えた、遠隔コールセンターから車両をプログラミングするシステムおよび方法も必要とされる。本発明の各種実施形態のこれらのおよびその他の目的は、以下の明細書および添付の特許請求の範囲で容易に自明となる。

米国特許第６９５６５０１号明細書 米国特許第７５１９４５８号明細書 米国特許出願公開第２００５／０２５１３０４号明細書 米国特許第７５３２９６２号明細書 米国特許出願公開第２００９／０２６５０５５号明細書 米国特許第７５８４０３０号明細書

車両を遠隔でプログラミングするシステムおよび方法の各種実施形態を開示する。いくつかの実施形態では、該システムは、一つ以上の車両サブシステムまたはモジュールと関連する複数のピンを有する車両コネクタと、車両コネクタに接続される車両通信装置と、車両通信装置と遠隔通信装置との間の双方向通信リンクと、遠隔通信装置に接続されるコンピュータシステムとを備える。車両通信装置は、ピンからの信号を受信し、その信号をネットワーク対応データパケットに変換するように構成され、該データパケットはその後、遠隔通信装置に送信され、その信号は車両走査ツールなどのコンピューティングシステムによって読み取り可能なピン信号に再変換される。プログラミング指示は、遠隔通信装置と車両通信装置との間の双方向通信リンク上で、走査ツールから車両に送信することができる。いくつかの実施形態では、プログラミング指示は、再プログラミング、プログラム更新、較正、リンキング、マリッジ、シリアルコーディング、セキュリティコーディング、およびそれらの組み合わせから成る指示群から選択される。

いくつかの実施形態では、走査ツールは、当該技術において既知の携帯型コンピュータ走査ツールを備える。他の実施形態では、走査ツールは、走査ツールエミュレーションソフトウェアを実行するコンピュータワークステーションを備える。

いくつかの実施形態では、双方向通信リンクはインターネットなどの電子通信ネットワークを介して確立され、車両通信装置と遠隔通信装置間のウェブベースの通信を可能にする。

いくつかの実施形態では、車両通信装置および遠隔通信装置はそれぞれ、ソケットと、通信プロセッサと、前記通信プロセッサに接続されるモデムとを有する。車両通信装置のソケットは、一つ以上の車両サブシステムと関連する複数のピンを有する車両コネクタと係合するように構成され、前記遠隔通信装置のソケットは、車両走査ツールや類似のコンピュータワークステーションと係合するように構成される。再度、車両通信装置と遠隔通信装置は、各装置のモデム間で確立される双方向通信リンク上で通信することができる。いくつかの実施形態では、モデムは、イーサネット、ユニバーサルシリアルバスなどの双方向通信リンクへの有線接続を利用する。他の実施形態では、モデムは、Ｗｉｆｉ、Ｂｌｕｅｔｏｏｔｈ、またはセルラデータ通信ネットワークなどの双方向通信リンクへの無線接続を利用する。

いくつかの実施形態では、本発明は、車両の一つ以上のサブシステムを遠隔でプログラミングする方法に関し、該方法は、車両通信装置と遠隔通信装置間の双方向通信リンクを確立するステップであって、車両通信装置が一つ以上の車両サブシステムと通信し、遠隔通信装置がコンピュータシステムまたは走査ツールと通信するステップと、双方向通信リンク上で車両通信装置から一つ以上の車両サブシステムからの一つ以上の出力ピン信号を要求するステップと、双方向通信リンク上の遠隔通信装置で出力ピン信号に対応するネットワーク対応車両パケットを受信するステップと、遠隔通信装置で車両パケットを一つ以上の出力ピン信号に変換するステップと、一つ以上の出力ピン信号をコンピュータシステムに送信するステップと、を備える。

いくつかの実施形態では、遠隔車両プログラミング方法は、コンピュータシステムでプログラミング指示を生成するステップと、コンピュータシステムから遠隔通信装置にプログラミング指示を送信するステップと、遠隔通信装置上でプログラミング指示をネットワーク対応プログラミングパケットに変換するステップと、双方向通信リンクでプログラミングパケットを車両通信装置に送信するステップとを含む。

車両ＯＢＤコネクタの一実施形態の図である。 本発明の通信インタフェース装置の一実施形態の概略図である。 各種構成要素を示す本発明のシステムの実施形態を示す。 各種構成要素を示す本発明のシステムの実施形態を示す。 各種構成要素を示す本発明のシステムの実施形態を示す。 各種構成要素を示す本発明のシステムの実施形態を示す。 各種構成要素を示す本発明のシステムの実施形態を示す。 各種構成要素を示す本発明のシステムの実施形態を示す。

本発明は、車両のＯＢＤコネクタにより車両を遠隔でプログラミングするシステムおよび方法のいくつかの非制限的実施形態に関する。図１に示すような１６−ピンＯＢＤ車両コネクタ１は通常、現在の大部分の車両においてはダッシュボードの下に配置され、車両オペレータまたは技術者からアクセス可能である。本発明のいくつかの実施形態では、車両コネクタ１は車両に配置される各種電子制御ユニットまたは「モジュール」とインタフェースをとる。このようなユニットおよびモジュールは、エアバッグ制御モジュール、アラーム制御モジュール、アンテナ制御モジュール、自動制御モジュール、車体制御モジュール、車室ヒータ制御モジュール、中央制御モジュール、充電制御モジュール、通信制御モジュール、ドア制御モジュール、電子ブレーキ制御モジュール、ＨＶＡＣ制御モジュール、電子スロットル制御モジュール、エンジン制御モジュール、ヘッドランプ制御モジュール、計器制御モジュール、ナビゲーション制御モジュール、駐車支援制御モジュール、パワーミラー制御モジュール、パワーシート制御モジュール、ラジエータファン制御モジュール、シートヒータ制御モジュール、ステアリングコラム制御モジュール、ステアリング制御モジュール、ステアリング搭載制御モジュール、サンルーフ制御モジュール、トランスミッション制御モジュール、トランスファケース制御モジュール、一般電子機器制御モジュール、ムーンルーフ制御モジュール、サスペンション制御モジュール、タイヤ圧制御モジュール、牽引制御モジュール、トレーラ灯制御モジュールを含むことができるが、それらに限定されない。本開示の目的上、これらのユニットおよびモジュールは以下一括して車両「サブシステム」と称する。

いくつかの実施形態では、車両コネクタ１０１は図１に示すように、各８個のピン１０２を２列有する。ピン１０２は、上述したような各種車両サブシステムと通信する。したがって、所与の車両では、１６個のピン１０２はそれぞれ、特定のサブシステムまたは他の機能に対応する車両信号を出力することができる。信号は１６個のピン１０２に同時に存在する必要はなく、ピン１０２の信号構成は所望の通信プロトコル、すなわち、信号フォーマットに応じてピン毎に変動する可能性があると理解される。単に例示のために、上記通信プロトコルは、上述のＳＡＥ Ｊ１８５０ＰＷＭ、ＳＡＥ ＶＰＭ、ＩＳＯ ９１４１−２、ＩＳＯ １４２３０、およびＩＳＯ １５７６５プロトコルを含むことができる。

各ピン１０２に存在する車両信号はアナログでもデジタルでもよく、このようなフォーマットはすべてのピン１０２で同一でなくてもよいと理解される。さらに、車両コネクタ１０１を「雌」コネクタとして構成する実施形態もあれば、「雄」コネクタとして構成する実施形態もあると理解される。

上述したように、走査ツールまたはその他の算出装置がデータケーブルによって車両コネクタ１０１に接続され、走査ツールが各種車両サブシステムに対応する車両データを受信するのは普通のことである。その目的で、走査ツールまたは算出装置は通常、実行されるデータ解析およびプログラミングのために、車両に近接して配置しなければならない。しかしながら、本発明は、遠隔データ解析および操作のためにコンピュータネットワークを介してピン１０２に存在する車両信号を送信し、対象車両のサブシステムの遠隔プログラミングを可能にするように構成される双方向通信システムを企図している。車両と遠隔位置間の双方向通信リンクにより、遠隔位置の技術者は、あたかも車両に近接して立っているかのように走査ツールまたはコンピューティングシステムを介して車両をプログラミングすることができる。

図２に示すように、本発明の１側面は、以後「ＣＩＤ」と称する２つの通信装置を備える通信システムおよびその関連方法を企図する。上述したように、ＣＩＤの目的は、技術者が対象車両を遠隔でプログラミングできるように、第１の位置の対象車両の車両コネクタ１０１と第２の遠隔位置の走査ツールまたはコンピュータとの間で双方向通信リンクを生成することである。したがって、車両ＣＩＤ２０１および遠隔ＣＩＤ２０２の実施形態が概略的に示されている。いくつかの実施形態では、車両ＣＩＤ２０１は、ソケット２１１、通信プロセッサ２４１、およびモデム２６１を有する。同様に、遠隔ＣＩＤ２０２は、ソケット２１２、通信プロセッサ２２２、およびモデム２６２を有する。

車両ＣＩＤ２０１は、ソケット２１１を介して車両コネクタ１０１と係合される。いくつかの実施形態では、ソケット２１１は、ピン１０２に存在する車両信号がＣＩＤ２０１によって受信され、通信プロセッサ２４１によって処理されるように、車両コネクタ１０１のピン１０２と係合するように構成される。その目的で、通信プロセッサ２４１は、出力ピン信号２２１を、コンピュータネットワーク上でモデム２６１によって遠隔ＣＩＤ２０２に送信可能なネットワーク対応パケットである車両パケット２５１に変換することを可能にする動作論理を含む。

遠隔ＣＩＤ２０２が走査ツールまたはコンピューティングシステムと通信することによって、ソケット２１２が上述の車両コネクタ１０１と同じピン構造を有する走査ツールコネクタ１０３と係合する。したがって、遠隔ＣＩＤ２０２は、モデム２６２を介して車両パケット２５１（車両ＣＩＤ２０１のモデム２６１から）を要求および受信することができ、通信プロセッサ２２２が該パケットを処理してピン信号に再変換し、そのピン信号は解析およびプログラミングのために（走査ツールコネクタ１０３上で）走査ツールまたはコンピュータシステムに通信することができる。この意味で、車両パケット２５１は遠隔ＣＩＤ２０２に「読み取り」データを提供し、該データを使用して、所与の車両サブシステムの現状を判定するだけでなく、エラー、異常、またはサブシステムに関するその他の問題があるか否かも判定することができる。

したがって、技術者は、走査ツールまたはコンピュータシステムを利用して、双方向通信リンク上で車両にプログラミング指示を送信することができる。たとえば、プログラミング指示は、走査ツールコネクタ１０３でソケット２１２を介して走査ツールまたはコンピュータシステムから遠隔ＣＩＤ２０２に送信される。プログラミング指示は当初、ピン対応の信号であるため、遠隔ＣＩＤ２０２の通信プロセッサ２２２は、車両ＣＩＤ２０１に関して上述したのとほぼ同じように信号を変換し、その後、双方向通信リンク（すなわち、モデム２６２からモデム２６１へ）上でネットワーク対応プログラミングパケット２３２を車両ＣＩＤ２０１に中継する。車両ＣＩＤ２０１はプログラミングパケット２３２を受信し、該パケットを、ソケット２１１と車両コネクタ１０１との係合を通じて車両に送られる車両対応入力ピン信号２４２に再変換する。

図２に示すように、通信プロセッサ２４１および２２２は、車両対応ピン信号を要求し読み取り、それらのピン信号の通信プロトコル、すなわち、信号フォーマットを判定し、ピン信号をネットワーク対応データパケットに変換するソフトウェア論理を含む。したがって、いくつかの実施形態では、車両パケット２５１およびプログラミングパケット２３２は、入力および出力データの通信プロトコルを特定するデータを含むことができる。いくつかの実施形態では、このＩＤ情報は、走査ツールまたはコンピューティングシステムがたとえば、車両の型とモデルに応じて適切なプログラミングソフトウェアを判定するために必要である。すなわち、各車両製造業者が固有の通信プロトコル、すなわち、信号フォーマットを有する範囲において、走査ツールまたはコンピューティングシステムは、車両を適切にプログラミングするためにそのプロトコルを認識することができる。各種通信プロトコルは、本開示の先の背景技術セクションで述べたようなプロトコルを含むことができるが、それらに限定されない。

上記事項に基づき、車両ＣＩＤ２０１および遠隔ＣＩＤ２０２は情報の双方向交換を可能にすると理解される。車両データ、すなわち、車両パケット２５１は遠隔位置に送信され、そこで技術者は該パケットを読み取り、解析し、処理して、新たな車両データ、すなわち、プログラミングパケット２３２を対象車両に送り戻すことができる。いったん双方向通信リンクが確立されれば、状況および所望のプログラミングタスクに応じて車両または遠隔位置のどちらからもデータ転送を開始することができると理解される。いくつかの実施形態では、遠隔ＣＩＤ２０２は車両ＣＩＤ２０１から出力ピン信号情報を要求し、ピン信号情報は車両ＣＩＤ２０１から車両パケット２５１として遠隔ＣＩＤ２０２に送信される。

いくつかの実施形態では、モデム２６１および２６２は、標準的な電話接続（ＲＪ−１１）、カテゴリ−５イーサネット接続（ＲＪ−４５）、ユニバーサルシリアルバス（ＵＳＢ）接続、ファイアワイヤ（ＩＥＥＥ１３９４）、または当該技術において既知のその他のシリアルまたはパラレルデータ伝送接続などの有線接続によりコンピュータネットワークと通信する。いくつかの実施形態では、モデム２６１および２６２は、ＷｉＦｉ、Ｂｌｕｅｔｏｏｔｈ、近接場通信（ＮＦＣ）、またはＧＳＭ、ＵＭＴＳ、またはＣＤＭＡ、ＥＤＧＥ、３Ｇ、４Ｇ、ＬＴＥ、ＨＳＰＡ、ＨＳＤＰＡ、ＥＶ−ＤＯなどのセルラデータ通信ネットワークプロトコルなどの無線接続により電子通信ネットワークと通信する。モデムは、電子通信ネットワーク（たとえば、インターネット）にアクセスして双方向通信リンクを確立できる限り、必ずしも同じ接続規格を使用する必要はない。

特定の車両ＣＩＤ２０１および遠隔ＣＩＤ２０２は、車両ＣＩＤ２０１および遠隔ＣＩＤ２０２の論理内に埋め込まれる一意の静的インターネットプロトコル（「ＩＰ」）アドレスまたはその他のＩＤコードなどの一意の識別子を任意で有することができると理解される。一意の識別子は、車両ＣＩＤ２０１から遠隔ＣＩＤ２０２に送信される車両パケット内に，あるいは車両パケットに加えて含めることができる。いくつかの実施形態では、一意の識別子は、所与の車両ＣＩＤに関するソースおよび所有者情報を識別するのに遠隔位置を支援し、車両ＣＩＤが正しい実体、すなわち、車両ＣＩＤが割り当てられている個々の技術者または店舗によって操作されていることを検証するために使用することもできる。

いくつかの実施形態では、車両ＣＩＤ２０１の内部ソフトウェアおよび論理が、使用前に遠隔ＣＩＤ２０２との適切な双方向通信リンクを始動および維持すべく構成されるように、車両ＣＩＤ２０１をイネーブルにすることができる。たとえば、車両ＣＩＤ２０１を受け取った後、技術者または店舗は、（ＵＳＢ、Ｂｌｕｅｔｏｏｔｈ、または本明細書に記載のその他の有線または無線接続プロトコルによって）車両ＣＩＤ２０１をローカルコンピュータまたはワークステーションに一時的に接続し、適切なソフトウェアを実行して、車両ＣＩＤ２０１を店舗のインターネット接続に接続させて遠隔位置で遠隔ＣＩＤ２０２と通信するように構成する。したがって、車両ＣＩＤ２０１（ならびに遠隔ＣＩＤ２０２）は構成データを記憶することのできる内部メモリを有することができるため、追加の構成を必要とせずに、以後の使用中にインターネットに再接続し得る。しかしながら、必ずしも車両ＣＩＤ２０１はローカルコンピュータまたはワークステーションによって構成される必要はなく、装置自体のインタフェースを通じて構成されるか、あるいは店舗が車両ＣＩＤ２０１を取得する際にあらかじめ構成が形成されてもよいと理解される。

図３〜図８は、本発明の遠隔車両プログラミングシステムおよび方法の各種実施形態を示す。車両ＣＩＤ３０１、遠隔ＣＩＤ３０２、走査ツール３０３、およびワークステーション３０４が示される図３から開始すると、車両ＣＩＤ３０１は対象車両に近接し、残りの構成要素、すなわち、遠隔ＣＩＤ３０２、走査ツール３０３、およびワークステーション３０４は車両位置から離れた位置にあると理解される。

上記によると、車両ＣＩＤ３０１は、対象車両（図示せず）の車両コネクタ１０１（図示せず）のピン１０２と係合する。双方向通信リンクは、インターネットなどの電子通信ネットワーク上で車両ＣＩＤ３０１と遠隔ＣＩＤ３０２との間で確立される。２つのＣＩＤ３０１および３０２間の通信は各自のモデム（図示せず）、この場合は有線接続を介して行われると理解される。

車両ＣＩＤ３０１は、ピン１０２上に存在する車両信号を受信し、車両信号をネットワーク対応データパケットに変換し、双方向通信リンクによりデータパケット、すなわち、車両パケットを遠隔ＣＩＤ３０２に中継することができる。遠隔ＣＩＤ３０２は、車両パケットを要求および受信して、それを車両対応信号に変換するように構成される。その後、車両信号は、あたかも走査ツール３０３が車両ＣＩＤ３０１に直接接続されるかのように、ＯＢＤ接続（たとえば、上述の走査ツール接続１０３）を通じて遠隔ＣＩＤ３０２と通信する走査ツール３０３によって処理および解析することができる。

したがって、走査ツール３０３は、所与の車両から出力される車両信号の特定の通信プロトコルを処理するように構成される特別なソフトウェアを含むコンピューティングシステムである。走査ツールは、車両信号とは関係なく、あるいは車両信号に応じて、新たなプログラミング情報を生成し、該情報を車両対応プログラミング信号としてＣＩＤシステムに出力することもできる。

通信リンクは双方向であるため、車両対応プログラミング信号は走査ツール３０３および／またはワークステーション３０４から遠隔ＣＩＤ３０２に送信することができる。次いで、遠隔ＣＩＤ３０２は、プログラミング信号をネットワーク対応データパケット、すなわち、プログラミングパケットに変換し、それを車両ＣＩＤ３０１に中継することができる。その後、車両ＣＩＤ３０１は、プログラミングパケットを車両対応プログラミング信号（ピン対応）に再変換し、車両コネクタ１０１のピン１０２上で特定の車両サブシステムに送信することができる。したがって、車両パケットおよびプログラミングパケットは、両方向で車両と遠隔位置間でやりとりすることができ、車両の遠隔解析およびプログラミングを可能にする。

車両の型およびモデルはそれぞれ異なるＯＤＢ通信プロトコル、すなわち、信号フォーマットを備えることがあるため、多数の異なる走査ツール３０３を利用可能にして互換性を確保することが望ましいと理解される。したがって、上述したように、ＣＩＤ３０１および３０２は、走査ツール３０３が車両パケットを適切に特定し、読み取り、解析し、操作することができるように、双方向通信リンク上の通信プロトコル（すなわち、信号フォーマット）データを含むように構成することができる。任意で、走査ツール３０３はワークステーション３０４（ネットワークスイッチ３０６を介して）と通信し、走査ツール３０３を遠隔操作させる。この構成では、複数の走査ツール３０３およびそれに対応する遠隔ＣＩＤ３０２は遠隔位置の分離された領域内に配置され、ワークステーション３０４はコールセンターまたはデスクや小部屋の集合などの、遠隔位置のその他別の場所に存在する。

図３は、複数の車両ＣＩＤ３０１、遠隔ＣＩＤ３０２、走査ツール３０３、およびワークステーション３０４を示す。したがって、本発明は、２台以上の車両が所与の時間にサービスを提供され、プログラミングされることを企図するため、同時に動作する複数のシステムを有することが望ましい。したがって、ネットワークスイッチ３０６を遠隔位置に導入して、複数の遠隔ＣＩＤ３０２に単独のネットワーク接続（すなわち、インターネット接続）でデータを受信させることができる。いくつかの実施形態では、各ＣＩＤは、走査ツールが車両データを適切に特定できるように、通信プロトコル、すなわち、信号フォーマットに関する情報を特定および送信するように構成される。さらに、複数のワークステーション３０４がシステムに接続され、ネットワークスイッチ３０６を介して走査ツール３０３と通信するように配置される。任意で、ファイアウォール３０５をネットワークスイッチ３０６の前に配置して、既知のネットワークセキュリティおよび暗号化プロトコルに従って、システムを保護することができる。

図４を参照すると、車両ＣＩＤ４０１、遠隔ＣＩＤ４０２、ワークステーション４０４、ファイアウォール４０５、およびネットワークスイッチ４０６が示されている。本実施形態では、ワークステーション４０４上で実行され、ネットワークスイッチ４０６を介してシステムとインタフェースをとるエミュレーションソフトウェアが優先されて、走査ツールが省略される。エミュレーションソフトウェアは、遠隔ＣＩＤ４０２から受信した車両信号を読み取り、処理して、通信プロトコルに基づき、適切な型およびモデルの走査ツールソフトウェアを呼び出してデータ解析と車両プログラミングを可能にするように設計される。本実施形態によると、ワークステーション４０４は、遠隔ＣＩＤ４０２とインタフェースをとるために適切なＯＢＤコネクタを有することができる。

図５は、車両ＣＩＤ５０１、遠隔ＣＩＤ５０２、走査ツール５０３、ワークステーション５０４、ファイアウォール５０５、ネットワークスイッチ５０６、およびシン・クライアント（thin client）５０７を示す。本実施形態では、走査ツール５０３は、すべてネットワークスイッチ５０６を介して、交互にワークステーション５０４に接続されるシン・クライアント５０７に接続されている。したがって、データ解析およびプログラミングは、シン・クライアント５０７に、次いで走査ツール５０３に中継される指示により、ワークステーション５０４から実行することができる。この構造では、シン・クライアント５０７はワークステーション５０４でのコンピューティングリソースの要件を低減する効果を有するだけでなく、データセキュリティおよび暗号化の追加手段を提供する。図６は図５に示されるのと同様のシステム構成を示すが、車両ＣＩＤ６０１、遠隔ＣＩＤ６０２、およびネットワークスイッチ６０６に関して無線通信を使用している。

図７を参照すると、車両ＣＩＤ７０１、遠隔ＣＩＤ７０２、ワークステーション７０４、ファイアウォール７０５、ネットワークスイッチ７０６、およびサーバ７１０が示されている。本実施形態では、サーバ７１０上で実行されるエミュレーションソフトウェアを優先して走査ツールが省略され、サーバ７１０はワークステーション７０４用の「クラウド」として構成され、その構成要素はネットワークスイッチ７０６を介して相互接続される。エミュレーションソフトウェアは、遠隔ＣＩＤ７０２から受信した車両信号を読み取り、処理し、通信プロトコルに基づき、適切な型およびモデルの走査ツールソフトウェアを呼び出してデータ解析および車両プログラミングを可能にするように設計される。本実施形態によると、サーバ７１０は、遠隔ＣＩＤ７０２とインタフェースをとるために適切なＯＢＤコネクタを有することができる。ワークステーション７０４はサーバ７１０とインタフェースをとり、車両パケットを検索して、プログラミングおよび解析を実行し、プログラミングパケットを車両ＣＩＤ７０１に中継する。図８は、無線通信を利用する類似の構造を示す。

本開示全体を通じて言及されるように、本発明のシステムおよび方法は、遠隔位置から複数の車両サブシステムを遠隔プログラミングすることができる。したがって、「プログラミング」という用語は、車両ＣＩＤ−遠隔ＣＩＤ双方向通信リンク上で走査ツールまたはコンピューティングシステムから車両に中継される特別に設計されたプログラミングパケットにより、車両サブシステムで実行可能な様々な動作を企図する。このような動作は読取り、再プログラミング、プログラム更新、較正、リンキング、マリッジ、シリアルコーディング、およびセキュリティコーディングを含むことができるが、それらに限定されない。

「再プログラミング」は、車両サブシステム内の不良なまたは不在のプログラミングを、完全な最新のプログラミング情報で置換し、修正し，リセットし，あるいはその他の形で変更することを可能にするプログラミングパケットの中継を含むことができる。

「プログラム更新」は、サブシステム内の既存だが旧式のプログラミングを最新の相手先商標製造会社（ＯＥＭ）プログラミングおよび構成と置き換えることを可能にするプログラミングパケットの中継を含むことができる。もしくは、これらのパケットはカスタムプログラミング更新を含むことができる。このようなプログラミング更新は、エンジン馬力出力またはシフトインターバルを増大させるため、たとえば、エンジン制御モジュール、トランスミッション制御モジュール、および関連モジュールの性能向上を企図することができる。これらのプログラム更新は特に、レーシングカーや「ホットロッド」などの高性能車両を「調整」するのに有益である。

「較正」は、各種センサからの出力信号を車両サブシステムで調整して、他の車両サブシステムからの入力信号を正確に読み取ることを可能にするプログラミングパケットの中継を含むことができる。また、「較正」は、車両サブシステム内の「設定点」またはパラメータのリセットを企図する。

「リンキング」または「ペアリング」は、２つまたはそれ以上の車両サブシステム間の双方向通信を確立することを可能にするプログラミングパケットの中継を含むことができる。これは、その他のモジュールまたはサブシステムが受け入れ、通信するように、車両内のモジュールまたはサブシステムを置き換える際に必須のステップである。

「マリッジ」は、車両レベルでの統合を含み、かつ単なるサブシステム対サブシステム通信ではない点を除き、リンキングと類似している。たとえば、プログラミングパケットは、車両と通信し、車両識別番号Ｖ１Ｎを特定して、サブシステムがその車両に属することを認証するようにサブシステムに命じることができる。「シリアルコーディング」はリンキングまたはマリッジの別の用語である。

最後に、「セキュリティコーディング」は、特定のセキュリティ関連サブシステムを車両、たとえば、ドア制御モジュールまたはセキュリティモジュールとリンクまたは結合させることを可能にするプログラミングパケットの中継を含むことができる。

これらのプログラミング活動または動作を実行するため、遠隔ＣＩＤが車両ＣＩＤにより、車両を「読み取り」、各種車両サブシステムの現状を判定することが望まれる場合が多いと理解される。したがって、いくつかの実施形態では、車両ＣＩＤは、車両パケットを遠隔ＣＩＤに送信して、特定のサブシステム内に．エラーまたは欠落要素があるか否かを判定するため、走査ツール、ワークステーション、またはその他のコンピューティングシステムによって読み出し，解析する。その時点で、技術者は、所望の結果に応じて、サブシステムの状態を訂正し、置き換え、リセットし、または操作するため、本明細書に開示される各種動作を実行するように設計された特別なプログラミングパケットを走査ツールまたはコンピューティングシステム上で生成することができる。

さらに、本明細書に開示されるプログラミング動作は、「キーオン」または「キーオフ」動作モードのいずれかで実行されるように構成される。「キーオン」モードでは、本明細書のシステムおよび方法は、車両のエンジンが動作しているときにアクティブになる特定のサブシステムを読み取り、解析し、操作し、プログラムするために利用することができる。特定のサブシステムが「キーオフ」動作モードのときと比較して異なるデータを出力しているため、エンジンが動作しているときにデータ解析およびプログラミングを実行することが望ましいであろう。一方、「キーオン」動作モードは、安全のために、特定のサブシステムを「ロックアウト」して、データ解析およびプログラミングを妨害することができる。したがって、「キーオフ」動作モードが、それらの特定のサブシステムをプログラムするために必要であるかもしれない。

本開示全体を通じて言及されるように、本発明は、様々な有効な方法を本明細書に開示の遠隔車両プログラミングシステムの各種構成要素に組み込むことを企図している。実際の環境では、本発明による遠隔車両プログラミングは、いくつかの方法で行うことができる。一例が「予約」モデルに関する。本実施例では、ある位置の店舗または修理工場が、遠隔位置の「コールセンター」と車両プログラミングの予約を予定する。適切な時間に、店舗は車両ＣＩＤを対象車両のＯＢＤコネクタに接続して、車両ＣＩＤとインターネット間の接続を開始させる。ほぼ同時に、コールセンターは、遠隔ＣＩＤとインターネット間の接続を開始させる。次に、コールセンターは、車両ＣＩＤがインターネットと適切に接続したことを確認するため、店舗の技術者またはその他の個人に電話するか、あるいは別の形の直接通信を開始させる。いったん接続が確認されれば、コールセンターは遠隔ＣＩＤと車両ＣＩＤの間の双方向通信リンクを確立し、上述の一意の識別子情報を用いて車両ＣＩＤを特定する。

その時点で、車両ＣＩＤと遠隔ＣＩＤとの間でデータをやりとりすることができる。いくつかの実施形態では、いったん双方向通信リンクが確立されれば、コールセンターはワークステーション、走査装置、サーバ、またはそれらの組み合わせを用いて、遠隔位置から車両へプログラミングパケットの中継を開始する。他の実施形態では、コールセンターはまず車両から車両データを受信し、その後、データを解析して適切なプログラミングを実行する。しかしながら、双方向通信リンクは動的であるので、これらの例は非限定的であると解釈すべきであり、したがって、所望のシーケンスのデータ通信およびプログラミングが可能である。

他の実施形態では、プログラミングは、「予約」ベースではなく「オンデマンド」ベースで達成することができる。したがって、ある位置の店舗は、車両ＣＩＤを対象車両のＯＢＤコネクタと接続して，その後、車両ＣＩＤとインターネット間の接続を開始させる。次いで、店舗は電話、コンピュータ、または車両ＣＩＤ自体によって遠隔位置のコールセンターに「ジョブリクエスト」を送信する。コールセンターはジョブリクエストを受信し、その後、適切な遠隔ＣＩＤと車両ＣＩＤとの間の双方向通信リンクを開始させる。その時点で、データ解析、操作、およびサブシステムのプログラミングを開始することができる。

上述したように、いくつかの実施形態では、コールセンターは、広範なＯＢＤ通信プロトコル、すなわち、信号フォーマットのためのプログラミング機能を提供するため、多数の遠隔ＣＩＤ−走査ツール／ワークステーションの組み合わせを採用することができる。したがって、コールセンターは、遠隔ＣＩＤおよび走査ツールのアレイを適所に配置して、最適な互換性および柔軟性を提供することができる。双方向通信リンクが最初に確立されると、遠隔ＣＩＤは、車両ＣＩＤから送信される車両パケットから通信プロトコル情報を要求し，受信する。したがって、コールセンターは、プログラミングを開始させるのに適切な走査ツール／ワークステーション／エミュレーションサーバを構成するため、通信プロトコル情報を読み取るように構成される。

本明細書に記載の本発明の実施形態の多くは乗用車に関するが、「車両」という用語は限定的であると解釈すべきではない。したがって、本明細書のシステムおよび方法は、船舶、航空機、重機、商業乗物、固定機器、および産業機器を含むがそれらに限定されない多数の用途を有する。ただし、上記の機械は各種電子制御モジュールおよびサブシステムによって制御され、走査ツールまたはコンピューティングシステムによってプログラムされるように構成される。

さらに、上述の本発明で実装される走査ツール、サーバ、およびワークステーションは、コンピュータサーバ、パーソナルコンピュータ、ラップトップコンピュータ、ネットブックコンピュータ、タブレット、スマートフォンなどの携帯電話を含むが、それらに限定されない、各種コンピューティングシステムを備えることができると理解される。標準的なコンピューティングシステムの以下の説明は単に例示のためだけに含まれ、本発明の限定とみなすべきではない。この説明は特定の種類のコンピューティングシステムについて説明する際に一般的に使用される用語を指すことができるが、記載される概念は、記載されるものと異なるアーキテクチャを有するシステムを含む他のコンピューティングシステムにも同様に適用される。

上記の走査ツール（「携帯型」コンピューティングシステム）、サーバ、およびワークステーションなどのコンピューティングシステムは、従来のマイクロプロセッサを有する中央処理装置（ＣＰＵ）、情報の一時的保管のためのランダムアクセスメモリ（ＲＡＭ）、および「読出し専用」情報の永久的保管のための読出し専用メモリ（ＲＯＭ）を含むことができる。メモリコントローラは、システムＲＡＭ制御のために設けられる。バスコントローラは、データバス制御のために設けられ、割込みコントローラは、その他のシステム構成要素から各種割込み信号を受信し処理するために設けられる。データ記憶装置は、ディスケットドライブ、ＤＶＤドライブ、ＣＤ−ＲＯＭドライブ、ＺＩＰ（登録商標）ドライブ、フラッシュドライブ、光磁気（「ＭＯ」）ドライブなどの既知の不揮発性の脱着可能な媒体記憶ドライブ、あるいはハードドライブなどの脱着不能なシステムによって設けることができる。データおよびソフトウェアは、フロッピーディスケット、ＣＤ−ＲＯＭ、ＤＶＤ、ＺＩＰ（登録商標）ディスク、ＭＯディスク、フラッシュドライブなどの．脱着可能媒体を介してコンピューティングシステムとやりとりすることができる。脱着可能媒体は互換可能かつ脱着可能な媒体記憶ドライブに挿入可能であり、その後、コントローラを利用してデータバスとインタフェースをとる。脱着不能記憶システムは、ハードドライブコントローラを利用してデータバスとインタフェースをとる固定ディスクドライブの一部である。コンピュータへのユーザ入力は、多数の装置によって提供することができる。たとえば、キーパッド、キーボード、マウス、およびトラックボールなどで、入力コントローラによってデータバスに接続することができる。直接メモリアクセス（ＤＭＡ）コントローラは、システムＲＡＭへの直接メモリアクセスを実行するために設けられる。視覚表示は、コンピューティングシステムに装着されるディスプレイ装置を制御するコンピューティングシステムのグラフィックサブシステムによって生成することができる。ディスプレイ装置は個々にアドレス指定可能な画素（「ピクセル」）を有する、従来の陰極線管（「ＣＲＴ」）、液晶ディスプレイ（「ＬＣＤ」）、発光ダイオード（「ＬＥＤ」）、またはプラズマモニタとすることができる。ピクセルは二次元Ｘ−Ｙグリッドに配列され、１画像または一連の画像（またはフレーム）を集めて動画を生成するために、グラフィックサブシステムによって定められるように選択的に発光させられる。

各種コンピューティングシステムをネットワークバスを介して記載のネットワークに接続させるネットワークインタフェースアダプタも含めることができる。ネットワークはローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、電子通信ネットワーク、すなわち、インターネットなどであってもよく、複数のネットワーク装置を相互接続する汎用通信プロトコルを利用することができる。単に例示のために、コンピューティングシステムは、Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃ ＯＳＸ、Ａｐｐｌｅ ｉＯＳ、Ｌｉｎｕｘ、Ｕｎｉｘ、Ａｎｄｒｏｉｄ ＯＳ、ＰａｌｍＯＳ、Ｗｉｎｄｏｗｓ Ｍｏｂｉｌｅ ＯＳなどのオペレーティングシステム（「ＯＳ」）ソフトウェアによって制御および調整される。他の機能としては、ＯＳは、システムリソースの配分を制御し、プロセススケジューリング、メモリ管理、ネットワーキング、およびＩ／Ｏサービスなどのタスクを実行する。

上記の説明では、本発明を特定の例示の実施形態を参照して説明した。本発明を理解する人であれば、より広い発明の技術思想と範囲を逸脱せずに本発明の原理を利用する変更またはその他の実施形態または変形を思いつくことができるのは、当業者にとって自明である。したがって、明細書と図面は、限定的ではなく例示的であるとみなすべきである。したがって、本発明は、添付の請求項を考慮して必須である場合を除き、限定的であることを目的としていない。

Claims (11)

1. 対象車両のサブシステムを遠隔でプログラミングするシステムにおいて、
   対象車両に近接して配置された第１の通信装置であって、
   対象車両用の車両コンピュータシステムとインタフェースし、ＯＢＤ通信プロトコル標準規格を用いて前記車両コンピュータシステムとの双方向通信を提供する第１のインタフェースと、
   通信ネットワークとインタフェースする第２のインタフェースと、
   前記第１及び第２のインタフェースを介した通信を制御する第１の通信プロセッサとを含む前記第１の通信装置と、
   対象車両から遠隔位置に配置された第２の通信装置であって、
   前記通信ネットワークとインタフェースする第３のインタフェースであって、前記通信ネットワークは、前記第１の通信装置と前記第２の通信装置との間の双方向通信リンクを提供する、前記第３のインタフェースと、
   前記第２の通信装置に近接して配置されたコンピューティングシステムとインタフェースする第４のインタフェースと、
   前記第３及び第４のインタフェースを介した通信を制御する第２の通信プロセッサとを含む前記第２の通信装置と、
   を備え、
   前記第１の通信装置および前記第２の通信装置は、前記コンピューティングシステムと前記車両コンピュータシステムとの間の通信を提供して、前記コンピューティングシステムが、対象車両に近接して配置されているかのように対象車両の車両サブシステムを走査し、かつプログラムすることを可能にし、
   前記第２の通信プロセッサが、
   前記双方向通信リンクにより、前記車両コンピュータシステムから、前記車両サブシステムからの一つ以上の出力ピン信号を要求し、
   前記双方向通信リンクにより、前記出力ピン信号に対応し、かつ前記出力ピン信号の通信プロトコルを特定するデータを含むネットワーク対応車両パケットを受信し、
   前記車両パケットを前記一つ以上の出力ピン信号に変換し、
   前記一つ以上の出力ピン信号を前記コンピューティングシステムに送信することができる、システム。
2. 前記コンピューティングシステムが車両走査ツールを含む、請求項１に記載のシステム。
3. 前記第２の通信プロセッサがさらに、
   前記コンピューティングシステムからプログラミング指示を受信し、
   前記プログラミング指示をネットワーク対応プログラミングパケットに変換し、
   前記双方向通信リンクにより前記プログラミングパケットを前記第１の通信装置に送信することができる、請求項１に記載のシステム。
4. 前記双方向通信リンクがインターネットを備える、請求項１に記載のシステム。
5. 前記双方向通信リンクがセルラデータ通信ネットワークを備える、請求項１に記載のシステム。
6. 前記双方向通信リンクが衛星通信ネットワークを備える、請求項１に記載のシステム。
7. 前記車両コンピュータシステムは、対象車両の複数の車両サブシステムとインタフェースする、請求項１に記載のシステム。
8. 前記第１の通信装置と前記第２の通信装置との間の通信は、能動的であり、かつ持続的なものである、請求項１に記載のシステム。
9. 前記第１の通信装置と前記第２の通信装置との間の通信は、全二重通信である、請求項１に記載のシステム。
10. 前記第１のインタフェースは、前記車両コンピュータシステムの第１のコネクタと係合するように適合された第１のソケットを含み、前記第１のコネクタは、前記車両サブシステムと関連する第１の複数のピンを含む、請求項１に記載のシステム。
11. 前記第２のインタフェースは、前記第２の通信装置に近接して配置された前記コンピューティングシステムの第２のコネクタと係合するように適合された第２のソケットを含み、前記第２のコネクタは、第２の複数のピンを含む、請求項１に記載のシステム。