JP5049349B2 - エンジンテストベッドの形式から独立しているエンジンテストベッド監視装置 - Google Patents

Description

本発明は、エンジンテストを、収容される可能性のあるエンジンテストベッドから完全に独立して構成できるようにする、複数のエンジンテストベッドの実時間監視を目的としている装置に関する。

熱エンジンまたは電気モータと、それらの動作に影響する多くのパラメータとの研究に加えて、特定の標準（たとえば、公害防止標準）への準拠には、研究ベンチまたは認証ベンチでのエンジンテストが必要である。新しい技術の出現によって絶えず増加しているエンジン制御パラメータのせいで、エンジンパラメータは、数個のエンジン構成段階の間に調整される。エンジンの開発に要する時間を短縮するために、テストセンターは、その作業方法とその装置とを最適化しなければならない。

エンジンテストベッドで実施される研究によれば、さまざまな調整可能なパラメータのエンジンの動作に対する影響を研究することによって、内燃エンジンの動作を完全に研究することができる。

エンジンテストベッドは、ソフトウェアの構成によってそのようなエンジンテストを構成し実施できるようにする監視装置（収集および制御装置）に組み合わされている。図１は、エンジンテストベッド監視装置に組み合わされている従来のハードウェアアーキテクチャを示している。エンジンテストベッド（ＢＥＭ）は、エンジン（ＭＯＴ）とエンジンの駆動およびその動作の分析を可能にする以下の要素からなる：
−ブレーキまたは発電機（ＦＧ）
−自動装置（ＢＵＴ）
−気体分析キャビネット（ＢＡＧ）
−煤煙濃度計（ＡＦ）
−燃料消費バランス（ＢＣＣ）
エンジンテストベッド監視ソフトウェア（ＳＯＦＴＷ）は、対象としているエンジンテストの収集、制御、および順序定義条件を記述している「テスト構成」を基にして概ね構成されている。

テスト構成は、監視ソフトウェアに固有の「テスト構成エディタ」を利用してユーザによって実施することができる。

それから、このテスト構成は、監視ソフトウェア自体によって実行することができる。それから監視ソフトウェアは、必要なデータ収集と必要な量の実時間評価との実施と、実験条件の安全性を保証しながら（常時安全監視）、結果として得られた複数の設定点の制御とを担当する。これらの動作の順序の定義は、組み合わされているドライバを介して電子Ｉ／Ｏとデジタル通信カードをsolicitするそのコンピュータプラットフォームの実時間コアを利用して監視ソフトウェアによって実施される。

従来の構成によれば、各テスト構成は、各エンジンテストベッドの特定の複数の装置に依存している。テスト構成がエンジンテストベッド第１の複数の装置を基に構成されている場合、このテスト構成をエンジンテストベッド第２にそのまま移動させることはできないが、これは、ブレーキ規制、気体分析、フューム分析、および燃料消費計測の機能に特に専用に設けられている高価な複数の装置が異なるためである。しかし、この可搬性は、エンジンテストベッド第１において達成されたテスト構成を、エンジンテストベッド第２の複数の装置に固有のＩ／Ｏの宣言と識別情報との変更を通してエンジンテストベッド第２に適合させることによって達成することができる。エンジンテストベッドの複数の装置のＩ／Ｏの一覧は、テスト構成の宣言に直接依存している。そこで、このテスト構成を異なる複数の装置を備えている他のエンジンテストベッドに移動させる場合には、これらの宣言は必ず変更しなければならない。

従来の監視ソフトウェアは、エンジンテストベッドの複数の装置を制御する複数のドライバを有しているだけである。現在、エンジンテストベッドの各装置は、各テストに適しているパラメータ：ダウンロードする複数の計測値の選択、計測範囲の定義、結果の形式の定義等が必要である。これらの操作は、テスト構成の編集段階にユーザによって実施される。

