特許 6912421 制御装置

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

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

(11)【特許番号】6912421

(24)【登録日】2021年7月12日

(45)【発行日】2021年8月4日

(54)【発明の名称】制御装置

(51)【国際特許分類】

   G06F 9/52 20060101AFI20210727BHJP

   G05B 19/414 20060101ALI20210727BHJP

   G06F 9/54 20060101ALI20210727BHJP

【ＦＩ】

   G06F9/52 120Z

   G05B19/414 P

   G06F9/54 A

【請求項の数】3

【全頁数】12

(21)【出願番号】特願2018-106000(P2018-106000)

(22)【出願日】2018年6月1日

(65)【公開番号】特開2019-211897(P2019-211897A)

(43)【公開日】2019年12月12日

【審査請求日】2019年11月12日

(73)【特許権者】

【識別番号】390008235

【氏名又は名称】ファナック株式会社

(74)【代理人】

【識別番号】110001151

【氏名又は名称】あいわ特許業務法人

(72)【発明者】

【氏名】金丸 智

【審査官】 田中 幸雄

(56)【参考文献】

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

【文献】 特開昭６３−２５４５５５（ＪＰ，Ａ）

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

Ｇ０６Ｆ ９／５２

Ｇ０５Ｂ １９／４１４

Ｇ０６Ｆ ９／５４

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

【請求項1】

各々がリソースを管理する、またはリソースを共有する複数のプロセッサを有する制御装置であって、
前記リソースのデータを整合させる処理の開始と、第１系統のシーケンス処理とを実行する第１のプロセッサと、
第２系統のシーケンス処理を実行する第２のプロセッサと、を有し、
前記第１のプロセッサが前記リソース間のデータを整合させる処理の開始を示すリクエストメッセージを送信し、前記リクエストメッセージには、バックアップ対象のデータを特定する情報が含まれ、前記第２のプロセッサが前記リクエストメッセージを受信するリクエストメッセージ送受信手段と、
前記第２のプロセッサが、前記バックアップ対象のデータに関連するシーケンス処理を完了した後、前記バックアップ対象のデータを含むレディメッセージを送信し、前記第１のプロセッサが前記レディメッセージを受信するレディメッセージ送受信手段と、
前記第２のプロセッサに対し、前記第１のプロセッサが前記レディメッセージに含まれる前記バックアップ対象のデータをバックアップし、前記リソースのデータを整合させる処理が完了したことを示すエンドメッセージを通知し、前記第２のプロセッサが前記エンドメッセージを受信するエンドメッセージ送受信手段と、
を有し、
前記第１のプロセッサは、前記リクエストメッセージの通知後に待機状態となり、前記レディメッセージの通知後に動作を再開し、
前記第２のプロセッサは、前記レディメッセージの通知後に待機状態となり、前記エンドメッセージの通知後に動作を再開することを特徴とする制御装置。

【請求項2】

前記第１のプロセッサは、前記データを整合させる処理として、メモリ上のデータのバックアップ処理を実行することを特徴とする
請求項１記載の制御装置。

【請求項3】

各々がリソースを管理する、またはリソースを共有する複数のプロセッサを有する制御装置であって、
前記リソースのデータを整合させる処理の開始と、第１系統のシーケンス処理とを実行する第１のプロセッサと、
第２系統のシーケンス処理を実行する第２のプロセッサと、を有し、
前記第１のプロセッサが前記リソース間のデータを整合させる処理の開始を示すリクエストメッセージを送信し、前記リクエストメッセージには、バックアップ対象のデータを特定する情報が含まれ、前記第２のプロセッサが前記リクエストメッセージを受信するリクエストメッセージ送受信手段と、
前記第２のプロセッサが、前記バックアップ対象のデータに関連するシーケンス処理を完了した後、前記バックアップ対象のデータを含むレディメッセージを送信し、前記第１のプロセッサが前記レディメッセージを受信するレディメッセージ送受信手段と、
前記第１のプロセッサは、前記データを整合させる処理として、前記第２のプロセッサによるレディメッセージの受信確認に応じて、シャットダウン処理を実行することを特徴とする制御装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、制御装置に関し、特にマルチプロセッサ又はマルチコアプロセッサ等の複数のプロセッサ間でリソースを共有することが可能な制御装置に関する。

