一种菜单生成方法、菜单生成装置及诊断设备

技术领域

本申请属于车辆诊断技术领域，尤其涉及一种菜单生成方法、菜单生成装置、诊断设备及计算机可读存储介质。

背景技术

传统诊断软件通过设置固定的系统菜单，来执行相关诊断功能。这种诊断方式虽然简单，但是灵活性也较差：如果车型协议发生改变，或者某个车型的电子系统新增某些功能，就需要研发人员手动增加相应的菜单选项和代码。

发明内容

本申请提供了一种菜单生成方法、菜单生成装置、诊断设备及计算机可读存储介质，可以实现诊断功能菜单的动态生成，使得诊断设备的使用更具灵活性。

第一方面，本申请提供了一种菜单生成方法，包括：

根据待诊断车辆的车型，加载上述车型所对应的源文件；

基于上述源文件生成动态链接库，其中，每一源文件唯一的对应上述动态链接库的一个接口，上述动态链接库的每一个接口唯一的对应一个诊断功能；

基于上述源文件及上述动态链接库生成菜单配置文件；

在确定待诊断车辆的待诊断系统后，加载上述菜单配置文件，获得与上述待诊断系统相关联的诊断功能的名称，以生成上述待诊断系统的诊断功能菜单，其中，上述待诊断系统为用户所选择的待诊断车辆的电子系统。

可选地，在生成上述待诊断系统的诊断功能菜单后，上述菜单生成方法还包括：

根据基于上述诊断功能菜单所输入的诊断功能选择指令，确定目标诊断功能；

调用目标接口，以执行上述目标诊断功能的诊断操作，其中，上述目标接口为上述动态链接库中上述目标诊断功能所对应的接口。

可选地，上述调用目标接口，包括：

在上述菜单配置文件中，根据上述目标接口的名称，查找上述目标接口的函数地址；

通过上述函数地址调用上述目标接口。

可选地，上述根据待诊断车辆的车型，加载上述车型所对应的源文件，包括：

根据上述待诊断车辆的车型，获取预设的车型系统配置文件及上述车型下的每个系统所分别对应的源文件；

基于上述车型系统配置文件，检测各个源文件是否正确；

若上述各个源文件均正确，则加载上述各个源文件。

可选地，上述基于上述车型系统配置文件，检测各个源文件是否正确，包括：

针对获取到的每个源文件，根据上述源文件的文件名，确定上述源文件所对应的电子系统的名称；

检测上述车型系统配置文件中是否存在上述源文件所对应的电子系统的名称；

若上述车型系统配置文件中存在上述源文件所对应的电子系统的名称，则确定上述源文件正确。

可选地，在上述基于上述车型系统配置文件，检测各个源文件是否正确之后，上述菜单生成方法还包括：

若存在一个以上源文件不正确，则输出错误提示，以提醒源文件内容错误。

可选地，上述基于上述源文件生成动态链接库，包括：

针对上述车型所对应的每个源文件，将上述源文件的内容转换为代码，以得到对应的代码文件，其中，上述代码采用预设的编程语言；

将所得到的所有代码文件编译成动态链接库。

第二方面，本申请提供了一种菜单生成装置，包括：

第一加载单元，用于根据待诊断车辆的车型，加载上述车型所对应的源文件；

第一生成单元，用于基于上述源文件生成动态链接库，其中，每一源文件唯一的对应上述动态链接库的一个接口，上述动态链接库的每一个接口唯一的对应一个诊断功能；

第二生成单元，用于基于上述源文件及上述动态链接库生成菜单配置文件；

第二加载单元，用于在确定待诊断车辆的待诊断系统后，加载上述菜单配置文件，获得与上述待诊断系统相关联的诊断功能的名称，以生成上述待诊断系统的诊断功能菜单，其中，上述待诊断系统为用户所选择的待诊断车辆的电子系统。

可选地，上述菜单生成装置还包括：

功能确定单元，用于根据基于上述诊断功能菜单所输入的诊断功能选择指令，确定目标诊断功能；

接口调用功能，用于调用目标接口，以执行上述目标诊断功能的诊断操作，其中，上述目标接口为上述动态链接库中上述目标诊断功能所对应的接口。