従来の監視ソフトウェア（ＳＯＦＴＷ）については、特定のソフトウェアのパラメータが監視ソフトウェアに組み込まれていないが、これは、組み込みによって、新しいドライバのサポートが追加されるたびに監視ソフトウェアを修正することになるからである。このコードは、具体的には、専用のドライバＰＸ、ＰＹ、およびＰＺをそれぞれ有している３種類の装置（ＥＸ、ＥＹ、およびＥＺ）を示している図３に示しているように、各ドライバに組み込まれている。ドライバは、従来の監視プログラム（ＳＯＦＴＷ）およびその組み合わされている編集ソフトウェア（ＥＤＩＴ）と通信する。したがって、各ドライバは、その特定のパラメータの編集機能のコード（ＥＤＩＴ用）と実時間管理コード（ＳＯＦＴＷＡＲＥ用）との両方を組み込まなければならない。

この構成は、一層制約が大きく、それは、各ドライバの特定のパラメータの編集のためには各ドライバ内でさまざまな互換性のある動作環境の管理が必要だからである。一般的に、Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフト、米国）のダイアログボックスのコードは、ドライバ内に直接組み込まれている。

最後に、これらのさまざまなエンジンテストベッド制御装置では、エンジン制御を合同で実施することができない。

本発明の実時間監視装置は、エンジン制御装置を組み込む一方で、実時間監視装置が収容される可能性のあるエンジンテストベッドから（そしてそのため特定の重要な装置から）完全に独立してエンジンテストを関知できるソフトウェア構成を有している。

本発明は、実時間収集と複数のエンジンテストベッドの制御とを目的としており、コンピュータプラットフォーム（ＰＣ）と、実時間モジュール（ＭＴＲ）に組み合わされているソフトウェア動作環境（ＯＳ）とを有している装置（ＳＳ）に関する。この装置は：
−様々なエンジンテストベッドに組み合わされている装置とドライバとの記述を有するファイル（ＦＤ）と、
−ソフトウェア動作環境（ＯＳ）とコンピュータプラットフォーム（ＰＣ）とから独立しており、複数のエンジンテストベッド装置を制御する一式のソフトウェアドライバ（ＰＬ）と、
−エンジンテストの収集および制御の複数の条件によって定義されており、一式のソフトウェアドライバ（ＰＬ）と複数のエンジンテストベッド装置とから独立している複数のテスト構成用のエディタ（ＥＤＩＴ）と、
−記述ファイル（ＦＤ）から情報を読み取り、必要な複数のソフトウェアドライバのロードを実行することによってエディタから得られた複数のテスト構成の実時間実行を担当することを目的としている実時間監視ソフトウェア（ＳＴＲ）と、の要素を有し、
−複数のエンジンテストベッド装置を制御する複数のソフトウェアドライバ（ＰＬ）は、実時間で実時間監視ソフトウェア（ＳＴＲ）と通信をする。

一実施態様によれば、テスト構成は、複数のエンジンテストベッドの一般的な複数の機能によって定義することができる記述ファイル（ＦＤ）は、ＸＭＬ（拡張マークアップ言語）形式にできることが有利である。同様に、テスト構成エディタ（ＥＤＩＴ）は、複数のＸＭＬ形式スキーマを使用できる。

他の実施態様によれば、収集と制御装置（ＳＳ）は、エンジン制御装置も有している。このエンジン制御装置はエンジンをソフトウェア（ＳＴＲ）と通信させるのに適しているエンジン制御ドライバの自動生成を目的としているモジュールを有していてもよい。本発明によれば、このエンジン制御ドライバ自動生成モジュールは、以下の要素を有することができる：
エンジン制御モデル生成モジュール、
エンジン制御モデルコンパイラモジュール。

制御ドライバを使用する実施態様では、コンピュータプラットフォーム（ＰＣ）は、そのプロセッサリソースを複数のエンジンテストベッド監視タスクと複数の制御ドライバ解釈タスクとで共有できることが有利である。

本発明の実時間監視装置の他の特徴と利点とは、添付の図面を参照して、非限定的な実施形態の以降の説明を読むことで明らかになろう。

エンジンテストベッド監視装置に組み合わされている従来のハードウェアアーキテクチャを示している図である。 本発明の監視装置の場合の、複数の汎用ドライバを通した、複数の装置と編集及び監視用の複数のソフトウェアとの間の通信の図である。 従来の監視装置の場合の、複数の専用ドライバを通した、複数の装置と編集及び監視用のソフトウェアとの間の通信の図である。

