CN117527938A - 应用于车辆的通信协议栈自动化配置方法、装置及设备 - Google Patents

Abstract

本申请公开了一种应用于车辆的通信协议栈自动化配置方法、装置及设备，属于计算机技术领域。所述方法包括：获取控制系统对应的通信数据定义信息；对通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；基于通信协议栈配置信息，配置生成基础软件层模块对应的通信配置信息。本申请实施例提供的技术方案中，通过解析通信数据定义信息对通信协议栈进行自动化配置的方式，可以实现通信协议栈的自动化配置，并且能够进一步地基于通信协议栈配置信息，自动生成控制系统中基础软件层的通信配置信息，整体上大幅降低了手动配置的步骤，有效提升了开发效率。

Description

应用于车辆的通信协议栈自动化配置方法、装置及设备

技术领域

本申请涉及计算机技术领域，特别涉及一种应用于车辆的通信协议栈自动化配置方法、装置及设备。

背景技术

AUTOSAR(AUTOmotive Open System Architecture，汽车开放系统体系结构)是一个开放的汽车电子控制单元(Electronic Control Unit，ECU)标准软件架构。DBC(Database CAN)文件是一种常用的CAN(Controller Area Network。控制器局域网)总线数据定义文件，常用于CAN总线网络中的电子控制单元(ECU)通信中，主要作用是描述信号名称、物理值、信号长度、发送周期、计算公式、单位等信息。

相关技术中，在使用AUTOSAR CP(Classical Platform，经典平台)架构的项目开发时，CP中间件除了静态代码以外，开发人员通常需要对照DBC文件中的大量数据，通过工具链配置生成Arxml(AUTOSAR eXtensible Markup Language，AUTOSAR标准定义的数据交换)文件，然后通过代码生成引擎来生成特定于项目和应用的动态代码和配置文件。

对于CAN通信协议栈来说，若通信矩阵复杂、信号繁多的话，此过程手动配置的工作量非常巨大，费时费力，开发质量不易控制，且在进行其他类似系统的开发时，需要重复进行此项开发，操作复杂度非常高。

发明内容

本申请实施例提供了一种应用于车辆的通信协议栈自动化配置方法、装置及设备，能够对通信协议栈进行自动化配置，大幅降低了手动配置的步骤，从而提升开发效率。

根据本申请实施例的一个方面，提供了一种应用于车辆的通信协议栈自动化配置方法，所述车辆包括电子控制单元，所述电子控制单元基于控制系统驱动运行，所述控制系统包括基础软件层模块；所述方法包括：

获取所述控制系统对应的通信数据定义信息，所述通信数据定义信息表征所述车辆内的所述电子控制单元之间的通信方式；

对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；

基于所述通信协议栈配置信息，配置生成所述基础软件层模块对应的通信配置信息。

根据本申请实施例的一个方面，提供了一种应用于车辆的通信协议栈自动化配置装置，所述车辆包括电子控制单元，所述电子控制单元基于控制系统驱动运行，所述控制系统包括基础软件层模块；所述装置包括：

通信信息获取模块，用于获取所述控制系统对应的通信数据定义信息，所述通信数据定义信息表征所述车辆内的所述电子控制单元之间的通信方式；

通信协议栈配置模块，用于对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；

基础软件层配置模块，用于基于所述通信协议栈配置信息，配置生成所述基础软件层模块对应的通信配置信息。

根据本申请实施例的一个方面，提供了一种计算机设备，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现上述应用于车辆的通信协议栈自动化配置方法。

根据本申请实施例的一个方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现上述应用于车辆的通信协议栈自动化配置方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行以实现上述应用于车辆的通信协议栈自动化配置方法。

本申请实施例提供的技术方案可以带来如下有益效果：

通过获取车辆电子控制单元控制系统对应的通信数据定义信息，比如DBC通信矩阵文件，并对其进行解析，即可对通信协议栈进行配置，自动生成通信协议栈的配置信息，通过解析通信数据定义信息对通信协议栈进行自动化配置的方式，可以实现通信协议栈的自动化配置，并且能够进一步地基于通信协议栈配置信息，自动生成控制系统中基础软件层的通信配置信息，整体上大幅降低了手动配置的步骤，有效提升了开发效率。

附图说明

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

图1是本申请一个实施例提供的应用于车辆的通信协议栈自动化配置方法的流程图一；

