JP2023087354A - シミュレーション方法 - Google Patents

Abstract

【課題】分散ハードウェア構成を考慮した上で、ホスト環境上でターゲット環境におけるソフトウェア実行タイミングを高精度に再現すること。【解決手段】第１のソフトウェア１０をホスト環境１００上において実行することによって得られる第１のホスト特徴量１１を抽出し、第１のソフトウェア１０をターゲット環境１１０上において実行することによって、ターゲット環境１１０上において第１のソフトウェア１０を実行するのに要するターゲット実行時間２０を算出し、第１のホスト特徴量１１とターゲット実行時間２０とに基づいて、ホスト環境１００とターゲット環境１１０との性能差を算出し、第２のソフトウェア１２をホスト環境１００上において実行することによって得られる第２のホスト特徴量１３を抽出し、第２のホスト特徴量１３と性能差とに基づいて、第２のソフトウェア１２をターゲット環境１１０上で実行するのに要する時間４０を推定する。【選択図】図３

Description

本発明は、シミュレーション方法に関する。

ＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づけるための既存技術として、特許文献１に記載の技術がある。特許文献１においては、ＰＣシミュレーション環境の実行タイミングを実ＥＣＵに近づける為の遅延処理を追加する機能を備えたシミュレーション装置を提供する事を目的としている。そしてその解決手段として、アプリケーションソフトを実行コードに変換して検証し、検証後の実行コードを他の計算機装置に移植するためのシミュレーション装置であって、アプリケーションのソースコードの関数単位で関数開始時、または終了時に時刻調整処理を行い、他の計算機装置における実行タイミングを調整することを特徴とするシミュレーション装置が記載されている。

再公表特許２０１９／２４４４７２

特許文献１に記載の方法によれば、ソフトウェアの関数単位で関数開始時または終了時に時刻調整処理を行うことで、実行タイミングを実ＥＣＵに近づけてシミュレーションを行うことが可能である。しかしながら、特許文献１においては、シミュレーション装置と計算機装置の速度比率(ＣＰＵクロック数比)に基づいて実行タイミングを調整しているが、キャッシュやバスといったプログラムの特徴やマイコンの特徴が実行時間に影響を与えることを考慮していない。そのため、速度比率単体では、調整の精度が十分でないことが問題となる。

また、特許文献１においては、分散ハードウェア構成を考慮していない。そのため、２つの関数(ソフトウェア)が別々のハードウェア上で動作していた際の通信タイミングの違いによるレイテンシを再現できないことが問題となる。

したがって、分散ハードウェア構成を考慮した上で、ホスト（ＰＣシミュレーション)環境上で高精度にターゲット(実ＥＣＵ)環境を再現することが課題である。

上記課題を解決するためのシミュレーション方法は、第１のソフトウェアをホスト環境上において実行することによって得られる第１のホスト特徴量を抽出し、第１のソフトウェアをターゲット環境上において実行することによって、ターゲット環境上において第１のソフトウェアを実行するのに要するターゲット実行時間を算出し、第１のホスト特徴量とターゲット実行時間とに基づいて、ホスト環境とターゲット環境との性能差を算出し、第２のソフトウェアをホスト環境上において実行することによって得られる第２のホスト特徴量を抽出し、第２のホスト特徴量と性能差とに基づいて、第２のソフトウェアをターゲット環境上で実行するのに要する時間を推定する。

本発明によれば、分散ハードウェア構成を考慮した上で、ソフトウェアを開発するホスト環境上で高精度にターゲット環境が再現される。すなわち、ホスト環境上にターゲット環境が模擬されることになる。従って、実際にターゲット環境にソフトウェアを移植しなくても、ターゲット環境上においてソフトウェアが正常に実行できるか否かを検証することが可能になり、ソフトウェアの開発効率が向上する。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

ホスト環境１００の構成を示した図。 ターゲット環境１１０の構成を示した図。 実施例１におけるシミュレーション方法を用いて行う処理全体の概要を示した図。 ホスト特徴量取得部１が行う処理フローの概要を示した図。 ホスト特徴量１１の例を示した図。 ターゲット実行時間取得部２が行う処理フローの概要を示した図。 ターゲット実行時間２０の例を示した図。 ソフトウェア実行管理部５が行う処理フローの概要を示した図。 実施例２におけるシミュレーション方法を用いて行う処理全体の概要を示した図。 機器割り当て情報５０の例を示した図。 データフロー情報５１の例を示した図。 機器間調整係数情報５２の例を示した図。 実施例２におけるソフトウェア実行管理部５が行う処理フローの概要を示した図。 実施例３におけるシミュレーション方法を用いて行う処理全体の概要を示した図。 周期情報６０の例を示した図。 実行順序推定部６が行う処理フローの概要を示した図。 実行順序検証部７が行う処理フローの概要を示した図。 実施例４におけるシミュレーション方法を用いて行う処理全体の概要を示した図。 ソフトウェア仕様書８０の例を示した図。 仕様評価部８が行う処理フローの概要を示した図。 機能割り当て部９が行う処理フローの概要を示した図。

本実施例は、ソフトウェアのシミュレーション方法に関する。以下、本発明に好適な実施形態の例（実施例）を説明する。

［実施例１］
＜ホスト環境の構成＞
図１は本発明におけるホスト環境（クラウド）１００の構成を示した図である。
本実施例におけるホスト環境１００は、管制連携自動運転システムにおけるソフトウェア部分の開発・検証を目的としている。ここで、管制連携自動運転システムにおけるハードウェアの構成は、インフラセンサ１０１、管制装置１０２、及び車両１０３を有する構成である。また、車両１０３には、少なくとも１つ以上のマイコン１０３０が搭載されている。

ホスト環境１００上には既存ソフトウェア１０と新規ソフトウェア１２が実装されている。これらは実際の環境において、インフラセンサ１０１、管制装置１０２、車両１０３上で実行されるソフトウェアである。また、ホスト環境１００は実際のセンサ１０４０やアクチュエータ１０４１を有さないため、シミュレータ１０４がセンサ１０４０やアクチュエータ１０４１を模擬する既存ソフトウェア１０を有する。

