JP7625989B2 - 乗客見守り装置、運行管理システム - Google Patents

Description

本開示は、例えばバスなどの乗客を輸送する車両においての乗客の転倒等に対する注意喚起を行う技術に関する。

特許文献１には、車内カメラや超音波センサを用いて乗客の転倒の可能性を検出し、車載ディスプレイを用いて運転士に通知する構成が開示されている。なお、転倒の可能性がある状態としては、立っている状態や、吊り革につかまっていない状態などが挙げられている。

特開２０１６－６２４１４号公報

特許文献１では、運転士や保安要員などの乗務員が車両に乗車していることを前提としている。換言すれば特許文献１では、例えば無人運行バスやロボットタクシーなど、乗務員が乗車しない旅客車両である無人旅客車両への適用は想定されていない。無人旅客車両は、例えば自動運転や遠隔操作などの技術を用いて走行する車両である。無人旅客車両においても、転倒のリスクがある乗客の不安全な行動／状態（以降、不安全行動等）に対して注意喚起等のアナウンスを実施可能な構成が求められている。

無人旅客車両において乗員の不安全行動等に対する注意喚起を実施するための１つの想定構成としては、乗客見守り装置が車内カメラの映像をもとに乗客の不安全行動等を検出するとともに、その旨を管制センタにいるオペレータに通知する構成が考えられる。当該想定構成によれば、オペレータは乗客見守り装置からの通知に基づき、車両から無線通信で送信されてくる車内カメラの映像を確認した上で、実際の状況に応じたアナウンスを実施可能となる。なお、ここでの乗客見守り装置とは、車両に搭載されて乗客の不安全行動等を検出する機能を備える装置を指す。乗客見守り装置は、運行管理システムを構成する車両側の装置と解することができる。

しかしながら、無人旅客車両の走行に伴って、無線通信環境は応じて動的に変動する。そのため、乗客見守り装置と管制センタとの通信状態がいつも良好とは限らない。乗客見守り装置と管制センタとが通信できない状態や、通信遅延が所定値以上となる状態も起こりうる。そして、乗客見守り装置と管制センタとの通信に不具合が生じている場合には、乗客の不安全行動等に対するアナウンスをリアルタイムに行うことが難しくなる。

本開示は、上記の検討又は着眼点に基づいて成されたものであり、その目的の１つは、乗務員が乗車していない旅客車両において乗客の挙動又は状態に応じた報知をリアルタイムに実施可能な乗客見守り装置、運行管理システムを提供することにある。

ここに開示される乗客見守り装置は、管制センタの管理のもと乗務員が乗車せずに運行可能に構成された旅客車両で使用される、管制センタと無線通信可能に構成されている乗客見守り装置であって、旅客車両に搭載された、車内を撮像するカメラでの映像である車内映像を管制センタに送信する報告処理部（Ｆ３）と、旅客車両に搭載されたセンサからの入力信号に基づいて、乗客が特定行動を実施していることを検出する特定行動検出部（Ｆ１）と、特定行動の内容に対応する音声メッセージを出力するためのデータが格納された報知用データ記憶部（Ｍ１）と、特定行動の実施が検出されたことに基づいて、検出された特定行動に対応する応答処理を実施する応答部（Ｆ４）と、旅客車両に搭載された無線通信装置から、管制センタとの現在の通信状態を取得する通信状態取得部（Ｆ２）と、を備え、応答部は、応答処理として、報知用データ記憶部に格納されたデータを用いて特定行動に対応する規定メッセージを、旅客車両に設置されたスピーカである車内スピーカ（１８）から音声出力することと、管制センタから車内映像に基づいて送信される音声データを取得し、当該音声データに対応する音声を車内スピーカから出力を行うことの、少なくとも２種類の処理を選択的、並列的、又は順番に実施可能に構成されており、応答部は、さらに、特定行動の実施が検出された際の管制センタとの通信状態に基づいて、応答処理として実行する内容を変更し、特定行動の実施が検出された際、管制センタとの通信に不具合が生じている場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出し、復旧予想時間が所定の待機許容時間未満である場合には、規定メッセージの出力は保留とするとともに管制センタからの音声データの受信を待機するように構成されている。

上記の乗客見守り装置が備える応答部は、管制センタから取得した音声を出力する処理の他に、乗客が実施している特定行動に対応する規定メッセージを出力可能に構成されている。そのような構成によれば、乗客の特定行動に対し、管制センタとの通信状態に応じた柔軟な応答が実施可能となる。例えば管制センタとの通信が可能な場合にはセンタ連携処理を実施する一方、通信不能な場合には規定メッセージを出力するといった対応が可能となる。このように上記構成によれば管制センタとの通信に不具合が生じている場合であっても、無人旅客車両において乗客の挙動又は状態に応じた報知をリアルタイムに実施可能となる。

また上記目的を達成するための運行管理システムは、乗務員が乗車せずに運行可能に構成された旅客車両の運行を管理する、少なくとも１つのプロセッサ（２３１）を用いてなる管制センタ（２）と、旅客車両で使用される、管制センタと無線通信可能に構成されている乗客見守り装置（３０）と、を含む運行管理システムであって、乗客見守り装置は、旅客車両に搭載された、車内を撮像するカメラでの映像である車内映像を管制センタに送信する報告処理部（Ｆ３）と、旅客車両に搭載されたセンサからの入力信号に基づいて、乗客が特定行動を実施していることを検出する特定行動検出部（Ｆ１）と、特定行動の内容に対応する音声メッセージを出力するためのデータが格納された報知用データ記憶部（Ｍ１）と、特定行動の実施が検出されたことに基づいて、検出された特定行動に対応する応答処理を実施する応答部（Ｆ４）と、旅客車両に搭載された無線通信装置から、管制センタとの現在の通信状態を取得する通信状態取得部（Ｆ２）と、特定行動の実施が検出されたことに基づき、報知用データ記憶部に格納されたデータを用いて特定行動に対応する規定メッセージを、旅客車両に設置されたスピーカである車内スピーカ（１８）から音声出力する規定メッセージ出力部（Ｆ４２）と、特定行動の実施が検出されたことに基づいて、特定行動に対する車内アナウンス用の音声データを管制センタから取得し、当該音声データに対応する音声を車内スピーカから出力するセンタ連携部（Ｆ４３）と、を備え、管制センタとの通信に不具合が生じていない場合には、規定メッセージ出力部よりもセンタ連携部が優先的に作動し、管制センタが有するプロセッサ（２３１）は、特定行動の実施が検出されたことに基づいて、オペレータに状況を確認させるための画像をオペレータ用のディスプレイ（２２１）に表示することと、マイク（２２２）を介して特定行動に対するオペレータの発話音声を取得することと、オペレータの発話音声に対応する音声データを乗客見守り装置に送信することと、を実施するように構成されており、応答部は、特定行動の実施が検出された際、管制センタとの通信に不具合が生じている場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出し、復旧予想時間が所定の待機許容時間未満である場合には、規定メッセージの出力は保留とするとともに管制センタからの音声データの受信を待機するように構成されている。

上記の運行管理システムにおいても、乗客見守り装置は、管制センタからの指示に基づく音声出力を実施するセンタ連携処理の他に、乗客が実施している特定行動に対応する規定メッセージを出力可能に構成されている。当該構成によれば、例えば管制センタとの通信が不能な場合には規定メッセージを出力するといった応急措置が可能となる。つまり、乗客見守り装置と管制センタとの通信に不具合が生じている場合であっても、無人旅客車両において乗客の挙動又は状態に応じた報知をリアルタイムに実施可能となる。

なお、特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、本開示の技術的範囲を限定するものではない。

運行監視システムの全体像を概略的に示す図である。 車載システムの構成の一例を示すブロック図である。 車載システムが備える車内センサの一例を示すブロック図である。 車内監視ＥＣＵの機能ブロック図である。 復旧予想時間を説明するための図である。 乗客対応テーブルの一例を示す図である。 管制センタの構成を示すブロック図である。 概要通知画像の一例を示す図である。 車両側処理を説明するためのフローチャートである。 臨時対応処理を説明するためのフローチャートである。 センタ連携処理を説明するためのフローチャートである。 センタ側処理を説明するためのフローチャートである。 規定メッセージ出力処理を説明するためのフローチャートである。 転倒リスクに基づき注意対象を設定する場合のフローチャートである。 通常モード復帰判定処理のフローチャートである。 車載システムの構成の変形例を示すブロック図である。 車載システムの構成の変形例を示すブロック図である。

図面を参照しながら、本開示の実施形態の一例を説明する。本開示は、以下の運行管理システムＳｙｓが適用される地域の法規及び慣習に適合するように適宜変更して実施可能である。

＜前置き＞
図１は、本開示に係る運行管理システムＳｙｓの概略的な構成の一例を示す図である。本開示の運行管理システムＳｙｓは、図１に示すように自動運転バス１に搭載されている車載システムＩｖＳ、及び、管制センタ２を含む。車載システムＩｖＳは、後述するように自動運転機能を提供する自動運転ＥＣＵ２０と、車内状況を見守る車内監視ＥＣＵ３０を含む。なお、図１では自動運転バス１を１台しか示していないが、管制センタ２が管理する自動運転バス１は複数台存在しても良い。

自動運転バス１は、自動運転ＥＣＵ２０を備えることにより、外界センサ１１の検出結果に基づいて自律的に（自動で）走行可能に構成されたバスである。自動運転バス１は、運転士などの乗務員が車内にいないバスに相当する。自動運転バス１は、無人運行バスや、自動運行バス、ロボットバスなどと呼ぶこともできる。自動運転バス１は、予め設定された運行ルートを定期的に走行するものであってもよいし、ユーザからの乗車要求に基づいて柔軟に走行ルートを変更する、いわゆるオンデマンドバスに相当するものであっても良い。自動運転バス１は、シャトルバスやスクールバスであってもよい。

もちろん、車載システムＩｖＳが適用される車両は、バスとしての形態を保持する旅客車両に限定されない。車載システムＩｖＳは、運転手が搭乗せずに自律的に走行するタクシーであるロボットタクシーに適用されても良い。本開示の構成は、多様な形式の旅客自動車に適用可能である。また、本開示は自動車に限らず、電車にも適用可能である。以降では車載システムＩｖＳが搭載されている車両を自車両とも記載する。

また、ここでは一例として自動運転バス１は、電気自動車とするがこれに限らない。自車両は、エンジン車であってもよいし、ハイブリッド車であってもよい。電気自動車は、モータのみを駆動源として備える車両を指す。電気自動車には、燃料電池車（ＦＣＶ：Fuel Cell Vehicle）も含まれる。ガソリン車は、駆動源としてエンジンのみを備える車両であって、ガソリンなどの燃料によって走行する車両に相当する。エンジン車にはディーゼル車も含まれる。ハイブリッド車は動力源としてエンジンとモータを備える車両を指す。

管制センタ２は、自動運転バス１の運行状況等を管理するセンタである。自動運転バス１は、無線基地局３に無線接続する事により、図１においてＷＡＮで示す広域通信ネットワーク４を介して管制センタ２と相互通信可能に構成されている。例えば自動運転バス１は、自車両の現在位置や、車内の様子、周辺状況などを示すデータを管制センタ２に逐次送信する。

なお、広域通信ネットワーク４は、例えばインターネットである。広域通信ネットワーク４は、例えばインターネット以外のＩＰ（Internet Protocol）ネットワークや、携帯電話網等といった通信事業者によって提供されるネットワークであってもよい。図１に示すＷＡＮはWide Area Networkの略である。

無線基地局３は、ＬＴＥ／４Ｇ／５Ｇ／６Ｇの規格（以降、４Ｇ等）に準拠した移動体通信網を形成する通信設備である。無線基地局３は、自動運転バス１とＬＴＥ等の規格に準拠した無線信号を送受信する設備である。無線基地局３は、例えば４Ｇに適合したｅＮＢ（evolved NodeB）である。もちろん、無線基地局３は、５Ｇで使用されるｇＮＢ（next generation NodeB）であってもよい。無線基地局３は、自動運転バス１に搭載された無線通信機と制御信号をやり取りすることで、広域通信ネットワーク４へのアクセス、ひいては自動運転バス１と管制センタ２とのデータ通信を実現する。

＜車載システムＩｖＳの全体構成について＞
車載システムＩｖＳは一例として図２に示す種々の構成を備える。すなわち、車載システムＩｖＳは、外界センサ１１、車両状態センサ１２、ロケータ１３、地図記憶装置１４、車内センサ１５、無線通信機１６、ディスプレイ１７、及び車内スピーカ１８を備える。また、車載システムＩｖＳは、走行アクチュエータ１９、自動運転ＥＣＵ２０、及び、車内監視ＥＣＵ３０を備える。部材名称中のＥＣＵは、Electronic Control Unitの略であり、電子制御装置を意味する。

外界センサ１１などの各装置はそれぞれ、車両内に構築された通信ネットワークである車両内ネットワークＩｖＮを介して車内監視ＥＣＵ３０と相互通信可能に接続されている。なお、ここで開示する装置間の接続態様は一例であって適宜変更可能である。一部の構成同士は、車両内ネットワークＩｖＮを介さずに、専用の通信線で接続されていてもよい。また、車両内ネットワークＩｖＮのトポロジはバス型に限らず、メッシュ型や、スター型、リング型などであってもよい。車両内ネットワークＩｖＮの規格としては、例えばController Area Network（以降、ＣＡＮ：登録商標）や、イーサネット（イーサネットは登録商標）、FlexRay（登録商標）など、多様な規格を採用可能である。

外界センサ１１は、自車の周辺を監視するセンサである。外界センサ１１は、所定の検出対象物の存在及びその位置を検出するように構成されている。外界センサ１１としては、例えば、周辺監視カメラ、ミリ波レーダ、ＬｉＤＡＲ（Light Detection and Ranging/Laser Imaging Detection and Ranging）、ソナー等を採用することができる。ミリ波レーダは、所定方向に向けてミリ波又は準ミリ波を送信するとともに、当該送信波が物体で反射されて返ってきた反射波の受信データを解析することにより、検出範囲内に存在する物体の位置を検出するデバイスである。ＬｉＤＡＲはレーザ光を照射することによって、検出方向ごとの反射点の位置を示す３次元点群データを生成するデバイスである。ＬｉＤＡＲはレーザレーダとも称される。ＬｉＤＡＲはスキャン型であってもよいし、フラッシュ型であってもよい。

