Automotive SPICEについて

Intro to Automotive SPICE

2.1. 新設プロセスの詳細: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として含まれる4つのプロセスについて以下に解説します。

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は、リリース対象となるハードウェアのサンプルがハードウェア要求を満たしていることを確認するための検証を対象としています。
ハードウェア要求は、顧客や自社内から要求されるテスト要求も含まれます。
前述の能力レベルの整理において、能力レベル1から戦略に関する概念が削除された旨を説明しました。
HWE.3、4でもBP1からは戦略に関する記述が削除され、代わりに検証手段という用語が用いられます。

既存の管理・支援系プロセス:

MAN.3やSUP.8などの管理・支援系プロセスも同様にハードウェアプロセスへも適用されます。
基本的な考え方は変わりませんが、管理対象の人的リソース、物的リソース、技術などが広がります。
もし、ハードウェアチームが他チームと異なる方法でプロジェクト管理を行っているようであれば、アセスメントにおいてMAN.3を別インスタンスとして扱うことも考慮が必要となります。
また、構成管理においては、ハードウェア固有の特徴として、実サンプルを扱う考慮が必要となります。
顧客に対して同一設計のサンプルを複数台納入するのであれば、個々のサンプルを識別するためのシリアル番号の管理も必要ですし、顧客からサンプルの長期保管を要求されている場合は、保管場所の管理も考慮に入れる必要があります。