虚拟局域网软件开源_基于开源AUTOSAR的高级驾驶员辅助系统的设计与实现过程...

原文引自 Park J, Choi B W. Design and implementation procedure for an advanced driver assistance system based on an open source AUTOSAR[J]. Electronics, 2019, 8(9): 1025.

本文仅供自学和交流使用，未经允许请勿转载~谢谢

摘要：在本文中，我们介绍了基于开源汽车开放系统架构（AUTOSAR）的高级驾驶员辅助系统（ADAS）的详细设计和实现过程。由于ADAS的软件复杂性不断提高，可移植性，组件互操作性和维护已成为必不可少的开发因素。AUTOSAR通过定义系统架构标准来满足这些要求。尽管已经建立了AUTOSAR的商业发行版，但可访问性却是一个巨大的问题，因为它们附带了非常昂贵的许可费用。开源AUTOSAR解决了这个问题，并且还可以最大程度地降低开发总成本。但是，开发过程还没有很好的建立，对于工程师来说可能很困难。本文的贡献分为两个主要部分：首先，我们提供了使用开源AUTOSAR开发碰撞警告系统的完整细节。其中包括简化的AUTOSAR基本概念，我们对其进行了组织，以便于理解。同样，我们对现有的AUTOSAR开发方法进行了改进，重点是在每个开发阶段都明确定义基础工具。

其次，由于尚未验证开源软件的性能，并且需要进行基准测试以确保系统的稳定性，因此我们提出了各种评估方法，用于评估任务的实时性能和通信堆栈的总体延迟。这些性能指标与确认整个系统是否具有确定性的行为和响应能力有关。

评估结果可以帮助开发人员提高车辆系统的整体安全性。

在与我们自行开发的碰撞警告系统集成的AUTOSAR评估套件上进行了实验。该程序和评估方法不仅适用于检测障碍物，还适用于ADAS的其他变体，并且对于将开源AUTOSAR集成到各种车辆应用中非常有用。

Keywords: AUTOSAR; ADAS; open source; design methodology; performance evaluation

1. Introduction

近来，随着交通量变得越来越复杂，对减少驾驶员交通事故造成的危及生命的状况的高级驾驶员辅助系统（ADAS）的需求出现了。ADAS使用传感器和电子设备来帮助驾驶员做出更好的决策[1]。近年来，随着传感器和电子技术的显着进步，对ADAS的期望也大大提高。在这种情况下，已经进行了各种研究，涉及使用摄像机[2]跟踪车辆，使用安装在车辆座椅上的传感器测量驾驶员的心率[3]，基于天气，道路通知建议的车速 ，车辆状况[4]和自动驾驶汽车之间的通信[5]。随着ADAS的发展，底层的电子软件变得更加复杂。互操作性，可移植性和可维护性成为关键要求的地方。这些要求通过汽车软件平台来解决，例如开放系统及其在汽车电子（OSEK）[6]和AUTOSAR [7-9]中的接口。

传统原始设备制造商（OEM）和电子控制单元（ECU）制造商在没有统一标准的情况下使用各种硬件和软件来开发车辆的ECU。在没有统一标准的情况下，ECU是以硬件相关的结构开发的，当硬件发生更改时，需要创建新的软件。这样，开发的ECU降低了软件的可重用性和可靠性，并增加了开发成本。为了解决这个问题，德国汽车公司共同启动了OSEK，其目的是开发“汽车分布式电子控制单元的开放式体系结构的行业标准”。它提供了包含硬件和软件的标准接口，以便于开发和重用。但是，汽车系统复杂性的不断提高导致当前汽车开放系统架构（AUTOSAR）的发展。AUTOSAR旨在开发独立于硬件的软件，并可以在ECU的不同组件中分发或重用[10,11]。AUTOSAR通过运行时环境层将独立于硬件的应用程序软件与面向硬件的软件分开。在这项研究中，我们专注于基于AUTOSAR的碰撞预警系统的开发。

AUTOSAR开发的解决方案分为商业[12]和开源发行[13]。在商业AUTOSAR解决方案中，供应商根据开发工具提供了从开发环境到实施的完善的开发方法。因此，在项目开发中相对容易使用，但许可成本较高。相反，开放源代码解决方案可以降低开发成本，因为许可证是免费的并且可以轻松获得。但是，文档和实现过程的定义不明确。例如，Sun等。[14]建立了一个基于AUTOSAR验收测试的基于控制器局域网（CAN）总线的软件框架。同样，Jansson等。15]，使用AUTOSAR通信堆栈实现了FlexRay通信。两位研究人员都对通信堆栈和所需的实现机制进行了性能评估。但是，这些研究并未提供实际的汽车应用。Melin等人提出了一种基于开源AUTOSAR的汽车座椅加热系统。[13]和消息认证的控制器局域网（MaCAN）协议在车辆应用中的应用Kulaty等。提出[16]。但是，所有这些研究都只专注于通信堆栈或特定应用程序的实现。没有考虑设计和实施程序。由于这个原因，工程师和从业人员提到复杂性，学习曲线和不良的文档是AUTOSAR可识别的缺点[10]。

为了解决这些缺点，本文旨在为从业者（尤其是初学者）提供有关汽车应用开源AUTOSAR的设计和实现的全面参考。首先，我们组织了AUTOSAR的基本概念，以使其更容易理解体系结构和每个基本组件。尽管AUTOSAR手册[17]描述了大多数零件，但本研究基于第一手经验提供了简化的解释，这在实际实施中非常有帮助。此外，我们提出了基于开源AUTOSAR的现有开发方法的改进[18-21]。重点在于定义每个开发阶段所需的基础工具，这对于为ADAS等复杂系统设计灵活且可重用的软件模块非常必要。