可选地，上述调用目标接口，包括：

函数地址查找子单元，用于在上述菜单配置文件中，根据上述目标接口的名称，查找上述目标接口的函数地址；

目标接口调用子单元，用于通过上述函数地址调用上述目标接口。

可选地，上述第一加载单元，包括：

源文件获取子单元，用于根据上述待诊断车辆的车型，获取预设的车型系统配置文件及上述车型下的每个系统所分别对应的源文件；

源文件检测子单元，用于基于上述车型系统配置文件，检测各个源文件是否正确；

源文件加载子单元，用于若上述各个源文件均正确，则加载上述各个源文件。

可选地，上述源文件检测子单元，包括：

名称确定子单元，用于针对获取到的每个源文件，根据上述源文件的文件名，确定上述源文件所对应的电子系统的名称；

名称检测子单元，用于检测上述车型系统配置文件中是否存在上述源文件所对应的电子系统的名称；

结果确定子单元，用于若上述车型系统配置文件中存在上述源文件所对应的电子系统的名称，则确定上述源文件正确。

可选地，上述结果确定子单元，还用于若存在一个以上源文件不正确，则输出错误提示，以提醒源文件内容错误。

可选地，上述第一生成单元，包括：

转换子单元，用于针对上述车型所对应的每个源文件，将上述源文件的内容转换为代码，以得到对应的代码文件，其中，上述代码采用预设的编程语言；

编译子单元，用于将所得到的所有代码文件编译成动态链接库。

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

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

第五方面，本申请提供了一种计算机程序产品，上述计算机程序产品包括计算机程序，上述计算机程序被一个或多个处理器执行时实现如上述第一方面的方法的步骤。

本申请与现有技术相比存在的有益效果是：不再将诊断功能菜单写死在代码中，而是在用户选择待诊断车辆的车型后，选择待诊断系统前，先根据该车型所对应的源文件来生成动态链接库，进而生成菜单配置文件，之后再由用户选择待诊断系统，并通过加载菜单配置文件来获得与该待诊断系统相关联的诊断功能的名称，基于此实现诊断功能菜单的动态生成，可使得诊断设备的使用更具灵活性。可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

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

图1是本申请实施例提供的菜单生成方法的实现流程示意图；

图2是本申请实施例提供的菜单生成方法中步骤101的具体实现流程示意图；

图3是本申请实施例提供的菜单生成方法中步骤102的具体实现流程示意图；

图4是本申请实施例提供的菜单生成装置的结构框图；

图5是本申请实施例提供的诊断设备的结构示意图。

具体实施方式

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

传统诊断软件通过设置固定的系统菜单，来执行相关诊断功能，其诊断流程为：在诊断界面上，先由用户选择待诊断车辆的车型；然后再由用户选择具体的电子系统，例如发动机系统、仪表系统或安全气囊系统等；在进入用户所选电子系统的诊断功能菜单页面后，再基于用户的选择来执行对应的诊断功能。通常来说，该页面显示的是固定菜单，需要由研发人员预先根据车型协议来为其下的每个电子系统配置相应的菜单；也即，通过该页面所能够执行的诊断功能已写死在了代码中，这导致当前的诊断方式较为死板，难以灵活适应外部环境的变化。基于此，本申请实施例提出了一种菜单生成方法、菜单生成装置、诊断设备及计算机可读存储介质，可以实现诊断功能菜单的动态生成，使得诊断设备的使用更具灵活性。为了说明本申请实施例所提出的技术方案，下面通过具体实施例来进行说明。

下面对本申请实施例提供的一种菜单生成方法进行描述。请参阅图1，该菜单生成方法包括：

步骤101，根据待诊断车辆的车型，加载上述车型所对应的源文件；

在本申请实施例中，在诊断设备与待诊断车辆建立连接后，可先确定该待诊断车辆的车型。示例性地，可以是在诊断设备上显示车型选择界面，并在接收到用户输入的车型选择指令后，将该车型选择指令所指向的车型确定为待诊断车辆的车型；或者，也可以是通过读取待诊断车辆的车辆识别号码(Vehicle Identification Number，VIN)后，基于该VIN码确定待诊断车辆的车型。在确定待诊断车辆的车型后，即可加载该车型所对应的源文件。示例性地，该源文件可以为OTX格式，由车辆制造商所提供；源文件名称中包含对应的电子系统的名称及功能类型，并以“_”连接。例如，源文件EMS_Learning.otx，其中的“EMS”表示发动机系统，“Learning”表示自学习功能。

