特許 6788145 処理装置、交通信号装置及び情報表示装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6788145

(24)【登録日】2020年11月2日

(45)【発行日】2020年11月18日

(54)【発明の名称】処理装置、交通信号装置及び情報表示装置

(51)【国際特許分類】

   G06F 11/07 20060101AFI20201109BHJP

【ＦＩ】

   G06F11/07 157

   G06F11/07 140E

【請求項の数】4

【全頁数】12

(21)【出願番号】特願2020-108293(P2020-108293)

(22)【出願日】2020年6月24日

(62)【分割の表示】特願2015-204139(P2015-204139)の分割

【原出願日】2015年10月16日

(65)【公開番号】特開2020-155153(P2020-155153A)

(43)【公開日】2020年9月24日

【審査請求日】2020年6月24日

(73)【特許権者】

【識別番号】390010054

【氏名又は名称】コイト電工株式会社

(74)【代理人】

【識別番号】100096770

【弁理士】

【氏名又は名称】四宮 通

(72)【発明者】

【氏名】改井 宏光

(72)【発明者】

【氏名】小松 隆寿

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開平３−２８８９４２（ＪＰ，Ａ）

【文献】 特開２０００−０９９４８０（ＪＰ，Ａ）

【文献】 特開２０１０−２７７３５８（ＪＰ，Ａ）

【文献】 特開２０１４−０５９８４６（ＪＰ，Ａ）

【文献】 特開平５−２５７７４８（ＪＰ，Ａ）

【文献】 特開平１０−２１４２０８（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ １１／２８−１１／３６

Ｇ０５Ｂ ９／０２

(57)【特許請求の範囲】

【請求項1】

各々が周期的に起動される複数のタスクが並列的に実行されるマルチタスク処理を行う処理装置であって、
前記複数のタスクは、監視対象となる１つ以上の監視対象タスクと、前記１つ以上の監視対象タスクの監視を所定周期毎に行う監視タスクとを含み、
前記１つ以上の監視対象タスクは、自身のタスクに対応する保持部に所定情報を所定周期毎に保持させる処理を含み、
前記監視タスクは、前記１つ以上の監視対象タスクの各々について、当該監視タスクの起動時に当該監視対象タスクに対応する前記保持部に保持されている情報が前記所定情報である場合には、当該監視対象タスクに対応する前記保持部に前記所定情報と異なる情報を保持させる処理を含み、
前記監視タスクは、前記１つ以上の監視対象タスクの各々について、当該監視タスクの起動時に当該監視対象タスクに対応する前記保持部に保持されている情報が前記所定情報である場合には、当該監視対象タスクに対応するカウント値を初期値にリセットする処理を含み、
前記監視タスクは、前記１つ以上の監視対象タスクのうちの１つの監視対象タスクについて、当該監視タスクの起動時に当該監視対象タスクに対応する前記保持部に保持されている情報が前記所定情報と異なる情報である場合には、当該監視対象タスクに対応する前記カウント値をカウント動作により変化させた後に、当該変化後のカウント値が当該監視対象タスクに対応して予め定められた所定値であるか否かを判定する処理を含み、
前記監視タスクによって、前記１つの監視対象タスクについて、当該変化後のカウント値が当該監視対象タスクに対応して予め定められた前記所定値であると判定された場合に、それ以後のウォッチドッグタイマクリア信号の出力を停止する一方で、前記監視タスクによってそうではないと判定された場合に、それ以後のウォッチドッグタイマクリア信号の定期的な出力を行う、
ことを特徴とする処理装置。

【請求項2】

前記ウォッチドッグタイマクリア信号に基づいて前記処理装置の異常を検出するウォッチドッグタイマを備えたことを特徴とする請求項１記載の処理装置。

【請求項3】

交通信号灯器と、
請求項１又は２記載の処理装置と、
前記処理装置の制御下で又は自律的に、前記交通信号灯器を制御する制御回路と、
を備えたことを特徴とする交通信号装置。

【請求項4】