車載システムＩｖＳは例えばＬｉＤＡＲと少なくとも１つの周辺監視カメラなど、検出方向ごとに複数種類の外界センサ１１を備えうる。周辺監視カメラは自車両の外側、所定方向を撮像するように配置されている車載カメラである。周辺監視カメラには、自車両の前方を撮影するようにフロントガラスの車室内側の上端部や、フロントグリル等に配置された、前方カメラが含まれる。前方カメラは、例えばＣＮＮ（Convolutional Neural Network）やＤＮＮ（Deep Neural Network）などを用いた識別器を用いて多様な検出対象物を検出する。

検出対象物には、例えば、歩行者や、他車両などの移動体が含まれる。他車両には自転車や原動機付き自転車、オートバイも含まれる。また、外界センサ１１は、所定の地物も検出可能に構成されている。外界センサ１１が検出対象とする地物には、道路端や、中央分離帯、路面標示、道路沿いに設置される立体構造物が含まれる。路面標示とは例えば、レーンの境界を示す車線区画線や、横断歩道、停止線、導流帯、安全地帯、規制矢印などである。道路沿いに設置される立体構造物とは、例えば、ガードレールや道路標識、信号機などである。

なお、外界センサ１１が生成する観測データに基づく物体認識処理は、自動運転ＥＣＵ２０など、センサ外のＥＣＵ（Electronic Control Unit）が実行しても良い。その場合、各種外界センサ１１は、画像データや測距データといった観測データを検出結果データとして自動運転ＥＣＵ２０に提供する。なお、ここでの観測データとは、例えばカメラが生成する映像／画像データや、ＬｉＤＡＲが生成する３次元点群データ、ミリ波レーダ／ソナーが取得する探査波の受信結果データなどを指す。

車両状態センサ１２は、自車両の状態に関する情報を検出するセンサ群である。車両状態センサ１２には、車速センサ、転舵角センサ、加速度センサ、ヨーレートセンサ等が含まれる。車速センサは、自車の車速を検出する。転舵角センサは、車両前後方向又は車軸に対するタイヤの角度である転舵角を検出する。転舵角は切れ角とも呼ばれうる。加速度センサは、自車の前後加速度、横加速度等の加速度を検出する。ヨーレートセンサは、自車両に作用するヨーレート（角速度）を検出する。加速度センサやヨーレートセンサは慣性センサと呼ぶこともできる。車両状態センサ１２は、検出対象とする物理状態量の現在の値（つまり検出結果）を示すデータを車両内ネットワークＩｖＮに出力する。車両内ネットワークＩｖＮに出力された検出結果は自動運転ＥＣＵ２０や車内監視ＥＣＵ３０などで参照及び利用される。なお、車両状態センサ１２として車載システムＩｖＳが備えるセンサの種類は適宜設計されればよく、上述した全てのセンサを備えている必要はない。また、上記以外のセンサ、例えばドアの開閉状態を検出するセンサや、各窓の開閉状態、施錠状態を検出するセンサなどを備えうる。

ロケータ１３は、複数の情報を組み合わせる複合測位により、自車両の高精度な位置情報等を生成する装置である。自車両の位置は、例えば緯度、経度、及び高度の３次元座標で表される。ロケータ１３は、例えば、ＧＮＳＳ受信機を用いて構成されている。ＧＮＳＳ受信機は、ＧＮＳＳ（Global Navigation Satellite System）を構成する測位衛星から送信される航法信号（以降、測位信号）を受信することで、当該ＧＮＳＳ受信機の現在位置を逐次検出するデバイスである。例えばＧＮＳＳ受信機は４機以上の測位衛星からの測位信号を受信できている場合には、１００ミリ秒ごとに測位結果を出力する。ＧＮＳＳとしては、ＧＰＳ、ＧＬＯＮＡＳＳ、Ｇａｌｉｌｅｏ、ＱＺＳＳ、Ｂｅｉｄｏｕ等を採用可能である。

ロケータ１３は、ＧＮＳＳ受信機の測位結果と、慣性センサの出力とを組み合わせることにより、自車両の位置を逐次算出しても良い。例えば、ロケータ１３は、トンネル内などＧＮＳＳ受信機がＧＮＳＳ信号を受信できない場合、ヨーレートと車速を用いてデッドレコニング（Dead Reckoning ：すなわち自律航法）を行う。ロケータ１３が算出した車両位置情報は車両内ネットワークＩｖＮに出力され、自動運転ＥＣＵ２０や車内監視ＥＣＵ３０等で利用される。

地図記憶装置１４は、地図データを保持する記憶媒体である。地図記憶装置１４が保持する地図データは、高精度地図データであっても良いし、ナビゲーション用の地図データであるナビ地図データであっても良い。高精度地図データは、道路構造、及び、道路沿いに配置されている地物についての位置座標等を、自動運転に利用可能な精度で示す地図データに相当する。自動運転に利用可能な精度とは、例えば、各地図要素にかかる実際の位置と地図に登録されている位置との誤差１０ｃｍ又は２０ｃｍ以下に抑制されているレベルに相当する。ナビ地図データは、ナビゲーション用の地図データであって、高精度地図データよりも相対的に精度の劣る地図データに相当する。

地図記憶装置１４は、自動運転バス１が走行しうる区域である走行予定区域についての地図データを保持していればよい。地図記憶装置１４は、走行予定区域における道路の接続関係や、道路形状、車線数などにかかる情報を含む。また、地図記憶装置１４が保持する地図データは、停留所の情報や、自動運転バス１が走行すべきレーンなどの情報を含んでいることが好ましい。自動運転バス１が走行すべきレーンには、バス専用レーンやバス優先レーンなどが含まれる。

車内センサ１５は、車内における乗客の様子を示す情報を検知し、出力するセンサである。車載システムＩｖＳは、車内センサ１５として、図３に示すように、車内カメラ１５１、車内マイク１５２、着座センサ１５３、超音波センサ１５４、及び赤外線カメラ１５５を備える。

車内カメラ１５１は、乗客の様子を撮像可能なように、例えば車室内の天井部に設置された可視光カメラである。車内カメラ１５１としては、例えばＣＭＯＳカメラやＣＣＤカメラ等を用いることができる。車内カメラ１５１は１台であってもよいし、複数台設けられていても良い。複数の車内カメラ１５１を設けた構成によれば、車内に死角が生じる恐れを低減できるとともに、１台が故障した場合でも残りのカメラで車内映像を取得可能となる。もちろん、車内カメラ１５１は１台であってもよい。車内カメラ１５１は、なるべく広範囲を撮像可能なように、魚眼レンズを用いて構成されていても良い。車内カメラ１５１は、画像データを車内監視ＥＣＵ３０に逐次出力する。なお、画像データとの表現には、映像信号も含まれる。

車内マイク１５２は、乗客の発話音声を取得するための装置（いわゆるマイクロフォン）である。車内マイク１５２は、車内の音声に対応する電気信号を車内監視ＥＣＵ３０に出力する。車内マイク１５２もまた複数箇所に分散配置されていても良い。例えば、車内マイク１５２は座席毎に設けられていても良い。車内マイク１５２、１つのマイクが互いに隣接する２つの座席付近を集音範囲に含むように配置されていても良い。また、座っている人と立っている人とで、頭部の高さ位置が異なる。そのような事情から、車載システムＩｖＳは立っている人用の車内マイク１５２と、座席に座っている人用の車内マイク１５２とを別々に備えていても良い。車内マイク１５２の設置位置や設置姿勢は、指向性を考慮して適宜選定されれば良い。

着座センサ１５３は、乗客が着座していることを検知するセンサであって、例えばシート毎に設けられている。着座センサ１５３は、例えば、各座席の着座面に埋設された圧力センサとすることができる。

超音波センサ１５４は、所定方向に向けて超音波を送信するとともに、当該送信波が物体で反射されて返ってきた反射波の受信データを解析することにより、検出範囲に存在する物体との距離を検出するデバイスである。超音波センサ１５４はソナーとも呼ばれる。超音波センサ１５４は、例えば、各座席の上方に相当する天井部において、座席の座面に向けて超音波を発する配備されている。超音波センサ１５４は、検出範囲に存在する物体との距離を示す信号を車内監視ＥＣＵ３０に出力する。超音波センサ１５４の検出結果は、座席の使用状況、すなわち、空席か、荷物が置かれているか否かを示す。また、超音波センサ１５４の検出結果は、着座者の身長を示す。

赤外線カメラ１５５は、近赤外線を検知する素子をアレイ配置してなるイメージセンサを用いて赤外線画像を生成するカメラである。赤外線画像が備える各画素の値は赤外線の強度を示す。赤外線カメラ１５５は、近赤外線を検出範囲に向けて投光する光源モジュールを備えていても良い。赤外線カメラ１５５は、例えば、天井部に車内カメラ１５１と同様に設置されうる。赤外線カメラ１５５は、赤外線画像データを車内監視ＥＣＵ３０に逐次出力する。赤外線カメラ１５５が生成する赤外線画像は、乗客の位置や、乗客の体温、姿勢などを特定するための材料として使用される。なお、赤外線カメラ１５５は、人体から放射されている遠赤外線の強弱を検知することで温度を計測する、サーマルカメラとして構成されていてもよい。上述した赤外線画像は熱画像（サーモグラフィ）であってもよい。

車内センサ１５として車載システムＩｖＳが備えるセンサの種類は適宜設計されればよく、上述した全てのセンサを備えている必要はない。また、上記以外のセンサ、例えばミリ波レーダや、ＬｉＤＡＲ、赤外線カメラ１５５、光電センサ、接触センサなどを車内センサ１５として備えていても良い。

ミリ波レーダやＬｉＤＡＲは超音波センサ１５４に代えて、又は、超音波センサ１５４と共に、天井部に配置されうる。超音波センサやミリ波レーダ、ＬｉＤＡＲは、探査波を用いて物体との距離を検出する測距センサの一例に相当する。レーザ光も電磁波の一種であるため探査波の概念に含まれる。

また、各吊り革及び手すりには、乗客によって把持されているか否かを検出するためのセンサとして接触センサが設けられていても良い。接触センサは感圧式のタッチセンサであってもよいし、静電容量式のタッチセンサであってもよい。種々の車内センサ１５は、車内の状況、具体的には乗客の状態を特定するための信号を、車内監視ＥＣＵ３０に提供する。なお、観測データに基づく乗客の状態判定は、各車内センサ１５が実施しても良いし、車内監視ＥＣＵ３０が実施しても良い。機能配置は適宜変更可能である。ここでは一例として車内監視ＥＣＵ３０が、各車内センサ１５からの入力信号を解析することにより、乗客情報を取得するものとする。

無線通信機１６は、管制センタ２などの外部装置と無線通信を実施するための装置である。無線通信機１６は、所定の広域無線通信規格に準拠した無線通信を実施するための通信モジュールを含む。ここでの広域無線通信規格としては例えばＬＴＥ（Long Term Evolution）や４Ｇ、５Ｇなど多様なものを採用可能である。自車両は、無線通信機１６の搭載により、インターネットに接続可能なコネクテッドカーとなる。

無線通信機１６は、受信信号の品質などに基づいて、管制センタ２を含む外部装置とデータ通信可能な状態であるか否かを示す情報を車内監視ＥＣＵ３０に出力する。また、無線通信機１６は、管制センタ２とデータ通信が可能である場合には、その通信速度（いわゆるスループット）の平均値や、レイテンシといった、管制センタ２との通信状態を示す指標を計測し、車内監視ＥＣＵ３０に出力してもよい。ここでのレイテンシは、無線通信機１６が送信した信号やデータが管制センタ２に届くまでにかかる伝送時間を指す。無線通信機１６は、管制センタ２と疎通確認のための制御信号を定期的にやり取りする場合には、管制センタ２宛の信号を送信してから応答が帰ってくるまでにかかる時間である往復レイテンシを計測するように構成されていても良い。往復レイテンシは、ラウンドトリップタイム（ＲＴＴ：Round-Trip Time）とも呼ばれうる。

さらに、無線通信機１６は、無線基地局３から送信される参照信号（ＲＳ：Reference Signal）を用いて、ＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱ、ＳＩＮＲ、ＰＨＲなどといった無線通信の品質／速度を直接的又は間接的に示す指標を算出しうる。無線通信機１６は、通信品質／通信速度これらの指標値を車内監視ＥＣＵ３０に出力してもよい。

なお、ＲＳＲＰは、Reference Signal Received Powerの略であり、ＲＳＲＰは、単位リソースエレメント当たりのＲＳの平均受信電力を示す。ＲＳＳＩはReceived Signal Strength Indicatorの略である。ＲＳＳＩは、ＲＳを収容するＯＦＤＭシンボルにおいてＬＴＥシステム帯域全体の電力の測定値を示す。ＲＳＳＩやＲＳＲＰは、無線基地局３からの信号（受信電波）の強度を示す指標値に相当する。以降における電波強度とはＲＳＳＩ又はＲＳＲＰを指す。

ＲＳＲＱはReference Signal Received Qualityの略である。ＲＳＲＱは、セル固有の参照信号の受信電力と、受信帯域幅内の総電力との比である。ＳＩＮＲは、Signal to Noise Interference Ratioの略であって、概略的には受信信号のうち、所望信号の電力と、所望信号以外の電力の比を示す。所望信号以外の電力とは、例えば他セル／他セクタからの干渉波や、熱雑音に由来する電力を指す。以降における受信品質とは、ＲＳＲＱ又はＳＩＮＲに対応する。ＲＳＲＰや、ＲＳＳＩ、ＲＳＲＱ、ＳＩＮＲなどの指標は値が大きいほど無線基地局３からの信号の受信品質が良いことを示す。

ＰＨＲはパワーヘッドルーム（Power Headroom）の略であって、送信電力の余力値を示す。ＰＨＲもまた大きいほど上り通信の帯域に余裕があることを示す。ＰＨＲや、ＲＳＲＰ、ＲＳＳＩ、ＲＳＲＱの算出方法自体は、３ＧＰＰ（Third Generation Partnership Project）が規定する方法により算出可能であるため、ここでの説明は省略する。

その他、無線通信機１６は他車両との無線通信である車車間通信や、路側機との無線通信である路車間通信を実施可能に構成されていてもよい。路側機とは道路沿いに設置されている通信設備を指す。例えば無線通信機１６はセルラーＶ２Ｘを実施可能に構成されていても良い。

