JP2007510992A - 制御システムをシミュレーションおよび検証するためのシミュレーションシステムおよびコンピュータにより実施される方法 - Google Patents

Abstract

開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステムであって，シミュレーションシステムがホスト−ターゲットアーキテクチャを備え，制御システムの少なくとも一部を表すターゲットのオペレーティングシステムが，ターゲットのオペレーティングシステムに専用のアプリケーションプログラミングインターフェースを介して，ホストにより再設定されるシミュレーションシステム。
【選択図】図１０

Description

本発明は，開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステム，ならびに開発中の制御システムをシミュレーションおよび検証するためのコンピュータにより実施される方法に関する。より詳細には，本発明は，車両，航空機，船舶等，およびそれらの一部のような動的システムに用いられる制御システムのいわゆる高速プロトタイピングに関する。さらに，本発明は，コンピュータ読取り可態な媒体と，コンピュータ読取り可態な媒体に記録され，コンピュータ上で実行される場合にかかるプロセスを実施するに適したプログラムコーディング手段を伴うコンピュータプログラムとを備えたコンピュータプログラム製品に関する。

制御システムの高速プロトタイピングは，開発中の制御システムの正確な機能およびリアルタイム挙動に関する初期検証のために，自動車業界，航空機業界等で一般に用いられている。このように，車両またはその一部のような動的システムに用いられる制御方法およびアルゴリズムは，制御ループの最終的な実装の有無にかかわらず，実世界（real world）の条件下でテストされる。

高速プロトタイピングシステムは，通常，一般に次の主要コンポーネントからなるハードウェア／ソフトウェア融合システムとして特徴付けられる。
・開発中の制御システムのモデルの一部を基本的に個々に実行し，対応するメモリモジュールを有する，１または複数のシミュレーションプロセッサからなるシミュレーションターゲット
・プラント（制御されている外界）より与えられている信号からなる入力インターフェース
・プラントに与える信号からなる出力インターフェース
・ホスト（多くの場合，パーソナルコンピュータ）からシミュレーションターゲットにモジュールをダウンロードし，シミュレーション実験（開始および停止指令等）を制御し，モジュール信号およびパラメータをそれぞれに測定およびキャリブレーションするための通信インターフェース。

図１は，従来技術から既知の従来のシミュレーションシステム１０をモデル水準で示す。技術的に既知のシミュレーションシステム１０は，開発中の制御システムのモデルの一部１２ａ，１２ｂ，１２ｃ（または，いわゆるサブモデル）が実行される，対応するメモリモジュールを有する，１または複数のシミュレーションプロセッサを備える。シミュレーションシステム１０は，さらに，いわゆる外界と信号を交換するための入力インターフェース１３ａおよび出力インターフェース１３ｂを備える。最終的に，シミュレーションシステム１０は，ホストからシミュレーションターゲットにモジュールをダウンロードし，シミュレーション実験を制御し，モジュール信号およびパラメータをそれぞれに測定およびキャリブレーションするための通信インターフェースを備える。図１は，モデル水準であり，技術水準ではない。刺激（stimuli）信号と称される１４は，物理的な入力信号が利用できない場合に用いられる。これ以外に，通信インターフェースについては，図３で後述される。本発明の通信インターフェースは，必要に応じて図１の構造に付加されうる。

入力および出力インターフェースの信号は，アナログ（例えば，温度または圧力センサ）またはデジタル（例えば，CANのような通信プロトコル）でありうる。シミュレーション実験内では，高速プロトタイピングシステムは，コントローラ（電子制御ユニット）の最終的な状態と同様に，制御ループの不可欠な部分として用いられる。

高速プロトタイピング実験の準備は，一般に次のステップからなる。
１ 例えば，挙動モデリングツール（MATLAB（登録商標）／Simulink（登録商標）^１またはASCET-SD^２のような）の利用または手動による，制御システムの数学モデルの生成
２ 何らかの高水準プログラム言語（例えば，Ｃ）のプログラムコードへのモデルの手動変換（手動コーディング）または自動変換（コード生成）
３ 実行ファイルへのプログラムコードのコンパイルおよびリンク
４ ホストからホスト−ターゲット通信インターフェースを介してシミュレーションターゲットへの実行ファイルのダウンロード
５ 通信インターフェースを介したホストからの実験のセットアップおよび実施

しばしば，１または複数のソース（例えば，挙動モデリングツール，手書きＣコード）からの複数のモデル部分（以下，モジュールと称す）は，制御システムのモデルの全体をなすために，互いに統合される。モジュール１２ａ，１２ｂ，１２ｃ間，およびモジュールと入力または出力インターフェース１３ａ，１３ｂとの間（以下でモジュールとして考慮されるのと同様に）の通信は，図１に円で示される入力および出力ポートを接続する信号を介して行われる。

従来，この通信は，互いに接続されているポートのために全く同一のメモリ域（同一の高水準言語変数）を共有し，あるモジュールが所定のメモリ域に信号の現在値を書込み，他のモジュールがそこから読取ることにより実現される。

これを実現するために，実行コードへのモデルの変換は，例えば，モジュールＡの出力ポートａがモジュールＢの入力ポートｂに接続されることを意味する，実際の相互接続スキームに応じた方法で行われる必要がある。この例では，ポートａおよびｂの両方は，モジュール間通信を可能にするために，シミュレーションターゲット上の全く同一のメモリ域上に静的にマッピングされる必要がある。

かかる従来の静的相互接続アプローチにより，信号は，ポートを分離不可能な方法で互いに接続する。信号間で１または複数の接続が確立，修正または切断される場合は常に，モデルからコードへの変換，コンパイルおよびリンク，実行ファイルのダウンロード，実験のセットアップおよび実施の全体のプロセスが行われる必要がある。実世界モデルの用途で，このプロセスは，非常に時間を要し，数１０分またはそれ以上の時間を要する場合がある。特に，不注意になされた誤った接続を訂正するとき，現在のターンアラウンドタイムは非常に長い。さらに，実験がダウンロ−ドされて開始された直後では，接続は，もはや変更，追加，または削除されえない。

先述のように，制御システムの高速プロトタイピングは，開発中の制御システムの正確な機能およびリアルタイム挙動に関する初期検証のために，自動車業界，航空機業界等で一般に用いられている。このように，車両またはその一部のような動的システムに用いられる制御方法およびアルゴリズムは，制御ループの最終的な実装の有無にかかわらず，実世界の条件下でテストされる。

高速プロトタイピングに続いて，制御システムの最終ソフトウェアが開発されている。結果は，ターゲットとされている電子制御ユニット用として実行可能な高品質ソフトウェアとなる。特に，この段階は，所定の要求に従って挙動を調整するために，ソフトウェアのコーディング，実世界の条件下でのテストおよび観察，およびそのパラメータのキャリブレーションを含む。後の２つのステップは，計測およびキャリブレーション（Ｍ＆Ｃ）技術に基づく。

Ｍ＆Ｃ技術は，以下の場合にホスト−ターゲットアーキテクチャとともに用いられうる。
・ホストは，一般にＭ＆Ｃツールを実行するパーソナルコンピュータである。
・ターゲットは，主にコントローラを作動させる，例えば，高速プロトタイピング用の実験ハードウェア専用，またはソフトウェア開発用の電子制御ユニット（ＥＣＵ）のような埋込み式コンピュータ等である。
・ホストおよびターゲットは，専用のＭ＆Ｃ通信インターフェースを介して互いに接続される。

ホストおよびターゲットからなる複数のインスタンス（instance）は，分散型のＭ＆Ｃシステムに含まれてもよい。

Ｍ＆Ｃツールは，通常，以下のようなタスクを行う。
・制御システムのソフトウェア内の変数値の測定，スコープ，ダイアル，ゲージ，または数字表示のようなグラフィック装置の形式でのそれら変数値の表示，それら変数値のディスクへの書込み
・スライダー，ボタン，ノブ，カーブおよび３次元マップ，または数字表示のようなグラフィック入力機器の形式での表示による，スカラ，アレイ，または補間マップ（interpolated map）等のパラメータ値のキャリブレーション，ならびにユーザによりなされた現在値の変更の制御システムのソフトウェアへの伝送

