基于AUTOSAR 架构的汽车电子软件产品的开发方法

詹克旭

（博世华域转向系统有限公司， 上海 201821）

随着中国汽车电子制造业的不断快速变革和汽车电子信息系统技术的不断创新发展，以及未来人们对汽车舒适性和汽车功能性的要求逐步提高，越来越多的汽车功能需求被集成在汽车上，使得汽车的电气系统架构愈加复杂，这样就可能造成不同功能的电子控制单元之间很可能存在高度耦合。对于汽车软件的整合开发，各大知名汽车专用电子软件厂商都已经有自己的开发标准，因此在开发集成软硬件时，由于软件开发平台之间存在着的差异性很可能会造成可移植性差、不正常兼容等问题。由于软件兼容性问题也会导致汽车软件开发存在潜在的安全风险，同时也会使软件开发成本大幅度增加，基于上述分析，如果依然按照传统的工业软件开发工作流程，已经不能完全满足要求，整车软件系统开发的工作复杂度将大大增加。

汽车开放电子系统软件架构技术标准名为AUTOSAR（Automotive Open System Architecture），由欧洲的全球汽车部件制造商、供应商、半导体和电动工具制造厂商共同联合发起组建，并共同制定了一系列用于汽车开放电子系统软件开发技术规范［1-3］，作为用于汽车软件开发的一个标准化开放式系统架构。为了有效解决目前汽车电子系统软件的可复用及在不同硬件平台上的可移植性，AUTOSAR通过引入各种模块化的软件开发方法，能够有效满足日益复杂的汽车电子系统软件开发的技术需求，以达到不断降低软件产品成本和不断提高软件产品品质的目的。基于AUTOSAR架构的软件开发越来越受到高度重视，近年来已经得到极大发展，其必将逐步发展成为能够满足未来汽车电子软件系统开发需求的软件架构。

1 AUTOSAR技术概述

AUTOSAR的计划目标主要有3个：建立分层的体系架构，为应用程序的开发提供方法论，制定各种应用接口规范。

1.1 AUTOSAR软件总体架构

为了充分方便用户切换硬件平台，实现系统软件和硬件分开，尽可能最大化提高模块软件的功能复用率，AUTOSAR系统架构采用软件分层和可分布的模块软件设计的工作思想。AUTOSAR系统架构从软件底层到上层共划分为3层：基础软件层、运行时环境层和应用层［4-6］，如图1所示。

图1 AUTOSAR软件总体架构

1） 基础软件层BSW。BSW （Basic Software） 由一系列的基础服务软件组件模块构成，主要功能用于提供各种基础软件服务，包括标准化的软件功能接口以及系统功能。BSW主要包括微控制器抽象层 （Microcontroller Abstraction Layer）、ECU抽象层 （ECU Abstraction Layer）、服务层 （Services Layer） 以及复杂驱动层 （Complex Drivers）。BSW每一层均向其上层软件组件提供服务，并屏蔽了其下层的实现细节。

2） 运行时环境RTE。作为AUTOSAR ECU体系结构的核心组成部分，RTE （Runtime Environment） 不依赖ECU，是最小可运行实体 （Runnable） 的实时运行环境。AUTOSAR虚拟功能总线 （Virtual Function Bus，VFB） 的接口 （针对某个特定ECU） 的实现是由RTE完成的，它为应用程序软件组件之间的通信提供基本的服务。RTE作为基础软件层和应用层的衔接桥梁，使ECU硬件开发和软件开发分开，因此策略开发人员可以更专注于软件功能的开发。

3） 应用层。应用层 （Application Software） 代表着汽车电子软件中最核心的功能，控制功能设计都在这一层进行。AUTOSAR规定以软件组件SWC （Software Component） 的形式表示应用层软件的功能，作为AUTOSAR应用软件最小可以复用的模块，一个或多个运行实体 （Runnable） 包含在软件组件之中，而运行实体是软件中最小的运行单元。应用软件由多个软件组件集成得到，组件将把行为和功能封装而仅把端口显示出来。

1.2 AUTOSAR方法论

AUTOSAR为汽车电子软件系统开发定义了一套通用的解决方案，即AUTOSAR方法论［7］。AUTOSAR方法论中不规定要执行哪些活动，而且也没有定义“责任”和“角色”之类的东西。它既不是商业模型，也不是完整的过程描述。它只是一个“工作产品流” （work-product flow），AUTOSAR方法论定义了具有相互依赖性的“工作产品流”中的活动。AUTOSAR方法论并不定义何时执行和怎样迭代，也并不定义整体的时间线。在不同的精确度上同样的行为 （即系统配置行为） 会重复执行，例如第一个“粗糙”配置和最后一个“精确”配置在系统设计中依赖于实际配置甚至是ECU的实现。

