신뢰할 수 있는 자율주행을 위해 가장 중요한 척도인, 완전한 툴 체인을 위해서는 일반적인 로드데이터나 테스트데이터 같은 드라이버 데이터들이 버추얼 시뮬레이션 툴 체인과 결합해야만 가능하다. 버추얼 시뮬레이션 툴 체인은 테스트데이터, 로드데이터, ODD부터 Safety가 준비되고 시나리오가 유기적으로 연결되는 Closed-Loop 시뮬레이션 등을 통해 가장 현실감 있고 살아 움직이는 시뮬레이션을 가능하게 하기 때문이다.

글｜신동섭·최원석 차장, Ansys Korea




지난 4월, 정부는 자율주행 Level 4 달성을 위해 1조 원 이상을 투입할 예정이라고 밝힌 바 있다. 글로벌 자율주행차 시장은 2035년 1,300조 원대로 성장할 것으로 예상되고 있으며, 그 어떤 산업보다 손꼽히는 미래 먹거리로 각광 받고 있다. 그렇다면 Level 4란 구체적으로 무엇을 말하는 것일까?

통상 자율주행 Level 4는 운전자가 수동 운전을 할 수 없는 상황에서도 차량의 판단으로 안전하게 자율주행을 할 수 있는 단계를 가리킨다. Level 5는 운전자의 개입이 전혀 필요 없는 완전한 수준의 자율주행을 의미한다. Level 4부터는 운전자의 개입이 불필요한 고등 자율주행으로 제어 주체와 주행에 대한 책임 모두 시스템에 있다.

안전한 Level 4 이상을 달성하기 위해서는 물리적으로 커버할 수 없는 긴 거리에 대한 시뮬레이션이 필요하다. 이를 위해서는 버추얼 시뮬레이션이 필수적이며, 자율주행차 개발과 검증 모두가 완전한 툴 체인에 의해서 개발돼야 한다. ODD(운행 설계 영역)부터 ADAS(첨단 운전자 지원 시스템) 기능과 자율주행 기능을 검증하는 프로세스들을 툴 체인 내에서 진행하기 때문에, 툴 체인은 안전을 가장 중요한 요소로서 최우선으로 고려하며 디자인과 검증을 커버해야 한다.


Level 4-5 달성 위한 전략   

툴 체인에 있어 가장 우선적인 것은 시뮬레이터를 선택하는 일이다. Level 4 이상을 달성하기 위해서는 가장 정밀도가 높은 센서들과 환경들이 필요하다. 2D+ 시뮬레이터의 경우에는 아이디얼(Ideal)한 센서와 로지컬한 환경에서 2D 기반으로 시뮬레이션이 이뤄지며, 수백만 km의 로드테스트를 하루 만에 할 수 있다. 3D+시뮬레이터는 가장 정확도가 높고 타깃이 명확하지만 하루에 수천 km의 테스트밖에 할 수 없다. 자율주행 Level 2나 ADAS 기능 확인 같은 경우에는 3D 시뮬레이터로 충분했지만, Level 3 이상을 커버하기 위해서는 완전히 다른 툴 체인이 필요하다. 무엇보다 센서 모델이나 환경 구축, 어떤 로직이 준비돼 있는지에 따라 시뮬레이터 선정이 달라지기 때문에, 목적에 부합하는 가장 효율적인 시뮬레이터를 선택하는 것이 가장 중요하다.
시뮬레이터를 선택했다면 완전한 ADAS/AD의 설계와 검증을 위해 시뮬레이터를 확장해야 한다. 여기서 가장 중요한 부분은 ODD, 정의된 피처와 FuSa/SOTIF/CySe로 통칭되는 Safety 그리고 시나리오가 Closed-Loop 시뮬레이터와 연결/추적되는 연결고리가 확장되는 것이다. ODD부터 Safety가 반영되고 Safety가 또 시나리오에 반영되어서 다시 Closed-Loop 시뮬레이션에 유기적으로 연결되는 시뮬레이터를 ‘통합 툴 체인이 완전하게 구축된 시뮬레이터’라고 할 수 있을 것이다. 데이터 라이브러리 혹은 데이터 리니지(Data Lineage)라고 불리는 데이터 센터 안에서 시뮬레이션된 결과를 수집하고 분류하며 최적화하는 방법들이 모두 다 한꺼번에 통합 툴 체인 안에서 들어가서 시뮬레이션되는 시나리오나 안전성 있는 팩터(factor)에 다시 유기적으로 연결되는 것이 최근 글로벌 트렌드에서 중요하게 부각되고 있다. 단순히 데이터를 모으는 것에 그치는 것이 아니고 의미 있는 데이터를 골라내고 다시 시뮬레이터를 통해 유기적으로 연결되는 확장성을 가진 시뮬레이션 툴 체인이 매우 중요하다. 현장에서 사용하는 소프트웨어나 툴의 환경들이 각각 다르기 때문에 ASAM 같은 표준화된 언어를 사용해서 유연성을 확보할 수 있다. Closed-Loop 시뮬레이션부터 시나리오, ODD 등이 모두 유기적으로 연결될 수 있게 언어를 통일하고 표준화하는 것이 시뮬레이터를 선택하고 개발하고 확장하는 데 있어 유연성 있는 툴 체인 확보를 위해 가장 중요한 전략이다.