新規ソフトウェア１２は、ホスト環境１００上において開発され、ターゲット環境１１０（図２参照）に移植される。各ソフトウェアは、例えば物体認識や経路計画や制御指令値の算出といった機能を発揮する。なお、図１において、新規ソフトウェア１２は車両１０３内のマイコン１０３０に実装されるソフトウェアとしているが、別の機器に新規ソフトウェア１２が実装されていてもよい。

＜ターゲット環境の構成＞
図２は本発明におけるターゲット環境（コントローラ）１１０の構成を示した図である。
ターゲット環境１１０は、管制連携自動運転システムにおける実際のハードウェア構成を有しており、例えば図２におけるターゲット環境１１０は車両１０３に搭載されるマイコン１０３０である。

また、ターゲット環境１１０のペリフェラル（内蔵装置や周辺機器等）については、図２に示すようにＰＣ１２０が模擬してもいいし、実際にインフラセンサ１０１、管制装置１０２、車両１０３を有していてもよい。実際のハードウェア構成を有する場合、車両１０３上にセンサ１０４０とアクチュエータ１０４１が搭載されているため、シミュレータ１０４は不要となる。同様に各ハードウェアが存在するため、ＰＣ１２０も不要となる。上述の通り、新規ソフトウェア１２はホスト環境１００上で開発されるが、ターゲット環境１１０に移植される。

また、図２において、新規ソフトウェア１２は車両１０３内のマイコン１０３０に実装されるソフトウェアとしているが、別の機器に新規ソフトウェア１２が実装されていてもよい。

＜シミュレーション方法の概要＞
図３は実施例１におけるシミュレーション方法の概要を示した図である。
本実施例に係るシミュレーション方法は、ホスト特徴量取得部１と、ターゲット実行時間取得部２と、実行時間推定モデル作成部３と、ターゲット上実行時間推定部４と、ソフトウェア実行管理部５と、によって実行される。

ホスト特徴量取得部１は、例えばホスト環境１００に搭載された機能部であり、種々のソフトウェアをホスト環境下で実行したときに、実行時間等の情報を含む、後述するホスト特徴量１１を算出し、取得する。

ターゲット実行時間取得部２は、例えばターゲット環境１１０に搭載された機能部であり、既存ソフトウェア１０をターゲット環境上において実行したときに要するターゲット実行時間２０を取得する。

実行時間推定モデル作成部３は、例えばホスト環境１００に搭載された機能部であり、ホスト特徴量１１及びターゲット実行時間２０に基づいてホスト環境１００とターゲット環境１１０との間の性能差を算出する。そして、任意のソフトウェアをターゲット環境１１０上において実行したときに要する実行時間を推定するための実行時間推定モデル３０を作成する。

ターゲット上実行時間推定部４は、例えばホスト環境１００に搭載された機能部であり、実行時間推定モデル３０と、新規ソフトウェア１２をホスト環境上において実行した際に得られる新規ソフトウェアホスト特徴量１３とから、ターゲット環境１１０上において新規ソフトウェア１２を実行したときに要する実行時間を推定し、推定実行時間４０を生成する。

ソフトウェア実行管理部５は、例えばホスト環境１００に搭載された機能部であり、推定実行時間４０に基づいて、ホスト環境１００上におけるソフトウェアの実行を管理する。

以下では、上記の各機能部及び各種データについて詳述する。

＜ホスト特徴量取得部＞
図４はホスト特徴量取得部１が行う処理フローの概要を示した図である。
ホスト特徴量取得部１は、ステップＳ１１において、特徴量の計測を行う対象のソフトウェアを取得する。
ステップＳ１２において、ソフトウェアの周期処理開始時に特徴量の計測を開始する。
ステップＳ１３において、ソフトウェアの周期処理終了時に特徴量の計測を終了し、特徴量を保存する。

ステップＳ１４において、ソフトウェアの実行結果が測定終了条件を満たしたかを判定し、測定終了条件を満たしている場合はステップＳ１５に進み、測定終了条件を満たしていない場合はステップＳ１２に戻る。測定終了条件は、例えば任意の時間を経過したかどうか、ソフトウェアが自動運転に関するものであれば自動運転によって目的地に到着したか、自動運転が継続できないといったエラーが出たか、などから決定できる。また、複数の測定終了条件を組み合わせてもよい。

ステップＳ１５において、ステップＳ１３で保存していた特徴量の中で、最悪実行時間時の特徴量を抽出する。ここで、最悪実行時間とは、特定のハードウェアで特定の計算タスクを実行するのにかかる最長の時間のことを指し、本実施例においては、ホスト環境１００上で、既存ソフトウェア１０または新規ソフトウェア１２を一定回数以上の周期実行した際に得られる最も長い周期のことを指す。ホスト環境１００上における最悪実行時間時の特徴量を抽出することで、ホスト環境１００上においてターゲット環境１１０上での実行を模擬した際に、ターゲット環境１１０上での最悪実行時間を再現することが期待でき、検証の正確性を担保することができる。
ステップＳ１６において、ステップＳ１５において抽出した特徴量をホスト特徴量１１として出力する。
このような手順でホスト特徴量取得部１はホスト特徴量１１を取得する。

