JPWO2020017264A1 - シミュレーション装置、及びその方法、並びにｅｃｕ装置 - Google Patents

Abstract

簡便な手法によりＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づけることができるシミュレーション装置、及びその方法、並びにＥＣＵ装置を提供する事を目的とする。第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置。

Description

本発明は、実行タイミングを合わせる機能を備えるシミュレーション装置、及びその方法、並びにＥＣＵ装置に係り、例えば自動車の電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）のソフトウェア開発時に開発者が使用するシミュレーション装置、及びその方法、並びにＥＣＵ装置に関する。

ＥＣＵ向けソフトウェアの開発において、開発初期段階でハードウェア試作機が出来ているケースは少ない。このため、最初にパソコンＰＣ上で設計した後、ＰＣ環境（シミュレーション環境）で動作確認を行い、ＰＣ環境で検証したソフトをハードウェア試作機である実ＥＣＵ環境へ移植し、動作確認を行う流れが一般的である。

またハードウェア試作機が出来た後でもソフト開発者に対して割り当てられるハードウェア試作機の数は少ないことがよくあり、例えば、１台のハードウェア試作機を１０人のソフト開発者が共用することもある。

このような場合、ハードウェア試作機である実ＥＣＵ環境とＰＣ環境の両方でソフトウェアＳＷなどの動作確認を行う形になる。

この開発の流れにおいて、パソコンＰＣとＥＣＵのＨＷ（ハードウェア）性能差に起因し、ＰＣ環境と実ＥＣＵ環境でアプリケーションソフトの動作結果に差が出てしまう事が良く発生する。

ＰＣ環境と実ＥＣＵ環境でアプリケーションソフトの実行タイミングに差が出る事により、どちらか片方の環境でのみ発生するような不具合が出てくる。

またＰＣ環境と実ＥＣＵ環境の違いだけではなく、開発で使用するパソコンＰＣのスペックが開発者ごとに異なることが多く、このことに起因して実ＥＣＵと特定のＰＣでのみ発生するような状況も発生する。

ＰＣシミュレータが使用されるソフトウェア開発の上流工程でソフトウェアの品質を高める為には、使用するパソコンＰＣ毎にＰＣシミュレーション環境での処理タイミングを実ＥＣＵ処理タイミングに近づける事が重要となっている。

これらの点に関連して、特許文献１の請求項２には、「シミュレーション開発環境が開発マシンのマイクロプロセッサユニットを実際に使用した時間だけを測定対象にしたクロック割込みのシミュレーションが可能であり、」という記載がある。

特開平５−２８２１６０号公報

特許文献１では、クロック割込みによる処理開始タイミングを合わせることは出来るが、それ以降の処理タイミングについては調整できない為、ＨＷ性能による差が出てしまう。

例えば、マルチタスクオペレーティングシステム上で複数アプリを動作させる場合、タスク間で共有する変数の更新タイミングが、シミュレーション環境と実ＥＣＵ環境で差が出てしまう事がある。この結果として、変数を参照するタイミングが変わる事によりアプリケーションソフトの動作に差が出てしまう事がある。

またＰＣシミュレータでの再現性を高めるために、タイミング調整を取る為の仕組みがあったとしても、開発者が使用するパソコンＰＣ毎に性能（クロック周波数等）の違いがあり、タイミング調整用パラメータはパソコンＰＣ毎に個別調整する必要がある。

然るに、タイミング調整用パラメータを決める為の情報として、ＣＰＵクロック比があるが、外部メモリアクセス性能の違いや、パソコンＰＣ上で動作しているほかプロセスの影響などの要因もあり、固定の計算式のみで有効なパラメータを算出する事は難しい。

そこで本発明では、簡便な手法によりＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づけることができるシミュレーション装置、及びその方法、並びにＥＣＵ装置を提供する事を目的とする。

以上のことから本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置」としたものである。

また本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、第１の計算機におけるアプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機と、アプリケーションソフトを実行したときの処理タイミングを第２の処理タイミングとして得る第２の性能測定機能を備える第２の計算機と、第１の計算機と第２の計算機を接続する通信装置を備えることを特徴とするシミュレーション装置」としたものである。

また本発明においては「アプリケーションソフトを実行したときに第２の処理タイミングを入手するための性能測定機能と、第２の処理タイミングを記憶する測定結果記憶部と、第２の処理タイミングを外部に送信するための通信装置を備えることを特徴とするＥＣＵ装置」としたものである。

また本発明においては「第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングと、第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うことを特徴とするシミュレーション方法」としたものである。

本発明によれば、ＰＣシミュレーション環境での実行タイミングを実ＥＣＵへ近づけることができる。ＰＣ毎にタイミングの調整を行えるため、開発者のＰＣ環境ごとに遅延量を調整することが出来る。

さらに本発明の実施例によれば、開発途中の実ＥＣＵ試作機の台数が少ない状態でも実ＥＣＵでの処理タイミングに近い環境でソフトウェアを検証することができ、より上流工程でのソフトウェアの品質確保に寄与することが出来る。

本発明のシミュレーション装置における実ＥＣＵ環境とＰＣ環境の構成例を示す図。 シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成並びに主な処理機能について示す図。 シミュレーション装置を用いて、ＥＣＵ装置に移植するソフトウェアを作成するまでの生成過程を示す図。 本発明の実施例２に係るアプリ開発第一段階に関わる処理を示す図。 本発明で使用するＣ言語プログラム例を示す図。 遅延パラメータファイルＦｉ３のテーブル設定例を示す図。 実ＥＣＵと、タイミング調整が無い場合と、タイミング調整を実施した場合のシミュレータでの実行タイミング例を示す図。 ＥＣＵの処理速度がパソコンの処理速度よりも早い場合のタイミング例を示す図。 実ＥＣＵのＣＰＵクロック数とシミュレータが動作するパソコンＰＣのクロック数の比率を示す図。 実ＥＣＵで実行した場合の処理タイミングと、ＰＣシミュレータで実行した場合の処理タイミングを示す図。 タスクＡとＢのタスクの優先度の関係を示す図。 マルチタスクにおける割り込み処理の場合におけるタイミング調整の考え方を示す図。 シミュレーション装置を構成するパソコンＰＣ及び実環境機Ｓの遅延量決定、調整機能についての処理の流れについて示す図。 遅延量決定、調整機能についての考え方を示した図。 本発明で使用するＣ言語プログラム例を示す図。 遅延量決定及びタイミング調整のために実行されるパソコンＰＣ、及び実環境機Ｓにおける処理内容を示す概略フローチャート。 ＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果ファイルＦｉ２の構成例を示す図。 タイミング調整前後の時間関係を示す図。 遅延パラメータファイルＦｉ３更新の具体的な処理フローを示す図。 性能比較前の初期状態における遅延パラメータテーブルの一例を示す図。 図２０の初期状態の遅延パラメータテーブルに子関数ごとの遅延量を反映させた遅延パラメータテーブルを示す図。 マルチタスクのコンテキスト切り替えが発生した場合の実行タイミング例を示す図。 各タスクが記憶した開始、終了時刻の一例を示す図。

以下本発明に係るシミュレーション装置について、図面を参照して詳細に説明する。なお、本発明の実施例は多岐にわたることから、実施例１ではシミュレーション装置の特にハードウェア構成を主体に説明し、実施例２から実施例５ではＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延処理を実行することについて説明し、実施例６以降ではパソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することについて説明する。

実施例１ではシミュレーション装置の特にハードウェア構成を主体に説明する。図１は、本発明のシミュレーション装置における実ＥＣＵ環境とＰＣ環境の構成例を表している。

図１の右側には実ＥＣＵ環境を実現する実環境機Ｓ、左側にはＰＣ環境を実現するパソコンＰＣの構成例が示されている。実環境機Ｓと複数のパソコンＰＣ（ＰＣａ、ＰＣｂ・・・ＰＣｎ）は、通信装置１８０を介して外部システム・バス１８１に接続されている。なおパソコンＰＣは基本的に同じ構成、機能のものであるので、以下においてはパソコンＰＣａを代表例として説明する。

