JP4853196B2 - 制御システム - Google Patents

Description

本発明は、車両に搭載された複数の電子制御装置がネットワークを介して接続された制御システムに関するものである。

車両において、各種の機器が電子制御装置によって制御されるようになり、かつ各種の機器を制御する複数の電子制御装置がネットワークによって接続され、連携して動作するようになりつつある。さらには車外のシステム（交通情報，娯楽情報，メールサービスなどを提供するサーバーや、家庭内システム）とも無線通信によって接続されることもある。

このような環境において、従来は、アプリケーションを動作させるプラットフォームを同一にすることにより、新規システムを構築する際のアプリケーションの再利用性や、複数のアプリケーション間の相互運用性を確保しようと試みられている。しかし、車両には、エンジン制御のような定期的にデータを収集して結果を常時出力する高度な信頼性が求められるアプリケーション、ボデー系制御のようなユーザーの操作を基点として一連のシーケンスを実施するアプリケーション、ナビゲーションのような大規模なデータを使用するが比較的信頼性が求められないアプリケーション等、異質のアプリケーションが実装された複数の電子制御装置が共存している。このように、車両内でネットワーク化される複数の電子制御装置において、制御の考え方や使用可能なリソースが大きく異なるので、プラットフォームを同一にすることは難しかった。

ここで、本来、アプリケーションの再利用性と相互運用性は別の課題である。そして、上述した電子制御装置を構成するマイクロコンピュータが、年々高速化・高集積化・高機能化していき、ソフト開発言語もよりモデル言語のように抽象度の高い開発効率の高い言語が出てきている。このような状況において、同一プラットフォームにおけるアプリケーションの再利用性向上は必ずしも有効な開発効率化の手段ではなくなってきている。むしろ、モデル言語などを用いてプラットフォームに応じたコード生成によるアプリケーションの移植性向上が、開発の効率化を向上するためにより有効な手段といえる。

また、アプリケーションの相互運用性については、アプリケーション間通信が、それぞれのアプリケーションにおいて期待されるシーケンスが確実に実行され得るものであれば十分であり、プラットフォームが同一である必然性は無い。

今後、より重要なことは、車両において求められる機能がさらに高度化して、新たなアプリケーションを追加するような場合であっても、既存のアプリケーションに対する影響を最小限に抑えることができるようにすることである。つまり、新たな機能を実現するためのアプリケーションを追加する毎に、既存のアプリケーションの大幅な修正や改良が必要となると、その開発には多大な労力が必要となってしまう。

本発明は、このような点に鑑みてなされたもので、既存のアプリケーションへの影響を最小限に抑えながら、新たな機能を実現するためのアプリケーションの追加を可能とした制御システムを提供することを目的とする。

上述した目的を達成するために、請求項１に記載の制御システムは、車両に搭載された複数の電子制御装置が車内ＬＡＮを介して接続され、これら複数の電子制御装置のいずれかにおいて第１のアプリケーションが実行されたとき、当該第１のアプリケーションが、複数の電子制御装置のいずれかに実装された第２のアプリケーションに所望の機能を実行させる制御システムであって、
第２のアプリケーションに所望の機能の実行要求を行う際に、第１のアプリケーションが指示すべき要求情報のフォーマットが予め定められており、
第１のアプリケーションからの要求情報を受け付けて、当該要求情報を、第２のアプリケーションが所望の機能を行うための機能指示フォーマットのかたちで、当該第２のアプリケーションに与えるサービスインターフェースをソフトウエアによって構成し、複数の電子制御装置の各々に実装したことを特徴とする。

例えば、第２のアプリケーションを、車両において既存の機能を実現するためのアプリケーションとした場合に、その機能の使用方法を予め規定し、その使用方法に沿って機能を利用する場合に必要な情報を、要求情報フォーマットとして規定しておく。