＜ホスト特徴量＞
図５は上述したホスト特徴量１１の例を示した図である。
ホスト特徴量１１は、ソフトウェア別に周期毎に取得した特徴量として出力される。図５に示した特徴量の種類は一例であり、以下に特徴量の対象となる候補を列挙する。
・実行時間：ソフトウェアの実行に要した時間である。
・ＣＰＵサイクル数：ソフトウェアの実行に要したＣＰＵサイクル数であり、これをＣＰＵ周波数で割った値が実行時間となる。
・キャッシュミス回数：キャッシュミスが発生すると、メモリアクセスといった実行に時間を要する処理が必要となる。またキャッシュミスはＬＬＣ（Ｌａｓｔ Ｌｅｖｅｌ Ｃａｃｈｅ）、Ｌ１、Ｌ２がある。
・コンテキストスイッチ回数：割込み処理等、実行中の処理とは別の処理にＣＰＵが使用されると、ＣＰＵの状態を保存・復元するための処理が発生する。
・ＣＰＵマイグレーション回数：処理が別のＣＰＵに移動すると、ＣＰＵの状態を移行するために処理が発生する。
・リタイアした命令数：投機的実行を行ったが、使用されなかった命令であり、必要な命令を分岐後に実行する必要があるため、実行時間が遅くなる。
・ブランチミス数：投機的実行に失敗した分岐の数であり、必要な命令を分岐後に実行する必要があるため、実行時間が遅くなる。
・ストアフォワード回数：あるメモリアドレスに書き込む命令の後に同じアドレスから読み込む命令が実行される場合に、キャッシュではなくバッファにあるデータを利用することであり、キャッシュとバッファでアクセスに要する時間が異なる。
・ロードブロック数：データのロードに失敗した回数であり、必要に応じて再度データのロードを試みるため、処理が増加する。
・ストアブロック数：データのストアに失敗した回数であり、必要に応じて再度データのストアを試みるため、処理が増加する。
・範囲外ロード回数：ソフトウェアによってアクセスできる範囲外にアクセスしようとすると、エラーが発生する可能性があり、正常に実行されないため、正常時と実行時間が異なる。
・不完全なアドレスによるアクセス失敗回数：不完全なアドレスの整列により、連続したアドレスにデータが存在せず、別のアドレスへアクセスが必要となる。
・ＤＴＬＢ(Ｄａｔａ－Ｔｒａｎｓｌａｔｉｏｎ Ｌｏｏｋａｓｉｄｅ Ｂｕｆｆｅｒ)ロードミス回数：要求したアドレスがＴＬＢ内になかった回数であり、アドレス変換のためにページテーブルを参照する必要があり、処理が増加する。
・メモリディスアンビギュレーションイベント回数：依存関係にあるロード命令とストア命令を並列実行する際に、ストア命令を先に実行する必要があり、ロード命令はストア命令の実行を待つ必要がある。
・メモリアクセスリタイア回数：アクセスしようとしたメモリが別のコアによって変更されたことにより、リタイアしたメモリアクセスの回数であり、アクセスのために追加の処理が必要となる。
・ハードウェア割り込みイベント回数：ハードウェア割り込みイベントが発生した回数であり、割り込みが発生すると、保存・復元の処理が必要になる。
・プリフェッチ回数：ＣＰＵがデータを事前にメモリからキャッシュメモリに読みだしておいた回数であり、メモリとキャッシュでアクセスに要する時間が異なる。
・キャッシュロックサイクル数：キャッシュがロックされていたサイクル数であり、アンロックされるまで待つ必要がある。
・実行が停止したサイクル数：実行が停止したサイクル数であり、ソフトウェア実行のサイクル数に影響を与える。
・直前実行ソフト：直前に実行されたソフトウェアのキャッシュの状況によって、例えばＲｅａｄしたいデータがキャッシュ内にあるため、高速にＲｅａｄできることが考えられる。

＜ターゲット実行時間取得部＞
図６はターゲット実行時間取得部２が行う処理フローの概要を示した図である。
ターゲット実行時間取得部２は、ステップＳ２１において、実行時間の計測を行う対象のソフトウェアを取得する。
ステップＳ２２において、ソフトウェアの周期処理開始時に実行時間の計測を開始する。
ステップＳ２３において、ソフトウェアの周期処理終了時に実行時間の計測を終了し、実行時間を保存する。

ステップＳ２４において、ソフトウェアの実行結果が測定終了条件を満たしたかを判定し、測定終了条件を満たしている場合はステップＳ２５に進み、測定終了条件を満たしていない場合はステップＳ２２に戻る。測定終了条件は、例えば任意の時間を経過したかどうか、ソフトウェアが自動運転に関するものであれば自動運転によって目的地に到着したか、自動運転が継続できないといったエラーが出たか、などから決定できる。また、複数の測定終了条件を組み合わせてもよい。

ステップＳ２５において、ステップＳ２３で保存していた実行時間の中で、最悪実行時間を抽出する。
ステップＳ２６において、ステップＳ２５において抽出した最悪実行時間をターゲット実行時間２０として出力する。
このような手順でターゲット実行時間取得部２はターゲット実行時間２０を取得する。

＜ターゲット実行時間＞
図７は本発明におけるターゲット実行時間２０の例を示した図である。本実施例においてはターゲット実行時間２０として、ソフトウェア別に取得した最悪実行時間が保存されている。

＜実行時間推定モデル作成部＞
上述の処理で得られたホスト特徴量１１及びターゲット実行時間２０は、実行時間推定モデル作成部３に出力される。実行時間推定モデル作成部３は、ホスト特徴量１１を独立変数(説明変数)とし、ターゲット実行時間２０を従属変数(目的変数)として、機械学習を行うことにより、実行時間推定モデル３０を生成する。機械学習のアルゴリズムとしては、重回帰分析やＤＮＮなどの公知のアルゴリズムを用いる。

＜実行時間推定モデル＞
実行時間推定モデル作成部３によって作成される実行時間推定モデル３０は、新規ソフトウェアホスト特徴量１３を入力すると、推定実行時間４０を出力するモデルである。

＜ターゲット上実行時間推定部＞
ターゲット上実行時間推定部４は、実行時間推定モデル作成部３が出力した実行時間推定モデル３０と、ホスト特徴量取得部１に新規ソフトウェア１２を入力することで得られる新規ソフトウェアホスト特徴量１３と、を入力として受け取る。そして、実行時間推定モデル３０に新規ソフトウェアホスト特徴量１３を入力することで、ターゲット環境１１０上において新規ソフトウェア１２を実行したときに要すると推定される推定実行時間４０を得る。

＜推定実行時間＞
本実施例における推定実行時間４０は、新規ソフトウェア１２をターゲット環境１１０上で実行した際の予測される最悪実行時間である。

