JP2019139315A

JP2019139315A - 車載通信システム

Info

Publication number: JP2019139315A
Application number: JP2018019413A
Authority: JP
Inventors: 優介宮内; Yusuke Miyauchi
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2018-02-06
Filing date: 2018-02-06
Publication date: 2019-08-22
Anticipated expiration: 2038-02-06
Also published as: CN110119104B; CN110119104A; US11288054B2; US20190243633A1; JP7006335B2

Abstract

【課題】ソフトウェアプログラムが更新された後におけるＥＣＵ同士の通信が想定されている通信であるか否かを判定すること。【解決手段】車載通信システム１は、複数のＥＣＵを相互に通信可能に接続しているバス上で送受信される予定のデータを示す第１情報を記憶する記憶部３２と、複数のＥＣＵの少なくとも一つのソフトウェアプログラムが更新された場合、バス上で送受信されているデータを示す第２情報を取得する取得部３４と、第１情報及び第２情報に基づいて、バス上で想定されている通信が実行されているか否かを判定する判定部３５と、を備える。【選択図】図６

Description

本発明は、車載通信システムに関する。

現代の自動車は、ＥＣＵ（Electronic Control Unit）と呼ばれるマイコンが複数搭載されており、これらのＥＣＵの間で通信が実行されている。また、運転支援技術や自動運転技術の普及に伴い、ＥＣＵで使用されるソフトウェアプログラムを更新する機会が増加し、ソフトウェアプログラムの更新が正当に実行されていることを検証する技術が重要になっている。

例えば、特許文献１には、制御プログラムの更新後における制御装置の動作が正常であるか否かを判定する手段を実現するコンピュータプログラムを実行し、その判定結果を中継装置に返答するプログラム更新システムが開示されている。

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

しかし、ソフトウェアプログラムの更新がＥＣＵごとに実行された場合、最新のソフトウェアプログラムに更新されているＥＣＵと更新されていないＥＣＵとが発生し、これらのＥＣＵの間で想定されている通信と異なる通信が実行されてしまうことがある。また、近年では、更新用のソフトウェアプログラムが無線ネットワークを経由して配信されることが増えていることにより、ソフトウェアプログラムが更新されるタイミングがＥＣＵごとに異なるケースが増えているため、この課題の解決に対する期待は大きい。

そこで、本発明は、ソフトウェアプログラムが更新された後におけるＥＣＵ同士の通信が想定されている通信であるか否かを判定することができる車載通信システムを提供することを目的とする。

本発明の一態様に係る車載通信システムは、複数のＥＣＵ（Electronic Control Unit）を相互に通信可能に接続しているバス上で送受信される予定のデータを示す第１情報を記憶する記憶部と、前記複数のＥＣＵの少なくとも一つのソフトウェアプログラムが更新された場合、前記バス上で送受信されているデータを示す第２情報を取得する取得部と、前記第１情報及び前記第２情報に基づいて、前記バス上で想定されている通信が実行されているか否かを判定する判定部と、を備える。

本発明によれば、ソフトウェアプログラムが更新された後におけるＥＣＵ同士の通信が想定されている通信であるか否かを判定することができる車載通信システムを提供することができる。

実施形態に係る車載通信システムの例を示す図である。実施形態に係る通信確認用ＥＣＵの例を示す図である。実施形態に係る通信確認用ＥＣＵが記憶しているメッセージの種類、ＩＤ、期待値及びデータ確認の有無の例を示す図である。実施形態に係る通信確認用ＥＣＵが記憶しているメッセージの種類、ＩＤ、期待値及びデータ確認の有無とこれらに対応するフラグとの関係の例を示す図である。実施形態に係る処理の例を示すシーケンス図である。実施形態に係る通信確認用ＥＣＵがバス上で想定されている通信が実行されているか否かを判定する処理の例を示すフローチャートである。

添付図面を参照して、本発明の好適な実施形態について説明する。なお、各図において、同一の符号を付したものは同一又は同様の構成を有する。

