MBSE에 통합된 RIL 검증 방법은 잘못된 요구사항이 큰 피해를 가져올 수 있는 안전 필수 시스템(Safety-Critical Systems) 개발에서 요구사항 정의부터 구현까지 일관된 검증 체계를 마련함으로써 시스템의 안전성(Safety)을 크게 향상시키는 효과적인 접근법이다. MBSE를 통해 얻게 되는 시스템 아키텍처 모델의 요소들을 살펴보고 체계적인 요구사항 검증을 위한 환경 구성으로 옵저버(Observer)를 통한 요구사항 모니터링, 다양한 오류를 검출하고 수정하는 방법에 대해 설명한다. 

글 | 신효주, 다쏘시스템코리아

신효주
다쏘시스템코리아에서 Industry Process Consultant로 모델 기반 시스템 엔지니어링(Model-Based Systems Engineering, MBSE) 솔루션을 담당하고 있다. 자동차, 항공, 전자제품 등 다양한 산업 분야에서 프로젝트를 수행하며 복잡한 시스템 개발 과정에서의 어려움을 파악하고 이를 해결하기 위한 방법론과 MBSE 기반의 솔루션을 제안하고 있다. 특히, 요구사항 검증 및 시스템 아키텍처 방법론을 중심으로 고객의 개발 효율성과 품질 향상을 지원하는 역할을 수행한다.







지난 글에서 현대의 증가된 시스템/소프트웨어의 복잡성(Complexity)과 불확실성(Uncertainty)을 해결하기 위해 많은 사용자는 시스템 엔지니어링 접근을 통해 초기에 불명확한 요구사항을 명확하게 정의하고 규격화하는데 노력하고 있고, 시스템 엔지니어링은 기존의 문서 중심(Document-Centric)에서 모델 기반 접근법인 MBSE(Model-based Systems Engineering)로 발전돼 엔지니어링 데이터의 정확성(correctness)과 일관성(consistency)이 보장된 모델 기반 시스템 규격서(System Specification) 정의도 가능케 됐음을 이야기했다. 
이번 글에서는 RIL(Requirement-in-the-Loop) 검증을 통해 기존의 MBSE를 어떻게 확장 시킬 수 있는지 알아본다. MBSE를 통해 얻게 되는 시스템 아키텍처 모델의 요소들을 살펴보고 체계적인 요구사항 검증을 위한 환경 구성으로 옵저버(Observer)를 통한 요구사항 모니터링에 대해 설명한다. 시스템의 기능 모델과 요구사항 모델의 시뮬레이션을 통해 다양한 오류를 검출하고 수정하는 방법들을 제안한다. 제안된 방법의 실행 가능성을 검토하기 위해 초기에 올바른 요구사항 정의가 반드시 필요한 자동차, 항공기, 철도 시스템과 같은 안전 필수 시스템(Safety-Critical System)의 예시를 통해 적용 결과를 살펴본다.


1. Requirement-In-the-Loop(RIL) 검증을 통한 MBSE(Model-based Systems Engineering) 확장 
RIL(Requirement-in-the-Loop) 검증은 MBSE(Model-based Systems Engineering)에서 V&V(Verification and Validation)를 위해 확장된 개념이다. RIL 검증은 실행가능한(executable) 요구사항 모델을 정의하고 MBSE의 결과물인 시스템 아키텍처 모델과 통합돼 시뮬레이션 기반 검증을 반복적으로 수행하면서 요구사항의 오류를 찾아내고 수정한다. RIL 검증은 요구사항의 불명확한 부분을 사전에 검증하는 데 목적을 두고 있기 때문에 시스템의 기능적 오류로 인해 발생하는 여러 문제들을 사전에 방지하고자 정의된 요구사항과 함께 동작하는 시스템의 거동 모델(Behavioral Model)을 기준으로 수행하게 된다. 이는 잘못된 기능 요구사항이 설계, 구현, 시험평가까지 이르게 됐을 때까지 그대로 방치되고 문제들을 찾아내지 못했을 때 시스템에 미치는 영향에 따라 수정에 많은 비용과 노력을 들여야 하는 점을 예방하기 위한 것이기도 하다. 정의된 기능 요구사항이 함께 주어진 시스템 아키텍처의 거동 모델 위에서 실행하다 보면 원하는 결과가 나오지 않거나 누락(missing) 또는 상충(conflict)되는 요구사항들을 검출하고 오류를 수정하면서 반복적인 시뮬레이션을 통해 요구사항의 완전성(completeness)를 보장할 수 있게 된다.

