ティアフォーにおける自動運転車両の運行管理サービスのご紹介

はじめまして、ティアフォーで自動運転のWebプラットフォーム開発を行っている森本です。
今回は、自動運転車に対して走行ルートの指示などを行う運行管理サービスであるFMS（Fleet Management System）についての概要をご紹介します。*1

運行管理サービスとは

まず、運行管理サービスとはどんなものなのかを簡単にご説明します。

実際に車両を運転する際は、どんな経路を通り途中で何をして最終的に目的地に到着するのか、といった経路に関する要素が存在します。

また、タクシーのようなサービスの場合、迎えに来てほしいというお客様に対してどの車両が向かうべきか、という最適配置の要素も存在します。

こうした要素に対し、例えば自動運転車両の向かいたい地点を指定された際、運行すべき経路をWeb側で生成して最も運行効率の良い車両を配車するということが考えられます。

このように、車両の運行に関する情報をWeb側で管理するサービスを運行管理サービスと呼びます。

運行管理において必要な情報

運行管理を行う上では車両の情報が欠かせません。車両の現在地や、運行中なのか停止中なのかといった情報だけでなく、場合によっては運行経路中の信号などのインフラ情報が必要になることもあり得ます。

一方で、例えばタクシーのように人を迎えに行ってから目的地に送り届ける、というモデルを考えると送迎などの情報も存在することになりますが、こういったサービスに関する情報はFMSとは別枠で考えるため、FMSではなくAutowareCallsという別サービスで管理を行なっています（今回は言及しません）。

ステートマシンの作成

FMSでは運行管理を行うためにステートマシンを作成して運行管理を行います。

例えばバスのようなモデルを考えると

・車両が決まったルートを運行しており、停車後一定時間待つと次の目的地に向かって走り出す

となり、これは以下のような状態遷移が考えられます。

f:id:junichi-morimoto:20190401115906p:plain

次にタクシーのようなモデルを考えると

・ユーザーが車両を呼び出し、車両が無人でその場に迎えに行き、ユーザーの乗車後に発進ボタンが押されることで目的地に向かって走り出す

となり、これは以下のような状態遷移が考えられます。

f:id:junichi-morimoto:20190401112335p:plain

このように、それぞれの運行モデル毎に適切なステートマシンの作成が必要となります。

また、実際にはもう少し細かく状態を管理する必要があり、異常系のケアなども必要になってきます。

FMS構成概要

FMSはあくまで運行管理を行うためのWebサービスなので、実際の運用では自動運転OSSであるAutowareやユーザーアプリなどと組み合わせることで一つのサービスとして稼働します。

構成例としては、以下のようなものが考えられます。

 

f:id:junichi-morimoto:20190402162845p:plain

処理の流れは以下のようになります。

  1. AutowareのPublishするトピックメッセージを元に車両情報を随時更新
  2. ユーザーアプリからの配車依頼を受け、車両それぞれについての最適経路を探索し、経路を元に配車する車両を決定する。また、走行が完了するまでその車両に対する配車を不可とする
  3. 配車対象車両のAutowareに対して走行経路をPublishする
  4. Autowareが受け取った経路情報を元に走行し、走行の状態毎にノードの情報を更新
  5. 走行が完了すると配車が可能な状態に戻る

このような状態遷移のためにはAutowareのPublishするトピックメッセージに含まれているステートが必要となりますが、FMSではこのステートを抽象化した上でAWS IoT側にPublishすることで極力Autowareを意識する必要がないようにしています。

動作検証の流れ

上記のような構成で実際に車両に対して経路を送信し、それに従って車両を自動走行させることが可能となりますが、いきなり実機で走行テストを行うのは様々なリスクが考えられます。そこで、Autowareのwfsimというシミュレーション機能とFMSを組み合わせることで事前にシミュレーションを行い、実機での動作検証を安全に行うことができます。

wfsimを用いたシミュレーション

以下は、タクシーのモデルについてwfsimを使ってシミュレーションした際の映像です。

最初は経路が与えられていませんが、ユーザーに呼び出されたタイミングで車両の現在地からユーザーのいる地点までの経路を生成してAutowareに送信しています。

次に、Autowareが経路を受け取ったことを確認するとFMSから発信命令を送信して自動で動作を開始します。

ユーザーの待つ地点に到着すると、そこから目的地への経路を新たに生成してAutowareに送信します。一つ目の経路では車両が無人のためFMSから自動で動作命令を送信していましたが、今度はユーザーが乗っているため（動画では判断できませんが）人が発信ボタンを押すことで発信命令が送信され、車が動き出しています。

このように、wfsimを用いると実機なしでのシミュレーションができるというだけでなく、実機では難しい連続可動試験が実施できるといったメリットも存在します。

実機を用いた検証

最後に、実際に実機を使って動作確認を行います。

Autowareの性質上、wfsimでのシミュレーションと実機での動作はほぼ差分がありません。そのため、ここで動作がおかしくなった場合はwfsimでのパラメータと実機検証でのパラメータの差分を確認しつつ問題を整理していくことになります。

以下は実際に実機を用いて試乗を行なった際の動画で、タクシーモデルで人が乗り込んだ後に発信ボタンを押すことで車が発信し、自動運転が開始される様子が映っています。



まとめ

以上がティアフォーの自動運転においてWeb側が担当している役割の一つである運行管理サービスについての概要となります。

自動運転と聞くと車両側の制御のことを想像しがちですが、実際のサービスとして車両が走行する際は、こうしたWeb側の役割も欠かせません。

実際のサービスでは複数台車両をどのように最適に捌くか、予約はどうするか、割り込みはどうするか、といった複雑な問題が様々存在しており、Web側にも多くのチャレンジングな課題が存在しています。

ティアフォーではこのような課題を解決するWebエンジニアを随時募集しておりますので、少しでもご興味をお持ちいただけましたら是非ご連絡ください

*1:運行管理サービスは要件毎に内容が異なってくるため、全ての案件で同一構成になっているわけではありません。