基于AUTOSAR的汽车电子控制系统嵌入式软件开发

目前， 汽车生产厂商面临着整车功能越来越多、 整车电子控制系统架构越来越复杂的挑战， 由于汽 车电子领域硬件平台的多样性， ECU软件开发严重 依赖硬件和系统配置， 每次相关约束条件的更改都 将导致重新编写软件或对软件进行大量修改。如果 没有开发模式的革新和统一的标准来规范各个ECU 的开发， 整车开发成本和周期就会受到很大的影 响。针对ECU内部软件的开发， 目前有一种较受推 崇的方式， 就是采用统一的开放式嵌入式软件架 构， 并为软件架构中的软件模块定义统一的标准。AUTOSAR是目前国际流行的标准软件架构， 独立 于具体物理硬件的AUTOSAR标准软件模块， 可以 应用到各种不同的汽车电子产品中。 

开发符合AUTOSAR标准的汽车电子控制系统 的通用标准软件模块， 来规范不同ECU供应商的内 部软件及其接口， 可以简化各个ECU开发流程， 并 使得ECU软件具有复用性， 实现软件和硬件通用功 能模块的标准化， 增强设计层面之间的沟通交流， 缩短开发周期， 提高安全性和可靠性， 降低整车成 本， 提高经济效益。例如：汽车目前使用的ECU一 般有20个左右， 如果要求零部件供应商使用我们开 发的通用标准软件模块为我们开发产品， 零部件供 应商就可以节省软件开发费用或者向我们支付软件 使用费用 （费用一般在20万元人民币左右）， 那么 一个车型仅在ECU开发中就会减少400万元左右人 民币的成本。 

1 AUTOSAR简介

1.1 什么是AUTOSAR 

AUTOSAR（AUTomotive Open System ARchitecture）是由全球的主要汽车生产厂商、 零部件供应商、 软硬件和电子工业等企业 （如BMW、 BOSCH、 Continental、 DAIMLER、 Ford、 OPEL、 PSA、 TOYOTA、 VW等）共同制定的汽车开放式系统架构标准。其 主要目的是建立标准的ECU开放式嵌入式软件架构， 并为ECU软件架构中的软件模块定义统一的标准接口。其主要研究内容是AUTOSAR的思想和方法学， AUTOSAR的软件架构和接口， AUTOSAR相关开发和集成工具以及应用AUTOSAR标准而产生的新的软件开发流程。 

AUTOSAR在定义软件架构和接口的同时，也定义了易于交换的硬件平台标准。AUTOSAR标准 不仅提供了基础软件模块的规范，还提供了用于开 发分布式系统应用软件的方法，这种方法以基于模型的软件和分布式系统描述开始，以自动代码生成 和可重复的测试结束。

目前，国内一汽、上汽已经申请加入了AUTOSAR 组织成为注册会员，并且都在研发符合AUTOSAR 的软件模块。欧洲很多汽车生产厂商和零部件供应商（如BMW、 BOSCH等）已经开始应用AUTOSAR 标准软件模块于汽车和零部件。

长城汽车股份有限公司目前已经完成AUTOSAR concept、AUTOSAR methodology、AUTOSAR tool - chain、AUTOSAR development process的研究 ， 完成操作系统的调研和选型、ECU的技术要求和硬件选型。下一阶段是研发COM、CAN、LIN、DIAG标准软件模块，研发与测试完成后可以用于新车型总线ECU的标准通信与诊断软件。最后是完成AUTOSAR其他标准软件模块的研发，研发与测试完成后可以用于新车型ECU的通用标准基础软件。 

1.2 AUTOSAR体系结构

为了实现AUTOSAR的目标，汽车ECU架构被抽 象成几个层，如图1所示。

图1 AUTOSAR体系结构

1.2.1 微控制器抽象层

第1层是微控制器抽象层（Microcontroller Abstraction Layer）。这一层主要是实现软件与实际微控制器之间的连接，用于映射微控制器的功能和外围接口，定义了内存接口、I ／O驱动接口和通信 连接接口，同时还可以模拟一些微控制器无法提供 的功能。

1.2.2 ECU抽象层 

第2层是ECU抽象层（ECU Abstraction Layer）。这一层在ECU相关硬件的基础上， 为ECU提供外围 设备的驱动程序。

