故障码生成结果监测方法、装置、设备及可读存储介质

技术领域

本申请涉及故障注入测试技术领域，具体涉及一种故障码生成结果监测方法、装置、设备及可读存储介质。

背景技术

车体定位软件在面对各类异常数据时不仅要有稳定的处理能力，而且需要及时提供各类故障码以辅助判断是否取信相关数据结果。在对车体定位软件进行仿真测试过程中，需要大量符合FEMA(Failure Mode and Effects Analysis，故障模式影响分析)分析中的各种故障类型要求的异常数据，以根据该异常数据生成故障并注入至车体定位软件中进行仿真测试。其中，由于车体定位软件提供故障码的速度和准确性会对车体定位软件的可靠性和准确性产生影响，因此在故障注入至车体定位软件后，对车体定位软件基于所注入的故障生成故障码的结果进行监测，以实现对车体定位软件提供故障码的速度和准确性的判断是非常重要的。

但是，相关技术中并未对车体定位软件的故障码生成结果进行监测，以致无法确定车体定位软件提供故障码的速度和准确性。

发明内容

本申请提供一种故障码生成结果监测方法、装置、设备及可读存储介质，以实现对车体定位软件故障码生成结果的监测，进而确定车体定位软件提供故障码的速度和准确性。

第一方面，本申请实施例提供故障码生成结果监测方法，所述故障码生成结果监测方法包括：

当接收到车体定位软件发送的故障码信息时，基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码，所述故障码信息包括车体定位软件所生成的故障码；

判断所述故障码信息中是否包含所述目标故障码；

若包含，则根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出；

若不包含，则判定车体定位软件的故障码生成结果的监测结果为未输出。

结合第一方面，在一种实施方式中，所述根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出，包括：

判断所述发送时刻和所述故障注入起始时刻间的差值是否位于所述标准输出时间阈值范围内；

若所述差值位于所述标准输出时间阈值范围内，则判定所述故障码生成结果的监测结果为准时输出；

若所述差值位于所述标准输出时间阈值范围外，则判定所述故障码生成结果的监测结果为延时输出。

结合第一方面，在一种实施方式中，在所述基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码的步骤之前，还包括：

根据所述发送时刻和各个故障记录对应的故障记录生成时刻以及预设监测持续时长从多个故障记录中筛选出目标故障记录，所述目标故障记录包括目标故障以及与其对应的故障传感器类型、故障类型和故障注入起始时刻。

结合第一方面，在一种实施方式中，所述故障码生成结果监测方法还包括：

针对每个故障，基于与故障对应的多传感器融合数据、故障传感器类型、故障持续时间、故障类型、故障误差范围以及是否启用故障生成故障数据及其对应的故障记录，并将所述故障数据注入所述车体定位软件，以供所述车体定位软件基于所述故障数据进行故障仿真测试并生成故障码。

结合第一方面，在一种实施方式中，通过实时注入方式或故障文件注入方式将所述故障数据注入所述车体定位软件。

第二方面，本申请实施例提供了一种故障码生成结果监测装置，所述故障码生成结果监测装置包括：

第一处理模块，其用于当接收到车体定位软件发送的故障码信息时，基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码，所述故障码信息包括车体定位软件所生成的故障码；

第二处理模块，其用于判断所述故障码信息中是否包含所述目标故障码；

第三处理模块，其用于若包含，则根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出；若不包含，则判定车体定位软件的故障码生成结果的监测结果为未输出。

结合第二方面，在一种实施方式中，所述第一处理模块具体用于：

判断所述发送时刻和所述故障注入起始时刻间的差值是否位于所述标准输出时间阈值范围内；

若所述差值位于所述标准输出时间阈值范围内，则判定所述故障码生成结果的监测结果为准时输出；

若所述差值位于所述标准输出时间阈值范围外，则判定所述故障码生成结果的监测结果为延时输出。