そして、例えば第１のアプリケーションが、第２のアプリケーションによる機能を利用する新規のアプリケーションであって、この第１のアプリケーションを新たに追加する場合には、その第１のアプリケーションからの要求情報を受け付けて、機能指示フォーマットのかたちで第２のアプリケーションに与えるサービスインターフェースを設ける。

このようにすれば、第１のアプリケーションは、第２のアプリケーションに所望の機能の実行要求を行おうとした場合に、予め定められた要求情報のフォーマットのかたちで、サービスインターフェースに要求情報を与えるだけで良い。このため、既存のアプリケーションに対する影響を最小限に抑えつつ、新たな機能を実現するためのアプリケーションを簡単に追加することができるようになる。

請求項２に記載したように、第１のアプリケーションからの要求情報は、複数のアプリケーションからの実行要求が競合したときに、いずれの実行要求を優先すべきかを判断するための情報を含むことが好ましい。既存のアプリケーションであれば、既に他のアプリケーションなどによって、その機能が利用されていることがある。このような場合、複数のアプリケーションによる実行要求が競合する可能性が生じる。このような事態に備え、要求情報に優先度を示す情報を含めておけば、複数の実行要求が競合したときに、容易にその調停を行うことが可能になる。

請求項３に記載したように、第２のアプリケーションは、機能指示が与えられると、その機能指示により動作した結果を応答情報として、サービスインターフェースを介して第１のアプリケーションに与えることが好ましい。これにより、第１のアプリケーションにおいて、自身からの実行要求に対して、第２のアプリケーションがその要求通りの機能を実行したかを確認することができる。

請求項４に記載したように、サービスインターフェースは、要求情報を機能指示に変換するインターフェースを含み、第１及び第２のアプリケーションが同一の電子制御装置に実装されているとき、第１のアプリケーションからの要求情報は、インターフェースを介して第２のアプリケーションに与えるようにしても良い。また、請求項５に記載したように、サービスインターフェースは、要求情報を機能指示に変換するインターフェースと、要求情報を制御システム内のアプリケーション間の通信に共通使用される共通通信プロトコル用の通信フォーマットに従う共通通信情報に変換するプロキシと、共通通信情報を要求情報に変換するスケルトンと、プロキシが通信すべきスケルトンに向けて共通通信情報を通信するメッセージゲートウェイとを含み、第１及び第２のアプリケーションが同一の電子制御装置に実装されているとき、第１のアプリケーションからの要求情報は、プロキシ、メッセージゲートウェイ、スケルトン、及びインターフェースを介して第２のアプリケーションに与えるようにしても良い。

第１及び第２のアプリケーションが同一の電子制御装置に実装されている場合、請求項５に記載のように、要求情報などを、アプリケーション間の通信に共通使用される共通通信プロトコル用の通信フォーマットの共通通信情報に変換することで、いずれのアプリケーションとも容易に通信することが可能になる。ただし、第１のアプリケーションが、要求情報を送信すべき第２のアプリケーションと特定するための情報を有している場合には、請求項４に記載したように、その第２のアプリケーションに対して、インターフェースのみを介して、直接的に、要求情報を送信することも可能である。

請求項６に記載するように、第１のアプリケーションと第２のアプリケーションとが異なる電子制御装置に実装されているとき、第１のアプリケーションを実行する電子制御装置におけるメッセージゲートウェイは、共通通信情報を、ネットワークの通信に使用されるネットワーク通信プロトコル用の通信フォーマットに従うネットワーク通信情報に変換し、第２のアプリケーションを実行する電子制御装置におけるメッセージゲートウェイは、ネットワーク通信情報を共通通信情報に変換するとともに、通信先として特定されたスケルトンにその共通通信情報を与えるように構成することが好ましい。