実環境機ＳおよびパソコンＰＣは、いずれも計算機システムにより構成されているので、そのハードウェア構成はよく知られているように、システム・バス１０１上に、ＣＰＵ１０２、主記憶装置（ＲＡＭ）１０３、ハードディスクドライブ（ＨＤＤ）１０４あるいはＲＯＭ１０８等を接続して構成されている。またパソコンＰＣには、開発者がシミュレーション操作やシミュレーション結果の検証を実行するためのキーボード１０５、マウス１０６、ディスプレイ１０７が接続されている。

実環境機ＳおよびパソコンＰＣのハードウェア構成は、上記のようであるが、ハードディスクドライブ１０４あるいはＲＯＭ１０８にはここで実現される主要な機能が搭載されている。

まずＰＣ環境を実現するパソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレーション環境で動作するソフトウェアＳｗとして、ＥＣＵアプリケーションソフトＳｗ１と、性能比較ソフトＳｗ２と、ＥＣＵとの通信を行う通信ソフトＳｗ３が格納されている。なおＥＣＵアプリケーションソフトＳｗ１には、遅延注入機能Ｓｗ１１と性能測定機能Ｓｗ１２を備え、性能比較ソフトＳｗ２には測定結果比較・遅延パラメータ設定部Ｓｗ２１、比較結果表示部Ｓｗ２２を備え、通信ソフトＳｗ３には測定結果受信部Ｓｗ３１を備えている。なおＥＣＵアプリケーションソフトＳｗ１は、パソコンＰＣにおけるシミュレーションソフト（ＰＣシミュレーションソフト）を表している。

またＰＣ環境を実現するパソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレーション環境で動作するときに使用する各種のデータについてのデータファイルＦｉとして、ＥＣＵでの測定結果を保存したＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果を保存したＰＣ測定結果ファイルＦｉ２、両測定結果の内容を比較し、決定した遅延パラメータを保存した遅延パラメータファイルＦｉ３が格納されている。

他方、実ＥＣＵ環境を実現する実環境機ＳのＲＯＭ１０８には、ＥＣＵアプリケーションソフトＳｗ４が格納されている。ＥＣＵアプリケーションソフトＳｗ４は、性能測定機能Ｓｗ４１と測定結果送信部Ｓｗ４２を持つ。また実ＥＣＵ環境を実現する実環境機Ｓの主記憶装置（ＲＡＭ）１０３には、実ＥＣＵ環境で動作するときに使用する各種のデータについてのデータファイルＦｉとして、ＥＣＵでの測定結果を保存したＥＣＵ測定結果ファイルＦｉ４が格納されている。

なお、図１で説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はない事を理解されたい。

図１を用いて説明した各種の処理のうち、パソコンＰＣのハードディスクドライブ１０４におけるＥＣＵアプリケーションソフトＳｗ１における遅延注入機能Ｓｗ１１は、ＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延処理を実行することに係るものであり、実施例２から実施例５において説明する。また図１におけるその他の処理機能は、パソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することに係るものであり、実施例６以降において説明する。

本発明の実施例２から実施例５の説明では、シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成、並びに主な処理機能について説明する。またシミュレーション装置を用いて、ＥＣＵ装置に移植するソフトウェアを作成するまでの生成過程について説明する。

まず、シミュレーション装置を構成するパソコンＰＣの特に遅延注入機能Ｓｗ１１についてのハードウェア構成並びに主な処理機能について図２を用いて説明する。

図１で述べたように、図２のシミュレーション装置は、一般的なパソコンＰＣで構成されており、そのハードウェア構成としては、パソコンＰＣのシステム・バス１０１上に、ＣＰＵ１０２、主記憶装置（ＲＡＭ）１０３、ハードディスクドライブ（ＨＤＤ）１０４、キーボード１０５、マウス１０６、ディスプレイ１０７などが接続されている。

図２のシミュレーション装置は、図１の遅延注入機能Ｓｗ１１を具体的に機能展開したものであり、ハードディスクドライブ１０４内に形成される各種機能或は生成物として表すことができる。遅延注入機能Ｓｗ１１は、具体的には、ＥＣＵアプリケーションソフトについてのＥＣＵソースコード１１１、実ＥＣＵ向けの実行ファイルを生成する為のクロスコンパイラ１１２、ＰＣシミュレーション用の実行ファイルを生成する為のコンパイラ１１３、クロスコンパイラ１１２を使用してアプリケーションソフト１１１をビルドする事により生成された実ＥＣＵ用実行ファイル１１４、コンパイラ１１３を使用してアプリケーションソフト１１１をビルドする事により生成されたＰＣシミュレータ用実行ファイル１１５が保持され、あるいは形成されたものとして表現することができる。

図２によれば、ＥＣＵアプリケーションソフトのソースコード１１１からＰＣシミュレータ用実行ファイル１１５を形成する処理フローＦ１と、ＥＣＵアプリケーションソフトのソースコード１１１から実ＥＣＵ用実行ファイル１１４を形成する処理フローＦ２が存在するが、これらの処理フローＦ１、Ｆ２は、図３に示し後述する手順で実行されている。

なおＥＣＵソースコード１１１には、実ＥＣＵとＰＣシミュレータ両方で動作するＥＣＵアプリケーションソフト１２１と、ＰＣシミュレータ環境のみで動作する遅延注入用関数１２２を持つ。

また、パソコンＰＣのハードディスクドライブ１０４には、ＰＣシミュレータ環境のみで使用される遅延情報を保存した遅延パラメータファイルＦｉ３が格納されている。

またＰＣシミュレータ用コンパイラ１１３には、遅延注入用機能呼び出し処理をＥＣＵソフト内にフッキングする為のコンパイルオプション１３１を持つ。ＥＣＵソースコード１１１をコンパイラ１１３でコンパイルオプション１３１を指定してコンパイルすると、ＰＣシミュレータ用実行ファイル１１５内に、遅延注入用実行コード１４１が含まれる。遅延注入用実行コード１４１は、遅延パラメータファイルＦｉ３に記載された遅延量分の遅延処理を実行する機能を持つ。

なお処理フローＦ１でのコンパイル処理により、ＰＣシミュレータ用実行ファイル１１５内にはＥＣＵアプリケーション実行コード１４２と遅延注入用実行コード１４１が生成記憶され、処理フローＦ２でのコンパイル処理により、実ＥＣＵ用実行ファイル１１４内にはＥＣＵアプリケーション実行コード１４３が生成記憶される。

なお、ここで説明する構成と処理は、一実施例として説明するものである、本発明の技術的範囲をこの実施例に限定して解釈する意図はない事を理解されたい。

図３は、シミュレーション装置を用いて、ＥＣＵに移植するソフトウェアを作成するまでの従来における生成過程を示す図である。

図３の（ａ）は、アプリ開発第一段階を表しており、例えばＥＣＵにおけるブレーキ操作についてのＥＣＵアプリケーションソフト１２１が、ＰＣシミュレータ用コンパイラ１１３により変換されて、ＰＣシミュレータ用実行ファイル１１５内にＥＣＵアプリケーション実行コード１４２を生成する。この処理の流れが処理フローＦ１で示されている。

またこの段階では、ＥＣＵアプリケーション実行コード１４２を用いた各種のシミュレーションがパソコンＰＣ内で実行され、その結果が適宜ディスプレイ１０７などに表示されている。開発者Ｍは、ディスプレイ１０７に表示されたシミュレーションの結果を受けてマウス１０６、キーボード１０５などの入力手段を用いてＥＣＵアプリケーションソフト１２１を適宜改変し、最終的にアプリケーションソフト１２１Ａを得る。また最終的にＥＣＵアプリケーション実行ファイルコード１４２Ａ（図示せず）を得る。

図３の（ｂ）は、アプリ開発第二段階を表しており、アプリ開発第一段階で最終的に生成したＥＣＵアプリケーションソフト１２１Ａを、実ＥＣＵ用クロスコンパイラ１１２により変換して、実ＥＣＵ用実行ファイル１１４内にＥＣＵアプリケーション実行コード１４３を生成する。この処理の流れが処理フローＦ２で示されている。

