　ガソリンエンジンのECUであれば、コードに当たるエンジンの燃焼制御理論の実装はある程度確立されていると言えます。もちろん、これは現在のECUのCPUパワーで行えるという前提が付きます。エンジンそのものの動作原理は、少なくともガソリンエンジンとディーゼルエンジンという大別があるにせよ、排気量が1000ccだろうが2500ccだろうが大きな違いはありません。動作原理が同じであれば、コードはそのまま適用できます。例えば、三角形の面積は「底辺×高さ÷2」で求められますが、この式自体がコードになります。そこに入力される「底辺」や「高さ」の値がデータになるのです。

　自動車のエンジン回転数を例にとって、コードとデータの関係を考察してみましょう。ここでは話を分かりやすくするために、アイドリング時にエンジン回転数を一定に保つという動作だけを対象にします。

　まず、アイドリングしている時（シフトをNレンジに入れたり、クラッチを切ったりしている状態）にアクセルペダルを踏み込むと、エンジンの回転数は上がります（当たり前ですね）。次に、アクセルペダルを踏み込まずに、エアコンのスイッチを入れてみます。すると、オルタネータを動作させるためにほんの少しですがエンジンの回転数が下がります。では、少しだけアクセルペダルを踏み込むと同時にエアコンのスイッチを入れたらどうなるでしょうか？アクセルペダルの踏み込み加減やエアコンのスイッチを入れるタイミングにもよると思いますが、エンジン回転数を一定に保てるようになると考えられます（これはあくまでも原理の話をしていて、皆さんの実際の車両でどうなるかは「適合状態」によります）。

　これと同様のことを実際のECUは行っています。つまり、協調制御によってエアコンのスイッチが入ったことを検知し、スロットルバルブの開度を調整してから、エアコンのコンプレッサをオンにします。このスロットルバルブの開度調整やタイミングは相似形（1000cc→2500cc)で自動的に決まるものでありません。各種部品の特性で変わってきます。つまり、データに関しては個別のセッティングが必要になります。

　この例ではエンジンだけに目を向けていますが、エンジンは自動車の主要な部品ではあるもののその1つにすぎません。自動車の持つ物理的な特性は、エンジンだけで決まるのではなく、ボディの構造、車体重量やエンジンを構成する部品の特性によって変化してきます。これらの要素を全てデータとして、コード（アルゴリズム）に入力して初めて自動車としてのシステムが成立することになります。

「持ち味」の一例

　適合プロセスの機能は以上の通りですが、実際にガソリンエンジンのECUに「持ち味」を加えるにはどうすればよいのでしょうか？よく、「ホンダらしい」とか「やっぱり、トヨタだよな、この感じは」と言ったりします。そういうものはどこで決まるのでしょうか？あるいは、ファミリーカーとスポーツカーのドライブフィーリング（味）の違いは？これらに対する答えの一例が下の図2になります。

図2　エンジンのトルクマップ。左がファミリーカーで、右がスポーツカーである。（クリックで拡大）出典：イータス

　このグラフは3次元マップになっています。入力として、X軸が「エンジン回転速度（回転数）」、Y軸が「ペダル踏度」になり、Z軸の「要求トルク」が出力になります。2つあるグラフのうち、左側のファミリーカー側が要求トルクのカーブがなだらかであるに対して、スポーツカー側はペダル踏度の割合が大きくなるにつれて（奥に行くほど大）、要求トルクが急峻に立ち上がっているのが分かり皆さんもます。

　つまり、踏度があるレベルを超えると「ガツン」とした加速感が味わえるわけです。これはペダル踏度に対応する要求トルクの急峻さの角度や位置をどのように決めるかで、同じ「ガツン」でも味付けが少しずつ変わってくることになります。このように与えるデータとタイミングの積み重ねによって「味」が決まってくるわけです。

「適合」と「ROMチューン」の違い

　自動車好きの人と会話していると、「じゃ、適合ってROMチューンと何が違うの？」という質問を受けることがあります。

　ROMチューンとは、ECU内部のデータを書き換えて、自分好みの味付けにすることを言います。データを調整して出力特性を変化させるという意味では、適合とROMチューンに違いはありません。しかし、データを調整するための目的は全く異なります。

　適合は、自動車を量産製品として最適な状態に仕上げることを目指して行うものです。一方ROMチューンは、自動車の所有者が自分好みの味にすることです。自分が好きだからと言って、塩分の強い濃い味付けにしていると身体に変調をきたすことがあります。これと同じで自分でよかれと思ってやっているROMチューンは、エンジン、ひいては自動車自体の寿命を縮めているかもしれません。いわゆるトレードオフになっていることは言を待ちません。

　次回の後編では、車載システム開発における適合プロセスの変遷や、適合プロセスに用いるツール、適合プロセスの今後について解説します。お楽しみに！

＜取材協力・資料提供：イータス＞

プロフィール

大橋　修（大宮技研合同会社　エグゼクティブエンジニア、産業技術大学院大学）

日本精工（株）でエアバッグの制御ソフトウェア開発、ボッシュ（株）にてエンジンマネージメントシステム開発、適合ツールの開発・サポート、プロジェクトマネージメント、ノキアにてシンビアンOS用ミドルウェアS60の開発や画像処理の研究などを担当。その後、外資系半導体会社勤務を経て現職。原稿執筆、システム開発、コンサルテーション業務を行う。

大宮技研のWebページ

関連キーワード

エンジン | ECU | 自動車 | 開発プロセス | 適合プロセス

AUTOSARで変わる車載ソフトウエア開発
車載ソフトウエアの標準規格AUTOSARの採用に向けた活動が活発化している。規格策定の中心地となっている欧州では、AUTOSAR準拠の車載ソフトウエアを採用した新車が発売されるなど、取り組みが先行している。一方、AUTOSARへの対応が遅れていると言われていた日本でも、JasParの評価活動をはじめさまざまな取り組み事例が報告されるようになった。本稿では、まず既存の車載ソフトウエアとAUTOSAR準拠の車載ソフトウエアの違いについてまとめる。その上で、欧州と日本におけるAUTOSARの実装に向けたさまざまな取り組みを紹介する。
本格化するEV/PHEV開発
国内自動車メーカーによる電気自動車/プラグインハイブリッド車の量産に向けた取り組みが本格化している。すでに、三菱自動車と富士重工業は電気自動車の量産を開始しており、2009年末からはトヨタ自動車がプラグインハイブリッド車を、2010年秋には日産自動車が電気自動車の量産を開始する予定である。本稿では、まず『第41回東京モーターショー』に出展された電気自動車、プラグインハイブリッド車、各自動車メーカーの開発姿勢についてまとめる。その上で、電気自動車開発に向けた半導体メーカーと開発ツールベンダーの取り組みを紹介する。
「機能安全」の導入で何が変わるのか？
自動車向けの機能安全規格ISO 26262の策定作業が最終段階に入った。この規格では、機能安全を実現し、それを証明するために必要となる開発プロセスが定められる。では、その新たな開発プロセスは、従来の開発プロセスとどのように異なり、それを適用する際にはどのようなことが課題になるのだろうか。本稿ではまずこの点を明らかにする。加えて、機能安全を実現する上でポイントとなるマイコンについて、各メーカーの取り組みの様子を紹介する。