Ｍ＆Ｃツールは，特に自動車業界では，真のまたは事実上の業界標準のいずれかである，多数の標準Ｍ＆Ｃインターフェースに依存する。高速プロトタイピング用またはソフトウェア開発用の両方の自動車用ハードウェア，特にAステップおよびBステップＥＣＵ（A-step and B-step ＥＣＵs）では，これらインターフェースの利用可能性が前提とされる。これに関連して，高速プロトタイピング用として用いられる実験環境は，限定されたまたは部分的に異なる機能性にもかかわらず，Ｍ＆Ｃツールと同じにみなされる。

Ｍ＆Ｃインターフェースは，ホストおよびターゲット上で，ソフトウェアおよびハードウェアの両方にサポートされる必要がある。両者は，何らかの通信プロトコルを作動する何らかの物理的な相互接続を介して互いに接続される。ホスト上のＭ＆Ｃツールは，一般にこれを目的とするソフトウェアドライバを用いる一方，ターゲットハードウェアは，専用のプロトコルハンドラを実行する。Ｍ＆Ｃプロトコルの例は，CCP，XCP，KWP2000，またはINCA^１，ASAP1b^２／L1¹，およびDistab^１プロトコルである。物理的な相互接続は，例えば，CAN，ETK^３，Ethernet（登録商標），FlexRay，USB，K-Line，WLAN（IEEE802.11），またはBluetoothである。

埋込み制御システムの開発の用途で，しばしば，ASCET^４，MATLAB（登録商標）／Simulink（登録商標）^５，StatemateMAGNUM（登録商標）^６，およびUMLまたはSDLツールのような挙動モデリングツールが用いられる。これらのツールは，一般に，制御システムの構造および挙動を記述するために，ブロック図，状態機械，シーケンス図，フロー図等を用いた，何らかのグラフィカルユーザーインターフェースを備える。このように，制御システムの数学モデルが生成されうる。

ひとたびモデルが利用可能になれば，何らかの高水準プログラム言語（例えば，Ｃ）のプログラムコードへのモデルの自動変換（コード生成），および最終的に実行可能プログラムへの自動変換は，高速プロトタイピング用または高品質ＥＣＵソフトウェア用として行われうる。

制御システムのソフトウェアまたはモデル自体をテストおよびデバッグする便利な方法として，多くのモデリングツールは，シミュレーション中または実行中のモデルの挙動を，以下のように視覚化すること等により，アニメーション化する方法を備える。
・信号線上に現在の信号値を表示する
・グラフィック装置に現在の信号値を表示する
・アクティブ状態および以前にアクティブ状態であったマシンの状態をモデリング環境内で直接的に強調表示する

このように，別個の実験環境は必要とされない。さらに，いくつかのツールは，モデリングツールの通常のユーザインターフェースを用いることで，モデリング環境を介してパラメータ値を直接的にキャリブレーションする可能性を備える。

今日では，このモデルアニメーションおよびモデル内キャリブレーションの従来的なアプローチは，例えば，モデリングツールおよび実験の両方を同時に実行するコンピュータ（オフラインシミュレーション）上，または専用の高速プロトタイピングハードウェア（オンラインシミュレーション）とともに，実験ハードウェア上でのみ利用可能である。さらに，例えば，外部モードプロトコルであるMATLAB（登録商標）／Simulink（登録商標）またはASCETのL1プロトコル等の独自仕様の通信プロトコルが用いられる。

上述されるこの従来的なアプローチは，図６に示される。

高速プロトタイピングシステムは，通常，以下の主要コンポーネントからなるハードウェア／ソフトウェア融合システムをなすものとして特徴付けられる。
・開発中の制御システムのモデルまたはプログラムコードの一部を基本的に個別に実行し，対応するメモリモジュールを有する，１または複数のシミュレーションプロセッサからなるシミュレーションターゲット
・プラント（制御されている外界）より与えられている信号からなる入力インターフェース
・プラントに与える信号からなる出力インターフェース
・ホスト（多くの場合，パーソナルコンピュータ）からシミュレーションターゲットに制御プログラムをダウンロードし，シミュレーション実験（開始および停止指令等）を制御し，モジュール信号およびパラメータをそれぞれに測定およびキャリブレーションするための通信インターフェース。

入力および出力インターフェースの信号は，アナログ（例えば，温度または圧力センサ）またはデジタル（例えば，CANのような通信プロトコル）でありうる。シミュレーション実験内では，高速プロトタイピングシステムは，コントローラ（電子制御ユニット）の最終的な状態と同様に，制御ループの不可決な部分として用いられる。

シミュレーションターゲット上の制御システムのコードは，通常，オペレーティングシステムＯＳ（Operating System），特にリアルタイムＯＳ（ＲＴ−ＯＳ^７），上で作動し，アプリケーションのリアルタイム挙動を規定および制御する。このため，他のプラットホームソフトウェアと連携して，ＲＴ−ＯＳは，一般にスケジューリング，リソース管理，Ｉ／Ｏ管理，または通信およびネットワーク管理のようなタスクを行う。自動車業界では，主にERCOSEK^９のようなOSEK/VDX^８準拠のＯＳが用いられる。

かかるシステムは，図８に示される。例として，マイクロコントローラハードウェア８３と，フラッシュローダ８４ａ，診断８４ｂ，通信およびネットワーク管理８４ｃ，スケジューラ８４ｄおよびハードウェア抽象化層８４ｅを伴うＲＴ−ＯＳ８４を含むプラットフォームソフトウェアとが記述されている。ＲＴ−ＯＳ８４とマイクロコントローラハードウェア８３との間のインターフェース８５が示される。インターフェース８６により，モジュール８７ａ，８７ｂおよび８７ｃを含むアプリケーションソフトウェアは，ＲＴ−ＯＳ８４と接続される。

アプリケーションは，通常，個別にプライオリティ，スケジューリングモード，実行期間およびオフセット，割込みソース，完了期限等を関連付けて有する，多数のタスク（OSEK/VDXのように），スレッド，またはプロセスに分割される。これらのデータにより，ＲＴ−ＯＳのスケジューラは，要求されるリアルタイム挙動を準備するために，タスクを発送，実施，および制御する。

埋込み制御用の多くのＯＳ，特にOSEK/VDX準拠のシステムは，静的に設定されている。これは，ＯＳの設定が何らかのＯＳ設定ユーティリティにより生成されているＣコードを用いて行われることを意味する。このＯＳ設定は，何らかの所定のＯＳ仕様（例えば，OSEK/VDXの場合のOIL^１０記述）を，例えば，スケジューラ，割込みマスクおよび割込みハンドラ，プライオリティスキームおよびタスクFIFO^１１キュー，タイマまたはスタックにより呼出される機能ポインタを含む，タスクコンテナおよびタスクテーブル等，ＯＳの内部データ構造および機能性を表すＣコードに変換する。

動的に設定可能なＯＳと異なり，静的に設定可能なＯＳは，一般に，演算処理速度およびメモリ消費の観点からより高いランタイム性能のために，全ての設定がコンパイル時の静的メモリ配置および初期化によりなされることを必要とする。一方，静的ＯＳ設定の修正は，動的に設定可能なＯＳとは対照的に，ランタイム時に行われえない。それにもかかわらず，動的に設定可能なＯＳは，ランタイム時に再設定されるよりはむしろ，システム起動時にアプリケーション自体によって通常１度だけ設定される。この通常の場合，ＯＳ設定は，ＯＳ仕様から手動コーディングまたはコード生成のいずれかによってなされる。