第１のアプリケーションと第２のアプリケーションとが異なる電子制御装置に実装されている場合には、それらの電子制御装置を接続するネットワークを利用して情報を通信する必要がある。通常、ネットワークにおける通信プロトコルは、ＩＳＯ標準規格に定められているＣＡＮなどのプロトコルを採用することが多い。従って、ネットワークを利用して情報を通信するには、プロキシによって変換された共通通信情報を、そのネットワーク通信プロトコル用の通信フォーマットに従うネットワーク通信情報に変換する必要がある。この場合、プロキシが通信すべきスケルトンを特定するメッセージゲートウェイが、その変換機能を備えることにより、通信先のスケルトンが同一の電子制御装置に実装されているか、異なる電子制御装置に実装しているかに応じて、その変換を実施するか否かを自動的に切り換えることができる。そして、上述した構成を採用することにより、プラットフォームに依存するのは、共通通信情報を、ネットワーク通信プロトコル用の通信フォーマットに従うネットワーク情報に変換する部分のみで済ませることができる。

請求項７に記載したように、第１のアプリケーションが実装された電子制御装置において、第１のアプリケーションが第２のアプリケーションに所望の機能の実行要求を行うための要求情報の通信先に関する情報を保存し、第１のアプリケーションからの要求に応じて、通信先情報を第１のアプリケーションに与える検索アプリケーションが実装されることが好ましい。これにより、個別のアプリケーションにおいて、各種の機能の実行要求を出す際に、その送信先に関する情報を保存しておくことが不要になる。

以下、本発明の好ましい実施形態について説明する。図１は、本実施形態による車両において構築された制御システムの全体構成を示す構成図である。なお、図１には、電子制御装置１０，３０，５０から構成される制御システムを示しているが、より多くの電子制御装置から制御システムを構成するようにしても良い。また、当該制御システムは、無線通信などにより、外部のシステム（（交通情報，娯楽情報，メールサービスなどを提供するサーバーや、家庭内システム）と接続されるものであっても良い。

図１において、各電子制御装置１０，３０，５０は、例えば、車両の各ドアのロック、アンロックを制御したり、ウインドウの開閉を制御したり、各ライトの点灯、消灯を制御したりするなど、各種の車載機器の動作をコントロールする機能を備えたものである。

これら電子制御装置１０，３０，５０は、通常のコンピュータとして構成されており、内部には周知のＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ及びこれらの構成を接続するバスラインが備えられている。そして、各電子制御装置１０，３０，５０において、車載機器の動作の制御を含む各種のアプリケーションを実行するために、ＲＯＭにはそれら各種のアプリケーションに対応するプログラムが書き込まれており、それらのプログラムに従ってＣＰＵ等が演算処理を実行する。

本実施形態においては、各電子制御装置１０，３０，５０に、上述した各種の車載機器の動作を制御するサーバーアプリケーションに対する、他のクライアントアプリケーションから所望の機能の実行要求を受け付けて、該当するサーバーアプリケーションに与えるサービスインターフェース１４，３３，５２をソフトウエアによって構成し、各電子制御装置１０，３０，５０に実装した。

例えば、車両のユーザによって携帯される携帯キーの操作に応じてロック又はアンロックを指示するキーレスエントリーに関するアプリケーションからの要求を受けて、車両ドアのロック、アンロックを制御するアプリケーションが動作する制御システムが既に構築されていたとする。この制御システムにおいて、図５（ａ）に示すように、新たにセキュリティ機能を実現するためのアプリケーションを追加しようとし、この追加アプリケーションがセキュリティ機能の一環として、ドアロックやパワーウインドウの閉成等を実施するものである場合、ドアロックを制御するアプリケーションにドアロック要求を行うことになる。

すると、キーレスエントリーに関するアプリケーションからの要求と、セキュリティに関するアプリケーションからの要求とが競合する場合が発生する。既存の制御システムにおいて、ドアロックを制御するアプリケーションが、キーレスエントリーに関するアプリケーションからの要求のみしか考慮していないものであったならば、セキュリティ機能を実現するためのアプリケーションの追加に際して、複数のアプリケーションからの要求が競合した場合に、それを調停するための調停処理についての修正が必要となる。

