Autosar Parallel Processing Design Guidelines 的翻译

1 Introduction to this document

1.1 Contents

本篇文档详述了AP之上的Parallel Processing。

本篇文档的主要目的是给使用AP Parallel Processing技术者提供guidelines。该技术主要涉及软件方面，特别是应用层（包含service）。通用的硬件Parallel Processing技术是Software的基础，本篇文章也会有涉及。

The document is organized as follows…TBA.

1.2 Prereads

This document is one of the high-level conceptual documents of AUTOSAR.
Useful pre-reads are [1] [2] [3] [4].

1.3 Relationship to other AUTOSAR specifications

Refer to Contents and Prereads.

2 Scope

2.1 Definition of parallel processing “technologies”

本篇文档并没有很严谨的给parallel processing technologies下定义。我们主要的目的还是希望提供一个设计准则。

对于parallel processing technologies包括硬件和软件两个方面。就硬件而言，；就软件而言，；一个AP based system 除了上述的技术还包括用于设计和实现parallel processing的工具。

本篇文档，不是来讲清现有的parallel processing技术，也不是讲述如何使用这些技术。然而，本篇文档还是会不得不涉及一些相关技术，但我们会尽可能的避免。

2.2 Audience

这篇文档适用于多领域的AP related designers and developers。the system designer就是决定软硬件的划分，hardware designer就是设计或者选择合适的硬件资源，software designer就是设计完整的软件系统体系。developers包括AP developers, and developers of AP services running on ARA。

3 Architectural design

3.1 Background

3.1.1 Evolving parallel processing technologies

parallel processing technologies在软/硬件方面发展很快速。在硬件方面，GPGPU是其中之一，除了GPGPU之外还包括manycore processors, dataflow processors, FPGA和一些dedicated accelerators。从未来来看，似乎还有更多的硬件方面的parallel processing technologies的诞生。

软件同硬件一样也有很多的parallel processing technologies。软件方面包括提供线程库的POSIX和C ++标准以及其他线程库TBB，MTAPI、基于线程的编译器，如OpenMP；编程语言加速器，如OpenCL和CUDA；基于FPGA的HLS编译器；除此之外，还有各种并行化编译器/工具，如graph or process network based tools通常使用下面的线程但是技术上不限于，甚至还有基于模型的并行化工具可以将Simulink模型作为输入。此外，还有各种消息传递通常与这些技术一起使用。有更高级别的库例如OpenCV，OpenVX–尽管这些并不是并行的处理库时，它们通常使用下层的并行处理技术加快处理速度。最后，更高级别的包括C ++ AMP和SYCL。在进一步来看，OpenMP 4现在也支持加速器。尽管如此，刚刚列出来的仍然只是部分。

3.1.2 Distributed, concurrent, and parallel

在大多数情况下，AUTOSAR系统是分布式系统。 分布式系统是并发的，意味着同时运行多个任务。 在分布式系统中每个子系统中有一些processing elements，通常是CPU（不是必要的） - 因此总的来说这是一个多处理器系统，能够兼顾并发和并行计算。 请注意，如果AP在单核处理器上运行并且没有任何其他计算元件的机器，并行处理是不可能的。虽然并发性仍然存在，但OS提供了基于事件触发的进程（线程）切换机制。

并行处理可能发生在不同的层级上，包括bit-level，instruction-level，hread-level，（和/或）task-level。 这里的task-level并不同于computing models and methodologies。 在AUTOSAR AP软件中，它们严格地说是thread-level，process level或machine (platform) level。 同样值得注意的是，在AP里面process是基于POSIX multi-process OS，它只是一个线程的容器而不是执行实体。 process为某些唯一的资源集提供了一个容器，其中包括一些process可访问的logical memory。 对于机器来说也是如此。 它始终是线程并发，在软件层并行（有两个以上可用的处理器）。

可能存在其他的processing elements，它们虽然不是直接执行AP，但提供一些有用的算力。 GPU，FPGA，DFP（Data Flow Processor）和manycore processor是很典型的例子，它们都或多或少的运行着OS和AP。如果他们根本就无法运行AP，那么并行处理能力只能通过某种运行在AP上线程的指定的接口来获取，不用管接口背后的机制如何。仍然可以用这种或那种方式编程 - 但不是ARA和C ++ bindings AP defines。

