作者 ：刘向
什么是 Adaptive AUTOSAR？
Adaptive AUTOSAR 是一种新的汽车软件框架，旨在满足现代汽车行业中不断增长的技术需求。随着汽车变得越来越智能，对处理器的性能要求也在不断增长。 Adaptive AUTOSAR 旨在通过提供高性能计算和通信机制以及灵活的软件配置来满足这些需求，为车联网和远程诊断、自动驾驶汽车铺平道路。
Adaptive AUTOSAR 为新应用程序（如高度自动驾驶、V2X、OTA 软件更新或车辆作为物联网的一部分）提供了支持，这些应用程序对下一代 ECU 的软件平台提出了全新的要求。它支持客户应用程序的动态部署，为需要高端计算能力的应用程序提供环境，并以平滑的方式连接深度嵌入式和非 AUTOSAR 系统，同时保留典型的深度嵌入式系统功能，如安全性、确定性和实时能力。 总之，Adaptive AUTOSAR 正在成为未来汽车 ECU 不可或缺的一部分。
图示是最新 AP R22-11 标准，相较以往版本， 新版本 AP 平台在 CAN、防火墙、面向服务车辆诊断等技术方面做了新增或改进。R22-11 版本新增了入侵检测系统管理和防火墙功能模块等。
为什么需要 Adaptive AUTOSAR？
汽车行业的电子电气架构需要统一标准和灵活性，主要是为了提高开发效率、降低成本并支持创新。
统一标准可以促进不同供应商之间的互操作性、可复用性，使得汽车制造商能够更容易地集成来自不同供应商的组件。这有助于降低开发成本，缩短开发时间，并提高产品质量。
灵活性则可以支持汽车制造商快速响应市场需求，开发新功能和创新产品。随着汽车行业的快速发展，汽车制造商需要能够快速适应新技术和新标准，灵活性可以帮助他们更快地推出新产品。
因此，统一标准和灵活性对于汽车行业的电子电气架构至关重要。
不使用 Adaptive AUTOSAR 行不行？
可以不用 Adaptive AUTOSAR，但是必须得有统一的电子电气软件架构，这对软件通用性，可移植性，稳定性非常重要。软件最重要的价值在于通用性：
- 灵活的软件配置，支持运行时软件更新（OTA），可以实现更快的功能迭代和改进。
- 面向服务的通信，提供了一系列标准化的服务接口和协议，用于实现各种汽车应用程序之间的通信和交互。
- 多协议和多硬件平台支持，可以根据实际需求选择最适合的通信协议和硬件平台。
- 标准化开发，提供了一系列标准化的 API 和协议，使得开发人员可以轻松地进行应用程序的集成和部署。
特斯拉没采用 AUTOSAR，他们是怎么解决基础软件问题的？
特斯拉没有采用 AUTOSAR 标准，而是采用了自主研发的基础软件和操作系统。他们是通过以下几种方式解决基础软件问题的：
1、自主开发， 即特斯拉自己设计和编写了车辆的基础软件和操作系统，包括车载电脑、摄像头、传感器、控制器等的软件¹。这种方式要求特斯拉具备强大的软件研发能力和创新能力，同时也面临着技术风险和维护成本。
2、 利用开源 ，即特斯拉利用了开源社区的资源和贡献，使用了一些开源的软件组件和工具，例如 Linux 内核、Qt 框架、TensorFlow 框架等。这种方式要求特斯拉遵守开源协议和规范，同时也需要与开源社区保持良好的沟通和合作。
3、第三方工具 ，即特斯拉借助了一些第三方的软件工具和平台，例如 TeslaFi、TeslaMate、Tezlab 等。这些工具可以提供一些额外的功能和服务，例如数据统计、行程记录、车辆控制等。
这种方式要求特斯拉与第三方工具提供者建立信任和合作关系，同时也需要保证车辆的安全性和隐私性。
AUTOSAR CP and AP 的对比
Adaptive Autosar 与 Classic Autosar 相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，如自动驾驶，引入了特别复杂、对计算资源要求很高的软件，同时还必须遵守完整性、安全性要求。这些软件实现了环境感知、行为规划、和后端系统集成等功能。在车辆的生命周期内，软件要不断升级，不断磨合，进行功能改进。
1、CP 和 AP 不是为了谁取代谁，而是针对不同的应用领域和不同的功能安全要求相辅相成。
2、CP 和 AP 都在持续开发和完善中
3、具有共同的基础并独立发布
AUTOSAR CP 与 AP 有什么差异？
AP AUTOSAR 是一种新的汽车软件平台，它可以适应未来的高性能计算和自动驾驶的需求。它与传统的 CP AUTOSAR 有很多不同之处，下面我简单地介绍一下：
1、AP AUTOSAR 是基于服务的架构，而 CP AUTOSAR 是基于组件的架构 。这意味着 AP AUTOSAR 的应用程序可以动态地连接和使用不同的服务，而不需要预先定义好接口和配置。CP AUTOSAR 的应用程序则需要在编译时确定好组件之间的连接和通信方式。
2、AP AUTOSAR 使用 POSIX 操作系统，而 CP AUTOSAR 使用 OSEK 操作系统。 这意味着 AP AUTOSAR 可以运行在更多种类的硬件平台上，也可以利用现有的 POSIX 兼容的软件库和工具。CP AUTOSAR 则需要专门为 OSEK 开发和优化软件。
3、AP AUTOSAR 支持多核处理器，而 CP AUTOSAR 通常运行在单核处理器。 这意味着 AP AUTOSAR 可以充分利用多核处理器的并行计算能力，提高性能和效率。CP AUTOSAR 则需要通过分时调度或者分布式系统来实现多任务处理，（通常一次只运行一个程序）。
4、AP AUTOSAR 支持网络管理和更新配置管理，而 CP AUTOSAR 不完全支持。 这意味着 AP AUTOSAR 可以在运行时动态地管理网络拓扑和节点状态，也可以远程地更新和配置软件。CP AUTOSAR 则需要在启动时确定好网络结构和节点功能，也需要通过物理介质来更新和配置软件。
5、AP AUTOSAR 通常运行在 SOC 之上，而 CP 通常运行在 MCU 上。 这意味着 AP 的硬件主频相对较高，使用 POSIX 操作系统，支持多进程的程序。基于 AP 开发的 ECU 具有更加智能、更大的计算力（基于 SOA 架构使得 AP 能够支持多核并行处理）拥有更好的兼容性，功能服务化，接口统一化。更容易实现基于以太网的 SOA 通信，适合无线，远程，云连接以及部署 V2X 应用。而 CP 使用 RTOS 操作系统是以 task 的形式，类似于多线程，它运行不了多进程的程序，功耗更低。
6、虽然 C 语言是嵌入式系统的主要编程语言，具有执行速度快、效率高的特点；但是在性能要求非常高的复杂应用和算法开发上（如机器学习、图像特征识别等）具有面向对象特性的 C++显然比 C 更具有优势。 另外 CP 和 AP 的软件架构也是不一样的。
SOA 就是一种面向服务的架构，它是一种粗粒度，松耦合的服务架构。服务之间通过简单精确定义的接口进行通信，不涉及底层通信接口和通信模型，大幅增强了软件的可复用性。
现有的 Linux 是一个通用的操作系统，是按照分时系统设计的，进程调度强调平衡各进程之间的响应时间来保证公平的 CPU 时间占用，以获得最大的整体性能，这也正是通用操作系统的设计原则。
虽然在后来的 2.6 版本开始，加入了内核抢占的功能，使它的实时性得到了提升，在某种程度上具备了软实时的能力。
AUTOSAR 经典平台适用于嵌入式系统，通过 RTE 为基础软件和应用软件提供了基础的应用环境资源池以及 API，对外接口封装成 RTE 的形式，主要目的有两个：
- 一个是 实现接口的并发访问，由系统来保证接口调用在多核场景下不发生冲突。
- 另一个是 通过注册之后，代码生成工具可以控制每个模块能够访问的接口，在整个的逻辑上更加清晰，最终实现软硬件的分层解耦，实现软件在不同平台上的复用。
CP AUTOSAR 和 AP AUTOSAR 的优缺点是什么？
CP AUTOSAR 和 AP AUTOSAR 都是 AUTOSAR 标准的两种变体，分别适用于不同的应用场景和需求。它们各有优缺点，下面简要地总结一下：
CP AUTOSAR 的优点是：
- 适合于深度嵌入式的电子控制单元（ECU），如车身控制、底盘控制、动力系统等，可以满足实时性、可靠性、安全性等方面的要求。
- 采用了虚拟功能总线（VFB）的概念，实现了应用层软件组件与基础软件层服务的解耦，支持硬件无关的软件开发。
- 标准化程度高，规范了详细的接口和配置方法，便于不同厂商之间的软件互操作和重用。
CP AUTOSAR 的缺点是：
- 基于 C 语言开发，面向过程，不支持面向对象和泛型等高级特性。
- 基于 OSEK 操作系统，需要专门为 OSEK 开发和优化软件，不能利用现有的 POSIX 兼容的软件库和工具。
- 只支持单核处理器，不能充分利用多核处理器的并行计算能力。
- 采用基于信号的静态配置通信方式，需要在编译时确定好组件之间的连接和通信方式，不支持动态地管理网络拓扑和节点状态。
- 不支持动态更新和配置软件，需要通过物理介质来更新和配置软件，不能适应外部系统的变化。
AP AUTOSAR 的优点是：
- 适合于高性能计算和自动驾驶等应用场景，如环境感知、行为规划、车辆与外部系统的集成等，可以提供更强大的功能和灵活性。
- 基于 C++语言开发，面向对象，支持泛型、模板、多态等高级特性。
- 基于 POSIX 操作系统，可以运行在多种硬件平台上，也可以利用现有的 POSIX 兼容的软件库和工具。
- 支持多核处理器，可以充分利用多核处理器的并行计算能力，提高性能和效率。
- 采用基于服务的动态通信方式，可以在运行时动态地连接和使用不同的服务，不需要预先定义好接口和配置。
- 支持网络管理和更新配置管理，可以在运行时动态地管理网络拓扑和节点状态，也可以远程地更新和配置软件。
AP AUTOSAR 的缺点是：
- 标准化程度低，只规定了一些 API 和语义，并没有详细地规范每个服务或组件的实现方式，导致不同厂商之间的软件互操作性和重用性较差。
- 面向服务的架构增加了通信开销和复杂度，需要更高带宽和更好的网络管理能力。
- 动态更新和配置软件可能带来安全性和稳定性方面的风险，需要更严格的验证和测试方法。
CP AUTOSAR 与 AP AUTOSAR 的分层架构
CP AUTOSAR 规范主要包括分层架构、方法论和应用接口三个部分。其中，分层架构是实现软硬件分离的关键，它让 ECU 软件开发和验证摆脱了对硬件系统的依赖，在 CP AUTOSAR 分层架构中，从上到下分别为：
- 应用软件层（Application software Layer ASW）
- 运行时环境（Runtime Environment）
- 基础软件层（Basic Software Layer）
基础软件层又可分为四层：包括服务层、ECU 抽象层、微控制器抽象层和复杂驱动。各层又由一系列基础软件组件构成，包括系统服务、存储服务、通信服务等，它们主要用于提供标准化的基础软件服务。
为保证上层与下层的无关性，通常每层只能使用下一层所提供的接口，并向上一层提供相应的接口。BSW 是可配置的，并且可以被多个产品线的 ECU 重复使用
从整体上来看 AP 的架构也是分层的，AP AUTOSAR 构建在 POSIX 操作系统之上，由不同的功能模块组成，这些模块被划分在服务模块和基础模块。
AUTOSAR Adaptive Platform 的基本构成包括以下几个方面：
1、应用程序层（Application Layer） ：是 AUTOSAR Adaptive Platform 中的最高层，它包括了所有的应用程序组件。应用程序层通过服务层和运行时层与其他组件进行通信和协作，以实现整个应用程序的功能。
2、AP 中间层 ：供了一系列的标准化服务，例如通信服务、诊断服务、存储服务等。这些服务为应用程序组件提供了一些基本的功能和接口，以便它们能够相互通信和协作。这些组件和服务为应用程序组件提供了一个运行环境，以便它们能够在 AUTOSAR Adaptive Platform 中运行。
3、操作系统层（Operating System Layer） ：AUTOSAR Adaptive Platform 使用基于 POSIX 标准的操作系统，例如 Linux 或 QNX。操作系统层提供了一些基本的操作系统服务和驱动程序，例如内存管理、进程管理、文件系统、网络协议栈、设备驱动程序等。这些服务和驱动程序为运行时层和应用程序层提供了底层的支持。
4、硬件抽象层（Hardware Abstraction Layer） ：硬件抽象层提供了一个通用的硬件接口，以便 AUTOSAR Adaptive Platform 可以在不同的硬件平台上运行。硬件抽象层将硬件平台与操作系统层和运行时层分开，以便 AUTOSAR Adaptive Platform 可以在不同的硬件平台上进行移植和扩展。
这些组件通过标准化的接口进行通信和协作，以实现整个 AUTOSAR Adaptive Platform 的功能。
车企为什么往往自研 AP AUTOSAR？
车企自主开发基于 AP AUTOSAR 标准的软件平台，而不使用第三方提供的 AP AUTOSAR 中间件，有以下优缺点：
优点：
- 可以实现软件的自主可控 ，不受第三方的限制和影响，可以根据自身的需求和特色进行定制和优化，提升软件的竞争力和创新力。例如，华为自研 AP AUTOSAR 可以结合自研微控制器芯片，实现软硬件垂直整合优化，提高质量和安全性。
- 可能可以降低成本和风险 ，避免购买第三方提供的 AP AUTOSAR 中间件所需的昂贵的费用，也避免因为第三方的技术问题或者合作变化而导致的项目延误或失败。例如，特斯拉自研了基于 Linux 开发的实时操作系统，而不使用 AP AUTOSAR 中间件。
- 可以适应未来的软件定义汽车的需求，提供更强大的功能和灵活性 。AP AUTOSAR 是一种面向高性能计算和自动驾驶等应用场景的软件平台，它提供了基于服务的动态通信方式，支持网络管理和更新配置管理，以及 POSIX 操作系统和多核处理器等特性。
缺点：
- 需要投入更多的人力物力 ，建立自己的软件开发团队和工具链，承担更多的技术难题和挑战。
- 需要与第三方进行更多的沟通和协调 ，保证软件的互操作性和兼容性，遵循相关的技术标准和规范。
- 需要承担更多的责任和风险 ，保证软件的质量和安全性，通过相关的验证和测试方法。
汽车行业是否会诞生广义的操作系统？
各大车企都在研发自己的 OEM.OS，是否有机会诞生标准化的广义汽车操作系统？
车载 OS 是车企与用户交互的重要窗口 ，它的好与坏直接影响到产品的竞争力和创新力。
车载 OS 是实现软件定义汽车和智能网联驾驶的基础和核心 ，它可以提供整车及部件感知、规划、控制等功能框架，并支持多样化的应用和服务。
自主研发车载 OS 可以实现软件的自主可控 ，不受第三方的限制和影响，可以根据自身的需求和特色进行定制和优化，提升软件的安全性和灵活性。
自主研发车载 OS 可以降低成本和风险 ，避免购买第三方提供的车载 OS 所需的昂贵的费用，也避免因为第三方的技术问题或者合作变化而导致的项目延误或失败。
目前，车载 OS 主要分为安全车载操作系统、智能驾驶操作系统和智能座舱操作系统三类。不同类别的车载 OS 有不同的技术特点和应用场景，也面临着不同的标准化需求和价值。
一般来说，安全车载操作系统对实时性和安全性要求极高，生态发展已趋于成熟，标准化程度较高；智能驾驶操作系统对安全性和可靠性要求较高，同时对性能和运算能力的要求也较高，生态尚未完备，标准化程度较低；
智能座舱操作系统对实时性和可靠性要求并不严苛，但需要支持多样化的应用和服务，并且具有丰富的生态资源，标准化程度中等。
目前，汽车行业还没有出现一个统一的标准化的广义汽车操作系统，不同的车企和供应商都有自己的软件平台和解决方案，导致软件的互操作性和重用性较差，也增加了维护和更新的复杂度。但是，随着汽车软件定义化、智能化、网联化的趋势，标准化的广义汽车操作系统的需求和价值也越来越明显。是否有机会诞生标准化的广义汽车操作系统，并没有一个确定的答案。这取决于各大车企在不同领域的技术路线、合作意愿、市场策略以及相关技术标准和规范的制定和推广等多方面因素。目前看来：
- 在安全车载操作系统领域，已经有了 AUTOSAR 等成熟的标准体系；
- 在智能驾驶操作系统领域，还没有形成统一的标准体系，但也有一些行业组织在推动相关工作；
- 在智能座舱操作系统领域，由于应用和服务的多样性和个性化需求较强，标准化可能更难实现。
