项目起因

从事Android系统开发10余年，切换到自动驾驶领域后，发现汽车相关的代码、文档、工具链资料信息比较少，大多需要付费，而且价格不菲，和之前做的安卓有着天壤之别，这里不得不感叹谷歌商业化的强大，迅速吸引了大量的开发者涌入到android，这也是android成功的一部分吧，言归正传，汽车领域的知识非常多，并且比较零散，很多工具个人很难获取，所以，在我自己自学的同时也希望把自己的经验分享给大家，本项目从AUTOSAR的文档中文本地化开始，后续将补充学习导读、工具链、源码分析等等，自己刚刚开始学习，希望不要烂尾 😊

所有的文档来自于 和互联网。

项目约定

本项目用于开展AUTOSAR文档的中文翻译工作，并确保项目的可持续性，特别做如下约定：

• 所有翻译工作转到 Github 来协同，可以通过 Github Pull Request 来完成评审。
• 所有翻译结果用 autosar.ltd 来展示，并方便导出
• 所有翻译后的文档格式统一为 MDBOOK支持的 Markdown 格式。
• 目录结构尽量遵循AUTOSAR组织原有发布的格式。

前言

为了顺利的从android消费类电子进入车载领域大门，先介绍一些基础知识方便后面的沟通中能够不蒙圈。

你认识几个车？

汽车电子相关知识：

1.开发常见黑话

• OEM：Original Equipment Manufacturer的缩写，通常指设备厂商/主机厂/整车厂。
• Tier 1：一级供应商，也就是跟OEM签订供应合同的供应商。一级供应商所供应的零部件，并不一定全部来自自身的产线生产制造，比如液晶仪表供应商的液晶屏幕就会采取外购的形式，液晶屏幕供应商，就是二级供应商。
• Tier 2：二级供应商，是跟一级供应商签订合同的供应商。在一般零部件制造中，一级供应商制造的零件中也会采用购买或外包的形式获取所需的零部件和服务。
• Tier0.5：源于主机厂全栈自研的诉求，通过与主机厂深度绑定，Tier0.5将从全流程介入主机厂研发、生产、制造，甚至后期的数据管理和运营。
• SOP： Start Of Production批量生产启动，不少网站写的是small-outline package，个人认为这个不适用在这里，一般这种指的是一种封装工艺，更多在芯片封装上。
• EOP： End of Prodcuction 量产结束

• A样件：prototype 零件设计初期，手工样件，关键尺寸要求，加工周期短，用于基本性能试验及mule car造车；
• B样件：soft tooling 手工样件，全尺寸要求，零件材料与结构都与量产件一致，但模具为软钢模，用于设计验证DV；
• C样件：hard tooling 批量样件，尺寸以及老化验证，量产用的模具，用于工艺和生产试验验证 PV。

2.MPU，CPU，MCU，ECU，SOC是什么？

• CPU：Central Processing Unit。中央处理器，CPU由运算器、控制器和寄存器及实现它们之间联系的数据、控制及状态的总线构成。

• MPU：Micro Processor Unit，叫微处理器，有时记作µP（读micro processor unit）,通常代表一个功能强大的CPU(暂且理解为增强版的CPU吧),但不是为任何已有的特定计算目的而设计的芯片。这种芯片往往是个人计算机和高端工作站的核心CPU。Intel X86，ARM的一些Cortex-A芯片如飞思卡尔i.MX6、全志A20、TI AM335X等都属于MPU。

• MCU：Micro Control Unit，叫微控制器(不是微控制器)，有时记作µC（读micro Control），是指随着大规模集成电路的出现及其发展，将计算机的CPU、RAM、ROM、定时计数器和多种I/O接口集成在一片芯片上，根据外界的信号，产生一些反应，做一点简单的人机界面，侧重点在于控制，而计算比较少。

  

• ECU：ECU原指的是Engine Control Unit，即发动机控制单元，特指电喷发动机的电子控制系统。后来随着汽车电子的迅速发展，ECU的定义变成了Electronic Control Unit，即电子控制单元，泛指汽车上所有电子控制系统。而原来的发动机ECU有很多的公司称之为EMS： Engine Management System。

  NOTE: In the AUTOSAR sense an ECU means one microcontroller plus peripherals and the according software/configuration. The mechanical design is not in the scope of AUTOSAR. This means that if more than one microcontroller in arranged in a housing, then each microcontroller requires its own description of an AUTOSAR-ECU instance.

  注：就AUTOSAR意义上而言，ECU是指一个MCU微控制器加上外围设备软件/配置。机械设计不在AUTOSAR的范围内。这意味着如果超过一个微控制器布置在外壳中，那么每个微控制器都需要对AUTOSAR-ECU实例。

• SoC：System-on-a-Chip ，中文的的意思就是“把系统都做在一个芯片上 ”,SoC上集成了很多关键的部件，比如CPU 、GPU 、内存 、也就说虽然它在主板上的存在是一个芯片，但是它里边可是由很多部件封装组成的。例如MTK6833，天玑9000，高通8155，麒麟970，三星的exynos 4412等 | | | :----------------------------------------------------------: | | 基于ARM架构的SOC |

• NoC： (Network on Chip)中文称之为片上网络。随着 SoC 技术的发展，芯片内部的 IP 核越来越多，有可能在一颗芯片中集成了数以百记的处理器内核（包括同构处理器内核和异构处理器内核）、数以千计控制器 IP 核等等，那么这种情况下 IP 核之间的互联就成为 SoC 性能一个重要组成部分。

3.A 核、R核、M核具体是什么？

• ARM公司目前主流处理器以Cortex来命名，下面是ARM的产品图：

ARM公司发布的处理器型号

• Cortex-A系列：Application Processors（应用处理器)，基于虚拟内存的操作系统和用户应用，可以运行Linux，偏向消费产品，应用包括智能手机、智能本和上网本、电子阅读器、数字电视、家用网络、家用网关和其他各种产品。这类处理器运行在很高的时钟频率（超过1GHz），支持像Linux，Android， Windows和移动操作系统等完整操作系统

• Cortex-R系列：Real-time Processors（实时处理器）–面向实时应用的高性能处理器系列，例如硬盘控制器，汽车传动系统和无线通讯的基带控制。多数实时处理器不支持MMU，不过通常具有MPU、Cache和其他针对工业应用设计的存储器功能。实时处理器运行在比较高的时钟频率（例如200MHz 到 >1GHz ），响应延迟非常低。虽然实时处理器不能运行完整版本的Linux和Windows操作系统，但是支持大量的实时操作系统（RTOS）。

• Cortex-M系列：Microcontroller Processors（微控制器处理器）–微控制器处理器通常设计成面积很小和能效比很高。通常这些处理器的流水线很短，最高时钟频率很低（虽然市场上有此类的处理器可以运行在200Mhz之上）。 并且，新的Cortex-M处理器家族设计的非常容易使用。因此，ARM 微控制器处理器在单片机和深度嵌入式系统市场非常成功和受欢迎。

  • 英飞凌的TC397 , 是自研的Tricore架构，不属于arm，也不是任何A，R，M系列

  • NXP的S32G 使用ARM Cortex M系列

4.车规级芯片和消费电子类芯片的区别

• 汽车行业和其他行业，特别是消费产品行业是有很大区别的，零部件的级别分军工级、车规级和消费级。很显然，汽车行业的技术要求比消费级的高。因为它涉及道路安全。

• 于是，软件上就有个叫AUTOSAR的东西，甚至还有个叫ASPICE的过程管理来管控整个产品的开发过程。

AutoSar是我们进入车圈避不开的一个东西，相关的从业人员不多，技术比较封锁（主要体现在和android差距比较大，不开源，找啥都没有，找啥都收费~！~），这东西也不似我们学习的C、Java语言一样，一书一电脑一个IDE足矣，基本上学习的头一个月是懵的，这也是接下来讲述的重点，可能要分好几部分

• ASPICE： Automotive Software Process Improvement and Capability dEtermination汽车产业的软件流程改进和能力测定标准

  

  

• CAN、LIN、FLEXRAY、ETH、MOST 汽车上使用的各类总线，CAN、ETH为主

• ASIL： Automotive Safety Integrity Level 汽车安全完整等级

  • ISO： International Standardization Organization，ISO26262 道路车辆功能安全

  • MISRA: The Motor Industry Software Reliability Association,汽车工业软件可靠性联合会，以MISRA-C而闻名，同样为了安全。

  • CPU lockstep 为了满足汽车功能安全（如ISO26262），有许多有用的措施来规避E/E系统异常崩溃造成的不必要伤害，CPU-LockStep是实现高诊断覆盖度（检测错误发生的能力）的一种常见手段，大致方法：两个核运行同样的程序，将结果输入一个逻辑比较器中，周期性（一般会存在周期delay）比较两个核的输出结果是否相同。如果相同，则继续运行；否则，则需要采取一定的措施（例如中断上报）。如果一段时间后错误还是存在，可能重启或者重新检查。

    

