JP6189004B1 - 共用バックアップユニットおよび制御システム - Google Patents

Abstract

共用バックアップＥＣＵ（１０１）において、診断部（１３２）は、個別の機能を発揮するために機能によって異なるプログラムを実行する複数のＥＣＵの異常を診断する。ロード部（１３５）は、複数のプログラムをあらかじめ記憶するメモリから、診断部（１３２）により異常が検知されたＥＣＵである異常ユニットが実行するプログラムと同じプログラムをロードする。実行部（１３１）は、ロード部（１３５）によりロードされたプログラムを実行することで、異常ユニットの代わりに異常ユニットの機能と同じ機能を発揮する。

Description

本発明は、共用バックアップユニットおよび制御システムに関するものである。

市販されている自動車に搭載されるＥＣＵでは、自己診断機能が追加されている。「ＥＣＵ」は、Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔの略語である。不具合が発生した瞬間のデータは記憶され、修理の際に参考資料とされている。ＥＣＵへの入力信号に異常が発生した場合、入力信号をＥＣＵ内に記憶されている標準値または基準値に切り替えることで、車の走行を可能にして、機能安全の確保が図られている。ＥＣＵに異常が発生すると、出力をバックアップＩＣによる固定信号に切り替えることによって、車を走行可能にして、機能安全の確保が図られている。「ＩＣ」は、Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。

昨今、国家的に開発が推進されている自動運転システムでは、事故を防ぐ観点から安全面での設計が非常に重視されている。現在の自動車そのものが、非常に複雑化したシステムとなっている。安全性の確保を図るために、自動車用の国際安全規格であるＩＳＯ ２６２６２が策定されている。ＩＳＯ ２６２６２では、機能安全を系統的に管理する枠組みが定められている。自動車のシステム、ハードウェアおよびソフトウェアのレベルにて、製品開発プロセスが規定されている。この枠組みの中で、自動車特有のリスクに基づいた方式で、リスク段階が定められている。ＡＳＩＬにてシステムの構成要素が整理されている。「ＡＳＩＬ」は、Ａｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌの略語である。

ＡＳＩＬに基づいた機能分類については、非特許文献１に位置付け、すなわち、相場観の例が紹介されている。例えば、曲がる機能でのアシスト喪失、および、走る機能の駆動力喪失は、ＡＳＩＬ Ａ以上の比較的緩いレベルである。一方、止まる機能の制動機能喪失、および、曲がる機能のステアリングロックは、ＡＳＩＬ Ｃ以上の重大レベルに位置付けられている。自動車の各種機能のリスク管理を考慮した設計が要求されている。

特に自動運転システムとして、制御処理の中枢となっているＥＣＵの実装では、一部のハードウェア故障が発生しても制御不能とならないように、宇宙ロケットおよび航空機と同様に多重系の仕組みが採用されている。多重系の中の１系統分が故障しても、残る１系統が正常動作可能であれば、ＥＣＵは、実行処理を継続できる。このＥＣＵは、一般にＡＤＡＳ ＥＣＵと呼ばれている。「ＡＤＡＳ」は、Ａｄｖａｎｃｅｄ Ｄｒｉｖｅｒ Ａｓｓｉｓｔａｎｃｅ Ｓｙｓｔｅｍの略語である。

自動運転システムの多重系の構成例を図１５に示す。図中の２つの判断ＥＣＵ３１１は、自動運転の経路判定処理を行うＥＣＵであり、２重系を構成している。２つの判断ＥＣＵ３１１の出力情報は、切替器３６１により比較される。一致しなかった場合、故障として判定されて、故障している判断ＥＣＵ３１１がＣＡＮ７１１から切り離される。「ＣＡＮ」は、Ｃｏｎｔｒｏｌｌｅｒ Ａｒｅａ Ｎｅｔｗｏｒｋの略語である。図中の３つの制御ＥＣＵ２１１は、エンジンおよびハンドルの制御を行うＥＣＵであり、３重系を構成している。３つの制御ＥＣＵ２１１の出力情報は、切替器２６１により比較される。一致しなかった場合、多数決で少数だった制御ＥＣＵ２１１が故障として判定されてＣＡＮ７１１から切り離される。

自動運転システム以外の用途でも、自動車は数多くのＥＣＵを搭載するようになってきている。搭載されるＥＣＵの数も近年、顕著な増加傾向にある。例えば、環境対策の排出ガス削減および低燃費化のためのエンジン制御、事故対応の高度安全機能のためのエアバッグ制御、歩行者検知システムおよびブレーキアシスト機能、ならびに、ドライバの利便性のためのＥＴＣ（登録商標）およびカーナビゲーションシステム等、多数の新しいＥＣＵが次々に追加されてきている。「ＥＴＣ」は、Ｅｌｅｃｔｒｏｎｉｃ Ｔｏｌｌ Ｃｏｌｌｅｃｔｉｏｎ Ｓｙｓｔｅｍの略語である。

重要な機能をＥＣＵが受け持つようになってきている。しかし、故障対応のために単純に多数のＥＣＵ系統を多重化していくと、ハードウェアコストの大幅な増加が避けられなくなる。

以下に、多重系の事例として公開されているウェブサイト情報を示す。

非特許文献２に記載されている技術では、基本的なサブシステムが多重系にされ、片系が故障したら別の系が補完する機能が実装されている。この技術におけるＥＣＵは、万が一故障した場合でも、必ず安全な方向に処理するフェイルセーフ機構を備えている。

非特許文献３では、自動車ステアバイワイヤ制御の３重系ＥＣＵについて紹介されている。３台のＥＣＵによる多数決に基づく、縮退と継続とを含むフェールオペレーショナルの安全アーキテクチャとなっている。

非特許文献４には、センサまたは走行制御ＥＣＵ内のマイクロコンピュータに故障または暴走が発生した場合、異常を検出し、自動的に故障系を切り離し、異常動作を防止できるＥＣＵを開発することが記載されている。

非特許文献５に記載されている技術では、ＥＣＵがＡ系ＣＰＵとＢ系ＣＰＵとから構成されている。「ＣＰＵ」は、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔの略語である。Ａ系ＣＰＵおよびＢ系ＣＰＵは、同一の入力情報をもとに同一のプログラムによって演算を行う。演算結果は、それぞれの系のメモリに格納される。メモリに格納されている演算結果は、ＦＳ比較回路にて照査されている。「ＦＳ」は、Ｆａｉｌ Ｓａｆｅの略語である。一致状態が継続中、ＦＳリレーはオン状態となり、出力状態である。不一致が発生した場合、ＦＳリレーはオフ状態となり、出力遮断状態となる。

以下に、多重系を拡張的に採用している特許文献を示す。

特許文献１には、エンジンＥＣＵの多重化に関する技術が記載されている。この技術では、単純にエンジンＥＣＵが多重化されているだけでなく、エンジンＥＣＵが互いに役割を分担し、故障時に動的に役割を変える。

特許文献２に記載されている技術では、複数の実行系ノードに対して、それぞれ仕様が異なる複数の待機系ノードが用意される。１つの実行系ノードに障害が発生した場合、障害の要因を取り除ける待機系ノードが選択され、選択された待機系ノードがデータ処理を引き継ぐ。

特許文献３に記載されている技術では、同一ネットワーク上の２重系構成の計算機の一方が他方を監視し、障害発生時に他方を電源断にしてネットワークから切り離す。

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

"車載システム開発時に使用するソフトウェアツールをＩＳＯ ２６２６２の要求事項に準拠させるための作業項目の抽出と考察"、［ｏｎｌｉｎｅ］、２０１３年２月、独立行政法人情報処理推進機構、［２０１７年１月１０日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｉｐａ．ｇｏ．ｊｐ／ｆｉｌｅｓ／００００２６８５９．ｐｄｆ〉 "自動運転"、［ｏｎｌｉｎｅ］、一般財団法人日本自動車研究所、［２０１７年１月１０日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｊａｒｉ．ｏｒ．ｊｐ／ｔａｂｉｄ／１１１／Ｄｅｆａｕｌｔ．ａｓｐｘ〉 金子 貴信、中村 英夫、"高度運転支援システムにおける安全アーキテクチャの調査"、［ｏｎｌｉｎｅ］、２０１５年６月、ＪＡＲＩ Ｒｅｓｅａｒｃｈ Ｊｏｕｒｎａｌ、［２０１７年１月１０日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｊａｒｉ．ｏｒ．ｊｐ／Ｐｏｒｔａｌｓ／０／ｒｅｓｏｕｒｃｅ／ＪＲＪ＿ｑ／ＪＲＪ２０１５０６０７＿ｑ＿．ｐｄｆ〉 青木 啓二、"自動運転技術の開発動向と実用化に向けた課題"、［ｏｎｌｉｎｅ］、２０１４年１月２４日、ＩＳＩＴカーエレクトロニクス研究会、［２０１７年１月１０日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｃａｒ−ｅｌｅｃｔｒｏｎｉｃｓ．ｊｐ／ｆｉｌｅｓ／２０１３／１１／ＣＥＷ１４＿ａｏｋｉ．ｐｄｆ〉 "自動運転・隊列走行技術の研究開発"、［ｏｎｌｉｎｅ］、国立研究開発法人新エネルギー・産業技術総合開発機構、［２０１７年１月１０日検索］、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｎｅｄｏ．ｇｏ．ｊｐ／ｃｏｎｔｅｎｔ／１０００９５９１２．ｐｄｆ〉

