JP2018095142A - 車載制御装置 - Google Patents

Abstract

【課題】診断処理を実行するアプリケーションが複数搭載された車載制御装置において、応答バッファを減らす。【解決手段】Ｓ３０３で、ダイアグ・通信制御アプリケーションは、診断処理を実行する診断アプリケーションを選択し、Ｓ３０４で、選択した診断アプリケーションに診断処理を実行させ、Ｓ３０５で、ダイアグデータ領域に格納されている診断処理を実行した結果を、返信データとして診断装置に送信する送信処理を行う。送信処理において、返信データは応答バッファに一時的に格納される。ダイアグ・通信制御アプリケーションは、次に診断処理を実行する診断アプリケーションを選択し、Ｓ３０４からＳ３０７までの処理を実行する。このようにして、複数の診断アプリケーションに、順に診断処理を実行させる、機能的要求に対するダイアグ制御処理が実行される。【選択図】図４

Description

本開示は、車載制御装置に関する。

特許文献１に記載のように、車両に搭載された車載制御装置が、車両の外部又は内部の診断装置からの要求に応じて、故障している部品の確認など、車両の状態の診断処理を実行する技術が知られている。診断処理は、車載制御装置に搭載されたアプリケーションによって実行される。すなわち、診断装置から診断メッセージが受信されると、アプリケーションによって診断処理が実行され、その結果が診断メッセージに対する返信データとして診断装置に送信される。車載制御装置は、データ送信処理のための応答バッファを有しており、アプリケーションにより応答バッファに格納された返信データが診断装置に送信される。

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

このような診断処理の技術において、診断処理を実行するアプリケーションは、１つの車載装置について１つのみ搭載されることが通常である。ところが、近年では、車両に搭載されている複数の車載制御装置を１つに統合し、１つの車載制御装置に、診断処理を実行するアプリケーションを複数搭載する技術のニーズがある。しかしながら、単純に１つの車載制御装置に複数のアプリケーションを集約すると、アプリケーションの数の分だけ応答バッファを設ける必要があった。

本開示の一局面は、診断処理を実行するアプリケーションが複数搭載された車載制御装置において、応答バッファを減らすことを目的としている。

本開示の一態様は、車両に搭載され、診断装置（２００）からの診断メッセージに対する診断処理を実行する車載制御装置（１００）であって、第１の処理部（１０１）と、第２の処理部（１０２）と、管理実行部（１０３）と、を備える。第１の処理部は、第１の診断処理を実行する。第２の処理部は、第２の診断処理を実行する。管理実行部は、診断メッセージを受信した場合、第１の処理部及び第２の処理部のうち少なくとも一方に診断処理を実行させる。具体的には、管理実行部は、単独実行部（Ｓ１０１〜Ｓ１０５）と、直列実行部（Ｓ３０３〜Ｓ３０７，Ｓ５０４〜Ｓ５０８）と、を備える。単独実行部は、第１の処理部を指定した診断メッセージを受信した場合、第１の処理部に診断処理を実行させ、第２の処理部を指定した診断メッセージを受信した場合、第２の処理部に診断処理を実行させる。直列実行部は、第１の処理部及び第２の処理部の両方を指定した診断メッセージを受信した場合、第１の処理部及び第２の処理部に順に診断処理を実行させる。

このような構成によれば、第１の処理部が応答バッファを使用する期間と、第２の処理部が応答バッファを使用する期間とがずれるため、第１の処理部及び第２の処理部が１つの応答バッファを共有して診断処理を実行することができる。このため、第１の処理部及び第２の処理部それぞれに対して応答バッファを設ける必要がなく、診断処理を実行するアプリケーションが複数搭載された車載制御装置において、応答バッファを減らすことが可能となる。

第１実施形態の車載制御装置の構成を示すブロック図である。 物理的要求に対する診断処理のフローチャートである。 物理的要求に対する診断処理のシーケンス図である。 第１実施形態の機能的要求に対する診断処理のフローチャートである。 第１実施形態の機能的要求に対する診断処理のシーケンス図である。 第２実施形態の機能的要求に対する診断処理のフローチャートである。 診断メッセージに含まれる診断の種類とそのデータ長を表す図である。

