JP2008146480A - オブジェクト指向型車両用制御システム及びプログラム搭載支援システム - Google Patents

Abstract

【課題】リスナー登録リストに割り当てられるＲＡＭ領域のサイズを、ＲＯＭ内の補助リストの占有サイズに応じて適正化する。
【解決手段】搭載先となる車両に対応する補助リスト２０３の補助リストのデータサイズに基づいてリスナー登録リストのＲＡＭ上の割当領域サイズ２２１を決定し、決定された割当領域サイズ２２１をプログラム搭載先となる車両のＲＡＭに対して設定する。
【選択図】図１Ｄ

Description

この発明は、オブジェクト指向型車両用制御システム及びプログラム搭載支援システムに関する。

特開２００１−２７０３９９号公報

近年、自動車に搭載される電子機器の制御は、ＥＣＵと呼ばれるマイコン（ＭＰＵ）を含んだハードウェアユニットを用いて行なうのが主流となっている。特許文献１に例示するごとく、この制御を、オブジェクト指向により設計されたコンピュータシステム（以下、「オブジェクト指向システム」ともいう）により実現する方式も普及している（特許文献１）。オブジェクト指向システムの採用により、制御に関与する機器のハードウェア構成の相違を、ソフトウェアを構成するオブジェクトの内部に隠蔽することができ、制御対象毎に各制御プログラムの独立性を高めることができる。オブジェクト指向型のプログラミング言語としては、例えばＪａｖａ（登録商標）やＣ＋＋が知られ、いずれもオブジェクトを単位として、プログラムの記述を行なう。オブジェクトは自律性をもつ有機的なプログラムの単位であり、データと手続きを一体化した形で記述される。プログラム全体としての仕事は、オブジェクト間のメッセージ交換により進められる。メッセージを受信することにより起動される手続きはメソッドと呼ばれる。オブジェクトへの仕事の依頼は、メソッドを介してのみ行なうことができ、オブジェクト内のデータへの直接のアクセスは禁止される。

オブジェクト指向システムにおいては、各オブジェクトが、自身に組み込まれているメソッドを呼び出すメッセージを他のオブジェクトから受け、そのメソッドによる実行結果をメッセージ元へ返す形で処理が実行されてゆく。ここで、オブジェクトは、クラス（クラスオブジェクト）と、そのクラスを用いて作成されるインスタンス（インスタンスオブジェクト）とに大別できる。クラスには、データが格納される変数の定義や、機能処理を記述したメソッドなどが記述されている。クラスはオブジェクトのテンプレートに相当するものであり、汎用的なメソッドの集合と変数の定義を有するのみで、このままでは具体的な処理を直接実行することができない。そこで、実際の処理内容を規定するオブジェクトであるインスタンスが、クラスに含まれる変数に具体的な値を代入し、また、クラスに記述されているメソッドのうち、実際に使用するものへのリンクを張るためのポインタを記述する、等の手続を経て作成される。なお、インスタンスは、あくまでクラスをテンプレートとして新たに作成されるものであり、元のクラスが書き換えられるのではない。また、実際の処理は、対応するクラスから作成された個々のインスタンスがメッセージを受け取り、該対応するクラスのメソッドへ制御を受け渡たす形で進んでゆく。

次に、オブジェクト指向システムにおいては、イベントシステムと称される概念が確立されている。「イベント」は、制御処理に関与する特定のオブジェクトが、ある定められた処理状態となることを条件として、他のオブジェクトに対応する操作や処理を要求するために発行されるものであり、発行されたイベントを対応するオブジェクトが受け、前述の操作や処理を実行する。この場合、イベント発行側のオブジェクトには、そのイベントに対応する処理を行なうためのメソッド（イベントハンドラ）が組み込まれていなければならない。しかし、該メソッドは必ずしも当該のオブジェクト内に存在しているとは限らず、むしろ、他のクラスからの継承により実装しているケースの方が圧倒的に多い。この場合、イベント発行側のオブジェクトは、イベントハンドラが直接組み込まれている継承先のクラスが見つかるまで検索を行なうことになる。しかし、イベントの発行数が増大し、また、同種のイベントに関与するクラスの数や関連分岐が多くなるにつれ、イベント処理の全体把握が非常に困難になり、システムが複雑化して、エラーあるいは誤処理の発生リスクが高くなる問題がある。

そこで、これを解決するために、代理イベントモデルと称されるシステムが考案され、実用に供されている。代理イベントモデルの概念では、イベント処理のためにイベントリスナーという専用クラスがインターフェースとして用意され、これを、受け側のオブジェクトに組み込んで使用する。イベントリスナー内には、そのイベントで使用するイベントハンドラのメソッドが用意されており、受け側のオブジェクトに代行してイベント処理を待ち受ける。その結果、発行されたイベントは全て一旦イベントリスナーに送られ、そこでイベント処理が実行され、結果が受け側のオブジェクト（つまり、最終的なイベント通知先となるオブジェクト）に受け渡される。これにより、発行されたイベントの処理のため、何処に存在するかわからないイベントハンドラを求めて継承先のクラス（スーパークラス）を探し回る問題が回避される。

しかしながら、イベント処理がイベントリスナーにクラス分離されることで、同種のイベントに対して、複数のインスタンス（アプリケーションプログラム）がイベントリスナーとなりうる場合、実際に通知を行なうイベントリスナーの特定や、その通知順あるいは通知タイミング処理に問題を生ずることがある。具体例を図１２に示す。

すなわち、イベントの発行元インスタンス１０１Ｊ（アプリケーションプログラム１：以下、アプリケーションプログラムのことを「アプリ」とも略記する）において、イベント通知先インスタンス１０２Ｊ〜１０２Ｌ（アプリ２〜アプリ４）にイベントクラス１０３のイベントリスナーが組み込まれているものとする。発行元インスタンス１０１Ｊにおいてイベント発生条件が成立し、イベントが発行されると、イベントクラス１０３のイベントリスナーを組み込んだインスタンスであるアプリ２〜アプリ４に自動的に順次受け渡す（通知）ことになる。

