AUTOSAR学习

文章目录

前言
1. 什么是autosar？
- 1.1 AP（自适应平台autosar）
- 1.2 CP（经典平台autosar)
- 1.3 我的疑问
2. 为什么会有autosar
3.autosar的架构
- 3.1 CP的架构
- - 3.1.1 应用软件层
  - 3.1.2 运行时环境
  - 3.1.3 基础软件层
- 3.2 AP的架构
4. 参考资料

前言

前段时间参加系统架构师的软考，其中案例分析中的嵌入式题目是分析autosar架构，但是自己只是听说过汽车领域正在使用这个架构，实际上这个架构到底是什么？以及它有什么作用，则是全然不知，最终作为一个嵌入式工程师，案例题也没有选择这个嵌入式题目。其实软考会考这个东西再一定层面上就说明，国家或者当前社会这块的人才是有些稀缺的，然后想通过这种软考让更多的人去了解autosar架构。

另外最近在看机器人领域的工作，发现和ROS（机器人操作系统）相关的开发工作中很多都提到了要对autosar有一定的了解。
再加上近些年新能源汽车越来越火，很多相关的高薪嵌入式岗位中都要求对autosar有一定了解，就想着去学习一下，看看这个autosar到底是个啥。

因为属于自我科普的记录文章，所以不会太深入去进行研究和讨论。如果想要对autosar有个深入的了解，建议大家可以去参考资料中寻找对应的信息。

1. 什么是autosar？

Home Autosar是一个汽车软件架构，提供开放式汽车软件架构，帮助您应对日益复杂的代码挑战。该架构支持开发标准化的电子系统，可改进质量、性能、安全性和环保功能。它还有助于简化汽车使用寿命内软件的更新流程。

autosar目前分为两种，分别是CP（经典autosar）和AP（自适应autosar）。
在这里插入图片描述

1.1 AP（自适应平台autosar）

全称为自适应AUTOSAR平台（AUTOSAR Adaptive Platform，AP）
2018年，为了迎合未来汽车智能化、网联化的需求，AUTOSAR联盟推出的一个全新平台，将AP加入到原有的AUTOSAR平台中

官方介绍地址：https://www.autosar.org/standards/adaptive-platform

1.2 CP（经典平台autosar)

经典AUTOSAR平台（AUTOSAR Classic Platform)
官方介绍地址：https://www.autosar.org/standards/classic-platform

1.3 我的疑问

1.AP和CP的关系是啥？

AP 和 CP 在 AUTOSAR 中是相互补充、协同发展的关系：

一方面，它们共同构成了 AUTOSAR 架构以满足不同类型汽车电子系统的需求。CP 作为基础，在传统汽车电子领域发挥着重要作用，保障了车辆基本功能的稳定运行；AP 则适应新的发展趋势，为智能网联汽车提供了更强大的功能扩展和灵活性。

另一方面，它们之间也存在一定的过渡和融合。随着技术的发展，一些 CP 上的功能可能会逐渐向 AP 迁移或融合，以实现更高效的系统整合和创新。并且在实际应用中，一辆车上可能同时存在基于 CP 和 AP 的不同系统，它们之间需要进行良好的协同和交互。

2. AP和CP的区别是啥？

  应用场景：面向汽车电子的基础控制领域
  硬件要求：对处理器要求不高，经常是运行在8 位、16 位、32 位的微控制器（MCU）中
  操作系统：一般采用实时操作系统RTOS

  应用场景：面向主要面向高度智能化、联网化且功能需求不断变化的复杂应用场景
  硬件要求：对处理器要求较高，一般是运行在64位的高性能处理器（MPU）或CPU中
  操作系统：一般是兼容POSIX的操作系统，如LINUX

2. 为什么会有autosar

随着电子技术在动力总成控制、底盘控制、车身控制以及车载信息娱乐系统等各个部分所占的比重越来越大、所占的整车成本也越来越高，电子技术已悄悄成为汽车各方面功能拓展和性能提升的重要技术支撑。

