KR20230160807A - 모바일 로봇 궤적 계획기들에 대한 성능 테스트 - Google Patents

Abstract

실제 또는 시뮬레이션된 시나리오에서 모바일 로봇에 대한 궤적 계획기의 성능을 평가하는, 컴퓨터로 구현된 방법이 제공되고, 이러한 방법은, 시나리오의 시나리오 실측 자료를 수신하는 것을 포함하고, 여기서 시나리오 실측 자료는 시나리오의 적어도 하나의 시나리오 요소에 응답하여 시나리오의 주체 에이전트를 제어하기 위해 궤적 계획기를 사용하여 발생된다. 시나리오에 대한 하나 이상의 성능 평가 규칙들 및 각각의 성능 평가 규칙에 대한 적어도 하나의 활성화 조건이 수신된다. 각각의 성능 평가 규칙의 활성화 조건이 시나리오의 복수의 시간 단계들에 걸쳐 충족되는지 여부를 결정하기 위해 테스트 오라클이 시나리오 실측 자료를 프로세싱한다. 각각의 성능 평가 규칙은 활성화 조건이 충족되는 경우에만 적어도 하나의 테스트 결과를 제공하기 위해 테스트 오라클에 의해 평가된다.

Description

모바일 로봇 궤적 계획기들에 대한 성능 테스트

본 개시내용은 실제 또는 시뮬레이션된 시나리오(real or simulated scenario)들에서 궤적 계획기(trajectory planner)들의 성능을 평가하기 위한 방법들에 관한 것이고, 그리고 이것을 구현하기 위한 컴퓨터 프로그램들 및 시스템들에 관한 것이다. 이러한 계획기들은 완전/반-자율주행 차량들(fully/semi-autonomous vehicles) 또는 모바일 로봇(mobile robot)의 다른 형태들에 대한 주체 궤적들(ego trajectories)을 자율적으로 계획할 수 있다. 예시적 응용들은 ADS(Autonomous Driving System; 자율 주행 시스템) 및 ADAS(Advanced Driver Assist System; 첨단 운전자 보조 시스템) 성능 테스트(performance testing)를 포함한다.

자율주행 차량들의 분야에서 주요한 그리고 급속한 발전들이 존재해 왔다. 자율주행 차량(Autonomous Vehicle, AV)은, 인간이 차량의 행태(behaviour)를 제어함이 없이, 차량으로 하여금 동작할 수 있게 하는 센서들 및 제어 시스템들이 장착된 차량이다. 자율주행 차량은 자율주행 차량으로 하여금 자신의 물리적 환경을 지각(perceive)할 수 있게 하는 센서들을 장착하고 있는데, 이러한 센서들은 예를 들어, 카메라들, 레이다(radar) 및 라이다(lidar)를 포함한다. 자율주행 차량들은, 센서들로부터 수신된 데이터를 프로세싱할 수 있고, 아울러 센서들에 의해 지각된 상황(context)에 근거하여 안전한 그리고 예측가능한 결정들을 행할 수 있는, 적절하게 프로그래밍된 컴퓨터들을 장착하고 있다. 자율주행 차량은, (자율주행 차량이 적어도 특정 상황들에서 어떠한 인간의 감독 또는 개입 없이 동작하도록 설계된다는 점에서) 완전 자율주행 차량일 수 있거나, 또는 반-자율주행 차량일 수 있다. 반-자율주행 시스템들은 인간의 감독 및 개입의 다양한 레벨(level)들을 요구할 수 있는데, 이러한 시스템들은 첨단 운전자 보조 시스템들 및 레벨 3 자유 주행 시스템들을 포함한다. 특정 자율주행 차량 또는 임의 타입(type)의 자율주행 차량에 탑재된 센서들 및 제어 시스템들의 행태를 테스트하기 위한 상이한 양상들이 존재한다.

"레벨 5(level 5)" 차량은 임의의 상황들에서 전체적으로 자율적으로 동작할 수 있는 차량인데, 왜냐하면 이러한 차량은 안전의 어떤 최소 레벨을 만족시키도록 항상 보장되기 때문이다. 이러한 차량은 수동 제어들(조향 휠(steering wheel), 페달(pedal)들, 등)을 전혀 요구하지 않게 된다.

대조적으로, 레벨 3 및 레벨 4 차량들은 완전히 자율적으로 동작할 수 있지만, 단지 특정된 정의된 상황들에서만(예컨대, 가상울타리 영역(geofenced area)들 내에서만) 그럴 수 있다. 레벨 3 차량에는 (비상 제동(emergency braking)과 같은) 즉각적인 응답을 요구하는 임의의 상황을 자율적으로 핸들링(handle)하기 위한 장비가 갖추어져 있어야만 하는데, 하지만, 상황들에서의 변경은 운전자로 하여금 일부 제한된 시간프레임(timeframe) 내에 차량의 제어를 취하도록 요구하는 "전이 요구(transition demand)"를 트리거(trigger)할 수 있다. 레벨 4 차량은 유사한 제한들을 갖지만, 운전자가 요구된 시간프레임 내에 응답하지 않는 경우에, 레벨 4 차량은 또한, "최소 위험 운행(Minimum Risk Maneuver, MRM)"을 자율적으로 구현할 수 있어야만 하는데, 즉, 차량이 안전한 조건들에 있도록 하기 위한 어떤 적절한 행위(action)(들)(예컨대, 차량을 감속시키는 것 및 주차시키는 것)를 자율적으로 구현할 수 있어야만 한다. 레벨 2 차량은 운전자로 하여금 임의의 시간에 개입할 준비를 하도록 요구하고, 그리고 만약 자율주행 시스템들이 임의의 시간에 적절하게 응답하는 데 실패한다면 개입은 운전자의 책임이다. 레벨 2 자동화에 있어서, 개입이 요구되는 때를 결정하는 것은 운전자의 책임이고, 레벨 3 및 레벨 4에 대해서, 이러한 책임은 차량의 자율주행 시스템들로 이동하고, 그리고 개입이 요구되는 때를 운전자에게 경고해야만 하는 것은 차량이다.

자율성(autonomy)의 레벨이 증가하고 더 많은 책임이 인간으로부터 기계로 이동함에 따라 안전은 증가하는 도전과제이다. 자율 주행에서, 보장된 안전의 중요성이 인식되었다. 보장된 안전은 0개의 사고들을 반드시 의미하는 것이 아니라 정의된 상황들에서 안전의 어떤 최소 레벨이 만족됨을 보장하는 것을 의미한다. 안전의 이러한 최소 레벨은 자율 주행이 실행가능하도록 하기 위해 인간 운전자들의 레벨을 상당히 초과해야한다고 일반적으로 가정된다.

본 명세서에 그 전체가 참조로 통합되는 문헌[저자: 샤레브-쉬와르츠(Shalev-Shwartz), 외, 제목: "On a Formal Model of Safe and Scalable Self-driving Cars" (2017), arXiv:1708.06374 (RSS 논문(the RSS Paper))]에 따르면, 인간 주행은 시간 당 대략 10^-6 건의 심각한 사고들을 유발하는 것으로 추정된다. 자유 주행 시스템들이 적어도 3차수의 크기만큼 이것을 감소시킬 필요가 있을 것이라는 가정 하에, RSS 논문은 시간 당 대략 10^-9 건의 심각한 사고들이 있는 최소 안전 레벨이 보장될 필요가 있다고 결론을 내리고 있는데, 따라서 이것은 순수하게 데이터로-구동되는 접근법은 AV 시스템의 소프트웨어 또는 하드웨어에 변경이 행해질 때마다 방대한 분량의 주행 데이터가 수집될 것을 요구하게 됨을 말한다.

RSS 논문은 보장된 안전에 대한 모델-기반 접근법을 제공한다. 규칙-기반(rule-based) 책임-민감성 안전(Responsibility-Sensitive Safety, RSS) 모델은 다음과 같은 작은 수의 "상식(common sense)" 주행 규칙들을 공식화함으로써 구성된다.

1. 누군가를 뒤에서 치지 마라(Do not hit someone from behind).

2. 무모하게 끼어들지 마라(Do not cut-in recklessly).

3. 통행권은 빼앗는 것이 아닌 주어지는 것이다(Right-of-way is given, not taken).

4. 가시성이 제한된 영역에서 주의하라(Be careful of areas with limited visibility).

5. 또 다른 사고를 초래함이 없이 사고를 피할 수 있다면 그렇게 해야만 한다(If you can avoid an accident without causing another one, you must do it).

RSS 모델은, 모든 에이전트(agent)들이 항상 RSS 모델의 규칙들을 준수한다면 어떠한 사고들도 일어나지 않게 된다는 의미에서 입증가능한 안전으로 제시된다. 목표는 요구된 안전 레벨을 증명(demonstrate)하기 위해 수집될 필요가 있는 주행 데이터의 양을 수 차수의 크기만큼 감소시키는 것이다.

(RSS와 같은) 안전 모델은, 자율주행 시스템의 제어(스택(stack)) 하에서 실제 또는 시뮬레이션된 시나리오에서 주체 에이전트(ego agent)에 의해 실현되는 궤적들의 품질을 평가하기 위한 기반으로서 사용될 수 있다. 스택은, 상이한 시나리오들에 노출됨으로써, 그리고 안전 모델의 규칙들을 준수하는 것에 대한 결과적인 주체 궤적들을 평가함으로써, 테스트된다(규칙들-기반 테스트). 규칙들-기반 테스트 접근법은 또한, 정의된 목표를 향한 진행(progress) 또는 안락(comfort)과 같은 성능의 다른 양상들에 적용될 수 있다.

본 명세서에서의 제 1 실시형태에 따르면, 실제 또는 시뮬레이션된 시나리오(real or simulated scenario)에서 모바일 로봇(mobile robot)에 대한 궤적 계획기(trajectory planner)의 성능을 평가하는, 컴퓨터로 구현된 방법이 제공되고, 이러한 방법은, 시나리오의 시나리오 실측 자료(scenario ground truth)를 수신하는 것(여기서, 시나리오 실측 자료는 시나리오의 적어도 하나의 시나리오 요소에 응답하여 시나리오의 주체 에이전트(ego agent)를 제어하기 위해 궤적 계획기를 사용하여 발생됨); 시나리오에 대한 하나 이상의 성능 평가 규칙(performance evaluation rule)들 및 각각의 성능 평가 규칙에 대한 적어도 하나의 활성화 조건(activation condition)을 수신하는 것; 그리고 각각의 성능 평가 규칙의 활성화 조건이 시나리오의 복수의 시간 단계(time step)들에 걸쳐 충족되는지 여부를 결정하기 위해 테스트 오라클(test oracle)에 의해 시나리오 실측 자료를 프로세싱(processing)하는 것을 포함한다. 각각의 성능 평가 규칙은 활성화 조건이 충족되는 경우에만 적어도 하나의 테스트 결과(test result)를 제공하기 위해 테스트 오라클에 의해 평가된다.

통과/실패 규칙들(pass/fail rules)의 상황에서, 이것은 주어진 시간 단계에서 규칙이 평가할 수 있는 제3의 '적용가능하지 않음(not applicable)"을 제공한다. 특히, (전형적으로 테스트에서 시뮬레이션 또는 시뮬레이션의 조합에서 발생되는) 대량의 시나리오 데이터를 평가할 때, 많은 시간 단계들 및 많은 시나리오들에 걸쳐 잠재적으로 복잡한 규칙들을 평가하는 것은 매우 큰 컴퓨팅연산 리소스(computational resource)들을 요구할 수 있다. (규칙들 그 자체보다 평가하기에 더 저렴한) 더 간단한 활성화 조건들에 근거하여 규칙들을 '비활성화(deactivating)'시킴으로써, 최종 결과들에 해롭지 않은 방식으로 상당한 리소스들의 절약들이 획득될 수 있다. 실제로, '적용할 수 없는' (비활성) 결과가 종종 더 유익함(informative)에 따라, 결과들의 품질은 향상될 수 있는데, 왜냐하면 이것은 규칙이 적용될 수 있는 그리고 통과/실패되는 상황과 규칙이 자연스럽게 적용될 수 있는 상황을 구분하기 때문이다. 예를 들어, 교차로 시나리오(junction scenario)에서, 규칙은, 주체 에이전트가 합류(join)하기를 원하는 도로 상에서 복수의 다른 에이전트들에 대한 다양한 거리 임계치들과 관련하여 정의될 수 있고, 그리고 주체 에이전트가 도로의 경계(boundary)를 횡단할 때에만 활성화될 수 있다. 만약 규칙이 대신 항상 활성 상태라면, 이것은 주체 에이전트가 교차로에서 대기하고 있는 때 평가하기 위해 비용이 많이 들 수 있을 뿐만 아니라 그 기간에서의 결과들은 그다지 유익한 것이 아니게 된다(말하자면, '통과'와 '적용가능하지 않음' 간의 구분이 없는 상황과 비교됨).

실시예들에서, 시나리오 실측 자료는, 각각의 성능 평가 규칙의 활성화 조건이 복수의 시나리오 요소들의 세트의 각각의 시나리오 요소에 대해 시나리오의 복수의 시간 단계들에 걸쳐 충족되는지 여부를 결정하기 위해 프로세싱될 수 있다. 각각의 성능 평가 규칙은, 활성화 조건이 시나리오 요소들 중 적어도 하나에 대해 충족되는 경우에만, 그리고 활성화 조건이 충족되는 시나리오 요소(들)와 주체 에이전트 간에만, 평가될 수 있다.

실시예들에서, 각각의 성능 평가 규칙은 규칙 생성 코드(rule creation code)의 단편(piece)에서 제 2 로직 술어(logic predicate)로서 인코딩(encode)될 수 있고, 활성화 조건은 여기서 제 1 로직 술어로서 인코딩되며, 각각의 시간 단계에서, 테스트 오라클은, 각각의 시나리오 요소에 대해 제 1 로직 술어를 평가하고, 그리고 제 1 로직 술어를 충족시키는 임의의 시나리오 요소와 주체 에이전트 간에만 제 2 로직 술어를 평가한다.

상이한 각각의 활성화 조건들을 갖는 복수의 성능 평가 규칙들이 수신될 수 있고, 그리고 상이한 각각의 활성화 조건들에 따라 테스트 오라클에 의해 선택적으로 평가될 수 있다.

각각의 성능 평가 규칙은 주행 성능((driving performance))과 관련될 수 있다.

방법은, 복수의 시간 단계들에 대한 각각의 결과들을 시-계열로 그래픽 사용자 인터페이스(Graphical User Interface, GUI) 상에 렌더링(rendering)하는 것을 포함할 수 있고, 각각의 시간 단계에서의 결과는 적어도 세 개의 범주들(categories) 중 하나의 범주를 시각적으로 표시하고, 여기서 적어도 세 개의 범주들은, 활성화 조건이 충족되지 않은 경우의 제 1 범주, 활성화 조건이 충족되고 규칙이 통과(pass)되는 경우의 제 2 범주, 그리고 활성화 조건이 충족되고 규칙이 실패(fail)되는 경우의 제 3 범주를 포함한다.

예를 들어, 결과는 적어도 세 개의 범주들에 대응하는 적어도 세 개의 상이한 컬러(colour)들 중 하나의 컬러로서 렌더링될 수 있다.

성능 평가 규칙들 중 제 1 성능 평가 규칙의 활성화 조건은 성능 평가 규칙들 중 적어도 제 2 성능 평가 규칙의 활성화 조건에 종속될 수 있다.

예를 들어, (예컨대, 안락(comfort)과 관련되는) 제 1 성능 평가 규칙은 (예컨대, 안전(safety)과 관련되는) 제 2 성능 평가 규칙이 활성 상태일 때 비활성화(deactivate)될 수 있다.

시나리오 요소들은 하나 이상의 다른 에이전트들을 포함할 수 있다.

