JP2010152513A - ハイブリッドシステムおよび割込制御装置並びに割込制御方法 - Google Patents

Abstract

【課題】ハイブリッドシステムにおける割込応答性能の低下を軽減する。
【解決手段】制御システム１５０は、Ｌｉｎｕｘ１２０側の割込要因がマスクされていないときの割込要求に対して、ＲＴＯＳ１３０側の割込要因かＬｉｎｕｘ１２０側の割込要因かの判定をし、Ｌｉｎｕｘ１２０側の割込要因であるときに、該割込要求に対する制御権をＬｉｎｕｘ１２０に移行させ、ＲＴＯＳ１３０側の割込要因であるときに、Ｌｉｎｕｘ１２０ＯＳ側の割込要因をマスクすると共に上記制御権をＲＴＯＳに移行させ、その後、ＲＴＯＳがＬｉｎｕｘタスクをスケジューリングするようになったときにＬｉｎｕｘ側の割込要因へのマスクを解除する。また、制御システム１５０は、Ｌｉｎｕｘ１２０側の割込要因がマスクされている間の割込要求に対して、ＲＴＯＳによる上記制御権の保持を継続させる。
【選択図】図１

Description

本発明は、２つのＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）がハードウェア資源を共有するハイブリッドシステムにおける割込み制御技術に関する。

組み込みシステムで使用されるＯＳの特徴の１つとして「リアルタイム性」が挙げられる。リアルタイム性とは、ある割込みが発生してから、該割込みに対応する割込処理が完了するまでの時間（割込み応答時間）が一定の範囲内に収まることを意味する。リアルタイム性が保証されるＯＳは、リアルタイムＯＳ（ＲＴＯＳ）と呼ばれている。それに対して、リアル性が保証されないＯＳは、非リアルタイムＯＳと呼ばれる。

リアルタイムＯＳは、必要な処理時間の予測機能や、複数の処理が同時に発生した場合でも目標時間内に完了させるための機能を備えており、これらの機能によりリアルタイム性を保証する。多くの組込みシステムにおいて、リアルタイムＯＳとしてＩＴＲＯＮ仕様に準拠したものが用いられており、各開発企業は、ＩＴＲＯＮのソフトウェア資産を多く所有する。なお、「ソフトウェア資産」とは、組込みシステムを構成するプログラム自体のみならず、システムの動作検証を行うプログラムや、そのシステムのために開発したソフトウェア部品やライブラリなどを含む。

近年、組込み機器の機能が向上し、ネットワークを介して他の機器と通信できる機能、取り扱うデータの再生、保存、管理のためのファイルシステム機能が不可欠となっており、さらに、ＵＳＢ／ＩＥＥＥ１３９４／Ｓｅｒｉａｌ ＡＴＡ／ＨＤＭＩなどのインタフェースを介して様々な機器と接続できることが要求されている。これらの機能を実現するためには、従来のＲＴＯＳでは対応しきれないという問題がある。

そこで、パーソナルコンピュータ（以下ＰＣ）向けのＯＳ（例えばＬｉｎｕｘ）の機能やソフトウェアを有効活用するという観点から、組込み機器で使用されるＯＳとして、ＰＣ向けのＯＳをベースとしたものを採用するという動きがある。

通常、ＰＣ向けのＯＳは、リアルタイム性を有しないので、組込み機器に適用するためにはリアルタイム性を保証するための工夫が必要である。そのため、リアルタイム処理を実現するための仕組みを備えたＲＴ ＬｉｎｕｘやＴｉｍｅＳｙｓ ＬｉｎｕｘなどのＯＳが開発されている。これらは、カーネルモードでプログラムを動作させる仕組みを有し、カーネルモードで動作するプログラムを優先的に動作させる。カーネルモードで動作するプログラムは、仮想化処理を介さずに直接ハードウェア制御を行うことができる。このようなプログラムと、通常のＬｉｎｕｘプロセスとは、特殊なインタフェース（ＡＰＩ）を使って情報通知を行う。カーネルモードで動作するプログラムは、通常のＬｉｎｕｘプロセスと開発方法が異なるため、それらの機能やＡＰＩについて、通常のＬｉｎｕｘプロセスの開発エンジニアを再教育する必要がある。勿論、ＲＴＯＳの技術者は、上記機能やＡＰＩの前に、まずＬｉｎｕｘを勉強する必要がある。

ＯＳの移行には、エンジニアの再教育のみならず、ツールの変更、ソフトウェア開発環境の移行、テスト資産の作り直しなども必要であるため、莫大なコストと時間がかかる。また、各開発企業が所有するＩＴＲＯＮのソフトウェア資産は、ＩＴＲＯＮ仕様のＯＳ上での動作を前提として作成されているので、ＯＳが移行すると、これらのソフトウェア資産は、無駄になってしまう。

そこで、リアルタイムＯＳと非リアルタイムＯＳがハードウェア資源を共有するハイブリッドシステムが注目されるようになっている。

非リアルタイムＯＳのＬｉｎｕｘを組込み産業界に浸透させ、周辺技術の標準化と情報交換を目的として活動しているＥｍｂｌｉｘ（日本エンベデッド リナックス コンソーシアム）には、３つのグループがあり、その１つである「ハイブリッドアーキテクチャＷＧ」では、ＬｉｎｕｘとＲＴＯＳについてのハイブリッド仕様の策定を行っている。

非特許文献１は、Ｅｍｂｌｉｘが定めたＬｉｎｕｘとＲＴＯＳのハイブリッド構造に関する仕様の第１版である。以下の説明において、非リアルタイムＯＳとＲＴＯＳの「ハイブリッド構造」とは、該仕様により定められたように、非リアルタイムＯＳとＲＴＯＳの２つのＯＳは１つのＣＰＵ上で動作し、非リアルタイムＯＳとＲＴＯＳのシステムは、それぞれのカーネルで制御を行うと共に、非リアルタイムＯＳは、ＲＴＯＳの最も優先度の低いタスク（以下Ｌｉｎｕｘタスクという）として動作する構造を指す。

