SYS.3 System Architectural Design 系統架構設計

(更新2020/2/20) ASPICE 標準解讀

Published in

ASPICE標準解讀

11 min readAug 8, 2019

目錄: Automotive SPICE(ASPICE)標準解讀 / 系統工程流程SYS.1 系統需求獲取
SYS.2 系統需求分析
SYS.3 系統架構設計
SYS.4 系統整合與整合測試
SYS.5 系統合格測試

流程目的(Process Purpose)

The purpose of the System Architectural Design Process is to establish a system architectural design and identify which system requirements are to be allocated to which elements of the system, and to evaluate the system architectural design against defined criteria.

系统架構設計流程的目的是建立一個系統架構設計，並將系統需求分配到系統架構設計中的系統元件;跟據已定義的標準評估系統架構設計。

開始閱讀前：在ASPICE 3.1的標準中提到幾個名詞，可能會與筆者描述的名詞有所差異。在開始本流程的閱讀前，請參考「ASPICE 關鍵觀念3: 元件、組件、單元、項目」文章中的"元件、組件、單元間的關係"。在ASPICE 3.1標準中，替別把「系統工程」與「軟體工程」分別獨立，這裡面牽涉到插件的概念，相關內容請參考「ASPICE 關鍵觀念１: 插件的概念」，建議在閱讀本流程前，先閱讀相關內容。

流程結果(Process Outcome)

成功實作系統架構設計流程，其相應的結果如下：
1) [Outcome 1]一個系統架構設計被定義，且系統元件被識別。
2) [Outcome 2]系統需求被分配到每個系統元件
3) [Outcome 3]每個系統元件的介面被定義
4) [Outcome 4]每個系統元件的動態行為被定義
5) [Outcome 5]系統需求與系統架構設計的一致性與雙向追溯已被建立;
6) [Outcome 6]系統架構設計已商定，並向所有受影響的成員溝通

基礎實踐(Base Practices)

SYS.3.BP1: Develop system architectural design.
SYS.3.BP1: 制定系統架構設計
[Outcome 1]

Develop and document the system architectural design that specifies the elements of the system with respect to functional and non-functional system requirements.

制定及紀錄系統架構設計；系統架構設計需根據功能性與非功能性的系統需求去指定(定義)系統元件。

NOTE 1: The development of system architectural design typically includes the decomposition into elements across appropriate hierarchical levels.
備註1:開發系統架構設計通常是在適當的架構層級(請參考下方拆解結構)將系統拆解成系統元件。

額外說明：在SYS.3所提到的系統架構，一般包含「軟體、機構、硬體」。
如果系統過大，一般可以額外定義「子系統」。在標準所提到的適當的拆解結構，並沒有明確的定義；因此在實作SYS.3的時候，需要由專案的團隊自行定義拆解的結構層級，並依造此定義進行系統的拆解。

ASPICE SYS.3 系統架構設計中的架構層級結構，深藍色的部分為SYS.3所要涵蓋的範圍。

額外說明：切分的方法請參考上述的圖片。其中，相對應SYS.3的架構設計中只會呈現子系統(sub-system)及系統元件(System Element)。一般系統架構設計會根據系統需求來描繪；但是並非所有的系統需求都可以被描繪成系統架構，例如：開發的產品必須符合MISRA-C的要求。一般來說功能性需求可以被描繪成系統元件，然而非功能性需求就相對比較難描繪。

—

SYS.3.BP2: Allocate system requirements
SYS.3.BP2: 分配系統需求
[Outcome 2]

Allocate the system requirements to the elements of the system architectural design.

將系統需求分配到系統架構設計中的系統元件。

額外說明：常見的需求分配，一條系統需求可能可以分配到多個系統元件；多條系統需求也可能分配到單一個系統元件。因此這兩者的關係是多對多關係(M:N)。在實務上，並非所有的系統需求都可以對應到系統元件，存在一些非功能性的系統需求，這些需求則會直接對應到軟體/硬體/機構需求。

額外說明：上述的矩陣圖可以作為雙向追溯性及系統需求的分配結果。

—