1.2.3 服务层

第3层是服务层 （Services Layer）。这一层提供 了各种服务， 例如网络服务、 内存管理、 网络通信 和操作系统。服务层在很大程度上独立于硬件系统。

1.2.4 运行时环境 

第4层是运行时环境（RTE）。这一层真正实现 了应用软件和基础软件之间的分隔。RTE负责处理应用软件集成以及应用软件与基础软件模块之间的 数据交换。RTE的存在是真正实现应用软件重用的 基础。由于RTE预定义了相关的接口， 所以开发人 员可以在对硬件一无所知的情况下进行应用软件的 开发， 并将这个软件应用在任何符合AUTOSAR标准的ECU中。

2 基于AUTOSAR的嵌入式软件开发流程

AUTOSAR在定义ECU软件架构的同时， 也定义 了开发AUTOSAR软件模块的方法。符合经过确认 的开发过程是开发软件的一个重要前提， 需求列表 中的不足会在开发早期被发现， 同时软件模块的重 用使得开发流程变得简化， 整个系统也就更加可 靠。但 是， 这种方法也允许一定程度的自由， 例 如：用户可以自己决定是使用从上至下还是从下至上的开发流程。

整个开发流程是以形式化描述为起点，包含对于软件架构、硬件资源和系统约束的描述，同时，系统配置作为ECU配置的基础，用户可以利用配置工具根据ECU配置生成基础软件。开发过程中的所有设计和配置数据都用统一的文件格式保存。为此，AUTOSAR定义了一种基于XML的文件格式，一方面， 统一的文件格式保证了开发流程的 通用性；另一方面，它简化了开发工具之间的无缝集成。具体的基于AUTOSAR的嵌入式软件开发流程 如图2所示。

图2 基于AUTOSAR的嵌入式软件开发流程

2.1 输入描述 

第1阶段是输入描述（Input Description），具体分为以下3个部分。

1a）软件架构描述 主要是描述独立于硬件的软件架构，如：通用特性、通信属性、内部架构、需求的硬件资源等。通过开发工具生成标准的软件架构描述文档。 

1b）硬件资源描述 主要是描述独立于应用软件的硬件资源，如：通用特性、 工作温度、信号路径、可用的硬件资源等。通过开发工具生成标准的硬件资源描述文档。 

1c）系统描述 主要是描述整车需求与输入信息， 如：网络拓扑、电源系统、 消息矩阵、软硬件映射等。通过开发工具生成标准的系统描述文档。 

2.2 系统配置 

第2阶段是系统配置（System Configuration）。通过开发工具配置第1阶段生成的标准文档，即：软件架构描述文档、硬件资源描述文档、系统描述文档，这是个需要反复配置的过程，最终生成标准的ECU描述文档和系统配置文档。 

2.3 ECU配置 

第3阶段是ECU配置（ECU Configuration）。通过配置工具配置第2阶段生成的标准文档 ，即：ECU描述文档、系统配置文档，以及RTE相关配置 资源， 进而生成标准的ECU配置文档。 

2.4 ECU软件生成 

第4阶段是ECU软件生成（ECU SW Generation）。将标准的ECU配置文档 、ECU的应用软件、AUTOSAR资源库通过配置工具生成标准的ECU软件。如果上述文档发生变更，则需要重新配置进而生成更新的标准ECU软件。然后将生成的标准ECU软件下载到ECU硬件中，测试软件的运行情况。如果与硬件资源有冲突或者更新了硬件资源，则需要反复地校正和优化ECU软件。

3 符合AUTOSAR嵌入式代码的开发成果

我们需要开发相应的开发工具和配置工具，因为合适的工具可以用于需求的结构化实现和相应的管理，同时能建立相应的配置。开发工具用于设计AUTOSAR软件模块，用来配置并生成RTE。配置工具用于配置不同的AUTOSAR软件模块，从而加快 ECU的开发过程。通过应用AUTOSAR标准，我们可以开发出一系列软件模块，如图3所示。

图3 符合AUTOSAR的软件模块

3.1 RTE