図８は、ＬｉｎｕｘとＲＴＯＳのハイブリッド構造のモデルを示す。このような構造を有するシステムでは、Ｌｉｎｕｘの機能を利用しながら、ＩＴＲＯＮのソフトウェア資産を使用することができる。また、割込み調停機能と割込マスクにより、リアルタイム性を保証することができる。ここで、該仕様に定められた優先順位（非特許文献１のページ５）と、割込調停機能（非特許文献１のページ２７）と、割込マスク（非特許文献１のページ４８）について説明する。

上記仕様では、実装上の例外を除き、高い優先順位から、ＲＴＯＳ側割込処理、ＲＴＯＳ側カーネルとスケジューラ、ＲＴＯＳ側タスク、Ｌｉｎｕｘ側割込処理、Ｌｉｎｕｘ側カーネルとボトムハーフとスケジューラ、Ｌｉｎｕｘ側プロセスの順で優先順位が規定されている。

割込調停機能は、発生した割込みを受け取り、割込み要因に応じてＬｉｎｕｘ側で処理すべきかＲＴＯＳ側で処理すべきかを判定して、当該ＯＳ側の割込ハンドラに制御を渡す機能である。判定に際して、ＲＴＯＳのリアルタイム性を損なわないように、ＲＴＯＳ側で処理すべきかどうかの判定を先に行う。

割込マスクとは、ＲＴＯＳ環境の動作中に、Ｌｉｎｕｘ側の割込要因をマスクすることを意味する。割込マスクにより、Ｌｉｎｕｘ側の割込要因に対応する割込み、すなわちＬｉｎｕｘ側で処理される割込みは禁止される。割込調停機能は、Ｌｉｎｕｘタスクが動作している間のみ割込マスクを解除し、Ｌｉｎｕｘタスク以外が動作している間は割込マスクをする。こうすることにより、仕様で定められた上記優先順位が守られる。本発明の説明において、割込要因のマスクと、該割込要因に対応する割込みの禁止とを同じ意味で使用する。

非特許文献２には、ハイブリッド構造のシステムにおける割込み制御機能の実装手法を開示している（非特許文献２のＰ１８−１９）。この手法は、特許文献１と特許文献２の割込処理技術を、ハイブリッド構造に適用している。なお、特許文献２は、特許文献１の出願を分割して出願したものであるため、以降では、特許文献１を参照して説明する。

特許文献１に開示された割込処理技術は、リアルタイム性が担保された所定の割込処理を実行するＯＳ支援システムと、割込管理機能を有するＯＳとを同一の情報処理装置に共存させ、ＯＳ支援システムにより、該情報処理装置で発生した割込要求を先取りして、この割込要求が上記所定の割込処理に対応するものであるかどうかを判定する。ＯＳ支援システムは、上記所定の割込処理に対応する割込要求の場合はＯＳ支援システム自身でその割込処理を実行し、上記所定の割込処理に対応しない割込要求の場合はその制御権をＯＳへ移行させる。図９は、特許文献１に開示された割込処理技術を示すフローチャートであり、特許文献１の図７に対してステップ番号を変更したものである。

図９に示すように、割込要求が発生した際に、ＯＳ支援システムは、割込判定で使用するＣＰＵのレジスタを保存すると共に割込要因を判定する（Ｓ１０、Ｓ１１）。割込要因が、ＯＳ支援システムが有する割込管理テーブルに予め登録された割込処理に対応する割込要因である（Ｓ１２：Ｙｅｓ）際に、ＯＳ支援システムは、ＣＰＵの残りのレジスタを保存して、当該割込要因に対応する割込処理プログラムを実行する（Ｓ１３、Ｓ１４）。その後、割込処理プログラムから制御権が戻ってきたとき、ＣＰＵのすべてのレジスタを復旧させ、割込を復帰させる（Ｓ１５、Ｓ１６）。

一方、割込要因が割込管理テーブルに登録された割込処理に対応する割込要因ではない場合に（Ｓ１２：Ｎｏ）、ＯＳ支援システムは、ステップＳ１０で保存したＣＰＵのレジスタを復旧させ、その割込要求についての制御権をＯＳ側に移行させる（Ｓ１７、Ｓ１８）。

このような構成では、リアルタイム性が要求される割込処理すなわち上記所定の割込処理をＯＳ支援システムの割込管理テーブルに予め登録しておけば、リアルタイム性が要求される割込処理がＯＳ支援システムの制御下で優先的に実行されるので、ＯＳに改造を加えることがなく、ＯＳのリアルタイム性を高めることができる。

非特許文献２に開示された実装手法は、下記の５点に配慮した上で、ＬｉｎｕｘとＲＴＯＳのハイブリッドシステムにおいて特許文献１と特許文献２の割込処理技術を適用したものである。

１．ＬｉｎｕｘとＲＴＯＳとで割込みの共有をしない。
これは、ＬｉｎｕｘとＲＴＯＳが１つのＣＰＵ上動作するハイブリッドシステムのハードウェア都合から、ハードウェア制御が複雑化になることを回避するためである。

２．割込要因の判定処理は、ＲＴＯＳ側が使用する割込要因かＬｉｎｕｘ側が使用する割込要因かを判定する。

３．ハイブリッドシステムの仕様で定められたように、ＲＴＯＳのリアルタイム性を損なわないように、割込要因の判定に際して、ＲＴＯＳ側で処理すべきかどうかの判定を優先して行う。

４．ＲＴＯＳのリアルタイム性を損なわないように、ＲＴＯＳ環境の動作中には、Ｌｉｎｕｘ側の割込要因をマスクする。

