KR102300451B1

KR102300451B1 - Protobuf 기반 프로젝트들에 대한 일반 검증 방법

Info

Publication number: KR102300451B1
Application number: KR1020200054373A
Authority: KR
Inventors: 치안 펭; 유롱 장; 페이 왕; 유 딩; 타오 웨이
Original assignee: 바이두 유에스에이 엘엘씨
Priority date: 2019-05-14
Filing date: 2020-05-07
Publication date: 2021-09-08
Also published as: KR20200131746A; CN111949249B; US10732944B1; JP6994071B2; CN111949249A; EP3739445B1; JP2020187737A; EP3739445A1

Abstract

데이터 통신을 위해 프로토콜 버퍼들(Protobuf)을 사용하는 애플리케이션의 검증에서 검증 대체 헤더 파일을 사용하는 것에 대한 방법, 장치 및 시스템이 개시된다. 동작들은: Protobuf 정의 파일로부터 하나 이상의 Protobuf 메시지 타입들을 획득하는 동작; 상기 Protobuf 메시지 타입들에 기초하여 상기 검증 대체 헤더 파일을 생성하는 동작; 상기 검증 대체 헤더 파일로 하나 이상의 검증 스텁들을 삽입하는 동작; 애플리케이션의 소스 코드에 상기 검증 대체 헤더 파일을 포함시키는 동작; 및 상기 검증 대체 헤더 파일을 포함하는 상기 애플리케이션의 상기 검증을 수행하는 동작;을 포함한다.

Description

PROTOBUF 기반 프로젝트들에 대한 일반 검증 방법{A GENERIC VERIFICATION APPROACH FOR PROTOBUF BASED PROJECTS}

본 개시 내용의 실시예들은 일반적으로 소프트웨어 개발에 관한 것이다. 보다 구체적으로, 본 개시내용의 실시예들은 Protobuf를 사용하는 애플리케이션(application)의 검증(verification)에 검증 대체 헤더 파일(verification substitute header file)을 사용하는 것에 관한 것이다.

구글에 의해 개발된 프로토콜 버퍼들(Protocol Buffers, Protobuf)은 구조화된 데이터를 직렬화하는(serializing) 언어- 및 플랫폼-중립 방법이다. 이것은 유선을 통해 서로 통신하거나 데이터를 저장하기 위한 프로그램들 개발에 유용하다.

점점 더 많은 인공지능(AI) 어플리케이션들(예를 들어, 자율 주행 교통수단들을 작동시키기 위한 AI 프로그램들)은 Protobuf를 사용한다. 자동화된 검증 및 유효성 검사 도구들(validation tools)을 사용하는 이러한 AI 애플리케이션들의 검증 및 유효성 검사(예를 들어, 메모리 안전을 위해서)는 구글에 의해 제공되는 Protobuf 코드 생성기(code generator)와 같은, 표준 Protobuf 코드 생성기에 의해 생성되는 Protobuf 헤더 파일들의 복잡성 때문에 느릴 수 있고, 시간이 오래 걸릴 수도 있다.

본 개시의 실시예들은 예시의 수단으로서 도시되고 유사한 참조번호가 유사한 요소들을 나타내는 첨부되는 도면들에서의 도시들로 제한되지 않는다.
도 1a는 Protobuf 헤더 파일을 생성하는 프로세스(process)를 도시하는 블록 다이어그램(block diagram)이다.
도 1b는 Protobuf 정의 파일(definition file)의 예시를 나타낸다.
도 2는 일 실시예에 따라 검증 대체 헤더 파일을 생성하는 프로세스를 도시하는 블록 다이어그램이다.
도 3a는 일 실시예에 따라 Protobuf 정의 파일인 example.proto에 대응하는 예시적인 AST를 도시하는 다이어그램이다.
도 3b 및 3c는 일 실시예에 따라 도 3a에 대응하는 특정 필드들을 정의하는 데이터 구조들이다.
도 3d는 일 실시예에 따라 도 3a의 예시적인 AST에 대응하는 등가 코드(equivalent code)를 나타낸다.
도 4는 일 실시예에 따라 데이터 통신(communication)을 위해 Protobuf를 사용하는 애플리케이션의 검증에 검증 대체 헤더 파일을 사용하는 방법을 도시하는 플로우 차트(flow chart)이다.
도 5는 일 실시예에 따라 데이터 처리(processing) 시스템을 도시하는 블록 다이어그램이다.

본 발명의 다양한 실시예들 및 양상들이 아래에서 설명되는 세부사항들을 참조하여 기술될 것이며, 첨부 도면들은 다양한 실시예들을 도시할 것이다. 이후의 설명 및 도면들은 본 발명의 예시일 뿐, 본 발명을 제한하는 것으로 해석되지 않아야 한다. 본 발명의 다양한 실시예들에 대한 전반적인 이해를 제공하기 위해 다수의 구체적인 세부사항들이 기술된다. 그러나, 어떤 경우들에서, 본 발명들의 실시예들의 간결한 설명을 제공하기 위해 공지되거나 종래의 세부사항들은 기술되지 않는다.

본 명세서에서 “일 실시예” 또는 “실시예”에 대한 언급은 실시예들과 함께 기술되는 특정한 특징, 구조, 또는 특성들이 본 발명의 적어도 하나의 실시예에 포함됨을 의미한다. 본 명세서의 다양한 부분들에서 “일 실시예에서”라는 문구의 등장들은 반드시 동일한 실시예를 모두 지칭하는 것은 아니다.

일부 실시예들에 따르면, 검증 대체 헤더 파일은 데이터 통신을 위해 프로토콜 버퍼들(Protobuf)을 사용하는 애플리케이션의 검증에 사용된다. 하나 이상의 Protobuf 메시지 타입들은 Protobuf 정의 파일로부터 획득될 수 있다. Protobuf 정의 파일은 대응하는 소스 코드(source code)의 실행 동안 호출될 하나 이상의 함수들을 정의하는, Protobuf 사양(specification)과 호환된다. 검증 대체 헤더 파일은 Protobuf 메시지 타입들에 기초하여 생성되며, Protobuf의 독점 라이브러리들(proprietary libraries) 대신에, 표준 C/C++ 라이브러리를 사용하여 호출되는 하나 이상의 함수들을 검증 대체 헤더 파일이 정의한다. Protobuf의 독점 라이브러리들은 검증이 복잡하다. 하나 이상의 검증 스텁(stub)들은 검증 대체 헤더 파일에 삽입된다. 검증 대체 헤더 파일은 애플리케이션의 소스 코드에 포함된다. 이후에, 검증 대체 헤더 파일을 포함하는 애플리케이션의 검증이 수행되며, 검증 대체 헤더 파일에 기초하여 호출된 표준 C/C++ 라이브러리의 함수들의 소스 코드를 증명하는 것을 포함한다.