为了验证该方法，我们开发了一个碰撞预警系统，该系统将实际的超声波传感器和发光二极管（LED）连接到AUTOSAR评估套件NXP MPC574XG-324DS [22]，其中包括完整的细节和实施步骤。传感器数据的可视化在虚拟机器人体验平台（V-REP）中进行[23,24]。由于诸如碰撞预警系统之类的ADAS由复杂的软件和电子硬件设备组成，因此，应确保精确的控制周期和最小的计算延迟，以便正确处理设备。因此，整个系统应显示确定性的行为和响应能力，即实时性能。由于缺乏确定开源AUTSOAR性能的文档和确定的方法，因此本研究还提供了各种评估方法，旨在评估在AUTOSAR运行时环境中运行的任务的实时性能。其中包括任务周期性测试，以确保系统满足AUTOSAR通信堆栈每一层上的实时约束和延迟测试。这些评估方法的结果可以帮助开发人员改善其开发的车辆系统的整体安全性。尽管我们已在碰撞预警系统中实施了建议的程序和评估方法，但这些方法和评估方法适用于任何其他类型的ADAS应用程序，并且对于将开源AUTOSAR与更复杂的车辆项目集成在一起非常有用。

总而言之，这项研究的贡献是双重的：首先，我们提供了使用开源AUTOSAR开发碰撞预警系统的完整细节； 包括简化的AUTOSAR基本概念和对现有AUTOSAR开发方法的改进。其次，我们提出了各种评估方法，用于评估运行时环境中任务的实时性能以及通信堆栈的总体延迟。本文的组织结构如下：第二部分介绍了AUTOSAR的简化基本概念。在第3节中介绍了使用开源AUTOSAR提出的ADAS开发过程。在第4节中显示了实验过程和结果。在第5节中，对使用所提出的评估方法的已实施系统进行了评估，最后一部分总结了结论。

2. AUTOSAR Basic Concept

AUTOSAR是由三个主要层组成的标准软件：应用程序软件组件（ASW），运行时环境（RTE）和基本软件（BSW）。每个层被模块化为各种软件组件，并通过称为虚拟功能总线（VFB）的虚拟网络相互连接[25]。图1显示了AUTOSAR的基本软件架构[26]。

ASW层由映射到特定ECU的AUTOSAR软件组件（SWC）组成。在信息隐藏和封装方面，SWC分为基于AUTOSAR应用程序功能可重复使用的最小单元，并且独立于硬件和网络总线。不同的SWC之间或SWC与BSW之间的通信是通过VFB执行的。它定义了一个可以向SWC输入和输出数据的访问点的接口，以及一种与其他SWC或BSW通信的通信方法。无论通信对象位于哪个ECU中，SWC都可以通过端口和接口发送和接收必要的数据。该通信接口包括发送器-接收器接口和客户端-服务器接口。在发送方-接收方接口的情况下，数据通过信号传递方法从发送方发送到接收方。从发送方发送的数据的数据类型必须与接收方指定的数据类型匹配。在客户端-服务器接口的情况下，服务器的功能由客户端在函数调用方法中调用。在客户端中调用服务器功能时要使用的参数的数据类型应与服务器中指定的数据类型匹配。

RTE层用作管理同一ECU的ASW层和BSW层之间通信的中间件。无论通信是在ECU内还是通过外部通信网络，RTE都提供相同的抽象接口，因此ASW层的SWC与BSW层的SWC无关。RTE层的VFB为客户端-服务器和发送方-接收方接口提供AUTOSAR通信机制，并向SWC提供通信服务。VFB是一种技术概念，可实现整个系统功能结构的开发，而与ECU和网络的实际硬件拓扑无关[25]。在图1中，SWC-1和SWC-2在ECU 1内进行通信，但是在SWC-3至SWC-6的情况下，在ECU 1和ECU 2的SWC之间进行通信。一个VFB，在将SWC-3升级为SWC-6时，它们的设计与SWC-1和SWC-2相同，而与映射的ECU的位置无关。将SWC映射到ECU后，VFB在每个ECU中被实现为RTE-1和RTE-2，如图1所示。结果，RTE-1和RTE-2在VFB中起着各自的作用。

图2显示了AUTOSAR的详细软件架构，该架构是根据我们自己的第一手经验和对AUTOSAR手册的解释而统一的。BSW在图1中进行了简单介绍，在图2中进行了详细说明。

BSW还是一个标准软件层，提供ASW层和SWC执行指定任务所需的服务。BSW由服务层，ECU抽象层和微控制器抽象层（MCAL）组成。服务层根据要提供的功能分为系统服务，内存服务和通信服务。系统服务是一组模块和功能，可以在模块的所有层中使用。系统服务提供实时操作系统，车辆网络通信和管理，ECU状态管理功能，WatchDog和诊断服务功能。在图2中，OS模块组，模式管理模块组和诊断模块组对应于系统服务。内存服务由负责非易失性数据管理的一组模块组成。标准的AUTOSAR接口向ASW层提供非易失性数据。内存位置和属性抽象； 用于存储，加载，校验和保护和验证的非易失性数据管理机制； 和稳定的存储。在图2中，内存模块组由内存服务提供。