일반적으로 요구사항 형식은 크게 informal, semi-formal, formal representation 등 세 가지로 구분할 수 있다. Informal representation은 형식에 구애받지 않고 자유롭게 표현하는 것을 의미하는 데, 우리가 사용하는 자연어가 여기에 해당할 수 있다. 누구나 쉽게 사용가능 하지만 모호한 요구사항을 정확하게 정리하기는 어렵다. Semi-formal representation은 UML, SysML과 같이 기호(Symbol) 등을 활용해 일부는 formal representation처럼 명확하게 정의할 수 있으나 중의적인 해석도 발생할 수 있는 요인이 남아 있다. Formal representation은 요구사항을 수학적 논리에 의해 명확하게 표현 가능한 방법으로 가장 명확하고 정확하게 정의할 수 있지만 사용하기 위해서는 많은 지식과 훈련이 필요하다. 
RIL 검증을 위해 요구사항을 실행가능한(executable) 모델 형태로 만들기 위해서는 Formal representation로 정의해야 한다. 실행가능한(executable) 요구사항 모델을 통해 기능 요구사항을 정의하고 시스템 아키텍처의 기능 모델 위에 함께 시뮬레이션을 반복적으로 수행하다 보면 시스템을 구현하거나 운영할 때 발생 가능한 문제들을 사전에 발견하고 해결 방안을 반영해 요구사항을 더욱 완전하게 정의할 수 있다. 시스템 아키텍처의 기능 모델 위에서 시뮬레이션을 통해 얻게 되는 결과들은 기본적으로 세 가지 범주 내에서 분석된다.

- 잘못된 요구사항: 시뮬레이션은 정상적으로 수행되었지만, 원하는 결과가 나오지 않는 경우 
- 누락된(missing) 요구사항: 일부 범위에서 정의되지 않은 값이 나오는 경우
- 충돌하는(conflict) 요구사항: 요구사항들이 서로 모순되는 부분이 있어서 동시에 만족시키지 못하는 경우

또, 보다 체계적인 검증을 위해 필요에 따라 옵저버(Observer) 모델을 정의해 테스트 중인 시스템에서 요구사항의 위반을 지속적으로 감지해 개선할 수 있도록 돕는다. 옵저버(Observer)를 통해 확인하는 부분은 주로 입출력 값, 기대치 대비 실제 동작의 차이 분석, 주어진 요구사항에 대한 위반사례 등인데, 이렇게 검출된 내용을 기초로 좀 더 명확한 요구사항을 정의하고 관리할 수 있도록 도와준다. 
이어지는 내용에서는 안전 필수 시스템(Safety-Critical System)의 하나인 항공기 시스템의 잘못된 기능 요구사항으로 인한 사고 사례를 살펴보고 MBSE와 RIL 검증을 통해 요구사항 정의 및 검증을 통한 안전성 확보를 살펴본다.


2. Safety-Critical System을 위한 모델 기반 요구사항 검증 
에어버스 공식 안전 매거진 ‘Safety First’는 Airbus A320 항공기의 활주로 이탈사고 두 건을 보고한 바 있다. 이 사고들의 주요 원인은 항공기 랜딩기어(Landing Gear)의 잘못된 다운 록(Down Lock) 상태 표시였다. 당시 Airbus A320 항공기의 랜딩기어는 단일 잠금 센서를 사용하고 있었으며, 이로 인해 조종사에게 잘못된 경고를 제공했다. 이를 개선하기 위해 시스템 아키텍처에 이중 잠금 센서를 적용하는 개선이 필요했고, 특히 착륙장치 확장(Extension)과 격납(Retraction) 시 이중 잠금 센서를 적용하는 설계 변경이 요구됐다. 
이 사례는 요구사항 정의 및 검증 과정이 항공기와 같은 안전 필수 시스템(Safety-Critical System)의 안전성 확보에 얼마나 중요한지 보여준다. 이런 안전 문제를 개선하기 위한 아키텍처 변경은 기존의 복잡한 시스템에 새로운 요구사항을 추가하게 되므로 이 요구사항들이 모호하거나, 누락되거나, 기존 기능과 상충되지 않도록 철저한 검증이 필요하다.
항공기 랜딩기어 시스템은 항공기가 이륙, 비행, 착륙하는 동안 안전하게 작동해야 하는 중요한 시스템이다. 핵심 요구사항으로는 다음과 같은 항목이 포함된다:

