SEBok - 시스템 아키텍처 (System Architecture)

안녕하세요. 자율주행 안전 전문가를 꿈꾸는 플라잉 준입니다.

 

오늘은 실무에서 시스템 엔지니어링 관련 업무를 하며 도움을 받았던 SEBok (Guide to the system engineering body of knowledge) 의 Part 3: SE and Management / System Definition 의 System Architecture 에 대한 내용을 정리해보도록 하겠습니다.

 

System Architecture - SEBoK

 

System Architecture

System Architecture 활동의 목적

• 원칙(원리), 컨셉, 속성간의 논리적인 관계 및 일관성을 기반으로 종합적인 솔루션을 정의하기 위함

솔루션 아키텍처는 기능, 속성 및 특성을 가지고 있음

• 시스템 요구사항과 수명주기 컨셉과 관련된 문제를 만족
• 기술 (e.g. 기계, 전자, 유압, 소프트웨어, 서비스, 절차, 인적 활동) 을 통해 구현될 수 있음

시스템 아키텍처

• 추상적이고 개념적이며 시스템의 미션 및 수명 주기를 달성하는데 중점을 둠
• 시스템 및 시스템 요소의 상위 수준 구조에 중점을 둠
• System-Of-Interest (SOI) 의 아키텍처 원칙, 컨셉, 속성 및 특성을 다룸
• 하나 이상의 시스템에 적용될 수 있으며, 유사한 시스템의 클래스 또는 제품군에 대한 공통 구조, 패턴 및 요구사항 집합을 형성할 수 있음

General Concept and Principles

Notion of Structure

시스템 아키텍처에 대한 대부분의 해석은 구조에 대한 개념 (i.e. 요소 간의 관계)를 기반으로 함

 

Architecture Description of the System

아키텍처 프레임워크 시스템 아키텍처의 여러 관점을 개발하는데 도움을 주며 다음을 포함함

• Standardized viewpoint
• View templates
• Meta-models
• model template 

 

Viewpoint 는 특정 이해 관계자의 관심사 (관련된 일련의 관심사) 를 다룸

Viewpoint 는 해당 문제 (일련의 문제) 를 해결하기 위해 시스템 아키텍처를 개발하는데 사용할 모델의 종류, 모델이 생성되어야 하는 방법, 모델이 관련 되고 view 를 구성하는 방법을 지정함

 

시스템 아키텍처의 기본 측면을 나타내는데 자주 사용되는 모델

• 논리적 모델 (Logical Model/View)
• 물리적 모델 (Physical Model/View)

시스템 아키텍처가 이해 관계자의 관심사를 해결하는 방법을 나타내기 위해 다른 보완적인 Viewpoint 및 View 가 사용됨

• 비용 모델 (Cost Model)
• 프로세스 모델 (Process Model)
• 규칙 모델 (Rule Model)
• 존재론적 모델 (Ontological Model)
• 프로젝트 모델 (Project Model)
• 신뢰 모델 (Belief Model)
• 기능 모델 (Capability Model)
• 데이터 모델 (Data Model)
• 등

Classification of Principles and Heuristics (원칙(원리) 및 발견적 분류)

엔지니어와 아키텍트는 수학적 원칙 (Mathematical Principels)와 경험적 방법 (Heuristics)을 혼합하여 시스템 아키텍처를 개발함

• 경험적 방법은 경험을 통해 배운 것이지만 수학적으로 입증되지는 않음

 

시스템 요구사항을 통해 문제를 식별하고 정의할 때 원칙과 경험적 방법으로 문제를 해결할 수 도 있고 해결하지 못할 수도 있음

수학적 원칙과 경험적 방법은 시스템 모델이 사용되는 영역에따라 다음과 같이 분류할 수 있음

• Static domain
  • 시스템 및 시스템 요소로 세분화된 SoI 의 물리적 구조 또는 조직과 관련됨
  • 분할된 시스템, 시스템 요소, 물리적 인터페이스를 다룸
• Dynamic domain
  • 논리적 아키텍처 모델과 관련되고 시스템의 동작을 표현
  • 기능에 대한 설명 (입력 흐름을 출력 흐름으로 변환)과 시스템 기능 간의 상호 작용과 외부 개체 또는 시스템 기능 간의 상호작용이 포함
  • 시스템의 기능 실행을 시작하거나 중지하는 이벤트에 대한 반응을 고려함
  • 시스템의 효율성 (성능, 운영 조건)을 다룸
