(57)【要約】【課題】  同種のイベントに対するリスナーの特定と、複数リスナーへの通知順序の制御を簡便かつ的確に行なうことができ、本来望まれないタイミングや意図しないリスナーに対してイベント通知がなされてしまう不具合を効果的に解消できるオブジェクト指向型車両用制御システムを提供する。【解決手段】  イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌをリスナーとして、リスナー登録リスト２０１にその都度動的に登録するとともに、該リスナー登録リスト２０１に登録されているリスナーに対してのみ、発行されたイベントの通知が行なわれる。すなわち、リスナー登録リスト２０１を参照することにより、通知を欲する申し出（イベント通知要求）を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌにのみ、選択的にイベント通知を行なうことが可能となる。【選択図】    図２
2008077219.tif 000002
【特許請求の範囲】
【請求項１】
ＣＰＵを含んで構成され、車載用電子機器を前記ＣＰＵにより、オブジェクト指向のプログラム処理により動作制御する制御主体を有した車両用制御装置であって、前記プログラムが、
イベント生成オブジェクトが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行するイベント管理オブジェクトと、
前記イベントの通知先候補オブジェクトからイベント通知要求を受け付けるイベント通知要求受付オブジェクトと、
前記イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、リスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行された前記イベントの通知を行なうイベント処理オブジェクトと、
を備えてなることを特徴とするオブジェクト指向型車両用制御システム。
【請求項２】
前記イベント処理オブジェクトは、前記リスナー登録リストの登録内容を監視するとともに、前記イベント管理オブジェクトからの当該イベントの発行タイミングと、前記イベント通知要求受付オブジェクトによる前記通知先候補オブジェクトからのイベント通知要求の受け付けタイミングとに基づいて前記イベントの通知タイミングを決定し、前記リスナー登録リスト上の対応するリスナーに通知を行なう請求項１記載のオブジェクト指向型車両用制御システム。
【請求項３】
前記イベント処理オブジェクトは、前記イベント管理オブジェクトが発行したイベントに対応するリスナーを、前記リスナー登録リストから該リスナー登録リストとは別に用意された通知実行用リストに複写し、当該通知実行用リスト上で通知実行対象となるリスナーを検索し、検索されたリスナーに対し、前記発行されたイベントの通知を順次実行するとともに、通知が完了したイベントに対応するリスナーを前記通知実行用リストから削除する請求項１又は請求項２に記載のオブジェクト指向型車両用制御システム。
【請求項４】
前記イベント処理オブジェクトは、前記イベント管理オブジェクトが前記イベントを発行するに伴い、該イベントに対応するリスナーを、前記リスナー登録リストから前記通知実行用リストに直ちに複写する請求項３記載のオブジェクト指向型車両用制御システム。
【請求項５】
インスタンスの異なる複数のイベントのそれぞれについて前記リスナー登録リストが個別に用意され、前記イベント処理オブジェクトは、前記イベントが発行された場合に、該イベントに対応するリスナー登録リストから前記リスナーを前記通知実行用リストに順次複写するものである請求項３又は請求項４に記載のオブジェクト指向型車両用制御システム。
【請求項６】
前記イベント処理オブジェクトは、発行された前記イベントに対応する前記リスナーを前記リスナー登録リストから前記通知実行用リストに複写するに伴い、当該リスナーを複写元となる前記リスナー登録リストから削除する請求項３ないし請求項５のいずれか１項に記載のオブジェクト指向型車両用制御システム。
【請求項７】
前記イベント処理オブジェクトは、予め定められたリスナーについて、発行された前記イベントに対応する前記リスナーを前記リスナー登録リストから前記通知実行用リストに複写するに伴い、当該リスナーを複写元となる前記リスナー登録リスト上に保持しつづける請求項３ないし請求項５のいずれか１項に記載のオブジェクト指向型車両用制御システム。
【請求項８】
前記イベント処理オブジェクトは、前記予め定められたリスナーのうち特定のものについて、他のオブジェクトからの削除依頼を受けた場合に当該リスナーを複写元となる前記リスナー登録リストから削除する請求項３ないし請求項５のいずれか１項に記載のオブジェクト指向型車両用制御システム。
【請求項９】
前記リスナー登録リストへ登録可能な全ての前記通知先候補オブジェクトが、前記リスナー登録リストとは別の補助リストに前記イベントの発行と無関係に静的に登録されてなり、
前記イベント処理オブジェクトは、前記リスナー登録リストに登録された前記リスナーが、前記補助リスト上のいずれかの通知先候補オブジェクトと一致する場合にのみ、該リスナーに対し発行された前記イベントの通知を実行する請求項１ないし請求項８のいずれか１項に記載のオブジェクト指向型車両用制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、オブジェクト指向型車両用制御システムに関する。
【背景技術】
【０００２】
【特許文献１】特開２００１−２７０３９９号公報
【０００３】
近年、自動車に搭載される電子機器の制御は、ＥＣＵと呼ばれるマイコン（ＭＰＵ）を含んだハードウェアユニットを用いて行なうのが主流となっている。特許文献１に例示するごとく、この制御を、オブジェクト指向により設計されたコンピュータシステム（以下、「オブジェクト指向システム」ともいう）により実現する方式も普及している（特許文献１）。オブジェクト指向システムの採用により、制御に関与する機器のハードウェア構成の相違を、ソフトウェアを構成するオブジェクトの内部に隠蔽することができ、制御対象毎に各制御プログラムの独立性を高めることができる。オブジェクト指向型のプログラミング言語としては、例えばＪａｖａ（登録商標）やＣ＋＋が知られ、いずれもオブジェクトを単位として、プログラムの記述を行なう。オブジェクトは自律性をもつ有機的なプログラムの単位であり、データと手続きを一体化した形で記述される。プログラム全体としての仕事は、オブジェクト間のメッセージ交換により進められる。メッセージを受信することにより起動される手続きはメソッドと呼ばれる。オブジェクトへの仕事の依頼は、メソッドを介してのみ行なうことができ、オブジェクト内のデータへの直接のアクセスは禁止される。
【０００４】
オブジェクト指向システムにおいては、各オブジェクトが、自身に組み込まれているメソッドを呼び出すメッセージを他のオブジェクトから受け、そのメソッドによる実行結果をメッセージ元へ返す形で処理が実行されてゆく。ここで、オブジェクトは、クラス（クラスオブジェクト）と、そのクラスを用いて作成されるインスタンス（インスタンスオブジェクト）とに大別できる。クラスには、データが格納される変数の定義や、機能処理を記述したメソッドなどが記述されている。クラスはオブジェクトのテンプレートに相当するものであり、汎用的なメソッドの集合と変数の定義を有するのみで、このままでは具体的な処理を直接実行することができない。そこで、実際の処理内容を規定するオブジェクトであるインスタンスが、クラスに含まれる変数に具体的な値を代入し、また、クラスに記述されているメソッドのうち、実際に使用するものへのリンクを張るためのポインタを記述する、等の手続を経て作成される。なお、インスタンスは、あくまでクラスをテンプレートとして新たに作成されるものであり、元のクラスが書き換えられるのではない。また、実際の処理は、対応するクラスから作成された個々のインスタンスがメッセージを受け取り、該対応するクラスのメソッドへ制御を受け渡たす形で進んでゆく。
【０００５】
次に、オブジェクト指向システムにおいては、イベントシステムと称される概念が確立されている。「イベント」は、制御処理に関与する特定のオブジェクトが、ある定められた処理状態となることを条件として、他のオブジェクトに対応する操作や処理を要求するために発行されるものであり、発行されたイベントを対応するオブジェクトが受け、前述の操作や処理を実行する。この場合、イベント発行側のオブジェクトには、そのイベントに対応する処理を行なうためのメソッド（イベントハンドラ）が組み込まれていなければならない。しかし、該メソッドは必ずしも当該のオブジェクト内に存在しているとは限らず、むしろ、他のクラスからの継承により実装しているケースの方が圧倒的に多い。この場合、イベント発行側のオブジェクトは、イベントハンドラが直接組み込まれている継承先のクラスが見つかるまで検索を行なうことになる。しかし、イベントの発行数が増大し、また、同種のイベントに関与するクラスの数や関連分岐が多くなるにつれ、イベント処理の全体把握が非常に困難になり、システムが複雑化して、エラーあるいは誤処理の発生リスクが高くなる問題がある。
【０００６】
そこで、これを解決するために、代理イベントモデルと称されるシステムが考案され、実用に供されている。代理イベントモデルの概念では、イベント処理のためにイベントリスナーという専用クラスがインターフェースとして用意され、これを、受け側のオブジェクトに組み込んで使用する。イベントリスナー内には、そのイベントで使用するイベントハンドラのメソッドが用意されており、受け側のオブジェクトに代行してイベント処理を待ち受ける。その結果、発行されたイベントは全て一旦イベントリスナーに送られ、そこでイベント処理が実行され、結果が受け側のオブジェクト（つまり、最終的なイベント通知先となるオブジェクト）に受け渡される。これにより、発行されたイベントの処理のため、何処に存在するかわからないイベントハンドラを求めて継承先のクラス（スーパークラス）を探し回る問題が回避される。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、イベント処理がイベントリスナーにクラス分離されることで、同種のイベントに対して、複数のインスタンス（アプリケーションプログラム）がイベントリスナーとなりうる場合、実際に通知を行なうイベントリスナーの特定や、その通知順あるいは通知タイミング処理に問題を生ずることがある。具体例を図１２に示す。
【０００８】
すなわち、イベントの発行元インスタンス１０１Ｊ（アプリケーションプログラム１：以下、アプリケーションプログラムのことを「アプリ」とも略記する）において、イベント通知先インスタンス１０２Ｊ〜１０２Ｌ（アプリ２〜アプリ４）にイベントクラス１０３のイベントリスナーが組み込まれているものとする。発行元インスタンス１０１Ｊにおいてイベント発生条件が成立し、イベントが発行されると、イベントクラス１０３のイベントリスナーを組み込んだインスタンスであるアプリ２〜アプリ４に自動的に順次受け渡す（通知）ことになる。
【０００９】
しかし、実際に欲する動作が、最初に発行されたイベントに対してはアプリ２にのみ通知を行い、そこからある時間遅れて同じイベントが再度発行されたときに、今度はアプリ３に対してのみ通知を行ないたい、といったような場合、図１２の方式では明らかに問題がある。つまり、最初のイベント発行でアプリ２だけでなくアプリ３（及びアプリ４）にも通知がなされ、本来望まれないタイミングであるにも拘わらずアプリ３（及びアプリ４）でイベントハンドラが動作して、システム全体としては誤動作につながってしまうのである。このような不具合を招く要因は、組み込まれたイベントリスナーにおいて、対象となるイベントの通知先（リスナー）が固定的（静的）に登録されており、登録されたリスナーに対して無条件にイベント通知を行なうようになっている点にある。
【００１０】
本発明の課題は、同種のイベントに対するリスナーの特定と、複数リスナーへの通知順序の制御を簡便かつ的確に行なうことができ、本来望まれないタイミングや意図しないリスナーに対してイベント通知がなされてしまう不具合を効果的に解消できるオブジェクト指向型車両用制御システムを提供することにある。
【課題を解決するための手段及び発明の効果】
【００１１】
本発明のオブジェクト指向型車両用制御システムは、ＣＰＵを含んで構成され、車載用電子機器をＣＰＵにより、オブジェクト指向のプログラム処理により動作制御する制御主体を有した車両用制御装置であって、上記の課題を解決するために該プログラムが、
イベント生成オブジェクトが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行するイベント管理オブジェクトと、
イベントの通知先候補オブジェクトからイベント通知要求を受け付けるイベント通知要求受付オブジェクトと、
イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、リスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行されたイベントの通知を行なうイベント処理オブジェクトと、
を備えてなることを特徴とする。
【００１２】
上記構成によると、イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクトをリスナーとして、リスナー登録リストにその都度動的に登録するとともに、該リスナー登録リストに登録されているリスナーに対してのみ、発行されたイベントの通知が行なわれる。すなわち、リスナー登録リストを参照することにより、通知を欲する申し出（イベント通知要求）を行なった通知先候補オブジェクトにのみ、選択的にイベント通知を行なうことが可能となるので、同じイベントに対して通知先候補オブジェクトが複数存在している場合においても、意図しない通知先候補オブジェクトにまで無作為にイベント通知がなされてしまう不具合を効果的に解消できる。
【００１３】
イベント処理オブジェクトは、リスナー登録リストの登録内容を監視するとともに、イベント管理オブジェクトからの当該イベントの発行タイミングと、イベント通知要求受付オブジェクトによる通知先候補オブジェクトからのイベント通知要求の受け付けタイミングとに基づいてイベントの通知タイミングを決定し、リスナー登録リスト上の対応するリスナーに通知を行なうものとすることができる。つまり、固定的なリスナーリストにのみ頼った従来のイベント通知方式では、その通知タイミングがイベント発行タイミングにより一律に支配されてしまい、的確なタイミングでイベントを通知できない要因となっていた。しかし、本発明では、受け側となる通知先候補オブジェクトが自立的にイベント通知要求を出し、リスナーとして動的登録されるので、上記の方式により、通知先候補オブジェクトがイベント通知要求を出したタイミングも考慮して、どの通知先候補オブジェクトにいつイベントを通知するかを的確に把握でき、本来望まれないタイミングでイベント通知がなされてしまう不具合を効果的に解消できる。
【００１４】
イベント処理オブジェクトは、イベント管理オブジェクトが発行したイベントに対応するリスナーを、リスナー登録リストから該リスナー登録リストとは別に用意された通知実行用リストに複写し、当該通知実行用リスト上で通知実行対象となるリスナーを検索するように構築できる。そして、検索されたリスナーに対し、発行されたイベントの通知を順次実行するとともに、通知が完了したイベントに対応するリスナーを通知実行用リストから削除するものとできる。
【００１５】
このようにすると、イベント発行中に新たに登録されるリスナーは、通知実行用リスト上のリスナーに対するイベント通知が完了するまでリスナー登録リスト上に保留され、本来通知を受けるべきタイミングで次のイベントが発行されて、はじめて通知実行用リストに移ってイベント通知を受けることができるので、矛盾のないタイミングでのイベント通知が可能となる。
【００１６】
次に、本発明においては、リスナー登録リストへ登録可能な全ての通知先候補オブジェクトを、リスナー登録リストとは別の補助リストにイベントの発行と無関係に静的に登録しておくことが可能である。この場合、イベント処理オブジェクトは、リスナー登録リストに登録されたリスナーが、補助リスト上のいずれかの通知先候補オブジェクトと一致する場合にのみ、該リスナーに対し発行されたイベントの通知を実行するものとして構築する。リスナー登録リストへのリスナーの登録は、上記のごとく、通知要求が発生するたびに動的に実施されるので、リスナー登録リスト自体は書換え可能なメモリ（ＥＥＰＲＯＭやフラッシュメモリも概念的には利用可能であるが、書換え速度が遅いのでＲＡＭであることが望ましい）上に作成する必要がある。上記のように構成すると、リスナー登録リストが書き込まれるメモリの記憶内容がバグや暴走等により破壊された場合も、固定的な補助リストを併用することで、イベント通知先のリスナーが正規のものであるか否かを容易に確認することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施の形態を、図面を参照して説明する。
図１は、本発明のオブジェクト指向型車両用制御システムにおける制御主体４０の構成を、オブジェクト指向プラットフォームの観点から概念的に示す図である。本実施形態では、制御主体４０は、Ｊａｖａで記述されたプログラムに基づく情報処理を実行する演算処理装置として構成されている。プログラム実行装置１は、Ｊａｖａによるバイトコードを実行する回路が組み込まれたＣＰＵであり、プログラム実行部３、メソッド検索部４、メモリコントローラ５などを具備する。メモリ２は、ＲＯＭまたはＲＡＭ、あるいは両者を包括した記憶領域を示しており、プログラムデータ領域６や検索用テーブル領域７などの記憶領域が設定される（なお、図１では、プログラム実行装置１を便宜上単一のＣＰＵとして扱っているが、構成はこれに限られるものではなく、例えば、ＣＡＮ（Controller Area Network）等の車載ネットワークにより接続されたＣＰＵ群であってもよい）。
【００１８】
前記プログラムデータ領域６には、Ｊａｖａのソースプログラムよりコンパイルされたバイトコードのプログラムが格納される（以下、１アドレス分のプログラムを「プログラムデータ」という）。検索用テーブル領域７には、メソッドの呼出し時に、呼び出されたメソッドが格納されている場所を検索するために、図示しないクラステーブルやメソッドテーブルなどが格納される。
【００１９】
プログラム実行装置１におけるメモリアクセスは、メモリコントローラ５により制御される。プログラム実行部３は、メモリコントローラ５に、読み出すべきプログラムデータの格納先を示すプログラムアドレスを与えることにより、前記プログラムデータ領域６から該当するプログラムデータを得て実行する。特にそのプログラムデータがメソッド呼出しを示すメッセージであったとき、プログラム実行部３は、そのメッセージをメソッド検索部４に送信して、メソッドの格納先の検索を要請する。
【００２０】
メッセージには、メッセージの対象となるオブジェクトの所属するクラス名、実行すべきメソッドのメソッド名、引数、戻り値の有無やその型を示すデータが含まれる。メソッド検索部４は、このメッセージにより、メッセージの対象となるオブジェクトが所属するクラスや指定されたメソッドを認識した後、前記検索用テーブルを用いてメソッドの格納場所を検索する。この検索処理は、メモリコントローラ５に、検索用テーブル領域７内で必要な検索用情報の格納先のアドレス（図中、「テーブルアドレス」と示す）を指定して情報の読出しを行なわせることにより実現する。なおテーブルアドレスは、各検索用テーブルのエントリ位置を示すポインタ、またはメモリ２において前記エントリ位置に該当する領域のアドレスを示す値により与えられる。
【００２１】
メソッド検索部４は、検索結果として、指定されたメソッドの格納場所の先頭アドレス（以下「プログラム先頭アドレス」という）を取得し、このプログラム先頭アドレスを、プログラムカウンタとしてプログラム実行部３に送信する。プログラム実行部３は、図示しないスタック用のメモリ領域に前記メソッドのための作業領域を設定するとともに、前記プログラムカウンタが示すアドレスを起点としてプログラムデータ領域６から前記メソッドを構成する各プログラムデータを順次読み出して、各プログラムデータに応じた処理を実行する。
【００２２】
制御主体４０の実行プログラムは、上記オブジェクト指向プラットフォーム上に構築されるものである。図２は、そのプログラムの構成を示すＵＭＬ（Unified Modeling Language）表記に従ったクラス図である。該プログラムは、次のようなオブジェクトによって構成されている。
・イベント管理オブジェクト１０１Ｃ：イベント生成オブジェクト１０１Ｊが予め定められた実行状態となった場合に生成するイベントを取得して、これを現在有効なイベントとして発行する。
・イベント通知要求受付オブジェクト１０２Ｃ：イベントの通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌからイベント通知要求を受け付ける。
・イベント処理オブジェクト１０３Ｃ：イベント通知要求が受け付けられる毎に、当該イベント通知要求を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌをリスナーとして、リスナー登録リスト２０１にその都度動的に登録するとともに、該リスナー登録リスト２０１に登録されているリスナーに対してのみ、発行されたイベントの通知を行なう。
【００２３】
イベント管理オブジェクト１０１Ｃは、イベント発生元となるアプリケーションプログラム（図２では、アプリ１を表示）に対応したインスタンスオブジェクトをイベント生成オブジェクト１０１Ｊとして作成可能なクラスオブジェクトである。アプリケーションプログラム側にてイベントが生成されるに伴い、当該インスタンスオブジェクトを作成するとともに生成した該イベントを発行して、イベント処理オブジェクト１０３Ｃに受け渡すよう動作する。
【００２４】
イベント通知要求受付オブジェクト１０２Ｃは、イベント通知先となるアプリケーションプログラムに対応したインスタンスオブジェクトを通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌとして作成可能であり、かつ、通知対象となるイベントに対応したイベントリスナークラス１０４Ｉをインターフェースとして実装したクラスオブジェクトである。そして、該イベントリスナークラス１０４Ｉに呼び出された通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌがリスナーとして、イベント処理オブジェクト１０３Ｃのリスナー登録リスト２０１（及び、後述の通知実行用リスト２０２と補助リスト２０３）に組み込まれている。なお、図２では、リスナー登録リスト２０１を「動的に登録されたリスナーリスト」、通知実行用リスト２０２を「イベント発行中のリスナーリスト」と、及び補助リスト２０３を「静的に登録されているリスナーリスト」と表記している。
【００２５】
そして、イベント処理オブジェクト１０３Ｃは、リスナー登録リスト２０１の登録内容を監視するとともに、イベント管理オブジェクト１０１Ｃからの当該イベントの発行タイミングと、イベント通知要求受付オブジェクト１０２Ｃによる通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌからのイベント通知要求の受け付けタイミングとに基づいてイベントの通知タイミングを決定し、リスナー登録リスト２０１上の対応するリスナーに通知を行なう。
【００２６】
図３は、図１のクラス図に対応するシーケンス図である。すなわち、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌは、そのどれかがイベント通知要求を行なうたびに、イベント通知を受けるリスナーとして、図４のリスナー登録リスト２０１にその都度動的に登録される。そして、該リスナー登録リスト２０１に登録されているリスナーに対してのみ、発行されたイベントの通知が行なわれる。すなわち、リスナー登録リスト２０１を参照することにより、通知を欲する申し出（イベント通知要求）を行なった通知先候補オブジェクトにのみ、選択的にイベント通知を行なうことが可能となる。その結果、同じイベントに対して通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが複数存在している場合においても、受け側となる通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが自立的にイベント通知要求を出し、その都度リスナーとして動的登録され、登録されているリスナーについてのみイベント通知がなされる。従って。図１２のように、意図しない通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌにまで無作為にイベント通知がなされてしまう不具合が生じず、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌ毎に適正なタイミングでイベント通知が可能となる。この場合、１つの通知に付き、その都度個別にイベントを発行する形となる。
【００２７】
図４は、リスナー登録リスト２０１を概念的に示すものである。リスナー登録リスト２０１は常時新しいリスナーの登録を受け付け可能な状態になっており、あるイベントの発行中に、同じイベントに対するリスナーが追加登録されることがある。このリスナーは、発行中のイベントに関与するリスナーと同じであってもよいし、異なるリスナーであってもよい。前者の場合は、発行中のイベントの通知がなされた後、同種のイベントが次回に発行されたときも同じリスナーに通知されることになるし、後者の場合は、次回に発行されるイベントが別のリスナーに通知される形になる。いずれにしろ、登録されるリスナーは、イベントの種別毎に通知要求のあった時系列順に順次登録され、先頭のものから順に対応するイベントの通知を受けることになる。
【００２８】
ここで、リスナー登録リスト２０１上でリスナーを直接サーチしてイベント通知を実行する処理とした場合、あるイベントの発行途中に、そのイベントに対する新たなリスナーが追加されると、後で追加されたリスナーに対して、次回以降のイベントループ周期で本来通知したかったイベントが、現在発行中のイベントをカバーするイベントループのサーチ周期に偶然引っかかってしまい、望みのタイミングよりも早くイベント通知されてしまう不具合を生じうる。
【００２９】
これを解決するために、本実施形態では、次のような方式が採用されている。すなわち、イベント処理オブジェクト１０３Ｃにおいて、図４に示すように、イベント管理オブジェクト１０１Ｃが発行したイベントに対応するリスナーを、リスナー登録リスト２０１から該リスナー登録リスト２０１とは別に用意された通知実行用リスト２０２に複写し、当該通知実行用リスト２０２上で通知実行対象となるリスナーを検索するようにする。そして、検索されたリスナーに対し、発行されたイベントの通知を順次実行する。なお、通知が完了したイベントに対応するリスナーは通知実行用リスト２０２から削除される。
【００３０】
あるイベントの発行中に、他のイベントに対するイベント通知要求がなされた場合、当該イベント通知要求を行なった通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌ（アプリ２〜アプリ４）がリスナーとしてリスナー登録リスト２０１に登録されるとともに、該リスナーは、対応するイベントの発行がなされるまでリスナー登録リスト２０１上に保持されることになる。イベント発行中に新たに登録されるリスナーは、通知実行用リスト２０２上のリスナーに対するイベント通知が完了するまで、リスナー登録リスト２０１上に保留され、本来通知を受けるべきタイミングで次のイベントが発行されると、はじめて通知実行用リスト２０２に移ってイベント通知を受けることができる。これにより、上記のような不具合が解消される。なお、イベント通知タイミングの精度を向上するため、イベント処理オブジェクト１０３Ｃにおいては、イベント管理オブジェクト１０１Ｃがイベントを発行するに伴い、該イベントに対応するリスナーを、リスナー登録リスト２０１から通知実行用リスト２０２に直ちに複写するようになっている（図２からも明らかな通り、各リスト２０１〜２０３は、リスナー登録数が０以上であって上限を設けない形で定義されている（0..*））。
【００３１】
なお、インスタンス（種別）の異なるイベントが順次発行される場合でも、対応するリスナーへスムーズにイベント通知を行なうことができるようにするために、図４に示すように、インスタンスの異なる複数のイベント（α、β、γ‥）のそれぞれについてリスナー登録リスト２０１は個別に用意されている。イベント処理オブジェクト１０３Ｃは、イベントが発行された場合に、該イベントに対応するリスナー登録リスト２０１からリスナーを通知実行用リスト２０２に順次複写する。
【００３２】
図４においては、イベントβに対し、アプリ２から通知要求が出された場合を例示している。リスナー登録リスト２０１のイベントβの割当領域には、アプリ２（番号「２」で識別している）がリスナーとして既に登録されている。そして、イベントβが実際に発行されると、リスナー登録リスト２０１のリスナーであるアプリ２を、通知実行用リスト２０２に複写する（Ｔ１）。そして、その通知実行用リスト２０２をサーチすることで、その複写された「アプリ２」が検索され、イベントβが通知される（Ｔ２）。
【００３３】
なお、通知が完了したイベントに対応するリスナーは、通知実行用リスト２０２からは必ず削除（あるいは無効化）する必要がある（そうでなければ、発行されたイベントに通知が重複して実行されることにつながる）。また、リスナー登録リスト２０１上のリスナーの扱いについても、リスナーの登録タイミングがイベント通知のタイミング支配要因の一つとなっているので、基本的には、イベント処理オブジェクト１０３Ｃは、発行されたイベントに対応するリスナーをリスナー登録リスト２０１から通知実行用リスト２０２に複写するに伴い、当該リスナーを複写元となるリスナー登録リスト２０１から削除するように構成しておく必要がある。
【００３４】
しかし、あるイベントの同じリスナーへの通知頻度が高い場合については、その特定のリスナーを必要な期間だけ（あるいは永続的に）リスナー登録リスト２０１上に留保できるようにしたほうが、通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌがいちいち通知要求を出す必要がなくなるので、便利なことがある。この場合、イベント処理オブジェクト１０３Ｃは、予め定められたリスナーについて、発行されたイベントに対応するリスナーをリスナー登録リスト２０１から通知実行用リスト２０２に複写するに伴い、当該リスナーを複写元となるリスナー登録リスト２０１上に保持しつづけるものとして構築される。リスナー登録リスト２０１上でのリスナー登録状態の保持は、一部の特定のリスナーについては永続的に設定することもできるが、期間限定的に保持を行ないたい場合は、イベント処理オブジェクト１０３Ｃは、予め定められたリスナーのうち特定のものについて、他のオブジェクトからの削除依頼を受けた場合に当該リスナーを複写元となるリスナー登録リスト２０１から削除するものとして構築すればよい。いずれにしろ、リスナー登録リスト２０１上に保持され続けるリスナーについては、イベントの通知タイミングは、該イベントの発行タイミングに支配されることになる。
【００３５】
次に、本実施形態では、リスナー登録リスト２０１へ登録可能な全ての通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌが、リスナー登録リスト２０１とは別の補助リスト２０３にイベントの発行と無関係に静的（固定的）に登録されている。イベント処理オブジェクト１０３Ｃは、リスナー登録リスト２０１に登録されたリスナーが、補助リスト２０３上のいずれかの通知先候補オブジェクト１０２Ｊ，１０２Ｋ，１０２Ｌと一致する場合にのみ、該リスナーに対し発行されたイベントの通知を実行する。リスナー登録リスト２０１へのリスナーの登録は、上記のごとく、通知要求が発生するたびに動的に実施されるので、リスナー登録リスト２０１自体は書換え可能なメモリ上に作成する必要がある。このメモリは、具体的には図１のメモリ２であり、ＲＡＭで構成されるが、バグや暴走等により記憶内容が失われるリスクは常に存在する。しかし、上記のように、固定的な補助リスト２０３を併用することで、リスナー登録リスト２０１が書き込まれるメモリの記憶内容がバグや暴走等により破壊された場合も、イベント通知先のリスナーが正規のものであるか否かを容易に確認することができる。
【００３６】
以下、上記の実施形態を、さらに車載用のセキュリティシステムに適用・展開した事例について説明する。図５は、オブジェクト指向型車両用制御システムの一具体化例であるセキュリティシステム１００の、概略ハードウェア構成を示すブロック図である。セキュリティシステム１００は、マイコン制御される侵入検知装置４２と、該侵入検知装置４２からの検知情報を受け、アラームを動作させたり、監視カメラによる車内画像撮影等のセキュリティ処理をマイコン制御により実行するセキュリティ制御部４１とが通信ネットワークにより接続されたシステムとして構成されている（以下、「セキュリティシステム４０」とも記載する）。また、セキュリティ制御部４１はユーザーが所持する携帯電話や、外部の警備センターなどと無線通信可能とされており、異常発生した場合の報知情報や、撮影画像等を無線送信することができる。
【００３７】
図６に示すごとく、ユーザーが携帯電話４３でセキュリティ制御部４１に電話をかけ、セキュリティセットを指令した場合を考える。セキュリティ制御部４１が侵入検知装置４２にセキュリティセットを指示し、そのセット完了のステータスを侵入検知装置４２から受け、これをユーザー（の携帯電話４３）にセット完了通知する動作を第一動作とする。また、セキュリティセット状態の侵入検知装置４２が車両への侵入を検知し、これをユーザー（の携帯電話４３）にアラーム通知する第２動作とする。イベント発行元となるアプリ１と、セキュリティ制御部４１に実装され、その通知先候補となるアプリ２（及び３，４）が侵入検知装置４２に実装されているものとする。
【００３８】
図１２の従来例に対応するパターンとして、第一動作では、セット完了のステータスを侵入検知装置４２から受けることを条件として「通知完了」を返すイベントが発行されるものとし、そして、第二動作では、侵入検知を侵入検知装置４２から受けることを条件として「通知完了」を返すイベントが発行されるものとする。また、リスナーはアプリ２（及び３，４）に固定的に登録されているのみとする。
【００３９】
セキュリティセットが完了して、十分な時間をおいて侵入検知がなされ、かつ、ユーザーの携帯電話４３への通知もいずれもうまくいった場合は、図６に示すように、イベントリスナーは矛盾なく動作し、いずれのイベント通知（セット完了あるいは侵入検知通知完了）も適正なタイミングでなされていることがわかる。
【００４０】
ところが、ユーザーの携帯電話４３は、電源が切れていたり、話中であったり、あるいは電波の届かない場所にあった場合は無線接続不可であるから、これを用いたユーザーへの通知が失敗することがある。また、ユーザーが携帯電話４３によりセキュリティセットした時点で、既に車両に賊が侵入していることもありえる。すると、図７に示すような不具合動作を生ずる。
【００４１】
つまり、侵入検知装置４２は、セキュリティセットされた時点で既に侵入検知も能動化されている状態にあるので、第一動作でのイベント通知は矛盾なく実行されるのに対し、そのあと切れ目なく侵入検知通知が侵入検知装置４２から返ってくることになる。このとき、ユーザーの携帯電話４３は、セキュリティセットのために車両側と電話がつながっている状態にあるから、車両側から侵入報知のためにユーザーに電話をかけようとしても「つながらない」状態となり、通知に失敗することになる。しかし、上記のイベントリスナーは、侵入検知を侵入検知装置４２から受ければ、直ちに「通知完了」のイベント通知を行なってしまうので、ユーザーへの通知が実際には失敗していることと矛盾する。
【００４２】
しかし、上記本実施形態の方式を採用することで、この問題は以下のように解消される（図９は、オブジェクト間の情報の流れを示し、図８は、イベント通知処理全体にかかるセキュリティ制御部４１内の処理の流れを示す）。図９に示すごとく、侵入検知装置４２側のアプリ２（３，４）側では、侵入検知するとイベント通知要求を行い（図８：Ｓ１）、リスナーとして動的に登録される（図９：応答先設定（ｂ）／図８：Ｓ２）。一方、イベント管理オブジェクト１０１Ｃでは、ユーザーへの通知処理を行い（図９：（ｃ）／図８：Ｓ３）、この通知が正常に完了した場合に限りイベントを有効化し、これをイベント処理オブジェクト１０３Ｃに発行する（図９：（ｅ）／図８：Ｓ４→Ｓ５）。
【００４３】
図１０に示すように、イベント処理オブジェクト１０３Ｃでは、前述のごとく、発行されたイベントに対応するリスナーを、リスナー登録リスト２０１から通知実行用リスト２０２に複写し、さらに、その通知実行用リスト２０２に複写されたリスナーが、補助リスト２０３に固定的に登録されているリスナーのどれかと一致した場合に、はじめて完了通知（イベント通知）を侵入検知装置４２に返す（図９：（ｆ）／図８：Ｓ６）。
【００４４】
その結果を示すシーケンス図が図１１である。つまり、前述のごとく、ユーザー側の携帯電話４３がセキュリティセットのために通話中の間は、ユーザー通知が失敗するが、この場合は、イベントが発行されないので、完了通知（イベント通知）が侵入検知装置４２に返っていない。侵入検知装置４２はイベント通知を受け取れないので、やむなく侵入検知通知の再送を行なう。このとき、ユーザーの携帯電話４３が通話終了し、呼び待ちの状態になっていれば、今度はユーザー通知が成功するので、ここではじめて通知完了を返すイベントが発行され、矛盾のない処理が実現する。
【図面の簡単な説明】
【００４５】
【図１】本発明のオブジェクト指向型車両用制御システムにおける制御主体の構成を、オブジェクト指向プラットフォームの観点から概念的に示す図。
【図２】図１の制御主体が実行するプログラムの構成を示すＵＭＬ表記に従ったクラス図。
【図３】図１のクラス図に対応するシーケンス図。
【図４】リスナー登録リストをその使用方法とともに概念的に示す図。
【図５】オブジェクト指向型車両用制御システムの一具体化例であるセキュリティシステムの、概略ハードウェア構成を示すブロック図。
【図６】従来のセキュリティシステムにおける正常時の動作を示すシーケンス図。
【図７】同じく不具合時の動作を示すシーケンス図。
【図８】イベント通知処理全体にかかるセキュリティ制御部内の処理の流れを示すフローチャート。
【図９】図８に対応するオブジェクト間の情報の流れを示す概念ブロック図。
【図１０】図９のイベント処理部の詳細を示す概念ブロック図。
【図１１】図８に対応するシーケンス図。
【図１２】従来のシステムの問題点を示す図。
【符号の説明】
【００４６】
１  プログラム実行装置（ＣＰＵ）
４０  制御主体  
１０１Ｃ  イベント管理オブジェクト
１０１Ｊ  イベント生成オブジェクト
１０２Ｃ  イベント通知要求受付オブジェクト
１０２Ｊ，１０２Ｋ，１０２Ｌ  通知先候補オブジェクト
１０３Ｃ  イベント処理オブジェクト
２０１  リスナー登録リスト
２０２  通知実行用リスト
２０３  補助リスト
【図１】
2008077219.tif 000003
【図２】
2008077219.tif 000004
【図３】
2008077219.tif 000005
【図４】
2008077219.tif 000006
【図５】
2008077219.tif 000007
【図６】
2008077219.tif 000008
【図７】
2008077219.tif 000009
【図８】
2008077219.tif 000010
【図９】
2008077219.tif 000011
【図１０】
2008077219.tif 000012
【図１１】
2008077219.tif 000013
【図１２】
2008077219.tif 000014