ディスプレイ１７は、画像を表示する装置である。ディスプレイ１７は、車内監視ＥＣＵ３０から入力された映像信号に対応する画像を表示する。ディスプレイ１７は、乗客から見やすい位置、例えば車室内の天井付近に配置されている。より具体的には、乗降用ドアの上側などに配置されている。ディスプレイ１７は、フルカラー表示が可能なものであり、液晶ディスプレイ、ＯＬＥＤ（Organic Light Emitting Diode）ディスプレイ、プラズマディスプレイ等を用いて実現できる。車載システムＩｖＳは、複数のディスプレイ１７を備えていても良い。

車内スピーカ１８は、音を出力する装置である。本開示における「音」との表現には、音声や音楽も含まれる。車内スピーカ１８は、車内監視ＥＣＵ３０から入力された音声信号に対応する音を出力する。車内スピーカ１８は、例えば車室内の天井や壁等に配置されている。車載システムＩｖＳは複数の車内スピーカ１８を備えていても良い。例えば車内スピーカ１８は、座席ごとに設けられていても良い。

走行アクチュエータ１９は、自動運転バス１が走行するためのアクチュエータ類を指す。例えば制動装置や、電子スロットル、操舵アクチュエータなどが走行アクチュエータ１９に該当する。制動装置とは例えばブレーキアクチュエータである。操舵アクチュエータには、ＥＰＳ（Electric Power Steering）モータが含まれる。なお、自動運転ＥＣＵ２０と走行アクチュエータ１９との間には、操舵制御を行う操舵ＥＣＵや、加減速制御を行うパワーユニット制御ＥＣＵ、及びブレーキＥＣＵ等、他のＥＣＵが介在していてもよい。

自動運転ＥＣＵ２０は、外界センサ１１の検出結果などをもとに走行アクチュエータ１９を制御することにより、運転操作の一部又は全部をユーザの代わりに実行するＥＣＵである。自動運転ＥＣＵ２０は自動運行装置とも称される。自動運転ＥＣＵ２０は、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、ストレージ、及びこれらの構成を接続するバスラインなどを備えた、コンピュータとして構成されている。

自動運転ＥＣＵ２０は、米国自動車技術会（ＳＡＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ）が定義するレベル４相当の機能を有する。自動化レベル４は、対応不可能な所定の道路、極限環境等の特定状況下を除き、システムが全ての運転タスクを実施するレベルである。レベル４は、予め設定された運行設計領域（ＯＤＤ：Operational Design Domain）内にてシステムが全ての運転タスクを実施するレベルに相当する。レベル４は、いわゆる高度自動運転に相当する。なお、自動運転ＥＣＵ２０が提供する自動運転機能は、例えばレベル３相当であってもよいし、レベル５相当であってもよい。

自動運転ＥＣＵ２０は、より細かい機能部として制御計画部Ｇ１と制御実行部Ｇ２とを備える。制御計画部Ｇ１は、外界センサ１１の検出結果と、地図記憶装置１４に保存されている地図データとを用いて、車両の制御計画を作成する。制御計画には、各時刻における走行位置をつなげてなる走行経路が含まれる。例えば制御計画には、どの道路を通り、どの交差点で曲がるかなどといった、道路レベルでの長期的な経路情報と、直近所定時間以内に通行する道路区間においてどのレーンを走行するかなどを示す短期的な経路情報が含まれる。制御計画は、算出した経路における速度調整のための加減速のスケジュール情報や、操舵角の制御スケジュール情報、車線変更を行う地点の情報、乗客に車両挙動を予告するタイミングなどの情報を含みうる。自動運転ＥＣＵ２０は、外界センサ１１の検出結果及び地図データの少なくとも何れか一方に基づいて特定される道路の曲率に応じた加減速及び操舵の計画を作成する。

制御計画部Ｇ１は、例えば外界センサ１１の検出結果及び地図データの少なくとも何れか一方に基づき、所定時間以内に交差点を通過することが検知された場合には、交差点内の走行経路や、信号機の点灯状態に応じた停車などの制御計画を作成する。また、外界センサ１１で、自車両の前方に、例えば路上駐車車両などの障害物が存在することが検出された場合には、障害物の側方を通過する走行計画を生成しうる。その他、路上の落下物の回避や、歩行者の手前で停車する制御など、他の物体との衝突を避けるための緊急回避行動なども計画する。制御計画部Ｇ１が作成した制御計画の概要は、車内監視ＥＣＵ３０にも通知される。なお、制御計画を作成する処理の一部や、車両の走行環境の認識にかかる処理の一部又は全部は、管制センタ２で実行されても良い。自動運転にかかる機能の配置態様は適宜変更可能である。

制御実行部Ｇ２は、制御計画部Ｇ１が生成した制御計画に基づき、走行アクチュエータ１９毎の制御量を決定し、各走行アクチュエータ１９に制御信号を出力する。また、制御実行部Ｇ２は、制御計画部Ｇ１が作成した制御計画及び外部環境に基づき、方向指示器やヘッドライト、ハザードランプ等の点灯／消灯なども制御する。

本実施形態の自動運転ＥＣＵ２０は動作モードとして、通常モードに加えて、フォールバックモードを備える。通常モードは、管制センタ２との通信が正常に実施可能な状態において適用される動作モードである。通常モードにおいて自動運転ＥＣＵ２０は、走行速度や、車体に作用する加減速度、ヨーレートなどが所定の標準許容範囲内に収まるように制御計画を作成する。

一方、フォールバックモードは、管制センタ２との通信に不具合が生じている場合に、車内監視ＥＣＵ３０からの指示に基づき適用されうる動作モードである。自動運転ＥＣＵ２０は、フォールバックモード時においては、走行速度や、車体に作用する加減速度、ヨーレートなどが通常モード時よりも小さい値となるように制御計画を作成する。フォールバックモードは、制御計画時に取りうる車速や、加速度、角速度といった諸元の許容値が通常モード時よりも所定量小さい値に設定された動作モードに相当する。

例えば速度の上限値は、通常モード時には６０ｋｍ／ｈとする一方、フォールバックモード時には４０ｋｍ／ｈとすることができる。また、加減速度の許容値は、通常モード時には２．０ｍ／ｓ＾２とする一方、フォールバックモード時には１．０ｍ／ｓ＾２とすることができる。そのような構成よれば、自動運転ＥＣＵ２０はフォールバックモード時、加減速度が１．０ｍ／ｓ＾２以下になるようにアクセル／ブレーキ制御を実施することとなる。つまり、フォールバックモード時には通常モード時よりも緩やかに加減速が行われるため、乗客が転倒する恐れを低減できる。

さらに、ヨーレートの許容値は、通常モード時には１．０ｒａｄ／ｓ＾２とする一方、フォールバックモード時には０．５ｒａｄ／ｓ＾２に設定できる。そのような設定によれば、自動運転ＥＣＵ２０はフォールバックモード時、角速度が０．５ｒａｄ／ｓ＾２以下になるように操舵制御を実施することとなる。つまり、フォールバックモード時には通常モード時よりも緩やかに旋回が行われるため、乗客が転倒する恐れを低減できる。

もちろん、上記の数値は一例であって通常モード時及びフォールバックモード時のそれぞれの制御上の許容値は適宜変更可能である。フォールバックモードとして抑制される諸元は、速度、加減速度、及びヨーレートの何れか１つだけであってもよい。フォールバックモードは、通常モードよりも慎重に制御するモードであればよい。また、フォールバックモードでの車両制御は慎重制御と呼ぶとともに、通常モードでの車両制御を通常制御と呼ぶことができる。慎重制御は通常制御よりも、乗客が転倒しにくい制御と解することができる。

なお、通常モードでの制御上の諸元もまた、乗客の安全性や乗り心地を鑑みて設定されている。常にフォールバックモードで運行すると、移動速度が遅くなり、渋滞の要因となったり、移動時間の増大に伴って乗客の利便性を損なったりする可能性が生じる。通常モードの制御条件は、乗客の安全性及び乗り心地に加えて、他の交通との協調性や、移動時間に対応する利便性なども考慮して設定されている。自動運転ＥＣＵ２０は、基本的には通常モードで運行する一方、管制センタ２との通信状況に応じて一時的にフォールバックモードで走行することにより、乗客の安全性や、乗り心地、利便性などの要求を充足可能となる。

車内監視ＥＣＵ３０は、車内センサ１５から入力される信号に基づいて、乗客の様子を見守り、必要に応じて注意喚起や降車案内、転倒者に対する安否確認などのアナウンスを実施するＥＣＵである。車内監視ＥＣＵ３０は、プロセッサ３１、ＲＡＭ３２、ストレージ３３、通信モジュール３４、及びこれらを接続するバス等を備えたコンピュータを主体として構成されている。プロセッサ３１は、ＲＡＭ３２と結合された演算処理のためのハードウェアである。プロセッサ３１は、ＣＰＵやＧＰＵ（Graphics Processing Unit）等の演算コアを少なくとも一つ含む構成である。プロセッサ３１は、ＲＡＭ３２へのアクセスにより、種々の処理を実行する。

ストレージ３３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ３３には、プロセッサ３１によって実行されるプログラムである乗客見守りプログラムが格納されている。なお、乗客見守りプログラムは、無線通信によって適宜書き換え（更新）可能に構成されていても良い。プロセッサ３１が乗客見守りプログラムを実行することは、乗客見守りプログラムに対応する方法が実行されることに相当する。通信モジュール３４は、車両内ネットワークＩｖＮを介して他の車載デバイスと通信するための回路である。通信モジュール３４は、アナログ回路素子やＩＣ、車両内ネットワークＩｖＮの通信規格に準拠したＰＨＹチップなどを用いて実現されている。

車内監視ＥＣＵ３０は、ストレージ３３に保存されている車内監視プログラムを実行することにより、図４に示す種々の機能ブロックに対応する機能を提供する。すなわち、車内監視ＥＣＵ３０は機能ブロックとして、特定行動検出部Ｆ１、通信状態取得部Ｆ２、報告処理部Ｆ３、及び、応答部Ｆ４を備える。また、車内監視ＥＣＵ３０は、乗客対応テーブルが格納されているデータベースである乗客対応テーブル記憶部Ｍ１と、電波強度マップが格納されている電波強度マップ記憶部Ｍ２とを備える。乗客対応テーブル記憶部Ｍ１が報知用データ記憶部に相当する。乗客対応テーブルは、乗客の行動に対応するアナウンス／車両制御を行うためのデータである。乗客対応テーブルについての詳細は別途後述する。電波強度マップは地点ごとの電波強度を示すデータである。電波強度マップ記憶部Ｍ２が記憶媒体に相当する。

乗客対応テーブル記憶部Ｍ１及び電波強度マップ記憶部Ｍ２はそれぞれ、書き換え可能な不揮発性の記憶媒体を用いて実現されている。ここでは一例として乗客対応テーブル記憶部Ｍ１及び電波強度マップ記憶部Ｍ２はストレージ３３が備える記憶領域を用いて実現されている。乗客対応テーブル記憶部Ｍ１及び電波強度マップ記憶部Ｍ２はそれぞれ、プロセッサ３１によるデータの書き込み、読出、削除等が実施可能に構成されている。なお、乗客対応テーブル記憶部Ｍ１は、ストレージ３３とは物理的に独立した記憶媒体を用いて実現されていても良い。電波強度マップ記憶部Ｍ２も同様である。また、電波強度マップ記憶部Ｍ２は例えばＲＡＭ３２等の揮発性メモリを用いて実現されていても良い。

なお、電波強度マップは、管制センタ２からの配信により動的に更新されうる。また、管制センタ２は、複数の自動運転バス１で観測された地点ごとの電波強度を統計化することで、電波強度マップを作成及び更新する。なお、電波強度マップは、先行車両で観測された電波強度を、車々間通信により取得することで生成又は修正されてもよい。車内監視ＥＣＵ３０は電波強度マップ記憶部Ｍ２を備えることにより、自車両がこれから走行予定の地点ごとの管制センタ２の通信状態を先読み（予測）することが可能となる。

特定行動検出部Ｆ１は、車内センサ１５からの入力信号に基づいて、乗客が所定の特定行動を実施したことを検出する構成である。ここでの特定行動には、転倒したこと、及び、転倒のリスクが高まる所定の不安全行動が含まれる。不安全行動とは、例えば、吊り革又は手すり（以降、吊り革等）に掴まずに立っていることや、車両走行中の歩行、車両走行中に立ち上がること、シートベルトの未装着、及び、窓から手／顔を出すことなどである。不安全行動が維持されている状態は不安全状態と呼ぶこともできる。本開示の特定行動は特定状態と読み替えることもできる。

本実施形態の特定行動検出部Ｆ１は、より好適な例として、乗車中のマナー違反に該当する行為も特定行動として検出可能に構成されている。マナー違反相当の特定行動とは、例えば、大声での会話や、携帯電話での通話、２つ以上の座席を１人で占有すること、座席に寝ること、喫煙などである。その他、車内の設備を叩く／蹴るなどの、車体／設備の破損につながる行為や、乗客同士の口論、喧嘩なども特定行動に含まれうる。

特定行動検出部Ｆ１は、乗客が転倒したことや、吊り革等に掴まずに立っていること、車両走行中の歩行、車両走行中に立ち上がることなどの行為を、車内カメラ１５１の画像を解析することで検出する。各種特定行動は、ＣＮＮ（Convolutional Neural Network）やＤＮＮ（Deep Neural Network）などを用いた識別モデルを用いて検出される。窓から手／顔を出すことや、２つ以上の座席を１人で占有すること、座席に寝ること、喫煙などの行為も同様である。

なお、吊り革等を掴んでいないことは、吊り革に設けられた接触センサなどの検知結果を併用して、換言すればセンサフュージョンにより特定されてもよい。また、窓を開けるなどの行為は、窓の開閉に対応する車両状態センサ１２からの入力信号に基づいて検出されうる。喫煙は車両に設置された煙センサの出力から検知されてもよい。車内設備を叩く／蹴るなどの破損につながる行為や、転倒したことなどは、加速度センサ／振動センサの出力を併用して検出しても良い。大声での会話や口論などは、車内マイク１５２が集音した音声のボリュームや発話内容から検出されても良い。検出すべき乗客の行動／状態、及び、その検出アルゴリズムは、乗客見守りプログラムに組み込まれている。