• Temporal domain
  • 시스템 기능 실행의 시간적 불변성 수준과 관련됨
  • 모든 기능이 주기적 또는 동기적 특성에 따라 실행됨을 의미함
  • 일부 기능 동작의 비동기 특성인 결정 수준이 포함됨
• Environmental domain
  • 조력자 (생산, 물류 지원 등) 뿐만 아니라 자연 재해 또는 위협에 대응하는 시스템의 생존 가능성 및 내부 잠재적 위험에 대응하는 시스템의 무결성과 관련됨
  • 기후, 기계, 전자기, 생물학적 측면이 포함됨

Transition from System Requirements to Logical and Physical Architecture

아래에서 설명할 해당 접근 방식의 목표

• 시스템 요구사항에서 시작하여 중간 모델인 논리적 아키텍처 모델의 요소를 물리적 아키텍처 모델의 시스템 요소에 할당하기 위함
  • 시스템 요구사항은 기술과 무관한 공급자/설계자의 관점에서 문제를 나타냄

시스템 요구사항과 논리적 아키텍처 모델은 구현과 별개로 기능 관점으로 여러 특성을 공유함

 

설계 결정 및 기술 솔루션은 성능 기준 및 비기능적 요구사항에 따라 결정됨

• 운영 조건, 수명 주기 제약 조건 (e.g. 환경 조건, 유지보수 제약 , 실현 제약 등)

중간 모델 (논리적 아키텍처) 을 생성하면 시스템 요구사항에 대한 시스템의 기능적, 행동적, 시간적 속성의 검증이 용이함

• 시스템 요구사항은 기술과 솔루션에 독립적임

Iterations between Logical and Physical Architecture Model Development

아키텍처 활동은 논리적 아키텍처 모델 개발과 물리적 아키텍처 모델 개발 사이에서 이 두 모델이 일관되고 필요한 세부 수준으로 분석될 때 까지 여러번 반복해야 함

첫 번째 아키텍처 활동

• 기능의 일반 시나리오를 기반으로 논리적 아키텍처 모델 생성
• 시스템 기능을 수행할 수 있는 주요 시스템 요소를 결정하고 구성하여 물리적 아키텍처 모델 생성

후속  아키텍처 활동

• 시스템 요소에 대한 기능 할당과 물리적 솔루션 선택에서 파생된 기능을 고려하여 논리적 아키텍처 개선
• 일반 시나리오 이외의 예외 시나리오, 대안 시나리오와 오류 번석 및 운영 요구사항을 고려하여 논리적 아키텍처 개선
• 개선된 논리적 아키텍처를 기반으로 물리적 아키텍처도 개선
  → 후속 아키텍처 활동은 솔루션에 대한 완전하고 일관된 논리 & 물리 아키텍처를 만드는데 중점을 둠

위의 아키텍처 활동을 진행하면, 기술 / 솔루션을 결정짓게 되며 이는 새로운 기능, 입력, 출력 및 제어 흐름, 물리적 인터페이스를 필요로 할 수 있습니다.

→ 이러한 새로운 요소 (기능, 입/출력, 제어 흐름, 동작 조건, 인터페이스 등)는 Derived requirement 라고 하는 새로운 시스템 요구 사항임

 

Notion of Interface

인터페이스

• 시스템의 아키텍처를 정의할 때 중요한 요소 중 하나임
• 기본적인 측면은 기능적이며 기능의 입력과 출력으로 정의됨
• 물리적 인터페이스 (physical interface) : 기능이 물리적 요소 (시스템 요소)에 의해 수행되기 때문에 기능의 입력/출력도 물리적 요소에 의해 수행됨
• 기능적 측면과 물리적 측면이 모두 고려되어야 함

• 인터페이스에 대한 상세한 분석은 다음 3가지 기능을 정리하는 것
  "전송 (Send)" : 하나의 시스템 요소에 있는 기능
  "수신 (Receive)" : 다른 시스템 요소에 있는 기능
  "이동 (Carry)" : 입/출력 흐름을 지원하는 물리적인터페이스에 의해 수행되는 기능 
• Software intensive system 에서 시스테 요소 간의 복잡한 교환 매락에서 "프로토콜 (Protocol)" 은 데이터 교환을 수행하는 물리적 인터페이스로 간주됨
• 입력 / 출력 정보에는 데이터 이외의 에너지, 빛 등 여러 요소가 있을수 있음

