一种针对不同车型的诊断故障代码识别方法及装置

技术领域

本申请涉诊断故障码识别技术领域，尤其涉及一种针对不同车型的诊断故障代码识别方法以及针对不同车型的诊断故障代码识别装置。

背景技术

随着汽车产业迅猛发展，各品牌新车型层出不穷，往往一个车型会有多种不同配置，有的甚至多达数十种。不同的配置下车辆所配备的软硬件也会有所不同，例如传感器，开关，芯片型号，软件功能多样性等等。随之而来的，针对外设和控制器内部所检测的故障也会不同。另外，同样的逻辑也适用于实现控制器系统中关于诊断信息服务的功能，例如ISO-14229中，190A服务会提供当前配置下所支持的DTC，DTC支持列表也可作为该服务的期待测试结果来对产品进行测试验证。由于诊断故障类型很大程度上由控制器生产方提供，作为整车厂很难了解在不同车型下，该控制器所能够支持检测的故障有哪些。因此整车厂往往会要求生产方提供不同车型对应的诊断故障码(以下简称DTC)列表以便参考。事实上，DTC的支持与否不单取决于外设是否配置，还取决于外设的类型，数量，芯片是否支持等因素。目前多数控制器供应商通过人工进行识别整理出各个配置下支持DTC的列表提供给整车厂，这样做会增加人工成本和错误率，后期更新修改后的配置不但需要修改已知改动，还要评审对DTC列表中其他DTC是否有额外影响。而且在实际控制器代码的诊断信息等服务(如19服务)中关于DTC支持性的判断逻辑软件代码也大多在开发过程中手写完成(具体支持性判断逻辑无法在类似AUTOSAR配置工具中自动生成)，如此也会增加人工成本和出错几率。

因此，希望有一种技术方案来解决或至少减轻现有技术的上述不足。

发明内容

本发明的目的在于提供一种针对不同车型的诊断故障代码识别方法来至少解决上述的一个技术问题。

本发明提供了下述方案：

根据本发明的一个方面，提供一种针对不同车型的诊断故障代码识别方法，所述针对不同车型的诊断故障代码识别方法包括：

获取预设的DTC数据库，所述DTC数据库包括至少一个预设车型配置ID以及需检测项目信息，一个预设车型配置ID对应至少一个需检测项目信息；

获取待识别车型ID信息以及待识别车型基本配置信息；

根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息。

可选地，所述需检测项目信息包括网络相关需检测项目数据库、无效配置需检测项目数据库以及外挂芯片相关需检测项目数据库；

所述待识别车型基本配置信息包括待识别车型网络相关信息、待识别车型无效配置信息以及待识别车型外挂芯片信息。

可选地，所述根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息包括：

根据待识别车型ID信息、待识别车型网络相关信息以及网络相关需检测项目数据库获取待识别车型的网络相关DTC诊断支持信息；

根据待识别车型ID信息、待识别车型无效配置信息以及无效配置需检测项目数据库获取待识别车型的无效配置DTC诊断支持信息；

根据待识别车型ID信息、待识别车型外挂芯片信息以及外挂芯片相关需检测项目数据库获取待识别车型的外挂芯片DTC诊断支持信息。

可选地，所述根据待识别车型ID信息、待识别车型网络相关信息以及网络相关需检测项目数据库获取待识别车型的网络相关DTC诊断支持信息包括：

获取与所述待识别车型ID信息相同的预设车型配置ID所对应的网络相关需检测项目数据库；

根据所述网络相关需检测项目数据库以及待识别车型网络相关信息生成待识别车型的网络相关支持信息。

可选地，所述根据待识别车型ID信息、待识别车型无效配置信息以及无效配置需检测项目数据库获取待识别车型的无效配置DTC诊断支持信息包括：

获取与所述待识别车型ID信息相同的预设车型配置ID所对应的无效配置需检测项目数据库；

根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息。

可选地，所述根据待识别车型ID信息、待识别车型外挂芯片信息以及外挂芯片相关需检测项目数据库获取待识别车型的外挂芯片DTC诊断支持信息包括：

