車両診断通信 【DoCAN】車両診断通信 その6【ISO-TP①】
1対1通信の物理アドレスと1対多の機能アドレスがある。
物理アドレス、機能アドレスは4種類のアドレッシングフォーマットによって構成が変わる
アドレッシングフォーマットはN_AI、N_TAtype、N_TA、N_SA、N_AEで構成される。
ただし、アドレッシングフォーマットによって使ったり使わなかったり。
2020-07
車両診断通信 
車両診断通信 【DoCAN】車両診断通信 その5【CAN③】
サンプリングポイントを決定するには各セグメントのクウォンタム数を決定する必要がある。
セグメントは4種で1bit分。
Synchronization Segment。
Propagation Segment。
Phase Segment1。
Phase Segment2。
Propagation Segment+Phase Segment1でtseg1、Phase Segment2をtseg2と表現することもある。
車両診断通信 【DoCAN】車両診断通信 その4【CAN②】
基本的には「はじめてのCAN/CAN-FD」を読んでおけばOK。
CANのボーレート設定は特殊。
いきなりボーレートを決めることはできず、1bitを分解したクウォンタム時間を先に決める。
総クウォンタムがボーレートになるので、設定したいボーレートから逆算する必要がある。
CANはサンプリングポイントを調整できる。
総クウォンタム中のどこのクウォンタムでサンプルするかで決定できる。
[%]で表現されることが多い。
真ん中であれば50[%]、やや後ろ側(3/4あたり)あれば75[%]。
車両診断通信 【DoCAN】車両診断通信 その3【CAN①】
ISO11898-2ことCANの物理層について。
必要な規格番号復習。
CANは割と一般的になってきたのでネット上からそこそこ情報が得られる。
DoCANでは1Mbpsが使われることはほぼ無い。
法規の都合。
1Mbpsだと安定性が欠ける面がある。
車両診断通信 【DoCAN】車両診断通信 その2【概要②】
車両診断通信のレイヤについて。
車両診断通信のレイヤはOSI参照モデルで表現できる。
ただし、プレゼンテーション層は無い。
車両診断通信には大きく2つの軸がある。
UDSとOBD。
OBDは自動車排出ガス規制から参照されているため、各種パラメータが明確。
UDSは推奨値があるだけで、実際の数値は完成車メーカ依存。
車両診断通信 【DoCAN】車両診断通信 その1【概要①】
自動車には診断通信機能というものが備わっている。
それについて語っていくシリーズもの。
車両診断通信の概要情報はググればOK。
代表的な規格はISO15765-2とISO14229-1。
完成車メーカの方針によっては具体的な要件ではなく、規格番号が要件ということもある。
事例 最小構成のモデルベース開発事例 バックナンバー
A/D、D/Aだけを持った装置にPID制御を載せるという最小構成の制御ユニットをモデルベース開発に則って開発するという事例のお話。
途中からインターフェースがA/D、D/AからCANに変わるという、とんでもない仕様変更をくらう若干事実っぽいエピソードも入る。
事例 【上流検証】最小構成のモデルベース開発事例 その57【ドライビングシミュレータ⑦】
ついに動かす時。
そして「最小構成のモデルベース開発事例」の最終回でもある。
CARLAにPID制御を組み込めた。
自動車業界で自動運転以外でもPythonの使いどころは多い。
自動テスト環境の一部とか。
コスト構造を意識すると問題点が見えやすい。
これにより何に対して創意工夫をすれば良いかが分かる。
ご拝読ありがとうございました！
事例 【上流検証】最小構成のモデルベース開発事例 その56【ドライビングシミュレータ⑥】
PID制御が弱い場合、PゲインかIゲインを調整するのが一般的。
しかし、今回はそもそも想定周期が異なっていた。
時間の刻み(タイムスタンプ)が明確であれば、前回値との差で時間差が特定できる。
この時間差を積分単位時間としてPIDの演算に組み込むことができる。
(無事、伏線回収！)
事例 【上流検証】最小構成のモデルベース開発事例 その55【ドライビングシミュレータ⑤】
オープンソースドライビングシミュレータであるCARLAの話。
PID制御の組み込みと、車速の取得ができたので動かす。
PythonAPIを叩きすぎると重くなる。
Sleep関数等を使用して処理の頻度を下げることで回避可能。