SW/Autosar

Adaptive Platform에서 병렬 처리 기술을 사용하기 위한 설계 지침

얇은생각 2018. 11. 28. 12:30
반응형

개요

이번 포스팅에서는 Adaptive Platform 또는 병렬 처리 지침에서 병렬 처리 기술을 사용하기 위한 지침을 간단히 설명합니다. 그 목적은 AP에서 병렬 처리 기술을 사용하기위한 설계 지침을 제공하는 것입니다. 초점은 소프트웨어, 특히 서비스를 포함한 응용 프로그램 계층에 있습니다. 일반적인 하드웨어 정보는 소프트웨어 기반을 구축하기 위해 포함됩니다.



병렬 처리 기술의 정의 

병렬 처리 기술의 의미는 가볍게 기술합니다. 이는 병렬 처리 및 관련 처리 (분산, 동시 및 병렬 참조)에 대한 설계 원칙을 제공하고자하는 의도입니다. 따라서 "병렬 처리 기술"이라는 용어는 하드웨어와 소프트웨어를 모두 포함합니다. 하드웨어, 멀티 코어, 멀티 코어, DFP (Data-Flow Processor), GPU (Graphical Processing Unit), FPGA (Field-ProGrammable-Array) 또는 이와 유사한 용어. 소프트웨어, 멀티 스레드 프로그래밍, OpenMP1과 같은 플러그 - 기반 기술, TBB2와 같은 다양한 템플릿 프로그래밍, OpenCL3과 같은 액셀러레이터 프로그래밍 언어, 심지어는 병렬 처리 기술이 아니지만 밀접한 관련이있는 다양한 메시지 전달 API 등이 있습니다. 이 기술은 AP 기반 시스템에 병렬 처리 기술을 설계하고 구현하는 데 도움이되는 다양한 도구를 포함합니다. 기존의 모든 병렬 처리 기술을 나열하고, 그 기술을 설명하고, 기술 자체를 사용하는 방법을 안내하는 것이 아닙니다. 그럼에도 불구하고 설계 지침을 설명하는 데 필요한 것으로 간주되는 최소한의 기술에 대한 언급이 포함될 수 있습니다.



Audience (대상) 

이 사양은 AP 관련 디자이너 및 개발자의 여러 도메인, 즉 하드웨어 / 소프트웨어 파티셔닝을 결정하는 시스템 디자이너, 컴퓨팅 하드웨어 리소스를 설계 및  선택하는 하드웨어 디자이너, 전체 소프트웨어 시스템 아키텍처를 설계하는 소프트웨어 디자이너, AP 개발자를 위한 것입니다. 반면 AA 개발자는 병렬 처리 기술을 직접 사용하지 않고 순차적인 단일 스레드 응용 프로그램만 설계 할 수 있습니다. 소프트웨어 설계자가 이 문서에서 설명하는 아키텍처 설계 지침을 따르는 경우에는 적합하지 않을 수도 있습니다. 그러나 요즘에는 어떤 형태의 멀티 스레드 프로그래밍없이 응용 프로그램을 작성하는 것이 어려워지고 있으며 앞으로는 더 많이 적용될 수 있습니다.



병렬 처리 기술 발전