Emergent Properties

시스템의 중요한 아키텍처는 시스템 요소 간의 배치 및 상호작용에서 나타나는 설계 속성 및 운영 효과를 가짐

• 요소들은 서로 상호작용하며 바람직하거나 바람직하지 않은 현상 (e.g. inhibition, interference, resonance 또는 reinforcement of any property) 을 생성할 수 있음
• 시스템의 정의에는 바람직하지 않은 속성 (Property) 을 방지하고 바람직한 속성 (Property) 을 강화하기 위해 시스템 요소 간의 상호작용 분석이 포함
• 시스템에서 나오는 속성 (Property) 은 단일 시스템 요소에서부터 여러 요소 간의 상호작용에 이르기까지 다양한 원인이 존재함
• Emergent Properties 는 시스템 에서 나타나는 속성을 식별하는데 사용
  
  • 예상치 못한 속성 및 시스템 개발 중 고려되지 않고 동작 중 발견된 속성 을 설명 하는데 사용
  • Synerge and reserve emergent property 라고도 불림

Broad Categories of Properties	Description and Examples
Local Property	단일 시스템 요소에 있는 속성 (Property) E.g. 컨테이너의 용량은 시스템의 용량
Accumulative System Property	속성은 여러 시스템 요소에 존재하며 전체 속성은 개별 속성들의 합으로 구할 수 있음 E.g. 시스템의 가중치는 시스템 요소의 가중치 합
Emergent Property Modified by Architecture and/or Interactions	속성은 여러 시스템 요소에 존재하며 요소간의 상호작용에 의해 수정됨 E.g. 시스템의 신뢰성/안전성은 각 시스템 요소의 신뢰성/안전성 구성 방식에서 비롯됨 아키텍처 단계는 시스템 요구 사항을 충족하는데 중요함
Emergent Property Created by Interactions	속성은 시스템 요소에 존재하지 않으며 상호 작용의 결과로만 나타남 E.g. 전자기계 인터페이스 (Electromechanical interfaces), 전자기 (Electromagnetism), 정전기 (Static electricity) 등
Controlled Emergent Property	시스템 외부로 나가기 전에 제어되거나 금지되는 속성 E.g. 부하 추가로 인해 제거된 불균형, 댐퍼에 의해 감쇠된 진동

 

물리적 아키텍처 설계

• 가능한 Synerge and emergent property 의 식별하는 것을 포함
• 허용 가능한 한도 내에서 특정 속성을 방지, 완화 또는 억제 하기 위한 논리적 물리적 아키텍처 모델에 파생된 기능, 구성요소, 배열, 환경적 제약을 포함하여 하는 것이 포함

Reuse of System Elements

시스템 엔지니어는 신규 시스템 개발시 기존 시스템 요소를 활용할 수 있음

재사용 제약은 시스템 요구 사항으로 식별되어야 하며 아미텍처 및 설계 중에 신중히 고려되어야 함

시스템 요소의 재사용 관련하여 아래 표와 같이 세가지 일반적인 경우로 고려할 수 있음

Re-use Case	Actions and Comments
Case 1 시스템 요소의 요구 사항은 최신 상태이며 수정할 필요 없이 재사용 됨	정의할 시스템 아키텍처는 경계, 인터페이스, 기능, 효율성 및 재사용된 시스템 요소의 동작에 적응해야 함 시스템 요소가 조정되지 안흥면 비용, 복잡성 및 위험이 증가할 가능성이 높음
Case 2 시스템 요소의 요구 사항은 최신 상태지만 수정하여 재사용 해야 함	정의할 시스템 아키텍처는 경계, 인터페이스, 기능, 효율성 및 재사용된 시스템 요소의 동작을 수용할 수 있을만큼 충분히 유연해야 함 테스트 보고서 및 기타 문서를 포함하여 재사용된 시스템 요소의 설계가 평가되고 잠재적으로 재설계됨
Case 3 요구사항이 최신 상태가 아니거나 관련 문서가 없을 수 있음	경계, 인터페이스, 기능, 성능 및 동작을 식별하기 위해 시스템 요소를 리버스 엔지니어링 해야 함 재사용된 시스템 요소에 대한 현존 문서가 없거나 불충분할 수 있기 때문에 이것은 어려운 활동 리버스 엔지니어링은 시간과 비용 면에서 비용이 많이 들고 위험이 증가

 

