JP5811865B2 - 制御装置及びプログラム実行方法 - 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）、フラッシュメモリ、ハードディスクドライブ若しくは光ディスクドライブ、又はこれらの組み合わせである。不揮発性メモリ１３は、ＯＳ１００、アプリケーション１０１〜１０３、バージョン情報１１１、１１２、１１３、ＣＲＣ１２１、１２３、有効範囲情報１３１、１３３、パラメータ情報１４２、１４３、２１１、及び、バージョン情報２２１、２２３を格納する。なお、不揮発性メモリ１３の少なくとも一部は安全制御装置１から取り外し可能に構成されてもよい。例えば、アプリケーション１０１〜１０３が格納されたメモリを取り外し可能としてもよい。また、不揮発性メモリ１３の少なくとも一部は、安全制御装置１の外部に配置されてもよい。

なお、ＯＳ１００は、図８で後述する機能安全ＯＳバイナリ２０４に含まれることになる。安全監視アプリケーション１０１、安全制御アプリケーション１０３、バージョン情報１１１、１１３、ＣＲＣ１２１、１２３、有効範囲情報１３１、１３３、及び、パラメータ情報１４３は、図８で後述する安全関連バイナリ２０２に含まれることになる。通常制御アプリケーション１０２、バージョン情報１１２、及び、パラメータ情報１４２は、図８で後述する非安全関連バイナリ２０１に含まれることになる。パラメータ情報２１１及びバージョン情報２２１、２２３は、図８で後述する安全関連設定バイナリ２０３に含まれることになる。

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

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

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

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

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

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

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

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

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

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

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

以上に説明したように、通常制御アプリケーション１０２は、非安全関連アプリケーションとなる。そのため、通常制御アプリケーション１０２が属するＴＰは、ユーザーが自由に設計・設定可能なＴＰとなる。また、安全監視アプリケーション１０１及び安全制御アプリケーション１０３のそれぞれは、安全関連アプリケーションとなる。そのため、安全監視アプリケーション１０１及び安全制御アプリケーション１０３のそれぞれが属するＴＰは、ユーザーが設計不能なＴＰとなる。

ここで、安全関連ＴＰのそれぞれを、ユーザーが設計不能であっても、ユーザーが設定のみ可能なＴＰとするか否かは、ベンダーによって任意に予め定めるようにしてよい。本実施の形態では、例として、安全監視アプリケーション１０１が属するＴＰが、ユーザーが設定のみ可能なＴＰである場合について説明する。すなわち、本実施の形態では、通常制御アプリケーション１０２が属するＴＰが、ユーザーが自由に設計・設定可能なＴＰであり、安全監視アプリケーション１０１が属するＴＰが、ユーザーが設定のみ可能なＴＰであり、安全制御アプリケーション１０３が属するＴＰが、ユーザーが設計・設定不能なＴＰである場合について説明する。

なお、ユーザーが設定するパラメータとして、通常制御アプリケーション１０２及び安全制御アプリケーション１０３が使用するパラメータでは、例えば、制御対象の走行速度又は歩行速度の限界値等が挙げられる。また、安全監視アプリケーション１０１では、例えば、異常を検出するための閾値（例えば、障害物までの距離等）、及び、異常の監視時間等が挙げられる。

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

バージョン情報１１１は、安全監視アプリケーション１０１のバージョンを示す情報である。バージョン情報１１１は、安全監視アプリケーション１０１を作成したベンダーによって予め作成される。

バージョン情報１１２は、通常制御アプリケーション１０２のバージョンを示す情報である。バージョン情報１１２は、通常制御アプリケーション１０２を作成したユーザーによって作成される。

バージョン情報１１３は、安全制御アプリケーション１０３のバージョンを示す情報である。バージョン情報１１３は、安全制御アプリケーション１０３を作成したベンダーによって予め作成される。

ＣＲＣ（Cyclic Redundancy Check）１２１は、安全監視アプリケーション１０１から生成されたＣＲＣ符号である。ＣＲＣ１２１は、安全監視アプリケーション１０１を作成したベンダーによって予め作成される。すなわち、ＣＲＣ１２１は、安全監視アプリケーション１０１から生成するＣＲＣの期待値となる。

ＣＲＣ１２３は、安全制御アプリケーション１０３から生成されたＣＲＣ符号である。ＣＲＣ１２３は、安全制御アプリケーション１０３を作成したベンダーによって予め作成される。すなわち、ＣＲＣ１２３は、安全制御アプリケーション１０３から生成するＣＲＣの期待値となる。

有効範囲情報１３１は、安全監視アプリケーション１０１で使用するパラメータの有効範囲を示す情報である。有効範囲情報１３１は、安全監視アプリケーション１０１を作成したベンダーによって予め作成される。すなわち、有効範囲情報１３１は、後述するパラメータ情報２１１が示すパラメータの有効な範囲を示す情報である。