図３の（ｃ）は、ＥＣＵ確認段階を表しており、アプリ開発第二段階において最終的に得られたＥＣＵアプリケーション実行コード１４３をＥＣＵに移植し、実機による各種の検査などを実行する。

図３に示す上記の手順は、シミュレーション装置を用いて、ＥＣＵに移植するソフトウェアを作成するまでの従来における生成過程を示しているが、この場合の問題点がシミュレーション装置を構成する第１の計算機であるパソコンＰＣと、ＥＣＵを構成する第２の計算機との間のＨＷ性能差（ハードウェア性能差）に起因し、パソコンＰＣ環境とＥＣＵ環境でアプリケーションソフトの動作結果に差が出てしまうという事であった。

なお第１の計算機と、第２の計算機との間のＨＷ性能差として、以下の例ではクロック周波数の差を例にとり説明するものとする。なお実施例２ではＥＣＵのクロック周波数ｆｅが１０００Ｈｚ、パソコンＰＣのクロック周波数ｆｐが３０００Ｈｚであり、パソコンＰＣの方がＥＣＵよりも高性能な事例を示している。また実施例３ではＥＣＵの方がパソコンＰＣよりも高性能な事例を示している。

本発明の実施例２は、図３の（ａ）アプリ開発第一段階に関わる処理を改善したものである。図４は、本発明の実施例２に係るアプリ開発第一段階に関わる処理を示している。

図４のアプリ開発第一段階では、図３の（ａ）アプリ開発第一段階にさらに以下の機能や処理が追加されている。これらは、ＥＣＵソースコード１１１に追加された遅延注入用関数１２２、パソコンＰＣ上に作成された遅延パラメータファイルＦｉ３、ＰＣシミュレータ用コンパイラ１１３に追加された関数結合オプション１３１、ＰＣシミュレータ用実行ファイル１１５に追加された遅延注入用実行コード１４１である。

なお図４の構成によれば、コンパイルオプションの指定の有無により実行タイミング調整処理を着脱する構成のものとする事が出来る。

これらの追加された機能は、要するに最終的に形成されるプログラム（ＰＣシミュレータ用実行ファイル１１５に生成されたＥＣＵアプリケーション実行コード１４２）中に、「予め定めたタイミングに予め定めた遅延時間を設定する」ものであり、このため本発明の計算機におけるプログラミング言語はＣ言語、Ｃ＋＋言語、ＪＡＶＡ（登録商標）を採用するのがよい。なお、これらの言語は以下単にＣ言語と略称する。

図５は、本発明で使用するＣ言語プログラム例を示す図である。Ｃ言語プログラムでは、図５に例示するようにＭａｉｎ関数の中でｆｕｎｃ１関数を呼び出し、ｆｕｎｃ１関数終了後にＭａｉｎ関数の残りを実行する単純なプログラムである。なお、Ｍａｉｎ関数の中では、複数のｆｕｎｃ関数を呼び出して処理を行わせることができる。なおＭａｉｎ関数を親関数、ｆｕｎｃ関数を子関数と呼ぶことがある。

図２のＥＣＵソースコード１１１に追加された遅延注入用関数１２２は、Ｃ言語のｆｕｎｃ関数のうち、「予め定めたタイミングに予め定めた遅延時間を設定する」機能を果たすための関数であり、プログラムの先頭位置に遅延時間を設定する目的で使用するのがｐｒｏｌｏｇｕｅ関数であり、プログラムの後尾に遅延時間を設定する目的で使用するのがｅｐｉｌｏｇｕｅ関数である。

なお、ＥＣＵは車両に組み込まれて使用される、いわゆる制御用計算機である。このため例えばシングルタスクのＥＣＵは１０（ｍｓ）周期で起動され、起動の都度Ｍａｉｎ関数に記述された一連の処理をこの期間内で余裕をもって処理完了するように運用される。従って、シミュレーション装置であるパソコンＰＣも同様に制御用計算機として取り扱うことを前提として、構成運用されている。なおマルチタスクのＥＣＵの場合には、例えば５（ｍｓ）周期で起動される別体系の制御周期を有し、適宜の優先順位で運用されるものとされる。

図６には、図２で規定した遅延パラメータファイルＦｉ３の本実施例でのテーブル設定例を記している。ここでは、Ｍａｉｎ関数、ｆｕｎｃ１関数、Ｄｅｆａｕｌｔについて、遅延時間設定位置の区別、呼び出し元関数名、遅延量、備考としての要件などを記述している。図６のテーブルは、遅延量の設定を終えた後の状態を表している。本テーブルで設定されている遅延量Δｔ４〜Δｔ７については、図７のタイミング例で図示する。

例えば、Ｍａｉｎ関数についての行２０１では、Ｍａｉｎ関数のＰｒｏｌｏｇｕｅ関数（以下この関数による処理をプロローグ処理という）で実行する遅延量としてΔｔ４が設定されている。

ｆｕｎｃ１関数についての行２０２では、ｆｕｎｃ１関数のＥｐｉｌｏｇｕｅ関数（以下この関数による処理をエピローグ処理という）における遅延量としてΔｔ７を設定している。 なおＤｅｆａｕｌｔとは、Ｍａｉｎ関数あるいはｆｕｎｃ関数などで定義していない部分について標準的に設定を行う事を意味している。本例では、記載されていない関数のプロローグ処理及びエピローグ処理では実行する遅延量として０（遅延処理を行わない）としている。

図６に記載の調整グループ２０３については、実施例７で後述する。

図７は、実ＥＣＵでの実行タイミングと、タイミング調整が無い場合のＰＣシミュレータでの実行タイミングと、タイミング調整を実施した場合のＰＣシミュレータでの実行タイミング例を記している。

まず図７左側のＥＣＵでの実行タイミングについて説明する。先にも述べたように、このタイミング処理は、ＥＣＵの１０（ｍｓ）の制御周期、かつ１０００Ｈｚのクロック周波数の下で実行された場合のタイミングである。ここでは時刻ｔ０において、１０（ｍｓ）の制御周期が開始されたものとする。

この例では、プログラムはＭａｉｎ関数の前段処理にΔｔＥ１時間、ｆｕｎｃ１関数の処理にΔｔＥ２時間、Ｍａｉｎ関数の後段処理にΔｔＥ３時間を要し、かつこの合計時間はＥＣＵの１０（ｍｓ）の制御周期内で十分な余裕をもって完了される。なお、Ｍａｉｎ関数の前段処理完了時刻をｔ１、ｆｕｎｃ１関数の処理完了時刻をｔ２、Ｍａｉｎ関数の後段処理完了時刻をｔ３として表記している。

これに対し、パソコンＰＣを用いたシミュレーション装置の内部では、ＥＣＵでの実行タイミングと同じタイミングを実現できるものであることが望まれる。

この点に関し、図３で示した時間調整を実行しない従来方式（図７中央）によれば、実行開始時点は、実ＥＣＵもＰＣシミュレーション環境でも同じ時刻ｔ０であるとしているが、パソコンＰＣのクロック周波数が３０００Ｈｚであることもあり、短時間で一連の処理を完了してしまう。具体的には、Ｍａｉｎ関数の前段処理にΔｔ１時間、ｆｕｎｃ１関数の処理にΔｔ２時間、Ｍａｉｎ関数の後段処理にΔｔ３時間を要しているが、これらの時間は実ＥＣＵの各時間よりも十分に早いものであるために、実行タイミングが実ＥＣＵのそれとはまったく異なるものになっている。本発明では、実ＥＣＵとＰＣシミュレーション環境での実行時間の差から図６で説明した遅延パラメータファイルＦｉ３の遅延量を計算して設定する。遅延量の計算は実施例６以降で説明する。

本発明では、関数の前後に適宜遅延時間を設定することで、図７左側のＥＣＵでの実行タイミングに近いものを実現する。なお図７右側のタイミング調整有の事例において、他の場合と同様に制御周期の開始時点はｔ０である。