Process Approach

Purpose

시스템 아키텍처 프로세스의 목적

1. 시스템 아키텍처 대안을 생성
2. 이해 관계자의 관심사를 구성하며 시스템 요구사항을 충족하는 하나 이상의 대안을 선택
3. 일관된 관점에서 이를 표현하는 것

 

시스템 아키텍처  활동은 System Definition 및 Concept definition 활동가 중복됨

• 특히, 운영 및 비즈니스 컨텍스트의 주요 측면 및 이해 관계자의 요구사항은 아키텍처 개발 및 설명에 대한 접근 방식에 큰 영향을 미침
• 아키텍처 활동은 솔루션 합성 (Solution synthesis)에 대한 접근 방식이 무엇이든 선택을 주도하고 그안에 맞음

 

Activities of the proess

주요 활동 및 작업은 아래와 같음

1.  시스템 아키텍처 정의 초기화 (Initialize the definition of the system architecture)
   1. 시스템이 필요한 환경/문맥에 대한 이해를 구축
      1. 이해 관계자의 관심사에 대한 통찰력을 확립하기 위함 
      2. 관련 시장, 산업, 이해 관계자, 기업, 비즈니스, 운영, 사명, 법률 및 기타 정보를 분석하여 시스템 아키텍처 모델의 정의를 가이드 할 수 있는 관점을 이해하는데 도움을 줌
   2. 시스템 수명 주기 단계에 걸쳐 이해 관계자의 관심 사항 (e.g. 기대, 제약 조건) 을 캡처함 (도출함)
      1. 관심 사항은 단계와 관련된 시스템의 중요한 특성과 관련됨
         1. 위의 관심 사항, 및 특성은 시스템 요구사항으로 번역되거나 통합되어야 함 (→ derived requirement)
   3. 아키텍처 요소 정의에 영향을 미칠 수 있는 시스템 요구사항에 태그 지정
      1. 시스템 요구사항 : 운영 조건 (e.g. 안전, 보안, 신뢰성, 인적 요소, 인터페이스, 환경 조건)
      2. 시스템 요구사항 : 수명 주기 제약 (e.g. 유지 관리, 폐기, 배포)
   4. 아키텍처 로드맵 및 전략을 수립
      1. Method, modeling technique, tools, 제품, 서비스, 프로세스 요구사항 (e.g. Measurement approach and method), 평가 프로세스 (e.g. review and criteria)
   5. 제품 또는 서비스를 가능하게 하는 계획 수립(필요, 요구사항, 조달)
2. 아키텍처 모델 정의
   1. Architecture viewpoint and architecture framework 정의
      1. 모델 및 View 의 개발을 지원할 수 있음
      2. 이해 관계자의 관심을 기반으로 정의할 필요가 있음
3. 후보 아키텍처 모델 및 View 개발
   1. System-of-interest context 결정
      1. 외부 요소와의 경계를 포함
      2. 이해 관계자의 니즈 요구사항 프로세스, 시스템 요구사항 프로세스와 함께 관련 모델링 기술 및 툴 사용
   2. 아키텍처 요소 정의
      1. e.g. 기능, 입출력 흐름, 시스템 요소, 물리적 인터페이스, 아키텍처 특성, 정보/데이터 요소, 컨테이너, 노드, 링크, 커뮤니케이션 자원 등
      2. 서로 다른 시스템 요구사항에 대해 설명 할 수 있음
         1. 기능 요구사항, 인터페이스 요구사항, 환경 요구사항, 동작 요구사항 (dependability, 인적 요소 등), 컨테이너 (물리적 치수, 생산, 유지보수, 폐기)
   3. 아키텍처 요소 연결
      1. 시스템 아키텍처를 결정하는데 영향을 미치는 개념, 속성, 특성, 동작, 기능, 제약 조건과 엔티티 연결
      2. 아키텍처 특성 (e.g. 일반성, 모듈성, 운용성, 효율성, 단순성) 을 발생
   4. 시스템의 후보 아키텍처 모델 선택, 조정, 개발
      1. Logical Architecture Model Development
      2. Physical Architecture Model Development
      3. 위의 두 모델을 사용하는 것이 충분하지 않을 수 있음
      4. 필요하면 다른 모델도 추가로 사용
   5. 후보 아키텍처 모델을 이용하여 이해 관계자의 관심사항, 중요한 요구사항과 관련된 View 를 구성
   6. derived system requirement 정의
      1. 아키텍처 엔티티 (e.g. 기능, 인터페이스) 의 필요한 인스턴스 및 구조적 성향 (e.g. 제약조건, 운영조건) 에 의해 도출
      2. System requirement definition process 를 이용하여 정의
   7. 모델 및 뷰의 일관성을 확인하고 식별된 이슈 해결
   8. 실행 또는 시뮬레이션을 통해 모델을 확인하고 검증
      1. 설계 도구를 사용하여 타당성과 유효성을 확인하고 부분 모형을 구현하거나 실행 가능한 아키텍처 프로토타입 또는 시뮬레이터를 사용
