ASPICE 標準解讀

(v4.0)ASPICE標準: SYS.3 系統架構設計(System Architectural Design)

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

本流程為ASPICE v4.0標準中的系統工程流程 — SYS.3 System Architectural Design 系統架構設計;本文章為「ASPICE v4.0 標準解讀」系列文章,筆者將針對ASPICE標準條文提供解讀與說明,期許本篇文章能夠為讀者,解決標準導入時的疑惑。


流程目的(Process Purpose)

The purpose is to establish an analyzed system architecture consistent with the system requirements.

本流程的目的是建立一個與系統需求相符的已分析系統架構。


流程結果(Process Outcome)

成功實作本流程,其相應的結果如下:
[Outcome 1] 設計一個系統架構,包括系統元件的定義,及它們的行為,介面,關係和互動。
[Outcome 2] 根據已定義的標準,對系統架構進行分析,且識別其特殊特性。
[Outcome 3] 在系統架構和系統需求之間建立一致性和雙向追溯。
[Outcome 4] 將已共識的系統架構和特殊特性傳達給所有相關方


基礎實踐(Base Practices)

SYS.3.BP1: Specify static aspects of the system architecture.
SYS.3.BP1: 具體描述系統架構的靜態觀點

Specify and document the static aspects of the system architecture with respect to the functional and nonfunctional system requirements, including external interfaces and a defined set of system elements with their interfaces and relationships.

根據功能和非功能性系統需求,具體說明並記錄系統架構的靜態觀點,包括外部介面以及一系列已定義系統元件及其介面和關係。

額外說明 -- 系統架構的靜態觀點

所謂的架構靜態觀點,指的是「系統靜態圖」,即Static Diagram,該靜態圖應描述:

1. 系統(及其邊界)及外部環境之間的關係

清楚地描述「系統」自身,及系統外部的相關組件。這將有利於後續的實作,也有助於其他標準的實施,例如: ISO/SAE 21434。

2. 標示系統與外部環境之間的介面

誠如標準BP1所描述,系統架構是根據系統需求而制定。在系統需求中存在「系統外部介面」的規格描述,這些系統與外部環境之間的介面,應在系統靜態圖中,清楚標示。

3. 根據系統拆解階層,標示子系統、系統元件等。

根據系統的複雜程度,其拆解方式也有所不同。專案團隊應先確定系統的拆解方式,例如: 將系統拆解成子系統,再拆解成系統元件;或將系統直接拆解成系統元件。

根據系統拆解定義,在系統靜態圖中,應清楚的標示這些子系統及系統元件。

需要注意的是,系統架構設計的架構圖是高層次且抽象的,因此系統元件指的是硬體、軟體和機構。

4. 標示 子系統/系統元件 間的介面

完成前述(3)的拆解及標示後,最後需要標示「子系統/系統元件」間的介面。

值得注意的是,系統元件間的介面通常不存在於系統需求描述中。換句話說,系統元件和系統元件間的介面都是為了實現特定系統需求而存在的。因此,需要詳細描述系統元件和其間的介面,以便在HWE.1或SWE.1中進一步展開各自的需求。

SYS.3.BP2: Specify dynamic aspects of the system architecture.
SYS.3.BP2: 具體描述系統架構的動態觀點

Specify and document the dynamic aspects of the system architecture with respect to the functional and nonfunctional system requirements including the behavior of the system elements and their interaction in different system modes.

根據功能和非功能性系統需求,具體說明並記錄系統架構的動態觀點,包含在不同系統模式下,系統元件間的行為與互動。

NOTE 1: Examples of interactions of system elements are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems.

備註1: 系統元件間互動的案例,包含機構組件的慣性時序圖、ECU的處理時間、匯流排系統的信號傳播時間。

額外說明 -- 系統架構的動態觀點

所謂的架構動態觀點,指的是「動態行為圖」,即為舊版(v3.1)所提到的「Dynamic behavior」,該動態行為圖可包含:

1. 狀態轉換圖 (State transition Diagram)

即狀態機(State Machine),可描述系統於不同狀態之間的行為與動作。常見的狀態包含:開機、關機、正常模式、校準、診斷。

2. 使用案例圖(Use-case diagram)

使用案例圖描述系統的高層次功能和範圍,但不涉及系統的內部操作。其目的是展示系統與其他系統組件、外部組件或使用者之間的互動情境。這些情境可以根據系統需求的描述而得出。

舉例來說 [系統需求]:
When receving  100 to 110 bus messages, The ECU shall react within 1[s].

在上述案例中,該需求提到的情境即為「When receving  100 to 110 bus messages...」,該情境可以被理解為產品的使用案例。

值得注意的是,使用案例通常與系統的狀態相關。以上述系統需求為例,這樣的使用案例只能發生在「已開機」的狀態下。

3. 時序圖(Sequence diagram)

又稱為「循序圖」,用於展示互動中物件之間訊息的順序。簡單來說,需要針對上述(2)的使用案例,描述系統元件之間的通訊或資料傳輸狀況,並從圖表中展示特定的時序關係。

4. 訊息序列圖(Message sequence charts)

訊息序列圖的目的是透過訊息交換來規範和描述系統組件及其環境的互動行為。(筆者建議:可以將訊息序列圖與時序圖考慮成一種圖)
額外說明 -- 動態圖的相關工具