图2示例性示出了一种DBC文件的文件格式示意图；

图3示例性示出了一种通信协议栈对应的系统描述文件的文件结构；

图4是本申请一个实施例提供的应用于车辆的通信协议栈自动化配置方法的流程图二；

图5示例性示出了一种自动生成的基础软件层模块及关系的示意图；

图6示例性示出了应用于CP工具链的CAN通信协议栈自动化配置的整体流程图；

图7是本申请一个实施例提供的应用于车辆的通信协议栈自动化配置装置的框图；

图8是本申请一个实施例提供的计算机设备的结构框图。

具体实施方式

在介绍本申请提供的方法实施例之前，先对本申请方法实施例中可能涉及的应用场景、相关术语或者名词进行简要介绍，以便于本申请领域技术人员理解。

AUTOSAR是一个开放和标准化的汽车电子软件架构，由汽车电子、半导体和软件行业的汽车制造商、供应商、服务提供商等公司组成的全球开发合作伙伴组织，它建立了一个开放的汽车电子控制单元(ECU)标准软件架构。AUTOSAR将汽车电子控制单元(ECU)的软件底层做了一个标准的封装，使得开发人员都能共用一套底层软件，只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。

DBC文件是一种常用的CAN总线数据定义文件，常用于CAN总线网络中的电子控制单元(ECU)通信中，主要作用是描述信号名称，物理值、信号长度、发送周期、计算公式、单位等信息。这些信息可以帮助不同的ECU之间进行通信，保证信息的准确性和可靠性。使用DBC文件可以简化CAN通信过程，从而提高CAN总线系统的可靠性和效率。

CAN最早出现在80年代末的汽车工业中，全称是“Controller Area Network”，即控制器局域网，是国际上应用最广泛的现场总线之一。随着汽车电子装置越来越多，它们之间的通信的控制也越来越复杂，CAN总线在汽车上的应用也越来越多。

AUTOSAR通信栈对应用层隐藏了与总线相关的协议和报文的属性。CAN通信发送机制为RTE(Runtime Environment，实时运行环境)>COM(Communication，通信模块)>PduR(Protocol Data Unit Router，协议数据单元路由模块)>CanIf(Can总线接口模块)>CANDriver(Can总线驱动模块)，过程描述如下：

Com模块获取应用层的信号(Signal)，经一定处理封装为I-PDU(InteractionLayer Protocol Data Unit)发送到PduR模块；PduR模块路由协议中所指定的I-PDU目标接收模块，将接收到的I-PDU经一定处理后发送给CanIf；CanIf将信号以L-PDU(Data LinkLayer Protocol Data Unit)的形式发送给CAN驱动模块。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

请参考图1，其示出了本申请一个实施例提供的应用于车辆的通信协议栈自动化配置方法的流程图一。该方法可应用于计算机设备中，所述计算机设备是指具备数据计算和处理能力的电子设备。该方法可以包括以下几个步骤(110～130)。

步骤110，获取控制系统对应的通信数据定义信息。

关于上述控制系统，控制系统是运行于车辆的电子控制单元内的控制系统，电子控制单元基于该控制系统驱动运行，上述车辆包括电子控制单元。其中，控制系统可以是基于AUTOSAR的底层软件系统。

控制系统包括基础软件层模块(Basic Software，BSW)、应用软件层模块(Application Layer)和实时运行环境层模块(RTE)。

关于上述通信数据定义信息，通信数据定义信息表征车辆内的电子控制单元之间的通信方式。可选地，通信数据定义信息可以是DBC文件。关于DBC文件的介绍可以参考方法实施例之前的简要介绍，这里不再赘述。

具体地，DBC文件包括如下内容：

一个DBC文件中有多个Networks(网络)，一个Network包含多个Network Nodes(网络节点)，一个Network Nodes包含多个Messages(消息)，一个Messages包含多个Signals(信号)，其结构如图2所示，图2示例性示出了一种DBC文件的文件格式示意图。

上述Network nodes是网络节点，可以通过它从单个节点的视角来观察与节点相关的所有：接收报文，发送报文，接收信号，发送信号。

上述Messages就是CAN报文，也是CAN总线上传输信息的最小单位。一条Message最大包含8个Byte的数据。

上述Signals是CAN信号，每个Signals都必需要分配在Message中。比如，它包含发动机的水温、当前车门的开关状态等信号。

步骤120，对通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息。

