図1

　前回紹介したインフォテイメント系はまだまだいろいろ話があるのだが、今回はちょっと趣旨を変えて、コンサバティブ（と思われている）なECUの話。俗にEFI（Electrical Fuel Injection）、以前はECU（Engine Control Unit）なんて言われていたものの話である。

　さて、きわめて初期のEFIの構造を簡単にまとめたのが図1である。本当はエンジンからは複数のデータが来るのだが、まぁ簡略化して今回は回転数のみを取得していると想定しよう。この場合EFIに入るのは

• アクセルペダルの開度センサー（アクセルを全く踏み込んでいない状態から、完全に踏み込んだ状態までを、ペダルの位置情報として捉え、これを信号の形で送り出すもの）出力
  
• エンジン回転数
  

ということになり、この情報を元にインジェクターへの制御を行わせるという仕組みである。以前の記事（http://car.watch.impress.co.jp/img/car/docs/471/865/html/p2.jpg.html）を見ると、1970年台に入ってエンジンがそれまでのキャブレターからインジェクターを使った燃料噴射方式に変わり、これに合わせてEFIが導入されたようである（EFI以前にも完全電気制御や、更にその前には機械式によるインジェクター制御の例もあるが、一般的に広まったのはやはり電子式のEFIと組み合わせてからだと筆者は記憶している）。

　こうしたものの構造は簡単である。図1のケースなら、まず開度センサーとエンジン回転数のセンサー出力を（適当な電圧変換などを行った後に）ADC（Analog/Digital Converter）という回路を通してデジタルデータ化し、それをEFI内部のMCU（Micro Controller Unit）に内蔵されたCPUコアに送り込む。CPUコアはこの2つのデータを元にLUT（Look Up Table）と呼ばれるデータから出力データを決定し、これを出力する。この出力結果はDAC（Digital/Analog Converter）という回路を経てアナログ信号になり、インジェクターに引き渡される形だ。

　実はこの処理は非常に高速である。LUTというのは要するに「参照テーブル（表）」のことである。論理的には図2の様に、回転数とアクセル開度の2つで、テーブルのある一要素（赤い部分）が特定できることになる。

　CPUは実はこうした処理が大変に得意であり、1970年前後に存在した8bitのCPUでも数十サイクル、最近の8bit CPUならば数サイクルでテーブル参照ができる。「サイクル」というのはCPUが動く時間の最小単位で、例えば2MHzで動くCPUならば、1サイクルは0.5μ秒ほどになる。仮に100サイクルと仮定しても、処理に必要な時間は0.05ミリ秒ほどになる計算で、1秒間に2万回ほどこれを繰り返すことができる。これは、この当時の車のエンジンには十分な性能だった。

　勿論これだとパラメータが2種類しか使えないことになるが、このテーブルを3次元以上に拡張することそのものは難しくない。具体的には図3の様に、テーブルを複数用意して、3つ目のパラメータに合わせてテーブルを選び、その中でさらに最初の2つのパラメータに合わせてデータを選ぶ形になる。もっと多数の、4次元とか5次元にすることも原理上は簡単だ。

図2	図3

　このLUTの中身が、俗に「デジタルマップ」と呼ばれる部分である。グラフ1～3は、例えばアクセル開度とエンジン回転数に応じて、どう燃料噴射率を変更するかを適当にシミュレーションした例である。

　グラフ1が比較的中庸な設定、グラフ2はかなりリーン気味、逆にグラフ3はかなりリッチ気味にしている。勿論このデータをそのまま車に持っていってもまともに走らないとは思うが、重要なのはこんな具合にいとも簡単にパラメータが変更できることである。

グラフ1	グラフ2	グラフ3

　通常はメーカー内で開発を終えると、それを後から書きかえられない「マスクROM」と呼ばれるメモリチップに焼きこんで、そのままEFIを出荷するという形になるが、これを後から書き換え可能な「EEPROM」というメモリチップにコピーして差し替えることで、マップの傾向とか細かいパラメータを書き換えできる、なんて話を聞いたことのある読者も多いだろう。あるいはレース用のエンジン向けのEFIだと、最初から書き換えを前提にしており、さらに書き換えを行うためのツールまで提供されることも珍しくない。

