k4n4のブログ一覧

ドラレコ＋パワーフロー＋テレメトリ表示アプリ

GitHubリポジトリ：https://github.com/k4n4ch/fl4obd
解析レポート：https://github.com/k4n4ch/fl4obd/blob/main/docs/did-analysis/fl4-did-analysis.md （PDF版）


■ はじめに
過去、シビックFL4のOBDからデータを抜いて色々やって来ましたが、今回はさらに一歩踏み込んでかなり詳細な解析をやってみた内容です。
結果的に、i-MMD HYBRIDシステムのエンジン、発電機、モーター、バッテリーを出入りするパワーを可視化できるようになりました。

過去やってきた内容は、全て SAE J1979の標準PIDに則った内容であり、その情報からエンジン回転数、バッテリー電圧と入出力の電流が判明していました。
しかしこれだけでは駆動系の情報がほとんど揃っていないため、他の情報が得られないかを模索しました。

■ 狙いECUを探す
Functional Addressをターゲットに、応答を返してくるECUを探索しました。
その結果、$01, $02, $06, $07, $10, $EFといったECUがレスポンスを返してきました。
ここでOBDだけでなくUDSに範囲を広げ、Service $22のData IDを$0000から$FFFFまで網羅的に探索し、何のレスポンスが得られるかを確認しました。
その結果、Phyisical Address $07のECUが多くのData IDに対してレスポンスを返し、特にそれらの中で走行内での数値変化が見られた $29xx系に絞って解析を行うことにしました。

■ 変数の同定
詳細内容は一番上にリンクを貼った解析レポートに記載しましたが、基本的にはパワーの系で使える情報はOBD PID $9Aのバッテリー電力だけなので、それをアンカーに複数の動作モードを用いて各変数を同定していきました。その際は、$29xxから取れる生データ内の任意の位置のHEX値とOBD取得値との相関性を取り、同時に同じ方向に動く変数を候補として抽出、それをスケーリング・オフセットとして評価していく手順を取っています。

■ 結果
特定できた変数
・駆動系動作モード
・車速
・エンジン回転数、トルク
・発電機回転数、トルク
・モーター回転数、トルク
・バッテリー電力

例えば今回同定したデータを使うと、EVからエンジンを掛ける挙動、シリーズから直結に遷移する際にエンジン回転数をあわせてクラッチを嵌合する挙動、直結からクラッチ嵌合を解除する際にトルクをゼロにしてから手放す挙動などが観察できます。面白いですね。


■ 応用
ELM327の青いOBDドングルからスマホでロギングするWebアプリを作成しました
→ https://k4n4ch.github.io/fl4obd/
ロギングだけでなく、走行中のパワーフローをリアルタイムで見ることもできます。

走行リプレイWebアプリ
→ https://k4n4ch.github.io/fl4obd/replay.html

ドラレコ合成テレメトリWebアプリ
→ https://k4n4ch.github.io/fl4obd/video.html
純正ドラレコのMicroSDをPCに挿し、ロギングアプリのデータをPCに送り、このWebアプリから読み込むと、こういった動画が再生できます。
また、手順に従った動画書き出しも可能です。


Webアプリの方も色々と凝っていて、特にGPSが途切れるトンネル区間については、トンネル前後地点をOpenSteetMapで判定し、平面方向に関してはOSM上の道路経路に沿うように、かつ速度情報の積分で自己位置を推定しています（車のナビと基本的に同じ思想）。また、トンネル内の標高と勾配は、駆動に使っているパワーから走行抵抗を算出し、そこから道路の勾配を推定しています。（これは独自）


少し話が逸れますが、このトンネル内勾配推定をやっている過程で、空気抵抗のパラメータとしてCdAが算出できます。これを関越トンネル内外で比較すると、
トンネル外：0.64
トンネル内：0.50
となります。

しかしCdAは当然物理的な形状で決まる定数なのでトンネル内外で変化するものではありません。CdAを固定しトンネル内では追い風があって実効的な空気抵抗が減っていると仮定すると、その追い風は3.1 m/s（約11km/h）となります。
関越トンネルのような長いトンネルの場合、多くの車両が同じ方向に走行することでトンネル内の空気全体が走行方向にゆっくり流れており、それが緩やかな追い風となって空気抵抗の低減に効いているという解釈になると思います（トンネルにおけるピストン効果）。250ccのバイクに乗っているとトンネル入った際に明らかに駆動が楽になると思っていましたが、今回の件で原理が判明しました。

◯ 背景
最近寒いので、触媒やら冷却水やらを温めるためにエンジンが回りまくって燃費が終わっています。以前作った コイツ でJ1979準拠のPIDを叩いて表示できるようになったので、触媒や冷却水の温度も見たいなと思ったわけです。