성능 평가 규칙들 중 적어도 하나는 시나리오에서 시나리오 요소들의 세트의 하나의 시나리오 요소 주체 에이전트 간에 쌍으로(pairwise) 선택적으로 평가될 수 있고, 활성화 조건은 각각의 시간 단계에서 주체 에이전트와 다른 에이전트 간의 성능 평가 규칙을 평가할지 여부를 결정하기 위해 각각의 시나리오 요소에 대해 독립적으로 평가될 수 있다.

시나리오 요소들의 세트는 다른 에이전트들의 세트일 수 있다.

각각의 시간 단계에서, 활성화 조건이 충족되는 임의의 시나리오 요소들의 식별자를 포함하는 반복가능 객체(iterable)를 컴퓨팅(compute)하기 위해 각각의 시나리오 요소에 대한 활성화 조건이 평가될 수 있고, 그리고 성능 평가 규칙은 각각의 시간 단계에서 반복가능 객체에 걸쳐 반복실행(looping)을 행함으로써 평가될 수 있다.

성능 평가 규칙은 시나리오 실측 자료로부터 추출된 하나 이상의 신호들에 적용되는 컴퓨팅연산 그래프(computational graph)로서 정의될 수 있으며, 반복가능 객체는 활성화 조건을 충족시키는 임의의 시나리오 요소 주체 에이전트 간의 규칙을 평가하기 위해 컴퓨팅연산 그래프를 통해 전달된다.

본 명세서에서의 추가 실시형태는, 실제 또는 시뮬레이션된 시나리오에서 모바일 로봇에 대한 궤적 계획기의 성능을 평가하는, 컴퓨터로 구현된 방법을 제공하고, 이러한 방법은, 시나리오의 시나리오 실측 자료를 수신하는 것(여기서, 시나리오 실측 자료는 시나리오의 하나 이상의 시나리오 요소들에 응답하여 시나리오의 주체 에이전트를 제어하기 위해 궤적 계획기를 사용하여 발생됨); 시나리오에 대한 하나 이상의 성능 평가 규칙들 및 각각의 성능 평가 규칙에 대한 적어도 하나의 활성화 조건을 수신하는 것; 그리고 각각의 시나리오 요소에 대해, 각각의 성능 평가 규칙의 활성화 조건이 시나리오의 복수의 시간 단계들에 걸쳐 충족되는지 여부를 결정하기 위해 테스트 오라클에 의해 시나리오 실측 자료를 프로세싱하는 것을 포함하고, 각각의 성능 평가 규칙은, 활성화 조건이 시나리오 요소들 중 적어도 하나에 대해 충족되는 경우에만, 그리고 활성화 조건이 충족되는 시나리오 요소(들)와 주체 에이전트 간에만, 적어도 하나의 테스트 결과를 제공하기 위해 테스트 오라클에 의해 평가된다.

추가적인 실시형태들은, 제 1 실시형태의 방법 또는 이것의 임의의 실시예를 구현하도록 구성된 하나 이상의 컴퓨터들을 포함하는 컴퓨터 시스템을 제공하고, 그리고 이들을 구현하도록 컴퓨터 시스템을 프로그래밍하기 위한 실행가능한 프로그램 명령들을 제공한다.

본 개시내용을 더 잘 이해하기 위해, 그리고 이것의 실시예들이 어떻게 실행될 수 있는지를 보여 주기 위해, 다음과 같는 도면들이 단지 예로서 참조되며, 이러한 도면들에서,
도 1a는 자율주행 차량 스택(autonomous vehicle stack)의 개략적인 기능 블록도를 보여주고;
도 1b는 자율주행 차량 테스트 패러다임(autonomous vehicle testing paradigm)의 개략적인 개관을 보여주고;
도 1c는 시나리오 추출 파이프라인(scenario extraction pipeline)의 개략적인 블록도를 보여주고;
도 2는 테스트 파이프라인(testing pipeline)의 개략적인 블록도를 보여주고;
도 2a는 테스트 파이프라인의 가능한 구현예의 추가 세부사항들을 보여주고;
도 3a는 테스트 오라클(test oracle) 내에서 평가되는 규칙 트리(rule tree)의 예를 보여주고;
도 3b는 규칙 트리의 노드(node)의 예시적인 출력을 보여주고;
도 4a는 테스트 오라클 내에서 평가될 규칙 트리의 예를 보여주고;
도 4b는 시나리오 실측 자료 데이터(scenario ground truth data)의 세트에 관해 평가되는 규칙 트리의 제 2 예를 보여주고;
도 4c는 어떻게 규칙들이 테스트 오라클 내에서 선택적으로 적용될 수 있는지를 보여주고;
도 5는 그래픽 사용자 인터페이스(graphical user interface)를 렌더링(rendering)하기 위한 시각화 컴포넌트(visualization component)의 개략적인 블록도를 보여주고;
도 5a, 도 5b, 및 도 5c는 그래픽 사용자 인터페이스 내에서 이용가능한 상이한 뷰(view)들을 보여주고;
도 6a는 끼어들기(cut-in) 시나리오의 제 1 인스턴스(instance)를 보여주고;
도 6b는 제 1 시나리오 인스턴스에 대한 예시적인 오라클 출력을 보여주고;
도 6c는 끼어들기 시나리오의 제 2 인스턴스를 보여주고;
도 6d는 제 2 시나리오 인스턴스에 대한 예시적인 오라클 출력을 보여주고;
도 7은 테스트 오라클에 의해 적용될 규칙들을 정의하기 위한 도메인 특정 언어(domain specific language)에서의 규칙 생성 코드(rule creation code)의 예를 보여주고; 그리고
도 8은 맞춤형 규칙 트리(custom rule tree)들의 출력들을 렌더링하기 위한 GUI 뷰의 추가 예를 보여준다.

설명되는 실시예들은 실제 또는 시뮬레이션된 시나리오들에서 모바일 로봇 스택(mobile robot stack)들의 규칙들-기반 테스트(rules-based testing)를 용이하게 하기 위한 테스트 파이프라인(testing pipeline)을 제공한다. 실제 또는 시뮬레이션된 시나리오들에서의 에이전트(행위자) 행태(behaviour)는 정의된 성능 평가 규칙들에 근거하여 테스트 오라클에 의해 평가된다. 이러한 규칙들은 안전의 상이한 양상들을 평가할 수 있다. 예를 들어, 특정 안전 표준, 규정(regulation) 혹은 안전 모델(예컨대, RSS)에 대비하여 스택의 성능을 평가하기 위해 안전 규칙 세트가 정의될 수 있고, 또는 성능의 임의의 양상을 테스트하기 위해 맞춤형 규칙 세트들이 정의될 수 있다. 테스트 파이프라인은 안전에 대한 적용에 한정되지 않으며, 어떤 정의된 목표를 향한 진행 또는 안락과 같은 성능의 임의의 양상들을 테스트하기 위해 사용될 수 있다. 규칙 편집기(rule editor)는 성능 평가 규칙들이 정의될 수 있게 하거나 수정될 수 있게 하고 그리고 테스트 오라클에게 전달될 수 있게 한다.

"전체(full)" 스택은 전형적으로, 낮은-레벨 센서 데이터(지각(perception))의 프로세싱 및 해석으로부터의 모든 것을 포함하는데, 이것은 예측 및 계획과 같은 1차 더 높은-레벨 기능들에 공급되고, 뿐만 아니라 계획-레벨 결정들을 구현하기 위해(예를 들어, 제동, 조향, 가속, 등을 제어하기 위해) 적절한 제어 신호들을 발생시키기 위한 제어 로직(control logic)을 포함한다. 자율주행 차량들에 대해, 레벨 3 스택들은 전이 요구들을 구현하기 위한 어떤 로직을 포함하고, 레벨 4 스택들은 최소 위험 운행들을 구현하기 위한 어떤 로직을 추가적으로 포함한다. 스택은 또한, 예를 들어, 시그널링(signalling), 헤드라이트(headlight)들, 차량 앞유리 와이퍼(windscreen wiper)들, 등의 2차 제어 기능들을 구현할 수 있다.

용어 "스택(stack)"은 또한, 개별적으로 또는 임의의 원하는 조합으로 테스트될 수 있는, 지각, 예측, 계획, 또는 제어 스택들과 같은, 전체 스택의 개별 서브-시스템들(sub-systems)(서브-스택들(sub-stacks))을 지칭할 수 있다. 스택은 순수하게 소프트웨어를 지칭할 수 있는데, 즉, 하나 이상의 범용 컴퓨터 프로세서들 상에서 실행될 수 있는 하나 이상의 컴퓨터 프로그램들을 지칭할 수 있다.

실제 또는 시뮬레이션된 시나리오는 주체 에이전트로 하여금 실제 또는 모델링된 물리적 상황을 항행(navigate)하도록 요구한다. 주체 에이전트는 테스트 중인 스택의 제어 하에서 움직이는 실제 또는 시뮬레이션된 모바일 로봇이다. 물리적 상황은 테스트 중인 스택이 효과적으로 응답하도록 요구되는 정적 및/또는 동적 요소(들)를 포함한다. 예를 들어, 모바일 로봇은 스택의 제어 하에 있는 완전 또는 반-자율주행 차량(주체 차량)일 수 있다. 물리적 상황은 시나리오가 진행됨에 따라 유지될 수 있거나 변할 수 있는 정적 도로 배치(static road layout) 및 환경 조건들의 주어진 세트(예컨대, 날씨, 시각, 조명 조건들, 습도, 오염/미립자 레벨, 등)를 포함할 수 있다. 상호작용적 시나리오(interactive scenario)는 추가적으로 하나 이상의 다른 에이전트들("외부" 에이전트(들), 예컨대, 다른 차량들, 보행자들, 자전거를 타는 사람들, 동물들, 등)을 포함한다

다음의 예들은 자율주행 차량 테스트에 대한 적용들을 고려한다. 하지만, 원리들은 모바일 로봇의 다른 형태들에 동등하게 적용된다.

시나리오들은 추상화(abstraction)의 상이한 레벨들에서 표현될 수 있거나 정의될 수 있다. 더 추상화된 시나리오들은 더 큰 변화도(degree of variation)를 수용한다. 예를 들어, "끼어들기 시나리오(cut-in scenario)" 또는 "차선 변경 시나리오(lane change scenario)"는 많은 변화들(예컨대, 상이한 에이전트 시작 위치들 및 속력들, 도로 배치, 환경 조건들, 등)을 수용하는 (관심 있는 운행 또는 행태에 의해 특징지어지는) 크게 추상화된 시나리오들의 예들이다. "시나리오 실행(scenario run)"은, 선택에 따라서는 하나 이상의 다른 에이전트들의 존재 하에서, 물리적 상황을 항행하는 에이전트(들)의 구체적인 발생을 지칭한다. 예를 들어, 상이한 에이전트 파라미터(agent parameter)들(예컨대, 시작 위치, 속력, 등), 상이한 도로 배치들, 상이한 환경 조건들, 그리고/또는 상이한 스택 구성들, 등으로, 끼어들기 또는 차선 변경 시나리오의 복수의 실행들이 (실-세계에서 그리고/또는 시뮬레이터(simulator)에서) 수행될 수 있다. 용어들 "실행(run)" 및 "인스턴스(instance)"는 이러한 맥락에서 상호교환가능하게 사용된다.

다음의 예들에서, 스택의 성능은, 적어도 부분적으로, 하나 이상의 실행들의 과정에 걸쳐, 성능 평가 규칙들의 주어진 세트에 대비하여 테스트 오라클에서 주체 에이전트의 행태를 평가함으로써, 평가된다. 테스트의 목적을 위해 권위있는 것(authoritative)으로서 취해지는 (주체 에이전트의 행태를 포함하는) 시나리오 실행의 적절한 표현을 일반적으로 간단히 의미하는 시나리오(또는 각각의 시나리오) 실행의 "실측 자료"에 규칙들이 적용된다. 실측 자료는 시뮬레이션에 내재되고, 시뮬레이터는, 정의에 의해, 시뮬레이션된 시나리오 실행의 완벽한 권위있는 표현인 시나리오 상태들의 시퀀스를 컴퓨팅한다. 실-세계 시나리오 실행에서, 시나리오 실행의 "완변한(perfect)" 표현은 동일한 의미로 존재하지 않는데, 그럼에도 불구하고, 적절하게 유익한 실측 자료가 수많은 방식들로 획득될 수 있는데, 예를 들어, 온-보드 센서 데이터(on-board sensor data)의 수동 주석(manual annotation), (예컨대, 오프라인/비-실제 시간 프로세싱(offline/non-real time processing)을 사용하는) 이러한 데이터의 자동화된/반-자동화된 주석, 그리고/또는 (외부 센서들, 지도(map)들, 등과 같은) 외부 정보 소스(external information source)들, 등을 사용하는 것에 근거하여 획득될 수 있다.

시나리오 실측 자료는 전형적으로 적용가능한 것으로서 주체 에이전트 및 임의의 다른 (두드러진) 에이전트(들)의 "트레이스(trace)"를 포함한다. 트레이스는 시나리오의 과정에 걸쳐 에이전트의 위치 및 모션(motion)의 이력(history)이다. 트레이스가 표현될 수 있는 많은 방식들이 존재한다. 트레이스 데이터는 전형적으로 환경 내의 에이전트의 공간 및 모션 데이터를 포함할 것이다. 용어는 (실-세계 트레이스들을 갖는) 실제 시나리오들 및 (시뮬레이션된 트레이스들을 갖는) 시뮬레이션된 시나리오들 양쪽 모두와 관련되어 사용된다. 트레이스는 전형적으로 시나리오에서 에이전트에 의해 실현되는 실제 궤적을 기록(record)한다. 용어에 관해서, "트레이스" 및 "궤적"은 동일한 또는 유사한 타입들의 정보(예컨대, 시간 경과에 따른 일련의 공간 및 모션 상태들)를 포함할 수 있다. 용어 "궤적"은 일반적으로 계획의 상황에서 선호되고(그리고 미래/예측된 궤적들을 나타낼 수 있고), 반면 용어 "트레이스"는 일반적으로 테스트/평가의 상황에서 과거 행태와 관련하여 선호된다.

시뮬레이션 상황에서, "시나리오 설명(scenario description)"이 입력으로 시뮬레이터에 제공된다. 예를 들어, 시나리오 설명은 시나리오 설명 언어(Scenario Description Language, SDL)를 사용하여 인코딩될 수 있고, 또는 시뮬레이터에 의해 소비될 수 있는 임의의 다른 형태로 인코딩될 수 있다. 시나리오 설명은 전형적으로 복수의 시뮬레이션된 실행들을 일으킬 수 있는 시나리오의 더 추상적인 표현이다. 구현예에 따라, 시나리오 설명은 가능한 변화도를 증가시키기 위해 변경될 수 있는 하나 이상의 구성가능한 파라미터들을 가질 수 있다. 추상화 및 파라미터화의 정도는 설계 선택이다. 예를 들어, 시나리오 설명은 고정된 배치를 (날씨, 조명, 등과 같은) 파라미터화된 환경 조건들로 인코딩할 수 있다. 하지만, 예를 들어, (도로 곡률, 차선 구성, 등과 같은) 구성가능한 도로 파라미터(들)로 추가 추상화가 가능하다. 시뮬레이터에 대한 입력은 (적용가능한 것으로서) 파라미터 값(들)의 선택된 세트와 함께 시나리오 설명을 포함한다. 후자는 시나리오의 파라미터화로서 지칭될 수 있다. 구성가능한 파라미터(들)는 파라미터 공간(이것은 또한 시나리오 공간으로서 지칭됨)을 정의하고, 그리고 파라미터화는 파라미터 공간 내의 지점(point)에 대응한다. 이러한 맥락에서, "시나리오 인스턴스"는 시나리오 설명 및 (적용가능하다면) 선택된 파라미터화에 근거하는 시뮬레이터에서의 시나리오의 인스턴스화(instantiation)를 지칭할 수 있다.