有効範囲情報１３３は、安全制御アプリケーション１０３が使用するパラメータの有効範囲を示す情報である。有効範囲情報１３３は、安全制御アプリケーション１０３を作成したベンダーによって予め作成される。すなわち、有効範囲情報１３３は、後述するパラメータ情報１４３が示すパラメータの有効な範囲を示す情報である。

パラメータ情報１４２は、通常制御アプリケーション１０２が使用するパラメータを示す情報である。パラメータ情報１４２は、通常制御アプリケーション１０２を作成したユーザーによって、そのパラメータが設定される。

パラメータ情報１４３は、安全制御アプリケーション１０３が使用するパラメータを示す情報である。パラメータ情報２１１は、安全制御アプリケーション１０３を作成したベンダーによって、そのパラメータが予め設定される。

パラメータ情報２１１は、安全監視アプリケーション１０１が使用するパラメータを示す情報である。パラメータ情報２１１は、通常制御アプリケーション１０２を作成したユーザーによって、そのパラメータが設定される。

バージョン情報２２１は、安全監視アプリケーション１０１のバージョンを示す情報である。バージョン情報２２１は、通常制御アプリケーション１０２を作成したユーザーによって、通常制御アプリケーション１０２と共に動作することが期待される安全監視アプリケーション１０１のバージョンが設定される。

バージョン情報２２３は、安全制御アプリケーション１０３のバージョンを示す情報である。バージョン情報２２３は、通常制御アプリケーション１０２を作成したユーザーによって、通常制御アプリケーション１０２と共に動作することが期待される安全制御アプリケーション１０３のバージョンが設定される。

通常制御アプリケーション１０２、バージョン情報１１２、２２１、２２３、及び、パラメータ情報１４２、２１１が、ユーザーによって、どのように作成されるかについては、後述する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

また、パーティションスケジューラ２１は、動作保証チェックルーチン２９を有している。動作保証チェックルーチン２９は、安全関連アプリケーション１０１、１０３の起動によって生成される安全関連のタスク２４、２８が正常に動作することができるか否かをチェックする。そして、動作保証チェックルーチン２９は、正常に動作をすることができないと判定した場合には、安全制御装置１の起動を抑止する。すなわち、安全関連のタスク２４、２８が正常に動作することができる場合のみ、安全制御装置１を起動して、各タスク２４、２６、２８の実行を開始することで、安全制御装置１の動作を保証する。

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

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

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

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

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

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

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

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

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

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

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

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

続いて、図７を参照して、本実施の形態にかかる動作保証チェックルーチン２９の処理手順について説明する。図７は、本実施の形態にかかる動作保証チェックルーチン２９の処理手順の具体例を示すフローチャートである。

パーティションスケジューラ２１は、安全制御装置１の起動時にＯＳ１００によって起動された場合、動作保証チェックルーチン２９を実行する。図７に示す動作保証チェックルーチン２９では、まず、ユーザーによる設計・設定不能なＴＰ（本実施形態では、安全制御タスク２８が属するＴＰ３）に対してチェックを行い（Ｓ２１〜２３）、次に、ユーザーによる設定のみ可能なＴＰ（本実施形態では、安全監視タスク２４が属するＴＰ１）に対してチェックを行う（Ｓ２５〜２７）場合について例示する。なお、ユーザーによる設定のみ可能なＴＰに対してチェックを行った後に、ユーザーによる設計・設定不能なＴＰに対してチェックを行うようにしてもよい。

動作保証チェックルーチン２９は、ＴＰ３のバイナリが想定するバイナリであるか否かを判定する（Ｓ２１）。すなわち、ＴＰ３に属する安全制御アプリケーション１０３に変更が加えられていないか判定する。具体的は、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納された安全制御アプリケーション１０３からＣＲＣを算出する。動作保証チェックルーチン２９は、算出したＣＲＣと、不揮発性メモリ１３に格納されたＣＲＣ１２３とが一致するか否かを判定する。そして、ＣＲＣが一致する場合には、ＴＰ３のバイナリが想定するバイナリであると判定し、ＣＲＣが一致しない場合には、ＴＰ３のバイナリが想定するバイナリでないと判定する。これによれば、安全制御アプリケーション１０３の内容が意図せず変更されていた場合に、それを検出することができる。

ここで、プログラムが変更されていないかどうかを検証するにあたり、ＣＲＣ以外の誤り検出符号を使用するようにしてもよい。誤り検出符号として、例えば、ＣＲＣ、パリティ、チェックサム、又は、ハッシュ関数等を使用することができる。

ＴＰ３のバイナリが想定するバイナリであると判定した場合、Ｓ２２に進み、ＴＰ３のバイナリが想定するバイナリでないと判定した場合、Ｓ２４に進む。