汽车电子电气架构EEA

EEA（Electrical/Electronic Architecture）把汽车中的各类传感器、ECU（电子控制单元）、线束拓扑和电子电气分配系统整合在一起完成运算、动力和能量的分配，进而实现整车的各项功能。

汽车电气：涵盖汽车电器、汽车电子、汽车线束以及他们的连接关系；

• 汽车电器只是汽车上安装或使用的一个用电设施（或叫设备），包括蓄电池、发电机、起动机灯具、暖风机、汽车电子设备（如收放机、导航仪等）等等，也可以把汽车线束看成是汽车电器的一种（一个成员）；
• 汽车线束是将汽车上蓄电池、发电机及所有用电设备，按照一定规则连接起来的导线的集合体，这些导线往往是捆扎成束，按需求分叉，分叉也捆扎成束。
• 汽车电子是指电子技术在汽车上的应用。包括：汽车上的电子设备（如收放机导航仪、电子点火器、电喷电控发动机用的ECU、ABS系统、安全气囊等等）、汽车上的网络通讯系统（比如CAN总线）、汽车防盗系统、定位系统等等

汽车电气电子结构

AUTOSAR的简介

AUTOSAR

是汽车和软件行业领先公司的全球合作联盟，为智能移动开发和建立标准化的软件框架以及开放的E/E系统架构。考虑到目前和未来市场中不同的汽车E/E架构(Electrical/Electronic Architecture)，他们制定了一套专门用于汽车的开放性的框架和行业标准，它将用作管理将来的应用程序和标准软件模块中功能的基本基础结构。AUTOSAR的是AUTomotive Open System ARchitecture的缩写，是一种软件架构，因此AUTOSAR有两种含义：

1. 代表AUTOSAR联盟

2. 代表AUTOSAR软件架构。

一、AUTOSAR成员

AutoSAR官网的成员的介绍界面，目前有7类合作伙伴(最近新增了premium plus)

• 核心合作伙伴（创始成员9个无法申请），战略合作伙伴一个电装
• 高级合作伙伴 +
• 高级合作伙伴
• 开发合作伙伴
• 关联合作伙伴
• 参与者
• 订阅者

AUTOSAR会员类型

二、合作伙伴

目前已经有超过300+AUTOSAR合作伙伴。

AUTOSAR合作伙伴

三、成员发展

西门子VDO原本也是核心成员，被Continental 收购，因此西门子VDO不再是AUTOSAR的核心成员

合作伙伴发展历史

AUTOSAR合作伙伴的遍布全球

四、AUTOSAR的组织

• AUTOSAR标准主要是由AUTOSAR Working Group组织制作的

• AUTOSAR还有一个用户组，用户组是变化的，当前主要有三个用户组：

  • UG-CN China，UG-CN的愿景是为中国市场启用AUTOSAR。

    • 为了实现此目标，用户组在AUTOSAR演示程序项目上工作，以提供用户指南“如何从AUTOSAR开始”和演示程序的启动配置。

  • UG-NA North America，UG-NA的愿景是增强北美用户在AUTOSAR方面的技能，以充分利用AUTOSAR带来的汽车EE体系结构开发的优势。

    • 为实现这一愿景，他们提供了一个协作环境，以促进AUTOSAR在北美地区的使用。
    • 开发关键文档以帮助理解AUTOSAR标准，并提供示例和配置以解决特定的用例。

  • UG-IE Improved Exploitation，UG-IE代表了更好地利用AUTOSAR工业标准。

    • 他们的任务是分享AUTOSAR的利用和开发经验。其他任务包括为战略方向准备提案，以提高AUTOSAR的可用性以及节省更多的精力。
    • UG-IE的总结结果创建了演示文稿和技术论文，对AUTOSAR战略，技术工作组和用户产生了推动作用。

• AUTOSAR软件框架，AUTOSAR分为CP和AP和合作平台

AUTOSAR CP和AP对比

• AUTOSAR交付内容

  从“Foundation”出发的，扩展出Classic Platform（简称CP）和Adaptive Platform（简称AP）两大平台，继而定义各种接口和测试等。

  • CP交付了规范文档
  • AP提供示例代码和文档
  • 白色部分属于还在扩展中的部分标准

• Foundation(FO)主要作用是确保不同AUTOSAR标准的兼容性，因此包含了所有常见的Artifact和协议，例如

  

五、AUTOSAR带来了什么好处

• 对于OEM车厂

• 对于供应商

• 对于工具供应商

• 对于新入市场者

六、AUTOSAR开发流程

AUTOSAR的方法论从参与者角色分工来看，分别支撑不同的工作。

• Software Component Description

  • 该SWC用到或被用到的Operation和Data
  • SWC对基础构架(network)和对硬件(latency times, timing, etc.)的要求
  • SWC使用的资源 (memory, CPU time, etc.)
  • 运行机制(repetition rate)
  • SWC软件接口

• ECU Resource Description

  • Sensor, actuator 传感器，执行器
  • Memory 存储器
  • Processor 处理器
  • Communications periphery 通信外部设备（如 收发器）
  • Pin assignments 引脚分配

• System Constraint Description 系统约束申明

  • Information on network topologies 网络拓扑
  • Limitations (“Constraints”) 限制
  • Protocol 协议
  • K-matrix 通信矩阵
  • Baud rate, timing 波特率，定时
  • ECU映射

前面提到了TOOL供应商，autosar的创始成员里面也有比如大陆集团的EB，博世旗下的ETAS，还有一些国产厂商也做的非常棒东软睿驰、经纬恒润，华为等。

不过市场占有率最高的还是Vector，工具链最全，市场占有率最高，同样价格也是非常美丽。

工具大致介绍

AUTOSAR的发展

首先思考一个问题，为什么需要AUTOSAR？

1、早期开发状态

裸写代码法，目前这种开发方式还是存在的，例如一些简单的ECU（锂电池管理单元BMS）在使用这种方式开发，缺点比较明显，软硬件耦合严重换颗芯片就要进行重新裸写。大致总结存在如下问题：

• 电子系统的复杂性不断增长，软件代码量急速上升
• 生命周期差别: 整车的生命周期往往长于ECU的生命周期
• 嵌入式系统不支持硬件抽象
• 有限的软件模块化
• 重用性差: 当硬件（处理器型号）更换后，软件往往要推倒重写
• 五花八门的硬件平台

2、基于封装思想的开发状态

裸写多了，程序员总会想着偷懒，通过有经验的架构师做出一套优化架构，并且结合一些操作系统（OS）对代码进行封装，这样一来便可以大大降低裸写代码法的很多弊端，极大的解决了软件的日益复杂化，可重用低的问题，不过缺点仍然有：

1. 对于不同的客户，由于各家客户需求不同，重用性依然不好
2. 软件耦合也会存在，同时该方法的优劣和架构师的能力直接挂钩，存在一定的安全隐患

如下图是Vector以前的解决方案:

Vector在AUTOSAR之前的解决方案

为了解决行业内嵌人式软件开发所面临的问题,提高软件的开发效率和可重用性,降低软件的开发成本,全球主流的汽车整车厂、零部件供应商以及软件、半导体和电子工业的企业于2003年联合成立了汽车开放系统架构AUTOSAR联盟旨在推动建立汽车电气/电子(E/E)架构的开放式标准,使其成为汽车嵌人式应用功能管理的基础架构,并规范汽车电子产品、软件和元器件的互通性,使用户避免因为采用私有的协议和解决方案而导致开发成本日益增长

3、使用AutoSAR作为解决办法

AUTOSAR定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案。从结构化概念设计阶段设计AUTOSAR软件组件及其在ECU间的分配,到定义通信和ECU间的配置,通过工具为软件开发流程提供通用的支持采用成熟的工具实现需求的结构化并进行相应的管理,同时建立相应的配置。

1、AUTOSAR的诞生

自从德国发明汽车后，在后来的岁月里，汽车不断地改进不断地演化，车内的系统和零部件越来越复杂和繁多。时至今日，汽车行业，变成了一个蓬勃发展的行业

作为汽车发源地的欧洲大地，准确地讲，德国，于2002年8月，有一群车企大佬（宝马、博世、大陆集团、戴姆勒克莱斯勒和大众汽车公司，后来西门子威迪欧也加入了）就共同的挑战和目标进行了讨论，成立一个联盟，制定标准，准备一统江湖。

很快，在2003年，他们就将AUTOSAR kickoff了，同时也制定了AUTOSAR Classic Platform的Draft版。

在后来几年，这个联盟吸引了无数车企和相关设备商加入，规模不断地发展壮大，所制定的标准框架也日益完善。

逐渐地，后来发现Classic Platform只覆盖了低端的设备，是基于微处理器之上的，上面更高端的系统或服务（有哪些？想想手机业务的发展情况），没有覆盖到。他们的野心是大大的，目标是宏伟的，到了2017年，一个Adaptive Platform就这样诞生了