図１から図４を参照しながら、実施形態に係る車載通信システムについて説明する。車載通信システム１は、例えば、図１に示すように、ゲートウエイＥＣＵ１０１と、ＥＣＵ１０２と、ＥＣＵ１０３と、ＥＣＵ１０４と、ＥＣＵ１０５と、ＥＣＵ１０６と、車載機器１０７と、入出力装置１０８と、通信確認用ＥＣＵ１０９と、バス１１０とを備える。なお、以下の説明では、ＥＣＵ１０２のソフトウェアプログラムが更新される場合を例に挙げて説明する。また、ソフトウェアプログラムの更新は、自動車が停止している場合でも走行している場合でも実行され得る。

ゲートウエイＥＣＵ１０１は、ＥＣＵ１０２、ＥＣＵ１０３、ＥＣＵ１０４、ＥＣＵ１０５又はＥＣＵ１０６と、バス１１０とは別のバスに接続されているＥＣＵとの間で送受信されるデータを中継する。これら五つのＥＣＵは、自動車の各部、例えば、ブレーキ、センサを制御する。車載機器１０７は、インターフェース機器、例えば、カーナビゲーション装置、メータである。入出力装置１０８は、ボタン等の入力装置及びディスプレイ等の出力装置を含む。

通信確認用ＥＣＵ１０９は、例えば、図２に示すように、受信部３１と、記憶部３２と、送信部３３と、取得部３４と、判定部３５と、設定部３６とを備える。また、通信確認用ＥＣＵ１０９は、少なくとも記憶部３２、取得部３４及び判定部３５備えていればよく、受信部３１、記憶部３２、送信部３３、取得部３４、判定部３５及び設定部３６の少なくとも一つについて同等の機能を備える他の装置を利用してもよい。さらに、通信確認用ＥＣＵ１０９は、無線ネットワークにより図１に示したサーバ２と相互に通信可能に接続されている。なお、通信確認用ＥＣＵ１０９は、ゲートウエイＥＣＵ１０１と同様の機能を備えていてもよい。この場合、車載通信システム１は、ゲートウエイＥＣＵ１０１を備えておく必要は無い。

受信部３１は、ＥＣＵ１０２からソフトウェアプログラムが更新されたことを示す情報を受信する。

記憶部３２は、バス１１０上で送受信される予定のデータを示す第１情報を記憶している記憶媒体であり、例えば、ＲＡＭ（Random Access Memory）、ＳＲＡＭ（Static Random Access Memory）である。ここで、第１情報は、例えば、バス１１０上で送受信される予定のメッセージの期待値、バス１１０上で送受信される必要が無い不要データ、バス１１０上で送受信される特に重要なデータそのものである。

例えば、図３に示すように、記憶部３２は、バス１１０上で送受信される予定のメッセージの種類、ＩＤ（Identification）、期待値及びデータ確認の有無を紐付けて記憶している。

メッセージの種類は、例えば、定期的に送信される制御メッセージ、不定期に送信される制御メッセージ、ネットワークマネジメントメッセージ及び不要メッセージの四種類がある。これら二種類の制御メッセージは、図１に示した五つのＥＣＵが制御する自動車の各部を制御するメッセージである。ネットワークマネジメントメッセージは、バス１１０をウェークアップ状態又はスリープ状態に移行させるメッセージである。不要メッセージは、バス１１０上で送受信される必要が無いメッセージであり、例えば、車載通信システム１がサイバー攻撃を受けた場合や図１に示したＥＣＵが誤って別のソフトウェアプログラムで更新されてしまった場合に受信される。

なお、定期的に送信される制御メッセージの期待値は、不定期に送信される制御メッセージの期待値よりも容易に生成される。なぜなら、不定期に送信される制御メッセージは、送信される場合が正常であるのか正常でないのかの判定が必ずしも容易ではないことがあるからである。

ＩＤは、メッセージを識別するための文字列であり、例えば、メッセージの前に付される。期待値は、メッセージの特徴を示す物理量、例えば、メッセージの周期、送信される回数である。データ確認とは、記憶部３２が記憶しているデータと、取得部３４が後述する第２情報として取得したデータとを比較し、バス１１０上で想定されている通信が実行されているか否かを確認する処理である。