このとき、プログラムはＭａｉｎ関数から開始する。最初に図６の遅延パラメータファイルＦｉ３を参照して、行２０１のＭａｉｎ関数のプロローグ処理を実行する。Ｍａｉｎ関数のプロローグ処理における遅延量がΔｔ４の為、遅延時間Δｔ４の経過後にｆｕｎｃ１関数の処理を実行する。ｍａｉｎ関数を実行していくと、Δｔ１時間後にｆｕｎｃ１関数が呼ばれる。Ｍａｉｎ関数プロローグ処理の遅延量が適切であれば、ｆｕｎｃ１関数呼び出しのタイミングが実ＥＣＵに近づく。

プログラムは次に、図６の遅延パラメータファイルＦｉ３を参照して、行２０３のｆｕｎｃ１関数のプロローグ処理を実行するが、ここでは遅延量としてΔｔ５が設定されているので、遅延時間Δｔ５の経過後にｆｕｎｃ１関数の処理を実行する。

ｆｕｎｃ１関数の実行時間は、タイミング調整なしのケースと同じΔｔ２である。図６の遅延パラメータファイルＦｉ３での設定により、ｆｕｎｃ１関数のエピローグ調整処理として遅延量Δｔ６が設定されており、Δｔ６分の遅延処理を実行する事により、ｍａｉｎ関数の後段処理開始時刻を、ＥＣＵにおけるｍａｉｎ関数の処理開始時刻ｔ２に合わせることができる。

同様に図６の遅延パラメータファイルＦｉ３での設定により、ｍａｉｎ関数のエピローグ調整処理として遅延量Δｔ７係数３が設定されており、Δｔ７分の遅延処理を実行することにより、ｍａｉｎ関数の後段処理終了時刻を、ＥＣＵにおけるｍａｉｎ関数の後段処理終了時刻ｔ３に合わせることができる。

なお、各関数での遅延時間の設定に当たり、これを絶対時刻（例えば制御周期の開始時刻）からの時間で設定するか、前回イベント（例えば各関数の開始、終了時刻）の発生時刻からの時間で設定するかは適宜採用可能である。

このように本発明では、ＰＣシミュレーション環境においてのみ動作する遅延処理を実装、追加できる仕組みを実現する事により、ＰＣシミュレーション環境での処理タイミングを実ＥＣＵに使づけることができる。

また遅延処理を入れる場所は「関数の開始時に呼び出されるプロローグ処理」または「関数の終了時に呼び出されるエピローグ処理」とする。どちらか一方で遅延処理を実装する事も出来るし、両方で遅延処理を入れることも可能である。

さらに遅延注入関数の呼び出し処理はコンパイルオプションの追加で実施することができる。ＧＣＣの”−ｆｉｎｓｔｒｕｍｅｎｔ−ｆｕｎｃｔｉｏｎｓ”オプションのような、プロローグとエピローグ時に動作する関数を指定できる機能を使用するのがよい。ＰＣシミュレーション環境でのテスト用にアプリケーションソフト内でテストコードを呼び出す処理を追加する事は不要である。

以上述べたように本発明は、アプリケーションソフトを実行コードに変換して検証し、検証後の実行コードを他の計算機装置に移植するためのシミュレーション装置であって、アプリケーションのソースコードの関数単位で関数開始時、または終了時に時刻調整処理を行い、前記他の計算機装置における実行タイミングを調整することを特徴とするシミュレーション装置としたものである。

実施例２においては、ＥＣＵの処理速度がパソコンの処理速度よりも遅いことを前提にして、各関数の前或は後に遅延時間を設定することで、ＥＣＵとの間のタイミングを合致させたものである。つまり時刻調整処理として遅延処理を行ったものである。

これに対しＥＣＵの処理速度がパソコンの処理速度よりも早い場合がある。図８はＥＣＵの処理速度がパソコンの処理速度よりも早い場合のタイミング例を示す図である。この場合における対応を示したものであり、例えばＭａｉｎ関数の処理にＥＣＵがΔｔＥ１かかるところ、パソコンではそれ以上の時間を要してしまうことが想定される。この場合には、パソコンでのＭａｉｎ関数の処理に要した時間に適宜の係数を乗じてＥＣＵにおける処理時間ΔｔＥ１にすべく、調整するのがよい。これは時刻調整処理として時間短縮化処理を行ったものである。

実施例４もまた、ＥＣＵの処理速度がパソコンＰＣの処理速度よりも早い場合の対応策を想定している。

実施例４について、図９、及び図１０を使用し、シミュレーション速度を実ＥＣＵ環境よりも下げて実行する場合の例を説明する。実ＥＣＵとシミュレータが動作するパソコンＰＣを比較し、実ＥＣＵの方が高速な場合のタイミング調整機能を適用した場合の実施例を説明する。

図５に記したｍａｉｎ関数を周期的に実行する実施例で説明する。実ＥＣＵのＣＰＵクロック数とシミュレータが動作するパソコンＰＣのクロック数の比率を図９に記す。本例は、実ＥＣＵの方がパソコンＰＣよりも２倍性能がよい環境を例にしている。

図１０に、実ＥＣＵで実行した場合の処理タイミングと、ＰＣシミュレータで実行した場合の処理タイミングを記す。

周期処理タイマイベント６０１、６０２が発生し、ｍａｉｎ関数を開始することで周期処理を開始する。Ｍａｉｎ関数の中からｆｕｎｃ１関数がコールされる（６０３、６０４）。Ｆｕｎｃ１関数実行後にｍａｉｎ関数へ戻り、ｍａｉｎ関数終了時点で周期処理が完了する（６０５、６０６）。次の周期処理タイマイベント発行（６０７、６０８）を受け、次回の周期処理がｍａｉｎ関数から開始されるが、本実施例の場合、ＰＣシミュレータ環境では、ＣＰＵ性能が低いことに起因して、前回分の周期処理が終わっていないことが、６０６、６０８のタイミングが入れ替わっていることから確認できる。

ＰＣシミュレータ環境では、等倍速で実行した場合に、ＥＣＵと同じタイミングで処理することが出来ないため、ＣＰＵ比率を元に、１／２倍速することによりＰＣシミュレーション環境でのタイマイベントの発生間隔を２倍にすることにより、ＰＣシミュレーション環境での処理タイミングを実ＥＣＵに近い形で実行する事が可能となる。

図１０の右側に、ＰＣシミュレーション環境で１／２倍速実行したときの処理タイミングを記す。タイマイベントの発生（６０９）、ｆｕｎｃ１関数の実行開始（６１０）、ｍａｉｎ関数の終了（６１１）は、ＰＣシミュレーション環境での等倍速再生時の実行タイミングと変わらないが、次の周期処理タイマイベント発生タイミング（６１２）が等倍速再生時よりも２倍後になることにより、ＰＣシミュレーション環境での周期処理を周期内に収めることが出来ている。なお、関数のＰＣでの実行時間がＥＣＵでの実行時間の２倍より短い場合の、プロローグ・エピローグでの補正方法は、実施例１と同様である。

タイマイベントを発生させる周期の変更は、プログラム初期化処理などで実行される関数のプロローグ処理またはエピローグ処理において実施する。

本実施例のバリエーションとして、ＰＣでの実時間でなく、仮想的な時刻を備えて、プロローグ・エピローグにおいて、仮想的な時刻をＥＣＵにおいてそこに到達する時刻に補正する方式も可能である。この方式では、待ちを挿入する代わりに仮想的な時刻の補正行うため、シミュレーション時間を削減することが出来る。

実施例２から実施例４においては、１つのタスクのみが一つのＣＰＵ上で動作するプログラム（いわゆるシングルタスク）に対し、タイミング調整機能を適用した場合の実施例を説明した。これに対し、マルチタスク方式のＥＣＵでは、複数のタスクＡ、Ｂが一つのＣＰＵ上で動作するプログラムに対して、タイミング調整機能を適用する必要がある。

係るマルチタスクの方式では、一方のタスク実行中に優先度の高い他のタスクの処理要求が入り、前者を中断して後者の処理を行い、その処理終了後に再度前者のタスクの残余部分を実行するといった切替処理が発生する。

図１１は、タスクＡとＢのタスクの優先度の関係を示している。タスクＡは例えば１０（ｍｓ）の制御周期で起動され、タスクＢは例えば５（ｍｓ）の制御周期で起動されるものであり、タスクＢの優先度が高くされた事例を示している。