- 핸들 명령이 down일 때, 모든 랜딩기어는 15초 이내에 확장되고 모든 도어는 닫혀야 한다.
- 랜딩기어가 확장 중일 때 도어는 열려 있어야 한다.
- 랜딩기어가 완전히 확장된 후에만 도어가 닫혀야 한다.
- 두 개의 잠금 센서 모두 잠금 상태를 표시해야만 랜딩기어가 완전히 확장된 것으로 간주한다.
- 두 센서 간에 상태 불일치가 발생할 경우 조종사에게 경고가 제공돼야 한다.

이런 요구사항들은 항공기 안전에 직결되는 내용이므로 설계 구현 이전에 요구사항 레벨에서 철저한 사전 검증이 필요하다. 특히 중요한 안전 요구사항은 옵저버(Observer)로 변환돼, CATIA Magic에서 작성된 시스템 아키텍처 모델과 Simulink에서 개발된 제어 모델이 이런 핵심 요구사항을 준수하는지 객관적으로 평가하는 기준으로 활용된다. 이처럼 STIMULUS는 단순한 요구사항 정의 도구를 넘어, 시스템 개발 전 과정에 걸쳐 요구사항 기반의 검증이 일관되게 수행될 수 있도록 지원하는 통합적인 검증 환경을 제공한다.


2.1 요구사항 기반 랜딩기어 시스템 아키텍처 정의 
시스템 아키텍처는 해당 시스템에 대한 이해관계자 요구사항, 시스템 요구사항을 기반으로 설계된다. 이를 위해 사전에 관리되고 있는 요구사항을 시스템 아키텍처 모델링 도구인 CATIA Magic으로 내보내고, 해당 요구사항들은 요구사항 모델이 돼 CATIA Magic에서 본격적인 시스템 아키텍처 정의를 하는 데 사용된다.
랜딩기어 시스템의 아키텍처는 Cyber MagicGrid 방법론을 통해 정의됐다. 이 방법론은 시스템의 문제(Problem Domain)를 분석하고 그에 대한 솔루션(Solution Domain)을 설계하는 접근법으로, 총 5개의 핵심 기둥인 요구사항(Requirements), 구조(Structure), 동작(Behavior), 매개변수(Parameters), 안전 및 신뢰성(Safety & Reliability)으로 구성된다. 이 구조화된 프레임워크를 통해 사용자 요구사항에서부터 하위 시스템 수준의 아키텍처까지 체계적으로 정의할 수 있다.
MagicGrid의 5개 기둥을 기반으로 시스템을 하나씩 분석해 나갈 때, 각 기둥은 다시 도메인(Domain) 측면에서 문제 정의(Problem Definition)와 솔루션(Solution)으로 구분돼 시스템의 모든 측면을 포괄적으로 다룬다. 사전에 import한 이해관계자 요구사항(Stakeholder Needs)에서 시작해, 대상 시스템과 밀접한 관계를 맺고 있는 외부 시스템들의 맥락을 구조화하는 시스템 컨텍스트(System Context), 유스케이스(Use Cases), 개념적 서브시스템(Conceptual Subsystems), 기능 분석(Functional Analysis)을 거쳐 점차 상세화된다. 이 과정에서 시스템 요구사항(System Requirements)이 정의되고, 이는 다시 서브시스템 요구사항(Subsystem Requirements)과 컴포넌트 요구사항(Component Requirements)으로 세분화된다.
랜딩기어 시스템의 경우, 이 방법론을 적용해 시스템 구조(System Structure), 시스템 동작(System Behavior), 시스템 매개변수(System Parameters), 시스템 안전성 및 신뢰성(System S&R)을 정의했다. 이후 각 서브시스템(예: 메인 랜딩기어, 노즈 랜딩기어, 도어 메커니즘, 잠금 장치, 센서, 제어 유닛)에 대한 구조, 동작, 매개변수, 안전성 및 신뢰성을 상세히 모델링했다.




그림 1 | 랜딩기어 시스템 아키텍처 



