(更新2024/04/15) 本流程為ASPICE v4.0標準中的系統工程流程 — SYS.3 System Architectural Design 系統架構設計；本文章為「ASPICE v4.0 標準解讀」系列文章，筆者將針對ASPICE標準條文提供解讀與說明，期許本篇文章能夠為讀者，解決標準導入時的疑惑。
流程目的(Process Purpose)
The purpose is to establish an analyzed system architecture, comprising static and dynamic aspects, 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 non-software system elements. Document a rationale for the system architectural design decisions.
分析系統架構中與產品生命週期相關的技術設計問題。分析結果用以支援專案管理的專案預估，並藉以推導出非軟體的系統元件的特殊特性。記錄系統架構設計決策的理由。
額外說明 -- 分析系統架構與其他標準 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. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other.
Note 8: There may be non-functional requirements that the system architectural design does not trace to. Examples are do not address, or represent, direct properties or characteristics of the physical end product. 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.
將已獲得共識的系統架構，及其特殊特性，向所有相關人員進行溝通。
額外說明 -- 已獲得共識 在ASPICE標準中，提到"已獲得共識"，並不代表一定需要正式的文件審核或簽核。 在實際執行時，專案團隊通常會用會議紀錄來提供已達成共識的證據。 例如，團隊成員在會議中討論，並達成一致後，會整理會議記錄並作為共識的證明。這種方法比較快速且靈活，因為如果要透過正式的文件管理流程去處理，不僅涉及到多個組織層級的審核與批准，還要經過最終的文件發行，這整個過程可能非常耗時。 當然，這個「會議紀錄」也可以作為溝通的證據。
輸出資訊項目 (Output Information Item)
04–06 系統架構13–51 一致性證據13–52 溝通證據15–51 分析結果17–57 特殊特性
