CN117234926A - 基于autosar架构的软件组件接口检查方法及装置 - Google Patents

Abstract

本申请提供一种基于AUTOSAR架构的软件组件接口检查方法及装置。该方法包括：获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；从配置文件中提取每个应用层软件组件对应的配置文件信息；从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。本申请能够提高软件集成的效率，降低软件开发的时间和成本。

Description

基于AUTOSAR架构的软件组件接口检查方法及装置

技术领域

本申请涉及应用软件开发技术领域，尤其涉及一种基于AUTOSAR架构的软件组件接口检查方法及装置。

背景技术

在嵌入式软件开发中，尤其是使用AUTOSAR(AUTomotive Open Syste mARchitecture)架构时，开发流程通常包括以下几个步骤：模型代码生成、应用层软件集成、RTE(Run-Time Environment)接口配置、底层软件集成以及代码编译。其中，Simulink作为一种广泛使用的建模工具，被用于生成应用层的模型代码。

在现有技术中，开发流程通常直接从Simulink模型生成代码，然后进行应用层软件集成和RTE接口配置，最后是底层软件集成和代码编译。在这个过程中，RTE接口的匹配通常没有得到事先的检查。由于现有技术中缺乏对RTE接口的早期检查，这导致在代码编译阶段可能会出现接口不匹配的问题。当这种情况发生时，整个软件开发流程需要重新走一遍，包括模型代码的生成和编译，这无疑增加了软件开发的时间和成本。因此，如何在模型代码生成阶段有效地检查RTE接口的匹配性，从而避免在后续软件开发流程中出现接口不匹配的问题，提高软件集成的效率，已经成为亟需解决的问题。

发明内容

有鉴于此，本申请实施例提供了一种基于AUTOSAR架构的软件组件接口检查方法及装置，以解决现有技术存在的无法有效地检查RTE接口的匹配性，导致软件集成效率降低，增加软件开发的时间和成本的问题。

本申请实施例的第一方面，提供了一种基于AUTOSAR架构的软件组件接口检查方法，包括：获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；将配置文件的路径添加到软件开发环境的工作路径中，并从配置文件中提取每个应用层软件组件对应的配置文件信息；从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。

本申请实施例的第二方面，提供了一种基于AUTOSAR架构的软件组件接口检查装置，包括：获取模块，被配置为获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；提取模块，被配置为将配置文件的路径添加到软件开发环境的工作路径中，并从配置文件中提取每个应用层软件组件对应的配置文件信息；查找模块，被配置为从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；生成模块，被配置为利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；匹配模块，被配置为对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。

本申请实施例的第三方面，提供了一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时实现上述方法的步骤。

本申请实施例的第四方面，提供了一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；将配置文件的路径添加到软件开发环境的工作路径中，并从配置文件中提取每个应用层软件组件对应的配置文件信息；从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。本申请在模型代码生成之后，可以准确有效地对应用层软件组件的接口进行匹配性检查，从而避免后续软件开发流程中出现接口不匹配的情况，提高软件集成的效率，降低软件开发的时间和成本。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本申请实施例提供的基于AUTOSAR架构的软件组件接口检查方法的流程示意图；

图2是本申请实施例提供的基于AUTOSAR架构的软件组件接口检查装置的结构示意图；

图3是本申请实施例提供的电子设备的结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

在嵌入式软件开发中，Simulink模型的Autosar代码生成及编译的主要步骤包括：模型代码生成、应用层软件集成、RTE接口配置、底层软件集成、代码编译。目前模型代码生成后不经过RTE接口检查，如果有RTE接口不匹配的话，会导致在代码编译时报接口不匹配的问题，然后又要重新走一遍代码生成及编译流程，为了提高软件集成的效率，本申请提出一种基于应用层组件的arxml文件检查RTE接口的方法，在模型代码生成后就可以检查RTE接口是否匹配。