５．すべてのＲＴＯＳ側の処理（割込処理、カーネルおよびスケジューラ処理、ＲＴＯＳタスク処理）が終わり、Ｌｉｎｕｘタスクが再びスケジューリングされる際に、Ｌｉｎｕｘ側の割込要因に対するマスクを解除する。

このような割込制御により、Ｌｉｎｕｘの機能を利用可能にしながら、ＲＴＯＳのリアルタイム性も保証されるハイブリッドシステムを実現する。
特開２０００−３３０７９６号公報 特開２００３−２２３３３４号公報 "ＬｉｎｕｘにおけるＲＴＯＳとのハイブリッド構成に関する仕様（第１版）"，２００２年８月１０日，インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｅｍｂｌｉｘ．ｏｒｇ／ＰＤＦ／ｅｍｂｌｉｘ＿ｈａｗｇ０３０１．ｐｄｆ＞ "Ｌｉｎｕｘ ｏｎ ＩＴＲＯＮ ハイブリッド構造の実装"，インターネット＜ｈｔｔｐ：／／ｗｗｗ．ｅｌｗｓｃ．ｃｏ．ｊｐ／ｊａｐａｎｅｓｅ／ｐｒｏｄｕｃｔｓ／ａｃｃｅｌ＿ｌｉｎｕｘ．ｈｔｍｌ＞

非特許文献２に具体的なフローは開示されていないが、上記割込制御は、図１０に示すフローが考えられる。図１０において、分かりやすいように、図９に示すフローと異なるステップを太線で示す。また、図９に示すフローと同じステップについては細線で示すと共に、図９と同様のステップ番号を付与する。

図１０に示すように、割込みが発生した際に、まず、割込判定で使用するＣＰＵのレジスタの保存と、割込要因の判定が行われる（Ｓ１０、Ｓ１１）。この割込要因は、ＲＴＯＳ側が使用する割込要因、すなわちＲＴＯＳ側が処理する割込処理に対応する割込要因である場合は（Ｓ１００：Ｙｅｓ）、ＣＰＵの残りのレジスタは保存され、Ｌｉｎｕｘ側が使用するすべての割込要因はマスクされる（Ｓ１３、Ｓ１０２）。この時点で、Ｌｉｎｕｘタスクはペンディングされる。

続いて、上記割込要因に対応する割込処理プログラム（ＲＴＯＳの割込処理プログラム）は起動され、割込処理は実行される（Ｓ１４）。その後、Ｌｉｎｕｘシステムへすぐには復帰せず、ＲＴＯＳシステムへ移行する（Ｓ１０４）。

ＲＴＯＳのスケジューラでＬｉｎｕｘタスクがスケジューリングされると（Ｓ１０６）、Ｌｉｎｕｘタスクは再起動される（Ｓ１０８）。ここで、Ｌｉｎｕｘ側が使用する割込要因のマスクの解除がなされる（Ｓ１１０）。そして、全てのＣＰＵのレジスタの復旧（Ｓ１５）を経て、Ｌｉｎｕｘシステムは復帰する（Ｓ１１２）。

一方、ステップＳ１００における判定の結果、割込要因はＬｉｎｕｘ側が処理する割込処理に対応する割込要因である場合（Ｓ１００：Ｎｏ）、ステップＳ１０で保存したＣＰＵのレジスタが復旧され、その割込要求についての制御権はＬｉｎｕｘに移行される（Ｓ１７、Ｓ１２０）。これにて、Ｌｉｎｕｘシステムは復帰する（Ｓ１２２）。

ここで、Ｌｉｎｕｘ側が使用する割込要因がすべてマスクされている間、すなわち図１０のステップＳ１４〜Ｓ１０８の間について考える。以下、この期間を「マスク期間」という。

上述したように、マスク期間において、Ｌｉｎｕｘ側の割込要因がマスクされるため、Ｌｉｎｕｘタスクはペンディングされる。そのため、Ｌｉｎｕｘ側の割込要因は、この期間内では発生しない。

一方、マスク期間においても、ＲＴＯＳタスク処理中に発生する割込み、ＲＴＯＳのカーネル／スケジューラ動作中に発生する割込み、割込処理中に発生する割込み（多重割込み）など、様々なＲＴＯＳ側の割込要因は発生し得る。

これらの割込みが発生する度に、図１０に示す処理が行われる。マスク期間中においては、ＲＴＯＳ側の割込要因のみが発生し得るので、ステップＳ１００の判定結果が常にＹｅｓとなる。また、マスク期間中につき、Ｌｉｎｕｘ側の割込要因が既にマスクされているにもかかわらず、ステップＳ１００の判定結果がＹｅｓであるために、ステップＳ１０２のマスク処理が行われる。これでは、結果がＹｅｓであると自明な割込要因判定処理や、既にマスク処理が施されているにもかかわらず再度マスク処理を行うといった無駄な処理が実行されることになる。

通常、割込処理は軽量かつ高速であることが求められる。リアルタイム性が要求される場合はなおさらである。図１０に示す割込制御フローは、Ｌｉｎｕｘタスクの実行中では妥当といえるが、Ｌｉｎｕｘ側の割込要因がマスクされ、Ｌｉｎｕｘタスクがペンディングされている期間中にもそのまま適用するのでは、無駄な処理が生じ、ＲＴＯＳ側の割込応答性能ないしリアルタイム性が悪化するという問題がある。

本発明の一つの態様は、ハイブリッドシステムである。このシステムは、ＣＰＵを含むハードウェア資源と、第１のＯＳと、第２のＯＳと、割込制御部とを備える。

第２のＯＳは、第１のＯＳとハードウェア資源を共有し、第１のＯＳの優先度の最も低いタスクである第２ＯＳタスクとして動作する。