以上述通信数据定义信息为DBC文件为例，在对DBC文件解析时，相关关键字及含义如下：

BU：Nodename1 Nodename2 Nodename3……其中，BU_为关键字，表示网络节点定义；Nodename为网络节点名字，由用户自定义，名字需要唯一性，节点之间由空格分割。

BO_messageId messageName：messageSize transmitter{signals}其中，BO_为关键字，表示报文帧定义；messageId和messageName必须是唯一的；messageSize为消息长度；transmitter指消息发送节点，如果message没有指定发送节点则必须命名为Vector__XXX；signals指报文包含的所有信号。

SG_SignalName(SigTypeDefinition)：StartBit|SignalSize@ByteOrderValueType(Factor,Offset)[Min|Max]Unit Receiver。其中，SG_为关键字，表示信号的定义；SigTypeDefinition表示多路选择信号的定义，是可选项，有3种格式：1)a>空；2)b>M表示多路选择器信号；3)c>m50表示被多路选择器选择的信号，50表示当‘M’定义的信号的值等于50的时候，该报文使用此通路；StartBit|SignalSize表示该信号的起始位及信号长度；ByteOrder表示信号的字节顺序：0代表Motorola格式，1代表Inter格式；ValueType表示该信号的数值类型：+表示无符号数，-表示有符号数；Factor、Offset分别表示因子、偏移量；这两个值用于信号的原始值与物理值之间的转换。转换公式：物理值＝原始值*因子+偏移量；Min|Max表示该信号的最小值和最大值，即指定了该信号值的范围；这两个值为double类型；Unit表示该信号的物理单位，为字符串类型；Receiver表示该信号的接收节点(可以是多个节点)；若该信号没有指定的接收节点，则必须设置为”Vector__XXX”。

BA_DEF_Object AttributeName ValueType Min Max。其中，BA_DEF_为关键字，表示属性定义；Object表示属性定义的对象类型，可以是网络节点“BU_”、消息报文“BO_”、消息信号”SG_”、网络””(用空格表示)等；AttributeName表示进行定义的属性名字(一般比较固定，参照相应的标准)；ValueType表示属性值的类型，可以是整型、字符串、浮点型、枚举类型等；Min/Max表示属性值的上下最值，即指定了取值范围(字符串类型没有此项)。

BA_DEF_DEF_AttributeName DefaultValue。其中，BA_DEF_DEF_为关键字，表示定义属性的初始值；AttributeName表示进行定义的属性名字(一般比较固定，参照相应的标准)；DefaultValue表示该属性的初始值。

BA_AttributeName Object Key Value。其中，BA_为关键字，表示属性值的设置；AttributeName表示进行定义的属性名字(一般比较固定，参照相应的标准)；Object表示属性定义的对象类型，可以是网络节点“BU_”、消息报文“BO_”、消息信号”SG_”等；Key表示该属性值应用在哪个元素上，如果是网络节点“BU_”，该值为nodeName；如果是消息报文“BO_”，该值为messageId；如果是消息信号”SG_”，该值为messageId signalName；Value表示该属性的值。

通过对上述相关关键字及含义进行解析，可以得到DBC文件中的有效内容。根据DBC文件解析出来的内容，按照AUTOSAR生成包含CanCluster(Can总线特定的集群属性)、EcuInstance(电子控制单元实例)、CanFrame(通信框架元素)、ISignal(交互层的信号)、NmConfig(网络管理配置)、ISignalIPdu/NmPdu(交互层协议数据单元/网络管理协议数据单元)、SystemSignal(系统信号)等结构的通信协议栈配置信息。具体地，通信协议栈配置信息可以是ARXML格式的系统描述文件，系统描述文件可定义拓扑、软件、通信、映射和映射约束五个主要元素，其文件结构如图3所示，图3示例性示出了一种通信协议栈对应的系统描述文件的文件结构。

ARXML代表AUTOSAR XML，是用XML(Extensible Markup Language，可扩展标记语言)描述AUTOSAR模型的一种人机可读的文本格式。一般通过AUTOSAR标准的XSD(XMLStandard Definition，XML模式定义)进行约束，可以用专用的工具生成。和XML文件一样，ARXML是一个通用的配置/数据库文件，所以这里只需了解ARXML文件的结构。

