JP2009053963A - プログラマブルコントローラ、そのｃｐｕモジュール - Google Patents

Abstract

【課題】複数レベルのタスクを実行するマイコンが低速デバイスにアクセスする場合に、アクセス実行完了を待たずに、他の処理を実行可能にする。
【解決手段】バスインタフェース１０は、マイコン側で実行する複数レベルのタスク各々に対応する複数のアクセスチャネル１１，１２，１３を有する。各アクセスチャネルは、複数のレジスタａ〜ｅを有する。マイコン側で任意のタスク実行中に共有メモリアクセス要求が発生すると、当該タスクのレベルに応じたアクセスチャネルにアクセスを依頼する。すなわち、要求内容を当該アクセスチャネルの上記レジスタにセットする。セット完了したら、バスインタフェース１０は、直ちにＲＤＹ信号をＯＮする（ＷＡＩＴ解除する）。その後は、バスアクセス制御部１５が、共有メモリアクセス処理を実行する。
【選択図】図１

Description

本発明は、プログラマブルコントローラ、そのＣＰＵモジュール等に関する。

従来の技術を図１８〜図２１を参照して説明する。
プログラマブルコントローラ(以下 PLC)は、例えばIEC61131-3で規格化されたプログラム言語によって記述されたアプリケーションを実行するものである。アプリケーションは実行優先度によって複数レベルのタスク（マルチタスク）をもつことができることが一般に知られている。図１８に、このマルチタスク実行の様子を示している。

図１８に示す例では、０レベルタスク、１レベルタスク、デフォルトタスクの３種類あり、“０レベルタスク＞１レベルタスク＞デフォルトタスク”の関係にある（つまり、０レベルタスクが最も実行優先度が高い）。

図示の例では、通常はデフォルトタスクを実行しているが、０レベルタスクの実行タイミング（２ms周期）又は１レベルタスクの実行タイミング（５ms周期）になる毎に、デフォルトタスクの実行を中断し、０レベルタスク又は１レベルタスクを実行する。また、図には示されていないが、１レベルタスク実行中に０レベルタスクの実行タイミングとなった場合には、１レベルタスクの実行を中断し、０レベルタスクを実行する。

また、図１９に、従来のＰＬＣの内部および外部構成例を示す。
図１９に示すＰＬＣ構成例では、複数のＩ／Ｏモジュール１０４と複数のＣＰＵモジュール１１０が、Ｉ／Ｏバス１０３に接続しており、モジュール相互に通信を行う。また、複数のＣＰＵモジュール１１０は、共有メモリバス１０２にも接続しており、各ＣＰＵモジュール１１０各々が、共有メモリバス１０２を介して共有メモリ１０１にアクセスする。

各ＣＰＵモジュール１１０は、マイコン１１１、ＲＯＭ１１２、ＲＡＭ１１３、バスインタフェース１１４、Ｉ／Ｏインタフェース１１５、ＲＤＹ制御部１１６を有する。
Ｉ／Ｏインタフェース１１５は、Ｉ／Ｏバス１０３に接続しており、他のモジュールとの通信制御を行う。バスインタフェース１１４は、共有メモリバス１０２に接続しており、共有メモリ１０１に対するアクセス制御を行う。

マイコン１１１は、ＲＡＭ１１３またはＲＯＭ１１２に格納されているアプリケーションプログラムを読み出しては命令の実行を行う。このアプリケーションプログラム実行中に、共有メモリアクセス処理が発生した場合には、アプリケーションはシステムソフトを呼び出す。このシステムソフトはＰＬＣメーカ側で予め作成しておくファームウェアであり、共有メモリアクセス処理を実行する。一方、アプリケーションプログラムは顧客側で作成する。顧客側では、新たなアプリケーションプログラムを作成する際、例えば上記共有メモリへアクセスする処理を逐一記述する必要はなく、上記予め用意されているシステムソフトを呼び出せばよいので、手間が軽減される。つまり、システムソフトは、アプリケーションが呼び出すサブルーチンの様なものである。

システムソフトは、バスインタフェース１１４を介して、共有メモリアクセス処理を実行するが、処理が完了するまで、後述するＲＤＹ信号のためにＷＡＩＴ状態となり、アプリケーションに戻らない。この為、上位レベルのタスクの実行タイミングになっても実行できないという問題が生じる。詳しくは後述する。

以下に共有メモリアクセス処理の実行について説明する。
マイコン１１１の上記システムソフトは、バスインタフェース１１４を介して共有メモリバス１０２上の共有メモリ１０１へアクセスする。

共有メモリ１０１は、共有メモリバス１０２に接続されている全ＣＰＵモジュール１１０からアクセス可能であり、複数アクセス者を調停機能により排他してアクセス者を決定する。このように、共有メモリアクセスには、マイコン１１１から見て、バスインタフェース１１４へのアクセスタイム、バスインタフェース１１４によるバス調停及び共有メモリ１０１へのアクセスタイムというように、内部のＲＯＭ１１２、ＲＡＭ１１３等へのアクセスタイムと比較して長い時間が掛かる。更に、仮に、調停で負けた場合は、他のCPUモジュール１１０による共有メモリアクセス完了まで待たされた後、ようやく共有メモリアクセス権が回ってくるため、さらに時間が掛かることになる。

図２０に、従来のバスインタフェース１１４の構成例を示す。また、図２１に、従来のバスインタフェース１１４による共有メモリアクセスタイミングチャート（リード処理の場合）例を示す。