特定行動検出部Ｆ１はサブ機能として、乗客情報取得部Ｆ１１とリスク評価部Ｆ１２を備える。乗客情報取得部Ｆ１１は、車内センサ１５からの入力信号に基づき、乗客についての情報である乗客情報を取得する。乗客情報には、乗客の人数や、乗客ごとの位置、乗車姿勢などが含まれる。乗車姿勢には、座席に座っているか、立っているかを含む。立っている乗客に関しては、より具体的な乗車姿勢として、吊り革や手すりを掴んでいるか否かを含めることができる。

さらに、乗客情報には、乗客の年齢や、体格、性別、服装などの属性情報を含めることができる。乗客の年齢は、例えば、１４歳以下の第１年齢層、１５歳以上６５歳未満の第２年齢層、及び、６５歳以上の第３年齢層に区分して判定されうる。年齢層の区分数は一例であって４つ以上に区分されても良い。第３年齢層は高齢層と言い換えることができる。服装には、ヒールなどの転倒しやすい靴を履いているか、スニーカなどの相対的に転倒しにくい靴を履いているかといった履物の種別を含めることができる。これらの乗客情報は、例えば車内カメラ１５１の撮影画像を解析することで特定されうる。もちろん、乗客情報取得部Ｆ１１は、車内カメラ１５１の画像と、着座センサ１５３や超音波センサ１５４など、複数種類の車内センサ１５の入力信号を組み合わせることにより、乗客ごとの情報を取得しても良い。

なお、乗客ごとの属性情報には、歩行補助具の使用の有無や、車椅子の使用の有無や、障がい（ハンディキャップ）の有無が含まれていてもよい。歩行用補助具には、杖やシルバーカーなどが含まれる。上記属性の検出もまた車内カメラ１５１の画像を解析することで特定されうる。たとえば乗客情報取得部Ｆ１１は、白杖を所持している乗客を画像認識により検出した場合には、視覚に障害を持つ可能性がある人物としてピックアップしてもよい。また、車椅子を画像認識により検出した場合には、車椅子の利用者が乗車中であると判定してもよい。その他、乗客情報取得部Ｆ１１は、赤外線カメラ１５５から入力された赤外線画像を解析することにより、発熱者などを検出しても良い。

リスク評価部Ｆ１２は、乗客の不安全行動を検出した場合に、当該不安全行動を実施した乗客である対象者の属性情報や、実施された不安全行動／状態の内容に基づいて、転倒する可能性の高さである転倒リスクＲｆを算出する。対象者は、行動実施者と呼ぶこともできる。転倒リスクＲｆは複数段階のレベルで表現されてもよいし、例えば０から１００までのスコア値で表現されても良い。ここでは一例として、転倒リスクＲｆを０から３までの４段階で評価する。

リスク評価部Ｆ１２は、例えば次のような式１で転倒リスクＲｆを算出する。
式１：Ｒｆ＝Ｅａ＋Ｅｂ＋Ｅｃ

上記の式１を構成するパラメータＥａは、不安全行動の内容に応じた値が設定されるパラメータである。パラメータＥａは、転倒のリスクが高い行動ほど大きい値が設定される。パラメータＥａは、吊り革等を掴まずに立っている場合には最も大きく、座っている状態が最も低く、吊り革等を掴んで立っている状態がその中間値に設定される。例えば、吊り革等を掴まずに立っている場合にはＥａ＝２が適用され、座っている場合にはＥａ＝０が適用され、吊り革等を掴んで立っている場合にはＥａ＝１が適用される。なお、吊り革等を掴んでいなくとも、車室内の壁や窓枠などに手をついたり、寄りかかったりしている場合には、例えば１．５など、吊り革等を掴んでいる場合よりも転倒リスクＲｆが高く算出される値が適用されても良い。また、着席している場合であっても、シートベルトが未装着である場合には、シートベルトを装着している場合よりもパラメータＥａは所定量大きく設定されうる。

パラメータＥｂは、乗客の年齢に応じた値が適用されるパラメータである。パラメータＥｂは、乗客が第１年齢層または第３年齢層に該当するとは判定されている場合、その他の場合よりも大きい値が設定されうる。より具体的には、乗客が第１年齢層または第３年齢層に該当するとは判定されている場合にはＥｂ＝１が設定される一方、第２年齢層に該当すると判定されている場合にはＥｂ＝０に設定される。

パラメータＥｃは、年齢以外の要素による値が適用される補正パラメータである。例えば、乗客が歩行補助具や車椅子、白杖を利用している場合に１以上の任意の値が設定される。また、乗客が身体的なハンディキャップを有することが推定される場合にも１等が適用される。乗客が妊婦、又は、抱っこ紐等で幼児を抱えている場合にも、パラメータＥｃには所定の正の値が適用されても良い。各パラメータが少数を含むことによって、Ｅａ＋Ｅｂ＋Ｅｃが少数を含む場合、小数第１位を四捨五入することにより、最終的な転倒リスクを決定しても良い。

上記の式１は一例である。式１では加算（加点）方式で転倒リスクＲｆを算出する構成に対応する。もちろん、リスク評価部Ｆ１２は加算方式ではなく、リスク因子を乗算することで最終的な転倒リスクＲｆを算出してもよい。例えばリスク評価部Ｆ１２は、次の式１ａを用いて転倒リスクＲｆを算出しても良い。

式１ａ：Ｒｆ＝Ｅａ×Ｅｂ×Ｅｃ
上記式１ａにおいてはＥｂやＥｃは、所定の体型であって且つスニーカを着用している２０歳の人物を基準値（１）として、種々の属性に応じた１以上の値が適用されることが好ましい。例えば高齢者である場合にはＥｂ＝１．５や２などが設定されうる。どのような人物を基準とするか、及び、種々の属性に対してどのような値を適用するかは適宜設計されれば良い。基本的に、転倒しやすい人ほど、あるいは、転倒したときのリスクが大きい人ほど、総合的な転倒リスクＲｆが高く評価されるように設定されれば良い。

さらにリスク評価部Ｆ１２は、自動運転ＥＣＵ２０から取得する、車外状況や制御計画を考慮して転倒リスクＲｆを算出しても良い。すなわち、車外状況や制御計画に由来するパラメータＥｄを用いて次の式１ｂのように転倒リスクＲｆを算出しても良い。パラメータＥｄは制御計画や道路形状に応じて転倒リスクＲｆの高さを補正する係数に相当する。

式１ｂ：Ｒｆ＝Ｅａ×Ｅｂ×Ｅｃ×Ｅｄ
例えばパラメータＥｄは、平坦な直線道路を略一定の速度で走行する場合を１（基準値）として、停車や発進、急カーブへの進入、右左折をする場合に、１よりも大きい値が適用されれば良い。ここでの直線道路とは、曲率が所定値未満の道路を指し、曲率が所定値以上の道路区間をカーブ路と称する。また、カーブ路のなかでも曲率が所定の閾値以上の道路を急カーブと称する。リスク評価部Ｆ１２は、所定の閾値以上の加減速を行うこと、所定の閾値以上の舵角速度で操舵を行うことなどの計画がなされている場合にも、パラメータＥｄを１よりも大きい所定値が適用しうる。

なお、リスク評価部Ｆ１２は、不安全行動を実施した人物に限らず、全ての乗客に対し、その乗車姿勢に応じた転倒リスクＲｆを算出しても良い。パラメータＥａの値は、現在の乗車姿勢、すなわち、座っているか、立っているか、吊り革等を掴んでいるか否かなどに基づいて決定されれば良い。

通信状態取得部Ｆ２は、管制センタ２との現在の通信状態を取得する構成である。現在の通信状態を取得する。すなわち、通信状態取得部Ｆ２は無線通信機１６から管制センタ２との現在の通信状態を示すデータを取得する。また、通信状態取得部Ｆ２は、無線通信機１６から現在の無線通信品質を示す情報として電波強度や受信品質などを取得してもよい。通信状態取得部Ｆ２が取得した現在の無線通信品質を示す情報は、応答部Ｆ４に提供される。

報告処理部Ｆ３は、自車両の現在位置や、車速、進行方位、ヨーレートなど、車両の走行状態を示すデータを走行状態報告として管制センタ２に送信する処理を逐次実行する。自車両の現在位置には、自車両が走行しているレーンであるエゴレーンが、左側または右側の道路端から何番目のレーンであるかを示すエゴレーン番号を含めることができる。また、報告処理部Ｆ３は、車外映像を管制センタ２に送信する。車外映像とは例えば前方カメラや側方カメラ、後方カメラの映像を指す。カメラ映像等の送信は、ＲＴＳＰ（Real Time Streaming Protocol）など所定のプロトコルに準拠して実施されうる。また、映像の伝送は例えばH.264や、H.265など、任意のコーデックを用いて実施されうる。すなわち、報告処理部Ｆ３は、多様なリアルタイム映像配信技術を用いて、車外映像を管制センタ２に送信する。報告処理部Ｆ３による走行状態報告の送信は、無線通信機１６との連携によって実施される。報告処理部Ｆ３が逐次走行状態報告を送信することにより、オペレータＯｐ等は、自動運転バス１の運行状態を管理可能となる。なお、ここでのオペレータＯｐとは、管制センタ２において自動運転バス１の運行状況を管理するスタッフを指す。

また、報告処理部Ｆ３は、車内映像及び車内音声を管制センタ２に逐次送信する。車内映像とは車内カメラ１５１の映像を指す。また、車内音声とは、車内マイク１５２が取得した音声を指す。車内映像等の送信は、車外映像の送信と同様の方式で実施されうる。車内映像及び車内音声を管制センタ２に送信する事により、オペレータＯｐ等は、自動運転バス１の車内状況を把握可能となる。また、報告処理部Ｆ３は、乗員数や、乗員ごとの体温、乗車姿勢などといった、映像等に基づく乗客の認識結果を示すデータを車内状態報告として管制センタ２に定期的に送信しても良い。

車内状態報告の送信は、管制センタ２との通信が可能な状態においては、定期的に実施される。また、車内状態報告の送信は、停留所等でドアを開けたことや、ドアを閉じたこと、所定値以上の加減速（いわゆる急ブレーキ）、所定値以上のヨーレート（いわゆる急操舵）などといった所定の報告イベントの発生を検知したことをトリガとして実行してもよい。前述の特定行動の検出も、報告イベントに含めることができる。

なお、他車両等との衝突回避等の観点から、報告処理部Ｆ３は車外映像を車内映像よりも優先的に送信するように構成されていても良い。そのような構成によれば無線通信環境の劣化等により、利用可能な帯域が少ない場合であってもできる限り車外映像等の走行環境を示すデータを管制センタ２に送信可能となる。また、他の態様として報告処理部Ｆ３は、車内保安の観点から、車内映像等を車外映像よりも優先的に送信するように構成されていても良い。そのような構成によれば、利用可能な帯域が少ない場合であってもできる限り乗客の様子を示すデータを管制センタ２に送信可能となり、乗客の転倒、不安全行動、トラブル等に迅速にオペレータＯｐが対応可能となる。

その他、報告処理部Ｆ３は、地点ごとの無線通信の状態を示すデータセットである通信状態報告を逐次管制センタ２に送信するように構成されていてもよい。通信状態報告は、例えば地点ごとの電波強度や受信品質などを示す通信パケットとすることができる。また、通信状態報告は、管制センタ２との通信におけるスループットや往復レイテンシなどの計測値を含んでいても良い。種々の報告データには、送信元を示す車両情報や、送信時刻を示す送信時刻情報などが含まれうる。

応答部Ｆ４は、特定行動検出部Ｆ１が乗客の特定行動を検出したことに基づいて、当該行動に対応する処理（以降、応答処理）を実施する。例えば特定行動検出部Ｆ１が乗客の転倒を検知した場合には、転倒した乗客の安否を問い合わせるアナウンスを出力する。なお、乗客の転倒を検知した場合、応答部Ｆ４は停車に向けた減速を開始しても良い。また、応答部Ｆ４は乗客の不安全行動を検出した場合には、着席や、吊り革等の把持を促すアナウンスを実施する。

応答部Ｆ４は、システム応答処理を実施するためのサブ機能部として、通信状態予測部Ｆ４１、規定メッセージ出力部Ｆ４２、及びセンタ連携部Ｆ４３を備える。

通信状態予測部Ｆ４１は、制御計画が示す各時刻の自車予定位置と、電波強度マップとを照らし合わせることにより、現在から所定時間以内の無線通信品質の推移を予測する。また、通信状態予測部Ｆ４１は、現時点において管制センタ２とのデータ通信に不具合が生じている場合には、電波強度マップと制御計画とを用いて図５に示すように復旧予想時間Ｔｒｃを算出する。

復旧予想時間Ｔｒｃは、電波強度が所定の要求レベルＰｒｑ以上となるまでに要する時間の予測値である。要求レベルＰｒｑは、車内カメラ１５１の映像信号を安定的に送信可能なレベルであっても良いし、オペレータＯｐの音声データを安定的に受信可能なレベルであってもよい。要求レベルＰｒｑは、管制センタ２とデータ通信可能な最低レベルであってもよい。要求レベルＰｒｑは設計者により予め設定されている。

管制センタ２とのデータ通信に不具合が生じている場合には、データ通信が完全に不能な状態が含まれる。また、管制センタ２とのデータ通信に不具合が生じている場合には、通信が不安定である状態を含めることができる。通信が不安定な状態とは、例えば、データ通信は可能であるものの、電波強度が所定の強度下限値Ｐｍｎ未満である場合を含む。強度下限値Ｐｍｎは、パケットロス率が所定の閾値以上となる値、あるいは、受信信号を復号できる受信強度の下限値に相当する。

図５では強度下限値Ｐｍｎを要求レベルＰｒｑよりも所定量小さく設定した態様を示しているがこれに限らない。強度下限値Ｐｍｎと要求レベルＰｒｑは同じであっても良い。つまり要求レベルＰｒｑが、通信困難と判定する閾値として使用されても良い。また、通信のレイテンシが所定の閾値以上となっている場合や、スループットが所定の閾値未満である場合、パケットロス率が所定の閾値以上である場合なども通信が不安定な状態に含めることができる。さらに、ＲＳＲＱやＳＩＮＲなどの品質指標が所定の閾値以下である場合も、不安定状態に含めることができる。

規定メッセージ出力部Ｆ４２は、乗客対応テーブルを参照し、検出された特定行動に対応する規定のメッセージを音声出力する構成である。乗客対応テーブルは、例えば図６に示すように、特定行動の内容と出力メッセージとの対応関係を示すデータとすることができる。このような規定メッセージ出力部Ｆ４２は、車両内部、より具体的には車内監視ＥＣＵ３０内で応答処理を完結させるため、内部処理部と呼ぶことができる。なお、乗客の行動に対応する適正なメッセージ／フレーズが存在しない場合には、「管制センタに連絡中です」などといったフレーズを採用可能である。

