AUTOSAR

AUTOSAR

AUTOSAR定义

AUTOSAR联盟，希望为汽车工业开发一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，也就是我们说的AUTOSAR（AUTomotive Open System ARchitecture）。

需求：

电子系统的复杂性不断增长；软件代码量急速上升；生命周期差别:整车的生命周期往往长于ECU（即电子控制单元，泛指汽车上所有电子控制系统）的生命周期；嵌入式系统不支持硬件抽象；有限的软件模块化；兼容性差，当硬件更换后，软件要推倒重写；（汽车软件开发成本高）

目标：

适用于整个产品生命周期；从软件中把硬件抽象出来，对于不同硬件平台具有更大的灵活性；更多的配置而非实现；标准化AUTOSAR的代码配置/建模工具；通过对BSW的标准化提高了代码质量；竞争力只体现于对OEM（原始设备制造商简称OEM，这种委托他人生产的合作方式简称OEM，承接加工任务的制造商便是OEM）的特殊功能要求的实现；在整个汽车生命周期中，软件可以不断更新或升级；兼容性将覆盖整个网络节点，甚至适用不同OEM。

AUTOSAR结构

应用层：

将软件划分成一个原子软件组件ASWC(Atomic Software component),包括Application Software Component，Sensor Software Component和Actuator Software Component等。不同ASWC之间，以及ASWC与BSW之间都是通过VFB(Virtual Functional Bus)通信。

RTE（运行环境）：

提供基础的通信服务，支持Software Component之间和Software Component到BSW的通信（包括ECU内部的程序调用、ECU外部的总线通信等情况）。RTE使应用层的软件架构完全脱离于具体的单个ECU和BSW。

BSW层:

主要包括任务调度，系统服务，诊断服务、存储服务、通讯协议栈，微控制器抽象层、外部硬件抽象层和复杂驱动。

工作内容

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和基础软件协议栈展开。

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

AutoSAR开发流程：

AUTOSAR开发实施工具：

• AUTOSAR架构开发工具：ETAS-ISOLAR-AB
• AUTOSAR应用层开发工具：MATLAB
• AUTOSAR MCAL：TRESOS STUDIO（Infineon）
• 其他开发或标定工具（IDE,仿真器等）

引用：
https://blog.csdn.net/usstmiracle/article/details/108248570