SYS.3.BP3: Define interfaces of system elements.
SYS.3.BP3: 定義系統元件的介面
[Outcome 3]

Identify, develop and document the interfaces of each system element.

識別、制定且紀錄系統元件間的介面。

額外說明：這邊提到的介面包含系統元件間的介面，稱為內部介面(internal interface)及系統對環境的介面，又稱為外部介面(external interface)。

—

SYS.3.BP4: Describe dynamic behavior.
SYS.3.BP4: 描述動態行為
[Outcome 4]

Evaluate and document the dynamic behavior of the interaction between system elements.

評估且紀錄系統元件之間交互的動態行為。

NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.).
備註2:動態行為取決於運作模式 (例如：開機、關機、正常模式、教準、診斷，等)

額外說明：系統的動態行為，將可以作為系統元件、系統介面所需要的資訊的參考。通常會建議透過時序圖來定義系統的動態行為，請參考下圖；值得一提的是，系統的動態行為將會成為軟體、硬體、機構的動態行為的參考。在SWE.2亦需要定義軟體的動態行為，其中軟體的動態行為需要參考系統動態行為的情境(運作模式)。

開機模式下的系統動態行為，在時序圖中可以看見系統元件(Element)及元件階段的介面(Internal, External ITF)，透過這個動態行為可以有效識別系統元件間的關係，以及參數與資料的傳遞。

—

SYS.3.BP5: Evaluate alternative system architectures.
SYS.3.BP5: 評估替代系統架構
[Outcome 1]

Define evaluation criteria for the architecture. Evaluate alternative system architectures according to the defined criteria. Record the rationale for the chosen system architecture.

針對系統架構定義評估準則。根據所定義的評估準則，評估可供選擇的系統架構，並紀錄最後選定系統架構的理由。

NOTE 3: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and usability) and results of make-buy-reuse analysis.
備註3: 評估準則可包含品質屬性(模組化、可維護性、延展性、擴充性、可靠性、安全實現性、可用性)及「自制-購買-重用」的分析結果

—

SYS.3.BP6: Establish bidirectional traceability.
SYS.3.BP6: 建立雙向追溯
[Outcome 5]

Establish bidirectional traceability between system requirements and elements of the system architectural design.

建立系統需求與系統架構設計的雙向追溯。

NOTE 4: Bidirectional traceability covers allocation of system requirements to the elements of the system architectural design.
NOTE 5: Bidirectional traceability supports coverage, consistency and impact analysis.
備註4: 雙向追溯包含系統需求分配到系統架構設計中的系統元件。
備註5: 雙向追溯援覆蓋性、一致性和影響分析。

—

SYS.3.BP7: Ensure consistency.
SYS.3.BP7: 確保一致性
[Outcome 1,2,5,6]

Ensure consistency between system requirements and the system architectural design.

確保系統需求與系統架構設計的一致性。

NOTE 6: Consistency is supported by bidirectional traceability and can be demonstrated by review records.
NOTE 7: System requirements typically include system architectural requirements. Refer to BP5.
備註6: 可以透過利益相關者需求與系統需求的雙向追溯來比對文件之間的一致性；可以透過審查記錄來展示一致性的確保。
備註7: 系統需求通常會包含系統架構需求。請參照BP5。

—

SYS.3.BP8: Communicate agreed system architectural design.
SYS.3.BP8: 溝通商定的系統架構設計
[Outcome 6]

Communicate the agreed system architectural design and updates to system architectural design to all relevant parties.

溝通商定的系統架構設計及其更新給所有相關的成員。

工作產出(Output Work product)

04-06 系統架構設計 [Outcome 1,2,3,4,5]
13-04 溝通記錄 [Outcome 6]
13-19 審查記錄 [Outcome 5]
13-22 追溯記錄 [Outcome 5]
17-08 介面需求規格書 [Outcome 3]

* ASPICE網站
* ASPICE 3.1標準

感謝閱讀本文章！

如果你對文章內容有任何問題，請隨時與我聯絡。
if you found any question in the article, please feel free to contact me.

mailto: linchewing@gmail.com