JP2007249357A - 情報処理装置、分散処理システム及びタスク管理方法 - Google Patents
情報処理装置、分散処理システム及びタスク管理方法 Download PDFInfo
- Publication number
- JP2007249357A JP2007249357A JP2006069130A JP2006069130A JP2007249357A JP 2007249357 A JP2007249357 A JP 2007249357A JP 2006069130 A JP2006069130 A JP 2006069130A JP 2006069130 A JP2006069130 A JP 2006069130A JP 2007249357 A JP2007249357 A JP 2007249357A
- Authority
- JP
- Japan
- Prior art keywords
- task
- data
- reception
- cpu
- priority
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Landscapes
- Small-Scale Networks (AREA)
Abstract
【課題】通信データの送受信処理に要する時間の予測可能性を向上させた分散処理処理システムを提供する。
【解決手段】MCU10は、CPU101、通信I/F104を備え、CPU101で実行されるタスクのスケジューリングを行うリアルタイムOS20を搭載している。通信I/F104のデータ受信によってCPU101に対する割り込み要求が発生すると、CPU101は、割り込みハンドラを起動する。割り込みハンドラは、通信I/F104に到着した受信データに付与されている優先度情報に基づいて、データ受信のために待ち状態にある複数のタスクの起床順序を決定し、優先度情報によって高い優先度が与えられた受信データの受信待ちを行っているタスクRTAを優先的に実行可能とする。さらに、リアルタイムOS20は、実行可能な状態にある複数のタスクの優先順位に基づいて、CPU101に割り当てるタスクを決定する。
【選択図】図5
【解決手段】MCU10は、CPU101、通信I/F104を備え、CPU101で実行されるタスクのスケジューリングを行うリアルタイムOS20を搭載している。通信I/F104のデータ受信によってCPU101に対する割り込み要求が発生すると、CPU101は、割り込みハンドラを起動する。割り込みハンドラは、通信I/F104に到着した受信データに付与されている優先度情報に基づいて、データ受信のために待ち状態にある複数のタスクの起床順序を決定し、優先度情報によって高い優先度が与えられた受信データの受信待ちを行っているタスクRTAを優先的に実行可能とする。さらに、リアルタイムOS20は、実行可能な状態にある複数のタスクの優先順位に基づいて、CPU101に割り当てるタスクを決定する。
【選択図】図5
Description
本発明は、情報処理装置間での送受信処理を一定時間内に完了させるリアルタイム通信の実現に有効な情報処理装置に関する。
リアルタイム通信とは、一定時間内に送受信処理が完了する通信を意味する。リアルタイム通信は、複数の情報処理装置、即ちコンピュータが相互に接続されて構成され、ハードリアルタイムが要求される制御システム等の分散処理システムにおいて、コンピュータ間のデータ送受信を行うために特に必要とされる。このようなハードリアルタイムが要求される分散処理システムには、例えば、センサ情報を用いて姿勢制御を行うロボットの制御システムや、ブレーキ制御等の自動車の制御システムがある。
上述したリアルタイム通信を実現可能な通信インタフェースとして、CAN(Controller Area Network)、ARCNET(登録商標)、FlexRay(登録商標)等が知られている。しかしながら、これらの通信インタフェースの制御システムへの適用には、特別なノウハウが要求される、また、システム開発環境のコストが高い。さらに、これらの通信インタフェースのデータ転送速度の上限は10Mbit/s程度であり、高速通信に対応していない。
一方で、高速通信に対応した通信インタフェースに、イーサネット(登録商標)、USB(Universal Serial Bus)2.0、IEEE1394等のインタフェースがある。なお、本明細書では、IEEE802.3委員会によって標準化された10BASE−T、100BASE−TX、1000BASE−T等を総称してイーサネット(登録商標)と呼ぶ。これらのインタフェースは、PC向けの通信インタフェースとして広く普及していることから開発環境が充実しているという利点がある。しかしながら、リアルタイム通信機能を持っていないため、ハードリアルタイムを要求する制御システムに適用することが困難であった。
イーサネット(登録商標)等の高速通信インタフェースにおいてリアルタイム通信を実現するため、又はリアルタイム通信に近づけるためには、通信データの送受信処理に要する時間の予測可能性を高める必要がある。
ここで、通信データの送受信処理に要する時間は、データ送信側でのデータ送信処理に要する時間、送信側の通信インタフェースと受信側の通信インタフェースの間の通信ネットワークの転送時間、受信側でのデータ受信処理に要する時間を総合して定まるものである。通信データの送受信処理に要する時間の予測可能性を向上させるためには、これらの各要素の処理時間の変動を抑制する必要がある。
さらに、ロボット等の制御システムを構成するコンピュータ間で転送される通信データは、ハードリアルタイムが要求されるものに限らない。つまり、一定周期でのデータ送受信は必ずしも必要でないが、データ量が大きいために高い転送速度を要求する通信データも存在している。
このようなリアルタイム性に対する要求レベルの異なる様々な通信データが1つの通信インタフェースに到着し、通信データの到着待ちを行うタスクが複数存在している状況において、リアルタイム性の要求レベルが高いタスクの受信処理が、通信インタフェースに先に到着している他の通信データの受信処理によって待たされるようでは、リアルタイム性を要求するタスクのデータ受信処理に要する時間の予測可能性を高めることは困難である。
なお、特許文献1には、リアルタイム通信と非リアルタイム通信の両方を行うことが可能な環境において、リアルタイム通信によるデータ通信に遅れが生じないようにする通信装置が開示されている。具体的には、リアルタイム通信用のデータを格納するバッファと非リアルタイム通信用のデータを格納するバッファとを備えることとし、データの送信時又は受信時には、リアルタイム通信用のデータを格納するバッファから優先してデータを取り出してデータ送信又はデータ受信を行うものである。
特開2005−198023号公報
本発明は、上述した事情を考慮してなされたものであり、複数のコンピュータが接続された分散処理システムにおいて、通信データの送受信処理に要する時間の予測可能性を向上させることを目的とする。
本発明にかかる情報処理装置は、タスクを実行するCPU、データを送受信可能な通信デバイス、イベント処理手段、及びスケジューリング手段とを備える。ここで、前記イベント処理手段は、前記通信デバイスに到着した受信データに付与されている優先度情報に基づいて、データ受信のために待ち状態にある複数のタスクの起床順序を決定し、前記優先度情報によって高い優先度が与えられた受信データの受信待ちを行っているタスクを優先的に実行可能とする。さらに、前記スケジューリング手段は、実行可能な状態にある複数のタスクの優先順位に基づいて、前記CPUに割り当てるタスクを決定する。
このような構成により、イベント処理手段によって優先順位の高いタスクをいち早く実行可能状態に遷移させ、スケジュール手段によって当該タスクをいち早く実行状態にディスパッチすることができる。このため、1つの通信デバイスに対して複数のタスクがデータの受信待ちを行っており、当該通信デバイスに複数の受信データが到着している場合であっても、リアルタイム通信を要求するような優先順位の高いタスクを優先的に実行できる。これにより、受信データの到着から優先順位の高い受信タスクが実行されるまでの処理時間が規定でき、通信データの送受信処理に要する時間の予測可能性を向上させることが可能となる。
なお、前記優先度情報が示す前記受信データの優先度は、当該受信データを処理するタスクの優先順位を反映して決定されていることが望ましい。
また、前記イベント処理手段は、前記通信デバイスから前記CPUに対する割り込み要求に応じて起動される割り込みハンドラ・プログラムを実行することにより実現することが望ましい。このように割り込みハンドラによって実現すれば、イベント処理手段が行う機能の実装に際して、タスク・スケジューリングを行うリアルタイムOSの改良を特に必要としないという利点がある。
さらに、上述した本発明にかかる情報処理装置は、前記CPUで実行されるタスクの状態を管理するタスク管理手段を備えることが望ましい。ここで、前記タスク管理手段は、前記CPUに割り当てられて実行されている第1の状態、実行可能であるが、前記CPUにおいて他のタスクが実行中であるために前記CPUに割り当てられていない第2の状態、前記通信デバイスに到着するデータの受信待ちのために停止された第3の状態、及び、前記通信デバイスに到着するデータの受信待ちを除く他の条件成立待ちのために停止された第4の状態の少なくとも4つの状態でタスクを管理し、前記第3の状態にあるタスクが受信待ちを行っているデータが、所定の時間内に前記通信デバイスに到着しない場合には、当該タスクを前記第2の状態に遷移させることを特徴とする。
このように、所定の時間内に受信データが得られない場合に、受信待ちを行っているタスクを、CPUに割り当てられる状態に遷移させることにより、リアルタイム性を要求するタスクの定期的な処理を継続できる。
また、上述した本発明にかかる情報処理装置は、一定周期で割り込み要求を生成するタイマと、前記通信デバイスからのデータ送信処理を実行する送信タスクを、前記タイマが生成する割り込み要求に応じて実行可能な状態とする手段を備えることが望ましい。これにより、リアルタイム通信の実現に必要なデータ送信の開始時刻を制御でき、通信データの送受信処理に要する時間の予測可能性をさらに向上させることが可能となる。
さらに、本発明にかかる情報処理装置におけるデータ送信処理では、前記通信デバイスから送信されるデータは、前記送信タスクによって、前記送信タスクがアクセス可能なユーザメモリ領域から前記通信デバイスにDMA転送することが望ましい。このような構成により、CPUによるデータコピーを伴わずに送信データの転送を開始できるため、メモリコピーに伴う遅延を回避し、送信処理を高速に行うことができる。また、さらに、前記送信タスクは、前記送信タスクの生成に応じて割り当てられたユーザメモリ領域を、当該送信タスクの終了まで前記DMA転送に継続的に使用することが望ましい。これにより、送信データが発生するたびにメモリ領域の確保と解放を繰り返すことによる予測不可能な遅延を排除できるため、送信処理に要する処理時間の予測可能性を向上させることができる。
本発明にかかる分散処理システムは、上述した本発明にかかる情報処理装置を複数備えており、複数の前記情報処理装置が備える前記通信デバイスはイーサネット(登録商標)デバイスであって、前記複数の情報処理装置はレイヤ2スイッチを介して通信可能に接続されているものである。このような構成であれば、レイヤ2スイッチと情報処理装置を繋ぐリンクは全二重で専有された状態である。このため、MACフレーム衝突によるデータ送信待ちが発生する余地はなく、情報処理装置を繋ぐネットワークでのデータ転送時間の予測が可能となる。
本発明にかかるタスク管理方法は、実行可能状態にある複数のタスクのCPUへの割り当て順序をタスクの優先度に基づいてスケジューリングするリアルタイムOSを搭載した情報処理装置におけるタスク管理方法である。具体的には、まず、前記CPUが、前記情報処理装置が備える通信デバイスにデータが到着したことを示す割り込み要求に応じて割り込みハンドラを起動する。次に、前記割り込みハンドラが、前記通信デバイスに到着している複数の受信データに付与されている優先度情報を走査することにより、前記優先度情報によって最も高い優先度が与えられた受信データを選択し、選択した受信データの受信待ちを行っているタスクを優先的に実行可能状態に遷移させる。最後に、前記リアルタイムOSが、前記割り込みハンドラによって実行可能状態とされたタスクのスケジューリング及び前記CPUへの割り当てを行うものである。
このような方法により、通信デバイスに受信データが到着してから優先順位の高い受信タスクが実行されるまでの処理時間が規定でき、通信データの送受信処理に要する時間の予測可能性を向上させることが可能となる。
本発明により、通信データの送受信処理に要する時間の予測可能性を向上させることが可能な情報処理装置、分散処理システム、及びタスク管理方法を提供できる。
以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。
発明の実施の形態1.
本実施の形態にかかる制御システム1の構成例を図1に示す。制御システム1は、複数のマイクロ・コントローラ・ユニット(MCU)10が相互に接続された分散制御システムである。図1では、2つのマイクロ・コントローラ・ユニット(MCU)10a及び10bが、イーサネット(登録商標)、具体的には100BASE−TXによって相互に接続された構成例を示している。MCU10aは、カメラ11によって入力された画像データに対する画像処理を行うコンピュータである。MCU11bは、イーサネット(登録商標)を介してMCU10aの画像処理結果を入力し、MCU10aの画像処理結果(例えば、目標物の位置情報など)を利用して、ロボットの可動部を駆動するためのモータ12を制御するコンピュータである。なお、図1の構成は一例であり、イーサネット(登録商標)を介して制御に必要なデータを交換するMCU10a及び10bは、様々な対象を制御する目的に使用可能である。以下では、MCU10a及び10bのハードウェア構成、ソフトウェア構成、及びリアルタイム通信の実現に有効な処理等について説明する。なお、以下では、MCU10a及び10bをまとめてMCU10と記載している。
本実施の形態にかかる制御システム1の構成例を図1に示す。制御システム1は、複数のマイクロ・コントローラ・ユニット(MCU)10が相互に接続された分散制御システムである。図1では、2つのマイクロ・コントローラ・ユニット(MCU)10a及び10bが、イーサネット(登録商標)、具体的には100BASE−TXによって相互に接続された構成例を示している。MCU10aは、カメラ11によって入力された画像データに対する画像処理を行うコンピュータである。MCU11bは、イーサネット(登録商標)を介してMCU10aの画像処理結果を入力し、MCU10aの画像処理結果(例えば、目標物の位置情報など)を利用して、ロボットの可動部を駆動するためのモータ12を制御するコンピュータである。なお、図1の構成は一例であり、イーサネット(登録商標)を介して制御に必要なデータを交換するMCU10a及び10bは、様々な対象を制御する目的に使用可能である。以下では、MCU10a及び10bのハードウェア構成、ソフトウェア構成、及びリアルタイム通信の実現に有効な処理等について説明する。なお、以下では、MCU10a及び10bをまとめてMCU10と記載している。
MCU10のハードウェア構成を図2に示す。CPU101は、ROM(Read Only Memory)102又は図示しないフラッシュメモリ等の不揮発性メモリに格納されたシステム・プログラム及び対象物を制御するためのアプリケーション・プログラムを実行する演算処理部である。
RAM(Random Access Memory)103は、CPU101のワーク領域として使用され、後述する通信インタフェース104、デジタルI/O105、アナログI/O106を介して送受信されるデータの一時保存領域としても使用される。
通信インタフェース104は、他のMCU10との間で制御データを送受信するためのインタフェースであり、図1の構成例では100BASE−TXインタフェースである。デジタルI/O105は、カメラ、圧力センサ、温度センサ等の様々なセンサから入力されるデータ、及びセンサに出力される制御信号等のデジタル信号の入出力を行うインタフェースである。一方、アナログI/Oは、A/D変換処理及びD/A変換処理を行うことによりアナログ信号の入出力を行うインタフェースである。なお、外部のセンサとのインタフェースをMCU10間でのデータ交換を行うデータ通信インタフェース104に統合してもよい。
次に、CPU101において実行されるシステム・プログラム及びアプリケーション・プログラムについて、図3を用いて説明する。本実施の形態のMCU10が実行するシステム・プログラムはマルチタスク環境を備えるリアルタイムOSであり、アプリケーション・プログラムは時間制約の違い等に基づいてタスクに分割されている。図3は、MCU10が実行するリアルタイムOS20と、リアルタイムOS20が提供するマルチタスク環境上で並列処理される複数のタスクの構成を示している。
ここで、リアルタイムOSとは、マルチタスク環境を提供し、プリエンプティブな優先度ベースのタスク・スケジューリングを行うシステム・プログラムである。プリエンプティブとは、実行途中のタスクの処理を停止して、他のタスクにCPUを割り当て可能であることを意味する。優先度ベースとは、タスクに与えられた優先度の高低によってCPUで実行するタスクが決定されることを意味する。また、タスクとは、リアルタイムOSが提供するマルチタスク環境において並列実行されるプログラム単位である。なお、リアルタイムOSは、リアルタイム・カーネルとも呼ばれる場合もある。なお、リアルタイムOSとしては、社団法人トロン協会によって規定されたμITRON4.0仕様が、リアルタイムOSの標準仕様として広く普及している。
リアルタイムOS20は、CPU101、RAM103等のハードウェア資源を利用して、タスク管理、タスク間同期、割り込み管理、メモリ管理、時間管理、デバイス管理等を実行する。これらの機能は、従来のリアルタイムOSが標準的に備える機能であるため、各機能の概略のみを以下に示す。
タスク管理は、タスク状態の管理、起動可能な状態にあるタスクを実行順序を示すレディキューの管理、タスクに与えられた優先度の管理、コンテキストの保存等を行うことにより、タスクの生成、削除、起動、及び終了を行う手段を提供するものである。タスク管理によって実現される管理機構を以下ではスケジューラと呼ぶこととする。
タスク間同期は、セマフォやリンクリストに基づくメールボックス等を利用して、タスク間通信及びタスク間での処理の待ち合わせを行う手段を提供するものである。
割り込み管理は、CPUへの割込みに応じて起動される割り込みハンドラを管理するものである。具体的には、割り込みハンドラを定義し、割り込みと割り込みハンドラとを対応させる役割を担うものである。
時間管理は、システム時刻を管理し、時間に依存した処理を実現する。具体的には、システム時刻に基づいて、一定周期で起動されるハンドラ(周期ハンドラと呼ぶ)、指定した時刻に起動されるハンドラ(アラームハンドラと呼ぶ)等のいわゆるタイムイベントハンドラの生成、削除を行う。
メモリ管理は、タスク間通信等に用いられる共有メモリ領域の管理を担うものである。
最後に、デバイス管理は、通信インタフェース104の入出力制御等の各ハードウェア・デバイスを動作させるためのデバイス・ドライバ機能、及びデバイス・ドライバ管理機能を提供する。なお、デバイス・ドライバ機能は、タスク管理、タスク間同期、割り込み管理、メモリ管理、及び時間管理等のカーネル部分から独立したソフトウェアとして実現される場合もある。
受信タスクRTA、受信タスクRTB、送信タスクSTC、及びタスクTDは、上述したリアルタイムOS20のマルチタスク環境で実行されるタスク群の一例を示すものである。なお、後の説明のため、受信タスクRTA及び受信タスクRTBは、通信インタフェース104によって受信されるデータを処理するタスクとする。さらに、受信タスクRTAはリアルタイム通信を要求する時間制約が厳しいタスクであり、受信タスクRTAには受信タスクRTBより高い優先度が与えられているものとする。
また、送信タスクSTCは、通信インタフェース105を介して他のMCU10にデータを送信する処理を実行するタスクとする。タスクTDは、通信インタフェース104を介したデータ送受信を行わないタスクであり、受信タスクRTA、受信タスクRTB、及び送信タスクSTCに比べて低い優先度がタスクTDに与えられているものとする。
割り込みハンドラINHは、CPU101に接続された通信インタフェース104等のデバイスが要求するハードウェア割り込みに応じて起動されるプログラムである。
続いて以下では、通信インタフェース104でのリアルタイム通信の実現に有効であるMCU10の特徴的な処理、及び制御システム1の構成について説明する。
<データ受信処理>
MCU10が備える通信インタフェース104に受信データが到着したときに行わるタスク・ディスパッチの流れを図4乃至6を用いて説明する。図4は、通信インタフェース104がデータを受信してから、データ受信待ちのために停止されていた受信タスクRTAが起動されるまでを示すタイミング図である。
MCU10が備える通信インタフェース104に受信データが到着したときに行わるタスク・ディスパッチの流れを図4乃至6を用いて説明する。図4は、通信インタフェース104がデータを受信してから、データ受信待ちのために停止されていた受信タスクRTAが起動されるまでを示すタイミング図である。
図4において、通信インタフェース104にデータが到着すると、通信インタフェース104からCPU101に対して割り込み要求が行われる(S11)。この割り込み要求に応じてCPU101によって割り込みハンドラINHが起動され、割り込みハンドラNHによる割り込み処理が実行される(S12)。
ここで、通信インタフェース104のデータ受信に基づいて起動された割り込みハンドラINHが行う割り込み処理(S12)の詳細を図5のフローチャートを用いて説明する。割り込みハンドラINHが起動されると、通信インタフェース104の受信データが格納されたメモリ領域にアクセスし、受信データに与えられた優先度を走査する(ステップS21)。ここで、受信データに与えられた優先度とは、データ送信側のMCU10によって通信データに付加されるものであり、時間制約が厳しいタスクに引き渡されるデータほど高い優先度が与えられている。
通信インタフェース104で転送される通信データに優先度を与えるためには、まず、リアルタイム通信を要求する送信タスク及び受信タスクが他のタスクより優先的に実行されるように、スケジューラにおいて他のタスクに比べて高い優先度を与えることとする。ここでの他のタスクには、リアルタイム通信を要求しない受信タスク及び送信タスクが含まれる。その上で、送信タスクの実行時に、スケジューラがリアルタイム通信を要求するタスクに対して与える優先度を反映した優先度を転送データに付加することとすればよい。
通信インタフェース104が100BASE−TXインタフェースである場合に転送されるMACフレームの構成を図6に示す。このようなMACフレームによるデータ転送を行う場合は、IEEE802.1pで規定されるVLANタグを挿入し、VLANタグ中の3ビットのユーザ優先度フィールドを、タスクに対して与える優先度を反映した優先度を示すフィールドとして利用してもよい。また、フレーム・ヘッダではなく、ペイロード中の所定の位置に挿入することとしてもよい。
図5に戻り、ステップS22では、最も優先度が高い受信データを判定し、当該受信データに対応する受信タスクを判定する。例えば、図3に示した受信タスクRTAが受信待ちを行っているデータ、及び受信タスクRTBが受信待ちを行っているデータがともに通信インタフェース104に到着している場合には、優先順位の高い受信タスクRTAが受信待ちを行っているデータが判定され、これに対応する受信タスクRTAが判定される。
ステップS23では、ステップS22で判定された受信タスクRTAを起床する。具体的には、受信データの格納場所を示すアドレスを受信タスクRTAに引き渡すとともに、受信タスクRTAの状態を、データ受信を待っている状態からスケジューリング対象となる実行可能状態(Ready状態)に変更する。なお、データ受信を待っている状態とは、コンテキストを保存してタスクの実行が中断された待ち状態(Waiting状態)又は後述するCommunication状態(以下、Com状態と呼ぶ)である。
続いて図4に戻り、割り込みハンドラINHによる割り込み処理(S12)に引き続く処理を説明する。割り込みハンドラINHの終了後のS13では、リアルタイムOS20によるタスクのスケジューリングが行われる。なお、当該スケジューリングの要請は、割り込みハンドラINHが明示的に要請する場合と、割り込みハンドラINHの終了に応じてリアルタイムOS20が暗黙に行う場合がある。このスケジューリングによって、データ受信待ちが解除されてReady状態となった受信タスクRTAがスケジューリングされる。このとき、リアルタイム通信を要求する受信タスクRTAに最も高い優先度を与えておくことにより、受信タスクRTAのディスパッチ処理が行われ(S14)、受信タスクRTAがCPU101において実行される(S15)。
上述したように本実施の形態にかかるMCU10では、対応するタスクの優先順位を反映した優先度情報をMCU10間の通信データに付与することとし、通信データに付与された優先度を参照することによってスケジューリング対象とすべき受信タスクを選択するものである。これにより、優先度の低い受信タスクRTBに対する受信データが優先度の高い受信タスクRTAに対する受信データより先に通信インタフェース104に到着していた場合であっても、受信タスクRTAを優先して実行できる。
通信インタフェース104に複数のデータが到着しているために、リアルタイム通信を要求する受信タスクRTAの実行開始が遅れたのでは、受信データの到着から受信タスクRTAがディスパッチされるまでの処理時間に予測不可能な変動が発生することになる。これに対して本実施の形態のMCU10は、通信インタフェース104に複数のデータが到着している状況下でも、受信タスクRTAを優先して実行可能である。このため、受信データの到着から受信タスクRTAがディスパッチされるまでの処理時間の予測可能性を向上させることができる。
また、受信データに付与された優先度情報に基づいて、データ受信待ちからReady状態に遷移させるタスクを決定する処理は、割り込みハンドラINHによって実現されている。このため、本機能の実装に際して、リアルタイムOS20、具体的にはタスク・スケジューリングを行うタスク管理機能(スケジューラ)の改良を特に必要としないという利点がある。
なお、図4のS11において通信インタフェース104からの割り込み要求に言及したが、CPU101には通信インタフェース104以外にも多数のデバイスが接続されていることが通常である。このため、割り込み要因の異なる様々な割り込み要求が、CPU101に対して行われることになる。このような多数の割り込み要求を調停するため、各割り込み要求には、予め割り込み要因に応じて優先度が割り当てられる。これにより、割り込み要因が異なる複数の割り込み要求が同時に発生している場合は、CPU101又はCPU101に割り込み要因を伝達するデバイスである割り込みコントローラ(不図示)によって、優先順位の高い割り込み要因に基づく割り込み要求が優先的に処理されることになる。
このため、通信インタフェース104においてリアルタイム通信を行うためには、通信インタフェース104のデータ受信を要因とする割り込み要求に対して、他のデバイスが行う割り込み要求よりも高い優先度を与えることが望ましい。このように構成することによって、通信インタフェース104のデータ受信を要因とする割り込み要求が優先的に処理されることになり、他の割り込み要求の処理を待つことによる予測不可能な処理遅延の発生を回避できる。これにより、データ受信処理の処理時間の予測可能性を向上させることができる。
<タスク管理>
次に、リアルタイムOS20におけるタスク管理について説明する。リアルタイムOS20におけるタスク状態の遷移図を図7に示す。図7に示すタスク状態のうち、Running状態301、Ready状態302、Waiting状態303、及びDormant状態305は、従来のタスク管理において定義されているタスク状態と同様である。具体的には、Running状態301は、CPU101が割り当てられてタスクを実行している状態である。Ready状態302は、タスクの実行に必要な条件は整っているが、当該タスクよりも優先度が高いタスク、又は当該タスクと同一優先度で先に実行可能となったタスクがRunning状態301にあるために実行できない状態である。
次に、リアルタイムOS20におけるタスク管理について説明する。リアルタイムOS20におけるタスク状態の遷移図を図7に示す。図7に示すタスク状態のうち、Running状態301、Ready状態302、Waiting状態303、及びDormant状態305は、従来のタスク管理において定義されているタスク状態と同様である。具体的には、Running状態301は、CPU101が割り当てられてタスクを実行している状態である。Ready状態302は、タスクの実行に必要な条件は整っているが、当該タスクよりも優先度が高いタスク、又は当該タスクと同一優先度で先に実行可能となったタスクがRunning状態301にあるために実行できない状態である。
Running状態301にあるタスクが終了した場合、又はRunning状態301にあるタスクより優先度が高いタスクがReady状態302になった場合は、新たなタスクが実行状態にディスパッチされる(S31)。なお、優先度が高いタスクにプリエンプトされたタスクは、Running状態301からReady状態302に遷移する(S32)。
Waitng状態303は、タスクを実行するための条件が整わず、何らかの条件成立を待っている状態である。Running状態301にあるタスクは、何らかの条件成立を待つ場合に、Waitng状態303に遷移し(S33)、条件が成立すればReady状態302に遷移する(S34)。
Dormant状態305は、まだ一度も起動されていないタスク又は実行が終了したタスクが遷移する状態である。Dormant状態305から起動されたタスクは、Ready状態に遷移する(S37)。実行が終了したタスクは、Running状態301又はReady状態302から、Dormant状態305に遷移する(S38又はS39)。
これら4つの状態に加えて、本実施の形態では、通信データの到着待ちのために待機しているタスク状態をCom状態304と定義し、リアルタイム通信を要求するタスクが受信待ちとなる際に、当該タスクをCom状態304に遷移させる(S35)。Com状態304からReady状態302に遷移する遷移する1つの条件は、データ受信待ちの解除である。具体的には、上述した割り込みハンドラINHによってReady状態302への変更が行われる。これとは別に、Com状態304からReady状態302に遷移する遷移するもう1つの条件はタイムアウトである。即ち、Com状態304に入る際にタイムアウト時間を指定し、タイムアウト時間が経過しても受信データが到着しない場合には、Com状態304からReady状態302に遷移することとする。
リアルタイム通信を要求するタスクは、通常、ハードリアルタイムを要求する処理に関するタスクである。このため、データ受信待ちを継続し続けることは、ハードリアルタイムを要求する処理に破綻をきたすことになり好ましくない。一方で、ハードリアルタイムを要求する処理であっても、新たな受信データが得られない場合に過去の受信データを用いた代替処理を実行することにより、危機的な状況の発生を回避可能な場合がある。本実施の形態のMCU10では、上述したCom状態304を定義し、タイムアウト時間が経過しても受信データが到着しない場合に、Com状態304からReady状態302に遷移する。これにより、タスクの定期的な処理を継続でき、上述したような代替処理の実行が可能となる。
<データ送信処理>
リアルタイム通信を要求する送信タスクSTCによって、通信インタフェース104からデータを送信する処理について説明する。まず、リアルタイム通信の実現のためには、データ送信の開始時刻を制御する必要がる。これを実現するためには、当該タスクによってデータを送信するタイミングを、上述したリアルタイムOS20が備える時間管理機能を利用して決定すればよい。具体的には、システム時刻に基づいて一定周期で起動される周期ハンドラによって、通信インタフェース104に対するデータ送信を行うこととすればよい。
リアルタイム通信を要求する送信タスクSTCによって、通信インタフェース104からデータを送信する処理について説明する。まず、リアルタイム通信の実現のためには、データ送信の開始時刻を制御する必要がる。これを実現するためには、当該タスクによってデータを送信するタイミングを、上述したリアルタイムOS20が備える時間管理機能を利用して決定すればよい。具体的には、システム時刻に基づいて一定周期で起動される周期ハンドラによって、通信インタフェース104に対するデータ送信を行うこととすればよい。
さらに短い周期でのリアルタイム通信を実現するためには、送信処理を高速に行うことが望ましい。そこで、本実施の形態にかかるMCU10では、通信インタフェース104のDMA(Direct Memory Access)機能を利用して、送信タスクから通信インタフェース104に対して送信データをDMA転送することとする。通常の通信では、送信タスクが生成した送信データがユーザメモリ領域からシステムメモリ領域にコピーされた後に通信インタフェースに転送されるのに対して、本実施の形態ではCPU101によるデータコピーを伴わずに送信データの転送を開始できる。このため、メモリコピーに伴う遅延を回避し、送信処理を高速に行うことができる。
なお、上述したDMA転送を行うためには、送信データを生成するメモリ領域としてDMA転送可能な領域を確保する必要がある。しかし、一般にメモリ領域を確保する処理は処理時間の予測が困難である。このため、本実施の形態のMCU10では、送信データが発生するたびにメモリ領域の確保と解放を繰り返すのではなく、リアルタイム通信を要求するタスクの起動時に確保したメモリ領域を、当該タスクの終了時まで繰り返し利用することとする。これにより、メモリ領域の確保と解放はそれぞれタスクの起動時と終了時に行うだけでよく、メモリ領域の確保処理による予測不可能な遅延を排除でき、送信処理に要する処理時間の予測可能性を向上させることができる。
<再送機能の不使用>
イーサネット(登録商標)の上位層(ネットワーク層及びトランスポート層)として、TCP/IPが広く使用されている。しかしながら、TCP/IPは、送信データの不到達時に再送処理を行うものであり、また、経路選択などの高度な転送制御を可能とするプロトコルであるため、処理が複雑で通信データの処理時間の予測が困難であるという問題がある。そこで、本実施の形態のMCU10では、TCP/IPを使用しないこととした。具体的には、ネットワーク層及びトランスポート層では、通信インタフェース104とタスクとを対応付けるデータの受け渡しのみを行うこととし、MCU10間でのデータ転送は、イーサネット(登録商標)のデータリンク層が行う隣接装置間でのデータ転送制御のみを使用することとする。
イーサネット(登録商標)の上位層(ネットワーク層及びトランスポート層)として、TCP/IPが広く使用されている。しかしながら、TCP/IPは、送信データの不到達時に再送処理を行うものであり、また、経路選択などの高度な転送制御を可能とするプロトコルであるため、処理が複雑で通信データの処理時間の予測が困難であるという問題がある。そこで、本実施の形態のMCU10では、TCP/IPを使用しないこととした。具体的には、ネットワーク層及びトランスポート層では、通信インタフェース104とタスクとを対応付けるデータの受け渡しのみを行うこととし、MCU10間でのデータ転送は、イーサネット(登録商標)のデータリンク層が行う隣接装置間でのデータ転送制御のみを使用することとする。
このとき、MCU10間の物理的な接続は、図1に示したpoint−to−point接続のほか、MACアドレスに基づいてスイッチングを行うレイヤ2スイッチ30を介して2以上のMCU10を接続する形態が使用できる。レイヤ2スイッチ30を用いたスター接続による制御システムの構成例を図8に示す。スター接続の場合でも、1つのレイヤ2スイッチ30とMCU10との間の物理リンク(100BASE−TXであればツイスト・ペア・ケーブル)は全二重で専有された状態である。このため、MACフレーム衝突によるデータ送信待ちが発生する余地はなく、データ転送時間の予測が可能となる。なお、レイヤ2スイッチ30を使用する場合は、レイヤ2スイッチ30内部でのデータストア処理及びフォワーディング処理に伴う内部遅延が発生するが、この内部遅延時間の変動量の予測は可能である。
このように、送信データの再送を行わず、MCU10間を接続するネットワーク構成として通信データの衝突が発生しない構成を採用することにより、データ送信処理に要する時間の予測可能性を向上させることができる。
その他の実施の形態.
上述した発明の実施の形態1にかかるMCU10は、データ受信処理、タスク管理、データ送信処理、及び再送機能の不使用といった特徴的な構成を有しており、これらの特徴的な構成の相乗的な効果によって、MCU10間でのリアルタイム通信を実現するために必要となるend−to−endでの送受信処理に要する時間の予測可能性を向上させている。しかしながら、MCU10が有する特徴的な構成の全てを具備しなくても、end−to−endでの送受信処理に要する時間の予測可能性を向上させることは可能である。
上述した発明の実施の形態1にかかるMCU10は、データ受信処理、タスク管理、データ送信処理、及び再送機能の不使用といった特徴的な構成を有しており、これらの特徴的な構成の相乗的な効果によって、MCU10間でのリアルタイム通信を実現するために必要となるend−to−endでの送受信処理に要する時間の予測可能性を向上させている。しかしながら、MCU10が有する特徴的な構成の全てを具備しなくても、end−to−endでの送受信処理に要する時間の予測可能性を向上させることは可能である。
例えば、通信データに付与された優先度を参照することにより、優先的に起動する受信タスクの選択を行うデータ受信処理のみを利用する場合でも、データ受信処理の処理時間の予測可能性を向上することが可能であるため、end−to−endでの送受信処理に要する時間の予測可能性の向上に寄与することができる。即ち、本発明にかかるMCUは、発明の実施の形態1にかかるMCU10が備える特徴的な構成の全てを備える必要はなく、これらの特徴的な構成の一部を具備するものであってもよい。
さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。
1 制御システム
10、10a、10b マイクロ・コントローラ・ユニット(MCU)
101 CPU
102 ROM
103 RAM
104 通信インタフェース
105 デジタルI/O(DIO)
106 アナログI/O(AIO)
20 リアルタイムOS(RTOS)
30 レイヤ2スイッチ
RTA、RTB 受信タスク
STD 送信タスク
INH 割り込みハンドラ
10、10a、10b マイクロ・コントローラ・ユニット(MCU)
101 CPU
102 ROM
103 RAM
104 通信インタフェース
105 デジタルI/O(DIO)
106 アナログI/O(AIO)
20 リアルタイムOS(RTOS)
30 レイヤ2スイッチ
RTA、RTB 受信タスク
STD 送信タスク
INH 割り込みハンドラ
Claims (8)
- タスクを実行するCPUと、
データを送受信可能な通信デバイスと、
前記通信デバイスに到着した受信データに付与されている優先度情報に基づいて、データ受信のために待ち状態にある複数のタスクの起床順序を決定し、前記優先度情報によって高い優先度が与えられた受信データの受信待ちを行っているタスクを優先的に実行可能とするイベント処理手段と、
実行可能な状態にある複数のタスクの優先順位に基づいて、前記CPUに割り当てるタスクを決定するスケジューリング手段とを備える情報処理装置。 - 前記優先度情報が示す前記受信データの優先度は、当該受信データを処理するタスクの優先順位を反映して決定されている請求項1に記載の情報処理装置。
- 前記イベント処理手段は、前記通信デバイスから前記CPUに対する割り込み要求に応じて起動される割り込みハンドラ・プログラムを実行することにより実現される請求項1に記載の情報処理装置。
- 前記CPUで実行されるタスクの状態を管理するタスク管理手段を備え、
前記タスク管理手段は、前記CPUに割り当てられて実行されている第1の状態、実行可能であるが、前記CPUにおいて他のタスクが実行中であるために前記CPUに割り当てられていない第2の状態、前記通信デバイスに到着するデータの受信待ちのために停止された第3の状態、及び、前記通信デバイスに到着するデータの受信待ちを除く他の条件成立待ちのために停止された第4の状態の少なくとも4つの状態でタスクを管理し、
前記第3の状態にあるタスクが受信待ちを行っているデータが、所定の時間内に前記通信デバイスに到着しない場合には、当該タスクを前記第2の状態に遷移させることを特徴とする請求項1に記載の情報処理装置。 - 一定周期で割り込み要求を生成するタイマと、
前記通信デバイスからのデータ送信処理を実行する送信タスクを、前記タイマが生成する割り込み要求に応じて実行可能な状態に遷移させる手段とをさらに備える請求項1又は4に記載の情報処理装置。 - 前記通信デバイスから送信されるデータは、前記送信タスクによって、前記送信タスクがアクセス可能なユーザメモリ領域から前記通信デバイスにDMA転送され、
前記送信タスクは、前記送信タスクの生成に応じて割り当てられたユーザメモリ領域を、当該送信タスクの終了まで前記DMA転送に継続的に使用する請求項5に記載の情報処理装置。 - 請求項1乃至6のいずれかに記載された情報処理装置を複数備え、
複数の前記情報処理装置が備える前記通信デバイスはイーサネット(登録商標)デバイスであって、
前記複数の情報処理装置はレイヤ2スイッチを介して通信可能に接続されている分散処理システム。 - 実行可能状態にある複数のタスクのCPUへの割り当て順序をタスクの優先度に基づいてスケジューリングするリアルタイムOSを搭載した情報処理装置におけるタスク管理方法であって、
前記CPUが、前記情報処理装置が備える通信デバイスにデータが到着したことを示す割り込み要求に応じて割り込みハンドラを起動し、
前記割り込みハンドラが、前記通信デバイスに到着している複数の受信データに付与されている優先度情報を走査することにより、前記優先度情報によって最も高い優先度が与えられた受信データを選択し、選択した受信データの受信待ちを行っているタスクを優先的に実行可能状態に遷移させ、
前記リアルタイムOSが、前記割り込みハンドラによって実行可能状態とされたタスクのスケジューリング及び前記CPUへの割り当てを行うタスク管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006069130A JP2007249357A (ja) | 2006-03-14 | 2006-03-14 | 情報処理装置、分散処理システム及びタスク管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006069130A JP2007249357A (ja) | 2006-03-14 | 2006-03-14 | 情報処理装置、分散処理システム及びタスク管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2007249357A true JP2007249357A (ja) | 2007-09-27 |
Family
ID=38593620
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006069130A Pending JP2007249357A (ja) | 2006-03-14 | 2006-03-14 | 情報処理装置、分散処理システム及びタスク管理方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2007249357A (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009282987A (ja) * | 2008-05-21 | 2009-12-03 | Korea Advanced Inst Of Sci Technol | 割込みスケジューリング方法 |
JP2011155443A (ja) * | 2010-01-27 | 2011-08-11 | Nippon Telegr & Teleph Corp <Ntt> | Ponシステムのmpcp処理装置 |
US10412017B2 (en) | 2017-09-13 | 2019-09-10 | Kabushiki Kaisha Toshiba | Transfer device, transfer method, and computer program product |
JP2020526968A (ja) * | 2017-07-12 | 2020-08-31 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 遠隔ノード発見、ならびに通信チャネル確認および通信チャネル接続のためのプロセッサによって実施される方法、コンピュータ・システム、およびコンピュータ・プログラム |
JP2020149526A (ja) * | 2019-03-15 | 2020-09-17 | 株式会社東芝 | 処理装置、処理方法及びプログラム |
CN114911434A (zh) * | 2022-06-28 | 2022-08-16 | 北京高德品创科技有限公司 | 一种打印机任务管理方法和装置 |
-
2006
- 2006-03-14 JP JP2006069130A patent/JP2007249357A/ja active Pending
Cited By (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2009282987A (ja) * | 2008-05-21 | 2009-12-03 | Korea Advanced Inst Of Sci Technol | 割込みスケジューリング方法 |
JP2011155443A (ja) * | 2010-01-27 | 2011-08-11 | Nippon Telegr & Teleph Corp <Ntt> | Ponシステムのmpcp処理装置 |
JP2020526968A (ja) * | 2017-07-12 | 2020-08-31 | インターナショナル・ビジネス・マシーンズ・コーポレーションInternational Business Machines Corporation | 遠隔ノード発見、ならびに通信チャネル確認および通信チャネル接続のためのプロセッサによって実施される方法、コンピュータ・システム、およびコンピュータ・プログラム |
JP7098711B2 (ja) | 2017-07-12 | 2022-07-11 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 遠隔ノード発見、ならびに通信チャネル確認および通信チャネル接続のためのプロセッサによって実施される方法、コンピュータ・システム、およびコンピュータ・プログラム |
US10412017B2 (en) | 2017-09-13 | 2019-09-10 | Kabushiki Kaisha Toshiba | Transfer device, transfer method, and computer program product |
JP2020149526A (ja) * | 2019-03-15 | 2020-09-17 | 株式会社東芝 | 処理装置、処理方法及びプログラム |
JP2022121525A (ja) * | 2019-03-15 | 2022-08-19 | 株式会社東芝 | 処理装置、処理方法及びプログラム |
JP7354361B2 (ja) | 2019-03-15 | 2023-10-02 | 株式会社東芝 | 処理装置、処理方法及びプログラム |
CN114911434A (zh) * | 2022-06-28 | 2022-08-16 | 北京高德品创科技有限公司 | 一种打印机任务管理方法和装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2009265963A (ja) | 情報処理システム及びタスクの実行制御方法 | |
JP3922070B2 (ja) | 分散制御方法及び装置 | |
US10785014B2 (en) | Computation device, control device and control method | |
JP5653431B2 (ja) | マルチプロセッサシステム | |
US6976095B1 (en) | Port blocking technique for maintaining receive packet ordering for a multiple ethernet port switch | |
US20160056905A1 (en) | Interface Device and Method for Exchanging User Data | |
US20090086737A1 (en) | System-on-chip communication manager | |
JP5231400B2 (ja) | マルチプロセッサ・ゲートウェイ | |
TWI484346B (zh) | 最適化網路連接器並減少中斷 | |
JP2000284980A (ja) | マルチタスクシステムおよびマルチタスクシステムにおけるメッセージ伝送スケジューリング方法 | |
JPH09128351A (ja) | 並列計算機における並列プロセススケジューリング方法および並列計算機用処理装置 | |
JP2007249357A (ja) | 情報処理装置、分散処理システム及びタスク管理方法 | |
JP2020048045A (ja) | スイッチ装置、スイッチング方法及びプログラム | |
JP4154853B2 (ja) | 制御データを等値化する冗長化プログラマブルコントローラ及び等値化方法。 | |
TWI426387B (zh) | 用於延遲之記憶體存取請求仲裁之方法及系統 | |
EP3304331A1 (en) | Single-chip multi-processor communication | |
Bello et al. | Priority-driven swapping-based scheduling of aperiodic real-time messages over EtherCAT networks | |
JP7451438B2 (ja) | 通信装置、通信システム、通知方法及びプログラム | |
Lee et al. | MC-SDN: Supporting mixed-criticality real-time communication using software-defined networking | |
CN102147776B (zh) | 数据处理装置和数据处理方法 | |
WO2023004801A1 (zh) | 一种任务处理方法及装置 | |
CN115884229B (zh) | 传输时延的管理方法、电子设备和存储介质 | |
EP1450256A2 (en) | Inter-task communications method, program, recording medium, and electronic device | |
CN109426562B (zh) | 优先级加权轮转调度器 | |
JP3713977B2 (ja) | リアルタイム分散システム |