Adaptive Autosar 병렬 처리 관련 Non-functional 설계 토픽

Performance

병렬 처리를 사용하는 주된 목적 중 하나는 더 높은 성능을 달성하는 것입니다. "서비스 기반 병렬 처리"는 AP의 SOA를 사용하기 때문에 일반적인 성능 관련 설계 기술도 적용됩니다.

 

Interface granularity and communication overhead  

인터페이스의 granularity은 API 당 연산 단위의 크기입니다. granularity가 작은 경우 서비스에 많은 API가 있습니다.  granularity가 더 작으면 일반적으로 서비스가 더 융통성이 있습니다. 작은 granularity으로 인해 다른 응용 프로그램에서 해당 용도를 최적화 할 수 있기 때문입니다. 

SOA에서 granularity을 높이면 일반적으로 클라이언트와 서버 간의 통신이 증가합니다. 그러나 AP와 같은 실시간 시스템에서는 캐싱과 같은 메커니즘이 우회하여 캐싱이 비 결정성을 높이기 때문에 편리한 선택이 아닙니다.

 

AP에는 서비스 오버 헤드를 최소화 할 수있는 두 가지 방법이 있습니다. 하나는 서비스 인터페이스를 가능한 한 조악하게 만드는 것입니다. 특히 사용에 높은 우선 순위를 갖는 인터페이스의 경우. 예를 들어, 하나의 데이터만 처리하기위한 인터페이스를 제공하는 대신 한 번에 데이터 배치를 처리하기 위한 또 다른 인터페이스를 제공하는 것이 좋습니다. 다른 접근법은 서비스 인터페이스 라이브러리에서 최적화하는 것입니다. 즉, 서비스 인터페이스는 클라이언트 프로세스 로컬 처리를 위한 일부 서버 측 데이터  또는 클라이언트 프로세스 힙에 로컬로 저장된 오브젝트의 필드를 설정하거나 읽는 단순 인터페이스를 캐시 할 수 있습니다. 이 두 기술은 혼합 될 수 있습니다.

 

Data handling and throughput balancing

매우 큰 데이터 이동의 오버 헤드는 무겁습니다. 이것은 많은 양의 데이터가 발생하는 경우 특히 그렇습니다. 대개 병렬 처리는 많은 양의 데이터를 처리하는 데 사용되며 종종 데이터 흐름 처리를 구성하는 데이터 스트림에 대해 수행됩니다. 따라서 데이터 생성 장치, 장치 드라이버, 원시 데이터를 처리하는 메인 서버, 메인 서버 출력에서 ​​작업 할 보조 서버, 그리고 마지막으로 사용하는 AA를 사용하여 데이터 흐름의 전체 체인을 설계해야합니다. 2 차 서버의 결과. 최고 처리량을 달성하기위한 일반적인 설계 중 하나는 이러한 모든 구성 요소가 PLP를 형성하고 각 구성 요소가 파이프 라인의 단계를 형성하는 것입니다. 무거운 계산을 수행하는 서버의 경우 DLP 또는 PLP가 사용됩니다. 구성 요소간에 흐르는 데이터는 효율적인 방식으로 전달되어야하며 가능한 경우 데이터를 복사하지 않아야합니다.

Deterministic execution  

CPU /코 프로세서 모델의 경우, 특히 병렬로 중복 실행을 수행 할 수있는 충분한 처리 요소가 있는 경우 이 접근법을 직선적인 방식으로 적용할 수 있습니다. 가속기 모델의 경우 서버 프로세스와 메인 스레드 및 일부 하위 스레드가 있으며 메인 계산은 가속기에서 실행되는 커널에 의해 수행됩니다. 변수는 다양하지만 가속기는 종종 한 번에 하나의 커널만 실행할 수 있습니다. 따라서 가속기가 여러 커널을 병렬로 실행하거나 여러 가속기를 사용하지 않는 한 병렬로 중복 실행을 수행 할 수 없습니다. 단일 가속기를 사용하면 하나의 옵션으로 중복 실행을 연속적으로 수행 할 수 있습니다. 그러나 이것이 성능에 영향을 미치기 때문에 실질적인 옵션은 중복 실행을 포기하고 ASIL-B에서 서비스 기반 병렬 처리를 수용하고 모니터링을 위해 다른 ASIL-B 이상의 상위 시스템을 수용하는 시스템 설계 방식을 취하는 것입니다.