【背景技術】

【0002】

ロボットや工作機械等の産業機械（以下、単に機械という）を制御する制御装置は、様々なデータのバックアップを行う機能を有することが一般的である。例えば制御装置は、停電等により制御装置の電源がＵＰＳ（無停電電源装置）に切り替わったことを検知すると、制御装置の再開に必要なメモリ上のデータを所定のストレージデバイス（以下、単にストレージという）にバックアップした後、制御装置自身をシャットダウンする。また、停電のようなイベント発生時だけでなく、定期的に上述のようなバックアップを実行することで、システムの可用性を高めている。

【0003】

バックアップされたデータに不整合があると、再開時に機械が立ち上がらなかったり、正常に運転できず加工不良やクラッシュなどが発生して、多大な損失をこうむるおそれがある。また、整合性のとれたデータがバックアップされていれば、バックアップデータを同様の機械及び制御装置を備える別のシステムに移植することにより、移植先のシステムの立ち上げを比較的簡便に行うことができる。

【0004】

マルチプロセッサやマルチコアプロセッサを有する制御装置では、メモリ上にあるバックアップ対象のデータや、バックアップ先のストレージへのアクセスが、複数のプロセッサ又はコアから同時に発生することがある。例えば図１に示すように、プロセッサ＃２がメモリ上のデータにアクセスしている時、又はプロセッサ＃３がストレージにアクセスしている時に、プロセッサ＃１がメモリ上のデータをストレージにバックアップしようとすることがある。このような場合、データの整合性を保証したバックアップができない可能性がある。又はバックアップに非常に長い時間がかかることがある。

【0005】

このような事態を避けるため、制御装置は、メモリやストレージ等のリソースに対する、複数のプロセッサやコアからのアクセスを管理するための機構（特許文献１に開示されているようなセマフォを使った排他制御機構等）を備えることが一般的である。しかしながら、プロセッサやコアの数が増え、アクセス処理が複雑な依存関係を有するようになったシステムでは、アクセス管理は非常に複雑である。ここでいう依存関係とは、あるプロセッサ（又はコア）による特定のリソースへのアクセスと、他のプロセッサ（又はコア）で実行している処理とが互いに競合したり、影響したりする関係性のことをいう。このようなアクセス処理の依存関係を解析することや、それらのアクセス処理各々に排他制御を実装することは、非常に工数が掛かり、開発者の負担となる。また、排他制御を実装することで発生するオーバヘッドによるパフォーマンスの低下や、コード量の増加も問題となる。

【0006】

汎用のコンピュータ用オペレーティングシステムは、スナップショットやハイバネーションといった、メモリ上のデータを所定のストレージへバックアップする機能を提供している。ところが、このような機能は、任意の瞬間におけるメモリ上のデータをそのままバックアップするものであって、メモリ上のデータの整合性は保証していない。

【0007】

例えば図２に示すように、４つのメンバ変数を持つ構造体が１つのデータセットとして定義されているものとする。そして制御装置がある指令を実行すると、これら４つのメンバ変数が全て更新されるものとする。この場合、仮に３つ目のメンバ変数までが更新され、４つの目のメンバ変数が未だ更新されていない状態でスナップショット機能が実行されると、バックアップされたデータセットはデータの整合性が保たれていないものとなる。つまり、データの整合性が保証されているとは、指令の実行結果が関連する全てのデータ（先の例における４つのメンバ変数）に完全に反映された状態となっていることをいう。

【0008】