以下、本開示の例示的な実施形態について図面を参照しながら説明する。
［１．第１実施形態］
［１−１．構成］
図１に示す第１実施形態の車載制御装置１００は、図示しない車両に搭載されている複数の電子制御装置のうちの１つであって、マイコン１、入出力回路２、センサ３、アクチュエータ４及び通信部５を備える。

マイコン１は、ＲＯＭ１０、ＲＡＭ２０、ＣＰＵ３０、Ｉ／Ｏ４０、データフラッシュ５０及びタイマ６０を備えたマイクロコンピューターである。
ＲＯＭ１０は、種々のプログラム等を記憶している記憶媒体である。ＲＯＭ１０には、後述する各処理を実行するためのプログラムとして、第１の診断アプリケーション１０１、第２の診断アプリケーション１０２及びダイアグ・通信制御アプリケーション１０３が記憶されている。

ＲＡＭ２０は、ＣＰＵ３０が種々のプログラムを実行するためのデータを一時的に記憶するための記憶媒体である。ＲＡＭ２０には、各種データを記憶するための記憶領域として、ダイアグデータ領域２０１、要求バッファ２０２、応答バッファ２０３及び通信タイマ領域２０４が確保されている。ダイアグデータ領域２０１は、後述する診断処理を実行した結果を格納するための領域である。要求バッファ２０２及び応答バッファ２０３は、後述する診断装置２００との間で送受信されるデータを、送受信処理のために一時的に格納する領域である。通信タイマ領域２０４は、後述する計時処理を実行する際に使用する領域である。

ＣＰＵ３０は、ＲＯＭ１０に記憶されているプログラムに従い種々の処理を実行する。
Ｉ／Ｏ４０は、マイコン１の外部から信号を入力し、マイコン１の外部へ信号を出力するための回路である。

入出力回路２は、マイコン１と、センサ３、アクチュエータ４及び通信部５と、の間での通信を可能とするための回路である。通信部５には、車両の診断を車載制御装置１００に要求する診断装置２００が着脱可能に接続される。

ここで、診断装置２００の概要について説明する。診断装置２００は、車両の外部から電子制御装置と通信を行い、異常の有無を診断するための装置である。診断装置２００は、診断処理を要求するメッセージである診断メッセージを電子制御装置に送信し、診断処理を実行した結果を返信データとして電子制御装置から受信することによって、車両の故障の有無を診断する。電子制御装置では、診断メッセージが受信されると、アプリケーションにより診断処理が実行され、返信データが送信される。診断処理の要求対象となる単位は、電子制御装置ではなく、診断処理を実行可能なアプリケーションである。本実施形態の車載制御装置１００の場合、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２のそれぞれが診断処理の要求対象となる。

診断装置２００が車載制御装置１００に要求する診断メッセージは、物理的要求と、機能的要求との２種類に分類される。物理的要求は、１つのアプリケーションを宛先として指定した診断メッセージである。つまり、診断装置２００から物理的要求としての診断メッセージが送信されると、宛先として指定された１つのアプリケーションのみが診断処理を実行する。一方、機能的要求は、複数のアプリケーションを宛先として指定した診断メッセージである。つまり、診断装置２００から機能的要求としての診断メッセージが送信されると、宛先として指定された複数のアプリケーションが診断処理を実行する。

［１−２．ダイアグ制御処理の概要］
次に、第１実施形態のダイアグ制御処理の概要について説明する。ダイアグ制御処理は、ＣＰＵ３０がダイアグ・通信制御アプリケーション１０３に従い実行する処理である。ダイアグ制御処理は、診断装置２００が診断メッセージを車載制御装置１００に送信することで開始される。診断メッセージには、診断装置２００が要求する診断処理を実行するアプリケーションの宛先であるターゲットアドレスと、要求する診断の種類を表すデータである種類データと、診断に必要なデータと、が含まれている。

まず、第１の診断アプリケーション１０１又は第２の診断アプリケーション１０２を宛先として指定した、物理的要求としての診断メッセージを車載制御装置１００が受信した場合のダイアグ制御処理について、図２を用いて説明する。Ｓ１０１で、ダイアグ・通信制御アプリケーション１０３は、診断装置２００から診断メッセージを受信する受信処理を行う。受信処理において、診断メッセージは、要求バッファ２０２に格納される。

