内容提要：在本文中，我们介绍了基于开源汽车开放系统架构 (AUTOSAR) 的高级驾驶辅助系统 (ADAS) 的详细设计和实现过程。首先，我们提供了使用开源AUTOSAR开发碰撞警告系统的完整细节。其次，由于开源软件的性能尚未得到证明，需要进行测试以确保系统的稳定性，我们提出了各种评估方法来衡量任务的实时性能和通信堆栈的整体延迟。

摘要

在本文中，我们介绍了基于开源汽车开放系统架构 (AUTOSAR) 的高级驾驶辅助系统 (ADAS) 的详细设计和实现过程。由于ADAS的软件复杂性不断增加，可移植性、组件互操作性和维护性正在成为必不可少的开发因素。AUTOSAR通过定义系统架构标准来满足这些需求。尽管AUTOSAR的商业发行版已经很成熟，但可访问性是一个巨大的问题，因为它们需要支付非常昂贵的许可费用。开源AUTOSAR解决了这个问题，还可以最大限度地降低总体开发成本。然而，开发程序还没有很好地建立起来，对工程师来说可能很困难。本文的贡献分为两个主要部分：首先，我们提供了使用开源AUTOSAR开发碰撞警告系统的完整细节。这包括AUTOSAR的简化基本概念，我们将其整理以便于理解。此外，我们还提出了对现有AUTOSAR开发方法的改进，重点是在每个开发阶段清晰地定义底层工具。其次，由于开源软件的性能尚未得到证明，需要进行测试以确保系统的稳定性，我们提出了各种评估方法来衡量任务的实时性能和通信堆栈的整体延迟。这些性能指标，与确认整个系统是否具有确定性行为和响应能力有关。评估结果可以帮助开发人员提高车辆系统的整体安全性。在集成了我们自主开发的碰撞预警系统的AUTOSAR评估套件上进行了实验。这些程序和评估方法不仅适用于检测障碍物，还适用于ADAS的其他变体，并且对于将开源AUTOSAR集成到各种车辆应用程序中非常有用。

1.简介

最近，随着交通量变得越来越复杂，出现了对高级驾驶员辅助系统(ADAS)的需求，以减少交通事故造成的危及生命的情况。ADAS使用传感器和电子设备来帮助驾驶员做出更好的决策。近年来，随着传感器和电子产品的显著进步，人们对ADAS的期望也大大提高。在这种情况下，已经进行了各种研究，涉及使用相机跟踪车辆，使用安装在车辆座椅上的传感器测量驾驶员的心率，根据天气、道路和车辆状况通知推荐车速，以及自动驾驶汽车之间的通信。随着ADAS的进步，底层软件变得更加复杂；互操作性、可移植性和可维护性成为关键要求。这些要求由汽车软件平台解决，例如开放系统及其汽车电子接口(OSEK)和AUTOSAR。

传统的OEM和ECU制造商使用各种没有统一标准的硬件和软件来开发车辆的ECU。由于没有统一的标准，ECU是在依赖硬件的结构中开发的，当硬件发生变化时需要创建新的软件。这样，开发的ECU软件的可重用性和可靠性比较低，增加了开发成本。为了解决这个问题，德国汽车公司联合启动了OSEK，旨在开发“汽车分布式电子控制单元的开放式架构的行业标准”。它提供了结合硬件和软件的标准接口，以便于开发和重用。然而，汽车系统复杂性的不断增加，导致了当前汽车开放系统架构（AUTOSAR）的发展。AUTOSAR旨在开发独立于硬件的软件，并且可以在ECU的不同组件中分发或重复使用。AUTOSAR通过运行时环境层将独立于硬件的应用软件与面向硬件的软件分开。在本研究中，我们专注于开发基于AUTOSAR的碰撞预警系统。

