特開 2024-3654 情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024003654

(43)【公開日】2024-01-15

(54)【発明の名称】情報処理装置

(51)【国際特許分類】

   G06F 9/48 20060101AFI20240105BHJP

【ＦＩ】

G06F9/48 300Z

【審査請求】未請求

【請求項の数】3

【出願形態】ＯＬ

(21)【出願番号】P 2022102943

(22)【出願日】2022-06-27

(71)【出願人】

【識別番号】509186579

【氏名又は名称】日立Ａｓｔｅｍｏ株式会社

(74)【代理人】

【識別番号】110002572

【氏名又は名称】弁理士法人平木国際特許事務所

(72)【発明者】

【氏名】本間 一樹

(57)【要約】

【課題】一定周期で実行されるタスクが何らかの要因により所定の周期内に処理が完了しない場合であっても、各タスクないしＭＰＵ全体として正常な動作を継続可能とする情報処理装置を提供する。
【解決手段】情報処理装置は、複数のタスクを実行するタスク実行部と、所定の周期で第一のトリガ信号を生成する周期生成部と、第一のトリガ信号を受信し、タスク実行部に対して複数のタスクの実行開始を指示する第二のトリガ信号を送信するタスク実行管理部と、を有し、タスク実行管理部は、タスク実行部の実行状況に応じて第二のトリガ信号の送信タイミングを調整する。
【選択図】図２

【特許請求の範囲】

【請求項1】

複数のタスクを実行するタスク実行部と、
所定の周期で第一のトリガ信号を生成する周期生成部と、
前記第一のトリガ信号を受信し、前記タスク実行部に対して前記複数のタスクの実行開始を指示する第二のトリガ信号を送信するタスク実行管理部と、を有し、
前記タスク実行管理部は、前記タスク実行部の実行状況に応じて前記第二のトリガ信号の送信タイミングを調整する、
ことを特徴とする情報処理装置。

【請求項2】

請求項１に記載の情報処理装置であって、
前記タスク実行部による、前記周期内における前記複数のタスクの実行を完了するまでの期間が所定の期間よりも短い場合に、
前記タスク実行管理部は、前記周期生成部に対して前記第一のトリガ信号を生成する周期を短縮化させる指示信号を送信する、
ことを特徴とする情報処理装置。

【請求項3】

請求項１に記載の情報処理装置であって、
前記タスク実行部は、前記周期内における前記複数のタスクの全ての実行が完了した場合に、前記タスク実行管理部に対して実行完了信号を送信し、
前記タスク実行管理部は、前記第一のトリガ信号を受信した後、前記実行完了信号の受信を条件として前記第二のトリガ信号を送信する、
ことを特徴とする情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は車両に搭載される情報処理装置に関し、特に、一定の周期で実行されるタスクの起動タイミングを調整可能な情報処理装置に関する。

【背景技術】

【0002】

車両等に搭載される情報処理装置において、一定の周期で実行されるタスクは様々な要因によりその実行が所定の周期内に終わらない場合がある。また、近年、自動車におけるＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）は複数のＥＣＵを統合した一種の仮想マシンであるＩｎｔｅｇｒａｔｅｄ ＥＣＵとして実装される様になってきており、これに伴いＩｎｔｅｇｒａｔｅｄ ＥＣＵ内で実行されるタスク数も増加傾向にあり、上記のような所定の周期内にタスク処理が終了しない問題が顕著になりつつある。

【0003】

図１は、一般的な情報処理装置のハードウェア構成を示すブロック図である。情報処理装置（１）は、データの読み出しが可能な記憶装置であるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）（１２）、データの書き込みと読み出しの両方が可能であるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）（１３）、データを基に車両制御に必要なパラメータの演算を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）（１１）、及び演算結果を通信用のプロトコルに変換して送信を行う通信モジュール（１０）を保有している。

【0004】

また、情報処理装置（１）は、たとえば車両に搭載され、車両を制御する装置である。ただし、情報処理装置（１）は車両に搭載されないものであってもよく、車両以外の対象を制御する装置であってもよい。

【0005】

情報処理装置（１）は、通信路（１４）を介して外部サーバ（１５）と接続されている。通信路（１４）は、物理的には複数の通信バスを含んでもよく、各通信バスの規格はすべて同一でもよいし異なっていてもよい。これら通信バスの規格はＣＡＮ（登録商標）、ＬＩＮ（登録商標）、ＦｌｅｘＲａｙ（登録商標）、イーサネット（登録商標）などである。

【0006】

情報処理装置（１）は通信路（１４）を通過したデータを受信する。すると、受信に応じて、受信データがＲＡＭ（１３）に展開される。そして、書き込まれたＲＡＭ（１３）のデータとＲＯＭ（１２）の読み出しデータを基に、ＣＰＵ（１１）が演算を行う。また、情報処理装置（１）には予めプログラムが組み込まれており、ＣＰＵ（１１）が当該プログラムを実行することによって以下に説明する処理を実行することが可能になる。

