JP2008186357A - データ処理装置 - Google Patents

Abstract

【課題】マルチＯＳ及びマルチプロセッサのデータ処理環境においてプロセッサ間通信を行うソフトウェアの開発コストを下げる。
【解決手段】ハードウェア構成やＯＳの相違を隠蔽するための管理プログラム（ＭＮＧ０〜ＭＮＧ２）をＯＳ毎に動作させて常駐させる。この管理プログラムが操作するデータベース(ＭＢＤ)を用意し、このデータベースは、ＯＳの管理のもとで処理されるハードウェア制御やソフトウェア処理のためのタスクと所属ＯＳとの対応関係等を複数のＯＳに亘って定義する。管理プログラムがタスクの起動要求を検出すると、そのタスクに対応するエントリをデータベースから抽出する。抽出されたエントリが保有する所属ＯＳが自ＯＳであれば当該ＯＳの管理のもとにそのタスクを処理させ、抽出されたエントリが保有する所属ＯＳが他ＯＳであればその起動要求を当該他ＯＳのプロセッサに渡して当該タスクを処理させる。
【選択図】図１

Description

本発明は、複数のＯＳ（Operating System）と複数のプロセッサを用いたデータ処理システムに関し、例えば複数のプロセッサと周辺回路デバイスをオンチップしたシステム・オン・チップ（ＳＯＣ）のＬＳＩ（半導体集積回路）に適用して有効な技術に関する。

１つのデータ処理システムに要求されるアプリケーション規模が増大されることにより、マルチプロセッサチップ、或いはマルチプロセッサを有するＳＯＣのＬＳＩなどのように、複数のプロセッサの機能を統合的に扱うシステム構成が用いられるようになってきている。このようなシステムにおいては、そのシステムを構成する複数のプロセッサ、周辺入出力回路及びメモリなどを統合的に管理する必要がある。この統合管理においては一のＯＳの管理の元で動作するプロセッサが、他のＯＳの管理の元で動作するプロセッサに特定のタスクを処理させたいとき、それらプロセッサ間での通信を行わなければならない。マルチプロセッサシステムにおけるプロセッサ間通信には、ＲＰＣ（リモート・プロシージャ・コール）のような手続を利用することができる。特許文献１にはＲＰＣを用いるファイルシステムが例示される。特許文献２には複数のデータプロセッサチップの一方のチップのＣＰＵから他方のチップの内部周辺回路デバイスをアクセス可能にするようなプロセッサ間通信技術について記載がある。

特開平８−３２８９３５号公報 国際公開第０２／０６１５９１号パンフレット

ＲＰＣの手続を利用すればソフトウェア開発者は通信プロトコルを記述する必要はない。しかしながら、アプリケーションプログラム上において通信を行うプロセッサを特定して、ＲＰＣを用いて通信することを個別に明示しなければならない。また、ＲＰＣにより異なるＯＳ間の通信に対応するのは難しい。異なるＯＳのもとで動作するプロセッサ間の通信を行うためには双方のＯＳに関するＡＰＩ（アプリケーション・プログラム・インタフェース）を満足させるようにプログラムを個別に記述しなければならない。ＡＰＩとは、あるＯＳ等のプラットフォーム向けのソフトウェアを開発するときに使用できる命令や関数の集合更にはそれを利用するためのプログラム上の手続きを定めた規約である。

このように、プロセッサ間通信を行うには通信部分をソフトウェア設計者が意識して記述する必要がある。それ故に、異なるプロセッサとの間で通信や制御を行うためのソフトウェアが複雑となり、ソフトウェア開発コスト増大の要因となる。また、システムを構成するプロセッサや周辺回路デバイスの増減により、プロセッサ間通信を制御する部分のソフトウェアを記述し直すことが必要になり、ソフトウェア移植性が低くなる。異種ＯＳ間の通信を行う際には統一的なＲＰＣプロトコルが存在しないため、特別なＲＰＣプロトコルを新たに開発する必要がある。

本発明の目的は、マルチＯＳ及びマルチプロセッサが混在するデータ処理環境において融通性の高いプロセッサ間通信が可能なデータ処理システムを実現することにある。

本発明の別の目的は、マルチＯＳ及びマルチプロセッサが混在するデータ処理環境においてプロセッサ間通信を行うソフトウェアの開発コストが低減されるデータ処理システムを実現することにある。

本発明の更に別の目的は、マルチＯＳ及びマルチプロセッサが混在するデータ処理環境においてプロセッサ間通信を行うソフトウェアの移植コストが低減されるデータ処理システムを実現することにある。

本発明の更に別の目的は、マルチＯＳ及びマルチプロセッサが混在するデータ処理環境において特定のハードウェアの使用不能状態に対しても当該ハードウェアの使用に匹敵するタスク処理を行なうことができるデータ処理システムを提供することにある。

本発明の前記並びにその他の目的と新規な特徴は本明細書の記述及び添付図面から明らかになるであろう。

本願において開示される発明のうち代表的なものの概要を簡単に説明すれば下記の通りである。