スナップショットやハイバネーションといった機能は、不具合の調査や、システム障害からの迅速な再起動には効果的ではあるが、データの整合性を厳密に保証することが求められるバックアップ用途には適さない。特に、リアルタイム性が高く、データセットとしての更新頻度が高い産業機械の制御装置においては、スナップショットやハイバネーションといった機能を採用することは難しい。

【0009】

データセットが完全に更新されるまでプロセッサ又はコア間で待ち合わせを行うことにより、データの整合性を保証することも考えられる。しかし、一般にプロセッサ間又はコア間で待ち合わせを行うには、各プロセッサ及び各コアが実行するプログラム内に、待ち合わせを行うためのコマンドを明示的に実装する必要がある。また、データセットの更新の度に待ち合わせを行うと、パフォーマンスの大幅な低下が懸念される。

【0010】

また、データの不整合は、複数のプロセッサ又はコアが協力してデータ更新処理を行うような場合に、任意のタイミングでバックアップを行うと発生することがある。例えば図３に示すように、データセットＤＡＴＡ＿ＳＥＴ１及びＤＡＴＡ＿ＳＥＴ２が、あるシーケンスの実行により連動して更新されるよう設計されている場合を考える。この場合、プロセッサ＃１がＤＡＴＡ＿ＳＥＴ１の更新を完了し、プロセッサ＃２がＤＡＴＡ＿ＳＥＴ２の更新を完了していない状態でバックアップが実行されると、ＤＡＴＡ＿ＳＥＴ１とＤＡＴＡ＿ＳＥＴ２との間で不整合が発生する。

【0011】

このように、任意のタイミングでデータバックアップを行う従来技術では、データの整合性を保証することが難しい。これは、メモリ内容のバックアップに限らず、ストレージやポータブルデバイス等に格納されたデータを入出力する際や、シャットダウンシーケンスを実行する際にも同様に生じうる問題である。また、バックアップ先及び入出力先のストレージやデバイスにおいても、厳密にはアクセス管理が必要になる。してみると、マルチプロセッサ又はマルチコアのプロセッサが稼動する情報処理システム、特にリアルタイム性の高い産業機械の制御装置においては、バックアップやデータ入出力は非常に難しい処理であるといえる。

【先行技術文献】

【特許文献】

【0012】

【特許文献1】特開昭６２−２１９０５８号公報

【発明の概要】

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

【0013】

こうした背景から、従来、産業機械の制御装置におけるデータのバックアップ及び入出力は、制御装置の電源投入直後、シングルプロセッサ又はシングルコアで動作する段階において実施するケースが多かった。産業機械においてはデータの整合性が特に強く要求され、バックアップすべきパラメタ等のデータの数も非常に多いからである。しかし、データのバックアップ及び入出力を行うだけのために制御装置の電源を入れ直すことは、周辺機器（例えばアクチュエータ、計測機器及びモータアンプ等）への負担が大きいうえ、製造工程への影響も少なくなく、無駄の多い作業であった。

【0014】

本発明はこのような課題を解決するためのものであり、マルチプロセッサ又はマルチコアプロセッサ等の複数のプロセッサ間で安全にリソースを共有することが可能な制御装置を提供することを目的とする。

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

【0015】

