JP5906584B2 - 制御装置及び制御方法 - Google Patents

Description

本発明は、制御装置及び制御方法に関し、特に機能安全の確保のためにサービスロボットおよび輸送機器等に搭載される制御装置に関する。

サービスロボットは、外界センサや自己診断装置によって安全状態を常時監視し、何らかの危険を検知した場合に適切な安全制御ロジックを実行することで、機能安全を確保する必要がある。

上述したサービスロボットのほか、運輸機器等の電気的な原理で動作するシステムを対象とした機能安全に関する国際標準としてIEC 61508が制定されている。IEC 61508では、機能安全の確保のために設けられるシステムのことを安全関連系と呼んでいる。IEC 61508は、マイクロプロセッサ及びPLC（Programmable Logic Controller）等のハードウェアとコンピュータプログラム（ソフトウェア）によって安全関連系を構築するための様々な技法を定めている。IEC 61508で定められている技法を用いることで、コンピュータシステムを用いて安全関連系を構築することが可能となる。

一方で、近年、マイクロプロセッサ等のプログラマブル電子機器の処理能力が向上している。このため、マルチタスクＯＳ（Operating System）を利用し、１つのコンピュータシステム上で様々なアプリケーションプログラムを並列実行することで、サービスロボット及び自動車等の機器に搭載されている複数用途のコンピュータシステムを統合することができる。

例えば特許文献１に、機能安全の確保に関するアプリケーションプログラム（以下、安全関連アプリケーションと呼ぶ）を、その他のアプリケーションプログラム（以下、非安全関連アプリケーションと呼ぶ）と共に１つのコンピュータシステム上で動作させる技術が開示されている。

IEC 61508で定められている技法を、安全関連アプリケーションおよび非安全関連アプリケーションを含むソフトウェア全体に適用すると、非安全関連アプリケーションにまで適用する必要性が生じる。このため、ソフトウェア開発コストが増大するという問題がある。

そこで、特許文献１に開示される技術では、システムプログラムのタイム・パーティションニングによって、安全関連アプリケーション（安全監視プログラム及び安全制御プログラム）を非安全関連アプリケーション（通常制御プログラム）から独立させている。このため、通常制御プログラムを安全関連系から除外することができ、コンピュータシステムを用いて構成される安全関連系の低コスト化に寄与することができる。

特開２０１０−２７１７５９号公報

しかしながら、本願出願人は、特許文献１に開示されるような安全制御装置に関して、本願出願人が新たに創案した安全制御装置において、以下に説明する課題を見出した。以下、図１５〜１７を参照して、その課題について説明する。

図１５は、本願出願人によって創案された安全制御装置にかかるタイムパーティションにおけるタスクの実行状況を示す図である。図１５に例示するタイムパーティションでは、最初のタイムパーティションＴＰ１（以下、「ＴＰ１」とする）に制御タスク及び故障検出タスクが実行される。なお、図１５では、最初のＴＰ１についてのみタスクの実行状況を示し、それ以降のタイムパーティションについては、図示を省略する。

ここで、図１６に示すように、一般的に、タスクは、ユーザ空間で動作し、オペレーティングシステム（ＯＳ）は、カーネル空間で動作する。つまり、タスクは、ユーザモードで動作し、ＯＳは、カーネル空間で動作する。ここで、カーネルモード（「マスターモード」、「スーパバイザーモード」、又は「特権モード」とも言う）とは、マイクロコントローラの全てのハードウェア資源が操作可能なモードのことを言う。それに対して、ユーザモードとは、マイクロコントローラの限られたハードウェア資源のみ操作可能なモードのことを言う。なお、カーネルモード及びユーザモードとは、ＣＰＵ（Central Processing Unit）（プロセッサ）の動作モードのことである。つまり、カーネルモードでは、ＣＰＵは、マイクロコントローラの全てのハードウェア資源にアクセスでき、ユーザモードでは、ＣＰＵは、アクセスできるハードウェア資源が制限される。

そのため、図１５の例では、制御タスクがサービスロボットを制御するためにハードウェア資源にアクセスする場合や、故障検出タスクがサービスロボットの故障を検出するためにハードウェア資源にアクセスする場合には、ユーザモードからカーネルモードに切り替える必要がある。この切り替えは、ＯＳに用意されたシステムコールをタスクが使用することによって行われる。つまり、タスクは、システムコールを使用することによって、ＯＳを介して、カーネルモードでのみアクセスすることができるハードウェア資源にアクセスすることができる。

図１７を参照して、図１５に例示したＴＰ１における処理手順について説明する。図１７は、図１５に示すＴＰ１における処理手順を示す図である。なお、図１７では、図１５に示す２つの制御タスクのそれぞれを、「Ｔａｓｋ１」及び「Ｔａｓｋ２」として示す。

ＯＳは、タスクスケジューリングにおいて、Ｔａｓｋ１を選択する（Ｓ１０１）。なお、Ｓ１０１は、カーネルモードでＯＳが動作する。ＯＳは、選択したＴａｓｋ１を実行する（Ｓ１０２）。なお、Ｓ１０２では、ユーザモードでＴａｓｋ１が動作する。Ｔａｓｋ１の実行が終了した場合、ＯＳは、タスクスケジューリングを行って、Ｔａｓｋ２を選択する（Ｓ１０３）。なお、Ｓ１０３では、カーネルモードでＯＳが動作する。ＯＳは、選択したＴａｓｋ２を実行する（Ｓ１０４）。なお、Ｓ１０４では、ユーザモードでＴａｓｋ２が動作する。

Ｔａｓｋ２の実行が終了した場合、ＯＳは、タスクスケジューリングを行って、故障検出タスクを選択する（Ｓ１０５）。なお、Ｓ１０５では、カーネルモードでＯＳが動作する。ＯＳは、選択した故障検出タスクの実行を開始する（Ｓ１０６）。なお、Ｓ１０６では、ユーザモードで、故障検出タスクが動作を開始する。故障検出タスクは、システムコールを使用して、サービスロボットの情報（以下、「故障検出情報」とする）を取得する（Ｓ１０７）。つまり、Ｓ１０７では、システムコールに応じて、カーネルモードでＯＳが動作する。

システムコールにおける処理の終了後、ユーザモードに戻る。故障検出タスクは、取得した故障検出情報に基づいて、故障を検出する。故障検出タスクは、次の故障検出を開始する（Ｓ１０８）。つまり、ハードウェア資源において、Ｓ１０７で故障検出情報を取得した箇所とは異なる箇所からの故障検出情報の取得を開始する。なお、Ｓ１０８では、ユーザモードで故障検出タスクが動作する。故障検出タスクは、システムコールを使用して、故障検出情報を取得する（Ｓ１０９）。つまり、Ｓ１０９では、システムコールに応じて、カーネルモードでＯＳが動作する。

システムコールにおける処理の終了後、ユーザモードに戻る。故障検出タスクは、取得した故障検出情報に基づいて、故障を検出する。故障検出タスクは、次の故障検出を開始する（Ｓ１１０）。なお、Ｓ１１０では、ユーザモードで、故障検出タスクが動作を開始する。以降も、同様にして、ハードウェア資源において、故障検出対象となる箇所の全てから故障検出情報を取得するまで、Ｓ１０８及びＳ１０９と同様の動作が繰り返され、そのたびに、ユーザモードとカーネルモードとの間で遷移が行われる。

しかしながら、ユーザモードとカーネルモードとの間で遷移をする場合、コンテキストスイッチが発生する。具体的には、システムコール関数を呼び出し中における処理は、カーネルモードで実行されることになるため、これらの関数が呼び出された際には、ユーザモードのコンテキストを退避し、カーネルモードのコンテキストを読み出す必要がある。さらに、システムコール関数における処理が終了したときには、元のユーザモードのコンテキストを復元する必要がある。