Simulink是一种建模、模拟和分析动态系统的图形化软件环境。在汽车、航空、机器人学和其他工程领域，它常用于系统级设计和模拟。在本申请的应用场景(新能源汽车的AUTOSAR开发)中，Simulink模型通常用于表示车辆的各种子系统，如动力总成(powertrain)、制动系统、传感器网络等。Simuli nk模型由以下部分组成：

方块(Blocks)：Simulink模型由各种方块组成，每个方块代表一个特定的函数、操作或者物理过程。例如，一个方块可以代表一个加速度传感器，另一个方块可以代表一个电机。

信号(Signals)：方块之间通过信号连接。信号代表信息的流动，如数据、控制命令等。

参数(Parameters)：每个方块都有一些参数，可以通过调整这些参数来模拟不同的工况。

子系统(Subsystems)：复杂的模型可能会包含子系统，即一个方块实际上是一个包含更多方块的小型模型。

进一步地，对Simulink模型在AUTOSAR和新能源汽车中的应用进行说明，在新能源汽车的AUTOSAR开发中，Simulink模型通常用于以下几个方面：

建模与验证：开发人员可以构建整个车辆或特定子系统(例如，电池管理系统、电机控制器等)的模型，并进行模拟以验证设计。

代码生成：Simulink模型可以用于自动化地生成符合AUTOSAR标准的代码。这就是所提到的“模型代码生成”。

测试与仿真：在模型构建完成后，可以运行各种仿真测试，确保模型和生成的代码都能满足实际需求。

在本申请的技术方案中，Simulink模型被用作生成应用层的AUTOSAR代码以及相应的ARXML文件。这些文件之后用于检查RTE(运行时环境)接口是否匹配，从而提高代码编译和软件集成的效率。

AUTOSAR(Automotive Open System Architecture，自动化软件架构)是一个全球标准，旨在简化汽车电子(ECUs,Electronic Control Units)的开发和改进。AUTOSAR提供了一个标准化的软件架构，用于开发更为模块化、可扩展、可重用的软件组件。AUTOSAR架构主要包含以下几个核心组成部分：

1、基础软件层(BSW,Basic Software Layer)

这一层提供了底层硬件和上层应用软件之间的抽象，包括诸如通信、诊断、操作系统功能等基础服务。

2、运行时环境(RTE,Runtime Environment)

运行时环境是AUTOSAR架构中的关键组成部分，负责软件组件(SWCs,SoftwareComponents)之间以及软件组件和基础软件层之间的通信。

3、软件组件(SWCs,Software Components)

在AUTOSAR架构中，软件逻辑被封装为软件组件。每个软件组件都有明确定义的接口和行为，这使得它们可以独立于特定的硬件和其他软件组件进行开发和测试。

4、系统描述

AUTOSAR使用特定的XML文件(ARXML)来描述系统的各个方面，包括软件组件的属性、系统配置、通信接口等。

5、方法论

AUTOSAR还提供了一套方法论，用于管理整个开发流程，包括需求分析、设计、实现、测试和维护。

进一步地，AUTOSAR架构在新能源汽车中的应用包括以下几个方面的内容：

模块化和可重用性：由于新能源汽车涉及多种复杂的子系统(如电池管理、电机控制、能量回收等)，AUTOSAR的模块化架构使得开发人员可以更容易地复用代码和组件。

安全和可靠性：AUTOSAR具有强大的安全特性，可确保车载软件的安全和可靠运行。

互操作性：AUTOSAR的标准接口和配置方式使得不同供应商和不同组件间能够更容易地进行集成。

灵活性和可扩展性：新能源汽车通常需要快速适应新技术和市场需求，AUTOSAR架构提供了足够的灵活性和可扩展性来满足这些需求。

在本申请的技术方案中，AUTOSAR被用于标准化软件组件和接口，以提高软件开发和集成的效率。特别是通过AUTOSAR的ARXML文件，本申请实施例能够提前检查RTE接口的匹配性，从而避免了后期编译和集成中可能出现的问题。

