メールマガジン
MAIL MAGAZINE
先月のメルマガでは、VDA Automotive SYSカンファレンスの速報として、Automotive SPICE 4.0に関する動向についてご紹介いたしました。
今回のメルマガでは、Automotive SPICE 4.0の内容について、もう少し詳細にご紹介いたします。
【Automotive SPICE 4.0の対象プロセス】
Automotive SPICE 4.0（以下、バージョン4.0）では以下のプロセスに追加と削除が行われました。
追加されたプロセス：
・HWE.1～4：ハードウェアエンジニアリングプロセス群
・MLE.1～4：機械学習エンジニアリングプロセス群
・SUP.11：機械学習データ管理
・VAL.1：妥当性確認
削除されたプロセス：
・SUP.2：検証
・SUP.4：共同レビュー
・SUP.7：文書化
・SPL.1：サプライヤー入札
・ACQ.4以外の取得プロセス
※削除された取得プロセスの内容は、Automotive SPICE for Cyber SecurityのACQ.2に集約
位置づけが変更されたプロセス：
・REU.2：再利用のためのプロダクト管理
※バージョン3.1までは組織的な再利用の仕組み（再利用プログラム）に基づいた再利用を想定していましたが、バージョン4.0ではベースモデルに基づいた再利用を想定する位置づけに変更されました。
(出典：VDA Automotive SYS Conference 2023、VDA WG13発表資料)
なお、Automotive SPICE for Cyber Securityは、バージョン4.0に内包されておりませんが、バージョン4.0の構造に合わせて更新される予定です。
また、当初予定されていたMEE（機械エンジニアリングプロセス）は、他プロセスを優先させる都合によりバージョン4.0への内包は見送られました。
次バージョン以降では、このMEEに加えてISO 26262に対応した機能安全PAMの導入が検討されています。
【新設プロセスの詳細：HWE】
従来、intacsからリリースされていた電気・電子系ハードウェア向けのエンジニアリングプロセスのPAM、Hardware SPICEが、Automotive SPICEのバージョン4.0に内包されることになりました。
intacsのHardware SPICEバージョン2.1とAutomotive SPICEバージョン4.0のHWEのプロセス群が対応関係を持つ形となります。
HWEの位置づけ：
Automotive SPICEバージョン3.0で導入されたプラグインコンセプトにより、システムエンジニアリング（SYS）を形成するドメインエンジニアリングの一つとしてハードウェアエンジニアリングのプロセスがAutomotive SPICEのプロセスと共に利用できるようになりました。
バージョン4.0では、このコンセプトが継承されます。
HWEは、下図のように、サブシステム化された下位レイヤーの電気・電子系ハードウェアに対して適用されます。
(出典：Automotive SPICE ガイドライン 2.0)
また、図には記載されていませんが、図中のHWは一般的にセンサ、コントローラ、アクチュエータドライバ等を含みます。
このうち、SoC（System On Chip）のようなパッケージは、それ自体をさらに下位のサブシステムと捉え、その構成要素に対してHWE（SoC上の回路）、SWE（ファームウェア）、MEE（パッケージのハウジング）のPAMがアセスメントで適用されます。
なお、上記のように階層化されたサブシステムにおいては、組織によってHWEとMEEの境界が異なる場合があります。
例えば、アンテナのように、筐体の形状によって筐体自体に電気的な特性を持たせている場合、筐体の設計がメカチームではなくハードウェアチームによって行われる組織があります。
これが合理的なアプローチであれば、Automotive SPICEにおいて弱みと捉えることはありません。その場合、アセッサーはアセスメント対象の設計意図に基づいて、Automotive SPICE上の評定対象プロセスの割り当てを判断する必要があります。
HWEとして含まれる４つのプロセスについて以下に解説します。
HWE.1 ハードウェア要求分析：
HWE.1の構造は、既存のSWE.1と変わりません。
ただ、ハードウェアにおいて扱われる要求には、State-of-the-art特性も含まれます。
なお、State-of-the-art特性には、ISO 26262-5 6.4.2に挙げられているセーフティメカニズムに関する特性も含まれます。
また、HWEにおいて環境に関する影響分析では、コネクタ、ケーブル、電源、通信ライン等のインターフェースに加えて、電圧変動、搭載スペース、EMC等の影響の確認も求められます。
HWE.2 ハードウェア設計：
HWE.2はハードウェアのアーキテクチャ設計と詳細設計を含む位置づけとなっています。
ただし、ハードウェアの規模が小さい場合など、アセスメント対象プロジェクトにおいてアーキテクチャ設計と詳細設計に分かれていなくても、それが合理的なアプローチであれば弱みとは捉えません。
ソフトウェアのアーキテクチャ設計との違いとしては、選択肢の評価に関する観点が含まれていないことが挙げられます。
バージョン4.0では、SYS.3、SWE.2のBPからも選択肢の評価に関するBPが削除されましたが、SYS.3とSWE.2については、選択肢の評価に関する観点が分析に関するBPの中に残ります。一方のハードウェアは、設計の選択肢が一意に決まる場合もあるため、この観点は対象外となります。
また、Automotive SPICEのHWEには生産に関するプロセスが含まれませんが、HWE.2は生産プロセスとの界面までを対象としており、特殊特性やEOL要件を特定して生産の関係者へ伝達する行為も含まれます。
なお、BPの定義には直接的な記載がありませんが、本プロセスはアーキテクチャ設計と詳細設計を含むため、両設計間の一貫性および双方向トレーサビリティも求められます。
HWE.3 ハードウェア設計に対する検証：
まず、エンジニアリングプロセスにおいて、バージョン4.0ではV字右側の用語がテストから検証に変わりました。
これはHWE.3、HWE.4も同様です。
従来のAutomotive SPICEでは、V字右側においては最終製品に組込まれる実体として、サブシステムやソフトウェアを対象とするテストに焦点を当てていました。
しかし、実際には実体に対するテストだけでなく、計算やシミュレーションもV字右側の確認行為として用いられることがあります。
そこで、バージョン4.0では従来のテストを検証という用語に改め、シミュレーション等も対象とすることになりました。
シミュレーションは、V字左側の設計に対する検証や要求に対する実現可能性確認にも用いられますが、HWE.3においては、リリース対象のサンプルを確認するための観点を対象とします。
なお、HWE.3においては、ソフトウェアのような段階的な統合の観点は含みません。
これは、ハードウェアにおいて部品をアセンブルし直しながら検証を行うアプローチが一般的ではないためです。
HWE.3において内部インターフェースに着目したテストは、ハードウェア内の各インターフェースに対して、ジャンパーピン等を用いた計測ポイントに着目したテストを想定しています。
ハードウェア対ハードウェアの統合が必要なケースについては、アセスメントではHWE.3ではなくSYS.4の対象として扱います。
HWE.4 ハードウェア要求に対する検証：
HWE.4は、リリース対象となるハードウェアのサンプルがハードウェア要求を満たしていることを確認するための検証を対象としています。
ハードウェア要求は、顧客や自社内から要求されるテスト要求も含まれます。
前述の能力レベルの整理において、能力レベル１から戦略に関する概念が削除された旨を説明しました。
HWE.3、4でもBP1からは戦略に関する記述が削除され、代わりに検証手段という用語が用いられます。
既存の管理・支援系プロセス：
MAN.3やSUP.8などの管理・支援系プロセスも同様にハードウェアプロセスへも適用されます。
基本的な考え方は変わりませんが、管理対象の人的リソース、物的リソース、技術などが広がります。
もし、ハードウェアチームが他チームと異なる方法でプロジェクト管理を行っているようであれば、アセスメントにおいてMAN.3を別インスタンスとして扱うことも考慮が必要となります。
また、構成管理においては、ハードウェア固有の特徴として、実サンプルを扱う考慮が必要となります。
顧客に対して同一設計のサンプルを複数台納入するのであれば、個々のサンプルを識別するためのシリアル番号の管理も必要ですし、顧客からサンプルの長期保管を要求されている場合は、保管場所の管理も考慮に入れる必要があります。
【新設プロセスの詳細：MLE】
昨今、自動車の自動運転等に導入が進んでいる機械学習に関するエンジニアリングプロセスと、その機械学習データの管理に関する支援プロセスが新たに定義されました。
MLE.1 機械学習要求分析：
本プロセスにおける機械学習は、ソフトウェアとして実装されるものを想定しています。
そのため、機械学習要求に対する要求は、SWE.1で扱うソフトウェア要求の一部として位置づけられ、SWE.1と同様に機械学習要求としての実現可能性、検証可能性等の分析が求められます。
また、後述のSUP.11 機械学習データ管理のための管理要求として、機械学習データに対する要求もこのプロセスで扱われます。
MLE.2 機械学習アーキテクチャ：
MLE.2では、機械学習におけるトレーニングや機械学習のデプロイを行うためのアーキテクチャを決定すること。そして、その決定したアーキテクチャが意図通りであることを確認することが求められます。このアーキテクチャには、機械学習モデル、前後処理、ハイパーパラメータ（モデルのパフォーマンスを決定するためのパラメータ）も含まれます。
また、機械学習を行うためのハイパーパラメータの初期値の設定や、トレーニングおよび運用に必要なリソースの決定も含まれます。
MLE.3 機械学習トレーニング：
MLE.3では、機械学習要求を満たすようにモデルに対するトレーニングを実施することが求められます。
そのため、トレーニングや妥当性確認の開始／終了基準、ハイパーパラメータの最適化方法、学習用データの作成／変更方法、実施環境などを決定し、作成された学習用データを用いてトレーニングを実施します。
なお、本プロセスで用いられる妥当性確認という用語は、VAL.1の妥当性確認とは異なり、上記トレーニングにおけるハイパーパラメータの最適化を意味しています。
MLE.4 機械学習モデルテスト：
MLE.4では、トレーニング済みのモデル、およびトレーニング済みのモデルから導出されたデプロイ用のモデルが、機械学習要求を満たしていることを保証することが求められます。
そのため、テストの開始／終了基準、テストに用いるデータセット、期待されるテスト結果、テスト用データの作成／変更方法、実施環境などを決定し、モデルに対するテストを実施します。
SUP.11 機械学習データ管理：
一連の機械学習エンジニアリングプロセスに用いる機械学習データに対する管理プロセスとして、SUP.11が新たな支援プロセスとして追加されました。
本プロセスでは、データ管理のための活動、データを管理するためのリソース、データのライフサイクル、利害関係者の窓口などを含んだデータ管理の仕組みを確立することや、データの品質を維持するため活動が求められます。
【新設プロセスの詳細：VAL】
従来のAutomotive SPICEでは、“正しくものを作ったか”という検証の観点を中心に編成されており、“正しいものを作ったか”という妥当性確認の観点は直接的に含まれていませんでした。
そのため、妥当性確認に関する観点をアセスメントで確認したい場合には、ISO/IEC 12207から妥当性確認プロセスを持ち込むか、Automotive SPICEのSYS.5を拡大解釈して妥当性確認の観点を加えるという方法がintacsから示されていました。
ただ、機能安全やサイバーセキュリティを考慮する中で、妥当性確認の観点は重要となります。
そこで、バージョン4.0では新たにVAL 妥当性確認プロセス群を設置し、その中にVAL.1妥当性確認プロセスが定義されました。
妥当性確認は、利害関係者要求との関係を持つため、SYS.1と対を成すようにSYS.6とする案もありましたが、既存の構造を維持するため、SYSのプロセス群とは別で定義されています。
妥当性確認は、検証と異なり技術的な観点だけでなく予見されるユーザーの振る舞いやユーザーが受けるフィーリングも含まれます。たとえば、自動車が走行中にもかかわらず、運転手がシフトレバーをRレンジに入れてしまうことが予見されます。機能安全では、合理的に予見可能な誤使用による危険事象も考慮対象としますが、危険事象に限らず利害関係者にとって不都合なことは、妥当性確認にて確認される必要があります。
そのため、妥当性確認のインプットは、明確に定義された利害関係者要求だけでなく、経験に基づいた探索的アプローチも対象となります。
探索的アプローチを用いた場合、利害関係者要求との間で完全なトレーサビリティの確立ができないことがありますが、これを許容することは評定ガイドラインの中で定義されています。
【VDAスコープ】
バージョン3.0、3.1には、旧HISスコープを継承する形で、アセスメント対象の基本スコープとしてVDAスコープが定義されていました。
バージョン4.0では、下図の通り基本パートに含まれる管理・支援系の5プロセスに、SYS、SWE、HWE、MLEのうち１つ以上のエンジニアリングに関するプロセス群を加えた範囲を新たなVDAスコープと位置付けます。
この新たなVDAスコープに対して、必要に応じて図下部のフレックスパートのプロセスがアセスメント対象として追加されます。
(出典：VDA Automotive SYS Conference 2023、VDA WG13発表資料)
【能力レベルの整理】
バージョン3.0では、エンジニアリングプロセスV字左側における検証の概念をSUP.2およびGP2.2.4に集約するなど、Automotive SPICEでは、重複した指標を回避する試みが従来から行われてきました。
バージョン4.0では、さらに能力レベル１に残っていた体系的な文書化に関する概念が能力レベル２に移されました。
これにより、従来のテスト系プロセスや支援系プロセスのBP1に存在していた戦略が、GP2.1.1に集約されるなどの変更が行われました。
従来の戦略も、能力レベル１では体系的な定義を求めていたわけではありませんでしたが、一部のアセッサーは、戦略というPAMの記載に基づいて体系的な定義を期待してしまっていたことで、文書の欠落を能力レベル１の弱みと捉えてしまっていました。
この点に関するバージョン4.0での変更は、能力レベル１と２でそれぞれ期待される状態を明確に区別するための意図です。
それに伴い、従来の戦略にその一部として含まれていた当該プロセスの実施に必要な取り決めは、Measure（手段）という用語として能力レベル１に新たに定義されました。
検証系プロセス（旧テスト系プロセス）においては、従来のテスト戦略が検証手段という用語となり、この検証手段には検証技法、合否基準を含むテストケース、開始／終了基準、検証環境などが含まれます。
その他、冗長だったり、強い依存関係を持っていたりしたBPも統合されました。
エンジニアリングプロセスに含まれる一貫性と双方向トレーサビリティもその一つです。
元々、バージョン2.5までは、一貫性と双方向トレーサビリティが一つのBPでしたが、一貫性を確保することよりもトレーサビリティを確立することに着目されがちであったことや、トレーサビリティの確立は一貫性を確保する以外の目的でも行われることから、バージョン3.0ではこれらが別のBPとして定義されました。
しかし、これらが別のBPとして定義されることで、アセッサーは評定時にこれらBP間の依存関係を考慮する必要が出てしまいます。
バージョン4.0では、このような依存関係を極力無くすことで、アセスメントの労力を極力低減することを意図して、いくつかのBPの統合が行われました。
なお、BPの統廃合によって全体的にBPの数が減り、旧VDAスコープでの比較でバージョン3.1のBP数が127だったのに対し、バージョン4.0では97となります。
ただし、前述した能力レベル２へ移された観点を除いて、能力レベル１で考慮すべき観点が減ったわけではありません。
(出典：VDA Automotive SYS Conference 2023、VDA WG13発表資料)
【共通プラクティスの整理】
バージョン4.0では、能力レベル２と３に関するGPの統廃合も行われました。
特に従来のPA3.1とPA3.2は概念的には正対称な位置づけであるにもかかわらず、GPの数が一致しておらず使い辛さがありましたが、バージョン4.0ではGPが正対称になるように整理されました。
なお、能力レベル２と３に関するGPの数の変化は以下の通りです。
【Automotive SPICE ガイドライン 2.0】
Automotive SPICEのバージョンアップに伴い、Automotive SPICEガイドラインもバージョン2.0にバージョンアップします。
従来のガイドラインは、アセッサーの共通理解を深めることにつながったものの、多くのルール、推奨事項が定義されたことで、アセスメントにおいてそれらを確認するための労力が大きく増えていました。
バージョン2.0では、従来のガイドラインにおける課題を解消すべく以下の改良が行われました。
・アセスメント対象組織、プロジェクトにおけるプロセスの解釈に役立てるための情報の記載
・曖昧だったルールの明確化
・推奨事項の撤廃
※適用条件が曖昧だったため、推奨事項に位置づけられたものは、ルールに移動するか削除となる
・アセスメントの再現性向上
なお、今回ご紹介したAutomotive SPICE 4.0の詳細は、9月のトレーニングにて改めて詳細に解説いたします。
トレーニングの詳細は下記をご参照ください。
[Automotive SPICE 4.0アップデートトレーニング ～ASPICE4.0の活用に向けた勘所～]
開催日：2023/9/21(木) 9:00～12:00
お申込先：https://biz3.co.jp/publictraining/5295
2023/8/7 田渕 一成
※Automotive SPICE 4.0の解説WEBページはこちら：https://biz3.co.jp/lp_category/automotive_spice