すなわち、マルチプロセッサを有し複数のＯＳが動作し得るデータ処理システムにおいて、ハードウェア構成やＯＳの相違を隠蔽するための管理プログラムをＯＳ毎に動作させて常駐させるようにする。この管理プログラムが操作するデータベースを用意し、このデータベースは、ＯＳの管理のもとで処理されるハードウェア制御やソフトウェア処理のためのタスクと所属ＯＳとの対応関係等を複数のＯＳに亘って定義する。管理プログラムがタスクの起動要求を検出すると、そのタスクに対応するエントリをデータベースから抽出する。抽出されたエントリが保有する所属ＯＳが自ＯＳであれば当該ＯＳの管理のもとにそのタスクを処理させ、抽出されたエントリが保有する所属ＯＳが他ＯＳであればその起動要求を当該他ＯＳのプロセッサに渡して当該タスクを処理させる。これによれば、他のＯＳに対する手続呼び出しは、管理プログラムを実行するプロセッサ間での通信という共通化された形式で実現される。ソフトウェア設計者はＯＳ間の通信が発生することを意識せずにソフトウェアを記述すればよい。データ処理システムの周辺回路デバイス等のハードウェアの変更に対し逐一ソフトウェアを変更しなくても済み、ＯＳ間通信の部分については管理データベースのエントリデータの変更で対処することが可能になる。異種ＯＳ間の通信であってもその通信プロトコルを意識する必要はない。異種ＯＳ間のソフトウェア移植も容易となる。

また、ハードウェア制御を行うタスクと当該タスクの処理をソフトウェア処理で行なうタスクとの夫々に対応するデータベースエントリを用意し、前者のタスクの起動が要求されたとき、管理プログラムに基づいて双方のタスクに対応するデータベースエントリを抽出するようにしておけば、前者のデータベースエントリからハードウェアの使用不能が検出されたときであっても、後者のデータベースエントリをその所属ＯＳの管理プログラムが利用できるようにする。これにより、ハードウェア制御を行うタスクに代えて当該タスクの処理をソフトウェアで実現可能になる。低消費電力のために一部ハードウェアの動作を停止させた状態でも当該ハードウェアを用いる処理に匹敵するタスク処理をソフトウェアで実現できる。システムの機能を犠牲にすることなくデータ処理システムの低消費電力を実現可能になる。

本願において開示される発明のうち代表的なものについて簡単に説明すれば下記のとおりである。

すなわち、マルチＯＳ及びマルチプロセッサが混在するデータ処理システムにおいて融通性の高いプロセッサ間通信が可能である。

また、マルチＯＳ及びマルチプロセッサが混在するデータ処理システムにおいてプロセッサ間通信を行うソフトウェアの開発コストが低減される。

また、マルチＯＳ及びマルチプロセッサが混在するデータ処理システムにおいてプロセッサ間通信を行うソフトウェアの移植コストが低減される。

また、マルチＯＳ及びマルチプロセッサが混在するデータ処理システムにおいて特定のハードウェアの使用不能状態に対しても当該ハードウェアの使用に匹敵するタスク処理を行なうことができる。

１．実施の形態の概要
先ず、本願において開示される発明の代表的な実施の形態について概要を説明する。代表的な実施の形態についての概要説明で括弧を付して参照する図面中の参照符号はそれが付された構成要素の概念に含まれるものを例示するに過ぎない。

〔１〕本発明の代表的な実施の形態に係るデータ処理システムは、複数のＯＳと複数のプロセッサを用いたシステムであり、前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベース（ＭＤＢ）と、前記ＯＳ毎に動作される管理プログラム（ＭＮＧ０〜ＭＮＧ２）と、を有する。一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリの所属ＯＳが前記一の管理プログラムの所属ＯＳであるときは当該所属ＯＳの管理のもとで当該タスクを処理し、前記選ばれたデータベースエントリの所属ＯＳが別の管理プログラムの所属ＯＳであるときは前記別の管理プログラムを実行するプロセッサに必要な情報、例えば前記選ばれたデータベースエントリの情報や前記タスクの起動要求に応ずる情報を渡して、前記別の管理プログラムの所属ＯＳによる管理のもとで当該タスクを処理させる。

上記した手段によれば、タスクの起動要求を受けたＯＳ側から他のＯＳ側に対する手続呼び出しは、管理プログラムを実行するプロセッサ間での通信という共通化された形式で実現される。ソフトウェア設計者はＯＳ間の通信が発生することを意識せずにソフトウェアを記述すればよい。データ処理システムの周辺回路デバイス等のハードウェアの変更に対し逐一ソフトウェアを変更しなくても済み、ＯＳ間通信の部分については管理データベースのエントリデータの変更で対処することが可能になる。異種ＯＳ間の通信であってもその通信プロトコルを意識する必要はない。異種ＯＳ間のソフトウェア移植も容易である。

前記複数のプロセッサは単一チップに形成されていてもよいし、複数チップに形成されていてもよい。

《双方向通信》一つの具体的な形態として、前記一の管理プログラムを実行するプロセッサは前記別の管理プログラムを実行するプロセッサと双方向通信可能である。原始的にタスクの起動要求を受けたＯＳ側から他のＯＳ側で処理されたタスクの結果を受け取ることができる。

《データベースエントリの構造》別の具体的な形態として、前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、及び当該タスクの稼働状況を夫々格納する領域を有し、前記タスクＩＤ及びタスクの稼働状況を夫々格納する領域は前記管理プログラムによって書換え可能な領域である。これにより管理プログラムはタスクの稼働状況を示す書き換え可能な領域からシステムの状態をダイナミックに把握して、起動が要求されたタスクの処理を、引き渡し可能な何れのＯＳの管理プログラムに引き渡すかを制御することが可能になる。

前記データベースエントリは、タスク実行環境を制限するタスク保護情報の格納領域を更に有してよい。例えば保護情報は所属ＯＳ以外からの処理要求に答えない、或いは特定のＯＳからの処理要求に対してだけ答えるというような制限である。

前記データベースエントリは、前記双方向通信に利用するバッファサイズを規定するバッファサイズ情報の格納領域を更に有してよい。前記双方向通信における情報のオーバーフロー若しくは取りこぼしを未然に防止することができる。