【0007】

上述した情報処理装置（１）として、例えばＩｎｔｅｇｒａｔｅｄ ＥＣＵ上の地図情報処理ユニット（ＭＰＵ：Ｍａｐ Ｐｏｓｉｔｉｏｎｉｎｇ Ｕｎｉｔ）等が挙げられる。ＭＰＵが実行するアプリは自動車に搭載される各種センサからの走行データを周期的に受信する経路において以下の遅延が発生し得る。すなわち、コンテナと仮想マシンとの間においてはタスクスイッチや他のコンテナとの干渉による遅延が生じ得、アプリとコンテナ間の仮想Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）においては、Ｓ／Ｗ（ＳｏｆｔＷａｒｅ）処理による遅延が生じ得る。ここで、コンテナとは、稼働中のオペレーティングシステム（ＯＳ）の一部を分離して他と隔離された専用のエリアを用意し、その上でソフトウェアを動作させるコンピュータの仮想方式の一つであるコンテナ型仮想化技術において、隔離された領域のことをいう。

【0008】

これらの遅延の影響によりタスクがある一定期間（例えば１０ｍｓ周期）内に終わらない場合、ＭＰＵの動作・出力結果を保証出来なくなる可能性がある。

【0009】

ここで、従来技術におけるＭＰＵの構成及び実行される処理を図１１－１４を用いて説明する。図１１は、従来技術におけるＭＰＵの構成の一例を示すブロック図である。ＭＰＵ（１００）は、ＲＴＯＳ（１３０）、タイマー（１４０）、Ｉ／Ｏ（１５０）を有し、タスク１（１１０）、タスク２（１１１）、タスク３（１１２）をある周期（例えば１０ｍｓ）毎に実行するものである。図１１においてＭＰＵ（１００）は単独の情報処理装置として描かれているが、例えばＭＰＵ（１００）をＩｎｔｅｇｒａｔｅｄ ＥＣＵ上の１つの仮想マシンとして実行する形態でも良い。なお、実施例を含め以降では本発明に係る情報処理装置として車載ＥＣＵの１つであるＭＰＵを例に説明するが、本発明の適用範囲は車載ＭＰＵに限定されることはなく、周期的にデータを受信して処理を実行するＥＣＵ全てに適用可能である。

【0010】

ＲＴＯＳ（１３０）は、「Ｒｅａｌ Ｔｉｍｅ Ｏｐｅｒａｔｉｏｎ Ｓｙｓｔｅｍ」の略称であり、要求される期限までに処理を実行するシステムのことである。近年では、特にＭＰＵ等の、処理にリアルタイム性が要求される機器に搭載されることが多くなっている。ＲＴＯＳ（１３０）はさらにタスク・ディスパッチャ（１３１）とＩ／Ｏドライバ（１３２）を有する。タスク・ディスパッチャ（１３１）は、ＲＴＯＳ（１３０）が有する制御機能部の１つであり、実行可能状態にある複数のタスクの中から次に実行すべきタスクを選択してＣＰＵの使用権を割り当てる機能を有する。Ｉ／Ｏドライバ（１３２）は、入出力制御、ファイルシステム、ネットワークプロトコルなどを含み、各種データへのアクセスを制御する機能を有する。

【0011】

タイマー（１４０）は、タスク毎に予め設定された周期を記憶しており、タスクを起動すべきタイミングで、タスク・ディスパッチャ（１３１）に対してタスクを起動するタイミングを示すトリガ信号（１４１）を送信する。タイマー（１４０）は例えばハードウェア的に実装されても良いし、ソフトウェア的に実装されても良い。

【0012】

Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）（１５０）は、データの入出力を行うインターフェースであり、Ｉ／Ｏ（１５０）を介してＭＰＵ（１００）と外部の車両（１６０）との間でデータの送受信が行われる。

【0013】

全てのタスクはＲＴＯＳ（１３０）内のタスク制御装置であるタスク・ディスパッチャ（１３１）からの起動信号（１２１）を契機に１つずつ順番に実行される。それぞれのタスクはその実行が完了した際、完了信号（１２２）を用いてその実行が完了したことをタスク・ディスパッチャ（１３１）に伝える。

【0014】

なお、実施例も含め、本明細書においては、タスク・ディスパッチャ（１３１）はＭＰＵ（１００）内に設置されたタイマー（１４０）で生成される例えば１０ｍｓ毎の一定間隔のトリガ信号（１４１）に基づいて、タスク１～３を一定間隔で起動していくものとする。しかし、１周期内で実行されるタスク数は任意であり、また異なる周期を有するタスクが実行されることもある。

【0015】

また、タスク３（１１２）はその処理において、車両（１６０）からリアルタイムで得られる走行データ（１５１）をＩ／Ｏ（１５０）からの通信路（１３３）、およびＲＴＯＳ（１３０）内のＩ／Ｏドライバ（１３２）からの通信路（１２３）を経由して入力値として用いて実行するものとする。

