产品
登录后复制
随着汽车ECU控制器的逐步发展，汽车电子领域需求也日益复杂，在这一环境之下，整车厂和 零部件制造商均不得不考
虑软件重复性，可裁剪性，质量保证等等问题，AutoSAR便是基于这些种种要求，由几大零部件提供商和主机厂联合提
出的要求。统一解决方案针对问题。
| 挑战：E/E系统复杂度快速增加 | 目标：重复使用、不断测试 |
| 功能代码爆炸式增长 | 提高软件质量，降低开发成本 |
| 硬件平台种类增多 | 重复使用功能层软件 |
| 开发流程和文件格式未统一 | 重复使用基础层软件 |
| 汽车电子系统设计复杂化造成的可靠性隐患，导致汽车因安全隐患被“召回”的现象频繁发生 | 重复使用开发方法论和开发工具 |
| 规范汽车电子产品，软件和元器件的互通性 |
登录后复制
AutoSAR是AUTomotive Open System Architecture的缩写，是由整车制造商、供应商、服务提供商以及来自汽车电子、半导体和软件
行业的公司共同组成的世界范围内的汽车电子软件联盟。AutoSar是一种软件系统架构，它从汽车ECU控制器角度带来了一整套系统软件解决方案，
它提供了一套标准化的接口和通信协议，使不同的软件组件可以相互协作。AutoSAR软件架构有众多的优越性。下图是汽车有无AutoSAR架构的对
比，“Yesterday”是指在使用AutoSar架构之前的软件系统架构，也就是说，在AutoSAR诞生早期，便已经存在汽车软件系统架构，例如OSEK，
OSEK/VDX也基于分层架构的软件平台。
只是，AutoSAR从整个软件汽车的平台化、统一化着眼，方法论也涵盖了整个ECU统一开发、统一流程的各个开发环节。可以说OSEK就是AutoSAR，比如AutoSAR使用的OS部分就是OSEK操作系统。主要区别在于，OSEK是一个操作系统标准，而AutoSAR是一个软件架构标准，以及由于基于嵌入式系统，OSEK的实现通常比较底层，而AutoSAR是实现通常是比较高层的。在此处我们主要需要清楚AutoSAR通过交互文档可以方便实现OEM与TIL1之间的软件统一设计、开发与交互；而OSEK只能通过 one by one的设计方式去独立开发单控制器，更是无法实现SWC层级的软件复用。种种结构均表明AutoSAR凸显出的不仅仅是一个简单的软件架构所具备的优越性。
2003成立
2005发布第一个AutoSAR标准；
2006年完成基础软件定义；
2013年AutoSAR成立10年，发布4.1.1
2014年发布4.3.0，加入面向服务的通讯协议，包括Extended Buffer Access forRapid Prototyping；SOME/IP Transport Protocal Decentralized Configuration
2017年发布v4.3.1
2018年发布v4.4，是当前最新版本。
登录后复制
本次介绍的重点仍然是AutoSAR软件架构，因为在目前的主机厂环境之中主要使用Autosar架构独立开发自己的控制器，还未涉及从公司层面按照
件开发方式设计软件全功能的模式，毕竟这是一个消耗成本的事情，这个话题就不再阐述。Autosar软件架构作为分层式软件架构，具有其相关的所
有目标和设计优势。在IOS26262中专门有对待软件的要求。
一般而言，软件架构设计要达到如下的目标：
可靠性（Reliable）
软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
安全性（Secure）
软件系统所承担的系统安全性非常重要。
可扩展性（Extensible）
在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。例如，在AUTOsar中有复杂驱动这一层，这样就保证了整个系统的灵活度和可扩展性。
可维护性（Maintainable）
客户体验（Customer Experience）
软件系统必须易于使用。
市场时间（Time to Market）
软件用户要面临同行竞争，软件提供商也要面临同行竞争。以最快的速度争夺市场先机非常重要。例如AutoSAR在当前的市场大环境下被广泛采用在新能源汽车，自动驾驶领域的控制器，控制器开发就足以说明采用AutoSAR架构所带来的商业上的时机在一个新兴领域被大家认可。
下面来看架构图：
AutoSAR架构在软件抽象上分成三层，软件运行在微控制器上自底向上分别是：
其中BSW又被细分成：
BSW从功能角度又做了进一步划分，如服务层被划分成：
这些功能层的划分体现了Autosar作为一个汽车嵌入式软件开发细分市场的专业性，同时这些BSW所提供的服务也占据了大量的Autosar标准的篇幅。这里的层层细分，并不是越细致越好，一个好的架构要保证一定的颗粒度，才能在复杂度和可靠性上有最优的体现。
**运行时环境（RTE）**是AutoSAR ECU体系结构的核心组成部分，应用程序软件组件包含独立于CPU和所处位置的系统软件，这就意味着为了满足系统设计者所作的一些限制，应用程序组件能够在系统配置期间被映射到任何有效的ECU上，RTE负责确保这些组件能够通信，RTE实现了AutoSAR VFB的接口，从而实现了AutoSAR软件组件之间的通信。
微控制器抽象层为软件层独立于μC（microcontroller/微控制器）而存在。它是最低软件层。它包含内部驱动程序，这些驱动程序是可以直接访问μC（microcontroller/微控制器）和内部外围设备的软件模块。
ECU抽象层为使更高的软件层独立于ECU硬件布局而存在。它含有与单片机抽象层的驱动程序接口。 它还包含用于外部设备的驱动程序。它提供了一个用于访问外围设备和设备的API，而无需考虑外围设备和设备的位置（内部/外部μC）及其与μC（microcontroller/微控制器）的连接（端口引脚，接口类型）。
目标： 复杂驱动程序涵盖范围从硬件设计到RTE，提供对复杂的输入类型的传感器和输出类型的控制器的驱动，保证架构的扩展性，例如设备驱动程序等在AutoSAR中未指定的部分，具有很高的时序约束性，这也是AutoSAR可扩展性和可移植性的重要体现。
功能： 为关键的应用提供对资源的直接访问
服务层是基本软件的最高层，这也适用于其与应用程序软件的相关性。系统服务是一组可以由所有层次模块使用的功能，
虽然ECU抽象层覆盖了对I / O信号的访问，但是服务层提供了：
接口层的定义也是AutoSAR标准中重要的一个工作，这些API接口关系到了整个模块可对外提供哪些抽象级服务，直接关系到了该模块的编码工作。
下图可以看出每个模块和其他模块的交互都是通过接口，AutoSAR的不同之处在于增加了RTE层，RTE层的存在就隔离了所有接口，应用层不直接调用BSW层的API，而应用层的SWC之间的交互也要通过RTE层，这样就保证了SWC的独立性，SWC可以不需要关心他们之间的通讯方式，因为有可能今天这个SWC在这个控制器、这个项目中，明天就可能存在在其他控制器内，这样做的好处就是SWC之间是通过CAN通讯还是内部变量交互，SWC完全不需要关心，全部交给RTE去实现即可。
底层模块之间的交互是通过标准化模块接口Standardized Interface实现的，同样针对复杂驱动，其与应用层SWC之间也是通过AutoSAR接口实现的，这里还有一点需要说明的是，不要被图中的双向箭头所误导，这里的箭头更多体现的是接口通过RTE层传递，实际的软件架构中只存在更高层调用与他直接相邻的下一层的调用API的方式，不允许出现跨层调用接口的情况，只有这样才能保证架构的可移植性，层与层之间不存在交叉调用，这样在需要移植时，只需要更改部分层的功能即可。
基本实现方式可分为以下三大块：
在虚拟化集成环节主要是讲整车系统需求转换，抽象成一个一个的SWC软件组件，这里不需要关心SWC之间的通讯方式，可以完全关注功能上的划分，在硬件需求描述环节就要定义出一个一个的ECU控制器单元，并将需要的硬件资源进行描述，为下一环节做准备，最后再进行ECU单控制器的开发功能，可以交付给供应商来具体实现完成ECU硬件控制器设计开发以及ECU底层软件开发以及应用层功能软件的开发集成测试工作。
第一步，完成车辆功能软件组件设计；
第二步，将组件分布至不同的ECU中；
第三步，将每个ECU道出系统描述；
第四步，进行ECU描述，进行ECU详细开发。
关于autoSAR的基础概念还有很多，本期分享就到这里，之后将通过实例来介绍Com stack模块及功能、BSW开发。
然后正式开始通过手写代码介绍AUTOSAR工具链的使用。
免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删
155-2731-8020
