特許 7508703 車両におけるＥＣＵの管理方法、ＥＣＵおよび可読記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-21

(45)【発行日】2024-07-01

(54)【発明の名称】車両におけるＥＣＵの管理方法、ＥＣＵおよび可読記憶媒体

(51)【国際特許分類】

   G06F 11/30 20060101AFI20240624BHJP

   G05B 9/02 20060101ALI20240624BHJP

   F02D 43/00 20060101ALI20240624BHJP

   G06F 11/07 20060101ALI20240624BHJP

   G06F 8/65 20180101ALI20240624BHJP

【ＦＩ】

G06F11/30 140D

G05B9/02 A

F02D43/00 301Y

F02D43/00 301Z

G06F11/07 193

G06F8/65

【請求項の数】 7

(21)【出願番号】P 2023519856

(86)(22)【出願日】2021-11-03

(65)【公表番号】

(43)【公表日】2023-11-14

(86)【国際出願番号】 CN2021128411

(87)【国際公開番号】W WO2022095896

(87)【国際公開日】2022-05-12

【審査請求日】2023-03-30

(31)【優先権主張番号】202011240019.5

(32)【優先日】2020-11-09

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(74)【代理人】

【識別番号】110000914

【氏名又は名称】弁理士法人ＷｉｓｅＰｌｕｓ

(72)【発明者】

【氏名】李翠

(72)【発明者】

【氏名】車忠輝

(72)【発明者】

【氏名】孫曉宇

【審査官】武田 広太郎

(56)【参考文献】

【文献】特開２００４－３２６６２９（ＪＰ，Ａ）

【文献】特開２００２－１０８６３８（ＪＰ，Ａ）

【文献】国際公開第２０１９／１５９６１５（ＷＯ，Ａ１）

【文献】国際公開第２０２０／０７５８０８（ＷＯ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １１／３０

Ｇ０５Ｂ ９／０２

Ｆ０２Ｄ ４３／００

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ ８／６５

(57)【特許請求の範囲】

【請求項1】

車両に配置された検査ノードにより、前記車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視するステップであって、前記検査ノードは、車載移動通信端末とターゲットＥＣＵとのうちの少なくとも一つを含むステップと、
前記検査ノードが、異常な動作状態にある異常ＥＣＵを検出すると、制御指令を前記異常ＥＣＵに送信するステップであって、前記制御指令は、対応する回復動作をするように前記異常ＥＣＵをトリガするように構成されているステップと、
を含み、
前記検査ノードが、異常な動作状態にある異常ＥＣＵを検出することは、
前記検査ノードが、ＥＣＵから送信される、対応するＥＣＵのトラフィック状態パラメータを含むネットワーク管理メッセージを受信するステップと、
前記検査ノードが、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定するステップと、
を含み、
前記検査ノードが、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定するステップは、
前記検査ノードが、前記トラフィック状態パラメータと正常走行時のトラフィック状態パラメータとが一致しない場合、前記ＥＣＵの状態が異常であると判定するステップと、
前記検査ノードが、前記ネットワーク管理メッセージからスリープレディー状態ＲＳＳ情報が抽出され、ＲＳＳにある正常の持続時間を超えた場合、前記ＥＣＵの状態が異常であると判定するステップと、
のうちの少なくとも一つを含む、車両における電子制御ユニットの管理方法。

【請求項2】

前記制御指令は、前記異常ＥＣＵによる再起動の実行をトリガするためのＥＣＵ再起動指令と、前記異常ＥＣＵによる停止の実行をトリガするためのＥＣＵ停止指令と、前記異常ＥＣＵによるファームウェアアップデートの実行をトリガするためのＥＣＵファームウェアアップデート指令と、のうちの少なくとも一つを含み、
前記車両がシステム停止状態にある場合、制御指令を前記異常ＥＣＵに送信する前記ステップは、
前記ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵ停止指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信し、前記異常ＥＣＵがファームウェアアップデートした後も異常である場合、前記ＥＣＵ停止指令を前記異常ＥＣＵに送信するステップと、
のうちの少なくとも一つを含む請求項１に記載の車両における電子制御ユニットの管理方法。

【請求項3】

前記制御指令は、前記異常ＥＣＵによる再起動の実行をトリガするためのＥＣＵ再起動指令と、前記異常ＥＣＵによるファームウェアアップデートの実行をトリガするためのＥＣＵファームウェアアップデート指令と、のうちの少なくとも一つを含み、
前記車両がシステム作動状態にある場合、制御指令を前記異常ＥＣＵに送信する前記ステップは、
前記ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
のうちの少なくとも一つを含む請求項１に記載の車両における電子制御ユニットの管理方法。

【請求項4】

前記ＥＣＵ再起動指令または前記ＥＣＵファームウェアアップデート指令を送信する前に、対応する構成項目が前記異常ＥＣＵに設定されていると判定するステップを
さらに含む請求項３に記載の車両における電子制御ユニットの管理方法。

【請求項5】

前記ターゲットＥＣＵが複数あり、複数の前記ターゲットＥＣＵの状態が異常である場合、ＥＣＵ再起動指令を前記ターゲットＥＣＵに送信するステップは、
前記ＥＣＵ再起動指令を異なる時点で複数の前記ターゲットＥＣＵに送信して、複数の前記ターゲットＥＣＵに異なる時点で再起動を実行させるステップ、
あるいは、異常状態にある前記ターゲットＥＣＵの割合が設定割合閾値を超えた場合、前記ＥＣＵ再起動指令を再起動順序に従って前記ターゲットＥＣＵに送信するステップ
を含む請求項１に記載の車両における電子制御ユニットの管理方法。

【請求項6】

プロセッサと、メモリと、通信バスとを備える電子制御ユニットであって、
前記通信バスは、プロセッサとメモリとの間の接続や通信を実現するように構成され、前記プロセッサは、メモリに記憶されている一つまたは複数のコンピュータプログラムを実行することで、請求項１から５の何れか一項に記載の車両における電子制御ユニットの管理方法のステップを実現するように構成される
電子制御ユニット。

【請求項7】

一つまたは複数のコンピュータプログラムを記憶しているコンピュータ可読記憶媒体であって、
前記一つまたは複数のコンピュータプログラムは、一つまたは複数のプロセッサにより実行されることで、請求項１から５の何れか一項に記載の車両における電子制御ユニットの管理方法のステップを実現できる
コンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は出願番号が２０２０１１２４００１９．５で、出願日が２０２０年１１月０９日である中国特許出願に基づいて提出され、その中国特許出願の優先権を主張し、その中国特許出願の全ての内容を参考として本願に援用する。

【0002】

本願の実施例は、自動車の技術分野に関するがこれに限定されず、具体的には、車両におけるＥＣＵの管理方法、ＥＣＵおよび可読記憶媒体に関するがこれらに限定されない。

【背景技術】

