JP5849731B2 - 情報処理装置及びデータ格納方法 - Google Patents

Description

本発明は、情報処理装置及びデータ格納方法に関し、特に、データを格納するタスクと、そのデータよりも格納する優先度の高いデータを格納するタスクとを実行する情報処理装置及びデータ格納方法に関する。

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

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

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

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

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

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

ここで、特許文献１に開示の技術では、リソース・パーティショニングという技術を採用している。この技術では、実行用メモリ等の固定的な資源をリソースパーティションと言われるパーティションにパーティショニングしている。そして、アプリケーションは、予め割り当てられたリソースパーティションを超えて他のリソースにアクセスすることが禁止される。

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

本願出願人は、特許文献１に開示されるような安全制御装置に基づいて、新たに、ログを保存する安全制御装置を検討するにあたり、以下に説明する課題を見出した。以下、その課題について説明する。なお、以下に説明する内容は、本願出願人が新たに検討した内容であって、従来技術を説明したものではない。

安全制御装置の動作・制御状況の調査を容易にする手法として、ログを保存することが考えられる。ここで、安全制御装置では、安全関連アプリケーションから起動される安全関連系タスクと、非安全関連アプリケーションから起動される非安全関連系タスクとが並列実行されることになる。

このような調査において、十分な調査を可能とするためには、全てのタスク（安全関連系タスク及び非安全関連系タスク）のそれぞれでログを保存しておくことが好ましい。しかしながら、そのようにした場合には、タスクの並列実行状況によっては、期待するログが保存されなくなってしまう場合がある。

具体的には、上述したような調査が必要となる主なケースとして、安全制御装置において異常が検出された場合が考えられる。ここで、安全制御装置における異常の検出は、主に、機能安全の確保に関する処理を実行する安全関連系タスクで行われることになる。しがたって、非安全関連系タスクが採取するログよりも、安全関連系タスクが採取する異常に関するログの方が、保存すべき優先度は高い。

その一方で、異常検出時には、安全制御装置において各タスクを制御するマイクロコントローラをリセットして、安全制御装置の復旧を行う場合もある。この場合、ウォッチドッグタイマーに対する信号を停止させることで、一定時間の経過後に、マイクロコントローラをリセットさせることが考えられる。これによれば、この一定時間が経過するまでに、ログを採取することも可能となる。

しかしながら、タスクの並列実行状況によっては、マイクロコントローラがリセットされるまでの一定時間の間に非安全関連系タスクが動作してしまい、非安全関連系タスクによってログの保存は行われるが、優先度の高いログを保存する安全関連系タスクの動作時間がなくなってしまい、安全関連系タスクによるログの保存が間に合わなくなってしまう場合がある。それに対して、マイクロコントローラをリセットするまでの時間を長くすることで、非安全関連系タスクの動作後においても、安全関連系タスクによるログの保存を間に合わせることもできる。しかしながら、そのようにしてしまうと、安全制御装置を復旧するまでの時間が長くなってしまい、運用上好ましくない。

これは、上述したケースに限られず、データを保存するタスクと、そのデータよりも保存する優先度の高いデータを保存するタスクとが動作するシステムであれば、同様のことが言える。

本発明は、上述した知見に基づいてなされたものであって、特定のタスクのデータを優先して保存することができる情報処理装置及びデータ格納方法を提供することを目的とする。

本発明の第１の態様にかかる情報処理装置は、第１のデータと、前記第１のデータよりも格納する優先度の高い第２のデータとが格納される記憶部と、前記記憶部に前記第１のデータを格納する第１のタスクと、前記記憶部に前記第２のデータを格納する第２のタスクとをスケジューリングして実行するタスク実行部と、前記第１のタスクからのデータ格納要求に応じて、前記第１のタスクに代わって前記記憶部に前記第１のデータを格納するとともに、前記第２のタスクからのデータ格納要求に応じて、前記第２のタスクに代わって前記記憶部に前記第２のデータを格納するデータ格納制御と、を備え、前記データ格納制御部は、前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がある場合には、前記第１のタスクからのデータ格納要求がある場合であっても、前記第２のタスクからのデータ格納要求に応じて、前記記憶部に前記第２のデータを格納するものである。

本発明の第２の態様にかかるは、第１のデータと、前記第１のデータよりも格納する優先度の高い第２のデータとが格納される記憶部に前記第１のデータを格納する第１のタスクと、前記記憶部に前記第２のデータを格納する第２のタスクとをスケジューリングして実行開始する実行開始ステップと、前記第１のタスクからのデータ格納要求に応じて、前記第１のタスクに代わって前記記憶部に前記第１のデータを格納する第１のデータ格納ステップと、前記第２のタスクからのデータ格納要求に応じて、前記第２のタスクに代わって前記記憶部に前記第２のデータを格納する第２のデータ格納ステップと、を備え、前記第２のデータ格納ステップでは、前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がある場合には、前記第１のタスクからのデータ格納要求がある場合であっても、前記第２のタスクからのデータ格納要求に応じて、前記記憶部に前記第２のデータを格納するものである。

上述した本発明の各態様によれば、特定のタスクのデータを優先して保存することができる情報処理装置及びデータ格納方法を提供することができる。

発明の実施の形態にかかる安全制御装置の構成例を示すブロック図である。 発明の実施の形態におけるタイム・パーティショニングの概念を説明するための図である。 発明の実施の形態におけるリソース・パーティショニングの概念を説明するための概念図である。 発明の実施の形態におけるパーティションスケジューラとタスクとの関係を示す図である。 スケジューリングパターンの具体例を示す図である。 スケジューリングパターンの具体例を示す図である。 発明の実施の形態にかかる安全関連系タスク及び非安全関連と、データＷｒｉｔｅ用タスクとの関係を示す図である。 発明の実施の形態にかかるパーティションスケジューラの処理手順の具体例を示すフローチャートである。 発明の実施の形態にかかるログ格納の処理手順の具体例を示すフローチャートである。 発明の実施の形態にかかるログ格納の処理手順による具体的な処理例を示すシーケンス図である。 発明の実施の形態にかかるログ格納の処理手順による具体的な処理例を示すシーケンス図である。 その他の実施の形態にかかるパーティションスケジューラとタスクとの関係を示す図である。 その他の実施の形態にかかるパーティションスケジューラとタスクとの関係を示す図である。

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

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

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

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

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

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

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

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

ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）１４は、電力の供給を受けることなく、実行用メモリ１１に比べて安定的に記憶内容を維持することが可能なメモリデバイスである。ＥＥＰＲＯＭ１４は、アプリケーション１０１〜１０３によって、データＷｒｉｔｅ用アプリケーション１０４、１０５を介してログが格納される。ＥＥＰＲＯＭ１４は、安全関連アプリケーション１０１、１０３（安全関連系タスク）のログが格納される領域と、非安全関連アプリケーション１０２（非安全関連系タスク）のログが格納される領域とを含む。なお、アプリケーション１０１〜１０３によって、ログが格納される記憶装置として、ＥＥＰＲＯＭ１４以外に、フラッシュメモリ等のその他の不揮発性メモリを使用するようにしてもよい。また、本実施の形態では、ＥＥＰＲＯＭ１４にログが格納される場合について例示するが、ＥＥＰＲＯＭ１４に格納されるデータは、ログに限られない。

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

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

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

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

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

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

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

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

図１に戻り説明を続ける。アプリケーション１０１〜１０５は、ＯＳ１００及びプロセッサ１０によって提供されるマルチプログラミング環境で実行される。このうち、安全監視アプリケーション１０１は、通常制御アプリケーション１０２の実行状況の監視と、安全制御アプリケーション１０３の実行状況の監視と、Ｉ／Ｏポート１２への入出力データの監視と、をプロセッサ１０に実行させるための命令コードを含む。さらに、安全監視アプリケーション１０１は、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。さらに、安全関連アプリケーション１０１は、ログの生成と、データＷｒｉｔｅ用アプリケーション１０５に対するログのＥＥＰＲＯＭ１４への格納の要求と、をプロセッサ１０に実行させるための命令コードを含む。つまり、安全監視アプリケーション１０１は、安全関連アプリケーションである。

