CAN解析 その2

ハード、ソフトの準備ができたとして、いよいよCAN解析です。
流れです。
　車体のCANに繋いでデータ取得
　スプレッドシートに読み込み
　CAN ID特定
　パケット内のデータを詳しく見る

データ取得
解析し易いように、特徴的なデータが採取できるようにします。（エンジン回転数なら、急に上下させるとか、アイドリングストップの設定なら、ボタンのON/OFFを10繰り返すとか）
candumpで取得します。コマンドラインは以下の通りです。
candump -L can0 > MyLog.log

ログファイルMyLog.logがカレントフォルダに出来上がります。
次にスプレッドシートに読み込み可能な形式に編集します。
スペース区切りになっているので、カンマ「,」区切りにします。IDとデータの区切りの「#」もカンマに置き換え、タイムスタンプの数値を囲んでいる「（）」を削除します。
エディタの置換機能を使えばできます。
最終的に写真のような書式になります。
また、ファイル名の拡張子は「.CSV」にします。

元の編集していないログファイルを写真のPython言語で書かれたツールに通して、CAN IDを絞ります。（ツールは私が作りました。MITライセンス準拠で使ってください。（利用無償です。編集もご自由に））
コマンドラインは以下のようになると思います。
python プログラムファイル.py ログファイル名 書き出しファイル名

引数のエラーチェックとかして無いので、実行時は注意してください。

私はコマンドラインでなく、VSCode上で動かしています。（エラー時止まってくれるので）
VSCodeで実行するには、launch.jsonに入力ログファイル名と出力ファイル名を記載して実行します。
launch.jsonの表示方法は以下を参照してください。
https://yaspage.com/yasunolog/vscode-python-launch/
写真は記載例です。
"justMyCode: true"の後に「,」を入れるのを忘れずに。

ツールを通すと、ログ上で値が変わったデータが「x」で表示されます。（4ビットひとまとまりでチェックしています）
値が変わっていないデータは探しているデータではないので、調査範囲から除外します。
例として、写真のデータだと0x228や0x22Aがパケットまるごと値が変わっていません。（先頭1バイトがチェックサム、2バイト目がシーケンシャルNoだと推測しての話）よってこれらは求めるCAN IDではありません。このように調査対象外のIDを特定します。

先程編集した、拡張子.CSVのログファイルをスプレッドシートに読み込みます。
私はGoogleSpreadを使っています。
読み込んだら全体の表示形式を「カスタム数値」の「0」にします。
それから一行目に行を挿入して、写真のようにタイトルを入力します。
次にシート全体を選択して、フィルタを掛けます。（「データ」メニューの「フィルタ」）

フィルタを掛けたらIDでソートして、特徴がデータに出ているIDを目視確認します。例えば、10回スイッチをON/OFFしたなら、10回データが変わっているか、切り替え間隔はスイッチを操作した間隔と同じか、など。
複数のIDのデータが絡みそうな場合は、フィルタを使って数個のIDだけ表示し、時間順に並べて確認します。（スイッチを押したら、設定が変更された、など）
さて、candumpをLog形式（-L）で取得しましたが、この形式だと先頭にタイムスタンプが入るので、IDでソートしたりしてもタイムスタンプでソートし直せば元の並び順に戻ります。
それと、タイムスタンプは「秒」ですので、同じIDの前のデータと比較すれば、パケットの間隔が分かります。「2秒程度に1回ボタンを押した」場合、タイムスタンプで間隔が確認できます。
また、頻繁にパケットが出ているIDならリアルタイム性が必要なデータと推測できますし、ほとんどパケットが無いようなデータなら重要性が低いものとか、特定のときのみ出るパケット、というような推測ができます。

写真の2行目に、他とデータの長さが違うパケットがありますが、これは680E000000000000というデータだと思われます。
スプレッドシート上は数値の指数表現に「E」を使い、123掛ける10の2乗は123E2のように記載します。そのため680掛ける10の0乗と解釈されてしまっています。
ファイル読み込み時に対策はできなさそうです。

IDの目処がついたら、実車でデータが合っているか確認します。実際に事象が起きたと同時にデータがCAN上に流れれば確実と言えるでしょう。エンジン回転数などは、メーターとデータ数値が合っているかの確認になります。