車両において求められる機能は、ますます高度化する傾向にある。求められる機能は、その機能を発揮するための車載機器を新たに車両に設けなければ達成できないこともあれば、既存の車載機器の動作を組み合わせて達成できる場合もある。いずれの場合であっても、既存の制御システムに対して、新たにアプリケーションを追加する際に、既存のアプリケーションに対する修正等の影響を最小限に抑えることができれば、上述したような、機能の高度化要求に応えうる制御システムを効率的に開発して提供することができる。

本実施形態においては、上述したように、各電子制御装置１０，３０，５０にサービスインターフェース１４，３３，５２を実装した。このサービスインターフェース１４，３３，５２を設けたことにより、各アプリケーションは、他のアプリケーションに所望の機能の実行要求を行おうとした場合に、予め定められた要求情報のフォーマットのかたちで、サービスインターフェース１４，３２，５５に要求情報を与えれば良い。要求情報は、サービスインターフェース１４，３２，５５によって、他のアプリケーションに対し、所望の機能を行うための機能指示フォーマットのかたちで与えられる。

要求情報には、複数のアプリケーションからの実行要求が競合したときに、いずれの実行要求を優先すべきかを判断するための優先度が含まれる。これにより、複数のアプリケーションからの複数の実行要求が競合したときに、容易にその調停を行うことが可能になる。

すなわち、本実施形態によれば、図５（ｂ）に概念的に示すように、サービスインターフェースが、アプリケーション間に介在し、フォーマットの変換や調停等を行いながら必要な情報の受け渡しを行う。従って、要求情報を出力するアプリケーション（キーレス、セキュリティ）にとっては、サービスインターフェースが、所望の機能を実行するアプリケーション（ドアロック）の代理となり、そのサービスインターフェースから先の状況については何ら考慮する必要がなくなる。

以下、本実施形態におけるサービスインターフェースに関して詳しく説明する。まず、図２に示すように、車両における各種の車載機器による機能をサービスとして規定する。さらに、これらのサービスに関しては、制御システム全体として共通の思想の下に、各サービスの使用方法を規定する。これにより、一のアプリケーションが、他のアプリケーションによるサービスを使用する場合には、その使用方法に従うことになる。

基本的に、各サービスの使用方法は、図３に一例を示すように、クライアントとしての一のアプリケーションが所望の機能（サービス）の実行を要求する際に必要な要求時の情報フォーマット、その要求に対するサーバーからの応答時の情報フォーマット、要求に従ってサーバーがサービスを実行するか否かを判断するための事前条件、要求に従ってサービスを実行した際の結果を示す事後条件、サーバーがサービスを実行するための最大時間を示す処理時間のデッドラインなどを含む。なお、サービスの実行要求を行うアプリケーションをクライアント、実行要求を受けてサービスを実施するアプリケーションをサーバーと呼ぶ。

図３には、サービスの対象がパワーウインドウであって、そのサービスによる操作がパワーウインドウの開閉である場合の、要求時の情報フォーマット、応答時の情報フォーマット、事前条件、事後条件、処理時間のデッドラインの具体例が示されている。なお、クライアントが実行要求を行った場合、サーバーが処理完了の応答を返す前に、要求受付応答を返す。この際、図３に示すように、処理時間のデッドラインに関して、その受付応答時に、サーバーが処理時間のデッドラインをクライアントに与えることもある。この場合には、受付応答時に受け取った処理時間のデッドラインが優先される。

クライアントの要求時の情報フォーマットには、図３に示すように、操作の種類、要求元属性、指示対象、操作パラメータが含まれている。特に、要求元属性として優先度を含んでいるので、複数のクライアントからのサービスの実行要求が競合したときに、いずれの要求に従って制御を行うべきかの調停処理が容易に行いうる。