また、通常制御アプリケーション１０２は、サービスロボット等の制御対象に通常の機能・動作を行わせるための制御手順をプロセッサ１０に実行させるための命令コードを含む。さらに、通常制御アプリケーション１０２は、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。さらに、通常制御アプリケーション１０２は、ログの生成と、データＷｒｉｔｅ用アプリケーション１０６に対するログのＥＥＰＲＯＭ１４への格納の要求と、をプロセッサ１０に実行させるための命令コードを含む。つまり、通常制御アプリケーション１０２は、非安全関連アプリケーションである。

また、安全制御アプリケーション１０３は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御手順をプロセッサ１０に実行させるための命令コードを含む。さらに、安全制御アプリケーション１０３は、パーティションスケジューラ２１への結果通知をプロセッサ１０に実行させるための命令コードを含む。さらに、安全制御アプリケーション１０３は、ログの生成と、データＷｒｉｔｅ用アプリケーション１０５に対するログのＥＥＰＲＯＭ１４への格納の要求と、をプロセッサ１０に実行させるための命令コードを含む。つまり、安全制御アプリケーション１０３は、安全関連アプリケーションである。

また、データＷｒｉｔｅ用アプリケーション１０５は、安全関連アプリケーション１０１、１０３からの要求に応じたログのＥＥＰＲＯＭ１４への格納をプロセッサ１０に実行させるための命令コードを含む。

また、データＷｒｉｔｅ用アプリケーション１０６は、非安全関連アプリケーション１０２からの要求に応じたログのＥＥＰＲＯＭ１４への格納をプロセッサ１０に実行させるための命令コードを含む。

リセット回路１５は、ＯＳ１００からの信号に基づき、マイクロコントローラ２０のリセットを行う。パーティションスケジューラ２１からリセット回路１５に定期的に送信信号を送信するようにし、リセット回路１５は、所定の時間の間、パーティションスケジューラ２１からの送信信号が途絶えた場合に、マイクロコントローラ２０をリセットする。すなわち、リセット回路１５は、ウォッチドッグタイマーとして機能する。例えば、パーティションスケジューラ２１は、後述するように、１Ｔｉｃｋごとに動作するタイミングでリセット回路１５に送信信号を送信する。そして、パーティションスケジューラ２１は、ＯＳ１００で異常を検知した場合、又は、アプリケーション１０１〜１０３のいずれかから異常を示す結果通知を受けた場合に、リセット回路１５への送信信号の送信を停止する。これによって、所定の時間の経過後に、リセット回路１５がマイクロコントローラ２０をリセットする。

また、ＯＳ１００で異常を検知した場合、又は、アプリケーション１０１〜１０５のいずれかから異常を示す結果通知を受けた場合に、パーティションスケジューラ２１がリセット回路１５にリセット信号を送信するようにして、それに応じて、リセット回路１５がマイクロコントローラ２０をリセットするようにしてもよい。このようにすることで、マイクロコントローラ２０に不具合が発生した場合に、マイクロコントローラ２０をリセットして復旧することができる。

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

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

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

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

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

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

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

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

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

安全監視タスク２４は、安全監視アプリケーション１０１の起動によって生成されるタスクである。図４の例では、安全監視タスク２４は、ＴＰ１及びＲＰ１に割り当てられている。安全監視タスク２４は、非安全関連アプリケーションである通常制御タスク２６の実行状況の監視と、安全関連アプリケーションである安全制御タスク２８の実行状況の監視と、Ｉ／Ｏポート１２の入出力データを監視する。さらに、安全監視タスク２４は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。さらに、安全監視タスク２４は、自身の処理に応じたログを生成して、生成したログのＥＥＰＲＯＭ１４への格納をデータＷｒｉｔｅ用タスク２９に要求する。安全監視タスク２４は、自身が属するＲＰ１に割り当てられた実行用メモリ１１のリソースを使用しながら、自身の処理を実行するために必要な演算等を行う。

通常制御タスク２６は、通常制御アプリケーション１０２の起動によって生成されるタスクである。図４の例では、通常制御タスク２６は、ＴＰ２及びＲＰ２に割り当てられている。通常制御タスク２６は、サービスロボット等の制御対象に通常の機能・動作を行わせるための制御を行う。さらに、通常制御タスク２６は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。さらに、通常制御タスク２６は、自身の処理に応じたログを生成して、生成したログのＥＥＰＲＯＭ１４への格納をデータＷｒｉｔｅ用タスク３０に要求する。通常制御タスク２６は、自身が属するＲＰ２に割り当てられた実行用メモリ１１のリソースを使用しながら、自身の処理を実行するために必要な演算等を行う。

安全制御タスク２８は、安全制御アプリケーション１０３の起動によって生成されるタスクである。図４の例では、安全制御タスク２８は、ＴＰ３及びＲＰ３に割り当てられている。安全制御タスク２８は、何らかの異常が検出された場合に対応して、機能安全を確保するために定められた制御を行う。さらに、安全制御タスク２８は、タスクの実行状況を、パーティションスケジューラ２１へ通知する。さらに、安全制御タスク２８は、自身の処理に応じたログを生成して、生成したログのＥＥＰＲＯＭ１４への格納をデータＷｒｉｔｅ用タスク２９に要求する。安全制御タスク２８は、自身が属するＲＰ３に割り当てられた実行用メモリ１１のリソースを使用しながら、自身の処理を実行するために必要な演算等を行う。

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

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

データＷｒｉｔｅ用タスク２９は、安全関連系タスク２４、２８からの要求に応じて、安全関連系タスク２４、２８が生成したログをＥＥＰＲＯＭ１４に格納する。図４の例では、データＷｒｉｔｅ用タスク２９は、ＴＰ１及びＲＰ１に割り当てられている。データＷｒｉｔｅ用タスク２９は、自身が属するＲＰ１に割り当てられた実行用メモリ１１のリソースを使用しながら、自身の処理を実行するために必要な演算等を行う。

データＷｒｉｔｅ用タスク３０は、非安全関連系タスク２６からの要求に応じて、非安全関連系タスク２６が生成したログをＥＥＰＲＯＭ１４に格納する。図４の例では、データＷｒｉｔｅ用タスク３０は、ＴＰ１及びＲＰ１に割り当てられている。データＷｒｉｔｅ用タスク２９は、自身が属するＲＰ１に割り当てられた実行用メモリ１１のリソースを使用しながら、自身の処理を実行するために必要な演算等を行う。

ここで、データＷｒｉｔｅ用タスク２９、３０が割り当てられるＴＰ及びＲＰは、図４に例示した場合に限られない。例えば、安全関連のＴＰ１、ＴＰ３に限られず、非安全関連のＴＰ２に属するようにしてもよく、データＷｒｉｔｅ用タスク２９、３０のみが属するデータＷｒｉｔｅ用のＴＰを用意して、それに属するようにしてもよい。なお、常にログの保存を可能とするためには、図５Ａ及び図５Ｂで例示するＴＰ１のように、通常制御スケジューリングパターン及び安全制御スケジューリングパターンのいずれのスケジューリングパターンにおいても、アクティブとなるＴＰで動作するようにすることが好ましい。

ここで、各タスク２４、２６、２８は、ログとして、それぞれの処理に応じた内容のデータを生成する。安全監視タスク２４は、例えば、上述したような監視における監視内容等を示すデータをログとして生成する。すなわち、監視の結果、何らかの異常が検出された場合には、安全監視タスク２４は、その異常原因に関するデータをログとして生成することになる。具体的には、安全監視タスク２４は、ログとして、Ｉ／Ｏポート１２を介して各種センサから取得したセンサ値及びセンサ値に基づいて算出した値等を生成する。例えば、通常制御タスク２６又は安全制御タスク２８からＩ／Ｏポート１２を介して制御対象に対して出力された出力データ値、視覚センサから取得した画像データ、視覚センサから取得した画像データに基づいて算出した障害物までの距離、姿勢センサから取得した制御対象の姿勢を示す値、回転センサから取得した制御対象のアクチュエータの状態を示す値、及び、制御対象又はマイクロコントローラ２０における回路の電流値等を示すデータである。また、通常制御タスク２６及び安全制御タスク２８のそれぞれは、例えば、制御対象に対する出力データの計算内容等を示すデータをログとして生成する。