通信服务是一组模块，它们执行诸如CAN，本地互连网络（LIN）和FlexRay之类的功能，以通过统一接口向高层提供通信。通信服务提供了用于通信网络管理的服务以及消除了下层依赖的统一接口。此外，它通过抽象的通信驱动程序访问通信驱动程序，并具有独立于MCAL层的通信驱动程序的结构。通信服务提供了统一的接口，消除了较低层对各种应用程序和车辆网络诊断通信的依赖性，从而允许开发应用程序时无需考虑协议和消息属性。在内部，有一个用于通信网络（例如CAN，LIN和FlexRay）的网络管理器（NM），状态管理器（SM）和传输协议（TP）。此外，存在诸如通信（Com）和协议数据单元路由器（PduR）的模块。在图2中，服务模块将CAN状态管理器（CanSm），CAN网络管理器（CanNm），CAN传输协议（CanTp），FlexRay状态管理器（FrSm），FlexRay网络管理器（FrNm），FlexRay传输协议（FrTp）， 在通信服务中提供了LIN状态管理器（LinSm）和LIN传输协议（LinTp）[27,28]。

ECU抽象层用作创建独立于硬件的软件上层的接口和驱动程序，因此可以使用MCAL。ECU抽象层独立于微控制器，但取决于所使用的ECU板。ECU抽象层根据要提供的功能分为车载设备抽象，内存硬件抽象，通信硬件抽象和输入/输出（I / O）硬件抽象。

车载设备抽象包含用于ECU车载设备的驱动程序，这些驱动程序在传感器或执行器（例如内部或外部看门狗）中不可见。该模块组的功能是从ECU特定的车载设备中抽象出来。在图2中，看门狗接口（WdgIf）模块包含在板载设备摘要中。内存硬件抽象是一组模块，这些模块抽象内部或外部存储设备。它提供了一种访问内部或外部存储设备的机制，无论存储类型如何，都可以通过同一接口进行访问，例如电可擦除可编程只读存储器（EEPROM）或闪存。在图2中，内存抽象接口（MemIf），电可擦可编程只读存储器抽象（Ea）和闪存电可擦可编程只读存储器仿真（Fee）模块都包含在板载设备抽象中。通信硬件抽象是一组抽象通信硬件的模块。要使用特定的通信协议，必须为该协议实现通信硬件抽象模块。在图2中，CanIf，FrIf和LinIf模块包含在通信硬件抽象中。I / O硬件抽象是一组抽象I / O硬件的模块。I / O硬件抽象的主要目的是提供对ASW层和SWC的I / O访问。可以通过I / O信号接口从上层访问它，而无需通过服务层。在图2中，I / O硬件抽象包括端口，用于数字输入/输出（DIO）的Dio，用于脉冲宽度调制（PWM）的Pwm和用于模数转换器（ADC）模块的Adc。

微控制器抽象层（MCAL）是BSW的最低软件层。为了避免直接访问高层软件中的微控制器寄存器，可以通过MCAL设备驱动程序来访问硬件，该驱动程序包括与硬件相关的驱动程序，例如ADC，PWM，DIO，EEPROM和闪存。通过MCAL路由对微控制器寄存器的访问，这使上层软件层独立于微控制器。根据功能，微控制器驱动程序，存储器驱动程序，通信驱动程序和I / O驱动程序被分类。这为设备及其与微型计算机的连接提供了应用程序编程接口（API）

3. Collision Warning ADAS based on an Open Source AUTOSAR

在本节中，我们描述了一个由超声波传感器和LED组成的简单碰撞警告系统的设计和实现过程，目的是为开源AUTOSAR提供深入的参考。我们提出了开发AUTOSAR应用程序的改进的设计方法，其重点是定义每个开发阶段所需的基础工具。我们还描述了碰撞警告系统的完整设计和实施过程，包括从配置SWC和BSW的逐步过程。这包括RTE和SWC可运行的开发实现.

3.1. Design Methodology

现有的AUTOSAR开发方法[18-21]难以澄清开发过程，因为在每个开发阶段都无法确定基本工具。对于商用AUTOSAR，这不是问题，因为提供解决方案的供应商提供了详细的手册，但是由于开源AUTOSAR没有明确的开发方法，因此开发人员面临许多挑战。在本文中，提出了使用开源AUTOSAR开发的专用程序。现有的AUTOSAR开发过程已分五个阶段进行了重新配置。使用ARCCORE的开源AUTOSAR开发解决方案的拟议程序。

步骤1：此步骤在Arctic Studio的SWCD编辑器中执行。

应该为.arxml文件的每个软件组件中的应用程序定义SWC描述和系统描述。

我们根据要实现的AUTOSAR软件的功能对SWC进行分类，并在每个SWC中定义通信接口，端口和数据类型。

定义SWC之后，使用定义的SWC创建SWC对象的原型。

然后，连接原型的通信端口以进行通信，并映射到ECU外部的外部端口的信号。

步骤2：此步骤在Arctic Studio的BSW编辑器中执行。用于提供SWC所需服务的BSW模块在export.arxml中定义和配置。在此阶段，默认情况下应配置的模块是用于任务调度的OS模块，用于ECU管理的EcuM模块和用于BSW管理的BswM模块。添加了其他模块以根据AUTOSAR SWC所需的功能执行其功能。如果要使用GPIO，请添加I / O模块。要实现其他ECU之间的通信，请添加通信模块。