つまり、システムコールを使用して、ユーザモードとカーネルモードとの間での切り替えを行うと、ＣＰＵに負荷がかかってしまうという問題がある。特に、ロボット制御においては、故障検出のために検査するハードウェア数も多くなってしまう。そのため、それぞれのハードウェアにアクセスするために、システムコールを多用することで、図１７を参照して説明したように、ユーザモードとカーネルモードとの間での切り替えが頻繁に行われてしまい、ＣＰＵの負荷が増大してしまうという問題も発生してしまう。さらには、このように故障検出タスクがシステムコールを多用してＣＰＵ時間を多く消費することで、故障検出タスク以外の制御タスクが利用できるＣＰＵ時間も短くなってしまうという問題も発生してしまう。

本発明は、上述したような課題を解決するために、プロセッサにかかる負荷を低減することができる制御装置及び制御方法を提供することを目的とする。

本発明の第１の態様にかかる制御装置は、ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをユーザモードで実行するオペレーティングシステムと、前記オペレーティングシステムを実行するプロセッサと、を備えた制御装置であって、前記オペレーティングシステムは、前記制御タスクを実行していない期間に、カーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出する異常検出処理を実行するものである。

本発明の第２の態様にかかる制御方法は、ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをプロセッサによってユーザモードで実行する制御方法であって、前記プロセッサが、前記制御タスクが実行終了したときに、ユーザモードからカーネルモードに切り替えるステップと、前記プロセッサが、前記切り替え後のカーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出するステップと、を備えたものである。

上述した本発明の各態様によれば、プロセッサにかかる負荷を低減することができる制御装置及び制御方法を提供することができる。

発明の実施の形態１にかかる安全制御装置の構成例を示すブロック図である。 発明の実施の形態１にかかるタイム・パーティショニングの概念を説明するための図である。 発明の実施の形態１にかかるリソース・パーティショニングの概念を説明するための概念図である。 図１に示したＯＳによって提供される実行環境で起動される、パーティションスケジューラとタスクとの関係を示す図である。 スケジューリングパターンの具体例を示す図である。 スケジューリングパターンの具体例を示す図である。 発明の実施の形態１にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。 発明の実施の形態１にかかるタイムパーティションにおけるタスクの実行状況を示す図である。 発明の実施の形態１にかかる安全監視・制御用のタイムパーティションにおける処理手順に示すフローチャートである。 発明の実施の形態２にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。 発明の実施の形態２にかかるタイムパーティションにおけるタスクの実行状況を示す図である。 発明の実施の形態２にかかる安全監視・制御用のタイムパーティションにおける処理手順に示すフローチャートである。 発明の実施の形態３にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。 発明の実施の形態３にかかるタイムパーティションにおけるタスクの実行状況を示す図である。 発明の実施の形態３にかかる安全監視・制御用のタイムパーティションにおける処理手順に示すフローチャートである。 本願発明の課題を説明するために、タイムパーティションにおけるタスクの実行状況の一例を示す図である。 ユーザモード及びカーネルモードを説明するための図である。 本願発明の課題を説明するために、図１５に示すタイムパーティションにおける処理手順を説明するための図である。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

＜発明の実施の形態１＞
本実施の形態１にかかる安全制御装置１は、サービスロボットや運輸機器等に搭載されて機能安全確保のための安全制御を実行する。安全制御装置１は、安全関連アプリケーションと非安全関連アプリケーションを同一のコンピュータシステムで実行するよう構成される。図１は、本実施の形態にかかる安全制御装置１の構成例を示すブロック図である。

プロセッサ１０は、プログラム（命令ストリーム）の取得、命令のデコード、命令のデコード結果に応じた演算処理を行う。なお、図１では、１つのプロセッサ１０のみを示しているが、安全制御装置１は、複数のプロセッサ１０を有するマルチプロセッサ構成であってもよい。また、プロセッサ１０は、マルチコアプロセッサでもよい。プロセッサ１０は、システムプログラムとしてのオペレーティングシステム（ＯＳ）１００を実行することによりマルチプログラミング環境を提供する。マルチプログラミング環境とは、複数のプログラムを定期的に切り替えて実行したり、あるイベントの発生に応じて実行するプログラムを切り替えたりすることによって、複数のプログラムがあたかも並列実行されているような環境を意味する。

マルチプログラミングは、マルチプロセス、マルチスレッド、マルチタスク等と呼ばれる場合もある。プロセス、スレッド及びタスクは、マルチプログラミング環境で並列実行されるプログラム単位を意味する。本実施の形態のプロセッサ１０が具備するマルチプログラミング環境は、マルチプロセス環境でもよいし、マルチスレッド環境でもよい。

実行用メモリ１１は、プロセッサ１０によるプログラム実行のために使用されるメモリである。実行用メモリ１１には、不揮発性メモリ１３からロードされたプログラム（ＯＳ１００及びアプリケーション１０１〜１０４等）、プロセッサ１０の入出力データ等が記憶される。なお、プロセッサ１０は、プログラムを不揮発性メモリ１３から実行用メモリ１１にロードすることなく、これらのプログラムを不揮発性メモリ１３から直接実行してもよい。

具体的には、実行用メモリ１１は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）等のランダムアクセス可能な揮発性メモリとすればよい。図１の実行用メモリ１１は、論理的な構成単位を示している。すなわち、実行用メモリ１１は、例えば、複数のＳＲＡＭデバイスの組み合わせ、複数のＤＲＡＭデバイスの組み合わせ、又はＳＲＡＭデバイスとＤＲＡＭデバイスの組み合わせでもよい。

Ｉ／Ｏポート１２は、外部デバイスとの間のデータ送受信に使用される。例えば、安全制御装置１がサービスロボットに搭載される場合であれば、外部デバイスは、サービスロボット周囲の障害物を計測可能な視覚センサ、サービスロボットの姿勢を検知するためのセンサ、及びサービスロボットのアクチュエータの状態を検知するためのセンタ等のサービスロボットの内外の状態を示す情報を取得する各種センサ、並びに、サービスロボットを動作させるアクチュエータ等である。

不揮発性メモリ１３は、電力の供給を受けることなく、実行用メモリ１１に比べて安定的に記憶内容を維持することが可能なメモリデバイスである。例えば、不揮発性メモリ１３は、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ハードディスクドライブ若しくは光ディスクドライブ、又はこれらの組み合わせである。不揮発性メモリ１３は、ＯＳ１００及びアプリケーション１０１〜１０４を格納する。なお、不揮発性メモリ１３の少なくとも一部は安全制御装置１から取り外し可能に構成されてもよい。例えば、アプリケーション１０１〜１０４が格納されたメモリを取り外し可能としてもよい。また、不揮発性メモリ１３の少なくとも一部は、安全制御装置１の外部に配置されてもよい。

ＯＳ１００は、プロセッサ１０によって実行されることにより、プロセッサ１０及び実行用メモリ１１及び不揮発性メモリ１３等のハードウェア資源を利用して、タスクスケジューリングを含むタスク管理、割り込み管理、時間管理、資源管理、タスク間同期およびタスク間通信機構の提供等を行う。

さらに、機能安全の確保に関連する安全制御アプリケーション１０４の通常制御アプリケーション１０３からの独立性を高めるため、ＯＳ１００は、ハードウェア資源を、時間的および空間的に保護する機能を有する。ここで、ハードウェア資源とは、プロセッサ１０、実行用メモリ１１、Ｉ／Ｏポート１２を含む。

このうち、時間的な保護は、プロセッサ１０の実行時間という時間的な資源をパーティショニングすることにより行う。具体的に述べると、時間的な保護は、プロセッサ１０の実行時間をパーティショニングし、各パーティション（タイムパーティションと呼ぶ）にタスク（プロセス又はスレッド）を割り当てることにより行う。ＯＳ１００のスケジューリング機能（パーティションスケジューラ２１）は、各タイムパーティション（以下、ＴＰと略称する場合がある。）に割り当てられたタスクに対して、プロセッサ１０の実行時間を含む資源の利用を保証する。

