WHAT? / 適合(Calibration)/セッティングとは?
は じ め に
電子コントローラ(ECU)の適合(Calibration/Matching/Setting)とは、車両の仕様や用途、使用地域にあわせて、制御定数の最適値を求めていく作業です。
ここでいう「適合」とは「更生」という意味合いではなく、Matching、Settingという意味合いです。
この最適値は、演算処理能力や、理論値と実際の値との誤差が大きく、今日のところECU内で計算して求めることが困難です。
この定数を、机上計算→ソースコード修正→Build→実験→ソースコード修正→Build→実験→ と何度も繰替えすと非常に工数がかかります。ソース修正者 と 実験者 は大抵異なりますし、部署が違うと指示/依頼の手間も生じます。

そこで、最適値をECU内の定数として、埋込む手法がとられています。
その作業の中で、エンジニアがECUへ各種指示を行うためのユーザインターフェイスが、PCアプリケーションとして開発されています。

主な機能は、
  1. ECUの内部変数の計測と分析
  2. 適合変数(MAP)のリアルタイム表示と更新
  3. 適合変数から、ECUのROMデータ(.hex や.mot)の生成
  4. ECUのROMデータの書換え(Reflash/Reprograming)
3.と4.は、純正ECUではPCのように内部データの書換が自由にできないために必要です。(後述FBLを参照) アフター向けなど、エンドユーザが頻繁に変更することが前提のECUでは、サイズが大きくアクセスの早い不揮発性メモリを搭載し、3と4は無い場合があります。

インターフェイスと規格
これらは、ECU、通信インターフェイス、アプリケーションソフトとシステムとして実現します。
市販製品では以下のものがあります。導入費はCANでの構成で1Set 150万円くらいです。
  1. ETAS社INCA 乗用車では世界シェアTOP、適合機能が高い。画面が汚く良く落ちるがエンドユーザでのカスタマイズ性が高い。マイコンが限られますがETKもpointです。
  2. Dspace社ControlDesk モデルベース開発との親和性が高い、実験用汎用ECU:MicroAutoBoxのユーザインターフェイスでもあります。
  3. Vector社CANpe INCAより画面がきれい。XCPonCANのECU側ドライバは他ベンダは無償版のみですが、こちらは有償版が有り。使用するマイコンに合せてCAN通信部も作ってくれるのかも。しかし全般的にカスタマイズ費は非常に高額。
  4. ATI社VISION 他はドイツ製ですがこちらはUSA製。画面デザインは非常にきれい、MATLAB/Simlinkのモデルを既存ECUにエクステンションできるとか。
自動車部品メーカー、車両メーカのオリジナル版も複数存在します。
それらの中では以下のキーワードが重要となります。
  1. 通信プロトコル応用層(CCP/XCP/オリジナル)
  2. 通信プロトコル物理層(CAN/K-Line/MCUデバッグ用)
  3. 適合/セッティングデータのファイルフォーマット(A2L/オリジナル)
  4. ECU書換プロトコル(CCP/XCP/オリジナル)
上記のものは、業界標準のものと、メーカー独自のものがあります。業界標準のもの使用方法は様々です。 その為、独自の適合アプリ、適合機能がいろいろと必要になってきます。


「A2L」とは何ぞや?との方は、ASAM委員会からこちらにダイジェスト版が公開されているようです。
「XCP」にいては、VECTER社の解説書が公開されています。DAQがいかに負荷および遅延なくRAM値計測が可能かが読みとけます。
適合データの作成
適合データの作成は非常に手間がかかるところです。
一般的にコンパイラが出力する .map から基本アドレスを抽出し、適合データを生成するアプリケーションを用意します。
構造体メンバアドレスや配列行列数は、.mapでは判断できないため、ソースコードを読込みそれらを抽出するアプリケーションも必要になります。

変数アドレスはECU開発中は逐次変わるため、素早くアドレスや構造変更に対応でき、アドレスずれによる動作異常を防ぐ仕組みも必要です。
これらはコード記述ルールは組織によって異なるため、各メーカ、サプライヤ毎に作成されていると言われています。