Safety considerations  

안전은 시스템 디자인 주제입니다. 일반적인 문제 중 하나는 병렬 처리 하드웨어 기술이 ASIL-D를 만족 시키지는 않지만 ASIL-B까지만 충족시키는 것입니다. 이 소프트웨어는 ASIL-D 실행을 기반으로 개발 될 수 있지만 하드웨어는 ASIL-B 만 가능하기 때문에 전체적으로 ASIL-D를 달성 할 수 없습니다. "서브 시스템"에 필요한 ASIL은 제공하는 시스템 기능에 따라 다릅니다. 병렬 처리 서브 시스템은 ASIL-B 시스템 기능에 사용되며, ASIL-D 서브 시스템에 의해 계산 결과가 안전 확인됩니다. 또는 ASIL-D를 달성하기 위해 중복 ASIL-B 하위 시스템을 사용할 수 있습니다 (비용이 많이 들지만). 전반적인 기능 안전 요구 사항을 달성하기위한 시스템 설계의 설계 지침은이 문서의 범위를 벗어납니다.

서비스 기반 병렬 처리로 ASIL-D를 달성하는 데 필수적인 결정성을 달성하려면 "Deterministic execution"에서 설명한 방법을 따르는 것이 좋습니다.

 

Prospects  

이 가이드 라인, 특히 서비스 모델에 숨겨진 병렬 처리는 본질적인 디커플링으로 인해 오랜 시간 생존 할 수 있어야합니다. 미래에 예측 가능한 진보가 있는 두 영역이 있습니다. 

(1) AP 표준 응용 서비스 

(2) AA 내에서 직접 더 많은 병렬 처리.

 

AP standard application services 

병렬 처리 기술을 사용하는 응용 서비스가 AP에 의해 표준화되기를 기대하는 것이 합리적이어야합니다. 이것은 실제로 발생하지 않았으며 모든 서비스를 즉시 수행하고 있지 않습니다. 그러나 이러한 서비스가 점진적 도입된다면 병렬 처리 기술을 제공하는 사람과 그러한 사용자도 도움이 될 것입니다. 병렬 처리 기술을 사용하는 고급 API 표준화가 OpenVX와 같은 일부 분야에서 이미 등장하고 있습니다.

 

More parallel processing within AA  

서비스 기반 병렬 처리 설계에 따라 AA는 여러 서비스를 동시에 사용합니다. 서비스 수가 증가하고 AA가 단일 스레드로 유지되면 AA 자체가 전체 처리 체인에서 병목 현상이 될 수 있습니다. 결국 AA 내에서 더 많은 병렬 처리가 필요합니다. AP는 현재 지원되는 C ++ 표준 및 POSIX API의 스레딩 API를 이미 제공하지만 이는 충분하지 않을 수 있습니다. AUTOSAR AP는 안전과 보안을 염두에 두고 언어를 사용하기 위해 CPP 코딩 가이드 라인과 함께 C ++ 표준을 채택합니다. C ++ 표준은 점진적으로 병렬 처리를 도입합니다. 대부분의 오픈 소스 및 상용 컴파일러는 표준을 지원하며 업계에서 널리 사용됩니다. 따라서 C ++ 표준이 진행됨에 따라 더 많은 병렬 처리 기술을 도입하는 것이 예측 가능하고 아마도 유망한 방법입니다. 잠재적으로 유망한 표준 중 하나는 SYCL입니다. 순전히 표준 C ++을 기반으로하며, 병렬 처리를 작성하는 템플릿 라이브러리가 있으며, 그 중 일부는 C ++ 17에서 소개되었습니다. 표준 언어를 사용하는 단일 소스 접근 방식은 물론 일반 C ++ 멀티 스레딩과도 혼합 할 수 있으므로 향후 상황을 통합하는 데 도움이 될 수 있습니다.