ここで、主に、ログに基づいた安全制御装置１の動作・制御状況の調査は、安全制御装置１において何らかの異常が検出された場合に、その異常原因を特定するために行われる。すなわち、安全監視タスク２４によって採取されるログは、他のログと比較してＥＥＰＲＯＭ１４に保存する優先度は高い。このように、安全関連系タスク２４、２８は、異常の検出及び検出した異常に応じた処理等の機能安全を確保するための処理を実行するタスクとなる。そのため、安全関連系タスク２４、２８が採取するログは、異常原因により強く関連したログとなるため、非安全関連系タスク２６が採取するログと比較して、ＥＥＰＲＯＭ１４に保存する優先度は高くなる。

そこで、本実施の形態では、非安全関連系タスクのログを保存するデータＷｒｉｔｅ用タスク３０よりも、安全関連系タスクのログを保存するデータＷｒｉｔｅ用タスク２９によるログの保存を優先的に行うことで、重要なログがより多く採取されるようにする。

続いて、図６を参照して、発明の実施の形態にかかる安全関連系タスク２４、２８及び非安全関連系タスク２６と、データＷｒｉｔｅ用タスク２９、３０との関係について説明する。図６は、発明の実施の形態にかかる安全関連系タスク２４、２８及び非安全関連系タスク２６と、データＷｒｉｔｅ用タスク２９、３０との関係を示す図である。

上述したように、ＯＳ１００は、ＯＳ１００上で動作するタスクに対してタスク間通信機能を提供する。具体的には、ＯＳ１００は、ＯＳ１００上で動作するタスクに対して、タスク間通信を行うためのシステムコールを提供する。

安全関連系タスク２４、２８は、自身が生成したログをＥＥＰＲＯＭ１４に格納する場合には、ログの格納を要求するログ格納要求データを、タスク間通信によってデータＷｒｉｔｅ用タスク２９に送信する。これは、安全関連系タスクが、ログ格納要求データを引数として指定して、ＯＳ１００によって提供されるシステムコールを呼び出すことによって行われる。なお、ログ格納要求データには、安全関連系タスクが生成したログと、そのログを格納するＥＥＰＲＯＭ１４のアドレスを示すデータとが含まれる。

システムコールの呼び出しによって動作するＯＳ１００のルーチンは、安全関連系タスクによって指定されたログ格納要求データを、リクエスト用のデータキュー(ＤＴＱ)に格納する。すなわち、データキューは、「メッセージキュー」として機能する。なお、データキューは、実行用メモリ１１の一部領域を利用して実現される。

データＷｒｉｔｅ用タスク２９は、安全関連系タスクから送信されたログ格納要求データを、タスク間通信によって受信する。これは、データＷｒｉｔｅ用タスク２９が、ＯＳ１００によって提供されるシステムコールを呼び出すことによって行われる。システムコールの呼び出しによって動作するＯＳ１００のルーチンは、リクエスト用のデータキューに格納されたログ格納要求データを読み出して、データＷｒｉｔｅ用タスク２９に受け渡す。具体的には、ＯＳ１００のルーチンは、システムコールの戻り値として、ログ格納要求データを呼び出し元のデータＷｒｉｔｅ用タスク２９に受け渡す。

データＷｒｉｔｅ用タスク２９は、タスク間通信によって受信したログ格納要求データに含まれるログをＥＥＰＲＯＭ１４に格納する。なお、データＷｒｉｔｅ用タスク２９は、そのログ格納要求データが示すＥＥＰＲＯＭ１４のアドレスにログを格納する。そして、データＷｒｉｔｅ用タスク２９は、ＥＥＰＲＯＭ１４へのログの格納結果を通知する結果通知データを、タスク間通信によってログの格納の要求元の安全関連系タスクに送信する。これは、上述と同様に、データＷｒｉｔｅ用タスク２９が、結果通知データを引数として、ＯＳ１００によって提供されるシステムコールを呼び出すことによって行われる。システムコールの呼び出しによって動作するＯＳ１００のルーチンは、データＷｒｉｔｅ用タスク２９によって指定された結果通知データを、レスポンス用のデータキューに格納する。

安全関連系タスクは、データＷｒｉｔｅ用タスク２９から送信された結果通知データを、タスク間通信によって受信する。これは、上述と同様に、安全関連系タスクが、ＯＳ１００によって提供されるシステムコールを呼び出すことによって行われる。システムコールの呼び出しによって動作するＯＳ１００のルーチンは、レスポンス用のデータキューに格納された結果通知データを読み出して、安全関連系タスクに受け渡す。具体的には、ＯＳ１００のルーチンは、システムコールの戻り値として、結果通知データを安全関連系タスクに受け渡す。

なお、非安全関連系タスクからデータＷｒｉｔｅ用タスク３０に対して、ログの格納を要求する場合も、同様にしてタスク間通信によって行われるため、説明を省略する。

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

なお、図７では、通常制御スケジューリングパターン（例えば図５Ａ）または安全制御スケジューリングパターン（例えば図５Ｂ）に従って、スケジューリングを実行する場合を例に説明する。すなわち、ＴＰ２またはＴＰ３に続く次のＴＰはＴＰ１であり、かつ、ＴＰ２での異常がＴＰ１で検知された場合に、ＴＰ１からの結果を受けて次に選択・決定されるＴＰはＴＰ３である場合を例に説明する。

ＯＳ１００は、１Ｔｉｃｋ経過するごとに（Ｓ１１）、パーティションスケジューラ２１を起動する（Ｓ１２）。パーティションスケジューラ２１は、スケジューリングパターンを参照して、ＴＰの切り替えタイミングか否かを判定する（Ｓ１３）。

ＴＰの切り替えタイミングでないと判定した場合（Ｓ１３でＮｏ）、パーティションスケジューラ２１は、同一のＴＰＸについての動作を継続させる。このため、ＴＰの切り替えタイミングとなるまでの間、Ｓ１１〜Ｓ１３、Ｓ１５、Ｓ１６の処理が繰り返される。ここで、変数ＸはＴＰの番号を示し、Ｘは１〜３のうちのいずれかの値となる。すなわち、通常制御スケジューリングパターンに従ってパーティション・スケジューリングを実施している場合は、安全制御用のＴＰ３を除いた、ＴＰ２及びＴＰ１のいずれかを動作させる。

一方、ＴＰの切り替えタイミングであると判定した場合（Ｓ１３でＹｅｓ）、パーティションスケジューラ２１は、ＴＰの切り替えを実行する（Ｓ１４）。このように、パーティションスケジューラ２１は、次にアクティブにするＴＰを変更する（Ｓ１３でＹｅｓ）場合には、さらに、切り替え前のＴＰに属するタスクからの通知結果に応じて、切り替え前のＴＰが正常であったか否かを判断する。判断の結果、切り替え前のＴＰが異常であった場合、パーティションスケジューラ２１は、次の１Ｔｉｃｋの間にアクティブにするＴＰＸを、安全制御スケジューリングパターンに従って、ＴＰ１及びＴＰ３のいずれかから選択・決定する。判断の結果、正常であった場合、パーティションスケジューラ２１は、次の１Ｔｉｃｋの間にアクティブにするＴＰＸを、通常制御スケジューリングパターンに従って、ＴＰ１及びＴＰ２のいずれかを選択・決定する。

パーティションスケジューラ２１は、現在アクティブになっているＴＰＸのタスクスケジューラを動作させる（Ｓ１５）。Ｓ１５で動作を開始したＴＰＸのタスクスケジューラは、ＴＰＸ内のタスクを優先度に応じて実行する（Ｓ１６）。

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

図７で示した処理に関して、パーティション・スケジューリングの具体例を説明する。まず、図５Ａに例示した通常制御スケジューリングパターンに従って、Ｓ１５においてＴＰ２がアクティブの状態からスケジューリングを開始した場合を説明する。この場合、Ｓ１５ではＴＰＸ＝ＴＰ２として開始し、続くＳ１６、Ｓ１１〜Ｓ１３にかけてもＴＰＸ＝ＴＰ２のままである。そして、Ｓ１３でＮｏが続く限り、ＴＰＸ＝ＴＰ２の状態が維持される。Ｓ１３でＹｅｓとなり、Ｓ１４でＴＰ２からＴＰ１へと変更された場合、続くＳ１５〜Ｓ１６、Ｓ１１〜Ｓ１３にかけてＴＰ１のままである。そして、Ｓ１３でＮｏが続く限り、ＴＰＸ＝ＴＰ１の状態が維持される。ＴＰ１がアクティブのときに、Ｓ１６で、ＴＰ２に関する実行状況（データ入出力等）が正常であると判定されていた場合には、次のＳ１４では、ＴＰＸ＝ＴＰ２となる（つまり、ＴＰ２から開始する通常制御スケジューリングパターンが継続される。）。一方で、Ｓ１６で、ＴＰ２に関する実行状況（データ入出力等）が異常であると判定されていた場合には、次のＳ１４で、ＴＰＸ＝ＴＰ３となる（つまり、ＴＰ３から開始する安全制御スケジューリングパターンに切り替わる。）。

