本系列学习笔记基于 AUTOSAR Adaptive Platform 官方文档 R20-11 版本。本文从AUTOSAR_EXP_PlatformDesign.pdf开始，一边学习，一边顺带着翻译一下。尽力而为，不保证精确。你若愿意，也可以当作 AUTOSAR Adaptive Platform （AP）中文版来阅读
1 介绍
1.1 内容
本规范（AUTOSAR_EXP_PlatformDesign.pdf）描述 AP 设计。目的在于提供概述，但不涉及所有的设计细节。为AP 用户和AP 实现者提供 AP 的设计概述和关键概念。
第二章“技术范围和方法”介绍了 AP 的背景。第三章“架构”分别从逻辑和物理视角介绍了 AP，然后介绍了方法论和 Manifest
之后各个章节分别介绍了每个功能模块 （FC，Functional Clusters）
详细的规范和讨论参见相应的 RS、SWS、TR 和 EXP 文档。
译注：各类文档介绍及下载方式参考上一篇 AP 学习笔记
1.2 预读
本文档（AUTOSAR_EXP_PlatformDesign.pdf）是 AUTOSAR high level 概念文档之一。在此之前，可以阅读[1][2][3]。
1.3 和其他 AUTOSAR 规范的关系
参考 1.1 和 1.2 节。
2 技术范围和方法
2.1 概述
传统 ECU 主要功能是替代/增强机电系统。软件主要根据总线的输入信号控制输出信号。很多控制软件在车辆的生命周期内不会有大的变化。
但新的技术如自动驾驶，引入了高度复杂、对计算资源要求很高的软件，且必须严格遵守完整性、安全性要求。这些软件实现了环境感知、行为规划、和后端/基建系统集成等功能。在车辆的生命周期内，软件要不断更新以适配外部系统的更新以及改进功能。
CP 标准是针对传统 ECU 需求而提出的，无法满足上述新型 ECU 的需求，于是 AUTOSAR 推出了新的软件平台 AP。
AP 主要提供了：
- 高性能计算和通信机制
- 灵活的软件配置以支持 OTA 软件升级
AP 也可以支持传统的汽车总线的信号，但不是 AP 标准的重点。
2.2 技术驱动
AP 背后的技术驱动主要是以太网和处理器。
以太网
不断增长的带宽需求引入了以太网。和传统车身通信技术（如 CAN）相比，以太网提供了更高的带宽和交换网络，传输长报文效率更高，支持点对点通信。CP 虽然也支持以太网，但 CP 主要为传统通信技术设计、优化，无法充分利用、发挥以太网的优势。
译注：长报文有效载荷比更大；交换网络不同于总线式广播，点对点传输，减少总线冲突，提高传输效率。
处理器
随着汽车越来越智能，对处理器性能的要求增长巨大，出现了众核（manycore，十核到百核）处理器、通用目的GPU、FPGA、专用硬件加速器，较传统 MCU 可以大幅提升性能。CP 原本为单核 MCU 设计，虽然支持多核（multicore），但对新型处理器的支持大大超出了 CP 的设计。此外，电源效率也日渐重要，尤其是这些智能 ECU。受限于 Pollack 法则，处理器的频率不可能无限增长，要想提升性能，只能增加核心数并行计算。为了取得最佳的电源效率性能/瓦，需要混合用到众核、协处理器、GPU、FPGA 及硬件加速器。这被称为异构计算，已被用于 HPC（High-Performance Computing），当然远超 CP 的范围。
Pollack Rule：处理器性能的提升与其复杂性的平方根成正比。 如果一个处理器的硬件逻辑提高一倍，至多能提高性能40%，而如果采用两个简单的处理器构成一个相同硬件规模的双核处理器，则可以获得70%～80%的性能提升。同时在面积上也同比缩小。
值得一提的是，处理器被集成到一块芯片上，通过新的处理器互联技术（如 NoC，Network-on-Chip），处理器之间的通信效率比传统 ECU 间通信提高了几个数量级。处理器性能和通信的提升也促进了对新平台（AP）的需求。
2.3 AP 特征
2.1 和 2.2 节决定了 AP 的特征。
2.3.1 C++
译注：C++ 比其他语言性能更好。和 C 相比，C++ 标准库提供 STL及标准库算法，可以快速适配新算法，提高开发效率。
2.3.2 SOA
为了支持复杂的应用，同时在分布式处理和计算资源分配时，保证最大灵活性和可扩展性，AP 遵循面向服务的架构（SOA）。SOA 基于如下概念：系统由一些列的服务组成，服务之间可以相互调用，应用可以根据需要使用一个或多个服务。一个服务可以运行在本地 ECU，也可以运行在远程 ECU 上。不论哪种情况，应用程序的代码都一样（译注：通过代理模式实现）。通信服务负责处理具体通信细节，应用程序无需关心。从另一个角度来看这个架构：分布式计算，通过消息传递的形式来通信。这种消息传递、基于通信的架构也受益于快速、高带宽的通信（如以太网）的兴起。
2.3.3 并行处理
分布式计算本来就是并行的。SOA 中，不同的应用使用不同的服务。众核以及异构计算所带来的并行计算能力，使得实现内在并行性在技术上成为可能。因此，随着众核-异构计算技术的发展，AP 在架构具有了扩展功能和性能的能力。硬件和平台接口规范只是一部分，OS/hypervisor 技术和开发工具（如自动并行化工具）的发展也非常重要。这部分将有 AP 供应商以及行业/学术生态系统实现。AP 也旨在适应此类技术。
2.3.4 利用现有标准
没理由重新发明*，对于规范（相比于实现）尤其如此。AP 采取了复用、适配现有开放标准的策略，以促进 AP 发展，并从现有标准的生态中获益。因此，AP 规范的一个关键就是：不要随意引入一个现有标准已有功能的替代。例如，不要因为现有接口表面上不容易理解，就随意引入新的接口。
2.3.5 功能安全（Safety）和网络安全（Security）
AP的目标系统通常要求一定的功能/网络安全等级（可上至最高等级）。虽然有些困难，新引入的概念和技术不应降低安全方面的要求。
为应对挑战，AP 集合了架构、功能、流程方法：
- 该架构基于基于 SOA 的分布式计算，本质上使每个组件更加独立，且不受意外干扰
- 帮助取得 Safety 和 Security 的专门功能
- C++ 编码规范，帮助开发者更安全地使用 C++ 这样的复杂语言
2.3.6 规划动态
AP 支持应用的增量部署：动态管理资源和通信，以减少软件开发、集成的工作量，从而实现较短的迭代周期。增量部署还支持探索性软件开发阶段。
对于产品交付，AP 允许系统集成限制一些行为，以降低不利影响带来的风险，保证功能安全。应用的动态行为可以通过 Execution Manifest 来限制。在执行时，资源和通信路径的动态分配只能以预先定义的方式进行（例如在配置的范围内）。
特定的 AP 实现可能从软件配置中移除动态能力。计划动态的例子：
- 预先决定服务发现
- 限制启动阶段的动态内存配分
- 基于优先级的调度策略之外的公平调度策略
- 把进程分配到固定的 CPU 核
- 仅访问文件系统中预先存在的文件
- 限制应用使用的 AP API
- 仅执行验证过的代码
2.3.7 敏捷
尽管不直接反映在平台的功能上，AP 以适应不同的开发流程为目标，尤其是基于敏捷的开发流程。对于敏捷开发，增量、可扩展的潜在架构至关重要：提供了先开发，再更新的可能性。AP 架构应当支持敏开发：作为概念验证，AP 的规范和示例代码都是基于 Scrum 开发的。
2.4 CP、AP 以及和非 AUTOSAR ECU 集成
AP 不会取代 CP 或非 AUTOSAR 平台。相反，AP 和后端系统以及路边基础设施共同协作，形成一个完整的系统（如图）。例如 CP 也支持 SOME/IP。
2.5 规范范围
AP 定义了运行时系统架构：平台组成、提供的功能和接口。还定义了开发过程中使用的机器可读模型。规范应当提供使用平台的必要信息以及实现平台的需求。
19 参考文档
[1] Glossary, AUTOSAR_TR_Glossary.pdf.
[2] Main Requirement, AUTOSAR_RS_Main.pdf.
[3] Methodology for Adaptive Platform, AUTOSAR_TR_AdaptiveMethodology.pdf.
[4] Design guidelines for using parallel processing technologies on Adaptive Platform, AUTOSAR_EXP_ParallelProcessingGuidelines.pdf.
[5] FCDesign IAM, AUTOSAR_EXP_FCDesignIdentityAndAccessManagement.pdf.
[6] P. Kruchten, “Architectural Blueprints—The “4+ 1” View Model of Software Architecture,” IEEE Software, vol. 12, no. 6, pp. 42-50, November 1995.