走行しないと分からないものは、Raspberry Piの画面での確認が難しいですが、Python等のツールも使えることですし、分かるように工夫するしかありません。
目当てのデータが来たときにLEDを点灯させるとか、小型LCDに表示させるとか、GUIのプログラムを組んで画面に表示させるとか・・・。ただ、Raspberry PiはIOピンが外に出ているので、単体でLED点灯やLCD駆動ができ、CAN解析には最適なデバイスと言えるかも知れません。Windowsパソコン等でやろうとすると結構大変だと思います。
Raspberry Piに繋いでいるディスプレイが小さければ、ダッシュボードに固定することもできると思います。
走行時チェックを考えると、Raspberry Pi Zero + RS485 CAN HAT + 小型ディスプレイという組み合わせが使えるのかも知れません。

分析のための知識
・CANは、伝送の仕組み上IDが若い方が優先されます。パソコンLANは早い者勝ちですが、CANは優先度があります。重要な機能ほど若いIDが割り当てられます。
舵角センサー（ステアリングの角度）のようなリアルタイムに処理しなければならない情報とアイドリングストップの設定と、どちらを優先してCANに流さなければいけないかを考えれば、当然の仕組みです。
例えば、前回の動画のようにコントローラユニットとスイッチがあったら、IDが若い方がコントローラユニットです。

・パケットのデータ
パケットの8バイトのデータをどう使うかは、設計（メーカーや設計者の思想など）で異なります。
前回の動画では、2つのIDのパケットでたまたま同じ構造（1バイト目チェックサム、2バイト目シーケンシャルNo）ですが、一般的には全く異なると思った方が良いです。
VM4はパケットのデータの長さも様々でしたが、VN5は8バイトに揃えられているので、ある程度形式を揃えようと設計した形跡が窺えます。

付随的なデータの種類としては以下があります。
・チェックサム
パケット中の他のバイトデータを合計した値です。VN5のパケットを見ると、合計値に固定値がプラスされています。
例えば、「4B080D0686968100」
先頭1バイトがチェックサムです。
先頭1バイトを除いたデータをバイト単位で合計すると「B8」（下1バイト）です。これに固定値0x93を加算すると「4B」になり、1バイト目の値になります。
同じIDのデータに「510E0D0686968100」というデータがありますが、同様に計算できます。
・シーケンシャルNo
パケットの通し番号です。
+1ずつカウントアップされるのが通例です。VN5では0〜Fの通し番号が多用されています。
・パリティビット
バイト単位で、2進数で1になっているビットの個数が偶数になるようにするのが偶数パリティ、奇数になるようにするのが奇数パリティです。
詳しい説明はググれば出てくると思います。
パリティは動きがトリッキーに見え、何のデータのビットか分からず混乱したときはパリティを疑ってみると良いでしょう。

また、データはバイト単位で見るのではなく、ビットで見なければならないことが多いです。
例えばある機能が81からC1にデータが変わるとします。これは「81」「C1」と見るのではなく、二進数で10000001が11000001に変わる、と見て、左から2ビット目がその機能のフラグだと判断した方がいいでしょう。

CAN IDを知る一番確実な方法は、パーツを取り外して電源、GNDとCANのH、Lの線だけを繋いでRaspberry Pi等でパケットを見ることです。
そのパーツのIDしか無いので確実です。
他のパーツが繋がっていないとエラーが発生したりするパーツも多いですが、IDは確実に分かります。（DMSなどはすぐ外せて電源線とCANの線しかないのでやり易いと思います）
しかし、パケットを一定間隔で送信し続けるパーツなら良いのですが、特定の操作をしないと出ないパケットもあるようです。
VMのMFDが該当すると思うのですが、設定変更の操作をしたときだけ出るIDのパケットがあるようです。これは車体ハーネスに接続されていないと分かりません。
上記のように複数IDを持っているパーツもあり、VNのEXナビも複数IDを持っていると思われますので、固定観念に捉われないことが必要です。（EXナビのアイドリングストップのスイッチのパケットは、他のボタンの機能とは関係ないと思われます。他のボタンをON/OFFしてもパケットデータに変更がありません。つまり、他の機能のIDがあるかも知れません）