JP2005529419A - 車両に係るテレマチックサービスのための方法及び装置 - Google Patents

Abstract

本発明は、車両に係るテレマチックサービスのための方法及び装置に関しており、ここではテレマチックサービスが複数の部分機能性に細分化され、これらの部分機能性がサーバーと端末に対して分割されている。

Description

本発明は、例えば車両におけるエアーインターフェース、例えば移動無線網を介した、特に自動車の遠隔診断と結び付けられた少なくとも１つの機能性への関与などの、車両に関するテレマチックサービスのための方法及び装置に関する。

今時の自動車における制御機器群の益々のネットワーク化は、自動車における機能性への関与の可能性を定常的に向上させており、例えば車両の機能性および/または構成要素の良好な遠隔操作手段ないしはエラー時の良好な診断可能性などが提供されている。この関係においては、次のような構想が成り立つ。すなわち移動無線網で支援された関与が可能になることや、任意の間隔距離を隔てた車両内の機能性へのアクセスが保証されることである。例えば遠隔診断を介して可能とされる高品質なエラー解析が、サービスセンターや診断データベースを含んだ遠隔診断サーバーによって実施されることである。このような構想によれば、車両内で統合化された通信システム、例えば移動電話及び/又はＧＳＭ方式のテレマチック端末が、車両ネットワークに接続された制御機器及び/又は構成要素とサービスセンターのサーバーとの間のデータ伝送実施のために使用される。この種のシステムに対する提案は、例えばドイツ連邦共和国特許出願公開第１００２６７５４号明細書に開示されている。しかしながらサーバーと端末の間の伝送内容並びに当該端末ないしサーバーの構成に関する具体的な実現構成はここでは明示されていない。

発明の利点
端末とサーバーの間の機能性（例えば診断機能）の分割によって（部分機能性の部分化）、著しい資源の節約が車両内で達成される。特に有利には、選択された機能性への関与が制御できる時間的に縛られることのない車両固有の機能性が車両端末においてではなく、サーバーにおいて維持され、そこからエアーインターフェースを介して伝送される。それにより、特に車両ネットワークによって設定される時間的な環境条件に係る適用業務に対して区切られる付加的な固有のエアーインターフェース用アプリケーションプロトコルが必要となり、そのため通常のエアーインターフェース用標準プロトコルに手をつけることが可能である。補足的に、エアーインターフェースを介した車両固有の情報の伝送が、端末内でパラメータ化可能な統一的機能性を可能にし、さらに車両に依存する端末内の実現を可能にする。システムの特に高い汎用性が達成され、それ自体も変化し得る車両の装備体系にも適応化が可能である。

遠隔診断のもとでは、診断自体に関する変更や改良も、それ自体が車両の制御ユニットを介してオンボード上で実行されない限り、サーバー内で可能となる。

特に有利には、遠隔診断との結び付きにおいて、車両固有の診断プロトコルの命令がエアーインターフェースを介してサーバーから端末へ伝送され得る。

車両端末における資源の節約、特にサービスセンタのサーバー内での時間的に縛られることのない手順のストックによって、端末内での車両ネットワークに対する簡単で迅速な変換が可能となる。

それによって総体的に、効果的でかつ少ないコストで実現が可能な車両機能性への関与、特に遠隔診断、遠隔アラーム、遠隔制御、ソフトウエアダウンロード等のための手法が、自動車において実現される。

さらなる別の利点は、以下の明細書若しくは従属請求項から明らかとなる。

図面
本発明は以下において図面に示された実施形態に基づき自動車の遠隔診断のケースで詳細に説明される。この場合、
図１は、遠隔診断システムの基本原理図であり、
図２は、車両側のシステム部分とサーバー側のシステム部分の間で診断機能性の分割並びに車両端末ないしサービスセンタのサーバーの構成を表わした図であり、
図３は、サーバー/端末間の伝送に関する並びに端末ないしサーバーの機能に関する遠隔診断の基本的なシーケンスを表わしているフローチャートであり、
図４は、サーバと端末の間の通信並びに端末と診断すべき制御機器の間の通信、並びにそれぞれのユニット内で実行される手順を詳細に説明するための図である。

