(57)【要約】【課題】従来の組込み製品では，基本部とミドルウェア部がひとまとまりのロードモジュールとなっており，ゲート管理機能が基本部の一部として提供されているため，アプリケーション部のみの改造をおこなう場合であっても，それに伴ってすべてのロードモジュールを入れ替える必要があるという問題があった。【解決の手段】この課題を解決するために，ゲート管理機能を基本部から独立させ，基本部，ミドルウェア部，アプリケーション部をそれぞれ独立した機能（コンポーネント）として捉え，このコンポーネント単位にロードモジュールを作成し、ゲート管理機能に管理テーブルを設け，各コンポーネントは，他のコンポーネントに提供するサービス機能をこのテーブルに各コンポーネントの初期化ルーチンにおいて自ら登録する。このような構成により、コンポーネントの追加や削除が他のコンポーネントに影響を与えることなく自由におこなうことが可能になる。【選択図】            図１
2005084900.tif 000002
【特許請求の範囲】
【請求項１】
基本部と，ミドルウェア部と，アプリケーション部とをそれぞれ独立した機能（コンポーネント）として分離し，ゲート管理部によって各コンポーネント単位に入替えるソフトウェア構成としたことを特徴とするプログラム管理方式。
【請求項２】
前記ソフトウェア構成において，入替えたいコンポーネントを停止することによって，プログラムが起動中であっても，コンポーネント単位で入替えることを特徴とする請求項１に記載のプログラム管理方式。
【請求項３】
前記ゲート管理部において、コンポーネントIDとシステムコールNoによって提供するコンポーネントを指定することを特徴とする請求項１に記載のプログラム管理方式。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は，組込みソフトウェア分野におけるソフトウェア構成に関するものである。
【背景技術】
【０００２】
図７，８は従来の組込み製品におけるソフトウエア構成を示す図である。
【０００３】
従来の組込み製品では，図７のように，基本部11，ミドルウェア部12，アプリケーション部13をひとまとめにしてロードモジュール14を作成している(特許文献1)。あるいは，図８のように，基本部15，ミドルウェア部16をひとまとまりにし，アプリケーション部17のみを分けてそれぞれロードモジュール18,19を作成している。そして、ロードモジュール18のシステムコールライブラリ20がロードモジュール19のコールゲート関数21を呼出すように構成されている。
【特許文献１】特表平９−５１２３５８
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従来の組込み製品では，図７あるいは図８のように，基本部とミドルウェア部がひとまとまりのロードモジュールとなっており，ゲート管理機能が基本部の一部として提供されているため，アプリケーション部のある一つのコンポーネントのみの改造をおこなう場合であっても，それに伴って基本部のコードも書き換える必要があり，結局すべてのロードモジュールを入れ替える必要があるという問題があった。このためソフトウエア開発時に多大の時間と労力を要した。また稼動時に保守性が良くなかった。
【課題を解決するための手段】
【０００５】
この課題を解決するために，本発明はゲート管理機能を基本部から独立させ，基本部，ミドルウェア部，アプリケーション部をそれぞれ独立した、いくつかの機能（コンポーネント）として捉え，このコンポーネント単位にロードモジュールを作成するようにする。そして，ゲート管理機能に管理テーブル（コールゲート管理テーブル）を設け，各コンポーネントは，他のコンポーネントに提供するサービス機能をこのテーブルに各コンポーネントの初期化ルーチンにおいて自ら登録するようにする。このような構成にすることにより，既存のコンポーネントの改造のみならず，コンポーネントの追加や削除が他のコンポーネントに影響を与えることなく自由におこなうことができる。
【発明の効果】
【０００６】
本発明により、各機能（コンポーネント）の改造や追加、その入替えがコンポーネント単位でおこなえるので，他のコンポーネントに影響を与えない。したがって、ソフトウエアの開発段階において、開発者が自身の担当するコンポーネントのみを把握して、ロードモジュールを作成すればよいため、開発効率が向上する。また、稼動時において既にFixしてあるコンポーネントは全く変更を加える必要がないので保守性が向上する。
【発明を実施するための最良の形態】
【０００７】
図１は、本発明によるプログラム管理方式におけるソフトウエア構成の説明図である。図において、１は基本部、２はミドルウエア部、３はアプリケーション部、４はゲート管理部、５はゲート管理部４に設けられるコールゲート管理テーブル、６はコールゲート管理テーブル５内に作成される管理テーブルである。ミヅルウエア部２とアプリケーション部３はシステムコールライブラリを有している。
【０００８】
図１は基本部１、ミドルウエア部２、アプリケーション部３がそれぞれ単一のコンポーネントで構成された実施例であるが機能のかたまりをどうするかによって複数のコンポーネントで構成されることもある。図１のように，ゲート管理機能を基本部１から独立させ，基本部１，ミドルウェア部２（各プロトコルスタックなど），アプリケーション部３（ユーザが構築する、いろいろな機能）をそれぞれ独立した機能（コンポーネント）として捉え，このコンポーネント単位にロードモジュールを作成する。また，その際，各コンポーネントに一意の番号を割当てておき，これをコンポーネントＩＤ（図においては、それぞれ１，２，３）として，各コンポーネントを識別できるようにしておく。
【０００９】
一方，ゲート管理部４にコンポーネントＩＤとそのコンポーネントが他のコンポーネントに対して提供するサービス機能のサービスエントリポイントを対応させた管理テーブル５（コールゲート管理テーブル）を設けておく。そして，各コンポーネントは，自分が他のコンポーネントに対して提供するサービス機能に番号を与え（この番号をシステムコールＮｏと呼ぶ），このシステムコールＮｏとその実態が存在するアドレスを対応させた管理テーブル６を作成しておき，初期化ルーチンにおいてこのテーブルの先頭アドレスをコールゲート管理テーブル５のサービスエントリポイントに登録する。このようにして，各コンポーネントが他のコンポーネントに提供するサービス機能をコンポーネントＩＤとシステムコールＮｏという２つの番号によって一意に指定できるようにしておく。この仕組みにより，ゲート管理部４のコールゲート機能は，コンポーネントＩＤとシステムコールＮｏを与えられれば，どのコンポーネントのどのサービスに対して要求が来たのかを判断でき，適切なサービスを呼出すことができる。以上述べてきたサービス機能とは汎用OSのAPI関数に相当するもので、例えば、コンポーネントをTCP/IPのプロトコルスタックとした場合、データ送信機能（send）やデータ受信機能（recv）などに相当するものである。
【００１０】
一方，各コンポーネントから他のコンポーネントが提供するサービス機能を呼出すにあたっては，そのコンポーネントのロードモジュール作成時にリンクするシステムコールライブラリを通じて，通常の関数呼出しと同じ形でその機能を呼出すことができる。そのためのシステムコールライブラリの構造を図２、図３に示す。図２のように，呼出したいサービス機能に応じて本来のパラメータとともにそのコンポーネントＩＤとシステムコールＮｏを引数に付加して，コールゲート関数（CallGate）を呼出すようにする。なお，コールゲート機能の呼出しの実現方法としては，図２に示すように、通常の関数として実装することによる固定番地方式と，図３に示すように，ソフトウェア例外（割込みベクタ）を利用した割込みルーチンとしての実現方式の２通りがある。通常はプロセッサがソフトウエア割り込み機能を提供しており、図３の形での実装が容易であるが、ものによってはソフトウエア割り込み機能を提供していない場合があり、その場合は図２の形での実装形式となる。
【００１１】
上述の仕組みにより，たとえば，アプリケーション部で基本部（コンポーネントＩＤ＝０）の提供するサービス機能のうち，Function2（システムコールＮｏ＝２）を呼出す場合には，アプリケーション部で記述されたFunction2がシステムコールライブラリによって解釈され，図２に示すようにコールゲート関数（CallGate）にパラメータとともにコンポーネントＩＤ（この場合０）とシステムコールＮｏ（この場合２）を渡すのである。そして，呼出されたコールゲート関数（CallGate）は，まず，コンポーネントＩＤからその番号に対応したサービスエントリポイントを把握し，次に，システムコールＮｏからその番号に対応した実態が存在するアドレスを把握し，最終的に基本部が提供するサービス機能であるFunction2を呼出すのである。
【００１２】
また，各コンポーネントの初期化ルーチンを図４に基づいて説明する。図４において、７はブート部、８はコンポーネント管理テーブル、９はＦＬＡＳＨメモリ、10はＲＡＭを示しており、これらは各コンポーネントに設けられる。各コンポーネントの初期化ルーチンは，図４のように，各コンポーネントＩＤに対応した初期化ルーチンのエントリポイントとしてコンポーネント管理テーブル８として設定しておく。そして，ブート部７は，このコンポーネント管理テーブル８を参照することにより，各コンポーネントを順番にローディングしながら，その初期化ルーチンを呼出すのである。このようにして，各コンポーネントが動き出す前に全てのコンポーネントが他のコンポーネントに提供するサービス機能を図１に示すゲート管理部４のコールゲート管理テーブル５に登録することが可能となっているのである。
【００１３】
このように，本発明によるソフトウェア構成では，各コンポーネントが互いに独立しているため，ソフトウェアの入替えをコンポーネント単位でおこなえることになる。たとえば，図５に示すようにアプリケーション部３を入替えることを考えた場合，プログラムの実行時に新しいアプリケーション部3aのロードモジュールをＲＡＭ10上の空き領域に転送した後（転送1)），ＦＬＡＳＨメモリ９に書き込む処理をしておけば（書込み2)），プログラムをリセットすれば，その後は新しいアプリケーション部３で起動させることが可能となる（ローディング3)）。図５はアプリケーション部３の入れ替えの例を示したが、システムの稼動中に入れ替えるのが難しい基本部１の入れ替えも可能である。また，図６に示すように基本部１から起動中のアプリケーション部３に対して，停止完了フラグによって停止完了を通知（停止完了フラグ2)）してもらうような形で停止要求を出し（停止要求1)），完了フラグによる停止完了通知確認後に新しいアプリケーション部3aのロードモジュールをローディングすることより（ローディング3)），プログラムの実行中（システムの稼動中でも）にそのコンポーネントのみを入れ替えるといったことも可能となる。さらに，コンポーネントのローディングにあたっては，別途設けた定義ファイル等を参照することによって，ローディングするコンポーネントを選択したり，起動モードといったような条件によって選択したりすることも可能となる。組み込み製品の実現にあたっては、全ての機能を必要としない場合やリソース（RAMやI/Oなどの資源）の制限があるため、不必要なサービス機能を起動させないような仕組みは大きなメリットである。
【図面の簡単な説明】
【００１４】
【図１】本システムのソフトウェア構成図
【図２】コールゲート固定番地方式によるシステムコールライブラリ構造を説明するための図
【図３】コールゲートソフトウェア例外方式によるシステムコールライブラリ構造を説明するための図
【図４】コンポーネントのローディングと初期化エントリコールを説明するための図
【図５】プログラムリセットによるコンポーネントの入替えを説明するための図
【図６】プログラム実行中でのコンポーネントの入替えを説明するための図
【図７】従来のソフトウェア構成図
【図８】従来の他のソフトウェア構成図
【符号の説明】
【００１５】
１  基本部
２  ミドルウエア部
３  アプリケーション部
４  ゲート管理部
５  コールゲート管理テーブル
６  管理テーブル
７  ブート部
８  コンポーネント管理テーブル
９  ＦＬＡＳＨメモリ
10  ＲＡＭ
【図１】
2005084900.tif 000003
【図２】
2005084900.tif 000004
【図３】
2005084900.tif 000005
【図４】
2005084900.tif 000006
【図５】
2005084900.tif 000007
【図６】
2005084900.tif 000008
【図７】
2005084900.tif 000009
【図８】
2005084900.tif 000010