Ｓ２２では、動作保証チェックルーチン２９は、ＴＰ３のソフトウェアのバージョンが想定するバージョンであるか否かを判定する（Ｓ２２）。すなわち、ＴＰ３に属する安全制御アプリケーション１０３のバージョンが期待したバージョンであるか否かを判定する。具体的には、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納されたバージョン情報１１３が示すバージョンと、不揮発性メモリ１３に格納されたバージョン情報２２１が示すバージョンとが一致するか否かを判定する。そして、バージョンが一致する場合には、ＴＰ３のソフトウェアのバージョンが想定するバージョンであると判定し、バージョンが一致しない場合には、ＴＰ３のソフトウェアのバージョンが想定するバージョンでないと判定する。これによれば、安全制御アプリケーション１０３が意図しないバージョンである場合に、それを検出することができる。

ＴＰ３のソフトウェアのバージョンが想定するバージョンであると判定した場合、Ｓ２３に進み、ＴＰ３のソフトウェアのバージョンが想定するバージョンでないと判定した場合、Ｓ２４に進む。

Ｓ２３では、ＴＰ３のパラメータが有効範囲内の値で設定されているか否かを判定する（Ｓ２３）。すなわち、ＴＰ３に属する安全制御アプリケーション１０３に対して設定されたパラメータが有効な範囲内の値であるか否かを判定する。具体的には、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納されたパラメータ情報１４３が示すパラメータが、不揮発性メモリ１３に格納された有効範囲情報１３３が示す有効範囲内の値であるか否かを判定する。そして、パラメータが有効範囲内の値である場合、ＴＰ３のパラメータが有効範囲内の値で設定されていると判定し、パラメータが有効範囲内の値でない場合、ＴＰ３のパラメータが有効範囲内の値で設定されていないと判定する。これによれば、安全制御アプリケーション１０３が使用するパラメータが不正な値となっている場合に、それを検出することができる。

ここで、ＴＰ３は、ユーザーが設定不能なＴＰであるが、これによれば、ベンダーによって予め作成されたパラメータ情報１４３が、ユーザーによって実行バイナリを生成する過程で意図せず改変されてしまった場合に、それを検出することができる。

ＴＰ３のパラメータが有効範囲内の値で設定されていると判定した場合、Ｓ２５に進み、ＴＰ３のパラメータが有効範囲内の値で設定されていないと判定した場合、Ｓ２４に進む。

Ｓ２４に進んだ場合は、ユーザーによる設計・設定不能なＴＰ３で異常が検出されたことになる（Ｓ２４）。この場合は、パーティションスケジューラ２１は、安全制御装置１の起動を抑止する。具体的には、タスクスケジューラ２３、２５、２７を動作させて、各タスク２４、２６、２８を動作させることは行わず、ＯＳ１００をシャットダウンする。

Ｓ２５では、動作保証チェックルーチン２９は、ＴＰ１のバイナリが想定するバイナリであるか否かを判定する（Ｓ２５）。すなわち、ＴＰ１に属する安全監視アプリケーション１０１に変更が加えられていないか判定する。具体的は、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納された安全監視アプリケーション１０１からＣＲＣを算出する。動作保証チェックルーチン２９は、算出したＣＲＣと、不揮発性メモリ１３に格納されたＣＲＣ１２１とが一致するか否かを判定する。そして、ＣＲＣが一致する場合には、ＴＰ１のバイナリが想定するバイナリであると判定し、ＣＲＣが一致しない場合には、ＴＰ１のバイナリが想定するバイナリでないと判定する。これによれば、安全監視アプリケーション１０１の内容が意図せず変更されている場合に、それを検出することができる。

ＴＰ１のバイナリが想定するバイナリであると判定した場合、Ｓ２６に進み、ＴＰ３のバイナリが想定するバイナリでないと判定した場合、Ｓ２８に進む。

Ｓ２６では、動作保証チェックルーチン２９は、ＴＰ１のソフトウェアのバージョンが想定するバージョンであるか否かを判定する（Ｓ２６）。すなわち、ＴＰ１に属する安全監視アプリケーション１０１のバージョンが期待したバージョンであるか否かを判定する。具体的には、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納されたバージョン情報１１１が示すバージョンと、不揮発性メモリ１３に格納されたバージョン情報２２３が示すバージョンとが一致するか否かを判定する。そして、バージョンが一致する場合には、ＴＰ１のソフトウェアのバージョンが想定するバージョンであると判定し、バージョンが一致しない場合には、ＴＰ１のソフトウェアのバージョンが想定するバージョンでないと判定する。これによれば、安全監視アプリケーション１０１が意図しないバージョンである場合に、それを検出することができる。

