AUTOSAR简介

GoalClearlyunderstandrequirementandfocusonimplementation.StatusPlanQ1学习了解AUTOSAR完成Q2深入理解AUTOSAR，了解AUTOSAR如何应用，有哪些工具正在进行Q3尝试使用AUTOSAR，做一个简单的实例。未开始Q4尝试将AUTOSAR应用到E-bus项目中。未开始研究内容标题AUTOSAR1.AUTOSAR背景介绍2.AUTOSAR技术概述3.AUTOSAR设计应用实例4.总结AUTOSAR背景介绍1.AUTOSAR是什么？AUTOSAR是英文AUTomotiveOpenSystemsARchitecture的缩写，中文意思是汽车开放系统架构，它定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，以便应用于不同的汽车平台，提高软件复用，降低开发成本。2.AUTOSAR标准建立背景􀂉电子系统的复杂性不断增长􀂉软件代码量急速上升􀂉生命周期差别:整车的生命周期往往长于ECU的生命周期􀂉嵌入式系统不支持硬件抽象􀂉有限的软件模块化􀂉重用性差:当硬件（处理器型号）更换后，软件往往要推倒重写􀂉五花八门的硬件平台AUTOSAR背景介绍3.AUTOSAR合作伙伴AUTOSAR背景介绍4.AUTOSAR的计划目标􀂉建立独立于硬件的分层的软件架构；􀂉为实施应用提供方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU中；􀂉制定各种车辆应用接口规范，作为应用软件整合标准，以便软件构件在不同的汽车平台上的复用􀂉在标准上合作，在实现上竞争􀂉统一标准、分散实现、集中配置AUTOSAR背景介绍5.AUTOSAR现状AUTOSAR自面世以来，从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本身，整个汽车领域内的价值体系都给予该标准积极的推动。AUTOSAR开发成员在2007年发布了2.1版本，使AUTOSAR的发展到达了一个稳定的阶段，随后通过几个不同的开发项目对AUTOSAR的实用性进行了测试，现在AUTOSAR已经做好进入到产品ECU的准备，而宝马集团已将符合AUTOSAR标准的ECU（电子控制单元）应用在全新BMW7系量产车型中，预计在2010年AUTOSAR的所有核心成员都将推出相关的产品。在商业领域里，支持AUTOSAR标准的工具和软件供应商已推出了相应的工具和软件，提供需求管理，系统描述，软件构件算法模型验证，软件构件算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，帮助OEM实现无缝的AUTOSAR系统软件架构开发流程。目前AUTOSAR版本为4.1版。AUTOSAR技术概述1、AUTOSAR软件架构2、AUTOSAR方法论3、标准化的应用接口AUTOSAR软件架构AUTOSAR软件架构AUTOSAR软件架构为了区别软件依赖和硬件依赖，基础软件分为四个层次：服务层（ServicesLayer）、ECU抽象层（ECUAbstractionLayer）、微控制器抽象层（MicrocontrollerAbstractionLayer）和RTE（RuntimeEnvironment）。除此四层外，在AUTOSAR软件架构中还有复杂驱动（ComplexDriver），由于对复杂传感器和执行器进行操作的模块涉及到严格的时序问题，在AUTOSAR中这部分没有被标准化。*服务层提供包括诊断协议、存储管理、ECU模式管理和操作系统等在内的系统服务。除了操作系统外，服务层的软件模块都是与平台无关的。*ECU抽象层将ECU结构（如外设与ECU的联接方式等）进行了抽象处理。该层与ECU平台相关，但与微控制器无关。*微控制器抽象层包括微控制器相关的驱动（如I/O驱动、ADC驱动等）。*RTE层负责AUTOSAR软件构件（即应用层）相互间的通信以及软件构件与基础软件之间的通信。RTE层之下的基础软件对于应用层来说是不可见的，必须通过RTE进入，它将软件构件从对底层软件和硬件平台的依赖中独立出来，实现了应用程序和基础软件之间的分隔。AUTOSAR方法论AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法，这种方法即被称为AUTOSAR方法论（AUTOSARMethodology）。汽车OEM作为整车系统功能的规划和设计者，需要了解并掌握AUTOSAR提供的这套开发流程，才能主导和推进符合AUTOSAR标准的系统的开发过程。AUTOSAR方法论主要步骤可划分两个阶段：第一个阶段是系统配置阶段，这属于系统级设计决策工作。首先是编写系统配置输入文件，为XML类型的文件。应用软件的描述术语在AOTUSAR中为软件构件（SoftwareComponents），该文件将确定需要使用的软件构件（即系统具有哪些功能）和硬件资源（ECU），以及整个系统的约束条件。AUTOSAR提供了一系列的模板（软件构件模板，ECU资源模板和系统模板）和标准的信息交换格式，工具供应商可据此提供相应的工具支持，从而简化系统设计的工作，最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。AUTOSAR方法论系统配置输入包含三部分内容，第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型，端口，接口等；第二个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设备、存储器、传感器和执行器等；第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。该文件将包含所有的系统信息，包括将软件构件映射到相关的ECU上（这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件，有时也需要考虑成本等方面的因素），以及通信矩阵（整车的网络结构、时序以及网络数据帧的内容）。AUTOSAR方法论第二个阶段是ECU的配置，这阶段的工作需要对系统中每个ECU分别进行。首先是使用第一个阶段的工作成果——系统配置描述文件，从中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合（据此产生需映射到该ECU上的所有软件构件），将放在另一个XML文件中。提取信息的工作可借助工具完成。然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务分配的可运行实体等。这一步的结果被放在ECU配置描述文件中，它包含了具体ECU所需的所有信息。最后一步是生成具体ECU的可执行程序，此步将根据ECU配置描述文件中的配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。AUTOSAR方法论此外，要说明的是，AUTOSAR系统的设计过程使用了虚拟功能总线（VirtualFunctionalBus）的概念。虚拟功能总线（VirtualFunctionalBus）将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象，同时使用预先定义的标准接口。而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区别，这种区别要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件构件本身对于这种区别并不关注，因此我们可以在独立的情况下开发软件构件。在系统实现过程中，虚拟功能总线所代表的功能最终以RTE的生成来体现。标准化的应用接口通过RTE实现AUTOSAR软件构件（即应用程序）相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必须具有标准的AUTOSAR接口。目前，AUTOSAR3.1版已定义了一些典型的汽车电子应用领域（动力，车身/舒适和底盘）的标准接口。AUTOSAR按照功能逻辑分别将这些领域的系统划分成若干个模块，这些模块可被视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称，含义，范围，数据类型，通信类型，单位等。应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。标准化的应用接口这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例，如图标准化的应用接口雨刷管理构件（WiperWasherManager）有两个接口，CmdWashing和StaWasher,图中WWManager表示为雨刷管理软件构件的实例。针对CmdWashing接口定义了以下信息：1)CmdWashing接口由WiperWasherManager构件提供，其数据内容为FrontWasher构件的Activation接口所使用。2）CmdWashing包含一个“Command”的数据元素。3）“Command”的数据类型为“t_onoff”。4）“t_onoff”属于“RecordType”，该类型描述一般的开/关信息。应用软件开发者应该意识到，面向AUTOSAR运行时环境（RTE）接口的应用软件设计的重要性，及早地将AUTOSAR应用层接口引入到实际的项目中来，为实现应用软件的可复用性做好准备，从而优化整个软件开发流程。设计应用与实施仍以车身/舒适领域的外部车灯控制系统的设计为例，在本例中只涉及转向灯的闪烁控制功能的实现。在系统配置阶段，第一步是收集系统配置输入内容。首先收集实现该功能所需的软件构件，如图4右部边框所示，在本系统中共使用了5个软件构件，按照AUTOSAR提供的软件构件模板编写每个软件构件的描述文件；然后明确系统中所用到的ECU资源，形成ECU资源描述文件，如图4左上部边框所示，这里有3类ECU；最后是系统约束条件的描述文件，描述系统的网络拓扑关系。一般OEM需要提供软件构件描述和系统约束描述文件，以供零部件供应商在ECU系统开发时使用。设计应用与实施以外部车灯控制系统的设计为例，在本例中只涉及转向灯的闪烁控制功能的实现。系统配置阶段设计应用实例图中描述文件的生成均有专门的工具（这类工具统称为AUTOSAR描述文件编辑器）支持，用户只需向工具中填充规定的内容即可。图中描述的是在系统配置阶段，第一步是收集系统配置输入内容。首先收集实现该功能所需的软件构件，在本系统中共使用了5个软件构件，按照AUTOSAR提供的软件构件模板编写每个软件构件的描述文件；然后明确系统中所用到的ECU资源，形成ECU资源描述文件，这里有3类ECU；最后是系统约束条件的描述文件，描述系统的网络拓扑关系。一般OEM需要提供软件构件描述和系统约束描述文件，以供零部件供应商在ECU系统开发时使用。设计应用实例系统配置阶段完成后，会生成下图所示设计应用实例ECU配置阶段设计应用实例将每个ECU的配置信息从系统配置文件中提取出来，其内容包括ECU通信矩阵、拓扑结构、顶级功能组合（即需映射到该ECU上的所有软件构件的组合）。此外，还需要更具体的关于AUTOSAR的基础软件各主要部分的配置，如RTE的配置，OS的配置，MCAL（微控制器抽象层）的配置和通信协议栈配置等。这些软件部件的配置目前均有相应的工具支持，直接生成可编译的头文件以供ECU系统软件的集成使用。在生成ECU可执行程序之前，需获得相关软件构件和基础软件的代码，然后与上述基础软件的配置头文件进行连编，最后生成ECU的可执行程序。总结AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而帮助企业实现快速的市场反应。许多OEM都计划在接下来的车型中采用AUTOSAR。在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具或软件支撑，可为AUTOSAR系统的设计和开发提供完整的无缝的解决方案。AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃，我们需要学习和理解它。但是也必须看到，在整个汽车行内打破传统的软件开发平台需要相当长的一个过程