図１２は、マルチタスクにおける割り込み処理の場合におけるタイミング調整の考え方を示している。図１２において左側は、ＥＣＵでの実処理を示しており、タスクＡとタスクＢは異なる制御周期の下で実行されている。ここではタスクＡの周期処理タイマ起動時刻がｔ０Ａ１、ｔ０Ａ２で、またタスクＢの周期処理タイマ起動時刻がｔ０Ｂで示されている。またこの例では時刻ｔ０Ａ１、ｔ０Ａ２間がタスクＡの制御周期であり、タスクＢの割り込む処理により、タスクＡの再開時刻がｔ１、タスクＡの終了時刻がｔ２になったことを表している。

この図１２の例では、タスクＡが時刻ｔ０Ａ１のタイマイベントを契機に処理を開始する。その後タスクＡの処理実行中の時刻ｔ０ＢにタスクＢのタイマイベントが発行された。このとき、優先度の関係からタスクＡの実行を中断し、タスクＢの処理を開始する事となる。

本例のイベント発生タイミングによれば、実ＥＣＵではタスクＡ実行処理がタスクＢ開始までに終了せず、タスクＢへの切替が発生している。タスクＢの処理終了後に、タスクＡの実行が再開されている。

一方、図１２中央の従来における処理によれば、ＥＣＵよりも高速なＰＣシミュレータ環境であることから、タスクＡの実行がタスクＢ開始までに終了してしまうため、タスク切替は発生していない。つまり従来方式では、マルチタスクにおけるタスク切り替えを再現することができない。この結果として、ＰＣシミュレータ環境では１周期で実行でき、正しく動作していても、実ＥＣＵ環境に移植して動作確認をした場合に、１周期の期間内に処理が完了しないという問題などもよく発生する。

ＰＣシミュレーション環境で関数のプロローグ、エピローグ処理でタイミング調整を入れた場合の本発明の動作を図１２の右側に記述している。この記述例によれば、適宜の遅延時間を加味することで、タスクＡの前段処理部分を形成することが可能であり、同様にタスクＢ、タスクＡの後段処理部分を形成することができ、割り込み処理を実現することができる。

このように、実施例２と同様に関数単位で細かくタイミング調整処理が入る為、実ＥＣＵとＰＣシミュレータで同じタイミングでタスクＡ及びタスクＢのタイマイベントが発生した場合に、ＰＣシミュレータ上でもタスクの切替が発生する事となる。つまり、異なる制御周期で動作するマルチタスク方式の場合にシミュレーション装置は、複数のタスクの夫々について時刻調整処理を行い、割り込み処理を再現することができる。

なおマルチタスク方式では、タイミングを調整する為に記憶する実行時間はタスクごとに管理し、タスクが切り替わった後のタイミング調整処理でリソースを奪われたタスクの実行時間のカウントアップを止める処理を実行するのがよい。

本例ではタスクＢの周期処理開始時のプロローグ関数でタスクＡの実行を止めることになる。タスクＢ開始時のプロローグ関数でタスクＡの処理時間カウントを止め、タスクＢの処理終了時のエピローグ関数内でタスクＡの実行時間カウントアップを再開する。その後タイミング調整タイミングが来た時に、タスクＢにリソースを奪われる前と復帰後の実行時間からタイミング調整時間を計算して、タイミング調整を行う。

実施例６以降では、パソコンＰＣ毎にＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延量を決定し、ＰＣシミュレーション環境での実行時に所定の位置で遅延処理を実行しながらタイミング調整することについて説明する。

図１３は、シミュレーション装置を構成するパソコンＰＣ及び実環境機Ｓの遅延量決定、タイミング調整機能についての処理の流れについて示す図である。

図１３によれば、実環境機Ｓ側において実ＥＣＵ環境におけるハードウェア試作機の性能試験が実行される。これは実ＥＣＵ環境を実現する実環境機ＳのＲＯＭ１０８内のＥＣＵアプリケーションソフトＳｗ４において、性能測定機能Ｓｗ４１が作動してＲＡＭ１０３内にＥＣＵシミュレータでの測定結果を得、ＥＣＵ測定結果ファイルＦｉ４として保存したものである。

なおその後、ＥＣＵ測定結果ファイルＦｉ４は、ＥＣＵアプリケーションソフトＳｗ４内の測定結果送信部Ｓｗ４２が作動して、パソコンＰＣ内の通信ソフトである測定結果受信部Ｓｗ３１を介してパソコンＰＣ内にＥＣＵ測定結果ファイルＦｉ１として保存される。

図１４は、遅延量決定、タイミング調整機能についての考え方を示した図であり、これと図１３の処理を対比して示すと、実環境機Ｓにおける上記処理は、図１４の左側のＥＣＵにおいてハードウェア試作機の性能試験の結果（ＥＣＵ測定結果ファイルＦｉ１またはＦｉ４）として、アプリケーションソフト（実ＥＣＵ）の開始時刻ｔｓＥと終了時刻ｔｅＥを測定したものである。

他方、パソコンＰＣ側においてＰＣ環境におけるシミュレータの性能試験が実行される。これはシミュレータを実現するパソコンＰＣのハードディスクドライブ１０４内のＥＣＵアプリケーションソフトＳｗ１について、性能測定機能Ｓｗ１２が作動してハードディスクドライブ１０４内にシミュレータでの測定結果を得、ＰＣ測定結果ファイルＦｉ２として保存したものである。

パソコンＰＣにおける上記処理は、図１４の中央のパソコンＰＣ（調整なし）においてシミュレータの性能試験の結果（ＰＣ測定結果ファイルＦｉ２）として、シミュレーション開始時刻ｔｓＰと終了時刻ｔｅＰを測定したものである。なお図１４においては、説明の都合上夫々の開始時刻ｔｓＥ、ｔｓＰを同一時刻上に表示している。またこの状態では、本発明による遅延処理に基づくタイミング調整は行われていないものである。

図１３に戻り、次に性能比較ソフトＳＷ２内の測定結果比較・遅延パラメータ設定部Ｓｗ２１が作動し、ＥＣＵ測定結果ファイルＦｉ１とＰＣ測定結果ファイルＦｉ２についての比較検証を実施する。図１４に示すように、測定結果比較・遅延パラメータ設定部Ｓｗ２１は、測定結果の差分を元に調整時間を算出する。図示の例では、開始時刻ｔｓＥ、ｔｓＰと、終了時刻ｔｅＥ、ｔｅＰの時間差分が比較検証され、この結果が遅延パラメータファイルＦｉ３に保存される。

その後、保存した遅延パラメータファイルＦｉ３を使用してパソコンＰＣ上でシミュレータの性能試験を再度実行する。これによりＰＣ測定結果ファイルＦｉ２が更新される。

性能比較ソフトＳＷ２内の測定結果比較・遅延パラメータ設定部Ｓｗ２１が作動し、ＥＣＵ測定結果ファイルＦｉ１とＰＣ測定結果ファイルＦｉ２についての比較検証を実施する。測定結果の差分を元に調整時間が再算出され、より実機に近い動作をするための遅延パラメータファイルＦｉ３が作成される。

タイミング調整後のシミュレータは、図１３の例ではＰＣ測定結果ファイルＦｉ２に反映され、保存されることを示しているが、適宜の場所に保存可能である。なお上記タイミング調整の手順は、測定結果比較・遅延パラメータ設定部Ｓｗ２１により自動実行されてもよいし、比較結果表示部ＳＷ２２を介してディスプレイ１０７に表示し、開発者の判断により具体的なタイミング調整内容が決定され、反映されてもよい。

図１４の右側にはタイミング調整後のＰＣシミュレータにおける開始時刻と、終了時刻の例を示している。この例では、実環境機ＳにおけるＥＣＵ実測時間帯（開始時刻ｔｓＥ、終了時刻ｔｅＥ）に対して、パソコンＰＣは処理命令を受け付けた時刻ｔｓＥから時間ｔｓ０遅らせてパソコン処理の開始時刻とし、パソコンＰＣはその終了時刻から時間ｔｅ０経過をもって、実環境機ＳにおけるＥＣＵ実測時間帯の終了時刻ｔｅＥと判断する。つまり、開始前時間ｔｓ０と終了後時間ｔｅ０を設定することで、ＰＣシミュレータにおける時刻を実環境機ＳにおけるＥＣＵの時刻に近づけたものである。