【0016】

図１２－１３に、従来技術における、それぞれのタスク１～３が実行される処理を表すタイムチャート及びフローチャートを示す。

【0017】

図１２のタイムチャートに示すように、タイマー（１４０）は一定周期でトリガ信号（１４１）を生成する。ここでは例として１０ｍｓ毎とするが、この周期は任意に設定可能である。タイマー（１４０）が第ｎ周期においてトリガ信号（１４１）を生成すると、それを受けてタスク・ディスパッチャ（１３１）はｂｕｓｙ状態となりタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を順番に起動していく。

【0018】

具体的には、先ずタスク・ディスパッチャ（１３１）はタスク１（１１０）に起動信号（１２１ａ）を送信し、タスク１（１１０）を起動する。タスク１（１１０）は起動信号（１２１ａ）の受信に応じて処理を開始し、その処理が完了すると完了信号（１２２ａ）をタスク・ディスパッチャ（１３１）に送信し、処理が完了したことを報告する。

【0019】

次にタスク・ディスパッチャ（１３１）はタスク２（１１１）に起動信号（１２１ｂ）を送信し、タスク２（１１１）を起動する。タスク２（１１１）は起動信号（１２１ｂ）の受信に応じて処理を開始し、その処理が完了すると完了信号（１２２ｂ）をタスク・ディスパッチャ（１３１）に送信し、処理が完了したことを報告する。

【0020】

更にタスク・ディスパッチャ（１３１）は起動信号（１２１ｃ）をタスク３（１１２）に送信し、タスク３（１１２）を起動する。タスク３（１１２）は起動信号（１２１ｃ）の受信に応じて処理を開始し、その処理が完了すると完了信号（１２２ｃ）をタスク・ディスパッチャ（１３１）に送信し、処理が完了したことを報告する。ここで、上述の通りタスク３（１１２）は車両（１６０）からリアルタイムで得られる走行データ（１５１）を入力値として用いるため、その起動には、１０ｍｓ毎に到着する走行データ（１５１）が必要である。このケースでは走行データ（１５１）がタスク３（１１２）の起動タイミング（起動信号１２１ｃの受信タイミング）よりも先であるため、タスク３（１１２）は起動信号（１２１ｃ）受信のタイミングで直ぐにその処理を開始する事が出来る。

【0021】

最後にタスク・ディスパッチャ（１３１）は第ｎ周期内に実行されるべき最後のタスクであるタスク３（１１２）から実行完了を示す完了信号（１２２ｃ）を受信すると、当該１０ｍｓの第ｎ周期内に実行すべきタスクは全て終了したものと見なして、ｂｕｓｙ状態を取り下げる。

【0022】

同様に第（ｎ＋１）周期、第（ｎ＋２）周期と連続して処理が実行される。

【0023】

図１３に上述の処理をフローチャートとして示す。まずステップＳ１３０１において、タスク・ディスパッチャ（１３１）がタイマー（１４０）からトリガ信号（１４１）を受信する。ステップＳ１３０２において、該受信に応じてタスクを起動し、ステップＳ１３０３において該タスクの処理が完了するとタスクから完了信号を受信する。ステップＳ１３０４において、完了信号を送信してきたタスクが該周期内において最後に実行されるべきタスクであったか否か判定し、最後でなければステップＳ１３０２へと戻り次のタスクを起動し、最後であれば処理を終了する（ｂｕｓｙ状態を取り下げる）。以上が、従来用いられてきたＭＰＵ（１００）が実行する処理である。

【0024】

図１４に、従来技術における、それぞれのタスク１～３が実行される際にあるタスクの実行が所定の１０ｍｓ間隔内に完了しない事により問題が発生するケースについて示す。
図１４において、第ｎ周期内における処理、及び第（ｎ＋１）周期内におけるタスク２（１１１）の実行までの処理は図１２と同様である。

【0025】

第（ｎ＋１）周期内において、タスク・ディスパッチャ（１３１）はタスク２（１１１）から完了信号（１２２ｂ）を受信後、起動信号（１２１ｃ）をタスク３（１１２）に送信して起動しようとする。ここで、車両（１６０）とタスク３（１１２）との間の通信路（１３３、１２３）に何等かの異常が生じ、第（ｎ＋１）周期内において走行データ（１５１）が、タスク３（１１２）を起動すべきタイミングを示す起動信号（１２１ｃ）の生成時点で得られない場合が生じ得る。この場合、タスク３（１１２）は起動信号（１２１ｃ）受信のタイミングで直ぐにその処理を開始する事が出来ず、走行データ（１５１）受信の遅延（２４０）分だけタスク３（１１２）も遅延（２５０）して起動されることになる。その場合、結果的にタスク３（１１２）が完了するのは次の第（ｎ＋２）周期の開始タイミングの後まで遅れる事態が生じ得る。

