JP2020042577A - 車両用システム - Google Patents

Abstract

【課題】処理遅延が発生する可能性がある場合でも、車両を適切に制御する。【解決手段】車両用システム（１００）は、複数の制御装置を用いて処理を実行する。車両用システムは、前記複数の制御装置に含まれる第１の制御装置の処理が完了した時点での処理時間を取得する取得手段と、前記取得した処理時間に基づいて、前記第１の制御装置よりも後段で処理を実行する第２の制御装置において処理遅延が発生する可能性があるか否かを判定する判定手段と、前記第２の制御装置において処理遅延が発生する可能性があると判定された場合に、所定の制御を実行する実行手段とを備える。【選択図】図１

Description

本発明は、車両において各種処理を実行する車両用システムの技術分野に関する。

実行すべき処理（タスク）を複数の制御装置を用いて並列的に実行するシステムが知られている。例えば特許文献１では、ネットワークで接続された複数の制御装置でタスクの分散処理が可能なシステムが開示されている。このシステムでは、タスクを実行しようとする場合に、各制御装置においてデッドライン（即ち、タスクの実行終了までの要求時間）を満たすか否かを判断し、デッドラインを満たす制御装置にタスクを割り当てることで、処理遅延の低減が図られている。

その他、処理遅延に関連する技術として、特許文献２では、基準処理時間と予め設定した遅れ基準値とを比較して、遅れ基準値以上であればカウント、遅れ基準値未満であればクリアを実行して、記録した値が予め設定した連続設定数以上になった場合に異常が発生していると判断する装置が開示されている。特許文献３では、システムの処理構成が確立した時点で各タスクの処理時間を積算して、算出された処理時間があるレベルを超えると異常が発生していると判断する装置が開示されている。

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

しかしながら、上述した特許文献１に記載されている技術では、デッドラインを満たす制御装置が存在しなかった場合に、タスクが放棄される、又はデッドラインを満たさない制御装置においてタスクが実行されることになる。すると、処理遅延が発生してしまう可能性が高くなるという技術的問題点が生ずる。このような処理遅延が車両（例えば、自動運転システム等）において発生すると、車両の搭乗者が危険な状況に陥る可能性もある。しかしながら、先行技術文献においては、このようなケースは全く想定されておらず、十分に改善の余地がある。

本発明は、例えば上記問題点に鑑みてなされたものであり、処理遅延が発生する可能性がある場合でも、車両を適切に制御することが可能な車両用システムを提供することを課題とする。

本発明に係る車両用システムの一態様では、複数の制御装置を用いて処理を実行する車両用システムであって、前記複数の制御装置に含まれる第１の制御装置の処理が完了した時点での処理時間を取得する取得手段と、前記取得した処理時間に基づいて、前記第１の制御装置よりも後段で処理を実行する第２の制御装置において処理遅延が発生する可能性があるか否かを判定する判定手段と、前記第２の制御装置において処理遅延が発生する可能性があると判定された場合に、所定の制御を実行する実行手段とを備える。

本実施形態に係る車両用システムの展開例を示すデータフローグラフである。 本実施形態に係る車両用システムの各ノードの通常動作の流れを示すフローチャートである。 本実施形態に係る車両用システムによる処理遅延判定動作の流れを示すフローチャートである。 判定ノードの処理中に実行される処理時間チェック動作の流れを示すフローチャートである。 本実施形態に係る車両用システムによる安全制御動作の流れを示すフローチャートである。 自動運転システムのノード構成例を示すデータフローグラフである。 自動運転システムの判定ノードにおける処理遅延判定動作の流れを示すフローチャートである。

以下、図面を参照して車両用システムの実施形態について説明する。

＜システム構成＞
まず、本実施形態に係る車両用システムの構成について、図１を参照して説明する。図１は、本実施形態に係る車両用システムの展開例を示すデータフローグラフである。

図１に示すように、本実施形態に係る車両用システム１００は、複数のノード（Ａ〜Ｑ）によって構成されている。なお、ここでのノードは、例えば制御装置、処理装置、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、又はＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）等に言い換えることができる。各ノードは、車両における各種処理をそれぞれ実行可能に構成されている。