しかし、実際に欲する動作が、最初に発行されたイベントに対してはアプリ２にのみ通知を行い、そこからある時間遅れて同じイベントが再度発行されたときに、今度はアプリ３に対してのみ通知を行ないたい、といったような場合、図１２の方式では明らかに問題がある。つまり、最初のイベント発行でアプリ２だけでなくアプリ３（及びアプリ４）にも通知がなされ、本来望まれないタイミングであるにも拘わらずアプリ３（及びアプリ４）でイベントハンドラが動作して、システム全体としては誤動作につながってしまうのである。このような不具合を招く要因は、組み込まれたイベントリスナーにおいて、対象となるイベントの通知先（リスナー）が固定的（静的）に登録されており、登録されたリスナーに対して無条件にイベント通知を行なうようになっている点にある。

本発明の課題は、同種のイベントに対するリスナーの特定と、複数リスナーへの通知順序の制御を簡便かつ的確に行なうことができ、本来望まれないタイミングや意図しないリスナーに対してイベント通知がなされてしまう不具合を効果的に解消できるオブジェクト指向型車両用制御システムとそれに用いるプログラム搭載支援システムとを提供することにある。

課題を解決するための手段及び発明の効果

本発明のオブジェクト指向型車両用制御システムは、 ＣＰＵ、ＲＯＭ及びＲＡＭを有するマイコンを含んで構成され、車載用電子機器をＣＰＵにより、ＲＯＭに格納されたオブジェクト指向のプログラムを、ＲＡＭを作業領域として実行することにより動作制御する制御主体を有した車両用制御システムであって、プログラムが、
イベント生成オブジェクトが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行するイベント管理オブジェクトと、
イベントの通知先候補オブジェクトからイベント通知要求を受け付けるイベント通知要求受付オブジェクトと、
イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、ＲＡＭ上に領域確保されるリスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行されたイベントの通知を行なうイベント処理オブジェクトとを備え、
かつ、ＲＯＭには、リスナー登録リストへ登録可能な全ての通知先候補オブジェクトが、リスナー登録リストとは別の補助リストにイベントの発行と無関係に静的に登録されてなり、
リスナー登録リストに割り当てられるＲＡＭ上の領域サイズが、ＲＯＭ内における補助リストの占有サイズに対応した値に定められてなることを特徴とする。

上記構成によると、イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、リスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行されたイベントの通知が行なわれる。すなわち、リスナー登録リストを参照することにより、通知を欲する申し出（イベント通知要求）を行なった通知先候補オブジェクトにのみ、選択的にイベント通知を行なうことが可能となるので、同じイベントに対して通知先候補オブジェクトが複数存在している場合においても、意図しない通知先候補オブジェクトにまで無作為にイベント通知がなされてしまう不具合を効果的に解消できる。

また、リスナー登録リストへ登録可能な通知先候補オブジェクトの総数は、搭載先となる車種によって相違する。他方、イベント通知を司るプログラムは車種間で共有する方が製造上も能率がよいが、この場合、リスナー登録リストに割り当てられるＲＡＭ上の領域のサイズも、上記共有化の流れから、通知先候補オブジェクトの総数の多い車種に合わせて一定に設定することが一見望ましいと思われる。しかし、自動車用のＥＣＵは、コスト削減の観点からメモリ資源が限られており、容量の小さいＲＡＭを目一杯有効活用することが求められている。従って、通知先候補オブジェクトの総数が少ない車種では、リスナー登録リストに割り当てられるＲＡＭ領域が過剰となり、ＲＡＭ容量を有効活用する観点からは非常に好ましくない。さらに、車両開発の進展やモデルチェンジなどによる設計変更により、通知先候補オブジェクトの数が増減することもありえ、リスナー登録リストに割り当てられるＲＡＭ領域が固定では柔軟に対応できない問題がある。

しかしながら、本発明では、リスナー登録リストへ登録可能な全ての通知先候補オブジェクトが、ＲＯＭ内の静的な補助リスト（この補助リストの内容は、例えば車種毎に固有の内容を有している）として登録してあり、リスナー登録リストに割り当てられるＲＡＭ領域のサイズを、この補助リストの占有サイズに対応した値に定めるようにしたから、リスナー登録リストのＲＡＭ割当サイズを、例えば車種毎に適正化することが可能となり、ＲＡＭ領域が無駄に消費されることがない。また、車両開発の進展やモデルチェンジなどによる設計変更にも柔軟に対応できる。

イベント処理オブジェクトは、リスナー登録リストの登録内容を監視するとともに、イベント管理オブジェクトからの当該イベントの発行タイミングと、イベント通知要求受付オブジェクトによる通知先候補オブジェクトからのイベント通知要求の受け付けタイミングとに基づいてイベントの通知タイミングを決定し、リスナー登録リスト上の対応するリスナーに通知を行なうものとすることができる。つまり、固定的なリスナーリストにのみ頼った従来のイベント通知方式では、その通知タイミングがイベント発行タイミングにより一律に支配されてしまい、的確なタイミングでイベントを通知できない要因となっていた。しかし、本発明では、受け側となる通知先候補オブジェクトが自立的にイベント通知要求を出し、リスナーとして動的登録されるので、上記の方式により、通知先候補オブジェクトがイベント通知要求を出したタイミングも考慮して、どの通知先候補オブジェクトにいつイベントを通知するかを的確に把握でき、本来望まれないタイミングでイベント通知がなされてしまう不具合を効果的に解消できる。

イベント処理オブジェクトは、イベント管理オブジェクトが発行したイベントに対応するリスナーを、リスナー登録リストから該リスナー登録リストとは別に用意された通知実行用リストに複写し、当該通知実行用リスト上で通知実行対象となるリスナーを検索するように構築できる。そして、検索されたリスナーに対し、発行されたイベントの通知を順次実行するとともに、通知が完了したイベントに対応するリスナーを通知実行用リストから削除するものとできる。

このようにすると、イベント発行中に新たに登録されるリスナーは、通知実行用リスト上のリスナーに対するイベント通知が完了するまでリスナー登録リスト上に保留され、本来通知を受けるべきタイミングで次のイベントが発行されて、はじめて通知実行用リストに移ってイベント通知を受けることができるので、矛盾のないタイミングでのイベント通知が可能となる。

