JP5966697B2

JP5966697B2 - 情報処理装置

Info

Publication number: JP5966697B2
Application number: JP2012152376A
Authority: JP
Inventors: 田中　啓一; 啓一田中; 三浦　広土; 広土三浦; 健二福地
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2012-07-06
Filing date: 2012-07-06
Publication date: 2016-08-10
Anticipated expiration: 2032-07-06
Also published as: JP2014017588A

Description

本発明は、情報処理装置に関する。

従来、例えば自動車技術分野においては、ＣＡＮ（Controller Area Network）（登録商標）と呼ばれる通信プロトコルが採用されている。このＣＡＮを利用したものとして、車両の動作を制御するＥＣＵ（Electric Control Unit）にＣＡＮバスを介して診断ツールを接続し、診断ツールから診断のための要求メッセージを送信してＥＣＵの動作状態の診断を行うシステムが知られている。

この種のシステムでは、複数の診断ツールが接続される場合は、１つのＥＣＵが各診断ツールからの各要求メッセージを同時に受信する可能性がある。そのため、現在利用されている診断サービスの通信仕様ＩＳＯ１４２３０のプロトコルでは、複数の診断ツールからの要求メッセージを並行して処理するよう要求されている。

一方、次期通信仕様であるＩＳＯ１４２２９のプロトコルでは、処理を簡易にするため、複数の診断ツールのうち優先度（優先順位）の高い診断ツールからの要求メッセージのみを受け付け、この要求メッセージの処理終了後に優先度の低い診断ツールからの要求メッセージを受け付けるよう要求されている。

優先度に応じてＥＣＵの動作状態を診断するものとしては、特許文献１に開示されたマルチタスクシステムが知られている。特許文献１記載のものは、実行可能状態にあるアプリケーションのうち最も優先度の高いアプリケーションを実行させ、優先度の低いアプリケーションは優先度の高いアプリケーションの終了後に実行されるようになっている。

特開２００９−２５１６６３号公報

しかしながら、特許文献１記載のものでは、アプリケーションが終了しているか否かを、定期的または新たな要求メッセージの受け付けごとに確認しなければならないので、ＣＰＵリソースを大量に消費する場合があるという問題があった。

具体的には、ＥＣＵの動作状態の診断を行う際に、例えば、多数のアクチュエータを動作させてその動作結果を求める場合があり、このような場合では、動作状態の確認先が多岐にわたるので、確認先ごとに動作状態を通知する処理が必要となってしまう。そのため、このような状況下においては特許文献１記載のものでは、ＣＰＵリソースを大量に消費してしまうという問題があった。

本発明は、前述のような従来の問題を解決するためになされたもので、ＣＰＵリソースの消費を抑制することができる情報処理装置を提供することを目的とする。

本発明に係る情報処理装置は、上記目的達成のため、（１）車両に搭載され、複数のクライアントに接続され、送信元の識別情報を含み所定のアプリケーションの実行を要求する要求メッセージを前記各クライアントから受信する情報処理装置であって、前記識別情報に基づいて前記要求メッセージを送信したクライアントの優先度を判定する優先度判定手段と、前記車両のイグニッションがオンにされてからその後オフにされ再びオンにされるまでの期間中において前記各クライアントのうち所定の優先度のクライアントからの要求メッセージを受け付けたことを条件に受付履歴を記録する手段と、前記受付履歴が記録されているか否かに基づいていずれのクライアントの要求を許可するかを調停する調停手段と、前記調停手段が許可した要求に係るアプリケーションを実行するアプリケーション実行手段と、を備え、前記調停手段は、前記期間中において、前記受付履歴が記録されていないことを条件に、前記所定の優先度よりも低い低優先度クライアントからの要求を許可し、前記受付履歴が記録されていることを条件に、前記低優先度クライアントからの要求を拒否するものである、構成を有する。

この構成により、本発明に係る情報処理装置は、予め定められた期間中に、所定の優先度のクライアントからの要求メッセージを受信した以降において、所定の優先度よりも低い優先度のクライアントからの要求メッセージに係るアプリケーションを実行する必要がなくなるので、各種アクチュエータ等を駆動させて診断データを求めるアプリケーションが実行されている場合でも、アクチュエータごとに動作状態をクライアントに通知する処理が不要となる。したがって、本発明に係る情報処理装置は、ＣＰＵリソースの消費を抑制することができる。