具体地，考虑到车辆的一个系统可能存在有多个诊断功能，每一个诊断功能唯一的对应着一个源文件，且不同诊断功能所对应的源文件不同，因而，上述步骤101可以包括：

步骤1011，根据上述待诊断车辆的车型，获取预设的车型系统配置文件及上述车型下的每个系统所分别对应的源文件；

针对每一个车型，可以预先创建一车型系统配置文件，该车型系统配置文件中包含了该车型的所有系统的名称。在确定待诊断车辆的车型后，可根据该车型获取对应的车型系统配置文件；同时，还可根据该车型获取对应的车辆制造商所提供的该车型下的每个系统所分别对应的源文件。

步骤1012，基于上述车型系统配置文件，检测各个源文件是否正确；

为了保障每个系统所对应的源文件均正确，避免出现源文件多、源文件少或源文件与系统对应不上的情况，可基于该车型系统配置文件对诊断设备所获取到的各个源文件是否正确进行检测。具体地，考虑到通常车辆制造商会以系统的名称作为源文件的文件名，因而，针对每个待检测的源文件，可先获取该源文件的文件名，并将该源文件的文件名与该车型的车型系统配置文件中所配置的电子系统的名称进行比对，也即，检测该车型系统配置文件中是否存在该源文件所对应的电子系统的名称；若该车型系统配置文件中存在有系统的名称与该源文件的文件名相同，也即，若该车型系统配置文件中存在该源文件所对应的电子系统的名称，则确定该源文件正确；反之，若该车型系统配置文件中没有任何系统的名称与该源文件的文件名相同，也即，若该车型系统配置文件中不存在该源文件所对应的电子系统的名称，则确定该源文件不正确。

步骤1013，若上述各个源文件均正确，则加载上述各个源文件。

当确定诊断设备针对该待诊断车辆的车型所获取到的所有源文件均正确时，即可加载这些源文件，以准备后续的诊断操作；反之，当确定诊断设备针对该待诊断车辆的车型所获取到的源文件中，有任意源文件不正确时，即可输出错误提示，用以提醒当前诊断设备所获取到的源文件内容错误。

在一些实施例中，考虑到源文件的文件名可能会被更改，因而，可以在源文件内部设置一个package属性，该package属性值与该源文件原始的文件名保持一致。下面给出源文件的一个示例：

源文件ACU_ActivitationFunction_Check.otx，其文件名即为“.otx”之前的部分，也即ACU_ActivitationFunction_Check。该源文件中包括如下内容：

otx package＝”ACU_ActivitationFunction_Check”

其中，“otx package”即为该源文件的package属性，具体的package属性值为“ACU_ActivitationFunction_Check”。由于源文件的内容很少被更改，因而可通过读取源文件的package属性来获取源文件的文件名，这一定程度增加了信息获取的准确性。

步骤102，基于上述源文件生成动态链接库，其中，每一源文件唯一的对应上述动态链接库的一个接口，上述动态链接库的每一个接口唯一的对应一个诊断功能；

在本申请实施例中，在加载了待诊断车辆的车型所对应的所有源文件后，即可基于上述源文件生成动态链接库。具体地，上述步骤102可以包括：

步骤1021，针对上述车型所对应的每个源文件，将上述源文件的内容转换为代码，以得到对应的代码文件；

诊断设备可以按照源文件的流程逻辑，将其转换为代码，该代码采用预设预设的编程语言，例如C或C++等，此处不作限定。所得到的代码文件可以是.h文件，或者，也可以是.cpp文件，此处不作限定。

步骤1022，将所得到的所有代码文件编译成动态链接库。