イベント処理オブジェクトは、リスナー登録リストに登録されたリスナーが、前述の補助リスト上のいずれかの通知先候補オブジェクトと一致する場合にのみ、該リスナーに対し発行されたイベントの通知を実行するものとして構築することができる。リスナー登録リストへのリスナーの登録は、上記のごとく、通知要求が発生するたびに動的に実施されるので、リスナー登録リスト自体は書換え可能なメモリ（ＥＥＰＲＯＭやフラッシュメモリも概念的には利用可能であるが、書換え速度が遅いのでＲＡＭであることが望ましい）上に作成する必要がある。上記のように構成すると、リスナー登録リストが書き込まれるメモリの記憶内容がバグや暴走等により破壊された場合も、固定的な補助リストを併用することで、イベント通知先のリスナーが正規のものであるか否かを容易に確認することができる。

次に、本発明のプログラム搭載支援システムは、上記本発明のオブジェクト指向型車両用制御システムを機能実現するオブジェクト指向のプログラムの、車両への搭載支援を行なうシステムであって、
搭載先となる車両毎に個別に用意された補助リストを記憶する補助リスト記憶手段と、
搭載すべき車両の補助リストを補助リスト記憶手段上にて特定し、その補助リストのデータサイズに基づいてリスナー登録リストのＲＡＭ上の割当領域サイズを決定する割当領域サイズ決定手段と、
決定された割当領域サイズをプログラム搭載先となる車両のＲＡＭに対して設定する割当領域サイズ設定手段と、を備えたことを特徴とする。

上記本発明のプログラム搭載支援システムを用いると、搭載先となる車両に対応する補助リストのデータサイズに基づいてリスナー登録リストのＲＡＭ上の割当領域サイズを決定し、決定された割当領域サイズをプログラム搭載先となる車両のＲＡＭに対して設定するようにしたから、リスナー登録リストに割り当てられるＲＡＭ領域のサイズを、ＲＯＭ内の補助リストの占有サイズに応じて適正化した本発明のオブジェクト指向型車両用制御システムを容易に得ることができる。

割当領域サイズ設定手段は、搭載すべきプログラムの、リスナー登録リストのＲＡＭ上の割当領域サイズを未定とした雛型プログラムを記憶する雛型プログラム記憶手段と、割当領域サイズ決定手段が決定した割当領域サイズを雛型プログラムに補完して搭載対象プログラムとする割当領域サイズ補完手段と、該搭載対象プログラムを車両側に転送する搭載対象プログラム転送手段と、を有するものとして構成することができる。リスナー登録リストのＲＡＭ上の割当領域サイズを未定とした雛型プログラムを用意しておき、割当領域サイズが決定される毎に雛型プログラムにこれを補完することで、リスナー登録リストに割り当てられるＲＡＭ領域のサイズ適正化を極めて簡便に実行することができる。

この場合、雛型プログラム記憶手段において雛型プログラムは、コンパイル型言語により、割当領域サイズを未定義定数として含んだ形で記述されたものとすることができる。 割当領域サイズ補完手段は、雛型プログラムの割当領域サイズを示す未定義定数を、決定された割当領域サイズにより書き換える未定義定数書換え手段と、その書き換えられた雛型プログラムを搭載対象プログラムとしてコンパイルする搭載対象プログラムコンパイル手段とを有するものとして構築できる。そして、搭載対象プログラム転送手段は、そのコンパイル済みの搭載対象プログラムを車両側に転送するものとして構成できる。コンパイル型の言語を採用することで、制御用のプログラムも補助リストも全て機械語にコンパイルしてから実車搭載することができ、実車側のプログラム（アプリケーション）動作環境を軽量化することができる。そして、本発明のプログラム搭載支援システムの上記構成を採用することで、コンパイル前の雛型プログラムの状態で割当領域サイズを容易に書き換えることができる。

オブジェクト指向プログラミングに向くプログラミング言語としては、Ｃ、Ｃ＋＋、Ｊａｖａなどが知られているが、実車搭載時に機械語にコンパイルした形で搭載可能な点を考慮すると、特にＣやＣ＋＋を採用することが望ましい（Ｊａｖａの場合は、実車側にＪａｖａの動作環境を構築する仮想マシンを搭載しておく必要がある）。

この場合、割当領域サイズ決定手段は、補助リスト記憶手段に記憶されている非コンパイル状態の補助リストのソースコードを解析することにより、コンパイル後の補助リストのメモリ占有サイズを算出し、その算出値に基づいてリスナー登録リストのＲＡＭ上の割当領域サイズを決定するものとして構築できる。非コンパイル状態の補助リストのソースコード解析により算出される補助リストのメモリ占有サイズを用いることで、リスナー登録リストのＲＡＭ割当領域サイズをより適正に決定できる。Ｃを採用する場合、プリプロセッサが未定義定数書換え手段の役割を果たし、該プリプロセッサは、算出された割当領域サイズの値を記述したヘッダファイルを生成し、これを用いてコンパイル前の雛型プログラムの割当領域サイズに該当する未定義定数の書換え処理を行なう。

以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明のオブジェクト指向型車両用制御システムにおける制御主体４０の構成を、オブジェクト指向プラットフォームの観点から概念的に示す図である。本実施形態では、制御主体４０は、Ｃ言語で記述されたプログラムに基づく情報処理を実行する演算処理装置（ＥＣＵ：以下、ＥＣＵ４０ともいう）として構成されている。プログラム実行装置１は、Ｃ言語によるバイトコードを実行する回路が組み込まれたＣＰＵであり、プログラム実行部３、メソッド検索部４、メモリコントローラ５などを具備する。メモリ２は、ＲＯＭまたはＲＡＭ、あるいは両者を包括した記憶領域を示しており、プログラムデータ領域６や検索用テーブル領域７などの記憶領域が設定される（なお、図１では、プログラム実行装置１を便宜上単一のＣＰＵとして扱っているが、構成はこれに限られるものではなく、例えば、ＣＡＮ（Controller Area Network）等の車載ネットワークにより接続されたＣＰＵ群であってもよい）。

前記プログラムデータ領域６には、Ｃ言語のソースプログラムよりコンパイルされたバイトコードの実行プログラムが格納される（以下、１アドレス分のプログラムを「プログラムデータ」という）。検索用テーブル領域７には、メソッドの呼出し時に、呼び出されたメソッドが格納されている場所を検索するために、図示しないクラステーブルやメソッドテーブルなどが格納される。