また、図５Ｂに例示した安全制御スケジューリングパターンに従って、Ｓ１５においてＴＰ３がアクティブの状態からスケジューリングを開始した場合を説明する。この場合、Ｓ１５ではＴＰＸ＝ＴＰ３として開始し、続くＳ１６、Ｓ１１〜Ｓ１３にかけてもＴＰＸ＝ＴＰ３のままである。そして、Ｓ１３でＮｏが続く限り、ＴＰＸ＝ＴＰ３の状態が維持される。Ｓ１３でＹｅｓとなり、Ｓ１４でＴＰ３からＴＰ１へと変更された場合、続くＳ１５〜Ｓ１６、Ｓ１１〜Ｓ１３にかけてＴＰ１のままである。そして、Ｓ１３でＮｏが続く限り、ＴＰＸ＝ＴＰ１の状態が維持される。ＴＰ１がアクティブのときに、Ｓ１６で、ＴＰ３に関する実行状況（データ入出力等）が正常であると判定されていた場合には、次のＳ１４では、ＴＰＸ＝ＴＰ２とする（つまり、ＴＰ２から開始する通常制御スケジューリングパターンに切り替わる。）。一方で、Ｓ１６で、ＴＰ３に関する実行状況（データ入出力等）に異常があると判定されていた場合には、次のＳ１４で、ＴＰＸ＝ＴＰ３となる（つまり、ＴＰ３から開始する安全制御スケジューリングパターンが継続される。）。

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

上述したように、本実施の形態では、ＯＳ１００は、安全監視用のＴＰ１からの通知、または、各ＴＰからの通知に応じて、次にアクティブとするパーティションを選択・決定するパーティションスケジューラ２１を備えている。パーティションスケジューラ２１は、各ＴＰにおいて実行されるタスクとは独立して、所定のタイマー周期で動作する。

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

続いて、図８を参照して、本実施の形態にかかるログ格納の処理手順について説明する。図８は、本実施の形態にかかるログ格納の処理手順を示すフローチャートである。

安全関連系タスクが、ＥＥＰＲＯＭ１４へのログの格納を、データＷｒｉｔｅ用タスク２９に対して要求しているか否かを判定する（Ｓ２１）。ここで、本実施の形態では、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求しているか否かが判定されるケースとして、２つのケースが存在する。

１つ目のケースは、データＷｒｉｔｅ用タスク２９が、ＯＳ１００が提供するシステムコールを呼び出すことによって、スリープして待ち状態となっているときに、ＯＳ１００によって判定されるケースである。このシステムコールは、呼び出し元のタスクをスリープさせるとともに、呼び出し元のタスクに対するデータがリクエスト用のデータキューに格納されたときに、呼び出し元のタスクを起床させて、実行状態に遷移させる。

したがって、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納をデータＷｒｉｔｅ用タスク２９に要求している場合（Ｓ２１：Ｙｅｓ）には、ＯＳ１００は、タスクスケジューラ２３によって、データＷｒｉｔｅ用タスク２９を起床させて、実行状態に遷移させる。実行状態に遷移して動作を開始したデータＷｒｉｔｅ用タスク２９は、上述したログ格納要求データを受信するシステムコールを呼び出して、ログ格納要求データを取得する（Ｓ２４）。そして、データＷｒｉｔｅ用タスク２９は、取得したログ格納要求データに基づいて、安全関連系タスクのログを格納する処理（Ｓ２６〜Ｓ３０）を行う。一方、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納をデータＷｒｉｔｅ用タスク２９に要求していない場合（Ｓ２１：Ｎｏ）、ＯＳ１００は、データＷｒｉｔｅ用タスク２９の待ち状態を継続させるとともに、非安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を、データＷｒｉｔｅ用タスク３０に対して要求しているか否かを判定する（Ｓ２２）。

２つ目のケースは、データＷｒｉｔｅ用タスク２９が、実行状態となって動作しており、ＯＳ１００が提供するシステムコールを呼び出すことによって判定を行うケースである。この判定は、例えば、データＷｒｉｔｅ用タスク２９が、上述したログ格納要求データを受信するシステムコールを呼び出すことによって行う。データＷｒｉｔｅ用タスク２９は、リクエスト用のデータキューにログ格納要求データが格納されており、システムコールの呼び出しによって、そのログ格納要求データを取得することができた場合には、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求していると判定する（Ｓ２１：Ｙｅｓ、Ｓ２４）。一方、データＷｒｉｔｅ用タスク２９は、リクエスト用のデータキューにログ格納要求データが格納されておらず、システムコールの呼び出しによって、ログ格納要求データを取得することができなかった場合には、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求していないと判定する（Ｓ２１：Ｎｏ）。すなわち、２つ目のケースでは、データＷｒｉｔｅ用タスク２９が、ポーリングによって、安全関連系タスクがログの格納を要求しているか否かを判定する。

安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求している場合（Ｓ２１：Ｙｅｓ）には、データＷｒｉｔｅ用タスク２９は、取得したログ格納要求データに基づいて、安全関連系タスクのログを格納する処理（Ｓ２６〜Ｓ３０）を行う。一方、安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求していない場合（Ｓ２１：Ｎｏ）、上述したスリープするシステムコールを呼び出して、その実行を終了する。これによって、ＯＳ１００に制御が移る。そして、ＯＳ１００は、非安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を、データＷｒｉｔｅ用タスク３０に対して要求しているか否かを判定する（Ｓ２２）。

ここで、非安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納を要求しているか否かが判定されるケースは、データＷｒｉｔｅ用タスク３０が、上述したスリープするシステムコールを呼び出すことによって、待ち状態となっているときに、ＯＳ１００によって判定されるケースのみである。

そして、非安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納をデータＷｒｉｔｅ用タスク３０に要求している場合（Ｓ２２：Ｙｅｓ）には、ＯＳ１００は、タスクスケジューラ２３によって、データＷｒｉｔｅ用タスク３０を起床させて、実行状態に遷移させる。実行状態に遷移して動作を開始したデータＷｒｉｔｅ用タスク３０は、上述したログ格納要求データを受信するシステムコールを呼び出して、ログ格納要求データを取得する（Ｓ２５）。そして、データＷｒｉｔｅ用タスク３０は、取得したログ格納要求データに基づいて、非安全関連系タスクのログを格納する処理（Ｓ２６〜Ｓ３０）を行う。一方、非安全関連系タスクがＥＥＰＲＯＭ１４へのログの格納をデータＷｒｉｔｅ用タスク３０に要求していない場合（Ｓ２２：Ｎｏ）、ＯＳ１００は、データＷｒｉｔｅ用タスク３０の待ち状態を継続させる。

このようにして、データＷｒｉｔｅ用タスク２９又はデータＷｒｉｔｅ用タスク３０に対して、ログの格納が要求されるまで、待ち合わせが行われる（Ｓ２３）。この後も、Ｓ２１及びＳ２２が繰り返され、ログの格納の要求に応じて、ログを格納する処理（Ｓ２６〜Ｓ３０）を行うといった処理手順が繰り返される。

また、上述したように、先に安全関連系タスクからのログの格納要求を判定し、次に非安全関連系タスクからのログの格納要求が判定されるようにしている。これによれば、安全関連系のログと非安全関連系のログの保存が同時に要求されている場合であっても、優先度の高い安全関連系のログを優先してＥＥＰＲＯＭ１４に格納することができる。これは、データＷｒｉｔｅ用タスク２９を実行する優先度を、データＷｒｉｔｅ用タスク３０よりも高くしておくことで、ＴＰ１においてデータＷｒｉｔｅ用タスク３０よりもデータＷｒｉｔｅ用タスク２９が先にスケジューリングされるようにすることで実現する。