本発明に係る情報処理装置は、上記目的達成のため、（２）車両に搭載され、複数のクライアントに接続され、送信元の識別情報を含み所定のアプリケーションの実行を要求する要求メッセージを前記各クライアントから受信する情報処理装置であって、前記識別情報に基づいて前記要求メッセージを送信したクライアントの優先度を判定する優先度判定手段と、前記車両のイグニッションがオンにされてからその後オフにされ再びオンにされるまでの期間中において前記各クライアントのうち所定の優先度のクライアントからの要求メッセージを受け付けたことを条件に受付履歴を記録する手段と、前記受付履歴が記録されているか否かに基づいていずれのクライアントの要求を許可するかを調停する調停手段と、前記調停手段が許可した要求に係るアプリケーションを実行するアプリケーション実行手段と、受信した最新の最新要求メッセージの１つ前に受信した直前要求メッセージが前記所定の優先度のクライアントからの予め定められた特定要求メッセージであることを条件に、前記アプリケーション実行手段が前記特定要求メッセージに係る直前実行アプリケーションの実行を完了しているか実行中であるかを確認する実行確認手段と、を備え、前記調停手段は、前記期間中において、前記直前要求メッセージが前記特定要求メッセージでなく前記受付履歴が記録されていないことを条件に、前記所定の優先度よりも低い低優先度クライアントからの要求を許可し、前記直前要求メッセージが前記特定要求メッセージでなく前記受付履歴が記録されていることを条件に、前記低優先度クライアントからの要求を拒否し、前記直前要求メッセージが前記特定要求メッセージであり前記直前実行アプリケーションの実行が完了していることを条件に、前記低優先度クライアントからの要求を許可し、前記直前要求メッセージが前記特定要求メッセージであり前記直前実行アプリケーションが実行中であることを条件に、前記低優先度クライアントからの要求を拒否するものである、構成を有する。

この構成により、本発明に係る情報処理装置は、直前要求メッセージが予め定められた特定要求メッセージである場合に限り、低優先度クライアントからの最新要求メッセージに係るアプリケーションを実行するので、全ての要求メッセージに対してアプリケーションの処理完了を確認するものよりもＣＰＵリソースの消費を抑制することができる。

上記（１）または（２）に記載の情報処理装置において、（３）前記調停手段は、前記低優先度クライアントからの要求メッセージに係るアプリケーションが実行中であることを条件に、前記低優先度クライアントよりも優先度が高い高優先度クライアントからの要求を許可するものであり、前記アプリケーション実行手段は、前記高優先度クライアントの要求に係るアプリケーションを、実行中のアプリケーションと並行して実行するものである、構成を有する。

この構成により、本発明に係る情報処理装置は、低優先度クライアントからの要求メッセージに係るアプリケーションを実行中でも、そのアプリケーションの実行完了を確認することなく、高優先度のクライアントからの最新要求メッセージに係るアプリケーションを並行して実行するので、アプリケーションの処理完了を確認するものよりもＣＰＵリソースの消費を抑制することができる。

本発明によれば、ＣＰＵリソースの消費を抑制することができる情報処理装置を提供することができる。

本発明の第１の実施の形態における車両のブロック構成図である。本発明の第１の実施の形態における第１ＥＣＵのソフトウェア構成図である。本発明の第１の実施の形態におけるＣＡＮプロトコルに従ったフレームの構成説明図である。本発明の第１の実施の形態における第１ＥＣＵの動作の概要を示すタイミングチャートである。本発明の第１の実施の形態における第１ＥＣＵの動作を示すフローチャートである。本発明の第２の実施の形態における第１ＥＣＵのソフトウェア構成図である。本発明の第２の実施の形態における要求判定部および実行確認部の機能を説明するタイミングチャートである。本発明の第２の実施の形態における要求判定部および実行確認部の機能を説明するタイミングチャートである。本発明の第２の実施の形態における第１ＥＣＵの動作を示すフローチャートである。本発明の第２の実施の形態におけるアプリケーション実行部が実行する並行処理の説明図である。

以下、本発明の実施の形態について、図面を参照して説明する。なお、本発明に係る情報処理装置を、複数の診断ツールが接続される車両のＥＣＵに適用した例を挙げる。

（第１の実施の形態）
まず、構成について説明する。