高速プロトタイピング実験の準備は，一般に以下のステップからなる。
１ 何らかの高水準プログラム言語（例えば，Ｃ）の制御システムのプログラムコードへの手動実装（手動コーディング）または自動コード生成（何らかの数学モデルから）
２ 手動，または何らかのテキストもしくはグラフィックユーティリティのサポートによるＯＳ仕様の生成
３ コード生成を用いたリアルタイムＯＳの設定
４ ＲＴ−ＯＳおよび設定を伴うプログラムコードの実行ファイルへのコンパイルおよびリンク
５ ホストからホスト−ターゲット通信インターフェースを介してシミュレーションターゲットへの実行ファイルのダウンロード
６ 通信インターフェースを介したホストからの実験のセットアップおよび実施

上述のように，この従来的なＯＳ設定アプローチでは，１度実行ファイルが生成されると，リアルタイム挙動は，もはや変更できない。プログラムコードおよびＲＴ−ＯＳは，分離不可能な方法で互いに関連付けられる。制御システムの１または２以上のリアルタイム特性が修正される場合，常に，ＯＳ仕様の全プロセス，コード生成を介した設定，コンパイルおよびリンク，実行ファイルのダウンロード，実験のセットアップおよび実施が行われる必要がある。実世界制御システムの用途で，このプロセスは，非常に時間を要し，数１０分またはそれ以上の時間を要する場合がある。特に，不注意になされた誤った接続を訂正するとき，現在のターンアラウンドタイムは非常に長い。さらに，実験がダウンロ−ドされて開始された直後では，接続は，もはや変更，追加，または削除されえない。

現在までの従来的なアプローチは，ETAS GmｂH（ASCET-SD製品群），The Mathworks，Inc．（MATLAB（登録商標）／Simulink（登録商標），Real-TimeWorkshop（登録商標），xPC Target）およびおそらく他のような，高速プロトタイピングシステムにより用いられることが知られている。

従来技術として既知のかかる静的相互接続は，図２ａに視覚化される。図２ａは，静的メモリ域８１に記録される変数を共有している，第１モジュール１２ｄおよび第２モジュール１２ｅを示す。

よって，発明の目的は，実行中のシミュレーションが容易に訂正，阻止または修正されうるように，これまでの静的接続より柔軟性の高い相互接続を提供することにある。本発明のさらなる目的は，車両の制御システムの高速プロトタイピングを提供するために，シミュレーションシステムの単体コンポーネント間の通信，およびシミュレーションモデルの単体モジュール間の通信を改良することにある。

これらの目的は，個々の独立請求項の特徴を有する，制御システムをシミュレーションおよび検証するためのシミュレーションシステムおよびコンピュータにより実施される方法を提案することにより実現される。

発明の利点

上述された従来技術に基づくアプローチとは対照的に，本発明の動的相互接続アプローチは，相互接続スキームに固有のモデル−コード変換に依存しない。代わりに，この変換は，使用されている実際のモジュール相互接続から完全に独立する。むしろ，モジュール間通信は，共有されるメモリ域ではなく別個のメモリ域を用いて，必要に応じてあるメモリ域から他のメモリ域に信号値をコピーまたは複製（replicating）することによる，系統だった方法により行われる。

有利に，開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステム，すなわち，少なくとも制御システムの一部を表すターゲットのＯＳがターゲットのＯＳに専用のＡＰＩ（Application Programming Interface）を介してホストにより再設定される，ホスト−ターゲットアーキテクチャからなるシミュレーションシステムが提示される。開発中の制御システムをシミュレーションおよび検証するために，かかるシミュレーションシステムを用いてコンピュータにより実施される方法と，コンピュータ上で実行される場合にかかる方法を実施するに適したプログラムコーディング手段を伴うコンピュータプログラムと，RAM,DVD,CD-ROM，ROM，EPROM，EEPROM，Flash等のようなコンピュータ読取り可態な媒体およびコンピュータ読取り可態な媒体に記録された各コンピュータプログラムを伴うコンピュータプログラム製品も，また本発明の一部である。

このシミュレーションシステムでは，ＯＳは，リアルタイムＯＳであり，ターゲットのソフトウェアのリアルタイム挙動が定義または変更されるように，ターゲット上に実行可能ソフトウェアをダウンロードした後に再設定される。

有利に，ＯＳのＡＰＩが用いられ，または，ＯＳのＡＰＩの代わりに第２の再設定可能なＡＰＩが用いられる。

かかるシミュレーションシステムでは，ホストは，少なくとも１つのモデリングツールを含み，制御システムのターゲットソフトウェア上で実行され，ターゲットサーバは，ターゲットとの通信に用いられる通信プロトコルのプロトコルドライバを含み，モデリングツールをターゲットに接続するために用いられる。

請求項４に係るシミュレーションシステムでは，少なくともいくつかのモジュールが別個のメモリ域を介する通信のために動的に再設定可能である。

他の実施形態では，シミュレーションシステムは，対応するメモリおよびインターフェースモジュールを伴う複数のシミュレーションプロセスを備えて示される。かかるシミュレーションシステムでは，モジュールがモジュール間通信用の別個のメモリ域を備え，シミュレーションが制御システムのシミュレーションモデルを実行することにより行われ，シミュレーションモデルが複数モジュールのうちの１モジュール上でそれぞれに実行されている多数のサブモジュールを備え，少なくともいくつかのモジュールが別個のメモリ域を介する通信のために動的に再設定可能である。

また，発明の一部は，開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステムのホストであり，ホスト−ターゲットアーキテクチャを備え，少なくとも制御システムの一部を表すターゲットのＯＳがターゲットのＯＳに専用のＡＰＩを介してホストにより再設定される，シミュレーションシステムである。

相互接続スキームは，単にシミュレーション実行ファイルに反映させるものではなく，シミュレーションターゲット上にそれぞれ渡される必要がある。これは，実行ファイルがダウンロードされた後，実験セットアップ中に，ホスト−ターゲット通信インターフェースを介して実際のモジュール相互接続が動的にセットアップされることにより実現される。

信号値の交換は，個別の相互接続スキームに基づいて行われる。暗示的な命名仕様（naming conventions），または静的メモリ共有アプローチに伴うような同様なものは，必要とされない。むしろ，所定の信号の現在値は，出力ポートに関連付けられるメモリ域から明示的に読取り，個別の入力ポートに対応するメモリ域に複製することにより，出力ポートから接続されたいかなる入力ポートにも分配される。

このアプローチの主な利点（説明中で詳細に示される）は，以下のようになる。

・コード生成，コンパイルおよびリンク，および実行ファイルのダウンロードを介するＯＳ設定の時間を要するプロセスが繰返されないため，ＯＳ仕様の変更後のターンアラウンドタイムが著しく低減される。これは，高速プロトタイピングの実際のアプリケーションを強力にサポートする。

・タスク，プロセス，アプリケーションモード，アラーム，イベント，またはメッセージのようなＯＳオブジェクトは，かなりの遅れを伴うことなく，実行中の実験中でさえ，確立，修正，または削除されうる。これは，以下のような新たな利用ケースを完全に可能にする（プロセッサ負荷，タスクのジッタ，グロスおよびネットのランタイム，期限違反等を測定する，または，例えばガントチャートの形式等でグラフィックトレース情報を表示する，何らかのＯＳモニタリングユーティリティにより最適にサポートされる）。
・実験を中断することなく，オンザフライで誤った設定を訂正する。
・制御システム全体の一部を徐々に実行することにより実験を徐々にセットアップし，一方で最終的なリアルタイム挙動を継続的に確立する。
・制御システムの要求に応じて，タスク期間，オフセット，および期限を繰返し調整する。
・タスクを待機フェーズにシフトすることによりプロセッサ負荷を平準化する。
・“トライアル＆エラー”再設定により，安定かつ機能的に的確な挙動のための許容値の範囲を特定する。
・集中的なアプリケーションの演算処理に際して，現時点で重要でない機能性を“オフ”することにより，負荷を平衡化する。
・オンザフライでタスクを生成および起動することにより，制御システムの一部を自発的にトリガする。
・対応するタスクまたはプロセスをマスクまたは抑制することにより，制御システムの一部を停止する。
・プロセスを内部実装からクランク軸同期信号のような実世界入力割込みに，または反対に切替える。
・対応する制御システムの一部を択一的に実行可能および実行不能にすることにより，並列に実行されている同一モジュールの多数の実装バリエーションを比較する。