ログの格納が要求されたデータＷｒｉｔｅ用タスクは、ログ格納要求データで指定されるログを格納するアドレスが、許容範囲内か否かを判定する（Ｓ２６）。具体的には、データＷｒｉｔｅ用タスクは、指定されたアドレスが、ＥＥＰＲＯＭ１４の有効アドレスに収まっているか否かを判定する。さらに、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク３０である場合は、指定されたアドレスが、ＥＥＰＲＯＭ１４の安全関連系タスク用の領域を指定していないか否かを判定する。

すなわち、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク２９であるときは、指定されたアドレスが、ＥＥＰＲＯＭ１４の有効アドレスに収まっている場合には、アドレスが許容範囲内であると判定する（Ｓ２７：Ｙｅｓ）。一方、指定されたアドレスが、ＥＥＰＲＯＭ１４の有効アドレスに収まっていない場合には、アドレスが許容範囲内でないと判定する（Ｓ２７：Ｎｏ）。

また、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク３０であるときは、指定されたアドレスが、ＥＥＰＲＯＭ１４の有効アドレスに収まっており、かつ、ＥＥＰＲＯＭ１４の安全関連系タスク用の領域でない場合（又はＥＥＰＲＯＭ１４の非安全関連系タスク用の領域である場合）には、アドレスが許容範囲内であると判定する（Ｓ２７：Ｙｅｓ）。一方、指定されたアドレスが、ＥＥＰＲＯＭ１４の有効アドレスに収まっていない場合、又は、ＥＥＰＲＯＭ１４の安全関連系タスク用の領域である場合（又はＥＥＰＲＯＭ１４の非安全関連系タスク用の領域でない場合）には、アドレスが許容範囲内でないと判定する（Ｓ２７：Ｎｏ）。

アドレスが許容範囲内でないと判定した場合（Ｓ２７：Ｎｏ）、データＷｒｉｔｅ用タスクは、ＥＥＰＲＯＭ１４へのログの格納は行わずに、異常を通知する結果通知データを、タスク間通信によって、要求元のタスクに対して送信する（Ｓ３０）。

このようにすることで、安全関連系タスク用の領域に格納された、優先度の高い安全関連系タスクのログが、非安全関連系タスクのログで上書きされないようにすることができる。また、これによれば、低コストかつ省スペースで、非安全関連系タスクのログに対する、安全関連系タスクのログの独立性を保証することができる。例えば、安全関連系タスクのログと非安全関連系タスクのログのそれぞれが格納される２つＥＥＰＲＯＭと、それぞれのＥＥＰＲＯＭに対するデータの格納を処理する２つの処理ルーチン（例えば、ドライバ等）を設けることで、独立性を保証する方法も考えられる。しかしながら、この場合は、２つのＥＥＰＲＯＭと、２つの処理ルーチンとを実装する必要があるため、コストが高くなってしまうという問題がある。また、２つのＥＥＰＲＯＭを実装するために、実装スペースも消費してしまうという問題もある。それに対して、本実施形態によれば、１つのＥＥＰＲＯＭ１４のみであっても、優先度の高い安全関連系タスクのログの上書きを防止することができる。そのため、低コストかつ省スペースで、ログの独立性を保証することができる。

なお、上述した説明では、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク２９である場合は、指定されたアドレスが、ＥＥＰＲＯＭ１４の非安全関連系タスク用の領域を指定していないか否かは判定していない。これよれば、非安全関連系タスクよりも、安全関連系タスクの方が、ログの優先度は高いことから、安全関連系タスク用の領域にログを格納する余裕がなくなった場合に、非安全関連系タスク用の領域にも、安全関連系タスクのログを格納可能となる。

また、逆に、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク２９である場合であっても、データＷｒｉｔｅ用タスク３０と同様に、指定されたアドレスが、ＥＥＰＲＯＭ１４の非安全関連系タスク用の領域を指定していないか否かも判定するようにしてもよい。そのようにすることで、安全関連系タスクのログと、非安全関連系タスクのログとで、より高い独立性を保証するようにしてもよい。

データＷｒｉｔｅ用タスクから異常を通知する結果通知データを受信したタスクは、異常の通知に応じた処理を実行する。例えば、マイクロコントローラ２０をリセットすることによって、復旧を試みるようにしてもよい。具体的には、結果通知データを受信したタスクは、パーティションスケジューラ２１に異常を示す結果通知を通知する。そして、パーティションスケジューラ２１は、通知に応じて、上述したように、リセット回路１５への送信信号の送信を停止して、リセット回路１５によってマイクロコントローラ２０をリセットさせるようにする。

また、このときに、マイクロコントローラ２０をリセットする前に、パーティションスケジューラ２１は、制御対象の安全を担保するために、制御対象を停止させるようにしてもよい。具体的には、図５Ａに示す通常制御スケジューリングパターンに従って動作している場合、パーティションスケジューラ２１は、スケジューリングパターンを、図５Ｂに示す安全制御スケジューリングパターンに切り替える。また、パーティションスケジューラ２１は、次の動作タイミングで、ＴＰを強制的にＴＰ３に切り替えるようにしてもよい。そして、ＴＰ３へ切り替えた後は、例えば、安全制御タスク２８によって制御対象を停止させる。また、パーティションスケジューラ２１は、タスクの実行状況が異常である旨の通知を安全制御タスク２８から通知された場合、パーティションスケジューラ２１自身が、制御対象を停止させるように制御するようにしてもよい。

アドレスが許容範囲内であると判定した場合（Ｓ２７：Ｙｅｓ）、データＷｒｉｔｅ用タスクは、ログ格納要求データに含まれるログを、ＥＥＰＲＯＭ１４に格納する（Ｓ２８）。データＷｒｉｔｅ用タスクは、成功を通知する結果通知データを、タスク間通信によって、要求元のタスクに対して送信する（Ｓ２９）。

このとき、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク２９である場合、データＷｒｉｔｅ用タスク２９は、上述したようにポーリングによって、安全関連系タスクがログの格納を要求しているか否かを判定する（Ｓ２１）。一方、ログの格納が要求されたデータＷｒｉｔｅ用タスクが、データＷｒｉｔｅ用タスク３０である場合は、データＷｒｉｔｅ用タスク３０は、上述したように、上述したスリープするシステムコールを呼び出すことによって、待ち状態に遷移する。これによって、ＯＳ１００によって、安全関連系タスクがログの格納を要求しているか否かが判定される（Ｓ２１）。

なお、以上の説明では、ＥＥＰＲＯＭ１４にログを格納する場合について例示したが、安全関連系タスク又は非安全関連系タスクがＥＥＰＲＯＭ１４に格納されたデータを読み出す場合についても、同様にして処理を行うようにしてもよい。この場合、安全関連系タスク及び非安全関連系タスクからは、読み出すログが格納されたアドレスが指定された、ログの読み出しを要求するログ読み出しデータを、タスク間通信によって、データＷｒｉｔｅ用タスク２９、３０に送信することになる。そして、ログ格納要求データに代えて、ログ読み出しデータに対して、上述した処理が行われることになる。また、データＷｒｉｔｅ用タスク２９、３０は、Ｓ２８ではログの格納に代えて、ログ読み出しデータで指定されるアドレスからログを読み出し、読み出したログを結果通知データに含めて、タスク間通信によって、要求元のタスクに対して送信することになる（Ｓ２９）。

続いて、図９を参照して、本実施の形態にかかるログ格納の処理手順の具体例について説明する。図９は、図８を参照して説明した、本実施の形態にかかるログ格納の処理手順による具体的な処理例を示すシーケンス図である。

まず、データＷｒｉｔｅ用タスク２９は、実行状態であり、ミューテックスをロックしており（Ｓ４１）、データＷｒｉｔｅ用タスク３０は、実行可能状態であるものとする。データＷｒｉｔｅ用タスク２９は、ポーリングによって、データキューからのログ格納要求データを受信できるか否かを確認する（Ｓ４２）。