4. 시스템 아키텍처를 시스템 설계에 연결
   1. 아키텍처 특성을 반영하는 시스템 요소를 정의
      1. 아키텍처 특성과 시스템 요구사항을 시스템 요소에 분할, 정렬 및 할당
   2. 아키텍처의 세부 수준 및 이해에 필요한 인터페이스 정의
      1. 시스템 요소 간의 내부 인터페이스 포함
      2. 다른 시스템과의 외부 인터페이스 포함
   3. 시스템 요소에 적용 가능한 디자인 속성 결정
      1. 아키텍처 특성을 만족시키기 위함
   4. 시스템 요소에 대한 요구사항을 개발
      1. 시스템 요소에 대한 설계 속성, 시스템 요구사항 할당,정렬 및 분할
5. 아키텍처 후보를 평가하고 하나 선택
   1. 아키텍처 평가 기준을 사용하여 후보 아키텍처를 평가
      1. 시스템 분석, 측정, 위험 관리 프로세스 적용을 통해 수행
   2. 아키텍처 선택
      1. Decision Management Process 적용을 통해 수행
6. 선택된 아키텍처 관리
   1. 아키텍처 관련 모든 내용에 대한 근거를 설정하고 유지함
      1. 아키텍처, 아키텍처 프레임워크, viewpoint, 모델 종류, 아키텍처 대안 및 결정
   2. 아키텍처 설명의 유지 관리 및 발전을 관리
      1. 아키텍처 설명 : 일치성, 완전성, 환경 및 컨텍스트 변경으로 인한 변경, 기술, 구현 및 운영 경험 포함
      2. 할당 및 추적 메트릭스는 아키텍처에 대한 영향을 분석하는데 사용
   3. 아키텍처의 Governance 수단 설정
      1. Governance 에는 역할, 책임, 권한 및 기타 아키텍처 제어 등이 포함됨
   4. 이해 관계자의 동의를 얻기 위해 아키텍처 검토를 조정

Artifacts, Methods and Modeling Techniques

산출물

• System architecture description documents
• System justification documents (추적성 메트릭, 아키텍처 선택)

산출물의 형식, 레이아웃, 상세 내용 등은 산출물을 만드는 사람과 사용되는 도메인에 따라 다름

 

Practical Considerations

Pitfalls

시스템 아키텍처 계획 및 실행 하면서 만날 수 있는 몇가지 Pitfall (함정)

Ptifall	Description
Problem Relevance	아키텍처가 이해 관계자의 관심사로부터 입력 없이 개발되거나 이해되지 않고 문제와 다시 관련될 수 었는 경우 이해 관계자의 투자를 잃을 수 있음
Reuse of System Elements	일부 프로젝트에서는 산업적 목적을 위해 기존 제품 또는 서비스가 포함된 시스템 사용의 새로운 컨텍스트에 충분한 주의를 기울이지 않고 이해 관계자 요구 사항 또는 시스템 요구 사항에서 아키텍처/설계 제약으로 매우 일찍 부과됨 처음부터 올바른 방향으로 작업하는 것이 좋음 먼저 시스템을 정의하고 다른 요구 사항을 확인한 다음 적절한 NDI(비개발 항목)를 사용할 수 있는지 확인 거래 공간을 줄이는 시스템 요소를 처음부터 부과하지 않아야 함 올바른 재사용 프로세스는 모든 사용 컨텍스트에서 재사용 가능한 시스템 요소를 정의하는 것으로 구성됨

 

Proven Practices

Practice	Description
Emerging properties	시스템 또는 시스템 요소 간 상호작용과 관련된 Emergent property 를 제어 필요한 Synergy 특성을 얻고 바람직하지 않은 동작 (e.g. 진동, 소음, 불안정, 공명 등) 을 제어하거나 방지함