図１には、車両に関するテレマチックサービスのためのシステムの構成図が示されており、この場合車両（端末）とサーバーの間で情報が移動無線網ないしデータネットワーク（例えばインターネット）を介して交換される。この種のコンフィグレーションは、遠隔操作、遠隔診断、遠隔アラーム、ソフトウエアダウンロードなどのための機能と結び付けて採用される。ここでの遠隔操作（作用）ないし遠隔問合せとは、実質的には車両機能の遠隔制御、例えば補助ヒータのスイッチオンや車両状態および/または作動パラメータの問合せなどを意味する。その場合にユーザーは、中央サーバーを介して車両との通信を開始したり、あるいは車両と直接通信を始める。遠隔診断には、車両からの診断データの遠隔読出しが含まれ、それらの分析や場合によっては十分な取り扱いのためのメッセージの形成が含まれる。データの分析やメッセージの形成は、中央サーバーを介して行われる。この中央サーバーは、移動無線網、ワイヤレスネットワークを介して車両と接続形成されるか、及び/又はインターネットなどのデータネットワークを介して車両と接続形成される。さらにいわゆるリモートフラッシングとも称されるソフトウエアのダウンロード機能としての関係においては、それを用いて新たなプログラムコード又はソフトウエア毎に構築可能なシステムに対するパラメータが車両内部で例えば制御機器に調達され、機能若しくは能力のアップが図られる。ここでも通信が移動無線網、ワイヤレスネットワーク及び/又はインターネットを介して中央コンピュータ（サーバー）ないしサービスセンタから行われる。遠隔アラームは、実質的には車両状態の監視と中央センタからの車両内のメンテナンスデータへのアクセスを表わし、目標状態の保全のための手段をいつどのように講じるべきかを検査している。これに対する例としてメンテナンス間隔の動的適応化が挙げられる。一般的にはこれらの機能は、ここでは車両に係るテレマチックサービスの概念に従属させられる。

図１は、車両側部分１とサーバー側部分２が示されている。この２つの部分は、通信インターフェース３、特にエアーインターフェース、例えば移動無線網を介して相互接続されている。車両側部分は、端末４、例えばテレマチック端末からなり、これはさらなるインターフェース５を介して車両電子回路（エレクトロニクス）６に接続されている。サーバー側部分２は、サーバー７からなっており、このサーバーは、例えばサービスセンタ、車両製造メーカー、又は供給元から作動されており、インターフェース８を介してデータメモリ９と接続されている。このデータメモリ９内には、例えばデータベースの枠内で車両に係るデータ及び/又はプログラムがファイルされている。以下で詳細に説明するように、図示のクライアント・サーバーシステムでは、部分的な機能が部分化されてる。すなわちサーバーとクライアントに、テレマチックサービスの所定の機能が割当てられる。その場合、車両内の診断すべきないしは制御すべき制御機器と端末との完全なネットワーク化から出発し、例えばＣＡＮバスによって並びにインターフェース３、特に自動車内の移動無線インターフェース３の可用性から出発する。診断データ把握のための公知の種々異なる方法は（例えばＣＡＮバスインターフェースを介した）、時間的に余裕のある（時間に縛られない）適用と時間的に余裕のない（時間に縛られる）適用とに分けられる。時間的に余裕のある適用（アプリケーション）とは、例えば診断テスターの実行制御が挙げられ、データベースへのアクセス、並びに診断プロトコル自体、例えばプロトコルＫＷＰ２０００ないしはそれに基づく応用方式が挙げられる。時間的に余裕のない適用（アプリケーション）とは、車両ネットワーク（例えばＣＡＮバス・トランスポートプロトコル）あるいはその応用例、その通信レイヤ（例えばＣＡＮ通信レイヤ）並びにバス（例えばＣＡＮバス）自身が挙げられる。重要なのは、自動車におけるテレマチック機能の実行の際に、不確かな移動無線チャネルに対し時間的に余裕のない過程は接続解除されることである。それ故に、限られた時間的要求、特にデータ伝送における命令と応答との間の最小ないし最大時間に関する要求の生じない関連する機能の全て若しくは一部が自動車からスワップアウトされる。それ故に極端なケースでは、時間的に余裕のないデータ転送のみが車両バス（例えばＣＡＮバスなど）上で維持される。これは転送プロトコルの機能によって例えば複雑なメッセージの細分化や非細分化を実現させ、クライアント側ないしは車両側へ戻す。通常は複雑で車両固有のサービスプロトコル（例えば診断プロトコル）の機能範囲は、この場合相応のサーバー（例えば診断サーバー）上に保管される。遠隔診断の適用ケースでは、そのつど使用される診断プロトコルに基づいた車両固有の診断命令の伝送の他に、さらに付加的な情報がサーバーアプリケーション（全過程に対する制御シーケンス）とクライアントアプリケーション（データ収集のための制御シーケンス）の間で伝送される。この制御シーケンスは、診断過程やクライアントアプリケーションのコンフィグレーション、後からのサーバー側データ分析結果の伝送の実施に用いられる。略示されている例では、時間的に余裕のある全ての過程がシステムの車両側部分からサーバー側部分にスワップアウトされており、図２に示されているシステムアーキテクチャが得られる。他の実施例では、時間的に余裕のある過程の部分だけがスワップアウトされ、それに対して一部は車両側端末に残される。それにより例えば車両固有のデータおよび/または特別な車両固有の診断コマンド（これらはセキュリティの理由からスワップアウトされない）がシステムの車両側部分に残されるように設定することが可能となる。

