CN110113196A - 一种协议配置方法、装置、设备及介质 - Google Patents

Abstract

本申请公开了一种协议配置方法，包括：获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；将所述配置文件转换为文档对象模型；根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。一方面，通过自动配置的方式大幅度减少了配置所需时间，提高了配置效率，另一方面，无需人工手动配置，降低了人力成本，并且降低了出错概率，提高了协议配置可靠性。本申请还公开了对应的装置、设备及介质。

Description

一种协议配置方法、装置、设备及介质

技术领域

本申请涉及计算机领域，尤其涉及一种协议配置方法、装置、设备及介质。

背景技术

协议，或者说网络协议是通信计算机双方必须共同遵从的一组约定。在进行网络部署时，为了确保网络中的设备之间能够通信，需要在设备上配置协议。

目前协议配置主要是人工手动进行配置的。在进行协议配置时，需要配置大量端口，具体包括每个端口的大小、地址、周期等信息，由于每个端口均为人工手动创建，导致人力成本和时间成本较高，而且出错概率高，影响网络通信可靠性。

因此，业界亟需提供一种协议配置方法，以减少用户操作，并降低出错概率。

发明内容

有鉴于此，本申请提供了一种协议配置方法，其通过将目标协议的配置文件转换为文档对象模型，将文档对象模型生成可执行文件，基于该可执行文件实现协议的自动配置，减少了用户操作，降低了人力成本和时间成本，而且降低了出错概率。对应地，本申请还提供了相应的装置、设备、介质及计算机程序产品。

本申请第一方面提供了一种协议配置方法，所述方法包括：

获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

将所述配置文件转换为文档对象模型；

根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

可选的，所述方法还包括：

获取与所述配置文件对应的验证文件，所述验证文件提供有针对所述配置文件的约束规则；

根据所述验证文件验证所述配置文件的内容是否与所述约束规则匹配，若验证成功，则再执行所述将所述配置文件转换为文档对象模型的步骤。

可选的，所述方法还包括：

若验证失败，则输出所述配置文件中验证失败的数据、验证失败的原因以及所述数据在所述配置文件中的位置。

可选的，所述目标协议包括多功能车辆总线协议、绞线式列车总线协议、车辆实时数据协议和基于控制局域网络的高层通信协议中的任意一种。

可选的，所述目标协议为所述多功能车辆总线协议时，所述基本配置信息包括如下配置段：

项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义；

其中，每个所述配置段包括至少一个配置项以及与所述配置项对应的值。

可选的，所述配置文件对应的验证文件包括数据类型约束规则、数据取值约束规则和数据表现形式规则中的至少一种。

可选的，所述将所述配置文件转换为文档对象模型包括：

利用基于逻辑编程平台开发的转换工具将所述配置文件转换为文档对象模型。

可选的，所述配置文件采用以下格式中的任意一种：

逗号分隔值、表格和文本格式。

本申请第二方面提供了一种协议配置装置，所述装置包括：

获取模块，用于获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

转换模块，用于将所述配置文件转换为文档对象模型；

生成模块，用于根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

配置模块，用于编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

可选的，所述获取模块还用于：

获取与所述配置文件对应的验证文件，所述验证文件提供有针对所述配置文件的约束规则；

所述装置还包括：

验证模块，用于根据所述验证文件验证所述配置文件的内容是否与所述约束规则匹配，若验证成功，则再执行所述将所述配置文件转换为文档对象模型的步骤。

可选的，所述验证模块还用于：

若验证失败，则输出所述配置文件中验证失败的数据、验证失败的原因以及所述数据在所述配置文件中的位置。

可选的，所述目标协议包括多功能车辆总线协议、绞线式列车总线协议、车辆实时数据协议和基于控制局域网络的高层通信协议中的任意一种。

可选的，所述目标协议为所述多功能车辆总线协议时，所述基本配置信息包括如下配置段：

项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义；

其中，每个所述配置段包括至少一个配置项以及与所述配置项对应的值。

可选的，所述配置文件对应的验证文件包括数据类型约束规则、数据取值约束规则和数据表现形式规则中的至少一种。

可选的，所述配置文件采用以下格式中的任意一种：

逗号分隔值、表格和文本格式。