AUTOSAR方法论描述了从系统层配置到ECU可执行代码的设计步骤，具体开发流程如下：①负责编写系统配置输入描述文件；②系统配置；③提取特定ECU的描述；④ECU配置；⑤生成可执行文件。

1.3 AUTOSAR接口类型

AUTOSAR共定义了3种类型的接口：标准接口、标准AUTOSAR接口和AUTOSAR接口，如图2所示。

图2 AUTOSAR接口类型

1） 标准接口是用C语言定义的标准API，这些接口可实现操作系统和RTE、BSW模块和ECU内部之间的函数调用。

2） 标准AUTOSAR接口包括两种类型：BSW提供给ASW的服务接口，整车企业根据需要配置的标准接口，其完全由AUTOSAR 标准规定。

3） AUTOSAR接口一方面描述软件组件与复杂驱动、ECU抽象层之间提供和获取的服务，另一方面描述软件组件之间提供和获取服务、数据。此种接口是按照AUTOSAR接口定义规则来定义的，这些接口中的一部分已经由AUTOSAR定义，另外一部分需要整车企业自定义，通过这些接口实现了软件组件在不同ECU上的可重用性。

2 AUTOSAR服务层设计

AUTOSAR的服务层主要包括通信服务、存储服务和系统服务，如图3所示。作为基础软件中的最高层，服务层与应用软件之间也具有密切关联。当用户访问一个包含ECU抽象层中的I/O接口信号时，服务层提供：①操作系统功能；②车辆网络通信及管理服务；③存储管理 （NVRAM管理）；④诊断数据服务 （主要包括系统故障数据处理、错误数据存储及UDS数据通信）；⑤ECU状态管理。

图3 AUTOSAR服务层

2.1 系统服务（System Services）

系统服务模块是基于一组同时可以由所有不同层次管理模块相互使用的系统功能和管理模块，包括AUTOSAR OS、诊断事件管理器、诊断通信管理器、BSW模式管理器、开发错误跟踪器、功能禁止管理器、全局时间软件模块、通信管理器、看门狗管理器、ECU状态管理器等，提供基本服务给应用和基本软件开发模块，如图4所示。

图4 系统服务

2.1.1 AUTOSAR OS

实时应用的所有基本服务由AUTOSAR系统提供，包括调度、中断处理、本地消息处理、错误检测机制以及系统时钟自动同步和系统运行时间。这些服务通过使用API将通信层和OS与应用连接，它们都隐藏在定义的API之后。

AUTOSAR OS的基本特征包括：①软件提供系统运行时保护功能 （包括计时、存储等）；②静态配置；③提供基于优先级的调度策略；④可宿主在低端控制器上，并且不需要其他资源；⑤能够推断实时系统性能。

2.1.2 BSW模式管理器

BSW模式管理器 （BswM） 是AUTOSAR BSW软件中用于控制与切换车辆或应用层模式的模块，其职责是基于规则仲裁来自应用层SWC或其他BSW模块的模式请求，并基于仲裁结果来执行动作。

BswM的一个基本功能是它可以描述并分为两个不同的任务：一个模式控制，一个模式仲裁。

2.1.3 诊断通信管理器

诊断通信管理器DCM （Diagnostic Communication Manager） 的主要作用之一是确保管理诊断通信状态，确保诊断通信数据流，特别是确保诊断会话模式和确保诊断安全状态。DCM在把数据消息传送至AUTOSAR SW组件进一步处理之前，进行诊断消息处理和内部检查。应用层中的每个调用将根据诊断服务的ID请求来自动执行。

此外，DCM在当前会话模式中诊断服务的执行将根据诊断状态来进行判断，以及检查是否支持相应的诊断服务请求。

2.1.4 功能禁止管理器

软件组件和软件组件功能的控制机制由功能禁止管理器中FIM （Function Inhibition Manager） 来提供。功能的具体构成条件是一个、多个或部分的具有相同禁止条件或相同执行权限的可执行实体，通过手动修改和重新配置可以实现对这些功能的禁止，具体可以通过FIM方法实现。这样一来，极大地提高了功能在新系统环境下的适应性。

2.1.5 诊断事件管理器

诊断事件管理器DEM （Diagnostic Event Manager） 跟AUTOSAR内诊断模块的功能禁止管理器 （FIM） 和诊断通信管理器 （DCM） 一样，它本身是一个子组件，负责存储和处理出错的诊断事件的Freeze Frame数据和Extended Data数据。例如DCM获取的所有存储的DTC （Diagnostic Trouble Code）故障信息都由DEM提供。DEM定义了一种类型可选的过滤服务，给FIM、DCM和应用层提供接口。