図２は、タイム・パーティショニングに関する概念図である。図２の例では、予め定められた１サイクル時間を３つのＴＰ１、ＴＰ２及びＴＰ３に分割する例を示している。例えば、１サイクル時間を１００Ｔｉｃｋとした場合、このうち前半の２０ＴｉｃｋがＴＰ１、中間の３０ＴｉｃｋがＴＰ２、後半の５０ＴｉｃｋがＴＰ３と規定される。

また、図２の例では、第１アプリケーション（ＡＰＬ１）〜第４アプリケーション（ＡＰＬ４）が、ＴＰ１〜ＴＰ３のいずれかに割り当てられている。ＯＳ１００のスケジューリング機能（パーティションスケジューラ２１）は、時間の経過に応じて、ＴＰ１〜ＴＰ３のいずれをアクティブにするかを選択・決定する。そして、アクティブなＴＰに割り当てられているアプリケーションが、プロセッサ１０で実行される。

一方、空間的な保護は、実行用メモリ１１及びＩ／Ｏポート１２を含む固定的な資源をパーティショニングし、各パーティション（リソースパーティションと呼ぶ）にタスクを割り当てることにより行う。ＯＳ１００のスケジューリング機能（パーティションスケジューラ２１）は、予め割り当てられたリソースパーティション（以下、ＲＰと略称する場合がある。）を超えてタスクが他のリソースにアクセスすることを禁止する。

図３は、リソース・パーティショニングに関する概念図である。図３の例では、２つのＲＰ（ＲＰ１及びＲＰ２）を示している。ＲＰ１には、実行用メモリ１１及び不揮発性メモリ１３の一部（Ａ領域）と、Ｉ／Ｏポート１２の一部（ポートＡ）が割り当てられている。また、ＲＰ２には、実行用メモリ１１及び不揮発性メモリ１３の他の一部（Ｂ領域）と、Ｉ／Ｏポート１２の他の一部（ポートＢ）が割り当てられている。ＲＰ１からはＲＰ２に割り当てられたリソースへのアクセスが禁止され、ＲＰ２からはＲＰ１に割り当てられたリソースへのアクセスが禁止される。

なお、全てのリソースがいずれかのＲＰに排他的に割り当てられてもよく、複数のＲＰによって共有されるリソースがあってもよい。例えば、サービスロボットの安全制御を行う場合、アクチュエータに、通常制御アプリケーション１０３及び安全制御アプリケーション１０４の双方からアクセスできるようにしてもよい。よって、通常制御アプリケーション１０３が属するＲＰと安全制御アプリケーション１０４が属するＲＰによって、アクチュエータを制御するためのＩ／Ｏポート１２を共有するようにしてもよい。なお、本実施の形態では、制御アプリケーション１０１、１０２が属するＲＰに、Ｉ／Ｏポート１２の全てが割り当てられる場合について例示する。

図１に戻り説明を続ける。アプリケーション１０１〜１０４は、ＯＳ１００及びプロセッサ１０によって提供されるマルチプログラミング環境で実行される。このうち、制御アプリケーション１０１、１０２のそれぞれは、サービスロボット等の制御対象を制御する制御手順をプロセッサ１０に実行させるための命令コードを含む。さらに、制御アプリケーション１０１、１０２のそれぞれは、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。つまり、制御アプリケーション１０１、１０２のそれぞれは、非安全関連アプリケーションである。

また、通常制御アプリケーション１０３は、サービスロボット等の制御対象に通常の機能・動作を行わせるための制御手順をプロセッサ１０に実行させるための命令コードを含む。さらに、通常制御アプリケーション１０３は、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。つまり、通常制御アプリケーション１０２は、非安全関連アプリケーションである。

また、安全制御アプリケーション１０４は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御手順をプロセッサ１０に実行させるための命令コードを含む。さらに、安全制御アプリケーション１０４は、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。つまり、安全制御アプリケーション１０４は、安全関連アプリケーションである。

リセット回路１４は、ＯＳ１００からの信号に基づき、マイクロコントローラ１５のリセットを行う。パーティションスケジューラ２１からリセット回路１４に定期的に送信信号を送信し、リセット回路１４は、パーティションスケジューラ２１からの送信信号が途絶えた場合に、マイクロコントローラ１５をリセットする。例えば、パーティションスケジューラ２１は、後述するような、１Ｔｉｃｋごとに動作するタイミングで、送信信号をリセット回路１４に送信する。また、パーティションスケジューラ２１は、ＯＳ１００で異常を検知した場合、又は、アプリケーション１０１〜１０４から異常を示す結果通知を受けた場合に、リセット回路１４にリセット信号を送信するようにして、それに応じて、リセット回路１４がマイクロコントローラ１５をリセットするようにしてもよい。このようにすることで、マイクロコントローラ１５に不具合が発生した場合に、マイクロコントローラ１５をリセットして復旧することができる。

続いて以下では、パーティションスケジューラ２１と、アプリケーション１０１〜１０４の起動により生成されるタスクと、の関係について、図４を用いて説明する。図４は、ＯＳ１００によって提供されるマルチプログラミング環境で起動される、パーティションスケジューラ２１とタスク２４、２５、２７、２９との関係を示す図である。

マイクロコントローラ１５は、プロセッサ１０、実行用メモリ１１、Ｉ／Ｏポート１２、不揮発性メモリ１３等を含む。なお、図４では、マイクロコントローラ１５の外部にリセット回路１４を備える構成を例示しているが、マイクロコントローラ１５の内部にリセット回路１４を含む構成としてもよい。

マイクロコントローラ１５には、外部のクロック源（図示せず）からのクロック信号が供給され、プロセッサ１０等は、このクロック信号に基づく所定のタイマー周期で動作する。本実施の形態では、所定のタイマー周期を、１Ｔｉｃｋであるとして説明する。このため、プロセッサ１０によりＯＳ１００が実行されることで、パーティションスケジューラ２１が１Ｔｉｃｋごとに動作すると共に、各ＴＰにおいて、タスクスケジューラ２３、２６、２８およびタスク（制御タスク２４、２５、通常制御タスク２７、安全制御タスク２９）が１Ｔｉｃｋごとに動作する。

ここで、ＯＳ１００と、ＯＳ１００に含まれる、パーティションスケジューラ２１及びタスクスケジューラ２３、２６、２８のそれぞれは、カーネルモードで実行され、タスク２４、２５、２７、２９は、ユーザモードで実行される。言い換えると、ＯＳ１００、パーティションスケジューラ２１、及びタスクスケジューラ２３、２６、２８は、カーネル空間で動作し、タスク２４、２５、２７、２９は、ユーザ空間で動作する。ここで、Ｉ／Ｏポート１２には、ユーザモード及びカーネルモードのうち、カーネルモードのみでアクセス可能であるものとする。つまり、本実施の形態では、サービスロボット等の制御対象には、カーネルモードでのみアクセス可能である。

したがって、制御タスク２４、２５は、Ｉ／Ｏポート１２にアクセスして、サービスロボット等の制御対象のアクチュエータを制御する場合及びセンサのセンサ値を取得する場合には、ＯＳ１００に用意されたシステムコールを使用することによって、ユーザモードからカーネルモードに切り替えて、Ｉ／Ｏポート１２にアクセスする必要がある。つまり、ＯＳ１００は、制御タスク２４、２５がＩ／Ｏポート１２にアクセスするためのインタフェースとなるシステムコールを有する。

ここで、具体的にシステムコールが使用されたときの動作について説明する。制御タスク２４、２５は、アクチュエータを制御する場合、アクチュエータを制御する指令値を引数として指定してシステムコール関数を呼び出す。ＯＳ１００は、システムコール関数が呼び出されると、ユーザモードからカーネルモードに切り替えて、指定された指令値をＩ／Ｏポート１２に対して出力する。そして、ＯＳ１００は、再びカーネルモードからユーザモードに切り替える。これによって、制御タスク２４、２５は、システムコール関数から復帰する。