ＴＰ１のソフトウェアのバージョンが想定するバージョンであると判定した場合、Ｓ２７に進み、ＴＰ１のソフトウェアのバージョンが想定するバージョンでないと判定した場合、Ｓ２８に進む。

Ｓ２７では、ＴＰ１のパラメータが有効範囲内の値で設定されているか否かを判定する（Ｓ２７）。すなわち、ＴＰ１に属する安全監視アプリケーション１０１に対して設定されたパラメータが有効な範囲内の値であるか否かを判定する。具体的には、動作保証チェックルーチン２９は、不揮発性メモリ１３に格納されたパラメータ情報２１１が示すパラメータが、不揮発性メモリ１３に格納された有効範囲情報１３１が示す有効範囲内の値であるか否かを判定する。そして、パラメータが有効範囲内の値である場合、ＴＰ１のパラメータが有効範囲内の値で設定されていると判定し、パラメータが有効範囲内の値でない場合、ＴＰ１のパラメータが有効範囲内の値で設定されていないと判定する。これによれば、安全監視アプリケーション１０１が使用するパラメータが不正な値となっている場合に、それを検出することができる。

ＴＰ１のパラメータが有効範囲内の値で設定されていると判定した場合、Ｓ２９に進み、ＴＰ１のパラメータが有効範囲内の値で設定されていないと判定した場合、Ｓ２８に進む。

Ｓ２８に進んだ場合、ユーザーによる設定のみ可能なＴＰ１で異常が検出されたことになる（Ｓ２８）。この場合は、Ｓ２４と同様に、パーティションスケジューラ２１は、安全制御装置１の起動を抑止する。

Ｓ２９に進んだ場合、ユーザーが設計・設定不能なＴＰ３と、ユーザーが設定のみ可能なＴＰ１は、正常である。そのため、パーティションスケジューラ２１は、安全制御装置１の起動を継続する。具体的には、パーティションスケジューラ２１は、図６を参照して説明したように、タスクスケジューラ２３、２５、２７を動作させて、各タスク２４、２６、２８を動作させる。

続いて、図８を参照して、本実施の形態にかかるソフトウェア生成装置２及びソフトウェア書込装置３のソフトウェア構成について説明する。図８は、本実施の形態にかかるソフトウェア生成装置２及びソフトウェア書込装置３のソフトウェア構成例を示すブロック図である。

ソフトウェア生成装置２は、コンフィグレータ５０、５２、コンパイラ５１、５３、リンカ５４、バイナリ変換ツール５５を有する。ソフトウェア書込装置３は、ソフトウェア書き込みツール６０を有する。

ソフトウェア生成装置２は、安全制御装置１においてプロセッサ１０によって実行される実行バイナリ２０６を生成する装置である。実行バイナリ２０６には、非安全関連バイナリ２０１、安全関連バイナリ２０２、安全関連設定バイナリ２０３、機能安全対応ＯＳバイナリ２０４が含まれる。すなわち、実行バイナリ２０６には、ＯＳ１００、安全管理アプリケーション１０１、通常制御アプリケーション１０２、安全制御アプリケーション１０３、バージョン情報１１１、１１２、１１３、ＣＲＣ１２１、１２３、有効範囲情報１３１、１３３、パラメータ情報１４２、１４３、２１１、及び、バージョン情報２２１、２２３が含まれる。ソフトウェア書込装置３は、ソフトウェア生成装置２が生成した実行バイナリ２２０を安全制御装置１に書き込む装置である。

コンフィグレータ５０は、ユーザーによって入力された非安全関連ＴＰの設定情報に基づいて、その設定情報を示すソースコード３０１を生成する。この設定情報として、非安全関連のＴＰ２に属する通常制御アプリケーション１０２のバージョンと、通常制御アプリケーション１０２が使用するパラメータとが入力される。

コンパイラ５１は、ソースコード３００、３０１をコンパイルして、非安全関連バイナリ２０１を生成する。ここで、ソースコード３００は、ユーザーによってコーディングされた通常制御アプリケーション１０２のソースコードである。非安全関連バイナリ２０１は、通常制御アプリケーション１０２及び非安全関連ＴＰ２の設定情報のオブジェクトコードである。よって、非安全関連バイナリ２０１には、通常制御アプリケーション１０２、ユーザーによって入力されたバージョンを示すバージョン情報１１２、及び、ユーザーによって入力されたパラメータを示すパラメータ情報１４２を含む。コンパイラ５１は、ソースコード３００が機能安全対応ＯＳ１００のＡＰＩライブラリを使用している場合には、機能安全対応ＯＳ ＡＰＩライブラリ２００を参照して、ソースコード３００をコンパイルする。