간결함을 위해, 용어 "시나리오"는 또한 시나리오 실행을 지칭하기 위해 사용될 수 있고, 또한 더 추상화된 의미에서 시나리오를 지칭하기 위해 사용될 수 있다. 용어 "시나리오"의 의미는 사용되는 상황으로부터 명백할 것이다.

궤적 계획은 현재 상황에서 중요한 기능이고, 그리고 용어들 "궤적 계획기", "궤적 계획 시스템", 및 "궤적 계획 스택"은 미래에 대한 모바일 로봇에 대한 궤적들을 계획할 수 있는 컴포넌트 또는 컴포넌트들을 지칭하기 위해 본 명세서에서 상호교환가능하게 사용될 수 있다. 궤적 계획 결정들은 궁극적으로 주체 에이전트에 의해 실현되는 실제 궤적을 결정한다(하지만, 일부 테스트 상황들에서, 이것은 다른 인자들에 의해 영향을 받을 수 있는데, 제어 스택에서의 이러한 결정들의 구현, 그리고 결과적인 제어 신호들에 대한 주체 에이전트의 실제 혹은 모델링된 동적 응답과 같은 것에 의해 영향을 받을 수 있음).

궤적 계획기는 별개로 테스트될 수 있거나, 또는 하나 이상의 다른 시스템들(예컨대, 지각, 예측, 및/또는 제어)과 결합되어 테스트될 수 있다. 전체 스택 내에서, 계획은 일반적으로 더 높은-레벨 자율주행 결정-수행 능력을 지칭하고(예컨대, 궤적 계획), 반면 제어는 일반적으로 이러한 자율주행 결정들을 수행하기 위한 제어 신호들의 더 낮은-레벨 발생을 지칭한다. 하지만, 성능 테스트의 상황에서, 용어 "제어"는 또한 더 넓은 의미로 사용된다. 불확실함을 피하기 위해, 궤적 계획기가 시뮬레이션에서 주체 에이전트를 제어하는 것으로 말해질 때, 이것은 (더 좁은 의미에서의) 제어 시스템이 궤적 계획기와 결합되어 테스트됨을 반드시 의미하는 것이 아니다.

예시적 AV 스택(Example AV stack)

설명되는 실시예들에 대한 관련 상황을 제공하기 위해, AV 스택의 예시적 형태의 추가 세부사항들이 이제 설명될 것이다.

도 1a는 AV 실행시간 스택(AV runtime stack)(100)의 매우 개략적인 블록도를 보여준다. 실행 시간 스택(100)은 지각 (서브-)시스템(102), 예측 (서브-)시스템(104), 계획 (서브-)시스템(계획기)(106) 및 제어 (서브-)시스템(제어기)(108)을 포함하도록 보여진다. 언급된 바와 같이, 앞에서 언급된 컴포넌트들(102 내지 108)을 설명하기 위해 용어 "(서브-)스택"이 또한 사용될 수 있다.

실-세계 상황에서, 지각 시스템(102)은, AV의 온-보드 센서 시스템(on-board sensor system)(110)으로부터 센서 출력들을 수신하고, 그리고 이러한 센서 출력들을 사용하여 외부 에이전트들을 검출하며 이들의 물리적 상태, 예컨대, 이들의 위치, 속도, 가속도, 등을 측정한다. 온-보드 센서 시스템(110)은 상이한 형태들을 취할 수 있지만 일반적으로 다양한 센서들을 포함하는데, 예컨대, 이미지 캡처 디바이스(image capture device)들(카메라들/광학 센서들), 라이다(lidar) 및/또는 레이다(radar) 유닛(unit)(들), 위성-위치결정 센서(들)(GPS, 등), 모션/관성 센서(motion/inertial sensor)(들)(가속도계들, 자이로스코프들, 등), 등과 같은 것을 포함한다. 따라서, 온-보드 센서 시스템(110)은 풍부한 센서 데이터를 제공하고, 이러한 센서 데이터부터 주변 환경 및 해당 환경 내에서의 AV 및 임의의 외부 행위자들(차량들, 보행자들, 자전거를 타는 사람들, 등)의 상태에 대한 상세한 정보를 추출하는 것이 가능하다. 센서 출력들은 전형적으로 하나 이상의 입체 광학 센서(stereo optical sensor)들, 라이다, 레이다, 등으로부터의 입체 이미지(stereo image)들과 같은 복수의 센서 양식들(sensor modalities)의 센서 데이터를 포함한다. 복수의 센서 양식들의 센서 데이터는 필터(filter)들, 융합 컴포넌트(fusion component)들, 등을 사용하여 결합될 수 있다.

지각 시스템(102)은 전형적으로 복수의 지각 컴포넌트(perception component)들을 포함하고, 이러한 지각 컴포넌트들은 센서 출력들을 해석하여 지각 출력들을 예측 시스템(104)에 제공하기 위해 함께-동작한다.

시뮬레이션 상황에서, 테스트의 성질에 따라(그리고 특히, 테스트의 목적을 위해 스택(100)이 어디서 "슬라이싱(slice)"되는지에 따라(아래 참조)), 온-보드 센서 시스템(100)을 모델링하는 것이 필요할 수 있거나 필요하지 않을 수 있다. 더 높은-레벨 슬라이싱의 경우, 시뮬레이션된 센서 데이터는 요구되지 않고, 따라서 복잡한 센서 모델링이 요구되지 않는다.

지각 시스템(102)으로부터의 지각 출력들은 AV 근처의 다른 차량들과 같은 외부 행위자들(에이전트들)의 미래 행태를 예측하기 위해 예측 시스템(104)에 의해 사용된다.

예측 시스템(104)에 의해 컴퓨팅된 예측들은 계획기(106)에게 제공되고, 계획기(106)는 주어진 주행 시나리오에서 AV에 의해 실행될 자율 주행 결정들을 행하기 위해 이러한 예측들을 사용한다. 계획기(106)에 의해 수신된 입력들은 전형적으로 주행가능 영역(drivable area)을 표시하게 되고, 그리고 또한 주행가능 영역 내에서 임의의 외부 에이전트들(AV의 관점으로부터 장애물들)의 예측된 움직임들을 캡처(capture)하게 된다. 주행가능 영역은 HD(High Definition; 고화질) 지도와 같은 지도 정보와 결합되어 지각 시스템(102)으로부터의 지각 출력들을 사용하여 결정될 수 있다.

계획기(106)의 핵심 기능은 예측된 에이전트 모션을 고려하여 AV에 대한 궤적들(주체 궤적들)을 계획하는 것이다. 이것은 궤적 계획으로서 지칭될 수 있다. 시나리오 내에서 원하는 목표를 수행하기 위해 궤적이 계획된다. 목표는 예를 들어, 환상교차로(roundabout)에 진입하고 원하는 출구에서 환상교차로를 떠나는 것, 전방 차량을 추월하는 것, 또는 타겟 속력(target speed)에서 현재 차선에 머무르는 것(차선 준수)일 수 있다. 목표는 예를 들어, 자율주행 노선 계획기(미도시)에 의해 결정될 수 있다.

제어기(108)는 적절한 제어 신호들을 AV의 온-보드 행위자 시스템(112)에게 제공함으로써 계획기(106)에 의해 취해진 결정들을 실행한다. 특히, 계획기(106)는 AV를 위한 궤적들을 계획하고, 그리고 제어기(108)는 이러한 계획된 궤적들을 구현하기 위해 제어 신호들을 발생시킨다. 전형적으로, 계획기(106)는 미래에 대한 계획을 행할 것이고, 이에 따라, 계획된 궤적은 새로운 궤적이 계획기(106)에 의해 계획되기 전에 제어 레벨에서 부분적으로만 구현될 수 있게 된다. 행위자 시스템(112)은, 제동, 가속, 및 조향 시스템들과 같은 "1차(primary)" 차량 시스템들을 포함하고, 뿐만 아니라 2차(secondary) 시스템들(예컨대, 시그널링, 와이퍼들, 헤드라이트들, 등)을 포함한다.

주어진 시각(time instant)에서의 계획된 궤적과 주체 에이전트에 의해 준수되는 실제 궤적 간의 구분이 존재할 수 있음에 유의해야 한다. 계획 시스템들은 전형적으로, 이전의 계획 단계 이후 시나리오에서의 임의의 변경들(또는 더 정확하게는, 예측된 변경들로부터 벗어난 임의의 변경들)을 고려하기 위해 각각의 계획 단계에서, 계획된 궤적을 업데이트(updating)하면서, 계획 단계들의 시퀀스에 걸쳐 동작한다. 계획 시스템(106)은 미래에 대한 추론(reason)을 행할 수 있고, 이에 따라 각각의 계획 단계에서의 계획된 궤적은 다음 계획 단계를 넘어 확장되게 된다. 따라서, 임의의 개개의 계획된 궤적은 완전히 실현되지 않을 수 있다(만약 계획 시스템(106)이 시뮬레이션에서 별개로 테스트된다면, 주체 에이전트는 단순히 다음 계획 단계까지, 계획된 궤적을 정확히 준수할 수 있는데, 하지만, 언급된 바와 같이, 다른 실제 및 시뮬레이션 상황들에서, 계획된 궤적은 다음 계획 단계까지 정확히 준수될 수 없는데, 왜냐하면 주체 에이전트의 행태가 제어 시스템(108)의 동작, 및 주체 차량의 실제 또는 모델링된 역학(dynamics)과 같은 다른 인자들에 의해 영향을 받을 수 있기 때문이다). 많은 테스트 상황들에서, 주체 에이전트의 실제 궤적이 궁극적으로 중요한 것인데, 특히 실제 궤적이 안전한지 여부, 뿐만 아니라 안락 및 진행과 같은 다른 인자들이 중요한 것이다. 하지만, 본 명세서에서의 규칙들-기반 테스트 접근법은 또한, 계획된 궤적들에 적용될 수 있다(비로 이러한 계획된 궤적들이 주체 에이전트에 의해 완전히 혹은 정확히 실현되지 않을지라도 그러함). 예를 들어, 에이전트의 실제 궤적이 안전 규칙들의 주어진 세트에 따라 안전한 것으로 고려되더라도, 순간적인 계획된 궤적이 불안전했을 수 있고, 계획기(106)가 행위의 불안전한 과정을 고려하고 있었다는 사실이, 비록 이것이 시나리오에서 불안전한 에이전트 행태로 이어지지 않았더라도, 들어날 수 있다. 순간적인 계획된 궤적들은, 시뮬레이션에서의 실제 에이전트 행태에 추가하여, 유용하게 평가될 수 있는 내부 상태의 하나의 형태를 구성한다. 내부 스택 상태의 다른 형태들이 유사하게 평가될 수 있다.

도 1a의 예는 분리가능한 지각, 예측, 계획, 및 제어 시스템들(102 내지 108)을 갖는 상대적으로 "모듈식(modular)" 아키텍처(architecture)를 고려한다. 서브-스택 자체도 또한, 예를 들어, 계획 시스템(106) 내에 분리가능한 계획 모듈들을 갖는 모듈식일 수 있다. 예를 들어, 계획 시스템(106)은 상이한 물리적 상황들(예컨대, 단순한 차선 주행 대 복잡합 교차로들 혹은 환상교차로들)에서 적용될 수 있는 복수의 궤적 계획 모듈들을 포함할 수 있다. 이것은 앞에서 논의된 이유들에 대해 시뮬레이션 테스트와 관련되는데, 왜냐하면 이것은 (계획 시스템(106) 또는 이것의 개개의 계획 모듈들과 같은) 컴포넌트들이 개별적으로 또는 상이한 조합들에서 테스트될 수 있게 하기 때문이다. 불확실함을 피하기 위해, 모듈식 스택 아키텍처(modular stack architecture)들에 있어서, 용어 "스택"은 전체 스택을 지칭할 수 있을 뿐만 아니라 임의의 개개의 서브-시스템 또는 이것의 모듈을 지칭할 수 있다.

다양한 스택 기능들이 통합되거나 분리가능한 정도는 상이한 스택 구현들 간에 크게 변할 수 있는데, 일부 스택들에서, 특정 실시형태들은 구분이 안 될 정도로 밀접하게 결합될 수 있다. 예를 들어, 다른 스택들에서, 계획과 제어는 통합될 수 있고(예컨대, 이러한 스택들은 제어 신호들의 측면에서 직접적으로 계획을 행할 수 있음), 반면 다른 스택들(예컨대, 도 1a에 도시된 것)은 (예컨대, 궤적들의 측면에서 계획을 갖는, 그리고 계획된 궤적을 제어 신호 레벨에서 실행하기에 최선의 방법을 결정하기 위한 별개의 제어 최적화(control optimization)들을 갖는) 둘 간의 명확한 구분을 끌어내는 방식으로 구성될 수 있다. 유사하게, 일부 스택들에서, 예측 및 계획은 더 밀접하게 결합될 수 있다. 극단적으로, 소위 "종단-간(end-to-end)" 주행에서, 지각, 예측, 계획 및 제어는 본질적으로 분리가능하지 않을 수 있다. 달리 표시되지 않는다면, 본 명세서에서 사용되는 지각, 예측, 계획 및 제어 용어는 이러한 실시형태들의 임의의 특정 결합 또는 모듈성(modularity)을 의미하지 않는다.

용어 "스택(stack)"은 소프트웨어를 포함하지만, 하드웨어도 또한 포함할 수 있음이 이해될 것이다. 시뮬레이션에서, 스택의 소프트웨어는, 물리적 차량의 온-보드 컴퓨터 시스템(on-board computer system)에 궁국적으로 업로드(upload)되기 전에 "일반(generic)" 오프-보드 컴퓨터 시스템(off-board computer system) 상에서 테스트될 수 있다. 하지만, "루프-내-하드웨어(hardware-in-the-loop)" 테스트에서, 테스트는 차량 자체의 기반이 되는 하드웨어로 확장될 수 있다. 예를 들어, 스택 소프트웨어는, 테스트의 목적을 위해 시뮬레이터에 결합된 온-보드 컴퓨터 시스템(또는 이것은 복제(replica)) 상에서 실행될 수 있다. 이러한 상황에서, 테스트 중인 스택은 차량의 기반이 되는 컴퓨터 하드웨어로 확장된다. 또 하나의 다른 예로서, 스택(110)의 특정 기능들(예컨대, 지각 기능들)은 전용 하드웨어에서 구현될 수 있다. 시뮬레이션 상황에서, 루프-내-하드웨어 테스트는 합성 센서 데이터(synthetic sensor data)를 전용 하드웨어 지각 컴포넌트들에 공급하는 것을 포함할 수 있다.

도 1b는 자율주행 차량들에 대한 테스트 패러다임의 매우 개략적인 개관을 보여준다. 예를 들어, 도 1a에 도시된 종류의 ADS/ADAS 스택(100)은, 시뮬레이터(202)에서 복수의 시나리오 인스턴스들을 실행함으로써, 그리고 테스트 오라클(252)에서 스택(100)(및/또는 이것의 개개의 서브-스택들)의 성능을 평가함으로써, 시뮬레이션에서의 반복되는 테스트 및 평가에 놓여진다. 테스트 오라클(252)의 출력은 전문가(expert)(122)(팀(team) 또는 개인(individual))에게 유익하고, 이것은 이들로 하여금 스택(100)에서의 문제들을 식별할 수 있게 하고 이러한 문제들을 완화시키기 위해 스택(100)을 수정할 수 있게 한다(S124). 결과들은 또한, 테스트를 위한 추가 시나리오들을 선택함에 있어 전문가(122)를 보조하고(S126), 프로세스는 시뮬레이션에서 스택(100)의 성능을 반복적으로 수정, 테스트, 및 평가하는 것을 계속한다. 개선된 스택(100)은 궁극적으로, 센서 시스템(110) 및 행위자 시스템(112)을 갖춘 실-세계 AV(101)에 통합된다(S125). 개선된 스택(100)은 전형적으로, 차량(101)의 온-보드 컴퓨터 시스템의 하나 이상의 컴퓨터 프로세서들(미도시)에서 실행되는 프로그램 명령들(소프트웨어)을 포함한다. 개선된 스택의 소프트웨어는 단계(S125)에서 AV(101)로 업로드된다. 단계(S125)는 또한 기반이 되는 차량 하드웨어에 대한 수정들을 포함할 수 있다. AV(101) 보드 상에서, 개선된 스택(100)은 센서 시스템(110)으로부터 센서 데이터를 수신하고 제어 신호들을 행위자 시스템(112)에 출력한다. 실-세계 테스트(S128)는 시뮬레이션-기반 테스트와 결합되어 사용될 수 있다. 예를 들어, 시뮬레이션 테스트 및 스택 정제(stack refinement)를 통해 성능의 허용가능한 레벨에 도달하면, 적절한 실-세계 시나리오들이 선택될 수 있고(S130), 그리고 그러한 실제 시나리오들에서의 AV(101)의 성능이 테스트 오라클(252)에서 캡처될 수 있고 유사하게 평가될 수 있다.