【0003】

インテリジェント化と情報化の発展に伴い、自動車の電気システムは日増しに複雑になり、今日の自動車は通常数十個の電子制御ユニット（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、ＥＣＵ）を備えている。ＥＣＵの増加は、機能の複雑さと安定性における難しさを表しており、ＥＣＵノードはすべてハードウェア＋ソフトウェアの構成となっている。一方、自動車のＥＣＵ製品の場合、これらのＥＣＵはすべてブラックボックスであり、使用者はＥＣＵの存在すら知らない。ＥＣＵに異常が発生した場合、使用者は自動車ディーラーまで運転して点検や修理を行ってもらわなければならず、その過程は所有者にとっては非常に面倒で不愉快なことである。

【0004】

現在、ＥＣＵノードの動作状態を他のＥＣＵを通じて修復する車全体の解決策がなく、それぞれのＥＣＵに独自の異常保護メカニズムが設計されるため、車全体の機能安定性において一定のリスクが存在する。各ＥＣＵの動作状態に依存しているため、リスクが大きい。

【0005】

システム停止状態の自動車の場合、あるＥＣＵが異常に動作し、決められた電源管理モードに従ってスリープに入ることができなかった場合、車全体のバッテリあがりを引き起こす可能性があり、これは使用者にとって受け入れ難いことである。

【発明の概要】

【発明が解決しようとする課題】

【0006】

本願の実施例により提供される車両におけるＥＣＵの管理方法、ＥＣＵおよび可読記憶媒体によれば、車全体のＥＣＵに対する状態監視を実現し、異常ＥＣＵが検出されると制御指令をそれに送信することにより、制御指令に応じて対応する回復動作を異常ＥＣＵに行わせることで、車両のエンスト後に異常ＥＣＵでバッテリあがりが引き起こされることを回避する。

【課題を解決するための手段】

【0007】

上記の技術的問題を少なくとも部分的に解決するために、本願の実施例は車両における電子制御ユニットの管理方法を提供する。この方法は、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視するステップと、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を異常ＥＣＵに送信するステップであって、該制御指令は、対応する回復動作をするように前記異常ＥＣＵをトリガするように構成されているステップとを含む。

【0008】

本願の実施例はさらに、プロセッサと、メモリと、通信バスとを備える電子制御ユニットを提供する。通信バスは、プロセッサとメモリとの間の接続や通信を実現するように構成され、プロセッサは、メモリに記憶されている一つまたは複数のコンピュータプログラムを実行することで、前述の車両における電子制御ユニットの管理方法のステップを実現するように構成されている。

【0009】

本願の実施例はさらに、一つまたは複数のコンピュータプログラムを記憶しているコンピュータ可読記憶媒体を提供する。該一つまたは複数のコンピュータプログラムは、一つまたは複数のプロセッサにより実行されることで、前述の車両における電子制御ユニットの管理方法のステップを実現できる。

【0010】

本願の他の特徴及び対応する有益効果は、明細書の後の部分で説明されるが、有益効果の少なくとも一部は、本願の明細書における記載から明らかになる。

【図面の簡単な説明】

【0011】

【図1】本願の第１の実施例にかかる、車全体のＥＣＵの接続模式図である。

【図2】本願の第１の実施例のフローチャートである。

【図3】本願の第２の実施例のフローチャートである。

【図4】本願の第２の実施例にかかる、システム停止状態でのフローチャートである。

【図5】本願の第３の実施例のフローチャートである。

【図6】本願の第３の実施例にかかる、システム作動状態での方法フローチャートである。

【発明を実施するための形態】

【0012】

本願の目的、技術案及び利点をより明らかにするために、以下では、具体的な実施形態に添付図面を組み合わせて本願の実施例をさらに詳しく説明する。ここで説明する具体的な実施例は本願を解釈するためだけに使われるものであって、本願を限定するために使われるものではない。

【0013】

第１の実施例
車全体のＥＣＵの作動安定性と信頼性を高めるために、本願の第１の実施例は車両における電子制御ユニットの管理方法を提案する。図１は車全体のＥＣＵの接続模式図である。各ＥＣＵはＣＡＮバスを介して接続され、相互にネットワークメッセージ、ＡＰＰメッセージおよびダイアグノーシスメッセージを送受信する。車全体はＴＢＯＸを介してＣＳＰサーバとインタラクションする。

【0014】

電子制御ユニット（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ、ＥＣＵ）：ＥＣＵ全体の機能は各ＥＣＵが協働して実現されるものである。本発明において、特定のＥＣＵノードが検査ノードとして他のＥＣＵの動作状態を監督し、通常のノードが監督対象となる。

【0015】

車載移動通信端末ＴＢＯＸ：同様にＥＣＵノードに属し、無線３ＧＰＰネットワークを介して外部ネットワークとインタラクションする通信システムを備えるとともに、車内の他のＥＣＵとのＣＡＮを介した情報のやりとりもサポートしている。サーバＣＳＰとインタラクションして、各ＥＣＵのトラフィックパラメータや動作状態を同期させ、車全体のＥＣＵ制御にも利用できる。

【0016】

車載クラウドサーバＣＳＰ：車のインターネットのアプリケーションシステムに相当し、クラウドアーキテクチャの車両動作情報プラットフォームであり、自動車メーカーにより保守され、自動車所有者にアプリケーションサービスを提供し、車両の使用過程の状態を追跡する。本発明では、自動車メーカーがこれを通じて車全体のＥＣＵトラフィックパラメータを保守および制御する。

【0017】

ＣＡＮ（Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋ、コントローラエリアネットワーク）：現在車で最も広く使用されているフィールドバスであり、各ＥＣＵの間ではＣＡＮを介して情報のやりとりを行っている。本発明では、検査ノードがＣＡＮ上で他のノードの情報を収集することで、状態の判断や異常時の制御を行う。

【0018】

本実施例において、車両における電子制御ユニットの管理方法を提案する。図２を参照し、この方法は以下のステップを含む。

【0019】

Ｓ２０１において、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視する。

【0020】

Ｓ２０２において、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信し、前記制御指令は、対応する回復動作をするように前記異常ＥＣＵをトリガするように構成されている。

【0021】

具体的な実施過程において、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視することは、前記車両に配置された検査ノードにより、前記ＥＣＵの動作状態を監視することにより実施してもよい。検査ノードとして選択可能なものは、車載移動通信端末ＴＢＯＸとターゲットＥＣＵとを含んでもよいが、もちろん、そのうちの一つのみを選択してもよく、ＴＢＯＸとターゲットＥＣＵを組み合わせて選択してもよい。例えば、ＴＢＯＸと複数のターゲットＥＣＵを組み合わせて選択してもよい。本実施例において、前記ターゲットＥＣＵとしては、ＥＣＵの実際の動作パフォーマンスまたはＥＣＵの機能複雑度に応じて、動作が比較的安定しているＥＣＵまたは機能複雑度の低いＥＣＵを検査ノードとして選択してから、検査ノードであるＥＣＵを用いて、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視するようにしてもよい。

