自動車の電子化を支える適合プロセス、ツール活用が鍵に：いまさら聞けない 適合プロセス入門（後編）（1/2 ページ）

車載システム開発における適合プロセスの変遷

　前編では、車載システム開発における適合プロセスの重要性について説明しました。

　さて、話が多少前後してしまいますが、ECU（電子制御ユニット）の今昔物語にお付き合いください。といっても、筆者自身が車載システム開発に携わったのは、既に電子制御が当たり前になっている時代なので、メカ制御から電子制御への移り変わりに関する実体験をお伝えするというわけではありません。

　しかし、二輪車やオールドカーなどでは、メカ制御で用いられる代表的な部品であるキャブレターはいまだに現役です。こういった過去の知識や歴史を知ることは、今後の技術の発展曲線に対して自分なりに外挿できるので有用かと思います。

メカ制御から電子制御へ

　初期のガソリンエンジンは、機械式にリンクされたスロットルやキャブレターを用いて空燃比を決定し、ガソリンを燃焼させて出力を得ていました。これだと、メカで動作が固定されてしまっているので、周辺環境（周囲の温度や標高）の変化などには対応できません。一方、電子制御では、周辺環境の情報はセンサーから取り込むことができます。特に、空燃比については、三元触媒を用いたλ（ラムダ）センサーによって、理想空燃比近傍での燃焼が可能になりました。これによって、燃費の向上とエミッションの低減を実現し、各種排出ガス規制をクリアしているのはご存じの通りです。

故障診断

　ECUにさまざまなセンサーやアクチュエータが取り付けられ、処理の起点としてセンサーの入力信号を使うようになると、アルゴリズムを実行する上で信号の妥当性やアクチュエータが期待値を出力しているかが論点になります。つまり、「センサーやアクチュエータは正常に動作しているのか？」ということが大事になるわけです。

　このため、ECUには故障診断の機能が備えられています。センサーを例にとると、もしセンサーに不具合が発生している場合に、その「センサー自身に／から」なんらかの信号を「与える／受け取る」^＊1）としても、当のセンサー自体が不具合を抱えているので意味がありません。

＊1）「センサー自身に信号を与える」というのは、故障診断やキャリブレーションのための制御信号を送ることを意味します。

　そこで、周囲の状態の組み合わせを演繹（えんえき）して、故障診断を行うことになります。例としては、このセンサーが温度センサーの場合、温度センサーが正しく動作しているとシステムが認識した時は、ヒーターの故障診断が可能になります。ここで、演繹を利用しているということに注意してください。つまり、ヒーターの出力をアクティブにすれば、温度センサーの出力値も変化するはずです。ここで温度センサーの出力値が温度上昇方向に変化すれば、ヒーターも動作していることが分かります。

　これはあくまでも一例です。エンジン制御をはじめとした車載電装部品の多くはクローズドループの制御になっており、センサーだけではなくヒーターのような出力側、つまりアクチュエータの動作も正しくないとアルゴリズムが成立しません。

　こういった故障診断はOBD（On Board Diagnostics）として、ECUのソフトウェアに組み込まれています。この演繹を行うための組み合わせや制御方法は、各コンポーネント（センサーやアクチュエータ）の特性や動作タイミングに依存します。そういった組み合わせや動作確認も適合プロセスの業務の範ちゅうに含まれます。

非線形領域の取り扱い

　制御を難しくしているもう一つの要因として、制御対象の非線形性があります。こういった非線形性をメカ制御で再現するのは非常に困難です。電子制御では、アルゴリズムとともに離散数値データで持たせたマップを使って非線形性を吸収できます。このマップは1次元から始まり、n次元までのマップで構成されます。

　前編で紹介した「味付け用」のトルクマップなどが典型例です。繰り返しになりますが、このマップの値を追い込んでいくことこそ、適合プロセスの主たる目的と言っても過言ではありません。ECUの進化は、CPUの進化と歩を合わせています。メモリの強化はマップの大きさや粒度になり、CPUの高速化はマップの探索速度とより高度なアルゴリズムの実行に置換されます。ただ、このマップを定義する工数とデータの増大とともに、アルゴリズムの検証作業にもより多くの工数が発生するのは想像に難くありません。

車載システム開発の適合プロセスに用いるツール

　これらの要因から、ECUの開発は複雑化の一途をたどります。当然、適合プロセスにもその皺寄せが来ることになります。以下に、適合プロセスと関わり合いの深い、ECUの開発フローについて説明しましょう。

ECUの開発フローにおける適合プロセスの役割（クリックで拡大） 出典：イータス

制御理論開発

　制御モデルの構築を行うフェーズです。新しい制御理論や物性特性の研究の知見から制御モデルを構築します。主として使われる開発ツールは、ETASの「ASCET-SD」、The MathWorksの「MATLAB/Simulink」、National Instrumentsの「LabVIEW」といったモデリングツールと呼ばれるソフトウェアです。このフェーズでは、制御モデルの動作を確認するために、実際に使用しているECUと接続する場合もあります。

制御ソフトウェア開発

　制御モデルをコード化して実際にターゲットCPUに落とし込み、実装する作業になります。ここではCやアセンブラなどの通常のコンピュータ言語によって記述します。また、制御モデルからコードを自動で生成するツールからの出力も状況に応じて利用します。このフェーズは、適合プロセスの最初期とも言えるので、初期（適合）値を用います。また、ここで生成されたコードは、ETASの「INCA」に代表されるキャリブレーションツールへ展開されます。

実験・計測

　テストベンチでのデータの収集作業になります。一般的なオシロスコープなどを使ったものから、堀場製作所などの専用の計測器を使ったものまで、さまざまな基本データを収集します。このフェーズから、キャリブレーションツールを使い始めます。

制御適合

　適合プロセスの中心的なフェーズと言ってもよいでしょう。計測したデータを基に各種パラメータの合わせ込み作業を行います。適合値の合わせ込みを効率良く行うために積極的にキャリブレーションツールを活用します。

インテグレーション

　ECUの進化とともに適合プロセスの作業は多岐に及んでいるため、複数のチームで同時進行で処理するようになっています。これは、一般的なソフトウェア開発とほとんど同じ文脈です。ソフトウェア開発では、構成管理ツールやバージョン管理システムを使って、各自の変更点をマージしたり、特殊な構成を試したい場合はブランチを発生させたりしてテストビルド（お試しビルド）を構成します。適合プロセスにおいても同様のことが行われます。最終的には、これらは1つにマージされ次の評価フェーズへと進むわけです。このフェーズでは、ETASの「QM-BASIC」などの適合データ管理ツールが使われることになります。

システム評価

　ここまでのフェーズを経てパッケージ化された適合データを用いて、実車で評価を行います。実験を行い、その結果がコードに起因することなのか、データによって起こっている事象なのかを切り分けて、各フェーズへフィードバックします。問題がなければ、その後の承認プロセスを経て最終の適合データとして使われることになります。

　そして、ここまでのフィードバックループを複数回繰り返すことによって、精度と品質を高めていけるのです。

ECUの開発では、フィードバックループを複数回繰り返すことによって精度と品質を高める（クリックで拡大） 出典：イータス