表示パネルと、
請求項１又は２記載の処理装置と、
前記処理装置の制御下で又は自律的に、前記表示パネルを制御する制御回路と、
を備えたことを特徴とする情報表示装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数のタスクが並列的に実行されるマルチタスク処理を行う処理装置、並びに、これを用いた交通信号装置及び情報表示装置に関するものである。

【背景技術】

【0002】

従来から、ＣＰＵやＭＰＵなどによる処理装置のプログラムの暴走等の異常を検出するため、一般的に、ウォッチドッグタイマが用いられている。前記処理装置は、プログラムの暴走等がなく正常である場合には、前記ウォッチドッグタイマをリセットするウォッチドッグタイマクリア信号を所定周期で発生し、プログラムの暴走等の異常が生ずると、ウォッチドッグタイマクリア信号を発生しないようになっている。

【0003】

例えば、下記特許文献１に開示された交通信号灯器を制御する交通信号制御機では、ウォッチドッグタイマを利用してＭＰＵの異常を検出している。この交通信号制御機では、ＭＰＵと信号制御用ＬＳＩが存在して、通常時はＭＰＵが信号制御用ＬＳＩを経由して信号制御を行って、ＭＰＵ異常が発生した場合は、ＭＰＵをＨＡＬＴ状態にして信号制御ＬＳＩのみで信号制御を行うようになっている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特許第３３６９０８７号公報

【発明の概要】

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

【0005】

近年のＣＰＵやＭＰＵなどによる処理装置では、複数のタスクが並列的に実行されるマルチタスク処理方式が採用されてきている。

【0006】

このようなマルチタスク処理方式において、複数のタスクを周期的に起動させて実行させる場合、それらのタスクのうちの１つとして、周期的にウォッチドッグタイマクリア信号を出力させるタスク（ウォッチドッグタイマクリアタスク）を行うとすれば、他のタスクに異常動作が生じても、ウォッチドッグタイマクリアタスクが正常に動作すれば、周期的にウォッチドッグタイマクリア信号が出力されてしまい、当該処理装置の異常を検出することができない。

【0007】

本発明は、このような事情に鑑みてなされたもので、各々が周期的に起動される複数のタスクが並列的に実行されるマルチタスク処理を行う処理装置であってより適切に異常を検出することができる処理装置、並びに、これを用いた交通信号装置及び情報表示装置を提供することを目的とする。

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

【0008】

前記課題を解決するための手段として、以下の各態様を提示する。第１の態様による処理装置は、各々が周期的に起動される複数のタスクが並列的に実行されるマルチタスク処理を行う処理装置であって、前記複数のタスクは、監視対象となる１つ以上の監視対象タスクと、前記１つ以上の監視対象タスクの監視を所定周期毎に行う監視タスクとを含み、前記１つ以上の監視対象タスクは、自身のタスクに対応する保持部に所定情報を所定周期毎に保持させる処理を含み、前記監視タスクは、前記１つ以上の監視対象タスクに対応する前記保持部に保持されている情報に基づいて、前記１つ以上の監視対象タスクのうちの少なくとも１つの監視対象タスクが所定時間以上正常に動作していない状態であるか否かを判定する処理を含み、前記監視タスクによって前記状態であると判定された場合に、それ以後のウォッチドッグタイマクリア信号の出力を停止する一方で、前記監視タスクによって前記状態ではないと判定された場合に、それ以後のウォッチドッグタイマクリア信号の定期的な出力を行うものである。

【0009】

この第１の態様によれば、１つ以上の監視対象タスクは、自身のタスクに対応する保持部に、所定情報を所定周期毎に保持させる処理を含んでいるので、当該監視対象タスクが正常に動作すれば、前記保持部に前記所定情報が保持されることになる。監視タスクは、前記１つ以上の監視対象タスクに対応する前記保持部に保持されている情報に基づいて、少なくとも１つの監視対象タスクが所定時間以上正常に動作していない状態であるか否かを判定する処理を含んでいる。そして、前記監視タスクによって前記状態であると判定された場合に、それ以後のウォッチドッグタイマクリア信号の出力が停止される一方で、前記監視タスクによって前記状態ではないと判定された場合に、それ以後のウォッチドッグタイマクリア信号の定期的な出力が行われる。

【0010】