一方、センタ連携部Ｆ４３は車両外部にある装置との連携によって特定行動に対応する車内アナウンスを行う構成である。便宜上、管制センタ２から特定行動に対するアナウンス用のデータを取得し、車内スピーカから音声出力する一連の処理のことをセンタ連携処理とも称する。また、検出されている特定行動について管制センタ２から送信されてくる音声データのことをセンタ音声データとも称する。

例えばセンタ連携部Ｆ４３は、オペレータＯｐに乗客対応（例えば音声入力）を要求する信号である対応要求信号を送信し、オペレータＯｐが入力した音声データの受信を待機する。すなわち、オペレータＯｐに検出された特定行動に対する乗客対応を委任する。そして、管制センタ２からの音声データを受信次第、当該音声データを車内スピーカ１８から出力する。

対応要求信号は、概要情報として、検出された特定行動の内容や、特定行動を実施した乗客である対象者の位置を示す情報を含んでいてもよい。対象者の位置を示す情報は、座席番号等で表現されうる。対応要求信号が概要情報を含む構成によれば、サーバプロセッサ２３１は概要通知画像を表示可能となり、オペレータＯｐが対象者を速やかに特定し、状況に応じた注意喚起／提案等を実施可能となる。また、対応要求信号は、概要情報の他に、対象者の拡大静止画などを含んでいても良い。対応要求信号は、その役割から、特定行動が実施されていることを管制センタ２に通知する通知信号と解することができる。

このようなセンタ連携部Ｆ４３は、特定行動が実施されていることを管制センタ２に報告するとともに、管制センタ２の指示に基づく音声出力や車両制御を実行する構成に相当する。管制センタ２の指示に基づく音声出力には、オペレータＯｐの音声を車内スピーカ１８に出力することを含む。なお、センタ連携処理は、オペレータＯｐ用のマイク２２２と、車内に配置された車内スピーカ１８とを仮想的に接続する処理であっても良い。具体的には、センタ連携処理として車内の乗客が車内マイク１５２及び車内スピーカ１８を介してオペレータＯｐと通話可能なように、電話回線を接続する処理であってもよい。

また、センタ連携部Ｆ４３は、規定メッセージの出力を保留し、オペレータＯｐを含む管制センタ２からの指示を待つ構成に相当する。なお、センタ連携処理のうち、特定行動が実施されていることの報告は、応答部Ｆ４と報告処理部Ｆ３との連携によって実施されうる。センタ連携部Ｆ４３が報告処理部Ｆ３の機能を備えていても良い。換言すれば報告処理部Ｆ３はセンタ連携部Ｆ４３に内在していても良い。応答部Ｆ４の具体的な作動例については別途後述する。

＜管制センタ２の構成について＞
ここでは、管制センタ２の構成について説明する。管制センタ２が図７に示すように、通信装置２１、オペレータ用ＨＭＩ２２、及び管理サーバ２３を備える。部材名称中のＨＭＩは、Human Machine Interfaceの略である。なお、管制センタ２の通信相手としての自動運転バス１との表現は、車載システムＩｖＳ又は車内監視ＥＣＵ３０と読み替えることができる。

通信装置２１は、広域通信ネットワーク４及び無線基地局３を介して自動運転バス１とデータ通信を実施するための通信設備である。通信装置２１は、例えば光ファイバなどを用いて広域通信ネットワーク４を構成する設備と接続されている。通信装置２１は、自動運転バス１から送信されてきたデータを受信して管理サーバ２３出力する。例えば通信装置２１は、自動運転バス１からの走行状態報告や車内状態報告を管理サーバ２３に出力する。また、通信装置２１は管理サーバ２３から入力されたデータを、自動運転バス１に向けて送信する。例えば通信装置２１は、管理サーバ２３から入力された音声データなどを自動運転バス１に向けて送信する。

オペレータ用ＨＭＩ２２は、オペレータＯｐが自動運転バス１の走行状態及び車内状態を確認するとともに、状況に応じて車両制御に介入したり乗客に向けた報知を実施したりするための設備である。オペレータ用ＨＭＩ２２は、ディスプレイ２２１、マイク２２２、スピーカ２２３、及び入力装置２２４を備える。

ディスプレイ２２１は、管理サーバ２３から入力された映像信号に基づいて画像を表示する。例えばディスプレイ２２１には自動運転バス１の車外映像と車内映像とが表示される。ディスプレイ２２１は１つであっても良いし、複数あってもよい。ディスプレイ２２１は、オペレータＯｐ用のデスクに配置されている。マイク２２２は、オペレータＯｐのためのマイクロフォンである。マイク２２２は、オペレータＯｐが発話した音声を集音し、電気信号に変換して管理サーバ２３に出力する。スピーカ２２３は、管理サーバ２３から入力された音声信号を音に変換して出力する。スピーカ２２３及びマイク２２２はオペレータＯｐ用のヘッドセットとして一体的に構成されていても良い。

入力装置２２４は、自動運転バス１に対するオペレータの指示操作を受け付けるための装置である。入力装置２２４としては、キーボードや、複数のスイッチを含む専用のデバイス、ディスプレイ２２１に積層されたタッチパネルなどを採用可能である。オペレータ用ＨＭＩ２２は、例えば入力装置２２４としてトークスイッチを備える。トークスイッチは、マイク２２２を有効化して、オペレータＯｐの発話音声を、自動運転バス１の車内スピーカ１８から出力するためのスイッチに相当する。

また、オペレータＯｐが自動運転バス１を遠隔操作するためのハンドルやペダル類、シフトレバー、ライトスイッチなどもまた入力装置２２４に含めることができる。なお、ライトスイッチは、方向指示器、前照灯、前部霧灯、（いわゆるフォグランプ）、及び、非常点滅表示灯（いわゆるハザードランプ）の少なくとも何れか１つの点灯状態を切り替えるスイッチである。スイッチの概念には、ボタン式のものに限らず、レバー式や、ダイヤル式、タッチセンサ式のものも含まれる。

入力装置２２４へのオペレータＯｐの操作は、オペレータＯｐの行為又は指示入力と読み替える事ができる。入力装置２２４は、当該装置に対してオペレータＯｐが行った操作に対応する電気信号を操作信号として管理サーバ２３に出力する。オペレータＯｐの操作信号は、オペレータＯｐの操作内容を示す情報を含む。

管理サーバ２３は、サーバプロセッサ２３１、ＲＡＭ２３２、及びストレージ２３３を備える、コンピュータを主体として構成されている。サーバプロセッサ２３１は、ＲＡＭ２３２と結合された演算処理のためのハードウェアである。サーバプロセッサ２３１は、ＣＰＵ等の演算コアを少なくとも一つ含む構成である。サーバプロセッサ２３１は、ＲＡＭ２３２へのアクセスにより、種々の処理を実行する。ストレージ２３３は、フラッシュメモリ等の不揮発性の記憶媒体を含む構成である。ストレージ２３３には、サーバプロセッサ２３１によって実行されるプログラムとして、サーバ用プログラムが格納されている。サーバプロセッサ２３１が上記プログラムを実行することは、サーバ用プログラムに対応する方法である車内状態外部調整方法を実行することに相当する。

管理サーバ２３は通信装置２１及びオペレータ用ＨＭＩ２２のそれぞれと通信可能に接続されている。管理サーバ２３には、通信装置２１及びオペレータ用ＨＭＩ２２のそれぞれから適宜データ信号が入力される。また、管理サーバ２３は、適宜、通信装置２１及びオペレータ用ＨＭＩ２２のそれぞれに制御信号及びデータ信号を出力する。

例えばサーバプロセッサ２３１は、通信装置２１が受信した自動運転バス１の車外映像や、車内映像、各種ステータス情報をディスプレイ２２１に表示する。このような処理は自動運転バス１の内部又は外部の状況をオペレータＯｐに通知する、車両状態通知処理に相当する。例えばサーバプロセッサ２３１は、自動運転バス１が運行中は、自動運転バス１の車外映像や、車内映像、各種ステータス情報をディスプレイ２２１に表示してもよい。また、サーバプロセッサ２３１は、特定の運行状況確認条件が充足した場合にのみ、車外映像や、車内映像、各種ステータス情報をディスプレイ２２１に表示するように構成されていても良い。運行状況確認条件が充足した場合とは、例えば、自動運転バス１から対応要求信号を受信した場合や、オペレータＯｐによる運行状態を確認するための操作が行われた場合、自動運転バス１がバス停などに停車した場合などが挙げられる。

サーバプロセッサ２３１は、自動運転バス１で特定行動が検出されている場合である特定行動検出時と、特定行動が観測されていない通常時とで、ディスプレイ２２１の表示内容、例えば画面レイアウトを変更するように構成されていてもよい。特定行動検出時は、対応要求信号を受信した場合に相当する。

例えばサーバプロセッサ２３１は、通常時には車内全体を俯瞰した画像を主として表示する一方、特定行動検出時には特定行動を実施している乗客付近の画像を拡大表示するように構成されていても良い。当該構成によれば、オペレータＯｐは検出された特定行動を確認しやすくなる。加えて、検出結果の正当性、つまり誤検出であるか否かを判断可能となる。

また、サーバプロセッサ２３１は、通常時には車外映像を車内映像よりも大きく表示する一方、特定行動検出時には車外映像よりも車内映像を大きく表示してもよい。より具体的には通常時には車外映像と車内映像とを６：４、又は１０：０のサイズ比で表示する一方、特定行動検出時には４：６又は０：１０のサイズ比で表示しても良い。通常時には車外映像を主体的に表示することにより、車外状況の視認性を高めることができる。また、特定行動検出時には車内映像を主体的に表示する事により車内状況の視認性を高めることができる。

なお、管理サーバ２３は、特定行動にかかる検出結果の正誤をオペレータＯｐが入力可能に構成されていても良い。そのような構成によれば、特定行動の検出結果に対してフィードバックがかかり、車内監視ＥＣＵ３０による特定行動の検出精度を向上可能となる。

また、サーバプロセッサ２３１は、自動運転バス１から対応要求信号を受信した場合には、車内監視ＥＣＵ３０が検出した特定行動の概要を示す概要通知画像を、車内カメラ１５１の映像に表示し、オペレータＯｐの入力操作を待機してもよい。そして、サーバプロセッサ２３１は、マイク２２２を介してオペレータＯｐの発話音声データを取得すると、当該音声データを通信装置２１との協働により自動運転バス１に送信する。

図８は概要通知画像の一理を示す画像である。概要通知画像は、検出された特定行動の内容や、特定行動を実施した乗客である対象者の位置を示す情報を含むことが好ましい。例えば概要通知画像は図８に示すように、概要を示すテキストＩｍ１と、車内を模式的に表す模式図画像Ｉｍ３と、対象者の位置を示す位置アイコン画像Ｉｍ４とを含む。位置アイコン画像Ｉｍ４は、模式図画像Ｉｍ３上において、対象者の位置に対応する領域に重畳表示される。

対象者の位置を示す情報は、座席番号等で表示されうる。また、対象者の位置情報は、車室内をメッシュ状に区切ってなる区画毎の番号で表現されても良い。概要通知画像を表示する構成によれば、オペレータＯｐは対象者を速やかに特定し、状況に応じた注意喚起／提案等を実施可能となる。

また、概要通知画像は、図８に例示するように、映像確認ボタンＩｍ５、マイク起動ボタンＩｍ６、処置不要ボタンＩｍ７など、オペレータＯｐの入力操作を受け付けるためのボタン画像を含んでいても良い。映像確認ボタンＩｍ５は、車内カメラ１５１の画像を表示するためのボタン画像である。サーバプロセッサ２３１は、映像確認ボタンＩｍ５が選択されたことを示す操作信号が入力されたことに基づいて車内カメラ１５１の画像を表示するように構成されていても良い。マイク起動ボタンＩｍ６は、マイク２２２を起動するためのボタン画像である。サーバプロセッサ２３１は、マイク起動ボタンＩｍ６が選択されたことを示す操作信号が入力されたことに基づいてマイク２２２を起動し、オペレータＯｐの発話音声を車内スピーカ１８から出力可能な状態に設定する。処置不要ボタンＩｍ７は、検出された行動に対するアナウンス等は不要であることをオペレータＯｐが入力するためのボタン画像である。サーバプロセッサ２３１は、処置不要ボタンＩｍ７が選択されたことを示す操作信号が入力されたことに基づいて、自動運転バス１に対して、注意喚起等は不要であることを示す応答信号を返送するように構成されていても良い。

その他、概要通知画像は、運行計画上の次のイベントの内容と、当該イベントまでの残距離／残余時間を含んでいても良い。例えばサーバプロセッサ２３１は、次の制御イベントとして交差点の左折が予定されている場合には、当該左折ポイントまでの残距離／残余時間を含む概要通知画像を表示しても良い。

なお、オペレータＯｐの音声送信は、特定行動検出時に限らず、オペレータＯｐの操作に基づき、いつでも実行可能に構成されている。また、管理サーバ２３は、オペレータＯｐの操舵又はブレーキなどの運転操作を検知した場合には、操作内容に対応する制御信号を自動運転バス１に送信する。例えばオペレータＯｐによるブレーキペダルの踏み込みを検知した場合には、自動運転バス１に対して、自動運転ＥＣＵ２０による制御を一時的に停止させるとともに、オペレータＯｐのペダル踏み込み量に応じた減速を実施させるための信号を送信する。管理サーバ２３はオペレータＯｐによるオーバライドを実現しうる。

その他、管理サーバ２３は、自動運転バス１を含む複数の車両から、地点ごとの電波強度を示す情報を収集することにより、電波強度マップを所定の更新間隔で更新するように構成されていても良い。更新間隔は例えば１時間、２時間、４時間、１日とすることができる。電波強度マップが示す地点ごとの電波強度は、所定の収集時間以内に受信した地点ごとの電波強度を母集団とする統計的な代表値とすることができる。ここでの代表値は、平均値であっても良いし中央値であってもよい。また、母集団から外れ値を除去してなる集合の平均値又は中央値であってもよい。外れ値は、もとの母集団の平均値又は中央値から標準偏差の２倍又は３倍以上離れた値とすることができる。外れ値判定の方法としては、スミルノフグラブス検定や、トンプソン検定など多様な方法を援用できる。

