JP2020009288A

JP2020009288A - 演算システム、演算装置

Info

Publication number: JP2020009288A
Application number: JP2018131352A
Authority: JP
Inventors: 憲太森島; Kenta Morishima
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2018-07-11
Filing date: 2018-07-11
Publication date: 2020-01-16
Anticipated expiration: 2038-07-11
Also published as: JP7011983B2; WO2020012822A1

Abstract

【課題】所定の演算を複数の演算装置で交代で実行できる。【解決手段】演算システムは、所定の演算を交代で実行する複数の演算装置を含む演算システムであって、それぞれの演算装置は、他の演算装置との通信を行う通信部と、所定の演算を行う演算部と、演算部が所定の演算を行っている場合に所定の条件を満たすと所定の演算を停止させ、他の演算装置に所定の演算を引き継がせる委任信号を送信する実行制御部とを備え、実行制御部は、委任信号を受信すると演算部に所定の演算を開始させる。【選択図】図２

Description

本発明は、演算システム、および演算装置に関する。

自動車には車両を制御する演算装置が複数搭載されている。特許文献１には、通信経路を介して接続された複数の車載機器を備えた車両制御システムにおいて、前記複数の車載機器は、それぞれ、自己以外の他の車載機器の状態を診断し、自己が診断した他の車載機器の状態を、他の車載機器との間で交換し、自己が診断した他の車載機器の状態と、他の車載機器から取得した他の車載機器の状態とに基づいて、他の車載機器の状態を判定する車両制御システムが開示されている。

特開２００７−１２６１２７号公報

特許文献１に記載されている発明では、所定の演算を複数の演算装置で交代で実行できない。

本発明の第１の態様による演算システムは、所定の演算を交代で実行する複数の演算装置を含む演算システムであって、それぞれの前記演算装置は、他の前記演算装置との通信を行う通信部と、前記所定の演算を行う演算部と、前記演算部が前記所定の演算を行っている場合に所定の条件を満たすと前記所定の演算を停止させ、他の前記演算装置に前記所定の演算を引き継がせる委任信号を送信する実行制御部とを備え、前記実行制御部は、前記委任信号を受信すると前記演算部に前記所定の演算を開始させる。
本発明の第２の態様による演算装置は、所定の演算を交代で実行可能な演算装置であって、他の前記演算装置との通信を行う通信部と、前記所定の演算を行う演算部と、前記演算部が前記所定の演算を行っている場合に所定の条件を満たすと前記所定の演算を停止させ、他の前記演算装置に前記所定の演算を引き継がせる委任信号を送信する実行制御部とを備え、前記実行制御部は、前記委任信号を受信すると前記演算部に前記所定の演算を開始させる。

本発明によれば、所定の演算を複数の演算装置で交代で実行できる。

演算システム２０００の概要図第１ＥＣＵ１０１の構成図ＥＣＵ１００が交代で車両１０００の通信を監視する様子を示す概略図図４（ａ）は遷移表１８ｂの一例を示す図、図４（ｂ）は遷移表１８ｂを可視化した図状態監視と通信監視のローテーションを模式的に示す図第１の実施の形態における通信監視ブロック１４の動作を表すフローチャート第１の実施の形態における通信監視ブロック１４の動作を表すフローチャート第１の実施の形態における通信監視ブロック１４の動作を表すフローチャート第１の実施の形態における通信監視ブロック１４の動作を表すフローチャート第２の実施の形態における通信監視ブロック１４の動作を表すフローチャート

―第１の実施の形態―
以下、図１〜図９を参照して、演算システムの第１の実施の形態を説明する。

（全体構成）
図１は本発明に係る演算システム２０００の概要図である。演算システム２０００は、車両１０００に格納される。演算システム２０００は、ゲートウェイ２００と、第１ＥＣＵ１０１と、第２ＥＣＵ１０２と、第３ＥＣＵ１０３と、第４ＥＣＵ１０４と、第１通信バス２１と、第２通信バス２２と、通信装置１１０とを備える。以下では、第１ＥＣＵ１０１、第２ＥＣＵ１０２、第３ＥＣＵ１０３、および第４ＥＣＵ１０４を特に区別しない場合は「ＥＣＵ１００」と呼ぶ。通信装置１１０は、無線通信により通信網２０１、たとえばインターネットとの通信が可能である。なお図１ではＥＣＵは第１〜第４の４つだけであるが、車両１０００に備えられるＥＣＵの数は２以上であればよく上限はない。また車両１０００が備える通信バスは１つのみでもよいし３つ以上でもよい。