【0026】

上記の状態においては、タイマー（１４０）は１０ｍｓ毎にトリガ信号（１４１）を生成するようプログラムされているため、第（ｎ＋１）周期開始時点から１０ｍｓ経過後に、第（ｎ＋２）周期を開始させるためのトリガ信号（１４１）を生成する。それを受けてタスク・ディスパッチャ（１３１）はタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を順番に起動して行こうとするが、この時点では第（ｎ＋１）周期内におけるタスク３（１１２）の処理は未だ完了しておらず、タスク・ディスパッチャ（１３１）は依然ｂｕｓｙ状態のままである。一方でタスク・ディスパッチャ（１３１）はタイマー（１４０）からのトリガ信号受信に応じて第（ｎ＋２）周期のタスク処理を起動するために自らの状態をｂｕｓｙ状態にしようとするため、タスク・ディスパッチャ（１３１）の状態に不整合が生じることになる。

【0027】

このため、仮に本来よりも遅れたタイミングでタスク３（１１２）の完了がタスク・ディスパッチャ（１３１）に報告されても、タイミング２３０の時点において、第（ｎ＋１）周期におけるタスク３（１１２）の完了信号（１２２ｃ）の受信とタイマー（１４０）による第（ｎ＋２）周期の開始を通知するトリガ信号（１４１）の受信とが重複してしまい、タスク・ディスパッチャ（１３１）は現状のｂｕｓｙ状態を以前の一連のタスク処理に該当するものとして解除して良いのか、あるいは次の一連のタスク処理に該当するためｂｕｓｙ状態を継続すべきなのか判断が出来ない。この不整合によりタスク・ディスパッチャ（１３１）が正常に動作を継続出来ない事態に陥る、あるいはタスク１（１１０）、タスク２（１１１）、タスク３（１１２）の処理が正しく継続出来なくなり、その処理内容の信頼性が低下する、などの問題が発生することになる。

【0028】

上記技術に関連して、特許文献１には、位置探索サービスをサポートするための技術であって、周期的トリガーサービスを有し、位置探索を実施する発明の構成が記載されており、さらに、受信した情報が蓄積された情報と適合しない場合に修正する技術が開示されている。

【先行技術文献】

【特許文献】

【0029】

【特許文献1】特開２０１３－０４８４４４号公報

【発明の概要】

【発明が解決しようとする課題】

【0030】

図１４の例で示した通り、一定周期で実行され、かつその起動に走行データ（１５１）の到着が必要となるタスクがある場合、走行データ（１５１）の到着が遅れること等の理由で所定の一定周期内にタスクの処理が完了せず、次の一定周期までその完了が遅れてしまい、全体のタスクないしＭＰＵ（１００）の実行結果が保証出来ないケースが起こりえる。なおこの様なタスクの完了の遅れは走行データ（１５１）の遅延に限った事では無く、例えばＩｎｔｅｇｒａｔｅｄ ＥＣＵ上の仮想マシンで実行されているＭＰＵ（１００）が同一Ｉｎｔｅｇｒａｔｅｄ ＥＣＵ上の他の仮想マシンで実行されているアプリケーションによる外乱を受けること、等の様々な要因が想定される事は自明である。

【0031】

本発明は、上記課題に鑑みてなされたものであり、一定周期で実行されるタスクが何らかの要因により所定の周期内に処理が完了しない場合であっても、各タスクないしＭＰＵ全体として正常な動作を継続可能とする情報処理装置を提供することを目的としている。

【課題を解決するための手段】

【0032】

上述の目的を実現するために、本発明に係る情報処理装置は、複数のタスクを実行するタスク実行部と、所定の周期で第一のトリガ信号を生成する周期生成部と、第一のトリガ信号を受信し、タスク実行部に対して複数のタスクの実行開始を指示する第二のトリガ信号を送信するタスク実行管理部と、を有し、タスク実行管理部は、タスク実行部の実行状況に応じて第二のトリガ信号の送信タイミングを調整する。

【発明の効果】

【0033】

本発明によれば、一定周期で実行されるタスクが何らかの要因により所定の周期内に処理が完了しない場合であっても、各タスクないしＭＰＵ全体として正常な動作を継続させることが可能となる。
本発明に関連する更なる特徴は、本明細書の記述、添付図面から明らかになるものである。また、上記した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。

【図面の簡単な説明】

【0034】

【図1】一般的な情報処理装置の構成を示すブロック図。

【図2】本発明に係るＭＰＵの構成の一例を示すブロック図。

【図3】本発明に係るＭＰＵが有するタイム・キーパーの構成を示すブロック図。

【図4】走行データ受信の遅延が生じていない場合に本発明に係るＭＰＵが実行する処理を示すタイムチャート。

【図5】本発明に係るＭＰＵ内にて実行される処理の概要を示すシーケンス図。