＜車内監視ＥＣＵ３０の作動例について＞
ここでは図９に示すフローチャートを用いて車内監視ＥＣＵ３０の作動について説明する。便宜上、図９に示す一連の処理を車両側処理と称する。図９に示すフローチャートは、走行用電源がオンに設定されている場合や、自動運転バス１の運行時間／営業時間に該当する場合など、所定の実行条件が充足されている間、所定の監視周期で繰り返し実行されうる。監視周期としては１００ミリ秒や２００ミリ秒、１秒などを採用することができる。ここでは一例として車両側処理は、ステップＳ１１～Ｓ１８を備える。なお、車両側処理を構成するステップ数や実行順番は適宜変更可能である。各ステップはプロセッサ３１によって実施される。

ステップＳ１１では乗客情報取得部Ｆ１１が、車内センサ１５からの入力信号に基づき乗客情報を取得し、ステップＳ１２に移る。本開示における取得には、他の装置／プログラムから提供される場合に限らず、内部演算によって生成／検出することも含まれる。ステップＳ１２は任意の処理であって省略されても良い。

ステップＳ１２ではプロセッサ３１が、外界センサ１１からの入力信号に基づき、車両外部についての情報である外界情報を取得してステップＳ１３に移る。外界情報には、例えば自車両が走行している道路の曲率や、エゴレーンＩＤ、先行車両を含む周辺車両との位置関係、前方障害物の有無などが含まれる。道路の勾配や、段差／陥没部の有無などといった、道路形状にかかる外界情報は、現在位置に対応する地図データを参照することによって特定されても良い。また周辺車両の位置や走行速度などは車車間通信によって取得してもよい。さらに、道路工事に伴う車線規制を含む障害物情報は路側機から無線通信により取得しても良い。

ステップＳ１３では自動運転ＥＣＵ２０から短期的な制御計画を取得してステップＳ１４に移る。短期的な制御計画とは例えば現在から３０秒又は１分以内の制御計画を指す。ステップＳ１４では通信状態取得部Ｆ２が、無線通信機１６から現在の通信状態を取得してステップＳ１５に移る。

ステップＳ１５では特定行動検出部Ｆ１が、ステップＳ１１で取得した乗客情報に基づき、特定行動を実施中の乗客がいるか否かを判定する。特定行動を実施している乗客がいない場合にはステップＳ１５を否定判定して本フローを終了する。一方、特定行動を実施している乗客がいる場合には、ステップＳ１６に移る。

ステップＳ１６では現在の通信状態が良好であるか否かを判定する。例えば電波強度が要求レベルＰｒｑ以上である場合に、通信状態は良好であると判定する。また、管制センタ２とのデータ通信のレイテンシが所定の閾値未満であることや、スループットが所定の閾値以上であること、パケットロス率が所定の閾値未満であることなどを条件として、通信状態が良好であると判定しても良い。通信状態が良好である場合とは管制センタ２との通信に、通信途絶や所定時間以上の遅延等といった不具合が生じていない場合に対応する。

通信状態が良好であると判定する条件は適宜変更可能である。また、通信状態が良好ではないと判定することは、管制センタ２との通信に不具合が生じていると判定することに相当する。ここでの不具合には、前述の通り、通信不能な状態に加えて、所定値以上の遅延が生じている状態、パケットロス率が所定値以上である場合、スループットが所定値以下である場合などを含めることができる。ステップＳ１６は、管制センタ２とデータ通信が可能かどうかを判定する処理に置き換えてもよい。

通信状態が良好であると判定された場合にはステップＳ１７に移り、センタ連携部Ｆ４３が対応要求信号を管制センタ２に送信し、管制センタ２からの応答を待機する。その後、管制センタ２から音声データを受信した場合には、車内スピーカ１８をオンにし、管制センタ２から送られてくる音声を車内スピーカ１８から出力する。つまり通信状態が良好である場合、規定メッセージ出力部Ｆ４２は動作しない。このような制御態様は、管制センタ２との通信に不具合が生じていない場合には規定メッセージ出力部Ｆ４２よりもセンタ連携部Ｆ４３を優先的に作動させる構成に相当する。

また、通信状態が良好ではないと判定された場合にはステップＳ１８に移り、臨時対応処理を実行する。臨時対応処理は、管制センタ２との通信に不具合があると判定されている場合に適用されるシーケンスである。臨時対応処理については図１０を用いて説明する。

図１０は臨時制御処理として実行される一連の処理の一例を示すフローチャートである。本実施形態として臨時制御処理はステップＳ２１～Ｓ２６を含む。ステップＳ２１では通信状態予測部Ｆ４１としてのプロセッサ３１が、電波強度マップを参照し、現在位置及び今後の制御計画に応じた復旧予想時間Ｔｒｃを算出し、ステップＳ２２に移る。ステップＳ２２では算出された復旧予想時間Ｔｒｃが所定の待機許容時間Ｔｗ未満であるか否かを判定する。

待機許容時間Ｔｗは、規定メッセージを出力するか、オペレータＯｐに乗客対応を委任するかを切り分けるための閾値である。待機許容時間Ｔｗは、例えば入力アクションに対してレスポンスがない／遅いと人間が感じる時間である遅延知覚時間の想定値に、往復レイテンシの想定値を加えた値に設定されることが好ましい。一般的な遅延知覚時間は２秒～３秒であることを踏まえ、本実施形態では一例として待機許容時間Ｔｗは５秒に設定されている。もちろん待機許容時間Ｔｗの具体的な値は、４秒や、８秒、１０秒などに設定されていても良い。

待機許容時間Ｔｗの長さは、検出されている特定行動の内容に応じて変更されても良い。例えば乗客の転倒が検出されている場合には待機許容時間Ｔｗを３秒や４秒など、相対的に短い時間に設定される。また、検出されている特定行動が不安全行動に該当する場合には、待機許容時間Ｔｗは５秒や６秒とすることができる。検出されている特定行動がマナー違反に相当するものである場合、待機許容時間Ｔｗは相対的に長い８秒や１０秒とすることができる。

ステップＳ２２の判定処理において復旧予想時間Ｔｒｃが待機許容時間Ｔｗ未満である場合にはステップＳ２３に移る。一方、復旧予想時間Ｔｒｃが待機許容時間Ｔｗ以上である場合にはステップＳ２４に移る。

ステップＳ２３ではセンタ連携部Ｆ４３がセンタ連携処理を実施する。センタ連携処理の一例を図１１に示す。センタ連携処理はステップＳ３１～Ｓ３５を含む。ステップＳ３１では、通信状態が復旧したか否かを逐次判定する。通信状態が復旧した場合とは、例えば電波強度が要求レベルＰｒｑ以上となった場合とすることができる。通信状態が復旧したと判定する条件は、通信状態が良好ではない／通信不能と判定する条件の裏返しとなるように設定されうる。

管制センタ２との通信が復旧した（可能となった）と判定した場合にはステップＳ３２に移る。なお、例えば待機許容時間Ｔｗなど、センタ連携処理を開始してから一定時間経過しても管制センタ２との通信が復旧しなかった場合には、例外処理としてステップＳ２５に移り、規定メッセージを出力しても良い。

ステップＳ３２ではセンタ連携部Ｆ４３が、対応要求信号を管制センタ２に送信する。ステップＳ３３では、管制センタ２からの応答の受信を待機する。管制センタ２からの応答は、実体的には、アナウンス用の音声データを指す。管制センタ２からの応答は、オペレータＯｐからの応答と読み替えることができる。オペレータＯｐからの応答を受信した場合には、ステップＳ３４に移る。ステップＳ３４では車内スピーカ１８をオンにし、管制センタ２から送られてくるオペレータＯｐの音声メッセージを順に音声出力する。

上記構成は、復旧予想時間Ｔｒｃの経過を待たずに、通信状態が回復次第速やかに対応要求信号を送信する構成に相当する。当該構成によれば、より迅速にオペレータＯｐによるアナウンスが実施可能となる。もちろん、他の態様としては、復旧予想時間Ｔｒｃが経過することを待ってから、対応要求信号を送信しても良い。

なお、ステップＳ３１～Ｓ３２では電波強度を定期的に観測し、電波強度が要求レベルＰｒｑとなったことを確認できてから対応要求信号を送信するパターンについて述べたが、センタ連携処理の内容はこれに限定されない。例えばステップＳ３１では対応要求信号を定期的に送信するとともに、対応要求信号を受信したことを示す応答信号（いわゆるＡｃｋ）を受信できた場合に、通信状態が回復したと判定してもよい。

ただし、臨時対応処理は通信状態が不安定な場合に実行されるため、対応要求信号を送信後に再び通信状態が悪化し、オペレータＯｐからの応答を受信できなくなってしまうケースも考えられる。そのような事情から、対応要求信号を送信してから所定時間、例えば待機許容時間Ｔｗ経過してもオペレータＯｐからの応答が得られなかった場合にはステップＳ３５に移り、規定メッセージを出力しても良い。加えて、応答部Ｆ４は、特定行動の検出から待機許容時間Ｔｗ経過しても管制センタ２からの音声データを受信できなかったことを条件としてステップＳ３５、すなわち行動内容に対応する規定メッセージの音声出力を実行してもよい。

図１０に戻り、ステップＳ２４以降の説明を続ける。ステップＳ２４以降は、前述の通り、電波強度マップに基づいて定まる復旧予想時間Ｔｒｃが待機許容時間Ｔｗ以上である場合の処理シーケンスである。ステップＳ２４では復旧予想時間Ｔｒｃが所定のフォールバック閾値Ｔｆｂ未満であるか否かを判定する。ここで使用されるフォールバック閾値Ｔｆｂは、自動運転ＥＣＵ２０にフォールバックモードに切り替えるための閾値、換言すればより安全性の高い制御条件で自動運転を実施させるための閾値である。フォールバック閾値Ｔｆｂは例えば３０秒に設定されている。もちろんフォールバック閾値Ｔｆｂは２０秒や４５秒などであってもよく、具体的な値は適宜変更可能である。

復旧予想時間Ｔｒｃがフォールバック閾値Ｔｆｂ未満である場合にはステップＳ２５を実行する。一方、復旧予想時間Ｔｒｃがフォールバック閾値Ｔｆｂ以上である場合にはステップＳ２６に移る。

ステップＳ２５では規定メッセージ出力部Ｆ４２が、規定メッセージ出力処理を実行する。すなわち、乗客対応テーブルを参照し、検出された特定行動に対応する規定のメッセージを音声出力する。例えば検出された特定駆動が吊り革を持たずに立っていることである場合には、「転倒防止のため、吊り革等にお掴まりください」などといった音声メッセージを出力する。

ステップＳ２６では応答部Ｆ４が自動運転ＥＣＵ２０に対してフォールバックモードに移行するように要求する制御信号であるフォールバック指示信号を出力する。すなわち、自動運転の計画を作成する際の上限速度、加減速度の許容値、及び角速度の許容値を所定量引き下げるように要求する信号を出力する。これにより、より安全性が高い制御態様で、運行が継続されることとなり、ひいては乗客が転倒するリスクを低減可能となる。

なお、ステップＳ２６は、検出された特定行動が不安全行動に該当する場合のみ、つまり不安全行動が検出されている場合のみ実施されても良い。また、ステップＳ２６ではフォールバックモードへの移行指示信号出力と並列的に、規定メッセージ出力処理を実施しても良い。例えば、ステップＳ２６ａとして、規定メッセージを音声出力してもよい。

＜管理サーバ２３の作動について＞
ここでは図１２に示すフローチャートを用いて管理サーバ２３の作動について説明する。便宜上、図１２に示す一連の処理をセンタ側処理と称する。図１２に示すフローチャートは、自動運転バス１の運行時間／営業時間に該当する場合など、所定の実行条件が充足されている間、所定の応答周期で繰り返し実行されうる。応答周期としては１００ミリ秒や２００ミリ秒などを採用することができる。ここでは一例としてセンタ側処理は、ステップＳ４１～Ｓ４６を備える。なお、センタ側処理を構成するステップ数や実行順番は適宜変更可能である。各ステップはサーバプロセッサ２３１によって実施される。

まずステップＳ４１では自動運転バス１から対応要求信号を受信したか否かを判定する。対応要求信号を受信していない場合にはステップＳ４１を否定判定して本フローを終了する。一方、対応要求信号を受信した場合にはステップＳ４２を実行する。なお、センタ側処理は対応要求信号を受信したことをトリガとして開始されても良い。その場合には、ステップＳ４１は省略され、ステップＳ４２から実行されれば良い。

ステップＳ４２では、スピーカ２２３から所定の通知音を出力するとともに、ディスプレイ２２１に自動運転バス１の車内にて特定行動を実施している乗客が検出されたことを示す通知画像を表示する。通知画像は、図８に例示するような概要情報を含む画像であってもよいし、車内映像そのものであっても良い。また、通知画像は、車内に異常が検出されたことのみを示す画像であっても良い。

ステップＳ４３ではオペレータＯｐによる音声入力が開始されたか否かを判定する。例えばマイク２２２がオンに設定された場合に、オペレータＯｐの音声入力が開始されたと判定する。オペレータＯｐによる音声入力が開始された場合にはステップＳ４４に移る。ステップＳ４４ではオペレータＯｐが発話した音声を所定のデータフォーマットに変換してなる音声データを自動運転バス１に送信する。その際、管理サーバ２３は、オペレータＯｐの発話音声を車内スピーカ１８から出力させるように指示する制御信号も送信する。

一方、所定時間待機してもオペレータＯｐによる音声入力が開始されなかった場合にはステップＳ４５に移る。ステップＳ４５では、入力装置２２４から入力される操作信号に基づき、今回検出された特定行動に関しては応答が不要であることが選択されたか否かを判定する。今回検出された特定行動に関しては応答が不要であることが選択された場合にはステップＳ４４にて、応答不要であることを示す指示信号を送信する。

なお、今回検出された特定行動に関しては応答不要であることの指示入力も、音声入力も、どちらも行われなかった場合には、ステップＳ４６の例外処理を実施してもよい。例外処理は規定メッセージの出力指示としても良いし、再度オペレータＯｐに対応要求が到着していることを通知する処理としてもよい。