시나리오들이 다양한 방식들로 시뮬레이션의 목적을 위해 획득될 수 있고, 여기에는 수동 인코딩(manual encoding)이 포함된다. 시뮬레이션은 또한, 실-세계 실행들로부터 시뮬레이션의 목적을 위한 시나리오들을 추출할 수 있고, 이것은 실-세계 상황들 및 이들의 변형들이 시뮬레이터(202)에서 재-생성될 수 있게 한다.

도 1c는 시나리오 추출 파이프라인의 매우 개략적인 블록도를 보여준다. 실-세계 실행의 데이터(140)가 시나리오 실측 자료를 발생시킬 목적을 위해 '실측 자료화(ground-truthing)' 파이프라인(142)에 전달된다. 실행 데이터(140)는 예를 들어, (자율주행을 행할 수 있거나, 인간에 의해 주행될 수 있거나, 또는 이들의 조합일 수 있는) 하나 이상의 차량들 보드 상에서 캡처된/발생된 센서 데이터 및/또는 지각 출력들, 그리고/또는 외부 센서들(CCTV, 등)과 같은 다른 소스들로부터 캡처된 데이터를 포함할 수 있다. 실행 데이터는, 실-세계 실행에 대한 적절한 실측 자료(144)(트레이스(들) 및 상황 데이터)를 발생시키기 위해 실측 자료화 파이프라인(142) 내에서 프로세싱된다. 논의된 바와 같이, 실측-자료화 프로세스는 '원시(raw)' 실행 데이터(142)의 수동 주석에 근거할 수 있거나, 또는 이러한 프로세스는 (예컨대, 오프라인 지각 방법(들)을 사용하여) 전체적으로 자동화될 수 있거나, 또는 수동 및 자동화된 실측 자료화의 조합이 사용될 수 있다. 예를 들어, 실행 데이터(140)에서 캡처된 차량들 및/또는 다른 에이전트들 주위에, 이들의 트레이스들의 공간 및 모션 상태들을 결정하기 위해, 3D 바운딩 박스(3D bounding box)들이 놓여질 수 있다. 시나리오 추출 컴포넌트(146)는 시나리오 실측 자료(144)를 수신하고, 그리고 시뮬레이션의 목적을 위해 사용될 수 있는 더 추상화된 시나리오 설명(148)을 추출하기 위해 시나리오 실측 자료(144)를 프로세싱한다. 시나리오 설명(148)은 시뮬레이터(202)에 의해 소비되고, 이것은 복수의 시뮬레이션된 실행들이 수행될 수 있게 한다. 시뮬레이션된 실행들은 본래 실-세계 실행(original real-world run)의 변형들이고, 가능한 변형도는 추상화의 정도에 의해 결정된다. 각각의 시뮬레이션된 실행에 대한 실측 자료(150)가 제공된다.

테스트 파이프라인(Testing pipeline)

테스트 파이프라인 및 테스트 오라클(252)의 추가 세부사항들이 이제 설명될 것이다. 다음과 같은 예들은 시뮬레이션-기반 테스트에 초점을 맞추고 있다. 하지만, 언급된 바와 같이, 테스트 오라클(252)은 실제 시나리오들 상에서 스택 수행을 평가하기 위해 동등하게 적용될 수 있고, 그리고 아래의 관련 설명은 실제 시나리오들에 동등하게 적용된다. 다음의 설명은 도 1a의 스택(100)을 예로서 참조한다. 하지만, 언급된 바와 같이, 테스트 파이프라인(200)은 매우 유연하고, 그리고 자율성의 임의의 레벨에서 동작하는 임의의 스택 또는 서브-스택에 적용될 수 있다.

도 2는 테스트 파이프라인의 개략적인 블록도를 보여주고, 이것은 참조 번호 200으로 표시되어 있다. 테스트 파이프라인(200)은 시뮬레이터(202) 및 테스트 오라클(252)을 포함하도록 보여진다. 시뮬레이터(202)는 AV 실행 시간 스택(100)의 일부 혹은 모두를 테스트할 목적을 위해, 시뮬레이션된 시나리오들을 실행하고, 그리고 테스트 오라클(252)은 시뮬레이션된 시나리오들 상에서 스택(또는 서브-스택)의 성능을 평가한다. 논의되는 바와 같이, 실행-시간 스택의 서브-스택만이 테스트되는 것일 수 있지만, 간략함을 위해, 다음의 설명은 (전체) AV 스택(100)을 전체적으로 참조한다. 하지만, 이러한 설명은 전체 스택(100) 대신에 서브-스택에 동등하게 적용된다. 용어 "슬라이싱(slicing)"은 테스트를 위한 스택 컴포넌트들의 세트 혹은 서브세트의 선택에 대해 본 명세서에서 사용된다.

이전에 설명된 바와 같이, 시뮬레이션-기반 테스트의 발상(idea)은 테스트되는 스택(100)의 제어 하에서 주체 에이전트가 항행해야만하는 시뮬레이션된 주행 시나리오를 실행히는 것이다. 전형적으로, 시나리오는, 주체 에이전트가, 전형적으로는 하나 이상의 다른 동적 에이전트들(예컨대, 다른 차량들, 자전거들, 보행자들, 등)의 존해 하에서 항행하도록 요구되는 정적 주행가능 영역(예컨대, 특정 정적 도로 배치)을 포함한다. 이를 위해, 시뮬레이션된 입력들(203)이 시뮬레이터(202)로부터 테스트 중인 스택(100)에 제공된다.

스택의 슬라이싱은 시뮬레이션된 입력들(203)의 형태를 나타낸다. 예를 들어, 도 2는 테스트되는 AV 스택(100) 내에서 예측, 계획, 및 제어 시스템들(104, 106 및 108)을 보여준다. 도 1a의 전체 AV 스택을 테스트하기 위해, 테스트 동안 지각 시스템(102)이 또한 적용될 수 있다. 이러한 경우에, 시뮬레이션된 입력들(203)은, 실제 센서 데이터와 동일한 방식으로 지각 시스템(102) 내에서 프로세싱되는 그리고 적절한 센서 모델(들)을 사용하여 발생되는 합성 센서 데이터를 포함하게 된다. 이것은 충분히 현실적인 합성 센서 입력들(예컨대, 실사 이미지 데이터(photorealistic image data) 및/또는 동등하게 현실적인 시뮬레이션된 라이다/레이다 데이터, 등)의 발생을 요구한다. 지각 시스템(102)의 결과적인 출력들은, 그 다음에, 더 높은-레벨 예측 및 계획 시스템들(104, 106)에 공급되게 된다.

대조적으로, 소위 "게획-레벨(planning-level)" 시뮬레이션은 본질적으로 지각 시스템(102)을 우회(bypass)하게 된다. 시뮬레이터(202)는 대신에, 더 간단한, 더 높은-레벨 입력들(203)을 예측 시스템(104)에 직접적으로 제공하게 된다. 일부 상황들에서, 시뮬레이션된 시나리오로부터 직접적으로 획득된 예측들(즉, "완벽한" 예측들) 상에서 계획기(106)를 테스트하기 위해서, 예측 시스템(104)을 또한 우회하는 것이 심지어 적절할 수도 있다.

이러한 극단들 사이에는, 예를 들어, "더 늦은(later)"(더 높은-레벨) 지각 컴포넌트들, 예컨대, 더 낮은-레벨 지각 컴포넌트들(예컨대, 객체 검출기(object detector)들, 바운딩 박스 검출기들, 모션 검출기들, 등)로부터의 출력들에 관해 동작하는 필터들 또는 융합 컴포넌트들과 같은 그러한 컴포넌트들과 같은, 지각 시스템(102)의 서브세트만을 테스트하는, 입력 슬라이싱의 많은 상이한 레벨들에 대한 범위(scope)가 존재한다.

이들이 어떤 형태를 취하든, 시뮬레이션되는 입력들(203)은 계획기(106)에 의한 결정-수행을 위한 기반으로서 (직접적으로 또는 간접적으로) 사용된다. 그 다음에, 제어기(108)는 제어 신호들(109)을 출력함으로써 계획기의 결정들을 구현한다. 실-세계 상황에서, 이러한 제어 신호들은 AV의 물리적 행위자 시스템(112)을 구동시키게 된다. 시뮬레이션에서, 주체 차량 역학 모델(ego vehicle dynamics model)(204)은, 결과적인 제어 신호들(109)을 시뮬레이션 내의 주체 에이전트의 현실적인 모션으로 변환(translate)하기 위해 사용된다(그럼으로써 제어 신호들(109)에 대한 자율주행 차량의 물리적 응답을 시뮬레이션하게 됨).

대안적으로, 시뮬레이션의 더 간단한 형태는 주체 에이전트가 계획 단계들 사이에 각각의 계획된 궤적을 정확히 준수한다고 가정한다. 이러하 접근법은 (계획으로부터 분리가능한 범위까지) 제어 시스템(108)을 우회하고, 그리고 주체 차량 동적 모델(204)에 대한 필요성을 제거한다. 이것은 계획의 특정 양상들을 테스트하기 위해 충분할 수 있다.

외부 에이전트들이 시뮬레이터(202) 내에서 자율주행 행태/결정 수행을 나타내는 한, 에이전트 결정 로직(agent decision logic)(210)의 일부 형태는 이러한 결정들을 수행하도록 그리고 시나리오 내에서 에이전트 행태를 결정하도록 구현된다. 에이전트 결정 로직(210)은 복잡도(complexity)에 있어 주체 스택(ego stack)(100) 자체에 필적할 수 있거나, 또는 더 제한된 결정-수행 능력을 가질 수 있다. 목표는 주체 스택(100)의 결정-수행 능력들을 유용하게 테스트할 수 있도록 시뮬레이터(202) 내에 충분히 현실적인 외부 에이전트 행태를 제공하는 것이다. 일부 상황들에서, 이것은 임의의 에이전트 결정 수행 로직(210)을 전혀 요구하지 않으며(개방-루프 시뮬레이션(open-loop simulation)), 그리고 다른 상황들에서, 유용한 테스트는 기본적인 적응형 순항 제어(Adaptive Cruise Control, ACC)와 같은 상대적으로 제한된 에이전트 로직(210)을 사용하여 제공될 수 있다. 하나 이상의 에이전트 역학 모델(agent dynamics model)들(206)은, 만약 적용가능하다면, 더 현실적인 에이전트 행태를 제공하기 위해 사용될 수 있다.

시나리오는 시나리오 설명(201a) 및 (만약 적용가능하다면) 시나리오의 선택된 파라미터화(201b)에 따라 실행된다. 시나리오는 전형적으로 정적 및 동적 요소들 양쪽 모두를 가지며, 이들은 시나리오 설명(201a)에 "하드 코딩(hard code)"될 수 있거나 구성가능할 수 있고, 따라서, 선택된 파라미터화(201b)와 결합되어 시나리오 설명(201a)에 의해 결정될 수 있다. 주행 시나리오에서, 정적 요소(들)는 전형적으로 정적 도로 배치를 포함한다.

동적 요소(들)는 전형적으로, 다른 차량들, 보행자들, 자전거들, 등과 같은, 시나리오 내의 하나 이상의 외부 에이전트들을 포함한다.

각각의 외부 에이전트에 대해 시뮬레이터(202)에게 제공되는 동적 정보의 범위는 다양할 수 있다. 예를 들어, 시나리오는 분리가능한 정적 및 동적 계층들에 의해 설명될 수 있다. (예컨대, 도로 배치를 정의하는) 주어진 정적 계층은 상이한 시나리오 인스턴스들을 제공하기 위해 상이한 동적 게층들과 결합되어 사용될 수 있다. 동적 계층은, 각각의 외부 에이전트에 대해, 공간적 경로(spatial path)를 포함할 수 있는데, 그 경로와 관련된 행태 데이터 및 모션 데이터 중 하나 또는 양쪽 모두와 함께 에이전트에 의해 준수될 그러한 공간적 경로를 포함할 수 있다. 간단한 개방-루프 시뮬레이션(open-loop simulation)에서, 외부 행위자는 비-반응성인, 즉 시뮬레이션 내에서 주체 에이전트에 반응하지 않는, 동적 계층에서 정의된 공간적 경로 및 모션 데이터를 단순히 준수한다. 이러한 개방-루프 시뮬레이션은 임의의 에이전트 결정 로직(210) 없이 구현될 수 있다. 하지만, 폐-루프 시뮬레이션(closed-loop simulation)에서, 동적 계층은 대신에 (ACC 행태와 같은) 정적 경로를 따라 준수될 적어도 하나의 행태를 정의한다. 이러한 경우에, 에이전트 결정 로직(210)은 반응하는 방식으로, 즉 주체 에이전트 및/또는 다른 외부 에이전트(들)에 반응하여, 시뮬레이션 내에 해당 행태를 구현한다. 모션 데이터는 정적 경로와 여전히 관련될 수 있지만, 이러한 경우에 덜 규정적(prescriptive)이고, 그리고 예를 들어, 경로를 따라 타겟으로서의 역할을 할 수 있다. 예를 들어, ACC 행태에 있어서, 타겟 속력들은 에이전트가 일치시키려고 추구할 경로를 따라 설정될 수 있지만, 에이전트 결정 로직(210)은 전방 차량으로부터 타겟 차머리(target headway)를 유지하기 위해서 경로를 따라 임의의 지점에서 타겟 아래로 외부 에이전트의 속력을 감소시키도록 허용될 수 있다.

이해될 것인 바와 같이, 시나리오들은 임의의 구성가능도(degree of configurability)로, 많은 방식들로 시뮬레이션의 목적을 위해 설명될 수 있다. 예를 들어, 에이전트들의 수 및 타입, 그리고 이들의 모션 정보는 시나리오 파라미터화(201b)의 일부로서 구성가능할 수 있다.

주어진 시뮬레이션에 대한 시뮬레이터(202)의 출력은, 주체 에이전트의 주체 트레이스(ego trace)(212a) 및 하나 이상의 외부 에이전트들의 하나 이상의 에이전트 트레이스(agent trace)들(212b)(트레이스들(212))을 포함한다. 각각의 트레이스(212a, 212b)는, 공간적 및 모션 컴포넌트들 양쪽 모두를 갖는, 시뮬레이션 내에서 에이전트의 행태의 전체 이력(history)이다. 예를 들어, 각각의 트레이스(212a, 212b)는, 속력, 가속도, 저크(jerk)(가속도의 변화율), 스냅(snap)(저크의 변화율), 등과 같은, 경로를 따라 지점들과 관련된 모션 데이터를 갖는 공간적 경로의 형태를 취할 수 있다.