車両１０００に搭載される機器の通信方式は特に限定されず、たとえばＣＡＮ（登録商標）やＩＥＥＥ８０２．３を用いることができる。なお通信方式や通信プロトコルによってネットワーク上に送出されるデータの呼び名はフレーム、データグラム、パケットなど様々であるが、本実施の形態では「パケット」と呼ぶ。ゲートウェイ２００はいわゆるリピータとして動作し、一方のポートで受信した情報を他方のポートから送信する。すなわち、受信したパケットの宛先を見て他方の通信バスへの転送の要否を判断せずにすべて転送する。

通信装置１１０、第１ＥＣＵ１０１、およびゲートウェイ２００は第１通信バス２１に接続される。ゲートウェイ２００、第２ＥＣＵ１０２、第３ＥＣＵ１０３、および第４ＥＣＵ１０４は第２通信バス２２に接続される。通信装置１１０はＥＣＵ１００へアップデート情報を提供する役目を担っている。すなわちこれは、図１に一点鎖線で示すように、通信装置１１０を入り口として外部から侵入される可能性があることを意味している。そのため本実施の形態では外部から侵入されたことによる異変を検知する。

（ＥＣＵの構成）
図２は第１ＥＣＵ１０１の構成を示す図である。ただし第２ＥＣＵ１０２〜第４ＥＣＵ１０４も第１ＥＣＵ１０１とほぼ同一の構成を有する。第１ＥＣＵ１０１は、アプリ１２と、基本ソフト１３と、通信監視ブロック１４と、通信部１１とを備える。それぞれのＥＣＵ１００は、アプリ１２により実現される機能は異なるが、そのほかの構成は同一である。

第１ＥＣＵ１０１は、不図示のＣＰＵ、ＲＯＭ、およびＲＡＭを備え、ＲＯＭに格納するプログラムをＲＡＭに展開してＣＰＵが実行することでアプリ１２、基本ソフト１３、および通信監視ブロック１４を実現することができる。ただしハードウエア回路や書き換え可能な論理回路により実現してもよい。

アプリ１２は、第１ＥＣＵ１０１が主目的とする機能を実現するアプリケーションである。基本ソフト１３は、アプリ１２を動作させるためのオペレーティングシステムである。通信監視ブロック１４は車両１０００内の通信を他のＥＣＵと交代で監視する。通信監視ブロック１４の詳細は以下で詳細に説明する。第１ＥＣＵ１０１は、アプリ１２により本来の機能を発揮しつつ、ある時間は通信監視ブロック１４を用いて車両１０００内の通信を監視する。図３を参照して詳述する。

図３は、ＥＣＵ１００が交代で、すなわちローテーションして車両１０００の通信を監視する様子を示す概略図である。図３（ａ）〜（ｄ）は時系列順に並んでおり、図３（ｄ）の次は図３（ａ）に戻る。図３（ａ）に示すように、初めに第１ＥＣＵ１０１が通信を監視し、所定の条件を満たすと通信の監視を引き継がせるための信号である委任パケット３２を第２ＥＣＵ１０２に送信する。なお「委任パケット」は「委任信号」と呼ぶこともできる。

委任パケット３２を送信した第１ＥＣＵ１０１は通信の監視を終了する。委任パケット３２を受信した第２ＥＣＵ１０２は、図３（ｂ）に示すように通信を監視する。そして第２ＥＣＵ１０２は、所定の条件を満たすと第３ＥＣＵ１０３に委任パケット３２を送信して監視を終了する。このようにしてＥＣＵ１００は、委任パケット３２を送信して通信の監視を次々に交代する。図２に戻って説明を続ける。

通信部１１は、受信バッファ１１ａと、送信バッファ１１ｂと、不図示のコントローラとを備える。受信バッファ１１ａは、コントローラにより通信バス２０を流れるすべてのパケットが入力されるバッファである。基本ソフト１３は第１ＥＣＵ１０１が対応すべきパケットを処理し、他のパケットは無視する。ただし後述する監視部１６が動作している場合は、受信バッファ１１ａに入力されるすべてのパケットを監視部１６が監視する。なお第１ＥＣＵ１０１が対応すべきパケットとは、ＣＡＮにおいてＣＡＮ−ＩＤが特定の値のパケットや、ＩＥＥＥ８０２．３において宛先のＩＰアドレスが第１ＥＣＵ１０１であるパケットである。

送信バッファ１１ｂは、第１ＥＣＵ１０１が送信するパケットが入力されるバッファである。送信バッファ１１ｂに入力されたパケットは、コントローラにより通信バス２０の空き状況やあらかじめ定められた通信周期に応じて通信バス２０に出力される。