＜上記構成の効果等について＞
以上の車内監視ＥＣＵ３０は、通信状態が良好である状況において、乗客の特定行動の実施を検出した場合には、センタ連携処理を実行する。すなわち、車内監視ＥＣＵ３０から管制センタ２に向けて対応要求信号を送信し、管制センタ２が備える管理サーバ２３が、車内で特定行動が検出されたことをオペレータＯｐに通知する。そしてオペレータＯｐの発話／指示に基づく音声データを、車内スピーカ１８から出力させる。このように通信状態が良好である状況において乗客の特定行動を検出した場合、オペレータＯｐが車内カメラ１５１の映像を確認した上で、注意喚起等のアナウンスを実施可能に構成されている。故に、運転士等の乗務員が車内にいなくとも、乗客の状態に応じたアナウンスを実施することが可能となる。つまり、乗客の特定行動に対してシステムが無反応となるおそれを低減できる。

また、管制センタ２との通信に不具合が生じている状況下において、乗客の特定行動の実施を検出した場合には、通信状況が所望の要求レベルまで回復するまでの予測時間である復旧予想時間Ｔｒｃの長さに応じて、システム応答を変更する。すなわち、復旧予想時間Ｔｒｃが比較的短い場合には、規定メッセージの出力をせずに、通常時と同様にセンタ連携処理を実行する。一方、復旧予想時間Ｔｒｃが比較的長い場合には、行動内容に対応する規定メッセージを出力する。

上記構成によれば、管制センタ２との通信に不具合が生じている状況下においても、比較的に短い時間で通信状況の改善が予見される場合には、乗客の行動に対してオペレータＯｐが対応することとなる。オペレータＯｐのアナウンスと、定型的／機械的な音声メッセージとでは、乗客に与える心証は異なる。定型的／機械的な音声メッセージよりも、オペレータＯｐのアナウンスのほうが、乗客がアナウンスに従う可能性が高いことが期待される。また、オペレータＯｐの音声を出力する構成によれば、乗客に、車内の様子が見守られていることを意識付ける効果が期待できる。すなわち、オペレータＯｐが原則的にアナウンスを実施する構成によれば、規定メッセージしか出力しない構成よりも、乗客に安心感を与えることができる。また、オペレータＯｐが車内を見ていることを乗客に意識付けることにより、マナー違反の抑制や、犯罪の抑止効果も期待できる。

また、仮に規定メッセージ出力部Ｆ４２を備えない構成においては、通信に不具合が生じると通信が復旧するまで乗客の不安全行動等に対して注意を行うことができない。そのような課題に対し、本実施形態の構成によれば規定メッセージ出力部Ｆ４２を備えることにより、復旧予想時間Ｔｒｃが所定値以上である場合には規定メッセージが出力される。規定メッセージを出力することにより、通信に不具合が生じている場合であっても、乗客の挙動又は状態に応じた報知をリアルタイムに実施可能となる。

また、上記の構成によれば、車内監視ＥＣＵ３０は電波強度マップに基づき、通信に不具合が生じた状況が一定時間以上継続することが予見される場合には、車速や加減速度等を抑制したフォールバックモードで運行を継続する。車速などが低減されることにより、安全性や乗り心地を高めることができる。その結果、管制センタ２がリアルタイムに自動運転バス１の内部に監視できない状況下において乗客の転倒が生じる恐れを低減できる。また、管制センタ２がリアルタイムに自動運転バス１の外界に監視できない状況下において他の移動体との衝突が生じる恐れも低減できる。

ところで、特定行動の検出は、機械学習によって構築された識別モデルを用いて実施される。そのため、特定行動検出部Ｆ１は、乗客による特定行動の実施を誤検出する可能性は０ではない。上記構成では、通信状態が良好である場合には原則、オペレータＯｐが車内カメラ１５１の映像を確認した上で、注意喚起を実施する。よって、誤検出に基づく不要な注意喚起が実施される恐れを低減できる。

また、上記の実施形態ではオペレータＯｐがアナウンス等は不要であると判断した場合には、特段の処置が不要であることを入力可能に構成されている。実際に乗客が吊り革等を持たずに立っている状態であっても、注意喚起するほどのシーンではない場合や、やむを得ないケースであることもありうる。そのような事情に対し、オペレータＯｐが車内カメラ１５１の映像を確認し、注意喚起の要否を判断可能な構成によれば、不要な注意喚起が実施される恐れを低減できる。またその結果として、乗客に煩わしさを与えてしまう恐れを低減できる。

以上、本開示の実施形態を説明したが、本開示は上述の実施形態に限定されるものではなく、以降で述べる種々の補足や変形例も本開示の技術的範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施することができる。例えば下記の種々の補足や変形例などは、技術的な矛盾が生じない範囲において適宜組み合わせて実施することができる。なお、以上で述べた部材と同一の機能を有する部材については、同一の符号を付し、その説明を省略することがある。また、構成の一部のみに言及している場合、他の部分については上記説明を適用することができる。

＜規定メッセージ出力処理の補足＞
規定メッセージは、通信に不具合が生じている間、一定間隔で繰り返し出力されうる。しかしながら、例えば３０秒など一定時間以上、同じ内容を報知し続けても、車室内状況が変わらない場合、それ以上、同じメッセージを繰り返し出力しても効果が得られないことが想定される。また、同じメッセージを出力し続けると、乗客に煩わしさや不快感を与えてしまう恐れがある。

そのような事情から、規定メッセージを所定回数／所定時間以上報知しても、乗客の状態が変わらない場合には、規定メッセージの繰り返し出力を停止することが好ましい。図１３は、そのような規定メッセージの出力にかかる処理の具体的なシーケンスの一例を示すフローチャートである。

図１３に示すフローチャートは、例えばステップＳ２５やＳ２６ａ、ステップＳ３５として実行されうる。当該応答部Ｆ４は、復旧予想時間Ｔｒｃ等を鑑みて規定メッセージを出力することを決定した場合、検出されている特定行動の内容に対応するメッセージを音声出力する（ステップＳ５１）。応答部Ｆ４は、メッセージの出力を行うと、その出力回数を１つインクリメントする。また、規定メッセージ出力処理を開始してからの経過時間を計測し始める（ステップＳ５２）。

そして、応答部Ｆ４は、規定メッセージ出力処理を開始してからの経過時間が３０秒以上となっている場合には（ステップＳ５３ ＹＥＳ）、規定メッセージの繰り返し出力を停止して本フローを終了する。また、応答部Ｆ４は、特定行動が解消された場合にも（ステップＳ５４ ＮＯ）規定メッセージの繰り返し出力を停止する。一方、規定メッセージ出力処理を開始してからの経過時間が３０秒未満であって、且つ、また特定行動が継続している場合には（ステップＳ５４ ＹＥＳ）、ステップＳ５１に戻り、再び規定メッセージを出力する。

上記構成によれば、同じメッセージが繰り返し出力され続けることで乗客に不快感を与えてしまう恐れを低減できる。なお、メッセージの繰り返し出力を打ち切る閾値としての３０秒は一例であって２０秒や４０秒などであってもよい。規定メッセージの繰り返しを停止するための回数は、２回や、３回、４回とすることができる。

＜対象者の選定方法の補足＞
車内監視ＥＣＵ３０は、図１４に示すフローに従って、不安全行動に対する注意喚起対象とする乗客を設定しても良い。すなわち、リスク評価部Ｆ１２が乗客ごとの転倒リスクＲｆを、その乗車姿勢や属性情報に基づき算出し（ステップＳ６１）、応答部Ｆ４は、算出された転倒リスクＲｆが最も高い乗客を、注意喚起の対象者に設定する（ステップＳ６２）。そして、応答部Ｆ４は、前ステップで設定された対象者に対して、現在の管制センタ２との通信状態に応じた態様で注意喚起を実施する（ステップＳ６３）。すなわち、通信状態が良好である場合にはセンタ連携処理を実施する一方、通信に不具合が生じている場合には規定メッセージを出力する。

上記の構成によれば、転倒リスクＲｆが高い乗客に対して優先的に注意喚起を実施することが可能となる。注意喚起により対象者が手すりを把持するなど、車内状況が変化した場合には、乗客ごとの転倒リスクＲｆを再計算し、まだ転倒リスクＲｆが所定値以上である別の乗客に対して注意喚起を実施しても良い。

また、応答部Ｆ４は、対象者の転倒リスクに応じて応答処理の内容を変更するように構成されていてもよい。例えば転倒リスクが所定値以上である場合には、復旧予想時間Ｔｒｃがフォールバック閾値Ｔｆｂ未満であっても、フォールバック指示信号を出力し、自動運転ＥＣＵ２０をフォールバックモードで動作させても良い。当該構成によれば、転倒リスクが高い場合には慎重制御が採用されることとなり、乗客が転倒する恐れを低減可能となる。なお、応答部Ｆ４は、転倒リスクが高いほどフォールバック閾値Ｔｆｂとして小さい値を適用するように構成されていても良い。

また、転倒リスクの高さに応じて、規定メッセージの繰り返し出力回数を変更しても良い。例えば、転倒リスクが所定の閾値以上である場合には繰り返し出力回数を３回とする一方、転倒リスクが閾値未満である場合には繰り返し出力回数を１回又は２回としてもよい。転倒リスクが低い場合には繰り返し回数を減らすことで乗客に不快感を与える恐れを低減可能となる。

＜フォールバックモードから通常モードへの復帰方法について＞
ここでは自動運転ＥＣＵ２０をフォールバックモードから通常モードに復帰させるための制御の一例について図１５を用いて説明する。便宜上、図１５に示すフローチャートを通常モード復帰判定処理とも称する。通常モード復帰判定処理は一例としてステップＳ７１～Ｓ７４を含む。本フローは自動運転ＥＣＵ２０がフォールバックモードで動作している間、所定の判定周期で繰り返し実行されうる。判定周期は５００ミリ秒や１秒、２秒などとすることができる。

まずステップＳ７１では特定行動検出部Ｆ１が、車内センサ１５からの入力信号に基づき、乗客による不安全行動が継続しているか否かを判定する。不安全行動が継続している場合にはステップＳ７２に移る。一方、不安全行動が終了している場合には、ステップＳ７４に移る。不安全行動が終了している場合とは、例えば、対象者が吊り革等を把持したり、着席したりした場合を指す。ステップＳ７２では管制センタ２との通信にまだ不具合が生じているか否かを判定する。まだ通信状態が回復していない場合にはステップＳ７３に移る。一方、もう通信状態が回復している場合にはステップＳ７４を実行する。

ステップＳ７３ではフォールバックモードを継続するように指示する信号を自動運転ＥＣＵ２０に出力して本フローを終了する。また、ステップＳ７４では通常モードに復帰するように指示する復帰指示信号を自動運転ＥＣＵ２０に出力して本フローを終了する。

以上の処理により、乗客の不安全行動が終了している場合や通信状態が要求レベルまで回復している場合には自動運転モードは通常モードに復帰する。すなわち、走行速度の上限値や、許容されるべき加減速度及びヨーレートにかかる制限が緩和される。

＜通常モードとフォールバックモードの補足＞
自動運転ＥＣＵ２０の通常モードは、法定速度に準ずる数値を車速の上限値とする走行する制御計画を作成する動作モードとする一方、フォールバックモードは法定速度よりも所定量小さい値を車速の上限値として制御計画を作成する動作モードであっても良い。

通常モードは、人間の運転士が路線バスの運転をする際と同様の加減速度を目標値として制御計画を作成する動作モードとする一方、フォールバックモードは、上記よりも所定量小さい下限速度で走行制御を行う動作モードであっても良い。人間の運転士が路線バスを運転する際の加減速度は、自動運転バス１と同じルートを人間の運転士が運転した場合の履歴データを元に決定されれば良い。また、複数のバス運転士の運転履歴データを統計的に解析することで、平均的な加速度及び減速度を算出し、これを通常モード時の加減速度の上限値として定めても良い。角速度についても同様である。例えば、人間の運転士が、交差点を右左折する際や、車線変更を行う際に生じるヨーレートを元に、通常モード時の制御上の許容値を設定しても良い。

＜管制センタ２の構成の変形例について＞
車内監視ＥＣＵ３０だけでなく、管理サーバ２３もまた、車内監視ＥＣＵ３０から提供される車内映像をもとに特定行動を実施している乗客の有無を判定するように構成されていても良い。上記構成によれば、通信状態が良好な状態において、車内監視ＥＣＵ３０が見落とした不安全行動等について、オペレータＯｐが注意喚起を実施可能となる。また、耐環境性が問われる車内監視ＥＣＵ３０よりも、管理サーバ２３のほうが、演算能力の高いプロセッサを有することが期待できる。上記構成によれば、より演算能力が高いプロセッサによって乗客の状態が判定されるため、特定行動の誤検出／検出漏れの可能性を抑制可能となる。

また、車内監視ＥＣＵ３０からの乗客対応要求、すなわち対応要求信号に対して、以上ではオペレータＯｐとしての人間が対応する構成について例示したが、これに限らない。例えば応答装置が、対応要求信号に対して自動応答するように構成されていても良い。すなわち、管制センタ２において乗客対応の内容を決定／指示する存在は、人間ではなく、応答装置であってもよい。応答装置は、例えばニューラルネットワークを主体として構築された学習済みの人工知能モデルを用いて、車内カメラ１５１の映像から乗客の状態を特定し、適正な応答を出力する装置とすることができる。このような応答装置もまた、一種のオペレータと解することができる。

＜復旧予想時間の算出材料についての補足＞
車内監視ＥＣＵ３０は、電波強度マップの代わりに、又は、電波強度マップと合わせて、受信品質マップを用いて復旧予想時間Ｔｒｃを算出しても良い。受信品質マップは、地点ごとの受信品質、例えばＲＳＲＱを示すデータである。例えば応答部Ｆ４は、電波強度と受信品質が両方とも所定の要求レベル以上となるまでにかかる時間を復旧予想時間Ｔｒｃとして算出しても良い。電波強度マップや受信品質マップが通信品質マップデータに相当する。また、通信品質マップデータは、地点ごとの上り／下りスループットや往復レイテンシなどを示すデータであってもよい。通信品質マップデータは電波マップと呼ぶこともできる。

＜検知対象事象とその応答処理のバリエーションについて＞
車内監視ＥＣＵ３０は、乗客の検温を行い、熱が所定値以上であることを検知した場合には、システムが別途手配するバス／タクシー／救急車に乗り換えることを提案しても良い。また、乗客のプライバシーを鑑みて、熱が所定値以上である乗客を検知した場合には、感染症拡大予防の観点又はその他の観点から、空調装置による空気の入れ替えを強めたり、窓を開けたりするなどの処置を自動的に実施してもよい。