本発明のエンジンテストベッド用の実時間収集および制御装置（ＳＳ）は、以下の要素（図１）を有している：
−コンピュータプラットフォーム（ＰＣ）、
−リアルタイムモジュール（ＭＴＲ）に組み合わされているソフトウェア動作環境（ＯＳ）、
−エンジンテストベッド監視モジュール（ＭＳ）、
−複数の入力と出力とを取得し制御する一式の電子カード（ＣＥＥＳ）。これらの入力と出力をＩ／Ｏで表す、
−一式の電子デジタル通信カード（ＣＥＣＮ）、
−デジタル通信多重化セット（ＭＣＮ）、
−一般にドライバと呼ぶ一式のソフトウェアドライバ（ＰＬ）。これらは以下のものであってもよい：
−様々な電子カードの複数のソフトウェアドライバ。一般に、ドライバは電子カードの各種類に組み合わされている、
−エンジンテストベッド装置のドライバ。一般に、これらの装置は、選択されたデジタル通信プロトコル用の解釈ドライバが系統的に組み合わされている専用のデジタル通信を通してアクセス可能である、
−複数の電子入力条件設定および形状設定インターフェイス（ＩＥＥ）、および複数の電子整形インターフェイスと、エンジン点火と噴射とのインターフェイスのための複数の電力ステージ（ＩＥＭＦ）。

コンピュータプラットフォーム（ＰＣ）は、ＰＣ互換マイクロコンピュータとすることができる。例として、本発明の監視装置を実装するために、以下のＰＣタイプ構成を使用することができる：
−Ｐｅｎｔｉｕｍ ７００ＭＨｚプロセッサ
−ＲＡＭメモリ：１２８ Ｍｏ
−ハードディスク：２０Ｇｏ以上
−ＣＤ−ＲＯＭリーダ：３２倍速以上。

本発明の実時間監視装置は、以下の複数のソフトウェア動作環境（ＯＳ）下で動作可能な一式のソフトウェアモジュール（監視モジュール（ＭＳ）、実時間モジュール（ＭＴＲ）、ドライバ（ＰＬ））を有している。Ａｒｄｅｎｃｅ Ｉｎｃ． Ｃｏｍｐａｎｙ（米国）のＲＴＸ拡張ボードを備えているＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ４、２０００、およびＸＰ。実時間モジュール（ＭＴＲ）を適合させることによって、他の動作環境を考えることができる。実時間モジュール（ＭＴＲ）は、監視装置（ＳＳ）のカーネルを表す実時間実行可能プログラムである。実時間実行可能プログラムは、アプリケーションの実時間実行の中心部分の役割を果たし、複数のドライバに接続し、収集と複数のエンジンテストベッドの制御のためにそれらを適切な時間に呼び出すために、ドライバインターフェイスを使用する。このモジュールは、監視モジュール（ＭＳ）の実時間監視ソフトウェア（ＳＴＲ）によって透過的に起動される。複数のアプリケーションの実時間実行を担当するのがこのモジュールである。実時間モジュールは、以下の機能を実行する：
−複数のドライバを開く、複数のドライバの特定、および複数のドライバとの通信、
−複数の実時間アプリケーションの実行、
−実時間監視ソフトウェア（ＳＲＴ）との通信。