なお、図３における、要求元属性の「システム外」とは、例えば車外からリモート操作によってパワーウインドウの開閉操作を行う場合に指定されるものである。また、「システム内」とは、車室内に設けられた開閉スイッチが操作されたときに指定されるものである。さらに、「システム内の安全性確保領域内」とは、例えばセキュリティ上の問題から緊急にパワーウインドウを操作する必要がある場合に指定されるものである。この場合「システム内の安全性確保領域内」が最も優先度が高くなる。

また、操作パラメータには、指示開度、動作パターン、および安全度が含まれている。動作パターンとしては、想定される複数のパターン（通常動作パターン、一旦開いてから閉めるパターン、音声、ブザー、灯火類の点滅などによって周辺に動作することを通知した後に動作するパターン）が予め定められており、クライアントは、いずれかの動作パターンを指定して、実行要求を行う。また、安全度により、挟み込み防止動作を行うか否かを指定できるようになっている。

クライアントから要求情報を受けると、サーバーは、処理の完了時に、応答時の情報フォーマットに従って、応答を行う。この応答には、操作の種類および応答パラメータが含まれる。応答パラメータには、要求に対する結果、および処理完了時の窓位置が含まれ、要求に対する結果として、要求に従って動作したか否かを成功、又は失敗によりクライアントに通知する。なお、失敗の場合、その失敗の要因もクライアントに通知する。

クライアントの要求に応じて動作するか否かは、事前条件に基づいてサーバーが判断して決定する。そして、サーバーは、その決定結果を含む応答情報を作成し、サービスインターフェースを介してクライアントに向けて通信する。

上述した要求時の情報や、応答時の情報が、クライアントとしてのアプリケーションとサーバーとしてアプリケーションとの間でやり取りされるときの、サービスインターフェースの各構成要素の役割および具体的な動作について、図１及び図４に基づいて説明する。

サービスインターフェース１４，３３，５２は、インターフェース１５，１７，１９，３４，３６，５３と、プロキシ１６，１８，３７と、スケルトン２０，３５，５４と、メッセージゲートウェイ２１，３８，５５とからなる。

例えば、インターフェースα１５は、サーバーである第４アプリケーションによるサービスＳｅｒｖｉｃｅ１に対応して、電子制御装置１０に設けられたものである。そして、クライアントとしての第１アプリケーション１１から、サーバーとしての第４アプリケーション３１によるサービスＳｅｒｖｉｃｅ１の実行要求が生じたときに、第１アプリケーション１１によって呼び出され、サービスＳｅｒｖｉｃｅ１実行時の要求情報を受け付ける。具体的には、インターフェースα１５などのインターフェースは、図４に示すように、関数によって表され、第１アプリケーション１１は、この関数を呼び出し、当該関数に必要な情報を入力して、インターフェースα１５に与える。すなわち、インターフェースとしての関数によって、第１アプリケーション１１による要求情報が、サービスの実行を指示する機能指示フォーマットに従う機能指示情報となる。

インターフェースα１５は、プロキシα１６と一体となっており、インターフェースα１５における機能指示情報は、プロキシα１６に伝えられる。このプロキシα１６は、機能指示情報を、制御システム内のアプリケーション間の通信に共通使用される共通通信プロトコル用の通信フォーマットに従う共通通信情報に変換する。

具体的には、図４に示すように、インターフェースα１５における関数に基づいて、サービスの種類を示すサービスＩＤ（ｓｅｒｖｉｃｅＩＤ）、操作の種類を示す操作ＩＤ（ｏｐｅｒａｔｉｏｎＩＤ）、クライアントを示すクライアントＩＤ（ｃｌｉｅｎｔＩＤ）、サービスを実行するサーバーを示すターゲットノードＩＤ（ｔａｒｇｅｔＮｏｄｅＩＤ）、通信情報のデータサイズｓｉｚｅ、及び要求内容を示すデータｄａｔａからなる共通通信フォーマットの共通通信情報を生成する。

