ASPICE 標準解讀

(v4.0)ASPICE標準: SYS.4 系統整合與整合驗證(System Integration and Integration Verification)

本文章源自於「Automotive SPICE v3.991」,內容與「Automotive SPICE v4.0」可能會有出入;屆時筆者會來修正這之中的差異

本流程為ASPICE v4.0標準中的系統工程流程 — SYS.4 System Integration and Integration Verification 系統整合與整合驗證;本文章為「ASPICE v4.0 標準解讀」系列文章,筆者將針對ASPICE標準條文提供解讀與說明,期許本篇文章能夠為讀者,解決標準導入時的疑惑。


流程目的(Process Purpose)

The purpose is to integrate systems elements and verify that the integrated system elements are consistent with the system architecture.

本流程的目的是整合系統元件並驗證整合後的系統元件與系統架構相一致。


流程結果(Process Outcome)

成功實作本流程,其相應的結果如下:
[Outcome 1] 針對系統架構 (包括系統元件間的介面和互動),明定系統元件整合驗證的驗證措施
[Outcome 2] 將系統元件整合成符合發佈範圍的完整整合系統
[Outcome 3] 根據發佈範圍,選擇了驗證措施,考慮回歸驗證的標準
[Outcome 4] 使用選定的驗證措施驗證整合系統元件,並記錄系統整合驗證的結果
[Outcome 5] 在驗證措施和系統架構元件之間建立一致性和雙向追溯性
[Outcome 6] 建立驗證結果和驗證措施之間的雙向追溯性
[Outcome 7] 將系統整合和整合驗證的結果總結並通知所有受影響的各方


基礎實踐(Base Practices)

SYS.4.BP1: Specify verification measures for system integration.
SYS.4.BP1: 指定系統整合的驗證措施

Specify the verification measures, based on a defined order and preconditions for the integration of system elements against the system static and dynamic aspects of the system architecture, including

  • techniques for the verification measures
  • pass/fail criteria for verification measures
  • a definition of entry and exit criteria for the verification measures
  • the required verification infrastructure and environment setup

根據系統元件的整合順序和整合前提,針對系統架構的靜態和動態方面,指定驗證措施,包括

  • 驗證措施的技術
  • 驗證措施的通過/不通過標準
  • 驗證措施的進入和退出標準的定義
  • 所需的驗證基礎設施和環境設定

NOTE 1: Examples on what a verification measure may focus are the timeliness and timing dependencies of the correct signal flow between interfacing system elements, or interactions between hardware and software. The system integration test cases may focus on

  • the correct signal flow between system items
  • the timeliness and timing dependencies of signal flow between system items
  • the correct interpretation of signals by all system items using an interface
  • the dynamic interaction between system items

備註1: 驗證措施可能關注的示例包括介面系統元件之間正確信號流的時效性和時序相依性,或硬體與軟體之間的互動。系統整合測試案例可能專注於:

  • 系統元件之間正確的信號流
  • 系統元件之間信號流的時效性和時序相依性
  • 所有系統元件使用介面正確解釋信號
  • 系統元件之間的動態互動
額外說明 -- 關於驗證策略與回歸驗證策略

ASPICE v4.0中,明確的將策略的制定從既有的BP移除。這些關於策略制定的部分,將會在CL2認證時,才需要詳細定義。換句話說,如果專案要取得CL1認證,將不需要撰寫或定義任何策略。
額外說明 -- 驗證措施

所謂的驗證措施,可以簡單的理解成驗證方法及細節。「Verification」驗證這個字詞,包含了許多手段,而「Test」(測試)只是其中的一個手段而已。ASPICE v4.0考量了更多產品開發情境,因此才將原有在v3.1中的測試一詞,換成驗證。

讓筆者提供一個思考情境:想像一個專案,其產品範圍包含一個既有的硬體元件、及一個需要修改的軟體元件。在系統整合階段時:

* 針對既有的硬體元件 : 可透過審查、黑箱測試、注錯測試等方法,確保該元件是沒問題的。
* 針對新修改的軟體元件:僅確認該軟體元件是否通過SWE.4 - 6 的測試即可。

待各自確認沒問題後,才針對軟硬體整合,進行進一步的驗證。
額外說明 -- 驗證措施應包含的內容:

將標準所提到的內文與ISO 26262相串接。驗證措施如果採用測試,則相關測試案例須包含:

* 測試方法 (Test Method)
* 測試案例設計方法 (Test Case Deisgn Method)
* 測試環境 (包含工具及其設定)
* 預先條件 
* 限制
* 測試步驟 (包含參照文件)
* 期望結果 (即Pass/Fail Criteira)
額外說明 -- 驗證措施的進入與退出條件:

這裡提到的進入與退出條件,可以理解成「特定測試回合/迭代」的進入與退出條件。

一般來說,多個測試案例會被包含在一個測試回合/迭代裡,當然也有特殊情況,一個測試回合/迭代只有一個測試案例。

在上述的情況,一般測試團隊會針對不同的回合/迭代,定義進入及退出條件。當滿足進入條件時,這個測試回合中的所有相關測試案例,將會被拿來進行測試;當滿足退出條件時,這個測試回合/迭代才算結束。

讓筆者提供一個案例,來幫助大家理解:

測試回合一: 整合前確認,包含10個測試案例及2份查檢表。
進入條件: 整合測試流程被允許啟動時
結束條件: 測試案例100% PASS、查檢表的mandotory項目均為PASS、required項目50%PASS

測試回合二: 第一次整合,包含50個測試案例
進入條件: 測試回合一通過後
結束條件: 測試案例100% PASS,允許minor bug

測試回合三: 第二次整合,包含剩下30個測試案例
進入條件: 測試回合二通過後
結束條件: 測試案例100% PASS,允許minor bug

值得一提的是,由於ASPICE v4.0 將制定驗證策略移除,因此這些有關測試回合的資訊並不一定會被完整的紀載,因此,如果是為了取得CL1,建議可以在個別測試案例、或群組測試案例撰寫進入與退出條件。

SYS.4.BP2: Select verification measures.
SYS.4.BP2: 選擇驗證措施

Document the selection of verification measures for each integration step considering selection criteria including criteria for regression verification. The documented selection of verification measures shall have sufficient coverage according to the release scope.

根據驗證措施選擇準則(包括回歸驗證準則),記錄每個整合步驟的驗證措施的選擇。所記錄的驗證措施選擇應根據釋出範圍具有足夠的涵蓋度。

NOTE 2: Examples for selection criteria can be prioritization of requirements, the need for regression verification (due to e.g. changes to the system architectural design or to system components), or the intended use of the delivered product release (e.g. test bench, test track, public road etc.)

備註2: 舉例來說,選擇準則可以包括需求的優先順序、需要回歸驗證(例如: 由於系統架構設計或系統元件的更改)或所交付產品發布的預期用途(例如: 測試台、測試場地、公共道路等)。

額外說明 -- 選擇驗證措施的思維

讓筆者來談談兩種選擇策略,
(1): 按照原來的計畫,排定測試案例測試的優先順序;
(2): 因測試缺陷後的修正或變更請求,必要進行局部或全部重測

上述(1),可根據架構設計中定義的修先順序、或整合的順序、或交付產品發布等資訊,定義各測試回合/迭代,並定義個別測試回合/迭代所涵蓋之測試案例;於所有測試回合/迭代定義完畢後,需檢查是否涵蓋所有的測試案例,即涵蓋度檢查。

上述(2),即「回歸驗證」,如果要通過CL2,則需要額外制定回歸驗證的測試案例選取標準。根據修正或變更的範圍,選擇局部或全部重測。
額外說明 -- 回歸驗證策略