通信監視ブロック１４は、実行制御部１５と、監視部１６と、検証部１７と、格納部１８とを備える。なお以下では、監視部と検証部１７とをあわせて演算部３０とも呼ぶ。格納部１８には、通信を監視するＥＣＵ１００の順番を示す監視順１８ａと、車両内の通信に関する正常な状態の遷移を示す遷移表１８ｂとが格納される。なお以下では、車両内の通信に関する状態を「通信状態」と呼ぶ。すなわち遷移表１８ｂには通信状態の正常な遷移が格納される。たとえば図３に示した例に対応する監視順１８ａは、｛第１ＥＣＵ１０１、第２ＥＣＵ１０２、第３ＥＣＵ１０３、第４ＥＣＵ１０４｝である。遷移表１８ｂの具体例は後述する。

実行制御部１５は、第１ＥＣＵ１０１宛の委任パケット３２を受信すると監視部１６および検証部１７に動作を開始させる。監視部１６および検証部１７が動作している状態で所定の条件を満たすと、実行制御部１５は監視部１６および検証部１７に動作を停止させるとともに、委任パケット３２を送信する。所定の条件とは、あらかじめ定められた時間の経過、または処理負荷の増加である。この委任パケット３２の送信先は、監視順１８ａに従って決定される。なおこの委任パケット３２には、後述するように現在の通信状態も付加して送信される。詳しくは後述する。

実行制御部１５はどのＥＣＵ１００が通信を監視しているかを常に把握する。以下では、通信を監視しているＥＣＵ１００を「監視ＥＣＵ」と呼び、実行制御部１５が記録する情報であって監視ＥＣＵを示す情報を「監視ＥＣＵ情報」と呼ぶ。委任パケット３２は通信バス２０を介してすべてのＥＣＵ１００に送信されるので、他のＥＣＵ１００同士で委任パケット３２が送受信されても監視ＥＣＵを把握できる。

監視部１６は、受信バッファ１１ａに入力されるパケットの識別子、たとえばＣＡＮ−ＩＤを監視して検証部１７に出力する。検証部１７は、現在の通信状態、監視部１６が出力するパケットの識別子、および遷移表１８ｂの３つの情報を用いて通信状態が正常に遷移したか否かを判断する。

（遷移表１８ｂ）
図４（ａ）は遷移表１８ｂの一例を示す図、図４（ｂ）は遷移表１８ｂを可視化した図である。遷移表１８ｂは複数のレコードから構成され、各レコードは、通信状態と、遷移のトリガ条件と、遷移先の通信状態と、タイムアウト時間と、トリガ設定のフィールドから構成される。通信状態のフィールドには、通信状態の番号が格納される。トリガ条件のフィールドには、次の通信状態に遷移する条件が格納される。遷移先の通信状態のフィールドには、トリガ条件を満たした場合に遷移する通信状態の番号が格納される。タイムアウトのフィールドにはその状態に遷移してからタイムアウトになるまでの時間が格納される。ただしタイムアウトがない場合には「なし」が格納される。

たとえば図４（ａ）の１行目の例は、通信状態１においてＣＡＮ−ＩＤが６のパケットを検知すると通信状態を２に遷移させることを示している。また図４（ａ）の２行目の例は、通信状態２においてＣＡＮ−ＩＤが７のパケットを検知すると通信状態を３に遷移させ、通信状態２に遷移してから１ｍｓ以内にＣＡＮ−ＩＤが７のパケットを検知しないとタイムアウトになることを示している。タイムアウトになると、後述する異常状態に遷移する。

図４（ｂ）は、図４（ａ）では省略されている記載を補って作成した、遷移表１８ｂの可視化図である。図４（ｂ）に示す丸囲みの数字は通信状態を示し、通信状態同士を接続する矢印近傍の数字はトリガ条件となるＣＡＮ−ＩＤを示す。図４（ｂ）を参照しながら検証部１７の動作の一部を説明する。図４（ｂ）によれば、通信状態１からの正常な遷移先は通信状態２のみなので、通信状態１においてＣＡＮ−ＩＤが６以外のパケットを受信すると検証部１７は異常状態に遷移させる。通信状態２では、ＣＡＮ−ＩＤが７、１１、１３以外のパケットを受信すると検証部１７は異常状態に遷移させる。また検証部１７は、通信状態３においてＣＡＮ−ＩＤが８のパケットを受信すると、通信状態３のままとする。

（監視の模式図）
図５は、状態監視と通信監視のローテーションを模式的に示す図である。図５の上部には第１ＥＣＵ１０１が通信を監視している様子を示しており、図５の下部には第２ＥＣＵ１０２が通信を監視している様子を示している。符号３１に示す枠内は、通信状態の遷移を模式的に示しており、アンダーバーが付されている数字は現在の通信状態であることを示している。なお図５に示す通信状態の模式図は作図の都合により図４とは異なっている。

