目前，汽车行业的技术发展正在加速增长。诸如自动驾驶和Car2X等新趋势要求对交互环境有详细的了解。因此，车辆之间以及与周围环境之间的联系越来越紧密。它们的功能通过智能软件模块得到增强，有助于增加车辆的性能。在自动驾驶的情况下，需要专门的传感器，以便有效实现整个车辆360°环境识别。鉴于操作条件的复杂性，高级驾驶辅助系统（ADAS）出现了，可以用以减少运作期间可能出现的危及生命的情况。
高级驾驶辅助系统是一个基于车辆的智能安全系统，在道路和交通安全方面为驾驶员提供支持。该模块通过部分和完全取代驾驶员的行为来监控、警告甚至控制车辆。虽然ADAS的形式多种多样，但它们都有一个共同的目的: 使驾驶体验更安全、更舒适。ADAS市场的构建考虑到了组件类型及其使用区域。第一类包括系统和传感器类型。系统类型细分为盲点物体检测系统、胎压监测系统、睡意监测系统、自适应巡航控制系统、自适应前照灯系统、智能停车辅助系统、夜视系统、车道偏离警告系统和驾驶员监控系统。
传感器类型类别包括雷达、图像传感器、超声波传感器、LiDAR传感器、红外传感器和激光。先进的驾驶辅助系统应用，如车道偏离警告系统和自适应巡航控制、夜视或盲点探测系统的实施，大大减少了汽车事故的数量。根据新车碰撞测试（NCAP）的政策现代汽车必须证明达到特定的安全等级，以鼓励在最先进的汽车设计中进行重大安全改进。关注道路安全的政府机构在这方面提供了额外的支持。所有这些工业、社会和公共方向都有望在未来催生高级驾驶辅助系统市场的增长，这需要优化的通信实现。
现代化的传感器，如超声波和激光传感器（LiDAR 传感器），当然还有环视摄像头，可确保安全距离识别，此外还可以识别驾驶环境。（中央）控制单元处理数据并将其转换为信号、视觉信息，甚至主动反应。如今，这些行动通常以数字方式发生，并在几分之一秒的时间内完成。由于现有系统的多样性和不同制造商提供的所有单独解决方案，不可能就哪种传感器系统或传感器系列适合用于任何特定的应用做出一般性声明。汽车制造商在所有不同车型中都使用了最多样化的驾驶员辅助系统、实用组合和新技术。传统上，电子控制单元（ECUs）是以硬件相关的范例开发的，考虑到了硬件设置的具体架构组件。这种方法需要为每次硬件升级创建新软件。多年来，由于硬件限制，汽车行业的新产品开发周期一直在放缓。此外，这降低了软件的可靠性和可重用性。因此，几家德国汽车原始设备制造商（OEMs）启动了机动车开放系统和电子技术（OSEK）和汽车开放系统架构（AUTOSAR）计划，以制定 "汽车分布式电子控制单元的开放式架构的行业标准"。AUTOSAR 旨在通过提供独立于硬件的应用软件来提供标准接口，这些应用软件可以通过运行时环境层分布在车辆 ECU 的各个组件中。
随着汽车行业向智能系统和自动驾驶的快速发展，AUTOSAR 平台是克服可扩展性和互操作性挑战的解决方案之一。自动驾驶需要大量的传感器，因此增加了网络参与者的数量和需要处理的关键数据。这就是为什么通信流量变得更加复杂的原因 ，也是因此才需要研究应用于 AUTOSAR 层面的优化方法。我们研究了在 AUTOSAR 层面上优化大数据传输的可能性。根据我们查阅的文献综述，这种特殊的方法尚未在科学文献中有详细讨论。在之前的工作中, 我们尝试探索类似解决方案的设计和实现。当前提案的发现和结果侧重于通过描述所使用的方法、技术硬件和软件实现、测试程序、经验教训和局限性，为具有类似特征的进一步项目提供新的科学见解。
面对Covid-19爆发的全球危机，汽车行业正在为嵌入式系统应用引入新的测试程序，如远程测试。在这种情况下，特定的设备形成了复杂的测试实验室，可以在任何距离和任何时间访问这些实验室。我们的研究是基于想在处理雷达传感器时提供这种解决方案。
基于上述观察，本文的研究问题表述如下：(RQ1) 构建AUTOSAR通信优化所需的解决方案; (RQ2) 构建远程测试架构和环境，用以访问和测试 AUTOSAR 级别的优化; (RQ3) 在性能和运行时间测量方面分析我们的系统，以便就我们的解决方案提供明确的科学结果，使研究人员在未来具有类似特征的工作中受益。
本文的其他部分：第2节介绍了AUTOSAR的基础知识，随后的第3节包含了AUTOSAR和雷达传感器优化以及AUTOSAR测试的文献回顾。接下来，在第4节中介绍了系统结构和三个主要特点：AUTOSAR优化解决方案，以远程方式访问雷达传感器，以及性能测试模块的实现。本文的下一部分，即第5节，介绍了我们进行的实验和获得的结果，而第6节则是我们的研究的结论。
汽车开放系统架构（AUTOSAR）成立于2003年，是一个由汽车制造商组成的全球开发合作联盟。该联盟的目标是为汽车ECU创建和建立一个开放、稳健和标准化的软件架构。这种设计包括对各种车辆和平台变体的可扩展性和软件的可移植性，一切以可用性、可靠性和安全要求为基础。它还旨在维护基于预定义的“产品生命周期”的开发过程。
AUTOSAR的开发过程 (图 1) 是在以下软件层中实现的。MCAL（微控制器抽象层）、基本软件层（BSW）、运行时环境（RTE）和应用层。运行时环境（RTE）的作用是将网络与应用程序的软件组件（SWC）解耦，并以基本软件（BSW）的形式提供统一服务，如系统和诊断服务、总线通信、IO访问和内存管理。BSW通信栈由服务层、ECU抽象层和微控制器抽象层（MCAL）组成。AUTOSAR通信栈 (图 2) 为BSW模块以及应用层提供通信服务。
图 1 AUTOSAR 架构
图 2 总线通信栈
通信（COM）模块位于RTE和PDU路由器之间，负责提供对应用层所需信号的访问。它还提供独立于所使用协议的对较低层的PDU级别访问。在发射器端，它将把所有的信号打包成一个PDU，而在应用端将把收到的PDU解包，以便为应用提供信号电平访问。
协议数据单元路由器（PduR）模块是服务层的一部分，将把PDU路由到特定的总线接口模块。它为以下模块的PDU路由提供服务: 传输协议模块；通信接口模块；诊断通信管理器（DCM）和传输协议模块；COM和通信接口模块或I-PDU复用器；IPDU-复用器；和通信接口模块。
通过总线传输协议（TP）模块可获得的基本服务是：对那些有效载荷超过8字节的信息进行分段，在流控制下传输信息，并在接收器处重新组装分段信息。总线状态管理器(SM)模块将为相应的总线实现控制流。总线网络管理器(NM)模块的目的是管理网络的正常运行模式和总线休眠模式之间的转换。总线接口模块是ECU抽象层的一部分，作为硬件抽象层（最低层）和服务层（总线接口模块以上）之间的接口。外部总线驱动程序为上层服务提供总线特定的收发器访问。
由于现代ECUs中存在各种复杂的模块化嵌入式软件组件，在实现软件功能时，必须达到不同的汽车安全完整性等级(ASIL)。ASIL是由ISO 26262-道路车辆-功能安全标准定义的，作为软件功能实现的属性，例如，在嵌入式系统中。ASIL被提出，作为对开发中的产品进行威胁分析和风险评估的结果，表明软件功能必须实现的质量等级。ECU软件可以由安全相关和非安全相关的组件组成；因此，必须考虑到不同的ASIL等级。在这种情况下，ISO 26262标准规定，要么在开发阶段必须遵循最高的ASIL等级，要么具有较低ASIL等级的软件组件必须与具有较高ASIL等级的组件实现接口自由。
为了确保各种软件组件之间所需的接口自由度，已实施AUTOSAR功能安全机制，以防止、检测和减轻可能出现的软件和硬件故障。ISO 26262 标准定义了诸如内存、时序、信息交换和执行等故障组。例如，通过将操作系统应用程序存储在不同的内存区域，AUTOSAR OS系统允许为内存故障提供接口自由。因此，在代码执行过程中，内存分区可以保护操作系统应用程序免受其他应用程序的影响。除了功能安全机制外，AUTOSAR的其他各种功能安全措施也支持安全相关软件的开发。
在与质量相关的相同背景下，汽车软件过程改进和能力确定（ASPICE）旨在评估一个组织的软件开发过程性能，并强调软件开发的基础实践。也就是说，ASPICE被定义为汽车OEM应用的框架，用于确定和评估汽车行业的软件开发过程。在不考虑安全方面的情况下，ASPICE可以确定一个组织的软件产品交付能力。然而，为了确保安全相关的要求，该组织必须证明其符合ASPICE和ISO 26262。ASPICE 涵盖了整个开发过程，提供了实现功能安全标准ISO 26262所需的框架。为了更好地理解两者之间的联系，ISO 26262可以被看作是ASPICE从功能安全角度定义的软件开发的延伸。即使ASPICE和ISO 26262标准在许多方面是不同的，但在工作产品的可追溯性和变更管理等方面仍然可以找到相似之处。
本节介绍了有关我们论文的主要议题、AUTOSAR通信和优化以及AUTOSAR测试的最新文献。
3.1 AUTOSAR 通信
在Anna Arestova等人的工作中，他们解决了通信挑战，并提出了AUTOSAR自适应平台、名为开放平台通信统一架构（OPC UA）的机器对机器通信技术和时间敏感网络（TN）的整合方法。通过结合使用TSN和OPC UA，通信开销大大减少，实现了各种设备之间的灵活通信。
然而，只有当数据流是安全的，通信优化才是可靠的。Cinzia Bernardeschi等人提出了一种方法来检查带安全注释的AUTOSAR模型中的数据安全流。这种方法是基于对信息流的分析和抽象的解释。他们的研究工作旨在提高汽车通信的安全性，因为最近的研究认为，入侵者可以破坏现代汽车电子系统的可操作性。他们定义了解决网络安全相关要求的AUTOSAR建模扩展，同时开发了一个代码生成工具，该工具综合了要使用的适当服务。事实证明，这些自动生成的安全组件极大地减少了开发阶段的常见错误。遵循相同网络安全路径， Pietro Biondi 等人提出了TOUCAN协议的概念验证。该安全协议遵循AUTOSAR标准，旨在确保控制器区域网络通信的安全。因此，该协议的目标是建立CAN帧的安全通信。该团队学者认为，TOUCAN为CAN通信增加了安全性，同时对运行时间的影响可以忽略不计。在专业的汽车环境外测试该协议，进一步证明了TOUCAN协议的易用性。Haichun Zhang等人的另一项研究强调了CAN总线协议的脆弱性。为了评估安全风险，我们提出了一个模拟恶意攻击的车载CAN安全评估工具--CANsec。此外，即使在没有提供车辆制造商信息的情况下，作者也证明了CANsec的作用。
汽车行业电子控制单元对计算能力的高需求催生了一种新的解决方案，以取代广泛使用的单核处理器。因为具有更高的计算能力和能源效率，多核电子控制单元的使用迅速增加。因此，很多研究提出了基于AUTOSAR标准的优化方法。为了最小化通信成本，Priyanshi Gupta等人提出了一种算法，用于在多核汽车嵌入式系统中高效映射AUTOSAR 可运行项。该解决方案旨在解决AUTOSAR定期运行项和任务的数据依赖所产生的通信开销，试图将可运行项从单核映射到多核。该算法是同质多核系统的一个可能解。针对多核电子控制单元可运行到任务映射的优化问题，Thomas Wilhelm和Raphael Weber提出了一个解决方案自动化两个流程步骤，其中优化了可运行任务映射的初始步骤和AUTOSAR平台中的优化步骤。通过使用约束编程，可以自动化平衡核心利用率，同时作者使用了进化算法来优化已经存在的配置。该论文还展示了AUTOSAR的隐性设计约束如何影响进化算法的建模。为了减少AUTOSAR中的繁忙等待，Robert Hottger等人提出了一个基于任务-释放-Delta的可运行重新排序(TDRR)的概念。为了减少任务响应时间，提高并行效率，改善时序可预测性，对一些AUTOSAR可运行项进行重新排序。他们的工作通过使用TDRR来执行具有不同离线计算可运行顺序的任务，成功地完全应用于AMALTHEA模型。此外，工业用例的实验证明了该解决方案能够通过减少任务响应时间来提高系统性能。在此基础上, Sebastian Kehr 等人提出了一种延迟感知的并行化技术Parcus，它结合了可运行项和任务级并行。该技术被用于AUTOSAR遗留应用程序的进行稳健和具有能源感知的并行。此外，还提出了一种进化算法，以探索大量的调度可能性。考虑到延迟和处理器频率，并行调度质量指标对并行化的成功与否进行了量化。作者用一个真实的柴油发动机管理系统证明了Parcus技术的适用性。
优化机会可以出现在任何方向，Qingling Zhao等人证明了这一点，在他们的论文中，优化了具有混合临界调度和抢占阈值的AUTOSAR模型的设计。由于混合临界嵌入式系统的可调度性分析的发展，他们提出了两种算法，PA-DMMPT 和 HeuPADMMPT。这两种算法旨在以最小化系统堆栈内存使用量的方式分配调度参数。使用随机生成的混合临界可运行集进行性能评估，结果表明该方法可以显著降低系统内存堆栈的使用。针对符合AUTOSAR标准的相同系统，Nesredin Mahmud等人的目标是优化容错嵌入式软件应用程序的分配。他们所提出的优化基于一个整数线性编程模型，该模型在考虑到强加的时序和可靠性要求的情况下，使系统的总功耗最小。合成汽车应用程序评价结果表明，该优化方法可有效地应用于中小型分布式容错应用，但不适用于复杂应用。
为了实现对车载故障诊断系统的离线分析，Shilpa Raju等人提出了一种机制，用于建立车辆上记录的故障数据的时间关系。由于车辆网络由异构的ECU组成，每个ECU都有自己的本地时间，因此故障数据的关联会导致不一致的结果。作者提出了一个同步的全局时间基准，为整个车辆网络的公共时间戳提供了一个解决方案。在一个实际的硬件设置上进行的测试成功的实现了时间从站和时间主站之间的时间同步。
3.2 AUTOSAR 测试
随着现代汽车上安装的软件组件数量的增加，软件故障导致严重后果的概率也在增加。这些组件由数百万行需要充分测试的代码组成。为了测试AUTOSAR架构中的这些软件组件，测试人员采用了硬件在环模拟。然而，这些模拟有其自身的局限性，因为软件组件不能在早期阶段进行测试。针对汽车行业的功能安全，Jihyun Park和Byoungju Choi强调了基于AUTOSAR的软件故障注入测试的重要性。这两位学者提出了一种故障注入的方法，并定义了可能发生的软件故障类型。这些故障可能是由于不同AUTOSAR层之间的调用关系而引起的。该方法应用软件开发过程中，可以注入基于AUTOSAR的汽车软件的各种故障。此外，该解决方案是作为ASFIT实现的，并与现有的故障注入方法进行了比较。一家韩国汽车公司进行了一项实证研究，证实了该方法的卓越性。Kazuto Shigihara等人指出AUTOSAR实时操作系统模块的测试面临不同的挑战，并引入了测试程序生成器来解决这些问题。测试AUTOSAR操作系统的面临挑战之一是需要大量的测试案例，从而导致的执行耗时。在他们的研究中，阐明了更深层的挑战，并引入了一种新的测试程序生成器。此外，为了解决非信任操作系统应用程序的约束，他们开发了一个测试库。通过对AUTOSAR操作系统的商业实现进行的测试，证明了该方法的有效性。
针对 AUTOSAR 中软件在环的测试技术的差距，Sooyong Jeong 和 Woo Jin Lee提出了一种自动化测试技术。由于涉及到闭环控制和反馈机制，所以还没有使用SiL模拟测试AUTOSAR组件的自动化技术，因而手动测试盛行。为了使用作为现有SiL模拟器集成的自动测试模块，可以通过测试用例转换方法，将包括闭环的测试用例转换为时间形式。通过实例分析，验证了他们所提出的自动化测试方法的效率和效果。按照类似的方法，Andrija Mihalj等人提出了一个现有的高级驾驶辅助系统环境测试系统，该系统在AUTOSAR架构的中间层为通信模拟创建了一个测试环境。该系统创建的生成器和测试环境被用来测试控制单元之间的通信。测试环境发生器实际上是一个基于Python的程序，用于处理ARXML。此外，通过使用不同的测试环境发生器配置，可以对ADAS系统的性能进行定性检查。拟议的测试环境生成器由解析器、数据存储器和生成器组成。然而，他们所进行的这些测试强调了未来工作的重要性，即需要加快执行时间并引入稳定的数据存储方法。
3.3 AUTOSAR远程测试
现代汽车日益增强的连接性可以被视为汽车工业最令人瞩目的方面之一。同时，通信技术的发展为物联网的发展提供了巨大的潜力。AUTOSAR的存在结合将这两个机遇结合到一起，提供了将现有物联网技术整合到现代汽车的机会。Marko Dragojevic´ 等人提出了一种利用物联网技术远程诊断现代车辆的方法。他们使用已经存在的物联网技术来加强汽车中间件--自适应AUTOSAR，以实现远程诊断和监测。该团队所提出的架构演示了如何利用简化的功能，将物联网轻松集成到自适应AUTOSAR中。该研究的结论是，他们的解决方案会产生一定的开销。然而，他们研究的目的是为了说明当前物联网技术在汽车行业的可行性。为了升级基于物联网解决方案的软件， Stevan Stevic´ 等人介绍了他们将物联网技术与自适应 AUTOSAR 平台结合的解决方案。该解决方案包括软件架构升级、基于物联网技术的云连接以及自适应AUTOSAR堆栈的扩展。他们所选择的物联网技术是OBLO，用作系统的后端部分，其允许对现代车辆进行空中更新(OTA)。新的自适应AUTOSAR平台与OBLO结合，针对解决有关更新昂贵和更新缓慢的问题。
随着越来越多的雷达解决方案被引入到汽车应用中，我们需要验证这些方案符合标准，并确保性能。在Carlos Junio Rocha等人的论文中，他们提出了一种自动化的方法，可以在各种雷达装置的生产单位进行空中测试和验证。该方法不仅涵盖了通过/失败条件，而且还可用于确定雷达天线阵辐射图。他们所展示的研究结果说明了在清洁和屏蔽的消声环境中进行测试的重要性。Patrick Pelland等人提出了汽车测试环境中遇到的一些独特挑战。该团队学者指出，传统的空中技术不足以测试复杂的系统，如现代汽车。他们的论文结语表示，下一代汽车天线测量系统将用于空中测试和天线模式测量。未来，这些设施将配备定位系统，适用于带有 OTA 测试设备的车辆，以帮助与相关的无线系统进行通信。Philipp Berlt等人强调了开发新的测试程序的重要性，因为如果射频端口无法访问，现有的测试程序就无法执行。无线信息和车辆运行状态之间的关系也突出了这一点。
Sreehari Buddappagari 等人在他们的论文中介绍了一个基于空中方法的完整测试系统，用于汽车雷达系统的安装性能评估。由于雷达系统是自主和互联驾驶技术的最重要的部分之一，其功能性能必须得到彻底验证。但这种方法消耗资源较多，相关风险较大。这项工作利用了一个示范性的交通场景，以验证整个实施系统的性能。进行的测试取得了良好的效果，其模拟结果与预期结果相似。同样，Sreehari Buddappagari和hJayapal Gowdu等人将77GHz雷达视为自动驾驶的关键驱动力，并进一步强调了传统测试的资源消耗，因为传统测试必须由真实的测试驾驶员驾驶覆盖数百万公里的路程。该团队所提出的解决方案旨在通过使用硬件在环模拟虚拟雷达环境来增强真实的现场测试。该解决方案允许在车辆上安装待测雷达的情况下，模拟车辆各互联子系统的响应行为。空中方法允许在无需修改的情况下操作雷达传感器，而虚拟环境有助于测试同一雷达传感器的正确操作。该团队成功地创建了一个整体的、可重复的、可靠的、可扩展的端到端测试概念。Michael Gadringer等人撰写的文章模拟器的开发过程，该模拟器负责生成虚拟雷达目标，以测试雷达传感器。正如之前的文章中所述，强调了广泛使用的道路测试的风险及其他相关风险和资源消耗。雷达目标模拟器和负责生成模拟器输入参数的软件已经被开发出来。该测试台用于车辆在环测试，以模拟其在道路上的测试公里数。雷达目标模拟器的性能在实验室和滚筒试验台上都得到了验证。此外，这些学者对雷达传感器潜在的未来发展进行了概述，指出这些趋势将对他们研究的雷达目标模拟器系统产生巨大影响。
另一方面，Nils Hirsenkorn 及其团队讨论了模拟精度和虚拟传感器的真实性的重要作用。他们的论文描述了一个汽车雷达传感器的模拟方法，从波的传输开始，一直到中频信号。为了获得高保真度，天线功率图、反射和光线发散都有考虑在内。最后，该模型被部署在虚拟试驾中，这是一个详细的驾驶模拟器，能够呈现与现实测试类似的结果。为了给空中雷达传感器测试提供低杂波环境，Muhammad Ehtisham Asghar等人经过初步分析，提出了一种最佳吸收器配置。为了检测测试设施中的杂波和不需要的散射，该学者利用了可编程的雷达手册和具有熟知的参考雷达传感器。通过对不需要的反射进行出色的检测，证明了所提方法的效率。
3.4 雷达优化
由于雷达传感器在安全驾驶体验中发挥重要作用，快速发展的汽车行业利用这些传感器，来提高对移动目标的检测能力。然而，高分辨率的雷达传感器和LiDAR导致了一个扩展的目标跟踪问题。Karl Granstrom 等人强调了当每个被跟踪目标有多个检测时面临的问题。他们在论文中提出了一种随机优化方法，在一个步骤中解决了这个问题，并使所需的可能性最大化。基于采样的方法在用Velodyne数据进行的实验中得到了证实，表明所提出的过滤器优于以前的任何其他方法。此外，该解决方案不依赖多种算法，而是直接输出所需的可能性。Ali Walid Daher等人也专注于优化移动目标的分类，他们提出了一种应用机器学习的解决方案。通过使用Raspberry Pi进行培训和测试，物联网被引入他们的工作中。Rulex是一个高性能的机器学习包，已被移植到客户端/服务器设置中的电路板上。实验证明，人类的准确率为100%，车辆的准确率为96.67%。为了改善移动目标的成像并提高角度分辨率，Shahzad Gishkori等人用前视汽车雷达传感器扩展了前摄合成孔径雷达方法。为了区分运动目标和静止目标，他们将非参数矩阵分解方法应用于前向扫描合成孔径雷达。在工作过程中，采用乘法器迭代法中的交替方向法解决优化问题。最后，通过模拟数据和实际数据验证了该方法的有效性。
本文介绍的系统为雷达传感器上实现的AUTOSAR通信提供了一个优化解决方案。该传感器可以通过一个从头开始实施的Arduino接口进行远程访问。本方法的研究步骤如下：
分析文献综述，以了解AUTOSAR优化和远程雷达传感器的现有方法（第3节）；
构建兼顾通信优化、远程测试、雷达应用测试的系统架构 （第4节）；
实施私有数据适配器(PDA) 优化方案 （第4.1节）；
构建雷达传感器远程测试样机 （第4.2节）；
通过构建雷达生产模式（RPM）模块来实施性能测试 （第4.3节）；
对已实施的性能测试进行分析 （第5.1节和第5.2节）；
确定并讨论使用拟议优化方案的优势和劣势 （第5.23节)。
该系统结构如图3所示，主要分为三个部分。应用程序安装在机器上时，它是在传感器内运行的软件组件。该模块表示通信软件模块，即私有数据适配器（PDA）的实现，该模块用于专用通信系统（传感器到传感器的通信），并集成在AUTOSAR通信中。
图 3 系统架构
该系统的设计是为了满足远程测试的要求（如RQ2中提出的），这意味着在正常的现场实验室之外，在特定条件下工作的开发者将能够访问雷达传感器的应用程序。开发人员或测试人员通过互联网连接到Arduino接口，而雷达传感器连接到公司实验室内部定义的接口。随着第五代雷达传感器的发展，需要有一种软件能够测试传感器是否正确组装，并为其商业使用做准备。雷达生产模式（RPM）是一个软件组件，能对雷达传感器及其应用程序进行各种测试和处理，如内存使用和运行时间测试。这些测试是基于在CAN总线上收到的命令执行的。因此，RPM是一个按照需求-响应原则工作的组件，唯一自动完成的活动是初始化它所需要的各种驱动器，以实现其目的。这个模块负责读取各种电压、温度、信号和内存部分。此外，RPM提供的另一项服务是在其所在项目的现有通信通道上发送固定结构报文。这些可以是CAN或以太网总线。发送的报文的结构将由其接收器检查，以确认传感器通信是否按预期工作。
当前生成的RPM是与其他软件组件一起加载到传感器的ROM内存中的。上传则是通过微控制器内存上的闪存完成的。一般来说，每个软件组件在初始化时都会配置传感器的硬件组件，但由于这个步骤已从RPM中删除，它是基于之前运行的组件，即Flash Bootloader (FBL)所做的配置。这个限制意味着对FBL配置所做的任何改变都会对RPM的功能产生负面影响。
雷达生产模式（RPM）与闪存加载程序进行通信，这是传感器开启后运行的第一个组件。该组件负责检查传感器内存中其他软件组件的完整性。这种检查是通过计算每个组件的循环冗余校验（CRC）来完成的，并将结果与组件加载到内存时附加在其上的验证值进行比较。此外，FBL可以分析哪些软件组件在传感器启动时存在，并根据优先级决定将启动哪个经过验证且无错误的组件。有两个组件可以由FBL启动，即传感器应用程序和测试软件管理器，其优先于应用程序。
测试软件管理器（TSM）的工作原理与RPM类似，都是基于需求-响应原则。这个组件等待一个请求，以报文的形式在CAN总线上发送，在处理请求后，它决定哪个测试组件将检查并启动它。在RPM的场景中，它将比较RPM中发现的有效性模型和TSM中包含的有效性模型模型。有效性模型是一个预先确定的数值序列（图4），分别写在传感器内存以及RPM和TSM的储存部分中。如果有效性模型相同，TSM将开启RPM的启动过程，包括将其从ROM复制到RAM并从RAM启动。测试过程结束时，RPM将从传感器内存中删除TSM。
图 4 RPM中的有效性模型
另一个可以由TSM启动的组件是生产校准（PC）。它可以处理传感器雷达天线的校准，它从传感器的存储器中的删除也是由RPM执行的。
4.1 私有数据适配器模块
77Ghz雷达传感器的通信系统是由一种特定的通信类型划分的。它是由ECU和传感器之间的特定车辆通信形成的。此外，在每两个雷达传感器之间建立专用通信。OEM的要求描述了雷达传感器使用的通信类型。这可以在CAN总线、以太网或这两者的组合上进行。鉴于车辆最多可配备16个雷达传感器，在车辆的专用信道上可以有8对此类传感器发起通信。在给定的时间，作为原始目标的数据在两个雷达传感器之间通过专用通信信道进行交换。这些数据是从环境中收集的，而私有通信的结果将在车辆通信信道内创建和传输目标和警告。汽车传感器的编号从汽车的前部开始。在这方面，标识为 S0 的传感器将在专用通道上与传感器S1建立通信；传感器S2将与传感器S3建立通信，依此类推。考虑到在某个时间t0只有两个传感器可以在一个专用通道上进行通信，为了简化软件，一个位于左边的传感器（用偶数标识符-S0-S14命名）将发送名称以"_S0 "结尾的报文。同时，一个右侧位置的传感器（用奇数标识符--S1-S15命名）将发送名称以"_S1 "结尾的信息。考虑到将在专用通道上传输的数据量较大，可以在以太网或CAN FD上发起通信。CAN FD的配置的仲裁速率是1Mb/s，配置的数据速率是2Mb/s。此外，以太网的总线速度配置为100Mb/s。
我们提出的解决方案称之为私有数据适配器（PDA），它将成为77Ghz雷达传感器软件的一部分，在AUTOSAR层面上实施。此解决方案可以分为两个部分，即软件组件（SWC）和AUTOSAR复杂设备驱动器（CDD），如图5所示。这两个组件有助于在专用通道上进行通信。该实现以1:n的方式促进了报文的转发，但同时它也存储大量的数据，直到这些数据被处理。私有数据适配器SWC负责在其他SWC和Pdu 路由器之间交换数据。私有数据适配器CDD代表通信栈中的AUTOSAR上层，并实现私有数据适配器SWC传输或接收的所有私有报文。
图 5 私有数据适配器模块设计
PDA（图6）使用专用软件缓冲器来传输/接收每个报文，并以每60毫秒一次的速度循环运行。同时，它执行报文的发送和接收，并通过RTE与其他SWC（如算法模块）进行通信，或者直接与Pdu路由器进行通信。
图 6 AUTOSAR开发流程中的PDA模块
PDA SWC的结构是基于几个子模块实现的，如每个报文的传输、每个报文的接收和PDA的具体功能。除了报文的传输和接收，PDA模块还负责以下工作：
信号计算，这意味着对信号应用一个因子和/或一个偏移量，以便在CAN/以太网上传输原始值，并在接收端去除它，以获得其他swc所需的物理值；
范围检查，根据DBC中定义的范围，和超出范围的信号的默认值分配（最小值/最大值）；
对收到的报文进行端到端（E2E）保护，通过验证数据完整性的CRC信号，和检查报文是否丢失的计数器信号检来完成。
为了避免CAN FD总线冲突，AUTOSAR通信栈使用了后期构建可选变体，这些变体是为每个传感器标识符定义的。在所有偶数变体（S0、S2等）上，报文命名以"_S0 "结尾。在所有其他变体上，报文的名称以"_S1 "结尾。一个CAN总线上只连接两个传感器，因此每个报文只需要两个不同的标识符。PDA负责读取传感器ID，并以相应的Pdu句柄ID将报文传送到Pdu路由器。由于以太网不依赖于报文的ID，在通信栈中只定义了"_S0 "报文，PDA发送它时不依赖于传感器标识符。例如，当传感器ID = S0时，CAN帧信息为<报文名称>_S0，而当传感器ID = S1时，CAN帧信息是<报文名称>_S1，等等。对于以太网帧，所有ID的格式将是相同的，即<报文名称>_S0。
图 7 (a) 将信号设置到软件缓冲区。(b) 从软件缓冲区获取信号。
4.1.1 PDA 传输
在DBC（CAN FD）或arxml（以太网）文件中的每个报文都有一个相应的发送信号子模块。通常情况下，在两个通道上以1:n的方式实现报文的传输。但是，也有仅在单个信道上实现和传输报文的情况。
所有报文的传输是以循环方式进行的，每60ms循环一次。如果传输被初始化并且被启用，数据将在通道上传输。否则，数据将在CH0或CH1上传输，这取决于其可用性。该过程在图8中描述。
图 8 传输配置图
报文传输的步骤如图9所示。此处，应传输的数据通过RTE接口从SWC读取，然后逐个信号映射到PDA软件缓冲区。除了从SWC读取的信号外，软件缓冲区还可能包含另外两个专门用于端对端保护的信号（只有当报文将被其他传感器接收时）。软件缓冲器信息被复制到一个Pdu路由数据类型中，通过调用PduR_PdaTransmit函数和相应的Pdu句柄ID来完成其向通信栈的传输。
图 9 报文传输图
头-数据-挂拖报文的传输包含三个不同的函数，每个报文包含一个函数，这就是为什么PduR_PdaTransmit会被多次调用，以传输多数据报文。
4.1.2 私有数据适配器（PDA）接收
报文的接收分两步实现。第一步，假设当Pda_RxIndication回调函数被调用时，将从总线上收到的数据复制到PDA的软件缓冲区（接收模式在通信栈中作为中断实现）。在这个函数中，更新位被设置为“TRUE”，以表示收到了一条新报文（图10）。此外，每个收到的报文都有一个相应的更新位。如果收到更多的消息，并且自上次报文处理之后没有再接收报文，更新位将只设置一次，缓冲区将包含可供处理的最新数据。
图 10 通过Pda RxIndication函数接收PDA图解
报文接收不取决于传感器标识符，因为AUTOSAR通信栈在其所有变体中对报文的是相同的Pdu句柄ID。PDA接收表与Pdule一致 ，它也不依赖于传感器标识符。如果在Pdu 路由器中MessageOne_S0和MessageOne_S1报文有一个Pdu句柄ID为 "0"，那么将在接收端设置Pda_RxIndication()调用。在这种情况下，如果数据可用，它将被复制到缓冲区。如果更新位表已初始化，则设置更新位。
第二步，数据处理，这意味着每个信号被解压并复制到SWC数据格式类型中。在处理数据之前，首先应清除更新位（设置为 "FALSE"）。之后，新数据通过RTE传输到SWC中。这个步骤是循环进行的。如果在一个周期内多次收到相同的报文，数据将被重新处理（按规定的次数），这意味着 "最后的总是最好的“。报文接收的处理部分每60毫秒循环执行一次。头-数据-挂拖报文的接收与上面介绍的类似，只是在这种情况下，为每个报文（头、数据、挂拖）都实现一个执行函数。在Pda_RxIndication（图11）中，每个消息的更新位都被设置。
图 11 处理接收的数据
4.2 远程访问和测试
由于目前需要从公司的物理边界以外的地方访问雷达传感器应用程序，因此形成了远程测试功能。该传感器与Arduino接口相连，如图12所示。
Arduino的引脚与继电器控制引脚、JTAG连接器（用于调试器）、DB25（用于传感器）、DE9（用于连接到CAN）和调试器电源线相连。Arduino的数字引脚3与继电器控制引脚相连。GND中断线与NC（常闭）引脚相连，这意味着调试器将正常供电。为了安全起见，使用了一个二极管，放置在连接Arduino和继电器的电线上，以便在发生短路时保护电路板。
为了实现调试器的条带功能，调试器通过一个10引脚的条带连接到JTAG端口。为了在传感器上闪现新实现的代码，这种连接是必需的。如果在代码中出现了任何问题或错误，雷达传感器将会重置。如果雷达传感器连接到条带，这种行为就不能被观察到，因为调试器不允许传感器复位。因此，测试必须在不连接条带的情况下进行。
图 12 雷达传感器与Arduino的连接
10-引脚条带需要10个具有单个触点的继电器来切断电源。我们选择了一个由五个继电器组成的解决方案，每个继电器有两个触点。Arduino产生的电流的最大电压为5V，这个电压太低，无法同时关闭所有五个继电器。我们引入了第六个继电器，并与Arduino连接，由处于常开状态的外部电源供电。在这个继电器的帮助下，可以控制其他5个并联的继电器，这样施加在每个继电器上的电压是相同的。第一个继电器将连接调试器的条带，该条带的10个引脚仍然与继电器相连，这样就有可能中断电流。第二个继电器的引脚将连接到继电器的输出端，并将一个与传感器连接的条带连接到它。
通过DB25连接器，为传感器提供电流，更确切地说，是通过1号引脚。为了重置传感器，必须中断电源。
为了实现总线关闭功能，需要三个继电器，其连接方式如下。CAN H到GND；CAN L到VCC；以及SHORT H到L。为了实现过载（图13），需要两个继电器，CAN H和CAN L。为了确定传感器在特殊情况下的反应，需要建立特定的连接，如CAN H到VCC、CAN L到GND。雷达传感器接口模块如图14所示。
图 13 总线关闭和过载功能
图 14 雷达接口模块
4.3 测试传感器的应用程序
在我们的系统中，雷达生产模式（RPM）负责对雷达应用程序进行必要的测试，以衡量私有数据适配器模块的性能。从RPM的角度来看，这些测试被视为服务。
第一次调用RPM模块时，它会调用其他模块初始化，但AUTOSAR中的BSW模块除外。此外，它记录执行服务所需的所有任务，然后配置所有必要的引脚和寄存器。在成功完成所有这些步骤后，它在CAN总线上触发一个信息，表示RPM已经准备好接收一个请求报文。
有两种类型的请求：单帧请求，这是简单的请求，其数据包含在一个CAN报文的8个字节中；多帧请求，它需要几个报文才能传输所有需要的数据。在多帧请求的情况下，第一个报文被发送，接着是一个来自RPM的报文。这个报文被称为 "流控制"，表明RPM已经准备好接收其余的报文。当在CAN总线上收到报文时，CAN模块通过Rx Indication函数将报文内容发送给模块。这个功能根据RPM的状态，确定收到的是什么类型的报文。然后对其进行处理，并将其内容保存在一个内部缓冲区中（图15）。
其中一个任务每毫秒被调用一次，叫做服务发现。它解析报文的内容并检查其结构和数据是否有效。紧接着，它检查RPM的状态。如果RPM已经准备好执行服务，它将继续向下运行。如果需要额外的数据来帮助执行服务，就会触发一条报文发出信号。如果RPM还没有准备好执行服务，它将等待，直到状态改变。一旦RPM准备好并继续执行，它就会确定所请求的服务属于哪个组，报文内容被发送到该服务组的过滤功能区。此步骤可见图16的活动图。
图 16 服务发现函数
请求的服务所属的组的过滤功能将接收报文的内容，然后检查请求的服务是否存在。如果服务存在，则调用该服务，并在适当的时候，将从报文中提取的执行参数发送给该服务。例如，这些执行参数可以是由写入服务写入的值，或者是报文之间的时间间隔，以及所选通信通道的测试服务所要暂存的报文数量。根据其复杂性和可配置性，也有一些服务具有自己的过滤功能。
如果在处理请求的过程中，该请求确定是无效的，无论是由于报文内容的结构还是由于其不正确的值，处理都会停止，并通过发送一个否定报文包含来表明该请求是无效的，该否定报文包含与请求消息中遇到的错误相关的错误代码。一旦被调用，该服务就试图满足请求。在成功的情况下，它将触发发送一个包含服务结果的肯定报文。如果无法满足请求，它就会触发一个否定报文，其中包含与它无法满足请求的原因有关的错误代码。
本节实现了第4节中提出的研究方法的第6步和第7步。首先，通过雷达生产模式下的服务，调查了内存使用和运行时间测量。此外，对通过Pdu 路由器实现PDA的解决方案和完全AUTOSAR解决方案进行了分析，并比较了这两种解决方案的优缺点。
5.1 内存使用情况
实验中使用的测试装置是由该大学和当地一家汽车公司合作创建的。将77Ghz雷达传感器连接到公司总部的Arduino接口。因此，软件开发人员或测试人员可以通过互联网远程连接到Arduino接口。基于AUTOSAR方法实现了三种不同报文（不同类型）的传输，并与基于Pda通过Pdu 路由器方法实现相同报文的传输进行了比较：
一个简单报文；
一个复杂报文（头部-数据-拖挂）；
多路复用信息（假设在AUTOSAR方法软件中引入IpuM AUTOSAR模块）。
简单消息被命名为MessageOne，其长度为64字节。复杂消息被命名为MessageTwo，MessageTwo数据在一个周期内最多可以发送40次。MessageTwo头部报文的长度为24字节；MessageTwo数据报文的长度为64字节，而MessageTwo拖挂报文的长度为3字节。多路复用报文，命名为MessageThree，有四种不同的布局，每一种布局都是根据一个选择器字段（复用器）来区分和传输的。其长度为20字节。
所有其他的报文都通过Pdu路由器模块在PDA中实现。这两种方法的区别在于以下文件中：
Pda_Send_MessageOne_Exec.c;
Pda_Send_MessageTwo_Exec.c;
Pda_Send_MessageThree_Exec.c.
我们调查了RAM（EMEM）和ROM（程序闪存）的内存使用情况，并对两种解决方案进行了运行时测量。如第4.3节所述，RPM通过使用专用服务来进行这些测量。
表 1 列出了优化解决方案（即通过 Pdu路由器实现 PDA）的模块使用结果，并与使用传统 AUTOSAR 解决方案（没有实施优化解决方案）的结果进行了比较。可以注意到，在采用通过Pdu路由器实现PDA情况下，Pda_Send的内存用量低于完全 AUTOSAR 的情况。EMEM和程序闪存块方面，也是同样的结果。
通过Pdu路由器实现PDA解决方案的对象内存使用结果与完全 AUTOSAR方案的对象内存使用结果进行了比较，见表 2。可以注意到，在复杂的头-数据-拖挂报文中取得了最大的改进，而在简单报文和多路报文的情况下，通过Pdu优化实现的PDA方案，ROM内存的使用率得到了改善。
5.2 运行时间测量
在调试环境下，使用系统定时寄存器0（STM0）对每个报文传输连续三次（从启动开始）的执行运行时测量，具体如下：
起始点：对于通过Pdu路由器实现Pda的解决方案，起点是PduR_PdaTransmit()。Full AUTOSAR 解决方案的起始点是Rte_Write_
结束点：在这两种情况下，结束点都是CanIf_TxConfirmation() 。
在表3和表4中可以注意到，从运行时测量结果来看,PDA通过Pdu路由器的优化方案对每个测试报文都有改进。此外，在执行的每一次活动中，改进最明显的是多路复用报文。
5.3 讨论情况
本文的（RQ3）旨在从性能方面分析拟议的AUTOSAR通信优化解决方案的收益。以往关于AUTOSAR雷达传感器优化的工作没有解决本文提出的AUTOSAR层面的通信问题；因此，从文献综述中，我们参考了旨在衡量性能的评价方法。从之前的实验中可以看出，通过Pdu路由器实现PDA的解决方案，其最大优势在于数据传输的执行时间。事实证明，它比完全AUTOSAR解决方案要快得多。图17中总结了结果，对于每种报文类型（X轴），给出了相应的测量值（Y轴）。
图 17 运行时测量结果比较
在ROM内存消耗方面，与完全AUTOSAR解决方案相比，通过Pdu路由器实现PDA优化方案使用的内存资源更少。完全AUTOSAR解决方案使用的内存资源几乎是后者的2倍。在图18中，通过强调报文类型（X轴）和区段长度（Y轴）来展示这些结果。传统AUTOSAR另一个可能的缺点是它对DBC布局的依赖性。随着每次报文布局的变化（例如增加/删除一个信号），必须更新相应的软件缓冲区。
图 18 关于程序闪存的对象内存使用情况的比较
仅通过RTE与其他SWC和Com模块的交互，代表了PDA SWC的抽象性，突出了完全AUTOSAR解决方案的主要优势。因此，这种通信方法以允许独立于PDU手柄ID。此外，由于AUTOSAR通信栈代码的维护只需要更少的努力，因此强调了完全AUTOSAR解决方案的另一个优势。如果通信栈需要改变，基于当前的DBC，模块会通过一个自动执行的配置更新过程进行更新。当一个新的报文被添加到DBC时，通过Pdu路由器实现PDA的解决方法意味着从Com模块中删除PDU，并在导入报文后添加一个到PDA CDD的新路由。如果使用完全 AUTOSAR 方法，在 DBC 导入之后，不需要进行额外的更改。然而，在采用通过Pdu路由器实现PDA方法时，RAM内存的占用量较低。
本文提出了一个优化AUTOSAR通信的解决方案，作为对我们（RQ1）的回应。这种方法假定两个连接的雷达传感器始终是同步的。在不同步的情况下（例如，由意外复位引起），PDA的行为将直接受到影响。为了解决(RQ2)问题，我们构建了一个基于Arduino的接口，其中附加了雷达传感器，允许从任何位置进行远程访问。这个接口提供了基于AUTOSAR应用直接访问雷达传感器可能性，即使在目前Covid-19限制期间在家庭办公室访问。对于（RQ3），我们实施了一个单独的软件模块，该模块能够进行性能测试，以确定我们的解决方案能提供哪些优势。根据前一章的结果，通过Pdu路由器的PDA解决方案在内存使用和运行时间测量方面比完全AUTOSAR更有优势。PDA模块能够以灵活的方式传输和接收大量数据，因为它能够处理事件和时间触发报文。