ARXML的五种类型包括：System Configuration(系统配置)、ECU Extract(电子控制单元提取信息)、ECU Configuration(电子控制单元配置信息)、SWC Description(软件组件描述)、BSW Module Description(基础软件层模块描述)。

其中，System Configuration包含多个ECU的描述信息，它描述的是ECU之间的发送或接收信息以及跨ECU组件的接口和端口描述信息，另外还包含ECU的硬件资源信息。System Configuration从整车系统的角度描述ECU之间的交互信息。系统级主要考虑系统功能需求、硬件资源、系统约束，然后建立系统架构；

ECU Extract属于System Configuration的子集，它描述单个ECU发送或接收的信息，同样它包含了单个ECU内部包含的SWC以及SWC的详细信息，如接口定义和port定义等。ECU Extract可与通信矩阵一致。从系统级到ECU级的过渡操作是指ECU信息抽取。在系统配置阶段已经将每个ECU所包含的所有软件组件，网络通信等信息封装好，ECU信息抽取阶段只要将待配置ECU信息抽取出来即可，服务于之后的ECU配置。

ECU Configuration属于单个ECU范畴，它描述了SWC Description、ECU Extract和BSW模块等配置之后所有的信息。ECU级根据抽象的信息对ECU进行配置。

SWC Description描述了所有用户自定义的设计信息，包含SWC定义、运行实体、接口、端口数据类型的定义。

BSW Module Description属于标准模块信息，模块信息与代码包有关，不同供应商可能存在差异，但都符合AUTOSAR标准定义。

关于上述CanCluster(Can总线特定的集群属性)、EcuInstance(电子控制单元实例)、CanFrame(通信框架元素)、ISignal(交互层的信号)、NmConfig(网络管理配置)、ISignalIPdu/NmPdu(交互层协议数据单元/网络管理协议数据单元)、SystemSignal(系统信号)等结构的信息解析生成方式，可以参见下述实施例中的说明解释。

关于系统信号，系统信号表示通信系统对位于不同ECU上的SWC(基础软件组件，Software component)之间交换的数据的视图。相应地，在示例性实施例中，如图4所示，其示出了本申请一个实施例提供的应用于车辆的通信协议栈自动化配置方法的流程图二。其中，上述步骤120可以包括以下步骤(1201、1202)。

步骤1201，解析通信数据定义信息，得到通信数据定义信息中的信号列表信息。

可选地，根据DBC文件中的相关关键字及含义，可以解析得到signal列表，即上述信号列表信息。

步骤1202，基于信号列表信息生成系统信号信息。

可选地，根据DBC文件解析出来signal列表，确定各信号(signal)对应的名称、长度、描述等信息，进而可以根据各信号(signal)对应的名称、长度、描述等信息生成系统信号信息，即上述SystemSignal。

其中，所述系统信号信息表征位于不同所述电子控制单元的基础软件组件之间数据交换的信号信息；相应地，所述通信协议栈配置信息包括所述系统信号信息。

通过上述方式，可以将通信数据定义信息(DBC文件)中的系统信号信息自动提取出来，减少了人工手动配置操作，有效提升了开发效率。

关于上述ISignal(交互层的信号)，在示例性实施例中，如图4所示，在上述步骤1201之后，上述步骤120还包括以下步骤(1203)：

步骤1203，基于信号列表生成交互层单元对应的交互信号信息。

其中，基础软件层模块包括交互层单元，交互信号信息包括系统信号参数，系统信号参数与系统信号信息相关联，通信协议栈配置信息包括系统信号信息。

可选地，将上述信号列表中与交互层单元关联的信号进行提取，得到上述交互层单元对应的交互单元信息，同时，交互单元信息其中的系统信号参数与上述系统信号信息相关联。

如此，可以将通信数据定义信息(DBC文件)中，与交互层单元对应的交互信号信息自动提取出来，减少了人工手动配置操作，有效提升了开发效率。

关于上述ISignalIPdu/NmPdu(交互层协议数据单元/网络管理协议数据单元)，在示例性实施例中，如图4所示，上述步骤120可以包括以下步骤(1204～1206)：

步骤1204，解析通信数据定义信息，得到通信数据定义信息中的消息列表信息。

通过解析通信数据定义信息(DBC文件)中的消息，可以得到消息列表信息(message列表)，以便于后续自动配置生成协议数据单元对应的配置信息。

步骤1205，确定消息列表中的消息对应的消息类型。