结合第二方面，在一种实施方式中，所述故障码生成结果监测装置还包括故障记录筛选模块，其用于：

根据所述发送时刻和各个故障记录对应的故障记录生成时刻以及预设监测持续时长从多个故障记录中筛选出目标故障记录，所述目标故障记录包括目标故障以及与其对应的故障传感器类型、故障类型和故障注入起始时刻。

结合第二方面，在一种实施方式中，所述故障码生成结果监测装置还包括故障数据生成及注入模块，其用于：

针对每个故障，基于与故障对应的多传感器融合数据、故障传感器类型、故障持续时间、故障类型、故障误差范围以及是否启用故障生成故障数据及其对应的故障记录，并将所述故障数据注入所述车体定位软件，以供所述车体定位软件基于所述故障数据进行故障仿真测试并生成故障码。

结合第二方面，在一种实施方式中，通过实时注入方式或故障文件注入方式将所述故障数据注入所述车体定位软件。

第三方面，本申请实施例提供了一种故障码生成结果监测设备，所述故障码生成结果监测设备包括处理器、存储器以及存储在所述存储器上并可被所述处理器执行的故障码生成结果监测程序，其中所述故障码生成结果监测程序被所述处理器执行时，实现如前述的故障码生成结果监测方法的步骤。

第四方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有故障码生成结果监测程序，其中所述故障码生成结果监测程序被处理器执行时，实现如前述的故障码生成结果监测的步骤。

本申请实施例提供的技术方案带来的有益效果至少包括：

当接收到车体定位软件发送的包括车体定位软件所生成的故障码的故障码信息时，通过目标故障传感器类型和目标故障类型确定出与目标故障对应的目标故障码；然后判断故障码信息中是否包含目标故障码，如果包含，说明车体定位软件准确识别出了目标故障的故障码并进行了输出，则车体定位软件提供的故障码是准确的；而若不包含，说明车体定位软件未识别出目标故障的故障码，则车体定位软件提供的故障码是不准确；同时对于准确的故障码，还根据与故障码信息对应的发送时刻、与目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围来确定其为准时输出还是延时输出，进而实现对车体定位软件提供故障码的速度监测。由此可见，本申请实施例实现了车体定位软件故障码生成结果的监测，进而有效确定了车体定位软件提供故障码的速度和准确性。

附图说明

图1为本申请故障码生成结果监测方法实施例的流程示意图；

图2为本申请故障码生成结果监测装置实施例的功能模块示意图；

图3为本申请实施例方案中涉及的故障码生成结果监测设备的硬件结构示意图。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。术语“第一”、“第二”和“第三”等描述，是用于区分不同的对象等，其不代表先后顺序，也不限定“第一”、“第二”和“第三”是不同的类型。

在本申请实施例的描述中，“示例性的”、“例如”或者“举例来说”等用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”、“例如”或者“举例来说”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”、“例如”或者“举例来说”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

在本申请实施例描述的一些流程中，包含了按照特定顺序出现的多个操作或步骤，但是应该理解，这些操作或步骤可以不按照其在本申请实施例中出现的顺序来执行或并行执行，操作的序号仅用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作或步骤可以按顺序执行或并行执行，并且这些操作或步骤可以进行组合。

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

第一方面，本申请实施例提供一种故障码生成结果监测方法。

一实施例中，参照图1，图1为本申请故障码生成结果监测方法实施例的流程示意图。如图1所示，故障码生成结果监测方法包括：

步骤S10：当接收到车体定位软件发送的故障码信息时，基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码，所述故障码信息包括车体定位软件所生成的故障码；