したがって、前記第１の態様によれば、各監視対象タスクが正常に動作しているか否かが監視タスクによって監視され、監視対象タスクが正常に動作していれば、ウォッチドッグタイマクリア信号が定期的に出力される一方で、いずれかの監視対象タスクが正常に動作していない場合には、ウォッチドッグタイマクリア信号の出力が停止される。このため、前記第１の態様によれば、各々が周期的に起動される複数のタスクが並列的に実行されるマルチタスク処理を行うにも拘わらず、より適切に異常を検出することができる。

【0011】

第２の態様による処理装置は、前記第１の態様において、前記監視タスクは、前記少なくとも１つの監視対象タスクの各々について、当該監視タスクの起動時に当該監視対象タスクに対応する前記保持部に保持されている情報が前記所定情報である場合には、当該監視対象タスクに対応する前記保持部に前記所定情報と異なる情報を保持させる処理を含むものである。

【0012】

この第２の態様は、監視対象タスクの動作状況を示す情報のいわばリセット動作を明示したものである。

【0013】

第３の態様による処理装置は、前記第１又は第２の態様において、前記ウォッチドッグタイマクリア信号に基づいて前記処理装置の異常を検出するウォッチドッグタイマを備えたものである。

【0014】

第４の態様による交通信号装置は、交通信号灯器と、前記第１乃至第３のいずれかの態様による処理装置と、前記処理装置の制御下で又は自律的に、前記交通信号灯器を制御する制御回路と、を備えたものである。

【0015】

第５の態様による情報表示装置は、表示パネルと、前記第１乃至第３のいずれかの態様による処理装置と、前記処理装置の制御下で又は自律的に、前記表示パネルを制御する制御回路と、を備えたものである。

【0016】

前記第４及び第５の態様は前記第１乃至第３の態様による処理装置の使用例をあげたものであるが、前記第１乃至第３の態様では、それらの例に限定されるものではない。

【発明の効果】

【0017】

本発明によれば、各々が周期的に起動される複数のタスクが並列的に実行されるマルチタスク処理を行う処理装置であってより適切に異常を検出することができる処理装置、並びに、これを用いた交通信号装置及び情報表示装置を提供することができる。

【図面の簡単な説明】

【0018】

【図1】本発明の第１の実施の形態による処理装置の概略構成を示すブロック図である。

【図2】図１に示す処理装置におけるＯＳとタスクとの関係を模式的に示す図である。

【図3】図１に示す処理装置において監視タスクで用いられるデータの構成の一例を模式的に示す図である。

【図4】図１に示す処理装置において監視対象タスクで所定周期毎に行われる処理を示す概略フローチャートである。

【図5】図１に示す処理装置における監視タスクの処理内容を示す概略フローチャートである。

【図6】本発明の第２の実施の形態による交通信号装置の概略構成を示すブロック図である。

【図7】本発明の第２の実施の形態による情報表示装置の概略構成を示すブロック図である。

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

【0019】

以下、本発明による処理装置、交通信号装置及び情報表示装置について、図面を参照して説明する。

【0020】

［第１の実施の形態］

【0021】

図１は、本発明の第１の実施の形態による処理装置１の概略構成を示すブロック図である。

【0022】

本発明による処理装置１は、マイクロコンピュータ２と、ウォッチドッグタイマ３とを備えている。マイクロコンピュータ２は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＥＥＰＲＯＭ等の不揮発性メモリ１４と、入出力インターフェース１５と、これらを相互に接続するバス１６とを有している。入出力インターフェース１５には、必要に応じて周辺機器等が接続されるが、その図示は省略している。

【0023】

ウォッチドッグタイマ３は、プログラムの暴走等がなくＣＰＵ１１が正常に動作する場合には、後述するようにＣＰＵ１１から周期的にウォッチドッグクリア信号を受け、そのウォッチドッグクリア信号を一定期間受けなくなった場合には、ＣＰＵ１１に異常が生じたことを示す異常検出信号を出力する。本実施の形態では、ウォッチドッグタイマ３からの異常検出信号は、ＣＰＵ１１をリセットするリセット信号として用いられている。もっとも、その異常検出信号によって、マイクロコンピュータ２の電源切断によるシステムの強制停止、あるいは電源切断後の再投入等を行うようにしてもよいし、単に異常を表示装置に表示させたり、他の管理機器に異常状態を通知するために用いたりしてもよい。なお、本実施の形態では、ウォッチドッグタイマ３は、マイクロコンピュータ２の外部に設けられているが、マイクロコンピュータ２に内蔵してもよい。

