JP2020096298A - 通信制御装置 - Google Patents

Abstract

【課題】通信のリアルタイム性を保証すると共に、演算制御装置の負荷率を軽減することを可能にした通信制御装置を提供する。【解決手段】第１の演算制御装置及び第２の演算制御装置の間を第１及び第２の通信手段で冗長接続し、それぞれ第１及び第２のデータを送受信する。マスク付き受信部は、前記第１のデータ又は前記第２のデータのいずれか一方を正常に受信完了した際には他方受信動作をマスクし、一方についてのみ受信処理を行う。【選択図】図１

Description

本発明は、通信制御装置に関し、特に、複数のマイコンを組み合わせて所定の制御処理を実行するとともに、マイコン（演算制御装置）間を相互に冗長接続する通信方式を備えた通信制御装置に関する。

自動車に関連する様々な社会的課題を解決する手段として、自動運転に対するニーズが増大している。運転の自動化レベルを示す指標としてはSociety of Automotive Engineers（ＳＡＥ）によるＪ３０１６がよく知られている。レベル１に相当するアダプティブクルーズコントロールやレーンキーピングアシストシステムといった、運転者の操作を部分的に支援する機能はすでに実用化されている。一方で、運転者が運転に介入することを不要にしたレベル４やレベル５対応の自動運転車は、それぞれ２０２５年及び２０３０年を目途に市場投入されると期待されている。それらの実現に向け、従来の完成車メーカやサプライヤ各社に加え、例えば画像認識や機械学習に強みをもつ異業種からの参入プレーヤやベンチャ企業が開発に鎬を削っているのが現状である。

車両の縦方向（加減速）と横方向（ステアリング）の運動を同時に制御するレベル２以上の自動運転車では、自動運転ＥＣＵと呼ばれる車両制御装置が車両制御の中心的役割を担うことになる。自動運転ＥＣＵには、（１）自車及び周囲の環境に関するデータを取得するセンシング、（２）取得したセンサデータや地図情報を統合し分析する状況認識、（３）認識結果に基づき安全な走行軌道を生成する行動計画、（４）行動計画を自車の運動に反映させるためのアクチュエータ制御、等を含む複雑な各種情報処理を、大規模なデータに対しリアルタイムに実行することが求められる。

自動運転ＥＣＵのアーキテクチャや実装方式に関し共通プラットフォームと呼べるものは現在のところ存在しない。上記情報処理のステージごとに独立したマイコン上で動作する複数の機能モジュールを実装し、それら複数の機能モジュール間を通信手段により相互接続することで各処理を連携させる分散システムは、技術的なメリットが多いと考えられている。

一方で、上記のモジュラ設計を導入することにより、複数の機能モジュール間の接続が新たなボトルネックを発生させる可能性がある。すなわち、制御処理全体を複数のマイコンによりソフトウェアパイプラインとして実行するため、処理の中間データをモジュールの主要構成デバイスであるマイコン間でリアルタイム（例えば１０ミリ秒オーダ）に受け渡す必要が生じ、このような中間データのやり取りがボトルネックを発生させ得る。

加えて、自動車向け応用においては、システムを構成する装置の一部が故障した場合でも、システム全体として所定の制御性と安全状態を維持することが期待される。そのため、自動運転ＥＣＵのような特に重要度の高い装置においては、マイコン間通信手段を含むハードウェアの冗長構成を採用することが求められる。

自動車向け応用ほどのリアルタイム性が要求されない分野においては、非特許文献１に開示されているように、イーサネットスイッチ（「イーサネット」は登録商標）を介して通信経路を冗長化するとともに、所定のプロトコルにより切り替えを含む経路管理を行う実装が公知である。

図１７は、従来方式により経路冗長化したマイコン間通信システムの一例を示す。マイコン９００はイーサネットプロトコルを処理するイーサネットアダプタ９０１を内蔵し、マイコン外部への接続ポート９０２及びイーサネットケーブル９０３を介して、マイコン外部とのイーサネット通信を行う。マイコン９００に接続ポート９０２が１つのみ実装されている場合には、マイコン９００ごとに外部にイーサネットスイッチ９１０が追加され、イーサネットケーブル９０３がイーサネットスイッチ９１０に備えられた複数のスイッチ接続ポート９１４（９１４ａ〜９１４ｈ）のいずれかに接続される。

更に、複数のスイッチ接続ポート９１４を利用して複数のイーサネットスイッチ９１０間をイーサネットケーブル９１５−１、９１５−２…により並列接続することで、マイコン間通信の経路冗長化を実現することができる。

イーサネットスイッチ９１０は、スイッチ接続ポート９１４間のフレーム転送ルールに関する制御情報を保持する制御テーブル９１１を有し、スイッチマトリクス制御インタフェース９１２を介してスイッチマトリクス９１３の動作を制御する。これにより、指定されたスイッチ接続ポート９１４間でフレーム転送が実行される。

更に、イーサネットスイッチ９１０はスパニングツリープロトコル（ＳＴＰ：Spanning Tree Protocol）をサポートすることで、ＳＴＰの定める手順に従い、ループ状の通信経路に起因するブロードキャストストームを抑止する目的で冗長化された２つの通信経路のうち一方のみのフレーム転送を有効とする。また、イーサネットスイッチ９１０は、ＳＴＰの定める手順に従い、ネットワーク管理用フレームの不達により通信経路の障害を検出した場合には、障害を含まない側の通信経路を有効とするよう、制御テーブル９１１の内容を適切に更新する。これにより、通信経路の冗長化及び障害時の経路切り替え制御が実現される。

ただし、ＳＴＰの仕様により障害発生から経路切り替え完了までの数１０秒間は通信不可となるため、リアルタイム性の要件を満たすことはできない。通信経路の冗長化によりマイコン間通信の耐障害性向上を図る場合、従来方式ではプロトコルに依存する切り替え時間に加え、通信エラー検出を起点とするリカバリ処理に伴うオーバヘッドが制御周期とは非同期に発生することで、通信のリアルタイム性を保証できなくなる虞がある。また冗長化された複数データの受信処理により演算制御装置（ＣＰＵ）の負荷率が上昇する虞がある。

宇野俊夫（２０１１）『独習ＴＣＰ／ＩＰ ＩＰネットワーキング編』翔泳社

本発明は、通信のリアルタイム性を保証すると共に、演算制御装置の負荷率を軽減することを可能にした通信制御装置を提供することを目的とする。

本発明に係る通信制御装置は、第１の演算制御装置と第２の演算制御装置とを接続し、第１のデータを送受信する第１の通信手段と、前記第１の演算制御装置と前記第２の演算制御装置とを接続し、前記第１のデータとは異なる第２のデータを送受信する第２の通信手段と、前記第１の通信手段及び第２の通信手段に接続され、前記第１のデータ又は前記第２のデータのいずれか一方を正常に受信した際には、他方の受信動作をマスクするマスク付き受信部とを備えたことを特徴とする。

本発明に係る通信制御装置では、第１及び第２の演算制御装置の間を第１及び第２の通信手段で冗長接続し、それぞれ第１及び第２のデータを転送する。受信側では、第１のデータ又は第２のデータのいずれか一方を正常に受信完了した際には他方の受信動作をマスク付き受信部によりマスクし、一方についてのみ受信処理を行うことで、ＣＰＵ負荷率の上昇を抑止することができる。従って、本発明によれば、通信のリアルタイム性を保証すると共に、演算制御装置の負荷率を軽減することを可能にした通信制御装置を提供することができる。