他のテレマチックサービス（例えば構成要素の遠隔制御や、ソフトウエアのダウンロードなど）との連係においては、時間的に余裕のあるアプリケーションは前述したような形式でスワップアウトされ、それに対して時間的に余裕のないアプリケーションは、車両端末に残される。

図２には、車両端末（クライアント）４とサーバー７が示されており、これらはエアーインターフェース３を介して相互に接続されている。有利な実施例によれば、このエアーインターフェース３は、従来方式の例えばＧＳＭ標準に準拠した移動無線網である。他の適用例では、その他の標準方式で作動する移動無線網である。サーバーは、次のモジュールを含んでいる。すなわち、移動無線通信プロトコルモジュール７ａ、移動無線通信モジュール７ｂ、シーケンス制御モジュール７ｃ、車両固有の診断プロトコルモジュール７ｄである。車両端末も同様に、通信プロトコルモジュール４ａ、移動無線インターフェースを介した通信のためのモジュール４ｂ、ＣＡＮ通信のためのモジュール４ｃ、トランスポートプロトコルモジュール４ｄを含んでいる。さらにシーケンス制御モジュール４ｅも車両端末内に設けられている。これらのモジュールはこの場合有利にはソフトウエアプログラムを表わしている。

移動無線通信モジュール４ｂ,７ｂ（これらは端末内にもサーバー内にも設けられている）は、安定したデータ転送と接続の形成ないし解除、データセキュリティ、場合によっては暗号化、パッキングなどのために用いられる。これらの課題は、例えばＧＳＭ標準の枠内で可能な通常の通信機能ユニットによって実現される。車両端末内に設けられるＣＡＮ通信モジュール４ｃは、接続されている制御機器へのＣＡＮバスを介したデータ転送のためのハードウエア依存型のソフトウエアインタフェースを表わしている。それに属するのは、ＣＡＮコントローラの初期化及び制御、ＣＡＮモジュールの転送と受信、オーバーフローやエラー処理及び通知機能などである。さらに当該モジュールは、ＯＳＩレイヤ１及び２（物理層、データリンク層）の機能も含む。ソフトウエアモジュールは、この場合有効なＣＡＮ仕様の枠内で作動する。他の実施例では、ＣＡＮバスの代わりに他のバスシステムが用いられ（標準化もしくはユーザー固有）、その場合ソフトウエアモジュールは、相応の仕様に基づいて実現される。

サーバー内のシーケンス制御モジュール７ｃは、診断基本機能を個別の部分プロセスないし診断サービスに細分化し、プロセスの初期化を請け負い、診断過程を制御及び終了させ、所要のパラメータ及び場合によっては診断過程のプロトコル機構を処理し、全過程を時間的に制御する。さらにここでは求められた診断データが評価され、場合によっては推奨の形成が実行される。さらにシーケンス制御モジュールは、サーバーの診断データベースへのアクセスも請け負う。シーケンス制御モジュールは、固有の適用に対して構成されているソフトウエアモジュールを表わしている。その一例を以下の明細書で図３及び図４に示されている遠隔診断に基づいて説明する。