获取与所述待识别车型ID信息所相同的预设车型配置ID所对应的外挂芯片相关需检测项目数据库；

根据所述外挂芯片相关需检测项目数据库以及待识别车型外挂芯片信息生成待识别车型的待识别车型的外挂芯片DTC诊断支持信息。

可选地，所述待识别车型无效配置信息包括外设连接信息以及理论连接信息；

所述根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息包括：

根据所述外设连接信息以及理论连接信息获取待识别车型中能够支持无效配置DTC诊断的外设信息。

可选地，所述网络相关需检测项目数据库包括预设节点信息以及每个预设节点信息所对应的网络故障检测支持信息；

所述根据所述网络相关需检测项目数据库以及待识别车型网络相关信息生成待识别车型的网络相关支持信息包括：

获取待识别车型网络相关信息中的节点信息；

获取与所述节点信息相同的预设节点信息所对应的网络故障检测支持信息。

可选地，所述外挂芯片相关需检测项目数据库包括预设外挂芯片名称以及每个预设外挂芯片名称对应的DTC检测支持信息；

所述根据所述外挂芯片相关需检测项目数据库以及待识别车型外挂芯片信息生成待识别车型的待识别车型的外挂芯片DTC诊断支持信息包括：

根据所述待识别车型外挂芯片信息获取每个外挂芯片名称；

获取与所述外挂芯片名称相同的预设外挂芯片名称所对应的DTC检测支持信息。

本申请还提供了一种针对不同车型的诊断故障代码识别装置，所述针对不同车型的诊断故障代码识别装置包括：

DTC数据库获取模块，所述DTC数据库获取模块用于获取预设的DTC数据库，所述DTC数据库包括至少一个预设车型配置ID以及需检测项目信息，一个预设车型配置ID对应至少一个需检测项目信息；

待识别车型ID信息获取模块，所述待识别车型ID信息获取模块用于获取待识别车型ID信息；

待识别车型基本配置信息获取模块，所述待识别车型基本配置信息获取模块用于获取待识别车型基本配置信息；

待识别车型检测支持信息生成模块，所述待识别车型检测支持信息生成模块用于根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息。

本申请所提供的针对不同车型的诊断故障代码识别方法能够根据所获取的待识别车型ID信息以及待识别车型基本配置信息，通过预设的DTC数据库自动生成该待识别车型的检测支持信息，从而解决了人工方法下，识别支持检测的DTC条目所带来的大量人工成本，较高的误识别率，以及更新配置后的重复工作量的问题。

附图说明

图1是本申请一实施例中的针对不同车型的诊断故障代码识别方法的流程示意图。

图2是本申请一个实施例提供的针对不同车型的诊断故障代码识别方法的一种电子设备结构框图。

图3为本申请一个实施例中的DTC数据库的列表形式的示意图。

图4是本申请一个实施例中的待识别车型基本配置信息的列表形式的示意图。

图5是本申请一个实施例中的预设主驾驶安全带锁扣开关基本信息的示意图。

图6是本申请一个实施例中的两个待识别车型的预设加速度传感器基本信息的示意图。

图7是本申请一个实施例中的待识别车型检测支持信息的示意图。

具体实施方式

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

图1是本申请一实施例中的针对不同车型的诊断故障代码识别方法的流程示意图。

如图1所示的针对不同车型的诊断故障代码识别方法包括：

步骤1：获取预设的DTC数据库，所述DTC数据库包括至少一个预设车型配置ID以及需检测项目信息，一个预设车型配置ID对应至少一个需检测项目信息；

步骤2：获取待识别车型ID信息以及待识别车型基本配置信息；

步骤3：根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息。

本申请所提供的针对不同车型的诊断故障代码识别方法能够根据所获取的待识别车型ID信息以及待识别车型基本配置信息，通过预设的DTC数据库自动生成该待识别车型的检测支持信息，从而解决了人工方法下，识别支持检测的DTC条目所带来的大量人工成本，较高的误识别率，以及更新配置后的重复工作量的问题。