また、メッセージゲートウェイ２１は、プロキシα１６が通信すべきスケルトンα３５に向けて共通通信情報を通信するものである。図１に示すように、プロキシα１６が電子制御装置１０内に実装され、そのプロキシα１６が通信すべきスケルトンα３５が電子制御装置３０に実装されている場合、プロキシα１６によって変換された共通通信情報は、電子制御装置１０，３０間を接続するネットワークである車内ＬＡＮを介して通信される必要がある。

このため、メッセージゲートウェイ２１は、共通通信情報を、車内ＬＡＮの通信プロトコル（プロトコルＡ）用のネットワーク通信フォーマットに従うネットワーク通信情報に変換する機能も備えている。この車内ＬＡＮの通信プロトコルＡとしては、例えばＩＳＯ標準規格に定められているＣＡＮなどが採用される。図４は、このようなメッセージゲートウェイ２１による通信情報のフォーマットの変換の様子も示している。

メッセージゲートウェイ２１によって変換されたネットワーク通信情報は、ドライバ２３を介して車内ＬＡＮに送信される。このネットワーク通信情報は、当該通信情報に含まれるターゲットノードＩＤに基づいて、電子制御装置３０に受信される。すなわち、ドライバ４１を介して通信情報が取り込まれ、メッセージゲートウェイ３８に与えられる。

この場合、メッセージゲートウェイ３８は、上述した変換処理とは逆に、ネットワーク通信情報を、共通通信情報にフォーマット変換する変換処理を実施するとともに、サービスＩＤもしくはターゲットノードＩＤなどに基づいて、変換した共通通信情報をスケルトンα３５に与える。スケルトンα３５は、上述したプロキシα１６とちょうど逆の処理を行う。すなわち、共通通信フォーマットに従う共通通信情報を、インターフェースα３４における関数のかたちに変換し、インターフェースα３４に与える。すると、その関数を第４アプリケーション３１が読み出すことにより、アプリケーション１１からの要求時の情報を取り込むことができる。

なお、インターフェースα３４の関数は、インターフェースα１５と同一である場合もあるが、異なる場合もある。それは、サーバーである第４アプリケーション３１へのサービスの実行指示フォーマットに依存する。すなわち、第４アプリケーション３１が、操作の種類、操作対象、操作パラメータなどについて、第１アプリケーション１１と同じフォーマットであれば、インターフェースα３４の関数もインターフェースα１５と同一となる。しかし、第４アプリケーション３１が独自のフォーマットを有する場合には、インターフェースα３４における関数を、そのフォーマットに対応したものとする必要がある。いずれの場合であっても、インターフェースは、クライアントアプリケーションからの要求情報を、サーバーアプリケーションに対する機能指示情報にする機能を有する。

また、第４アプリケーション３１が、処理を完了して応答を返す場合には、スケルトンα３５がプロキシとしての役割を果たし、メッセージゲートウェイ３８が共通通信情報をネットワーク通信情報に変換するなど、上述した要求情報の通信時とは、それぞれ逆の処理を行うことになる。

上述した例は、サービスの実行要求を行うクライアントアプリケーション１１と、そのサービスを実際に行うサーバーアプリケーション３１とが、異なる電子制御装置１０，３０に実装されている場合に関するものである。しかし、クライアントアプリケーションとサーバーアプリケーションとが、同一の電子制御装置に実装される場合もある。例えば、図１に示す電子制御装置１０における、第２アプリケーション１２と、第３アプリケーション１３との場合などである。

