AUTOSAR技术简介

总体概述

E/E架构：分布式

• 汽车电子电气架构（Electrical/Electronic
  Architecture），集合汽车的电子电气系统原理设计、中央电器盒的设计、连接器的设计、电子电气分配系统等设计为一体的整车电子电气解决方案的概念。
  
  通过EEA的设计，可将动力总成、驱动信息、娱乐信息等车身信息转化为实际的电源分配的物理布局、信号网络、数据网络、诊断、容错、能量管理等的电子电气解决方案。
  
  
  
  传统上，当一个新功能被添加到汽车上时，方法只是简单地添加一个ECU，多一点电线和线束布线，然后嵌入硬件和软件。最后，也是最难的部分——找到放置它的最佳位置。自从汽车问世以来，我们一直在不断地增加，非常拥挤。
  CAN总线的出现改善了当时电子电气架构的效率与互操作性。另外，CAN总线还显著降低了系统的复杂度，而复杂度降低又意味着可以减少布线数量。在这种情况下，不仅可协助车辆实现最高减重45kg公斤，还能节约珍贵的安装空间。
  
  但即使这样，如今的高档车使用100多种不同的ECU，线束长度从1.5英里增加到2.5英里。在这种架构下，大量ECU单元会相互协同工作，共同为驾驶员能提供各种功能。但这种架构已经快要“到达极限”了，就不可避免的会带来以下问题：
  Swap（Size，Weight，Power）
  （1）电子电气部件占据整车大量有效空间
  （2）硬件开销，功耗，重量随之增加，导致油耗也随之增加
  （3）整车的架构设计开发难度增大

总线通讯
（1）架构的复杂性增加（协议，线束，ECU，网关等）
（2）整车总线负载率Overload增加
（3）某些信号会在多个子网中重复发送

集成验证
E/E架构的复杂性增加，意味着OEM在集成验证更加困难。 如果需要实现一个较为复杂的功能，需要许多个控制器同时开发完成才能进行验证。以及如果其中任意一个控制器出现问题，就可能导致整个功能全部失效。
既然分布式架构缺点如此明显，但为何却成为主流呢？原因是：采用分布式控制策略可以最大程度地利用汽车电气系统已有的软硬件资源和成熟的技术方案，从而有效地降低研发成本并缩短开发周期。
但分布式架构也导致各个物理子系统之间的相互协作关系复杂，增加了在各个物理子系统之间平衡需求以及将各个物理子系统进行系统集成时的工作难度，这会在一定程度上增加开发成本，但只要车型具有一定规模的销量，这些开发成本可以被节省下来的软硬件资源费用所抵消，因此对于复杂的涉及多个物理子系统的整车级电气功能，采用分布式架构已经成为一种主流趋势。

为什么要用AUTOSAR ?