これまでの自動車システムでは、故障時対応のために重要なＥＣＵ系統を多重化する設計がなされてきた。しかし、ＥＣＵの数は、近年、顕著な増加傾向にある。そのため、多数のＥＣＵ系統を多重化すると、ハードウェアコストの大幅な増加が避けられなくなる。

具体的なハードウェアとしては、ＥＣＵのマイクロコンピュータだけでなく、搭載基板、ネットワークインタフェース等の周辺機器、ネットワークケーブル、筐体等が増加する。配線も増加し、配線設置、製作および保守の工数が増大する。これは、自動車の価格上昇をもたらし、利用者の負担増加につながる。

搭載電子機器の数が増加することで、消費される電力も増加することになる。これは、搭載されるバッテリ容量を大きくする必要性にもつながる。

本発明は、少ないハードウェアでＥＣＵの実質的な多重化を可能にすることを目的とする。

本発明の一態様に係る共用バックアップユニットは、
個別の機能を発揮するために機能によって異なるプログラムを実行する複数の電子制御ユニットの異常を診断する診断部と、
複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、
前記ロード部によりロードされたプログラムを実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部とを備える。

本発明では、共用バックアップユニットが、各ＥＣＵを動的に代替できる。そのため、１つ１つのＥＣＵに対してバックアップユニットを個別に用意しなくても、各ＥＣＵの実質的な多重化が可能になる。すなわち、本発明によれば、少ないハードウェアでＥＣＵの実質的な多重化が可能になる。

実施の形態１に係る制御システムの構成を示すブロック図。 実施の形態１に係る制御システムのハードウェア構成を示すブロック図。 実施の形態１におけるマルチタスクの周期処理の例を示す図。 実施の形態１に係る共用バックアップＥＣＵの構成を示すブロック図。 実施の形態１に係る共用バックアップＥＣＵへの処理の引き継ぎ例を示す図。 実施の形態１に係る共用バックアップＥＣＵ内の管理テーブルの例を示す表。 実施の形態１に係る共用バックアップＥＣＵの動作を示すフローチャート。 実施の形態１に係る共用バックアップＥＣＵの退避対象ＳＷＣ選定処理の手順を示すフローチャート。 実施の形態２に係る共用バックアップＥＣＵ内の管理テーブルの例を示す表。 実施の形態２に係る共用バックアップＥＣＵの退避対象ＳＷＣ選定処理の手順を示すフローチャート。 実施の形態３に係る共用バックアップＥＣＵの構成を示すブロック図。 実施の形態３に係る共用バックアップＥＣＵへの処理の引き継ぎ例を示す図。 実施の形態３におけるアクセルペダルおよびエンジンスロットルの出力制御曲線の例を示すグラフ。 実施の形態３に係る共用バックアップＥＣＵの動作を示すフローチャート。 従来の自動運転システムの多重系の構成例を示すブロック図。

以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態のうち、２つ以上の実施の形態が組み合わせられて実施されても構わない。あるいは、以下に説明する実施の形態のうち、１つの実施の形態または２つ以上の実施の形態の組み合わせが部分的に実施されても構わない。

実施の形態１．
本実施の形態について、図１から図８を用いて説明する。

＊＊＊構成の説明＊＊＊
図１を参照して、本実施の形態に係る制御システム１００の構成を説明する。

制御システム１００は、個別の機能を発揮するために、機能によって異なるプログラムを実行する複数の電子制御ユニットと、これら複数の電子制御ユニットのうち、任意の電子制御ユニットを代替可能な共用バックアップユニットとを備える。

本実施の形態において、制御システム１００は、自動運転システムに相当する。

制御システム１００は、複数の電子制御ユニットとして、制御ＥＣＵ２０１および判断ＥＣＵ３０１を備える。判断ＥＣＵ３０１は、運転経路を判断する機能を発揮するために、運転経路の判断処理を行うプログラムである判断ＳＷＣ３０２を実行する電子制御ユニットである。「ＳＷＣ」は、Ｓｏｆｔｗａｒｅ Ｃｏｍｐｏｎｅｎｔの略語である。制御ＥＣＵ２０１は、エンジンまたはハンドルを制御する機能を発揮するために、エンジンまたはハンドルの制御処理を行うプログラムである制御ＳＷＣ２０２を実行する電子制御ユニットである。

制御システム１００は、共用バックアップユニットとして、共用バックアップＥＣＵ１０１を備える。共用バックアップＥＣＵ１０１は、制御ＥＣＵ２０１および判断ＥＣＵ３０１のどちらかが故障した際にバックアップとして機能する共用バックアップユニットである。

実際のケースでは、複数のＥＣＵの故障に備えて、システム全体で複数の共用バックアップＥＣＵ１０１が用意されることになる。第１の共用バックアップＥＣＵ１０１自体が故障した際にも、第２および第３の共用バックアップＥＣＵ１０１への切り替えができるようになる。すなわち、制御システム１００は、少なくとも１つの共用バックアップユニットを備えていればよいが、本実施の形態では、複数の共用バックアップユニットとして、図１に示した共用バックアップＥＣＵ１０１だけでなく、１つ以上の他の共用バックアップＥＣＵ１０１を備える。

共用バックアップＥＣＵ１０１は、切替器１４４を介してＣＡＮ７０１に接続されている。切替器１４４は、共用バックアップＥＣＵ１０１をＣＡＮ７０１から切り離す機能を有する。

制御ＥＣＵ２０１は、切替器２５１を介してＣＡＮ７０１に接続されている。切替器２５１は、制御ＥＣＵ２０１をＣＡＮ７０１から切り離す機能を有する。制御ＥＣＵ２０１の故障時には、切替器２５１を用いて、制御ＥＣＵ２０１がＣＡＮ７０１から切り離される。

判断ＥＣＵ３０１は、切替器３５１を介してＣＡＮ７０１に接続されている。切替器３５１は、判断ＥＣＵ３０１をＣＡＮ７０１から切り離す機能を有する。判断ＥＣＵ３０１の故障時には、切替器３５１を用いて、判断ＥＣＵ３０１がＣＡＮ７０１から切り離される。

なお、ＣＡＮ７０１は、ＬＩＮ、ＦｌｅｘＲａｙ（登録商標）またはＥｔｈｅｒｎｅｔ（登録商標）といった他の種類のネットワークに置き換えられてもよい。「ＬＩＮ」は、Ｌｏｃａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｎｅｔｗｏｒｋの略語である。ＣＡＮ７０１に他の種類のネットワークが複雑に結合されてくる場合もある。複数のＣＡＮ７０１のネットワーク系統がゲートウェイまたはネットワーク系統切り替えスイッチを介して相互に接続される場合もある。ネットワーク系統例としては、エンジンおよびステアリング制御機器を含むパワートレイン系、カーナビゲーションおよびカーオーディオを含むマルチメディア系、パワーウィンドウおよび電動シートを含むボディ系、ならびに、各種センサおよびアクチュエータを含むスイッチ／センサ系がある。

本実施の形態では、１つ１つのＥＣＵを多重化せずに、故障時に利用できる共用バックアップＥＣＵ１０１をこれらのＥＣＵにて共用することで、ハードウェアコストの増加を低減することができる。

共用バックアップＥＣＵ１０１は、切替機能１０２、解析機能１０３、ロード機能１０４および診断機能１０５を有する。切替機能１０２は、バックアップ対象のＥＣＵを切り替える機能である。解析機能１０３は、ＣＡＮメッセージを解析する機能である。ロード機能１０４は、ＳＷＣの圧縮イメージを解凍してロードする機能である。診断機能１０５は、外部のＥＣＵの異常を診断する機能である。共用バックアップＥＣＵ１０１は、これらの機能によって、メモリ４０２上にバックアップ対象ＥＣＵ上に搭載する必要最小限のＳＷＣ群を起動して、バックアップ処理を実行する。具体的には、共用バックアップＥＣＵ１０１は、制御ＥＣＵ２０１を代替する際には制御ＳＷＣ１１１を起動する。共用バックアップＥＣＵ１０１は、判断ＥＣＵ３０１を代替する際には判断ＳＷＣ１２１を起動する。故障発生時にすぐに継続処理用のＳＷＣが実行できるように、共用バックアップＥＣＵ１０１はＯＳ起動後待機する。「ＯＳ」は、Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍの略語である。

共用バックアップＥＣＵ１０１の使用時には、故障ＥＣＵのネットワークインタフェースが切断されるか、切り替えられるか、あるいは、故障ＥＣＵの電源が切られる。

バックアップ時の継続処理に必要な故障ＥＣＵの状態および学習の情報を正常動作時にあらかじめ用意しておく必要がある。これには任意の方法を用いてよいが、本実施の形態では、そのような情報を故障ＥＣＵから離れた独立したメモリ領域に退避しておく方法が用いられる。具体的には、制御ＥＣＵ２０１は、制御ＳＷＣ２０２の処理の引き継ぎに必要な情報をメモリ５０２から読み取る。制御ＥＣＵ２０１は、読み取った情報を送信機能２０４によってＣＡＮ７０１経由で共用バックアップＥＣＵ１０１に送信する。共用バックアップＥＣＵ１０１は、制御ＥＣＵ２０１から送信された情報を受信する。共用バックアップＥＣＵ１０１は、受信した情報をメモリ４０２に記憶する。同様に、判断ＥＣＵ３０１は、判断ＳＷＣ３０２の処理の引き継ぎに必要な情報をメモリ６０２から読み取る。判断ＥＣＵ３０１は、読み取った情報を送信機能３０４によってＣＡＮ７０１経由で共用バックアップＥＣＵ１０１に送信する。共用バックアップＥＣＵ１０１は、判断ＥＣＵ３０１から送信された情報を受信する。共用バックアップＥＣＵ１０１は、受信した情報をメモリ４０２に記憶する。