・モデル−コード変換，コンパイルおよびリンク，および実行ファイルのダウンロードの時間を要するプロセスが繰返されないため，相互接続スキームの変更後のターンアラウンドタイムは著しく低減される。これは，高速プロトタイピングの実際のアプリケーションを強力にサポートする。

・ポートを接続する信号は，かなりの遅れを伴うことなく，実行中の実験中でさえ，確立，修正，または削除されうる。これは，以下のような利用の新たな可能性を完全に可能にする。
・実験を中断することなく，オンザフライで誤った設定を訂正する。
・制御システム全体の一部を徐々に実行することにより実験を徐々にセットアップし，一方で最終的な相互接続スキームを継続的に確立する。
・入力ポートとの接続を確立することにより，自発的にモデルを活性化（stimulate）させる
・入力ポートを所定の活性化モジュールから実世界入力信号に切替える。
・それらの出力をプラントに択一的に切替えることにより，並列に実行されている同一モジュールの多数の実装バリエーションを比較する。
・高速プロトタイピングシステムへの入力または出力を，物理的なケーブル接続での引抜きおよび差込みに代わって実質的なツールレベルで交換する。

よって，本発明によれば，シミュレーションモデルは，シミュレーションシステムの同一または異なるノード（プロセッサ）上で実行される多数のサブモデルからなり，開発中の制御システムをシミュレーションおよび検証するために実行される。モジュールが互いに動的に接続され，シミュレーションモデルおよびシミュレーションシステムの個別モジュール間の通信が個別および分離されたメモリ域を介して行われる。

本発明の望ましい一実施形態では，データおよび／または信号がクロスバースイッチによって整合性を保ちつつ複製される。望ましくは，この複製がリアルタイム条件下で行われる。

本発明の他の実施形態では，モジュールが相互接続ノードを介して自動的に相互接続し，データを複製する。

リアルタイム状況または条件下でのデータの整合性を保った複製は，通信変数を介してなされうる。上述のクロスバースイッチは，整合性を保てる状態に達した後に，出力信号の値を通信変数に整合性を保ちつつコピーする手段を備える。さらに，クロスバースイッチは，個別のモジュールが演算処理を継続する前に，これらの値を接続された入力信号に整合性を保ちつつ渡す手段を備える。

シミュレーションシステムの個別のリアルタイムアーキテクチャ，および／またはリアルタイムＯＳのセットアップに応じて，整合性を保ったコピーの機構は，アトミックコピープロセス，ブロッキングインタラプト，または同様な方法により実現されうる。個別のリアルタイム環境設定により定められている特定の状況下では，信号変数または通信変数が利用されず，より高いパフォーマンスを得るために切離して最適化される場合がある。

本発明の代替手段の実施形態によれば，モジュール相互接続の動的再設定のために，上述の集中型アプローチの代わりに分散型アプローチが用いられうる。この代替手段の実施形態では，ポートは，個別の相手方に自らを接続し，信号値の複製を担いうる。

本発明は，また，コンピュータ上で実行される場合，上述のような本発明によるプロセスを実施するに適したプログラムコーディング手段を伴うコンピュータプログラムを含む。コンピュータプログラム自体，およびコンピュータ読取り可態な媒体上に記録されたコンピュータプログラムが請求される。

さらに，本発明の特徴および実施形態は，添付図面および実施形態の説明によって明らかにされる。

上述および後述の特徴は，本発明の範囲内において，指定される組合せのみならず他の組合せまたはそれら自体でも用いられうるものと理解される。

本発明は，一例として一実施形態を用いて概略的に図面に示され，以下で図面を参照して詳細に説明される。説明は，本発明の範囲を限定するものではなく，単に本発明の望ましい一実施形態を示すものであると理解される。

実施形態

図２ａを参照して上述された従来技術から既知の静的接続とは対照的に，本発明によれば，別個のメモリ域を介する動的相互接続アプローチが提供される。本発明に基づく動的相互接続の原理は，図２ｂに視覚化されるように，第１モジュール２ｄのデータ８１ａが動的複製２０により第２モジュール２ｅの別個のメモリ域にデータ８１ａ’としてコピーまたは複製される。

動的再設定アプローチを構成する複数のアーキテクチャが考えられうる。図３を参照すれば，本発明に基づくシミュレーションシステム３０の第１の例は，いわゆる集中型アプローチとして以下に説明される。

集中型アプローチのシミュレーションシステム３０の主要コンポーネントは，相互接続スキーム１１を伴ういわゆるクロスバースイッチ１０である。シミュレーションシステム３０は，さらに複数のモジュール２ａ，２ｂ，２ｃ，入力インターフェース３ａ，出力インターフェース３ｂ，刺激生成モジュール４およびリアルタイムＯＳ７を備える。

図３で両矢印により視覚化されるように，シミュレーションシステム３０の全コンポーネントは，クロスバースイッチ，すなわち，シミュレーションターゲット上のモジュールの出力および入力ポートの互いの接続を定義する相互接続スキーム１１を介して，互いに相互接続される。相互接続スキームは，ブロック図中の接続の全体に対応し，各ブロックがシミュレーションターゲット３０上で統合されているモジュールの１つに対応する。

相互接続スキーム１１は，両方の次元がモジュールのポートを意味し，マトリクス値が個別ポートの互いの接続（さらに可能であれば，信号フローの方向）を定義する，二次元交換マトリクスとして考えられうる。

シミュレーションホスト５は，ホスト−ターゲット通信インターフェース６を介してクロスバースイッチ１０と接続され，高速プロトタイピングシステムに対するヒューマン・マシン・インターフェースを構成する。

ホスト５は，望ましくは何らかのグラフィックユーザインターフェースによりサポートされて，相互接続スキームの設定および再設定を可能にする。

ホスト−ターゲット通信インターフェース６は，シミュレーションホスト５をシミュレーションターゲット３０に接続する。一般に，これは，有線または無線の接続（シリアルインターフェース，Ethernet（登録商標），Bluetooth等）に基づいており，規格化されたまたは独自仕様の通信プロトコル（例えば，ASAP1b，L1）である。これは，少なくとも以下の機能性を備える。
・ホスト５からシミュレーションターゲット３０へのシミュレーション実行ファイルのダウンロード
・相互接続スキーム１１を定義する設定データのダウンロード

さらに，これは，以下の用途の機能性を備えうる。
・例えば，シミュレーションを開始および停止するために，実験を制御する
・モデル信号，相互接続信号，および入力または出力信号の値を測定する
・モデルパラメータをキャリブレーションする等

クロスバースイッチ１０は，シミュレーションターゲット上で作動し，以下に接続される。
・ホスト−ターゲット通信インターフェース６を介してシミュレーションホスト５
・開発中の制御システムのモデル部分またはサブモデルを表すモジュール２ａ，２ｂ，２ｃ
・制御システムのプラントとの入力および出力インターフェースを表すモジュール３ａ，３ｂ
・モデルに対する刺激生成器として機能するモジュール４
・望ましくは，シミュレーション実験を構成するリアルタイムＯＳ７

シミュレーション実験を開始する前，初期の相互接続スキーム１１は，ホスト５からホスト−ターゲット通信インターフェース６を介してクロスバースイッチ１０にダウンロードされる。

実験の実施中，クロスバースイッチ１０は，出力ポートから入力ポートに信号値をコピーすることによってモジュールおよびコンポーネント間で実際の通信を行う。この複製プロセスが行われる方法は，相互接続スキーム１１によって定義される。