您可以为所有添加的模块配置每个模块的详细功能。对于OS模块，可以配置任务创建，优先级和期限。在此阶段执行的模块的添加和配置都在GUI环境中进行。最后，执行ECU提取方法以创建extract.arxml文件。

步骤3：此步骤是在Arctic Studio的RTE编辑器和BSW编辑器中执行的RTE配置步骤。

RTE配置基于在步骤1和2中创建的extract.arxml文件。作为此步骤的结果，将生成RTE和BSW的源代码和头文件。

RTE配置过程将实例化在步骤1中创建的SWC原型，并将在步骤2的OS模块配置中创建的任务和事件映射到实例化的SWC的可运行对象。

通过此过程，可以在AUTOSAR OS中调度和执行SWC的可运行状态。

RTE配置完成后，将使用RTE编辑器提供的生成功能生成RTE和RTE合同文件以连接BSW和ASW。

在RTE合同文件中，定义了用于在ASW层的应用程序中调用BSW层提供的服务的API。

最后，使用BSW编辑器提供的generate函数生成BSW代码。

步骤4：使用C语言创建可运行的函数，该函数定义了SWC。

可运行对象是指RTE合同文件，该文件定义了通过RTE进行通信的API，该API是由于执行步骤3而生成的。

步骤5：构建步骤3和步骤4生成的源代码和头文件，并将其用于生成将在ECU上运行的可执行文件。

在ECU中指定并使用MCU的工具链和环境变量。

这些是在Arctic Studio中执行的。

3.2. Designing a Collision Warning System

碰撞警告系统是当障碍物位于驾驶员无法识别的盲点时，根据障碍物与车辆之间的距离向驾驶员发出警告，从而允许驾驶员识别并避开障碍物的系统。在本文中，测量了从超声波传感器到障碍物的距离，并将其传输到ECU。ECU根据距离数据确定警告级别。作为演示系统，V-REP用于显示通过CAN总线传输的传感器数据的可视化。控制信号还显示有LED指示灯。以下各节提供了上一节中描述的碰撞警告系统的详细设计过程。

3.2.1. SWC Configuration

根据通信目标模块，SWC的Communication接口分为标准化接口和AUTOSAR接口，如图4所示。标准化接口与BSW一起使用，而AUTOSAR接口与SWC一起使用。AUTOSAR框架提供了标准化接口，无需定义。AUTOSAR接口设计根据数据的大小和类型进行分类。本文定义了三个接口：声纳数据接口（SonarDataInterface）用于传输测量的超声传感器数据，数据接口（DataInterface）用于CAN数据传输，LED请求接口（LedRequestInterface）用于LED控制要求。使用SonarDataInterface和DataInterface进行通信时，使用表示距离的数据和无符号int数据类型的四个字节。使用LedRequestInterface进行通信时，该数据仅需要指示是否打开/关闭LED进行控制，因此使用了一个字节的布尔数据类型。在图4中，这些用于连接SWC原型的通信端口。

1. SWC配置SWC的通信接口根据通信目标模块，分为标准化接口和AUTOSAR接口，如图4所示。标准化接口与BSW一起使用，而AUTOSAR接口与SWC一起使用。AUTOSAR框架提供了标准化接口，无需定义。AUTOSAR接口设计根据数据的大小和类型进行分类。本文定义了三个接口：声纳数据接口（SonarDataInterface）用于传输测量的超声传感器数据，数据接口（DataInterface）用于CAN数据传输，LED请求接口（LedRequestInterface）用于LED 控制要求。使用SonarDataInterface和DataInterface进行通信时，使用表示距离的数据和无符号int数据类型的四个字节。使用LedRequestInterface进行通信时，该数据仅需要指示是否打开/关闭LED进行控制，因此使用了一个字节的布尔数据类型。在图4中，这些用于连接SWC原型的通信端口。通过将ECU中执行的操作分为五种功能来设计构成通信端口和内部行为的SWC：距离障碍物的距离测量，通过CAN总线的数据传输，警告级别判断，警告的LED控制和ECU 初始化。此外，为每个SWC配置了可运行文件（可执行文件）。设计的SWC提供了实例化SWC原型的结构。图4中显示了具有每个SWC原型的详细操作和连接的应用程序层。在已开发的碰撞警告系统中，SWC分为UltraSonic，CanTranslate，ObstacleDetection，LEDActuator和。UltraSonic将来自超声传感器的测量数据转换为以米为单位的距离数据。然后将计算出的距离数据发送到CanTranslate和ObstacleDetection进行进一步处理。接收到距离数据后，CanTranslate通过CAN通信堆栈将其中继到CAN总线。另一方面，ObstacleDetection根据从超声波接收的相同距离数据确定要控制的LED的颜色，并向LEDActuator发送信号。LEDActuator对所连接的LED进行实际控制，无论是YellowLED还是RedLED。ModeManagerInit将ECU控制信号发送到ecuM和bswM，并让BSW执行Ecu，Gpt（通用计时器）和通信初始化功能。通过这些操作，最终为SWC描述创建了.swcd和.sysd文件，并且还通过ECU导出生成了.arxml文件。

3.2.2 BSW configuration