上述配置协议数据单元对应的配置信息需要根据消息类型生成不同的结果。其中，消息类型包括网络配置类型(对应的消息类型关键字可以是Nm)和非网络配置类型(消息类型为除网络配置类型之外的其他消息类型)。

步骤1206，根据消息类型和消息列表信息，生成协议数据单元对应的配置信息。

其中，基础软件层模块包括协议数据单元(Protocol Data Unit，PDU)，通信协议栈配置信息包括协议数据单元对应的配置信息。

对于消息类型属于网络配置类型的消息，可以根据该消息生成网络管理协议数据单元对应的配置信息(NmPdu)。其中，协议数据单元包括网络管理协议数据单元。

对于消息类型属于非网络配置类型的消息，可以根据该消息生成交互层协议数据单元对应的配置信息(ISignalIPdu)。其中，协议数据单元包括交互层协议数据单元。其中，交互层协议数据单元对应的配置信息对应的交互层信号到协议数据单元的映射参数(ISignalToPduMapping)与交互信号信息(ISignal)相关联。

如此，通过解析通信数据定义信息(DBC文件)中的消息，可以得到消息列表信息(message列表)，并且根据消息类型，可以自动且有区分地生成相应的协议数据单元对应的配置信息，减少了人工手动配置操作，有效提升了开发效率。

关于NmConfig(网络管理配置)，上述步骤120还可以包括步骤：根据消息类型属于网络配置类型的消息，自动配置生成网络管理配置信息。具体地，根据DBC文件解析出来的类型为Nm的消息对应的消息名称、网络的NmAsr等参数信息生成NmConfig。

关于CanFrame(通信框架元素)，在示例性实施例中，如图4所示，上述步骤1204之后，上述步骤120还包括以下步骤(1207、1208)：

步骤1207，确定消息列表中的消息对应的消息名称信息和消息长度信息；

步骤1208，基于消息名称信息和消息长度信息确定通信框架元素信息，通信协议栈信息包括通信框架元素信息。

通过解析消息列表中的消息对应的名称、长度等信息，可以自动配置生成通信框架元素CanFrame，减少了人工手动配置操作，有效提升了开发效率。

关于CanCluster(Can总线特定的集群属性)，在示例性实施例中，如图4所示，上述步骤1204之后，上述步骤120还包括以下步骤(1209、1210)：

步骤1209，获取网络协议信息；

步骤1210，基于消息列表信息和网络协议信息，生成通信集群属性信息，通信协议栈信息包括通信框架元素信息。

根据DBC文件解析出来的message及上述网络协议等信息，可以自动配置生成通信集群属性信息，即上述Can总线特定的集群属性信息CanCluster，减少了人工手动配置操作，有效提升了开发效率。

关于EcuInstance(电子控制单元实例)，在示例性实施例中，如图4所示，上述步骤120还包括以下步骤(1211、1212)：

步骤1211，解析通信数据定义信息，得到通信数据定义信息中的通信节点信息；

上述通信节点信息包括通信节点名称。

步骤1212，基于通信节点信息生成电子控制单元对应的实例信息。

实例信息用于定义通信网络拓扑中使用的电子控制单元。

具体地，根据DBC文件解析出来的通信节点名称，可以自动生成电子控制单元实例(EcuInstance)的名称，上述电子控制单元对应的实例信息包括电子控制单元实例(EcuInstance)的名称。其中，ECU实例用于定义拓扑中使用的ECU。

如此，通过解析DBC文件中的通信节点信息，可以自动配置生成电子控制单元实例信息，减少了人工手动配置操作，有效提升了开发效率。

步骤130，基于通信协议栈配置信息，配置生成基础软件层模块对应的通信配置信息。

请参考图5，其示例性示出了一种自动生成的基础软件层模块及关系的示意图。其中，基础软件层模块包括Com模块(Communication，通信模块)、PduR模块(Protocol DataUnit Router，协议数据单元路由模块)、CanIf模块(Can总线接口模块)、ComM模块(Communication Manager，通信管理模块)、CanSM模块(CAN State Manager，CAN状态管理模块)、EcuC模块、NM模块(Network Management，网络管理模块)、CAN NM模块(CAN NetworkManagement，CAN总线网络管理模块)。其中，各个模块及模块间关系的介绍如下：