2、AUTOSAR软硬件隔离

Android是一个非常优秀的架构设计，做到了分层软件，软硬件解耦、高度可重用

一、Android解决碎片化问题退出的Project Treble

大家经常能看到的下图能很形象的说明这一点，隔离后的好处就是不管你用NXP的还是英飞凌的亦或者是TI的；不管你的硬件是怎么设计的，我们都不用修改我们的代码，只需要配置一下AutoSAR，告诉它我换硬件了，然后AutoSAR帮你匹配硬件。当然，实际操作起来还是需要对AuoSAR配置的熟练掌握的,因为要改很多

二、AUTOSAR的作用

旧实现各家方案是各搞各的，并且自己内部也是各项目各搞个的，也就意味着APP无法内外部复用，需要消耗大量的适配成本。

3.Autosar的出现因素

• 汽车电子系统复杂度和代码量的不断提升，当前整车控制系统的代码量都已达到千万行代码的级别，其复杂度远比高端的航空航天要高，只是安全性比他们要低些。
• 软件的复习用性差，由于软件依赖于固定的硬件开发，当硬件发生变更时功能往往需要推倒重来，无疑增加重复开发的工作量和周期，这都是血琳琳的投入和成本。

汽车行业里有众多的整车厂（OEM）和供应商。一般来说，每一家OEM会生产不止一种车型，每一家OEM对不同子系统和零部件会选择不止一个供应商，每个供应商也会向不止一家OEM供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM希望可以让同一套系统和部件用在不同的车型上；同一辆车上来自不同供应商的的各个系统和部件可以相互兼容；而供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的OEM。

另一方面，各个供应商的开发进度往往是不同步的。人们希望可以在供应商开发的过程中就可以测试该部件能否与整车上的其它系统正确配合。因此需要一种统一的、标准化的系统描述方法。

这便是AUTOSAR的初衷，即通过提升OEM以及供应商之间软件模块的可复用性和可互换性来改进对复杂汽车电子电气架构的管理。

对于此，汽车圈，德国为主的几个大佬拉倒一起讨论了300来回，并成为最初的九大核心成员（博世、BMW、大陆、福特、戴姆勒、PSA、通用、丰田和大众）。

AUTOSAR架构

AUTOSAR总的思想是，Cooperate on standards – Compete on implementation，标准上合作，实现上竞争。

意思就是汽车行业的整车厂和供应商共同合作开发一套汽车电子系统的软件开发标准，这样大家就可以专注于功能的开发，而无需顾虑目标硬件平台。

• 将汽车系统的基础软件标准化为一个跨OEM的 标准栈

• 集成不同供应商生产的功能模块

• 适用于不同的车辆及不同的车型

AUTOSAR的计划目标主要有三个：

• 规范分布式开发流程中的交换格式
• 为应用程序的开发提供方法论
• 制定各种应用接口规范

AUTOSAR的使用

AUTOSAR架构分层

AUTOSAR的应用范围：AUTOSAR专用于汽车ECU。此类ECU具有以下属性：

• 与硬件（传感器和执行器）强交互
• 与CAN、LIN、FlexRay或以太网等车辆网络的连接，
• 具有有限计算能力和内存资源的微控制器（通常为16或32位）（与企业解决方案相比）
• 实时系统和从内部或外部闪存执行程序。

分层架构是实现软硬件分离的关键，使汽车系统软件开发者摆脱了之前ECU软件开发与验证时对硬件系统的依赖,在AUTOSAR分层架构中，汽车嵌入式系统软件自上而下分别为：

• 基础软件层（Basic Software Layer， BSW)
• 应用软件层（Application Software ,ASW）
• 运行时环境 （Runtime Environment，RTE）
• 微控制器（Microcontroller）

AUTOSAR分层示意图

1、基础软件层（Base Software Layer）

• 进一步，BSW 基础软件层（Basic Software Layer，BSW）又可分为四层:
  1. 微控制器抽象层（Microcontroller Abstraction Layer，MCAL）
  2. ECU抽象层（ECU Abstraction Layer）
  3. 服务层（Services Layer）
  4. 复杂驱动 （Complex Device Drivers ，CDD）

基础软件层详细划分

• 基础软件层被进一步划分为功能组（functional groups）。服务层**（Services Layer）** 分为系统服务、内存服务和通信服务等。

基础软件功能分组

从上图可以看到，BSW这一层的划分有点乱，既有纵向的，也有横向的，CDD可以认为是纵向的独立的一个功能组，这些跨越多个层级的都是一些比较特殊的，比如左侧的系统服务跨越多个层级，并且包含了OS(AUTOSAR OS后面描述)；然后还有一个I/O硬件抽象。每个功能组在纵向上都是一个分类，但这并不是说每个模块/功能组只能在自己所属纵向上使用。比如SPI底层驱动可能划分在Communication Drivers里面。但是该模块的调用路径很可能是通过RTE → I/O Hardware Abstraction → SPI。但是像CAN这种外设，它就是通过RTE → Communication Services → Communication Hardware Abstraction → Communication Drivers/CAN这条线来使用的。

1.1 微控制器抽象层（Microcontroller Abstraction Layer）

微控制器抽象层是基本软件中最低的软件层。它包含内部驱动程序，这是一种可以直接访问µC和内部外设的软件模块。

微控制器抽象层

任务：

让MCAL层的上层软件独立于/不依赖微控制器。

特性：：

• 实现：依赖于µC的实现

• 接口：标准化和µC独立

举个例子：

例如我们现在有一个芯片A，基本开发完成了，但是为了cost down，，要求换个芯片吧（叫芯片B），芯片B不但便宜，还Pin2Pin兼容。这时候做应用及上面服务层的同事一片叫好（反正没他们啥事，吃瓜群众）。做MCAL的人就苦逼了，他们得重新针对新的芯片B重新弄一遍。这就是上面不依赖于芯片，有MCAL搞定。

微控制器抽象层包括：

微控制器抽象层驱动分组

微控制器层详细划分

如果更详细一点的划分如上图

• 微控制器驱动（Microcontroller Drivers）

  • 内部外设的驱动程序（如看门狗、通用计时器）功能
  • 具有直接访问µC的函数（如核心测试）

• 存储器驱动 （Memory Drivers）

  • 芯片上存储设备（例如内部Flash、内部EEPROM)和内存映射的外部内存设备（例如外部闪存）的驱动程序

• 加密驱动

  • 如SHE(Secure Hardware Extension)或HSM(Hardware Secure Module)等芯片上加密设备的驱动程序

• 无线通信（Wireless Communication Drivers）

  • 无线网络系统的驱动（V2X、车内无线网络系统和非车载ECU通信系统）

• 通信驱动（Communication Drivers）

  • 车载ECU(如SPI)和车辆通信(如CAN)
  • OSI网络分层结构的数据链路层的一部分
  • SPIHandlerDriver
    • SPIHandlerDriver允许并行访问一个或多个SPI总线
    • 为了抽象专用于芯片选择的SPI微控制器引脚的所有特征，这些特征应由SPIHandlerDriver直接处理。这意味着这些引脚在DIO Driver中不可用。

• I/O驱动 （I/O Drivers）

• 模拟和数字I/O的驱动程序（如ADC、PWM、DIO)

1.2 ECU抽象层（ECU Abstraction Layer）

ECU抽象层与微控制器抽象层的驱动程序接口。它还包含外部设备的驱动程序。它提供了一个API 用于访问外围设备和设备，无论其位置（µC内部/外部）以及与µC的连接（端口引脚、接口类型）

任务：

使更高的软件层独立于ECU硬件布局

特性：

实现：µC独立，依赖于ECU硬件

上层接口：独立与µC和ECU硬件

ECU抽象层（ECU Abstraction Layer）包括

• 板载设备抽象 （Onboard Devices Abstraction）
• 存储器硬件抽象 （Memory Hardware Abstraction）
• 通信硬件抽象 （Communication Hardware Abstraction）
• I/O硬件抽象 （Input/Output Hardware Abstraction）。

ECU抽象层有点类似于Android平台的AOSP 标准化的HAL层，ECU抽象层是MCAL层的接口，这一层里面有很多名为Xxx_If的模块，与MCAL层相应模块对应。实际上这一层也包含驱动程序，但是是针对外部设备的驱动，而前面提到的MCAL是针对微控制器内部外设的。

举个例子:

由于MCU的资源有限，有些时候我们需要使用外扩Flash，通常这种外扩Flash是通过SPI这种端口连接的。我们知道芯片内部自带的Flash是由MCAL里面的Fls模块负责的，那现在这个外扩Flash就自能自己实现.

1.3 服务层（Services Layer）

服务层（Services Layer）可分为系统服务（System Services）、存储器服务 （Memory Services）以及通信服务（Communication Services）三大部分。提供包括网络通信管理、存储管理、ECU模式管理和实时操作系统 （Real Time Operating System，RTOS）等服务。除了操作系统外，服务层的软件模块都是与ECU平台无关的。