《データベース初期化》更に具体的な形態として、前記プロセッサはシステムの初期化指示に応答して起動するＯＳの下で、対応する管理プログラムを実行することによって前記データベースの可変領域に対する初期設定を行い、管理プログラムによる管理タスクは常駐タスクとされ、当該ＯＳのもとで動作するプロセッサに常駐する。これにより、データベースの可変領域は各管理プログラムに対応するＯＳの制御を受ける夫々のプロセッサの稼働状況とローカルなタスクＩＤが初期設定される。管理プログラムが常駐タスクとして動作されるから、タスクの起動が要求されるたびに管理プログラムを立ち上げる手間が無く、即時応答性がある。

ＯＳ毎に動作される管理プログラムは、そのＯＳが所属するデータベースエントリの可変領域に対する更新を行う。データ処理システムの低消費電力モードにおいて定特定のＯＳの管理下にあるプロセッサ又は周辺回路デバイスの動作が停止されるようなとき、それを利用して実行されるタスクに対応されるデータベースエントリの稼働状況を示す領域は「動作不可」に書換えられる。

《検索キー》前記グローバルタスク名はタスク名に対応される。前記管理プログラムを実行するプロセッサは、例えば前記グローバルタスク名を検索キーとして前記データベースの検索を行う。起動が要求されたタスクに対して所属ＯＳの異なる同種のタスクは複数存在することが想定される。それらには同一のグローバルタスク名を付与し、個別のグローバルタスクＩＤＳを付与しておけば、その同種のタスクに係るデータベースエントリを選択するための判定因子として、前記所属ＯＳ、タスク保護情報、稼動状況を利用することにより、データ処理上最適なタスクを起動することが可能になる。

《優先順位》前記データベースエントリは優先順位を格納する領域を更に有する。グローバルタスクＩＤが相違しグローバルタスク名が同一の複数のデータベースエントリ間においては前記優先順位格納領域で指定される優先順位が相違される。前記優先順位を前記判定因子の一つとして利用することができる。

例えば、前記管理プログラムを実行するプロセッサは、前記検索により複数のデータベースエントリが選ばれたとき、稼動可能なタスが複数存在する場合には優先順位格納領域で特定される優先順位が最も高いデータベースエントリを選べばよい。

《ソフト代替》グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクは他のタスクが利用するハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクとされる。例えば前記他のタスクが利用する周辺回路デバイスやプロセッサ等のハードウェアの動作が不能になったとき、そのタスクに対応するデータベースエントリには「稼働状況＝動作不可」という情報が反映される。このようなときにも、ハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクを起動させることができる。要するに、故障や低消費電力モード等により特定のプロセッサ及び周辺回路デバイス等のハードウェアの動作が不能になっているとき、それによるハードウェア処理のタスクに代えて、ソフトウェア処理によるタスクを起動させることができる。

《代替ハード》グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクと他のタスクは所属ＯＳが相違される。前記複数のタスクによる処理を規定するプログラムを別々のＯＳに則して予め用意しておくことにより、一のタスクを実行するプロセッサの動作が不能になっても、その処理に対応する他のタスクを所属ＯＳの異なる他のプロセッサに処理させることができる。要するに、故障や低消費電力モード等により特定のプロセッサが動作不能なとき、所属ＯＳの異なる別のプロセッサに同等のタスク処理を振り当てることができる。

〔２〕《ソフト代替》別の観点によるデータ処理システムは、複数のＯＳと複数のプロセッサを用いたシステムであって、前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベースと、前記ＯＳ毎に動作される管理プログラムと、を有する。前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、当該タスクのタスクの稼働状況及び当該タスクの優先順位を夫々格納する領域を有する。グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクは他のタスクが利用するハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクである。一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリのタスクが前記一のタスクと前記他のタスクであるとき、稼動可能なタスクの内で前記優先順位の最も高いタスクをその所属ＯＳによる管理のもとで処理させる。

故障や低消費電力モード等により特定のプロセッサ及び周辺回路デバイスが動作不能なときそれによるハードウェア処理のタスクに代えて、別のプロセッサのソフトウェア処理によるタスクを起動させることができる。双方ともに稼動可能なときは優先順位に従って、ハードウェアによる処理を行なうタスクを起動させることができる。部分的な故障等に対してシステムを保全することができ、また、システムの機能を犠牲にすることなくデータ処理システムの低消費電力を実現可能になる。

〔３〕《代替ハード》別の観点によるデータ処理システムは、複数のＯＳと複数のプロセッサを用いたシステムであって、前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベースと、前記ＯＳ毎に動作される管理プログラムと、を有する。前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、当該タスクの稼働状況及び当該タスクの優先順位を夫々格納する領域を有する。グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクと他のタスクは所属ＯＳが相違される。一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリのタスクが前記一のタスクと前記他のタスクであるとき、稼動可能なタスクの内で前記優先順位の最も高いタスクをその所属ＯＳによる管理のもとで処理させる。

故障や低消費電力モード等により特定のプロセッサが動作不能なとき、所属ＯＳの異なる別のプロセッサに同等のタスク処理を振り当てることができる。双方ともに稼動可能なときは優先順位に従って、ハードウェアによる処理を行なうタスクを起動させることができる。部分的な故障等に対してシステムを保全することができ、また、システムの機能を犠牲にすることなくデータ処理システムの低消費電力を実現可能になる。

２．実施の形態の詳細
次に、実施の形態について更に詳述する。