相互接続スキーム１１は，割込み後または実行中のシミュレーションでさえ再設定されうる。よって，モジュール相互接続は，かなりの遅れを伴うことなく，オンザフライで変更されうる。

図４を参照すれば，本発明に基づく信号および／またはデータの伝達の望ましい代替手段が示されている。動的複製４０により，第１モジュール２ｆの信号および／またはデータ値８２ａ，８２ｅは，通信変数８２ｂ，８２ｆとしてそれぞれに個別のメモリ域にバッファリングされうる。さらなる動的複製４０により，第２および第３モジュール２ｇ，２ｈは，個別の信号および／またはデータ値８２ｃ，８２ｇおよび８２ｄ，８２ｈをそれぞれに受取る。

よって，リアルタイム環境内でのデータの整合性が確保される。各モジュール２ｆ，２ｇ，２ｈは，例えば，異なる速度でまたは割込みトリガに応じて演算処理でき，データ複製４０は，現在の信号値をバッファリングする通信変数８２ｂ，８２ｆを用いて行われる。よって，全体として有効状態を構成する複数の出力信号の値は，これらの出力信号が入力されているモジュールが自らを有効状態に依存できるように，整合性を保った方法によってコピーされることを保証される。

すでに上述したように，クロスバースイッチ１０は，以下の手段を備える。
・整合性を保てる状態に至った後に，出力信号の値を通信変数に整合性を保ちつつコピーする
・個別のモジュールが演算処理を継続する前に，これらの値を接続された入力信号に整合性を保ちつつ渡す

上述の整合性を保ったコピー機構は，リアルタイムアーキテクチャおよびＯＳの構成に応じて，アトミックコピープロセス，ブロッキング割込み等により実現されうる。

個別のリアルタイム環境設定により定められている特定の状況下では，信号変数または通信変数が利用されず，より高いパフォーマンスを得るために切離して最適化される場合がある。

上述の動的再設定アプローチは，信号調整設備によって拡張されうる。これを実現するため，各信号値は，元の値をソースメモリ域から読取った後にターゲットメモリ域に書込む前に，所定方法によるモジュール間通信中に操作されうる。

可能な信号調整オペレーションは，以下のようである。
・実装方式の適応（例えば，スケールまたはオフセット修正，サチュレーション）
・基本数理オペレーション（例えば，信号の和，差，積，参照テーブルまたは補間特性によるマッピング，定数）

適用されているオペレーションの種類および個別のパラメータは，相互接続スキームの一部をなしているものとして考慮される。これらの各々は，モジュール相互接続として，動的方法で設定および再設定されうる。この拡張は，動的再設定アプローチの実用性を著しく拡大する。

図５を参照すれば，ターゲット上で個別のクロスバースイッチコンポーネントを用いる集中型アプローチの代わりに用いられうる，モジュール相互接続の動的再設定のための分散型アプローチが説明される。ポートは，中央コンポーネントのコピー信号値を有するよりむしろ，個別の相手方に自らを接続し，信号値の複製を担いうる。

例えば，これは，モジュール２ｊおよび２ｋの入力ポート９２ａ，９２ｂおよび９３ｂ自体を，所定の出力ポートをそれぞれに表す，接続されているモジュール２ｉの出力ポートサーバ９１ａ，９１ｂに登録させることによって実現されうる。通信は，プルアプローチ（入力ポートクエリー信号値）またはプッシュアプローチ（出力ポートにより実施される信号値のマルチキャスト）のいずれかに従って行われうる。よって，値複製用の情報は，中央クロスバースイッチコンポーネントに集中される代わりに，システムのコンポーネントに分配される。

（高速プロトタイピングおよびソフトウェア開発のための包括的なモデルアニメーションおよびモデル内キャリブレーションインターフェース；図７）
高速プロトタイピングおよびソフトウェア開発のための包括的なモデルアニメーションおよびモデル内キャリブレーションインターフェースは，ホスト−ターゲットアーキテクチャを伴った測定およびキャリブレーション技術，および個別のシミュレーションシステムおよび方法を用いる。

（基本概念）
従来技術で説明されたアプローチと対照的に，本発明の包括的なモデルアニメーションおよびモデル内キャリブレーションアプローチは，専用のシミュレーションまたは高速プロトタイピングハードウェアまたは独自仕様の通信プロトコルのいずれにも依存しない。代わりに，標準Ｍ＆Ｃ技術が用いられる。

先述のように，このアプローチの主な利点は，以下のようである。
・アプローチが標準化された解法に基づくため，関連するハードウェアおよびソフトウェアにおいてM＆C技術の形式で必要とされるインターフェースの利用可能性が前提とされうる。
・ターゲットハードウェアおよび物理的な相互接続の各組合せにソフトウェアをポーティングする必要がない（さもなければかなりの労力となる）。
・オフラインおよびオンラインの実験中，およびＥＣＵ作動中のモデルアニメーションおよびモデル内キャリブレーションのために，同一のモデリングツールインターフェースが用いられうる。
・付加的な独自仕様のプロトコルハンドラが必要とされないため，ターゲットハードウェア上にはメモリもランタイムオーバヘッドも存在しない。
・付加的な独自仕様のプロトコルが作動しないため，物理的な相互接続上に帯域幅オーバヘッドが存在しない。
・通信用にバックグラウンドタスクまたは同様なものが必要とされないため，ターゲットハードウェア上でのモデルのランタイム挙動が左右されない。
・よって，特にＥＣＵ（一般にメモリおよびランタイムリソースが非常に少なく，本質的に多数のハードウェアおよびインターフェースバリエーション上でM＆C技術をサポートする）が理想的にサポートされる。
・ログ＆リプレイのオフラインデバッギング機能性がサポートされる。
・包括的なモデルアニメーションの用途で，制御システムのソフトウェア，またはそのモデルのアニメーション化，またはその挙動の視覚化のために，これらの標準インターフェースが用いられる。
・モデル内キャリブレーションの用途で，制御システムのソフトウェアのパラメータをそのモデル内からキャリブレーションするために，これらの標準インターフェースが用いられる。
・ログ＆リプレイの用途で，測定データをホスト上にログし，後でアニメーション化および視覚化用のモデリングツール上で透過的にリプレイするために，これらの標準インターフェースが用いられる。
・標準インターフェースの利用は，関連するハードウェアシステムの大半（ターゲット，ホスト，および両者間の相互接続の組合せ）で可能であり，よって，ソフトウェア適応またはポーティングのための付加的な労力を要しない。
・ホストまたは高速プロトタイピングターゲット上のシミュレーション，およびＥＣＵ動作の用途で，同一の標準インターフェースが用いられうる。
・利用可能な標準インターフェースを用いるため，メモリ，ランタイム，および帯域幅オーバヘッドが免れる。

オフラインデバッギングは，例えば，オンライン実験中，まず，測定データがホストのメモリまたはハードディスク上にログされることを意味する。その後，データは，以前に接続された高速プロトタイピングハードウェアまたは作動中のＥＣＵを模倣して，オフラインモードでモデリングツールに対してリプレイされる。これは，モデリングツールに対して完全に透過的に行われうる。さらに，このアプローチによって可能となる共通のデバッグ機能は，モデリングツールによるサポートが想定される，シングルステップ実行およびモデルブレイクポイントである。

図７では，モデリングツール７０ａおよび７０ｂ，および選択的にM＆Cツール７１が示される。これらのモデリングツール７０ａおよび７０ｂ，選択的にM＆Cツール７１と，ターゲット８０との間には，モデルアニメーションインターフェース７２が配される。プロトコルドライバ７４（例えば，CCP ７４ａ，XCP ７４ｂ，KWP2000 ７４ｃ，INCA ７４ｄ，ASAP ７４ｅ，Distab ７４ｆ等）を伴うターゲットサーバ７３または同様なものが，物理的な相互接続７５に接続される。ターゲット８０内の標準M＆Cインターフェース７６は，この物理的な相互接続７５をモデル７７ａおよび７７ｂに接続する。ターゲットまたはターゲットプロセッサ上では，開発中の制御システムの少なくとも一部として，アプリケーションソフトウェアが実行される。このアーキテクチャは，本発明のシミュレーションシステムの一例である。包括的なモデルアニメーションおよびモデル内キャリブレーションアプローチを構成する複数のアーキテクチャが考えられうる。一例として，ターゲットサーバに基づくこのアプローチが以下で説明される。この主要コンポーネントは，ホストコンピュータ上で作動し，ホストおよびターゲットハードウェア上のモデリングツール間でブリッジを形成するターゲットサーバである。

