"ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをユーザモードで実行するオペレーティングシステムと、前記オペレーティングシステムを実行するプロセッサと、を備えた制御装置であって、前記オペレーティングシステムは、前記制御タスクを実行していない期間に、カーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出する異常検出処理を実行する、制御装置。前記オペレーティングシステムは、少なくとも1つの前記制御タスクに実行時間が割り当てられる制御タイムパーティションを含む複数のタイムパーティションをスケジューリングするパーティションスケジューラを有する、請求項1に記載の制御装置。前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タイムパーティションに実行時間が割り当てられる全ての制御タスクの実行を終了して、ユーザモードからカーネルモードに切り替えたときに、前記異常検出処理を実行する、請求項2に記載の制御装置。前記オペレーティングシステムは、前記全ての制御タスクの実行を終了したときにおける前記制御タイムパーティションの残り期間が、前記異常検出処理の実行時間以上である場合に、前記異常検出処理を実行する、請求項3に記載の制御装置。前記オペレーティングシステムは、前記パーティションスケジューラが前記制御タイムパーティションに切り替えたとき、かつ前記制御タスクの実行を開始する前に、前記異常検出処理を実行する、請求項2に記載の制御装置。前記制御タイムパーティションは、複数の前記制御タスクに実行時間が割り当てられ、前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タスクの実行を終了して、次の前記制御タスクの実行を開始するまでの期間に、前記異常検出処理を実行する、請求項2に記載の制御装置。前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タスクをスケジューリングするタスクスケジューラを有する、請求項2乃至6のいずれか1項に記載の制御装置。ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをプロセッサによってユーザモードで実行する制御方法であって、前記プロセッサが、前記制御タスクが実行終了したときに、ユーザモードからカーネルモードに切り替えるステップと、前記プロセッサが、前記切り替え後のカーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出するステップと、を備えた制御方法。しかしながら、本願出願人は、特許文献1に開示されるような安全制御装置に関して、本願出願人が新たに創案した安全制御装置において、以下に説明する課題を見出した。以下、図15~17を参照して、その課題について説明する。図15は、本願出願人によって創案された安全制御装置にかかるタイムパーティションにおけるタスクの実行状況を示す図である。図15に例示するタイムパーティションでは、最初のタイムパーティションTP1以下、TP1とするに制御タスク及び故障検出タスクが実行される。なお、図15では、最初のTP1についてのみタスクの実行状況を示し、それ以降のタイムパーティションについては、図示を省略する。ここで、図16に示すように、一般的に、タスクは、ユーザ空間で動作し、オペレーティングシステムOSは、カーネル空間で動作する。つまり、タスクは、ユーザモードで動作し、OSは、カーネル空間で動作する。ここで、カーネルモードマスターモード、スーパバイザーモード、又は特権モードとも言うとは、マイクロコントローラの全てのハードウェア資源が操作可能なモードのことを言う。それに対して、ユーザモードとは、マイクロコントローラの限られたハードウェア資源のみ操作可能なモードのことを言う。なお、カーネルモード及びユーザモードとは、CPUCentralProcessingUnitプロセッサの動作モードのことである。つまり、カーネルモードでは、CPUは、マイクロコントローラの全てのハードウェア資源にアクセスでき、ユーザモードでは、CPUは、アクセスできるハードウェア資源が制限される。そのため、図15の例では、制御タスクがサービスロボットを制御するためにハードウェア資源にアクセスする場合や、故障検出タスクがサービスロボットの故障を検出するためにハードウェア資源にアクセスする場合には、ユーザモードからカーネルモードに切り替える必要がある。この切り替えは、OSに用意されたシステムコールをタスクが使用することによって行われる。つまり、タスクは、システムコールを使用することによって、OSを介して、カーネルモードでのみアクセスすることができるハードウェア資源にアクセスすることができる。図17を参照して、図15に例示したTP1における処理手順について説明する。図17は、図15に示すTP1における処理手順を示す図である。なお、図17では、図15に示す2つの制御タスクのそれぞれを、Task1及びTask2として示す。OSは、タスクスケジューリングにおいて、Task1を選択するS101。なお、S101は、カーネルモードでOSが動作する。OSは、選択したTask1を実行するS102。なお、S102では、ユーザモードでTask1が動作する。Task1の実行が終了した場合、OSは、タスクスケジューリングを行って、Task2を選択するS103。なお、S103では、カーネルモードでOSが動作する。OSは、選択したTask2を実行するS104。なお、S104では、ユーザモードでTask2が動作する。Task2の実行が終了した場合、OSは、タスクスケジューリングを行って、故障検出タスクを選択するS105。なお、S105では、カーネルモードでOSが動作する。OSは、選択した故障検出タスクの実行を開始するS106。なお、S106では、ユーザモードで、故障検出タスクが動作を開始する。故障検出タスクは、システムコールを使用して、サービスロボットの情報以下、故障検出情報とするを取得するS107。つまり、S107では、システムコールに応じて、カーネルモードでOSが動作する。システムコールにおける処理の終了後、ユーザモードに戻る。故障検出タスクは、取得した故障検出情報に基づいて、故障を検出する。故障検出タスクは、次の故障検出を開始するS108。つまり、ハードウェア資源において、S107で故障検出情報を取得した箇所とは異なる箇所からの故障検出情報の取得を開始する。なお、S108では、ユーザモードで故障検出タスクが動作する。故障検出タスクは、システムコールを使用して、故障検出情報を取得するS109。つまり、S109では、システムコールに応じて、カーネルモードでOSが動作する。システムコールにおける処理の終了後、ユーザモードに戻る。故障検出タスクは、取得した故障検出情報に基づいて、故障を検出する。故障検出タスクは、次の故障検出を開始するS110。なお、S110では、ユーザモードで、故障検出タスクが動作を開始する。以降も、同様にして、ハードウェア資源において、故障検出対象となる箇所の全てから故障検出情報を取得するまで、S108及びS109と同様の動作が繰り返され、そのたびに、ユーザモードとカーネルモードとの間で遷移が行われる。しかしながら、ユーザモードとカーネルモードとの間で遷移をする場合、コンテキストスイッチが発生する。具体的には、システムコール関数を呼び出し中における処理は、カーネルモードで実行されることになるため、これらの関数が呼び出された際には、ユーザモードのコンテキストを退避し、カーネルモードのコンテキストを読み出す必要がある。さらに、システムコール関数における処理が終了したときには、元のユーザモードのコンテキストを復元する必要がある。つまり、システムコールを使用して、ユーザモードとカーネルモードとの間での切り替えを行うと、CPUに負荷がかかってしまうという問題がある。特に、ロボット制御においては、故障検出のために検査するハードウェア数も多くなってしまう。そのため、それぞれのハードウェアにアクセスするために、システムコールを多用することで、図17を参照して説明したように、ユーザモードとカーネルモードとの間での切り替えが頻繁に行われてしまい、CPUの負荷が増大してしまうという問題も発生してしまう。さらには、このように故障検出タスクがシステムコールを多用してCPU時間を多く消費することで、故障検出タスク以外の制御タスクが利用できるCPU時間も短くなってしまうという問題も発生してしまう。本発明は、上述したような課題を解決するために、プロセッサにかかる負荷を低減することができる制御装置及び制御方法を提供することを目的とする。本発明の第1の態様にかかる制御装置は、ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをユーザモードで実行するオペレーティングシステムと、前記オペレーティングシステムを実行するプロセッサと、を備えた制御装置であって、前記オペレーティングシステムは、前記制御タスクを実行していない期間に、カーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出する異常検出処理を実行するものである。本発明の第2の態様にかかる制御方法は、ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをプロセッサによってユーザモードで実行する制御方法であって、前記プロセッサが、前記制御タスクが実行終了したときに、ユーザモードからカーネルモードに切り替えるステップと、前記プロセッサが、前記切り替え後のカーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出するステップと、を備えたものである。上述した本発明の各態様によれば、プロセッサにかかる負荷を低減することができる制御装置及び制御方法を提供することができる。以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。<発明の実施の形態1>本実施の形態1にかかる安全制御装置1は、サービスロボットや運輸機器等に搭載されて機能安全確保のための安全制御を実行する。安全制御装置1は、安全関連アプリケーションと非安全関連アプリケーションを同一のコンピュータシステムで実行するよう構成される。図1は、本実施の形態にかかる安全制御装置1の構成例を示すブロック図である。プロセッサ10は、プログラム命令ストリームの取得、命令のデコード、命令のデコード結果に応じた演算処理を行う。なお、図1では、1つのプロセッサ10のみを示しているが、安全制御装置1は、複数のプロセッサ10を有するマルチプロセッサ構成であってもよい。また、プロセッサ10は、マルチコアプロセッサでもよい。プロセッサ10は、システムプログラムとしてのオペレーティングシステムOS100を実行することによりマルチプログラミング環境を提供する。マルチプログラミング環境とは、複数のプログラムを定期的に切り替えて実行したり、あるイベントの発生に応じて実行するプログラムを切り替えたりすることによって、複数のプログラムがあたかも並列実行されているような環境を意味する。マルチプログラミングは、マルチプロセス、マルチスレッド、マルチタスク等と呼ばれる場合もある。プロセス、スレッド及びタスクは、マルチプログラミング環境で並列実行されるプログラム単位を意味する。本実施の形態のプロセッサ10が具備するマルチプログラミング環境は、マルチプロセス環境でもよいし、マルチスレッド環境でもよい。実行用メモリ11は、プロセッサ10によるプログラム実行のために使用されるメモリである。実行用メモリ11には、不揮発性メモリ13からロードされたプログラムOS100及びアプリケーション101~104等、プロセッサ10の入出力データ等が記憶される。なお、プロセッサ10は、プログラムを不揮発性メモリ13から実行用メモリ11にロードすることなく、これらのプログラムを不揮発性メモリ13から直接実行してもよい。具体的には、実行用メモリ11は、SRAMStaticRandomAccessMemory、DRAMDynamicRandomAccessMemory等のランダムアクセス可能な揮発性メモリとすればよい。図1の実行用メモリ11は、論理的な構成単位を示している。すなわち、実行用メモリ11は、例えば、複数のSRAMデバイスの組み合わせ、複数のDRAMデバイスの組み合わせ、又はSRAMデバイスとDRAMデバイスの組み合わせでもよい。I/Oポート12は、外部デバイスとの間のデータ送受信に使用される。例えば、安全制御装置1がサービスロボットに搭載される場合であれば、外部デバイスは、サービスロボット周囲の障害物を計測可能な視覚センサ、サービスロボットの姿勢を検知するためのセンサ、及びサービスロボットのアクチュエータの状態を検知するためのセンタ等のサービスロボットの内外の状態を示す情報を取得する各種センサ、並びに、サービスロボットを動作させるアクチュエータ等である。不揮発性メモリ13は、電力の供給を受けることなく、実行用メモリ11に比べて安定的に記憶内容を維持することが可能なメモリデバイスである。例えば、不揮発性メモリ13は、ROMReadOnlyMemory、フラッシュメモリ、ハードディスクドライブ若しくは光ディスクドライブ、又はこれらの組み合わせである。不揮発性メモリ13は、OS100及びアプリケーション101~104を格納する。なお、不揮発性メモリ13の少なくとも一部は安全制御装置1から取り外し可能に構成されてもよい。例えば、アプリケーション101~104が格納されたメモリを取り外し可能としてもよい。また、不揮発性メモリ13の少なくとも一部は、安全制御装置1の外部に配置されてもよい。OS100は、プロセッサ10によって実行されることにより、プロセッサ10及び実行用メモリ11及び不揮発性メモリ13等のハードウェア資源を利用して、タスクスケジューリングを含むタスク管理、割り込み管理、時間管理、資源管理、タスク間同期およびタスク間通信機構の提供等を行う。さらに、機能安全の確保に関連する安全制御アプリケーション104の通常制御アプリケーション103からの独立性を高めるため、OS100は、ハードウェア資源を、時間的および空間的に保護する機能を有する。ここで、ハードウェア資源とは、プロセッサ10、実行用メモリ11、I/Oポート12を含む。このうち、時間的な保護は、プロセッサ10の実行時間という時間的な資源をパーティショニングすることにより行う。具体的に述べると、時間的な保護は、プロセッサ10の実行時間をパーティショニングし、各パーティションタイムパーティションと呼ぶにタスクプロセス又はスレッドを割り当てることにより行う。OS100のスケジューリング機能パーティションスケジューラ21は、各タイムパーティション以下、TPと略称する場合がある。に割り当てられたタスクに対して、プロセッサ10の実行時間を含む資源の利用を保証する。図2は、タイムパーティショニングに関する概念図である。図2の例では、予め定められた1サイクル時間を3つのTP1、TP2及びTP3に分割する例を示している。例えば、1サイクル時間を100Tickとした場合、このうち前半の20TickがTP1、中間の30TickがTP2、後半の50TickがTP3と規定される。また、図2の例では、第1アプリケーションAPL1~第4アプリケーションAPL4が、TP1~TP3のいずれかに割り当てられている。OS100のスケジューリング機能パーティションスケジューラ21は、時間の経過に応じて、TP1~TP3のいずれをアクティブにするかを選択決定する。そして、アクティブなTPに割り当てられているアプリケーションが、プロセッサ10で実行される。一方、空間的な保護は、実行用メモリ11及びI/Oポート12を含む固定的な資源をパーティショニングし、各パーティションリソースパーティションと呼ぶにタスクを割り当てることにより行う。OS100のスケジューリング機能パーティションスケジューラ21は、予め割り当てられたリソースパーティション以下、RPと略称する場合がある。を超えてタスクが他のリソースにアクセスすることを禁止する。図3は、リソースパーティショニングに関する概念図である。図3の例では、2つのRPRP1及びRP2を示している。RP1には、実行用メモリ11及び不揮発性メモリ13の一部A領域と、I/Oポート12の一部ポートAが割り当てられている。また、RP2には、実行用メモリ11及び不揮発性メモリ13の他の一部B領域と、I/Oポート12の他の一部ポートBが割り当てられている。RP1からはRP2に割り当てられたリソースへのアクセスが禁止され、RP2からはRP1に割り当てられたリソースへのアクセスが禁止される。なお、全てのリソースがいずれかのRPに排他的に割り当てられてもよく、複数のRPによって共有されるリソースがあってもよい。例えば、サービスロボットの安全制御を行う場合、アクチュエータに、通常制御アプリケーション103及び安全制御アプリケーション104の双方からアクセスできるようにしてもよい。よって、通常制御アプリケーション103が属するRPと安全制御アプリケーション104が属するRPによって、アクチュエータを制御するためのI/Oポート12を共有するようにしてもよい。なお、本実施の形態では、制御アプリケーション101、102が属するRPに、I/Oポート12の全てが割り当てられる場合について例示する。図1に戻り説明を続ける。アプリケーション101~104は、OS100及びプロセッサ10によって提供されるマルチプログラミング環境で実行される。このうち、制御アプリケーション101、102のそれぞれは、サービスロボット等の制御対象を制御する制御手順をプロセッサ10に実行させるための命令コードを含む。さらに、制御アプリケーション101、102のそれぞれは、パーティションスケジューラ21への結果通知をプロセッサ10に実行させるための命令コードを含む。つまり、制御アプリケーション101、102のそれぞれは、非安全関連アプリケーションである。また、通常制御アプリケーション103は、サービスロボット等の制御対象に通常の機能動作を行わせるための制御手順をプロセッサ10に実行させるための命令コードを含む。さらに、通常制御アプリケーション103は、パーティションスケジューラ21への結果通知をプロセッサ10に実行させるための命令コードを含む。つまり、通常制御アプリケーション102は、非安全関連アプリケーションである。また、安全制御アプリケーション104は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御手順をプロセッサ10に実行させるための命令コードを含む。さらに、安全制御アプリケーション104は、パーティションスケジューラ21への結果通知をプロセッサ10に実行させるための命令コードを含む。つまり、安全制御アプリケーション104は、安全関連アプリケーションである。リセット回路14は、OS100からの信号に基づき、マイクロコントローラ15のリセットを行う。パーティションスケジューラ21からリセット回路14に定期的に送信信号を送信し、リセット回路14は、パーティションスケジューラ21からの送信信号が途絶えた場合に、マイクロコントローラ15をリセットする。例えば、パーティションスケジューラ21は、後述するような、1Tickごとに動作するタイミングで、送信信号をリセット回路14に送信する。また、パーティションスケジューラ21は、OS100で異常を検知した場合、又は、アプリケーション101~104から異常を示す結果通知を受けた場合に、リセット回路14にリセット信号を送信するようにして、それに応じて、リセット回路14がマイクロコントローラ15をリセットするようにしてもよい。このようにすることで、マイクロコントローラ15に不具合が発生した場合に、マイクロコントローラ15をリセットして復旧することができる。続いて以下では、パーティションスケジューラ21と、アプリケーション101~104の起動により生成されるタスクと、の関係について、図4を用いて説明する。図4は、OS100によって提供されるマルチプログラミング環境で起動される、パーティションスケジューラ21とタスク24、25、27、29との関係を示す図である。マイクロコントローラ15は、プロセッサ10、実行用メモリ11、I/Oポート12、不揮発性メモリ13等を含む。なお、図4では、マイクロコントローラ15の外部にリセット回路14を備える構成を例示しているが、マイクロコントローラ15の内部にリセット回路14を含む構成としてもよい。マイクロコントローラ15には、外部のクロック源図示せずからのクロック信号が供給され、プロセッサ10等は、このクロック信号に基づく所定のタイマー周期で動作する。本実施の形態では、所定のタイマー周期を、1Tickであるとして説明する。このため、プロセッサ10によりOS100が実行されることで、パーティションスケジューラ21が1Tickごとに動作すると共に、各TPにおいて、タスクスケジューラ23、26、28およびタスク制御タスク24、25、通常制御タスク27、安全制御タスク29が1Tickごとに動作する。ここで、OS100と、OS100に含まれる、パーティションスケジューラ21及びタスクスケジューラ23、26、28のそれぞれは、カーネルモードで実行され、タスク24、25、27、29は、ユーザモードで実行される。言い換えると、OS100、パーティションスケジューラ21、及びタスクスケジューラ23、26、28は、カーネル空間で動作し、タスク24、25、27、29は、ユーザ空間で動作する。ここで、I/Oポート12には、ユーザモード及びカーネルモードのうち、カーネルモードのみでアクセス可能であるものとする。つまり、本実施の形態では、サービスロボット等の制御対象には、カーネルモードでのみアクセス可能である。したがって、制御タスク24、25は、I/Oポート12にアクセスして、サービスロボット等の制御対象のアクチュエータを制御する場合及びセンサのセンサ値を取得する場合には、OS100に用意されたシステムコールを使用することによって、ユーザモードからカーネルモードに切り替えて、I/Oポート12にアクセスする必要がある。つまり、OS100は、制御タスク24、25がI/Oポート12にアクセスするためのインタフェースとなるシステムコールを有する。ここで、具体的にシステムコールが使用されたときの動作について説明する。制御タスク24、25は、アクチュエータを制御する場合、アクチュエータを制御する指令値を引数として指定してシステムコール関数を呼び出す。OS100は、システムコール関数が呼び出されると、ユーザモードからカーネルモードに切り替えて、指定された指令値をI/Oポート12に対して出力する。そして、OS100は、再びカーネルモードからユーザモードに切り替える。これによって、制御タスク24、25は、システムコール関数から復帰する。また、制御タスク24、25は、センサのセンサ値を取得する場合、システムコール関数を呼び出す。OS100は、システムコール関数が呼び出されると、ユーザモードからカーネルモードに切り替えて、I/Oポート12からセンサ値を取得する。そして、OS100は、再びカーネルモードからユーザモードに切り替えて、取得したセンサ値をシステムコール関数の戻り値とする。これによって、制御タスク24、25は、システムコール関数から復帰して、システムコール関数の戻り値をセンサ値として取得することができる。OS100は、サービスロボット等の制御対象の異常を検知するルーチンが含まれている。OS100は、I/Oポート12を介して、サービスロボット等の制御対象が有するセンサのセンサ値を取得して、取得したセンサ値に基づいて、サービスロボット等の制御対象の異常を検知する。OS100は、サービスロボット等の制御対象の異常を検知した場合、図5A、Bを参照して後述するような、TPのスケジューリングパターンを、異常が検知された場合に適用されるスケジューリングパーティションに切り替える。パーティションスケジューラ21は、1Tickごとに動作し、TPの切り替えパーティションスケジューリングを行う。パーティションスケジューラ21は、次の1Tickの間にTP1~TP3のいずれをアクティブにするかを選択決定する。さらに、パーティションスケジューラ21は、選択したTPに関するタスクスケジューラの動作を開始させる。パーティションスケジューラ21によるパーティションスケジューリングについて具体的に述べると、パーティションスケジューラ21は、スケジューリングテーブル22を参照し、TPの設定を定めたスケジューリングパターンに従って、パーティションスケジューリングを行う。スケジューリングテーブル22は、TPの切り替え順序およびタイミングを規定したスケジューリングパターンを保持している。なお、スケジューリングテーブル22は、少なくとも2つの異なるスケジューリングパターンを保持している。1つは、OS100によって異常が検知されていない場合つまり通常時に適用されるスケジューリングパターンである。もう1つは、OS100によって異常が検知された場合に適用されるスケジューリングパターンである。以下では、通常時に適用されるスケジューリングパターンを通常制御スケジューリングパターンと呼ぶ。また、異常検知時に適用されるスケジューリングパターンを安全制御スケジューリングパターンと呼ぶ。図5Aは、通常制御スケジューリングパターンの具体例を示している。図5Aでは、制御タスク24、25が属するTP1が1サイクル時間の前半T1に割り当てられている。また、通常制御タスク27が属するTP2が1サイクル時間の後半T2に割り当てられている。図5Aのスケジューリングパターンによれば、制御タスク24、25と通常制御タスク27が繰り返しスケジューリングされる。図5Bは、安全制御スケジューリングパターンの具体例を示している。図5Bでは、制御タスク24、25が属するTP1が1サイクル時間の前半T3に割り当てられている。また、安全制御タスク29が属するTP3が1サイクル時間の後半T4に割り当てられている。図5Bのスケジューリングパターンによれば、制御タスク24、25と安全制御タスク29が繰り返しスケジューリングされる。図4に戻り説明を続ける。タスクスケジューラ23、26、28は、それぞれが属するTP内でのタスクのスケジューリングを行う。各TP内でのタスクのスケジューリングには、一般的な優先度ベースのスケジューリングを適用すればよい。なお、図4では、各TP2及び3はそれぞれ1つのタスクのみを含み、TP1は2つのタスクのみを含む場合について図示しているが、1又は2以上のタスクが含まれるようにしてもよい。例えば、通常制御用のTP2内には、通常制御タスクA及び通常制御タスクBの2つのタスクが含まれていてもよい。制御タスク24は、制御アプリケーション101の起動によって生成されるタスクであり、制御タスク25は、制御アプリケーション102の起動によって生成されるタスクである。図4の例では、制御タスク24、25は、TP1及びRP1に割り当てられている。制御タスク24、25のそれぞれは、サービスロボット等の制御対象を制御する。具体的は、制御タスク24、25のそれぞれは、アクチュエータの指令値をI/Oポート12に出力することによって、アクチュエータを制御する。この指令値は、後述するように、通常制御タスク27又は安全制御タスク29から取得する。さらに、制御タスク24、25は、タスクの実行状況を、パーティションスケジューラ21へ通知する。通常制御タスク27は、通常制御アプリケーション103の起動によって生成されるタスクである。図4の例では、通常制御タスク27は、TP2及びRP2に割り当てられている。通常制御タスク27は、サービスロボット等の制御対象に通常の機能動作を行わせるための制御を行う。具体的には、通常制御タスク27は、アクチュエータの制御計算をして、アクチュエータの指令値を算出する。例えば、サービスロボット等の制御対象に通常動作をさせる指令値となる。通常制御タスク27は、算出した指令値を制御タスク24、25のそれぞれに出力する。さらに、通常制御タスク27は、タスクの実行状況を、パーティションスケジューラ21へ通知する。安全制御タスク29は、安全制御アプリケーション104の起動によって生成されるタスクである。図4の例では、安全制御タスク29は、TP3及びRP3に割り当てられている。安全制御タスク29は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御を行う。具体的には、安全制御タスク29は、アクチュエータの制御計算をして、アクチュエータの指令値を算出する。例えば、サービスロボット等の制御対象を安全方向に動作させる又は停止させる指令値となる。安全制御タスク29は、算出した指令値を制御タスク24、25のそれぞれに出力する。さらに、安全制御タスク29は、タスクの実行状況を、パーティションスケジューラ21へ通知する。なお、各タスクからパーティションスケジューラ21へと結果を通知する具体的な構成としては、様々な手法を採用することができる。例えば、タスクがOS100のシステムコールサービスコールを呼び出し、OS100を介して、パーティションスケジューラ21に結果を通知することができる。また、例えば、タスクの実行状況に関するフラグを実行用メモリ11に格納するものとして、タスクがその実行状況に応じてフラグの値を設定し、パーティションスケジューラ21がフラグの設定値に応じてタスクの実行状況を判断することもできる。上述したように、パーティションスケジューラ21が1Tickごとに動作し、TP1~TP3のいずれをアクティブにするかを選択決定する。さらに、パーティションスケジューラ21が、選択したTPに関するタスクスケジューラの動作を開始させる。そして、タスクスケジューラ23、26、28が動作を開始することでタスクのスケジューリングが行われ、プロセッサ10が、タスクスケジューラ23、26、28によりスケジューリングされた順序に従って、TP内でのタスクを実行していく。これによって、アクティブなTPに割り当てられているアプリケーションが、プロセッサ10で実行される。続いて以下では、発明の実施の形態1にかかるパーティションスケジューラ21によるパーティションスケジューリングについて、図6を用いて説明する。図6は、発明の実施の形態1にかかるパーティションスケジューリングにおける処理手順の具体例を示すフローチャートである。まず、1Tickごとに動作するパーティションスケジューラ21が、TP1のタスクスケジューラ23を動作させるS11。なお、図6では、通常制御スケジューリングパターン例えば図5Aまたは安全制御スケジューリングパターン例えば図5Bに従って、スケジューリングを実行する場合を例に説明する。すなわち、TP1に続く次のTPはTP2又はTP3であり、かつ、OS100によって、サービスロボット等の制御対象に故障等の何らかの異常が検知された場合に、TP1の次に選択決定されるTPがTP3である場合を例に説明する。つまり、最初のまだ異常が検知されていない状態では、TP1の次に選択決定されるTPがTP2である場合を例に説明する。つまり、通常時は、通常制御スケジューリングパターンを参照してTPのスケジューリングを行い、異常の検知後は、安全制御スケジューリングパターンを参照してTPのスケジューリングを行う場合を例に説明する。つまり、後述するTPXの初期値が、TPX=TP2である場合について説明する。S11で動作を開始したTP1のタスクスケジューラ23は、TP1内の制御タスク24、25を優先度に応じて実行するS12。なお、ここでは、TP1内の制御タスク24、25で実行状態又は実行可能状態となっている制御タスクがある場合に、そのうちのいずれかの制御タスクが実行される。つまり、TP1内の制御タスク24、25がいずれも実行状態及び実行可能状態のいずれの状態にもなっていない場合、制御タスクは実行されない。実行状態及び実行可能状態のいずれの状態にもなっていない場合とは、待ち状態、休止状態、強制待ち状態又は二重待ち状態等である。ここで、制御タスク24、25は、例えば、通常制御タスク27及び安全制御タスク29のいずれからも指令値を取得していない場合、もしくは、通常制御タスク27又は安全制御タスク29からの指令値の取得に応じたアクチュエータの制御処理の実行が終了している場合には、待ち状態となっている。そして、制御タスク24、25は、例えば、通常制御タスク27又は安全制御タスク29から指令値を取得したときに、待ち状態から実行可能状態に遷移する。制御タスク24、25は、例えば、タスク間通信によって、通常制御タスク27又は安全制御タスク29から指令値を取得することで、待ち状態から起床して実行可能状態となる。S12で制御タスク24、25のいずれかの実行が終了した場合、OS100は、TP1内に実行する制御タスク24、25がないか否かを判定するS13。TP1内に実行する制御タスク24、25がないか否かは、例えば、TP1内の制御タスク24、25が実行状態及び実行可能状態のいずれの状態にもなっていないか否かによって判定する。TP1内に実行する制御タスク24、25がない場合S13でYes、OS100は、故障検出処理を実行するS14。具体的には、OS100は、I/Oポート12を介して、サービスロボット等の制御対象のセンサ値を取得する。OS100は、取得したセンサ値が、正常値の範囲内か否かを判定する。ここで、正常値は、例えば、実行用メモリ11に予め格納しておき、OS100が参照可能としておく。OS100は、センサ値が正常値の範囲内に収まっている場合、サービスロボット等の制御対象は故障していないと判定する。OS100は、センサ値が正常値の範囲内に収まっていない場合、サービスロボット等の制御対象が故障していると判定する。すなわち、この場合、サービスロボット等の制御対象の故障が検出されことになる。言い換えると、サービスロボット等の制御対象の異常が検知されたことになる。OS100は、故障検出処理によって、サービスロボット等の制御対象の故障を検出した場合S15でYes、後述するTPXを、TPX=TP3とするS16。つまり、OS100は、パーティションスケジューラ21が参照するスケジューリングパターンを、通常制御スケジューリングパターンから安全制御スケジューリングパターンに切り替える。一方で、1Tickが経過すると、パーティションスケジューラ21が、TPのスケジューリングを開始するS17。すなわち、パーティションスケジューラ21は、スケジューリングパターンに従って、次の1Tickの間にいずれのTPをアクティブにするかを選択決定する。パーティションスケジューラ21は、次にアクティブにするTPを変更しないS18でNo場合には、S11に戻り、同一のTP1についての動作を継続させる。このため、TP1の切り替えタイミングとなるまでの間、S11~S16までの処理が繰り返される。なお、このときに、S12でTP1内に実行する制御タスク24、25がない場合S13でYesは、故障検出処理S14が継続されることになる。パーティションスケジューラ21は、次にアクティブにするTPを変更するS18でYes場合には、その変更するタイムパーティションのタスクスケジューラを動作させるS19。ここでは、TPXのタスクスケジューラを動作させる。ここで、変数XはTPの番号を示す。すなわち、S19では、TP1を除いた、TP2又はTP3のいずれかを動作させる。そして、TPXのタスクスケジューラが、TPX内のタスクを優先度に応じて実行するS20。S20でも、S12と同様に、TPX内のタスクの状態に応じて、タスクが実行される。1Tickが経過すると、パーティションスケジューラ21が、再びスケジューリングを開始するS21。パーティションスケジューラ21は、スケジューリングパターンに従って、次の1Tickの間にいずれのTPをアクティブにするかを選択決定し、次にアクティブにするTPを変更しないS22でNo場合には、S19に戻り、TPXについての動作を継続させる。パーティションスケジューラ21は、次にアクティブにするTPを変更するS22でYes場合には、次の1Tickの間にアクティブにするTPとして、TP1を選択決定するS23。図6で示した処理に関して、パーティションスケジューリングの具体例を説明する。まず、図5Aに例示した通常制御スケジューリングパターンに従って、S11においてスケジューリングを開始した場合を説明する。この場合、S11ではTPX=TP2として開始し、S12~S18にかけては、TP1のままである。そして、サービスロボット等の制御対象の故障が検出されなければ、S19でTP1からTP2へと変更され、S19~S22にかけてTP2のままであるつまり、TP2から開始する通常制御スケジューリングパターンが継続される。。一方で、S15でサービスロボット等の制御対象の故障を検出したと判定されていた場合には、S16で、TPX=TP3となるつまり、TP3から開始する安全制御スケジューリングパターンに切り替わる。。なお、上述の例では、スケジューリングパターンとして、3つのTP安全監視制御用のTP1、通常制御用のTP2、安全制御用のTP3のみを組み合わせた場合を例に説明したが、TP2のような通常制御用パーティションや、TP3のような安全制御用パーティションを、それぞれ複数個存在するものとしてもよい。例えば、2つの通常制御用のTP2及びTP4と、安全監視制御用のTP1と、2つの安全制御用のTP3及びTP5と、が存在し、これら5つのTPTP1~TP5を組み合わせてスケジューリングパターンを構成してもよい。この場合、S16では、サービスロボット等の制御対象の異常状態の種類を判定し、その異常種類に応じて、安全制御用のTP3またはTP5のいずれかを選択するようにしてもよい。上述したように、本実施の形態では、OS100は、サービスロボット等の制御対象の故障の検出に応じたスケジューリングパターンに基づいて、次にアクティブとするパーティションを選択決定するパーティションスケジューラ21を備えている。パーティションスケジューラ21は、各TPにおいて実行されるタスクとは独立して、所定のタイマー周期で動作する。さらに、図6で例示した処理では、OS100における故障検出結果に応じて、安全制御用のTP3を選択決定するS16ものとして説明したが、本発明はこれに限定されない。例えば、TP1~TP3のそれぞれからパーティションスケジューラ21に対して実行状況を通知する構成とし、パーティションスケジューラ21が、各TPからの結果通知に応じて、安全制御用のTP3を選択決定するものとしてもよい。独立に動作するパーティションスケジューラ21が、全てのTPから結果通知を受ける構成とすることで、パーティションスケジューラ21は、全てのTPに関する状況を一元的に把握することができる。このため、例えば、安全監視制御用のTP1からの結果通知に応じて、パーティションスケジューラ21が次のパーティションを決定選択しようとする場合には、パーティションスケジューラ21は、各TPの状況を考慮した上で、正常状態にあるTPのみから次のパーティションを決定選択することができる。従って、従来技術と比較して、より正確なパーティションスケジューリングを実現することができるという効果を奏する。続いて、図7及び図8を参照して、発明の実施の形態1にかかるTP1における処理手順をより具体的に説明する。図7は、発明の実施の形態1にかかるTPにおけるタスクの実行状況を示す図である。図8は、発明の実施の形態1にかかるTP1における処理手順を示すフローチャートである。なお、図7及び図8では、制御タスク24をTask1として示し、制御タスク25をTask2として示す。また、図7では、最初のTP1についてのみタスクの実行状況を示し、それ以降のTPについては、図示を省略する。まず、Task1及びTask2が実行可能状態となっているものとする。パーティションスケジューラ21は、TPをTP1に切り替えたときに、タスクスケジューラ23を動作させる。タスクスケジューラ23は、Task1を選択するS31。なお、S31では、カーネルモードでタスクスケジューラ23が動作する。そして、タスクスケジューラ23は、選択したTask1を実行するS32。なお、S32では、ユーザモードでTask1が動作する。S31及びS32、図6のS12に対応する。Task1の実行が終了した場合、タスクスケジューラ23は、Task2を選択するS33。Task1の実行が終了した場合とは、例えば、Task1が予定されていた処理を全て実行し、スリープして待ち状態となった場合等である。そのため、タスクスケジューラ23は、残りの実行可能状態となっているTask2を選択する。なお、S33では、カーネルモードでタスクスケジューラ23が動作する。そして、タスクスケジューラ23は、選択したTask2を実行するS34。なお、S34では、ユーザモードでTask2が動作する。S33及びS34は、図6のS12に対応する。TP1内の全てのTask1及びTask2の実行が終了し、TP1内に実行するタスクがなくなった場合、OS100は、TP1に故障検出処理を実行するだけの残り時間があるか否かを判定するS35。言い換えると、TP1の残り時間が、故障検出処理の実行時間以上であるか否かを判定する。残り時間は、TP1に対して割り当てられる時間から、TP1に切り替わってからの経過時間を減算することで算出する。ここで、TP1に対して割り当てられる時間は、例えば、実行用メモリ11に予め格納しておき、OS100が参照可能としておく。TP1に切り替わってからの経過時間は、例えば、OS100が、TP1に切り替わってからのTickの発生回数をカウントすることで算出する。また、故障検出処理の実行時間も、例えば、実行用メモリ11に予め格納しておき、OS100が参照可能としておく。故障検出処理の実行時間は、事前に故障検出処理の時間を計測することで決定してもよく、処理内容から処理にかかる時間を推定して決定してもよい。TP1に対して割り当てられる時間及び故障検出処理の実行時間も、Tick数として用意しておくことで、単純に、TP1に対して割り当てられる時間から経過時間を減算するだけでTP1の残り時間が算出でき、TP1の残り時間と故障検出処理の実行時間とを比較するだけで、TP1の残り時間が故障検出処理の実行時間以上であるか否かを判定することができる。TP1に故障検出処理を実行するだけの残り時間があると判定した場合S35でYes、OS100は、故障検出処理を実行するS36。TP1に故障検出処理を実行するだけの残り時間がないと判定した場合S35でNo、OS100は、故障検出処理は実行しない。S35及びS36は、図6のS14に対応する。そして、TP1に割り当てられた時間が満了した場合、パーティションスケジューラ21は、TPをTP2又はTP3に切り替えるS37。S37は、S19でYesに対応する。なお、S35~37では、カーネルモードでOS100及びパーティションスケジューラ21が動作する。以上に説明したように、本実施の形態1では、OS100が、TP1において、TP1に属する全ての制御タスク24、25の実行を終了して、ユーザモードからカーネルモードに切り替えたときに、カーネルモードで、故障検出処理を行うようにしている。これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。例えば、故障検出のために確認する必要があるハードウェア数が多かったとしても、図17のS106以降に示すように、ユーザモードとカーネルモードとの間での切り替えが多発しないようにすることができる。したがって、本実施の形態1によれば、プロセッサにかかる負荷を低減することができる。また、本実施の形態1では、OS100が、TP1内の全ての制御タスク24、25の実行を終了したときにおけるTP1の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにしている。これによれば、スケジューリングパターンによって、TP1に割り当てられている時間を超過して故障検出処理が継続実行されることによって、TP1の期間が本来TP1に割り当てられている時間を超過してしまうことを防止することができる。具体的には、本実施の形態1では、OS100が、カーネルモードで、故障検出処理を実行するようにしている。そのため、TP1に割り当てられている時間が満了するまでに、故障検出処理が終了していない場合、パーティションスケジューラ21が、TP2に切り替えても、OS100によって故障検出処理が継続して実行されてしまう。したがって、TP1で実行されるべき故障検出処理がTP2の期間を浸食して実行されてしまうことになり、実質的にTP1の期間が本来TP1に割り当てられている時間を超過する結果を招いてしまう。これに対して、本実施の形態1のように、TP1の残り期間が、故障検出処理の実行時間以上であるのみに場合に、故障検出処理を実行するようにすることで、このような事態を防止することができる。<発明の実施の形態2>続いて、本実施の形態2にかかる安全制御装置について説明する。本実施の形態2にかかる安全制御装置の構成は、実施の形態1にかかる安全制御装置1と同様であるため、説明を省略する。以下、図9~11を参照して、本実施の形態2にかかる安全制御装置1の処理手順について説明する。なお、図9及び図11では、実施の形態1と同様の処理には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。まず、発明の実施の形態2にかかるパーティションスケジューラ21によるパーティションスケジューリングについて、図9を用いて説明する。図9は、発明の実施の形態2にかかるパーティションスケジューリングにおける処理手順の具体例を示すフローチャートである。本実施の形態2では、図9に示すように、実施の形態1と異なり、パーティションスケジューラ21がTPをTP1に切り替えたときS22でYesに、OS100が、故障検出処理を実行するS14。そして、故障検出処理S14及びそれに付随する処理S15、S16の実行後に、OS100は、TP1のタスクスケジューラ23を動作させてS11、TP1内の制御タスク24、25の実行を開始するS12。このように、本実施の形態2では、TPがTP1に切り替わったときS22でYesに、故障検出処理S14を実行するようにしている。それに伴い、本実施の形態2では、実施の形態1のように、TP1内の制御タスク24、25の実行終了後には、TP1内に実行する制御タスクがあるか否かの判定S13及びその判定結果に応じての故障検出処理等S14~16は行わない。続いて、図10及び図11を参照して、発明の実施の形態2にかかるTP1における処理手順をより具体的に説明する。図10は、発明の実施の形態2にかかるTPにおけるタスクの実行状況を示す図である。図11は、発明の実施の形態2にかかるTP1における処理手順を示すフローチャートである。なお、図10及び図11では、制御タスク24をTask1として示し、制御タスク25をTask2として示す。また、図10では、最初のTP1についてのみタスクの実行状況を示し、それ以降のTPについては、図示を省略する。本実施の形態2では、図10及び図11に示すように、実施の形態1と異なり、パーティションスケジューラ21が、TPをTP1に切り替えたときに、OS100が故障検出処理を実行するようにしているS36。このようにすることで、パーティションスケジューラ21がカーネルモードで実行されることを利用して、そのカーネルモードのまま、ユーザモードとカーネルモードとの間の切り替えを発生させることなく、OS100が故障検出処理を実行することができる。ここで、OS100は、予め設定された設定時間の間、故障検出処理を実行するものとする。設定時間としては、例えば、Task1及びTask2がTP1内で実行することが必須となっている場合には、Task1及びTask2の実行に最も長く時間がかかったとしても、TP1内でTask1及びTask2の実行が終了できるような時間を設定する。設定時間は、例えば、実行用メモリ11に予め格納しておき、OS100が参照可能としておく。また、設定時間は、安全制御装置1の利用者によって予め設定されるものとする。例えば、安全制御装置1に入力装置図示せずを備えるようにして、利用者が入力装置を介して、設定時間を入力して設定するようにする。入力装置は、例えば、マウス、キーボード若しくはタッチパネル等、又はこれらの組み合わせである。そして、故障検出処理S36が終了したときに、OS100が、TP1のタスクスケジューラ23を動作させる。タスクスケジューラ23は、Task1を選択するS31。以降、S31~S34が実行される。そして、Task2の実行S34が終了した後に、TP1に割り当てられた時間が満了した場合、パーティションスケジューラ21は、TPをTP2又はTP3に切り替えるS37。以上に説明したように、本実施の形態2では、OS100が、パーティションスケジューラ21がTP1に切り替えたとき、かつ制御タスク24,25の実行を開始する前のカーネルモードで、故障検出処理を行うようにしている。これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。したがって、本実施の形態2によれば、プロセッサにかかる負荷を低減することができる。<発明の実施の形態3>続いて、本実施の形態3にかかる安全制御装置について説明する。本実施の形態3にかかる安全制御装置の構成は、実施の形態1にかかる安全制御装置1と同様であるため、説明を省略する。以下、図12~14を参照して、本実施の形態3にかかる安全制御装置1の処理手順について説明する。なお、図12及び図14では、実施の形態1と同様の処理には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。まず、発明の実施の形態3にかかるパーティションスケジューラ21によるパーティションスケジューリングについて、図12を用いて説明する。図12は、発明の実施の形態3にかかるパーティションスケジューリングにおける処理手順の具体例を示すフローチャートである。本実施の形態3では、図12に示すように、実施の形態1と異なり、S12で制御タスク24、25のいずれかの実行が終了した場合に、OS100は、TP1に属する制御タスク24、25が予め定めた設定数だけ実行終了したか否かを判定するS23。そして、TP1に属する制御タスク24、25が予め定められた設定数だけ実行終了したと判定した場合S23でYesに、OS100は、故障検出処理を実行するS14。具体的には、OS100は、制御タスクの実行を終了するごとに、実行が終了した制御タスクの数をカウントするようにする。そして、カウントした数と、予め定めた設定数とを比較して、一致した場合に、故障検出処理を実行するS14ようにする。ここで、設定数は、例えば、実行用メモリ11に予め格納しておき、OS100が参照可能としておく。また、カウントした、実行終了した制御タスクの数についても、OS100が、実行用メモリ11に格納してカウントするごと更新していくようにすることで、後の判定時S23に参照可能としておく。なお、設定数は、実施の形態2で説明した設定時間のように、入力装置を介して、利用者によって予め設定されるようにしてもよい。さらに、上述した実施の形態2と同様に、故障検出処理の実行時間についても、利用者が予め設定するようにしてもよい。なお、1Tickが経過したときにS17、パーティションスケジューラ21は、次にアクティブにするTPを変更しないS18でNo場合には、S11に戻り、同一のTP1についての動作を継続させるが、このときに、TP1に属する制御タスク24、25が予め定めた設定数だけ実行終了している場合S23でYesは、故障検出処理S14が継続されることになる。続いて、図13及び図14を参照して、発明の実施の形態3にかかるTP1における処理手順をより具体的に説明する。図13は、発明の実施の形態3にかかるTPにおけるタスクの実行状況を示す図である。図14は、発明の実施の形態3にかかるTP1における処理手順を示すフローチャートである。なお、図13及び図14では、制御タスク24をTask1として示し、制御タスク25をTask2として示す。また、図13では、最初のTP1についてのみタスクの実行状況を示し、それ以降のTPについては、図示を省略する。本実施の形態3では、図13及び図14に示すように、実施の形態1と異なり、Task1の実行S32が終了したときに、OS100が故障検出処理を実行するようにしているS36。このようにすることで、Task1の実行が終了して、タスクスケジューリングのためにカーネルモードに切り替わることを利用して、そのカーネルモードのまま、ユーザモードとカーネルモードとの間の切り替えを発生させることなく、OS100が故障検出処理を実行することができる。つまり、本実施の形態3では、設定数が1である場合について例示している。そして、故障検出処理S36が終了したときに、OS100が、タスクスケジューラ23を動作させる。タスクスケジューラ23は、Task2を選択するS33。そして、Task2の実行S34が終了した後に、TP1に割り当てられた時間が満了した場合、パーティションスケジューラ21は、TPをTP2又はTP3に切り替えるS37。以上に説明したように、本実施の形態3では、OS100が、TP1において、制御タスク24の実行を終了して、次の制御タスク25の実行が開始されるまでのカーネルモードで、故障検出処理を行うようにしている。これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。したがって、本実施の形態2によれば、プロセッサにかかる負荷を低減することができる。以上に説明したように、本実施の形態1~3では、いずれも、OS100が、制御タスク24、25を実行していない期間に、カーネルモードで、制御対象から情報を取得して、取得した情報に基づいて制御対象の異常を検出する異常検出処理を実行するようにしている。なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。例えば、実施の形態では、TP1において、制御タスクと、OS100による故障検出処理とを実行するようにしているが、これに限られない。例えば、制御タスク及び故障検出処理のうち、制御タスクのみを実行するTPを備えるようにしてもよく、故障検出処理のみを実行するTPを備えるようにしてもよい。また、実施の形態1において、TP1の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにしているが、これに限られない。TP1における全ての制御タスクの実行が終了した時点で、故障検出処理を実行するようにしてもよい。この場合に、実施の形態2と同様に、予め設定された設定時間の間、故障検出処理を実行するようにしてもよい。ただし、好ましくは、TP1の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにすることで、上述したように、TP1の期間が本来TP1に割り当てられている時間を超過する事態を防止することができる。また、本実施の形態では、タイムパーティショニングを行うOSに適用した場合について例示したが、これに限られない。タイムパーティショニングは行わない、マルチタスクOSに適用するようにしてもよい。"