这里的体系设计主要是将parallel processing technologies应用在system level。 分布式，并发和并行处理高度相关。 一个例子是，一个设计良好的多线程程序可以在单核处理器上并发运行，或在多核处理器上并行运行，或者使用一些处理器/机器透明线程通信让它们分布在两台机器上运行。

3.1.3 TLP/DLP/PLP3.1.3 TLP/DLP/PLP

通常，有三种类型的并行处理：Task Level Parallelism（TLP），Data Level Parallelism（DLP）和Pipeline Level Parallelism（PLP）。 TLP指的是同时执行多个任务，多个任务之间（大多数）是独立的，不（大部分）相互依赖。 DLP指的是具有多个（大多数）非相互依赖的（大）数据集执行相同的运算。 同样的运算在不同的数据集复用。 PLP指的是执行多个相互独立的管道方式的任务。 每个任务都分配给一个管道阶段。

三种类型的并行性存在于系统的多层中。system level parallelism就像两台AP机器之间可能有TLP甚至PLP。 举个例子，基于多个摄像头的360度实时物体识别可以通过多个AP机器对大数据集执行DLP来实现（虚拟）车辆周围的视频图像。 重要的是车辆系统设计者要了解系统的整体数据流和处理相应地加载和分配AP机器。 这可以说是AP-machine level parallelism。

下一个是物理层的OS-thread level parallelism。 上述的三种类型可以使用OS threads来实现并行性。

另一个物理层的instruction level parallelism。 这是处理器和编译器技术的领域。 例如，VLIW处理器架构具有多个并发执行的执行单元，它允许多个指令流以TLP或DLP方式并发执行。 SIMD（Single Instruction Multiple Data）协处理器指令扩展使DLP成为instruction level。 通常，GPGPU就是一种instruction level DLP。manycore processor包括大部分DFP（Data Flow Processor），提供一般的MIMD（Multiple Instruction Multiple Data）instruction level parallelism。 由于它不是像SIMD那样的单指令，因此可以使用MIMD实现所有三种形式的并行，即TLP，DLP和PLP。

此外，无论physical levels，即AP-machine level，OS-thread level，Instruction level，TLP，DLP和PLP并不总是独立使用。 例如，对于大数据的多阶段处理，DLP和PLP是比较常用的技术。

3.2 Service-based parallel processing

有了3.1中提供的背景，本指南的关键概念是利用AP的SOA。 也就是说，推动在非平台服务下并行处理技术的使用，让AA免于各种并行处理的技术。 另一方面，服务“实施”将选择特定的并行处理技术。 我们称之为并行处理模型即“3.2 Service-based parallel processing”。

该模型在满足需要的高性能前提下，最大程度地实现AA的可重用性。

3.2.1 Layered architectural view

图3-1说明了基于服务的并行处理的总体架构。该示例基于某些ADAS应用程序，但不局限于此模型。

从上往下看，整体情况显示谁使用了什么（consumers），谁提供什么（providers）。

AA layer使用了各种服务。 AA不需要知道它使用的服务所采用的并行处理技术。

在本指南的上下文中，服务层由服务组成使用并行处理技术。有非平台服务使用ARA ::融为一体。它们提供了从服务定义生成的C ++接口库，AA使用的。请注意，这些服务可能很好地使用其他服务内部。一个示例是可以设计预处理或低级感测服务，以及使用以前服务的输出的元数据提供程序服务。另一个例子可以是可以设计各种检测服务，以及a预测器服务，使用检测服务来预测未来的对象地平线。另外，请注意，可能会有一些常见的高级库或
服务层使用的引擎。这样的库可以使用一些并行处理下面的图书馆。一个例子可能是OpenCV和OpenCV之间的关系OpenCL的。 OpenCV提供了视觉处理框架/库下面（可以）使用OpenCL来使用可编程加速器。 OpenCV
库可以由多个服务使用。这与之间的关系类似OpenVX和OpenCL - 然而，与OpenCV不同，OpenVX的设计使得
OpenVX接口实现可以直接访问特定的加速器，没有OpenCL之间。因此，它被绘制为并行处理图中的库/语言层。