＜ソフトウェア実行管理部＞
図８はソフトウェア実行管理部５が行う処理フローの概要を示した図である。
ソフトウェア実行管理部５は、ステップＳ５１において、シミュレーションを行う対象の新規ソフトウェア１２を取得する。
ステップＳ５２において、ターゲット上実行時間推定部４から推定実行時間４０を取得する。
ステップＳ５３において、ソフトウェアの周期処理開始時に実行時間の計測を開始する。
ステップＳ５４において、ソフトウェアの周期処理内のデータ出力処理の直前に実行時間の計測を終了し、実行時間を保存する。

ステップＳ５５において、計測した実行時間が推定実行時間４０より短ければ、その差分の時間だけビジーウェイトさせる。即ち、通常ホスト環境１００は、ターゲット環境１１０よりも高い演算処理能力を有している。そのため、ホスト環境１００上においてあるソフトウェアを実行した場合における各処理の実行時間は、ターゲット環境１１０上においてそのソフトウェアを実行するのに要すると推定される時間よりも短くなる。そのため、ホスト環境１００上においてソフトウェアを実行した際の各処理における推定実行時間と実際の実行時間との差分の時間だけ待機することによって、ホスト環境上にターゲット環境１１０を高精度に模擬することが可能になる。

ステップＳ５６において、ソフトウェアの実行の結果得られたデータの出力処理を行う。
ステップＳ５７において、ソフトウェアの実行結果が測定終了条件を満たしたかを判定し、測定終了条件を満たしている場合は処理を終了し、測定終了条件を満たしていない場合はステップＳ５３に戻る。測定終了条件は、例えば任意の時間を経過したかどうか、ソフトウェアが自動運転に関するものであれば自動運転によって目的地に到着したか、自動運転が継続できないといったエラーが出たか、などから決定できる。また、複数の測定終了条件を組み合わせてもよい。
このような手順でソフトウェア実行管理部５は新規ソフトウェア１２をホスト環境１００上で実行し、ターゲット環境１１０上での新規ソフトウェア１２の実行を模擬する。

上述した実施例１におけるシミュレーション方法によれば、事前に既存ソフトウェア１０をホスト環境１００上とターゲット環境１１０上のそれぞれにおいて実行することで、ホスト特徴量１１からターゲット環境１１０上における最悪実行時間を推定可能な実行時間推定モデル３０を生成する。そして、ホスト環境１００上において新規ソフトウェア１２を実行することによって得られた新規ソフトウェアホスト特徴量１３を実行時間推定モデル３０に入力することで、新規ソフトウェア１２を実際にターゲット環境１１０に移植することなく、新規ソフトウェア１２をターゲット環境１１０上において実行した際の最悪実行時間を推定することが可能になっている。そして、推定実行時間４０に基づいて、実行時間を調整しながらホスト環境１００上において新規ソフトウェア１２を実行することで、高精度にターゲット環境１１０上での新規ソフトウェア１２の実行を模擬して検証できるため、ホスト環境１００上において開発している新規ソフトウェア１２をシームレスにターゲット環境１１０へ移植することが可能となる。

［実施例２］
続いて、本発明の実施例２におけるシミュレーション方法について説明する。
実施例２が実施例１と異なる点は、実施例１で用いた情報に加えて、機器割り当て情報５０とデータフロー情報５１と機器間調整係数情報５２とを用いて、ソフトウェア間の通信を再現し、ホスト環境１００上でのソフトウェアの実行タイミングを調整する点である。なお、実施例１と同様の構成については、同一の符号を付してその説明を省略する。

＜シミュレーション方法の概要＞
図９は実施例２におけるシミュレーション方法の概要を示した図である。
本実施例においては、推定実行時間４０に加えて、機器割り当て情報５０とデータフロー情報５１と機器間調整係数情報５２をソフトウェア実行管理部５へ入力する。なお、機器割り当て情報５０、データフロー情報５１及び機器間調整係数情報５２は、例えばホスト環境１００内に格納されている。

＜機器割り当て情報＞
図１０は本発明における機器割り当て情報５０の例を示した図である。
機器割り当て情報５０は、それぞれのソフトウェアがどの機器上で動作しているかの情報を示している。本実施例においては、例えばソフトウェアＡとソフトウェアＣはマイコンＡ上で動作し、ソフトウェアＢはマイコンＢ上で動作している。

＜データフロー情報＞
図１１は本発明におけるデータフロー情報５１の例を示した図である。
データフロー情報５１は、それぞれのソフトウェアがどのソフトウェアにどのような通信方法でデータを送信するかの情報を示している。本実施例においては、例えばソフトウェアＡは、ソフトウェアＢへＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ）を用いてデータを送信し、ソフトウェアＣへはマイコン内(プロセス間通信など)でデータを送信する。

＜機器間調整係数情報＞
図１２は本発明における機器間調整係数情報５２の例を示した図である。
機器間調整係数情報５２は、機器の間でどの程度データ送受信のタイミングを調整するかを設定するための機器間調整係数の情報を示している。例えばマイコン内は高速でデータの送受信が可能であるため調整が不要(係数が０)であるが、ＷｉＦｉ（登録商標)の場合は無線であるため調整すべき遅延が大きい(係数が８)と設定する。機器間調整係数は、実際にターゲット環境１１０で計測を行い決定する、もしくは、ターゲット環境１１０のスペックと送信されるデータサイズから決定する。

＜ソフトウェア実行管理部＞
図１３は実施例２におけるソフトウェア実行管理部５が行う処理フローの概要を示した図である。
ソフトウェア実行管理部５は、ステップＳ５１において、シミュレーションを行う対象の新規ソフトウェア１２を取得する。
ステップＳ５２において、ターゲット上実行時間推定部４から推定実行時間４０を取得する。
ステップＳ５８において、機器割り当て情報５０を取得する。
ステップＳ５９において、データフロー情報５１を取得する。
ステップＳ５Ａにおいて、機器間調整係数情報５２を取得する。

ステップＳ５３において、ソフトウェアの周期処理開始時に実行時間の計測を開始する。
ステップＳ５Ｂにおいて、その周期において受信したデータを、何周期目であるかの情報とともに保存する。