本発明の実時間エンジンテストベッド監視装置は、「オブジェクトプログラミング」原理に基づいている。コンピュータプログラミングの分野では特にＣ＋＋言語を使用して開発されたこの原理が本発明によってエンジンテストベッド制御装置に適用される。言い換えると、「オブジェクトプログラミング」の原理は、エンジンテストベッド監視の管理に拡張される。「オブジェクトプログラミング」の原理によって、コンピュータプログラムの全ての構成要素が複数のオブジェクト内にカプセル化される。オブジェクトのこの概念は、産業用プログラミングにおいて必須であり、これはこの概念によって、各オブジェクトがオブジェクトを動作できるようにする使用可能な一式のメソッドを持つことができるからである。原理的には、このオブジェクトの外部のソフトウェア関数がこれらの保護されている変数に直接アクセスできないように、オブジェクトの動作に必要な全ての変数が対象のオブジェクトのクラス内にカプセル化される。アクセスは、各オブジェクトに組み合わされている「メソッド」（対象とするオブジェクトクラスを使用して宣言されているソフトウェア関数）によってのみ実現される
エンジンテストベッド監視装置の場合、この原理によって、装置が収容される可能性のあるエンジンテストベッド（と、そのため特定の複数の重要な装置）とから完全に独立している複数のエンジンテストを構成可能な非常に特有の構造を有している複数の装置を構成することができる。エンジンテストベッドは「オブジェクト」となる。

したがって、エンジンテストベッド監視モジュール（ＭＳ）は以下の要素からなる（図２）：
−収集、制御、および対象としているエンジンテストの順序の定義条件を記述するテスト構成エディタ（ＥＤＩＴ）、
−実時間監視ソフトウェア（ＳＴＲ）、
−様々なエンジンテストベッドの構成を記述しているファイル（ＦＤ）。

テスト構成エディタ（ＥＤＩＴ）は、ユーザが複数のテスト構成をメニュー、ツールバー、グラフィカルオブジェクト等によって記述できるようにするグラフィカル実行可能ファイルである。このエディタは複数のＸＭＬ（拡張マークアップ言語）スキーマを使用することが好ましい。構成エディタは以下の機能を実行する。
−エンジンテストの構成をＸＭＬからロードする、
−複数の構成（実施する複数のテストを表している複数のアプリケーション）の編集のためのマン／マシンインターフェイス、
−表示スクリーンのグラフィカル編集のためのマン／マシンインターフェイス。

実時間監視ソフトウェア（ＳＴＲ）は、エンジンテストを実施するためにユーザと対話するアプリケーションである。ユーザは、アプリケーションの実行を制御するための自由に使用できる複数のメニューと複数のグラフィカルウィンドウとを有している。このエンジンテストの実施に必要な全ての実時間アプリケーションをユーザに対して透過的に起動するのがこのアプリケーションである。このソフトウェアによって、テストベッドのオペレータは、エディタによって構成された複数のアプリケーションを実行することができる。実時間監視ソフトウェアは以下の機能を実行する。
−マン／マシンインターフェイス、
−複数の実時間モジュールとのインターフェイス、
−ＸＭＬからロードされた構成。

エンジンテストベッド監視モジュール（ＭＳ）は、使用される全てのエンジンテストベッドの構成を記述しているファイル（ＦＤ）だけを使用する。これらは、たとえば、会社の全てのエンジンテストベッドである。このファイル内に記述されており、実時間監視ソフトウェア（ＳＴＲ）によって読み取られる各エンジンテストベッドの複数の装置と個別の装置のそれぞれの機能の一覧などの情報が、そのような監視装置を収容する可能性のある任意のテストベッドで利用可能な一般的な機能の形式で一覧に構成されている。記述ファイル（ＦＤ）は、管理を促進するように標準的なＸＭＬ形式とすることができる。

図２は、そのような監視装置の動作も示している。この図は、従来の監視装置の動作を示している図３と比較することができる。従来の場合、エディタＥＤＩＴを使用した特定の構成の編集は、各装置（ＥＸ、ＥＹ、ＥＺ）の様々なドライバ（ＰＸ、ＰＹ、ＰＺ）に従って行われることが理解される。他方、本発明の制御装置によれば、複数の構成の編集は、複数のドライバと装置の種類とから完全に独立している。ＥＸとＰＸであろうとＥＹとＰＹであろうと、構成の編集は変わらない。

したがって、エディタＥＤＩＴによるテスト構成の宣言は、複数のエンジンテストベッドの複数の装置から完全に独立しており、これは、宣言には、監視装置（燃料消費計測機能、ＣＯ₂の計測、フュームの不透明性の計測等）を収容することを目的としているエンジンテストベッドの複数の一般的な機能だけが必要なためである。必要な装置のドライバの暗示的なロードは、さまざまなエンジンテストベッドの構成を記述しているファイル（ＦＤ）のおかげで、実時間監視ソフトウェア（ＳＴＲ）内で自動化されている。