本発明の第１の実施の形態に係る車両制御装置１の構成を示すブロック図である。 遅延付き送信部１００の詳細な構成を示すブロック図である。 マスク付き受信部１２０の詳細な構成を示すブロック図である。 図４は、受信状態保持レジスタ１３７に保持される情報と、その情報に基づく受信マスク制御部１３６の動作との関係を示すテーブルである。 動作モード制御部１４０の詳細な構成を示すブロック図である。 動作モード決定部１５０の動作モード決定フローを示すフローチャートである。 タイマ１５２におけるアンダフロー発生の有無に基づく、動作モード制御部１４０の動作モード決定メカニズムを示すタイミングチャートである。 タイマ１５２におけるアンダフロー発生の有無に基づく、動作モード制御部１４０の動作モード決定メカニズムを示すタイミングチャートである。 制御周期内のＴＰ１／ＴＰ２受信完了順序と、第２のマイコン２０の実行ソフトウェアとの関係を動作レベルで示すタイミングチャートである。 制御周期内のＴＰ１／ＴＰ２受信完了順序と、第２のマイコン２０の実行ソフトウェアとの関係を動作レベルで示すタイミングチャートである。 制御周期内のＴＰ１／ＴＰ２受信完了順序と、第２のマイコン２０の実行ソフトウェアとの関係を動作レベルで示すタイミングチャートである。 制御周期内のＴＰ１／ＴＰ２受信完了順序と、第２のマイコン２０の実行ソフトウェアとの関係を動作レベルで示すタイミングチャートである。 本発明の第２の実施の形態に係る車両制御装置１に従う、制御周期を跨ぐ動作モード制御方式に基づく第２のマイコン２０の動作を示す。 本発明の第２の実施の形態に係る車両制御装置１に従う、制御周期を跨ぐ動作モード制御方式に基づく第２のマイコン２０の動作を示す。 本発明の第２の実施の形態に係る車両制御装置１に従う、制御周期を跨ぐ動作モード制御方式に基づく第２のマイコン２０の動作を示す。 本発明の第２の実施の形態に係る車両制御装置１に従う、制御周期を跨ぐ動作モード制御方式に基づく第２のマイコン２０の動作を示す。 従来方式により経路冗長化したマイコン間通信を示す。

以下、添付図面を参照して本実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号又は対応する番号で表示される場合もある。なお、添付図面は本開示の原理に則った実施形態と実装例を示しているが、これらは本開示の理解のためのものであり、決して本開示を限定的に解釈するために用いられるものではない。本明細書の記述は典型的な例示に過ぎず、本開示の特許請求の範囲又は適用例を如何なる意味においても限定するものではない。

本実施形態では、当業者が本開示を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本開示の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

［第１の実施の形態］
図１は、本発明の第１の実施の形態に係る車両制御装置１（通信制御装置）の構成を示す。車両制御装置１（ＥＣＵ）は、当該装置に課せられた所定の制御処理のうち、それぞれ一部を実行する第１のマイコン１０(第１の演算制御装置)及び第２のマイコン２０（第２の演算制御装置）を備える。説明の簡単のため、図１では車両制御装置１が２個のマイコン１０、２０を有しているものとして説明をするが、車両制御装置１が２より大きい数のマイコンを有していてもよいことは言うまでもない。２より大きい数のマイコンが１つの車両制御装置に含まれている場合でも、その中の２つのマイコンの構成を、以下の説明に従って構成することが可能である。

第１のマイコン１０及び第２のマイコン２０の間の接続は、第１の通信手段１０１（以下ＴＰ１とも記す）と第２の通信手段１０２（以下ＴＰ２とも記す）による冗長接続の態様で構成される。特に制限されないが、説明を簡潔にするため、マイコン間のデータ通信方向は第１のマイコン１０（送信側）から第２のマイコン２０（受信側）に限定して説明を行う。第１の通信手段１０１と第２の通信手段１０２は、準拠する規格／仕様は共通であってもよいし、その一部又は全部が異なるものであってもよい。一例としては、第１の通信手段１０１はＰＣＩｅなどの高速インタフェースであり、第２の通信手段１０２はＣＡＮやＳＰＩ等の低速インタフェースであるが、これに限られるものではない。

第１の通信手段１０１は、所定の制御処理の実行に必要な全制御データ（以下「通常時データ」又は「第１のデータ」とも記す）の転送に利用するインタフェースである。また、第２の通信手段１０２は、冗長接続を構成する第１の通信手段１０１と第２の通信手段１０２の一方に通信障害が生じた場合に実行する縮退処理に必要な制御データ（以下「縮退時データ」又は「第２のデータ」とも記す）の転送に利用するインタフェースである。

どのデータを縮退時データとするかは、装置構成、ネットワーク構成、通信路の状況等に応じて適宜決定することができる。縮退時データは、通常時データのうちの一部のデータとしてもよい。一例としては、自動運転に必要な全てのデータのうち、緊急停止に必要なデータのみを縮退時データとして抽出することができる。又は、縮退時データは、通常時データの一部又は全部から所定のアルゴリズムに基づき生成したダイジェストデータであってもよい。あるいは、縮退時データは、それらの任意の組み合わせであってもよい。なお、２つのマイコン１０、２０の間のインタフェースの数は、２に限定されるものではなく、３以上であってもよい。３以上のインタフェースのうちの幾つかが通常時データの転送に利用され、それ以外のインタフェースが縮退時データの転送に利用可能とされていればよい。

第１のマイコン１０は、所定の制御処理の一部に相当する第１の制御アプリケーション２１０を実行可能に構成されている。第１のマイコン１０は、遅延付き送信部１００を備えている。第１の制御アプリケーション２１０は、実行の結果得られた通常時データ及び縮退時データを、遅延付き送信部１００が提供する送信インタフェース２１１を利用し第２のマイコン２０に送出する。遅延付き送信部１００は、後述するように、通常時データの受信の完了を縮退時データの受信の完了に先行させるため、第１の通信手段１０１の転送処理よりも、第２の通信手段１０２の転送処理を遅延させる遅延処理を実行可能に構成されている。

第２のマイコン２０は、第２の制御アプリケーション２２０、第１の縮退モード用システムソフトウェア２３０、及び第２の縮退モード用システムソフトウェア２４０を実行可能に構成されている。第２の制御アプリケーション２２０は、第１の制御アプリケーション２１０と同様に、所定の制御処理の一部に相当する処理を実行する。第１の縮退モード用システムソフトウェア２３０は、冗長接続に生じた通信障害が第１の段階である場合に選択・実行される。第２の縮退モード用システムソフトウェア２４０は、冗長接続に生じた通信障害が第２の段階である場合に選択・実行される。

また、第２のマイコン２０は、マスク付き受信部１２０、動作モード制御部１４０、及びスケジューリング制御部１６０を備える。

マスク付き受信部１２０は、第１の通信手段１０１及び第２の通信手段１０２に接続され、各通信手段の受信状態や障害発生（受信未完了、又は受信処理中にエラー検出）の有無に基づき所定の手続きにより生成した受信状態通知を、受信状態制御インタフェース１２２から動作モード制御部１４０に対して出力する。

動作モード制御部１４０は、マスク付き受信部１２０の状態（マスク付き受信部１２０から受信した受信状態通知）及び／又は自身の内部状態に基づき、次に第２のマイコン２０が遷移すべき状態（モード）を決定する。そして、動作モード制御部１４０は、動作モード制御インタフェース１４１経由でスケジューリング制御部１６０へ、第２のマイコン２０が遷移すべき状態を指示する。

スケジューリング制御部１６０は、動作モード制御部１４０からの指示に従い、指示に従ったソフトウェアの実行を指示する。例えば、次に実行すべき（遷移すべき）ソフトウェアが第２の制御アプリケーション２２０の場合には、実行制御インタフェース１６１により、第２の制御アプリケーション２２０の実行が指示される。次に実行すべき（遷移すべき）ソフトウェアが第１の縮退モード用システムソフトウェアの場合には、実行制御インタフェース１６２により、第１の縮退モード用システムソフトウェアの実行が指示される。次に実行すべき（遷移すべき）ソフトウェアが第２の縮退モード用システムソフトウェアの場合には、実行制御インタフェース１６３により、第２の縮退モード用システムソフトウェアの実行が指示される。実行を指示されたソフトウェアは、マスク付き受信部１２０の提供する受信インタフェース１２１を利用してデータの受信を行う。実行を指示されたソフトウェアは、通常時データ及び／又は縮退時データの受信処理を行う。実行の指示に対象外とされたソフトウェアは、いずれのデータの受信処理も行わない。

図２は、遅延付き送信部１００の詳細な構成の一例を示す。遅延付き送信部１００は、一例として、送信トリガ制御部１１０、第１の送信バッファ１１４、第２の送信バッファ１１６、第１の送信制御部１１８、及び第２の送信制御部１１９を備える。

第１の送信バッファ１１４は、通常時データを第１の通信手段１０１を介して送信するために通常時データを一時格納するデータ記憶部である。第１の送信バッファ１１４に一時格納された通常時データは、第１の送信データインタフェース１１５を介し第１の送信制御部１１８に出力される。

また、第２の送信バッファ１１６は、縮退時データを第２の通信手段１０２を介して送信するために縮退時データを一時格納するデータ記憶部である。第２の送信バッファ１１６に一時格納された縮退時データは、第２の送信データインタフェース１１７を介し第２の送信制御部１１９に出力される。

第１の送信制御部１１８は、第１の送信データインタフェース１１５から取得した送信データ（通常時データの一部又は全部）を所定のプロトコルに従い第１の通信手段１０１に送出する。また、第２の送信制御部１１９は、第２の送信データインタフェース１１７から取得した送信データ（縮退時データの一部又は全部）を所定のプロトコルに従い第２の通信手段１０２に送出する。

