I. 배경
자동차 전장 산업에서의 소프트웨어 아키텍처(Software Architecture)의 hierarchy(계층)에 대한 Granularity(입도, 상세화 등의 의미)의 수준에 대해서, 현장의 많은 엔지니어 분들과 엔지니어링 프로세스를 담당하는 분들이 어려움을 겪는 영역입니다.
그래서 현재 자동차 산업에서 가장 많이 요구되는 프로세스인 Automotive SPICE®와 안전 관련 엔지니어링 프로세스 및 방법을 기술하고 있는 ISO 26262 관점에서 소프트웨어 아키텍처의 Granularity를 살펴보고자 합니다.
소프트웨어 아키텍처(Software architecture) 및 소프트웨어 상세 설계(Software detailed design)와 관련된 개발활동들은 “소프트웨어 요구사항에 기반한 솔루션(e.g., software to be built)들을 구현(e.g., coding)이 가능하도록 제시” 하는 것입니다. 그리고, 실제로 SW의 설계와 구현은 동시에 진행되는 경우가 많습니다
일반적으로 설계를 생략하고 구현을 한다는 의미는 요구사항과 불일치 되는 위험이 매우 높으며, 제품의 품질 저하를 가져오거나, 재작업 등 비용을 상승시키는 요인으로 작용합니다.
특히 구현되어야 하는 솔루션의 명시적(Explicit) 표현(Documenting, Modeling, Capturing a design etc.)은 프로젝트 이해관계자와 의사소통이나, 의견조정을 가능하게 하고, 또한 제품의 유지보수(Maintenance)나 개선(Enhancement) 등을 유용하게 합니다.
하지만, 실제 현장의 차량 임베디드 소프트웨어 시스템에는 의미론 적인 방법의 부족 또는 리소스 및 일정 등의 이슈로 체계적으로 적용되지 않은 사례들이 많습니다. 현재는 Functional safety(ISO 26262) 및 Automotive SPICE® 등의 프로세스와 MBD(Model Base Development) 및 AUTOSAR(AUTomotive Open System Architecture) 등이 적용되면서 소프트웨어 아키텍처와 소프트웨어 상세 설계를 많이 수행하고 있는 상황입니다. 하지만 소프트웨어 아키텍처의 Hierarchy level을 결정하는 Granularity 부분에 대해서는 도메인 및 개발특성에 맞는 기준 없이 적용되고 있는 것도 사실입니다.
본 기사에서는 이러한 관점에서 아키텍처의 상세화 레벨과 유닛에 대해 간단하게 살펴보고자 합니다.
II. Definition of architectural design, detailed design, and unit
먼저 ISO/IEC 24765:2017에서는 “Architectural design”과 “Detailed design” 및 “Software unit” 다음과 같이 정의하고 있습니다. 소프트웨어 레벨에서 아키텍처는 소프트웨어 컴포넌트들과 컴포넌트들 간의 인터페이스를 정의하고, 소프트웨어 상세 설계는 해당 설계가 충분히 구현 가능한 범위까지의 컴포넌트들을 상세화 하는 단계로 기술하고 있습니다. 추가로 소프트웨어 유닛은 독립적으로 컴파일 가능한 코드 범위 및 독립적으로 테스트 가능한 소프트웨어 아키텍처의 가장 작은 단위의 소프트웨어 구성요소로 정의하고 있습니다.
“Architectural design” 1. process of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system 2. the result of defining a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system cf. functional design.
“Detailed design” 1. process of refining and expanding the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented 2. result of the process in (1) cf. software development process.
“Software unit” 1. atomic‐level software component of the software architecture that can be subjected to standalone testing [ISO/IEC TS 24748-1:2016 Systems and software engineering — Life cycle management — Part 1: Guide for life cycle management, 2.49] 2. separately compliable piece of code [ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes, 4.43].
ISO 26262와 Automotive SPICE®에서 요구하는 소프트웨어를 구성하는 용어를 정리하면, 아래 표와 같습니다.
즉, Software design은 다양한 레벨의 계층구조를 가질 수 있으며, 각 계층에는 SW component들의 요소(elements)와 관계들이 설명이 되어야 하며, 그 요소들을 구성하는 유닛들이 식별되고, 그 유닛(elements)들의 관계가 설명이 되어야 합니다. 이러한 근거가 되는 산출물이 SW 아키텍처 또는 SW 상세설계가 될 수 있으며, 필요에 따라 여러 개의 작업 산출물 또는 하나의 작업 산출물로 생성할 수 있습니다.
III. Functional safety에서 아키텍처 상세화 수준
ISO 26262; 2018 Part 6에서는 Software architecture design을 다음과 같이 설명하고 있습니다.
소프트웨어 아키텍처 설계는 모든 소프트웨어 엘리먼트(elements)와 그들 간의 상호작용들(interactions)을 정적인(Static) 측면에서 표현하고, 로직의 순서나 타이밍 관련 거동에 대한 동적인(Dynamic) 측면에서 표현해야 합니다. 그리고 소프트웨어 아키텍처의 Granularity level은 소프트웨어 유닛들이 식별될 수 있는 레벨까지 개발해야 되어야 한다고 요구하고 있습니다.
(The software architectural design shall be developed down to the level where the software units are identified. (7.4.4 Clause))
참고로, 안전 관련 요구사항과 일반 요구사항은 하나의 아키텍처에 포함되어야 하므로, 하나의 소프트웨어 개발 라이프사이클 동안 적용이 되길 요구하고 있습니다. (In order to develop a software architectural design both software safety requirements as well as all non-safety-related requirements are implemented. Hence in this sub-phase safety-related and non-safety-related requirements are handled within one development process. (7.2 Clause))
IV. Automotive SPICE®에서 아키텍처 상세화 수준
Software architecture design을 다음과 같이 기술하고 있습니다.
소프트웨어의 기능 및 비 기능 요구사항에 대응하는 소프트웨어 엘리먼트(element)들을 명세화 하는 구조적 설계를 개발하고 문서화합니다. (즉, 소프트웨어 엘리먼트(element)들로 분해하고 명세화 한다는 의미이며, 상세화 수준은 소프트웨어 컴포넌트(component) 수준까지 내려야 합니다. – 여기서 소프트웨어 컴포넌트(component)는 아키텍처의 가장 하위 모듈이며, 하나의 유닛(unit) 또는 복수개의 유닛(units) 포함할 수 있습니다.), 참고로 “소프트웨어 컴포넌트(component)는 상세 설계에서 기술된다.”라고 기술하고 있습니다.
즉 소프트웨어 컴포넌트레벨에서 모든 유닛(Unit)들을 기술하는 것을 필수적으로 요구하고 있지 않는다는 점이 ISO 26262와이 다를 수 있으며, 나머지는 동일하게 최 하위수준의 소프트웨어 컴포넌트까지 식별하여 정적인(Static)측면과 동적인(Dynamic)측면으로 표현하면 된다고 기술하고 있습니다.
V. 유닛의 정의는
그럼 Software architecture를 설계하기 위해, SW 컴포넌트의 구성요소인 유닛의 범위에 대해서는 다양한 의견이 있을 수 있으며, 아래 사항의 관점에서 유닛을 고려해야 합니다.
- SW의 기능 및 비기능적인 추적이 가능해야 하며, 그러기 위해서는 상세설계를 구성하는 유닛들은 의미(Sematic)를 가져야 한다.
- 유닛은 소스코드에서 구현 단위가 아닌, 상세설계에 명시된 구현을 위한 솔루션으로 정의해야 한다
- 분해할 수 없고, 논리적/일관된 동작의 설명 및 독립적인 검증이 가능해야 함.
- 유닛은 SW의 유닛 검증(유닛에 대항 정적 검증 및 동적 검증)이 가능해야 하므로, 만약 유닛 설계 기준으로 Cyclomatic complexity을 규제하고 있다면, 당연히 유닛 범위에 대한 상대적인 제약이 발생된다.
The boundary of a software unit is independent from the software unit’s representation in the source code, code file structure, or model-based implementation, respectively. It is rather driven by the semantics of the application domain perspective. Therefore, a software unit may be, at the code level, represented by a single subroutine or a set of subroutines. [A-SPICE 4.0 SWE.3 BP1]
VI. 결론적으로
Software architecture의 “계층구조의 수준”과 “컴포넌트(엘리먼트의) 정의”는 도메인 및 제품의 특성, 그리고 소프트웨어 복잡도에 따라 상이하게 정의가 가능하며, 하나의 기준이나 공통적인 기준을 강요해서는 안 됩니다. 하지만, 프로젝트 및 제품에 적용을 하기 위해서는 적어도 충분한 근거가 있고, 설명이 가능해야 합니다.
“소프트웨어 유닛이라는 정의”도 함수, Function/Sub-function, *.C 파일, 클래스 등 기계적으로 정의할 수 없으며, 적어도 SW의 요구사항을 설명하는 상세설계에 대해, 해당 상세설계를 구현 가능한 의미를 가진 엘리먼트 이어야 합니다. 그래서 하나의 C 파일이 유닛이 될 수도 있고, C 파일 내의 함수 또는 서브 함수들이 유닛이 될 수 있습니다. 물론 유닛에 대한 기준은 프로젝트 및 제품의 상황에 따라, 개발단계 초기에 정의할 수도 있고, SW 요구사항과, 아키텍처, 상세설계를 진행하면서 정의할 수도 있습니다.
참고사항 Application of SW engineering process according to SW architecture hierarchy
아래 표는 A-SPICE Guidelines (Draft 2nd edition)의 내용을 발췌하여 정리한 내용입니다. 붉은색 박스 영역에 대한 설계 단계와 검증단계에서의 A-SPICE V4.0 Process가 어떻게 연결되지 나타내고 있습니다.
㈜1 PAM V4.0에서는 심사를 위해 SWE.5에서 다루는 것으로 결정하였으나, 해당 소프트웨어 컴포넌트만을 개발하는 업체의 경우 및 프로젝트의 정황에 따라 SWE.6의 적용도 고려할 수 있다.
㈜2 유닛들 간의 인터페이스는 프로젝트 및 조직이 프로세스 요구사항에 따라 SW 상세 설계서 또는 SW 아키텍처 설계서에 식별 및 정의할 수 있다.
[Reference]
- ISO/IEC/IEE 24765(2017) Systems and software engineering — Vocabulary
- R, Nava. F, Duenas. J. C, (2007) Modeling and Documenting the Evolution of Architectural Design Decisions. 29th International Conference on Software Engineering Workshops (ICSEW’07)
- ISO 26262(Second edition), Road vehicle-Functional Safety-Part 6: Product development at the software level
- Automotive SPICE® Process Reference Model & Process Assessment Model Version 3.1
- Automotive SPICE® Process Reference Model & Process Assessment Model Version 3.991
- Automotive SPICE® Guidelines 1st edition, September 2017
- Automotive SPICE® Guidelines Draft version for 2nd Edition, May 2023