自動車の組込ソフトウェア開発が難しい理由は3つある

自動車の組込ソフトウェア開発の現場を見ると、とても難しいなと思う。
第三者視点で考えたことをメモ。

【参考】
自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

システムズエンジニアリングに基づく製品開発の実践的アプローチ | 後町智子, 土屋浩幸, 鈴木　研 |本 | 通販 | Amazon

図解カーエレクトロニクス 上 システム編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

図解カーエレクトロニクス 下 要素技術編 増補版 | デンソー カーエレクトロニクス研究会, 加藤 光治, 日経Automotive Technology |本 | 通販 | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] エンジニアリングセット | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

Automotive SPICE 4.0 実践ガイドブック[入門編] 管理支援 | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

ISO26262 2nd実践ガイドブック［エンジニアリングセット］ | ビジネスキューブ・アンド・パートナーズ | 車・バイク | Kindleストア | Amazon

詳解 車載ネットワーク -CAN、CAN FD、LIN、CXPI、Ethernetの仕組みと設計のために- | 藤澤行雄, 品川雅臣, 高島 光, 村上 倫, 石本裕介 |本 | 通販 | Amazon

【1】自動車の組込ソフトウェア開発を現場で見ていると、皆いつも忙しそうにしている。
基幹系システム開発の時よりも大変なように見える。

組込ソフトウェア開発の初心者である僕から見て、ハードとソフトを組み合わせて正常動作させることすら、根本的に難しいように思う。
業務系Webシステムの設計・開発・保守を経験した僕が見て、ハードと一体化したソフトウェア開発は、ハードレベルに近い知識も必要。
相当大変なように思える。

また、自動車にも自動運転のように、AIを使った機能追加は当たり前になった。
おそらく、どのOEMメーカーも、どの部品メーカーも、AIを使った新機能の開発、さらには研究開発に相当のリソースを投入しているはずだ。
もはやハードウェアに付加価値はないので、ソフトウェアでいかに付加価値を上げるか、にビジネスモデルの力点が移動している。
しかし、AIの開発は、組込ソフトウェアやWebシステムとは異なる異次元の専門知識も必要なので、習得のハードルも高い。

さらに、自動車の製造には、数多くのISO規格の認証が必要だ。
なぜならば、民生品と言えども、人命に関わる製品なので、人命第一の品質保証が問われるからだ。
数多くのISO規格の監査を踏んで承認が得られなければ、そもそも販売できない。

そんな状況を踏まえると、自動車の組込ソフトウェア開発が難しい理由は、3つあると思う。

【2】１・ECUというハードとソフト双方を結合した部品を作った後に、さらに複数のECUを統合して初めて1台の自動車が完成するので、結合・統合テストで非常に苦労する。

そもそも、ECUとは、車載の電子制御装置（Electronic Control Unit）の略。CPUが10個ぐらい搭載されていて、ハード部品と組込プログラムから成る。例えば、エンジンECU、ブレーキECU、エアバックECU、自動運転ECUなどがある。一般に、デンソーのようなTier1メーカーが製造し、OEMメーカーであるトヨタ、ホンダに納品し、OEMメーカーが20～50個くらいのECUを結合して1個の自動車を作る。

Geminiでは、下記の解説があった。
車ECU（Electronic Control Unit）は、自動車のエンジン、ブレーキ、エアバッグなど様々なシステムを電子的に制御する「車載小型コンピューター」です。センサーから得たデータをもとに最適な動作を計算し、1台の車に約100個搭載されることもあります。現代の車には不可欠な「頭脳」です。
ECUの主な特徴と役割
役割（自動車の「頭脳」）: エンジンの燃料噴射・点火制御、ブレーキ（ABS）、パワーステアリング、車線維持支援など、安全・快適・性能を包括的に管理します。
構成: マイクロコントローラ、メモリー（ROM/RAM）、入出力インターフェースで構成され、厳しい耐熱・耐振動設計が施されています。
連携: 車載ネットワーク（CAN）を介して、それぞれのECUが連携して動作します。
種類: エンジン系、シャシー系、ボディ系（ライト、ドア）、情報系（ナビ）など、機能ごとに分散しているほか、これらを統合する「統合ECU」の採用も進んでいます。
近年は、自動運転や電動化の進展に伴い、より高度な処理能力を持つECUの重要性が高まっています。