複数のノードには、重要ノード及び判定ノードが含まれている。重要ノードは、複数のノードの中でも重要度の高い処理（遅延が発生するとその後の各処理に大きな影響が出てしまう処理等）を実行するノードであり、具体的には、多数のノードに処理結果を出力するノード（例えば、ノードＣ及びノードＧ）や、車両の挙動に直結するデータを出力するノード（例えば、ノードＱ）が一例として挙げられる。判定ノードは、重要ノードにおける処理遅延を事前に判定するためのノードであり、重要ノードよりも前に処理を実行するノードが判定ノードとして設定される。具体的には、ノードＣ及びノードＧのように、出力が多数のノードに使用されるため、処理遅延がシステム全体へ大きな影響を与えてしまうような重要ノードについては、直前のノードＢ及びノードＤが判定ノードとして設定される。一方、ノードＱのように、車両の挙動に大きく影響するデータを出力する重要ノードについては、より早い段階で判定が行えるようにノードＪが判定ノードとして設定される。

＜各ノードの通常動作＞
次に、本実施形態に係る車両用システム１００の各ノードにおける通常動作の流れについて、図２を参照して説明する。図２は、本実施形態に係る車両用システムの各ノードの通常動作の流れを示すフローチャートである。

図２に示すように、本実施形態に係る車両用システムの１００のノードは、まず処理を実行するために用いるデータを受信する（ステップＳ１１）。続いて、ノードは、受信したデータを利用した処理を開始する（ステップＳ１２）。なお、具体的な処理の内容はノード毎に異なる。ノードは、処理を実行し（ステップＳ１３）、処理が終了すると（ステップＳ１４）、処理結果として得られたデータを次のノードに送信する（ステップＳ１５）。

続いて、ノードは、実行すべきすべての処理が終了したか否かを判定する（ステップＳ１６）。そして、すべての処理が終了したと判定された場合（ステップＳ１６：ＹＥＳ）、一連の処理が終了する。一方で、すべての処理が終了していないと判定された場合（ステップＳ１６：ＮＯ）、再びＳ１１からの処理を実行する。このように、本実施形態に係る車両用システムの１００の各ノードでは、ステップＳ１１からステップＳ１５までの処理が繰り返し実行される。

＜処理遅延判定動作＞
次に、本実施形態に係る車両用システム１００による処理遅延判定動作（即ち、重要ノードにおいて処理遅延が発生する可能性があるか否かを判定する動作）について、図３を参照して説明する。図３は、本実施形態に係る車両用システムによる処理遅延判定動作の流れを示すフローチャートである。なお、処理遅延判定動作は、判定ノードにおいて上述したノードの通常動作と並行して実行される処理である。

図３に示すように、処理遅延判定動作には、まずノードによる処理（即ち、通常動作）が開始されたか否かを判定する（ステップＳ２１）。具体的には、図２のステップＳ１２の段階となったか否かを判定する。なお、ノードによる処理が開始されていないと判定された場合（ステップＳ２１：ＮＯ）、以降の処理は省略され一連の処理が終了する。この場合、所定期間後に再びステップＳ２１の処理が実行されてもよい。

ノードによる処理が開始されたと判定された場合（ステップＳ２１：ＹＥＳ）、ノードは、チェック処理を開始する（ステップＳ２２）。ノードは、チェック処理を実行することで（ステップＳ２３）、自身が実行している処理において時間超過が発生しているか否かを判定する（チェック処理については、後に詳述する）。チェック処理中には、ノードによる処理（即ち、通常動作）が終了したか否かを判定する（ステップＳ２４）。具体的には、図２のステップＳ１４の段階になったか否かを判定する。処理が終了していないと判定された場合には（ステップＳ２４：ＮＯ）、チェック処理を続行する。

ノードによる処理が終了したと判定された場合（ステップＳ２４：ＹＥＳ）、チェック処理を終了する（ステップＳ２５）。なお、ノードはチェック処理を終了した際に、処理が終了した時点での処理時間を取得する。ここで取得される処理時間は、ノードが処理（即ち、通常動作）を開始してから、その処理が終了するまでの時間である。或いは、取得される処理時間は、システム全体で処理が開始されてから、そのノードでの処理が終了するまでの時間であってもよい。