未來車用專案不僅僅考量ASPICE,也同時需要考量ISO 26262及ISO 21434,因此針對上述動態圖的製作工具,高度建議參考ISO 26262的方法。目前業界常見的工具包含:SysML 或 UML。

SYS.3.BP3: Analyze system architecture.
SYS.3.BP3: 分析系統架構

Analyze the system architecture regarding relevant technical design aspects related to the product lifecycle, and to support project management regarding project estimates, and derive Special Characteristics for hardware elements. Document a rationale for the system architectural design decision.

根據產品生命週期相關的技術設計觀點,分析系統架構,以支援專案管理的專案預估,並推導硬體元件的特殊特性。並為系統架構設計決策記錄理由。

黃色區塊說明

標準僅提到硬體的特殊特性。基於軟體亦可能存在特殊特性,但在目前的版本(v3.991)中並未提及,因此如果後續有更新,筆者會再額外交代
額外說明 -- 分析系統架構與其他標準

ASPICE v4.0新版本的標準中,新增加了一個全新的「分析架構」的BP,這條BP將會與以下兩個車用標準存在互動,請參考下圖。

* ISO 26262:2018 
Part 4, 6.4.4 Safety Analyses and avoidance of systematic failures 

* ISO/SAE 21434
Clause10,  RQ-10-07 The architectural design defined in [RQ-10-01] shall be analysed to identify weaknesses.

---
針對ISO 26262的架構分析,其方法列於ISO 26262: 2018,  Part 9, Clause 8
針對ISO 21434的架構分析,其方法列於Clause 8.5 及 Clause 8.6
額外說明 -- 「Evaluation alternatives design」

在早期版本(v3.1以前)的BP中,存在一個步驟為「評估多個可選擇的設計方案」,並要求明確定義評估方法以及最終選擇方案的原因;然而在新版本(v4.0)的標準中,將「評估」納入分析架構的其中一個選項。

專案團隊需要自行決定分析架構的方法,可以選擇使用其他標準的分析手法,或者繼續遵循「評估」的做法。無論是在新舊標準中,唯一保留的要求是:記錄最終選擇該設計方案的理由。

NOTE 2: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.
NOTE 3: Examples for product lifecycle phases are production, maintenance & repair, decommissioning.
NOTE 4: Examples for technical aspects are manufacturability for production, suitability of pre-existing system elements to be reused, or availability of system elements.
NOTE 5: Examples for methods being suitable for analyzing technical aspects are prototypes, simulations, and qualitative analyses (e.g. FMEA approaches)
NOTE 6: Examples of design rationales are proven-in-use, reuse of a product platform or product line), a make-or-buy decision, or found in an evolutionary way (e.g. set-based design).

備註2: 有關專案可行性,請參見MAN.3.BP3;有關專案估算,請參見MAN.3.BP5。
備註3: 關於產品生命週期階段,可包含生產、維護與修護以及停用階段。
備註4: 關於「技術觀點」,可包含生產可行性、重複使用的現有系統元件的合適性,或系統元件的可用性。
備註5: 關於「適合用來分析技術觀點的方法」,可包含原型、模擬和定性分析(例如: FMEA方法)。
備註6: 關於「系價架構的採用理由」, 可包含使用既有的產品平台或產品線、自主開發-採購評估(make-buy)、或其他創新的方法(例如:基於集合的設計)

額外說明 -- 「Set-based design」基於集合的設計

基於集合的設計(Set-Based Design,SBD)是一種「精實開發」的實踐方法,它在開發過程中保持需求和設計選項的靈活性。專案團隊採用此方法來同時探索多個選項,並隨著時間的推移淘汰較差的選擇。這種方法通過在驗證假設之後才確定技術解決方案,提高了設計的靈活性。

傳統的方法則是在一開始就選擇一個單一的解決方案,然後一路開發到底。然而,這種作法可能導致最終產出物與目標偏離,需要進行大範圍的調整與修正。

詳細介紹請參考:scaledagileframework.com

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

Ensure consistency and establish bidirectional traceability between the elements of the system architecture and the system requirements that represent properties or characteristics of the physical end product.

確保系統架構中的元件與系統需求之間的一致性,並建立雙向追溯。在此,「系統需求」指的是實際成品的屬性與特性。

NOTE 7: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.
NOTE 8: There may be non-functional system requirements that the system architectural design does not trace to. Examples are development process requirements. Such requirements are still subject to verification.

備註7: 雙向追溯可支持一致性,並有助於變更請求的影響分析和驗證覆蓋狀況的展示。
備註8: 系統架構設計可能無法追溯到非功能性系統需求。例如: 開發流程需求。這些需求仍然需要進行驗證確認。

SYS.3.BP5: Communicate agreed system architecture.
SYS.3.BP5: 溝通已獲得共識的系統架構

Communicate the agreed system architecture, including the special characteristics, to all affected parties.

將已獲得共識的系統架構,及其特殊特性,向所有相關人員進行溝通。


工作產出(Output Work product)

04–06 系統架構
13–51 一致性證據
13–52 溝通證據
15–51 分析結果
17–57 特殊特性



感謝閱讀本文章!

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

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


WRITTEN BY
David Lin

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

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