sz2のブログ一覧

とりあえず作ってみた

起動時に一瞬暗転が無効なる問題をなんとかしたい。

WebSocketGaugeServerをAndroid単独で動作させる方法を整備手帳にUpしました。

もともとこのプログラムはELM327（あるいはArduinoボード）と通信するサーバー部分をPCやRaspberry piで動作させ、サーバーから配信されたセンサ情報をクライアント用のブラウザアプリで表示する構成を取っておりました。

昔はRaspberry Piの入手性は今ほど悲惨ではなかったので、これでも問題なかったのですが、昨今はRaspberry Piが高騰・入手困難になってしまったため、なんとかAndroid単体で動作させる方法を試していました。

サーバー部分をAndroidで動かすのですが、プログラムをAndroidアプリに移植するのは大変なので、Androidでlinux互換環境を実現するtermuxを利用します。ただtermuxはELM327等との通信に必要なUSBやBluetooth（シリアル）アクセスが不可能であるため、シリアル→TCPのトンネル部分を外部のハードや変換用アプリに頼ることになります。

整備手帳その１
整備手帳その２

となります。このやり方も時にAndroidが勝手にサーバーを落としてくれたりして結構大変なのですが、何かの役には立つのかもしれないです。

拙作のプログラム、元々は

車載PCとかラズパイにELM327(あるいはArduino)を繋いでサーバーとし、スマホのWebブラウザにメーターを表示する

構成でしたが、昨今はラズパイが暴騰極まりないので、このサーバー部分もAndroidで動作させられないかをトライしています。

このサーバー部分は(dotnet6.0ベース)でWindowsないしはLinuxでの動作を確認しているわけですが、Androidアプリとして移植するのはかなり大変なので、
Termuxという（公式のアプリストアにはないのですが）Linux互換環境アプリで動作させようとしています。

実際のところプログラム自体は動かすことはVer4.0にてもう出来ております。
ただ問題はTermux上から（ELM327が接続されている）USBシリアルポートやBluetoothシリアルアダプタに直接アクセスすることが出来ないことです。そこで、Termuxでの動作のために、シリアルポート通信をTCPでトンネルする機構を実装し、別途TCPからBluetoothやUSBシリアルにトンネルするサーバーアプリを使うようにします。
例えば、
こういうのとかです。

これでなんとか動かすことが出来ているのですが、問題はAndroidがこのシリアルポート<->TCPトンネルアプリを勝手に落としてしまうことです。電池の最適化を切ったりしてるのですが、いかんせん完全ではなく、どうしたものかと悩んでいます（RAMが潤沢なスマホなら起きないものなのでしょうか？手持ちのRAM4Gのスマホでは結構頻繁に落とされてしまっています）
シリアル<->TCPトンネルアプリを使わず、最初からWifi用ELM327を使ったほうが良いのかもしれません（手元にないので試していませんが・・）

前回に引きつづきOBDIIの複数PID同時通信についてです。

前回はPCからELM327経由→ECUへ複数のPIDを問い合わせる方法を書きましたが、今回はECU側の実装について書きます。

もちろん実際にECUを作るわけではないのですが、Arduinoを使ったECUシミュレータとか、これみたいなOBDII対応ECUのふりをするプログラムを作っている関係で、ECU側の実装もトライしてみようとしたわけです。

さて、ECU側がELM327から要求されたPIDに対するセンサ情報を返すとき、
1. ECUはELM327から届いたCANメッセージを解読して、要求されたPIDを抽出する
2. ECUは要求されたPID情報に対応するデータをELM327に返信する
という流れになるわけです。

1ではELM327から送られたメッセージを解析するわけですが、
ここはそんなに難しくなく、PID問い合わせが一つの場合と複数同時の場合でそれほどプロトコルに変更があるわけではありません。

PID問い合わせが一つの場合では、このWikipediaの"CAN (11-bit) bus format"->"Query"->"SAE Standard"にある通り、ELM327から送られるCANメッセージは