이렇게 CATIA Magic을 통해 정의된 시스템 아키텍처는 SysML 기반의 다양한 다이어그램(BDD, IBD, 상태 다이어그램, 활동 다이어그램 등)으로 표현되며, 이후 STIMULUS로 내보내져 요구사항 검증에 활용된다. 이 과정에서 시스템 아키텍처가 정의된 요구사항을 충족하는지, 그리고 서브시스템 간 인터페이스가 올바르게 정의됐는지 검증할 수 있다.


2.2 시스템 아키텍처 기반 시스템 기능 요구사항 검증     
위와 같은 과정을 통해 CATIA Magic에서 시스템 아키텍처를 정의한 후, 이를 STIMULUS로 내보내 아키텍처 내 다이어그램을 활용한 상세 기능 요구사항 검증을 수행한다. CATIA Magic에서 정의된 다이어그램과 포트 정보들은 STIMULUS로 완전히 통합돼 단일 정보 원천(Single Source of Truth) 원칙에 따라 데이터의 연속성과 정합성을 확보한다. 이런 접근법은 정보 이전 과정에서 발생할 수 있는 오류를 최소화하고, 시스템 설계 과정 전반에 걸쳐 일관된 요구사항 관리를 가능하게 한다.
STIMULUS 환경에서는 CATIA Magic에서 가져온 시스템 아키텍처를 기반으로 형식화된 요구사항(Formalized Requirements)을 시스템에 할당하고 시뮬레이션을 통해 검증할 수 있다. 핸들 명령(HandleCommand), 액추에이터(Actuator), 도어(Doors), 기어(Gears) 등 랜딩기어 시스템의 주요 구성요소와 그 관계를 보여주는 시스템 아키텍처 다이어그램은 STIMULUS의 Block Diagram으로 들어와 시뮬레이션을 위한 시나리오 역할을 한다. 해당 다이어그램 내 각 구성요소에 할당된 형식화된 기능 요구사항이 계층적으로 정리돼 있으며, 이들은 정형 언어로 명확하게 작성된다.





그림 2 | 시스템 아키텍처 모델 기반 시나리오와 정형화된 요구사항



작성된 요구사항은 시뮬레이션을 통해 해당 요구사항 간 누락(missing), 모호성(ambiguity), 또는 충돌(conflict)이 없는지 체계적으로 검증된다. 특히 이미 검증된 요구사항을 옵저버(Observer)로 설정해, 새로운 기능 요구사항들이 이런 옵저버를 위반하지 않는지, 요구조건 간 상충 가능성은 없는지 난수(random value) 생성을 통해 정밀하게 분석한다.

그림 3의 시뮬레이션에서는 단계(Step)를 1,000으로 설정함으로써 각 시뮬레이션 실행 시 요구사항 적용 범위에 대해 1,000개의 데이터 포인트를 생성했다. 이 과정을 통해 방대한 요구사항 간 불일치, 모순되는 제약조건, 또는 정의되지 않은 상태 영역(undefined state space)을 효과적으로 식별할 수 있다.




그림 3 | STIMULUS 시뮬레이션 수행



또한 시스템의 제어 흐름을 State Machine Diagram으로 나타내 시스템의 동적 시나리오를 보다 직관적으로 모델링할 수도 있다. 이런 State Machine Diagram 기반 시뮬레이션은 기존의 요구사항 기반 시뮬레이션과 동일한 동작을 보이는지 검증함으로써 모델의 일관성을 확보할 수 있다. 특히 입력(Inputs), 출력(Outputs), 그리고 옵저버(Observer) 정보를 각각 별도의 차트로 시각화해 시스템 동작의 다양한 측면을 동시에 모니터링함으로써 복잡한 시스템의 동작 특성과 제약조건 만족 여부를 효율적으로 분석할 수 있다.
이런 방식으로 STIMULUS는 요구사항의 형식적 검증(formal verification)과 시뮬레이션 기반 검증(simulation-based validation)을 통합해 설계 초기 단계에서 잠재적인 문제점을 식별하고 해결해 개발 후기 단계에서 발생할 수 있는 비용 증가와 일정 지연을 효과적으로 방지할 수 있다.