各々がリソースを管理する、またはリソースを共有する複数のプロセッサを有する制御装置であって、リソースのデータを整合させる処理の開始と、第１系統のシーケンス処理とを実行する第１のプロセッサと、第２系統のシーケンス処理を実行する第２のプロセッサと、を有し、第１のプロセッサがリソース間のデータを整合させる処理の開始を示すリクエストメッセージを送信し、リクエストメッセージには、バックアップ対象のデータを特定する情報が含まれ、第２のプロセッサがリクエストメッセージを受信するリクエストメッセージ送受信手段と、第２のプロセッサが、前記バックアップ対象のデータに関連するシーケンス処理を完了した後、バックアップ対象のデータを含むレディメッセージを送信し、第１のプロセッサがレディメッセージを受信するレディメッセージ送受信手段と、第２のプロセッサに対し、第１のプロセッサがレディメッセージに含まれるバックアップ対象のデータをバックアップし、リソースのデータを整合させる処理が完了したことを示すエンドメッセージを通知し、第２のプロセッサがエンドメッセージを受信するエンドメッセージ送受信手段と、を有し、第１のプロセッサは、リクエストメッセージの通知後に待機状態となり、レディメッセージの通知後に動作を再開し、第２のプロセッサは、レディメッセージの通知後に待機状態となり、エンドメッセージの通知後に動作を再開することを特徴とする。
各々がリソースを管理する、またはリソースを共有する複数のプロセッサを有する制御装置であって、リソースのデータを整合させる処理の開始と、第１系統のシーケンス処理とを実行する第１のプロセッサと、第２系統のシーケンス処理を実行する第２のプロセッサと、を有し、第１のプロセッサがリソース間のデータを整合させる処理の開始を示すリクエストメッセージを送信し、リクエストメッセージには、バックアップ対象のデータを特定する情報が含まれ、第２のプロセッサがリクエストメッセージを受信するリクエストメッセージ送受信手段と、第２のプロセッサが、バックアップ対象のデータに関連するシーケンス処理を完了した後、バックアップ対象のデータを含むレディメッセージを送信し、第１のプロセッサがレディメッセージを受信するレディメッセージ送受信手段と、第１のプロセッサは、データを整合させる処理として、第２のプロセッサによるレディメッセージの受信確認に応じて、シャットダウン処理を実行することを特徴とする。

【発明の効果】

【0016】

本発明により、マルチプロセッサ又はマルチコアプロセッサ等の複数のプロセッサ間で安全にリソースを共有することが可能な制御装置を提供することができる。

【図面の簡単な説明】

【0017】

【図1】データの不整合の発生例を示す図である。

【図2】データの不整合の発生例を示す図である。

【図3】データの不整合の発生例を示す図である。

【図4】制御装置１の機能及び動作を示す図である。

【図5】制御装置１の機能及び動作を示す図である。

【図6】制御装置１の動作を示す図である。

【図7】制御装置１の機能及び動作を示す図である。

【図8】制御装置１の動作を示す図である。

【図9】制御装置１のハードウェア構成を示す図である。

【図10】プロセッサ１１ａ、１１ｂの関係を示す図である。

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

【0018】

＜実施形態１＞
図９は、本発明の実施形態１による制御装置１の要部を示す概略的なハードウェア構成図である。制御装置１は、例えばプログラムを読み込んで工作機械やロボット等の機械の制御を行う数値制御装置等である。制御装置１は、複数のプロセッサ１１（本図では１１ａ，１１ｂの２つを例示する）、ＲＯＭ１２、ＲＡＭ１３、不揮発性メモリ１４、インタフェース１８、バス１０、軸制御回路１６、サーボアンプ１７を有する。インタフェース１８には、例えば操作盤６０等が接続される。

【0019】

プロセッサ１１は、制御装置１を全体的に制御するプロセッサである。プロセッサ１１は、ＲＯＭ１２に格納されたシステム・プログラムをバス１０を介して読み出し、システム・プログラムに従って制御装置１全体を制御する。
本実施の形態では、制御装置１は複数のプロセッサ１１（１１ａ，１１ｂ）を有している。個々のプロセッサ１１（１１ａ，１１ｂ）は、例えばマルチプロセッサ環境における各プロセッサ、マルチコアプロセッサにおける各コアに相当する。

【0020】

ＲＯＭ１２は、機械の各種制御等を実行するためのシステム・プログラムを予め格納している。

【0021】

ＲＡＭ１３は、一時的な計算データや表示データ、後述する操作盤６０を介してオペレータが入力したデータ等を一時的に格納する。例えばＤＲＡＭはこれに含まれる。

【0022】

不揮発性メモリ１４は、例えば図示しないバッテリでバックアップされており、制御装置１の電源が遮断されても記憶状態を保持する。例えばバッテリでバックアップされたＳＲＡＭなどが相当する。不揮発性メモリ１４は、例えばＲＡＭ１３上のデータのバックアップ先ストレージとして使用される。

