엔지니어링 프로세스의 초기 단계라 할 수 있는 요구사항 분석/정의에서 추상화 레벨이 높아짐에 따라 요구사항 정형화 작업이 어렵고 많은 시간을 투자해야 할 수 있다. 다쏘시스템은 시스템의 요구사항이 정의되고 명세화되는 시점부터 모호하지 않고 명확한 요구사항 정의를 위해 RIL(Requirements-in-the-Loop) 방식 접근을 기능 요구사항 검증 도구로 활용한다. 이 글은 요구사항 모델링 및 시뮬레이션 접근법인 RIL을 살펴보고, 요구사항 검증 도구를 통해 이를 어떻게 가시화시키고, 모호하거나 불명확한, 누락되거나 상충되는 것을 시뮬레이션을 통해 검출하고 수정할 수 있는지 살펴본다.

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

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







1. MBSE(Model-based System Engineering) 접근을 통한 요구사항 검증    
현대의 시스템은 기술 진화에 따라 인공지능(AI), 자동화(Automated), 소프트웨어 정의(Software-defined)와 같은 다양한 기술 요소를 하나로 융합해 복합적이고 유기적인 서비스 제공을 목표로 발전하고 있다. 특히 자동차, 항공 등 높은 복잡성을 가진 시스템들은 기술 융합에 따른 다양성(Diversity) 증가로 시스템 및 소프트웨어의 복잡성(Complexity)과 불확실성(Uncertainty)이 함께 증가하고 있다. 이에 따라 안전(Safety)과 보안(Cybersecurity)에 대한 중요성이 크게 강조되고 있다. 

시스템 개발 과정에서 작은 요구사항의 오류조차도 치명적인 결과를 초래할 수 있기 때문에 산업계는 시스템 엔지니어링 접근을 통해 개발 초기 단계부터 시스템의 위험(Risk)을 최소화하고 제거할 수 있도록 명확하고 철저하게 요구사항을 정의하고 검증하는 데 많은 노력을 기울이고 있다. 최근에는 디지털 데이터에 기반한 모델 기반 시스템 엔지니어링(Model-based Systems Engineering, MBSE)을 통해 엔지니어링 데이터의 정확성(correctness)과 일관성(consistency)이 보장된 모델 기반 시스템 규격서(System Specification) 정의도 가능하게 됐다. 

MBSE는 시스템의 기능, 구조, 특성을 가시화하고 실행가능한 디지털 모델로 표현한다. 이런 시스템 모델은 MBD(Model-based Design)와 Model-based V&V(검증 및 확인) 활동에 활용된다. 특히 V&V 영역에서는 MIL(Model-in-the-Loop), SIL(Software-in-the-Loop), HIL(Hardware-in-the-Loop) 등의 방법으로 HW/SW 기능을 검증해 문제를 해결하고 있다. 그러나 이는 정의된 요구사항을 기준으로 적합성을 평가하기 때문에 요구사항 자체의 불명확성이나 오류를 사전에 식별하는 데 한계가 있다. 또 MBSE 사용자들은 기능 중심의 다양한 테스트 시나리오 생성과 반복적인 가상 검증을 통해 오류 없는 시스템 구현에 집중하지만, 이런 검증은 소프트웨어나 하드웨어와 같은 특정 부분에 국한돼 있어 요구사항의 정확성 자체를 보장하지는 못한다.