第１ＥＣＵ１０１は通信状態１から監視を開始し、何度かパケットを受信して状態遷移を繰り返し、図５の右上に示すように通信状態３となった。そして所定の条件を満たしたので、次に通信を監視する第２ＥＣＵ１０２に委任パケット３２を送信する。この委任パケット３２には、現在の通信状態が「通信状態３」であることを示す情報も含まれる。この委任パケット３２を受信した第２ＥＣＵ１０２は、委任パケット３２に含まれる情報にしたがい現在の通信状態が「通信状態３」であるとして通信の監視を開始する。第２ＥＣＵ１０２はパケットを受信して通信状態を遷移させ、通信状態が「通信状態５」になったところで所定の条件を満たした。そのため次の第３ＥＣＵ１０３には、現在の通信状態が「通信状態５」であることを示す情報を含む委任パケット３２を送信する。

（フローチャート）
図６〜図９は、通信監視ブロック１４の動作を表すフローチャートである。なお図６〜図８の説明では、以下に説明する動作を行うＥＣＵ１００を「当該ＥＣＵ」や「自分」と呼ぶ。ＥＣＵ１００の実行制御部１５は起動すると図６に示す動作を開始する。

実行制御部１５はまず監視順１８ａを読み込み（Ｓ１０２）、当該ＥＣＵが最初の順番であるか否かを判断する（Ｓ１０３）。たとえば上述した監視順１８ａの例であれば、第１ＥＣＵ１０１のみＳ１０３を肯定判断してＳ１０４に進み、他のＥＣＵはＳ１０３を否定判断してＳ１０５に進む。Ｓ１０４では実行制御部１５は当該ＥＣＵ自身に委任パケット３２を送信してＳ１０５に進む。この委任パケット３２には現在の通信状態が「通信状態１」である旨の情報が含まれる。

Ｓ１０５では実行制御部１５は何らかのパケットを受信するまで待機し、パケットを受信するとＳ１０７に進む。なおＳ１０４からＳ１０５に進んだ場合は即座にＳ１０７に進む。Ｓ１０７では実行制御部１５は、通信を監視中か否かを判断し監視中であると判断する場合は図７の丸囲み２に進み、監視中ではないと判断する場合はＳ１０８に進む。Ｓ１０８では実行制御部１５は、受信したパケットが委任パケット３２であるか否かを判断し、委任パケット３２を受信したと判断する場合は図７の丸囲み３に進み、委任パケット３２以外のパケットを受信したと判断する場合は図８の丸囲み４に進む。

図７は図６のＳ１０７またはＳ１０８において肯定判断された場合の処理を示す図である。Ｓ１１８は実行制御部１５は、図６のＳ１０８において肯定判断されると丸囲み３を経由して実行される。Ｓ１１８では受信した委任パケット３２が当該ＥＣＵ宛であるか否かを判断する。委任パケット３２の宛先は、パケットの識別子であるＣＡＮ−ＩＤや宛先を示すＩＰアドレスで判断してもよいしペイロードに含まれる情報から判断してもよい。実行制御部１５は自分宛と判断する場合はＳ１２０に進み、自分宛でないと判断する場合はＳ１１９に進む。Ｓ１１９では実行制御部１５は、監視ＥＣＵ情報を更新し、丸囲み１に進む。

Ｓ１２０では実行制御部１５は、監視開始時の処理である通信状態の設定とタイマーのセットを行いＳ１２１に進む。通信状態の設定とは、委任パケット３２に含まれる情報であり現在の通信状態、たとえば図４（ｂ）に示す１〜４のいずれの状態なのか、を読み込むことである。タイマーのセットとは、通信の監視をあらかじめ定めた長さの時間である監視時間、たとえば１０秒の経過で交代するために計時を開始することである。

Ｓ１２１は、Ｓ１２０の次に、または図６のＳ１０７で肯定判断されて丸囲み２を経由して実行される。Ｓ１２１では実行制御部１５は、後述するように監視時の処理を行いＳ１２２に進む。Ｓ１２２では実行制御部１５は、監視時間が終了したか否か、すなわちＳ１２０において開始した計時が所定の時間に達したか否かを判断する。実行制御部１５はＳ１２２を肯定判断するとＳ１２４に進み、Ｓ１２２を否定判断するとＳ１２３に進む。Ｓ１２４では実行制御部１５は監視順１８ａを参照して次に監視を担当するＥＣＵ１００を特定し、特定したＥＣＵ１００に委任パケット３２を作成して送信する。ただしこの委任パケット３２には、現在の通信状態を示す情報も含まれる。そして実行制御部１５は、Ｓ１２４の次に丸囲み１に進む。

Ｓ１２３では実行制御部１５は、当該ＥＣＵ１００の現在の処理負荷が所定値よりも大きいか否かを判断し、所定値よりも大きいと判断するとＳ１２４に進み、所定値以下と判断すると丸囲み１に進む。すなわち実行制御部１５は、通信の監視を開始して所定の時間が経過するか、処理負荷が所定値より大きくなると、委任パケット３２を送信して次のＥＣＵ１００に通信を監視させる。