ノードは、取得した処理時間に基づいて、後段の重要ノードにおいて処理遅延が発生する可能性があるか否かを判定する（ステップＳ２６）。なお、処理遅延が発生する可能性を判定する方法については、既存の技術を適宜採用することができるが、例えば、取得された実際の処理時間と、予め設定された基準となる処理時間とを比較することで判定してもよい。重要ノードにおいて処理遅延が発生する可能性がないと判定された場合（ステップＳ２６：ＮＯ）、以降の処理は省略され一連の処理が終了する。この場合、所定期間後に再びステップＳ２１の処理が実行されてもよい。

重要ノードにおいて処理遅延が発生する可能性があると判定された場合（ステップＳ２６：ＹＥＳ）、ノードは、所定の安全制御を実行させる。具体的には、安全制御を実行するノードに対して、安全制御を実行するための要求を送信する。安全制御は、重要ノードで処理遅延が発生した場合を想定して、車両を安全な状態に維持するために実行される制御である。安全制御の具体的な内容については、後に詳述する。

＜処理時間チェック動作＞
次に、判定ノードの処理中に実行される処理時間チェック（即ち、図３のステップＳ２３の処理）について、図４を参照して説明する。図４は、判定ノードの処理中に実行される処理時間チェック動作の流れを示すフローチャートである。

図４に示すように、判定ノードにおけるチェック処理では、まずノードにおける処理時間（即ち、ノードで通常動作が開始されてからの時間）をカウントする（ステップＳ３１）。続いて、カウントした処理時間に基づいて、時間超過が発生しているか否かを判定する（ステップＳ３２）。具体的には、カウントした処理時間が。予め設定された基準時間よりも長くなっているか否かを判定する。

時間超過が発生していると判定された場合（ステップＳ３２：ＹＥＳ）、ノードは安全制御を実行させる（ステップＳ３３）。即ち、図３のステップＳ２７と同様の処理が実行される。安全制御を実行させる場合には、その時点でチェック処理が終了することになる。一方で、時間超過が発生していないと判定された場合（ステップＳ３２：ＮＯ）、ステップＳ３２の処理は省略され、チェック処理を終了するか否かを判定する（ステップＳ３４）。つまり、ノードの通常動作が終了し、チェック処理を終了する状況になったか否かを判定する（図２のステップＳ２４及びステップＳ２５参照）。

チェック処理を終了すると判定された場合（ステップＳ３４：ＹＥＳ）、一連のチェック処理は終了する。一方で、チェック処理を終了しないと判定された場合（ステップＳ３４：ＮＯ）、再びステップＳ３１の処理を開始する。このように、チェック処理中には、ノードにおいて時間超過が発生しているか否かが繰り返し判定されることになる。

＜安全制御動作＞
次に、本実施形態に係る車両用システム１００による安全制御動作（即ち、重要ノードにおいて処理遅延が発生する可能性がある場合に実行される動作）について、図５を参照して説明する。図５は、本実施形態に係る車両用システムによる安全制御動作の流れを示すフローチャートである。

図５に示すように、安全制御動作時には、まず実際に判定ノードで発生した時間超過、或いは今後重要ノードで発生すると予想される処理遅延が５ｍｓ以内であるか否かを判定する（ステップＳ４１）。時間超過又は処理遅延が５ｍｓ以内であると判定された場合（ステップＳ４１：ＹＥＳ）、以降の処理は省略され一連の処理が終了する。即ち、具体的な安全制御は実行されないまま処理が終了する。

時間超過又は処理遅延が５ｍｓ以内でないと判定された場合（ステップＳ４１：ＮＯ）、時間超過又は処理遅延が１０ｍｓ以内であるか否かを判定する（ステップＳ４２）。時間超過又は処理遅延が１０ｍｓ以内であると判定された場合（ステップＳ４２：ＹＥＳ）、安全制御としてドライバへの警告が実行される（ステップＳ４３）。この警告は、例えば音声による警告、或いはディスプレイへの警告表示等によって実現されればよい。一方、時間超過又は処理遅延が１０ｍｓ以内でないと判定された場合（ステップＳ４２：ＮＯ）、正常な処理実行が継続できないと判断し、システムそのものが停止される（ステップＳ４４）。