关于Com模块：Com模块位于运行实时环境RTE与PduR模块之间，其主要功能包括：将信号装载到I-PDU中发送，从接收到的I-PDU中解析出信号；提供信号路由功能，将接收到的I-PDU中的信号打包到发送I-PDU中；通信发送控制(启动/停止I-PDU组)；发送请求的应答等。

对于每个Com I-PDU根据DBC文件中message类型设定I-PDU的传输方向(ComIPduDirection)、信号处理方式(ComIPduSignalProcessing)、类型(ComIPduSignalRef)、所属的I-PDU工作组(ComIPduGroupRef)、Com信号引用(ComIPduSignalRef)、全局PDU引用(ComPduIdRef)等。

Com层中的Signal是应用层通过Com模块收发的基本单元，也是Com层内信息交互的基本单元，其需要引用系统信号(System Signal)。I-PDU作为Com层与下层网络交互的基本单元，可由一个或多个Signal信号组成，各信号在Com模块中装载和解析。

每个ComSignal需要配置信号的初始值(ComSignalInitValue)、发送属性(ComTransferProperty)、数据类型(ComSignalType)、字节顺序(ComSignalEndianness)、字节大小(ComSignalLength)、系统信号引用(ComSystemTemplateSystemSignalRef)等。

关于PduR模块：PduR模块是主要为通信接口模块、传输协议模块、诊断通信管理模块以及通信模块提供基于I-PDU的路由服务。它在通信协议栈中起着承上启下的作用，为上层服务基础软件模块和应用屏蔽了网络细节，使得上层基础软件模块和应用不用关心运行于那种总线网络之上。同时，PduR模块提供了基于I-PDU的网关功能，使得不同总线之间的通信成为可能。其中PduRDestPduRef/PduRSrcPduRef关联EcuC中的Pdu，PduRRoutingPath则定义了PDU的路由路径。

关于CanIf模块：CAN接口层(CanIf)是访问CAN总线的标准接口。CanIf抽象了CAN控制器的位置信息，并向上提供了一个与平台无关的接口，即上层不用关心CAN控制器是微控制器的片上设备还是片外设备。

CanIf模块根据DBC文件中message类型为硬件对象句柄(Hardware objecthandle，Hoh)，包括Hth(Hardware transmit handle)和Hrh(Hardware receive handle)等进行生成，它们需要引用Can模块中定义的CAN硬件对象。

关于ComM模块：通信管理模块(Communication Manager，ComM)可以简化总线通信栈的初始化、网络管理等，并可收集/协调总线通信访问请求。其中的ComMChannel包含了总线通道的配置参数。

关于CanSM模块：CAN状态管理器(CAN State Manager，CanSM)负责实现CAN网络控制流程的抽象，它为ComM模块提供API来请求CAN网络进行通信模式的切换。其中CanSMComMNetworkHandleRef关联ComM中的ComMChannel。

关于EcuC模块：EcuC模块是一个虚拟模块，它可以创建全局PDU，这用于连接每个模块的本地PDU。通过将全局PDU作为局部PDU的内部参数来进行连接。根据DBC文件中的message关联生成Pdu，Pdu的名字、长度如何等属性由message是发送还是接收以及message的长度决定。

关于NM模块：AUTOSAR Network Management(以下简称：AUTOSAR NM)，即“AUTOSAR网络管理”，是AUTOSAR体系中的网络管理机制。其中NmComMChannelRef关联ComM中的ComMChannel。

关于CAN NM模块：在AUTOSAR NM中，按照总线协议的类型，在CAN总线上使用的为CAN NM。其中CanNmRxPduRef/CanNmTxPduRef关联EcuC中的Pdu。

在AUTOSAR通信协议栈中，AUTOSAR通信协议栈对应用层隐藏了与总线相关的协议和报文的属性。CAN通信发送机制为RTE-->COM-->PduR-->CanIf-->CAN Driver，过程描述如下：Com模块获取应用层的信号(Signal)，经一定处理封装为I-PDU(Interaction LayerProtocol Data Unit)发送到PduR模块；PduR模块路由协议中所指定的I-PDU目标接收模块，将接收到的I-PDU经一定处理后发送给CanIf；CanIf将信号以L-PDU(Data Link LayerProtocol Data Unit)的形式发送给CAN驱动模块。由此可见，若通信矩阵复杂、信号繁多的话，此过程手动配置的工作量非常巨大，费时费力，开发质量不易控制，且在进行其他类似系统的开发时，需要重复进行此项开发，非常浪费人力物力。

