针对自动驾驶的系统开发，本文我们重点从实例触发讲解如何利用一定的工具链进行有效的系统建模。建模的实质是对系统架构中的模型元素进行模块设计、原子服务定义、接口设计以及信号设计等等。本文采用的的工具链是基于Enterprise Architecture （简称EA）进行架构设计的。其中，很多设计过程基于我们已经很熟悉的自动驾驶系统开发平台中Autosar的过程开发思想。

众所周知，AP Autosar的开发过程主要包括三层，从下到上分别为基础层、中间层及应用层。Autosar为基础层和中间层定义了功能和相关的接口，同时也为应用层组件提供了接口规范和运行环境支持。对于系统架构设计和开发来说，我们仅止步于需求设计到软件组件接口设计层。

在建模基础上，为了支持不同OEM与Tier1的工作交接，并支持从设计面向开发的代码生成。Autosar定义了一种称之为ARXML的接口文件。该文件能够描述模型module、组件component、接口interface标准。自动驾驶以面向服务的方式开发过程中，一般是将各个ECU作为服务提供端或服务请求端。由于OEM关注的点是系统级的功能和集成，因此主机厂通常会提供以***ECU.arxml***描述文件作为ECU 的系统级参数定义文件。该文件中包含多个ECU的实例，并不包含软件组件部分，只有ECU级的通讯关系。这样就可以自动生成相关的配置，完整配置好后即可生成代码文件，就可以免去手写代码的时间，提高开发效率。

01 系统建模过程

本文以自动驾驶系统整体架构设计和其中比较典型的功能需求设计（车道持续对中LCC）为例说明整个建模过程。本文将以EA软件工具链详细讲解整个系统建模与ARXML文件生成的过程。首先利用三方工具链EA进行系统建模，建模的整个过程从上到下依次为客户需求Customer Requirement，系统需求System Requirement，系统模型System Model，行为元素Behavioral Elements生成用例模型。其中涉及对结构元素Structure Elements（包含各种模型视点、架构视点、结构分解视点、组件分配视点、行为视点、行为分配视点）的整个过程定义。随后，基于.arxml的文件作为输入导入工具链进行相关的配置（比如可以通过基础软件EA外加LiberLiber Autosar Engineering插件）来完成整个模型建模和接口文件生成。当然，也可以通过另外单独的软件PREEVISION进行模型文件导出。

细化下来整体上包括如下建模流程：

从系统设计和软件开发的角度讲，两者是分工协作的，整个系统架构设计需要的工作流程如下：

1）整车企业定义整体的自动驾驶系统架构，并把系统进一步拆分为子系统SubSystem和组件SWC，定义子系统和应用组件的功能Function List和接口；其中基于Autosar的系统设计和软件开发过程中，模型构建是其重要的核心内容。

2）中间层和底层通常是由OEM把控Tier1或者Tier2进行开发，由于中间层可以有效屏蔽掉底层驱动的差异，应用组件的接口则可以主要关注功能和RTE映射，并可以通过配置完成，平台厂家通过RTE规范提供VFS的实现；而底层技术厂家按照底层软件BSW的规范开发基础软件。

3）底层软件开发厂家不需要关注系统功能定义和应用组件设计，只需要把应用组件之间的通信通过实时运行环境（Real Time Environment）RTE的配置对接到BSW，实现应用和驱动的隔离，能够最快速地构建应用。

综上，对于开发而言主要包含建模、仿真、ARXML接口文件生成、对BSW和RTE代码实现几个重要步骤。前三者我们采用汽车电子行业主流的建模工具EA软件实现，包含系统工程建模语言Sysml和软件工程建模语言UML支持，并提供了面向Autosar软件架构和建模扩展。

02 软件建模过程

根据应用功能LCC可以首先划分其实现的软件组件SWC，软件组件之间通过Port口进行通信。Port口包括支持异步通信的“发送者Sender+接受者模式Receiver”模式，也支持同步调用过程下的“客户端Client+服务端Server”模式。设置SWC内部运行体Runnable通过Port口定义的数据类型DataType和函数Operation可以实现相应的功能。

1、数据模型DataType定义

数据模型工具箱包含用于创建整个软件架构的数据Data和接口interface元素。通过定义的不同数据类型，可以对应将其导出到ARXML文件中。

如上图所示，整个软件模块设计中支持如下数据类型：

1）通用基本类型Gerneric Base Type：主要定义原始数据类型，例如int、double等，在如上定义的ARXML中，这这类通用基本类型主要生成到一个叫SW-BASE-TYPE-XML结构中；

2）常用数据类型Data Type：包括数值Value，数组Array，数据结构Data Structure；这三者的关系类似于C或者类C语言中的对应数据关系。即一个数组Array大小通过嵌入数据元素的多维属性设置被指定，每个数组的数据类型必须保持一致。但是，一个结构体Structure则可包括多个Value元素，且各个Value元素类型可以不相同（即int、float类型均可以涵盖至结构体中）；

3）端口类型定义Port Type Definition：EA软件在SOA的Sender-Receiver和Client-Server模型中，通常使用Operation来进行函数头的定义。如下图所示，黑色菱形连接的所有数据元素都是对应接口的组成元素。且有部分的Port类型不能被导出为ARXML文件。

1、数据端口定义

