知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-01-07
(45)【発行日】2022-01-21
(54)【発明の名称】隊列走行コントローラの状態マシン
(51)【国際特許分類】
G08G 1/00 20060101AFI20220114BHJP
G08G 1/09 20060101ALI20220114BHJP
G08G 1/16 20060101ALI20220114BHJP
B60W 50/14 20200101ALI20220114BHJP
B60W 30/165 20200101ALI20220114BHJP
【ＦＩ】
G08G1/00 X
G08G1/09 H
G08G1/16 A
G08G1/16 E
B60W50/14
B60W30/165
【請求項の数】
10
(21)【出願番号】P 2018562534
(86)(22)【出願日】2017-05-30
(65)【公表番号】
(43)【公表日】2019-07-04
(86)【国際出願番号】 US2017035019
(87)【国際公開番号】W WO2017210200
(87)【国際公開日】2017-12-07
【審査請求日】2020-05-29
(31)【優先権主張番号】62/343,819
(32)【優先日】2016-05-31
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/363,192
(32)【優先日】2016-07-15
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/377,970
(32)【優先日】2016-08-22
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】518064248
【氏名又は名称】ぺロトン テクノロジー インコーポレイテッド
(74)【代理人】
【識別番号】100147485
【弁理士】
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】230118913
【弁護士】
【氏名又は名称】杉村 光嗣
(74)【代理人】
【識別番号】100132045
【弁理士】
【氏名又は名称】坪内 伸
(72)【発明者】
【氏名】ローレンツ ロービンガー
(72)【発明者】
【氏名】ステファン エム エーリエン
(72)【発明者】
【氏名】ジョシュア ピー スウィックス
【審査官】田中 将一
(56)【参考文献】
【文献】特開２０１３－０７３３６０（ＪＰ，Ａ）
【文献】特開２０１０－２４４２９０（ＪＰ，Ａ）
【文献】特開２０００－３３９５９９（ＪＰ，Ａ）
【文献】特開２０１４－０７８１７０（ＪＰ，Ａ）
【文献】特開２０１２－２３０５２３（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０８Ｇ １／００ － ９９／００
Ｂ６０Ｗ １０／００ － １０／３０
Ｂ６０Ｗ ３０／００ － ６０／００
(57)【特許請求の範囲】
【請求項1】
ホスト車両と隊列走行パートナーとの間で隊列走行を開始する方法であって、前記隊列走行パートナーとの通信を確立するステップと、
前記隊列走行パートナーの隊列走行制御システムが隊列走行の準備は完了しているというメッセージを受信するステップと、
前記ホスト車両の隊列走行コントローラが隊列走行準備完了状態であるか否かを決定する決定ステップであり、前記ホスト車両が隊列走行準備完了状態であることを決定される前に複数の隊列走行必要条件チェックが合致していなければならず、また前記ホスト車両の隊列走行コントローラは前記隊列走行コントローラの状態を決定する状態マシンを備え、前記ホスト車両が後続車両として指定されるときの前記状態マシンの応対可能な状態は、ランデブー状態と、後方システム準備完了状態と、後方隊列走行準備完了状態と、後方隊列走行制御維持状態と、及び後方隊列走行解消状態とを含むものである、該決定ステップと、
前記ホスト車両の前記隊列走行コントローラが隊列走行準備完了状態であることを決定するとき、かつ前記隊列走行パートナーの隊列走行制御システム準備完了メッセージを受信した後にのみ、ホストシステム隊列走行準備完了メッセージを前記隊列走行パートナーに送信するステップと、
前記隊列走行パートナーが隊列走行を同意したことを示す隊列走行パートナー隊列走行準備完了メッセージを受信するステップであり、前記隊列走行パートナー隊列走行準備完了メッセージは、前記ホストシステム隊列走行準備完了メッセージ送信後にのみ受信されるものである、該ステップと、
前記ホスト車両が隊列走行準備完了状態であるという情報を前記ホスト車両の運転者に知らせるステップであり、前記運転者は、前記隊列走行パートナー隊列走行準備完了メッセージを受信した後に前記ホスト車両が隊列走行準備完了状態であるという情報のみを知らされる、該ステップと、
前記運転者からの隊列走行開始コマンドを受信するステップと、
前記隊列走行開始コマンドに応答して前記ホスト車両の少なくとも部分的な自動隊列走行制御を開始するステップと
を備える、方法。
【請求項2】
請求項１記載の方法において、前記状態マシンは、前記パートナー車両における対応する隊列走行コントローラが前方隊列走行準備完了状態にあるときにのみ、前記後方隊列走行準備完了状態に遷移することができ、前記前方隊列走行準備完了状態は、前記パートナー車両の運転者が隊列走行準備完了であることを肯定的に意思表示することを必要とするものである、方法。
【請求項3】
請求項１又は２記載の方法において、前記状態マシンは、複数の隊列走行必要条件チェックが合致するときにのみ後方システム準備完了状態に遷移することができる、方法。
【請求項4】
請求項３記載の方法において、前記隊列走行必要条件チェックは、現在隊列走行パートナーが隊列走行準備完了状態にあるかを検証するチェックと、
前記隊列走行パートナーが前記ホスト車両の指定レンジ内にあるかを検証するチェックと、
前記ホストと前記隊列走行パートナーとの間の通信が安定しているかを検証するチェックと、及び
前記ホストにおける追跡ユニットが前記隊列走行パートナーの位置決定をしているかを検証するチェックと
を含む、方法。
【請求項5】
請求項１～４のうちいずれか一項記載の方法において、前記後続車両の運転者は、前記状態マシンを前記後方隊列走行準備完了状態から前記後方隊列走行制御維持状態に遷移させるため、隊列走行準備完了であることを肯定的に意思表示しなければならない、方法。
【請求項6】
請求項１～５のうちいずれか一項記載の方法において、前記ホスト車両が先行車両として指定されるときの前記状態マシンの応対可能な状態は、前方ランデブー状態と、
前方システム準備完了状態と、
前方隊列走行準備完了状態と、及び
前方隊列走行制御維持状態と
を含む、方法。
【請求項7】
請求項１～６のうちいずれか一項記載の方法において、前記隊列走行コントローラは、さらに、前記状態マシンが後方隊列走行制御維持状態にあるとき、複数の隊列走行必要条件チェックを実施するよう構成され、また前記隊列走行必要条件チェックのうちいずれかのチェックが不合格の場合には、前記状態マシンを前記後方隊列走行解消状態に遷移させる、方法。
【請求項8】
請求項７記載の方法において、前記隊列走行必要条件チェックのうち１つは、前記隊列走行パートナーから受信する通信を監視し、また信頼性のある通信が前記隊列走行パートナーから指定された経時期間にわたり受信されない場合、前記状態マシンを前記後方隊列走行制御維持状態から前記後方隊列走行解消状態に遷移させる、方法。
【請求項9】
請求項７記載の方法において、前記隊列走行必要条件チェックのうち１つは、懸念車両が前記隊列走行パートナーの前方にいることを認識するとき、前記状態マシンを前記後方隊列走行制御維持状態から前記後方隊列走行解消状態に遷移させる、方法。
【請求項10】
請求項１～９のうちいずれか一項記載の方法において、前記ホスト車両及び前記隊列走行パートナーは双方ともにトラックである、方法。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、２０１６年５月３１日に出願された米国仮出願第６２／３４３，８１９号及び２０１６年７月１５日に出願された米国仮出願第６２／３６３，１９２号の優先権を主張するものであり、これら米国仮出願各々は、参照により全体が本明細書に組み入れられるものとする。
本出願は、２０１６年５月３１日に出願された米国仮出願第６２／３４３，８１９号及び２０１６年７月１５日に出願された米国仮出願第６２／３６３，１９２号の優先権を主張するものであり、これら米国仮出願各々は、参照により全体が本明細書に組み入れられるものとする。
【0002】
本出願は、概して、自動制御又は部分的自動制御を用いて、車両を順次他の車両に接近して安全に追従させることを可能にするシステム、方法及び装置に関する。より具体的には、本発明は、車両が車両隊列走行（プラトーン）を安全かつ効率的に開始、維持及び解消するのを可能にするシステム、方法及び装置に関する。
【背景技術】
【0003】
近年、自動車両制御の分野において大幅な発展がなされてきた。車両自動化における１つのセグメントは、車両同士が互いに接近して安全、効率的及び都合よく追従できる車両集団走行（コンボイ）化システムに関する。接近して他の車両に後続することは大幅な燃料節約の利点をもたらす潜在力を有するが、運転者が手動で行うとき一般的には安全ではない。１つのタイプの車両集団化システムは、ときに車両隊列走行（プラトーン）化と称され、第２の及び潜在的に追加され得る車両が先行車両に接近して安全に追従するよう自動的又は半自動的に制御される。
【発明の概要】
【発明が解決しようとする課題】
【0004】
隊列走行の燃料効率における利点は、長距離を幹線道路（ハイウェイ）速度で走行しがちなトラック輸送産業のような分野で特に顕著である。隊列走行における１つの継続する課題は、隊列走行制御を開始し、参加者を互いに導き出すことにより隊列走行パートナーの識別からその隊列走行を管理し、隊列走行中に所望間隔（ギャップ）を維持し、また適宜隊列走行を優雅に解消することである。他の課題は、隊列走行が推奨されない状況を信頼性高く識別することである。本出願は、隊列走行を管理するための、また隊列走行制御を開始すべきでないことを示唆する及び／又は隊列走行している既存の隊列の解消を示唆する条件を識別する技術について記載する。
【課題を解決するための手段】
【0005】
自動又は部分的自動制御を使用し、車両を他の車両に対して至近距離で追従させる制御するための様々な方法、コントローラ、及びアルゴリズムを記載する。本明細書に記載する制御スキームは、隊列走行する車両及び／又は集団走行する車両向け用途に使用するのに十分好適であり、トラックの隊列走行化及び集団走行化用のコントローラを含む。
【0006】
一態様において、ホスト車両（隊列走行における後続車両とすることができる）と隊列走行パートナー（隊列走行における先行車両とすることができる）との間で隊列走行を開始する方法について記載する。幾つかの実施形態において、隊列走行参加車両間における特別なハンドシェイクプロトコルが隊列走行制御を確立する前に必要である。隊列走行参加車両間の通信が確立した後、先行車両は、その隊列走行コントローラが隊列走行準備完了状態にあるとき、前方システム準備完了メッセージを後続車両に送信する。後続車両の隊列走行コントローラは、隊列走行準備完了状態にあるか否かを決定する。後続車両の隊列走行コントローラが隊列走行準備完了状態であるとき、後方システム準備完了メッセージを先行車両に送信する。しかし、後方システム準備完了メッセージは、前方システム準備完了メッセージを受信した後でしか送信することができない。後方システムが準備完了状態となった後では、先行車両は隊列走行に同意しなければならない。先行車両が手動運転者制御の下にあるシステムにおいては、運転者の同意を得なければならない；先行車両同意を受信した後、後続車両の運転者は、隊列走行パートナーが隊列走行の準備を完了しているという情報を与えられる。この時点で、後続車両の運転者は隊列走行を開始することができ、後続車両の少なくとも何らかの自動制御を開始し、この自動制御には、典型的には少なくともトルクリクエスト及び制動リクエストの制御を含む。
【0007】
好適には、隊列走行参加車両各々は、そのシステムが隊列走行準備完了と見なされる前に多数の隊列走行必要条件チェックに合格しなければならないが、特別なチェックは、隊列走行参加車両が先行車両又は後続車両として指名されるか否かに基づいて変化し得る。
【0008】
他の態様において、ホスト車両の隊列走行コントローラがホスト車両の隊列走行制御を開始する準備を完了しているか否かを決定する多数の特定チェックについて記載する。幾つかの実施形態において、前記チェックとしては、現在、隊列走行パートナーが隊列走行準備完了状態にあるかを検証するチェック、隊列走行パートナーがホスト車両の指定レンジ内にあるかを検証するチェック、ホストと隊列走行パートナーとの間の通信が安定しているかを検証するチェック、及びホストにおける追跡ユニットが隊列走行パートナーの位置決定をしているかを検証するチェックを含む。
【0009】
幾つかの実施形態において、前記チェックは、隊列走行パートナーの現在減速が指定された減速閾値を超えていないかを検証するチェック、ホストと隊列走行パートナーとの間に割込み車両が検出されていなかったかを検証するチェック、現時点における隊列走行制御への遷移が指定制動リクエスト閾値を超える制動リクエストを発生させることがないかを検証するチェック、及び隊列走行パートナー速度、ホスト車両速度、及びホスト車両の隊列走行パートナーに対する相対速度のうち少なくとも２つが認可された隊列走行限界内にあるかを検証するチェックのうち、１つ又はそれ以上のチェックを含む。
【0010】
他の態様において、隊列走行に参加するホスト車両を制御する隊列走行コントローラについて記載する。隊列走行コントローラは、隊列走行コントローラの状態を決定する状態マシンを備える。幾つかの実施形態において、ホスト車両が後続車両として指定されるときの状態マシンの応対可能な状態は、ランデブー状態と、後方システム準備完了状態と、後方隊列走行準備完了状態と、後方隊列走行制御維持状態、及び後方隊列走行解消状態とを含む。
【0011】
幾つかの実施形態において、状態マシンは、前記パートナー車両における対応する隊列走行コントローラが前方隊列走行準備完了状態にあるときにのみ、前記後方隊列走行準備完了状態に遷移することができ、前記前方隊列走行準備完了状態は、前記パートナー車両の運転者が隊列走行準備完了であることを肯定的に意思表示することを必要とするものである。幾つかの実施形態において、前記状態マシンは、上述した複数の隊列走行必要条件チェックが合致するときにのみ後方システム準備完了状態に遷移することができる。幾つかの実施形態において、前記後続車両の運転者は、前記状態マシンを前記後方隊列走行準備完了状態から前記後方隊列走行制御維持状態に遷移させるため、隊列走行準備完了であることを肯定的に意思表示しなければならない。
【0012】
好適には、隊列走行コントローラは、さらに、前記状態マシンが後方隊列走行制御維持状態にあるとき、複数の隊列走行必要条件チェックを実施するよう構成され、また前記隊列走行必要条件チェックのうちいずれかのチェックが不合格の場合には、前記状態マシンを前記後方隊列走行解消状態に遷移させる。
【0013】
幾つかの実施形態において、前記隊列走行必要条件チェックのうち幾つかは、先行車両から受信した情報、例えば、懸念車両が前記隊列走行パートナーの前方にいる（例えば、パートナー車両前方に速度が遅い車両が隊列走行パートナーに接近し過ぎている）ことの認識、又は信頼性のある通信が前記隊列走行パートナーから指定された経時期間にわたり受信されないことの決定に基づく。
【0014】
幾つかの実施形態において、ホスト車両が先行車両として指定されるときの前記状態マシンの応対可能な状態は、前方ランデブー状態と、前方システム準備完了状態と、前方隊列走行準備完了状態と、及び前方隊列走行制御維持状態とを含む。
【0015】
他の態様において、車両が隊列走行における後続車両として隊列走行コントローラによって少なくとも半自動的に制御されている間に、前記車両の運転者に対して制動アラートを発生する方法について記載する。幾つかの実施形態において、前記後続車両の前方にいる隊列走行パートナーから受信する情報の少なくとも一部に基づいて所望制動レベルを決定する。前記所望制動レベルが前記隊列走行コントローラによってコマンド指令され得る最大制動を超えることを決定し、また追加制動が必要であると見なされるとき、手動によりブレーキを掛けるアラートを前記運転者に発令する。好適には、前記アラートは、緊急制動であることを示す発話音声通知を含み、例えば、「BRAKE NOW（今ブレーキを掛けよ）」の発話指令である。
【0016】
本発明及びその利点は、添付図面に関連する以下の説明を参照することによって最もよく理解されるであろう。
【図面の簡単な説明】
【0017】
【図1A】本発明による隊列走行の第１段階（応対可能）における先行車両及び追従又は後続車両を示す図である。
【図1B】本発明による隊列走行の第２段階（リンク付け中）における先行車両及び追従又は後続車両を示す図である。
【図1C】本発明による隊列走行の第３段階（リンク付け済）における先行車両及び後続車両を示す図である。
【図2】後続車両から見た前方視図の実施形態を示す図である。
【図3】隊列走行している車両、補助車両、無線トランシーバ、及びネットワークオペレーションセンターの間の種々の通信リンクを示す図である。
【図4】ＮＯＣに保守されているような中央サーバが、リンク付けする候補を決定する際に考慮し得る種々の要素を示す図である。
【図5A】通信を管理するとともに種々の車両の機能を監視及び制御するために車両に搭載される制御システムの実施形態を簡略化して示す図である。
【図6】ＮＯＣと車両との間で送信される種々のタイプのメッセージとともに、車載システム及びＮＯＣのためのアーキテクチャを簡略化して示す図である。
【図7A】本発明の一実施形態による、車両監視及び制御システムを１つ又は複数のソフトウェア層に組み合わせて含む隊列走行監督システムの動作を示すブロック図である。
【図8B】本発明の車両制御システムの実施形態の動作を、ソフトウェア機能の観点から示す図である。
【図9】本発明による車両データ処理の主ループの一実施形態を、フローで示す図である。
【図10】ＮＯＣの車両通信管理の一実施形態をフローで示す図である。
【図11A】地理的フェンス付け能力を含む、本発明の長距離連携の態様を示す図である。
【図11B】地理的フェンス付け能力を含む、本発明の長距離連携の態様を示す図である。
【図12】本発明による連携及びリンク付けの処理の実施形態をフローで示す図である。
【図13】本発明の一態様である走行予測機能の実行に好適なソフトウェアアーキテクチャの実施形態を示す図である。
【図14】本発明による隊列走行システム用のプロセスアーキテクチャの実施形態を示す図である。
【図15】車両が隊列走行位置に「プルイン（引き入れ）」し、或る期間にわたり接近隊列走行車間距離を維持し、またこの後適宜隊列走行を解消する実施形態をフローチャート形式で示す図である。
【図16】図１６Ａは、隊列走行を形成するプルイン段階中における車両ペアの関わり合いを示す図である。図１６Ｂは、隊列走行を形成するプルイン段階中における車両ペアの関わり合いを示す図である。図１６Ｃは、隊列走行を形成するプルイン段階中における車両ペアの関わり合いを示す図である。
【図17】図１７Ａは、前方車両に対する後方車両の接近速度対現出隊列走行が安全領域内で運行していることを確証する車間距離をプロットしたグラフである。図１７Ｂは、速度対プルイン中又はシステム関与中における車両ペアのための目標車間が達成されるまでの時間をプロットしたグラフである。
【図18A】システムが検出して運転者への制動アラートを生ぜしめる様々な運行条件をフロー形式で示す図である。
【図18B】システムが検出して運転者への制動アラートを生ぜしめる様々な運行条件をフロー形式で示す図である。
【図18C】システムが検出して運転者への制動アラートを生ぜしめる様々な運行条件をフロー形式で示す図である。
【図19】車両間通信リンクの適正な動作を確証するためのプロセスをフロー形式で示す図である。
【図20】隊列走行速度を選択するための代替案的プロセスを示す図である。
【図21A】互いに逸脱している車両の連携付けプロセスを示す図である。
【図22】イベントデータのログ記録及びデータ転送の全体的プロセスフローを示す図である。
【図23】運転者が気付くような、隊列走行にペア付けされていない車両の遷移の実施形態を状態マシン（ステートマシン）の形式で示す図である。
【図24A】ペア付けされていない状態から隊列走行化への遷移及びペア付けされていない状態に戻ることを管理するための種々のゾーンの実施形態を示す図である。
【図25】図２５Ａは、隊列走行をしようとしている車両間のランデブー開始状態における運転者が見るディスプレイを示す図である。隊列走行をしようとしている車両間のランデブー開始状態における道路状況を示す図である。図２５Ｂは、隊列走行をしようとしている車両間のランデブー開始状態における運転者が見るディスプレイを示す図である。図２５Ｃは、隊列走行をしようとしている車両間のランデブー開始状態における運転者が操作することができる手制御及び足制御を示す図である。
【図26】図２６Ａは、車両が互いに比較的接近しているが隊列走行のためのプルイン（又はドローイン）が確立していないときの道路状況を示す図である。図２６Ｂは、車両が互いに比較的接近しているが隊列走行のためのプルイン（又はドローイン）が確立していないときのディスプレイ画面を示す図である。図２６Ｃは、車両が互いに比較的接近しているが隊列走行のためのプルイン（又はドローイン）が確立していないときの運転者制御を示す図である。
【図27】図２７Ａは、先行しようと意図する車両が後続しようと意図する車両の背後にいる場合の逆フォーメーションにおける道路状況を示す図である。図２７Ｂは、先行しようと意図する車両が後続しようと意図する車両の背後にいる場合の逆フォーメーションにおけるディスプレイ画面を示す図である。図２７Ｃは、先行しようと意図する車両が後続しようと意図する車両の背後にいる場合の逆フォーメーションにおける運転者制御を示す図である。
【図28】図２８Ａは、車両が隊列走行の準備が完了するほど十分に接近したときの道路状況を示す図である。図２８Ｂは、車両が隊列走行の準備が完了するほど十分に接近したときのディスプレイ画面を示す図である。図２８Ｃは、車両が隊列走行の準備が完了するほど十分に接近したときの運転者制御を示す図である。
【図29】図２９Ａは、車両がドローイン（引き込み）し始めるときの道路状況を示す図である。図２９Ｂは、車両がドローイン（引き込み）し始めるときのディスプレイ画面を示す図である。図２９Ｃは、車両がドローイン（引き込み）し始めるときの運転者制御を示す図である。
【図30】図３０Ａは、車両が隊列組みを済ませており、隊列走行定常状態を呈しているときの道路状況を示す図である。図３０Ｂは、車両が隊列組みを済ませており、隊列走行定常状態を呈しているときのディスプレイ画面を示す図である。図３０Ｃは、車両が隊列組みを済ませており、隊列走行定常状態を呈しているときの運転者制御を示す図である。
【図31】図３１Ａは、車両が隊列組みを済ませており、一方の運転者が手制御又は足制御のいずれかを操作して隊列走行を終了させることを決定するときの道路状況を示す図である。図３１Ｂは、車両が隊列組みを済ませており、一方の運転者が手制御又は足制御のいずれかを操作して隊列走行を終了させることを決定するときのディスプレイ画面を示す図である。図３１Ｃは、車両が隊列組みを済ませており、一方の運転者が手制御又は足制御のいずれかを操作して隊列走行を終了させることを決定するときの運転者制御を示す図である。
【図32】図３２Ａは、隊列走行を解消し、また車両が離れる移動をしているときの道路状況を示す図である。図３２Ｂは、隊列走行を解消し、また車両が離れる移動をしているときのディスプレイ画面を示す図である。図３２Ｃは、隊列走行を解消し、また車両が離れる移動をしているときの運転者制御を示す図である。
【図33】図３３Ａは、隊列走行が解消された後、車両が隊列走行に再関与する上で十分なほど接近しているが、手動への引継ぎが許可されるほどに十分離れているときの道路状況を示す図である。図３３Ｂは、隊列走行が解消された後、車両が隊列走行に再関与する上で十分なほど接近しているが、手動への引継ぎが許可されるほどに十分離れているときのディスプレイ画面を示す図である。図３３Ｃは、隊列走行が解消された後、車両が隊列走行に再関与する上で十分なほど接近しているが、手動への引継ぎが許可されるほどに十分離れているときの運転者制御を示す図である。
【図34】図３４Ａは、車両が「隊列走行準備完了」状態に復帰するには十分遠く離れているときの道路状況を示す図である。図３４Ｂは、車両が「隊列走行準備完了」状態に復帰するには十分遠く離れているときのディスプレイ画面を示す図である。図３４Ｃは、車両が「隊列走行準備完了」状態に復帰するには十分遠く離れているときの運転者制御を示す図である。
【図35】図３５Ａは、運転者がその車両制御を引き継ぐことを必要としているほど十分遠く離れているときの道路状況を示す図である。図３５Ｂは、運転者がその車両制御を引き継ぐことを必要としているほど十分遠く離れているときのディスプレイ画面を示す図である。図３５Ｃは、運転者がその車両制御を引き継ぐことを必要としているほど十分遠く離れているときの運転者制御を示す図である。
【図36】本発明実施形態による隊列走行コントローラの状態及び状態間遷移トリガのセットを示す状態図である。
【図37】隊列走行状態への遷移を司るハンドシェイクプロセスの実施形態を示すフローチャートである。
【図38】本発明実施形態によるホスト車両が隊列走行の準備が完了しているか否かを決定するのに有用な多数のモニタを示すブロック図である。
【図39】隊列走行を支援する自動化した又は部分的に自動化した車両制御システムに使用するのに適した代案的なコントローラアーキテクチャのブロック図である。
【図41】本発明の一実施形態による間隔コントローラのブロック図である。
【図42】図４２Ａは、異なる運行状態中における本発明実施形態による間隔レギュレータが使用する異なる制御状態を示す図である。図４２Ｂは、異なる運行状態中における本発明実施形態による間隔レギュレータが使用する異なる制御状態を示す図である。図４２Ｃは、異なる運行状態中における本発明実施形態による間隔レギュレータが使用する異なる制御状態を示す図である。
【図43】スライディングモード制御のスキームを示す状態空間図である。
【発明を実施するための形態】
【0018】
本発明は、添付図面に示されるように、幾つかの実施形態を参照して、詳細に説明される。以下の説明において、本発明の実施形態の完全な理解を促すために、特定の詳細を、本発明の複数の異なる態様の記載を含め（場合によっては１つ以上の選択肢を含む）、多数示す。本発明は、本明細書に開示した特徴の全てを実装しなくても実施できることは、当業者に明らかである。実施形態の特徴及び利点は、以下の図面及び説明を参照することによって、より理解され得る。
【0019】
本発明は、自動及び半自動で車両集団走行（コンボイ）化システム及び方法に関する。このようなシステムによれば、車両は、便利で安全に、順次互いに接近して後続することが可能になる。例示の便宜上、以下の説明で示す例示の車両は、一般に大型トラックとするが、本明細書に開示される特徴の全てではないにしても多くは、多数の他タイプの車両にも適用し得ることは、当業者には明らかであろう。したがって、本開示及び本明細書に開示された実施形態の少なくとも幾つかは、任意な特定タイプの車両に限定されない。
【0020】
まず、図１Ａ～図１Ｃは、隊列走行の３つの段階を示している。図１Ａにおいて、１００により示す車両Ａと、１０５により示す車両Ｂとは、互いに独立して動作しているが、それぞれリンク付け（linking）に応対可能である。幾つかの実施形態において、車両Ａ及びＢについて１１０及び１１５により示されるディスプレイは、それぞれ、場合によって、状態、候補のパートナー車両からの距離、及び燃料消費量を示すが、以下によりよく理解されるように、他のデータも表示することができる。図１Ｂにおいて、車両Ａ及びＢは、リンク付け（リンク中）、すなわち隊列走行への合流が可能な程度に十分互いに近接している。以下により詳細に説明するように、リンク付けの候補は、代表的には、車両が大型トラックである場合、例えば、車隊管理センターなどのネットワークオペレーションセンター（ＮＯＣ）で選択される。そのような実施形態では、ＮＯＣは、リンク付けに適した候補を識別するメッセージとともに、双方の運転者が同時に目標のランデブー地点に到達して隊列走行を形成できることを容易にするための情報を、各車両に送信する。
【0021】
再び図１Ｂを参照すると、車両Ａ及びＢは、この時点において、隊列走行に適した或る道路区域におけるランデブー地点に案内されている。米国特許第８，７４４，６６６（参照によって本明細書に組み入れられるものとし、また以下により詳細に説明する）に開示されているように、２つの車両が十分近接している時、これら車両間に通信リンクが確立され、また前方又は先行（先頭）のトラックに存在している処理システムが、後方又は後続のトラックにおける同様の処理システムとの通信を開始する。一実施形態では、次に、先行トラックが後続トラックの処理システムにコマンドを送って、例えば後続トラックの加速及び制動を制御し、先行トラックに至近距離で後続（追従）する位置に移動させる。一実施形態では、先行トラックのプロセッサは、先行トラックの加速及び制動を制御して、後続トラックを、先行トラックの背後位置であって例えば３.０５ｍ（１０フィート）～１８.２９ｍ（６０フィート）の範囲における至近距離で後続する位置に安全に誘導することができる。
【0022】
後続トラックが隊列走行の位置に誘導された後、先行車両は、後続トラックの少なくとも加速及び制動の制御を維持する。この時点で、図１Ｃに示すように、車両はリンク付けされている（リンク済み）。しかしながら、少なくとも幾つかの実施形態では、後方車両の運転者は、後方車両が半自動でのみ操作されるように操縦の制御を維持する。他の実施形態では、後方車両の全自動運転が実施される。このような半自動化及び自動化は、ときに半自律型及び自律型とも称されることは、当業者には明らかであろう。
【0023】
リンク付けされたとき、後方車両の前部から見た眺めは図２に示すようになり、この場合、説明の便宜上大型トラックの例を示してある。先行トラック２００は、後続トラックの直前にあり、ディスプレイ２１０は、先行トラックに取り付けられた前方指向カメラからの視界を示す。幾つかの実施形態では、触感又は音声の装置を実装して、後続トラックの運転者が、隊列走行中に先行トラックのほぼ直後を維持し得るようにできる。例えば、後続車両の運転者が車線（レーン）を外れて左側に進路を変えようとする場合、左側の音声信号を作動させて、運転者が車両を先行車両に対して適正整列状態に復帰するのをアシストすることができる。同様に、後続車両の運転者が車線を外れて右側に進路を変えようとする場合、右側の音声信号を作動させることができる。幾つかの実施形態では、作動させる音声信号を逆にしてもよい。すなわち、左側に進路を変えると右側の音声信号を作動させることができ、また逆も同様とすることができる。触感刺激が望ましい場合、一対の（右及び左の）振動源を、ハンドル若しくは運転席又はその双方に実装してもよい。あるいは、幾つかの実施形態では、単一の振動源を使用してもよい。
【0024】
車両が隊列走行フォーメーションを形成しているとき、各トラックのプロセッサ間でメッセージを通信するには、例えばＤＳＲＣなどの短距離通信リンクが好適であるが、例えばセルラーなどの他方式の無線通信を使用することもできる。しかしながら、隊列走行フォーメーションを形成している場合でも、車両にとってＮＯＣとの通常通信を維持することは有用である。以下により詳細に説明するように、トラックの整備状況及び性能、経路変更、局地的な気象及び他のデータを含む種々のデータが、各トラックからＮＯＣに送信される。これにより、車隊のオペレータは、積極的にトラックのメンテナンス及び修理を管理したり、気象の問題や道路工事に応じて経路を調整したり、緊急時に車両の位置を特定したり、その他の種々の分析を管理することができる。
【0025】
図３は、本発明によるシステムにおけるメッセージ交換を管理する通信リンクの実施形態を示す図である。より具体的には、図３は、潜在的な又は実際の隊列走行パートナーと、１つ以上の関連するＮＯＣと、ＮＯＣにリモートアクセスを行う無線アクセスポイントとの間で、メッセージ交換を管理する種々の通信プロトコルを使用する実施形態を示している。ＮＯＣとの通信が一定期間利用できない場合、図３は、ＮＯＣと車両との間で中間の車両を介してメッセージを通信することができるメッシュネットワークの実施形態を示す。より具体的には、車両１００は、参照符号３００で示すように、ＤＳＲＣ又は他の適切な有線又は無線の技術を介して、隊列走行のパートナー車両１０５と通信している。さらに、車両１００の経路の大部分について、車両１００は、セルラーリンク３２０を介して、ＮＯＣ３１０とも通信している。同様に、車両１０５は、無線リンクにおける切断がない限り、セルラーリンク３２０を介して、ＮＯＣ３１０と通信する。
【0026】
しかしながら、セルラー通信は、特に変化する地形を長距離運転する車両において、常に可能とは限らない。さらに、ビデオ録画又は他の高帯域の機能が使用される場合に車両に格納され得るような大量のデータを転送するには、セルラーは比較的遅い。したがって、幾つかの実施形態では、車両１００及び１０５は、ＷｉＦｉホットスポット３３０にアクセスする装備がなされており、このＷｉＦｉホットスポット３３０は、参照符号３４０で示した無線リンク又は参照符号３５０で示した有線チャネルのいずれかを介してＮＯＣと通信する。固定されたＷｉＦｉホットスポットは、車隊オペレーションセンターと同様に、車道に沿ってますます偏在するようになっている。さらに、４ＧのＬＴＥ又は同様のサービスに基づく車両内ＷｉＦｉホットスポットが導入されるようになった。場合によっては、マイクロセル及び同様の技術も、通信リンクを提供することができる。
【0027】
幾つかの実施形態では、アドホックメッシュネットワークに基づく中継技術を用いることができる。例えば、車両１００が東に走行し、ＮＯＣ３００へのセルラー接続が良好な領域をちょうど通過したが、次に無線接続性がないゾーンを通過しつつあると仮定する。また、参照符号３６０で示す車両Ｘが西に走行しており、ある期間、ＮＯＣとの接続は外れたが、トラック１００より先に無線接続を回復すると仮定する。少なくとも幾つかの実施形態では、ＮＯＣ３１０は、セルラー又は同様のリンクが利用できないときでも、さらに後述するように、走行の予測に基づいて、監視するそれぞれの車両の位置を、合理的な精度で把握する。したがって、ＮＯＣ３１０が車両Ｘに情報を送信する必要がある場合、ＮＯＣは、車両１００が依然としてＮＯＣに接続性を有している間に、車両Ｘへのメッセージを車両１００に送信する。この後、車両１００及び車両Ｘが互いに近接しているとき、車両１００は、ＮＯＣのメッセージを車両Ｘに中継する。同様に、車両１００はＮＯＣにデータを送信する必要があるが、ＮＯＣとその時点で接続していない場合、車両１００がそのデータを車両Ｘに中継して、車両ＸがＮＯＣへの接続を回復すると、車両ＸはＮＯＣにデータを再送信することができる。
【0028】
幾つかの実施形態では（他の実施形態ではあり得ないこともあるが）、このような無線のメッセージ交換がセキュリティ目的で暗号化されることは、当業者に明らかであろう。適切な安全対策を取ることで、車隊運行管理内にはない車両も利用してメッセージを中継することができる。例えば、参照符号３７０及び３８０で示す車両Ｙ及びＺは、リンク３９０を介して車両Ａ及びＢからメッセージを受信し、ＮＯＣと通信する装備が適切であれば（標準プロトコルによって可能になる）、そのメッセージをＮＯＣ３１０に中継することができる。無線接続性のための装備をした十分な台数の車両が存在する環境であれば、メッシュネットワークが形成され、これにより、メッセージは、車両から車両に、またそこからＮＯＣに送られる。このようなメッシュネットワークはまた、状態メッセージを車両から車両に伝達することを可能にするので、例えば車両１００及び１０５の隊列走行において、周囲の車両の状態を知得することができる。例えば、左側の車が道路を出る必要がある場所を隊列走行に知らせることができ、例えば、その車が車両１００と車両１０５との間に割り込むのを隊列走行に回避させることができる、さもなければ隊列走行は予想外の挙動をする。同様に、緊急事態を十分前もって車両Ａ及びＢを含む隊列走行に伝えることにより、運行の安全性を高めることができる。
【0029】
前述の隊列走行及びネットワークを経て車両から車両へと行う通信を理解することで、少なくとも幾つかの実施形態において車両１００、１０５などを誘導及び監視する中央サーバの動作は、より明らかになる。次に図４を参照すると、中央サーバ及びその入力の一部を、簡略化したブロック図に示す。中央サーバ４００は、単独で、又は各車両４１０，４２０に搭載されたシステムとの組み合わせで、４３０Ａ～ｎに示すように、車両位置、目的地、積荷、天候、交通状況、車両タイプ、トレーラタイプ、リンク付けの直近履歴、燃料価格、運転者履歴、及びその他の要素の１つ以上に関する知得に基づいて、隊列走行のため又は単に運行改善のための決定及び提案を行う。中央サーバ４００及び車載システムは、双方とも、ディスプレイ４４０を介して運転者と通信する。これらの通信は、リンク付けの提案、道路状況、気象問題、更新された経路情報、交通状況、潜在的車両保守問題、及び他データのホストを含むことができる。場合によっては、リンク付けの機会は、それ自体、中央サーバから独立して示されてもよい。このような場合、ペアリングが認識された後、その潜在的ペアリングは少なくとも車載システムに通信され、必ずしも全てではないがほとんどの場合、中央サーバにも通信される。中央サーバ又は車載システムのいずれかは、そのペアがリンク付けに適していないと結論を下すことができ、ボックス４５０で示すように、リンク付けは無効とされる。
【0030】
２０１４年３月１７日に出願され係属中のＰＣＴ出願ＰＣＴ／ＵＳ１４／３０７７０に記載のように、リンク付けの機会は、車両の移動中に決定することができるが、例えばトラックストップ、休憩所、計量所、倉庫、デポ（発着所）などに１以上の車両が停車中に決定することもできる。これはまた、車隊（フリート）管理者又は他の関連する人員によって、事前に算出することもできる。また、それは、出発時又は数時間前若しくは数日前に予定してもよいし、道路にいる間に、その場その場で、システムの連携機能性支援の有無によらずに、行ってもよい。
【0031】
上述したように、システム全体のインテリジェンスの多くは、中央サーバ又は各車両の車載システムによるものとすることができる。しかしながら、車載システムは、車両の運行を制御する特定の機能を含む。例えば、大型トラックのみならず大抵の車両の場合、車載システムは、即時運行条件を反映する種々の入力を受け取り、中央サーバから受信したプラスされる関連情報に基づいて、少なくとも加速度／速度及び制動について車両を制御する。したがって、図５Ａに示すように、車載システムの実施形態は、例えば車載レーダーユニット５０５、ビデオカメラ５１０、及びライダーユニット５１５からの入力を、接続部（ａ）（必ずしも必須ではないが、代表的にはＣＡＮインタフェース）を介して受信する、制御プロセッサ５００を備える。制御プロセッサは、これらユニットそれぞれを環境設定し、データを受信することができる。無線にし得る慣性測定センサ又はジャイロ５２０への接続部（ｂ）は、制御プロセッサに、１、２又は３軸の加速度情報のみならず１、２又は３軸に関する回転速度情報を与える。幾つかの実施形態では、加速度計をジャイロに置き換えることができるが、ジャイロは、一般的には例えば回転速度のために使用される。（Ｃ）で示し、また図５Ａの下部に詳細を拡張して示される複数のデータリンク５３０は、先行トラック１００の関連する特性に関する情報を、その加速度を含めて提供するか、又は同一若しくは類似の情報を後続トラック１０５に提供するために使用される。バス（ｄ）に接続された制動バルブ及びセンサ５５０は、ブレーキ圧力に関するデータを提供し、制御プロセッサ５００からのコマンドを介して圧力を加えるのに使用される。加速装置（アクセル）コマンド５５５は、アナログ電圧又は通信信号（ＣＡＮ又はその他）を介して送信される。
【0032】
制御プロセッサは、センサ情報、ＧＵＩからの情報、及び任意な他のデータソースを処理し、その時点における（カレント）目標（例えば先行車両までの一定の追従距離を維持すること）を達成するための一組のアクチュエータコマンドの適正セットを決定するための演算を実行する。図５Ａに示すように、データリンクは、セルラー、ＤＳＲＣなどのような１つ以上の無線リンク５３５を含む。データリンク５３０はまた、参照符号５４０で示す車両からの入力を含み、この入力は、典型的には、車両のエンジン制御ユニット又は参照符号５４５で示すＥＣＵ（典型的には自動車製造業者によって提供される）を経て送信される。実施形態に応じて、制御プロセッサは、種々の入力装置と双方向に通信する。
【0033】
図５Ｂは、本発明の車載システム又は車両制御ユニットの動作をさらに説明する図であり、一実施形態において、２つのリンク付けした（リンク済み）車両における車両制御ユニット間の一般的なフローを示す。実施形態に応じて、典型的には２つの動作モードが実装される。第１モードでは、前方トラックの制御ユニットは、後方トラックの制御ユニットにコマンドを発行する。これらコマンドは、一般的には順守されるが、例えば安全のためなどの適切な状況においては、無視される。第２モードでは、前方トラックの制御ユニットは、第２のトラックにデータを送り、先行トラックによって検出されたデータ及び先行トラックがとった行動を、追従するトラックに通知する。次に、第２トラックの制御ユニットは、前方トラックからの当該データに従って、適切な行動をとるように動作する。ボックス５６０に示すように、後続の又は追従するトラックは、その動作に関するデータを、前方又は先行のトラックに送信する。ボックス５６５において、先行トラックは、追従する（後続）トラックからデータを受信し、動き及び／又は外部物体及び／又は通信入力を検出する。次に、先行トラックは、ボックス５７０に示すように、先行トラックとしての行動を決定し、第１モードで動作している場合は、ボックス５７５に示すように、後方トラックに対する行動も決定する。次に、第１モードで動作しているか又は第２モードで動作しているかに応じて、先行トラックは、（ボックス５８０で）追従トラックにコマンドを送信する（第１モード）か、又は（ボックス５８５で）追従トラックにデータを送信する（第２モード）。第１モードで動作している場合、第２トラックはコマンドを受信し、ボックス５９０でそれらのコマンドを実行し、第２トラックはまた、幾つかの実施形態においては、このようなコマンドの無視を選択してもよい。第２モードで動作している場合、第２トラックはボックス５９５でデータを受信し、どの行動を実施するかを決定する。双方の制御部（ユニット）の制御プログラムは、幾つかの実施形態では同じであるため、ほとんどの場合、第２トラックの制御は、結果的に、動作モードにかかわらず同一になる。最後に、第２トラックは、６００で示すように、どの行動をとるかについて前方トラックに通信するため、各トラックは他のトラックの状態を知得する。制御プログラムは、全ての実施形態において、双方の車両について同じである必要はないことは、当業者に明らかであろう。
【0034】
少なくとも幾つかの実施形態では、上記処理は、例えば毎秒１回のように、ほぼ連続的に繰り返され、各トラックが他のトラックの現在状態を保有するとともに、ＮＯＣが双方の現在状態を保有するため、幹線道路において密集隊列フォーメーションで運行しているときでも、各トラックの安全かつ予測可能な運行確保を支援する。
【0035】
車載システムの制御プロセッサに対する前述の入力に加えて、幾つかの実施形態では、２０１４年３月１７日に出願されたＰＣＴ出願ＰＣＴ／ＵＳ１４／３０７７０に詳細に記載したように、制御プロセッサ又は別個の警告及びアラートプロセッサに対する入力として、種々の警告及びアラートを行うことができる。同様に、同ＰＣＴ出願に記載のように、制動チェックの処理を実行して、車両のブレーキが正常に機能していることを確認するとともに、先行する車両を決定することを支援することができる（他の全てのパラメータが同じとすれば、通常は良好なブレーキを備えた車両が追従車両として位置付けられる）。
【0036】
少なくとも幾つかの実施形態では、信頼性の高い安全な隊列走行は、ＮＯＣと車載システムとの間の協働による。したがって、図６を参照すると、ＮＯＣによって提供される機能と、車載システムの動作との間の相互作用が、高いレベルで求められる。隊列走行を確立するために、ＮＯＣ６０１（少なくとも幾つかの実施形態ではクラウド上に存在する）は、簡略化すると、リンク探知機能部６０５、リンク認可機能部６１０、及びログ記録機能部６１５を含む。これら機能部の出力は、通信ゲートウェイ６２０を経て、車載システム６２５に伝達される。車載システム６２５は、ＮＯＣ６０１から、リンク付けの可能性を有するとＮＯＣが判定した車両ペアリングに関する情報を受信し、それから参照符号６３０で示すように、適切な時点でリンク付け承認に関する情報を受信する。また、車載システムは、参照符号６３５で示すように、ハザード注意報を受信し、これは一般に、予測される走行経路に基づく車両に対するハザードを含む。
【0037】
車載システム６２５は、機能的な観点から、１つ以上の電子制御ユニットすなわちＥＣＵを備え、図７Ａに関連してより具体的に説明するように、このＥＣＵは種々の機能を管理する。説明を簡単にするために、図６においてはデータＥＣＵのみを示し、このデータＥＣＵは、メッセージの取扱い処理及び通信の管理を行う。ＥＣＵの機能は別個の装置に実装することができ、他の機能も提供するＥＣＵに統合することもできることは、当業者には明らかであろう。本明細書に記載したようなＥＣＵは、ほとんどの場合、コントローラ又は他のプロセッサとともに、適切なストレージ及び本明細書により詳細に記載したような（特に図７Ａから始まる）タイプのプログラム命令を実行する他の補助装置を含むことは明らかであろう。一実施形態では、データＥＣＵ６４０は、ＷｉＦｉ、ＬＴＥ、及びＢｌｕｅｔｏｏｔｈ（登録商標）インタフェース（それぞれ６４５、６５０、及び６５５により示す）を管理して、隊列走行コントローラのＥＣＵ機能部６６０と双方向通信する。次にこの隊列走行コントローラのＥＣＵは、ＤＳＲＣリンク６６５を介して他の隊列走行の候補及びメンバーと双方向通信して、運転者のディスプレイ６７０にデータを出力する。
【0038】
少なくとも幾つかの実施形態では、車載ＥＣＵの機能部は、隊列走行コントローラ６７５、ログコントローラ６８０、運転者インタフェース６８５に接続する車両のＣＡＮバス７３０と通信する。このＥＣＵはまた、車両の位置及び健全度（health）の報告、すなわち「ブレッドクラム」を、参照符号６９７で示すように、１秒にほぼ１回の割合で、ＮＯＣに戻す。さらに、例えばＷｉＦｉのような、好適な高帯域かつ低コストのデータリンクが応対可能なとき、ＥＣＵは、参照符号６９９で示すように、そのログをＮＯＣにダンプする。実施形態に応じて、ログは、ビデオ情報を含めてあらゆるデータを有することができる、又はそのデータのサブセットを有することができる。例えば、一実施形態では、ログのダンプは、ＳＡＥ Ｊ１９３９のデータ、レーダー（ｒａｄａｒ）、ライダー（ＬＩＤＡＲ）及びビデオデータにおける幾つか又は全部のデータ、幾つか又は全部のＧＰＳデータ、幾つか又は全部のＤＳＲＣデータ、及び双方の無線システムのための幾つか又は全部の状態データを含めて、幾つか又は全部のＣＡＮバスデータを有することができる。このようなデータの全てはＣＡＮバス上で送信されず、その代わりにイーサネット接続、ポイントツーポイント接続、又は他の適切な通信リンクを介して通信できることは、当業者に明らかであろう。
【0039】
図７Ａは、本発明によるシステムの実施形態を示す図であり、ハードウェア層、及び本発明の機能をハードウェア層に実行させるソフトウェア層を示す、簡略化した形式の概略的ブロック図である。具体的には、車両監視及び制御システム７００は、以下に図７Ｂつきさらに説明するように、１つ以上のプロセッサ及び関連するハードウェアを備えている。システム７００は、チャネル７０５Ａを介して、車両制御層７０５にデータを提供し、及び車両制御層７０５からの命令を実行し、またさらに、チャネル７１０Ａを介して、隊列走行監督層７１０にデータを提供し、及び隊列走行監督層７１０からの命令を実行する。さらに、隊列走行監督層７１０は、チャネル７１０Ｂを介して車両制御層７０５との通信もする。層７０５及び７１０は、ソフトウェア層であり、システム７００として示すハードウェア層のハードウェア上で実行されることは、当業者には明らかであろう。
【0040】
図７Ｂからは、車両監視及び制御システム７００を含むハードウェアコンポーネント、並びに、これらとソフトウェア層７０５及び７１０との相互動作をより明らかにすることができる。より具体的には、一実施形態において、車両監視及び制御システムは、車両制御層７０５及び隊列走行監督層７１０の制御の下で、各種センサからの入力を受信して、各種アクチュエータ及び他の装置（例えば運転者ＨＭＩ並びにセル及びＤＳＲＣ送受信機を含む）に出力を提供する、１つの以上の電子制御ユニット（ＥＣＵ）を備える。システム７００はまた、接続７１５Ａを経て運転者７１５と通信する。システム７００はまた、通常、セルタワー（携帯電話基地局）７２０Ａで示すような無線のリンクを介して、ＮＯＣ７２０と通信する。
【0041】
本発明の少なくとも幾つかの実施形態において必要な全ての機能は単一のＥＣＵでも実行できるが、最近の車両のほとんどは、それぞれ専門機能が割り当てられている複数のＥＣＵを有する。したがって、図７Ｂの実施形態に示すように、複数のＥＣＵ７２５Ａ～７２５Ｎは、システム７００のコアを構成し、バス７３０上で互いに通信し、少なくとも幾つかの実施形態では、バス７３０は、ＣＡＮバスとしてもよいが、接続される特定のデバイスに応じて、バス７３０は異なるタイプのバスとしてもよいし、ポイントツーポイント（point-to-point）接続としてもよい。一実施形態では、ＥＣＵ７２５Ａ～７２５Ｎ（単に代表的なものであり、網羅的なリストを表すことを意図しない）は、ビデオセンサ７３５、ＧＰＳデバイス７４０、トレーラセンサ７４５、ハザードセンサ７５０、及びトラクタセンサ７５５からの入力を受信する。実施形態に応じて、センサを少なくしてもよいし、多くしてもよいし、異なるセンサを使用してもよい。バス７３０によれば、ＥＣＵは、トラクタアクチュエータ７６０に制御信号を送信することができ、ＨＭＩ７６５を介して、運転者にデータを提供する、及び運転者からの入力を受信することができ、またセル送受信機７７０及びＤＳＲＣ送受信機７７５のそれぞれを管理することができる。さらに、バス７３０は、各種のセンサ及びＥＣＵからのデータをデータ記憶装置７８０に格納できるリンクを提供する。種々のＥＣＵ７２５Ａ～Ｎは、とりわけ、レーダーＥＣＵ７２５Ａ、制動／安定性ＥＣＵ７２５Ｂ、車間距離適応走行制御（アダプティブ・クルーズ・コントロール）ＥＣＵ７２５Ｃ、隊列走行ＥＣＵ７２５Ｄ、データ収集ＥＣＵ７２５Ｅ、ＨＭＩのＥＣＵ７２５Ｆ、ＤＳＲＣのＥＣＵ７２５Ｇ、エンジンＥＣＵ７２５Ｈ、ダッシュボードＥＣＵ７２５Ｉ、シャーシＥＣＵ７２５Ｊ、変速機ＥＣＵ７２５Ｋを含むことができる。参照符号７２５Ｍで示すように、他のトラクタＥＣＵを実装してもよいし、参照符号７２５Ｎで示すように、他のトレーラＥＣＵを同様に実装してもよい。なお、車両制御層及び隊列走行監督層を含むソフトウェアを、そのようなＥＣＵのうち１つ、幾つか又は全部にわたって分散させ得ることは、当業者に明らかであろう。
【0042】
次に図８Ａを参照することにより、隊列走行監督層、並びに、この隊列走行監督層と車両監視及び制御システム７００との相互作用がより詳細に理解できる。図８Ａは、システム７００を除いて、本発明の実施形態の様々なソフトウェアの機能を示している。参照符号７６５で示す運転者ＨＭＩの機能は、車両の運転者と直接やりとり（対話的作用）をして、システム７００のみならず隊列走行監督層からの運転者情報を運転者に提示し、例えばリンク付けするパートナーの選択、又はリンク付けのオファー受けた運転者による受諾のような、運転者のコマンド及び選択のための入力機構として機能する。
【0043】
ＮＯＣ通信マネージャ８００は、車両とＮＯＣとの間のセキュアな通信リンクを確立及び維持し、ＮＯＣに対してメッセージを信頼性高く送受信するための機構を提供する。ＮＯＣ通信マネージャは、車両監視機能部８０５、ハザード監視機能部８１０、ソフトウェア更新管理機能部８１５、及びＮＯＣ自体からの入力を受信する。
【0044】
車両監視機能部８０５は、ＮＯＣ７２０からのリクエストに基づいて、バス７３０に接続された任意のソースから、車両の状態をサンプリング及びフィルタリングする。ＮＯＣ７２０は、どの情報を提供すべきか、及びどの間隔又は頻度で情報を提供すべきかを特定し、またさらにデータがＮＯＣに返送される前にどのように処理すべきかを特定する。代案として、ローカル処理をＮＯＣに代替してもよい。ハザード監視部８１０は、バス７３０上で車両障害を「聴取（listens）」して、関連する車両障害をＮＯＣに通信する。ハザード監視部８１０はまた、ＮＯＣからのハザードアラートを受信し、また車両状態及び環境条件を含む入力に基づいて、隊列走行の承認を上書きするか否かについて局所的決定を下す。ハザード監視部８１０は、承認管理機能部８２０に承認の上書きを提供し、またＨＭＩサービス機能部８４０を介して運転者にハザード警告を送信する。ソフトウェア更新マネージャ８１５は、バージョンの問合せに応答して、車両上でソフトウェアをリモートでアップグレードし得る機構を提供する。
【0045】
ハザード監視部は、計画されたリンク付けを否定する、隊列走行の距離を調整する、あるいは認証の基になる条件を変更する、のいずれかの条件が検出された場合に、ＮＯＣからのリンク付け承認をローカルで上書きすることができる。このような条件は、典型的には、車両状態の問題又は有害環境条件を含む。ハザード監視部の上書きが車両障害又は他の状態問題に基づく場合、その障害又は問題もまたＮＯＣに通信されるため、ＮＯＣは、当該車両を取り込むその後のリンク付けを評価するときにそれらを考慮に入れることができる。ハザードの上書きに至る他の条件は、例えば他の車両が検出する気象、交通又は道路状況のような、当該車両自体の外部での問題に起因し得る。実施形態及び特別な状態に基づいて、外部問題についての情報は、他の車両によってＮＯＣに通信されてから、リンク付け承認を受信する車両に送信することができる、又は外部問題についての情報は、他の車両から、リンク付け承認を受信する車両に直接通信することができる。いずれの場合も、車載システムはハザード情報をハザード監視部に伝達し、このハザード監視部は適切なアクションを取って、承認されたリンク付けをキャンセル又は変更する。
【0046】
ハザード監視部からの上書きがない場合、承認マネージャ８２０は、ＮＯＣ通信マネージャ８００を介してＮＯＣからの、車両位置追跡機能部８２５からの絶対位置、速度、及び進路の情報（順番にシステム７００から受信）と組み合わせた承認パケットを受信し、また解釈して、以下さらに詳細に説明するように、ＮＯＣが提案する隊列走行パートナーの近接度を判定するのに役立てる。承認マネージャは、リンク付け承認状態メッセージを、遷移時間（すなわち隊列走行パートナーが近接しており、リンク付けが開始できる時点）とともに、システム７００に送信する。承認マネージャは、さらに、選択された隊列走行パートナーの識別（同定）を車両間通信管理機能部８３０に送信し、また幾つかの実施形態では、選択された隊列走行パートナー、その位置、及びリンク付け誘導に関する情報を、アプローチ誘導機能部８３５に送信する。
【0047】
車両間通信マネージャ８３０は、システム７００にセキュリティ認証情報を供給する（典型的には通常ＤＳＲＣ（Digital Short Range Communication）リンクを介して通信される）ことで、隊列走行パートナー同士の相互承認を管理する。アプローチ誘導を有する実施形態では、アプローチ誘導機能部８３５は、２つのモードで動作する。パートナー車両がＤＳＲＣ範囲外であるとき、アプローチ誘導機能部８３５は、ＮＯＣからアプローチ誘導を直接行う（このような誘導が応対可能である場合）。次に、隊列走行パートナーとのセキュアな通信リンクが確立された後、少なくとも幾つかの実施形態においては、ＤＳＲＣリンクを介して、アプローチ誘導機能部は、パートナー車両によって提供される位置及び速度情報とともに、例えばシステム７００から受信したレーダー追跡状態及び車両位置追跡機能部８２５からのデータのようなローカルの車両追跡情報を用いて、ＮＯＣとは独立してローカルのアプローチ誘導を提供する。実施形態によっては、マッピング、ビデオ及びレーダー入力、車線（レーン）整列、並びにシステムから入手可能である任意な他のデータの一部又は全部を運転者に提供して誘導を行うこともできるし、前述のデータのいずれも提供せずに誘導を行うこともできる。幾つかの実施形態では、前述のようなデータを運転者が自分で使用して隊列走行のために車両を位置付けて、当該位置において隊列走行コントローラが関与して、隊列走行の所望の車間距離に車両を移動する。
【0048】
ＨＭＩサービス機能部８４０は、車両の運転者と相互にやりとりするセマンティック層を提供し、車両（ソフトウェア層を含む）からの状態情報を、運転者に関連するメッセージに変換する。さらに、ＨＭＩサービス機能部は、運転者からの入力を処理する。ＨＭＩサービスモジュールは、提示データを、運転者ＨＭＩ上で運転者に表示するための車両のハードウェア（典型的には運転者のコマンド、選択、及び他の入力を容易に受け付けるタッチスクリーンディスプレイ）に提供する。後続車両の運転者のために、このディスプレイは、典型的には、先行車両の前方カメラのビデオストリームを含めた表示を行う。
【0049】
図８Ｂを参照して、上述したソフトウェア機能を、システム全体のソフトウェア機能の観点から説明する。図８Ａに示すように、車両間通信機能部８３０（ＤＳＲＣ通信、及び以下に図１７Ａで説明するような、着信車両シグネチャーコマンドの管理を含む）は、ＨＭＩサービス機能部８４０（参照符号７６５で示す運転者機能部にインタフェースを提供する）にメッセージを送信する。運転者インタフェース７６５からの入力は、運転者による隊列走行パートナーの選択に基づくリンク付けリクエストを含む。当然のことながら、多くの経路上において隊列走行パートナーになり得る候補は複数存在し、したがって運転者には複数の選択肢がある。しかしながら、幾つかの実施形態では、及び幾つかの車隊に関しては、隊列走行パートナーの選択は、例えば複数のトラックが日常的に同一の又は近隣の目的地まで同一経路を辿るような、車隊運行によって決定される。そのような場合、運転者の選択肢は、リンク付けを受諾するか拒否するかのいずれかになる。
【0050】
ＨＭＩサービス機能部は、さらに、運転者から受信した入力イベントを監督層８５０に供給し、また監督層から提示データを受信する。ＨＭＩサービス機能部は、一実施形態では、ＧＵＩ８４０Ａ、ビデオフィード８４０Ｂ、物理的入力８４０Ｃ、及びオーディオ入出力８４０Ｄを含む。監督層は、リンク管理機能８５０Ａ、セルラー通信管理８５０Ｂ、並びにデータ記憶及びログ記録８５０Ｃを含む。
【0051】
監督層は、さらに、リンク承認及び車両シグネチャーコマンドを隊列走行コントローラ機能部８５５に送信し、ＤＳＲＣ状態、障害、及びレーダー状態を含む、コントローラの状態メッセージを受信する。隊列走行コントローラ８５５は、間隔（ギャップ）調整８５５Ａ、質量推定８５５Ｂ、ブレーキ健全性監視８５５Ｃ、隊列走行状態８５５Ｄ、及び障害対処８５５Ｅを含む、種々の機能を有する。間隔調整は、先行車両から後続車両までの距離の設定、又は、先行車両の後部から後続車両の前部までの間隔における時間の設定を含む。いずれの場合も、目的は、その距離が容認可能な燃料経済上の利益を得つつ、同時に双方の車両の安全性を確保するのを確実にすることである。
【0052】
上述の機能を実行するために、隊列走行コントローラは、種々のトラクタ機能（トラクタセンサ機能部８６０で概略的に示す）の状態を表すトラクタからの入力を受信する。一実施形態では、これらの機能は、ライダデータ８６０Ａ、視覚データ８６０Ｂ、レーダー８６０Ｃ、ＧＰＳ位置８６０Ｄ、ホイール（車輪）速度８６０Ｅ、ペダル位置８６０Ｆ、エンジン温度８６０Ｇ（エンジンブロックから、エンジン室から、又は他の好適な場所のうちのいずれかから感知される）、ステアリング８６０Ｈ、慣性計測８６０Ｉ、ブレーキ圧８６０Ｊ、気圧計及び関連する天候の感知８６０Ｋ、及び、このように感知されたデータの組合せ（センサ統合８６０Ｌとして示す）を含む。幾つかの実施形態においては、例えば燃料レベル又は残りの走行距離のような他のデータ、並びに感知した車両シグネチャーデータ（以下に図１７で詳述する）も提供される。幾つかの実施形態において、トラクタセンサ機能部は、車両間通信モジュールとの間と双方向に通信し、車両シグネチャーに関するデータの何らかの処理がトラクタセンサ機能部に関連するＥＣＵ内で生ずる。
【0053】
隊列走行コントローラは、質量、位置、速度、トルク／ブレーキ、ギア、及び障害について、車両間通信モジュール８３０と双方向で通信する。より具体的には、コントローラ８５５は、質量、位置、速度、トルク／ブレーキの状態、ギア、及び障害を含む、他の車両に関するデータを、ＤＳＲＣリンクを介して受信する。隊列走行コントローラは、これらの入力を使用して、上述のように監督層に状態データを提供し、またさらに、トルク及びブレーキのコマンド、並びにギアを提供する。ギアセンサがない場合、マニュアル変速機のために、エンジン速度及びタイヤ回転速度に基づいて、ギアの選択を計算することができる。オートマチック変速機のギアは、変速機ＥＣＵから直接感知することができる。
【0054】
隊列走行コントローラ８５５は、さらに、トラクタ作動機能部８６５から状態及び障害の情報を受信し、一実施形態では、これら情報としては、機能部８６５Ａ～８６５Ｆにおけるステアリング、スロットル、シフト、クラッチ、及びブレーキの情報、並びに、例えばジェイクブレーキのような他の運転者制御行動に関する情報を含む。少なくとも幾つかの実施形態では、運転者（機能ブロック７６５）は、このような入力の全てをトラクタ作動ブロック８６５に供給することができるが、リンク付け中及び隊列走行としてリンク付け済みの状態中、ブレーキ及びスロットルは、隊列走行コントローラ８５５の制御の下にある。幾つかの実施形態では、隊列走行表示８７０Ａを含むトラクタ表示機能部８７０が設けられ、このトラクタ表示機能部８７０は、トラクタに位置付けられて隊列走行に近接する他の車両に視認可能な物理的インジケータを制御する。物理的インジケータは、典型的には、隊列走行が形成されるとき有効化され、またリンク付けプロセス中に有効化することもできる。
【0055】
次に、図９につき説明すると、車両において生ずるデータ処理がよりよく理解できるであろう。車両が始動すると、ステップ９００で示すようにハードウェアが起動する。データバスハンドラは、デフォルトの設定を使用するか、又はＮＯＣから受信した設定が有効であれば当該設定を使用して、ステップ９０５でシステムに登録される。ステップ９１０において隊列走行承認「リスナー」が始動され、その機能はＮＯＣから隊列走行の承認メッセージを聴取（listen）することである。
【0056】
次にステップ９１５において、最新の車両イベントデータが処理され、その後ステップ９２０において、ＮＯＣから隊列走行の承認通知を受信したか否かがチェックされる。隊列走行の承認通知が受信された場合、ステップ９２５において、例えばＡＰＩなどのソフトウェアインターフェースによって承認記録がコントローラに記入（ポスト）される。隊列走行の承認通知が受信されない場合、ステップ９３０において、ＮＯＣから環境設定変更を受信したか否かがチェックされる。新規環境設定が受信された場合、新規環境設定が実行されて、「ブレッドクラム」メッセージにおいて車両から収集され、またＮＯＣに報告されるデータが変更され、再起動信号が送信されてステップ９０５に戻り、ここでデータバスハンドラが新規環境設定に基づいて再登録される。
【0057】
新規環境設定が受信されない場合、処理はステップ９４０に進み、ここで位置及び状態の情報がＮＯＣに送信されることになる十分な時間が経過したか否かをチェックする。十分な時間が経過していない場合、処理は９１５に戻る。十分な時間が経過した場合、ＮＯＣに位置及び状態の情報すなわち「ブレッドクラム」メッセージが送信される。このようなブレッドクラムメッセージがＮＯＣに送信される頻度は、少なくとも幾つかの実施形態では、ＮＯＣから受信した環境設定パラメータによって定義され、当該パラメータは、ＮＯＣにメッセージの一部として送信すべきイベントデータも定義する。少なくとも幾つかの実施形態では、「ブレッドクラム」のメッセージは、例えば１秒に１回のように定期的にＮＯＣに報告される。さらに、適宜、「私は隊列走行に応対可能である（I am available for platooning）」のメッセージが定期的にＮＯＣに送信される。
【0058】
図１０は、ＮＯＣと車両との間の接続が管理される処理の実施形態を説明する図である。ＮＯＣのサービスは、ステップ１０００で示すように開始し、ＮＯＣは、ステップ１００５で示すように、既知のポート上で車両からの接続を待機する。次にＮＯＣは、ステップ１０１０で示すように、トラックを認証してセキュアなセッションを開いてから、ステップ１０１５で示すように、メッセージブローカ機能で発行者メッセージを生成する。次に、ステップ１０２０で発行者スレッドが作成（スポーン）され、その時点で、発行者の接続及びネットワークの接続がスレッドに渡される。スレッドは、ステップ１０２５で示すように、車両からのメッセージ、例えば「ブレッドクラム」メッセージ又は「私は隊列走行に応対可能である（I’m available for platooning）」メッセージを聴取する。ステップ１０３０で示すように、車両からメッセージを受信した後、処理はループし、またステップ１０２５でＮＯＣは聴取モードに戻る。所定の時間ウィンドウ内にメッセージが発生しない場合、ステップ１０３５に示すように、スレッドは終了する。
【0059】
発行者スレッドの作成に続いて、また基本的には当該スレッドの実行に並行して、ステップ１０４０で示すように、メッセージブローカによる加入者メッセージを生成する処理が行われる。次に、ステップ１０４５において加入者スレッドが作成され、ステップ１０５０で示すように、加入者接続及びネットワーク接続が、加入者スレッドに渡される。ステップ１０５５で待ち行列メッセージがチェックされて、待ち行列メッセージがあればステップ１０６０で車両に送信される。待ち行列メッセージがない場合、又は待ち行列メッセージがすでに送信された場合、処理はステップ１０６５に進み、メッセージが車両に発行されるのを待機する。次に、処理はステップ１０６０に戻る。ステップ１０６０でトラックにメッセージが送信できなかった場合（典型的には接続に失敗した結果）、ステップ１０７０でメッセージが待ち行列に入れられ、またステップ１０７５でスレッドは終了する。
【0060】
次に、図１１Ａ及び図１１Ｂを参照して説明すれば、連携及びリンク付けにより隊列走行を形成する処理をよりよく理解できるであろう。図１１Ａは、参照符号１１００で全体的に示すように、連携及びリンク付けの機能の一実施形態を示す。ステップ１１０１で処理が開始すると、１組の隊列走行可能ペアリングのセットが受信される。当該ペアリングのセットは、少なくともいくつかの実施形態では、ＮＯＣから受信され、潜在的隊列走行パートナーのリストを含む。他車両の利用可能性、又は車隊の優先度に基づいて、隊列走行を受諾するか拒否するかの択一的な選択のみが運転者に提示されてもよい。代案として、いくつかの実施形態では、又は幾つかの車両に関しては、隊列走行可能なパートナーの識別がローカルで生成されてもよい。いずれの場合も、リンク付けするパートナー間でセキュアな通信を可能にする承認キーが提供される。そして、ステップ１１１０で、運転者又はシステムのいずれかが、隊列走行パートナーとしての連携に応対可能な車両を識別し、ステップ１１２２で示すように、隊列走行オファーが通信され（いくつかの実施形態において自己受諾メッセージによって示される）。いずれのアプローチにおいても、他車両（「遠くの」車両）は、ステップ１１２４で受諾し、これはステップ１１３０で示すように可能なリンク付けのための連携にそのペアが同意したことを意味する。車両の位置、積荷の重量、車載機器、及び他の要因に基づいて、リンク付け範囲内の車両は、後続車両がリンク付けに応対可能であるものとして（ステップ１１４２）又は先行車両がリンク付けに応対可能であるものとして（ステップ１１４４）識別することができる。これらのどちらでもない場合、システムは連携モードに戻る。連携に応対可能な後続車両がリンク付けを受諾し（ステップ１１５２）、また自車両もリンク付けを受諾した（ステップ１１５３）後に（この順序は任意）、リンク付けが開始される。リンク付けが完了すると、これら車両はリンク付け済みとなる（ステップ１１６２）。同様に、連携応対可能な先行車両がリンク付けを受諾し（ステップ１１５４）、また自車両もリンク付けを受諾した（ステップ１１５５）後に、リンク付けが開始される。リンク付けが完了すると、ステップ１１６４で示すように、これら車両はリンク付け済みとなる。
【0061】
どの車両がリンク付けに適切であるかを適正に決定するためのみならず、どちらの車両を先行車両とし、またどちらの車両を後続車両にすべきかを適正に決定するためには、所定の車両特性が重要になる。一態様を図１１Ｂに示し、この態様において、エンジントルク及び加速度の特性はステップ１１６５において車両の内部で収集され、また車両の質量はステップ１１７０で算出される。この後、その情報（ローカルに又はＮＯＣで処理可能）は、ステップ１１７５で示すように、車両間のギ間隔を調整するため、又はアルゴリズムを変更するために使用される。さらに、当該データは、ステップ１１８０においてリンク付けすべきか否かを選択するために使用されてもよいし、少なくとも幾つかの実施形態においては、他の要因を考慮してもよい。他の要因は、例えば、隊列走行の提案された距離、持続時間、一日における時間、就業時間、及び関連する制約、燃料レベル及び走行距離、再給油可能性、サービスレベル同意事項（他の使用又はメンテナンスのため車両が所定時刻に所定目的地に存在する必要性）、運転者の食事、息抜き休憩、運転者の満足度、運転者の賃金、並びに、交通規則及び規制等があり得る。リンク付けが行われる場合、これらの要因のうち１つ又はそれ以上は、どの車両を先行車両にすべきかの決定についての情報を与える上で支援することができる。
【0062】
隊列走行を形成する前に、また潜在的な隊列走行パートナーを識別できる前であっても、隊列走行に応対可能な車両の経路は少なくとも部分的に既知でなければならない。このことは、図１２に示すように、車両の走行予測を行うことによって達成できる。その処理は、ステップ１２００において車両Ａとして示す車両の位置情報を受信することにより開始する。当該位置情報は、経度／緯度情報、又は座標対に加えて速度及び進行向き、又は一連の座標対若しくは座標対の軌跡を含むことができる。このような情報を提供する上で、前述の図に記載したような、ＧＰＳ装置が好適である。
【0063】
図１２の処理は、ステップ１２０５でチェックを行って車両Ａの経路が既知であるか否か決定して続行する。多くの場合、例えば大型商用トラックのような車両は、頻繁に繰り返し往来する経路、又は車隊管理者若しくは他の監督者によって設定される経路を走行する。結果として、多くの場合、特定の車両経路は、既知であってデータベース（典型的にはＮＯＣにて維持される）に記憶され、また少なくともいくつかの例において、ローカルでも応対可能である。しかしながら、車両Ａの経路が既知でない場合、特許文献である２０１５年２月１１日出願の米国特許出願第６２／２４９８９８号（U.S. Patent Application SN 62/249,898, filed 11/2/2015）に記載のように、ステップ１２１０で隊列走行に容認可能な近隣経路に対する検索が行われ、この特許文献は参照により全体が本明細書に組み入れられるものとする。
【0064】
ステップ１２１０で検索した後、ステップ１２１５でチェックを行って、車両Ａが使用するのに好適な隊列走行可能な経路が少なくとも１つ発見されたか否かを決定する。発見されない場合、ステップ１２２０で示すように、処理は当面停止する。しかしながら、ほとんどの場合、少なくとも１つの隊列走行可能な経路が同定される。このような場合、ステップ１２２５で示されるように、車両Ａは隊列走行可能な経路のどこで及びいつ合流を実現できるかが決定される。次に、ステップ１２３０において、車両Ａの経路の開始位置及び時間とともに車両Ａの予測速度を用いて、ＮＯＣ又は車両監視及び制御システム７００において、同定された経路上で車両Ａが特定の通過点に到着する最小及び最大の時間を算出する。これらの計算に基づいて、ステップ１２３５で示すように、ローカル又はリモートの処理において、車両Ａの走行予測が生成される。走行予測を生成するための上述の要因に加え、上述の図１１Ｂに関連して説明した１つ以上の要因も考慮されて、幾つかの実施形態における走行予測が策定される。図１３に関連して説明するように、少なくとも幾つかの実施形態ではＮＯＣに記憶されている走行予測を用いて、潜在的な隊列走行パートナーを検索することができる。
【0065】
車両Ａの経路が既知である場合、経路情報は既知の経路のデータベースからフェッチされる。次に、ステップ１２４５に示すように、車両Ａの位置が既知の経路と比較される。車両Ａが経路外にある場合、ステップ１２５０において、車両Ａが予測された経路にどこでまたいつ再合流できるかが決定される。ステップ１２５５において再合流が可能と判定された場合、処理はステップ１２３０に戻って、経路に再合流するための適切な誘導を車両Ａに提供し、続いて走行予測を生成する。車両Ａが経路に再合流不可能な場合、ステップ１２６０において処理は当面終了する。ステップ１２２０又はステップ１２６０のいずれかにおける終了は一時的なものであり、これはすなわち、車両Ａの経路上における位置が変化するとき、また少なくともいくつかの実施形態では車両がそれぞれ変更された位置をブレッドクラムメッセージによって報告するとき、隊列走行の可能性は変動するからである。
【0066】
車両Ａの走行予測が生成されると、潜在的隊列走パートナーを検索することができる。このような検索及びリンク付けの処理の一実施形態を図１３に示し、これは、図１１Ａに示した処理をいくつかの観点において詳細に示すものである。図１３の処理は、車両Ａから隊列走行リクエストを受信することで開始する。ステップ１３００に示すリクエストはプロセッサで受信され、このプロセッサは、少なくともいくつかの実施形態ではＮＯＣに位置するが、他の実施形態では潜在的には他のいずれの場所にも、例えば、１つ又はそれ以上の車両上にも位置し得る。次に、ステップ１３０５で示すように、例えば図１２の処理の結果のような走行予測が生成又は検索される。ステップ１３１０において、１３１５で示すＮＯＣのデータベースに記憶された走行予測の検索を行って、同様の経路についての他の記憶された予測を同定する。これら同様の経路に基づいて、潜在的隊列走行パートナーのリストがプロセッサで生成される。
【0067】
検索によって潜在的隊列走行パートナーが同定されないこともある。この場合、ステップ１３２０で行われるチェックの結果は「いいえ（Ｎｏ）」になる。このような場合、車両Ａの走行予測が、すでに記憶されていなければデータベース１３１５に追加され、隊列走行の可能性は現時点でないことが運転者に通知される。しかしながら、ほとんどの場合、１以上の潜在的隊列走行パートナーが識別（同定）されるため、ステップ１３２０におけるチェックの結果は「はい（Ｙｅｓ）」になる。この場合、ステップ１３３０に示すように、潜在的隊列走行パートナーのリストが車両Ａに送信される。実施形態に応じて、ステップ１３３５に示すように、隊列走行オファーを、識別された潜在的隊列走行パートナーＢ１、…、Ｂｎに一斉送信することもできる。場合によっては、ステップ１３４０に示すように、運転者がステップ１３３０で提供されたリストから選択し、車両Ａの運転者によって選択されたパートナーのみに隊列走行オファーが送信される。幾つかの実施形態では、潜在的ペアリングを車隊オペレータが決定して、運転者は１つの選択のみ受け取り、これを受諾することも拒否することもできる。ステップ１３４５で、車両Ａの選択が読み出され、これは、典型的には運転者によるコマンド又は運転者からの可聴コマンドによって示される。ステップ１３５０において、潜在的パートナー（例えば車両Ｂ１）からの応答を示す。ステップ１３５５において隊列走行オファーを受諾するためのチェックが行われる。受諾がない場合、ステップ１３２５で示すように、車両Ａの走行予測が、すでに記憶されていなければ現在の走行予測データベースに追加される。
【0068】
ほとんどの場合、車両Ａ及びＢ１は合意し、この場合処理はステップ１３６０に進む。ステップ１３６０で示すように、ほとんどの場合、図８Ａ～８Ｂに関連して上述したように、隊列走行の承認がＮＯＣによって送信されるとともに、車両Ａ及びＢ１が取るべきそれぞれのランデブー行動のためのアドバイスも送信される。また、ステップ１３６５で示すように、車両Ａ及びＢ１の走行予測は現在の走行予測のデータベースから削除され、これはすなわち、現時点でどちらも隊列走行に利用できないからである。いくつかの実施形態では、３以上の車両の隊列走行が許可され、この場合、車両Ａ及びＢ１の走行予測は、現在の走行予測のデータベースに維持される。
【0069】
隊列走行の承認に続いて、車両Ａ及びＢ１の位置は、隊列走行の形成中及びその後を含めて、ＮＯＣによって監視される。さらに、ＮＯＣは、交通、天候、工事等々の道路及びその他の状態を監視して、車両Ａ及びＢ１の隊列走行に関連する状態を識別し、両方の運転者にアラートを発するとともに、各車両における車載システムに対して関連するデータ又はコマンドを提供する。このような監視は、少なくとも、ステップ１３８０で隊列走行可能経路設定が完了するまで、又は、ステップ１３８５で運転者の１人が離脱するまで継続し、その後処理は１３９０で停止する。
【0070】
隊列走行として、すなわち、互いに比較的接近した（至近）距離内で半自動的に（又は幾つかの実施形態においては、自動的／自律的に）車両を運行させるプロセスは、概して上述したように数個のフェーズを有する。本発明は、説明を簡明にするため２台の車両の隊列走行に関連して説明するが、当業者には、２台の車両による隊列走行に限定されず、本明細書に記載のプロセス及びシステムにより、連携運行する任意な台数の車両とし得ることは理解できるであろう。より具体的には、隊列走行の開始には、車両が最終的に目標車間距離だけ離れるまで、スピードを出して互いに密に近接して運行する状態に車両をプルイン（引き入れる）又はその状態にすることを含む。プルインが完了した後、隊列走行としての連合移動は正常運行中に維持され、これには、同一車間距離を維持すること又は特定運行条件のための車間距離を調整することのいずれかが含まれる。さらに、正常運行は様々なアラートを受けることもあり、これらアラートのうち幾つかによれば隊列走行を解消させることもあり得る。隊列走行の解消には、車両の独立的運行を可能にする上で車間距離を十分増大させること、半自動的運行を終わらせること、及び少なくとも場合によっては車両の運行を運転者に引き継がせることが含まれる。他の実施形態においては、全自動運行を可能にし、また運転者引継ぎを全く必要としない。
【0071】
本発明隊列走行システムが用いる様々なプロセスを、ハードウェア及びソフトウェアの双方を含めて大局観に本明細書で先に詳述してきたが、図１４は、概括化したフロー図として、プルイン、通常運行、及び隊列走行解消に伴われる様々なプロセスの相互作用の実施形態を示す。とくに、ユーザー・インタフェース１４００は運転者入力を受け取り、また運転者に出力を供給する。入力プロセスは、パートナー選択及び隊列走行を開始する又は解消するいずれかのための開始／停止コマンドを含むことができる。出力プロセスは、光又は音声の形式のアラート又は警告に加えてビデオデータ又は他データの表示することを含む。さらに、ブロック１４０５で示すように、様々なプロセスは、ビークル・ツー・ビークル［Ｖ２Ｖ］（車両間）通信、前方車両から後方車両（又は複数後方車両）への一次的なデータ取得、及び隊列走行における先頭車両に後続する車両から前方又は他の車両へのデータ送信が含まれる。先に詳述したように、データは、例えば、エンジン及びブレーキの状態、速度、レーダー、又はＧＰＳのようなセンサデータ、前方車両運転者からのユーザー入力、並びにビデオ／音声通信を含むことができる。隊列走行における後続車両から他の車両に送信されるデータは、後続車両からのビデオ／音声データに加えて、とくに、速度コントローラがオン又はオフ状態であるか否かのデータを含めて上述のデータすべてを有することができる。
【0072】
メインプロセスをブロック１４１０で示し、このメインプロセスは、ユーザー・インタフェース・プロセス１４００及びＶ２Ｖプロセスブロック１４０５からの入力を受信する。メインプロセス１４１０は、さらに、Ｖ２Ｖブロック１４０５を介してセンサプロセスブロック１４１５及び前方トラック追跡（トラッカー）プロセスブロック１４２０からのデータを受信する。これに加えて、メインプロセスブロックは、速度及び間隔コントローラプロセス１４２５からのコマンドも受信し、この速度及び間隔コントローラプロセス１４２５は、さらに前方トラック追跡プロセス１４２０からのデータも受信する。速度コントローラプロセス１４２５は、少なくとも幾つかの実施形態において、図８Ｂに示す隊列走行コントローラ８５５の一部であり、車両間の所望間隔、車両間の所望相対速度、又は操縦中の異なる時点での２台の車両の組合せを達成するよう作用する。速度コントローラプロセスがトルク及び制動コマンド並びに他のアクチュエータコマンドを必要に応じて出力して、所望間隔又は所望相対速度、並びに幾つかの実施形態において、変速機ギア選択を達成する。センサプロセスブロック１４１５が管理するプロセスは、後方車両の前方におけるすべての車両であって、隊列走行における前方車両又は他の車両、並びに隊列走行の一部ではない、例えば、隊列走行車両間に割り込む車両のような車両を検出することを含む。さらに、センサプロセスは、例えば、ＧＰＳプロセスによって場所を決定することを含む。
【0073】
前方トラック追跡プロセス１４２０は、前方車両の後端部、例えば、車両がトラクタ（牽引車両）・トレーラ（被牽引車両）の組合せである場合の前方トラックのトレーラの後部を識別（同定）する。上述したように、このような識別は、少なくとも幾つかの実施形態において、双方のトラックにおけるセンサからのデータを融合すること、隊列走行車両における車間サイズ及び相対的側方位置を決定すること、また隊列走行車両間における又は心配となるほどに十分接近している他の車両を検出することが含まれる。これら機能のすべてがあらゆる実施形態で必要とはならず、例えば、側方位置検出は不要であり、近接車両も検出しないことがあり得る。速度及び間隔コントローラプロセス１４２５は、前方トラック追跡プロセス１４２０からのデータとともに、メインプロセス１４１０から受信した命令に基づいてエンジン及び制動コマンドを決定することを含む。それら命令としては、例えば、車両間の車間距離（「間隔（ギャップ）」）を詰めること、間隔を維持すること、及び間隔を増大させることが含まれる。さらに、速度コントローラプロセスは、エンジントルク及びエンジン遅延コマンドを車両のエンジン制御ＥＣＵに送信すること、並びにブレーキコマンドを車両のブレーキＥＣＵに送信することを含むことができる。或る実施形態において、それらコマンドの各々は、メインプロセス経由で発信される。メインプロセス１４１０は、システムコンポーネントを監視すること、ユーザー入力を処理すること、及び関連する速度コントローラをオン又はオフ状態にすることを含む制御システムプロセスを有する。さらに、速度コントローラがオン状態である場合、メインプロセスのブロックは、速度コントローラのプロセスが、間隔を詰める、間隔を維持する、及び間隔を増大させる（隊列走行を解消又は終了させることができる）ことを含む様々なコマンドを発生するようリクエストすることができる。
【0074】
次に図１５につき説明すると、図１４で概括的に示したプロセスの実施がより詳細に理解できるであろう。システムはステップ１５００で開始し、上述したように、ステップ１５０５で隊列走行パートナーの選択に進む。この後、ステップ１５１０で示すように隊列走行の準備をし、この準備は、ステップ１５１５で示すようにすべての隊列走行条件が確実に合致するか否かのチェックで始まる。すべての条件が合致しない場合、プロセスはステップ１５１０にループバックする。隊列走行を始める承認を求める。しかし、条件が合致する場合、プロセスはステップ１５２０に進み、隊列走行を始める承認を行う。１人又はそれ以上の運転者が、ステップ１５２５でのチェックでボタン押しのような行為をすることで示されるような隊列走行準備が完了している場合、プロセスはステップ１５３０で示すように、プルインプロセスを始める。運転者の準備が完了していない場合、プロセスはステップ１５１５にループする。幾つかの実施形態において、例えば、自律車両に関しては、運転者は存在せず、またプロセスは自律的に進行する。
【0075】
ステップ１５３０で示すように、プルインプロセスは、通常隊列走行運行のための目標間隔に到達するまで、隊列走行車両間の間隔を詰めることを含む。プルインは以下に詳細に説明する。或る実施形態において、目標間隔は、典型的には長距離輸送トラックに関して約９.１４４ｍ（約３０フィート）であるが、このような大型車両に関しては６.０９６ｍ（２０フィート）未満から１５.２４ｍ（５０フィート）を超える範囲にわたることができ、また他タイプの隊列走行車両に関してはその範囲から大幅に変動することができる。安全な車間距離の計算は、好適には、車両速度及び制動能力を考慮に入れ、また車両外部における天候、道路状況、他の要因も考慮することができる。プルインが開始された後、ステップ１５３５で車両が目標隊列走行間隔に近づいたか否かを決定するチェックを行う。もし「はい（Ｙｅｓ）」の場合、ステップ１５４０で示すようにその距離を維持する。もし「いいえ（Ｎｏ）」の場合、ステップ１５５０で、例えば、図１８Ａ～Ｃにつき説明する理由のうち１つ又はそれ以上の理由から隊列走行を解消するリクエストが存在するか否かを決定するチェックを行う。隊列走行を解消するリクエストが生じていなかった場合、プロセスはステップ１５３０にループし、またプルインプロセスを継続する。ステップ１５３５で行われる検査はシステムのリアルタイム制御ループの一部として頻繁に生じ、典型的には１秒につき１回よりも相当速く、例えば、１秒につき１０回以上の頻度で生じ、ステップ１５３０～１５３５～１５５０のループは、典型的には車両が目標車間距離をとるほど十分接近移動する前に何回も生ずる。当業者には、幾つかの実施形態において、何らかの車両におけるアクティブ・クルーズ・コントロール（ＡＣＣ）及び衝突被害軽減システム（ＣＭＳ）の動作を本発明に従うよう変更して、隊列走行車両が所望車間距離に近づけるようにすることができる。
【0076】
隊列走行解消のリクエストもステップ１５４５でのチェックにより識別することができ、この識別も周期的に、やはり典型的には上述したように１秒あたり１回より相当速く行われる。解消リクエストをステップ１５４５又は１５５０から受信する場合、それらリクエストはステップ１５５５で多重化され、また隊列走行解消プロセスがステップ１５６０で開始される。隊列走行解消プロセスは、基本的に前方車両に対する後方車両の速度を減速することによって間隔を徐々に増大させることを含む。適正な距離が達成され、このシステムの制動及び他の安全方策がもはや必要でなくなった後、ステップ１５６５でチェックされる運転者引継ぎが有効になる。運転者引継ぎのために間隔が未だ十分でない場合、ステップ１５６５におけるチェックはいいえ（Ｎｏ）を生じ、また解消プロセスはステップ１５６０にループする。ステップ１５６５がはい（Ｙｅｓ）を生ずる場合、解消プロセスは、運転者が車両の運行を引き継ぐべきとの信号を送ることによってステップ１５７０で継続する。勿論、緊急事態の場合には、運転者は、ブレーキを踏むか又は単に隊列走行受諾を止めるかのいずれかによって隊列走行を即座に終了することができ、このいずれかはステップ１５４５及び１５５０でチェックされるような解消リクエストを発生する。
【0077】
ステップ１５７０で示すように運転者引継ぎに続いて、ステップ１５７５で解消プロセスが完了したか否かを決定するチェックが行われる。はい（Ｙｅｓ）は異なるシナリオで生じ得る。幾つかの場合において、隊列走行は、道路状況、交通量、他車両による割込み、又は隊列走行を短期間不適切にする他のイベントを理由として解消されるが、経路付け及びパートナー選択は、容認できない条件が消滅した後に隊列走行にとって容認可能である。解消プロセスは、さらに、例えば、緊急事態を理由として終了して運転者による引継ぎが行われる。このように、ステップ１５７５でのチェックがはい（Ｙｅｓ）を生じた場合、多重化ステップ１５８５を経由してステップ１５１０にループバックし、他の隊列走行が容認可能であるかを見る。ステップ１５７５が「いいえ（Ｎｏ）」を生ずる場合、プロセスはステップ１５８０に進み、運転者の引継ぎが成功したか否かを決定する。「いいえ（Ｎｏ）」の場合はステップ１５７０にループするとともに、はい（Ｙｅｓ）の場合はステップ１５８５でステップ１５７５からのはい（Ｙｅｓ）と多重化されて１５１０にループバックする。当然のことながら、車両のＡＣＣ及びＣＭＳの動作は隊列走行が解消されたとき通常通りに動作することができる。
【0078】
次に図１６Ａ～Ｃにつき説明すると、これらはプルインに関する様々なシナリオを示す。より具体的には、図１６Ａにおいて、後方車両１６００は前方車両１６０５と同一レーン（車線）にある。後方運転者が隊列走行システムに関与し、また隊列走行が図１５に示すように承認されると仮定した後、後方車両が前方車両に向かって所望車間距離に達するまで前進することによってプルインが始まる。そのプルインプロセスを管理する方法論は図１７Ａ～１７Ｂにつき説明する。同一レーンにおけるこのプルインプロセスは難題であり、これはすなわち、前方トラックより速い速度を有し、したがって、より長い停車距離を有する後方車両を巻き込むからである。このことは、以下に説明するように、安全を確保するための制約を運行に課すことになる。これに引き替え、図１６Ｂにおける車両１６１０及び１６１５によって示されるように、後方トラックは先行車両のレーンに隣接するレーンに存在するが、先行車両の背後に存在する場合があり得る。最後に、図１６Ｃにおける車両１６２０及び１６２５によって示されるように、先行車両が後方車両に隣接するレーンにいるが、前方車両が後方車両に対して追い越す必要がある。本発明システムの態様の実施形態によれば、図１６Ｂ及び１６Ｃのシナリオで必要となるレーン変更を完遂するための制限された時間窓がシステムによって課せられる。この時間窓は、運転者が隊列走行システムに関与し、またシステムによって設定されるときスタートする。或る実施形態において、この時間窓は、例えば、非隊列走行車両の追い越しを可能にするが、運転者が隣接レーンにあって延長した期間にわたり隊列走行しない程度に十分短いものに設定する。
【0079】
図１６Ｂ及び１６Ｃのシナリオにおいて、レーン変更を必要とする車両は他車両に対する所望車間距離まで移動することができ、また他車両に対して相補的速度調整を何らする必要もなしに、速度を維持しつつレーン変更することができる。しかし、双方車両が同一レーンにあって、プルインが後方車両を前方車両からの目標間隔まで持っていくことが含まれる図１６Ａのシナリオでは、最も安全な運行に関して、このことは当てはまらない。レーン変更が他車両から適正距離で行われない場合に図１６Ｂ及び１６Ｃのシナリオにも適用できるこのようなシナリオにおいて、安全運行の範囲が存在し、また好適には、安全マージンを改善するよう先行車両を僅かに遅くすることがあり得る。このことは図１７Ａ～Ｂを参照することでよりよく理解できるであろう。図１７Ａにおいて、接近速度又は後方車両と前方車両との間における相対速度を縦軸にプロットするとともに、後方車両の前部と前方車両の後部との間における間隔又は距離を横軸にプロットする。目標間隔はこの実施形態において図示のように非ゼロ位置である。間隔が大きくなればなるほど相対速度が大きくなり、したがって、平行線模様付け（クロスハッチング）によって示した三角形領域は安全運行の領域を表す。このグラフからは、間隔を狭めるために後方トラックが前方トラックに対して速度上昇する場合、安全運行に必要な車両間の距離増大が、これら車両が目標車間距離に達するのに要する時間を引き延ばすことが分かる。
【0080】
図１７Ｂにつき説明すると、先行車両を僅かに減速することによってプルイン中により小さい間隔が容認可能であることが分かる。車間距離が達成された後、双方車両は隊列走行システムの制御の下で加速することができ、これにより双方とも所望隊列走行速度に復帰する。図１７Ｂに破線で示すように、後方車両は、速度を維持するよう指令される、又は速度を上昇するよう指令される、又は先行車両の速度が減速される量よりも幾分少ない量だけ減速するよう指令されることができる。これらシナリオの各々において、先行車両の減速は、依然として、先行車両が速度を維持している場合よりもより迅速かつ安全に、隊列走行車両が所望車間距離に達することができる。
【0081】
次に図１８Ａ～１８Ｃを参照して、潜在的制動問題に応答する運転者アラートを管理する様々な選択肢を説明する。大型トラックを含む多くの車両は、ブレーキを制御する制動コントローラを有する。運転者の制動入力に応答することに加えて、このような幾つかのコントローラは、電子システム（例えば、隊列走行コントローラ、ＡＣＣ又はＣＭＳシステム、自律車両コントローラ等）からの制動コマンドを受信することができる。現行の多くのこのような制動コントローラは、電子システムが指令されることができる制動量を制限する。この制限は、しばしば、安全問題に基づき、また運転者は電子的コントローラよりも潜在的制動緊急事態に対する適切な応答をよりよく判断できるとの信頼に基づく。したがって、様々な自動制御システムからのコマンドに応答するよう実装されているよりも、ブレーキペダルに対する踏み込みによってより多くの制動を運転者が指令できるようにしているのが一般的である。
【0082】
隊列走行コントローラがこのような制限を受ける制動コントローラを利用するとき、手動制動又は手動支援制動が望ましい状況を運転者に警告するよう運転者に対して制動アラートを発生するのが賢明であり得る。概して、制動アラートは、隊列走行コントローラ及び／又は制動コントローラからのコマンドに応答できる又は応答するよう実装されているよりも多くの制動が必要である又は望ましいことを、隊列走行コントローラが決定する（又は状況がそのような事態を示す）いかなる時点でも発令することができる。
【0083】
制動アラートは、音声アラート、触覚シグナル（例えば、操舵ハンドル等における振動）、画面ディスプレイ等を含む様々な異なる様態で運転者に伝えることができる。しかし、制動アラートは、即時的な運転者の行動が必要であると考えられるときにのみ発生するのが好ましい。したがって、メッセージは、運転者が即時に知覚、理解及び行動を起こすようなやり方で伝えるのが好適である。多くの進化した車両制御システムは、様々な条件に対して聴覚に訴える音声及びダッシュボードのディスプレイの形式におけるアラートを発生する。このようなアラートは多くの場合にうまく機能するが、ここで考えられるタイプの緊急制動アラートとしては、緊急の意味が伝わるような発話（言葉による）アラートがよりよく知覚され、また例えば、ブザー、ホーン、又は他の警告タイプの音の作動のような他タイプのアラートよりもより迅速に応答しうる傾向があることが分かっている。したがって、幾つかの実施形態において、「BRAKE NOW（今ブレーキを掛けよ）」のような言葉による（発声ベースの）警告を、好適には、緊急の意味を伝える大声の発声で発する。適切であれば、言葉による警告は複数回繰り返すことができる。幾つかの実施形態において、視覚的アラート信号及び／又は他のアラートを言葉による警告と並行して表示又は作動させることができる。様々な実施形態において、言葉による警告は、予め録音した警告メッセージ若しくはコンピュータ生成メッセージとすることができる、又は任意な他の適切なやり方で生成することができる。
【0084】
制動アラートは隊列走行に関連する異なる運行条件に相関することが分かる。図１８Ａは、間隔を詰める、間隔を維持する、隊列走行を解消する、隊列走行を解消して運転者に引き継がせる間それぞれにおいて発生する制動アラートを管理する個別のプロセスフローをステップ１８００～１８５５によって示す。各制動アラートは、条件が制動システムの能力を超える制動リクエストを必要とする場合に発生する。幾つかの実施形態において、運行条件及びシステム能力に対する予測評価を行い、これにより予測される又は見込まれる運行条件が制動能力又は他のシステム能力を超える場合、調整が自動的に行われる又は運転者が警報を受けるようにすることができる。図１８Ｂは、これらプロセスフローを、ステップ１８６０で示す制動閾値の単一チェック、及びステップ１８６５で示す運転者への制動アラートを発令する単一ステップのみに集約して示す。図１８Ｃにおいて、さらに他の変化形態を示し、この場合、隊列走行を解消するとともに運転者引継ぎを伴う命令が、このリクエストをシステム能力と比較する必要なく、即座にアラート１８７０を発生する状況を示す。
【0085】
次に図１９につき説明すると、他の安全性チェックはほぼ連続的な信頼性高いＶ２Ｖ通信を検証することを含む。Ｖ２Ｖ通信（典型的には上述したようなＤＳＲＣリンクではあるが、同様な品質及び信頼性を有する他のプロトコルも容認できる）をシステムによって連続的に監視する。好適には、冗長Ｖ２Ｖリンクを設け、異なるプロトコル又はモダリティを使用するリンク、例えば、ＬＴＥ、ＷｉＦｉ、又は変調光トランスミッタ／レシーバ対を含む。ＤＳＲＣに頼らずに後方車両の前部から前方車両の後部までの距離を測定する技術としては、レーダー、カメラ、ライダー及び超音波がある。前方トラックによる制動操作は、ＤＳＲＣとは独立して後続車両の前部に備え付けたカメラによって検出することができる。或る実施形態において、Ｖ２Ｖ通信の問題が検出される場合、通信問題が解決されるまで隊列走行は無効にする。したがって、隊列走行に関与することができないか、又は既に関与している場合には隊列走行を解消するかのいずれかとなる。当業者には、幾つかの実施形態においては複数通信リンクを実装し、１つ又はそれ以上に障害があっても精度が保証されて依然として十分動作している場合、隊列走行機能を無効にする結果とならないようにすることは理解できるであろう。図１９に示すステップ１９００～１９２０の検証プロセスは、(a) 最新の受信メッセージを受け取ってからの時間を測定し、またメッセージ間の予想時間と比較すること、(b) メッセージＩＤ及び内容を検証すること、及び(c) 通信チャネルのノイズレベルが所定閾値を超えるか否かを決定することのうち１つ又はそれ以上、及び場合によってはそのすべてを含む。図１９に示す実施形態に関して、これら３つのいずれかにおける障害は、ステップ１９２０で示すように更なる隊列走行を停止する。
【0086】
図２０のステップ２０００～２０２５は、隊列走行速度を選択する他の処理を示す。多くの実施形態においては、先行車両が隊列走行の速度を設定する。しかし、幾つかの場合、例えば上り坂勾配では、後方車両が隊列走行の速度を設定できるようにすることが有益であり得る。したがって、図２０は、後方車両が前方車両の速度、及びひいては隊列走行速度を設定できる２つの選択肢を示す。第１の選択肢では、メインプロセスのブロック及び速度コントローラのブロックが前方車両の目標速度を決定し、またその目標速度を前方車両にＶ２Ｖ通信リンクを介して通信する。この後、前方車両はそれに応じて自身の速度を調整する。第２の選択肢では、後方車両が前方車両にデータを送信するだけで、この後前方車両がそれに応じて自身の目標速度を決定する。最適隊列走行速度を決定するのに使用されるデータとしては、双方のトラクタにおけるエンジン性能及びギアリングデータ、双方のトラックにおける荷重、現在及び今後の道路セグメントにおけるグレード情報、及び間隔がある。さらに、当然のことながら、幾つかの実施形態において、システムが前方車両の速度を制御しない場合もあり得る。このような実施形態において、所望速度は、前方車両の運転者に通信され、これに応じて調整されることができる。
【0087】
次に図２１Ａ～２１Ｂにつき説明すると、本発明の付加的態様がよりよく理解できる。とくに、車両にとって、一方又は双方の車両が静止しているときから、例えば、その出発点、休憩停車、又は他の同様な状況で、隊列走行に編入されるのが望ましいことが時々ある。例えば、幾台かの長距離輸送トラックは、食事又は他の休憩後のように双方又は複数の車両が同時に継続している間におけるそれらの車隊場所で、隊列走行に編入される。このような場合、車両の出発を協調させるのが望ましい。図２１Ｂはヤードを去ろうとしている２台の車両の相対位置を示す。第１トラックは既に移動したが相当ゆっくりと移動しているとともに、第２トラックは未だ移動していない。このような場合、双方の車両が隊列走行準備完了状態に達するまでに情報の即時共有によって、隊列走行は容易になる。そのことは、典型的には双方車両における隊列走行システムが初期化され、また運用可能となること、双方車両が移動している又は移動準備が完了していること、及び車両が容認可能な相対場所に居ることを必要とする。このような連携は、図２１Ａのステップ２０００～２０２５で示すプロセスによって達成することができ、この場合、上側ブロックは第１車両がとる処理ステップを示し、下側ブロックは第２車両がとる処理ステップを示す。このとき車両間通信は、ＤＳＲＣ、ＬＴＥ、ＷｉＦｉ又は変調光源／レシーバ対のような他の適当なプロトコルを介して行う。
【0088】
次に図２２につき説明すると、本発明態様によるデータログ記録プロセスの実施形態をよりよく理解できるであろう。ブロック２２００で示すイベントトリガは、ブロック２２０５で示す車両に記憶され、またこの後、ブロック２２１０で示すように適当なプロトコルを介してＮＯＣに転送される。イベントトリガとしては、図７Ａ～８Ｂに示したセンサについて上述したような、システム関与、ハード制動、運転者への制動アラート、等々がある。
【0089】
上述の説明は、車両のセンス及び制御を管理するよう組み合わさるハードウェア及びソフトウェアの観点からシステム動作の理解をもたらす。これに追加しての重要態様は、ユーザー・インタフェース及びこれに関連するユーザーエクスペリエンス（ユーザー体験）である。ユーザー・インタフェースは上述した教示で概説しているとともに、Ｕｌａｎｄ ＵＸの例示的実施形態は以下の説明からよりよく理解できるであろうが、当業者は、本明細書における教示が限定を意図しないことを理解するであろう。先ず、図２３につき説明すると、これは本発明の態様による、上述のシステム説明に一貫する車両の３つの運行段階を示す状態図である。より具体的には、第１段階２３００は、車両が初期的には「隊列走行に応対可能ではない（unavailable for platooning）」状態２３０５にあることを示し、この状態から「ペアリングに応対可能である（available for pairing）」状態２３１０に移行することができる。上述したように、段階２３１５で示すように隊列走行パートナー車両が応対可能である場合、どちらかの車両は拒否することができ、状態を「応対可能（available）」に戻す。しかし、相互受諾の際に、状態は段階２３２０に示すように変化する。幾つかの場合、例えば、自律車両の場合には、隊列走行情報は２台より多い数の車両を含むことがあり得るとともに、他の場合には、初期的又は隊列走行存在時全体にわたり隊列走行は２台の車両しか含まないことがあり得る。いずれの場合でも、少なくとも２台の車両が受諾した後、隊列走行の形成は、以下により詳細に説明するように、車両が依然として幾分かの距離だけ離間していても、段階２で示すように始まる。説明を分かり易くするため、２台のみの車両における隊列走行を例示目的として使用するが、２台より多い数の隊列走行も本発明の範囲内である。
【0090】
図２３の段階２で示す状態は、２台の車両がともにより接近して移動するときに生ずる遷移を反映する。少なくとも幾つかの場合、車両は参照符号２３３０で示すＤＳＲＣ通信のためには距離があり過ぎるときの隊列走行ランデブーのプロセスを開始する。車両がＤＳＲＣレンジ内に十分なほど接近した後、状態は参照符号２３３５の状態に変化する。この後車両がそれ以上離れる場合、状態は参照符号２３３０の状態に戻ることは勿論である。ＤＳＲＣ通信レンジは、依然として隊列走行に使用するよりも大きい距離を含んでおり、また車両は互いに接近する移動を継続するとともに状態２３３５にある。状態２３３５にある間に車両は操縦して同一レーンで適正順序となる。車両が互いに十分接近して、隊列走行を始めることができるようになった後、状態は「隊列走行レンジ内（inside platoon range）」状態２３４０に切り替わる。
【0091】
参照符号２３４５で示す段階３はその時点で開始する。段階３は、その期間中車両の運行が少なくとも部分的に自動化される期間を表し、また参照符号２３５０でしめすプルイン又は「ドローイン」状態、参照符号２３５５で示す間隔維持状態、及び参照符号２３６０で示す隊列走行解消状態を有する。これら状態の各々におけるシステム動作は、とくに、図１５につき既に詳細に説明してある。当然のことながら、幾つかの場合、車両が依然としてプルイン状態にある間に隊列走行は解消され、またしたがって、状態２３５０から状態２３６０への直接遷移を生ずることがあり得る。さらに、解消状態の終了は段階２における状態２３４０に戻るよう遷移し、この場合、車両は隊列走行レンジ内であるが、自動制御下にはない。さらに当然のことながら、段階２におけるいずれか任意の状態からの遷移は、どちらか又は双方の車両の運転者がペア解消を決める場合に、状態２３１０に戻るよう遷移することができる。
【0092】
各状態中の車両間の物理的距離は、一連のゾーンが図２４Ａ～２４Ｃで本発明による行動とともに示されるように表すことができ、これら行動は、これらゾーンの各々において可能である。当業者であれば、これらゾーン各々における数値的距離は車両速度、道路状況、環境条件、通信品質、ネットワークポリシー、車隊管理ポリシー、及び本明細書で説明したような他の要因に基づいて変動し得ることは理解できるであろう。例えば、プルイン中の速度と安全距離との間における相関は図１７Ａ～１７Ｂにつき説明した。以下図２５Ａ～２５Ｃから図３５Ａ～３５Ｃは、関連ゾーン、後続車両の運転者が見る視覚ディスプレイ、及び各状態におけるユーザーが応対可能な物理的入力を表示する。説明を簡略化及び分かり易くするため、図２５Ａ～３５Ｃは後続車両の透視図を反映するが、当業者には、以下の説明から先行車両のディスプレイも同様であり、容易に確認されることは分かるであろう。
【0093】
先ず図２４Ａにつき説明すると、先行車両２４００及び後続車両２４０５が車道上の同一レーン２４１０で進行している。後続車両２４０５の前方における右向き矢印は、車両間の距離を詰めるため先行車両２４００よりも比較的速い速度で進行しているが、多くの場合、双方の車両は本明細書のいずれかの箇所で説明するようにほぼ幹線道路（ハイウェイ）速度で移動している。ゾーン２４１５は、先行車両の後部から測った距離（これら実施例に関してはすべてのゾーンは先行車両の後部から測っている）を示し、この距離にわたり堅牢なＤＳＲＣ通信が車両間で存在する。当然のことながら、この実施例に関してはＤＳＲＣ通信を仮定するが、適正な帯域幅の任意の適当な信頼性の高い通信プロトコルで置き換える、又はＤＳＲＣに付加して使用することができる。ゾーン２４２０は、通常の非隊列走行運行中に、警告用車両の衝突被害軽減システム（ＣＭＳ）及び自動緊急（衝突被害軽減）ブレーキ（「ＡＥＢ」）が介入するよう動作可能になり得る距離を示す。ゾーン２４２５は、協調的適応走行制御が動作する距離を示す。ゾーン２４３０は指令（コマンド）車間距離を示し、この車間距離ゾーン中では隊列走行が状態２３５５で正常に運行しているとき本発明システムの制御の下に車両２４００及び２４０５のトルク及び制動、並びにひいては速度で動作する。ゾーン２４３５は、隊列走行公差ゾーンを示し、隊列走行が状態２３５５で運行を継続している間にコマンド（指令）間隔が変動し得る可変距離を表す。簡略化及び分かり易くするため、このゾーン２４３５は図２４Ｂ～２４Ｃでは省略する。
【0094】
図２４Ｂは、車両が隊列走行に関与し始めたとき、すなわち、図２３における状態２３３５～２３５５に関連するゾーンを付加することによって、図２４Ａを増補する。したがって、ゾーン２４４０は、隊列走行への関与が、双方の運転者にとっての又は全自動車両の場合にはコマンドプログラム運行車両にとっての選択肢である距離を示す。さらに、ゾーン２４４５は、「関与青信号（グリーンライト）ゾーン」、すなわち車両オペレータ又はコマンドプログラムが、隊列走行を、またひいては図２３の状態２３４０から２３５０への遷移を開始することができる好適な距離を示す。当然のことながら、青信号ゾーン２４４５は、とくに完全自律型車両への実装に基づいて、ゾーン２４４０と同一又はほぼ同一であり得る。
【0095】
図２４Ｃは、隊列走行が解消されようとしているとき、すなわち、図２３における状態２３３６に関連するゾーンを付加することによって、図２４Ａを増補する。本明細書で上述したように、解消中には、車両が離れ、車両間の距離が増大し、例えば、最終的に車両間の間隔は、運転者が車両速度の手動制御をとるのに十分な間隔となる。したがって、図２４Ｃには、後続車両２４０５の背後に左向き矢印で車両間の相対速度が大きくなり、したがって、距離が増大していくことを示す。さらに、図２４Ｃは、隊列走行再関与（re-engagement）ゾーン２４５０、すなわち、運転者／コマンドプログラムが隊列走行への再関与することが許容される距離を示す。図２４Ｃは、さらに、再関与（re-engagement）青信号ゾーン２４５５も示し、このゾーンは、少なくとも幾つかの実施形態において、先行車両に最も近接する側のゾーン２４５０の端部からヒステリシス距離又は間隔２４６０だけ離れ、また先行車両に最も遠い側のゾーン２４５０の端部からポリシー距離又は間隔２４６５だけ離れる幾分小さい距離である。ヒステリシス間隔によれば、システムの潜伏（待ち）時間で生ずる比較的僅かな変動、ヒューマン応答時間等々を許容する。ポリシー間隔は、任意な安全要因である。当然のことながら、幾つかの実施形態において、間隔２４６０及び２４６５は、とくに自律運行に関してはゼロ又はほぼゼロとすることができる。さらに、図２４Ｃは手動引継ぎゾーン２４７０を有し、これは、運転者が車両を手動で制御することを可能にするのに十分ではあるが、依然として再関与距離内である距離を示す。この距離が手動引継ぎゾーンを越えて拡大する場合、再関与はもはや許容されず、手動引継ぎが必要となり、運転者は参照符号２４７５で示すように一次制御状態になる。
【0096】
次に図２５Ａ～２５Ｃにつき説明すると、状態２３３０にあるときのシステム動作が運転者の透視図からよりよく理解できるであろう。図２５Ａに示す実施例において、後続車両２４０５は先行車両２４００の背後に約１.９３ｋｍ（約１.２マイル）の位置にあり、この例示的実施例ではゾーン２４１５の外側にあると見なされ、これにより車両間の堅牢なＤＳＲＣ通信は依然として信頼性高く利用できない。当然のことながら、堅牢なＤＳＲＣ通信のための実質距離はここで示す例示的距離よりも小さい又は大きい場合があり得る。図２５Ｂに示すように、後続車両の視覚ディスプレイ２５００は先行車両までの距離を示し、また運転者に速度限界で進行するようシステム命令を与える。さらに、ディスプレイ右上のアイコン２５０５は、双方の運転者によってペアリングが受諾されたことを示す。当然のことながら、この時点から先行車両のディスプレイは、先行車両の運転者に対して後続車両が追い付けるよう減速し図１７Ａに示す速度差に一致させる命令をする。少なくとも幾つかの実施形態において、先行車両のディスプレイは、典型的には車両間の距離を負の値で示す。図２５Ｃは、隊列走行関与／離脱制御部１５１０及び２５１５、並びに運転者のブレーキペダル２５２０及びアクセルペダル２５２５も示す。制御部２５１０及び２５１５は非アクティブ状態であり、また運転者は車両の制動及びトルク／速度を操作する。隊列走行関与／離脱制御部は車両の任意な都合のよい場所に、例えば、ダッシュボード、運転席に隣接するストーク（茎状体）、座席間コンソール、頭上、又は操舵ハンドルのいずれかに配置することができる。概して、運転者が不慮に押し込むことが起こり得るような場所に設けることなく、これら制御部に容易に確実にアクセスできることが好ましい。さらに、当然のことながら、幾つかの実施形態において、関与／離脱制御部は、状態に応じて異なる機能に対する単独制御部とすることができる。
【0097】
次に図２６Ａ～Ｃにつき説明すると、後続車両が堅牢なＤＳＲＣ（又は上述した他の）通信範囲内にある状態２３３５を反映している。したがって、このときディスプレイは、車両間の距離が１５０.８８ｍ（４９５フィート）にあり、システムが間隔を９１.４４ｍ（３００フィート）まで縮めよと運転者に命令している状態を示す。９１.４４ｍ（３００フィート）の距離は単に例示であり、限定を意図するものではなく、この目的は、距離が徐々に信頼性高く安全にプルインできるほど十分に大きいものとして選択されるということを示すにある。さらに、ディスプレイは、車両間（ビークル・ツー・ビークル）通信がアクティブであるというアイコン２６００を示す。制御部２５１０及び２５１５は非アクティブ状態のままであり、また運転者はアクセルペダル及びブレーキペダルの双方を操作する責任を負っている。
【0098】
次に、図２７Ａ～２７Ｃにつき説明すると、異なる運行環境が理解できるであろう。この場合、車両がペアリングされ、またＶ-to-Ｖ通信が利用可能であるが、意図する先行車両が意図する後続車両に依然として追い付いておらず、後続車両への引継ぎを必要としている。この場合、ディスプレイ２５００は、後続車両に対して、先行車両が意図する後続車両の背後に－１５０.８８ｍ（４９５フィート）の位置にあることを示している。システムは後続車両のオペレータに対して先行車両を先行させるよう命令する。双方車両の実装条件及び動作条件に基づいて、システムは、一方又は双方の車両間における運転者に対して、速度を適切に調整し、妥当な時間内に隊列走行位置に到達できるよう命令することができる。双方の運転者はこの状態中ブレーキペダル及びアクセルペダルを操作する。
【0099】
運転者の透視図からの状態２３４０を図２８Ａ～２８Ｃに示す。この状態において、車両２４０５は図２７Ａに示すようなゾーン２４４５内にあり、図２７Ｂのディスプレイ２５００は９１.４４ｍ（３００フィート）よりも小さい距離を示す。ディスプレイは、運転者に対して関与制御部２５１０を押し込むことによって隊列走行を開始するようシステム承認を与え、この関与制御部２５１０は少なくとも幾つかの実施形態において照明点灯させることができる。関与制御部２５１０が押し込むまでは、運転者はブレーキペダル及びアクセルペダル双方の操作を継続する。参照符号２８００で示す音声信号を使用し、この時点で運転者が隊列走行関与の選択肢をとったという情報を運転者に提供することができる。
【0100】
次に図２９Ａ～２９Ｃにつき説明すると、運転者の透視図から見た状態２３５０が理解できるであろう。関与制御部（又は自律型車両に関しては適切なプログラムコマンド）がアクティブ状態になっており、プルイン又はドローインが開始している。運転者は、もはやアクセル制御することはないが、ブレーキペダル２５２０又は離脱制御部２５１５を押し込むことによってプルインを終了させることができる。図２９Ｂの例に関しては、ディスプレイ２５００は、３８.１ｍ（１２５フィート）から１５.２４ｍ（５０フィート）への間隔減少を示し、さらに、先行車両の前方指向カメラが見た視界を表示する。関与制御部２５１０は、幾つかの実施形態において、図２８Ｃとは異なるように照明点灯することができ、隊列走行の開始をプルイン状態とは差別化することができる。幾つかの場合、音声アラートを使用することができる。
【0101】
図３０Ａにおけるゾーン２４３０として示すように車両がコマンド（指令）間隔に達したとき、状態が状態２３５０から状態２３５５に遷移し、この場合、本明細書記載のシステムが制動及びトルクを操作してコマンド間隔を維持する。このようにして、隊列走行は定常状態で運行し、また多くの場合、この状態を長時間の期間にわたり持続する。この状態へのエントリーは、やはり参照符号２８００で示す音声アラートで合図することができる。さらに、関与制御部２５１０における照明は定常状態運行を示すものへと変化することができる。ディスプレイ２５００は間隔距離を示し、また先行車両の前方指向カメラが見た視野を示す。上述したように、どちらかの運転者は、ブレーキペダル又は離脱制御部を押し込むことによって、又は図３１Ａ～Ｃに示すように関与制御部を押し込むことによって、隊列走行を終了することができる。このことは状態を状態２３５５から状態２３６０（解消）へと遷移する。
【0102】
図３２Ａ～３２Ｃは状態２３６０（解消）を示し、この場合、車両間の間隔は、運転者による手動引継ぎが安全になるまで増大する。ディスプレイ２５００は増大した距離を示す。ゾーン２４５０は、図３２Ａで後続車両２４０５の左向き矢印で描かれる。関与制御部２５１０は、幾つかの実施形態において、例えば、点灯の反時計方向進行によって他の状態とは異なるように照明される。システムはトルク及び制動の双方制御を保持するが、運転者がブレーキペダルを踏み込み、より迅速にブレーキを掛けることができる。ディスプレイ２５００は、先行車両の前方指向カメラからの視界を示し続ける。さらに、ディスプレイ２５００は、「解消している（dissolving）」の状態表示を行い、運転者に対して再度プルインするため関与制御部を押し込むよう情報を与える。Ｖ-to-Ｖ通信も堅牢のままである。音声シグナルも発令させることができる。
【0103】
車両間の間隔が再関与青信号ゾーンに達した後には、図３３Ａ～Ｃに示すように、手動引継ぎが再関与とともに許容される。ディスプレイ２５００は、増大する間隔、及び運転者に対して制御する、すなわち、隊列走行に再関与するため関与制御部を押すことを勧める警告を示し続ける。この再関与制御部は、図３２Ｃで示されるように照明され続けるが、運転者はアクセルペダルの制御をとることができる。間隔が増大し続ける、例えば、９１.４４ｍ（３００フィート）を超えて増大するとき、再関与の選択肢は、図３４Ａ～Ｃに示すように、もはや存在しなくなる。その代わりに、この時点で状態は、基本的に図２８Ａ～Ｃで示したように、車両が隊列走行の準備が完了している状態２３４０に戻るが、最小安全手動後続距離を超えている。運転者はアクセル制御をとり、またディスプレイはこのことを表示する。しかし、車両間の距離は図２８Ａ～Ｃで示されるよりも大きいものであり得る。
【0104】
図３５Ａ～Ｃに示すように、距離が隊列走行関与距離を超えて増大するとき、手動引継ぎを必要とする。ディスプレイは距離を提示し、また運転者に対して車両の引継ぎ制御をとるよう緊急警告を与え、また音声警告も発令することができる。図２５Ａ～３５Ｃから、及び車両のオペレータの透視図から、例示的実施形態における隊列走行の進展を完全に理解できるであろう。
【0105】
隊列走行コントローラに関する数個の潜在的状態がある。幾つかの実施形態において、得られる状態には、（以下に限定しないが）、(1) 応対可能、(2) ランデブー、(3) 隊列走行、及び(4) 解消の状態がある。極めて大まかには、応対可能状態においては、隊列走行コントローラがアクティブ状態であり、また１つ又はそれ以上の外部システムとの通信を利用可能であるが、何ら特定の隊列走行パートナーが識別されていないという意味で、システムはアクティブ状態である。ランデブー状態においては、隊列走行パートナーが識別されているが、いずれかの隊列走行パートナーを何らかの方法で自動制御するという意味で隊列走行制御は非アクティブ状態である。隊列走行状態においては、隊列走行コントローラは、少なくとも１台の隊列走行パートナーを少なくとも部分的に自動制御することを容易にするよう構成される。解消状態においては、隊列走行コントローラは、隊列走行制御以外の何らかの制御、例えば、手動制御又は他のシステムによる制御によって、このような車両を制御する状態に復帰させるのに適切な様態で御は非アクティブ状態である。隊列走行状態において、隊列走行コントローラは、少なくとも１台の隊列走行パートナーを少なくとも部分的に自動制御しようと試みる。様々な実施形態において、これら状態のいずれも複数の互いにはっきりと区別できる状態に細分割することができる。例えば、隊列走行は、個別プルイン状態、間隔制御状態、及び速度制御状態を含むことができ、これら状態は異なる状況で使用するのに適切である。
【0106】
当業者には理解できるように、米国運輸省の国家幹線道路交通安全局（ＮＨＴＳＡ）は自律運転における５つの異なるレベルを定義した。本明細書記載の実施形態のうちの数個において、先行車両の運転者はこの先行車両の完全（フル）制御を期待する。レベル１の自動化（ＮＨＴＳＡによって定義されたような）は、後続（トレーリング）車両について考慮している。すなわち、後続車両の運転者は能動的に車両を操舵する（例えば、すべてステアリング制御を行う）。したがって、後続車両の運転者は、注意を怠らず、また隊列走行制御全体にわたり能動的に関与することを期待される。注意を怠らない運転者を利用できること（利用可能性）は、隊列走行コントローラの設計を大いに簡素化することができ、これはすなわち、人間の運転者はコントローラよりも一層容易に気付くことができ、したがって、時によって隊列走行コントローラよりも不安状況に対してより容易に又はより迅速に反応し得る多数の運転条件があるからである。
【0107】
次に図３６及び３７を参照して、後続車両における手動オペレータ制御から隊列走行制御（例えば、レベル１の自動化隊列走行制御）への遷移を管理するのに適した隊列走行を開始するための、隊列走行制御の状態マシン及びハンドシェイクベースの方法を説明する。本明細書記載の状態マシン及び隊列走行管理又はそれらの変形体は、本明細書に記載される実施形態のうち任意なものに関連して使用することができる。
【0108】
図３６は、特別な実施形態による隊列走行コントローラ状態マシンにおける多数の潜在的状態を示す状態図である。図示の実施形態において、状態としては、初期化又は起動状態３６１５、ほぼ応対可能状態に対応するパートナー管理状態３６１８、ランデブー状態３６２１、及びホストが前方／先行車両又は後続／後方車両に指名されるか否かについて特異的な多数の状態を含む。当然のことながら、ホスト車両は、任意な特定隊列走行において先行車両又は後続車両のいずれかとして指名されることがあり、また任意な特定状態に関するタスクはホストが前方又は後方車両として指名されるか否かに基づいて変化することがよくある。したがって、有り得る状態としては、ホストが前方車両として指名される隊列走行コントローラの状態における１組のセット、及びホストが後続車両として指名されることに対応する隊列走行コントローラの状態における１組のセットがある。図示の実施形態において、前方車両状態としては、前方ランデブー状態３６２３、前方システム準備完了状態３６２５、前方車両の隊列走行準備完了又は前方運転者の隊列走行準備完了状態３６２７、前方隊列走行維持状態３６２９及び前方解消状態３６３１がある。後方車両状態としては、後方ランデブー状態３６４３、後方システム準備完了状態３６４５、後方車両の隊列走行準備完了又は後方運転者の隊列走行準備完了状態３６４７、後方隊列走行維持状態３６４９及び前方解消状態３６５１がある。幾つかの実施形態において、後方隊列走行維持状態３６４９は、プルイン状態、間隔制御状態、及び相対速度制御状態のような制御状態に細分割することができる。図４１の実施形態においては、プルイン状態及び間隔制御状態はスライディングモードコントローラ４２１５の制御の下に結合され、また相対速度制御状態は速度コントローラ４２１８の制御の下に実行される。勿論、他の実施形態においては、付加的又は代案的に隊列走行維持状態の一部として又はそれに代えて、他の制御状態を採用することができる。
【0109】
特定の実装の背景において、これら種々の状態間における遷移のための代表的フロー及びトリガを図３７につき説明し、この図３７は、各コントローラにおけるそれぞれに対応するランデブー状態からそれぞれに対応する隊列走行状態への遷移を連携させるのに使用し得る特別なハンドシェイクプロトコルも示す。
【0110】
予め、各隊列走行パートナー用の隊列走行コントローラを、ステップ３７０２で示すように初期化する（状態３６１５）。概して、隊列走行コントローラの各々はシステム設計者が適切と見なした任意なトリガ、例えば、車両キーオンイベントに応答して、それぞれに対応する運転者による隊列走行システムの作動に応答して、又はシステム設計者が適切と見なした任意な他の時点で起動することができる。起動後に、隊列走行コントローラはパートナー管理状態３６１８に遷移し、このパートナー管理状態３６１８は、概して車両が任意な特定隊列走行に割り当てられていないときに関連したコントローラの基本管理を伴う。隊列走行が何ら割り当てられでいないので、この時点までのそれぞれに対応する隊列走行コントローラの活動は概して互いに何ら連携されない。
【0111】
何らかの時点で車両は隊列走行に割り当てることができる。概して、隊列走行パートナーは、ＮＯＣのような中央システムによって割り当てることができる、又はアドホック隊列走行が可能とされるシステムでは、隊列走行が望ましいことを示す近接車両間における通信に基づいて車両自体が識別することができる。
【0112】
ホスト車両が他の車両とペアリングされるとき、その隊列走行コントローラはランデブー状態３６２１に遷移し、この状態において、コントローラは割り当てたパートナーとの隊列走行の準備を開始する。同一の遷移は双方の隊列走行パートナーで生ずる。何らかの時点で、一方の車両は先行車両として識別され、また他方の車両は後続車両として識別され、これら識別はそれぞれステップ３７０５及び３７０６によって表される。この順序は、パートナーが割り当てられると同時に、又は後の段階で割り当てられる。様々な異なる要因を利用して、どちらの車両を先行させ、どちらの車両を追従させるかを決定することができ、要因としては、例えば、参加者それぞれの重量及び／又はパフォーマンス能力（これはとくに、隊列走行が大型トラックからなるときとくに重要である）、ペアが識別されるときの車両の相対位置（例えば、その時点でどちらの車両が先頭であるか）、運転者間の同意又は任意な他の適切な要因がある。一方のトラックが他方よりも相当重量があるとき、重い方のトラックは先行トラックとして指名され、これはすなわち、その制動距離が軽い方のトラックよりも長いと予期され得るからである。
【0113】
ランデブー状態においては、車両コントローラは互いに通信を開始する。いずれかのコントローラが、意図したパートナー以外の車両と通信している、又はそのペアリングが同等でないと決定する場合、関連のコントローラはパートナー管理状態３６１８に戻る。
【0114】
位置の順序が割り当てられるとき、先行車両の隊列走行コントローラは前方ランデブー状態３６２３に遷移し、また後続車両の隊列走行コントローラは後方ランデブー状態３６４３に遷移する。どちらかのコントローラが、任意の時点で間違った状態にあって、パートナー以外の車両と通信していることを決定する場合、又は何らかの理由で割り当てられた位置にいないと決定する場合、パートナー車両はその情報を受け取り、コントローラはランデブー状態６２１に戻る。
【0115】
隊列走行が開始する前に、各参加者におけるシステムは、隊列走行に参加する準備が完了していることを検証しなければならない。図３７に示される実施形態においては、ハンドシェイクプロトコルを用いて、双方のコントローラ及び双方の運転者が、隊列走行制御を始動する前に隊列走行の準備が確定的に完了していることを検証する。前方ランデブー状態にある間に、前方車両における隊列走行コントローラは、１組のチェックセットを実施し、前方車両が隊列走行に適した条件にあることを検証する（ステップ３７１０）。前方隊列走行コントローラが実施する幾つかの代表的チェックを以下に図３８の説明後に説明する。必要な隊列走行条件のいずれにも合致しない場合、決定ブロック３７１１の「いいえ（ＮＯ）」で示されるように、合致するまでシステムは待機する。必要とされる隊列走行条件のすべてが合致する場合及び時点で、前方隊列走行コントローラは、アクティブ隊列走行に参加する準備が完了していることを効果的に決定し、FRONT_SYSTEM_READYメッセージを後続車両に送信する（ステップ３７１２）。これと平行して、前方隊列走行コントローラは前方システム準備完了状態３６２５に遷移する。
【0116】
前方隊列走行コントローラは、前方システム準備完了状態３６２５にある間にその隊列走行適合性チェックを稼働させ続ける。コントローラが前方システム準備完了状態にある間にそれらチェックのいずれかが不合格である場合にはいつでも、前方車両のコントローラは、後続車両に対してもはや隊列走行の準備が整っていないという情報を（例えば、NOT SYSTEM_READYメッセージを送信することによって）与え、前方ランデブー状態３６２３に戻る遷移をする。
【0117】
その一方で、後続車両の隊列走行コントローラも一連のチェックを実施して、後続車両が隊列走行に適した条件にあることを検証する（ステップ３７２５）。後方車両隊列走行コントローラが実施することができる幾つかの代表的チェックを以下に図３８につき説明する。必要とされる隊列走行条件のいずれにも合致しない場合、システムは、決定ブロック３７２６の「いいえ（ｎｏ）」分岐によって表されるように、すべての条件が合致するまで待機する。必要とされる隊列走行条件のすべてが合致する場合及び時点で、後方隊列走行コントローラは、アクティブ隊列走行に参加する準備が完了していることを効果的に決定し、BACK_SYSTEM_READYメッセージを先行車両に送信する（ステップ３７２７）。このBACK_SYSTEM_READYメッセージは、ときに「すべて青信号」メッセージと本明細書で称される。これと平行して、後方隊列走行コントローラは後方システム準備完了状態３６４５に遷移する。後方隊列走行コントローラは、後方システム準備完了状態３６４５にある間にその隊列走行適合性チェックを稼働させ続け、それらチェックのいずれかが不合格である場合にはいつでも、前方車両のコントローラは、先行車両に対してもはや隊列走行の準備が完了していないという情報を（例えば、NOT SYSTEM_READYメッセージを送信することによって）与え、後方ランデブー状態３６４３に戻る遷移をする。
【0118】
図示の実施形態において、後方隊列走行コントローラに必要とされるチェックのうちの１つは、先行車両が隊列走行状態の準備が完了していることを検証することである。したがって、後方隊列走行コントローラは、前方隊列走行コントローラが前方システム準備完了状態３６２５にある場合及び時点でのみ、後方システム準備完了状態６４５に遷移する（及びBACK_SYSTEM_READYメッセージを送信する）ことができる。すなわち、FRONT_SYSTEM_READYメッセージを受信した後には、そのメッセージはキャンセルされなかったことになる。
【0119】
前方システムが準備完了状態になった後、前方システムは、ステップ３７１４によって表されるように、BACK_SYSTEM_READYメッセージを受信することを待機する。BACK_SYSTEM_READYメッセージを受信するとき、前方車両の運転者はシステムが隊列走行の準備を完了していることを通知される（ステップ３７１５）。その通知は、任意な所望のアラートシステム及び／又はユーザー・インタフェースを用いて、例えば、システムが隊列走行の準備を完了していることを知らせる特別な色で手動隊列走行ボタンを点灯させること、画面に適切なメッセージを表示すること、音声シグナル又はメッセージを発生すること、等のうち１つ又はそれ以上によって伝えることができる。先行車両の運転者は、次に、ステップ３７１７で示されるように自身が隊列走行の準備を完了していることを肯定的に指示しければならない。運転者の同意は、システム設計者が適切であると見なした任意なインタフェースを用いて、システムに通信することができる。先に示唆したように、１つの適当なインタフェースは運転者が隊列走行の準備を完了していることを指示するよう押し込むことができる隊列走行ボタンである。先行車両の運転者は隊列走行の準備を完了していることを指示した後、運転者は、隊列走行制御はその段階では依然として確立されていないのが好ましいが、隊列走行をしているかのように車両を運行させなければならない。むしろ、先行車両の隊列走行コントローラは、後続車両に対してFRONT_READY_TO_PLATOONメッセージを送信し（ステップ３７１８）、また前方隊列走行準備完了状態３６２７に遷移する。本明細書においては、ときにこのFRONT_READY_TO_PLATOONメッセージを「オールクリア」メッセージと称する。
【0120】
後方隊列走行コントローラがBACK_SYSTEM_READYメッセージを送信した後には、ステップ３７２９で示されるように、FRONT_READY_TO_PLATOONメッセージを受信するのを後方システム準備完了状態３６４５で待機する。このFRONT_READY_TO_PLATOONメッセージを受信する際に、後続車両の隊列走行コントローラは後方隊列走行準備完了状態６４７に遷移し、後続車両の運転者に対して、システム及び先行車両の運転者双方が隊列走行の準備を完了していることを通知する（ステップ３７３０）。やはり、運転者への通知は、限定しないが前方車両につき詳述した通知スキームのいずれをも含む任意な所望形式をとることができる。FRONT_READY_TO_PLATOONメッセージを受信した後、後続車両の運転者は、ステップ３７３２によって表されたように、肯定的に隊列走行を開始しなければならない。やはり、この同意はシステム設計者が所望した任意なインタフェースを用いて、例えば、後続車両における隊列走行ボタンを押し込むことによって、入力することができる。後続車両の運転者が隊列走行を開始した後には、後方隊列走行コントローラは後方隊列走行準備完了状態３６４７から隊列走行状態（後方隊列走行維持状態３６４９）に遷移し、その情報を前方隊列走行コントローラに与え、この前方隊列走行コントローラも隊列走行状態（前方隊列走行維持状態３６２９）に遷移する。この通知は、ACTIVE_PLATOONメッセージの形式をとることができる。
【0121】
どちらかの車両運転者が、条件は隊列走行するのに適切であると思わない限り、また信ずるまでは、隊列走行に同意しないことが予想される。したがって、隊列走行は勧められないと運転者達に思わせるものを見る場合、隊列走行ボタンを押そうとしない（又はそうでない場合には隊列走行を開始する）。上述のハンドシェイクプロセスは、どちらかの運転者が隊列走行に参加する機会をオファーされる前に双方のシステムが隊列走行の準備を完了していることを保証する。さらに隊列走行を始める前に双方の運転者の同意を必要とし、また隊列走行中に制御される主要車両である後続車両の運転者に隊列走行を開始する最終権限を与える。
【0122】
運転者が隊列走行に同意を与えた後であっても、その同意はいつでも撤回／破棄することができる。このような破棄は、二度目の隊列走行ボタン押込みによって又は任意な他の適切なユーザー・インタフェースによって、隊列走行無効コマンドとして処理される。隊列走行無効コマンドを開始した運転者へのシステム反応は、隊列走行無効コマンドが入力されるときにシステムがとっている状態に幾分依存する。前方運転者が隊列走行承認を破棄するよう入力する場合、DISABLE_PLATOONを後方車両に送信する。後方システムが後方隊列走行準備完了状態３６４７にある間にDISABLE_PLATOONコマンドを受信する場合、後方システムは後方システム準備完了状態３６４７に戻る遷移をする。この状態において、前方車両の運転者はやはり肯定的に隊列走行承認を開始しなければならず、また隊列走行が開始可能となる前に上述のハンドシェイクプロトコルの残りの部分を繰り返さなければならない。隊列走行が始まった後にどちらかの運転者が隊列走行無効ボタンを押し込むことによって隊列走行を終了させる決心をする場合、システムは、以下に詳述するように解消状態に遷移する。
【0123】
ランデブー状態で始まる場合、隊列走行コントローラは条件が隊列走行に適切であることを検証するチェックを繰り返し、また適切条件がすべて合致しない限り、また合致するまでは、前方システム準備完了状態３６２５及び後方システム準備完了状態３６２７は入力され得ない。準備完了状態が入力された後であっても、隊列走行コントローラは適切なチェックを行い続ける。このチェックの頻度は変動し得るが、概して繰り返しまたしばしば行うのが好ましい。例えば、１秒の１／１０の割合（１０Ｈｚ）又はそれより速い、またそれより相当速いこともあり得る。システム準備完了状態が入力された後ではあるが、隊列走行制御が始まる前に決定される場合、この影響を受けるシステムはそれぞれに対応のランデブー状態に戻る。
【0124】
隊列走行が始まった後であっても適切なチェックを継続するのが好ましく、これにより条件が隊列走行にとって適正なままでいることを保証するのに役立つ。条件がもはや隊列走行に適さないことを決定する場合にはいつでも、ステップ３７２１及び３７３６によって表されるように、解消がリクエストされる。どちらかの運転者もいつでも解消を開始することができ、この解消開始は、例えば、隊列走行無効／解消ボタンを押し込むことによって行うことができる。解消がリクエストされるとき、コントローラは、ステップ３７２２及び３７３７によって表されるように、前方隊列走行解消状態３６３１及び後方隊列走行解消状態３６５１に遷移する。解消状態において、後続車両は、上述したように、手動制御又は他の自動化又は自律型制御システムによる制御に安全に移行できるように制御される。幾つかの実施形態において、後方車両の運転者はブレーキペダルを踏むことによって解消をトリガすることもできる。
【0125】
解消がトリガされた後に条件が隊列走行に適正となる場合、後方運転者は隊列走行ボタンを再び押し込むことによって隊列走行制御を再開しようと試みることができる。このような選択は、後方隊列走行コントローラを後方隊列走行解消状態３６５１から後方隊列走行維持状態３６４９に遷移させる。しかし、いずれかの隊列走行チェックが不合格である、又は前方運転者が隊列走行を無効にする場合、このようなチェックが解決される又は前方運転者が隊列走行を再有効化しない限り又は再有効化するまでは、隊列走行は回復できない。
【0126】
後続車両の運転者は、隊列走行中又は解消中のいずれかでいつでも車両の手動制御をとることもできる。後方隊列走行コントローラをトリガして、運転者に対して隊列走行状態又は解消状態からの制御を断念させる特定行為は変化し得る。幾つかの実施形態において、運転者に引き継がせる１つの方法はアクセルペダルを踏むことである。概して、隊列走行コントローラはアクセルペダルコマンドに応答するよう構成し、このようなコマンドがない限りは、安全性リスクが高いものと認知される。幾つかの実施形態において、システムは、後方運転者がアクセルペダルを少なくとも閾値期間（例えば、２秒であるが、より長い又は短い閾値期間を所望により利用することもできる）にわたり踏む場合／時点で制御を断念するよう構成することができる。他の実施形態において、システムは、後方運転者がアクセルペダルを踏み込むときはいつでも制御を断念するよう構成することができる。運転者がアクセルペダルに触れるときいつでも制御を断念することの欠点は、アクセルペダルに不慮に触れることが望まない解消をトリガするリスクを高める点にある。他方、単なるコマンド受け取りによる遅延なしに（例えば、通常運転のようにアクセルペダルを作動させることによって）後方運転者が制御を引き継ぐことを可能にするのが望ましい。
【0127】
隊列走行中及び／又は解消中にアクセルペダル又はブレーキペダルからの入力を開始した運転者に対する後方隊列走行コントローラの応答は、コントローラがとっている状態（例えば、後方隊列走行維持状態又は後方隊列走行解消状態）に基づいて異なることがあり得る。例えば、これら状態のいずれかでブレーキペダルが作動する場合、コントローラは、隊列走行コントローラによって指令される（例えば、制動リクエストコントローラ４２２３）制動量及び運転者がブレーキペダルを踏むことによって指令される制動量より大きい量に対応する制動量を加えるよう設計することができる。このような構成によれば、より積極的な制動コマンドを利用することを確保する。後方隊列走行維持状態でブレーキペダルを踏むことによれば、後方隊列走行解消状態３６５１への遷移を開始することもできる。
【0128】
隊列走行コントローラが隊列走行状態又は解消状態のいずれかにある間に、アクセルペダルが後方運転者によって作動させられる場合も、幾分同様に、より大きいつの入力を使用することができる。すなわち、システムは、隊列走行コントローラ（例えば、トルクリクエストコントローラ４２２１）によって指令されるトルク及び運転者がアクセルペダルを踏むことによって指令されるトルク量より大きいトルクリクエストを実装するよう設計することができる。隊列走行コントローラが後方隊列走行維持状態３６４９にある間にアクセルペダルが第１閾値期間にわたり踏み込まれる場合、後方解消状態３６５１に遷移することなく、手動制御が可能になり得る。このような状況においては、後方隊列走行コントローラは後方ランデブー状態３６４３に直接戻る遷移をすることができる。
【0129】
解消中、隊列走行コントローラは後方車両を制御し、上述したように前方トラックに対して後退させる。間隔が余裕のある距離に達したとき、後方運転者はアクセルペダルを踏むことによって解消から脱する遷移をすることができ、またこれにより制御を引き継ぐことができる。運転者が制御を引き継いだ後、隊列走行コントローラは後方ランデブー状態３６４３に遷移する。起こりそうもないが、解消を完了するために運転者がアクセルペダルを踏まないことがあり得る。この場合、隊列走行コントローラは後続車両に対して隊列走行が終了する最大隊列走行距離（例えば、１００メートル又は他の適切な閾値距離）に落し戻し、また隊列走行コントローラはランデブー状態に遷移する。このような時点において、隊列走行コントローラ又は運転者のどちらもいかなるトルクリクエストをすることなく、このことは車両を惰性で運行させる。
【0130】
解消中に後続車両の運転者が解消完了前に隊列走行を再確立したほうがいいと思う時もある。解消状態は、好適には、隊列走行の再関与が任意な特定状況で許容されるか否かを決定する論理を含む。概して、解消から直接隊列走行への再関与は、再関与が望まれる時点で解消から再関与することに関連する隊列走行チェックのすべてが合格する場合（及び好適には、そのような場合のみ）、許容され得る。好適には、後続車両の運転者の断定的な行為が隊列走行の再関与に必要となる。例えば、運転者は、隊列走行ボタンを押す、又はシステム設計者が指定した任意な他の適当な入力によって隊列走行の再関与をトリガすることができる。
【0131】
先に示唆したように、解消状態であっても種々の隊列走行チェックを継続して実行する。いずれかの隊列走行チェックが不合格である場合、１つ又はそれ以上の隊列走行モニタの再関与チェックが「不合格」状態であるときはいつでも、隊列走行は解消から直接再開することができない。しかし、解消中にすべての隊列走行モニタ再関与チェックが合格する条件に状況変化する場合、その時点で再関与が可能になる。幾つかの実施形態において、チェックのすべてが合格するとき、隊列走行ボタンは点灯して、運転者に対して隊列走行の再関与が許容可能であることを指示する。
【0132】
解消状態は様々な異なる様態でトリガすることができる。幾つかの実施形態において、いずれかの運転者は、いつでも隊列走行コントローラのインタフェースにおける適切なボタン（幾つかの実施形態においては、ダッシュボード上又は隊列走行コントローラ上のボタンとすることができる）を押すことによって解消をトリガすることができる。隊列走行コントローラは、さらに、１つの隊列走行チェックにおける不合格を検出することに応じて車両自体における解消を開始することができる。
【0133】
解消が前方運転者からのリクエストによってトリガされた場合、前方コントローラの状態は前方ランデブー状態に戻り、双方パートナーからの同意更新を含むハンドシェイクルーチン全体を経ることなしには、その隊列走行に再関与できない。しかし、解消がシステム又は後続車両運転者の行為によってトリガされる場合、すべての隊列走行チェックが行われ、かつ後続車両の運転者が再関与を選択する場合及び時点で、隊列走行の再関与をすることができる。
【0134】
図３７につき上述した実施形態は、後続車両における手動制御から部分的自動制御への遷移を含めて運転者がプロセスに能動的に参加することを予期しており、また少なくとも後続車両運転者は手動制御に戻る遷移に参加する。しかし、当然のことながら、隊列走行が異なる自動制御状態から開始するとき、同様のプロセスを採用することができる。このような事情において、本明細書に記載の運転者相互作用は、アクティブコントローラ、例えば、アクティブ・クルーズ・コントロール（ＡＣＣ）システムによって容易になり得る。
【0135】
上述したように、システムにアクティブ隊列走行の準備が完了するには多数の条件が合致しなければならない。パートナー各々が「隊列走行準備完了」になる前に合致しなければならない特別な条件は、システムに基づいて幅広く変動し得る。例えば、幾つかの特別なチェックを図３８につき説明する。概して、チェックのうちいずれか１つ又はそれ以上が不合格である場合、システムは隊列走行の準備が完了しておらず、これに対応の隊列走行コントローラは、条件がすべてのチェックが合格するに十分変化しない限り、また十分変化するまでは関連するランデブー状態３６２３，３６４３からシステム準備完了状態３６２５，３６４５に遷移できない。好適には、このチェックは、隊列走行コントローラがシステム準備完了状態又は隊列走行準備完了状態に遷移した後であっても継続し、これによりシステムは隊列走行の妥当性に悪影響を及ぼす変化に気付くようになる。関連の隊列走行コントローラがシステム準備完了状態又は隊列走行準備完了状態になった後にチェックが不合格となる場合、隊列走行コントローラは適切なランデブー状態３６２５，３６４５に戻る遷移をし、またパートナー車両はその遷移の情報を受け取り、条件の変化を独立的に検出することに基づいてその戻り遷移をしていない場合に、そのパートナー車両自体もランデブー状態に戻る遷移を行う。
【0136】
チェック（全般的に同様なチェックのセット）は、好適には、隊列走行コントローラが隊列走行維持状態３６２９，３６４９に遷移した後であっても継続する。アクティブ隊列走行制御中にチェックが不合格になる場合、隊列走行コントローラは、典型的には隊列走行の解消を編成する隊列走行解消状態３６３１、３６５１に遷移する。幾つかの実施形態において、チェックは、常にオン状態のモニタとしてセットアップされ、また関連の条件が合致しないときアラートを送信し、フラグを立てる又はそのことを示すことができる。
【0137】
次に図３８につき説明すると、これは、特定隊列走行チェックを実施するモニタのセットである。図示のモニタの多くは後方隊列走行コントローラが利用して、条件が隊列走行に適切であるかを検証する。特定のモニタセットを説明するが、記載のモニタは説明目的で示されており、特別な実施形態ではすべてのモニタを設ける必要はなく、新たな又は付加的なモニタを設けることができる、及び／又は記載されるモニタの機能性も任意の特別なコントローラの必要性に合わせて変化し得るものである。さらに、多数の個別モニタを図示するが、当然のことながら、記載のモニタ及び他のモニタの機能性は任意な所望の様態で組み合わせることができ、また専用モニタで記載される機能性を提供する必要はない。むしろ、類似のチェックは隊列走行コントローラによってアルゴリズム的に又は任意な他の所望様態で実施することができる。
【0138】
図３８の実施形態において、レンジモニタ３８４１はパートナー間の距離を監視する。このモニタはさらにパートナー車両（すなわち、先行車両）がアクティブ隊列走行レンジ内にあるか否かをチェックするよう構成されている。車両が互いに指定レンジ内にあるときのみアクティブ隊列走行を始めるのが望ましいことがよくある。許容される特定レンジは、所望制御の性質、それぞれに対応する隊列走行コントローラに利用可能な技術、及び隊列走行を開始する時点での運転環境（例えば、道路状況、交通量等）に基づいて幅広く変動し得る。例えば、車両が一列になっているとき（例えば、同一レーンで互いに追従する）５～１０メートルのオーダーにある離間量は、多くの用途でうまく機能する傾向にある。このような場合、モニタ３８４１が実施するパートナーインレンジチェックは、先行車両が後続車両の先に１００メートルより大きい距離にいる場合に不合格とする。同様に、モニタ３８４１が実施するパートナーインレンジチェックは、指定先行車両がホスト（指定後方）車両の背後にいる、又はホスト（指定後方）車両の先に５メートル未満の距離にいる場合に不合格とする。
【0139】
所望であれば、モニタ３８４１が実施するパートナーインレンジチェックは、車両が側方に（例えば、異なるレーンに）オフセットしているときも同一とすることができ、車両が異なるレーンで互いに並走しているとき隊列走行コントローラが関与するのを除外することもある。しかし、幾つかの場合、車両が側方にオフセットしているとき若干異なる閾値を使用するのが望ましいことがあり得る。とくに、車両が異なるレーンで互いに前後する間に隊列走行制御の開始を可能にするのが適切なことがあり得、これにより「後方」車両は隊列走行を始める前に必ずしも後退する必要がないようにする。車両が互いに並走している間に隊列走行を可能にすることは、アクティブ隊列走行中、最初は後続車両であった車両が先頭をとるよう隊列走行パートナーが位置交換するときにも有用である。
【0140】
隊列走行レンジの外側限界は、それぞれに対応する隊列走行パートナーの能力に部分的に依存し得る。実際上、現今のトラックにおける標準レーダー装備は、１００メートルより相当大きい距離で隊列走行制御に良好な測定を行おうとするものではなく、単に比較的狭い視界内で車両の前方を見るように構成されているだけである。同様に、現今の標準ＤＳＲＣシステムは１５０メートルより相当大きい距離で信頼性が高すぎる傾向にはなっていない。これらタイプの装備限界は、車両が一層離れている又は互いの視界内に入っていないときのアクティブ隊列走行の実用性を制限する。しかし、利用可能な装備の能力が向上し続けるとき、アクティブ隊列走行の容認可能なレンジが拡大することが予想される。１００メートルの最大レンジも、隊列走行制御がアクティブ状態ではないときの車両の手動オペレータ制御、及び自動化又は部分的に自動化された制御が始まる前の断定的な運転者の選択を想定している本明細書に記載の隊列走行システムでうまく機能する。これはすなわち、後続車両の運転者は一般的には制御をシステムに転移させる前に十分１００メートルのレンジ内に位置しようと思うからである。
【0141】
モニタ３８４３及び３８４４はそれぞれパートナー車両及びホスト車両の速度を監視する。これらモニタは、さらに、先行車両及びホスト車両がそれぞれ隊列走行に適した速度で現在走行しているか否かをチェックするよう構成される。隊列走行に適した特定車両の速度は状況に基づいて大きく変動し得る。例えば、前方車両は毎時５６.３～１１２.７ｋｍ（３５～７０マイル）のオーダーの速度が幾つかの状況／用途で適切であることが分かっている。後続車両における隊列走行コントローラは、ホスト車両の速度及び車両間の測定した（例えば、レーダーユニット、１つ又はそれ以上のカメラ、ライダー、又は他の適当な距離及び相対速度測定技術によって測定した）相対速度に基づいて先行車両の速度を決定することができる。測定した速度は、車両間のＤＳＲＣ（又は他の）通信の一部として先行車両によって報告される速度との比較によって検証することもできる。
【0142】
後続車両は、僅かに大きい許容隊列走行速度レンジを有することが可能であり、これはすなわち、先行車両に対して追い付く（又は後退する）必要があるからである。したがって、後続車両の適当なレンジは、同様な用途に対して毎時５３.１～１１７.５ｋｍ（３３～７３マイル）のオーダーであり得る。勿論、先行車両及び後続車両に対する特定許容隊列走行速度及び許容可能なレンジの相対的スケールは、道路状況、交通量条件、速度制限、車両能力、車隊管理優先度、運転者優先度等を含む様々な広範囲の要因に基づいて幅広く変動し得る。
【0143】
モニタ３８４６は前方車両に対する後続車両の相対速度を監視する。相対速度モニタは、さらに、車両の相対速度が隊列走行に適した範囲内であるか否かをチェックするよう構成することができる。概して、車両が互いに比較的接近しているが、大きく異なる速度で走行している場合、隊列走行を開始するのは望ましくない。やはり、特定レンジは幅広く変動し得るものの、５ｍ／秒又は毎時１６.１ｋｍ（１０マイル）を超えない速度差が幾つかの状況で適切であり得る。幾つかの実施形態において、許容される速度差は、部分的に車両が離れている縦方向距離に基づくものであり得る。
【0144】
モニタ３８４８及び３８４９は、それぞれパートナー車両及びホスト車両の加速度レベルを監視する。加速度モニタは、さらに、先行車両及び後続車両が指定量よりも多く減速（制動）しているか否かをチェックするよう構成することができる。このことは、指定減速閾値（例えば、－１ｍ／ｓ２を超えない）又はたの適切な閾値を意味することができる。代替的又は付加的に、他のモニタ３８５０は、どの隊列走行コントローラが現時点で制動リクエストを出しているかを監視するよう構成することができる。このモニタは、さらに、現時点での隊列走行開始が後続車両の隊列走行コントローラに対して特定閾値を超える制動コマンドを発生させるか否かをチェックするよう構成することができる。後者の手法に関しては、間隔レギュレータの制御アルゴリズムは、パートナーが識別された後のランデブー状態で、又は隊列走行が実際に開始されない、すなわち、後方隊列走行コントローラがステップ３７３３で隊列走行状態に（例えば、後方隊列走行維持状態３６４９に）遷移しない限り又は遷移するまではその出力が使用されない他の適切な時点で、開始を実行することができる。しかし、間隔レギュレータの制御アルゴリズムは、隊列走行が始まる前に実行されるため、その制動コマンド出力は、現時点で制動閾値を超えていないことを確かめるようチェックすることができる。
【0145】
モニタ３８５２お３８５３は、それぞれパートナー車両及びホスト車両の通信の完全性を監視する。そのプロセスの一部として、それらモニタは、制御チャネル通信がパートナー車両及びホスト車両のそれぞれで安定しているか否かをチェックする。本明細書に記載する隊列走行制御はパートナー車両からのデータを使用するため、車両間で情報が頻繁に送信され、しばしばほとんど連続的送信を基本としている。いずれか一方の車両におけるコントローラが他方からの通信を期待通りに受信していないこと、又はこのような通信が途切れることを決定する場合、その車両における制御チャネル通信安定性チェックは不合格となる。
【0146】
モニタ３８５５は追跡ユニットを監視する。この追跡ユニットモニタはさらに、追跡ユニット（例えば、レーダーユニット４１３７）が先行車両の位置を決めるか否かをチェックするよう構成することができる。参照により本明細書に組み入れられるものとする、米国特許出願第１５／５９０，７１５号及び同第６２／４８９，６６２号は、パートナー車両に対するレーダー位置決定を取得しまた維持する幾つかの適当な技術について記載している。追跡ユニットが先行車両の位置決定をしない場合、追跡ユニット位置決定のアクティブチェックは不合格となる。利用可能な複数の異なる追跡ユニット（例えば、２つ又はそれ以上のレーダー、ＬＩＤＡＲ、カメラ、又は他の測距技術を利用するトラッカー）を有する実施形態においては、モニタ３８５５は、トラッカーのうちすべて、幾つか、又は少なくとも１つがパートナー車両の位置を決定してシステム設計者の選好に基づいてチェックを合格することを必要とするよう構成することができる。
【0147】
割込みモニタ３８５７は、先行車両と後続車両との間における割込み車両の存在を検出するよう構成される。概して、車両が隊列走行パートナー間でインラインに存在する場合、隊列走行は始まることを許容されない。後続車両の運転者は、車両が車両間に存在していた場合には、又は観測した他の交通動向に基づいて割込みが生ずることを運転者が心配する場合には、隊列走行の準備ができていることを意味する隊列走行ボタンを押すことはないと期待される。しかし、割込みチェックは、安全性に関する余剰レベルを提供し、これはすなわち、車両が指定した隊列走行パートナー間にインラインで存在することを検出する場合、システムが準備完了と見なされるようになることを防止するからである。この割込みチェックは、アクティブ隊列走行制御中に割込み車両検出が解消状態への遷移をトリガするおそれがある場合に一層重要でさえある。
【0148】
レベル１の隊列走行では、トルクリクエスト及び制動が所望間隔を維持するよう自動的に制御されることがあり得る場合であっても、運転者は積極的に車両制御（操舵のような）に係わる。多くの場合、運転者は割込みが起こりそうな状況を認識し、また適切に対処できることが期待される。例えば、運転者は、他のレーンにいる車両の行動が隊列走行パートナー間に割り込みたい（例えば、突然近づく出口に出たい）と思っていることを示唆していると観測する場合があり得る。このことは、小さい車両間間隔で隊列走行している２台のトラック間に車両が割り込もうとしているとき特に危険な状況であり得る。運転者がこのような状況を検出する場合、適切な対処としては、未だ割込みが生じておらず、したがって、コントローラによって検出されていなくても、ブレーキを掛けることがあり得る。他の一般例は合流交通箇所であり、このような箇所では、合流する車両は隊列走行パートナー間に割り込む以外に選択はほとんどない。
【0149】
幾つかの実施形態において、隊列走行コントローラ、制動コントローラ、又は他の適当なコントローラは、隊列走行コントローラ自体が発生する任意な制動コマンド、及びブレーキペダルを踏む運転者が指令する任意な制動をより多く実装するよう構成される。このことは、運転者が検出されたイベントに応答する制動に従事するリスクを改善するのに役立つ。
【0150】
ＣＭＳモニタ３８５９は、衝突災害軽減システム（collision mitigation system）の状態を監視する。多くの車両は、衝突のリスクが高い状況を検出するよう構成される衝突災害軽減システムを有し、この衝突災害軽減システムは、幾つかの実施形態において、衝突リスクを軽減する及び／又はその後に起こる衝突の衝撃を緩和するのに役立つ幾つかのレベルの自動制御を始動させる。ＣＭＳモニタは、どちらかの車両における衝突災害軽減システムがトリガされたか否かを検出する。ＣＭＳがトリガされるときには、隊列走行は開始することができない。幾つかの状況においては、通常の隊列走行制御（例えば、先行車両に至近距離で追従している）が衝突災害軽減システムをトリガする場合、後続車両における予めインストールされている衝突災害軽減システムを変更又は無効にするのが望ましい又は必要であり得ることに留意されたい。
【0151】
レーンモニタ３８６１は、前方車両前方のレーンを監視する。レーンモニタは、先行車両前方に懸念車両の存在を検出するよう構成される。概して、進行が遅い車両が先行車両前方に比較的近接していることを検出する場合、隊列走行制御にとって懸念事案である。したがって、幾つかの実施形態において、隊列走行制御は、先行車両パートナー前方に懸念車両を検出する場合には隊列走行制御を開始できないようにする。懸念車両チェックの不合格をトリガする特定閾値は、システム設計目的、隊列走行パートナーの重量及び制動能力、又は様々な他の要因に基づいて変動し得る。しかし、概して先行トラックが他の車両背後に至近距離にある及び／又は同一レーンで他の車両に急激に接近しつつある場合、制動及び潜在的に強引な制動を必要とすることが起こり易く、また一般的にこのようなリスク要因が存在するときに隊列走行を開始するのは望ましくない。やはり、前方車両の運転者は、懸案車両が存在するとき隊列走行準備完了ボタンを押す（ステップ３６２７）ことはありそうにない。しかし、システムはこのような状況に対するチェックを肯定的に行うことができ、またこのような障害物が存在する場合、システムは隊列走行準備完了と見なさない。同様に、先行車両前方における懸念車両検出は解消をトリガすることができる、又はこのようなイベント検出に応答して隊列走行コントローラが目標間隔を増大させるようにする。
【0152】
オフセットモニタ３８６３は、車両間の側方オフセットを監視するよう構成される。様々なチェックは、車両間の検出された側方オフセットに基づくものであり得る。オフセットモニタが実施する１つのチェックは、隊列走行パートナーが異なるレーンで走行していることの決定に基づく。とくに、パートナー同士が側方にオフセット状態で（例えば、隣接レーンで）運転している状態で他の車両が後続車両と同一レーンで後続車両前方に比較的接近している場合、隊列走行開始を許容するのは望ましくないことがあり得る。やはり、これら状況の下での隊列走行を阻止するトリガとして使用される特定閾値距離／相対速度等は幅広く変動し得る。
【0153】
ネットワーク・オペレーション・システム（ＮＯＣ）のような中央システム又は何らかの他のシステムによる承認を必要とする用途において、前方車両及びホスト車両の双方が隊列走行に対して承認されているか否かの他のチェックを行うことができる。ＮＯＣモニタ３８６５はこのチェックを実施するよう構成することができる。
【0154】
パートナー状態モニタ３８６７はパートナー車両の状態を監視する。パートナー状態モニタが実施する１つのチェックは、後方隊列走行コントローラが所定状態に遷移できる前に先行車両が適正状態にあることを検証することである。例えば、前方隊列走行コントローラは、後方隊列走行コントローラが後方システム準備完了状態３６４５に遷移できる前には、前方システム準備完了状態３６２５でなければならない。同様に、前方隊列走行コントローラは、後方隊列走行コントローラが後方隊列走行準備完了状態３６４７に遷移できる前には、前方隊列走行準備完了状態３６２７でなければならない。逆に、後方隊列走行コントローラは、前方隊列走行コントローラが前方隊列走行準備完了状態３６２７に遷移できる前には、後方システム準備完了状態３６４５でなければならない。隊列走行システム準備完了状態（例えば、前方システム準備完了状態）。このチェックは、図３７につき詳述したハンドシェイクプロトコルの局面を補強するのに役立つ。
【0155】
図３８につき説明した実施形態において、モニタ３８４１～３８６７はすべて各車両に存在し、必要になったときそれらに対応のチェックを行うことができる。それぞれ詳述したそれら特定モニタは、後続車両制御に関連するチェックを実施する。概して、異なる一連のチェックは、ホストが先行車両を指名されるとき実施され、先行車両がシステム隊列走行準備完了であることを検証する。先行車両チェックは、冗長的に後続車両が実施する幾つかの同一チェック及び特定状況で適切であると見なされる任意な他のチェックを含むことができる。例えば、幾つかの実施形態において、(i) 先行車両におけるホスト速度モニタ３８４５は、後続車両速度モニタが実施する速度チェックに類似のチェック（その速度が隊列走行を許容される速度内であるかを検証する）を実施することができる、(ii) 先行車両におけるホスト通信モニタ３８５３は、後続車両通信モニタが実施する通信チェックに類似のチェック（その制御チャネル通信が安定的であるかを検証する）を実施することができる、(iii) 前方車両におけるレーンモニタ３８６１は、先行車両前方に懸念車両が存在するか否かを決定し、先行車両におけるＮＯＣ承認モニタ３８６５も必要に応じて隊列走行が承認されているか否かを検証する。勿論、先行車両及び先行車両モニタが実施する特定チェックは、先行車両が利用可能な情報及びセンサ、システム設計者の選好等のような要因に基づいて幅広く変動し得る。
【0156】
当然のことながら、本明細書に記載のモニタ及びチェックは実際例示的なものである。したがって、本明細書に記載の様々なモニタ及びチェックはうまく機能すると分かっているが、当然のことながら、記載されたチェックのすべてが任意の特定実施形態で必要ではなく、記載されたチェックとは別の適切な又は変更されたチェックも、本明細書記載の特定チェックに付加して、又はそれらの代わりに用いることができる。
【0157】
モニタは、隊列走行コントローラがアクティブ（例えば、起動後の）状態にあるとき常にオン状態になるのが好適である。上述したように、概して、隊列走行コントローラがランデブー状態からシステム準備完了状態、隊列走行準備完了状態、及び／又は隊列走行維持状態に、並びに隊列走行解消状態にさえ遷移した後に、隊列走行適合性チェックを実施し続けるのが望ましい。記載したモニタ及びチェックの大部分は、これら状態各々において稼働するのが適切であるが、幾つかの状況においては、モニタチェックに関連する制約又は閾値は隊列走行コントローラの現状態に基づいて変動し得る。したがって、モニタは、それら種々のチェックの結果及び他の出力がすべての状態に関連するものではない場合であっても、隊列走行コントローラがアクティブ状態であるとき連続的に稼働するのが好ましい。モニタを常にアクティブ状態にすることは、その結果を必要なときはいつでも隊列走行コントローラに即座に利用可能となることを意味する。
【0158】
先に示唆したように、不合格をトリガする特定閾値又は範囲（レンジ）は隊列走行コントローラの状態に基づいて変動し得る。このような変動は、コントローラがトリガ近接レベルで動作中に状態間振動する蓋然性を減少するため、所定程度のヒステリシスを含むよう設計することができる。例えば、承認された前方車両速度が隊列走行を開示するための毎時５６.３～１１２.７ｋｍ（３５～７０ｍｐｈ）の範囲内である場合、速度が範囲限界に近似するときの合格と不合格との間でチェックが交互に切り替わる蓋然性を減少するよう、隊列走行準備状態及び隊列走行状態を維持するため、僅かに大きい範囲が適切であり得る。所定程度のヒステリシスは、他のチェックにも適用することができる。
【0159】
アクティブ隊列走行制御中にチェックが不合格である場合、隊列走行コントローラは、典型的には隊列走行の解消を司る隊列走行解消状態３６３１、３６５１に遷移する。当然のことながら、解消に遷移させるトリガは、コントローラが隊列走行制御を開始する準備が完了していないことを示すトリガとは異なるものであり得る。例えば、通信の短時間途絶（例えば、１秒の半分又はそれより短い時間の途絶）はコントローラがランデブー状態にあるとき通信安定性テスト３７５２、３７５３を不合格にするのに十分であり得る。しかし、アクティブ隊列走行制御中、運行条件が安全かつ安定的範囲にあるときは解消をトリガすることなしに、より長い（例えば、１秒又は２秒の）通信途絶の生起を許容するのが望ましいものであり得る。
【0160】
他の実施例において、車両が異なるレーンにある状態でアクティブ隊列走行を継続する時間量を（例えば、２０秒、１分、５秒等に）制限するのが望ましいことがあり得る。この制約は、車両が側方にオフセットする時間量を追跡するオフセットモニタ３８６３によって強要され、またレーンオフセットが指定閾値期間を超えて持続されたか否かを見るチェックを実装することができる。幾つかの設計においては、システムが隊列走行準備完了と見なされるための側方オフセット運行に対して同様の制約を持たせるのが望ましいものであり得る。しかし、他の用途では、隊列走行開始中の側方オフセットは推奨される（例えば、ランデブー状態、システム準備完了状態、及び隊列走行準備完了状態で車両が側方オフセットしている時間に何ら制約を設けないことにより）、又は一層禁止する（例えば、側方オフセットを検出した場合に不合格となるチェックを使用することにより）こともあり得る。このように、当然のことながら、車両が側方にオフセットする状態で隊列走行が許容される時間量は、システム設計目的に基づいて幅広く変動し得る。
【0161】
幾つかの場合、所定条件検出は、採用する隊列走行制御のタイプの変化をトリガし得る。例えば、先行車両がアクティブ隊列走行制御中にレーン変更して後続車両から側方にオフセットする場合、トラッカーはもはや先行車両の背後を「見る」ことができない。通信が安定している場合、間隔制御モードから相対速度制御モードに遷移するのが望ましく、これにより後続車両を制御された割合で後退させ、最終的に解消をトリガすることなく追跡ユニットによって先行車両の背後を再び「見る」ことを可能にすることができる。しかし、他のチェック又はトリガを使用して、追跡ユニットが前方車両の背後を再探索できるようにすることをせず、過剰な時間量が経過する場合、解消を開始することができる。
【0162】
他の実施例において、幾つかの状況又はイベントの検出は、隊列走行中に目標間隔を増大（又は短縮）するのが適切であり得る。例えば、隊列走行とほぼ同一速度で走行している先行車両の前方に交通量があり、ただし所望よりも近接している場合、１つの適切な対処としては隊列走行パートナー間の間隔を増大させることがあり得る。勿論、幅広い様々な他の制御スキームも容易に採用することができる。
【0163】
チェック（又は一般的に類似したチェックのセット）は、好適には、隊列走行コントローラが隊列走行維持状態３６２９，３６４９に遷移した後であっても継続する。アクティブ隊列走行制御中にチェックが不合格である場合、隊列走行コントローラは、典型的には隊列走行の解消を司る隊列走行解消状態３６３１、３６５１に遷移する。
【0164】
代案的隊列走行コントローラアーキテクチャの実施形態を図３９に図式的に示す。図示のアーキテクチャは、隊列走行するトラクタ・トレーラ式のトラックで使用するのが好適である。図示の特別なコントローラは、主として、双方の車両が能動的運転者を有する隊列走行システムに関連して使用するよう設計され、先行車両の運転者が前方車両の制御に責任を負う。後続車両の運転者は後続車両を操舵する責任を負うが、隊列走行コントローラ４１１０が、主にアクティブ隊列走行中における後続車両のトルクリクエスト及び制動リクエストを制御する責任を負っている。しかし、当然のことながら、概して同様の制御スキームは、隊列走行パートナーのうち一方又は双方に対するより多く自動化した又は全自動化した制御を考慮しているシステムに使用することができる。
【0165】
図３９に示す実施形態において、隊列走行コントローラ４１１０は、トラクタ及び／又は１台若しくはそれ以上の台数のトレーラにおける多数のセンサ４１３０若しくは他の接続ユニットからの、並びにトラクタのパワートレイン及び他の車両システムの動作を制御するよう構成されたアクチュエータ若しくはアクチュエータコントローラ４１５０からの入力を受信する。アクチュエータインタフェース４１６０は、隊列走行コントローラ４１１０及びアクチュエータコントローラ４１５０との間における通信を容易にするために設けることができる。隊列走行コントローラ４１１０は、さらに、隊列走行パートナーとの通信を司る車両間通信コントローラ４１７０及びネットワーク・オペレーション・センター（ＮＯＣ）との通信を司るＮＯＣ通信コントローラ４１８０に対して相互作用する。車両は、さらに、好適には、車両に関する既知の情報を含む環境設定ファイル４１９０を選択している。
【0166】
隊列走行コントローラ４１１０における幾つかの機能コンポーネントは、間隔コントローラ４１１２、種々のエスティメータ（推定器）４１１４、１つ若しくはそれ以上のパートナー車両トラッカー（追跡器）４１１６、及び種々のモニタ４１１８を有する。多くの用途において、隊列走行コントローラ４１１０は様々な他のコンポーネント４１１９を有する。隊列走行コントローラ４１１０及び間隔コントローラ４１１２の例示的実施形態を図４０及び４１につき以下により詳細に説明する。
【0167】
隊列走行コントローラ４１１０が利用する幾つかのセンサとしては、ＧＮＳＳ（ＧＰＳ）ユニット４１３１、ホイール（車輪）速度センサ４１３２、慣性測定装置４１４３、レーダーユニット４１３７、ＬＩＤＡＲユニット４１３８、カメラ４１３９、アクセルペダル位置センサ４１４１、ハンドル（ステアリングホイール）位置センサ４１４２、ブレーキペダル位置センサ４１４３、及び種々の加速度計４１４４があり得る。勿論、これらセンサのすべてが隊列走行に係わるすべての車両に利用可能ではなく、またこれらセンサのすべてが任意な特定の実施形態で必要となるわけではない。様々な他のセンサ４１４９（既存の又は将来開発される又は市場に展開されている）も、付加的又は代案的に他の実施形態における隊列走行コントローラが利用することができる。本明細書に記載の主要な実施形態において、ＧＰＳ位置データを使用する。しかし、ＧＰＳは現在利用可能な全地球的航法衛星システム（ＧＮＳＳ）のうちの１つでしかない。したがって、当然のことながら、任意な他のＧＮＳＳシステムからの、又は他の適当な位置検知システムからのデータをＧＰＳシステムに代えて又はＧＰＳシステムに付加して使用することができる。
【0168】
ホイール速度センサ４１３２、レーダーユニット４１３７、アクセルペダル位置センサ４１４１、ハンドル位置センサ４１４２、ブレーキペダル位置センサ４１４３、及び加速度計４１４４を含めて本明細書に記載したセンサの多くは、半トレーラを牽引するのに使用される新しいトラック（トラクタ）において比較的標準装備である。しかし、ＧＮＳＳユニット４１３１及びＬＩＤＡＲユニット４１３８（もし使用されるならば）のような他のユニットはこのようなトラクタには現在のところ標準装備ではなく、特定車両には存在しておらず、また隊列走行支援に役立てるのに必要又は所望に応じて設置することができる。
【0169】
隊列走行コントローラが少なくとも部分的に監督する幾つかの車両アクチュエータコントローラ４１５０は、エンジントルクコントローラ４１５２（しばしばエンジン制御ユニット（ＥＣＵ）又はパワートレイン制御モジュール（ＰＣＭ）の統合化した機能性の一部である）、変速機コントローラ４１５４、ブレーキコントローラ４１５６、操舵コントローラ４１５７（自動操舵が提供されているとき）、及びクラッチコントローラ４１５８を含む。勿論、これらセンサのすべてが任意な特定の実施形態で利用可能ではなく、また必要となるわけではなく、制御される車両に利用可能となり得る様々な他の車両アクチュエータコントローラ４１５９とインタフェースをとるのが望ましいこともある。したがって、当然のことながら、任意の特別な制御される車両における隊列走行コントローラによって監督される又は利用される特別なアクチュエータコントローラ４１５０も幅広く変動し得る。さらに、任意の特別なアクチュエータコントローラ（例えば、エンジントルクコントローラ４１５２）の能力、並びにそのインタフェース（例えば、コマンド、命令、リクエスト及びメッセージの性質及びフォーマットを取り扱うことができる又は発生することができる）も、しばしばその特別なアクチュエータコントローラの製造及びモデルとともに変動する。したがって、アクチュエータインタフェース４１６０は、好適には、隊列走行コントローラ４１１０からのリクエスト、コマンド、メッセージ及び命令を、制御される車両で利用された特別なアクチュエータコントローラのハードウェア及びソフトウェアに適切なフォーマットに翻訳するために設けられる。アクチュエータインタフェース４１６０は、さらに、種々のアクチュエータコントローラから受信したメッセージ、コマンド及びリクエストを隊列走行コントローラ４１１０に戻す通信／翻訳を行うメカニズムを提供する。典型的には適切なアクチュエータインタフェースは、利用される特定車両コントローラの各々と相互作用するよう設けられる。種々の実施形態において、エンジントルクインタフェース４１６１、ブレーキインタフェース４１６２、変速機インタフェース４１６４、リターダ（補助ブレーキ）インタフェース４１６５（別個のリターダコントローラが使用される場合）、操舵インタフェース４１６７、及び／又は任意な他の適切なコントローラインタフェース４１６９のうち１つ又はそれ以上のインタフェースがあり得る。
【0170】
大型トラック及び他の大型車両は、しばしばトラックを「制動」するための複数のシステムを有する。これらのシステムとしては、車両のホイールに備え付けられた伝統的ブレーキ系統アセンブリを含み、これらは産業界で「基本ブレーキ」と称されることがよくある。多くの大型トラック／大型車両は、「リターダ」と称され、基本ブレーキを増強するのに使用されるメカニズムを有し、このリターダは車両を減速させ、車両が坂道を加速下降するのを防止する補助をする代替的メカニズムとして作用する。しばしば、このリターダはエンジントルクコントローラ４１５２によって制御され、またこのような実施形態において、リターダは適切なトルクコマンド（負の値であり得る）をエンジントルクコントローラ４１５２に送信することによって制御することができる。他の実施形態において、別個のリターダコントローラ（図示せず）もアクセス可能であり、またしたがって、適切なリターダインタフェース４１６５を介して隊列走行コントローラ４１１０によって監督され得る。
【0171】
車両間通信は、任意の適当なチャネル上で監督され、またまた車両間通信コントローラ４１７０によって連携されることができる。例えば、車両対車両通信用に開発された双方向近中距離無線通信技術である専用近距離通信（ＤＳＲＣ）プロトコルもうまく機能する。車両間でやりとりされる特別な情報は、隊列走行コントローラの必要に応じて幅広く変動し得る。
【0172】
車両間通信は、任意の適当なチャネル上で監督され、またまた車両間通信コントローラ４１７０によって連携されることができる。例えば、車両対車両通信用に開発された双方向近中距離無線通信技術である専用近距離通信（ＤＳＲＣ）プロトコル（例えば、IEEE802.11Pプロトコル）もうまく機能する。勿論、他の通信プロトコル及びチャネルもＤＳＲＣリンクに付加して又はそれに代えて使用することができる。例えば、車両間通信は、付加的又は代替的に市民バンド周波数帯チャネル、１つ若しくはそれ以上の一般移動無線サービス（ＧＭＲＳ）帯域、及び１つ若しくはそれ以上の家庭用無線サービス（ＦＲＳ）帯域、又は任意な他の既存の若しくは将来開発される任意の適当な通信プロトコルを用いる通信チャネル上で送信することができる。
【0173】
種々の実施形態において、送信される情報は、リクエストされた／指令されたエンジントルク４２８０、リクエストされた／指令された制動減速４２８２のような隊列走行コントローラ４１１０が発生した現時点コマンドを含むことができる。それら情報としては、操舵コマンド、ギアコマンド等も含むことができ、それらの局面は隊列走行コントローラ４１１０によって制御される。対応する情報は、それらコマンドがパートナー車両における隊列走行コントローラ又は他の適当なコントローラ（例えば、車間距離適応走行制御システム（ＡＣＣ）若しくは衝突災害軽減システム（ＣＭＳ））によって、又は例えば、運転者入力（例えば、アクセルペダル位置、ブレーキ位置、ハンドル位置等）に応答する他のより伝統的なメカニズムを介して発生したものか否かに係わらず、パートナー車両から受信される。
【0174】
多くの実施形態において、隊列走行コントローラ４１１０に提供されるトラクタセンサ情報の大部分又はすべては隊列走行パートナーにも送信され、また対応する情報は隊列走行パートナーから受信され、これにより各車両における隊列走行コントローラ４１１０は、パートナー車両が行っている正確なモデルを展開することができる。このことは、隊列走行コントローラに関連する任意の車両形態情報４１９０を含む、隊列走行コントローラに提供される任意な他の関連情報に対しても言える。当然のことながら、送信される特定情報は、それぞれの車両で利用可能な隊列走行コントローラ４１１０、センサ及びアクチュエータの要件、及び各車両がその車両自体に関して持っている特定認識に基づいて幅広く変化し得る。
【0175】
車両間で送信される情報は、さらに、意図するその後の行動についての情報も含み得る。例えば、先行車両が坂道に接近しつつあることを知る場合、近い将来トルクリクエストが増大することが予期され、その情報は、後続車両の隊列走行コントローラ４１１０が適切に使用するため後続車両に伝達することができる。勿論、将来トルク又は制動のリクエストを予想するのに使用できる幅広い様々な他の情報もあり、その情報は種々の異なる形式で伝達することができる。幾つかの実施形態において、予期されるイベント自体の性質（例えば、坂道又はカーブ又は出口が近づいている）は、このようなイベントの予想時刻とともに表示することができる。他の実施形態において、意図されるその後の行動は、予期される制御コマンドの内容、例えば、予期されるトルク及び／又は他の制御パラメータ、並びにこのような変化が予想される時刻として報告することができる。勿論、隊列走行制御に関連し得る予想イベントの幅広い様々な異なるタイプがある。
【0176】
車両とＮＯＣとの間における通信は、セルラーネットワーク、様々なＷｉ-Ｆｉネットワーク、衛星通信ネットワーク及び／又は適切な任意の様々な他のネットワークのような種々の異なるネットワーク上で送信することができる。ＮＯＣとの通信は、ＮＯＣ通信コントローラ４１８０によって連携することができる。ＮＯＣに対して送信及び／又は受信される情報は、全体的システム設計に基づいて幅広く変化し得る。幾つかの状況において、ＮＯＣは、目標間隔公差のような特定制御パラメータを提供することができる。これら制御パラメータ又は制約は、ＮＯＣで知得された速度制限、道路／地形の性質（例えば、有勾配か平坦か、曲がりくねっているか真直ぐか、等々）、気象条件、交通量又は道路状況、等々のような因子に基づくことがあり得る。他の状況において、ＮＯＣは、このような情報を隊列走行コントローラに提供することができる。ＮＯＣは、さらに、形態情報を含むパートナー車両に関する情報、重量、トレーラ長さ等のような現運行状態に関する任意な既知の関連情報を提供することができる。
【0177】
形態ファイル４１９０は、コントローラに関連して考慮し得るホスト車両に関する幅広い様々な情報を含むことができる。例えば、幾つかの情報としては、エンジン性能特性、利用可能なセンサ、制動システムの性質、運転台前方に対するＧＮＳＳアンテナの場所、ギア比、差動比のようなものを含む車両仕様があり得る。
【0178】
図４０は、隊列走行コントローラ４１１０の特別な実施形態を示す。図示の実施形態において、隊列走行コントローラ４１１０は、間隔コントローラ４１１２、複数個のエスティメータ４１１４、１つ以上のトラッカー４１１６、任意な所望のモニタ４１１８、及び潜在的に任意な種々の他のコンポーネント４１１９を含む。
【0179】
図示の実施形態において、間隔コントローラ４１１２は、目標及び状態セッター（設定器）４２００、間隔レギュレータ４２１０、及び間隔エスティメータ（推定器）４２４０、を有する。概して、目標及び状態セッター４２００は、間隔レギュレータ４２１０の意図する運行モード（状態）、及びその運行モードに使用するのに適切な任意な可変制御パラメータの値を決定するよう構成される。
【0180】
間隔レギュレータ４２１０は、目標及び状態セッター４２００によって指定されたように後続隊列走行パートナーを制御するよう構成される。間隔制御動作モードにおいて、間隔レギュレータ４２１０は、状態セッター４２００によって特定された任意な指定制御パラメータに従って、所望間隔を達成及び維持することを見出すよう車両を制御する。他のモードにおいて、間隔レギュレータ４２１０は、選択された動作モードに対する適切応答を達成するのを見出すように車両を制御する。
【0181】
間隔エスティメータ４２４０は、隊列走行コントローラ４１１０に利用可能な実際の測定値及び／又は他の情報に基づいて現在間隔を推定／決定するよう構成される。現在間隔を正確に把握することは間隔レギュレータがうまく動作する上で重要である。同時に、当然のことながら、任意な測定システムは、固有の公差を有しており、また何らかの状況において、誤差の報告を受けることができる及び／又は利用不能になり得る。したがって、間隔エスティメータ４２４０は、センサに関連する複数位置又は相対位置からの情報を受信し、またこれらデータを現在間隔の信頼性高い推定に融合するよう構成される。
【0182】
間隔レギュレータ４２１０が発生するトルク及び制動リクエストは適切なアクチュエータインタフェース（例えば、エンジントルクインタフェース４１６１及びブレーキブレーキ４１６２それぞれ）に送信される。エンジントルクインタフェース４１６１はこのとき適切なトルクコマンドをエンジントルクコントローラ４１５２に転送し、このエンジントルクコントローラ４１５２は、燃料チャージ、バルブタイミング、リターダ状態等々のような種々のエンジン動作パラメータを指示することによってリクエストされたトルクの送給を適切に指示する。ブレーキインタフェース４１６２は、ブレーキコントローラ４１５６に送信される適切な制動リクエストを発生する。
【0183】
間隔コントローラ４１１２の特別な実施形態を以下に図４１につきより詳細に説明する。
【0184】
図４０に戻って説明すると、間隔コントローラ４１１２に有用な種々のエスティメータ４１１４がある。種々の実施形態において、これらエスティメータは、質量エスティメータ４２７１、ドラックエスティメータ４２７３、対地速度エスティメータ４２７５、ジャイロバイアスエスティメータ４２７７、及び／又は他のエスティメータ４２７９のうち１つ又はそれ以上のエスティメータを有することができる。
【0185】
質量エスティメータ４２７１は、隊列走行パートナーそれぞれの質量を推定するよう構成される。これら質量エスティメータは、間隔コントローラ４１１２が使用することができ、隊列走行パートナーの重量（質量）に適切に基づくトルク及び制動のリクエストを増減するのに役立てる。
【0186】
ドラグエスティメータ４２７３は、隊列走行パートナーそれぞれのドラグ（引きずり）抵抗を推定するよう構成される。これらドラグ抵抗推定も間隔コントローラが使用することができ、トルク及び制動のリクエストを調整するのに役立てる。概して、任意の特別なトラック又は他の車両におけるドラグ抵抗は、(a) その車両のドラグプロファイル（トラックの背景事情においては、もしあるとして牽引されているトレーラ、又は積荷の他の特性に基づいて変化し得る）、(b) 車両の現在速度、(c) 風速及び風向き、(d) 転がり抵抗、(e) 隊列走行状態（例えば、隊列走行がアクティブ状態であるか否か、隊列走行内の車両位置、間隔）、(f) 軸受摩耗、等々を含む様々な要因に基づいて変動することができる。
【0187】
対地速度エスティメータ４２７５は、隊列走行パートナーそれぞれの実際の対地速度を推定するよう構成される。多くのトラック及び他の車両はホイール（車輪）速度センサを有し、このホイール速度センサは、関連するホイール（車輪）の回転速度を実に正確に測定することができる。車両が走行している実際の対地速度は、ホイールそれぞれの直径、及びタイヤのスリップ条件に基づいて変動する。ホイールの精密な直径は使用されるタイヤに基づいて変動し得る。さらに、ホイール直径は、時間の経過につれてタイヤ摩耗、外気温変化、及び他の要因で変動する。ホイール直径は、使用中にタイヤが温度上昇する（又は他の温度変化）につれて、特別な運行行程にわたってさえも変化する。実際上、これらホイール直径変動のすべては、潜在的に間隔推定及び間隔制御に影響を及ぼす程に十分大きい。対地速度推定は、トラッカーに基づく間隔測定（例えば、レーダー、カメラ、ライダー等）が利用できないとき（このようなときは、例えば、隊列走行パートナーがレーン変更等で側方にオフセットするとき生じ得る）には、特に有用である。
【0188】
間隔コントローラ４１１２が利用する幾つかの測定は、ジャイロをベースとする慣性測定である。これら慣性測定としては、関連する車両が旋回する割合を示すヨー測定、縦方向加速度測定等々があり得る。ジャイロは、しばしば測定に影響を及ぼすおそれがあるジャイロバイアスと称される固有の測定誤差を有する。ジャイロバイアスエスティメータ４２７７は、このようなバイアスを推定して、間隔コントローラが測定誤差に基づいてこのようなジャイロに対して補償できるようにする。
【0189】
隊列走行コントローラ４１１０は、任意の特別な間隔コントローラ４１１２に対しても有用な任意な他のエスティメータ４２７９を有することができる。
【0190】
隊列走行コントローラ４１１０は、さらに、１つ又はそれ以上のトラッカー４１１６を有することができる。各トラッカー４１１６は、間隔を測定又は決定するよう構成される。多くの実施形態で使用される他タイプのトラッカーは、レーダーに基づくレーダートラッカー４２８３である。最近市場に入手可能なトラックは、しばしば標準装備としてレーダーユニットを装備するようになっており、レーダートラッカーは、このような車両での使用にも特に好適である。勿論、予めレーダーユニットが装備されていないあらゆる車両に１つ又はそれ以上のレーダーユニットを設置して、レーダートラッカー４２８３の使用を容易にする。例えば、幾つかの特別なレーダートラッカーは同時係属の特許文献、すなわち、双方とも２０１７年５月９日出願の米国特許出願第１５／５９０，７１５号及び同第１５／５９０，８０３号により詳細に説明されており、これら特許文献は双方とも参照により本明細書に組み入れられるものとする。
【0191】
ライダー（ＬＩＤＡＲ）は、車両間の間隔（ギャップ）を測定するのに好適な他の測距技術である。ＬＩＤＡＲは、自動及び自律運転用途での使用に対する要望が急速に高まってきている。ＬＩＤＡＲトラッカー４２８６は、ＬＩＤＡＲユニットを既に有している又は設けている車両での使用にも好適である。カメラ及びステレオカメラも、種々の自動及び自律運転用途で使用する最も人気のある測距ツールとなりつつある。
【0192】
勿論、他の測距技術を使用して車両間の間隔を測定又は推定することができ、これら技術を他のトラッカー４２８９で示す。例えば、主に車両それぞれの報告されるＧＰＳ位置に基づくＧＰＳトラッカーを使用することができる。
【0193】
多くの実施形態で使用されるトラッカーは、複数センサからのデータを融合して、それぞれのトラッカーが使用する一次センサの測定を有効化するのに役立てる。上述のレーダートラッカーに関する特許出願は、そのように一次センサの測定を有効化するのに役立つようデータを融合する方法について記載している。
【0194】
種々の実施形態において、間隔エスティメータ４２４０は、１つ若しくはそれ以上のトラッカーに置き換わる若しくは置き換えられる、又はトラッカー自体としても考えられ、これはすなわち、複数センサからの入力に基づいて間隔を決定／推定するからである。図示の実施形態において、間隔エスティメータ４２４０は、間隔コントローラ４１１２の一部として別個に示されており、これはすなわち、各車両におけるトラッカー及びＧＮＳＳセンサのような任意な他の利用可能センサからの距離データを融合するからである。
【0195】
隊列走行コントローラ４１１０は、さらに、間隔制御に関連する特定コンポーネントを監視するよう構成されている１つ又はそれ以上のモニタ４１１８を有することができる。例えば、隊列走行しているトラックを制御するのに特に有用な１つの特別なモニタは、ブレーキ健全性モニタ４２９１である。このブレーキ健全性モニタ４２９１は、ブレーキ系統を監視し、通常隊列走行制御に期待される制動レベルを送給できなくなる状況を認識するよう構成され、このような状況は、例えば、基本ブレーキがドラムブレーキを有し、このドラムブレーキが山の下り坂を走行する間に使用されており、オーバーヒートに近い状態になる場合に生じ得る。ブレーキ健全性モニタ４２９１がこのような状況を認識する場合、隊列走行コントローラに通報し、隊列走行コントローラが適切な是正措置をとることができるようにする。この適切な是正措置は、ブレーキ健全性モニタが認識した特別な状況に基づいて変化するが、措置としては、例えば、隊列走行を解消する、目標間隔をブレーキ条件にとってより適切なレベルまで増大させる、等々があり得る。勿論、ブレーキ健全性モニタは、さらに、ブレーキ条件が改善された状況を認識し、それら状況を隊列走行コントローラに通報し、隊列走行コントローラがそれに応じた作動を十分できるよう構成することができる。例えば、改善された制動状態によれば、目標間隔を減少させる、隊列走行を再確立又は他の適切な行動をとることを可能にする。
【0196】
隊列走行コントローラは、隊列走行に関連し得る、他コンポーネントの様態又は状態、システム、環境条件、道路又は交通状況、等々を監視するよう構成されている様々な他のモニタ４２９９を有することができる。例えば、ＤＳＲＣリンクモニタを設け、隊列走行パートナー間におけるＤＳＲＣ通信リンクの状態をモニタすることができる。
【0197】
次に図４１を参照して、間隔コントローラ４１１２の他の実施形態を詳細に説明する。図２に示す実施形態と同様に、間隔コントローラ４１１２は、目標及び状態セッター４２００、間隔レギュレータ４２１０、及び間隔エスティメータ４２４０を有する。図３の実施形態において、目標及び状態セッター４２００は、動作状態セレクタ４２０３及び制御パラメータセレクタ４２０６を有し、この制御パラメータセレクタ４２０６は、間隔レギュレータに対して、選択された動作モードで使用するのに適切な任意な可変制御パラメータを決定、選択、設定、又はさもなければ表示する。
【0198】
動作状態セレクタ４２０３は、間隔レギュレータ４２１０の意図した運行モード（状態）を決定するよう構成される。幾つかの特別な実施形態において、運行モードは、間隔レギュレータが車両間の指定された間隔を達成して維持する制御を行うよう構成される、「通常」又は「間隔制御」運行モードを有することができる。間隔制御動作モードにおいて、制御パラメータは制御パラメータセレクタによって指示される制御パラメータ変数が目標間隔自体（例えば、１０ｍ、１２ｍ、等々）を有することができ、この目標間隔は、運転条件（天候、地形、道路条件、交通量、等々）に基づいて幾分変動することができる。通常運行中における他の制御パラメータとしては、ドローイン速度、制御の厳密度、トルク制御と制動制御との間における公差又は変分に影響を与えるパラメータがあり得る。他の実施形態において、「隊列走行を開始する（initiate platoon）」及び／又は「ドローイン（draw-in）」若しくは「プルイン（pull-in）」は、少なくとも部分的に自動化した制御の下で安全に隊列走行パートナーが互いに隊列走行を確立及び／又は隊列走行状態になるのに使用される１つ又はそれ以上の個別の状態である。
【0199】
他の潜在的運行モードは「解消」モードであり、このモードにおいては、隊列走行コントローラは、後続車両の運転者（又は自動車速設定（オートクルーズ）制御システム）が車両の制御を安全に引き継ぐことができる位置に向かって／にまで後続車両を遷移させる。概して、隊列走行を解消することは、隊列走行が解消でき、また車両制御が安全に運転者による手動制御、又は車間距離適応走行制御のような異なるシステムの使用による制御に移行することができるポイントまで／に向かって制御した状態で車両間の間隔を増大させることを含む。この解消モードは、広範囲にわたる様々な異なる状況によって随意的にトリガされることができ、例えば、隊列走行パートナー又はＮＯＣが隊列走行終了を決めること、隊列走行車両間に割り込む自動車の検出、長期間にわたる車両間通信の喪失、先行車両前方に遅すぎる又は隊列走行に接近し過ぎている物体の検出、等々のうちの１つに応答してトリガされ得る。
【0200】
他の潜在的運行モードは速度制御モード又は相対速度制御モードがあり得る。速度制御又は相対速度制御は、好適には、種々の特別な状況において、例えば、レーン変更又は他の条件に起因して車両間で側方オフセットを生ずるときに起こり得る後続車両のレーダー追跡ユニットがパートナー車両を見失うときに、特定間隔を維持する制御を試行することができる。
【0201】
勿論、様々な他の運行モードもあり得る。
【0202】
間隔レギュレータ４２１０は、目標及び状態セッター４２００によって指定されたように後続隊列走行パートナーを制御するよう構成される。図３に示す実施形態において、間隔レギュレータ４２１０は、スケーラー４２１２と、及び異なる運行モードにおいて異なる組合せで使用される２つの個別コントローラとを有する。図示の実施形態において、コントローラは、スライディングモードコントローラ４２１５（間隔制御を実施する）及び速度／相対速度コントローラ４２１８を有する。当然のことながら、他の実施形態において、付加的及び／又は異なる単一コントローラを任意の特別な実施形態に適切なように設けることができる。
【0203】
図示の実施形態において、フィードフォワードスケーラー４２１２は、前方車両からのトルク及びブレーキ信号を、スライディングモード及び相対速度コントローラ４２１５、４２１８からの出力に加算する前に増減（スケーリング）し、エンジン及びブレーキコントローラに対するトルク及びブレーキリクエストを生成するよう構成される。このようなスケーリングは、隊列走行パートナーそれぞれの重量（質量）、車両それぞれのドラグ、制動イベントの深刻度（例えば、高制動シナリオでは、制動コマンドは制動性能及び反応時間の不確定性を考慮して安全マージンを得るよう僅かに増加し得る）、等々のような要因に基づくことができる。他の実施形態において、このようなスケーリング機能は、コントローラそれぞれ自体内に所望に応じて組み込むことができる。
【0204】
スライディングモードコントローラ４２１５は、制御パラメータセレクタ４２０６が特定した目標間隔及び任意な他の制御パラメータに従って、所望間隔を達成及び維持することを見出すように後続車両を制御するよう構成される。したがって、その主要機能は間隔制御である。速度コントローラ４２１８は、後続車両を制御して、後続車両の先行車両に対する指定速度を維持するよう、又は何らかの状況では単に指定速度を維持するよう構成される。図示の実施形態において、これら２つの個別のコントローラを設け、間隔レギュレータ４２１０が異なる運行状況で適切であるように異なるタイプの制御を行うことができるようにする。２、３の特別な実施例を図４２Ａ～４２Ｃにつき説明する。この説明する実施形態において、双方のコントローラ４２１５及び４２１８は隊列走行中に連続的に動作し、またセレクタ／加算器４２５０を使用して、現運行モードに基づいて出力に対する適切信号を選択する。随意的な制動モニタ４２５５は、セレクタ／加算器４２５０が出力した制動コマンドが、安全／衝突防止の観点から必要である場合を除いて、後続車両に対して過剰に強引な制動を掛けないことを確実にするよう補助するのに利用できる安全要部である。これは、後続隊列走行パートナーの背後の交通が後続隊列走行パートナーの予期しなかった強引な制動によって影響されるリスクを減少することである。
【0205】
スライディングモードコントローラ４２１５は、後続車両の前方車両に対する相対速度が車両間の間隔の関数として変化するよう後続車両を制御するよう構成される。この特徴は、１つの特別な実施形態による制御スキームを示す図４３の状態空間図で図解される。より具体的には、図４３は、車両間の相対速度（Ｙ軸）対車両間の間隔（Ｘ軸）をプロットしている。図４３は、さらに、トルクリクエストコントローラの目標制御ライン４３２０を示す。図示の実施形態において、公称所望間隔は１２メートルであり、これをライン４３１０で表す。したがって、目標制御ポイント４３１１は相対速度がゼロの１２メートルであり、これはライン４３１０（１２メートル間隔）とライン４３１２（相対速度ゼロ）との交点で表されるポイントである。
【0206】
間隔レギュレータ４２１０のコンポーネントであるトルクリクエストコントローラ４２２１は、目標制御ライン４３２０に従って間隔を制御するのに適切なトルクリクエストを発生するよう構成される。このトルクリクエストは、この後エンジントルクコントローラによって実施される。図４３で分かるように、間隔が所望間隔より大きいとき、後方トラックは走行している前方トラックよりも僅かに速く走行するよう制御され、したがって、後方トラックの相対速度は小さい正の値をとる。後方トラックが先行トラックに一層接近していくにつれて、相対速度は滑らかに減少し、最終的には間隔が目標制御ポイント４３１１に減少し、このポイントでは、完璧な制御が行われたとして相対速度はゼロになる。後方トラックが所望間隔よりも近づき過ぎた場合、減速して先行トラックに対する相対速度を負の値にし、所望間隔を再確立する。
【0207】
スライディングモードコントローラ４２１５は、隊列走行の「プルイン」段階及び間隔維持段階の双方中に統合されたスライディングモード制御スキームを利用する。目標制御ライン４３２０に向かう制御をするようにスライディングモードコントローラを構成することは、相対速度対間隔の相関関係を図１７Ａに示す安全運行領域内に確実に留めるのに役立つ。
【0208】
図４１に示す実施形態において、スライディングモードコントローラ４２１５は、個別のコントローラ（例えば、トルクリクエストコントローラ４２２１及びブレーキリクエスト発生器コンポーネント４２２３）を有し、これらコントローラは、異なる間隔制御目標に向かって制御するよう構成される。この異なる制御目標は、１つの特別な実施形態による制御スキームを示す図４３の状態空間図で図解される。より具体的には、図４３は、トルクリクエストコントローラの目標制御ライン４３２０に加えて、ブレーキリクエストコントローラの目標制御ライン４３３０を示す。図４３は、状態空間における種々のポイントからトルクリクエストの目標制御ライン４３２０までの代表的遷移経路も示す。
【0209】
多くの野外幹線道路での運転条件に関しては、トルクリクエストの単独変調は、基本ブレーキを使用することなく適切に間隔を制御するのに十分である。このことは、一部には、トルクリクエストは、エンジンブレーキ及び／又はリターダ（利用可能であれば）の使用により基本ブレーキを作動させる必要なく若干程度負の値にすることができるからである。上述したように、燃料がカットオフされるとき、幾らかのポンピング損失及びパワートレインでの幾らかの摩擦損失が存在し、したがって、単に燃料チャージを適切に遅らせることによって、通常のバルブタイミングを使用する間に幾らかの負トルクレベルを得ることができる。より大きな負トルクが必要なときには、エンジントルクコントローラ４１５２は、リターダを作動させることによって及び／又は他の適切な方策をとることによってより大きなトルクを発生することができる。
【0210】
間隔レギュレータ４２１０における別個のコンポーネントであるブレーキリクエストコントローラ４２２３は、通常運行中にブレーキリクエストを生成するよう構成され、概してトルクリクエストコントローラ４２２１の目標とは異なる間隔、特別にはより小さい間隔を維持するよう構成される。トルクリクエストコントローラ及びブレーキリクエストコントローラが制御する間隔の差は、ときに間隔公差として本明細書内で称される。概して、ブレーキリクエスト４２１３は、間隔が少なくともトルクリクエスト目標制御ライン４３２０以下で間隔公差に減少しない限り又は減少するまでは生成されない。ブレーキは車両を減速するのに使用されるだけであるため、この差の効果は、間隔レギュレータがトルクリクエスト単独制御では所望間隔を維持できないとき基本ブレーキが作動する前に後続トラックが比較的僅かな量（例えば、２メートル）だけクリープできる点である。目標ブレーキ制御ライン４３３０に交わらずにトルクリクエスト単独を変調することによって所望間隔が回復できるときは、基本ブレーキは全く不要である。このことは、間隔を安全に維持するとともに基本ブレーキを不必要に発動する可能性を減らす効果を有する。
【0211】
通常間隔制御を図４２Ａに図解する。通常間隔制御中、スライディングモードコントローラ４２１５は、制御パラメータセレクタ４２０６が設定した目標間隔を達成及び維持するに適切なトルクリクエスト及びブレーキリクエストを決定するのに使用する。適切なとき、スライディングモードコントローラ４２１５が発生するトルクリクエスト及びブレーキリクエストは、フィードフォワードスケーラー４２１２からの入力に基づいてセレクタ／加算器４２５０によってスケーリング（増減）され得る。この通常間隔制御モードにおいては、相対速度コントローラ４２１８は後続車両の制御には使用されない。
【0212】
幾つかの実施形態において、スライディングモードコントローラ４２１５は、図４１に図解したような別個のトルクリクエストコントローラ４２２１及びブレーキリクエストコントローラ４２３３を有する。このトルクリクエストコントローラ４２２１及びブレーキリクエストコントローラ４２３３は、それぞれ異なる間隔目標に向かうようエンジン及びブレーキを制御するよう構成され、このことは同一目標間隔になるようエンジン及びブレーキが制御される制御に比べると、より滑らかでより快適な乗り心地が得られ、またホイールブレーキの使用を減らす傾向がある。このような間隔制御アーキテクチャは、米国仮出願第６２／４８９，６６２号により詳細に記載されており、この特許文献は、参照によって本明細書に組み入れられるものとする。
【0213】
スライディングモードコントローラ４２１５は間隔を制御する上でとてもうまく機能するが、異なるタイプの制御が適切な運行状況がある。例えば、異なるタイプの制御は隊列走行を解消して後続車両を手動又は他の自動制御に復帰させることが必要なときに望ましい。典型的には、隊列走行中における車両間の間隔は手動制御の下で運転者が安全に維持できるよりも小さく、しばしば相当小さいものとなる。したがって、概して、後続車両の手動制御に復帰することを意図して隊列走行を解消するときには、制御を運転者に手放す前に手動制御に適切な距離まで間隔を増大するのが望ましい。このことは、相対速度コントローラ４２１８によって滑らかに完遂することができる。
【0214】
運行状態セレクタ４２０３が隊列走行を解消すべきであると決定するとき、間隔レギュレータ４２１０に指令して図４２Ｂで表すように解消モードに遷移させる。この解消モードにおいては、主制御は相対速度コントローラ４２１８によって行われる。制御パラメータセレクタ４２０６は、解消中後続車両に対して所望（目標）相対速度を指定することができる。特定の目標相対速度は、状況及び／又は隊列走行に取り込まれる車両の性質に基づいて変動し得る。概して、後続車両を過剰に減速させる（このことは、これに続く交通を不当に阻害するおそれがある）必要がなく、また好適には、先行車両の運転プランを変更させる必要がなく、これら車両を徐々にではあるが素早く引き離す相対速度を選択するのが望ましい。例えば、０.５～４メートル／秒のオーダーの解消中における相対速度が、隊列走行トラックの背景状況でうまく機能することが分かっている。
【0215】
解消中先行車両は様々な行動を取り得る。例えば、先行車両は、強引に加速する又はトルクコマンドを増大することがあり得る。このようなケースにおいて、後続車両を同様に加速させるのは望ましくなく、これにより相対速度制御の下で起こり得るよりも長く先行車両を引き離すことができるようになる。隊列走行トラックの背景事情でこのことを完遂する１つのやり方は、フィードフォワードスケーラー４２１２からの正のトルクコマンドを無視又は無効にすることである。
【0216】
他の潜在的シナリオは、速度制御下で先行トラックが十分にブレーキを掛ける又は減速することである。幾つかの状況において、速度コントローラ４２１８は、間隔が比較的大きいとき所定の間隔短縮量を可能にするよう構成し、これにより必要な制動総量を減らすことができる。図示の実施形態において、スライディングモードコントローラは、車両間の間隔を常に十分大きくするのを確実にし、後続車両に対して（合理的な）予期しないイベントの発生とは無関係に、後続車両が先行車両の後部に衝突するのを回避するよう応答するに十分な時間を後続車両に与えるよう構成される。したがって、スライディングモードコントローラが制動又は負トルク信号であって、相対速度コントローラが出力するよりも大きい大きさの制動又は負トルク信号を出力している場合、その大きな制動／負トルクコマンドを車両のエンジンコントローラ及び制動コントローラに伝送すべきである。したがって、解消中には、セレクタ／加算器４２５０は、スライディングモードコントローラ４２１５からの負コマンド（すなわち、制動コマンド及び負トルクコマンド）のみを利用し、またそれらコマンドの方が相対速度コントローラ４２１８からのコマンドよりも大きさが大きいときに、そのようなコマンドのみ使用するよう構成される。
【0217】
さらに、解消状況の他にも相対速度制御又は単なる速度制御が望ましい運行状況があり得る。例えば、先行車両の後部が後続車両のトラッカー４１１６の視界から逸脱する、又はそのトラッカー４１１６が隊列走行パートナーの後部を見失う状況があり得る。このことは、例えば、一方の隊列走行パートナーによるレーン変更の結果として生じ得る。このような状況において、間隔レギュレータは車両間の縦方向間隔の正確な測定が得られず、また車両それぞれにおけるＧＮＳＳ位置のような間隔を決定する上で精度の劣る手法に頼らなければならないことになり得る。このような状況においては、先行車両の後部がトラッカーの視界内に入るまで後続車両をゆっくりと後退させるよう制御するのが望ましい。この状況においても、やはり相対速度コントローラ４２１８を使用するのが十分に好適であるが、好適な相対速度制御は、解消中に生ずるのとは若干異なるものであり得る。とくに、典型的にその目的は、解消中に生起するような、できるだけ迅速又はできるだけ遠くに後退することではなく、したがって、より小さい相対速度（例えば、０.５ｍ／ｓ対２ｍ／ｓ）が適切であり得る。
【0218】
このような相対速度制御の１つの手法を図４２Ｃに図解する。図４２Ｃの速度制御スキームにおいて、速度コントローラ４２１８はフィードフォワードスケーラー４２１２からの通常スケーリングと併用する。このことは、後続隊列走行パートナーが、図４２Ｂに図解する解消状態中に生ずるよりも先行車両の加速及び／又はトルク上昇によりよく追従させる。同時に、安全目的のため、スライディングモードコントローラ４２１５からの制動リクエスト及び負トルクリクエストを、図４２Ｂにつき説明した手法に類似してセレクタ／加算器４２５０が適切に利用することができる。
【0219】
特別な隊列走行及び間隔コントローラのアーキテクチャを図４０及び４１に示したが、当然のことながら、利用されるこの特定アーキテクチャは、任意の特別な隊列走行又は他の自動車両制御スキームの必要性に合致するよう幅広く変化させることができる。
【0220】
当業者には明らかなように、説明したコントローラは、１つ又はそれ以上のプロセッサ上で実行するソフトウェア又はファームウェアを用いて、プログラム可能な論理を用いて、デジタル若しくはアナログのコンポーネントを用いて、又は上述したものの任意な組合せを用いてアルゴリズム的に実現することができる。
【0221】
上述した詳細な説明において、制御される動力装置は内燃機関、例えば、ジーゼルエンジンであると考えられる。しかし、当然のことながら、上述の制御手法は、ホスト車両を駆動するトルクを供給するのに使用される動力装置の性質に無関係に、利用することができる。したがって、本明細書記載の実施形態は、説明目的であって限定的なものではなく、本発明は本明細書に記載の細部に限定されず、特許請求の範囲及び均等物の範囲内で変更することができる。
【0222】
要約すれば、本発明は、車両を監視及び隊列走行させる装置、システム及び方法を提供し、幾つかの実施形態において、半自動車両コンボイ化の様々な能力、並びに隊列走行パートナーの向上した識別を生ずるよう、センサデータを通信されたデータと統合するためのシステム、プロセス及び方法論を提供し、さらに、至近距離に接近して走行する車両の向上した安全性及び改善した隊列走行性能をも含めて提供する。このようなシステムの多くの利点のうち、とくに、安全、効率的かつ利便性よく互いに接近して追従できる能力とともに、向上した燃料経済性、より良い車隊（フリート）管理、先を見越す改善された車隊及び車両メンテナンス、減少した偶発事故リスク、及び多数の他の恩恵がある。
【0223】
本発明を幾つかの実施形態の観点で説明したが、本発明範囲内の代替例、変更例、置換例、代用均等物がある。本発明方法及び装置を実現する多くの代替的方法を考慮して、特許請求の範囲は、本発明の真の範囲内にあたるこのような代替例、変更例、置換例、代用均等物すべてを包含するものとして解釈すべきであることを意図する。
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図6】
【図7A】
【図7B】
【図8A】
【図8B】
【図9】
【図10】
【図11A】
【図11B】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18A】
【図18B】
【図18C】
【図19】
【図20】
【図21A】
【図21B】
【図22】
【図23】
【図24A】
【図24B】
【図24C】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
【図35】
【図36】
【図37】
【図38】
【図39】
【図40】
【図41】
【図42】
【図43】