而本申请实施例提供的技术方案，通过获取车辆电子控制单元控制系统对应的通信数据定义信息，比如DBC通信矩阵文件，并对其进行解析，即可对通信协议栈进行配置，自动生成通信协议栈的配置信息，通过解析通信数据定义信息对通信协议栈进行自动化配置的方式，可以实现通信协议栈的自动化配置，并且能够进一步地基于通信协议栈配置信息，自动生成控制系统中基础软件层的通信配置信息，整体上大幅降低了手动配置的步骤，有效提升了开发效率。

具体地，结合具体的应用场景--AUTOSAR系统开发场景而言，本申请实施例提供的技术方案，通过读入DBC通信矩阵文件，对CAN通信协议栈的相关模块如Com、PduR、CanIf、CanSM、CanNm、Nm、ComM等进行自动化配置，以大幅降低手动配置的工作量，从而提升开发效率。具体可参考图6，其示例性示出了应用于CP工具链的CAN通信协议栈自动化配置的整体流程图。其中，通过DBC文件的读取与解析，可以实现AUTOSAR规范的系统描述文件的转换生成，可以提供给多种CP工具链使用，用于BSW模块生成参考；并且最终能够自动化配置BSW模块，如Com、PduR、CanIf、CanSM、CanNm、Nm、ComM等，以大幅降低手动配置的工作量，从而提升开发效率。

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

请参考图7，其示出了本申请一个实施例提供的应用于车辆的通信协议栈自动化配置装置的框图。其中，所述车辆包括电子控制单元，所述电子控制单元基于控制系统驱动运行，所述控制系统包括基础软件层模块；该装置具有实现上述应用于车辆的通信协议栈自动化配置方法的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以是计算机设备，也可以设置在计算机设备中。该装置700可以包括：

通信信息获取模块710，用于获取所述控制系统对应的通信数据定义信息，所述通信数据定义信息表征所述车辆内的所述电子控制单元之间的通信方式；

通信协议栈配置模块720，用于对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；

基础软件层配置模块730，用于基于所述通信协议栈配置信息，配置生成所述基础软件层模块对应的通信配置信息。

综上所述，本申请实施例提供的技术方案，通过获取车辆电子控制单元控制系统对应的通信数据定义信息，比如DBC通信矩阵文件，并对其进行解析，即可对通信协议栈进行配置，自动生成通信协议栈的配置信息，通过解析通信数据定义信息对通信协议栈进行自动化配置的方式，可以实现通信协议栈的自动化配置，并且能够进一步地基于通信协议栈配置信息，自动生成控制系统中基础软件层的通信配置信息，整体上大幅降低了手动配置的步骤，有效提升了开发效率。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

请参考图8，其示出了本申请一个实施例提供的计算机设备的结构框图。该计算机设备可以是终端。该计算机设备用于实施上述实施例中提供的应用于车辆的通信协议栈自动化配置方法。具体来讲：

通常，计算机设备900包括有：处理器901和存储器902。

处理器901可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器901可以采用DSP(Digital Signal Processing，数字信号处理)、FPGA(FieldProgrammable Gate Array，现场可编程门阵列)、PLA(Programmable Logic Array，可编程逻辑阵列)中的至少一种硬件形式来实现。处理器901也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU(Central ProcessingUnit，中央处理器)；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器901可以在集成有GPU(Graphics Processing Unit，图像处理器)，GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器901还可以包括AI(Artificial Intelligence，人工智能)处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器902可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器902还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器902中的非暂态的计算机可读存储介质用于存储至少一个指令，至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集，且经配置以由一个或者一个以上处理器执行，以实现上述应用于车辆的通信协议栈自动化配置方法。

在一些实施例中，计算机设备900还可选包括有：外围设备接口903和至少一个外围设备。处理器901、存储器902和外围设备接口903之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口903相连。具体地，外围设备包括：射频电路904、触摸显示屏905、摄像头组件906、音频电路907、定位组件908和电源909中的至少一种。

本领域技术人员可以理解，图8中示出的结构并不构成对计算机设备900的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

在示例性实施例中，还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或所述指令集在被处理器执行时以实现上述应用于车辆的通信协议栈自动化配置方法。