本申请编写的自动工具代码经过测试认证，可实现准确的判断且极难出现错误，大大降低了人工带来的误识别率；后续如果配置更新，无须修改业务逻辑，即可生成新的DTC列表。发明中所实现的逻辑，也可用于生成嵌入式软件代码，作为单独组件集成到控制器软件中，使其也能够应用于软件中关于诊断服务的DTC支持性判断逻辑，从而保证软件逻辑的正确性和一致性。

在本实施例中，需检测项目信息包括网络相关需检测项目数据库、无效配置需检测项目数据库以及外挂芯片相关需检测项目数据库；

所识别车型基本配置信息包括待识别车型网络相关信息、待识别车型无效配置信息以及待识别车型外挂芯片信息。

在本实施例中，所述根据待识别车型以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息包括：

根据待识别车型ID信息、待识别车型网络相关信息以及网络相关需检测项目数据库获取待识别车型的网络相关DTC诊断支持信息；

根据待识别车型ID信息、待识别车型无效配置信息以及无效配置需检测项目数据库获取待识别车型的无效配置DTC诊断支持信息；

根据待识别车型ID信息、待识别车型外挂芯片信息以及外挂芯片相关需检测项目数据库获取待识别车型的外挂芯片DTC诊断支持信息。

在本实施例中，所述根据待识别车型ID信息、待识别车型网络相关信息以及网络相关需检测项目数据库获取待识别车型的网络相关DTC诊断支持信息包括：

获取与所述待识别车型ID信息所相同的预设车型配置ID所对应的网络相关需检测项目数据库；

根据所述网络相关需检测项目数据库以及待识别车型网络相关信息生成待识别车型的网络相关支持信息。

在本实施例中，所述根据待识别车型ID信息、待识别车型无效配置信息以及无效配置需检测项目数据库获取待识别车型的无效配置DTC诊断支持信息包括：

获取与所述待识别车型ID信息所相同的预设车型配置ID所对应的无效配置需检测项目数据库；

根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息。

在本实施例中，所述根据待识别车型ID信息、待识别车型外挂芯片信息以及外挂芯片相关需检测项目数据库获取待识别车型的外挂芯片DTC诊断支持信息包括：

获取与所述待识别车型ID信息所相同的预设车型配置ID所对应的外挂芯片相关需检测项目数据库；

根据所述外挂芯片相关需检测项目数据库以及待识别车型外挂芯片信息生成待识别车型的待识别车型的外挂芯片DTC诊断支持信息。

在本实施例中，根据所述网络相关需检测项目数据库以及待识别车型网络相关信息生成待识别车型的网络相关支持信息包括：

配置表中应标明有哪些网络节点需要进行超时检测、完整性检测(如CRC)或连续性检测(如Alive Counter)。依据配置情况，对DTC表中的网络节点DTC依次进行判断。

在本实施例中，根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息包括：

无效配置DTC是一种实际安装与配置不符的故障(配置中没有某外设，而实际中则安装了该硬件)，此类DTC的支持性判断与其他正常DTC恰好相反，当配置中配置了此外设，则该外设的相关电路、数据等DTC应支持，而该外设的无效配置DTC不应支持。反之配置中没有配置该外设，则只有该外设的无效配置DTC会被支持。

在本实施例中，根据所述外挂芯片相关需检测项目数据库以及待识别车型外挂芯片信息生成待识别车型的待识别车型的外挂芯片DTC诊断支持信息包括：

不同车型配置中，所配备的外挂芯片数量可能会不同，不同的外挂芯片的故障类型相对通用(如电压故障、逻辑故障)，但每个外挂芯片会对应不同DTC，如(外挂芯片1电压过低、外挂芯片2电压过低)，如芯片在该车型中未配置，则相应DTC不应支持。

在本实施例中，待识别车型无效配置信息包括外设连接信息以及理论连接信息；

根据无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息包括：

根据外设连接信息以及理论连接信息获取待识别车型中能够支持无效配置DTC诊断的外设信息。