诊断设备可以将转换所得的所有代码文件编译成一个动态链接库。其中，考虑到基于一个源文件转换所得到的对应的代码文件的内容可能存在多个函数，但在这多个函数中，仅可能存在一个入口函数；因而，每一个代码文件均可将其自身的入口函数导出作为动态链接库的一个接口。需要注意的是，所得到的入口函数(也即接口)的命名规则为：package属性值+“_main”。例如，上文所示例子中的ACU_ActivitationFunction_Check源文件的入口函数(也即接口)的名称可以是：ACU_ActivitationFunction_Check_main。

步骤103，基于上述源文件及上述动态链接库生成菜单配置文件；

在本申请实施例中，诊断设备在加载了所需要的所有源文件并生成了动态链接库后，可基于此继续生成菜单配置文件。其中，该菜单配置文件中包括有多个“FUNCTION”节点，也即诊断功能节点；每个“FUNCTION”节点包含一个系统的名称属性“ECU-NAME”，该名称属性值是通过源文件的package属性来获取的；并且，每个“FUNCTION”节点下还包含诊断功能的名称，该诊断功能的名称可被作为菜单项显示在诊断功能菜单页面；除此之外，每个“FUNCTION”节点下还包含该诊断功能所对应的源文件和基于该源文件所导出的接口的名称。下面给出菜单配置文件的文件内容的一个示例：

安全校验

刷写安全校验

ACU_ActivitationFunction_Check.otx

ACU_ActivitationFunction_Check_main

其中，SHORT-NAME为诊断功能的短名称，虽然上述例子中SHORT-NAME为中文“安全校验”，但在应用中实际应为英文，其与对应的源文件的功能类型保持一致；LONG-NAME为真实的诊断功能的名称，具体以数字ID来标识，以适应多语言。诊断设备最终是根据该LONG-NAME所标识的数字ID来去文本库中查找该诊断功能所要显示在诊断功能菜单上的文本(也即菜单项)。

步骤104，在确定待诊断系统后，加载上述菜单配置文件，获得与上述待诊断系统相关联的诊断功能的名称，以生成上述待诊断系统的诊断功能菜单，其中，上述待诊断系统为用户所选择的待诊断车辆的电子系统。

在本申请实施例中，用户所选择的待诊断车辆的电子系统为等待进行诊断的电子系统，也即待诊断系统。诊断设备可在确定了待诊断系统后，对步骤103中所获得的菜单配置文件进行加载。由于菜单配置文件中包含有每个系统的多个诊断功能节点，且每个诊断功能节点均包含有诊断功能的名称，因而可从加载后的菜单配置文件中获得与待诊断系统相关联的诊断功能的名称，并以此生成该待诊断系统的诊断功能菜单。也即，最终该诊断功能菜单中会显示有与待诊断系统相关联的各个诊断功能的名称。

需要注意的是，步骤101-103均是在确定了待诊断车辆的车型后，且用户选择待诊断系统前执行并完成；当用户选择了待诊断车辆的电子系统后，也即确定待诊断系统后，即可执行步骤104，加载菜单配置文件，根据该菜单配置文件的“ECU-NAME”属性，获取该待诊断系统下所有的诊断功能(也即菜单项)，并显示在诊断设备的屏幕上，供用户进行选择。

在步骤104之后，上述菜单生成方法还包括：

根据基于上述诊断功能菜单所输入的诊断功能选择指令，确定目标诊断功能；

调用目标接口，以执行上述目标诊断功能的诊断操作，其中，上述目标接口为上述动态链接库中上述目标诊断功能所对应的接口。

在本申请实施例中，用户可以在诊断设备所显示的诊断功能菜单上输入诊断功能选择指令，该诊断功能选择指令所指向的诊断功能即为目标诊断功能。在确定目标诊断功能后，可调用已生成的动态链接库中该目标诊断功能所对应的接口，也即目标接口。通过调用该目标接口，即可执行目标诊断功能所需要的各项诊断操作。具体地，调用目标接口的流程如下：首先在菜单配置文件中，根据该目标接口的名称，查找出该目标接口的函数地址，随后，即可在该函数地址处获取到该目标接口，并调用该目标接口。举例来说，上文所示出的例子中，用户在ACU系统的诊断功能菜单中选择了“安全刷写”这一诊断功能，则诊断设备在菜单配置文件中读取到的接口的信息如下：

ACU_ActivitationFunction_Check_main