◯ まずはPIDの一覧をちゃんと取得する
Wikipediaの記事 を見ると、PID $00の内容 → PID $01~$20 の対応状況を表示してくれるという機能になっており、以降PID $00, $20, ..., $C0の上位ニブルが偶数のPIDがその代の対応状況を示しています。PIDの一覧はJ1979規格で定義されているしWikipediaの記事にも情報あるので、まずはFL4で何を出してくれるかの一覧を作りました。

ハードウェアとしては既存のものを流用し、中身のソフトだけPID $00, $20, ..., $C0をFunctional Address宛にリクエストして、何のPhysical Addressからどういったレスポンスが返って来たかを収集しました。そしてそれを整理して各PIDにどのPhysical AddressのECUが対応しているかの一覧表を作成しました。見方としては、一番上の行で背景オレンジの「01, 02, 06, 07, 10, EF」がECUの種類で、そこから下の列がそのECUの対応状況を示しています。行方向の見方としては、例えばPID $0C（Engine speed）は全ECUがリクエスト返してくれるという意味になります。（対応しているECUが居ないPIDは表示上除外しています。）



◯ 取得したPID一覧から欲しい情報を取る
ということで一覧を見てみると、PID $05, $3Cがそれぞれ冷却水温と触媒温度なようなので、こいつらを取得してみることにしました。実際に表示を追加したものがこちら。右下に追加した"Wa"が冷却水温、"Ca"が触媒温度です。


◯ わかったこと
今回分かったこととしては、触媒温度は意外と一気に500℃くらいまで上昇してくれる。冷却水温の上昇はかなりゆっくり。したがって、当たり前ですが冷却水を熱源として使う暖房をONにすると、冷却水を温めるためにエンジンを動かし続けるので、冷却水も触媒も温めなきゃいけなくて燃費が終わります。短距離だったらEV走行で粘りやすいようにエアコンはOFFにしたいところ。

また、走行すると走行風で冷えてしまうので全体の温度上昇がかなり遅い。一旦温まればそれを維持するためのエンジン出力は少なくて済むので、とりあえず走らずに暖気した方が体感としてはエンジン回ってる時間は少ない気がします。

もう一つ気付いたこととして、暖気のエンジン回転数は複数の段階が存在すること、その段階によってバッテリーへの充電有無が異なることです。暖気のエンジン回転数は1700rpm, 1500rpm, 1200rpmあたりの3段階があるようで、前ふたつは停車中でもバッテリーへの充電がなく、走行に電力が必要な時はその分だけエンジン負荷を上げてバッテリーへの入出力が無いように制御しているようでした。つまりほとんどHEVとして動いておらず燃費がかなり悪い。逆に1200rpmモードの時は車両の負荷によらずほとんど回転数は変わらず維持されていて、停車中もバッテリーに充電しています。この場合、まさに上記の写真がそうなのですが、ひたすらバッテリーSOCが貯まっていく挙動になるようです。

初回：https://minkara.carview.co.jp/userid/3661994/blog/48450663/
2回目：https://minkara.carview.co.jp/userid/3661994/blog/48457713/
3回目：https://minkara.carview.co.jp/userid/3661994/blog/48468738/

このところFLシビックHEVでOBD2のPIDから情報取得してエンジン回転やバッテリー使用状況を表示する補助メーターを作ってきたわけですが、今回一旦完成と言えるところまで来ました。

まず、元々Arduino UNOを使用していましたが、SRAMが2kBしかなくSSD1306 OLEDへの描画バッファが足りない始末だったためお役御免に。手元に転がっていたRaspberry pi picoがSRAMモリモリでArduinoの環境そのまま使えそうだったので移植しました。結果的にかなり小型化できました。



移植したものも無事動き、OLEDの描画バッファ問題もあっさり解決しました。
移植にあたってChatGPTに元のコード丸投げして「Pico用に書き換えて」と言ったらそのまま動くコード出てきて神でした。

ちなみに前回言及していた、SF (req) -> FF (rsp) -> FC (req) -> CF (rsp) の会話がうまくいかずにCFでもらうPID 0x9Aのバッテリ電流がうまく取れない問題ですが、forで回すリクエストを決め打ちでSFのあとにFC送る順番で固定することでとりあえず動くようにしました。本当はちゃんと会話したいんだけど、場当たり対応でお茶を濁した。。。

というわけで本体は動くようになったのでケースを作ります。
いつも通りFusion 360でモデルを作り、Bambu Lab A1 miniで出力。
裏蓋の張り出しは、FLのメーター下部に両面テープで固定するための保持部です。



実際に車に設置した姿がこちら。
前回少し画面を作り込んでいましたが、結局欲しいパラメータはエンジン回転数、バッテリ電力、バッテリ電流、SOCの4つで、バッテリ電圧と稼働時間はそこまで大きくなくても良いなということで、メイン4つを大きく表示するシンプルなレイアウトに変更しました。