병렬 처리 기술은 하드웨어와 소프트웨어 모두에서 빠르게 발전하고 있습니다. 하드웨어에서 GPGPU (General Purpose GPU)는 그 중 하나 일 뿐이지 만 다양한 코어 코어 프로세서, 데이터 흐름 프로세서, FPGA 및 일부 전용 액셀러레이터가 등장하고 있으며 이러한 기존 코드의 진화를 비롯하여 더 많은 기능이 추가 될 것으로 보입니다.구조는 소프트웨어와 유사합니다. POSIX 및 C ++ 표준 라이브러리 AP에서 제공하는 스레딩 라이브러리 및 TBB, MTAPI4와 같은 다른 스레딩 라이브러리, OpenMP와 같은 스레딩 기반 컴파일러 지시문, OpenCL 및 CUDA® (독점적)와 같은 가속기 프로그래밍 언어, HLS5 컴파일러 기반 FPGA 프로그래밍, 그래프 또는 프로세스 네트워크 기반 도구와 같은 다양한 병렬화 컴파일러 / 도구 (일반적으로 스레딩을 사용하지만 기술적으로 제한되지는 않음) 및 Simulink® 모델을 입력으로 사용할 수있는 모델 기반 병렬화 도구가 있습니다. 또한 이러한 기술과 함께 작동하는 다양한 메시지 전달 API가 있습니다. OpenCV6, OpenVX7과 같은 고급 라이브러리가 있습니다. 라이브러리 자체를 병렬 처리하는 것은 아니지만 일반적으로 병렬 처리 기술을 사용하여 처리 속도를 높입니다. 마침내 C ++ AMP8과 SYCL9가 더 높은 수준이라는 점에서 비슷합니다. 이 문제를 더욱 복잡하게 만들기 위해 OpenMP 4는 가속기를 지원합니다.



Distributed, concurrent, and parallel 

대부분의 경우 AUTOSAR 시스템은 분산 시스템입니다. 분산 시스템은 동시적이며, 동시에 여러 개의 태스크가 실행 중임을 의미합니다. 분산 시스템의 각 서브 시스템에는 일종의 처리 요소, 일반적으로 CPU가 있습니다 (반드시 그런 것은 아닙니다). 따라서 전체적으로 이것은 동시 및 병렬 컴퓨팅이 가능한 멀티 프로세서 시스템입니다. AP가 다른 컴퓨팅 요소없이 단일 코어 프로세서 시스템에서 실행되는 경우 OS가 일부 이벤트에 의해 트리거 된 처리 (스레드)를 전환하는 스레딩 메커니즘을 제공하기 때문에 동시성은 그대로이지만 병렬 처리는 불가능합니다. 

병렬 처리는 비트 레벨, 명령어 레벨, 스레드 레벨, 및 / 또는 태스크 레벨로부터 상이한 컴퓨팅 계층에서 발생할 수 있습니다. "태스크 레벨"의 정의는 컴퓨팅 모델과 방법론에 따라 다릅니다.  AUTOSAR AP 소프트웨어의 관점에서 볼 때 이들은 엄격하게 스레드 레벨, 프로세스 레벨 또는 머신 (플랫폼) 레벨 중 하나입니다. 또한 POSIX 다중 프로세스 OS를 기반으로하는 AP의 맥락에서 프로세스가 스레드의 컨테이너 일 뿐이며 스레드와 같은 실행 엔티티가 아닌 프로세스를 인식하는 것이 주목할 만합니다. 컨테이너는 프로세스가 액세스 할 수있는 논리 메모리를 포함하는 특정 고유 한 자원 세트를 위한 인클로저를 제공합니다. 이것은 머신에서도 마찬가지입니다. AUTOSAR AP OS에서 직접 실행되는 것은 소프트웨어 수준에서 항상 스레드 동시성 및 병렬 처리 (두 개 이상의 프로세서를 사용할 수있는 경우)입니다. 

 AP를 직접 실행할 수 없지만 유용한 컴퓨팅을 제공하는 다른 처리 요소가 있을 수 있습니다. GPU, FPGA, DFP (데이터 흐름 프로세서) 및 manycore 프로세서는 2017 년 현재 대표적인 사례입니다. 일부는 임원 또는 OS, 심지어 AP 자체 또는 전체 또는 일부를 실행할 수 있습니다. AP를 적어도 부분적으로 실행할 수없는 경우 병렬 처리 기능은 인터페이스 뒤의 메커니즘에 관계없이 AP에서 실행중인 스레드의 특정 인터페이스로만 액세스 할 수 있습니다. 그것들은 여전히 ​​어떤 방식 으로든 프로그래밍이 가능합니다. 그러나 ARA와 C ++ 바인딩 AP가 정의하는 방식은 아닙니다.

 여기서 중요한 아키텍처 설계 고려 사항은 병렬 처리가 전체적으로 시스템 레벨 주제라는 것입니다. 분산, 동시 및 병렬 처리는 상호 연관성이 높습니다. 한 가지 예는 잘 설계된 멀티 스레드 프로그램이 단일 코어 프로세서에서 동시에 실행되거나 멀티 코어 프로세서에서 병렬로 실행되거나 일부 프로세서 / 시스템 transparent 스레드 통신을 사용하는 경우 두 대의 컴퓨터에 분산 될 수도 있다는 것입니다.

 