为了提供SWC执行特定功能所需的服务，定义并配置了BSW中使用的模块。因此，超声波SWC需要计时器服务来测量数字I / O和超声波的返回时间。可以翻译需要的CAN通讯服务。由于障碍检测SWC不需要任何硬件资源，因此不需要BSW服务。另一方面，与硬件相关的SWC（例如，发黄和红色的LED）需要数字I / O服务。modeManagerInit所需的服务是ECU管理功能，用于执行ECU，计时器和通信的初始化。另外，任务创建和计划需要OS服务。Com，PduR，CanIf和Can connumodules用于实现CAN通信堆栈。CanSM模块用于实现CAN BUS的控制流程。使用了用于数字I / O控制的Dio，Port和IoHw Av模块；使用了用于定时器控制的GPT模块；ECUM，BSWM，MCU和ECUM模块用于系统管理；OS模块用于管理AUTOSAR任务的创建和调度。图5显示了执行SWC和BSW配置后的碰撞警告系统的分层结构。

3.2.3 BSW and RTE Generation

接下来的过程是生成RTE和BSW代码。RTE由前面小节中提到的SWC和BSW配置中的.arxml文件配置。RTE配置过程将实例化在SWC配置过程中配置的SWC原型，以便RTE可以将SWC识别为ASW层的一部分。实例化SWC原型后，可运行对象将映射到BSW配置中Os模块中配置的Task和Event。通过此过程，可运行的SWC映射到OS调度程序管理的任务，并在任务单元中调度。

碰撞警告系统中映射到SWC的任务在图4中以虚线显示。它们是OsObstacleDetectionTask，OsLEDTask，以及OsSonarTask，OsComTask。OsStartupTask通过调用EcuM_StartupTwo作为要执行的第一个任务来初始化BSW模块。该任务未映射，仅在执行OS时运行一次。OsBswServiceTask也未映射，它调用ComM，Com，EcuM，CanSM，Can和BswM模块的MainFunction，这些模块应定期调用以提供服务。该任务也未映射，并且由BSW Scheduler安排为每10毫秒以轮询方法运行一次。每20毫秒触发一次OsObstacleDetectionTask，并映射ObstacleDetection SWC原型中的可运行对象。每10毫秒触发一次OsLEDTask，并映射YellowLED和RedLED SWC原型中的可运行对象。每40毫秒触发一次OsSonarTask，并映射Ultrasonic SWC原型中的可运行对象。在SonarRecv端口接收到数据时触发OsComTask，并映射CanTranslate SWC原型中的可运行对象。

3.2.4. SWC Runnable Implementation

SWC的算法是在SWC配置过程中设计的。每个SWC都实现了一个.c文件，而可运行文件则实现为.c文件中的一个函数。通过引用作为RTE生成结果而生成的RTE合同文件中定义的API，可以实现SWC与其他SWC之间的通信，或者SWC与BSW之间的通信。

4. Experiment Results

根据上一节中提出的方法，进行了实验以验证开发的碰撞预警系统的运行情况。碰撞预警系统通过获取与超声波传感器的距离来进行操作，并根据电子设备2019、8、1025 10之18障碍物的测量距离来改变相应LED的状态。在本节中，我们将指定实验测试台的硬件和软件环境，在移动平台上验证开发系统的操作，并使用可视化软件V-REP可视化传感器数据。

4.1. Hardware Environment

在我们开发的系统中，我们将MPC574XG-324DS板与MPC5748G MCU用作ECU。USB Multilink Universal调试探针用于调试和软件上传。USB至CAN转换器用于通过CAN协议在PC和ECU之间进行通信。使用工具V-REP [23,24]可视化传输到PC的数据。超声波传感器用于测量碰撞预警系统中与障碍物之间的距离。红色和黄色的LED通知用户有关危险的危险。示波器用于识别CAN消息帧。完整的硬件环境如图6所示。

4.2. Software Environment

在本研究中，开源的AUSTOSAR设计基于ARCCORE的Arctic Core 21.0.0以及在Eclipse下运行的集成开发环境（IDE）Arctic Studio 21.0.0。要为MPC5748G MCU开发AUTOSAR软件，需要IDE支持的PowerPC架构的工具链。当前，支持的工具链是CodeWarrior，Diab和Greenhills。但是，CodeWarrior（恩智浦板卡的工具链）不支持MPC57xx系列MCU。因此，我们使用了NXP为PowerPC体系结构提供的“ S32 Design Studio for Power Architecture” IDE提供的工具链。

安装工具链后，将在Arctic Studio中配置用于构建AUTOSAR项目的环境变量。这些包括BOARDDIR，COMPLIER和CROSS_COMPILE。例如，BOARDDIR。COMPILER设置为“ gcc”以启用gcc交叉编译器的使用，并且CROSS_COMPILE定义工具链的安装目录。为了生成可以在目标板上操作的BSW的代码，在ECU信息和Arctic Studio的BSW编辑器的选项中找到的MCAL项设置为目标板的MCU MPC5748G。最后，安装了机器人模拟器V-REP PRO EDU，以可视化PC上ECU的行为。

4.3. Collision Warning System Operation Test

为了验证碰撞预警系统在实际环境中的运行，在将障碍物的距离从0.5 m移至2.0 m的同时观察了LED的变化。当距障碍物的距离小于1.0 m时，红色LED会亮起；当距障碍物的距离小于1.0 m且小于2.0 m时，黄色LED会亮起；如果距障碍物的距离超过2.0 m，则两个LED均保持熄灭。测试结果如图7所示，以0.5 m的增量显示了距碰撞警告系统的障碍物距离。一块瓷砖的大小为宽度0.5 m和高度0.5 m。通过这些结果，我们验证了碰撞预警系统的正常运行。

4.4. Sensor Data Visualization Using V-REP