服务层是基础软件的最高层，它提供了：

• 操作系统功能
• 车辆网络通信管理服务
• 内存服务（NVRAM管理）
• 诊断服务（包括UDS通信，内存错误和故障处理）
• ECU状态管理，模式管理
• 逻辑和程序时序流监控（Wdg管理）

任务：

给应用层，RTE，BSW模块提供基础服务。

特性：

实现：除了OS部分功能外,不依赖于µC和ECU

接口：µC和ECU硬件独立

注意：

对I/O信号的访问是由ECU抽象层实现的。上面提到服务层应用层，RTE提供服务比较号理解。容易忽略的是也对BSW模块提供服务，其实也很好理解，比如其他BSW模块可能不可避免的需要使用OS服务。这又涉及到前面提到过的调用关系了。总的来说大的原则是从上至下调用。但横向互相调用也是可以的。只有下面调用/通知上面这种情况，AUTOSAR使用callback机制。

1.4 复杂驱动层（Complex Drivers Layer ）

如图所示，复杂驱动层从硬件直接跨越到RTE层。CDD为集成特殊功能提供了可能性。

任务：

• 那些没有在AUTOSAR里面规定的外设驱动。
• 对时序约束很高的驱动。
• 或者用于迁移集成等。

特性：

实现：可能是依赖于应用程序、µC和ECU的硬件的

上层接口：可能是依赖于应用程序、µC和ECU的硬件的

注意：

CDD虽然名字叫驱动，但它其实也可以是应用程序。例如vector的实现就是将CDD归类为SWC 与ECU硬件及MCU相关。

2、运行时环境层（Runtime Environment Layer）

RTE是为应用软件提供通信服务的。这些AUTOSAR软件组件之间/软件组件与服务之间的通信都由RTE来实现。这里说的应用软件包含AUTOSAR软件组件/传感器/执行器组件等。在RTE以上的软件架构风格由下面这种“层”的概念变为“软件组件”的风格。

任务

针对ECU进行映射以达到AUTOSAR组件完全独立/不依赖于ECU。

属性

实现：ECU和特定应用（为每个ECU单独生成）

接口：完全独立于ECU

AppL的组成

AppL中最重要的就是SWC了，而SWC与其他SWC通信需要接口，每个SWC中又由runnable组成，所以AppL主要的组成就分下面三部分：

1. 应用软件组件（SWC Software Component）
2. AutoSAR接口（Ports）和连接器（Connector）
3. 可运行实体（Runnable Entity）

一、举个例子

汽车顶灯的控制：

车内的顶灯一般有三种模式：

1. 常闭的模式
2. 常开的模式
3. 随车开关而开关的模式

好了，那么我们来捋一捋。

• 首先肯定是需要传感器（包括图上的和车门上的）
• 处理单元
• 执行器（图上的车顶灯）。

假如就以下图为简单逻辑而言：有左右两个车门，左右两个车灯，一个开关传感器。这里我们分配了7个SWC，将传感器、处理单元和执行器都分的很细，且这里并非由一个ECU控制。

二、SWC的通信

我们将上图的SWC整理一下，做成大家容易理解的横向一排的样式，如下：

SWC之间的通信是通过独立的一个层级进行交互，我们称其为虚拟功能总线（VFB)，也就是RTE的实现。该总线是意义上的片内外通信的结合体，取了个名字叫虚拟功能总线，其实际就是分两部分：

1. 在片内就是通过RTE通信。一个SWC可以理解为一个.c文件，那么c文件间怎么通信呢——全局变量。所以大家可以把ECU内部SWC的通信暂时先想象成全局变量，具体怎么实现的，在后续RTE章节中将做详述
2. 在片外就通过片外总线通信（一般汽车上都是CAN Bus）

上图中有几个特殊的符号是指的AutoSAR接口

而它们之间蓝色的连接线成为连接器（Connector，也即是刚刚说的全局变量)

三、应用软件组件（SWC Software Component）SWC类型

• 原子级的SWC（Atomic SWC）

​ 不可再拆分的SWC，其实之前我们列举的都是Atomic SWC，默认情况下说的SWC也是指ASWC。一个SWC是对应一个.c文件，这个c文件就是我们的最小单元，不可再分。

那可运行实体（runnable）不就是组成SWC的更小单元吗？确实如此，但是我们将SWC看成原子，那runnable就是其中的电子、质子和中子，它们与原子密不可分。因此将SWC看成是最小单元，runnable是其中的函数。每个SWC的功能基本都是用来实现特定的算法。

• 集合级的SWC（Composition SWC）

​ 有不可分割的SWC，就肯定有可分割的SWC。所以AutoSAR还规定了一类集合级的SWC（Composition SWC）。它们可以分为一个一个更小的Atomic SWC。就好像是一个分子由很多原子组成的概念。分子是有实际意义的，很多原子就没有实际意义（但是有些也有，比如金、银和铜等）。

还是那个例子，我们可以将功能相近或者需要整合到一处方便观看的SWC（以后Atomic SWC都简称为SWC）利用一个compositon SWC包含起来。这样，就可以方便SWC归类，这里Composition SWC有点从功能角度去看。

于是，我们的文件映射也发生了一定的变化：方便大家对比，应该能很快明白composition SWC是啥了：

注意： 在Vector的DaVinci中其实不会生成Composition的文件夹，其实Composition只是一个概念，是用来在配置工具上方便大家归类整理，看起来更加符合功能设定

• 特殊的SWC

​ 前面描述BSW的时候提到IO硬件抽象层（IoHwAb，BSW章节中会讲到）和复杂驱动（Cdd)，在DaVinci Developer中都是可以作为SWC进行配置和加runnable等操作的。因此，我们将其算成是特殊的SWC来看待

四、AutoSAR接口（Ports）和连接器（Connector）

Ports是SWC和SWC做接口（Interface）通信使用，或者SWC通过RTE和BSW做接口（Interface）通信使用。

• Sender Ports发送端口：提供信息

• Receiver Ports接收端口：接收信息

• Sender/Receiver Ports发送/接收端口：可在一个Port端口内提供和接收信息

• Server Ports服务端口：提供服务（operations)

• Client Ports客户端端口：使用服务（operations)

Connector指的是SwComponentType的PortPrototypes来连接建立SwComponentPrototypes之间的实际连接的SwConnector

Ports主要分为5种类型，列在下面的图中：

其中又可分类为：R-Ports、P-Ports和PR-Ports。值得注意的是，这里的PR-Ports是在AUTOSAR4.0以后定义。

或者又可以分为：**Send/Receiver（S/R）接口和Client/Server（C/S）**接口。

需型端口可以和供型端口连接。软件组件SWC1有一个需型端口（R）和一个供型端口（P），其中需型端口与SWC2的供型端口相连，它们之间的交互关系通过连线箭头表示，由SWC2的供型端口指向SWC1的需型端口。SWC3具有一个供需端口，被认为自我相连。 由于端口仅仅定义了方向，所以AUTOSAR中用端口接口 （Port Interface）来表征端口的属性

软件组件SWC1具有两个端口，其中一个引用的端口接口类型为发送者-接收者（S/R）接口，另一个引用的端口接口类型为客户端-服务器（C/S）接口。从中也可以看出，对于引用发送者-接收者接口的一组端口而言，需型端口为接收者 （Receiver），供型端口为发送者（Sender）。对于引用客户端-服务器 接口的一组端口而言，需型端口为客户（Client），供型端口为服务器（Server）。

一、S/R接口

作用： 传输数据。通过RTE传输数据，并且通过RTE管理数据的传输，避免数据出问题（例如同时调用同一数据时可能出错）

发送者-接收者接口用于数据的传递关系，发送者发送数据到一个或多个接收者。该类型接口中定义了一系列的数据元素（Data Element，DE），这些数据元素之间是相互独立的。如下图所示，该发送者-接收者接口SR_Interface中定义了两个数据元素，名字分别为DE_1与DE_2，并且需要为每个数据元素赋予相应的数据类型

• 一个接口可以包含多个数据，类似于通过结构体传输

• 可以传输基础数据类型（int，float等）和复杂数据类型（record，array等）

• 通信方式: 1:n 或者 n:1

• 如果一个data element要通过总线传输， 那么它必须与一个signal对应起来

• 通信方式 - 不使用队列

  • 直接访问

    适用于实时性要求高的数据，直接访问

    • RTE直接访问数据地址
    • 初始值即为默认值

    

  • 使用缓存

    适用于有一致性要求的数据组

    • 在进入runnable之前RTE为数据建立副本
    • 在runnable运行结束之后RTE把副本数据拷贝到实际数据地址
    • 在runnable运行过程中只操作副本，实际数据不会改变

  

