私の選んだテーマは「柏市の交通課題」
柏の葉 IoTハッカソンでは、全部で8つのテーマがあって、その中からテーマを選択し、提案するという流れでした。私の選んだテーマは、「柏市の交通課題」についてです。
簡単に言うと、柏駅前のタクシー待機列がかなり長くなって交通の妨げになっていて、これを解消したい、というものでした。
タクシーショットガンシステム
タクシー待機列の悩みは全国のどこの自治体にもあるようで、既にいくつか待機列の解消に成功した例があります。駅前の近くにそれなりの大きさの駐車場等を設けて、タクシーは列を作らずそこに待機、順番が来たら駅前に移動することで、長い待機列を作らずにタクシーを待機させることができます。
これを、タクシーショットガンシステムと言います。タクシーを待機させておく駐車場のことを、タクシープールと言います。
ショットガンシステムには広い敷地が必要
ショットガンシステムはとてもよく考えられたシステムですが、ひとつネックがあって、広い敷地を用意する必要があるという点です。例えばタクシープールが8台分のスペースしかなければ結局そこにタクシーの列ができてしまうだけで、ある程度の台数を収容できるタクシープールを用意する必要があります。
「分散型タクシープール」のご提案
「柏市の交通課題」は柏市土木部交通政策課さんの出されたテーマだったのですが、柏駅付近にはタクシープールを設置できる環境がなかなか用意できないようで、そこで、タクシープールを一箇所ではなく、複数箇所に分散し、広い敷地を用意することなくタクシープールを運用することはできないか?というご提案をされていました。「分散型タクシープール」を、LoRaWANを用いて運用することはできないだろうか?ということですね。
分散型タクシープールが運用できれば、敷地面の環境に左右されずにショットガンシステムを運用できます。
具体的なテーマで考えやすそうだったので、私はこのテーマを選ぶことにしました。
私の提案(アイディア)
ここまでがテーマの概要で、ここからが私の提案内容です。まず、分散型タクシープールの問題点を考えました。
分散型タクシープールの問題点
普通のタクシープールでは出てこない問題が、分散型タクシープールにはあります。
- 「プールへの入庫順」が滅茶苦茶になるので、順番がわからなくなる。
- 分散したプールは小規模になるので、空き状況がわからないと、いつまでもプールに車を停められない。
- 駅前に向かうタイミングがわかりにくいので、混乱が起きやすい
- あちこちの分散プールから車両がやってくるので、プールを経由しないで駅前に直接向かう「違反車両」を見分けにくい。
- タクシープールからの距離差により、駅前に安定した車両供給ができないかもしれない
ざっくりですが、こんなところでしょうか。逆に言えば、これらの問題をクリアできれば、分散型タクシープールを運用することができる、ということになります。
問題解決①:入庫順を正しくまとめる
タクシープールが複数になってしまったからこそ出てくる問題です。複数箇所それぞれ別々に順番を決めたところで、駅前に車両を向かわせるタイミングは見えてきません。なので、順番は「全てのタクシープール」の合算で決める必要があります。
具体的には、タクシープールに入庫した時、「どの車両」が「何時何分何秒」にタクシープールへ入庫したのか、というデータを取ることができれば、タクシープールの場所に関係なく、全部まとめた順番リストを作ることが可能です。
近傍型ICを車両に搭載し、タクシープールの出入口にICリーダー、LoRaWANデバイス、制御用マイコンを設置しておけば、上記のデータを取得することができます。
タクシープールに入ったらICが反応し、ICのID番号がLoRaWANデバイスで送信される、という流れです。時刻情報は、LoRaWANデバイスのデータをMQTTで受け取る時のJSONに時刻情報が入ってるので、それを使用します。
問題解決②:プールの空き状況を知る
どこのタクシープールが空いているのかわからないと、いつまでも車を停められません。なので、各タクシープールに今何台駐車しているのか、という情報を知る必要があります。
これはとても簡単です。LoRaWANのデータを受け取る時のJSONに、LoRaWANデバイスのIDのような値が入っています。どこのタクシープールにどのデバイスを設置したのかをデータベースに登録しておけば、デバイスのIDでデータベース検索すれば、「このデータはどこのタクシープールから来たデータなのか」がすぐにわかります。
問題解決③:駅前に向かうタイミングを決める
現在多くの自治体で運用されているショットガンシステムですが、タクシープールから駅前に向かうタイミングは、「駅前の様子をモニターに映しておいて、運転手の判断でプールから出庫」という感じのところもあるそうです。
分散型タクシープールではこのやり方だと混乱が起きます。タクシープールがひとつしかないからこそできるやり方です。
なので私の提案では、呼出もプログラムに自動でやってもらうことにしました。呼出方法は、車両にもLoRaWANデバイスを設置しておいて、LEDやブザー、小型モニタなどで知らせるか、タクシープールそれぞれに大きめのモニターを設置して、ナンバープレートなどを表示して呼び出すか、など、色々考えられます。
問題解決④:「違反車両」の検知
タクシープールでみんな順番を待っているのに、ズルして直接駅前にいく車両を黙認しては、制度を作る意味がありません。
これに関しては、駅前にもLoRaWANデバイスやICリーダーを設置することで、解決できます。車両搭載のIC番号をデータベースに参照し、「タクシープールを経由した車両かどうか」を判定すればOKです。侵入防止バーなどは設置しないので、その場ではどうにもなりませんが、後日ペナルティを出すなりすることができます。
問題解決⑤:安定した車両供給
タクシープールを分散すると、プールごとに駅までの距離差が発生します。交通状態だとか色々な要素が絡むので、駅前に安定して車両を供給するという点では少し不安定になりがちです。また、距離差によって順番が前後してしまったりして、「あそこの駐車場は遠いから嫌だなぁ」なんてことになれば、駐車場ごとに人気・不人気が出てしまい、運用に支障をきたします。
そこで、タクシープールから駅前に直接向かうのではなく、駅近くに一箇所「メインプール」というのを作り、その他のタクシープールを「サブプール」としました。タクシーは、次のような経路を通ることになります。
サブプール→メインプール→駅前
一度メインプールに集まってもらうので、これにより距離差による不安定さを解消することができます。
情報の可視化
運用状態を見てわかるようにするために、ウイングアーク1stさんのMotionBoardを利用させていただくことにしました。
機械やプログラムで処理すると、どうしても状態を把握しにくくなるので、「見える化」はとても大事なポイントとなります。
詳しいことは、3ページ目で紹介しています。