本実施の形態では、監視対象ＥＣＵからの故障検知信号を共用バックアップＥＣＵ１０１が受信する仕組みが用意される。具体的には、エラー検知信号を受信するもの、ハートビート信号を受信するもの、自己診断回路等の情報を受信するものがある。

本実施の形態では、性能が比較的劣る共用バックアップＥＣＵ１０１が、故障ＥＣＵのソフトウェアをすべて実行するのではなく、継続運転に必須のソフトウェアを優先的に実行する。そのために、共用バックアップＥＣＵ１０１は、ＡＳＩＬに基づいてＳＷＣを管理し、実行すべきＳＷＣを選択する。本実施の形態によれば、多数のＥＣＵの多重化に匹敵する共用バックアップユニットを用意しなくて済む。

本実施の形態では、数多くのＥＣＵのＳＷＣを共用バックアップＥＣＵ１０１で限られたメモリ容量内で選択的に起動できるように、共用バックアップＥＣＵ１０１は、メモリ展開イメージを圧縮して保持し、必要時に解凍してＳＷＣの引き継ぎを行う。具体的には、共用バックアップＥＣＵ１０１は、制御ＥＣＵ２０１を代替する際には制御ＳＷＣ１１１の圧縮イメージ１１４を解凍して制御ＳＷＣ１１１を起動する。共用バックアップＥＣＵ１０１は、判断ＥＣＵ３０１を代替する際には判断ＳＷＣ１２１の圧縮イメージ１２４を解凍して判断ＳＷＣ１２１を起動する。

図２を参照して、制御システム１００のハードウェア構成を説明する。

共用バックアップＥＣＵ１０１は、マイクロコンピュータである。共用バックアップＥＣＵ１０１は、プロセッサ４０１を備えるとともに、メモリ４０２およびＣＡＮインタフェース４０３といった他のハードウェアを備える。プロセッサ４０１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

プロセッサ４０１は、各種処理を行うＩＣである。プロセッサ４０１は、具体的には、ＣＰＵである。

メモリ４０２は、例えば、フラッシュメモリまたはＲＡＭである。「ＲＡＭ」は、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙの略語である。

ＣＡＮインタフェース４０３は、データを受信するレシーバおよびデータを送信するトランスミッタを含む。ＣＡＮインタフェース４０３は、例えば、通信チップまたはＮＩＣである。「ＮＩＣ」は、Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄの略語である。ＣＡＮインタフェース４０３は、ＵＳＢインタフェースに置き換えられてもよい。「ＵＳＢ」は、Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓの略語である。

共用バックアップＥＣＵ１０１は、プロセッサ４０１を代替する複数のプロセッサを備えていてもよい。それぞれのプロセッサは、プロセッサ４０１と同じように、各種処理を行うＩＣである。

切替器１４４は、ＦＰＧＡ４１１を備える。「ＦＰＧＡ」は、Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略語である。

制御ＥＣＵ２０１は、マイクロコンピュータである。制御ＥＣＵ２０１は、プロセッサ５０１を備えるとともに、メモリ５０２およびＣＡＮインタフェース５０３といった他のハードウェアを備える。プロセッサ５０１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

プロセッサ５０１、メモリ５０２およびＣＡＮインタフェース５０３については、共用バックアップＥＣＵ１０１のプロセッサ４０１、メモリ４０２およびＣＡＮインタフェース４０３と同様である。

メモリ５０２には、制御ＳＷＣ２０２が記憶されている。制御ＳＷＣ２０２は、プロセッサ５０１に読み込まれ、プロセッサ５０１によって実行される。

切替器２５１は、ＦＰＧＡ５１１を備える。

判断ＥＣＵ３０１は、マイクロコンピュータである。判断ＥＣＵ３０１は、プロセッサ６０１を備えるとともに、メモリ６０２およびＣＡＮインタフェース６０３といった他のハードウェアを備える。プロセッサ６０１は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。

プロセッサ６０１、メモリ６０２およびＣＡＮインタフェース６０３については、共用バックアップＥＣＵ１０１のプロセッサ４０１、メモリ４０２およびＣＡＮインタフェース４０３と同様である。

メモリ６０２には、判断ＳＷＣ３０２が記憶されている。判断ＳＷＣ３０２は、プロセッサ６０１に読み込まれ、プロセッサ６０１によって実行される。

切替器３５１は、ＦＰＧＡ６１１を備える。

図３を参照して、ＥＣＵでの組込ソフトウェアの一般的な実装形態を説明しておく。本実施の形態では、この実装形態がバックアップ対象のＥＣＵにも、共用バックアップＥＣＵ１０１にも適用される。図３において、黒塗りの矢印はタスク実行中の状態、白塗りの矢印はタスク実行待ちの状態を示している。

基本的に、組込ＯＳ上のアプリケーションソフトウェアは、図３に示すようにマルチタスク環境下で実行される場合が多い。故障時に処理が中断しても、個別のタスク変数、共有変数またはグローバル変数、および、アプリケーションの挙動の学習記憶情報等の現行情報をメモリ４０２に蓄積しておけば、蓄積した情報を再利用することで共用バックアップＥＣＵ１０１での継続的な処理の実行が可能になる。

なお、アプリケーションソフトウェアの実行周期が数十ミリ秒程度までの比較的短い周期となっていれば、共用バックアップＥＣＵ１０１での継続的な処理の実行が容易になる。具体的には、処理開始時点に一揃いの入力用蓄積情報としてまとめて退避しておいた情報を使用することができる。ただし、周期の途中でダウンしたアプリケーションソフトウェアの処理の実行を再開する場合は、その周期の処理を最初からやり直すため、遅延が発生する。

周期ごとの入力用蓄積情報の退避途中にアプリケーションソフトウェアがダウンする可能性もあるため、退避完了フラグが用意される。退避が完了したかどうかをこのフラグのオンオフで判定できる。入力用蓄積情報の退避領域を２つ保有しておくと、１つの領域の退避書き込みが未完の場合でも、もう１つの領域にある過去の情報を使用することで、１周期分の遅延のみで影響を留めることができる。

図４を参照して、本実施の形態に係る共用バックアップＥＣＵ１０１の構成を説明する。

共用バックアップＥＣＵ１０１は、機能要素として、実行部１３１、診断部１３２、生成部１３３、管理テーブル１３４、ロード部１３５、解凍部１３６、第１記憶部１３７、第２記憶部１３９、解析部１４０および通信部１４１を備える。実行部１３１は、第１処理部１４２および第２処理部１４３を備える。実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能は、ソフトウェアにより実現される。管理テーブル１３４、第１記憶部１３７および第２記憶部１３９は、メモリ４０２により実現される。通信部１４１は、ＣＡＮインタフェース４０３により実現される。

メモリ４０２には、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能を実現するプログラムである共用バックアッププログラムが記憶されている。共用バックアッププログラムは、プロセッサ４０１に読み込まれ、プロセッサ４０１によって実行される。メモリ４０２には、ＯＳも記憶されている。プロセッサ４０１は、ＯＳを実行しながら、共用バックアッププログラムを実行する。なお、共用バックアッププログラムの一部または全部がＯＳに組み込まれていてもよい。

実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の処理の結果を示す情報、データ、信号値および変数値は、メモリ４０２、または、プロセッサ４０１内のレジスタまたはキャッシュメモリに記憶される。

共用バックアッププログラムは、磁気ディスクおよび光ディスクといった可搬記録媒体に記憶されてもよい。

＊＊＊動作の説明＊＊＊
図１を参照して、本実施の形態に係る共用バックアップＥＣＵ１０１の動作の概要を説明する。共用バックアップＥＣＵ１０１の動作は、本実施の形態に係るバックアップ方法に相当する。

共用バックアップＥＣＵ１０１は、ＣＡＮ７０１を経由して届いたＣＡＮメッセージを解析機能１０３で調べて、判断ＥＣＵ３０１または制御ＥＣＵ２０１の故障を診断機能１０５で検知する。別の方式として、判断ＥＣＵ３０１または制御ＥＣＵ２０１が自己診断機能を備えて故障発生時のＣＡＮメッセージを共用バックアップＥＣＵ１０１に送信する方式も実装可能である。

共用バックアップＥＣＵ１０１は、故障を検知すると、切替機能１０２によって管理テーブル１３４を参照し、退避すべきＳＷＣを選定し、該当するＳＷＣの圧縮イメージを取り出す。具体的には、共用バックアップＥＣＵ１０１は、判断ＳＷＣ１２１の圧縮イメージ１２４、あるいは、制御ＳＷＣ１１１の圧縮イメージ１１４を取り出す。共用バックアップＥＣＵ１０１は、ロード機能１０４により、圧縮イメージを実行メモリ上に展開し、該当するＳＷＣを実行する。具体的には、共用バックアップＥＣＵ１０１は、判断ＳＷＣ１２１あるいは制御ＳＷＣ１１を実行する。

