当前位置:首页 >> 信息与通信 >>

面向OEM的AUTOSAR应用与实施


面向 OEM 的 AUTOSAR 应用与实施

一、 AUTOSAR 背景介绍 AUTOSAR 是英文 AUTomotive Open Systems ARchitecture 的缩写,中文意思是汽车开放系 统架构, 它定义了一套支持分布式的、 功能驱动的汽车电子软件开发方法和电子控制单元上 的软件架构标准化方案,以便应用于不同的汽车平台,提高软件复用,降低开

发成本。 AUTOSAR 是由汽车 OEM 和其一线供应商建立的汽车软件开发全球合作联盟,于 2003 年夏 天正式成立,并于 2004 年启动了主要的工作,其目的就在于控制汽车软件的复杂性和多样 性。AUTOSAR 包括 9 个核心成员:BMW Groups(宝马) 、BOSCH(博世) 、Continental(大 陆) 、DAIMLER(戴姆勒) 、Ford(福特) 、GM(通用) 、PSA Peugeot Citro?n(标志-雪铁龙) 、 TOYOTA(丰田) 、VOLKSWAGEN AG(大众) 。目前其成员已超过 150 个,国内 OEM 中已有一 汽及上汽加入,零部件供应商恒润科技成为继一汽、上汽之后,国内第三家加入该组织的公 司。 AUTOSAR 自面世以来,从半导体工业、工具和软件厂商、零部件供应商到汽车制造商本 身,整个汽车领域内的价值体系都给予该标准积极的推动。 AUTOSAR 开发成员在 2007 年 发布了 2.1 版本,使 AUTOSAR 的发展到达了一个稳定的阶段,随后通过几个不同的开发项 目对 AUTOSAR 的实用性进行了测试,现在 AUTOSAR 已经做好进入到产品 ECU 的准备, 而宝 马集团已将符合 AUTOSAR 标准的 ECU(电子控制单元)应用在全新 BMW 7 系量产车型中, 预计在 2010 年 AUTOSAR 的所有核心成员都将推出相关的产品。 在商业领域里, 支持 AUTOSAR 标准的工具和软件供应商已推出了相应的工具和软件,提供需求管理,系统描述,软件构件 算法模型验证,软件构件算法建模,软件构件代码生成,RTE 生成,ECU 配置以及基础软件 和操作系统等服务, 帮助 OEM 实现无缝的 AUTOSAR 系统软件架构开发流程。 目前 AUTOSAR 版本为 3.1 版,预计将于 2009 年秋季发布 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 软件架构层次图 为了区别软件依赖和硬件依赖,基础软件分为四个层次:服务层(Services Layer) 、ECU 抽象层(ECU Abstraction Layer) 、微控制器抽象层(Microcontroller Abstraction Layer)和 RTE (Runtime Environment) 。除此四层外,在 AUTOSAR 软件架构中还有复杂驱动(Complex Driver) ,由于对复杂传感器和执行器进行操作的模块涉及到严格的时序问题,在 AUTOSAR 中这部分没有被标准化。 ? 服务层提供包括诊断协议、 存储管理、 模式管理和操作系统等在内的系统服务。 ECU 除了操作系统外,服务层的软件模块都是与平台无关的。 ? ECU 抽象层将 ECU 结构 (如外设与 ECU 的联接方式等) 进行了抽象处理。 该层与 ECU 平台相关,但与微控制器无关。 ? 微控制器抽象层包括微控制器相关的驱动(如 I/O 驱动、ADC 驱动等) 。 ? RTE 层负责 AUTOSAR 软件构件(即应用层)相互间的通信以及软件构件与基础软件 之间的通信。RTE 层之下的基础软件对于应用层来说是不可见的,必须通过 RTE 进 入,它将软件构件从对底层软件和硬件平台的依赖中独立出来,实现了应用程序和 基础软件之间的分隔。 2、 AUTOSAR 方法论 AUTOSAR 为符合该标准的汽车电子软件系统开发过程定义了一套通用的技术方法, 这种 方法即被称为 AUTOSAR 方法论 (AUTOSAR Methodology) 汽车 OEM 作为整车系统功能的规 。 划和设计者, 需要了解并掌握 AUTOSAR 提供的这套开发流程, 才能主导和推进符合 AUTOSAR

标准的系统的开发过程。 兼容 AUTOSAR 标准的汽车电子软件系统设计与开发流程如图 2 所示。