コンフィグレータ５２は、ユーザーによって入力された安全関連ＴＰの設定情報に基づいて、その設定情報を示すソースコード３０２を生成する。この設定情報として、安全関連のＴＰ１に属する安全監視アプリケーション１０１のバージョンと、安全監視アプリケーション１０１が使用するパラメータと、安全関連のＴＰ３に属する安全制御アプリケーション１０３のバージョンとが入力される。

コンパイラ５３は、ソースコード３０２をコンパイルして、安全関連設定バイナリ２０３を生成する。すなわち、安全関連設定バイナリ２０３は、安全関連ＴＰ１、ＴＰ３の設定情報のオブジェクトコードである。よって、安全関連設定バイナリ２０３には、ユーザーによって入力されたパラメータを示すパラメータ情報２１１と、ユーザーによって入力されたバージョンを示すバージョン情報２２１、２２３とが含まれる。

リンカ５４は、非安全関連バイナリ２０１、安全関連バイナリ２０２、安全関連設定バイナリ２０３、及び、機能安全対応ＯＳバイナリ２０４をリンクして、実行バイナリ２０５を生成する。ここで、安全関連バイナリ２０２は、安全関連ＴＰ１、ＴＰ３に属する安全監視アプリケーション１０１及び安全制御アプリケーション１０３のオブジェクトコードである。また、安全関連バイナリ２０２には、バージョン情報１１１、１１３、ＣＲＣ１２１、１２３、有効範囲情報１３１、１３３、及び、パラメータ情報１４３が含められている。機能安全対応ＯＳバイナリ２０４は、ＯＳ１００のオブジェクトコードである。機能安全対応ＯＳ ＡＰＩライブラリ２００、安全関連バイナリ２０２、及び、機能安全対応ＯＳバイナリ２０４は、ベンダーによって予め用意されたものとなる。

これによって、ＯＳ１００、各アプリケーション１０１〜１０３、及び、各種情報１１１、１１２、１１３、１２１、１２３、１３１、１３３、１４２、１４３、２１１、２２１、２２３を含む実行バイナリ２０５が生成されることになる。

バイナリ変換ツール５５は、実行バイナリ２０５をバイナリ変換して、実行バイナリ２０６を生成する。具体的には、実行バイナリ２０５の命令コードを、安全制御装置１のプロセッサ１０で実行可能な形式の命令コードに変換する。

ソフトウェア書込装置３のソフトウェア書き込みツール６０は、ソフトウェア生成装置２によって生成された実行バイナリ２０６を安全制御装置１の不揮発性メモリ１３に書き込む。

続いて、図９を参照して、本実施の形態にかかるソフトウェア生成及び書き込み処理について説明する。図９は、本実施の形態にかかるソフトウェア生成及び書き込み処理を示すフローチャートである。

非安全関連系のコンフィグレータ５０は、ユーザーによって入力された非安全関連ＴＰ２の設定情報の内容が定義された記述を含むソースコード３０１を生成する（Ｓ３１）。非安全関連系のコンパイラ５１は、ソースコード３００、３０１をコンパイルして非安全関連バイナリ２０１を生成する（Ｓ３２）。

一方、安全関連系のコンフィグレータ５２は、ユーザーによって入力された安全関連ＴＰ１、ＴＰ３の設定情報の内容が定義された記述を含むソースコード３０２を生成する（Ｓ３３）。安全関連系のコンパイラ５３は、ソースコード３０２をコンパイルして安全関連設定バイナリ２０４を生成する（Ｓ３４）。

リンカ５４は、非安全関連バイナリ２０１、安全関連バイナリ２０３、安全関連設定バイナリ２０４、及び、機能安全対応ＯＳバイナリ２０５をリンクして、実行バイナリ２０６を生成する（Ｓ３５）。バイナリ変換ツール５５は、実行バイナリ２０６をバイナリ変換して実行バイナリ２０６を生成する（Ｓ３６）。ソフトウェア書き込みツール６０は、実行バイナリ２０６を安全制御装置１に書き込む（Ｓ３７）。

続いて、図１０を参照して、本実施の形態にかかるソフトウェア生成装置２及びソフトウェア書込装置３のハードウェア構成例について説明する。図１０は、本実施の形態にかかるソフトウェア生成装置２及びソフトウェア書込装置３のハードウェア構成例を示すブロック図である。なお、図１０を参照して説明するハードウェア構成は、一例であって、上述したソフトウェア生成装置２及びソフトウェア書込装置３の動作を実行可能であれば、この構成に限定されるものではない。

図１０に示すハードウェア構成は、プロセッサ７０、メモリ７１、Ｉ／Ｏポート７２、入力装置７３、光ディスクドライブ７４、及び、不揮発性メモリ７５を有する。