일 실시예에서, Protobuf 정의 파일로부터 하나 이상의 Protobuf 메시지 유형들을 얻는 단계는 Protobuf 정의 파일에 기초하여 추상 구문 트리(Abstract Syntax Tree, AST)를 생성하고 AST를 파싱(parsing)하는 단계를 포함한다. 일 실시예에서, Protobuf 메시지 유형 각각에 대한 검증 대체 헤더 파일에 C++ 클래스가 생성되고, 하나의 멤버 필드 및 대응하는 멤버 함수가 대응하는 Protobuf 메시지 유형의 필드 각각에 대해 C++ 클래스에 생성된다.

일 실시예에서, 검증 대체 헤더 파일을 포함하는 애플리케이션의 검증은 C/C++ 표준 라이브러리에 의존하여 C++ 클래스의 하나 이상의 객체들을 생성, 접근 또는 삭제한다. 일 실시예에서, 검증 스텁들은 멤버 함수와 관련된 하나 이상의 전제 조건들, 멤버 함수와 관련된 하나 이상의 사후 조건들, 또는 이들의 조합을 포함한다. 일 실시예에서, 하나 이상의 전제 조건들 및/또는 하나 이상의 사후 조건들은 커스터마이즈 가능하다(customizable). 일 실시예에서, Protobuf 메시지 유형들은 Protobuf 정의 파일에서 정의된다.

도 1a를 참고하면, Protobuf 헤더 파일을 생성하기 위한 프로세스를 나타내는 블록 다이어그램(100)이 도시된다. 개발자(developer)는 Protobuf 인터페이스 설명 언어를 사용하여 구조화된 데이터, 또는 메시지들을 Protobuf 정의 파일(110)(일반적으로 파일 이름 확장자가 .proto 임)에서 정의한다. 이하에서 Protobuf 정의 파일(110)은 단순히 프로토 파일로 지칭될 수도 있다. Protobuf 정의 파일(110)은 Google에 의해 정의된 Protobuf 라이브러리들의 세트와 연관된, Protobuf 사양과 호환된다. Protobuf 코드 생성기(120)는 Protobuf 정의 파일(110)에 기초하여 하나 이상의 Protobuf 헤더 파일들(130)을 생성한다. 표준 Protobuf 코드 생성기(120)는 Google로부터 사용 가능할 수 있다. 예를 들어, C/C++ 언어를 사용하여, Protobuf 코드 생성기 (120)는 Protobuf 정의 파일(110)로부터 헤더 파일(확장명이 .pb.h 인) 및 구현 파일(implementation file)(확장명이 .pb.cc 인)을 생성한다. 그 후, 헤더 파일들(130)은 개발자에 의해 애플리케이션에 포함될 수 있으며, 이는 애플리케이션이 Protobuf 정의 파일(110)에 포함된 메시지 타입 정의에 따라 Protobuf 메시지들을 읽고 쓸 수 있게 한다.

예시의 목적으로, example.proto라는 이름의 간단한 예시 Protobuf 정의 파일(110)이 도 1b에 제공된다. 이 예시에서 example.proto 파일은 MsgType1 및 MsgType2의 두 가지 메시지 유형들을 정의하며, 여기서 MsgType1은 필수 32 비트 정수 값을 포함하고, MsgType2는 필수 Boolean 값을 포함한다.

이 명세서 끝 부분의 부록 A에 나열된 example.pb.h 헤더 파일은 도 1b에 도시되는 example.proto 정의 파일을 기초하여 Google의 표준 Protobuf 코드 생성기에서 생성한 예시 헤더 파일이다. 검증 프로세스는 Google의 Protobuf 라이브러리들을 조사하고 그리고 대응하는 함수들을 검증해야 하기 때문에, example.pb.h 헤더 파일은 확인 프로세스와 관련된 워크로드(workload)를 크게 증가시킬 수 있는, Protobu의 Google의 구현으로부터의 독점 라이브러리들(예를 들어, 헤더 파일들이 1 내지 7행에 나열된 라이브러리들)에 크게 의존하는 것을 볼 수 있다.

점점 더 많은 인공 지능(AI) 애플리케이션들(예를 들어, 자율 주행 차량들에 대한 AI 프로그램들)이 Protobuf를 사용하고 있다. 자동화된 검증 및 검증 도구들을 사용하는 이러한 AI 애플리케이션들의 검증 및 승인(예를 들어, 메모리 안전성에 대한)은 표준 Protobuf 코드 생성기에 의해 생성된 Protobuf 헤더 파일들의 복잡성으로 인해 느리고 시간이 오래 걸릴 수 있다. 특히, 표준 Protobuf 코드 생성기에 의해 생성된 Protobuf 헤더 파일들은 표준 Protobuf 라이브러리들의 데이터 구조들로 생성되었기 때문에 복잡하다. 따라서, 검증 및 승인될 애플리케이션에 표준 Protobuf 코드 생성기에 의해 생성된 Protobuf 헤더 파일들을 포함시키는 것은 검증 및 인증 프로세스를 불필요하게 느려지게 할 수도 있다.

도 2를 참고하면, 일 실시예에 따른 검증 대체 헤더 파일을 생성하는 프로세스를 나타내는 블록 다이어그램(200)이 도시되어 있다. AST(Abstract Syntax Tree) 생성기(210)는 Protobuf 정의 파일(110)에 정의된 메시지 타입들을 기술하는 AST를 생성하기 위해 Protobuf 정의 파일(110)을 분석한다. AST 파서(parser)(220)는 모든 Protobuf 메시지 타입들을 얻기 위해 Protobuf 메시지 유형 각각의 모든 필드들을 포함하여 AST를 파스(parse)한다. 이렇게 획득된 Protobuf 메시지 타입들은 AST가 생성되는 것에 기초하여 Protobuf 정의 파일(110)에 정의된 것과 일치할 것임을 이해해야 한다.

