はじめに
newmoでエンジニアをしているzukkyです。
newmoグループのタクシー車両には、乗務員さん向けの車載端末が設置されています。この端末は、開発チーム内では TDA(Taxi Driver App)と呼ばれており、乗務員さんはTDAを使って配車リクエストを受け、乗客を迎えに行きます。
このTDAでは、タクシーメーターの状態(空車・実車・迎車など)を取得する必要があります。取得した情報は、配車室システムから無線配車を行うときなどに、その車両が配車を受けられる状態かどうかを判断するために使われます。
現在は、タクシーメーターとTDAをBluetoothで接続し、メーターの状態をTDAで取得してバックエンドに送信しています。この一連の仕組みを、社内ではメーター連携と呼んでいます。
メーター連携の課題
私はTDAのAndroidアプリエンジニアとしてこのメーター連携の開発に関わることが多く、次のような課題を感じています。

1. メーターの種類とBluetooth送信機の組み合わせが車両ごと異なる
newmoグループではタクシー会社を多くグループに迎えていることもあり、メーターの種類やBluetooth送信機の組み合わせがいくつか存在します。
過去にその組み合わせが増えるたびに、検証・開発をしてきました。メーターのメーカーごとにメーター情報の形式が異なるのはもちろんのこと、「Bluetooth経由でメーター情報を取得する」と一口に言っても、実際にはいくつかの方式があります。
例えば、BLE(Bluetooth Low Energy)GATT 接続、Bluetooth Classic接続、BLEのAdvertiseパケットを一定周期で受信するなど方式があります。
今後もタクシー会社をグループに迎える可能性もあり、メーターやBluetooth送信機の組み合わせが増えることが予想され、そのたびに検証・開発が必要になります。
2. 100%の接続状態を保つのが難しい
Bluetooth通信は無線通信のため電波干渉などの影響で接続が不安定になることがあります。切断時の再接続などの実装は入れているものの、常に100%の接続状態を保てているという保証はありません。
3. メーターの運用コスト
メーター連携の課題とは少し異なりますが、現行のタクシーメーターについても個人的に課題感を持っています。
例えば、運賃改定等があった場合にはタクシーメーター本体の更新が必要となったり、法令に基づき定期的な検定やメンテナンスが求められるため、ハードウェアならではの運用・更新作業が発生します。
こうした課題を解決できるものが「ソフトメーター」であると個人的には考えています。
ソフトメーターとは
ソフトメーターは、従来は専用ハードウェアとして車両に取り付けていたタクシーメーターの機能を、タブレット端末等のソフトウェアとして実装したものです。

従来のタクシーメーターは、タイヤの回転数などの車両信号をもとに走行距離を推定し、その距離や時間に応じて運賃を計算していました。
一方、ソフトメーターは、GNSS(GPS など)から取得した位置情報などから走行距離を推定し、その距離や時間をもとに運賃を計算します。計算処理はすべてタブレット内で行われるため、メーター本体という専用機器に依存せず、従来のメーター機能を提供できます。
このソフトメーターを自社で開発し、車両に統一して導入すればメーター連携の課題の解決が期待できます。
メーカーごとに異なるメーター仕様に対応する実装が必要なくなり、乗務員さんがタブレット端末でメーター操作をして、端末のネットワーク経由でバックエンドにメーター情報を送信できるようになります。これにより、Bluetooth経由でメーター情報を取得してからTDAでバックエンドに送信することが不要になり、より安定したメーター連携が期待できます。
さらに、運賃計算をソフトウェアで行うため、運賃改定や制度変更にも柔軟に対応でき、設定変更も遠隔でできるため、車両ごとの対応が不要になります。定期的なメーターの検査についても、運行中のデータをソフトウェア的に収集し、国土交通省へ提供することで対応できます。これらにより、ハードウェアに起因する物理的な運用作業も減らせる可能性があります。
ソフトメーターの走行距離推定について
タクシーメーターの重要な役割の一つとして、運賃計算があります。
運賃は「走行距離」と「走行時間」に基づいて決まるため、走行距離を一定の精度で正しく推定する必要があります。
ソフトメーターにおける走行距離の推定方法については、国土交通省が資料として公開しています。