図２は本発明に係るデータ処理システムのハードウェアブロック図である。同図に示されるデータ処理システムＳＹＳは、代表的に示された複数個のプロセッサＭＰＵ０〜ＭＰＵｉ、周辺回路デバイスＩＰ０〜ＩＰｍ、及びメモリＭＥＭを有し、それらは内部バスＢＵＳに接続される。内部バスＢＵＳの構成は特に制限されず、スプリットトランザクションバスであってもよいし、排他制御に行ってアービトレーションが行われるバスであってもよい。周辺デバイスＩＰ０〜ＩＰｍはＤＭＡＣ（ダイレクト・メモリ・アクセス・コントローラ）、ＳＣＩ（シリアル・コミュニケーション・インタフェース）、ＬＣＤ（液晶ドライバ）、ＶＩＯ（ビデオ入出力回路）、ＧＲＦ（グラフィックプロセッサ）、ＭＥＭＣＮＴ（メモリコントローラ）、ＤＳＰ（ディジタル信号処理プロセッサ）、ＴＭＲ（タイマ・カウンタ）等、何れでもよい。

プロセッサＭＰＵ０〜ＭＰＵｉは、少なくとも中央処理装置を含み、必要に応じてアドレス変換バッファ、キャッメモリ、及びその他のロジック回路を備える。特に制限されないが、プロセッサＭＰＵ０〜ＭＰＵｉは異なるＯＳのもとでアプリケーションプログラム（ユーザプログラム）を実行する。このデータ処理システムはマルチＯＳ・マルチプロセッサのシステムであり、シングルチップで形成されたＳＯＣの半導体集積回路として構成される。

図１には本発明に係るデータ処理システムＳＹＳのソフトウェア構成が例示される。ここでは４個のプロセッサＭＰＵ０〜３、５個の周辺回路デバイスＩＰ０〜ＩＰ４、及びメモリＭＥＭをハードウェア（ＨＲＤ）として備える場合を一例とする。特に制限されないが、ソフトウェアは、オペレーティングシステム（ＯＳ）、管理プログラム（ＭＮＧ）、アプリケーションプログラム（ＡＰＬ）、ドライバソフトウェア（ＤＲＶ）から構成される。ソフトウェアの核となるオペレーティングシステムとしてＯＳ０〜ＯＳ２が用いられる。アプリケーションプログラムＡＰＬ０，ＡＰＬ１はオペレーティングシステムＯＳ０の管理のもとで実行される。アプリケーションプログラムＡＰＬ２，ＡＰＬ３はオペレーティングシステムＯＳ１の管理のもとで実行され、アプリケーションプログラムＡＰＬ４はオペレーティングシステムＯＳ２の管理のもとで実行される。ここではアプリケーションプログラムはユーザタスク（単にタスクとも記す）の起動を要求するプログラムモジュールと位置付ける。更に、起動されたタスクの処理を規定するプログラムモジュールをドライバソフトウェアとして位置付ける。ドライバソフトウェアには、周辺回路デバイスを利用するために実行されるものだけでなく、プロセッサが専らソフトウェアだけで実現する処理を規定するためのプログラムも含む。要するに、アプリケーションプログラムは上位のユーザプログラム、ドライバソフトウェアは下位のユーザプログラムとして位置付けることができる。図２では、ＤＲＶｉ０〜ＤＲＶｉ４は周辺回路デバイスを用いる処理のためのドライバソフトウェア、ＤＲＶｍ０〜ＤＲＶｍ３はプロセッサが専らソフトウェアだけで実現する処理のためのドライバソフトウェアである。ドライバソフトウェアＤＲＶｍ０〜ＤＲＶｍ３の夫々は複数のプログラムの集合であってもよい。

オペレーティングシステムＯＳ０〜ＯＳ２は複数のプロセッサの動作を制御する対称型マルチプロセッサＯＳか、１つのプロセッサを制御するＯＳかによらず、各ＯＳで一つのプロセッサが起動されるものとする。

管理プログラムＭＮＧ０〜ＭＮＧ２は対応するオペレーティングシステムＯＳ０〜ＯＳ２のもとで起動し、起動後は常駐タスクとして機能する。管理プログラムＭＮＧ０〜ＭＮＧ２は、対応するオペレーティングシステムＯＳ０〜ＯＳ２のもとでアプリケーションプログラムがタスクの起動を要求したとき、管理データベースを参照ならびに操作し、且つ相互に連携して、タスクの起動を制御する。管理プログラムＭＮＧ０〜ＭＮＧ２の相互連携が、アプリケーションプログラムにおいてシステムのハードウェア構成やＯＳの相違を隠蔽可能とする。管理プログラムは、前記相互連携を行うのに、図３に例示されるように複数のオペレーティングシステムＯＳ１〜ＯＳ３によるメモリ管理機能の下で夫々参照可能なメモリＭＥＭ上の共有領域ＣＯＭを通信バッファとして利用する。ＥＸＣ０〜ＥＸＣ２は対応するオペレーティングシステムＯＳ１〜ＯＳ３が管理する専用領域である。特に制限されないが、共有領域ＣＯＭに管理データベースＭＤＢが形成される。以下、管理プログラムと管理データベースの機能について詳述する。

図４には管理データベースの一つのエントリデータが例示される。管理データベースＭＤＢは複数のデータベースエントリｅｄ_０〜ｅｄ_ｎを有する。それぞれのデータベースエントリｅｄ_０〜ｅｄ_ｎは、ＯＳの管理のもとで処理されるハードウェア制御やソフトウェア処理のためのタスクと所属ＯＳとの対応関係等を複数のＯＳに亘って定義する。図４に従えば、データベースエントリが備えるデータ項目は以下のとおりである。管理データベースＭＤＢにおいては複数のＯＳの複数のタスクを夫々グローバルタスク、すなわちサーバントと称して管理する。サーバントはタスクと一対一対応され、それぞれはサーバントＩＤ（グローバルタスクＩＤ）によって区別される。サーバンドＩＤ毎にそのタスクを規定するためのハードウェア制御やソフトウェア処理のための処理プログラムであるドライバソフトウェアに対応付けられる。本明細書においてＯＳの管理のもとで起動が要求されるタスクは管理プログラムと管理データベースを介してサーバントさらにはドライバソフトウェアに対応付けられる。