示范性的，本实施例中，在进行车体定位软件的仿真测试时，当某一故障对应的故障数据被注入至车体定位软件后，车体定位软件将会基于该故障数据进行故障码的生成并定频输出。需要说明的是，定频输出对应的时间间隔的设置可根据实际需求进行确定，在此不作限定；比如，定频输出对应的时间间隔为T1，则车体定位软件会每间隔T1时间，将该T1时间段内生成的故障码以故障码信息的形式进行输出。具体的，假设T1时间段内，车体定位软件分别生成了故障码A、故障码B以及故障码C，则在T1时间达到后，将包含故障码A、故障码B以及故障码C的故障码信息输出。

而本实施例在接收到车体定位软件发送的故障码信息后，将启动对车体定位软件输出的故障码生成结果进行监测，也即持续监测故障数据注入后车体定位软件是否在指定处理时间内发出故障码。本实施例中，将对处于当前时间段内的目标故障的故障码进行确定，即根据与该目标故障对应的目标故障传感器类型和目标故障类型来确定出与目标故障对应的目标故障码。需要说明的是，本实施例在为每个故障生成故障数据时，会自动记录与该故障对应的故障传感器类型、故障类型以及故障注入起始时刻等信息；此外，如何根据故障传感器类型和故障类型确定故障码的方法是公知常识，具体可根据实际需求进行自行设计并一一对应，在此不再赘述。

另外，应当理解的是，本实施例还将提供故障码显示UI(User Interface，用户界面)界面，以用于实时显示故障码。具体的，在本实施例接收到车体定位软件发送的故障码信息后，故障码显示UI将实时显示车体定位软件发出的故障码，且当车体定位软件发出的故障码有变更时，还会显示更新内容，比如显示新故障码的发送时间及具体内容等。

步骤S20：判断所述故障码信息中是否包含所述目标故障码；

示范性的，在本实施例中，当确定出目标故障的目标故障码后，将判断车体定位软件发送的故障码信息中是否包含该目标故障码，也即判断车体定位软件是否生成了与目标故障对应的故障码，进而可确定车体定位软件是否准确识别出了故障码，从而实现对车体定位软件提供故障码的准确性监测。

步骤S30：若包含，则根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出；

示范性的，在本实施例中，若检测到车体定位软件所生成的故障码中包含目标故障码，说明车体定位软件准确识别出了目标故障的故障码并进行了输出，即车体定位软件提供的故障码是准确的，并准确识别了该故障类型且及时向下游提供相关警示信息；同时本实施例还将根据车体定位软件发送故障码信息时对应的发送时刻、与目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围来确定车体定位软件输出的故障码是准时输出还是延时输出，从而实现对车体定位软件提供故障码的速度监测。

需要说明的是，标准输出时间阈值范围用于表征车体定位软件是否在指定时间内准时输出了故障码，其具体值设定可根据不同故障的特性和需求进行确定，在此不作限定。

步骤S40：若不包含，则判定车体定位软件的故障码生成结果的监测结果为未输出。

示范性的，在本实施例中，若检测到车体定位软件所生成的故障码中不包含目标故障码，说明车体定位软件未识别出目标故障的故障码，则车体定位软件提供的故障码是不准确的且未识别出该故障类型，也即车体定位软件的可靠性和准确性不满足要求。由此可见，本实施例实现了车体定位软件故障码生成结果的监测，进而有效确定了车体定位软件提供故障码的速度和准确性。

此外，本实施例还可对每个故障对应的回退时间进行预设，以根据回退时间对系统节点进行回退，进而对故障进行重复测试。可以理解的是，当系统需要重复测试某一时间的某一故障时，为保证系统能够重启成功，则需要使监测节点回退到该故障对应的故障数据开始注入前的某一时刻，则回退时间指的就是该时刻与故障数据开始注入时刻的差值。

进一步地，一实施例中，所述根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出，包括：

判断所述发送时刻和所述故障注入起始时刻间的差值是否位于所述标准输出时间阈值范围内；

若所述差值位于所述标准输出时间阈值范围内，则判定所述故障码生成结果的监测结果为准时输出；

若所述差值位于所述标准输出时间阈值范围外，则判定所述故障码生成结果的监测结果为延时输出。