図１に示すように、本発明の実施の形態における車両５０は、クライアント１および２と通信可能に接続され、サーバとしての第１ＥＣＵ１０、第２ＥＣＵ２０および第３ＥＣＵ３０、診断コネクタ５１、無線通信装置５２、ＣＡＮバス５３を備えている。ここで、第１ＥＣＵ１０、第２ＥＣＵ２０および第３ＥＣＵ３０は、それぞれ、本発明に係る情報処理装置を構成する。

クライアント１は、例えば、自動車販売店が使用するサービスツールであって、診断コネクタ５１に接続されるものである。クライアント２は、例えば、公知のＧ−Ｂｏｏｋ（登録商標）のようなテレマティクスサービスのサービスセンタが備えるリモートツールであって、無線通信回線を介して無線通信装置５２に接続されるものである。クライアント１および２は、ＣＡＮバス５３を介し、第１ＥＣＵ１０、第２ＥＣＵ２０および第３ＥＣＵ３０の各動作状態を診断するための要求メッセージを送信するようになっている。

第１ＥＣＵ１０、第２ＥＣＵ２０および第３ＥＣＵ３０は、例えば、エンジンＥＣＵ、変速機ＥＣＵ、バッテリＥＣＵ等として動作するものである。これらのＥＣＵは、ＣＡＮバス５３を介して互いに接続されている。ＣＡＮバス５３には、診断コネクタ５１および無線通信装置５２が接続さている。

次に、第１ＥＣＵ１０のハードウェア構成について説明する。なお、第２ＥＣＵ２０および第３ＥＣＵ３０は、第１ＥＣＵ１０と同様な構成であるので、その説明を省略する。

第１ＥＣＵ１０は、中央演算処理装置としてのＣＰＵ（Central Processing Unit）１１と、プログラム等が記憶されるＲＯＭ（Read Only Memory）１２と、一時的にデータ等が記憶されるＲＡＭ（Random Access Memory）１３と、を備えている。

また、第１ＥＣＵ１０は、各種センサが接続される入力部１４と、ＣＰＵ１１の演算結果に基づいた制御信号を各種アクチュエータに出力する出力部１５と、ＣＡＮバス５３に接続された通信部１７と、各種信号を伝送するバス１８と、を備えている。第１ＥＣＵ１０が、例えば、エンジンＥＣＵである場合は、各種センサとしては、エンジン回転数センサ、スロットル開度センサ等であり、各種アクチュエータとしては、スロットルバルブ、燃料噴射弁等である。

次に、第１ＥＣＵ１０のソフトウェア構成について図２を参照して説明する。

図２に示すように、第１ＥＣＵ１０は、通信処理部１０１、ネットワーク層処理部１０２、セッション層処理部１０３、サービス受付指示部１０４、アプリケーション実行部１０５を備えている。

ここで、ネットワーク層処理部１０２およびセッション層処理部１０３は、それぞれ、ＯＳＩ（Open Systems Interconnection）基本参照モデルで定義される第３層（ネットワーク層）および第５層（セッション層）に対応する信号処理を実行するようになっている。

通信処理部１０１は、ＣＡＮバス５３を経由し、診断コネクタ５１を介してクライアント１と通信し、無線通信装置５２を介してクライアント２と通信するようになっている。

ネットワーク層処理部１０２は、クライアント１および２から受信した診断のためのメッセージを要求メッセージとして組み立て、セッション層処理部１０３に出力するようになっている。

ネットワーク層処理部１０２が出力するＣＡＮプロトコルに従ったフレームは、図３（ａ）に示すようなフォーマットを有しており、フレームを識別するためのＣＡＮ−ＩＤを格納するアービトレーション（調停）フィールド、転送すべきデータを格納するデータフィールドを含む。

ここで、フレーム中のアービトレーションフィールドに格納されるＣＡＮ−ＩＤは、フレームの種類毎に設定され、データの内容やクライアントを識別するために用いられ、さらに、通信における調停において優先度を決めるための番号をも表している。

データフィールドは、Ｎ＿ＰＣＩ（Network Protocol Control Information）およびＮ＿Ｄａｔａ（Network Data）の領域を含む。Ｎ＿Ｄａｔａの領域には、所定のＥＣＵの動作状態を診断するための診断メッセージが格納されるようになっている。

診断メッセージは、図３（ｂ）に示すように、要求メッセージと、要求メッセージに応答する応答メッセージとで構成される。

