【AutoSar】AutoSar规范各版本号对应关系

本文详细介绍了系统描述文件和虚拟功能总线描述文件的结构和用法，并提供了相应的源代码示例。AutoSAR描述文件主要分为两类：System Description（系统描述文件）和Virtual Functional Bus（虚拟功能总线）描述文件。虚拟功能总线组件描述（VFB Component Description）：描述了VFB中的各个组件，包括软件模块以及相应的接口和端口。系统描述文件是AutoSAR中最重要的描述文件之一，它用于描述整个汽车电子系统的组成结构和功能。AutoSAR描述文件详解。

AUTOSAR最新版本规范文档汇总、历史版本号记录。（https://www.autosar.org/）

AUTOSAR为复杂的车载系统提供了统一架构，而ARXML文件作为AUTOSAR的核心配置文件，承载着系统设计、组件定义和通信配置等关键信息，堪称整个开发流程的“蓝图”。但问题来了，当团队里不同人、不同工具，甚至不同供应商用着不同版本的ARXML文件时，麻烦就大了。兼容性问题可能会导致系统集成失败，代码生成出错，调试时一堆莫名其妙的bug，甚至直接拖慢项目进度，增加风险。面对这种乱象，咋办？

本文介绍了Classic AUTOSAR与Adaptive AUTOSAR规范版本之间的关系。

CP架构面向单机架构，AP架构采用SOA（service oriented architecture）理念，扩展为可适用于分布式系统。对比Autosar cp，Autosar ap的RTE在运行时连接各个service和client。当前的车机系统，一套硬件（CPU）多个虚拟机已经很普及，未来多套硬件（多个CPU）的系统也会普及。2005年发布的第一版AUTOSAR，开始不区分CP和AP，早期一个版本可以持续更新多年。AUTOSAR最新版本是R22-11，cp和ap都是这个版本。

您可以使用一些诊断和分析工具，如CANoe，CANalyzer，Trace32等，来监控和调试软件的运行情况。- 可以提高软件的协作性和互操作性，因为arxml文件是基于AUTOSAR架构的模块化设计，可以方便地将软件分解为不同的组件，并且可以与其他组件进行协同和集成。- 其次，您需要根据您的软件需求和架构，定义好arxml文件中的各种元素，如软件组件、端口、接口、信号、PDU、帧等。- 可以提高软件的可重用性和可移植性，因为arxml文件是基于XML的通用格式，可以在不同的工具和平台之间进行交换和转换。

AUTOSAR Overview of different version Stephen Du 1. AUTOSAR History Overview 2006200820102012201420162018V1.0 V2.0 V2.1 V3.0 V3.1 V4.0 V3.2 V4.1 V4.2 V4.3 V4.4 HistoryAUTOSAR Release 2. Summary of C...

1标准概况不同 1.1 时间 在2003年AUTOSAR组织刚成立的时候，只有一个AUTOSAR标准，没有AP（Adaptive Platform）与CP（Classic Platform）之分。 在2005年，AUTOSAR组织推出了第一个AUTOSAR版本1.0 在2017年，AUTOSAR组织推出了第一个AP AUTOSAR版本R1703，这是第一次外界看到AP AUTOSAR，AUTOSAR也是从这个时候起被分为AP与CP。此时，CP AUTOSAR版本命名为R4.x.x。 在外界看来，A

AUTOSAR网络管理需求规范1.概述1.1 AUTOSAR基本定义1.2 CAN总线基本介绍1.3 网络管理基本介绍2.CAN协议栈定义3.网络管理模式介绍3.1 运行模式3.1.1 Bus Sleep Mode3.1.2 Prepare Bus Sleep Mode3.1.3 NetworkMode3.2 定时器控制及参数3.3 网络管理报文3.4 总线休眠处理3.5 应答丢失行为处理 1.概述 1.1 AUTOSAR基本定义 1.2 CAN总线基本介绍 1.3 网络管理基本介绍 2.CAN协议栈定义

AUTOSAR规范根据MCU底层驱动功能的相似性，把MCAL抽象为4个驱动组，分别是微控制器驱动组（Microcontroller DriversGroup）、存储器驱动组（Memory Drivers Group）、通信驱动组（Communication Drivers Group）、输入/输出驱动组（I/O DriversGroup）。如下图所示，MCAL位于AUTOSAR软件架构中基本软件（Basic Software，BSW）的底层，是可以直接访问MCU寄存器和内部外设的底层驱动。