本申请第三方面提供了一种设备，所述设备包括处理器以及存储器：

所述存储器用于存储计算机程序；

所述处理器用于根据所述计算机程序执行权利要求1至7任一项所述的方法。

本申请第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行本申请第一方面所述的方法。

本申请第五方面提供了一种包含计算机可读指令的计算机程序产品，当该计算机可读指令在计算机上运行时，使得计算机执行上述第一方面所述的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例提供了一种协议配置方法，其是通过将大量的重复性配置工作转换为程序自动执行实现的，具体地，获取目标协议的配置文件，该配置文件包括用于配置协议的基本配置信息，然后将该配置文件转换为文档对象模型，根据上述文档对象模型可以生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件，通过编译结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件生成可执行文件，并向下位机发送该可执行文件，指示下位机运行该可执行文件，从而实现协议自动配置。一方面，通过自动配置的方式大幅度减少了配置所需时间，提高了配置效率，另一方面，无需人工手动配置，降低了人力成本，并且降低了出错概率，提高了协议配置可靠性。此外，该方法能够适用多种协议，具有较好的兼容性、可扩展性。

附图说明

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

图1为本申请实施例中一种协议配置方法的场景架构图；

图2为本申请实施例中一种协议配置方法的流程图；

图3为本申请实施例中一种协议配置方法的流程图；

图4为本申请实施例中一种协议配置装置的结构示意图；

图5为本申请实施例中一种终端的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

针对现有技术中由人工手动配置协议导致配置时间长、成本高、出错概率高的技术问题，本申请提供了一种协议配置方法，其是通过将大量的重复性配置工作转换为程序自动执行实现的，一方面，通过自动配置的方式大幅度减少了配置所需时间，提高了配置效率，另一方面，无需人工手动配置，降低了人力成本，并且降低了出错概率，提高了协议配置可靠性。此外，该方法能够适用多种协议，具有较好的兼容性、可扩展性。

可以理解，该方法可以应用于任意具有数据处理能力的处理设备中。该处理设备可以是终端，也可以是服务器。其中，终端具体可以是桌面终端、便携式移动终端等设备，作为一个示例，终端可以是笔记本电脑，后文均以笔记本电脑进行示例性说明。

本申请提供的上述协议配置方法可以以计算机程序的形式存储于处理设备，处理设备通过执行上述应用程序实现本申请的协议配置方法。

为了使得本申请的技术方案更加清楚，易于理解，下面结合列车通信网(TrainCommunication Network，TCN)的场景对本申请的协议配置方法进行介绍。

参见图1所示的协议配置方法的场景架构图，该场景中包括终端10和列车通信网20，列车通信网20中包括牵引系统21、制动系统22……空调系统2n在内的多个设备，n为正整数，终端10作为上位机，列车通信网络中的牵引系统21、制动系统22……空调系统2n作为下位机，通过上位机实现对下位机的协议配置。

具体地，终端10获取目标协议的配置文件，将所述配置文件转换为文档对象模型，根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件，编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，然后终端10向下位机即列车通信网20中的设备，如牵引系统21、制动系统22以及空调系统2n等，发送所述可执行文件，指示所述下位机运行所述可执行文件，从而实现列车通信网20的协议配置。

接下来，将从终端的角度对本申请实施例提供的协议配置方法的各个步骤进行详细说明。

参见图2所示的协议配置方法的流程图，该方法包括：

S201：获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息。

目标协议是指待配置的协议。应用于车辆通信网络场景中，目标协议可以是多功能车辆总线(Multifunction Vehicle Bus，MVB)协议、绞线式列车总线(Wire Train Bus，WTB)协议、车辆实时数据(Train Real-time Data Protocol，TRDP)协议和基于控制局域网络的高层通信协议(Controller Area Network，CANopen)中的任意一种。

配置文件是指用于配置协议的文件，其携带有用于配置协议的基本配置信息。该基本配置信息通常由配置段组成，其中，配置段又有至少一个配置项组成，配置段至少包括端口信息、端口变量结构定义等，配置项表征该配置段的属性，如配置段为项目信息时，其配置项可以包括项目名称、日期、作者、公司和版本等多个配置项。

