(57)【特許請求の範囲】
【請求項１】
アプリケーション・プログラムを実行する自動車用コンピュータ・システムであって、
複数の電子制御ユニットと、
前記複数の電子制御ユニットに少なくとも１つのバスによって接続されたコンピュータ・プラットフォームと
を含み、
前記コンピュータ・プラットフォームは、
複数のＪａｖａＢｅａｎと、
前記複数のＪａｖａＢｅａｎをアクセスするルックアップ機構と、
前記複数のＪａｖａＢｅａｎを保持するデータベースと、
前記ルックアップ機構と、前記データベースと発見機構とを含むレジストリと
を含み、
ここで前記複数の電子制御ユニットの各々は、当該複数の電子制御ユニットの各々用の異なるソフトウェア・ドライバを利用して、前記コンピュータ・プラットフォームと通信し、及び前記アプリケーション・プログラムは、前記複数の電子制御ユニットのいずれとも又は各電子制御ユニット用の前記ソフトウェア・ドライバのいずれとも直接的にインタフェースせず、
前記複数のＪａｖａＢｅａｎの各々は、前記複数の電子制御ユニットのうちの１つの電子制御ユニットに関連付けられ且つ当該１つの電子制御ユニットの機能をそれぞれ表すものであり、当該１つの電子制御ユニットの前記機能へのアクセスは、当該１つの電子制御ユニットに関連付けられる当該ＪａｖａＢｅａｎを介して提供され、前記複数のＪａｖａＢｅａｎの各々は、前記アプリケーション・プログラムと当該ＪａｖａＢｅａｎに関連付けられる１つの前記電子制御ユニット用のソフトウェア・ドライバとの間のソフトウェア・インタフェースであり、及び前記複数のＪａｖａＢｅａｎの各々は、当該１つの電子制御ユニットとは直接的にインタフェースしないものであり、
前記コンピュータ・プラットフォームは、前記複数の電子制御ユニットのうちの１つの電子制御ユニットの前記機能をアクセスするための要求を受信すると、前記発見機構を使用して、前記レジストリを発見し及び参照し、次いで前記ルックアップ機構を使用して、該レジストリ内のデータベースに格納された、前記１つの電子制御ユニットに関連付けられる１つのＪａｖａＢｅａｎを受け取って前記１つの電子制御ユニットに返す、前記自動車用コンピュータ・システム。
【請求項２】
前記複数の電子制御ユニットの１つが燃料計器センサである、請求項１に記載の自動車用コンピュータ・システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、自動車用コンピュータ・システムに係り、更に詳細には、自動車用コンピュータ・プラットフォーム上で実行されるアプリケーションに対し、自動車用装置機能及びソフトウェア・サービスを伝達するシステムを提供することに係る。
【０００２】
【従来の技術】
歴史的に、コンピュータ・プログラムは、低レベルのハードウェア及びソフトウェア・サービスから構築され、これらのパーツを単一の実行可能なイメージに緊密に結合することにより構成された。このアプローチは、変化する要求に対して予想される変更及び適応化が非常に困難な、柔軟性の無いコンピュータ環境を生ぜしめた。これらの環境に対して作成されたアプリケーションは、他のコンピュータ環境に適応するのが非常に困難であった。異なるコンピュータ環境において同一の問題を解決するために、アプリケーション・ソフトウェアを再利用する機会が殆ど無かった。
【０００３】
最近、コンピュータ・アーキテクチャは、コンポーネント・アプローチを組み込むようになった。これらのコンピュータ・アーキテクチャでは、体系的に一貫性を有する態様で、基本プラットフォームが低レベルのコンポーネントにより構成される。このアプローチは、ソフトウェア・プラットフォームに対するよりモジュール指向のアプローチを与え、任意のコンポーネントが同一のタスクを達成する別のコンポーネントにより置換されることを可能にする。コンポーネントのこの互換性を可能にするのは、ソフトウェア・インタフェースの標準化である。コンポーネントは１つ以上のインタフェースをサポートするように構築され、これらのサービスをコンピュータ・プラットフォームに提供する。これらのインタフェースを実現する任意の他のコンポーネントが置換として使用され得る。
【０００４】
コンポーネント・アーキテクチャの幾つかの例が、現在登場している。これらの例には、マイクロソフト社により開発されたＡｃｔｉｖｅＸアーキテクチャ、及びサン・マイクロシステムズ社により開発されたＪａｖａのためのＪａｖａＢｅａｎコンポーネント・モデルが含まれる。
【０００５】
１９７０年代後半以降、コンピュータは自動車に搭載されるようになった。今日、一般の車両は５個〜１２個のマイクロプロセッサを含み、高級自動車では５０個も含み得る。これらのプロセッサは、８ビット・マイクロコントローラから３２ビット汎用プロセッサまで様々である。ソフトウェア・プログラムは、動力伝達装置、シャーシ、一体ボディ及び娯楽機能を制御し、５０００００行以上のコードを含み得る。オペレーティング・システム、言語、ライブラリ及び多数のプログラムを実現する技術は、一貫した設計方法が殆ど存在しないために極めて多様化している。歴史的に、これらのシステムの殆どは、互いに通信することがなかった。
【０００６】
車両ソフトウェアの複雑度が増し、半導体技術が進歩すると、エレクトロニクス及びソフトウェアがより一層高度化する。最新の車両エレクトロニクス・システムは、ＥＣＵ（電子制御ユニット）間通信を可能にするバス・アーキテクチャを含む。将来の車両コンピュータ環境は、一層この傾向を強め、複数のＥＣＵが共同作業を行い（collaborate）、多彩なアプリケーションに参加することを可能にするであろう。車両外通信を含むこれらのアプリケーションは、無線通信技術が一層浸透するにつれて、発展し続けることであろう。
【０００７】
車両コストの増加要因としてのソフトウェアは、この発展の兆候である。この傾向は加速することが予測されるので、ソフトウェアが市場投入時期の重大な障害となるであろう。
【０００８】
パーソナル・コンピュータ（ＰＣ）プラットフォームは、ハードウェア及びソフトウェア・サービスの標準の予測可能な構成を有する。この構成は、ＣＰＵ、メモリ、キーボード、マウス、モニタ、シリアル・ポート、及び外部装置をＰＣ上のコンピュータ・プラットフォームに接続するための少数の標準バス・アーキテクチャを含む。
【０００９】
ＰＣのために作成されたプログラムは、この標準の構成が使用可能であると想定し、この想定が破られる場合、しばしば適切に機能しなくなる。
【００１０】
自動車組み込み型コンピュータは、ＰＣ及び他のパーベイシブ・コンピュータ状況と異なる。なぜなら、自動車は、スマート・ページャやセルラ電話などの単一目的適合装置、又は業界標準のＰＣにより定義される装置の高信頼度の構成とは異なり、複数の接続装置の複合体であるからである。
【００１１】
アプリケーションは、自動車上の装置により伝達される機能へのアクセスを必要とし、例えば燃料計器の場合、それらの現ステータスがポーリングされ、無線アプリケーションに事前設定された無線局の場合、装置が操作される。装置群は、ディーラの及び売買後の装置の追加に基づき、個々の自動車ごとに変化し得るので、アプリケーションは、固定の標準の装置群に頼ることができない。その結果、アプリケーションは、装置実現及び装置構成とは独立に作成される必要がある。アプリケーションが、実現の詳細とは独立に、標準のＡＰＩに作成される場合、それらは複数の自動車モデルに亘り、及びオプション／売買後の追加の装置群に亘り、移植可能となる。更に、アプリケーションは、低レベルの装置の実現の詳細に依存しなくなるため、より単純となる。
【００１２】
更に、装置及びソフトウェア・サービス機能へのアクセスが、（その装置又はソフトウェア・サービスの特定の実現に特有の詳細を通してではなく）業界標準のアプリケーション・プログラミング・インタフェース（ＡＰＩ）を通して行われるように、アプリケーションを構築する必要がある。こうすると、様々な装置構成や自動車用コンピュータ・プラットフォーム環境を全く変更しないか又は殆ど変更することなく、アプリケーションを実行することが可能になる。また、自動車の寿命が尽きるまで、アプリケーションを自動車用コンピュータ・プラットフォームに追加することが可能になり、特に、第３者ソフトウェア開発者が、自動車用コンピュータ・プラットフォーム上で実行するように、アプリケーションを構築することが可能になる。
【００１３】
ＡｕｔｏＰＣは、マイクロソフト社により開発されたＡＰＩセットであり、ＷｉｎＣＥオペレーティング・システムを自動車産業に拡張するものである。ＷｉｎＣＥオペレーティング・システムは、マイクロソフト社から提供されるオペレーティング・システムである。しかしながら、ＡｕｔｏＰＣは、１セットのデータ構造及びそれらを操作するための複数のＡＰＩを提供するという、古典的な手続き的アプローチを使用する。
【００１４】
自動車内の様々な装置へのアクセスの保護に関し、自動車上の特定の装置機能（現オイル圧の読出しなど）は寛容であり、殆どセキュリティ上の問題を有さない。一方、パワー・シートの調整、車のドアのロック解除、現ＧＰＳデータ、又はメーカの所有権に係る（所有権的）エンジン診断データなどの他の装置機能は、アクセス制限を必要とする。これらの装置又はソフトウェア・サービスへのアクセスは、特定のアプリケーションにとって重要であるが、任意のユーザによるこれらの装置へのインターネット（又は直接接続）を介するアクセスを放置すると、セキュリティ上のリスクを負うことになる。自動車業界は、（特定の地域では法律によって規制されているように）顧客の安全性及びセキュリティに関心を持っているので、搭載装置の機能への安全なアクセスは、自動車ネットワーク・コンピュータの要件である。
【００１５】
【発明が解決しようとする課題】
従って、自動車用コンピュータ・プラットフォームのために作成されるアプリケーションを、モジュール化及びコンポーネント化するように設計及び構築する方法及び装置を提供することが有利である。
【００１６】
【課題を解決するための手段】
本発明は、自動車用装置機能及びソフトウェア・サービスを、自動車用コンピュータ・プラットフォームのソフトウェア・コンポーネントとして表すための、自動車用コンピュータ環境において使用される方法及び装置を提供する。自動車用コンピュータ・プラットフォームは、Ｊａｖａ言語により作成されたコンピュータ・プログラム命令を実行可能である。ＪａｖａＢｅａｎコンポーネントからＪａｖａＢｅａｎｓとして作成された複数のプログラム・コンポーネントは、自動車用コンピュータ・プラットフォーム上で使用可能な装置機能及びソフトウェア・サービスを表すために使用される。コンポーネント・レポジトリが使用され、それによりソフトウェア・アプリケーションは、ＪａｖａＢｅａｎコンポーネントの使用可能性を決定でき、Ｊａｖａ言語メソッド呼び出しを使用して、任意のコンポーネントの機能へのアクセスを確立できる。
【００１７】
本発明は、コンポーネント・レポジトリを突き止めるためにアプリケーションにより使用される第１の機構を提供し、これはレポジトリ発見として知られる。第２の機構は、アプリケーションがコンポーネント・レポジトリにコンポーネントの使用可能性を決定するように問い合わせるために存在し、これはコンポーネント・ルックアップとして知られる。第３の機構は、アプリケーションがコンポーネント・レポジトリからコンポーネントへのアクセスを獲得するために使用可能である。
【００１８】
【発明の実施の形態】
本発明は、車両内のアプリケーションと装置との間の通信を統合及び提供するための解決策を提供するものであり、ソフトウェア・システム開発のライフサイクルにおける幾つかの点で、即ち、１）装置及びソフトウェア・サービス・コンポーネント開発、２）アプリケーション開発、３）システム構成時間、及び４）システム実行時間に関して、Ｊａｖａベースの自動車用コンピュータに影響を与える。
【００１９】
本発明は、自動車用コンピュータ・プラットフォームで使用される方法及び装置を提供する。本発明の好適な実施例に従って、装置及びソフトウェア・サービスのための標準のＪａｖａ  ＡＰＩが、自動車用コンピュータ・プラットフォーム上で使用可能である。これらの実現体は、ＪａｖａＢｅａｎｓの形式である。本発明は、ＪａｖａのためのＪａｖａＢｅａｎコンポーネント・モデルを使用して、自動車用コンピュータ・プラットフォームのハードウェア及びソフトウェア・コンポーネントを表すための方法及び装置を提供する。
【００２０】
自動車用コンピュータ・プラットフォームと相互作用する装置は、標準のＡＰＩを使用する。ＡＰＩは、自動車などの車両内に現れる全ての装置に適用される。更に、装置に問い合わせたり、装置を操作するための機構又は電子手段が存在する。後述の例では、これらの装置の標準ＡＰＩは、Ｊａｖａインタフェース定義に関して定義される。
【００２１】
Ｊａｖａにおける標準コンポーネント・モデルは、ＪａｖａＢｅａｎコンポーネント・モデルである。ＪａｖａＢｅａｎは、２つの部分を有する。第１の部分は、「パブリック・フェース」であり、自動車用装置又はソフトウェア・サービスを表す、標準のＪａｖａインタフェースを実現するためのコミットメントである。これは、ＪａｖａＢｅａｎが互換性を有する、Ｊａｖａ言語の或るタイプを定義する。第２の部分は、インタフェース実現コミットメントを履行する共同作業用Ｊａｖａインスタンスのウェブである。このインスタンスのウェブは、Ｊａｖａインタフェース定義のセマンティックスが正しく実現されるように、バス及び装置特有の実現の詳細を完成するように共同して作用する。
【００２２】
車両外データ通信のためのネットワーク・スタック、又は自動車のスピーカを使用する音響出力サービスなどのソフトウェア・サービスも、ＪａｖａＢｅａｎｓとして表すことができる。
【００２３】
ＪａｖａＢｅａｎｓは、幾つかの理由で、Ｊａｖａアプリケーションに対して、自動車用装置及びソフトウェア・サービスを表すための優れたアプローチを提供する。第１に、コンポーネント・モデル・アプローチは、アプリケーションが自動車上に存在し得る様々な装置及びサービスに対処するための効率的な機構を提供する。更に、自動車の装置及びサービスの構成は、ＪａｖａＢｅａｎｓの直列化を通して、動的に又は静的に行われ得る。静的構成は、メモリ空間的に効率的であり、コスト効率がよい。
【００２４】
更に、ＪａｖａＢｅａｎは、装置を代理するか又はサービスを伝達する、Ｊａｖａインスタンスの共同作業用ウェブをユニットとして表すことができる。こうすると、装置インタフェースの実現体をオブジェクトの共同作業用セットから形成することが可能になり、それらのオブジェクトのあるものは他の装置の実現のために再利用される。例えば、アクセス機構を自動車用バスにカプセル化するゲートウェイ・オブジェクトは、バス上の各装置を代理するＪａｖａＢｅａｎにサービスを提供できる。また、アプリケーションは、低レベルのコンポーネント構築ブロックから構成され得る。この構成は、実現に独立の態様で行われ、アプリケーションのより優れた移植性を提供する。
【００２５】
ＪａｖａＢｅａｎｓによるコンポーネント化は、アプリケーション及びシステム構成をパッケージ化する際に、高度な柔軟性を提供する。
【００２６】
後述の例では、様々なＪａｖａＢｅａｎコンポーネントに対するアプリケーションのアクセスを提供するために、レジストリが使用される。更に、このレジストリは、認可レベルをキーとして、オブジェクトのセットによりレジストリ・エントリを索引付けする能力を強化され得る。特に、ルックアップ機構がレジストリをアクセスするために使用され、そこではルックアップ機構が要求元アプリケーションの認可証明書（authorization certificate）をパラメータとして含む。
【００２７】
（例えば、公知の名前を用いて）レジストリのルックアップが行われるとき、その認可レベルは、認可レベルをキーとして索引付けされるエントリのセットと比較される。後述の例では、この認可は、Ｘ５０９証明書に基づいており、要求元エージェントをレジストリ内に記憶されるユーザ・プロファイルにマップするために使用される。ユーザ・プロファイルは、所有者、運転手、コンテント・プロバイダ、ＩＳＰ、ディーラ、第３者機械工、メーカなどを含む。返されるオブジェクトは、所与の認可レベルとディレクトリ・エントリ内のコンポーネントの集合の１つとの合致に依存する。後述の例では、もし、コンポーネントの認可レベルとユーザの認可レベルとが合致しなければ、ユーザは、この特定のコンポーネントへのアクセスを許可されない。この場合、ユーザは、特定のコンポーネントが車両に存在しないと告げられる。
【００２８】
図１には、本発明の好適な実施例に従った、自動車用コンピュータ・プラットフォーム（以下「プラットフォーム」と略記）が示されている。図示の自動車１００は、プラットフォーム１０２を含み、これは中央処理ユニット（ＣＰＵ）１０４及びメモリ１０６を含む。ＣＰＵ１０４は、この例では、組み込み型プロセッサであるが、インテル社のペンティアム・プロセッサ（「ペンティアム」はインテル社の商標）などの他のプロセッサを用いても実現され得る。メモリ１０６は、読出し専用メモリ（ＲＯＭ）、ランダム・アクセス・メモリ（ＲＡＭ）、不揮発性ＲＡＭ又はフラッシュ・メモリの形態を有し得る。
【００２９】
また、プラットフォーム１０２は、コンポーネント・レジストリ（以下「レジストリ」と略記）１０８を含む。オプションとして、大容量記憶装置１１０を設けてもよい。レジストリ１０８は、大容量記憶装置１１０上に記憶されるか、メモリ１０６及び大容量記憶装置１１０の両方に配置され得る。大容量記憶装置１１０は、ハード・ディスク・ドライブ又はＣＤ−ＲＯＭドライブである。ソフトウェア・コンポーネント１１２は、プラットフォーム１０２と一緒に構成され、レジストリ１０８内に記憶される。ソフトウェア・アプリケーションもレジストリ１０８内に記憶され得る。
【００３０】
エンジン室のセンサ、キャビン内のパワー・ドア・ロック、又は自動車１００の燃料タンク内の現燃料レベル・センサなどの装置が、電子制御ユニット（ＥＣＵ）１１４ａ〜１１４ｃとして組み込まれる。また、ＥＣＵ１１４ａ〜１１４ｃは、自動車１００内に導入されるステレオ・システム又は移動電話などの電子装置の形態を有し得る。
【００３１】
これらのＥＣＵは、自動車１００内の様々なアーキテクチャの１つ以上のデータ通信バス１１６を介して接続され得る。自動車業界は、コンピュータ業界で一般的なものとは異なるバス・アーキテクチャを使用する。自動車内で使用される自動車用バス・アーキテクチャの例には、コントローラ・エリア・ネットワーク（ＣＡＮ）、Ｊ１８５０、インテリジェント・トランスポーテーション・システム・データ・バス（ＩＤＢ）、マルチメディア・リンク（ＭＭＬ）、及びＭＯＳＴが含まれる。
【００３２】
ＣＡＮは、乗用車用に欧州で開発されたプロトコルであり、ＩＳＯ１１８９８の下で国際的に標準化されている。Ｊ１８５０は、様々な自動車メーカにより開発された自動車技術者協会（ＳＡＥ）規格である。ＩＤＢは、ＳＡＥにより定義され、オープンで且つ非所有権的な標準アーキテクチャを作成するシリアル通信バスであり、複数の電子装置が任意の車両に容易に、費用に対し効率よく、更に安全に導入されることを可能にする。ＭＭＬは、Ｄｅｌｃｏ／Ｄｅｌｐｈｉにより開発されたバス・アーキテクチャである。エンジン室、シャーシ、及びキャビン内のＥＣＵをネットワーク接続するために、しばしば低速バス・アーキテクチャが使用される。高速バス・アーキテクチャは、例えばラジオとキャビン内スピーカの間など、自動車内の娯楽装置間でマルチメディア・データを伝送するときに使用される。各タイプのバスは、メッセージ・プロトコルの形式を定義し、そのメッセージ・プロトコルは、バスに接続される装置が通信し合うための機構を決定する。
【００３３】
プラットフォーム１０２は、或る手段の電子接続を通して、１つ以上の自動車用バス、又は入出力（Ｉ／Ｏ）の個別のポイントに接続される。この接続は、ゲートウェイ１１８として知られる。ゲートウェイ１１８は、ハードウェア及びソフトウェアの組み合わせであり、プラットフォーム１０２上で実行されるコンポーネント及びアプリケーションが、ＥＣＵ１１４ａ〜１１４ｃと通信し合うための機構を提供する。
【００３４】
更に、プラットフォーム１０２は、コンピュータ業界においてより一般的に見いだされる他のバス・アーキテクチャをサポートし得る。シリアル接続又はユニバーサル・シリアル・バス（ＵＳＢ）１２０などの接続が、使用され得る。ゲートウェイ１２２は、バス１１６に対するゲートウェイ１１８に関連して説明したのと類似の機構を提供する。ラップトップ・コンピュータ１２４又はエンジン機能診断コンソール１２６などの接続装置が、このタイプのゲートウェイを使用してプラットフォーム１０２に接続され得る。更に、スマート・カード１２８がＵＳＢ１２０に接続され、車両の運転手又はユーザがログオンするために使用される。実施例に依存して、運転手又はユーザは、その車両を使用するためにログオンすることを要求され得る。かかる例では、特定の情報がスマート・カード１２８内に配置され得る。スマート・カード１２８は、証明書などの情報が配置される組み込み論理又はファームウェアを含む、回路ボード又は他の回路を備えた装置である。スマート・カード１２８は、一般に、クレジットカード・サイズの装置であるが、イグニション・キー内に組み込まれ、スマート・キーを形成してもよい。
【００３５】
図１の例は、複数のバスによりコンポーネントに接続されるプラットフォーム１０２を示すが、他のタイプの接続も使用され得る。例えば、バス１１６の代わりに、プラットフォーム１０２と、ＥＣＵ１１４ａ〜１１４ｃなどの様々なコンポーネントとの間の個別の接続が使用され得る。
【００３６】
図２には、本発明の好適な実施例に従った、レジストリ１０８の部分が示されている。図面を通して、同一の参照番号は同一の要素を表す。レジストリ１０８は、コンポーネント２０２ａ〜２０２ｃを保持するコンポーネント・データベース２００を含む。データベース２００内で見いだされるコンポーネント２０２ａ〜２０２ｃは、例えば自動車１００上で使用可能な装置のソフトウェア表現、ソフトウェア・サービス（車両外データ通信のためのデータ通信スタックなど）、又はアプリケーションなどである。
【００３７】
レジストリ１０８は登録機構２０４を含み、これによりコンポーネントをデータベース２００に挿入し、変更し、又はデータベース２００から除去できる。また、レジストリ１０８は、アプリケーションがレジストリ１０８を突き止めるための発見機構２０６を含む。発見機構２０６は、多様な態様で実現され、例えば、プラットフォーム１０２に接続される１つ以上のバス・アーキテクチャ上の同報機構として実現され得る。代替的に、発見機構２０６は、プラットフォーム１０２のアーキテクチャ仕様で公開される公知のメモリ・アドレスにより、又はプラットフォーム１０２のデータ通信アドレス空間内の公知の名前により実現され得る。
【００３８】
また、レジストリ１０８は、アプリケーションがコンポーネント・データベース２００の内容を問い合わせ、１つ以上のコンポーネント２０２ａ〜２０２ｃの参照を獲得するためのルックアップ機構２０８を有する。ルックアップ機構２０８は、アプリケーションから、当該アプリケーションが必要とするコンポーネントの種類を指定する照会を受信する。この照会の実施例は、名前と値の対の任意の述語を含む。これは例示照会プログラムとして知られる。これはまた、コンポーネントがサポート又は実現しなければならない、必要とされるインタフェースに関して必要とされるコンポーネントを指定することによっても実現され得る。参照機構は、Ｊａｖａプログラミング・モデルにより伝達される標準のオブジェクト参照モデルである。
【００３９】
図３には、本発明の好適な実施例に従った、レジストリ１０８による、コンポーネントの作成及び登録を示すプロセスが示されている。このプロセスは、プログラマがＥＣＵソフトウェア・ドライバ３００により伝達される機能の詳細を理解することから開始し、それらにはＥＣＵの外部ＡＰＩの仕様、及びＥＣＵソフトウェア・ドライバ３００により理解されるバス・メッセージ・プロトコルが含まれる。換言すると、プログラマは、このソフトウェア・ドライバ３００が提供するＡＰＩを理解する必要がある。
【００４０】
また、プログラマは、その機能をアクセス可能にするための機構、及びプラットフォーム１０２をＥＣＵに接続する対応するゲートウェイ（図１のゲートウェイ１１８）により使用可能にされる設備の仕様を使用する。
【００４１】
プログラマは、その装置に対して定義される任意の標準のＪａｖａインタフェースの仕様を獲得する。Ｊａｖａインタフェース３０２は、当該Ｊａｖａインタフェース自身を定義するテキスト仕様又はソース・コードの形式で記述される。Ｊａｖａ言語開発環境３０４は、例えば、或る装置又はソフトウェア・サービスに対応するＪａｖａＢｅａｎを定義するために使用される。本発明の好適な実施例に従って、Ｊａｖａ言語開発環境３０４は、ＩＢＭ社から提供される「VisualAge for Java」を用いて実現される。ＥＣＵを表すＪａｖａＢｅａｎの場合、そのＥＣＵ  ＡＰＩ及びメッセージ・プログラミング・プロトコルの詳細が、このプロセスに入力される。一般に、ＪａｖａＢｅａｎは、例えば自動車用バス上にメッセージを送信するなど、低レベルのプログラミング構造体をアクセスするために、Ｊａｖａネイティブ・インタフェース（ＪＮＩ）を用いて構成される。かかる構造体は、通常、Ｃ言語などの低レベルの手続き的言語により実現される。ＪＮＩは、Ｊａｖａネイティブ・メソッドを作成し且つＪａｖａ仮想マシンをネイティブ・アプリケーションに組み込むための、標準のプログラミング・インタフェースである。このインタフェースの主な目標は、所与のプラットフォーム上の全てのＪａｖａ仮想マシンに亘って、ネイティブ・メソッド・ライブラリのバイナリ互換性を提供することである。これらの詳細は、そのバスに通じるゲートウェイに完全に組み込まれ、この場合、ＪａｖａＢｅａｎは、如何なるネイティブ・コードも有する必要はない。もし、かかる規格が定義されなければ、ＪａｖａＢｅａｎは、その装置のための標準のインタフェースを実現しなければならない。これらのインタフェース規格は、開発環境３０４内に入力される。
【００４２】
プログラマは、開発環境３０４を用いて、クラスのセットを作成し、これらのクラスが共同して作用し、ＪａｖａＢｅａｎを作成したり、プロパティ・シートを作成したり、オブジェクトをカストマイズ化し、システム・インテグレータがＪａｖａＢｅａｎを特定のプラットフォームに適応化するための支援をする。
【００４３】
開発環境３０４の出力は、ＪａｖａＢｅａｎコンポーネント３０６である。ＪａｖａＢｅａｎコンポーネント３０６は、一般に、１つ以上のＪａｖａクラス・ファイルから構成され、しばしばＪａｖａアーカイブ（ＪＡＲ）ファイルの形式で伝達される。ＪａｖａＢｅａｎコンポーネント３０６は、図２の登録機構２０４を用いて、レジストリ１０８に入力される。登録機構２０４は、それ自身とコンポーネント・データベース３１０との間のインタフェース３０８を使用し、ＪａｖａＢｅａｎコンポーネント３０６をデータベース３１０に挿入する。この時、プラットフォーム１０２上の装置機能又はソフトウェア・サービスをアクセスするために、ＪａｖａＢｅａｎコンポーネント３０６がアプリケーションにとって使用可能になる。
【００４４】
当業者には明らかなように、この登録プロセスは、いつでも発生し得る。一般に、プラットフォーム１０２の開発初期の段階中に、多くのコンポーネントがそのレジストリ１０８に登録される。しかしながら、これらのコンポーネントは、自動車が生産され、ディーラに出荷され、最終顧客に販売された後にも、レジストリ１０８に追加され得る。本発明によれば、コンポーネント登録が行われ得る時期を制限しないことにより、自動車への新たな装置をその売買後に追加することをサポートできる。
【００４５】
図４には、自動車用ソフトウェア・アプリケーションが、本発明に従ったコンポーネント・モデルを用いて構築されるプロセスが示されている。このプロセスは、アプリケーションの意図された機能である、仕様４００で開始する。仕様４００は、通常、テキスト記述として組み込まれ、これは使用ケース、シナリオ、機能的要件、及び非機能的要件を含み得る。また、このプロセスには、レジストリ１０８の標準インタフェース４０２が入力される。本発明の好適な実施例に従って、標準インタフェース４０２は、Ｊａｖａインタフェースであり、これは任意のプラットフォーム１０２上のレジストリ１０８への、標準のＡＰＩを記述する。更に、Ｊａｖａインタフェース４０４が、装置又はソフトウェア・サービスなどの自動車上のコンポーネントへの入力として使用される。本発明の好適な実施例に従って、Ｊａｖａインタフェース４０４は、プラットフォーム１０２がインタフェースすべき全ての装置に対して、一様又は標準的であるのが好ましい。
【００４６】
プログラマは、ＩＢＭ社の「VisualAge for Java」などのＪａｖａ言語開発環境４０６を使用する。プログラマは、アプリケーションにより必要とされる装置又はソフトウェア・サービス・コンポーネントへの標準インタフェースの他に、レジストリ１０８のインタフェースのための定義をインポートする。開発環境４０６の出力は、Ｊａｖａアプリケーション又はＪａｖａアプレットの形式を有するアプリケーション４０８である。この出力の実施例は、Ｊａｖａクラス・ファイル又はＪａｖａアーカイブ（ＪＡＲ）ファイルである。
【００４７】
ビジュアル・プログラミングは、ソフトウェア開発において使用される重要な生産性ツールである。また、高度自動車用ソフトウェア開発環境は、自動車用アプリケーションの開発及びテストを加速するために、シミュレーション環境を統合できる。或る装置を表すＪａｖａＢｅａｎは、シミュレーション環境に適した当該装置のグラフィック表現を含むように、装置メーカによりプログラムされ得る。アプリケーション開発者は、シミュレーション環境においてＪａｖａＢｅａｎを使用することにより、自分のアプリケーションを開発及びテストできる。これらの一時的なグラフィック表現は、アプリケーションのパッケージ化オペレーションにより除去される。
【００４８】
アプリケーション４０８は、多数の方法により、プラットフォーム１０２上にダウンロードされ得る。即ち、アプリケーション４０８は、プラットフォーム１０２自身と一緒に、その大容量記憶装置１１０内に記憶されるイメージとしてパッケージ化され得る。また、このパッケージ機構は、Ｊａｖａアプリケーション・ファイルをＲＯＭ内に存在し得るコードに変換するツールを使用することにより、アプリケーション４０８をメモリ１０６としてのＲＯＭ内に配置し得る。代替的に、アプリケーション４０８は、前述の登録機構２０４を用いて、レジストリ１０８へのコンポーネントとして導入され得る。また、アプリケーション４０８は、ネットワークを介して動的に、しかしながら安全に、Ｊａｖａアプレットとしてロードされ得る。
【００４９】
当業者には明らかなように、アプリケーション４０８は、開発プロセス中の任意の時点で、プラットフォーム１０２に追加され得る。アプリケーション４０８は、プラットフォーム１０２の製造中にその一部として開発したり、その製造後にレジストリ１０８内のコンポーネントとして追加したり、又はデータ通信ネットワークを介するローディングのためのＪａｖａの安全機構クラスを使用することにより、インターネットからダウンロードできる。
【００５０】
図５には、本発明の好適な実施例に従った、プラットフォーム１０２上で実行中のアプリケーション５００が、装置及びソフトウェア・サービス機能を表すコンポーネントをアクセスする機構が示されている。アプリケーション５００は、前述の発見機構２０６を使用することにより、レジストリ１０８を発見できる。一旦アプリケーション５００がレジストリ１０８の参照を有すると、アプリケーション５００は、ルックアップ機構２０８を使用し、コンポーネント・データベース２００に問い合わせて、必要とされる機能がレジストリ１０８に登録されたコンポーネントにより伝達されるか否かを決定できる。もし、かかるコンポーネントがレジストリ１０８内で使用可能であれば、ルックアップ機構２０８は、アプリケーション５００にそのコンポーネントの参照を返す。この例では、かかるコンポーネントは、ＪａｖａＢｅａｎコンポーネント５０２である。一旦アプリケーション５００がＪａｖａＢｅａｎコンポーネント５０２の参照を有すると、アプリケーション５００は、Ｊａｖａメソッド呼び出しの通常の機構を使用し、ＪａｖａＢｅａｎコンポーネント５０２上のメソッドを呼び出すことにより、装置又はソフトウェア・サービス機能をアクセスできる。
【００５１】
このように、各アプリケーションは、今日の自動車で見いだされる多彩な装置構成上で実行されるように構築され得る。
【００５２】
図６には、本発明の好適な実施例に従った、セキュリティ機構により管理されるコンポーネント・ルックアップのために使用される、レジストリ１０８内のコンポーネントが示されている。アプリケーション６００は、レジストリ１０８内のルックアップ機構２０８を使用し、データベース２００から特定のプロパティ・セットを満足する（例えば、公知の名前に合致するか、又は所与のＪａｖａインタフェースを実現する）或るコンポーネントを要求する。ルックアップ機構２０８は、アプリケーション６００に認証トークン６０２を供給するように要求することにより、コンポーネントへのアクセスを制限する。説明中の例では、認証は、ＣＣＩＴＴ  Ｘシリーズの証明書である、Ｘ５０９証明書を用いて達成され得る。ＣＣＩＴＴ  Ｘシリーズは、公衆アクセス及び専用コンピュータ・ネットワークの両方で使用される機器及びプロトコルを標準化するために、以前のＣＣＩＴＴに当たる国際電気通信連合（ＩＴＵ−Ｔ）及びＩＳＯにより採用された勧告である。証明書は、個人又は組織を識別するファイルである。証明書は、当該証明書の所有者の識別を証明するために使用される情報を暗号化し得る。説明中の例では、証明書は、それを保持するスマート・キー６０４から検索され得る。
【００５３】
実施例に拘わらず、このトークンは、自動車の保有者から無数の方法で検索され得る。これらの方法には、顧客への引渡し前にディーラが車両を用意する間にイグニション・キー上にＸ５０９証明書を符号化すること、保有者にシステム・ログオンを実行するように要求すること（ユーザＩＤ／パスワードの組み合わせを認証として使用する）、及び保有者に関連付けられる音声パターンを記録し、プラットフォーム１０２により発行されるシステム・グリーティング／チャレンジに応答して、音声認識に基づき保有者を認識することなどが含まれる。
【００５４】
レジストリ１０８内のデータベース６０４は、認証トークン（Ｘ５０９、音声認識、ユーザＩＤ／パスワード）の好適な実施例のインスタンスを、１つ以上のユーザ・プロファイルと突き合わせる。一意的なパスワード・プロファイルに加えて、標準のユーザ・プロファイルがプラットフォーム１０２に関連付けられ、それらにはゲスト、所有者、運転手、乗客、認可機械工、認可販売店機械工、認可工場技術者などが含まれる。また、プラットフォーム１０２上に導入されるシステム・サービス又は第３者アプリケーションにより定義され、それらに特有の他のユーザ・プロファイルも存在する。データベース６０４は、例えばＸ５０９公開キー連鎖などの多数の方法で実現され得る。
【００５５】
ルックアップ機構２０８は、ルックアップ要求を、コンポーネント・データベース２００内で見いだされる全ての適したコンポーネントと突き合わせる。
【００５６】
説明中の例では、ルックアップ機構２０８は、ユーザ・プロファイルを保持するデータベース６０４を同時にアクセスし、アプリケーション６００により提出されたルックアップ要求に関連付けられるユーザ・プロファイルを確立する。アプリケーション６００により供給される認証トークン６０２に関連付けられるユーザ・プロファイルに基づき、ルックアップ機構２０８は、そのユーザ・プロファイルに関連付けられる特権に合致しないコンポーネントを除去することにより、提出された要求に合致するコンポーネントのセットを低減する。
【００５７】
もし、照会要求及びユーザ・プロファイルに合致する任意のコンポーネントが存在すれば、コンポーネントの１つがアプリケーション６００に返される。説明中の例では、もし、ユーザ・プロファイルの特権を満足し且つルックアップ基準に合致する２つ以上のコンポーネントが存在すれば、ルックアップ機構２０８は、最も多くの機能を保持するコンポーネントを返す。一方、これらの制限を満足するコンポーネントが全く存在しなければ、値ヌルがアプリケーション６００に返され、如何なるコンポーネントも使用可能でないことを示す。合致が不在の場合、レジストリ１０８の応答は、幾つかの形式を取り得る。例えば、レジストリ１０８は、サービスが使用可能でないことを示す例外を発するか、又は装置を使用不能にすることがある（厳格なケースでは、これは、明白な攻撃に対する最善の応答である。なぜなら、ディーラ又は認可された管理者は、ＪａｖａＢｅａｎを再度「使用可能にする」ことを必要とするからである。）。代替的に、レジストリ１０８がＪａｖａＢｅａｎをそのままに維持しつつ、（防御体制同様）それをアクセスするために要求されるセキュリティを増加するようにしてもよい。或いは、レジストリ１０８は、恰もデータベース２００内に対応するエントリが存在しなかったかのように的確に応答し、そのためにアプリケーション６００が、「装置が存在しない」ことと、「装置が存在するが、それを見る権限が無い」こととの違いを区別できないようにしてもよい。
【００５８】
図７及び図８には、本発明の好適な実施例に従った、レジストリ１０８内に含まれるデータベース内のエントリを示すテーブルが示されている。図７のテーブル７００は、データベース６０４内のユーザ・プロファイルに対するエントリを示すテーブルであり、図８のテーブル７０２は、データベース２００内のコンポーネントに対するエントリを示す。テーブル７０２内の各エントリは、当該エントリに関連付けられるコンポーネントの参照（図示せず）を含む。この参照は、標準のＪａｖａ参照である。テーブル７００では、プロファイル名が認可レベルに関連付けられている。従って、ルックアップ機構２０８は、これを使用することにより、アプリケーション内の基準に合致する或るコンポーネントが、そのアプリケーションに返されるべきか否かを決定できる。説明中の例では、エントリ７０４は認可レベル６を有する運転手であり、エントリ７０６は認可レベル５を有する所有者であり、エントリ７０８は認可レベル４を有する第３者機械工であり、エントリ７１０は認可レベル３を有するディーラであり、エントリ７１２は認可レベル２を有するメーカであり、エントリ７１４は認可レベル１を有する設計者である。エントリ７０４内の運転手のプロファイルは、車両の各運転手ごとに一意的にすることができる。
【００５９】
テーブル７０２では、コンポーネントが認可レベルに関連付けられている。従って、ルックアップ機構２０８は、テーブル７００内のユーザ・プロファイル・エントリ内で定義されるユーザの認可レベルに基づき、コンポーネントをアプリケーション６００に返すべきか否かを決定できる。説明中の例では、エントリ７１６は認可レベル６を有するステレオ・コンポーネントを含み、エントリ７１８は認可レベル６を有する燃料計器コンポーネントを含み、エントリ７２０は認可レベル４を有する燃料注入コンポーネントを含み、エントリ７２２は認可レベル６を有するパワー・シート・コンポーネントを含み、エントリ７２４は認可レベル４を有する標準エンジン診断コンポーネントを含み、エントリ７２６は認可レベル５を有するＧＰＳ（衛星航法システム）航行コンポーネントを含み、エントリ７２８は認可レベル１を有する所有権的エンジン診断コンポーネントを含む。この例では、もし、或るユーザの認可レベルが或るコンポーネントに関連付けられる認可レベル以下であれば、そのコンポーネントとそのユーザとの間の合致が発生する。
【００６０】
実現され得る別の機構は、コンポーネント・タイプ及び要求との正確な合致を必要とするものであろう。即ち、そのタイプを実現する各コンポーネントが調査され、当該コンポーネントが有するアクセス権のリストを、要求を発するユーザの認可レベルと比較する、ということである。かかるケースでは、或るコンポーネント・タイプに対して多数のコンポーネントが存在し、各コンポーネントが異なる量の機能を提供し得る。例えば、図９には、本発明の好適な実施例に従った、或るオブジェクト又はコンポーネント・タイプに対する複数のオブジェクトを保持するテーブル７３０が示されている。図７及び図８のテーブル７００及び７０２同様、このテーブル７３０はレジストリ１０８内に配置され得る。この例では、エントリ７３２〜７４２は全て、エンジン診断として識別されるコンポーネント・タイプに対するエントリである。各エントリは、このコンポーネント・タイプに加え、認可レベル、及びコンポーネントを表すオブジェクトの識別を保持する。説明中の例では、エンジン診断を要求したアプリケーションは、認可レベルに基づく結果を受信するであろう。もし、認可レベルが４以下であれば、このアプリケーションは、エントリ７３６〜７４２内で識別されるオブジェクトの１つを返されるであろう。エントリ７３６〜７４２内のこれらのオブジェクトは、同一のコンポーネントの異なるバージョンであり、異なる量の機能又は異なる数の機能へのアクセスを提供できる。代替的に、これらが完全に異なる機能を提供するようにしてもよい。
【００６１】
もし、アプリケーション６００の認可レベルが５又は６であれば、ヌル・パラメータがエントリ７３２及び７３４内で見いだされる。かかる例では、アプリケーション６００は、要求に合致するソフトウェア・コンポーネントが存在しない、或いはそのコンポーネントへのアクセスが許可されないことを示す結果を返されるであろう。もし、認可レベルが２であれば、エンジン診断コンポーネントとして識別されるタイプを有するコンポーネントに対する要求に応答して、エントリ７４０内のオブジェクト３がアプリケーション６００に返されるであろう。説明中の例では、アプリケーション６００が認可レベルに基づき、２つ以上のコンポーネントをアクセスすることが許可される場合、最善のコンポーネント又は最も高いレベルの機能を有するコンポーネントが、アプリケーション６００に返されるであろう。例えば、もし、アプリケーション６００が２つのコンポーネントをアクセスすることを許可され、一方のコンポーネントが使用可能なより多くの機能又はメソッドを有していれば、そのコンポーネントがアプリケーション６００に返されるであろう。
【００６２】
ルックアップ機構２０８に拘わらず、装置又はサービス「ＪａｖａＢｅａｎ」により伝達される機能が、要求に関連付けられる認可レベルに依存して、制限されたサービス・レベルを有することがあるという要件が存在する。例えば、エンジン診断では、この情報を提供するサービスが、３つの認可レベル（即ち、所有者、車庫機械工、及びメーカ技術者）を有することがある。所有者の認可レベルに関連付けられるエンジン診断「ＪａｖａＢｅａｎ」は、全くアクセスを許可しない。車庫機械工に関連付けられるエンジン診断「ＪａｖａＢｅａｎ」は、全てのエンジン診断ＡＰＩ定義を実現され得るが、それ以外のものはない。最後に、メーカ技術者の認可レベルに関連付けられる「ＪａｖａＢｅａｎ」は、標準のエンジン診断ＡＰＩ全体に加え、専用の所有権的エンジン・データをアクセスする追加のメソッドを有するであろう。
【００６３】
図１０には、本発明の好適な実施例に従った、ＪａｖａＢｅａｎコンポーネントを作成するプロセスの流れ図が示されている。図示の例は、装置に対するＪａｖａＢｅａｎコンポーネントの作成に関連するが、このプロセスはソフトウェア・サービスに対するＪａｖａＢｅａｎコンポーネントの作成にも適用され得る。
【００６４】
図１０のプロセスは、ＪａｖａＢｅａｎコンポーネントが作成される装置を識別することにより開始する（ステップ８００）。次に、その装置に対するＪａｖａインタフェースが識別される（ステップ８０２）。ステップ８０２では、その装置が通信するインタフェースが識別される。殆どの場合、その装置が標準のＪａｖａインタフェースを使用することが好ましい。もし、その装置により他のインタフェースが使用されるならば、ＪＮＩを介して当該ＪａｖａＢｅａｎコンポーネントと共に使用されるインタフェースを作成することが可能である。
【００６５】
次に、そのＪａｖａＢｅａｎコンポーネントが表すべきその装置の機能に基づいて、メソッドがそのＪａｖａＢｅａｎコンポーネントに対して選択される（ステップ８０４）。ＪａｖａＢｅａｎコンポーネント内のメソッドは普通のＪａｖａメソッドであり、他のコンポーネント又はスクリプト記述環境から呼び出すことができる。次に、そのＪａｖａＢｅａｎコンポーネントに対して、プロパティがセットされる（ステップ８０６）。プロパティは、或るビーン（bean）に関連付けられる名前付き属性であり、当該ビーン上の適切なメソッドを呼び出すことにより読み書きされ得る。次に、そのＪａｖａＢｅａｎコンポーネントに対してイベントが選択される（ステップ８０８）。イベントは、或るコンポーネントにとって、何か興味深いことが発生したことを他のコンポーネントに通知する一方法を提供する。これらのコンポーネントは、他のビーンであり得る。その後、そのＪａｖａＢｅａｎコンポーネントが作成され（ステップ８１０）、その後プロセスは終了する。
【００６６】
図１１には、本発明の好適な実施例に従った、ＪａｖａＢｅａｎコンポーネント及び関連ユーザ・プロファイルのセットを登録するために使用されるプロセスの流れ図が示されている。例えば、自動車のエンジン診断を表すＪａｖａＢｅａｎについて考えてみよう。エンジン診断「ＪａｖａＢｅａｎ」は、Ｊａｖａで定義される標準のエンジン診断サービス・インタフェースに基づく。説明の便宜上、このインタフェースが１２個のメソッドを定義するとしよう。
【００６７】
エンジン診断サブシステムのメーカは、選択されたインタフェースを実現する１つ以上のＪａｖａＢｅａｎコンポーネントを定義し得る（ステップ９００）。ステップ９００で開発される各ＪａｖａＢｅａｎコンポーネントは、標準のエンジン診断インタフェースを実現し、異なる機構を使用する。各ＪａｖａＢｅａｎコンポーネントは、或るユーザ・プロファイルに関連付けられる（ステップ９０２）。ＪａｖａＢｅａｎのプロパティを用いて、ユーザ・プロファイルの集合と、装置又はソフトウェア・サービス「ＪａｖａＢｅａｎ」との間の関連付けが行われる。
【００６８】
例えば、そのメーカは、そのユーザ・プロファイルの「ゲスト」に関連して、１つのＪａｖａＢｅａｎ実現体を作成し、更にそのユーザ・プロファイルの「所有者」に対して１つ、そのユーザ・プロファイルの「車庫機械工」に対して１つ、及びそのユーザ・プロファイルの「工場技術者」に対して１つのＪａｖａＢｅａｎ実現体をそれぞれ作成するように決定する。「ゲスト」ユーザ・プロファイルに関連付けられる実現体は、例外「UnsupportedOperationException」を発するための、インタフェースの１２個の全てのメソッドを実現する。「所有者」ユーザ・プロファイルに関連付けられるＪａｖａＢｅａｎは、単純な読出し専用アルゴリズムを使用する６個のメソッドを実現し、他の６個のメソッドに対して「UnsupportedOperationException」を発する。「車庫機械工」バージョンは、２個のメソッドを除く全てを適切に実現され、最後の２個のメソッドは、詳細な所有権的エンジン診断データに関連付けられ、「UnsupportedOperationException」を発する。最後に、インタフェースの最も完全な実現体は、「工場技術者」に関連付けられ、１２個のメソッドの完全で詳細な実現体を有する。
【００６９】
ＪａｖａＢｅａｎのセットは、前述の登録機構２０４を用いてレジストリ１０８に登録される（ステップ９０４）。登録機構２０４は、各ＪａｖａＢｅａｎコンポーネントを、コンポーネント・データベース２００に登録する（ステップ９０６）。セット内の各ＪａｖａＢｅａｎに対して、登録機構２０４は、そのＪａｖａＢｅａｎのユーザ・プロファイルのプロパティを問い合わせ、もし、そのＪａｖａＢｅａｎにより定義された新たなユーザ・プロファイルが存在すれば、ユーザ・プロファイルのデータベース６０４を更新する（ステップ９０８）。ステップ９０６及び９０８は、説明中の例では同時に実行される。
【００７０】
図１２には、本発明の好適な実施例に従った、前述のルックアップ機構２０８内で使用されるプロセスの流れ図が示されている。アプリケーションがルックアップ機構２０８を使用し、必要とされたインタフェースを実現するＪａｖａＢｅａｎコンポーネントの参照を確立する。アプリケーションが車両内の装置又はサービスをアクセスすることを望むとき、そのアプリケーションは、その装置又はサービスに対するレジストリ１０８内のルックアップ機構２０８に要求を送信する。もし、その装置又はサービスに合致するコンポーネントがレジストリ１０８内に存在し、しかもそのアプリケーションがそのコンポーネントへのアクセスを許可されていれば、前記要求に応答して、そのコンポーネントの参照がそのアプリケーションに返されるであろう。
【００７１】
このプロセスは、特定のインタフェースを実現するＪａｖａＢｅａｎコンポーネントにより表される装置又はサービスに対する要求を受信することにより開始する（ステップ１０００）。この要求は、特定の機能又はサービスに対するものである。説明中の例では、認証トークンがその要求の一部として受信される。次に、データがその認証トークンから抽出され、要求されたＪａｖａＢｅａｎコンポーネントのためにユーザの認証を実行する（ステップ１００２）。認証トークンから抽出されたこのデータは、ユーザ・プロファイル名を含む。認証トークンから抽出された情報を用いて、ユーザ・プロファイルを保持するデータベース６０４が照会される（ステップ１００４）。結果がデータベース６０４から受信される（ステップ１００６）。この結果は、図７に示されるような認可レベルを保持する。コンポーネントを保持するデータベース２００も照会される（ステップ１００８）。ステップ１００４及び１００８は、説明中の例では同時に実行される。結果がこの照会から受信される（ステップ１０１０）。この例では、結果は、要求された機能又はサービスに合致する１つ以上のコンポーネントである。
【００７２】
ステップ１００４及び１００８からの結果を受信した後、ＪａｖａＢｅａｎコンポーネントをアプリケーションに返すべきか否かが決定される（ステップ１０１２）。この決定は、説明中の例では、ユーザ・プロファイルの認可レベルをＪａｖａＢｅａｎコンポーネントに対して必要とされる認可レベルと比較することにより行われる。図７及び図８に示される認可レベルに基づき、合致が発生するのは、そのユーザの認可レベルがそのＪａｖａＢｅａｎコンポーネントに関連付けられる認可レベル以下である場合である。もし、そのＪａｖａＢｅａｎコンポーネントがアプリケーションに返されるのであれば、そのＪａｖａＢｅａｎコンポーネントのＪａｖａ参照がそのアプリケーションに送信され（ステップ１０１４）、このプロセスはその後終了する。もし、ステップ１０１０で、２つ以上のコンポーネントが返されたのであれば、最も多くのフィーチャを有する機能又は装置が返されるか、最も最近の改訂データを有する装置又は機能が返され得る。一方、ＪａｖａＢｅａｎコンポーネントがそのアプリケーションに返されないのであれば、ヌル値が返され（ステップ１０１６）、このプロセスはその後終了する。この値は、要求された装置又はサービスに対応するＪａｖａＢｅａｎコンポーネントが、レジストリ１０８内に不在であることをそのアプリケーションに示すために使用される。
【００７３】
図１３には、本発明の好適な実施例に従った、車両のユーザ又は運転手がログオンするために使用するプロセスの流れ図が示されている。このプロセスは、車両のイグニションへのスマート・キーの挿入を検出することにより開始する（ステップ１１００）。前述のように、スマート・キーは、証明書を記憶する回路を含む。認証情報がスマート・キーから受信される（ステップ１１０２）。次に、証明書から認証トークンが作成され（ステップ１１０４）、その後このプロセスは終了する。代替的に、ユーザは、ユーザ名及びパスワードを介して、又はこれらの入力が認証トークンを作成するために使用される音声認識システムを通してログオンしてもよい。
【００７４】
従って、本発明は、装置機能及びソフトウェア・サービスをＪａｖａベースのアプリケーションに効率的に受け渡す機構を提供する。本発明は、使用可能な可変の装置群及びソフトウェア・サービスを有し得る車両上のプラットフォーム内でＪａｖａコンポーネントを使用する。このプラットフォームは、アプリケーションがこれらの装置を見いだし且つアクセスすることを可能にする。
【００７５】
結果として、本発明は、自動車上の装置の機能及びソフトウェア・サービスが、プラットフォームのモジュール式コンポーネントとして設計され得る技術を提供する。本発明が提供する技術によれば、プラットフォームのアプリケーションは、ソフトウェア・コンポーネント・モデルを通して当該プラットフォーム上で使用可能な機能を発見し且つこれを利用するように設計され、構築され得る。本発明は、装置コンポーネントが標準ＡＰＩ定義を使用する機構を通してこれらの利点を提供する。即ち、アプリケーションは、プラットフォームの特定の装置又はソフトウェア・サービスに特有の、低レベルの実現の詳細に基づくのではなしに、これらの標準インタフェースに基づき、装置及びソフトウェア・サービスをアクセスするように構築される。
【００７６】
本発明は、完全機能型のデータ処理システムに関連して説明されてきたが、当業者であれば、本発明のプロセスが、命令のコンピュータ読取り可能媒体の形式及び様々な形態で分散され得ること、本発明がこの分散を実施するために実際に使用される特定タイプの信号担持媒体に拘わらず、同様に適用可能であることが理解できよう。コンピュータ読取り可能媒体の例には、フロッピー・ディスク、ハード・ディスク・ドライブ、ＲＡＭ及びＣＤ−ＲＯＭなどの記録型媒体、及びデジタル及びアナログ通信リンクなどの伝送型媒体が含まれる。
【００７７】
本発明の説明は、例示のために提供されたものであり、本発明がここで開示された形態に限定されることを意図するものではない。当業者であれば、多くの変更及び変形が明らかであろう。例えば、図示の例は自動車に関連付けられたが、本発明のプロセス、装置及び命令は、他のタイプの車両にも適用され得る。例えば、本発明は、飛行機やヘリコプタなどの航空機において使用され得る。更に、本発明の装置、プロセス及び命令は、Ｊａｖａ以外の他のプログラミング・システムにも適用され得る。例えば、本発明は、Ｓｍａｌｌｔａｌｋなどの、他のバイトコード・ベースのシステムにも適用され得る。ここで開示された実施例は、本発明の原理及び実際のアプリケーションを最も良く説明するために、また当業者が本発明を理解し、特定の使用に適した様々な変更を有する様々な実施例に対応するために選択されたものである。
以下に、本発明の内容を開示する。
（１）  アプリケーション・プログラムを実行する自動車用コンピュータ・システムであって、
複数の電子制御ユニットと、
前記複数の電子制御ユニットに少なくとも１つのバスによって接続されたコンピュータ・プラットフォームと
を含み、
前記コンピュータ・プラットフォームは、
複数のＪａｖａＢｅａｎと、
前記複数のＪａｖａＢｅａｎをアクセスするルックアップ機構と、
前記複数のＪａｖａＢｅａｎを保持するデータベースと、
前記ルックアップ機構と、前記データベースと発見機構とを含むレジストリと
を含み、
ここで前記複数の電子制御ユニットの各々は、当該複数の電子制御ユニットの各々用の異なるソフトウェア・ドライバを利用して、前記コンピュータ・プラットフォームと通信し、及び前記アプリケーション・プログラムは、前記複数の電子制御ユニットのいずれとも又は各電子制御ユニット用の前記ソフトウェア・ドライバのいずれとも直接的にインタフェースせず、
前記複数のＪａｖａＢｅａｎの各々は、前記複数の電子制御ユニットのうちの１つの電子制御ユニットに関連付けられ且つ当該１つの電子制御ユニットの機能をそれぞれ表すものであり、当該１つの電子制御ユニットの前記機能へのアクセスは、当該１つの電子制御ユニットに関連付けられる当該ＪａｖａＢｅａｎを介して提供され、前記複数のＪａｖａＢｅａｎの各々は、前記アプリケーション・プログラムと当該ＪａｖａＢｅａｎに関連付けられる１つの前記電子制御ユニット用のソフトウェア・ドライバとの間のソフトウェア・インタフェースであり、及び前記複数のＪａｖａＢｅａｎの各々は、当該１つの電子制御ユニットとは直接的にインタフェースしないものであり、
前記コンピュータ・プラットフォームは、前記複数の電子制御ユニットのうちの１つの電子制御ユニットの前記機能をアクセスするための要求を受信すると、前記発見機構を使用して、前記レジストリを発見し及び参照し、次いで前記ルックアップ機構を使用して、該レジストリ内のデータベースに格納された、前記１つの電子制御ユニットに関連付けられる１つのＪａｖａＢｅａｎを受け取って前記１つの電子制御ユニットに返す、前記自動車用コンピュータ・システム。
（２）  前記複数の電子制御ユニットの１つが燃料計器センサである、請求項１に記載の自動車用コンピュータ・システム。
【図面の簡単な説明】
【図１】本発明が実施され得る自動車上の典型的なコンピュータ環境を示すブロック図である。
【図２】自動車用コンピュータ・プラットフォーム上で見いだされるプログラム・コンポーネントのレポジトリを表すブロック図である。
【図３】ＪａｖａＢｅａｎコンポーネントが構築され、レポジトリに登録されるプロセスを示す図である。
【図４】ソフトウェア・アプリケーションがＪａｖａＢｅａｎｓを用いて構築されるプロセスを示す図である。
【図５】ソフトウェア・アプリケーションが自動車用コンピュータ・プラットフォーム上のレジストリを発見し、このレジストリに必要とされたＪａｖａＢｅａｎ機能を問い合わせ、装置機能又はソフトウェア・サービスを表すＪａｖａＢｅａｎの参照を獲得するプロセスを示す図である。
【図６】本発明の好適な実施例に従った、セキュリティ機構により管理されるコンポーネント・ルックアップのために使用される、レジストリ内のコンポーネントを示す図である。
【図７】本発明の好適な実施例に従った、レジストリに含まれるデータベース内のエントリのテーブルを示す図である。
【図８】本発明の好適な実施例に従った、レジストリに含まれるデータベース内のエントリのテーブルを示す図である。
【図９】本発明の好適な実施例に従った、オブジェクト又はコンポーネント・タイプに対する複数のオブジェクトを含むテーブルを示す図である。
【図１０】本発明の好適な実施例に従った、ＪａｖａＢｅａｎコンポーネントを作成するプロセスの流れ図である。
【図１１】本発明の好適な実施例に従った、ＪａｖａＢｅａｎコンポーネント及び関連ユーザ・プロファイルのセットを登録するために使用されるプロセスの流れ図である。
【図１２】本発明の好適な実施例に従った、レジストリ内のルックアップ機構内で使用されるプロセスの流れ図である。
【図１３】本発明の好適な実施例に従った、車両のユーザ又は運転手がログオンするために使用されるプロセスの流れ図である。
【符号の説明】
１００  自動車
１０２  コンピュータ・プラットフォーム
１０８  コンポーネント・レジストリ
１１２  ソフトウェア・コンポーネント
１１４ａ、１１４ｂ、１１４ｃ  電子制御ユニット（ＥＣＵ）
１２６  エンジン機能診断コンソール
２００  コンポーネント・データベース
２０２ａ、２０２ｂ、２０２ｃ  コンポーネント
２０４  登録機構
２０６  発見機構
２０８  ルックアップ機構
【図１】
0003851042.tif 000002
【図２】
0003851042.tif 000003
【図３】
0003851042.tif 000004
【図４】
0003851042.tif 000005
【図５】
0003851042.tif 000006
【図６】
0003851042.tif 000007
【図７】
0003851042.tif 000008
【図８】
0003851042.tif 000009
【図９】
0003851042.tif 000010
【図１０】
0003851042.tif 000011
【図１１】
0003851042.tif 000012
【図１２】
0003851042.tif 000013
【図１３】
0003851042.tif 000014