相応の形式でシーケンス制御モジュール４ｅは、車両端末内に設けられている。このソフトウエアモジュールも、固有の適用（アプリケーション）のために構成されている。例えば以下では図３及び図４に示されている遠隔診断に基づいて説明する。このシーケンス制御は、遠隔診断を実行するためのサーバー問合せを生成する。それは車両内の次のような機能を構成する。例えばテスタープレゼントメッセージの確定、トランスポートプロトコルのためのタイミングパラメータの設定、場合によってはＣＡＮ通信のためのパラメータの設定などである。さらにシーケンス制御モジュールは、テスタープレゼントメッセージの周期的な生成によって、診断すべき制御ユニットとの診断通信を構築する。さらにサーバーから伝送された診断コマンドがＣＡＮトランスポートプロトコルに変換される。さらにシーケンス制御モジュールは、データをサーバーに伝送し、この目的のために、車両内で求められた診断データを移動無線インターフェースに対して変換する。その他にも一例として、サーバーから伝送されたエラー分析評価結果を表示する手段が講じられ得る。さらにシーケンス制御モジュールは、診断通信の終了をテスタープレゼントメッセージの停止によって行う。さらに一例として中断された診断過程の自動終了が、例えばサーバーコマンドの受信に対するタイムアウトないしウオッチドックによって実施され得る。

クライアント４側に設けられているトランスポートプロトコルモジュール４ｄは、複雑なメッセージ若しくはデータ単位のＣＡＮバスを介した伝送を実施しており、物理的な伝送媒体からの診断プロトコルの接続解除を行い、ＯＳＩレイヤー３（ネットワーク層）のサービスが使用可能であり、ＯＳＩレイヤー２（データリンク層）と７（アプリケーション層）の間の接続を行う。トランスポートプロトコルモジュールからはデータリンク層のデータのセグメント化と収集が行われる。すなわち個々のメッセージのデータ流の制御には、論理的メッセージ若しくはデータ単位並びにエラー識別に対する物理的なＣＡＮメッセージの管理と対応付けが含まれる。実現化は一般的に拡張されたＩＳＯトランスポートプロトコル（ＩＳＯ１５７６５−２）で表わされ、その場合他の適用ケースにおいて当該プロトコルの特別な変形例も用いられ得る。このことは、車両制御機器との通信のための他のバスシステムの利用下でも当て嵌まる。

サーバーに割当てられている診断プロトコルモジュール７ｄは、有利にはＩＳＯに準拠する固有の診断プロトコルＫＷＰ２０００も含んだ診断層を含む。その場合は実施例に応じてその変化例も用いられる。この診断プロトコルモジュールでは、特有の診断サービスが定められ、それは自動車の製造メーカに応じて及び/又は自動車のタイプに応じて区別して用いられ、一部は異なった状態サービスが含まれる。この診断プロトコルモジュールは、診断問合せを評価する。モジュールによって解決されるさらなる課題は、アプリケーション層、固有サービスの直接的使用、及び未知のサービスの使用の際の例外処理に対するサービスから機能インターフェースへの変換である。そのようなモジュールの実現のための例は、以下で説明される手法から得られる。

遠隔診断の枠内での基本的な手法は、次のことからなっている。すなわち、操作者、例えば自動車のユーザー及び/又はサービスプロバイダ及び/又は車両メーカー及び/又は工場のメカニックによる遠隔診断の活性化の後で、端末とサーバーの間の接続形成のための手段の終了後に、車両固有の診断プロトコルのコマンドがエアーインターフェースを介してサーバーから端末に伝送される。この場合車両固有の診断プロトコルコマンドは、診断サーバーによって、診断すべき自動車の識別後にデータベースから読出される。端末は車両ネットワークに対して伝送される診断コマンドを変換する。これは例えば次のことによって行われる。すなわち受信されたコマンドを診断すべき制御機器用のコマンドに変換し、車両ネットワーク用のインターフェース、特にＣＡＮバスを介して制御機器へ送信されることによって行われる。この制御機器の応答は、車両ネットワークからのデータメッセージとして相応の形態で車両ネットワークインターフェースを介して受信され、その後端末からサーバー用の応答メッセージに変換される。これらはその後移動無線インターフェースへ転送され、当該移動無線インターフェースは、このメッセージを設定されている転送プロトコル（例えばＧＳＭ標準の枠内）を介してサーバーに送信する。統合的に、クライアントは、有利な実施例によれば、サーバーから伝送された診断プロトコル（ＫＷＰ２０００）をＣＡＮトランスポートプロトコルに変換し、またＣＡＮトランスポートプロトコルを診断プロトコルに変換する。車両内の診断通信の維持のための前述してきた過程のシーケンス制御は、端末機器内で自立的になされている（例えばいわゆるテスタープレゼントメッセージによって）。これらはＫＷＰ２０００仕様において定められ、車両ネットワークの時間的要求の充足に用いられる。それにより、サーバー内の時間的に余裕のある診断シーケンスから車両内の時間的に余裕のない診断通信の接続解除が達成される。その結果として、車両内の車両固有の診断通信の融通性に富んだコンフィグレーションが得られ、これはエアーインターフェースの生じ得るトラブルやサーバー内の診断シーケンスのトラブルによって負荷されることはない。