サーバントにはサーバント名が付される。ここではサーバント名はＯＳの管理下におけるタスク名に一致される。この関係は、ＯＳや管理プログラムのＡＰＩ（アプリケーション・プログラム・インタフェース）をプログラム開発において参照することによって担保されているものとする。サーバント名が同じであってもサーバントＩＤは区別される。サーバント名が同じサーバント間での処理の優先順位は優先順位のデータ項目によって規定される。サーバントには対応するタスクが管理を受ける所属ＯＳが指定される。入力バッファサイズおよび出力バッファサイズのデータ項目は管理プログラム間で行われる通信に用いるバッファサイズを意味し、当該バッファは共有領域ＣＯＭに確保される。サーバントには所属ＯＳにより割り当てられたタスクＩＤ（所属ＯＳ内タスクＩＤ）が割り当てられる。この所属ＯＳ内タスクＩＤの割り当ては所属ＯＳが起動されて始めて確定する。サーバントはその稼働状況が特定される。稼働状況のデータ項目にはＯＳによる対応タスクのタスク管理の内容が反映され、そのデータは、少なくとも対応するハードウェア処理やソフトウェア処理が可能か不可能かを示す。したがって、この稼動状況のデータはシステムの状態に応じて可変される。低消費電力状態において動作が停止されたハードウェア或いは故障により動作不能のハードウェアを使用するサーバントの稼動状況は動作不可とされる。稼働状況のデータ項目に対するデータエントリ操作は対応するＯＳの管理プログラムが行うが、書き換えるべき情報はＯＳを介してから入手する。低消費電力状態における動作の停止はモードレジスタの設定内容にしたがって認識する。故障による動作不能の状態はウォッチドッグタイマなどのセルフチェック機能を用いて把握すればよい。データベースエントリは、タスク実行環境を制限するタスク保護情報を有する。例えば保護情報は、所属ＯＳ以外からの処理要求に答えない、或いは特定のＯＳからの処理要求に対してだけ答える、というような制限情報である。サーバントへの処理要求が許可されていないＯＳからの要求であった場合、例えばサーバントを実行せずにエラーを返す。

所属ＯＳ内タスクＩＤおよび稼働状況のデータ項目以外はサーバントに固有の固定値とされる。管理データベースには管理プログラムが管理する全てのサーバントの情報が登録されており、全てのＯＳで同じ管理データベースのコピーを持つ。ただし、属性がダイナミック（dynamic）のデータ項目は所属ＯＳに依存する情報であるため、そのＯＳの管理プログラムのみが書き換え可能であり、他のＯＳは書き換え操作することはできない。属性がstatic（スタティック）の項目はシステム全体で静的な情報であり、全てのＯＳで共通の情報とされる。

図５には管理プログラムを常駐タスクとして起動する起動シーケンスが例示される。特に制限されないが、ここでは特定の一つのプロセッサＭＰＵ０を起動用のメインプロセッサとし、これにリセット信号を供給して最初に起動し、起動されたメインプロセッサＭＰＵ０が残りのサブプロセッサＭＰＵ１〜ＭＰＵ３にリセットを指示してそれらを起動する。各ＯＳの起動時に、各ＯＳの常駐タスクが起動される。ここでは管理プログラムが起動され、起動された管理プログラムによって管理データベースの設定が行われる。共有領域ＣＯＭに配置された管理データベースＭＤＢの各データベースエントリにおいて属性がダイナミックとされているデータ項目は不定になっている。管理プログラムはこの状態の管理データベースＭＤＢをそれぞれのメモリ領域にコピーし、コピーした管理プログラムのデータベースエントリの内、所属ＯＳが自ＯＳとされているデータベースエントリに対して、属性がダイナミックとされているデータ項目である所属ＯＳ内タスクＩＤと稼動状況のデータを設定する。その後、ＯＳドメイン内において、ユーザタスクの起動要求に対する応答処理を行い、必要なユーザタスクを実行する。

図６にはユーザタスクの起動要求に対する応答処理における代表的な処理系統が示される。ＯＳドメインにおいてユーザタスクの起動要求があると、管理プログラムは自ＯＳドメイン、即ち自ＯＳ側の管理プログラムを参照し、そのタスク名に対応するサーバント名のデータエントリを検索する。検索したデータエントリの所属ＯＳが要求元と同じＯＳであればそのサーバントを実行するための手続を行う。例えばＣＮＴ０の経路で示されるようにＯＳ０側においてドライバソフトウェアＤＲＶｍ０をプロセッサＭＰＵ０に実行させる。一方、検索したデータエントリの所属ＯＳが要求元とは異なるＯＳであればその、そのサーバントが所属するＯＳの管理プログラムと通信を行って、当該ユーザタスクの起動要求を伝え、当該ユーザタスクの実行結果を返すことを要求する。要求が伝えられた当該他のＯＳドメインでは、その管理プログラムが起動要求に対応するサーバントのデータベースエントリを参照して、サーバントを実行するための手続を行う。例えばＣＮＴ１の経路で示されるように、ＯＳ０ドメインからのサーバント起動要求がＯＳ１ドメインの管理プログラムに引き渡され、周辺回路デバイスＩＰ２を用いるドライバソフトウェアＤＲＶｉ２をプロセッサＭＰＵ２に実行させる。実行結果はＯＳ０ドメインの管理プログラムＭＮＧ１からＯＳ１ドメインのＭＮＧ０に戻される。