送信トリガ制御部１１０は、第１の通信手段１０１及び第２の通信手段１０２への送信開始タイミング時間の差分を計測し、カウントダウン動作が可能なタイマ１１１を備える。送信トリガ制御部１１０は、送信トリガインタフェース１１２、１１３を介して、それぞれ第１の通信手段１０１へのデータの送信開始、及び第２の通信手段１０２へのデータの送信開始を指示するトリガを、第１の送信制御部１１８及び第２の送信制御部１１９に送信する。

なお、第１の制御アプリケーション２１０と遅延付き送信部１００とのインタフェースとなる送信インタフェース２１１は、第１の送信バッファ１１４、第２の送信バッファ１１６への送信データ格納に加え、送信バッファの空き状態チェックや明示的な送信要求を可能とするインタフェースを含んでいてよい。

特に制限されないが、送信トリガ制御部１１０は、第１の制御アプリケーション２１０からの送信開始要求を受け、タイマ１１１のカウント値を所定の初期カウント値に設定する。その後、タイマ１１１にカウントダウン動作を開始させ、同時に送信トリガインタフェース１１２を介して、第１の通信手段１０１への通常時データの送信開始を指示する。

送信トリガ制御部１１０は更に、タイマ１１１のカウント値がゼロ以下（アンダフロー）となった時点でカウントダウン動作を停止させ、同時に第２の通信手段１０２への送信トリガインタフェース１１３を介して、第２の通信手段１０２への縮退時データの送信開始を指示する。なお、第１の通信手段１０１及び第２の通信手段１０２がいずれも一度の送受信動作で正常に通信が完了する（すなわち再送が発生しない）という条件下で、通常時データの受信完了時刻が縮退時データの受信完了時刻に対して先行するよう、タイマ１１１の初期カウント値を設定することができる。このように設定することで、通常時データの受信の完了を縮退時データの受信の完了に先行させることができ、データ送受信のオーバヘッドを低減することが可能になる。マスク付き受信部１２０は、受信の不要なデータをマスクすることにより演算制御装置の負荷率を軽減する役割を有するが、この遅延付き送信部１００は、データ送信のタイミングの遅延により、通常時データの受信が縮退時データの受信に比べて先行するようにすることで、演算制御装置の負荷率を軽減することができる。

図３は、マスク付き受信部１２０の詳細な構成を示すブロック図である。

マスク付き受信部１２０は、所定のプロトコルに従い第１の通信手段１０１からデータ（通常時データ）を受信する第１の受信制御部１３０、所定のプロトコルに従い第２の通信手段１０２からデータ（縮退時データ）を受信する第２の受信制御部１３３、第１の受信データインタフェース１３２から取得した受信データ（通常時データ）を格納する第１の受信バッファ１３８、第２の受信データインタフェース１３５から取得した受信データ（縮退時データ）を格納する第２の受信バッファ１３９を備える。また、マスク付き受信部１２０は受信マスク制御部１３６を備える。

第１の受信制御部１３０は、第１の通信手段１０１の準拠するプロトコルで定義された受信処理が完了すると、第１の受信状態通知インタフェース１３１に対し、受信状態（受信処理完了及び受信処理中のエラー検出の有無）を出力する。通信エラーの検出については、送信データに対して付加された巡回冗長検査（ＣＲＣ）コードのチェックなど、第１の通信手段１０１の準拠するプロトコルにて規定された手段を利用するものとする。

第２の受信制御部１３３は、第２の通信手段１０２の準拠するプロトコルで定義された受信処理が完了すると、第２の受信状態通知インタフェース１３４に対し、受信状態（受信処理完了及び受信処理中のエラー検出の有無）を出力する。通信エラーの検出については、送信データに対して付加された巡回冗長検査（ＣＲＣ）コードのチェックなど、第２の通信手段１０２の準拠するプロトコルにて規定された手段を利用するものとする。

受信マスク制御部１３６は、第１の受信状態通知インタフェース１３１を経由して取得した第１の受信制御部１３０の受信状態、第２の受信状態通知インタフェース１３４を経由して取得した第２の受信制御部１３３の受信状態に加え、自身による受信マスク動作の有効性を指定する受信マスク設定情報を、受信状態保持レジスタ１３７に保持する。

受信マスク制御部１３６は更に、受信状態保持レジスタ１３７の保持データに基づき、後述する手続きにより生成した受信状態通知を、受信状態制御インタフェース１２２から動作モード制御部１４０へ出力する。また、受信マスク制御部１３６は、受信状態制御インタフェース１２２から受信状態保持レジスタ１３７の更新要求を受信した場合には、要求された更新処理を行う。

なお、第２の制御アプリケーション２２０、第１の縮退モード用システムソフトウェア２３０、及び第２の縮退モード用システムソフトウェア２４０とのインタフェースとしての受信インタフェース１２１は、第１の受信バッファ１３８、第２の受信バッファ１３９に格納された受信データに加え、受信状態保持レジスタ１３７の保持データの一部又は全部の取得を可能とするインタフェースを含んでいてよい。

図４は、受信状態保持レジスタ１３７に保持される情報と、その情報に基づく受信マスク制御部１３６の動作（受信状態通知、受信マスク更新）との関係を示すテーブルである。

受信状態保持レジスタ１３７は、一例として以下の設定情報、又は状態情報を示すデータを保持可能に構成されている。
（１）第１の通信手段１０１（ＴＰ１）に関して、受信完了時に動作モード制御部１４０への完了通知をマスクするかどうかを設定するＴＰ１受信マスク設定（Ｃ１０１）
（２）第１の受信制御部１３０が受信処理を完了したか否かを示すＴＰ１受信状態（完了）（Ｃ１０２）
（３）第１の受信制御部１３０の受信処理中にエラーを検出したか否かを示すＴＰ１受信状態（エラー）（Ｃ１０３）
（４）第２の通信手段１０２（ＴＰ２）に関して、受信完了時に動作モード制御部１４０への完了通知をマスクするかどうかを設定するＴＰ２受信マスク設定（Ｃ２０１）
（５）第２の受信制御部１３３が受信処理を完了したか否かを示すＴＰ２受信状態（完了）（Ｃ２０２）
（６）第２の受信制御部１３３の受信処理中にエラーを検出したか否かを示すＴＰ２受信状態（エラー）（Ｃ２０３）

受信状態保持レジスタ１３７は、受信マスク設定（Ｃ１０１、Ｃ２０１）に関する情報を、受信インタフェース１２１又は受信状態制御インタフェース１２２からの更新要求に応じて、それぞれ独立してセット（Ｙ：マスクは有効とされ、受信完了通知は無効とされる）又はクリア（Ｎ：マスクは無効とされ、受信完了通知は有効とされる）を行うことが可能なように構成され得る。

また、受信状態保持レジスタ１３７は、受信状態（完了）（Ｃ１０２、Ｃ２０２）に関する情報を、受信マスク制御部１３６の指示によりセット（Ｙ：受信完了）又はクリア（Ｎ：受信未完了）を行うことが可能に構成され得る。加えて、受信状態保持レジスタ１３７は、受信インタフェース１２１又は受信状態制御インタフェース１２２からの要求に応じて、受信状態（完了）（Ｃ１０２、Ｃ２０２）に関する情報のクリア（Ｎ：受信未完了）のみが可能に構成されることもできる。

更に、受信状態保持レジスタ１３７は、受信完了（エラー）（Ｃ１０３、Ｃ２０３）に関する情報を、受信状態（完了）がＹ（受信完了）である場合のみ有効に設定することができる。また、受信状態保持レジスタ１３７は、受信マスク制御部１３６の指示により、受信完了（エラー）（Ｃ１０３、Ｃ２０３）に関する情報についてセット（Ｙ：エラーあり）又はクリア（Ｎ：エラーなし）を設定可能である。これに代えて、受信インタフェース１２１又は受信状態制御インタフェース１２２からの要求によりクリア（Ｎ：エラーなし）のみが可能に構成されることもできる。