• AUTOSAR是Automotive Open System
  Architecture（汽车开放系统架构）的首字母缩写，是一家致力于制定汽车电子软件标准的联盟。AUTOSAR是由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立，各成员保持开发合作伙伴关系。自2003年起，各伙伴公司携手合作，致力于为汽车工业开发一个开放的、标准化的软件架构。AUTOSAR这个架构有利于车辆电子系统软件的交换与更新，并为高效管理愈来愈复杂的车辆电子、软件系统提供了一个基础。此外，AUTOSAR在确保产品及服务质量的同时，提高了成本效率。

  [添加链接描述](https://www.autosar.org/)
  

• 现如今汽车电子进入的了高速发展的时代，据统计一辆高档的汽车其内部的代码量差已经超过了1kw行，超过上百个ECU。而随着顾客对功能需求的增加，以及整车厂对顾客需求的满足，这个数字还会不断的增加。日益增加的功能需求与软件复杂度之间似乎有一个不可逾越的横沟！因为在传统的E/E开发流程中存在着如下现状：

（1）电子系统复杂性的爆炸性增长
（2）软件代码急速上升
（3）生命周期差别：整车的生命周期往往长于ECU的生命周期
（4）嵌入式系统不支持硬件抽象
（5）有限的软件模块化
（6）软件重用性差：
当硬件型号（处理器型号）更换后，软件往往要倒推重写
（7）五花八门的硬件平台
这是因为上述现状，各大厂商纷纷开始寻求解决办法，而当他们发现这些矛盾不是以一己之力就能解决的时候，Autosar就诞生了！

• 整车软件系统可通过AUTOSAR架构对车载网络、系统内存及总线的诊断功能进行深度管理，它的出现有利于整车电子系统软件的更新与交换，并改善了系统的可靠性和稳定性。目前支持AUTOSAR标准的工具和软件供应商都已经推出了相应的产品，提供需求管理，系统描述，软件构件算法模型验证，软件构建算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝的系统软件架构开发流程。

• AUTOSAR计划目标主要有三个：
  1）建立独立于硬件的分层软件架构；
  2）为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU；
  3）制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同汽车平台复用。

分层概述

AUTOSAR整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件（Basic Software）。
|

• AUTOSAR整体框架为分层式设计，以中间件RTE(Runtime Environment)为界，隔离上层的应用层（Application Layer）与下层的基础软件（Basic Software）。
  
  

• Application Layer（应用层）
  
  应用层中的功能由各软件组件SWC（software component）实现，组件中封装了部分或者全部汽车电子功能，包括对其具体功能的实现以及对应描述，如控制大灯，空调等部件的运作，但与汽车硬件系统没有连接。

• 软件组件SWC（software component）
  

• 端口Ports
  端口Ports是用来和其他SWC通信。通信内容分为Data elements与operations。其中，Data elements用Sender/Receiver通信方式；operations用Client/Server通信方式。
  

• 可运行实体（Runnables entities）

  可运行实体（Runnablesentities），简称Runnables。可运行实体包含实际实现的函数，可以是具体的逻辑算法或是实际操作。可运行实体由RTE周期性或是事件触发调用，如当接收到数据。
  ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210126092530949.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Z1aGFuZ2ExMjM=,size_16,color_FFFFFF,t_70#pic_center)
  

• Runtime environment层（RTE）
  
  中间件部分给应用层提供了通信手段，这里的通信是一种广义的通讯，可以理解成接口，应用层与其他软件体的信息交互有两种，第一种是应用层中的不同模块之间的信息交互；第二种是应用层模块同基础软件之间的信息交互。而RTE就是这些交互使用的接口的集散地，它汇总了所有需要和软件体外部交互的接口。从某种意义上来看，设计符合AUTOSAR的系统其实就是设计RTE。

• SWC之间的通信是调用RTE
  API函数而非直接实现的，都在RTE的管理和控制之下。每个API遵循统一的命名规则且只和软件组件自身的描述有关。具体通信实现取决于系统设计和配置，都由工具供应商提供的RTE
  Generator自动生成的。
  

• Basic software层（BSW）
  
  虽然汽车中有各种不同的ECU，它们具有各种各样的功能，但是实现这些功能所需要的基础服务是可以抽象出来的，比如IO操作，AD操作，诊断，CAN通讯，操作系统等，无非就是不同的ECU功能，所操作的IO、AD代表不同的含义，所接收发送的CAN消息代表不同的含义，操作系统调度的任务周期优先级不同。这些可以被抽象出来的基础服务被称为基础软件。根据不同的功能对基础软件继续可以细分成四部分，分别为服务层（Service Layer），ECU抽象层（ECUAbstract Layer），复杂驱动（ComplexDriver）和MCAL（Microcontroller Absstraction Layer），四部分之间的互相依赖程度不尽相同。
  

功能分类

摘自成都道纬科技公司

• VKware AUTOSAR OS 产品特性

  AUTOSAR OS是专为汽车电子控制领域设计的可抢占、多任务、高性能的嵌入式实时操
  

作系统。结合AUTOSAR开放系统架构的方法学与配置概念，结合多年AUTOSAR基础软件产
品研发与应用经验，充分应用AUTOSAR配置理念，实现了最大程度地降低资源消耗，提高
源码级的可裁剪性。

VKware AUTOSAR4.3 OS有以下特性：

1. 系统符合AUTOSAR4.3标准且兼容OSEK/VDX OS 2.2.3标准；
2. 系统配置按照标准全部实现为编译器配置，编译后不可进行更改；
3. 最大支持16个核，提供核启动关闭、核间同步、跨核调用功能；
4. 最大支持4095个任务，可配置任务可抢占或不可抢占；
5. 支持中断嵌套，提供一类和二类中断，满足不同实时性应用需求；
6. 提供堆栈溢出和堆栈使用率检测；
7. 最大支持32个跨核事件设置、同步；
8. 提供核内资源互斥访问机制；
9. 提供核间资源互斥访问机制——自旋锁；
10. 提供软硬件计数器功能；
11. 支持周期警报、调度表；
12. 提供外设地址访问接口；
13. 当前已实现支持芯片：英飞凌AURIX TC27X。

开发流程

研究AUTOSAR的工程师在OEM、TIER1和TIER2都会有分布，各自角色不同，研究重点也不同。我们按产品开发流程的顺序大致梳理：
1、整车厂以EE架构设计和应用层功能设计为主，所以如果你身在OEM中，你只需要着重了解AUTOSAR的方法论和基于方法论的SWC设计即可。这两点说着简单，其实并非我们想象中那么简单。方法论本身就是非常宏观的概念，想要把控产品流程，能为TIER1提供明确需求文档，这本身就要对功能和下游工作十分了解，才能有高质量的输出；

2、TIER1涉及AUTOSAR的工作分工就比较多了。
如果你是系统工程师，着重研究功能算法的实现，那么你需要对SWC的升级了如指掌，深入理解；如果你是软件架构工程师，对于上游OEM提供的需求文档要有宏观概念，所以也要对方法论和SWC审计十分了解；
如果你是基础软件工程师，需要整个团队协同实现：底层驱动工程师要深入学习芯片的抽象层MCAL应用；BSW协议栈工程师要熟悉OS，ComStack，DiagStack，Memory Stack，WgdStack等协议栈应用细节；复杂驱动工程师，要对AUTOSAR针对CDRV的接口定义方式等深入研究；
如果集成工程师，要十分清楚RTE的运行集成和相关应用配置；

3、TIER2要深入研究的内容和TIER1的BSW工程师侧重内容相似，主要围绕芯片MCAL和基础软件协议栈展开。

4、除了以上三类产品开发流程上的角色外，其实还有一个重要角色的存在：工具供应商。了解了AUTOSAR架构和实现过程后，大家可能会看到很多arxml格式的配置文件的制作都离不开工具的支持，以及编译环境、建模工具等，都离不开一直走在超前道路上的工具供应商

• AUTOSAR 方法论之开发流程
  
  AUTOSAR方法论（AUTOSAR Methodology）的开发涉及系统级、ECU级和软件组件级。系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；ECU级根据抽象后的信息对ECU进行配置；系统级和ECU级设计的同时，伴随着软件组件级的开发。上述每个环节都有良好的通信接口，并使用统一的arxml（AUTOSAR Extensible Markup Language）描述文件，以此构建了AUTOSAR方法论。其中各主要步骤如图所示。
  
  系统级设计可进行整车级别的软件架构设计，其基础是软件组件，即功能模块的定义; ECU 级则着重对单片机底层软件进行开发; 而软件组件级是对各软件组件的控制算法进行具体实施。各阶段开发过程之间以规范化的 arxml 描述性文件进行配置信息交互， 从而便于 OEM 与各零部件供应商间的沟通与合作。

  系统级设计可进行整车级别的软件架构设计，其基础是软件组件，即功能模块的定义; ECU 级则着重对单片机底层软件进行开发; 而软件组件级是对各软件组件的控制算法进行具体实施。各阶段开发过程之间以规范化的 arxml 描述性文件进行配置信息交互， 从而便于 OEM 与各零部件供应商间的沟通与合作。
  在开发之前，需要先编写系统配置输入描述文件，其包含以下三部分内容。
  ①软件组件描述（SW-Component Description）：包含系统中所涉及的软件组件的接口信息，例如数据类型、端口接口、端口等。
  ②ECU资源描述（ECU Resource Description-HW only）：包含系统中每个ECU所需要的处理器及其外设、传感器、执行器等信息。
  ③系统约束描述（System Constraint Description）：包含总线信号、软件组件间的拓扑结构和一些映射关系等信息。

• AUTOSAR 系统开发工具分类与介绍
  在不使用相关配置工具的情况下完成符合AUTOSAR 分层架构的汽车嵌入式系统软件开发是非常困难的，并且后期需要进行一系列底层代码的测试与验证。经过多年的发展， 国内外工具供应商已针对 AUTOSAR 方法论中的各阶段开发了相关工具， 总体上按功能大致可以分为以下三类:

( 1) 系统级设计工具 主要完成软件组件框架( 包括端口、端口接口、数据类型、运行实体、触发事件等) 的设计定义及其框架代码生成; 软件组件间通信端口的连接; 硬件拓扑及网络拓扑设计; 导入 DBC、LDF 和 FIBEX 等传统网络描述性文件进行软件组件向 ECU 的映射以及数据至系统信号的映射; 实现待配置 ECU 信息抽取( ECUExtract) 等工作。

( 2) 软件组件级设计工具 主要完成软件组件内部行为( internal behaviour， IB) ， 即控制算法逻辑的设计建模， 以及符合 AUTOSAR 规范的代码与软件组件 arxml 描述性文件的生成工作。

( 3) ECU 级配置工具 主要完成 ECU 配置( 包括 BSW 各需求模块、RTE) 及其代码生成。
此外，还有编译器、单片机调试工具等。

1，使用Matlab/Simulink来实现部分软件组件级的开发，并自动生成应用层软件组件代码及arxml描述文件，其中软件组件arxml描述文件作为AUTOSAR系统级开发的输入文件之一。
2，使用ETAS ISOLAR-A工具来进行AUTOSAR系统的设计与配置，过程中会利用
ISOLAR-A工具设计一些附加的SWC，以及I/O硬件抽象层SWC。系统级开发最后会抽取出待配置ECU的信息，进而可以进入ECU级开发阶段。
3，在ECU级开发阶段，基于ETAS RTA系列工具（RTA-RTE、RTA-BSW、RTA-OS）来实现ECU级的开发，即RTE及除MCAL以外的BSW模块配置和代码生成；使用NXP MCAL配置工具来实现MCAL模块的配置及代码生成。
4，进行代码集成，使用Wind River编译器进行代码编译链接，生成单片机可执行的文
件，并通过Lauterbach调试器将单片机可执行的文件烧写到MPC5744P开发板进行代码调试。