【0023】

軸制御回路１６は、機械の動作軸を制御する。軸制御回路１６は、プロセッサ１１が出力する軸の移動指令量を受けて、軸の移動指令をサーボアンプ１７に出力する。

【0024】

サーボアンプ１７は、軸制御回路１６が出力する軸の移動指令を受けて、サーボモータ５０を駆動する。

【0025】

サーボモータ５０は、サーボアンプ１７により駆動されて機械の動作軸を動かす。サーボモータ５０は、典型的には位置・速度検出器を内蔵する。位置・速度検出器は位置・速度フィードバック信号を出力し、この信号が軸制御回路１６にフィードバックされることで、位置・速度のフィードバック制御が行われる。

【0026】

なお、図１では軸制御回路１６、サーボアンプ１７、サーボモータ５０は１つずつしか示されていないが、実際には制御対象となる機械に備えられた軸の数だけ用意される。例えば、６軸を備えたロボットを制御する場合、それぞれの軸に対応する軸制御回路１６、サーボアンプ１７、サーボモータ５０が合計６セット用意される場合もある。

【0027】

操作盤６０は、ディスプレイやハードウェアキー等を備えたデータ入出力装置である。操作盤６０は、インタフェース１８を介してプロセッサ１１から受けた情報をディスプレイに表示する。操作盤６０は、ハードウェアキー等から入力された指令やデータ等をインタフェース１８を介してプロセッサ１１に渡す。

【0028】

図４は、本実施形態における制御装置１の概略的な機能及び動作ブロック図である。制御装置１は、リクエストメッセージ送受信手段１０１、シーケンス処理完了判定手段１０２、レディメッセージ送受信手段１０３、エンドメッセージ送受信手段１０４を有する。リクエストメッセージ送受信手段１０１、シーケンス処理完了判定手段１０２、レディメッセージ送受信手段１０３、及びエンドメッセージ送受信手段１０４は、プロセッサ１１の一機能としてハードウェア的に実現されても良く、例えばＲＯＭ１２、ＲＡＭ１３、又は不揮発性メモリ１４に格納されたプログラムをプロセッサ１１が実行することにより実現されても良い。

【0029】

図４のプロセッサ１１ａ（プロセッサ＃１）、プロセッサ１１ｂ（プロセッサ＃２）は、それぞれＲＡＭ１３上に各自のリソースを管理しているものとする。本実施例は、図１０に示すように、１つのデータセット内の異なるデータ（データ＃１、データ＃２）を、プロセッサ１１ａ及びプロセッサ１１ｂがそれぞれ独自に管理している状態を想定している。

【0030】

リクエストメッセージ送受信手段１０１は、プロセッサ１１ａ（任意のプロセッサ又はコア。図４においてはプロセッサ＃１）からプロセッサ１１ｂ（他の全てのプロセッサ又はコアの各々。図４においてはプロセッサ＃２）に対してリクエストメッセージを送信する。プロセッサ１１ａとプロセッサ１１ｂとは、１対多の関係である。
リクエストメッセージとは、メッセージの送信者（プロセッサ１１ａ）がバックアップ処理を実行したい旨を受信者（プロセッサ１１ｂ）に通知するものである。リクエストメッセージには、バックアップ対象のデータ（データセットを含む）を特定する情報（メモリブロックのインデックス）が含まれる。
リクエストメッセージの送信後、リクエストメッセージ送受信手段１０１は、プロセッサ１１ａをバックアップ処理の実行待ち（待機状態）とする。
リクエストメッセージを受信したプロセッサ１１ｂは、リクエストメッセージの内容をシーケンス処理完了判定手段に通知する。

【0031】