상황을 보완(supplement)하고 트레이스들(212)에 제공하기 위해 추가적인 정보가 또한 제공된다. 이러한 추가적인 정보는 "상황(contextual)" 데이터(214)로서 지칭된다. 상황 데이터(214)는, 시나리오의 물리적 상황과 관련되고, 그리고 정적 컴포넌트들(예컨대, 도로 배치) 및 동적 컴포넌트들(예컨대, 시뮬레이션의 과정에 걸쳐 변하는 정도에서 날씨 조건들) 양쪽 모두를 가질 수 있다. 어느 정도까지, 상황 데이터(214)는, 시나리오 설명(201a) 또는 파라미터화(201b)의 선택에 의해 직접적으로 정의되고, 따라서 시뮬레이션의 결과에 의해 영향을 받지 않는다는 점에서, "통과(passthrough)"일 수 있다. 예를 들어, 상황 데이터(214)는 시나리오 설명(201a) 또는 파라미터화(201b)로부터 직접적으로 나오는 정적 도로 배치를 포함할 수 있다. 하지만, 전형적으로 상황 데이터(214)는 시뮬레이터(202) 내에서 도출되는 적어도 일부 요소들을 포함하게 된다. 이것은 예를 들어, 날씨 데이터와 같은 시뮬레이션된 환경 데이터를 포함할 수 있는데, 여기서 시뮬레이터(202)는 시뮬레이션이 진행됨에 따라 날씨 조건들을 자유롭게 변경한다. 그러한 경우에, 날씨 데이터는 시간-종속성(time-dependent)일 수 있고, 그러한 시간 종속성은 상황 데이터(214)에서 반영될 것이다.

테스트 오라클(252)은 트레이스들(212) 및 상황 데이터(214)를 수신하고, 그리고 성능 평가 규칙들(254)의 세트와 관련하여 이러한 출력들을 점수화한다. 성능 평가 규칙들(254)은 테스트 오라클(252)에 대한 입력으로 제공되도록 보여진다.

규칙들은 성질에 있어 범주적(categorical)이다(예컨대, 통과/실패-타입 규칙들). 특정 성능 평가 규칙들은 또한, 궤적들을 "점수화(score)"하기 위해 사용되는(예를 들어, 범주적 결과들을 설명하는 것을 돕는 또는 그렇지 않으면 범주적 결과들과 관련된 성공 또는 실패의 정도 혹은 어떤 다른 양을 표시하는) 수치적 성능 메트릭(numerical performance metric)들과 관련된다. 규칙들의(254)의 평가는 시간-기반인데, 주어진 규칙은 시나리오에서 상이한 지점들에서 상이한 결과를 가질 수 있다. 점수화는 또한 시간-기반(time-based)이고, 각각의 성능 평가 메트릭(performance evaluation metric)에 대해, 테스트 오라클(252)은 시뮬레이션이 진행됨에 따라 해당 메트릭의 값(점수)이 시간 경과에 따라 어떻게 변하는 지를 추적한다. 테스트 오라클(252)은, 이후 더 상세히 설명되는 바와 같이, 각각의 규칙에 대한 범주적(예컨대, 통과/실패) 결과들의 시간 시퀀스(256a), 및 각각의 성능 메트릭에 대해 점수-시간 플롯(score-time plot)(256b)을 포함하는 출력(256)을 제공한다. 결과들 및 점수들(256a, 256b)은 전문가(122)에게 유익하고, 그리고 테스트되는 스택(100) 내에서 성능 문제들을 식별하고 완화시키기 위해 사용될 수 있다. 테스트 오라클(252)은 또한 시나리오에 대한 전체(집계) 결과(예컨대, 전체 통과/실패)를 제공한다. 테스트 오라클(252)의 출력(256)은 출력(256)과 관련된 시나리오에 대한 정보와 관련지어 테스트 데이터베이스(258)에 저장된다. 예를 들어, 출력(256)은 시나리오 설명(210a)(또는 이것의 식별자) 및 선택된 파라미터화(201b)와 관련지어 저장될 수 있다. 시간-종속성 결과들 및 점수들 뿐만 아니라, 전체 점수가 또한 시나리오에 할당될 수 있고 출력(256)의 일부로서 저장될 수 있다(예를 들어, 각각의 규칙에 대한 집계 점수(예컨대, 전체 통과/실패) 및/또는 모든 규칙들(254)에 걸친 집계 결과(예컨대, 통과/실패)).

도 2a는 슬라이싱의 또 하나의 다른 선택을 예시하고, 그리고 전체 스택 및 서브-스택을 각각 표시하기 위해 참조 번호들 100 및 100S를 사용한다. 도 2의 테스트 파이프라인(200) 내에서 테스트 하에 놓이게 되는 것은 서브-스택(100S)이다.

다수의 "더 늦은(later)" 지각 컴포넌트들(102B)은 테스트될 서브-스택(100S)의 일부를 형성하고, 그리고 테스트 동안, 시뮬레이션된 지각 입력들(203)에 적용된다. 더 늦은 지각 컴포넌트들(102B)은 예를 들어, 복수의 더 이른 지각 컴포넌트들로부터의 지각 입력들을 융합하는 필터링 또는 다른 융합 컴포넌트들을 포함할 수 있다.

전체 스택(100)에서, 더 늦은 지각 컴포넌트들(102B)은 더 이른 지각 컴포넌트들(102A)로부터 실제 지각 입력들(213)을 수신하게 된다. 예를 들어, 더 이른 지각 컴포넌트들(102A)은 하나 이상의 2D 또는 3D 바운딩 박스 검출기들을 포함할 수 있고, 이러한 경우에, 늦은 지각 컴포넌트들에 제공된 시뮬레이션된 지각 입력들은 광선 추적(ray tracing)을 통해 시뮬레이션에서 도출되는 시뮬레이션된 2D 또는 3D 바운딩 박스 검출들을 포함할 수 있다. 더 이른 지각 컴포넌트들(102A)은 일반적으로, 센서 데이터에 관해 직접적으로 동작하는 컴포넌트(들)를 포함하게 된다. 도 2a의 슬라이싱에 있어서, 시뮬레이션된 지각 입력들(203)은, 형태에 있어, 더 이른 지각 컴포넌트들(102A)에 의해 정상적으로 제공되게 되는 실제 지각 입력들(213)에 대응하게 된다. 하지만, 더 이른 지각 컴포넌트들(102A)은 테스트의 일부로서 적용되는 것이 아니라, 대신, 하나 이상의 지각 에러 모델들(208)을 훈련시키기 위해 사용되는데, 이러한 지각 에러 모델들(208)은 통계적으로 엄격한 방식으로 현실적인 에러를 시뮬레이션된 지각 입력들(203)에 도입하기 위해 사용될 수 있으며, 시뮬레이션된 지각 입력들(203)은 테스트 중인 서브-스택(100)의 더 늦은 지각 컴포넌트들(102B)에 공급된다.

이러한 지각 에러 모델들은 지각 통계적 성능 모델(Perception Statistical Performance Model, PSPM)들로서 지칭될 수 있고, 또는 동의어로 "PRISM들"로서 지칭될 수 있다. PSPM들의 원리들의 추가 세부사항들, 그리고 이들을 구축하고 훈련시키기 위한 적절한 기법들은 국제 특허 공개 번호들 WO2021037763, WO2021037760, WO2021037765, WO2021037761, 및 WO2021037766에서 결속될 수 있으며, 이들 각각은 그 전체가 참조로 본 명세서에 통합된다. PSPM들 뒤에 있는 발상은 서브-스택(100S)에 제공되는 시뮬레이션된 지각 입력들에 현실적인 에러들을 효율적으로 도입하는 것이다(즉, 더 이른 지각 컴포넌트들(102A)이었다면 실-세계에서 적용될 것으로 예상되게 되는 에러들의 종류가 반영됨). 시뮬레이션 상황에서, "완벽한(perfect)" 실측 자료 지각 입력들(203G)이 시뮬레이터에 의해 제공되는데, 하지만 이들은 지각 에러 모델(들)(208)에 의해 도입된 현실적인 에러로 더 현실적인 지각 입력들(203)을 도출하기 위해 사용된다.

앞에서 언급된 참조물에서 설명되는 바와 같이, PSPM은 물리적 조건(들)을 나타내는 하나 이상의 변수들("교란기(confounder)들")에 종속될 수 있고, 이것은 상이한 가능한 실-세계 조건들을 반영하는 에러의 상이한 레벨들이 도입될 수 있게 한다. 따라서, 시뮬레이터(202)는 날씨 교란기(들)의 값을 간단히 변경함으로써(이것은 또한 지각 에러가 어떻게 도입되는지를 변경시킬 것임) 상이한 물리적 조건들(예컨대, 상이한 날씨 조건들)을 시뮬레이션할 수 있다.

서브-스택(100S) 내의 더 늦은 지각 컴포넌트들(102b)은, 이들이 전체 스택(100) 내에서 실-세계 지각 입력들(213)을 프로세싱하게 되는 것과 정확히 동일한 방식으로, 시뮬레이션된 지각 입력들(203)을 프로세싱하고, 그리고 이들의 출력들은 차레로 예측, 계획, 및 제어를 구동시킨다.

대안적으로, 늦은 지각 컴포넌트들(208)를 포함하는 전체 지각 시스템(102)을 모델링하기 위해 PRISM들이 사용될 수 있고, 이러한 경우에 PSPM(들)은 예측 시스템(104)에 입력들로서 직접적으로 전달되는 현실적인 지각 출력을 발생시키기 위해 사용된다.

구현예에 따라, 주어진 시나리오 파라미터화(201b)와 스택(100)의 주어진 구성에 대한 시뮬레이션의 출력 간에 결정론적 관계(deterministic relationship)가 존재할 수 있거나 존재하지 않을 수 있다(득, 동일한 파라미터화가 동일한 스택(100)에 대해 동일한 결과로 항상 이어질 수 있거나 이어지지 않을 수 있음). 비-결정론(non-determinism)이 다양한 방식들로 일어날 수 있다. 예를 들어, 시뮬레이션이 PRISM들에 근거하는 경우, PRISM은 시나리오의 각각의 주어진 시간 단계에서, 가능한 지각 출력들에 관한 분포(distribution)를 모델링할 수 있는데, 이로부터 현실적인 지각 출력이 확률적으로 샘플링(sample)된다. 이것은 시뮬레이터(202) 내에서 비-결정론적 행태로 이어지고, 그럼으로써 동일한 스택(100) 및 시나리오 파라미터화에 대해 상이한 결과들이 획득될 수 있는데, 왜냐하면 상이한 지각 출력들이 샘플링되기 때문이다. 대안적으로, 또는 추가적으로, 시뮬레이터(202)는 내재적으로 비-결정론적일 수 있는데, 예를 들어, 날씨, 조명, 또는 다른 환경 조건들이 어느 정도까지 시뮬레이터(202) 내에서 무작위화(randomize)될 수 있고/확률적일 수 있다. 이해될 것인 바와 같이, 이것은 설계 선택인데, 다른 구현들에서는 대신에, 다양한 환경 조건들이 시나리오의 파라미터화(201b)에서 완전히 특정될 수 있다. 비-결정론적 시뮬레이션에 있어서, 각각의 파라미터화에 대해 복수의 시나리오 인스턴스들이 실행될 수 있다. 집계 통과/실패 결과는, 예컨대, 통과 또는 실패 결과들의 카운트(count) 또는 퍼센티지(percentage)로서 파라미터화(201b)의 특정 선택에 할당될 수 있다.

테스트 편성 컴포넌트(test orchestration component)(260)는 시뮬레이션의 목적을 위해 시나리오들을 선택할 책임이 있다. 예를 들어, 테스트 편성 컴포넌트(260)는 이전의 시나리오들로부터의 테스트 오라클 출력들(256)에 근거하여 시나리오 설명들(201a) 및 적절한 파라미터화들(201b)을 자동적으로 선택할 수 있다.

테스트 오라클 규칙들(Test oracle rules)

테스트 오라클 내에서 적용될 컴퓨팅연산 그래프들(규칙 트리들)로서 성능 평가 규칙들(254)이 구성된다. 달리 표시되지 않는다면, 본 명세서에서 용어 "규칙 트리(rule tree)"는 주어진 규칙을 구현하도록 구성된 컴퓨팅연산 그래프를 지칭한다. 각각의 규칙이 규칙 트리로서 구성되고, 그리고 복수의 규칙들의 세트는 복수의 규칙 트리들의 "포리스트(forest)"로서 지칭될 수 있다.

도 3a는 추출기 노드(extractor node)들(리프 객체(leaf object)들)(302)과 평가기 노드(assessor node)들(비-리프 객체(non-leaf object)들)(304)의 조합으로부터 구성된 규칙 트리(300)의 예를 보여준다. 각각의 추출기 노드(302)는 시나리오 데이터(310)의 세트로부터 시간-가변성 수치(예컨대, 부동 소수점(floating point)) 신호(점수)를 추출한다. 시나리오 데이터(310)는 앞에서 기술된 의미에서 시나리오 실측 자료의 형태이고, 그리고 그렇게 지칭될 수 있다. 시나리오 데이터(310)는 실제 또는 시뮬레이션된 시나리오에서 (도 1a의 계획기(106)와 같은) 궤적 계획기를 전개(deploying)시킴으로써 획득되었고, 그리고 상황 데이터(214)뿐만 아니라 주체 및 에이전트 트레이스들(212)을 포함하도록 보여진다. 도 2 또는 도 2a의 시뮬레이션 상황에서, 시나리오 실측 자료(310)는 시뮬레이터(202)의 출력으로서 제공된다.

각각의 평가기 노드(304)는 적어도 하나의 자식(child) 객체(노드)를 갖도록 보여지고, 여기서 각각의 자식 객체는 추출기 노드들(302) 중 하나, 또는 평가기 노드들(304) 중 또 다른 하나이다. 각각의 평가기 노드는 자신의 자식 노드(들)로부터 출력(들)을 수신하고 이러한 출력(들)에 평가기 함수를 적용한다. 평가기 함수의 출력은 범주적 결과들의 시-계열(time-series)이다. 다음의 예들은 간단한 이진 통과/실패 결과(binary pass/fail result)들을 고려하지만, 이러한 기법들은 비-이진 결과(non-binary result)들로 쉽게 확장될 수 있다. 각각의 평가기 함수는 미리결정된 극소 규칙(atomic rule)에 대비하여 자신의 자식 노드(들)의 출력(들)을 평가한다. 이러한 규칙들은 원하는 안전 모델에 따라 유연하게 결합될 수 있다.

추가적으로, 각각의 평가기 노드(304)는 자신의 자식 노드(들)의 출력(들)으로부터 시간-가변성 수치 신호를 도출하는데, 이것은 임계 조건(threshold condition)에 의해 범주적 결과들과 관련된다(아래 참조).

최상위-레벨 루트 노드(top-level root node)(304a)는 임의의 다른 노드의 자식 노드가 아닌 평가기 노드이다. 최상위-레벨 노드(304a)는 결과들의 최종 시퀀스를 출력하고, 이것의 자손(descendant)들(즉, 최상위-레벨 노드(304a)의 직접적인 또는 간접적인 자식들(children)인 노드들)은 기반이 되는 신호들 및 중간 결과들을 제공한다.

도 3b는 평가기 노드(304)에 의해 컴퓨팅된, 도출된 신호(312) 및 결과들(314)의 대응하는 시-계열의 예를 시각적으로 도시한다. 결과들(314)은 도출된 신호(312)와 상관(correlate)되는데, 도출된 신호가 실패 임계치(316)를 초과할 때(및 초과할 때에만) 통과 결과(pass result)가 반환(return)된다는 점에서, 그러하다. 이해될 것인 바와 같이, 이것은 단지, 결과들의 시간-시퀀스를 대응하는 신호에 관련시키는 임계 조건의 하나의 예일 뿐이다.

추출기 노드들(302)에 의해 시나리오 실측 자료(310)로부터 직접적으로 추출된 신호들은, 평가기 노드들(304)에 의해 컴퓨팅된 "도출된(derived)" 신호들과 구분하기 위해 "원시(raw)" 신호들로서 지칭될 수 있다. 결과들 및 원시/도출된 신호들은 시간에 있어 이산화(discretize)될 수 있다.