【0022】

具体的な監視手段としては、対応する物理アドレスを各ＥＣＵに割り当て、対応する物理アドレスに基づいてＥＣＵの動作状態を監視してもよい。もちろん、対応する物理アドレスに基づいて制御指令を前記異常ＥＣＵに送信してもよい。本実施例によれば、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信することにより、実施過程によっては、異常ＥＣＵが制御指令に従って対応する回復動作を実行できるため、車全体のＥＣＵの動作安定性を向上させ、ＥＣＵの異常による車のバッテリあがりを避けて、使用者の体験を向上させることができる。

【0023】

また、前記制御指令は、前記異常ＥＣＵによる再起動の実行をトリガするためのＥＣＵ再起動指令と、前記異常ＥＣＵによる停止の実行をトリガするためのＥＣＵ停止指令と、前記異常ＥＣＵによるファームウェアアップデートの実行をトリガするためのＥＣＵファームウェアアップデート指令と、のうちの少なくとも一つを含んでもよい。

【0024】

本願の一つの可能な実施形態において、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信する。

【0025】

具体的な制御指令としては、ＥＣＵ再起動指令であってもよい。異常ＥＣＵは、ＥＣＵ再起動指令を受信すると再起動を実行することができる。

【0026】

ＥＣＵ停止指令であってもよい。異常ＥＣＵは、ＥＣＵ停止指令を受信すると停止を実行することができる。

【0027】

ＥＣＵファームウェアアップデート指令であってもよい。異常ＥＣＵは、ＥＣＵファームウェアアップデート指令を受信するとファームウェアアップデートを実行することができる。

【0028】

一つの可能な実施形態において、制御指令を前記異常ＥＣＵに送信することは、対応する制御動作の指令コードを前記ＥＣＵに直接送信し、例えば、対応するＥＣＵの物理アドレスをＩＤとするＵＤＳ再起動指令０ｘ１１を送信してから、０ｘ１１に対する応答を待つようにしてもよい。カスタマイズされたＵＤＳ制御指令を異常ＥＣＵに送信し、異常ＥＣＵは、カスタマイズされたＵＤＳ制御指令を通じて自身の状態異常を知ることで、対応する制御指令に合わせて再起動動作、停止動作またはファームウェアアップデート動作を実行するようにしてもよい。もちろん、本例で説明されたＥＣＵファームウェアアップデート指令は、異常ＥＣＵがファームウェアアップデートを実行するようにトリガするためだけの指令であってもよく、すなわち、ＥＣＵファームウェアアップデート指令に、対応するファームウェアが含まれていなくてもよい。異常ＥＣＵは、ＥＣＵファームウェアアップデート指令を受信すると、アップデートする必要のあるファームウェア情報をローカルストレージ、サーバ、またはローカルの外付け記憶装置から取得することができる。なお、本実施例で言うファームウェアアップデートは、最新バージョンのファームウェアへのアップデートであってもよく、並行アップデート、すなわちファームウェアのバージョン番号を変更しないアップデートでもよく、古いファームウェアバージョンへのアップデートでもよい。例えば、対応するＥＣＵの性能が比較的安定している古いバージョンのファームウェアが、ローカルストレージ、サーバ、またはローカルの外付け記憶装置に格納されている場合、ＥＣＵファームウェアアップデート指令により、ファームウェアアップデートを実行するように異常ＥＣＵに指示してもよい。制御指令を前記異常ＥＣＵに送信した後、該異常ＥＣＵが回復動作を行う旨のメッセージをＣＡＮバスを介してＴＢＯＸにブロードキャストしてから、ＴＢＯＸを利用してＣＳＰサーバに報告してもよい。

【0029】

また、異常な動作状態にある異常ＥＣＵを検出することは、
ＥＣＵから送信される、対応するＥＣＵのトラフィック状態パラメータを含むネットワーク管理メッセージを受信するステップと、
前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定するステップとを含んでもよい。

【0030】

具体的には、例えば、ＴＢＯＸの電源投入後、ＣＳＰサーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを収集し、解析および保存し、ＣＡＮを介してＣＡＮバスの他の検査ノードにブロードキャストしてもよい。これにより、すべての検査ノードは、各ＥＣＵの正常動作状態でのトラフィックパラメータを知ることになる。本実施例において、ＣＳＰサーバによってレコードされた各ＥＣＵトラフィックパラメータのフォーマットは、車全体の各ＥＣＵのネットワーク管理メッセージＩＤが一意であることに基づいて設定してもよい。例えば、一つの具体的なＥＣＵノードを表すＥＣＵのネットワーク管理メッセージＩＤをこのレコードのフラグとする。車全体にはＫＬ１５ ｏｆｆシステム停止状態とＫＬ１５ ｏｎシステム作動状態の２つのキー状態が含まれており、これら２つのキー状態および対応するＥＣＵのトラフィックパラメータを記録してもよい。これにより、本実施例において、ＥＣＵから送信されたネットワーク管理メッセージから現在のＥＣＵのトラフィック状態パラメータを解析により取得して、トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータを比較することにより、ＥＣＵの状態が異常であるか否かを判定することができる。

【0031】

また、ＥＣＵからアップロードされたネットワーク管理メッセージを受信する前に、さらに、
ＥＣＵから送信されるネットワーク管理メッセージを正常に受信できないと判定した場合、前記ＥＣＵの動作状態が異常であると判定することを含んでもよい。

【0032】

もう一つの可能な実施形態において、ＥＣＵがネットワーク管理メッセージを送信できない状態にあれば、ＥＣＵから送信されるネットワーク管理メッセージを正常に受信できない状況に基づいて、ＥＣＵの状態が異常であると直接判定してもよい。例えば、システム作動状態において、サーバから送出された、正常なネットワーク管理メッセージの送信間隔がｔ１であるとすると、ｔ１時間が経過しても、検査ノードが該ＥＣＵのネットワーク管理メッセージを受信できなかった場合、該ＥＣＵの状態が異常であると直接判定してもよい。

【0033】

また、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定するステップは、
前記トラフィック状態パラメータと正常走行時のトラフィック状態パラメータとが一致しない場合、前記ＥＣＵの状態が異常であると判定するステップと、
前記ネットワーク管理メッセージからスリープレディー状態ＲＳＳ（Ｒｅａｄｙ Ｓｌｅｅｐ Ｓｔａｔｅ）情報が抽出され、ＲＳＳにある正常の持続時間を超えた場合、前記ＥＣＵの状態が異常であると判定するステップと、のうちの少なくとも一つを含んでもよい。

【0034】