为了添加一个Interface到component，需要使用不同Port元素，在Port的选项中设置name和type（Property type），设置在一个Port的标签值Tagged Value中可以设置方向以及该Port口是否是一个服务端口。Port类型定义通常被建模为软件组件的接口元素，且每个Port类型都有一个对应的Interface元素被定义，对于Sender-Receiver接口Interface定义数据元素而言，需要创建部分关联整体的模型（Part-Association）的连接形式（如下图的黑色菱形）来指定数据元素是否是其接口的组成部分。

为了连接两个Port口，需要使用连接器Flow Connector，该connector存在于一个新建的Port口和一个Component之间。且服务端口之间需要设置Port方向，该方向表数据流的传递关系及组件层次关系（该层次关系主要表示了一个Component是否是另外一个元素的子元素）。比如探测道路目标数据中，其车道线、车道标志、静止/运动车辆、行人等这些都是其相应的道路子元素目标。

2、行为模型定义

所有的组件行为需要被建模在一个行为视图上（该行为视图可以创建多个实例），也就是说在创建了一个组件后，可以添加行为元素作为容器用于建模。在行为视图上，使用Runnable或Inter-Runnable-Variables等元素建模内部行为，包括并发调用。例如某个轨迹预测模块，既可以被主控制器端调用作为车道对中的轨迹预瞄函数，也可以被辅助控制器端调用用于安全停车的预瞄轨迹。

AP采用了各种传统上尚未被ECU充分利用的成熟技术，其中比较典型的就是面向服务的架构设计SOA(service-oriented-architecture)。AP Autosar需要遵循面向服务的体系结构SOA。由于SOA是基于以下概念：

即系统由一组服务组成（称之为Service Group），其中一个服务可以依次使用另一个服务，应用程序可以根据其需要使用一个或多个服务。服务可以驻留在应用程序运行的本地ECU上，也可以位于正在运行AP另一个实例的远程ECU上。

03 模型导出为ARXML文件

这里我们解释下什么叫ARXML文件。ARXML（Architecture eXtensible Markup Language）文件作为通用配置文件或数据库文件，是在AUTOSAR架构下基于汽车电子应用场景定义的传输信息文件格式，在数据传输和存储中起到关键作用。ARXML 作为W3C 的推荐标准，具有自我描述性，其标签没有被预定义，需要自行定义。

对于OEM来说，其更加关注系统应用层功能，通过提供包含ECU的应用功能需求的系统描述文件（该文件不包含基础软件组件），控制器的供应商将基于OEM提供的系统描述文档，加载到工具链（如Vector DavinciDeveloper、Artop、AutosarExplorer等），将ARXML文件导入支持其文件格式的工具，可查看到里面的信息。引入系统的虚拟功能总线（Virtual Function Bus）上，就可以和系统的其它模块进行通讯。根据OEM提供的系统功能描述文件，其内部包含了系统部件Component到ECU的映射关系，信号Signal的映射关系，供应商就可进行ECU内部硬件结构和接口的设计，并将信号分配给实际的接口，如此就完成了arxml创建。

本文直接将Autosar插件简单的插入到EA软件模块中。导出过程也十分简单。直接选中扩展菜单中的LieberLieber Autosar Engineer——>Export Selected Components to ARXML——>选择要导出的Component即可。

这里需要注意的是，ARXML文件的导出形式包括主流的三种：

1、多个软件组件Software Component 组；

2、某个未包含数据类型的Component；

3、具备所有引用数据类型的Component。

04 典型的自动驾驶系统ARXML文件解析

本文以自动驾驶系统HWP中定义的其中一个服务端口为例说明整个系统的ARXML文件内容，并以此完整对ARXML文件内容的解析。整体来说，ARXML文档中的元素形成了一棵文档树。这棵树从根部开始，并扩展到树的最顶端。ARXML元素标签必须成对，各元素需要正确嵌套至标签中。所有元素均可拥有子元素，所有元素均可拥有文本内容和属性，文档必须有根元素，属性值必须加引号。

如下截取了系统设计中的核心ARXML内容进行详细解析。

软件组件原型将不会出现在ARXML源代码中，但是会出现在文件头赫尔二进制接口中，以此来作为头文件的文件名部分。

Port口名称将会出现在ARXML源代码中（以<SHORT-NAME>Port</SHORT-NAME>表示），该Shortname定义的Port口处于每个软件组件子分支中。

05 结束语

本文以自动驾驶系统开发实例详细讲解了各面向对象服务的接口文件arXML创建流程。其中包括设计可以基于UML/SysUML建模。对于供应商拿到OEM提供的系统级的功能描述文件并导入到工具链（比如vector的PREEVISION）后，可以直接加入到系统的虚拟功能总线上，也就是AutoSAR的RTE，这样就可以和系统内的其它模块进行通讯，此时，还是系统级的ECU，并没有软件组件部分。因OEM提供的系统级的功能描述文件中包含了系统部件到ECU的映射，以及信号的映射，基于此可进行ECU内部硬件结构和借口的设计，并将信号分配给实际的接口，这整个过程就完成了整个系统建模到软件开发的整体流程。读者需要重点关注下系统建模相关的知识点，从实际出发完成各分子服务的建模，这对于关注于自研的主机厂来说是必须掌握的相关能力。