【図6】タスク・ディスパッチャが実行する処理を示すフローチャート。

【図7】走行データ受信の遅延が生じた場合に本発明に係るＭＰＵが実行する処理を示すタイムチャート。

【図8】タイム・キーパーが実行する処理を示すフローチャート。

【図9】本発明の変形例に係るＭＰＵが実行する処理を示すタイムチャート。

【図10】図９に示す処理中タイム・キーパーが実行する処理を示すフローチャート。

【図11】従来のＭＰＵの構成の一例を示すブロック図。

【図12】従来のＭＰＵが実行する処理の一例を示すタイムチャート。

【図13】従来のＭＰＵにおいてタスク・ディスパッチャが実行する処理を示すフローチャート。

【図14】従来のＭＰＵを採用した場合に、走行データ受信の遅延が生じた場合に生じる問題点を説明するためのタイムチャート。

【発明を実施するための形態】

【0035】

以下、本発明の実施形態について、図面を用いて説明する。
図２は、本発明の一実施例に係るＭＰＵ（１００）の構成を示すブロック図である。本実施例に係るＭＰＵ（１００）は、所定の周期毎にタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を実行する点においては従来と同様である。本実施例に係るＭＰＵ（１００）が図１１に示した従来のＭＰＵ（１００）と異なる点は、ＲＴＯＳ（１３０）内にさらにタイム・キーパー（３００）を備える点である。従来のＭＰＵ（１００）におけるタスク・ディスパッチャ（１３１）はタイマー（１４０）からのタスクの起動タイミングを示すトリガ信号（１４１）を直接受信し、各タスクを起動していたが、本実施例においては、タイマー（１４０）からのトリガ信号（１４１）はタイム・キーパー（３００）に送信され、タスク・ディスパッチャ（１３１）は、タイム・キーパー（３００）からのトリガ信号（３２０）の受信に応じて各タスクを起動する。

【0036】

タイム・キーパー（３００）はＭＰＵ（１００）内に設置されたタイマー（１４０）で生成される例えば１０ｍｓ毎の一定間隔のトリガ信号（１４１）に基づいて、タスク・ディスパッチャ（１３１）に対してそれぞれのタスク１～３を一定間隔で起動していくタイミングをトリガ信号（３２０）の送信により伝える。タイマー（１４０）は例えばハードウェア的に実装されても良いし、ソフトウェア的に実装されても良い。

【0037】

タスク・ディスパッチャ（１３１）はＲＴＯＳ（１３０）内に設置されたタイム・キーパー（３００）からのトリガ信号（３２０）に基づいて、それぞれのタスク１～３を一定間隔で起動していく。またタスク・ディスパッチャ（１３１）はそれぞれのタスクから来る完了信号（１２２）を監視し、全てのタスクの実行が完了したのを確認すると直ちにディスパッチャ完了信号（３１０）をタイム・キーパー（３００）に伝える。

【0038】

図３にタイム・キーパー（３００）の構成例を示す。タイム・キーパー（３００）はディスパッチャ完了信号（３１０）を保持しておくディスパッチャ完了信号保持レジスタ（３０１）、タイマー（１４０）からのトリガ信号（１４１）を保持しておくタイマー要求保持レジスタ（３０２）、ディスパッチャ完了信号保持レジスタ（３０１）の出力（３０４）およびタイマー要求保持レジスタ（３０２）の出力（３０５）が共に有効になった際にトリガ信号（３２０）を生成するＡＮＤ器（３０３）を有する。またディスパッチャ完了信号保持レジスタ（３０１）およびタイマー要求保持レジスタ（３０２）はトリガ信号（３２０）が出力されるとその内容がクリアされるように設定されている。なお、「ディスパッチャ完了信号（３１０）及びトリガ信号（１４１）を保持」するとは、例えば各レジスタがフラグを有しており、信号の受信に応じてフラグを１に設定し、リセットする際にはフラグを０にする、といった方法で実現される。

【0039】

図４は、走行データ受信の遅延が生じていない場合に、本実施例に係るＭＰＵ（１００）が実行する処理を示すタイムチャートである。なお、図４に示すタイムチャートは、図１２に示す従来例におけるタイムチャートにタイム・キーパー（３００）による処理が加わったものであるため、タイム・キーパー（３００）に関わる処理についてのみ説明する。

【0040】

タイマー（１４０）がある１０ｍｓ周期のタイミング（例えば第ｎ周期の開始タイミング）でトリガ信号（１４１）を生成すると、それを受けてタイム・キーパー（３００）はタイマー要求保持レジスタ（３０２）にトリガ信号が来た情報を保持する。ここでタイム・キーパー（３００）のディスパッチャ完了信号保持レジスタ（３０１）は初期値として完了信号を保持した状態であるため、ＡＮＤ器（３０３）はタイマー（１４０）からのトリガ信号（１４１）の受信に応じてトリガ信号（３２０）をタスク・ディスパッチャ（１３１）に送信すると同時にディスパッチャ完了信号保持レジスタ（３０１）とタイマー要求保持レジスタ（３０２）をクリアする。トリガ信号（３２０）の受信に応じてタスク・ディスパッチャ（１３１）はｂｕｓｙ状態となりタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を順番に起動していく。このタスク起動処理については従来と同様である。