시뮬레이터의 준비와 선택  

표준화를 통한 유연성 확보 



Ansys Autonomy: 
ADAS/AD 위한 안전 기반 워크플로  

Ansys Workflow는 ODD부터 밸리데이션까지 모든 영역을 수행할 수 있다. ODD는 자율주행 차량이 어떤 영역을 운행할지 자율주행 개발 업체에서 결정하는 부분이다. 보통 ODD로부터 테스트 시나리오가 나오지만 ODD와 시나리오 영역은 완벽하게 겹치지 않는다. ODD에서 고려되는 시나리오 영역만으로 시뮬레이션 테스트를 진행하면 미처 생각하지 못했던 변수를 고려할 수 없기 때문이다. 따라서 ODD를 좀 더 벗어난 영역에 대해서 시뮬레이션을 진행하며 SOTIF나 기능안전성에 대한 부분들이 시나리오에 녹아들 수 있도록 한다.

예를 들어 ODD가 “고속도로 상황에서 자율주행을 한다”는 상황을 설정하는 것이라면, 드라이빙 시나리오 엔지니어 단계에서는 단순한 고속도로를 지정하는 것에 그치지 않고 교통 도심 상황 반영이나 고속도로 진출입 위치를 설정하는 등, 보다 상세한 영역을 설정하는 것이 필요하기 때문에 시나리오에 대한 플로를 짜야 한다. 또 낮 시간대 혹은 밤 시간대의 주행 같은 설정도 엔지니어단에서 시나리오에 반영할 수 있다.

Functional Architecture에는 시스템 엔지니어, 안전 부분에 대한 엔지니어, 시뮬레이션 엔지니어 등 세 부류의 엔지니어가 모두 참여한다. 예를 들어, 시스템 엔지니어가 Architecture를 구성하게 되면 안전 엔지니어가 이 Architecture가 정말로 안전한지를 검증한 후에 다시 시뮬레이션 엔지니어가 그 Architecture가 시뮬레이션으로 돌려봤을 때 구성에 문제가 없는지를 확인하는 식으로 이뤄진다. 자율주행 Level 4 이상을 위해서는 Architecture를 단순하게 꾸미는 데서 끝나지 않는다. 정말 시스템에 대해서 안전성에 대한 문제가 있는지 없는지 검토하는 과정이 꼭 필요하다.

안전 분석은 여러 방법이 가능한데, 각 요소에 따라서 추적할 수 있으며 또한 위험에 대한 분석이나 Functional Architecture 부분에 대해서 어떤 부분이 빠졌고 더 필요한지를 확인할 수 있다. 예를 들어 브레이크에 대한 기능을 설계한다고 했을 때 전방에 차량이 있을 경우 인지를 하고 브레이크를 밟으라는 명령을 내릴 수 있다. 그런데 곡선 주행 상황에서는 앞에 차량이 있더라도 차선이 같지 않기 때문에 브레이크를 밟을 필요가 없다. 이처럼 곡선 주행 상황을 차량이 인지해야 한다는 Functional 부분을 추가하면 곡선 주행 상황에서 전방에 차량이 있더라도 브레이크를 밟지 않고 자연스럽게 자동차를 주행하도록 유도할 수 있다.




Functional Architecture Definition 



Physical Allocation at Vehicle leve



Technical Architecture Definition 
and Selection of Components   

Functional Architecture가 정의되면 거기에 속해 있는 블록이 각 Physical Architecture와 매핑이 되고 그 매핑된 블록 자체를 Technical Architecture로 볼 수 있다. 예를 들어 프로그램 내에서 Functional Architecture 부분에서 Perception이라는 박스를 볼 수 있는데, 실제 물리적 구성으로 봤을 때 이는 센서에 해당이 된다. 센서 종류는 매우 다양하지만 레이더 센서만 선택해서 시뮬레이션을 돌린다고 생각해보자. 그전에 엔지니어는 각종 센서에 대해 장단점을 파악한 뒤에 센서를 정의할 수가 있는데, Requirements에 부합이 되면 그 센서를 쓸 수 있다고 엔지니어가 판단할 수 있다. 하지만 센서 위치에 대한 내용은 Requested에 나와 있지 않기 때문에 시뮬레이션 엔지니어가 이 부분을 다시 수행해서 이 요구사항이 맞는지 확인해야 한다.