共用バックアップＥＣＵ１０１は、故障した判断ＥＣＵ３０１あるいは制御ＥＣＵ２０１が異常なＣＡＮメッセージの送受信処理を行わないように、切替器３５１あるいは切替器２５１に対して切断命令のＣＡＮメッセージを送信する。

図４を参照して、共用バックアップＥＣＵ１０１の動作の詳細を説明する。

通信部１４１は、ＣＡＮ７０１と接続してＣＡＮメッセージの送受信処理を行う。通信部１４１は、受信したＣＡＮメッセージを第１処理部１４２および解析部１４０に渡す。第１処理部１４２は、ＳＷＣが起動および実行されたときの受信ＣＡＮメッセージの処理を行う。第２処理部１４３は、ＳＷＣが起動および実行されたときの送信ＣＡＮメッセージを通信部１４１に渡す。生成部１３３は、切替器１４４に対する送信ＣＡＮメッセージを通信部１４１に渡す。

解析部１４０は、診断対象のＥＣＵに関する情報を診断部１３２に渡す。診断部１３２は、ＥＣＵが故障しているかどうかを判定する。診断部１３２は、故障を検知すると、実行部１３１および生成部１３３に故障検知情報を伝達する。解析部１４０は、診断対象のＥＣＵの通常動作時のＣＡＮメッセージ情報を第２記憶部１３９に伝達し、保存しておく。

実行部１３１は、診断部１３２により故障が報告されると、管理テーブル１３４を参照して、退避が必要なＳＷＣを選定する。実行部１３１は、第１記憶部１３７から必要なメモリイメージを取り込み、解凍部１３６により解凍する。実行部１３１は、ロード部１３５にてメモリ４０２上に当該メモリイメージを展開する。そして、実行部１３１は、当該ＳＷＣを起動および実行する。

このように、本実施の形態において、診断部１３２は、複数のＥＣＵの異常を診断する。ロード部１３５は、複数のプログラムをあらかじめ記憶するメモリ４０２から、診断部１３２により異常が検知されたＥＣＵである異常ユニットが実行するプログラムと同じプログラムをロードする。実行部１３１は、ロード部１３５によりロードされたプログラムを実行することで、異常ユニットの代わりに異常ユニットの機能と同じ機能を発揮する。

具体例として、診断部１３２が、制御ＥＣＵ２０１の異常を検知したとする。この場合、ロード部１３５は、メモリ４０２から、制御ＥＣＵ２０１が実行する制御ＳＷＣ２０２と同じプログラムである制御ＳＷＣ１１１をロードする。実行部１３１は、ロード部１３５によりロードされた制御ＳＷＣ１１１を実行することで、制御ＥＣＵ２０１の代わりにエンジンまたはハンドルを制御する機能を発揮する。

通信部１４１は、複数のＥＣＵがプログラムの実行中に使用する状態変数を示す個別のメッセージを複数のＥＣＵから受信する。実行部１３１は、診断部１３２により異常が検知される前に通信部１４１により異常ユニットから受信されたメッセージに基づいて、ロード部１３５によりロードされたプログラムを実行する際に使用する状態変数を設定する。

具体例として、診断部１３２が、制御ＥＣＵ２０１の異常を検知したとする。この場合、実行部１３１は、診断部１３２により異常が検知される前に通信部１４１により制御ＥＣＵ２０１から受信されたＣＡＮメッセージに示された制御ＳＷＣ２０２の状態変数に合わせて、ロード部１３５によりロードされた制御ＳＷＣ１１１の状態変数を設定する。

なお、管理テーブル１３４が用意されている点について、ＳＷＣの選定処理そのものは、プログラムのｉｆ文等の分岐処理にて実現可能であるため、必ずしもテーブルが必須というわけではない。しかし、ＳＷＣの設定処理の実装および保守が容易になるため、テーブルが推奨される。具体的に、ＳＷＣがどのように選定されるかを図５の例にて説明する。

図５の例では、通常は動作しているＥＣＵとして、高性能のＥＣＵ１、高性能のＥＣＵ２、および、中性能のＥＣＵ３の３個がある。ＥＣＵ１およびＥＣＵ２は、それぞれ制御ＥＣＵ２０１に該当する。ＥＣＵ３は、判断ＥＣＵ３０１に該当する。ＥＣＵ１では、ＡＳＩＬ Ｄ対応ＯＳ８０５上で、制御ＳＷＣ２０２として、ＡＳＩＬ Ｄ ＳＷＣ１１、ＡＳＩＬ Ｄ ＳＷＣ１２およびＡＳＩＬ Ｄ ＳＷＣ１３の３つが動作している。ＥＣＵ２では、ＡＳＩＬ Ｃ対応ＯＳ８１５上で、制御ＳＷＣ２０２として、ＡＳＩＬ Ｃ ＳＷＣ２１、ＡＳＩＬ Ｂ ＳＷＣ２２およびＡＳＩＬ Ａ ＳＷＣ２３の３つが動作している。ＥＣＵ３では、ＡＳＩＬ Ｂ対応ＯＳ８２５上で、判断ＳＷＣ３０２として、ＡＳＩＬ Ｂ ＳＷＣ３１、ＡＳＩＬ Ａ ＳＷＣ３２およびＱＭ ＳＷＣ３３の３つが動作している。

これに対して、共用バックアップＥＣＵ１０１としては、低性能のＢＥＣＵ１およびＢＥＣＵ２の２個がある。ＢＥＣＵ１では、ＡＳＩＬ Ｄ対応ＯＳ８３４が実行中である。ＢＥＣＵ２では、ＡＳＩＬ Ｄ対応ＯＳ８４４が実行中である。

図５の例では、完全にＥＣＵが故障したときではなく、温度上昇によりＥＣＵ１、ＥＣＵ２およびＥＣＵ３が故障する可能性が生じたときに、共用バックアップＥＣＵ１０１への退避が行われる。退避の対象として選定されるＳＷＣは、ＡＳＩＬがＣ以上のものである。ＡＳＩＬがＢ以下のものは動作しなくても最悪ケースは避けられることが前提となっている。

温度上昇によりＥＣＵ１、ＥＣＵ２およびＥＣＵ３が故障する可能性が生じたか、あるいは、実際にＥＣＵ１、ＥＣＵ２およびＥＣＵ３が故障したとする。この場合、ＥＣＵ１内のＡＳＩＬ Ｄ ＳＷＣ１１およびＡＳＩＬ Ｄ ＳＷＣ１２がＢＥＣＵ１に退避され、ＥＣＵ１内のＡＳＩＬ Ｄ ＳＷＣ１３と、ＥＣＵ２内のＡＳＩＬ Ｃ ＳＷＣ２１とがＢＥＣＵ２に退避される。その結果、ＢＥＣＵ１では、ＡＳＩＬ Ｄ対応ＯＳ８３４上で、制御ＳＷＣ１１１として、ＡＳＩＬ Ｄ ＳＷＣ４１およびＡＳＩＬ Ｄ ＳＷＣ４２が実行される。ＢＥＣＵ２では、ＡＳＩＬ Ｄ対応ＯＳ８４４上で、制御ＳＷＣ１１１として、ＡＳＩＬ Ｄ ＳＷＣ５１およびＡＳＩＬ Ｃ ＳＷＣ５２が実行される。その他のＡＳＩＬがＢ以下のＳＷＣは退避されない。

図５の例にて使用される管理テーブル１３４の例を図６に示す。

通常は動作しているＥＣＵ１、ＥＣＵ２およびＥＣＵ３について、ＩＤ別に、バックアップ対象のＳＷＣのＩＤと退避先の共用バックアップＥＣＵ１０１のＩＤとが登録されている。「ＩＤ」は、Ｉｄｅｎｔｉｆｉｅｒの略語である。バックアップ対象の各ＳＷＣのＩＤには、ＡＳＩＬ情報が付記されている。退避先の共用バックアップＥＣＵ１０１のＩＤについては、共用バックアップＥＣＵ１０１が２個あるため、管理テーブル１３４のエントリも２個割り当てられている。重要なＡＳＩＬのＳＷＣには、必ず共用バックアップＥＣＵ１０１が退避先として割り当てられる。低レベルのＡＳＩＬのＳＷＣに割り当てられる退避先は１個あるいは０個となる。

前述した故障の例では、バックアップ対象のＳＷＣのうち、ＳＷＣ１１およびＳＷＣ１３がＢＥＣＵ１に割り当てられ、ＳＷＣ１３およびＳＷＣ２１がＢＥＣＵ２に割り当てられる。割当規則として、共用バックアップＥＣＵ１０１で動作させるＳＷＣはそれぞれ２つまでとしている。故障時に退避先の共用バックアップＥＣＵ１０１が割り当てられ、退避処理が完了すると、管理テーブル１３４内の退避先の共用バックアップＥＣＵ１０１の使用フラグが立てられる。これにより、次にＥＣＵが故障したときに、同じ共用バックアップＥＣＵ１０１ではなく、空いている共用バックアップＥＣＵ１０１を選定できる。