• 通信方式-使用队列

  “event” (isQueued=True),”event“ 查询接收或等待接收，RTE从队列中读取数据，等待接收有超时处理。

  • “查询接收” 或 “等待接收”
  • RTE从队列中读取数据
  • “等待接收” 有超时处理

  

  //Read表示是一个RPort、同样也会有一个PPort，Rte_Write_xxx_xxx()
  Rte_Read_<Port>_<Data>()
  //这里Data是指的传输的数据类型，比如DoorOpen就是：
  SWC_DoorOpen = Rte_Read_Door_DoorOpen();
  

• 对于S/R通信模式，分为显示（Explicit）和隐式（Implicit）两种模式。当多个运行实体需要读取相同的数据时，若能在运行实体运行之前先把数据读到缓存中，在运行实体运行结束后再把数据写出去，则可以改善运行效率，这就是隐式模式。

二、C/S接口

作用： 提供操作。就是Server提供函数供Client调用

客户端-服务器接口用于操作（Operation，OP），即函数调用关系，服务器是操作的提供者，多个客户端可以调用同一个操作，但同一个客户端不能调用多个操作。客户端-服务器接口定义了一系列操作 （Operation），即函数，它（们）由引用该接口的供型端口所在的软件组（服务器）件来实现，并提供给引用该接口的需型端口所在的软件组件调用。如下图所示，该客户端-服务器接口CS_Interface中定义了两个操作OP_1 与OP_2，对于每一个操作需要定义相关参数及其方向，即函数的形参，需要注意的是，每个端口只能引用一种接口类型，并且引用相同端口接口类型的端口才可以进行交互。

• 可以同步和异步。同步就是直接调用，相当于函数直接插入上下文运行；异步的话需要等待，相当于让函数在另一个线程中运行，运行完了再返回，原上下文依然运行

  

• 一个接口可以提供多个操作，就是一个接口可以包含很多函数

• ECU内部和跨ECU都可以调用，跨ECU也是通过外部总线

• 通信方式: 1:1 或 n:1 （与S/R对应）

  Rte_Call_<Port>_<Function>()
  //这里的Call是指的调用的函数，比如调用State()就是
  Rte_Call_Door_State();
  

Runnable entities (简称Runnables)

Runnable就是SWC中的函数，而在AutoSAR架构在被DaVinci软件生成的时候，Runnable是空函数，需要手动添加代码来实现其实际的功能。 Runnable可以被触发，比如被定时器触发、被操作调用触发或者被接受数据触发等。

这里的函数就是我们前面提到的Send接口，发送的就是DoorOpen这个数据，由RTE进行管理。然而由于这里的这个SWCn.c文件中并未包含BSW中的.h文件，通过这个方式将AppL和BSW隔离开。

Runnable是需要OS中的Task做载体的。runnable是函数，但是c文件中光有一个函数那没用，必须要调用该函数才能起作用，就必须要有操作系统中的任务来执行这个函数。类比于Linux中的线程就是Task，这里的Runnable更多的像内核中的threadfn，或者说是Java中Runnable，需要载体，另外在AppL中没有Task这个概念。

举个例子：

从传感器到应用程序的过程:

代码什么样？

1.Runnable Entity(可运行实体 ）

Runnable是主要用来封装SWC中的功能的。是由C语言函数实现的。一个SWC中需要至少要包含一个Runnable。简单举个例子：

CheckStatusRunnable()
{
/* 判断是否完成 */
    if(!finished)
    {
/* 如果未完成，就返回不OK */
        return E_NOT_OK;
    }
    return E_OK； //如果完成，返回OK
}

Runnable 简单分为两类：

Category 1：No WaitPoint （在有限的时间内运行至结束，不能等待）。

Category 2：With a WaitPoint at least.（至少包含一个WaitPoint，运行过程中可以等待）

怎么在Runnable中设置WaitPoint？通过直接调用对应RTE API实现。

Rte_Receive() : 用于等待接收数据；

Rte_Feedback() : 用于等待数据发送完成；

• Rte_Invalidate_

  _()，表示sensor发送的数据无效，接收方feedback对无效值的处理

Rte_SwitchAck() : 用于等待模式切换操作；

Rte_Result() : 用于等待异步服务器调用的结果。

2. Task（任务）

是操作系统（OS）管理的最小可调度单元。操作系统决定何时在ECU的CPU上运行哪个任务。在OS启动后，所有的Task都处于默认状态：挂起状态（Suspended）。Task被激活（Activated）后进入准备状态（Ready）。Ready的task将会按照优先级（Priority）的高低依次运行（Running）。

在RTE的代码中：

TASK(TSK_Task1)
{
    ...
    Runnable1();
    Runnable2();
    CheckStatusRunnable();
    Runnable3();
    ...
  }
}
TASK(TSK_Task2)
{
  ...
}

当TSK_Task1被激活并运行后，map到它的Runnable也会按map的顺序依次执行。

3.运行实体的RTE事件（RTE Event）

每个运行实体都会被赋予一个RTE事件（Trigger Event），即RTE 事件（RTE Event），这个事件可以引发这个运行实体的执行。对于 RTE事件可以细分为很多种类，较常用的RTE事件有以下几种：

• 周期性（Periodic）事件，即Timing Event；
• 数据接收事件（Data-received Event）；
• 客户端调用服务器事件（Server-call Event）。

一、什么是RTE

RTE的作用有点像Binder的ServiceManger，或者说DNS（就是上个世界那种要先打电话到接线员那里，然后通过接线员转接电话线到目的地），其作用就是将一个SWC的信息通过RTE连接到其他SWC或者BSW上。且RTE具有管理这些信息的功能，比如接收的SWC正忙（您所拨打的用户正忙），那么RTE负责让发送信息的SWC等待，或者做其他处理；RTE还能触发SWC，就像是这时接收的SWC在睡觉，这时发送的SWC发信息来了，那么RTE就要把接收的SWC叫醒起床。一句话概括就是RTE提供了SWC的运行环境。

二、RTE的作用

• 提供 跨ECU / ECU内部 的通信管理，通过COM。
• 提供对runnable的管理功能（触发、唤醒等，简单说就是runnable需要映射到Task上运行嘛，而这个映射就是通过RTE具体实现的）
• 保证数据一致性(e.g. exclusive area)
• 支持简单数据及复杂数据(records)
• 在Vector的工具链中，RTE是自动生成的

下面这张图将其再做细化，就能很清楚的看出其关联关系了。这里的RTE就是统一的管理，具体那些连接时怎么连的，我们是不需要在RTE中关心的（因为AppL中配好，RTE就自动生成嘛）。

三、RTE主要功能点

• 通过RTE给runnable提供触发事件。 之前说过了runnable是可以被触发的，就是需要通过RTE来实现这个触发和调用runnable
• 通过RTE给runnable提供所需资源。 就是之前说的接口通信，将runnable需要的一些资源通过接口传输给它
• 将BSW和SWC做隔绝。 因此OS和runnables也被隔绝了，runnable的运行条件由RTE提供，不能由OS直接提供

FUNC(Std_ReturnType, RTE_CODE) Rte_Start(void)
{
	... ...
	/* activate the tasks */
  (void)ActivateTask(App_Task); 
  (void)ActivateTask(Task10ms); 
  (void)ActivateTask(Task1ms); 
  (void)ActivateTask(Task20ms);
  ... ...
  //设置定时alarm，1ms, 2ms, 10ms ... ...
  (void)SetRelAlarm(Rte_Al_TE_Task1ms_0_1ms, RTE_MSEC_SystemTimer(0) + (TickType)1, RTE_MSEC_SystemTimer(1)); 
  (void)SetRelAlarm(Rte_Al_TE_Task2ms_0_2ms, RTE_MSEC_SystemTimer(0) + (TickType)1, RTE_MSEC_SystemTimer(2)); 
  (void)SetRelAlarm(Rte_Al_TE_App_AppRunnable, RTE_MSEC_SystemTimer(0) + (TickType)1, RTE_MSEC_SystemTimer(10)); 
... ...
}

//RTE controlled tasks
//App_Task
TASK(App_Task)
{
  EventMaskType ev;

  for(;;)
  {
    (void)WaitEvent(Rte_Ev_Run_DemoApp_DemoRunnable);
    (void)GetEvent(App_Task, &ev);
    (void)ClearEvent(ev & (Rte_Ev_Run_DemoApp_DemoRunnable)); 

    if ((ev & Rte_Ev_Run_DemoApp_DemoRunnable) != (EventMaskType)0)
    {
      /* call runnable */
      AppRunnable(); 
    }
  }
} 

