JP4618647B2

JP4618647B2 - リアルタイムｏｓシステム

Info

Publication number: JP4618647B2
Application number: JP2006015275A
Authority: JP
Inventors: 信緒由井; 郁男重光
Original assignee: Yaskawa Electric Corp
Current assignee: Yaskawa Electric Corp
Priority date: 2006-01-24
Filing date: 2006-01-24
Publication date: 2011-01-26
Anticipated expiration: 2026-01-24
Also published as: JP2007199848A

Description

本発明は、リアルタイムＯＳシステムに関し、特にメモリ容量の少ない環境下で動作可能なリアルタイムＯＳシステムに関する。

マイクロコンピュータを使った製品は、ますます高機能化するに従ってアプリケーションプログラムも複雑化・大規模化している。これらのソフト開発においては生産性向上が課題となっている。ソフト開発の生産性向上にはソフトの再利用が重要であるが、これにはＯＳの搭載が必要となる。
上記製品に搭載される従来のリアルタイムＯＳとしては、μＩＴＲＯＮ（登録商標）やＶｘＷｏｒｋｓ（登録商標）、Ｌｉｎｕｘ（登録商標）等がある。これらのＯＳは一般に大きなメモリ容量を必要とするが、これはタスク制御ブロック（以下、ＴＣＢと称す。）やスタック領域のためのメモリであり、タスク数が増加すると使用するメモリ容量も増加する。一般にプログラムの複雑化・大規模化によってタスク数も増加するので、メモリ容量は増加傾向にある。
しかしながら、内蔵するメモリ容量に制約がある小規模システムの場合は、このようなリアルタイムＯＳを使用することが困難な場合が多い。小規模システムのようなメモリ容量の少ない環境下で、多くのタスクの制御を可能とするリアルタイムＯＳが必要となっている。
これに対して、複数の同時に実行されないタスクをグループ化し、このグループ化したタスク群でＴＣＢとスタック領域を共有し、リアルタイムＯＳがこのタスク群を管理するようにしているものもある（たとえば、特許文献1を参照）。図５は、特許文献1のリアルタイムＯＳを適用したソフトウエアの構成を示す図である。図５において、リアルタイムＯＳは、ＯＳ部１、ＡＰＩ部２で構成される。ここでは、タスクは、同時に実行されないタスク群１０とシーケンス制御が可能なタスク群２０とに分けられており、前者用としてＴＣＢ３７ａおよびスタック領域３８ａを、また後者用としてＴＣＢ３７ｂとスタック領域３８ｂを備える。シーケンス制御が可能なタスク群２０では、タスク毎にＴＣＢとスタック領域が必要であるが、同時に実行されないタスク群１０では、通常ＴＣＢとスタック領域が各々1個で良い。このように、同時に実行されないタスク群１０については、ＴＣＢとスタック領域が少なくて良いので、従来のリアルタイムＯＳよりもメモリ使用量を削減できる。

特開平１０-１０５４１５号公報

特許文献1のリアルタイムＯＳの場合は、タスク数を維持してメモリ容量（RAM）を低減することを可能としている。しかしながら、このリアルタイムＯＳ上で開発されたソフトウエア資産を異なるリアルタイムＯＳで使用する場合、異なるリアルタイムＯＳの大幅改造が必要となるのでソフトウエア資産の再利用が困難であるという問題があった。
本発明はこのような問題点に鑑みてなされたものであり、使用できるタスク数を維持しつつ少ないメモリ使用量で実行でき、ソフトウエア資産の再利用が容易なリアルタイムＯＳシステムを提供することを目的とする。