プログラム実行装置１におけるメモリアクセスは、メモリコントローラ５により制御される。プログラム実行部３は、メモリコントローラ５に、読み出すべきプログラムデータの格納先を示すプログラムアドレスを与えることにより、前記プログラムデータ領域６から該当するプログラムデータを得て実行する。特にそのプログラムデータがメソッド呼出しを示すメッセージであったとき、プログラム実行部３は、そのメッセージをメソッド検索部４に送信して、メソッドの格納先の検索を要請する。

メッセージには、メッセージの対象となるオブジェクトの所属するクラス名、実行すべきメソッドのメソッド名、引数、戻り値の有無やその型を示すデータが含まれる。メソッド検索部４は、このメッセージにより、メッセージの対象となるオブジェクトが所属するクラスや指定されたメソッドを認識した後、前記検索用テーブルを用いてメソッドの格納場所を検索する。この検索処理は、メモリコントローラ５に、検索用テーブル領域７内で必要な検索用情報の格納先のアドレス（図中、「テーブルアドレス」と示す）を指定して情報の読出しを行なわせることにより実現する。なおテーブルアドレスは、各検索用テーブルのエントリ位置を示すポインタ、またはメモリ２において前記エントリ位置に該当する領域のアドレスを示す値により与えられる。

メソッド検索部４は、検索結果として、指定されたメソッドの格納場所の先頭アドレス（以下「プログラム先頭アドレス」という）を取得し、このプログラム先頭アドレスを、プログラムカウンタとしてプログラム実行部３に送信する。プログラム実行部３は、図示しないスタック用のメモリ領域に前記メソッドのための作業領域を設定するとともに、前記プログラムカウンタが示すアドレスを起点としてプログラムデータ領域６から前記メソッドを構成する各プログラムデータを順次読み出して、各プログラムデータに応じた処理を実行する。

図１Ｂに、制御主体４０を、マイコンを主体とするＥＣＵ４０にて構成した例を示す。プログラム実行装置１はＣＰＵ１であり、メモリ２はＲＡＭ２Ａ及びＲＯＭ２Ｂとからなる。ＲＡＭ１Ａには後述のリスナー登録リスト２０１と通知実行用リスト２０２とが形成されている。また、ＲＯＭ２Ｂには、上記のプログラムデータ６と検索用データテーブル７及び補助リスト２０３が格納されている。上記のＣＰＵ１、ＲＡＭ２Ａ、ＲＯＭ２Ｂ及び入出力部１０２が内部バスにより相互接続されている。

該ＥＣＵ４０は、車載ネットワーク（通信プロトコル：例えばＣＡＮ（Controller Area Network））を構築するシリアル通信バス３０により、各々シリアルインターフェース１０７及び受信バッファ１０７ａを介して、車両上の他のＥＣＵ群と接続されている。シリアル通信バス３０には外部機器接続用のコネクタ１０９も接続され、該コネクタ１０９に調整ツール１０が接続される。

この調整ツール１０は、本発明のプログラム搭載支援システムの要部を構成するものである。図１Ｃは、調整ツール１０の電気的構成を示すブロック図である。調整ツール１０は、ＣＰＵ１１３、ＲＡＭ１１４、ＲＯＭ１１５（フラッシュメモリ等の不揮発性メモリからなる）、入出力部１１２が内部バスにて接続されたマイコンを主体とする。入出力部１１２には、キーボード１１６と液晶パネル等からなるモニタ１１７とが接続されている。ＲＯＭ１１５には、Ｃ言語用のコンパイラ１２１、プリプロセッサ１２２、リスナー登録リスト２０１のＲＡＭ２Ａ上の割当領域サイズを解析するための解析ファームフェア１２３、前述の実行プログラムの、リスナー登録リスト２０１の上記割当領域サイズを未定とした雛型プログラム１２３及び各種車種にて使用する補助リスト１２４がライブラリ化された形で格納されている。また、ＲＡＭ１１４には、解析ファームフェア１２３の作業領域１３１、その解析結果が記述されたヘッダファイルを格納するためのヘッダファイル格納領域１３２、プリプロセッサ１２２の作業領域１３３及びコンパイル用領域１３４が各々形成されている。モニタ４１に表示される指示内容に従いキーボード１１６からオペレーターが適宜コマンド入力を行なうことで、調整ツール１０は、解析ファームフェア１２３により、対象車種の補助リストの内容を解析してリスナー登録リスト２０１の割当領域サイズを決定する割当領域サイズ処理と、プリプロセッサ１２２により、割当領域サイズを（コンパイル前の）雛型プログラムに補完して搭載対象プログラムとする処理と、搭載対象プログラムを機械語にコンパイルしてＥＣＵ４０のＲＯＭ２Ｂに転送する処理を順次行なう。

次に実行プログラムは、上記オブジェクト指向プラットフォーム上に構築されるものである。図２は、そのプログラムの構成を示すＵＭＬ（Unified Modeling Language）表記に従ったクラス図である。該プログラムは、次のようなオブジェクトによって構成されている。
・イベント管理オブジェクト１０１Ｃ：イベント生成オブジェクト１０１Ｊが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行する。
・イベント通知要求受付オブジェクト１０２Ｃ：イベントの通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌからイベント通知要求を受け付ける。
・イベント処理オブジェクト１０３Ｃ：イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌをリスナーとして、リスナー登録リスト２０１にその都度動的に登録するとともに、該リスナー登録リスト２０１に登録されているリスナーに対してのみ、発行されたイベントの通知を行なう。

イベント管理オブジェクト１０１Ｃは、イベント発生元となるアプリケーションプログラム（図２では、アプリ１を表示）に対応したインスタンスオブジェクトをイベント生成オブジェクト１０１Ｊとして作成可能なクラスオブジェクトである。アプリケーションプログラム側にてイベントが生成されるに伴い、当該インスタンスオブジェクトを作成するとともに生成した該イベントを発行して、イベント処理オブジェクト１０３Ｃに受け渡すよう動作する。

イベント通知要求受付オブジェクト１０２Ｃは、イベント通知先となるアプリケーションプログラムに対応したインスタンスオブジェクトを通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌとして作成可能であり、かつ、通知対象となるイベントに対応したイベントリスナークラス１０４Ｉをインターフェースとして実装したクラスオブジェクトである。そして、該イベントリスナークラス１０４Ｉに呼び出された通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌがリスナーとして、イベント処理オブジェクト１０３Ｃのリスナー登録リスト２０１（及び、後述の通知実行用リスト２０２と補助リスト２０３）に組み込まれている。なお、図２では、リスナー登録リスト２０１を「動的に登録されたリスナーリスト」、通知実行用リスト２０２を「イベント発行中のリスナーリスト」と、及び補助リスト２０３を「静的に登録されているリスナーリスト」と表記している。

