(57)【要約】【課題】複数の通信メッセージに対する異常診断結果を用いて、送信元のアプリケーションまたはコントローラの異常判定を行うことで、異常診断の精度や詳細度を向上させる。【解決手段】車載機器を制御するための複数のアプリケーションと、前記複数のアプリケーション同士のデータの交換がなされる共通実効環境部と備えた車両制御装置において、前記複数のアプリケーションが前記共通実行環境部とデータのやり取りを行う際に、当該データの異常判定を行うための通信保護部と、前記通信保護部による異常判定結果からシステム異常を判定するシステム異常判定部と、を備える。【選択図】  図１
2014058210.tif 000002
【特許請求の範囲】
【請求項１】
複数の車両制御装置が通信バスを介して接続されて相互にデータ通信を行う車載システムに用いられ、
車載機器を制御するための演算処理を実行する演算処理装置と、前記演算処理装置に処理されるプログラムを格納する記憶装置と、を備え、
前記プログラムは、車載機器を制御するための複数のアプリケーションと、前記複数のアプリケーション同士のデータの交換がなされる共通実効環境部と備えた車両制御装置において、
前記プログラムは、前記複数のアプリケーションが前記共通実行環境部とデータのやり取りを行う際に、当該データの異常判定を行うための通信保護部と、前記通信保護部による異常判定結果からシステム異常を判定するシステム異常判定部と、を備え、前記システム異常判定部の判定結果に基づき、ログの出力、前記記憶装置へのログの記憶、または前記車載機器の制御のうち少なくとも一つ実行することを特徴とする車両制御装置。
【請求項２】
前記システム異常判定部は、前記複数のアプリケーションの動作状態を取得するアプリ動作状態管理手段と、当該動作状態からシステム異常を判定するルールを切り替える判定ルール決定手段と、前記判定ルール決定手段によって切り替えられたルールに基づいてシステム異常の判定を行う状態判定手段と、を備えることを特徴とする請求項１に記載の車両制御装置。
【請求項３】
前記動作状態は、前記複数のアプリケーションの休止状態を含むことを特徴とする請求項２記載の車両制御装置。
【請求項４】
前記通信保護部は、誤り検出符号またはメッセージカウンタの少なくとも一つを用いることを特徴とする請求項２記載の車両制御装置。
【請求項５】
前記通信保護部が異常判定を行うデータは、前記通信バスを介して、前記複数の車両制御装置中の他の情報制御装置から受信したデータであることを特徴とする請求項２記載の車両制御装置。
【請求項６】
複数の車両制御装置と、前記複数の情報制御装置間で相互にデータ通信を行うための通信バスと、を備え、前記複数の車両制御装置各々は、車載機器を制御するための演算処理を実行する演算処理装置と、前記演算処理装置に処理されるプログラムを格納する記憶装置と、を備え、
前記プログラムは、車載機器を制御するための複数のアプリケーションと、前記複数のアプリケーション同士のデータの交換がなされる共通実効環境部と備える車両制御システムにおいて、
前記プログラムは、前記複数のアプリケーションが前記共通実行環境部とデータのやり取りを行う際に、当該データの異常判定を行うための通信保護部と、前記通信保護部による異常判定結果からシステム異常を判定するシステム異常判定部と、を備え、
前記システム異常判定部は、前記複数のアプリケーションの動作状態を取得するアプリ動作状態管理手段と、当該動作状態からシステム異常を判定するルールを切り替える判定ルール決定手段と、前記判定ルール決定手段によって切り替えられたルールに基づいてシステム異常の判定を行う状態判定手段と、を備えることを特徴とする車両制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車載機器を制御するための車両用制御装置に関する。
【背景技術】
【０００２】
従来、通信ネットワークを備える車載制御装置では、外部から受信する通信メッセージに対して異常判定が行われ、判定結果に応じた処理を行う。例えば、特許文献１では、通信制御回路で表される通信処理部の、制御ロジック部において全ての通信メッセージに対して異常判定を行い、通信メッセージに異常があった場合には通信を停止する機能について開示がある。
【０００３】
また、車載制御装置のソフトウェア構成の一つに、車載機器を制御する個別機能を実現する計算部を部品化したアプリケーションと、異なるアプリケーション間で共通に利用される機能を備え、アプリケーションに定型のインタフェースを提供する基盤ソフトウェア部と、アプリケーションと基盤ソフトウェア部の間に位置し、基盤ソフトウェア部をアプリケーションから隠した上でアプリケーション同士のデータ交換環境を提供する共通実行環境部を備えた構成がある。共通実行環境部を備えると、アプリケーションの変更箇所の他への影響を局所化できるため、アプリケーションの移植が容易になり、生産性向上に寄与する。例えば、車載ソフトウェアの標準規格AUTOSAR(非特許文献１)では、ソフトウェア内にRTE(Run Time Environment)と呼ばれる共通実行環境を用意し、電子制御を行うための計算部をソフトウェアコンポーネントとして部品化し、RTE上で動作させる構成が取られている。
【０００４】
更に、近年では電子制御システムの安全性を担保するために機能安全規格への準拠が求められている。通信機能を機能安全規格に準拠させるには、データの交換を行うアプリケーション間のレベルで通信データ保護と検査を行い、通信データの信頼性を向上させる事が求められる。このため、共通実行環境を有するソフトウェアを機能安全規格に対応させるには、メッセージ毎の異常判定をアプリケーション毎に行う構成が必要となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平8-9471号公報
【非特許文献】
【０００６】
【非特許文献１】AUTOSAR http://www.autosar.org/
【発明の概要】
【発明が解決しようとする課題】
【０００７】
特許文献１記載の技術では、通信メッセージの異常診断は、通信ネットワークとデータの送受信処理を行う通信処理部によって行うため、複数の通信メッセージに関する異常診断結果を用いた通信ネットワークを介した送信元に対する異常判定を行うことが可能である。しかし、非特許文献１記載のような共通実行環境を有するソフトウェア構成でアプリケーション同士の通信データ保護については格別配慮がなされていない。また、単純に共通実行環境上の各アプリケーションに特許文献１記載のような通信メッセージ毎の異常判定を分散配置したとしても、複数の通信メッセージに対する異常判定の結果を用いたシステム単位、制御装置単位の異常判定を行う事ができない。
【０００８】
また、アプリケーション毎に通信メッセージ毎の異常判定を備えても、異常判定の処理がアプリケーションの動作状態に影響され、送信元に対する異常判定を誤る場合がある。
【０００９】
本発明はこのような課題に鑑みてなされたものであり、本発明の目的は、複数の通信メッセージに対する異常診断結果を用いて、送信元のアプリケーションまたはコントローラの異常判定を行うことで、異常診断の精度や詳細度を向上させることにある。
【課題を解決するための手段】
【００１０】
上記課題を解決するため本願発明は、アプリケーションのレベルで、通信の異常判定結果を収集する機能と、システム単位の異常判定をおこなう機能を有したソフトウェア部品を実装し、アプリケーション毎にメッセージの通信異常判定を行う構成であっても、通信異常判定を収集してシステムの異常を判定する。
【００１１】
更に、アプリケーションの動作状態を用いて判定ルールを変える。
【発明の効果】
【００１２】
本発明によれば、共通実行環境を有するソフトウェア構成において、各アプリケーション間の通信メッセージの保護と、複数の通信メッセージに対する異常判定の結果を用いたシステム単位の異常判定が可能になる。
【００１３】
更に、アプリケーションの動作状態を用いて判定ルールを変えることにより、通信メッセージ毎異常判定の処理が個々のアプリケーションの動作状態に影響されても、複数の通信メッセージに対する異常判定を用いた上記異常判定を誤らない。
【図面の簡単な説明】
【００１４】
【図１】本発明を適用した車載制御システムを表す図である。
【図２（ａ）】本発明のソフトウェア構成を表す図である。
【図２（ｂ）】システム状態判定部の構成を表す図である。
【図３（ａ）】通信メッセージを表す図である。
【図３（ｂ）】通知パラメータとアプリケーションの動作状態の関係を表す図である。
【図４】送信側の通信異常保護部の処理を表す図である。
【図５】受信側の通信異常保護部の処理を表す図である。
【図６】通信異常判定方法を現す図である。
【図７（ａ）】アプリケーション動作状態管理部の処理フローである。
【図７（ｂ）】動作状態テーブルを表す図である。
【図８（ａ）】判定ルール決定部の処理を表す図である。
【図８（ｂ）】判定ルール選択テーブルを表す図である。
【図９（ａ）】状態判定部の処理を表す図である。
【図９（ｂ）】アプリケーションが通常状態の場合の判定テーブルある。
【図９（ｃ）】アプリケーションの一部が休止状態の場合の判定テーブルである。
【図１０】具体化したアプリケーションの説明図である。
【図１１（ａ）】ECU間の通信を表す図である。
【図１１（ｂ）】診断アプリケーションの判定テーブルを表す図である。
【図１２（ａ）】回生アプリケーションが休止した場合のECU間の通信を表す図である。
【図１２（ｂ）】診断アプリケーションの切り替え後の判定テーブルを表す図である。
【発明を実施するための形態】
【００１５】
以降、本発明の実施例について図面を用いて説明を行う。
【実施例１】
【００１６】
本発明の基本的な構成を示す。
【００１７】
図1に本発明を適用した車載制御システムを示す。車載制御システムは、少なくとも2つのECU(Electronic Control Unit)101-1、101-2、…、101-nを有し、これらはデータ交換のための通信ネットワーク102に接続し、相互にデータのやりとりを行う。ECU100には通信ネットワーク102からデータを受信、あるいは通信ネットワーク102にデータを送信するための通信装置103と、プログラムが格納された記憶装置であるROM(Read Only Memory)104と、このROM104に格納されたプログラムを実行する演算回路であるCPU(Central Processing Unit)105と、ソフトウェアの状態を記憶する記憶装置となるRAM(Random Access Memory)106と、センサからの値を取得し制御対象のアクチュエータへと制御信号を出力する入出力装置107が備えられている。
【００１８】
図2に本発明のソフトウェア構成を示す。図2(a)はソフトウェア全体の構成を示す。図2(a)は図１のECU100のROM104上に記憶され、CPU105によって実行される。ソフトウェアの状態はRAM106上に一時的に記憶される。
【００１９】
通信インタフェース部201は、通信ネットワーク102からの通信メッセージを送受信する機能と、通信ネットワーク102上での宛先情報を付与し、通信データを通信ネットワーク102上におけるデータフォーマット(例えばビット列の表現方法)に変換する機能を備える。
【００２０】
共通実行環境部202は同じECU100か外部のECU100かに寄らずアプリケーション203同士のデータ通信を管理し実行する機能やアプリケーション203の一部処理を起動する機能を備え、アプリケーションへデータ交換の為のインタフェースを提供し、アプリケーション203のデータ通信を管理する。
【００２１】
アプリケーション203-1、203-2、…、203-mは、自動車や自動車を構成するコントローラの制御や診断処理や入出力の管理をするための各種計算を行う機能を持ち、本発明の構成には少なくとも1つ以上備える。
【００２２】
通信保護部204は、アプリケーション203と共通実行環境部202の間に位置し、アプリケーション203が共通実行環境部202へ受け渡すデータに保護データを付加する機能と、共通実行環境部202がアプリケーション203に受け渡すデータの異常を診断する機能を有する。
【００２３】
システム状態判定部205は、通信保護部204が行う保護データの異常判定の結果と、アプリケーション203の動作状態を収集し、メッセージの送信元のアプリケーションまたはコントローラに対する異常判定を行う。
【００２４】
ログ記憶部206は、通信保護部204の通信保護結果やシステム状態判定部205のシステム状態判定結果を保存する事ができる。ログ記憶部206に保存可能なデータは、通信保護結果やシステム状態判定結果に限らない。
【００２５】
図2(b)にシステム状態判定部205の機能を示す。アプリケーション動作状態管理部207は、各アプリケーションから送信されるアプリケーション動作状態データを共通実行環境部202から取得し、動作状態テーブルへまとめて判定ルール決定部208へと通知する。判定ルール決定部208は、アプリケーション動作状態管理部207から受け渡された各アプリケーションの動作状態を用いて、状態判定部209が用いる判定ルールを選択し、状態判定部209へ通知する。状態判定部209では、通信保護部204から送られてきた1ないし複数の通信異常判定結果を共通実行環境部202から受け取り、通信異常判定結果を用いて送信元のアプリケーションまたはコントローラの状態を判定する。
【００２６】
本発明においては、少なくとも送信側に1つ受信側に１つの通信保護部が必要であるが、必ずしも全てのアプリケーションに備えられる必要はない。
【００２７】
図3に、共通実行環境部 202 上を流れる通信メッセージを示す。図3(a)は通信メッセージに含まれるデータを示しており、通信メッセージには、宛先情報等を含むヘッダ情報301と、アプリケーション203が作成し宛先に送られるアプリケーションデータ304と、通信保護部204が計算する保護用のデータが含まれる。保護用のデータには、アプリケーションデータ304のビット列から計算され、1ビット以上の値が反転した際に検出可能となる誤り検出符号302や、メッセージの順序を識別するためのメッセージカウンタ303が備えられる。
【００２８】
誤り検出符号302は、例えば8bit CRCが用いられ、8bit CRCは、8bitのデータ領域で表す事が出来る誤り検出符号である。誤り検出符号は、上記8bit CRCに限らず、他の誤り検出符号、例えば、他のbitのCRCや、チェックサム等を用いるようにしてもよい。
【００２９】
メッセージカウンタ303は、例えば4bit(0〜15で巡回)で表され、通信保護部はメッセージ毎の最新のメッセージカウンタの値を保持し、カウンタ値を誤りなく増加させる。メッセージカウンタは4bitの値に限定されるものではない。
【００３０】
アプリケーションデータ304の一つkaに、アプリケーションの動作状態に関するデータがある。現在のアプリケーションの動作状態を数値で表し、状態が変化した時或いは一定間隔でシステム状態判定部に通知する。図3(b)は、アプリケーションの動作状態を表す数値を示したデータ表である。通知パラメータの1はアプリケーションが通常動作中であることを、通知パラメータ0はアプリケーションが休止状態に入った事を示す値である。  本発明には2つ以上の動作状態を必要とするが、アプリケーションの動作状態は3つ以上あっても良い。アプリケーションデータ304は上記に限らず、ヘッダ情報301や誤り検出符号302やメッセージカウンタ303等の保護用データ以外のデータを表す。
【００３１】
これらの通信メッセージのサイズは、例えば車載通信プロトコルの一つであるCANを用いるならば最大8byteのデータ長内に納める必要がある。メッセージのサイズ、及び使用するプロトコルやデータフォーマットは上記に限らないが、設定した最大データ長を上回らない。
【００３２】
以上が本発明のシステム構成となる。続いて本発明を適用したシステムの基本的な振る舞いを示す。
【００３３】
以下では、送信側となるECU(100-x(x=1〜n))のソフトウェアにおける処理を説明する。
【００３４】
送信側ECUでの処理は、アプリケーション203が送信したいアプリケーションデータ304を作成し、通信保護部204にて保護データを付与し、共通実行環境部202を通って、通信インタフェース部201にてヘッダ情報301を付与し、通信メッセージを通信ネットワーク102へと送信する。
【００３５】
図4は通信保護部204の送信時の処理フローを示している。
【００３６】
まず、ステップ401において、通信保護部204はアプリケーションから送信要求のある送信データと宛先アプリケーション情報を表すデータを受け取る。
【００３７】
次に、ステップ402において、保持していたメッセージカウンタ303の前回値から1増やしたものを、次のメッセージカウンタ303として計算し、計算されたメッセージカウンタ303をアプリケーションデータ304と共にと通信メッセージへと格納する。
【００３８】
次に、ステップ403において、アプリケーションデータ304とメッセージカウンタ303が格納された通信メッセージに対して誤り検出符号302として8bitCRCを計算し、CRCの値を通信メッセージへと格納する。
【００３９】
次に、ステップ404において、通信メッセージと宛先アプリケーション情報を共通実行環境部202へと受け渡すことでデータを送信する。
【００４０】
通信メッセージと宛先アプリケーション情報を受け取った共通実行環境部202は、通信メッセージの宛先アプリケーション情報をもとに設定されたテーブル情報から宛先ECU情報を付与し、通信インタフェース部201へ送る。通信インタフェース部201は通信ネットワーク102にデータを送信する。
【００４１】
受信側となるECU100-X(X=1〜n)のソフトウェアにおける受信処理について示す。
【００４２】
受信側ECU100-X(X=1〜n) の通信インタフェース部102はデータを受信し、共通実行環境部202に受信データを渡す。共通実行環境部202は、宛先アプリケーション情報をもとに通信保護部204-1〜mの1つに受信データを渡す。
【００４３】
図5に通信保護部204の受信時の処理フローを示す。まず、ステップ501において、共通実行環境部から自身を宛先とした通信メッセージを受け取る。
【００４４】
次に、ステップ502において、通信メッセージ401に付与された付与データを確認し、異常判定を行う。異常判定方法及び処理フローについては図6を用いて説明する。
【００４５】
次に、ステップ503において、ステップ502で確認した結果異常が無い場合はステップ505に、異常がある場合はステップ504に移る。
【００４６】
次に、ステップ504では、異常が無かった通信データをアプリケーションへと受け渡す。
【００４７】
次に、ステップ505では、異常判定の結果をシステム状態判定部205へと受け渡すため、異常判定結果をシステム状態判定部を宛先として共通実行環境部へと受け渡す。
【００４８】
図6にステップ502で行う通信異常判定方法の処理フローを示す。
【００４９】
まず、ステップ601において、通信メッセージに格納されたCRC等の誤り検出符号と、誤り検出符号以外のメッセージ領域から計算された値を比較し、等しければデータが正常であるとしてステップ602に、等しくなければデータに異常があるとしてステップ603に移る。
【００５０】
次に、ステップ602において、メッセージカウンタが異常かを判定する。メッセージカウンタの異常は、受信側通信保護部に記憶されている前回値との比較によって行う。前回値と同じ値であった場合や、カウンタの順番が間違っていた場合、異常があったとしてステップ604に、異常が無い場合はステップ605に移る。
【００５１】
ステップ603では、判定結果を、誤り訂正符号に異常があったとして、異常とする。
【００５２】
ステップ604では、判定結果を、メッセージカウンタに異常があったとして、異常とする。
【００５３】
ステップ605では、判定結果を、異常が無かったとして正常とする。
異常判定方法、及び判定結果は上記フローに限定されるものではない。システム状態判定部に通知される通信メッセージ毎の判定結果があれば良い。例えば、CRC等による誤り検出と、メッセージカウンタを用いた異常判定とをそれぞれ単独で行ってもよい。
【００５４】
続いて、受信側となるECU(100に相当)のソフトウェアの動作を説明する。
【００５５】
アプリケーション203-M(M=1〜m)は、自身の動作状態をシステム状態判定部205へと通知する。アプリケーション203は、自身の動作状態をアプリケーションデータ304とし、宛先アプリケーションをシステム状態判定部205として共通実行環境部202へと受け渡す。共通実行環境部202は、宛先アプリケーション情報をもとにシステム状態判定部205に受信データを渡す。
【００５６】
通信保護部204-M(M=1〜m)は、異常判定の結果を正常か異常かに関らず、共通実行環境部202を介してシステム状態判定部205へ通知する。異常判定結果はアプリケーションデータ304とし、宛先アプリケーションをシステム状態判定部205として共通実行環境部202へと受け渡す。共通実行環境部202は、宛先アプリケーション情報をもとにシステム状態判定部205に受信データを渡す。
【００５７】
システム状態判定部205において、アプリケーション状態管理部206はアプリケーション203-M(M=1〜m)の状態データを収集、管理し、判定ルール決定部208へアプリケーションの動作状態を通知する。
【００５８】
判定ルール決定部208は、アプリケーションの動作状態を用いて、状態判定部209で用いる状態判定ルールを決定し、状態判定ルールの情報を状態判定部209へと通知する。
【００５９】
状態判定部209は、通信保護部204-Mの異常判定結果と判定ルール決定部208によって通知された判定ルールに従って送信元のアプリケーションまたはコントローラの状態を判定する。
【００６０】
図7に、アプリケーション動作状態管理部207の処理を示す。
【００６１】
図7(a)は、アプリケーション動作状態管理部207の処理フローを示しており、図7(b)はアプリケーション動作状態管理部207で扱う、各アプリケーションの動作状態を記録した動作状態テーブルを表す。
【００６２】
図7(a)を用いてアプリケーション動作状態管理部207の処理を示す。
【００６３】
まず、ステップ701において、受信処理を行い共通実行環境部206から各アプリケーションの動作状態データを受信する。
【００６４】
次に、ステップ702において、受信したアプリケーションの動作状態データを、動作状態テーブルへと格納する。図7(b)に示すように、動作状態テーブルには各アプリケーション203に一意に対応した管理番号とアプリケーションの動作状態値を格納する領域が存在する。ステップ702では、動作状態データの値を対応するアプリケーションの動作状態値へと保存する。
【００６５】
次に、ステップ703において、動作状態テーブルを判定ルール決定部208へと受け渡す。
【００６６】
図8に、判定ルール決定部208の処理を示す。図8(a)は、判定ルール決定部208の処理フローを示しており、図8(b)は判定ルールを決定する際に用いる判定ルール選択テーブルを示す。
【００６７】
図8(a)を用いて判定ルール決定部の処理を示す。
【００６８】
まず、ステップ801において、アプリケーション動作状態管理部207から動作状態管理テーブルを受け取る。
【００６９】
次に、ステップ802において動作状態管理テーブルの情報と判定ルール選択テーブルの情報とを用いて、現在のアプリケーションの状況に適した判定ルールを決定する。図8(b)に示すように、判定ルール選択テーブルは、各アプリケーションの動作状態の組み合わせから、判定ルールを選択するためのものである。
【００７０】
次に、ステップ803において、ステップ802で決定された判定ルール情報を、状態判定部209へと受け渡す。
【００７１】
図9に、状態判定部209の処理を示す。
【００７２】
図9(a)は、状態判定部209の処理フローを示し、図9(b)(c)は状態判定部で用いる判定ルールテーブルを示す。
【００７３】
図9(a)を用いて判定ルール決定部の処理を示す。
【００７４】
まず、ステップ901において、受信処理を行い、共通実行環境部202から、各メッセージの異常判定結果を受信する。
【００７５】
次に、ステップ902において、判定ルール決定部208から判定ルール情報を受け取る。
【００７６】
次に、ステップ903において、判定ルール情報から、判定ルールテーブルを決定する。図9(b)(c)に示すように、判定ルールテーブルには、メッセージの異常判定結果の組み合わせから、状態判定の結果を導き出すためのものである。図9(b)は、図8(b)において、各アプリケーションが通常状態である場合の判定ルールを示しており、メッセージA、Bの異常判定の結果の組み合わせ分の判定ルールをもつ。図9(c)は、図8(b)において、アプリケーション2が休止状態にあった場合の判定テーブルでありメッセージAの異常判定結果のみを用いて判定結果を導いている。
【００７７】
次にステップ904において、ステップ903において決定した判定テーブルとステップ901によって受信した通信異常判定結果を用いて、システム状態を判定する。
【００７８】
システム状態判定部によって判定された状態判定結果を用いて、異常時に入出力回路107を通して異常を操縦者や整備者に通知する警告灯などの外部機器へと送られる信号の作成や、状態判定結果をログ記憶部206へ保存することで故障の調査を行う際に用いる事が出来る。状態判定結果の利用方法は上記に限らず、様々な利用方法があってもよい。
【００７９】
上記構成により、AUTOSARと機能安全に対応したソフトウェアであっても、通信の異常判定結果を用いてアプリケーション／コントローラ単位の診断が可能になる。また、アプリケーション動作状態を用いることにより判定結果が誤ることなく、診断可能である。
【００８０】
以上が本発明を適用した車載制御装置の一般的な構成と振る舞いとなる。
【００８１】
次に、本発明を適用した車載制御システムの一つの実施例としてアプリケーション203を具体化したものを、図10を用いて示す。図10はある2つのECUのアプリケーション間のデータフローを表す、簡単のため通信保護部204はアプリケーション203に含まれているとし、省略している。
【００８２】
ECU1001は、図１等におけるECU 100に相当し、ソフトウェアにブレーキ制御の為の計算を実行させる機能を有する。また、ECU1001は外部出力の手段として警告灯を有し、異常ログを保存可能な記憶部を有している。
【００８３】
ECU1002は本発明におけるECU 100に相当し、ソフトウェアにモータ制御の為の計算と、バッテリ管理を行う機能を有する。
【００８４】
診断アプリケーション1003は図２のシステム状態判定部205に相当し、ECU1001に含まれるアプリケーションであり、ECU1001内のアプリケーションの動作モードと異常判定結果を収集し、警告灯の点灯及び記憶部へとログを保存する。
【００８５】
制御モード管理アプリケーション1004はシステム状態判定部205のアプリケーション状態管理部206の機能と、通信保護部204を有する、ECU1001に含まれるアプリケーションであり、ECU1002からの駆動モータ異常フラグのON/OFFに応じて、ECU1001 のブレーキ制御アプリケーション1005と回生アプリケーション1006に対して、回生ブレーキを実行するか否かの指示を表す回生有無データを送信する。
【００８６】
ブレーキ制御アプリケーション1005はアプリケーション203に相当し通信保護部204を有する、ECU1001に含まれるアプリケーションであり、ブレーキペダルのストロークセンサをA/D変換で取り込み踏込量データとする機能を有し、制御モード管理アプリケーション1004からの回生有無通知に応じて、回生有ならば、ブレーキペダルアプリケーション1007から通知される踏込量と回生アプリケーション1006から通知される目標制動力に応じて、ブレーキの制動力を計算する機能を有し、回生無しならば、プレーキペダルアプリケーション1007から通知される踏込量に応じてブレーキの制動力を計算し、ブレーキを制御する。
【００８７】
回生アプリケーション1006はアプリケーション203に相当し通信保護部204を有する、ECU1001に含まれるアプリケーションであり、モータを発電機として利用した際の回転抵抗を利用した回生ブレーキに関して、その制動力を計算する機能を有しており、ブレーキペダルアプリケーション1007の踏込量に応じて、ブレーキ制御アプリケーション1006へ回生ブレーキを併用した際の目標制動力を通知する。また、制御モード管理アプリケーションからの回生有無通知が回生無しであった場合、回生有が通知されるまで動作を休止する。
【００８８】
ブレーキペダルアプリケーション1007はアプリケーション203に相当し通信保護部204を有する、ECU1001に含まれるアプリケーションであり、運転手の操作したブレーキペダルの踏込量を取得し、回生アプリケーション1006とブレーキ制御アプリケーション1005に通知する。
【００８９】
駆動モータ制御アプリケーション1008はアプリケーション203に相当し通信保護部204を有する、ECU1002に含まれるアプリケーションであり、現在のモータの電流値を計測し、計測した電流値からモータの駆動力を計算し、PWM信号としてモータへと出力する。また、電流値から現在のモータの駆動に以上が無いかを判定し、異常があった際にはECU1001の制御モードアプリケーションに通知する。
【００９０】
バッテリ管理アプリケーション1009はアプリケーション203に相当し通信保護部204を有する、ECU1002に含まれるアプリケーションであり、バッテリの電圧と電流値からバッテリ残量を計算し、ECU1001の回生アプリケーション1006へと通知する。
【００９１】
図11を用いて、ECU1001 の診断アプリケーション1003がECU1002の状態を判定する処理を示す。図11(a)は、図10からECU1002とECU1001とのデータ通信部分を抜き出したものとなる。
【００９２】
駆動モータ制御アプリケーション1008 から送信される駆動モータ異常フラグの通信データは、制御モードアプリケーション 1004の異常判定部 204によって異常判定が行われ、異常判定の結果が診断アプリケーション  1003へと通知される。
【００９３】
バッテリ管理アプリケーション 1009から送信されるバッテリ残量の通信データは、回生アプリケーション1006の通信保護部204 によって異常判定が行われ、異常判定の結果が診断アプリケーション1003へと通知される。
【００９４】
診断アプリケーションは、異常判定の結果からECU1002の動作状態を判定し、異常と判定した場合、警告灯の点灯の為の処理を行う。システム状態判定はログとしてログ記憶部206に記憶される。適宜、警告等の点灯以外にも、フェールセーフ処理や異常状態に応じた車載機器の制御を行ってもよい。
【００９５】
図11(b)は、診断アプリケーション1003で行われるシステム状態判定の判定ルールを表したデータテーブルとなる。2つの送信データの異常判定結果の組み合わせから、ECU1002の動作状態を判定する。
【００９６】
この構成では、制御モード管理アプリケーション1004との通信によって、回生アプリケーション1006が休止することがある。このとき、診断アプリケーション1003は異常判定に用いる送信データの一つであるバッテリ残量の通信データに関する異常判定結果を得ることができず、正常な状態判定を行うことができない。例えば、回生アプリケーション1006が休止状態にあるとき、バッテリ管理アプリケーション1009が異常であると誤判定してしまうことが考えられる。また、例えば駆動モータ異常フラグおよびバッテリ残量いずれの通信データも異常のときにECU2全体に異常が生じていると判断するような場合において、駆動モータ制御アプリケーション1008に異常が生じ、かつ回生アプリケーション1006が休止状態の時、駆動モータ制御アプリケーション1008のみが異常なのか、ECU2全体が異常なのか区別できない。
【００９７】
そこで、制御モード管理アプリケーション1004は、駆動モータ制御アプリケーション1008から駆動モータ異常フラグを受け取ると、ブレーキ制御アプリケーション1005と回生アプリケーション1006へ回生無しとして回生有無通知を送信する。
【００９８】
また、回生アプリケーション1006は、回生無しとの通知を受信すると動作状態を通常から休止へと切り替える。休止に切り替えた際に、診断アプリケーション1003に休止状態に移行した事をアプリケーションの動作状態情報として通知する。
【００９９】
診断アプリケーション1003は、回生アプリケーション1006から休止状態に移行した事をアプリケーションの動作状態データとして受け取ると、診断アプリケーション1003内のアプリケーション状態管理部206に該当する機能によって、アプリケーションの動作状態テーブル(図7(b)に相当する)を更新する。さらに、判定ルール決定部208に該当する機能によって、アプリケーションの動作状態を元に状態判定ルールを図11(b)の1101から図12(b)の1201へと切り替えることで、回生アプリケーション1006が休止した状態でも正常に状態判定を続ける事が出来る。
【０１００】
反対に、診断アプリケーション1003は、回生アプリケーション1006から休止状態から復帰した事をアプリケーションの動作状態データとして受け取ると、アプリケーションの動作状態を元に状態判定ルールを図12(b)の1201から図11(b)の1101へと再度切り替えるようにするとよい。
【０１０１】
図12を用いて、回生アプリケーション1006が動作を休止した際のECU1002の動作状態の判定方法を示す。図12(a)では、回生アプリケーション1006が動作を休止するため、バッテリ管理アプリケーション1009 の通信データバッテリ残量の受信処理、及び通信異常判定が行われない。そのため、診断アプリケーション1003 には制御モード管理アプリケーション1004の異常判定結果が送られることになる。
【０１０２】
図12(b)では、通知されていた回生アプリケーション1006のアプリ状態通知から回生アプリケーション1006の通信異常判定を用いない異常判定テーブル1201へと変更しており、駆動モータ異常フラグの通信異常結果のみでECU2の状態を判定する。
【０１０３】
上記構成により、共通実行環境部上でアプリケーションが個々に動作するソフトウェアであっても、通信の異常判定結果を用いてアプリケーション及びコントローラ単位の診断が可能になる。例えば、１つのコントローラが複数の通信メッセージを送信する場合、一部の通信メッセージのみに異常が検出されれば、送信元コントローラは一部のアプリケーションの異常など、部分的な異常であると判定できる。また全通信メッセージに異常が判定されれば、送信元コントローラは完全に異常であると判定できる。
【０１０４】
また、個々のアプリケーション動作状態により診断結果が誤ることなく診断可能となる。
異常診断後、診断結果を用いて警告灯の点灯を指示する信号を作成し、入出力回路107を通して警告灯へ送付する事で警告灯に点灯の指令をだす、或いは診断結果をログ記憶部へ保存し異常理由の調査に用いることができる。
【符号の説明】
【０１０５】
１０１…ＥＣＵ、１０２…通信ネットワーク、２０２…共通実行環境部、２０３…アプリケーション、２０４…通信保護部、２０５…システム状態判定部、２０６…ログ記憶部、２０７…アプリケーション動作状態管理部、２０８…判定ルール決定部、２０９…状態判定部、
【図１】
2014058210.tif 000003
【図２（ａ）】
2014058210.tif 000004
【図２（ｂ）】
2014058210.tif 000005
【図３（ａ）】
2014058210.tif 000006
【図３（ｂ）】
2014058210.tif 000007
【図４】
2014058210.tif 000008
【図５】
2014058210.tif 000009
【図６】
2014058210.tif 000010
【図７（ａ）】
2014058210.tif 000011
【図７（ｂ）】
2014058210.tif 000012
【図８（ａ）】
2014058210.tif 000013
【図８（ｂ）】
2014058210.tif 000014
【図９（ａ）】
2014058210.tif 000015
【図９（ｂ）】
2014058210.tif 000016
【図９（ｃ）】
2014058210.tif 000017
【図１０】
2014058210.tif 000018
【図１１（ａ）】
2014058210.tif 000019
【図１１（ｂ）】
2014058210.tif 000020
【図１２（ａ）】
2014058210.tif 000021
【図１２（ｂ）】
2014058210.tif 000022