Ideal 센서를 이용한 
센서 장착 위치 검증  중제

Ideal 센서를 이용해서 센서를 어떤 위치에 장착하는 것이 가장 적합한지도 파악할 수 있다. 예를 들어, 현재 장착된 센서의 높이나 방향에 문제가 없는지 알고 싶다면 라이더 센서, 카메라 센서, 레이더 센서 등이 엔지니어가 보고 싶은 방향을 정확하게 인지하고 커버하고 있는지를 확인해야 한다. 오류가 있다면 Requirements 부분을 수정해서 Architecture를 재구성해야 한다.

물리 기반 센서에 대해서도 고려해야 한다. 예를 들어, 카메라 센서가 윈드실드 뒤에 장착돼 있기 때문에 외광에 의해서 카메라가 전방을 보지 못하고 윈드실드에 반사된 물체를 전방에 있다고 인지하는 경우가 생길 수 있다. 이런 오류를 방지하기 위해 실제 물리 기반 센서에 대해서 시뮬레이션을 하고 그 현상을 이해해야만 센서의 제한적인 부분을 정확히 찾을 수 있다.

라이더나 레이더 센서도 마찬가지다. 실제로 센서에 대한 모델링은 인지 알고리즘이 ideal 센서로 바로 받는 게 아니라 라이더 센서나 레이더 센서의 데이터에서 나온 raw 데이터를 기반으로 다시 한번 계산해서 인지하게끔 돼 있다. 때문에 Ideal 센서에서 나온 리소스 데이터와 실제 물리 기반 센서에서 나온 raw 데이터를 통해 얻은 타깃팅 데이터가 얼마나 다른지 알아야만 자율주행 Level 4를 위한 정확한 시뮬레이션을 할 수 있다.



Ideal 센서를 이용한 센서 장착 위치 검증


이처럼 성능에 대한 취약성과 한계를 파악한 다음에 Architecture를 검토하고 다시 시뮬레이션을 통해 검증해야 안전성을 보장할 수 있다. 안전성은 여러 번 강조했듯이 Level 4 이상을 달성하기 위한 가장 중요한 요소이기 때문에 최우선으로 고려해야 한다. 

도로 보수공사 관계로 도로에 철판이 깔려 있는 상황을 가정해보자. 레이더 센서만 사용하면 주행에 문제가 없음에도 철판을 인지하고 급 브레이크를 걸어 차량이 정지된다. 이처럼 Technical Architecture 단계 시뮬레이션 시에 레이더 센서만 사용하면 잘못된 판단을 내릴 수 있기 때문에 안전을 위해 추가적으로 보완해 레이더 센서와 카메라 센서를 융합해 인지 알고리즘을 짜야 한다. 이를 시뮬레이션을 통해 검증하기 위해서 환경을 구성하면, 앞서 말한 것과 같이 고속도로에 철판이 깔려 있고 차량이 주행했을 때 인지하고 멈추지 않는지 멈추는지를 확인할 수 있다.

이처럼 실제로 유도한 대로 동작하는지에 대한 여부를 시뮬레이션으로 검증할 수 있기 때문에, 센서에 대한 취약성과 한계를 파악한 뒤에 Architecture 구성과 모델링을 진행하고 다시 시뮬레이션을 하는 방식으로 검증해야 한다.

여기에서 끝이 아니다. 모델이 완성된 이후에는 실제로 컨트롤러 소프트웨어를 생성해서 업데이트해야 한다. Ansys SCADE를 사용하면 LC ASIL-D 등급의 코드 제네레이터를 이용해서 컨트롤 소프트웨어를 사용할 수 있고 생성된 소프트웨어로 다시 시뮬레이션을 통해 자율주행 차에 대해서 안전성을 다시 검토할 수 있다.



도로 보수 공사 상황 예시



Validation of the ADAS/AD Function 

