(57)【要約】車両に配置されて、少なくとも１つの車両動作特性に対応するデータを送受信する車載装置と、車載装置を介して取得した少なくとも１つの車両動作特性に対応するデータを処理する関連機能を有する複数のモジュラアプリケーションと、カスタマイズシステムを作り出すために複数のモジュラアプリケーションの中から選択を行うことを可能にするインターフェースとによって構成される、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行うシステムおよび方法。
2005520725.tif 000002
【特許請求の範囲】
【請求項１】
車両に配置されて、少なくとも１つの車両動作特性に対応するデータを送受信する車載装置と、前記車載装置を介して取得された前記少なくとも１つの車両動作特性に対応するデータを処理する関連機能を有する複数のモジュラアプリケーションと、カスタマイズシステムを作り出すために前記複数のモジュラアプリケーションの中から選択を行うことを可能にするインターフェースとによって構成される、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行うシステム。
【請求項２】
前記車載装置は、前記車載装置と前記車載装置の外にある少なくとも１つの装置間の通信をサポートする少なくとも１つの車載装置インターフェースと、前記少なくとも１つのインターフェースを介して前記車載装置により送受信されるデータを管理するプロセッサと、前記プロセッサに連結されたメモリとを備えることを特徴とする請求項１に記載のシステム。
【請求項３】
前記少なくとも１つの車載装置インターフェースは、無線通信システムとの通信をサポートする無線インターフェースと、車両データバスを介した少なくとも１つの車両構成要素との通信をサポートする車両インターフェースと、ユーザとの通信をサポートするユーザインターフェースと、ドライバインターフェースと車載装置のうちの少なくとも１つとの通信をサポートするシリアル・インターフェースと、グローバル・ポジショニング・システム（ＧＰＳ）装置との通信をサポートするグローバル・ポジショニング・インターフェースとからなるグループから選択される少なくとも１つのインターフェースであることを特徴とする請求項２に記載のシステム。
【請求項４】
前記車両インターフェースは、前記プロセッサと前記車両データバス間のアプリケーション非特定接続を処理するデータパーサー／リクエスタモジュールと、前記プロセッサと前記車両データバス間のアプリケーション特定接続を処理する前記データパーサー／リクエスタモジュールに連結するアプリケーション特定モジュールとからなるグループから選択される少なくとも１つを含むことを特徴とする請求項３に記載のシステム。
【請求項５】
前記モジュラアプリケーションは、サードパーティアプリケーションと、システム供給アプリケーションと、コアサービスとからなるグループから選択されることを特徴とする請求項１に記載のシステム。
【請求項６】
前記サードパーティアプリケーションと前記システム供給アプリケーションのうちの少なくとも１つは、少なくとも１つのコアサービスからの情報を用いて機能することを特徴とする請求項５に記載のシステム。
【請求項７】
前記コアサービスは、車両パラメータ値のセットを長期的に取得するスナップショットサービスを含むことを特徴とする請求項５に記載のシステム。
【請求項８】
前記スナップショットサービスにより、前記車載装置が、トリガイベントに関して、選択された数のパラメータ読取りをキャッシュに格納することを特徴とする請求項７に記載のシステム。
【請求項９】
前記車載装置は、選択された時間間隔で複数のパラメータ読み取りを保存することによって、前記選択された数のパラメータ読取りをキャッシュに格納することを特徴とする請求項８に記載のシステム。
【請求項１０】
前記コアサービスは、リクエストに応じて少なくとも１つの車両コントローラ値を出力する保存値取得サービスを含み、リクエスト時に車両コントローラが利用可能である場合は現在の車両コントローラ値を出力し、リクエスト時に車両コントローラが利用不可である場合は前記車載装置に保存されている車両コントローラ値を出力することを特徴とする請求項５に記載のシステム。
【請求項１１】
前記保存値取得サービスは、選択された時間間隔で車両コントローラ値を収集し、一番最近の車両コントローラ値を、車両コントローラ現在値として保存することを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記コアサービスは、応答形（solicited）フォルトと任意形(unsolicited)フォルトのうちの少なくとも１つを検出するアラートサービスを含むことを特徴とする請求項５に記載のシステム。
【請求項１３】
前記アラートサービスは、フォルトをフィルタし、ユーザにより応答されたフォルトのみを出力することによって応答形フォルトを検出することを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記アラートサービスは、個々のフォルトを追加および削除する機能と、アラートが発された後、所定フォルトに対する前記アラートサービスをキャンセルする機能と、パラメータが選択された時間の間選択されたしきい値を超過した後にアラートを発する機能と、セーブされたパラメータと現在パラメータとを比較して盗難を検知する機能とからなるグループから選択された少なくとも１つの機能を含むことを特徴とする請求項１２に記載のシステム。
【請求項１５】
前記コアサービスは、リクエストに応じて、少なくとも１つの車両パラメータを変更するパラメータ変更サービスを含むことを特徴とする請求項５に記載のシステム。
【請求項１６】
前記インターフェースは、ヒューマンユーザとのインタラクションをサポートするユーザインターフェースと、マシン同士のインターフェースとからなるグループから選択された少なくとも１つのインターフェースであることを特徴とする請求項１に記載のシステム。
【請求項１７】
前記ユーザインターフェースは、グラフィカルユーザインターフェースであることを特徴とする請求項１６に記載のシステム。
【請求項１８】
さらに、前記モジュラアプリケーションを介して前記車載装置を前記インターフェースに接続するサーバを備えることを特徴とする請求項１に記載のシステム。
【請求項１９】
前記サーバは、前記モジュラアプリケーションを定義するロジックを含むウェブ／アプリケーションサーバと、前記モジュラアプリケーションと前記車載装置間のトランスレータとして機能する車両サーバと、無線ネットワークを介して通信をサポートする通信サーバと、前記車両の関連情報を保有する少なくとも１つの関連データテーブルを含むデータベースサーバとからなるグループの少なくとも１つを含むことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記サーバと前記モジュラアプリケーションの少なくとも１つは、アプリケーションサービスプロバイダ（ＡＳＰ）インフラストラクチャを形成することを特徴とする請求項１８に記載のシステム。
【請求項２１】
前記複数のモジュラアプリケーションは、遠隔診断アプリケーションを含むことを特徴とする請求項１に記載のシステム。
【請求項２２】
前記複数のモジュラアプリケーションは、リース車両管理アプリケーションを含むことを特徴とする請求項１に記載のシステム。
【請求項２３】
前記複数のモジュラアプリケーションは、遠隔診断アプリケーションと、リース車両管理アプリケーションと、燃料効率アプリケーションと、車両位置アプリケーションと、トリップリポーティングアプリケーションと、エンジン管理アプリケーションと、メンテナンスアラートアプリケーションと、車両コンフィギュレーションアプリケーションと、保証管理アプリケーションとからなるグループから選択された少なくとも１つのアプリケーションを含むことを特徴とする請求項１に記載のシステム。
【請求項２４】
前記複数のモジュラアプリケーションのうちの少なくとも１つは、同一車両にある少なくとも２つの車両コントローラ間のデータを関連付けることを特徴とする請求項１に記載のシステム。
【請求項２５】
前記複数のモジュラアプリケーションの少なくとも１つは、前記インターフェースを介して送信される１つのコマンドにより複数の車両に対して設定を構築することを特徴とする請求項１に記載のシステム。
【請求項２６】
車載装置と前記車載装置の外にある少なくとも１つの装置間の通信をサポートする少なくとも１つの車載装置インターフェースと、前記少なくとも１つのインターフェースを介して前記車載装置により送受信されるデータを管理するプロセッサと、前記プロセッサに連結されたメモリとによって構成され、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行うシステムにおいて使用する、車両に配置される車載装置。
【請求項２７】
前記少なくとも１つの車載装置インターフェースは、無線通信システムとの通信をサポートする無線インターフェースと、車両データバスを介した少なくとも１つの車両構成要素との通信をサポートする車両インターフェースと、ユーザとの通信をサポートする車載ユーザインターフェースと、ドライバインターフェースと車載装置のうちの少なくとも１つとの通信をサポートするシリアル・インターフェースと、グローバル・ポジショニング・システム（ＧＰＳ）装置との通信をサポートするグローバル・ポジショニング・インターフェースと、からなるグループから選択された少なくとも１つのインターフェースであることを特徴とする請求項２６に記載の車載装置。
【請求項２８】
前記車両インターフェースは、前記プロセッサと前記車両データバス間のアプリケーション非特定接続を処理するデータパーサー／リクエスタモジュールと、前記プロセッサと前記車両データバス間のアプリケーション特定インターフェースを処理する前記データパーサー／リクエスタモジュールに連結したアプリケーション特定モジュールと、からなるグループから選択された少なくとも１つを含むことを特徴とする請求項２７に記載の車載装置。
【請求項２９】
車両に配備された車載装置から、少なくとも１つの車両動作特性に対応するデータを取得するステップと、ユーザにより選択可能な複数のモジュラアプリケーションを提供してカスタマイズシステムを作り出すステップと、少なくとも１つの選択されたモジュラアプリケーションに関連する少なくとも１つの機能に従って、前記車載装置を介して得られた少なくとも１つの車両動作特性に対応するデータを処理するステップとからなる、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行う方法。
【請求項３０】
さらに、車両パラメータ値のセットを長期的に取得するステップを含むことを特徴とする請求項２９に記載の方法。
【請求項３１】
前記取得ステップは、トリガイベントを検出するステップと、トリガイベントに関して、選択された数のパラメータ読取りをキャッシュに格納するステップを含むことを特徴とする請求項３０に記載の方法。
【請求項３２】
前記キャッシュに格納するステップは、選択された時間間隔で複数のパラメータ読取りを保存するステップを含むことを特徴とする請求項３１に記載の方法。
【請求項３３】
さらに、車両コントローラ値のリクエストを検出するステップと、リクエスト時に車両コントローラが利用可能である場合は現在の車両コントローラ値を出力するステップと、リクエスト時に前記車両コントローラが利用不可である場合には、保存されている車両コントローラ値を出力するステップと、を含むことを特徴とする請求項２９に記載の方法。
【請求項３４】
さらに、選択された時間間隔で車両コントローラ値を収集するステップと、一番最近の車両コントローラ値を車両コントローラ現在値として保存するステップとを含むことを特徴とする請求項３３に記載の方法。
【請求項３５】
さらに、応答形フォルトと任意形フォルトのうちの少なくとも１つを検出するステップと、前記検出ステップの後、アラートを発するステップと、を含むことを特徴とする請求項２９に記載の方法。
【請求項３６】
応答形フォルトの検出ステップは、フォルトをフィルタし、ユーザにより応答されたフォルトのみを出力するステップを含むことを特徴とする請求項３５に記載の方法。
【請求項３７】
さらに、個々のフォルトを追加および削除するステップと、アラートが発された後、所定フォルトに対するアラートサービスをキャンセルするステップと、パラメータが選択された時間の間選択されたしきい値を超過した後にアラートを発するステップと、セーブされたパラメータと現在のパラメータとを比較して盗難を検知するステップとからなるグループから選択された少なくとも１つのステップを有することを特徴とする請求項３５に記載の方法。
【請求項３８】
リクエストに応じて少なくとも１つの車両パラメータを変更するステップをさらに含むことを特徴とする請求項２９に記載の方法。
【請求項３９】
さらに、前記モジュラアプリケーションと前記車載装置間のデータをトランスレートするステップを含むことを特徴とする請求項２９に記載の方法。
【請求項４０】
前記提供するステップは、遠隔診断アプリケーションを提供するステップを含むことを特徴とする請求項２９に記載の方法。
【請求項４１】
前記提供するステップは、リース車両管理アプリケーションを提供するステップを含むことを特徴とする請求項２９に記載の方法。
【請求項４２】
前記提供するステップは、遠隔診断アプリケーションと、リース車両管理アプリケーションと、燃料効率アプリケーションと、車両位置アプリケーションと、トリップリポーティングアプリケーションと、エンジン管理アプリケーションと、メンテナンスアラートアプリケーションと、車両コンフィギュレーションアプリケーションと、保証管理アプリケーションと、からなるグループから選択された少なくとも１つを提供することを特徴とする請求項２９に記載の方法。
【請求項４３】
さらに、同一車両にある少なくとも２つの車両コントローラ間のデータを関連付けるステップを含むことを特徴とする請求項２９に記載の方法。
【請求項４４】
前記複数のモジュラアプリケーションの少なくとも１つは、前記インターフェースを介して送信される１つのコマンドにより複数車両に対して設定を構築することを特徴とする請求項２９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の参照）
本出願は、同一出願人により、2000年8月18日に出願された、「遠隔車両診断、モニタリング、コンフィギュレーション、および再プログラミングを行うシステム、方法、およびコンピュータプログラム製品」（粘ystem, Method and Computer Program Product for Remote Vehicle Diagnostics, Monitoring, Configuring and Reprogramming煤jと称する同時係属米国特許出願番号０９／６４０，７８５の、ブロムリー他への利益の請求を行っている一部継続出願である。これの開示内容全体を本明細書に引用したものとする。
【０００２】
本発明は、概ねコンピュータデータおよび情報システムに係り、さらに詳細には車両情報を保存、処理、および表示するコンピュータツールに関する。
【背景技術】
【０００３】
会社が、数多くの、あるいは一群の商業用自動車を所有することは一般的である。そうした会社の典型的な例には、乗用車リース会社および旅客車両のみならず、商業用国際宅配便、引越会社、運送会社およびトラック運送会社、トラックリース会社が含まれる。利益維持のため、車両フリートを所有する会社は車両整備や修理に費やす時間を理想的に最小限に抑える。最適な車両性能を維持するためには、しばしば車両を業務からはずして故障分析、定期整備、診断モニタリング、およびパラメータ修正を行う必要がある。
【０００４】
さらに、車両構成部品を製造する会社は、構成部品が車両に取り付けられた後に、製品改良、保障サービス、診断、および他の部品データに関する情報にアクセスするための中央データベースを望むかもしれない。異なる会社および異なる産業においては、ニーズを収集し、リポートする異なる車両データを有していることから、現状の解決法においては特定のユーザアプリケーションごとに専用システムを構築する必要がある。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
車両データのカスタマイゼーションに異なるユーザの異なるニーズを適応させながら、車両および／または車両部品をモニタ、構成、プログラム、および診断することの可能なシステムが求められている。
【課題を解決するための手段】
【０００６】
したがって、本発明の一実施形態によれば、車両に配置されて、少なくとも１つの車両動作特性に対応するデータを送受信する車載装置と、車載装置を介して取得した少なくとも１つの車両動作特性に対応するデータを処理する関連機能を有する複数のモジュラアプリケーションと、カスタマイズを作り出すために複数のモジュラアプリケーションの中から選択を行うことを可能にするインターフェースとによって構成される、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行うシステムが提供される。
【０００７】
本発明の別の実施形態によれば、車載装置と車載装置の外にある少なくとも１つの装置間の通信をサポートする少なくとも１つの車載装置インターフェースと、この少なくとも１つのインターフェースを介して車載装置により送受信されるデータを管理するプロセッサと、プロセッサに連結されたメモリとにより構成される、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行うシステムにおいて使用する、車両に配置される車載装置が提供される。
【０００８】
本発明のさらなる実施形態によれば、車両に配備された車載装置から少なくとも１つの車両動作特性に対応するデータを取得するステップと、ユーザにより選択可能な複数のモジュラアプリケーションを提供してカスタマイズシステムを作り出すステップと、少なくとも１つの選択されたモジュラアプリケーションに関連する少なくとも１つの機能に従って、車載装置を介して得た少なくとも１つの車両動作特性に対応するデータを処理するステップとからなる、少なくとも１つの車両のモニタリング、構成、プログラミング、および／または診断オペレーションを行う方法が提供される。
本発明のさらなる実施形態およびそのバリエーションが図面および以下に記載の詳細説明によって明らかとなろう。
【発明を実施するための最良の形態】
【０００９】
システムの機能性とアーキテクチャ
図１は、本発明の一実施形態に従った車両モニタリングおよび診断システム１００の典型的な機能図である。一般的に、本発明のシステム１００は、ユーザのカスタマイズされた仕様に従いデータを表示およびコントロールすることによって、車両フリートのモニタリングおよび調整を可能にする。システム１００は、コアデータおよびサービスと交信するモジュラアプリケーションで設計されており、それにより車両パラメータは特定のユーザおよび／または特定の産業に有意なフォーマットでモニタ、分析、かつ表示がなされ得る。異なるユーザおよび／または産業の異なる車両データ要求にもかかわらず、こうした柔軟性によって異なるユーザかつ／または産業が、車両および構成要素のモニタリングのために同一の全体システム１００を使用することが可能となる。
【００１０】
図を参照に説明すると、システム１００には、複数の車両１０４間のゲートウェイとして機能するアプリケーションサービスプロバイダ（ＡＳＰ）インフラストラクチャ１０２が備わり、各車両には付随の車載コンピュータ（例えば車載装置、すなわち“ＯＢＵ”１０５）とカスタマイズ可能インターフェース１０６とが配備されている。インターフェース１０６により、オリジナルのシステム供給アプリケーション１１０同様、車両１０４から様々なデータを得て、分析することが可能となる。サードパーティアプリケーション１０８などの様々なアプリケーションの中から、ユーザもしくはマシン１０６ａが選択を行い、フリートマネージャにリアルタイムのドライバ／フリート通知を提供させるのみならず、例えば、リアルタイムのフリート特徴、傾向分析、および診断を得るためのツールをアプリケーションに含み、マニュアル、動的、またはルールベースコンフィギュレーションを実行することも可能である。ユーザが、ユーザ特定アプリケーションに有意なデータを確実に受け取ることができるよう、ユーザにより選択されたアプリケーションを操作するようにユーザインターフェース１０６をカスタマイズすることができる。図１に示した例において、異なるタイプのユーザ１０６ａは、彼等自身のビジネスに適用可能なニーズをモニタリングかつリポーティングする詳細データを適応させるよう、カスタマイズアプリケーショングループ１１２のような異なるアプリケーションを選択することが出来る。
【００１１】
例えば、図１に示しているように、ディーラ／修理施設は、提供されたアプリケーション１０８、１１０から、そのアプリケーショングループ１１２として、車両コンフィギュレーション、定期的整備、遠隔診断、およびコンシェルジュサービスを選択するかもしれず、一方、トラック製造者は、保障サービス／キャンペーンサポート、車両履歴、およびガイド診断など、アプリケーション１１２の異なる収集を選択するかもしれない。特定のユーザのニーズに従って選択および組合わせ可能な様々なモジュラアプリケーション１０８、１１０を提供することにより、インフラストラクチャ１０２自体をほとんど、あるいは全く修正することなく、同一インフラストラクチャ１０２をカスタマイズすることが可能であり、異なるユーザが異なる目的に使用することが可能となる。さらに、ユーザが、システム供給アプリケーション１１０のような同一インフラストラクチャによってサードパーティアプリケーション１０８にアクセスすることが可能となることによって、システム１００それ自体では提供し得ないサービスをシステム１００が利用可能となり、さらにフレキシビリティと適応性とを増す。
【００１２】
さらに、ＡＳＰベースモデルを使用する本発明のシステムの実施形態において、アプリケーションサービスプロバイダはインターネットを介して、加入者ベースで、遠隔車両診断、モニタリング、コンフィギュレーション、および再プログラミングツールへのアクセスを提供し、これを可能にする。すなわち、アプリケーションサービスプロバイダは、ハードウェア（例えば、サーバ、車載コンピュータ）およびソフトウェア（例えばデータベース）インフラストラクチャ、アプリケーションソフトウェア、顧客サポート、および請求メカニズムを提供し、その顧客（例えばフリートマネージャ、車両販売会社、車両ディーラ、相手先商標製品の製造会社（ＯＥＭ）、リース／レンタル会社など）がフリート内の車両に遠隔アクセスを行うのを可能にする。加入者がモジュラアプリケーション１０８、１１０を選択、かつアクセスする際にはツールを使用することができる。
【００１３】
ＡＳＰベースモデルでは、ソフトウェアをユーザに物理的に供給する必要がなくなることに注目されたい。代わりにシステムがアプリケーションサーバに備わり、サーバで実行するため、新規フューチャおよび更新を即座にユーザに提供することが可能となる。一実施形態において、アプリケーションサーバにはないアプリケーションはＯＢＵ１０５に備えることができる。車両インストレーションの間、車載装置アプリケーションをＯＢＵ１０５にロードすることが可能であり、無線ネットワーク接続を介して追加のアプリケーションもしくはアプリケーション更新をＯＢＵ１０５にダウンロードすることが可能である。
【００１４】
図２は、本発明の一実施形態に従ったシステムアーキテクチャ２００の典型的なブロック図である。図２に示したシステムアーキテクチャは、図１に示した上記説明の機能を実行するための１つの可能な方法である。本例において、アーキテクチャは、インターフェース１０６、サーバ２０２、および車載装置（ＯＢＵ）１０５などの、３つの主要な構成要素を含む。３つの構成要素１０６、２０２、１０５の全ては、無線ネットワーク２０６を介するなどの既知の手段により相互に通信を行うように設計されている。
【００１５】
インターフェース１０６は、人やマシンをインフラストラクチャ１０２にアクセス可能にする、例えば、ユーザインターフェースおよび／またはマシンインターフェースであり、サーバ２０２を含んでいる。サーバ２０２は、例えば、ウェブページホスティングの実行、アプリケーションの実行、データ格納の実行、および／または無線通信ネットワーク管理を行う一連のサーバを含む。この例において、サーバ２０２は、ウェブ／アプリケーションサーバ２０２ａ、車両サーバ２０２ｂ、および通信サーバ２０２ｃを含み、これら全てはデータベースサーバ２０２ｄとリンクしている。図に示すように、サーバ２０２は、ＯＢＵ１０５を有するウェブベースクライアント（ユーザ）１０６間のリンクとして機能し、インターネット２１０もしくは他のインターネットワーキングシステムを介して、車両データストリームへのユーザアクセスかつコントロールを可能にする。
【００１６】
ＯＢＵ１０５は様々な車両構成要素からのデータにアクセスし、それ自身の車両データを生成してサーバ２０２に供給することも可能である。ＯＢＵ１０５は、無線ネットワークへの通信リンクを提供する無線通信モジュール１０５ａと、車両構成要素から得たデータを処理する車両データ処理モジュール１０５ｂと、例えば車両データバスに接続した車両インターフェース１０５ｃとを備え、電子制御装置などの車両システムにより、時間あるいは工程クリティカル機能を処理および管理するための車両構成要素からデータを集める。ＯＢＵ１０５は、グローバル・ポジショニング・システムおよびドライバディスプレイインターフェースも備え得る。
システムアーキテクチャ構成要素の各々については以下においてより詳細なる説明を行う。
【００１７】
インターフェース
インターフェース１０６は標準的なブラウザインターフェースおよび／またはマシン同士のインターフェースである。ブラウザインターフェースにおいて、ヒューマンユーザは標準的なウェブブラウザを介してシステムにアクセスを行う。一実施形態において、ユーザはログインおよびパスワード認証後に、その特定の一式の認可車両および機能にアクセスを行うことが可能となる。マシン同士のインターフェースにおいては、サーバおよび車両データおよび機能は、保護アプリケーションプログラムインターフェース（ＡＰＩ）を介してアクセス可能となる。マシン同士のインターフェースは、システム１００の機能への他アプリケーションのアクセスを可能にし、それにより、車両およびシステムによって提供される機能に遠隔アクセスを行うことが可能となる。これにより、システム１００が、既存の、もしくは計画されたバック・オフィスアプリケーションおよびオペレーションとインターフェースをとることが可能となり、システム１００を例えば全フリートオペレーションあるいは他のシステムとの統合に適したものにする。
【００１８】
サーバ
サーバシステムはシステムの固定をベースとした構成要素であり、上記に説明を行ったように、サーバシステムはインターネットベースシステムであり、ＡＳＰモデルを使用する。エンドユーザは、市販のウェブブラウザのようなインターフェース１０６からシステムにアクセスを行うことが可能である。上で述べたように、本実施形態におけるサーバ２０２は、ウェブアプリケーションサーバ２０２ａ、車両サーバ２０２ｂ、通信サーバ２０２ｃ、およびデータベースサーバ２０２ｄを含む。これら各々については以下にてより詳細なる説明を行う。
【００１９】
ウェブアプリケーションサーバ２０２ａはエンドユーザへの１つ以上のアプリケーションを定義するロジックを含む。特定ユーザアプリケーションに必要な全データは無線通信ネットワーク２０６を介してリクエストされ、ＯＢＵ１０５に送られる。以下においてさらなる詳細を説明するように、アプリケーションは必要な計算を実行し、それからユーザに規定のフォーマットで提示するために結果をパッケージする。さらに、ウェブアプリケーションサーバ２０２は、ユーザアクティビティに関連するビジネスアプリケーションの実行を担う。これには、ビジネスロジックの実行と、フリート、車両、構成要素、トランザクションアクティビティのシステムデータベースとのインターフェースと、知識ベース格納と、車両サーバ２０２ｂおよび通信サーバ２０２ｃへのユーザリクエスト車両問合せまたは機能の送信とを含む。
【００２０】
サーバ２０２の車両サーバ２０２ｂは車両詳細データの保存および処理を行い、アプリケーション１０８、１１０と特定の車両かつ／または車両構成要素間のトランスレータとして機能する。さらに詳しく述べると、車両サーバ２０２ｂはデータリクエストと車両回答の処理を担い、アウトバウンドデータおよびインバウンドデータをトランスレート車両情報に変換する。
【００２１】
車両サーバ２０２ｂはインターフェース１０６からのユーザリクエストを、リクエストが導かれる車両１０４に特定のフォーマットに変換する。車両サーバ２０２ｂはユーザインタラクションあるいはプロパティ選択を行わずにこの変換を履行する。例えば、車両サーバ２０２ｂは、特定の車両に送られるメッセージを評価し、車両タイプ、車両バスタイプ、および、メッセージの受信者とみなされる車両構成要素およびサブ構成要素を検出する。次に車両サーバ２０２ｂは、受信者構成要素により命じられた特定の通信プロトコルに従ってメッセージをパッケージする。結果的に、車両サーバ２０２ｂは、所定ユーザおよびアプリケーションに対して、同一インターフェース１０６による、異なる構成要素を有する異なる車両のモニタリングとコントロールとを可能にする。
【００２２】
図２に示すように、本発明のシステムの一実施形態においては、衛星または地上波ベースネットワークなどの無線ネットワークにより、少なくとも車両１０４とサーバ２０２間の通信を可能にする。通信サーバ２０２ｃがサーバ２０２に含まれ、無線通信をサポートし、かつ無線技術における変化および改良をサポートする中央ロケーションを提供する。一実施形態において、通信サーバ２０２ｃは、ＯＢＵ１０５と車両サーバ２０２ｂ間の通信アクティビティを管理し、かつ、ＯＢＵ１０５とサーバ２０２ｂ間の車両／構成要素詳細リクエストを処理する。
【００２３】
一実施形態において、通信サーバ２０２ｃは、サーバ２０２と車両１０４間の通信リンクを可能にする無線通信フレームワークを使用する。無線移動通信システムは本発明のシステム１００において使用可能であるが、複数のプラットフォームおよび／または複数の通信プロバイダを処理することの可能なフレキシブル無線通信インフラストラクチャが望ましい。このようなフレームネットワークの可能な一実施例が、２００２年１月２３日に出願された、「無線通信フレームワーク」（埜ireless Communication Framework煤jと称する、米国特許仮出願番号第６０／３５１，１６５号（代理人登録番号６５８５５−００６０）に記載されている。これの開示内容全体を本明細書に引用したものとする。
【００２４】
複数通信プロバイダおよび／またはプラットフォームを処理するために、フレキシブル無線通信インフラストラクチャは、メッセージサイズ、メッセージフォーマット、および特定プロトコル詳細など、特定の無線通信プロバイダのニーズを、複数システムおよびプラットフォームにより理解可能な標準メッセージ通信ＡＰＩにして取り出す。一実施形態において、通信サーバ２０２ｃはメッセージを抽出し、かつ、メッセージの保存、転送を行い、一時的に無線通信のサービスエリア外にいる車両に対して、後に確実にメッセージ配信を行う。また、通信サーバ２０２ｃは、費用および／またはメッセージの重要度に基づきメッセージルーティングの優先順位をつける目的にて、複数無線ネットワークから選択を行う最少費用ルーティングルールを含むことでさえ可能である。
【００２５】
サーバ２０２はまた、ユーザ、車両、フリート、システムトランザクション履歴、および所定車両１０４に関連する他の関係などに関連した情報を保有するよう設計された関連データテーブルを含んだデータベースサーバ２０２ｄを備える。データベースサーバ２０２ｄはまた、ＯＢＵ１０５とサーバ２０２間のトランザクションのような、車両トランザクションの結果から得られるデータを保有するようにも設計可能である。一実施形態において、認可されたユーザが、例えばフリート所有者、リースフリート、車両製造者、および構成部品製造者により、多くの方法で車両へのアクセスが可能であるようにデータベースは構成される。この構成により、システム１００が、こうした受益者各々に詳細なカスタマイズデータを提供することが可能となり、各ユーザに有意なフォーマットでのアクセスを可能にする。
【００２６】
車載装置（ＯＢＵ）
上に述べたように、ＯＢＵ１０５により、車両サイドの、リアルタイム計算ベースをシステムにもたらす。一実施形態において、ＯＢＵ１０５は、データストリーム処理、離散計測、車両位置情報、無線通信、およびデータのリアルタイム分析を担う。システムの全体フレームワーク内で、ＯＢＵ１０５は車両サーバとして機能し、車両詳細データおよび機能を提供する。一実施形態において、ＯＢＵ１０５は、異なる構成部品仕様およびニーズを有する多種多様な車両に配備するように設計、製造された拡張可能カスタムハードウェアプラットフォームであり、かつ、他への車両データゲートウェイとして機能しながら、好ましくは複数アプリケーションを実行可能とする。
【００２７】
図３（Ａ）および（Ｂ）は、ＯＢＵ１０５の典型的なハイレベル・ブロック図である。ＯＢＵ１０５の一実施形態においては、無線ネットワーク２０６を介しＯＢＵ１０５とサーバ２０２間の通信を制御する無線インターフェース３０２、そして、例えば電子制御装置（ＥＣＵ）、車両コントローラ、および／または他の車両構成要素３０８への伝送、かつこれらからの受信をＯＢＵ１０５が行うことを可能にする車両インターフェース３０４、そして、ユーザ読取りを可能にする、かつ／またはＯＢＵ１０５への情報入力を可能にするオプショナルユーザインターフェース３０６などの、１つ以上のインターフェース３０２、３０４、３０６と、データプロセッサ３００とを備える。
【００２８】
一実施形態において、無線インターフェース３０２は、サーバ２０２からのデータをＯＢＵ１０５に送信し、かつ、ＯＢＵ１０５から受信を行う。そして、異なる無線ネットワーク装置から通信を抽出し、サーバ２０２に関して上述したようなタイプのフレキシブル無線通信インフラストラクチャとＯＢＵ１０５との通信を可能にする。さらに詳細に述べると、無線インターフェース３０２は、様々な無線ネットワーク装置におけるプロトコルの相違をカプセル化して、プロセッサ３００に標準出力を供給する。一実施形態において、無線ネットワークメッセージはエラーチェックおよびフィルタリングのためにサーバ２０２から無線インターフェース３０２に送られる。フィルタリングの後、コマンドはプロセッサ３００に渡され、それからそれぞれの車両構成要素に送られる。
【００２９】
プロセッサ３００は、無線インターフェース３０２を介したサーバ２０２と車両１０４間におけるリクエストの送受信を管理することによってＯＢＵ１０５の中央処理装置（ＣＰＵ）としての機能を果たす。一実施形態において、プロセッサ３００はロジックおよび知能を有し、診断リクエストおよび処理などの車両特有サービスを実行する。例えば、プロセッサ３００は、ＯＢＵのメモリ３１５、３１６、３１８内にロードされている特定のアプリケーションを実行し、かつ、車両データストリーム、ＧＰＳ装置、無線通信、および遠隔サーバ２０２間のアクティビティを調整する。さらに、一実施形態において、プロセッサ３００は無線ネットワークを介してアップデートされ、その機能性を追加、向上させる。この能力により、フューチャおよび機能性を向上させるソフトウェアアップデートのために車両をサービスベイに配置する必要がなくなる。
【００３０】
車両インターフェース３０４によりＯＢＵ１０５が多種多様な車両構成要素およびサブ構成要素をサポートすることが可能となる。ＯＢＵがサポートすることの可能なインターフェースに、ＳＡＥＪ１７０８、ＳＡＥＪ１９３９、ＳＡＥ  ＯＢＤ II／ＣＡＮ、ＩＳＯ−９１４１、離散Ｉ／Ｏ、プリプライエタリインターフェース、および他のインターフェース（例えば、離散あるいは計装用インターフェース）を含む。さらに、車両インターフェース３０４は、車両１０４の全車両構成要素および制御装置に対して１つのコンタクトポイントを提供し、衛星ベース通信システムなどの無線通信装置と同様、車両の実際のデータバスラインによるＯＢＵソフトウェア間の通信を可能にする。
【００３１】
一実施形態において、車両インターフェース３０４はデータパーサー／リクエスタモジュール３１０を備えており、データパーサー／リクエスタモジュール３１０は、より詳細には以下に説明を行うように、アプリケーション非特定（すなわち、「一般的」ＳＡＥＪ１７０８またはＳＡＥ１９３９離散計測ポイント）パラメータ読取り、アラート、コンフィギュレーション、あるいは再プログラミングデータのために、プロセッサ３００と車両データバス３０７間のダイレクトインターフェースを処理する機能も果たすソフトウェアコードロジックを含む。
【００３２】
車両インターフェース３０４は、アプリケーション特定パラメータ読取り、アラート、コンフィギュレーション、または再プログラミングデータのために、プロセッサ３００と車両データバス３０７間のインターフェースを処理する機能を果たすソフトウェアコードロジックを各々が含んだ、車両１０４内の各製造者特定コントローラ３０８のための１つであるような、例えば１つ以上のアプリケーション特定モジュール３１２を含む場合もある。
【００３３】
ＯＢＵ１０５は、データを直接的に車両データバス３０７に置くアプリケーションのサーバかつ／あるいはデータゲートウェイとして機能することに注意されたい。一実施形態において、ＯＢＵ１０５はデータゲートウェイの構成要素として、ＴＭＣ  ＲＰ  １２１０Ａなどのインターフェース規格を使用する。使用される特定の規格に関わらず、データゲートウェイとしてＯＢＵ１０５を使用するアクティビティはいずれもプロセッサ３００を通過するデータを必要とする。
【００３４】
本発明の実施形態において、ＯＢＵ１０５は、車両１０４内に含まれる（あるいは取付けされる）構成要素であることから、SAE's Joint SAE/TMC Recommended Environmental Practices for Electronic Equipment Design(Heavy-Duty Trucks)、文書番号Ｊ１４５５（１９９４年８月）規格に準拠するように設計されている。これの全体内容をここに引用したものとする。上記にて指摘しているように、ＯＢＵ１０５は特定の規格に準拠するようには制限されておらず、所定の車両電子システムにどの規格が使用されていても、システム１００がコマンドをインターフェース１０６とＯＢＵ１０５間で変換可能であるかぎり、どのサブシステム（例えば、エンジン、トランスミッション、ブレーキシステム、インストルメント・クラスタ等）も車載電子システム規格（例えばＳＡＥＪ１７０８、ＳＡＥＪ１９３９、ＳＡＥＪ１８５０、ＩＳＯ９１４１、プロプライエタリデータストリーム等）に対応可能である。車両電子システムが例えばプロプリエタリスタンダードを使用する場合、ＯＢＵ１０５上の車両サーバ２０２ｂおよびその関連のアプリケーション特定モジュール３１２はプロプリエタリスタンダードに対応するように構成される。
【００３５】
図３（Ｂ）は、ＯＢＵ１０５の別の実施形態を示したものであり、例えば、並列インターフェース、直列インターフェース、ユニバーサル・シリアル・バス（ＵＳＢ）、衛星、地上波無線（例えば８０２．１１ｂ）、および／またはグローバル・ポジショニング・システム（ＧＰＳ）を介して、他の装置とインターフェースを行う可能性を明示している。さらに詳細に述べると、図３（Ｂ）に示したＯＢＵ１０５の実施形態では、携帯端末、携帯電話、音声メッセージ・システム、データロガー、あるいは他の装置などのドライバインターフェースもしくは他の車載装置（図示せず）と通信する直列インターフェース３１４から、およびＧＰＳアンテナから信号を受取るＧＰＳ回路３１３を含む。図３（Ｂ）ではまた、車両バッテリおよびイグニションスイッチ（図示せず）に連結する電源のみならず、フラッシュメモリ３１５、ダイナミックランダムアクセスメモリ３１６、そして、プロセッサ３００に連結するオプショナルコンパクトフラッシュ（登録商標）メモリ３１８を明示している。図３（Ａ）および（Ｂ）に示した構成要素およびコンセプトが、本発明の範囲を逸脱することなく、いかなる方法においても組合せされ得ることは従来技術において明らかである。
【００３６】
アプリケーションソフトウェアおよびアプリケーションフレームワークはソフトウェアとハードウェア抽象層の両方により構築される。このアプローチはフレームワークを数多くの別のオペレーティングシステムや別のハードウェアプラットフォームに適合可能にする。ＯＢＵ１０５の一実施形態では既知のリアルタイムオペレーティングシステムを使用する。
【００３７】
システムオペレーション例
全体システム１００は考えられる多くのサービスおよびアプリケーションをサポートすることが可能であり、その例を以下に詳述し、図４から図８において示す。上述のように、図１および図２に示したシステム１００は、ＡＳＰベースモデルを使用するシステム１００のサービスとアプリケーション間における１つの可能な関係を示したものである。一実施形態において、車両特定オペレーションを実行するコアサービス３５０のグループがアプリケーション１０８、１１０に利用可能である。上に述べたように、アプリケーション１０８、１１０により、ユーザは、ユーザ自身の要求に基づいて、車両特定オペレーションの解釈および表示をカスタマイズすることが可能である。コアサービス３５０は、所望の方法において選択または組合せ可能なサービスのビルディングブロックとして機能し、システム１００のいずれかのアプリケーション１０８、１１０により、あるいは共にアクセスされ得る。言い換えると、アプリケーション１０８、１１０は、より基本のコアサービス３５０上の機能層として機能する。例えば、パラメトリックデータとともに車両位置を得るヘルプデスクアプリケーションによりコアサービス３５０にアクセス可能であり、またパラメトリックデータを得て機能テストを実行するサービスアプリケーションによってコアサービス３５０にアクセス可能である。システム１００はそれ自体が有してない他のアプリケーションやサービスを利用することが可能であって、かつ、それらをシステム１００自身のアプリケーションやサービスと組合わせることが可能であることから、システム１００は、多くの異なるニーズに対応可能な、フレキシブルで、かつ適応性のあるプラットフォームを提供する。
【００３８】
一実施形態において、アプリケーションは特定の機能を実行するコアサービスをアセンブルする。例えば、コアサービス３５０の１つは計測された値を捕捉し、かつ／または車両１０４におけるパラメータあるいはオペレーション設定を変更する。一方、アプリケーション１０８、１１０は、コアサービスからの情報を所定のユーザに有意なグループに編成し、処理する。例えば、サービスアウトレットは、異なるデータ、そして／またはリース団体もしくは部品製造者とは異なる方式で編成されたデータを欲するかもしれない。
【００３９】
上で述べ、かつ図１および図２において示したように、インターフェース１０６は、ヒューマンユーザをシステム１００にアクセス可能にするブラウザインターフェースあるいはグラフィックインターフェース（ＧＵＩ）、もしくはマシン同士のアプリケーションプログラミングインターフェース（ＡＰＩ）であり得る。ユーザインターフェース１０６は、アプリケーションおよびサービスを介して、システム１００をユーザと車両１０４間のゲートウェイとして機能させる。
【００４０】
上述のように、システム１００によって提供されるコアサービス３５０は、ユーザに最善にサービスし得る多様な方法にて、アプリケーションによってアセンブル可能なビルディングブロックとして機能する。可能なコアサービス３５０に以下を含む。
パラメータ：ユーザリクエストに基づいて、標準メッセージおよびプロプライエタリメッセージを含んだ離散あるいはデータストリームベース車両パラメータを得る；
【００４１】
アラート：特別なイベント発生の通知（例えば、トラブルコードの受信、あるいは許容パラメータ範囲外で発生しているパラメータ値の通知）；
機能：車両構成要素に機能テストを実施し、結果のリポートを生成する；
コンフィギュレーション：例えば１つ以上の車両パラメータを変更することにより、車両または構成要素の遠隔コンフィギュレーションを実行する；
再プログラミング：全面的な再プログラミングを行う、あるいは選択された車載コントローラの「再フラッシング」を行う；
地理的ロケーション：例えばＧＰＳシステムにより車両位置を提供する。
【００４２】
コアサービス３５０の上記リストが包括的であることを意図しない。これは、ユーザに直接提供可能な、あるいはさらなる処理のためにアプリケーションに供給可能なサービスの例にすぎない。以下の説明においては車両ＥＣＵ３０８からデータを取得することに焦点をあてているが、以下に記載するシステムおよび機能はどのような車両データにも当てはまることに注意されたい。
【００４３】
「パラメータ」サービスには、例えば車両がオフにされた際に車両データ獲得の限界をアドレスする、より高度なパラメータ検索サービスのみならず、単純なパラメータ検索サービスを含む。図４はパラメータを得る１つの単純なプロセス４００を示したものである。ブロック４０２においてＯＢＵ１０５がサーバ２０２からコマンドを受け取り、データ値を検索すると、ブロック４０４においてＯＢＵ１０５はＥＣＵ３０８に問い合わせメッセージを送り、ＥＣＵの現在の読取りを得る。ブロック４０６において一旦ＥＣＵ３０８がパラメータ値を返送すると、ブロック４０８においてＯＢＵ１０５は値を検索し、それをサーバに送る。頻繁に使用されるパラメータはパッケージされ、データ転送を行うためのより効果的な方法として、単一メッセージとしてサーバ２０２に伝送されることに注目されたい。さらに、特定のデータアイテムを得るための特定の手段は、所定ＥＣＵ３０８の特定の要求によって決定する。例えば、従来技術において公知のように、アンチロックブレーキシステムに対応するデータポイントは、エンジン冷却温度に対応するデータとは異なる方法にて得られる。
【００４４】
図５は、上記の簡単なパラメータ検索サービスよりもさらに高度な「パラメータ」サービスとして提供される１つの可能なプロセスを示したフローチャートである。パラメータデータは車両電子コントローラから簡単に読取り可能であり、要求に応じてユーザに提供可能であるが、「パラメータサービス」もまた、図５に示したタイプのような、より高度なパラメータデータ捕捉方法を提供可能とする。図５は、ある期間にわたって、一式のパラメータ値を得るための「スナップショット」プロセス５００を示したものである。ここで、パラメータ値の報告は指定のイベントによりトリガされる。車載診断ツールとしてのこのサービス提供は、間欠的故障診断および車両性能分析に特に有効である。さらに、所定の周期的間隔でのデータセットの収集は、通常、遠隔診断を無効にする、通信ドロップアウトおよび圏外などの無線通信システム特有の問題から生じる弊害を最小限とすることができる。
【００４５】
スナップショットプロセス５００を実行するために、システム１００はまず初めに、たとえば診断パラメータを格納してモニタし、パラメータ値が捕捉される時間間隔を設定し、単一リポートに含まれる捕捉値の数を選択し、そして捕捉値のリポーティングをトリガするイベントを選択することによって、ブロック５０２においてイニシャライズする。この情報はインターフェース１０６を介してＯＢＵ１０５に入力可能である。捕捉されるパラメータ値は、診断データストリームによって、またはＯＢＵ１０５の離散入力から、車両の電子コントローラにてアクセス可能なパラメータである。トリガするイベントは、車両コントローラからの、あるいは設定許容範囲外に動くパラメータからのアクティブトラブルコードの捕捉などの車両でモニタされる非継続的イベントである。
【００４６】
ＯＢＵ１０５が設定されると（ブロック５０２）、通常の車両オペレーションの間、選択された数のパラメータ読取りをキャッシュに格納することにより、ブロック５０４においてＯＢＵ１０５は多数の履歴値のセットを保持する。ＯＢＵ１０５はパラメータ読取りを捕捉する一方で、トリガイベントが生じるのを待つ。トリガイベントが生じると（ブロック５０６）、ＯＢＵ１０５はイベント後に生じる設定されたパラメータ読取りをキャッシュに格納し続ける（ブロック５０８）。履歴値のセット数は例えば最終リポートに含まれる捕捉数の半分であり、トリガイベントの後に取得された値のセット数があとの半分を構成する。別の実施形態において、ＯＢＵ１０５はトリガイベントの前または後にだけ同様にパラメータ読取りを捕捉するか、もしくはイベントの両方のサイドで異なる値の数量を捕捉することに注目されたい。
【００４７】
所望の値のセットが全て捕捉され、収集された後、イベントの前後両方で捕捉された読取りの全てが、ブロック５１０において最終リポートにコンバインされる。そのリポートは後の検索のためにＯＢＵ１０５に格納されるか、もしくは、すぐに見ることの出来るよう無線通信を通じてアプリケーションサーバ２０２ａに送信される。
【００４８】
「パラメータ」サービスとして提供され得る他の可能なプロセスは、図６に示すような、「保存値取得」（ＧＳＶ）プロセス６００であり、問い合わせ時に車両が現在のパラメータ値を提供できない場合であっても、車両からパラメータ値を収集する。ＧＳＶプロセス６００は、車両コントローラ３０８がＯＢＵ１０５によって問い合わせに応答出来ない状況（例えば車両がオフになっている間）をアドレスし、問い合わせに応答する。このプロセスは予定期間終了時におけるオドメータ読取りなどの時間依存データの遠隔検索を必要とするアプリケーションにおいて、もしくは、車両オペレーティング状態が問い合わせ時点で分かっていないアプリケーションにおいて特に有用である。
【００４９】
ＧＳＶプロセス６００を有効にするため、ＯＢＵ１０５が常にメッセージ受送信が可能であるよう、ＯＢＵ１０５は継続的に遠隔アクセスが可能であるように設計されるべきである。ＯＢＵ１０５は指示を受け取ることによりイニシャライズされ、選択された問い合わせ時間間隔で、指定のパラメータデータを定期的に収集する（ブロック６０２）。このコマンドを受け取った後、ＯＢＵ１０５は指定の問い合わせ時間間隔でデータを定期的に収集する（ブロック６０４）。ＯＢＵ１０５によって収集された値は、車両１０４がオフにされる際ＯＢＵ１０５がシャットダウンする前に、ブロック６０６においてフラッシュメモリなどの車載装置メモリに保存される。
【００５０】
ＯＢＵ１０５がアプリケーションサーバ２０２ａからＧＳＶ「検索」コマンドを受け取るような場合（ブロック６０８）、ブロック６１０において、ＯＢＵ１０５は車両コントローラ３０８の状態をチェックする。車両コントローラ３０８がアクセス可能である場合、ＯＢＵ１０５はその時に車両コントローラ３０８から現在値を収集し、サーバ２０２に収集した現在値を送信する。コマンドの時点で車両コントローラ３０８が使用不可の（例えば車両がオフになっている）場合、車両コントローラ３０８の現在値は検索不可能とされ、ＯＢＵ１０５にセーブされた値が検索値としてサーバ２０２に返送される（ブロック６１２）。
【００５１】
選択された時間間隔でデータを定期的に収集することにより、車両コントローラが作動状態の間、車両コントローラ３０８がしばらく後にアクセス不可能となる前に、ＯＢＵ１０５は少なくとも最近の車両コントローラパラメータ読取りを得ることが出来る。結果として、問い合わせ時点で現在のデータが入手できない場合、ＧＳＶプロセス６００によって、遠隔サーバ２０２が一番最近のコントローラデータを得ることが可能となる。要約すると、車両がオンになっている場合、ＧＳＶプロセス６００においてメモリ内の最新の既知の値をサーバ２０２に返送する。車両がオフにされている場合には、そのときにメモリ内の最新の既知の値であるバックアップ値を検索する。
【００５２】
システム１００において、多重「アラート」サービスもまたコアサービスとして提供可能である。その最も単純な形態においては、「アラート」サービスは車両トラブルコードをモニタし、トラブルコードの発生時に、メッセージをＯＢＵ１０５に伝送する。例えば、フォルトコードは、ＯＢＵ１０５内のコントローラ３０８がフォルト処理をいかに指示されるかにより応答形（solicited）、もしくは任意形（unsolicited）となる。任意形のフォルトを得るために、ＯＢＵ１０５はフォルト発生に関して車両データバス３０７をモニタし、フォルトが発生している場合はサーバ２０２に通知する。個々のフォルトのセットのみがモニタされる場合、追加のパーシングが実行され、不要なフォルトを取り除く。例えば、全部のフォルトコードが通知されるのとは対照的に、構成要素のブレークダウンに対応したフォルトコードの通知のみをユーザが望む場合、ユーザは、インターフェース１０６を介してこの選好を指示することが可能である。
【００５３】
応答形フォルトを得るために、ユーザは、設定通知に加えて、ＯＢＵプロセッサ３００に対して定期的問い合わせを設定する。実際にフォルトがない場合であっても応答メッセージはメッセージテンプレートに一致することに注意されたい。この場合、有用情報を得るために、応答メッセージの追加のパーシングが必要とされる。例えば、ユーザが情報のリクエスト請求を行うと、ユーザは、求められていない通知のクライテリアとは異なる、そのリクエストのクライテリアに基づいて応答を得る。
【００５４】
必要なら、「アラート」サービスは、個々のフォルトを追加／削除する能力を提供するなどの機能や、第一フォルト発生（そして続きのフォルト発生がない）のみが通知メッセージをトリガするように、フォルトアラートが発されると所定のフォルトのアラート機能をキャンセルするなどの機能、あるいは、ユーザがサービスを解除するまで、もしくはフォルト発生によってサービスがキャンセルされるまで、「アラート」サービスが、例えばデータサービス２０２ｄに永久保存されるように構成するなどの追加の機能を含み得る。
【００５５】
図７に示すような例に関して、上述のように、「アラート」サービスは、モニタされた値が選択されたしきい値を超過するか否かをチェックすることにより、その機能の中に特定イベントの検出を含み得る。本例においては、１つの診断パラメータに焦点を当てているが、しきい値の制限境界を検出するために複数診断パラメータがアルゴリズムに組合わされ得ることを注記する。さらに、１つのシングルアラートトリガイベントとしてよりもむしろ、値は長期的にモニタされ、パターンおよび傾向をモニタし、より正確にイベントを検出する。
【００５６】
長期的にモニタを行う「アラート」サービスの例として、図７において、車両ドライバが車両のエンジンを誤用した場合に検出する「超過ＲＰＭ」しきい値アラートの例を示している。この例において、超過ＲＰＭしきい値アラートは、単にＲＰＭがレベルを超過する時間ごとにアラートを生成するのではなく、ＲＰＭレベルが特定の制限（本例では６０００ＲＰＭ）を超過する時間量を考慮に入れる。時間遅延により、アラートが真に懸念を生じるイベントに対してのみ確実に生成されるようにする。
【００５７】
図７に示すように、２秒未満といった短い時間だけＲＰＭが６０００ＲＰＭを超過する場合（７０２）、「アラート」サービスはアラートを生成しない。しかし、ＲＰＭが２秒よりも長く６０００ＲＰＭを超過する場合（７０４）、サービスはアラート７０７を発し、ＲＰＭが６０００ＲＰＭ未満に戻ると（７０８）それ自身をリセットする。ＲＰＭをモニタし、システム１００において（例えばＯＢＵ１０５にて）「アラート」サービスのこの例を実行する実際の回路は、従来技術において十分に可能なものである。さらに、図７に示した時間遅延の概念は、時間と値のしきい値によって望ましからざるオペレーションが望ましく検出される、あらゆるパラメータに使用可能である。
【００５８】
図８に示すように、「アラート」サービスには盗難アラームフィーチャを含むことも可能であり、ユーザが、コンフィギュレーション可能パラメータの不正変更をモニタすることが可能となる。一般的にこのフィーチャ８００はセットアッププロセス８０２および盗難チェックプロセス８０４を含む。ユーザが盗難アラームサービスをリクエストすると（ブロック８０６）、ＯＢＵ１０５はリクエスト時にパラメータ値を捕捉し、ブロック８０８において、ＯＢＵのメモリ（例えばフラッシュメモリ３１５またはＤＲＡＭ３１６）のファイルにパラメータ値をセーブする。このパラメータ検索プロセスは、ＥＣＵあるいは他の車両コントローラあるいは構成要素３０８に問い合わせを行うために、上記にて説明を行ったような「パラメータ」サービスの使用を伴うことを注記する。
【００５９】
実際の盗難チェックプロセスは例えば車両に始めに電源が入った際に行われる。このポイントでＯＢＵ１０５はパラメータを再度チェックし、車両イグニションに電源が入ったときのその現在値を取得する（ブロック８１０）。現在値がセーブされた値と異なる場合（ブロック８１２）、盗難アラートメッセージがユーザに返信される（ブロック８１４）。しかし、ブロック８１２において比較値が同一である場合には、車両は盗難アラート信号を送信することなく通常通りのオペレーションを続ける（ブロック８１６）。一実施形態において、ユーザが個々の盗難アラートを追加／削除することが可能であり、一旦アラートが発されると、ブロック８１８において盗難アラートはキャンセルされる。
【００６０】
図９に示すように、「変更パラメータ」機能もまたコンフィギュレーションコアサービスの一部として含み得る。このフィーチャは、ユーザが、車両のパラメータまたはメッセージ定義を遠隔的に挿入もしくはアップデートするのを可能にする。図９に示すように、機能８５０は、パラメータ変更リクエストを受け取り（ブロック８５２）、車両において変更される特定パラメータを受け取り（ブロック８５４）、パラメータを変更し（ブロック８５６）、そして、メモリにパラメータをセーブする（ブロック８５８）ことを含む。一実施形態において、アップデートされたパラメータ定義は次の変更リクエストまでメモリに永久保存される。さらに、一実施形態において、アップデートされる定義はアップデートが完了するとすぐに有効となる。
【００６１】
上述のように、コアサービスは１つ以上のアプリケーションによりアクセス可能である。システム１００は、燃料税リポーティング／州境横断アプリケーション、資産管理／活用プログラム、ドライバパフォーマンスアプリケーション、オンライン車両ドキュメンテーション、詳細マッピングアプリケーション等を含む、もしくは含まない他のサービスを活用する能力を含み得る。付加することの可能なモジュラサービスおよびアプリケーション１０８、１１０と、結合、取り外し、かつ任意に一体化されるこのフレキシビリティによって、非常にフレキシブルでかつ適応性のあるプラットフォームを提供する。
【００６２】
アプリケーション
上記のように、システム１００は、ユーザが所望するように選択が可能であって、かつモジュラ方式にて組合わせ可能な複数のアプリケーションを提供することにより、ユーザ独自のニーズに基づいてユーザ自身の車両のモニタリング、プログラミング、および診断システムをユーザがカスタマイズすることを可能にする。アプリケーションには、遠隔診断、燃料効率、トリップリポーティング、ＧＰＳまたは衛星ベースシステムに基づいたオートマティック車両位置情報などのサービス提供を含む。本文に記載され、以下においてより詳細なる説明を行うアプリケーションは単に例であり、制限を設ける意図や包括的であることを意図するものでは全くない。他のアプリケーションも可能なアプリケーションオプションとして含み得ることは従来技術において理解され得る。
【００６３】
例えば、「遠隔診断」アプリケーションは、車両ブレークダウンの前もしくはその間に構成要素分析を実行する能力を提供し、かつ、車両整備場所において、その到着に先立ち、あるいは車両への技術者派遣に先立ち、車両からパラメトリック情報を受け取ることができるようにする。さらに、「遠隔診断」アプリケーションは、技術者が、OBU１０５によって管理されたテストプロセスにより、車両あるいはシステムに選択された診断テストを実行することを可能にする。
【００６４】
一実施形態において、「遠隔診断」アプリケーションにより、ユーザが、例えば、パラメータ、アクティブおよび非アクティブフォルトコード、および車両コンフィギュレーションを見ることが可能となり、認可ユーザが車両に機能テストおよびコンフィギュレーション変更を行うこともまた可能となる。例えば、車両が一連の設定されたアラートに基づいてフリートに通知を行うと、あるいはフリート認可ユーザにより診断がマニュアルでリクエストされると、遠隔診断がイニシャライズされる。実際に、アプリケーションは本発明のシステム１００を介して診断アプリケーションを提供する。ユーザが例えばインターフェース１０６を介してシステム１００にログオンすると、注意する必要のある、アラートもしくは通知をリポートした車両のリストが彼あるいは彼女に提示される。アラートがアクティブでない場合、ユーザには、彼または彼女に責任のある車両のリストが提供される。この時点で、ユーザは、以下に記載、また図１０に示す遠隔診断アプリケーション９１２のような遠隔診断アプリケーションを使用することを選択し、問題の重要度を判断するために車両にさらなる分析を実行する。
【００６５】
図１０は、遠隔診断アプリケーションを含む１つの可能な全体ウェブサイトアーキテクチャ９００を示したブロック図である。本例において、ユーザはアプリケーションにログインし（ブロック９０２）、アプリケーションホームページ９０４に達する。ホームページから、ユーザは燃料効率９０６あるいはリース車両情報９０８などの情報の範囲にアクセスを行うか、もしくは、車両パラメータをモニタ、診断、かつ／または再プログラムするためにユーティリティ９１０かもしくは遠隔診断アプリケーション（RDA）ページ９１２にアクセスを行う。この例において、ユーティリティ９１０により、ユーザが、車両グループ９１４、特定車両９１６、およびアラート９１８を定義および／または修正することが可能となる。RDAページ９１２は、パラメータビューイング９２２と再プログラミング９２４を可能にするページを含んだ、例えば車両情報およびパラメータ９２０へのユーザアクセスを可能にする。他のアプリケーションと同様に、本アプリケーションにおいては本発明の範囲を逸脱することなく他のアーキテクチャおよび実行が可能であることを注記する。
【００６６】
「リース車両管理」（LVM）アプリケーションは、トータル車両距離、トータル無駄燃料、トータル無駄時間、使用されたトータル燃料、および／またはトータル燃料効率など、フリートの各車両に対して選択されたパラメータをサマライズする定期的なステータスリポートを生成するための、別の可能なオプションである。図１１は、リース車両管理アプリケーション９５０の１つの可能な例示的アーキテクチャを示したブロック図である。この例において、ユーザは、グループ詳細ページ９５４とタスク詳細ページ９５６のどちらかをユーザが選択することのできるメインページ９５２に達する。グループ詳細９５４は、選択された車両グループの全情報に相当し、タスク詳細９５６は選択されたタスクの全情報に相当する。グループ詳細ページ９５４は、例えば、新規タスクの作成（例えば選択された車両グループのデータ収集のタイミング）９５８、リポートリストの生成９６０、あるいは、例えば選択されたリポートのパラメータ値を特定する、より詳細なリポートリスティングの生成９６２をユーザが行うことを可能にする。タスク詳細ページには同様のオプションを含み、ユーザが、選択されたタスクのリポートを見ること（９６４）が可能となり、より詳細なリポートを生成すること（９６６）が可能となる。また、タスク詳細ページ９５６により、ユーザがタスクを中止したり(９６８)、あるいはタスクを削除する（９７０）ことも可能となる。
【００６７】
「エンジン管理」アプリケーションもまた、道路および交通状況の変化、また道路タイプおよび車両重量の変化に車両が遭遇する対象フリートへのオプションである。「エンジン管理」アプリケーションの目的は、車両の動作特性、特に、馬力の格付けや道路の最大速度制限の動的制御により、フリート全体の燃料効率を改善することである。もともとそのようなオペレーティングパラメータは、上記に挙げた変数のいくつかは考慮に入れられず、かつてはフリート幅レベルで設定された。加えて、これらの変更には車両との物理的接触が必要となり、望ましからざる車両のダウンタイムを伴う。動作条件に基づく動的調整は車両の運用コストの削減を可能にし、それによりフリートレベルではかなりの節約となる。このアプリケーションにより、ユーザは、それがどこにあっても車両を動的に構成することが可能である。すなわち、ルート、道路、および他の車両動作要因に基づいてその動作特性を調整する。「エンジン管理」アプリケーションは計測パラメータとプログラム可能パラメータの両方を含み得る。プログラム可能パラメータの例には、車道速度制限、エンジン馬力／トルク、エンジンシャットダウンアイドル時間、およびクルーズコントロール設定を含む。
【００６８】
「トリップリポート」アプリケーションもまたオプションにて提供することが可能である。このアプリケーションにより、フリートマネージャはほぼリアルタイムベースで車両からトリップ情報を得ることができる。ユーザはフリートの増加と同様に、単体車両のトリップ情報を分析することができる。このアプリケーションは主として、オドメータ読取り、トータルトリップ燃料、無駄燃料、平均燃料効率、走行車両ルートなどの計測パラメータを使用する。このアプリケーションからの出力は、マイル距離に基づいて顧客に請求を行うリース会社の請求システムへの入力にも使用可能である。
【００６９】
「整備アラート」アプリケーションは、フリートマネージャによる、キーパラメータに基づいた一連の整備トリガ設定を可能にする。パラメータしきい値になると、フリートマネージャはシステムより自動的に通知を受け、こうして、車両との物理的接触なしに整備イベントをイニシャライズする。例えば、フリートはオドメータ読取りに基づいて予防的整備周期を設定するかもしれない。サーバ２０２が時間間隔を認識すると、時間間隔が生じた際に、まさにその時をフリートに通知することができる。アラートは、車両にとっての不当な盗難のみならず、診断コード、燃料レベル、およびパラメータ範囲などのパラメータに関して通知を行う。
【００７０】
「車両コンフィギュレーション」アプリケーションが提供されることで、フリートマネージャは、フリート内の複数車両に特定のパラメータを設定することが可能となり、それによって、選択された車両はその設定された基準内でオペレートする。パラメータの例に、馬力格付け、道路の最大速度制限、最大および最少クルーズコントロール設定速度、シャットダウン前の最大エンジン無駄時間を含む。もともとこのステップは、診断アプリケーションあるいはツールの車両への物理接続を必要とするものであった。しかし、物理接続は時間消費となり、かつサービスを受ける車両ごとに同一工程を繰り返す必要がある。「車両コンフィギュレーション」アプリケーションの無線の特質によって、選択車両の識別、パラメータの設定、および、各車両が同一パラメータ設定により体系的に設定される自動工程の開始をユーザが行うことが可能となることから、フリート内の複数車両に対して一度での動作設定およびアラートが可能となる。
【００７１】
「保証管理」アプリケーションもまた、例えば相手先商標製品の製造会社（OEM）により使用されるデータマイニングストラテジーの一部として提供され、主構成要素における診断保証関係をヘルプするかあるいはその有効性について保証請求にアクセスを行うことが出来る。このアプリケーションは例えば、フリート特定データマイニングおよびシステムワイドデータマイニングの両方を用いてデータベースサーバ２０２ｄから詳細な車両データを取得し、それからデータと保証要求との関連付けを行う。
【００７２】
上に述べたように、本文に記載した可能なモジュラアプリケーションは単に例示であるにすぎない。さらに、上述したように、インフラストラクチャ１０２によりアクセスされるアプリケーション１０８、１１０はサードパーティによる生成も可能とし、また、特定のユーザインターフェース１０６に取り込むモジュールとして、かつOBU１０５および他のシステムサポートコアサービスおよびアプリケーションにアクセスを行うモジュールとして提供され得る。別々のアプリケーション１０８、１１０により提供されるモジュラ機能により、異なるユーザが同一のOBU１０５と同一のインフラストラクチャ１０２を介して同一車両データにアクセスすることが可能となる一方、ユーザにより選択された特定のモジュラアプリケーションによって決定される、ユーザの産業に有意なカスタマイズデータ、機能性、およびインターフェースが提供される。例えばコンピュータプログラムによりアプリケーションを実行する特定の方法は、従来技術において可能な範囲内である。
【００７３】
ゆえに、本発明のシステムは、ユーザの仕様にカスタマイズ可能なモジュラ無線車両診断、コマンド、および制御システムを提供する。さらに詳しく述べると、モジュラアプリケーション１０８、１１０は多くの汎用性をもたらし、異種産業のユーザが、彼ら独自の産業に関連したアプリケーション１０８、１１０を選択することによって、本発明の同一全体システム１００を使用することが可能となる。さらに、無線診断およびコマンドおよびコントロールサービスを作り出すことにより、本発明は、例えばインターネットや無線ネットワークを通じて、車両および車両システムへのリアルタイム遠隔アクセスを可能にする。一実施形態において、本発明のシステムによって、ユーザは、所定車両の複数データポイントに接続して車両データをリアルタイムで解釈および分析すること、必要に応じて車両パラメータを変更すること、また、将来決定を導く履歴データベースを作成することが可能となる。さらに、リアルタイムで車両オペレーションをモニタリングし、車両ごとにカスタマイズされたリポートを提供することによって、本発明のシステムは、高い動作効率と、より低い整備コストおよびダウンタイムを達成し、かつ、車両からアプローチする定期整備として部品の先行予約さえも可能にする。
【００７４】
上記説明の可能性は例示であって制限をもたらす意図ではないことを注記する。例えば、システム１００は、車両ごとに個々に設定を構築するのでなく、ワン・コマンドにより、選択された車両グループに適用される設定を構築するように構成できる。認可、車両／構成要素相違、パスワード相違、および特定リクエストのコンフィギュレーション制限を含む、リクエストのアスペクトは、例えばサーバ２０２によって管理される。別の実施形態において、システム１００は、各車両１０４を１つのエンティティと見なすことができ、ユーザは、同一車両１０４の複数ECUと同時に通信可能となる。例えば、他に関連付けられた各コントローラからの結果データにより、エンジンECUおよびトランスミッションECUからデータを同時に得て、ユーザに提供されたデータにさらに詳細を加えることが出来る。
【００７５】
本発明の範囲を逸脱することなく、上に記載のシステムの変更もまた可能である。例えば、選択されたアプリケーションを、インターネットによる代わりに、スタンドアロンのソフトウェアアプリケーションとして顧客（すなわちフリートマネージャ、車両販売会社、車両ディーラ等）所有のプリプライエタリ装置にて局所的に実行することも可能である。さらに、OBU１０５に例えばバーコードスキャナおよび／または他のヒューマンユーザインターフェースを装備し、データの捕捉を容易にすることが可能である。携帯診断ツール、ワークフロー統合ツール、異なるアプリケーションにより捕捉されたデータ間のリンク、および、車両故障の事前警告または到着前の診断情報を提供するツールなど、他のユーザインターフェースおよび機能もまたアプリケーションモジュールまたはコアサービスとして含むことが可能であり、もしくはアプリケーションモジュールそれ自体に統合することでさえも可能である。１つ以上の追加サーバをシステムに取り込み、例えば、追加のデータ管理機能を提供すること、および／または既存のアプリケーションと統合するためのインターフェースを提供することも可能であることに注目されたい。
【００７６】
本発明のシステムを介して得た情報は、例えば、車両構成要素の再較正を行う、ファームウェアダウンロードを実行する、構成要素故障分析を実行する、摩耗特性を判断する、その製造工程において使用される構成要素の品質を分析する、保証情報を検索および管理する、車両整備ニーズの指示を受け取る、車両の使用および不正使用をモニタする、および／または賃借人のトリップ情報をモニタする、先行データ分析を実行する、到着前診断を実行する、車両構成要素の再較正を行う、および／またはファームウェアダウンロードを実行するためにも使用可能である。このオプションの記載は包括的なものでなく、本発明の範囲を逸脱することなく、本発明のシステムを介して得られるデータの他のバリエーションが考えられ、データ提供およびその使用の方法もまた変更可能であることは従来技術において理解され得ることを注記する。
【００７７】
本文に記載した本発明の実施形態の多様な代替案が、本発明の実施において使用可能であることは理解されるべきである。請求項において本発明の範囲を明確にし、これら請求項の範囲内、かつ、その同等内における方法および装置がそれにより網羅されることを意図する。
【図面の簡単な説明】
【００７８】
【図１】本発明の一実施形態に基づく全体システムを示した典型的な機能ブロック図である。
【図２】本発明の一実施形態に基づくシステムアーキテクチャを示した典型的なブロック図である。
【図３（Ａ）】本発明の一実施形態における車載装置の一実施形態の典型的なブロック図である。
【図３（Ｂ）】本発明の一実施形態における車載装置の一実施形態の典型的なブロック図である。
【図４】本発明の一実施形態に基づくパラメータ検索プロセスのブロック図である。
【図５】本発明の別の実施形態に基づくパラメータ検索プロセスのブロック図である。
【図６】本発明のまた別の実施形態に基づくパラメータ検索プロセスのブロック図である。
【図７】本発明の一実施形態に基づくしきい値アラートプロセスのオペレーションを示したグラフである。
【図８】本発明の一実施形態に基づく盗難アラートプロセスのオペレーションを示したブロック図である。
【図９】本発明の一実施形態に基づくパラメータ変更プロセスを示したブロック図である。
【図１０】本発明の一実施形態において使用される遠隔診断アプリケーションの１つの可能なアーキテクチャを示したブロック図である。
【図１１】本発明の一実施形態において使用されるリース車両管理アプリケーションの１つの可能なアーキテクチャを示したブロック図である。
【図１】
2005520725.tif 000003
【図２】
2005520725.tif 000004
【図３（Ａ）】
2005520725.tif 000005
【図３（Ｂ）】
2005520725.tif 000006
【図４】
2005520725.tif 000007
【図５】
2005520725.tif 000008
【図６】
2005520725.tif 000009
【図７】
2005520725.tif 000010
【図８】
2005520725.tif 000011
【図９】
2005520725.tif 000012
【図１０】
2005520725.tif 000013
【図１１】
2005520725.tif 000014
【国際調査報告】
2005520725.tif 000015
2005520725.tif 000016
2005520725.tif 000017