プロセッサ７０は、プログラム（命令ストリーム）の取得、命令のデコード、命令のデコード結果に応じた演算処理を行う。なお、プロセッサ１０と同様に、プロセッサ７０は、マルチプロセッサ構成としてもよく、マルチコアプロセッサであってもよい。メモリ７１は、プロセッサ７０によるプログラム実行のために使用されるメモリである。具体的には、メモリ７１は、ＳＲＡＭ、ＤＲＡＭ等のランダムアクセス可能な揮発性メモリとすればよい。メモリ７１は、図１の実行用メモリ１１と同様に、論理的な構成単位を示している。

Ｉ／Ｏポート７２は、外部デバイスとの間のデータ送受信に使用される。Ｉ／Ｏポート７２は、シリアルポート又はＵＳＢ（Universal Serial Bus）ポート等である。入力装置７３は、ユーザーからの入力を受け付ける。入力装置７３は、例えば、マウス、キーボード、及びタッチパネル等である。

光ディスクドライブ７４は、光ディスク８０に対するデータの書き込み、及び、光ディスク８０からのデータの読み込みを行う。光ディスクは、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、及び、ＤＶＤ−ＲＯＭ（Digital Versatile Disc Read Only Memory）等である。不揮発性メモリ７５は、電力の供給を受けることなく、メモリ７１に比べて安定的に記憶内容を維持することが可能なメモリデバイスである。例えば、不揮発性メモリ７５は、ＲＯＭ、フラッシュメモリ、ハードディスクドライブ若しくは光ディスクドライブ、又はこれらの組み合わせである。

ソフトウェア生成装置２が、図１０に示すようなハードウェア構成である場合、次に説明するように動作することで、上述したソフトウェア生成処理を実行する。不揮発性メモリ７５は、コンフィグレータ５０、５２、コンパイラ５１、５３、リンカ５４、及び、バイナリ変換ツール５５が格納される。プロセッサ７０は、それらのプログラム５０〜５５をメモリ７１にロードして実行する。プロセッサ７０は、コンフィグレータ５０を実行することによって、ユーザーから入力装置７３に対して入力された設定情報に基づいて、ソースプログラム３０１を生成して不揮発性メモリ７５に格納する。

また、不揮発性メモリ７５は、機能安全対応ＯＳ ＡＰＩライブラリ２００、非安全関連バイナリ２０１、及びソースコード３００も格納される。プロセッサ７０は、コンパイラ５１を実行することによって、不揮発性メモリ７５に格納されたソースコード３００、３０１から、非安全関連バイナリ２０１を生成して不揮発性メモリ７５に格納する。

また、プロセッサ７０は、コンフィグレータ５２を実行することによって、ユーザーから入力装置７３に対して入力された設定情報に基づいて、ソースコード３０２を生成して不揮発性メモリ７５に格納する。プロセッサ７０は、コンパイラ５３を実行することによって、不揮発性メモリ７５に格納されたソースコード３０２から、安全関連設定バイナリ２０３を生成して不揮発性メモリ７５に格納する。また、不揮発性メモリ７５は、安全関連バイナリ２０２、及び機能安全対応ＯＳバイナリ２０４も格納される。

プロセッサ７０は、リンカ５４を実行することによって、不揮発性メモリ７５に格納された非安全関連バイナリ２０１、安全関連バイナリ２０２、安全関連設定バイナリ２０３及び機能安全対応ＯＳバイナリ２０４から、実行バイナリ２０５を生成して不揮発性メモリ７５に格納する。プロセッサ７０は、バイナリ変換ツール５５を実行することによって、不揮発性メモリ７５に格納された実行バイナリ２０５から、実行バイナリ２０６を生成して不揮発性メモリ７５に格納する。プロセッサ７０は、光ディスクドライブ７４を制御して、不揮発性メモリ７５に格納された実行バイナリ２０６を光ディスク８０に記録する。

ソフトウェア書込装置３が、図１０に示すようなハードウェア構成である場合、次に説明するように動作することで、上述したソフトウェア書き込み処理を実行する。不揮発性メモリ７５は、ソフトウェア書き込みツール６０が格納される。プロセッサ７０は、ソフトウェア書き込みツール６０をメモリ７１にロードして実行する。光ディスクドライブ７４には、実行バイナリ２０６が記録された光ディスク８０が挿入される。プロセッサ７０は、光ディスクドライブ７４を制御して、光ディスク８０に記録された実行バイナリ２０６を読み出して、不揮発性メモリ７５に格納する。プロセッサ７０は、ソフトウェア書き込みツール６０を実行することによって、不揮発性メモリ７５に格納された実行バイナリ２０６を安全制御装置１の不揮発性メモリ１３に書き込む。これは、例えば、安全制御装置１とソフトウェア書込装置３とを、シリアルケーブル又はＵＳＢケーブル等で接続して、Ｉ／Ｏポート７２を介して、シリアル通信又はＵＳＢ通信等によって行われる。