図８は、図６のＳ１０８において否定判断された場合に、丸囲み４を経由して実行される処理を示す図である。丸囲み４の次に実行されるＳ１０９では実行制御部１５は、直前に委任パケット３２を送信してから第１規定時間以上が経過したか否かを判断する。ただし第１規定時間とは、あらかじめ決められた長さの時間である。実行制御部１５はＳ１０９を肯定判断する場合はＳ１１０に進み、Ｓ１０９を否定判断する場合は丸囲み１に進む。

Ｓ１１０では実行制御部１５は、現在、通信を監視している監視ＥＣＵが監視順１８ａにおける自分の直前であるか否かを判断する。実行制御部１５は監視ＥＣＵが自分の直前であると判断する場合はＳ１１５に進み、監視ＥＣＵが自分の直前ではないと判断する場合はＳ１１２に進む。Ｓ１１２では実行制御部１５は、直前に委任パケット３２を送信してから第２規定時間以上が経過したか否かを判断する。ただし第２規定時間とは、あらかじめ決められた長さの時間であり、第１規定時間と同一であっても異なっていてもよい。実行制御部１５はＳ１１２を肯定判断する場合はＳ１１３に進み、Ｓ１１２を否定判断する場合は丸囲み１に進む。

Ｓ１１３では実行制御部１５は、長時間にわたって委任パケット３２が検知されないことを理由にアラートを出力し、続くＳ１１４では自分宛に委任パケット３２を送信して丸囲み１に進む。Ｓ１１５では実行制御部１５は、監視ＥＣＵの失陥を検出したか否かを判断する。なお通信バス２０に接続されたＥＣＵ１００の失陥を検出する機能は、それぞれＥＣＵ１００が備えてもよいし、通信バス２０に接続された危機が失陥を検出してそれぞれのＥＣＵ１００に伝達してもよい。実行制御部１５はＳ１１５を肯定判断する場合はＳ１１７に進み、Ｓ１１５を否定判断する場合はＳ１１６に進む。

Ｓ１１６では実行制御部１５は、アラートを出力してＳ１１７に進む。なおＳ１１５において否定判断された場合のみアラートを出力するのは、失陥が検出された場合には通信の監視以外の保護機構により対処されることを想定しているためである。Ｓ１１７では自分宛に委任パケットを送信して丸囲み１に進む。

図９は図７のＳ１２１の詳細を示すフローチャートである。図９に示す処理は実行制御部１５から動作を指示された検証部１７が実行する。検証部１７はまずＳ１３０において、受信したパケットに基づき通信状態を更新する。続くＳ１３１では検証部１７は、不正を検知したか否か、すなわちＳ１３０において異常状態に遷移したか否かを判断する。検証部１７は異常状態に検知したと判断するとＳ１３２に進んでアラートを出力してＳ１３３に進み、異常状態に遷移していないと判断するとＳ１３３に進む。Ｓ１３３ではＳ１３０において遷移させた通信状態を実行制御部１５に通知して図９に示す処理を終了する。

上述した第１の実施の形態によれば、次の作用効果が得られる。
（１）演算システム２０００は、通信の監視を交代で実行する複数のＥＣＵ１００を含む。ＥＣＵ１００は、他のＥＣＵ１００との通信を行う通信部１１と、所定の演算を行う演算部３０と、演算部３０が所定の演算を行っている場合に所定の条件を満たすと所定の演算を停止させ、他のＥＣＵ１００に所定の演算を引き継がせる委任パケット３２を送信する実行制御部１５とを備える。実行制御部１５は、委任パケット３２を受信すると演算部３０に所定の演算を開始させる。そのため演算システム２０００は、所定の演算を複数の演算装置１００で交代で実行できる。

（２）演算部３０は、ＥＣＵ１００同士の通信を受信する監視部１６と、正常な通信の順番を示す遷移表１８ｂを格納する格納部１８と、監視部１６が受信する通信の順番と遷移表１８ｂとを照合する検証部１７とを備える。そのため演算部３０は、演算システム２０００の通信を監視できる。

（３）ＥＣＵ１００が通信の監視を交代する条件の１つは、通信の監視を開始してからの所定時間、すなわち監視時間の経過である。そのため特定のＥＣＵ１００に演算の負荷が偏ることを防止できる。

（４）ＥＣＵ１００が通信の監視を交代する条件の１つは、当該ＥＣＵの現在の処理負荷が所定の閾値より高いことである。そのためアプリ１２の処理負荷が高い場合は通信の監視を次のＥＣＵ１００に委任し、通信を監視することがＥＣＵ１００の本来の動作へ与える悪影響を軽減できる。