举例来说，无效配置是一类外设故障，任何外设(传感器，LED灯，开关等)只要可以检测出安装状态都可以检测这个故障。如A车型，配置了外设1和外设2，而控制器最大可以支持4个外设，那么外设1和外设2则不支持无效配置DTC，因为他们已经被配置，不会存在该错误，外设3和外设4则支持检测无效配置DTC，即无效配置DTC诊断支持信息为外设3和外设4则支持检测无效配置DTC，例如，外设3理论上在该车型上是没有东西的，因此不应该有任何信号，但是某次检测发现其有信号，说明安装错误。

在本实施例中，网络相关需检测项目数据库包括预设节点信息以及每个预设节点信息所对应的网络故障检测支持信息；

所述根据所述网络相关需检测项目数据库以及待识别车型网络相关信息生成待识别车型的网络相关支持信息包括：

获取待识别车型网络相关信息中的节点信息；

获取与所述节点信息相同的预设节点信息所对应的网络故障检测支持信息。

举例来说，网络故障检测支持信息是指：网络相关需检测项目数据库中应表明该配置存在哪些节点，这些节点是否支持超时、完整性、连续性的故障检测。如A车型有节点1，节点2，节点1在网络相关需检测项目数据库中写明支持超时、完整性和连续性故障检测，则DTC列表中关于节点1的超时、完整性和连续性故障的DTC则可以支持，即网络故障检测支持信息为节点1的超时、完整性和连续性故障的DTC支持。如节点2只支持超时检测，不支持完整性、连续性检测，则节点2的超时DTC置为支持，完整性和连续性的DTC置为不支持，即网络故障检测支持信息为节点2支持超时检测，不支持完整性、连续性检测。

在本实施例中，外挂芯片相关需检测项目数据库包括预设外挂芯片名称以及每个预设外挂芯片名称对应的DTC检测支持信息；

根据所述外挂芯片相关需检测项目数据库以及待识别车型外挂芯片信息生成待识别车型的待识别车型的外挂芯片DTC诊断支持信息包括：

根据待识别车型外挂芯片信息获取每个外挂芯片名称；

获取与所述外挂芯片名称相同的预设外挂芯片名称所对应的DTC检测支持信息。

举例来说，外挂芯片故障检测，外挂芯片相关需检测项目数据库中应表明该配置中有几个外挂芯片，如A车型没有外挂芯片，B车型有1个外挂芯片，则外挂芯片所有相关DTC在A车型中均不支持，外挂芯片1的DTC(如过压、欠压故障)在B车型中支持，外挂芯片2的DTC(如果存在)则在车型A和B中均不支持，即外挂芯片DTC诊断支持信息为外挂芯片1的DTC(如过压、欠压故障)在B车型中支持。

在本实施例中，需检测项目信息还包括主驾驶安全带锁扣开关配置项目；

所述待识别车型基本配置信息包括预设主驾驶安全带锁扣开关基本信息；

在本实施例中，根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息进一步包括：

根据主驾驶安全带锁扣开关基本信息判断开关类型，若开关属于简单开关，则

生成无法检测主驾驶安全带锁扣开关相关电路故障诊断支持信息。

在本实施例中，根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息进一步包括：

根据开关基本信息判断开关类型，若所述开关属于100/400Ohm类型开关，则

生成能够检测主驾驶安全带锁扣开关相关电路故障诊断支持信息。

在本实施例中，无效配置需检测项目数据库包括加速度传感器配置项目；

待识别车型无效配置信息包括预设加速度传感器基本信息；

根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息包括：

根据预设加速度传感器基本信息判断加速度传感器连接方式以及加速度传感器连接数量；

根据加速度传感器连接方式以及加速度传感器连接数量生成加速度传感器诊断支持信息。

在本实施例中，DTC数据库可以以列表形式出现，待识别车型基本配置信息也以列表形式出现，DTC列表如图3所示，待识别车型基本配置信息如图4所示，在本实施例中：1.列表使用Excel表格以便于数据的分别读取。2.DTC数据库中，除基本的“DTC码”，“DTC名称”外，可按照需求添加DTC的属性列，如“DTC设置/清除条件”，“维修建议”等。3.待识别车型基本配置信息须包含对DTC支持性进行判断所需信息，如外设类型，外设位置，特殊功能等。4.所有行列需对照工整，所有内容按照相同的排列规则填写，以便程序进行读取处理。