Protobuf 메시지 타입들이 획득되면, 검증 코드 생성기(230)는 Protobuf 메시지 타입들에 기초하여 하나 이상의 C++ 클래스들을 생성한다. 특히, 각 Protobuf 메시지 유형마다 하나 이상의 C++ 클래스가 생성됩니다. Protobuf 메시지 타입의 각 필드에 대해, 검증 코드 생성기(230)는 Protobuf 메시지 타입에 대응하는 C++ 클래스의 멤버 필드에 접근하기 위한 멤버 함수뿐만 아니라 멤버 필드를 생성한다. 데이터 멤버들 및 함수 멤버들을 포함한 C++ 클래스들은 검증 대체 헤더 파일(250)에 저장된다.

또한, 검증 대체 헤더 파일(250)이 검증될 수 있도록, 검증 스텁 생성기(240)는 검증 스텁들을 검증 대체 헤더 파일(250)에 추가한다. 검증 스텁들은 메모리 안전 등을 보증하기 위한 하나 이상의 멤버 함수에 대한 전제 조건들 및/또는 사후 조건들을 포함한다. 예를 들어, 전제 조건들은 다음을 포함할 수도 있다: 1) 함수의 입력 매개 변수가 포인터인 경우, 이는 NULL 포인터가 아니어야 하고; 그리고, 2) 함수의 입력 매개 변수는 각 기본 유형의 범위(예를 들어, 정수, 플로트(float), 더블(double) 등과 같은 기본 유형들은 정의된 범위들을 가짐)를 초과하지 않아야 한다. 다른 실시예에서, 예시적인 전제 조건은 입력 값이 특정 범위 내에 있어야 한다는 것일 수도 있다. 사후 조건의 한 예시는 출력 값이 특정 범위 내에 있어야 한다는 것일 수도 있다. 본 명세서에 설명된 예시적인 전제 조건들 및 사후 조건들은 본 개시를 제한하지 않는다. 다른 실시예들에서, 전제 조건들 및 사후 조건들은 상이한 방식들로 커스터마이징 될 수도 있다. 추가적으로, 전제 조건들 및 사후 조건들은 임의의 적합한 포멧(format)으로 정의될 수 있다. 일 실시예에서, ANSI/ISO C Specification Language(ACSL)는 전제 조건들 및 사후 조건들을 정의하기 위해 사용된다.

따라서, 표준 C++ 클래스들이 사용되기 때문에, 검증 헤더 대체 파일(250)이 검증 및 인증하는 경우에 애플리케이션에 포함되는 경우, C/C++ 표준 라이브러리(예를 들어, stdlibC++)만이 객체들을 생성, 접근 또는 삭제하는데 의존할 것이며, 검증 및 인증하는 경우에 보다 복잡한 Protobuf 특정 코드, 함수들 및 라이브러리들은 사용되지 않는다.

전술한 example.proto 정의 파일에 대응하는 verify_example.h라는 검증 대체 헤더 파일(250)의 예시는 설명의 목적으로 이 명세서의 끝에 있는 부록 B에 제공된다. 부록 A의 example.pb.h 헤더 파일과 비교하면 각 메시지 타입에 대해 필요한 모든 방법들이 크게 단순화되었음을 볼 수 있다. 전제 조건들 및 사후 조건들과 관련된 확인 검사들이 매개 변수들로 함수들에 추가된다. 특히, 포인터 체크(pointer check)가 포인터들을 인수로 가지는 함수들에 추가된다. 예를 들어, 부록 B의 46 내지 47 행에 도시되는 바와 같이, 검증 서브(verification sub) "

"가 삽입된다. 비슷하게, 81행은 변수 "from"의 검증을 요구하는 반면에 86행은 변수 "other"의 검증을 요구한다. 이러한 검증 스텁은 변수 "x"가 유효한 포인터인지 검증하도록 검증 프로세스에 지시한다. 확인에 실패하는 경우(예를 들어, 포인터 x가 유효하지 않은 포인터) 사용자에게 알리는 경고가 생성될 수도 있다. 조건은 ACSL 포맷을 따른다. 따라서, 검증 프로세스는 조건들이 충족되는지 자동으로 확인하고 검증할 것이다. Protobuf 정의 파일에 기초하여 AST를 생성하는 것은 당업자의 기술들 내에 있다.

도 3a를 참고하면, example.proto 정의 파일에 대응하는 AST(300)의 예시가 도시되어 있다. AST(300)는 Protobuf 정의 파일 이름 ("1: example.proto"), 패키지 이름("2 : test") 및 2개의 정의된 메시지 타입들(예를 들어, MsgType1 및 MsgType2)(노드들 "3:1": 두 메시지 타입들 모두 1 필드; 노드 "4:2": 두 메시지 유형들 모두 "필수" 레이블; 노드들 "5:5" 및 "5:8": 필드 유형은 각각 int32 및 bool이다.)과 관련된 정보를 포함한다. 키-값 페어들과 유사하게, 일 실시예에 따르면, 키들(예를 들어, 도 3b에 도시된 필드 ID들) 및 관련 값들(예를 들어, 도 3c에 도시된 필드 타입들)을 나타내는 것을 열거하는데 숫자들이 이용된다. AST 파서는 모든 Protobuf 메시지 타입들을 얻기 위해 하여 Protobuf 메시지 타입들 각각의 모든 필드들을 포함하여 AST를 파스할 수도 있다. AST의 등가 코드 표시는 설명의 목적으로 도 3d에 제공된다.

도 4를 참고하면, 데이터 통신을 위해 Protobuf를 사용하는 애플리케이션의 검증에서 검증 대체 헤더 파일을 이용하기 위한 방법(400)을 나타내는 플로우 차트가 도시되어 있다. 방법(400)은 하드웨어, 소프트웨어 또는 이들의 조합으로 구현될 수 있다. 블록 (410)에서, 하나 이상의 Protobuf 메시지 타입들은 Protobuf 정의 파일(예를 들어, Protobuf 호환 정의 파일)에 기초하여 획득된다. 블록 (420)에서, 검증 대체 헤더 파일은 표준 C/C++ 헤더 파일들과 호환되는, Protobuf 메시지 타입들에 기초하여 생성된다. 블록 (430)에서, 하나 이상의 검증 스텁들이 검증 대체 헤더 파일에 추가된다. 블록 (440)에서, 검증 대체 헤더 파일이 애플리케이션의 소스 코드에 포함된다. 블록 (450)에서, 검증 대체 헤더 파일을 포함하는 애플리케이션의 검증은 Protobuf의 독점 라이브러리들을 검증할 필요없이 오직 표준 C/C++ 라이브러리들을 검증함으로써 수행된다.