そして、イベント処理オブジェクト１０３Ｃは、リスナー登録リスト２０１の登録内容を監視するとともに、イベント管理オブジェクト１０１Ｃからの当該イベントの発行タイミングと、イベント通知要求受付オブジェクト１０２Ｃによる通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌからのイベント通知要求の受け付けタイミングとに基づいてイベントの通知タイミングを決定し、リスナー登録リスト２０１上の対応するリスナーに通知を行なう。

図３は、図１のクラス図に対応するシーケンス図である。すなわち、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌは、そのどれかがイベント通知要求を行なうたびに、イベント通知を受けるリスナーとして、図４Ａのリスナー登録リスト２０１にその都度動的に登録される。そして、該リスナー登録リスト２０１に登録されているリスナーに対してのみ、発行されたイベントの通知が行なわれる。すなわち、リスナー登録リスト２０１を参照することにより、通知を欲する申し出（イベント通知要求）を行なった通知先候補オブジェクトにのみ、選択的にイベント通知を行なうことが可能となる。その結果、同じイベントに対して通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが複数存在している場合においても、受け側となる通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが自立的にイベント通知要求を出し、その都度リスナーとして動的登録され、登録されているリスナーについてのみイベント通知がなされる。従って。図１２のように、意図しない通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌにまで無作為にイベント通知がなされてしまう不具合が生じず、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌ毎に適正なタイミングでイベント通知が可能となる。この場合、１つの通知に付き、その都度個別にイベントを発行する形となる。

図４Ａは、リスナー登録リスト２０１を概念的に示すものである。リスナー登録リスト２０１は常時新しいリスナーの登録を受け付け可能な状態になっており、あるイベントの発行中に、同じイベントに対するリスナーが追加登録されることがある。このリスナーは、発行中のイベントに関与するリスナーと同じであってもよいし、異なるリスナーであってもよい。前者の場合は、発行中のイベントの通知がなされた後、同種のイベントが次回に発行されたときも同じリスナーに通知されることになるし、後者の場合は、次回に発行されるイベントが別のリスナーに通知される形になる。いずれにしろ、登録されるリスナーは、イベントの種別毎に通知要求のあった時系列順に順次登録され、先頭のものから順に対応するイベントの通知を受けることになる。

ここで、リスナー登録リスト２０１上でリスナーを直接サーチしてイベント通知を実行する処理とした場合、あるイベントの発行途中に、そのイベントに対する新たなリスナーが追加されると、後で追加されたリスナーに対して、次回以降のイベントループ周期で本来通知したかったイベントが、現在発行中のイベントをカバーするイベントループのサーチ周期に偶然引っかかってしまい、望みのタイミングよりも早くイベント通知されてしまう不具合を生じうる。

これを解決するために、本実施形態では、次のような方式が採用されている。すなわち、イベント処理オブジェクト１０３Ｃにおいて、図４Ａに示すように、イベント管理オブジェクト１０１Ｃが発行したイベントに対応するリスナーを、リスナー登録リスト２０１から該リスナー登録リスト２０１とは別に用意された通知実行用リスト２０２に複写し、当該通知実行用リスト２０２上で通知実行対象となるリスナーを検索するようにする。そして、検索されたリスナーに対し、発行されたイベントの通知を順次実行する。なお、通知が完了したイベントに対応するリスナーは通知実行用リスト２０２から削除される。

あるイベントの発行中に、他のイベントに対するイベント通知要求がなされた場合、当該イベント通知要求を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌ（アプリ２〜アプリ４）がリスナーとしてリスナー登録リスト２０１に登録されるとともに、該リスナーは、対応するイベントの発行がなされるまでリスナー登録リスト２０１上に保持されることになる。イベント発行中に新たに登録されるリスナーは、通知実行用リスト２０２上のリスナーに対するイベント通知が完了するまで、リスナー登録リスト２０１上に保留され、本来通知を受けるべきタイミングで次のイベントが発行されると、はじめて通知実行用リスト２０２に移ってイベント通知を受けることができる。これにより、上記のような不具合が解消される。なお、イベント通知タイミングの精度を向上するため、イベント処理オブジェクト１０３Ｃにおいては、イベント管理オブジェクト１０１Ｃがイベントを発行するに伴い、該イベントに対応するリスナーを、リスナー登録リスト２０１から通知実行用リスト２０２に直ちに複写するようになっている（図２からも明らかな通り、各リスト２０１〜２０３は、リスナー登録数が０以上であって上限を設けない形で定義されている（0..*））。

なお、インスタンス（種別）の異なるイベントが順次発行される場合でも、対応するリスナーへスムーズにイベント通知を行なうことができるようにするために、図４Ａに示すように、インスタンスの異なる複数のイベント（α、β、γ‥）のそれぞれについてリスナー登録リスト２０１は個別に用意されている。イベント処理オブジェクト１０３Ｃは、イベントが発行された場合に、該イベントに対応するリスナー登録リスト２０１からリスナーを通知実行用リスト２０２に順次複写する。

図４Ａにおいては、イベントβに対し、アプリ２から通知要求が出された場合を例示している。リスナー登録リスト２０１のイベントβの割当領域には、アプリ２（番号「２」で識別している）がリスナーとして既に登録されている。そして、イベントβが実際に発行されると、リスナー登録リスト２０１のリスナーであるアプリ２を、通知実行用リスト２０２に複写する（Ｔ１）。そして、その通知実行用リスト２０２をサーチすることで、その複写された「アプリ２」が検索され、イベントβが通知される（Ｔ２）。

なお、通知が完了したイベントに対応するリスナーは、通知実行用リスト２０２からは必ず削除（あるいは無効化）する必要がある（そうでなければ、発行されたイベントに通知が重複して実行されることにつながる）。また、リスナー登録リスト２０１上のリスナーの扱いについても、リスナーの登録タイミングがイベント通知のタイミング支配要因の一つとなっているので、基本的には、イベント処理オブジェクト１０３Ｃは、発行されたイベントに対応するリスナーをリスナー登録リスト２０１から通知実行用リスト２０２に複写するに伴い、当該リスナーを複写元となるリスナー登録リスト２０１から削除するように構成しておく必要がある。