下面以主驾驶安全带锁扣开关配置项目为例具体说明，在本实施例中，需检测项目信息还包括主驾驶安全带锁扣开关配置项目；

所述待识别车型基本配置信息包括预设主驾驶安全带锁扣开关基本信息；

在本实施例中，根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息进一步包括：

根据主驾驶安全带锁扣开关基本信息判断开关类型，若开关属于简单开关，则

生成无法检测主驾驶安全带锁扣开关相关电路故障诊断支持信息。

在本实施例中，根据所述无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息进一步包括：

根据开关基本信息判断开关类型，若所述开关属于100/400Ohm类型开关，则

生成能够检测主驾驶安全带锁扣开关相关电路故障诊断支持信息。

参见图5，举例来说，当该开关被配置为Open/Short简单开关时，由于从电阻值角度，无法区分正常和故障状态下的差别，故无法检测相关电路故障(如：短路，开路等)，则相应DTC(如“主驾驶安全带锁扣开关短路/开路”)应判断为不支持。同理，若该开关被配置为100/400Ohm类型开关时，由于各故障和正常状态都有相应的阻值区间，则可以检测通过阻值判断的故障(如：短路，开路等)，相应DTC应判断为支持。

在本实施例中，无法检测主驾驶安全带锁扣开关相关电路故障诊断支持信息即为待识别车型检测支持信息，相应待识别车型检测支持信息中的主驾驶安全带锁扣开关短路/开路信息应判断为不支持。

在本实施例中，能够检测主驾驶安全带锁扣开关相关电路故障诊断支持信息即为待识别车型检测支持信息，待识别车型检测支持信息中的短路，开路等信息应判断为支持。

参见图6，下面以加速度传感器为例进行举例：

无效配置需检测项目数据库包括加速度传感器配置项目；

待识别车型无效配置信息包括预设加速度传感器基本信息；

根据无效配置需检测项目数据库以及待识别车型无效配置信息生成待识别车型的无效配置DTC诊断支持信息包括：

根据预设加速度传感器基本信息判断加速度传感器连接方式以及加速度传感器连接数量；

根据加速度传感器连接方式以及加速度传感器连接数量生成加速度传感器诊断支持信息。

举例来说，左侧车型配置了1个加速度传感器，右侧车型配置了3个传感器，已知该控制器芯片最多支持四路传感器硬线，则左侧车型只用到了第一路传感器硬线，右侧车型用到了第一、二、三路传感器硬线，而传感器电路故障(如对地短路，对电源短路等)均基于传感器硬线线路，故左侧车型不支持检测第二、三、四路硬线(即左侧车型的加速度传感器诊断支持信息为不支持检测第二、三、四路硬线)，右侧车型不支持检测第四路硬线(即右侧车型的加速度传感器诊断支持信息为不支持检测第二、三、四路硬线)。另由于左侧车型只配备一个传感器，则不存在传感器之间串联故障的可能，故不支持传感器串联DTC。

当把所有能够进行是否支持的信息获取到后，这些信息即组成待识别车型检测支持信息，待识别车型检测支持信息可以以表格的形式列出(例如图7所示)。

参见图7，在本实施例中，根据类似上述的判断规则(支持还是支持)可以总结确认所有故障支持性判断逻辑，并用工具进行实现(可用VBA，Python等脚本语言)，通过Excel等方式以清单形式形成每个待识别车型检测支持信息并输出，作为参考文档或测试期待结果，具体输出格式可根据不同需求进行定制，如checklist形式或以每个车型为单位。

参见图7，图7为某个待识别车型的待识别车型检测支持信息，例如，驾驶员的气囊第一阶段电路对地短路即为需检测项目信息，该项目前边的对钩代表支持，对钩上边的V1代表V1车型，V2代表V2车型，V3代表V3车型，V4代表V4车型，V5代表V5车型。