마지막으로 Validation에 대해 알아보자. 앞서 말한 대로 보조 기능 같은 자율주행에 필요한 기능을 시뮬레이션 테스트를 이용해서 검증할 수가 있는데, 이를 위해 첫 번째로 할 일은 테스트 시나리오를 짜는 일이다. 테스트 시나리오는 Functional 시나리오와 Logical 시나리오로 나눌 수 있는데 Functional 시나리오는 말로 설명할 수 있는 상황이라고 이해하면 된다. 예를 들어, 고속도로에서 커브 진입 위치나 심각한 교통 체증 등의 상황을 전제로 했을 때, 차량이 정지한다는 시나리오를 설정한다면 이 자체가 Functional 시나리오이다. 그리고 이처럼 말로 설명한 시나리오를 숫자로 표현한 것이 Logical 시나리오이다.

Ansys Workflow는 Logical 시나리오를 기반으로 Safety 엔지니어가 안전성을 검증하기 위해 안전에 대한 테스트를 충분히 했는지 검토하고 이 부분을 다시 시뮬레이션 엔지니어로 넘기는 방식으로 진행된다. 시뮬레이션 엔지니어는 숫자를 파라미터화해, 단순히 하나의 시나리오만 시뮬레이션해서 결과를 얻는 것이 아니고 시나리오를 기반으로 여러 가지 상황을 연출해서 테스트할 수 있다.

우선적으로 해야 하는 일은 라이더 센서나 레이더 센서를 사용해서 전방의 물체가 인지되는지 확인하고 혹은 카메라 센서를 이용해서 물체나 차선이 인지되는지 테스트해야 한다. 레이더 센서를 통해 기본적인 센서 검증을 진행할 수도 있다. 센서가 검증되었다면 다음으로 센서에 대한 기능을 기반으로 차량이 정확하게 움직이는지 시뮬레이션해야 한다.



센서를 통한 물체 인지 예시


이런 식으로 각 센서의 융합을 통해서 어떤 특정 센서의 물체 인지 여부를 확인할 수 있고 인지를 통해 어떻게 반응할 것인지 차량에 명령을 내리는 것이다. 이를 토대로 고속도로 상황에서 교통 체증이 일어났을 때 정지하라는 명령을 내린다고 가정해보자. 이렇게 말로 했을 때는 간단하게 설명할 수 있지만 사실상 이 시나리오에는 약 14가지 정도의 파라미터가 사용되었다.

Ansys Workflow에서는 이 많은 시나리오를 다 한꺼번에 시뮬레이션하지 않아도, 파라미터에 대한 중요성을 기준으로 특정 파라미터가 더 중요하기 때문에 이 파라미터를 더 우선적으로 하라든지 혹은 다른 파라미터는 중요하지 않기 때문에 그 파라미터는 나중에 하라는 식으로 효율적으로 명령할 수 있다. 파라미터에 대한 선별 작업을 통해 최적화된 시나리오를 통한 시뮬레이션을 할 수 있는 것이다. 이러한 효율성이 Ansys Workflow의 가장 큰 특징이라고 할 수 있다.

내용을 요약하자면, 신뢰할 수 있는 자율주행을 위해 가장 중요한 척도인, 완전한 툴 체인을 위해서는 일반적인 로드데이터나 테스트데이터 같은 드라이버 데이터들이 버추얼 시뮬레이션 툴 체인과 결합해야만 가능하다. 버추얼 시뮬레이션 툴 체인은 테스트데이터, 로드데이터, ODD부터 Safety가 준비되고 시나리오가 유기적으로 연결되는 Closed-Loop 시뮬레이션 등을 통해서 가장 현실감 있고 살아 움직이는 시뮬레이션을 가능하게 하기 때문이다.

다만, 툴 체인 사용 시 Scope를 넓게 잡으면 무한에 가까워지고 좁게 잡으면 정밀도가 떨어지는 단점이 있는데, 2D 시뮬레이터부터 3D 같은 특정 목적을 달성하기 위한 정밀도가 높은 시뮬레이션을 선택하는 것이 중요할 것이다. 무엇보다 가장 중요한 것은 안전이 고려된 디자인이며, 안전이 고려된 디자인이 담을 수 있는 시나리오와 팩터들이 이런 툴 체인을 통해서 유기적으로 연결되었을 때 그것을 완전한 툴 체인이라고 할 수 있다. 

각 개발자 입장에서는 담당하는 분야가 서로 다르기 때문에 각각의 컴포넌트들이 자신이 원하는 툴 체인 안에서 어떤 피드백을 받고 어떤 결과를 내는지가 가장 중요하게 여겨질 것이다. OEM과 정부 등 통합적인 툴 체인을 개발할 수 있는 분야에서 툴 체인을 공유할 수 있다면 한국의 버추얼 시뮬레이터와 Level 4 이상의 자율주행을 이루는 데 가장 중요한 역할을 할 수 있을 것으로 믿는다.



완전한 버추얼 시뮬레이션 툴 체인