要求メッセージは、必須のサービスＩＤ（SID）、オプションのサブファンクション（Sub function）、データＩＤ（Data ID）およびデータ（Data）の各領域を含む。サービスＩＤは、要求する診断サービスの大枠を示すものであり、１バイトの識別番号で表される。サブファンクション領域には、要求する診断サービスの詳細が示される１バイトの識別番号が記述される。データＩＤ領域には、要求する診断サービスの対象を示す１〜２バイトのＩＤ番号が記述される。データ領域には、診断サービスの実施に必要なデータが記述される。

応答メッセージは、要求メッセージと同様な構成になっているが、各領域に記述される内容が要求メッセージとは異なっている。応答メッセージにおいては、サービスＩＤの領域には、要求された診断サービスを確認するための識別番号として、要求メッセージのサービスＩＤに「０ｘ４０」を加算した値が記述されるようになっている。サブファンクション領域には、要求されたサブファンクションの値がそのまま記述される。データＩＤ領域には、要求されたデータＩＤの値がそのまま記述される。データ領域には、診断サービスを実施して得られたデータが記述される。

クライアント１および２は、要求メッセージでサービスＩＤを指定することにより、例えば、バッテリＥＣＵに対してバッテリ電圧の測定データを要求したり、所定のＥＣＵに対してアクチュエータの強制駆動や診断専用のルーチンを使った際の動作結果のデータを要求したりすることができる。

図２に戻り、セッション層処理部１０３は、要求メッセージを送信したクライアントの優先度を判定する優先度判定部１０３ａ、アプリケーションの実行を優先度に応じて調停する調停部１０３ｂを備えている。

優先度判定部１０３ａは、要求メッセージに含まれるＣＡＮ−ＩＤに基づいてクライアントの優先度を判定するようになっている。ここで、優先度判定部１０３ａは、本発明に係る優先度判定手段を構成する。本実施の形態では、クライアント１がクライアント２よりも優先度が高いものとする。

調停部１０３ｂは、高優先度のクライアント１から要求メッセージを受け付ける以前は、低優先度のクライアント２からの要求メッセージを受け付け、高優先度のクライアント１から要求メッセージを受け付けた以降は、低優先度のクライアント２からの要求メッセージを受け付けないという調停を行うようになっている。ここで、調停部１０３ｂは、本発明に係る調停手段を構成する。

サービス受付指示部１０４は、要求メッセージに含まれるサービスＩＤを参照して、診断サービスの結果情報の出力や消去、各種アクチュエータの強制駆動、診断専用のルーチン処理の実行等の処理を受け付けて、アプリケーション実行部１０５に指示するようになっている。

アプリケーション実行部１０５は、サービス受付指示部１０４の指示に基づき、診断サービスの情報取得、各アクチュエータの強制駆動、診断専用のルーチン処理等を実行し、その結果のデータを出力するようになっている。ここで、アプリケーション実行部１０５は、本発明に係るアプリケーション実行手段を構成する。

次に、動作について説明する。

最初に、動作の概要について図４に示すタイミングチャートを参照して説明する。なお、図４に示したオペレーションサイクルは、本発明に係る予め定められた期間に対応し、ＩＳＯ１４２２９の仕様書に記載された「operation cycles」に相当するものである。本実施の形態では、イグニッションがオンにされてからその後オフにされ再びオンにされるまでの期間をオペレーションサイクルとする。

図４に示すように、オペレーションサイクルＡにおいて、クライアント１が要求メッセージ１を第１ＥＣＵ１０に送信すると、要求メッセージ１は、通信処理部１０１およびネットワーク層処理部１０２を経由してセッション層処理部１０３に送られる。セッション層処理部１０３は、クライアント１および２のうちで優先度が高いクライアント１からの要求メッセージを受け付けたことを示す受付履歴を記録する。この受付履歴には、例えば、クライアント１から要求メッセージを受け付けたことを示すデータ、要求メッセージに含まれるサービスＩＤ、データＩＤ等のデータが記録される。

セッション層処理部１０３は、要求メッセージ１をサービス受付指示部１０４に送信し、サービス受付指示部１０４は、要求メッセージ１に含まれるサービスＩＤに基づいてアプリケーション実行部１０５にアプリケーションを実行処理させる。

アプリケーション実行部１０５は、要求メッセージ１に含まれるサービスＩＤによって特定される診断サービスを実施するためのアプリケーション（以下、「要求メッセージ１に係るアプリケーション」という。）の処理を受け付けたことを示す応答メッセージ１をサービス受付指示部１０４に送信し、要求メッセージ１に係るアプリケーションを実行処理する。応答メッセージ１は、最終的にはクライアント１が受信する。