참고로, 위에서 도시되고 설명된 바와 같은 구성 요소들 중 일부 또는 전부는 소프트웨어, 하드웨어 또는 이들의 조합으로 구현될 수 있다. 예를 들어, 이러한 구성 요소들은 프로세서(미도시)에 의해 메모리에 로드 및 실행되어 본 출원 전체에 걸쳐 기술된 프로세스들 또는 동작들을 수행하기 위해 프로세서에 의해 메모리에 로딩되고 실행될 수 있는, 영구 저장 장치에 설치 및 저장된 소프트웨어로서 구현될 수 있다. 대안적으로, 이러한 구성 요소들은 집적 회로(예를 들어, 애플리케이션 특정 IC 또는 ASIC), 디지털 신호 프로세서 (DSP) 또는 필드 프로그래머블 게이트 어레이(field programmable gate array)(FPGA)와 같은 전용 하드웨어에 프로그래밍 되거나 임베디드(embedded)되는 실행 코드로서 구현될 수 있고, 이는 응용 프로그램에서 해당 드라이버 및/또는 운영 체제를 통해 접근할 수 있다. 또한, 이러한 구성 요소들은 하나 이상의 특정 명령들을 통해 소프트웨어 구성 요소에 의해 접근 가능한 명령 세트의 일부로서 프로세서 또는 프로세서 코어에서 특정 하드웨어 로직으로서 구현될 수 있다.

일부 실시예들은 C++ 프로그래밍 언어를 참조하여 설명되었지만, 프로그래밍 언어는 본 개시를 제한하지 않으며, 본 개시의 실시예들은 본 개시의 범위를 벗어나지 않고 다른 프로그래밍 언어들에 적용될 수 있음을 이해해야 한다.

도 5는 본 개시의 일 실시예에 따라 데이터 처리 시스템(data processing system)을 도시한 블록 다이어그램이다. 예를 들어, 시스템(1500)은 예를 들어, 상술한 클라이언트 디바이스 또는 서버와 같은(예를 들어, 상술한 바와 같이 도 2의 AST 생성기(210), AST 파서(220), 검증 코드 생성기(230), 및 검증 스텁 생성기(240)와 같은), 상술한 임의의 프로세스들 또는 방법들을 수행하는 상술한 임의의 데이터 처리 시스템들을 표시할 수도 있다. 시스템(1500)은 다수의 상이한 구성 요소들을 포함할 수 있다. 이러한 구성 요소들은 집적 회로(IC), 그들의 일부, 개별 전자 디바이스, 컴퓨터 시스템의 애드-인(add-in)카드 또는 마더보드(motherboard)와 같이 회로 보드에 적합한 다른 모듈들, 또는 컴퓨터 시스템의 전체 구조(chassis) 내에 달리 포함된 구성 요소들로서 구현될 수 있다.

참고로, 또한 시스템(1500)은 컴퓨터 시스템의 많은 구성 요소들의 높은 레벨의 뷰(view)를 나타내도록 의도된다. 그러나, 추가적인 구성 요소들이 특정 구현들에 존재할 수도 있으며, 나아가, 도시되는 구성 요소들의 상이한 배열이 다른 구현들에서 발생할 수도 있음을 이해하여야 한다. 시스템(1500)은 데스크탑, 랩탑, 태블릿, 서버, 모바일 폰, 미디어 플레이어(media player), 개인 휴대 정보 단말기(PDA), 스마트 워치, 개인 통신기(communicator), 게임 디바이스, 네트워크 라우터(router)또는 허브, 무선 접근 포인트(AP) 또는 리피터(repeater), 셋-탑(set-top) 박스, 또는 이들의 조합을 표시할 수 있다. 또한, 단일 기기(machine) 또는 시스템만이 도시되어 있지만, 용어 "기기" 또는 "시스템"은 마찬가지로 본 명세서에서 논의된 임의의 하나 이상의 방법론들을 수행하기 위한 명령들의 한 세트를 개별적 또는 공동적으로 실행하는 기기들 또는 시스템들의 임의의 집합을 포함하는 것으로 간주되어야 한다.

일 실시예에서, 시스템(1500)은 버스 또는 인터커넥트(interconnect)(1510)를 통해 연결된 프로세서(1501), 메모리(1503) 및 디바이스들(1505-1508)을 포함한다. 프로세서(1501)는 단일 프로세서 또는 단일 프로세서 코어 또는 다중 프로세서 코어가 포함된 다중 프로세서들을 표시할 수도 있다. 프로세서(1501)는 마이크로 프로세서, 중앙 처리 디바이스(CPU) 등과 같은 하나 이상의 범용 프로세서를 나타낼 수 있다. 보다 구체적으로, 프로세서 (1501)는 복합 명령어 집합 컴퓨팅 (CISC) 마이크로 프로세서, 축소 명령어 집합 컴퓨팅 (RISC) 마이크로 프로세서, 훨씬 긴 명령어 워드 (VLIW) 마이크로 프로세서, 또는 다른 명령어 세트들을 구현하는 프로세서, 또는 명령어 세트들의 조합을 구현하는 프로세서들 일 수 있다. 프로세서(1501)는 또한, ASIC (application specific integrated circuit), 셀룰러(cellular) 또는 기저 대역 프로세서(baseband processor), FPGA (Field Programmable Gate Array), DSP (Digital Signal Processor), 네트워크 프로세서, 그래픽 프로세서, 통신 프로세서, 암호화 프로세서, 코-프로세서(co-processeor), 임베디드 프로세서, 또는 명령어들의 처리가 가능한 임의의 다른 유형의 로직과 같은, 하나 이상의 특수-목적(special-purpose) 프로세서들일 수 있다.

