加入高工智能汽车行业群（自动驾驶5群，车联 智能座舱3群，智能商用车群），加微信：17157613659，并出示名片，仅限汽车零部件及OEM厂商。
AUTOSAR（汽车开放系统架构）是由汽车制造商和供应商在2003年发起的标准化倡议，其目标是为ECU软件开发一个参考体系结构，以克服现代车辆软件日益复杂的问题。
这要从为什么迁移到AUTOSAR开始说起。
有人可能会问，汽车行业真的需要如此复杂的体系结构吗？随着对联 汽车和更安全、更智能的汽车需求的增加，软件开发瓶颈已经出现。
过去，考虑一辆汽车，它有安全气囊，发动机控制单元，远程信息技术，信息娱乐等，所有这些单独的功能都是由不同的汽车供应商在不同的ecu上实现。
但未来，它们的实现方式不再是独立的。随着非标准开发过程的增加，这成为一个更加关键的问题。这些形成了AUTOSAR出现的根本原因。
未来，每个部分开发的软件不再只是针对交付预期的功能，转而必须考虑它如何影响整个系统。更复杂的是，过去许多功能分布在不同车辆 络(CAN、LIN、MOST等)的不同ecu上。
AUTOSAR分层架构在RTE的帮助下，确保了应用软件和硬件平台以及驱动程序之间的清晰划分。这有助于ECU设计方法从编码到配置模式的转变。
1、模块化：汽车软件的模块化，使软件能够根据电子控制单元及其任务的不同需求进行裁剪。
2、可伸缩性功能：可扩展性保证了通用软件模块对不同车辆平台的适应性，防止功能相似的软件泛滥。
3、可迁移：可转移性优化了整个车辆的电子架构中可用资源的使用。
4、可重用性：有助于提高产品质量和可靠性，同时降低跨产品线的重复资源投入。
5、标准化：跨制造商和供应商的功能接口标准化，以及不同软件层之间接口的标准化，这些被视为实现AUTOSAR技术目标的基础。
AUTOSAR分层架构是AUTOSAR的基本概念，是分离应用程序和基础硬件。应用程序部分由AUTOSAR软件组件和连接器组成。软件组件封装了每个子系统的功能。
上面的图显示了AUTOSAR方法的一个非常简洁的视图。
AUTOSAR体系结构主要包括三个软件层：应用程序层、运行时环境层和基础软件层。
基础软件是标准化的软件层，它为AUTOSAR软件组件提供服务，是运行软件功能部分所必需的。它本身不完成任何功能任务，并且位于AUTOSAR运行时环境之下，包含标准化和ECU特定组件。
AUTOSAR基础软件进一步划分为服务层、ECU抽象层、微控制器抽象层和复杂驱动层。
MCU抽象层对硬件的访问通过微控制器抽象层(MCAL)路由，以避免从更高级别的软件直接访问微控制器寄存器。
MCAL是一个特定于硬件的层，它确保基本软件组件的标准接口。它对MCU外围设备进行管理，并为基本软件的组成部分提供了与MCU无关的值。MCAL实现通知机制，以支持向不同进程分发命令、响应和信息。
复杂的设备驱动程序，此层用于其他层上未找到的复杂函数。这一层直接访问微控制器(MCU)，例如：注入控制、电量值控制、位置增加检测等。对于处理复杂的传感器和执行机构，这是一种特殊的功能和时间要求。
CDD（Complex Device Drivers）通过直接访问特定于uC的中断和外围设备，实现复杂的传感器评估和执行器控制。
ECU抽象层，此层接口与MCAL(包括外部设备驱动程序)，提供对外设和设备的访问，不论它们是在微控制器(MCU)内部还是外部，以及用于与微控制器(MCU)接口的API(端口插脚、接口类型)。它使得上层软件层独立于ECU硬件布局。
虚拟功能总线(VFB)，VFB是AUTOSAR所提供的基本软件的所有通信机制和基本接口的抽象集合，即独立于技术的层次。当为具体系统定义AUTOSAR软件组件之间的连接时，VFB将允许在早期开发阶段对它们进行虚拟集成。
运行环境(RTE)，从AUTOSAR软件组件的角度来看，RTE在特定的ECU上实现了VFB功能。然而，RTE可以尽可能地将此任务委托给基础软件。
AUTOSAR区分了三种类型的接口：
AUTOSAR Interface：AUTOSAR接口是一个通用接口，它派生自任何SWC的端口。
AUTOSAR接口由RTE提供，充当SWCs之间或SWC与ECU固件(IoHwAb，复杂驱动程序)之间的接口。例如，SWC可以通过这些接口读取输入值并编写输出值。
Standardized AUTOSAR Interface：标准化的AUTOSAR接口是由AUTOSAR标准预定义的特殊AUTOSAR接口。
SWCs使用这些类型的接口访问AUTOSAR服务，AUTOSAR服务由服务层的BSW模块提供，例如ECU状态管理器或诊断事件管理器。
Standardized Interface：标准化接口是AUTOSAR标准在C语言中将其预定义为API的接口。它用于ECU中的BSW模块之间、RTE与操作系统之间或RTE与BSW模块Com之间。
AutoSAR工作流
不过，对于面向自动驾驶，上述AUTOSAR经典平台已经不太适合，尤其是需要软件架构的灵活性来进行空中更新，这个时候就有了AUTOSAR自适应平台（AUTOSAR Adaptive Platform）。
自适应AUTOSAR并不是经典AUTOSAR的继承者；它不会取代它。相反，它是定义ECU软件及其如何在ECU硬件上运行的另一种方法。
为什么需要另一个AUTOSAR平台？
因为，对于自动驾驶，软件架构的需求已经发生了根本性的变化，比如需要更多的环境感知、多传感融合、远程通讯、软件定期更新等等。
而基于AUTOSAR经典平台设计软件体系结构，只能运行在小型专用硬件上(就计算能力而言)，不需要修改，通信是使用传统的汽车总线 络，这些都不能很好地满足自动驾驶、联 汽车的需求。
这时候，灵活性就是关键要素。
通过AUTOSAR自适应平台，软件功能之间的通信是面向服务的。此外，底层通信不再基于CAN或其他使用专用协议的经典汽车总线系统，而是基于以太 。
作为面向服务的中间件层，它定义了应用程序通信的实际方式。例如，您不再需要在代码行为中直接定义循环触发器时间。
此外，使用AUTOSAR经典平台，软件组件之间的通信是硬连接的，并由AUTOSAR运行环境(RTE)实现，RTE将通信从体系结构级别转换为ECU级别。它通过解析静态宏并将它们转换为适当的基本软件调用来实现这一点，例如，将它们包装成总线消息。
如果您想要在运行时替换软件，这是行不通的。自适应平台通过实现面向服务的通信体系结构，克服了硬连接通信的缺点。
同时，对于自动驾驶系统来说，特别是在传感器数据处理方面，是在Linux系统上开发的。我们需要操作系统提供的所有灵活性，包括灵活的内存分配、线程处理等等。
我们不想——也可能不能——放弃这种灵活性，因为我们必须为专门的ECU操作系统编译代码。因此，AUTOSAR自适应平台是基于POSIX接口的。
去年11月，AUTOSAR发布了最新版本的自适应平台（Release 18-10），具有数据分发服务(DDS)标准的完整 络绑定。随着新版本的发布，汽车制造商现在可以使用DDS实现AUTOSAR自适应框架，并开发L4/5高等级自动驾驶系统。
这意味着可用于量产的通信框架，提供这些复杂系统所需的可靠性、可扩展性和性能，它使开发人员能够动态配置平台，以支持不同车型平台的各种操作模式和硬件功能。
在AUTOSAR自适应平台中，DDS组件被优化为端到端数据共享，几乎不需要定制集成。因此，基于DDS的技术为汽车制造商提供了一个以数据为中心的互操作框架，支持常用的所有操作系统和处理器体系结构，从而消除了复杂的集成和安全挑战。
汽车制造商还可以利用AUTOSAR规范之外的其他技术，包括基于云的和后端系统，以及汽车行业中常见的附加组件，如MatLab和Simulink，以及DSpace、Linux和QNX平台。
要知道，让自动驾驶汽车上路不仅仅是技术和算法的问题。
（以下内容为丰田在去年发布的面向自动驾驶和高性能计算ECU的新软件平台的挑战的相关演示内容。）
有立场，有态度的智能 联汽车全产业链服务平台
商务合作咨询：15818636852 郑先生
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！