SDV時代のAutomotive SPICE® 4.0への対応 -Draft編-

2023-06-19

はじめに

自動車業界では近年、各社があらゆる角度から「CASE」（Connected、Autonomous、Shared & Services、Electric）への対応を推進しています。こうした中、従前までのアクチュエータを制御する組み込みソフトウェアが多いハードウェア主体の車から、自動運転用の高速かつ高度な計算処理や、UI/UXに活用される車載アプリ用などのソフトウェアへと価値の比重が移行してきており、自動車におけるソフトウェアの重要性はますます高まってきています。さらにソフトウェアは上市後も市場でアップデートできるため、世の中のトレンドや競合動向に合わせて変更、すなわち成長し続けることが可能であり、ソフトウェアが自動車の価値を左右するようになってきました。そのため、自動車業界はこれまでハードウェアを中心に設計していた世界から、SDV（Software Defined Vehicle）としてソフトウェアを軸とした価値創造モデルへと移行しています。

一方で、メカ／ハードと異なり、ソフトウェアコードは出来栄えや成果物を人間が見て正しく理解またはレビューすることが困難なことから、ソフトウェアにおいては設計プロセスの評価により重きが置かれています。そこで、本稿では車載ソフトウェア開発における体系的アプローチおよびアセスメントモデルを定義したAutomotive SPICE^®4.0（Draft）について解説します。

※本稿発行時点では、2023年6月に発行されたAutomotive SPICE^® 4.0 のドラフト版（Version 3.991）およびAutomotive SPICE^® Guideline 2.0（Yellow book）を参考に執筆しています。

※本稿におけるAutomotive SPICE^®に関する用語の和訳は、Automotive SPICE^® 3.1の正式な和訳を参照しており、新規用語の和訳はPwCによるものです。

Automotive SPICE^® 4.0（Draft）の概要

2005年に初版が発行されたAutomotive SPICE^Ⓡ（以降、「A-SPICE」）は、VDA QMC（ドイツ自動車工業会品質管理センター）によって管理されている車載システム開発向けのプロセスモデルです。客観的なプロセス評価や、プロジェクトおよび組織レベルでのプロセス改善のための業界標準のモデルとして、自動車メーカーやサプライヤーを問わず、現在まで活用され続けています。今回は2017年にVersion 3.1がリリースされてから約6年ぶりの改訂となり、これまでの業界における運用結果や最新の技術動向を踏まえた修正および改善が随所に織り込まれています。A-SPICEは、「プロセス参照モデル（PRM）」と「プロセスアセスメントモデル（PAM）」から構成されており、プロセス参照モデルは図表1のとおり、A-SPICEで定義されるプロセスカテゴリー、プロセスグループ、およびプロセスを定義しています。

プロセスアセスメントモデルは、A-SPICEのアセッサーがアセスメント時に利用する指標を提供しており、ISO/IEC 33020に基づき、レベル0からレベル5まで6段階のプロセス能力レベルが定義されています（図表2）。

Automotive SPICE^® 3.1 から 4.0（Draft）における主な変化点

A-SPICE 3.1から4.0（Draft）に改定するにあたっては大小さまざまな変更がなされていますが、本稿では主な変更点について説明します。図表2で示すプロセス能力モデルは、Version 3.1からVersion 4.0（Draft）において変更はないため、本稿で詳細は扱わないこととします。一方でプロセス参照モデルは図表3に示すとおり、新規で追加、削除、名称変更されたプロセスグループ、ならびにプロセスが多くあるため、各変化点について以下のとおり説明します。

A-SPICE 3.1より定義されているVDAスコープ（推奨されるアセスメント対象プロセス）に関しては、A-SPICE 4.0（Draft）においても一部変更されています（図1の赤点線枠）。A-SPICE 3.1では「ACQ.4 サプライヤー監視」が含まれていましたが、A-SPICE 4.0ではオプションとなっています。また、今回新規で追加された、ハードウェアエンジニアリングプロセスグループと機械学習エンジニアリングプロセスグループの各プロセスも対象となっています。また、MAN.3およびSUP.1-SUP.10が“ベース”で、SYS.2-SYS.5、SWE.1-SWE.6、HWE.1-HWE.4、およびMLE.1-MLE.4が“プラグイン”として少なくとも１つ選択することとなっています。ただし、もともとVDAスコープはアセスメント目的に応じてテーラリングまたは拡張することが可能なため、A-SPICE 4.0（Draft）においても根本的な考え方は同じです。

なお、2021年に発行された Automotive SPICE^® for Cybersecurityは、A-SPICE 4.0には組み込まれていません。

主要ライフサイクルプロセスにおける変化点