系統整合與整合驗證流程談道的回歸驗證策略,屬於架構類型的回歸驗證。如果要選取局部重測,一般建議的選取邏輯,共計有兩種:
(1) 根據「已變更之元件」的介面,選取重測範圍
(2) 針對所有修正,制定基礎重測範圍

讓筆者針對上述(2)進行多一點的描述。

所謂的回歸驗證,概念上是為了減輕全部重測的工作量,進而定義出最小限度的重測範圍,上述(1),針對已變更元件的介面,識別受影響之範圍,並以此作為重測範圍,這是一種合理的思考方式;但是負責的系統開發,常常牽一髮而動全身,僅針對受影響之範圍進行測試,雖然合理但是有可能會存在一些漏網之魚。

為了避免這些被遺漏的缺陷存在,回歸驗證可以將產品的「基礎功能」或「關鍵功能」等項目,納入作為重測的範圍中。


SYS.4.BP3: Integrate system elements and perform integration verification.
SYS.4.BP3: 整合系統元件並執行整合驗證

Integrate the system elements until the system is fully integrated according to the specified interfaces and interactions between the system elements, and according to the defined order and defined preconditions. Perform the selected system integration verification measures. Record the verification measure data including pass/fail status and corresponding verification measure data.

根據系統元件之間的指定介面、互動、已定義順序和預定條件,整合系統元件,直到系統完全整合。執行所選的系統整合驗證措施。記錄驗證措施的資料,包括「通過/不通過」狀態以及相應的驗證措施資料。

NOTE 3: Examples for preconditions for starting system integration can be successful system element verification or qualification of pre-existing system elements.
NOTE 4: See SUP.9 for handling verification results that deviate from expected results.

備註3: 舉例來說,開始系統整合的前置條件可以是個別系統元件通過驗證或先前已存在的系統元件通過合格認定。
備註4: 請參閱SUP.9,以處理偏離預期結果的驗證結果。

SYS.4.BP4: Ensure consistency and establish bidirectional traceability.
SYS.4.BP4: 確保一致性並建立雙向追溯

Ensure consistency and establish bidirectional traceability between verification measures and the system architecture. Establish bidirectional traceability between verification results and verification measures.

在驗證措施和系統架構之間確保一致性並建立雙向追溯。
建立驗證結果與驗證措施之間的雙向追溯。

NOTE 5: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

備註5: 雙向追溯可以用來支援一致性、協助變更請求的影響分析、並支援展示對利益相關者需求的範圍覆蓋。

額外說明 -- 追溯的細節

有關於SYS.4的追溯及一致性,請參考下圖。

針對驗證措施及系統架構之間的追溯,需要注意以下3個重點:

(1) 驗證措施與系統元件之追溯 (這裡指的是系統元件本身)
(2) 驗證措施與系統介面之追溯 (這裡包含內外部介面)
(3) 驗證措施與系統動態圖之追溯 (這裡包含系統元件的互動)

SYS.4.BP5: Summarize and communicate results.
SYS.4.BP5: 總結並傳達結果

Summarize the system integration and integration verification results and communicate them to all affected parties.

總結系統整合和整合驗證結果,並將其傳達給所有受影響的各方。

NOTE 6: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

備註6: 從測試案例執行中提供所有必要的資訊摘要,使其他各方能夠判斷後果。


輸出資訊項目(Output Information Item)

08–60 驗證措施
06-50 整合順序指導書
08–58 驗證措施選擇結果
15–52 驗證結果
13–51 一致性證據
13–52 溝通證據
11–06 已整合之系統



感謝閱讀本文章!

如果你對文章內容有任何問題,請隨時與我交流聯絡。

歡迎訂閱我的文章,當有最新文章發布時,我將第一時間通知您 :)


WRITTEN BY
David Lin

現任國際標準輔導顧問及評鑑師;
在這個網站,我將分享一些產業新知、趨勢以及標準的解讀與看法。

歡迎與我交流:
Email:
linchewing@gmail.com
LinkedIn:
https://www.linkedin.com/in/linchew/