ステップＳ５Ｃにおいて、機器割り当て情報５０とデータフロー情報５１から、受け取ったデータに対応する機器間調整係数を決定する。例えば、新規ソフトウェア１２がソフトウェアＢであり、データの送信元がソフトウェアＡの場合を考える。図１０の機器割り当て情報５０と図１１のデータフロー情報５１から、ソフトウェアＡとソフトウェアＢはＣＡＮを用いて通信が行われるため、図１２の機器間調整係数情報５２の該当行を参照し、機器間調整係数は１であることがわかる。

ステップＳ５Ｄにおいて、ステップＳ５Ｃで決定した機器間調整係数に基づき、ステップＳ５Ｂで保存していた過去の受信データの中から、機器間調整係数に基づいて選択した過去のデータを今回の制御周期処理での入力として処理を行う。
ステップＳ５４において、ソフトウェアの周期処理内のデータ出力処理の直前に実行時間の計測を終了し、実行時間を保存する。
ステップＳ５５において、計測した実行時間が推定実行時間４０より短ければ、その差分の時間だけビジーウェイトさせる。
ステップＳ５６において、データ出力処理を行う。

ステップＳ５７において、ソフトウェアの実行結果が測定終了条件を満たしたかを判定し、測定終了条件を満たしている場合は処理を終了し、測定終了条件を満たしていない場合はステップＳ５３に進む。測定終了条件は、例えば任意の時間を経過したかどうか、ソフトウェアが自動運転に関するものであれば自動運転によって目的地に到着したか、自動運転が継続できないといったエラーが出たか、などから決定できる。また、複数の測定終了条件を組み合わせてもよい。
このような手順で実施例２におけるソフトウェア実行管理部５はホスト環境１００上において新規ソフトウェア１２を実行する。

上述したステップＳ５ＢからＳ５Ｄまでの処理についてより詳細に説明する。図１０－１１を参照すると、例えば、ソフトウェアＥは、マイコンＡ上で実行されているソフトウェアＣと、管制装置上で実行されているソフトウェアＤとからデータを受け取る。図１１と図１２より、ソフトウェアＣとソフトウェアＥとの間のデータ通信はＷｉＦｉで行われており、その機器間調整係数は８である。これはすなわち、ソフトウェアＥのＮ周期目の実行において、ソフトウェアＣがＮ－８周期目に生成したデータが用いられることを意味する。同様に、ソフトウェアＤとソフトウェアＥとの間のデータ通信はＥｔｈ（Ｅｔｈｅｒｎｅｔ：登録商標）で行われており、その機器間調整係数は２である。これは、ソフトウェアＥのＮ周期目の実行において、ソフトウェアＤがＮ－２周期目に生成したデータが用いられることを意味する。

このように、上述の例では、ソフトウェアＥのＮ周期目に用いられるデータは、ソフトウェアＣがＮ－８周期目に生成したデータとソフトウェアＤがＮ－２周期目に生成したデータとなる。しかしながら、ホスト環境１００とターゲット環境１１０間の性能差により、ホスト環境１００上において同じソフトウェアを実行した場合、ソフトウェアＥのＮ周期目に用いられるデータは、例えばソフトウェアＣがＮ―２周期目に生成したデータとソフトウェアＤがＮ―２周期目に生成したデータとなることが考えられる。この場合、ソフトウェアＥの実行に用いられるデータが生成されたタイミングがターゲット環境１１０と異なるため、ホスト環境１００上での実行結果とターゲット環境１１０上での実行結果が異なることとなり、ホスト環境１００で高精度なターゲット環境１１０を再現することが不可能となる。

これに対して、実施例２におけるソフトウェア実行管理部５の行う処理フローにより、機器間の通信方法に応じた遅延を挿入するため、ホスト環境１００上で新規ソフトウェア１２を実行する際にターゲット環境１１０上で実行した際の通信タイミングとなるように調整することが可能となる。

なお、本実施例において、データ受信側においてデータを調整する処理を行っているが、データ送信側においてデータを調整する処理を行っても同様の効果を得ることができる。

上述したように、実施例２におけるシミュレーション方法によれば、機器割り当て情報５０とデータフロー情報５１と機器間調整係数情報５２とを用いることにより、ソフトウェア間で処理を行う際のデータの送受信タイミングを調整する。これにより、ホスト環境１００上で新規ソフトウェア１２を実行する際に、ターゲット環境１１０上で実行した際の通信タイミングとなるように調整することが可能になるため、ターゲット環境１１０上でソフトウェアを実行する際のデータの生成タイミングをホスト環境１００上で正確に再現することが可能となる。

［実施例３］
本発明の実施例３におけるシミュレーション方法について説明する。
実施例３が実施例１と異なる点は、新規ソフトウェア１２を含むソフトウェア群をターゲット環境１１０で実行した際の実行順序を推定し、上記ソフトウェア群をホスト環境１００上で実行した際の実行順序と比較検証する点をさらに含むことである。これにより、ホスト環境１００に起因する事象により実行したシミュレーションが正しく実行できなかった可能性があることを検知することができる。なお、実施例１と同様の構成については、同一の符号を付してその説明を省略する。

＜シミュレーション方法の概要＞
図１４は実施例３におけるシミュレーション方法の概要を示した図である。
本実施例に係るシミュレーション方法は、実施例１に加えてさらに実行順序推定部６及び実行順序検証部７による処理が行われる。実行順序推定部６及び実行順序検証部７は、例えばホスト環境１００に搭載された機能部である。

実行順序推定部６には、ターゲット実行時間２０と機器割り当て情報５０と周期情報６０と、が入力され、推定実行順序６１が出力される。実行順序検証部７は、ホスト環境１００上でソフトウェアを実行した際の実行結果と推定実行順序６１と、が入力され、ソフトウェアがホスト環境１００上で正しく実行されたかを検証する。

＜周期情報＞
図１５は本発明における周期情報６０の例を示した図である。周期情報６０は、例えばホスト環境１００内に格納されている。
周期情報６０は、それぞれのソフトウェアの実行周期の情報を示している。例えばソフトウェアＡは、５０ｍｓ毎に１回実行される。