また、制御タスク２４、２５は、センサのセンサ値を取得する場合、システムコール関数を呼び出す。ＯＳ１００は、システムコール関数が呼び出されると、ユーザモードからカーネルモードに切り替えて、Ｉ／Ｏポート１２からセンサ値を取得する。そして、ＯＳ１００は、再びカーネルモードからユーザモードに切り替えて、取得したセンサ値をシステムコール関数の戻り値とする。これによって、制御タスク２４、２５は、システムコール関数から復帰して、システムコール関数の戻り値をセンサ値として取得することができる。

ＯＳ１００は、サービスロボット等の制御対象の異常を検知するルーチンが含まれている。ＯＳ１００は、Ｉ／Ｏポート１２を介して、サービスロボット等の制御対象が有するセンサのセンサ値を取得して、取得したセンサ値に基づいて、サービスロボット等の制御対象の異常を検知する。ＯＳ１００は、サービスロボット等の制御対象の異常を検知した場合、図５Ａ、Ｂを参照して後述するような、ＴＰのスケジューリングパターンを、異常が検知された場合に適用されるスケジューリングパーティションに切り替える。

パーティションスケジューラ２１は、１Ｔｉｃｋごとに動作し、ＴＰの切り替え（パーティション・スケジューリング）を行う。パーティションスケジューラ２１は、次の１Ｔｉｃｋの間にＴＰ１〜ＴＰ３のいずれをアクティブにするかを選択・決定する。さらに、パーティションスケジューラ２１は、選択したＴＰに関するタスクスケジューラの動作を開始させる。

パーティションスケジューラ２１によるパーティション・スケジューリングについて具体的に述べると、パーティションスケジューラ２１は、スケジューリングテーブル２２を参照し、ＴＰの設定を定めたスケジューリングパターンに従って、パーティション・スケジューリングを行う。

スケジューリングテーブル２２は、ＴＰの切り替え順序およびタイミングを規定したスケジューリングパターンを保持している。なお、スケジューリングテーブル２２は、少なくとも２つの異なるスケジューリングパターンを保持している。１つは、ＯＳ１００によって異常が検知されていない場合（つまり通常時）に適用されるスケジューリングパターンである。もう１つは、ＯＳ１００によって異常が検知された場合に適用されるスケジューリングパターンである。以下では、通常時に適用されるスケジューリングパターンを"通常制御スケジューリングパターン"と呼ぶ。また、異常検知時に適用されるスケジューリングパターンを"安全制御スケジューリングパターン"と呼ぶ。

図５Ａは、通常制御スケジューリングパターンの具体例を示している。図５Ａでは、制御タスク２４、２５が属するＴＰ１が１サイクル時間の前半（Ｔ１）に割り当てられている。また、通常制御タスク２７が属するＴＰ２が１サイクル時間の後半（Ｔ２）に割り当てられている。図５Ａのスケジューリングパターンによれば、制御タスク２４、２５と通常制御タスク２７が繰り返しスケジューリングされる。

図５Ｂは、安全制御スケジューリングパターンの具体例を示している。図５Ｂでは、制御タスク２４、２５が属するＴＰ１が１サイクル時間の前半（Ｔ３）に割り当てられている。また、安全制御タスク２９が属するＴＰ３が１サイクル時間の後半（Ｔ４）に割り当てられている。図５Ｂのスケジューリングパターンによれば、制御タスク２４、２５と安全制御タスク２９が繰り返しスケジューリングされる。

図４に戻り説明を続ける。タスクスケジューラ２３、２６、２８は、それぞれが属するＴＰ内でのタスクのスケジューリングを行う。各ＴＰ内でのタスクのスケジューリングには、一般的な優先度ベースのスケジューリングを適用すればよい。なお、図４では、各ＴＰ２及び３はそれぞれ１つのタスクのみを含み、ＴＰ１は２つのタスクのみを含む場合について図示しているが、１又は２以上のタスクが含まれるようにしてもよい。例えば、通常制御用のＴＰ２内には、通常制御タスクＡ及び通常制御タスクＢの２つのタスクが含まれていてもよい。

制御タスク２４は、制御アプリケーション１０１の起動によって生成されるタスクであり、制御タスク２５は、制御アプリケーション１０２の起動によって生成されるタスクである。図４の例では、制御タスク２４、２５は、ＴＰ１及びＲＰ１に割り当てられている。制御タスク２４、２５のそれぞれは、サービスロボット等の制御対象を制御する。具体的は、制御タスク２４、２５のそれぞれは、アクチュエータの指令値をＩ／Ｏポート１２に出力することによって、アクチュエータを制御する。この指令値は、後述するように、通常制御タスク２７又は安全制御タスク２９から取得する。さらに、制御タスク２４、２５は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。

通常制御タスク２７は、通常制御アプリケーション１０３の起動によって生成されるタスクである。図４の例では、通常制御タスク２７は、ＴＰ２及びＲＰ２に割り当てられている。通常制御タスク２７は、サービスロボット等の制御対象に通常の機能・動作を行わせるための制御を行う。具体的には、通常制御タスク２７は、アクチュエータの制御計算をして、アクチュエータの指令値を算出する。例えば、サービスロボット等の制御対象に通常動作をさせる指令値となる。通常制御タスク２７は、算出した指令値を制御タスク２４、２５のそれぞれに出力する。さらに、通常制御タスク２７は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。

安全制御タスク２９は、安全制御アプリケーション１０４の起動によって生成されるタスクである。図４の例では、安全制御タスク２９は、ＴＰ３及びＲＰ３に割り当てられている。安全制御タスク２９は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御を行う。具体的には、安全制御タスク２９は、アクチュエータの制御計算をして、アクチュエータの指令値を算出する。例えば、サービスロボット等の制御対象を安全方向に動作させる又は停止させる指令値となる。安全制御タスク２９は、算出した指令値を制御タスク２４、２５のそれぞれに出力する。さらに、安全制御タスク２９は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。

なお、各タスクからパーティションスケジューラ２１へと結果を通知する具体的な構成としては、様々な手法を採用することができる。例えば、タスクがＯＳ１００のシステムコール（サービスコール）を呼び出し、ＯＳ１００を介して、パーティションスケジューラ２１に結果を通知することができる。また、例えば、タスクの実行状況に関するフラグを実行用メモリ１１に格納するものとして、タスクがその実行状況に応じてフラグの値を設定し、パーティションスケジューラ２１がフラグの設定値に応じてタスクの実行状況を判断することもできる。

上述したように、パーティションスケジューラ２１が１Ｔｉｃｋごとに動作し、ＴＰ１〜ＴＰ３のいずれをアクティブにするかを選択・決定する。さらに、パーティションスケジューラ２１が、選択したＴＰに関するタスクスケジューラの動作を開始させる。そして、タスクスケジューラ２３、２６、２８が動作を開始することでタスクのスケジューリングが行われ、プロセッサ１０が、タスクスケジューラ２３、２６、２８によりスケジューリングされた順序に従って、ＴＰ内でのタスクを実行していく。これによって、アクティブなＴＰに割り当てられているアプリケーションが、プロセッサ１０で実行される。

続いて以下では、発明の実施の形態１にかかるパーティションスケジューラ２１によるパーティション・スケジューリングについて、図６を用いて説明する。図６は、発明の実施の形態１にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。

まず、１Ｔｉｃｋごとに動作するパーティションスケジューラ２１が、ＴＰ１のタスクスケジューラ２３を動作させる（Ｓ１１）。

