車間距離警報システム、自動ブレーキ、ＡＣＣ、ＬＤＷＳ、ＬＫＡが運転支援システムの主なものとなる。その他、レーンチェンジ時の斜め後方車両警報、自動レーンチェンジ、駐車時の周辺警報、自動駐車等がある。
何れの運転支援システムも、ドライバへの情報提供方法や警報に関するＨＭＩのヒューマンファクターはドライビングシミュレータで評価可能であり、実車よりも安全かつ効率的に実験を行うことができる。また、制御フィーリングはＨＭＩの一種と見做すことができるため、ドライビングシミュレータで評価可能である。ただし、制御フィーリングは実車同様のＧを再現できるドライビングシミュレータを使う必要があり、揺動装置を持たない映像だけのドライビングシミュレータを使う場合は、評価項目を厳選する必要がある。
次はＬＫＡ（レーン・キープ・アシスト）。ＬＫＡも自動ブレーキが車間距離警報システムにブレーキ制御を入れたものではなかったように、車線逸脱警報システムにハンドル制御を入れたものがＬＫＡではない。
ＬＫＡのハードウエア構成は、車線逸脱警報システムにハンドル制御を加えたものである。したがって、走行車線を認識する車載カメラは同じものである。
しかし、ＬＫＡの車線制御は車線を逸脱することがないため、ＬＫＡが働いているときは車線逸脱警報が発っせられることがない。そのため、ＬＫＡのドライビングシミュレータを使用した評価項目は、カーブ路での制御状況がドライバに受け入れらるかが主なものになる。通常、ドライバはカーブ走行時、車線内側に寄せて走行することが多い。したがって、直線時にレーン中央を維持して走行していても、そのままカーブ路でレーン中央を維持するとドライバが違和感を覚えることがある。そのため、カーブ走行時の車線制御でどの程度カーブ内側に寄せるか確認する必要があるのである。
また、ＬＫＡはドライバがハンドルを把持していないと働かないようにしている。そのため、ドライバがハンドルから手を離したときの警報音や警報方法、およびハンドルから手を離して何秒後に制御を解除するかというＨＭＩもドライビングシミュレータでの評価項目となる。
次は車線逸脱警報システム。走行中に車線からの逸脱を警報するシステムである。ＬＤＷＳ（レーン・デパーチャー・ウォーニング・システム）とも呼ばれる。
ＬＤＷＳは車載カメラで前方の走行レーン両端の道路端を示す白線を検知するため、自動車専用道での使用を前提としている。また、市外走行では、路面に道路端を示す以外の白線が多く誤検知があるため、例えば時速６０ｋｍ以上で作動するようにしているものが多い。
ＬＤＷＳのドライビングシミュレータが活用できる評価項目としては、以下の項目がある。
１）警報タイミングの妥当性
２）警報手段の妥当性
３）過検出率の妥当性
４）未検出率の妥当性
５）カーブ路での商品性評価（カーブ時は内側の白線をよぎることが多いため）
警報タイミングは、白線までの距離や白線まで何秒で到達するかの妥当性を検証する。警報手段は、音なのか表示なのか、またはハンドルを振動させるハプティックか等を評価する。過検出や未検出は車間距離警報システムと同様の考え方である。カーブ路では、カーブ内側の白線をカットインするドライバが多いため、過警報対策としてどの程度のカットインまで許容するとよいかを評価する。
次はＡＣＣ（アダプティブ・クルーズ・コントロール）。運転支援システムとしては、車間距離警報システムの次に商品化された古参であり、クルーズ・コントロールの改良版と考えれば最古参のシステムといえる。
ＡＣＣはクルーズ・コントロールに車間距離警報システムを追加すれば必要なセンサが揃うため、車間距離警報システムの機能も持たせることができる。しかし、自動ブレーキと同様、車間距離警報システムの機能全部は持たず、ＡＣＣに必要な仕様のみであることが多い。
ＡＣＣのドライビングシミュレータを使った評価項目としては、前方走行車に追い付いてからの減速度や、前方走行車が不在になってセット速度に復帰するときの加速度の良し悪しという制御フィーリングが考えられる。しかし、制御フィーリングは実車試験には適わないので、わざわざドライビングシミュレータを使うまでもないだろう。ドライビングシミュレータの使用は、ＡＣＣの効用や安全性評価をヒューマンファクターの観点から評価することに用いられることが多い。例えば、ＡＣＣにより運転タスクの負荷が減少することの効果や、ＡＣＣに慣れることによってドライバ行動の変化が生じないか等がドライビングシミュレータで評価される。
ＡＣＣは歴史的に、スロットル制御のみからブレーキ制御付へ、時速４０ｋｍ以上での使用からストップ＆ゴーを含めた全速度域対応と進化を続けている。これらの進歩のヒューマンファクターに関する仕様決定に、ドライビングシミュレータが活躍していることは言うまでもない。
次は自動ブレーキ。自動ブレーキは車間距離警報システムにブレーキ制御を入れただけのものではない。
車間距離警報システムの失敗を反省した仕様になっているため、警報仕様が異なるからである。さらに、車間距離警報システムからは、予想できないブレーキ制御となっているからでもある。
車間距離警報システムは、一次警報、二次警報とＴＴＣの大小によって２種類の警報が出るものが多かった。しかし、１次警報は余分な警報が多く「いらいら警報」と称され、そのため商業的には成功しなかったのである。そこで、自動ブレーキには１次警報を設定していないものが多い。また、車間距離警報は情報提供の観点から車間距離を表示するものもあることに対し、自動ブレーキの情報提供要素は２次警報のみである。そして、自動ブレーキがかかるタイミングは２次警報より更に遅く、ブレーキのかけ方も強烈な急ブレーキで、一般的なドライバなら生涯かけることがないくらいのものである。
そのため、自動ブレーキでは、ドライビングシミュレータ上で２次警報タイミングの評価が中心になる。自動ブレーキをかけるタイミングは、物理的に衝突を避ける限界のため、ドライバに対する評価は不要なほどである。
車間距離警報システムは、車両制御がなくドライバへの情報提供のみのシステムなため、ドライビングシミュレータでの評価項目はＨＭＩに関わるものが中心となる。警報タイミングの妥当性評価とは、システムが警報を出すときの遅れや、ドライバの反応時間も評価する警報システムとしての基本となるものである。
警報手段の妥当性評価とは、警報を音でやるのか表示でやるのか、あるいはハンドルを振動させるハプティックでやるのかということと、それぞれの手段の内容を評価する。例えば、音で警報するなら、音色、音量、出し方等を評価し、４KHzの音を80dbの2Hzの断続音に決めるという具合である。
車間距離警報システムが前方走行車両を検出する外界センサは、LiDAR、電波レーダー、カメラ等種々のものがある。何れのシステムも１００％正しく検出することは難しい。センサの特性として、過検出（第一種過誤）と未検出（第二種過誤）が付き物のため、それぞれがドライバに許容できるか評価する必要がある。センサの種類によって、開発者はどのような状況で過検出や未検出が出やすいかを把握しているため、ドライビングシミュレータで誤検出の状況を再現可能であるため、ドライビングシミュレータでの評価が可能となる。
また、走行シーンによって、過検出や未検出と分類できないような誤警報が発生することがある。代表的なものが、曲率が小さいカーブ路を走行するとき、センサの検知範囲にガードレールが入りそれを先行車両と誤認識する場合である。これら誤警報がどの程度ドライバに許容できるかもドライビングシミュレータで評価可能である。
さて、ここでドライビングシミュレータで評価可能な運転支援システムと、評価可能な機能を解説しておこう。運転支援システムは自動運転のレベル１の最下層で最も自動化率が低いものの、レベル２以上の自動運転より遥かに多くの仕様であふれている。
まずは、車間距離警報システムから。運転支援システムの中では最も古いシステムである。
このシステムの基本機能は、同一車線を走行中の前方走行車両との車間距離を計測し、ＴＴＣがあるしきい値以下になるとドライバに警報を発することである。ドライビングシミュレータが活用できる評価項目としては、以下の項目がある。
１）警報タイミングの妥当性
２）警報手段の妥当性
３）過検出率の妥当性
４）未検出率の妥当性
５）カーブ路での商品性評価（カーブ時はガードレールを検出して誤警報を出すことがよくあったため）
過検出というのは、前方走行車以外のものも検出することで、第一種過誤にことである。また、未検出というのは、前方走行車を検出しないことで、第二種過誤のことである。
テイクオーバーには数々の課題があることがわかったと思う。自動運転から手動運転の切替は、容易に仕様を決めて簡単に済ますことはできないのである。
逆に、手動運転から自動運転への切替はどうだろうか。こちらは運転支援システムで経験済みのことで、特に問題はない。
ＡＣＣならセットスイッチをオンにするだけでよく、ドライバは安心してペダルから足を離せばよい。自動運転への切替も同様で、ドライバが任意のタイミングで自動運転がオンになるスイッチを入れればよいだろう。もし、自動運転になれば、何か特別なＨＭＩが必要ではないかと心配になれば、テイクオーバーを実験したときのようにドライビングシミュレータで試してみればよい。運転支援システムや自動運転では、ドライバが運転操作を自動車に委ねるため、ドライビングシミュレータの活用度が大いに上がるのである。ドライバが手動で運転するときは、ハンドル操作に対する車両の挙動や、逆に車両挙動がハンドルを通してドライバに与えるフィーリング等が厳格に求められるため、ドライビングシミュレータはより運転感覚に訴求するＧの発生の高精度なものが必要になる。しかし、運転支援システムや自動運転の場合は、ドライバがハンドルを通して車両に求める感覚がシビアなものでないため、ドライビングシミュレータは走行環境を表現するグラフィックスに注意しれば、手動運転時ほどＧの発生は高精度なものでなくてもよい。したがって、低価格なドライビングシミュレータでも十分活用できるのである。
一方、テイクオーバーをサポートできていない車両側の課題とは、テイクオーバー要請後にいきなり手動運転に制御を移してしまうことである。つまり、これは走行中にいきなりドライバに運転制御を移動させても、ドライバは運転動作の準備ができていないため問題が生じるということである。
計画的なテイクオーバーでは、直線路でのみテイクオーバー要請が発せられると仮定した。これは、直線路でないとドライバが対応できないだろうということから考えたのである。
前述のように、直線路でテイクオーバーを完了後すぐに車線変更したときと、テイクオーバー完了後しばらくそのまま同一車線で走行してから車線変更した方が、ほとんどのドライバでハンドル操作が滑らかだった。これは、ドライバの手動運転には、慣熟走行が必要なことを示していると考えられる。また、カーブ走行時にテイクオーバーさせると、ハンドル操作が乱れるという他研究もある。
以上のことから、テイクオーバー時に車両制御をやめるのではなく、レーンキーピング等のレベル１の車両制御は継続しておいた方がよいのではないだろうか。ただし、障害物回避のため素早いハンドル操作が必要なときに、レーンキーピングが働いていて問題がないかどうかは検証が必要である。
当研究室では、ドライバの覚醒度低下問題について、覚醒度が低下してから警報するという立場でなく、覚醒度が下がらないようにするにはどうすればよいかという立場で研究を続けている。自動運転は運転するという重いタスクをドライバから解放しているため、覚醒度が下がらないように新たなタスクを課す場合も、極力ドライバへの負荷が少ないものを選んでいる。
ドライバへの負荷を無視すれば、覚醒度が下がらないタスクはいくつもある。積極的な会話や歌唱をしていれば覚醒度は下がらないものの、ドライバへは負荷がかかる。
当研究室で試した覚醒度を下げないタスクは、ハンドルを把持、走行地点に応じた情報提供、覚醒度が高い状態の呼吸数に応じたLEDの点滅、サッカード刺激を誘発するLEDの点滅等である。この中で顕著に効果のあったものは、ハンドル把持とサッカード誘発だった。ハンドルを把持していると、これまでの運転習慣から覚醒度が下がらないものと思われる。サッカード誘発は、人間の生体特性から効果があるものと思われるが、自発的に実施できるかどうかという課題がある。
ハンドル把持が覚醒度の低下防止に有効というのは、自動運転レベル１の延長にあって、かつコストがかからない方法である。自動運転レベルが１から２や３に進化しても、ドライバに運転姿勢を維持させてハンドルを把持したままにさせるのが、テイクオーバーにとって最も有効な手段といえる。
以上の実験で、走行中にテイクオーバーを行うと問題が生じる場合があることがわかった。この問題は、ドライバ側に課題があることと、車両側に課題があることがわかる。
ドライバ側の課題は、テイクオーバー要請が発せられたとき、ドライバが即座にテイクオーバーが可能な状態にあるかどうかということである。そして、車両側の課題とは、テイクオーバーをサポートできていないということである。
ドライバがテイクオーバー可能かどうかというのは、テイクオーバー要請が出たとき即座に前方監視ができて状況認識が行え、スムーズに運転操作に移行できるかどうかということである。つまり、ドライバには十分な覚醒度があるということである。そのため、テイクオーバー要請時、あるいは要請前のドライバの覚醒度を判定するため、ドライバモニタの必要性が議論されるのである。ドライバモニタを設置し、自動運転時は常時ドライバを監視し、覚醒度の低下が検出されれば覚醒度を戻すように警報を出したり刺激を与えればよいだろうか。
ドライバモニタが正確にドライバの覚醒度を監視できればよいが、もし、誤って覚醒度が低下していないのに警報を出すとどうなるだろうか。重大なミスではないものの、快適な自動運転を楽しんでいるドライバには、その警報は不快なものに感じらえるのではないだろうか。
以上の実験では、ドライバは障害物回避時、全員が最終的にハンドル操作で障害物を回避していた。これは、運転経験が浅いドライバが多かったからかも知れない。
そこで、運転経験が２０年以上のドライバ３２名に、これらのドライビングシミュレータ実験に協力してもらった。ＴＴＣ７秒で、サブタスクは行わず、自動運転中どうするかはドライバに任せた。
３２名中、６２％にあたる２１名は、テイクオーバー要請に気付くと，まずブレーキで減速しその後再び加速しながらハンドル操作で車線変更して障害物を回避した。１９％の６名は，ブレーキ操作なしで速度を維持しながらハンドル操作で回避した。１６％にあたる５名は、ブレーキで減速し障害物の手前で完全に停止した。そして、ブレーキで減速しながらハンドル操作で障害物を回避した後、停止した者が１名（３％）という結果になった。よって、８１％にあたる２７名がハンドル操作で障害物を回避したことになる。直進のままブレーキ操作で停止した者は１６％のため、少数派といえる。
運転経験を増すと、ハンドル操作せず停止する者も増える傾向は確認できた。しかし、それは少数派であって、走行中にテイクオーバーすると、走行を維持しながら状況に対処しようとする者が多数派といえるのではないだろうか。
次に、混在交通でテイクオーバーが成立するかどうか、先の実験と同様にドライビングシミュレータ上で実施してみた。ＴＴＣは７秒で、テイクオーバー要請が呈示されてから、斜め後方から追越車両が接近するというシナリオである。
実験毎に追越車両がいたりいなかったりし、いたとしても出現するタイミングを変化させ、ドライバが実験シナリオを学習することがないように工夫した。実験協力者は先の実験と同じ１４名である。
１４名中１３名は、混在交通環境でも各種タスク下で問題なくテイクオーバーが成立した。ところが、数回行った実験の中で一回だけ１名のドライバが接触事故を起こしたケースが発生した。それは、斜め後方の追越車両の発見が遅れ回避操作ができず、減速も不十分だったため障害物に接触するという事故だった。トータルで１００回程の実験で１回しか起こらなかったものの、テイクオーバーが成立しないケースがあることを示すには十分である。つまり、ＴＴＣ７秒という余裕がある状況でも、テイクオーバーがいつでも成立するとはいえないのである。
なお。この実験では後続車の確認方法を、通常のドアミラーで行う場合と、メーターの両側に左右のドアミラーの代わりとなる液晶表示のモニタを設定した場合の比較も行った。すると、液晶表示モニタの場合は、ドアミラーのように視線を移動しなくても視界に入るため、斜め後方の追越車両の発見遅れは発生せず、全試行回数でテイクオーバーが成立していた。
ＴＴＣ３．６秒でもテイクオーバーが成立していたため、テイクオーバー要請は障害物の３．６秒前までに出せばよいかというと、そうではなさそうだ。なぜなら、ドライバはＴＴＣに余裕がないと不安を覚えるからである。
ＴＴＣ７秒では、ドライバは全員とも障害物を回避するためにレーンチェンジするとき右のドアミラーを目視して、斜め後方に車両がいないことを意識的に確認していた。ところが、ＴＴＣ５秒になると、全員とっさにレーンチェンジしたため、ドアミラーで後続車の確認ができなかったと言っていた。
ところが、実験のときに録画した各ドライバの顔表情を見てみると、レーンチェンジするとき全員とも視線が右のドアミラーに向かっていたことがわかったのである。つまり、ドライバはレーンチェンジのとき無意識にドアミラーを見ており、不安体験から自分の動作を覚えていなかったといえる。物理的に障害物を回避できるＴＴＣだからといって、ドライバが不安を覚える操作を強いるのは問題があるといえる。したがって、ＴＴＣは余裕がある７秒以上を確保した方がよいと思われる。
ただし、この実験は、自車両がコースを単独で走行する特別な状況だった。通常の他車両も混在走行している状況ならどうなるだろうか。
ＴＴＣ７秒と５秒の場合の、障害物を回避するためのハンドル操作を見てみると、滑らかさが異なっていた。すなわち、ＴＴＣ７秒は滑らかにハンドルを操作していたが、ＴＴＣ５秒では急峻にハンドル操作をしていた。
これは、ＴＴＣ７秒では障害物までの距離に余裕があるため、ドライバが冷静に対応したためと思われる。一方、ＴＴＴＣ５秒のときは、障害物までの距離に余裕がなく、ドライバは慌ててハンドルを操作したためと思われる。
１４名のハンドル操作の開始時点の分布を調べると、ＴＴＣ７秒の方がＴＴＣ５秒よりばらついていた。これは、ＴＴＣ７秒では余裕があるため、回避操作を自分の好みのタイミングで行っていたものと考えられる。ところが、ＴＴＣ５秒になると余裕がないため、即座に回避操作を開始するため、分布はばらつかなかったのだろう。そして、１４名全員について、ＴＴＣ７秒と５秒のハンドル操作の上記違いは共通していた。
実験協力者の実験後の感想としては、やはりＴＴＣ５秒は余裕がなく焦ったというものが多かった。しかし、その後ＴＴＣ３．６秒での実験を行ったところ、全員が障害物を回避したため、ＴＴＣの限界値は３．６秒以下といえる。
１４名の実験協力者に、ＴＴＣ７秒と５秒の場合について、サブタスク①～⑥を実験回毎にランダムに選択して実験したところ、全回ともテイクオーバーは成立していた。障害物への対処方法は、基本的にハンドル操作で回避していた。
テイクオーバー要請が出たときからの実験協力者の挙動は、事前に予想した通り、まずサブタスクを行うために見ていた方向から即座に前方を注視し、同時にハンドルから手を放していればハンドルを両手で把持し、状況を理解して回避操作に移行していた。
１４名全員が停止することなくハンドル操作で障害物を回避したものの、ペダル操作はドライバによって異なっていた。テイクオーバー要請が出るとブレーキはかからずアクセルだけがオフ状態になる仕様だったため、１４名中８名はアクセルペダルを踏み込み車速を維持しながらハンドル操作を行っていた。一方、１４名中６名は最初にブレーキペダルを踏んで減速しながらハンドル操作を行い、すぐにペダルをアクセルに踏みかえて車速を復元させたいた。
最終的には、自車両を完全に停止させたものはおらず、全員がハンドルで回避操作を行って手動で運転を継続していた。この挙動の不変性があるのかを確認するため、この実験以来実験協力者を募ってデータを集めたので、後ほどその結果を紹介する。
実験結果にいく前に、テイクオーバー要請があったときからテイクオーバーを行うまでのドライバの反応を想定してみよう。ただ実験結果を求めるより、どのような過程を経て結果が得られるか想定し、実際の結果と比べることが重要だからである。
テイクオーバー要請が出されたとき、ドライバが前方を注視していなければドライバは直ちに前を向き意識を前方に向けるものと思われる。そして、テイクオーバー要請が出された理由を探るため、状況を理解しようとするだろう。
そして、状況が理解できれば、その状況に相応しい行動を選択しハンドル操作するとかブレーキをかけるとかの行動に移るはずだ。このような行動に移ったときは、運転タスクのテイクオーバーが完了し、運転のフォードバックループ内、いわゆる手動運転ループに入ることになる。自動運転時は、運転操作にドライバが一切関与していないため、フォードバックループから外れた運転ループ外といえる。すなわち，テイクオーバー要請後、ドライバはを運転操作に戻し，次に状況を理解し，そして運転操作を開始して手動運転による運転フィードバックループを完了させるものと考えることができる。
以上の行動がＴＴＣ秒内で完了すれば、テイクオーバーは成立したと考えられる。
この実験でテイクオーバー要請が出る原因となる障害物の位置は、ドライバに位置を予想されないよう実験を行う毎に変更した。実験は走行レーンと追越レーンの２車線ある高速道路で行い、自車の走行と障害物が設置されたレーンは、どちらも走行レーンだった。
ドライバにはテイクオーバー要請がビープ音で出されるまで自動運転であることを告げ、テイクオーバー要請が出された理由は自分で判断し適切に対処するよう伝えた。ハンドル操作で逃げるとか、ブレーキペダルで減速する等には一切触れていない。
また、テイクオーバー要請が出されるまで、次の６種類どれかのタスクを依頼した。
①ステアリングに両手を添え，前方を監視．足元は自由．
②ステアリングから手を放し，視線は自由．足元も自由．
③ステアリングに両手を添え，ナビ画面の動画を注視
④ステアリングから手を放し，ナビ画面の動画を注視
⑤ステアリングに片手を添え，付加タスクを実行
⑥ステアリングから手を放し，付加タスクを実行
なお、ナビ画面はインパネ中央の下部に設置し、ナビ画面を注視すると前方風景は確認できない状況とした。付加タスクとは、ナビ画面の横に呈示された多くの４桁の数字を、ナビ画面をタッチすることによって入力する作業である。
当研究室では、緊急時のテイクオーバー時のドライバの挙動について、ドライビングシミュレータを使っていくつかの実験を行ってきた。代表的なものを紹介しておこう。
最初に検討したことは、緊急時のテイクオーバーが成り立つかどうかということである。ここで最初に考えなければならなかったのが、何秒前にテイクオーバー要請が出せるかということである。
テイクオーバー要請が発生する状況としては、自律センサーだけでレベル２の自動運転で走行中に、対応できない障害物を自律センサーが検出しドライバにテイクオーバー要請を発し、即座に自動運転を解除するというものである。テイクオーバー要請は、ドライバがはっきりと気付く高周波のビープ断続音で発する。自律センサーの検出距離が２００ｍで、障害物は静止物とすると、車両速度が２７．８ｍ／ｓのため、２００÷２７．８≒７秒となり、障害物まで７秒の地点でテイクオーバー要請を出すことができることになる。自律センサーの検出性能が１４０ｍだと５秒になり、１００ｍだと３．６秒になる。
以上の設定により、テイクオーバー要請がＴＴＣ７秒、５秒、３．６秒の３種類でテイクオーバーが可能か実験を行った。
この研究で用いたドライビングシミュレータは、６軸揺動式のもので、ドライバの前方２７０°に走行シーンを投影するものである。ルームミラー、バックミラーにも走行シーンを映し、ドライバからはほぼ全周囲に走行シーンが映し出されているように見える。
自動運転中は、ペダル類は動かないがハンドルが自動的に動くため、ドライバは即座に自動運転中であることが理解できる。疑似走行音も発生させ、加減速やカーブ時の適切なＧもあるため、ドライバの走行感に容易に没入できる。
走行コースはカーブ路もある高速道路を模擬したもので、コース周辺の景色は随時変化を持たせ、視覚的に単調な状況が続かないよう工夫していある。そのため、初めてこのドライビングシミュレータを体験する被験者が自動運転を経験しても、車外走行シーンに飽きることはない。
緊急のテイクオーバーでテイクオーバー要請がカーブで出るとどうなるだろうか。高速道路でもカーブはあり、勾配のある地点でのカーブもある。
ドライビングシミュレータを使って、カーブ上でテイクオーバーを行うとどうなるか実験してみると、問題があることがわかる。ほとんどの被験者が、テイクオーバー後にふらつくのである。
直進時には感じることがなかった自動運転の走り方とドライバの走り方の相違が、カーブでは感じるようになる。カーブの走り方は、ドライバの経験や好みが現れるところであり、カーブへの進入時、カーブ途中時、そしてカーブの出口と個性的である。例えば、直線部からカーブに入る地点で、ドライバによっては自動運転の速度とステアリング制御に違和感を感じることがある。そのため、カーブの途中でテイクオーバーすると、自分の走行ラインに修正しようとしてハンドル操作するためふらつくのかも知れない。
緊急のテイクオーバーは問題がありそうである。それはカーブ地点でテイクオーバーするときだけではない。
なお、計画的なテイクオーバーを実行する場合、テイクオーバー要請を発する地点が重要である。その地点とは、直線が続く地点である。
なぜなら、テイクオーバーするまでドライバは運転操作を行っていないため、運転操作に慣れる時間が必要だからである。運転操作に慣れるには、まず、直線から走行するほうがよい。
本研究室で過去に行ったドライビングシミュレータによる実験では、直線部でテイクオーバーした後にレーンチェンジする状況で、直線を長く走行するほどレーンチェンジのためのハンドル操作がスムーズだった。これは、運転操作には慣れる時間が必要なことを示しているのである。そのため、テイクオーバー要請は直線が長く続く地点を選ぶのである。自動運転車はデジタルマップを装備しているため、地点選びは問題ない。
ところが、緊急のテイクオーバーは地点を選ぶことができない。すなわち、テイクオーバー要請が出る地点が、長い直線部とは限らないのである。
結局のところ、自動運転レベル２と３は、居眠りができない自動運転システムといえる。さらにいえば、自動運転中に覚醒度が低下してもよくない。
覚醒度が低下すると、レベル２では周辺監視が疎かになり、レベル３では緊急のテイクオーバー要請に応えられなくなるからである。なお、緊急のテイクオーバーに対し、計画的なテイクオーバーが行われることもある。
計画的なテイクオーバーとは、一般道では自動運転できず、高速道路だけ自動運転ができるシステムに出現する種類のテイクオーバーである。すなわち、高速道路の退出箇所やドライブインへの入場箇所がわかっており、その手前で行われる自動運転から手動運転へのテイクオーバー要請である。この場合は、十分な余裕をもってテイクオーバー要請がだされるため、覚醒度が低下していてもテイクオーバー要請後の手動運転ができるまで戻ることが期待できる。また、テイクオーバー要請の出し方も、急な依頼ではなく、徐々にドライバに伝えていけばよいため、ドライバの意識も徐々に運転に向かって高まっていくものと思われる。
実は、これまで数々の居眠り警報が研究開発され、商品化も行われてきた。ところが、居眠り警報装置付きの自家用車は一般的ではない。
運転中に眠たくなるような体調では運転しない、というのが一般的な考え方である。眠たくなれば、無理せず運転を続けないで、休憩して仮眠を取るのが通常の考え方だろう。
また、居眠りを検知して警報しても効果があるのだろうか。一時的な効果が期待できるものの、継続的に居眠りを防止するのは、経験的にも難しいといえる。したがって、レベル３の自動運転に搭載されたドライバモニタがドライバの覚醒度低下を検知し、ドライバに警報して一旦覚醒度を上げた後、自動運転は解除しばければならないのではないだろうか。
つまり、レベル３でも居眠り運転はできないのである。眠くなれば、やはりドライブインで休憩しなければならないのだ。
ハンドルを持つ限りでは、レベル２とレベル１は大して変わらない。それでは、レベル３はどうだろうか。
レベル３では、運転制御を自動運転側が行うことに加え、周辺監視も自動運転が行う。したがって、ドライバには監視義務はない。
周辺監視義務がないので、ドライバは自動運転モードで走行中に何をしてもよいことになる。ナビ画面にＤＶＤの映画を流して楽しんでもよいし、スマホを見ていてもよい。しかし、居眠りしてもよいのだろうか。レベル３にも自動運転からテイクオーバー要請が発生することがある。それは、自動運転システムが対応できない状況に遭遇したときや故障した場合である。このとき、ドライバが居眠りしていれば、スムーズにドライバがテイクオーバーができるはずがない。
そのため、やはりドライバモニタの装着が考えられている。レベル２のときのように、周辺監視の集中度を警報するのではないため、わき見の警報はなくなるものの居眠りをすると警報を出さなくてはならない。
レベル２は運転制御を自動運転が行うため、手放し運転が可能となる。ところが、手放し運転にすると、これまで述べてきたように周辺監視の集中度が下がってしまう。
そのため、現在商品化されているレベル２相当の自動運転では、ドライバがハンドルを掴んでいないと自動運転が働かない仕様になっているものがほとんどである。ハンドルを持っていると、自動運転がステアリングとペダルを操作していても、自然と運転に意識が集中し周辺監視にも集中できるのである。
ハンドルを持つということは、レベル１のキープ・レーン・アシストと同じ仕様になってしまう。キープ・レーン・アシストは、ハンドルを持っていないと作動しないのが一般的である。キープ・レーン・アシストはペダル操作が含まれないものの、レベル１のアダプティブ・クルーズ・コントロールと組み合わせれば、レベル２走行と同じになる。つまり、レベル２でドライバにハンドルを持たせてしまうと、レベル１と変わらないことになる。
ドライバがハンドルを持っているとテイクオーバーがやりやすいし、周辺監視にも集中するので何ら問題はない。ただし、レベル１とレベル２を区分する意味はなくなり、レベル２の存在意義は低くなる。
ドライバが周辺監視に集中しているかどうか、ドライバの顔をカメラで解析するドライバモニタが考えられている。現在の画像処理では、ドライバの視線と、ドライバの眠気の指標となるまばたきの回数やまぶたの開閉の度合いが検出可能なため、ドライバが周辺監視に集中しているか判別可能といえる。
ドライバモニタでドライバの集中度が低下したことが検出されれば、アラームを鳴らしてドライバに注意を促すことになる。居眠りをしてしまえば、居眠り警報として働かせることも可能だ。
レベル２の自動運転では、ドライバは周辺監視の集中度が下がりがちになることを解説した。そのため、ドライバモニタを装着してドライバを監視すると、レベル２の自動運転中は常時アラームが作動することになる。果たして、これでドライバは快適だろうか。アラーム音は、通常、快適な音とはいいがたい。ドライバに注意させるための音なので、不快な音の方がドライバは反応するはずである。したがって、ドライバモニタのアラーム音によって、自動運転の快適さが損なわれるかも知れない。
ドライバモニタに監視されながら自動運転モードにするか、不快なアラーム音を聞きたくないので敢えて手動運転に徹するかどちらだろうか。最初のうちは自動運転モードを試すだろうが、やがて手動運転だけになるのではないだろうか。
なぜレベル２の自動運転の周辺監視に問題があるかというと、本研究室で行ったドライビングシミュレータでの実験結果による。運転制御なしで周辺監視のみの自動運転を体験させると、ほとんどの実験協力者の周辺監視の集中度が低下するのである。
集中度が低下するどころではなく、覚醒度も低下してしまう。つまり、運転制御がなしで運転を続けると、眠たくなってしまうのだ。
むしろ、周辺監視以外のタスクを行っている方が眠気は起きないようである。例えば、周辺監視だけではなく、ナビ画面の動画を見たりスマホを見るようにした方が眠気は起きない。しかし、これではいわゆる脇見運転になってしまい。十分な周辺監視が行われているとはいえない。
自動運転がテイクオーバー要請したにもかかわらず、そのときドライバが周辺監視以外のタスクをしていたらどうなるだろうか。このような状況ではスムーズなテイクオーバーは期待できず、本来安全性を向上させるための自動運転が危険な状況を招くことになり兼ねない。
レベル２は運転制御が自動運転側、周辺監視がドライバ側といっても、実際は運転制御を行うために自動運転側も周辺監視を行っている。そのため、ドライバが周辺監視を怠ったとしても、ほとんどの場合、適切な運転制御が行われるのである。
そのため、レベル２の仕様を周辺監視をしなくてもよいもの、と勘違いするドライバの発生が懸念されるのである。また、運転制御をやらなくてもよい状況では、周辺監視義務があっても周辺監視に集中できなくなることも懸念される。ドライバ自身が運転していれば、当然のことながら周辺監視なしでは運転できないため、ドライバは周辺監視に集中する。もし、何らかのタスク、例えば携帯電話の使用で意識が会話に集中する状況、では、周辺監視に集中できず、安全に運転ができないことは誰もがわかっている。したがって、周辺監視に集中できなくなる仕様で、周辺監視義務を課すのは問題があるのではないだろうか。
自動運転の各レベルでテイクオーバーがどのように行われるか考えてみよう。もちろんレベル０は関係ないので、レベル１から。
レベル１とは、アダプティブ・クルーズのような先進ドライバ支援システムそのものである。追従走行中、ドライバは自由にどんなときでもテイクオーバーすることができ、運転制御から手動運転に切り替えるより、手動運転から運転支援可能な状況になると運転制御に託すことが多い。
レベル２になると、運転制御は全て自動車に託すことができるので、テイクオーバーの機会は増えることになる。ドライバが自分の意志で積極的にテイクオーバーをして、自動運転が行う運転制御以上の運転を楽しむような状況では特に問題はない。問題が懸念されるのは、自動運転が運転制御を行っているときにドライバが周辺監視に集中していない状況で、自動運転からドライバにテイクオーバーの要請が出る場合である。
自動運転がテイクオーバー要請を出すのは、制御が困難な状況である。しかし、そのときドライバがテイクオーバー可能な状況でなかった場合が懸念されるのである。
今日から１０月。２０２０年も後三か月となった。
自動運転の課題対策の次は、テイクオーバーについて考えてみよう。テイクオーバーとは、乗っ取りという意味で、自動運転状態を奪取してドライバが手動運転に変更するということである。
レベル４までの自動運転はステアリングやペダルが装着されているので、テイクオーバーが可能になるはずである。ここで、テイクオーバーの観点から自動運転レベルをおさらいしておこう。
自動運転レベルとは、レベル０の従来通りの手動運転から、レベル５の完全自動運転まで、ＳＡＥが６段階で自動運転レベルを分類したものである。レベルが変わると影響のある項目としては、車両制御、周辺監視、故障時対応の３種類あり、レベル１は車両制御を自動運転とドライバが協調して行い、レベル２では自動運転が車両制御を行い、レベル３で周辺監視が加わり、レベル４では故障時対応も加わった自動運転となる。レベル４と５の機能は同じなものの、レベル５ではドライバが不要なため、ステアリングやペダル等の操縦装置そのものが不要となる。
したがって、テイクオーバーはレベル２と３で発生することになる。しかし、レベル４であっても、ドライバの運転は可能なので、テイクオーバー可能なものになると予想しているのである。
最近のコメント