実時間収集および制御装置（ＳＳ）の複数のドライバ（ＰＬ）は、既存の部分を修正せずに装置を拡張可能にする独立しているソフトウェアモジュールである。複数のドライバ（ＰＬ）は、Ｗｉｎｄｏｗｓ（登録商標）（マイクロソフト、米国）またはＲＴＸ（登録商標）の実行可能ファイルとすることができる。Ｗｉｎｄｏｗｓ（登録商標）実行可能ファイルは必然的に非同期ドライバであるのに対して、ＲＴＸ（登録商標）実行可能ファイルは、同期形式にも非同期形式にもすることができる。複数の非同期ドライバは、カーネルに対して非同期に動作する複数のドライバであって、そのため、それらの実行を妨げない。非同期ドライバは、ハードウェアを制御できたりできなかったりする。同期ドライバは、実時間装置（ＳＳ）のカーネルと同期して動作するＲＴＸ（登録商標）実時間実行可能ファイルであって、ハードウェアを制御できたりできなかったりする。

複数のドライバ定義ファイルもＸＭＬ形式であることが好ましく、２種類のデータを有している。
−ドライバによってエクスポートされた複数のチャネル、テーブル、マップおよび動作について実時間装置（ＳＳ）に通知するパブリックデータ。このデータは、例えば複数のチャネルの種類、複数のテーブルの大きさ、またはドライバの動作の編集方法または表示方法を記述している、
−プライベートデータは、各ドライバに固有であって、各ドライバに特有のスキーム内で定義可能である。例えば、マップの１６進アドレスまたはドライバによって制御される装置の名前がそのようなデータの例である。

さらに、これらのドライバには、カーネルとドライバとの間の通信を可能にするインターフェイスが必要である。このドライバインターフェイスは、メモリ内でロックされている共有メモリと同期オブジェクト（ミューテックス、セマフォ、イベント）との使用に基づいている。それによって、ドライバとアプリケーションとがメッセージを交換することが可能になる。

エンジンテストベッド監視モジュール（ＭＳ）の構造を最適に動作させるために、エンジンテストベッド制御装置はパラメータコードを一切使用せずに複数のエンジンテストベッド装置を制御する複数のドライバ（ＰＬ）を有している。装置のパラメータは、記述ファイル（ＦＤ）内に記録される。複数のドライバ内ではパラメータコードは必要ではなく、そのため、動作環境（たとえば、Ｗｉｎｄｏｗｓ ＮＴ４ ＳＰ６、Ｗｉｎｄｏｗｓ ＸＰ、その国の言語へ対応しているマン／マシンインターフェイス）と監視プラットフォームとには依存しない。複数のドライバは、対象としている装置の監視ソフトウェアＳＴＲのコアとの実時間関係を制御する目的に関してのみ最適化されている。

エンジンテストベッド装置を制御するドライバを有しているだけの従来の監視ソフトウェアとは異なり、監視ソフトウェアＳＴＲは、エンジンテストベッド装置を制御するドライバと、さまざまなエンジンテストベッドの全ての装置を記述しているファイル（ＦＤ）の両方に基づくことができる。

複数の重要な装置の複数のソフトウェアドライバの複数の機能とテストの構成機能との間のこの分離は必須であり、これは、各エンジンテストベッド装置が各テストに適しているパラメータ：ダウンロードする計測値の選択、計測範囲の定義、結果の形式の定義等を必要とするためである。これらの操作は、テスト構成の編集段階にユーザによって実施される。
エンジン制御を行う実施形態
本発明のエンジンテストベッド監視装置の特定の実施形態によれば、エンジンテストベッド監視装置は、エンジン制御装置も有している。

