2020/08/25 実社会でのIoT活用例 ～バス輸送の効率化とサービス向上のために～
今回は、EurotechのIoT技術が公共バス事業に対してどのように貢献できるのか考えてみたいと思います。
乗客目線での問題提起
今日、多くの人がスマートフォンでバスの乗車料金を支払っていますが、一方でプリペイド式の電子マネーカード（SUICA/PASMO等）を使っている人も少なくありません。
そうした人たちは電子マネーカードにどのくらいの残金があるかあまり把握しておらず、残金が不足していたとしてもバス車内では現金でしかチャージができないので、財布に現金が入っていなければ、たとえ急いでいてもバスに乗ることはできません。
せめてバス停でカード残金の確認だけでもできれば、バスが来るのを待っている間に近くのATMで現金を引き出すことができるのではないでしょうか。
ある女性がバス停でバスを待っています。到着時刻を５分過ぎていますがバスはまだ来ません。彼女は時間に余裕がないため、タクシーを呼び止めることにしました。そしてタクシーの席に座った瞬間、ミラー越しに後部からバスが近づいて来るのが見えました。もし彼女がもう少し早くそのバスの走行地点と到着時間を知ることができていたとしたら、どうだったでしょうか。
ある女性がバス停でバスを待っています。到着時刻を10分過ぎていますがバスはまだ来ません。実はバス停から約1 km手前の地点で交通事故が発生したのですが、彼女にはそれを知る術がありません。彼女はあとどのくらい待つことになるのでしょうか。
他にも、臨時の休日ダイヤであることに気づかないままずっとバスを待ち続けるなど、多くの例が考えられます。
誰もが一度はこのような経験をしたことがあるのではないでしょうか。
運行者目線での問題提起
運行者としての主たる目標は、運行効率を向上させてコストを削減し、迅速かつ正確なタイムサービスを提供することです。
しかし、そうした目標に対して実際の状況では不十分な側面がたくさんあります。例えば、異なる路線を走るバスが同じバス停に停車するケースです。運転手がバス停に並んで待っている人たちを見ても、その人たちがそのバスを待っているのか、あるいは別の路線のバスを待っているのかを的確に把握する方法はありません。結局、運転手はどのバス停でも一旦停車し、ドアを開け、ドアを閉め、再び発進をすることになります。言うまでもなくこれは時間とガソリンの無駄です。
また、走行中の経路上で交通事故が発生し、停止または渋滞を余儀なくされた場合、そのバスの運転手から運行会社へと連絡することはできますが、同じルートを走る後続のバスへとリアルタイムで情報を伝える方法はありません。事故現場より先のバス停で待っている人たちに対しても同様です。
IoTでサービス向上へ
では、EurotechのEveryware IoTを活用した具体例を見ていきましょう。
バス停とバス車両の双方にインテリジェントセンサーとゲートウェイを設置し、クラウドへと接続します。
太陽光発電を利用したインテリジェントバス停と、スマートフォン用アプリの活用例
- 運行中のバスのバス停への到着時刻をライブ配信
- 各バスのルート情報
- バス座席の空き状況をライブ表示（座席予約も可）
- プリペイドカード（SUICA/PASMO等）の残金チェック
- 交通事故などによる停車や渋滞での遅延等、緊急情報の表示
運転手用インテリジェントディスプレイ
- 運転中のバスを待つ乗客のリアルタイム表示（異なる路線を走るバスが同一のバス停に停車する場合）
- 交通事故などによる通行止めあるいは渋滞などの緊急情報、再ルーティングの表示
予兆メンテナンス
IoTの実装により、バスの車両からデータが収集され、予測メンテナンスが可能になります。車両に搭載された各種センサーからリアルタイムの走行速度、走行距離、空気圧、燃料残量、燃料使用量などのデータがリモートで送信され、メンテナンススケジュールに基づく作業時間の算出をより正確に求めることができます。また、トラブル発生時にはバスのステータスレポートを送ることもできます。それぞれのデータはローカル（ドライバーのコントロールパネル）に表示されると同時に、EurotechのEveryware Cloud（EC）に送信されます。
Eurotechの Everyware Software Framework（ESF）及び Everyware Cloud（EC）は、各センサーのステータスに依存することなく、他の時間情報の追加についても簡単にプログラムができます。例えばタイマーを追加して、バスのメンテナンス対象部品を1,000営業時間毎に交換するようメンテナンスチームへ通知したい時、たとえプログラミングスキルがなくても 、ESFが持つドラッグアンドドロップ型の開発ツールで容易に設定ができます。さらにオプションのWebアプリケーションをECに接続すれば、リモートで簡単にアップデートすることも可能です。
こうしたカウンターは、実際の部品ごとの条件や状態によって調整が可能です。例として、バスの製造メーカーが1,000時間の営業時間毎にある部品を交換することを推奨しているにも関わらず、経験上では800時間後にその部品のパフォーマンスが大幅に低下する可能性があると示されたことがありました。そうした場合でもカウンターをすぐに修正し、ECを通じて全ての車両にESFの最新バージョンを一度に展開できるため、時間と費用の両方を節約できます。
メンテナンスチームのリーダーは、ECを経由しリモートでリアルタイムデータにアクセスでき、スペアパーツの注文や現場に派遣するエンジニアの選定、チームメンバーのシフト編成ができます。
Eurotech が提供するビルトイン型のIoTデバイス管理 「Everyware IoT」では、バス車両をリモート管理できるほか、デバイスマネジメントにより、下記のようないくつかのメンテナンスタスクをリモートで実行できます。
- 路線の一部に道路工事が予定されている際のルート変更
- 自然災害等の特別な事情による運行ダイヤの変更
このようなルートまたは時刻表の変更情報は、デバイスプロビジョニングを介して、対象路線のすべてのバス及びバス停に物理的にアクセスすることなく配信できます。
デバイスプロビジョニング
デバイスプロビジョニングでは、デバイスマネージャーがデバイスに直接アクセスし、プロビジョニングパラメーターでデバイスを構成し、プロビジョニングモードに設定します。これによってデバイスがフィールドに展開できるようになります。オペレーターはハードウェアをフィールドに設置し、必要に応じてネットワーク設定を変更して、デバイスとEveryware Cloud間を接続できるようにします。デバイスマネージャーは、プロビジョニング対象デバイスに対するプロビジョニング要求をEveryware Cloudに作成します。デバイスがプロビジョニングプロセスを始めるにはこのプロビジョニング要求が必要となり、接続が成功するとデバイスはプロビジョニングフロー開始のメッセージをEveryware Cloudのプラットフォームに送信します。
プラットフォームは、デバイスから受信したメッセージを検証し、有効であれば新しいコンフィギュレーションとアプリケーションでデバイスに応答します。すべてのコンフィギュレーションが受信されインストールされると、デバイスはプロビジョニングブローカーから切断され、デバイスを配下に置くアカウントブローカーに再接続されます。
次の図は、デバイスのプロビジョニングフローです。
Everyware Cloudアカウント管理者が、自身のアカウントでプロビジョニング要求を作成し、プロビジョニングするデバイスのプロビジョニング接続用クライアントID、ユーザー名、パスワードを設定します。
デバイスが有効になり、クライアントID、ユーザー名、パスワードを使ってプロビジョニングブローカーへ接続します。もしプロビジョニング要求のクライアントIDが作成されていない場合は、デバイスは接続できません。
デバイスがブローカーにメッセージを発行します。ブローカーは、プロビジョニング要求のステータスと、デバイスによって発行された値をチェックします。有効であればプロビジョニング処理が開始されます。
プロビジョニングブローカーがコンフィギュレーションとアプリケーションを取得し、デバイスへと送り返します。成功すればプロビジョニング要求は完了です。
デバイスは新しいコンフィギュレーションとアプリケーションをインストールします。そしてプロビジョニングブローカーから切断され、プロビジョニング要求で受信した値を使い、そのデバイスを配下に置くアカウントブローカーへ再接続します。
プロビジョニングプロセスは、目的による役割の分離ができるように設計されています。
プロビジョニングプロセス用にデバイスを設定するオペレーターと、フィールドにデバイスを展開するオペレーターを区別することができます。このアプローチは、オペレーターの各グループがそれぞれのタスクを実行するために必要な情報へと正確にアクセスできるようになっており、セキュリティ面でも有効です。一連のプロセスを自動化することにより、セキュリティ及びロジスティクスはさらに強化されます。