＜実行順序推定部＞
図１６は本発明における実行順序推定部６の処理フロー概要を示した図である。
実行順序推定部６は、ステップＳ６１において、機器割り当て情報５０を取得する。
ステップＳ６２において、ターゲット上実行時間推定部４から推定実行時間４０を取得する。
ステップＳ６３において、ターゲット実行時間取得部２からターゲット実行時間２０を取得する。
ステップＳ６４において、周期情報６０を取得する。

ステップＳ６５において、スケジューリングを行い、ソフトウェア群の実行順序を推定する。スケジューリングアルゴリズムは、ラウンドロビン方式やレートモノトニックスケジューリング方式など公知のアルゴリズムを用いる。
ステップＳ６６において、ステップＳ６５で推定した実行順序を推定実行順序６１として出力する。
このような手順で実行順序推定部６は推定実行順序６１を取得・出力する。

＜実行順序検証部＞
図１７は本発明における実行順序検証部７が行う処理フローの概要を示した図である。
実行順序検証部７は、ステップＳ７１において、実行順序推定部６から推定実行順序６１を取得する。
ステップＳ７２において、ホスト環境１００上でソフトウェア群を実行した際に計測された計測実行順序を取得する。

ステップＳ７３において、推定実行順序６１と計測実行順序が同一であるかを判定し、推定実行順序６１と計測実行順序が同一である場合は処理を終了し、推定実行順序６１と計測実行順序が同一でない場合はステップＳ７４に進む。

ステップＳ７４において、ソフトウェアが正しく実行できなかった可能性があることを出力する。例えばホスト環境１００において、今回実行したソフトウェア群以外のソフトウェアが割り込みを行ったため、実行順序が崩れることが考えられる。このような手順で実行順序検証部７は実行順序を評価する。

上述のように、実施例３におけるシミュレーション方法によれば、ターゲット環境１１０で実行した際のソフトウェア群の実行順序を推定し、ホスト環境１００でソフトウェア群を実際に実行した際の実行順序と比較を行う。ホスト環境１００で実行する際に、ターゲット環境１１０での実行時間を再現しているため、別のソフトウェアの割り込みなどがなければ同じ実行順序となる。そのため、推定した実行順序と実行した実行順序を比較することにより、実行結果が、想定したソフトウェア群のみによるものかどうかを判定することが可能となる。

［実施例４］
本発明の実施例４におけるシミュレーション方法について説明する。
実施例４は、実施例３において追加の処理を行う実施例であり、実施例３と異なる点は、さらに仕様評価部８及び機能割り当て部９による処理が行われる点である。仕様評価部８及び機能割り当て部９は、例えばホスト環境１００に搭載された機能部である。仕様評価部８は、推定実行時間４０と機器割り当て情報５０と周期情報６０とソフトウェア仕様書８０と推定実行順序６１と、から、ソフトウェア群の実行が仕様を満たしているかを判定する。機能割り当て部９は、ソフトウェア群の実行が仕様を満たしていない場合に、ソフトウェアの割り当てを実行する。なお、実施例３と同様の構成については、同一の符号を付してその説明を省略する。

＜シミュレーション方法の概要＞
図１８は実施例４におけるシミュレーション方法の概要を示した図である。
仕様評価部８には、例えば推定実行時間４０と機器割り当て情報５０と周期情報６０とソフトウェア仕様書８０と推定実行順序６１と、が入力される。ソフトウェア仕様書８０は、例えばホスト環境１００に搭載されていてもよいし、外部から手動で入力することによって与えてもよい。

＜ソフトウェア仕様書＞
図１９は本発明におけるソフトウェア仕様書８０の例を示した図である。
例えば、ソフトウェアＡの実行を開始してからソフトウェアＤの実行が完了するまでに要する時間が１００ｍｓ以下であるという仕様や、ＣＰＵ負荷が９０％未満であるという仕様が記載されている。

＜仕様評価部＞
図２０は本発明における仕様評価部８の処理フロー概要を示した図である。
仕様評価部８は、ステップＳ８１において、ターゲット上実行時間推定部４から推定実行時間４０を取得する。
ステップＳ８２において、機器割り当て情報５０を取得する。
ステップＳ８３において、周期情報６０を取得する。
ステップＳ８４において、ソフトウェア仕様書８０を取得する。
ステップＳ８５において、実行順序推定部６から推定実行順序６１を取得する。

また仕様評価部８は、ステップＳ８６において、ハイパーピリオドを算出する。ハイパーピリオドとは、それぞれの機器において動作しているソフトウェアの実行周期の最小公倍数のことを言う。それぞれの機器において動作しているソフトウェアは機器割り当て情報５０（図１０参照）に基づいてわかる。また、周期情報６０（図１５参照）に基づき、それぞれの機器において動作しているソフトウェアの実行周期がわかる。すなわち、例えば図１０に基づくと、マイコンＡで動作しているソフトウェアはソフトウェアＡとソフトウェアＣである。図１５に基づくと、ソフトウェアＡは５０ｍｓ周期でソフトウェアＣは１００ｍｓ周期であるため、この最小公倍数である１００ｍｓがハイパーピリオドとなる。

ステップＳ８７において、ソフトウェアの実行に関する仕様が存在しているかを判定し、仕様が存在している場合にはステップＳ８８に進み、仕様が存在しない場合は処理を終了する。
ステップＳ８８において、ＣＰＵ利用率を算出する。ＣＰＵ利用率はΣ｛（推定実行時間／実行周期）＊１００｝で算出することができる。

ステップＳ８９において、ソフトウェアの実行が仕様を満たしているかを判定し、仕様を満たしている場合はステップＳ８Ｃに進み、仕様を満たしていない場合はステップＳ８Ａに進む。例えば図１９のＣＰＵ利用率に関して判定する場合、ステップＳ８８で求めたＣＰＵ利用率が９０％未満であるかを判定すればよい。レイテンシ制約に関して判定する場合、推定実行順序６１と推定実行時間４０から実行が完了するまでの時間が算出できるため、その時間が仕様を満たしているかを判定すればよい。