在本节中，如前小节所述，执行V-REP可视化以可视地确认碰撞警告系统的操作和超声传感器的数据。图8显示了使用USB到CAN转换器通过主机PC的V-REP从ECU到CAN总线发送的超声传感器数据的可视化结果。为了与实际实验环境保持一致，将一块砖的宽度和高度均设置为0.5 m。超声波传感器安装在车辆的前部，障碍物的位置由蓝色圆盘指示。指示障碍物危险的LED由与实际硬件配置相同的红色和黄色组成。左侧的UI显示超声波传感器的数据，侧面视图和上方视图。我们确认蓝盘的移动和LED的状态根据ECU与障碍物之间的距离而变化。结果显示出与上一节中的实际实验相同的行为。

5. Performance Evaluation

由于开源AUTOSAR的性能尚未得到验证，并且缺乏对AUTOSAR开源分布进行基准测试的现有方法，因此，本节重点介绍已开发的冲突，以评估AUTOSAR通信堆栈的实时性能和延迟的指标。上一节中的警告系统。对Os任务进行了实时性能测试，以验证是否满足实时约束。具体来说，测量任务的周期性。由于通信堆栈是以分层方式实现的，因此这可能会增加任务的总体延迟，并可能影响实时性能。因此，我们还评估了每一层的延迟，并从软件计算了总延迟

5.1. Real-Time Performance

本节介绍了碰撞预警系统的实时性能评估[29,30]。AUTOSAR OS基于开放式系统及其用于汽车电子系统的接口（OSEK）OS，它是符合OSEK /车辆分布式执行程序（VDX）的实时操作系统，并支持基于优先级的抢占实时调度。功能[31]。为了验证AUTOSAR OS是否满足实时约束，评估了BSW OS模块中构造的任务的周期性。这用于确认系统是否显示确定性的行为和响应性，这对于系统的稳定性至关重要[29]。在RTE配置步骤中，将OS模块中配置的任务和事件映射到SWC的可运行对象。然后生成RTE源代码。其中，在Rte.c文件中实现了映射了任务，事件和可运行对象的源代码。Rte.c文件中实现的任务被重复执行，等待映射到任务的事件。发生映射事件时，将再次执行任务。使用此特性，通过测量从事件发生后立即到事件再次发生之间的时间，来检查AUTOSAR OS的实时属性。Tperiod代表一个任务周期花费的实际时间。Enow是映射到当前任务的事件发生的时间，而Eprev是之前发生的事件的时间。它与周期的关系由以下公式定义：

实验进行了30分钟，并评估了OS模块配置中的事件和可运行的映射任务OsLEDTask任务（τ1），OsObstacleDetectionTask（τ2）和OsSonarTask（τ3）的实时性能。τ1具有最高优先级，并在10 ms的Tcycle中执行。τ2具有中等优先级，并在20 ms的Tcycle中执行。τ3的优先级最低，并且以40 ms的Tcycle执行。Tcycle是实时任务的预期周期。表1总结了每个时序度量的统计平均值（avg），最大值（max），最小值（min）和标准偏差（σ）值。Tperiod表示完成一个任务周期的实际时间。它与抖动的关系由以下公式[32,33]定义：

结果表明，具有最高优先级的任务具有最佳性能，并且与周期和抖动的统计平均值的偏差最小。因此，可以确定AUTOSAR OS根据优先级和满足的周期性执行调度。

5.2. AUTOSAR Communication Stack

为了将实现ADAS的ECU应用于实际车辆，它必须能够与安装在车辆中的各种ECU通信。AUTOSAR提供了用于这些ECU之间通信的通信堆栈。通信堆栈是服务层，ECU抽象层和BSW层的MCAL中存在的通信相关模块的分层结构。Com和PduR模块用于服务层。Com模块控制通信传输，并将RTE中使用的信号转换为在通信堆栈中使用的交互层协议数据单元（I-PDU）。PduR模块根据指定的通信方法将从Com模块接收的I-PDU路由到ECU抽象层的接口（If）模块。

在ECU抽象层中，根据通信方法使用If模块。接口模块提供服务层PduR模块和MCAL通信驱动程序模块之间的接口，并初始化驱动程序模块。MCAL的通讯驱动程序模块控制ECU的通讯控制器。由于层次结构，从SWC传输以与另一个ECU的SWC通信的信号经过每一层，这会产生延迟。这会影响AUTOSAR的实时行为。因此，在AUTOSAR通信堆栈的每一层中消耗的等待时间都经过测量以考虑到这一点。

AUTOSAR通信堆栈的各层使用API​​来调用下一层，以将数据传输到下一层并请求数据处理。通过在API中安装Gpt模块提供的计时器来测量数据处理时间，该计时器会调用每一层中的下一层。通信堆栈源代码是由AUTOSAR开发工具基于BSW配置自动生成的，因此在BSW配置完成后将安装计时器。图9a是伪代码，它调用COM模块以使用RTE中的通信堆栈。调用Com_MainFunctionTx API时，将要传输的数据从COM模块顺序调用到驱动程序模块，该模块是通信堆栈的最低模块。图9b显示了在COM模块中完成数据处理之后，调用PduR_ComTransmit API将数据发送到下一层PduR模块的过程。图9a中测得的rte_latency是通信堆栈所有层的延迟之和，而图9b中测得的com_latency是COM模块下方所有层的延迟之和。因此，COM模块中的延迟是通过从rte_latency中减去com_latency获得的值。剩余的层使用相同的方法测量。

