(57)【要約】      （修正有）【課題】オペレータとターゲットプラットフォームに配置された電子装置の機能コアとのソフトウェアインタフェースの作成サイクルを短くし、設計上の柔軟性を与えられるようにする。【解決手段】プラットフォームの制御要素に対応するインタフェース視覚要素が配置された設計ウィンドウと、要素が機能的に接続している状態機械とを含む設計モジュール２００と、設計モジュール２００から発せられたデータが機能コア３３１，３３２，３３３の特性とマッチするかどうかをテストする検証モジュール２１０と、検証モジュール２１０から発せられたデータを変換しプラットフォームの管理要素に送信する翻訳ユニット２３１を含む、制御要素によって機能コア３３１，３３２，３３３をシミュレートするためのターゲットプラットフォーム３００のシミュレーションモジュール２３０と、を備える。【選択図】図１
2009003918.tif 000002
【特許請求の範囲】
【請求項１】
オペレータ（４０１）と、ターゲットプラットフォーム（３００）に配置された電子装置の機能コア（３３１、３３２、３３３）と、の間のソフトウェアインタフェースの自動作成システムであって、
設計モジュール（２００）と、検証モジュール（２１０）と、前記ターゲットプラットフォーム（３００）のシミュレーションモジュール（２３０）と、を備え、
前記設計モジュール（２００）は、前記プラットフォーム（３００）の制御要素（３１０）に対応する複数のインタフェース視覚要素（１０、２１、２２、２３、２４）が配置された設計ウィンドウ（１）と、前記複数のインタフェース視覚要素（１０、２１、２２、２３、２４）が機能的に接続されている状態機械（１００）と、を含み、
前記検証モジュール（２１０）は、前記設計モジュール（２００）から発せられたデータが前記機能コア（３３１、３３２、３３３）の特性とマッチするかどうかをテストし、
前記シミュレーションモジュール（２３０）は、前記検証モジュールから発せられたデータを変換し前記ターゲットプラットフォーム（３００）の管理要素（３２０）に送信する翻訳ユニット（２３１）を含み、前記制御要素（３１０）によって前記機能コア（３３１、３３２、３３３）をシミュレートする、
ソフトウェアインタフェースの自動作成システム。
【請求項２】
前記検証モジュール（２１０）から発せられたデータを、電子装置の機能コア（３３１、３３２、３３３）と接続せずにシミュレートするように構成されたソフトウェアデバイスプラットフォームのシミュレーションモジュール（２２０）を備える、請求項１記載のソフトウェアインタフェースの自動作成システム。
【請求項３】
前記インタフェースが、ソフトウェアデバイスプラットフォームのシミュレーションモジュール（２２０）に接続されたコンピュータ（２５０）によってシミュレートされる、請求項２記載のソフトウェアインタフェースの自動作成システム。
【請求項４】
前記電子装置の機能コア（３３１、３３２、３３３）から発せられたデータがコンピュータモニタ（２５０）に表示される、請求項３記載のソフトウェアインタフェースの自動作成システム。
【請求項５】
前記インタフェース視覚要素（１０、２１、２２、２３、２４）は、前記電子装置の機能コア（３３１、３３２、３３３）の特性に対応する属性を備えている、請求項１乃至４のいずれか１項に記載のソフトウェアインタフェースの自動作成システム。
【請求項６】
前記状態機械（１００）は、前記インタフェースの種々の起こり得る状態を表す複数のブロック（５１、５２、５３）を含み、前記複数のブロック（５１、５２、５３）は前記種々の状態間の遷移手段を表すリンクによって接続されている、請求項１記載のソフトウェアインタフェースの自動作成システム。
【請求項７】
前記翻訳ユニット（２３１）は、前記電子装置の機能コア（３３１、３３２、３３３）に応じてパラメータ化される、請求項１記載のソフトウェアインタフェースの自動作成システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両における人と電子装置との間の通信の分野に関する。
【背景技術】
【０００２】
従来では、ＣＤプレーヤーなどの電子装置と通信するために、ユーザはＣＤの再生や曲の変更を開始する目的でボタン、ローレットホイール、カーソルなどのプレーヤーの制御要素を操作する。
ところが運搬車両、より具体的に言うと自動車の電子装置の数が増えたことによって、ダッシュボード上の制御要素の数を制限する必要が出てきた。実際にはダッシュボードの表面は制限されているので、その上にこういった装置それぞれの制御要素を配置するのは不可能である。
【０００３】
限られた数の制御要素で多数の電子装置と通信するためには、要素とプラットフォームに配置される装置の機能コアとのソフトウェアインタフェースを実現する必要がある。分かりやすくするため、そしてコアの意味を説明するために、ＣＤプレーヤーの機能コアは、例えば、再生レンズ、レーザヘッド、ＣＤを回転させるための手段を含む。ソフトウェアインタフェースを通じて、幾つかの機能コアを制御するために制御要素を使用できる。
【０００４】
ソフトウェアインタフェースの実現は、多数のステップを伴う長く要求の厳しいプロセスである。
【０００５】
従来では、こういったプロセスは、トレーシングペーパー上に種々の色の付いた形を使用して装置の機能コアの制御に必要な制御要素を図式化するステップを伴う理論上の「プロトタイピング」ステップを含む。例えば、ラジオ受信機を含む自動車ラジオの場合、表示領域を表す矩形とボタンを表す色の付いた円盤がトレーシングペーパー上に定義される。
【０００６】
プロトタイピングステップは、制御要素と装置の機能コアとの関係を定義できるようにした仕様の作成を含むステップを伴う。したがって前の例に戻って言うと、この仕様では、ボタンを作動させるとラジオ受信機が作動して捕獲した局の名前や歌のタイトルを表示領域に送信するということが規定されている。こういった仕様によって、ソフトウェアインタフェースの要求を定義することができる。
【０００７】
コーディングステップでは、仕様を種々の装置の機能コアが解釈できる言語に翻訳する。
【０００８】
一般的に言うと、電子装置は実行の速度やエラーのチェックを向上させるいわゆる「低レベル」言語は解釈することができ、こういったコーディングタイプはあらゆる車載システムで従来から使用されている。こういった言語は、グラフィックスを強化するプロトタイプの実現のために使用するいわゆる「高レベル」言語とは対照的である。
【０００９】
コーディングステップは仕様書に基づいており、機能コアそれぞれについて個別的に実施される。その理由は、ここでも先の例で説明すると、ヘルツラジオ受信機を有する自動車ラジオと衛星ラジオ受信機を有する自動車ラジオについて個別のコーディングを実行する必要があるためである。生成したコードを車両に配置されている管理モジュールに送信する。この管理モジュールは、制御要素と機能コアとの通信を自律的に管理する。
【００１０】
ソフトウェアインタフェースの作成は、制御要素と機能コアとの通信をこの要素を操作するユーザがテストする実際のシミュレーションステップで完了する。
【発明の開示】
【発明が解決しようとする課題】
【００１１】
インタフェースを作成するこういった従来のプロセスには、多数の欠点がある。
【００１２】
コーディングステップの際、技術上の理由から仕様書が厳密に順守されず、その結果機能または表示モードをコーディングできない事態が起こり得る。
【００１３】
さらに、仕様を作成した時に既に承認したトレーシングペーパーのグラフィックスがもはや不適当であるといった事態もよくあることである。そうなるとプロトタイプを再度定義し、仕様を修正し、ソフトウェアインタフェースを再度コーディングしなければならない。それまでの設計ステップを繰り返すことによって、設計サイクルが延長してしまう。
【００１４】
またさらに、機能コアの物質的な修正がインタフェースの設計中に生じる可能性もある。そのため、仕様を認証したにも関わらず幾つかの機能が削除または追加されるため、ソフトウェアインタフェースの作成を再度始めなければならない。
【００１５】
ソフトウェアインタフェース、いわゆるヒューマン・マシーンインタフェース（ＨＭＩ）の作成は、緻密で時間のかかるプロセスである。柔軟性に欠けるために、制御要素と機能コアとの通信がうまくいくという保証も一切ないまま設計ステップを繰り返さなければならない。
【課題を解決するための手段】
【００１６】
本願の発明は、こういった欠点の克服を目的とする。そのために、本発明は、オペレータと、ターゲットプラットフォームに配置された電子装置の機能コアと、の間のソフトウェアインタフェースの自動作成システムに関し、このシステムは、
プラットフォームの制御要素に対応する複数のインタフェース視覚要素が配置された設計ウィンドウと、複数のインタフェース視覚要素が機能的に接続されている状態機械と、を含む設計モジュールと、
この設計モジュールから発せられたデータが、前記機能コアの特性とマッチするかどうかをテストする検証モジュールと、
検証モジュールから発せられたデータを変換しプラットフォームの管理要素に送信する翻訳ユニットを備えており、前記制御要素によって前記機能コアをシミュレートするためのターゲットプラットフォームのシミュレーションモジュールと、を備える。
【００１７】
本発明のシステムによって、有利には、インタフェースの作成サイクルを短くできると同時に、設計上の柔軟性を与えることができる。本発明の作成システムは多目的型で、あらゆる種類の装置に適応できる。
【００１８】
好ましくは、本発明のシステムは、検証モジュールからのデータを、電子装置の機能コアと接続せずにシミュレートするように構成されたソフトウェアデバイスプラットフォームのシミュレーションモジュールを備えている。
【００１９】
したがって、物理的な装置に依存せずに本発明のインタフェースをテストできるため、こういった装置が利用不可能な場合にインタフェース作成が遅くなってしまう事態を回避できる。
【００２０】
さらに好ましくは、本発明のインタフェースは、ソフトウェアデバイスプラットフォームのシミュレーションモジュールに接続されたコンピュータによってシミュレートされる。
【００２１】
さらに好ましくは、電子装置の機能コアからのデータは、コンピュータモニタに表示される。
【００２２】
好ましくは、インタフェース視覚要素は、電子装置の機能コアの特性に対応する属性を備えている。
【００２３】
こういったことによって、視覚要素と機能コアとの不適合を一切懸念することなく、アプリケーションをターゲットプラットフォームで有利に実施できる。
【００２４】
さらに好ましくは、状態機械はインタフェースの種々の起こり得る状態を表す複数のブロックを含み、こういったブロックが種々の状態間の遷移手段を表すリンクによって接続されている。
【００２５】
さらに好ましくは、ターゲットシミュレーションモジュールの翻訳ユニットは、電子装置の機能コアに応じてパラメータ化されている。
【００２６】
本発明は、以下の説明と添付図面によってよりよく理解されるであろう。
【発明を実施するための最良の形態】
【００２７】
自動車は、レジャー用の電子装置（ＣＤ／ＤＶＤプレーヤー、ラジオ受信機）、あるいは、運転に直接関係する目的のために使用する電子装置（ＧＰＳ受信機、レーダー探知機）を数台搭載している。ラジオ受信機のみを搭載した自動車の場合、当該ラジオ受信機の制御要素が、このラジオ受信機を制御するために用いられ、制御要素としては、可動カーソルやプッシュボタンまたは回転ボタンが含まれる。
【００２８】
車両がこういった装置の幾つかを搭載している場合、自動車のダッシュボードの上に全ての装置の制御要素を配置するのは不可能である。
【００２９】
そこで、制御要素を有する種々の装置を、そういった装置の機能コアを集めたレジャー用プラットフォームに置き換える。ＣＤプレーヤーの機能コアは、例えば、再生レンズ、レーザヘッド、ＣＤを回転させるための手段を含む。限られた数の制御要素で多数の電子装置と通信するためには、こういった要素と装置の機能コアとの間のソフトウェアインタフェースを実施することが必要になる。
【００３０】
こういったソフトウェアインタフェースの自動作成システムについて説明する前に、ラジオ受信機の機能コア３３１、ＣＤプレーヤーの機能コア３３２、ＧＰＳユニットの機能コア３３３を含む、自動車用のマルチメディアレジャープラットフォーム３００を一例として参照して種々の構成モジュールについて詳細に言及する。
【００３１】
このターゲットプラットフォーム３００は、プッシュボタン、回転ボタン、そして液晶ディスプレイ画面（ＬＣＤ）（図示せず）などの制御要素３１０をさらに含む。プラットフォーム３００は、ユーザ４０１から制御要素３１０を介して受け取った種々の制御を処理するために、車載計算機などの管理要素３２０を含む。制御要素は、管理要素３２０によってコア３３１、３３２、３３３に転送される。
【００３２】
インタフェース作成システムは、制御要素３１０を、機能コア３３１、３３２、３３３と理論上通信させる、以下で説明する設計モジュール２００を含む。この設計モジュール２００は、当該設計モジュール２００に与えられたデータが機能コア３３１、３３２、３３３の特性と一致するかどうかをチェックするように構成された検証モジュール２１０と接続している。例えば、検証モジュール２１０によって、画面のサイズがＧＰＳユニット３３３のビデオ出力に適合する寸法を示しているかどうかをチェックすることができる。
【００３３】
次いで検証モジュール２１０から発せられたデータは、ターゲットプラットフォームのシミュレーションモジュール２３０に転送される。このモジュールは、データを管理要素３２０が解釈可能な言語に変換する翻訳ユニット２３１を含む。こうして、プラットフォーム３００のソフトウェアインタフェースは、制御要素３１０によって自律的にシミュレートされる。こういった例示の実施形態では、モジュール２００、２１０、２３０は、（図示しない）コンピュータなどに集められている。
【００３４】
図２を参照すると、設計モジュール２００は、設計ウィンドウ１を含む。こういったウィンドウ１には、プッシュボタン２１、２２、２３や回転ボタン２４を表す色の付いた円盤、そしてテキスト、写真またはビデオなどの種々のグラフィカル特徴を表示するための液晶画面（ＬＣＤ）１０を表す矩形といったグラフィカルフォームが表示されている。こういったグラフィカルフォームを、インタフェース視覚要素１０、２１、２２、２３、２４と呼ぶ。
【００３５】
こういったインタフェース視覚要素１０、２１、２２、２３、２４は、インタフェースされるユニットのコアの機能特性に対応する機能属性を持っている。例えば、矩形１０は、ここでは画面の解像度、表示可能な色の数、更新の頻度を属性として持っている。同様に、回転ボタンの属性は、回転におけるピッチ数と、逆戻りしない力（no-return force）の度合い、である。したがって、ＬＣＤ（液晶ディスプレイ）型のディスプレイ画面を有する第１のプラットフォームと、ＴＦＴ（薄膜トランジスタ）型のディスプレイ画面を有する第２のプラットフォーム、の２つの同じ部類のレジャープラットフォームの場合、同じ設計ウィンドウ１を同じインタフェース視覚要素と共に使用でき、その属性のみが異なる。
【００３６】
図３を参照すると、設計モジュール２００は、設計ウィンドウ１に配置されているインタフェース視覚要素１０、２１、２２、２３、２４の論理的、順次的、かつ機能的行動を定義できるダイアグラム、すなわち状態機械１００をさらに含む。この機械１００は、種々のインタフェース視覚要素１０、２１、２２、２３、２４の作動時の状態を表す。
【００３７】
インタフェース視覚要素２１、２２、２３は、ラジオ受信機のコア３３１、オーディオＣＤプレーヤーのコア３３２、ＧＰＳユニットのコア３３３をそれぞれ作動させ、回転ボタン２４は種々の機能コアの切り換えを可能にする。
【００３８】
状態機械１００は、種々のインタフェース状態を表すブロック５１、５２、５３のセットの形式で、ブロック５１、５２、５３は状態間の遷移に対応するリンクによって互いに接続されている。
【００３９】
インタフェース作動時の初期状態が状態機械１００に示され、これはＩＮＩの略語で状態ブロック５１に示されている。
【００４０】
状態ブロック５１、５２、５３は、ここではラジオ受信機のコア３３１、オーディオＣＤプレーヤーのコア３３２、ＧＰＳユニットのコア３３３のアクティブ状態にそれぞれ対応する。
【００４１】
初期状態では、ラジオが作動される。もしもＣＤプレーヤーに対応する要素２２に何らかの作用を行うと、ラジオの作動は止まり、オーディオＣＤプレーヤーが作動する。そしてシステムはブロック５２で表される状態になる。同様に、ボタン２３を作動すると、ブロック５３で表される状態に手順が進み、ＧＰＳユニットが作動すされる。つまり、ボタン２１、２２、２３によってプラットフォーム３００の種々の機能の切り替えを便利に行える。
【００４２】
同様に、システムの状態がブロック５１によって表される場合（ラジオ状態）、ボタン２１（ラジオボタン）を作動させても状態は変わらない。
【００４３】
プラットフォーム３００の異なる機能を切り換えるために、回転ボタン２４を使用する。システムの状態がブロック５１によって表されている場合、ＧＰＳ機能（状態５３）に切り換えるにはボタン２４を左に回転させ、ＣＤ機能（状態５２）に切り換えるにはボタンを右に回転させればよい。図３の点線は、回転ボタン２４を回転させたときの種々の状態間の遷移を表す。
【００４４】
こういった全ての作用によって、ラジオ局名、アーティスト名、曲名の表示といったディスプレイ画面１０や受信している周波数の変更が行われる。
【００４５】
インタフェース視覚要素１０、２１、２２、２３、２４を設計ウィンドウ１に配置する際、同時にこういった要素を状態図１００にも配置できるため、要素の全ての属性に迅速にアクセスできる。
【００４６】
設計ウィンドウ１と状態図１００の両方において、設計モジュール２００で追加されたデータは、チェックのために検証モジュール２１０に送信される。
【００４７】
検証モジュール２１０によって、状態機械１００で定義したイベントの論理シーケンスと設計ウィンドウ１で定義した視覚要素２２、２３、２４が適当なフォーマットで入力され、ユニットの機能コア３３１、３３２、３３３の特性と一致することを保証できる。
【００４８】
こういった自動検証ステップは、インタフェース設計時のどの段階でも行い得る。例えば、各ボタン２１、２２、２３を設計ウィンドウ１に挿入した後にインタフェースを検証することができる。こういった部分的な検証によって、いかなるエラーのリスクを回避することができるため、インタフェースの品質を向上させることができる。つまり、こういったことによってインタフェース作成の全体的なプロセスにかかる時間の節約につながる。
【００４９】
設計モジュール２００からのデータがモジュール２１０によって検証されると、データはターゲットプラットフォームのシミュレーションモジュール２３０、いわゆるターゲットシミュレーションモジュールに送信され、制御要素３１０によってインタフェースをシミュレートする。
【００５０】
設計モジュール２００で使用するソフトウェア言語は、プラットフォーム３００の管理要素３２０で使用する言語とは異なる。そこで、実際のシミュレーションを実行するために、ターゲットシミュレーションモジュール２３０の翻訳ユニット２３１によって、設計データを、プラットフォーム３００の管理要素３２０が解釈可能ないわゆる「ターゲット」低レベル言語に変換することができる。こういった翻訳は自動的に実行されるため、時間の節約になる。
【００５１】
さらに、翻訳ユニット２３１は、これが含む機能コア３３１、３３２、３３３の関数としてパラメータ化できる。したがって自動車のレジャープラットフォームの部類では、生成されたコードを同部類の種々のプラットフォームに適用するために、翻訳ユニット２３１のパラメータ化を修正することで十分である。
【００５２】
実際のテストでは、ユーザ４０１は制御要素３１０を作動させ、機能コアの行動を観察し、ターゲットプラットフォーム３００上での実行において典型的な欠陥を検出する。
【００５３】
本発明の別の実施形態では、プラットフォーム３００または機能コア３３１、３３２、３３３が利用できないか、または物理的なプラットフォーム３００にも制御要素３１０にも一切依存せずにテストを実行するのが望ましい場合が生じ得る。こういった仮定で図４を参照すると、設計モジュール２００からのデータは、ソフトウェアデバイスプラットフォームのシミュレーションモジュール２２０、いわゆるソフトウェアシミュレーションモジュール２２０に送信され、そこでモジュール２２０に接続されたコンピュータ２５０などによって作成されたインタフェースをシミュレートする。
【００５４】
オペレータ４０１と原則として同一人物のオペレータ４０２が、ソフトウェアシミュレーションモジュール２２０を使用してインタフェースをテストし、コンピュータマウスでボタン２２をクリックしてオーディオＣＤプレーヤーを作動させることで、コンピュータ２５０のモニタに表示される設計ウィンドウ１００の矩形１０への「ＣＤ」というテキストの表示がトリガされる。
【００５５】
設計者またはカスタマであるオペレータは、プラットフォーム３００に依存しなくてもインタフェースの品質を評価することができる。その理由は、プラットフォーム３００のコアがなくてもインタフェースを常に開発することが可能なためである。さらに、こういった「理論上の」インタフェースは検証モジュール２１０によって検証されているため、プラットフォーム３００や利用不可能なコアとインタフェースとの将来の適合性が保証される。
【００５６】
本明細書中で使用されているように、ボタン、ローレットホイール、カーソル、他のハンドルといった用語は、音声（例えば、声）コマンド、ビジュアルコマンド（ユーザの動きの検出）、タッチコマンド（タッチ画面）、そしていわゆる「ワイヤレス」コマンド（赤外線、ブルートゥース、ワイファイ、電波など）といった、装置機能を作動させるための全ての手段も含む。
【図面の簡単な説明】
【００５７】
【図１】本発明に係るインタフェース作成システムの図である。
【図２】本発明に係る設計ウィンドウの図である。
【図３】本発明に係る状態図である。
【図４】ソフトウェアデバイスプラットフォームのシミュレーションモジュールを有する本発明のシステムの別の実施形態を表す。
【図１】
2009003918.tif 000003
【図２】
2009003918.tif 000004
【図３】
2009003918.tif 000005
【図４】
2009003918.tif 000006
【外国語明細書】
2009003918000001.pdf