その後、オペレーションサイクルＡにおいて、クライアント１よりも優先度が低いクライアント２が要求メッセージを送信した場合について説明する。

クライアント２が、アプリケーション実行部１０５の実行処理が終了していない期間に、要求メッセージ２を送信した場合は、セッション層処理部１０３は、高優先度のクライアント１の受付履歴が既に記録されているので、要求メッセージ２を受け付けないという調停を行う。すなわち、要求メッセージ２に係るアプリケーションは、アプリケーション実行部１０５によって実行されない。

また、クライアント２が、アプリケーション実行部１０５の実行処理が終了した後に、要求メッセージ３を送信した場合でも、高優先度のクライアント１の受付履歴が既に記録されているので、要求メッセージ３を受け付けないという調停を行う。

なお、セッション層処理部１０３は、クライアント１の受付履歴が記録された以降において、その受付履歴に記録されたサービスＩＤ、データＩＤと異なるサービスＩＤ、データＩＤがクライアント２からの要求メッセージに含まれていたとしても、クライアント２からの要求メッセージは受け付けない。

オペレーションサイクルＡが終了し、その後のオペレーションサイクルＢにおいて、クライアント２が、要求メッセージ４を送信した場合は、セッション層処理部１０３は、高優先度のクライアント１の受付履歴が記録されていないので、調停処理は行わない。したがって、アプリケーション実行部１０５は、例えば、要求メッセージ４に係る処理を受け付けたことを示す応答メッセージ４をサービス受付指示部１０４に送信し、要求メッセージ４に係るアプリケーションを実行処理する。応答メッセージ４は、最終的にはクライアント２が受信する。

次に、図５に示すフローチャートを参照して動作を説明する。

ＣＰＵ１１は、オペレーションサイクルが開始されたか否かを判断する（ステップＳ１１）。ＣＰＵ１１は、オペレーションサイクルが開始されたと判断しなかった場合は、ステップＳ１１を繰り返す。

一方、ＣＰＵ１１は、オペレーションサイクルが開始されたと判断した場合は、クライアント１または２から要求メッセージを受信したか否かを判断する（ステップＳ１２）。

ステップＳ１２において、ＣＰＵ１１は、要求メッセージを受信したと判断した場合は、要求メッセージに含まれるＣＡＮ−ＩＤに基づいて、要求メッセージを送信した送信元のクライアントを示す送信元データをＲＡＭ１３に記録する（ステップＳ１３）。この送信元データは、例えば、特定ビットのオン、オフで表され、要求メッセージを受信するたびに更新される。

ＣＰＵ１１は、要求メッセージに含まれるＣＡＮ−ＩＤに基づいて、要求メッセージを送信した送信元のクライアントの優先度を判定する（ステップＳ１４）。

ステップＳ１４において、要求メッセージの送信元が高優先度のクライアント１である場合は、ＣＰＵ１１は受付履歴のデータをＲＡＭ１３に記録する（ステップＳ１５）。

一方、ステップＳ１４において、要求メッセージの送信元が低優先度のクライアント２である場合は、ＣＰＵ１１は、高優先度のクライアント１の受付履歴が記録されているか否かを判断する（ステップＳ１６）。

ステップＳ１６において、ＣＰＵ１１は、高優先度のクライアント１の受付履歴が記録されていると判断した場合は、調停を実行し（ステップＳ１７）、ステップＳ１２に戻る。すなわち、ＣＰＵ１１は、クライアント１の受付履歴が記録されている場合は、クライアント２からの要求メッセージは受け付けない。

ＣＰＵ１１は、ステップＳ１５で受付履歴を記録した後、およびステップＳ１６で受付履歴が記録されていないと判断した場合は、要求メッセージに係るアプリケーションの処理を実行し（ステップＳ１８）、応答メッセージを送信する（ステップＳ１９）。

ＣＰＵ１１は、オペレーションサイクルが終了したか否かを判断し（ステップＳ２０）、オペレーションサイクルが終了したと判断した場合は処理を終了し、オペレーションサイクルが終了したと判断しなかった場合はステップＳ１２に戻る。

以上のように、本実施の形態における第１ＥＣＵ１０は、１つのオペレーションサイクルにおいて、高優先度のクライアント１から要求メッセージを受け付けると受付履歴を記録し、それ以降に受信した低優先度のクライアント２からの要求メッセージは受け付けない構成としたので、例えば、各種アクチュエータ等を駆動させて診断データを求める場合でも、アクチュエータごとに動作状態をクライアント１または２に通知する処理が不要となる。