초-저전압(ultra-low voltage) 프로세서와 같은 저전력 멀티-코어 프로세서 소켓(socket)일 수도 있는 프로세서(1501)는 시스템의 다양한 구성 요소들과 통신하기 위한 메인 처리 유닛 및 중앙 허브로서 작동할 수도 있다. 이러한 프로세서는 SoC(system on chip)으로서 구현될 수 있다. 프로세서(1501)는 본 명세서에서 논의된 동작들 및 단계들을 수행하기 위한 명령들을 실행하도록 구성된다. 시스템(1500)은 디스플레이 컨트롤러, 그래픽 프로세서 및/또는 디스플레이 디바이스를 포함할 수 있는, 선택적인 그래픽 서브시스템(optional graphics subsystem)(1504)과 통신하는 그래픽 인터페이스를 더 포함할 수도 있다.

프로세서(1501)는 일 실시예에서 주어진 양의 시스템 메모리를 제공하기 위해 다수의 메모리 디바이스들을 통해 구현될 수 있는 메모리(1503)와 통신할 수 있다. 메모리 (1503)는 랜덤 액세스 메모리 (RAM), 동적 RAM (DRAM), 동기식 DRAM (SDRAM), 정적 RAM (SRAM), 또는 다른 유형들의 저장 디바이스들과 같은 하나 이상의 휘발성 저장(volatile storage)(또는 메모리) 디바이스들을 포함할 수 있다. 메모리 (1503)는 프로세서 (1501) 또는 임의의 다른 디바이스에 의해 실행되는 명령들의 시퀀스들을 포함하는 정보를 저장할 수도 있다. 예를 들어, 다양한 운영 체제들, 디바이스 드라이버들, 펌웨어(예를 들어, 입력 출력 기본 시스템 또는 BIOS), 및/또는 애플리케이션의 실행가능 코드 및/또는 데이터들은 메모리(1503)에 로딩되고 프로세서(1501)에 의해 실행될 수 있다. 운영 체제는, 예를 들어, Robot Operating System (ROS), Microsoft®의 Windows® 운영 체제, Apple의 Mac OS®/iOS®, Google의 Android®, LINUX, UNIX 또는 리얼-타임(real-time) 또는 임베디드 운영 체제들과 같은, 임의의 종류의 운영 체제들일 수 있다.

시스템(1500)은 네트워크 인터페이스 디바이스(들)(1505), 선택적인 입력 디바이스 (들)(1506) 및 다른 선택적인 IO 디바이스(들)(1507)를 포함하는 디바이스들(1505-1508)과 같은 IO 디바이스들을 더 포함할 수 있다. 네트워크 인터페이스 디바이스(1505)는 무선 트랜시버 및/또는 네트워크 인터페이스 카드(NIC)를 포함할 수도 있다. 무선 트랜시버(transceiver)는 WiFi 트랜시버, 적외선 트랜시버, 블루투스 트랜시버, WiMax 트랜시버, 무선 셀룰러 전화 트랜시버, 위성 트랜시버 (예를 들어, GPS (Global Positioning System) 트랜시버), 또는 다른 라디오 주파수(RF) 트랜시버 또는 이들의 조합일 수도 있다. NIC는 이더넷 카드(Ethernet card)일 수도 있다.

입력 디바이스(들)(1506)은 마우스, 터치 패드, 터치 감지 스크린(디스플레이 디바이스(1504)와 통합될 수도 있는), 스타일러스(stylus)와 같은 포인터 디바이스, 및/또는 키보드(예를 들어, 물리적 키보드 또는 터치 감지 스크린의 일부분으로 디스플레이된 가상 키보드)일 수도 있다. 예를 들어, 입력 디바이스(1506)는 터치 스크린에 연결된 터치 스크린 컨트롤러를 포함할 수도 있다. 터치 스크린 및 터치 스크린 컨트롤러는, 예를 들어, 터치 스크린과 하나 이상의 접촉점을 결정하기 위한 다른 근접 센서 어레이들 또는 다른 요소들뿐 아니라, 용량성, 저항성, 적외선 및 표면 탄성파(surface acoustic wave) 기술들을 포함하지만 이에 제한 되지 않는, 복수의 터치 감지 기술들 중 임의의 것을 사용하여 발생되는 접촉 및 움직임 또는 이의 중단(brake)을 감지할 수 있다.

IO 디바이스들(1507)은 오디오 디바이스를 포함할 수도 있다. 오디오 디바이스는 음성 인식, 음성 복제, 디지털 기록, 및/또는 전화 기능들과 같은, 음성-가능(voice-enabled) 기능들을 용이하게 하는 스피커 및/또는 마이크로폰을 포함할 수도 있다. 다른 IO 디바이스들(1507)은 범용 직렬 버스(USB) 포트(들), 병렬 포트(들), 직렬 포트(들), 프린터, 네트워크 인터페이스, 버스 브리지 (예를 들어, PCI-PCI 브리지), 센서(들)(예를 들어, 가속도계, 자이로스코프, 자기력계(magnetometer), 광 센서, 나침반, 근접 센서 등과 같은 모션 센서) 또는 이들의 조합을 더 포함할 수도 있다. 디바이스들(1507)은, 사진들 및 비디오 클립들을 녹화하는 것과 같은 카메라 기능들을 용이하게 하기 위해 이용되는 고체촬상소자(charged coupled device, CCD) 또는 상보성 금속산화물 반도체 (complementary metal-oxide semiconductor, CMOS) 광학 센서와 같은 광학 센서를 포함할 수도 있는 이미징 처리 서브 시스템(예를 들어, 카메라)을 더 포함할 수 있다. 특성 센서들은 센서 허브(도시되지 않은)를 통해 인터커넥트(interconnect)(1510)에 연결될 수 있으며, 반면에, 키보드 또는 열 센서와 같은 다른 디바이스들은 시스템(1500)의 특정 구성 또는 설계에 따라 임베디드된 컨트롤러(미도시)에 의해 제어될 수도 있다.