【0024】

図２は、図１に示す処理装置１におけるＯＳ（オペレーティングシステム）２０とタスク２１−１〜２１−ｎ，２２との関係を模式的に示す図である。ＲＯＭ１２にはＯＳ２０や所望の処理プログラムが格納されており、マイクロコンピュータ２が起動されると、ＯＳ２０は、前記処理プログラムを適当な処理単位に分割したｎ個（ｎは２以上の整数）のタスク２１−１〜２１−ｎと、監視タスク２２とを設定し、これらのタスク２１−１〜２１−ｎ，２２を管理してＣＰＵ１１に実行させる。

【0025】

本実施の形態では、ＯＳ２０の管理下で、タイマ（図示せず）による割り込み等を利用して、各々が周期的に起動されるタスク２１−１〜２１−ｎ，２２が並列的に実行されるマルチタスク処理が実現される。本実施の形態では、タスク２１−１は周期Ｔ１で起動され、タスク２１−２は周期Ｔ２で起動され、・・・、タスク２１−ｎは周期Ｔｎで起動され、監視タスク２２は周期Ｔ０で起動される。周期Ｔ１〜Ｔｎ，Ｔ０は互いに異なっていてもよいし、一部の周期が互いに異なるとともに一部の周期が互いに同一でもよいし、全部の周期が同一でもよい。例えば、ｎ＝５の場合、Ｔ１＝１００ミリ秒、Ｔ２＝２００ミリ秒、Ｔ３＝１００ミリ秒、Ｔ４＝１００ミリ秒、Ｔ５＝５００ミリ秒、Ｔ０＝１秒とすることができる。

【0026】

ｎ個のタスク２１−１〜２１−ｎのうちの１つ以上のタスクが、正常に動作しているか否かの監視対象となる監視対象タスクとして予め設定されている。ｎ個のタスク２１−１〜２１−ｎの全部を監視対象タスクとしてもよいし、そのうちの任意の一部のタスクのみを監視対象タスクとしてもよい。監視タスク２２は、周期Ｔ０で起動され、監視対象タスクの監視を所定周期Ｔ０毎に行う。監視タスク２２の処理内容は後に詳述する。

【0027】

図３は、監視タスク２２で用いられるデータの構成の一例を模式的に示す図である。本実施の形態では、監視タスク２２において、予め定められた最大タスク数（例えば、２５６個）の各々のタスクを識別するためのタスクＩＤと、各タスクＩＤにそれぞれ関連づけられ各タスクＩＤ毎に設けられたタスク起動番号、アライブチェックフラグＦ、ヘルスチェックカウント値Ｃ及びタスク名が、データとして用いられる。

【0028】

タスク起動番号は、当該タスクが監視対象であるか否かを示す番号であり、０であれば、当該タスクがｎ個のタスク２１−１〜２１−ｎのいずれでもなく実際には存在しないタスクであるか、あるいは、ｎ個のタスク２１−１〜２１−ｎのいずれかであっても当該タスクは監視対象ではないことを示す。当該タスクがｎ個のタスク２１−１〜２１−ｎのうちの監視対象とされるタスクであれば、当該タスクのタスク起動番号は、０以外の番号とされる。タスク名は、後述するログの作成等に用いられるものである。本実施の形態では、タスクＩＤ、タスク起動番号及びタスク名は、予め定められ、後述する動作では書き換えられない。一方、アライブチェックフラグＦは当該タスクに関する後述の動作で書き換えられるフラグであり、ヘルスチェックカウント値Ｃは当該タスクに関する後述の動作で書き換えられるカウント値である。

【0029】