したがって、本発明における第１ＥＣＵ１０は、ＣＰＵリソースの消費を抑制することができる。

なお、前述の実施の形態では、クライアントの個数を２つとして説明したが、本発明はこれに限定されない。例えば、クライアントが３つ以上の場合で、それぞれに異なる優先度を持たせる場合は、それぞれの受信履歴を残し、所定の優先度よりも低い優先度のクライアントからの要求メッセージを受け付けない構成とすることにより、前述と同様の効果が得られる。

（第２の実施の形態）
まず、構成について説明する。

本実施の形態における第１ＥＣＵ４０のハードウェア構成は、第１の実施の形態（図１）における第１ＥＣＵ１０と同様であるので図示を省略し、ソフトウェア構成について図６を参照して説明する。なお、第１の実施の形態と同様な構成には同一の番号を付して、その説明を省略する。

図６に示すように、本実施の形態における第１ＥＣＵ４０は、セッション層処理部１０６を備えている。このセッション層処理部１０６は、優先度判定部１０３ａおよび調停部１０３ｂに加えて、要求判定部１０６ａおよび実行確認部１０６ｂを備えている。

要求判定部１０６ａは、受信した要求メッセージに含まれるサービスＩＤに基づいて、受信した要求メッセージが予め定められた特定要求メッセージであるか否かを判定するようになっている。この特定要求メッセージは、予め定められた特定のサービスＩＤを含むものである。特定のサービスＩＤは、例えば、アクチュエータの強制駆動や診断専用のルーチンを使った診断サービス（以下「ＩＤ駆動の診断サービス」という。）を要求するためのサービスＩＤである。

実行確認部１０６ｂは、要求メッセージが特定要求メッセージであると要求判定部１０６ａが判定した後、次に要求メッセージを受信した場合に、アプリケーション実行部１０５が、直前に受信した特定要求メッセージに係るアプリケーションの実行を完了しているか実行中であるかを確認するようになっている。ここで、実行確認部１０６ｂは、本発明に係る実行確認手段を構成する。

要求判定部１０６ａおよび実行確認部１０６ｂの機能について図７、図８を参照して説明する。なお、図７、図８において、第１ＥＣＵ４０のソフトウェア構成のうち、セッション層処理部１０６、アプリケーション実行部１０５のみを図示し、他の図示は省略している。

図７は、クライアント１が要求メッセージ１１を送信し、アプリケーション実行部１０５では、要求メッセージ１１に係る処理を実行して応答メッセージ１１を返信した状態を示している。図示のように、セッション層処理部１０６が要求メッセージ１１を受け付けて応答メッセージ１１を送信するまでの間に、クライアント２が要求メッセージ１２を送信しても、セッション層処理部１０６の調停部１０３ｂは、クライアント２がクライアント１よりも優先度が低いので、要求メッセージ１２に係るアプリケーションを実行しないよう調停を行う。

実際の車両においては、図７に示した状態で、低優先度のクライアント２からの要求メッセージが受け付けされない場合がほとんどである。ここで、サービスＩＤが、例えば、単にデータを読み出す診断サービスを要求するものであれば、アプリケーション実行部１０５が応答メッセージを返した時点でその処理が完了したと判断できる。しかしながら、サービスＩＤが、ＩＤ駆動の診断サービスを要求するものである場合は、アプリケーション実行部１０５は、その処理の完了ではなく、処理を受け付けた時点で応答メッセージを送信するよう規格で規定されているので、応答メッセージが返った時点ではいつ処理が終了するかを知ることはできない。

そこで、要求判定部１０６ａが、受信した要求メッセージに含まれるサービスＩＤに基づいて、ＩＤ駆動の診断サービスを要求する要求メッセージ（特定要求メッセージ）であるか否かを判定する構成としている。そして、要求判定部１０６ａが、特定要求メッセージであると判定した場合は、特定要求メッセージの次に要求メッセージを受信した際に、実行確認部１０６ｂが、特定要求メッセージに係るアプリケーションの実行処理が完了したか否かを確認するようになっている。

具体的には、図８において、クライアント１から要求メッセージ１３が送信され、セッション層処理部１０６の要求判定部１０６ａがそのサービスＩＤを参照した結果、要求メッセージ１３がＩＤ駆動の診断サービスを要求する特定要求メッセージであると判定したものとする。この場合、次の要求メッセージを受信すると、セッション層処理部１０６の実行確認部１０６ｂは、直前の特定要求メッセージに係るアプリケーションの実行処理が完了したか否かを確認する。