次に、Ｓ１０２で、ダイアグ・通信制御アプリケーション１０３は、計時処理を開始する。計時処理は、診断装置２００のタイムアウトを防ぐために行われる。すなわち、診断装置２００は、診断メッセージを送信してからあらかじめ設定した時間を過ぎても車載制御装置１００からデータを受信しない場合、車載制御装置１００との通信を中断するタイムアウトの機能を有する。このような通信の中断を防ぐため、ダイアグ・通信制御アプリケーション１０３は、計時処理を行い、一定の時間を過ぎても診断処理が完了しない場合、通信を中断させないための待機応答データを診断装置２００に送信する。

次に、Ｓ１０３で、ダイアグ・通信制御アプリケーション１０３は、ターゲットアドレスが示す診断アプリケーションに診断処理を実行させる。診断アプリケーションが診断処理を実行した結果は、ダイアグデータ領域２０１に格納される。

次に、Ｓ１０４で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。

次に、Ｓ１０５で、ダイアグ・通信制御アプリケーション１０３は、計時処理を終了する。このようにして、物理的要求に対して、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２のうちいずれか一方に診断処理を単独で実行させるダイアグ制御処理が実行される。

次に、第１の診断アプリケーション１０１又は第２の診断アプリケーション１０２を宛先として指定した、物理的要求に対するダイアグ制御処理において車載制御装置１００と診断装置２００との間で行われる具体的なやりとりの例について図３のシーケンス図を用いて説明する。なお、図３では、物理的要求に対してＣＰＵ３０が実行するアプリケーションである第１の診断アプリケーション１０１、第２の診断アプリケーション１０２及びダイアグ・通信制御アプリケーション１０３と、診断装置２００とのやりとりを表し、ＣＰＵ３０については図示を省略する。

Ｓ２０１で、ダイアグ・通信制御アプリケーション１０３は、第１の診断アプリケーション１０１を宛先として指定した、物理的要求としての診断メッセージを受信する受信処理を行う。受信処理で受信された診断メッセージは、要求バッファ２０２に一時的に格納される。

Ｓ２０２で、ダイアグ・通信制御アプリケーション１０３は、第１の診断アプリケーション１０１に診断処理を実行させる。
Ｓ２０３で、第１の診断アプリケーション１０１は、診断メッセージに応じた診断処理を実行し、その結果をダイアグデータ領域２０１に格納する。

Ｓ２０４で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。

Ｓ２０５で、ダイアグ・通信制御アプリケーション１０３は、第２の診断アプリケーション１０２を宛先として指定した、物理的要求としての診断メッセージを受信する受信処理を行う。受信処理で受信された診断メッセージは、要求バッファ２０２に一時的に格納される。

Ｓ２０６で、ダイアグ・通信制御アプリケーション１０３は、第２の診断アプリケーション１０２に診断処理を実行させる。
Ｓ２０７で、第２の診断アプリケーション１０２は、診断メッセージに応じた診断処理を実行し、その結果をダイアグデータ領域２０１に格納する。

Ｓ２０８で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。このようにして、物理的要求に対するダイアグ制御処理において車載制御装置１００と診断装置２００との間で具体的なやりとりが行われる。

次に、少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を宛先として指定した、機能的要求としての診断メッセージを車載制御装置１００が受信した場合のダイアグ制御処理について、図４を用いて説明する。なお、ここでいう診断メッセージには、他の宛先、例えば車載制御装置１００以外の電子制御装置のアプリケーションを指定した宛先、が含まれていてもよい。また、機能的要求としての診断メッセージを受信した場合のダイアグ制御処理は、物理的要求としての診断メッセージを受信した場合のダイアグ制御処理における処理の流れと基本的に同じである。このため、物理的要求としての診断メッセージを受信した場合と同じ処理については説明を省略する。

Ｓ３０１で、ダイアグ・通信制御アプリケーション１０３は、診断装置２００から診断メッセージを受信する受信処理を行う。受信処理において、診断メッセージは、要求バッファ２０２に格納される。次に、Ｓ３０２で、ダイアグ・通信制御アプリケーション１０３は、すべての診断アプリケーション、この例では、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２のそれぞれについて計時処理を開始する。すなわち、ダイアグ・通信制御アプリケーション１０３は、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２のうち少なくとも一方による診断処理が一定の時間を過ぎても完了しない場合、待機応答データを診断装置２００に送信する。