上記問題を解決するため、本発明は、次のように構成したのである。
請求項１に記載の発明では、特定のＯＳに依存するタスク群と、同時に実行されずに、且つ、該ＯＳで実行されないサブルーチンで構成されたタスク群について、これら各タスク間のイベントを管理するイベント管理部を備え、前記イベント管理部は、該ＯＳとは独立した構成であって、その内部に、前記サブルーチンで構成された各タスクに対応する実行優先度を予め登録するタスク優先度テーブルと、同時に実行されないタスク群の各タスクに対応したイベントバッファと、前記実行優先度に従って前記サブルーチンで構成されたタスクを格納するレディーキューと、を記録する領域が確保され、前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するように制御するとともに、前記ＯＳに依存するタスクが、前記サブルーチンで構成されたいずれかのタスクに対してイベントを通知したときには、該ＯＳのＡＰＩから、そのイベントを受けて、これを前記イベントバッファに登録し、前記サブルーチンで構成されたいずれかのタスクが、前記ＯＳに依存するいずれかのタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを該ＯＳのＡＰＩに対して転送し、前記サブルーチンで構成されたいずれかのタスクが、前記サブルーチンで構成された他のタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを前記イベントバッファに登録することを特徴とするものである。
請求項２に記載の発明では、前記イベント管理部は、その内部に、前記サブルーチンで構成されたタスクの状態を管理するタスク状態情報を記録する領域がさらに確保され、前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、あわせて該タスクに対応する前記タスク状態情報を参照して該タスクが待機状態と判断された場合には、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するときに、その実行と合わせて該タスクの状態を前記タスク状態情報に記録するように制御することを特徴とするものである。

本発明によると、従来のリアルタイムＯＳの下にイベント管理部を設けて、このイベント管理部で同時に実行されないタスク群の実行を制御する構成としているので、異なるリアルタイムＯＳにおいても既存ソフトウエアの再利用が可能となるのである。
また、イベント管理部において、優先度テーブル、タスク状態情報、メッセージプール領域を、同時に実行されないタスク群で共有するので、少ないメモリ使用量で多くのタスクを処理できる。

以下、本発明の実施の形態について図を参照して説明する。

図１は、本発明のリアルタイムＯＳシステムを適用したソフトウエアの構成を示す図である。
図において、１はＯＳ部、２はＡＰＩ部（Application Program Interface）、３はイベント管理部、１０は同時に実行されないタスク群、２０はシーケンス制御が可能なタスク群である。
ＯＳ部１においては、シーケンス制御が可能なタスク群２０に対応したＴＣＢ３７ｂとスタック領域３８ｂを複数備えている。
イベント管理部３において、３１はイベントバッファ、３２はレディーキュー、３３はタスク優先度テーブル、３４はタスク状態情報、３５はイベント獲得関数テーブル、３６はメイン処理関数テーブル、３９はメッセージプール領域である。
本発明の特徴とするところは、上記のように２種類のタスク群に区分し、同時に実行されないタスク群１０をイベント管理部３でタスクスケジューリングさせるところである。
リアルタイムＯＳシステムは、ＯＳ部１、ＡＰＩ部２、イベント管理部３で構成しており、ＯＳ部１には従来のリアルタイムＯＳであるμＩＴＲＯＮ（登録商標）やＬｉｎｕｘ（登録商標）などが使用される。
シーケンス制御が可能なタスク群２０は、ＯＳで実行されるタスク群であり、待ち状態でＯＳによりタスクチェンジされるタスクである。
同時に実行されないタスク群１０は、ＯＳで実行されないタスク群であり、複数のタスク１０１〜１０５から構成される。このタスク１０１〜１０５は機能ごとに分割したサブルーティンであり、待ち状態はなく一度で処理が完了するタスクである。この例ではタスク数を１６個としている。
イベント管理部３は、ＯＳ部1の下に配置され、サブＯＳ的な役目を果たすものであるが、タスク制御のために、タスク優先度テーブル３３、タスク状態情報３４およびメッセージプール領域３９を各1個使用する。ここでは、このタスク優先度テーブル３３、タスク状態情報３４は、従来のＴＣＢと類似の機能を有する。一方、メッセージプール領域３９は、従来のスタック領域の機能の一部であるメッセージ格納機能を備える。