（５）実行制御部１５は、演算部３０が所定の演算を終了してから第１の期間、すなわち図８のＳ１０９における第１規定時間、またはＳ１１２における第２規定時間が経過することを条件の１つとして、委任パケット３２を受信しなくても演算部３０に所定の演算を実行させる。他のＥＣＵ１００に障害が発生し、委任パケット３２を送信してもらえない場合にも、当該ＥＣＵが通信を監視できる。

（６）委任パケット３２には監視の経過情報、すなわち現在の通信状態が含まれる。そのため図５に示すように通信を監視るＥＣＵ１００が交代しても、通信状態の情報を引き継いで監視ができる。

（変形例１）
上述した第１の実施の形態では、委任パケット３２には監視ＥＣＵ情報が含まれたがタイムアウト残り時間は含まれなかった。しかしＥＣＵ１００はタイムアウトの残り時間も併せて送信してもよい。たとえばある通信状態のタイムアウトを時間が１０ｍｓであり、その通信状態に遷移してから４ｍｓ経過後に委任パケット３２を出力する場合には、委任パケット３２には通信状態と、４ｍｓがすでに経過している旨の情報を含める。この委任パケット３２を受信したＥＣＵ１００は、６ｍｓ以内にパケットを受信しない場合はタイムアウトと判断する。この変形例１によれば、監視ＥＣＵが変更されてもタイムアウトを正確に評価できる。

（変形例２）
いずれかのＥＣＵ１００がローテーションの順番を変更する機能を有する親機となってもよい。親機は、一定時間の経過や進入の検知などを契機としてローテーションの順番を変更し、変更後のローテーションの順番を委任パケット３２に含めて送信する。この委任パケット３２を受信したＥＣＵ１００は、格納部１８に格納された監視順１８ａを委任パケット３２に含まれるローテーションの順番で上書きする。さらにこの委任パケット３２を受信したＥＣＵ１００は、自身が送信する委任パケット３２に、受信済の情報である、変更後のローテーションの順番を含める。

なお、たとえば以下のような構成により親機がなくてもローテーションの順番を変更できる。すなわち、ＥＣＵ１００に複数の監視順１８ａがあらかじめ格納され、時間の経過などの条件によりそれぞれのＥＣＵ１００が各自の判断により参照する監視順１８ａを変更することでローテーションの順番を変更してもよい。

この変形例２によれば、第１の実施の形態の作用効果に加えて、次の作用効果が得られる。
（７）ＥＣＵ１００が通信を監視する順序は一定ではない。そのためローテーションの順番を変更して、安全性を向上できる。

（変形例３）
図７のＳ１２３において処理負荷が所定値より大きい場合には、即座に委任パケット３２を作成して次のＥＣＵ１００に通信の監視を委任した。しかし処理負荷の大きさに応じて監視時間を短くしてもよい。たとえば処理負荷の閾値を３段階設けて、最も低い閾値を超える場合には当該ＥＣＵがネットワークを監視する時間を３０％短くし、次の閾値を超える場合には６０％短くし、最も大きい閾値を超える場合に即座に監視を終了してもよい。

（変形例４）
ＥＣＵ１００は、委任パケット３２を受信すると通信の監視を開始した。しかし、委任パケット３２を受信した際に処理負荷があらかじめ定められた閾値よりも大きい場合は、受信した委任パケット３２を無視してもよい。たとえばＳ１１８において肯定判断された場合に処理負荷があらかじめ定められた閾値よりも大きいと判断すると、Ｓ１２０に進まずに丸囲み１に進む。この変形例４によれば、ＥＣＵ１００の本来の処理に集中させることができる。

（変形例５）
第１の実施の形態では、ＥＣＵ１００は交代で通信の監視を行った。しかし交代で行う処理は通信の監視に限定されない。たとえば車両１０００の走行に必要な機能や付加的な機能を実現するための演算を交代で実行してもよい。車両１０００の走行に必要な機能とはたとえば、エンジンの最適な点火時期の演算である。付加的な機能とはたとえば、車両１０００が備えるセンサが取得したデータを処理して障害物を検出する演算である。

（変形例６）
ＥＣＵ１００は、監視順１８ａにおける２つ先のＥＣＵ１００に対して委任パケット３２を送信してもよい。この場合にＥＣＵ１００は次の動作を行う。ＥＣＵ１００は、自身が委任パケット３２を送信すると監視順１８ａにおける次のＥＣＵ１００の委任パケット３２の送信を監視する。そして自身が委任パケット３２を送信してから所定時間以内に委任パケット３２の送信が確認できない場合は、２つ先のＥＣＵ１００に対して委任パケット３２を送信する。なお監視順１８ａにおける当該ＥＣＵの次の順番のＥＣＵ１００を「次装置」とも呼び、さらに次のＥＣＵ１００を「次々装置」とも呼ぶ。