シーケンス処理完了判定手段１０２は、リクエストメッセージの受信者（プロセッサ１１ｂ）において、リクエストメッセージの内容に関連する、プロセッサ１１ｂ自身が実行するシーケンス処理が完了したか否かを判定する。つまりプロセッサ１１ｂは、リクエストメッセージに含まれていたメモリブロックのインデックスにアクセスするデータを特定し、当該データにかかるシーケンス処理を終わらせる。
シーケンス処理が完了したと判断すると、シーケンス処理完了判定手段１０２は、プロセッサ１１ｂを待機状態に設定し、レディメッセージ送受信手段１０３に通知を送信する。

【0032】

レディメッセージ送受信手段１０３は、リクエストメッセージの受信者（プロセッサ１１ｂ）からリクエストメッセージの送信者（プロセッサ１１ａ）に対してレディメッセージを送信する。
レディメッセージとは、リクエストメッセージの送信者（プロセッサ１１ａ）が実行を希望するバックアップ処理に関連するシーケンス処理のうち、リクエストメッセージの受信者（プロセッサ１１ｂ）に関係する部分の実行が完了したことを、リクエストメッセージの送信者（プロセッサ１１ａ）に通知するものである。
プロセッサ１１ａは、リクエストメッセージの宛先となった全てのプロセッサ１１ｂからレディメッセージを受信したか否かを判断する。全てのプロセッサ１１ｂからレディメッセージを受信したならば、レディメッセージ送受信手段１０３は、プロセッサ１１ａのバックアップ処理の実行待ち（待機状態）を解除する。
プロセッサ１１ａはバックアップ処理を実行する。

【0033】

エンドメッセージ送受信手段１０４は、リクエストメッセージの送信者（プロセッサ１１ａ）からリクエストメッセージの受信者（プロセッサ１１ｂ）に対してエンドメッセージを送信する。
エンドメッセージとは、リクエストメッセージの送信者（プロセッサ１１ａ）においてバックアップ処理が完了したことを通知するものである。
エンドメッセージ送受信手段１０４は、エンドメッセージを受信したプロセッサ１１ｂの待機状態を解除する。

【0034】

図５を用いて、従来技術に対する本実施形態の利点について説明する。本実施形態の特徴的な構成要素であるシーケンス処理完了判定手段１０２は、リクエストメッセージを受信した全てのプロセッサ１１ｂにおいてバックアップ処理の対象データに関連するシーケンス処理が完了したことを確認してから、プロセッサ１１ｂを待機状態に移行させる。仮にプロセッサ１１ｂがリクエストメッセージを受信してすぐに待機状態に移行するなら、データセットには不整合が発生してしまう。しかし本実施形態では、シーケンス処理完了判定手段１０２が、シーケンス処理が終了するまではプロセッサ１１ｂを待機状態に移行させず、データセットが整合するまで実行処理を継続させる。そのため、データセットの不整合が発生しない。

【0035】

図６は、プロセッサ１１ａ（プロセッサ＃１）、プロセッサ１１ｂ（プロセッサ＃２）、プロセッサ１１ｃ（プロセッサ＃３）がそれぞれ、系統１軸制御、系統２軸制御、系統３軸制御を実行する制御装置１において、プロセッサ１１ｂ（プロセッサ＃２）がデータバックアップを実行する場合のプロセッサ間の処理フローの例を示すチャートである。

【0036】

初期状態において、プロセッサ１１ａ、プロセッサ１１ｂ、プロセッサ１１ｃはそれぞれ系統１軸制御、系統２軸制御、系統３軸制御にかかる処理を実行している（Ｓ１１，Ｓ２１，Ｓ３１）。

【0037】

プロセッサ１１ｂが、バックアップ処理のリクエストメッセージをプロセッサ１１ａ、プロセッサ１１ｃに対して送信する（Ｓ２２）。この後、プロセッサ１１ｂは待機状態となる。

【0038】

リクエストメッセージを受信したプロセッサ１１ａ、プロセッサ１１ｃは、それぞれ当該リクエストメッセージの内容に関係するシーケンス処理を完了させ（Ｓ１２，Ｓ３２）、プロセッサ１１ｂに対しレディメッセージを送信する。この後、プロセッサ１１ａ、プロセッサ１１ｃは待機状態となる。