在本实施例中，配置文件可以采用以下格式中的任意一种：逗号分隔值(Comma-Separated Values，CSV)、表格excel和文本格式txt。通过采用上述格式生成配置文件，可以对协议进行规范化，在规定格式下，能够以高度直观的结构，批量地收集所有设备的配置信息，进而基于该配置信息生成所需要的变量类型声明和变量表文件，克服了手工配置的不便，极大的提高了配置效率。此外上述格式的配置文件能够适用多种编辑器，为用户带来方便。

为了便于理解，本申请提供了配置文件的一个示例，该配置文件包括的所有配置段可以基于下表的格式生成：

表1

其中，M和N均为正整数。需要说明的是，配置段名称唯一标识一个配置段，故不能重复。

S202：将所述配置文件转换为文档对象模型。

文档对象模型(Document Object Model，DOM)是一种处理可扩展标志语言的标准编程接口。在网页上，组织页面(或文档)的对象被组织在一个树形结构中，用来表示文档中对象的标准模型就称为DOM，其可以认为是页面上数据和结构的一个树形表示。

由于DOM可以以一种独立于平台和语言的方式访问和修改一个文档的内容和结构，因而采用DOM具有较好的平台兼容性和语言兼容性。

在本实施例中，终端可以通过转换工具自动将配置文件转换为DOM。该转换工具可以是基于逻辑编程平台开发得到的，其中，逻辑编程平台可以是openMPC软件应用平台。在具体实现时，终端通过运行所述转换工具，将输入的配置文件转换为对应的DOM，并输出该DOM。

S203：根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件。

结构体定义文件即TYP文件，包括配置目标协议所需要的各种结构体的定义。全局变量定义文件即POE文件，包括配置目标协议所需要的各种全局变量的定义，其中，全局变量的结构体类型在TYP文件中定义。程序逻辑文件也即ST文件，用于收集配置信息，调用下位机实现的函数完成设备配置。在实际应用时，针对一个下位机设备可以生成2个ST文件，其中，一个用于初始化，另一个用于周期运行。辅助文件为在配置目标协议时其他配置需要的文件。

以目标协议为MVB为例，终端通过访问DOM，将其转换为MVBTypes.TYP文件、MVBGlbVars.POE文件、MVB_Device1_INIT.ST、MVB_SET_Device1.ST和D2000.TXT文件。

其中，MVBTypes.TYP文件保护配置MVB需要的结构图类型的定义，MVBGlbVars.POE文件可以在逻辑编程平台如OpenMPC上使用，其符合国际电工委员会(InternationalElectro technical Commission，IEC)61131-3：2002标准(该标准对应于国家标准GB/T15969.3-2005)。

MVB_Device1_INIT.ST和MVB_SET_Device1.ST为在OpenMPC上可用的ST文件，用于收集MVB的配置信息，并调用下位机实现的函数，完成协议配置。具体地，MVB_Device1_INIT.ST用于初始化，MVB_SET_Device1.ST用于周期运行。在进行MVB配置时，D2000.TXT为辅助配置文件，用于总线管理器(Bus Administrator，BA)配置。

需要说明的是，终端在生成上述TYP文件、POE文件、ST文件和辅助文件时，可以是并行生成的，如此可以提高文件生成效率，进而提供协议配置效率，当然，上述文件也可以按照设定的顺序依次生成，在此种情形下，对终端的计算性能要求较低，很多终端均可以用于协议配置。

S204：编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

终端可以在逻辑编程平台如OpenMPC中编译结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，然后向下位机发送该可执行文件，下位机运行该可执行文件配置目标协议。

由上可知，本申请实施例提供了一种协议配置方法，包括获取目标协议的配置文件，该配置文件包括用于配置协议的基本配置信息，然后将该配置文件转换为文档对象模型，根据上述文档对象模型可以生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件，通过编译结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件生成可执行文件，并向下位机发送该可执行文件，指示下位机运行该可执行文件，从而实现协议自动配置。一方面，通过自动配置的方式大幅度减少了配置所需时间，提高了配置效率，另一方面，无需人工手动配置，降低了人力成本，并且降低了出错概率，提高了协议配置可靠性。此外，该方法能够适用多种协议，具有较好的兼容性、可扩展性。