なお万能では無いようですが、A2Lは制御モデル等からの生成も可能になっています。
ECU開発現場に限られそうですが、build後の.absファイル等から変数一覧が表示できるツールもあるようです。

また付随機能として、異なる車両、異なる仕向けの適合データ値を、比較、マージするアプリケーションも必要です。

その他技術要素
アプリケーションに付随する技術要素しては以下のようなものがあります。
  1. ECUもしくは中継I/FとのUSB通信
  2. PCアプリのコピーガード対策、USBドングル、ネット上でのライセンスアクティベーション。
  3. インストーラの作成。


FLASH BOOT LOADER
またECU適合を行うには、FBL(Flash Boot Loador)の適用が欠かせません。
ROMライターを用いず、マイコン自らがROMを書換えるのための各種機構です。その一構成の概要を下図に示します。


純正ECU( 開発用スペシャルは除く )ではこれが無いと適合値をECUに反映できません。
FBL以下の機能を有します。
  1. ECU起動時に、通常起動するか、ROM書込モードに移行するか切替える。
  2. ROM書込モード時、ROM書換制御プログラムをRAM上に展開し、スタートします。
  3. ROM書換制御プログラムは、シリアル通信やCANから新しい制御本体プログラムを受信しながら、ROMを書換えます。
  4. ROMを書換え後、書換えが成功したかCRC等で照合します。
その他FBL技術要素を以下に示します。
  1. ベクタテーブの二重化、可変化。
  2. FBL専用のROMエリアのアロケート。
  3. ECUをROM書込モードに移行する手段。
    → 起動直後のみ受付ける方法、専用通信コマンドでECU稼働中に受付ける方法があります。
  4. ROM書換制御プログラムを保持する方法。ROMに予め埋込む方法、PCアプリから転送する方法があります。
    → 後者の方が適合作業や生産ラインでの時間短縮に繋がります。
  5. ROM書換制御プログラムを暗号化するか?
    → 埋込方式時は、誤ってROM書換制御プログラムにJUMPした場合、ROM消去されるリスクが減ります。
    → 転送方式時は通信スキャンによる情報漏洩を防げます。
  6. 適合データ部と制御本体プログラムを別々に書込みできるようにするか?
    → 対応すれば適合作業や試験時にROM書換時間が圧倒的に減ります。
  7. 制御本体プログラムをPCアプリから送信時に暗号化するか?
    → 対応すれば通信スキャンによる情報漏洩を防げます。
  8. 書込み失敗時のリカバリ方法。
  9. 市場での不具合/改善によるECU書換えとの両立もしくは共用。
エミュレータやROMライターのみでの書換えを採用している場合、ROM/RAMサイズの変更、信頼性度によっては大きな工数が掛かります。
まとめ
実車のみでの使用と思われがちですが、ECUのハードウェアとファームウェアの開発に、利用されるケースも多々あり、比較的ユーザ層は広い場合もあります。
技術的には、車載およびエンジン制御に限らず、広く電子コントローラに適用できると考えます。
弊社ではこれらの一連のHowToを保有しています。
以下の場合はぜひこちらより相談ください。
  1. 社内用には市販適合ツールは高価なため全て開発メンバーにライセンスを用意できない。
  2. 市販適合ツールにしたいがプロトコル規格に合わせられない。
  3. 内製適合ツールがあるが機能/性能が低い。
  4. 内製適合ツールがあるが古くてメンテナンスできない。
  5. 適合(車両実験)担当以外に、回路担当、ファーム担当、外部委託先でも広く利用したい。
  6. 単に仕向け毎に、制御常数のプログラムコード変更に非常に手間がかがっている。
  7. 適合はせず XCP DAQだけしか使わないのに市販ツールが高価。オリジナルを作りたい。
  8. 内製適合ツールがあるが、XCP DAQ on CANに対応させたい。

(c)2019 Moto+4 Applications LLC All rights reserved.