小説で学ぶ自動車ソフトウェア開発 (その8) AUTOSAR
本エントリーは、小説で学ぶ自動車ソフトウェア開発（車載ソフトウェア開発）のシリーズものです。
小説で学ぶ自動車ソフトウェア開発 (その3) A-SPICE (1)
小説で学ぶ自動車ソフトウェア開発 (その4) A-SPICE (2)
小説で学ぶ自動車ソフトウェア開発 (その5) ISO26262とASIL
小説で学ぶ自動車ソフトウェア開発 (その7) SDV・OTA
前回の「その7」では、Part 4としてSDV・OTAの世界を見てきた。
車は、もはや工場を出た瞬間に完成する製品ではない。出荷後もソフトウェアによって機能が追加され、バグが修正され、安全性が高められ、場合によってはAIモデルそのものが更新されていく。SDVの時代において、OTAは単なる便利機能ではなく、車を継続的に進化させるための基盤である。
しかし、OTAで安全に更新するためには、その前提として、車載ソフトウェアが適切に分割され、標準化されたインタフェースで接続され、どの機能をどこまで更新できるのかが明確になっていなければならない。
そこで登場するのが、Part 5で扱う AUTOSAR である。
現代の自動車は、1社だけで作られているわけではない。OEM、Tier1、Tier2、半導体メーカー、ツールベンダー、ソフトウェア企業など、数多くの会社が関わり、それぞれが作ったソフトウェア部品を一台の車の上で動かしている。もし各社が独自のインタフェース、独自の通信方式、独自の実装ルールで作っていたら、それらを統合することはほとんど不可能になる。
AUTOSARは、その不可能に見える課題に対する、自動車業界の答えだった。
今回の「その8」では、主人公の成田剛志が、Classic AUTOSARとAdaptive AUTOSAR、SW-C、RTE、BSW、そしてゾーンアーキテクチャへと進む車載ソフトウェア基盤の世界を学んでいく。
Part 5 AUTOSAR ―― 車載ソフトの共通言語
100社が作るソフトを、1台の車に乗せる。
その不可能に見える課題を解いた人たちの発明が、AUTOSARだ。
第35章 なぜ「共通言語」が必要だったか
AUTOSAR.001：AUTOSARとは何か ― 誕生の経緯と基本概念
Part 5の担当は泉谷さんだった。ある朝、泉谷さんは会議室のホワイトボードに2つの図を描いた。
一つは「AUTOSARなし」の図。100社のサプライヤーが、それぞれ独自のAPIで、独自のデータ形式で、独自のスケジューリングで、それぞれのECUに載るソフトを作っている。ある会社のブレーキSW-CとADASのSW-Cを同じECUに統合しようとしたとき、インタフェースが全く合わない。再設計が必要になる。
もう一つは「AUTOSARあり」の図。全社が同じポートとインタフェースの仕様に従ってSW-Cを作る。ポートの向きと型さえ合えば、誰が作ったSW-Cでも接続できる。レゴブロックのように組み合わせられる。
「これがAUTOSARの発明の本質だ」と泉谷さんは言った。
「AUTOSARはAutomotive Open System ARchitectureの略。2003年、BMW、Bosch、Continental、Daimler、Ford、GM、PSA、Volkswagen、Siemens VDO（後にContinentalに吸収）の9社がCore Partnerとして共同で設立したコンソーシアムが策定した、車載ソフトウェアのアーキテクチャ標準だ。後年Toyotaが加入して10社体制になった」
「なぜこれが必要だったか、歴史的背景を少し話す」
「1990年代〜2000年代初頭、車に乗るECUが急増した。ECUが増えると、それぞれの上で動くソフトウェアも増える。そして複数のサプライヤーが別々の車両プラットフォーム向けに同じような機能を別々に実装する、という無駄が爆発的に起きていた」
「推定では、当時の車載ソフトウェア開発の70%が"既存機能の再実装"だったと言われる。OEMもサプライヤーも、同じ車輪を何度も発明し直していた」
「AUTOSARはこれを解決するために、"基盤ソフトウェア（BSW）"を標準化し、"アプリケーション層（SW-C）"を再利用可能にした。ソフトウェアが"plug and play"できる世界を作ろうとした」
用語
AUTOSAR（AUTomotive Open System ARchitecture）：車載ソフトウェアのアーキテクチャ標準。2003年にBMW・ボッシュ・コンチネンタル等が設立したコンソーシアムが策定。SW-Cの標準インタフェースと基盤ソフトウェア（BSW）の標準化が核心。Classic（従来型ECU向け）とAdaptive（高性能ECU向け）の二系統がある。
その日のノート。
剛志のノート（35）
・AUTOSAR＝車載ソフトウェアのアーキテクチャ標準（2003年〜）。
・誕生の背景：ECUが増えるにつれ、「同じ機能を各社が別々に実装する」無駄が爆発。
・発明の本質：SW-Cの標準インタフェースと基盤ソフト（BSW）の標準化 → レゴブロック的接続。
・Classic（旧来型）とAdaptive（高性能ECU向け）の2世代。
・「車載ソフトの共通言語」：これがないと、100社の部品は一台の車に乗らない。
第36章 Classic AUTOSARの世界 ―― 積み重なった三層
AUTOSAR.002：Classic AUTOSAR ― 三層アーキテクチャと基盤ソフトウェア
「Classic AUTOSARのアーキテクチャを説明する」と泉谷さんは言った。「三層に分かれている」
泉谷さんはホワイトボードに積み重なる三つの層を描いた。
Classic AUTOSARの三層構造
┌──────────────────────────────────┐
│ Application Layer（アプリケーション層） │
│ SW-C（ソフトウェアコンポーネント）群 │
│ → 各サプライヤーが作る機能部品 │
├──────────────────────────────────┤
│ RTE（Runtime Environment） │
│ → SW-C間の通信を管理する「中間層」 │
├──────────────────────────────────┤
│ BSW（Basic Software）＋MCAL │
│ → OS、通信スタック、メモリ管理、診断 │
│ ＋ マイコン依存の抽象化層（MCAL） │
└──────────────────────────────────┘
「一番下のBSW（Basic Software）は、車載ECUが共通に必要とする機能の集合だ。OS、CANスタック、Ethernetスタック、FlexRayスタック、NVM（不揮発メモリ管理）、診断（UDS）、ウォッチドッグ管理、電源管理......これらを全部AUTOSAR仕様で標準化している」
「MCALはMicrocontroller Abstraction Layer。マイコン（ルネサスかインフィニオンかTIか）が違っても、BSWから見ると同じインタフェースに見える抽象化層だ。これがあるから、BSWは特定のマイコンに依存しない」
「真ん中のRTE（Runtime Environment）が重要だ。SW-CはRTEのインタフェース越しにデータをやり取りする。SW-C同士は直接通信しない。RTEがすべての通信を管理する」
「これがAUTOSARの"疎結合"の仕組みだ。SW-CはRTEとのインタフェースだけ知っていればいい。他のSW-CがどのECUに乗っているか、通信バスは何かを知らなくていい。RTEがよしなにやってくれる」
「一番上のアプリケーション層がSW-C群。センサーフュージョンSW-C、ブレーキ制御SW-C、ステアリング制御SW-C、HMI SW-Cなど。これらがRTEのポートで繋がって動く」
SW-Cのポートとインタフェース
「SW-CのポートはAUTOSARで型付けされている」と泉谷さんは続けた。「Sender/Receiver（データを送る/受け取る）ポートと、Client/Server（サービスを呼ぶ/提供する）ポートの二種類が基本だ」
「たとえば、センサーフュージョンSW-Cが前方物体の位置データを出力するSender-Portを持って、行動予測SW-CがそれをReceiver-Portで受け取る。ポートの"型"（データ型、レート、単位）が一致すれば、どのメーカーが作ったSW-Cでも接続できる」
「"型が一致すれば接続できる"というのは、Webサービスのいわゆるコントラクト設計に似てますね」と僕は言った。
「そうだ。Webで言えばOpenAPI Specがインタフェース定義に当たる。AUTOSARではARXML（Automotive Runtime XML）というXMLフォーマットでインタフェースを定義する。このARXMLをVector DAVINCI、EB tresos、DSSといったツールで読み込んでコード生成する」
その日のノート。
剛志のノート（36）
・Classic AUTOSAR三層：BSW（＋MCAL）→ RTE → Application（SW-C群）。
・BSW：OS、通信スタック、診断、電源管理など基盤機能の標準化。
・MCAL：マイコン依存性を抽象化。BSWは特定チップに縛られない。
・RTE：SW-C間通信の管理役。SW-Cはお互いを知らなくていい（疎結合）。
・SW-CのポートはSender/ReceiverとClient/Serverの2種。ARXMLで定義。
・"型が合えば接続できる"＝WebのOpenAPI Specに近い発想。
第37章 SDV時代のAUTOSAR ―― Adaptiveの登場
AUTOSAR.003：Adaptive AUTOSAR ― SDV・自動運転・OTAに対応した次世代アーキテクチャ
「Classic AUTOSARは偉大な発明だ。でも、2010年代に入って限界が見えてきた」と泉谷さんは言った。
「何が問題だったか。Classic AUTOSARは、組込みリアルタイムOSの上で動くことを前提にしている。マイコンのRAMは数MB、処理能力はMHz単位。そこにカメラ映像を処理するNNモデルは乗らない」
「でも、自動運転・ADAS・OTAには高性能プロセッサが必要だ。NVIDIAのOrin、クアルコムのSA8295P、ルネサスのR-Car Ultra。これらはLinuxやAOS（AUTOSAR Adaptive OS）の上で動く。古いClassicのRTEとBSWでは対応できない」
「そこで2017年から公開が始まったのがAdaptive AUTOSARだ」
ClassicとAdaptiveの違い
泉谷さんはホワイトボードに二列の比較表を書いた。
Classic AUTOSAR：
OS：AUTOSAR OS（OSEK/VDX系、リアルタイム）
処理能力：マイコン（数十MHz〜数百MHz、数MB RAM）
通信：COM（AUTOSAR内部通信）+ CAN/LIN/Ethernet
アプリ統合：コンパイル時静的統合
OTA：ECU全体書き換え
用途：エンジン制御、ブレーキ、ステアリング等のリアルタイム制御
Adaptive AUTOSAR：
OS：POSIX準拠（Linux等）
処理能力：高性能SoC（数GHz × 多コア。例：NVIDIA Orinは12コア前後、数GB〜数十GB RAM）
通信：SOA（Service Oriented Architecture）、SOME/IP＋ara::com（標準ミドルウェアAPI）。DDSはオプション扱いで、Adaptive AUTOSAR外でも広く使われる別標準
アプリ統合：実行時動的統合
OTA：アプリケーション単位で更新可能
用途：自動運転ECU（ADC）、インフォテインメント、OTA管理、ML推論
「"実行時動的統合"というのが、OTAとの関係で重要だ。Classicはコンパイル時にすべてのSW-Cを統合する。一度焼いたら変えられない。Adaptiveはアプリケーションを実行時に追加・削除・更新できる。これがPart 4で説明した"細粒度OTA"を可能にする技術的基盤だ」
「SOA（Service Oriented Architecture）というのは、Webサービスのような発想だ。各機能がサービスとして公開されて、他の機能がそれを呼ぶ。EthernetベースのSOME/IPプロトコルでサービスを動的に検出・呼び出す。Adaptive AUTOSARでは、アプリケーションから通信を扱う標準APIとして ara::com が用意されていて、SOME/IPの上にC++のサービス指向APIを被せている。これでアプリ側は通信プロトコルの詳細を意識せずにサービスを呼べる。これはWeb開発者には親しみやすい発想だよ、成田くん」
「確かに！ マイクロサービスのDiscoveryに似てますね」
「そうだ。車がWebアーキテクチャに近づいている。ただし、リアルタイム性と安全性の制約の中で」
その日のノート。
剛志のノート（37）
・Adaptive AUTOSAR（2017〜）：高性能SoC＋POSIX OS上で動くSDV時代のアーキテクチャ。
・ClassicとAdaptiveの違い：静的統合vs動的統合、マイコンvs高性能SoC、COM vs SOA。
・Adaptiveのキー技術：SOME/IP（SOAの通信プロトコル）、実行時サービス検出。
・「実行時動的統合」＝細粒度OTAの技術基盤。Part 4（OTA）との直接連携。
・Webのマイクロサービスに近い発想。車がWebアーキテクチャに近づいている。
第38章 ドメインアーキテクチャという革命
AUTOSAR.004：ドメインアーキテクチャとゾーンアーキテクチャ ― SDV時代のECU設計
「今日はアーキテクチャの話をする。ECUをどう配置するか、という話だ」と泉谷さんは言った。
「昔の車は"分散アーキテクチャ"だった。各機能に専用のECUがある。ドアロックECU、ウィンドウスイッチECU、ミラーECU、シートECU......。機能が増えるたびにECUが増えた。その結果、高級車には150個以上のECUが乗り、車内の配線だけで数キロになった」
「これを統合しようとした最初のステップが"ドメインアーキテクチャ"だ」
ボディドメイン（BCM：Body Control Module）：ドアロック、ウィンドウ、照明、シート
シャシードメイン：ブレーキ、ステアリング、サスペンション
パワートレインドメイン：エンジン/モーター制御、バッテリー管理
ADASドメイン：自動運転、エアバッグ、カメラ処理
インフォテインメントドメイン：ナビ、オーディオ、HMI
「ドメインごとに"ドメインECU"（または"ドメインコントローラー"）を置いて、そのドメイン内の機能を統合する。50〜100個のECUが5〜10個に集約される。これが2010年代の主流設計だ」
「カイトでは？」と僕は聞いた。
「カイトはさらに進んだ"ゾーンアーキテクチャ"を採用している。これはTeslaが先導したアーキテクチャで、機能でなく車両の"物理的な場所"でECUを配置する」
フロントゾーンコントローラー：フロントの全機能（センサー、ライト、etc.）
リアゾーンコントローラー：リアの全機能
左サイドゾーンコントローラー
右サイドゾーンコントローラー
中央Vehicle Computer（高性能。全体統括）
「物理的な配線が短くなり、コスト削減になる。そして中央のVehicle Computerが強力なSoC（NVIDIA Orin等）で、自動運転・OTA・AI推論を全部やる。Adaptive AUTOSARはこのVehicle Computerの上で動く」
「Classic AUTOSARはゾーンコントローラーの中の小さなマイコンで動いて、Adaptive AUTOSARがVehicle Computerの上で動く。ClassicとAdaptiveが共存するハイブリッド構成だ」
その日のノート。
剛志のノート（38）
・分散アーキテクチャ（旧）→ ドメインアーキテクチャ → ゾーンアーキテクチャ（最新）。
・ゾーンアーキテクチャ：機能でなく「物理的な場所」でECU配置。配線短縮・コスト削減。
・中央Vehicle Computer（高性能SoC）がAI・OTA・自動運転を担う。
・Adaptive AUTOSAR：Vehicle Computerの上で動く。
・Classic AUTOSAR：ゾーンコントローラーの小マイコンで動く。
・カイトはハイブリッド構成：Classic（安全コア、低レイテンシ制御）＋Adaptive（ADC、OTA、AI推論）。
第39章 AUTOSARを実装するということ ―― 現場の現実
AUTOSAR.005：AUTOSARの実装と課題 ― ツールチェーンと現場の現実
「最後に、AUTOSARを実際に実装する現場の現実を話す」と泉谷さんは言った。「教科書的なきれいな話だけじゃなくて」
ツールチェーン
「AUTOSARの開発は、ツール前提だ。手でARXMLを書く人間はほぼいない。主なツールは――」
・Vector DAVINCI Developer：SW-Cのアーキテクチャ設計、RTE生成
・Vector DAVINCI Configurator：BSWの設定、コード生成
・EB tresos：Elektrobit製のAUTOSAR BSW設定ツール（Continentalグループから2022年に売却され、現在はEB Automotive社が提供）
・Simulink + Embedded Coder：モデルベース設計からSW-Cコード生成
・PolySpace：MISRA準拠確認（自動生成コードも対象）
・CANoe / CANalyzer：通信テスト、AUTOSARメッセージのデバッグ
「これらのツールは高価だ。開発環境だけで、一人のエンジニアが年間数百万円のライセンス費用を負担することがある。中小サプライヤーには重い」
現場でよく起きる問題
「現実の現場でよく起きる問題をあげる。AUTOSARを入れたからといって、すべてが解決するわけではない」
「問題1：ベンダーロックイン。BSWの実装（ETASかVectorかCodeXかTASTE）によって、BSW設定のやり方が微妙に違う。"AUTOSAR標準"のはずが、BSWベンダーごとに癖がある」
「問題2：生成コードの肥大化。AUTOSAR準拠のコードを生成すると、手書きのコードより大きくなりがちだ。特にRTEの生成コードは、機能の割に大きい。リソース制約の厳しいマイコンでは問題になる」
「問題3：統合の難易度。複数のサプライヤーが作ったSW-CをOEMがシステム統合する際、"AUTOSAR準拠のはずなのに型が合わない"という問題が起きる。AUTOSAR準拠の解釈に幅があるため」
「問題4：Classicの学習コスト。AUTOSARのBSWは複雑だ。COMスタック、MemスタックなどBSPモジュールが数十個あって、それぞれの設定項目が数百ある。新人エンジニアがキャッチアップするのに半年〜1年かかることは珍しくない」
「ただ、これらの課題があっても、AUTOSARなしで現代の複雑な車載ソフトを作ることは現実的ではない。なぜなら、AUTOSARが解決しようとしている問題（相互接続性、再利用性、基盤の標準化）は本物だからだ」
「......」泉谷さんは少し黙った。
「移行コストが高すぎて、誰もやりたがらない----そういう見方もできますよね」と僕は言った。
泉谷さんはゆっくりと答えた。「そうだ。だから、今まさに車載業界全体がその岐路にいる。誰かがやらなければ置いていかれる。でも、誰もが怖くて踏み出せない。カイトはその最前線にいる。だからこそ、僕らがやる意味がある」
「現実の評価は、"理念は正しい。実装は難しい"というところだ」
「泉谷さん、最後に一個聞いていいですか」と僕は言った。「AUTOSARって、Webのフレームワークに似てますね。Reactとかみたいに、"みんなが同じフレームワーク使えば再利用できる"という発想」
「そうだ。完全にその通り。だから、Web出身の君には比較的馴染みやすいはずだ。RTEは"フレームワークのルーター"で、SW-Cは"コンポーネント"で、BSWは"Node.jsのランタイム"みたいなものだ」
「でも」と泉谷さんは付け加えた。「Webと違うのは、AUTOSARは"命に関わる"から、フレームワークを変えることがほぼできない点だ。Reactが気に入らなければVueに変えられる。でも、量産車のBSWをリプレイスするのは、数年規模のプロジェクトになる」
「一度選んだら、10年〜20年付き合う技術選択。それが車載の現実だ」
翌週、財前さんからメールが届いた。「アイソーさんのAUTOSAR Adaptive実装の検討状況を教えてほしい。OEM側でもゾーンアーキテクチャへの移行を計画しており、サプライヤーの対応状況を把握したい。文書でご回答願いたい」と書いてあった。
泉谷さんは苦笑いしながら「財前さんは、こちらが整理できたと思ったタイミングで来る。だいたい半歩先の質問を持ってくるんだよな」と言った。
「回答、どうするんですか」と僕は聞いた。
「正直に書く。今の段階で決まっていること、検討中のこと、未確定のことを分けて書く。財前さんは嘘や曖昧な回答を一番嫌う。証拠と現状をそのまま出す方がいい」と泉谷さんは言った。
----それはまるで、アセスメントのときの藤谷さんの言葉「で、証拠は？」と重なった。
その夜のノート。
剛志のノート（39・AUTOSAR まとめ）
① AUTOSARは「車載ソフトの共通言語」。誕生背景は「同じ機能の無駄な再実装爆発」。
② Classic三層：BSW（基盤）＋RTE（通信管理）＋SW-C（アプリ）。
③ SW-CのポートはSender/ReceiverとClient/Server。ARXMLで型付け。
④ Adaptive：POSIX OS、SOA/SOME/IP、動的統合。SDV・自動運転・OTA対応。
⑤ アーキテクチャ進化：分散→ドメイン→ゾーン。中央Vehicle ComputerがAdaptiveで動く。
⑥ 現実の課題：ベンダーロックイン、生成コード肥大、統合の難、学習コスト。
⑦ 評価：「理念は正しい、実装は難しい」。でもAUTOSARなしで現代の車は作れない。
⑧ WebのReact的発想。でも一度選んだら10〜20年付き合う技術選択。