上記２系統の応答処理に代表されるように、ユーザタスクの起動要求を受けたＯＳドメインから他のＯＳドメインに対する手続呼び出しは、管理プログラムを実行するプロセッサ間での通信という共通化された形式で実現される。したがって、ソフトウェア設計者はＯＳ間の通信が発生することを意識せずにユーザプログラムのようなソフトウェアを記述すればよい。データ処理システムの周辺回路デバイス等のハードウェアの変更に対し逐一ソフトウェアを変更しなくても済み、ＯＳ間通信の部分については管理データデータベースのエントリデータの変更で対処することが可能になる。実質的に異種ＯＳ間の通信であってもアプリケーションの開発時にはその通信プロトコルを意識する必要はない。したがって、異種ＯＳ間のソフトウェア移植も容易である。

上記各応答処理系統におけるＯＳドメイン内の手続について更に説明する。前記グローバルタスク名はタスク名に対応される。前記管理プログラムを実行するプロセッサは、そのＯＳドメイン内で前記グローバルタスク名を検索キーとしてデータベースエントリの検索を行う。検索結果に対しては、起動が要求されたタスクに対して所属ＯＳの異なる同種のタスクが複数存在することが想定される。それらには同一のグローバルタスク名が付与されるが、個別のグローバルタスクＩＤＳが付与されている。前記同種のタスクに係るデータベースエントリを選択するための判定因子として、前記所属ＯＳのほかに、タスク保護情報、稼動状況を利用することにより、データ処理上最適なタスクを起動することが可能になる。例えば、タスク保護情報は所属ＯＳ以外からの処理要求に答えない、或いは特定のＯＳからの処理要求に対してだけ答えるというような制限を意味する。このようなサーバントのタスク保護情報が静的に定められることで、許可していないＯＳからのタスク起動要求を自動的に遮断し、セキュリティ強度を高めることができる。

また、グローバルタスクＩＤが相違しグローバルタスク名が同一の複数のデータベースエントリ間においては指定された優先順位が相違されることにより、前記優先順位を前記判定因子の一つとして利用することができる。例えば、前記管理プログラムを実行するプロセッサは、前記検索により複数のデータベースエントリが選ばれたとき、稼動可能なタスクが複数存在する場合には優先順位格納領域で特定される優先順位が最も高いデータベースエントリのサーバントを実行させるようにすればよい。更に、上記管理データベースＭＤＢにおいてＯＳ毎に動作される管理プログラムは、そのＯＳが所属するデータベースエントリの可変領域（属性がダイナミックとされるデータ項目）である稼動状況のデータ項目に対する更新を行う。データ処理システムの低消費電力モードにおいて特定のＯＳの管理下にあるプロセッサ又は周辺回路デバイスの動作が停止されるようなとき、それを利用して実行されるタスクに対応されるサーバントのデータベースエントリの稼働状況を示す領域は「動作不可」に書換えられる。管理プログラムを実行するプロセッサは「稼働状況＝動作不可」のサーバントに対しては実行を見送る。

管理プログラムを実行するプロセッサは前記稼働状況および優先順位のデータ項目に基づいて例えば以下の手続きを行う。

例えばソフトウェア処理によってハードウェア部分の処理を代替するタスクを用意している場合について説明する。グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクは他のタスクが利用するハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクとする場合である。このとき、前記他のタスクが利用する周辺回路デバイスやプロセッサ等のハードウェアの動作が不能になったとき、そのタスクに対応するデータベースエントリには「稼働状況＝動作不可」という情報が反映される。このようなとき、特定のハードウェア処理を用いるタスクの起動が要求された場合であっても、当該ハードウェアが動作不能であっても、ハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクを起動させることができる。要するに、故障や低消費電力モード等により特定のプロセッサ及び周辺回路デバイス等のハードウェアの動作が不能になっているとき、それによるハードウェア処理のタスクに代えて、ソフトウェア処理によるタスクを起動させることができる。当該ハードウェアの動作が可能な場合には、当該ハードウェアを用いるサーバントの優先順位が、ソフトウェア代替処理を行うサーバントの優先順位よりも高くされていることにより、ハードウェアを用いた処理を優先させることができる。更に、任意の周辺回路デバイスが存在しない廉価版のシステムでも、ソフトウェアの変更なしに対応することができる。電力や制約時間の情報をもとに当該周辺回路デバイスのクロックを遮断し、他のプロセッサや、周辺回路デバイスでタスクを実行することにより、システムの低消費電力化を促進することができる。

別の例として、実質同一の処理を異なるＯＳドメインにおける異なるタスクとして用意している場合について説明する。一のタスクが他のタスクの予備になる関係である。このようなタスクに対応して相互にサーバント名が等しくサーバントＩＤが相違されるサーバントを用意し、優先順位は一のサーバントが高く他のサーバントが低くされる。これにより、一のタスクを実行するプロセッサの動作が不能になっても、その処理に対応する他のタスクを所属ＯＳの異なる他のプロセッサに処理させることができる。要するに、故障や低消費電力モード等により特定のプロセッサが動作不能なとき、所属ＯＳの異なる別のプロセッサに同等のタスク処理を振り当てることができる。あるプロセッサが故障した場合、別のプロセッサで必要なタスクの処理を実行させることができるから、ソフトウェアの変更なしに処理を継続可能となる。

図７には管理データベースを用いるタスク管理を簡素化する場合に用いる管理データベースが例示される。図４との相違は優先順位のデータ項目を省いたことである。この場合、管理プログラムはユーザタスクの起動要求に対してサーバントＩＤを検索キーに用いて管理データベースを検索する。検索によって複数のデータベースエントリがヒットすることはない。ソフトウェアで代替するタスクへのスイッチ、故障又は動作停止されたハードウェを用いるタスクに対する代替タスクへのスイッチは行われなくなるが、管理プログラムによるＯＳドメイン内の手続は簡素化される。小規模なデータ処理システム、データ処理システムに対する簡易な制御に最適である。

