RIL (Requirements-In-the-Loop) — MBSE의 확장된 형태로, 시스템의 기능 요구사항을 정형 언어(Formal Language)로 모델링해 정의 단계부터 반복 실행·시뮬레이션으로 모호성·오류·누락·충돌을 사전에 식별·수정하는 모델 기반 요구사항 검증 방법. 다쏘시스템 STIMULUS가 대표 도구.
등장 배경 — 기존 V&V의 한계
기존 HIL은 정의된 요구사항을 기준으로 적합성을 평가하므로 요구사항 자체의 불명확성·오류 사전 식별에 한계. 자연언어로 작성된 초기 요구사항은:
- 본질적 모호성으로 다양한 해석 여지
- 안전·보안 요구사항에 치명적 영향 가능
- 복잡한 시스템에선 수많은 요구사항 간 상충 관계 모두 확인 어려움
- 요구사항 오류가 개발 후기에 발견될수록 수정 비용·시간 기하급수 증가
두 가지 요구사항 관점
| 관점 | 설명 | 예시 |
|---|---|---|
| What | 시스템이 수행해야 하는 동작·기능 | ”핸들 명령이 down일 때, 모든 랜딩기어는 15초 이내 확장되고 모든 도어는 닫혀야 한다” |
| How well | 기능 요구사항을 얼마나 잘 충족 — 안전·성능·사용성 등 품질 속성 | 15초 이내 모든 기어 확장·도어 닫힘 성공 여부 |
RIL 시뮬레이션은 주로 What 관점의 기능 요구사항에 집중.
STIMULUS — 핵심 기능
1. 요구사항 모델링 — 정형 언어 템플릿
레고 블록처럼 조합 가능한 문장 템플릿:
| 템플릿 | 의미 |
|---|---|
| When | 조건이 참일 때 특정 동작을 활성화하는 상태 기계(State machine) |
| is | 수학적 동등성 |
| shall be | 요구사항 조건 명시 |
→ 동일 의미의 요구사항을 누구나 동일하게 모델링·해석 가능.
용어집(Glossary): 시스템 변수·데이터 타입·물리 단위·범위 정의. 블록 다이어그램으로 시스템 구조 표현 — 각 요구사항이 어떤 하위 블록에 적용되는지 명확.
2. 요구사항 시뮬레이션
- 형식화된 요구사항 → 컴파일러로 제약조건 변환
- 시뮬레이터가 시간 흐름에 따라 활성 제약조건을 솔버에 전달
- 솔버가 부울·수치·시간 값을 모두 고려해 만족하는 동작 결정 → 시스템 출력
- 반복으로 실행 트레이스 생성
- 제약 충돌 발생(예: 동시에 문 열고 닫기) 시 시뮬레이션 중단 + 문제 요구사항 자동 알림
3. 시뮬레이션 결과 분석
| 결과 유형 | 의미 |
|---|---|
| 잘못된 요구사항 발견 | 시뮬레이션은 정상 실행되지만 결과가 원하는 동작과 다름 |
| 누락된 요구사항 발견 | 결과 일부 구간이 점선 — 해당 기간 어떤 요구사항도 값을 정의하지 않음 |
| 충돌하는 요구사항 발견 | 시뮬레이션 특정 시점 멈춤 — 솔버가 충돌 요구사항 최소 집합을 자동 제시 |
4. 옵저버(Observer)
- 검증된 요구사항을 옵저버로 설정해 시스템 입출력 신호 실시간 모니터링
- 미리 정의된 예상 동작과 실제 동작을 실시간 비교
- 요구사항 위반 발생 시 즉시 감지·기록 (차트 빨간색 표시)
활용 예 — 항공기 랜딩기어
에어버스 Safety First — Airbus A320 활주로 이탈 사고 두 건의 원인이 단일 잠금 센서 오류로 잘못된 다운록 표시. 개선을 위해 이중 잠금 센서 적용 시 새 기능 요구사항이 기존 복잡 아키텍처에 추가/수정될 때 모호·누락·충돌 가능성 큼 → RIL로 신중 검증.
STIMULUS ↔ Simulink Co-simulation 워크플로
- Simulink에서 기능 요구사항대로 제어 시스템(랜딩기어 수납·하강 사이클 + 센서 고장 디스플레이) 모델링
- STIMULUS에서 작성한 옵저버·테스트 시나리오를 FMU(Functional Mockup Unit) 형식으로 Simulink에 가져와 연동
- Simulink 모델이 옵저버 요구사항 위반 시 STIMULUS 시뮬레이션 패널에 Error Level·Message 제공 → 위반 위치 즉시 파악
- Simulink 모델 수정·재시뮬레이션 반복 → 초기 설계 단계부터 요구사항 오류·모호성·충돌 사전 해결
CATIA Magic ↔ STIMULUS ↔ Simulink 3 도구 통합
2025-05 신효주에 따르면 시스템 아키텍처 도구를 포함한 3 도구 통합 워크플로가 A320 랜딩기어 사례로 구체화된다:
- CATIA Magic — 시스템 아키텍처 정의
- Cyber MagicGrid 방법론의 5개 기둥(Requirements·Structure·Behavior·Parameters·Safety & Reliability)으로 문제·솔루션 도메인 구조화
- 이해관계자 요구 → 시스템 컨텍스트 → 유스케이스 → 개념 서브시스템 → 기능 분석 → 시스템·서브시스템·컴포넌트 요구사항 단계 상세화
- SysML BDD·IBD·상태·활동 다이어그램으로 표현
- STIMULUS — 요구사항 정형화·검증
- CATIA Magic 다이어그램·포트 정보가 STIMULUS에 완전 통합 → 단일 정보 원천(Single Source of Truth) 원칙
- 검증된 요구사항을 옵저버로 설정, 난수 생성으로 1,000회 시뮬레이션해 불일치·모순·정의되지 않은 상태 영역 식별
- Simulink — 제어 모델 통합 검증
- Simulink 제어 모델을 FMU로 내보내 STIMULUS 환경에서 옵저버와 함께 시뮬레이션
- 3가지 신호 차트(FMU 입력·출력·State Machine 옵저버) 동시 모니터링
- 옵저버 위반 표시 → Simulink 모델 수정 → 재시뮬레이션 반복 → 위반 해소
- 양방향 피드백 루프로 요구사항 ↔ 구현 일관성 지속 보장
효과
- 요구사항 재정의·코드 재작성·디버깅 시간 절약
- 다수 서플라이어 참여 대형 복합 시스템 개발에서 개발 반복 횟수 감소
- 시험 단계 테스트 시나리오 조기 정제로 개발 시간 단축
- 안전·보안 관점 고품질 요구사항 스펙 정의