ここで、イベント通知の流れについては、図1にて太線矢印で示しているが、以下にその動作を説明する。
シーケンス制御が可能なタスク２０から同時に実行されないタスク１０へのイベント通知は、ＡＰＩ部２を介して実行され、ＡＰＩ関数のパラメータで送信先タスク番号を指定することで、特定のタスクへのイベント通知が可能となっている。なお、イベント通知された後のタスクへの振り分けはイベント管理部３が行う。
また、同時に実行されないタスク１０内のタスクからシーケンス制御が可能なタスク２０へのイベント通知は、ＡＰＩ部２にてＡＰＩ関数の送信先タスク番号による判定をした後、ＯＳ部１を介してイベント通知が可能となっている。
また、タスク間のイベント送受信はイベント管理部３で処理される。

図２は、イベント管理部のメインループを示す概略フローチャートである。
以下、図に従ってイベント管理部３の動作を説明する。
イベント処理は、タスク毎に、イベント発行処理、イベント確認登録処理、イベント獲得処理、獲得イベント毎のメイン処理を実行する。
以下に各ステップの動作を説明する。
イベント発行処理では、発生したイベントをイベントバッファ３１にセットする。（ステップ１）
次に、発生イベントの確認登録処理では、発生したイベントに対応したタスクを、タスクの優先度に従ってレディーキューに登録する。本ステップの詳細は後述の図３で説明する。（ステップ２）
イベントの獲得処理では、優先度の高いタスク番号を取得する。本ステップの詳細は後述の図４で説明する。（ステップ３）
次の獲得イベントのメイン処理では、イベントの獲得処理で獲得したタスクの実行処理を行う。本ステップの詳細は後述の図４で説明する。（ステップ４）

図３は、発生イベントの確認登録処理のフローチャートである。
ここで、タスク優先度テーブル３３には、事前にタスク番号毎に優先度を登録しておく。
本図では優先度レベルは４段階としている。
レディーキュー３２では、イベントで発生したタスクを優先度順に登録するが、各優先度レベルに登録可能なタスク数は、管理されるタスク数と同一としており、ここでは１６個としている。
タスク状態情報３４は、管理されているタスクの状態を設定表示する。1が稼動状態で、０が待機状態である。
以下に各ステップの動作を説明する。
最初に、タスク宛てのイベントをすべて確認したかを判断する。
イベントの確認を完了した場合は、[１]ＥＮＤに進み、発生イベントの確認登録処理を終了する。確認を完了していない場合は、ステップ２に進む。（ステップ１）
次に、タスク状態情報３４を参照し、発生したイベントに対応したタスクが待機状態であることを確認する。タスク状態情報３４の該当タスクのビットが０であれば待機状態と判断しステップ３に進む。該当タスクのビットが１であれば稼動状態と判断しステップ５に進む。（ステップ２）
レディーキューにタスク番号を登録する処理は、発生したイベントに対応するタスクの優先度をタスク優先度テーブル３３から取得し、レディーキュー３２において該当する優先度のタスク番号登録バッファの最後尾に、そのタスク番号を追加する。（ステップ３）
次に、そのタスクを稼動状態に移行させるため、タスク状態情報３４の該当タスクのビットに１をセットする。（ステップ４）
上記の処理の後、次のイベントの処理に遷移する。（ステップ５）
以上の処理を、発生したすべてのイベントについて実行する。

図４は、イベントの獲得処理とメイン処理のフローチャートである。
事前に、タスク毎にイベント獲得関数をイベント獲得関数テーブル３５に、各タスクのメイン処理関数をメイン処理関数テーブル３６に登録しておく。
以下に各ステップの動作を説明する。
先ず、レディーキュー３２において優先度の高いタスクから順にタスクを確認する。登録された先頭のタスク番号を獲得する。（ステップ１）
獲得したタスク番号をレディーキュー３２から削除する。（ステップ２）
獲得したタスク番号に相当するイベントを、イベント獲得関数テーブル３５から取得する。（ステップ３）
獲得したタスク番号に相当するメイン処理関数をメイン処理関数テーブル３６から取得し、取得したメイン処理関数のメイン処理を行なう。（ステップ４）
上記でメイン処理を行ったタスクを待機状態に移行させる。（ステップ５）
上記の処理後、レディーキュー３２の内容をすべて確認したかを判断する。確認が終了している場合は、[２]ＥＮＤに進みイベントの獲得処理とメイン処理を終了する。確認が終了していない場合はステップ1に戻り、次のタスクを確認する。（ステップ６）