【0041】

図５は、本実施例に係るＭＰＵ（１００）内にて実行される上記処理の概要を示すシーケンス図である。図５に示すように、まずステップ５０１においてタイマー（１４０）が各周期の開始タイミングにおいてトリガ信号を生成し、タイム・キーパー（３００）に送信する。ステップ５０２及び５０３において、タイム・キーパー（３００）は、ディスパッチャ完了信号保持レジスタ（３０１）及びタイマー要求保持レジスタ（３０２）の内容をクリアするとともに、タスク・ディスパッチャ（１３１）に、各タスクの起動タイミングを通知するトリガ信号（３２０）を送信する。ステップ５０４においてタスク・ディスパッチャ（１３１）はタスクを順次起動させ、ステップ５０５において該周期内において最後に実行されるタスクからの完了信号（１２２）を受信する。タスク・ディスパッチャ（１３１）は、該最後の完了信号受信に応じて、ステップ５０６においてタイム・キーパー（３００）にディスパッチャ完了信号（３１０）を送信する。ステップ５０７においてタイム・キーパー（３００）は、ディスパッチャ完了信号保持レジスタ（３０１）にディスパッチャ完了信号（３１０）を保持し、タイマー（１４０）から次のトリガ信号（１４１）を受信するまで待機する。

【0042】

続いて、本実施例においてタスク・ディスパッチャ（１３１）が実行する処理について図６のフローチャートを用いて説明する。図６のフローチャートは、図１３に示した従来におけるタスク・ディスパッチャ（１３１）が実行する処理に加えて、ステップＳ６０１が追加されている。また、ステップＳ１３０１において受信するトリガ信号は、タイマー（１４０）からのトリガ信号（１４１）ではなく、タイム・キーパー（３００）からのトリガ信号（３２０）である。

【0043】

本実施例におけるタスク・ディスパッチャ（１３１）は、ステップＳ１３０４において該周期内に実行されるべき全タスクの処理が完了したと判定すると、ディスパッチャ完了信号（３１０）を生成し、タイム・キーパー（３００）に送信する。タイム・キーパー（３００）は、上述の通りこれに応じてディスパッチャ完了信号保持レジスタ（３０１）にこの信号を保持する。

【0044】

図７に、走行データ受信の遅延が生じた場合に本実施例に係るＭＰＵ（１００）が実行する処理を表すタイムチャートを示す。図７においては、第（ｎ＋１）周期において、走行データ（１５１）の受信が遅延したと想定する。

【0045】

第ｎ周期内における処理については走行データの受信遅延が生じていない図４と同様であり、タスク・ディスパッチャ（１３１）はタスク１～３を順次起動し、最後のタスク３（１１２）から完了信号（１２２ｃ）を受信すると、ディスパッチャ完了信号（３１０）をタイム・キーパー（３００）に送信する。タイム・キーパー（３００）は、該受信においディスパッチャ完了信号保持レジスタ（３０１）に該受信情報を保持する。

【0046】

そして、タイマー（１４０）は第ｎ周期に続く第（ｎ＋１）周期の開始タイミングにおいてトリガ信号（１４１）を生成し、タイム・キーパー（３００）に送信する。すると、タイム・キーパー（３００）はタイマー要求保持レジスタ（３０２）にトリガ信号が来たことを保持する。上述の通りタイム・キーパー（３００）のディスパッチャ完了信号保持レジスタ（３０１）は完了を保持した状態であるため、ＡＮＤ器（３０３）はトリガ信号（３２０）をタスク・ディスパッチャ（１３１）に送信すると同時にディスパッチャ完了信号保持レジスタ（３０１）とタイマー要求保持レジスタ（３０２）をクリアする。それを受けてタスク・ディスパッチャ（１３１）はｂｕｓｙ状態となりタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を順番に起動していく。

【0047】

タスク・ディスパッチャ（１３１）はタスク２（１１１）からの完了信号（１２２ｂ）を受信後、タスク３（１１２）を起動するための起動信号（１２１ｃ）をタスク３（１１２）に送信し、タスク３（１１２）を起動しようとする。しかし、上述の通り図７においては第（ｎ＋１）周期中において走行データ（１５１）の受信に遅延（２４０）が生じている。

【0048】