下面对Simulink模型与AUTOSAR架构之间的关系进行解释说明，具体可以包括以下内容：

Simulink是一种图形化的模型设计工具，常用于控制系统和嵌入式系统的开发。通过Simulink，工程师可以用图形化的方式建立一个系统模型，这个模型能够进行模拟运行，以检验系统设计是否正确。

AUTOSAR(AUTomotive Open System ARchitecture)则是一种为了提高汽车电子控制单元(ECUs)软件的可复用性和可替换性而设计的开放标准。

两者之间的关系主要在于“桥接”和“转换”。

桥接：Simulink允许开发者设计复杂的控制算法和系统逻辑，而AUTOSA R标准则定义了如何在实际的汽车电子硬件(ECU)上实现这些算法和逻辑。通过某些工具和库，Simulink设计的模型可以被转换为符合AUTOSAR标准的代码。

转换：通常，从Simulink模型到AUTOSAR的转换是一个自动化的过程。这样一来，原本在Simulink中设计的控制逻辑或算法能够以AUTOSAR标准的形式部署到汽车的电子控制单元(ECU)上，这大大提高了工程效率。

互操作性：因为AUTOSAR定义了标准的方式来组织软件代码，所以用Si mulink设计的模型一旦转换为AUTOSAR格式，就更容易与其他遵循AUTOS AR标准的系统或组件进行集成。

下面结合附图以及具体实施例对本申请技术方案进行详细描述。

图1是本申请实施例提供的基于AUTOSAR架构的软件组件接口检查方法的流程示意图。图1的基于AUTOSAR架构的软件组件接口检查方法可以由服务器来执行。如图1所示，该基于AUTOSAR架构的软件组件接口检查方法具体可以包括：

S101，获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；

S102，将配置文件的路径添加到软件开发环境的工作路径中，并从配置文件中提取每个应用层软件组件对应的配置文件信息；

S103，从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；

S104，利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；

S105，对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。

本申请实施例的应用层软件组件接口也可以理解为RTE接口(即运行时环境接口)，RTE(Runtime Environment)是AUTOSAR架构的核心部分，实现了上层SWC(SoftwareComponent)与基础软件(Basic Software Module)之间的通信，使得SWC可以独立于任何特定ECU和其它SWC进行单独开发。而RTE是针对ECU和特定SWC配置生成的，所以每个ECU都有自己特定的RTE。RTE按作用可以分为两部分：实现SWC之间的通信，实现SWC的调度。

下面结合具体实施例对AUTOSAR架构中的RTE(Runtime Environment，运行时环境)以及它的核心作用和特点进行详细说明，具体可以包括以下内容：

首先，RTE是AUTOSAR架构不可或缺的一部分，它充当了一个桥梁或中介的角色。RTE负责处理软件组件(SWC，Software Component)和基础软件模块(Basic SoftwareModule)之间的信息交流。简单来说，SWC是包含特定功能或逻辑的代码块，而基础软件模块则提供底层的系统服务。

RTE使得软件组件SWC可以独立于任何特定ECU和其他SWC进行单独开发，这意味着可以单独开发和测试一个软件组件，而不必担心它如何与特定的电子控制单元(ECU，Electronic Control Unit)或其他软件组件交互。这极大地增加了代码的可重用性和系统的灵活性。针对ECU和特定SWC配置生成，说明每个ECU(电子控制单元，通常是一个物理硬件单元，如引擎控制模块或气囊系统)都有其专属的RTE配置。换句话说，RTE是为特定的硬件和软件环境量身定做的。

在实际应用中，RTE按照作用可以分为以下两部分(即RTE主要包括以下两个功能)：

第一，实现SWC之间的通信：即RTE允许不同的软件组件之间互相交换信息。

第二，实现SWC的调度：即RTE负责决定哪个软件组件何时运行，以及如何优先处理。

