面向OEM的AUTOSAR应用与实施

面对OEM的AUTOSAR应用与实施一、AUTOSAR背景介绍AUTOSAR是英文AUTomotiveOpenSystemsARchitecture的缩写，中文意思是汽车开放系统架构，它定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子把握单元上的软件架构标准化方案，以便应用于不同的汽车平台，提高软件复用，降低开发成本。AUTOSAR是由汽车OEM和其一线供应商建立的汽车软件开发全球合作联盟，于2003年夏天正式成立，并于2004年启动了主要的工作，其目的就在于把握汽车软件的简洁性和多样性。AUTOSAR包括9个核心成员：BMWGroups（宝马）、BOSCH（博世）、Continental（大陆）、DAIMLER（戴姆勒）Ford（福特）GM（通用）、PSAPeugeotCitroen（标志-雪铁龙）TOYOTA（丰田）VOLKSWAGENAG（大众）。目前其成员已超过150个，国内OEM中已有一汽及上汽加入，零部件供应商恒润科技成为继一汽、上汽之后，国内第三家加入该组织的公司。AUTOSAR自面世以来，从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本身，整个汽车领域内的价值体系都赐予该标准乐观的推动。AUTOSAR开发成员在2007年发布了2.1版本，使AUTOSAR的进展到达了一个稳定的阶段，随后通过几个不同的开发项目对AUTOSAR的有用性进行了测试，现在AUTOSAR已经做好进入到产品ECU的预备，而宝马集团已将符合AUTOSAR标准的ECU（电子把握单元）应用在全新BMW7系量产车型中，估量在2022年AUTOSAR的全部核心成员都将推出相关的产品。在商业领域里，支持AUTOSAR标准的工具和软件供应商已推出了相应的工具和软件，供应需求管理，系统描述，软件构件算法模型验证，软件构件算法建模，软件构件代码生成，RTE生成，ECU配置以及基础软件和操作系统等服务，关怀OEM实现无缝的AUTOSAR系统软件架构开发流程。目前AUTOSAR版本为3.1版，估量将于2022年秋季发布4.0版本。由于AUTOSAR提倡在标准上合作，在实现上竞争”的原则，其核心思想在于统一标准、分散实现、集中配置，所以接受AUTOSAR将为OEM带来很大的好处，这将使得他们对于软件选购和把握拥有更灵敏和更大的权利，由于软件系统的标准化和开放化将使更多的软件供应商进入汽车电子行业，从而使得他们有更多的选择，同时软件的质量监督也会相应提高，有利于提高他们的产品质量。但是，也必需看到在全行业内推行此标准还是存在潜在障碍的，就是来自一些OEM厂商和大的第一级汽车供应商的抵制，由于他们已经有自己的标准和架构了，而接受AUTOSAR标准及其架构可能产生更换成本、丢失把握等风险。尽管如此，汽车电子软件开发方法和软件架构的标准化是汽车行业不行阻挡的进展趋势，而且目前还没有哪种标准比AUTOSAR标准走的更远。鉴于此，国内汽车OEM必需做好应对AUTOSAR的准备，这对他们来说，是挑战更是机遇。在AUTOSAR标准的实施过程中，OEM将起主导作用。OEM应如何提出需求并在他们的产品上使用这些来自不同供应商的具有标准功能和接口的软件呢？AUTOSAR为此同时制定了方法上、流程上的标准，即AUTOSAR方法论。本文将着重解读AUTOSAR方法论内容，讲解OEM应如何将该标准应用在他们的产品研发及生产过程中。二、AUTOSAR技术概述AUTOSAR的方案目标主要有3项，第一是建立独立于硬件的分层的软件架构；其次是为实施应用供应方法论，包括制定无缝的软件架构堆叠流程并将应用软件整合至ECU中；第三是制定各种车辆应用接口法律法律规范，作为应用软件整合标准，以便软件构件在不同的汽车平台上的复用。1、AUTOSAR软件架构为了实现AUTOSAR的目标，即实现应用程序和基础模块之间的分别，汽车电子软件架构被抽象成几个层，如图1所示。图1：AUTOSAR软件架构层次图为了区分软件依靠和硬件依靠，基础软件分为四个层次：服务层(ServicesLayer)、ECU抽象层(ECUAbstractionLayer)、微把握器抽象层(MicrocontrollerAbstractionLayer)和RTE(RuntimeEnvironment)0除此四层外，在AUTOSAR软件架构中还有简洁驱动(ComplexDriver)，由于对简洁传感器和执行器进行操作的模块涉及到严格的时序问题，在AUTOSAR中这部分没有被标准化。服务层供应包括诊断合同、存储管理、ECU模式管理和操作系统等在内的系统服务。除了操作系统外，服务层的软件模块都是与平台无关的。 ECU抽象层将ECU结构(如外设与ECU的联接方式等)进行了抽象处理。该层与ECU平台相关，但与微把握器无关。 微把握器抽象层包括微把握器相关的驱动(如I/O驱动、ADC驱动等)。 RTE层负责AUTOSAR软件构件(即应用层)相互间的通信以及软件构件与基础软件之间的通信。RTE层之下的基础软件对于应用层来说是不行见的，必需通过RTE进入，它将软件构件从对底层软件和硬件平台的依靠中独立出来，实现了应用程序和基础软件之间的分隔。2、AUTOSAR方法论AUTOSAR为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法，这种方法即被称为AUTOSAR方法论(AUTOSARMethodology)。汽车OEM作为整车系统功能的规划和设计者，需要了解并把握AUTOSAR供应的这套开发流程，才能主导和推动符合AUTOSAR标准的系统的开发过程。兼容AUTOSAR标准的汽车电子软件系统设计与开发流程如图2所示。图2:AUTOSAR系统设计与开发流程主要步骤可划分两个阶段：第一个阶段是系统配置阶段，这属于系统级设计决策工作。首先是编写系统配置输入文件，为XML类型的文件。应用软件的描述术语在AOTUSAR中为软件构件（SoftwareComponents），该文件将确定需要使用的软件构件（即系统具有哪些功能）和硬件资源（ECU），以及整个系统的约束条件。AUTOSAR供应了一系列的模板（软件构件模板，ECU资源模板和系统模板）和标准的信息交换格式，工具供应商可据此供应相应的工具支持，从而简化系统设计的工作，最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入文件。系统配置输入包含三部分内容，第一个输入是软件构件描述，定义每个需要的软件构件的接口内容，包括数据类型，端口，接口等；其次个输入是ECU资源描述，定义了每个ECU的资源需求，如处理器、外部设施、存储器、传感器和执行器等；第三个输入是系统约束描述，定义总线信号，拓扑结构和软件构件的映射关系。系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生成系统配置描述文件，同样为XML文件，这是系统配置阶段的最终工作成果。该文件将包含全部的系统信息，包括将软件构件映射到相关的ECU上（这种映射需要考虑到构件的需要、构件的连接、资源需求以及约束条件，有时也需要考虑成本等方面的因素），以及通信矩阵（整车的网络结构、时序以及网络数据帧的内容）。其次个阶段是ECU的配置，这阶段的工作需要对系统中每个ECU分别进行。首先是使用第一个阶段的工作成果一一统配置描述文件，从中提取出与各个ECU相关的系统配置描述信息，提取的信息包括ECU通信矩阵、拓扑结构、顶级功能组合（据此产生需映射到该ECU上的全部软件构件），将放在另一个XML文件中。提取信息的工作可借助工具完成。然后进入ECU配置的实际工作中，这一步负责往输入对象中添加具体应用所必需的信息，如任务调度、必要的BSW模块、BSW配置信息、给任务支配的可运行实体等。这一步的结果被放在ECU配置描述文件中，它包含了具体ECU所需的全部信息。最终一步是生成具体ECU的可执行程序，此步将依据ECU配置描述文件中的配置信息构建完成ECU的基础软件的设置和与基于AUTOSAR构件的应用软件的集成，最终生成ECU的可执行代码。此外，要说明的是,AUTOSAR系统的设计过程使用了虚拟功能总线（VirtualFunctionalBus）的概念。虚拟功能总线(VirtualFunctionalBus)将AUTOSAR软件构件相互间的通信以及软件构件与基础软件之间的通信进行了抽象，同时使用预先定义的标准接口。而对于虚拟功能总线来说，ECU内部通信和外部总线通信并没有什么区分，这种区分要等到系统布局以及ECU的具体功能最终确定才会体现出来。软件构件本身对于这种区分并不关注，因此我们可以在独立的状况下开发软件构件。在系统实现过程中，虚拟功能总线所代表的功能最终以RTE的生成来体现。3、标准化的应用接口通过RTE实现AUTOSAR软件构件(即应用程序)相互间的通信以及软件构件与基础软件之间的通信的前提是，软件构件必需具有标准的AUTOSAR接口。目前，AUTOSAR3.1版已定义了一些典型的汽车电子应用领域(动力，车身/舒适和底盘)的标准接口。AUTOSAR依据功能规律分别将这些领域的系统划分成若干个模块，这些模块可被视为一个软件构件或多个软件构件的组合，这些功能性的软件构件的接口被明确定义，所定义的接口的内容包括名称，含义，范围，数据类型，通信类型，单位等。应用软件开发者在软件构件的设计与开发时需要应用这些接口定义。这里以车身/舒适系统的雨刷管理的软件构件的接口定义为示例，如图3：图3：软件构件的接口定义说明：雨刷管理构件(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系统开发时使用。图4：系统配置输入内容以上描述文件的生成均有特地的工具（这类工具统称为AUTOSAR描述文件编辑器）支持,用户只需向工具中填充规定的内容即可。九软件构件描述文件的生成，需要猎取每个软件构件的关于接口，行为，直接的硬件接口（I/O）,运行性能需求（内存，功耗，定时等）等方面的信息；而软件构件描述文件本身将包含4部分内容： 一般特性：名称，生产商等通信属性：端口，接口 内部结构：子构件，连接关系 需要的硬件资源：处理时间，调度，内存大小和类型等。ECU资源描述文件生成之前，需要猎取每个ECU的关于传感器和执行器，硬件接口，硬件属性（内存，处理器，功耗），连接和带宽等方面的信息；而ECU描述文件本身将包含7部分内容：九 一般特性：名称，生产商等 温度（自身，环境，冷却/加热） 可用的信号处理方法 可用的编程力气可用的硬件：微把握器，架构（如多处理器）；内存，接口（CAN，LIN,MOST，FlexRay）,外设（传感器/执行器），连接（如引脚数目）。 RTE之下针对微把握器的基础软件模块从引脚到ECU抽象层的信号系统约束描述文件生成之前，需要关于整个系统的信息，如总线系统，合同，通信矩阵和属性，功能集群，功能部署（向ECU的分布）；而系统约束描述文件本身将包含3部分内容： 网络拓扑：总线（CAN,LIN,FlexRay）,连接的ECU,网关，电源供应 通信（针对每个通道）：通信矩阵，网关表 软件构件的映射以上所描述的系统配置输入内容收集完整后，使用系统配置工具导出系统配置文件，这一步准备哪个软件构件运行在哪块ECU上，它生成ECU配置描述；此外还生成该系统内的通信矩阵。如图5所示。图5：系统配置结果以上工作完成后，接下来进入ECU配置阶段。将每个ECU的配置信息从系统配置文件中提取出来，其内容包括ECU通信矩阵、拓扑结构、顶级功能组合（即需映射到该ECU上的全部软件构件的组合）。此外，还需要更具体的关于AUTOSAR的基础软件各主要部分的配置，如RTE的配置，OS的配置，MCAL（微把握器抽象层）的配置和通信合同栈配置等。这些软件部件的配置目前均有相应的工具支持，直接生成可编译的头文件以供ECU系统软件的集成使用。在生成ECU可执行程序之前，需获得相关软件构件和基础软件的代码，然后与上述基础软件的配置头文件进行连编，最终生成ECU的可执行程序。如图6所示。HardwareEjCIHcDrillown(Kirvq4i临jnrrasA%摩卒fl*呵剁fifM-CALRWy那th?SWCQiporwnUAyrrOMiR-RTG圖ChipmantiECMVBamluayscHnTtmcdoris-runmcn#tfnvttt图6：ECU的配置与可执行程序的生成综上所述，整个系统设计和开发流程可用图7表示，这里要留意的是，该过程可能需要多次迭代修改，以达到最优。swcamponenalaSWI席电触hECUInput：RflquinemnteVehlcfeIrtfo*SftVKKutalli-D3foreachECUCTCsnUgureoachGU-ECURadUMdISsvip杯n_-*ktratioscoffBiartsandlJorootmijflCons:lifncciui忙曲iSystemOEcrlptionCcinflgur?占y手佃rn&s吐rat目axtrsclotECUdwcrlpliant1-a,SWCompcnont&e?npthn图7：系统设计和开发流程四、总结AUTOSAR正在成为现实，建立这样一个标准化平台并贯彻标准化，将会缩短新产品的研发时间和测试时间，从而关怀企业实现快速的市场反应。许多OEM都方案在接下来的车型中接受AUTOSARo在市场上不少工具和软件供应商都已推出了符合AUTOSAR标准的工具或软件支撑，可为AUTOSAR系统的设计和开发供应完整的无缝的解决方案。AUTOSAR是汽车电子软件平台标准化的历程中的一个巨大飞跃，我们需要学习和理解它。但是也必需看到，在整个汽车行内打破传统的软件开发平台需要相当长的一个过程。我们可以依据用户的需求和目标，在初期搭建AUTOSAR与传统软件的混合平台，这是是一个能够实现向AUTOSAR平滑升级的可行的方法。在这个过程里，重点不是单纯地使用，理解AUTOSAR的理念和思想才最重要，由于它对汽车电子软件开发的工作流程和商业模式都将带来意义深远的变革。