第（ｎ＋１）周期内におけるタスク３（１１２）の実行が完了しない場合であっても、タイマー（１４０）内のタイムカウンタは作動し続けるため、第（ｎ＋１）周期の開始から１０ｍｓ経過後に、タイマー（１４０）は第（ｎ＋２）周期における処理を開始するためのトリガ信号（１４１）を生成し、タイム・キーパー（３００）に送信する。タイム・キーパー（３００）は該信号の受信に応じてタイマー要求保持レジスタ（３０２）にトリガ信号（１４１）が来た情報を保持する。しかし、タスク・ディスパッチャ（１３１）はこの時点ではタスク３（１１２）から完了信号（１２２ｃ）を受信していないため、タイム・キーパー（３００）にディスパッチャ完了信号（３１０）を送信していない。従って、タイム・キーパー（３００）のディスパッチャ完了信号保持レジスタ（３０１）にはディスパッチャ完了信号（３１０）の受信情報が保持されていない。そのため、ＡＮＤ器（３０３）の信号生成条件が成立せず、タイム・キーパー（３００）によるトリガ信号（３２０）の生成は保留状態となる。

【0049】

上述の保留状態は第（ｎ＋１）周期内にて遅延していたタスク３（１１２）の実行が完了し、タスク・ディスパッチャ（１３１）がタイム・キーパー（３００）に対してディスパッチャ完了信号（３１０）を送信するまで継続する。その結果として、第（ｎ＋２）周期の始点として想定されていたタイミングから、タイム・キーパー（３００）がディスパッチャ完了信号（３１０）を受信するまでの期間（２６０）は、第（ｎ＋２）周期の開始タイミングを通知するトリガ信号（１４１）の生成が保留状態になる「抑止期間」となる。

【0050】

タスク・ディスパッチャ（１３１）がタスク３（１１２）からの完了信号（１２２ｃ）の受信に応じてタイム・キーパー（３００）に対してディスパッチャ完了信号（３１０）を送信すると、タイム・キーパー（３００）はディスパッチャ完了信号保持レジスタ（３０１）に信号を保持する。すると、ＡＮＤ器（３０３）のＯＮ条件が満たされるため、タイム・キーパー（３００）第（ｎ＋２）周期の開始を通知するトリガ信号（３２０）をタスク・ディスパッチャ（１３１）に送信すると同時にディスパッチャ完了信号保持レジスタ（３０１）とタイマー要求保持レジスタ（３０２）をクリアする。それを受けてタスク・ディスパッチャ（１３１）はｂｕｓｙ状態となりタスク１（１１０）、タスク２（１１１）、タスク３（１１２）を順番に起動していく。以下、先述と同様の流れに従ってタスク１（１１０）、タスク２（１１１）、タスク３（１１２）が処理されていく。

【0051】

上記説明した実施例においてタイム・キーパー（３００）が実行する処理を図８のフローチャートを用いて説明する。まずステップＳ８０１においてタイム・キーパー（３００）は、タイマー（１４０）から、ある周期の開始タイミングを通知するトリガ信号（１４１）を受信する。ステップＳ８０２において、タイム・キーパー（３００）はディスパッチャ完了信号保持レジスタ（３０１）を参照し、ディスパッチャ完了信号（３１０）の受信を保持しているか否か判定する。保持していなければそのまま待機し、保持していればステップＳ８０３へと移行し、トリガ信号（３２０）を生成し、タスク・ディスパッチャ（１３１）に対して処理の開始を通知する。

【0052】

以上説明した様に本実施例によれば、あるタスクの実行が想定されていた実行周期内に完了しなかった場合においても、タイム・キーパー（３００）は全てのタスクの実行が完了するまでタスク・ディスパッチャ（１３１）に処理開始を通知するトリガ信号（３２０）の生成を保留とすることで、タイマー（１４０）から次の周期の開始を通知するトリガ信号（１４１）を受信した場合であってもタスク・ディスパッチャ（１３１）は正常に動作を継続することが可能であり、タスク１（１１０）、タスク２（１１１）、タスク３（１１２）の処理も正しく継続することが可能となる。

【0053】

次に、本発明の変形例に係るＭＰＵ（１００）が実行する処理について図９－１０を用いて説明する。図９は、変形例に係るＭＰＵ（１００）が実行する処理を示すタイムチャートであり、図１０は、タイム・キーパー（３００）が実行する処理を示すフローチャートである。

【0054】

上記で説明した実施例においては、あるタスクの実行が想定されていた周期内に完了しない場合に、次の周期の開始を通知するトリガ信号が生成されることに起因する問題点を解消することを目的としていた。これに対して変形例においては、一周期内において全てのタスク実行が完了するまでの期間が所定の期間よりも短いときに、次の周期の開始を早め、ＣＰＵの利用効率を向上させることを目的とするものである。

【0055】

具体的には、図９に示すように例えば第ｎ周期において、タイム・キーパー（３００）は、タスク・ディスパッチャ（１３１）からディスパッチャ完了信号（３１０）を受信した時点から、タイマー（１４０）から第（ｎ＋１）周期の開始を通知するトリガ信号（１４１）を受信するまでの時間である周期間期間（２７０）を計測する。これは例えば、ディスパッチャ完了信号保持レジスタ（３０１）とタイマー要求保持レジスタ（３０２）のそれぞれにタイムカウンタを備えさせ、その受信時刻の差分を得ることで計測可能である。