図８には適当な機能の集合毎に個別チップ化されたマルチチップで構成されたデータ処理システムが示される。データ処理システムＳＹＳ＿Ａは複数個の半導体集積回路ＣＨＰ０〜ＣＨＰ２を有する。ＭＰＵ０〜ＫＰＵ２はプロセッサ、ＭＥＭ０〜ＭＥＭ２はローカルメモリ、ＩＰ０ｂ，ＩＰ１ｂ，ＩＰ２ｂは通信用周辺回路デバイス、ＩＰ０ａ，ＩＰ１ａ，ＩＰ２ａはその他の周辺回路デバイスである。通信用周辺回路デバイスＩＰ０ｂ，ＩＰ１ｂ，ＩＰ２ｂによる通信はシリアルやＴＣＰ／ＩＰなどの通信プロトコルを用いて実現されるが、その通信処理は感涙プログラムにより常駐タスクと間の通信としてアプリケーションプログラムからは隠蔽可能とされ、アプリケーションプログラムの作成においてはその通信用のシステム構成を意識する必要はない。マルチＯＳのマルチプロセッサ構成がオンチップであるのかオフチップであるのかに拘わらず同様の効果を得ることができる。図８のように共有メモリを設けていない場合には、パワーオンリセット等に応答してメインとなる一つの半導体集積回路のプロセッサが他の半導体集積回路のプロセッサに管理データベースのコピーを渡すことが必要になる。

以上説明したデータ処理システムによれば以下の作用効果を得ることができる。

（１）ＯＳ間でのタスク呼出しの手続きを管理プログラムによる常駐タスク間で自動的に行うため、ソフトウェア設計者はＯＳ間の通信が発生することを意識せずにソフトウェアを記述することができる。

（２）周辺回路デバイスの数や周辺回路デバイスの所属するＯＳなどのハードウェア構成が変わったとしても、周辺回路デバイスのドライバソフトウェアの所属を上記常駐タスクが自動的に検索するため、アプリケーションプログラムに対しそれに対応させてソフトウェアを修正することを要しない。ハードウェア構成に対する変更への対応は管理データベースを更新すればよい。

（３）管理データベースに対する参照と制御は全てのＯＳで共通化するので、異種ＯＳ間の通信であってもその通信を意識する必要はない。異種ＯＳ間のソフトウェア移植も容易となる。

（４）プロセッサや周辺回路デバイスが故障した場合、他のプロセッサや周辺回路デバイスを用いて必要なタスクの処理を代替させることができるから、ソフトウェアの変更なしに処理を継続可能となる。

（５）ハードウェアを用いた処理をソフトウェアによる処理で代替ささせることができるから、プロセッサや周辺回路デバイスが存在しない廉価版のデータ処理システムを提供する場合にも、ユーザプログラム等のソフトウェアを変更なしに実行することができる。

（６）スリープモードやスタンバイモード等に応じてプロセッサや周辺回路デバイスに対する同期クロックや動作電源の供給を遮断したとき、この状態を稼働状況のデータ項目に反映して、別のプロセッサや周辺回路デバイスを用いたタスクの処理に代替させることができるから、機能低下をもたらすことなく、データ処理システムの低消費電力を図ることができる。

以上本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。

例えば、管理データベースのデータ項目の属性を全てダイナミックとし、対応する管理プログラムにて書換え可能にしてもよい。但し、管理データベースは各ＯＳで同一である必要があるため、サーバントの所属ＯＳや保護情報が変更された際には全てのＯＳの常駐タスク動作を一時停止し、全てのＯＳドメインに関し管理データベースの更新処理を行なって、コヒーレンシを保証することが必要である。サーバントの所属ＯＳや保護情報が変更可能になって、システム構成の柔軟性が高まるが、セキュリティ強度が低下する場合がある。また、本発明のデータ処理システムで採用可能なＯＳの種類やプロセッサのアーキテクチャは制限されず適宜選択可能である。

本発明に係るデータ処理システムのソフトウェア構成を例示するシステム構成図である。 本発明に係るデータ処理システムのハードウェアを例示するハードウェアブロック図である。 管理プログラムが通信バッファとして利用するメモリ領域上の共有領域を例示する説明図である。 管理データベースの一つのエントリデータを例示するフォーマット図である。 管理プログラムを常駐タスクとして起動する起動シーケンスを例示するフローチャートである。 ユーザタスクの起動要求に対する応答処理における代表的な処理系統を例示する説明図である。 管理データベースを用いるタスク管理を簡素化する場合に用いる管理データベースを例示するフォーマット図である。 マルチチップで構成されたデータ処理システムを例示するブロック図である。

符号の説明

ＳＹＳ、ＳＴＳ＿Ａ データ処理システム
ＭＰＵ０〜ＭＰＵｉ プロセッサ
ＩＰ０〜ＩＰｍ 周辺回路デバイス
ＭＥＭ メモリ
ＢＵＳ 内部バス
ＯＳ０〜ＯＳ２ オペレーティングシステム
ＡＰＬ０，ＡＰＬ１ アプリケーションプログラム
ＤＲＶｉ０〜ＤＲＶｉ４ 周辺回路デバイスを用いる処理のためのドライバソフトウェア
ＤＲＶｍ０〜ＤＲＶｍ３ ソフトウェアだけで実現する処理のためのドライバソフトウェア

Claims (20)