以上の流れを図１４に整理すると、以下のようである。まず実ＥＣＵとパソコンＰＣでＥＣＵアプリケーションソフトＳＷ１、ＳＷ４を実行し、測定ポイント（関数の開始、終了）で時間を記録する。実ＥＣＵでの測定タイミングを図１４の左側に、ＰＣシミュレータでの実行タイミングを図１４の中央に記す。パソコンＰＣ上の性能比較ソフトＳＷ２にて、ＥＣＵでの測定結果とパソコンＰＣでの測定結果を比較し、性能差を埋めるための遅延量を計算し、遅延パラメータファイルＦｉ３に遅延量を格納する。

次にＰＣシミュレータを実行する際は、更新された遅延パラメータ情報を読み込み、関数の開始時と終了時に遅延処理を実行したうえで、ＥＣＵアプリケーションソフトＳＷ１を実行する。遅延処理を実行した場合の処理タイミングを図１４の右側に記す。ＥＣＵでの処理タイミング（図１４の左側）とＰＣシミュレータでの実行時間が近づいていることが分かる。

以上の実施例６において、ＥＣＵ測定結果ファイルＦｉ１には、実ＥＣＵで測定した実行時間、タイミングが記憶されている。ここでＥＣＵ測定結果ファイルＦｉ１に記憶された実行時間、タイミングは、ＰＣ測定結果ファイルＦｉ２に記憶された実行時間、タイミングを合致させるための目標データと言えるものである。実施例６では実環境機Ｓにおいて目標データを計測してから、パソコンＰＣ側での計測、並びに比較を行うという手順を示しているが、目標データが予め得られ、ＥＣＵ測定結果ファイルＦｉ１にデータ確保されているのであれば、実環境機Ｓでの計測を毎回実行する必要がないことは言うまでもない。

また上記実施例では、パソコンＰＣの方が実環境機Ｓよりも処理が速い、従ってタイミング調整処理は遅延時間の処理であることを前提として述べているが、実施例３などで述べたように、これはパソコンＰＣの方が実環境機Ｓよりも処理が遅い場合であっても対応可能である。これら両者を含む意味合いでは、遅延処理とは、タイミング調整処理というのが適切である。本発明は広い意味ではタイミング調整を行ったものである。

なお本発明におけるタイミング調整は、必ずしもＥＣＵに完全合致させることを意図してはいない。例えば９０％程度合致させることができれば、シミュレーション上の大きな不利益を生じるものではないといえる。

また本発明の場合に実環境機Ｓは例えばＥＣＵであり、ＥＣＵはその内部にアプリケーションソフト実行時にそのタイミングを計測する性能測定機能を備えており、かつ測定結果を記憶するＥＣＵ測定結果ファイルを保持していることが本発明の特徴である。

実施例７では、図１５〜図２１を使用し、シングルタスクで動作するプログラムに対し、タイミング調整機能を適用した場合の具体的な処理例を説明する。

図１５は、図５に例示したと同じ本発明で使用するＣ言語プログラム例を示す図である。Ｃ言語の詳細説明は割愛するが、図１５に記載するＣ言語プログラムは、１０ｍｓ周期で処理を行うＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の中で、小さい処理単位を実行する３組のｆｕｎｃ関数としてｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）を実行する単純なプログラムである。これにより、Ｍａｉｎ関数１７１で規定する制御周期である１０ｍｓ内で、ｅｅｐｒｏｍからのｒｅａｄ処理、ｎｗへのｓｅｎｄ処理、ｅｅｐｒｏｍへのｗｒｉｔｅ処理が実行される。なお、Ｃ言語プログラムは、その処理開始時刻、終了時刻を記憶する機能を有している。

本発明の実施例におけるパソコンＰＣ、及び実環境機Ｓにおける処理は、上記したＣ言語プログラムにより実行される。図１６は、遅延量決定及びタイミング調整のために実行されるパソコンＰＣ、及び実環境機Ｓにおける処理内容を示す概略フローチャートである。

図１６の右側にはパソコンＰＣにおける処理内容、図１６の左側には実環境機Ｓにおける処理内容を例示している。

図１６の処理フローでは、最初に実ＥＣＵ側の処理ステップＳ１４１において実行時間計測を行う。プログラム内に記載されている性能測定コードを実行する事により、処理ステップＳ１４２において実行タイミングを記録する。処理ステップＳ１４３において実ＥＣＵで記録した実行タイミングを実ＥＣＵの測定結果送信部ＳＷ４２から同一ネットワーク上につながっているパソコンＰＣ側へ送信する。パソコンＰＣ側では、受信した測定結果をＥＣＵ測定結果ファイルＦｉ１として保存する。

次にパソコン側では、処理ステップＳ１４４においてＰＣシミュレーション環境でプログラムを実行し、実行タイミングを記録する。パソコンＰＣ内に存在する遅延パラメータファイルＦｉ３の設定値を使用して、プログラム内に記載されている性能測定コードを実行する事により、実行タイミングを記録する。また処理ステップＳ１４５においてＰＣシミュレーション環境で記録した実行タイミングをＰＣ測定結果ファイルＦｉ２に保存する。

図１７は、上記処理により作成されたＥＣＵ測定結果ファイルＦｉ１、ＰＣ測定結果ファイルＦｉ２に形成されるデータ構成例を示している。これらのファイルは同一形式で作成されており、ＥＣＵとパソコンＰＣで記録する情報は同じである。

図１７のファイルＦｉ１、Ｆｉ２の横軸項目としては、時間（３０１、３０５）、動作タスク（３０２、３０６）、関数名（３０３、３０７）、測定タイミング（開始・終了）（３０４、３０８）の４つの情報を記録する。Ｃ言語プログラムによる測定対象の関数の開始部と終了部に存在する時刻計測コードを使用して、実行時間と動作タスクを記録している。本実施例ではシングルタスクの例を示しており、タスク３０２、３０６は一つなので、すべて同じタスクＡである。

このＥＣＵ測定結果ファイルＦｉ１によれば、タスクＡについてＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の開始時刻がｔ０、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の開始時刻がｔ２、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の終了時刻がｔ６、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の開始時刻がｔ９、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の終了時刻がｔ１１、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の開始時刻がｔ１２、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の終了時刻がｔ１３、Ｍａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の終了時刻がｔ１４であり、上記順番にてデータ生成されたことを表している。

同様にＰＣ測定結果ファイルＦｉ２によれば、タスクＡについてＭａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の開始時刻がｔ０、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の開始時刻がｔ１、ｆｕｎｃ１関数１７２（ｅｅｐｒｏｍ＿ｒｅａｄ）の終了時刻がｔ３、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の開始時刻がｔ４、ｆｕｎｃ２関数１７３（ｎｗ＿ｓｅｎｄ）の終了時刻がｔ５、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の開始時刻がｔ７、ｆｕｎｃ３関数１７４（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）の終了時刻がｔ８、Ｍａｉｎ関数１７１（１０ｍｓ＿ｆｕｎｃ）の終了時刻がｔ１０であり、上記順番にてデータ生成されたことを表している。

図１８は、タイミング調整前後の時間関係を示す図である。図１８の左側の２列には、図１７の時間関係を計測したときの状況が示されている。ＥＣＵについてみると、親関数１７１が規定する１０ｍｓの中で、子関数１７２、１７３、１７４が順次実行されており、各開始、終了の時刻が左側縦軸に記載されている。またパソコンＰＣについても親関数１７１の中で、子関数１７２、１７３、１７４が順次実行されているが、各開始、終了の時刻が記載されているように、実環境機Ｓに比較して高性能、高速のパソコンＰＣの場合には、親関数１７１が規定する１０ｍｓの時間経過前に一連の子関数の処理を完了してしまっている。