このように、本発明では、同時に実行されないタスク群１０をイベント管理部３で優先度付きでタスクスケジューリングするようにして、タスク優先度テーブル３３、タスク状態情報３４、メッセージプール領域３９をタスク群１０で共有するので、従来のリアルタイムＯＳと同じ数のタスクを、少ないメモリ使用量で処理できる。
ＯＳ部１の下にイベント管理部３を配置した構成としているので、異なるＯＳで使用する場合でもＯＳ部の変更が必要でないので、既存のソフトウエアを異なるリアルタイムＯＳ上での使用を容易に実現できる。これにより、ソフトウエアの生産性の向上が可能となる。
また、本発明のリアルタイムＯＳシステムを利用することで、メモリ容量が小さくリアルタイムＯＳを実装出来ないシステムにおいては、ＯＳ部１をなくしたものを適用することで、リアルタイム処理が可能となる。

リアルタイム処理が必要で、特にメモリ容量の少ないマイクロコンピュータを搭載した製品に適用できる。

本発明のリアルタイムＯＳシステムを適用したソフトウエアの構成本発明のイベント管理部のメインループを示す概略フローチャート本発明の発生イベントの確認登録処理のフローチャート本発明のイベントの獲得処理とメイン処理のフローチャート特許文献1のリアルタイムＯＳを適用したソフトウエアの構成

符号の説明

１ＯＳ部
２ＡＰＩ部
３イベント管理部
１０同時に実行されないタスク群
２０シーケンス制御が可能なタスク群
３１イベントバッファ
３２レディーキュー
３３タスク優先度テーブル
３４タスク状態情報
３５イベント獲得関数テーブル
３６メイン処理関数テーブル
３７ＴＣＢ
３８スタック領域
３９メッセージプール領域

Claims

特定のＯＳに依存するタスク群と、同時に実行されずに、且つ、該ＯＳで実行されないサブルーチンで構成されたタスク群について、これら各タスク間のイベントを管理するイベント管理部を備え、
前記イベント管理部は、該ＯＳとは独立した構成であって、
その内部に、前記サブルーチンで構成された各タスクに対応する実行優先度を予め登録するタスク優先度テーブルと、
同時に実行されないタスク群の各タスクに対応したイベントバッファと、
前記実行優先度に従って前記サブルーチンで構成されたタスクを格納するレディーキューと、
を記録する領域が確保され、
前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、
その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、
前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するように制御するとともに、
前記ＯＳに依存するタスクが、前記サブルーチンで構成されたいずれかのタスクに対してイベントを通知したときには、該ＯＳのＡＰＩから、そのイベントを受けて、これを前記イベントバッファに登録し、
前記サブルーチンで構成されたいずれかのタスクが、前記ＯＳに依存するいずれかのタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを該ＯＳのＡＰＩに対して転送し、
前記サブルーチンで構成されたいずれかのタスクが、前記サブルーチンで構成された他のタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを前記イベントバッファに登録する
ことを特徴とするリアルタイムＯＳシステム。
前記イベント管理部は、その内部に、前記サブルーチンで構成されたタスクの状態を管理するタスク状態情報を記録する領域がさらに確保され、
前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、
あわせて該タスクに対応する前記タスク状態情報を参照して該タスクが待機状態と判断された場合には、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、
前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するときに、その実行と合わせて該タスクの状態を前記タスク状態情報に記録するように制御する
ことを特徴とする請求項１に記載のリアルタイムＯＳシステム。