(57)【要約】【課題】検証コードの有無がコード量や制御系システムの時間的なふるまいに与える影響を小さくすることができるプログラムの検証装置を提供すること。【解決手段】ＣＰＵ５０によるタスクの実行時間を検証する検証装置において、ＣＰＵ５０が実行するタスクのタスクコードと、タスクコードの直前に記述されたタイマ１５をスタートさせる第１の命令と、タスクコードの後に記述された、タイマ１５をストップさせる第２の命令と、が記述されたプログラムを記憶する記憶手段１０と、第１の命令のみを１つ実行しただけでタイマ１５をスタートさせる手段１２と、第２の命令を１つ実行しただけでタイマ１５をストップさせ実行時間を測定すると共に、複数回のタスクの実行により得られた複数の前記実行時間に統計処理を施す手段１７、１５、１８、１９、１４と、を有することを特徴とする。【選択図】図１
2010160716.tif 000002
【特許請求の範囲】
【請求項１】
ＣＰＵによるタスクの実行時間を検証する検証装置において、
前記ＣＰＵが実行する前記タスクのタスクコードと、前記タスクコードの直前に記述されたタイマをスタートさせる第１の命令と、前記タスクコードの後に記述されたタイマをストップさせる第２の命令と、が記述されたプログラムを記憶する記憶手段と、
前記第１の命令を１つ実行しただけでタイマをスタートさせる手段と、
前記第２の命令を１つ実行しただけでタイマをストップさせ前記実行時間を測定すると共に、複数回の前記タスクの実行により得られた複数の前記実行時間に統計処理を施す手段と、
を有することを特徴とする検証装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、タスクが設計通りに実行されるかを検証する検証装置に関し、特に、タスクの実行時間を測定する検証装置に関する。
【背景技術】
【０００２】
制御系システムは、タスクの実行タイミングに非常に厳しい制約が課される。例えば、制御系システムがプログラムのフローチャートどおりに動いても、タスクの実行タイミングが許容範囲を超えてずれると期待通りに作動しない。このため、タスクが設計通りに実行されるかどうかを検証しながら開発が進められることが多い（例えば、特許文献１参照。）。特許文献１には、割込みの発生のタイミングが制御系システムの動作時間に与える影響を検証する検証プログラムを、ＣＰＵの命令実行時間を消費することなく実行することで、検証プログラムがタスクの実行時間に与える影響を排除して制御系システムを検証する検証装置が記載されている。
【０００３】
しかしながら、特許文献１記載の検証装置では、割込み試験装置をＣＰＵとは別に実装する必要があるためコスト増となるという問題がある。また、割込みが制御系システムの動作時間に与える影響しか検証できない。
【０００４】
ところで、タスクの実行タイミングが設計上の仕様を満たすかどうかをタイマを利用して検証する方法が知られている。この方法は、制御系システムに、タスクの実行時間を測定する検証用の検証コードを記述しておき、制御系システムの実行と共にタスクの実行時間を厳密に測定するものである。実行時間の測定結果を記録しておくことで、設計上の仕様を満たすかどうか、満たすのであれば仕様に対しどのくらい余裕があるかを検証することができる。
【０００５】
図１は、従来の検証コードの一例を示す図である。この検証コードには、例えば割込み要因の発生による割り込みに対応した「Timing  Critical  job」タスクの実行時間を測定する手順が記述されている。
【０００６】
「Timing  Critical  job」タスクの実行に先立ち、「Timer_inst（）」で新しくタイマのインスタンスを作成し、「Timer_start（）」でタイマをスタートする。タイマをスタートすると「Timing  Critical  job」タスクが実行される。
【０００７】
「Timing  Critical  job」タスクが終了すると、「Timer_stop（）」によりタイマがストップされる。実行時間はメモリに記憶しておく。ここで、制御系システムでは同じタスクが繰り返し実行されることがあるが、同じタスクであってもI/O待ちや他のタスクの実行状況等に応じて実行時間は完全に同じにはならない。このため、検証コードにより「Timing  Critical  job」タスクの実行の度に実行時間を上書きすることなく記憶しておく。
【０００８】
そして、検証コードの実行により実行時間の統計データが算出される。すなわち「Calc_min()」により、複数ある実行時間のうち最小の実行時間が決定され、「Calc_max()」により、複数ある実行時間のうち最大の実行時間が決定され、「Calc_average()」により、複数ある実行時間の平均値が算出される。また、実行時間が仕様を満たしているか否かを判定するため、「Check_dedline()」により、例えば最大の実行時間と最大許容時間との差を算出する。
【０００９】
このように、検証コードをタスクのプログラムに一体に記述することで、制御系システムのプログラムを別のハードウェア上に実装した際にも、タスクの実行時間が仕様を満たしているか否かを容易に検証できる。
【特許文献１】特開平０６−０１９７５２号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかしながら、検証コードは実際の製品に搭載された際には不要となる。このため、検証コードをプログラムと一体に記述したまま製品を出荷することは、プログラムの肥大化やパフォーマンスの劣化をもたらすことになっている。
【００１１】
したがって、プログラムから検証コードを削除して製品を出荷することが望ましいが、検証コードを削除すると制御系システム全体の時間的なふるまいも変わってしまう。例えば、図１に示すようにコンパイル型のプログラムはオブジェクトコードにコンパイルされてからＣＰＵで実行される。「Timer_inst（）」は「Timer_inst0x2123」と「Timer_inst0x2124」のオブジェクトコードに、「Timer_start（）」は「Timer_start0x1234」と「Timer_start0x1235」のオブジェクトコードにコンパイルされている。同様に、「Timer_stop（）」は「Timer_stop0x5892」と「Timer_stop0x5893」に、「Calc_min()」は「Calc_min0x7278」と「Calc_min0x7279」に、「Calc_max()」は「Calc_max0x5290」と「Calc_max0x5291」に、「Calc_average()」は「Calc_average0x0821」と「Calc_average0x822」に、「Check_dedline()」は「Check_dedline0x2122」と「Check_dedline0x2123」に、それぞれコンパイルされている。なお、数値「0x・・・・」はそのオブジェクトコードが記憶されているメモリのアドレスを示す。
【００１２】
このように、検証コードが１命令でもオブジェクトコードは複数命令に渡ったり、1命令のオブジェクトコードの実行にも命令によっては複数クロックを消費するなど、実行時間を測定するためのオブジェクトコードの実行には比較的長い時間がかかっている。実行時間の測定のため、制御系システムの時間的な振るふるまいが変わると「Timing  Critical  job」タスクの実行時間にも影響を与えるので、仕様を満たしていることを保証できない。このため、従来は、検証コードをプログラムに記述したまま製品を出荷していた。
【００１３】
すなわち、従来は、検証コードの有無がコード量や制御系システムの時間的ふるまいに与える影響が大きいため、そのままでは削除することも実装したままとすることも適当でないという問題があった。
【００１４】
本発明は、上記課題に鑑み、検証コードの有無がコード量や制御系システムの時間的なふるまいに与える影響を小さくすることができるプログラムの検証装置を提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記課題に鑑み、本発明は、ＣＰＵによるタスクの実行時間を検証する検証装置において、ＣＰＵが実行するタスクのタスクコードと、タスクコードの直前に記述されたタイマをスタートさせる第１の命令と、タスクコードの後に記述されたタイマをストップさせる第２の命令と、が記述されたプログラムを記憶する記憶手段と、第１の命令を１つ実行しただけでタイマをスタートさせる手段と、第２の命令を１つ実行しただけでタイマをストップさせ実行時間を測定すると共に、複数回の前記タスクの実行により得られた複数の実行時間に統計処理を施す手段と、を有することを特徴とする。
【発明の効果】
【００１６】
検証コードの有無がコード量や制御系システムの時間的なふるまいに与える影響を小さくすることができるプログラムの検証装置を提供することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を実施するための最良の形態について図面を参照しながら説明する。
図２は、本実施形態の検証装置１００による「Timing  Critical  job」タスクの実行時間の測定を模式的に説明する図の一例である。本実施形態の検証装置１００は、次のような特徴を備える。
（１）ソフトウェアで測定していた実行時間の測定と統計処理をＣＰＵ５０が実行する。
（２）検証コードには、タイマのスタートを１命令で、統計処理を1命令で、それぞれ記述する。
【００１８】
例えば、「Timer_inst_start()」がタイマのスタートをＣＰＵ５０に実行させる命令で、「Timer_stop_calc()」がタイマをストップさせ統計処理をＣＰＵ５０に実行させる命令である。すなわち、ＣＰＵ５０は「Timer_inst_start()」を実行するとタイマをスタートさせ、「Timer_stop_calc()」を実行すると一連の統計処理を行う。それぞれ１命令なので、コード量や制御系システムの時間的ふるまいに与える影響は誤差として無視できる範囲である。このため、検証コードを含むプログラムをそのまま実際の製品に搭載しても、プログラムの肥大化やパフォーマンスの劣化をもたらすことがない。
【００１９】
なお、実行時間や統計処理の結果はＣＰＵ５０のメモリに記憶しておく。実行時間や統計処理の結果は、ＪＴＡＧ（Joint  Test  Action  Group）ツール３０等を利用してＣＰＵ５０のメモリから読み出すことができるので、実行時間や統計処理の結果を読み出すためのコードを記述しておく必要はない。
【００２０】
また、「１命令」とはオブジェクトコードにコンパイルされた際に、例えば１回の命令フェッチで読み出される１つの命令である。「オペコード、オペランド０，オペランド１…」のオブジェクトコードの場合，１つのオペコードが本実施形態の「１命令」に相当する。オペランドを有しているか否かは問わない。
【００２１】
図３は検証コードを含むプログラムの記述例とオブジェクトコードの一例を示す。図３（ａ）に示すように、実行タイミングに厳しい制約が課されるタスクのプログラムの冒頭に「Timer_inst_start()」の１命令が、タスクの末尾に「Timer_stop_calc()」の一命令が記述されている。コンパイラがプログラムをコンパイルすることで、図３（ｂ）に示すオブジェクトコードが得られる。このオブジェクトコードはＣＰＵ５０に接続されたＥＥＰＲＯＭ（Electrically  Erasable  and  Programmable  Read  Only  Memory）１０に記憶される。
【００２２】
プログラムの１命令「Timer_inst_start()」が、１命令のまま「Timer_inst_start()0x1111」というオブジェクトコードにコンパイルされており、プログラムの１命令「Timer_stop_calc()」が、１命令のまま「Timer_stop_calc()0x2222」というオブジェクトコードにコンパイルされている。このようなオブジェクトコードは、ＣＰＵ５０の命令セットに対応したものであり、コンパイラ及びＣＰＵ５０が１命令による実行時間の検証に対応していることになる。なお、数値「0x・・・・」はそのオブジェクトコードが記憶されているメモリのアドレスを示す。
【００２３】
図４は、本実施形態の検証装置１００の概略構成図の一例を示す。検証装置１００はＣＰＵ５０とＥＥＰＲＯＭ１０に記憶された検証コードを実体としている。このＣＰＵ５０は検証が完了すると例えば車載されるＥＣＵ（Electronic  Control  Unit）に搭載される。本実施形態の検証方法は制御系システムに好適であるため、例えばエンジンＥＣＵ、パワートレイン系ＥＣＵ又はブレーキＥＣＵ等に適用される。なお、ＣＰＵ５０やＥＥＰＲＯＭ１０の他、ＲＡＭ、ＲＯＭ、ＡＳＩＣ（Application  Specific  Integrated  Circuit）及び入出力端子等を備える。
【００２４】
ＣＰＵ５０は命令レジスタに記憶された「Timer_inst_start()0x1111」をフェッチしてデコーダ１１で解読して、タイマスタート回路１２にタイマ１５をスタートさせる信号を出力する。タイマスタート回路１２はクロック信号をカウントして時間を測定するタイマ１５をスタートさせる。初期化処理は必要に応じて実行される。また、タイマスタート回路１２はカウンタ回路１３に信号を出力する。カウンタ回路１３は信号を受信する毎にカウントアップする回路で、「Timing  Critical  job」タスクの実行回数をカウントする。この後、ＣＰＵ５０は「Timing  Critical  job」タスクを実行する。
【００２５】
「Timing  Critical  job」タスクが終了すると、ＣＰＵ５０は命令レジスタに記憶された「Timer_stop_calc()0x2222」を読み出しデコーダ１１で解読して、タイマストップ回路１７にタイマ１５をストップさせる信号を出力する。タイマ１５がストップした時のタイマ１５の値が実行時間である。また、ＣＰＵ５０が「Timer_stop_calc()0x2222」を実行することで、以下の一連の処理が実行される。
【００２６】
タイマ１５のストップ後、タイマ１５が測定した実行時間は比較回路１８、比較回路１９及び合計加算回路１６に出力される。比較回路１８はタイマ１５が測定した実行時間と記憶しているｍｉｎ値を比較して、実行時間の方が小さい場合のみ、実行時間を新たにｍｉｎ値に置き換える。こうすることで、比較回路１８には常に最小の実行時間が記憶された状態となる。
【００２７】
比較回路１９はタイマ１５が測定した実行時間と記憶しているｍａｘ値を比較して、実行時間の方が小さい場合のみ、実行時間を新たにｍａｘ値に置き換える。こうすることで、比較回路１９には常に最大の実行時間が記憶された状態となる。
【００２８】
また、合計加算回路１６は、タイマ１５がストップする毎に実行時間を累積する回路である。合計加算回路１６には、過去の実行時間が全て累積された累積時間が記憶される。合計加算回路１６は、累積時間を算出したタイミングで平均算出回路１４に累積時間を出力する。
【００２９】
平均算出回路１４は、累積時間が入力されるとカウンタ回路１３から実行回数を読み出し、所定の演算（除算）を施して実行時間の平均値を算出する。平均算出回路１４は最新の平均値を記憶した状態となる。また、平均算出回路１４は平均値を算出したタイミングで平均値を比較回路２１に出力する。
【００３０】
比較回路２１は、予め定められた最大許容時間を記憶している。比較回路２１は最大許容時間と平均値の差を算出して記憶する。なお、最大許容時間はＪＴＡＧツール３０により検証前に書き込まれている。また、比較回路２１は、平均値と最大許容時間との差でなく、ｍｉｎ値又はｍａｘ値との差を算出してもよい。
【００３１】
そして、プログラムの実行が終了すると、ユーザはＪＴＡＧツール３０を用いてＣＰＵ５０から検証結果を読み出す。すなわち、比較回路１８からｍｉｎ値を、比較回路１９からｍａｘ値を、平均算出回路１４から平均値を、比較回路２１から最大許容時間と平均値の差を、それぞれ読み出す。
【００３２】
したがって、タイマ１５のストップから数クロック程度で最大許容時間と平均値の差までを算出できるので、プログラムが検証コードを含んだまま製品に実装されても制御系システムの時間的なふるまいを変えるおそれがない。また、タイマ１５のスタートに１命令、統計処理に１命令のコード量なので、コードを肥大化させることもない。
【００３３】
なお、図４では検証コードの実行手段をハードウェアとして実装したが、複数のマイクロ命令から成るマイクロプログラムを実行することで、一連の処理を実行してもよい。この場合、タイマ１５が測定した実行時間を「Timer_stop_calc()0x2222」が実行される毎に記憶しておく。そして、マイクロプログラムにより、ｍｉｎ値、ｍａｘ値、平均値、及び、平均値と最大許容時間との差を算出する。算出結果はそれぞれレジスタに記憶しておく。
【００３４】
ところで、本実施形態では「Timing  Critical  job」タスクを１つであるかのように説明したが、実際には１つの制御系システムに「Timing  Critical  job」タスクは複数あることが多い。この場合、タイマ１５をスタートする１命令と、統計処理の１命令にそれぞれオペランドとしてそれぞれIDを記述することで、複数の「Timing  Critical  job」タスクそれぞれの実行時間の測定と統計処理が可能となる。
「Timer_inst_start()  ID」
「Timer_stop_calc()  ID」
IDは0〜0xffffの有限個とするが、実際には１〜３２個程度で十分である。
また、オペランドとしてのIDとＣＰＵ５０側の実装部のハードウェアID(以下、HWIDという)をテーブルで対応づけておく。
ID０  →  HWID０
ID１  →  HWID１
ID２  →  HWID２
ID３  →  disable
ID４  →  disable
ID５  →  disable
ID６  →  HWID３
こうすることで、ＣＰＵ５０は「Timer_inst_start()  ID」や「Timer_stop_calc()  ID」を実行する際に、どの実装部を利用すべきか判定できる。このようなテーブルは、例えばＥＥＰＲＯＭ１０に記憶され、ＪＴＡＧツール３０により必要に応じて動的に修正・追加できる。なお、初期状態では全ての対応関係が「disable」である。「Timer_inst_start()  ID」又は「Timer_stop_calc()  ID」が「disable」ＩＤを指定した場合、ＣＰＵ５０はＮＯＰ（No  Operation）として処理する（何も実行しない）。
【図面の簡単な説明】
【００３５】
【図１】従来の検証コードの一例を示す図である。
【図２】検証装置による「Timing  Critical  job」タスクの実行時間の測定を模式的に説明する図の一例である。
【図３】検証コードを含むプログラムの記述例とオブジェクトコードの一例を示す図である。
【図４】検証装置の概略構成図の一例である。
【符号の説明】
【００３６】
１０    ＥＥＰＲＯＭ
１５    タイマ
３０    ＪＴＡＧツール
５０    ＣＰＵ
１００  検証装置
【図１】
2010160716.tif 000003
【図２】
2010160716.tif 000004
【図３】
2010160716.tif 000005
【図４】
2010160716.tif 000006