도 4a는 테스트 플랫폼(testing platform)(200) 내에서 구현되는 규칙 트리의 예를 보여준다.

테스트 오라클(252)로 구현될 규칙들을 구성하기 위해 규칙 편집기(400)가 제공된다. 규칙 편집기(400)는 (시스템의 최종-사용자일 수 있거나 또는 아닐 수 있는) 사용자로부터 규칙 생성 입력들을 수신한다. 본 예에서, 규칙 생성 입력들은, 도메인 특정 언어(Domain Specific Language, DSL)에서 코딩되고, 그리고 테스트 오라클(252) 내에서 구현될 적어도 하나의 규칙 그래프(408)를 정의한다. 규칙들은 다음의 예들에서 논리적 규칙들인데, 여기서 참(TRUE) 및 거짓(FALSE)은 통과 및 실패를 각각 나타낸다(이해될 것인 바와 같이, 이것은 순전히 설계 선택임).

다음의 예들은 극소 로직 술어(atomic logic predicate)들의 조합들을 사용하여 공식화되는 규칙들을 고려한다. 기본적인 극소 술어들의 예들은, 기본 로직 게이트들(OR, AND, 등), 그리고 (a가 b보다 클 때 참을 반환하고 그렇지 않으면 거짓을 반환하는) "greater than", (Gt(a,b))와 같은 논리적 함수들을 포함한다.

Gt 함수는 시나리오에서 주체 에이전트와 (에이전트 식별자 "other_agent_id"를 갖는) 또 하나의 다른 에이전트 간의 안전한 측방향 거리 규칙(safe lateral distance rule)을 구현하기 위한 것이다. 두 개의 추출기 노드들(latd, latsd)은 LateralDistance 및 LateralSafeDistance 추출기 함수들을 각각 적용한다. 이러한 함수들은, (주체 에이전트와 식별된 다른 에이전트 간의 측방향 거리를 측정하는) 시간-가변성 측방향 거리 신호와, 그리고 주체 에이전트 및 식별된 다른 에이전트에 대한 시간-가변성 안전한 측방향 거리 신호를 각각 추출하기 위해 시나리오 실측 자료(310)에 관해 직접적으로 동작한다. 안전한 측방향 거리 신호는, (트레이스들(212)에서 캡처된) 주체 에이전트의 속력 및 다른 에이전트의 속력, 그리고 상황 데이터(214)에서 캡처된 환경 조건들(예컨대, 날씨, 조명, 도로 타입, 등)과 같은 다양한 인자들에 종속될 수 있다.

평가기 노드(is_latd_safe)는 latd 및 latsd 추출기 노드들에 대한 부모(parent)이고, 그리고 Gt 극소 술어에 맵핑된다. 이에 따라, 규칙 트리(408)가 구현되는 경우, is_latd_safe 평가기 노드는, 시나리오의 각각의 시간단계에 대한 참/거짓 결과를 컴퓨팅하기 위해서, latd 및 latsd 추출기 노드들의 출력들에 Gt 함수를 적용하고, latd 신호가 latsd 신호를 초과하는 각각의 시간 단계에 대해서는 참을 반환하고, 그렇지 않으면 거짓을 반환한다. 이러한 방식으로, "안전한 측방향 거리(safe lateral distance)" 규칙이 극소 추출기 함수들 및 술어들로부터 구성되었고, 측방향 거리가 안전한 측방향 거리 임계치에 도달하거나 그 아래로 떨어지는 경우 주체 에이전트는 안전한 측방향 거리 규칙을 실패한다. 이해될 것인 바와 같이, 이것은 규칙 트리의 매운 간단한 예이다. 임의의 복잡도의 규칙들이 동일한 원리들에 따라 구성될 수 있다.

테스트 오라클(252)은 시나리오 실측 자료(310)에 규칙 트리(408)를 적용하고, 그리고 사용자 인터페이스(User Interface, UI)(418)를 통해 결과들을 제공한다.

도 4b는 도 4a의 측방향 거리 분기(lateral distance branch)에 대응하는 측방향 거리 분기를 포함하는 규칙 트리의 예를 보여준다. 추가적으로, 규칙 트리는, 안전한 거리 메트릭을 구현하기 위해 길이방향 거리 분기(longitudinal distance branch) 및 최상위-레벨 OR 술어(안전한 거리 노드(is_d_safe))를 포함한다. 측방향 거리 분기와 유사하게, 길이방향 거리 브랜드는 시나리오 데이터로부터 (추출기 노드들(lond 및 lonsd) 각각이) 길이방향 거리 및 길이방향 거리 임계 신호들을 추출하고, 그리고 길이방향 거리가 안전한 길이방향 거리 임계치 위에 있는 경우 길이방향 안전 평가기 노드(is_lond_safe)가 참을 반환한다. 최상위-레벨 OR 노드는, 측방향 및 길이방향 거리들 중 하나 혹은 양쪽 모두가 안전한 경우(적용가능한 임계치 아래에 있는 경우), 참을 반환하고, 그리고 만약 그 어느 것도 안전하지 않다면 거짓을 반환한다. 이러한 상황에서, 거리들 중 단 하나만이 안전 임계치를 초과하면 충분하다(예를 들어, 만약 두 개의 차량들이 인접한 차선들에서 주행하고 있다면, 이들이 나란히 있는 경우 이들의 길이방향 분리는 제로(zero)이거나 제로에 가까운데, 하지만 이러한 상황은 만약 이러한 차량들이 충분한 측방향 분리를 갖는다면 불안전하지 않음).

최상위-레벨 노드의 수치 출력은 예를 들어, 시간-가변성 강건도 점수(time-varying robustness score)일 수 있다.

상이한 규칙 트리들이, 예를 들어, 주어진 안전 모델의 상이한 규칙들을 구현하기 위해, 또는 상이한 안전 모델들을 구현하기 위해, 또는 상이한 시나리오들에 규칙들을 선택적으로 적용하기 위해, 구성될 수 있다(주어진 안전 모델에서, 모든 규칙이 모든 시나리오에 반드시 적용가능한 것은 아닐 것이며, 이러한 접근법에 있어서, 상이한 규칙들 또는 규칙들의 조합들이 상이한 시나리오들에 적용될 수 있음). 이러한 프레임워크(framework) 내에서, 규칙들은 또한, (예컨대, 궤적을 따르는 순간 가속도 및/또는 저크에 근거하는) 안락, (정의된 목표에 도달하기 위해 소요되는 시간에 근거하는) 진행, 등을 평가하기 위해 구성될 수 있다.

앞서의 예들은, OR, AND, Gt, 등과 같은, 단일 시간 인스턴스에서 결과들 또는 신호들에 관해 평가되는 간단한 논리적 술어들을 고려한다. 하지만, 실제로는, 시간적 로직(temporal logic)의 측면에서 특정 규칙들을 공식화하는 것이 바람직할 수 있다.