次に、Ｓ３０３で、ダイアグ・通信制御アプリケーション１０３は、診断処理を実行する診断アプリケーションを選択する。すなわち、診断処理は、１つずつ順に実行される。診断処理の順番、換言すれば診断アプリケーションが選択される順番は、あらかじめ決められている。この例では、宛先として指定されたすべての診断アプリケーションのうち、ターゲットアドレスが若い順に選択され、第２の診断アプリケーション１０２よりもターゲットアドレスが若い第１の診断アプリケーション１０１が先に選択される。

次に、Ｓ３０４で、ダイアグ・通信制御アプリケーション１０３は、選択した診断アプリケーションに診断処理を実行させ、その結果は、ダイアグデータ領域２０１に格納される。

次に、Ｓ３０５で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。

次に、Ｓ３０６で、ダイアグ・通信制御アプリケーション１０３は、選択した診断アプリケーションに対する計時処理を終了する。
次に、Ｓ３０７で、ダイアグ・通信制御アプリケーション１０３は、宛先として指定されたすべての診断アプリケーションの診断処理が完了したか否かを判定する。ダイアグ・通信制御アプリケーション１０３は、すべての診断アプリケーションの診断処理が完了していないと判定した場合、処理をＳ３０３に移行する。そして、Ｓ３０３で、ダイアグ・通信制御アプリケーション１０３は、次に診断処理を実行する診断アプリケーション、この例では第２の診断アプリケーション１０２、を選択し、Ｓ３０４からＳ３０７までの処理を実行する。このようにして、ダイアグ・通信制御アプリケーション１０３は、宛先として指定されたすべての診断アプリケーションの診断処理が完了するまで、処理を繰り返す。

一方、Ｓ３０７で、ダイアグ・通信制御アプリケーション１０３は、すべての診断処理が完了したと判定した場合、処理を終了する。このようにして、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に、順に、換言すれば直列に、診断処理を実行させる、機能的要求に対するダイアグ制御処理が実行される。

次に、少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を宛先として指定した、機能的要求に対するダイアグ制御処理において車載制御装置１００と診断装置２００との間で行われる具体的なやりとりの例について図５のシーケンス図を用いて説明する。なお、図５でも、図３と同様、ＣＰＵ３０については図示を省略する。

Ｓ４０１で、ダイアグ・通信制御アプリケーション１０３は、少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を宛先として指定した、機能的要求としての診断メッセージを受信する受信処理を行う。受信処理で受信された診断メッセージは、要求バッファ２０２に一時的に格納される。

Ｓ４０２で、ダイアグ・通信制御アプリケーション１０３は、ターゲットアドレスが若い診断アプリケーション、この例では第１の診断アプリケーション１０１、を先に選択し、第１の診断アプリケーション１０１に診断処理を実行させる。

Ｓ４０３で、第１の診断アプリケーション１０１は、診断メッセージに応じた診断処理を実行し、その結果をダイアグデータ領域２０１に格納する。
Ｓ４０４で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。

Ｓ４０５で、ダイアグ・通信制御アプリケーション１０３は、ターゲットアドレスが次に若い診断アプリケーションである第２の診断アプリケーション１０２を選択し、第２の診断アプリケーション１０２に診断処理を実行させる。

Ｓ４０６で、ダイアグ・通信制御アプリケーション１０３は、第２の診断アプリケーションによる診断処理が一定の時間を過ぎても完了しないため、待機応答データを診断装置２００に送信する。

Ｓ４０７で、第２の診断アプリケーション１０２は、診断メッセージに応じた診断処理を実行した結果をダイアグデータ領域２０１に格納する。
Ｓ４０８で、ダイアグ・通信制御アプリケーション１０３は、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、返信データは応答バッファ２０３に一時的に格納される。このようにして、機能的要求に対するダイアグ制御処理において車載制御装置１００と診断装置２００との間で具体的なやりとりが行われる。

［１−３．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。
（１ａ）ダイアグ・通信制御アプリケーション１０３は、少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を指定した、機能的要求としての診断メッセージを受信した場合、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に順に診断処理を実行させる。