그렇다면 개발 과정 초기 단계인 요구사항 작성 및 검증 단계는 어떨까? 시스템 개발 과정에서 MBSE를 적용하더라도 초기 요구사항은 자연언어로 명세되는데, 이는 전문 지식 없이도 이해하기 쉽고 엔지니어링 전체 라이프사이클에서 일관되게 사용할 수 있다는 장점이 있다. 그러나 자연언어의 본질적인 모호성은 다양한 해석의 여지를 남겨 안전이나 보안 관련 요구사항일 경우 시스템에 치명적인 영향을 미칠 수 있다. 복잡한 현대 시스템에서는 수많은 요구사항 간 상충 관계를 모두 확인하기 어렵고, 요구사항의 오류가 개발 후기 단계에서 발견될수록 수정 비용과 시간이 기하급수적으로 증가한다. 따라서 텍스트 중심의 요구사항도 MBSE처럼 실행가능한 형태로 모델링해 검증할 수 있다면, 불명확하거나 위험한 요구사항을 초기에 발견하고 수정함으로써 시스템 개발의 효율성과 안전성을 크게 향상시킬 수 있다.

다쏘시스템(Dassault Systemes)에서는 시스템의 요구사항이 정의되고 명세화(Specified)되는 시점부터 모호하지 않고 명확한 요구사항 정의를 위해 RIL(Requirements-in-the-Loop) 방식의 접근법을 기능 요구사항의 검증 도구로 활용하고 있다. RIL 기반 요구사항 검증 방법은 MBSE의 확장된 형태로 시스템의 기능(제어) 모델의 요구사항을 정형언어(Formal Language) 형태로 정의해 요구사항 정의 단계부터 반복적인 실행/검증으로 오류가 없는(error-free) 요구사항 정의를 목적으로 한다. 엔지니어링 프로세스의 앞부분이라 할 수 있는 요구사항 분석/정의 단계에서 추상화 레벨이 높아짐에 따라 정의되는 개념과 요구사항이 모호할 수밖에 없는 만큼 요구사항을 정형화(formalize)시키는 작업은 생각보다 어렵고, 많은 시간을 투자해야 할 수 있다. 이 부분을 해결하기 위해서는 요구사항을 실행가능한 정형언어 형태로 정의할 수 있는 템플릿을 제공하고 다수의 테스트 케이스 생성, 실행에 도움을 줄 수 있는 자동화 검증 도구가 필요하다. 

STIMULUS는 요구사항을 정형화, 디버그, 테스트할 수 있도록 고유한 모델링 및 시뮬레이션 기능을 제공해 요구사항이 올바르고(correct), 일관되며(consistency) 완전한지(complete) 확인할 수 있도록 돕는 요구사항 검증 도구다. STIMULUS의 RIL 접근법은 요구사항을 재정의하고 코드를 재작성하고 디버깅하는데 걸리는 시간을 절약하고, 특히 다수의 서플라이어들이 참여하는 대형 복합 시스템 개발의 품질 결과를 달성하는 데 필요한 개발 반복 횟수를 줄인다.  

이 글은 요구사항의 모델링 및 시뮬레이션 접근법인 RIL 방법을 살펴보고, 요구사항 검증 도구를 통해 요구사항을 어떻게 가시화(visualize)시키고 모호하거나, 불명확한, 누락, 상충되는 요구사항을 시뮬레이션을 통해 검출하고 수정할 수 있는지에 대해 살펴본다.


2. Requirement-In-the-Loop, 모델 기반 요구사항 검증 방법 
시스템 개발에서 요구사항의 정확한 명세와 검증은 성공적인 프로젝트 수행을 위한 핵심 요소다. 이 글에서는 먼저 STIMULUS의 핵심기능인 Requirement-In-the-Loop(RIL) 시뮬레이션에 대해 알아본다.

(1) 요구사항 모델링    
시스템의 기능을 검증하기 위해서는 두 가지 주요 요구사항 관점을 이해해야 한다. 첫째는 ‘What’ 관점으로, 시스템이 수행해야 하는 구체적인 동작이나 특정 기능을 명시하는 요구사항을 의미한다. 예를 들어 랜딩기어(Landing Gear) 시스템에서 “핸들 명령이 down일 때, 모든 랜딩기어는 15초 이내에 확장되고 모든 도어는 닫혀야 한다”와 같은 요구사항이 이에 해당된다.

