(57)【要約】  【課題】プログラムコンポーネントそれぞれの処理負荷及び通信負荷を小さくすると共に、プログラムコンポーネントの異常時におけるエラー処理を早期に実現する。  【解決手段】利用側コンポーネント２０は、実施依頼メッセージにて提供側コンポーネント３０に処理の実施を依頼した後（ａ）、これを受け付けた提供側コンポーネント３０から受付通知メッセージを受けることで（ｃ）、その依頼が正常に受け付けられたことを認識できる。受付通知メッセージは、処理が登録されれば、その処理を実施するタイミングに拘わらず送信されるため、提供側コンポーネント３０が依頼を正常に受け付けられない状態であることを認識するために、処理の登録が行われるまでの短時間だけ待機すればよい。こうして、提供側コンポーネント３０の処理負荷の大きさに起因する遅延が発生していた場合に再度の依頼及び処理の実施に必要なデータの送信をしないようにできる。【選択図】図２
2009252103.tif 000002
【特許請求の範囲】
【請求項１】
他のプログラムコンポーネントに対してサービスを提供するプログラムコンポーネント（以降、提供側コンポーネントという）と、該提供側コンポーネントから提供されるサービスを利用するプログラムコンポーネント（以降、利用側コンポーネントという）とを含む２種類以上のプログラムコンポーネントを、それぞれ１以上の処理装置のいずれかに実装してなる処理システムであって、
前記利用側コンポーネントは、
特定処理の実施およびその実施結果の通知を依頼するための実施依頼メッセージを、その特定処理を実施可能なプログラムコンポーネントに対して送信する実施依頼手順と、
前記実施依頼メッセージを受信したプログラムコンポーネントから、該実施依頼メッセージに係る処理の実施を受け付けた旨を通知するための受付通知メッセージを受信した以降、同プログラムコンポーネントから、その処理の実施を開始することを通知するための実施開始メッセージを受信した際に、同プログラムコンポーネントに対して、その処理の実施を開始すべき旨を指令するための開始指令メッセージを送信する開始送信手順とを、
当該利用側コンポーネントを実装した処理装置に実行させるためのものであって、
前記提供側コンポーネントは、
他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントに対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録する処理登録手順と、
該処理登録手順にて処理を登録する際、該登録の契機となった前記実施依頼メッセージを送信してきたプログラムコンポーネントに対して、その処理の実施を受け付けた旨を通知するための受付通知メッセージを送信する受付通知手順と、
前記処理登録手順にて登録した処理それぞれを所定の順番で実施する処理実施手順と、
該処理実施手順にて実施された処理の実施結果を、該処理に対応づけて前記処理登録手順で登録したプログラムコンポーネントに対して通知する結果通知手順と、
前記処理実施手順による処理の実施に先立ち、該処理に対応づけて前記処理登録手順で登録したプログラムコンポーネントに対して、その処理の実施を開始することを通知するための実施開始メッセージを送信する開始通知手順とを、
当該提供側コンポーネントを実装した処理装置に実行させるためのものであって、
前記開始通知手順にて実施開始メッセージを送信した以降、該送信先のプログラムコンポーネントから前記開始指令メッセージを受信した際に、前記処理実行手順により、その開始指令メッセージで指令された処理の実施を開始するように構成されている
ことを特徴とする処理システム。
【請求項２】
前記利用側コンポーネントは、
前記実施依頼メッセージとして、特定処理の実施およびその実施結果の通知だけでなく、その実施または通知を所定時期までに行うべき旨を依頼するためのメッセージを、前記実施依頼手順により送信するように構成されており、
前記提供側コンポーネントは、
他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理の実施または実施結果の通知が、その依頼に係る時期までに行うことができるか否かを、前記処理登録手順で登録した処理に基づいて判定する可否判定手順を、
さらに当該提供側コンポーネントを実装した処理装置に実行させるためのものであって、
前記可否判定手順にて処理の実施または実施結果の通知を依頼に係る時期までに行うことができると判定した場合に、前記処理登録手順により、その判定の契機となった前記実行依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントに対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録するように構成されている
ことを特徴とする請求項１に記載の処理システム。
【請求項３】
前記提供側コンポーネントは、
他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理を実施または実施結果を通知できる時期を、前記処理登録手順で登録した処理に基づいて特定する時期特定手順を、
さらに当該提供側コンポーネントを実装した処理装置に実行させるためのものであって、
前記時期特定手順による特定の契機となった前記実施依頼メッセージを送信してきたプログラムコンポーネントに対して、処理の実施を受け付けた旨と共に、その特定された時期を通知するためのメッセージを、前記受付通知手順により、前記受付通知メッセージとして送信するように構成されている
ことを特徴とする請求項１または請求項２に記載の処理システム。
【請求項４】
前記提供側コンポーネントは、
前記処理登録手順により、複数の処理を登録可能なバッファに前記実施依頼メッセージにて依頼された処理を登録するように構成されている
ことを特徴とする請求項１から３のいずれかに記載の処理システム。
【請求項５】
前記提供側コンポーネントは、
前記処理登録手段により、前記実施依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントまたはその処理の内容に応じて定められた優先度を対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録して、
前記処理登録手段により登録された処理それぞれを、前記処理実施手順により、該処理に対応づけられた優先度の高い順番で実施するように構成されている
ことを特徴とする請求項１から４のいずれかに記載の処理システム。
【請求項６】
前記利用側コンポーネントは、
前記実施依頼手順にて実施依頼メッセージを送信した以降、該送信先のプログラムコンポーネントから前記実行開始メッセージを受信した際に、当該利用側コンポーネントまたは当該処理システムの動作状態に基づいて、その実施開始メッセージに係る処理を実施すべきか否かを判定する実施判定手順を、
さらに当該利用側コンポーネントを実装した処理装置に実行させるためのものであって、
該実施判定手順にて処理を実施すべきと判定した場合に、その判定の契機となった実施開始メッセージを送信してきたプログラムコンポーネントに対して、前記開始送信手順により、その処理の実施を開始すべき旨を指令するための開始指令メッセージを送信するように構成されている
ことを特徴とする請求項１から５のいずれかに記載の処理システム。
【請求項７】
請求項１から６のいずれかに記載の利用側コンポーネントおよび提供側コンポーネントのいずれか一方または両方を実装してなる処理装置。
【請求項８】
請求項１から６のいずれかに記載の利用側コンポーネントにおける全ての手順をコンピュータシステムに実行させるためのプログラム。
【請求項９】
請求項１から６のいずれかに記載の提供側コンポーネントにおける全ての手順をコンピュータシステムに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２種類以上のプログラムコンポーネントを、それぞれ１以上の処理装置のいずれかに実装してなる処理システムに関する。
【背景技術】
【０００２】
このような処理システムにおいては、いずれかのプログラムコンポーネント（クライアントにおける要求プログラム）が、他のプログラムコンポーネントに対して処理の実施を依頼するに際し、その依頼のためのメッセージだけでなく、その処理の実施に必要なデータを合わせて送信することが一般的である（例えば、特許文献１参照）。
【特許文献１】特開２０００−１３４４２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
通常、依頼元のプログラムコンポーネントは、依頼をしてから所定時間以内に実施結果が通知されてこない場合に、再度の依頼をするように構成されている。
ただ、依頼元のプログラムコンポーネントは、依頼先のプログラムコンポーネント側でその依頼が正常に受け付けられたことを認識できないため、依頼先のプログラムコンポーネントにおいて処理負荷に応じた遅延が発生している状況であっても、所定時間の経過をもって再度の依頼をしてしまうこととなる。
【０００４】
この場合、再度の依頼に際しても、処理の実施に必要なデータを合わせて送信することになるため、先の依頼に際して送信されたデータや、このデータに基づいて実施された処理が無駄なものとなってしまう結果、プログラムコンポーネントそれぞれの処理負荷および通信負荷を無用に大きくしてしまう恐れがある。
【０００５】
また、プログラムコンポーネントは、依頼先のプログラムコンポーネントがその依頼を正常に受け付けられない状態であったとしても、そのことを認識するために、少なくとも依頼から実施結果の通知までに要すると想定される時間だけ待機しなければならず、そのような異常に対応するためのエラー処理（代替処理）を実行するまでに長時間を要してしまう。
【０００６】
このように、従来の構成では、プログラムコンポーネントそれぞれの処理負荷および通信負荷が無用に大きくなり、また、依頼先となるプログラムコンポーネントの異常に対応するためのエラー処理を早期に実行できないという問題があった。
【０００７】
本願発明は、このような課題を解決するためになされたものであり、その目的は、プログラムコンポーネントそれぞれの処理負荷および通信負荷を小さくすると共に、プログラムコンポーネントの異常時におけるエラー処理を早期に実現できるようにするための技術を提供することである。
【課題を解決するための手段】
【０００８】
上記課題を解決するためには、他のプログラムコンポーネントに対してサービスを提供するプログラムコンポーネント（以降、提供側コンポーネントという）と、該提供側コンポーネントから提供されるサービスを利用するプログラムコンポーネント（以降、利用側コンポーネントという）とを含む２種類以上のプログラムコンポーネントを、それぞれ１以上の処理装置のいずれかに実装してなる処理システムについて、以下に示す第１の構成（請求項１）とすることが考えられる。
【０００９】
この構成において、前記利用側コンポーネントは、特定処理の実施およびその実施結果の通知を依頼するための実施依頼メッセージを、その特定処理を実施可能なプログラムコンポーネントに対して送信する実施依頼手順と、前記実施依頼メッセージを受信したプログラムコンポーネントから、該実施依頼メッセージに係る処理の実施を受け付けた旨を通知するための受付通知メッセージを受信した以降、同プログラムコンポーネントから、その処理の実施を開始することを通知するための実施開始メッセージを受信した際に、同プログラムコンポーネントに対して、その処理の実施を開始すべき旨を指令するための開始指令メッセージを送信する開始送信手順とを、当該利用側コンポーネントを実装した処理装置に実行させるためのものである。
【００１０】
そして、開始送信手順にて開始指令メッセージを送信した以降、該送信先のプログラムコンポーネントから、該開始指令メッセージにて開始すべき旨を指令した処理の実施結果を受け、該実施結果に基づく別の処理を、当該利用側コンポーネントを実装した処理装置に実行させるように構成されている。
【００１１】
また、前記提供側コンポーネントは、他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントに対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録する処理登録手順と、該処理登録手順にて処理を登録する際、該登録の契機となった前記実施依頼メッセージを送信してきたプログラムコンポーネントに対して、その処理の実施を受け付けた旨を通知するための受付通知メッセージを送信する受付通知手順と、前記処理登録手順にて登録した処理それぞれを所定の順番で実施する処理実施手順と、該処理実施手順にて実施された処理の実施結果を、該処理に対応づけて前記処理登録手順で登録したプログラムコンポーネントに対して通知する結果通知手順と、前記処理実施手順による処理の実施に先立ち、該処理に対応づけて前記処理登録手順で登録したプログラムコンポーネントに対して、その処理の実施を開始することを通知するための実施開始メッセージを送信する開始通知手順とを、当該提供側コンポーネントを実装した処理装置に実行させるためのものである。
【００１２】
そして、前記開始通知手順にて実施開始メッセージを送信した以降、該送信先のプログラムコンポーネントから前記開始指令メッセージを受信した際に、前記処理実行手順により、その開始指令メッセージで指令された処理の実施を開始するように構成されている。
【００１３】
このように構成された処理システムにおいて、利用側コンポーネントは、実施依頼メッセージを送信することで提供側コンポーネントに処理の実施を依頼した後、この依頼を受け付けた提供側コンポーネントからの受付通知メッセージを受信する。
【００１４】
これにより、利用側コンポーネントは、依頼先のプログラムコンポーネント側でその依頼が正常に受け付けられたことを認識できるため、その後、提供側コンポーネントにおける処理負荷の大きさに起因する遅延が発生して長期間が経過したとしても、再度の依頼（実施依頼手順による実施依頼メッセージの送信）および処理の実施に必要なデータの送信をしないようにすることができる。
【００１５】
これにより、不必要な再度の依頼およびデータの送信をしてしまうことがなくなるため、こうして送信されるデータや、このデータに基づいて実施される処理が無駄なものとなってしまうこともなくなる結果、プログラムコンポーネントそれぞれの処理負荷および通信負荷を小さくすることができる。
【００１６】
また、提供側コンポーネントが利用側コンポーネントに送信する受付通知メッセージは、提供側コンポーネントが処理の登録を行うときであれば、その処理を実際に実施するタイミングに拘わらず送信される。そのため、利用側コンポーネントは、提供側コンポーネントが依頼を正常に受け付けられない状態であることを認識するために、提供側コンポーネントにおいて処理の登録が行われるまでの短時間だけ待機すればよく、処理の実施結果が通知されるまでの長時間を待機する必要はない。
【００１７】
つまり、利用側コンポーネントは、実施依頼メッセージを送信してから受付通知メッセージを受信するまでに要すると想定される時間だけ待って、提供側コンポーネントに異常が発生しているとみなし、その異常に対応するためのエラー処理を実行することができる。これにより、提供側コンポーネントの異常時におけるエラー処理を実行するまでの時間を大幅に短縮することができるようになる。
【００１８】
また、上記実施形態では、実施開始メッセージ後に、提供側コンポーネントと利用側コンポーネントとの間で必要なデータをやり取りして実施の依頼を受けた処理を実行できるため、最新のデータで処理でき、制御上好ましい。
【００１９】
なお、ここでいう「エラー処理」とは、例えば、提供側コンポーネントに対して実施依頼メッセージを再度送信したり、実施依頼メッセージにて依頼した処理の実施結果に基づいて実行すべき別の処理を規定のパラメータに基づいて実行したり、といった処理のことである。
【００２０】
なお、上記構成におけるプログラムコンポーネント間では、コンポーネント同士が同じ処理装置に実装されていれば、その処理装置内部でメッセージのやり取りが行われることとなるが、コンポーネント同士が異なる処理装置に実装されている場合であれば、それぞれのコンポーネントが実装された処理装置の通信機能を介してメッセージのやり取りが行われることとなる。
【００２１】
ところで、上記処理システムを、例えば、車両などのアクチュエータを制御対象として制御するための構成として採用することを考えると、各プログラムコンポーネントによる処理がそれぞれ決められたスケジュールに従って実行できることが望ましい。
【００２２】
それは、例えば、利用側コンポーネントが、提供側コンポーネントによる実施結果を受けて別の処理を実行するにあたり、制御対象を適切に動作させるために、その処理の実行を特定の時期までに開始しなければならない場合があるからである。
【００２３】
このような場合を想定すると、利用側コンポーネントでは、その処理の実行を特定の時期までに開始できるか否かを早急に判断し、開始できないのであれば、それに対応するためのエラー処理を実行できるようにする必要がある。
【００２４】
このためには、上記第１の構成を以下に示すようにした第２の構成（請求項２）、または、第３の構成（請求項３）とすることが考えられる。
第２の構成において、前記利用側コンポーネントは、前記実施依頼メッセージとして、特定処理の実施およびその実施結果の通知だけでなく、その実施または通知を所定時期までに行うべき旨を依頼するためのメッセージを、前記実施依頼手順により送信するように構成されている。
【００２５】
一方、前記提供側コンポーネントは、他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理の実施または実施結果の通知が、その依頼に係る時期までに行うことができるか否かを、前記処理登録手順で登録した処理に基づいて判定する可否判定手順を、さらに当該提供側コンポーネントを実装した処理装置に実行させるためのものである。そして、前記可否判定手順にて処理の実施または実施結果の通知を依頼に係る時期までに行うことができると判定した場合に、前記処理登録手順により、その判定の契機となった前記実行依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントに対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録するように構成されている。
【００２６】
この構成であれば、利用側コンポーネントは、処理の実施だけでなく、その処理の実施または通知を特定の時期までに行うべき旨を提供側コンポーネントに依頼しており、この依頼を受けた提供側コンポーネントは、その依頼に係る時期までに処理の実施または通知ができると判定してはじめて、処理の登録を行い、その処理の実施を受け付けた旨を通知する。
【００２７】
このように、提供側コンポーネントからの通知は、利用側コンポーネントからの依頼に係る時期までに処理の実施または通知を行うことができる場合に行われることから、利用側コンポーネントは、依頼に基づく通知があったことをもって、その依頼に係る処理が受け付けられ、かつ、所定時期までに処理の実施または通知が行われることを認識できる。
【００２８】
そのため、利用側コンポーネントは、所定時期までに処理の実施または通知が行われないことを認識するために、提供側コンポーネントにおいて処理の登録が行われるまでの短時間だけ待機すればよく、その処理結果に基づく別の処理を実際に実行すべき時期が到来するまで待機する必要はない。
【００２９】
つまり、利用側コンポーネントは、実施依頼メッセージを送信してから受付通知メッセージを受信するまでに要すると想定される時間だけ待って、所定時期までに処理の実施または通知が行われないとみなし、それに対応するためのエラー処理を実行することができる。これにより、所定時期までに処理の実施または通知が行われない場合におけるエラー処理を実行するまでの時間を大幅に短縮することができるようになる。
【００３０】
この構成において、実施または通知を行うべき所定時期とは、例えば、実施または通知を行うべき時刻そのものを示すものであればよく、また、その時刻を、実施依頼メッセージを受けてから実施または通知を行うまでの最大時間で規定したものであってもよい。
【００３１】
また、提供側コンポーネントが、依頼に係る時期までに処理の実施または実施結果の通知を行うことができるか否かは、処理登録手順にて先に登録した処理に基づいて行えばよい。例えば、それら登録済みの処理それぞれに要する処理負荷に応じて、または、それら処理負荷および依頼に係る処理に要する処理負荷に応じて、それら全ての処理を終了する時期を推定し、これを依頼に係る時期と対比することによって、依頼に係る時期までに処理の実施または実施結果の通知を行うことができるか否かを判定することが考えられる。
【００３２】
第３の構成において、前記提供側コンポーネントは、他のプログラムコンポーネントから前記実施依頼メッセージを受信した際に、該実施依頼メッセージにて依頼された処理を実施または実施結果を通知できる時期を、前記処理登録手順で登録した処理に基づいて特定する時期特定手順を、さらに当該提供側コンポーネントを実装した処理装置に実行させるためのものである。そして、前記時期特定手順による特定の契機となった前記実施依頼メッセージを送信してきたプログラムコンポーネントに対して、処理の実施を受け付けた旨と共に、その特定された時期を通知するためのメッセージを、前記受付通知手順により、前記受付通知メッセージとして送信するように構成されている。
【００３３】
この構成であれば、提供側コンポーネントは、利用側コンポーネントから実施依頼メッセージを受信した際、その依頼に係る処理の実施を受け付けた旨と共に、その依頼に係る処理の実施または実施結果を通知できる時期をその利用側コンポーネントに通知する。
【００３４】
これを受けた利用側コンポーネントでは、実施依頼メッセージを送信した以降、受付通知メッセージを受けて処理が実施または実施結果が通知される時期を認識でき、その時期に基づいて所定時期までに処理結果の通知が行われるか否かを判定することができる。
【００３５】
そのため、その所定時期が到来する，または，実際に処理結果が通知されてくるまで待機しなくても、提供側コンポーネントからの受付通知メッセージを受けて、所定時期までに処理結果の通知が行われるか否かを判定することができる。そして、処理結果の通知が行われないと判定したことをもって、それに対応するためのエラー処理を実行することができる。
【００３６】
これにより、所定時期までに処理結果の通知が行われない場合におけるエラー処理を実行するまでの時間を大幅に短縮することができるようになる。
この構成におけるエラー処理としては、例えば、所定時期までに処理結果の通知が行われないと判定された場合に、その判定の契機となった実施依頼メッセージに係る依頼をしなかったものとみなして、その依頼に係る処理の実施についての開始指令メッセージの送信をしないようにする、といった処理が考えられる。また、所定時期までに処理結果の通知が行われないと判定された場合に、その判定の契機となった実施依頼メッセージに係る依頼を取り消すべき旨の依頼取消メッセージを送信する、といった処理が考えられ、この場合、提供側コンポーネントが、その依頼取消メッセージにて取り消すべきとされた依頼に係る処理の登録を取り消す、といった処理を行うようにするとよい。
【００３７】
また、この構成において、提供側コンポーネントが、実施依頼メッセージにて依頼された処理を実施または処理の実施結果を通知できる時期を特定するためには、処理登録手順にて先に登録した処理に基づいて行えばよい。例えば、それら登録済みの処理それぞれに要する処理負荷に応じて、または、それら処理負荷および依頼に係る処理に要する処理負荷に応じて、それら全ての処理を終了する時期を推定し、これを実施または通知できる時期として特定することが考えられる。
【００３８】
また、上記各構成において、提供側コンポーネントによる処理の登録は、どのように実現することとしてもよく、例えば、以下に示すようにした第４の構成（請求項４）とすることが考えられる。
【００３９】
この構成において、前記提供側コンポーネントは、前記処理登録手順により、複数の処理を登録可能なバッファに前記実施依頼メッセージにて依頼された処理を登録するように構成されている。
【００４０】
この構成であれば、提供側コンポーネントでは、バッファに登録された処理を随時実施することができる。
また、上記各構成の提供側コンポーネントにおいて登録された各処理は、どのような順番で実施することとしてもよく、例えば、その登録された順番（つまり、先入れ先出し方式）にて実施することとすればよい。また、処理の内容に応じた優先度に基づき、その登録された処理それぞれを優先度の高いものから先に実施するようにしてもよい。
【００４１】
この後者のように処理を実施するためには、例えば、上記各構成を以下に示すようにした第５の構成（請求項５）とすることが考えられる。
この構成において、前記提供側コンポーネントは、前記処理登録手段により、前記実施依頼メッセージにて依頼された処理を、該実施依頼メッセージを送信してきたプログラムコンポーネントまたはその処理の内容に応じて定められた優先度を対応づけた状態で、当該提供側コンポーネントが実施すべき処理として登録して、前記処理登録手段により登録された処理それぞれを、前記処理実施手順により、該処理に対応づけられた優先度の高い順番で実施するように構成されている。
【００４２】
この構成であれば、提供側コンポーネントでは、登録済みの処理それぞれを、その処理に対応づけられた優先度に基づく順番で実施することができる。
なお、このような優先度を対応づけた状態での処理の登録には、例えば、単一のバッファに優先度を示す情報と共に処理を登録したり、登録すべき処理を、それぞれ異なる優先度が割り当てられた複数のバッファのうち、その処理に対応する優先度が割り当てられたバッファへと登録したりすることで実現すればよい。
【００４３】
また、上記各構成において、利用側コンポーネントは、提供側コンポーネントからの実行開始メッセージを受けた際、その実施開始メッセージに係る処理の実施を開始すべき旨の開始指令メッセージを、その提供側コンポーネントに送信することとなる。このとき、実行開始メッセージを受信するまでの間に、その実施依頼メッセージにより依頼した処理の処理結果を必要としない、または、先に優先すべき処理が発生していることも考えられ、このような場合には、開始指令メッセージを送信して処理の実施を開始させることが必ずしも適切とはいえない。
【００４４】
そのため、そのような場合には、開始指令メッセージを送信しないなどにより、提供側コンポーネントによる処理の実施を開始させないようにすることが望ましい。このためには、上記各構成を以下に示すようにした第６の構成（請求項６）とすることが望ましい。
【００４５】
この構成の前記利用側コンポーネントは、前記実施依頼手順にて実施依頼メッセージを送信した以降、該送信先のプログラムコンポーネントから前記実行開始メッセージを受信した際に、当該利用側コンポーネントまたは当該処理システムの動作状態に基づいて、その実施開始メッセージに係る処理を実施すべきか否かを判定する実施判定手順を、さらに当該利用側コンポーネントを実装した処理装置に実行させるためのものである。そして、該実施判定手順にて処理を実施すべきと判定した場合に、その判定の契機となった実施開始メッセージを送信してきたプログラムコンポーネントに対して、前記開始送信手順により、その処理の実施を開始すべき旨を指令するための開始指令メッセージを送信するように構成されている。
【００４６】
この構成であれば、利用側コンポーネントは、提供側コンポーネントからの実行開始メッセージを受けた際、その実行開始メッセージに係る処理を実施すべきと判定してはじめて、その処理の実施を開始すべき旨を指令すべく開始指令メッセージを送信する。
【００４７】
これにより、例えば、実施依頼メッセージを送信した以降、実行開始メッセージを受信するまでの間に、その実施依頼メッセージにより依頼した処理の処理結果を必要としない、または、先に優先すべき処理が発生していた場合には、その実行開始メッセージに係る処理を実施すべきでないと判定し、開始指令メッセージを送信しないようにすることができる。こうして、提供側コンポーネントによる処理の実施を開始させないようにすることができ、提供側コンポーネントでの処理負荷の軽減にも寄与することとなる。
【００４８】
また、上記課題を解決するための構成としては、上記第１〜第６のいずれかの利用側コンポーネントおよび提供側コンポーネントのいずれか一方または両方を実装してなる処理装置（請求項７）としてもよい。この構成であれば、上記各構成における処理システムの一部を構成することができるからである。
【００４９】
また、上記課題を解決するための構成としては、上記第１〜第６のいずれかの利用側コンポーネントに含まれる全ての手順をコンピュータシステムに実行させるためのプログラム（請求項８）、または、上記第１〜第６のいずれかの提供側コンポーネントに含まれる全ての手順をコンピュータシステムに実行させるためのプログラム（請求項９）としてもよい。
【００５０】
なお、上述したプログラムは、コンピュータシステムによる処理に適した命令の順番付けられた列からなるものであって、各種記録媒体や通信回線を介して各処理装置や、これを利用するユーザに提供されるものである。
【発明を実施するための最良の形態】
【００５１】
以下に本発明の実施形態を図面と共に説明する。
（１）全体構成
処理システム１は、図１に示すように、複数（本実施形態では３つ）の処理装置（ＥＣＵ；Electronic Control Unit ）２それぞれがネットワーク１００を介して通信可能に接続されてなり、アクチュエータ２００を介して所定の制御対象を駆動させるように構成されたシステムである。ここでいうアクチュエータ２００とは、例えば、モータや油圧バルブなどのことであり、制御対象とは、例えば、スロットル弁や可変バルブ機構などのことである。
【００５２】
これら処理装置２それぞれには、処理装置２全体の動作を制御する制御部１０，各種データを記憶する記憶部１２，外部機器（アクチュエータ２００，センサ３００，表示部４００など）との間で信号の入出力を行う入出力部１４，ネットワーク１００を介したデータのやりとりを制御する通信部１６などが備えられている。
【００５３】
この処理システム１では、それぞれ制御対象の動作を制御するために必要な機能の一部を実現する複数種類のプログラムコンポーネント（以降、「コンポーネント」という）が、それぞれ処理装置２に実装されている。ここでいうコンポーネントとは、ソフトウェアプラットフォーム上で動作するアプリケーションコンポーネント（具体的な例としてエンジン制御を行うコンポーネントなど）のことである。そして、各処理装置２は、これを制御部１０の内蔵メモリにおいて展開，起動することによって、このコンポーネントに従って制御対象の駆動に関する処理を実行する。
【００５４】
これらコンポーネントには、図２に示すように、例えば、利用側コンポーネント２０，提供側コンポーネント３０などの種類がある。
利用側コンポーネント２０は、提供側コンポーネント３０から提供されるサービスを利用するものであり、具体的には、別のコンポーネントに処理の実施を依頼し、その実施結果に基づいて別の処理を起動する、といった処理を、この利用側コンポーネント２０が実装された処理装置２（の制御部１０）に実行させるためのものである。
【００５５】
一方、提供側コンポーネント３０は、他のプログラムコンポーネントに対してサービスを提供するものであり、具体的には、別のコンポーネントからの依頼を受け、その依頼に係る処理を実施すると共に、その実施結果を依頼元のコンポーネントに返信する、といった処理を、この提供側コンポーネント３０が実装された処理装置２（の制御部１０）に実行させるためのものである。
【００５６】
なお、利用側コンポーネント２０と提供側コンポーネント３０との間では、コンポーネント同士が同じ処理装置２に実装されている場合であれば、その処理装置２内でメッセージのやり取りが行われることとなるが、コンポーネント同士が異なる処理装置２に実装されている場合であれば、それぞれのコンポーネントが実装された処理装置２の通信部１６を介してメッセージのやり取りが行われることとなる。
【００５７】
以下、各コンポーネントにより実行される処理の違いに応じた実施形態それぞれについて説明する。
（２）第１実施形態
（２−１）実施依頼処理／実施受付処理
はじめに、利用側コンポーネント２０が提供側コンポーネント３０に対して処理の実施を依頼し、提供側コンポーネント３０がその依頼を受け付ける、といった過程において実行される実施依頼処理および実施受付処理の処理手順を図３に基づいて説明する。
【００５８】
利用側コンポーネント２０は、提供側コンポーネント３０の提供するサービスを利用すべきタイミングとなった際に、実施依頼処理の実行を開始する。
この実施依頼処理では、まず、それぞれ複数種類の処理それぞれに対応づけられたコンポーネントのうち、そのサービスの利用に際して実施させるべき処理（以降、「実施処理」という）に対応するコンポーネントに対して、その実施処理の実施および実施結果の通知を依頼するための実施依頼メッセージが送信される（ｓ１１０）（図２の（ａ）参照）。
【００５９】
こうして、実施依頼メッセージが送信された後は、提供側コンポーネント３０から後述する受付通知メッセージが受信されるまで待機状態となる（ｓ１２０：ＮＯ）。
一方、この実施依頼メッセージを受信した提供側コンポーネント３０は、実施受付処理の実行を開始し、この中で、その実施依頼メッセージにて依頼された処理を登録可能であるか否かのチェック（ｓ２１０）結果に応じた受付通知メッセージを、その実施依頼メッセージを送信してきた利用側コンポーネント２０へと送信する（ｓ２３０，ｓ２４０）。
【００６０】
具体的には、提供側コンポーネント３０が実装された処理装置の実施受付用バッファ（図２参照）に空きがあれば、依頼された処理を登録可能であるとして（ｓ２１０：ＹＥＳ）、実施依頼メッセージにて依頼された処理が登録される（ｓ２２０）（同図（ｂ）参照）と共に、登録可能である旨（ＯＫ）を示す受付通知メッセージが送信される（ｓ２３０）（図２の（ｃ）参照）。その一方、実施受付用バッファに空きがなければ、依頼された処理を登録不可能であるとして（ｓ２１０：ＮＯ）、登録不可能である旨（ＮＧ）を示す受付通知メッセージが送信される（ｓ２４０）（同図（ｃ）参照）。
【００６１】
なお、上記ｓ２２０での登録は、実施依頼メッセージを送信してきたコンポーネントを特定するための特定情報，実施依頼メッセージにて依頼された処理に関する処理情報などを、実施受付用バッファに記憶させることにより実現される。また、この登録に際しては、実施依頼メッセージの送信元であるコンポーネント，実施依頼メッセージにて依頼された処理の内容，または，その処理結果を受けて実行すべき特定処理の内容，などに応じて定められた優先度を対応づけた状態で登録することとしてもよい。
【００６２】
ここで利用側コンポーネント２０による実施依頼処理へ戻り、実施依頼メッセージが送信された以降、提供側コンポーネント３０からの受付通知メッセージが受信された場合には（ｓ１２０：ＹＥＳ）、その受付通知メッセージが、処理を登録可能である旨（ＯＫ）を示すものであるか否かがチェックされる（ｓ１４０）。
【００６３】
このｓ１４０で、処理を登録可能である旨（ＯＫ）を示すものであると判定されたら（ｓ１４０：ＹＥＳ）、上記ｓ１１０において実施依頼メッセージにより実施を依頼した処理が、依頼済みの処理として登録された後（ｓ１５０）、本実施依頼処理が終了する。
【００６４】
ここでの登録は、利用側コンポーネント２０が実装された処理装置２の記憶部１２に、上記ｓ１１０において実施依頼メッセージにより実施を依頼した処理に関する処理情報や、依頼先のコンポーネントに関する依頼情報などを記憶させることにより実現される。
【００６５】
また、上記ｓ１４０で処理を登録不可能である旨（ＮＧ）を示すものであると判定された場合（ｓ１４０：ＮＯ）には、別のコンポーネントによる処理の実施結果が取得できないとして、それに対応するためのエラー処理が行われた後（ｓ１６０）、本実施依頼処理が終了する。
【００６６】
この「エラー処理」とは、例えば、一定時間の待機を経て実施依頼メッセージを再度送信したり、実施結果に基づいて実行すべき別の処理を規定のパラメータに基づいて実行したり、といった処理のことである。この規定のパラメータに基づく処理としては、例えば、デフォルト値を用いた処理などが考えられる。
【００６７】
なお、上記ｓ１２０での待機状態が一定時間以上継続した場合にも、このｓ１６０へと移行してエラー処理が行われることとしてもよい。
（２−２）実施指令処理／実施特定処理
続いて、提供側コンポーネント３０が、実施受付バッファに登録された処理を実施して、その結果を利用側コンポーネント２０に通知する、といった過程において実行される実施特定処理および実施指令処理の処理手順を図４に基づいて説明する。
【００６８】
まず、提供側コンポーネント３０は、実施特定処理の中で、実施受付用バッファに処理が登録された状態となっているか否かを監視しており（ｓ３１０）、登録された状態となった際に（ｓ３１０：ＹＥＳ）、そうして登録されている処理の中から、次に実施すべき処理を特定する（ｓ３２０）。
【００６９】
ここでは、実施受付用バッファに登録されている処理のうち、最も先に登録された処理を、次に実施すべき処理として特定することとすればよく、また、各処理それぞれに優先度が対応付けられた状態で登録されている場合であれば、そうして登録されている処理のうち、最も優先度の高い処理を、次に実施すべき処理として特定することとすればよい。
【００７０】
次に、上記ｓ３２０にて特定された処理の実施を開始することを通知するための実施開始メッセージが、その処理に対応する依頼元の利用側コンポーネント２０に対して送信される（ｓ３３０）（図２の（ｄ）参照）。ここで、依頼元の利用側コンポーネント２０は、上記ｓ３２０にて特定された処理に係る特定情報に基づいて特定される。
【００７１】
このｓ３３０にて送信された実施開始メッセージを受けた利用側コンポーネント２０は、実施指令処理の実行を開始し、この中で、まず、その実施開始メッセージにて実施を開始するとされた処理を実施すべきか否かを、利用側コンポーネント２０または処理システム１の動作状態に基づいて判定する（ｓ４１０）。
【００７２】
ここでは、実施開始メッセージを受信した時点における利用側コンポーネント２０または処理システム１の動作状態から、この実施開始メッセージにて実施を開始するとされた処理の処理結果を必要としない、または、先に優先すべき処理が発生した状況となっている場合に、該当処理を実施すべきではないと判定される。
【００７３】
このｓ４１０で処理を実施すべきであると判定された場合には（ｓ４１０：ＹＥＳ）、その処理の実施を開始すべき旨を指令するための開始指令メッセージが、実施開始メッセージの送信元である提供側コンポーネント３０に送信される（ｓ４２０）（図２の（ｅ）参照）。
【００７４】
この開始指令メッセージを受信した提供側コンポーネント３０は、後述のように、開始指令メッセージにて開始を指令した処理を実行し、その処理において必要に応じて利用側コンポーネント３０との間でデータをやりとりしつつ、その処理結果を通知するための結果通知メッセージを送信してくる（図２の（ｆ）参照）。
【００７５】
そのため、上記ｓ４２０にて開始指令メッセージを送信した後は、提供側コンポーネント３０からの結果通知メッセージが受信されるまで待機状態となる（ｓ４３０：ＮＯ）。その後、結果通知メッセージが受信されたら（ｓ４３０：ＹＥＳ）、この結果通知メッセージにて通知された処理結果に基づいて実行すべき対応処理の実行が開始されて（ｓ４４０）、本実施指令処理が終了する。
【００７６】
このｓ４４０では、利用側コンポーネント２０の実装された処理装置の記憶部１２に記憶された処理情報および依頼情報のうち、上記ｓ４２０で送信した開始指令メッセージにて開始を指令した処理に対応する処理情報および依頼情報を、記憶部１２から削除する処理も併せて行われる。
【００７７】
また、上記ｓ４１０で処理を実施すべきでないと判定された場合には（ｓ４１０：ＮＯ）、その処理の実施を中止すべき旨を指令するための中止指令メッセージが、実施開始メッセージの送信元である提供側コンポーネント３０に送信される（ｓ４５０）（図２の（ｅ）参照）。
【００７８】
そして、上記ｓ４１０で処理を実施すべきでないと判定したことに対応するためのエラー処理が行われた後で（ｓ４６０）、本実施指令処理が終了する。
ここでの「エラー処理」とは、例えば、ここで中止すべきとした処理の処理結果を必要とするタイミングとなるまで待機したうえで、実施指令処理を上記ｓ４２０から再開したり、上記対応処理の実行を規定のパラメータに基づいて開始したり、といった処理のことである。
【００７９】
なお、上記ｓ４３０で一定時間以上待機状態となった場合にも、このｓ４６０へと移行してエラー処理が行われることとしてもよい。
ここで提供側コンポーネント３０による実施特定処理へ戻り、提供側コンポーネント３０は、上記ｓ３３０による実施開始メッセージの送信後、利用側コンポーネント２０からメッセージが受信されるまで待機状態となる（ｓ５００：ＮＯ）。
【００８０】
その後、メッセージが受信されたら（ｓ５００：ＹＥＳ）、そのメッセージが開始指令メッセージであるか否かがチェックされる（ｓ５１０）。
このｓ５１０で開始指令メッセージであると判定された場合には（ｓ５１０：ＹＥＳ）、実施受付バッファに登録されている処理のうち、その開始指令メッセージにて開始を指令された処理の実施が開始される（ｓ５２０）。この処理の実施に際しては、必要に応じて利用側コンポーネント３０との間でのデータのやりとりが行われることとなる。
【００８１】
この後、こうして開始された処理が終了するまで待機状態となり（ｓ５３０：ＮＯ）、その処理が終了したら（ｓ５３０：ＹＥＳ）、そうして終了した処理の処理結果（例えば、処理結果を示す特定のパラメータなど）を通知するための結果通知メッセージが、その処理に対応する依頼元の利用側コンポーネント２０（上記ｓ３３０の送信先と同じコンポーネント）に対して送信される（ｓ５４０）（図２の（ｆ）参照）。
【００８２】
そして、実施受付バッファに登録されている処理のうち、上記ｓ５２０にて実施を開始した処理についての登録内容が削除された後（ｓ５５０）（同図（ｇ）参照）、プロセスがｓ３１０へと戻る。
【００８３】
また、上記ｓ５１０で中止指令メッセージであると判定された場合にも（ｓ５１０：ＮＯ）、プロセスがｓ５５０へと移行する。
（２−３）作用，効果
このように構成された処理システム１において、利用側コンポーネント２０は、実施依頼メッセージを送信することで提供側コンポーネント３０に処理の実施を依頼した後、この依頼を受け付けた提供側コンポーネント３０からの受付通知メッセージを受信する（図２の（ａ），（ｃ）参照）。
【００８４】
これにより、利用側コンポーネント２０は、依頼先のプログラムコンポーネント側でその依頼が正常に受け付けられたことを認識できるため、その後、提供側コンポーネント３０における処理負荷の大きさに起因する遅延が発生して長時間が経過したとしても、再度の依頼（実施依頼メッセージの再送信）および処理の実施に必要なデータの送信をしないようにすることができる。
【００８５】
具体的にいえば、利用側コンポーネント２０は、依頼が受け付けられるまでの期間（図２のｔ１参照）を一つのセッションとしてリソースを確保しており（図３のｓ１１０〜ｓ１６０）、その後、提供側コンポーネント３０から実施開始メッセージを受けるまでの間、その依頼に関するセッションに拘束されなくなるため、それ以降の遅延に拘わらず再度の依頼およびデータの送信をすることはない。
【００８６】
これにより、不必要な再度の依頼およびデータの送信をしてしまうことがなくなるため、こうして送信されるデータや、このデータに基づいて実施される処理が無駄なものとなってしまうこともなくなる結果、プログラムコンポーネントそれぞれの処理負荷および通信負荷を小さくすることができる。
【００８７】
また、上記実施形態では、実施開始メッセージ後に、提供側コンポーネントと利用側コンポーネントとの間で必要なデータをやり取りして実施の依頼を受けた処理を実行できるため、最新のデータで処理でき、制御上好ましい。
【００８８】
また、提供側コンポーネント３０からの受付通知メッセージは、処理の登録が行われたときであれば（図２の（ｂ）参照）、その処理を実施するタイミングに拘わらず送信される（同図（ｃ）参照）。そのため、利用側コンポーネント２０は、提供側コンポーネント３０が依頼を正常に受け付けられない状態であることを認識するために、提供側コンポーネント３０において処理の登録が行われるまでの短時間（図２のｔ１参照）だけ待機すればよく、処理の実施結果が通知されるまでの長時間（同図ｔ２参照）を待機する必要はない。
【００８９】
つまり、利用側コンポーネント２０は、実施依頼メッセージを送信し、提供側コンポーネントから受付通知メッセージを受け、その内容を確認することで提供側コンポーネント３０に異常が発生していると判断でき、その異常に対応するためのエラー処理を実行することができる（図３のｓ１６０参照）。これにより、提供側コンポーネント３０の異常時におけるエラー処理を実行するまでの時間は、せいぜい実施依頼メッセージを送信してから受付通知メッセージを受信するまでに要すると想定される時間ｔ１程度まで大幅に短縮することができるようになる。
【００９０】
また、この提供側コンポーネント３０は、実施受付バッファに登録された処理それぞれを、その登録された順番，または，処理に対応づけられた優先度に基づく順番で実施することができる。
【００９１】
また、上記実施形態において、利用側コンポーネント２０は、提供側コンポーネント３０からの実行開始メッセージを受けた際、その実行開始メッセージに係る処理を実施すべきと判定してはじめて、その処理の実施を開始すべき旨を指令すべく開始指令メッセージを送信することができる（図４のｓ４１０「ＹＥＳ」→ｓ４２０）。
【００９２】
これにより、例えば、実施依頼メッセージを送信した以降、実行開始メッセージを受信するまでの間に、その実施依頼メッセージにより依頼した処理の処理結果を必要としない、または、先に優先すべき処理が発生していた場合には、その実行開始メッセージに係る処理を実施すべきでないと判定し、開始指令メッセージを送信しないようにすることができる。こうして、提供側コンポーネント３０による処理の実施を開始させないようにすることができ、提供側コンポーネント３０での処理負荷の軽減にも寄与することとなる。
（３）第２実施形態
本実施形態においては、利用側コンポーネント２０による実施依頼処理および提供側コンポーネント３０による実施受付処理それぞれの処理手順が一部異なっているだけであるため、その相違点についてのみ詳述する。
（３−１）実施依頼処理／実施受付処理
まず、上記実施形態の実施依頼処理においては、実施依頼メッセージが、処理の実施およびその実施結果の通知を依頼するためのメッセージである場合を例示したが、本実施形態における実施依頼メッセージは、処理の実施およびその実施結果の通知だけでなく、その実施または通知を特定時期（例えば、具体的な時刻や、利用側コンポーネント２０において待機可能な時間）までに行うべき旨を依頼するためのメッセージである。
【００９３】
この場合、実施受付処理では、図５に示すように、ｓ２１０で「ＹＥＳ」と判定された場合に、実施依頼メッセージにて依頼された処理の実施または実施結果の通知が、その依頼に係る時期までに可能か否かを、実施受付用バッファの登録内容に基づいて判定する（ｓ２１２）。
【００９４】
そして、その依頼に係る時期までに可能であると判定された場合に（ｓ２１２：ＹＥＳ）、ｓ２２０へ移行するのに対し、不可能であると判定された場合に（ｓ２１２：ＮＯ）、ｓ２４０へと移行するようにする。
【００９５】
このｓ２１２による判定は、例えば、実施受付用バッファに登録された処理それぞれに要する処理負荷に応じて、または、それら処理負荷および依頼に係る処理に要する処理負荷に応じて、それら全ての処理を終了する時期を推定し、これを依頼に係る時期と対比することによって、依頼に係る時期までに処理の実施または実施結果の通知を行うことができるか否かを判定することとすればよい。
（３−２）作用，効果
このように構成された処理システム１であれば、第１実施形態と同様の構成から得られる作用，効果の他、次のような作用，効果を得ることができる。
【００９６】
例えば、処理システム１を、車両に搭載された制御対象を制御する構成として採用することを考えると、各コンポーネントによる処理がそれぞれ決められたスケジュールに従って実行できる必要がある。それは、例えば、利用側コンポーネント２０が、提供側コンポーネント３０による実施結果を受けて別の処理を実行するにあたり、制御対象を適切に動作させるために、その処理の実行を特定の時期までに開始しなければならない場合があるからである。
【００９７】
このような場合を想定すると、利用側コンポーネント２０では、その処理の実行を特定の時期までに開始できるか否かを早急に判断し、開始できないのであれば、それに対応するためのエラー処理を実行できるようにする必要がある。
【００９８】
上記実施形態では、このような要請に応えるべく、利用側コンポーネント２０が、処理の実施だけでなく、その処理の実施または通知を所定時期までに行うべき旨を依頼すると共に、この依頼を受けた提供側コンポーネント３０が、その依頼に係る時期までに処理の実施または通知ができると判定してはじめて処理の登録を行い（図５のｓ２１２「ＹＥＳ」→ｓ２２０）、その処理の実施を受け付けた旨を通知している（同図ｓ２３０）。
【００９９】
このように、提供側コンポーネント３０からの通知は、利用側コンポーネント２０からの依頼に係る時期までに処理の実施または通知を行うことができる場合に行われることから、利用側コンポーネント２０は、依頼に基づく通知があったことをもって、その依頼に係る処理が受け付けられ、かつ、所定時期までに処理の実施または通知が行われることを認識できる。
【０１００】
そのため、利用側コンポーネント２０は、所定時期までに処理の実施または通知が行われないことを認識するために、提供側コンポーネント３０において処理の登録が行われるまでの短時間だけ待機すればよく、その処理結果に基づく別の処理を実際に実行すべき時期が到来するまで待機する必要はない。
【０１０１】
つまり、利用側コンポーネント２０は、実施依頼メッセージを送信し、提供側コンポーネントから受付通知メッセージを受け、その内容を確認することで提供側コンポーネント３０に異常が発生していると判断でき、その異常に対応するためのエラー処理を実行することができる（同図ｓ１４０「ＮＯ」→ｓ１６０）。これにより、提供側コンポーネント３０の異常時におけるエラー処理を実行するまでの時間は、せいぜい実施依頼メッセージを送信してから受付通知メッセージを受信するまでに要すると想定される時間ｔ１程度まで大幅に短縮することができるようになる。
（４）第３実施形態
本実施形態においては、利用側コンポーネント２０による実施依頼処理および提供側コンポーネント３０による実施受付処理それぞれの処理手順が、上記実施形態と一部異なっているだけであるため、その相違点についてのみ詳述する。
（４−１）実施依頼処理／実施受付処理
まず、上記第２実施形態では、提供側コンポーネント３０による処理の実施または実施結果の通知が所定時期までに可能か否かを、提供側コンポーネント３０で判定することとしているが、本実施形態では、この判定を、利用側コンポーネント２０により実現している。
【０１０２】
具体的にいえば、まず、図６に示すように、提供側コンポーネント３０による実施受付処理において、ｓ２１０で「ＹＥＳ」と判定された場合に、上記ｓ２１２と同様に、実施依頼メッセージにて依頼された処理の実施または実施結果の通知を行うことのできる時期を、実施受付用バッファの登録内容に基づいて特定し（ｓ２１４）、こうして特定した時期を付加した状態で、ｓ２３０にて処理の登録を行うこととする。
【０１０３】
そして、利用側コンポーネント２０による実施依頼処理では、ｓ１４０で「ＹＥＳ」と判定された場合に、受付通知メッセージに付加された時期に基づいて、実施依頼メッセージにて依頼した処理の実施または実施結果の通知が所定時期までに実現されるか否かを判定し（ｓ１４２）、実現されると判定された場合に（ｓ１４２：ＹＥＳ）、ｓ１５０へ移行するのに対し、実現されないと判定された場合に（ｓ１４２：ＮＯ）、ｓ１６０へ移行するようにするとよい。
【０１０４】
この場合、ｓ１６０によるエラー処理としては、例えば、ｓ１４２による判定の契機となった実施依頼メッセージに係る依頼をしなかったものとみなして、その依頼に係る処理の実施についての開始指令メッセージの送信をしないようにする（具体的には、ｓ４１０で「ＮＯ」と判定するようにするなど）、といった処理が考えられる。
【０１０５】
また、ｓ１４２による判定の契機となった実施依頼メッセージに係る依頼を取り消すべき旨の依頼取消メッセージを送信する、といった処理が考えられ、この場合、提供側コンポーネント３０が、その依頼取消メッセージにて取り消すべきとされた依頼に係る処理の登録を取り消す（実施受付バッファから該当処理についての登録内容を削除する）、といった処理を行うようにするとよい。
（４−２）作用，効果
このように構成された処理システム１であれば、上記実施形態と同様の構成から得られる作用，効果の他、次のような作用，効果を得ることができる。
【０１０６】
例えば、提供側コンポーネント３０は、利用側コンポーネント２０から実施依頼メッセージを受信した際、その依頼に係る処理の実施を受け付けた旨と共に、その依頼に係る処理の実施または実施結果を通知できる時期をその利用側コンポーネント２０に通知する（図６のｓ２１４，ｓ２３０）。
【０１０７】
これを受けた利用側コンポーネント２０では、実施依頼メッセージを送信した以降、受付通知メッセージを受けて処理が実施または実施結果が通知される時期を認識でき、その時期に基づいて所定時期までに処理結果の通知が行われるか否かを判定することができる。
【０１０８】
そのため、その所定時期が到来する，または，実際に処理結果が通知されてくるまで待機しなくても、提供側コンポーネントからの受付通知メッセージを受けて、所定時期までに実施結果の通知が行われるか否かを判定することができる。そして、処理結果の通知が行われないと判定したことをもって、それに対応するためのエラー処理を実行することができる（同図ｓ１４２「ＮＯ」→ｓ１６０）。
【０１０９】
これにより、所定時期までに実施結果の通知が行われない場合におけるエラー処理を実行するまでの時間を大幅に短縮することができるようになる。
（５）変形例
以上、本発明の実施の形態について説明したが、本発明は、上記実施形態に何ら限定されることはなく、本発明の技術的範囲に属する限り種々の形態をとり得ることはいうまでもない。
【０１１０】
例えば、上記実施形態においては、提供側コンポーネント３０が、依頼に係る処理を、優先度を対応づけた状態で単一の実施受付バッファに登録するように構成されたものを例示した（図３のｓ２３０）。しかし、依頼に係る処理の登録に際しては、実施受付バッファとして、それぞれ優先度が対応づけられたものを複数用意しておき、その処理の優先度に対応する実施受付バッファに登録するように構成してもよい。
【０１１１】
この場合、提供側コンポーネント３０による実施特定処理では、図７に示すように、実施受付用バッファそれぞれ（第１バッファ〜第ｎバッファ）を、その優先度の高い順番で処理が登録された状態となっているか否かをチェックするようにしておき（ｓ３１０〜ｓ３１ｎ）、登録された状態となっている場合に（ｓ３１０〜ｓ３１ｎ：ＹＥＳ）、ｓ３２０において、そうして登録された状態となった実施受付バッファに登録されている処理の中から、次に実施すべき処理（例えば、最初に登録された処理など）を特定することとすればよい。
【０１１２】
また、以下に、本処理システム１を、エンジン制御用のエンジンＥＣＵ，ナビゲーションシステム制御用のナビＥＣＵを含む複数の処理装置からなるものとし、利用側コンポーネントとしてエンジン制御用のアプリケーション（以降「エンジン制御アプリ」という）をエンジンＥＣＵに実装し、提供側コンポーネントとして他の処理装置からの故障データを収集して集中的に管理するためのアプリケーション（以降「故障データ記録アプリ」という）をナビＥＣＵに実装した構成とした場合を例示する。
【０１１３】
この場合において、エンジンＥＣＵは、失火や着火遅れを検出するためのクランク角センサなど各種センサからの検出値に基づいてアクチュエータを制御することにより、制御対象としてのエンジンを駆動させる処理装置である。また、このエンジンＥＣＵは、車両のイグニッションスイッチ（ＩＧ）がオフ側に切り替えられた際に、その時点における故障データを上記故障データ記録アプリの実装された処理装置（ここではナビＥＣＵ）に対して送信する、といった処理を実施するように構成されている。
【０１１４】
一方、ナビＥＣＵは、車両のイグニッションスイッチがオフ側に切り替えられた以降、他の処理装置（イグニッション系のＥＣＵ）から送信されてくる故障データを収集し、随時記憶部１２に記憶する、といった処理を実施するように構成されている。
【０１１５】
このように構成した場合においては、本発明の処理システムのような構成を採用しないと、ナビＥＣＵ以外の処理装置は、ナビＥＣＵ側で処理付加による遅延が生じているとしても、故障データの記憶を依頼した後、一定の待機時間を経て、故障データの記憶を再度依頼することになってしまう。
【０１１６】
一般的に故障データはそのデータ量が大きいため、そのような依頼毎に故障データが送信されてしまうことは、ネットワーク１００におけるトラフィックを不必要に増大させるばかりか、ナビＥＣＵが全ての処理装置における故障データを記憶し終える前にシステムがシャットダウンしてしまったり、全ての故障データを記憶し終えることができるようにすべくシャットダウンまでの時間が不必要に長くなってしまう恐れがある。
【０１１７】
それに対し、本発明の処理システムのような構成を採用すると、そのような再度の依頼および故障データの送信がなされなくなるため、システムがシャットダウンしてしまうまでに全ての処理装置における故障データを記憶し終える可能性が高くなり、また、全ての故障データを記憶し終えることができるようにするために確保すべきシャットダウンまでの時間を短縮することができる。
（６）本発明との対応関係
以上説明した実施形態では、実施依頼処理のｓ１１０が本発明における実施依頼手順であり、実施指令処理のｓ４２０が本発明における開始送信手順であり、同ｓ４１０が本発明における実施判定手順である。
【０１１８】
また、実施受付処理のｓ２２０が本発明における処理登録手順であり、同ｓ２３０が本発明における受付通知手順であり、同ｓ２１２が本発明における可否判定手順であり、同ｓ２１４が本発明における時期特定手順であり、実施特定処理のｓ３３０が本発明における開始通知手順であり、同ｓ５４０が本発明における結果通知手順である。
【図面の簡単な説明】
【０１１９】
【図１】処理システムの全体構成を示すブロック図
【図２】プログラムコンポーネント間のやりとりを示すシグナルフロー
【図３】第１実施形態における実施依頼処理／実施受付処理を示すフローチャート
【図４】第１実施形態における実施指令処理／実施特定処理を示すフローチャート
【図５】第２実施形態における実施依頼処理／実施受付処理を示すフローチャート
【図６】第３実施形態における実施依頼処理／実施受付処理を示すフローチャート
【図７】別の実施形態における実施特定処理を示すフローチャート
【符号の説明】
【０１２０】
１…処理システム、２…処理装置、１０…制御部、１２…記憶部、１４…入出力部、１６…通信部、２０…利用側コンポーネント、３０…提供側コンポーネント、１００…ネットワーク、２００…アクチュエータ、３００…センサ、４００…表示部。
【図１】
2009252103.tif 000003
【図３】
2009252103.tif 000004
【図４】
2009252103.tif 000005
【図５】
2009252103.tif 000006
【図６】
2009252103.tif 000007
【図７】
2009252103.tif 000008
【図２】
2009252103.tif 000009