例えば、特定要求メッセージである要求メッセージ１３に続いて、クライアント２が要求メッセージ１４を送信した場合は、実行確認部１０６ｂは、特定要求メッセージに係るアプリケーションの実行処理が完了していないと判定するので、セッション層処理部１０６の調停部１０３ｂは、要求メッセージ１４を受け付けないという調停を行う。

一方、特定要求メッセージである要求メッセージ１３に続いて、クライアント２が要求メッセージ１５を送信した場合は、実行確認部１０６ｂは、直前の特定要求メッセージに係るアプリケーションの実行処理が完了していると判定するので、調停部１０３ｂは調停を行わず、要求メッセージ１５に係るアプリケーションが実行される。

次に、図９に示すフローチャートを参照して動作を説明する。なお、第１の実施の形態と同様なステップには同一の番号を付して、その説明を省略する。

ステップＳ１４において、ＣＰＵ１１は、要求メッセージの送信元が高優先度のクライアント１であると判定した場合は、ステップＳ１５において受付履歴を記録した後、要求メッセージに含まれるサービスＩＤ（SID）のデータをＲＡＭ１３に記録する（ステップＳ２１）。

一方、ステップＳ１４において、ＣＰＵ１１は、要求メッセージの送信元が低優先度のクライアント２であると判定した場合は、直前に受信した要求メッセージのサービスＩＤのデータをＲＡＭ１３から読み出す（ステップＳ２２）。

ＣＰＵ１１は、読み出したサービスＩＤに基づいて、直前に受信した要求メッセージが特定要求メッセージであるか否かを判断する（ステップＳ２３）。

ステップＳ２３において、ＣＰＵ１１は、直前に受信した要求メッセージが特定要求メッセージであると判断した場合は、その特定要求メッセージに係るアプリケーションの処理が完了したか否かを判断する（ステップＳ２４）。

ステップＳ２４において、ＣＰＵ１１は、特定要求メッセージに係るアプリケーションの処理が完了したと判断した場合は、ステップＳ２１に進む。

前述のステップＳ２３において、ＣＰＵ１１は、直前に受信した要求メッセージが特定要求メッセージであると判断しなかった場合は、ステップＳ１６の受付履歴が記録されているか否かを判断する。

ステップＳ１６において、ＣＰＵ１１は、受付履歴が記録されていると判断した場合、およびステップＳ２４において、特定要求メッセージに係るアプリケーションの処理が完了したと判断しなかった場合は、ステップＳ１７に進み、調停を実行する。

ステップＳ１６において、ＣＰＵ１１は、受付履歴が記録されていると判断しなかった場合は、ステップＳ２１に進む。

ところで、ステップＳ１８において、クライアント２の要求メッセージに係るアプリケーションの処理中に、クライアント１の要求メッセージに係るアプリケーションの処理が実行される場合がある。図１０を用いて説明する。

図１０において、クライアント２が要求メッセージ１６を送信し、アプリケーション実行部１０５において要求メッセージ１６に係るアプリケーションの実行中に、クライアント１が要求メッセージ１７を送信した場合が示されている。この場合、図９に示したステップＳ１４において優先度が判定され、クライアント１の方がクライアント２よりも優先度が高いので、アプリケーション実行部１０５においては、要求メッセージ１７に係るアプリケーションが、要求メッセージ１６に係るアプリケーションと並行して実行されることとなる。なお、図１０に示したアプリケーション実行部１０５による並行処理は、第１の実施の形態における第１ＥＣＵ１０においても前述の説明と同様に実施可能である。

以上のように、本実施の形態における第１ＥＣＵ４０は、高優先度のクライアント１から要求メッセージを受信し、その次の要求メッセージを低優先度のクライアント２から受信した場合に、クライアント１から要求メッセージが特定要求メッセージである場合に限り、その特定要求メッセージに係るアプリケーションの処理完了を確認する構成としたので、全ての要求メッセージに対してアプリケーションの処理完了を確認するものよりもＣＰＵリソースの消費を抑制することができる。

また、本実施の形態における第１ＥＣＵ４０は、低優先度のクライアント２からの最新要求メッセージに係るアプリケーションを実行中でも、そのアプリケーションの実行完了を確認することなく、高優先度のクライアント１からの最新要求メッセージに係るアプリケーションを並行して実行するので、アプリケーションの処理完了を確認するものよりもＣＰＵリソースの消費を抑制することができる。