둘째는 ‘How well’ 관점으로, 시스템이 기능 요구사항을 얼마나 잘 충족하는지, 즉 안전성과 성능, 사용성 등 시스템의 품질 속성을 정의하는 요구사항을 의미한다. 랜딩기어 시스템이 15초 이내에 모든 기어를 확장하고 모든 도어를 닫는데 성공하는지 여부가 예시가 될 수 있다.

RIL 시뮬레이션에서는 두 가지 중에서도 ‘What’ 관점의 기능 요구사항을 주로 사용한다. STIMULUS는 이런 기능 요구사항을 형식화하기 위해 일련의 문장 템플릿을 제공하며, 이를 레고 블록처럼 조합해 정형화된 요구사항을 만들 수 있다. 랜딩기어 시스템에서 ‘핸들 명령이 down일 때, 모든 랜딩기어는 15초 이내에 확장되고 모든 도어는 닫혀야 한다.’라는 요구사항을 STIMULUS에서 형식화하기 위해 ‘When’, ‘is’, ‘shall be’와 같은 기본 템플릿을 조합하게 된다. When, is, shall be와 같은 템플릿들은 단순한 문장 구조를 넘어 정확한 의미를 내포하고 있다. 예를 들어 When 템플릿은 조건이 참일 때 특정 동작을 활성화하는 상태 기계(State machine)로 정의돼 있으며, ‘is’ 템플릿은 수학적 동등성을 의미한다. 이렇게 명확한 의미가 정의돼 있기 때문에 특정 기능 요구사항에 대해 모두 동일한 방식으로 STIMULUS 요구사항 모델을 정의하고, 동등한 의미로 해석할 수 있다. 





그림 1 | 랜딩기어 시스템 핸들 명령 요구사항 모델링



시스템에서 사용되는 용어들은 용어집(Glossary)을 통해 관리된다. 용어집을 통해 시스템 변수와 각 변수의 데이터 타입, 변수의 물리적 단위와 범위 등을 정의할 수 있다. 또 전체 시스템이 어떤 구조로 정의돼 있는지에 대한 정보를 블록 다이어그램(Block Diagram)을 통해 표현할 수 있어 각 요구사항이 시스템의 어떤 하위 블록에 적용되는지 명확하게 표현할 수 있다.

이렇게 형식화돼 모델링된 요구사항은 이후 시뮬레이션을 통해 검증할 수 있다. 마치 프로그래밍 언어로 코드를 작성하듯이 요구사항을 정확하고 모호하지 않게 작성할 수 있게 된다.

(2) 요구사항 시뮬레이션  
이전 단계에서 요구사항을 형식화 및 공식화했다면, STIMULUS 실행 엔진을 사용해 시뮬레이션이 가능하다. 
먼저 형식화된 요구사항은 컴파일러를 통해 제약조건으로 변환된다. 그리고 STIMULUS 내 시뮬레이터는 시간의 흐름에 따라 이런 제약조건들을 처리하고, 각 시점에서 활성화된 제약조건들은 솔버로 전달된다. 솔버는 부울 값, 수치 값, 시간 관련 값들을 모두 고려해 제약조건을 만족하는 가능한 동작들을 결정하고, 이를 시스템의 출력으로 사용한다. 이 과정이 반복되면서 시스템의 동작을 보여주는 실행 트레이스가 만들어진다. 제약 조건들 사이에 충돌이 발생하면 (동시에 문을 열고 닫으라는 명령 등), 시뮬레이션이 중단되고 문제가 되는 요구사항들을 자동으로 알려준다.

이런 시뮬레이션을 통해 요구사항의 정확성, 완전성, 일관성을 검증할 수 있으며, 나중에 실제 시스템을 구현할 때 발생할 수 있는 문제들을 미리 발견하고 해결할 수 있다.