具体的には、例えばＫＬ１５ ｏｎシステム作動状態において、システム作動状態でのトラフィック状態パラメータと正常走行時のトラフィック状態パラメータとが一致しない場合、前記ＥＣＵの状態が異常であると直接判定してもよい。正常走行時のトラフィック状態パラメータは、電源投入時にサーバから送出されて得てもよく、ローカルストレージを読み取ることで得てもよい。

【0035】

ＫＬ１５ ｏｆｆ状態については、前記ネットワーク管理メッセージから該ＥＣＵに対応するスリープレディー状態ＲＳＳ情報を抽出し、抽出されたＲＳＳ情報をＲＳＳにある正常の持続時間と比較し、ＲＳＳにある正常の持続時間を超えた場合、前記ＥＣＵの状態が異常であると判定してもよい。システム停止状態において、正常な場合、ＲＳＳの時間内にトラフィックが完了するとＲＳＳ状態を終了することになり、ＲＳＳの状態がいつまでも維持されないため、ＲＳＳの状態がいつまでも維持されているのであれば、異常の発生したＥＣＵがあることを意味する。異常ＥＣＵは、すなわちネットワーク管理メッセージを異常に送信し続けているＥＣＵである。対応する各ＥＣＵの最大トラフィック持続時間はすべて、サーバから送出されて得てもよい。

【0036】

前記車両がシステム停止状態にある場合、制御指令を前記異常ＥＣＵに送信する前記ステップは、
前記ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵ停止指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信し、前記異常ＥＣＵがファームウェアアップデートした後も異常である場合、前記ＥＣＵ停止指令を前記異常ＥＣＵに送信するステップと、
のうちの少なくとも一つを含む。

【0037】

具体的な実施過程において、上記方法によりＥＣＵの状態が異常であると判定した後、更に検査ノードにより制御指令を異常ＥＣＵに送信してもよい。前記ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信し、異常ＥＣＵは指令を受信すると再起動を実行するようにしてもよい。

【0038】

あるいは、異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信する。具体的には、再起動による回復が可能であると前記故障コードに基づいて判定することは、以下のように行ってもよい。例えば、既定のコード比較表またはコードデータベースを用いて、異常ＥＣＵの故障コードを特定して既定のコード比較表またはコードデータベースと比較し、再起動による回復が可能であると比較により判定された場合には、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信する。コード記録表に該当する故障コードが記載されていなければ、異常ＥＣＵへの前記ＥＣＵ再起動指令の送信を試みてもよい。再起動して回復に成功した場合、対応する記録表またはデータベースをアップデートして、対応するコードを再起動による回復が可能であるとして記録してもよい。再起動して回復に失敗した場合、対応する記録表またはデータベースをアップデートして、対応するコードを再起動による回復が不可能であるとして記録してもよい。

【0039】

あるいは、前記ＥＣＵ停止指令を前記異常ＥＣＵに直接送信する。異常な動作状態にある異常ＥＣＵが検出されると、ネットワーク管理メッセージを送信しているＥＣＵノードが一つでもあれば、すべてのＥＣＵノードがＣＡＮ ｂｕｓ ｓｌｅｅｐ、すなわち低消費電力状態にはならない。そのため、異常が発生したノードが１つでもあれば、車全体が異常でスリープせず、バッテリあがりが発生する問題を引き起こす。本実施例において、車両がシステム停止状態にある場合、対応する異常ＥＣＵに停止指令を直接送信することにより、異常が発生したノードが１つでもあれば車全体が異常でスリープせず、バッテリあがりが発生する問題を解決することができる。

【0040】

あるいは、前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信する。具体的な故障コード特定方法は上記を参照されたい。本実施例において、車両がシステム停止状態にある場合、対応する異常ＥＣＵに停止指令またはファームウェアアップデートを直接送信することにより、異常が発生したノードが１つでもあれば車全体が異常でスリープせず、バッテリあがりが発生する問題を解決することができる。

【0041】

あるいは、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信する。再起動指令の案と似た方法で、本実施例において、ファームウェアアップデートにより故障ＥＣＵを直接回復させる。

【0042】

あるいは、前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信する。本実施例で言う既定の再起動制御ルールは、再起動回数としてもよい。例えば、再起動指令を三回繰り返し実行する、または、再起動指令を３回繰り返し実行するがその間に指定の間隔をおいてから再起動を実行するなどして、このような再起動制御ルールの実行後も前記ＥＣＵの状態が依然として異常であれば、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信してもよい。再起動制御では異常ＥＣＵを回復させることができないので、ＥＣＵのファームウェアをアップデートまたは直接停止してもよい。

【0043】

あるいは、前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信し、前記異常ＥＣＵがファームウェアアップデートした後も異常である場合、前記ＥＣＵ停止指令を前記異常ＥＣＵに送信する。前述のプロシージャとは異なり、本実施例において、極端な状況に対して、再起動制御ルールでは異常ＥＣＵが回復できず、ファームウェアアップデートでも故障ＥＣＵが回復できない場合、本実施例においては上述の再起動とアップデートの両方の実行が完了した後に、該ＥＣＵに対して停止制御を行うことで、ＥＣＵ故障による電圧レベル不足を回避することができる。

【0044】

また、前記車両がシステム作動状態にある場合、制御指令を前記異常ＥＣＵに送信する前記ステップは、
ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信するステップと、
前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信するステップと、
前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信するステップと、
のうちの少なくとも一つを含んでもよい。

【0045】

具体的には、車両がシステム作動状態にある場合について、制御指令を前記異常ＥＣＵに送信することは、ＥＣＵ再起動指令を前記異常ＥＣＵに直接送信することを含む。また、車両走行中に直接再起動できないＥＣＵもあるので、制御指令を前記異常ＥＣＵに送信する前に、対応する構成項目が前記異常ＥＣＵに設定されているか否かと判定する。対応する構成項目が前記異常ＥＣＵに設定されていると判定した場合、制御指令を前記異常ＥＣＵに送信してもよい。例えば、一つの可能な実施形態としては、ＴＢＯＸの電源投入後、サーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを受信して、この通知メッセージを解析することにより、各ＥＣＵに再起動スイッチが設けられているか否かを判定する。再起動スイッチが設けられていれば、システム作動状態では該ＥＣＵが再起動またはアップデート動作を実行することができることになる。本実施例において、対応する構成項目が異常ＥＣＵに設定されていると判定した場合、ＥＣＵ再起動指令またはアップデート指令を異常ＥＣＵに直接送信することにより、システム作動状態において、状態回復させるようにＥＣＵを制御することができる。

【0046】

あるいは、前記異常ＥＣＵの故障コードを特定し、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信する。具体的な故障コード比較方式は前述の説明を参照されたい。本実施例において、システム作動状態について、再起動による回復が可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ再起動指令を前記異常ＥＣＵに送信することにより、車両走行中のＥＣＵ故障を回復させる。

【0047】