데이터, 애플리케이션들, 하나 이상의 운영 체제들과 같은 정보의 영구 저장을 제공하기 위해, 대용량 저장소(mass storage)(미도시) 또한, 프로세서(1501)에 결합될 수도 있다. 다양한 실시예들에서, 시스템 응답성을 향상시킬 뿐 아니라, 더 얇고 더 가벼운 시스템 설계가 가능하도록, 이러한 대용량 저장소는 솔리드 스테이트 디바이스(solid state device, SSD)를 통해 구현될 수도 있다. 그러나, 다른 실시예들에서, 전원 차단 이벤트들 동안에 컨텍스트 상태(context state) 및 다른 기타 정보의 비-휘발성 저장이 가능하여 시스템 활동들의 재시작에 빠른 전원 공급이 가능하도록 하는 SSD 캐시로서 작동하는 적은 양의 SSD 저장소를 가지는 하드 디스크 드라이브(HDD)를 사용하여 대용량 저장소가 주로 구현될 수도 있다. 또한, 플래시 디바이스는 예를 들어, 직렬 주변 디바이스 인터페이스(SPI)를 통해 프로세서(1501)에 연결될 수도 있다. 이러한 플래시 디바이스는 시스템의 다른 펌웨어뿐만 아니라, BIOS를 포함하여 시스템 소프트웨어의 비-휘발성 저장을 제공할 수도 있다.

저장 디바이스(1508)는 본 명세서에서 기술된 임의의 하나 이상의 방법론들 또는 기능들을 구현하는 명령들 또는 소프트웨어의 하나 이상의 세트들(예를 들어, 모듈, 유닛, 및/또는 로직(1528))이 저장된 컴퓨터-접근가능한 저장 매체(1509)(또한, 기기-판독 가능 저장 매체 또는 컴퓨터-판독 가능 매체라고도 하는)를 포함할 수도 있다. 처리 모듈/유닛/로직(1528)은 예를 들어, AST 생성기(210), AST 파서(220), 검증 코드 생성기(230), 및 검증 스텁 생성기(240)와 같은 전술된 임의의 구성 요소들을 나타낼 수도 있다. 처리 모듈/유닛/로직(1528)은 데이터 처리 시스템(1500), 메모리(1503) 및, 기기-접근가능한 저장 매체를 구성하기도 하는 프로세서(1501)에 의해 실행 동안 메모리(1503) 내에 그리고/또는 프로세서(1501) 내에 완전히 또는 적어도 부분적으로 존재할 수 있다. 처리 모듈/유닛/로직(1528)은 추가로 네트워크 인터페이스 디바이스(1505)를 통해 네트워크를 통해 송신되거나 또는 수신될 수도 있다.

컴퓨터-판독 가능 저장 매체(1509)는 또한, 전술한 일부 소프트웨어 기능들을 영구적으로 저장하는데 사용될 수도 있다. 컴퓨터-판독 가능 저장 매체(1509)가 예시적인 실시예에서 단일 매체인 것으로 도시되어 있지만, "컴퓨터-판독 가능 저장 매체"라는 용어는 단일 매체 또는 하나 이상의 명령어들의 세트들을 저장하는 다중 매체(예를 들어, 중앙 또는 분산 데이터베이스, 및/또는 관련된 캐시들 및 서버들)를 포함하는 것으로 간주되어야 한다. "컴퓨터-판독 가능 저장 매체"라는 용어는 또한, 기기에 의해 실행되는 명령들의 세트를 저장 또는 인코딩할 수 있고, 기기가 본 개시의 방법론들 중 임의의 하나 이상을 수행하게 하는 임의의 매체를 포함하는 것으로 간주되어야 한다. 따라서, "컴퓨터-판독 가능 저장 매체"라는 용어는 솔리드-스테이트 메모리, 및 광학 및 자기 매체, 또는 임의의 다른 비-일시적 기기-판독 가능 매체를 포함하지만 이에 제한되지는 않는다.

본 명세서에 기술된 처리 모듈/유닛/로직(1528), 구성요소들 및 다른 특징들은 이산 하드웨어 구성 요소들(discrete hardware components)로서 구현되거나 ASICS, FPGA, DSP 또는 유사한 디바이스들과 같은 하드웨어 구성 요소들의 기능에 통합될 수 있다. 추가적으로, 처리 모듈/유닛/로직(1528)은 하드웨어 디바이스 내에서 펌웨어 또는 기능 회로로서 구현될 수 있다. 또한, 처리 모듈/유닛/로직(1528)은 하드웨어 디바이스들 및 소프트웨어 구성요소들의 임의의 조합으로 구현될 수 있다.

참고로, 시스템(1500)이 데이터 처리 시스템의 다양한 구성 요소들로 도시되어 있지만, 구성 요소들을 상호 연결하는 임의의 특정 아키텍처(architecture) 또는 방식을 나타내도록 의도되지 않았으며; 이러한 세부 사항들은 본 개시의 실시예들과 밀접한 관련이 없다. 또한, 더 적은 구성 요소들 또는 아마도 더 많은 구성 요소들을 가지는 다른 데이터 처리 시스템들, 서버들, 모바일 폰들, 소형 컴퓨터들(handheld computers), 및/또는 네트워크 컴퓨터들이 또한 본 개시의 실시예들과 사용될 수도 있음이 이해될 것이다.

전술한 상세한 설명들의 몇몇 부분들은 컴퓨터 메모리 내의 데이터 비트들에 대한 동작들의 알고리즘 및 상징적 표시들의 관점에서 제시되고 있다. 이러한 알고리즘적 설명들 및 표시들은 데이터 처리 분야의 당업자들이 그들의 작업 내용을 다른 당업자들에게 가장 효과적으로 전달하기 위해 사용되는 방식들이다. 여기서, 알고리즘은 일반적으로, 원하는 결과를 도출하는 일관된 동작들의 시퀀스인 것으로 생각될 수 있다. 동작들은 이러한 물리적 수량들의 물리적 조작들이 요구된다.

그러나, 이들 및 유사한 용어들은 모두 적절한 물리적 수량들과 관련되어야 하며, 이들 수량들에 적용되는 단지 편리한 레이블들일 뿐임을 명심해야 한다. 상기 논의로부터 명백하게 달리 구체적으로 언급되지 않는 한, 설명 전반에 걸쳐, 아래의 청구 범위들에 제시된 것과 같은 용어들을 이용하는 논의들은, 컴퓨터 시스템의 레지스터들 및 메모리들 내의 물리적(전기적) 수량들로 표시된 데이터를 컴퓨터 시스템 메모리들 또는 레지스터들 또는 다른 그러한 정보 저장, 전송 또는 디스플레이 디바이스들 내의 물리적 수량들로 유사하게 표시되는 다른 데이터로 조작 및 변환하는, 컴퓨터 시스템 또는 유사한 전자 컴퓨팅 디바이스의 작동 및 프로세스들을 의미하는 것으로 이해된다.

