プログラム検査方法
【課題】マルチコアシステムにおける動作試験を短時間かつ正確に実行可能な技術を提供する。
【解決手段】マルチコアシステムにおけるプログラム検査方法は、複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、システム内で複数並列に実行し、あるノードで実行中のプログラムにデバイス競合が発生した場合に、このプログラムの実行を中断するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する。これにより複数の動作試験を並列に実行することで効率的な試験が行えるとともに、各動作試験を単独で実行した場合と同様の結果が得られるので正確な試験が行える。
【解決手段】マルチコアシステムにおけるプログラム検査方法は、複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、システム内で複数並列に実行し、あるノードで実行中のプログラムにデバイス競合が発生した場合に、このプログラムの実行を中断するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する。これにより複数の動作試験を並列に実行することで効率的な試験が行えるとともに、各動作試験を単独で実行した場合と同様の結果が得られるので正確な試験が行える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム検査方法に関し、特に、マルチコアシステムにおいて短時間かつ正確に動作試験を実行可能なプログラム検査方法に関する。
【背景技術】
【０００２】
近年の組み込み機器分野では、低電力化や部品点数の削減による低コスト化への要求に対する対応として、１チップに複数のＣＰＵコアを搭載するマルチコアプロセッサの利用が進められている。マルチコアプロセッサでは、各コアで処理を並列に実行することで高性能化しつつ低電力化を図ることができる。
【０００３】
たとえば車載システムにおいては、車両のエレクトロニクス化に伴う電子制御ユニット（ＥＣＵ）数の増加が問題となっている。そこで、マルチコアプロセッサを利用して、従来いくつかのＥＣＵとして構成されていたものを１つに統合してＥＣＵ数を抑制することが行われている。このような車載システムはマルチコアプロセッサを有する複数のノードから構成されるマルチコア分散処理システムの一例である。
【０００４】
ネットワーク接続された複数のノードから構成されるシステムにおいて、あるノードでソフトウェアの更新・変更をした場合、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定される処理が正常に動作することを確認するための動作試験を行うべきである。マルチコアシステムにおいては、複数の処理を並列に実行できるため、複数の動作試験プログラムを並列して実行することで試験時間を短縮可能である（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−２３６３８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載の技術では、プロセッサ間で共有するデバイスについての考慮がなされていない。動作試験の実行を短時間で行うため複数の試験プログラムを並列に実行する場合は、実際の動作環境では生じないようなデバイス競合が発生する可能性が高まる。デバイス競合が発生してしまうと、試験と実際の動作で環境が異なってしまい正しい試験が行えない。また、デバイスが利用可能となるまで処理が待ち状態となるため、演算資源を有効に利用できず試験時間も長引いてしまう。
【０００７】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、マルチコアプロセッサをノードに採用したマルチコアシステムにおいて、デバイス競合による悪影響を回避して動作試験を短時間かつ正確に実行可能な技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために本発明では、以下の手段または処理によってマルチコアシステムにおいてプログラム検査を行う。
【０００９】
すなわち、本発明は、マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、シス
テム内で複数並列に実行し、
あるノードで実行中のプログラムにデバイス競合が発生した場合に、このプログラムの実行を中断するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する、ことを特徴とする。
【００１０】
このようにデバイス競合時に連携するプログラム全体の動作を中断することで、単独で動作試験を行うのと同様の環境で動作試験を並列実行可能であり、より正確な試験が実現できる。
【００１１】
また、本発明において、ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、その実行可能な動作試験をシステム内で実行することが好ましい。
【００１２】
このように、デバイス競合に伴う動作試験の実行中断により生じた演算資源の空きを利用して別の動作試験を実行することで、演算資源を有効に利用した試験が可能となり、試験の実行時間を短縮することができる。
【００１３】
また、本発明において、実行中のプログラムが正常に動作しているかを監視し、あるノードで実行中のプログラムが正常に動作していない場合に、このプログラムを停止するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する、ことが好ましい。
【００１４】
なお、正常動作とはプログラムが意図された動作を行うことであり、期待する結果と異なる結果が得られた場合にエラーコードを返して終了することなどは正常動作に含まれる。したがって、正常に動作していないとは、プログラムが意図と反して実行を停止してしまう、あるいは実行が停止しているように見える現象を指す。
【００１５】
このように、プログラムが正常に動作していない場合に、連携するプログラム全体の動作を停止することで、演算資源に空きを作ることができる。この演算資源の空きを利用して別の動作試験を実行可能となり、試験の実行時間を短縮することができる。
【００１６】
なお、本発明は、上記処理の少なくとも一部を含むプログラム検査方法として捉えることができる。また、本発明は、このような方法を実現するためのプログラムとして捉えることもできる。また、本発明は、このようなプログラム検査方法を実行するマルチプロセッサシステムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【００１７】
本発明によれば、マルチコアプロセッサをノードに採用したマルチプロセッサシステムにおいて、動作試験を短時間かつ正確に行うことが可能となる。
【図面の簡単な説明】
【００１８】
【図１】図１は本実施形態に係るマルチコアプロセッサシステムの構成を示す図である。
【図２】図２はテストの基本的な流れを示すフローチャートである。
【図３】図３は各テストケースを構成するプログラムを記憶したテーブルの例を示す図である。
【図４】図４は動作試験プログラムのいずれかがデバイスへのアクセスを要求した場合の処理の流れを示すフローチャートである。
【図５】図５は競合していたデバイスが解放され利用可能となった場合の処理の流れを示すフローチャートである。
【図６Ａ】図６Ａは複数の動作試験プログラムが並列して実行されることを説明する図である。
【図６Ｂ】図６Ｂはデバイスへのアクセス競合が発生したときに連携する全てのプログラムの実行が中断されることを説明する図である。
【図６Ｃ】図６Ｃはある動作試験プログラムの実行中断に伴い別の動作試験プログラムが実行されることを説明する図である。
【図７】図７はプログラムのフリーズを監視しフリーズしたプログラムおよび連携するプログラムの実行を停止する処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２０】
＜システムの構成＞
本実施形態に係るマルチコアシステムは、それぞれがマルチコアプロセッサを有する複数のノードから構成される。各ノードでは複数のプログラムが動作可能であり、ノード内またはノード間のプログラムが連携して１つの処理を実行する機能分散型のシステムを構成する。
【００２１】
本実施形態に係るマルチコアシステムは、たとえば、車載システムに適用することができる。安全運転支援を行う車載システムでは、たとえば、センサを用いて前方の障害物を認識し、一定の距離以下になると運転者への警告や減速制御などを行ったり、シートベルトの巻き取りを行ったりする。また、車外カメラから画像を取得し画像認識により人物や障害物を検知し、運転者に注意を促したりする。このように、安全運転支援を行う車載システムでは、多数のカメラやセンサから種々のデータを取得し、これらのデータをリアルタイムで処理することが求められる。そこで、マルチコアシステムを利用することで、各処理を並列に実行することでリアルタイム処理を実現する。
【００２２】
図１は、本実施形態に係るマルチコアシステムの構成を示す図である。図１に示すように、本システムはそれぞれが複数のプロセッサコアを有する複数のノードから構成される。図１では５つのノードＮ１〜Ｎ５が示されているが、ノード数はいくつであっても構わない。これらのノードはネットワーク４０を介して接続されている。
【００２３】
各ノードの構成について説明する。各ノードはハードウェア１０として複数のプロセッサコア（ここでは４つのプロセッサコア１１〜１４）を有する。このようなハードウェア上にスーパーバイザ２０を導入し、その上で複数のオペレーティングシステムを動作させる。スーパーバイザ導入によるアクセスオーバヘッドを小さくし、かつ既存機能への変更をできるだけ小さくするために、インテル社のＶＴ−ｘやＡＭＤ社のＡＭＤ−Ｖなどの仮想化技術を採用してプロセッサレベルで仮想化に対応することが好ましい。
【００２４】
スーパーバイザ２０は、その機能として連携部２１、システム状態監視部２２、デバイス状態管理部２３を有する。連携部２１は、１つのオペレーティングシステムが同一ノードまたは他ノード内の他のオペレーティングシステムとの間で連携を取るための通信を行う。システム状態監視部２２は、ノード内で実行中の動作試験プログラムがフリーズしているかを監視し、必要に応じてプログラムの停止や停止理由の記録などを行う。デバイス状態管理部２３は、各オペレーティングシステムによるデバイスアクセスを管理し、排他的なデバイス利用を実現する。
【００２５】
各オペレーティングシステムは、上記のようなハードウェアが仮想化されたマルチコアプラットフォーム上で並列に動作する。したがって、各オペレーティングシステムが物理デバイスにアクセスする場合には、システム制御部（３１〜３３）を介してスーパーバイ
ザ２０に要求する。
【００２６】
＜プログラムテスト＞
このようなマルチコアシステムにおいては、一部のソフトウェアのみを更新した場合であっても、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定されるあらゆる動作について試験を行うべきである。想定されるテストケースの数が多いので、複数のテストケースを並列に実行することでテスト処理を高速に行う。
【００２７】
図２にテストの基本的な流れを示す。まず、マルチコアシステム内での各ノードの演算資源（プロセッサコア）の使用状況を把握する（Ｓ１０１）。次に、実行可能な動作試験プログラム（テストケース）が存在するか判断する（Ｓ１０２）。なお、各テストケースにおいて連係動作するプログラムの関係は、図３に示すような形式でメモリ上に格納されている。図３においては連携するプログラムがＸ−Ｙ−Ｚの形式で記載されているが、これはノードＸ上のオペレーティングシステムＹ内のプログラムＺを表す。このようにテストケースごとに連携するプログラムが記憶されているので、各テストケースを実行するために必要な演算資源を把握できる。したがって、各ノードでの演算資源の使用状況と比較することで、実行可能なテストケースが存在するか否かを判断できる。
【００２８】
実行可能なテストケースが存在しない場合（Ｓ１０２−ＮＯ）は、ステップＳ１０１へ戻って演算資源の空きができるまで待つ。実行可能なテストケースが存在する場合（Ｓ１０２−ＹＥＳ）には、そのテストケースを実行する（Ｓ１０３）。
【００２９】
次に、全ての動作試験プログラムを実行済みか判断し（Ｓ１０４）、まだ実行すべき動作試験プログラムがある場合（Ｓ１０４−ＮＯ）にはステップＳ１０１へ戻る。このようにすることで、複数の動作試験プログラムを並列に実行可能である。
【００３０】
なお、上記で説明した図２の処理は、本マルチコアシステム内のいずれかのオペレーティングシステム内のプログラムが実行しても良いし、本マルチコアシステムにテスト用のコンピュータを接続して、このコンピュータで実行をしても良い。また、システム内の複数のプロセッサが連携してこの処理を実行しても良い。
【００３１】
＜テストの並列動作における問題＞
このように動作試験プログラムを複数並列して実行する場合、複数のプログラムから同一のデバイスに対するアクセスが発生する可能性が高まる。その場合、アクセス競合が発生したプログラムはデバイスが利用可能になるまで処理を行うことができない。
【００３２】
デバイスへのアクセス競合が発生することで、動作試験プログラムの並列実行が阻害され、テストの効率的な実行が妨げられる。演算資源の乏しいシステムやアクセス競合の発生が少ないシステムでは、デバイスが解放されるまでの待機処理をビジーウェイトによって実現することが多い。したがって、演算資源が有効に利用できず、テストの完了に時間がかかってしまう。
【００３３】
また、１つのテストケースは複数のノードで並列実行される複数のプログラムから構成されるため、あるノードでの処理が中断されることでプログラム間の連携のタイミングが狂ってしまう。この場合、正しい処理結果が得られなかったり、エラーが発生したりしてしまう。
【００３４】
これらの問題は、実際のシステム運用時にはコア間でデバイス競合が発生しないようなシステムで顕著なものとなる。そこで、本発明ではデバイス競合時に、連携する全てプロ
グラムの実行を中断することで、動作試験プログラムが単独動作した場合と同じ環境でのテストを実現する。
【００３５】
＜デバイス競合時の動作＞
まず、図４を参照して動作試験プログラムのいずれかがデバイスへのアクセスを必要とする場合の処理の流れを説明する。
【００３６】
あるプログラムがデバイスへのアクセスを要求する場合、スーパーバイザ２０へデバイス利用のための割り込みを発生させる（Ｓ２０１）。この割り込みにより、デバイス状態管理部２３が割り込みハンドラとして起動する（Ｓ２０２）。デバイス状態管理部２３は、指定されたデバイスが利用中であるか調べる（Ｓ２０３）。デバイスが利用中でなければ（Ｓ２０４−ＮＯ）、割り込み発生元のプログラムがそのデバイスを占有利用する（Ｓ２０５）。この場合は、動作試験プログラムが単独で動作している場合と同様であるので、その他の処理は行わない。
【００３７】
一方、指定されたデバイスが利用中である場合（Ｓ２０４−ＹＥＳ）は、デバイスアクセスを要求したプログラムと連携しているプログラムの実行を中断させるために、連携部２１を介して他ノードの連携部へ中断を要求する（Ｓ２０６）。なお、中断要求を受信したノードでの処理（Ｓ２０９以降）については、後で説明する。
【００３８】
デバイスアクセスを要求した対象プログラムを実行しているノードは、デバイスが利用可能となるまで、そのプログラムの実行を中断させる（Ｓ２０７）。また、同一ノード内の別のオペレーティングシステムで連携して動作しているプログラムが存在する場合には、連携部２１を介して、そのプログラムの実行も中断させる。このように、プログラムの実行を中断させることでコアがアイドルになるので、他に実行すべき動作試験プログラムがあれば実行する（Ｓ２０８）。
【００３９】
次に、ノード間通信を介して他ノードからの中断要求を受信したノードでの処理について説明する。デバイス競合が発生したノードからの中断要求を受信すると（Ｓ２０９）、中断要求を受信したノードで連携部２１が動作する（Ｓ２１０）。連携部２１は、中断要請元のプログラムと連携するプログラムを中断させるために、対象のシステム制御部に対して連携プログラムの中断を通知する（Ｓ２１１）。この通知を受け取ったシステム制御部は、対象のプログラムの実行を中断する（Ｓ２１２）。
【００４０】
このような処理により、動作試験プログラムを構成するいずれかのプログラムでデバイス競合が発生し処理の継続ができなくなった場合に、動作試験プログラムを構成する全ての連携プログラムを、システム内で同時に中断させることができる。また、それによりリソースに空きができた場合に、他の動作試験プログラムを実行できる。
【００４１】
＜デバイス解放時の動作＞
次に、図５を参照して、競合していたデバイスが利用可能となった場合の処理について説明する。デバイスが解放されて利用可能になると（Ｓ３０１）、デバイス状態管理部２３が起動する（Ｓ３０２）。そしてデバイス状態管理部２３が、中断していたプログラムに対応するシステム制御部を動作させる（Ｓ３０３）とともに、他ノードの連携部に中断していたプログラムの実行再開を要求する（Ｓ３０４）。システム制御部は、対象プログラムの実行を再開させる（Ｓ３０５）。
【００４２】
ノード間通信を介して他ノードからの再開要求を受信（Ｓ３０６）したノードでは、この指示を受けてノード内の連携部を動作させる（Ｓ３０７）。連携部は、対象のシステム制御部に対して連携プログラムの実行再開を通知する（Ｓ３０８）。この通知を受けて、
システム制御部は対象プログラムの実行を再開する。
【００４３】
このような処理により、デバイス競合によって実行が中断されていた動作試験プログラムを再開させることができる。なお、デバイスが解放された場合であっても、プロセッサコアに空きがない場合はこの動作試験プログラムを実行できないので、その場合はデバイスとともにプロセッサコアが利用可能となるまで、実行再開を待つ必要がある。
【００４４】
＜動作例＞
上記の処理による、具体的な動作試験プログラムの実行例を、図６Ａ〜６Ｃを参照して説明する。ここでは、各動作試験プログラム（テストケース）が、図３に示すような連携プログラムによって構成されているものとして説明する。
【００４５】
まず、デバイス競合が発生していない状況では、図６Ａに示すようにテストケース１〜３が実行される。たとえば、ノードＮ１では、テストケース１用のプログラム１−１−１，１−３−２、およびテストケース２用のプログラム１−１−２，１−２−１が、並列して実行される。他のノードでも同様に複数のプログラムが並列して実行される。
【００４６】
このように、実際の運用時には１つのケースしか実行されないようなシステムであってもプログラムテスト時には複数のテストケースを並列に実行することで、効率的にテストを実行することができる。
【００４７】
ここで、ノードＮ１でデバイスへのアクセス競合が発生したとする。たとえば図６Ｂに示すように、テストケース１におけるプログラム１−１−１がデバイスを利用中に、テストケース２におけるプログラム１−２−１が同時にそのデバイスにアクセスしようとした場合を考える。この場合、プログラム１−２−１の実行を中断するだけでなく、テストケース２を構成する全てのプログラムの実行を中断する。ノードＮ１内では、ノード内での通信により他のオペレーティングシステム内で実行しているプログラムを中断させる。ノードＮ３など、デバイス競合が発生したノードＮ１以外のノードには、ノード間通信によって連携プログラムの中断を指示する。
【００４８】
このようにテストケース２を構成するプログラムのうちの１つがデバイス競合によって実行できなくなった場合は、テストケース２を構成する全てのプログラムの実行が中断される。
【００４９】
テストケース２を構成する全てのプログラムの実行が中断された場合、プロセッサコアに空きができるため、図６Ｃに示すように実行可能な他のテストケース（ここではケース４）が実行される。
【００５０】
＜プログラム異常時の処理＞
テスト中にはプログラムが予期しない動作を行い処理が停止してしまうことがある。ここでいう処理の停止とはいわゆるフリーズ（ハングアップともいう）のことを指し、期待する結果と違う結果が得られたり、エラーコードを出力して終了する場合などは含まれない。プログラムがフリーズした場合はプロセッサ資源がこのプログラムに割り当てられたままとなり、他のプログラムに割り当てることができなくなってしまう。そのため、フリーズが発生した場合には、そのプログラムを停止させる必要がある。そこでスーパーバイザ２０（システム状態監視部２２）は、動作試験を監視し不具合発生時に、フリーズしたプログラムおよびこれと連携する他のプログラムの実行を停止させる。
【００５１】
図７を参照してシステム状態監視部２２による監視処理を説明する。システム状態監視部２２は定期的に処理を行うものであり、インターバルタイマなどにより割り込みが発生
する（Ｓ４０１）と、割り込みハンドラとしてシステム状態監視部２２が起動する（Ｓ４０２）。起動したシステム状態監視部２２は、自ノード上で実行されている全てのオペレーティングシステムの状態を調査し（Ｓ４０３）、状態が変化しないシステムが存在するか判断する（Ｓ４０４）。状態が変化しないシステムが存在しない場合は、次の割り込みが発生するまでシステム状態監視部を休眠させる（Ｓ４０８）。
【００５２】
状態が変化しないシステムが存在する場合（Ｓ４０４−ＹＥＳ）は、プログラムがフリーズしたと判断し、他ノードで動作している連携プログラムの停止を、他ノードのシステム制御部へ要求する（Ｓ４０５）。また、システム制御部は、フリーズしたプログラムを停止し、停止理由をログとして記録する（Ｓ４０６）。
【００５３】
これにより連携するプログラム全ての実行が停止されるので、プロセッサコアに空きができる。そこで、実行できる動作試験プログラムがある場合にはそれを実行する（Ｓ４０７）。そして、次の割り込みが発生するまでシステム状態監視部を休眠させる（Ｓ４０８）。
【００５４】
このようにフリーズしたプログラムが発生した場合に連携するプログラムを全て停止させることで、プロセッサコアに空きを作り他の動作試験プログラムを実行できる。したがって、プログラムがフリーズした場合であってもテストを効率良く実行することができる。
【００５５】
＜実施形態の作用・効果＞
このように本実施形態におけるプログラムテストでは、実際のシステム運用時には１つの処理（複数のノード間で連携して行う処理）しか行わないシングルスレッド型のシステムであっても、複数のテストケースを並列して実行することで短時間にプログラムテストを実行できる。
【００５６】
また、実際のシステム運用時と同様のシングルスレッド型の動作環境を実現するために、デバイスアクセス競合をトリガとして連携するプログラムを一斉に中断および再開する。テストケースを構成する一部のプログラムのみが中断された場合には、プログラム間の実行タイミングがずれて実際のシステム運用時とは異なる動作となってしまうが、本実施形態によるテスト手法では連携するプログラムを一斉に中断するためこのような実行タイミングのずれなどが発生しなくなる。したがって、実際の動作環境と同様の条件下でテストが実行可能となり正確なテストが実現できる。
【００５７】
また、デバイス競合が発生した場合はそのデバイスが利用可能となるまでテストケースが完了できないため、テストの実行効率が悪くなる。しかし、デバイス競合が発生したテストケースの連携プログラムを全て中断することで、演算資源に空きを作り他のテストケースを実行可能となる。つまり、より効率的にテストプログラムを実行可能である。
【００５８】
また、テストケースを構成する一部のプログラムをフリーズした場合に連携するプログラムを全て停止させることで、他のテストケースを実行可能となる。これにより、プログラムがフリーズして応答しなくなった場合であっても、効率良くテストを実行することができる。
【符号の説明】
【００５９】
Ｎ１〜Ｎ５ ノード
１０ ハードウェア
１１〜１４ プロセッサコア
２０ スーパーバイザ
２１ 連携部
２２ システム状態監視部
２３ デバイス状態管理部
３１〜３３ システム制御部
【技術分野】
【０００１】
本発明は、プログラム検査方法に関し、特に、マルチコアシステムにおいて短時間かつ正確に動作試験を実行可能なプログラム検査方法に関する。
【背景技術】
【０００２】
近年の組み込み機器分野では、低電力化や部品点数の削減による低コスト化への要求に対する対応として、１チップに複数のＣＰＵコアを搭載するマルチコアプロセッサの利用が進められている。マルチコアプロセッサでは、各コアで処理を並列に実行することで高性能化しつつ低電力化を図ることができる。
【０００３】
たとえば車載システムにおいては、車両のエレクトロニクス化に伴う電子制御ユニット（ＥＣＵ）数の増加が問題となっている。そこで、マルチコアプロセッサを利用して、従来いくつかのＥＣＵとして構成されていたものを１つに統合してＥＣＵ数を抑制することが行われている。このような車載システムはマルチコアプロセッサを有する複数のノードから構成されるマルチコア分散処理システムの一例である。
【０００４】
ネットワーク接続された複数のノードから構成されるシステムにおいて、あるノードでソフトウェアの更新・変更をした場合、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定される処理が正常に動作することを確認するための動作試験を行うべきである。マルチコアシステムにおいては、複数の処理を並列に実行できるため、複数の動作試験プログラムを並列して実行することで試験時間を短縮可能である（特許文献１）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０００−２３６３８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１に記載の技術では、プロセッサ間で共有するデバイスについての考慮がなされていない。動作試験の実行を短時間で行うため複数の試験プログラムを並列に実行する場合は、実際の動作環境では生じないようなデバイス競合が発生する可能性が高まる。デバイス競合が発生してしまうと、試験と実際の動作で環境が異なってしまい正しい試験が行えない。また、デバイスが利用可能となるまで処理が待ち状態となるため、演算資源を有効に利用できず試験時間も長引いてしまう。
【０００７】
本発明は上記実情に鑑みてなされたものであって、その目的とするところは、マルチコアプロセッサをノードに採用したマルチコアシステムにおいて、デバイス競合による悪影響を回避して動作試験を短時間かつ正確に実行可能な技術を提供することにある。
【課題を解決するための手段】
【０００８】
上記目的を達成するために本発明では、以下の手段または処理によってマルチコアシステムにおいてプログラム検査を行う。
【０００９】
すなわち、本発明は、マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、シス
テム内で複数並列に実行し、
あるノードで実行中のプログラムにデバイス競合が発生した場合に、このプログラムの実行を中断するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する、ことを特徴とする。
【００１０】
このようにデバイス競合時に連携するプログラム全体の動作を中断することで、単独で動作試験を行うのと同様の環境で動作試験を並列実行可能であり、より正確な試験が実現できる。
【００１１】
また、本発明において、ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、その実行可能な動作試験をシステム内で実行することが好ましい。
【００１２】
このように、デバイス競合に伴う動作試験の実行中断により生じた演算資源の空きを利用して別の動作試験を実行することで、演算資源を有効に利用した試験が可能となり、試験の実行時間を短縮することができる。
【００１３】
また、本発明において、実行中のプログラムが正常に動作しているかを監視し、あるノードで実行中のプログラムが正常に動作していない場合に、このプログラムを停止するとともに、このプログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する、ことが好ましい。
【００１４】
なお、正常動作とはプログラムが意図された動作を行うことであり、期待する結果と異なる結果が得られた場合にエラーコードを返して終了することなどは正常動作に含まれる。したがって、正常に動作していないとは、プログラムが意図と反して実行を停止してしまう、あるいは実行が停止しているように見える現象を指す。
【００１５】
このように、プログラムが正常に動作していない場合に、連携するプログラム全体の動作を停止することで、演算資源に空きを作ることができる。この演算資源の空きを利用して別の動作試験を実行可能となり、試験の実行時間を短縮することができる。
【００１６】
なお、本発明は、上記処理の少なくとも一部を含むプログラム検査方法として捉えることができる。また、本発明は、このような方法を実現するためのプログラムとして捉えることもできる。また、本発明は、このようなプログラム検査方法を実行するマルチプロセッサシステムとして捉えることもできる。上記手段および処理の各々は可能な限り互いに組み合わせて本発明を構成することができる。
【発明の効果】
【００１７】
本発明によれば、マルチコアプロセッサをノードに採用したマルチプロセッサシステムにおいて、動作試験を短時間かつ正確に行うことが可能となる。
【図面の簡単な説明】
【００１８】
【図１】図１は本実施形態に係るマルチコアプロセッサシステムの構成を示す図である。
【図２】図２はテストの基本的な流れを示すフローチャートである。
【図３】図３は各テストケースを構成するプログラムを記憶したテーブルの例を示す図である。
【図４】図４は動作試験プログラムのいずれかがデバイスへのアクセスを要求した場合の処理の流れを示すフローチャートである。
【図５】図５は競合していたデバイスが解放され利用可能となった場合の処理の流れを示すフローチャートである。
【図６Ａ】図６Ａは複数の動作試験プログラムが並列して実行されることを説明する図である。
【図６Ｂ】図６Ｂはデバイスへのアクセス競合が発生したときに連携する全てのプログラムの実行が中断されることを説明する図である。
【図６Ｃ】図６Ｃはある動作試験プログラムの実行中断に伴い別の動作試験プログラムが実行されることを説明する図である。
【図７】図７はプログラムのフリーズを監視しフリーズしたプログラムおよび連携するプログラムの実行を停止する処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１９】
以下に図面を参照して、この発明の好適な実施の形態を例示的に詳しく説明する。
【００２０】
＜システムの構成＞
本実施形態に係るマルチコアシステムは、それぞれがマルチコアプロセッサを有する複数のノードから構成される。各ノードでは複数のプログラムが動作可能であり、ノード内またはノード間のプログラムが連携して１つの処理を実行する機能分散型のシステムを構成する。
【００２１】
本実施形態に係るマルチコアシステムは、たとえば、車載システムに適用することができる。安全運転支援を行う車載システムでは、たとえば、センサを用いて前方の障害物を認識し、一定の距離以下になると運転者への警告や減速制御などを行ったり、シートベルトの巻き取りを行ったりする。また、車外カメラから画像を取得し画像認識により人物や障害物を検知し、運転者に注意を促したりする。このように、安全運転支援を行う車載システムでは、多数のカメラやセンサから種々のデータを取得し、これらのデータをリアルタイムで処理することが求められる。そこで、マルチコアシステムを利用することで、各処理を並列に実行することでリアルタイム処理を実現する。
【００２２】
図１は、本実施形態に係るマルチコアシステムの構成を示す図である。図１に示すように、本システムはそれぞれが複数のプロセッサコアを有する複数のノードから構成される。図１では５つのノードＮ１〜Ｎ５が示されているが、ノード数はいくつであっても構わない。これらのノードはネットワーク４０を介して接続されている。
【００２３】
各ノードの構成について説明する。各ノードはハードウェア１０として複数のプロセッサコア（ここでは４つのプロセッサコア１１〜１４）を有する。このようなハードウェア上にスーパーバイザ２０を導入し、その上で複数のオペレーティングシステムを動作させる。スーパーバイザ導入によるアクセスオーバヘッドを小さくし、かつ既存機能への変更をできるだけ小さくするために、インテル社のＶＴ−ｘやＡＭＤ社のＡＭＤ−Ｖなどの仮想化技術を採用してプロセッサレベルで仮想化に対応することが好ましい。
【００２４】
スーパーバイザ２０は、その機能として連携部２１、システム状態監視部２２、デバイス状態管理部２３を有する。連携部２１は、１つのオペレーティングシステムが同一ノードまたは他ノード内の他のオペレーティングシステムとの間で連携を取るための通信を行う。システム状態監視部２２は、ノード内で実行中の動作試験プログラムがフリーズしているかを監視し、必要に応じてプログラムの停止や停止理由の記録などを行う。デバイス状態管理部２３は、各オペレーティングシステムによるデバイスアクセスを管理し、排他的なデバイス利用を実現する。
【００２５】
各オペレーティングシステムは、上記のようなハードウェアが仮想化されたマルチコアプラットフォーム上で並列に動作する。したがって、各オペレーティングシステムが物理デバイスにアクセスする場合には、システム制御部（３１〜３３）を介してスーパーバイ
ザ２０に要求する。
【００２６】
＜プログラムテスト＞
このようなマルチコアシステムにおいては、一部のソフトウェアのみを更新した場合であっても、それまで動作していた他のノードとの連携が機能しなくなる可能性がある。したがって、想定されるあらゆる動作について試験を行うべきである。想定されるテストケースの数が多いので、複数のテストケースを並列に実行することでテスト処理を高速に行う。
【００２７】
図２にテストの基本的な流れを示す。まず、マルチコアシステム内での各ノードの演算資源（プロセッサコア）の使用状況を把握する（Ｓ１０１）。次に、実行可能な動作試験プログラム（テストケース）が存在するか判断する（Ｓ１０２）。なお、各テストケースにおいて連係動作するプログラムの関係は、図３に示すような形式でメモリ上に格納されている。図３においては連携するプログラムがＸ−Ｙ−Ｚの形式で記載されているが、これはノードＸ上のオペレーティングシステムＹ内のプログラムＺを表す。このようにテストケースごとに連携するプログラムが記憶されているので、各テストケースを実行するために必要な演算資源を把握できる。したがって、各ノードでの演算資源の使用状況と比較することで、実行可能なテストケースが存在するか否かを判断できる。
【００２８】
実行可能なテストケースが存在しない場合（Ｓ１０２−ＮＯ）は、ステップＳ１０１へ戻って演算資源の空きができるまで待つ。実行可能なテストケースが存在する場合（Ｓ１０２−ＹＥＳ）には、そのテストケースを実行する（Ｓ１０３）。
【００２９】
次に、全ての動作試験プログラムを実行済みか判断し（Ｓ１０４）、まだ実行すべき動作試験プログラムがある場合（Ｓ１０４−ＮＯ）にはステップＳ１０１へ戻る。このようにすることで、複数の動作試験プログラムを並列に実行可能である。
【００３０】
なお、上記で説明した図２の処理は、本マルチコアシステム内のいずれかのオペレーティングシステム内のプログラムが実行しても良いし、本マルチコアシステムにテスト用のコンピュータを接続して、このコンピュータで実行をしても良い。また、システム内の複数のプロセッサが連携してこの処理を実行しても良い。
【００３１】
＜テストの並列動作における問題＞
このように動作試験プログラムを複数並列して実行する場合、複数のプログラムから同一のデバイスに対するアクセスが発生する可能性が高まる。その場合、アクセス競合が発生したプログラムはデバイスが利用可能になるまで処理を行うことができない。
【００３２】
デバイスへのアクセス競合が発生することで、動作試験プログラムの並列実行が阻害され、テストの効率的な実行が妨げられる。演算資源の乏しいシステムやアクセス競合の発生が少ないシステムでは、デバイスが解放されるまでの待機処理をビジーウェイトによって実現することが多い。したがって、演算資源が有効に利用できず、テストの完了に時間がかかってしまう。
【００３３】
また、１つのテストケースは複数のノードで並列実行される複数のプログラムから構成されるため、あるノードでの処理が中断されることでプログラム間の連携のタイミングが狂ってしまう。この場合、正しい処理結果が得られなかったり、エラーが発生したりしてしまう。
【００３４】
これらの問題は、実際のシステム運用時にはコア間でデバイス競合が発生しないようなシステムで顕著なものとなる。そこで、本発明ではデバイス競合時に、連携する全てプロ
グラムの実行を中断することで、動作試験プログラムが単独動作した場合と同じ環境でのテストを実現する。
【００３５】
＜デバイス競合時の動作＞
まず、図４を参照して動作試験プログラムのいずれかがデバイスへのアクセスを必要とする場合の処理の流れを説明する。
【００３６】
あるプログラムがデバイスへのアクセスを要求する場合、スーパーバイザ２０へデバイス利用のための割り込みを発生させる（Ｓ２０１）。この割り込みにより、デバイス状態管理部２３が割り込みハンドラとして起動する（Ｓ２０２）。デバイス状態管理部２３は、指定されたデバイスが利用中であるか調べる（Ｓ２０３）。デバイスが利用中でなければ（Ｓ２０４−ＮＯ）、割り込み発生元のプログラムがそのデバイスを占有利用する（Ｓ２０５）。この場合は、動作試験プログラムが単独で動作している場合と同様であるので、その他の処理は行わない。
【００３７】
一方、指定されたデバイスが利用中である場合（Ｓ２０４−ＹＥＳ）は、デバイスアクセスを要求したプログラムと連携しているプログラムの実行を中断させるために、連携部２１を介して他ノードの連携部へ中断を要求する（Ｓ２０６）。なお、中断要求を受信したノードでの処理（Ｓ２０９以降）については、後で説明する。
【００３８】
デバイスアクセスを要求した対象プログラムを実行しているノードは、デバイスが利用可能となるまで、そのプログラムの実行を中断させる（Ｓ２０７）。また、同一ノード内の別のオペレーティングシステムで連携して動作しているプログラムが存在する場合には、連携部２１を介して、そのプログラムの実行も中断させる。このように、プログラムの実行を中断させることでコアがアイドルになるので、他に実行すべき動作試験プログラムがあれば実行する（Ｓ２０８）。
【００３９】
次に、ノード間通信を介して他ノードからの中断要求を受信したノードでの処理について説明する。デバイス競合が発生したノードからの中断要求を受信すると（Ｓ２０９）、中断要求を受信したノードで連携部２１が動作する（Ｓ２１０）。連携部２１は、中断要請元のプログラムと連携するプログラムを中断させるために、対象のシステム制御部に対して連携プログラムの中断を通知する（Ｓ２１１）。この通知を受け取ったシステム制御部は、対象のプログラムの実行を中断する（Ｓ２１２）。
【００４０】
このような処理により、動作試験プログラムを構成するいずれかのプログラムでデバイス競合が発生し処理の継続ができなくなった場合に、動作試験プログラムを構成する全ての連携プログラムを、システム内で同時に中断させることができる。また、それによりリソースに空きができた場合に、他の動作試験プログラムを実行できる。
【００４１】
＜デバイス解放時の動作＞
次に、図５を参照して、競合していたデバイスが利用可能となった場合の処理について説明する。デバイスが解放されて利用可能になると（Ｓ３０１）、デバイス状態管理部２３が起動する（Ｓ３０２）。そしてデバイス状態管理部２３が、中断していたプログラムに対応するシステム制御部を動作させる（Ｓ３０３）とともに、他ノードの連携部に中断していたプログラムの実行再開を要求する（Ｓ３０４）。システム制御部は、対象プログラムの実行を再開させる（Ｓ３０５）。
【００４２】
ノード間通信を介して他ノードからの再開要求を受信（Ｓ３０６）したノードでは、この指示を受けてノード内の連携部を動作させる（Ｓ３０７）。連携部は、対象のシステム制御部に対して連携プログラムの実行再開を通知する（Ｓ３０８）。この通知を受けて、
システム制御部は対象プログラムの実行を再開する。
【００４３】
このような処理により、デバイス競合によって実行が中断されていた動作試験プログラムを再開させることができる。なお、デバイスが解放された場合であっても、プロセッサコアに空きがない場合はこの動作試験プログラムを実行できないので、その場合はデバイスとともにプロセッサコアが利用可能となるまで、実行再開を待つ必要がある。
【００４４】
＜動作例＞
上記の処理による、具体的な動作試験プログラムの実行例を、図６Ａ〜６Ｃを参照して説明する。ここでは、各動作試験プログラム（テストケース）が、図３に示すような連携プログラムによって構成されているものとして説明する。
【００４５】
まず、デバイス競合が発生していない状況では、図６Ａに示すようにテストケース１〜３が実行される。たとえば、ノードＮ１では、テストケース１用のプログラム１−１−１，１−３−２、およびテストケース２用のプログラム１−１−２，１−２−１が、並列して実行される。他のノードでも同様に複数のプログラムが並列して実行される。
【００４６】
このように、実際の運用時には１つのケースしか実行されないようなシステムであってもプログラムテスト時には複数のテストケースを並列に実行することで、効率的にテストを実行することができる。
【００４７】
ここで、ノードＮ１でデバイスへのアクセス競合が発生したとする。たとえば図６Ｂに示すように、テストケース１におけるプログラム１−１−１がデバイスを利用中に、テストケース２におけるプログラム１−２−１が同時にそのデバイスにアクセスしようとした場合を考える。この場合、プログラム１−２−１の実行を中断するだけでなく、テストケース２を構成する全てのプログラムの実行を中断する。ノードＮ１内では、ノード内での通信により他のオペレーティングシステム内で実行しているプログラムを中断させる。ノードＮ３など、デバイス競合が発生したノードＮ１以外のノードには、ノード間通信によって連携プログラムの中断を指示する。
【００４８】
このようにテストケース２を構成するプログラムのうちの１つがデバイス競合によって実行できなくなった場合は、テストケース２を構成する全てのプログラムの実行が中断される。
【００４９】
テストケース２を構成する全てのプログラムの実行が中断された場合、プロセッサコアに空きができるため、図６Ｃに示すように実行可能な他のテストケース（ここではケース４）が実行される。
【００５０】
＜プログラム異常時の処理＞
テスト中にはプログラムが予期しない動作を行い処理が停止してしまうことがある。ここでいう処理の停止とはいわゆるフリーズ（ハングアップともいう）のことを指し、期待する結果と違う結果が得られたり、エラーコードを出力して終了する場合などは含まれない。プログラムがフリーズした場合はプロセッサ資源がこのプログラムに割り当てられたままとなり、他のプログラムに割り当てることができなくなってしまう。そのため、フリーズが発生した場合には、そのプログラムを停止させる必要がある。そこでスーパーバイザ２０（システム状態監視部２２）は、動作試験を監視し不具合発生時に、フリーズしたプログラムおよびこれと連携する他のプログラムの実行を停止させる。
【００５１】
図７を参照してシステム状態監視部２２による監視処理を説明する。システム状態監視部２２は定期的に処理を行うものであり、インターバルタイマなどにより割り込みが発生
する（Ｓ４０１）と、割り込みハンドラとしてシステム状態監視部２２が起動する（Ｓ４０２）。起動したシステム状態監視部２２は、自ノード上で実行されている全てのオペレーティングシステムの状態を調査し（Ｓ４０３）、状態が変化しないシステムが存在するか判断する（Ｓ４０４）。状態が変化しないシステムが存在しない場合は、次の割り込みが発生するまでシステム状態監視部を休眠させる（Ｓ４０８）。
【００５２】
状態が変化しないシステムが存在する場合（Ｓ４０４−ＹＥＳ）は、プログラムがフリーズしたと判断し、他ノードで動作している連携プログラムの停止を、他ノードのシステム制御部へ要求する（Ｓ４０５）。また、システム制御部は、フリーズしたプログラムを停止し、停止理由をログとして記録する（Ｓ４０６）。
【００５３】
これにより連携するプログラム全ての実行が停止されるので、プロセッサコアに空きができる。そこで、実行できる動作試験プログラムがある場合にはそれを実行する（Ｓ４０７）。そして、次の割り込みが発生するまでシステム状態監視部を休眠させる（Ｓ４０８）。
【００５４】
このようにフリーズしたプログラムが発生した場合に連携するプログラムを全て停止させることで、プロセッサコアに空きを作り他の動作試験プログラムを実行できる。したがって、プログラムがフリーズした場合であってもテストを効率良く実行することができる。
【００５５】
＜実施形態の作用・効果＞
このように本実施形態におけるプログラムテストでは、実際のシステム運用時には１つの処理（複数のノード間で連携して行う処理）しか行わないシングルスレッド型のシステムであっても、複数のテストケースを並列して実行することで短時間にプログラムテストを実行できる。
【００５６】
また、実際のシステム運用時と同様のシングルスレッド型の動作環境を実現するために、デバイスアクセス競合をトリガとして連携するプログラムを一斉に中断および再開する。テストケースを構成する一部のプログラムのみが中断された場合には、プログラム間の実行タイミングがずれて実際のシステム運用時とは異なる動作となってしまうが、本実施形態によるテスト手法では連携するプログラムを一斉に中断するためこのような実行タイミングのずれなどが発生しなくなる。したがって、実際の動作環境と同様の条件下でテストが実行可能となり正確なテストが実現できる。
【００５７】
また、デバイス競合が発生した場合はそのデバイスが利用可能となるまでテストケースが完了できないため、テストの実行効率が悪くなる。しかし、デバイス競合が発生したテストケースの連携プログラムを全て中断することで、演算資源に空きを作り他のテストケースを実行可能となる。つまり、より効率的にテストプログラムを実行可能である。
【００５８】
また、テストケースを構成する一部のプログラムをフリーズした場合に連携するプログラムを全て停止させることで、他のテストケースを実行可能となる。これにより、プログラムがフリーズして応答しなくなった場合であっても、効率良くテストを実行することができる。
【符号の説明】
【００５９】
Ｎ１〜Ｎ５ ノード
１０ ハードウェア
１１〜１４ プロセッサコア
２０ スーパーバイザ
２１ 連携部
２２ システム状態監視部
２３ デバイス状態管理部
３１〜３３ システム制御部
【特許請求の範囲】
【請求項１】
マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、当該システム内で複数並列に実行し、
あるノードで実行中のプログラムにデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する
ことを特徴とするプログラム検査方法。
【請求項２】
ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を前記システム内で実行する
ことを特徴とする請求項１に記載のプログラム検査方法。
【請求項３】
前記複数のプログラムが正常に動作しているかを監視し、
あるノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する
ことを特徴とする請求項１又は２に記載のプログラム検査方法。
【請求項４】
マルチコアプロセッサを有する複数のノードから構成され、当該複数のノードにおいて実行される複数のプログラムからなる動作試験を並列に実行するマルチコアシステムであって、
当該マルチコアシステムを構成する各ノードが、
ノードに接続されるデバイスへのアクセスを管理する管理部と、
動作試験を構成するプログラムにおいてデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを中断させる要求を通知する連携部と、
を備えることを特徴とするマルチコアシステム。
【請求項５】
ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を実行する
ことを特徴とする請求項４に記載のマルチコアシステム。
【請求項６】
前記複数のプログラムが正常に動作しているかを監視する監視部をさらに有し、
前記連携部は、自ノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを停止させる要求を通知する
ことを特徴とする請求項４又は５に記載のマルチコアシステム。
【請求項１】
マルチコアプロセッサを有する複数のノードから構成されるシステムにおけるプログラム検査方法であって、
複数のノードにおいて分散して実行される複数のプログラムからなる動作試験を、当該システム内で複数並列に実行し、
あるノードで実行中のプログラムにデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムの実行も中断する
ことを特徴とするプログラム検査方法。
【請求項２】
ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を前記システム内で実行する
ことを特徴とする請求項１に記載のプログラム検査方法。
【請求項３】
前記複数のプログラムが正常に動作しているかを監視し、
あるノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムも停止する
ことを特徴とする請求項１又は２に記載のプログラム検査方法。
【請求項４】
マルチコアプロセッサを有する複数のノードから構成され、当該複数のノードにおいて実行される複数のプログラムからなる動作試験を並列に実行するマルチコアシステムであって、
当該マルチコアシステムを構成する各ノードが、
ノードに接続されるデバイスへのアクセスを管理する管理部と、
動作試験を構成するプログラムにおいてデバイス競合が発生した場合に、当該プログラムの実行を中断するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを中断させる要求を通知する連携部と、
を備えることを特徴とするマルチコアシステム。
【請求項５】
ある動作試験の実行を中断した場合に、実行可能な他の動作試験が存在すれば、当該実行可能な動作試験を実行する
ことを特徴とする請求項４に記載のマルチコアシステム。
【請求項６】
前記複数のプログラムが正常に動作しているかを監視する監視部をさらに有し、
前記連携部は、自ノードで実行中のプログラムが正常に動作していない場合に、当該プログラムを停止するとともに、当該プログラムと同じ動作試験に属し他のノードで実行中のプログラムを停止させる要求を通知する
ことを特徴とする請求項４又は５に記載のマルチコアシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図６Ｃ】
【図７】
【公開番号】特開２０１０−１９１５２２（Ｐ２０１０−１９１５２２Ａ）
【公開日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願番号】特願２００９−３２６９１（Ｐ２００９−３２６９１）
【出願日】平成２１年２月１６日（２００９．２．１６）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
【公開日】平成２２年９月２日（２０１０．９．２）
【国際特許分類】
【出願日】平成２１年２月１６日（２００９．２．１６）
【出願人】（５０２０８７４６０）株式会社トヨタＩＴ開発センター (232)
【出願人】（０００００３２０７）トヨタ自動車株式会社 (59,920)
【Ｆターム（参考）】
[ Back to top ]