示范性的，在本实施例中，将对发送时刻和故障注入起始时刻间的差值是否位于标准输出时间阈值范围内进行判断，如果该差值位于标准输出时间阈值范围内，说明车体定位软件在指定时间内输出了与目标故障对应的故障码，则判定车体定位软件的故障码生成结果的监测结果为准时输出；而如果位于标准输出时间阈值范围外，说明车体定位软件未在指定时间内输出与目标故障对应的故障码，则判定车体定位软件的故障码生成结果的监测结果为延时输出。

进一步地，一实施例中，在所述基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码的步骤之前，还包括：

根据所述发送时刻和各个故障记录对应的故障记录生成时刻以及预设监测持续时长从多个故障记录中筛选出目标故障记录，所述目标故障记录包括目标故障以及与其对应的故障传感器类型、故障类型和故障注入起始时刻。

示范性的，应当理解的是，每个故障码都是有时效性的，即系统要求车体定位软件接收到故障数据后在对应的时长内将该故障报出来反馈给下游，也即在该时长内输出的故障码是针对当前几帧的故障数据生成的，而并不是针对前一段时间的故障数据生成的。于是，本实施例还将对每个故障对应的持续监测时长进行记录，其中，持续监测时长表示各故障注入后监测故障码是否产生的持续时间，由于不同的故障所对应的时长是不同的，因此每个故障对应的监测持续时长的具体值设定可根据实际需求确定，在此不作限定。

同时，在为每个故障生成故障数据时，本实施例会自动记录与该故障对应的故障传感器类型、故障类型以及故障注入起始时刻等信息，以形成对应的故障记录。因此，当需要进行故障码生成结果的监测时，将从所有故障记录中筛选出对应的目标故障记录，以根据目标故障记录中的存储的目标故障传感器类型和目标故障类型确定出目标故障的故障码。

具体的，当接收到车体定位软件发送的故障码信息时，对各个故障记录进行遍历，即对与故障码信息对应的发送时刻与各个故障记录对应的故障记录生成时刻作差处理，得到时间差值；若时间差值小于对应的预设监测持续时长，则将该故障记录作为目标故障记录。比如，以故障A对应的预设监测持续时长为t1且故障A对应的故障记录X的故障记录生成时刻是t2为例，假设发送时刻与t2的差值小于t1，则将故障记录X作为目标故障记录；若发送时刻与t2的差值不小于t1，说明车体定位软件未识别出故障A，则判定未输出故障A。

进一步地，一实施例中，所述故障码生成结果监测方法还包括：

针对每个故障，基于与故障对应的多传感器融合数据、故障传感器类型、故障持续时间、故障类型、故障误差范围以及是否启用故障生成故障数据及其对应的故障记录，并将所述故障数据注入所述车体定位软件，以供所述车体定位软件基于所述故障数据进行故障仿真测试并生成故障码。

示范性的，在本实施例中，通过数据回放模块将多传感器融合数据传输至故障数据生成及注入模块。其中，数据回放模块可包括数据播放UI、倍速设置UI、文件加载UI以及各个故障传感器类型对应的数据处理模块等，通过文件加载UI选定并加载待回放的原始数据包，数据播放UI用于控制原始数据包的播放和暂停，并可通过拖动进度条控制原始数据包的播放位置，倍速设置UI用于设置原始数据包的播放速度。数据回放模块负责接收并解析多传感器融合数据，当没有故障待注入时，将解析后的数据直接发送到车体定位软件；当存在待注入故障时，将解析后的数据后发送给对应的故障传感器类型的数据处理模块进行处理，然后再由数据处理模块将处理后的多传感器融合数据传输至故障数据生成及注入模块。