1. 複数のＯＳと複数のプロセッサを用いたデータ処理システムであって、
   前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベースと、
   前記ＯＳ毎に動作される管理プログラムと、を有し、
   一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリの所属ＯＳが前記一の管理プログラムの所属ＯＳであるときは当該所属ＯＳの管理のもとで当該タスクを処理し、前記選ばれたデータベースエントリの所属ＯＳが別の管理プログラムの所属ＯＳであるときは当該別の管理プログラムを実行するプロセッサに必要な情報を渡して、前記別の管理プログラムの所属ＯＳによる管理のもとで当該タスクを処理させる、データ処理システム。
2. 前記一の管理プログラムを実行するプロセッサは前記別の管理プログラムを実行するプロセッサと双方向通信可能である、請求項１記載のデータ処理システム。
3. 前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、及び当該タスクの稼働状況を夫々格納する領域を有し、前記タスクＩＤ及びタスクの稼働状況を夫々格納する領域は前記管理プログラムによって書換え可能な領域である、請求項２記載のデータ処理装置。
4. 前記データベースエントリは、タスク実行環境を制限するタスク保護情報の格納領域を更に有する、請求項３記載のデータ処理装置。
5. 前記データベースエントリは、前記双方向通信に利用するバッファサイズを規定するバッファサイズ情報の格納領域を更に有する、請求項４記載のデータ処理装置。
6. 前記プロセッサはシステムの初期化指示に応答して起動するＯＳの元で、対応する管理プログラムを実行することによって前記データベースの可変領域に対する初期設定を行い、管理プログラムによる管理タスクは常駐タスクとされ、当該ＯＳのもとで動作するプロセッサに常駐する、請求項３記載のデータ処理システム。
7. ＯＳ毎に動作される管理プログラムは、そのＯＳが所属するデータベースエントリの可変領域に対する更新を行う、請求項６記載のデータ処理システム。
8. 前記グローバルタスク名はタスク名に対応され、前記管理プログラムを実行するプロセッサは、前記タスク名を検索キーとして前記データベースの検索を行う、請求項３記載のデータ処理装置。
9. 前記データベースエントリは優先順位を格納する領域を更に有し、
   グローバルタスクＩＤが相違しグローバルタスク名が同一の複数のデータベースエントリ間においては前記優先順位格納領域で指定される優先順位が相違される、請求項８記載のデータ処理装置。
10. 前記管理プログラムを実行するプロセッサは、前記検索により複数のデータベースエントリが選ばれたとき、稼動可能なタスクが複数存在する場合には優先順位格納領域で特定される優先順位が最も高いデータベースエントリを選ぶ、請求項９記載のデータ処理装置。
11. グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクは他のタスクが利用するハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクである、請求項１０記載のデータ処理システム。
12. グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクと他のタスクは所属ＯＳが相違される、請求項１０記載のデータ処理システム。
13. 前記複数のプロセッサは単一チップに形成されている、請求項２記載のデータ処理装置。
14. 前記複数のプロセッサは複数チップに形成されている、請求項２記載のデータ処理装置。
15. 複数のＯＳと複数のプロセッサを用いたデータ処理システムであって、
    前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベースと、
    前記ＯＳ毎に動作される管理プログラムと、を有し、
    前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、当該タスクの稼働状況及び当該タスクの優先順位を夫々格納する領域を有し、
    グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクは他のタスクが利用するハードウェアによる処理をプロセッサのソフトウェアによる処理で代替するタスクであり、
    一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリのタスクが前記一のタスクと前記他のタスクであるとき、稼動可能なタスクの内で前記優先順位の最も高いタスクをその所属ＯＳによる管理のもとで処理させる、データ処理システム。
16. 前記グローバルタスク名はタスク名に対応され、前記管理プログラムを実行するプロセッサは、前記タスク名を検索キーとして前記データベースの検索を行う、請求項１５記載のデータ処理装置。
17. グローバルタスクＩＤが相違しグローバルタスク名が同一の複数のデータベースエントリ間においては前記優先順位格納領域で指定される優先順位が相違される、請求項１６記載のデータ処理装置。
18. 複数のＯＳと複数のプロセッサを用いたデータ処理システムであって、
    前記ＯＳの管理のもとで処理されるタスクとその所属ＯＳとの対応関係を複数のＯＳに亘って定義したデータベースと、
    前記ＯＳ毎に動作される管理プログラムと、を有し、
    前記データベースエントリは、複数のＯＳの複数のタスクを夫々区別するためのグローバルタスクＩＤ、グローバルタスク名、当該タスクの所属ＯＳ、所属ＯＳにより割り当てられた当該タスクのタスクＩＤ、当該タスクの稼働状況及び当該タスクの優先順位を夫々格納する領域を有し、
    グローバルタスクＩＤが相違しグローバルタスク名が同一とされるデータベースエントリで特定される複数のタスク間において、一のタスクと他のタスクは所属ＯＳが相違され、
    一の管理プログラムを実行するプロセッサは、前記タスクの起動が要求されたとき、前記データベースから当該タスクに対応するデータベースエントリを検索し、それによって選ばれたデータベースエントリのタスクが前記一のタスクと前記他のタスクであるとき、稼動可能なタスクの内で前記優先順位の最も高いタスクをその所属ＯＳによる管理のもとで処理させる、データ処理システム。
19. 前記グローバルタスク名はタスク名に対応され、前記管理プログラムを実行するプロセッサは、前記タスク名を検索キーとして前記データベースの検索を行う、請求項１８記載のデータ処理装置。
20. グローバルタスクＩＤが相違しグローバルタスク名が同一の複数のデータベースエントリ間においては前記優先順位格納領域で指定される優先順位が相違される、請求項１９記載のデータ処理装置。

Images