あるいは、前記異常ＥＣＵの故障コードを特定し、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵ停止指令または前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信する。すなわち、システム作動状態について、再起動による回復が不可能であると前記故障コードに基づいて判定した場合、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信してもよい。ファームウェアアップデート後もＥＣＵが依然として異常である場合、使用者に警告して、現在の車両のあるＥＣＵが異常状態にあることを使用者に提示してもよい。もちろん、ファームウェアアップデート後もＥＣＵが依然として異常である場合、対応するＥＣＵの異常状況をサーバ側に送信し、対応する解決策をサーバ側の専門家により人為的に判定し、例えばコードを書き換えるなどすることで、ＥＣＵの異常状態をサーバ側から解決してもよい。

【0048】

もちろん、これに似たように、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに直接送信してもよい。あるいは、前記ＥＣＵ再起動指令を既定の再起動制御ルールに従って前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令に従って前記異常ＥＣＵが再起動した後も異常であることが検出されると、前記ＥＣＵファームウェアアップデート指令を前記異常ＥＣＵに送信してもよい。具体的な実行方式はシステム停止状態での実行方式と同様であるため、ここでは説明を省略する。

【0049】

また、前記ターゲットＥＣＵが複数あり、複数の前記ターゲットＥＣＵの状態が異常である場合、前記ＥＣＵ再起動指令を前記ターゲットＥＣＵに送信するステップは、
前記ＥＣＵ再起動指令を異なる時点で複数の前記ターゲットＥＣＵに送信して、複数の前記ターゲットＥＣＵに異なる時点で再起動を実行させるステップ、
あるいは、
異常状態にある前記ターゲットＥＣＵの割合が設定割合閾値を超えた場合、前記ＥＣＵ再起動指令を再起動順序に従って前記ターゲットＥＣＵに送信するステップを含んでもよい。

【0050】

複数の検査ノードが車両に配置されている場合、本実施例において、各検査ノードは、自身以外のすべてのＥＣＵの動作状態を監視する。検査ノードＥＣＵとして比較的簡単な機能を持つＥＣＵが選択されるが、故障する可能性もあり、極限状況においては検査ノードのＥＣＵが一定期間内に同時に故障する可能性がある。このような状況に対して、本実施例において、前記ＥＣＵ再起動指令を異なる時点で複数の前記ターゲットＥＣＵに送信して、複数の前記ターゲットＥＣＵに異なる時点で再起動を実行させてもよい。すなわち、異なる時点で再起動指令を検査ノードＥＣＵに送信することにより、複数の検査ノードがすべて故障した状況において、すべての検査ノードが同時に再起動しないことを保証する。もちろん、異なる検査ノード再起動時間遅延を設定してもよい。すなわち、再起動指令を即時に且つ同時に発するが、検査ノードは、極限状況において、設定された異なる再起動時間遅延に従って再起動を完了することで、ＥＣＵネットワーク内に少なくとも一つの検査ノードが動作状態にあることを保証してもよい。

【0051】

もちろん、異常状態にある前記ターゲットＥＣＵの割合が設定割合閾値を超えているか否かを監視してもよい。例えば、車両内に４つの検査ノードが配置されているとすると、２つの検査ノードに異常が発生した場合、２つの検査ノードのＥＣＵを直接再起動させてもよい。現在の検査ノード以外の３つの検査ノードにすべて異常が発生した場合、異なる再起動優先度で再起動順序を決定してから、順次再起動させてもよい。各ＥＣＵの再起動に一定の時間間隔を設ける。例えば、あるＥＣＵの再起動完了所要時間が２ｍｉｎであれば、順次再起動の時間間隔を２ｍｉｎに設定してもよい。

【0052】

以上のように、本実施例によれば、車全体のＥＣＵノードから、機能が比較的安定している複数のノードを検査ノードとして選択して、ＣＡＮバスに対する検知により他のＥＣＵノードの動作状態を監視し、車載移動通信端末ＴＢＯＸを介して、サーバＣＳＰ側から送出される通知メッセージを受信し、各ＥＣＵのトラフィック最長持続時間およびＥＣＵのトラフィック動作ロジックを設定してから、ＴＢＯＸによりこのメッセージを他の検査ノードにブロードキャストすることが可能である。あるＥＣＵの動作異常が検査ノードにより検出され、そのトラフィック最長持続時間を超えたことが確認された場合、該ノードが異常であるとみなして、車全体の状態を判断する。重大な故障とみなされ且つその再起動条件が満たされている場合、ＣＡＮ再起動のダイアグノーシス指令を該ＥＣＵに送信し、該ＥＣＵを再起動させて初期状態に回復させ、さらに正常に回復させる。そうでなければ、異常をサーバに送信し、サーバ側で人為的に判断と操作を行って、問題の初歩的な分析を行い、再起動して解決できる問題であれば、サーバ側からあるＥＣＵを再起動させればよく、自動車ディーラーに行く必要はない。これにより、異常ノードの異常動作状態が長時間維持されないことが保証される。もちろん、車両がシステム停止状態にある場合、本実施例の方法によれば、ＥＣＵ異常によるバッテリあがりを回避し、使用者の車両使用体験を向上させることができる。

【0053】

第２の実施例
本実施例において、車両における電子制御ユニットの管理方法を提案する。図３を参照し、この方法は以下のステップを含む。

【0054】

Ｓ３０１において、ＴＢＯＸを介してＣＳＰサーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを受信し、車両に配置されている他の検査ノードＥＣＵにブロードキャストする。

【0055】

Ｓ３０２において、検査ノードは車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視する。

【0056】

Ｓ３０３において、異常な動作状態にある異常ＥＣＵが検出されると、検査ノードは、制御指令を前記異常ＥＣＵに送信し、前記制御指令は、対応する回復動作をするように前記異常ＥＣＵをトリガするように構成されている。

【0057】

具体的には、検査ノードとして選択可能なものは、車載移動通信端末ＴＢＯＸとターゲットＥＣＵとを含んでもよいが、もちろん、そのうちの一つのみを選択してもよく、ＴＢＯＸとターゲットＥＣＵを組み合わせて選択してもよい。例えば、本実施例において、ＴＢＯＸと複数のターゲットＥＣＵを組み合わせて選択してもよい。本実施例において、前記ターゲットＥＣＵとしては、ＥＣＵの実際の動作パフォーマンスまたはＥＣＵの機能複雑度に応じて、動作が比較的安定しているＥＣＵまたは機能複雑度の低いＥＣＵを検査ノードとして選択してから、検査ノードであるＥＣＵを用いて、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視するようにしてもよい。

【0058】