ステップＳ８９で仕様を満たしていないと判定された場合、ステップＳ８Ａにおいて、機能割り当て部９で機能の割り当てを行う。この機能の割り当てについては図２１を用いて後述する。
ステップＳ８Ｂにおいて、機能の割り当てを行った結果、仕様を満たす割り当てが存在するかを判定し、仕様を満たす割り当てが存在する場合はステップＳ８Ｃに進み、仕様を満たす割り当てが存在しない場合はステップＳ８Ｄに進む。

ステップＳ８Ｃにおいて、次の仕様に処理を移し、ステップＳ８７に戻り前記処理を継続する。
ステップＳ８Ｄにおいて、割り当てエラーを出力する。機能の割り当てによっては仕様を満たすことができないため、例えばソフトウェアの再開発や仕様する機器の見直しが必要となる。
このような手順で仕様評価部８は仕様を満たしているかを判定し、仕様を満たしていない場合は機能割り当てを試みる。機能割り当てを実行しても仕様を満たさない場合は割り当てエラーを出力する。

＜機能割り当て部＞
図２１は本発明における機能割り当て部９が行う処理フローの概要を示した図である。
機能割り当て部９は、ステップＳ９１において、実行していない組み合わせが存在するかを判定し、実行していない組み合わせが存在する場合はステップＳ９２に進み、実行していない組み合わせが存在しない場合は処理を終了する。なお、本実施例における組み合わせとは、機器割り当て情報５０に記載されているソフトウェアと機器の組み合わせのことである。すなわち、図１０に示す、ソフトウェアと、当該ソフトウェアを実行する機器との組み合わせのことである。

ステップＳ９２において、新しい組み合わせにおけるスケジューリング、すなわちソフトウェアを実行する順序の設定を行う。
ステップＳ９３において、新しい組み合わせによるソフトウェアの実行が仕様を満たしているかを判定し、仕様を満たしている場合はステップＳ９４に進み、仕様を満たしていない場合はステップＳ９１に戻る。
ステップＳ９４において、仕様を満たした割り当て情報を保存する。
このような手順で機能割り当て部９は、仕様を満たす機能割り当てが存在するかを判定する。

実施例４におけるシミュレーション方法によれば、新規ソフトウェア１２を含むソフトウェア群の実行が仕様を満たしているかを判定し、満たしていない場合においても機能の割り当てによって仕様を満たすことができるかを判定することが可能となる。

以上、実施例１から実施例４に関して説明したが、これらの内２つ以上の実施例を組み合わせてシミュレーションを行ってもよい。

＜各実施例の作用効果のまとめ＞
実施例１におけるシミュレーション方法によれば、ホスト環境１００で新規ソフトウェア１２を実行した際の新規ソフトウェアホスト特徴量１３を実行時間推定モデル３０に入力することで、新規ソフトウェア１２をターゲット環境１１０に移植することなく、新規ソフトウェア１２をターゲット環境１１０上で実行した際の最悪実行時間を推定することができる。そして、推定実行時間４０に基づいてホスト環境１００上で新規ソフトウェア１２を実行することで、高精度にターゲット環境１１０を模擬して検証できるため、ホスト環境１００で開発しているソフトウェアをシームレスにターゲット環境１１０へ移植することが可能となる。

実施例２におけるシミュレーション方法によれば、ホスト環境１００で新規ソフトウェア１２を実行する際に、機器間調整係数に基づいてターゲット環境１１０上で実行した際の通信タイミングとなるように調整することで、ソフトウェアを実行する際のデータの生成タイミングを再現することが可能となる。

実施例３におけるシミュレーション方法によれば、ホスト環境１００で新規ソフトウェア１２を含むソフトウェア群を実行する際に、ターゲット環境１１０での実行時間を再現しているため、別のソフトウェアの割り込みなどがなければ同じ実行順序となる。そのため、推定した実行順序と実行した実行順序を比較することにより、ホスト環境１００上での実行結果が、実行しているソフトウェア以外の影響を受けたかどうかを判定することが可能となる。

実施例４におけるシミュレーション方法によれば、新規ソフトウェア１２を含むソフトウェア群の実行が仕様を満たしているかを判定し、満たしていない場合においても機能の割り当てによって仕様を満たすことができるかを判定することが可能となる。

以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明の一実施例に係るシミュレーション方法は、第１のソフトウェアをホスト環境上において実行することによって得られる第１のホスト特徴量を抽出し、第１のソフトウェアをターゲット環境上において実行することによって、ターゲット環境上において第１のソフトウェアを実行するのに要するターゲット実行時間を算出し、第１のホスト特徴量とターゲット実行時間とに基づいて、ホスト環境とターゲット環境との性能差を算出し、第２のソフトウェアをホスト環境上において実行することによって得られる第２のホスト特徴量を抽出し、第２のホスト特徴量と性能差とに基づいて、第２のソフトウェアをターゲット環境上で実行するのに要する時間を推定する。

上記構成により、ソフトウェアを開発するホスト環境上で高精度にターゲット環境が再現される。すなわち、ホスト環境上にターゲット環境が模擬されることになる。従って、実際にターゲット環境にソフトウェアを移植しなくても、ターゲット環境上においてソフトウェアが正常に実行できるか否かを検証することが可能になり、ソフトウェアの開発効率が向上する。

（２）推定した時間に基づいて、前記ホスト環境上において前記第２のソフトウェアを実行する実行時間を調整する。これにより、ホスト環境とターゲット環境との性能差を補填することが可能になり、より高精度にターゲット環境を模擬できる。

（３）ターゲット環境上におけるデータの送受信タイミングに関する機器間調整係数を取得し、前記ホスト環境上において第２のソフトウェアを実行する際に、前記機器間調整係数に基づいて、データの送受信タイミングを調整する。これにより、ホスト環境上で新規ソフトウェア１２を実行する際に、機器間調整係数に基づいてターゲット環境上で実行した際の通信タイミングとなるように調整することが可能になるため、ソフトウェアを実行する際のデータの生成タイミングを同期させることが可能になる。