【0039】

プロセッサ１１ｂは、全てのプロセッサ１１ａ、プロセッサ１１ｃからレディメッセージを受信したことを確認すると、待機状態を解除してバックアップ処理を実行する（Ｓ２３）。バックアップ処理が完了すると、プロセッサ１１ｂは、プロセッサ１１ａ、プロセッサ１１ｃに対してエンドメッセージを送信し（Ｓ２４）する。またプロセッサ１１ｂは、系統２軸制御の実行を再開する（Ｓ２５）。

【0040】

プロセッサ１１ａ、プロセッサ１１ｃは、エンドメッセージを受信すると待機状態を解除し、系統１軸制御、系統３軸制御の実行を再開する（Ｓ１３，Ｓ３３）。

【0041】

本実施形態によれば、データの更新頻度が高く、複雑なアクセス処理が混在する制御装置１であっても、データの整合性を保証したデータバックアップ、データ入出力、及びシャットダウンシーケンスの実行等が可能になる。また、排他制御を実装することで発生するオーバヘッドによるパフォーマンスの低下、コード量の増加によるストレージやメモリの圧迫等の問題を回避することができる。

【0042】

また本実施形態では、リクエストメッセージの内容に応じ、データの整合性を保つために必要な範囲において、バックアップ前にシーケンス処理を完了させ、バックアップ処理の完了を待機する構成とした。したがって、例えば系統間や制御軸間の依存関係に従って、シーケンス処理の実行範囲、すなわちデータの整合性の保証範囲が適切に設定される。

【0043】

なお上述の実施形態では、バックアップ処理のリクエストメッセージをトリガとして、一連の処理が実行される例を示した。しかしながら、プライマリのプロセッサ又はコアの実行したい処理の種類に応じて、リクエストメッセージの種類、形式、内容、シーケンス処理の内容や範囲等が異なっていても構わない。例えばバックアップ処理の場合でも、不揮発性メモリ１４やＲＯＭ１２へのバックアップ、図示しない外部ストレージへのバックアップといった態様の違いに応じて、諸条件を適宜変更して差し支えない。

【0044】

＜実施形態２＞
図７を用いて、実施形態２にかかる制御装置１の動作について説明する。実施形態２は実施形態１の変形例であり、特に明示しない限り、実施形態２にかかる制御装置１の構成要素及び動作は実施形態１のものを踏襲する。

【0045】

本実施形態では、シーケンス処理完了判定手段１０２は、リクエストメッセージの受信者（実施形態１の例ではプロセッサ１１ｂ）において、リクエストメッセージで通知された処理（実施形態１の例ではバックアップ処理）に依存しない（影響を与えない）処理を別のタスクとして実装しておくことができる。そしてプロセッサ１１ｂは、レディメッセージを送信後、待機状態に移行する代わりに、当該別のタスクにスイッチする。すなわち、バックアップ処理に関係のないタスクを、バックアップ処理と独立したメモリ空間で継続することができる。

【0046】

この場合、エンドメッセージ送受信手段１０４は、エンドメッセージを受信した際、プロセッサ１１ｂがバックアップ処理の完了待ち（待機状態）であるか、別のタスクを実行している状態であるかを判定する。バックアップ処理の完了待ち（待機状態）であれば、待機状態を解除する。一方、別のタスクが実行状態であれば、リクエストメッセージ受信時のタスク（例えば軸制御）にスイッチする。

【0047】

本実施例によれば、リクエストメッセージを受信したプロセッサ又はコアは、リクエストされた処理の完了を待つ間に別のタスクを実行できるので、制御装置１全体の処理効率を向上させることができる。

【0048】