これでSSD1306に表示するタイプとしては完成ということにした。
次はILI9341の液晶画面にもうちょっとグラフィカルに表示することを目指そうと思っているので、また進捗があれば何か書くかもしれない。

一応書いたコードを置いておきます。
インデントうまく反映できないのでテキストベタ貼りではなく画像にします。

（また同じ話題の続きになるんですが）
PID 0x9AでFirst frame（以下FF）は受信できるのになぜかその後にくるはずのConsecutive frame（同CF）が受信できず、ハイブリッドバッテリーの電圧は分かるけど電流が分からないという状況になっていた。

最初はFF受信したあとにECUが間髪入れずにレスポンス返してきてマイコン側が受信できてないんじゃないかと考えていたので、ブログの前回の最後に書いたようにCAN受信してバッファに格納するタイマー割り込みとそれ以外を分けなきゃ・・・みたいなことを考えていた。でも更によくよく考えると、FFのあとにFlow control frameを打ってあげないとCFを返さないんじゃないかってところに思い至った。
つまり、受信できていないんじゃなくて、そもそもECUが出してきていない。

だとするともうちょっと光明が見えてきて、現状のloop()の中でFF受信した時だけ分岐でFC打ってあげてCF受信するという形にすれば、必要なデータも取れるんじゃないか？？という方針で今後やってみようかなと。

あと、今のところそもそもちゃんと受信できるのかってところを確認する試作段階なのでテキトーなOLEDに表示しているんですが、ゆくゆくは日常ユースで車に設置したいと考えているので、それ用の3.2インチ液晶もアリエクで買いました。
ぼちぼち上記課題を解決しつつ、表示したいデータを満足に作れるようになったら液晶への出し方も考えていきたいな～と。

◯ はじめに
前回（https://minkara.carview.co.jp/userid/3661994/blog/48450663/）こんな話をしていた。

早速ちょっと手詰まり感でてきたのでアプローチを変えてみようと思い、ELM327のリバースエンジニアリングやSAE J1979 DAやISO 15765-2といった規格文書を読んでみて色々分かってきたので、メモを残しておく。


◯ ELM327

正攻法で地道にやるのも飽きてきたので、市販のELM327+Carscannerアプリを使って各値を表示させつつ、ELM327のピンから物理的にCAN信号を傍受して、ELM327と車載ECUとの間の通信がどうなっているかを把握することにしました。
実際に傍受できたリクエストとレスポンスをまとめて、代表的なデータを含めて記載したものがコチラ。


自分が欲しいデータについて、Descriptionの列に色を塗った。基本的にレスポンスを返してくれるのは18DAF101くんのようだ。

ここで、PID 0C, 0D, 5Bに関してはレスポンスが1フレームに収まっているが、9Aに関しては挙動が異なっている模様。でも知識的にこれ以上分からん。。。



◯ ISO 15765-2
こういうのは教科書を読みましょうということで、ISOを参照してみましょう。
分かったこと：
・レスポンスデータの1バイト目の上位ニブルがPCItypeというパラメータで、そのフレームの役割を示す
・PCItype=0：SF (Single Frame)：1フレームで完結するレスポンス
・PCItype=1：FF (First Frame)：複数フレームに跨るレスポンスの最初のフレーム
・PCItype=2：CF (Consecutive Frame)：複数フレームに跨るレスポンスの続き

・レスポンスデータの1バイト目の下位ニブル（FFの場合は2バイト目も）がそのレスポンスのデータ長を示している。
・FFの場合はFF自身だけでなくCFに載るデータも含めたデータの全長が示される。

ということで、PID 0x9Aのレスポンスについては
・FF+CFの2フレームで構成される
・データの全長は8バイト
・表のデータ例だと、FFに07 00 41 BF、CFに00 06のペイロードが載っている

データの見方がわかったので、データの読み方を調べてみましょう。


◯ SAE J1979 DA
OBD法規に引用されているSAE J1979に、具体的なデータの詳細が書いてあります。それを元に読み解いた結果がこちら。

というわけで、CDEFのData Byteを読み取れば良いということが分かった。
なお、CDはFF、EFはCFのペイロードになっている。


◯ おわりに
とりあえず仕様は理解したので、これに合わせてArudinoくんに動いてもらうように躾けが必要ですね。
具体的には、受信したフレームがSF, FF, CFのどれなのかを判別し、FF, CFの場合は連続するそれらのペイロードを連結してデータを再構成する。
ただしこういった処理をする場合は今のようにメインのLoop関数の中で逐次処理するやり方ではおそらく不可能。CAN受信をタイマー割り込みに変えて、そっちで格納した変数をLoop側で処理するという構成になると思う。一発でそこまで行くのは厳しいので、とりあえず次回はCAN受信をタイマー割り込みにするところあたりから。。。