また、車内監視ＥＣＵ３０は、乗車人数を特定することにより、定員オーバーや、重量オーバーなどを検出し、管制センタ２に報告するように構成されていても良い。定員オーバーや、重量オーバーなどは、ドアを閉じる前、又は、発進前に判定することが好ましい。管制センタ２又は規定メッセージ出力部Ｆ４２は、定員オーバーが検出された場合、最後に乗車した人物に降車を促す音声メッセージをしてもよい。定員オーバーが検出された場合、管制センタ２は別の車両を手配してもよい。

さらに、車内監視ＥＣＵ３０は荷物の置き忘れを検知し、降車しようとする乗客に向けて注意喚起を行っても良い。また、乗客の顔を画像認識することで乗客としてのユーザを識別するように構成されていても良い。ユーザを特定可能な構成においては、顔画像と紐付けられている名前などのユーザ情報を用いて、挨拶などを実施するように構成されていても良い。また、乗車中にユーザが発作などを起こした場合には、ユーザ情報を用いて家族や指定病院に連絡をとってもよい。

＜システム構成の変形例＞
以上では図２に示すように自動運転ＥＣＵ２０と車内監視ＥＣＵ３０とが別の装置として構成されている態様について述べたがこれに限らない。例えば図１６に示すように自動運転ＥＣＵ２０の機能の一部又は全部は車内監視ＥＣＵ３０が備えていても良い。より具体的には車内監視ＥＣＵ３０が制御計画部Ｇ１及び制御実行部Ｇ２を備えていても良い。

また、図１７に示すように自動運転ＥＣＵ２０が車内監視ＥＣＵ３０に相当する機能部である車内監視部Ｇ３を備えていてもよい。車内監視部Ｇ３は、車内監視ＥＣＵ３０と同様の処理を実行する構成である。車内監視部Ｇ３は、自動運転ＥＣＵ２０以外のＥＣＵ、例えば車載ＨＭＩを制御するＨＭＩ制御ＥＣＵが備えていても良い。図１６及び図１７に示す構成は、自動運転ＥＣＵ２０と車内監視ＥＣＵ３０とを統合した構成に相当する。車内監視ＥＣＵ３０、又は、車内監視部Ｇ３を備える装置が乗客見守り装置に相当する。

＜付言＞
本開示に記載の装置、システム、並びにそれらの手法は、コンピュータプログラムにより具体化された一つ乃至は複数の機能を実行するようにプログラムされたプロセッサを構成する専用コンピュータにより、実現されてもよい。また、本開示に記載の装置及びその手法は、専用ハードウェア論理回路を用いて実現されてもよい。さらに、本開示に記載の装置及びその手法は、コンピュータプログラムを実行するプロセッサと一つ以上のハードウェア論理回路との組み合わせにより構成された一つ以上の専用コンピュータにより、実現されてもよい。例えば車内監視ＥＣＵ３０が備える機能の一部又は全部はハードウェアとして実現されても良い。或る機能をハードウェアとして実現する態様には、１つ又は複数のＩＣなどを用いて実現する態様が含まれる。プロセッサ（演算コア）としては、ＣＰＵや、ＭＰＵ、ＧＰＵ、ＤＦＰ（Data Flow Processor）などを採用可能である。また、車内監視ＥＣＵ３０が備える機能の一部又は全部は、複数種類の演算処理装置を組み合わせて実現されていてもよい。車内監視ＥＣＵ３０が備える機能の一部又は全部は、システムオンチップ（ＳｏＣ：System-on-Chip）や、ＦＰＧＡ、ＡＳＩＣなどを用いて実現されていても良い。ＦＰＧＡはField-Programmable Gate Arrayの略である。ＡＳＩＣは、Application Specific Integrated Circuitの略である。

また、コンピュータプログラムは、コンピュータにより実行されるインストラクションとして、コンピュータ読み取り可能な非遷移有形記録媒体（non- transitory tangible storage medium）に記憶されていてもよい。プログラムの保存媒体としては、ＨＤＤ（Hard-disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ、ＳＤ（Secure Digital）カード等を採用可能である。コンピュータを車内監視ＥＣＵ３０として機能させるためのプログラム、及び、このプログラムを記録した半導体メモリ等の非遷移的実態的記録媒体等の形態も本開示の範囲に含まれる。以上では車内監視ＥＣＵ３０を例にとってその具体的な実現態様の変形例について言及したが、本付言の内容は管理サーバ２３についても適用されうる。

１ 自動運転バス（旅客車両）、２ 管制センタ、１５ 車内センサ、１８ 車内スピーカ、２０ 自動運転ＥＣＵ（コンピュータ）、３０ 車内監視ＥＣＵ（乗客見守り装置）、２２ オペレータ用ＨＭＩ、２３ 管理サーバ、１５１ 車内カメラ、１５２ 車内マイク、２２１ ディスプレイ、２２２ マイク、２２３ スピーカ、２２４ 入力装置、２３１ サーバプロセッサ、Ｆ１ 特定行動検出部、Ｆ１１ 乗客情報取得部、Ｆ１２ リスク評価部、Ｆ２ 通信状態取得部、Ｆ３ 報告処理部、Ｆ４ 応答部、Ｆ４１ 通信状態予測部、Ｆ４２ 規定メッセージ出力部、Ｆ４３ センタ連携部、Ｍ１ 乗客対応テーブル記憶部（報知用データ記憶部）、Ｍ２ 電波強度マップ記憶部（記憶媒体）

Claims (13)

1. 管制センタの管理のもと乗務員が乗車せずに運行可能に構成された旅客車両で使用される、前記管制センタと無線通信可能に構成されている乗客見守り装置であって、
   前記旅客車両に搭載された、車内を撮像するカメラでの映像である車内映像を前記管制センタに送信する報告処理部（Ｆ３）と、
   前記旅客車両に搭載されたセンサからの入力信号に基づいて、乗客が特定行動を実施していることを検出する特定行動検出部（Ｆ１）と、
   前記特定行動の内容に対応する音声メッセージを出力するためのデータが格納された報知用データ記憶部（Ｍ１）と、
   前記特定行動の実施が検出されたことに基づいて、検出された前記特定行動に対応する応答処理を実施する応答部（Ｆ４）と、
   前記旅客車両に搭載された無線通信装置から、前記管制センタとの現在の通信状態を取得する通信状態取得部（Ｆ２）と、を備え、
   前記応答部は、前記応答処理として、
   前記報知用データ記憶部に格納されたデータを用いて前記特定行動に対応する規定メッセージを、前記旅客車両に設置されたスピーカである車内スピーカ（１８）から音声出力することと、
   前記管制センタから前記車内映像に基づいて送信される音声データを取得し、当該音声データに対応する音声を前記車内スピーカから出力を行うことの、少なくとも２種類の処理を選択的、並列的、又は順番に実施可能に構成されており、
   前記応答部は、さらに、
   前記特定行動の実施が検出された際の前記管制センタとの通信状態に基づいて、前記応答処理として実行する内容を変更し、
   前記特定行動の実施が検出された際、前記管制センタとの通信に不具合が生じている場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、前記管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出し、
   前記復旧予想時間が所定の待機許容時間未満である場合には、前記規定メッセージの出力は保留とするとともに前記管制センタからの前記音声データの受信を待機するように構成されている乗客見守り装置。
2. 請求項１に記載の乗客見守り装置であって、
   前記応答部は、前記復旧予想時間が前記待機許容時間以上であることを条件として、前記規定メッセージを出力するように構成されている乗客見守り装置。
3. 請求項１又は２に記載の乗客見守り装置であって、
   前記応答部は、検出された前記特定行動の内容に応じて前記待機許容時間を変更するように構成されている乗客見守り装置。
4. 請求項１に記載の乗客見守り装置であって、
   前記応答部は、
   前記管制センタとの通信が不能であり且つ前記乗客による前記特定行動が継続されている間は、前記規定メッセージを所定間隔で繰り返し出力するように構成されており、
   前記規定メッセージを出力開始から所定時間経過した場合、又は、前記規定メッセージを所定回数出力した場合には、当該規定メッセージの出力を停止するように構成されている乗客見守り装置。
5. 請求項１から４の何れか１項に記載の乗客見守り装置であって、
   前記応答部は、
   前記特定行動の実施が検出された際、前記管制センタとの通信が不能である場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、前記管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出するとともに、
   前記復旧予想時間が所定の制限適用閾値以上である場合には、前記応答処理として、前記管制センタと通信可能な場合よりも走行速度を所定量抑制した制御計画を作成するよう、前記制御計画の作成を実施するコンピュータ（２０）に要求するように構成されている乗客見守り装置。
6. 請求項１から５の何れか１項に記載の乗客見守り装置であって、
   前記応答部は、
   前記特定行動の実施が検出された際、前記管制センタとの通信が不能である場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、前記管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出するとともに、
   前記復旧予想時間が所定の制限適用閾値以上である場合には、前記応答処理として、加速度又は角速度に対する走行制御上の許容値を所定の標準値から所定量下げるよう、制御計画を作成するコンピュータ（２０）に要求するように構成されている乗客見守り装置。
7. 請求項１から４の何れか１項に記載の乗客見守り装置であって、
   前記応答部は、
   前記特定行動の実施が検出された際、前記管制センタとの通信が不能である場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、前記管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出し、
   前記復旧予想時間が所定の制限適用閾値以上である場合には、前記応答処理として、前記管制センタと通信可能な場合よりも前記旅客車両に作用する加速度又は角速度が小さくなるように前記旅客車両の走行制御を行うように構成されている乗客見守り装置。
8. 請求項１から７の何れか１項に記載の乗客見守り装置であって、
   前記特定行動として、転倒、及び、転倒のリスクが高まる所定の不安全行動が登録されており、
   前記不安全行動には、吊り革又は手すりに掴まずに立っていること、移動中の歩行、移動中に立ち上がること、シートベルトを装着していないこと、及び、窓から手／顔を出すことの少なくとも何れか１つが含まれる乗客見守り装置。
9. 請求項１から８の何れか１項に記載の乗客見守り装置であって、
   前記特定行動は、大声での会話、携帯電話での通話、２つ以上の座席を１人で占有すること、座席に寝ること、及び、喫煙の少なくとも何れか１つを含むように設定されている乗客見守り装置。
10. 請求項１から９の何れか１項に記載の乗客見守り装置であって、
    前記特定行動として、転倒のリスクが高まる所定の不安全行動が登録されており
    前記特定行動検出部は、前記不安全行動を実施している乗客の年齢と前記特定行動の内容とを因子として、当該乗客が転倒する可能性の高さを示すパラメータである転倒リスクを算出し、
    前記応答部は、前記管制センタとの通信状態に加えて、前記転倒リスクに応じて前記応答処理の内容を決定するように構成されている乗客見守り装置。
11. 請求項１から１０の何れか１項に記載の乗客見守り装置であって、
    前記特定行動検出部は、乗客の年齢及びハンディキャップの有無の少なくとも何れか１つと、乗客の乗車姿勢と、を因子として、当該乗客が転倒する可能性の高さを示すパラメータである転倒リスクを乗客ごとに算出し、
    前記応答部は、前記転倒リスクが所定値以上の乗客が複数存在する場合には、前記転倒リスクが最も高い乗客を注意喚起の対象に設定するように構成されている乗客見守り装置。
12. 乗務員が乗車せずに運行可能に構成された旅客車両の運行を管理する、少なくとも１つのプロセッサ（２３１）を用いてなる管制センタ（２）と、
    前記旅客車両で使用される、前記管制センタと無線通信可能に構成されている乗客見守り装置（３０）と、を含む運行管理システムであって、
    前記乗客見守り装置は、
    前記旅客車両に搭載された、車内を撮像するカメラでの映像である車内映像を前記管制センタに送信する報告処理部（Ｆ３）と、
    前記旅客車両に搭載されたセンサからの入力信号に基づいて、乗客が特定行動を実施していることを検出する特定行動検出部（Ｆ１）と、
    前記特定行動の内容に対応する音声メッセージを出力するためのデータが格納された報知用データ記憶部（Ｍ１）と、
    前記特定行動の実施が検出されたことに基づいて、検出された前記特定行動に対応する応答処理を実施する応答部（Ｆ４）と、
    前記旅客車両に搭載された無線通信装置から、前記管制センタとの現在の通信状態を取得する通信状態取得部（Ｆ２）と、
    前記特定行動の実施が検出されたことに基づき、前記報知用データ記憶部に格納されたデータを用いて前記特定行動に対応する規定メッセージを、前記旅客車両に設置されたスピーカである車内スピーカ（１８）から音声出力する規定メッセージ出力部（Ｆ４２）と、
    前記特定行動の実施が検出されたことに基づいて、前記特定行動に対する車内アナウンス用の音声データを前記管制センタから取得し、当該音声データに対応する音声を前記車内スピーカから出力するセンタ連携部（Ｆ４３）と、を備え、
    前記管制センタとの通信に不具合が生じていない場合には、前記規定メッセージ出力部よりも前記センタ連携部が優先的に作動し、
    前記管制センタが有する前記プロセッサ（２３１）は、
    前記特定行動の実施が検出されたことに基づいて、オペレータに状況を確認させるための画像をオペレータ用のディスプレイ（２２１）に表示することと、
    マイク（２２２）を介して前記特定行動に対するオペレータの発話音声を取得することと、
    前記オペレータの前記発話音声に対応する音声データを前記乗客見守り装置に送信することと、を実施するように構成されており、
    前記応答部は、
    前記特定行動の実施が検出された際、前記管制センタとの通信に不具合が生じている場合には、所定の記憶媒体（Ｍ２）に保存されている地点ごとの無線通信品質を示す通信品質マップデータをもとに、前記管制センタとの通信品質が所定の要求レベル以上となるまでの時間である復旧予想時間を算出し、
    前記復旧予想時間が所定の待機許容時間未満である場合には、前記規定メッセージの出力は保留とするとともに前記管制センタからの前記音声データの受信を待機するように構成されている運行管理システム。
13. 請求項１２に記載の運行管理システムであって、
    前記乗客見守り装置は、前記特定行動が検出されたことに基づいて、その検出された前記特定行動の概要を示す情報を含む通知信号を前記管制センタに送信し、
    前記プロセッサは、前記通知信号を受信した場合には、当該通知信号に含まれる前記概要を示す概要通知画像を前記ディスプレイに表示するように構成されている運行管理システム。

Images