この場合、メッセージゲートウェイ２１は、プロキシβ１８から共通通信情報を受け取ると、その共通通信情報のまま、プロキシβ１８が通信すべきスケルトンβ２０に向けて、通信情報を送信する。つまり、メッセージゲートウェイ２１は、サービスの種類を示すサービスＩＤ、もしくは各サービスを実行するサーバーアプリケーションを示すターゲットノードＩＤに関連付けて、それらのサーバーアプリケーションが実装された電子制御装置についての情報を記憶しており、その記憶情報に基づいて、通信先を振り分けるのである。

なお、第２アプリケーション１２が、サービスの実行を要求するための要求情報を送信すべきサーバーである第３アプリケーション１３を特定するための情報を有しており、その第３アプリケーション１３に付随するインターフェースβ１９を呼び出すことができる場合には、第３アプリケーション１３に対して、インターフェースβ１９のみを介して、直接的に、要求情報を送信することも可能である。インターフェースβの関数を呼び出すことができれば、その関数を利用して要求情報を直接的に第３アプリケーション１３に伝えることができるためである。

また、図１に示すように、本実施形態は、車内ＬＡＮとして、プロトコルが異なる（プロトコルＡとプロトコルＢ）複数のネットワークを含む場合でも適用可能である。図１に示す例では、電子制御装置１０と３０が、プロトコルＡによる車内ＬＡＮによって接続され、電子制御装置３０と５０が、プロトコルＢによる車内ＬＡＮによって接続された例を示している。

以上、説明したように、本実施形態においては、クライアントアプリケーション及びサーバーアプリケーションが実装された電子制御装置に、それらアプリケーション間に介在して、フォーマットの変換や調停等を行いながら必要な情報の受け渡しを行うサービスアプリケーションを実装した。従って、既存の各アプリケーションに対する影響を最小限に抑えつつ、新たな機能を実現するためのアプリケーションを簡単に追加することができるようになるとともに、既存のアプリケーションの再利用性を高めることができるとの優れた効果を奏することが可能になる。

上述した実施形態は、本発明の好ましい実施形態ではあるが、本発明は、それになんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々の変形が可能である。

例えば、上述した実施形態において、スケルトンとサーバーアプリケーションとの間にインターフェースを設けたが、スケルトンが、そのインターフェースの機能を含むものであっても良い。

また、上述した実施形態において、クライアントアプリケーションが実装された電子制御装置に、当該クライアントアプリケーションがサーバーアプリケーションにサービスの実行要求を行う際の通信先に関する情報を保存し、クライアントアプリケーションからの質問に応じて、その通信先情報をクライアントアプリケーションに与える検索アプリケーションを実装するようにしても良い。これにより、個別のクライアントアプリケーションにおいて、サービスの実行要求を行うために、その通信先に関する情報を個別に保存しておくことが不要になる。

さらに、上述した実施形態では、要求時の情報フォーマットの要求元属性が、優先度とエリアとからなるものであった。そして、優先度は、複数のクライアントアプリケーションからのサービスの実行要求が競合したときに、いずれの要求に従って制御を行うべきかの調停処理を行う際に利用された。

しかしながら、要求元属性のエリアも、いずれのクライアントアプリケーションからの要求を優先すべきか判断する情報となりえる。従って、調停処理は、要求元属性のエリアに基づいて実施しても良い。この場合、「優先度」は、要求時の情報フォーマットから省略しても良い。

本実施形態による車両において構築された制御システムの全体構成を示す構成図である。 車両における各種の車載機器による機能をサービスとして規定した概念を説明するための説明図である。 サービスインターフェースを作成する前提となる、サービスの使用方法を規定した一例を示す図である。 サービスインターフェースの各構成要素の役割および具体的な動作を説明するための説明図である。 （ａ）は新規アプリケーションを追加した場合の従来の制御システムにおける問題点を説明するためのものであり、（ｂ）は、新規アプリケーションを追加した場合でも、既存システムに対する影響を最小限に抑えられる本実施形態による制御システムの概念的特徴を説明するための説明図である。

符号の説明