なお、図６では、通常制御スケジューリングパターン（例えば図５Ａ）または安全制御スケジューリングパターン（例えば図５Ｂ）に従って、スケジューリングを実行する場合を例に説明する。すなわち、ＴＰ１に続く次のＴＰはＴＰ２又はＴＰ３であり、かつ、ＯＳ１００によって、サービスロボット等の制御対象に故障等の何らかの異常が検知された場合に、ＴＰ１の次に選択・決定されるＴＰがＴＰ３である場合を例に説明する。つまり、最初のまだ異常が検知されていない状態では、ＴＰ１の次に選択・決定されるＴＰがＴＰ２である場合を例に説明する。つまり、通常時は、通常制御スケジューリングパターンを参照してＴＰのスケジューリングを行い、異常の検知後は、安全制御スケジューリングパターンを参照してＴＰのスケジューリングを行う場合を例に説明する。つまり、後述するＴＰＸの初期値が、ＴＰＸ＝ＴＰ２である場合について説明する。

Ｓ１１で動作を開始したＴＰ１のタスクスケジューラ２３は、ＴＰ１内の制御タスク２４、２５を優先度に応じて実行する（Ｓ１２）。なお、ここでは、ＴＰ１内の制御タスク２４、２５で実行状態又は実行可能状態となっている制御タスクがある場合に、そのうちのいずれかの制御タスクが実行される。つまり、ＴＰ１内の制御タスク２４、２５がいずれも実行状態及び実行可能状態のいずれの状態にもなっていない場合、制御タスクは実行されない。実行状態及び実行可能状態のいずれの状態にもなっていない場合とは、待ち状態、休止状態、強制待ち状態又は二重待ち状態等である。

ここで、制御タスク２４、２５は、例えば、通常制御タスク２７及び安全制御タスク２９のいずれからも指令値を取得していない場合、もしくは、通常制御タスク２７又は安全制御タスク２９からの指令値の取得に応じたアクチュエータの制御処理の実行が終了している場合には、待ち状態となっている。そして、制御タスク２４、２５は、例えば、通常制御タスク２７又は安全制御タスク２９から指令値を取得したときに、待ち状態から実行可能状態に遷移する。制御タスク２４、２５は、例えば、タスク間通信によって、通常制御タスク２７又は安全制御タスク２９から指令値を取得することで、待ち状態から起床して実行可能状態となる。

Ｓ１２で制御タスク２４、２５のいずれかの実行が終了した場合、ＯＳ１００は、ＴＰ１内に実行する制御タスク２４、２５がないか否かを判定する（Ｓ１３）。ＴＰ１内に実行する制御タスク２４、２５がないか否かは、例えば、ＴＰ１内の制御タスク２４、２５が実行状態及び実行可能状態のいずれの状態にもなっていないか否かによって判定する。

ＴＰ１内に実行する制御タスク２４、２５がない場合（Ｓ１３でＹｅｓ）、ＯＳ１００は、故障検出処理を実行する（Ｓ１４）。具体的には、ＯＳ１００は、Ｉ／Ｏポート１２を介して、サービスロボット等の制御対象のセンサ値を取得する。ＯＳ１００は、取得したセンサ値が、正常値の範囲内か否かを判定する。ここで、正常値は、例えば、実行用メモリ１１に予め格納しておき、ＯＳ１００が参照可能としておく。ＯＳ１００は、センサ値が正常値の範囲内に収まっている場合、サービスロボット等の制御対象は故障していないと判定する。ＯＳ１００は、センサ値が正常値の範囲内に収まっていない場合、サービスロボット等の制御対象が故障していると判定する。すなわち、この場合、サービスロボット等の制御対象の故障が検出されことになる。言い換えると、サービスロボット等の制御対象の異常が検知されたことになる。

ＯＳ１００は、故障検出処理によって、サービスロボット等の制御対象の故障を検出した場合（Ｓ１５でＹｅｓ）、後述するＴＰＸを、ＴＰＸ＝ＴＰ３とする（Ｓ１６）。つまり、ＯＳ１００は、パーティションスケジューラ２１が参照するスケジューリングパターンを、通常制御スケジューリングパターンから安全制御スケジューリングパターンに切り替える。

一方で、１Ｔｉｃｋが経過すると、パーティションスケジューラ２１が、ＴＰのスケジューリングを開始する（Ｓ１７）。すなわち、パーティションスケジューラ２１は、スケジューリングパターンに従って、次の１Ｔｉｃｋの間にいずれのＴＰをアクティブにするかを選択・決定する。

パーティションスケジューラ２１は、次にアクティブにするＴＰを変更しない（Ｓ１８でＮｏ）場合には、Ｓ１１に戻り、同一のＴＰ１についての動作を継続させる。このため、ＴＰ１の切り替えタイミングとなるまでの間、Ｓ１１〜Ｓ１６までの処理が繰り返される。なお、このときに、Ｓ１２でＴＰ１内に実行する制御タスク２４、２５がない場合（Ｓ１３でＹｅｓ）は、故障検出処理（Ｓ１４）が継続されることになる。

パーティションスケジューラ２１は、次にアクティブにするＴＰを変更する（Ｓ１８でＹｅｓ）場合には、その変更するタイムパーティションのタスクスケジューラを動作させる（Ｓ１９）。ここでは、ＴＰＸのタスクスケジューラを動作させる。ここで、変数ＸはＴＰの番号を示す。すなわち、Ｓ１９では、ＴＰ１を除いた、ＴＰ２又はＴＰ３のいずれかを動作させる。そして、ＴＰＸのタスクスケジューラが、ＴＰＸ内のタスクを優先度に応じて実行する（Ｓ２０）。Ｓ２０でも、Ｓ１２と同様に、ＴＰＸ内のタスクの状態に応じて、タスクが実行される。

１Ｔｉｃｋが経過すると、パーティションスケジューラ２１が、再びスケジューリングを開始する（Ｓ２１）。パーティションスケジューラ２１は、スケジューリングパターンに従って、次の１Ｔｉｃｋの間にいずれのＴＰをアクティブにするかを選択・決定し、次にアクティブにするＴＰを変更しない（Ｓ２２でＮｏ）場合には、Ｓ１９に戻り、ＴＰＸについての動作を継続させる。

パーティションスケジューラ２１は、次にアクティブにするＴＰを変更する（Ｓ２２でＹｅｓ）場合には、次の１Ｔｉｃｋの間にアクティブにするＴＰとして、ＴＰ１を選択・決定する（Ｓ２３）。

図６で示した処理に関して、パーティション・スケジューリングの具体例を説明する。
まず、図５Ａに例示した通常制御スケジューリングパターンに従って、Ｓ１１においてスケジューリングを開始した場合を説明する。この場合、Ｓ１１ではＴＰＸ＝ＴＰ２として開始し、Ｓ１２〜Ｓ１８にかけては、ＴＰ１のままである。そして、サービスロボット等の制御対象の故障が検出されなければ、Ｓ１９でＴＰ１からＴＰ２へと変更され、Ｓ１９〜Ｓ２２にかけてＴＰ２のままである（つまり、ＴＰ２から開始する通常制御スケジューリングパターンが継続される。）。一方で、Ｓ１５でサービスロボット等の制御対象の故障を検出したと判定されていた場合には、Ｓ１６で、ＴＰＸ＝ＴＰ３となる（つまり、ＴＰ３から開始する安全制御スケジューリングパターンに切り替わる。）。

なお、上述の例では、スケジューリングパターンとして、３つのＴＰ（安全監視・制御用のＴＰ１、通常制御用のＴＰ２、安全制御用のＴＰ３）のみを組み合わせた場合を例に説明したが、ＴＰ２のような通常制御用パーティションや、ＴＰ３のような安全制御用パーティションを、それぞれ複数個存在するものとしてもよい。例えば、２つの通常制御用のＴＰ２及びＴＰ４と、安全監視・制御用のＴＰ１と、２つの安全制御用のＴＰ３及びＴＰ５と、が存在し、これら５つのＴＰ（ＴＰ１〜ＴＰ５）を組み合わせてスケジューリングパターンを構成してもよい。この場合、Ｓ１６では、サービスロボット等の制御対象の異常状態の種類を判定し、その異常種類に応じて、安全制御用のＴＰ３またはＴＰ５のいずれかを選択するようにしてもよい。