ＥＣＵとパソコンＰＣの測定結果がそろった後で、性能比較ソフトＳＷ２を使用して測定結果の比較を行い、ＰＣシミュレーション環境で注入する遅延量を決定し、遅延パラメータファイルＦｉ３を更新する。この間の処理である遅延パラメータファイルＦｉ３更新の具体的な処理フローを図１９に示している。

図１９の処理フローの最初の処理である処理ステップＳ１５１では、遅延パラメータファイルＦｉ３から遅延量を取得し、処理ステップＳ１５２においてＰＣシミュレーション環境で遅延パラメータファイルＦｉ３を使用した時刻測定を実施し、処理ステップＳ１５３において実行結果をＰＣ測定結果ファイルＦｉ２へ格納する。この間の処理フローは図１６に記載の内容のとおりである。なお、上記一連の処理は遅延パラメータを変更しながら複数回繰り返し実行されるので、処理ステップＳ１６０において実行回数を更新しながら繰り返し回数をカウントする。

処理ステップＳ１５４ではＥＣＵ測定結果とＰＣ測定結果を比較し、性能差を算出するが、この具体的な処理内容について説明する。この場合に、実行時間を比較したいＣ言語プログラムによる関数（Ｍａｉｎ関数と、複数のＦｕｎｃ関数）は複数あり、それぞれの関数間で呼び出し関係があることから、性能比較、処理の小さいグループ（他から呼び出されない関数）から実施していく。

図２０は、性能比較前の初期状態における遅延パラメータテーブルの一例を示している。この図では、横軸項目として関数名、タスク名、呼び出し元関数名、調整グループ１８１、開始、終了の区別、遅延量、備考の欄を設けている。関数名は図１５の例で言えば、親関数であるＭａｉｎ関数１７１、子関数であるｆｕｎｃ関数１７２、１７３、１７４であり、開始、終了の区別ごとに行わけして記載している。呼び出し元関数名は、子関数からみたときの親関数を記述しており、性能比較前の初期状態であるため遅延量の欄は０に設定されている。またこの表では、親子の関係毎に調整グループ１８１が設定されており、親関数側に調整グループ「２」が設定され、子関数側に調整グループ「１」が設定されている。

処理ステップＳ１５４における調整の順番は、図２０の遅延パラメータテーブルに記載の調整グループ１８１の小さいものから順に実施していく。本実施例では一番小さい関数として、調整グループ「１」にランク付けされたｆｕｎｃ関数１７２、１７３、１７４である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数が先行して選択され、この順序で実行されていく。

図１７、図１８に例示した時間関係で説明すると、実ＥＣＵでの（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の、開始、終了の実行時間はそれぞれ、（ｔ６−ｔ２）、（ｔ１１−ｔ９）、（ｔ１３−ｔ１２）であり、ＰＣシミュレーション環境での実行時間はそれぞれ（ｔ３−ｔ１）、（ｔ５−ｔ４）、（ｔ８−ｔ７）である。

図１９の処理フローの処理ステップＳ１５５では、最初に子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）について、実ＥＣＵとＰＣシミュレーション環境での実行時間の差が閾値よりも大きいかどうかを判定し、閾値よりも大きい場合、処理ステップＳ１５６に移動してＰＣシミュレーション環境で指定時間分の遅延処理を実行するための遅延量計算処理を行う。子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）の場合、実行時間の差は（（ｔ６−ｔ２）-（ｔ３−ｔ１））として算出される。

処理ステップＳ１５７では、関数ごとに遅延量を更新する。最初に子関数（ｅｅｐｒｏｍ＿ｒｅａｄ）について遅延量を更新する。ここではＰＣシミュレーション環境で実行時間の差分分だけ、遅延処理を入れるものとし、これにより実ＥＣＵでの処理時間に近づけられる。遅延量調整は、関数開始時と、関数終了時の２か所で入れるため、実行時間の差を２分割した量が遅延量として遅延パラメータファイルＦｉ３に書き込まれる。

なお、その後の繰り返し処理により求められる（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の実行時間の差はそれぞれ、（（ｔ１１−ｔ９）-（ｔ５−ｔ４））、（（ｔ１３−ｔ１２）-（ｔ８−ｔ７））である。これらに対しても順次処理ステップＳ１５６、処理ステップＳ１５７の処理が実行され、子関数ごとの遅延量が定められていく。

図２１は、図２０の初期状態の遅延パラメータテーブルに子関数ごとの遅延量を反映させた第一段階（ｓｔｅｐ１）での遅延パラメータテーブルを示している。従ってここには、子関数である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の遅延量の更新データが反映されている。１８２〜１８７の６か所に先ほど計算した遅延量が書き込まれている。

なお遅延処理の例としては、タスクをスリープさせるのではなく、遅延させる時間分無駄な演算や、無駄なｗｈｉｌｅループの実行などをする処理になる。

次に図１９の処理ステップＳ１５８では、子関数である（ｅｅｐｒｏｍ＿ｒｅａｄ）、（ｎｗ＿ｓｅｎｄ）、（ｅｅｐｒｏｍ＿ｗｒｉｔｅ）関数の調整が終わると、タイミング未調整の関数があるかどうかの判定を行う。

子関数調整終了段階におけるシミュレータ処理の時間関係を仮に図示すると、図１８の右から２番目の「Ｓｔｅｐ１」のようになっている。ＥＣＵとの関係では、子関数通しは概ね時間関係が合致した状況になっている。子関数調整終了段階では、全体としては４３１に示す時間長だけＥＣＵの実行時間に近づいているが、未だ時間長４３２の部分で、時間が合致していない。

次の第二段階（ｓｔｅｐ２）では、図２０の遅延パラメータテーブルに記載の調整グループ「２」に記述された関数（前述の子関数を呼び出している親関数）である（１０ｍｓ＿ｆｕｎｃ）関数についての、実行タイミング調整を行う。親関数のタイミング調整処理は、図１９の処理ステップＳ１５８において子関数の全数完了を確認し、処理ステップＳ１５９で実施回数を０に初期化した後に開始する。親関数のタイミング調整処理は、子関数の場合と同様に処理ステップＳ１５１、Ｓ１５２、Ｓ１５３、Ｓ１６０、Ｓ１５４、Ｓ１５５、Ｓ１６１、Ｓ１５６、Ｓ１５７を順次、必要回数だけ繰り返し実行することで達成される。

図１９の処理ステップＳ１５１の処理から再度実行し、実ＥＣＵとの性能差を再度測定したときの実行タイミングは、図１８の右側に「Ｓｔｅｐ２」として記述されるものであり、時間長４３２の部分が解消された実行タイミングとされている。この実行タイミングは、時間長さ４３２について、その半分の時間長の分だけ、親関数実行開始タイミングを遅らせたものである。従って、パソコン環境下では、親関数実行終了タイミングから時間長さ４３２の半分の時間経過後のタイミングが、ＥＣＵ環境下での終了タイミングに合致するはずである。

図１９の一連の処理によれば、最初に子関数について遅延処理を実行し、その後に親関数に遅延処理を実行することで、終了するが、この終了判断は、処理ステップＳ１５８においてタイミング未調整の関数がないことを確認することで完結とする。

なお一連の処理では、付随的に以下の処理を行うのがよい。まず処理ステップＳ１６１では、関数の遅延処理の繰り返し回数が予め定めた上限（図２０の例では、関数数４＊開始、終了の２で定まる８）の範囲内での繰り返し処理を許可し、上限以上の繰り返しを行わないものとするのがよい。

また性能比較ソフトＳＷ２を使用しての遅延量調整処理が終わらないケースも想定するのがよい。その時の性能調整フローを図１９で説明する。例えば、一関数の実施タイミングが変わった影響で別関数の動作が変わることが考えられる。これまでエラー処理に流れていたものが、正常処理に切り替わる場合などが例として挙げられる。