2.3 요구사항 모델과 제어 모델과의 통합 검증(STIMULUS + Simulink) 
항공기 랜딩기어와 같은 안전 필수 시스템에서는 정밀한 제어 로직 구현이 필수적이다. 이런 제어 로직 개발을 위해 MathWorks의 Simulink가 산업계 표준 도구로 널리 사용되고 있다. Simulink는 블록 다이어그램 기반 시각적 모델링 환경을 제공해 복잡한 제어 알고리즘을 직관적으로 설계, 시뮬레이션 및 분석할 수 있게 한다. 그러나 Simulink는 주로 제어 로직의 구현과 동작 분석에 초점을 맞추고 있어 초기 요구사항이 정확히 구현됐는지 체계적으로 검증하는 데는 한계가 있다. 이런 한계를 극복하기 위해 요구사항 중심의 검증 도구인 STIMULUS와 제어 모델링 도구인 Simulink 간 연계가 필수적이다. 이 두 도구의 통합을 통해 요구사항부터 구현까지의 일관성을 확보하고, 정형화된 요구사항을 기준으로 제어 모델을 객관적으로 검증할 수 있다.
STIMULUS와 Simulink 간 연계는 FMU(Functional Mockup Unit) 기반으로 이뤄진다. Simulink에서 개발된 제어 모델은 FMU로 내보내져 STIMULUS 환경에서 기 정의된 요구사항 및 옵저버와 통합 시뮬레이션된다. 이 과정에서 STIMULUS는 Simulink 제어 모델이 정의된 요구사항을 준수하는지 객관적으로 검증하는 역할을 수행한다.





그림 4 | 시스템 내부에 검증 필요한 Simulink FMU와 옵저버(Observer) 통합


그림 5 | STIMULUS 옵저버 위반 확인 후 Simulink 모델 수정



그림 4에서 내부 메인 시스템인 Digital Part에 “DigitalPart_With_Observer” 시스템을 통합함으로써, Simulink에서 개발된 LandingGearController_V1.FMU와 STIMULUS에서 정의된 상태 기계(State Machine) 기반 옵저버 간 동작 검증이 가능하다. 이 프로세스에서는 다음 세 가지 주요 요소가 병행 모니터링된다:

- FMU 입력 신호: 첫 번째 차트에 표시되어 제어 모델에 전달되는 입력 조건을 모니터링
- FMU 출력 신호: 두 번째 차트에 표시되어 제어 모델의 반응과 동작을 모니터링
- State machine 기반 옵저버: 세 번째 차트에 표시되어 제어 모델의 동작이 요구사항을 준수하는지 실시간 검증

그림 5와 같이 시뮬레이션에서 옵저버 위반이 감지되면, 이는 Simulink 모델의 구현이 STIMULUS에서 정의된 요구사항과 불일치함을 의미한다. 이런 불일치는 시뮬레이션 결과 화면에 명확히 표시되며, 개발자는 이를 기반으로 Simulink 모델을 수정할 수 있다.
수정된 Simulink 모델을 STIMULUS 환경에 다시 통합해 시뮬레이션을 실행하면, 옵저버 위반이 해소돼 제어 모델이 요구사항을 완전히 준수함을 확인할 수 있다. 이는 STIMULUS와 Simulink 간 양방향 피드백 루프를 형성해 요구사항과 구현 간 일관성을 지속적으로 보장한다.
이처럼 STIMULUS와 Simulink의 통합 검증 프로세스는 요구사항 정의 단계부터 구현 검증 단계까지 추적성(traceability)을 확보해 시스템 개발의 모든 단계에서 요구사항 충족을 보장한다. 특히 안전 필수 시스템인 랜딩기어와 같은 경우, 이런 체계적 검증 방식은 잠재적 위험 요소를 초기에 식별하고 해소하는 데 핵심적인 역할을 한다.


3. 결론 
이 글은 안전 필수 시스템(Safety-Critical System)의 대표적 사례인 항공기 랜딩기어 시스템의 오류 사고를 분석해 MBSE(Model-based System Engineering) 및 RIL(Requirements-in-the-Loop) 통합 검증을 통해 정확한 요구사항을 정의하는 과정을 CATIA Magic과 STIMULUS, 그리고 Simulink와의 연계를 통해 살펴봤다. 이런 접근법을 통해 몇 가지 주요 가치를 확인할 수 있다. 먼저 시스템 아키텍처 모델을 통해 식별된 구조적 정확성 확보를 위해 CATIA Magic의 아키텍처 모델과 STIMULUS를 연계해 요구사항과 아키텍처 모델 간 일관성(Consistency)을 검증해 시스템의 구조적 요소들이 안전 요구사항들을 정확하게 반영할 수 있도록 보장했다. 
또한 시스템 아키텍처 모델에서 정의된 기능 모델과 요구사항을 STIMULUS를 통해 정형언어(Formal Language) 형태로 정의해 시뮬레이션을 함께 수행하면서 시스템의 핵심 동작 흐름 (ex. 도어 개방, 기어 확장, 잠금 감지, 도어 폐쇄 등)들이 모든 상황에서 요구사항을 정확하게 충족시키는지 검증할 수 있었다. 특히, State Machine 모델을 활용할 때는 시간적 제약 조건과 상태 전의 과정에서의 안전 요구사항 준수 여부를 더욱 효과적으로 검증할 수 있게 됐다. 

