当前位置：首页 > news >正文

【汽车电子架构】AutoSAR从放弃到入门专栏导读

news 来源：原创 2025/5/16 7:17:47

本文是汽车电子架构：AutoSAR从放弃到入门专栏的导读篇。文章延续专栏文章的一贯作风，从概念与定义入手，希望读者能对AutoSAR架构有一个整体的认识，然后对专栏涉及的文章进行分类与链接。本文首先从AutoSAR汽车软件架构的概念，架构以及方法与模版三个方面帮助读者能够在一个更高的抽象角度理解这个架构的思想。然后依据笔者自身的开发经历，对整个AutoSAR入门学习的路线进行简单的分类之后，梳理了一套AutoSAR入门学习的路线图，依据能够构成一个ECU最小基础工程的理念，把专栏中包含的必要基础软件模块分别链接到专栏中具体模块的详细介绍，帮助读者根据自己的情况更好的查找到对应的模块详解文章。

写在前面

概述

Concept（概念）

Architecture（架构）

Methodology and Templates（方法论与模版）

方法论概念

整体工作流程

模版

AutoSAR学习路线图

MCAL

BSW软件模块

系统集成开发

写在前面

本专栏的文章采用的结构为：概念->实战->验证，均从三个角度来帮助读者对AutoSAR模块有一个全方位的了解（BSW中的纯软模块通过代码的阅读完成了功能验证的角度解读）。文章中概念的解读大部分来自于规范文档本身（笔者根据自身的开发经历做了一些删减和结构调整）；实战部分则着眼于最基础的应用，做了详细的介绍个配置过程解读；最后，则是对具体模块的验证和使用测试过程，帮助读者能对模块有更直观的认识。

因为本专栏的文章系我一个人码的，所有难免会有一些笔/思误，且在解读AutoSAR规范的过程中，笔者也遇到过前后矛盾的情况，所以希望广大读者，如果在阅读本人的文章中发现错误或者跟您在实际应用开发过程中有出入的情况时，给我在文后评论留言，我一定尽快回复大家，一起讨论技术问题，共同塑造一个有对AutoSAR学习有普遍指导意义的专栏，这个专栏以及后续的文章会一直保持免费，感谢大家的付出：）。

最后，经过我这一年以来的总结学习，深知一个人的能力力量有限，这个系列的专栏我本打算分成三步，首先是现在这个开题的入门专栏，然后再做一个以解决项目中实际遇到的问题为导向的分享专栏，最后再做一个用“手写”代码逐步对模块进行替代的专栏，其中还想穿插一些用Simulink进行应用层开发的知识。如果有想共创、接棒的童鞋，私信联系我，没什么回报哈，就是单纯的做些事情，师夷长技以制夷，我这边一定全力配合。

概述

AutoSAR（Automotive Open System Architecture）是汽车电子行业的一个开放且标准化的软件架构，它促进了不同供应商之间的软件兼容性和互操作性。标准上合作，实现上竞争（Cooperate on standards，Compete on implementation），AutoSAR作为汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，帮助大家能够专注于功能的开发，而无需顾虑其他主体开发的功能模块以及目标硬件平台。它主要完成了以下的目标：

基于定义的概念（Concept），一个基本的概念是虚拟功能总线(VFB)，应用程序间通过虚拟总线进行交互，VFB处理单个ECU内部和ECU之间的通信。
基于定义的分层架构（Architecture），给出一个控制器软件参考架构，通过软件抽象层RTE(运行时环境)将独立于硬件的应用软件和面向硬件的基础软件分离，并将汽车系统的基础软件标准化为一个跨OEM的标准栈。
基于定义的方法论和模板（Methodology and Templates），为应用程序的开发提供方法论，定义模块间的通信接口。规范分布式开发流程中不同模块间的交换描述格式（遵循AUTOSAR Schema的.arxml文件），各种生成器可以利用描述中的信息来支持RTE和AUTOSAR基础软件软件(包括操作系统)的配置和生成。