図３には５つの基本的な部分ステップに分けられている全過程のフローチャートが示されている。そのような部分過程内の詳細なシーケンスは、車両タイプに応じて、あるいは生じ得るエラーケースに応じて及び/又は診断サーバー内のシステムのそのつどの実施形態に応じて可変である。第１のステップ１００では、相応の問合せが伴う当該診断の開始がサーバーで行われる。この活動化は、有利には、ドライバによって、ないしは自動車のユーザーによって行われる。その際には診断接続を構築すべくサービスセンタのもとで呼出し等によって車両内のクライアントへのサーバーの要求が形成される。その後でクライアントは要求された接続を構築する。別の実施例では、診断接続がクライアントからの問合せによって構築される。ここでは本来の診断接続の構築は、サーバーかまたはクライアントによって行われる。次のステップ２００では、サーバーによって車両内の遠隔診断機能のコンフィグレーションが行われる。その際シーケンス制御、トランスポート層及び場合によってはＣＡＮ通信などが車両個別に適応化される。このことは、サーバーからのコマンドないしデータによって行われる。それらの情報は、固有の車両ないし車両タイプ及び/又はオプション装備毎にデータベースからリストアップされる。活動化の際には、サーバーは例えば識別コードを用いて診断すべき車両に関する情報を受取る。この情報に基づいてサーバーは車両固有のパラメータをデータベースから読出し、それらはその後遠隔診断機能のコンフィグレーションのためにクライアントに転送される。

活動化（１００）と初期化（２００）の部分ステップの後では、例えば制御機器における診断過程（３０１〜３０３）の実施が部分ステップで表わされている。まずステップ３０１では、サーバーによって、診断すべき制御機器内で、それが必要である限り、診断モードがトリガされ、それによって制御機器が診断機能の実施のためにスタンバイされる。さらに固有の制御器記タイプへの診断コマンドの適応化のために制御機器の識別、例えばそのソフトウエア状態の識別が行われる。このことは任意でもあるが、このことが例えば多数のソフトウエア状態に基づいて必要であると認められる場合には実施される。それに従って選択された診断コマンドがサーバーから車両のクライアントへ伝送される。そのような診断コマンドの例は、例えば該当する制御機器の少なくとも１つのエラーメモリの呼出し、発生したエラーの記憶されている環境パラメータの読出し、及び/又は相応する制御機器からの付加的な実際値の問合せなどである。

ステップ３０２ではクライアントが、伝送された１つ又は複数の診断コマンドを車両ネットワークに対して変換する。それに続くステップ３０３では、１つまたは複数の送信されたコマンドに対する制御機器の応答が受信され（それらは例えば所定の時間周期内で発生されなければならない）、クライアントからサーバーの伝送インターフェースへ置換えられ、そこからフィードバックされる。ステップ３０１〜３０３は、診断すべき各制御機器毎に、若しくは診断コマンドが個別にあるいはグループで相前後して送信される場合に、個々の診断コマンド毎に、または診断コマンドグループ毎に繰返される。制御機器のための診断が終了する場合には、診断コマンドとして１つの終了コマンドが送信され、これは場合によっては制御機器内の診断モードを非活動化させ、再びノーマル動作モードへ戻す働きをする。