마지막으로 기존의 정의된 제어모델과의 FMU(Functional Mockup Unit)을 활용한 상호 연계를 통해 제어모델이 요구사항을 준수하는지 또는 새로운 제어 기능 요구사항이 추가됐을 때 문제가 되는 요소들은 없는지를 객관적으로 검증할 수 있었다. 이 부분은 제어시스템에 탑재된 임베디드 SW의 기능을 개선하거나 새로운 기능을 고려할 때 불확실성을 줄이는데 크게 기여할 수 있다. 기존에는 모델링 도구를 통해 알고리즘을 모델링하거나 SW 프로토타입으로 빠르게 구현한 후에 시뮬레이션을 통한 검증을 수행했다면, RIL 검증에서는 정의된 요구사항과 제어모델이 직접 시뮬레이션을 수행할 수 있어 초기 요구사항을 정의하는 단계부터 안전성을 보장한 제어 기능을 빠르고 정확하게 정의할 수 있는 강점이 있다. 특히 이 글에서 RIL 검증을 위해 활용된 STIMULUS는 제어 기능 요구사항을 자체적인 시뮬레이션을 통해 검증할 수 있다. 또, 제어 알고리즘 설계에 많이 활용되는 Simulink 모델 간 통합 검증 환경이 기본적으로 제공돼 안전 및 보안을 고려한 기능 요구사항들을 연관된 Simulink 제어 모델과 함께 검증하면서 발견된 옵저버(Observer) 위반 사항들을 반복적으로 개선할 수 있다. 이를 통해 안전 필수 시스템(Safety-Critical Systems)의 기능 및 안전 요구사항을 초기에 명확하게 정의할 수 있게 돼 기능 복잡도를 관리할 수 있으며 요구사항의 완전성(Completeness)을 확보할 수 있게 됐다.

이처럼 RIL 기반 검증 접근법은 특히 두 개의 독립적인 잠금 센서를 사용하는 개선된 랜딩기어 시스템에서 센서 오류 상황이나 예외적인 조건에서도 시스템의 안전한 동작을 보장하는 데 핵심적인 역할을 했다. 이 과정에서 정의된 State Machine 및 옵저버는 향후 다른 항공기 시스템 개발에도 재사용가능한 검증 자산으로 활용될 수 있다. 이렇게 RIL 검증을 MBSE(Model-based Systems Engineering)와 통합한다면 다양한 고장모드 또는 예외 상황을 포함하는 포괄적인 시나리오 기반 검증으로 확장할 수 있으며, 시스템을 구성하는 여러 하위 시스템과의 상호운용성(interoperability)을 고려한 통합 시스템 수준의 검증으로 전체 시스템의 안전성을 향상시킬 수 있다. 
특히, MBSE에 통합된 RIL 검증 방법은 잘못된 요구사항이 큰 피해를 가져올 수 있는 안전 필수 시스템(Safety-Critical Systems) 개발에서 요구사항 정의부터 구현까지 일관된 검증 체계를 마련함으로써 시스템의 안전성(Safety)을 크게 향상시키는 효과적인 접근법이 될 수 있음을 확인했다. 이는 안전성뿐만 아니라 신뢰성(Reliability), 가용성(Availability), 정비성(Maintainability), 사이버보안(Cybersecurity) 등이 요구되는 현대의 다양한 복합 시스템 영역(자동차, 항공기, 철도, 의료기기 등)에서 적용되고 사용할 수 있는 가능성을 열었다. 

향후 많은 사용자가 MBSE(Model-based Systems Engineering)와 모델 기반 요구사항 검증 방법인 RIL(Requirement-in-the-Loop)을 다양한 시스템에 적용함으로써 더욱 향상된 RIL 검증 방법이 완성되길 기대한다.