Concept（概念）

AUTOSAR中，应用程序被建模为相互连接的组件的组合，如下图的上半部分所示(标记为“VFB view”)，而虚拟功能总线是允许这些组件交互的通信机制，这些组件可以按需要映射到特定的系统资源(ECU)中。因此，组件之间的虚拟连接映射到本地连接(在一个ECU内)或映射到网络技术特定的通信机制(例如CAN或者FlexRay帧）。最后，针对每个独立的ECU可以配置生成对应的RTE和BSW，组件之间以及组件与BSW(基础软件模块)之间的具体连接关系称为运行时环境(RTE)。

虚拟功能总线的概念允许应用程序和其余组件之间严格分离。实现应用程序的软件组件在很大程度上独立于其他组件或硬件(如传感器或执行器)交互的通信机制。这实现了AUTOSAR的可重用性目标。通过这种方式，可以指定系统的完整通信，包括所有通信源和目标位置，因此，VFB可用于对软件组件的通信进行合理性检查。通信连接和连接的软件组件保存在一个描述中，该描述将用于后续处理步骤(映射、软件配置等)。VFB规范需要为实现汽车应用的组件所需的所有基础设施服务提供概念。这些包括：

与系统中其他组件的通信。
与系统中的传感器和执行器的通信。
访问标准化服务，例如读取或写入非易失性RAM。
响应模式变化，例如本地ECU的电源状态变化。

Architecture（架构）

AUTOSAR是专门为汽车ECU设计的。这些ECU具有以下特性：

与硬件(传感器和执行器)的复杂交互作用。
连接到车辆网络，如CAN、LIN、FlexRay或以太网。
微控制器(通常为16位或32位)具有有限的计算能力和内存资源。

AUTOSAR架构在最高抽象级别上区分了三个软件层：应用程序、运行环境和基础软件，这些层运行在微控制器上。

AUTOSAR基础软件进一步分为以下几个层次：系统服务、ECU抽象、单片机抽象和复杂驱动程序。

基础软件层被进一步按功能划分为不同的服务组。服务示例包括系统、内存和通信服务。

微控制器抽象层是基本软件的最低软件层。它包含内部驱动程序，这些驱动程序是直接访问Microcontroller和其内部外设。它可以使上层的模块与Microcontroller尽可能解耦。

ECU抽象层是从ECU的角度进一步封装了微控制器抽象层的驱动程序，它主要包含外部设备的驱动程序。用于提供访问微控制器芯片外围硬件芯片的API（微控制器芯片内部的功能API也在这里再次封装供上层使用）。这一层的主要目标是实现更高的软件层独立于ECU的硬件设计。

复杂驱动程序层提供给RTE直接访问硬件渠道。它提供了实现AUTOSAR规范外功能的可能性，例如设备通信（Wifi、RF通信），硬件加速核等驱动的实现。

服务层是基础软件的最高层，应用软件。虽然I/O信号的工作由ECU抽象层负责，但服务层提供：

类操作系统功能。
车辆网络通信和管理服务。
内存服务(NVRAM管理)。
诊断服务(包括UDS通信、错误存储和故障处理)。
ECU状态管理、模式管理。
程序监控(Wdg manager)。

RTE是为应用软件(AUTOSAR软件组件和/或AUTOSAR传感器/执行器组件)提供通信服务的层。
在RTE上方，软件架构的风格从“分层”变为“组件”风格。AUTOSAR软件组件通过RTE与其他组件(ECU内部和/或内部)通信。这层主要实现AUTOSAR软件组件独立于对特定ECU。

基础软件可以细分为以下几类服务：

Input/Output (I/O)：对传感器、执行器和车载ECU外围设备的标准化访问。
Memory：对内部/外部存储器(非易失性存储器)的标准化访问。
Crypto：对加密服务(包括内部/外部硬件加速器)的标准化访问。
Communication：对车辆网络通信系统、ECU板上通信和ECU内部软件的标准化访问。
Off-board Communication：:车对X通信、车内无线网络系统、ECU板外通信系统的标准化访问。
System：提供标准化系统服务(调度器、定时器、错误存储器)和ECU专用(ECU状态管理、watchdog管理）服务和库功能。

驱动程序包含控制和访问内部或外部功能集成电路的能力。微控制器内部的功能集成电路（微控制器片内外设）的驱动程序称为内部驱动程序，位于微控制器抽象层中。片内外设的例子有：

内部EEPROM。
内部CAN控制器。
内部ADC。

外部功能集成电路位于微控制器之外但在同一个ECU硬件上（片外外设），片外外设的例子有：

外部EEPROM。
外部watchdog。
外部flash。

片外外设的驱动程序称为外部驱动程序，位于ECU抽象层。它通过微控制器抽象层的驱动程序访问片外外设。例如针对具有SPI接口的外部EEPROM，驱动程序通过微控制器抽象层提供的SPI总线API访问外部EEPROM。有一些常用的片外外设会集成到一个芯片上（系统基础芯片：SBC）,比如收发器和看门狗。有一种例外情况，例如映射到片内地址空间的外部设备(例如外部闪存)，驱动程序可以直接访问微控制器来操作片外外设。这些外部驱动程序位于微控制器抽象层中，因为它们依赖于微控制器。

一个接口(接口模块)包含从结构上位于其下方模块的功能抽象。它提供了一个通用API，用于访问特定类型的设备，而不受该类型现有设备数量与设备硬件实现的影响。接口模块不会改变数据的内容。通常，接口模块位于ECU抽象层中。例如，CANIf接口模块提供了一组通用API，用于访问CAN通信网络，而不受ECU中CAN控制器数量的影响，也不受硬件实现(片上、片外)的影响。

handler实现对一个或多个驱动程序并发、异步的访问（它实现缓冲、排队、仲裁和复用逻辑）。
handler不会更改数据的内容。handler通常包含在驱动程序或接口模块中(例如，SPIHandlerDriver，ADC Driver)。

manager为多个客户端提供特定的服务。在handler无法满足多个客户端的情况下都需要manager。除了handler外，管理员还可以评估和更改或调整数据的内容。
一般情况下，manager位于服务层，例如NVRAM管理对内部和/或外部存储器设备(如闪存和EEPROM存储器)的并发访问。它还执行分布式和可靠的数据存储、数据检查、提供默认值等。

库是用于相关目的的函数集合，它具有以下特征：

可以由BSW模块(包括RTE)SW-C、集成代码或其他库调用。
运行需要跟调用一致的上下文保护环境。
其自身只能调用其他库。
是重入的。
没有内部状态，不需要任何初始化。
是同步的，即它们没有等待点。

以下库在AUTOSAR中指定包含的：

Fixed point mathematical
Interpolation for floating point data
CRC calculation
Floating point mathematical
Bit handling
Extended functions (e.g. 64bits calculation, filtering, etc.)
Interpolation for fixed point data
E2E communication

Methodology and Templates（方法论与模版）

方法论概念

AutoSAR方法论主要定义了下面五个领域：

Virtual Functional Bus
System
Software Component
Basic Software
ECU

他们之间的工作流如下图所示。

上图的工作流涉及了AutoSAR定义的五种基本元素：

Task Definition：任务
Work Product Definition：工作产品
Role Definition：角色
Tool Definition：工具
Guidance：指导

这五种元素的图标如下，多出的Deliverable（交付品）是工作产品的聚合。

一个任务有一个明确的目的，其中执行角色实现一个定义明确的目标。对于AUTOSAR方法论，任务是可重用的元素，在多个方法论用例中都可以使用。任务至少与一个执行角色相关联，并且可能有多个额外的执行者任务使用工具来实现其输出。可选执行者和任务的可选输入和输出由关系的复数性来描述。

下图展现了一个任务与其他基本元素的关系。

工作产品定义由任务使用、修改和产生(即任务输入和输出)。工作产品在大多数情况下是由任务消耗、产生或修改的有形工作产品。工作产品可以是一个交付品，也可以是一个工件，工件的类型如下：

AUTOSAR XML
Source Code
Object Code
Executable
Text

下图是工件与其他元素的关系。

角色定义了个人或一组个人的职责，从而定义了执行任务所需的一组相关技能、能力和资格。一个角色可以由一个人或多人担任，一个人可以担任多个角色。每个角色用于执行任务。下图是角色与其他元素的关系。

工具定义描述了CASE工具、通用工具或任何其他自动化单元的能力，这些工具支持相关角色执行任务所定义的工作（例如编译器）。下图是工具与其他元素的关系。

指导提供与角色、工作产品和任务等相关的额外信息。指导可以是以下几种形式：

Supporting Material：辅助材料是其他类型指南的统称，这些指南在其他地方没有具体定义。
Tool Mentor：工具导师展示了如何使用特定的工具来完成某项工作，无论是在任务或活动的上下文中还是独立于任务或活动。
White Paper：白皮书是经过外部审查或发布的概念指南，可以独立于其他方法内容阅读和理解。AUTOSAR文档就是白皮书的例子。

下图是指导与其他元素的关系：

整体工作流程

以下简要介绍了开发AUTOSAR系统的主要活动。第一步侧重于开发抽象系统，其次是描述VFB开发，最后是进一步改进和开发系统的活动。

Development of a functional view on the system（系统设计阶段）：整个工作流程从这个可选的活动开始，预先开发抽象系统描述，它从功能或抽象的角度(功能架构)代表整个系统。一方面，这个抽象系统描述可能包含与VFB相关的部分。这些信息可能作为VFB开发的输入，并在这两个视图之间建立映射。请注意，在此步骤中，功能包括软件组件的端口映射。因此，抽象视图中使用的某些端口可能在随后的开发中不再使用。另一方面，抽象系统描述可能包含有关拓扑和映射到ECU的信息。这是开发具体系统描述的基础。下图是系统的抽象视图(上)和对VFB视图的SW-C的映射示例。

Development of the Overall VFB System（虚拟总线系统开发阶段）：总体VFB系统开发，如果省略上面提到的系统设计阶段（可选的第一步），则开发直接从定义总体VFB系统开始。VFB是软件组件之间通信的抽象。它提供了系统包含的所有软件组件的专用视图，如下图所示，独立于任何ECU和网络。

Development of the system （系统开发）：VFB通过定义ECU和网络的拓扑结构，并在ECU上部署软件组件来进行系统的开发，见下图。此外，还推导出用于连接分布式功能的通信矩阵。作为通信开发的一部分，可以指定自定义计算方法，用于在ECU之间通信时转换数据。此转换是相应基本软件模块实现的基础。系统的开发可以直接在一个阶段或几个阶段完成。下图是一个系统包含的内容。

两阶段开发方法当存在组织责任分离时，使用两阶段方法其中主要组织(通常是OEM)在第一阶段定义整个系统，其他几个组织(通常是供应商)在第二阶段并行定义子系统。在这种情况下，主要组织移交系统提取，这些提取代表整个系统的子系统。这些子系统包含子系统VFB，它们是整体VFB的一部分。总体系统定义了主要的公共ECU和拓扑结构，而子系统设计通过在系统中添加私有ECU和网络来做出贡献。请注意，在子系统内定义的部分对其他子系统或总体系统是不可直接访问的。主要组织的系统提取可以被视为需求，而由一个或多个电子控制单元系统描述代表的接收组织的子系统可以被视为解决方案，其必须满足交付的需求。下图显示了不同的系统提取与ECU系统描述之间的关系。

Producing ECU-specific deliverables（ECU特定交付物抽取）：获取特定ECU的可交付成果是在完成系统设计后。我们需要提取与特定ECU相关的部分，为每个ECU生成一个可交付成果，即所谓的ECU提取。与之前对系统或ECU的描述相比，ECU提取被完全分解，仅包含原子软件组件。它是ECU配置的基础。

Development of Software Components（软件组件开发）：与系统设计并行，软件组件(交付原子软件组件)根据抽象VFB、VFB或子系统VFB所需定义进行实现。基于VFB定义的外部接口，可以定义内部行为，并最终实现软件组件，见下图。最终软件组件完成开发之后，被交付以集成到ECU中，并在其中部署。请注意，软件组件的实现在很大程度上独立于ECU的配置。

Development of Basic Software modules（基础软件开发）：由于基本软件模块独立于VFB，因此可以在ECU集成前的任何时间开发。下图显示BSW的开发。

Integration of AUTOSAR ECUs（针对ECU的集成工作）：当AUTOSAR SIP包（包含MCAL）、ECU提取完成（ECU涉及软件组件描述文件（arxml完成），ECU涉及系统信号添加完成，系统/内部信号连接完成），以及所有交付的原子软件组件的实现可用时，AUTOSARECU的集成开始。在此阶段，对ECU进行配置。执行顺序由任务调度和将软件组件运行程序分配给这些任务来确定，并根据ECU抽取结果自动进行初步的基础软件配置（主要针对通信栈）。然后，完整的完成对基础软件模块的配置。最后，在生成RTE后，将完整的代码编译并链接成可执行文件。

模版

下图说明了用于定义正式模板的整体方法（以系统模版为例）。正其中重要的是要从具体的XML-DTDS、XML-Schemas或其他用于定义实际模板的技术中分离出需要捕获的信息的精确和简洁的模型。

下面介绍一下模版涉及的一些文档概念：

template document：模板文档(在此示例中为系统模板)描述了可以在模板中捕获的信息。它包含了对AUTOSAR元模型相关部分中所有可捕获信息的语义(确切含义)的详细描述。
M2 Templates：AUTOSAR元模型中称为M2模板的模型，这个模型通过在模板文档中表示为类表的标注进行注释。
Generic Structure Template：泛型结构模板的文档被重新表示为元模型中的预定义类，这些类被并入生成的schema中。
Template UML Profile and Modeling Guide：模板UML简介和建模指南描述了在创建元模型内容时应用的基本概念。
XML Schema Production Rules：这个文档叫XML规则构建文档，它描述了如何使用XML，以及如何将“软件组件模板”中设计的元模型由“Schema生成器”(MDS)转换为XML-Schema(XSD)的“数据交换格式”。这种“形式化策略”应该用于所有在元模型中正式描述的数据。为了理解元模型和基于XML的AUTOSAR模板的映射，值得深入理解本文档。
Data Exchange Format：数据交换格式表示为从AUTOSAR元模型自动生成的XML Schema，生成使用XML Schema Production Rules中定义的方法和模式。该Schema通常用作AUTOSAR工具的输入。
M1-level descriptions：M1级别的描述(在上图中显示为“系统配置描述”和“系统约束描”)是XML文件，可以按照XML模式进行验证，并进一步遵循相关“模板文档”中的规范。换句话说，XML文件是定义模板XML表示的模式的实例。

下图描绘了元模型的总体结构，它正式定义了描述AUTOSAR软件组件所需的词汇表。正如该图所指出的，其他模板规范(例如ECU资源模板和系统模板)也使用相同的建模方法，以定义AUTOSAR 软件描述的整个一致模型。
图中的虚线箭头描述了元模型中包之间的导入关系依赖。例如，包SWComponentTemplate导入在包Generic-Structure(本文档中描述)和ECUResourceTemplate中定义的元类。

可以看到，所有的模版都依赖于Autosar Top Level Structure，这种方法为AUTOSAR方法中的工件设计提供了最大的灵活性，下图说明了AUTOSAR的顶层结构。

以下ARXML文件示例了顶级结构。该文件以英语和德语维护，英语是主语言。

<?xml version="1.0" encoding="UTF-8"?>
<AUTOSAR xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://autosar.org/schema/r4.0"
xsi:schemaLocation="http://autosar.org/schema/r4.0 AUTOSAR_4-1-3.xsd"
><ADMIN-DATA><LANGUAGE>EN</LANGUAGE><USED-LANGUAGES><L-10 L="EN" xml:space="default">English</L-10><L-10 L="DE" xml:space="default">German</L-10></USED-LANGUAGES></ADMIN-DATA><AR-PACKAGES><AR-PACKAGE><SHORT-NAME>demo</SHORT-NAME><ELEMENTS><!--autosar elements here--></ELEMENTS></AR-PACKAGE></AR-PACKAGES></AUTOSAR>

详细的模版规范可以在AutoSAR网站搜索到对应到的文档说明，主要包含：

Software Component Template：软件组件模版，详细模版内容见《AUTOSAR_TPS_SoftwareComponentTemplate.pdf》。
System Template：系统模版，详细模版内容见《AUTOSAR_TPS_SystemTemplate.pdf》。
Basic Software Module Description Template：基础软件模块描述模版，详细模版内容见《AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf》。
Specifcation of ECU Confguration：ECU配置模版，详细模版内容见《AUTOSAR_TPS_ECUConfiguration.pdf》。

AutoSAR学习路线图

AutoSAR开发大概可以按下图分为四个部分。下图的BSW软件模块特指BSW中不包含MCAL的其余部分。

因为BSW软件模块的配置大部分可以通过系统与ECU的配置由工具链自动生成，所以BSW模块配置开发与MCAL配置与底层驱动开发往往归于一个团队来处理，我们可以针对某个芯片（例如英飞凌3系列）的开发板从ETAS购买工程服务从而得到一个基础软件例程，然后针对具体项目对MCAL、BSW和系统集成开发方面进行二次开发，一个团队就能处理包括MCAL、BSW和系统集成开发的工作，大大缩减项目开发周期，并且能够得到工具链厂商有针对性的技术支持。

在学习AutoSAR之前，我们需要先了解一下我们跑AutoSAR软件的微控制器芯片，常见的芯片厂商有英飞凌、瑞萨和恩智浦，本专栏涉及的控制器芯片为英飞凌的TC397芯片，本专栏涉及这个方面的文章有：

英飞凌（Infineon）平台嵌入式开发基础：文章介绍英飞凌芯片开发的一些基础知识，包括手册等资料的获取方法等。
【MCAL】HighTec集成TC3xx对应MCAL的Demo：文章介绍了在安装了TC3xx的MCAL之后，使用HighTec集成开发环境使用它的Demo程序来搭建一个只有MCAL的工程，从而后边能够针对MCAL中的模块进行驱动测试。
英飞凌（Infineon）TC397链接文件解析：文章介绍了前面提到的TCxx对应MCAL的Demo中的链接文件解析，帮助读者后边更好的理解程序各部分在运行时的地址位置，完成一些特殊值的预存。

开发过程中难免会使用一些工具：

【汽车电子】CAN总线分析仪使用介绍（PCAN/同星CAN卡）：文章介绍了PCAN和同星CAN卡的使用过程。

MCAL

MCAL作为除了OS（虽然依然使用的是驱动中的中断处理函数，但是AUTOSAR OS接管了所有硬件的中断的控制，包括向量表实现，开启/关闭中断）之外唯一直接跟硬件打交道的基础软件，它主要包含以下这些部分：

专栏对MCAL的学习主要是前面提到的利用HighTec搭建起来的MCAL的Demo程序，使用的调试软件是UDE。

专栏中涉及的MCAL模块足以支撑一个一般ECU的功能，每篇文章首先都从理论原理入手，介绍了相关模块的Autosar规范手册和MCAL手册的功能定义说明，然后再结合实际的配置目标，记录了完整的配置过程，最后展示了配置目标的功能测试过程。展览包含的MCAL模块有：

【AUTOSAR MCAL】MCAL基础与EB tresos工程新建：文章介绍了使用tresos Studio新建MCAL工程的过程。
【MCAL】TC397+EB-tresos之MCU配置实战 - 芯片时钟：文章介绍了使用MCU模块实现芯片时钟。
【MCAL】TC397+EB-tresos之Port&Dio配置实战 - LED灯闪烁：文章介绍了使用Port&Dio模块实现LED灯闪烁。
【MCAL】TC397+EB-tresos之GPT配置实战 - 定时器：文章介绍了使用GPT模块实现LED定时器。
【MCAL】TC397+EB-tresos之CAN配置实战 - (CAN/CANFD)：文章介绍了使用CAN模块实现CAN/CANFD通信。
【MCAL】TC397+EB-tresos之ADC配置实战 - (模数转换)：文章介绍了使用ADC模块实现模拟电压转化为数字量。
【MCAL】TC397+EB-tresos之存储器驱动配置- (Fls_17_Dmu/FlsLoader)：文章介绍了使用ADC模块实现模拟电压转化为数字量。
【MCAL】TC397+EB-tresos之SPI配置实战 - (同步/异步)：文章介绍了使用SPI模块实现与片外外设实现同步或异步通信。
【MCAL】TC397+EB-tresos之ICU配置实战：文章介绍了使用ICU模块实现方波信号检测功能。
【MCAL】TC397+EB-tresos之PWM配置实战 - (占空比可调方波)：文章介绍了使用PWM模块实现方波发生功能。

BSW软件模块

此部分涉及的基础软件模块包含除了MCAL等跟硬件有关的纯软件基础软件模块，专栏中涉及的模块足以支撑一个一般ECU的的功能。下面涉及的所有文章均从AUTOSAR规范解析，ISOLAR-AB配置以及模块相关代码分析三个维度详细介绍对应的BSW软件模块，其中包含：

【ETAS CP AUTOSAR基础软件】EcuM模块详解：EcuM模块主要完成ECU的状态管理，包括上电初始化，休眠验证等功能。
【ETAS CP AUTOSAR基础软件】BswM模块详解：BswM模块主要完成基础软件状态管理。它可以根据不同条件定义不同基础软件状态，每种状态则会对应一个执行动作列表，在切换到这个状态中执行列表中的动作。
【ETAS CP AUTOSAR基础软件】DET、Bfx、CRC、ComStack、rba_ArxmlGen模块详解：这几个模块功能范围相对小且独立，放到了一起统一介绍。
【ETAS CP AUTOSAR基础软件】DCM模块详解（诊断）：DCM模块中主要处理诊断除故障管理的部分。其中主要包括诊断服务，安全等级，DID等配置。
【AUTOSAR 基础软件】DEM模块详解（诊断故障管理）：DEM模块中主要处理故障管理部分。其中主要包括DTC的相关配置。
【AUTOSAR 基础软件】存储栈（NvM、MemIf、Fee）详解：存储栈（NvM、MemIf、Fee）主要处理基础软件中跟存储有关的功能。
通信栈：
1. 【AUTOSAR 基础软件】COM模块详解（通信）：COM模块主要处理能从具体底层通信方式抽象出来的通信功能部分，包括拆解/拼装信号到Pdu（报文）以及周期发送报文等功能。
2. 【AUTOSAR 基础软件】PduR模块详解（通信路由）：PduR模块主要处理不同底层通信方式报文与上层模块之间的路由。
3. 【AUTOSAR 基础软件】ComM模块详解（通信管理）：ComM模块主要处理通信状态管理功能。
CAN栈：
1. 【AUTOSAR 基础软件】Can模块详解（Can栈之驱动模块）：CAN模块主要提供MCAL中CAN模块的MailBox等配置信息，并提供给其余CAN栈模块引用。
2. 【AUTOSAR 基础软件】CanSM模块详解（Can栈之状态管理模块）：CanSM模块主要提供CAN通信的状态管理功能，主要包含BusOff处理等。
3. 【AUTOSAR 基础软件】CanTp模块详解（Can栈之传输模块）：CanTp最常见的应用是将诊断涉及的相关功能模块发送/接收数据转化为包括单帧（SF）、首帧（FF）、连续帧（CF）以及流控帧（FC）格式并下发到CanIf模块，并提供整个通信过程中超时时间的判决。
4. 【AUTOSAR 基础软件】CanIf模块详解（Can栈之接口模块）：CanIf模块作为AUTOSOR的CAN栈最下层模块，向CAN栈的上层提供了不同CAN控制器与收发器的统一抽象接口。

系统集成开发

系统集成开发涉及了包括SWC的集成与开发，内部信号的连接，OS的配置与集成，DBC/LDF通信信息描述文件的导入以及系统信号连接，部分BSW自动配置（主要涉及通信栈）以及RTE代码的生成。这块的内容比较繁杂，需要对SWC，RTE，BSW三个部分都有一定的理解，才能快速的定位解决集成工作中遇到的问题。下面是本专栏相关的集成开发内容文章，涉及的相关操作要点足以支撑完成日常集成工作：

【ETAS CP AUTOSAR工具链】基本概念与开发流程：文章介绍了基于ETAS工具链完成集成工作的一些基本概念与开发流程，涉及到RTE之前，可以称这部分为“系统开发”。
【ETAS CP AUTOSAR工具链】RTE运行时环境详解：文章介绍了RTE的开发概念与基于ETAS工具链完成配置的过程，文章介绍集成工作到RTE代码生成。
【ETAS CP AUTOSAR工具链】RTA-OS操作系统详解：文章介绍了RTA-OS的开发概念与配置过程，能够帮助我们完成一些基本的任务/中断添加等集成工作。
【ETAS CP AUTOSAR工具链】RTA-BSW基础软件开发详解：文章介绍了使用ETAS工具链完成BSW自动配置，手动配置，以及代码生成的过程与相关概念。
【ETAS CP AUTOSAR工具链】ARXML文件详解：文章首先介绍了ARXML的一些基础概念，然后基于使用ISOLAR-AB从A到B的开发过程，将涉及到的ARXML文件进行了详细的解析，它们都是前文提到模版的具体实现。

软件组件开发

AutoSAR架构中仅仅定义了软件组件的开发方法论，其具体的开发方式供各个供应商选择，您可以采用Simulink基于模型的设计开发方式，也可以采用“手写”代码的实现ECU的相应功能规范。本专栏中简单介绍了基于ETAS工具链实现一些基础软件必要的软件组件设计开发，实现一些所谓“代理”的SWC，在真正的应用软件组件之下实现一些逻辑功能。

【AUTOSAR 基础软件】软件组件的建立与使用（“代理”SWC）：本文从创建软件组件讲起，并针对软件组件中的常用部分以实例为基础进行了详尽的说明，帮助读者能够使用ISOLAR这个工具建立并使用SWC。

十六宿舍原创作品，转载必须标注原文链接。

©2023 Yang Li. All rights reserved.

欢迎关注 『十六宿舍』，大家喜欢的话，给个👍，更多关于嵌入式相关技术的内容持续更新中。

写在前面

概述

Concept（概念）

Architecture（架构）

Methodology and Templates（方法论与模版）

方法论概念

整体工作流程

模版

AutoSAR学习路线图

MCAL

BSW软件模块

系统集成开发

软件组件开发

相关文章：