(3) 시뮬레이션 결과 분석 및 검증 
요구사항 시뮬레이션을 실행한 후에는 결과를 분석하고 검증하는 과정이 수행된다. 먼저 기본적인 결과 분석 방식은 세 가지로 구분할 수 있다.

잘못된 요구사항 발견: 시뮬레이션은 정상적으로 실행되지만, 결과가 원하는 시스템의 동작과 다른 경우를 말한다. 이때는 Stimulus의 고급 탐색 기능을 사용해 특정 시점에 어떤 변수가 어떤 값을 갖게 됐는지, 그리고 그것이 어떤 요구사항들과 관련 있는지 찾아볼 수 있다.
누락된 요구사항 발견: 시뮬레이션 결과에서 일부 구간이 점선으로 표시되기도 한다. 이는 해당 기간 어떤 요구사항도 그 값을 정의하지 않았다는 의미다. 이는 구현의 자유도를 위해 의도적으로 비워둔 것이거나, 정말 필요한 주요 요구사항을 빠뜨린 것일 수 있다.
충돌하는 요구사항 발견: 이 경우는 시뮬레이션이 특정 시점에서 멈추는데, 이는 요구사항들이 서로 모순돼 동시에 만족시킬 수 없기 때문이다. 이때는 솔버가 자동으로 특정 요구사항들이 충돌하는지 최소한의 집합을 찾아 알려준다.

또 STIMULUS는 보다 체계적인 검증을 위해 옵저버(Observer)를 활용한다. 옵저버는 테스트 중인 시스템을 실시간으로 모니터링하고 요구사항 위반을 감시하는 검증된 요구사항이다. 절대적으로 위반되면 안 될 중요 요구사항을 사용자가 옵저버로 설정해 활용한다. 옵저버의 주요 기능은 다음과 같다:

시스템의 입출력 신호 모니터링: 옵저버는 시스템의 모든 입출력 신호를 지속적으로 관찰해 동작을 파악한다.
실시간 요구사항 준수 검증: 미리 정의된 예상 동작과 실제 시스템의 동작을 실시간으로 비교해 차이점을 분석한다.
요구사항 위반 감지: 요구사항 위반이 발생할 경우 즉시 이를 감지하고 기록한다.

시뮬레이션 결과 다음 차트에서 빨간색으로 표시되는 구간은 옵저버가 요구사항 위반을 감지한 것을 의미하며, 이를 통해 시스템 설계자는 문제점을 즉각적으로 파악하고 수정할 수 있다.



그림 2 | 옵저버를 활용한 요구사항 검증



이런 분석과 검증 과정을 돕기 위해 STIMULUS는 기본적인 디버깅 도구를 제공한다. 이를 통해 현재 어떤 요구사항들이 활성화돼 있는지 확인하거나, 변수들의 값 변화를 추적할 수 있다.



3. RIL 활용 예시: 제어모델 활용한 기능 요구사항 검증   
(1) 항공기 랜딩기어 전체 워크플로             
에어버스 공식 안전 매거진인 ‘Safety First’에서는 Airbus A320 항공기의 활주로 이탈 사고 두 건을 보고한 바 있다. 이 사고들의 주요 원인은 항공기의 랜딩기어의 잘못된 다운록(Down Lock) 상태 표시로, 당시 사용됐던 단일 잠금 센서의 오류로 조종사에게 잘못된 경고가 제공된 것이었다. 이 사례들은 요구사항 정의 및 검증 과정이 항공기와 같은 안전 중시 시스템(Safety-Critical System)의 안전성 확보에 얼마나 중요한지를 보여준다.

사고의 근본적인 설계 문제는 랜딩기어의 수납 및 하강 과정에서의 단일 잠금 센서 구조였으며, 이를 개선하기 위해 시스템 아키텍처에 이중 잠금 센서를 적용하는 설계 변경이 필요했다. 그러나 이런 새로운 기능 요구사항은 기존의 복잡한 시스템 아키텍처에 추가되거나 수정될 때 모호하거나, 누락되거나, 기존 기능과 상충될 가능성이 높아 신중한 검증이 요구된다.
이런 상황에서 효과적으로 활용될 수 있는 접근 방법이 바로 RIL(Requirements-in-the-Loop)이며, STIMULUS를 통해 이를 수행할 수 있다.
  