RTE（Runtime Environment）是一个标准的运行时环境。符合AUTOSAR标准的软件模块可以通 过RTE实现无缝集成。其功能包含：发送端与接收 端之间的通信（外部／内部），客户端与服务器之间的通信（内部），显性和隐性数据访问，接收数据队列， 超时处理， 支持简单或复杂数据类型， 通过定时器、接收数据或数据发送完成等事件激活运行实体，支持所有类型的运行实体等。

3.2 OS

OS（Operation System）是OSEK OS的扩展，是一种抢占式实时多任务操作系统，包括时间监控、内存监控和支持网络分布式应用。其功能包含：调度表，定时保护，全局系统时间同步，测量，内存保护等。

3.3 SYS 

SYS（System）是一个由ECU状态管理器、循环冗余校验程序、看门狗管理器和看门狗接口组成的基础软件。SYS保证了系统的成功启动和持续运行 。其功能包含：CRC（循环冗余校验程序 ），ECUM（ECU状态管理器）， SCHM（基础软件调度器）等。

3.4 MEM 

MEM（Memory）负责处理数据抽象，包括数据管理，检查并重新产生应用数据，访问Flash和EEPROM。MEM将用户数据封装成能够被写入非易失性内存的数据块，这些数据块可以根据它们的重要性采用不同的方法进行保护，其中包含冗余数据存储。其功能包含：NVM（非易失性管理器 ） ， MEMIF（内存抽象接口），FEE（Flash EEPROM仿真），EA（EEPROM抽象）等。

3.5 DIAG 

DIAG（Diagnosis）符合ISO 14229 -1（UDS） 诊断标准。其功能包含：DCM（诊断通信管理器），DEM （诊断时间管理器），FIM（功能禁止管 理器）等。

3.6 COM 

COM（Communication）为应用软件提供基于信号的服务。为了集成完整的通信协议栈，COM需要和CAN（LIN ／ FlexRay）联合使用 。其 功 能 包 含 ：COM（通信），PDUR（协议数据单元路由器），NMIF（网络管理接口） 等。

3.7 CAN

CAN（Controller Area Network）可以实现基于CAN总线的AUTOSAR通信。其功能包含：CANIF（CAN总线接口），CANNM（CAN总线网络管 理），CANTP（CAN总线传输层）等。

3.8 LIN 

LIN（Local Interconnect Network）总线是一种低成本、低速率串行通信总线。LIN可以加快用户 的LIN总线开发流程。其功能包含：LINIF（LIN总线接口），LINTP（LIN总线传输层）等。

3.9 FR 

FlexRay总线是一种可扩展的、灵活的、确定性的高速通信总线， 能够满足汽车日益增长的安全相 关需求。FR可以更好地支持用户开发FlexRay总线。其功能包含：FRIF（FlexRay总线接口），FRNM（FlexRay总线网络管理），FRTP（FlexRay总线传输层）等。

3.10 MCAL 

MCAL （ Microcontroller Abstraction Layer）包含微控制器的各种底层驱动，从而实现和其它外围设备之间的信号通信。其功能包含：ADCDRV （ADC驱动），CANDRV（CAN驱动），DIODRV（数字输入／输出驱动） ， EEPDRV（EEPROM驱动），FLSDRV（Flash驱动），FRDRV（ FlexRay驱动 ） ， GPTDRV （通用定时器驱动），ICUDRV（输入捕捉单元驱动），LINDRV（LIN驱动），MCUDRV（MCU驱动），PORTDRV（端口驱动），PWMDRV（PWM驱动），SPIDRV（串行外围设备接口驱动）， WDGDRV（看门狗驱动）等。

4 结束语

目前，国外许多的汽车生产厂商和零部件供应商都在研究 AUTOSAR标准 ，并准备开发符合AUTOSAR标准的软件模块，而我们对此项技术还一无所知，没有足够的重视。如果我们不及时介入研发， 这项高新技术势必会被国外主机厂和供应商再次垄断， 如果我们开发完成这些软件模块， 小则 可以作为我们汽车公司的标准，大也可以作为中国 汽车的行业标准，来规范汽车ECU软件的开发，这样将十分有利于提高我国汽车品牌和零部件供应商的竞争力和影响力。 

参考文献：

［1］AUTOSAR Rel. 3.1，2008［S］.www.autosar.org，2008.

文章转载自公众号：智能汽车开发者平台