第４の部分ステップは、サーバー内で得られたデータの評価に関している（ステップ４００）。このサーバーは、収集されたエラー情報を場合によっては特有のアルゴリズムに従って評価し、診断結果及び/又はさらなる推奨措置を求める。それに続くステップ５００では、サーバーによって求められた結果が端末機器に伝送され、その端末機器によって車両内で表示される。この第５番目の部分ステップは、結果の送出を表わしている。このステップでは、別の有利な実施例によれば、エラー発生ケースにおいてさらなる推奨措置、例えば“最寄りの修理工場の検索”などの伝送と表示がなされる。

図４には、遠隔診断サーバーとテレマチック端末機器と制御機器の間の例示的な通信シナリオが示されている。この通信シナリオは、図３中の第３の部分ステップの実現を表わしている。この通信のベースとなっているのは、ＩＳＯ１４２３０−３によって特定される診断プロトコルＫＷＰ２０００である。他の実施例では、この診断プロトコルのメーカ固有の変化例または他の診断プロトコルが相応に用いられる。実施例に応じてステップのシーケンスとステップの規模は、個々の適用ケースで変化する。図４は、遠隔診断サーバーＩと、車両内に設けられているテレマチック端末機器ＩＩと、診断すべき制御機器ＩＩＩの間の通信の実現が表わされている。この場合の通信は、ＩＳＯ１４２３０−３で特定されている診断プロトコルＫＷＰ２０００に基づいている。エラーの検出とエラーメモリのセットは、大抵のケースでは公知の診断メソードにより診断すべき制御機器内の既存のソフトウエアか若しくは読み込まれたソフトウエアによって行われる。

図４には、関与している３つのユニット間での通信の各々が示されており、この場合は上方から下方へ向けて時系列が表わされている。前記ユニット内には、伝送すべきメッセージを生成したり評価するソフトウエアプログラムが存在している。

部分過程１及び２（図３のステップ１００と２００参照）の終了後に、第１のステップＳ１において診断モードが診断すべき制御機器内で活動化される。それに対してサーバーは相応の診断コマンド（スタートダイアグノシスセッションリクエスト）を送信する。これは端末機器によって受信され、インターフェースを介して診断すべき制御機器へ転送（ステップＳ２）されるか、ないしはまず車両ネットワークに適したフォーマットに変換されて（例えばテーブルを介して）車両に送出される。診断すべき制御機器は、相応の応答信号で応答し（スタートダイアグノシスセッションレスポンス）、これは診断モードが開始されているか否かに応じて送出される。この情報は、診断すべき制御機器がステップＳ３において端末機器に送信し、この端末機器は再びステップＳ４において（場合によっては所定のフォーマットに変換した後で）当該情報をサーバーに伝送する。

車両ネットワーク内で端末機器ＩＩから制御機器ＩＩＩへの時間要求の充足とシーケンス制御のために、ステップＳ５においては、１つのコマンドが送信され（テスタープレゼントリクエスト）、このコマンドはステップＳ６において制御機器から相応の応答信号（テスタープレゼントレスポンス）で返信される。この通信は、以下では診断過程の間に、サーバーから他の診断コマンドが何も転送されないか若しくは制御機器からサーバーへの応答が何も返信されない場合に実施される。それ故に、ステップＳ５とステップＳ６は、所期のコマンドがサーバーから受信されるまで何度も繰返される。前述した事象の１つが現れない場合、当該端末機器と制御機器の間の通信は中断される。

ステップＳ４で応答を受信した後では、サーバーはステップＳ７において、診断すべき制御機器の識別を問い合わせするコマンド（リードＥＣＵ識別リクエスト）を送信する。このコマンドは、端末機器によって受信され、場合によっては変換され、その後でステップＳ８において制御機器に転送される。制御機器は、そのメモリから少なくとも１つの識別パラメータを読出し、それを端末機器に送信する（リードＥＣＵ識別レスポンス、ステップＳ９）。この情報は、その後場合によっては変換された後で端末機器ＩＩからステップＳ１０においてサーバーに伝送される。識別パラメータに基づいてサーバーがこの制御機器、場合によってはそのソフトウエア状態並びに場合によっては車両を識別し、データベースから相応のパラメータが選択される。介在期間においては、ステップＳ１１及びＳ１２に基づいて表わされているように、端末機器と診断すべき制御機器の間では、前述したようなテスタプレゼント通信が実行される。これは端末機器と制御機器との間の通信が維持され続けることを保証しており、この制御機器は診断モードで維持され、中断に結び付くような車両ネットワーク内の通信の環境条件の欠落は何も起こらない。

