概述
第一章 AUTOSAR架构介绍
AUTOSAR(AUTomotive Open System ARchitecture)是汽车和软件行业领先公司的全球合作联盟，为智能移动开发和建立标准化的软件框架以及开放的E/E系统架构。考虑到目前和未来市场中不同的汽车E/E架构，AUTOSAR联盟为汽车软件架构建立了开放的行业标准。因此AUTOSAR有两种含义，一是代表AUTOSAR联盟，二是代表AUTOSAR软件架构。
AUTOSAR 组织
随着AUTOSAR标准的完善以及广泛的应用，AUTOSAR联盟中的成员也是越来越多。这进一步推动了AUTOSAR软件架构的发展和应用。
官 ：https://www.autosar.org/
AUTOSAR基本原理
相比传统软件架构，AUTOSAR在上层软件和底层硬件平台之间嵌入标准的中间层，实现了软硬件的解耦。AUTOSAR的口 是标准上协作，实现上竞争。
通过软硬件解耦，缩短研发周期和降低研发成本，同时通过软件的复用提供研发质量和效率。由于有统一的标准（软件接口，文件交换格式，方法论），因此OEM、供应商、工具提供商等可以协同开发，简化软件系统的集成，软件模块可以复用和高效率的衍生，提高了研发效率，降低整体软件的研发成本。
基本的AUTOSAR方法
下图是简化版的AUTOSAR开发工作流。AUTOSAR将应用软件和硬件平台进行解耦，在应用软件和基础软件与硬件之间嵌入虚拟功能总线，应用之间的通信或者访问硬件资源等都是通过虚拟功能总线进行资源交换。在Classic Platform中虚拟功能总线为RTE层，在Adaptive Platform中虚拟功能总线为ARA层。由于AUTOSAR采用自上而下的方法论，从架构设计、接口描述，软件开发，功能组件集成都是采用模型开发。因此可以使用代码生成工具，将SWC描述文件、ECU描述文件、系统约束文件等导入工具后可以生成可执行代码。
未来的汽车产业挑战
2003年，汽车行业的高端玩家们发起了汽车嵌入式系统软件架构标准化项目——AUTOSAR(汽车开放系统架构)。2017年，为适应汽车的发展趋势（智能化， 联化等），应对汽车E/E系统开发面临的新的挑战（高性能处理器的应用，自动驾驶软件的实现，高带宽通信的需求，车与外界的互联互通，汽车E/E架构的演变等），AUTOSAR组织推出了AUTOSAR Adaptive Platform。
AUTOSAR的愿景和目标
AUTOSAR架构的特点
AUTOSAR 软件架构
Foundation
Foundation是Classic Platform和Adaptive Platform公共的部分，比如总线协议，方法论等
Classic Platform
CP平台是为硬实时和安全要求严格的嵌入式系统的提出的AUTOSAR解决方案。
Adaptive Platform
AP平台是为高性能计算的ECU提出的解决办法，用于自动驾驶等。
Acceptance Tests
AUTOSAR验收测试是总线级和应用程序级的系统测试，用于验证与应用软件组件和通信总线相关的AUTOSAR堆栈的行为
Acceptance Interface
AUTOSAR根据语法和语义为以下五个汽车领域标准化了大量的应用接口:车身和舒适性、动力总成发动机、动力总成传动系统、底盘控制以及乘员和行人安全。
AUTOSAR Classic Platform架构
Classic AUTOSAR将微控制器上的软件抽象为三个软件层：应用程序、运行时环境(RTE)和基本软件(BSW)。其中BSW分为三个主要层：服务层、ECU抽象层和微控制器抽象层。应用与应用之间，以及应用于BSW之间的通信都是经过RTE完成数据交换，因此做到了应用与硬件的完全独立。
Classic AUTOSAR是分层软件体系结构，软件需求在设计时通过每一层的静态配置来实现。因此，对于运行时的更改，它的灵活性较低，但是这点还是可以接受的，因为这个平台通常在车辆的生命周期内保持稳定，因为被控制的传感器和执行器的应用逻辑不会改变，传感器和执行器仍然履行它们本身的功能。
VECTOR Classic AUTOSAR架构
AUTOSAR Adaptive Platform架构
Adaptive AUTOSAR平台为AUTOSAR应用实现了运行环境ARA。使用两种接口完成数据交换：服务和API。平台由功能集群组成，这些集群按服务和自适应AUTOSAR基础进行分组如下。
Adaptive AUTOSAR解决了新一代汽车高性能需求、连接性和持续软件无线(OTA)更新带来的新市场需求，它作为多个供应商的软件集成平台，解决了Classic AUTOSAR经典架构的局限性，其为灵活性而设计的，以便在运行时支持软件更改。Adaptive AUTOSAR构建在POSIX操作系统之上，由不同的功能模块组成，这些模块被划分在服务模块和基础模块上,它的的通信是面向服务类型的，会将 络绑定到DDS或者SOME/IP使用以太 与其它ECU通信。
Adaptive Platform逻辑视图
VECTOR Adaptive AUTOSAR架构
AP与CP架构比较
AUTOSAR CP平台与AP平台特性比较
综上，AUTOSAR包含了Classic Platform和Adaptive Platfrom。Adaptive Platform并不是用来取代Classic Platform或者非AUTOSAR平台，而是为了相互兼容，协作并满足未来的需求。
第二章 Adaptive AUTOSAR特性介绍
技术范围和方法
智能ECU
现在的ECU的主要功能实现都是为了增强或者取代电子机械系统，所以现在的电子电器架构很多都采用线控系统。ECU内部的嵌入式软件根据输入的信 或者来自于车载 络的其他ECU的信息控制输出信 。许多软件是根据目标车辆设计和实现，在车辆的生命周期中不会发生根本性的变化。
未来的车辆功能，比如高级自动驾驶，会使得软件变得非常复杂且需要很高的算力，并且要满足严格的集成性和安全需要。这些软件实现了环境感知、行为规划等功能，并将车辆集成到外部后端和基础设施系统中。由于外部系统的发展或功能的改进，在车辆的生命周期中，车辆中的软件需要更改。正是由于这些需要，现在越来越多的车辆支持OTA功能，OTA功能就像我们使用手机一样，可以借助空中升级功能不断更新软件功能。功能的更新可能是修复一个BUG，或是增加一个功能，又或是增强一个性能等等，这种变化使能车辆具有不断升级的能力，也赋予了用户与车辆更多的粘性。
由于AUTOSAR Classic Platform(CP)标准不能完全解决以上需求，因此，AUTOSAR组织提出了AP平台的标准，AP平台主要提供了高性能的计算和通信机制以及灵活的软件配置，例如支持OTA软件升级。
技术驱动
技术驱动主要有两个方面，一个是以太 ，另一个是处理器。
日益增长的车辆 络带宽需求帮助以太 应用在汽车 络通信中，其提供了更高的带宽和交换 络，相比传统的车载通信总线，例如CAN总线，其带来了长消息的有效传递和点对点的通信。虽然CP也支持以太 通信，但主要是为传统通信技术设计和优化的，因此也是很难充分利于以太 的通信能力。
类似的，随着汽车功能越来越复杂，对于处理器的处理能力的需要也是逐年剧增。虽然多核处理器已经能够应用在CP平台，但是有些应用需要成百上千的多核处理器，比如GPU，专用加速器等应用相比传统MCU来说能够提供更高的性能。CP平台曾经是为了单核处理器设计，虽然现在也支持多核，但计算的最佳性能往往需要结合不同的计算资源，比如多核，协处理器，GPU，FPGA和加速器等。这种混合方式被称为异构计算，其能力远远超过了CP。
AP特性
AP包含的特性来自于未来的智能ECU和技术驱动两个方面。高性能的计算满足了安全的需要同时也需要很高的能耗，因此带来了许多新的挑战。为了应对这些挑战，AP采用了很多传统ECU未充分利用的技术。有如下几个方面
C++
Adaptive AUTOSAR平台的应用都将采用C++编程。虽然C语言是嵌入式系统的主要编程语言，具有执行速度快、效率高的特点；但是在性能要求非常高的复杂应用和算法开发上（如机器学习、图像特征识别等）具有面向对象特性的C++显然比C更具有优势。C++能够提供算法开发和性能均衡的软件。并且方便很快地适配和量产开发。
SOA
为了支持复杂的应用程序，同时在处理分布和计算资源分配方面允许最大的灵活性和可伸缩性，AP遵循SOA(
service-oriented-architecture)的架构。SOA主要基于以下概念：系统由一组服务构成，其中 一个可使用另外一个的服务，应用程序可根据自己的需要使用一个或者多个服务；此外服务可以在应用程序运行的本地ECU上，也可以运行在另一个AP实例的远程ECU上。关于什么是SOA，目前还没有明确的结论。
官 ：Scalable service-Oriented MiddlewarE over IP (SOME/IP) (some-ip.com)
并行处理能力
分布式计算本质是并行的。先进的多核异构处理器既具有强大的计算能力也能为并行计算提供技术支持，随着多核异构计算技术的发展，AP具有扩展其功能和性能架构的能力。事实上，硬件和接口规范仅是实现AP的一部分，在OS等技术和开发工具的发展上对实现AP的应用也至关重要。
利用现有标准
重新发明轮子是没有意义的，尤其在规范方面。正如已经在c++中描述的那样，AP采取了重用和适应现有开放标准的策略，以促进AP自身的更快发展，并从现有标准的生态系统中受益。因此，开发AP规范的一个关键重点是不要随意引入现有标准已经提供的新替代功能。例如，这意味着不会仅仅因为现有标准提供了所需的功能，但接口表面上不容易理解，就随意引入新的接口。
安全性
AP所针对的系统通常需要某种级别的安全性，可能是最高级别的安全性。新概念和技术的引入不应破坏这些需求，尽管实现这些需求并非易事。为了应对这一挑战，AP结合了体系结构、功能和过程方法。该架构基于基于SOA的分布式计算，这使得每个组件更加独立，避免了意想不到的干扰，具有专门的功能来帮助实现安全和保障，以及诸如c++编码指南之类的指导方针，它促进了像c++这样的复杂语言的安全使用。
动态计划
AP支持应用程序的动态部署，动态地管理资源和通信，以减少软件开发和集成的工作量，从而缩短迭代周期。在AP架构下，不同的应用可能由不同的供应商提供，因此在产品交付阶段，AP允许系统集成商合理限制这种动态部署的特性以降低不必要的风险和影响。
敏捷
敏捷尽管没有直接反映在平台功能中，AP的目标是适应不同的产品开发过程，特别是基于敏捷的过程。对于基于敏捷的开发，至关重要的是系统的底层架构是可增量扩展的，在部署后可以更新系统。AP的体系结构应该允许这样做。作为概念的证明，AP规范本身和演示者(AP的演示实现)都是用Scrum[^1]开发的。
[^1]: Scrum是迭代式增量软件开发过程，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法：Scrum of Scrums. [1]
CP、AP和非AUTOSAR ECU的集成
综合以上的介绍，AP不会替代CP或者非AUTOSAR的平台。而是与这些平台以及外部后端系统(如路边基础设施)交互，形成一个完整的系统(图2-1不同平台部署示例、图2-2 AP与CP交互示例)。例如，CP已经包含了一些SOME/IP协议，AP也支持这些协议。
架构
我们将从逻辑视图，物理视图以及方法论三个方面了解自适应平台的架构。
逻辑视图
ARA
下图表示AP的架构，其中Adaptive Application(自适应应用)运行在ARA(AUTOSAR自适应应用的运行环境)之上。ARA是应用程序（AP中称为Adaptive Application）运行时的基础环境，可以提供多种本地功能供应用程序调用，这些本地功能在AP中统称为Function Clusters，其分为两个部分：Foundation Function Clusters和Service Function Clusters。
语言绑定，C++标准库，以及POSIX接口
这些API的语言基于C++绑定的，C++标准库也可以作为ARA的一部分使用。关于OS接口，只有POSIX标准的单进程概要文件(PSE51接口)作为ARA的一部分可用。选择PSE51是为了为现有的POSIX应用程序提供可移植性，并实现应用程序之间的自由干扰。
C++标准库包含许多基于POSIX的接口，也包括多线程接口。
应用启动和关闭
由Execution Management(EM)管理应用的生命周期。应用程序的加载/启动是通过使用EM的功能来管理的，它需要在系统集成时或运行时进行适当的配置才能启动应用程序。下图说明了不同类型的AP应用。
应用交互
对于AAs之间的交互，PSE51没有包含IPC (Inter-Process- Communication)，所以在AAs之间没有直接的交互接口。通信管理(CM)是唯一的显式接口。CM还为ECU内外部提供面向服务的通信。CM处理服务请求/响应的路由，而不管服务和客户端应用程序的拓扑部署。
非标准接口
AA和功能集群可以使用任何非标准接口，只要它们不与标准AP功能冲突，并且符合项目的安全性/安全性要求。除非它们是纯粹的应用程序本地运行时库，否则应该注意尽量减少这种使用，因为这将影响软件对其他AP实现的可移植性。
物理视图
OS，处理器，和线程
AP操作系统要提供多进程 POSIX OS的兼容性。每一个AA实现为一个独立的进程。自适应平台服务和非平台服务也实现为进程。
进程可以是一个单线程或多线程进程。可以使用OS API根据进程所属的逻辑层而有所不同。如果它们是运行在ARA之上的AAs，那么它们应该只使用PSE51。如果一个进程是功能集群之一，它可以自由使用任何可用的操作系统接口。
AA进程不能直接使用IPC，只能通过ARA进行通信。其他进程可以通过IPC或任何其他可用的OS功能相互交互。
基于库或基于服务的功能集群的实现
在图3-1 AP架构逻辑视图中，功能集群可以是自适应平台基础模块，也可以是自适应平台服务。如前所述，这两个过程通常都有。为了与同样是进程的AAs进行交互，它们需要使用IPC。有两种替代设计可以实现这一点。一种是基于库的设计，由功能集群提供的接口库链接到AA，直接调用IPC。另一种是基于服务的设计，流程使用通信管理功能，并有一个服务器代理库链接到AA。代理库调用通信管理接口，协调AA进程和Server进程之间的IPC。注意，它是由实现定义的，AA是否只直接执行IPC与通信管理或混合直接IPC与服务器通过代理库。为功能集群选择设计的一般原则是，如果它只在AP实例中本地使用，那么基于库的设计更合适，因为它更简单，也更高效。如果它以分布式方式从其他AP实例中使用，建议采用基于服务的设计，因为通信管理提供透明的通信，而不考虑客户端AA和服务的位置。自适应平台基础的功能集群是基于库的，自适应平台服务的功能集群是基于服务的。最后，需要注意的是，一个功能集群的实现可以没有进程，而是以库的形式实现，在AA进程的上下文中运行，只要它满足功能集群定义的需求规范和软件规范。在这种情况下，AA和功能集群之间的交互将是常规的过程调用，而不是像前面描述的那样基于IPC。
功能集群间的交互
通常，功能集群可以以AP实现的特定方式相互交互，因为它们没有绑定到ARA接口，比如限制IPC使用的PSE51。它可能确实使用了其他功能集群的ARA接口，这些接口是公共接口。功能集群之间的一个典型交互模型是使用功能集群的受保护接口来提供实现功能集群的特殊功能所需的特权访问。
机器/硬件
AP将其运行的硬件视为机器。背后的基本原理是，硬件可以使用各种与hypervisor相关的技术进行虚拟化，并实现一致的平台视图。在硬件上，可以有一个或多个机器，并且在一台机器上只能运行一个AP实例。通常假定该硬件包括一个芯片，托管一个或多个机器。但是，如果AP实现允许的话，多个芯片也可以组成一个机器。
方法论和清单
为了支持功能应用程序的分布式、独立和敏捷开发，需要在开发方法上采用标准化的方法。AUTOSAR自适应方法涉及到工作产品的标准化，用于描述工件(如服务、应用程序、机器及其配置);并在各自的任务中定义了这些工作产品应如何交互，以实现设计信息的交换，为自适应平台的产品开发所需的各种活动。图4.1说明了自适应AUTOSAR的开发工作流草案，其中涉及的步骤主要包含以下7步，最终将开发的软件集成入车辆中。
- E/E Architect Define Services
- ECU(Machine) Architect/Platform Software Cluster Architect
- Software Cluster Architect
- Application Developer
- Software Cluster Integrator
- ECU(Machine) Integrator
- Vehicle Integrator
相关概念介绍：
Machine：在AP的概念体系中，Machine代表一种计算资源，它可以是真实存在的处理器，也可以是一个虚拟机，AP软件则运行在某一个特定的Machine上。
Manifest：Manifest是一种AUTOSAR模型的描述文件，主要包含AP软件部署涉及到的一些配置信息（比如Service Instance Manifest会包括服务接口的版本信息，SD参数信息等内容）
操作系统
概述
操作系统负责运行时的资源和时间管理。EM负责平台初始化和应用的启动和停止，与操作系统协同工作。
AP没有为高性能的处理器指定操作系统。而是，其定义执行上下文和操作系统接口供AP应用使用。
OSI(操作系统接口)规范包含了ARA中部分应用接口以及AP应用的标准接口。OS本身可以很好地提供其他接口，例如创建进程，这是执行管理启动应用程序所需要的。然而，提供此类功能的接口，以及其他接口，不能作为ARA的一部分使用，它被定义为依赖于平台实现。
OSI同时提供C和c++接口。对于C程序，应用程序的主要源代码业务逻辑包括在POSIX标准中定义的C函数调用，即在IEEE1003.13[1]中定义的PSE51。在编译过程中，编译器决定来自平台操作系统的哪个C库提供了这些C函数，应用程序的可执行文件应该在运行时被链接。对于c++程序，应用软件组件的源代码包括在c++标准及其标准c++库中定义的函数调用。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！