본 개시의 실시예들은 또한 본 명세서의 동작들을 수행하기 위한 장치에 관한 것이다. 이러한 컴퓨터 프로그램은 비-일시적 컴퓨터 판독 가능 매체에 저장된다. 기기 판독 가능 매체는 기기(예를 들어, 컴퓨터)에 의해 판독 가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함한다. 예를 들어, 기기 판독 가능 (예를 들어, 컴퓨터 판독 가능) 매체는 기기(예를 들어, 컴퓨터) 판독 가능 저장 매체 (예를 들어, 읽기 전용 메모리 (read only memory, "ROM"), 랜덤 액세스 메모리(random access memory, "RAM"), 자기 디스크 저장 매체(magnetic disk storage media), 광 저장 매체(optical storage media), 플래시 메모리 장치들(flash memory devices))를 포함한다..

전술한 도면들에 도시된 프로세스들 또는 방법들은 하드웨어(예를 들어, 회로, 전용 로직 등), 펌웨어, 소프트웨어 (예를 들어, 비 일시적 컴퓨터 판독 가능 매체에 구현되는) 또는 이들의 조합을 포함하는 처리 로직에 의해 수행될 수도 있다. 프로세스들 또는 방법들이 몇몇 순차적 동작들과 관련하여 위에서 설명되었음에도, 설명된 동작들 중 몇몇은 다른 순서로 수행될 수도 있음을 이해해야 한다. 또한, 몇몇 동작들은 순차적이 아닌 병렬로 수행될 수도 있다.

본 개시의 실시예들은 임의의 특정 프로그래밍 언어를 참조하여 설명되지 않는다. 본 명세서에 기술된 바와 같이 본 개시의 실시예들의 교시들(teachings)을 구현하기 위해 다양한 프로그래밍 언어들이 사용될 수도 있음을 이해할 것이다.

전술한 명세서에서, 본 개시의 실시예들은 특정 예시적인 실시예들을 참고하여 설명되었다. 다음의 청구 범위들에 기재된 본 개시의 더 넓은 사상 및 범위를 벗어나지 않고 다양한 변형들이 이루어질 수 있음이 명백할 것이다. 따라서, 명세서 및 도면들은 제한적인 의미보다는 예시적인 의미로 간주되어야 한다.

부록 A

example.pb.h

부록 B

verification.example.h

Claims