The Service layer使用 Parallel processing library/language layer，它可以根据服务实现中使用的parallel processing technologies的选择而变化。 该层的编程接口如“3.1.1 Evolving parallel processing technologies”中所讨论的那样变化，并且在语义上不可能有一个统一的接口来概括所有甚至大多数不同的接口/语言，而不会严重影响 性能优势，这与首先采用parallel processing 的目的相矛盾。

3.2.2 Accelerator-model

Parallel processing library/languages layer以不同方式与parallel processing hardware交互。 有两种通用模型。 一种是accelerator model，其中parallel processing library/language调用直接控制parallel processing hardware的某种形式的设备驱动程序。 根据所使用的OS的设计，设备驱动程序可以是在OS内核的上下文中执行的另一个进程或某种形式的内核模块。 此accelerator model的示例包括OpenCL / CUDA，OpenVX等。图3-2显示了基于OpenCL的并行处理的组合过程和物理架构视图。

3.2.3 CPU/co-processor-model

另一种模型是CPU/co-processor-model,，其中parallel processing由CPU直接执行，不管有或没有 co-processor支持。 最流行的例子是线程模型，它使用多个POSIX线程来并行化处理。 这可以完全手写，基于指令，如OpenMP，或使用一些其他供应商特定的半/完全并行化编译器技术。 此外，可以支持使用专用协处理器指令，也可以是手动或半自动的。 图3-3显示了基于线程（如POSIX线程）并行处理的组合流程和物理架构视图。

3.3 Rationale: decoupling of parallel processing specific knowledge from application development

了解非通用计算硬件的细节需要特定的技能。 如前所述，parallel processing technologies仍在积极开发和发展中，很难理解所有这些。 一些标准化工作（例如OpenCL）旨在通过设置独立于硬件的API集来缓解此问题。 但是，为了覆盖各种类型的硬件并充分利用硬件功能以获得最佳性能，OpenCL通常是非常 low-level API，基本上需要类似级别的详细硬件级别知识。

我们提出的Service-based parallel processing模型通过AP服务接口从AA开发人员中分离出 parallel processing hardware所需的知识。 这使得AA开发人员无需在每次引入新的，更高效的或更合适的硬件时获取特定的硬件知识，并且如果引入这样的硬件产生更好的系统设计，则允许系统设计者这样做。 同时，这种去耦还使硬件设计人员能够提出新的创新并行处理技术，只要他们能够提供用户所需的AP服务。

3.4 Adaptive Platform methodology consideration

Service-based parallel processing方法不会引入任何新的AP方法。 它使用已定义的服务接口描述来定义服务。

4 Non-functional design topics

4.1 Performance

使用parallel processing的主要目的之一是实现更高的性能。 由于“Service-based parallel processing”利用了AP的SOA，因此一般的性能相关设计技术也适用。

4.1.1 Interface granularity and communication overhead

接口的粒度是每个API的操作单元的大小。 如果粒度很小，则该服务具有许多API。 粒度越细，服务一般就越灵活，因为小粒度将允许不同的应用程序优化其使用。

在SOA中，增加粒度将增加客户端和服务器之间的通信。 然而，在AP的实时系统中使用诸如高速缓存之类的机制来规避高速缓存增加的非确定性，因此不是方便的选择。

在AP中，有两种可能的方法来最小化服务的开销。 一种方法是使服务接口尽可能粗糙，特别是对于使用频率较高的接口。 例如，建议不要提供仅用于处理一个数据的接口，而是提供另一个用于一次处理一批数据的接口。 另一种方法是在服务接口库进行优化。 这意味着服务接口可以缓存用于客户端进程本地处理的一些服务器端数据，和/或设置或读取客户端进程堆中本地存储的对象中的字段的简单接口。 这两种技术可以混合使用。

4.1.2 Data handling and throughput balancing