（４）前記ターゲット実行時間と、前記第２のソフトウェアに関して推定した前記ターゲット環境上における実行時間と、前記第１のソフトウェア及び前記第２のソフトウェアそれぞれの周期情報と、に基づいて、ターゲット環境上における前記第１のソフトウェアと前記第２のソフトウェアの実行順序を推定する。これにより、新規ソフトウェアを含むソフトウェア群をターゲット環境上において実行した際の実行順序が推定され、当該実行順序に従ってソフトウェア群を実行した際の実行結果を予測することが可能になる。

（５）推定した実行順序と、前記ホスト環境上において前記第１のソフトウェア及び前記第２のソフトウェアを実行した際の実行順序とを比較することで、前記ホスト環境上で前記第２のソフトウェアが正しく実行できたかを検証する。これにより、ホスト環境上に他のソフトウェアによる割込み処理が発生する等、推定した実行順序による新規ソフトウェアの実行が正しく行われない場合等を評価できるため、実行順序を再設定すること等が可能になる。

（６）第１のソフトウェア及び第２のソフトウェアを実行可能な機器が複数存在し、推定した実行順序による前記第１のソフトウェア及び前記第２のソフトウェアの実行と、予め定められた仕様とを比較し、当該実行順序によるソフトウェアの実行が前記仕様を満たさない場合には、前記第１のソフトウェアまたは前記第２のソフトウェアの少なくとも一方を実行する機器を変更する。これにより、新規ソフトウェア１２を含むソフトウェア群の実行が仕様を満たしているかを判定し、満たしていない場合においても、機能の再割り当てを行うことによって仕様を満たすことができるか否かを判定することが可能となる。

（７）第１のホスト特徴量及び第２のホスト特徴量は少なくともソフトウェアの実行時間を含む。これにより、ホスト環境とターゲット環境との性能差を、ソフトウェアの実行時間を用いて算出することが可能になり、ソフトウェアを開発するホスト環境上においてより高精度にターゲット環境を再現することが可能になる。

なお、本発明は、上記の実施例に限定されるものではなく、様々な変形が可能である。例えば、上記の実施例は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備える態様に限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能である。また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、削除したり、他の構成を追加・置換したりすることが可能である。

１ ホスト特徴量取得部、２ ターゲット実行時間取得部、３ 実行時間推定モデル作成部、４ ターゲット上実行時間推定部、５ ソフトウェア実行管理部、６ 実行順序推定部、７ 実行順序検証部、８ 仕様評価部、９ 機能割り当て部、１０ 既存ソフトウェア（第１のソフトウェア）、１１ ホスト特徴量（第１の特徴量）、１２ 新規ソフトウェア（第２のソフトウェア）、１３ 新規ソフトウェアホスト特徴量（第２の特徴量）、２０ ターゲット実行時間、３０ 実行時間推定モデル、４０ 推定実行時間、５０ 機器割り当て情報、５１ データフロー情報、５２ 機器間調整係数情報、６０ 周期情報、６１ 推定実行順序、８０ ソフトウェア仕様書、１００ ホスト環境、１１０ ターゲット環境

Claims (7)

1. 第１のソフトウェアをホスト環境上において実行することによって得られる第１のホスト特徴量を抽出し、
   前記第１のソフトウェアをターゲット環境上において実行することによって、前記ターゲット環境上において前記第１のソフトウェアを実行するのに要するターゲット実行時間を算出し、
   前記第１のホスト特徴量と前記ターゲット実行時間とに基づいて、前記ホスト環境と前記ターゲット環境との性能差を算出し、
   第２のソフトウェアを前記ホスト環境上において実行することによって得られる第２のホスト特徴量を抽出し、
   前記第２のホスト特徴量と前記性能差とに基づいて、前記第２のソフトウェアを前記ターゲット環境上で実行するのに要する時間を推定する、
   ことを特徴とするシミュレーション方法。
2. 請求項１に記載のシミュレーション方法であって、
   前記推定した時間に基づいて、前記ホスト環境上において前記第２のソフトウェアを実行する実行時間を調整する、
   ことを特徴とするシミュレーション方法。
3. 請求項１に記載のシミュレーション方法であって、
   前記ターゲット環境上におけるデータの送受信タイミングに関する機器間調整係数を取得し、
   前記ホスト環境上において前記第２のソフトウェアを実行する際に、前記機器間調整係数に基づいて、データの送受信タイミングを調整する、
   ことを特徴とするシミュレーション方法。
4. 請求項１に記載のシミュレーション方法であって、
   前記ターゲット実行時間と、前記第２のソフトウェアに関して推定した前記ターゲット環境上における実行時間と、前記第１のソフトウェア及び前記第２のソフトウェアそれぞれの周期情報と、に基づいて、前記ターゲット環境上における前記第１のソフトウェアと前記第２のソフトウェアの実行順序を推定する、
   ことを特徴とするシミュレーション方法。
5. 請求項４に記載のシミュレーション方法であって、
   前記推定した実行順序と、前記ホスト環境上において前記第１のソフトウェア及び前記第２のソフトウェアを実行した際の実行順序とを比較することで、前記ホスト環境上で前記第２のソフトウェアが正しく実行できたかを検証する、
   ことを特徴とするシミュレーション方法。
6. 請求項４に記載のシミュレーション方法であって、
   前記第１のソフトウェア及び前記第２のソフトウェアを実行可能な機器が複数存在し、
   前記推定した実行順序による前記第１のソフトウェア及び前記第２のソフトウェアの実行と、予め定められた仕様とを比較し、当該実行順序によるソフトウェアの実行が前記仕様を満たさない場合には、前記第１のソフトウェアまたは前記第２のソフトウェアの少なくとも一方を実行する機器を変更する、
   ことを特徴とするシミュレーション方法。
7. 請求項１に記載のシミュレーション方法であって、
   前記第１のホスト特徴量及び前記第２のホスト特徴量は少なくともソフトウェアの実行時間を含む、
   ことを特徴とするシミュレーション方法。

Images