データＷｒｉｔｅ用タスク２９は、ログ格納要求データを受信できなかった場合（Ｓ４３：Ｎｏ）、ミューテックスをアンロックし（Ｓ４４）、ログ格納要求データを待ち合わせるために待ち状態に遷移する（Ｓ４５）。一方、データＷｒｉｔｅ用タスク２９は、ログ格納要求データを受信できた場合（Ｓ４３：Ｙｅｓ）、ＥＥＰＲＯＭ制御処理を実行する（Ｓ４９）。すなわち、ログをＥＥＰＲＯＭ１４に格納する（Ｓ２６〜Ｓ２９）。そして、データＷｒｉｔｅ用タスク２９は、再び、ポーリングによって、データキューからのログ格納要求データを受信できるか否かを確認する（Ｓ４２）。これによって、安全関連系タスクからのログの格納要求がある場合には、それに応じた安全関連系タスクのログの格納を優先的に連続して実行することができる。

データＷｒｉｔｅ用タスク２９が待ち状態に遷移した後（Ｓ４５）、タスクスケジューラ２３は、実行可能状態のデータＷｒｉｔｅ用タスク３０を実行状態に遷移させる。ここで、データＷｒｉｔｅ用タスク３０は、例えば、ログの格納を終了した状態であるものとする。データＷｒｉｔｅ用タスク３０は、ログ格納要求データを待ち合わせるために待ち状態に遷移する（Ｓ４６）。

タスクスケジューラ２３は、安全関連系タスクによって、データＷｒｉｔｅ用タスク２９に対するログ格納要求データがリクエスト用のデータキューに格納されたとき、データＷｒｉｔｅ用タスク２９を実行状態に遷移させる。実行状態に遷移したデータＷｒｉｔｅ用タスク２９は、データキューからログ格納要求データを受信する（Ｓ４７）。データＷｒｉｔｅ用タスク２９は、ミューテックスをロックして（Ｓ４８）、ＥＥＰＲＯＭ制御処理を実行する（Ｓ４９）。そして、データＷｒｉｔｅ用タスク２９は、再び、データキューからのログ格納要求データを受信できるか否かを確認する（Ｓ４２）。

一方、データＷｒｉｔｅ用タスク２９が待ち状態に遷移した後に、データＷｒｉｔｅ用タスク３０に対するログ格納要求データがリクエスト用のデータキューに格納されたとき、タスクスケジューラ２３は、データＷｒｉｔｅ用タスク３０を実行状態に遷移させる。実行状態に遷移したデータＷｒｉｔｅ用タスク３０は、データキューからログ格納要求データを受信する（Ｓ５０）。データＷｒｉｔｅ用タスク３０は、ミューテックスをロックして（Ｓ５１）、ＥＥＰＲＯＭ制御処理を実行する（Ｓ５２）。そして、データＷｒｉｔｅ用タスク２９は、ミューテックスをアンロックして（Ｓ５３）、ログ格納要求データを待ち合わせるために待ち状態に遷移する（Ｓ４６）。

続いて、図１０を参照して、本実施の形態にかかるログ格納の処理手順の具体例について説明する。図１０は、図８を参照して説明した、本実施の形態にかかるログ格納の処理手順による具体的な処理例を示すシーケンス図である。図１０では、図９を参照して説明した処理例とは、異なる例について説明する。

まず、データＷｒｉｔｅ用タスク２９とデータＷｒｉｔｅ用タスク３０のそれぞれは、待ち状態であるものとする。データＷｒｉｔｅ用タスク２９に対するログ格納要求データがリクエスト用のデータキューに格納されたとき、タスクスケジューラ２３は、データＷｒｉｔｅ用タスク２９を実行状態に遷移させる。実行状態に遷移したデータＷｒｉｔｅ用タスク２９は、データキューからログ格納要求データを受信する（Ｓ６１）。データＷｒｉｔｅ用タスク２９は、ミューテックスをロックして、ＥＥＰＲＯＭ制御処理を開始する（Ｓ６３）。

ここで、図１０に示す例では、データＷｒｉｔｅ用タスク２９がシステムコールを呼び出す等のディスパッチの契機となる処理を行って、ディスパッチが発生したものとする。また、このときに、データＷｒｉｔｅ用タスク３０に対するログ格納要求データがリクエスト用のデータキューに格納されているものとする。この場合、タスクスケジューラ２３は、データＷｒｉｔｅ用タスク２９を実行可能状態に遷移させるとともに（Ｓ６４）、データＷｒｉｔｅ用タスク３０を実行状態に遷移させる。

実行状態に遷移したデータＷｒｉｔｅ用タスク３０は、データキューからログ格納要求データを受信する（Ｓ６５）。データＷｒｉｔｅ用タスク３０は、受信したログ格納要求に応じたＥＥＰＲＯＭ制御処理を実施するために、ミューテックスをロックする（Ｓ６６）。しかしながら、すでにデータＷｒｉｔｅ用タスク２９によってミューテックスがロックされているため（Ｓ６２）、データＷｒｉｔｅ用タスク３０は、ロック待ちとなる。そのため、タスクスケジューラ２３は、データＷｒｉｔｅ用タスク３０を待ち状態に遷移させる（Ｓ６７）。

それによって、タスクスケジューラ２３は、再び、実行可能状態となっている、データＷｒｉｔｅ用タスク２９を実行状態に遷移させる（Ｓ６７）。実行可能状態となったデータＷｒｉｔｅ用タスク２９は、先ほど中断されたＥＥＰＲＯＭ制御処理を継続する。そして、データＷｒｉｔｅ用タスク２９は、ＥＥＰＲＯＭ制御処理を終了したとき（Ｓ６８）、ポーリングによって、データキューからログ格納要求データを受信できるか否かを確認する（Ｓ６９）。

データＷｒｉｔｅ用タスク２９は、ログ格納要求データを受信できた場合（Ｓ７０：Ｙｅｓ）、ＥＥＰＲＯＭ制御処理を実行する（Ｓ７１）。これ以降は、図９を参照して説明したＳ４９以降の処理と同様であるため、説明を省略する。

一方、データＷｒｉｔｅ用タスク２９は、ログ格納要求データを受信できなかった場合（Ｓ７０：Ｎｏ）、ミューテックスをアンロックし（Ｓ７２）、ログ格納要求データを待ち合わせるために待ち状態に遷移する（Ｓ７３）。

データＷｒｉｔｅ用タスク２９が待ち状態に遷移した後は（Ｓ４５）、データＷｒｉｔｅ用タスク２９によってミューテックスがアンロックされているため（Ｓ７２）、タスクスケジューラ２３は、待ち状態のデータＷｒｉｔｅ用タスク３０を実行状態に遷移させる。データＷｒｉｔｅ用タスク３０は、ミューテックスをロックして（Ｓ７４）、ＥＥＰＲＯＭ制御処理を実行する（Ｓ７５）。そして、データＷｒｉｔｅ用タスク３０は、ミューテックスをアンロックして（Ｓ７６）、ログ格納要求データを待ち合わせるために待ち状態に遷移する（Ｓ７７）。

上述した説明によれば、データＷｒｉｔｅ用タスク２９が、ＥＥＰＲＯＭ１４にログを格納する前に、ＥＥＰＲＯＭ１４をロックし、ＥＥＰＲＯＭ１４にログを格納した後に、ＥＥＰＲＯＭ１４をアンロックするようにしている。これによれば、安全関連系のログの格納処理中に、データＷｒｉｔｅ用タスク２９からデータＷｒｉｔｅ用タスク３０へのディスパッチが発生したとしても、安全関連系のログの格納を優先することができる。すなわち、安全関連系のログの保存中に、非安全関連系のログの保存要求があったとしても、安全関連系のログを優先して保存することができる。

ここで、各タスク２４、２６、２８からのデータＷｒｉｔｅ用タスク２９、３０に対して保存を要求するログのサイズが、タスク間通信によって１回で送信可能なサイズを超えている場合には、各タスク２４、２６、２８は、ログを分割して、複数のログ格納要求データに分けて送信する。以下、そのときの処理について、図９及び図１０を参照して説明する。

この場合、データＷｒｉｔｅ用タスク３０は、Ｓ５０において、複数のログ格納要求データを受信する。これは、上述したログ格納要求データを受信するシステムコールを連続して呼び出すことによって行う。ここで、ログ格納要求データを受信する回数は、最初のログ格納要求データに、ログを何分割して送信したのかを示す情報を含めておくことによって特定可能とする。そして、データＷｒｉｔｅ用タスク３０は、最後のログ格納要求データを受信したときに、ミューテックスをロックする（Ｓ５１）。そして、受信した複数のログ格納要求データのそれぞれに含まれるログを結合して１つのログとして、ＥＥＰＲＯＭ制御処理（Ｓ５２）を行う。