このように、本実施の形態において、実行部１３１は、異常ユニットが２つ以上のプログラムを実行するＥＣＵである場合、プログラムごとにあらかじめ定義された優先度によって、ロード部１３５にロードさせるプログラムを選定する。実行部１３１は、診断部１３２により２つ以上のＥＣＵの異常が検知された場合、ＥＣＵとプログラムとの組み合わせごとにあらかじめ定義された優先度によって、ロード部１３５にロードさせるプログラムを選定する。優先度の定義としては、任意の定義が用いられてよいが、前述したように、本実施の形態ではＡＳＩＬが用いられている。

図７を参照して、共用バックアップＥＣＵ１０１内にて動作する共用バックアッププログラムの処理手順を説明する。自動車では、一度エンジンが始動され、電源がオンにされると、共用バックアップＥＣＵ１０１のバックアップ対応処理は、エンジン停止による電源断まで継続して実行される。

電源オンにより、バックアップ対応処理が開始されると、ステップＳ１１において、内部情報の初期化処理が実行される。通信部１４１は、ＣＡＮ７０１上のＣＡＮメッセージの取得を開始する。

ステップＳ１２において、解析部１４０は、退避元となる各ＥＣＵの現行情報を取り込み、第２記憶部１３９に保存する。退避元となる各ＥＣＵに、常時、現行情報を共用バックアップＥＣＵ１０１へ送信してもらうことになるが、メッセージサイズを低減するために、現行情報そのものを圧縮して送信してもらい、共用バックアップＥＣＵ１０１で解凍することも可能である。

ステップＳ１３において、診断部１３２は、解析部１４０によるＣＡＮメッセージの解析の結果から、いずれかのＥＣＵで故障が発生したかどうかを確認する。故障が発生していなければ、再びステップＳ１２の処理から、繰り返しループ処理が行われる。診断部１３２は、受信したＣＡＮメッセージの解析の結果から故障の発生を検出するだけではなく、定期的に受信するはずのＣＡＮメッセージが到着していない場合も故障の発生として検出する。

故障が発生している場合には、ステップＳ１４において、実行部１３１は、この共用バックアップＥＣＵ１０１が退避先に該当するかどうかを確認する。退避先に該当しなければ、またステップＳ１２の処理から、繰り返しループ処理が行われる。

この共用バックアップＥＣＵ１０１が退避先に該当している場合には、ステップＳ１５において、実行部１３１は、管理テーブル１３４を参照して退避対象ＳＷＣを選定する退避対象ＳＷＣ選定処理を実行する。ここで、退避対象ＳＷＣ選定処理の手順を図８に示す。ステップＳ３１において、実行部１３１は、バックアップ対象のＳＷＣのＩＤを管理テーブル１３４から取得する。ステップＳ３２において、実行部１３１は、バックアップ対象のＳＷＣのＩＤのうち、ＡＳＩＬが必要レベル以上のものだけを選定する。ステップＳ３３において、実行部１３１は、選定したバックアップ対象のＳＷＣのＩＤについて、管理テーブル１３４内の使用フラグをオンにする。
なお、管理テーブル１３４の使用フラグの更新は、本来は、他の共用バックアップＥＣＵ１０１の管理テーブル１３４へもＣＡＮメッセージ等で伝達する必要があるが、他の共用バックアップＥＣＵ１０１も同様に故障検知できていることから、伝達は不要で、更新対応は可能である。

ステップＳ１６において、ロード部１３５は、第１記憶部１３７から、ステップＳ１５で選定されたＳＷＣのメモリイメージを取得する。ロード部１３５は、取得したメモリイメージを解凍部１３６により解凍する。ロード部１３５は、解凍したメモリイメージをメモリ４０２上に展開する。

ステップＳ１７において、実行部１３１は、退避元ＥＣＵに接続された切替器を操作して退避元ＥＣＵをＣＡＮ７０１から切り離す。具体的には、実行部１３１は、退避元ＥＣＵが制御ＥＣＵ２０１であれば、切替器２５１に対して、切り離しを指示するＣＡＮメッセージを通信部１４１により送信する。実行部１３１は、退避元ＥＣＵが判断ＥＣＵ３０１であれば、切替器３５１に対して、切り離しを指示するＣＡＮメッセージを通信部１４１により送信する。

ステップＳ１８において、実行部１３１は、ステップＳ１６で展開されたＳＷＣの処理を起動する。このＳＷＣの処理は、バックアップ対応処理のメインループ処理とは独立した別のタスクとして起動される。

展開されたＳＷＣの処理が開始されると、ステップＳ２１において、実行部１３１は、展開されたＳＷＣのメインループ処理を実行する。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態では、共用バックアップＥＣＵ１０１が、各ＥＣＵを動的に代替できる。そのため、１つ１つのＥＣＵに対してバックアップユニットを個別に用意しなくても、各ＥＣＵの実質的な多重化が可能になる。すなわち、本実施の形態によれば、少ないハードウェアでＥＣＵの実質的な多重化が可能になる。

本実施の形態では、共用バックアップＥＣＵ１０１が、実行部１３１、診断部１３２、ロード部１３５、第１記憶部１３７、第２記憶部１３９、解析部１４０および通信部１４１を備える。通信部１４１は、ネットワークと接続してメッセージの送受信処理を行う。解析部１４０は、受信されたメッセージを解析する。診断部１３２は、メッセージの解析結果から他のＥＣＵが故障しているかどうかを判定する。実行部１３１の第１処理部１４２は、他の複数のＥＣＵのうちどれかの故障が検知された際にバックアップのための代替ソフトウェアコンポーネントを必ずしもすべてではなく継続実行のための必須性レベルから個別に選定して起動する。実行部１３１の第２処理部１４３は、故障したＥＣＵが接続される切替器に送信される切断指示メッセージを生成して通信部１４１に渡す。第１記憶部１３７は、他の複数のＥＣＵの代替ソフトウェアコンポーネントの実行メモリイメージを記憶しておく。ロード部１３５は、実行メモリイメージを実行メモリ上にロードする。

本実施の形態によれば、ＥＣＵを多重系にする場合の増加するＥＣＵの総数を、バックアップＥＣＵの共用化により低減できる。その結果、ハードウェア生産コストおよび消費電力の増大を抑制できる。

本実施の形態では、バックアップ対象のＳＷＣとして、継続運転に必須の重要なものを選定して、共用バックアップＥＣＵ１０１上で限定して動作させることができる。そのため、バックアップＥＣＵとして必ずしも高性能のＥＣＵを採用しなくて済むことから、ハードウェア生産コストおよび消費電力の増大をさらに抑制できる。

ＥＣＵを多重系にした場合、２重系であれば、２個のＥＣＵの故障で処理が破綻する。３重系であれば、３個のＥＣＵの故障で処理が破綻する。しかし、バックアップＥＣＵを共用化することで、数多くのバックアップＥＣＵを相互で利用することができる。そのため、固定的な多重系ＥＣＵよりも連続運転の耐久性が向上する。

ＥＣＵを多重系にした場合、ハードウェア構成上、多重にしたＥＣＵをまとめて基板上に配置することになる。自動車の局所的な故障により、その多重系ＥＣＵ基板の温度上昇等での破壊が想定される場合、同時に多重系ＥＣＵがすべて破壊される可能性がある。それに比べて、共用バックアップＥＣＵ１０１は、離れた基板に分散して配置することが可能であるため、局所的な故障に巻き込まれて全滅することを回避できる。結果として、集中型の多重系ＥＣＵの構成よりも、連続運転の耐久性が向上する。

＊＊＊他の構成＊＊＊
本実施の形態では、制御システム１００は、自動運転システムに相当するが、変形例として、制御システム１００は、自動運転システム以外のシステムとして実装されてもよい。特に、制御システム１００は、非常に多くのマイクロコンピュータを搭載し、動作処理を電子制御にて行い、ＥＣＵの故障への対策が必要であり、多重系の構成が想定される機械装置全般に利用できる。その例として、宇宙ロケット、人工衛星、航空機、電車、船舶、潜水艦、工作機械、工事機械、医用機械およびロボット等がある。

本実施の形態では、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能がソフトウェアにより実現されるが、変形例として、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能の一部が専用の電子回路により実現され、残りがソフトウェアにより実現されてもよい。

専用の電子回路は、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックＩＣ、ＧＡ、ＦＰＧＡまたはＡＳＩＣである。「ＧＡ」は、Ｇａｔｅ Ａｒｒａｙの略語である。「ＡＳＩＣ」は、Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔの略語である。

プロセッサ４０１、メモリ４０２および専用の電子回路を、総称して「プロセッシングサーキットリ」という。つまり、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の機能は、プロセッシングサーキットリにより実現される。

共用バックアップＥＣＵ１０１の「ＥＣＵ」を「プログラム」、「プログラムプロダクト」または「プログラムを記録したコンピュータ読取可能な媒体」に読み替え、実行部１３１、診断部１３２、生成部１３３、ロード部１３５、解凍部１３６および解析部１４０の「部」を「手順」または「処理」に読み替えてもよい。

実施の形態２．
本実施の形態について、主に実施の形態１との差異を、図９および図１０を用いて説明する。

実施の形態１では、各ソフトウェアコンポーネントの継続実行の必須度レベルが管理テーブル１３４に記憶されている。本実施の形態では、この管理テーブル１３４に各ソフトウェアコンポーネントの実行時のＣＰＵ負荷がさらに記憶されている。共用バックアップＥＣＵ１０１は、ＣＰＵ負荷の総容量が上限を超えないように、ＣＰＵ負荷の算出結果に応じて、複数のＥＣＵのソフトウェアコンポーネントから個別のソフトウェアコンポーネントを選定する。