A-SPICE 3.1 までは4つのプロセスグループで構成されていましたが、A-SPICE 4.0（Draft）では、ハードウェアエンジニアリングプロセスグループ（HWE）、機械学習エンジニアリングプロセスグループ（MLE）、および妥当性確認プロセスグループ（VAL）が追加されたことで、7つのプロセスグループにより構成されるようになりました。システムエンジニアリング、ソフトウェアエンジニアリングプロセスグループでは、「統合テスト（Integration Test）」が「統合検証（Integration Verification）」、「適格性確認テスト（Qualification Test）」が「検証（Verification）」に、それぞれ名称変更されました。もともとSYS.5 システム検証の後に「妥当性確認（Validation）」がなく、プロセスとしては不完全であったものが、今回、妥当性確認プロセスグループ（VAL）が追加されたことで、「テスト」「検証」「妥当性確認」といったV字の右側のプロセス名称が修正され、プロセス全体が最適化されました。

今回ハードウェアエンジニアリングプロセスグループが追加されましたが、ハードウェアはA-SPICE 3.1からプラグインコンセプトの1つとして表現されており、元々あったコンセプトが正式にプロセスグループに追加された形になります。また、機械学習エンジニアリングプロセスグループも今回新たに追加されました。機械学習エンジニアリングにおける要件（インプット）は、ソフトウェアエンジニアリングプロセスから機能学習要件へと連携されます。機械学習エンジニアリングにおいても他のエンジニアリングプロセス同様に、一貫性の確保と双方向トレーサビリティの確立は重要な要素の1つとなります。また、他のエンジニアリングプロセスに比べて特徴的なのが、「MLE.3 機械学習トレーニング」で、ここでは機械学習モデルのトレーニング、結果の検証、調整または最適化などのアプローチを定義する必要があります。

取得プロセスグループはもともと7つのプロセスで構成されていましたが、A-SPICE 4.0（Draft）では「ACQ.4 サプライヤー監視」以外の6つのプロセスが削除されました。これは実運用上、「MAN.3 プロジェクト管理」を代表とする管理プロセスグループで網羅されることが多いということなどが背景にあると考えられます。

支援ライフサイクルプロセスにおける変化点

支援ライフサイクルプロセスにおいては、「SUP.2 検証」「SUP.4 共同レビュー」「SUP.7 文書化」が削除されました。これらは各エンジニアリングプロセスおよび他の支援プロセスに包含されてアセスメントを受けることが多いことなどが背景にあると考えられます。一方で今回機械学習エンジニアリングプロセスグループが追加されたことに伴い、「SUP.11 機械学習データ管理」が新規で追加されました。機械学習データも重要な設計資産の1つであるため、従前までの設計資産と同様に決められたルールの元に適切に管理される必要があります。

組織ライフサイクルプロセスにおける変化点

組織ライフサイクルプロセスにおいては、「REU.2 再利用プログラム管理」の名称が「REU.2 再利用プロダクト管理」へと微修正されました。これは再利用対象が実際はシステムレベルからハードウェア、その他関連設計資産まで多岐にわたるため、「プログラム」に限定しなくなったことが背景にあると考えられます。

SDV時代におけるAutomotive SPICE^Ⓡ 4.0への向き合い方

SDV時代において、これまで以上にソフトウェアに対する価値が高まるとされる一方で、重要性および品質リスクも高まると考えられます。最初にも述べたとおり、ソフトウェア開発においてはプロセス評価がますます重要となっているため、A-SPICEのような業界標準プロセスを適用し、ソフトウェアサプライチェーン全体として一定の品質を担保することが求められます。車載ソフトウェア開発企業の多くはA-SPICE 3.1の社内適用を既に完了しており、今後はA-SPICE 4.0に対しFit & Gapを通じ差分を明確化した上で、プロセスをアドオン／修正することになると考えます。

今回ハードウェアが正式に追加されたことからも分かるように、SDV時代となりソフトウェア軸で開発が進むようになったとしても、自動車1台を世に送り出すためには、システム・ソフトウェア・ハードウェアを完全に切り離すことは不可能であり、今後も絶妙なバランスおよび連携を取りながら、開発を進める必要があると考えます。そのためには、プロセス軸で閉じて考えず、組織軸やITシステム／開発ツール軸などを広く把握し、SDV時代に必要な各社に適した開発環境を構築することが肝要です。

また、自動車業界においては図表4のとおり、順守すべき多くの法規や標準が複雑に関連し合うため、これらの全体像を適切に把握し、社内で瞬発力高く対応できる仕組みや体制を構築することも重要です。SDV時代においては、これらの法規や標準に対応するためのプロセスの礎としてA-SPICEやISO9001などの既存の社内ルールや仕組みを活用できれば、既存業務を遂行しつつ、プロセス間で矛盾なく実運用可能なプロセスを構築できるのではないかと考えます。