SDVの技術要件は単一の企業や団体では対応し切れない

　同プロジェクトの特徴として後藤氏は「開発プロセス自体を第三者機関に監査してもらいながら進めている点」を挙げる。「成果物であるプログラムコードだけでなく開発プロセスを含めて、機能安全の国際規格「ISO 26262」への準拠を目指している」（同）ためだ。

　後藤氏は「従来のオープンソースプロジェクトで機能安全規格に準拠した例は限定的だ。特に車載ソフトウェアの包括的なミドルウェアスタックとしては画期的な試みだ」と評価する。

　今後は、2025年末にバージョン0.5を、2026年に1.0の公開をそれぞれ予定する。新機能の開発言語としては主に「ミドルウェアの記述に適しており、安全性や信頼性を特に重視しているRust」（後藤氏）を採用している。

　S-COREプロジェクトのミドルウェア構造の中では「AUTOSARがすでに開発した仕様と共通する機能がある」と後藤氏は話す（図2）。AUTOSARとしては「S-COREの標準の中にAUTOSARの機能を統合していきたい。2つのコードが存在したり、矛盾が出たりすることは避けたい」（後藤氏）考えだ。

図2：S-COREプロジェクトのHPC用ミドルウェアの中には、AUTOSARが開発済みの仕様との共通点がある。セキュリティや通信、診断）などだ

　ただ「難題もある」（後藤氏）。AUTOSARは会費を支払った企業が仕様策定に参加できる会員制コンソーシアムとして活動してきたため「AUTOSARの成果物である仕様を、オープンなS-COREプロジェクトで、どのように活用するかの議論が続いている」（同）という。

仕様策定に加え新たな協業モデルへの挑戦が始まっている

　AUTOSARの仕様をSDVに活用するための考え方として後藤氏は「役割の異なるECUの種別に応じて最適なプラットフォームを配置する」という指針を示す（図3）。

図3：SDVにおけるAUTOSARプラットフォームの活用指針の例

　例えば、センサー／アクチュエーターを制御するECUでは、要件に応じてAUTOSARの要・不要を判断し、特定ゾーンのECUでは確実性・信頼性を重視するClassic Platformを、SDVの中心となるHPCでは柔軟性を重視するAdaptive Platformを配置する。

　クラウドと車両間のデータ連携であれば「ナビやオーディオなど外部との通信機能を持つIVI（In-Vehicle Infotainment：車載インフォテインメント）システムを経由点として利用するアーキテクチャーの例がある」（後藤氏）という。ただ「詳細な実装については今後の検討課題」（同）としたうえで「追加要求や早いリリースを希望する方々による貢献をお願いしたい」（同）という。

　また、より特に高い機能安全要件への対応が求められるADAS（Advanced Driver-Assistance Systems：先進運転支援システム）分野へのAUTOSARの適用に向けて後藤氏は「ADASのための安全で高性能なデータ処理」というコンセプトを示したうえで、センサーデータの適切な処理と機能安全の確保の2つを重要課題に挙げる。

　技術の進歩がSDVの実現を加速させ、米Teslaやスウェーデンのボルボ・カーズ（Volvo Cars）などは、ソフトウェアだけでなく、ハードウェアの継続的なアップグレードを実施する動きを強めている。後藤氏は「従来の仕様策定に加えて、新たな協業モデルへの挑戦が始まっている」と指摘する。

　上述したEclipse SDVのS-COREプロジェクトとの協業も、その象徴の１つだ。後藤氏は「AUTOSARの仕様がS-COREに取り込まれ、これまでの標準化活動が実装段階でも活用されることは、AUTOSARの技術的価値の証明でもある」とする。そのために「S-COREプロジェクトとは、その協調の方法を一所懸命に議論している最中だ」（同）ともいう。

　後藤氏は「個別のECUに対する技術提案という強みを維持しながら、業界全体の変化に柔軟に対応していく」と今後の活動方針を示す。