TLP/DLP/PLP 

일반적으로 병렬 처리에는 TLP (Task Level Parallelism), DLP (Data Level Parallelism) 및 PLP (Pipeline Level Parallelism)의 세 가지 유형이 있습니다. TLP는 (대부분) 독립적이며 동시에 (주로) 서로 의존하지 않는 동시에 여러 작업을 수행하는 것을 말합니다. DLP는 여러 개의 (대개) 비 상호 의존적 인 (대용량) 데이터 세트로 동일한 계산을 수행하는 것을 말합니다. 동일한 계산이 다른 데이터 세트로 다중화됩니다. PLP는 파이프 라인 방식으로 여러 개의 상호 종속적 인 작업을 실행하는 것을 의미합니다. 각 작업은 작업 입력 / 출력의 데이터 종속성마다 파이프 라인 단계에 할당됩니다.

 

세 가지 유형의 병렬 처리가 시스템의 다중 계층에 존재합니다. 두 개의 AP 시스템이 TLP 또는 PLP를 가질 수 있는 것처럼 시스템 수준의 병렬 처리가 있을 수 있습니다. 또 다른 예는 다중 카메라 기반의 360도 실시간 객체 인식이 비디오 이미지를 둘러싼 (가상) 차량의 대형 데이터 세트에 대해 DLP를 수행하는 여러 AP 머신에 의해 실현 될 수 있다는 것입니다. 여기에서 요점은 차량 시스템 설계자가 시스템 전반적인 데이터 흐름과 처리 부하를 이해하고 이에 따라 AP 시스템을 할당하는 것이 중요하다는 것입니다. 이는 AP-머신 수준 병렬 처리라고 할 수 있습니다.

 

아래 physical level은 OS 스레드 수준의 병렬 처리입니다. 위에 설명 된 세 가지 유형의 병렬 처리는 OS 스레드를 사용하여 구현할 수 있습니다.

 

아래의 또 다른 physical level은 명령어 수준의 병렬 처리입니다. 이것은 일반적으로 프로세서 및 컴파일러 기술 분야에 있습니다. 예를 들어, VLIW10 프로세서 아키텍처에는 TLP 또는 DLP 방식으로 여러 명령 스트림을 동시에 실행할 수있는 여러 실행 단위가 있습니다. SIMD (단일 10 매우 긴 명령 워드 명령 다중 데이터) 듀얼 프로세서 명령 확장은 명령 레벨에서 DLP를 가능하게합니다. 일반적으로 GPGPU는 "3.2.2 Accelerator-model"의 지침 수준 DLP 형식입니다. 반면 SIMD 확장은 "3.2.3 CPU / 코 프로세서 모델"의 DLP입니다. 대부분의 DFP (데이터 흐름 프로세서)를 포함한 manycore 프로세서는 일반적으로 MIMD (다중 명령 다중 데이터) 명령 수준 병렬 처리를 제공합니다. SIMD와 같은 단일 명령어가 아니기 때문에, MIMD는 세 가지 형태의 병렬 처리, 즉 AP 머신 레벨, OS 스레드 레벨 또는 명령어 레벨과 상관없이 TLP, DLP 및 PLP가 항상 독립적으로 사용되는 것은 아닙니다. 예를 들어, 대용량 데이터의 다단계 처리의 경우 DLP와 PLP의 조합이 널리 사용됩니다.



