AUTOSAR技术初探｜下

AUTOSAR技术初探

中汽创智科技有限公司 – 基础软件部门

说明

文章转载请注明作者、出处以及版权声明。未经授权，禁止用于商业目的。本文章仅代表作者观点，不对其中包含或引用信息的准确性、可靠性或完整性提供任何明示或默示的承诺及保证。对于任何直接或间接采用、转载本文章信息产生的损失，作者不承担任何责任。

联系

如果您对本文档内容有任何建议，请发邮件至以下邮件列表。

邮件列表：

zhoushu@t3caic.com

autosemo-info@caam.org.cn

AUTOSAR发展史大致有这么几个阶段：Initialization(2002-2003)；Phase 1(2003-2006)；Phase 2(2007-2009)；Phase 3(2010-2012)；2013年开始继续更多开发；2017年开始启动自适应平台。笔者认为AUTOSAR在国内发展的黄金期始于4.0（2013年，版本进入稳定状态），国内汽车企业开始尝试在产品中导入AUTOSAR技术，同时国内开始陆续有软件供应商发布自主AUTOSAR解决方案。2017年开始，AUTOSAR技术产生新分支形成Adaptive Platform（自适应平台），而原来的更名为Classic Platform（经典平台）以示区分。

从2019年开始，CP和AP标准的发布版本号统一按发布时间命名，比如目前最新的版本是R21-11，意思是2021年11月发布的版本。

成员单位发展趋势 ^[1]

AUTOSAR 组织架构 ^[2]

这里主要了解一下工作组（Working Groups）的主要工作内容：

–       指定AUTOSAR运行时环境，在车辆网络的所有节点上提供ECU间和ECU内的通信。

–       定义基础软件模块和汽车操作系统领域现有解决方案的需求和分析。

–       定义方法和数据交换格式，以描述交换车辆E/E系统架构的相关元素。

–       定义AUTOSAR运行时环境的API和服务接口。

–       定义跨不同车辆领域的标准化接口。

–       定义验收测试标准。

–       为自适应平台整合一个典型的AUTOSAR软件实现。

–       工作组成员包括核心合作伙伴、高级合作伙伴和发展合作伙伴，以及代表了各个领域广泛知识和经验的与会者。

工作组主要包括三大板块：跨标准工作组（Cross-standard Working Groups），经典平台工作组（Classic Platform Working Groups），自适应工作组（Adaptive Platform Working Groups）。跨标准工作组负责共性技术建设，经典平台和自适应平台共组织负责各自特性技术建设。各工作组详细工作内容介绍见 https://www.autosar.org/working-groups/

工作组组织架构 ^[2]

下图可见，AUTOSAR标准不仅包括“Classic Platform”（经典平台）和“Adaptive Platform”（自适应平台），还有“Foundation”、“Acceptance Test”、“Application Interface”。所以，如果你是测试工程师，那么可能也需要关注“Acceptance Test”，如果你是应用工程师，那么可能也需要关注“Application Interface”。

AUTOSAR 标准之间的关系 ^[2]

因为 CP 和 AP 是基础软件平台，所以先对两者之间的主要区别简单介绍。

接下来结合AUTOSAR官方网站信息对各个规范展开概述性介绍。

“Foundation”（基础）

Foundation标准的目的是加强AUTOSAR平台之间的互用性。

Foundation包含AUTOSAR平台之间共享的通用需求和技术规范(例如协议)。

“Classic Platform”（经典平台）

AUTOSAR经典平台架构在最高抽象级别上区分了运行在微控制器上的三个软件层:应用程序（ASW）、运行时环境（RTE）和基本软件（BSW）。

–       应用软件层基本上独立于硬件。

–       软件组件之间的通信以及访问BSW都是通过RTE。

–       RTE表示应用程序的完整接口。

–       BSW包括三个主要分层，以及复杂的驱动程序（三个主要分层：服务层，ECU抽象层，微控制器抽象层）。

–       服务被进一步划分为代表系统、内存和通信服务的功能组。

CP AUTOSAR 分层架构 ^[1]

CP AUTOSAR的核心内容主要有两部分，即“软件架构”和“开发方法论”，接下来结合官方资料对这两部分进行概述。

标准化ECU软件体系结构的主要概念是通过软件抽象层RTE（运行环境）将与硬件无关的应用软件和面向硬件的基础软件分离开来。在RTE的上层，可以开发特定于OEM竞争力的应用软件。在RTE的下方，它实现了基础软件的标准化和应用软件解耦。AUTOSAR软件架构的进一步特点是ECU软件的可扩展性，适用于多个汽车和各种车型。