TASK(Task10ms) 
{
  EventMaskType ev;

  for(;;)
  {
    (void)WaitEvent(Rte_Ev_Cyclic_Task10ms_0_10ms); 
    (void)GetEvent(Task10ms, &ev); 
    (void)ClearEvent(ev & (Rte_Ev_Cyclic_Task10ms_0_10ms)); 

    if ((ev & Rte_Ev_Cyclic_Task10ms_0_10ms) != (EventMaskType)0)
    {
        //10ms swc runnable
        AppSiganlRunnable();
        AppConfigRunnable();
        AppInputRunnable();
        ... ...
    }
  }

Runnables的触发条件

ECU之间通信：

跨ECU的数据传输，在runnable中使用Rte_Write__()这样的函数后，会需要走runnable (ECU1) ->RTE (ECU1) ->BSW (ECU1) ->外部总线->BSW (ECU2) ->RTE (ECU2) ->runnable (ECU2) COM传输的接口函数:

保证数据一致性

同一个SWC内的、运行在不同Task上的runnable之间的通信.

不同SWC之间的通信，无论是ECU内部还是ECU之间，都不会遇到这个问题，因为RTE会负责保证数据一致性.

• 顺序调度策略
• 中断屏蔽策略
• 资源锁等
• 数据备份

假如有两个任务，分别为Task A和Task B，其中Task A的优先级高于Task B。Task A每次访问均使X加2，Task B每次访问均使X加1。因此这两个任务中都要执行（step1）、修改（step2）、写（step3）三步操作。如果没有原子操作，则可能会发现以下情况，如图所示：

1. 假定X=5；
2. Task B执行读取（step1) X=5，并临时存储（堆栈或MCU寄存器中）；
3. Task A 优先级高于Task B， Task B被打断；
4. Task A执行读，修改，写操作，将X=7写回内存中；
5. Task A结束，继续执行Task B；
6. Task B将之前临时存储的X（操作2）取出，并加1，将X=6写回内存。

显然，开发人员期待的 结果是X = 8，但是最终的确实X = 6，Task A的运算失效。

解决办法:

• 专用区域(Exclusive Areas )

  • Entire block or RTE protected

  • Rte_Enter_()

  • Rte_Exit_()

    Rte_Enter_<name>();
    //需要保护的代码
    ....
    Rte_Exit_<name>();
    

• 内部变量(Inter-runnable variables)

  • 运行实体间变量（Inter Runnable Variable，IRV）即两个运行实体之间交互的变量。
  • Rte_IrvWrite__

AUTOSAR的接口

AUTOSAR中定义了三种接口，AUTOSAR Interface, Standardized Interface 以及 Standardized AUTOSAR Inerface. 要了解这三种接口，需要首先了解什么是"Standardized"的Interface，以及什么是"AUTOSAR"的Interface.

Standardaized 表示的是，这个接口是被事先标准化定义好的, 需要注意的是这里的"标准化定义"，指得就是被AUTOSAR这个标准所定义。用户在使用这个接口的时候，不可以改变接口的内容。所谓"接口"，其实就是一个API函数. AUTOSAR标准中的软件模块被事先定义好，需要向其它模块提供哪些API函数, 这些API函数的输入输出变量的个数，类型以及返回值的类型都会被事先定义好，不能改变。在开发时需要做的，就是开发API中的内容。

AUTOSAR 的接口指的RTE提供的接口。RTE向所有的SWC，以及IoHwAb和Complex Drivers模块，提供AUTOSAR 接口，也就是说，这些模块都会连接在RTE上面。当某两个这类模块之间互相收发数据或者调用内部函数时，RTE会帮助它们来做这些。

理解了Standardized Interface 和 AUTOSAR Interface, 那么 Standardized AUTOSAR Interface 就容易理解了。指的是，被AUTOSAR标准提前定义好的，并且是由RTE提供的接口。

下面这个表格是关于这三个接口的总结:

OS和COM是唯一的两个标准接口允许直接和RTE相连的。因为RTE的很多功能是需要基于这两个模块来实现的。

还是回到之前的案例，如下图

上图将所有的接口以及其分布的位置都详细的标识了出来，还是用的原来的那张ECU的图添加，结合上面的描述和上图：

AutoSAR接口

• 一句话概括： 之前说的S/R和C/S接口就是AutoSAR接口
• 特征： 接口函数名可变，例如之前说过的Std_ReturnType Rte_Read_<port>_<data> (<DataType> *data)这中形式的S/R函数，其中的<port> <data>就是用户自己配置的名字，因此，这些接口的函数名都是可以改变的，但大体的形式是不变的。
• 位置： SWC<>RTE、RTE<>CDD、RTE<>ECU AB(这里提一句，ECU AB之前没有讲到，其实很多的传感器、执行器都放在这里，是ECU的抽象，也是可以看作是SWC的，IoHwAb就在这里面)。说明白一点，就是只要能看成是SWC处理的，就是AutoSAR接口

标准接口

• 一句话概括： 就是AutoSAR规定的C语言API
• 特征： 接口函数名是固定不变的，是AutoSAR规定好的。比如：Com_SendSignal() WaitEvent()这类都是API函数名，可以有上层调用，但是一般是使用工具配置生成的，做上层应用的一般是不用关心其具体实现的
• 位置： 第一张图中棕色的就是标准接口，说白了就是对函数API的调用。

需要特殊说明一点的是：下图中两个红圈中的箭头，OS和COM是唯一的两个标准接口允许直接和RTE相连的。因为RTE的很多功能是需要基于这两个模块来实现的

标准AutoSAR接口

• 一句话概括： 就是AutoSAR接口，不过名称是由AutoSAR官方规定不能修改
• 特征： 就是标准接口和AutoSAR接口的特征它都有一部分。首先是和AutoSAR接口一样，提供的是C/S、S/R接口；然后又和标准接口一样，函数名是不可变的。说白了就是官方规定好的C/S、S/R接口，咱们就当成是AutoSAR接口就行了，函数名字什么不用管它
• 位置： RTE<>Services，就这么一个地方

AUTOSAR方法论 (methodology)

一、ECUEX简介

什么是ECUEX文件呢？开始提到ECU提取文件（全称是ECU Extract of System Description），简单说就是OEM和TIER1交接的文件。该文件由OEM设计整车时生成，并根据不同的ECU提取出对应的ECUEX文件交接给TIER1，TIER1拿到文件后便可以根据上面的信息来设计和开发ECU。ECUEX文件是arxml文件，但是如果只做通信矩阵这些内容，DBC(Database Can)这类文件也可以胜任（不过随着时代的进步，以后还是arxml）。

要可以包含以下内容（也可以只包含其中一部分）：

• 通信矩阵： 比如CAN总线包含的信息，像CAN ID号、signals、扩展帧还是普通帧和波特率之类的信息
• SWCs、Ports等： SWC以及内部的runnable都可以在ECUEX文件中给出；还包含其Ports；还有SWC之间的连接关系（Connecters）
• 数据映射（Data Mapping）： 将总线的信号（Network Signals）映射到SWCs中

ECUEX文件可以很简单（简单到只有通信矩阵），也可以很复杂（复杂到连一部分代码都要自己写）。

某些OEM和TIER1的分工，不绝对，未来OEM会负责更多的事务：

| 名称 | 解释 | OEM | TIER1 | | ------------------ | -------------------------------------------------------- | ------ | ------ | | Service Components | 为SWCs提供实际使用的BSW服务的接口（需要在BSW中配置过了） | 不负责 | 负责 | | Service Mapping | 连接SWCs和Service Components | 不负责 | 负责 | | Atomics | 功能的具体实现 | 不负责 | 负责 | | Compositions | 每个SWC上需要哪些Port、连接器之类的 | 不负责 | 负责 | | Data Mapping | 连接Network Signals到SWCs中 | 不负责 | 负责 | | ECU Composition | 就是需要哪些SWC | 不负责 | 负责 | | Communication | 就是上面说的通信矩阵 | 负责 | 不负责 |

二、AutoSAR开发流程

AUTOSAR文档如何阅读

1、文档查询

从autosar.org 官网可以下载和查询文档：

AUTOSAR官网

选中classic可以看到有的版本，通过search按钮可以查询对应的文档。

基本上一年一个版本，目前已经release了R22版本，22年11月份。

由于官网的维护和改版，和之前的版本有了较大的变化，没有办法按照功能组去下载对应的文档了。

2、文档类型

文档目前官网处于R22发布重新维护中，当前文档服务无法提供，文档也无法下载，需要下载的我这边可以提供。

AUTOSAR文档目录

可以看到从文件命名的格式来看，都是AUTOSAR开头，以AUTOSAR_XXX_YYY 等结尾，XXX主要分为如下几个大类：

文档下载列表中带有 GENERAL 的为 High-level 的一般性文档，应该优先阅读。

下面详细解释一下各项简写的意思：

• **MMOD：**Meta Model，介绍AUTOSAR的元模型

  元模型的本质是沟通工具，是模型的模型

  举个例子：一个具体的流程图，比如应用启动流程、消息发送流程等都是模型，而让不同的人看到模型都能理解其中的含义就是元模型的功劳了，具体来说就是方框代表什么、菱形代表什么，更直白点就是你画图的时候工具栏上的工具条。

  没错，我们常说的UML，就是统一建模语言，AUTOSAR元模型是UML2.0模型（2.0基于1.x，对结构类、精确的接口和端口、拓展性、交互片断和操作符以及基于时间建模能力做了增强）。

  使用UML定义的AUTOSAR Meta-model没有太大必要单独去看，因为所有相关信息和图表都会在AUTOSAR Template Specification里有。下图是基于EA打开的AUTOSAR_MMOD_MetaModel.zip,可以看到各种UML图

  

  AUTOSAR_MMOD_MetaModel