在图2所示实施例中，终端还可以获取与所述配置文件对应的验证文件，该验证文件提供有针对所述配置文件的约束规则，然后终端可以根据所述验证文件验证所述配置文件的内容是否与所述约束规则匹配，若验证成功，也即配置文件各配置段各配置项的数据与约束规则匹配，则再执行所述将所述配置文件转换为文档对象模型的步骤。如此，提前检查出配置文件中的错误，避免影响后续配置过程，提高配置成功率。

进一步地，若验证失败，也即至少有一个配置段中的配置项的数据与所述约束规则不匹配，则终端还可以输出所述配置文件中验证失败的数据、验证失败的原因以及所述数据在所述配置文件中的位置。其中，验证失败的数据具体是指配置文件中与约束规则不匹配的数据，该数据在配置文件中的位置可以通过其在配置文件的行列进行表征，当然在实际应用时，也可以在配置文件中增加相应的定位符指示该数据在配置文件中的位置。

配置文件对应的验证文件包括约束规则，具体可以是数据类型约束规则、数据取值约束规则和数据表现形式规则中的至少一种。具体地，根据配置项的数据类型不同，其可以使用的约束规则可以上述规则中的一种或多种。

在实际应用时，终端可以采用JS对象表示法(JavaScript Object Notation，JSON)格式存储约束规则，也即验证文件可以采用JSON格式。如此，当约束条件发生变化时，终端不需要修改转换工具代码，只需要使用文本编辑器，修改约束规则即可，提高了适应性。

针对图2所述实施例，当目标协议为MVB时，所述基本配置信息包括如下配置段：项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义；其中，每个所述配置段包括至少一个配置项以及与所述配置项对应的值。

上述项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义等配置段的格式及其约束规则依次如下所示：

1.1项目信息

表2

其中，项目信息包含5个配置项，其对应的约束规则如下：

表3

1.2设备地址

该配置段用于配置设备地址，其格式如下表所示：

表4

设备地址仅包含3个配置项，其约束规则如下：

表5

配置项名称	数据类型	说明	约束条件
				device_name	String	设备名称	非空，唯一
device_address	String	设备地址	16进制表示，0-255，非空
				device_description	String	设备描述	可空

1.3板卡信息

该配置段格式如下所示：

表6

板卡信息包含8个配置项，其约束规则具体如下所示：

表7

1.4端口信息

端口信息配置段格式如下：

表8

端口信息包含10个配置项，其约束规则如下：

表9

1.5消息数据

消息数据配置段格式如下：

表10

消息数据包含13个配置项，其约束规则如下所示：

表11

1.6端口变量结构定义

端口变量结构定义配置段格式如下：

表12

端口变量结构定义包含8个配置项，其约束规则具体如下所示：

表13

1.7消息变量定义

消息变量定义配置段格式如下：

表14

消息变量包含12个配置项，其约束规则具体如下表所示：

表15

配置项名称	数据类型	说明	约束条件
				struct_name	String		非空，必须出现在MDPortConfig中
mvno	Int		非空，唯一，取值范围0到255
				enable	Bool		非空，取值范围0或1
variable_name	String		非空，唯一，最长32个字符
				description	String		非空，最长32个字符
byte_offset	Int		非空
				bit_offset	Int		非空，取值范围0或7
var_type	Enum		非空，详细见第10节

1.8数据类型长度

当生成结构体定义时，将用户数据转换为IEC类型，其中，数据类型长度配置段格式如下：

表16

终端对上述文件中的配置参数进行提取，可以得到用于BA管理的所有过程数据和消息数据端口信息，基于该信息可以生成BA文件。在MVB协议配置时，以下函数在ST文件中调用，实现协议配置，具体如下所示：