割込制御部は、第２のＯＳ側の割込要因がマスクされていないときの割込要求に対して、第１のＯＳ側の割込要因か第２のＯＳ側の割込要因かの判定をし、第２のＯＳ側の割込要因であるときに、該割込要求に対する制御権を前記第２のＯＳに移行させ、第１のＯＳ側の割込要因であるときに、第２のＯＳ側の割込要因をマスクするマスクを行うと共に制御権を第１のＯＳに移行させ、その後、第１のＯＳが第２ＯＳタスクをスケジューリングするようになったときに第２のＯＳ側の割込要因へのマスクを解除する。また、割込制御部は、第２のＯＳ側の割込要因がマスクされている間の割込要求に対して、第１のＯＳによる制御権の保持を継続させる。

なお、上記態様のハイブリッドシステムを装置に置き換えて表現したものや、該ハイブリッドシステムにおける割込制御の手法や、該割込制御をコンピュータに実行せしめるプログラムは、本発明の態様としては有効である。

本発明にかかる技術によれば、非リアルタイムＯＳとリアルタイムＯＳがハードウェア資源を共有するハイブリッドシステムにおいて、リアルタイムＯＳの割込応答性能の悪化を軽減できる。

以下、図面を参照して本発明の実施の形態を説明する。
＜第１の実施の形態＞

図１は、本発明の第１の実施の形態にかかるハイブリッドシステム１００を示す。ハイブリッドシステム１００は、リアルタイムＯＳ（ＲＴＯＳ）と、非リアルタイムＯＳ（ここで例としてＬｉｎｕｘ）とがハイブリッド構造で実装された情報処理装置例えば携帯端末装置であり、Ｌｉｎｕｘ１２０とＲＴＯＳ１３０以外に、ＣＰＵ１１０と、固定メモリ１４０と、制御システム１５０と、入力装置１６０と、出力装置１７０と、シリアル装置１８０と、入出力制御部１９０を備える。図１において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。また、説明の明確化のため、以下の記載及び図面は、適宜、省略及び簡略化がなされている。

ＣＰＵ１１０、入力装置１６０、出力装置１７０、シリアル装置１８０、入出力制御部１９０は、通常の携帯端末装置に備えられたものと同様であり、ここで詳細な説明を省略する。但し、本実施の形態において、ＣＰＵ１１０は、割込みが発生したときに参照するアドレス（以下割込参照アドレスという）の変更が可能なものである。

Ｌｉｎｕｘ１２０とＲＴＯＳ１３０は、ハイブリッド構造で実装されており、割込みを共有しないようになっている。

固定メモリ１４０は、Ｌｉｎｕｘ１２０、ＲＴＯＳ１３０、および制御システム１５０が動作するための様々なデータを格納している。

図２は、Ｌｉｎｕｘ１２０、ＲＴＯＳ１３０、固定メモリ１４０の詳細構成、およびこれらの機能ブロックと制御システム１５０の接続関係を示す図である。制御システム１５０は、入出力制御部１９０を介して上記各機能ブロックと接続されるが、分かりやすいように、図２では入出制御部１９０を省略する。図示のように、Ｌｉｎｕｘ１２０は、Ｌｉｎｕｘ側アプリケーション（ＡＰ）１２２と、割込実行部１２４と、割込管理部１２６を備える。ＲＴＯＳ１３０は、ＲＴＯＳ側アプリケーション（ＡＰ）１３２と、割込実行部１３４と、割込管理部１３６を備える。固定メモリ１４０は、Ｌｉｎｕｘ１２０により管理されるＬｉｎｕｘベクタ領域１４２と、制御システム１５０により管理される拡張ベクタ領域１４４と、Ｌｉｎｕｘ１２０とＲＴＯＳ１３０と制御システム１５０とで共通に使用される共通データ領域１４６と、ＲＴＯＳ１３０により管理されるＲＴＯＳベクタ領域１４８を有する。

Ｌｉｎｕｘ１２０において、割込管理部１２６は、Ｌｉｎｕｘベクタ領域１４２を参照してＬｉｎｕｘ側の割込処理を管理し、割込実行部１２４は、Ｌｉｎｕｘ側の割込処理を実行する。

ＲＴＯＳ１３０において、割込管理部１３６は、ＲＴＯＳベクタ領域１４８を参照してＲＴＯＳ側の割込処理を管理し、割込実行部１３４は、ＲＴＯＳ側の割込処理を実行する。

図３は、固定メモリ１４０の各領域に格納されたデータの詳細を示す。
Ｌｉｎｕｘベクタ領域１４２には、Ｌｉｎｕｘ１２０側で割込処理を行う場合にＬｉｎｕｘ１２０内の割込処理ルーチンに制御権が移るように、割込要因（Ｌｉｎｕｘ側の割込要因）毎の起動プログラムのアドレス（ポインタ）が設定されている。

拡張ベクタ領域１４４には、制御システム１５０側の各種機能を実現するプログラム（後述する割込制御処理のプログラムを含む）のアドレスが設定されている。

共通データ領域１４６には、Ｌｉｎｕｘ１２０とＲＴＯＳ１３０と制御システム１５０の仲介をなすデータが設定されている。これらのデータは、Ｌｉｎｕｘ１２０の初期化処理時に参照される制御システム１５０の初期化処理用プログラムのアドレスと、ＲＴＯＳ１３０のスケジューラ起動プログラムのアドレスと、各種割込情報のアドレスと、情報書込処理ルーチンのアドレスと、書込対象となる情報のアドレスと、情報読出ルーチンのアドレスと、読出対象となる情報のアドレスを含む。なお、制御システム１５０の初期化処理用プログラムのアドレスと、各種割込情報のアドレスと、情報書込処理ルーチンのアドレスは、共通データ領域１４６が配置された時点で設定され、ＲＴＯＳ１３０のスケジューラ起動プログラムのアドレスと、情報読出ルーチンのアドレスと、読出対象となる情報のアドレスは、Ｌｉｎｕｘ１２０とＲＴＯＳ１３０の初期化時に設定される。