たとえば監視順１８ａが第１の実施の形態と同様に、第１ＥＣＵ１０１、第２ＥＣＵ１０２、第３ＥＣＵ１０３、第４ＥＣＵ１０４の順番の場合に、第１ＥＣＵ１０１を主体とした具体的な動作は次のとおりである。第１ＥＣＵ１０１は、第２ＥＣＵ１０２に委任パケット３２を送信すると、第２ＥＣＵ１０２による委任パケット３２の送信を監視する。そして第１ＥＣＵ１０１が第２ＥＣＵ１０２に委任パケット３２を送信してから所定時間以内に第２ＥＣＵ１０２が第３ＥＣＵ１０３に対して委任パケット３２を送信していないと判断すると、第１ＥＣＵ１０１は次々装置である第３ＥＣＵ１０３に委任パケット３２を送信する。

この変形例６によれば、第１の実施の形態の作用効果に加えて、次の作用効果が得られる。
（８）格納部１８には監視順１８ａが格納される。実行制御部１５は、次装置および次々装置を、監視順１８ａを参照して特定する。実行制御部１５は、次装置に委任パケット３２を送信してから第２の所定時間が経過するまでに次装置から次々装置への委任パケット３２を検出しない場合は、次々装置へ委任パケット３２を出力する。

（変形例７）
図７のＳ１２３では実行制御部１５は、当該ＥＣＵ１００の現在の処理負荷が所定値よりも大きいか否かを判断した。しかし実行制御部１５は、近い将来、たとえば１０ｍｓ後や１００ｍｓ後の当該ＥＣＵ１００の処理負荷を予測して、予測した処理負荷が所定値よりも大きいか否かを判断してもよい。本変形例によれば、通信を監視することによる本来の処理、すなわちアプリ１２の処理に与える悪影響を低減できる。なおＥＣＵ１００の処理は周期的なものが多いので処理負荷の予測が容易である。

―第２の実施の形態―
図１０を参照して、演算システムの第２の実施の形態を説明する。以下の説明では、第１の実施の形態と同じ構成要素には同じ符号を付して相違点を主に説明する。特に説明しない点については、第１の実施の形態と同じである。本実施の形態では、主に、短い時間間隔で委任パケットを受信すると処理負荷が大きくても監視を終了しない点で、第１の実施の形態と異なる。

（第２の実施の形態の概要）
上述した第１の実施の形態では、通信を監視しているＥＣＵ１００の処理負荷が大きくなると、監視時間が終了する前であっても通信の監視を終了していた（図７のＳ１２２：ＮＯ、Ｓ１２３：ＹＥＳ、Ｓ１２４）。そのため、全てのＥＣＵ１００の処理負荷が高い場合には、委任パケット３２を受信したＥＣＵ１００がすぐに次のＥＣＵ１００に委任パケット３２を送信し、監視ＥＣＵが次々に変更される。この場合は監視ＥＣＵの変更ばかりが行われて通信が監視されないので好ましくない。

そのため本実施の形態では、ＥＣＵ１００は短時間で再び委任パケット３２を受信すると、ＥＣＵ１００が全体的に処理負荷が高いことを示すフラグ（以下、「継続フラグ」）をオンに設定する。そして継続フラグがオンの場合は処理負荷が所定の閾値よりも高くても監視時間が終了するまでは通信の監視を継続する。なお第１の実施の形態ではすべてのＥＣＵ１００が同様の動作を行ったが、本実施の形態では一部のＥＣＵ１００は第１の実施の形態と同様の動作を行ってもよい。

（構成）
車両１０００の構成およびＥＣＵ１００の機能構成は以下の点を除いて第１の実施の形態と同様である。すなわち少なくとも一部のＥＣＵ１００の動作が以下に説明するように異なる。これはたとえば不図示のＲＯＭに格納されるプログラムが異なる、ハードウエア回路が異なる、または論理回路に書き込まれる回路が異なることを意味している。

（フローチャート）
図１０は、第２の実施の形態における通信監視ブロック１４の動作を表すフローチャートである。ただし図１０は第１の実施の形態における図７の代わりに実行されるフローチャートである。すなわち第２の実施の形態における通信監視ブロック１４は、図６、図８〜図１０に示される動作を行う。図７と図１０の相違点は、Ｓ１１８において肯定判断された場合にＳ１４２〜Ｓ１４４を実行した後にＳ１２０に遷移する点、およびＳ１２３において肯定判断された場合にＳ１４９を実行する点である。なおＳ１２４のあとにＳ１５１およびＳ１５３が追加されているが、これらはなくてもよい。以下では追加された各ステップを説明する。