我们测量了碰撞预警系统中使用的CAN通信堆栈中每一层的延迟。通过在图10所示的例程中安装计时器来测量等待时间，该例程将数据从构成通信堆栈的层传递到下一层。该图说明了CAN通信堆栈每一层的等待时间以及将数据传递到下一层的例程。对通信堆栈中每层延迟的分析表明，SWC和RTE之间的数据交换具有较低的延迟，因为数据存储在共享结构中。Com模块将RTE中使用的信号转换为BSW通信模块中使用的I-PDU的信号。此任务确定要转换为字节序的字节数。碰撞警告系统使用32位Little Endian CAN消息。此数据转换操作在Com模块中消耗最多的时间，并测量出最长的延迟。在传输过程中，从SWC到CAN控制器的等待时间为36μs。

6. Conclusions

在本文中，提出了使用开源AUTOSAR开发ADAS的过程。使用开源AUTOSAR解决了该问题，以确保复杂ADAS软件的互操作性，可移植性和维护性。要使用AUTOSAR开发系统，必须首先选择开发解决方案。商业解决方案的开发过程定义明确，易于开发，但是很难获得许可证。开源解决方案很容易获得许可证，但是尚无确定的开发程序，因此用户难以开发。因此，需要为大多数工程师定义基于开源AUTOSAR的ADAS的详细设计过程。在这里，我们提出了一个开发过程，其中包括使用开源解决方案进行的设计，实现和评估。为了验证提议的程序，我们使用ARCCORE的开源AUTOSAR解决方案Arctic工具和配备了NXP MPC5748G MCU的MPC574XG-324DS板，为ADAS实现了简单的碰撞警告系统。进行了实时性能评估，传感器数据的可视化以及通信堆栈评估，以测试已实现的系统。我们确认所实现的系统满足了实时约束，并通过可视化验证了传感器数据。对于希望使用开源AUTOSAR从开发环境到实现和评估来开发更复杂的ADAS的工程师来说，本文将是一个有希望的结果。在[34]中，我们提供了用于碰撞预警系统的完整AUTOSAR和V-REP软件，其中列举了BSW模块及其用法。作者贡献：J.P.调查了这项研究的背景，介绍了使用开源AUTOSAR进行ADAS设计，过程和评估方法的过程，并进行了实验以验证提出的过程。

致谢：这项工作得到了韩国能源技术评估与规划学院（KETEP）资助的人力资源开发的支持

References

1. Lu, M.; Wevers, K.; van der Heijden, R.; Heijer, T. ADAS applications for improving traffic safety. In Proceedings of the 2004 IEEE International Conference on Systems, Man and Cybernetics (IEEE Cat. No.04CH37583), The Hague, The Netherlands, 10–13 October 2004; Volume 4, pp. 3995–4002. Electronics 2019, 8, 1025 17 of 18 2. Zou, Y.; Zhang, W.; Weng, W.; Meng, Z. Multi-Vehicle Tracking via Real-Time Detection Probes and a Markov Decision Process Policy. Sensors 2019, 19, 1309. [CrossRef] [PubMed]

3. Wusk, G.; Gabler, H. Non-Invasive Detection of Respiration and Heart Rate with a Vehicle Seat Sensor. Sensors 2018, 18, 1463. [CrossRef] [PubMed]

4. Galanis, I.; Anagnostopoulos, I.; Gurunathan, P.; Burkard, D. Environmental-Based Speed Recommendation for Future Smart Cars. Future Internet 2019, 11, 78. [CrossRef]

5. Hobert, L.; Festag, A.; Llatser, I.; Altomare, L.; Visintainer, F.; Kovacs, A. Enhancements of V2X communication in support of cooperative autonomous driving. IEEE Commun. Mag. 2015, 53, 64–70. [CrossRef]

6. Sun, Y.; Huang, W.L.; Tang, S.M.; Qiao, X.; Wang, F.Y. Design of an OSEK/VDX and OSGi-based embedded software platform for vehicular applications. In Proceedings of the 2007 IEEE International Conference on Vehicular Electronics and Safety, Beijing, China, 13–15 December 2007; pp. 1–6.

7. Kutila, M.; Pyykonen, P.; van Koningsbruggen, P.; Pallaro, N.; Perez-Rastelli, J. The DESERVE project: Towards future ADAS functions. In Proceedings of the 2014 International Conference on Embedded Computer Systems: Architectures, Modeling, and Simulation (SAMOS XIV), Agios Konstantinos, Samos, Greece, 14–17 July 2014; pp. 308–313.

8. Jo, K.; Kim, J.; Kim, D.; Jang, C.; Sunwoo, M. Development of Autonomous Car—Part I: Distributed System Architecture and Development Process. IEEE Trans. Ind. Electron. 2014, 61, 7131–7140. [CrossRef]

9. Jo, K.; Kim, J.; Kim, D.; Jang, C.; Sunwoo, M. Development of autonomous car—Part II: A case study on the implementation of an autonomous driving system based on distributed architecture. IEEE Trans. Ind. Electron. 2015, 62, 5119–5132. [CrossRef]

10. Martínez-Fernández, S.; Ayala, C.P.; Franch, X.; Nakagawa, E.Y. A Survey on the Benefits and Drawbacks of AUTOSAR. In Proceedings of the First International Workshop on Automotive Software Architecture—WASA ’15, Montreal, QC, Canada, 4–8 May 2015; pp. 19–26.