由此可见，RTE在AUTOSAR架构中起到非常关键的角色，它不仅连接了软件组件和基础软件，还使得这些组件能够在多样化的硬件环境中以高度模块化的方式运行和交互。这一切都有助于提高软件开发的效率、灵活性和可靠性。

在一些实施例，获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个所述应用层软件组件对应模型代码的配置文件，包括：利用预定的AUTOSAR建模工具将所述应用层软件组件的模型代码导出，并利用预定的AUTOSAR配置工具，获取每个所述应用层软件组件对应的配置文件，其中，所述配置文件采用ARXML格式的文件。

具体地，开发者首先使用预定的AUTOSAR建模工具(如Matlab Simulink的AUTOSAR模块)来创建或编辑应用层(Application Layer)的软件组件(Software Component，SWC)。这些软件组件可以是一些控制算法、数据处理模块等。通过这个工具，开发者将应用层软件组件的模型代码导出。

进一步地，开发者使用预定的AUTOSAR配置工具(如EB Tresos或Vector DaVinci)来获取每个应用层软件组件对应的配置文件。这些配置文件通常采用ARXML(AUTOSAR XML)格式。

配置文件类型和SWC Description，在AUTOSAR的开发环境中，一般存在多种类型的ARXML文件，ARXML文件包括但不限于以下类型：

System Configuration：系统配置，描述了整个系统的布局和连接。

ECU Extract：ECU(电子控制单元)提取，涵盖了特定ECU的配置。

ECU Configuration：ECU配置，包括用于单个ECU的所有设置和参数。

SWC Description：软件组件描述，描述了所有用户自定义的设计信息。

BSW Module Description：基础软件模块描述，描述了基础软件层面的各种模块。

在本申请实施例中，本申请主要关注SWC Description这一类型的ARXML文件。这个文件提供了所有关于用户自定义软件组件(SWC)的设计信息，包括但不限于以下信息：SWC定义：明确软件组件的属性和功能。运行实体(Runnable Entities)：描述了软件组件内部的运行逻辑。接口(Interfaces)：描述了软件组件的输入和输出，以及与其他软件组件或系统的交互方式。端口数据类型(Port Data Types)：定义了通过软件组件接口交换的数据的类型。

在一个示例中，假设一个开发者正在设计一个汽车防抖系统。开发者可以使用Simulink工具来设计一个“防抖控制器”软件组件。这个组件将有各种输入和输出，比如车速、轮速等。一旦设计完成，开发者通过AUTOSAR建模工具将这个“防抖控制器”的模型代码导出。随后，通过预定的AUTOSAR配置工具来生成相应的SWC Description ARXML文件。这个ARXML文件将包含防抖控制器的所有设计细节，包括它的运行实体、输入/输出接口以及数据类型等。通过上述方式，开发者不仅能够生成符合AUTOSAR标准的应用层软件组件，还能够获取详尽的配置文件，为后续的接口匹配和集成工作提供了有力的支持。

AUTOSAR Interface：表示可以使用VFB概念来表示的软件组件接口。RTE上方的Application SWCs,Actuator(执行器)/Sensor(传感器)SWCs以及下方的ECU Abstraction(ECU抽象)，Complex Driver(复杂设备驱动)都使用这种接口。通过AUTOSAR Interface连接到RTE的各个SWCs都可以拥有自己的P-Port和R-Port，并与其它SWCs进行交互，从而实现SWC之间的通信。在软件编译中会对编译环境中的接口信息进行检查，若一个SWC的R-Port没有与之匹配的P-Port(即一个SWC需要的接口没有另外的地方提供此接口)，会报编译失败，从而影响软件编译效率。

在一些实施例，从配置文件中提取每个应用层软件组件对应的配置文件信息，包括：利用软件脚本中预先设定的程序及参数，自动获取每个应用层软件组件的配置文件信息，其中，配置文件信息包括配置文件的文件名、提供者接口名称、请求者接口名称、Interfaceming名称、Element名称以及Element的数据类型。