由于在诊断服务，尤其是诊断信息读取功能(例如19服务)中，DTC支持性是输出的前提，例如经过判断，该DTC在当前配置下不支持检测，则通过19服务读取相关信息(如1904读取DTC快照信息，1906读取DTC扩展数据)时，会回复否定响应(NRC 31)，告知用户此DTC不在支持范围内。而筛选、罗列DTC时(如1902筛选符合状态的DTC，190A报告所有支持的DTC)，均不会将此DTC考虑在内。因此，DTC支持性识别是诊断服务所必须实现的功能，而通过将此系统中所应用的逻辑加以转换，即可获得满足嵌入式C/C++语言的代码。但生成的代码无法直接集成使用，其中部分所需接口(如获取配置，获取类型等，则需要自行进行编辑。反之，如果控制器嵌入式代码中已经包含DTC支持性识别逻辑，也可仿照此逻辑辅助进行脚本工具的开发。

本申请还提供了一种针对不同车型的诊断故障代码识别装置，所述针对不同车型的诊断故障代码识别装置包括DTC数据库获取模块、待识别车型ID信息获取模块、待识别车型基本配置信息获取模块以及待识别车型检测支持信息生成模块，DTC数据库获取模块用于获取预设的DTC数据库，DTC数据库包括至少一个预设车型配置ID以及需检测项目信息，一个预设车型配置ID对应至少一个需检测项目信息；待识别车型ID信息获取模块用于获取待识别车型ID信息；待识别车型基本配置信息获取模块用于获取待识别车型基本配置信息；待识别车型检测支持信息生成模块用于根据待识别车型ID信息、待识别车型基本配置信息以及所述DTC数据库生成每个待识别车型的待识别车型检测支持信息。

图2是本发明一个或多个实施例提供的一种电子设备结构框图。

如图2所示，本申请还公开了一种电子设备，包括：处理器、通信接口、存储器和通信总线，其中，处理器，通信接口，存储器通过通信总线完成相互间的通信；存储器中存储有计算机程序，当计算机程序被处理器执行时，使得处理器执行针对不同车型的诊断故障代码识别方法的步骤。

本申请还提供了一种计算机可读存储介质，其存储有可由电子设备执行的计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行针对不同车型的诊断故障代码识别方法的步骤。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended IndustryStandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

电子设备包括硬件层，运行在硬件层之上的操作系统层，以及运行在操作系统上的应用层。该硬件层包括中央处理器(CPU，Central Processing Unit)、内存管理单元(MMU，Memory Management Unit)和内存等硬件。该操作系统可以是任意一种或多种通过进程(Process)实现电子设备控制的计算机操作系统，例如，Linux操作系统、Unix操作系统、Android操作系统、iOS操作系统或windows操作系统等。并且在本发明实施例中该电子设备可以是智能手机、平板电脑等手持设备，也可以是桌面计算机、便携式计算机等电子设备，本发明实施例中并未特别限定。

本发明实施例中的电子设备控制的执行主体可以是电子设备，或者是电子设备中能够调用程序并执行程序的功能模块。电子设备可以获取到存储介质对应的固件，存储介质对应的固件由供应商提供，不同存储介质对应的固件可以相同可以不同，在此不做限定。电子设备获取到存储介质对应的固件后，可以将该存储介质对应的固件写入存储介质中，具体地是往该存储介质中烧入该存储介质对应固件。将固件烧入存储介质的过程可以采用现有技术实现，在本发明实施例中不做赘述。

电子设备还可以获取到存储介质对应的重置命令，存储介质对应的重置命令由供应商提供，不同存储介质对应的重置命令可以相同可以不同，在此不做限定。

此时电子设备的存储介质为写入了对应的固件的存储介质，电子设备可以在写入了对应的固件的存储介质中响应该存储介质对应的重置命令，从而电子设备根据存储介质对应的重置命令，对该写入对应的固件的存储介质进行重置。根据重置命令对存储介质进行重置的过程可以现有技术实现，在本发明实施例中不做赘述。

为了描述的方便，描述以上装置时以功能分为各种单元、模块分别描述。当然在实施本申请时可以把各单元、模块的功能在同一个或多个软件和/或硬件中实现。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非被特定定义，否则不会用理想化或过于正式的含义来解释。

对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器或者网络设备等)执行本申请各个实施方式或者实施方式的某些部分所述的方法。

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