Service-based parallel processing  

서비스 기반 병렬 처리의 핵심 개념은 AP의 SOA를 이용하는 것입니다. 즉, 비 플랫폼 서비스 아래에서 병렬 처리 기술을 사용하도록 밀어 넣어 AA가 다양한 병렬 처리 기술을 사용하지 않도록 합니다. 반면 서비스 '구현'은 사용되는 병렬 처리 기술의 선택에 따라 달라질 것입니다. 우리는이 병렬 처리 모델을 "3.2 서비스 기반 병렬 처리"라고 부릅니다.


이 모델 기능을 실현하는 데 있어 고성능 컴퓨팅을 필요로하는 AA를 최대한 재사용 할 수 있습니다. 무거운 리프팅 부분은 비 플랫폼 서비스로 분리 될 것이며 서비스의 구현은 프로젝트의 안전 / 보안 요구 사항을 준수한다면 선택한 병렬 처리 기술의 모든 기능을 자유롭게 활용할 수 있습니다.


 

Layered architectural view 

아래 그림은 서비스 기반 병렬 처리의 전체 아키텍처를 보여줍니다. 이 예는 일부 ADAS 도메인 응용 프로그램을 기반으로하지만 어떤 방식 으로든 도메인을 제한하려는 의도는 아닙니다.


Parallel processing consumer-provider layered view example  


전반적인 그림은 누가 (소비자) 무엇을 사용하고, 무엇을 (제공자)에게 누가 하향식으로 제공 하는지를 보여줍니다.


AA 계층은 다양한 서비스를 사용하는 AA입니다. AA는 사용하고있는 서비스가 아래의 병렬 처리를 사용하고 있다는 것을 모르고 있습니다.

 

이 가이드 라인의 컨텍스트에서 서비스 계층은 병렬 처리 기술을 사용하는 서비스로 구성됩니다. ara :: com을 사용하는 비 플랫폼 서비스가 있습니다. 이들은 AA에서 사용하는 서비스 정의에서 생성 된 C ++ 인터페이스 라이브러리를 제공합니다. 이러한 서비스는 내부적으로 다른 서비스를 잘 사용할 수 있습니다. 하나의 예는 전처리 또는 저수준 감지 서비스를 설계 할 수 있고, 이전 서비스의 출력을 사용하는 메타 데이터 제공자 서비스를 설계 할 수 있습니다. 또 다른 예는 다양한 탐지 서비스를 설계 할 수 있으며 미래의 수평선에서 객체를 예측하기 위해 탐지 서비스를 사용하는 예측 서비스입니다. 또한 서비스 계층에서 사용하는 일반적인 상위 라이브러리 또는 엔진이있을 수 있습니다. 그러한 라이브러리는 밑에 어떤 병렬 처리 라이브러리를 사용할 수 있습니다. 하나의 예가 OpenCV와 OpenCL 간의 관계 일 수 있습니다. OpenCV는 프로그래밍 가능 액셀러레이터를 사용하기 위해 OpenCL을 사용할 수있는 비전 처리 프레임 워크 / 라이브러리를 제공합니다. OpenCV 라이브러리는 여러 서비스에서 사용할 수 있습니다. 이것은 OpenVX와 OpenCL 간의 관계에서도 비슷합니다. 그러나 OpenCV와는 달리 OpenVX는 OpenVX 인터페이스 구현이 OpenCL없이 특정 가속기에 직접 액세스 할 수 있도록 설계되었습니다. 따라서 그림에서 병렬 처리 라이브러리 / 언어 계층에 있다고 가정합니다.

 

서비스 계층은 서비스 구현에 사용되는 병렬 처리 기술의 선택에 따라 달라질 수있는 병렬 처리 라이브러리 / 언어 계층을 사용합니다. 이 계층의 프로그래밍 인터페이스는 "진화 병렬 처리 기술"에서 설명했듯이 다양합니다. 또한 단일 인터페이스를 사용하여 다른 인터페이스 / 언어의 전체 또는 대부분을 일반화하는 것은 의미 상 불가능합니다. 성능상의 이점은 병렬 처리를 처음 사용하는 목적과 모순됩니다.

 