移动非常大的数据的开销是昂贵的。 如果发生大量数据处理，尤其如此。 通常，并行处理用于执行处理大量数据，并且这通常针对数据流执行，构成数据流处理。 因此，必须设计整个数据流链，从数据生成设备，设备驱动程序，主服务器处理原始数据，辅助服务器处理主服务器输出，然后最终使用AA 辅助服务器的结果。 实现最高吞吐量的一种典型设计是使所有这些组件形成PLP，每个组件形成管道的一个阶段。 对于执行大量计算的服务器，使用DLP和/或PLP。 必须以有效的方式传播在组件之间流动的数据，从而避免在可能的情况下复制数据。

4.2 Deterministic execution

如果有必要通过基于service-based parallel processing确定性执行，应遵循[5]定义的方法。

对于CPU /co-processor-model，特别是如果有足够的处理元件并行执行冗余执行，该方法可以直接应用。

对于 accelerator-model，仍然存在服务器进程以及主线程和一些子线程，主要计算将由accelerator上执行的内核执行。 虽然它有所不同，但accelerator通常只能一次执行一个内核。 因此，除非accelerator能够并行运行多个内核或采用多个accelerator单元，否则不可能并行执行冗余运算。 使用单个加速器，一个选项是串行执行冗余运算。 但是，由于这会影响性能，实际的选择是放弃冗余运算并采用系统设计方法接受ASIL-B的service-based parallel processing，以及另一个ASIL-B或更高的子系统来监控accelerator-model service的结果。

4.3 Safety considerations

安全是系统设计的主题。 典型问题之一是parallel processing hardware technology不满足ASIL-D，而是仅满足ASIL-B。 该软件可以基于ASIL-D实践开发，但由于硬件仅支持ASIL-B，因此整体无法实现ASIL-D。 “子系统”所需的ASIL取决于它提供的系统功能 - 例如parallel processing subsystem用于ASIL-B系统功能，其计算结果由ASIL-D子系统进行安全检查。 或者，可以使用重复的ASIL-B子系统来实现ASILD（尽管它可能很昂贵）。 系统设计的设计指南以实现整体功能安全要求超出了本文档的范围。

为了实现通过基于服务的并行处理实现ASIL-D所必需的确定性，建议遵循“4.2 Deterministic execution”中讨论的方法。

4.4 Prospects

由于内在的解耦，本指南，尤其是隐藏在服务模型下的并行处理，应该能够在很长一段时间内存活下来。 未来有两个领域具有可预见的进步; （1） AP standard application services和（2） more parallel processing directly within AA。

4.4.1 AP standard application services

对于期望使用parallel processing technologies的这种应用服务由AP标准化应该是合理的。 这确实不会立即发生，也不会立即发生所有服务 - 但是，即使逐步引入此类服务也应该有助于parallel processing technologies的提供者以及这些服务的用户。 更高级别的API标准化，使用下面的并行处理技术，已经在某些领域出现，例如OpenVX。

4.4.2 More parallel processing within AA

遵循service-based parallel processing的设计，AA将并行使用多个服务。 随着服务数量的增长以及AA仍然是单线程的，AA可能成为整个处理链的瓶颈。 这将要求AA内的更多并行处理。 AP已经提供了当前支持的C ++标准和POSIX API的线程API，但是，这可能还不够。

AUTOSAR AP采用C ++标准以及CPP编码指南，在使用该语言时考虑到安全性和保密性。 C ++标准逐步引入并行处理。 开源和商业编译器中的大多数都支持该标准并在业界广泛使用。 因此，随着C ++标准的发展，引入更多并行处理技术是可预见的，也许是有希望的。 一个可能有希望的标准是SYCL，因为它纯粹基于标准C ++，带有用于编写并行处理的模板库，其中一部分是在C ++ 17中引入的。 使用标准语言并且能够与普通C ++多线程混合的单一来源方法可能有助于巩固目前的情况。

5 References

[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] Explanations of Adaptive Platform Design, AUTOSAR_EXP_PlatformDesign.pdf.
[5] Specification of Execution Management, AUTOSAR_SWS_ExecutionManagement.pdf.