其他编码规范除了命名规范，AUTOSAR 编码标准还关注其他方面，如代码结构、代码风格、模块化设计、可维护性、内存管理等。为了保证系统的可靠性和可移植性，AUTOSAR 还强调以下几个要点：避免使用动态内存分配：由于嵌入式系统的内存有限，AUTOSAR 推荐使用静态内存分配。模块化和可配置性：系统应当模块化，并且各个模块之间的依赖应尽量减少。接口的标准化：接口的定义应尽量标准化，确保模块间的兼容性和可扩展性。

通信保护机制标准化与灵活性通过E2E Profile实现通信保护机制的标准化与灵活性，不同Profile组合了不同的数据保护机制，如CRC校验、计数器、数据ID等，以适应多样的通信场景和故障检测需求。每个Profile定义了消息格式、配置参数以及特定的控制字段组合，发送方添加控制字段保护数据，接收方评估这些字段来检测通信故障。错误检测与报告内部监督机制依据预定义的E2E Profile进行错误检测和报告，使用特定错误代码表示不同错误类型，如输入参数错误、函数执行成功等。

AUTOSAR规范与车用控制器软件开发

搞底层嵌入式的人员来说，需要MCAL层，而MCAL层有的厂商是需要付费的，而且价格很高，像英飞凌，等，而恩智浦提供有免费版和付费版的MCAL供用户使用，对于学习来说，大家可以到官网下载，需要有NXP的账号，可以在官网注册一个账号就可以下载。PDU被事先定义好的PDU路由表，发送到指定目的层（根据PDU ID来查找PDU的路由表），比如CAN总线的PDU就会路由到CanIf层，Lin的PDU就会路由到LinIf层。通常除了主版本外，还会有一些补丁包，补丁包也包含两类：HF(HotFix的缩写)和Patch。

AUTOSAR架构下，应用层软件与基础软件是最核心的两部分，前面说过应用层软件主要实现控制逻辑，一般采用图形化编程（simulink/stateflow），相信这部分对于大家来说都是不陌生的。那么基础软件主要做些什么工作呢？基础软件层基础软件可以分为服务层、ECU抽象层、微控制器抽象层和复杂驱动。其中：1、服务层提供了汽车嵌入式系统软件常用的一些服务，其可分为系统服务存储器服务以及通信服务三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统等服务。除了操作系统外，

我们在查看 AUTOSAR 代码的时候可以看到，每个 AUTOSAR 模块都有 GetVersionInfo 函数，里面管理了 AUTOSAR 的模块版本信息，我们来分解这个版本信息的含义。

AUTOSAR XML Schema生成规则定义了如何将AUTOSAR元模型映射到W3C XML Schema，从而建立了UML模型世界与XML描述世界之间的桥梁。标准化：提供了一种标准方法来表示AUTOSAR模型数据可配置性：通过标记值系统提供灵活的配置选项结构保存：保留了AUTOSAR元模型的类层次结构和关系互操作性：确保不同工具可以无缝交换AUTOSAR模型数据验证支持：通过XML Schema验证确保数据正确性。

Embedded Coder可基于Matlab/Simulink模型生成符合AUTOSAR规范的代码、描述文件（arxml），但在建模过程中，需要按一定的对应关系设计AUTOSAR软件组件的各个组成元素，所以在使用Matlab/Simulink进行基于模型的设计前，首先要清理AUTOSAR与Matlab/Simulink元素的对应关系。Simulink中设计完SWC内部行为，并且完成上述准备工作后，可以进行模型的配置，即将模型配置成AUTOSAR SWC。首先，需要新建一个函数调用子系统，如下所示。

AUTOSAR与OSEK的关系 AUTOSAR与OSEK二者都是汽车电子软件的标准。OSEK/VDX是基于ECU开发的操作系统标准，AUTOSAR基于整体汽车电子开发的功能标准。AUTOSAR中规定的操作系统标准就是基于OSEK/VDX，通信和网络管理虽然和OSEK有区别，但是是有继承性的。可以认为，AUTOSAR是基于OSEK/VDX发展出来的，OSEK/VDX被AUTOSAR标准软件架构所包含。