例えば、図３に示すように、ＩＤ「ｘｘｘ」の制御メッセージ（定期）は、期待値が周期１０ｍｓｅｃ及び回数８０回であり、データ確認が行われない。同様に、ＩＤ「ｐｐｐ」の制御メッセージ（不定期）は、期待値が回数１回であり、データ確認が行われる。或いは、ＩＤ「ｑｑｑ」の制御メッセージ（不定期）は、期待値が回数２回であり、データ確認が行われない。また、図３に示した他のメッセージについても同様である。なお、不要メッセージは、バス１１０上で送受信される必要が無いメッセージであるため、期待値が記憶部３２に記憶されておらず、データ確認の有無についても特に定義されていない。

また、記憶部３２は、アクセサリー電源又はイグニッション電源が投入されてから所定の時間内にバス１１０上で送受信される第１情報を記憶することが好ましい。なぜなら、当該所定の時間内における第１情報は、予め決められていることが多く、バス１１０上で想定されている通信が実行されているか否かを判定する処理を容易にすることが多いからである。また、当該所定の時間は、バス１１０上で送受信されるデータ全ての正確な期待値を生成するため、これらのデータのうち送信周期が最も長いデータの期待値を生成する上で十分な長さであることが好ましい。なお、記憶部３２は、バス１１０上で送受信された不要メッセージを逐一記憶してもよい。

送信部３３は、第１情報の記憶が完了したことを示す情報をサーバ２へ送信する。また、送信部３３は、ＥＣＵ１０２等のソフトウェアプログラムが更新されたことを示す情報及びバス１１０上で想定されている通信が実行されているか否かを判定する処理を開始することを示す情報の少なくとも一方を入出力装置１０８へ送信する。さらに、送信部３３は、当該通信に問題が無いことを示す情報又は当該通信に問題があることを示す警告情報を車載機器１０７へ送信する。

取得部３４は、図１に示した五つのＥＣＵの少なくとも一つソフトウェアプログラムが更新された場合、バス１１０上で送受信されているデータを示す第２情報を取得する。ここで、第２情報は、例えば、バス１１０上で送受信されているメッセージの期待値、バス１１０上で送受信される必要が無い不要データ、バス１１０上で送受信されている特に重要なデータそのものである。取得部３４は、例えば、バス１１０上に電気信号として広がった第２情報をバス１１０から直接取得する。

また、取得部３４は、上述した所定の時間内にバス１１０上で送受信されている第２情報を取得することが好ましい。なぜなら、当該所定の時間内における第２情報は、予め決められていることが多く、バス１１０上で想定されている通信が実行されているか否かを判定する処理を容易にすることが多いからである。なお、取得部３４は、バス１１０上で送受信された不要メッセージを逐一取得してもよい。

判定部３５は、第１情報及び第２情報に基づいて、バス１１０上で想定されている通信が実行されているか否かを判定する。具体的には、判定部３５は、第１情報及び第２情報がメッセージの期待値である場合、第１情報と第２情報とを比較し、両者が異なる場合、バス１１０上で想定されている通信が実行されていないと判定する。或いは、判定部３５は、第１情報及び第２情報が不要データである場合、第１情報と第２情報とを比較し、両者が等しい場合、バス１１０上で想定されている通信が実行されていないと判定する。

また、判定部３５は、ダイアグ登録が必要であるか否かを判定し、警告情報の送信が必要であるか否かを判定する。ここで、ダイアグ登録とは、バス１１０上で想定されていない通信が実行されているものの、警告情報を送信する必要が無い場合に当該通信が実行されたことを登録する処理である。

なお、判定部３５は、上述した三つの判定を自動車が停止している場合でも走行している場合でも実行することができる。

設定部３６は、判定部３５が行った各判定の結果に応じて、フラグ「０」、フラグ「１」又はフラグ「２」を設定し、ダイアグ登録を行う。

