TOYOTAの組込みソフトウェアに関するリスク

トヨタ自動車は2005年度決算説明会で、2006年度はECU（電子制御ユニット）統合によるコスト低減活動を重視するとの方針を示した。（日経BP Tech-onの記事はこちら。無料の会員登録をしないと見られないので注意）

キター！という感じた。なにが「キター！」なのかというと『組込みソフトエンジニアを極める』の中で、これまでハードウェアとソフトウェアをセットにして機能分散してきた組込みソフトの作り方を、コスト削減のために機能集中的にしていくと、ソフトウェア品質を低下させるいろいろな危険が増えるよ、という主張をしているからだ。

左の図は『組込みソフトエンジニアを極める』の第二章－機能分割のハードルを越える－の中に出てくる図2.1 機能分散型と機能集中型の違いの図だ。

実はこの図の上は、自動車のEUC（Electronic Control Unit：電子制御ユニット）を想定していた。今自動車には100個以上のCPUが使われており、左右のドアミラーの制御にも一個ずつCPUが使われていると聞いたことがある。tech-onの記事にかかれているのは、ECUシステム（機能単位でCPUの数ではない）約60個を、複数のECUを一体統合化して標準4群に統廃合するというものだ。

もちろん、CPUの数が4個になる訳ではないが、ソフトウェア側から見れば機能分散的な作り方が機能集中型になるのは間違いないと思う。

このような機能分散から機能集中に移行する傾向は、自動車だけでなく、他の業務ドメインでも起こっている。

その原因はCPUの高性能化とコストダウンの目的からだ。CPUがムーアの法則（CPUの性能は18ヶ月～24ヶ月で2倍になるという経験則）によりどんどん高性能になるのだから、一個のCPUに機能を集中させてコストダウンしようと考えるのは当然だ。

しかし、ここには大きな落とし穴がある。CPU（ソフトウェア）とハードウェアが一体となって機能を担っていたときは、ソフトウェアエンジニアとハードウェアエンジニアが同じ土俵で仕事をしており、不具合が発生してもハード、ソフトに問わずエンジニアが顔をつきあわせて問題の解明に当たることができる。

ところが、機能集中型の作り方になると、ひとつの巨大なソフトウェアに対して、複数のハードウェアがぶら下がることになり、ハードウェアエンジニアはソフトウェアとのインターフェースだけをチェックして「後はよろしくね」というパターンになりやすい。どこで何をやっているのかわからないくらいソフトウェアが巨大化してているからしょうがない。

そのような状況になると、ソフトウェアの中身がどんどん見えなくなってくる。結局機能集中型の構造にしたとしても、いかにソフトウェアの中身が機能分割されてその分割が見えるようになっているかどうかがソフトウェアの信頼性や安全性に直結することになる。

ただ、『組込みソフトエンジニアを極める』で何回も繰り返したのは、ソフトウェアによる機能分割を優先させたことにより、時間分割（リアルタイム性、応答性）を犠牲にしてしまっては日本の組込みソフトのよさや強みを殺してしまうことになるということだ。

自動車のECUの場合は、これまで機能分散型でいかにネットワーク上で問題が起こらないようにするかに関心が集まっていたが、トヨタがコストダウンのため機能集中・機能統合をめざしたことによって、ソフトウェアの中の機能分散、独立性の確立に注目が集まるようになるだろ。

冒頭の記事の表面的な部分だけ見て、「コストダウンのためにCPUを一個にしろ！」などという経営者が出てくると後でひどいことになりかねない。