このような構成によれば、第１の診断アプリケーション１０１が応答バッファ２０３を使用する期間と、第２の診断アプリケーション１０２が応答バッファ２０３を使用する期間とがずれる。このため、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２が１つの応答バッファ２０３を共有して診断処理を実行することができる。その結果、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２それぞれに対して応答バッファを設ける必要がなくなり、診断処理を実行するアプリケーションが複数搭載された車載制御装置１００において、応答バッファを減らすことが可能となる。

なお、第１実施形態では、第１の診断アプリケーション１０１が第１の処理部としての処理に相当し、第２の診断アプリケーション１０２が第２の処理部としての処理に相当する。また、ダイアグ・通信制御アプリケーション１０３が管理実行部としての処理に相当し、Ｓ１０１〜Ｓ１０５が単独実行部としての処理に相当し、Ｓ３０３〜Ｓ３０７が直列実行部としての処理に相当する。

［２．第２実施形態］
［２−１．構成］
第２実施形態は、ダイアグ制御処理が、第１実施形態のダイアグ制御処理と異なる。その他、基本的な構成及び処理の流れは第１実施形態と同様であり、第１実施形態と共通する構成及び処理については、同一符号を用いて説明を省略する。

［２−２．ダイアグ制御処理の概要］
少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を宛先として指定した機能的要求としての診断メッセージを車載制御装置１００が受信した場合のダイアグ制御処理について、図６を用いて説明する。なお、図６におけるＳ５０１、Ｓ５０２及びＳ５０４〜Ｓ５０８の処理は、第１実施形態のＳ３０１〜Ｓ３０７の処理と同様であるため、説明を省略する。

Ｓ５０３で、ダイアグ・通信制御アプリケーションは、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２が並行して実行する診断処理である並列診断処理を実行可能であるか否かを判定する。具体的には、ダイアグ・通信制御アプリケーションは、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２を指定した診断メッセージに含まれる種類データが、あらかじめ定められた種類であるか否かを判定する。

ここで、種類データについて説明する。図７に示すように、診断メッセージに含まれる種類データは、複数種類、この例では、故障コード読出し、フリーズフレームデータ読出し、データ読出し、診断情報消去及びデータ書込み、の５種類が存在する。ここで、診断メッセージに送信される返信データのデータ量である返信データ長は、種類データに応じて異なる。この例では、診断情報消去及びデータ書込みの種類データに対する返信データ長は、故障コード読出し、フリーズフレームデータ読出し及びデータ読出しの種類データに対する返信データ長と比較して短い。つまり、対応する返信データ長が短い種類データは、あらかじめ決まっている。そこで、第１の診断アプリケーション１０１の返信データのデータ長と第２の診断アプリケーション１０２の返信データのデータ長との合計が、応答バッファ２０３のバッファ長を超すことがないよう、並列診断処理を実行する場合の種類データがあらかじめ設定されている。この例では、診断メッセージに含まれる種類データが、診断情報消去及びデータ書込みのうちいずれかである場合、並列診断処理が実行可能であると判定するよう、あらかじめ設定されている。なお、１つの診断メッセージに含まれる種類データの数は１つである。

Ｓ５０３の処理に戻り、ダイアグ・通信制御アプリケーションは、並列診断処理が実行不可能であると判定した場合、Ｓ５０４の処理へ移行する。
Ｓ５０４〜Ｓ５０８で、ダイアグ・通信制御アプリケーションは、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に順に診断処理を実行させる。

一方、Ｓ５０３で、ダイアグ・通信制御アプリケーションは、並列診断処理が実行可能であると判定した場合、処理をＳ５０９へ移行する。
Ｓ５０９で、ダイアグ・通信制御アプリケーションは、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２のそれぞれに並行して診断処理を実行させる。それぞれの診断処理の結果は、ダイアグデータ領域２０１に格納される。

Ｓ５１０で、ダイアグ・通信制御アプリケーションは、ダイアグデータ領域２０１に格納されている診断処理を実行した結果を、返信データとして診断装置２００に送信する送信処理を行う。送信処理において、第１の診断アプリケーション１０１の返信データ及び第２の診断アプリケーション１０２の返信データの両方が、応答バッファ２０３に一時的に格納される。

次に、Ｓ５１１で、ダイアグ・通信制御アプリケーションは、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に対する計時処理を終了する。その後、図６のダイアグ制御処理を終了する。