例えば、図４に示すように、設定部３６は、図３及び図４に示したＩＤ「ｘｘｘ」の制御メッセージ（定期）について判定部３５が「周期ＮＧ」、「回数ＮＧ」又は「不要メッセージ受信」と判定した場合、フラグ「０」を設定し、「データ不良」と判定した場合、フラグ「１」を設定する。ここで、「データ不良」とは、図３及び図４に示したデータ確認の結果、バス１１０上で想定されている通信が実行されていないと判定されたことを意味する。同様に、設定部３６は、図３及び図４に示したネットワークマネジメントメッセージについて判定部３５が「周期ＮＧ」、「データ不良」及び「不要メッセージ受信」と判定した場合、フラグ「２」を設定する。また、図４に示した他のメッセージについても同様である。

次に図５を参照しながら、実施形態に係る好適な処理の例について説明する。

ステップＳ１において、サーバ２は、更新用のソフトウェアプログラムをＥＣＵ１０２へ送信する。

ステップＳ２において、ＥＣＵ１０２は、ソフトウェアプログラムを更新する。

ステップＳ３において、ＥＣＵ１０２は、ステップＳ２でソフトウェアプログラムが更新されたことを示す情報をサーバ２へ送信する。

ステップＳ４において、受信部３１は、ステップＳ２でソフトウェアプログラムが更新されたことを示す情報をＥＣＵ１０２から受信する。

ステップＳ５において、サーバ２は、バス１１０上で送受信される予定のデータを示す第１情報を通信確認用ＥＣＵ１０９へ送信する。

ステップＳ６において、記憶部３２は、バス１１０上で送受信される予定のデータを示す第１情報を記憶する。

ステップＳ７において、送信部３３は、第１情報の記憶が完了したことを示す情報を送信する。

ステップＳ８において、送信部３３は、ステップＳ２でソフトウェアプログラムが更新されたことを示す情報を入出力装置１０８へ送信する。

ステップＳ９において、入出力装置１０８は、イグニッション電源が投入されたことを示す情報を受信して通信確認用ＥＣＵ１０９及び車載機器１０７へ送信する。

ステップＳ１０において、通信確認用ＥＣＵ１０９は、バス１１０上で想定されている通信が実行されているか否かを判定する。ステップＳ１０の詳細は、図６を参照しながら説明する。

なお、ステップＳ９において、入出力装置１０８は、イグニッション電源ではなくアクセサリー電源が投入されたことを示す情報を受信して通信確認用ＥＣＵ１０９及び車載機器１０７へ送信してもよい。

次に図６を参照しながら、ステップＳ１０の詳細の例について説明する。

ステップＳ１０１において、送信部３３は、バス１１０上で想定されている通信が実行されているか否かを判定する処理を開始することを示す情報を入出力装置１０８へ送信し、処理をステップＳ１０２へ進める。

ステップＳ１０２において、取得部３４は、バス１１０上で送受信されているデータを示す第２情報を取得し、処理をステップＳ１０３へ進める。

ステップＳ１０３において、判定部３５は、バス１１０上で想定されている通信が実行されているか否かを判定する。判定部３５は、当該通信が実行されていると判定した場合（ステップＳ１０３：Ｙｅｓ）、処理をステップＳ１０４へ進め、当該通信が実行されていないと判定した場合（ステップＳ１０３：Ｎｏ）、処理をステップＳ１０６へ進める。

ステップＳ１０４において、設定部３６は、フラグ「０」を設定し、処理をステップＳ１０５へ進める。

ステップＳ１０５において、送信部３３は、バス１１０上で実行されている通信に問題が無いことを示す情報を入出力装置１０８へ送信し、処理を終了させる。

ステップＳ１０６において、判定部３５は、ダイアグ登録が必要であるか否かを判定する。判定部３５は、ダイアグ登録が必要であると判定した場合（ステップＳ１０６：Ｙｅｓ）、処理をステップＳ１０７へ進め、ダイアグ登録が必要でないと判定した場合（ステップＳ１０６：Ｎｏ）、処理を終了させる。

ステップＳ１０７において、設定部３６は、ダイアグ登録を行い、処理をステップＳ１０８へ進める。