走行距離の基本的な考え方は、GNSSから一定間隔で送られてくる緯度・経度・時刻の情報をもとに、地点どうしの距離を計算し、それらを順番に足し合わせることで走行距離を求めます。
しかし、トンネル内などGNSSの電波が届かず、しばらく位置情報が更新されない区間も存在します。そのような場合には、車両から取得できる走行信号(車速など)や、ジャイロや加速度といったセンサーデータを用いて、位置情報を補正する必要があります。
そのため、ソフトメーター開発のための第一歩としては「GNSS信号」「走行信号」「センサーデータ」の取得について検証する必要があります。
GNSS信号とセンサーデータについては、タブレットなどの端末から取得できる可能性が高いと考え、今回は走行信号の取得を試してみることとしました。
車速の取得方法について
前述の通り、走行信号は移動した距離の算出に使用されるため車速を取得する必要があります。
車速の取得にはいくつか方法はありますが、近年はOBD2(On-Board Diagnostics Ⅱ)が多くの車両に搭載されており、比較的手軽に利用できることから、今回はOBD2を用いた方法を試してみました。
OBD2は、車両の自己診断や整備のために用意されているコネクタで、エンジン回転数や車速といった様々な車両情報にアクセスできます。
OBD2アダプタを車両のOBD2ポートに接続し、有線(USB)でタブレットなどの上位機でつなぐことで、車速情報を取得することができます。
※ 車両やOBD2アダプタによっては、ECU(Electronic Control Unit:車両用コンピュータ)等に影響を及ぼす可能性があります。使用や検証は自己責任で行ってください。
OBD2での車速検証の方法
以下のOBD2アダプタを使用して検証することにしました。

newmoでは、テスト用のタクシー車両としてJPN TAXIを保有しています。
この車両は 運転席下部にOBD2ポートが設置されているため、そこにOBD2アダプタを接続します。

PCとOBD2アダプタを接続し、Pythonのpython-OBDライブラリを用いて以下のコードで車速を取得することします。
import obd import time def get_speed(): connection = obd.OBD("/dev/tty.usbserial-XXXXXX") if not connection.is_connected(): print("OBDアダプター接続失敗") return while True: response = connection.query(obd.commands.SPEED) speed = response.value.magnitude print(f"\r車速: {speed} km/h") time.sleep(0.5) if __name__ == "__main__": get_speed()
OBD2アダプタの反応がない…
いざテスト車両で検証しようとしたところ、OBD2アダプタに反応がなく車両の常時電源を取得できていないようでした。
同僚に相談したところ「ヒューズが飛んで電流が流れていないのではないか」という話になりました。ヒューズは、規定以上の電流が流れたときに内部の金属部分が溶けて回路を遮断し、配線や機器を守るための部品です。
助手席下部のフューズボックスから取り出してフューズの状態を確認してみることにしました。

車両から取り出したヒューズを確認したところ動線が切れており、なんらかのタイミングでヒューズが飛んでしまっていることがわかりました。

(少し見にくいかも...)
新品のヒューズに交換したところ、OBD2アダプタのLEDが点灯し、無事にOBD2ポートと接続することができるようになりました。
検証結果
テスト車両で検証をし、以下のように車速を取得できました。車両のスピードメーターと比較すると、OBD2ポートから取得した車速は-5km/hくらいの差があることがわかりました。

これは車両のスピードメーターは「道路運送車両の保安基準」により実際の速度を超えてはならないという制限があり、スピードメーターは実際の速度より高めに設定されていることに起因すると考えられます。
今回の結果だけではソフトメーターとしての認定基準を満たせるかどうかまでは判断できませんが、OBD経由の車速情報からはある程度妥当な速度が取得できていそうだという感触は得られました。
おわりに
今回は、ソフトメーターのアプローチを検討するにあたっての参考として、JPN TAXIからOBD2経由で車速を取得できるかを試しました。
ソフトメーターはメーター連携の課題を解決しうる選択肢のひとつですが、実運用には国交省の認定が必要で、不具合や異常時には営業継続や運賃請求に直結するため、かなり慎重な検討や設計が求められます。
今回の検証が将来のタクシーメーターのありかたを考える材料になれば幸いです!