针对每个故障，故障数据生成及注入模块将根据接收到的多传感器融合数据以及预设的故障传感器类型、故障持续时间、故障类型、故障误差范围和是否启用故障生成故障数据及其对应的故障记录；具体的，当是否启用故障为启用时，使多传感器融合数据加上故障误差或故障误差范围以生成故障数据及其对应的故障记录，并将故障数据注入车体定位软件，以供车体定位软件基于故障数据进行故障仿真测试并生成故障码。由此可见，本实施例能生成符合各种故障类型要求的故障数据，且扩展性好、能够自动监测各类故障码是否及时和准确生成，有效提升了仿真测试过程中的自动化性能和效率。

进一步地，一实施例中，通过实时注入方式或故障文件注入方式将所述故障数据注入所述车体定位软件。

示范性的，在本实施例中，故障数据生成及注入模块可包括故障数据人机交互UI和故障数据显示UI等。其中，在以实时注入方式将故障数据注入车体定位软件时，可通过故障数据人机交互UI实现；而在以故障文件注入方式将故障数据注入车体定位软件时，可通过故障数据显示UI实现。

具体的，故障数据人机交互UI为实时注入故障数据提供设置界面，通过该界面用户可选择故障注入的配置参数，该配置参数包括但不限于故障传感器类型、故障持续时间、故障类型、故障误差范围以及是否启用该故障。其中，故障传感器类型包括但不限于RTK(Real-time kinematic，实时动态)数据故障、车身数据故障、感知数据故障、IMU(InertialMeasurement Unit，惯性传感器)数据故障、高精地图数据故障以及其他传感器数据故障。

故障类型包括生成误差、屏蔽信号以及时延类故障。生成误差的方式为对接收到的传感器数据按照设置的故障误差范围进行加偏处理并替换原有数据进行发送；其中，加偏处理分为固定加偏和随机加偏，固定加偏指的是利用原有数据和加偏值并根据特定公式计算得到故障数据，随机加偏指的是在故障误差范围内生成具有特定数字特征的随机变量并计算得到故障数据；需要说明的是，加偏类型可在设置故障误差范围时选择。屏蔽信号的方式为在指定时间段内停止发送相关数据；时延类故障为在指定时间范围内以特定方式计算各数据发送间隔，通过改变数据的发送时间来模拟信号堵塞情况；当选择启用故障后，所选故障数据开始且在故障持续时间范围内持续生成并发送。

应当理解的是，本实施例可以同时生成多个传感器的故障数据，每个传感器的故障数据可以同时注入多个故障；且同一传感器的多个故障中，屏蔽信号类故障的优先级最高，误差生成类故障的优先级最低。

故障数据显示UI为根据故障文件注入故障数据提供数据显示界面，即在开始测试前可根据说明文档直接批量写入故障数据，其中，该方案下需要写入的配置参数包括故障数据生成的起始时刻(即故障注入起始时刻)、故障持续时间、故障传感器类型、故障类型以及故障误差范围等；需要说明的是，本实施还会记录故障数据生成的起始时刻与数据包起始时刻的差值，这样可以实现故障文件的重复利用，也即当读取故障文件时，本实施例会根据该差值自动计算出故障数据生成的起始时刻在数据包中的对应时间，进而仅加载数据包中该时间范围内的故障记录。

第二方面，本申请实施例还提供一种故障码生成结果监测装置。

一实施例中，参照图2，图2为本申请故障码生成结果监测装置实施例的功能模块示意图。如图2所示，故障码生成结果监测装置包括：

第一处理模块，其用于当接收到车体定位软件发送的故障码信息时，基于与目标故障对应的目标故障传感器类型和目标故障类型确定出目标故障码，所述故障码信息包括车体定位软件所生成的故障码；

第二处理模块，其用于判断所述故障码信息中是否包含所述目标故障码；

第三处理模块，其用于若包含，则根据与故障码信息对应的发送时刻、与所述目标故障对应的故障注入起始时刻以及预设的标准输出时间阈值范围确定车体定位软件的故障码生成结果的监测结果为准时输出或延时输出；若不包含，则判定车体定位软件的故障码生成结果的监测结果为未输出。