＜実施形態３＞
図８を用いて、実施形態３にかかる制御装置１の動作について説明する。実施形態３は実施形態１の変形例であり、特に明示しない限り、実施形態３にかかる制御装置１の構成要素及び動作は実施形態１のものを踏襲する。
本実施形態は、プライマリのプロセッサから送信されるメッセージの種類に応じて、シーケンス処理完了判定の条件や、エンドメッセージ受信後の動作を変える点に特徴を有する。
図８は、実施形態３のバックアップ処理に関する動作スキームを、システムエラー発生時のシャットダウンシーケンス実行に応用した場合の、プロセッサ１１ａ（プロセッサ＃１）、プロセッサ１１ｂ（プロセッサ＃２）、プロセッサ１１ｃ（プロセッサ＃３）の動作を示すチャートである。

【0049】

初期状態において、プロセッサ１１ａ、プロセッサ１１ｂ、プロセッサ１１ｃはそれぞれ系統１軸制御、系統２軸制御、系統３軸制御にかかる処理を実行している（Ｓ２１１，Ｓ２２１，Ｓ２３１）。

【0050】

プロセッサ１１ｂが、システムエラー発生通知（実施形態１のバックアップ処理のリクエストメッセージに相当）をプロセッサ１１ａ、プロセッサ１１ｃに対して送信する（Ｓ２２２）。なおシステムエラー発生通知にも、バックアップ対象のデータが存在するメモリブロックのインデックスが含まれるものとする。この後、プロセッサ１１ｂは待機状態となる。

【0051】

システムエラー発生通知を受信したプロセッサ１１ａ、プロセッサ１１ｃは、それぞれバックアップ対象のデータに関係するシーケンス処理を完了させる。併せて、システムエラー発生通知の受信時には、シャットダウンシーケンスの実行に備え、レジスタをリセットする、コアの周波数を落とす等の処理を実行しても良い（Ｓ２１２，Ｓ２３２）。シーケンス処理等が完了したなら、プロセッサ１１ａ、プロセッサ１１ｃは、プロセッサ１１ｂに対しレディメッセージを送信する。この後、プロセッサ１１ａ、プロセッサ１１ｃは待機状態となる。

【0052】

プロセッサ１１ｂは、全てのプロセッサ１１ａ、プロセッサ１１ｃからレディメッセージを受信したことを確認すると、待機状態を解除してシャットダウンシーケンスを実行する（Ｓ２２３）。シャットダウンシーケンスが完了すると、プロセッサ１１ｂは、プロセッサ１１ａ、プロセッサ１１に対してプロセッサ停止要求（実施形態１のエンドメッセージに相当）を送信し（Ｓ２２４）する。またプロセッサ１１ｂは動作を停止する（Ｓ２２５）。

【0053】

プロセッサ１１ａ、プロセッサ１１ｃは、プロセッサ停止要求を受信すると待機状態を解除し、動作を停止する（Ｓ２１３，Ｓ２３３）。

【0054】

以上、本発明の実施の形態について説明したが、本発明は上述した実施の形態の例のみに限定されることなく、適宜の変更を加えることにより様々な態様で実施することができる。

【0055】

例えば、本発明は、データバックアップ、データ入出力、及びシャットダウンシーケンスに限らず、様々な用途に適用可能である。例えばシステムエラー発生時のプロセッサ間又はコア間の通信方法、安全にシステムを停止するための非常停止処理の実行方法などに応用できる。また、アプリケーションの再起動を行う際に、メモリマップ上の特定のメモリを初期化する方法としても利用できる。

【符号の説明】

【0056】

１ 制御装置
１１（１１ａ，１１ｂ，１１ｃ） プロセッサ
１２ ＲＯＭ
１３ ＲＡＭ
１４ 不揮発性メモリ
１８ インタフェース
１０ バス
１６ 軸制御回路
１７ サーボアンプ
５０ サーボモータ
６０ 操作盤
１０１ リクエストメッセージ送受信手段
１０２ シーケンス処理完了判定手段
１０３ レディメッセージ送受信手段
１０４ エンドメッセージ送受信手段

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】