図１９では、処理ステップＳ１５５の判定条件で性能差が閾値未満にならずに、処理ステップＳ１６１の判定条件がＹｅｓの場合（実施回数が上限を超えた場合）、閾値を変更する。図１９の処理ステップＳ１６２において、許容する性能差を緩和し、遅延量調整を行う。再調整を行い、実施回数が上限に到達し、なお性能差が閾値未満にならない場合（判定条件である処理ステップＳ１６３の結果がＮｏの場合）は、タイミング調整ができないと判定し、図１９の処理ステップＳ１６４において、遅延パラメータファイルＦｉ３の内容を初期化（遅延注入なし）し、性能調整処理を終了する。

以上により、パソコンＰＣ１台に対するＰＣシミュレーション環境の遅延量調整処理が終わる。一般には、開発者ごとに使用しているパソコンＰＣの種類（ＨＷ仕様）が異なるが、パソコンＰＣ毎に遅延量調整を行う事により、開発者毎のＰＣシミュレーション環境での実行タイミングを実ＥＣＵに近づけることが可能となる。

実施例７ではシングルタスク環境で遅延量決定、タイミング調整を行うことを説明したが、ＥＣＵアプリケーションソフトはマルチタスク環境で動作することが多い。

マルチタスク環境では、タスクの優先順位に基づいたコンテキスト切り替えが発生する。コンテキスト切り替えが発生するかどうかにより関数の終了時間が変わってしまう。

実施例８では、性能比較ソフトＳｗ２での関数の実行時間計算時に、動作タスク情報を考慮することでコンテキスト切り替えが発生した場合でも実際に処理を行った時間を計算することができる。

本実施例で使用する２つのタスクの情報を図２２に示し説明する。

図２２にはタスクのコンテキスト切り替えが発生した場合の測定結果ファイルの内容と各タスクの実行タイミング例を示している。

この例では、ＡとＢのタスクがあり、Ａ、Ｂ共にタイマイベントで起動し、周期的に処理を行うタスクであるが、タスクＢの優先度が高く、タスクＡの実行中に優先度の高いタスクＢが起動される。

時系列的には、タスクＡがタイマイベント２０１を契機に時刻ｔ０から処理を開始する。タスクＡの処理実行中に、タスクＢのタイマイベント２０２が時刻ｔ１において発行された場合、優先度の関係からタスクＡの実行を中断し、タスクＢの処理を開始する。その後時刻ｔ２においてタスクＢの処理が終了、タスクＡの処理が再開し、最終的にタスクＡは時刻ｔ３で終了となる。

このとき、タイミングを調整する為に記憶する開始、終了時間はタスクごとに管理しており、各タスクは上記開始、終了時刻を記憶している。図２３は、各タスクが記憶した開始、終了時刻の一例である。マルチタスクの場合には、他タスクが動作している間の時間を関数の実行時間から減算することにより、実際の実行時間を算出する。

例えば、タスクＡの関数（ｆｕｎｃ＿ａ）の開始、終了時間をｔ０、ｔ３、タスクＢの関数（ｆｕｎｃ＿ｂ）の開始、終了時間をそれぞれｔ１、ｔ２とした場合、タスクＢに割り込まれたタスクＡの実行時間は（（ｔ３−ｔ０）−（ｔ２−ｔ１））で計算することが出来る。

上記説明の本発明では、ＥＣＵソフト内で時間計測機能と遅延注入機能を持たせる。実ＥＣＵとＰＣシミュレーション環境でソフトを実行し、実行タイミング（起動後の経過時間）を記録する。

実ＥＣＵとＰＣシミュレータでの実行タイミングを保存した処理タイミングデータの内容を比較し、処理時間の差からＰＣシミュレータで注入する遅延量を決定し、ファイルへ保存する機能を備えた性能比較ソフトを用意する。

性能比較ソフトを実行により更新された遅延パラメータファイルの情報を使用してＰＣシミュレーション環境でＥＣＵアプリケーションソフトを再度実行する。ＰＣシミュレーション環境で調整済みの遅延量で遅延処理を行う事でＰＣシミュレーション環境での実行タイミングを実ＥＣＵへ近づけることができる。

時刻測定は、実行タイミングを調整したい関数の開始時と終了時で記録する。また遅延処理を入れる場所は、関数開始時の時刻計測直後と、関数終了直前の時刻計測直前で行う。どちらか一方で遅延処理を実行する事も出来るし、両方で遅延処理を入れることも可能である。

ＥＣＵの試作ＨＷが出来ていないタイミングでは、ＣＰＵの評価ボードや、開発のベースとなっているＥＣＵハードウェアを使用することで、ＥＣＵでの実行タイミング情報として保存し、それを実ＥＣＵでの実行タイミングとして利用することも可能である。

１０１：システム・バス
１０２：ＣＰＵ
１０３：主記憶装置
１０４：ＨＤＤ
１０５：キーボード
１０６：マウス
１０７：ディスプレイ
１０８：ＲＯＭ
Ｓ：実環境機
ＰＣ（ＰＣａ、ＰＣｂ・・・ＰＣｎ）：パソコン
１８０：通信装置
１８１：外部システム・バス
Ｓｗ１：ＥＣＵアプリケーションソフト
Ｓｗ２：性能比較ソフト
Ｓｗ３：通信ソフト
ＳＷ１１：遅延注入機能
ＳＷ１２：性能測定機能
ＳＷ２１：測定結果比較・遅延パラメータ設定部
ＳＷ２２：比較結果表示部
ＳＷ３１：測定結果受信部
Ｆｉ１：ＥＣＵ測定結果ファイル
Ｆｉ２：ＰＣ測定結果
Ｆｉ３：遅延パラメータファイル
ＳＷ４：ＥＣＵアプリケーションソフト
ＳＷ４１：性能測定機能
ＳＷ４２：測定結果送信部
Ｆｉ４：ＥＣＵ測定結果ファイル

Claims (10)

1. 第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、前記第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機で構成されたことを特徴とするシミュレーション装置。
2. 請求項１に記載のシミュレーション装置であって、
   前記第１の計算機は、通信装置を介して前記第２の計算機に接続されており、前記第２の計算機は当該第２の計算機でアプリケーションソフトを実行したときの前記第２の処理タイミングを得る第２の性能測定機能を備えることを特徴とするシミュレーション装置。
3. 第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングを得る第１の性能測定機能と、前記第１の処理タイミングと第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うタイミング調整機能を備える第１の計算機と、
   アプリケーションソフトを実行したときの処理タイミングを前記第２の処理タイミングとして得る第２の性能測定機能を備える第２の計算機と、
   前記第１の計算機と前記第２の計算機を接続する通信装置を備えることを特徴とするシミュレーション装置。
4. 請求項１から請求項３のいずれか１項に記載のシミュレーション装置であって、
   前記タイミング調整機能は、前記第２の処理タイミングを目標タイミングとして前記第１の処理タイミングを合わせることを特徴とするシミュレーション装置。
5. 請求項１から請求項４のいずれか１項に記載のシミュレーション装置であって、
   前記アプリケーションソフトは、親関数の中で子関数が実行されるとともに親関数並びに子関数の関数開始時刻および関数終了時刻が記録される言語で記述されていることを特徴とするシミュレーション装置。
6. 請求項５に記載のシミュレーション装置であって、
   前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整は、前記子関数のタイミング調整完了後に、前記親関数のタイミング調整が行われることを特徴とするシミュレーション装置。
7. 請求項１から請求項６のいずれか１項に記載のシミュレーション装置であって、
   前記第２の計算機は、ＥＣＵであることを特徴とするシミュレーション装置。
8. 請求項１から請求項７のいずれか１項に記載のシミュレーション装置であって、
   複数の前記第１の計算機が、通信装置を介して接続されていることを特徴とするシミュレーション装置。
9. アプリケーションソフトを実行したときに第２の処理タイミングを入手するための性能測定機能と、前記第２の処理タイミングを記憶する測定結果記憶部と、前記第２の処理タイミングを外部に送信するための通信装置を備えることを特徴とするＥＣＵ装置。
10. 第１の計算機でアプリケーションソフトを実行したときの第１の処理タイミングと、第２の計算機でアプリケーションソフトを実行したときの第２の処理タイミングの間の時間差をもとに、前記第１の計算機における前記アプリケーションソフトの実行時刻のタイミング調整を行うことを特徴とするシミュレーション方法。

Images