AUTOSAR软件体系结构中的基本软件进一步分为以下几个层：服务、ECU抽象和微控制器抽象。RTE实现了应用层与基础软件的分离，包括对应用层与基础软件之间数据交换的控制。这在应用程序级别形成了面向组件、与硬件无关的软件结构的基础，软件组件(SWCs)是独立的单元。由于SWC的硬件独立性，因此可以在不了解硬件使用的情况下开发SWC。

除了软件架构之外，AUTOSAR还引入了一种用于汽车软件开发的协调方法。这主要是由于需要改善当今汽车项目中涉及的各方之间的合作。

AUTOSAR提供了方法来指定在ECU上集成软件组件所需的所有方面，并通过各种不同的总线系统将不同的ECU集成到整个网络通信中。该方法定义了活动对工作产品的依赖关系，并可预见支持AUTOSAR中的活动、描述和工具的使用。

描述(.arxml)基于AUTOSAR模板，它定义了正式的交换格式(AUTOSAR Schema)和语义约束，这些约束伴随着交换格式。描述用于保存在AUTOSAR方法中产生或使用的信息。各种生成器可以利用描述中的信息来支持RTE和AUTOSAR基本软件(包括操作系统)的配置和生成。

“Adaptive Platform”（自适应平台）

AUTOSAR自适应平台为自适应应用程序(ARA)实现了AUTOSAR运行时。有两种类型的接口可用，服务和API。该平台由按服务和自适应AUTOSAR基础分组的功能簇组成。

功能簇……

–       自适应平台的组装功能

–       定义需求规范的簇

–       从应用和网络的角度描述软件平台的行为

–       不限制实现自适应平台的架构的最终软件设计。

AP AUTOSAR 分层架构 ^[1]

AUTOSAR自适应平台基础中的功能簇必须在每个(虚拟)机中至少有一个实例，而服务可以分布在车内网络中。

与AUTOSAR经典平台（CP）相比，自适应平台的AUTOSAR运行时环境在运行时动态连接服务和客户端。

AUTOSAR扩展了现有的方法论，能够为经典平台和自适应平台提供通用的方法论方法。为了支持功能应用程序的分布式、独立和敏捷开发，需要在开发方法上采用标准化的方法。AUTOSAR自适应方法涉及到工作产品及其各自任务的标准化。工作产品描述了诸如服务、应用程序、系统以及它们的配置等构件。各自的任务定义了工作产品如何交换所需活动的设计信息。

“Acceptance Test”（验收测试）

AUTOSAR验收测试是总线级也是应用程序级的系统测试，用于验证与应用软件组件和通信总线相关的AUTOSAR堆栈的行为。

因此，验收测试可用于验证网络中不同AUTOSAR栈的互操作性。AUTOSAR提供的测试用例涵盖了RTE需求（如产物的生成、API的存在、RTE行为）、基本软件服务、库，以及总线行为（如传输行为、总线关闭处理、网络管理）和总线协议（如传输协议、网络管理、诊断通信）。AUTOSAR指定的测试用例的数量不断增加。

此外，AUTOSAR提供了一种方法，用户可以使用它来扩展标准测试套件，例如，在标准集中没有涵盖到的标准特性上，或者在特定于用户的特性上。

测试流程 ^[1]

“Application Interface”（应用接口）

AUTOSAR为以下六个汽车领域标准化了大量的语法和语义应用接口：车身和舒适性、动力总成发动机、动力总成传动系统、底盘控制、乘员和行人安全以及人机交互、多媒体和信息通讯。

重点是完善应用程序的接口规范，以强调软件复用和交换，这被认为是AUTOSAR的主要需求之一。部署标准化的应用程序接口是应用程序复用的关键因素。

这些标准化的接口允许软件设计师和实现者在扩展或复用独立于特定硬件和/或电子控制单元(ECU)的软件组件时使用它们。

一般来说，应用程序是ECU的竞争力。AUTOSAR不会标准化应用程序的内部功能行为，例如算法，而是标准化应用程序之间交换的内容。

典型的应用例子有电子稳定控制（ESC）、转向、电动驻车制动、停车距离控制、外灯、防盗系统、远程无钥匙进入等。

应用接口规范 ^[1]

至此，我们对AUTOSAR有了一个基本认识，下一篇我们将就如何能更高效地对CP AUTOSAR技术学习进行探讨。