しかし、あるイベントの同じリスナーへの通知頻度が高い場合については、その特定のリスナーを必要な期間だけ（あるいは永続的に）リスナー登録リスト２０１上に留保できるようにしたほうが、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌがいちいち通知要求を出す必要がなくなるので、便利なことがある。この場合、イベント処理オブジェクト１０３Ｃは、予め定められたリスナーについて、発行されたイベントに対応するリスナーをリスナー登録リスト２０１から通知実行用リスト２０２に複写するに伴い、当該リスナーを複写元となるリスナー登録リスト２０１上に保持しつづけるものとして構築される。リスナー登録リスト２０１上でのリスナー登録状態の保持は、一部の特定のリスナーについては永続的に設定することもできるが、期間限定的に保持を行ないたい場合は、イベント処理オブジェクト１０３Ｃは、予め定められたリスナーのうち特定のものについて、他のオブジェクトからの削除依頼を受けた場合に当該リスナーを複写元となるリスナー登録リスト２０１から削除するものとして構築すればよい。いずれにしろ、リスナー登録リスト２０１上に保持され続けるリスナーについては、イベントの通知タイミングは、該イベントの発行タイミングに支配されることになる。

次に、本実施形態では、リスナー登録リスト２０１へ登録可能な全ての通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが、リスナー登録リスト２０１とは別の補助リスト２０３にイベントの発行と無関係に静的（固定的）に登録されている。図４Ｂに示すように、イベント処理オブジェクト１０３Ｃは、イベント発行要求を受けるに伴い（Ｔ５１），リスナー登録リスト２０１に登録されたリスナーが、補助リスト２０３上のいずれかの通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌと一致するか否かにより正規のリスナーであるか否かが判定され（Ｔ５２）、正規のリスナーであった場合にのみ、該リスナーに対し発行されたイベントの通知を実行する（Ｔ５３，Ｔ５４）。リスナー登録リスト２０１へのリスナーの登録は、上記のごとく、通知要求が発生するたびに動的に実施されるので、リスナー登録リスト２０１自体は書換え可能なメモリ上に作成する必要がある。このメモリは、具体的には図１のメモリ２であり、ＲＡＭで構成されるが、バグや暴走等により記憶内容が失われるリスクは常に存在する。しかし、上記のように、固定的な補助リスト２０３を併用することで、リスナー登録リスト２０１が書き込まれるメモリの記憶内容がバグや暴走等により破壊された場合も、イベント通知先のリスナーが正規のものであるか否かを容易に確認することができる。

以下、調整ツール１０を用いて実行プログラムを車両側に搭載する処理について説明する。該調整ツール１０をコネクタ１０９により、図１Ｂに示す車両側のシリアル通信バス３０に接続する。次いで、図１Ｃの調整ツール１０のキーボード１１６から、実行プログラム搭載対象となる車両の特定情報を入力する。これにより、ＲＯＭ１１５上にて当該車種に対応する補助リストが特定される。

続いて解析ファームウェア１２３が立ち上がり、特定された補助リストのデータサイズに基づいてリスナー登録リストのＲＡＭ上の割当領域サイズが決定される。具体的には、図１Ｄに示すように、非コンパイル状態の補助リスト２０３上にてソースコードを解析することにより（図１Ｃの解析用作業領域１３１を利用する）、イベントリスナーの特定情報を示すデータ（Object 1、Object 2、‥）を抽出する。そして、抽出されたソースコードのコンパイル後のバイト数（つまり、補助リストのメモリ占有サイズ）を算出し、その算出値をリスナー登録リスト２０１のＲＡＭ上の割当領域サイズ（定数名：Rom Table Size）として決定する。

決定された割当領域サイズは、定数Rom Table Sizeの定義値として、ヘッダファイル２２１に書き出され、図１Ｃのヘッダファイル格納領域１３２に保存される。続いてプリプロセッサ１２２が立ち上がり、雛型プログラム１２３のソースコードをオープンする（プリプロセッサ作業領域１３３を利用する）。この雛型プログラム１２３は車種間で共通であり、リスナー登録リスト２０１のＲＡＭ上の割当領域サイズ（Rom Table Size）が定数未定義の形で記述されている。プリプロセッサ１２２は、ヘッダファイル２２１から定数Rom Table Sizeの定義値を読出し、雛型プログラム１２３の未定義定数にこれを書き込んで補完する。

上記割当領域サイズの定義値が補完されることで、雛型プログラム１２３は対応する車種の実行プログラムとなる。次いでコンパイラ１２１を立ち上げ、コンパイル用領域１３４を用いて、該実行プログラムを機械語にコンパイルする。コンパイル済みの実行プログラムは、図１Ｂのシリアル通信バスを介して、対象となるＥＣＵ４０のフラッシュＲＯＭ２Ｂに書き込まれ、実車搭載処理が終了する。

以下、本発明を車載用のセキュリティシステムに適用・展開した事例について説明する。図５は、オブジェクト指向型車両用制御システムの一具体化例であるセキュリティシステム１００の、概略ハードウェア構成を示すブロック図である。セキュリティシステム１００は、マイコン制御される侵入検知装置４２と、該侵入検知装置４２からの検知情報を受け、アラームを動作させたり、監視カメラによる車内画像撮影等のセキュリティ処理をマイコン制御により実行したりするセキュリティ制御部４１とが通信ネットワークにより接続されたシステムとして構成されている（以下、「セキュリティシステム４０」とも記載する）。また、セキュリティ制御部４１はユーザーが所持する携帯電話や、外部の警備センターなどと無線通信可能とされており、異常発生した場合の報知情報や、撮影画像等を無線送信することができる。

図６に示すごとく、ユーザーが携帯電話４３でセキュリティ制御部４１に電話をかけ、セキュリティセットを指令した場合を考える。セキュリティ制御部４１が侵入検知装置４２にセキュリティセットを指示し、そのセット完了のステータスを侵入検知装置４２から受け、これをユーザー（の携帯電話４３）にセット完了通知する動作を第一動作とする。また、セキュリティセット状態の侵入検知装置４２が車両への侵入を検知し、これをユーザー（の携帯電話４３）にアラーム通知する第２動作とする。イベント発行元となるアプリ１と、セキュリティ制御部４１に実装され、その通知先候補となるアプリ２（及び３，４）が侵入検知装置４２に実装されているものとする。