上述したように、本実施の形態では、ＯＳ１００は、サービスロボット等の制御対象の故障の検出に応じたスケジューリングパターンに基づいて、次にアクティブとするパーティションを選択・決定するパーティションスケジューラ２１を備えている。パーティションスケジューラ２１は、各ＴＰにおいて実行されるタスクとは独立して、所定のタイマー周期で動作する。

さらに、図６で例示した処理では、ＯＳ１００における故障検出結果に応じて、安全制御用のＴＰ３を選択・決定する（Ｓ１６）ものとして説明したが、本発明はこれに限定されない。例えば、ＴＰ１〜ＴＰ３のそれぞれからパーティションスケジューラ２１に対して実行状況を通知する構成とし、パーティションスケジューラ２１が、各ＴＰからの結果通知に応じて、安全制御用のＴＰ３を選択・決定するものとしてもよい。

独立に動作するパーティションスケジューラ２１が、全てのＴＰから結果通知を受ける構成とすることで、パーティションスケジューラ２１は、全てのＴＰに関する状況を一元的に把握することができる。このため、例えば、安全監視・制御用のＴＰ１からの結果通知に応じて、パーティションスケジューラ２１が次のパーティションを決定・選択しようとする場合には、パーティションスケジューラ２１は、各ＴＰの状況を考慮した上で、正常状態にあるＴＰのみから次のパーティションを決定・選択することができる。従って、従来技術と比較して、より正確なパーティション・スケジューリングを実現することができるという効果を奏する。

続いて、図７及び図８を参照して、発明の実施の形態１にかかるＴＰ１における処理手順をより具体的に説明する。図７は、発明の実施の形態１にかかるＴＰにおけるタスクの実行状況を示す図である。図８は、発明の実施の形態１にかかるＴＰ１における処理手順を示すフローチャートである。なお、図７及び図８では、制御タスク２４を「Ｔａｓｋ１」として示し、制御タスク２５を「Ｔａｓｋ２」として示す。また、図７では、最初のＴＰ１についてのみタスクの実行状況を示し、それ以降のＴＰについては、図示を省略する。

まず、Ｔａｓｋ１及びＴａｓｋ２が実行可能状態となっているものとする。パーティションスケジューラ２１は、ＴＰをＴＰ１に切り替えたときに、タスクスケジューラ２３を動作させる。タスクスケジューラ２３は、Ｔａｓｋ１を選択する（Ｓ３１）。なお、Ｓ３１では、カーネルモードでタスクスケジューラ２３が動作する。そして、タスクスケジューラ２３は、選択したＴａｓｋ１を実行する（Ｓ３２）。なお、Ｓ３２では、ユーザモードでＴａｓｋ１が動作する。Ｓ３１及びＳ３２、図６のＳ１２に対応する。

Ｔａｓｋ１の実行が終了した場合、タスクスケジューラ２３は、Ｔａｓｋ２を選択する（Ｓ３３）。Ｔａｓｋ１の実行が終了した場合とは、例えば、Ｔａｓｋ１が予定されていた処理を全て実行し、スリープして待ち状態となった場合等である。そのため、タスクスケジューラ２３は、残りの実行可能状態となっているＴａｓｋ２を選択する。なお、Ｓ３３では、カーネルモードでタスクスケジューラ２３が動作する。そして、タスクスケジューラ２３は、選択したＴａｓｋ２を実行する（Ｓ３４）。なお、Ｓ３４では、ユーザモードでＴａｓｋ２が動作する。Ｓ３３及びＳ３４は、図６のＳ１２に対応する。

ＴＰ１内の全てのＴａｓｋ１及びＴａｓｋ２の実行が終了し、ＴＰ１内に実行するタスクがなくなった場合、ＯＳ１００は、ＴＰ１に故障検出処理を実行するだけの残り時間があるか否かを判定する（Ｓ３５）。言い換えると、ＴＰ１の残り時間が、故障検出処理の実行時間以上であるか否かを判定する。

残り時間は、ＴＰ１に対して割り当てられる時間から、ＴＰ１に切り替わってからの経過時間を減算することで算出する。ここで、ＴＰ１に対して割り当てられる時間は、例えば、実行用メモリ１１に予め格納しておき、ＯＳ１００が参照可能としておく。ＴＰ１に切り替わってからの経過時間は、例えば、ＯＳ１００が、ＴＰ１に切り替わってからのＴｉｃｋの発生回数をカウントすることで算出する。また、故障検出処理の実行時間も、例えば、実行用メモリ１１に予め格納しておき、ＯＳ１００が参照可能としておく。故障検出処理の実行時間は、事前に故障検出処理の時間を計測することで決定してもよく、処理内容から処理にかかる時間を推定して決定してもよい。ＴＰ１に対して割り当てられる時間及び故障検出処理の実行時間も、Ｔｉｃｋ数として用意しておくことで、単純に、ＴＰ１に対して割り当てられる時間から経過時間を減算するだけでＴＰ１の残り時間が算出でき、ＴＰ１の残り時間と故障検出処理の実行時間とを比較するだけで、ＴＰ１の残り時間が故障検出処理の実行時間以上であるか否かを判定することができる。

ＴＰ１に故障検出処理を実行するだけの残り時間があると判定した場合（Ｓ３５でＹｅｓ）、ＯＳ１００は、故障検出処理を実行する（Ｓ３６）。ＴＰ１に故障検出処理を実行するだけの残り時間がないと判定した場合（Ｓ３５でＮｏ）、ＯＳ１００は、故障検出処理は実行しない。Ｓ３５及びＳ３６は、図６のＳ１４に対応する。

そして、ＴＰ１に割り当てられた時間が満了した場合、パーティションスケジューラ２１は、ＴＰをＴＰ２又はＴＰ３に切り替える（Ｓ３７）。Ｓ３７は、Ｓ１９でＹｅｓに対応する。なお、Ｓ３５〜３７では、カーネルモードでＯＳ１００及びパーティションスケジューラ２１が動作する。

以上に説明したように、本実施の形態１では、ＯＳ１００が、ＴＰ１において、ＴＰ１に属する全ての制御タスク２４、２５の実行を終了して、ユーザモードからカーネルモードに切り替えたときに、カーネルモードで、故障検出処理を行うようにしている。

これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。例えば、故障検出のために確認する必要があるハードウェア数が多かったとしても、図１７のＳ１０６以降に示すように、ユーザモードとカーネルモードとの間での切り替えが多発しないようにすることができる。したがって、本実施の形態１によれば、プロセッサにかかる負荷を低減することができる。

また、本実施の形態１では、ＯＳ１００が、ＴＰ１内の全ての制御タスク２４、２５の実行を終了したときにおけるＴＰ１の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにしている。

これによれば、スケジューリングパターンによって、ＴＰ１に割り当てられている時間を超過して故障検出処理が継続実行されることによって、ＴＰ１の期間が本来ＴＰ１に割り当てられている時間を超過してしまうことを防止することができる。具体的には、本実施の形態１では、ＯＳ１００が、カーネルモードで、故障検出処理を実行するようにしている。そのため、ＴＰ１に割り当てられている時間が満了するまでに、故障検出処理が終了していない場合、パーティションスケジューラ２１が、ＴＰ２に切り替えても、ＯＳ１００によって故障検出処理が継続して実行されてしまう。したがって、ＴＰ１で実行されるべき故障検出処理がＴＰ２の期間を浸食して実行されてしまうことになり、実質的にＴＰ１の期間が本来ＴＰ１に割り当てられている時間を超過する結果を招いてしまう。これに対して、本実施の形態１のように、ＴＰ１の残り期間が、故障検出処理の実行時間以上であるのみに場合に、故障検出処理を実行するようにすることで、このような事態を防止することができる。