2.1.6 开发错误跟踪器

在软件开发期间，跟踪和记录软件错误主要由开发错误跟踪器DET （Development Error Tracer） 来实现，它本身是一个辅助工具，用来实现辅助软件的开发和软件的集成工作。API已经明确定义，但在软件产品的代码中并不一定都需要包含DET。在特定的软件测试和应用环境下，软件系统开发人员和软件系统集成人员可以为API功能选择最优的策略。

2.1.7 全局时间软件模块

全局时间软件模块StbM （Synchronized Time-base Manager） 的功能有两个：①提供绝对时间值；②同步各个软件模块实体。

2.1.8 通信管理器

通信管理器，用于实时收集并协调网络访问者的请求，主要用于负责整个网络通信资源的管理。特定的物理通道对一个应用程序可以使用与否的定义可以用通信管理器通过其定义“通信模式”的方式来进行表示，并以此方式来定义诸如只接收、只发送、不接收也不发送，接收/发送等多种使用方式。

2.1.9 看门狗管理器

看门狗管理器的触发是基于应用软件的生存状态。作为AUTOSAR的标准化基本软件体系结构的基本安全模块，与软件计时器和约束有关的应用程序执行的可靠性由看门狗管理器负责监控。看门狗硬件计时约束和应用计时约束的分离基于分层体系的结构设计方法。这样一来，在触发硬件看门狗功能的同时，对一些独立应用的生存监控也被看门狗管理器来提供。

2.1.10 ECU状态管理器

ECU状态管理器可以管理诸如run、off、sleep等ECU内部的不同状态，此外还会管理诸如startup、shutdown、wakeup等ECU的不同状态之间的转换。它是一个基本软件模块，控制包括系统的AUTOSAR BSW模块的启动阶段。

为了保证能够同时启动ECU或为了能够将其转换模式到具有备用工作状态、休眠工作状态等低或高功耗工作状态，ECU状态管理器必须同时支持独立的预处理动作和过渡。通过ECU状态管理器的能力和特性的优化使用，电源消耗的预定义策略就可以通过该模块来执行，ECU的能源管理也就能够得以有效地实现。

2.2 存储服务

存储服务负责管理从不同存储驱动读/写非易失性数据，由一个NVRAM管理器模块构成。它提供给应用快速读取，需要一个RAM镜像作为数据接口。

存储服务抽象了存储位置和属性，其任务是为系统提供了诸如数据校验、保护、保存、加载、可靠性存储等非易失性应用数据管理机制，以一种统一的方式向应用提供非易失性数据。

2.3 通信服务

通信服务通过车辆通信网络硬件中的抽象与车辆通信驱动程序进行连接，用于实现车辆LIN、CAN、FlexRay等通信网络之间通信的一组模块。通信服务主要职责有如下几个任务：①为网络管理提供统一的服务；②可以隐藏放在应用程序文件中的应用消息文件属性和应用协议；③为车辆网络提供统一的接口以进行通信。

3 AUTOSAR系统实现

根据客户需求，在遵从AUTOSAR规范的前提下进行AUTOSAR服务层软件的各项配置工作。现在比较流行的AUTOSAR系统软件开发工具主要有使用Bosch公司ETAS的软件ISOLAR、ElektroBit公司的EB tresos、dspace公司的SystemDesk、Vector公司的DaVinci等［8］。图5为使用Bosch的ISOLAR软件进行DCM的相关软件配置，图6为DEM的相关软件配置信息。

图5 DCM设计实现

图6 DEM设计实现

在RTE、基础软件配置和软件组件设计完成后，需要通过开发工具生成相应的可执行应用代码和静态代码。之后需要根据客户需求，进行应用层代码的开发工作。

4 结束语

当前在汽车电子软件开发中AUTOSAR架构已经被广泛采用，基于AUTOSAR 标准并且通过标准化的BSW 接口进行软件模块设计和接口配置，实现了底层基础软件和应用层软件的相互独立，使软件有了更好的移植性和可重用性。通过AUTOSAR配置工具生成软件，代码一致性好，开发周期短，提高了软件开发的效率，大大降低了成本。本文详细阐述了AUTOSAR架构方法论中系统级软件的开发方法，可以帮助开发人员更好地了解AUTOSAR软件架构优点，从而能够促进传统ECU开发模式和开发流程向AUTOSAR架构开发的转变。基于AUTOSAR架构的软件开发以其优势，必将成为未来汽车电子软件发展的方向。