11. Fürst, S.; Mössinger, J.; Bunzel, S.; Weber, T.; Kirschke-Biller, F.; Heitkämper, P.; Kinkelin, G.; Nishikawa, K.; Lange, K. AUTOSAR–A Worldwide Standard is on the Road. In Proceedings of the 14th International VDI Congress Electronic Systems for Vehicles, Baden-Baden, Germany, 7–8 October 2009; Volume 62, p. 5.

12. Wozniak, E.; Tucci-Piergiovanni, S.; Mraidha, C.; Gerard, S. An Integrated Approach for Modeling, Analysis and Optimization of Systems whose Design Follows the EAST-ADL2/AUTOSAR Methodology. SAE Int. J. Passeng. Cars Electron. Electr. Syst. 2013, 6, 276–286. [CrossRef]

13. Melin, J.; Boström, D. Applying AUTOSAR in Practice: Available Development Tools and Migration Paths. Master’s Thesis, School of Innovation, Design and Engineering, Mälardalen University, Västerås, Sweden, April 2011.

14. Sun, B.; Huang, S.T. AUTOSAR Acceptance Test of Communication on CAN Bus. Master’s Thesis, Department of Computer and Information Science, Linköping University, Linköping, Sweden, November 2017.

15. Jansson, J.; Elgered, J. AUTOSAR Communication Stack Implementation with FlexRay. Master’s Thesis, Chalmers University of Technology, Gothenburg, Sweden, March 2012.

16. Kulatỳ, O. Message Authentication for CAN Bus and AUTOSAR Software Architecture. Master’s Thesis, Czech Technical University in Prague, Prague, Czech Republic, 2015.

17. AUTOSAR Methodology. Available online: https://www.autosar.org/fileadmin/user_upload/standards/ classic/4-2/AUTOSAR_RS_Methodology.pdf (accessed on 3 May 2019).

18. Chaaban, K.; Leserf, P.; Saudrais, S. Steer-By-Wire system development using AUTOSAR methodology. In Proceedings of the 2009 IEEE Conference on Emerging Technologies & Factory Automation, Palma de Mallorca, Spain, 22–25 September 2009; pp. 1–8.

19. Kumar, M.; Yoo, J.; Hong, S. Enhancing AUTOSAR methodology to a cotsbased development process via mapping to V-Model. In Proceedings of the 2009 IEEE International Symposium on Industrial Embedded Systems, Lausanne, Switzerland, 8–10 July 2009; pp. 50–53.

20. Sung, K.; Han, T. Development Process for AUTOSAR-based Embedded System. Int. J. Control Autom. 2013, 6, 10.

21. Hebig, R. Methodology and Templates in AUTOSAR; Technical Report; HassoPlattner-Institut für Softwaresystemtechnik: Potsdam, Germany, 2009.

22. MPC5748G EVB User Guide. Available online: https://www.nxp.com/files-static/microcontrollers/doc/user_ guide/MPC5748GEVBUG.pdf (accessed on 15 May 2019). Electronics 2019, 8, 1025 18 of 18

23. Freese, M.; Singh, S.; Ozaki, F.; Matsuhira, N. Virtual robot experimentation platform v-rep: A versatile 3d robot simulator. In Proceedings of the International Conference on Simulation, Modeling, and Programming for Autonomous Robots, Darmstadt, Germany, 15–18 November 2010; pp. 51–62.

24. Rohmer, E.; Singh, S.P.N.; Freese, M. V-REP: A versatile and scalable robot simulation framework. In Proceedings of the 2013 IEEE/RSJ International Conference on Intelligent Robots and Systems, Tokyo, Japan, 3–7 November 2013; pp. 1321–1326.

25. Naumann, N. Autosar Runtime Environment and Virtual Function Bus; Technical Report; Hasso-Plattner-Institut: Potsdam, Germany, 2009; p. 38.

26. AUTOSAR Layered Software Architecture. Available online: https://www.autosar.org/fileadmin/ user_upload/standards/classic/4-3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf (accessed on 26 August 2019).

27. Warschofsky, R. AUTOSAR Software Architecture; Hasso-Plattner-Institute für Softwaresystemtechnik: Potsdam, Germany, 2009.

28. Gosda, J. Autosar Communication Stack; Technical Report; Hasso-Plattner Institute fur Softwaresystemtechnik: Potsdam, Germany, 2009; pp. 13–23.

29. Delgado, R.; Park, J.; Choi, B.W. Open embedded real-time controllers for industrial distributed control systems. Electronics 2019, 8, 223. [CrossRef]

30. Koh, J.H.; Choi, B.W. Real-time performance of real-time mechanisms for rtai and xenomai in various running conditions. Int. J. Control Autom. 2013, 6, 235–246.

31. Anssi, S.; Tucci-Piergiovanni, S.; Kuntz, S.; Gérard, S.; Terrier, F. Enabling scheduling analysis for AUTOSAR systems. In Proceedings of the 2011 14th IEEE International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing, Newport Beach, CA, USA, 28–31 March 2011; pp. 152–159.

32. Delgado, R.; You, B.J.; Choi, B.W. Real-time control architecture based on xenomai using ros packages for a service robot. J. Syst. Softw. 2019, 151, 8–19. [CrossRef]

33. Delgado, R.; Choi, B.W. Network-Oriented Real-Time Embedded System Considering Synchronous Joint Space Motion for an Omnidirectional Mobile Robot. Electronics 2019, 8, 317. [CrossRef]

34. Park, J. Collision Warning System. Available online: https://github.com/qkrwoghsla12/ARCCORE-collisionwarning-system (accessed on 26 May 2019).