１つの物理的な相互接続に接続される単体のターゲットの代わりに，分散型システムを構成し，多様な通信チャネルを介して接続される複数の異なるハードウェアターゲットが考えられる。さらに，各モデリングツールは，ターゲット上の複数のモデルのアニメーションおよびキャリブレーションのために同時に用いられうる。

（機能）
（ターゲットサーバ）
ターゲットサーバは，包括的なモデルアニメーションおよびモデル内キャリブレーションアプローチの中央コンポーネントである。この役割は，ターゲットハードウェアおよび通信抽象化の役割である。ターゲットサーバの主要タスクは，モデリングツールをターゲットハードウェアのＭ＆Ｃインターフェースに透過的な方法で接続することである。

このように，モデリングツールは，ターゲットとして用いられる個別のハードウェア，またはホスト−ターゲットインターフェースとして用いられている，通信プロトコルもしくは物理的な相互接続を認識する必要がない。この目的のために，ターゲットサーバは，モデルアニメーション関連の通信からM＆C固有のプロトコルへの転換を行うために，サポートされる各通信プロトコルのための専用プロトコルドライバまたは同様なものを含みうる。

ターゲットサーバの他のタスクは，後でオフラインデバッギングリプレイに用いるために，測定データをホストのメモリまたはハードディスク上にログすることである。

（モデリングツール）
モデリングツールは，そのモデルアニメーションインターフェースを介してターゲットサーバにアクセスする。このように，モデルのアニメーション化に要するデータは，ターゲットからモデリングツールに渡される。さらに，キャリブレーションデータは，反対方向，モデリングツールからターゲットハードウェアに渡される。

基本的なモデルアニメーションおよびモデル内キャリブレーションは，ターゲットアクセスのために，独自仕様の通信プロトコルの代わりにターゲットサーバを用いると直ぐに，モデリングツール内で利用可能となる。シングルステップデバッギングおよびモデルブレークポイントのような高度なログ＆リプレイ機能の用途で，モデリングツールは，付加的な機能性を備えることが前提とされる。

（Ｍ＆Ｃツール）
M＆Cツールは，全く同一のM＆Cインターフェースおよび通信チャネルを用いてモデリングツールと並列して作動しうる。しかし，これは，包括的なモデルアニメーションおよびモデル内キャリブレーションのための前提条件ではないが，従来的なＭ＆Ｃアプローチを実行するために描かれる。

複合（モデリングまたはＭ＆Ｃ）ツールが同時に１つかつ同一セットのパラメータのキャリブレーションを試みる場合，安全およびデータの整合性のために排他制御（arbitrage）スキームが用いられる必要がある。この排他制御スキームは，以下の技術の１つまたは２つ以上を用いうる。例えば，
・例えば，読取り専用パラメータを用いて，所定のパラメータセット（マスタ／スレーブ法則）のキャリブレーション用のツール以外の全てをロックする。
・所定セットのパラメータのキャリブレーション後，他の全てのツールに通知する。
・所定のパラメータセットの定期的な測定を介して操作される全てのツールによってパラメータをリフレッシュする（ポーリング）。

（アプリケーションソフトウェア）
ターゲット上で作動するアプリケーションソフトウェアは，主にモデルのコード，リアルタイムＯＳ，またはモデルコードを実施するスケジューラ，モデル入力および出力を可能にするハードウェアおよび通信ドライバ等からなる。

シミュレーションされているモデルから生成されるコードは，モデル固有の挙動に基づいて演算処理を行う。コード内のデータ構造は，従来的な測定およびキャリブレーション，またはモデルアニメーションおよびモデル内キャリブレーションをそれぞれに行うために，標準Ｍ＆Ｃインターフェースによってアクセス（読取りおよび書込み）される。

（標準Ｍ＆Ｃインターフェース）
ターゲット上の標準Ｍ＆Ｃインターフェースは，アプリケーションソフトウェアとターゲットサーバとの間のリンクを構成する。これは，測定およびキャリブレーションのためにモデルデータにアクセスし，物理的な相互接続を介してホストに接続される。
・測定の用途で，Ｍ＆Ｃインターフェースは，データをアプリケーションソフトウェアから読取り，Ｍ＆Ｃプロトコルを介してターゲットサーバに渡す。ここで，ターゲットサーバがデータをモデリングツールおよびＭ＆Ｃツール（適用可能であれば）に送る。
・キャリブレーションの用途で，モデリングツールまたはＭ＆Ｃツールは，ターゲットサーバおよびＭ＆Ｃプロトコルを介してＭ＆Ｃインターフェースに新たなパラメータ値を送信する。ここで，Ｍ＆Ｃインターフェースがターゲット上のアプリケーションソフトウェア内で新たなパラメータ値を更新する。

標準Ｍ＆Ｃインターフェースとしては，物理的な相互接続としての，例えば，CAN，Ethernet（登録商標），FlexRay，USB，またはK-Lineに基づいて，例えば，CCP，XCP，KWP2000，INCA，またはASAP1bプロトコルが用いられうる。

（代替手段）
（分散型アプローチ）
中央ターゲットサーバコンポーネントを用いる代わりに，各モデリングおよびＭ＆Ｃツールは，ホスト側のＭ＆Ｃインターフェース適応を自らに内蔵しうる。このように，ターゲットハードウェアからの抽象化が未だ維持されうる一方で，通信チャネルからの抽象化が関連するツールに転送される。

この理由から，ターゲットアクセスの透過性が低下し，サポートされているＭ＆Ｃインターフェースの数が少なくなりうる。さらに，ログ＆リプレイオフラインデバッギングのサポートがより高価なものとなる。一方で，さもなければ，全てのモデリングおよびＭ＆Ｃツールがターゲットサーバコンポーネントの１つかつ同一のインターフェースに従うことを必要とするものではない。

（Ｍ＆Ｃツールインターフェースアプローチ）
モデリングツールをターゲットサーバに直接的にアクセスさせる代わりに，Ｍ＆Ｃツールが中継として用いられうる。このため，モデルアニメーションインターフェースは，ターゲットサーバに内蔵されず，例えば，高速プロトタイピング用の実験環境等のＭ＆Ｃツールに内蔵される。そして，モデリングツールがこのインターフェースに接続する。

このアプローチは，以下の理由から，キャリブレーションの排他制御のためのサポートをより容易に提供しうる。
・一般に，同一セットのパラメータのキャリブレーションでは，Ｍ＆Ｃツールおよび単体モデリングツールのみが競合する。
・Ｍ＆Ｃツールは，キャリブレーション指令をモデリングツールから受取り，自らの目的（表示値のリフレッシュ，データ記録等）のために解釈し，実際のキャリブレーションプロセスのためにターゲットサーバに渡す。

（高速プロトタイピングシステム上でのリアルタイムＯＳの動的最設定；図９，図１０）
（基本概念）
上述のアプローチと対照的に，本発明の動的再設定アプローチは，コード生成または手動コーディングによるＯＳ設定に依存しない。代わりに，設定および統合プロセスは，用いられている実際のＯＳ仕様から完全に独立している。むしろ，図９に示すように，ＲＴ−ＯＳとアプリケーションとの関連付けは，ダウンロードおよびアプリケーションとのアセンブルの後，ランタイム直前またはランタイム時におけるＯＳの設定によりなされる。このアプローチが静的および動的に設定可能なＲＴ−ＯＳにアドレス指定する点に留意する。