ここで、上述した説明では、ソフトウェア生成装置２からソフトウェア書込装置３に光ディスク８０を介して実行バイナリ２０６を受け渡す場合について説明したが、これに限られない。例えば、光ディスクドライブ７４に代えてフロッピー（登録商標）ディスクドライブを有するようにし、フロッピー（登録商標）ディスクを介して実行バイナリ２０６を受け渡すようにしてもよい。また、ソフトウェア生成装置２及びソフトウェア書込装置３のそれぞれに、有線ＬＡＮポート、無線ＬＡＮポート、又は赤外線ポート等の通信ポートを有するようにして、有線ＬＡＮ通信、無線ＬＡＮ通信、又は赤外線通信等の通信によって、実行バイナリ２０６を受け渡すようにしてもよい。

また、上述した説明では、ソフトウェア生成装置２とソフトウェア書込装置３とが異なる装置で構成されている場合について説明したが、同一の装置で構成されていてもよい。また、コンフィグレータ５０、５２が、１つのコンフィグレータとして構成されていてもよく、コンパイラ５１、５３が、１つのコンパイラとして構成されていてもよい。

以上に説明したように、本実施の形態１にかかる安全制御装置１では、ユーザーによって作成された非安全関連アプリケーション１０２と、ユーザーによって作成されていない安全関連アプリケーション１０１、１０３と、安全関連アプリケーション１０１、１０３から予め生成されたＣＲＣ１２１、１２３とを含む、ユーザーによって生成された実行バイナリ２０６に基づいて、非安全関連アプリケーション１０２及び安全関連アプリケーション１０１、１０３をスケジューリングして実行するようにしている。そして、そのときに、実行バイナリ２０６に含まれる安全関連アプリケーション１０１、１０３からＣＲＣを生成し、生成したＣＲＣと、実行バイナリ２０６に含まれるＣＲＣ１２１、１２３とが一致しない場合には、非安全関連アプリケーション１０２及び安全関連アプリケーション１０１、１０３の実行を抑止するようにしている。

これよれば、ユーザーが非安全関連アプリケーション１０２の作成に応じて、非安全関連アプリケーション１０２と安全関連アプリケーション１０１、１０３とを含む実行バイナリ２０６を作成したときに、安全関連アプリケーション１０１、１０３の内容が意図せず改変されてしまった場合に、その内容が改変されてしまった安全関連アプリケーション１０１、１０３の実行を抑止することができる。そのため、ユーザーによる一部のプログラムの作成を許容する場合であっても、動作を保証することができる。

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

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

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

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

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

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

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

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

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

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

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

このように、ユーザーが作成可能な非安全関連アプリケーションは、上述した通常制御アプリケーション１０２に限られず、ここで説明したもの以外の任意の処理を実行するアプリケーションであってもよい。例えば、制御対象がサービスロボットである場合には、視覚センサによって取得した画像に対する画像処理、サービスロボットの歩行を制御する処理、又は、サービスロボットのアームを制御する処理等を実行するアプリケーションを作成可能としてもよい。

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

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

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

本実施の形態では、タイム・パーティショニングを採用したマルチタスクＯＳについて例示したが、これに限られない。タイム・パーティショニングを採用していないマルチタスクＯＳに適用することもできる。すなわち、この場合には、タスクを生成するアプリケーションが、ユーザーが自由に設計・設定可能なアプリケーション（非安全関連系）と、ユーザーが設計・設定不能なアプリケーション（安全関連系）と、ユーザーが設定のみ可能なアプリケーション（安全関連系）との３種類に分類される。

本実施の形態では、ユーザーが自由に設計・設定可能なタイムパーティション（アプリケーション）と、ユーザーが設計・設定不能なタイムパーティション（アプリケーションん）と、ユーザーが設定のみ可能なタイムパーティション（アプリケーション）とを、非安全関連系か、安全関連系かに基づいて分類するようにしたが、これに限られず、その他の基準に基づいて分類をするようにしてもよい。

本実施の形態では、動作保証チェックルーチン２９をパーティションスケジューラ２１が含む場合について例示したが、ＯＳ１００が動作保証チェックルーチン２９を有するようにし、ＯＳ１００が起動時に動作保証チェックルーチン２９を実行するものであれば、これに限られない。