ss 01 aa xx xx xx xx xx
(ssは後続のデータバイトの数。この例では後続データは01 (サービス番号) + PIDの2バイトになることが確定しているのでss=02となる。01はサービス番号で「現在のセンサ値を要求」に対応する。aaが要求するPID）

となります。

PID問い合わせが複数の場合はこれの拡張で下記のようになります。

ss 01 aa bb cc dd ee ff
(ssは後続のデータバイトの数。いくつPIDを問い合わせているかで変わる。01はサービス番号、aa~ffが要求するPID）
となるわけですが、規格上同時に問い合わせるPIDの数は最大6となっておりますので8バイトを超えることはありません。

さて、問題は2のECU→ELM327への返信です。
フォーマット自体は単純で、下のようにただ「PID」+「対応するデータ」を繰り返し列挙するだけです。

41 aa xx bb yy cc zz zz dd uu ee vv ff ww wｗ
(41は返信用サービス番号。問い合わせのサービス番号+40hなので、01の問い合わせに対しては41を設定する。
aa~ffは問い合わせたPID, xx~zz, uu ~ wwはPIDに対応したデータ。
上の例ではccとffに対応したデータが2バイトであるとしてzzとwwは2バイトになっている（ほかは1バイト）。）

しかしここで問題になるのは、
「CANが1回で送信できるのは最大8バイトまで」
という制約があるということです。Arduino用CANトランシーバ (MCP2515)のライブラリも送信メソッドは8バイトまでしか対応してなく、
上の例では8バイトを余裕で越しているので、そのままでは送ることができません。

そのため、8バイト以上のデータを送信するために複数回に分割して送信するわけですが、送信の手順には決まりがあり、ISO-TP(ISO15765-2)に従わなくてはならないそうです。こちらにも説明があります
（送信側が勝手にデータをガンガン送るのではなく、一旦受信側から受信準備ができたのを確認してから（更には受信側が最大何フレーム連続で受信できるかとかも確認しつつ）、送らなくてはならないというわけです）

このような分割処理を一から実装るするのは大変なので、ここは先人の知恵、すなわちライブラリを参照させていただきます。GithubにArduino用ライブラリを公開されている方がいますので、これを利用させていただくこととします。

これを利用すれば、MCP2515のオブジェクトをラップする形で、任意の長さのバイト配列をISO-TPに則った形で送信することができます。

本日はOBDIIの複数PID同時通信についてです

OBDIIの通信方法としてまず参考にするのがWikipediaの記事
https://en.m.wikipedia.org/wiki/OBD-II_PIDs
です。
ここにCAN通信を行ったときのプロトコルが書いてありますが、
ここに書いてある例では一回のECUへの問い合わせ(Query)で使うPID（車両センサ情報の種類）は一つのみになっております。
よって複数のPIDを問い合わせる場合には、PIDの数だけ問い合わせを発行しなくてはならず、結果PIDの数だけ通信が遅くなってしまいます。（例えば1回の通信の応答時間が20msだとすると6種類の PID を問い合わせるのに20*6=120ms要し、fpsに換算すれば10fps以下とコマ送りになってしまいます。）

一方ELM327のデータシートにはMultiple PID requestという項目があり、通信先の ECUが条件を満たせば、最大で6つのPIDを同時に問い合わせることができるとあります。
(ここのデータシートの45ページ目参照。)

というわけでこれの実装トライしてみます。

ELM327→ECUへの通信はELM327のデータシートにある通り、問い合わせたいPIDをまとめてELM327に送れば良いようです。データシートの例にもありますが、エンジン負荷(PID:04)、水温(PID:05)、インマニ圧(PID:0B)、エンジン回転数(PID:0C)を一度に問い合わせるならば、
01 04 05 0B 0C
とELM327に投げれば良いことになります。（同時問い合わせをしないならば01 04, 01 05, 01 0B, 01 0Cの5回要求を投げ、各々1回毎にECUからの返答を待たなくてはなりません）

ただ、ECUからの返信に関しては注意が必要で、データとしては「問い合わせたPID」+「PIDに対応したデータ（センサ値）」の組（上の例なら4組分）がまとめて返ってくるわけですが、このPIDとデータ組の合計が6バイトを超えると、（データシートの例にある通り）通常とは変わった複数行フォーマットでELM327は読み取りデータを返すことになります。

例えば、
エンジン負荷(04)と水温のみ(05)の問い合わせならば、どちらもデータは1バイトであり、PIDと合わせても合計2*2=4バイトなので、ELM327の応答は

41 04 3F 05 44
(PID04 のデータが3F、PID05のデータが44）

となるわけですが、これにインマニ圧(PID:0B)、エンジン回転数(PID:0C)を加えた場合は

00A
0: 41 04 3F 05 44 0B
1: 21 0C 17 B8 00 00 00

と返信のフォーマットが変わるので、これを考慮したプログラムが必要です。

（実のところこのようにフォーマットが変わるのは、ECUが返信を2回に分けて行っているからなのですが、これについては次のECU編で書きます。）