(그 전체가 참조로 본 명세서에 통합되는) 헤크마트네자드(Hekmatnejad), 외의 문헌("Encoding and Monitoring Responsibility Sensitive Safety Rules for Automated Vehicles in Signal Temporal Logic" (2019), MEMOCODE'19: Proceedings of the 17th ACM-IEEE International Conference on Formal Methods and Models for System Design)은 RSS 안전 규칙들의 신호 시간적 로직(Signal Temporal Logic, STL) 인코딩을 개시한다. 시간적 로직은 시간의 측면에서 수식(qualify)되는 술어들을 구성하기 위한 형식적 프레임워크(formal framework)를 제공한다. 이것은, 주어진 시각에 평가기에 의해 컴퓨팅된 결과가 또 하나의 다른 시각(들)에서의 결과들 및/또는 신호 값들에 종속될 수 있음을 의미한다.

예를 들어, 안전 모델의 요건은 설정된 시간 프레임 내에서 특정 이벤트에 주체 에이전트가 응답하는 것일 수 있다. 이러한 규칙들은 규칙 트리 내의 시간적 로직 술어(temporal logic predicate)들을 사용하여 유사한 방식으로 인코딩될 수 있다.

앞서의 예들에서, 스택(100)의 성능은 시나리오의 각각의 시간 단계에서 평가된다. 이로부터 전체 테스트 결과(예컨대, 통과/실패)가 도출될 수 있는데, 예를 들어, 특정 규칙들(예컨대, 안전에 필수적인 규칙(safety-critical rule)들)은, 만약 규칙이 시나리오 내의 임의의 시간 단계에서 실패된다면, 결과적으로, 전체 실패가 될수 있다(즉, 규칙은, 시나리오에 관해 전체 통과를 획득하기 위해서 모든 시간 단계에서 통과돼야만 함). 규칙의 다른 타입들에 대해, 전체 통과/실패 기준들은 "더 연성(softer)"일 수 있고(예를 들어, 실패는, 특정 규칙에 대해, 그 규칙이 어떤 수의 순차적 시간 단계들에 걸쳐 실패되는 경우에만 트리거될 수 있음), 그리고 이러한 기준들은 상황 종속적일 수 있다.

도 4c는 테스트 오라클(252) 내에서 구현되는 규칙 평가의 계층체계(hierarchy)를 개략적으로 도시한다. 규칙들(254)의 세트가 테스트 오라클(252) 내에서의 구현을 위해 수신된다.

특정 규칙들은 주체 에이전트에만 적용된다(예는 임의의 주어진 시각에서 주체 궤적에 의해 어떤 최대 가속도 또는 저크 임계치가 초과되는지 여부를 평가하는 안락 규칙임).

다른 규칙들은 다른 에이전트들과의 주체 에이전트의 상호작용에 관한 것이다(예를 들어, 앞에서 고려된 안전한 거리 규칙 또는 "충돌 없음(no collision)" 규칙). 각각의 이러한 규칙은 주체 에이전트와 각각의 다른 에이전트 간에 쌍을 이루는 방식으로 평가된다. 또 하나의 다른 예로서, "보행자 긴급 제동(pedestrian emergency braking)" 규칙이, 주체 차량의 전방에서 보행자가 걸어나올 때에만, 그리고 해당 보행자 에이전트와 관련하여서만 활성화될 수 있다.

모든 규칙이 모든 시나리오에 반드시 적용가능하지는 않을 것이고, 그리고 일부 규칙들은 시나리오의 일부에 대해서만 적용가능할 수 있다. 테스트 오라클(252) 내의 규칙 활성화 로직(422)은, 규칙들(254) 각각이 해당 시나리오에 적용가능한지 그리고 언제 적용가능한지를 결정하고, 그리고 규칙들이 적용됨에 따라 그리고 적용될 때 규칙들을 선택적으로 활성화시킨다. 따라서, 규칙은 전체 시나리오에 대해 활성 상태에서 유지될 수 있거나, 주어진 시나리오에 대해 결코 활성화될 수 없거나, 또는 시나리오 중 일부에 대해서만 활성화될 수 있다. 더욱이, 규칙은 시나리오 내의 상이한 지점들에서 상이한 수의 에이전트들에 대해 평가될 수 있다. 이러한 방식으로 규칙들을 선택적으로 활성화시키는 것은 테스트 오라클(252)의 효율을 크게 증가시킬 수 있다.

주어진 규칙의 활성화 또는 비활성화는 하나 이상의 다른 규칙들의 활성화/비활성화에 종속될 수 있다. 예를 들어, "최적의 안락(optimal comfort)" 규칙은 보행자 긴급 제동 규칙이 활성화될 때 적용가능하지 않는 것으로 고려될 수 있고(왜냐하면 보행자의 안전이 1차 관심사이기 때문임), 그리고 전자는 후자가 활성화될 때마다 비활성화될 수 있다.

규칙 평가 로직(424)은 각각의 활성 규칙을 활성 상태에서 유지되는 임의의 시간 기간(time period)(들)에 대해 평가한다. 각각의 비활성 규칙은 이것이 적용되는 주체 에이전트와 임의의 다른 에이전트 간에 쌍을 이루는 방식으로 평가된다.

규칙들의 적용에 있어 상호종속도(degree of interdependency)가 또한 존재할 수 있다. 예를 들어, 안락 규칙과 긴급 제동 규칙 간의 관계를 처리하기 위한 또 하나의 다른 방식은 긴급 제공 규칙이 적어도 하나의 다른 에이전트에 대해 활성화될 때마다 안락 규칙의 저크/가속도 임계치를 증가시키는 것이다.

통과/실패 결과들이 고려되었지만, 규칙들은 비-이진일 수 있다. 예를 들어, 실패에 대한 두 개의 범주들, "허용가능함(acceptable)" 및 "허용불가능함(unacceptable)"이 도입될 수 있다. 다시, 안락 규칙과 긴급 제동 규칙 간의 관계를 고려하면, 안락 규칙에 관한 허용가능한 실패는 해당 규칙이 실패된 경우 하지만 긴급 제동 규칙이 활성 상태인 때에 일어날 수 있다. 따라서, 규칙들 간의 상호종속성은 다양한 방식들에서 다루어질 수 있다.

규칙들(254)에 대한 활성화 기준들은 규칙 편집기(400)에게 제공된 규칙 생성 코드에서 특정될 수 있고, 가능한 것으로서, 임의의 규칙 상호종속성들의 성질 및 이러한 상호종속성들을 구현하기 위한 메커니즘(들)이 특정될 수 있다.

그래픽 사용자 인터페이스(Graphical user interface)

도 5는 시각화 컴포넌트(520)의 개략적인 블록도를 보여준다. 그래픽 사용자 인터페이스(Graphical User Interface, GUI)(500) 상에 테스트 오라클(252)의 출력들(256)을 렌더링하기 위해 테스트 데이터베이스(258)에 연결된 입력을 갖는 시각화 컴포넌트가 보여진다. GUI가 디스플레이 시스템(522) 상에 렌더링된다.

도 5a는 GUI(500)의 예시적 뷰를 보여준다. 이러한 뷰는 복수의 에이전트들을 포함하는 특정 시나리오와 관련된다. 이러한 예에서, 테스트 오라클 출력(526)은 복수의 외부 에이전트들과 관련되고, 그리고 결과들은 에이전트에 따라 조직화(organize)된다. 각각의 에이전트에 대해, 결과들의 시-계열은 시나리오에서의 어떤 지점에서 해당 에이전트에 적용가능한 각각의 규칙에 대해 이용가능하다. 도시된 예에서, "에이전트 01"에 대해 개요 뷰(summary view)가 선택되었고, 이것은 컴퓨팅된 "최상위-레벨" 결과들로 하여금 각각의 적용가능한 규칙에 대해 디스플레이되도록 한다. 각각의 규칙 트리의 루트 노드에서 컴퓨팅된 최상위-레벨 결과들이 존재한다. 규칙이 해당 에이전트에 대해 비활성 상태('적용가능하지 않음')일 때, 활성 상태이고 통과한 때, 그리고 활성 상태이고 실패된 때의 기간들 간을 구분하기 위해 컬러 코딩(colour coding)이 사용된다.

제 1 선택가능 요소(534a)가 결과들의 각각의 시-계열에 대해 제공된다. 이것은 규칙 트리의 더 낮은-레벨 결과들이 액세스(access)될 수 있게 하는데, 즉, 규칙 트리에서 아래로 더 낮게 컴퓨팅되는 바와 같이 액세스될 수 있게 한다.

도 5b는 "규칙 02"에 대한 결과들의 제 1 확장된 뷰를 보여주고, 여기에는 더 낮은-레벨 노드들의 결과들이 또한 시각화된다. 예를 들어, 도 4b의 "안전한 거리" 규칙에 대해, "is_latd_safe 노드" 및 "is_lond_safe" 노드들의 결과들이 시각화될 수 있다(도 5b에서 "C1" 및 "C2"로 라벨링(label)되어 있음). 규칙 02의 제 1 확장된 뷰에서, 규칙 02에 관한 성공/실패가 결과들(C1과 C2) 간의 논리적 OR 관계에 의해 정의된다는 것, 그리고 (앞서의 "안전한 거리" 규칙에서와 같이) 규칙 02는 C1과 C2 양쪽 모두에 관해 실패가 획득되는 경우에만 실패된다는 것을 알 수 있다.

제 2 선택가능 요소(534b)가 결과들의 각각의 시-계열에 대해 제공되고, 이것은 관련된 수치적 성능 점수들이 액세스될 수 있게 한다.

도 5c는 제 2 확장된 뷰를 보여주고, 여기서는 규칙 02에 대한 결과들 및 "C1" 결과들이, 이러한 규칙들이 에이전트 01에 대해 활성 상태인 시간 기간(들)에 대한 관련된 점수들을 들어내기 위해, 확장되었다. 점수들은 통과/실패를 나타내기 위해 유사하게 컬러 코딩된 시각적 점수-시간 플롯(visual score-time plot)으로서 디스플레이된다.

예시적 시나리오들(Example scenarios)

도 6a는 주체 차량(602)과 또 하나의 다른 차량(604) 간의 충돌 이벤트로 종료되는 시뮬레이터(202)에서의 끼어들기 시나리오의 제 1 인스턴스를 도시한다. 끼어들기 시나리오는, 복수-차선 주행 시나리오로서 특징지어지는데, 여기서 주체 차량(602)은 제 1 차선(612)(주체 차선)을 따라 움직이고 있고, 다른 차량(604)은 초기에 인접하는 제 2 차선(604)을 따라 움직이고 있다. 시나리오에서의 어떤 지점에서, 다른 차량(604)은 인접하는 차선(614)로부터 주체 차선(612)으로 주체 차량(602)의 앞으로(끼어들기 거리) 움직인다. 이러한 시나리오에서, 주체 차량(602)은 다른 차량(604)과의 충돌을 피할 수 없다. 제 1 시나리오 인스턴스는 충돌 이벤트에 응답하여 종료된다.

도 6b는 제 1 시나리오 인스턴스의 실측 자료(310a)로부터 획득된 제 1 오라클 출력(256a)의 예를 도시한다. "충돌 없음(no collision)" 규칙이 주체 차량(602)과 다른 차량(604) 간에 시나리오의 지속기간에 걸쳐 평가된다. 충돌 이벤트는 결과적으로 시나리오의 끝에서 이러한 규칙에 대한 실패를 초래한다. 추가적으로, 도 4b의 "안전한 거리" 규칙이 평가된다. 다른 차량(604)이 주체 차량(602)에 측방향으로 더 가깝게 움직임에 따라, 안전한 측방향 거리 및 안전한 길이방향 거리 임계치들 양쪽 모두가 깨지는 시점(t1)에 도달하고, 이것은 결과적으로 시간(t2)에서의 충돌 이벤트까지 지속되는 안전한 거리 규칙에 관한 실패를 초래한다.

도 6c는 끼어들기 시나리오의 제 2 인스턴스를 도시한다. 제 2 인스턴스에서, 끼어들기 이벤트는 결과적으로 충돌을 초래하지 않고, 그리고 주체 차량(602)은 끼어들기 이벤트 이후 다른 차량(604) 뒤에서 안전한 거리에 도달할 수 있다.

도 6d는 제 2 시나리오 인스턴스의 실측 자료(310b)로부터 획득된 제 2 오라클 출력(256b)의 예를 도시한다. 이러한 경우에, "충돌 없음" 규칙은 전적으로 통과된다. 주체 차량(602)과 다른 차량(604) 간의 측방향 거리가 불안전하게 되는 시간(t3)에서 안전한 거리 규칙은 깨진다. 하지만, 시간(t4)에서, 주체 차량(602)은 다른 차량(604) 뒤에서 안전한 거리에 도달하려고 한다. 따라서, 안전한 거리 규칙은 시간(t3)과 시간(t4) 사이에서만 실패된다.

규칙 편집기 - 도메인 특정 언어( DSL )(Rule editor - domain specific language ( DSL ))

도 7은 DSL의 특정 선택에서 코딩된 테스트 오라클(400)에 대한 규칙 생성 입력들의 예를 보여준다.

도 7의 예에서, 맞춤형 규칙 그래프(custom rule graph)들이 테스트 플랫폼(200) 내에서 구성될 수 있다. 테스트 오라클(252)은, 미리결정된 추출기 함수들(702) 및 미리결정된 평가기 함수들(704)의 형태에서, 모듈식 "빌딩 블록(building block)들"의 세트를 제공하도록 구성된다.

규칙 편집기(400)가 사용자로부터 규칙 생성 입력들을 수신한다. 규칙 생성 입력들은 DSL에서 코딩되고, 그리고 규칙 생성 코드(706)의 예시적 섹션(example section)이 도시된다. 규칙 생성 코드(706)는 도 4a의 맞춤형 규칙 그래프에 대응하는 맞춤형 규칙 그래프(408)를 정의한다. 규칙 그램(rule gram)의 선택은 순수하게 예시적이고, 그리고 DSL의 혜택은 원하는 규칙 그래프가 맞춤화 방식으로 사용자에 의해 구성될 수 있다는 것이다. 규칙 편집기(400)는 규칙 생성 코드(706)를 해석하고, 맞춤형 규칙 그래프(408)로 하여금 테스트 오라클(252) 내에 구현될 수 있도록 한다.

코드(706) 내에, 추출기 노드 생성 입력이 도시되고, 그리고 711로 라벨링되어 있다. 추출기 노드 생성 입력(711)은 미리결정된 추출기 함수들(702) 중 하나의 추출기 함수의 식별자(712)를 포함하도록 보여진다.

평가기 노드 생성 입력(713)이 또한 도시되고, 그리고 미리결정된 평가기 함수들(704) 중 하나의 평가기 함수의 식별자(714)를 포함하도록 보여진다. 여기서, 입력(713)은 평가기 노드에게 명령하여 노드 식별자들(715a, 715b)을 갖는 두 개의 자식 노드들과 함께 생성되도록 한다(이들은 본 예에서 추출기 노드들이 되도록 일어나지만, 평가기 노드들일 수 있고, 추출기 노드들일 수 있고, 또는 일반적으로는 양쪽 모두의 조합일 수 있음).

맞춤형 규칙 그래프의 노드들은 객체-지향 프로그래밍(Object-Oriented Programming, OOP) 의미에서 객체들이다. 노드 팩토리 클래스(node factory class)(Nodes())가 테스트 오라클(252) 내에 제공된다. 맞춤형 규칙 그래프(708)를 구현하기 위해, 노드 팩토리 클래스(710)가 인스턴스화되고, 그리고 결과적인 팩토리 객체(factory object)(710)(node-factory)의 노드 생성 함수(add_node)가, 생성될 노드의 세부사항들과 함께 호출된다.

코드(706)에 따르면, Gt 함수는 시나리오에서 주체 에이전트와 (에이전트 식별자 "other_agent_id"를 갖는) 또 하나의 다른 에이전트 간에 안전한 측방향 거리 규칙을 구현하기 위해 사용되게 된다. 두 개의 추출기 노드들(latd, latsd)이 코드(406)에서 정의되고, 그리고 미리결정된 LateralDistance 및 LateralSafeDistance 추출기 함수들에 각각 맵핑된다. 이러한 함수들은, (주체 에이전트와 식별된 다른 에이전트 간의 측방향 거리를 측정하는) 시간-가변성 측방향 거리 신호와, 그리고 주체 에이전트 및 식별된 다른 에이전트에 대한 시간-가변성 안전한 측방향 거리 신호를 각각 추출하기 위해 시나리오 실측 자료(310)에 관해 직접적으로 동작한다. 안전한 측방향 거리 신호는, (트레이스들(212)에서 캡처된) 주체 에이전트의 속력 및 다른 에이전트의 속력, 그리고 상황 데이터(214)에서 캡처된 환경 조건들(예컨대, 날씨, 조명, 도로 타입, 등)과 같은 다양한 인자들에 종속될 수 있다. 이것은 원하는 추출기 함수를 간단히 선택해야만 하는 최종-사용자에게 거의 가시적이지 않다(하지만, 일부 구현예들에서, 함수의 하나 이상의 구성가능한 파라미터들은 최종-사용자에게 노출될 수 있음).

평가기 노드(is_latd_safe)는 latd 및 latsd 추출기 노드들에 대한 부모로서 코드(706)에서 정의되고, 그리고 Gt 극소 술어에 맵핑된다. 이에 따라, 규칙 트리(408)가 구현되는 경우, is_latd_safe 평가기 노드는, 시나리오의 각각의 시간단계에 대한 참/거짓 결과를 컴퓨팅하기 위해서, latd 및 latsd 추출기 노드들의 출력들에 Gt 함수를 적용하고, latd 신호가 latsd 신호를 초과하는 각각의 시간 단계에 대해서는 참을 반환하고, 그렇지 않으면 거짓을 반환한다. 이러한 방식으로, "안전한 측방향 거리(safe lateral distance)" 규칙이 극소 추출기 함수들 및 술어들로부터 구성되었고, 측방향 거리가 안전한 측방향 거리 임계치에 도달하거나 그 아래로 떨어지는 경우 주체 에이전트는 안전한 측방향 거리 규칙을 실패한다. 이해될 것인 바와 같이, 이것은 맞춤형 규칙의 매운 간단한 예이다. 임의의 복잡도의 규칙들이 동일한 원리들에 따라 구성될 수 있다. 테스트 오라클(252)은 시나리오 실측 자료(310)에 맞춤형 규칙 트리(408)를 적용하고, 그리고 출력 그래프(717)의 형태에서 결과들을 제공하는데, 즉, 테스트 오라클(252)은 단순히 최상위-레벨 출력들을 제공하는 것이 아니라 맞춤형 규칙 그래프(408)의 각각의 노드에서 컴퓨팅된 출력을 제공한다. "안전한 측방향 거리 예"에서는, is_latd_safe 노드에 의해 컴퓨팅된 결과들의 시-계열이 제공되고, 하지만 기반이 되는 신호들(latd 및 latsd)이 또한 출력 그래프(717)에서 제공되는데, 이것은 최종-사용자로 하여금 그래프 내의 임의의 레벨에서 특정 규칙에 관한 실패의 원인을 쉽게 조사할 수 있게 한다. 이러한 예에서, 출력 그래프(717)는 사용자 인터페이스(UI)(418)를 통해 디스플레이되는 맞춤형 규칙 그래프(408)의 시각적 표현이고, 맞춤형 규칙 그래프의 각각의 노드는 도 5a 내지 도 5c에 도시된 방식으로 그 출력의 시각화로 증강(augment)된다.

도 8은 맞춤형 규칙 트리를 렌더링하기 위한 GUI(500)의 추가적인 예시적 뷰를 보여준다. 복수의 출력 그래프들이 GUI를 통해 이용가능하고, 출력 그래프가 관련되어 있는 시나리오 실측 자료의 시각화(501)와 연관되어 디스플레이되어 있다. 각각의 출력 그래프는 규칙 그래프의 각각의 노드의 출력의 시각화로 증강된 특정 규칙 그래프의 시각적 표현이다. 각각의 출력 그래프는 초기에, 각각의 컴퓨팅연산 그래프의 루트 노드만이 나타내어진, 축소된 형태(collapsed form)에서 디스플레이된다. 제 1 시각적 요소(802) 및 제 2 시각적 요소(804)는 제 1 컴퓨팅연산 그래프 및 제 2 컴퓨팅연산 그래프의 루트 노드들을 각각 나타낸다. 제 1 출력 그래프는 축소된 형태에서 도시되고, 그리고 루트 노드에 대한 이진 통과/실패 결과들의 시-계열만이 (제 1 시각적 요소(802) 내에서 간단한 컬러-코딩된 수평 바(horizontal bar)로서) 시각화되어 있다. 하지만, 제 1 시각적 요소(802)는 시각화를 더 낮은-레벨 노드(들) 및 이들의 출력(들)으로 확장시키도록 선택가능하다. 제 2 출력 그래프는 확장된 형태에서 도시되고, 이것은 제 2 시각적 요소(804)를 선택함으로써 액세스된다. 시각적 요소들(806, 808)은 적용가능한 규칙 그래프 내에서 더 낮은-레벨 평가기 노드들을 나타내고, 이들의 결과들은 동일한 방식으로 시각화된다. 시각적 요소들(810, 812)은 그래프 내에서 추출기 노드들을 나타낸다. 각각의 노드의 시각화는 또한 해당 노드의 확장된 뷰를 렌더링하도록 선택가능하다. 확장된 뷰는 해당 노드에서 컴퓨팅된 혹은 추출된 시간-가변성 수치 신호의 시각화를 제공한다. 제 2 시각적 요소(804)는 확장된 상태에서 보여지고, 이 경우 그 도출된 신호의 시각화가 결과들의 이진 시퀀스 대신에 디스플레이된다. 도출된 신호는 실패 임계치에 근거하여 컬러-코딩된다(제로 이하로 떨어지는 신호는 본 예에서, 적용가능한 규칙에 관한 실패를 나타냄). 추출기 노드들의 시각화들(810, 812)은 이들의 원시 신호들의 시각화들을 렌더링하기 위해 동일한 방식으로 확장가능하다. 도 8의 뷰는 규칙 그래프의 출력들을 렌더링하는데, 이것은 시나리오 실측 자료의 주어진 세트에 관해 평가가 이루어진 경우이다. 추가적으로, 평가 이전에 규칙 그래프를 생성하는 사용자의 혜택을 위해 초기 시각화가 렌더링될 수 있다. 초기 시각화는 규칙 생성 코드(406)에서의 변경에 응답하여 업데이트될 수 있다.

비록 도 7에서는 도시되지 않지만, 노드 생성 입력(711, 713)은 관련된 평가기 또는 추출기 함수의 하나 이상의 구성가능한 파라미터(들)(예컨대, 임계치들, 시간 간격들, 등)에 대한 값(들)을 추가적으로 설정할 수 있다.

특정 실시예들에서, 증가된 컴퓨팅연산 효율이, 규칙 그래프의 선택적 평가를 통해 성취될 수 있다. 예를 들어, 도 7의 그래프 내에서, 만약 (예를 들어) is_latd_safe가 어떤 시간 단계에서 또는 시간 간격에서 참을 반환한다면, 최상위-레벨 is_d_safe 노드의 출력은 그 시간 단계/간격에 대한 길이방향 거리 분기를 평가함이 없이 컴퓨팅될 수 있다. 이러한 효율 이득들은 그래프의 "하향식(top-down)" 평가에 근거하는데, 이것은 트리의 최상위-레벨에서 시작하며 최상위-레벨 출력을 획득하기 위해 필요에 따라 추출기 노드들로의 하향 분기(들)만을 컴퓨팅한다.

평가기 또는 추출기 함수는 하나 이상의 구성가능한 파라미터들을 가질 수 있다. 예를 들어, latsd 및 lonsd 노드들은 예컨대, 주체 속도의 구성가능한 함수들로서 시나리오 실측 자료(310)로부터 임계 거리들이 어떻게 추출되는지를 특정하는 구성가능한 파라미터(들)를 가질 수 있다.

추가 효율 이득들은 가능한 정도까지 결과들을 캐싱(caching) 및 재사용함으로써 획득될 수 있다.

예를 들어, 사용자가 그래프 또는 일부 파라미터를 수정하는 경우, 영향을 받는 노드들의 출력들만이 재컴퓨팅될 수 있다(그리고, 일부 경우들에서는, 최상위-레벨 결과를 컴퓨팅하기 위해 필요한 정도까지만 재컴퓨팅될 수 있음, 앞서의 설명 참조).

앞서의 예들은 시간-가변성 신호들 그리고 또는 범주적인 것(예컨대, 통과/실패 또는 참/거짓 결과들)의 시-계열의 형태에서 출력들을 고려하지만, 출력의 다른 타입들이 대안적으로 또는 추가적으로 노드들 간에 전달될 수 있다. 예를 들어, 시간-가변성 반복가능 객체들(즉, for 루프에 걸쳐 반복될 수 있는 객체들)이 노드들 간에 전달될 수 있다.

변수들이 할당될 수 있고 그리고/또는 트리를 통해 전달될 수 있으며 실행시간에 결속될 수 있다. 실행시간 변수들 및 반복가능 객체들의 조합은 루프들의 제어 및 실행시간 (시나리오-관련) 파라미터화를 제공하고, 반면 트리 자체는 "정적(static)" 상태에서 유지된다.

for 루프들은 예를 들어, "전방의 에이전트들에 대해" 또는 "해당 교차로에서의 각각의 교통 신호등에 대해" 규칙들이 적용되는 시나리오-특정 조건들을 정의할 수 있다. 이러한 루프들을 구현하기 위해, (예컨대, 'other_agent' 변수에 근거하여 '각각의 인근 에이전트에 대한' 루프를 구현하기 위해) 변수들이 필요하지만, 이들은 또한, 트리에서 더 아래에 있는 다른 블록들(노드들)에 의해 이후 액세스(로딩)될 수 있는 현재 상황에서의 변수들을 정의(저장)하기 위해 사용될 수 있다.

시간 기간들은 요구되는 바에 따라서만 컴퓨팅될 수 있고(이것도 또한 하향식 방식으로 행해짐), 그리고 결과들은 새롭게 요구되는 시간 기간들에 대해 캐싱 및 병합될 수 있다.

예를 들어, 하나의 규칙(규칙 그래프)은 적응형 순항 제어 차머리에 대비하여 점검할 전방 차량에 대해 가속도가 컴퓨팅될 것을 요구할 수 있다. 별개로, 또 하나의 다른 규칙(규칙 트리)은 주체 에이전트 주위의 모든 차량들('인근' 에이전트들)의 가속도를 요구할 수 있다.

적용가능한 시간 기간들이 중첩(overlap)되는 경우에(예컨대, 'other_vehicle'이 '전방(forward)'인 것으로 고려되는 지속기간이 그것이 '인근(nearby)'인 것으로 고려되는 지속기간의 서브세트인 경우에), 하나의 트리는 다른 것의 가속도 데이터를 재-사용할 수 있다.

도 4c를 참조하면, 규칙 활성화 로직(422)은, 시나리오 실행이 진행됨에 따라, 앞에서 설명된 방식에서, 반복가능 객체들에 걸쳐 루프들에 근거하여 구현될 수 있다. DSL은 임의의 주어진 시간 단계에서 임의의 술어들에 걸쳐 루프들을 구현하도록 확장될 수 있다. 이러한 경우에, 제 1 로직 술어는 각각의 에이전트에 적용가능한 활성화 조건을 정의한다. 예를 들어, 제 1 술어는 (예컨대, 주체 에이전트의 어떤 임계 거리 내에서 임의의 에이전트(들)에 의해 충족되는) 거리 임계 조건의 측면에서 "인근" 에이전트의 개념을 정의할 수 있고, 또는 (예컨대, 단일 에이전트에 의해, 만약 해당 에이전트가 (ⅰ) 주체 에이전트의 전방에 있다면, (ⅱ) 주체 에이전트와 동일한 차선에 있다면, 그리고 (ⅲ) 조건 (ⅰ) 및 조건 (ⅱ)를 충족시키는 임의의 다른 에이전트보다 에이전트에 더 가까이 있다면, 충족되는) 에이전트 위치에 관한 조건들의 적절한 세트로서 "전방" 에이전트의 개념을 정의할 수 있다. 활성화 조건을 정의하는 제 1 로직 술어는 규칙들 자체들과 동일한 방식으로 DSL에서 코딩될 수 있다. 규칙 트리는, 그 다음에, 앞서의 방식으로 제 2 로직 술어에 의해 정의될 수 있다. 이것은 DSL 프레임워크를 임의의 술어들에 걸쳐 루프들을 통합시키도록 확장시킨다. DSL에서 구성될 형태 "[술어 1을 충족시키는 임의의 에이전트]에 대해, [술어 2]를 평가"의 루프들을 사용하여 DSL에서 인코딩될 규칙들 및 활성화 조건들의 경우에, 시나리오 실행의 각각의 단계에서, (만약 있다면) 술어 1을 충족시키는 에이전트(들)의 세트가 구성되고, 그리고 술어 2가 해당 세트의 멤버(member)들에 대해서만 평가된다. "술어 1"은, 에이전트 당, 규칙에 대한 활성화 조건을 정의하고, 그리고 "술어 2"는 규칙 트리 자체를 정의한다. 시간-가변성 반복가능 객체는 어떤 에이전트들이 시나리오 실행의 지속기간에 걸쳐 임의의 시간에 술어 1을 충족시키는 지를 추적하도록 구성될 수 있고, 그리고 효율적인 규칙 평가를 용이하게 하기 위해 필요에 따라 규칙 트리 아래로 전달될 수 있다.

각각의 규칙 및 그 활성화 조건은 예를 들어, 1-차 로직(first-order logic)에서 정의될 수 있다.

아래에는, 대안적 구문(syntax)을 사용하여 시간적 로직 술어(temporal logic predicate)로서 맞춤형 규칙 그래프(ALKS_01)를 정의하는 코드의 섹션이 제공된다.

앞서의 예에서, LongitudinalDistance() 및 VelocityAlongRoadLateralAxis()는 미리결정된 추출기 함수들이고, 그리고 "and", Eventually(), Next() 및 Always()와 같은 함수들은 극소 평가기 함수들이다. 함수 AgentIsOnSameLane()은 주어진 에이전트가 주체 에이전트와 동일한 차선에 있는지 여부를 결정한, 시나리오에 직접적으로 적용되는 평가기 함수이다.

여기서, NearbyAgents()는 주체 에이전트에 대한 어떤 거리 임계치를 충족시키는 임의의 다른 에이전트들을 식별하는 시간-가변성 반복가능 객체이다. 이것은 주체 에이전트로부터의 거리에 근거하여 주체 에이전트와 각각의 다른 에이전트 간에 적용되는 규칙 활성화 조건의 하나의 예이다.

앞서의 예들이 AV 스택 테스트를 고려하지만, 이러한 기법들은 모바일 로봇의 다른 형태들의 테스트 컴포넌트에 적용될 수 있다. 예를 들어, 내부 및 외부 산업 구역들에서 화물 공급품들을 운반하기 위해 다른 모바일 로봇들이 개발되고 있다. 이러한 모바일 로봇들에 탑승한 사람들은 없게 되며, 이러한 모바일 로봇들은 UAV(Unmanned Autonomous Vehicle, 무인 자율주행 차량)으로 지칭되는 모바일 로봇의 클래스에 속한다. 자율주행 비행 모바일 로봇(드론(drone))들이 또한 개발되고 있다.

컴퓨터 시스템은, 본 명세서에서 개시되는 방법/알고리즘적 단계들을 실행하도록 구성될 수 있는 그리고/또는 본 기법들을 사용하여 훈련되는 모델을 구현하도록 구성될 수 있는, 실행 하드웨어를 포함한다. 용어 "실행 하드웨어"는 관련된 방법/알고리즘적 단계들을 실행하도록 구성된 하드웨어의 임의의 형태/조합을 포함한다. 실행 하드웨어는 프로그래밍가능할 수 있거나 비-프로그래밍가능할 수 있는 하나 이상의 프로세서들의 형태를 취할 수 있고, 또는 프로그래밍가능한 그리고 비-프로그래밍가능한 하드웨어의 조합이 사용될 수 있다. 적절한 프로그래밍가능 프로세서들의 예들은, CPU들, GPU들/가속기 프로세서들, 등과 같은 명령 세트 아키텍처에 근거하는 범용 프로세서들을 포함한다. 이러한 범용 프로세서들은 전형적으로, 프로세서에 결합된 혹은 프로세서의 내부에 있는 메모리 내에 보유된 컴퓨터 판독가능 명령들을 실행하고, 그리고 이러한 명령들에 따라 관련 단계들을 수행한다. 프로그래밍가능 프로세서들의 다른 형태들은 회로 설명 코드(circuit description code)를 통해 프로그래밍가능한 회로 구성을 갖는 현장 프로그래밍가능 게이트 어레이(Field Programmable Gate Array, FPGA)들을 포함한다. 비-프로그래밍가능 프로세서들의 예들은 애플리케이션 특정 집적 회로(Application Specific Integrated Circuit, ASIC)들을 포함한다. 코드, 명령들, 등은 일시적 또는 비-일시적 매체들(후자들의 예들은 솔리드 스테이트(solid state), 자기(agnetic) 및 광학(optical) 저장 디바이스(들), 등을 포함함) 상에 적절하게 저장될 수 있다. 도 1의 실행시간 스택의 서브시스템들(102 내지 108)은 테스트, 등의 상황에서 차량 보드 상에서, 또는 오프-보드 컴퓨터 시스템(off-board computer system)에서 프로그래밍가능 혹은 전용 프로세서(들), 또는 양쪽 모두의 조합에서 구현될 수 있다. 시뮬레이터(202) 및 테스트 오라클(252)과 같은, 도 2의 다양한 컴포넌트들은 프로그래밍가능 및/또는 전용 하드웨어에서 유사하게 구현될 수 있다.

Claims (16)

1. 실제 또는 시뮬레이션된 시나리오(real or simulated scenario)에서 모바일 로봇(mobile robot)에 대한 궤적 계획기(trajectory planner)의 성능을 평가하는, 컴퓨터로 구현된 방법으로서, 상기 방법은,
   상기 시나리오의 시나리오 실측 자료(scenario ground truth)를 수신하는 것과, 여기서 상기 시나리오 실측 자료는 상기 시나리오의 적어도 하나의 시나리오 요소에 응답하여 상기 시나리오의 주체 에이전트(ego agent)를 제어하기 위해 상기 궤적 계획기를 사용하여 발생되며;
   상기 시나리오에 대한 하나 이상의 성능 평가 규칙(performance evaluation rule)들 및 각각의 성능 평가 규칙에 대한 적어도 하나의 활성화 조건(activation condition)을 수신하는 것과; 그리고
   각각의 성능 평가 규칙의 활성화 조건이 상기 시나리오의 복수의 시간 단계(time step)들에 걸쳐 충족되는지 여부를 결정하기 위해 테스트 오라클(test oracle)에 의해 상기 시나리오 실측 자료를 프로세싱(processing)하는 것을 포함하고,
   각각의 성능 평가 규칙은 활성화 조건이 충족되는 경우에만 적어도 하나의 테스트 결과(test result)를 제공하기 위해 상기 테스트 오라클에 의해 평가되는 것을 특징으로 하는 방법.
2. 제1항에 있어서,
   상기 시나리오 실측 자료는, 각각의 성능 평가 규칙의 활성화 조건이 복수의 시나리오 요소들의 세트의 각각의 시나리오 요소에 대해 상기 시나리오의 복수의 시간 단계들에 걸쳐 충족되는지 여부를 결정하기 위해 프로세싱되고,
   각각의 성능 평가 규칙은, 활성화 조건이 상기 시나리오 요소들 중 적어도 하나에 대해 충족되는 경우에만, 그리고 활성화 조건이 충족되는 상기 시나리오 요소(들)와 상기 주체 에이전트 간에만, 평가되는 것을 특징으로 하는 방법.
3. 제1항 또는 제2항에 있어서,
   각각의 성능 평가 규칙은 규칙 생성 코드(rule creation code)의 단편(piece)에서 제 2 로직 술어(logic predicate)로서 인코딩(encode)되고, 활성화 조건은 규칙 생성 코드의 상기 단편에서 제 1 로직 술어로서 인코딩되며,
   각각의 시간 단계에서, 상기 테스트 오라클은, 각각의 시나리오 요소에 대해 상기 제 1 로직 술어를 평가하고, 그리고 상기 제 1 로직 술어를 충족시키는 임의의 시나리오 요소와 상기 주체 에이전트 간에만 상기 제 2 로직 술어를 평가하는 것을 특징으로 하는 방법.
4. 제1항 또는 제2항 또는 제3항에 있어서,
   상이한 각각의 활성화 조건들을 갖는 복수의 성능 평가 규칙들이 수신되고, 그리고 상이한 각각의 활성화 조건들에 따라 상기 테스트 오라클에 의해 선택적으로 평가되는 것을 특징으로 하는 방법.
5. 임의의 선행 항에 있어서,
   각각의 성능 평가 규칙은 주행 성능(driving performance)과 관련되는 것을 특징으로 하는 방법.
6. 임의의 선행 항에 있어서,
   상기 방법은, 상기 복수의 시간 단계들에 대한 각각의 결과들을 시-계열로 그래픽 사용자 인터페이스(Graphical User Interface, GUI) 상에 렌더링(rendering)하는 것을 포함하고,
   각각의 시간 단계에서의 상기 결과는 적어도 세 개의 범주들(categories) 중 하나의 범주를 시각적으로 표시하고,
   상기 적어도 세 개의 범주들은,
   활성화 조건이 충족되지 않은 경우의 제 1 범주,
   활성화 조건이 충족되고 상기 규칙이 통과(pass)되는 경우의 제 2 범주, 그리고
   활성화 조건이 충족되고 상기 규칙이 실패(fail)되는 경우의 제 3 범주를 포함하는 것을 특징으로 하는 방법.
7. 제6항에 있어서,
   상기 결과는 상기 적어도 세 개의 범주들에 대응하는 적어도 세 개의 상이한 컬러(colour)들 중 하나의 컬러로서 렌더링되는 것을 특징으로 하는 방법.
8. 임의의 선행 항에 있어서,
   상기 성능 평가 규칙들 중 제 1 성능 평가 규칙의 활성화 조건은 상기 성능 평가 규칙들 중 적어도 제 2 성능 평가 규칙의 활성화 조건에 종속되는 것을 특징으로 하는 방법.
9. 제8항에 있어서,
   상기 제 1 성능 평가 규칙은 상기 제 2 성능 평가 규칙이 활성 상태일 때 비활성화(deactivate)되는 것을 특징으로 하는 방법.
10. 제9항에 있어서,
    상기 제 2 성능 평가 규칙은 안전(safety)과 관련되고,
    상기 제 1 성능 평가 규칙은 안락(comfort)과 관련되는 것을 특징으로 하는 방법.
11. 임의의 선행 항에 있어서,
    상기 시나리오 요소들은 하나 이상의 다른 에이전트들을 포함하는 것을 특징으로 하는 방법.
12. 제11항에 있어서,
    시나리오 요소들의 상기 세트는 다른 에이전트들의 세트인 것을 특징으로 하는 방법.
13. 제2항에 종속될 때의 제11항 또는 제12항에 있어서,
    각각의 시간 단계에서, 활성화 조건이 충족되는 임의의 시나리오 요소들의 식별자를 포함하는 반복가능 객체(iterable)를 컴퓨팅(compute)하기 위해 각각의 시나리오 요소에 대한 활성화 조건이 평가되고,
    상기 성능 평가 규칙은 각각의 시간 단계에서 상기 반복가능 객체에 걸쳐 반복실행(looping)을 행함으로써 평가되는 것을 특징으로 하는 방법.
14. 제13항에 있어서,
    상기 성능 평가 규칙은 상기 시나리오 실측 자료로부터 추출된 하나 이상의 신호들에 적용되는 컴퓨팅연산 그래프(computational graph)로서 정의되며,
    상기 반복가능 객체는 활성화 조건을 충족시키는 임의의 시나리오 요소 상기 주체 에이전트 간의 상기 규칙을 평가하기 위해 상기 컴퓨팅연산 그래프를 통해 전달되는 것을 특징으로 하는 방법.
15. 임의의 선행 항의 방법을 구현하도록 구성된 하나 이상의 컴퓨터들을 포함하는 컴퓨터 시스템.
16. 임의의 선행 항의 방법을 구현하도록 컴퓨터 시스템을 프로그래밍하기 위한 실행가능한 프로그램 명령들.

Images