１ 安全制御装置
２ ソフトウェア生成装置
３ ソフトウェア書込装置
１０、７０ プロセッサ
１１ 実行用メモリ
１２、７２ Ｉ／Ｏポート
１３、７５ 不揮発性メモリ
１５ リセット回路
２０ マイクロコントローラ
２１ パーティションスケジューラ
２２ スケジューリングテーブル
２３、２５、２７ タスクスケジューラ
２４ 安全監視タスク
２６、３１ 通常制御タスク
２８、３２ 安全制御タスク
２９ 動作保証チェックルーチン
３０ 監視制御タスク
３３ 監視タスク
３４ 制御タスク
３５ ＨＭＩタスク
５０、５２ コンフィグレータ
５１、５３ コンパイラ
５４ リンカ
５５ バイナリ変換ツール
６０ ソフトウェア書き込みツール
７１ メモリ
７３ 入力装置
７４ 光ディスクドライブ
８０ 光ディスク
１００ オペレーティングシステム
１０１ 安全監視アプリケーション
１０２ 通常制御アプリケーション
１０３ 安全制御アプリケーション
１１１、１１２、１１３、２２１、２２３ バージョン情報
１２１、１２３ ＣＲＣ
１３１、１３３ 有効範囲情報
１４２、１４３、２１１ パラメータ情報
２００ 機能安全対応ＯＳ ＡＰＩライブラリ
２０１ 非安全関連バイナリ
２０２ 安全関連バイナリ
２０３ 安全関連設定バイナリ
２０４ 機能安全対応ＯＳバイナリ
２０５、２０６ 実行バイナリ
３００、３０１、３０２ ソースコード

Claims (6)

1. ユーザーによって作成された第１のプログラムと、前記ユーザーによって作成されていない第２のプログラムと、前記第２のプログラムから予め生成された誤り検出符号とを含み、前記ユーザーによって生成された実行バイナリが格納される記憶部と、
   前記実行バイナリに含まれる第１のプログラム及び第２のプログラムをスケジューリングして実行するプログラム実行部と、
   前記実行バイナリに含まれる第２のプログラムから誤り検出符号を生成し、生成した誤り検出符号と、前記実行バイナリに含まれる誤り検出符号とが一致しない場合には、前記プログラム実行部による前記第１のプログラム及び前記第２のプログラムの実行を抑止する実行制御部と、を備え、
   前記第１のプログラムは、制御対象の通常の制御を実行するプログラムであり、
   前記第２のプログラムは、異常の検出に応じて前記制御対象の機能安全を確保するための制御を実行するプログラムである、
   制御装置。
2. 前記実行バイナリは、前記ユーザーによって設定され、前記第２のプログラムによって使用される設定値と、予め生成された、前記設定値の有効範囲を示す有効範囲情報とを含み、
   前記実行制御部は、前記実行バイナリに含まれる設定値が、前記実行バイナリに含まれる有効範囲情報が示す有効範囲内でない場合、前記プログラム実行部による前記第１のプログラム及び前記第２のプログラムの実行を抑止する、
   請求項１に記載の制御装置。
3. 前記実行バイナリは、前記ユーザーによって設定された前記第２のプログラムのバージョンを示す第１のバージョン情報と、予め生成され、前記第２のプログラムのバージョンを示す第２のバージョン情報とを含み、
   前記実行制御部は、前記実行バイナリに含まれる第１のバージョン情報と、前記実行バイナリに含まれる第２のバージョン情報とが一致しない場合には、前記プログラム実行部による前記第１のプログラム及び前記第２のプログラムの実行を抑止する、
   請求項１又は２に記載の制御装置。
4. 前記プログラム実行部は、前記第１のプログラムが実行される第１のタイムパーティションと前記第２のプログラムが実行される第２のタイムパーティションとを含む複数のタイムパーティションのスケジューリング内容を示すスケジューリング情報に従って、前記第１のプログラム及び前記第２のプログラムをスケジューリングして実行する、
   請求項１乃至３のいずれか１項に記載の制御装置。
5. 前記実行バイナリは、前記第１のプログラム及び前記第２のプログラムを実行させるためのシステムプログラムを含み、
   前記制御装置は、さらに、前記実行バイナリに含まれる前記システムプログラムを実行することによって、前記プログラム実行部及び前記実行制御部として機能するプロセッサを備えた、
   請求項１乃至４のいずれか１項に記載の制御装置。
6. ユーザーによって作成された第１のプログラムと、前記ユーザーによって作成されていない第２のプログラムと、前記第２のプログラムから予め生成された誤り検出符号とを含み、前記ユーザーによって生成されて、記憶部に格納された実行バイナリに基づいて、前記実行バイナリに含まれる第１のプログラム及び第２のプログラムをスケジューリングして実行するステップと、
   前記実行バイナリに含まれる第２のプログラムから誤り検出符号を生成し、生成した誤り検出符号と、前記実行バイナリに含まれる誤り検出符号とが一致しない場合には、前記第１のプログラム及び前記第２のプログラムの実行を抑止するステップと、を備え、
   前記第１のプログラムは、制御対象の通常の制御を実行するプログラムであり、
   前記第２のプログラムは、異常の検出に応じて前記制御対象の機能安全を確保するための制御を実行するプログラムである、
   プログラム実行方法。

Images