具体地，一旦应用层软件组件(Application Layer SWC)的模型代码和对应的ARXML配置文件被生成和获取，接下来便是从这些配置文件中提取必要的信息。这通常是一个重要但容易出错的步骤，特别是当系统规模庞大、组件众多时。为了解决这个问题，本申请实施例中使用软件脚本中预先设定的程序和参数来自动化这个过程。下面结合具体实施例对配置文件信息的提取过程进行详细说明，具体可以包括以下步骤：

1)软件脚本设定：首先，开发者或系统工程师编写一个软件脚本，通常是用Python、Perl或其他脚本语言。这个脚本中包含了预先设定的程序和参数，用于解析ARXML文件。

2)自动读取ARXML文件：运行软件脚本后，它会自动扫描指定目录中的所有ARXML文件，并开始读取它们。

3)信息提取：软件脚本会根据预设定的规则和参数，从每个ARXML文件中提取以下信息：文件名(File Name)：ARXML文件的名称。提供者接口名称(Provider InterfaceName，P-Port)：该软件组件提供的接口。请求者接口名称(Requester Interface Name，R-Port)：该软件组件需要的接口。Interfaceming名：接口映射名称，描述接口之间的对应关系。Element名：接口内各个元素的名称。Element的数据类型：这些元素的数据类型(例如，整数、浮点数等)。

在实际应用中，所有提取出来的配置文件信息将被整理和存储，以供后续的接口匹配矩阵生成和分析。通过这样的自动化处理，开发者可以大大提高提取和处理配置信息的效率和准确性，从而更快地进入下一阶段的开发和集成。

在一些实施例，从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息，包括：定义用于获取提供者接口信息和请求者接口信息的查询指令，响应于执行查询指令的操作，对配置文件信息中的相关字段进行分析，得到应用层软件组件的提供者接口信息和请求者接口信息。

具体地，在提取出ARXML配置文件信息之后，需要进一步获取每个应用层软件组件(Application Layer SWC)的提供者接口信息和请求者接口信息。为了自动化这一过程并减少人为错误，本申请实施例提出了定义和执行查询指令以自动分析和获取这些接口信息的方法。

进一步到，查询指令定义包括查询语言与结构：开发者或系统工程师首先需要定义一组查询指令。这些查询指令可以用SQL、XQuery或其他适用的查询语言来表示。指令目标：每个查询指令都旨在提取一个特定类型的接口信息，例如提供者接口名称(P-Port)、请求者接口名称(R-Port)等。

进一步地，执行与响应包括执行查询指令：预先编写的软件脚本或应用程序会自动执行定义好的查询指令。数据分析：查询结果会被捕获并进一步分析，以便从中提取出提供者和请求者接口的信息。

进一步地，信息获取与处理包括字段匹配：根据查询结果，脚本或应用程序会对配置文件信息中的相关字段进行匹配和分析。信息抽取：从匹配的字段中，提供者接口信息和请求者接口信息会被准确地抽取出来。

在一些实施例，利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，包括：在预定的数据结构中对每个应用层软件组件的请求者接口和提供者接口进行配对操作，根据配对结果，构建一个接口匹配矩阵，其中，接口匹配矩阵中包含所有可能的请求者接口和提供者接口组合，接口匹配矩阵中的每个单元格包含一个特定的接口配对信息。

具体地，当从配置文件中成功提取了每个应用层软件组件(SWC)的提供者(P-Port)和请求者(R-Port)接口信息，接下来需要生成一个接口匹配矩阵。这个矩阵是为了解决AUTOSAR应用层组件间接口匹配问题而设计的。在实际应用中，接口匹配矩阵的构建过程包括以下步骤：

1)数据结构与配对操作

预定数据结构：使用多维数组、列表或其他适用的数据结构来创建一个空矩阵。