데이터 통신(communication)을 위한 프로토콜 버퍼들(Protocol Buffers, Protobuf)을 사용하는 애플리케이션(application)의 검증에 검증 대체 헤더 파일(verification substitute header file)을 사용하기 위한 컴퓨터-구현 방법으로서,
Protobuf의 사양(specification)에 따라 하나 이상의 함수들의 제 1 세트를 정의(define)하는 Protobuf 정의 파일로부터 하나 이상의 Protobuf 메시지 타입들(message types)을 획득하는 단계 - 상기 제 1 세트의 상기 함수들은 Protobuf 라이브러리들의 세트를 호출함. - ;
상기 Protobuf 메시지 타입들에 기초하여 상기 검증 대체 헤더 파일을 생성하는 단계 - 상기 검증 대체 헤더 파일은 표준(standard) C/C++ 프로그래밍 언어에 따라 하나 이상의 함수들의 제 2 세트를 정의하고, 상기 제 2 세트의 상기 함수들은 표준 C/C++ 라이브러리들의 세트를 호출함. - ;
상기 검증 대체 헤더 파일로 하나 이상의 검증 스텁들(stubs)을 삽입하는 단계 - 상기 검증 스텁들은 멤버 함수와 관련된 하나 이상의 전제 조건들(preconditions), 상기 멤버 함수와 관련된 하나 이상의 사후 조건들(postconditions), 또는 이들의 조합을 포함함 -; 및
상기 Protobuf 라이브러리들의 세트를 검증할 필요가 없는 상기 표준 C/C++ 라이브러리들의 세트에 기초하여 상기 검증 대체 헤더 파일을 포함하는 상기 애플리케이션의 상기 검증을 수행하는 단계;
를 포함하는,
컴퓨터-구현 방법.
제 1 항에 있어서,
상기 Protobuf 정의 파일로부터 상기 하나 이상의 Protobuf 메시지 타입들을 획득하는 단계는,
상기 Protobuf 정의 파일에 기초하여 추상 구문 트리(abstract syntax tree, AST)를 생성하는 단계 및 상기 AST을 파스(parse)하는 단계를 포함하는,
컴퓨터-구현 방법.
제 1 항에 있어서,
상기 Protobuf 메시지 타입 각각에 대해 상기 검증 대체 헤더 파일에 C++ 클래스(class)가 생성되고, 그리고 대응되는 상기 Protobuf 메시지 타입의 필드 각각에 대해 상기 C++ 클래스에 하나의 멤버 필드(member field) 및 대응되는 상기 멤버 함수가 생성되는,
컴퓨터-구현 방법.
제 3 항에 있어서,
상기 애플리케이션의 상기 검증은 상기 C++ 클래스의 하나 이상의 객체들(objects)을 생성, 접근, 또는 삭제하도록, C/C++ 표준 라이브러리에 의존하는 상기 검증 대체 헤더 파일을 포함하는,
컴퓨터-구현 방법.
제 1 항에 있어서,
상기 하나 이상의 전제 조건들 또는 상기 하나 이상의 사후 조건들 중 적어도 하나는 커스텀 가능한(customizable),
컴퓨터-구현 방법.
제 1 항에 있어서,
상기 Protobuf 메시지 타입들은 상기 Protobuf 정의 파일에서 정의되는,
컴퓨터-구현 방법.
프로세서에 의해 실행될 경우, 상기 프로세서가 데이터 통신을 위해 프로토콜 버퍼들(Protobuf)을 사용하는 애플리케이션의 검증에서 검증 대체 헤더 파일을 사용하기 위한 동작들을 수행하도록 하는 명령들이 저장된 비-일시적 기기-판독가능 매체로서, 상기 동작들은:
Protobuf의 사양에 따라 하나 이상의 함수들의 제 1 세트를 정의하는 Protobuf 정의 파일로부터 하나 이상의 Protobuf 메시지 타입들을 획득하는 동작 - 상기 제 1 세트의 상기 함수들은 Protobuf 라이브러리들의 세트를 호출함 - ;
상기 Protobuf 메시지 타입들에 기초하여 상기 검증 대체 헤더 파일을 생성하는 동작 - 상기 검증 대체 헤더 파일은 표준 C/C++ 프로그래밍 언어에 따라 하나 이상의 함수들의 제 2 세트를 정의하고, 상기 제 2 세트의 상기 함수들은 표준 C/C++ 라이브러리들의 세트를 호출함 - ;
상기 검증 대체 헤더 파일로 하나 이상의 검증 스텁들을 삽입하는 동작 - 상기 검증 스텁들은 멤버 함수와 관련된 하나 이상의 전제 조건들(preconditions), 상기 멤버 함수와 관련된 하나 이상의 사후 조건들(postconditions), 또는 이들의 조합을 포함함 - ; 및
상기 Protobuf 라이브러리들의 세트를 검증할 필요가 없는 상기 표준 C/C++ 라이브러리들의 세트에 기초하여 상기 검증 대체 헤더 파일을 포함하는 상기 애플리케이션의 상기 검증을 수행하는 동작;
을 포함하는,
비-일시적 기기-판독가능 매체
제 7 항에 있어서,
상기 Protobuf 정의 파일로부터 상기 하나 이상의 Protobuf 메시지 타입들을 획득하는 동작은,
상기 Protobuf 정의 파일에 기초하여 추상 구문 트리(AST)를 생성하는 동작 및 상기 AST을 파스하는 동작을 포함하는,
비-일시적 기기-판독가능 매체
제 7 항에 있어서,
상기 Protobuf 메시지 타입 각각에 대해 상기 검증 대체 헤더 파일에 C++ 클래스가 생성되고, 그리고 대응되는 상기 Protobuf 메시지 타입의 필드 각각에 대해 상기 C++ 클래스에 하나의 멤버 필드 및 대응되는 상기 멤버 함수가 생성되는,
비-일시적 기기-판독가능 매체.
제 9 항에 있어서,
상기 애플리케이션의 상기 검증은 상기 C++ 클래스의 하나 이상의 객체들을 생성, 접근, 또는 삭제하도록, C/C++ 표준 라이브러리에 의존하는 상기 검증 대체 헤더 파일을 포함하는,
비-일시적 기기-판독가능 매체.
제 7 항에 있어서,
상기 하나 이상의 전제 조건들 또는 상기 하나 이상의 사후 조건들 중 적어도 하나는 커스텀 가능한,
비-일시적 기기-판독가능 매체.
제 7 항에 있어서,
상기 Protobuf 메시지 타입들은 상기 Protobuf 정의 파일에서 정의되는,
비-일시적 기기-판독가능 매체.
데이터 처리(data processing) 시스템에 있어서,
프로세서; 및
상기 프로세서에 의해 실행되는 경우, 상기 프로세서로 하여금 데이터 통신을 위해 프로토콜 버퍼들(Protobuf)을 사용하는 애플리케이션의 검증에서 검증 대체 헤더 파일을 사용하기 위한 동작들을 수행하도록 하는, 명령들을 저장하기 위해 상기 프로세서와 연결된 메모리를 포함하고,
상기 동작들은:
Protobuf의 사양에 따라 하나 이상의 함수들의 제 1 세트를 정의하는 Protobuf 정의 파일로부터 하나 이상의 Protobuf 메시지 타입들을 획득하는 동작 - 상기 제 1 세트의 상기 함수들은 Protobuf 라이브러리들의 세트를 호출함 - ;
상기 Protobuf 메시지 타입들에 기초하여 상기 검증 대체 헤더 파일을 생성하는 동작 - 상기 검증 대체 헤더 파일은 표준 C/C++ 프로그래밍 언어에 따라 하나 이상의 함수들의 제 2 세트를 정의하고, 상기 제 2 세트의 상기 함수들은 표준 C/C++ 라이브러리들의 세트를 호출함 - ;
상기 검증 대체 헤더 파일로 하나 이상의 검증 스텁들을 삽입하는 동작 - 상기 검증 스텁들은 멤버 함수와 관련된 하나 이상의 전제 조건들(preconditions), 상기 멤버 함수와 관련된 하나 이상의 사후 조건들(postconditions), 또는 이들의 조합을 포함함 - ; 및
상기 Protobuf 라이브러리들의 세트를 검증할 필요가 없는 상기 표준 C/C++ 라이브러리들의 세트에 기초하여 상기 검증 대체 헤더 파일을 포함하는 상기 애플리케이션의 상기 검증을 수행하는 동작;
을 포함하는,
데이터 처리 시스템.
제 13 항에 있어서,
상기 Protobuf 정의 파일로부터 상기 하나 이상의 Protobuf 메시지 타입들을 획득하는 동작은,
상기 Protobuf 정의 파일에 기초하여 추상 구문 트리(AST)를 생성하는 동작 및 상기 AST을 파스하는 동작을 포함하는,
데이터 처리 시스템.
제 13 항에 있어서,
상기 Protobuf 메시지 타입 각각에 대해 상기 검증 대체 헤더 파일에 C++ 클래스가 생성되고, 그리고 대응되는 상기 Protobuf 메시지 타입의 필드 각각에 대해 상기 C++ 클래스에 하나의 멤버 필드 및 대응되는 상기 멤버 함수가 생성되는,
데이터 처리 시스템.
제 15 항에 있어서,
상기 애플리케이션의 상기 검증은 상기 C++ 클래스의 하나 이상의 객체들을 생성, 접근, 또는 삭제하도록, C/C++ 표준 라이브러리에 의존하는 상기 검증 대체 헤더 파일을 포함하는,
데이터 처리 시스템.
제 13 항에 있어서,
상기 하나 이상의 전제 조건들 또는 상기 하나 이상의 사후 조건들 중 적어도 하나는 커스텀 가능한,
데이터 처리 시스템.
삭제
삭제
삭제