つまり、ECUに組み込むソフトウェアのテスト、ECUというハードとソフト自体の結合テスト、さらには複数のECUを組み合わせた1つの自動車という統合テストという多段階のテストが必要。
Webシステムのような単純なテストモデルではない。

また、彼らのテスト作業を見ると、回這う現場にはECUというハードの台数が少ないので、ECUのテスト時間を予約して、その間にテストしてバグ出ししている。
ECUというテスト機器も1チーム1台ではなく、複数チーム1台しかないので、テスト機器の確保が大変みたい。
すなわち、ハードに縛られたソフトウェア開発では、テスト対象のECUというハードウェアが作業のボトルネックになりうる。

【3】２・自動運転（AD）や走行制御（ADAS）のように、全てのECUに指示制御する統合ECUが初めて出現したために、従来のハード中心のゾーンアーキテクチャからソフトウェア主導のアーキテクチャに変わったので、ソフトウェア開発力が弱いメーカーは非常に苦しいと思う。

Geminiに聞くとECUのアーキテクチャには、ハードの名残りから進化した歴史がある。

自動車の脳にあたる「コンピューター（ECU）」の配置ルールは、進化とともに3段階あります。
・ドメイン型：役割ごとのチーム制。「走る」「止まる」など機能別に脳を分ける方式です。機能が増えるほど配線が複雑になり、車が重くなるのが弱点です。
・ゾーン型：場所ごとのエリア制。「右前」「後ろ」など車の場所で脳をまとめます。近くの部品を最短の配線でつなぐため、線を劇的に減らして軽量化できます。
・セントラル型：一極集中制。車の中央に超高性能な「1つの脳」を置き、全てを指揮します。スマホのようにソフトの更新だけで車の性能を後から進化させやすくなります。
現在は、配線を減らしつつ高度な制御を行うため、2と3を組み合わせた形が主流になりつつあります。

つまり、最近では、自動運転（AD）や走行制御（ADAS）が全てのECUを指示・制御する必要がある。
そのために、ADやADASの機能を持つ統合ECUが必須となるセントラル型アーキテクチャが主流になっていると思う。
ハード面でもソフト面でもアーキテクチャ設計が以前よりも遥かに重要な印象。

昔は、トヨタやホンダが「ハードの部品のすり合わせ」により1つの自動車を作っていた印象。
しかし、今は、SDVという「車のAPI化やOTAでソフトウェアによるハード制御などの実装に近い設計手法」になったために、
20～50個ものECUを結合して、性能、品質、セキュリティなどを担保するのは、昔ながらの「すり合わせ」では実現不可能。

「すり合わせ」という複数チームのコミュニケーション活動による解決ではなく、ハード面でもソフト面でも「アーキテクチャにより自動車の構造をすり合わせる」へ時代が変わったと考える。
だから、MBSEのような「アーキテクチャ主導の製品開発」が重要になってきたと考える。

【4】３・A-SPICE、機能安全、サイバーセキュリティのような監査プロセスを踏んで品質担保を保証する必要がある。
ソフトウェア開発チームはソフトウェア開発だけでなく、監査ドキュメント作成の作業負荷も増えている。
これらの規格をOEMメーカーがTier1の部品メーカーに要求するため、開発現場はいつも人手不足で作業が大変な印象。

その問題点は下記に書いた。

自動車業界におけるA-SPICE・機能安全・サイバーセキュリティの規格に対応したプロセス改善とは何か？: プログラマの思索

【5】自動車のソフトウェア開発が面白いなと思う点は、元々、ハードとソフトを組み合わせるので難易度が高い上に、MBSEのようなアーキテクチャ主導のソフトウェア開発が必要になったこと、更には、A-SPICE、機能安全、サイバーセキュリティのようなISO規格遵守も必要になったことにより、他のシステム開発よりも複雑かつ難易度が高い点だ。

一方、他の製造業の業界に比べると、トヨタを頂点とした自動車業界は品質面でもプロセス面でも優れているので、彼らの考え方を理解できれば、他の製造業を富士山から眺めるような観点で見下ろして、強みや弱みを比較分析して把握できるだろうと思う。
たとえば、家電、機械製品、化学、医療、食品加工、防衛産業などの製造業を比較評価することで理解しやすくなると思う。

その辺りも色々考えてみたい。