＊＊＊構成の説明＊＊＊
本実施の形態に係る制御システム１００の構成は、図１および図２に示した実施の形態１のものと同様である。

本実施の形態に係る共用バックアップＥＣＵ１０１の構成は、図４に示した実施の形態１のものと同様である。

＊＊＊動作の説明＊＊＊
ＳＷＣの実行ＣＰＵ負荷をも合わせて管理する管理テーブル１３４の例を図９に示す。

図９の例では、図６の例と比べると、新しくＣＰＵ負荷レベルの列が加えられている。ＣＰＵ負荷が退避可能な共用バックアップＥＣＵ１０１のＣＰＵ負荷容量を超えないようにＣＰＵ負荷の積算が可能である。図９の例では、自動運転用の５つのＥＣＵが元々備えられている車載機器システムに、３つの共用バックアップＥＣＵ１０１が用意されている。自動運転用の５つのＥＣＵとしては、道路状況認知の機能を発揮するＥＣＵ１、周辺状況認知の機能を発揮するＥＣＵ２、走行パス生成の機能を発揮するＥＣＵ３、ステアリング制御の機能を発揮するＥＣＵ４、および、エンジン制御の機能を発揮するＥＣＵ５が用意されている。これらのＥＣＵの各ＳＷＣが退避先の共用バックアップＥＣＵ１０１へ振り分けられている。３つの共用バックアップＥＣＵ１０１としては、ＢＥＣＵ１、ＢＥＣＵ２およびＢＥＣＵ３がある。ＢＥＣＵ１、ＢＥＣＵ２およびＢＥＣＵ３の最大ＣＰＵ負荷容量は、それぞれ６０、４０および４０であるとする。

ＣＰＵ負荷の計算の例として、ＥＣＵ３およびＥＣＵ４が故障した場合のＳＷＣ退避について説明する。ＥＣＵ３では、ＳＷＣ３１、ＳＷＣ３２およびＳＷＣ３３が実行されている。ＥＣＵ４では、ＳＷＣ４１、ＳＷＣ４２およびＳＷＣ４３が実行されている。ＡＳＩＬ ＣのＳＷＣとＡＳＩＬ ＤのＳＷＣとが共用バックアップＥＣＵ１０１へ退避されるものとする。該当する退避対象ＳＷＣは、ＳＷＣ３１、ＳＷＣ４１およびＳＷＣ４２の３つとなる。ＳＷＣ３１、ＳＷＣ４１およびＳＷＣ４２のＣＰＵ負荷レベルは、それぞれ４０、２０および１０である。

まず、重要なＡＳＩＬ ＤのＳＷＣ３１とＳＷＣ４１との退避について処理が行われる。退避先の共用バックアップＥＣＵ１０１の第１候補は、どちらもＢＥＣＵ１である。ＢＥＣＵ１の負荷上限は６０となっている。ＳＷＣ３１およびＳＷＣ４１の負荷合計は６０である。よって、ＳＷＣ３１およびＳＷＣ４１の両者ともＢＥＣＵ１に退避できることになる。ＢＥＣＵ１にＳＷＣ３１およびＳＷＣ４１のそれぞれが退避したことを示すために、ＳＷＣ３１およびＳＷＣ４１の使用フラグがチェックされる。これ以降、さらなる故障が発生しても、ＢＥＣＵ１は満杯状況で、ＳＷＣの追加退避はできないことになる。

次に、ＳＷＣ４２の退避について処理が行われる。退避先の共用バックアップＥＣＵ１０１の第１候補は、ＢＥＣＵ２である。ＢＥＣＵ２の負荷上限は４０となっている。ＳＷＣ４２の単独負荷は１０である。よって、ＳＷＣ４２は問題なくＢＥＣＵ２に退避できることになる。ＢＥＣＵ２にＳＷＣ４２が退避したことを示すために、ＳＷＣ４２の使用フラグがチェックされる。これ以降、さらなる故障が生じても、ＢＥＣＵ２の負荷の余裕として３０残存していて、ＳＷＣの追加退避がその分だけ可能である。

このように、本実施の形態において、実行部１３１は、異常ユニットが２つ以上のプログラムを実行するＥＣＵである場合、プログラムごとにあらかじめ予測されたプロセッサ４０１の負荷の大きさによって、ロード部１３５にロードさせるプログラムを選定する。実行部１３１は、診断部１３２により２つ以上のＥＣＵの異常が検知された場合、ＥＣＵとプログラムとの組み合わせごとにあらかじめ予測されたプロセッサ４０１の負荷の大きさによって、ロード部１３５にロードさせるプログラムを選定する。

共用バックアップＥＣＵ１０１内にて動作する共用バックアッププログラムの処理手順は、ステップＳ１５の退避対象ＳＷＣ選定処理を除いて、図７に示した実施の形態１のものと同様である。ここで、退避対象ＳＷＣ選定処理の手順を図１０に示す。ステップＳ４１およびステップＳ４２の処理は、それぞれ図８のステップＳ３１およびステップＳ３２の処理と同じである。ステップＳ４３において、実行部１３１は、ステップＳ４２で選定したバックアップ対象のＳＷＣのＩＤのうち、現在のＣＰＵ負荷状況から退避可能なものだけを選定する。ステップＳ４４において、実行部１３１は、ステップＳ４３で選定したバックアップ対象のＳＷＣのＩＤについて、管理テーブル１３４内の使用フラグをオンにする。

＊＊＊実施の形態の効果の説明＊＊＊
実施の形態１では、退避先の共用バックアップＥＣＵ１０１上で実行される退避元ＥＣＵのＳＷＣの個数があらかじめ規定されている。ＳＷＣの実行ＣＰＵ負荷は、軽いものから重たいものまで多様に存在する。そのため、本実施の形態では、管理テーブル１３４でも、ＳＷＣの実行ＣＰＵ負荷が管理される。つまり、ＣＰＵ負荷がＣＰＵ性能の上限値内となるように、実行対象のＳＷＣについてＣＰＵ負荷が計算されつつ実行対象のＳＷＣが追加される。そのため、効率よく共用バックアップＥＣＵ１０１のＣＰＵを活用できることになる。

実施の形態３．
本実施の形態について、主に実施の形態１との差異を、図１１から図１４を用いて説明する。

実施の形態１では、バックアップのための代替ソフトウェアコンポーネントの実行に必要な現行情報がネットワーク上のメッセージとして他の複数のＥＣＵから共用バックアップＥＣＵ１０１へ送信され、第２記憶部１３９に記憶される。本実施の形態では、そのような現行情報がネットワーク上のメッセージとして送信されるのではなく、既存のネットワーク送受信処理で送信されるネットワーク上のメッセージの内容が解析され、解析結果を利用して処理の引き継ぎが行われる。具体的には、共用バックアップＥＣＵ１０１は、故障ＥＣＵの現行情報を持たない状態で、故障ＥＣＵのソフトウェアコンポーネントが故障前に出力していた情報から外挿法により故障ＥＣＵのソフトウェアコンポーネントがその後出力するはずであった情報を予測する。

バックアップ時の継続処理に必要な故障ＥＣＵの状態および学習の情報を、ＣＡＮメッセージ等で、共用バックアップＥＣＵ１０１の独立したメモリ領域に退避させることは、ＣＡＮ７０１の通信帯域を消費することにつながる。そのため、本実施の形態では、共用バックアップＥＣＵ１０１は、実行中ＳＷＣの状態情報を退避領域に定期的に退避せずに、送信される既存のＣＡＮメッセージを回収して外挿法にて出力制御値を予測して継続処理を行う。

＊＊＊構成の説明＊＊＊
図１１を参照して、本実施の形態に係る共用バックアップＥＣＵ１０１の構成を説明する。

共用バックアップＥＣＵ１０１は、機能要素として、算出部１３８をさらに備える。算出部１３８の機能は、ソフトウェアにより実現される。

＊＊＊動作の説明＊＊＊
実施の形態１では、図４に基づいて説明したように、解析部１４０から診断対象のＥＣＵの通常動作時のＣＡＮメッセージ情報が第２記憶部１３９に伝達され、保存される。実施の形態１では、各ＥＣＵからＳＷＣの継続実行に必要な内部変数情報がＣＡＮメッセージに載せられて、共用バックアップＥＣＵ１０１へ送信される。したがって、共用バックアップＥＣＵ１０１への退避のためのＣＡＮメッセージが追加で送信されることになる。ＣＡＮ７０１の通信帯域の消費が増大することになるため、消費量が大きくなりすぎないように、通信負荷の見積りをしておく必要がある。

本実施の形態では、追加のＣＡＮメッセージの通信が不要である。基本的に、既存のＳＷＣから送信されているＣＡＮメッセージが利用され、共用バックアップＥＣＵ１０１内で解析が行われ、退避ＳＷＣの出力ＣＡＮメッセージが生成される際に、外挿法で予測された出力値が算出される。

このように、本実施の形態において、通信部１４１は、複数のＥＣＵがプログラムの実行結果として送信する個別のメッセージをそれら複数のＥＣＵから受信する。実行部１３１は、診断部１３２により異常が検知される前に通信部１４１により異常ユニットから受信されたメッセージに基づいて、異常ユニットがプログラムの実行中に使用する状態変数を推定する。実行部１３１は、推定した状態変数に合わせて、ロード部１３５によりロードされたプログラムを実行する際に使用する状態変数を設定する。