为了满足汽车电子硬件系统的多样性，提高软件的模块化和复用度，减少研发成本、降低研发周期。因此在 2003 年，基于先前 EAST-EEA 项目的研究成果，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（Automotive Open System Architecture），即 AUTOSAR。

autosar的特点：
在讨论为什么有autosar时，其实我们也可以看一下autosar有哪些优点，知道了他有哪些优点，也就大概能够反推为什么汽车电子领域会需要autosar了

高度的标准化
通过定义一整套全面且细致的标准和规范，包括软件架构、接口定义、通信协议等各个方面，确保了不同的汽车电子组件和系统能够在统一的框架下和谐共存、协同工作，避免了因缺乏标准而导致的兼容性问题和混乱局面，极大地提升了系统的整体协调性和稳定性。
AUTOSAR 具备强大的可扩展性
其架构设计灵活，能够轻松容纳新的功能和技术的融入。无论是新的传感器、执行器的加入，还是新的软件模块的引入，都可以较为顺畅地与现有系统进行整合，无需对整个体系进行大规模的重构，这使得汽车电子系统能够快速适应不断变化的技术发展趋势和用户多样化的需求，保持与时俱进的能力。
软件复用性在 AUTOSAR 中得到了高度的体现
它创建了一个有利于软件组件重复使用的环境，减少了重复开发的工作量和成本。开发人员可以从已有的软件库中挑选合适的组件，并根据具体项目需求进行定制和组合，从而大大提高了开发效率，缩短了产品的上市时间，同时也保障了软件质量的一致性和可靠性。
AUTOSAR 对于安全性和可靠性的保障极为重视
它制定了严格的安全准则和测试要求，对软件的开发、验证和部署过程进行严格把控。通过严格的质量控制和风险评估机制，确保软件在各种复杂环境和工况下都能稳定、安全地运行，降低潜在故障和风险发生的可能性，为驾驶者提供了高度可靠的行车保障。
AUTOSAR 还具有良好的兼容性和互操作性
不同的汽车制造商、零部件供应商以及软件开发商都可以在这一统一的平台上进行合作和交流。它打破了传统的技术壁垒和界限，促进了整个汽车产业链的协同发展，使得各方资源能够更加高效地整合和利用，共同推动汽车电子技术的进步和创新。

3.autosar的架构

3.1 CP的架构

完整版本：
在这里插入图片描述
简化版本：

3.1.1 应用软件层

包含若干个软件组件（Software Component，SWC），这些组件实现了具体的车辆功能，每个软件组件都具有明确的功能定义和接口，比如控制类组件，负责对车辆的某些系统进行精确控制；监测类组件，实时监控车辆的状态和参数；通信类组件，处理与其他 ECU 或外部系统的信息交互等。

软件组件间通过端口（Port）进行交互。每个软件组件可以包含一个或者多个运行实体（Runnable Entity，RE），运行实体中封装了相关控制算法，其可由 RTE 事件（RTE Event）触发。

我的疑问
- autosar组件中的端口是指socket的端口吗？
  在 AUTOSAR 中，端口（Port）并不是指网络编程中的 Socket 端口。在 AUTOSAR 架构中，端口是软件组件（Software Component，SWC）之间进行通信的接口。每个端口都有明确的定义和功能，用于在不同的软件组件之间传递数据和控制信息。
- autosar中的SWC又是个啥？
  SWC（Software Component）即软件组件，是 AUTOSAR 架构中的核心概念之一。它是一个独立的、可重用的、自我描述的、可替换的软件单元，具有清晰的输入输出接口。
  
  在使用 AUTOSAR 架构时，开发人员首先需要将整个汽车电子系统分解为不同的 SWC，每个 SWC 都应具有特定的功能，如传感器数据处理、控制算法、用户界面等，同时需要定义其输入输出接口以及其它自述和控制接口，这些接口都要符合 AUTOSAR 定义的规范。

3.1.2 运行时环境

AUTOSAR 运行时环境（Runtime Environment，RTE）作为应用软件层和基础软件层交互的桥梁，为软硬件分离提供了可能。RTE 可以实现软件组件间、基础软件间以及软件组件和基础软件之间的通信