并可通过GetProcAddress函数获得ACU_ActivitationFunction_Check_main接口的函数地址。随后诊断设备即可从该函数地址处开始执行该接口的代码流程，实现对该接口的调用。

需要注意的是，本申请实施例所提出的诊断功能，可以为特殊诊断功能，例如ECU刷写及写数据等，此处不作限定。

由上可见，通过本申请方案，不再将诊断功能菜单写死在代码中，而是在用户选择待诊断车辆的车型后，选择待诊断系统前，先根据该车型所对应的源文件来生成动态链接库，进而生成菜单配置文件，之后再由用户选择待诊断系统，并通过加载菜单配置文件来获得与该待诊断系统相关联的诊断功能的名称，基于此实现诊断功能菜单的动态生成，可使得诊断设备的使用更具灵活性。

对应于上文所提供的菜单生成方法，本申请实施例还提供了一种菜单生成装置。如图4所示，本申请实施例中的菜单生成装置400包括：

第一加载单元401，用于根据待诊断车辆的车型，加载上述车型所对应的源文件；

第一生成单元402，用于基于上述源文件生成动态链接库，其中，每一源文件唯一的对应上述动态链接库的一个接口，上述动态链接库的每一个接口唯一的对应一个诊断功能；

第二生成单元403，用于基于上述源文件及上述动态链接库生成菜单配置文件；

第二加载单元404，用于在确定待诊断车辆的待诊断系统后，加载上述菜单配置文件，获得与上述待诊断系统相关联的诊断功能的名称，以生成上述待诊断系统的诊断功能菜单，其中，上述待诊断系统为用户所选择的待诊断车辆的电子系统。

可选地，上述菜单生成装置400还包括：

功能确定单元，用于根据基于上述诊断功能菜单所输入的诊断功能选择指令，确定目标诊断功能；

接口调用单元，用于调用目标接口，以执行上述目标诊断功能的诊断操作，其中，上述目标接口为上述动态链接库中上述目标诊断功能所对应的接口。

可选地，上述接口调用单元，包括：

函数地址查找子单元，用于在上述菜单配置文件中，根据上述目标接口的名称，查找上述目标接口的函数地址；

目标接口调用子单元，用于通过上述函数地址调用上述目标接口。

可选地，上述第一加载单元401，包括：

源文件获取子单元，用于根据上述待诊断车辆的车型，获取预设的车型系统配置文件及上述车型下的每个系统所分别对应的源文件；

源文件检测子单元，用于基于上述车型系统配置文件，检测各个源文件是否正确；

源文件加载子单元，用于若上述各个源文件均正确，则加载上述各个源文件。

可选地，上述源文件检测子单元，包括：

名称确定子单元，用于针对获取到的每个源文件，根据上述源文件的文件名，确定上述源文件所对应的电子系统的名称；

名称检测子单元，用于检测上述车型系统配置文件中是否存在上述源文件所对应的电子系统的名称；

结果确定子单元，用于若上述车型系统配置文件中存在上述源文件所对应的电子系统的名称，则确定上述源文件正确。

可选地，上述结果确定子单元，还用于若存在一个以上源文件不正确，则输出错误提示，以提醒源文件内容错误。

可选地，上述第一生成单元402，包括：

转换子单元，用于针对上述车型所对应的每个源文件，将上述源文件的内容转换为代码，以得到对应的代码文件，其中，上述代码采用预设的编程语言；

编译子单元，用于将所得到的所有代码文件编译成动态链接库。

由上可见，通过本申请方案，不再将诊断功能菜单写死在代码中，而是在用户选择待诊断车辆的车型后，选择待诊断系统前，先根据该车型所对应的源文件来生成动态链接库，进而生成菜单配置文件，之后再由用户选择待诊断系统，并通过加载菜单配置文件来获得与该待诊断系统相关联的诊断功能的名称，基于此实现诊断功能菜单的动态生成，可使得诊断设备的使用更具灵活性。

对应于上文所提供的菜单生成方法，本申请实施例还提供了一种诊断设备，请参阅图5，本申请实施例中的诊断设备5包括：存储器501，一个或多个处理器502(图5中仅示出一个)及存储在存储器501上并可在处理器上运行的计算机程序。其中：存储器501用于存储软件程序以及单元，处理器502通过运行存储在存储器501的软件程序以及单元，从而执行各种功能应用以及菜单生成，以获取上述预设事件对应的资源。具体地，处理器502通过运行存储在存储器501的上述计算机程序时实现以下步骤：