具体例として、診断部１３２が、制御ＥＣＵ２０１の異常を検知したとする。この場合、実行部１３１は、診断部１３２により異常が検知される前に通信部１４１により制御ＥＣＵ２０１から受信されたＣＡＮメッセージに示された制御ＳＷＣ２０２の出力値から、制御ＳＷＣ２０２の状態変数を推定する。実行部１３１は、推定した状態変数に合わせて、ロード部１３５によりロードされた制御ＳＷＣ１１１の状態変数を設定する。

以下に、具体的な例として、図１２に示すような電子制御スロットルシステム１５０を取り上げる。この電子制御スロットルシステム１５０は、自動車のアクセルペダルとエンジン１５３のスロットルとの間を電気的に接続して制御する機構である。アクセルペダルおよびスロットルの出力制御には、基本的な制御パターンがある。そのため、イレギュラーなケースがほとんどなく、計算上の予測が容易である。例えば、図１３に示すように、エンジン１５３の状態として、オーバーベンチュリと呼ばれるものがある。これは、エンジン１５３が十分な回転数に至らない時点で、スロットルを全開にしても、吸入される空気流の密度が増加することはなく充填効率が悪い状態を指す。このような状態を避けるために、電子制御スロットルシステム１５０ではスロットルの開度およびエンジン１５３の回転数等からアクセルを開く際のスロットルの開度を制限するように出力制御値が算出されている。

電子制御スロットルシステム１５０は、制御システム１００と、入力装置となるアクセルペダルセンサ１５２およびモータセンサ１５４と、出力装置となるエンジン１５３とを備える。制御システム１００は、制御ＥＣＵ２０１として、高性能のＥＣＵ１を備える。制御システム１００は、共用バックアップＥＣＵ１０１として、低性能のＢＥＣＵ１を備える。ＥＣＵ１では、エンジン１５３の出力を制御する制御ＳＷＣ２０２が実行されている。故障時には、ＢＥＣＵ１上の、エンジン１５３の出力を制御する制御ＳＷＣ１１１が実行される。外挿法にて予測した出力値を算出する予測ＳＷＣ１５７もＢＥＣＵ１上にて実行される。

ＥＣＵ１の制御ＳＷＣ２０２に対するアクセルペダルセンサ１５２からの入力値Ｘと、ＥＣＵ１の制御ＳＷＣ２０２に対するモータセンサ１５４からの入力値Ｙと、制御ＳＷＣ２０２の内部変数情報Ｓとから、エンジン１５３への出力値Ｚを求める算出式ｆは以下のようになる。
Ｚ＝ｆ（Ｘ，Ｙ，Ｓ）

ＢＥＣＵ１では、ＥＣＵ１の制御ＳＷＣ２０２の継続実行に必要な内部変数情報Ｓが実施の形態１のようなＣＡＮメッセージにより提供されず、未知である。外挿法で出力値Ｚを予測する算出式ｇは以下のようになる。
Ｚ＝ｇ（Ｘ，Ｙ）

算出部１３８は、ＥＣＵ１の制御ＳＷＣ２０２の退避を開始した直後からある一定期間、算出式ｇを用いてエンジン出力値Ｚを求める。基本的に、内部変数情報Ｓは、過去の状態から求められるため、上記の一定期間の後は、内部変数情報Ｓを新たに推定できるようになり、算出式ｆでの出力値Ｚの算出が可能になる。

算出式ｇとしては、２次曲線または３次曲線等の近似曲線を表す式が使用される。既存の方法を用いて、多項式または微分方程式等により出力値Ｚを算出することができる。本実施の形態では、算出法そのものは、従来の方法でよいが、退避時の引き継ぎのためにＣＡＮメッセージの出力値から引き継ぎ時点の出力値を予測する点が特徴になっている。

図１４を参照して、共用バックアップＥＣＵ１０１内にて動作する共用バックアッププログラムの処理手順を説明する。

ステップＳ５１の処理は、図７のステップＳ１１の処理と同じである。ステップＳ５３からステップＳ５８の処理は、図７のステップＳ１３からステップＳ１８の処理と同じである。

図７に示した実施の形態１のものとの違いは、主に以下の２点である。

図７のステップＳ１２において、解析部１４０は、追加のＣＡＮメッセージで内部変数情報を含む現行情報を退避元となる各ＥＣＵから取得する。この追加のＣＡＮメッセージは、共用バックアップＥＣＵ１０１宛のメッセージである。一方、ステップＳ５２において、解析部１４０は、通常のＣＡＮメッセージからエンジン１５３等の機器への出力値を取得する。この通常のＣＡＮメッセージは、共用バックアップＥＣＵ１０１宛のメッセージではなく、エンジン１５３等の機器宛のメッセージである。

図７のステップＳ２１において、実行部１３１は、展開されたＳＷＣのメインループ処理を実行する。このメインループ処理は、退避開始時点にすぐに開始される。一方、本実施の形態では、一定期間、外挿法による出力制御処理が実行され、その後に、展開されたＳＷＣのメインループ処理が開始される。具体的には、ステップＳ６１において、実行部１３１は、一定期間が経過したかどうかを判定する。一定期間が経過していなければ、ステップＳ６２において、算出部１３８は、算出式ｇにより出力値を算出する。実行部１３１は、算出部１３８により算出された出力値をエンジン１５３等の機器へ送信する。一定期間が経過していれば、ステップＳ６２において、実行部１３１は、展開されたＳＷＣのメインループ処理を実行する。このメインループ処理では、実行部１３１が、算出式ｆにより出力値を算出する。実行部１３１は、算出した出力値をエンジン１５３等の機器へ送信する。

＊＊＊実施の形態の効果の説明＊＊＊
本実施の形態では、バックアップ時に継続処理に必要な故障ＥＣＵの状態および学習の情報を、追加のＣＡＮメッセージ等で、共有バックアップＥＣＵ１０１の独立したメモリ領域に退避するのではなく、元々送信されるＣＡＮメッセージが回収されて外挿法にて出力値が予測される。そのため、追加のＣＡＮメッセージの通信コストが削減でき、ネットワークの帯域の消費増大を回避できる。

本実施の形態では、元々送信されるＣＡＮメッセージを回収して外挿法にて出力制御値を予測して継続処理を行えるようにすることで、バックアップＥＣＵが元々存在しないシステム構成にて既存ＥＣＵのＳＷＣの改修が不要となる。共用バックアップＥＣＵ１０１を追加する開発が外付けで行えるため、開発効率が向上する。

実施の形態４．
本実施の形態について、主に実施の形態１との差異を説明する。

実施の形態１では、共用バックアップＥＣＵ１０１の内蔵ＣＰＵのコア数が１つである。この場合には、ハイパーバイザ構成を採用しない限り、複数のＯＳを実行させることができない。ＥＣＵのシングルコアのハードウェア性能からも単一のＯＳの実行が前提となっている。本実施の形態では、共用バックアップＥＣＵ１０１として、マルチコアのＣＰＵを内蔵したマイクロコンピュータ、あるいは、マルチプロセッサを内蔵したマイクロコンピュータが採用される。そのため、ＡＵＴＯＳＡＲ（登録商標）およびＬｉｎｕｘ（登録商標）等の異なるＯＳを動作させた場合、それぞれに対応したＳＷＣの継続実行が可能になる。

実施の形態５．
本実施の形態について、主に実施の形態１との差異を説明する。

実施の形態１では、共用バックアップＥＣＵ１０１が１つのネットワーク系統内で共用されている。図示していないが、本実施の形態では、複数のネットワーク系統がゲートウェイにより接続されている。このゲートウェイの位置には、複数のネットワーク系統で共用できる共用バックアップＥＣＵ１０１が配置されている。最も通信速度が速いネットワーク系統上に共用バックアップＥＣＵ１０１を配置すると、通信効率が向上する。

実施の形態６．
本実施の形態について、主に実施の形態１との差異を説明する。

一般的に、ＣＡＮには、数多くのＥＣＵが接続されるようになってきており、ＣＡＮ ＩＤの枯渇が懸念されるようになっている。そこで、本実施の形態では、複数の共用バックアップＥＣＵ１０１にＣＡＮ ＩＤを個別に割り当てるのではなく、複数の共用バックアップＥＣＵ１０１に対して全体で１つのＣＡＮ ＩＤが割り当てられる。要するに共用バックアップＥＣＵ１０１群は、既存のＥＣＵ群を監視し、緊急時にバックアップ対応処理を行うため、１つのＩＤを共用する。バックアップ対応処理が開始されてからは、個々の共用バックアップＥＣＵ１０１間での識別を行うために、ＣＡＮ ＩＤとは異なるローカルなＩＤがＣＡＮメッセージ内にアプリケーション情報として格納される。