　さて、ここまでの話は1980年代か、遅くても1990年代くらいまでの話である。最近のEFIでデジタルマップをまだ採用している、なんてケースは筆者が知る限りほぼ皆無と言ってよい。何でかといえば単純な話で、パラメータが多すぎてテーブルで収まりきらないからだ。例えば最近の車のEFIでは

• アクセル開度
  
• 空気流量ないし空気流速
  
• 酸素濃度
  
• エンジン回転数
  
• エンジン温度
  

あたりは間違いなく燃料噴射量を決定するためのパラメータとしてセンサーから取り込んでおり、しかももっと段階が細かい。

　例えばグラフ1～3は回転数を1000～8000rpmまで500rpmというラフな段階で区切ったが、最近はこれが100rpm刻みだったりする。同様にアクセル開度も10段階よりもっと細かく取得している。まぁ言い始めるとキリがないので、仮に上の5つのパラメータをそれぞれ32段階で取得し、結果も32段階で出力するものと考える。なんで「32」かというと、CPUが扱うには2のべき乗（2・4・8・16・32・64……）に揃っているのが便利だからで、64とか128でもいいのだが、レース用ならともかく一般の乗用車ならまぁ32段階程度だろう、という見積もりだ。この場合、テーブルのサイズは

32×32×32×32×32×32＝1,073,741,824bit＝134,217,728Bytes＝128MB

となる。はっきり言えば、こんな大きなサイズのテーブルを、メモリとして格納するのはまず無理である。「最近のスマートフォンなら16GBとかのメモリを搭載してるじゃない」という声がありそうだが、スマートフォンなどで使われているフラッシュメモリは「まとめてあるブロックをガバっと読み込んで返す」というタイプのものなので、平均速度としては十分速いのだが、「ある値を読みに行ったらまだ読み込まれてなかった」なんて場合、しばらく待たされることになる。

　EFIでは、毎秒数百～数千回（最近のディーゼルエンジンで使われているコモンレールの場合は数万回）の頻度でずーっとテーブルをアクセスするから、「読み込みが追いつかないので待ってください」という訳にはいかない。だいたいフラッシュメモリが大容量化したのもここ数年の話であって、昔はこんな大容量のメモリを実装する方法がそもそもなかった。

　それにトータルで3350万もの項目のテーブル（＝32^5）に、データを埋めるという作業がまず大変である。実車の上でデータを取るとかは不可能な分量だし、シミュレーションだって不可能だろう。そんなわけでテーブルを使った、いわゆる「デジタルマップ」方式が使われたのは1980年代半ばまでであって、その後はTransfer Function（伝達関数）を使ったものを経て、1990年代後半からは「モデル制御」と呼ばれる方式が利用され始めている。特に初期は「平均値モデル」という静的なものを使っていたが、最近は動的モデルを使ったものになりつつあるようだ。

　伝達関数というのは何か？　と言うと、入力に対してどういう出力があるか、を関数で定義するというもの。例えばグラフ2の場合、式1の様な関数を（適当に筆者の判断で）でっちあげて描画している。

式1

　テーブルベースの場合は、この関数の結果を計算して、その結果をテーブルに入れる形になるが、伝達関数の場合は入力されてきたセンサーの値を元に、リアルタイムにこの関数の計算を行って燃料噴射率を決めるという方式だ。これならば、関数さえ決まれば、パラメータがいくら多くなっても大丈夫である。

　モデルベースというのはもっと先を行った話である。ここではエンジンの中の様々な物理現象（例えば空気の流れ方や燃料の拡散しかた、着火から炎の伝播の仕方といったもの）をすべて数値モデル化し、このモデルを元に燃料噴射制御を行ってゆくというものである。

　この伝達関数やモデル制御を使う場合、EFIの内蔵CPUには高い性能が求められる。特に制御の場合、計算精度も問題になるため、整数演算のみでは不十分で、浮動小数点演算機能が搭載される場合もある。要するに小数以下切捨てで計算していると精度が足りなくなるので、小数を扱えるようにするということだ。この結果として、1980年代あたりまでのEFIは8bitもしくは16bitの小規模なMCUで足りていたのに、1990年以降はかなり高速な32bit MCUが半ば必須となりつつある。

　ここまでの説明では、「え、でもまだデジタルマップ使ってるじゃない」とか「んじゃサブコンは？」という疑問を持たれる方もおられよう。そのあたりは来月をお楽しみに。