図１２の従来例に対応するパターンとして、第一動作では、セット完了のステータスを侵入検知装置４２から受けることを条件として「通知完了」を返すイベントが発行されるものとし、そして、第二動作では、侵入検知を侵入検知装置４２から受けることを条件として「通知完了」を返すイベントが発行されるものとする。また、リスナーはアプリ２（及び３，４）に固定的に登録されているのみとする。

セキュリティセットが完了して、十分な時間をおいて侵入検知がなされ、かつ、ユーザーの携帯電話４３への通知もいずれもうまくいった場合は、図６に示すように、イベントリスナーは矛盾なく動作し、いずれのイベント通知（セット完了あるいは侵入検知通知完了）も適正なタイミングでなされていることがわかる。

ところが、ユーザーの携帯電話４３は、電源が切れていたり、話中であったり、あるいは電波の届かない場所にあった場合は無線接続不可であるから、これを用いたユーザーへの通知が失敗することがある。また、ユーザーが携帯電話４３によりセキュリティセットした時点で、既に車両に賊が侵入していることもありえる。すると、図７に示すような不具合動作を生ずる。

つまり、侵入検知装置４２は、セキュリティセットされた時点で既に侵入検知も能動化されている状態にあるので、第一動作でのイベント通知は矛盾なく実行されるのに対し、そのあと切れ目なく侵入検知通知が侵入検知装置４２から返ってくることになる。このとき、ユーザーの携帯電話４３は、セキュリティセットのために車両側と電話がつながっている状態にあるから、車両側から侵入報知のためにユーザーに電話をかけようとしても「つながらない」状態となり、通知に失敗することになる。しかし、上記のイベントリスナーは、侵入検知を侵入検知装置４２から受ければ、直ちに「通知完了」のイベント通知を行なってしまうので、ユーザーへの通知が実際には失敗していることと矛盾する。

しかし、上記本実施形態の方式を採用することで、この問題は以下のように解消される（図９は、オブジェクト間の情報の流れを示し、図８は、イベント通知処理全体にかかるセキュリティ制御部４１内の処理の流れを示す）。図９に示すごとく、侵入検知装置４２側のアプリ２（３，４）側では、侵入検知するとイベント通知要求を行い（図８：Ｓ１）、リスナーとして動的に登録される（図９：応答先設定（ｂ）／図８：Ｓ２）。一方、イベント管理オブジェクト１０１Ｃでは、ユーザーへの通知処理を行い（図９：（ｃ）／図８：Ｓ３）、この通知が正常に完了した場合に限りイベントを有効化し、これをイベント処理オブジェクト１０３Ｃに発行する（図９：（ｅ）／図８：Ｓ４→Ｓ５）。

図１０に示すように、イベント処理オブジェクト１０３Ｃでは、前述のごとく、発行されたイベントに対応するリスナーを、リスナー登録リスト２０１から通知実行用リスト２０２に複写し、さらに、その通知実行用リスト２０２に複写されたリスナーが、補助リスト２０３に固定的に登録されているリスナーのどれかと一致した場合に、はじめて完了通知（イベント通知）を侵入検知装置４２に返す（図９：（ｆ）／図８：Ｓ６）。

その結果を示すシーケンス図が図１１である。つまり、前述のごとく、ユーザー側の携帯電話４３がセキュリティセットのために通話中の間は、ユーザー通知が失敗するが、この場合は、イベントが発行されないので、完了通知（イベント通知）が侵入検知装置４２に返っていない。侵入検知装置４２はイベント通知を受け取れないので、やむなく侵入検知通知の再送を行なう。このとき、ユーザーの携帯電話４３が通話終了し、呼び待ちの状態になっていれば、今度はユーザー通知が成功するので、ここではじめて通知完了を返すイベントが発行され、矛盾のない処理が実現する。

本発明のオブジェクト指向型車両用制御システムにおける制御主体の構成を、オブジェクト指向プラットフォームの観点から概念的に示す図。 制御主体のマイコンハードウェア構成の一例を示すブロック図。 調整ツールの構成の一例を示すブロック図。 本発明のプログラム搭載支援システムの作用説明図。 図１の制御主体が実行するプログラムの構成を示すＵＭＬ表記に従ったクラス図。 図１のクラス図に対応するシーケンス図。 リスナー登録リストをその使用方法とともに概念的に示す図。 補助リストの使用方法を示すフローチャート。 オブジェクト指向型車両用制御システムの一具体化例であるセキュリティシステムの、概略ハードウェア構成を示すブロック図。 従来のセキュリティシステムにおける正常時の動作を示すシーケンス図。 同じく不具合時の動作を示すシーケンス図。 イベント通知処理全体にかかるセキュリティ制御部内の処理の流れを示すフローチャート。 図８に対応するオブジェクト間の情報の流れを示す概念ブロック図。 図９のイベント処理部の詳細を示す概念ブロック図。 図８に対応するシーケンス図。 従来のシステムの問題点を示す図。

符号の説明

１ プログラム実行装置（ＣＰＵ）
１０ 調整ツール（プログラム搭載支援システム）
４０ 制御主体
１０１Ｃ イベント管理オブジェクト
１０１Ｊ イベント生成オブジェクト
１０２Ｃ イベント通知要求受付オブジェクト
１０２Ｊ，１０２Ｋ，１０２Ｌ 通知先候補オブジェクト
１０３Ｃ イベント処理オブジェクト
１１５ ＲＯＭ（補助リスト記憶手段）
１２１ コンパイラ（搭載対象プログラムコンパイル手段）
１２２ プリプロセッサ（割当領域サイズ設定手段、未定義定数書換え手段）
１２３ 解析ファームウェア（割当領域サイズ決定手段）
２０１ リスナー登録リスト
２０２ 通知実行用リスト
２０３ 補助リスト

Claims (13)