【0056】

タイム・キーパー（３００）は第ｎ周期内においてタスク１－３の実行が完了するまでの期間と所定の期間とを比較し、タスク１－３の実行が完了するまでの期間が該所定の期間よりも短い場合に、タイマー（１４０）に対して、第（ｎ＋２）周期の開始を短縮時間（２８０）だけ早めるように指示する。これは、周期間期間（２７０）と、一周期（図９においては１０ｍｓ）と上記所定の期間との差分を比較することによって判定できる。

【0057】

上記において、タスク１－３の実行が完了するまでの期間と比較される所定の期間は、既述の、周期内にタスクの実行が完了しない場合の問題が生じないような範囲で設定され、走行データの受信間隔や各タスクの最悪実行時間等を考慮して予め定めることができる。

【0058】

図１０は、本変形例においてタイム・キーパー（３００）が実行する処理を示すフローチャートである。まず、ステップＳ１００１において、タイム・キーパー（３００）はタスク・ディスパッチャ（１３１）からディスパッチャ完了信号（３１０）を受信する。ステップＳ１００２において、タイム・キーパー（３００）から、次の周期の開始を通知するトリガ信号（１４１）を受信する。そしてタイム・キーパー（３００）は上述のように周期間期間（２７０）を計測し、ステップＳ１００３において、予め設定された所定の期間に対応する閾値と比較し、周期間期間（２７０）が閾値よりも長ければ、一周期内において全タスクの実行を完了してから次周期が始まるまでの期間に余裕があると判断し、ステップＳ１００４において、タイム・キーパー（３００）に対して、次の周期の開始を通知するトリガ信号（１４１）の生成周期を短縮するよう指示する信号を送信する。

【0059】

以上説明した変形例によれば、一周期内において全タスクの実行を完了してから次周期の開始までに余裕がある場合に、周期開始のタイミングを早めることで、ＣＰＵが稼働しないｉｄｌｅ時間を削減することが可能になり、ＣＰＵの利用効率を向上させ、タスク実行の高速化が期待できる。

【0060】

以上で説明した本発明の実施例によれば、以下の作用効果を奏する。
（１）本発明に係る情報処理装置は、複数のタスクを実行するタスク実行部と、所定の周期で第一のトリガ信号を生成する周期生成部と、第一のトリガ信号を受信し、タスク実行部に対して複数のタスクの実行開始を指示する第二のトリガ信号を送信するタスク実行管理部と、を有し、タスク実行管理部は、タスク実行部の実行状況に応じて第二のトリガ信号の送信タイミングを調整する。

【0061】

上記構成により、一定周期で実行されるタスクが何らかの要因により所定の周期内に処理が完了しない場合であっても、各タスクないしＭＰＵ全体として正常な動作を継続することが可能になる。

【0062】

（２）タスク実行部による、周期内における複数のタスクの実行を完了するまでの期間が所定の期間よりも短い場合に、タスク実行管理部は、周期生成部に対して第一のトリガ信号を生成する周期を短縮化させる指示信号を送信する。これにより、ＣＰＵが稼働しないｉｄｌｅ時間を削減することが可能になり、ＣＰＵの利用効率を向上させ、タスク実行の高速化が期待できる。

【0063】

（３）タスク実行部は、周期内における複数のタスクの全ての実行が完了した場合に、タスク実行管理部に対して実行完了信号を送信し、タスク実行管理部は、第一のトリガ信号を受信した後、実行完了信号の受信を条件として第二のトリガ信号を送信する。これにより、タイム・キーパー（３００）は全てのタスクの実行が完了するまでタスク・ディスパッチャ（１３１）に処理開始を通知するトリガ信号（３２０）の生成を保留とすることで、タイマー（１４０）から次の周期の開始を通知するトリガ信号（１４１）を受信した場合であってもタスク・ディスパッチャ（１３１）は正常に動作を継続することが可能になる。

【産業上の利用可能性】

【0064】

本実施例では地図情報処理ユニット（ＭＰＵ）での動作を例に説明しているが、これはＭＰＵに限定されるものでは無く、例えば一定間隔で定期的な処理を行うシステム全般への適用が考えられる。また情報処理システムは必ずしも実機である必要は無く、前述の通り例えばＩｎｔｅｇｒａｔｅｄ ＥＣＵの上に構築されたＭＰＵや情報処理システム全般への応用が考えられる。

【0065】

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

【符号の説明】

【0066】

１００：ＭＰＵ（情報処理装置） １３１：タスク・ディスパッチャ（タスク実行部） １４０：タイマー（周期生成部） ３００：タイム・キーパー（タスク実行管理部）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】