ASPICE 關鍵觀念１: 插件的概念

ASPICE 標準解讀: 附錄

Published in

ASPICE標準解讀

Feb 20, 2020

目錄: Automotive SPICE(ASPICE)標準解讀 / 附錄: 關鍵觀念ASPICE關鍵觀念1:插件的概念
ASPICE關鍵觀念2:V-model
ASPICE關鍵觀念3:元件、組件、單元、項目
ASPICE關鍵觀念4:追溯性及一致性
ASPICE關鍵觀念5:同意、總結與溝通
ASPICE關鍵觀念6:評估、驗證標準和確保合規
ASPICE關鍵觀念7:策略與計畫的關係

前言

在ASPICE 標準中，特別將工程流程拆分成「系統工程」及「軟體工程」兩個部分；在車用功能安全(ISO 26262)標準，也能看到「系統工程」、「軟體工程」、「硬體工程」也都是各自獨立的。

ASPICE的標準附錄D.1，特別說明解釋。筆者將針對這種「插件」概念再做細部的說明與講解。

標準定義

在ASPICE 3.1標準附錄D.1說明與解釋如下:

標準原文
The following figure shows the basic principle of the "plug-in" concept. The top-level comprises all system engineering processes organized in a system "V". Depending on the product to be developed the corresponding engineering disciplines with their domain-specific processes (e.g. hardware engineering HWE, mechanical engineering MEE, or software engineering SWE) can be added to the assessment scope. All other processes such as management processes and supporting processes are domain-independent and are therefore designed in a way that they can be applied to both the system level and the domain levels.

如下圖所示，這是一個「插件」的基本概念。在上層(即系統層級，System Level)將所有的系統工程流程整理在系統“ V”(即V-Model，V工程開發流程)。下層的部分(即領域層級，Domain level)，則根據所要開發產品的特性，可將特定領域流程的工程流程(如: 硬體工程 HWE、機構工程 MEE、或軟體工程 SWE)納入評鑑的範圍。所有其他流程(如: 管理流程和支持流程)都是與領域流程無關的，因此可以同時應用於系統層級及特定領域層級。

插件的概念 (The “Plug-in” concept) 圖來源: ASPICE 3.1標準 Figure D.1

筆者延伸解釋：

在一般的狀況下，一個應用ASPICE標準的車用專案，主要涵蓋的開發模型包含「管理流程」、「支持流程」、「系統工程」及以下工程流程的組合。

硬體工程流程
軟體工程流程
機構工程流程
其他工程流程(標準未提到)

一般專案常見的範圍組合是(1)+(2)或(1)+(2)+(3)；少有不包含軟體的專案(這種專案一般不會被要求導入ASPICE標準)

在ASPICE標準中，只定義了上圖中深藍色底色流程的部分(SYS.1~SYS.5、SWE.1~SWE.6、MAN.3、ACQ.4、SUP.1、SUP.8、SUP.9、SUP.10)，其他淺灰色的流程(HWE.1~HWE.6、MEE.1~MEE.6)並沒有在標準中被定義。

假定一個專案包含「硬體工程」或「機構工程」，那麼隸屬於「硬體工程」與「機構工程」的流程該如何評鑑？

以ASPICE標準評鑑師的觀點來看，「硬體工程」與「機構工程」的流程為專案自行應用的流程，並不在ASPICE評鑑的範圍內，因此評鑑時不會檢查。

雖然評鑑不檢查，但這不表示就沒有流程、沒有相關證據喔！這部分的流程或證據，則由專案團隊自行定義跟管理。

系統工程是什麼？

在ASPICE及ISO 26262中所定義的「系統」並非一般大家以為的作業系統，這邊所謂的系統，指的是：

電子控制單元(ECU)：即車用微控制器，常見為軟體 + 硬體的組合。
機電系統(Mechatronic system)：常見為軟體 + 硬體 + 機構的組合。

錯誤的解釋：系統 = 純軟體
系統 = 純硬體
系統 = 純機構

因此，系統工程扮演著一個比較整體的概念，置於領域流程(軟體、硬體及機構)的上層。用一個比較容易理解的說法，「系統工程」即是整個「產品」。如下圖所示，利益相關者需求(一般理解為客戶需求，即圖中Stakeholder REQ)先對應到SYS.2系統需求分析、SYS.3系統架構設計，「系統工程」用整個「產品」的概念來進行需求分析與架構設計，再細部展開到硬體、軟體、機構等領域流程中。

例外的狀況？

雖然在上面的內容中，我們提到系統工程不僅止於單一的硬體、軟體、機構。然而在實務上，可能會有例外會打破這個框架，例如：純軟體的專案。

在ASPICE標準中，特別將純軟體專案的概念標註在軟體工程流程的備註中(詳參SWE.1軟體需求分析流程的備註2、備註11)；

如果是純軟體的專案(純機構、純硬體專案，在標準中沒有定義，因此不在討論範圍)，那麼根據備註的定義，建議專案團隊直接跳過系統工程。大家可以想像，在系統工程流程時，所有的需求都是軟體需求，且在定義系統架構時，亦只有唯一的軟體元件，這個情況下，執行系統工程意義不大。

實務的做法，請參考下圖。圖中，系統工程的四個流程都被排除在專案之外，而利益相關者的需求直接對應到SWE.1軟體需求分析。

※特別注意※實務上，各公司可根據自行定義的「裁剪指南」針對標準流程進行裁剪(如上圖，純軟體專案便是一種裁剪後的結果)。然而，如果被客戶要求進行ASPICE評鑑(假設被要求VDA Scope)，那麼建議盡量選擇包含所有流程的專案。「純軟體專案」，因為沒有系統工程流程，如果選定這樣的專案進行評鑑，最終評鑑的證書也不會有系統工程；這就不一定會滿足客戶的評鑑範圍喔！