次のステップでは、診断すべき制御機器のエラーメモリが読出される。それに対してサーバーは、ステップＳ１０のメッセージの受信後及びステップＳ１３の端末機器のための制御機器固有のパラメータの読出し後に相応の問合せ（リードＤＴＣリクエスト）を転送する。この問合せにおいては制御機器固有のパラメータが得られ、その中では、例えばどのエラーメモリが読出されているかが提示されている。この問合せは、ステップＳ１４において端末機器から場合によっては変換を経由した後で制御機器に伝送される。制御機器は、受信したコマンドを実行し、エラーメモリ内容をリードＤＴＣレスポンスメッセージとしてステップＳ１５において端末機器に送信する。それによりこのリードＤＴＣレスポンスメッセージは、関連するエラーメモリ内容を含んでいる。この応答は、端末機器から場合によっては変換を経由した後でステップＳ１６においてサーバーに伝送される。さらにステップＳ１７とＳ１８においては、メッセージが新たに受信されるまで、端末機器と制御機器の間で前述したテスタープレゼント通信がサーバーによって実施される。

以下に述べる任意付加的な部分ステップにおいては、エラーエントリに属する環境パラメータが読出される。この目的のためにサーバーは、ステップＳ１６におけるメッセージの受信の後で、並びにステップＳ１９におけるエラーエントリの評価の後で、端末機器に相応の問合せ（リードフリーズフレームリクエスト）を送信する。これは場合によってはステップＳ２０における変換の後で制御機器に転送される。各実施に応じて制御機器は、記憶されたエラーに対する所望のパラメータを読出すか若しくはサーバーは、エラーメモリの内容に基づいてそのメッセージの内容を特定する。そのためこのメッセージによれば、所定の環境パラメータのみが要求される。制御機器は、いずれにせよ相応の応答信号（リードフリーズフレームレスポンス）でもって応答する。その場合１つのやり方若しくは別のやり方を要求するパラメータが含まれている。ステップＳ２１では、応答が端末機器に送信され、この端末機器はその応答を再び、場合によってはステップＳ２２の変換の後でサーバーに転送する。ステップＳ２３及びＳ２４では、テスタープレ線と通信が新たに行われる。

それに続く部分ステップにおいては、エラーメモリとそれに属する環境パラメータが読出され転送された後で、当該診断モードが制御機器において非活動化される。これに対してサーバーは、当該診断過程を終了するための要求（ストップダイアグノシスセッションリクエスト）を端末機器に送信する。この端末機器は、さらに終了のための要求を制御機器に転送する（ステップＳ２６）。制御機器はステップＳ２７において、診断モードの終了を伝える相応の応答信号（ストップダイアグノシスセッションレスポンス）で応答する。さらにステップＳ２９では、前述した診断結果の評価と表示並びに場合によっては推奨にも係る部分過程４及び５が引き続き行われる。

前述してきた通信のシナリオは実施可能な１つの例である。従って他の実施例において、制御機器における診断モードの活動化/非活動化のためのステップ、及び/又は制御機器の識別のためのステップ、及び/又は所属する環境パラメータの読出しのためのステップが省かれてもよい。

前述してきた通信に関する具体的な技術的実現は、それぞれ本発明の一部をなすものであるサーバー、端末機器、制御機器において、相応のソフトウエアプログラムにより実施することが可能である。

遠隔診断システムの基本原理図 車両側のシステム部分とサーバー側のシステム部分の間で診断機能性の分割並びに車両端末ないしサービスセンタのサーバーの構成を表わした図 サーバー/端末間の伝送に関する並びに端末機器ないしサーバーの機能に関する遠隔診断の基本的なシーケンスを表わしているフローチャート サーバと端末機器の間の通信並びに端末機器と診断すべき制御機器の間の通信、並びにそれぞれのユニット内で実行される手順を詳細に説明するための図

Claims (16)

1. 車両に係るテレマチックサービスのための方法であって、中央コンピュータ（サーバー）と端末機器を有しており、該端末機器は、有利には自動車内部に配設されており、前記中央コンピュータ（サーバー）と端末機器との間で通信接続が形成される形式の方法において、
   テレマチックサービスが部分機能性に分割され、
   前記部分機能性は再びサーバーと端末機器に対して分割され、
   時間的に余裕のある機能性はサーバー内で実行され、時間的に余裕のない機能性は端末機器内で実行されるようにしたことを特徴とする方法。