Accelerator-model 

병렬 처리 라이브러리 / 언어 계층은 여러 가지 방식으로 병렬 처리 하드웨어와 상호 작용합니다. 두 가지 일반적인 모델이 있습니다. 하나는 병렬 처리 하드웨어를 직접 제어하는 ​​장치 드라이버의 일부 양식 아래에서 병렬 처리 라이브러리 / 언어가 호출하는 가속기 모델입니다. 디바이스 드라이버는 사용되는 OS의 설계에 따라 OS 커널의 컨텍스트에서 실행되는 커널 모듈의 또 다른 프로세스 또는 일부 형태 일 수 있습니다. 이 가속기 모델의 예에는 OpenCL / CUDA, OpenVX 등이 포함됩니다. 그림 3-2는 OpenCL 기반 병렬 처리에 대한 결합 된 프로세스 및 물리적 아키텍처 뷰를 보여줍니다.

 

Accelerator-model example 



CPU/co-processor-model 

다른 모델은 CPU / 코 프로세서 모델로, 코 프로세서 지원이 있거나없는 CPU에 의해 병렬 처리가 직접 실행됩니다. 가장 보편적인 예는 다중 POSIX 스레드를 사용하여 처리를 병렬 처리하는 스레딩 모델입니다. 이것은 OpenMP와 같이 직접 작성되거나 지시기 기반 일 수 있으며, 다른 벤더의 준결정 / 완전 병렬화 컴파일러 기술을 사용할 수도 있습니다. 또한, 특수 코 프로세서 (co-processor) 명령을 이용하는 것에 대한 지원이 있을 수 있고, 또한 수동 또는 반자동 일 수 있습니다. 그림은 스레딩 기반 (POSIX 스레드와 같은) 병렬 처리에 대한 결합 된 프로세스 및 physical structure를 보여줍니다.

 

CPU/co-processor-model example  

 


Rationale: decoupling of parallel processing specific knowledge from application development 

비 일반 컴퓨팅 하드웨어의 특성을 이해하려면 특정 기술이 필요합니다. 앞서 언급했듯이, 병렬 처리 기술은 여전히 ​​활발히 개발되고 발전하고 있으며, 모든 것을 이해하는 것이 최선입니다. OpenCL과 같은 일부 표준화 노력은 하드웨어 독립적 인 API 세트를 설정하여이 문제를 완화하는 것을 목표로합니다. 그러나 다양한 유형의 하드웨어를 포괄하고 최상의 성능을 위해 하드웨어 기능을 완벽하게 활용하기 위해 OpenCL은 일반적으로 매우 낮은 수준의 API이며 기본적으로 유사한 수준의 하드웨어 수준 지식을 요구합니다.

 

제안된 서비스 기반 병렬 처리 모델은 AP 서비스 인터페이스를 통해 병렬 처리 하드웨어에 대한 지식을 AA 개발자와 분리합니다. 이는 새롭고 더 효율적이거나 보다 적합한 하드웨어가 도입 될 때마다 AA 개발자가 특정 하드웨어 지식을 습득하는 것을 자유롭게하며, 그러한 하드웨어의 도입으로 더 나은 시스템 설계가 가능 해지면 시스템 설계자도 그렇게 할 수 있습니다. 동시에 디커플링은 하드웨어 설계자가 사용자가 필요로하는 AP 서비스를 제공 할 수 있는 한 새롭고 혁신적인 병렬 처리 기술을 제공 할 수 있습니다.



Adaptive Platform methodology consideration 

서비스 기반 병렬 처리 방식은 새로운 AP 방법론을 도입하지 않습니다. 이미 정의된 서비스 인터페이스 설명을 사용하여 서비스를 정의합니다.

반응형