进一步地，一实施例中，所述第一处理模块具体用于：

判断所述发送时刻和所述故障注入起始时刻间的差值是否位于所述标准输出时间阈值范围内；

若所述差值位于所述标准输出时间阈值范围内，则判定所述故障码生成结果的监测结果为准时输出；

若所述差值位于所述标准输出时间阈值范围外，则判定所述故障码生成结果的监测结果为延时输出。

进一步地，一实施例中，所述故障码生成结果监测装置还包括故障记录筛选模块，其用于：

根据所述发送时刻和各个故障记录对应的故障记录生成时刻以及预设监测持续时长从多个故障记录中筛选出目标故障记录，所述目标故障记录包括目标故障以及与其对应的故障传感器类型、故障类型和故障注入起始时刻。

进一步地，一实施例中，所述故障码生成结果监测装置还包括故障数据生成及注入模块，其用于：

针对每个故障，基于与故障对应的多传感器融合数据、故障传感器类型、故障持续时间、故障类型、故障误差范围以及是否启用故障生成故障数据及其对应的故障记录，并将所述故障数据注入所述车体定位软件，以供所述车体定位软件基于所述故障数据进行故障仿真测试并生成故障码。其中，多传感器融合数据由数据回放模块进行处理得到并传输至故障数据生成及注入模块。

进一步地，一实施例中，通过实时注入方式或故障文件注入方式将所述故障数据注入所述车体定位软件。

其中，上述故障码生成结果监测装置中各个模块的功能实现与上述故障码生成结果监测方法实施例中各步骤相对应，其功能和实现过程在此处不再一一赘述。

第三方面，本申请实施例提供一种故障码生成结果监测设备，故障码生成结果监测设备可以是个人计算机(personal computer，PC)、笔记本电脑、服务器等具有数据处理功能的设备。

参照图3，图3为本申请实施例方案中涉及的故障码生成结果监测设备的硬件结构示意图。本申请实施例中，故障码生成结果监测设备可以包括处理器、存储器、通信接口以及通信总线。

其中，通信总线可以是任何类型的，用于实现处理器、存储器以及通信接口互连。

通信接口包括输入/输出(input/output，I/O)接口、物理接口和逻辑接口等用于实现故障码生成结果监测设备内部的器件互连的接口，以及用于实现故障码生成结果监测设备与其他设备(例如其他计算设备或用户设备)互连的接口。物理接口可以是以太网接口、光纤接口、ATM接口等；用户设备可以是显示屏(Display)、键盘(Keyboard)等。

存储器可以是各种类型的存储介质，例如随机存取存储器(randomaccessmemory，RAM)、只读存储器(read-only memory，ROM)、非易失性RAM(non-volatileRAM，NVRAM)、闪存、光存储器、硬盘、可编程ROM(programmable ROM，PROM)、可擦除PROM(erasable PROM，EPROM)、电可擦除PROM(electrically erasable PROM，EEPROM)等。

处理器可以是通用处理器，通用处理器可以调用存储器中存储的故障码生成结果监测程序，并执行本申请实施例提供的故障码生成结果监测方法。例如，通用处理器可以是中央处理器(central processing unit，CPU)。其中，故障码生成结果监测程序被调用时所执行的方法可参照本申请故障码生成结果监测方法的各个实施例，此处不再赘述。

本领域技术人员可以理解，图3中示出的硬件结构并不构成对本申请的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

第四方面，本申请实施例还提供一种计算机可读存储介质。

本申请可读存储介质上存储有故障码生成结果监测程序，其中所述故障码生成结果监测程序被处理器执行时，实现如上述的故障码生成结果监测方法的步骤。

其中，故障码生成结果监测程序被执行时所实现的方法可参照本申请故障码生成结果监测方法的各个实施例，此处不再赘述。

需要说明的是，上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。