配对操作：对于每个应用层软件组件，根据之前获取的P-Port和R-Port信息，在数据结构中进行配对操作。

2)接口匹配矩阵构建

矩阵填充：根据配对结果，在预定的数据结构中填充信息，构建一个完整的接口匹配矩阵。

矩阵内容：该矩阵包括所有可能的P-Port和R-Port组合。每个单元格都包含一个特定的接口配对信息，还可能包括了其他属性(例如，数据速率、接口版本等)。

在一个具体实例中，矩阵也可用于执行自动检查，以确保配对接口满足所有必要的约束条件，例如数据类型匹配、接口版本兼容等。通过上述方法，不仅能清晰地视觉化接口配对问题，还能自动进行接口匹配检查，进一步提高系统集成的效率和准确性。

在一些实施例，对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，包括：利用预定的匹配算法，对接口匹配矩阵进行遍历，以判断每个请求者接口是否有与其相对应的提供者接口，若判断请求者接口没有与其相对应的提供者接口时，将请求者接口标记为异常接口。

具体地，生成的接口匹配矩阵还需进一步分析，以确定每个请求者接口(R-Port)是否有与之匹配的提供者接口(P-Port)。这样做可以提前发现潜在的接口不匹配问题，从而提高整体系统集成的效率和准确性。在实际应用中，接口匹配矩阵的分析过程可以包括以下内容：

1)预定的匹配算法：使用预先定义的匹配算法，例如可以采用基于字符串匹配、数据类型比较或其他合适的方法。

2)遍历矩阵：逐行和逐列遍历生成的接口匹配矩阵，对每个R-Port与P-Port进行匹配检查。

3)异常接口标记：如果发现某个R-Port没有与之匹配的P-Port，该R-Port将被标记为异常接口。

4)异常数据类型：即使找到了名称相同的R-Port和P-Port，如果它们的数据类型不一致，也会标记为异常。

5)记录异常信息：所有标记为异常的R-Port信息将被记录下来，包括它们没有匹配的P-Port名称和不一致的数据类型。

在一些实施例，记录异常接口的信息，包括：对异常接口的接口名以及异常数据类型进行记录，并根据全部的异常接口的信息生成相应的编译失败报告，其中，异常数据类型用于表征请求者接口与提供者接口的数据类型不一致。

具体地，在一个示例中，假设根据前述实施例生成的接口匹配矩阵中，若发现FuelInjector(EngineControl)没有找到与之匹配的P-Port，而ClutchActivation(TransmissionControl)与GearShift(TransmissionControl)的数据类型不一致。那么，便可以将这些信息标记并记录为：

异常接口名：FuelInjector(EngineControl)(无对应的P-Port名)

异常数据类型：ClutchActivation(TransmissionControl)和GearShift(TransmissionControl)(数据类型不一致)

在另外的实施例中，上述异常信息不仅可以被记录，还可以用于触发其他工作流，如自动通知开发人员或输出修正建议。通过上述方法，本申请实施例不仅能确保接口匹配的准确性，还能在早期阶段即发现并记录可能的接口不匹配问题，大大提高了系统开发的效率。

根据本申请实施例提供的技术方案，本申请实施例通过在模型代码生成阶段就利用arxml文件进行RTE接口匹配检查，有效地提前发现了RTE接口不匹配问题。这样，开发人员可以在代码编译前解决这些问题，从而避免了在后期编译阶段浪费时间和资源。由于RTE接口问题在早期就被识别和解决，编译阶段将更加顺利，极大地提高了软件编译的效率。这不仅缩短了产品的开发周期，还有助于减少开发成本。本申请实施例还增加了模型代码的RTE接口检查机制，这种检查可以作为后续代码编辑和自动化工作流的一部分，从而进一步提高开发效率和代码质量。通过早期识别和解决RTE接口不匹配问题，本申请实施例有助于确保整个系统的可靠性和稳定性。这样，系统在部署时能够避免由于接口不匹配而导致的潜在风险和缺陷。因此，综上所述，本申请实施例针对AUTOSAR开发，提供了一种高效、可靠的RTE接口检查机制，不仅提高了软件编译效率，还有助于确保系统的可靠性，同时也为后续的代码编辑和自动化提供了便利。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图2是本申请实施例提供的基于AUTOSAR架构的软件组件接口检查装置的结构示意图。如图2所示，该基于AUTOSAR架构的软件组件接口检查装置包括：