なお、受信中にエラーを検出した場合の受信完了通知の有効性を選択可能とするため、受信マスク設定（Ｃ１０１、Ｃ２０１）とは独立した設定（以下「拡張受信マスク設定」と記す）を、受信状態保持レジスタ１３７の保持対象データとして追加してもよい。このとき、以下の（１）〜（３）のうちのいずれかの動作を、通信手段毎に独立に設定することができる。
（１）受信マスク設定＝Ｙ（マスク有効）
この場合、拡張受信マスク設定の設定内容によらず受信完了通知は無効とされる。
（２）受信マスク設定＝Ｎ（マスク無効）、且つ拡張受信マスク設定＝Ｎ（マスク無効）
この場合、受信中のエラー検出の有無によらず受信完了通知は有効とされる。
（３）受信マスク設定＝Ｎ（マスク無効）、且つ拡張受信マスク設定＝Ｙ（マスク有効）
この場合、受信中にエラーが検出されなかった場合のみ受信完了通知は有効とされる。

受信マスク制御部１３６は、図４のテーブルに従い、第１の通信手段１０１と第２の通信手段１０２のうち、受信処理が先行して完了し且つ受信マスクが無効に設定されている通信手段については、当該通信手段に関する受信状態通知（Ｃ３０１）を、受信状態制御インタフェース１２２から出力する。なお、拡張受信マスク設定が追加されていれば当該設定を併せて反映する。

同時に、先行して完了した受信処理でエラーが検出されなかった場合、受信処理が未完了の通信手段に関する受信状態通知を抑止するよう受信マスクを更新（Ｃ３０２）する。本制御により、第２のマイコン２０の動作に影響しない受信データについてはソフトウェアによる受信処理を省略し、冗長化された通信手段であってもＣＰＵ負荷率の上昇を抑止することが可能となる。

図５は、動作モード制御部１４０の詳細な構成を示すブロック図である。

動作モード制御部１４０は、動作モード決定部１５０と、カウントダウン動作が可能な１つ以上のタイマ１５２（１５２ａ及び１５２ｂ）を備えたデッドライン検出部１５１とを備える。動作モード決定部１５０とデッドライン検出部１５１とは、タイマ１５２のそれぞれについてカウント値がゼロ以下（アンダフロー）であることを示すデータを送信するためのデッドライン通知インタフェース１５３により相互接続される。この第１の実施の形態の動作モード制御部１４０は、１の制御周期Ｔｃ毎にデータ受信の状況を判断し、動作モードを切り替える。デッドライン検出部１５１は、所定の制御周期の中でデータが所定時間内に正常に受信を完了するか否かを検出する機能を有する。

動作モード決定部１５０は、受信状態制御インタフェース１２２から取得した受信状態通知、及びデッドライン検出部１５１からデッドライン通知インタフェース１５３を経由して取得したデッドライン検出情報に基づき、第２のマイコン２０の動作モードを決定し、その決定の結果を動作モード制御インタフェース１４１に出力することでスケジューリング制御部１６０に通知する。

動作モード制御部１４０は、制御周期の開始タイミングを特定する制御周期開始トリガも受信可能に構成される。動作モード制御部１４０は、制御周期開始トリガを受信すると、１つ以上のタイマ１５２のカウント値をそれぞれ所定の初期カウント値に設定した後、タイマ１５２のカウントダウン動作を開始させる。同時に動作モード制御部１４０は、受信状態保持レジスタ１３７の保持データの初期化を、受信状態制御インタフェース１２２経由でマスク付き受信部１２０中の受信マスク制御部１３６に対して要求する。具体的には、保持データＣ１０１、Ｃ１０２、Ｃ１０３、Ｃ２０１、Ｃ２０２、Ｃ２０３がクリアされる。ただし、拡張受信マスク設定の内容は保持される。

また、動作モード決定部１５０は、１つ以上のタイマ１５２のうちいずれかのカウント値がゼロ以下（アンダフロー）となったことがデッドライン検出部１５１から通知されると、デッドライン通知インタフェース１５３を介して当該タイマ１５２のカウントダウン動作の停止を指示する。当該タイマ１５２が特定のタイマ（１５２ｂ）であった場合には、受信状態保持レジスタ１３７に保持されたＴＰ１受信マスク設定（Ｃ１０１）を有効（Ｙ）とするよう、受信状態制御インタフェース１２２を介して受信マスク制御部１３６に対し要求する。

また、特に制限されないが、タイマ１５２ｂの初期カウント値には、制御周期Ｔｃから第２の制御アプリケーション２２０の実行に要する時間Ｔｅ１を減じた、第１の通信手段１０１の受信処理を許可する時間（ＴＰ１受信ウィンドウ（第１の経過時間））Ｔｒ１（＝Ｔｃ−Ｔｅ１）を計測するためのカウント値を設定することができる。これにより、第１の通信手段１０１の受信完了タイミングの遅延が原因として、第２の制御アプリケーション２２０の処理が当該制御周期内に完了しないという問題を回避することができる。

また、特に制限されないが、タイマ１５２ａの初期カウント値には、制御周期Ｔｃから第２の縮退モード用システムソフトウェア２４０の実行に要する時間Ｔｅ２を減じた、第１の通信手段１０１又は第２の通信手段１０２の受信処理を許可する時間（デッドライン時間（第２の経過時間））Ｔｒ２（＝Ｔｃ−Ｔｅ２）を計測するためのカウント値を設定することができる。これにより、第１の通信手段１０１及び第２の通信手段１０２のいずれも正常に受信完了しなかったことを原因として、第２の縮退モード用システムソフトウェア２４０の処理が当該制御周期内に完了しないという問題を回避することができる。デッドライン時間Ｔｒ２は、上述のＴＰ１受信ウィンドウＴｒ１よりも長い時間に設定され得る。

次に、動作モード決定部１５０において動作モードを決定するための手順を、図６のフローチャートを参照して説明する。動作モード決定部１５０は、デッドライン通知インタフェース１５３からのデッドライン情報と、受信状態制御インタフェース１２２からの受信状態通知（Ｃ３０１）に基づき、以下の処理フローにより第２のマイコン２０の動作モードを決定し、その決定情報を動作モード制御インタフェース１４１に出力してスケジューリング制御部１６０に転送する。

本手順では、まずタイマ１５２ａのアンダフローにより、制御周期開始からデッドライン時間Ｔｒ２が経過（デッドライン検出）しているかどうかを確認する（ステップＳ１０１）。デッドライン検出が認められた場合には（ステップＳ１０１：Ｙｅｓ）、第１の通信手段１０１及び第２の通信手段１０２の両方で障害が発生していると判断し、動作モード制御インタフェース１４１により第２の縮退モードへの遷移を要求（ステップＳ１０７）する。この要求を受信したスケジューリング制御部１６０は、第２の縮退モード用システムソフトウェアへの実行制御インタフェース１６３により、第２の縮退モード用システムソフトウェア２４０の実行をトリガ（指示）する。

デッドライン検出が認められない場合（ステップＳ１０１：Ｎｏ）は、続いて受信状態通知（Ｃ３０１）が「受信待ち」であるかどうかを確認（ステップＳ１０２）し、「受信待ち」である場合（ステップＳ１０２：Ｙｅｓ）にはステップＳ１０１に戻り、デッドライン検出、又は第１の通信手段１０１又は第２の通信手段１０２のいずれかの受信完了を示す受信状態通知が得られるまで、上記のループが繰り返される。

受信状態通知が「受信待ち」でなかった場合には（ステップＳ１０２：Ｎｏ）、更に受信状態通知（Ｃ３０１）が「ＴＰ１受信完了（正常）」であるかどうかが確認される（ステップＳ１０３）。

「ＴＰ１受信完了（正常）」である場合（ステップＳ１０３：Ｙｅｓ）は、第１の通信手段１０１から通常時データを正常に受信できたと判断し、動作モード制御インタフェース１４１により通常モードへの遷移が要求される（ステップＳ１０５）。この要求を受信したスケジューリング制御部１６０は、第２の制御アプリケーションへの実行制御インタフェース１６１により、第２の制御アプリケーション２２０の実行をトリガする。

一方、受信状態通知が「ＴＰ１受信完了（正常）」でなかった場合（ステップＳ１０３：Ｎｏ）は、更に受信状態通知（Ｃ３０１）が「ＴＰ２受信完了（正常）」であるかどうかが確認される（ステップＳ１０４）。

「ＴＰ２受信完了（正常）」である場合（ステップＳ１０４：Ｙｅｓ）は、第１の通信手段１０１に障害が発生しているがＴＰ２から縮退時データを正常に受信できたと判断し、動作モード制御インタフェース１４１により第１の縮退モードへの遷移を要求（ステップＳ１０６）する。この要求を受信したスケジューリング制御部１６０は、第１の縮退モード用システムソフトウェアへの実行制御インタフェース１６２により、第１の縮退モード用システムソフトウェア２３０の実行をトリガする。