それに対して、安全関連系タスクのログが分割される場合には、データＷｒｉｔｅ用タスク２９は、最初のログ格納要求データを受信したときに（Ｓ４７）、ミューテックスをロック（Ｓ４８）して、後続するログ格納要求データを受信する。そして、データＷｒｉｔｅ用タスク２９も、受信した複数のログ格納要求データのそれぞれに含まれるログを結合して１つのログとして、ＥＥＰＲＯＭ制御処理（Ｓ４９）を行う。

このようにすることで、データＷｒｉｔｅ用タスク２９が、全てのログ格納要求データを受信するまでに、データＷｒｉｔｅ用タスク３０へのディスパッチが発生してしまった場合であっても、図１０に示すように、データＷｒｉｔｅ用タスク３０は、ミューテックスのロック待ちとなり、再び、データＷｒｉｔｅ用タスク２９に制御が戻ることになる。すなわち、安全関連系のログの保存中に、非安全関連系のログの保存要求があったとしても、安全関連系のログを優先して保存することができる。

また、データＷｒｉｔｅ用タスク３０が、全てのログ格納要求データを受信するまでに、データＷｒｉｔｅ用タスク２９へのディスパッチが発生してしまった場合は、データＷｒｉｔｅ用タスク３０によって、まだミューテックスはロックされていない。そのため、データＷｒｉｔｅ用タスク２９は、ミューテックスをロックして、ログの保存を行うことができる。すなわち、これによれば、非安全関連系のログの保存処理中に、安全関連系のログの保存要求があった場合であっても、安全関連系のログを優先して保存することが可能となる。

なお、上述した説明では、ＥＥＰＲＯＭ１４のロックをかける機構として、ミューテックスを用いた場合について例示したが、これに限られない。ＥＥＰＲＯＭ１４のロックをかける機構として、ミューテックス、セマフォ、又はスピンロック等の任意のロック機構を用いてよい。

以上に説明したように、本実施の形態では、安全関連系のタスクのログを格納したときに、安全関連系のタスクからのデータ格納要求がある場合には、非安全関連系のタスクからのデータ格納要求がある場合であっても、安全関連系のタスクからのデータ格納要求に応じて、ＥＥＰＲＯＭ１４に安全関連系のタスクのログを格納するようにしている。これによれば、優先度の高い安全関連系のタスクのログを優先的にＥＥＰＲＯＭ１４に格納することができる。すなわち、特定のタスクのデータを優先して保存することができる。

ここで、安全関連系のタスクから送信されたデータと非安全関連系のタスクから送信されたデータの両方がデータキューに格納されている場合には、先に送信されたデータが、先に受信されることになる。データキューにおいては、優先度の高い安全関連系のタスクからのデータを先に受信するという待ち合わせの仕方をすることはできない。それに対して、本実施の形態では、データの優先度に応じて別々のデータＷｒｉｔｅ用タスクを用意して、優先度の高いデータを保存するデータＷｒｉｔｅ用タスクを優先的に動作させるようにしている。

これによれば、データキュー（タスク間通信）及びマルチタスクの仕組みを利用して、低コストで、優先度の高い安全関連系のタスクのデータを優先して保存することが可能となる。

＜発明の他の実施の形態＞
本実施の形態では、ＴＰのそれぞれに属するタスクが、それぞれ安全監視タスク２４、通常制御タスク２６、及び安全制御タスク２８である場合について例示したが、タスクの種類は、これに限られない。安全監視タスク２４、通常制御タスク２６及び安全制御タスク２８に限られず、その他の制御対象の制御に関する任意の処理を実行するタスクを有するようにしてもよい。

例えば、図１１に示すようなタスク３１〜３３を有するようにしてもよい。なお、この場合、安全制御装置は、アプリケーション１０１〜１０３に代えて、タスク３１〜３３に対応するアプリケーションを有する必要があるが、その点は自明であるため図示及び説明を省略する。また、図１１では、データＷｒｉｔｅ用タスク２９、３０の図示は省略している。

監視制御タスク３１は、制御対象を制御する。具体的には、監視制御タスク３１は、通常制御タスク３２及び安全制御タスク３３からの指令値に基づいて、制御対象のアクチュエータを制御する。通常制御タスク３２は、制御対象に通常の機能・動作を行わせるための制御計算を行う。具体的には、通常制御タスク３２は、通常制御におけるアクチュエータの制御計算をして、アクチュエータの指令値を算出する。通常制御タスク３２は、算出した指令値を監視制御タスク３１に出力する。安全制御タスク３３は、機能安全を確保するために定められた制御計算を行う。具体的には、安全制御タスク３３は、安全制御におけるアクチュエータの制御計算をして、アクチュエータの指令値を算出する。安全制御タスク３３は、算出した指令値を監視制御タスク３１に出力する。監視制御タスク３１は、通常制御タスク３２又は安全制御タスク３３から出力された指令値に基づいてアクチュエータを制御する。

さらに、監視制御タスク３１は、制御対象のセンサから、センサ値を取得する。監視制御タスク３１は、取得したセンサ値を通常制御タスク３２及び安全制御タスク３３に出力する。通常制御タスク３２及び安全制御タスク３３のそれぞれは、監視制御タスク３１から出力されたセンサ値に基づいて、アクチュエータの制御計算を行うようにしてもよい。なお、各タスク３１〜３３間での指令値及びセンサ値の受け渡しは、タスク間通信で行ってもよく、実行用メモリ１１に設けられた、各タスク３１〜３３で共有してアクセス可能な領域である共有メモリを介して行うようにしてもよい。

図１１の例では、監視制御タスク３１及び安全制御タスク３３は、制御対象の監視や、機能安全を確保するために定められた制御計算等のように、制御対象の機能安全の確保に関する処理を実行するタスクとなる。それに対して、通常制御タスク３２は、その他の制御対象の制御に関する処理を実行するタスクとなる。そのため、監視制御タスク３１及び安全制御タスク３３は、安全関連系タスクとなり、通常制御タスク３２は、非安全関連系タスクとなる。

また、その他に、例えば、図１２に示すようなタスク３４〜３６を有するようにしてもよい。なお、この場合、安全制御装置は、アプリケーション１０１〜１０３に代えて、タスク３４〜３６に対応するアプリケーションを有する必要があるが、その点は自明であるため図示及び説明を省略する。また、図１２では、データＷｒｉｔｅ用タスク２９、３０の図示は省略している。

監視タスク３４は、制御対象のセンサから、センサ値を取得する。このセンサには、上述したように制御対象の姿勢を検知するための姿勢センサを含む。ここで説明する例では、制御対象として、人が搭乗することができる走行装置に適用した場合について説明する。この場合、監視タスク３４、搭乗者による重心移動を姿勢センサにより検知することができる。監視タスク３４は、取得したセンサ値をＨＭＩ（Human Machine Interface）タスク３６に出力する。

ＨＭＩタスク３６は、監視タスク３４から出力されたセンサ値に基づいて、制御対象のアクチュエータの制御計算をして、アクチュエータの指令値を算出する。ＨＭＩタスク３６は、算出した指令値を制御タスク３５に出力する。制御タスク３５は、ＨＭＩタスク３６から出力された指令値に基づいて、アクチュエータを制御する。なお、各タスク３４〜３６間での指令値及びセンサ値の受け渡しは、タスク間通信で行ってもよく、実行用メモリ１１に設けられた、各タスク３４〜３６で共有してアクセス可能な領域である共有メモリを介して行うようにしてもよい。

図１２の例では、監視タスク３４、ＨＭＩタスク３６及び制御タスク３５によって、制御対象の監視、それに応じた制御計算、制御計算結果に基づいた制御対象の制御を行うことで、状況によっては制御対象の機能安全の確保に関する処理を実行する。そのため、監視タスク３４、ＨＭＩタスク３６及び制御タスク３５のそれぞれは、安全関連系タスクとなる。この場合には、ＴＰ１〜ＴＰ３以外のＴＰ（図示せず）に属する、その他の制御対象の制御に関する処理を実行するタスクが、非安全関連系タスクとなる。