获取模块201，被配置为获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个应用层软件组件对应模型代码的配置文件；

提取模块202，被配置为将配置文件的路径添加到软件开发环境的工作路径中，并从配置文件中提取每个应用层软件组件对应的配置文件信息；

查找模块203，被配置为从配置文件信息中查找每个应用层软件组件对应的提供者接口信息和请求者接口信息；

生成模块204，被配置为利用提供者接口信息和请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部提供者接口信息和请求者接口信息汇总在一起；

匹配模块205，被配置为对接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录异常接口的信息。

在一些实施例中，图2的获取模块201利用预定的AUTOSAR建模工具将应用层软件组件的模型代码导出，并利用预定的AUTOSAR配置工具，获取每个应用层软件组件对应的配置文件，其中，配置文件采用ARXML格式的文件。

在一些实施例中，图2的提取模块202利用软件脚本中预先设定的程序及参数，自动获取每个应用层软件组件的配置文件信息，其中，配置文件信息包括配置文件的文件名、提供者接口名称、请求者接口名称、Interfaceming名称、Element名称以及Element的数据类型。

在一些实施例中，图2的查找模块203定义用于获取提供者接口信息和请求者接口信息的查询指令，响应于执行查询指令的操作，对配置文件信息中的相关字段进行分析，得到应用层软件组件的提供者接口信息和请求者接口信息。

在一些实施例中，图2的生成模块204在预定的数据结构中对每个应用层软件组件的请求者接口和提供者接口进行配对操作，根据配对结果，构建一个接口匹配矩阵，其中，接口匹配矩阵中包含所有可能的请求者接口和提供者接口组合，接口匹配矩阵中的每个单元格包含一个特定的接口配对信息。

在一些实施例中，图2的匹配模块205利用预定的匹配算法，对接口匹配矩阵进行遍历，以判断每个请求者接口是否有与其相对应的提供者接口，若判断请求者接口没有与其相对应的提供者接口时，将请求者接口标记为异常接口。

在一些实施例中，图2的匹配模块205对异常接口的接口名以及异常数据类型进行记录，并根据全部的异常接口的信息生成相应的编译失败报告，其中，异常数据类型用于表征请求者接口与提供者接口的数据类型不一致。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

图3是本申请实施例提供的电子设备3的结构示意图。如图3所示，该实施例的电子设备3包括：处理器301、存储器302以及存储在该存储器302中并且可以在处理器301上运行的计算机程序303。处理器301执行计算机程序303时实现上述各个方法实施例中的步骤。或者，处理器301执行计算机程序303时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序303可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器302中，并由处理器301执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序303在电子设备3中的执行过程。

电子设备3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等电子设备。电子设备3可以包括但不仅限于处理器301和存储器302。本领域技术人员可以理解，图3仅仅是电子设备3的示例，并不构成对电子设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如，电子设备还可以包括输入输出设备、网络接入设备、总线等。

处理器301可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器302可以是电子设备3的内部存储单元，例如，电子设备3的硬盘或内存。存储器302也可以是电子设备3的外部存储设备，例如，电子设备3上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器302还可以既包括电子设备3的内部存储单元也包括外部存储设备。存储器302用于存储计算机程序以及电子设备所需的其它程序和数据。存储器302还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围，均应包含在本申请的保护范围之内。

Claims (10)

1.一种基于AUTOSAR架构的软件组件接口检查方法，其特征在于，包括：

