(57)【要約】車両に関連する情報を伝送する方法および装置、車両に関連する情報を送受信する方法および装置を提供する。車両に関連したリモートコントロールを実現するために情報が移動無線通信網を介して伝送される。ここで通信は移動無線通信網の状況に適した標準化プロトコル、有利にはＷＡＰプロトコルに基づいて行われる。
2005529424.tif 000002
【特許請求の範囲】
【請求項１】
車両側にクライアント、ネットワーク側にサーバが設けられており、サーバとクライアントとのあいだで移動無線通信網を介して通信が行われる
車両に関連する情報を伝送する方法において、
車両に関連したリモートコントロールを実現するために情報を利用し、
移動無線通信網の状況に適合化された標準化プロトコル、有利にはＷＡＰプロトコルに基づいて通信を行う
ことを特徴とする車両に関連する情報を伝送する方法。
【請求項２】
移動無線通信網を介してサーバと通信するクライアントが車両側に設けられている
車両に関連する情報を送受信する方法において、
車両に関連したリモートコントロールを実現するために情報を利用し、
問い合わせの送信により、情報、例えば命令を呼び出してこれを受信し、
当該の情報に依存してデータを求め、このデータをサーバへ送信する
ことを特徴とする車両に関連する情報を送受信する方法。
【請求項３】
ネットワーク側にサーバが設けられており、移動無線通信網を介して車両側のクライアントと通信が行われる
車両に関連する情報を送受信する方法において、
車両に関連したリモートコントロールを実現するために情報を利用し、
受信した問い合わせに基づいて情報を選択して送信し、
さらにデータを受信して処理し、その結果を返送する
ことを特徴とする車両に関連する情報を送受信する方法。
【請求項４】
前記問い合わせはＵＲＬアドレスを使用したものである、請求項１から３までのいずれか１項記載の方法。
【請求項５】
前記情報はＷＭＬページとして送信されるＷＡＰページであり、スクリプトへのリンクおよび／またはダイナミックに作成された別のデータを含む、請求項１から４までのいずれか１項記載の方法。
【請求項６】
前記情報はＷＭＬスクリプトとして送信されるスクリプトであり、所定のアクションを実行するために車両側のクライアントで用いられる、請求項１から５までのいずれか１項記載の方法。
【請求項７】
遠隔診断のために前記スクリプトは車両ごとの診断プロトコルまたは車両特有の他の情報を含む、請求項１から６までのいずれか１項記載の方法。
【請求項８】
モバイルクライアント内にインプリメントされた少なくとも１つの自立的な外部アプリケーションとの通信を移動無線通信ユニットとアプリケーションとのあいだの標準化された機能インタフェース、すなわちＥＦＩインタフェースを介して行う、請求項１から７までのいずれか１項記載の方法。
【請求項９】
車両側のクライアントと移動無線通信網を介してこれと通信するサーバとを有する
車両に関連する情報を伝送する装置において、
車両に関連したリモートコントロールを実現するために情報が用いられ、
クライアントおよびサーバは移動無線通信網の状況に適合化された標準化プロトコル、有利にはＷＡＰプロトコルに基づいて通信を行う手段を有する
ことを特徴とする車両に関連する情報を伝送する装置。
【請求項１０】
移動無線通信網を介してサーバと通信する車両側のクライアントを有する
車両に関連する情報を送受信する装置において、
車両に関連したリモートコントロールを実現するために情報が用いられ、
クライアントは、前記情報、例えば問い合わせを送信することにより命令を呼び出し受信する手段と、得られた情報に依存してデータを求めて送信する手段とを有する
ことを特徴とする車両に関連する情報を送受信する装置。
【請求項１１】
クライアント内に少なくとも１つの自立的な外部アプリケーションがインプリメントされており、移動無線通信ユニットとアプリケーションとのあいだで通信を行うための標準化された機能インタフェース、すなわちＥＦＩインタフェースが設けられている、請求項１０記載の装置。
【請求項１２】
移動無線通信網を介して車両側のクライアントと通信するネットワーク側のサーバを有する
車両に関連する情報を送受信する装置において、
車両に関連したリモートコントロールを実現するために情報が用いられ、
サーバは、受信した問い合わせに基づいて情報を選択して返送する手段と、データを受信して処理し、その結果を返送する手段とを有する
ことを特徴とする車両に関連する情報を送受信する装置。
【請求項１３】
コンピュータ上で動作するとき、請求項１から８までのいずれか１項記載の車両に関連する情報を伝送する方法または車両に関連する情報を送受信する方法の全てのステップが実行される
ことを特徴とするプログラムコード手段を備えたコンピュータプログラム。
【請求項１４】
コンピュータで読み出し可能なデータ担体に記憶されており、
コンピュータ上で動作するとき、請求項１から８までのいずれか１項記載の車両に関連する情報を送受信する伝送方法の全てのステップが実行される
ことを特徴とするプログラムコード手段を備えたコンピュータプログラム製品。
【発明の詳細な説明】
【技術分野】
【０００１】
従来の技術
本発明は車両に関連する情報を伝送する方法および装置、また、車両に関連する情報を送受信するための方法および装置に関する。本発明は特に特に車両のコンポーネント／機能の遠隔診断、遠隔制御および／または遠隔操作のための方法および装置に関する。
【０００２】
独国公開第１００２６７５４号公報には、車両に関連する情報を伝送する方法および装置、また車両に関連する情報を送受信するための方法および装置が記載されている。ここには通信網および／またはデータネットワークを介して車両のコンポーネントおよび／または機能の遠隔保守・遠隔診断・遠隔制御などを実現するためにデータがやり取りされることが開示されている。通信網の例としてはＧＳＭ規格またはＵＭＴＳ規格に準拠した移動無線通信網が挙げられており、データネットワークの例としてはインタネットが挙げられている。ただしここでは、情報交換のフレキシビリティおよび／または信頼性および／またはセキュリティや車両内の端末のコスト低減に関する具体的な構成は示唆されていない。
【０００３】
本発明の利点
移動端末機とインタネット内の定置のコンピュータとが標準化された通信路（例えばＷＡＰプロトコル）を介して通信することにより、相応のアクセス権を有する車両内の既存のテレマティクス端末機を利用して、車両に関連するテレマティクスアプリケーションを実行することができる。これは例えば問い合わせや、車両コンポーネントの遠隔制御および／または遠隔診断の実行などである。しかも本発明の端末機は全く新しいコンセプトに基づいているにもかかわらず、大きなコストは要さない。
【０００４】
特に有利にはＷＡＰプロトコルが使用される。なぜならこのプロトコルの伝送能力およびセキュリティ機構は移動通信の分野、特に前述のような車両に関連するテレマティクスの分野（車両制御装置の遠隔診断など）での適用に特に適しているからである。
【０００５】
ＷＡＰプロトコルを使用することのさらなる利点は端末機のメモリ容量および計算能力などのリソースが節約されることである。なぜならこのプロトコルはもともと小さなリソースしか有さない端末機に対して構成されているからである。このプロトコルを使用すればデータの伝送およびその内容のヴィジアル化のための付加的な機能ユニットは必要ない。このことは周知のＷＡＰブラウザおよびこれに付随するＷＡＰ通信スタックを使用することによってのみ達成される。特に端末機内には他のサービス（例えばモバイルインタネット）のために既にＷＡＰプロトコルが設けられているので、端末機のリソースの節約の点でこのプロトコルを利用すると都合が良い。ＷＡＰプロトコルを利用することによる相乗効果は際立ったものとなる。
【０００６】
伝送されたＷＡＰ内容がＷＭＬページの形態で実現されていることにより、スタティックおよびダイナミックに形成された内容が（例えばユーザとのインタラクションのために）端末機内のＷＡＰブラウザに対してサーバによって準備される。ここでＷＭＬページはいわゆるＷＭＬスクリプトを含んでおり、端末機内での複雑なフローを記述することができる。例えば遠隔診断などの端末機のアプリケーションの一部は明示的に変換されるものでなくともよく、ＷＡＰスタックとして既に実現され汎用されているものでもよい。
【０００７】
特に有利には、ＷＡＰ規格ではインタフェース、例えばＥＦＩインタフェースが設けられており、これを用いてＷＡＰブラウザひいてはサーバとモバイル端末機の自立的な外部アプリケーションとが標準化された機能インタフェースを介して通信する。このようにしてブラウザ内に含まれないソフトウェアコンポーネント（例えば診断すべき制御装置に対する診断インタフェース）との通信を軽減する機構が提供される。
【０００８】
特に有利には、上述の車両に関連するテレマティクスアプリケーション（例えば車両制御装置の遠隔診断）に加えて、標準化プロトコルを介した別のテレマティクスサービス、例えばトラブルシューティング、非常呼出、交通情報提供なども実現される。
【０００９】
特に有利には、標準化プロトコルを使用した端末機とサーバとのあいだの通信が、質問応答通信として固定に設定された部分ステップで、標準化データフレームおよび標準化データ内容（ＷＭＬ，ＷＭＬスクリプト）に基づいて実現される。
【００１０】
特に有利には、既存のセキュリティ機構を利用し、ユーザＩＤおよび／または車両ＩＤの識別および認証を行ったのちにテレマティクスサービスをアクティブにすれば確実で信頼性の高い情報交換を行うことができる。
【００１１】
モバイルの分野に適したプロトコル規格（例えばＷＡＰプロトコル）を使用することにより、移動無線通信網を介した車両でのテレマティクスサービスにおいて特に有利な結果が得られる。
【００１２】
他の特徴および利点は以下の説明および各従属請求項に記載されている。
【００１３】
図面
本発明を以下に図示の実施例に則して詳細に説明する。図１には車両に関連するテレマティクスサービスシステムの概略図が示されている。図２にはＷＡＰプロトコルに基づく図１のシステムの実施例が示されている。図３にはテレマティクス端末機とサーバとのあいだでのインタフェースを介した伝送のステップの実施例が示されている。図４および図５には図３に示されているテレマティクス端末機とサーバとのあいだの通信のプログラムのフローチャートが示されている。
【００１４】
実施例の説明
図１には車両に関連するテレマティクスサービスシステムの概略図が示されている。ここで、車両またはその端末機とサーバとのあいだで、移動無線通信網またはデータネットワーク（例えばインタネット）を介して情報が交換される。こうしたコンフィグレーションは遠隔からの作用、遠隔診断、遠隔保守、ソフトウェアダウンロードなどの機能に関連して使用される。遠隔からの作用または問い合わせとは、主として車両の機能の遠隔制御、特にヒータのスイッチオンなどの快適性機能部の遠隔制御や、車両状態および／または駆動パラメータの問い合わせのことであると理解されたい。このときユーザはセントラルサーバを介して車両と通信したり、直接に車両と通信したりする。遠隔診断は車両からの診断データの読み出しやその解析、場合によってはさらなる処置の推奨などを含む。データの解析や推奨の作成はセントラルサーバによって行われる。このセントラルサーバは移動無線通信網や有線ネットワーク、データネットワーク（例えばインタネット）を介して車両に接続されている。またこれに関連していわゆるソフトウェアダウンロードやリモートフラッシングなどと呼ばれる機能も挙げられ、これにより新たなプログラムコードまたは新たなパラメータがソフトウェアごとにコンフィグレーション可能な車両内のシステム（例えば制御装置）に付与され、その機能または能力が向上する。この場合にも通信は移動無線通信網、有線ネットワークおよび／またはインタネットを介してセントラルコンピュータ（サーバ）またはサービスセンタから行われる。遠隔保守は主として車両状態の監視およびセントラルコンピュータからの車両内の保守データへのアクセスであり、目標状態を維持するにはいつどのような措置を行えばよいかを検査するために行われる。この例としてメンテナンスインターバルのダイナミック適合化が挙げられる。一般にこれらの機能は車両に関連したリモートコントロールとしてまとめられる。
【００１５】
前述の全ての機能またはサービスは以下に説明する車両またはその端末機とセントラルコンピュータ（特にサービスセンタ、車両メーカまたは部品メーカのサーバ）とのあいだでインタフェースを介して実現される。必要な場合には車両内のコンポーネントおよび／または機能の制御も以下に説明する端末機と該当する車両コンポーネントとのあいだのインタフェースを介して行われる。以下では“遠隔診断”のサービスを例として説明するが、本発明のインタフェースはもちろん前述した他のサービスに適用することもできる。
【００１６】
図１には遠隔診断システムの概略図が示されている。車両側には車両エレクトロニクス１、例えば制御装置系が存在しており、これは所定のインタフェース２を介して遠隔診断システムの車両側ユニット３、特にテレマティクス端末機に接続されている。車両側のアプリケーションは車両エレクトロニクス内に組み込まれた診断機構（オンボード診断機構）を利用して例えばエラーメモリ内容を検出しようとしている。遠隔診断システムの車両側ユニット３はインタフェース２、例えばＣＡＮバスまたは設定された通信プロトコルの範囲のＫ線路を介して車両のネットワークへ、つまり車両エレクトロニクス１または診断すべき制御装置へアクセスする。
【００１７】
前述の車両側ユニットは別のインタフェース４を介して遠隔診断システムのセントラルユニット５に接続されている。このセントラルユニット５は有利にはサービスセンタのサーバまたはコンピュータシステムである。有利な実施例ではこのサーバは遠隔診断に該当するタスクをできるだけ多く処理し、車両端末機のリソースができるだけ小さくて済むようにする。例えばサーバは主として車両内の診断装置のコンフィグレーションを担当し、診断の開始、診断過程中の診断装置の制御、求められたデータの評価を行う。このためサーバは特にデータメモリ６内に記憶された車両ごとに個別のデータおよび命令へアクセスする。有利な実施例ではこのサーバはインタネットサーバである。
【００１８】
サーバとクライアント（車両端末機）とのあいだの伝送区間４は、有利な実施例では、カバレージや操作性、コストなどの特性から移動無線インタフェースとなっている。遠隔診断に関連した情報交換に使用されるプロトコルは、移動無線通信網に特有の要求に適合化された標準化プロトコルである。上述の適用分野にはワイヤレスアプリケーションプロトコルＷＡＰが特に適していると判明した。ＷＡＰはモバイル端末機とインタネット内の定置のコンピュータとの通信についての世界標準のプロトコルである。これは完全な通信過程を記述する種々のプロトコルから成る。ここでＷＡＰ機能を有する端末機は専用のＷＡＰブラウザを介して標準化された伝送内容を解釈しヴィジュアル化する。伝送内容はＷＭＬページの形態で実現されている。ＷＭＬページは端末機内での複雑なフローを記述できるいわゆるＷＭＬスクリプトを含んでいる。さらに標準化された機能インタフェース（ＥＦＩインタフェース）が存在している。これはＷＡＰブラウザの構成要素であり、ブラウザ内に含まれていないソフトウェアコンポーネント（特に車両機能や診断機能）との通信に利用される。
【００１９】
ＷＡＰプロトコルでは、核となる前述の機能のほか、車両またはそのコンポーネントの遠隔診断に適用される場合には、そのセキュリティ機構も使用される。このため端末機には、データ伝送の安全性を保証したり、および／またはアクセス権を確認したりするための付加的な機能は必要ない。
【００２０】
図２にはＷＡＰ通信を行う遠隔診断システムの実施例の概略図が示されている。車両側ユニット（端末機）１０は主として診断アプリケーションの機能を含むモジュール１０ａ、ＷＡＰブラウザとしてのモジュール１０ｃ、情報を移動無線通信網へ送信しそこから受信する通信モジュール１０ｄから成っている。モジュール１０ａはバスシステム（診断バス）１２、例えばＣＡＮバスを介して車両の他の制御ユニットおよび／またはコンポーネントへ接続されている。インタフェースを介して情報、データおよび／または命令が交換される。別のインタフェース１０ｂ（ＥＦＩインタフェース）を介してモジュール１０ａはウェブブラウザ１０ｃに結合されている。通信モジュール１０ｄは送受信機１４、例えば移動無線機を用い、エアインタフェース１６を介してデータを送受信する。さらに、図２には示されていないが、フローを統括する駆動システムがいわゆるＷＡＰスタックのモジュール１０ｃ内に設けられており、これはＷＡＰプロトコルを実現する機能を含む。
【００２１】
システムの車両側ユニットはこの実施例ではテレマティクス端末機内に組み込まれている。ここには前述の移動無線トラフィックに対するＧＳＭモジュールやインタネット機能に対するＷＡＰスタックも含まれている。診断バス（たいていの場合ＣＡＮバス）への接続部も同様に構成されている。ＧＳＭ規格に代えてまたはＧＳＭ規格に加えて、ＷＡＰによる通信に対して、ＧＰＲＳまたはＵＭＴＳなどの移動無線規格も良好に適している。なぜなら迅速なコネクション形成、僅かな遅延時間および高いデータ伝送レートを低コストで実現できるからである。
【００２２】
車両端末機とセントラルコンピュータとのあいだの通信は移動無線通信網１６を介して行われる。セントラルコンピュータ１８、特にウェブサーバは、移動無線インタフェースの送受信機２０と直接に、またはゲートウェイコンピュータを介してシステムの車両側ユニットとデータをやり取りする。ゲートウェイコンピュータがネットワーク側で使用される場合、このコンピュータはＷＡＰゲートウェイを形成しており、ここにＷＡＰスタックがインプリメントされる。通常はこうしたゲートウェイ内で移動無線機１４のインタネットへのダイヤルアップが行われる。ＷＡＰモジュールのほか、ゲートウェイコンピュータは特に移動無線通信網への通信インタフェースとウェブサーバへのインタフェースとを有している。ＷＡＰゲートウェイは一方ではＷＡＰフォーマットからインタネットフォーマットＨＴＴＰへ、またはインタネットフォーマットＨＴＴＰからＷＡＰフォーマットへプロトコルを変換するタスクを有しており、他方ではウェブサーバから得られたＷＭＬページおよびＷＭＬスクリプトをプレ圧縮および圧縮し、移動無線加入者へ返送するタスクを有している。こうしたゲートウェイ機能は図２に示されているようにサーバ１８自身、つまりモジュール１８ａおよび移動無線インタフェースモジュール１８ｂが担当する。これに対して別の実施例として、インタネットコネクションを介してサーバに接続されたゲートウェイコンピュータに前述のタスクを担当させてもよい。
【００２３】
例えばサービスセンタのウェブサーバ１８は診断サーバのタスクを有する。ウェブサーバ１８にインプリメントされているソフトウェア、すなわちモジュール１８ｃは、クライアント（端末機）の問い合わせに対して、ダイナミックに作成した応答ページおよび応答スクリプトで応答する。ダイナミックな応答の作成はサーバ側のスクリプトすなわちプログラムとデータバンク２２とによって行われる。データバンクは相応の問い合わせ元に対して、ＩＤ識別や車両内の診断アプリケーションのコンフィグレーションのために必要な全てのデータを含む。ウェブサーバのタスクは一方では一般的なウェブサーバタスク、例えば問い合わせ処理、適正な受信者へのページまたはデータの配信、通信マネジメントなどであり、他方では診断フローの上位制御、ダイナミックに形成したＷＭＬページおよびＷＭＬスクリプトによるクライアントでの診断アプリケーションのコンフィグレーション、車両診断に必要なデータバンク内のデータの維持および管理、データバンクそのものの管理、車両から到来する有効データの評価、車両内の診断アプリケーションに対する画面の維持および作成などである。エラーメモリの有効データを求めること、つまり診断そのものは、車両内にインプリメントされている周知の診断法に基づいて行われる。
【００２４】
診断過程中、ＷＭＬページおよびＷＭＬスクリプトは診断フローの制御のためにサーバから端末機へ伝送され、そこで処理される。このときデータはここからＣＡＮバスへ変換される。その場合、システムの車両側ユニットにインプリメントされているマンマシンインタフェースが省略される。なぜならマンマシンインタフェースはＷＭＬページをＷＡＰブラウザとして表示することにより実現されるからである。
【００２５】
サーバ５０と車両側ユニット５２とのあいだの通信の実施例が図３に示されている。図示の実施例では通信過程はユーザ、例えば車両のドライバーによって開始されている。別の実施例として遠隔診断をサービスセンタによる通信からアクティブ化してもよい。図３の実施例では、描かれているステップの付加的な前段階として、サーバが例えばＳＭＳを介してクライアントに通信コネクションの形成を要求している。こうした過程はＷＡＰ規格においてもいわゆるＰｕｓｈとして標準化されている。
【００２６】
遠隔診断に関連する内容およびデータは、本来の診断データのほか、制御命令と車両内に組み込まれた遠隔診断機能のコンフィグレーションとを含む。これらは構成に応じて種々に構造化されている。第１の構成では、車両内の遠隔診断ユニットが自立的な診断過程を実行するための機構および機能を有する。制御装置エラーメモリがデータ検出のためにテレマティクス端末機の遠隔制御機能部によって読み出される。ここにはＣＡＮバスデータのためのトランスポートプロトコル層などの機能ユニットが設けられており、ここに論理的な診断過程に必要なプロトコル層と相応のフロー制御部とが含まれている。また相応のプロトコル層およびフロー制御部に必要なデータが診断過程の開始時に診断サーバからダウンロードされ、プロトコルマクロおよび通信パラメータを用いてこれらの層がコンフィグレーションされる。このように、診断機能を遠隔制御するための本来の制御命令のほか、場合によってはパラメータや診断マクロも伝送しなければならない。パラメータ化に必要なデータは基本的には持続的にテレマティクス端末機内に維持されているが、これをサーバからクライアントへ伝送するとオーバフローとなってしまう。
【００２７】
第２の構成では命令の伝送は診断プロトコルのレベルで行われる。この場合、車両内のユニットは診断過程を自立的には実行せず、サーバから到来するデータを診断すべき制御装置へ転送するのみである。これにより車両内の診断プロトコル機能部は最小限まで著しく省略される。つまり診断プロトコル機能部はほとんど完全にサーバ内に設けられることになる。この場合、個々の診断命令はトランスペアレントにエアインタフェースを介して伝送される。簡単な構造の幾つかのメッセージのみ車両内で形成される。このことは診断過程中に伝送されるデータ内容が本来の診断データ（エラーメモリの内容）のほか、例えばＫＷＰ２０００診断プロトコル規格に準拠した付加的な診断命令も伝送することを意味する。
【００２８】
第３の構成は前述の２つの構成の混合形態であり、テレマティクス端末機とサービスセンタとのあいだで診断機能をパーティショニングする究極のバリエーションを使用する。例えばこのとき、端末機内に固定には組み込まれていない、全機能を遠隔制御するための命令と個別の診断プロトコルの命令とが同時に伝送される。
【００２９】
図３の左方には診断システムの車両側ユニット５２が示されており、右方にはネットワーク側ユニット５０が示されている。矢印は情報流の方向であり、上方から下方へ通信フレームの問い合わせおよび応答の時間シーケンスが表されている。図示の通信ステップは例であり、例えば１つの通信過程内の個々の部分ステップをまとめることによりステップ数を低減することもできる。
【００３０】
まずステップＣ１で、遠隔診断開始ページの要求がクライアントからサービスセンタへ送信される。有利な実施例ではこのメッセージは端末機内に記憶されたＵＲＬアドレスとして送信される。この要求は相応の遠隔診断をユーザがアクティブ化することによりトリガされる。これには例えば車両内に配置されたスイッチ、入力、命令のコンビネーションを用いてもよいし、また移動無線を介して（ユーザ側またはサービスセンタ側から）要求を伝送してもよい。サーバの応答はステップＳ１に示されている。有利な実施例ではサーバは端末機に車両内の遠隔診断をアクティブ化するＷＡＰページを表示する。このページはＷＭＬページとして実現される。これらの２つのステップは“遠隔診断サービスの要求”の部分過程である。
【００３１】
ＷＡＰページ受信後の次のステップＣ２では、クライアントが自動で、またはユーザのイニシャライズにより、Ｌｏｇｉｎページの送信を要求する。そのＵＲＬは取得されたページ内に存在している。サーバはこれに応じてステップＳ２でＬｏｇｉｎスクリプトへのリンク（Verweis）を備えた所望のＬｏｇｉｎページを準備する。このページはここではＷＭＬページとして相応のスクリプトリンクとともに送信される。クライアントでは場合によりロードされたＬｏｇｉｎページについての情報がユーザのディスプレイに表示される。次のステップＣ３では、クライアントによるＬｏｇｉｎスクリプトの自動要求が、サーバ（サービスプロバイダ）での認証および／またはユーザＩＤ識別のために行われる。そのためのＵＲＬはスクリプトリンクによりＷＭＬページ内で求められる。続くステップＳ３で、サーバは要求されたＬｏｇｉｎスクリプトを車両内の有効データ読み出しのためのＷＭＬスクリプトとして送信する。これはクライアントが自動で行ってもよいし、またユーザの入力によって行ってもよい。これに応じてクライアントはステップＣ４で次のＷＡＰページの要求とともにユーザＩＤデータをサーバへ送信する。サーバでは送信されたユーザデータが検査され、これらのデータが正しい場合には遠隔診断過程を続行し、正しくない場合には過程を中断するかステップＳ３を反復する。ステップＳ２〜ステップＣ４は“ユーザＩＤの識別および認証”の部分過程である。
【００３２】
ユーザデータが正しいことが認証されると、サーバは遠隔診断を開始する。ステップＳ４で、サーバは、ユーザＩＤの認証が成功した後、Ｌｏｇｉｎ確認を行うＷＡＰページをスクリプトリンクを有するＷＭＬページとして送信する。ここでＷＡＰページは車両ＩＤ識別のためのＷＭＬスクリプトへのリンクを含む。クライアントではＬｏｇｉｎ確認の送信がユーザ情報としてディスプレイに表示される。次のステップＣ５ではクライアントが車両ＩＤデータを読み出すためのスクリプト要求をサーバへ送信する。これに必要なＵＲＬアドレスはステップＳ４のスクリプトリンクに含まれている。サーバはこの要求を受け取り、ステップＳ５で車両ＩＤデータを読み出すためのスクリプトをＷＭＬスクリプトとしてクライアントへ送信する。これに応じてクライアントでは相応のＩＤデータが読み出され、次のＷＡＰページの要求とともにデータをステップＣ６でサーバへ送信する。送信された車両ＩＤデータ（車両型式、ソフトウェアステータスなど）は場合により送信されるＧＰＳ位置データとともにサーバ内で検査される。データに応じて診断フローおよび必要なパラメータがデータバンクから選択される。こうしてステップＳ４〜ステップＣ６の“車両ＩＤの識別”の部分過程は終了し、次のＷＭＬページがサーバに要求される。そのためのＵＲＬは前述のようにこの部分ステップ中にクライアントに送信されている。
【００３３】
サーバはこれに応じてステップＳ６で、ステータス情報を備えた診断続きページを診断スクリプトへのリンクとともにクライアントへ送信する。これはスクリプトリンクを有するＷＭＬページとして行われる。クライアントでは場合により診断開始がユーザに対してディスプレイに表示される。ステップＳ６の情報が受信された後、クライアントはステップＣ７でサーバへ診断データの読み出しのための診断スクリプトの伝送要求を送信する。ＵＲＬアドレスはステップＳ６のスクリプトリンクから取り出される。サーバはこの要求に基づいて診断スクリプト（ＷＭＬスクリプト）を作成し、ステップＳ７でクライアントへ伝送する。これに応じて診断スクリプトの実行中に車両側のエラーメモリが読み出され、次のＷＭＬページの要求とともにステップＣ８でサーバへ伝送される。ステップＳ６〜ステップＣ８は“診断データの読み出し”の部分過程であり、これは基本的に複数のフロー、つまり複数の部分スクリプトによって実行される。例えば制御装置ごとに１つずつスクリプトを設けることができる。この部分過程は複数回実行される。
【００３４】
先行ステップで取得されたＵＲＬアドレスを用いて診断結果を含むＷＡＰ続きページが要求される。サーバでは診断データ（エラーコード）がデータバンクによって評価され、場合により重みづけされ、ダイナミックに診断結果が作成される。この結果のページはステップＳ８でＷＭＬページとしてクライアントへ送信される。結果のページの送信に基づいてクライアントでは診断結果がディスプレイに表示される。ステップＳ８は“診断結果の作成およびその出力”の部分過程である。
【００３５】
これに応じて続くステップＣ９ではクライアントが場合によりマニュアルでイニシャライズして続きの推奨を備えたＷＡＰページの要求をサーバへ送信する。そのためのＵＲＬは端末機内に記憶されているか、または診断結果とともに送信されている。要求を受信したサーバは、データバンクから、識別された１つまたは複数のエラーに依存して続きの推奨を作成し、推奨ページを形成して診断過程を終了する。ステップＳ９でサーバは推奨ページをＷＭＬページとしてクライアントへ送信する。求められた続きの推奨はクライアントがディスプレイへ出力する。
【００３６】
ＷＭＬスクリプトまたはページにおいてインプリメントに応じて終了のためにブラウザ命令が設けられることを補足しておく。これは、次のＷＭＬページをサーチし、これに関連するデータをロードし、場合によりクライアントで求められたデータを要求とともにサーバへ伝送するためのものである。
【００３７】
ここに挙げた通信のシナリオでは、クライアント側で前述のＷＭＬスクリプトの実行の際にＷＡＰ規格として標準化されているＥＦＩインタフェースへ頻繁にアクセスが行われる。上述のシナリオは１つの実施例であり、個別のケースに応じて大きく異なってくる。遠隔診断のフローは次のような部分ステップ（上述の説明では部分過程）から成っている。すなわち
１．遠隔診断サービスの要求
２．ユーザＩＤの識別および認証
３．車両ＩＤの識別
４．診断データの読み出し
５．診断結果の作成
６．続きの推奨の作成
である。
【００３８】
これらの部分ステップの順序は部分的に交換可能である。またステップ６は場合によっては省略される。
【００３９】
個々の通信ステップの個数および長さは車両内の診断すべきユニットの個数に依存して定まる。説明したフローは遠隔診断をアクティブ化した時点から診断結果が出力されるまでユーザとのインタラクションなしに完全に自動で行われる。
【００４０】
クライアントでは、ＣＡＮコネクションを介して所定の命令を診断すべき制御装置へ送信することにより、スクリプトが実行される。求められたデータはＣＡＮコネクションを介してクライアントへ送信され、そこからエアインタフェースを介してサーバへ送信される。
【００４１】
上述の方法はサーバ内および端末機のマイクロコンピュータ内の相応のプログラムにより実現される。このプログラムも本発明の独立請求項の対象となっている。以下にサーバのプログラムの例を図４に即して、また端末機のプログラムの例を図５に即して詳細に説明する。
【００４２】
図４のプログラムは遠隔診断を開始する要求によりスタートする。ステップ１００でサーバアクティブ化のための所定のＷＡＰページを送信する。サーバはつねに到来する要求に応答する。すなわちサーバは要求が来ないかぎり“イナクティブステータス”にある。クライアントからの要求が到来しないとサーバの通信は終了する。ステップ１０２ではＬｏｇｉｎページの問い合わせ（ＵＲＬアドレス）の受信が待機される。問い合わせが受信されるとステップ１０３へ移行する。問い合わせが受信されないとサーバからの通信は失敗として終了される。ステップ１０３でサーバは問い合わせにしたがってＬｏｇｉｎページをスクリプトリンクとともに応答する。これに応じてステップ１０５ではＬｏｇｉｎスクリプトに対する応答（ＵＲＬアドレス）の受信が待機される。問い合わせが受信されるとステップ１０６へ移行する。問い合わせが受信されないとサーバからの通信は失敗として終了される。ステップ１０６でサーバは問い合わせにしたがってＬｏｇｉｎスクリプトを送信する。これに応じてステップ１０７では次のページの問い合わせ（ＵＲＬアドレス）、ユーザＩＤデータおよび認証データの受信が待機される。問い合わせおよびデータが正しく受信されるとステップ１０８へ移行する。問い合わせまたはデータが受信されないと通信は失敗として終了される。ステップ１０８ではユーザＩＤデータおよび認証データが検査される。これらが予め記憶されているデータと一致する場合、つまり送信者が権限を有する場合には、ステップ１０９へ移行する。そうでない場合にはステップ１２３でエラー報告のためのＷＭＬページが作成され、誤った問い合わせに対する応答としてクライアントへ送信される。この場合には通信はステップ１０４で終了する。ステップ１０９ではサーバは問い合わせにしたがって、取得したデータに基づいてダイナミックに作成された続きページをＬｏｇｉｎの確認および車両ＩＤスクリプトに対するスクリプトリンクとともに送信する。これに応じてステップ１１０では車両ＩＤスクリプトに対する応答（ＵＲＬアドレス）の受信が待機される。問い合わせが受信されるとステップ１１１へ移行する。問い合わせが受信されないと通信は失敗として終了される。ステップ１１１ではサーバは問い合わせにしたがって車両ＩＤスクリプトを送信する。これに応じてステップ１１２では続きページの問い合わせ（ＵＲＬアドレス）と車両ＩＤデータとの受信が待機される。問い合わせおよびデータが受信されるとステップ１１３へ移行する。問い合わせまたはデータが受信されないと通信は終了する。ステップ１１３ではサーバは送信された車両データにしたがって相応の車両に対する診断スクリプトをデータバンクから取り出し、これを送信する。ステップ１２４で送信されたデータに対してスクリプトが形成されるか否かが検査され、形成されない場合には標準スクリプトが使用されるかまたは当該の過程が終了される。このときステップ１２５でＷＭＬページの形式でエラーが報告されるかまたはそのリンクが返送される。ステップ１１４ではサーバは問い合わせにしたがって続きページを診断スクリプトへのリンク（ＵＲＬアドレス）とともに送信する。これに応じてステップ１１５ではスクリプトに対する問い合わせ（ＵＲＬアドレス）の受信が待機される。問い合わせが受信されるとステップ１１６へ移行する。問い合わせまたはデータが受信されないと通信は失敗として終了される。ステップ１１６ではサーバは問い合わせにしたがって診断スクリプトを送信する。これに応じてステップ１１７では続きページに対する問い合わせ（ＵＲＬアドレス）および診断データの受信が待機される。ステップ１２６で問い合わせおよびデータが受信されると、ステップ１１８へ移行する。問い合わせまたはデータが受信されないとサーバからの通信は中断または終了する。この場合にはステップ１２７でＷＭＬページの形式でエラーが報告されるかまたはそのリンクが返送される。ステップ１１８ではサーバは送信された診断データにしたがってデータバンクを用い、診断結果を求める。次のステップ１１９ではサーバは問い合わせにしたがって診断結果ページを送信する。これに応じてステップ１２０で推奨ページに対する問い合わせ（ＵＲＬアドレス）の受信が待機される。問い合わせが受信されるとステップ１２１へ移行する。問い合わせが受信されないとステップ１０４で通信は失敗として終了される。ステップ１２１ではサーバは送信された診断データにしたがってデータバンクを用い、さらなる処置に対する推奨のページを作成する。次のステップ１２２でサーバは問い合わせにしたがって推奨ページをクライアントへ送信する。こうしてステップ１０４で通信ひいては遠隔診断過程が終了する。
【００４３】
サーバ側で、本来は独立かつ匿名のクライアントのそれぞれの問い合わせのあいだの関係を把握するために、通信のはじめＬｏｇｉｎ後に１回だけセッションＩＤが付与され、順次の問い合わせが識別される。これによりサーバは誰の問い合わせを聴取しているかを知ることができる。このようなセッション管理の手法はインタネットの分野では周知であり、広汎に用いられている。
【００４４】
図５のプログラムはユーザのアクティブ化によりスタートする。ステップ２００でクライアントは遠隔診断の開始を要求する問い合わせ（所定のＵＲＬアドレス）をサーバへ送信する。ステップ２０１でアクティブ化ページの受信が検査される。例えば設定された時間内にページが受信されればステップ２０２へ移行する。問い合わせが受信されないとステップ２０４で通信は失敗として中断または終了される。ステップ２０２ではクライアントはＬｏｇｉｎページの問い合わせ（ＵＲＬアドレス）をサーバへ送信する。これに応じてステップ２０５では相応のページの受信が検査される。例えば設定された時間内にページが受信されればステップ２０６へ移行する。ページが受信されないとステップ２０４で通信は中断または終了される。ステップ２０６ではクライアントはＬｏｇｉｎスクリプトの問い合わせを送信する。これに応じてステップ２０７ではスクリプトの受信が検査される。例えば設定された時間内にスクリプトが受信されればステップ２０８へ移行する。スクリプトが受信されないとステップ２０４で通信は中断または終了される。ステップ２０８ではＥＦＩインタフェースを介してユーザＩＤデータがメモリから取り出され、これがサーバへ送信され、さらに続きページが問い合わされる。これに応じてステップ２１０では続きページ、Ｌｏｇｉｎ確認およびスクリプトリンクの受信が検査される。例えば設定された時間内に続きページが相応のデータとともに受信されればステップ２１１へ移行する。ページまたは確認が受信されないとステップ２０４で通信は中断または終了される。ステップ２１１では車両ＩＤスクリプトの問い合わせが送信される。これに応じてステップ２１２ではスクリプトの受信が検査される。例えば設定された時間内にスクリプトが受信されればステップ２１３へ移行する。スクリプトが受信されないとステップ２０４で通信は中断または終了される。ステップ２１３では、例えば端末機のメモリからの取り出しまたは診断すべき制御装置またはコンポーネントへのＥＦＩインタフェースを介した問い合わせによって、車両ＩＤデータが求められ、このＩＤデータとともに続きページの問い合わせが送信される。これに応じてステップ２１４で診断ページおよびスクリプトリンクの受信が検査される。例えば設定された時間内にページが受信されればステップ２１５へ移行する。データが受信されないとステップ２０４で通信は失敗として中断または終了される。ステップ２１５では診断スクリプトの問い合わせが送信される。これに応じてステップ２１６で診断スクリプトの受信が検査される。例えば設定された時間内にスクリプトが受信されればステップ２１７へ移行する。ＷＭＬスクリプトが受信されないとステップ２０４で通信は中断または終了される。ステップ２１７では診断すべき制御装置とのＥＦＩインタフェースを介した相応の通信によって診断データが求められ、続きページの問い合わせとともに送信される。これに応じてステップ２１８で結果ページの受信が検査される。例えば設定された時間内にページおよびデータが受信されればステップ２１９へ移行する。応答ページが受信されないとステップ２０４で通信は失敗として中断または終了される。ステップ２１９では結果に基づいて、推奨ページを要求すべきか否かが求められる。要求しない場合にはステップ２０４で遠隔診断過程は終了する。要求する場合には相応の問い合わせがステップ２２０で送信される。これに応じてステップ２２２で推奨ページの受信が検査される。例えば設定された時間内にページが受信されればステップ２２３へ移行する。ページが受信されないとステップ２０４で通信は中断または終了される。ステップ２２３では推奨ページが表示され、通信ひいては遠隔診断過程がステップ２０４で終了する。診断過程中、通常は、取得されたページがサーバで作成されたステータス情報とともに表示される。
【図面の簡単な説明】
【００４５】
【図１】車両に関連するテレマティクスサービスシステムの概略図である。
【図２】ＷＡＰプロトコルに基づく図１のシステムの実施例の概略図である。
【図３】テレマティクス端末機とサーバとのあいだの伝送のステップの実施例を示す図である。
【図４】通信プログラムのフローチャートである。
【図５】通信プログラムのフローチャートである。
【図１】
2005529424.tif 000003
【図２】
2005529424.tif 000004
【図３】
2005529424.tif 000005
【図４】
2005529424.tif 000006
【図５】
2005529424.tif 000007
【国際調査報告】
2005529424.tif 000008
2005529424.tif 000009
2005529424.tif 000010
2005529424.tif 000011
2005529424.tif 000012
2005529424.tif 000013