一方、受信状態通知が「ＴＰ２受信完了（正常）」でなかった場合（ステップＳ１０４：Ｎｏ）は、第１の通信手段１０１、第２の通信手段１０２の両方で障害が発生していると判断し、動作モード制御インタフェース１４１により第２の縮退モードへの遷移を要求（ステップＳ１０７）する。この本要求を受信したスケジューリング制御部１６０は、第２の縮退モード用システムソフトウェアへの実行制御インタフェース１６３により、第２の縮退モード用システムソフトウェア２４０の実行をトリガする。

上記の構成によれば、第１の通信手段１０１／第２の通信手段１０２の受信状態と受信完了順序の様々な組み合わせが異なると、動作モード制御部１４０における制御情報の入出力、決定される動作モード、第２のマイコン２０で実行されるソフトウェアが異なる。以下、図７〜図１６を参照して、異なる組合せ毎の各部の動作を説明する。

図７及び図８は、それぞれＴＰ１受信ウィンドウＴｒ１、デッドライン時間Ｔｒ２を計測するタイマ１５２ｂ、１５２ａにおけるアンダフロー発生の有無に基づく、動作モード制御部１４０の動作モード決定メカニズムを詳細に示したタイミングチャートである。図７〜図８では、Ｃａｓｅ１−１〜１−３を示している。図７、図８は、それぞれ、その左側においてＣａｓｅ１−１の場合のタイミングチャートを図示し、その右側にＣａｓｅ１−２、１−３を示している。Ｃａｓｅ１−１〜１−３は、様々な状況の変化により生じ得動作を示したものであり、それぞれ独立である。

＜Ｃａｓｅ１−１＞
図７及び図８に示すように、Ｃａｓｅ１−１は、第１の通信手段１０１で第２の通信手段１０２に先行してＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了したことで、当該制御周期は通常モード用の処理である第２の制御アプリケーション２２０を実行する場合を示している。

動作モード制御部１４０中の動作モード決定部１５０は、動作モード制御インタフェース１４１を介して、スケジューリング制御部１６０から制御周期開始トリガ（Ｔ）を受信する。トリガ（Ｔ）を受信した動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ａ及び１５２ｂへの初期カウント値の再ロード（Ｌ）を指示し、同時に受信状態制御インタフェース１２２に対して受信状態保持レジスタ１３７の初期化（リセット）要求（Ｒ）を出力する。

再ロード（Ｌ）の指示を受けたデッドライン検出部１５１は、タイマ１５２ａ、１５２ｂに対し、制御周期先頭を基準にそれぞれデッドライン時間Ｔｒ２、ＴＰ１受信ウィンドウＴｒ１の経過を計測するための所定のカウント値を設定し、デクリメント動作の開始を指示する。また、初期化要求（Ｒ）を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうち拡張受信マスク設定以外の保持データをすべてクリアすることで、第１の通信手段１０１、及び第２の通信手段１０２での受信完了通知が有効となるよう設定する。

ＴＰ１受信ウィンドウＴｒ１内に第１の受信制御部１３０が通常時データを正常に受信完了すると、当該情報は第１の受信状態通知インタフェース１３１により受信マスク制御部１３６に伝達される。受信マスク制御部１３６は、当該情報を反映するよう受信状態保持レジスタ１３７の内容を更新（図４の＃５に相当）し、同時に受信状態制御インタフェース１２２に対して、受信状態通知「ＴＰ１受信完了（正常）」を出力する。加えて、受信が未完了である第２の通信手段１０２についてＴＰ２受信マスク（Ｃ２０１）を設定（図４の＃７に遷移）することで、当該制御周期内の受信状態が確定する（図７参照）。

受信状態制御インタフェース１２２の受信状態通知を監視していた動作モード決定部１５０は、図６の動作モード決定フローに基づき通常モードへの遷移を決定し、動作モード制御インタフェース１４１を介してスケジューリング制御部１６０に当該遷移を指示（Ｃ）する。動作モード決定部１５０は同時に、偽のアンダフローイベント発生を抑止するため、デッドライン通知インタフェース１５３によりタイマ１５２ａ、１５２ｂのデクリメント動作の停止を指示する（図７参照）。

遷移指示（Ｃ）を受けたスケジューリング制御部１６０は、第２の制御アプリケーションへの実行制御インタフェース１６１により、第２の制御アプリケーション２２０の実行を指示する。

＜Ｃａｓｅ１−２＞
図７の右側に示すように、Ｃａｓｅ１−２は、第１の通信手段１０１はＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了できず（受信未完了、又は受信完了したが受信中にエラー検出のいずれか）、第２の通信手段１０２でデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了し、このため、当該制御周期は第１の縮退モード用の処理である第１の縮退モード用システムソフトウェア２３０を実行する場合を示している。

動作モード決定部１５０は、動作モード制御インタフェース１４１を介して、スケジューリング制御部１６０から制御周期開始トリガ（Ｔ）を受信する。トリガ（Ｔ）を受信した動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ａ及び１５２ｂへの初期カウント値の再ロード（Ｌ）を指示し、同時に受信状態制御インタフェース１２２に対して受信状態保持レジスタ１３７の初期化要求（Ｒ）を出力する。

再ロード（Ｌ）の指示を受けたデッドライン検出部１５１は、タイマ１５２ａ、１５２ｂに対し、制御周期の先頭を基準に、それぞれデッドライン時間Ｔｒ２、ＴＰ１受信ウィンドウＴｒ１の経過を計測するための所定のカウント値を設定し、デクリメント動作の開始を指示する。また、初期化要求（Ｒ）を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうち拡張受信マスク設定以外の保持データをすべてクリアする。これにより、第１の通信手段１０１、第２の通信手段１０２の受信完了通知が有効となる。

通常時データを正常に受信完了できないままＴＰ１受信ウィンドウＴｒ１が経過すると、タイマ１５２ｂでアンダフローが発生し、当該イベント情報がデッドライン通知インタフェース１５３を介して動作モード決定部１５０に通知される。通知を受けた動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ｂのデクリメント動作の停止を指示するとともに、受信状態制御インタフェース１２２に対してＴＰ１受信マスク設定要求（Ｍ）を出力する。ＴＰ１受信マスク設定要求（Ｍ）を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうちＴＰ１受信マスク（Ｃ１０１）の内容をセット（図４の＃１３に相当）することで、ＴＰ１受信ウィンドウ時間経過後は第２の通信手段１０２での受信完了通知のみが有効となるよう設定が更新される。

デッドライン時間Ｔｒ２までに第２の受信制御部１３３が縮退時データを正常に受信完了すると、当該情報は第２の受信状態通知インタフェース１３４により受信マスク制御部１３６に伝達される。受信マスク制御部１３６は、当該情報を反映するよう受信状態保持レジスタ１３７の内容を更新する（図４の＃１５に相当）。具体的には、ＴＰ受信状態（完了）をＮからＹに切り替える。受信マスク制御部１３６は、同時に受信状態制御インタフェース１２２に対して、受信状態通知「ＴＰ２受信完了（正常）」を出力する。ＴＰ１受信マスクはすでに設定されているため、以上で当該制御周期内の受信状態が確定する。

受信状態制御インタフェース１２２の受信状態通知を監視していた動作モード決定部１５０は、図６の動作モード決定フローに基づき第１の縮退モードへの遷移を決定し、動作モード制御インタフェース１４１を介してスケジューリング制御部１６０に当該遷移を指示（Ｃ）する。動作モード決定部１５０は同時に、偽のアンダフローイベント発生を抑止するため、デッドライン通知インタフェース１５３によりタイマ１５２ａのデクリメント動作の停止を指示する。

遷移指示（Ｃ）を受けたスケジューリング制御部１６０は、第１の縮退モード用システムソフトウェアへの実行制御インタフェース１６２により、第１の縮退モード用システムソフトウェア２３０の実行を指示する。

＜Ｃａｓｅ１−３＞
図８の右側に示すように、Ｃａｓｅ１−３は、第１の通信手段１０１はＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了できず（受信未完了、又は受信完了したが受信中にエラー検出のいずれか）、且つ第２の通信手段１０２もデッドライン時間Ｔｒ２までに縮退時データが正常に受信完了できず（受信未完了、又は受信完了したが受信中にエラー検出のいずれか）、このため、当該制御周期は第２の縮退モード用の処理である第２の縮退モード用システムソフトウェア２４０を実行する場合を示している。

動作モード決定部１５０は、動作モード制御インタフェース１４１を介して、スケジューリング制御部１６０から制御周期開始トリガ（Ｔ）を受信する。トリガ（Ｔ）を受信した動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ａ及び１５２ｂへの初期カウント値の再ロード（Ｌ）を指示し、同時に受信状態制御インタフェース１２２に対して受信状態保持レジスタ１３７の初期化要求（Ｒ）を出力する。

