들어가며
MBSE(Model-Based Systems Engineering)를 처음 접하면 다양한 SysML 다이어그램을 만나게 된다. Activity Diagram, Sequence Diagram, State Machine Diagram 등 여러 종류가 있지만, 시스템의 전체 구조를 이해할 때 가장 먼저 활용되는 다이어그램이 바로 BDD(Block Definition Diagram)이다.
제가 MBSE를 처음 공부했을 때도 가장 먼저 익힌 다이어그램이 BDD였다. 이유는 단순했다. 시스템이 어떤 구성요소로 이루어져 있는지 이해하지 못하면 기능이나 동작을 모델링하기 어렵기 때문이다.
건물을 설계할 때도 먼저 전체 구조를 파악한 뒤 내부 공간과 설비를 설계하듯, MBSE에서도 시스템의 큰 틀을 정의하는 과정이 중요하다. 이번 글에서는 BDD의 개념과 구성 요소, 실제 활용 사례를 중심으로 살펴본다.
BDD란 무엇인가?
BDD(Block Definition Diagram)는 시스템을 구성하는 블록(Block)과 블록 사이의 관계를 표현하는 SysML 다이어그램이다.
여기서 블록(Block)은 시스템을 구성하는 하나의 요소를 의미한다.
블록은 다음과 같이 다양한 대상을 표현할 수 있다.
- 하나의 시스템
- 하위 시스템
- 하드웨어 장치
- 소프트웨어 모듈
- 센서
- 제어기
- 사람(운영자)
- 외부 시스템
즉, BDD는 시스템을 구성하는 주요 요소들을 계층적으로 정리한 설계도라고 이해하면 된다.
블록(Block)은 무엇을 표현할까?
블록은 단순히 이름만 적어두는 상자가 아니다.
필요에 따라 다양한 정보를 함께 표현할 수 있다.
예를 들어 자율주행 차량 시스템의 블록이라면 다음과 같은 속성을 포함할 수 있다.
- 블록 이름
- 주요 기능
- 내부 구성요소
- 제공하는 인터페이스
- 연결 대상
- 주요 속성
이러한 정보를 통해 개발자는 각 구성요소의 역할을 쉽게 이해할 수 있다.
BDD에서 자주 사용하는 관계
BDD에서는 블록만 그리는 것이 아니라 블록 간의 관계도 함께 표현한다.
관계를 이해하면 다이어그램을 훨씬 쉽게 읽을 수 있다.
Composition(합성)
하나의 블록이 다른 블록을 포함하는 관계이다.
예를 들어 자동차 시스템은 다음과 같은 하위 블록으로 구성될 수 있다.
- 엔진
- 변속기
- 제동장치
- 조향장치
- 전장 시스템
자동차가 상위 블록이고 각각의 장치가 하위 블록이 된다.
Association(연관)
두 블록이 서로 정보를 주고받거나 협력하는 관계를 나타낸다.
예를 들어 카메라 센서가 영상 처리 모듈과 데이터를 주고받는 경우 연관 관계로 표현할 수 있다.
Generalization(일반화)
상위 개념과 하위 개념의 관계를 표현한다.
예를 들어 "센서"라는 상위 블록 아래에
- 카메라 센서
- 레이더 센서
- 라이다 센서
를 배치하여 공통 특성과 개별 특성을 표현할 수 있다.
드론 시스템으로 살펴보는 BDD 예시
드론을 예로 들어보면 BDD는 다음과 같은 형태로 구성될 수 있다.
드론 시스템
- 비행 제어 컴퓨터
- GPS 모듈
- 카메라
- 모터
- 배터리
- 통신 모듈
- 장애물 감지 센서
각 블록은 다시 하위 블록으로 세분화될 수 있다.
예를 들어 통신 모듈은 안테나, 송수신기, 프로토콜 처리 기능으로 구성될 수 있으며, 카메라 블록은 이미지 센서와 영상 처리 장치로 나눌 수 있다.
이처럼 시스템을 단계적으로 분해하는 것이 BDD의 핵심 역할이다.
BDD와 IBD는 어떻게 다를까?
MBSE를 처음 공부하면 BDD와 IBD(Internal Block Diagram)를 혼동하는 경우가 많다.
두 다이어그램은 서로 보완 관계에 있다.
BDD
- 시스템의 전체 구조를 표현한다.
- 어떤 블록이 존재하는지 보여준다.
- 계층 구조를 이해하는 데 적합하다.
IBD
- 블록 내부 연결을 표현한다.
- 데이터와 신호의 흐름을 보여준다.
- 인터페이스를 분석하는 데 적합하다.
간단히 말하면 BDD는 "무엇으로 구성되어 있는가"를, IBD는 "어떻게 연결되어 있는가"를 설명한다.
BDD를 먼저 작성하는 이유
많은 MBSE 프로젝트에서는 요구사항 분석 이후 BDD를 먼저 작성한다.
그 이유는 시스템의 범위를 명확히 정의할 수 있기 때문이다.
예를 들어 프로젝트 초기에 시스템의 구성 요소를 합의하면 이후 기능 모델과 인터페이스 모델도 일관성 있게 작성할 수 있다.
반대로 구조가 명확하지 않은 상태에서 기능 모델을 작성하면 중복되거나 누락되는 요소가 발생하기 쉽다.
BDD 작성 시 고려할 점
실무에서는 단순히 블록을 많이 만드는 것이 좋은 모델은 아니다.
다음과 같은 원칙을 고려하면 관리하기 쉬운 모델을 만들 수 있다.
의미 있는 수준으로 분해하기
너무 큰 블록은 역할이 모호해지고, 너무 작은 블록은 모델이 복잡해질 수 있다.
프로젝트 목적에 맞는 수준으로 계층을 구성하는 것이 중요하다.
이름을 일관성 있게 사용하기
블록 이름은 프로젝트 전체에서 동일한 기준을 유지해야 한다.
예를 들어 어떤 문서에서는 "제어기", 다른 모델에서는 "컨트롤러"라고 표현하면 혼란이 생길 수 있다.
요구사항과 연결하기
BDD의 각 블록은 관련 요구사항과 연결해 두는 것이 좋다.
이렇게 하면 특정 요구사항이 어떤 구성요소와 관련되는지 쉽게 확인할 수 있다.
변경 사항을 지속적으로 반영하기
프로젝트가 진행되면서 시스템 구조가 변경될 수 있다.
BDD 역시 최신 설계 상태를 반영하도록 관리해야 모델의 신뢰성을 유지할 수 있다.
실무에서 BDD가 활용되는 분야
BDD는 다양한 산업에서 시스템 구조를 정의하는 기본 모델로 사용된다.
대표적인 활용 사례는 다음과 같다.
- 자동차 전장 시스템
- 항공기 제어 시스템
- 인공위성 개발
- 철도 신호 시스템
- 산업용 로봇
- 스마트팩토리 설비
- 무인 이동체
- 의료기기
산업 분야는 다르더라도 시스템을 구성 요소로 나누고 관계를 정의한다는 기본 원리는 동일하다.
마무리
BDD(Block Definition Diagram)는 MBSE에서 시스템의 구조를 이해하기 위한 가장 기본적인 다이어그램이다.
시스템을 구성하는 블록과 그 관계를 계층적으로 표현함으로써 프로젝트 참여자들이 동일한 관점에서 시스템을 이해할 수 있도록 돕는다.
BDD가 시스템의 '뼈대'를 만든다면, 이후 작성하는 IBD는 각 구성요소가 실제로 어떻게 연결되고 상호작용하는지를 보여준다. 두 다이어그램은 함께 사용할 때 더욱 큰 효과를 발휘한다.
다음 글에서는 IBD(Internal Block Diagram)를 중심으로 데이터 흐름과 인터페이스를 모델링하는 방법을 살펴본다.
FAQ
Q1. BDD는 소프트웨어 구조도와 같은 개념인가요?
아니다. BDD는 소프트웨어뿐 아니라 하드웨어, 사람, 외부 시스템 등 시스템 전체를 구성하는 요소를 표현하는 SysML 다이어그램이다.
Q2. BDD를 작성한 후 반드시 IBD도 작성해야 하나요?
필수는 아니다. 프로젝트 목적에 따라 BDD만 사용하는 경우도 있지만, 인터페이스와 데이터 흐름을 상세하게 분석해야 한다면 IBD를 함께 작성하는 것이 일반적이다.
Q3. BDD는 프로젝트 초기에만 사용하는 다이어그램인가요?
초기 시스템 구조를 정의할 때 많이 활용되지만, 프로젝트가 진행되며 구조가 변경될 경우 지속적으로 업데이트하여 최신 상태를 유지하는 것이 중요하다.