ＲＴＯＳベクタ領域１４８には、ＲＴＯＳ１３０側で割込処理を行う場合にＲＴＯＳ内の割込処理ルーチンに制御権が移るように、割込要因（ＲＴＯＳ側の割込要因）毎の起動プログラムのアドレスが設定されている。

図４は、制御システム１５０を示す。制御システム１５０は、初期化部１５１と、割込管理部１５２と、制御実行部１５８を備え、割込管理部１５２は、割込管理テーブル１５３を有する。

初期化部１５１は、Ｌｉｎｕｘ１２０とＲＴＯＳ１３０の初期化処理時に、制御システム１５０の初期化処理用プログラムがＣＰＵ１１０で実行されることにより形成される。制御システム１５０の初期化処理用プログラムのアドレスは、固定メモリ１４０の共通データ領域１４６に格納されている。

初期化部１５１は、まず、Ｌｉｎｕｘ１２０が自身の初期化処理時にＣＰＵ１１０に通知することにより設定されるＬｉｎｕｘベクタ領域１４２のベースアドレスを参照し、そのベースアドレスを自システム内データとして拡張ベクタ領域１４４に保持する。また、初期化部１５１は、ＲＴＯＳ１３０が自身の初期化処理時にＣＰＵ１１０に通知することにより設定されるＲＴＯＳベクタ領域１４８のベースアドレスも、自システム内データとして拡張ベクタ領域１４４に保持する。その後、拡張ベクタ領域１４４のベースアドレスをＣＰＵ１１０に通知する。前述したように、本実施の形態において、ＣＰＵ１１０は割込参照アドレスの変更ができる。したがって、初期化部１５１からの拡張ベクタ領域１４４のベースアドレスの通知により、初期化処理後に初めて割込みが発生した際に、ＣＰＵ１１０は、拡張ベクタ領域１４４のベースアドレスを参照することになる。これにより、制御システム１５０は、初期化処理後に初めて割込みが発生した際に、ＣＰＵ１１０からの割込要求を先取りできるようになる。

初期化部１５１は、また、自システム（制御システム１５０）の制御対象となるハードウェア例えばシリアル装置１８０の割込状態の初期化を行うと共に、割込管理部１５２の割込管理テーブル１５３に、リアルタイム性が要求される割込処理に対応する割込要因と、当該割込処理を担う割込処理プログラムのアドレスとを対応付けて登録する。実際には、ハードウェア初期化処理ルーチンや割込管理部１５２の機能を形成するためのプログラムを呼び出して実行させる。

図５は、割込管理テーブル１５３の登録内容を示す。本実施の形態において、リアルタイム性が要求される割込要因とは、ＲＴＯＳ１３０により処理されるべき割込処理に対応する割込要因であり、割込管理テーブル１５３には、ＲＴＯＳ１３０により処理されるべき割込処理に対応する割込要因と、当該割込処理プログラムのアドレスとを対応付けて登録されている。なお、割込管理テーブル１５３におけるデータ「０」は、当該割込要因に対応する割込処理がＬｉｎｕｘ側により処理されるべき割込処理であり、リアルタイム性を要求されていないことを示す。

制御実行部１５８は、ＣＰＵ１１０が参照するアドレスが拡張ベクタ領域１４４のベースアドレスであるときに起動され、割込発生時に割込制御処理を行う。図６は、制御実行部１５８による割込制御処理を示すフローチャートである。図６において、太線により示されるステップＳ２２４とＳ２３２は、本発明の特徴部分である。

制御実行部１５８は、まず、余分なオーバーヘッドを回避するために、ＣＰＵ１１０の動作環境の一部、例えばＣＰＵ１１０のレジスタのうちの、割込判定に使用する部分を図示しないスタック内に一時的に保存した上で、割込要求を取得して割込判定を行う（Ｓ２００、Ｓ２０２）。割込判定は、当該割込要求に対応する割込要因がＲＴＯＳ１３０側が使用するものかＬｉｎｕｘ１２０側が使用するものかを判定する処理であり、図４に示す割込管理部１５２に設けられた割込管理テーブル１５３の登録内容に基づいて行われる。具体的には、「０」に対応する割込要因（図５に示す例では割込要因０、割込要因２、割込要因４、割込要因５）をＬｉｎｕｘ側が使用する割込要因であると判定し、「０」以外に対応する割込要因（例えば図５に示す例における割込要因１、割込要因３）をＲＴＯＳ側が使用する割込要因であると判定する。

ステップＳ２０２における割込判定の結果、ＲＴＯＳ側が使用する割込要因ではない、すなわちＬｉｎｕｘ側が使用する割込要因である場合（Ｓ２０４：Ｎｏ）、制御実行部１５８は、ステップＳ２００で保存したＣＰＵ１１０のレジスタを復旧させて（Ｓ２１０）、その割込要求に対する制御権をＬｉｎｕｘ１２０に移行させ、Ｌｉｎｕｘシステムを復帰させる（Ｓ２１２、Ｓ２１４）。具体的には、初期化部１５１が初期化処理時に拡張ベクタ領域１４４に保存したＬｉｎｕｘベクタ領域１４２のベースアドレスから割込要求に対応したＬｉｎｕｘ１２０側の起動プログラムのアドレスを知り、そのアドレスのプログラムに制御権を渡す。これにより、Ｌｉｎｕｘ１２０の割込実行部１２４により、当該割込処理が実行される。

一方、ステップＳ２０２における割込判定の結果、ＲＴＯＳ側が使用する割込要因である場合（Ｓ２０４；Ｙｅｓ）、制御実行部１５８は、ＣＰＵ１１０の残りのレジスタを保存する（Ｓ２２０）と共に、Ｌｉｎｕｘ１２０側が使用する割込要因を全てマスクする（Ｓ２２２）。これにより、Ｌｉｎｕｘタスクはペンディングされる。