再ロード（Ｌ）の指示を受けたデッドライン検出部１５１は、タイマ１５２ａ、１５２ｂに対し、制御周期先頭を基準にそれぞれデッドライン時間Ｔｒ２、ＴＰ１受信ウィンドウＴｒ１の経過を計測するための所定のカウント値を設定し、デクリメント動作の開始を指示する。また、初期化要求（Ｒ）を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうち拡張受信マスク設定以外の内容をすべてクリアすることで、第１の通信手段１０１、第２の通信手段１０２での受信完了通知が有効となるよう設定する。

通常時データを正常に受信完了できないままＴＰ１受信ウィンドウＴｒ１が経過すると、タイマ１５２ｂでアンダフローが発生し、当該イベント情報がデッドライン通知インタフェース１５３を介して動作モード決定部１５０に通知される。通知を受けた動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ｂのデクリメント動作の停止を指示するとともに、受信状態制御インタフェース１２２に対してＴＰ１受信マスク設定要求（Ｍ）を出力する。ＴＰ１受信マスク設定要求（Ｍ）を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうちＴＰ１受信マスク（Ｃ１０１）の内容をセット（図４の＃１３に相当）することで、ＴＰ１受信ウィンドウＴｒ１経過後は第２の通信手段１０２での受信完了通知のみ有効となるよう設定を更新する。

更に、縮退時データを正常に受信完了できないままデッドライン時間Ｔｒ２が経過すると、タイマ１５２ａでアンダフローが発生し、当該イベント情報がデッドライン通知インタフェース１５３を介して動作モード決定部１５０に通知される。通知を受けた動作モード決定部１５０は、デッドライン通知インタフェース１５３によりタイマ１５２ａのデクリメント動作の停止を指示する。これに加え、図示しない追加の処理として、受信状態制御インタフェース１２２に対してＴＰ２受信マスク設定要求を出力してもよい。ＴＰ２受信マスク設定要求を受けた受信マスク制御部１３６は、受信状態保持レジスタ１３７のうちＴＰ２受信マスク（Ｃ２０１）の内容をセットする（図４の＃１９に相当）。デッドライン時間Ｔｒ２経過後は第１の通信手段１０１／第２の通信手段１０２のいずれの受信完了通知とも無効となるよう設定を更新してもよい。

動作モード決定部１５０は、図６の動作モード決定フローに基づき第２の縮退モードへの遷移を決定し、動作モード制御インタフェース１４１を介してスケジューリング制御部１６０に当該遷移を指示（Ｃ）する。遷移指示（Ｃ）を受けたスケジューリング制御部１６０は、第２の縮退モード用システムソフトウェアへの実行制御インタフェース１６３により、第２の縮退モード用システムソフトウェア２４０の実行を指示する。

次に、図９〜図１２のタイミングチャートを参照して、制御周期内の第１の通信手段１０１及び第２の通信手段１０２の受信完了順序と、第２のマイコン２０での実行ソフトウェアとの関係を動作レベルで説明する。

＜Ｃａｓｅ２−１＞
図９及び図１０の左側に示すＣａｓｅ２−１は、第１の通信手段１０１で第２の通信手段１０２に先行してＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の処理の一部として、通常時データの受信処理を実行する。

Ｃａｓｅ２−１では、第１の通信手段１０１だけでなく、第２の通信手段１０２もデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了している。しかし、第１の通信手段１０１の正常な受信が完了した時点でＴＰ２受信マスクが受信マスク制御部１３６により設定される。このため、第２の制御アプリケーション２２０の実行には不要な、縮退時データの受信処理が第２のマイコン２０において実行されることはない。これにより、第２のマイコン２０における負荷率が軽減される。

＜Ｃａｓｅ２−２＞
図９の中央に示すＣａｓｅ２−２は、第１の通信手段１０１はＴＰ１受信ウィンドウ内に受信完了したが受信中にエラーを検出した場合を示している。この場合、拡張受信マスク設定に基づき、第１の通信手段１０１の受信完了通知はマスクされる。

一方、第２の通信手段１０２でデッドライン時間Ｔｒ２までに縮退時データが正常に受信完了すると、第２の通信手段１０２の受信完了通知についてはマスクがされず、受信状態制御インタフェース１２２により動作モード制御部１４０に出力される。このため、当該制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の処理の一部として、縮退時データの受信処理を実行する。

このＣａｓｅ２−２では、第２の通信手段１０２の正常な受信が完了した時点でＴＰ１受信マスクが設定される。このため、当該時点以降の再送処理により第１の通信手段１０１で正常に受信が完了したとしても、第１の縮退モード用システムソフトウェア２３０の実行には不要な通常時データの受信処理は実行されない。これにより、第２のマイコン２０における負荷率が軽減される。

＜Ｃａｓｅ２−３＞
図９の右側に示すＣａｓｅ２−３は、第１の通信手段１０１は伝送路の障害によりＴＰ１受信ウィンドウＴｒ１内に受信完了せず、一方、第２の通信手段１０２ではデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の処理の一部として、縮退時データの受信処理を実行する。

このＣａｓｅ２−３では、第２の通信手段１０２の正常な受信が完了した時点でＴＰ１受信マスクが設定される。このため、当該時点以降に第１の通信手段１０１において正常に通常時データの受信が完了したとしても、第１の縮退モード用システムソフトウェア２３０の実行には不要な通常時データの受信処理が実行されることはない。

＜Ｃａｓｅ２−４＞
図１０の中央に示すＣａｓｅ２−４は、第１の通信手段１０１で、第２の通信手段１０２に先行してＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了し、一方、第２の通信手段１０２もデッドライン時間Ｔｒ２までに受信完了したが受信中にエラーを検出した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の処理の一部として、通常時データの受信処理を実行する。第２の通信手段１０２もデッドライン時間Ｔｒ２までに受信完了したが受信中にエラーを検出したため、拡張受信マスク設定に基づき受信完了通知は受信マスク制御部１３６でのマスク設定によりマスクされる。第１の通信手段１０１での正常受信完了時点でＴＰ２受信マスクが設定されるので、当該時点以降の再送処理により第２の通信手段１０２側で正常に受信完了したとしても、第２の制御アプリケーション２２０の実行には不要な、縮退時データの受信処理が実行されることはない。これにより、第２のマイコン２０における負荷率が軽減される。

＜Ｃａｓｅ２−５＞
図１０の右側に示すＣａｓｅ２−５は、第１の通信手段１０１で第２の通信手段１０２に先行してＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了し、一方、第２の通信手段１０２は伝送路の障害によりデッドライン時間Ｔｒ２までに受信完了しなかった場合を示している。この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の処理の一部として、通常時データの受信処理を実行する。

Ｃａｓｅ２−５では、第２の通信手段１０２は伝送路の障害によりデッドライン時間Ｔｒ２までに受信完了しない。第１の通信手段１０１の正常受信完了時点で、受信マスク制御部１３６によりＴＰ２受信マスクが設定される。当該時点以降に第２の通信手段１０２側で正常に受信完了したとしても、第２の制御アプリケーション２２０の実行には不要な、縮退時データの受信処理は実行されない。これにより、第２のマイコン２０における負荷率が軽減される。

＜Ｃａｓｅ３−１＞
図１１の左側に示すＣａｓｅ３−１は、第１の通信手段１０１はＴＰ１受信ウィンドウＴｒ１内に通常時データを受信完了したが受信中にエラーが検出され、第２の通信手段１０２もデッドライン時間Ｔｒ２までに縮退時データを受信完了したが受信中にエラーを検出した場合を示している。この場合、拡張受信マスク設定に基づき、第１の通信手段１０１の受信完了通知はマスクされる。

また、第２の通信手段１０２もデッドライン時間Ｔｒ２までに受信完了したが受信中にエラーを検出したため、拡張受信マスク設定に基づき、第２の通信手段１０２の受信完了通知はマスクされる。第１の通信手段１０１／第２の通信手段１０２いずれの受信完了通知が行われないままデッドライン時間Ｔｒ２が経過すると、当該制御周期における第２のマイコン２０は、デッドライン検出により第２の縮退モード用システムソフトウェア２４０を実行する。

＜Ｃａｓｅ３−２＞
図１１の右側に示すＣａｓｅ３−２は、第１の通信手段１０１側は伝送路の障害によりＴＰ１受信ウィンドウＴｒ１内に受信完了せず、第２の通信手段１０２も伝送路の障害によりデッドライン時間Ｔｒ２までに受信完了しない場合を示している。この場合、第１の通信手段１０１／第２の通信手段１０２のいずれの受信完了通知も行われないままデッドライン時間Ｔｒ２が経過する。当該制御周期における第２のマイコン２０は、デッドライン検出により第２の縮退モード用システムソフトウェア２４０を実行する。