以上のように、安全制御動作時には、時間超過又は処理遅延の程度によって複数種類の安全制御が実行される。なお、上述した５ｍｓ及び１０ｍｓという閾値は、あくまで一例であり、異なる値が閾値として設定されてよい。また、ここでは、２つの閾値を用いる例を上げたが、より少ない又は多い数の閾値が設定されていてもよい。或いは、閾値等を用いた判定は行わず、安全制御動作が開始されると同時に、何らかの安全制御（例えば、車両の挙動を変化させる制御）が実行されるようにしてもよい。

＜自動運転システムへの適用例＞
次に、上述した本実施形態に係る車両用システム１００が自動運転システム（即ち、車両の走行をドライバの操作によらずに自動的に制御するシステム）に適用される場合の例を挙げて、より具体的に説明を進める。

＜自動運転システムのノード構成＞
まず、自動運転システムのノード構成について、図６を参照して説明する。図６は、自動運転システムのノード構成例を示すデータフローグラフである。

図６に示すように、自動運転システムは、自車位置推定ノード、周辺物標判定ノード、経路生成ノード、行動判断ノード、緊急非難行動ノード、ハンドル操作ノード、アクセル操作ノード、及びブレーキ操作ノードを備えて構成されている。なお、この例では、行動判断ノードが重要ノードとして設定され、経路生成ノードが判定ノードとして設定されている。

自車位置推定ノードは、例えばＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）等から車両の位置に関する情報を取得し、現在の車両の位置を推定する処理を実行する。周辺物標判定ノードは、自車位置推定ノードから出力される情報や、車両が備えるカメラやレーダ等からのデータに基づいて、車両周辺に存在する物標（言い換えれば、障害物）に関する情報を判定する処理を実行する。経路生成ノードは、自車位置推定ノードから出力される車両の位置情報、及び周辺物標判定ノードから出力される車両周辺の物標情報に基づいて、車両が走行すべき経路を生成する処理を実行する。行動判断ノードは、経路生成ノードから出力される経路情報に基づいて、車両の具体的な行動を決定するための処理を実行する。緊急避難行動ノードは、経路生成ノードの判定ノードとしての処理結果（即ち、処理遅延判定動作及び処理時間チェック動作の結果）に基づいて、緊急避難行動に関する処理を実行する。ハンドル操作ノード、アクセル操作ノード、及びブレーキ操作ノードの各々は、行動判断ノード又は緊急避難行動ノードの出力に基づいて、車両のハンドル、アクセル、ブレーキを自動的に操作するための処理をそれぞれ実行する。

＜判定ノードの動作例＞
次に、自動運転システムの判定ノード（即ち、経路生成ノード）における処理遅延判定動作の流れについて、図７を参照して説明する。図７は、自動運転システムの判定ノードにおける処理遅延判定動作の流れを示すフローチャートである。

図７に示すように、自動運転システムの判定ノードでは、まず実際に判定ノードで発生した時間超過、或いは今後重要ノードで発生すると予想される処理遅延が５ｍｓ以内であるか否かを判定する（ステップＳ５１）。時間超過又は処理遅延が５ｍｓ以内であると判定された場合（ステップＳ５１：ＹＥＳ）、以降の処理は省略され一連の処理が終了する。即ち、具体的な安全制御は実行されないまま処理が終了する。

時間超過又は処理遅延が５ｍｓ以内でないと判定された場合（ステップＳ５１：ＮＯ）、判定ノードである経路生成ノードにおける処理（即ち、通常動作）が未完了であるか否かを判定する（ステップＳ５２）。経路生成ノードにおける処理が未完了であると判定された場合（ステップＳ５２：ＹＥＳ）、ノードの再初期化を実行する（ステップＳ５３）。経路生成ノードにおける処理が未完了でないと判定された場合（ステップＳ５２：ＮＯ）、或いはノードの再初期化後には、緊急避難行動ノードへデータを送信する（ステップＳ５４）。この場合、緊急避難行動ノードの処理結果に基づいて、緊急避難行動（即ち、安全制御）が実行されることになる。緊急避難行動は、例えば停車、路肩に寄せて停車、自動ブレーキ、手動運転に切り替える等の制御を含んでいる。

＜技術的効果＞
次に、本実施形態に係る車両用システム１００によって得られる技術的効果について説明する。