2. 車両に係るテレマチックサービスのための方法であって、中央コンピュータ（サーバー）を有しており、該中央コンピュータ（サーバー）は、端末機器と通信接続を形成する形式の方法において、
   テレマチックサービスが部分機能性に分割され、時間的に余裕のある機能性がサーバー内で実行されるようにしたことを特徴とする方法。
3. 車両に係るテレマチックサービスのための方法であって、有利には自動車内に配設された端末機器を有しており、該端末機器は中央コンピュータ（サーバー）と通信接続を形成する形式の方法において、
   テレマチックサービスが部分機能性に分割され、時間的に余裕のない機能性が端末機器内で実行されるようにしたことを特徴とする方法。
4. 時間的に余裕のない部分機能性は、自立的に端末機器内で実行され、時間的に余裕のある部分機能性は、サーバーによって、端末機器との通信を介して実施される、請求項１から３いずれか１項記載の方法。
5. 前記端末機器内で、診断すべき制御機器及び/又は診断すべき構成要素との時間的に余裕のない通信が実施される、請求項１から４いずれか１項記載の方法。
6. 前記テレマチックサービスは自動車の遠隔診断であり、診断プロトコルがサーバー内で実施される、請求項１から５いずれか１項記載の方法。
7. 車両固有の診断プロトコルのコマンドがエアーインターフェースを介してサーバーから端末機器へ伝送される、請求項１から６いずれか１項記載の方法。
8. 前記端末機器は、伝送される診断コマンドを車両ネットワークに対して変化し、生成された応答メッセージを移動無線インタフェースに転送する、請求項１から７いずれか１項記載の方法。
9. 診断プロトコルとしてＫＷＰ２０００若しくはそれに基づく応用方式が用いられる、請求項１から８いずれか１項記載の方法。
10. 車両に係るテレマチックサービスのための装置であって、中央コンピュータ（サーバー）と端末機器を有しており、該端末機器は、有利には自動車内部に配設されており、前記中央コンピュータ（サーバー）と端末機器との間で通信接続が形成される形式の装置において、
    テレマチックサービスが部分機能性に分割されており、
    前記部分機能性は、再びサーバーと端末機器に対して分割されていることを特徴とする装置。
11. 車両に係るテレマチックサービスのための装置であって、中央コンピュータ（サーバー）を有しており、該中央コンピュータ（サーバー）は、端末機器と通信接続を形成する形式の装置において、
    テレマチックサービスが部分機能性に分割されており、この場合時間的に余裕のある機能性がサーバー内で実行されるように構成されていることを特徴とする装置。
12. 車両に係るテレマチックサービスのための装置であって、有利には自動車内に配設された端末機器を有しており、該端末機器は中央コンピュータ（サーバー）と通信接続を形成する形式の装置において、
    テレマチックサービスが部分機能性に分割されており、この場合時間的に余裕のない機能性が端末機器内で実行されるように構成されていることを特徴とする装置。
13. サーバーがエアーインターフェースを介して端末機器と通信され、前記テレマチックサービスは、自動車の遠隔診断であり、この場合診断プロトコルが、時間的に余裕のある部分機能性としてサーバー内で実行される、請求項１０または１１記載の装置。
14. 端末機器がエアーインターフェースを介してサーバーと通信され、該サーバーはさらなるインターフェースを含んでおり、該さらなるインタフェースを用いて、診断すべきユニットとの接続が形成され、前記端末機器は、時間的に余裕のない部分機能性としてシーケンス制御機能を含んでおり、該シーケンス制御機能は、中央コンピュータに対して自立的でありかつ車両において診断通信を維持するものである、請求項１０または１２記載の装置。
15. 請求項１から９いずれか１項記載の方法の全てのステップを実施するためのプログラムコード手段を備え、コンピュータ上で実施されることを特徴とするコンピュータプログラム。
16. 請求項１から９いずれか１項記載の方法の全てのステップを実施するために、コンピュータで読出し可能なデータ担体上に記憶されているプログラム手段を備え、コンピュータ上で実施されることを特徴とするコンピュータプログラム製品。

Images