ＯＳ仕様は，単にシミュレーション実行ファイルにより反映されるものではなく，別途にシミュレーションターゲット上に渡される必要がある。これは，実行ファイルがダウンロードされた後，実際のＯＳ，特にＲＴ−ＯＳの設定が実験セットアップ中にホスト−ターゲット通信インターフェースを介して動的および外部的にセットアップされることにより実現される。構成するＯＳの性能に応じて，動的ＯＳ再設定は，実験のランタイム中でさえ行われうる。図９ａおよび図９ｂでは，これが，タスクＴｂｇ，Ｔ１，Ｔ２およびＴ３で，それらのプログラムＰ１，Ｐ２，Ｐ３，Ｐ４，Ｐ５およびＰ６を伴って時間ｔ（０〜１００時間単位）上に示される。図９ａおよび図９ｂでプログラムおよびそれらの配置および割込み挙動を対比すれば，この例の再設定プロセスが明らかになる。

動的に設定可能なＯＳの用途で，これは，既存のＯＳＡＰＩを介してなされる。おそらく，修正は必要とされない。静的に設定可能なＯＳは，一般に，少なくともＯＳ初期化またはＯＳ始動の間，およびそのシャットダウン後にアクセス可能である，ＯＳ再設定ＡＰＩとともに拡張される必要がある。これは，おそらく，ＯＳ内部データ構造の配置および初期化を静的なものから動的なものに変更することを意味する。

以下では，簡略化のためにERCOS^ＥＫＯＳが典型的な方法（ただし，本発明の他のＲＴ−ＯＳへの適用可能性を制限することを意味しない）で用いられている。
ERCOS^ＥＫは，スケジューラエンティティとしてプロセス（無効／Ｃ無効機能）を含むタスク，およびコオペラティブおよびプリエンプティブなスケジューリングを同時にサポートする。

特に，以下のＯＳオブジェクト形式でのリアルタイム特性は，動的再設定の対象になることが前提とされる（ただし，以下は，限定列挙するものではない）。
・タスクの種類（定期，ISR，ソフトウェアによって，またはアプリケーションモード初期化に応じて実施されるタスク）
・タスクプライオリティおよびスケジューリングモード（コオペラティブ，プリエンプティブ，またはノンプリエンプティブ）
・タスク期間およびオフセット
・タスク期限および最大起動数
・タスク内容：タスク内のプロセスおよびプロセス順序
・ＯＳのアプリケーションモード
・リソース，アラーム，およびカウンタ
・Ｉ／Ｏ設定（ドライバ，ハードウェア抽象化層，等）およびネットワーク管理
・通信用のイベントおよびメッセージ
・それらの関連付け

このアプローチの主な利点は：
・コード生成，コンパイルおよびリンク，および実行ファイルのダウンロードを介するＯＳ設定の時間を要するプロセスが繰返されないため，ＯＳ仕様の変更後のターンアラウンドタイムが著しく低減される。これは，高速プロトタイピングの実際のアプリケーションを強力にサポートする。
・タスク，プロセス，アプリケーションモード，アラーム，イベント，またはメッセージのようなＯＳオブジェクトは，かなりの遅れを伴うことなく，実行中の実験中でさえ，確立，修正，または削除されうる。これは，以下のような新たな利用ケースを完全に可能にする（プロセッサ負荷，タスクのジッタ，グロスおよびネットのランタイム，期限違反等を測定する，または，例えばガントチャートの形式等でグラフィックトレース情報を表示する何らかのＯＳモニタリングユーティリティにより最適にサポートされる）：
・実験を中断することなく，オンザフライで誤った設定を訂正する。
・制御システム全体の一部を徐々に実行することにより実験を徐々にセットアップし，一方で最終的なリアルタイム挙動を継続的に確立する。
・制御システムの要求に応じて，タスク期間，オフセット，および期限を繰返し調整する。
・タスクを待機フェーズにシフトすることによりプロセッサ負荷を平準化する。
・“トライアル＆エラー”再設定により，安定かつ機能的に的確な挙動のための許容値の範囲を特定する。
・集中的なアプリケーションの演算処理に際して，現時点で重要でない機能性を“オフ”することにより，負荷を平衡化する。
・オンザフライでタスクを生成および起動することにより，制御システムの一部を自発的にトリガする。
・対応するタスクまたはプロセスをマスクまたは抑制することにより，制御システムの一部を停止する。
・プロセスを内部実装からクランク軸同期信号のような実世界入力割込みに，または反対に切替える。
・対応する制御システムの一部を択一的に実行可能および実行不能にすることにより，並列に作動する同一モジュールの多数の実装バリエーションを比較する。

（アーキテクチャ）
動的再設定アプローチを構成する複数のアーキテクチャが考えられうる。一例として，静的に設定可能なOSEK/VDX準拠のリアルタイムＯＳに基づくアプローチが以下に説明される。この主要コンポーネントは，再設定ＡＰＩにより補完され，シミュレーションターゲット上で作動するＲＴ−ＯＳである。

かかるシステムが図１０に示される。図１０では，マイクロコントローラハードウェア９３と，例えば，フラッシュローダ９４ａ，診断９４ｂ，通信およびネットワーク管理９４ｃ，スケジューラ９４ｄおよびハードウェア抽象化層９４ｅを含むプラットホームソフトウェアを伴うＲＴ−ＯＳ９４とが一例として示される。ＲＴ−ＯＳ９４とマイクロコントローラハードウェア９３との間には，インターフェース９５が示される。モジュール９７ａ，９７ｂおよび９７ｃを含むアプリケーションソフトウェア９９は，インターフェース９６によりＲＴ−ＯＳ９４に接続される。通信インターフェース１００を介して，例えば図７のように，ホスト１０１は，ＡＰＩ１０２を用いてターゲット，特にＲＴ−ＯＳに接続される。これは，ＲＴ−ＯＳのＡＰＩまたは代わりの再設定ＡＰＩとなりうる。

（機能）
（リアルタイムＯＳ）
リアルタイムＯＳは，シミュレーションターゲットのリソースを管理し，アプリケーションのリアルタイムスケジューリングを行う。この設定は，制御システムの実行ファイルをシミュレーションターゲットにダウンロードした後に変更されうる。よって，内部ＯＳデータ構造は，ランタイム時に拡張または修正するために，動的に配置され初期化されると想定される。データ構造の実際の実装は，個別のＲＴ−ＯＳに大きく依存する。

ＲＴ−ＯＳは，以下に接続される。
・ハードウェアサービスおよびリソースを用いてシミュレーションターゲットのハードウェア
・複数モジュールからなる制御システムのプログラムコードを構成するアプリケーションソフトウェア，および
・再設定ＡＰＩ

（シミュレーションホスト）
シミュレーションホストは，高速プロトタイピングシステムに対するヒューマン・マシン・インターフェースを構成する。これは，ホスト−ターゲット通信インターフェースを介してシミュレーションターゲットに接続される。

ホストは，おそらくは，何らかのグラフィックユーザインターフェースによりサポートされて，リアルタイムＯＳの設定および再設定を可能にする。

（ホスト−ターゲット通信インターフェース）
ホスト−ターゲット通信インターフェースは，シミュレーションホストをシミュレーションターゲットに接続する。一般に，これは，有線または無線の接続（シリアルインターフェース，Ethernet（登録商標），Bluetooth等）に基づいており，規格化されたまたは独自仕様の通信プロトコル（例えば，ASAP1b^１２，L1¹³）である。これは，少なくとも以下の機能性を備える。
・ホストからシミュレーションターゲットへのシミュレーション実行ファイルのダウンロード
・リアルタイムＯＳの挙動を定義する設定データのダウンロード