以上説明したように、本発明に係る情報処理装置は、ＣＰＵリソースの消費を抑制することができるという効果を有し、複数の診断ツールが接続される車両のＥＣＵ等として有用である。

１、２クライアント
１０、４０第１ＥＣＵ（情報処理装置）
１１ＣＰＵ
１４入力部
１５出力部
１７通信部
２０第２ＥＣＵ（情報処理装置）
３０第３ＥＣＵ（情報処理装置）
５１診断コネクタ
５２無線通信装置
５３ＣＡＮバス
１０１通信処理部
１０２ネットワーク層処理部
１０３、１０６セッション層処理部
１０３ａ優先度判定部（優先度判定手段）
１０３ｂ調停部（調停手段）
１０４サービス受付指示部
１０５アプリケーション実行部（アプリケーション実行手段）
１０６ａ要求判定部
１０６ｂ実行確認部（実行確認手段）

Claims

車両に搭載され、複数のクライアントに接続され、送信元の識別情報を含み所定のアプリケーションの実行を要求する要求メッセージを前記各クライアントから受信する情報処理装置であって、
前記識別情報に基づいて前記要求メッセージを送信したクライアントの優先度を判定する優先度判定手段と、
前記車両のイグニッションがオンにされてからその後オフにされ再びオンにされるまでの期間中において前記各クライアントのうち所定の優先度のクライアントからの要求メッセージを受け付けたことを条件に受付履歴を記録する手段と、
前記受付履歴が記録されているか否かに基づいていずれのクライアントの要求を許可するかを調停する調停手段と、
前記調停手段が許可した要求に係るアプリケーションを実行するアプリケーション実行手段と、
を備え、
前記調停手段は、前記期間中において、
前記受付履歴が記録されていないことを条件に、前記所定の優先度よりも低い低優先度クライアントからの要求を許可し、
前記受付履歴が記録されていることを条件に、前記低優先度クライアントからの要求を拒否するものである、
ことを特徴とする情報処理装置。
車両に搭載され、複数のクライアントに接続され、送信元の識別情報を含み所定のアプリケーションの実行を要求する要求メッセージを前記各クライアントから受信する情報処理装置であって、
前記識別情報に基づいて前記要求メッセージを送信したクライアントの優先度を判定する優先度判定手段と、
前記車両のイグニッションがオンにされてからその後オフにされ再びオンにされるまでの期間中において前記各クライアントのうち所定の優先度のクライアントからの要求メッセージを受け付けたことを条件に受付履歴を記録する手段と、
前記受付履歴が記録されているか否かに基づいていずれのクライアントの要求を許可するかを調停する調停手段と、
前記調停手段が許可した要求に係るアプリケーションを実行するアプリケーション実行手段と、
受信した最新の最新要求メッセージの１つ前に受信した直前要求メッセージが前記所定の優先度のクライアントからの予め定められた特定要求メッセージであることを条件に、前記アプリケーション実行手段が前記特定要求メッセージに係る直前実行アプリケーションの実行を完了しているか実行中であるかを確認する実行確認手段と、
を備え、
前記調停手段は、前記期間中において、
前記直前要求メッセージが前記特定要求メッセージでなく前記受付履歴が記録されていないことを条件に、前記所定の優先度よりも低い低優先度クライアントからの要求を許可し、
前記直前要求メッセージが前記特定要求メッセージでなく前記受付履歴が記録されていることを条件に、前記低優先度クライアントからの要求を拒否し、
前記直前要求メッセージが前記特定要求メッセージであり前記直前実行アプリケーションの実行が完了していることを条件に、前記低優先度クライアントからの要求を許可し、
前記直前要求メッセージが前記特定要求メッセージであり前記直前実行アプリケーションが実行中であることを条件に、前記低優先度クライアントからの要求を拒否するものである、
ことを特徴とする情報処理装置。
前記調停手段は、前記低優先度クライアントからの要求メッセージに係るアプリケーションが実行中であることを条件に、前記低優先度クライアントよりも優先度が高い高優先度クライアントからの要求を許可するものであり、
前記アプリケーション実行手段は、前記高優先度クライアントの要求に係るアプリケーションを、実行中のアプリケーションと並行して実行するものである、
ことを特徴とする請求項１または請求項２に記載の情報処理装置。