(2) STIMULUS - Simulink 동적 모델 완성도 검증  
STIMULUS는 상세 설계 단계 이전, 기능 요구사항을 시뮬레이션해 요구사항의 모호성, 오류, 누락 또는 충돌을 식별할 수 있도록 도와주는 도구이다. 이를 통해 안전성이 중요한 주요 시스템의 검증에 필수적인 고품질 요구사항 스펙을 정의할 수 있다.




그림 3 | STIMULUS ~ Simulink Co-simulation 중 옵저버 위반 요구사항 확인



STIMULUS는 검증된 기능 요구사항을 옵저버(Observer)로 활용해 시스템 설계 단계부터 요구사항의 정확성을 효과적으로 검증할 수 있게 지원한다. 시험 담당자는 STIMULUS에서 생성된 테스트 벡터를 활용해 Simulink에서 설계한 모델이 요구사항을 올바르게 준수하는지 자동으로 테스트할 수 있다. 이를 위해 먼저 Simulink에서 기능 요구사항에 따라 제어 시스템의 랜딩기어 수납 및 하강(retraction and deployment) 사이클과 그 과정에서 발생하는 센서 고장을 디스플레이하는 로직을 모델링한다. 이후, STIMULUS에서 작성한 옵저버와 테스트 시나리오를 FMU(Functional Mockup Unit) 형식으로 Simulink로 가져와 연동해 시뮬레이션을 수행한다.

Simulink 모델이 옵저버에서 정의된 요구사항을 위반하는 경우, STIMULUS 화면 하단의 시뮬레이션 패널에 Error Level과 Message 정보가 제공돼 위반된 요구사항과 해당 시스템의 위치를 즉시 파악할 수 있다. 확인된 내용을 바탕으로 Simulink 모델의 해당 부분을 수정하거나 재정의한 뒤, 변경된 모델을 다시 시뮬레이션해 옵저버 요구사항 준수 여부를 반복적으로 검토한다. 이런 반복적이고 체계적인 접근 방식을 통해 초기 설계 단계부터 요구사항 관련 오류, 모호성 및 충돌을 사전에 식별하고 해결해 최종 모델의 정확성과 신뢰성을 높일 수 있다.

(3) 결론
반복적인 RIL(Requirements-in-the-Loop) 기반 접근을 통해 요구사항을 철저히 검증하고 완전하고 명확한 요구사항을 구축할 수 있다. 그러나 초기에 올바른 요구사항을 정의하기 위해 요구사항 모델을 정형화하는 과정에 많은 시간과 노력이 요구된다. 다쏘시스템의 STIMULUS는 이런 어려움을 해소하기 위해 요구사항을 모델 형태로 손쉽게 정의할 수 있도록 정형언어(Formal Language) 기반 템플릿을 제공하고, 내장된 솔버를 활용한 반복적인 시뮬레이션으로 요구사항의 명확성 및 완성도를 높일 수 있게 한다.

또 STIMULUS는 FMI(Functional Mockup Interface) 기반의 모델 데이터 교환 기능을 제공해 요구사항을 FMU 형태로 변환하고 다양한 기능 모델 및 시뮬레이션 도구와 연계한 사전 검증이 가능하다. 이를 통해 새롭게 정의하거나 개선된 기능들이 요구사항을 위반하는지를 미리 식별할 수 있어 기능의 유용성을 일찍 확보할 수 있다. 결과적으로 시험평가 단계에서 필요한 테스트 시나리오를 조기에 정제해 개발 시간을 단축할 수 있다.