＜発明の実施の形態２＞
続いて、本実施の形態２にかかる安全制御装置について説明する。本実施の形態２にかかる安全制御装置の構成は、実施の形態１にかかる安全制御装置１と同様であるため、説明を省略する。

以下、図９〜１１を参照して、本実施の形態２にかかる安全制御装置１の処理手順について説明する。なお、図９及び図１１では、実施の形態１と同様の処理には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

まず、発明の実施の形態２にかかるパーティションスケジューラ２１によるパーティション・スケジューリングについて、図９を用いて説明する。図９は、発明の実施の形態２にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。

本実施の形態２では、図９に示すように、実施の形態１と異なり、パーティションスケジューラ２１がＴＰをＴＰ１に切り替えたとき（Ｓ２２でＹｅｓ）に、ＯＳ１００が、故障検出処理を実行する（Ｓ１４）。そして、故障検出処理（Ｓ１４）及びそれに付随する処理（Ｓ１５、Ｓ１６）の実行後に、ＯＳ１００は、ＴＰ１のタスクスケジューラ２３を動作させて（Ｓ１１）、ＴＰ１内の制御タスク２４、２５の実行を開始する（Ｓ１２）。

このように、本実施の形態２では、ＴＰがＴＰ１に切り替わったとき（Ｓ２２でＹｅｓ）に、故障検出処理（Ｓ１４）を実行するようにしている。それに伴い、本実施の形態２では、実施の形態１のように、ＴＰ１内の制御タスク２４、２５の実行終了後には、ＴＰ１内に実行する制御タスクがあるか否かの判定（Ｓ１３）及びその判定結果に応じての故障検出処理等（Ｓ１４〜１６）は行わない。

続いて、図１０及び図１１を参照して、発明の実施の形態２にかかるＴＰ１における処理手順をより具体的に説明する。図１０は、発明の実施の形態２にかかるＴＰにおけるタスクの実行状況を示す図である。図１１は、発明の実施の形態２にかかるＴＰ１における処理手順を示すフローチャートである。なお、図１０及び図１１では、制御タスク２４を「Ｔａｓｋ１」として示し、制御タスク２５を「Ｔａｓｋ２」として示す。また、図１０では、最初のＴＰ１についてのみタスクの実行状況を示し、それ以降のＴＰについては、図示を省略する。

本実施の形態２では、図１０及び図１１に示すように、実施の形態１と異なり、パーティションスケジューラ２１が、ＴＰをＴＰ１に切り替えたときに、ＯＳ１００が故障検出処理を実行するようにしている（Ｓ３６）。このようにすることで、パーティションスケジューラ２１がカーネルモードで実行されることを利用して、そのカーネルモードのまま、ユーザモードとカーネルモードとの間の切り替えを発生させることなく、ＯＳ１００が故障検出処理を実行することができる。

ここで、ＯＳ１００は、予め設定された設定時間の間、故障検出処理を実行するものとする。設定時間としては、例えば、Ｔａｓｋ１及びＴａｓｋ２がＴＰ１内で実行することが必須となっている場合には、Ｔａｓｋ１及びＴａｓｋ２の実行に最も長く時間がかかったとしても、ＴＰ１内でＴａｓｋ１及びＴａｓｋ２の実行が終了できるような時間を設定する。設定時間は、例えば、実行用メモリ１１に予め格納しておき、ＯＳ１００が参照可能としておく。

また、設定時間は、安全制御装置１の利用者によって予め設定されるものとする。例えば、安全制御装置１に入力装置（図示せず）を備えるようにして、利用者が入力装置を介して、設定時間を入力して設定するようにする。入力装置は、例えば、マウス、キーボード若しくはタッチパネル等、又はこれらの組み合わせである。

そして、故障検出処理（Ｓ３６）が終了したときに、ＯＳ１００が、ＴＰ１のタスクスケジューラ２３を動作させる。タスクスケジューラ２３は、Ｔａｓｋ１を選択する（Ｓ３１）。以降、Ｓ３１〜Ｓ３４が実行される。そして、Ｔａｓｋ２の実行（Ｓ３４）が終了した後に、ＴＰ１に割り当てられた時間が満了した場合、パーティションスケジューラ２１は、ＴＰをＴＰ２又はＴＰ３に切り替える（Ｓ３７）。

以上に説明したように、本実施の形態２では、ＯＳ１００が、パーティションスケジューラ２１がＴＰ１に切り替えたとき、かつ制御タスク２４，２５の実行を開始する前のカーネルモードで、故障検出処理を行うようにしている。

これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。したがって、本実施の形態２によれば、プロセッサにかかる負荷を低減することができる。

＜発明の実施の形態３＞
続いて、本実施の形態３にかかる安全制御装置について説明する。本実施の形態３にかかる安全制御装置の構成は、実施の形態１にかかる安全制御装置１と同様であるため、説明を省略する。

以下、図１２〜１４を参照して、本実施の形態３にかかる安全制御装置１の処理手順について説明する。なお、図１２及び図１４では、実施の形態１と同様の処理には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

まず、発明の実施の形態３にかかるパーティションスケジューラ２１によるパーティション・スケジューリングについて、図１２を用いて説明する。図１２は、発明の実施の形態３にかかるパーティション・スケジューリングにおける処理手順の具体例を示すフローチャートである。

本実施の形態３では、図１２に示すように、実施の形態１と異なり、Ｓ１２で制御タスク２４、２５のいずれかの実行が終了した場合に、ＯＳ１００は、ＴＰ１に属する制御タスク２４、２５が予め定めた設定数だけ実行終了したか否かを判定する（Ｓ２３）。そして、ＴＰ１に属する制御タスク２４、２５が予め定められた設定数だけ実行終了したと判定した場合（Ｓ２３でＹｅｓ）に、ＯＳ１００は、故障検出処理を実行する（Ｓ１４）。具体的には、ＯＳ１００は、制御タスクの実行を終了するごとに、実行が終了した制御タスクの数をカウントするようにする。そして、カウントした数と、予め定めた設定数とを比較して、一致した場合に、故障検出処理を実行する（Ｓ１４）ようにする。

ここで、設定数は、例えば、実行用メモリ１１に予め格納しておき、ＯＳ１００が参照可能としておく。また、カウントした、実行終了した制御タスクの数についても、ＯＳ１００が、実行用メモリ１１に格納してカウントするごと更新していくようにすることで、後の判定時（Ｓ２３）に参照可能としておく。なお、設定数は、実施の形態２で説明した設定時間のように、入力装置を介して、利用者によって予め設定されるようにしてもよい。さらに、上述した実施の形態２と同様に、故障検出処理の実行時間についても、利用者が予め設定するようにしてもよい。

なお、１Ｔｉｃｋが経過したときに（Ｓ１７）、パーティションスケジューラ２１は、次にアクティブにするＴＰを変更しない（Ｓ１８でＮｏ）場合には、Ｓ１１に戻り、同一のＴＰ１についての動作を継続させるが、このときに、ＴＰ１に属する制御タスク２４、２５が予め定めた設定数だけ実行終了している場合（Ｓ２３でＹｅｓ）は、故障検出処理（Ｓ１４）が継続されることになる。

続いて、図１３及び図１４を参照して、発明の実施の形態３にかかるＴＰ１における処理手順をより具体的に説明する。図１３は、発明の実施の形態３にかかるＴＰにおけるタスクの実行状況を示す図である。図１４は、発明の実施の形態３にかかるＴＰ１における処理手順を示すフローチャートである。なお、図１３及び図１４では、制御タスク２４を「Ｔａｓｋ１」として示し、制御タスク２５を「Ｔａｓｋ２」として示す。また、図１３では、最初のＴＰ１についてのみタスクの実行状況を示し、それ以降のＴＰについては、図示を省略する。