RTE 封装了基础软件层的通信和服务，为应用层软件组件提供了标准化的基础软件和通信接口，使得应用层可以通过 RTE 接口函数调用基础软件的服务。

虚拟功能总线VFB及运行环境RTE

虚拟功能总线（VFB）是底层基础软件与网络拓扑结构的抽象。是AutoSar提供的所有通信机制的集合，在信息学数据交互的过程中，应用程序被建模为组合组件。软件组件之间通过VFB进行通讯的。

在系统配置时，软件组件会被映射到制定的ECU上，同时组件间的虚拟连接也被映射到了CAN，FlexRay, MOST等总线上。

需要注意的是 RTE也就是单个ECU上对VFB接口的实现。

使用虚拟功能总线，可以使得负责应用层软件的开发人员不用去关心一个软件组件最终在整车中的哪个 ECU 中具体实现，从而使得应用软件的开发可以独立于具体的 ECU 开发。因此，可以让应用软件开发人员专注于应用软件组件的开发。而 VFB 的真实通信实现则由 RTE 和基础软件来保证，从这一角度来看，RTE 是 AUTOSAR 虚拟功能总线的具体实现。
什么是AUTOSAR中的ECU？

ECU可以看作是一个单独的芯片或者说是微型计算机。
汽车电子中要控制那么多的电子器件，不同的电子器件对实时性和性能要求又不一样，因此一辆汽车中肯定是有多个控制芯片组成的。
不同的控制芯片就是不同的ECU。

虽然一辆完整的汽车，物理上是不同的控制芯片组成，但是在用户的角度来看整个汽车仍然是一个实体，所以不同的ECU之间是要进行交互和通讯的。这也就引出了VFB虚拟总线的概念。不同的ECU去实现该协议，然后借助WIFI或者CAN等通过该协议进行设备发现，状态同步等功能。

3.1.3 基础软件层

在这里插入图片描述

AUTOSAR 基础软件层（Basic Software Layer，BSW）又可分为四层，即服务层（Services Layer）、ECU 抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstraction Layer，MCAL）和复杂驱动（Complex Drivers）。

服务层
- 通信服务：
  • 也就是对CAN、LIN、FlexRay在内的整车网络系统进行统一封装。
  • 对上层应用隐藏协议以及报文属性，也就是说上层应用无需关注通信是通过CAN还是LIN 去进行的。
  • 提供统一的总线通信接口、网络管理服务、诊断通讯服务
- 内存服务
  • 也就是对内存访问进行了统一的封装。
- 系统服务
  • 提供RTOS服务，包括中断管理、资源管理、任务管理等
ECU抽象层
ECU 抽象层（ECU Abstraction Layer）包括板载设备抽象、存储器硬件抽象、通信硬件抽象和 I/O 硬件抽象。该层将 ECU 结构进行了抽象，负责提供统一的访问接口，实现对通信、存储器以及 I/O 的访问，从而不需要考虑这些资源是由微控制器片内提供的，还是由微控制器片外设备提供的。该层与 ECU 平台相关，但与微控制器无关，这种无关性正是由微控制器抽象层来实现的。

刚开始我以为ECU抽象层应该就是微控制器抽象层，但实际上它是在微控制器之上的一层，可以把微控制器抽象层理解为驱动层。
当驱动有了之后，应用层在使用时很少会直接使用驱动，因为驱动提供的接口很全，但是使用起来也会更加麻烦，我理解ECU应该是对驱动又进行了一些封装。
微控制器抽象层
微控制器抽象层（Microcontroller Abstraction Layer，MCAL）是实现不同硬件接口统一化的特殊层。通过微控制器抽象层可将硬件封装起来，避免上层软件直接对微控制器的寄存器进行操作。微控制器抽象层包括微控制器驱动、存储器驱动、通信驱动、I/O 驱动等模块。
复杂驱动层
由于对复杂传感器和执行器进行操作的模块涉及严格的时序问题，难以抽象，所以在 AUTOSAR 规范中这部分没有被标准化，统称为复杂驱动（Complex Drivers）。