ステップＳ１０８において、判定部３５は、警告情報の送信が必要であるか否かを判定する。判定部３５は、警告情報の送信が必要であると判定した場合（ステップＳ１０８：Ｙｅｓ）、処理をステップＳ１１１へ進め、警告情報の送信が必要でないと判定した場合（ステップＳ１０８：Ｎｏ）、処理をステップＳ１０９へ進める。

ステップＳ１０９において、設定部３６は、フラグ「１」を設定し、処理をステップＳ１１０へ進める。

ステップＳ１１０において、送信部３３は、バス１１０上で実行されている通信に問題が無いことを示す情報を入出力装置１０８へ送信し、処理を終了させる。

ステップＳ１１１において、設定部３６は、フラグ「２」を設定し、処理をステップＳ１１２へ進める。

ステップＳ１１２において、送信部３３は、警告情報を入出力装置１０８へ送信し、処理を終了させる。

なお、車載通信システム１は、ステップＳ１０８において警告情報の送信が必要でないと判定した後、ステップＳ１０９及びステップＳ１１０を実行することなく処理を終了させてもよい。

また、車載通信システム１は、ステップＳ１０６においてダイアグ登録が必要でないと判定した後、ステップＳ１０９及びステップＳ１１０を実行してもよい。この場合、車載通信システム１は、例えば、ステップＳ１０５を実行した後、処理を終了させてもよい。

以上、本発明の一例である実施形態について説明した。実施形態に係る車載通信システム１は、複数のＥＣＵを相互に通信可能に接続しているバス上で送受信される予定のデータを示す第１情報を記憶する記憶部３２と、複数のＥＣＵの少なくとも一つのソフトウェアプログラムが更新された場合、バス上で送受信されているデータを示す第２情報を取得する取得部３４と、第１情報及び第２情報に基づいて、バス上で想定されている通信が実行されているか否かを判定する判定部３５と、を備える。このため、車載通信システム１は、ソフトウェアプログラムが更新された後におけるＥＣＵ同士の通信が想定されている通信であるか否かを判定し、この判定結果をユーザ宛てに通知することができる。

本発明は、上述した実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内において、他の様々な形態で実施することができる。このため、上述した実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈されるものではない。例えば、上述した各処理ステップは処理内容に矛盾を生じない範囲で任意に順番を変更し、又は並列に実行することができる。

１…車載通信システム、１０１…ゲートウエイＥＣＵ、１０２，１０３，１０４，１０５，１０６…ＥＣＵ、１０７…車載機器、１０８…入出力装置、１０９…通信確認用ＥＣＵ、１１０…バス、２…サーバ、３１…受信部、３２…記憶部、３３…送信部、３４…取得部、３５…判定部、３６…設定部

Claims

複数のＥＣＵ（Electronic Control Unit）を相互に通信可能に接続しているバス上で送受信される予定のデータを示す第１情報を記憶する記憶部と、
前記複数のＥＣＵの少なくとも一つのソフトウェアプログラムが更新された場合、前記バス上で送受信されているデータを示す第２情報を取得する取得部と、
前記第１情報及び前記第２情報に基づいて、前記バス上で想定されている通信が実行されているか否かを判定する判定部と、
を備える車載通信システム。
前記記憶部は、アクセサリー電源又はイグニッション電源が投入されてから所定の時間内に前記バス上で送受信される前記第１情報を記憶し、
前記取得部は、前記所定の時間内に前記バス上で送受信されている前記第２情報を取得する、
請求項１に記載の車載通信システム。
前記記憶部は、前記バス上で送受信される予定のメッセージの期待値を前記第１情報として記憶し、
前記取得部は、前記バス上で送受信されているメッセージの期待値を前記第２情報として取得し、
前記判定部は、前記第１情報と前記第２情報とを比較し、両者が異なる場合、前記バス上で想定されている通信が実行されていないと判定する、
請求項１又は２に記載の車載通信システム。
前記記憶部は、前記バス上で送受信される必要が無い不要データを前記第１情報として記憶し、
前記取得部は、前記不要データを前記第２情報として取得し、
前記判定部は、前記第１情報と前記第２情報とを比較し、両者が等しい場合、前記バス上で想定されている通信が実行されていないと判定する、
請求項１又は２に記載の車載通信システム。