このように、本実施の形態において、複数のＥＣＵがプログラムの実行結果として送信する個別のメッセージには、ＥＣＵによって異なる識別子が送信元アドレスとして含まれる。複数の共用バックアップＥＣＵ１０１が実行部１３１でのプログラムの実行結果として送信する個別のメッセージには、共通の識別子が送信元アドレスとして含まれるとともに、共用バックアップＥＣＵ１０１によって異なる識別子が送信データの一部として含まれる。ＥＣＵによって異なる識別子、および、共通の識別子としては、任意のアドレス体系のＩＤが割り当てられてよいが、前述したように、本実施の形態ではＣＡＮ ＩＤが割り当てられる。共用バックアップＥＣＵ１０１によって異なる識別子としても、任意のアドレス体系のＩＤが割り当てられてよいが、前述したように、本実施の形態ではＣＡＮ ＩＤとは別のローカルなＩＤが割り当てられる。

実施の形態７．
本実施の形態について、主に実施の形態１との差異を説明する。

実施の形態１では、各種ＥＣＵおよび共用バックアップＥＣＵ１０１がＣＡＮ７０１等の車両用の有線ネットワークに接続される。しかし、昨今の自動車のＥＣＵの劇的な増加に伴い、一般的にＣＡＮのネットワークケーブル配線は非常に込み入ったものとなり、自動車製造上もネットワークケーブル配線が各所で困難になってきている。そこで、本実施の形態では、従来と同じネットワーク通信には、従来と同じ有線ネットワークが使用される一方で、故障時の退避処理という限定した用途には、無線ネットワークが使用される。すなわち、必要な退避用通信処理は、無線ネットワークを介して行われる。

具体的な例として、複数の共用バックアップＥＣＵ１０１がまとめて１つのボックスに収納される。そのボックスと、基幹ＣＡＮ上の無線ゲートウェイとの間で無線通信が行われる。このような構成を採用することで、配線を気にせずに、既存の自動車ネットワークシステムの完成品に共用バックアップＥＣＵ１０１用ボックスを後付けで設置することができる。

１００ 制御システム、１０１ 共用バックアップＥＣＵ、１０２ 切替機能、１０３ 解析機能、１０４ ロード機能、１０５ 診断機能、１１１ 制御ＳＷＣ、１１４ 圧縮イメージ、１２１ 判断ＳＷＣ、１２４ 圧縮イメージ、１３１ 実行部、１３２ 診断部、１３３ 生成部、１３４ 管理テーブル、１３５ ロード部、１３６ 解凍部、１３７ 第１記憶部、１３８ 算出部、１３９ 第２記憶部、１４０ 解析部、１４１ 通信部、１４２ 第１処理部、１４３ 第２処理部、１４４ 切替器、１５０ 電子制御スロットルシステム、１５２ アクセルペダルセンサ、１５３ エンジン、１５４ モータセンサ、１５７ 予測ＳＷＣ、２０１ 制御ＥＣＵ、２０２ 制御ＳＷＣ、２０４ 送信機能、２１１ 制御ＥＣＵ、２５１ 切替器、２６１ 切替器、３０１ 判断ＥＣＵ、３０２ 判断ＳＷＣ、３０４ 送信機能、３１１ 判断ＥＣＵ、３５１ 切替器、３６１ 切替器、４０１ プロセッサ、４０２ メモリ、４０３ ＣＡＮインタフェース、４１１ ＦＰＧＡ、５０１ プロセッサ、５０２ メモリ、５０３ ＣＡＮインタフェース、５１１ ＦＰＧＡ、６０１ プロセッサ、６０２ メモリ、６０３ ＣＡＮインタフェース、６１１ ＦＰＧＡ、７０１ ＣＡＮ、７１１ ＣＡＮ、８０５ ＡＳＩＬ Ｄ対応ＯＳ、８１５ ＡＳＩＬ Ｃ対応ＯＳ、８２５ ＡＳＩＬ Ｂ対応ＯＳ、８３４ ＡＳＩＬ Ｄ対応ＯＳ、８４４ ＡＳＩＬ Ｄ対応ＯＳ。

Claims (11)

1. 個別の機能を発揮するために機能によって異なるプログラムを実行する複数の電子制御ユニットの異常を診断する診断部と、
   複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、
   前記ロード部によりロードされたプログラムを実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部と
   を備え、
   前記実行部は、前記異常ユニットが２つ以上のプログラムを実行する電子制御ユニットである場合、プログラムごとにあらかじめ予測されたプロセッサの負荷の大きさによって、前記ロード部にロードさせるプログラムを選定する共用バックアップユニット。
2. 個別の機能を発揮するために機能によって異なるプログラムを実行する複数の電子制御ユニットの異常を診断する診断部と、
   複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、
   前記ロード部によりロードされたプログラムを実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部と
   を備え、
   前記実行部は、前記診断部により２つ以上の電子制御ユニットの異常が検知された場合、電子制御ユニットとプログラムとの組み合わせごとにあらかじめ予測されたプロセッサの負荷の大きさによって、前記ロード部にロードさせるプログラムを選定する共用バックアップユニット。
3. 前記複数の電子制御ユニットがプログラムの実行中に使用する状態変数を示す個別のメッセージを前記複数の電子制御ユニットから受信する通信部をさらに備え、
   前記実行部は、前記診断部により異常が検知される前に前記通信部により前記異常ユニットから受信されたメッセージに基づいて、前記ロード部によりロードされたプログラムを実行する際に使用する状態変数を設定する請求項１または２に記載の共用バックアップユニット。
4. 前記複数の電子制御ユニットがプログラムの実行結果として送信する個別のメッセージを前記複数の電子制御ユニットから受信する通信部をさらに備え、
   前記実行部は、前記診断部により異常が検知される前に前記通信部により前記異常ユニットから受信されたメッセージに基づいて、前記異常ユニットがプログラムの実行中に使用する状態変数を推定し、推定した状態変数に合わせて、前記ロード部によりロードされたプログラムを実行する際に使用する状態変数を設定する請求項１または２に記載の共用バックアップユニット。
5. 個別の機能を発揮するために機能によって異なるプログラムを実行する複数の電子制御ユニットの異常を診断する診断部と、
   複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、
   前記ロード部によりロードされたプログラムを実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部と、
   前記複数の電子制御ユニットがプログラムの実行結果として送信する個別のメッセージを前記複数の電子制御ユニットから受信する通信部と、
   を備え、
   前記実行部は、前記診断部により異常が検知される前に前記通信部により前記異常ユニットから受信されたメッセージに基づいて、前記異常ユニットがプログラムの実行中に使用する状態変数を推定し、推定した状態変数に合わせて、前記ロード部によりロードされたプログラムを実行する際に使用する状態変数を設定する共用バックアップユニット。
6. 前記実行部は、前記異常ユニットが２つ以上のプログラムを実行する電子制御ユニットである場合、プログラムごとにあらかじめ定義された優先度によって、前記ロード部にロードさせるプログラムを選定する請求項１から５のいずれか１項に記載の共用バックアップユニット。
7. 前記実行部は、前記診断部により２つ以上の電子制御ユニットの異常が検知された場合、電子制御ユニットとプログラムとの組み合わせごとにあらかじめ定義された優先度によって、前記ロード部にロードさせるプログラムを選定する請求項１から６のいずれか１項に記載の共用バックアップユニット。
8. 請求項１から７のいずれか１項に記載の共用バックアップユニットと、
   前記複数の電子制御ユニットと
   を備える制御システム。
9. それぞれ前記共用バックアップユニットである複数の共用バックアップユニットを備え、
   前記複数の電子制御ユニットがプログラムの実行結果として送信する個別のメッセージには、電子制御ユニットによって異なる識別子が送信元アドレスとして含まれ、
   前記複数の共用バックアップユニットが前記実行部でのプログラムの実行結果として送信する個別のメッセージには、共通の識別子が送信元アドレスとして含まれるとともに、共用バックアップユニットによって異なる識別子が送信データの一部として含まれる請求項８に記載の制御システム。
10. 個別の機能を発揮するために機能によって異なるプログラムを実行する複数の電子制御ユニットと、
    前記複数の電子制御ユニットの異常を診断する診断部と、複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、前記ロード部によりロードされたプログラムを実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部とを備える複数の共用バックアップユニットと
    を備え、
    前記複数の電子制御ユニットがプログラムの実行結果として送信する個別のメッセージには、電子制御ユニットによって異なる識別子が送信元アドレスとして含まれ、
    前記複数の共用バックアップユニットが前記実行部でのプログラムの実行結果として送信する個別のメッセージには、共通の識別子が送信元アドレスとして含まれるとともに、共用バックアップユニットによって異なる識別子が送信データの一部として含まれる制御システム。
11. 個別の機能を発揮するために機能によって異なるプログラムをプロセッサにより実行する複数の電子制御ユニットと、
    前記複数の電子制御ユニットの異常を診断する診断部と、複数のプログラムをあらかじめ記憶するメモリから、前記診断部により異常が検知された電子制御ユニットである異常ユニットが実行するプログラムと同じプログラムをロードするロード部と、前記ロード部によりロードされたプログラムを前記複数の電子制御ユニットのプロセッサよりも低性能なプロセッサにより実行することで、前記異常ユニットの代わりに前記異常ユニットの機能と同じ機能を発揮する実行部とを備える複数の共用バックアップユニットと
    を備え、
    前記実行部は、前記異常ユニットが２つ以上のプログラムを実行する電子制御ユニットである場合、前記実行部を備える共用バックアップユニットが、プログラムごとにあらかじめ登録された退避先の共用バックアップユニットに該当するかどうかによって、前記ロード部にロードさせるプログラムを選定する制御システム。

Images