AUTOSAR开发解决方案分为商业版和开源版。在商用AUTOSAR解决方案中，供应商提供完善的开发方法论，从开发环境到开发工具实施。因此，在项目开发中使用起来相对容易，但许可成本较高。相反，开源解决方案可以降低开发成本，因为许可证是免费的，并且很容易获得。但是，文档和实施程序没有明确定义。有研究人员在AUTOSAR验收测试之后，构建了基于控制器局域网(CAN)总线的软件框架。同样，有研究人员使用AUTOSAR通信堆栈实现了FlexRay通信。两位研究人员都提供了通信堆栈的性能评估和所需的实施机制。然而，这些研究并未提供实际的汽车应用。另有研究人员提出了一种基于开源AUTOSAR的车辆座椅加热系统，并提出了消息认证控制器局域网(MaCAN)协议在车辆应用中的应用。然而，所有这些研究都只关注通信栈或特定应用程序的实现，没有考虑设计和实施程序。出于这个原因，工程师和从业者公认复杂性、学习曲线和糟糕的文档是开源AUTOSAR的缺点。
针对这些不足，本文旨在为从业者，尤其是初学者提供一个面向汽车应用的开源AUTOSAR设计与实现的全面参考。首先，我们组织了AUTOSAR的基本概念，以便更容易理解架构和每个基本组件。尽管AUTOSAR手册描述了大部分内容，但本研究提供了基于第一手经验的简化解释，这在实际实施中非常有帮助。此外，我们还建议改进基于开源AUTOSAR的现有开发方法。这侧重于定义每个开发阶段所需的底层工具，这对于为ADAS等复杂系统设计灵活且可重用的软件模块非常必要。

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

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

2.AUTOSAR基本概念

AUTOSAR是一个标准软件，由三个主要层组成：应用软件组件(ASW)、运行时环境(RTE)和基础软件(BSW)。每一层都模块化为各种软件组件，通过称为虚拟功能总线(VFB)的虚拟网络相互连接。图1显示了AUTOSAR的基本软件架构。

图1.简化的AUTOSAR软件架构

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

RTE层作为中间件，用于管理同一ECU的ASW层和BSW层之间的通信。无论通信是在ECU内部还是通过外部通信网络，RTE都提供相同的抽象接口，因此ASW层的SWC独立于BSW层的SWC。RTE层的VFB为客户端-服务器和发送方-接收方接口提供AUTOSAR通信机制，为SWC提供通信服务。VFB 是一个技术概念，它支持开发整个系统的功能架构，独立于ECU和网络的实际硬件拓扑。在图1中，SWC-1和SWC-2在ECU 1内通信，但在SWC-3到SWC-6 的情况下，通信在ECU 1和ECU 2的SWC之间执行。由于所有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中进行了详细介绍。

图2.详细的AUTOSAR软件架构

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

通信服务是一组模块，它们执行CAN、LIN和FlexRay等功能，通过统一接口向更高层提供通信。通信服务为通信网络管理提供服务，提供统一的接口，消除对下层的依赖。此外，它通过抽象的通信驱动程序访问通信驱动程序，具有独立于MCAL层通信驱动程序的结构。通信服务提供了一个统一的接口，消除了下层对各种应用程序和车辆网络诊断通信的依赖，使得应用程序的开发无需考虑协议和消息属性。在内部，有网络管理器（NM）、状态管理器（SM）和通信网络的传输协议（TP），例如CAN、LIN和FlexRay。此外，还存在通信（Com）和协议数据单元路由器（PduR）等模块。在图2中，服务模块分组CAN状态管理器（CanSm）、CAN网络管理器（CanNm）、CAN传输协议（CanTp）、FlexRay状态管理器（FrSm）、FlexRay网络管理器（FrNm）、FlexRay传输协议（FrTp）、通信服务中提供了LIN状态管理器(LinSm)和LIN传输协议(LinTp)。

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中，端口、用于数字输入/输出(DIO)的Dio、用于脉宽调制(PWM)的Pwm和用于模数转换器(ADC)模块的Adc都包含在I/O硬件抽象中。

微控制器抽象层(MCAL)是BSW的最底软件层。为了避免在高层软件中直接访问单片机寄存器，对硬件的访问是通过MCAL设备驱动来完成的，它包括ADC、PWM、DIO、EEPROM、Flash等硬件相关的驱动。对微控制器寄存器的访问通过MCAL路由，这使得上层软件层独立于微控制器。根据功能，微控制器驱动程序、内存驱动程序、通信驱动程序和I/O驱动程序被分类。这为设备及其与微控制器的连接提供了应用程序编程接口(API)。

3.基于开源AUTOSAR的碰撞预警ADAS

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

3.1.设计方法论

