【手続補正書】
【提出日】平成20年12月25日(2008.12.25)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
特定のＯＳに依存するタスク群と、同時に実行されずに、且つ、該ＯＳに依存しないサブルーチンで構成されたタスク群について、これら各タスク間のイベントを管理するイベント管理部を備え、
前記イベント管理部は、該ＯＳとは独立した構成であって、
その内部に、前記サブルーチンで構成された各タスクに対応する実行優先度を予め登録するタスク優先度テーブルと、
同時に実行されないタスク群の各タスクに対応したイベントバッファと、
前記実行優先度に従って前記サブルーチンで構成されたタスクを格納するレディーキューと、
を記録する領域が確保され、
前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、
その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、
前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するように制御するとともに、
前記ＯＳに依存するタスクが、前記サブルーチンで構成されたいずれかのタスクに対してイベントを通知したときには、該ＯＳのＡＰＩから、そのイベントを受けて、これを前記イベントバッファに登録し、
前記サブルーチンで構成されたいずれかのタスクが、前記ＯＳに依存するいずれかのタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを該ＯＳのＡＰＩに対して転送し、
前記サブルーチンで構成されたいずれかのタスクが、前記サブルーチンで構成された他のタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを前記イベントバッファに登録する
ことを特徴とするリアルタイムＯＳシステム。
【請求項２】
前記イベント管理部は、その内部に、前記サブルーチンで構成されたタスクの状態を管理するタスク状態情報を記録する領域がさらに確保され、
前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、
あわせて該タスクに対応する前記タスク状態情報を参照して該タスクが待機状態と判断された場合には、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、
前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するときに、その実行と合わせて該タスクの状態を前記タスク状態情報に記録するように制御する
ことを特徴とする請求項１に記載のリアルタイムＯＳシステム。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】発明の名称
【補正方法】変更
【補正の内容】
【発明の名称】リアルタイムＯＳシステム
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は、リアルタイムＯＳシステムに関し、特にメモリ容量の少ない環境下で動作可能なリアルタイムＯＳシステムに関する。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
特許文献1のリアルタイムＯＳの場合は、タスク数を維持してメモリ容量（RAM）を低減することを可能としている。しかしながら、このリアルタイムＯＳ上で開発されたソフトウエア資産を異なるリアルタイムＯＳで使用する場合、異なるリアルタイムＯＳの大幅改造が必要となるのでソフトウエア資産の再利用が困難であるという問題があった。
本発明はこのような問題点に鑑みてなされたものであり、使用できるタスク数を維持しつつ少ないメモリ使用量で実行でき、ソフトウエア資産の再利用が容易なリアルタイムＯＳシステムを提供することを目的とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００４
【補正方法】変更
【補正の内容】
【０００４】
上記問題を解決するため、本発明は、次のように構成したのである。
請求項１に記載の発明では、特定のＯＳに依存するタスク群と、同時に実行されずに、且つ、該ＯＳに依存しないサブルーチンで構成されたタスク群について、これら各タスク間のイベントを管理するイベント管理部を備え、前記イベント管理部は、該ＯＳとは独立した構成であって、その内部に、前記サブルーチンで構成された各タスクに対応する実行優先度を予め登録するタスク優先度テーブルと、同時に実行されないタスク群の各タスクに対応したイベントバッファと、前記実行優先度に従って前記サブルーチンで構成されたタスクを格納するレディーキューと、を記録する領域が確保され、前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するように制御するとともに、前記ＯＳに依存するタスクが、前記サブルーチンで構成されたいずれかのタスクに対してイベントを通知したときには、該ＯＳのＡＰＩから、そのイベントを受けて、これを前記イベントバッファに登録し、前記サブルーチンで構成されたいずれかのタスクが、前記ＯＳに依存するいずれかのタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを該ＯＳのＡＰＩに対して転送し、前記サブルーチンで構成されたいずれかのタスクが、前記サブルーチンで構成された他のタスクに対してイベントを通知したときには、該サブルーチンから、そのイベントを受けて、これを前記イベントバッファに登録することを特徴とするものである。
請求項２に記載の発明では、前記イベント管理部は、その内部に、前記サブルーチンで構成されたタスクの状態を管理するタスク状態情報を記録する領域がさらに確保され、前記イベントバッファに記録されたイベントに対応する前記実行優先度を前記タスク優先度テーブルから参照して、あわせて該タスクに対応する前記タスク状態情報を参照して該タスクが待機状態と判断された場合には、その実行優先度に対応する前記サブルーチンで構成されたタスクを前記レディーキューに登録し、前記レディーキューから前記実行優先度に応じて前記サブルーチンで構成されたタスクを読みだして実行するときに、その実行と合わせて該タスクの状態を前記タスク状態情報に記録するように制御することを特徴とするものである。
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
図１は、本発明のリアルタイムＯＳシステムを適用したソフトウエアの構成を示す図である。
図において、１はＯＳ部、２はＡＰＩ部（Application Program Interface）、３はイベント管理部、１０は同時に実行されないタスク群、２０はシーケンス制御が可能なタスク群である。
ＯＳ部１においては、シーケンス制御が可能なタスク群２０に対応したＴＣＢ３７ｂとスタック領域３８ｂを複数備えている。
イベント管理部３において、３１はイベントバッファ、３２はレディーキュー、３３はタスク優先度テーブル、３４はタスク状態情報、３５はイベント獲得関数テーブル、３６はメイン処理関数テーブル、３９はメッセージプール領域である。
本発明の特徴とするところは、上記のように２種類のタスク群に区分し、同時に実行されないタスク群１０をイベント管理部３でタスクスケジューリングさせるところである。
リアルタイムＯＳシステムは、ＯＳ部１、ＡＰＩ部２、イベント管理部３で構成しており、ＯＳ部１には従来のリアルタイムＯＳであるμＩＴＲＯＮ（登録商標）やＬｉｎｕｘ（登録商標）などが使用される。
シーケンス制御が可能なタスク群２０は、ＯＳで実行されるタスク群であり、待ち状態でＯＳによりタスクチェンジされるタスクである。
同時に実行されないタスク群１０は、ＯＳで実行されないタスク群であり、複数のタスク１０１〜１０５から構成される。このタスク１０１〜１０５は機能ごとに分割したサブルーティンであり、待ち状態はなく一度で処理が完了するタスクである。この例ではタスク数を１６個としている。
イベント管理部３は、ＯＳ部1の下に配置され、サブＯＳ的な役目を果たすものであるが、タスク制御のために、タスク優先度テーブル３３、タスク状態情報３４およびメッセージプール領域３９を各1個使用する。ここでは、このタスク優先度テーブル３３、タスク状態情報３４は、従来のＴＣＢと類似の機能を有する。一方、メッセージプール領域３９は、従来のスタック領域の機能の一部であるメッセージ格納機能を備える。
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】変更
【補正の内容】
【００１０】
図３は、発生イベントの確認登録処理のフローチャートである。
ここで、タスク優先度テーブル３３には、事前にタスク番号毎に優先度を登録しておく。
本図では優先度レベルは４段階としている。
レディーキュー３２では、イベントで発生したタスクを優先度順に登録するが、各優先度レベルに登録可能なタスク数は、管理されるタスク数と同一としており、ここでは１６個としている。
タスク状態情報３４は、管理されているタスクの状態を設定表示する。1が稼動状態で、０が待機状態である。
以下に各ステップの動作を説明する。
最初に、タスク宛てのイベントをすべて確認したかを判断する。
イベントの確認を完了した場合は、[１]ＥＮＤに進み、発生イベントの確認登録処理を終了する。確認を完了していない場合は、ステップ２に進む。（ステップ１）
次に、タスク状態情報３４を参照し、発生したイベントに対応したタスクが待機状態であることを確認する。タスク状態情報３４の該当タスクのビットが０であれば待機状態と判断しステップ３に進む。該当タスクのビットが１であれば稼動状態と判断しステップ５に進む。（ステップ２）
レディーキューにタスク番号を登録する処理は、発生したイベントに対応するタスクの優先度をタスク優先度テーブル３３から取得し、レディーキュー３２において該当する優先度のタスク番号登録バッファの最後尾に、そのタスク番号を追加する。（ステップ３）
次に、そのタスクを稼動状態に移行させるため、タスク状態情報３４の該当タスクのビットに１をセットする。（ステップ４） 
上記の処理の後、次のイベントの処理に遷移する。（ステップ５）
以上の処理を、発生したすべてのイベントについて実行する。
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】変更
【補正の内容】
【００１２】
このように、本発明では、同時に実行されないタスク群１０をイベント管理部３で優先度付きでタスクスケジューリングするようにして、タスク優先度テーブル３３、タスク状態情報３４、メッセージプール領域３９をタスク群１０で共有するので、従来のリアルタイムＯＳと同じ数のタスクを、少ないメモリ使用量で処理できる。
ＯＳ部１の下にイベント管理部３を配置した構成としているので、異なるＯＳで使用する場合でもＯＳ部の変更が必要でないので、既存のソフトウエアを異なるリアルタイムＯＳ上での使用を容易に実現できる。これにより、ソフトウエアの生産性の向上が可能となる。
また、本発明のリアルタイムＯＳシステムを利用することで、メモリ容量が小さくリアルタイムＯＳを実装出来ないシステムにおいては、ＯＳ部１をなくしたものを適用することで、リアルタイム処理が可能となる。
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】変更
【補正の内容】
【００１４】
【図１】本発明のリアルタイムＯＳシステムを適用したソフトウエアの構成
【図２】本発明のイベント管理部のメインループを示す概略フローチャート
【図３】本発明の発生イベントの確認登録処理のフローチャート
【図４】本発明のイベントの獲得処理とメイン処理のフローチャート
【図５】特許文献1のリアルタイムＯＳを適用したソフトウエアの構成
【手続補正１０】
【補正対象書類名】図面
【補正対象項目名】図２
【補正方法】変更
【補正の内容】
【図２】
2007199848.tif 000001