監視装置を受け入れることが意図されているエンジンテストベッドは、エンジン制御機能を様々な方法で実施することができる。
−第１の方法は、この機能をエンジン配線チューブに一般的に付属している標準エンジン計算機にゆだねることにある。しかし、この第１の解決策では、ユーザがこのエンジン計算機内に組み込まれているエンジン制御の複数のパラメータにアクセすることができない、
−第２の解決策は、標準エンジン計算機を開発用エンジン計算機に交換することに存する。この第２の解決策は、顧客（自動車または部品の製造者）によって提供されることが多いそのような装置を装備することを認可するまたは認可しないエンジン研究契約によって条件が定められていることが多い。この解決策によって、複数の設定点とエンジン制御の主な複数の結果とにまずアクセスすることができるが、この解決策ではエンジン自動制御方法にアクセスすることができず、この解決策は設定点へのアクセスを電子的に制御できないインターフェイス（ＰＣラップトップのことが多い）に限定している、
−第３の解決策は、標準エンジン計算機をＩＦＰ（フランス）によって開発されたＡＣＥｂｏｘ（登録商標）装置などの完全なエンジン制御開発装置に交換することに存する。この第３の解決策によって、完全に電子的に制御可能なインターフェイスを使用して、複数の設定点、主なエンジン制御の複数の結果、および複数のエンジン自動制御方法への完全なアクセスが可能になる。この解決策は、エンジン制御に関しては開発ニーズに完全に適しているが、エンジン制御専用の全ＣＰＵ（中央処理装置）リソースを必要としている用途を依然として対象としている。

本発明の装置は、エンジン制御がエンジン制御専用の全ＣＰＵリソースを必要としていない場合の第４の解決策を提供する。この装置は、標準エンジン計算機の代わりに、監視装置（ＳＳ）内に組み込まれているエンジン制御装置を有している。

本実施形態によれば、監視装置（ＳＳ）のコンピュータプラットフォーム（ＰＣ）は、プラットフォームプロセッサ（ＣＰＵ）のリソースを２つのタスクの間で共有している。第１のタスクはテストベッドの監視である。第２は、自動モデリングから得られたコンパイルされたコードの解釈である。このモデリングは、複数のマルチドメイン動的装置のシミュレーション用の設計プラットフォームの下で実施される。

たとえば、そのようなプラットフォームは、ＭＡＴＬＡＢ（登録商標）（ＭａｔｈＷｏｒｋｓ、米国）とＳｉｍｕｌｉｎｋ（登録商標）（ＭａｔｈＷｏｒｋｓ、米国）との組み合わせに存するとすることができる。ＭＡＴＬＡＢ（登録商標）は、信号処理またはデジタル分析問題の解法専用のソフトウェアである。これによって、行列計算を実行し、結果をグラフィカル形式で表示することができる。問題の定式化は、解く問題の数学的な定式化に似ている。ソフトウェアの使用は、Ｃプログラミングにほとんどの場合に似ているコマンドラインの起動に存する。Ｓｉｍｕｌｉｎｋ（登録商標）は、マルチドメイン動的系のシミュレーションのための設計プラットフォームである。Ｓｉｍｕｌｉｎｋ（登録商標）は、制御／コマンド、信号処理、通信装置、および時間につれて変化する他の系を正確に設計できるように、個人用に設定されているブロックライブラリを備えている対話によるグラフィカル環境を提供する。ＭＡＴＬＡＢ（登録商標）の下で起動されるコマンドによってＳｉｍｕｌｉｎｋ（登録商標）と組み合わされるＭＡＴＬＡＢ（登録商標）は、プロセスシミュレーションのための非常に使用が容易な（複数の機能ブロックのコピー／ペーストによるプログラミング）グラフィカルツールとなる。

それから、エンジンテストベッド監視装置はエンジン制御ドライバの自動生成のためのモジュールを有している。このモジュールは以下のモジュールを有している：
−実時間エンジン制御モデル生成モジュールと、
−実時間エンジン制御モデルコンパイラモジュール。

コンパイルによってエンジン制御ドライバが得られる：これらのモジュールの使用によって、エンジン制御モデルを、標準エンジン計算機の知能部分（マップ、アルゴリズム、戦略）を置き換えることができる監視用のドライバに変換することができる。