1. ＣＰＵ、ＲＯＭ及びＲＡＭを有するマイコンを含んで構成され、車載用電子機器を前記ＣＰＵにより、前記ＲＯＭに格納されたオブジェクト指向のプログラムを、前記ＲＡＭを作業領域として実行することにより動作制御する制御主体を有した車両用制御システムであって、前記プログラムが、
   イベント生成オブジェクトが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行するイベント管理オブジェクトと、
   前記イベントの通知先候補オブジェクトからイベント通知要求を受け付けるイベント通知要求受付オブジェクトと、
   前記イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、前記ＲＡＭ上に領域確保されるリスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行された前記イベントの通知を行なうイベント処理オブジェクトとを備え、
   かつ、前記ＲＯＭには、前記リスナー登録リストへ登録可能な全ての前記通知先候補オブジェクトが、前記リスナー登録リストとは別の補助リストに前記イベントの発行と無関係に静的に登録されてなり、
   前記リスナー登録リストに割り当てられる前記ＲＡＭ上の領域サイズが、前記ＲＯＭ内における前記補助リストの占有サイズに対応した値に定められてなることを特徴とするオブジェクト指向型車両用制御システム。
2. 前記イベント処理オブジェクトは、前記リスナー登録リストに登録された前記リスナーが、前記補助リスト上のいずれかの通知先候補オブジェクトと一致する場合にのみ、該リスナーに対し発行された前記イベントの通知を実行する請求項１記載のオブジェクト指向型車両用制御システム。
3. 前記イベント処理オブジェクトは、前記リスナー登録リストの登録内容を監視するとともに、前記イベント管理オブジェクトからの当該イベントの発行タイミングと、前記イベント通知要求受付オブジェクトによる前記通知先候補オブジェクトからのイベント通知要求の受け付けタイミングとに基づいて前記イベントの通知タイミングを決定し、前記リスナー登録リスト上の対応するリスナーに通知を行なう請求項１又は請求項２に記載のオブジェクト指向型車両用制御システム。
4. 前記イベント処理オブジェクトは、前記イベント管理オブジェクトが発行したイベントに対応するリスナーを、前記リスナー登録リストから該リスナー登録リストとは別に用意された通知実行用リストに複写し、当該通知実行用リスト上で通知実行対象となるリスナーを検索し、検索されたリスナーに対し、前記発行されたイベントの通知を順次実行するとともに、通知が完了したイベントに対応するリスナーを前記通知実行用リストから削除する請求項１ないし請求項３のいずれか１項に記載のオブジェクト指向型車両用制御システム。
5. 前記イベント処理オブジェクトは、前記イベント管理オブジェクトが前記イベントを発行するに伴い、該イベントに対応するリスナーを、前記リスナー登録リストから前記通知実行用リストに直ちに複写する請求項４記載のオブジェクト指向型車両用制御システム。
6. インスタンスの異なる複数のイベントのそれぞれについて前記リスナー登録リストが個別に用意され、前記イベント処理オブジェクトは、前記イベントが発行された場合に、該イベントに対応するリスナー登録リストから前記リスナーを前記通知実行用リストに順次複写するものである請求項４又は請求項５に記載のオブジェクト指向型車両用制御システム。
7. 前記イベント処理オブジェクトは、発行された前記イベントに対応する前記リスナーを前記リスナー登録リストから前記通知実行用リストに複写するに伴い、当該リスナーを複写元となる前記リスナー登録リストから削除する請求項４ないし請求項６のいずれか１項に記載のオブジェクト指向型車両用制御システム。
8. 前記イベント処理オブジェクトは、予め定められたリスナーについて、発行された前記イベントに対応する前記リスナーを前記リスナー登録リストから前記通知実行用リストに複写するに伴い、当該リスナーを複写元となる前記リスナー登録リスト上に保持しつづける請求項４ないし請求項６のいずれか１項に記載のオブジェクト指向型車両用制御システム。
9. 前記イベント処理オブジェクトは、前記予め定められたリスナーのうち特定のものについて、他のオブジェクトからの削除依頼を受けた場合に当該リスナーを複写元となる前記リスナー登録リストから削除する請求項４ないし請求項６のいずれか１項に記載のオブジェクト指向型車両用制御システム。
10. 請求項１ないし請求項９のいずれか１項に記載のオブジェクト指向型車両用制御システムを機能実現する前記オブジェクト指向のプログラムの、前記車両への搭載支援を行なうシステムであって、
    搭載先となる車両毎に個別に用意された前記補助リストを記憶する補助リスト記憶手段と、
    搭載すべき車両の前記補助リストを前記補助リスト記憶手段上にて特定し、その補助リストのデータサイズに基づいて前記リスナー登録リストの前記ＲＡＭ上の割当領域サイズを決定する割当領域サイズ決定手段と、
    決定された前記割当領域サイズをプログラム搭載先となる車両の前記ＲＡＭに対して設定する割当領域サイズ設定手段と、
    を備えたことを特徴とするプログラム搭載支援システム。
11. 前記割当領域サイズ設定手段は、
    搭載すべき前記プログラムの、前記リスナー登録リストの前記ＲＡＭ上の割当領域サイズを未定とした雛型プログラムを記憶する雛型プログラム記憶手段と、
    前記割当領域サイズ決定手段が決定した前記割当領域サイズを前記雛型プログラムに補完して搭載対象プログラムとする割当領域サイズ補完手段と、
    該搭載対象プログラムを前記車両側に転送する搭載対象プログラム転送手段と、
    を有する請求項１０記載のプログラム搭載支援システム。
12. 前記雛型プログラム記憶手段において前記雛型プログラムは、コンパイル型言語により、前記割当領域サイズを未定義定数として含んだ形で記述され、
    前記割当領域サイズ補完手段は、前記雛型プログラムの割当領域サイズを示す前記未定義定数を、決定された前記割当領域サイズにより書き換える未定義定数書換え手段と、
    その書き換えられた雛型プログラムを前記搭載対象プログラムとしてコンパイルする搭載対象プログラムコンパイル手段とを有し、
    前記搭載対象プログラム転送手段は、そのコンパイル済みの搭載対象プログラムを前記車両側に転送する請求項１１記載のプログラム搭載支援システム。
13. 前記割当領域サイズ決定手段は、前記補助リスト記憶手段に記憶されている非コンパイル状態の前記補助リストのソースコードを解析することにより、コンパイル後の補助リストのメモリ占有サイズを算出し、その算出値に基づいて前記リスナー登録リストの前記ＲＡＭ上の割当領域サイズを決定するものである請求項１２に記載のプログラム搭載支援システム。

Images