１０，３０，５０…電子制御装置
１１，１２，３２…クライアントアプリケーション
１３，３１，５１…サーバーアプリケーション
１４，３３，５２…サービスインターフェース
１５，１７，１９，３４，３６，５３…インターフェース
１６，１８，３７…プロキシ
２０，３５，５４…スケルトン
２１、３８，５５…メッセージゲートウェイ

Claims (7)

1. 車両に搭載された複数の電子制御装置が車内ＬＡＮを介して接続され、前記複数の電子制御装置のいずれかにおいて第１のアプリケーションが実行されたとき、当該第１のアプリケーションが、前記複数の電子制御装置のいずれかに実装された第２のアプリケーションに所望の機能を実行させる制御システムであって、
   前記第２のアプリケーションに所望の機能の実行要求を行う際に、前記第１のアプリケーションが指示すべき要求情報のフォーマットが予め定められており、
   前記第１のアプリケーションからの要求情報を受け付けて、当該要求情報を、前記第２のアプリケーションが前記所望の機能を行うための機能指示フォーマットのかたちで、当該第２のアプリケーションに与えるサービスインターフェースをソフトウエアによって構成し、前記複数の電子制御装置の各々に実装したことを特徴とする制御システム。
2. 前記要求情報は、複数のアプリケーションからの実行要求が競合したときに、いずれの実行要求を優先すべきかを判断するための情報を含むことを特徴とする請求項１に記載の制御システム。
3. 前記第２のアプリケーションは、機能指示が与えられると、その機能指示により動作した結果を応答情報として、前記サービスインターフェースを介して前記第１のアプリケーションに与えることを特徴とする請求項１又は請求項２に記載の制御システム。
4. 前記サービスインターフェースは、前記要求情報を前記機能指示に変換するインターフェースを含み、
   前記第１及び第２のアプリケーションが同一の電子制御装置に実装されているとき、前記第１のアプリケーションからの要求情報は、前記インターフェースを介して前記第２のアプリケーションに与えられることを特徴とする請求項１乃至請求項３のいずれかに記載の制御システム。
5. 前記サービスインターフェースは、前記要求情報を前記機能指示に変換するインターフェースと、前記要求情報を前記制御システム内のアプリケーション間の通信に共通使用される共通通信プロトコル用の通信フォーマットに従う共通通信情報に変換するプロキシと、前記共通通信情報を要求情報に変換するスケルトンと、前記プロキシが通信すべきスケルトンに向けて前記共通通信情報を通信するメッセージゲートウェイとを含み、
   前記第１及び第２のアプリケーションが同一の電子制御装置に実装されているとき、前記第１のアプリケーションからの要求情報は、前記プロキシ、前記メッセージゲートウェイ、前記スケルトン、及び前記インターフェースを介して前記第２のアプリケーションに与えられることを特徴とする請求項１乃至請求項３のいずれかに記載の制御システム。
6. 前記第１のアプリケーションと前記第２のアプリケーションとが異なる電子制御装置に実装されているとき、前記第１のアプリケーションを実行する電子制御装置における前記メッセージゲートウェイは、前記共通通信情報を、前記ネットワークの通信に使用されるネットワーク通信プロトコル用の通信フォーマットに従うネットワーク通信情報に変換し、前記第２のアプリケーションを実行する電子制御装置における前記メッセージゲートウェイは、前記ネットワーク通信情報を共通通信情報に変換するとともに、通信先として特定されたスケルトンにその共通通信情報を与えることを特徴とする請求項５に記載の制御システム。
7. 前記第１のアプリケーションが実装された電子制御装置において、前記第１のアプリケーションが前記第２のアプリケーションに所望の機能の実行要求を行うための要求情報の通信先に関する情報を保存し、前記第１のアプリケーションからの要求に応じて、前記通信先情報を第１のアプリケーションに与える検索アプリケーションが実装されることを特徴とする請求項１乃至請求項６のいずれかに記載の制御システム。

Images