1、MvbCardNumConfig，用于设置板卡级别的信息；3、MvbGetCardStatus，用于返回板卡初始化状态信息(包括过程数据初始化配置以及消息数据初始化配置成功与否信息)；4、MvbPortConfig，用于设置过程数据端口信息，无输出信息；5、MvbSourcePortUpdate，用来周期性将源端口更新写入数据信息，并周期性输出端口写数据状态信息；6、MvbSinkPortUpdate，用来周期性更新宿端口数据信息，并同时更新端口读状态信息以及宿端口数据新鲜度信息；7、MvbMsgConfig，用来设置消息数据的相关配置信息；8、MvbMsgUpdate，用于更新消息数据收发信息及状态信息；9、MvbDswRead，用于实现读取MVB总线上的该设备的被配置的状态字，由用户根据需求选择是否使用，若使用，则返回MVB的设备状态字以及执行相关状态信息；10、MvbInit，用来执行MVB驱动的初始化；11、MvbUpdateCard，用于通知下位机新的板卡设置开始；12、MvbUpdateEnd，用于读写周期性的消息数据和过程数据。

其中，序号1至5和7、10对应的函数功能块仅运行一次，需要说明的是，序号3对应的函数功能块在MVB初始化完成之后调用，而序号6、8、9、11和12对应的函数功能块周期性运行。

为了更加易于理解本申请的技术方案，本申请还提供了配置MVB协议的具体实施例。

参见图3所示的协议配置方法的流程图，该方法包括：

步骤S1，终端按行读取用户提供的CSV数据文件到内存。

步骤S2，终端读取验证文件，使用开源的JSON解析器Newtonsoft进行验证文件进行反序列化为.NET的对象模型。

步骤S3，终端根据验证规则，验证CSV数据文件中的内容，是否与约束规则完全匹配。

每个配置项的定义如下，然后根据配置项的数据类型不同，可使用的规则是其中的一条或多条，如下所示：

步骤S4，如果数据文件通过验证，则将CSV文件内容转换到.NET的DOM对象中，通过该DOM对象，可以方便的对其中的数据进行访问。如果验证失败，则跳转至步骤S12。

步骤S5，终端访问DOM对象，生成TYP文件(MVBTypes.TYP)，该文件包含需要的结构体类型的定义。

步骤S6，终端访问DOM对象，将其转换为OpenMPC可以使用的POE文件(MVBGlbVars.poe)，该文件符合IEC 61131-3：2002标准(GB/T15969.3-2005)，文件包含了MVB所需要的全局变量定义。

步骤S7，终端访问DOM对象，将其转换为OpenMPC可以使用的ST文件。

CSV中的每个设备会生成2个ST文件，一个用于初始化(MVB_Device1_INIT.ST)，另一个用于周期运行(MVB_SET_Device1.ST)。

步骤S8，终端生成D2000.TXT配置文件，用于BA配置。

步骤S9，终端打开OpenMPC并导入生成好的TYP、POE，以及所有的ST文件，进行编译。

步骤S10，终端通过OpenMPC将这些配置信息下装到下位机的运行环境中。

具体地，终端通过上位机过程控制程序CFC将MVB配置信息传输到下位机运行环境中。

步骤S11，下位机获得从上位机即终端中传输过来的信息，组织构造为C语言的MVB结构体并填充数据，最终由下位机Runtime(运行时)对MVB进行配置。

步骤S12，当步骤S4验证数据文件失败时，终端输出所有验证失败的数据，包括数据在CSV文件中的行、列，以及验证失败的详细原因，方便快速的定位错误，以及重新编辑数据文件。

以上为本申请实施例提供的协议配置方法的一些具体实现方式，基于此，本申请还提供了对应的装置，下面将从功能模块化的角度对上述装置进行介绍。

参见图4所示的协议配置装置的结构示意图，该装置400包括：

获取模块410，用于获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

转换模块420，用于将所述配置文件转换为文档对象模型；

生成模块430，用于根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

配置模块440，用于编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

可选的，所述获取模块410还用于：

获取与所述配置文件对应的验证文件，所述验证文件提供有针对所述配置文件的约束规则；

所述装置400还包括：

验证模块，用于根据所述验证文件验证所述配置文件的内容是否与所述约束规则匹配，若验证成功，则再执行所述将所述配置文件转换为文档对象模型的步骤。

可选的，所述验证模块还用于：

若验证失败，则输出所述配置文件中验证失败的数据、验证失败的原因以及所述数据在所述配置文件中的位置。

可选的，所述配置文件对应的验证文件包括数据类型约束规则、数据取值约束规则和数据表现形式规则中的至少一种。