すでに図１から７を参照して説明したように、本実施形態に係る車両用システム１００によれば、重要ノードで処理遅延が発生する前に、判定ノードで処理遅延が発生する可能性があるか否かが判定される。即ち、重要ノードよりも前のノードにおいて、後の重要ノードにおいて処理遅延が発生する可能性があるか否かが判定される。このため、実際に重要ノードで処理遅延が発生する前に、処理遅延への対策（即ち、安全制御）を実行することができる。このため、重要ノード自身で処理遅延の発生を判定する場合と比べると、好適に処理遅延への対策を行うことができる。

本実施形態に係る車両用システム１００のように、車両において各種処理を実行するシステムでは、重要ノードにおいて処理遅延が発生すると、正常に車両を走行させることができなくなるおそれがある。例えば、本実施形態に係る車両用システム１００が自動運転システムに適用される場合、重要ノードにおいて処理遅延が発生してしまうと、車両の挙動が不安定になり、安全な走行を維持することができなくなる可能性がある。

これに対し、本実施形態に係る車両用システム１００では、上述したように、実際に重要ノードで処理遅延が発生する前に（言い換えれば、重要ノードでの処理遅延を予測して）、安全制御を実行することができる。このため、仮に重要ノードで処理遅延が発生してしまうような場合であっても、事前に安全制御を開始することができ、その結果として車両の安全を維持することが可能となる。

＜付記＞
以上説明した実施形態から導き出される発明の各種態様を以下に説明する。

（付記１）
付記１に記載の車両用システムは、複数の制御装置を用いて処理を実行する車両用システムであって、前記複数の制御装置に含まれる第１の制御装置の処理が完了した時点での処理時間を取得する取得手段と、前記取得した処理時間に基づいて、前記第１の制御装置よりも後段で処理を実行する第２の制御装置において処理遅延が発生する可能性があるか否かを判定する判定手段と、前記第２の制御装置において処理遅延が発生する可能性があると判定された場合に、所定の制御を実行する実行手段とを備える。

付記１に記載の車両用システムによれば、第１の制御装置の処理が完了した時点での処理時間に基づいて、第２の制御装置において処理遅延が発生する可能性があるか否かが判定される（即ち、第２の制御装置における処理遅延が予測される）。第２の制御装置は、処理遅延が発生することにより、システムに比較的大きな影響が出る制御装置（言い換えれば、複数の制御装置の中でも比較的重要度の高い制御装置）である。第２の制御装置において処理遅延が発生する可能性は、例えば取得した処理時間と予め設定された基準処理時間とを比較して算出される超過時間（言い換えれば、第１の制御装置の処理が完了した時点で、どれだけ処理が遅れているかを示す値）に基づいて判定されればよい。なお、ここでの「処理時間」とは、第１の制御装置の処理開始から第１の制御装置の処理完了までの時間であってもよいし、システム全体での処理開始から第１の制御装置の処理完了までの時間であってもよい。

上述した判定によれば、実際に第２の制御装置において処理遅延が発生する前に、処理遅延への対応策である所定の制御を実行すべきか否かを判断し、より適切なタイミングで所定の制御を実行することが可能である。具体的には、例えば車両用システムが車両の自動運転のための処理を実行している状況において、第２処理装置における処理遅延が発生する可能性があると判定された場合には、処理遅延によって正常な自動運転ができなくなる前に（即ち、第１処理装置の処理が完了した時点で）、例えば停車、路肩に寄せて停車、自動ブレーキ、手動運転に切り替える等の所定の制御が実行できる。従って、仮に処理遅延が発生した場合であっても、車両の安全を維持することが可能である。

本発明は、上述した実施形態に限られるものではなく、請求の範囲及び明細書全体から読み取れる発明の要旨或いは思想に反しない範囲で適宜変更可能であり、そのような変更を伴う車両用システムもまた本発明の技術的範囲に含まれるものである。

１００ 車両用システム

Claims (1)

1. 複数の制御装置を用いて処理を実行する車両用システムであって、
   前記複数の制御装置に含まれる第１の制御装置の処理が完了した時点での処理時間を取得する取得手段と、
   前記取得した処理時間に基づいて、前記第１の制御装置よりも後段で処理を実行する第２の制御装置において処理遅延が発生する可能性があるか否かを判定する判定手段と、
   前記第２の制御装置において処理遅延が発生する可能性があると判定された場合に、所定の制御を実行する実行手段と
   を備えることを特徴とする車両用システム。

Images