なお、本実施の形態では、タスクＩＤ毎のタスク起動番号及びタスク名は、設定情報として不揮発性メモリ１４内に格納されており、マイクロコンピュータ２の起動時に不揮発性メモリ１４からＲＡＭ１３の所定のデータ領域に読み出される。各タスクＩＤ毎のアライブチェックフラグＦ及びヘルスチェックカウント値Ｃは、マイクロコンピュータ２の起動時にＲＡＭ１３の所定のデータ領域に設定される。これにより、マイクロコンピュータ２が起動すると、ＲＡＭ１３内に、タスクＩＤ毎に図３に示すデータが格納されることになる。本実施の形態では、ＲＡＭ１３内のアライブチェックフラグＦの記憶領域が、アライブチェックフラグＦを保持する保持部を構成している。なお、マイクロコンピュータ２の起動時に、各タスクのアライブチェックフラグＦは０に初期設定され、各タスクのヘルスチェックカウント値Ｃは後述する所定値Ｃｍａｘに初期設定される。

【0030】

図４は、図１に示す処理装置１において監視対象タスクで所定周期毎に行われる処理を示す概略フローチャートである。本実施の形態では、各監視対象タスクは、自身のタスクで行う本来の処理（前記処理プログラムに基づいて定められた本来の処理）の他に、各監視対象タスク毎に設定された所定周期毎に各監視対象タスクで呼び出されるサブルーチンの処理として、自身のタスクのアライブチェックフラグＦを１にセットする処理を行う。したがって、当該監視対象タスクがこの時点で正常に動作していれば、自身のタスクのアライブチェックフラグＦが１にセットされ、当該監視対象タスクの動作がこの時点で異常であれば、自身のタスクのアライブチェックフラグＦを１にセットすることができなくなる。

【0031】

例えば、タスク２１−１が監視対象タスクであれば、タスク２１−１において、タスク２１−１が周期Ｔ１で起動される度に毎回前記サブルーチンを呼び出して、自身のタスク２１−１のアライブチェックフラグＦを１にセットする処理を行う。この場合、タスク２１−１において、所定周期Ｔ１で、自身のタスク２１−１のアライブチェックフラグＦを１にセットする処理が行われることになる。これに限らず、タスク２１−１において、タスク２１−１が周期Ｔ１で起動される度（回）のうちｍ回（ｍは２以上の整数）に１回の割合で前記サブルーチンを呼び出して、自身のタスク２１−１のアライブチェックフラグＦを１にセットする処理を行ってもよい。この場合、タスク２１−１において、所定周期ｍ×Ｔ１で、自身のタスク２１−１のアライブチェックフラグＦを１にセットする処理が行われることになる。これらの点は、他のタスク２１−２〜２１−ｎのいずれかが監視対象タスクである場合も同様である。

【0032】

図５は、図１に示す処理装置１における監視タスク２２の処理内容を示す概略フローチャートである。本実施の形態では、監視タスク２２は、前述したように周期Ｔ０で起動される度に毎回、図５に示す処理を行う。

【0033】

監視タスク２２が起動されると、ＣＰＵ１１は、ウォッチドッグタイマクリア信号（ＷＤＴクリア信号）を出力する（ステップＳ１）。その後、ＣＰＵ１１は、ループ開始端Ｒ１でそれ以降の処理の対象となるタスクを最大タスク数のタスク（前記タスクＩＤが付与されている全てのタスク）まで順次変更しながら、ループ開始端Ｒ１以降の処理を行う。

【0034】

ＣＰＵ１１は、ループ開始端Ｒ１で処理対象となるタスク（タスクＩＤ）が設定されると、ＲＡＭ１３内の当該タスクのタスク起動番号を参照して、当該タスクが監視対象タスクであるか否かを判定し（ステップＳ２）、当該タスクが監視対象タスクでなければ（タスク起動番号が０であれば）ループ開始端Ｒ１に戻る一方、当該タスクが監視対象タスクであれば（タスク起動番号が０でなければ）ステップＳ３へ移行する。

【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】

１ 処理装置
２ マイクロコンピュータ
３ ウォッチドッグタイマ
２１−１〜２１−ｎ タスク
２２ 監視タスク
３１ 交通信号灯器
３２ 制御用ＬＳＩ
４１ 表示パネル

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】