エンジン、より具体的にはその配線チューブ（複数のエンジンアクチュエータと検出器の配線）は、ソフトウェア（ＳＴＲ）に複数の電子Ｉ／Ｏカード、電子条件設定インターフェイス（直流絶縁、計測尺度設定等）、および複数の電力インターフェイス（複数の点火コイル、インジェクタ、ソレノイドバルブ、リレー等）を介して接続されている。ソフトウェア（ＳＲＴ）とのこの接続は、このようにコンパイルされた特定の実時間ドライバを通してＷｉｎｄｏｗｓ（登録商標）動作環境の下で実現される。実時間ドライバによってエンジン制御機能が実行される。

この解決策の利点は明らかであって、エンジンテストベッド上の制御ユニットの数が最適化されるためである（１ＰＣ＝監視＋エンジン制御）。他方、この概念は、１つのプラットフォーム内でデータを集中化するという要求にも合致している。監視コンピュータプラットフォームとエンジン制御との間には通信用電子部品は、もはや必要ない。ユーザによって収集されたすべてのデータは、１つのマシン内で利用可能であって、そのため完全に相互に関連している。

エンジン制御機能に基づいている前述のこの概念は、使用するＯＳについて互換性のあるＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）のモデルの形式で開発された任意の他の機能に適用することができる。エンジンブレーキなどの装置の調整の例は、まさにその実例である。
監視装置（ＳＳ）の動作
エンジンテストベッド（ＢＥＭ）は、以下の動作を一般に担当する制御装置（ＳＳ）に組み合わされている。
−データ収集と複数のエンジン設定点の制御（ＢＡＧ、ＡＦ、ＢＣＣ）、
−ブレーキまたは発電機の制御と調整（ＦＧ）、
−エンジンテストの順序設定の自動化と定義、
−エンジンテストベッドの安全性（専用の自動化装置（ＡＵＴ）が直接担当することが多い）の管理と集中化。

図１に複数の矢印によって示しているこれらの動作は以下のように実行される：
−エンジンデータ収集は、入力電子条件設定および整形インターフェイス（ＩＥＥ）と、複数のエンジンテストベッド装置（気体分析キャビネット（ＢＡＧ）、フュームの不透明性の分析のための煤煙濃度計（ＡＦ）、燃料消費バランス（ＢＣＣ）など）とのデジタル通信とによって実行される。これらの異種のインターフェイス（収集カード、デジタルリンク、フィールドバス等）を通した装置の状態の取得は、独立している複数のモジュール：ドライバによって制御され、
−複数のエンジン設定点の制御は、複数の出力電子整形および電力ステージ（ＩＥＭＦ）によって実行される、
−複数のエンジンテストベッド装置の複数の設定点の制御は、これらの装置とのデジタル通信（ＭＣＮ）：範囲選択、バケツ充填等によって実行される、
−ブレーキ（または発電機）の制御と調整とは、電子Ｉ／Ｏインターフェイス（ＩＥＥとＩＥＭＦ）および／または特定のデジタル通信（ＭＣＮ）によって実現される、
−エンジンテスト順序の自動化と定義とは、監視ソフトウェア（ＳＴＲ）に固有である。エンジンテストの構成は、一度構成され再利用可能なジョブオブジェクト（消費バランス、自動装置、正規化サイクル等）の形式で実行される。これらのオブジェクトは、継承とポリモーフィズムをサポートする：同じアプリケーションは、種類が非常に異なる複数の装置を備えている複数のテストベッド上で修正なしに実行可能である、
−エンジンテストベッドの安全性の制御と集中化とは、テストベッド自動化装置（ＡＵＴ）を使用してデジタル通信によって実施される。

エンジン制御装置を有しているエンジンテストベッド監視装置の特定の実施形態によれば、監視装置はＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）形式のプラットフォームから自動的に複数のコードを生成することができる。その非常にオープンなアーキテクチャのおかげで、装置の全ての機能は、既存のコードを修正したり再コンパイルさえせずに、非常に容易に拡張することができる。したがって、ドライバと乗り物とのモデルばかりでなくアルゴリズムも、ＭＡＴＬＡＢ（登録商標）／Ｓｉｍｕｌｉｎｋ（登録商標）形式のプラットフォームからテストベッドへ２、３分以内に移動することができる。