＜Ｃａｓｅ４−１＞
図１２の左側に示すＣａｓｅ４−１は、伝送路の障害による再送が発生し受信完了タイミングが遅延したにも拘わらず、第１の通信手段１０１側で第２の通信手段１０２側に先行してＴＰ１受信ウィンドウＴｒ１内に通常時データを正常に受信完了した場合を示している。また、第２の通信手段１０２では、デッドライン時間Ｔｒ２までに縮退時データを正常に受信完了したと想定している。

この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の処理の一部として、通常時データの受信処理を実行する。第１の通信手段１０１の正常な受信完了時点でＴＰ２受信マスクが設定される。このため、第２の通信手段１０２がデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了しても、その受信完了通知はマスクされる。このため、第２の制御アプリケーション２２０の実行には不要な、縮退時データの受信処理が実行されることはない。

＜Ｃａｓｅ４−２＞
図１２の中央に示すＣａｓｅ４−２は、伝送路の障害による再送が発生し受信完了タイミングが遅延したことにより、第１の通信手段１０１はＴＰ１受信ウィンドウＴｒ１の経過以降に通常時データを正常に受信完了した場合を示している。この場合、ＴＰ１受信ウィンドウＴｒ１が経過した時点でＴＰ１受信マスクが設定されるため、通常時データの受信処理が実行されることはない。一方、第２の通信手段１０２に関してはデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了したと想定している。この場合、当該制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の処理の一部として、縮退時データの受信処理を実行する。

＜Ｃａｓｅ４−３＞
図１２の右側に示すＣａｓｅ４−３は、伝送路の障害により再送が発生し受信完了タイミングが遅延したことにより、第１の通信手段１０１はＴＰ１受信ウィンドウＴｒ１の経過以降に通常時データを正常に受信完了した場合を示している。一方、第２の通信手段１０２については、デッドライン時間Ｔｒ２までに受信完了したが、受信中にエラーが検出されたと想定している。

ＴＰ１受信ウィンドウＴｒ１が経過した時点でＴＰ１受信マスクが設定されるため、通常時データの受信処理が実行されることはない。また、第２の通信手段１０２についても、デッドライン時間Ｔｒ２までに受信完了したが、受信中にエラーを検出したため、拡張受信マスク設定に基づき、第２の通信手段１０２の受信完了通知はマスクされる。このため、第１の通信手段１０１、及び第２の通信手段１０２いずれの受信完了通知も行われないままデッドライン時間Ｔｒ２が経過する。このため、当該制御周期における第２のマイコン２０は、デッドライン検出により第２の縮退モード用システムソフトウェア２４０を実行する。

以上説明したように、第１の実施の形態の車両制御装置によれば、複数のマイコンを複数のインタフェースにより冗長接続した場合であっても、マスク付き受信部１２０により不要なデータの受信がマスク動作により遮断される。これにより、通信のリアルタイム性を保証すると共に、演算制御装置の負荷率を軽減することを可能にした車両制御装置を提供することができる。

[第２の実施の形態]
次に、図１３〜図１６を参照して、本発明の第２の実施の形態に係る車両制御装置１を説明する。第２の実施の形態の装置の構成は、第１の実施の形態と略同一であるので、重複する説明は省略する。ただし、後述するように、遅延付き送信部１００によるタイミング制御は不要であるので、遅延付き送信部１００の遅延制御が無効とされるか、または遅延付き送信部１００が通常の送信部に置換され得る。

第２の実施の形態では、複数の制御周期を跨ぐ動作モード制御方式が採用されている。図１３〜図１６は、その方式が採用される場合における第２のマイコン２０の動作を示す。第１の実施の形態で説明した制御方式とは異なり、図１３〜図１６は、１の制御周期において、第１の通信手段１０１、及び第２の通信手段１０２のうちの１つのみについて受信完了通知が有効（受信マスク無効）に設定される。動作モード決定部１５０は、１の制御周期における第１の通信手段１０１又は第２の通信手段１０２による受信の状態を判断し、その判断の結果に従い、動作モードを決定する。動作モード決定部１５０が決定した動作モードは、当該制御周期（第１の制御周期）ではなく、当該制御周期の次の制御周期（第２の制御周期）で実行される。

従って、図１３〜図１６の方式では、通常時データ及び縮退時データの受信が１つの制御周期内で完了すればよく、その後決定された動作モードは、当該周期内で完了する必要はなく、次の制御周期で実行される。また、第１の通信手段１０１と第２の通信手段１０２の間での受信完了タイミングの順序関係は不問である。このため、遅延付き送信部１００における通常時データ及び縮退時データの送信タイミング制御が不要となる。この方式は、制御周期内の各処理に対し処理時間を時系列的に割り当てるタイミング設計の難易度が低下するというメリットがある。

なお、この第２の実施の形態での制御方式においては、制御周期の先頭で設定するＴＰ１／ＴＰ２受信マスクに３つの設定パタンが存在する。制御開始時点では、通常時データのみ受信完了通知を許可する通常モード用受信完了通知マスクが設定される。これによれば、通常時データを転送する第１の通信手段１０１側の受信完了通知が有効（マスク無効）に、縮退時データを転送する第２の通信手段１０２側の受信完了通知が無効（待機状態＝マスク有効）にそれぞれ初期設定される。また、拡張受信マスク設定については常に無効（エラー検出時も完了通知は有効）とされる。

また、特に制限されないが、第２の実施形態におけるタイマ１５２は１つ（１５２ａのみ）でもよい。制御周期から以下で説明するＴＰ１／ＴＰ２受信マスク切り替えに要する時間を減じた、第１の通信手段１０１又は第２の通信手段１０２の受信処理を許可する時間をデッドライン時間Ｔｒ２とし、当該時間を計測するカウント値をタイマ１５２ａに設定することができる。

＜Ｃａｓｅ５−１＞
図１３の左側に示すＣａｓｅ５−１は、通常モード用受信完了通知マスクが設定された状態で、第１の通信手段１０１側がデッドライン時間Ｔｒ２までに通常時データを正常に受信完了し、第２の通信手段１０２側もデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の処理の一部として、通常時データの受信処理を実行する。第２の通信手段１０２側もデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了したが、ＴＰ２受信マスクが設定されているため、縮退時データの受信処理が実行されることはない。次制御周期の受信マスク設定パタンは変更せず、通常モード用受信完了通知マスク設定が維持される。

＜Ｃａｓｅ５−２＞
図１３の中央に示すＣａｓｅ５−２は、通常モード用受信完了通知マスクが設定された状態で、第１の通信手段１０１側はデッドライン時間Ｔｒ２までに受信完了したが受信中にエラーを検出した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第２の制御アプリケーション２２０の一部である第１のエラー処理として、次制御周期の受信マスク設定パタンを第１の縮退モード用受信完了通知マスクに設定する。これによれば、第１の通信手段１０１の受信完了通知が無効に変更され（閉塞＝マスク有効かつ再解除禁止）、第２の通信手段１０２の受信完了通知が有効（待機状態解除＝マスク無効）に変更される。第２の通信手段１０２は当該制御周期のデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了するが、ＴＰ２受信マスクが設定されているため、縮退時データの受信処理が実行されることはない。

＜Ｃａｓｅ５−３＞
図１３の右側に示すＣａｓｅ５−３は、Ｃａｓｅ５−２が発生して第１の縮退モード用受信完了通知マスクが設定され、第２の通信手段１０２は次の制御周期におけるデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了した場合における処理を示している。この場合、当該次の制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の処理の一部として、縮退時データの受信処理を実行する。更に次の制御周期の受信マスク設定パタンは変更せず、第１の縮退モード用受信完了通知マスク設定が維持される。

＜Ｃａｓｅ５−４＞
図１４に示すＣａｓｅ５−４は、Ｃａｓｅ５−２が発生して第１の縮退モード用受信完了通知マスクが設定され、第２の通信手段１０２側は当該制御周期においてはデッドライン時間Ｔｒ２までに受信完了したが、次の制御周期での受信中にエラーを検出した場合を示している。この場合、当該制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の一部である第２のエラー処理として、次制御周期の受信マスク設定パタンを第２の縮退モード用受信完了通知マスクに設定する。このマスクにより、第１の通信手段１０１側の受信完了通知は無効（閉塞＝マスク有効かつ再解除禁止）を維持し、第２の通信手段１０２側の受信完了通知も無効（閉塞＝マスク有効かつ再解除禁止）に変更される。このＣａｓｅ５−３、５−４の説明から明らかなように、この第２の実施の形態では、障害の深刻度に応じて縮退レベルが変更される。