このようにして、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に、順に又は並行して診断処理を実行させる、機能的要求に対するダイアグ制御処理が実行される。

［２−３．効果］
以上詳述した第２実施形態によれば、前述した第１実施形態と同様の効果に加え、以下の効果が得られる。

（２ａ）ダイアグ・通信制御アプリケーションは、少なくとも第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の両方を指定した診断メッセージを受信した場合、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に、順に又は並行して診断処理を実行させる。具体的には、ダイアグ・通信制御アプリケーションは、当該診断メッセージに含まれる種類データが、診断情報消去及びデータ書込みのうちいずれかである場合、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に、並行して診断処理を実行させる。また、ダイアグ・通信制御アプリケーションは、当該診断メッセージに含まれる種類データが、診断情報消去及びデータ書込みのうちいずれでもない場合、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に順に診断処理を実行させる。このような構成によれば、ダイアグ・通信制御アプリケーションが、応答バッファ２０３のみを用いて、種類データに応じた診断処理の実行、すなわち、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２の診断処理を並列に又は順に実行させることができる。その結果、第１実施形態と比較して、診断処理に要する時間が短縮され得る。

なお、第２実施形態では、Ｓ５０４〜Ｓ５０８が直列実行部としての処理に相当し、Ｓ５０９〜Ｓ５１１が並列実行部としての処理に相当する。
［３．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は、上記各実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。

（３ａ）上記各実施形態では、１つの車載制御装置１００が、診断処理を実行可能なアプリケーションを２つ有する構成を例示したが、診断処理を実行可能なアプリケーションの数はこれに限定されるものではない。例えば、１つの車載制御装置が、診断処理を実行可能なアプリケーションを３つ以上有する構成であってもよい。この場合における図６に示す第２実施形態のダイアグ制御処理は、ダイアグ・通信制御アプリケーションが、Ｓ５１１で並列診断処理が可能な診断アプリケーションの計時処理を終了した後、Ｓ５０３に戻り、診断処理がまだ実行されていない診断アプリケーションの並列診断処理が可能か否かを判定する構成としてもよい。

（３ｂ）上記各実施形態では、車両の外部にある診断装置２００を例示したが、診断装置のある場所については特に限定されるものではない。例えば、診断装置は、車両の内部にあるものであってもよい。

（３ｃ）上記各実施形態では、診断処理が実行される順番として、ターゲットアドレスが若い順を例示したが、これ以外の順番であってもよい。
（３ｄ）上記第２実施形態では、診断メッセージに含まれる種類データがあらかじめ定められた種類である場合に、並列診断処理を実行させるダイアグ制御処理を例示した。しかし、ダイアグ制御処理はこれに限定されるものではなく、並列診断処理が実行可能であるか否かを他の方法によって判定してもよい。

例えば、第１変形例のダイアグ・通信制御アプリケーションは、第２実施形態の並列診断処理とは異なる並列診断処理を実行する。具体的には、第１変形例のダイアグ・通信制御アプリケーションは、並列診断処理の判定において、種類データの代わりに、受信した診断メッセージから算出される返信データの情報である、返信データ長を用いる点で第２実施形態の並列診断処理と相違する。

ここで、返信データ長について説明する。第２実施形態で前述したように、返信データの返信データ長は、種類データ及び診断に必要なデータに応じてあらかじめ決まっており、返信データ長は、受信した診断メッセージから算出できる。算出した返信データ長の情報を利用し、ダイアグ・通信制御アプリケーションは、並列診断処理が実行可能であるか否かを判定する。具体的には、ダイアグ・通信制御アプリケーションは、診断メッセージを受信した時点で、各診断アプリケーションの返信データ長を合計し、合計した合計値があらかじめ定められた閾値以下である場合、並列診断処理が実行可能であると判定する。この例では、ダイアグ・通信制御アプリケーションは、診断メッセージに含まれている、第１の診断アプリケーション１０１の返信データのデータ長と、第２の診断アプリケーション１０２の返信データのデータ長とを合計し、合計値と閾値とを比較することで、並列診断処理の判定を行う。なお、閾値は、応答バッファ２０３のバッファ長を超すことがない値、例えばバッファ長と同じ値に設定されている。

合計値が閾値よりも大きい場合、ダイアグ・通信制御アプリケーションは、並列診断処理が実行不可能であると判定し、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に順に診断処理を実行させる。