• **MOD：**model，介绍基于元模型建模的原理，一般指的是如下的arxml，该标准介绍了如何将AUTOSAR模型序列化为AUTOSAR XML描述的规则，为AUTOSAR工具之间的互操作性提供支持。

  

  • AUTOSAR_MOD_GeneralDefinitions.zip
  • AUTOSAR_MOD_MiscSupport.zip
  • AUTOSAR_MOD_GeneralBlueprints.zip
  • AUTOSAR_MOD_BSWUMLModel.zip
  • AUTOSAR_MOD_ECUConfigurationParameters.zip
  • AUTOSAR_MOD_AdaptivePlatformGeneralBlueprints.zip

  例如所有安全事件定义集中在AUTOSAR_MOD_GeneralDefinition_SecurityEvents.arxml文件中

  

  AUTOSAR_MOD_GeneralDefinitions.zip

• **RS：**Requirement Specification，需求规范，层次比SRS要高，比如AUTOSAR_RS_Main.pdf中对架构、基础软件、方法论等进行了明确的规范(如下图所示)。

  文档需求规范	需求规范示例

• **TR：**Technical Report，技术报告，比如AUTOSAR_TR_PredefinedNames.pdf用于对不同的缩写进行了说明。

• **TPS：**Template Specification，模板规范，用于介绍模块的处理架构、层次关系等，比如下图对诊断事件的层次结构进行的规范(如下图所示)。

  

• **EXP：**Explaination，说明文档，对其他文档中提到的内容进行解释说明。

  • 例如AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf，这是非常非常重要的一部分，大多的基础概念来自于这个文档。

• **SRS：**Software Requirement Specification，软件需求规范，用于对各个软件模块功能需求进行说明。例如AUTOSAR_SRS_OS，定义了OS的各类需求，包括需求来源

  

  图示:AUTOSAR_SRS_OS.pdf SRS需求定义

• SWS：Software Specification，软件规范，详细介绍模块设计和实现原理，包括模块功能的详细介绍，API接口介绍，数据类型介绍，软件的流程图(如下图所示)，一般软件开发，重点我们看这个文档

  

图示:AUTOSAR_SWS_OS.pdf 软件设计定义

如何阅读？

对于大部分基于工具的AutoSAR工作者来说，只需要看SWS即可；一般来说，对于工具开发商而言，其也会提供一套参考文档（比如Vector公司提供的文档位于TechnicalReferences下）。对于AutoSAR工具的开发者而言，或者一些需要手写AutoSAR代码的，就需要按需求深入理解文档了。

为什么不建议通读？

闲来无聊，统计了一下文档的页数：

# !/usr/bin/env python3
import argparse
from glob import glob
from os.path import exists, join
from PyPDF2 import PdfFileReader


def get_total_pages(folder):
    if not exists(folder):
        return "文件目录: {}  不存在".format(folder)
    pdf_list = glob(join(folder, "*.pdf"))

    pages = []
    for pdf in pdf_list:
        reader = PdfFileReader(pdf)
        num_page = reader.getNumPages()
        pages.append(num_page)
    return [sum(pages), len(pdf_list)]


if __name__ == "__main__":
    parser = argparse.ArgumentParser()
    parser.add_argument('folder', type=str, help='输入文件路径')
    args = parser.parse_args()
    [total_pages, files] = get_total_pages(args.folder)

    print("'%s'\n 文件数: %d  总页数:%d " % (args.folder, files, total_pages))

按照A4纸每页0.104mm的厚度计算，27300页单面打印出来2.8米高，

三、AUTOSAR文档阅读建议

CP文档的阅读：

一般性文档

• AUTOSAR_EXP_VFB 虚拟总线，建议从这个了解SWC开发

• AUTOSAR_EXP_LayeredSoftwareArchitecture 整体 Overview，建议从这份文档开始学习

详细了解文档：

• AUTOSAR_SWS_OS autosar OS的描述
• AUTOSAR_SWS_RTE 运行时环境
• AUTOSAR_SWS_COM 通讯模块
• AUTOSAR_SWS_BSWGeneral BSW模块的规范
• AUTOSAR_TR_Methodology CP 方法论

AP 部分

一般性文档

• AUTOSAR_EXP_PlatformDesign：整体 Overview，建议从这份文档开始学习
• AUTOSAR_EXP_SWArchitecture：软件架构
• AUTOSAR_EXP_AdaptivePlatformInterfacesGuidelines：接口使用指引
• AUTOSAR_EXP_ARAComAPI：通信管理API

有些 High-level 文档可以先快速浏览，用到的时候再细看：

• AUTOSAR_TR_FunctionalClusterShortnames：各个 FC 的缩写
• AUTOSAR_RS_General：编码风格指南
• AUTOSAR_RS_CPP14Guidelines：MISRA C++ 编码规范，已废弃，之后交给 MISRA 维护，不再由 AUTOSAR 维护
• AUTOSAR_TPS_ManifestSpecification：Manifest 规范
• AUTOSAR_TR_AdaptiveMethodology：AP方法论
• AUTOSAR_RS_OperatingSystemInterface：操作系统接口
• AUTOSAR_SWS_AdaptiveCore

如果你不知道从哪份文档开始阅读，我建议可以从这份开始 AUTOSAR_EXP_PlatformDesign.pdf

AUTOSAR的Hello World

Comming soon.....~~

AUTOSAR的Hello World

Comming soon.....~~

1、概述 DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信。

：

1、概述 DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信。

1、概述 DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信。

1、概述 DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信。

1、概述 DoIP是Diagnostic communication over Internet Protocol 的简称，顾名思义，就是通过网络协议进行诊断通信。

MISRA C

一、简介

MISRA C是由汽车产业软件可靠性协会（MISRA）提出的C语言开发标准。其目的是在增进嵌入式系统的安全性及可移植性。针对C++语言也有对应的标准MISRA C++。本文主要关注C语言部分。MISRA C一开始主要是针对汽车产业，不过其他产业也逐渐开始使用MISRA C：包括航天、电信、国防、医疗设备、铁路等领域中都已有厂商使用MISRA C。

MISRA C的第一版《Guidelines for the use of the C language in vehicle based software》是在1998年发行，一般称为MISRA-C:1998.。MISRA-C:1998有127项规则，规则从1号编号到127号，其中有93项是必需要求，其余的34项是推荐使用的规则。

在2004年时发行了第二版的MISRA C的第一版《Guidelines for the use of the C language in critical systems》（或称作MISRA-C:2004），其中有许多重要建议事项的变更，其规则也重新编号。MISRA-C:2004有141项规则，其中121项是必需要求，其余的20项是推荐使用的规则。规则分为21类，从“开发环境”到“运行期错误”。

2012年发布第三版，为当前最新有效的C语言规范版本，称为MISRAC:2012。

Misra C不能100%保证程序不出问题，但是能尽可能的预防，总结一下，基本上使用Misra C具有以下五个维度的优势：

• 提升可靠性
• 提升可读性
• 提升可移植性
• 提升可维护性
• 提升安全性

二、具体规则（翻译）

2.1 一个标准C环境

1. 必需。程序应不包含违反标准C语法和限制的内容，也不应超出执行的翻译限制。
2. 建议。不应使用语言扩展。
3. 必需。不应该出现未定义或是临界的未指定行为。

2.2 不使用的代码

1. 必需。不应包含未执行的代码。
2. 必需。不应该有死代码。
3. 建议。不应包含被声明但未使用的类型。
4. 建议。不应包含未使用的标签声明。
5. 建议。不应包含未使用的宏定义。
6. 建议。函数中不应包含未使用的标记。
7. 建议。不应有未使用的函数参数。

2.3 注释

1. 必需。不允许嵌套注释。
2. 必需。不允许在//注释中进行行拼接。

2.4 字符集

1. 必需。八进制和十六进制转义字符序列应被终止。
2. 建议。三字母词不应使用。

2.5 标识符

1. 必需。外部标识符应区分开。
2. 必需。标识符声明在同一作用域且位域应被区分。
3. 必需。声明于内部作用域的标识符不应隐藏外部作用域的标识符。
4. 必需。宏标识符应被区分。
5. 必需。标识符要区别于宏名。
6. 必需。Typedef名应是独一无二的标识符。
7. 必需。标签应是独一无二的标识符。
8. 必需。定义有外部链接的对象或函数的标识符应是独一无二的。
9. 建议。定义有内部链接的对象或函数的标识符应是独一无二的。

2.6 类型