可选的，所述目标协议包括多功能车辆总线协议、绞线式列车总线协议、车辆实时数据协议和基于控制局域网络的高层通信协议中的任意一种。

可选的，所述目标协议为所述多功能车辆总线协议时，所述基本配置信息包括如下配置段：

项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义；

其中，每个所述配置段包括至少一个配置项以及与所述配置项对应的值。

可选的，所述配置文件采用以下格式中的任意一种：

逗号分隔值、表格和文本格式。

基于本申请实施例提供的上述方法、装置，本申请实施例还提供了一种设备，用于协议配置，下面将从硬件实体化的角度，对该设备进行介绍。

参见图5所示的设备的结构示意图，该设备具体为终端，如图5所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该终端可以为包括手机、平板电脑、个人数字助理(英文全称：Personal DigitalAssistant，英文缩写：PDA)、销售终端(英文全称：Point of Sales，英文缩写：POS)、车载电脑等任意终端设备，以终端为手机为例：

图5示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图5，手机包括：射频(英文全称：Radio Frequency，英文缩写：RF)电路510、存储器520、输入单元530、显示单元540、传感器550、音频电路560、无线保真(英文全称：wireless fidelity，英文缩写：WiFi)模块570、处理器580、以及电源590等部件。本领域技术人员可以理解，图5中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储器520可用于存储软件程序以及模块，处理器580通过运行存储在存储器520的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器520可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器520可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

处理器580是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器520内的软件程序和/或模块，以及调用存储在存储器520内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器580可包括一个或多个处理单元；优选的，处理器580可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器580中。

在本申请实施例中，该终端包括的处理器580具有以下功能；

获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

将所述配置文件转换为文档对象模型；

根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

可选的，所述处理器580还用于执行本申请实施例提供的协议配置方法的任意一种实现方式的步骤。

本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行本申请所述的协议配置方法。

本申请实施例提供了一种包含计算机可读指令的计算机程序产品，当该计算机可读指令在计算机上运行时，使得计算机执行本申请所述的协议配置方法。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

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

Claims (10)

1.一种协议配置方法，其特征在于，所述方法包括：

获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

将所述配置文件转换为文档对象模型；

根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

获取与所述配置文件对应的验证文件，所述验证文件提供有针对所述配置文件的约束规则；

根据所述验证文件验证所述配置文件的内容是否与所述约束规则匹配，若验证成功，则再执行所述将所述配置文件转换为文档对象模型的步骤。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

若验证失败，则输出所述配置文件中验证失败的数据、验证失败的原因以及所述数据在所述配置文件中的位置。

4.根据权利要求2所述的方法，其特征在于，所述配置文件对应的验证文件包括数据类型约束规则、数据取值约束规则和数据表现形式规则中的至少一种。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述目标协议包括多功能车辆总线协议、绞线式列车总线协议、车辆实时数据协议和基于控制局域网络的高层通信协议中的任意一种。

6.根据权利要求5所述的方法，其特征在于，所述目标协议为所述多功能车辆总线协议时，所述基本配置信息包括如下配置段：

项目信息、设备地址、板卡信息、端口信息、消息数据、端口变量结构定义和消息变量结构定义；

其中，每个所述配置段包括至少一个配置项以及与所述配置项对应的值。

7.根据权利要求1至3任一项所述的方法，其特征在于，所述配置文件采用以下格式中的任意一种：

逗号分隔值、表格和文本格式。

8.一种协议配置装置，其特征在于，所述装置包括：

获取模块，用于获取目标协议的配置文件，所述配置文件包括用于配置协议的基本配置信息；

转换模块，用于将所述配置文件转换为文档对象模型；

生成模块，用于根据所述文档对象模型生成结构体定义文件、全局变量定义文件、程序逻辑文件和辅助文件；

配置模块，用于编译所述结构体定义文件、所述全局变量定义文件、所述程序逻辑文件和所述辅助文件生成可执行文件，并向下位机发送所述可执行文件，指示所述下位机运行所述可执行文件。

9.一种设备，其特征在于，所述设备包括处理器以及存储器：

所述存储器用于存储计算机程序；

所述处理器用于根据所述计算机程序执行权利要求1至7任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储计算机程序，所述计算机程序用于执行权利要求1至7任一项所述的方法。