可选地，该计算机可读存储介质可以包括：ROM(Read Only Memory，只读存储器)、RAM(Random Access Memory，随机存取记忆体)、SSD(Solid State Drives，固态硬盘)或光盘等。其中，随机存取记忆体可以包括ReRAM(Resistance Random Access Memory,电阻式随机存取记忆体)和DRAM(Dynamic Random Access Memory，动态随机存取存储器)。

在示例性实施例中，还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述应用于车辆的通信协议栈自动化配置方法。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。另外，本文中描述的步骤编号，仅示例性示出了步骤间的一种可能的执行先后顺序，在一些其它实施例中，上述步骤也可以不按照编号顺序来执行，如两个不同编号的步骤同时执行，或者两个不同编号的步骤按照与图示相反的顺序执行，本申请实施例对此不作限定。

另外，在本申请的具体实施方式中，涉及到用户信息等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

以上所述仅为本申请的示例性实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种应用于车辆的通信协议栈自动化配置方法，其特征在于，所述车辆包括电子控制单元，所述电子控制单元基于控制系统驱动运行，所述控制系统包括基础软件层模块；所述方法包括：

获取所述控制系统对应的通信数据定义信息，所述通信数据定义信息表征所述车辆内的所述电子控制单元之间的通信方式；

对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；

基于所述通信协议栈配置信息，配置生成所述基础软件层模块对应的通信配置信息。

2.根据权利要求1所述的方法，其特征在于，所述对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息，包括：

解析所述通信数据定义信息，得到所述通信数据定义信息中的信号列表信息；

基于所述信号列表信息生成系统信号信息；

其中，所述系统信号信息表征位于不同所述电子控制单元的基础软件组件之间数据交换的信号信息，所述通信协议栈配置信息包括所述系统信号信息。

3.根据权利要求2所述的方法，其特征在于，所述对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息，还包括：

基于所述信号列表生成交互层单元对应的交互信号信息；

其中，所述基础软件层模块包括所述交互层单元，所述交互信号信息包括系统信号参数，所述系统信号参数与所述系统信号信息相关联，所述通信协议栈配置信息包括所述系统信号信息。

4.根据权利要求1所述的方法，其特征在于，所述对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息，包括：

解析所述通信数据定义信息，得到所述通信数据定义信息中的消息列表信息；

确定所述消息列表中的消息对应的消息类型；

根据所述消息类型和所述消息列表信息，生成协议数据单元对应的配置信息；

其中，所述基础软件层模块包括所述协议数据单元，所述通信协议栈配置信息包括所述协议数据单元对应的配置信息。

5.根据权利要求4所述的方法，其特征在于，所述解析所述通信数据定义信息，得到所述通信数据定义信息中的消息列表信息之后，还包括：

确定所述消息列表中的消息对应的消息名称信息和消息长度信息；

基于所述消息名称信息和所述消息长度信息确定通信框架元素信息，所述通信协议栈信息包括所述通信框架元素信息。

6.根据权利要求4所述的方法，其特征在于，所述解析所述通信数据定义信息，得到所述通信数据定义信息中的消息列表信息之后，还包括：

获取网络协议信息；

基于所述消息列表信息和所述网络协议信息，生成通信集群属性信息，所述通信协议栈信息包括所述通信框架元素信息。

7.根据权利要求1所述的方法，其特征在于，所述对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息，包括：

解析所述通信数据定义信息，得到所述通信数据定义信息中的通信节点信息；

基于所述通信节点信息生成所述电子控制单元对应的实例信息，所述实例信息用于定义通信网络拓扑中使用的电子控制单元。

8.一种应用于车辆的通信协议栈自动化配置装置，其特征在于，所述车辆包括电子控制单元，所述电子控制单元基于控制系统驱动运行，所述控制系统包括基础软件层模块；所述装置包括：

通信信息获取模块，用于获取所述控制系统对应的通信数据定义信息，所述通信数据定义信息表征所述车辆内的所述电子控制单元之间的通信方式；

通信协议栈配置模块，用于对所述通信数据定义信息进行解析转换处理，自动生成通信协议栈配置信息；

基础软件层配置模块，用于基于所述通信协议栈配置信息，配置生成所述基础软件层模块对应的通信配置信息。

9.一种计算机设备，其特征在于，所述计算机设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至7任一项所述的应用于车辆的通信协议栈自动化配置方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由处理器加载并执行以实现如权利要求1至7任一项所述的应用于车辆的通信协议栈自动化配置方法。