Ｓ１１８において肯定判断されると実行されるＳ１４２では、実行制御部１５は前回Ｓ１２４を実行してからＳ１４２を実行するまでの時間間隔が所定の閾値よりも短いか否かを判断する。この閾値はたとえば、あらかじめ定められた時間の長さである監視時間、通信バス２０に接続されるＥＣＵ１００の台数、および所定の係数であるたとえば０．１の３つの積である。実行制御部１５は、Ｓ１４２を肯定判断する場合はＳ１４４に進んで継続フラグをオンに設定し、否定判断する場合はＳ１４３に進んで継続フラグをオフに設定する。Ｓ１４３またはＳ１４４を実行すると、実行制御部１５はＳ１２０に進む。Ｓ１２０の処理は第１の実施の形態と同様なので説明を省略する。

Ｓ１２３を肯定判断されると実行されるＳ１４９では実行制御部１５は、継続フラグがオンであるか否かを判断する。実行制御部１５は、オンであると判断する場合は委任パケット３２を作成することなく丸囲み１に進み、継続フラグがオフであると判断する場合はＳ１２４に進む。すなわち本実施の形態では、継続フラグがオンの場合には監視時間が終了しなければＳ１２４には進まない。

実行制御部１５は、第１の実施の形態と同様にＳ１２４を実行し、次にＳ１５１に進む。Ｓ１５１では実行制御部１５は、継続フラグがオンであるか否かを判断し、継続フラグがオンの場合にはＳ１５３に進んで継続フラグをオフｚに設定する。実行制御部１５は、継続フラグがオフであると判断する場合はそのまま丸囲み１に進む。

上述した各実施の形態および変形例は、それぞれ組み合わせてもよい。上記では、種々の実施の形態および変形例を説明したが、本発明はこれらの内容に限定されるものではない。本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

１１…通信部
１４…通信監視ブロック
１５…実行制御部
１６…監視部
１７…検証部
１８…格納部
３０…演算部
３２…委任パケット
１００…ＥＣＵ
１０００…車両
２０００…演算システム

Claims

所定の演算を交代で実行する複数の演算装置を含む演算システムであって、
それぞれの前記演算装置は、
他の前記演算装置との通信を行う通信部と、
前記所定の演算を行う演算部と、
前記演算部が前記所定の演算を行っている場合に所定の条件を満たすと前記所定の演算を停止させ、他の前記演算装置に前記所定の演算を引き継がせる委任信号を送信する実行制御部とを備え、
前記実行制御部は、前記委任信号を受信すると前記演算部に前記所定の演算を開始させる演算システム。
請求項１に記載の演算システムにおいて、
前記演算部は、
前記演算装置同士の通信を受信する監視部と、
正常な前記通信の順番を示す順番情報を格納する記憶部と、
前記監視部が受信する通信の順番と、前記順番情報とを照合する検証部とを備える演算システム。
請求項１に記載の演算システムにおいて、
前記所定の条件とは、前記所定の演算を開始してからの所定時間の経過である演算システム。
請求項１に記載の演算システムにおいて、
前記所定の条件とは、前記演算部の現在または将来の処理負荷が所定の閾値より高いことである演算システム。
請求項１に記載の演算システムにおいて、
前記実行制御部は、前記演算部が前記所定の演算を終了してから第１の期間が経過すると、前記委任信号を受信しなくても前記演算部に前記所定の演算を実行させる演算システム。
請求項２に記載の演算システムにおいて、
前記記憶部には前記所定の処理を実行する前記演算装置の順番を示す順番情報がさらに格納され、
前記実行制御部は、当該演算装置の次に前記所定の処理を実行する次装置、および前記次装置の次に前記所定の処理を実行する次々装置を、前記順番情報を参照して決定し、
前記実行制御部は、前記次装置に前記委任信号を送信してから第２の所定時間が経過するまでに前記次装置から前記次々装置への委任信号を検出しない場合は、前記次々装置へ委任信号を出力する演算システム。
請求項１に記載の演算システムにおいて、
前記委任信号には前記所定の演算の経過情報が含まれる演算システム。
請求項１に記載の演算システムにおいて、
前記複数の演算装置が前記所定の演算を実行する順序は一定ではない演算システム。
所定の演算を交代で実行可能な演算装置であって、
他の前記演算装置との通信を行う通信部と、
前記所定の演算を行う演算部と、
前記演算部が前記所定の演算を行っている場合に所定の条件を満たすと前記所定の演算を停止させ、他の前記演算装置に前記所定の演算を引き継がせる委任信号を送信する実行制御部とを備え、
前記実行制御部は、前記委任信号を受信すると前記演算部に前記所定の演算を開始させる演算装置。