そして、制御実行部１５８は、ＲＴＯＳベクタ領域１４８のベースアドレスをＣＰＵ１１０に通知すると共に、制御権をＲＴＯＳ１３０に移行させる（Ｓ２２４、Ｓ２２６）。制御権をＲＴＯＳ１３０に移行させる際に、制御実行部１５８は、具体的には、共通データ領域１４６からＲＴＯＳ側スケジューラ起動プログラムのアドレスを知り、そのアドレスのプログラムに制御権を渡す。

その後、ＲＴＯＳシステムがＬｉｎｕｘタスクのスケジューリングを再び開始した後、制御実行部１５８は、ＲＴＯＳ側から制御権が戻るまで（Ｓ２２８：Ｎｏ）待機する。ＲＴＯＳ側から制御権が戻ると(Ｓ２２８：Ｙｅｓ）、制御実行部１５８は、ステップＳ２２２で行ったマスクを解除する（Ｓ２３０）。そして、拡張ベクタ領域１４４のベースアドレスをＣＰＵ１１０に通知すると共に、ＣＰＵ１１０の全てのレジスタを復旧させ、制御権をＬｉｎｕｘ１２０に移行させる（Ｓ２３２、Ｓ２３４、Ｓ２３６）。

ステップＳ２２６でＲＴＯＳ側への移行が行われた後、ＲＴＯＳシステムの処理が行われる。これらの処理は、具体的には、ＲＴＯＳ割込処理、ＲＴＯＳカーネル処理、ＲＴＯＳスケジューリング処理、ＲＴＯＳタスク処理などである。前述したように、ハイブリッドシステムにおいて、ＬｉｎｕｘはＲＴＯＳのタスクの一つ（Ｌｉｎｕｘタスク）として動作しており、Ｌｉｎｕｘタスクは、ＲＴＯＳの全てのタスクの中で最も低い優先度を与えられている。そのため、一旦ＲＴＯＳ１３０に制御権が渡ると、ＲＴＯＳシステムの処理として必要な処理が全て完了するまで、制御権はＬｉｎｕｘ側に戻されることがない。

すなわち、ステップＳ２２２（Ｌｉｎｕｘ側が使用する全ての割込要因のマスク）から、ステップＳ２２８（ＲＴＯＳ側からの復帰）まで、Ｌｉｎｕｘ側が使用する割込要因は、発生することがない。

本実施の形態において、ステップＳ２２４では、制御実行部１５８は、ＲＴＯＳベクタ領域１４８のベースアドレスをＣＰＵ１１０に通知する。これにより、その後に割込みが発生した際に、ＣＰＵ１１０がＲＴＯＳベクタ領域１４８を参照することにより、ＲＴＯＳ側起動プログラムに含まれるＲＴＯＳ割込処理のプログラムが起動される。このＲＴＯＳ割込処理プログラムは、ＲＴＯＳシステムが単体で動作する場合の割込処理を行うプログラムと同一であり、ＲＴＯＳ１３０の割込実行部１３４と割込管理部１３６により実行される。

図７は、割込実行部１３４と割込管理部１３６によるＲＴＯＳ割込処理のフローチャートを示す。割込が発生した際に、割込管理部１３６は、ＣＰＵ１１０のレジスタを保存すると共に、該割込みの内容に対応する割込処理プログラムのアドレスを割込実行部１３４に提供する（Ｓ３００、Ｓ３０２）。割込実行部１３４は、割込管理部１３６からアドレスが提供されたプログラムを実行して割込処理を行う（Ｓ３０４）。図７に示す処理は、ＣＰＵ１１０に通知された割込用のベースアドレスがＲＴＯＳベクタ領域１４８である限り、割込みが生じる度に行われる。

図６において、ＲＴＯＳシステムの処理が完了すると（Ｓ２２８：Ｙｅｓ）、制御実行部１５８は、Ｌｉｎｕｘ側の割込要因のマスクを解除すると共に、拡張ベクタ領域１４４のベースアドレスをＣＰＵ１１０に通知する（Ｓ２３０、Ｓ２３２）。これにより、その後、割込みが発生すると、ＣＰＵ１１０が拡張ベクタ領域１４４のベースアドレスを参照するため、図６に示す制御実行部１５８による割込制御処理が実行される。

こうすることにより、Ｌｉｎｕｘタスクの動作中においてのみ、割込みが発生した際に図６に示す処理フローが実施され、Ｌｉｎｕｘ側の割込要因がマスクされて、Ｌｉｎｕｘタスクがペンディングされている間には、図７に示すＲＴＯＳ割込処理が実行される。そのため、図１０に示す従来の割込処理のフローにあった無駄な処理（Ｌｉｎｕｘ側の割込要因がマスクされている間の、割込要因がＬｉｎｕｘ側のものかＲＴＯＳ側のものかの判定と、既にマスクされているＬｉｎｕｘ側の割込要因のさらなるマスク）を回避することができる。その結果、ＲＴＯＳの割込応答性能が向上し、高いリアルタイム性を保証することができる。
＜第２の実施の形態＞

第１の実施の形態において、制御システム１５０は、Ｌｉｎｕｘ側の割込要因のマスクと、Ｌｉｎｕｘ側の割込要因のマスク解除に伴って、割込みが発生したときにＣＰＵ１１０が参照するアドレス（割込参照アドレス）を、拡張ベクタ領域１４４とＲＴＯＳベクタ領域１４８のベースアドレス（先頭番地）間で切り替えることにより、Ｌｉｎｕｘ側の割込要因がマスクされていない間は割込要求を先取りし、Ｌｉｎｕｘ側の割込要因がマスクされている間は割込要求を先取りせずに、ＲＴＯＳ１３０により割込要求を受け取ることを実現している。この手法は、ＣＰＵ１１０は、割込参照アドレスの変更が可能であることを前提とする。本第２の実施の形態として、割込参照アドレスの変更ができないＣＰＵの場合の対応手法を説明する。

まず、割込参照アドレスを拡張ベクタ領域のベースアドレスに設定する。これにより、制御システムは常に割込要求を先取りする。

この場合、制御システムは、Ｌｉｎｕｘ側の割込要因がマスクされているか否かに応じ制御を行えばよい。具体的には、制御システムは、Ｌｉｎｕｘ側の割込要因をマスクした後解除するまでの間、割込要求に対する制御権を常にＲＴＯＳ側に渡すようにする。また、Ｌｉｎｕｘ側の割込要因がマスクされていない間には、割込要因がＬｉｎｕｘとＲＴＯＳのいずれで使用されるものかの判定を行って、判定結果に応じて制御権をＬｉｎｕｘまたはＲＴＯＳに渡す。ＲＴＯＳに渡す場合には、Ｌｉｎｕｘ側の割込要因をマスクし、ＲＴＯＳがＬｉｎｕｘタスクを再びスケジューリングするようになれば、マスクを解除する。なお、割込要求に対する制御権をＲＴＯＳまたはＬｉｎｕｘに渡すかの処理は、ＲＴＯＳ側スケジューラ起動プログラムのアドレスと、Ｌｉｎｕｘ側起動プログラムのアドレス間で切替可能なポインタを設けることにより実現できる。このポインタの切替えは、図６に示す処理におけるステップＳ２２４（ＲＴＯＳベクタ領域１４８のベースアドレスをＣＰＵに通知する処理）と、ステップＳ２３２（拡張ベクタ領域１４４のベースアドレスをＣＰＵに通知する処理）と同様の効用を有する。該制御システムの他の処理については、図６に示す処理と同様であるので、ここで詳細な説明を省略する。

本第２の実施の形態によれば、割込参照アドレスの変更ができないＣＰＵの場合にも、第１の実施の形態と同様の効果を得ることができる。

以上、実施の形態をもとに本発明を説明した。実施の形態は例示であり、本発明の主旨から逸脱しない限り、上述した各実施の形態に対してさまざまな変更、増減、組合せを行ってもよい。これらの変更、増減、組合せが行われた変形例も本発明の範囲にあることは当業者に理解されるところである。

本発明の第１の実施の形態にかかるハイブリッドシステムを示す図である。 図１に示すハイブリッドシステムにおけるＬｉｎｕｘ、ＲＴＯＳ、固定メモリ、制御システムを機能的に示す図である。 固定メモリの各領域の詳細を示す図である。 図１に示すハイブリッドシステムにおける制御システムを示す図である。 図２に示す制御システムにおける割込管理部の管理テーブルの登録例を示す図である。 図２に示す制御システムによる割込制御処理を示すフローチャートである。 ＲＴＯＳ内の割込処理を示すフローチャートである。 ハイブリッド構造のモデルを示す図である。 特許文献１による割込処理手法を示すフローチャートである。 非特許文献２による実装手法の考えられる処理フローを示すフローチャートである。

符号の説明

１００ ハイブリッドシステム
１１０ ＣＰＵ
１２０ Ｌｉｎｕｘ
１２２ Ｌｉｎｕｘ側ＡＰ
１２４ 割込実行部
１２６ 割込管理部
１３０ ＲＴＯＳ
１３２ ＲＴＯＳ側ＡＰ
１３４ 割込実行部
１３６ 割込管理部
１４０ 固定メモリ
１４２ Ｌｉｎｕｘベクタ領域
１４４ 拡張ベクタ領域
１４６ 共通データ領域
１４８ ＲＴＯＳベクタ領域
１５０ 制御システム
１５１ 初期化部
１５２ 割込管理部
１５３ 割込管理テーブル
１５８ 制御実行部
１６０ 入力装置
１７０ 出力装置
１８０ シリアル装置
１９０ 入出力制御部

Claims (16)

1. ＣＰＵを含むハードウェア資源と、
   第１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｙｔｅｍ）と、
   前記第１のＯＳと前記ハードウェア資源を共有し、前記第１のＯＳの優先度の最も低いタスクである第２ＯＳタスクとして動作する第２のＯＳと、
   割込制御部とを備えたハイブリッドシステムにおいて、
   前記割込制御部は、
   前記第２のＯＳ側の割込要因がマスクされていないときの割込要求に対して、
   前記第１のＯＳ側の割込要因か前記第２のＯＳ側の割込要因かの判定をし、
   前記第２のＯＳ側の割込要因であるときに、該割込要求に対する制御権を前記第２のＯＳに移行させ、
   前記第１のＯＳ側の割込要因であるときに、前記第２のＯＳ側の割込要因をマスクすると共に前記制御権を前記第１のＯＳに移行させ、その後、前記第１のＯＳが前記第２ＯＳタスクをスケジューリングするようになったときに前記第２のＯＳ側の割込要因へのマスクを解除し、
   前記第２のＯＳ側の割込要因がマスクされている間の割込要求に対して、
   前記第１のＯＳによる前記制御権の保持を継続させることを特徴とするハイブリッドシステム。
2. 前記ＣＰＵは、割込みが発生したときに参照するアドレスである割込参照アドレスの変更が可能なものであり、
   前記割込制御部は、
   前記第２のＯＳ側の割込要因へのマスクを解除するときに、前記割込参照アドレスが、該割込制御部の起動プログラムのアドレスになり、
   前記第２のＯＳ側の割込要因をマスクするときに、前記割込参照アドレスが、前記第１のＯＳ内で割込処理を制御するプログラムのアドレスになるように前記ＣＰＵの割込参照アドレスを書き換えることを特徴とする請求項１に記載のハイブリッドシステム。
3. 割込みが発生したときに前記ＣＰＵが参照する割込参照アドレスを格納する拡張ベクタ領域をさらに備え、
   前記ＣＰＵは、割込参照アドレスの変更が不可能なものであり、
   前記拡張ベクタ領域に格納された割込参照アドレスは、前記割込制御部の起動プログラムのアドレスであることを特徴とする請求項１に記載のハイブリッドシステム。
4. 前記第１のＯＳは、前記第２のＯＳよりリアルタイム性が高いＯＳであることを特徴とする請求項１から３のいずれか１項に記載のハイブリッドシステム。
5. 前記第１のＯＳはリアルタイムＯＳであり、前記第２のＯＳはＬｉｎｕｘであることを特徴とする請求項４に記載のハイブリッドシステム。
6. 第１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｙｔｅｍ）と、ＣＰＵを含むハードウェア資源を前記第１のＯＳと共有し、前記第１のＯＳの優先度の最も低いタスクである第２ＯＳタスクとして動作する第２のＯＳとを備えたハイブリッドシステムにおける割込制御装置であって、
   前記割込制御部は、
   前記第２のＯＳ側の割込要因がマスクされていないときの割込要求に対して、
   前記第１のＯＳ側の割込要因か前記第２のＯＳ側の割込要因かの判定をし、
   前記第２のＯＳ側の割込要因であるときに、該割込要求に対する制御権を前記第２のＯＳに移行させ、
   前記第１のＯＳ側の割込要因であるときに、前記第２のＯＳ側の割込要因をマスクすると共に前記制御権を前記第１のＯＳに移行させ、その後、前記第１のＯＳが前記第２ＯＳタスクをスケジューリングするようになったときに前記第２のＯＳ側の割込要因へのマスクを解除し、
   前記第２のＯＳ側の割込要因がマスクされている間の割込要求に対して、
   前記第１のＯＳによる前記制御権の保持を継続させることを特徴とする割込制御装置。
7. 前記ＣＰＵは、割込みが発生したときに参照するアドレスである割込参照アドレスの変更が可能なものであり、
   前記第２のＯＳ側の割込要因へのマスクを解除するときに、前記割込参照アドレスが、該割込制御部の起動プログラムのアドレスになり、
   前記第２のＯＳ側の割込要因をマスクするときに、前記割込参照アドレスが、前記第１のＯＳ内で割込処理を制御するプログラムのアドレスになるように前記ＣＰＵの割込参照アドレスを書き換えることを特徴とする請求項６に記載の割込制御装置。
8. 前記ＣＰＵは、割込みが発生したときに参照する割込参照アドレスの変更が不可能なものであり、
   自身の起動プログラムのアドレスが前記割込参照アドレスに設定され、割込が発生したときに割込要求を先取りすることを特徴とする請求項６に記載の割込制御装置。
9. 前記第１のＯＳは、前記第２のＯＳよりリアルタイム性が高いＯＳであることを特徴とする請求項６から８のいずれか１項に記載の割込制御装置。
10. 前記第１のＯＳはリアルタイムＯＳであり、前記第２のＯＳはＬｉｎｕｘであることを特徴とする請求項９に記載の割込制御装置。
11. 第１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｙｔｅｍ）と第２のＯＳがハードウェア資源を共有し、前記第２のＯＳが、前記第１のＯＳの優先度の最も低いタスクである第２ＯＳタスクとして動作するハイブリッドシステムにおける割込制御方法であって、
    前記第２のＯＳ側の割込要因がマスクされていないときの割込要求に対して、
    前記第１のＯＳ側の割込要因か前記第２のＯＳ側の割込要因かの判定をし、
    前記第２のＯＳ側の割込要因であるときに、該割込要求に対する制御権を前記第２のＯＳに移行させ、
    前記第１のＯＳ側の割込要因であるときに、前記第２のＯＳ側の割込要因をマスクすると共に前記制御権を前記第１のＯＳに移行させ、その後、前記第１のＯＳが前記第２ＯＳタスクをスケジューリングするようになったときに前記第２のＯＳ側の割込要因へのマスクを解除し、
    前記第２のＯＳ側の割込要因がマスクされている間の割込要求に対して、
    前記第１のＯＳによる前記制御権の保持を継続させることを特徴とする割込制御方法。
12. 前記第１のＯＳは、前記第２のＯＳよりリアルタイム性が高いＯＳであることを特徴とする請求項１１に記載の割込制御方法。
13. 前記第１のＯＳはリアルタイムＯＳであり、前記第２のＯＳはＬｉｎｕｘであることを特徴とする請求項１２に記載の割込制御方法。
14. 第１のＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｙｔｅｍ）と第２のＯＳがハードウェア資源を共有し、前記第２のＯＳが、前記第１のＯＳの優先度の最も低いタスクである第２ＯＳタスクとして動作するハイブリッドシステムにおける割込制御処理をコンピュータに実行せしめるプログラムであって、
    前記第２のＯＳ側の割込要因がマスクされていないときの割込要求に対して、
    前記第１のＯＳ側の割込要因か前記第２のＯＳ側の割込要因かの判定をし、
    前記第２のＯＳ側の割込要因であるときに、該割込要求に対する制御権を前記第２のＯＳに移行させ、
    前記第１のＯＳ側の割込要因であるときに、前記第２のＯＳ側の割込要因をマスクすると共に前記制御権を前記第１のＯＳに移行させ、その後、前記第１のＯＳが前記第２ＯＳタスクをスケジューリングするようになったときに前記第２のＯＳ側の割込要因へのマスクを解除し、
    前記第２のＯＳ側の割込要因がマスクされている間の割込要求に対して、
    前記第１のＯＳによる前記制御権の保持を継続させることをコンピュータに実行せしめることを特徴とするプログラム。
15. 前記第１のＯＳは、前記第２のＯＳよりリアルタイム性が高いＯＳであることを特徴とする請求項１４に記載のプログラム。
16. 前記第１のＯＳはリアルタイムＯＳであり、前記第２のＯＳはＬｉｎｕｘであることを特徴とする請求項１５に記載のプログラム。

Images