バスインタフェース１１４とマイコン１１１とは、データバス、アドレスバス、セレクト(*CS)、リード／ライト(RD/*WT)、レディ(RDY)の各信号線が接続される。バスインタフェース１１４内の「内部制御信号とＲＤＹの生成部」１３１は、マイコン１１１から送信されるセレクト*CS信号、アドレス信号により共有メモリ１０１へのアクセス要求を認識すると、レディ(RDY)信号をWAIT状態“Ｌ”（Low）にしてマイコン１１１をWAIT状態にさせておいて、バスアクセス制御部１３２に対してアクセス要求を出す。尚、図２１に示す通り、レディ(RDY)信号は‘Ｌ’でＷＡＩＴ、‘Ｈ’でＲＤＹ（ＷＡＩＴ解除）を意味する。

バスアクセス制御部１３２は、このアクセス要求に応じて共有メモリ１０１へのアクセスを行う。尚、バスアクセス制御部１３２には、データバス、アドレスバスが接続しており、アドレスバスを介して共有メモリ１０１へのアクセスアドレスが入力される。そして、リード／ライト(RD/*WT)信号がライト要求*WTであれば、データバスを介して共有メモリ１０１への書き込みデータが入力され、バスアクセス制御部１３２は、このデータを共有メモリ１０１の上記アクセスアドレスの領域に書き込む。一方、リード／ライト(RD/*WT)信号がリード要求ＲＤであれば、バスアクセス制御部１３２は、共有メモリ１０１の上記アクセスアドレスの領域からデータを読み出して、このリードデータをデータバスに出力する。これらの入力／出力の相手先は、当然、マイコン１１１である。

図２１はリードの場合の例なので、ここではリード要求RDに応じて、共有メモリ１０１へのリードアクセスを行うものとする。
バスアクセス制御部１３２は、共有メモリバス１０２上でのリードアクセスが完了すると、上記の通りデータバス上に読出しデータを出力すると共に、「内部制御信号とＲＤＹの生成部」１３１に対してアクセス完了を通知する。この通知を受けた「内部制御信号とＲＤＹの生成部」１３１は、図２１に示す通り、レディ(RDY)信号をWAIT状態“Ｌ”からRDY状態“Ｈ”にする。これによって、マイコン１１１はリードデータを取得する。

これにより、マイコン１１１としては、共有メモリアクセス命令の実行を完了し、アプリケーションプログラム上の次の命令実行に移ることになる。しかし、図２１に示す通り、バスインタフェース１１４による共有メモリ１０１へのリードアクセスが完了するまでの間、レディ(RDY)信号はＷＡＩＴ状態となっており、マイコン１１１は、この間ずっと待たされることになる。そして、上述してある通り、この待ち時間は長く、更に調停で負
けた場合には非常に長くなる。

低速デバイスへアクセスに行った時に待ち時間を短縮する方法として、例えば特許文献１に記載の手法が知られている。
この手法は、マスタからスレーブにアクセスする際、コマンドをスレーブ内に設けたバッファに一旦受けた時点で、マスタのウエイト解除をするというものである。
特開平１１−２９６２１０号公報

上述した従来技術の問題点について、以下、説明する。
（課題１）
ＰＬＣにおいては、各ＣＰＵモジュール１１０毎に1つのマイコン１１１によって、アプリケーションの実行、ローダとの通信など複数の処理を実行させている。ＰＬＣではＩ／Ｏモジュール１０４とのアクセス、複数のＣＰＵモジュール１１０とのメモリ共有が相変わらず存在しているが、この共有メモリ等のような低速デバイスへのアクセスタイムは、マイコン１１１の動作スピード、ＲＡＭ１１３、ＲＯＭ１１２へのアクセスタイム等と比較して圧倒的に長いため、マイコン１１１が行なわなければならない処理が低速デバイスアクセスによって阻害、滞ることが深刻化してきている。特に、マイコン１１１の動作スピードに比較して、共有メモリへのアクセスタイムは非常に長いため、従来技術で述べたように、共有メモリアクセスが完了するまでの間、ＣＰＵがWAIT状態になり続けるのは、マイコンが行なわなければならない処理が非常に阻害されることになる。

また近年、より高速なネットワークとの接続もＰＬＣに求められてくると考えられ、ますますマイコン１１１の処理性能劣化への対策が重要となってくる。
このような共有メモリ等の低速デバイスへのアクセスに伴うマイコン１１１の処理性能劣化の問題を解決することが求められている。

ここで、特に、マイコン１１１が上記図１８に示すようなマルチタスク実行を行うものである場合、例えば図２２に示すように、低いレベルのタスク（デフォルトタスク等）を実行中に共有メモリアクセスがあった場合、上記ＷＡＩＴ中に高レベルのタスク（例えば０レベルタスク）の実行タイミングになっても、マイコン１１１がWAIT状態なので、割り込みが受け付けられず、高レベルのタスク（例えば０レベルタスク）の実行に移れない。勿論、図示の通り、ＷＡＩＴ状態が解除されれば、高レベルのタスクを実行できるようになるが、ＷＡＩＴ状態が解除されるまで待たなければならない。このため、応答性能が要求される場合（高レベルタスクは、通常、決められた実行タイミングで実行されることが要求されている）は深刻な問題となる。

また、PLCがネットワーク接続されているなどにより通信処理が頻繁に行われる状況にあって（特に図示しないが、例えばＣＰＵモジュールがＬＡＮに接続しており、ＬＡＮを介して外部の情報処理装置等と頻繁にやりとりする必要がある場合等）、長期間のWAIT状態が発生することは、スループットの低下、バッファアンダーランなどの発生を招く。

以上述べたように、マイコンがアプリケーションプログラム実行上、アクセスタイムの長い低速デバイスへアクセスする場合であっても、マイコンのWAIT状態を解除して他の処理（特に上位レベルのタスクの処理）が行えたり、割込み受付可能な状態にすることが本課題である。

尚、ＰＬＣにおけるアプリケーションプログラムには、例えば図２３に示すようにラダー図のような、順次命令実行を行い、直前の命令実行結果を得て次の命令実行へ移るとい
った“シーケンシャル処理”がある。また、例えば、IEC61131-3で規定されているFBD(Function Block Diagram)やST(Structured Text)言語で表現されるような、ある条件が満足されたらある実行を行うといった“判断処理”もある。

このようにプログラム言語としては、アクセス関数が用途に応じた最適インタフェースを備えていることが望まれる。すなわち、メモリアクセス命令で当てはめると、ラダー図であればメモリアクセスが完了してから、次の命令に実行が移ってほしい。一方、FBDであればメモリアクセスが完了していなくても、とりあえずメモリアクセス要求だけ発しておいて次の命令実行に移り、次のスキャンでメモリアクセスが完了しているかいないか判別して相応の処理が行えればよい。

（課題２）
上記ＦＢＤやＳＴ言語の場合、アプリケーションプログラムには、メモリアクセス命令が、1つだけでなく複数含まれる。それぞれのアクセス命令が実行されるタイミングはプログラム処理の流れによって決定するため、１スキャンで複数の共有メモリアクセス要求が発生し得る。例えば、図２５に示すように、１タスク内に多数のＦＢ（ファンクションブロック）が存在し、図示の１スキャンでＦＢ１〜ＦＢ１００の１００個のＦＢの命令が実行される場合であって、このＦＢ１〜ＦＢ１００全てが共有メモリアクセス要求を発生するものである場合、1スキャンで100個の共有メモリアクセス要求が発生し得る。このような場合であっても、アクセス要求発生順に順次アクセスを実行させることが本課題である。尚、１タスク内の複数の命令を、始めから終わりまで全て実行することを１スキャンと呼んでいる。

（課題３）
図１９に示したように、PLCにはローダ１２０が接続される場合がある。ローダ１２０は、一般的に、アプリケーションの変数モニタや変数の書換え、プログラムダウンロード等を行うために接続される。

アプリケーション実行中に共有メモリ上の変数をモニタしたいといった場合に、ローダ１２０からモニタコマンドが発行され、マイコン１１１がモニタコマンドを受けて、アプリケーションを中断するか又はスキャンエンド（アプリケーションを実行していない状態）で、システムソフトが共有メモリアクセスを行う。

既に述べたように、共有メモリアクセス中にはマイコン１１１にはＷＡＩＴが掛かるので、図２４に示すように、ローダ１２０からのモニタコマンドに応じた共有メモリアクセス中には、アプリケーションは一切実行されない。すなわち、デフォルトタスクは中断されるし、０レベルタスク、１レベルタスクのような定周期タスクの実行タイミングになっても、割込みが受け付けられないため、実行されない。

この様に、ローダ１２０からモニタ要求があると、アプリケーション実行がされない又は実行が遅れるという問題点があり、この様なローダ１２０からの要求に影響されずにアプリケーションを実行できるようにすることが本課題である。

また、上記特許文献１に記載の従来技術は、本例に当て嵌めれば、上記図１９におけるＣＰＵモジュール１１０（マスタに相当）とＩ／Ｏモジュール１０４（スレーブに相当）との間の話であり、Ｉ／Ｏモジュール１０４が、自己に接続している周辺メモリに対する書き込みを行う前に、直ちに、ＣＰＵモジュール１１０へウェイト信号を返信することに相当する技術であり、共有メモリアクセスの話ではない。すなわち、特許文献１では、複数のスレーブが接続されたバスである為、直ちにバスを解放することに意味があるが、共有メモリの場合、アクセスが完了していないのにバスを解放しても意味がない。

更に、特許文献１では、結局、バスを介して、マスタ−スレーブ間でデータ送受信する為の時間が掛かる。また、特許文献１では、上記課題１で述べたようなマルチタスクにおける問題には対応できないし、課題２のような１スキャンで多数のアクセス命令が生じる場合にも対応できない。課題３についても同様である。

本発明の課題は、マイコンが共有メモリ等のアクセスタイムの長いデバイス（低速デバイス）をアクセスする場合に、アクセス実行完了を待たずに、他の処理を実行可能にしたり割込み受付可能な状態にすることであり、特にマイコンが複数レベルのタスクを実行可能な場合にも対応可能とすることであり、又はタスク内で複数ＦＢがアクセス要求を発生させても要求発生順に順次要求が処理されるようにでき、あるいはモニタ要求等のようなＣＰＵモジュール外部（又ＰＬＣ外部）からの要求に起因する低速デバイスアクセスを行っても影響されずにアプリケーションを実行可能にするプログラマブルコントローラのＣＰＵモジュール、当該プログラマブルコントローラ等を提供することである。

本発明のプログラマブルコントローラのＣＰＵモジュールは、複数レベルのタスクを実行する処理ユニットと、該処理ユニットからの要求に応じて低速デバイスにアクセスするインタフェースユニットとを有するＣＰＵモジュールであって、該インタフェースユニットは、前記複数のレベル各々に応じた複数のアクセスチャネルを有し、前記処理ユニットは、前記何れかのレベルのタスクを実行中に前記低速デバイスへのアクセス要求が発生した場合、該タスクのレベルに応じた前記アクセスチャネルに対して低速デバイスアクセス処理の実行を依頼するアクセス処理手段を有し、前記インタフェースユニットは、該アクセスチャネルへの依頼が完了すると、前記処理ユニットのWAIT状態を解除し、その後に、該依頼に基づく前記低速デバイスへのアクセスを実行する。

上記ＣＰＵモジュールにおいては、当該ＣＰＵモジュール外の任意の低速デバイスにアクセスする場合、インタフェースユニットが処理ユニットからの依頼に応じて低速デバイスアクセス処理を実行するが、その際、依頼受付完了した時点で、処理ユニットのWAIT状態を解除する。よって、処理ユニットは他の処理を実行可能となり、割り込みも受付可能となる。

特に、上記構成では、インタフェースユニットは、複数のレベル各々に応じた複数のアクセスチャネルを有している。
これによって、例えば、前記処理ユニットは、前記ＷＡＩＴ状態の解除によって、前記アクセス要求が発生したタスクより上位レベルのタスクの実行が可能となり、前記アクセス処理手段は、該上位レベルのタスクを実行中に前記低速デバイスへのアクセス要求が発生した場合、該タスクのレベルに応じた前記アクセスチャネルに対して低速デバイスアクセス処理の実行を依頼することができる。

また、例えば、前記タスクのアプリケーションがシーケンシャル処理を実行するものである場合、前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い前記アクセスチャネルに対する低速デバイスアクセス処理の実行依頼後、該依頼先のアクセスチャネルに対する定期的なポーリングを行って低速デバイスアクセス処理の実行完了を待つ。

上記シーケンシャル処理を実行するアプリケーションとは、例えばラダー図のように、順次命令実行を行い、直前の命令実行結果を得て次の命令実行へ移るといった処理を行うものである。この場合、直前の命令実行完了しなければ次の命令実行に移れないので、上記ポーリングを行って実行完了を待つことになる。但し、上位レベルのタスクの割り込み
があった場合、当該上位レベルのタスクを実行することはできる。

また、例えば、前記タスクのアプリケーションが判断処理を実行するものである場合、前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い前記アクセスチャネルに対する低速デバイスアクセス処理の実行依頼後、次の命令実行に移る。

上記判断処理を実行するアプリケーションとは、例えばＦＢＤで表現されるアプリケーションのように、前の命令の実行完了を待たずに次の命令に移れるものである。この為、ポーリングを行うことなく、直ちに、アプリケーションに戻り、次の命令を実行可能としている。

但し、判断処理を実行するものである場合、１スキャンで複数の共有メモリアクセス要求が発生し得る。これに対応する為に、例えば以下の構成を追加する。すなわち、例えば、
前記タスクのアプリケーションが判断処理を実行するものである場合、前記処理ユニットは、各レベルに応じた記憶手段を更に有し、前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い低速デバイスアクセス要求が発生する毎に、該要求を該アプリケーションのレベルに対応する前記記憶手段に格納し、前記インタフェースユニット側で低速デバイスアクセス処理が完了する毎に、該記憶手段に記憶されている要求の中で最も古い要求を取り出して、前記インタフェースユニットに対して低速デバイスアクセス処理を依頼する。

また、例えば、前記インタフェースユニットは、システム用アクセスチャネルを更に備え、前記アクセス処理手段は、前記タスクのアプリケーション以外による低速デバイスアクセス要求が発生すると、前記システム用アクセスチャネルに対して低速デバイスアクセス処理を依頼し、前記インタフェースユニットは、該アクセスチャネルへの依頼が完了すると、前記処理ユニットのWAIT状態を解除し、該システム用アクセスチャネルは、低速デバイスアクセス処理が完了すると、前記処理ユニットに対して、アクセス完了割込みを出力する。

上記構成によってタスクのアプリケーション以外に起因するバスアクセス要求の場合にも対応可能となる。更に、依頼後、ポーリングを行う必要が無く、完了割込みで例えばリードデータの取り込み等を行えるので、処理ユニットの処理能力を無駄なく使用できる。

本発明のプログラマブルコントローラのＣＰＵモジュール、当該プログラマブルコントローラ等によれば、マイコンが共有メモリ等のアクセスタイムの長いデバイス（低速デバイス）をアクセスする場合に、アクセス実行完了を待たずに、他の処理を実行可能にしたり割込み受付可能な状態にすることができ、特にマイコンが複数レベルのタスクを実行可能な場合にも対応できる。また、ラダー図用、FBD用等、用途に応じたインタフェース、仕様のアクセス手段の提供を実現できる。更に、タスク内で複数ＦＢがアクセス要求を発生させても要求発生順に順次要求が処理されるようにできる。あるいは、モニタ要求等のようなＣＰＵモジュール外部（又ＰＬＣ外部）からの要求に起因する低速デバイスアクセスを行っても影響されずにアプリケーションを実行可能にできる。

以下、図面を参照して、本発明の実施の形態について説明する。
本例では、例えば一例として、0レベル、1レベル、デフォルトタスクの3レベルのタスクを実行可能なPLCを想定する。

図1に、実施例１、２におけるバスインタフェースの構成例を示す。
また、図２に、本例のプログラマブルコントローラ全体の構成を示しておく。この全体構成自体は従来と同じである。すなわち、複数のＩ／Ｏモジュール４と複数のＣＰＵモジュール１０が、Ｉ／Ｏバス３に接続しており、モジュール相互に通信を行う。また、複数のＣＰＵモジュール１０は、共有メモリバス２にも接続しており、各ＣＰＵモジュール１０各々が、共有メモリバス２を介して共有メモリ１にアクセスする。

また、各ＣＰＵモジュール１０は、マイコン２１、ＲＯＭ２２、ＲＡＭ２３、バスインタフェース１０、Ｉ／Ｏインタフェース２５、ＲＤＹ制御部２６を有する。
Ｉ／Ｏインタフェース２５は、Ｉ／Ｏバス３に接続しており、他のモジュールとの通信制御を行う。バスインタフェース１０は、共有メモリバス２に接続しており、共有メモリ１に対するアクセス制御を行う。

但し、バスインタフェース１０の構成・動作は従来とは異なり、マイコン２１の動作も従来とは異なる。すなわち、簡単に説明するならば、共有メモリ１へのアクセス要求を受け付ける為の、各タスクレベルに対応する複数のアクセスチャネルを、バスインタフェース１０内に備えている。一方、マイコン２１に実装されるシステムソフトは、従来のバスアクセス手順とは違うバスアクセス手順を実行する。本例のバスアクセス手順は、従来のように直接共有メモリ１にアクセスする為の手順ではなく、アクセスチャネルに対するリード／ライトを行う手順であり、一例は図５に示し、後に説明する。

図２に示すように、マイコン２１を中心としてＲＡＭ２３、ＲＯＭ２２、バスインタフェース１０、Ｉ／Ｏインタフェース２５、ＲＤＹ制御部２６の各ブロックでＣＰＵモジュール２０が構成される。複数のＣＰＵモジュール２０からアクセスが可能な共有メモリ１が共有メモリバス２上に存在し、共有メモリ１を本実施例における低速デバイスと位置付ける。

尚、ＲＤＹ制御部２６は、図示していないが、バスインタフェース１０だけでなく他の構成（Ｉ／Ｏインタフェース２５等）からのＲＤＹ信号を集中管理制御する構成であるが、本説明では特に関係ないので、ＲＤＹ制御部２６については特に触れずに、マイコン２１−バスインタフェース１０間で直接ＲＤＹ信号をやりとりするものと見做して説明するものとする。

ここで、図１に示すバスインタフェース１０について説明する。バスインタフェース１０は、アクセスチャネルを、ＰＬＣで実行可能なアプリケーションタスクレベル数分備えるようにする。本例では、上記の通り、3レベルのタスクを実行可能なＰＬＣを例にしているので、図１に示すように、バスインタフェース１０は、レベル０用、レベル１用、デフォルトタスク用の３つのアクセスチャネル１１、１２，１３を備える。これら各アクセスチャネルは、マイコン２１から読み書きできるレジスタ群を備える。１つのアクセスチャネルは１度に１つのアクセス要求のみ受け付けられるものとする。よって、同レベルのタスクの要求は、前の要求が完了するまで受け付けられない。

図示の例では、各アクセスチャネルは、各々、５つのレジスタを有する。ここではレベル０用アクセスチャネル１１を例にすると、コマンドレジスタａ、アクセスアドレスレジスタｂ、ライトデータレジスタｃ、リードデータレジスタｄ、及びステータスレジスタｅの５本のレジスタを備える。他のアクセスチャネル１２，１３も同じ構成である。よって、バスインタフェース１０は、３チャネル分合計１５本のレジスタを持つ。

マイコン２１が上記アクセスチャネルにアクセス要求を書き込むと、以後、バスインタフェース１０側が、マイコン２１とは独立してバスアクセス（共有メモリアクセス）を実
行する。すなわち、アクセス要求が書き込まれたアクセスチャネルは、その要求コマンド等をアクセス要求キュー１４に積む。バスアクセス制御部１５は、アクセス要求キュー１４から要求コマンドを取り出して共有メモリ１へのアクセス実行を開始する。このアクセス実行が完了したら、要求発行元のアクセスチャネル内のステータスレジスタｅの完了ビットがセットされる。

アクセス実行中に新たに別なアクセスチャネルへアクセス要求が書き込まれた場合、その要求コマンド等はアクセス要求キュー１４に積まれる。前のアクセス完了後、順次キュー１４に積まれている次のアクセス要求が実行される。このようにして共有メモリへのアクセスが間断なく行われる。

アクセスチャネルは、具体的には、例えば、ゲートアレイ、ＰＬＤ（Programmable Logic Device）等で実現されるディジタル回路である。
以下、更に詳しく説明する。

低いレベルのアプリケーションタスクからの要求に応じた共有メモリアクセス中に、マイコン２１側で上位レベルタスクによる割り込みが発生し、この上位レベルのアプリケーションタスクを実行中に共有メモリアクセス要求が発生する場合に備えて、上記の通りバスインタフェース１０内に、アプリケーションタスクのレベル数と同じ数（ここでは３つ）のアクセスチャネルを用意している。但し、上位レベルのタスクの要求を優先的に処理するわけではない。しかし、例えば、デフォルトタスクがアクセス要求を出し、その後に実行されたレベル１タスクもアクセス要求を出した後、レベル０タスクが実行される場合、レベル０タスクは待たされることなく直ちに実行される。レベルが高いタスクほど、定周期性を崩さずに決められたタイミングで実行することが要求されるので、この点で効果がある。

マイコン２１は、例えば、レベル０のタスクからの共有メモリアクセス要求は、レベル０用アクセスチャネル１１にアクセスを依頼し、レベル１のタスクからの共有メモリアクセス要求は、レベル１用アクセスチャネル１２にアクセスを依頼する。

このようにアクセスチャネルを介して共有メモリアクセスを行った場合には、ダイレクトに共有メモリアクセスをする場合に比較して、アクセスチャネルへの要求書き込み等に余計な時間が掛かるが、もともとバスアクセス制御部１５による共有メモリアクセスの時間が長いため、全体としてアクセス完了までに掛かる時間は、若干増加するに過ぎない。その引き換えに、アクセス完了までの長い時間、マイコン２１は別の処理（例えば上位のタスク。あるいは同タスクにおける他の命令）を実行することができる。割り込みも問題なく受け付けられる。

図３にこれら各種レジスタのレジスタマップを示す。図３に示す通り、バスインタフェース１０が有する不図示のメモリ内の各アドレスが、上記各種レジスタとして割り当てられている。マイコン２１は、このレジスタマップを記憶している。そして、例えばレベル１のタスク実行で共有メモリ１へのリード／ライト要求が発生した場合には、例えばアドレスバスには図示のアドレス“＋６”を出力し、データバスには共有メモリ１へのアクセスアドレスを出力することで、アクセスチャネル１２のアクセスアドレスレジスタｂに、共有メモリ１へのアクセスアドレスをセットする。

図４に上記各種レジスタの構成例を示す。
図４に示す通り、コマンドレジスタａは、リードアクセス要求ビット、ライトアクセス要求ビットの２ビットのみ使用する。例えば、リードアクセス要求があった場合にはリードアクセス要求ビットが‘１’となり、ライトアクセス要求があった場合にはライトアク
セス要求ビットが‘１’となる。

アクセスアドレスレジスタｂには、上記の通り、マイコン２１が指定した共有メモリ１へのアクセスアドレスがセットされる。リードデータレジスタｃには、リードアクセス要求に対して共有メモリ１から読み出されたリードデータが格納される。ライトデータレジスタｄには、ライトアクセス要求に伴いマイコン２１が出力した、共有メモリ１への書き込みデータが格納される。

ステータスレジスタｅは、アクセス完了／未完了を表す１ビット（完了ビット）のみ使用する。ここでは、この完了ビットが‘０’の場合はアクセス未完了、完了ビットが‘１’の場合はアクセス完了を示すものとする。マイコン２１から任意のアクセス要求を受けると完了ビットを‘０’にリセットし、この要求に対する応答をバスアクセス制御部１５から受けると、完了ビットを‘１’にセットする。

ここで、図１の構成の動作について説明する。
上記各アクセスチャネル１１〜１３は、上記の通り、アクセス要求が書き込まれると、その要求コマンド等をアクセス要求キュー１４に積む。ここで、マイコン２１が書き込む上記アクセス要求には、リードアクセス要求かライトアクセス要求かを示す上記要求コマンド、共有メモリ１へのアクセスアドレスが含まれ、更にライトアクセス要求である場合には共有メモリ１への書き込みデータも含まれる。上記要求コマンドはコマンドレジスタａにセットされ、アクセスアドレスはアクセスアドレスレジスタｂに格納され、書き込みデータはライトデータレジスタｃに格納される。

そして、上記アクセス要求が書き込まれたアクセスチャネルは、上記要求コマンドと自己の識別情報（レベル０、レベル１、デフォルトの何れであるかを示す情報。予め各アクセスチャネル内に記憶されている）とを（以下、これらをまとめてアクセス要求データと呼ぶ）、アクセス要求キュー１４に格納する。アクセス要求キュー１４は、FIFO(Fast In
Fast Out)構造となっている。よって、要求発生順にアクセスの実行がなされる。

バスアクセス制御部１５は、任意のアクセス要求に応じた共有メモリ１へのリードアクセス処理又はライトアクセス処理を完了する毎に、アクセス要求キュー１４から新たなアクセス要求データを取り出す。その際、上記識別情報は、そのまま、アドレスセレクタ１７、ライトデータセレクタ１８、及びチャネルセレクタ１９に入力され、これらセレクタの選択信号となる。つまり、これら各セレクタは、この識別情報に対応するアクセスチャネルを選択する。よって、バスアクセス制御部１５は、これらセレクタを介して、要求元のアクセスチャネルのレジスタからのデータ取得又レジスタへのデータ書き込みを行うことになる。

すなわち、バスアクセス制御部１５は、リード／ライト要求何れの場合でも、アドレスセレクタ１７を介して、要求元のアクセスチャネルのアクセスアドレスレジスタｂに格納されているデータを読み出す。ライト要求である場合には、更に、ライトデータセレクタ１８を介して、要求元のアクセスチャネルのライトデータレジスタｃに格納されているデータを読み出す。そして、これら取り出した要求コマンド、読み出したデータに基づいて、共有メモリ１に対するアクセス処理を実行する。そして、アクセス処理完了したら、チャネルセレクタ１９を介して、要求元のアクセスチャネルに処理結果を書き込む。リード要求の場合は、処理結果として得られたリードデータをリードデータレジスタｄに格納すると共に、ステータスレジスタｅの上記完了ビットを‘１’にセットする。ライト要求の場合は、ステータスレジスタｅの上記完了ビットを‘１’にセットする。

そして、バスアクセス制御部１５は、アクセス要求キュー１４から次のアクセス要求デ
ータを取り出して、上記と同様の処理を実行する。
尚、上記処理は一例を示しているに過ぎない。例えば、バスアクセス制御部１５は、アクセス要求キュー１４からアクセス要求データを取り出して、コマンドと識別情報の両方を取得し、識別情報に基づいて上記各セレクタを制御するようにしてもよい。

上記の通り、マイコン２１が、アクセスチャネルの各レジスタにデータを格納させるが、これについて図５を参照して説明する。図５は、リード要求の場合のアクセスタイミングチャートである。

まず、図１に示す通り、“内部制御信号とＲＤＹ生成部”１６は、アドレスバスに接続しており、マイコン２１から出力される任意のアドレスを入力している。このアドレスは、上述してある通り、任意のアクセスチャネルの任意のレジスタのアドレスであり、共有メモリ１へのアクセスアドレスとは異なるものである。また、“内部制御信号とＲＤＹ生成部”１６には、マイコン２１から出力されるセレクト信号（＊ＣＳ）とリード／ライト信号（ＲＤ／＊ＷＴ）が入力している。

“内部制御信号とＲＤＹ生成部”１６は、セレクト信号（＊ＣＳ）が有効（‘Ｌ’）且つリード／ライト信号（ＲＤ／＊ＷＴ）が‘０’のときには、上記アドレスのレジスタに、データバスを介して入力されるデータを書き込む。“内部制御信号とＲＤＹ生成部”１６は、セレクト信号（＊ＣＳ）が有効（‘Ｌ’）且つリード／ライト信号（ＲＤ／＊ＷＴ）が‘１’のときには、上記アドレスのレジスタに格納されているデータを、データバスを介してマイコン２１に出力する。つまり、リード／ライト信号（ＲＤ／＊ＷＴ）が‘０’はライト、‘１’はリードを意味する。尚、マイコン２１側は、アドレスバスに出力するアドレスが、上記レジスタａ〜ｄの何れかのアドレスであるときには、セレクト信号（＊ＣＳ）を有効（‘Ｌ’）にする。

また、“内部制御信号とＲＤＹ生成部”１６は、マイコン２１からの指示に応じた上記レジスタへのアクセスが完了する毎に、マイコン２１に対してＲＤＹ信号“Ｈ”を送信する。レジスタへのリード／ライトだけなので、ＲＤＹ信号“Ｈ”は短時間でマイコンに返信されることになる。

図５に示す例は上記の通りリード要求の場合なので、マイコン２１において図６の処理を実行するシステムソフトは、まず、アクセスアドレスレジスタｂのアドレスをアドレスバスに出力すると共に、データバスには共有メモリ１に対するアクセスアドレスを出力する。勿論、その際、マイコン２１は、セレクト信号（＊ＣＳ）を有効（‘Ｌ’）にし且つリード／ライト信号（ＲＤ／＊ＷＴ）を‘０’にする。これより、“内部制御信号とＲＤＹ生成部”１６は、アクセスアドレスレジスタへの書き込み制御を行う。そして、ＲＤＹ信号‘Ｈ’を返す。

更に続いて、マイコン２１は、コマンドレジスタａのアドレスをアドレスバスに出力すると共に、データバスにはリードアクセス要求であることを示す要求コマンドを出力する。リード／ライト信号（ＲＤ／＊ＷＴ）が‘０’なので、“内部制御信号とＲＤＹ生成部”１６は、コマンドレジスタａへの書き込み制御を行う。そして、ＲＤＹ信号‘Ｈ’を返す。

その後は、アクセス要求キュー１４に従って、順番が来れば、バスアクセス制御部１５は、共有メモリ１に対するリード動作制御を行う。そしてリード完了したら、要求発行元のアクセスチャネルのリードデータレジスタｄに、共有メモリ１から読み出したリードデータを格納すると共に、ステータスレジスタに“アクセス完了”をセットする（上記“完了ビット”が‘１’となる）。

システムソフトは、コマンドレジスタａへの要求コマンド書込み後は、ステータスレジスタｅの“完了ビット”をポーリングしている。すなわち、図５に示す通り、定期的に、アドレスバスにステータスレジスタｅのアドレスを出力し、リード／ライト信号（ＲＤ／＊ＷＴ）は‘１’（リード要求）とすることで、ステータスレジスタｅのデータを読み出す。当然、共有メモリ１へのアクセスが完了するまでは、完了ビットは‘０’（未完了）となっている。勿論、その都度、直ちにＲＤＹ信号‘Ｈ’を返すので（ＷＡＩＴ状態を解除するので）、マイコン２１の待ち時間は非常に短くて済む。そして、図５の図上右側に示すように、ステータスレジスタｅの完了ビットが‘１’にセットされた後にこれを読み出したら、マイコン２１はアクセス完了を知るので、図５には示していないが、アドレスバスにリードデータレジスタｄのアドレスを出力し、リード／ライト信号（ＲＤ／＊ＷＴ）は‘１’（リード要求）とすることで、共有メモリ１からのリードデータを取得する。以上により共有メモリリードシーケンスが完了する。

共有メモリ１へのライト要求の場合は、上記アクセスアドレスライト後にライトデータレジスタｃに共有メモリ１への書き込みデータをセットし、コマンドレジスタａにはライト要求を示す要求コマンドを書き込む。

マイコン２１は、その後、リード要求の場合と同様に、アクセス完了までステータスレジスタｅをポーリングしながら待つ。勿論、その間、上位タスクの割り込みが入った場合には、上位タスクの処理が実行されるので、ポーリングは中断される。上位タスクの処理が完了したら、ポーリングを再開することになる。

ここで、ＰＬＣにおけるアプリケーションプログラム例としては、図２３に示すラダー図のような、順次命令実行を行い、直前の命令実行結果を得て次の命令実行へ移るといったシーケンシャル処理がある。あるいは、図８に示すようなＦＢＤでのアプリケーション命令もある。

まず、以下、ラダー図の場合における上記システムソフトの処理について説明する。ここでは、図２３に示す例を用いて、まず接点命令を実行し、次にコイル命令を実行する場合の処理について説明する。

マイコン２１においてアプリケーションは、図示の各命令を実行し共有メモリ１へのアクセスが必要になると、上記システムソフトを呼び出す。
システムソフトは、共有メモリ１に対するリード処理の場合には図６の処理を実行し、ライト処理の場合には図７の処理を実行する。すなわち、従来で説明したように、システムソフトは、アプリケーションが呼び出すサブルーチンのような存在であるが、このサブルーチンは複数種類存在し、リード処理の場合は図６の処理を実行するサブルーチンが呼び出され、ライト処理の場合は図７の処理を実行するサブルーチンが呼び出されることになる。これは後述する他の処理フローチャート図の処理についても同様である。

ここでは、接点命令に係る処理がリード処理、コイル命令に係る処理がライト処理であるものとする。
図６、図７に示す処理は、既に図５の説明で触れているので、ここでは簡単に説明する。

図６に示す処理は、共有メモリからのデータリード要求の処理であり、図７に示す処理は、共有メモリへのデータライト要求の処理である。
図６に示す処理おいて、まず、接点命令のレベルに応じたアクセスチャネルのアクセスアドレスレジスタｂに、共有メモリ１へのアクセスアドレスを書き込む処理（ステップＳ
１１）、及びコマンドレジスタａのリードアクセス要求ビットを‘１’にセットする処理（ステップＳ１２）を実行する。そして、その後は、上記ポーリングを行う。すなわち、定期的に上記要求を書き込んだアクセスチャネルのステータスレジスタｅをリードし（ステップＳ１３）、完了ビットが‘１’（完了）であれば（ステップＳ１４，ＹＥＳ）、このアクセスチャネルのリードデータレジスタｄからデータを読出し、これをアプリケーションに渡す（ステップＳ１５）。これを受けたアプリケーションは、続いてコイル命令を実行する。これによって、図７の処理が実行される。尚、共有メモリからのリードデータは、コイル命令の入力値となる。従って、接点命令の実行が完了するまでは、コイル命令は実行できない。

図７の処理では、まず、コイル命令のレベルに応じたアクセスチャネルに対して、そのアクセスアドレスレジスタｂに共有メモリへのアクセスアドレスを書き込む処理（ステップＳ２１）、そのライトデータレジスタｃに共有メモリへの書き込みデータを格納する処理（ステップＳ２２）、及びそのコマンドレジスタのライトアクセス要求ビットを‘１’にセットする処理（ステップＳ２３）を実行する。

そして、その後は、上記ポーリングを行う。すなわち、定期的に上記アクセスチャネルのステータスレジスタｅをリードし（ステップＳ２４）、完了ビットが‘１’（完了）であれば（ステップＳ２５，ＹＥＳ）、アプリケーションに完了を知らせ、アプリケーションに戻る。

尚、上記説明では、「接点命令のレベルに応じた」、「コイル命令のレベルに応じた」と記したが、図２３に示す例において接点命令とコイル命令とでレベルが異なるわけではない。同一タスク内の一連の命令全てが、同じレベルである。これは、ＦＢＤの場合も同じであり、例えば図２５に示す１タスク内の全ての命令（ＦＢ）は、同じレベルである（このタスクのレベルである）。

上記図６、図７で説明した処理では、アクセスチャネルに対して要求を出した後、アプリケーションに戻らずにシステムソフトの処理を続行する（ポーリングを繰返す）。よって、リード要求であればリードデータを共有メモリ１から得るまで、ライト要求であれば共有メモリ１へのデータライト完了までは、ラダー図の後続命令の実行には移らない。上記の通り、ラダー図は、順次命令実行を行い、直前の命令実行結果を得て次の命令実行へ移るといったシーケンシャル処理であるからである。よって、コイル命令、接点命令ともにシステムソフト層でポーリングを行い、アクセス完了でアプリケーションに戻るようにしている。但し、割込みは受付可能なので、上記のように、より高いレベルのタスクへの遷移は可能である。

図８（ａ）、（ｂ）に、ＦＢＤで表現されるアプリケーション命令の具体例を示す。
尚、FBの基本概念は国際規格IEC61131-3で規定、説明されている。
図８（ａ）にはREAD_WORD(リード用FB)、図８（ｂ）にはWRITE_WORD(ライト用FB)の例を示す。尚、図８に示す表記は単にIEC61131-3によるものであり、この例に限るわけではない。

図８（ａ）に示す命令（READ_WORD）は、入力端子にRQ（アクセス要求）、AD（アクセスアドレス）を備え、出力端子にDONE(完了)、RD(読出しデータ)を備える。DONEが‘１’になると、後段の命令は、本命令（READ_WORD）の実行完了を知り、新たに取得してデータ（共有メモリリードデータ）を用いて命令実行する。

また入力端子から入力されるデータ、出力端子からの出力データ情報、内部状態情報(EXビット、XRQビット、E_DONEビット)は、1つのＦＢに1つ割り付けられるインスタンスと
呼ばれるメモリ領域に、格納・保持される。

また、図８（ｂ）に示す命令（WRITE_WORD）は、入力端子にRQ（アクセス要求）、AD（アクセスアドレス）、WD(ライトデータ)、出力端子にDONE(完了)を備える。
図８（ａ）、（ｂ）において、AD（アクセスアドレス）に共有メモリへのアクセスアドレスが入力された場合に、本処理が実行されることになる。

図９（ａ）に、実施例１におけるREAD_WORDのインスタンスのデータ構造を示す。
図示のインスタンス８０において、EXビット８１はアクセス実行中を示すビットである。XRQビット８２はRQ端子に前スキャン時に入力された値、ＲＱビット８３はRQ端子に今回スキャン時に入力された値であり、XRQビット８２が‘０’で且つＲＱビット８３が‘１’の場合、「新要求あり」と判定される（後述するステップＳ９７の判定がＹＥＳとなる）。DONEビット８４は上記DONE端子の出力データであり、‘１’が完了、‘０’が未完了を意味する。

また、アドレス下位８５及びアドレス上位８６には、共有メモリ１へのアクセスアドレスが格納される。リードデータ下位８７及びリードデータ上位８８には、共有メモリ１から読み出されたデータが格納される。図示の通り、当該インスタンス８０の先頭アドレスから、それぞれ、＋２、＋３、＋４、＋５のアドレスに、上記アドレス下位８５、アドレス上位８６、リードデータ下位８７、リードデータ上位８８が格納される。

図９（ｂ）に、上記READ_WORDが呼び出すシステムソフトの処理フローチャート図を示す。
図９において、まず、DONEビットをクリアする（未完了とする）（ステップＳ９１）。そして、アクセス実行中であるか否かを判定する（ステップＳ９２）。これは、上記呼び出し元のREAD_WORDのインスタンス８０を参照し、ＥＸビット８１＝‘１’であればアクセス実行中と判定する。

もし、アクセス実行中であれば（ステップＳ９２，ＹＥＳ）、当該READ_WORDのレベルに対応するアクセスチャネルのステータスレジスタｅをリードし（ステップＳ９３）、その完了ビットが‘１’（完了）であれば（ステップＳ９４，ＹＥＳ）、上記アクセスチャネルのリードデータレジスタｄからデータを読出し、これをインスタンス８０の上記＋４、＋５のアドレス（リードデータ下位８７、リードデータ上位８８）に格納する（ステップＳ９５）。

そして、ＥＸビット８１をクリアし（１→０）、DONEビット８４をセット（０→１）する（ステップＳ９６）。そして、ステップＳ１０１へ進む。アクセス実行中で且つ未完了であれば（ステップＳ９４，ＮＯ）、そのままステップＳ１０１へ進む。

ステップＳ１０１では、ＲＱビット８３の値をＸＲＱビット８２にコピーする。これで本処理は終了し、アプリケーションに戻る
一方、ＥＸビット＝‘０’である場合には（アクセス実行なし）（ステップＳ９２，ＮＯ）、このREAD_WORDに新たなアクセス要求が発生しているか否かを判定する。これは、上記の通り、XRQビット８２が‘０’で且つＲＱビット８３が‘１’の場合、すなわちＲＱが０から１へと立ち上がった場合に、「新要求あり」と判定される（ステップＳ９７，ＹＥＳ）。「新要求あり」の場合には、まず、インスタンス８０の上記＋２、＋３のアドレスに格納されているデータ（アドレス下位８５、アドレス上位８６）と要求コマンド（リードｏｒライト）を、それぞれ、当該READ_WORDのレベルに対応するアクセスチャネルのアクセスアドレスレジスタｂとコマンドレジスタａにセットする（ステップＳ９８，Ｓ９９）。そして、ＥＸビット８１をセット（０→１）し（ステップＳ１００）、ステップ
Ｓ１０１へ進む。尚、アクセスチャネルは、コマンドレジスタａに要求コマンドがセットされたことをトリガとして、上記要求コマンドと識別情報をアクセス要求キュー１４に格納する動作を行う回路構成となっている。

新要求がない場合には（ステップＳ９７，ＮＯ）、そのままステップＳ１０１へ進む。
図１０に、上記図９の処理のアクセスタイミングチャートを示す。
尚、図１０において図上縦の点線は、処理の実行周期を示す。すなわち、縦の点線で示すタイミング毎に、図９の処理が実行される。

ここでは、アクセス実行中ではないものとし、図上左側に示すように、ＲＱの立ち上がり（０→１）を検出することによって（ステップＳ９７，ＹＥＳ）、アクセスチャネルに対して新規要求を出すことになる。すなわち、上記ステップＳ９８，Ｓ９９の処理により、アクセスチャネルのレジスタに、アドレスと要求コマンドを書き込む。更に、ステップＳ１００によって、ＥＸビット（ＥＸフラグ）がセットされる。

アクセスチャネルは、コマンドレジスタａに要求コマンドがセットされると、上記の通り、この要求コマンド等をアクセス要求キュー１４に格納し、これによってその後、共有メモリ１へのアクセス動作（ここではリード）が開始されることになる。そして、アクセス完了すると、アクセスチャネルの上記完了ビットを‘１’にする。これによって、図１０の図上右側に示す通り、次の図９の処理実行時に、リードデータの読出し、ＥＸフラグのクリア、ＤＯＮＥビットのセット（ステップＳ９５，Ｓ９６）が行われる。図１０に示す通り、ＤＯＮＥビットは、更に次の図９の処理実行により（そのステップＳ９１の処理により）クリアされるまでの間、セットされており、その間に、アプリケーションは、ＤＯＮＥビット＝１であることからリード完了を認識し、リードデータ（８７，８８）を使用する。

尚、図８（ｂ）に示すWRITE_WORDが呼び出すシステムソフトの処理は、特に図示しないが、図９（ａ）に示すインスタンスにおいて、アドレス＋４、＋５の位置に、リードデータ下位８７及びリードデータ上位８８に代えて、ライトデータ下位、上位が格納されることになり、更に、図９（ｂ）に示すフローチャートにおいてステップＳ９８の処理の後に「インスタンスの＋４、＋５に格納されているライトデータ（下位と上位）を、アクセスチャネルのライトデータレジスタへセットする」という処理が追加される。更に、ステップＳ９５の処理は必要ないので削除される。

上記図９等の処理では、図６、図７の処理とは異なり、要求を出した後、ポーリングは行わずに、直ちにアプリケーションに戻る。これは、上述してある通り、FBDやST言語で表現されるプログラムでは、メモリアクセスが完了していなくても、とりあえずメモリアクセス要求だけ発しておいて次の命令実行に移り、次のスキャン以降の各スキャンでメモリアクセスが完了しているかいないか判別すればよいからである。接点命令、コイル命令が共有メモリアクセス中は同レベル以下のタスクの命令実行ができなかったのに比べ、アクセス完了までの時間も余すことなく全レベルのタスク実行が可能である。

尚、“次の命令実行”とは、例えば図２５においてＦＢ１がメモリアクセス要求を発したなら、メモリアクセスが完了していなくても、ＦＢ２を実行することを意味している。但し、ＦＢ１の後段の命令であるＦＢ１０１も、メモリアクセスが完了しなくてもＦＢ１のアクセス前の出力を用いて命令実行してよい仕様となっている場合には、メモリアクセスが完了していなくても、ＦＢ１０１を実行できる。

また、図２５に示すタスクの各命令（ＦＢ）を実行中に、不図示の上位タスクの割り込みが入った場合には、この上位タスクを実行することになるので、その間、図２５に示す
タスクの命令実行は中断される。

ところで、ここで、上記一例のようにＦＢ１に関してメモリアクセスが完了していない状態でＦＢ２を実行した場合において、ＦＢ２でもメモリアクセス要求が発生する可能性はある。ＦＢ１とＦＢ２は同一タスクなので、当然、レベルは同じであり、要求先のアクセスチャネルは同じであるので、ＦＢ２の要求を受けられないことになる。特に、１タスク内で実行される順番は、ＦＢ１→ＦＢ２→・・・ＦＢ１００というように決まっている為、ＦＢ１の要求が最優先で受け付けられてしまう為、ＦＢ２以降の他のＦＢはなかなか要求が受け付けられず、特に最後のＦＢ１００は、殆ど要求が受け付けられないという事態に成り得る。これが上記課題２に係る問題点となる。従って、要求発生順に、順番に、要求が受け付けられるようにする必要がある。

この問題に対して、実施例２を提案する。
以下、実施例２について説明する。実施例２は、上記課題２を解決するものである。
課題２で述べたように（及び上記の通り）、FBDやST言語で表現されるプログラムでは、1タスク内で複数個のアクセス要求発生が起こり得るため、実施例２では、これに対応して、マイコン側２１側に、共有メモリアクセス要求を格納するための要求バッファを備えている。要求バッファは、アプリケーションのタスクレベル数分用意する。

図１２（ａ）に、実施例２におけるREAD_WORDのインスタンスのデータ構造を示す。図示のインスタンス４０において、EXビット４１はアクセス実行中を示すビット、XRQビット４２はRQ端子に前スキャン時に入力された値、E_DONE４４はアクセスチャネルのアクセス完了/未完了を示すビットである（ＯＮ（‘１’）で完了）。また、DONEビット４５は上記DONE端子の出力データである。ＲＱビット４３はRQ端子に今回スキャン時に入力された値であり、XRQビット４２が‘０’で且つＲＱビット４３が‘１’の場合、「新規要求あり」と判定される。

また、アドレス下位４６及びアドレス上位４７には、共有メモリへのアクセスアドレスが格納される。リードデータ下位４８及びリードデータ上位４９には、共有メモリから読み出されたデータが格納される。

また、図１５（ａ）に、実施例２におけるWRITE_WORDのインスタンス６０のデータ構造を示す。図示の通り、EXビット４１〜アドレス上位４７までは上記READ_WORDのインスタンス４０と同じであるので、同一符号を付してある。インスタンス６０には、上記リードデータ下位４８及びリードデータ上位４９の代わりに、ライトデータ下位６１及びライトデータ上位６２がある。

図１２（ｂ）に、要求バッファの一例を示す。
図１２（ｂ）に示す要求バッファ５０は、１タスク内のインスタンスの数（つまり、ＦＢの数；尚、要求バッファ５０は、リード、ライト共通で使用される）の分だけ要求キューを格納できる記憶容量を持ち（図示の例では、Ｎ個のＦＢがあり、要求キュー１〜要求キューＮまでのＮ個の要求キューを格納可能）、リングバッファ状に使用される。各要求キューは、要求元ＦＢのインスタンスの先頭アドレス５１と要求コマンドデータ５２から成る。要求コマンドデータ５２のデータフォーマットは、上記アクセスチャネル内のコマンドレジスタａと同じである（要求キューから読み出して、そのまま、コマンドレジスタａに書き込めるようにする為）。

図示のリードポインタＲｐ又はライトポインタＷｐによって、現在の処理対象である要求キューが指定される。リードポインタＲｐはアクセスチャネルへの要求を発行するためのポインタ、ライトポインタＷｐはFBの内部処理でアクセス要求を積むときに使用する。

ソフトウェア処理として、共有メモリアクセスするＦＢの内部処理（このＦＢが呼び出すシステムソフト）によって、アクセスチャネルの完了／未完了処理、新たなアクセス要求のキューへの積み上げ、アクセスチャネルへの要求発行を行わせるようにする。

図１１に、上記ＦＢ（READ_WORD）が呼び出すシステムソフトの処理フローチャートを示す。また、図１１に示すステップＳ３２の詳細フローを図１３に示し、ステップＳ３６の詳細フローを図１４に示す。

以下、図１１の処理について、その詳細フローも参照して説明する。
尚、以下の説明におけるアクセスチャネルは、当然、上記ＦＢ（READ_WORD）のレベルに応じたアクセスチャネルである。但し、上記の通り、同一タスク内の全てのＦＢのレベルは同じである。

図１１において、まず、DONEビットをクリアする（未完了とする）（ステップＳ３１）。そして、アクセスチャネルに対して、現在の状況を確認する処理を行う（ステップＳ３２）。ステップＳ３２の詳細フローは図１３に示す。

図１３において、まず、アクセスチャネルのステータスレジスタｅをリードし（ステップＳ５１）、現在の完了ビットの状態が“未完了”である場合には（ステップＳ５２，ＮＯ）、現在、全く要求が無い状態であるか、又は何等かの要求に対する処理を実行中であることになるので、アクセスチャネルのコマンドレジスタａをリードして確認する（ステップＳ６０）。その結果、もし、上記リードアクセス要求ビット、ライトアクセス要求ビットの何等かが‘１’であれば（ステップＳ６１，ＹＥＳ）、変数BUSYに‘１’をセットする（ステップＳ６２）。一方、アクセスチャネルが現在何も要求を受け付けていない状態であれば（ステップＳ６１，ＮＯ）、そのままステップＳ５９に進み、変数BUSYに‘０’をセットする。

一方、ステータスレジスタｅの完了ビットが示す状態が“完了”である場合には（ステップＳ５２，ＹＥＳ）、上記リードポインタRpが現在指している位置の要求キューから、要求元のインスタンスの先頭アドレス５１と要求コマンドデータ５２とを読出す（ステップＳ５３，Ｓ５４）。つまり、現在アクセスチャネルに依頼しているアクセス要求の要求元ＦＢのインスタンスの特定と、要求コマンドが”リード”なのか”ライト”なのか判別する。尚、本処理の呼び出し元ＦＢ（以下、自ＦＢ又は自インスタンスと呼ぶ）がアクセス要求元ＦＢとは限らない。例えば、上記例において、仮に、ＦＢ１の実行に伴って本処理が呼び出され、現在の要求元がＦＢ２であった場合、ステップＳ５６，Ｓ５７の処理は、ＦＢ２のインスタンスに対して行われることになる。

要求コマンドがリードであれば（ステップＳ５５，ＹＥＳ）、アクセスチャネルのリードデータレジスタｄからデータを読出し、これを要求元ＦＢのインスタンスの先頭アドレスから＋４、＋５の領域（リードデータ下位４８、リードデータ上位４９）に格納する（ステップＳ５６）。そして、ステップＳ５７に進む。一方、要求コマンドがライトであれば（ステップＳ５５，ＮＯ）、そのままステップＳ５７に進む。

ステップＳ５７では、要求元ＦＢのインスタンス４０のE_DONEビット４４をＯＮする。更に、アクセスチャネルの完了ビットをクリアする（ステップＳ５８）。そして、変数BUSYに‘０’をセットし（ステップＳ５９）、本処理は終了し、図１１のステップＳ３３の処理に進む。

ステップＳ３３では、アクセス実行中であるか否かを判定する。これは、上記自インス
タンスのＥＸビット４１を参照し、ＥＸビット＝‘１’であればアクセス実行中と判定する。アクセス実行中の場合（ステップＳ３３，ＹＥＳ）、続いて、自インスタンスのE_DONEビット４４が‘１’（ＯＮ）であるか否かを判定する（ステップＳ３４）。上記の通り、ステップＳ５７の処理でE_DONEビット４４がＯＮされるが、上述してある通り、これは自ＦＢによる処理でＯＮされるとは限らず、他ＦＢによる処理でＯＮされる場合もあり得る。

E_DONEビット４４＝‘１’であれば（ステップＳ３４，ＹＥＳ）、自インスタンスのＥＸビット４１をクリアし（１→０）、DONEビット４５をセットし（０→１）、E_DONEビット４４はクリアする（１→０）（ステップＳ３５）。そして、ステップＳ３６へ進む。自ＦＢが要求したアクセス実行中で且つ未完了であれば（ステップＳ３４，ＮＯ）、そのままステップＳ３６へ進む。

一方、自インスタンスのＥＸビット＝‘０’であれば（アクセス実行なし）（ステップＳ３３，ＮＯ）、この自ＦＢのインスタンスに新たなアクセス要求が発生していれば、要求を出してよい状態である。よって、自インスタンスのＸＲＱビット４２とＲＱビット４３をチェックし、新要求がある場合には（ステップＳ３８，ＹＥＳ）、当該インスタンスの先頭アドレスと要求コマンドデータ（リード）とを、上記ライトポインタＷｐが示す位置の要求キューにセットする（ステップＳ３９，Ｓ４０）。自インスタンスの先頭アドレスを積むのは、インスタンスが個々のＦＢに与えられた一意なものだからである。但し、先頭アドレスを用いるのは一例であり、例えば、PLCシステムによりIDが別途存在するならばそれを使用してもかまわない。

そして、ライトポインタＷｐの位置を１つ進める（ステップＳ４１）。最後に、自インスタンスのＥＸビット４１をセットし（０→１）（ステップＳ４２）、ステップＳ３６へ進む。新要求がない場合には（ステップＳ３８，ＮＯ）、そのままステップＳ３６へ進む。

ステップＳ３６の処理の詳細フローを図１４に示す。
まず、リードポインタRpとライトポインタＷｐを参照し（ステップＳ７１）、リードポインタRpの位置とライトポインタＷｐの位置が同じであれば（ステップＳ７２，ＹＥＳ）、未処理の要求は無いことになるので（当然、ＲｐとＷｐの初期位置は同じにしてある）、アクセスチャネルに対する新規要求発行は行わずに、本処理を終了する。これは、変数BUSYが‘１’である場合（Rpが指す位置の要求キューに対する処理をバスインタフェース側で実行中である場合）（ステップＳ７３，ＹＥＳ）も同様である。

要求バッファ５０に未処理の要求があり（ステップＳ７２、ＮＯ）且つ変数BUSYが‘０’である場合（ステップＳ７３，ＮＯ）には、バスインタフェースへの新規要求発行処理を行う。すなわち、まず、Rpが指す位置の要求キューから、要求元のインスタンス（自インスタンスとは限らない）の先頭アドレス５１と要求コマンドデータ５２を取得する（ステップＳ７４）。そして、取得した要求元インスタンスの先頭アドレスから＋２、＋３の領域（アドレス下位４６、アドレス上位４７）から、共有メモリ１へのアクセスアドレスを取得して、これをバスインタフェースのアクセスチャネルのアクセスアドレスレジスタｂへセットする（ステップＳ７５）。更に、取得した要求コマンドデータ５２がライト要求であれば（ステップＳ７６，ＹＥＳ）、要求元インスタンスの先頭アドレスから＋４、＋５の領域（この場合は、ライトデータ下位６１、ライトデータ上位６２となる）から共有メモリ１へのライトデータを取得して、これをバスインタフェースのアクセスチャネル内のライトデータレジスタｃへセットする（ステップＳ７７）。そして、取得した要求コマンドデータ５２をアクセスチャネル内のコマンドレジスタａへセットする（ステップＳ７８）ことで、バスインタフェースへの新規要求発行処理は完了し、最後に、Rpを１つ進
める（ステップＳ７９）。

以上説明したステップＳ３６の処理が終了したら、最後にＲＱビット４３の値をＸＲＱビット４２にコピーして（ステップＳ３７）、図１１に示す処理は終了する。
図１５（ｂ）に、上記ＦＢ（WRITE_WORD）が呼び出すシステムソフトの処理フローチャートを示す。

図１５（ｂ）の処理において、図１１と同じ処理は、同一のステップ番号を付してあり、その説明は省略する。図１５（ｂ）の処理が図１１と異なる点は、図１１のステップＳ４０の処理に代えて、図示のステップＳ８１の処理を実行している点のみである。すなわち、要求バッファへのセットにおいて、要求コマンドデータがライト要求であることのみである。

次に、実施例３について説明する。実施例３は上記課題３を解決するものである。
図１６に、実施例３におけるバスインタフェース７０の構成図を示す。
図１６に示す構成において、図１に示す構成と同一の構成には同一の参照符号を付しており、その説明は省略する。すなわち、図１の構成に加えて、システム用アクセスチャネル７１を設けている。

各アクセスチャネル１１〜１３が定周期タスクに対応するものであるのに対して、システム用アクセスチャネル７１は、例えばローダ３０のモニタ要求や、ＣＰＵモジュール間のメッセージ通信に対応する。具体的にはローダ３０からのモニタコマンドによる低速デバイス（ここでは、共有メモリ１等を指す）へのアクセス要求や、アプリケーション実行サポートの為のＣＰＵモジュール２０間のメッセージの遣り取り（ここでは、共有メモリ１を等を利用）等があげられる。これらは、任意のＣＰＵモジュールの外部からの割り込み等に起因し、上記タスクのアプリケーションによって発生したアクセス要求以外の共有メモリアクセス要求に対応するものである。

システム用アクセスチャネル７１は、割込みによるアクセス完了通知機能を備える。すなわち、バスアクセス（共有メモリアクセス）の完了を、図２に示す割込み信号ＩＮＴによって、マイコン２１に通知する。システム用アクセスチャネル７１は、自己のステータスレジスタ内の上記“完了ビット”が‘１’になったら、ＩＮＴ信号を活性化（ＯＮ）する。これによって、マイコン２１に完了割込みが入り、システムソフトは不図示の割り込み処理を実行する。仮にリード要求を出した場合であれば、システムソフトは当該割込み処理において、リードデータをリードデータレジスタから取り出したのち、図１７に示すステータスレジスタ内の完了ビットを０クリアして、割込み処理を終了し、中断していた処理を続行する。システム用アクセスチャネル７１は、この０クリアにより、INT信号はOFFする。

以上述べたように、実施例３では、マイコン２１は、モニタ要求等のようなＣＰＵモジュール外部（又ＰＬＣ外部）からの要求に起因するバスアクセス要求の発行後、実施例１等の場合と同様に直ちに定周期タスクのアプリケーションに戻ることができるだけでなく、その後のポーリングを行う必要が無く、完了割込みでリードデータの取り込みを行えるので、マイコンの処理能力を無駄なく使用できる。

尚、ここでいう“ポーリング”は、上述したラダー図の場合のようにそのままシステムソフト層に留まって行うポーリングとは異なる。本例の場合、アクセス要求を依頼完了したら、直ちに、定周期タスクアプリケーションに戻ってよいが、当然、アクセス完了したらアクセス結果をローダ等に返信する必要がある為、本来であれば定期的に定周期タスクアプリケーションを中断して、アクセス完了したか否かを確認する必要が生じる。これが
本例におけるポーリングの意味である。しかし、上記本手法では、上記の通り、ポーリングを行う必要がないようにしている。

尚、本実施形態では、アクセス対象は共有メモリとしたが、この例に限らず、アプリケーションがRS232やシリアルEEPROMなど応答の遅いデバイス（これらを総称して低速デバイスと呼ぶものとする）を使う場合にも本発明が適用できる。

実施例１、２におけるバスインタフェースの構成例を示す図である。 本例のプログラマブルコントローラ全体の構成例を示す図である。 各種レジスタのレジスタマップである。 各種レジスタの構成例である。 リード要求の場合のアクセスタイミングチャートである。 リード要求の場合のシステムソフトの処理フローチャート図である。 ライト要求の場合のシステムソフトの処理フローチャート図である。 （ａ）、（ｂ）は、ＦＢＤで表現されるアプリケーション命令の具体例を示す図である。 （ａ）は実施例１におけるREAD_WORDのインスタンスのデータ構造図、（ｂ）はREAD_WORDが呼び出すシステムソフトの処理フローチャート図である。 図９の処理のアクセスタイミングチャートである。 READ_WORDが呼び出すシステムソフトの処理フローチャート図である。 （ａ）は実施例２におけるREAD_WORDのインスタンスのデータ構造図、（ｂ）は要求バッファの一例を示す図である。 図１１に示すステップＳ３２の詳細フローチャート図である。 図１１に示すステップＳ３６の詳細フローチャート図である。 （ａ）は実施例２におけるWRITE_WORDのインスタンス６０のデータ構造図、（ｂ）はWRITE_WORDが呼び出すシステムソフトの処理フローチャート図である。 実施例３におけるバスインタフェースの構成図である。 実施例３におけるステータスレジスタの完了ビットについて説明する為の図である。 マルチタスク実行の一例を示す図である。 従来のＰＬＣの内部および外部構成例を示す図である。 従来のバスインタフェースの構成例である。 従来のバスインタフェースによる共有メモリアクセスのタイミングチャート（リード処理の場合）図である。 従来の問題点を説明する為の図（その１）である。 ラダー図の一例を示す図である。 従来の問題点を説明する為の図（その２）である。 課題２について一例を説明する為の図である。

符号の説明

１ 共有メモリ
２ 共有メモリバス
３ Ｉ／Ｏバス
４ Ｉ／Ｏモジュール
１０ バスインタフェース
１１ アクセスチャネル（レベル０用）
１２ アクセスチャネル（レベル１用）
１３ アクセスチャネル（デフォルト用）
ａ コマンドレジスタ
ｂ アクセスアドレスレジスタ
ｃ ライトデータレジスタ
ｄ リードデータレジスタ
ｅ ステータスレジスタ
１４ アクセス要求キュー
１５ バスアクセス制御部
１６ 内部制御信号とＲＤＹ生成部
１７ アドレスセレクタ
１８ ライトデータセレクタ
１９ チャネルセレクタ
２０ ＣＰＵモジュール
２１ マイコン
２２ ＲＯＭ
２３ ＲＡＭ
２５ Ｉ／Ｏインタフェース
２６ ＲＤＹ制御部
３０ ローダ
４０ インスタンス
４１ EXビット
４２ XRQビット
４３ ＲＱビット
４４ E_DONE
４５ DONEビット
４６ アドレス下位
４７ アドレス上位
４８ リードデータ下位
４９ リードデータ上位
５０ 要求バッファ
５１ 要求元のインスタンスの先頭アドレス
５２ 要求コマンドデータ
６０ インスタンス
６１ ライトデータ下位
６２ ライトデータ上位
７０ バスインタフェース
７１ システム用アクセスチャネル
８０ インスタンス
８１ EXビット
８２ XRQビット
８３ ＲＱビット
８４ DONEビット
８５ アドレス下位
８６ アドレス上位
８７ リードデータ下位
８８ リードデータ上位

Claims (8)

1. 複数レベルのタスクを実行する処理ユニットと、該処理ユニットからの要求に応じて低速デバイスにアクセスするインタフェースユニットとを有するＣＰＵモジュールであって、
   該インタフェースユニットは、前記複数のレベル各々に応じた複数のアクセスチャネルを有し、
   前記処理ユニットは、前記何れかのレベルのタスクを実行中に前記低速デバイスへのアクセス要求が発生した場合、該タスクのレベルに応じた前記アクセスチャネルに対して低速デバイスアクセス処理の実行を依頼するアクセス処理手段を有し、
   前記インタフェースユニットは、該アクセスチャネルへの依頼が完了すると、前記処理ユニットのWAIT状態を解除し、その後に、該依頼に基づく前記低速デバイスへのアクセスを実行することを特徴とするプログラマブルコントローラのＣＰＵモジュール。
2. 前記処理ユニットは、前記ＷＡＩＴ状態の解除によって、前記アクセス要求が発生したタスクより上位レベルのタスクの実行が可能となり、前記アクセス処理手段は、該上位レベルのタスクを実行中に前記低速デバイスへのアクセス要求が発生した場合、該タスクのレベルに応じた前記アクセスチャネルに対して低速デバイスアクセス処理の実行を依頼することを特徴とする請求項１記載のプログラマブルコントローラのＣＰＵモジュール。
3. 前記インタフェースユニットは、前記複数のアクセスチャネルに前記低速デバイスアクセス処理の依頼があると、該依頼受付順に、前記低速デバイスへのアクセスを実行するアクセス制御手段を更に有することを特徴とする請求項１又は２記載のプログラマブルコントローラのＣＰＵモジュール。
4. 前記タスクのアプリケーションがシーケンシャル処理を実行するものである場合、前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い前記アクセスチャネルに対する低速デバイスアクセス処理の実行依頼後、該依頼先のアクセスチャネルに対する定期的なポーリングを行って低速デバイスアクセス処理の実行完了を待つことを特徴とする請求項１〜３の何れかに記載のプログラマブルコントローラのＣＰＵモジュール。
5. 前記タスクのアプリケーションが判断処理を実行するものである場合、前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い前記アクセスチャネルに対する低速デバイスアクセス処理の実行依頼後、次の命令実行に移ることを特徴とする請求項１〜３の何れかに記載のプログラマブルコントローラのＣＰＵモジュール。
6. 前記タスクのアプリケーションが判断処理を実行するものである場合、前記処理ユニットは、各レベルに応じた記憶手段を更に有し、
   前記アクセス処理手段は、該アプリケーションにおける任意の命令実行に伴い低速デバイスアクセス要求が発生する毎に、該要求を該アプリケーションのレベルに対応する前記記憶手段に格納し、前記インタフェースユニット側で低速デバイスアクセス処理が完了する毎に、該記憶手段に記憶されている要求の中で最も古い要求を取り出して、前記インタフェースユニットに対して低速デバイスアクセス処理を依頼することを特徴とする請求項１に記載のプログラマブルコントローラのＣＰＵモジュール。
7. 前記インタフェースユニットは、システム用アクセスチャネルを更に備え、
   前記アクセス処理手段は、前記タスクのアプリケーション以外による低速デバイスアクセス要求が発生すると、前記システム用アクセスチャネルに対して低速デバイスアクセス処理を依頼し、
   前記インタフェースユニットは、該アクセスチャネルへの依頼が完了すると、前記処理ユニットのWAIT状態を解除し、
   該システム用アクセスチャネルは、低速デバイスアクセス処理が完了すると、前記処理ユニットに対して、アクセス完了割込みを出力することを特徴とする請求項１に記載のプログラマブルコントローラのＣＰＵモジュール。
8. 請求項１〜７の何れかに記載のＣＰＵモジュールを有するプログラマブルコントローラ。

Images