本実施の形態３では、図１３及び図１４に示すように、実施の形態１と異なり、Ｔａｓｋ１の実行（Ｓ３２）が終了したときに、ＯＳ１００が故障検出処理を実行するようにしている（Ｓ３６）。このようにすることで、Ｔａｓｋ１の実行が終了して、タスクスケジューリングのためにカーネルモードに切り替わることを利用して、そのカーネルモードのまま、ユーザモードとカーネルモードとの間の切り替えを発生させることなく、ＯＳ１００が故障検出処理を実行することができる。つまり、本実施の形態３では、設定数が"１"である場合について例示している。

そして、故障検出処理（Ｓ３６）が終了したときに、ＯＳ１００が、タスクスケジューラ２３を動作させる。タスクスケジューラ２３は、Ｔａｓｋ２を選択する（Ｓ３３）。そして、Ｔａｓｋ２の実行（Ｓ３４）が終了した後に、ＴＰ１に割り当てられた時間が満了した場合、パーティションスケジューラ２１は、ＴＰをＴＰ２又はＴＰ３に切り替える（Ｓ３７）。

以上に説明したように、本実施の形態３では、ＯＳ１００が、ＴＰ１において、制御タスク２４の実行を終了して、次の制御タスク２５の実行が開始されるまでのカーネルモードで、故障検出処理を行うようにしている。

これによれば、ユーザモードとカーネルモードとの間での切り替えを発生させることなく、サービスロボット等の制御対象の情報を取得することができる。したがって、本実施の形態２によれば、プロセッサにかかる負荷を低減することができる。

以上に説明したように、本実施の形態１〜３では、いずれも、ＯＳ１００が、制御タスク２４、２５を実行していない期間に、カーネルモードで、制御対象から情報を取得して、取得した情報に基づいて制御対象の異常を検出する異常検出処理を実行するようにしている。

なお、本発明は上記実施の形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

例えば、実施の形態では、ＴＰ１において、制御タスクと、ＯＳ１００による故障検出処理とを実行するようにしているが、これに限られない。例えば、制御タスク及び故障検出処理のうち、制御タスクのみを実行するＴＰを備えるようにしてもよく、故障検出処理のみを実行するＴＰを備えるようにしてもよい。

また、実施の形態１において、ＴＰ１の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにしているが、これに限られない。ＴＰ１における全ての制御タスクの実行が終了した時点で、故障検出処理を実行するようにしてもよい。この場合に、実施の形態２と同様に、予め設定された設定時間の間、故障検出処理を実行するようにしてもよい。ただし、好ましくは、ＴＰ１の残り期間が、故障検出処理の実行時間以上である場合に、故障検出処理を実行するようにすることで、上述したように、ＴＰ１の期間が本来ＴＰ１に割り当てられている時間を超過する事態を防止することができる。

また、本実施の形態では、タイム・パーティショニングを行うＯＳに適用した場合について例示したが、これに限られない。タイム・パーティショニングは行わない、マルチタスクＯＳに適用するようにしてもよい。

１ 安全制御装置
１０ プロセッサ
１１ 実行用メモリ
１２ Ｉ／Ｏポート
１３ 不揮発性メモリ
１４ リセット回路
１５ マイクロコントローラ
２１ パーティションスケジューラ
２２ スケジューリングテーブル
２３、２６、２８ タスクスケジューラ
２４、２５ 制御タスク
２７ 通常制御タスク
２８ 安全制御タスク
１００ オペレーティングシステム
１０１、１０２ 制御アプリケーション
１０３ 通常制御アプリケーション
１０４ 安全制御アプリケーション

Claims (7)

1. ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをユーザモードで実行するオペレーティングシステムと、前記オペレーティングシステムを実行するプロセッサと、を備えた制御装置であって、
   前記オペレーティングシステムは、少なくとも１つの前記制御タスクに実行時間が割り当てられる制御タイムパーティションを含む複数のタイムパーティションをスケジューリングするパーティションスケジューラを有し、
   前記オペレーティングシステムは、前記制御タイムパーティションにおいて前記制御タスクを実行していない期間は、ユーザモードに切り替えることなくカーネルモードを維持し、
   前記オペレーティングシステムは、前記制御タイムパーティションにおいて前記制御タスクを実行していない期間に、カーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出する異常検出処理を実行し、
   前記パーティションスケジューラは、前記制御タイムパーティションと、前記制御タスクによって前記制御対象を通常動作をさせるための制御計算を行う通常制御タイムパーティションとを含む複数のタイムパーティションを示す通常制御スケジューリングパターンと、前記制御タイムパーティションと、前記制御タスクによって前記制御対象を安全方向に動作させる又は停止させるための制御計算を行う安全制御タイムパーティションとを含む複数のタイムパーティションを示す安全制御スケジューリングパターンとのいずれかに基づいて、前記スケジューリングを行い、
   前記オペレーティングシステムは、前記異常検出処理によって前記制御対象の異常を検出した場合、前記パーティションスケジューラが利用するスケジューリングパターンを、前記通常制御スケジューリングパターンから、前記安全制御スケジューリングパターンに切り替える、
   制御装置。
2. 前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タイムパーティションに実行時間が割り当てられる全ての制御タスクの実行を終了して、ユーザモードからカーネルモードに切り替えたときに、前記異常検出処理を実行する、
   請求項１に記載の制御装置。
3. 前記オペレーティングシステムは、前記全ての制御タスクの実行を終了したときにおける前記制御タイムパーティションの残り期間が、前記異常検出処理の実行時間以上である場合に、前記異常検出処理を実行する、
   請求項２に記載の制御装置。
4. 前記オペレーティングシステムは、前記パーティションスケジューラが前記制御タイムパーティションに切り替えたとき、かつ前記制御タスクの実行を開始する前に、前記異常検出処理を実行する、
   請求項１に記載の制御装置。
5. 前記制御タイムパーティションは、複数の前記制御タスクに実行時間が割り当てられ、
   前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タスクの実行を終了して、次の前記制御タスクの実行を開始するまでの期間に、前記異常検出処理を実行する、
   請求項１に記載の制御装置。
6. 前記オペレーティングシステムは、前記制御タイムパーティションにおいて、前記制御タスクをスケジューリングするタスクスケジューラを有する、
   請求項１乃至５のいずれか１項に記載の制御装置。
7. ユーザモード及びカーネルモードのうち、カーネルモードでアクセス可能である制御対象を制御する制御タスクをプロセッサによってユーザモードで実行する制御方法であって、
   前記プロセッサが、少なくとも１つの前記制御タスクに実行時間が割り当てられる制御タイムパーティションを含む複数のタイムパーティションをスケジューリングするステップと、
   前記プロセッサが、前記制御タイムパーティションにおいて、前記制御タスクが実行終了したときに、ユーザモードからカーネルモードに切り替えるステップと、
   前記プロセッサが、前記切り替え後のカーネルモードで、前記制御対象から情報を取得して、取得した情報に基づいて前記制御対象の異常を検出するステップと、を備え、
   前記切り替え後のカーネルモードは、前記制御タイムパーティションが終了するまでユーザモードに切り替えることなく維持され、
   前記タイムパーティションをスケジューリングするステップでは、前記制御タイムパーティションと、前記制御タスクによって前記制御対象を通常動作をさせるための制御計算を行う通常制御タイムパーティションとを含む複数のタイムパーティションを示す通常制御スケジューリングパターンと、前記制御タイムパーティションと、前記制御タスクによって前記制御対象を安全方向に動作させる又は停止させるための制御計算を行う安全制御タイムパーティションとを含む複数のタイムパーティションを示す安全制御スケジューリングパターンとのいずれかに基づいて、前記スケジューリングを行い、
   前記制御対象の異常を検出するステップでは、前記制御対象の異常を検出した場合、前記スケジューリングするステップにおいて利用するスケジューリングパターンを、前記通常制御スケジューリングパターンから、前記安全制御スケジューリングパターンに切り替える、
   制御方法。

Images