ここで、図１２において説明した構成によれば、搭乗者の操作に応じて制御対象が制御されるというＨＭＩを実現することができる。例えば、搭乗者が重心を前後に移動させることで制御対象が前後後退を行い、搭乗者が重心を左右に移動させることで制御対象が左右旋回を行うといった制御が可能となる。これについては、実施の形態及び図１１によって説明した例についても同様のことが言える。具体的には、安全監視タスク２４又は監視制御タスク３１が取得したセンサ値に応じて、通常制御タスク２６及び安全制御タスク２８、もしくは、通常制御タスク３２及び安全制御タスク３３が同様の制御をすることで、ＨＭＩを実現することが可能である。

なお、走行装置として、例えば、立ち乗り方の同軸二輪車とすることもできる。その場合は、アクチュエータを制御することで、車輪が回転動作をすることになる。また、安全制御装置自体も制御対象に搭載される構成としてもよい。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

本実施の形態では、ＯＳが、ＴＰ１〜ＴＰ３を有する場合について例示したが、ＴＰの種類及び数は、これに限られない。スケジューリングパターンについても、本実施の形態に例示したものに限られない。

本実施の形態では、タスクの数が５つである場合について例示したが、タスクの数は、これに限られない。例えば、本実施の形態では、ＴＰがＴＰ１〜ＴＰ３の３つである場合について例示したが、ＴＰの数を３つ以外の数とし、それぞれのＴＰが任意の数のタスクを有するようにしてもよい。

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

本実施の形態では、ログを格納する非安全関連系のタスクと、そのログよりも格納する優先度の高いログを格納する安全関連系のタスクとを実行する場合について例示したが、これに限られない。データを格納するタスクと、そのデータよりも優先度の高いデータを格納するタスクとを実行する情報処理装置であれば、同様にして適用することが可能である。すなわち、本実施の形態において対象となるデータは、ログに限られない。また、異なる優先度のデータを格納するタスク同士であれば、その分類は、安全関連系と非安全関連系とに限られることはない。

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

Claims (10)

1. 第１のデータと、前記第１のデータよりも格納する優先度の高い第２のデータとが格納される記憶部と、
   前記記憶部に前記第１のデータを格納する第１のタスクと、前記記憶部に前記第２のデータを格納する第２のタスクとをスケジューリングして実行するタスク実行部と、
   前記第１のタスクからのデータ格納要求に応じて、前記第１のタスクに代わって前記記憶部に前記第１のデータを格納するとともに、前記第２のタスクからのデータ格納要求に応じて、前記第２のタスクに代わって前記記憶部に前記第２のデータを格納するデータ格納制御部と、を備え、
   前記データ格納制御部は、前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がある場合には、前記第１のタスクからのデータ格納要求がある場合であっても、前記第２のタスクからのデータ格納要求に応じて、前記記憶部に前記第２のデータを格納する、
   情報処理装置。
2. 前記タスク実行部は、さらに、前記第１のタスクに代わって前記記憶部に前記第１のデータを格納する第１のデータ書き込みタスクと、前記第２のタスクからのデータ格納要求に応じて、前記第２のタスクに代わって前記記憶部に前記第２のデータを格納する第２のデータ書き込みタスクとをスケジューリングして実行することで、前記データ格納制御部として機能し、
   前記第１のデータ書き込みタスクは、前記記憶部に前記第１のデータを格納したときに、前記第１のタスクからのデータ格納要求があるか否かに関わらず、待ち状態に遷移し、
   前記第２のデータ書き込みタスクは、前記記憶部に前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がある場合には、待ち状態に遷移せずに、当該データ格納要求に応じて、前記記憶部に前記第２のデータを格納する、
   請求項１に記載の情報処理装置。
3. 前記データ格納要求は、メッセージキューを介して送信され、
   前記第２のデータ書き込みタスクは、前記記憶部に前記第２のデータを格納したときに、前記メッセージキューから前記第２のタスクからのデータ格納要求を受信可能な場合に、待ち状態に遷移せずに、当該データ格納要求に応じて、前記記憶部に前記第２のデータを格納する、
   請求項２に記載の情報処理装置。
4. 前記第２のデータ書き込みタスクは、前記第１のデータ書き込みタスクよりも優先度が高い、
   請求項２又は３に記載の情報処理装置。
5. 前記第１のデータ書き込みタスクは、前記記憶部に前記第１のデータを格納する前に前記記憶部をロックし、前記第１のデータを格納したときに、前記第１のタスクからのデータ格納要求があるか否かに関わらず、前記記憶部をアンロックし、
   前記第２のデータ書き込みタスクは、前記記憶部に前記第２のデータを格納する前に前記記憶部をロックし、前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がない場合に、前記記憶部をアンロックする、
   請求項２乃至４のいずれか１項に記載の情報処理装置。
6. 前記データ格納要求は、前記第１のタスク又は前記第２のタスクが、前記第１のデータ書き込みタスク又は前記第２のデータ書き込みタスクに対して、その格納を要求する第１のデータ又は第２のデータが含まれ、
   前記第１のタスク及び前記第２のタスクのそれぞれは、１つの前記データ格納要求に前記第１のデータ又は前記第２のデータを含めることができない場合は、当該第１のデータ又は当該第２のデータを複数の前記データ格納要求に分けて送信し、
   前記第１のデータ書き込みタスクは、前記複数のデータ格納要求のうち、最後のデータ格納要求を受信したときに、記記憶部をロックし、
   前記第２のデータ書き込みタスクは、前記複数のデータ格納要求のうち、最初のデータ格納要求を受信したときに、記記憶部をロックする、
   請求項５に記載の情報処理装置。
7. 前記タスク実行部は、前記第１のタスク、前記第２のタスク、前記第１のデータ書き込みタスク、及び、前記第２のデータ書き込みタスクがいずれかに含まれる複数のタイムパーティションのスケジューリング内容を示すスケジューリング情報に従って、前記第１のタスク、前記第２のタスク、前記第１のデータ書き込みタスク、及び、前記第２のデータ書き込みタスクをスケジューリングして実行し、
   前記第１のデータ書き込みタスク及び前記第２のデータ書き込みタスクは、少なくとも同一のタイムパーティションに含まれる、
   請求項２乃至６のいずれか１項に記載の情報処理装置。
8. 前記記憶部は、前記第１のデータが格納される領域と、前記第２のデータが格納される領域と、を含み、
   前記データ格納要求は、前記記憶部において、前記第１のデータ又は前記第２のデータを格納するアドレスを示す情報が含まれ、
   前記データ格納制御部は、前記第１のタスクからのデータ格納要求で示されるアドレスが、前記第２のデータが格納される領域に含まれる場合には、当該第１のタスクからのデータ格納要求に応じた前記第１のデータの格納を抑止する、
   請求項１乃至７のいずれか１項に記載の情報処理装置。
9. 前記情報処理装置は、制御対象を制御する制御装置であって、
   前記第２のタスクは、前記情報処理装置において検出した異常に関するログを前記第２のデータとして格納し、
   前記第１のタスクは、その他の前記制御対象の制御に関する処理を実行するとともに、当該処理に関するログを前記第１のデータとして格納する、
   請求項１乃至８のいずれか１項に記載の情報処理装置。
10. 第１のデータと、前記第１のデータよりも格納する優先度の高い第２のデータとが格納される記憶部に前記第１のデータを格納する第１のタスクと、前記記憶部に前記第２のデータを格納する第２のタスクとをスケジューリングして実行開始する実行開始ステップと、
    前記第１のタスクからのデータ格納要求に応じて、前記第１のタスクに代わって前記記憶部に前記第１のデータを格納する第１のデータ格納ステップと、
    前記第２のタスクからのデータ格納要求に応じて、前記第２のタスクに代わって前記記憶部に前記第２のデータを格納する第２のデータ格納ステップと、を備え、
    前記第２のデータ格納ステップでは、前記第２のデータを格納したときに、前記第２のタスクからのデータ格納要求がある場合には、前記第１のタスクからのデータ格納要求がある場合であっても、前記第２のタスクからのデータ格納要求に応じて、前記記憶部に前記第２のデータを格納する、
    データ格納方法。

Images