さらに，これは，以下の用途の機能性を備えうる。
・例えば，シミュレーションを開始および停止するために，実験を制御する
・ＲＴ−ＯＳの挙動および内部状態をモニタリングおよびトレースする
・信号を測定し，制御システムのパラメータをキャリブレーションする，等

（ＯＳ再設定ＡＰＩ）
ＯＳ再設定ＡＰＩは，シミュレーションターゲット上で作動し，シミュレーション実行ファイル外部からのアクセスを可能にする再設定機能性によってＲＴ−ＯＳを拡張する。再設定ＡＰＩは，ＲＴ−ＯＳをホスト−ターゲット通信インターフェースを介してシミュレーションホストに接続する。

・シミュレーション実験を開始する前，初期のＯＳ設定は，ホストからホスト−ターゲット通信インターフェースおよび再設定ＡＰＩを介してＲＴ−ＯＳにダウンロードされる。
・実験の実行中，ＲＴ−ＯＳは，通常のようにスケジューリングおよびリソース管理を行う。これがなされる方法は，ＯＳ設定によって定義される。
・ＲＴ−ＯＳは，割込み後または実行中のシミュレーション中でさえ再設定されうる。このように，ＯＳ設定は，かなりの遅れを伴うことなく，オンザフライで変更されうる。

本発明の利点および最も重要な特徴は，
１ リアルタイムＯＳの動的再設定は，その実行ファイルを生成しターゲット上にダウンロードした後に，制御システムのソフトウェアのリアルタイム挙動を定義および変更することを可能にする。
２ リアルタイム挙動は，制御システムのソフトウェアのランタイム直前またはランタイム時でさえ再設定されうる。
３ 動的再設定は，ターゲットの外部から行われ，ホスト−ターゲット間の何らかの相互接続を介してなされる。
４ ＯＳ設定時の柔軟性が大幅に増加する。
５ ＯＳ仕様の変更後のターンアラウンドタイムが顕著に低減される。

（代替手段）
（動的に設定可能なＯＳの再設定）
動的に設定可能なＲＴ−ＯＳの用途で，その機能性が既存のＲＴ−ＯＳＡＰＩの一部であると想定されるために，おそらくは再設定ＡＰＩが不要となる。この場合，元のＲＴ−ＯＳＡＰＩは，シミュレーションホストがＲＴ−ＯＳＡＰＩにアクセス可能なように，単にホスト−ターゲット通信インターフェースに接続されるために必要とされる。

従来技術および本発明のシミュレーションシステムのモデル水準での概略ブロック図を示す。 従来技術の静的相互接続の概略図を示す。 本発明に基づく動的相互接続の望ましい実施形態を示す。 図２ｂの動的相互接続を用いた本発明に基づくシミュレーションシステムの望ましい実施形態を示す。 本発明に基づく通信変数を介したリアルタイム状況下での整合性を保った複製の一例を示す。 本発明に基づく相互接続スキームの代替手段の実施形態を示す。 モデルアニメーションおよびモデル内キャリブレーションのアーキテクチャを示す。 ターゲットサーバを伴う本発明のモデルアニメーションおよびモデル内キャリブレーションアプローチの一例を示す。 アプリケーションおよびプラットホームソフトウェアを伴うリアルタイムＯＳの相互作用を記す。 ＲＴ−ＯＳ再設定の前のタスクスケジューリングガントチャートを記す。 ＲＴ−ＯＳ再設定の後のタスクスケジューリングガントチャートを記す。 ＲＴ−ＯＳ再設定用のアーキテクチャを示す。

注釈

１ INCA，Ｌ1，およびDistabは，ETASGmbH（Robert Bosch GmbHの関連子会社）独自仕様の通信プロトコルである。
２ ASAP1b通信プロトコルは，ASAM協会により標準化されている。
３ ETKは，ETAS独自仕様の物理的な相互接続である。
４ ASCETは，ETAS
GmbHの製品群である。
５ MATLAB（登録商標），Simulink（登録商標），およびReal-TimeWorkshop（登録商標）は，The Mathworks,Incの登録商標である。
６ StatemateMAGUNUM^ＴＭは，I-Logix,Incの登録商標である。
７ ＯＳ：OperatingSystem
８ OSEK/VDX：リアルタイムＯＳ用の車両規格
９ ERCOS^ＥＫは，ETASGmbH（Robert Bosch GmbHの関連子会社）の製品である。
１０ OIL：OSEK/VDX実行言語
１１ FIFO：firstin, first out
１２ ASAP1b通信プロトコルは，ASAM協会により標準化されている。
１３ Ｌ1通信プロトコルは，ETASGmbHの独自仕様である。

Claims (15)

1. 開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステムであって，
   前記シミュレーションシステムがホスト−ターゲットアーキテクチャを備え，
   前記制御システムの少なくとも一部を表す前記ターゲットのオペレーティングシステムが，前記ターゲットの前記オペレーティングシステムに専用のアプリケーションプログラミングインターフェースを介して，前記ホストにより再設定されることを特徴とする，シミュレーションシステム。
2. 前記オペレーティングシステムがリアルタイムオペレーティングシステムであることを特徴とする，請求項１に記載のシミュレーションシステム。
3. 前記オペレーティングシステムは，前記ターゲットのソフトウェアの前記リアルタイム挙動が定義または変更されるように，前記ターゲット上に実行可能ソフトウェアをダウンロードした後に再設定されることを特徴とする，請求項２に記載のシミュレーションシステム。
4. 前記オペレーティングシステムの前記アプリケーションプログラミングインターフェースが用いられることを特徴とする，請求項１に記載のシミュレーションシステム。
5. 前記オペレーティングシステムのアプリケーションプログラミングインターフェースの代わりに，第２の再設定可能なアプリケーションプログラミングインターフェースが用いられることを特徴とする，請求項１に記載のシミュレーションシステム。
6. 前記ホストは，少なくとも１つのモデリングツールを含み，前記制御システムの前記ターゲットソフトウェア上で実行されることを特徴とする，請求項１に記載のシミュレーションシステム。
7. 前記モデリングツールを前記ターゲットに接続するターゲットサーバを備えることを特徴とする，請求項６に記載のシミュレーションシステム。
8. 前記ターゲットサーバは，前記ターゲットとの通信に用いられる通信プロトコルのプロトコルドライバを含むことを特徴とする，請求項７に記載のシミュレーションシステム。
9. 対応するメモリおよびインターフェースモジュールを伴う複数のシミュレーションプロセスを備え，モジュールがモジュール間通信のために個別のメモリ域を備えることを特徴とする，請求項１に記載のシミュレーションシステム。
10. 制御システムのシミュレーションモデルを実行することによりシミュレーションが行われ，前記シミュレーションモデルは，前記複数モジュールのうちの１つでそれぞれに実行されている多数のサブモデルを備えることを特徴とする，請求項９に記載のシミュレーションシステム。
11. 少なくとも１または２以上の前記モジュールが個別のメモリ域を介した通信のために動的に再設定可能であることを特徴とする，請求項９に記載のシミュレーションシステム。
12. 開発中の制御システムをコンピュータによりシミュレーションおよび検証するためのシミュレーションシステムのホストであって，
    前記シミュレーションシステムがホスト−ターゲットアーキテクチャを備え，
    前記制御システムの少なくとも一部を表す前記ターゲットのオペレーティングシステムが，前記ターゲットの前記オペレーティングシステムに専用のアプリケーションプログラミングインターフェースを介して，前記ホストにより再設定されることを特徴とする，シミュレーションシステムのホスト。
13. 請求項１に記載のシミュレーションシステムを用いて，開発中の制御システムをシミュレーションおよび検証するためにコンピュータにより実施される方法。
14. コンピュータ上で実行される場合に，請求項１３に記載の方法を実施するに適したプログラムコーディング手段を伴うコンピュータプログラム。
15. コンピュータ読取り可能な媒体と，前記コンピュータ読取り可能な媒体に記録された請求項１３に記載のコンピュータプログラムとを伴うコンピュータプログラム製品。

Images