ＴＢＯＸの電源投入後、ＣＳＰサーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを収集し、解析および保存し、ＣＡＮを介してＣＡＮバスの他の検査ノードにブロードキャストしてもよい。これにより、すべての検査ノードは、各ＥＣＵの正常動作状態でのトラフィックパラメータを知ることになる。本実施例において、ＣＳＰサーバによってレコードされた各ＥＣＵトラフィックパラメータのフォーマットは、車全体の各ＥＣＵのネットワーク管理メッセージＩＤが一意であることに基づいて設定してもよい。例えば、一つの具体的なＥＣＵノードを表すＥＣＵのネットワーク管理メッセージＩＤをこのレコードのフラグとする。ＥＣＵから検査ノードに送信されるネットワーク管理メッセージにはＫＬ１５ ｏｆｆシステム停止状態とＫＬ１５ ｏｎシステム作動状態の２つのキー状態が含まれてもよい。検査ノードはこれら２つのキー状態を記録してもよい。ネットワーク管理メッセージには対応するＥＣＵのトラフィックパラメータがさらに含まれてもよい。これにより、本実施例において、ＥＣＵから送信されたネットワーク管理メッセージから現在のＥＣＵのトラフィック状態パラメータを解析により取得して、トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータを比較することにより、ＥＣＵの状態が異常であるか否かを判定することもできる。

【0059】

具体的な監視手段としては、対応する物理アドレスを各ＥＣＵに割り当て、対応する物理アドレスに基づいてＥＣＵの動作状態を監視してもよい。もちろん、対応する物理アドレスに基づいて制御指令を前記異常ＥＣＵに送信してもよい。本実施例によれば、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信することにより、実施過程によっては、異常ＥＣＵが制御指令に従って対応する回復動作を実行できるため、車全体のＥＣＵの動作安定性を向上させ、ＥＣＵの異常による車のバッテリあがりを避けて、使用者の体験を向上させることができる。

【0060】

また、前記制御指令は、前記異常ＥＣＵによる再起動の実行をトリガするためのＥＣＵ再起動指令と、前記異常ＥＣＵによる停止の実行をトリガするためのＥＣＵ停止指令と、前記異常ＥＣＵによるファームウェアアップデートの実行をトリガするためのＥＣＵファームウェアアップデート指令と、のうちの少なくとも一つを含んでもよい。

【0061】

本実施例において、システム停止状態で再起動するようにＥＣＵを制御する場合を例に挙げて説明するが、図４に示すように、本実施例の方法は、以下のステップを含む。

【0062】

Ｓ４０１において、ＥＣＵから送信される、対応するＥＣＵのトラフィック状態パラメータを含むネットワーク管理メッセージを受信する。

【0063】

Ｓ４０２において、車両がシステム停止状態にあると判定する。

【0064】

Ｓ４０３において、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定する。

【0065】

Ｓ４０４において、異常な動作状態にある異常ＥＣＵが検出されると、検査ノードは、ＥＣＵ再起動指令を前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令は、対応する再起動動作をするように前記異常ＥＣＵをトリガするように構成されている。

【0066】

具体的な実現過程において、本願の方法によれば、検査ノードは、受信されたＥＣＵネットワーク管理メッセージのＩＤに基づいて動作し、このＩＤはあるＥＣＵを表し、すなわち、このＥＣＵがスリープレディー状態ＲＳＳ状態以外にあることを意味し、このＥＣＵがネットワークの異常が維持される原因である可能性があるため、次の判定を行う。

【0067】

ＫＬ１５の状態を判断し、ＫＬ１５がＣＡＮネットワークの正常動作を必要とする状態にある場合、現時点でこの異常監視プロセスを継続する必要はなく、すなわち現時点でＥＣＵの動作状態が正常であるとみなして、対処しない。ＫＬ１５がＣＡＮネットワークの正常動作を必要としない状態にある場合、次のステップに進む。

【0068】

ネットワーク管理メッセージに対応するＥＣＵがスリープレディー状態ＲＳＳ状態であるか否かを判定する。ＲＳＳ状態でない場合、現時点で異常監視プロセスを開始する必要はなく、ＥＣＵ自身がＣＡＮネットワークの維持が必要であると考えていることを示している。この検査ＥＣＵ異常がＣＡＮネットワークを維持する場合、他の検査ＥＣＵノードがこの異常を検出すると、異常保護プロセスを開始し、この異常判断基準はＡｕｔｏＳａｒのネットワーク管理プロトコルに基づいて得ることができる。

【0069】

本実施例において、システム停止状態において、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定するステップは、前記ネットワーク管理メッセージからスリープレディー状態ＲＳＳ情報が抽出され、ＲＳＳにある正常の持続時間を超えた場合、前記ＥＣＵの状態が異常であると判定するステップを含む。

【0070】

ＫＬ１５ ｏｆｆ状態については、前記ネットワーク管理メッセージから該ＥＣＵに対応するスリープレディー状態ＲＳＳ情報を抽出し、抽出されたＲＳＳ情報をＲＳＳにある正常の持続時間と比較し、ＲＳＳにある正常の持続時間を超えた場合、前記ＥＣＵの状態が異常であると判定してもよい。システム停止状態において、正常な場合、ＲＳＳの時間内にトラフィックが完了するとＲＳＳ状態を終了することになり、ＲＳＳの状態がいつまでも維持されないため、ＲＳＳの状態がいつまでも維持されているのであれば、異常の発生したＥＣＵがあることを意味する。異常ＥＣＵは、すなわちネットワーク管理メッセージを異常に送信し続けているＥＣＵである。対応する各ＥＣＵの最大トラフィック持続時間はすべて、サーバから送出されて得てもよい。

【0071】

一つの可能な実現方式として、ネットワーク管理メッセージが今回ＲＳＳにある時間を計算し、ネットワーク管理メッセージで提供される状態に基づいて今回のネットワーク管理がＲＳＳ状態に入った時間を計算することで、今回ＲＳＳが維持されている時間を判断する。正常な場合、ＲＳＳの時間内にトラフィックが完了するとＲＳＳ状態を終了することになり、ＲＳＳの状態がいつまでも維持されないため、ＲＳＳの状態がいつまでも維持されているのであれば、異常の発生したＥＣＵがあることを意味する。異常ＥＣＵは、すなわちネットワーク管理メッセージを異常に送信し続けているＥＣＵである。

【0072】

今回ＲＳＳにある時間が対応するＥＣＵトラフィックの最大時間を超えているか否かを判定する。車全体における各ＥＣＵのＣＡＮネットワークに関連するトラフィックにはいずれもその最大持続時間が存在し、具体的にはサーバから送出された通知メッセージから解析して得てもよい。ＲＳＳの維持時間が、受信された、該メッセージのＩＤに対応するＥＣＵの最大トラフィック時間を超えている場合、該ＥＣＵトラフィックは異常であるとみなし、異常保護プロセスを継続する。

【0073】