获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个所述应用层软件组件对应模型代码的配置文件；

将所述配置文件的路径添加到软件开发环境的工作路径中，并从所述配置文件中提取每个所述应用层软件组件对应的配置文件信息；

从所述配置文件信息中查找每个所述应用层软件组件对应的提供者接口信息和请求者接口信息；

利用所述提供者接口信息和所述请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部所述提供者接口信息和所述请求者接口信息汇总在一起；

对所述接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个所述请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录所述异常接口的信息。

2.根据权利要求1所述的方法，其特征在于，所述获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个所述应用层软件组件对应模型代码的配置文件，包括：

利用预定的AUTOSAR建模工具将所述应用层软件组件的模型代码导出，并利用预定的AUTOSAR配置工具，获取每个所述应用层软件组件对应的配置文件，其中，所述配置文件采用ARXML格式的文件。

3.根据权利要求1所述的方法，其特征在于，所述从所述配置文件中提取每个所述应用层软件组件对应的配置文件信息，包括：

利用软件脚本中预先设定的程序及参数，自动获取每个所述应用层软件组件的配置文件信息，其中，所述配置文件信息包括配置文件的文件名、提供者接口名称、请求者接口名称、Interfaceming名称、Element名称以及Element的数据类型。

4.根据权利要求3所述的方法，其特征在于，所述从所述配置文件信息中查找每个所述应用层软件组件对应的提供者接口信息和请求者接口信息，包括：

定义用于获取所述提供者接口信息和请求者接口信息的查询指令，响应于执行所述查询指令的操作，对所述配置文件信息中的相关字段进行分析，得到所述应用层软件组件的提供者接口信息和请求者接口信息。

5.根据权利要求1所述的方法，其特征在于，所述利用所述提供者接口信息和所述请求者接口信息，生成一个接口匹配矩阵，包括：

在预定的数据结构中对每个所述应用层软件组件的请求者接口和提供者接口进行配对操作，根据配对结果，构建一个所述接口匹配矩阵，其中，所述接口匹配矩阵中包含所有可能的请求者接口和提供者接口组合，所述接口匹配矩阵中的每个单元格包含一个特定的接口配对信息。

6.根据权利要求1所述的方法，其特征在于，所述对所述接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，包括：

利用预定的匹配算法，对所述接口匹配矩阵进行遍历，以判断每个所述请求者接口是否有与其相对应的提供者接口，若判断所述请求者接口没有与其相对应的提供者接口时，将所述请求者接口标记为所述异常接口。

7.根据权利要求6所述的方法，其特征在于，所述记录所述异常接口的信息，包括：

对所述异常接口的接口名以及异常数据类型进行记录，并根据全部的所述异常接口的信息生成相应的编译失败报告，其中，所述异常数据类型用于表征请求者接口与提供者接口的数据类型不一致。

8.一种基于AUTOSAR架构的软件组件接口检查装置，其特征在于，包括：

获取模块，被配置为获取基于AUTOSAR架构生成的应用层软件组件的模型代码，并获取每个所述应用层软件组件对应模型代码的配置文件；

提取模块，被配置为将所述配置文件的路径添加到软件开发环境的工作路径中，并从所述配置文件中提取每个所述应用层软件组件对应的配置文件信息；

查找模块，被配置为从所述配置文件信息中查找每个所述应用层软件组件对应的提供者接口信息和请求者接口信息；

生成模块，被配置为利用所述提供者接口信息和所述请求者接口信息，生成一个接口匹配矩阵，以将提取到的全部所述提供者接口信息和所述请求者接口信息汇总在一起；

匹配模块，被配置为对所述接口匹配矩阵进行分析，以判断每个请求者接口是否有与之匹配的提供者接口，若一个或多个所述请求者接口没有与之匹配的提供者接口时，将没有匹配成功的请求者接口作为异常接口，记录所述异常接口的信息。

9.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。