＜Ｃａｓｅ５−５＞
図１４に示すＣａｓｅ５−５は、Ｃａｓｅ５−４により第２の縮退モード用受信完了通知マスクが設定された場合における次の制御周期における処理を示している。この場合、通常時データ又は縮退時データの受信完了を待たずに、第２の縮退モード用システムソフトウェア２４０が実行される。特に制限されないが、車両制御装置１全体、又は第２のマイコン２０を対象とする所定の初期化処理の一部として第１の通信手段１０１／第２の通信手段１０２の閉塞を解除することで、通常モード用受信完了通知マスクの設定状態に復帰可能としてよい。

＜Ｃａｓｅ５−６＞
図１５に示すＣａｓｅ５−６は、Ｃａｓｅ５−１が発生した後、通常モード用受信完了通知マスクが設定されたが、次の制御周期において、第１の通信手段１０１の受信完了通知が行われないままデッドライン時間Ｔｒ２が経過した場合を示している。この場合、当該制御周期における第２のマイコン２０は、デッドライン通知インタフェース１５３によるデッドライン通知を契機に、第２の制御アプリケーション２２０の一部である第１のエラー処理として、第１の通信手段１０１側の受信が未完了であることを確認し、次制御周期の受信マスク設定パタンを第１の縮退モード用受信完了通知マスクに変更する。第２の通信手段１０２はデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了したが、ＴＰ２受信マスクが設定されているため、縮退時データの受信処理が実行されることはない。

＜Ｃａｓｅ５−７＞
図１５に示すＣａｓｅ５−７は、Ｃａｓｅ５−１及びＣａｓｅ５−６が発生した後、第１の縮退モード用受信完了通知マスクが設定された状態で、第２の通信手段１０２側がデッドライン時間Ｔｒ２までに縮退時データを正常に受信完了した場合を示している。当該制御周期における第２のマイコン２０は、第１の縮退モード用システムソフトウェア２３０の処理の一部として、縮退時データの受信処理を実行する。更に次の制御周期の受信マスク設定パタンは変更せず、第１の縮退モード用受信完了通知マスク設定が維持される。

＜Ｃａｓｅ５−８＞
図１６に示すＣａｓｅ５−８は、Ｃａｓｅ５−１に続いてＣａｓｅ５−６が発生した後、第１の縮退モード用受信完了通知マスクが設定され、次の制御周期において、第２の通信手段１０２側の受信完了通知が行われないままデッドライン時間Ｔｒ２が経過した場合を示している。この場合、当該制御周期における第２のマイコン２０は、デッドライン通知インタフェース１５３によるデッドライン通知を契機に、第１の縮退モード用システムソフトウェア２３０の一部である第２のエラー処理として、第２の通信手段１０２側の受信が未完了であることを確認し、更に次の制御周期の受信マスク設定パタンを第２の縮退モード用受信完了通知マスクに変更する。このように、この第２の実施の形態では、障害の深刻度に応じて縮退レベルを適宜変更することが可能にされている。

＜Ｃａｓｅ５−９＞
Ｃａｓｅ５−８の後、図１６の右側に示すＣａｓｅ５−９が実行される。このＣａｓｅ５−９では、第２の縮退モード用受信完了通知マスクが設定されているため、通常時データ又は縮退時データの受信完了を待たずに、第２の縮退モード用システムソフトウェア２４０を実行する。特に制限されないが、車両制御装置１全体、又は第２のマイコン２０を対象とする所定の初期化処理の一部として第１の通信手段１０１／第２の通信手段１０２の閉塞を解除することで、通常モード用受信完了通知マスクの設定状態に復帰可能としてよい。

以上、本発明の実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。実施の形態中で説明された構成要素は、ハードウェアにより実現されてもよいし、ソフトウェアにより実現されてもよい。

１…車両制御装置
１０…第１のマイコン
２０…第２のマイコン
１００…遅延付き送信部
１０１…第１の通信手段（ＴＰ１）
１０２…第２の通信手段（ＴＰ２）
１１０…送信トリガ制御部
１１１…タイマ
１１２、１１３…送信トリガインタフェース
１１４…第１の送信バッファ
１１５…第１の送信データインタフェース
１１６…第２の送信バッファ
１１７…第２の送信データインタフェース
１１８…第１の送信制御部
１１９…第２の送信制御部
１２０…マスク付き受信部
１２１…受信インタフェース
１２２…受信状態制御インタフェース
１３０…第１の受信制御部
１３１…第１の受信状態通知インタフェース
１３２…第１の受信データインタフェース
１３３…第２の受信制御部
１３４…第２の受信状態通知インタフェース
１３５…第２の受信データインタフェース
１３６…受信マスク制御部
１３７…受信状態保持レジスタ
１３８…第１の受信バッファ
１３９…第２の受信バッファ
１４０…動作モード制御部
１４１…動作モード制御インタフェース
１５０…動作モード決定部
１５１…デッドライン検出部
１５２、１５２ａ、１５２ｂ…タイマ
１５３…デッドライン通知インタフェース
１６０…スケジューリング制御部
１６１〜１６３…実行制御インタフェース
２１０…第１の制御アプリケーション
２１１…送信インタフェース
２２０…第２の制御アプリケーション
２３０…第１の縮退モード用システムソフトウェア
２４０…第２の縮退モード用システムソフトウェア
９００…マイコン
９０１…イーサネットアダプタ
９０２…接続ポート
９０３…イーサネットケーブル
９１０…イーサネットスイッチ
９１１…制御テーブル
９１２…スイッチマトリクス制御インタフェース
９１３…スイッチマトリクス
９１４、９１４ａ、９１４ｂ、９１４ｃ、９１４ｄ、９１４ｅ、９１４ｆ、９１４ｇ、９１４ｈ…スイッチ接続ポート
９１５−１、９１５−２…イーサネットケーブル

Claims (8)

1. 第１の演算制御装置と第２の演算制御装置とを接続し、第１のデータを送受信する第１の通信手段と、
   前記第１の演算制御装置と前記第２の演算制御装置とを接続し、前記第１のデータとは異なる第２のデータを送受信する第２の通信手段と、
   前記第１の通信手段及び第２の通信手段に接続され、前記第１のデータ又は前記第２のデータのいずれか一方を正常に受信した際には、他方の受信動作をマスクするマスク付き受信部と
   を備えた通信制御装置。
2. 前記第１のデータが前記第２のデータに先行して前記第２の演算制御装置において受信されるよう送信タイミングを制御する遅延付き送信部を更に含む、請求項１に記載の通信制御装置。
3. 少なくとも前記マスク付き受信部の状態に基づき、前記第２の演算制御装置が遷移すべき動作モードを切り替える動作モード制御部を更に含む、請求項１又は２に記載の通信制御装置。
4. 前記動作モード制御部は、制御周期毎に前記第１の通信手段又は前記第２の通信手段による受信の状態を判断して動作モードを切り替えるよう構成された、請求項３に記載の通信制御装置。
5. 前記動作モード制御部は、制御周期毎に第１の経過時間と、前記第１の経過時間よりも長い第２の経過時間を計測するよう構成され、
   前記動作モード制御部は、前記第１の経過時間又は前記第２の経過時間の間に前記第１のデータ又は前記第２のデータの受信が完了しない場合に、前記マスク付き受信部におけるマスクの状態を切り替えるよう構成された、請求項３に記載の通信制御装置。
6. 前記動作モード制御部は、前記第１のデータ及び第２のデータのうちいずれか一方を前記第１の経過時間の間に受信できなかった場合には、動作モードを第１の縮退モードに切り替え、
   前記第１のデータ及び第２のデータのいずれも前記第２の経過時間の間に受信できなかった場合には、動作モードを前記第１の縮退モードとは異なる第２の縮退モードに切り替える、請求項５に記載の通信制御装置。
7. 前記動作モード制御部は、第１の制御周期において前記第１の通信手段又は前記第２の通信手段による受信の状態に従って動作モードを決定し、前記第１の制御周期に続く第２の制御周期において決定した動作モードを実行する、請求項３に記載の通信制御装置。
8. 前記第２のデータは、前記第１のデータのうちの一部のデータ、又は前記第１のデータの一部又は全部から所定のアルゴリズムに従って生成されたダイジェストデータである、請求項１〜７のいずれか一項に記載の通信制御装置。

Images