1. 必需。位域只能被定义为一个合适的类型。

   C90：无符号整型和有符号整型。C99：除上述两个以外还有布尔类型。

2. 必需。单比特命名的位域不应是有符号类型。

2.7 常量

1. 必需。不要使用八进制常量和八进制的转义字符串；
2. 必需。所有以无符号类型表示的整型常量都应加上u或U后缀。
3. 必需。小写字母l不应用于文字后缀。
4. 必需。除非对象类型是指向字符常量的指针，否则字符串不应赋给对象。

2.8声明与定义

1. 必需。类型应被显式声明。
2. 必需。函数应以原型形式命名参数。
3. 必需。所有对象和函数的声明需要使用完全相同的名字和参数。
4. 必需。当定义有外部链接的对象或函数时，兼容声明是可见的。
5. 必需。外部变量或函数应被在仅一个文件内被声明过。
6. 必需。有外部链接的标识符应有一个确切的外部定义。
7. 建议。若函数和对象仅被一个单元引用，最好不定义外部链接。
8. 必需。静态存储类说明符应在所有具有内部链接的对象和函数的声明中使用。
9. 建议。如果一个对象的标识符仅在一个函数内出现，该对象应被定义在一个块域中。
10. 必需。内联函数定义时应有静态存储类。
11. 建议。当有外部链接的数组被定义，它的大小应明确表示。
12. 必需。枚举列表内的枚举值应独一无二。
13. 建议。可能的话指针最好指向一个const类型的变量。
14. 必需。restrict限定词不应使用。

2.9 初始化

1、强制。自动变量在使用前应该被赋值。

2、必需。结构和和联合体的初始化应在大括号内完成。

3、必需。数组不应被部分初始化。

4、必需。一个对象的元素不应被多次初始化。

5、必需。若一个数组对象被指定初始化，那么数组大小应明确表示。

2.10 基本数据类型

1. 必需。操作数不应是不合适的数据类型。
2. 必需。表达式字符之间不应使用加减法。
3. 必需。不应将表达式的值赋给不同类型或更窄的类型。
4. 必需。一个运算符的两个操作数应是相同类型。
5. 建议。表达式的值不应被转换成一个不合适的类型。
6. 必需。复合表达式的值不应赋给一个有更宽类型的对象。
7. 必需。若复合表达式参与数学运算，那么另一个操作数不应是更宽的基本类型。
8. 必需。复合表达式的值不应被转换为不同的基本类型分类或更宽的基本类型。

2.11指针类型转换

1. 必需。不应在函数指针和其他类型间进行转换。例外：空指针可被转换为函数指针。函数指针可被转换为void类型。函数可以被隐式转换为该函数类型的指针。
2. 必需。指向不完全类型的指针与其他类型间的转换不应出现。
3. 必需。不同类型指针间不应转换。
4. 建议。不应将指针转换为整形变量。
5. 建议。不应直接将void类型指针转换为指向对象的指针。
6. 必需。算数类型和void类型指针不应转换。
7. 必需。指向对象的指针和一个非整型算数类型不应转换。
8. 必需。指针指向的const和volatile修饰的变量不应被删除。

2.12 表达式

1. 建议。表达式中的运算符优先级应明确。
2. 必需。移位运算符的右手操作数应该小于左手操作数的基本类型的位宽。
3. 建议。不应使用逗号运算符。
4. 建议。常量表达式的计算不应导致无符号整数的回绕。

2.13 副作用

1. 必需。初始化列表不应包含持续副作用。
2. 必需。表达式的值和他的持续副作用应在允许的计算顺序下保持相同。
3. 建议。包含自增或自减的完整表达式应无其他除自增自减外的潜在副作用。
4. 建议。不应使用赋值运算的结果。
5. 必需。逻辑与和逻辑或的右手操作数不应包含持续副作用。
6. 强制。sizeof运算符的操作数不应包含任何有潜在副作用的表达式。

2.14 控制语句表达式

1. 必需。循环计数器不应有浮点型数据。
2. 必需。for循环应完整。
3. 必需。控制语句不应一成不变。
4. 必需。if语句和迭代表达式应有布尔类型。

2.15 控制流

1. 建议。不应该使用goto语句。
2. 必需。goto语句应跳跃至同一函数后定义的语句处。
3. 必需。被goto语句引用的任何标志都应在同一块内定义或任何包含goto语句的块。
4. 建议。不应有多个break或goto语句来结束迭代语句。
5. 建议。一个函数在其结尾应该有单一的退出点，即一个函数最多有一个return语句。
6. 必需。迭代语句和选择语句的主体应是复合语句。
7. 必需。if elseif语句应由一个else语句结束。

2.16 Switch语句

1. 必需。所有switch语句都要是完整的。
2. 必需。switch标签应仅用于最紧密封闭的复合语句作为switch语句的主体时。
3. 必需。每个switch分支都要有一个break语句。
4. 必需。每个switch语句都要有一个default标签。
5. 必需。default标签应出现在switch语句的第一个或最后一个标签处。
6. 必需。每个switch语句都要至少包含两个分支。
7. 必需。switch表达式不应有布尔类型。

2.17 函数

1. 必需。头文件<stdarg.h>内的功能不可使用。
2. 必需。函数不能调用自身，不管是直接或者间接的，即不允许递归调用；
3. 必需。函数应被明确定义。
4. 必需。所有函数退出位置都应有相应的返回语句，除了返回值为void类型的函数。
5. 建议。函数参数中若有数组，在调用函数的时候数组大小应与定义时的数组大小相同。
6. 强制。定义数组时不应在[]中包含static修饰的变量。
7. 必需。非空返回值的函数的返回值应被使用。
8. 建议。函数参数不应被修改。

2.18 指针和数组

1. 必需。数组的索引应该是指针数学运算中唯一可允许的方式。
2. 必需。只有基类型相同的指针间才可以相减。
3. 必需。除非指针指向同一个对象，否则不应使用关系运算符进行比较。
4. 建议。不要使用+、+=和-=操作符来应用于指针类型表达式。
5. 建议。不要定义两级以上的指针。
6. 必需。具有自动存储功能的对象的地址不得复制到第一个对象停止存在后仍然存在的另一个对象。
7. 必需。数组定义时必需指定大小。
8. 必需。变长数组不应使用。

2.19 重叠存储

1. 强制。一个对象不得分配或复制到一个重叠的对象。
2. 建议。union关键字不应被使用。

2.20 预处理指令

1. 建议。#include指令前应只存在预处理器指令或注释。
2. 必需。头文件名中不应包含‘，’和注释字符。
3. 必需。#include后应跟随或“filename”。
4. 必需。宏名不应与关键字冲突。
5. 建议。不要使用#undef。
6. 必需。宏的参数中不应出现类似预处理指令的符号。
7. 必需。由宏参数扩展产生的表达式应用括号括起来。
8. 必需。#if或#elif预处理指令的控制表达式应赋值为0或1.
9. 必需。#if或#elif中控制表达式使用的标识符在赋值前应被#define。
10. 建议。#和##预处理器操作符不应使用。
11. 必需。宏参数在紧随#后后续不得有##紧跟该参数。
12. 必需。宏参数用作#或##操作符的操作数，这本身就是收到进一步的宏替换，应仅被用作这些操作符的操作数。
13. 必需。以#开头的一行应是有效的预处理指令。
14. 必需。所有的#else、#elif和#endif预处理指令应该同与他们相关的#if或者#ifdef指令放在相同的文件中。

2.21 标准库

1. 必需。#define和#undef不得用于保留标识符或保留宏的名字。
2. 必需。不应定义保留的标识符或宏名。
3. 必需。<stdlib.h>的allocation和deallocation函数不应使用。
4. 必需。不应使用标准头文件<setjmp.h>。
5. 必需。不应使用标准头文件<signal.h>。
6. 必需。标准库中的输入输出函数不应使用。
7. 必需。不应使用<stdlib.h>的atof，atoi，atoll函数。
8. 必需。不应使用<stdlib.h>的abort，exit，getenv和system函数。
9. 必需。不应使用<stdlib.h>的bsearch函数。
10. 必需。不应使用标准库中的时间和日期函数。
11. 必需。不应使用标准头文件<tgmath.h>。
12. 建议。不应使用<fenv.h>中的异常处理功能。

2.22 资源

1. 必需。用标准库函数动态获得的资源应显式释放。
2. 强制。仅用标准库函数分配的内存需要被释放。
3. 必需。同一文件不应在同一时间在不同流中读写。
4. 强制。不应尝试在以只读形式打开的流中写入数据。
5. 强制。指向文件对象的指针不应被引用。
6. 强制。在相关流关闭后文件指针的值不应使用。

Continuous Integration

下面所有的缩写词汇均来自autosar官方资料，主要来源于AUTOSAR_TR_GLOSSARY.pdf，还有一些其他文档中的术语添加，方便后续查找.

#各位贡献者名单