现有的AUTOSAR开发方法学很难明确开发过程，因为没有明确定义每个开发阶段的底层工具。对于商用AUTOSAR来说，这不是问题，因为提供解决方案的厂商提供了详细的手册，但由于开源的AUTOSAR没有明确的开发方法论，给开发者带来了很多挑战。在本文中，提出了使用开源AUTOSAR进行开发的专门程序。现有的AUTOSAR开发过程已重新配置为五个阶段。使用ARCCORE的开源AUTOSAR开发解决方案的建议过程如图3所示。

图3.开源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的可运行性。通过这个过程，SWC的可运行程序在AUTOSAR操作系统中进行调度和执行。RTE配置完成后，生成RTE和RTE合同文件，使用RTE编辑器提供的生成功能连接BSW和ASW。在RTE合同文件中，定义了用于调用ASW层应用程序中BSW层提供的服务的API。最后，使用BSW编辑器提供的generate函数生成BSW代码。

步骤4：可运行程序是一个定义SWC的函数，它是用C语言创建的。可运行是指RTE合同文件，它定义了通过执行步骤3生成的RTE进行通信的API。

步骤5：构建步骤3和4生成的源代码和头文件，并用于生成将在ECU上运行的可执行文件。MCU的工具链和环境变量被指定，并在ECU中使用。这些都是在Arctic Studio中进行的。

3.2.设计碰撞警告系统

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

3.2.1. SWC配置

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

图4.碰撞警告应用层概览

构成通信端口和内部行为的SWC是通过将ECU中执行的操作分为五个功能来设计的：到障碍物的距离测量、与CAN总线的数据传输、警告级别判断、用于警告的LED控制和ECU初始化。此外，还为每个SWC配置了runnable（可执行文件）。设计的SWC提供了一个用于实例化SWC原型的结构。每个SWC原型的应用层详细操作和连接如图4所示。在开发的碰撞预警系统中，SWC分为UltraSonic、CanTranslate、ObstacleDetection、LEDActuator，以及UltraSonic将超声波传感器的测量数据转换为以米为单位的距离数据。计算出的距离数据，然后传输到CanTranslate和ObstacleDetection进行进一步处理。在接收到距离数据后CanTranslate通过CAN通信堆栈将它们中继到CAN总线。另一方面，ObstacleDetection根据从UltraSonic接收到的相同距离数据，确定要控制的LED的颜色，并向LEDActuator发出信号。LEDActuator执行连接的LED的实际控制，无论是黄色LED还是红色LED。ModeManagerInit将ECU控制信号传输到ecuM和bswM，并让BSW执行Ecu、Gpt（通用定时器）和通信初始化功能。通过这些操作，最终生成SWC描述的.swcd和.sysd文件，并通过ECU导出生成.arxml文件。

3.2.2. BSW配置

为了提供SWC执行特定功能所需的服务，定义和配置了BSW中使用的模块。在这种情况下UltraSonic SWC需要定时器服务通信服务。由于ObstacleDetection SWC不请求任何硬件资源，因此不需要BSW服务。另一方面，与硬件相关的SWC（例如黄色LED和红色LED）需要数字I/O服务。ModeManageInit所需的服务是ECU管理功能，用于执行ECU、定时器和通信。此外，任务创建和调度需要OS服务。Com、PduR、CanIf和Can模块用于实现CAN通信栈。CanSM模块用于实现CAN总线的控制流程。Dio、Port和IoHwAb模块用于数字I/O控制；定时器控制使用Gpt模块；EcuM、BswM、Mcu、EcuC模块用于系统管理；Os模块用于管理AUTOSAR任务的创建和调度。图5显示了执行SWC和BSW配置后碰撞警告系统的分层结构。

图5.分层碰撞警告系统架构

3.2.3. BSW和RTE生成

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

碰撞警告系统中映射到SWC的任务在图4中显示为虚线。它们是OsObstacleDetectionTask、OsLEDTask和OsSonarTask、OsComTask。OsStartupTask通过调用EcuM_StartupTwo作为要执行的第一个任务来初始化BSW模块。此任务未映射，仅在执行OS时运行一次。OsBswServiceTask也是没有映射的，调用ComM、Com、EcuM、CanSM、Can、BswM模块的MainFunction，这些是BSW模块，应该周期性调用提供服务。该任务也未映射，由BSW调度器调度为每10毫秒以轮询方式运行一次。OsObstructDetectionTask每20毫秒触发一次， 并映射ObstacleDetection SWC原型中的可运行对象。OsLEDTask每10毫秒触发一次，并映射黄色LED和红色LED SWC原型中的可运行对象。OsSonarTask每40毫秒触发一次，并映射超声波SWC原型中的可运行对象。OsComTask在SonarRecv端口接收到数据时被触发，并且 CanTranslate SWC原型中的可运行对象被映射。