ＥＣＵの状態が異常であると判定された場合、検査ノードは、再起動指令を対応するＥＣＵに送信する。ＵＤＳサービス０ｘ１１再起動指令を送信してもい。もちろん、ＵＤＳ指令である異常指令を自分で定義してもよく、この指令を受信したＥＣＵが自分のＣＡＮネットワークの異常を知り、自分で動作してＣＡＮネットワークを回復させ、すべてのＣＡＮに関連する状態をリセットする。

【0074】

最後に、検査ノードは、該ＥＣＵの異常再起動メッセージをＣＡＮメッセージを通じてＴＢＯＸにブロードキャストし、ＴＢＯＸはそれをＣＳＰサーバに報告する。

【0075】

再起動で問題が解決できない場合、サーバ側から人為的に判定することで、異常状態の解決策を決定してもよい。他のシステム停止状態での指令操作は、上述したプロセスに似ているため、本実施例では説明を省略する。

【0076】

以上のように、本願の実施例によれば、システム停止状態で再起動するように異常ＥＣＵを制御することにより、異常ノードの異常動作状態が長時間維持されないことを保証する。もちろん、車両がシステム停止状態にある場合、本実施例の方法によれば、ＥＣＵ異常によるバッテリあがりを回避し、使用者の車両使用体験を向上させることができる。

【0077】

第３の実施例
本願の第３の実施例は、車両における電子制御ユニットの管理方法を提案する。図５に示すように、この方法は以下のステップを含む。

【0078】

Ｓ５０１において、ＴＢＯＸを介してＣＳＰサーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを受信し、車両に配置されている他の検査ノードＥＣＵにブロードキャストする。

【0079】

Ｓ５０２において、検査ノードは車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視する。

【0080】

Ｓ５０３において、異常な動作状態にある異常ＥＣＵが検出されると、検査ノードは、制御指令を前記異常ＥＣＵに送信し、前記制御指令は、対応する回復動作をするように前記異常ＥＣＵをトリガするように構成されている。

【0081】

具体的には、検査ノードとして選択可能なものは、車載移動通信端末ＴＢＯＸとターゲットＥＣＵとを含んでもよいが、もちろん、そのうちの一つのみを選択してもよく、ＴＢＯＸとターゲットＥＣＵを組み合わせて選択してもよい。例えば、本実施例において、ＴＢＯＸと３つのターゲットＥＣＵを組み合わせて選択してもよい。本実施例において、前記ターゲットＥＣＵとしては、ＥＣＵの実際の動作パフォーマンスまたはＥＣＵの機能複雑度に応じて、動作が比較的安定しているＥＣＵまたは機能複雑度の低いＥＣＵを検査ノードとして選択してから、検査ノードであるＥＣＵを用いて、車両における少なくとも一つの電子制御ユニットＥＣＵの動作状態を監視するようにしてもよい。

【0082】

ＴＢＯＸの電源投入後、ＣＳＰサーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを収集し、解析および保存し、ＣＡＮを介してＣＡＮバスの他の検査ノードにブロードキャストしてもよい。これにより、すべての検査ノードは、各ＥＣＵの正常動作状態でのトラフィックパラメータを知ることになる。本実施例において、ＣＳＰサーバによってレコードされた各ＥＣＵトラフィックパラメータのフォーマットは、車全体の各ＥＣＵのネットワーク管理メッセージＩＤが一意であることに基づいて設定してもよい。例えば、一つの具体的なＥＣＵノードを表すＥＣＵのネットワーク管理メッセージＩＤをこのレコードのフラグとする。ＥＣＵから検査ノードに送信されるネットワーク管理メッセージにはＫＬ１５ ｏｆｆシステム停止状態とＫＬ１５ ｏｎシステム作動状態の２つのキー状態が含まれてもよい。検査ノードはこれら２つのキー状態を記録してもよい。ネットワーク管理メッセージには対応するＥＣＵのトラフィックパラメータがさらに含まれてもよい。これにより、本実施例において、ＥＣＵから送信されたネットワーク管理メッセージから現在のＥＣＵのトラフィック状態パラメータを解析により取得して、トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータを比較することにより、ＥＣＵの状態が異常であるか否かを判定することもできる。

【0083】

具体的な監視手段としては、対応する物理アドレスを各ＥＣＵに割り当て、対応する物理アドレスに基づいてＥＣＵの動作状態を監視してもよい。もちろん、対応する物理アドレスに基づいて制御指令を前記異常ＥＣＵに送信してもよい。本実施例によれば、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信することにより、実施過程によっては、異常ＥＣＵが制御指令に従って対応する回復動作を実行できるため、車全体のＥＣＵの動作安定性を向上させ、ＥＣＵの異常による車のバッテリあがりを避けて、使用者の体験を向上させることができる。

【0084】

また、前記制御指令は、前記異常ＥＣＵによる再起動の実行をトリガするためのＥＣＵ再起動指令と、前記異常ＥＣＵによる停止の実行をトリガするためのＥＣＵ停止指令と、前記異常ＥＣＵによるファームウェアアップデートの実行をトリガするためのＥＣＵファームウェアアップデート指令と、のうちの少なくとも一つを含んでもよい。

【0085】

本実施例において、システム作動状態で再起動するようにＥＣＵを制御する場合を例に挙げて説明するが、図６に示すように、本実施例の方法は、以下のステップを含む。

【0086】

Ｓ６０１において、ＥＣＵから送信される、対応するＥＣＵのトラフィック状態パラメータを含むネットワーク管理メッセージを受信する。

【0087】

Ｓ６０２において、車両がシステム作動状態にあると判定する。

【0088】

Ｓ６０３において、前記トラフィック状態パラメータと前記ＥＣＵに対応する正常なトラフィック状態パラメータとの比較に基づいて、前記ＥＣＵの状態が異常であると判定する。

【0089】

Ｓ６０４において、異常な動作状態にある異常ＥＣＵが検出されると、対応する構成項目が異常ＥＣＵに設定されているか否かと判定する。

【0090】

Ｓ６０５において、対応する構成項目が異常ＥＣＵに設定されていると判定されると、検査ノードは、ＥＣＵ再起動指令を前記異常ＥＣＵに送信し、前記ＥＣＵ再起動指令は、対応する再起動動作をするように前記異常ＥＣＵをトリガするように構成されている。

【0091】

Ｓ６０６において、対応する構成項目が異常ＥＣＵに設定されていないと判定されると、検査ノードは、異常ＥＣＵをサーバに報告するとともに、サーバから送出された再起動指令を受信し解析してから異常ＥＣＵに送信する。

【0092】

本実施例では、システム作動走行状態での電子制御ユニットの管理方法に対応する。システム作動状態において、検査ノードは、ＣＡＮバスを利用して他のＥＣＵの、ＥＣＵのトラフィック状態が保持されているＡＰＰメッセージを受信する。

【0093】

そして、メッセージに基づいてＫＬ１５の状態を判断し、ＫＬ１５がＯＮであれば本プロセスを続行し、そうでなければプロセスを終了する。

