⁠
⁠30年ほど自動車メーカーでエンジニアをやっています。ここ数年会社外での活動が増えてきたのですが、自動車会社を外から見直すと、新たな気づきが得られたりもします。「自動車メーカーの開発現場から」では自動車に関わる「軽めな」こぼれ話をご紹介できればと思っています。

先日、娘のPCが動かなくなったというのでちょっと見てみると、Windows PCのはずなのになぜかUbuntu（オープンソースのLinux系OS）のブートローダーが起動できずにコケていました。

「もしかしてデュアルブートにした？」と聞くと、「そうだけど、これまでWin10でちゃんと両方使えていたのにWindows 11にしたら動かなくなったんだ」という。

「いやー、OSごとに物理ドライブ分けてインストールしたほうがいいんじゃない？　同じHDDでLinuxと共存とか度胸ありすぎだろ」というと、知り合いに教えてもらって、「その人はちゃんと使えているよ」と娘。

「うん、これからはその人に聞いてね」……などとは言わず、さっさとリカバリしてWindows 11を動くようにして一件落着です。個人のPCなら、こんな感じでも良いのですけどね。

当然ながら、自動車開発では、そうはいかないわけです。

自動車開発は安全が最優先

鉄の塊だった自動車に、電子制御システムが搭載され始めたのは1970年代、厳しくなった排ガス規制に対応するため、エンジン制御に用いられたのが始まりだったと聞いています。筆者が初めて電子制御に触れた頃は、試作のプログラムは紫外線で消去できるUV-EPROMやEEPROMに入れて開発し、テストベンチや実車試験をこれでもかというくらい繰り返してバグ出しして、OKとなれば書き換え不可のマスクROMにして量産という流れでした。当時のプログラムはソースコードが数千行、メモリのサイズも16KBとか32KBとかで、アセンブラやC言語で書いてましたし、機械語を読みながらそのままデバッグするような強者（つわもの）もいました。

1990年代後半には自動車のユニット同士が通信回路で接続されるようになって制御も複雑さを増し、サイズも1MBを超えてきました。開発規模が徐々に大きくなる一方で、コストを削減するため開発期間は短縮したいという動きが出始めます。このあたりは個人的な見解で、諸説あるのでしょうが、短期間ではソフトウェアのバグを取り切れなくなってきたのかもしれません。

マスクROMにバグがあれば在庫含めて部品は破棄ですから、絶対にバグが出るはずだという前提で、マスクROMよりも高価だが販売後に書き換え可能なフラッシュROMが搭載され始めました。当初はフラッシュによる書き換え（リプログラム）も、マスクROMを捨てるよりはマシだろうという「やむを得ず」感があったと思うのですが、そのうちにリプロによって不具合修正が早期化できるというメリットから、積極的に使われるようになりました。それでもまだ、ソフトウェアは基本的に1社で開発し、バグが出てもすぐに対応できる体制に変わりありませんでした。安全も品質も積み重ねですから、慣れ親しんだ開発プロセスを変えるようなことには抵抗感があったのかもしれません。

Linux、お前もか

前回触れましたが、携帯電話のように自動車メーカー側から中身が見えないような外部デバイスとの接続は一筋縄ではいかないこともあります。「スマホとつなぐ」だけでも大変なのに、「電子ユニットの中にオープンソースのOSを入れる」なんて、どうかしてると思いませんか？（笑）

とはいえ、自動車の「走る曲がる止まる」という基本的で最重要な機能を司るユニットも、2000年代になるとそれまでの独自OSからリアルタイムOS（RTOS）を採用し始めました。これはOSを開発するメーカーがきちんとコア部分を固めた上で、それぞれの用途に合わせてカスタマイズしている商用OSで、これまでの延長線上で開発を進めることができたように思います。

もう1つは、ネット接続や音楽再生など情報系、エンターテインメント系（インフォテインメントと言います）の採用拡大に伴って搭載されるようになったLinuxです。最初に搭載が決まるころ、既存のリソースが活用できるとかオープンソースだとか安定性も高いとか、ほぼメリットしかないという説明を聞いた記憶があるのですが、当時の自動車メーカーエンジニアにとって、Linuxを自動車に搭載するのは未知の領だったと思います。

ご存じの方も多いと思いますが、Linuxのコアであるカーネルはオープンソースを支えるコミュニティによって継続的に開発されており、日々世界中でさまざまな機能追加や修正が加えられています。そのカーネルや周辺ドライバやライブラリなどをまとめたディストリビューションという形で利用するのですが、Linuxを載せたコントロールユニットがソフトウエアを更新したら急に動かなくなって実験が止まり、大騒ぎになったことがあります。

サプライヤさんがすぐに持ち帰って調査し、しばらくして原因が分かったのですが、一部のソフトウェアがタイムスタンプが違う「別物」に変わっていたらしく、以前のバージョンに差し替えたら正常に動作したようです。1社開発だったらまずあり得ない状況ですが、誰でも触れるオープンソースだとこうした見逃しが致命的なエラーの原因になったりします。

実験する側は、動かなくなるたびに「安定性高いんじゃなかったのかよ」と言いたくもなるのでしょうが、使い方が悪い、バージョン管理ちゃんとしろ、と言われて終わりです。開発中は「パソコンみたいにフリーズしたらリセットしてもらおう」と、冗談か本気か分からないような愚痴を現場でよく聞きました（笑）

SDVに向けて

ここ数年の動きの中心には、ソフトウエア定義車両（SDV）があります。ソフトウエアの生産性も飛躍的に高まり、車載電子機器に使われているソースコードは数億行とも言われ、30年前には予想もしなかった方向を目指しています。いろいろと大変な思いもしたあのLinuxも、ディストリビューション企業などと協力しながらAutomotive Grade Linux（AGL）で自動車用途にちゃんとフォーカスして利用できるようになりました。

SDVを見据えて、ネットワーク経由で車載ユニットのリプロが可能なOTA（Over The Air）も導入されつつあり、「自動車のスマートフォン化」が加速しています。ただ、「走る曲がる止まる」が最重要であることには変わりなく、SDVだからといってPCやスマホアプリのように「フリーズしたらリセット」はできません。

当初は便利機能扱いだったナビゲーションも、自動運転でITSに組み込まれ従来以上の品質確保が必須となっています。今となってはソフトウェアを1社で開発することも、その中身をすべて把握することも到底不可能ですが、安全面での性能低下を招かないようロバストな設計開発が求めれていると思います。

⁠