一方、合計値が閾値以下である場合、ダイアグ・通信制御アプリケーションは、並列診断処理が実行可能であると判定し、第１の診断アプリケーション１０１及び第２の診断アプリケーション１０２に並行して診断処理を実行させる。

このような構成によれば、前述した第２実施形態と同様の効果が得られる。
（３ｅ）上記各実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合したりしてもよい。また、上記各実施形態の構成の一部を省略してもよい。また、上記各実施形態の構成の少なくとも一部を、他の上記各実施形態の構成に対して付加、置換等してもよい。なお、特許請求の範囲に記載の文言から特定される技術思想に含まれるあらゆる態様が本開示の実施形態である。

（３ｆ）本開示は、前述した車載制御装置の他、当該車載制御装置を構成要素とするシステム、当該車載制御装置としてコンピュータを機能させるためのプログラム、このプログラムを記録した媒体、及び診断方法など、種々の形態で実現することができる。

１…マイコン、２…入出力回路、３…センサ、４…アクチュエータ、５…通信部、１０…ＲＯＭ、２０…ＲＡＭ、３０…ＣＰＵ、４０…Ｉ／Ｏ、５０…データフラッシュ、６０…タイマ、１００…車載制御装置、１０１…第１の診断アプリケーション、１０２…第２の診断アプリケーション、１０３…ダイアグ・通信制御アプリケーション、２００…診断装置、２０１…ダイアグデータ領域、２０２…要求バッファ、２０３…応答バッファ、２０４…通信タイマ領域。

Claims (4)

1. 車両に搭載され、診断装置（２００）からの診断メッセージに対する診断処理を実行する車載制御装置（１００）であって、
   第１の診断処理を実行する第１の処理部（１０１）と、
   第２の診断処理を実行する第２の処理部（１０２）と、
   前記診断メッセージを受信した場合、前記第１の処理部及び前記第２の処理部のうち少なくとも一方に前記診断処理を実行させる管理実行部（１０３）と、
   を備え、
   前記管理実行部は、
   前記第１の処理部を指定した前記診断メッセージを受信した場合、前記第１の処理部に前記診断処理を実行させ、前記第２の処理部を指定した前記診断メッセージを受信した場合、前記第２の処理部に前記診断処理を実行させる、単独実行部（Ｓ１０１〜Ｓ１０５）と、
   前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信した場合、前記第１の処理部及び前記第２の処理部に順に前記診断処理を実行させる、直列実行部（Ｓ３０３〜Ｓ３０７，Ｓ５０４〜Ｓ５０８）と、を備える、車載制御装置。
2. 請求項１に記載の車載制御装置であって、
   前記管理実行部は、前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信した場合、前記第１の処理部及び前記第２の処理部に並行して前記診断処理を実行させる、並列実行部（Ｓ５０９〜Ｓ５１１）を更に備える、車載制御装置。
3. 請求項２に記載の車載制御装置であって、
   前記並列実行部は、前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信し、前記診断メッセージの種類があらかじめ定められた種類である場合に、前記第１の診断処理部及び前記第２の診断処理部に並行して前記診断処理を実行させ、
   前記直列実行部（Ｓ５０４〜Ｓ５０８）は、前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信し、前記診断メッセージの種類が前記あらかじめ定められた種類でない場合、前記第１の処理部及び前記第２の処理部に順に前記診断処理を実行させる、車載制御装置。
4. 請求項２に記載の車載制御装置であって、
   前記並列実行部は、前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信し、前記第１の処理部が前記診断処理を実行した結果を表す第１の返信データのデータ量と前記第２の処理部が前記診断処理を実行した結果を表す第２の返信データのデータ量との合計が、あらかじめ定められた閾値以下であると判断した場合に、前記第１の処理部及び前記第２の処理部に並行して前記診断処理を実行させ、
   前記直列実行部（Ｓ５０４〜Ｓ５０８）は、前記第１の処理部及び前記第２の処理部の両方を指定した前記診断メッセージを受信し、前記第１の返信データのデータ量と前記第２の返信データのデータ量との合計が前記閾値よりも大きいと判断した場合に、前記第１の診断処理部及び前記第２の診断処理部に順に前記診断処理を実行させる、車載制御装置。

Images