【0094】

本実施例におけるシステム作動状態でのＥＣＵ異常判定には、以下の２つの方法を含んでもよい。

【0095】

ＥＣＵから送信されるネットワーク管理メッセージを正常に受信できないと判定した場合、前記ＥＣＵの動作状態が異常であると判定する。

【0096】

一つの任意の実施形態において、ＥＣＵがネットワーク管理メッセージを送信できない状態にあれば、ＥＣＵから送信されるネットワーク管理メッセージを正常に受信できない状況に基づいて、ＥＣＵの状態が異常であると直接判定してもよい。例えば、システム作動状態において、サーバから送出された、正常なネットワーク管理メッセージの送信間隔がｔ１であるとすると、ｔ１時間が経過しても、検査ノードが該ＥＣＵのネットワーク管理メッセージを受信できなかった場合、該ＥＣＵの状態が異常であると直接判定してもよい。

【0097】

サーバから送出された、対応するＥＣＵのトラフィック状態に基づいて、メッセージ内のＥＣＵのトラフィック状態を比較し、現在のメッセージ内のトラフィック状態とレコードのトラフィック状態とが一致するか否かを判定する。

【0098】

もう一つの形態において、例えばＫＬ１５ ｏｎシステム作動状態において、システム作動状態でのトラフィック状態パラメータとサーバから送出された正常走行時のトラフィック状態パラメータとが一致しない場合、前記ＥＣＵの状態が異常であると直接判定してもよい。正常走行時のトラフィック状態パラメータは、電源投入時にサーバから送出されて得てもよく、ローカルストレージを読み取ることで得てもよい。

【0099】

ＥＣＵが異常であると判定された後、本実施例において、異常が確認された時点を開始時点として異常時間を累積してもよい。もちろん、その代わりに、ＥＣＵが正常であると判定された場合、異常時間をゼロにリセットしてもよい。異常時間を累積した後に、さらに異常時間の累積値が設定された最大異常時間を超えているか否かを判定する。最大異常時間を超えたと判定してから、さらに、対応する構成項目が異常ＥＣＵに設定されているか否かを判定する。構成項目について、一つの任意の実施形態としては、ＴＢＯＸの電源投入後、サーバから送出された、各ＥＣＵのトラフィックパラメータを保持している通知メッセージを受信して、この通知メッセージを解析することにより、各ＥＣＵに再起動スイッチが設けられているか否かを判定し、再起動スイッチが設けられていれば、システム作動状態では該ＥＣＵが再起動動作を実行することができることになる。本実施例において、対応する構成項目が異常ＥＣＵに設定されていると判定した場合、ＥＣＵ再起動指令を異常ＥＣＵに直接送信することにより、システム作動状態において、状態回復させるようにＥＣＵを制御することができる。

【0100】

対応する構成項目が異常ＥＣＵに設定されていないと判定されると、検査ノードは、ＥＣＵのトラフィック状態が異常である旨の緊急イベントをＴＢＯＸに報告し、さらにＴＢＯＸによりＣＳＰサーバに報告し、ＣＳＰサーバにより装置を再起動させる必要があるか否かを判定する。該ＥＣＵを再起動させる必要があるとサーバ側で判定された場合、ＴＢＯＸはサーバから送出された再起動指令を受信し解析してから、対応するＥＣＵに送信する。

【0101】

以上のように、本願の実施例によれば、システム作動状態で再起動するように異常ＥＣＵを制御することにより、異常ノードの異常動作状態が長時間維持されないことを保証する。これにより、車両の安定した運転を保証し、使用者が自動車ディーラーに行く回数を効果的に減らし、使用者の車両使用体験を向上させる。

【0102】

第４の実施例
本願の実施例はさらに、電子制御ユニットを提供する。前記電子制御ユニットは、プロセッサと、メモリと、通信バスとを備える。
前記通信バスは、プロセッサとメモリとの間の接続や通信を実現するように構成されている。
前記プロセッサは、メモリに記憶されている一つまたは複数のコンピュータプログラムを実行することで、第１、第２、および第３の実施例の車両における電子制御ユニットの管理方法のステップを実現するように構成されている。

【0103】

本願の実施例はさらに、自動車を提供し、前記自動車は前述の電子制御ユニットを備える。

【0104】

本願の実施例はさらに、コンピュータ可読記憶媒体を提供する。前記コンピュータ可読記憶媒体には、一つまたは複数のコンピュータプログラムが記憶されており、前記一つまたは複数のプログラムは、一つまたは複数のプロセッサにより実行されることで、第１、第２、および第３の実施例の車両おける電子制御ユニットの管理方法のステップを実現できる。

【0105】

本願の実施例により提供される車両におけるＥＣＵの管理方法、ＥＣＵ、自動車および可読記憶媒体によれば、異常な動作状態にある異常ＥＣＵが検出されると、制御指令を前記異常ＥＣＵに送信することにより、実施過程によっては、異常ＥＣＵが制御指令に従って対応する回復動作を実行できるため、車全体のＥＣＵの動作安定性を向上させ、ＥＣＵの異常による車のバッテリあがりを避けて、使用者の体験を向上させることができる。

【0106】

これにより分かるように、上記で開示された方法のステップの全てまたは一部、システム、装置における機能モジュール／ユニットは、ソフトウェア（コンピューティング装置によって実行可能なコンピュータプログラムコードによって実装できる）、ファームウェア、ハードウェア、及びそれらの適切な組み合わせとして実装されてもよい。ハードウェアによる実施形態において、上記説明で言及された機能モジュール／ユニット間の区分は、物理的組立体の区分に必ずしも対応しているとは限らず、例えば、一つの物理的組立体は複数の機能を有してもよく、または、一つの機能またはステップはいくつかの物理的組立体によって協働して実行されてもよい。いくつかの物理的組立体またはすべての物理的組立体は、中央処理装置、デジタルシグナルプロセッサまたはマイクロプロセッサのようなプロセッサによって実行されるソフトウェアとして、あるいはハードウェアとして、あるいは特定用途向け集積回路のような集積回路として実施されてもよい。

【0107】

さらに、通信媒体は通常、コンピュータ可読指令、データ構造、コンピュータプログラムモジュール、または搬送波もしくは他の伝送メカニズムのような変調データ信号中の他のデータを含み、任意の情報伝送媒体を含んでもよい。したがって、本願は、いかなる特定のハードウェア及びソフトウェアの組み合わせにも限定されない。

【0108】

以上の内容は、本願の実施例を具体的な実施形態を合わせてさらに詳しく説明したものであり、本願の具体的な実施例がこれらの説明に限定されると認めるべきではない。本願が属する技術分野の当業者にとって、本願の発明構想を逸脱することなく、いくつかの簡単な推断演繹または置換を行うことができ、それらはいずれも本願の保護範囲に属するとみなすべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】