3.2.4. SWC可运行实现

SWC的算法是在SWC配置过程中设计的；为每个SWC实现一个.c文件，并且runnable在.c文件中实现为一个函数。参考RTE生成后生成的RTE合约文件中定义的API，实现了一个SWC与其他SWC或SWC与BSW的通信。

4.实验结果

根据上一节中提出的方法进行了实验，以验证所开发的碰撞预警系统的运行情况。碰撞警告系统通过获取超声波传感器的距离来运行，并根据测量到的障碍物距离，相应LED的状态发生变化。在本节中，我们指定了实验平台的硬件和软件环境，验证了开发系统在移动平台上的运行，并使用可视化软件V-REP可视化传感器数据。

4.1.硬件环境

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

图6.硬件环境

4.2.软件环境

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

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

4.3.碰撞警告系统操作测试

为了验证碰撞预警系统在真实环境中的运行情况，在障碍物距离从0.5米移动到2.0米时观察LED的变化。当与障碍物的距离小于1.0 m时，红色LED亮起，当距离障碍物在1.0 m和小于2.0 m之间时，黄色LED亮起，如果距离障碍物超过2.0 m，两个LED均保持熄灭。测试结果如图7所示，以0.5 m的增量显示障碍物与碰撞警告系统的距离。一格瓦片的尺寸是宽0.5m，高0.5m。通过这些结果，我们验证了碰撞预警系统的正常运行。

图7.检测距离时的状态

4.4.使用V-REP的传感器数据可视化

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

图8.探测距离为：(a) 0.5 m；(b) 1.0 米；(c) 1.5 米；(d) 2.0 米

5.绩效评价

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

5.1.实时性能

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

实验进行了30分钟，并针对OsLEDTask任务(τ1)、OsObstacleDetectionTask (τ2)和OsSonarTask (τ3)评估了实时性能，这些任务是OS模块配置中的事件和可运行映射任务。τ1具有最高优先级并在10毫秒Tcycle内执行。τ2具有中等优先级并以20毫秒的Tcycle执行。τ3的优先级最低，以40毫秒的Tcycle执行。Tcycle是实时任务的预期周期。结果总结在表1中，其中包含每个时序指标的统计平均值(avg)、最大值(max)、最小值(min)和标准偏差(σ)值。Tperiod表示一个任务周期实际花费的时间。它与抖动的关系由下式定义：

表1.碰撞预警系统中使用的任务周期的统计分析

结果表明，具有最高优先级的任务具有最好的性能，并且与周期和抖动的统计平均值的偏差最小。因此，确认AUTOSAR OS按照优先级和满足的周期性进行了调度。

5.2. AUTOSAR通信堆栈

为了将实现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模块中的latency就是rte_latency减去com_latency得到的值。使用相同的方法测量其余层。

图9.用于测量通信堆栈延迟的伪代码：(a)从Com模块到Driver模块；(b)从PduR模块到Driver模块

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

图10.每层中的AUTOSAR控制器局域网(CAN)通信堆栈延迟

6.结论

在本文中，介绍了使用开源AUTOSAR开发ADAS的过程。它是使用开源AUTOSAR来解决的，以确保复杂ADAS软件的互操作性、可移植性和维护性。要使用AUTOSAR开发系统，必须首先选择开发解决方案。商业解决方案的开发流程定义明确，易于开发，但很难获得许可。开源解决方案很容易获得许可，但没有既定的开发程序，用户很难进行开发。因此，需要为大多数工程师定义基于开源AUTOSAR的ADAS的详细设计流程。

在这里，我们介绍了一个开发过程，包括使用开源解决方案的设计、实施和评估。为了验证建议的程序，我们使用ARCCORE的开源AUTOSAR解决方案Arctic工具和配备NXP MPC5748G MCU的MPC574XG-324DS板，为ADAS实施了一个简单的碰撞警告系统。执行实时性能评估、传感器数据可视化和通信堆栈评估以测试已实施的系统。我们确认实施的系统满足实时约束并通过可视化验证传感器数据。对于想要使用开源AUTOSAR开发更复杂的ADAS的工程师，从开发环境到实施和评估，这篇文章是一个有希望的引导。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！