임베디드 스터디 - 요구사항 분석 / 시스템 아키텍처

요구사항의 종류

• 요구사항은 기능 요구사항과 비기능 요구사항으로 나뉜다.

• 기능 요구사항 : 시스템이 무엇을 하는가 (What)
  • 검증 방법 : Pass/Fail
  • 예) 센서 데이터를 읽어 액추에이터를 제어해야 한다
• 비기능 요구사항 : 시스템이 얼마나 잘 하는가 (How well)
  • 검증 방법 : 수치 측정
  • 세부 유형 :

유형	예시
성능 (Performance)	자세제어 루프는 100ms 이내에 완료
정확도 (Accuracy)	자세 오차 ±0.1° 이내 유지
신뢰성 (Reliability)	단일 센서 고장 시에도 동작 지속
제약 (Constraint)	C99 표준으로 작성
가용성 (Availability)	연간 99.9% 이상 정상 동작
보안 (Security)	명령어 인증 없이 실행 불가

임베디드/항공우주 실무에서 비기능 요구사항은 측정 가능한 수치로 명세해야 한다.
DO-178C에서도 측정 방법까지 함께 명세할 것을 요구한다.

좋은 요구사항의 조건

• 아래 두 요구사항을 비교해보자.

A: "시스템은 빨라야 한다"
B: "자세제어 루프는 최악 조건에서 100ms 이내에 완료되어야 한다"

• A는 “빠르다”는 기준이 사람마다 다르고 측정할 수 없다. B는 조건·대상·수치가 명확하다.

• IEEE 830 기준 좋은 요구사항의 조건:

• 명확성 (Unambiguous) : 해석이 하나로 수렴해야 함
• 측정 가능성 (Measurable) : 수치로 검증 가능해야 함
• 추적 가능성 (Traceable) : 어떤 기능에 해당하는지 식별 가능해야 함
• 완전성 (Complete) : 조건·예외 상황까지 명세해야 함
• 일관성 (Consistent) : 다른 요구사항과 충돌하지 않아야 함
• 실현 가능성 (Feasible) : 주어진 HW에서 달성 가능한 수치여야 함

임베디드에서 실현 가능성이 특히 중요하다.
타깃 MCU 성능 확인 없이 요구사항을 작성하면, 요구사항 자체가 잘못된 것이다.

유스케이스 (Use Case)

• 유스케이스는 요구사항을 수집하고 정리하는 도구다.
• 작성 전 가장 먼저 결정해야 하는 것이 시스템 경계(System Boundary) 다.

경계를 어디로 잡느냐에 따라 Actor가 완전히 달라진다.

• 경계를 OBC SW로 잡으면 통신 서브시스템·DAQ·스케줄러가 시스템 밖으로 나와 Actor가 된다.

• 명령 처리에 스케줄러가 Actor인 이유 : 지상국과 교신이 끊긴 상태에서도 자율적으로 자세제어·배터리 모니터링·페일세이프 체크가 실행되어야 하기 때문
• 큐브위성은 지상국과 교신 가능한 시간이 하루 수 분에 불과 → 스케줄러 기반 자율 동작이 주된 운용 모드

시스템 아키텍처 패턴

• 유스케이스로 무엇을 할지 정의했으면, 어떻게 구조를 잡을지가 시스템 아키텍처다.
  대표적인 4가지 패턴을 큐브위성 OBC SW에 대입해보자.

레이어드 (Layered)

• 전체 구조의 뼈대. 상위 레이어는 하위 레이어에만 의존한다.

• 강점 : HW가 바뀌어도 HAL만 수정하면 상위 레이어는 그대로
• 실무 예 : RTOS 기반 OBC에서 드라이버/미들웨어/앱 계층 분리

이벤트 드리븐 (Event-Driven)

센서 인터럽트, 서브시스템 IPC, 타이머 이벤트 처리에 사용.

• 강점 : 비동기 처리, CPU 낭비 없이 이벤트 기반 반응
• 실무 예 : IMU 데이터 수신 인터럽트 → 큐 → 자세제어 태스크

파이프-필터 (Pipe-Filter)

RF 수신 데이터 처리 파이프라인에 사용.

• 강점 : 각 단계가 독립적 → 필터 교체·추가 용이
• 실무 예 : CCSDS 프로토콜 스택이 정확히 이 구조

클라이언트-서버 (Client-Server)

지상국↔위성 통신 구조.

• 강점 : 역할 분리 명확, 요청-응답 구조 단순
• 실무 예 : TC/TM(Telecommand/Telemetry) 통신

큐브위성 OBC 혼합 아키텍처 (Hybrid Architecture)

실무에서는 단일 패턴만 쓰는 경우가 거의 없다.
각 관심사(concern)에 맞는 패턴을 계층별로 선택하는 것이 현실적이다.

이 구조는 CCSDS 표준 아키텍처와 유사하다.
DO-178C는 특정 아키텍처를 강제하지 않으나, 계층 간 인터페이스와 추적성을 명확히 문서화할 것을 요구한다.

정리

요구사항 분석
├── 기능 요구사항   : 무엇을 하는가 → Pass/Fail 검증
├── 비기능 요구사항 : 얼마나 잘 하는가 → 수치 측정 검증
└── 좋은 요구사항  : 명확·측정가능·추적가능·완전·일관·실현가능

유스케이스
├── 시스템 경계를 먼저 정의
├── 경계 밖 상호작용 주체 = Actor
└── Actor는 사람뿐 아니라 시스템·타이머·스케줄러도 포함

시스템 아키텍처 패턴
├── 레이어드       : 전체 구조 뼈대, HW 독립성 확보
├── 이벤트 드리븐  : 센서·인터럽트·IPC 비동기 처리
├── 파이프-필터    : RF 수신 데이터 처리 파이프라인
└── 클라이언트-서버: 지상국↔위성 TC/TM 통신