根据待诊断车辆的车型，加载上述车型所对应的源文件；

基于上述源文件生成动态链接库，其中，每一源文件唯一的对应上述动态链接库的一个接口，上述动态链接库的每一个接口唯一的对应一个诊断功能；

基于上述源文件及上述动态链接库生成菜单配置文件；

在确定待诊断车辆的待诊断系统后，加载上述菜单配置文件，获得与上述待诊断系统相关联的诊断功能的名称，以生成上述待诊断系统的诊断功能菜单，其中，上述待诊断系统为用户所选择的待诊断车辆的电子系统。

假设上述为第一种可能的实施方式，则在第一种可能的实施方式作为基础而提供的第二种可能的实施方式中，在生成上述待诊断系统的诊断功能菜单后，处理器502通过运行存储在存储器501的上述计算机程序时还实现以下步骤：

根据基于上述诊断功能菜单所输入的诊断功能选择指令，确定目标诊断功能；

调用目标接口，以执行上述目标诊断功能的诊断操作，其中，上述目标接口为上述动态链接库中上述目标诊断功能所对应的接口。

在上述第二种可能的实施方式作为基础而提供的第三种可能的实施方式中，上述调用目标接口，包括：

在上述菜单配置文件中，根据上述目标接口的名称，查找上述目标接口的函数地址；

通过上述函数地址调用上述目标接口。

在上述第一种可能的实施方式作为基础，或者上述第二种可能的实施方式作为基础，或者上述第三种可能的实施方式作为基础而提供的第四种可能的实施方式中，上述根据待诊断车辆的车型，加载上述车型所对应的源文件，包括：

根据上述待诊断车辆的车型，获取预设的车型系统配置文件及上述车型下的每个系统所分别对应的源文件；

基于上述车型系统配置文件，检测各个源文件是否正确；

若上述各个源文件均正确，则加载上述各个源文件。

在上述第四种可能的实施方式作为基础而提供的第五种可能的实施方式中，上述基于上述车型系统配置文件，检测各个源文件是否正确，包括：

针对获取到的每个源文件，根据上述源文件的文件名，确定上述源文件所对应的电子系统的名称；

检测上述车型系统配置文件中是否存在上述源文件所对应的电子系统的名称；

若上述车型系统配置文件中存在上述源文件所对应的电子系统的名称，则确定上述源文件正确。

在上述第四种可能的实施方式作为基础而提供的第六种可能的实施方式中，在上述基于上述车型系统配置文件，检测各个源文件是否正确之后，处理器502通过运行存储在存储器501的上述计算机程序时还实现以下步骤：

若存在一个以上源文件不正确，则输出错误提示，以提醒源文件内容错误。

在上述第一种可能的实施方式作为基础，或者上述第二种可能的实施方式作为基础，或者上述第三种可能的实施方式作为基础而提供的第七种可能的实施方式中，上述基于上述源文件生成动态链接库，包括：

针对上述车型所对应的每个源文件，将上述源文件的内容转换为代码，以得到对应的代码文件，其中，上述代码采用预设的编程语言；

将所得到的所有代码文件编译成动态链接库。

应当理解，在本申请实施例中，所称处理器502可以是中央处理单元(CentralProcessing Unit，CPU)，该处理器还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器501可以包括只读存储器和随机存取存储器，并向处理器502提供指令和数据。存储器501的一部分或全部还可以包括非易失性随机存取存储器。例如，存储器501还可以存储设备类别的信息。

由上可见，通过本申请方案，不再将诊断功能菜单写死在代码中，而是在用户选择待诊断车辆的车型后，选择待诊断系统前，先根据该车型所对应的源文件来生成动态链接库，进而生成菜单配置文件，之后再由用户选择待诊断系统，并通过加载菜单配置文件来获得与该待诊断系统相关联的诊断功能的名称，基于此实现诊断功能菜单的动态生成，可使得诊断设备的使用更具灵活性。

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

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

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

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

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

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

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