さらに、監視装置（ＳＳ）によって以下が可能になる：
−ベクトル、表、およびマップをサポートした（実時間での）数学的な計算、
−（計算を含む）装置の全てのチャネル上でのアラームとそれに対する対応の監視。各チャネルは閾値を非常に複雑な式とすることが可能な任意の数のアラームを有することが可能である、
−複数のドライバよって拡張可能な真の実時間マクロ言語によるプロセスのマルチタスク制御と、重要な安全性に対する使用を除く、自動機械の使用の不要化、
−複数の周波数データの手動保存と自動保存、
−実時間に対して最適化されているマルチスレッドグラフィカル表示と動画。

本発明の監視装置（ＳＳ）によって、装置の状態の１０ｋＨｚまでの周波数（チャネルは無制限）での実時間監視、制御、および収集が可能になる。その利用分野は、従来の複数のテストベッドの監視から一式のプラットフォームの監視とエンジン制御にまでわたる。

Claims (8)

1. 実時間収集と複数のエンジンテストベッドの制御とを目的としており、コンピュータプラットフォーム（ＰＣ）と、実時間モジュール（ＭＴＲ）に組み合わされているソフトウェア動作環境（ＯＳ）とを有している装置（ＳＳ）において、
   様々なエンジンテストベッドに組み合わされている複数の装置と複数のドライバとの記述を有するファイル（ＦＤ）と、
   前記ソフトウェア動作環境（ＯＳ）と前記コンピュータプラットフォーム（ＰＣ）とから独立しており、複数のエンジンテストベッド装置を制御する一式のソフトウェアドライバ（ＰＬ）と、
   エンジンテスト収集および制御の複数の条件によって規定され、前記一式のソフトウェアドライバ（ＰＬ）と前記複数のエンジンテストベッド装置とから独立している複数のテスト構成用のエディタ（ＥＤＩＴ）と、
   前記記述ファイル（ＦＤ）から情報を読み取り、必要な前記複数のソフトウェアドライバのロードを実行することによって、前記エディタから得られた前記複数のテスト構成の実時間実行を担当することを目的としている実時間監視ソフトウェア（ＳＴＲ）と、
   を有し、
   前記複数のエンジンテストベッド装置を制御する前記複数のソフトウェアドライバ（ＰＬ）は、実時間で前記実時間監視ソフトウェア（ＳＴＲ）と通信をする
   ことを特徴とする収集および制御装置。
2. 前記エディタ（ＥＤＩＴ）によって編集されたテスト構成は、一般的な複数のエンジンテストベッド機能によって規定される、請求項１に記載の収集及び制御装置。
3. 前記記述ファイル（ＦＤ）はＸＭＬ（拡張マークアップ言語）形式である、請求項１または２に記載の収集および制御装置。
4. 前記テスト構成エディタ（ＥＤＩＴ）は、複数のＸＭＬ（拡張マークアップ言語）形式スキーマを使用する、請求項１から３のいずれか１項に記載の収集および制御装置。
5. 該収集および制御装置はエンジン制御装置も有する、請求項１から４のいずれか１項に記載の収集および制御装置。
6. 前記エンジン制御装置は、エンジンを前記ソフトウェア（ＳＴＲ）と通信させるのに適しているエンジン制御ドライバを自動生成するのを目的としているエンジン制御ドライバ自動生成モジュールを有する、請求項５に記載の収集および制御装置。
7. 前記エンジン制御ドライバ自動生成モジュールは、
   エンジン制御モデル生成モジュールと、
   エンジン制御モデルコンパイラモジュールと、
   を有する、
   請求項６に記載の収集および制御装置。
8. 前記コンピュータプラットフォーム（ＰＣ）は、そのプロセッサリソースを複数のエンジンテストベッド監視タスクと前記制御ドライバの複数の解釈タスクとの間で共有する、請求項６または７に記載の収集および制御装置。

Images