图 2 :AUTOSAR 系统设计与开发流程 主要步骤可划分两个阶段: 第一个阶段是系统配置阶段,这属于系统级设计决策工作。首先是编写系统配置输入文 件,为 XML 类型的文件。应用软件的描述术语在 AOTUSAR 中为软件构件(Software Components) 该文件将确定需要使用的软件构件 , (即系统具有哪些功能) 和硬件资源 (ECU) , 以及整个系统的约束条件。AUTOSAR 提供了一系列的模板(软件构件模板,ECU 资源模板和 系统模板)和标准的信息交换格式,工具供应商可据此提供相应的工具支持,从而简化系统 设计的工作, 最终系统设计者只需要使用工具填充或编辑相应的模板即可导出系统配置输入 文件。 系统配置输入包含三部分内容,第一个输入是软件构件描述,定义每个需要的软件构件 的接口内容,包括数据类型,端口,接口等;第二个输入是 ECU 资源描述,定义了每个 ECU 的资源需求,如处理器、外部设备、存储器、传感器和执行器等;第三个输入是系统约束描 述,定义总线信号,拓扑结构和软件构件的映射关系。 系统配置阶段接下来的工作是将初步获得的系统配置输入文件借助系统配置生成器生 成系统配置描述文件,同样为 XML 文件,这是系统配置阶段的最终工作成果。该文件将包 含所有的系统信息,包括将软件构件映射到相关的 ECU 上(这种映射需要考虑到构件的需 要、构件的连接、资源需求以及约束条件,有时也需要考虑成本等方面的因素) ,以及通信 矩阵(整车的网络结构、时序以及网络数据帧的内容) 。 第二个阶段是 ECU 的配置, 这阶段的工作需要对系统中每个 ECU 分别进行。首先是使用 第一个阶段的工作成果——系统配置描述文件, 从中提取出与各个 ECU 相关的系统配置描述 信息,提取的信息包括 ECU 通信矩阵、拓扑结构、顶级功能组合(据此产生需映射到该 ECU 上的所有软件构件) ,将放在另一个 XML 文件中。提取信息的工作可借助工具完成。然后进 入 ECU 配置的实际工作中,这一步负责往输入对象中添加具体应用所必需的信息,如任务 调度、必要的 BSW 模块、BSW 配置信息、给任务分配的可运行实体等。这一步的结果被放 在 ECU 配置描述文件中,它包含了具体 ECU 所需的所有信息。最后一步是生成具体 ECU 的 可执行程序,此步将根据 ECU 配置描述文件中的配置信息构建完成 ECU 的基础软件的设置 和与基于 AUTOSAR 构件的应用软件的集成,最终生成 ECU 的可执行代码。 此外, 要说明的是, AUTOSAR 系统的设计过程使用了虚拟功能总线 (Virtual Functional Bus)

的概念。虚拟功能总线(Virtual Functional Bus)将 AUTOSAR 软件构件相互间的通信以及软 件构件与基础软件之间的通信进行了抽象, 同时使用预先定义的标准接口。 而对于虚拟功能 总线来说,ECU 内部通信和外部总线通信并没有什么区别,这种区别要等到系统布局以及 ECU 的具体功能最终确定才会体现出来。软件构件本身对于这种区别并不关注,因此我们可 以在独立的情况下开发软件构件。在系统实现过程中,虚拟功能总线所代表的功能最终以 RTE 的生成来体现。 3、标准化的应用接口 通过 RTE 实现 AUTOSAR 软件构件 (即应用程序) 相互间的通信以及软件构件与基础软件 之间的通信的前提是,软件构件必须具有标准的 AUTOSAR 接口。目前,AUTOSAR 3.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 所示。

图 6:ECU 的配置与可执行程序的生成 综上所述,整个系统设计和开发流程可用图 7 表示,这里要注意的是,该过程可能需要 多次迭代修改,以达到最优。

图 7 :系统设计和开发流程 四、 总结 AUTOSAR 正在成为现实,建立这样一个标准化平台并贯彻标准化,将会缩短新产品的研 发时间和测试时间,从而帮助企业实现快速的市场反应。许多 OEM 都计划在接下来的车型 中采用 AUTOSAR。在市场上不少工具和软件供应商都已推出了符合 AUTOSAR 标准的工具或 软件支撑,可为 AUTOSAR 系统的设计和开发提供完整的无缝的解决方案。 AUTOSAR 是汽车电子软件平台标准化的历程中的一个巨大飞跃, 我们需要学习和理解它。 但是也必须看到, 在整个汽车行内打破传统的软件开发平台需要相当长的一个过程。 我们可 以根据用户的需求和目标,在初期搭建 AUTOSAR 与传统软件的混合平台,这是是一个能够 实现向 AUTOSAR 平滑升级的可行的方法。在这个过程里,重点不是单纯地使用,理解 AUTOSAR 的理念和思想才最重要,因为它对汽车电子软件开发的工作流程和商业模式都将 带来意义深远的变革。


相关文章:
新autosar
AUTOSAR 是由汽车 OEM 和其一线供应商建立的汽车软件开发全球合作联盟, 2003 年...应用软件开发者应该意识到,面向 AUTOSAR 运行时环境(RTE)接口的应用软件设 计的...
AUTOSAR技术概述
汽车 OEM 作为整车系统功能的规划和设计者, 需要了解并掌握 AUTOSAR 提供的这套...应用软件开发者应该意识到,面向 AUTOSAR 运行时环境(RTE)接口的应用 软件设计的...
AUTOSAR解决方案
AUTOSAR 这一开放的系统架构标准是由全 世界的汽车 OEM,零部件供应商以及软件、...用户可以利用 DaVinci Developer 的图形用户界面开发应用程序(SWC)以及定义应用程序...
AUTOSAR技术分析报告
AUTOSAR技术分析报告_计算机软件及应用_IT/计算机_专业资料。AUTOSAR 技术分析报告...接口标准化 减少/避免 OEM 供应商之间的 接口。 通过使用通用接口目录,使...
现代汽车电子技术结课论文
现代汽车电子技术课程论文 浅谈 AUTOSAR 及其应用发展 姓学班学 名: 院: 级:...在 AUTOSAR 标准的实施过程中,OEM 将起主导作用。 OEM 应如何提出需求并在他们...
AUTUSAR
AUTOSAR 是由汽车 OEM 其一线供应商建立的汽车软件开发全球合作联盟 ,于 2003...与开发应用现状基于“在标准上合作、在实施上竞争冶这一宗旨 , AUTOSAR 开发...
汽车电子论文(大作业)
将逐渐为功能驱动的、面向架构集 成的开发模式所...(1)基础系统功能作为 OEM 的“标准核”方 案实施...采用 AUTOSAR 标准的汽车电子产品 的应用越来越广,...
更多相关标签:
面向实施的城市设计 | 面向服务架构与应用 | 面向应用 | 计算机面向应用的语言 | js面向对象的应用 | 面向web应用程序设计 | 面向外部客户移动应用 | oem应用程序配置文件 |