掌桥专利:专业的专利平台
掌桥专利
首页

一种轨道交通整机监控方法、系统、终端设备及存储介质

文献发布时间:2023-06-19 18:37:28


一种轨道交通整机监控方法、系统、终端设备及存储介质

技术领域

本申请涉及交通监控技术领域,尤其涉及一种轨道交通整机监控方法、系统、终端设备及存储介质。

背景技术

随着各大城市轨道交通的快速建设,在各种应用场景中,如地铁闸机、自动查询机、电动开关闸门等轨道交通设备的运行都需要轨道交通整机的控制。

当前,轨道交通整机属于一个独立的计算机系统,不受外部系统的监控,当轨道交通设备出现系统故障时,轨道交通整机无法记录相关的硬件报错信息,所以需要相关运维人员对系统故障进行逐项的排查确认,加重了相关维护人员的工作量,从而轨道交通整机的监控效果较差。

发明内容

为了提升对轨道交通整机的监控效果,本申请提供一种轨道交通整机监控方法、系统、终端设备及存储介质。

第一方面,本申请提供一种轨道交通整机监控方法,包括以下步骤:

获取信号监控器接收到的目标运行信号;

识别所述目标运行信号,获取对应的系统运行参数;

判断所述系统运行参数是否符合对应的参数运行指标;

若所述系统运行参数不符合对应的所述参数运行指标,则获取对应的异常运行项;

判断所述异常运行项对应的修复类型;

若所述修复类型为内部自行修复,则获取并记录所述异常运行项对应的修复指令以及所述修复指令对应的第一修复结果至第一日志;

若所述修复类型为外部控制修复,则获取并记录所述异常运行项对应的修复策略以及所述修复策略对应的第二修复结果至第二日志。

通过采用上述技术方案,根据信号监控器接收到设备的目标运行信号,以便于将设备的系统运行参数与对应的参数运行指标做对比,得出系统存在运行问题的异常运行项,进一步为了清楚区分记录异常运行项以及其对应的修复类型,将可通过系统内部自行修复的异常运行项、异常运行项对应的修复指令以及相应的第一修复结果记录至第一日志,将需通过外部控制修复的异常运行项、异常运行项对应的修复策略以及相应的第二修复结果记录至第二日志,从而便于通过第一日志或第二日志记录追溯系统出现的异常问题以及异常问题的修复处理过程,提升了对轨道交通整机的监控效果。

可选的,所述异常运行项包括CPU运算错误,并且所述若所述修复类型为内部自行修复,则获取并记录所述异常运行项、所述异常运行项对应的修复指令以及所述修复指令对应的第一修复结果至第一日志包括以下步骤:

若所述修复类型为内部自行修复,则获取并判断所述CPU运算错误的错误类型;

若所述错误类型为CPU运算不可纠正错误,则生成对应的重启指令作为第一修复指令;

执行所述第一修复指令,获取对应的重启运行参数作为所述第一修复结果;

记录所述CPU运算不可纠正错误、所述第一修复指令和所述第一修复结果至所述第一日志;

若所述错误类型为CPU运算可纠正错误,则生成对应的恢复指令作为第二修复指令;

执行所述第二修复指令,获取对应的恢复运行参数作为所述第一修复结果;

记录所述CPU运算可纠正错误、所述第二修复指令和所述第一修复结果至所述第一日志。

通过采用上述技术方案,进一步对CPU运算错误的错误类型进行分类细化,从而便于通过第一日志对CPU运算不可纠正错误或者CPU运算可纠正错误的异常运行项以及相应修复指令和修复结果进行记录追踪,实时记录系统的异常状态以及相应修复过程。

可选的,所述异常运行项包括CPU温度异常,并且所述若所述修复类型为外部控制修复,则获取并记录所述异常运行项、所述异常运行项对应的修复策略以及所述修复策略对应的第二修复结果至第二日志包括以下步骤:

若所述修复类型为外部控制修复,则获取并判断所述CPU温度异常的异常类型;

若所述异常类型为主板过热,则生成对应的降热指令作为第一修复策略;

执行所述第一修复策略,获取对应的CPU实时温度作为所述第二修复结果;

记录所述主板过热、所述第一修复策略和所述第二修复结果至所述第二日志。

通过采用上述技术方案,将主板过热、降热指令以及执行降热指令后CPU实时温度记录至第二日志,从而便于通过第二日志实时对主板过热的异常情况以及相应修复处理过程进行记录追踪。

可选的,所述降热指令包括降频指令和散热指令,并且所述执行所述第一修复策略,获取对应的CPU实时温度作为所述第二修复结果包括以下步骤:

执行所述降频指令,获取对应的CPU频率值;

判断所述CPU频率值是否达到预设CPU频率最低值;

若所述CPU频率值达到所述预设CPU频率最低值,则获取对应的所述CPU实时温度;

判断所述CPU实时温度是否处于预设CPU正常温度阈值范围;

若所述CPU实时温度处于所述预设CPU正常温度阈值范围,则停止执行所述散热指令,并获取所述CPU实时温度作为所述第二修复结果;

若所述CPU实时温度超出所述预设CPU正常温度阈值范围,则继续执行所述散热指令,并获取所述CPU实时温度作为所述第二修复结果。

通过采用上述技术方案,判断执行降频指令后的CPU实时温度是否处于预设CPU正常温度阈值范围,依此作为是否继续执行散热指令的依据,从而降低了系统功耗。

可选的,在所述若所述修复类型为外部控制修复,则获取并判断所述CPU温度异常的异常类型之后还包括以下步骤:

若所述异常类型为CPU内核过热,则获取当前运行程序;

判断所述当前运行程序的数量是否超过预设程序数量阈值;

若所述当前运行程序的数量超过所述预设程序数量阈值,则获取所述当前运行程序的数量和名称,并读取当前CPU内核温度;

判断所述当前CPU内核温度是否超出预设报警温度阈值;

若所述当前CPU内核温度超出所述预设报警温度阈值,则生成输出低电平指令和主板电源关闭指令作为第二修复策略;

执行所述第二修复策略,获取对应的实时CPU内核温度作为所述第二修复结果;

记录所述当前运行程序的数量和名称、所述第二修复策略和所述第二修复结果至所述第二日志。

通过采用上述技术方案,判断当前运行程序的数量是否超过预设程序数量阈值,可分析出CPU内核过热是否由于程序同时运行过多的原因导致的,若当前运行程序的数量超出预设程序数量阈值,则进一步记录其数量以及对应的名称、后续的修复策略以及修复结果至第二日志,从而通过第二日志便于对引发CPU内核过热的原因以及相应修复处理过程进行追踪。

可选的,在所述判断所述当前CPU内核温度是否超出预设报警温度阈值之后还包括以下步骤:

若所述当前CPU内核温度超出所述预设报警温度阈值,则生成对应的清除COMS设置指令;

执行所述清除COMS设置指令,获取对应的清除COMS设置完成度;

记录所述清除COMS设置指令和所述清除COMS设置完成度至所述第二日志。

通过采用上述技术方案,若当前CPU内核温度超出对应预设报警温度阈值需要重新开机时,通过清除COMS设置,从而可减少因COMS设置错误造成系统不开机情况的发生。

可选的,在所述执行所述第二修复策略,获取对应的实时CPU内核温度作为所述第二修复结果之后还包括以下步骤:

判断所述实时CPU内核温度是否超出所述预设报警温度阈值;

若所述实时CPU内核温度超出所述预设报警温度阈值,则生成并执行对应的重启指令;

判断在预设重启时长内系统是否生成对应的开启信号;

若在所述预设重启时长内所述系统未生成对应的所述开启信号,则输出开机异常信息;

记录所述实时CPU内核温度、所述重启指令和所述开机异常信息至所述第二日志。

通过采用上述技术方案,对超出预设报警温度阈值的实时CPU内核温度以及执行重启指令后的运行开启信号进行记录,从而便于通过第二日志对实时CPU内核温度以及相应执行重启指令后的开启信号进行识别追踪。

第二方面,本申请提供一种轨道交通整机监控系统,包括:

第一获取模块,用于获取信号监控器接收到的目标运行信号;

识别模块,用于识别所述目标运行信号,获取对应的系统运行参数;

第一判断模块,用于判断所述系统运行参数是否符合对应的参数运行指标;

第二获取模块,若所述系统运行参数不符合对应的所述参数运行指标,所述第二获取模块则用于获取对应的异常运行项;

第二判断模块,用于判断所述异常运行项对应的修复类型;

第一记录模块,若所述修复类型为内部自行修复,所述第一记录模块则用于获取并记录所述异常运行项、所述异常运行项对应的修复指令以及所述修复指令对应的第一修复结果至第一日志;

第二记录模块,若所述修复类型为外部控制修复,所述第二记录模块则用于获取并记录所述异常运行项、所述异常运行项对应的修复策略以及所述修复策略对应的第二修复结果至第二日志。

通过采用上述技术方案,根据第一获取模块获取信号监控器接收到设备的目标运行信号,以便于通过第一判断模块将设备的系统运行参数与对应的参数运行指标做对比,进而通过第二获取模块得出系统存在运行问题的异常运行项,进一步通过第二判断模块便于清楚区分异常运行项以及其对应的修复类型,随即通过第一记录模块将可通过系统内部自行修复的异常运行项、异常运行项对应的修复指令以及相应的第一修复结果记录至第一日志,通过第二记录模块将需通过外部控制修复的异常运行项、异常运行项对应的修复策略以及相应的第二修复结果记录至第二日志,从而便于通过第一日志或第二日志记录追溯系统出现的异常问题以及异常问题的修复处理过程,提升了对轨道交通整机的监控效果。

第三方面,本申请提供一种终端设备,采用如下的技术方案:

一种终端设备,包括存储器和处理器,所述存储器中存储有能够在处理器上运行的计算机指令,所述处理器加载并执行计算机指令时,采用了上述的一种轨道交通整机监控方法。

通过采用上述技术方案,通过将上述的一种轨道交通整机监控方法生成计算机指令,并存储于存储器中,以被处理器加载并执行,从而,根据存储器及处理器制作终端设备,方便使用。

第四方面,本申请提供一种计算机可读存储介质,采用如下的技术方案:

一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器加载并执行时,采用了上述的一种轨道交通整机监控方法。

通过采用上述技术方案,通过将上述的一种轨道交通整机监控方法生成计算机指令,并存储于计算机可读存储介质中,以被处理器加载并执行,通过计算机可读存储介质,方便计算机指令的可读及存储。

综上所述,本申请包括以下至少一种有益技术效果:根据信号监控器接收到设备的目标运行信号,以便于将设备的系统运行参数与对应的参数运行指标做对比,得出系统存在运行问题的异常运行项,进一步为了清楚区分记录异常运行项以及其对应的修复类型,将可通过系统内部自行修复的异常运行项、异常运行项对应的修复指令以及相应的第一修复结果记录至第一日志,将需通过外部控制修复的异常运行项、异常运行项对应的修复策略以及相应的第二修复结果记录至第二日志,从而便于通过第一日志或第二日志记录追溯系统出现的异常问题以及异常问题的修复处理过程,提升了对轨道交通整机的监控效果。

附图说明

图1是本申请一种轨道交通整机监控方法中步骤S101至步骤S107的流程示意图。

图2是本申请一种轨道交通整机监控方法中CPU与EC的连接示意图。

图3是本申请一种轨道交通整机监控方法中步骤S201至步骤S207的流程示意图。

图4是本申请一种轨道交通整机监控方法中步骤S301至步骤S304的流程示意图。

图5是本申请一种轨道交通整机监控方法中步骤S401至步骤S406的流程示意图。

图6是本申请一种轨道交通整机监控方法中步骤S501至步骤S507的流程示意图。

图7是本申请一种轨道交通整机监控方法中步骤S601至步骤S603的流程示意图。

图8是本申请一种轨道交通整机监控方法中步骤S701至步骤S705的流程示意图。

图9是本申请一种轨道交通整机监控系统的模块示意图。

附图标记说明:

1、第一获取模块;2、识别模块;3、第一判断模块;4、第二获取模块;5、第二判断模块;6、第一记录模块;7、第二记录模块。

具体实施方式

以下结合附图1-9对本申请作进一步详细说明。

本申请实施例公开一种轨道交通整机监控方法,如图1所示,包括以下步骤:

S101.获取信号监控器接收到的目标运行信号;

S102.识别目标运行信号,获取对应的系统运行参数;

S103.判断系统运行参数是否符合对应的参数运行指标;

S104.若系统运行参数不符合对应的参数运行指标,则获取对应的异常运行项;

S105.判断异常运行项对应的修复类型;

S106.若修复类型为内部自行修复,则获取并记录异常运行项、异常运行项对应的修复指令以及修复指令对应的第一修复结果至第一日志;

S107.若修复类型为外部控制修复,则获取并记录异常运行项、异常运行项对应的修复策略以及修复策略对应的第二修复结果至第二日志。

在本实施例中,步骤S101中的信号监控器是指独立的微处理器,如图2所示,为CPU与信号监控器的连接示意图,本方案以CPU为例展开说明,其中EC为信号监控器,信号监控器使用GPIO作为输入信号,连接CPU的关键信号,信号监控器可通过获取CPU的关键信号分析出CPU的实际运行状态。

需要说明的是,独立的微处理器可设置为IT8987E控制器芯片,当信号监控器接收到CATERR#信号时,代表CPU出现关键运算错误,接收到THERMTIP#信号时,代表CPU内核过热,接收到PROCHOT#信号时,代表CPU普通过热,接收到PWRBTN#信号时,代表开机指令,接收到SYS_RESET信号时,可以通过信号监控器通过GPIO使系统复位,接收到RTCRST信号时,可以清除主板CMOS设定重新开机,接收到PECI信号时,信号监控器可以通过清单读取CPU的内核温度,接收到ESPI信号时,信号监控器可以让主机重新从备用BIOS ROM启动,上述CATERR#信号、THERMTIP#信号、PROCHOT#信号、PWRBTN#信号、SYS_RESET信号、RTCRST信号、PECI信号、ESPI信号即为步骤S101中的目标运行信号。

进一步可通过识别上述目标运行信号得到CPU的系统运行参数,为了便于获取CPU出现异常时的具体原因,通过将上述获取的系统运行参数与对应的参数运行指标进行对比,进而判断出CPU出现异常时的异常运行项,其中,参数运行指标是指CPU正常运行下的各项参数指标,异常运行项是指CPU的系统运行参数不符合对应参数运行指标对应的功能模块项。

例如,当信号监控器接收到CATERR#信号时,代表CPU出现关键运算错误,此时CPU对应的系统运行参数为CPU运算参数,说明该CPU运算参数不符合正常情况下CPU进行运算时所运行的参数即CPU运算模块所对应的参数运行指标。

又例如,当信号监控器接收到THERMTIP#信号时,代表CPU内核过热,此时CPU对应的系统运行参数为CPU内核温度参数,说明该CPU内核温度参数不符合正常情况下CPU内核温度参数即CPU内核测温模块所对应的参数运行指标。

在实际运用中,CPU出现的某些异常只能通过CPU内部自行修复,有的异常需要依靠外部生成相应的控制指令对其进行修复,故为了区分上述两类处理过程,以便于后期对其异常运行项以及相应修复过程进行记录追溯,对获取的异常运行项对应的修复类型进行分析判断。

需要说明的是,若异常运行项对应的修复类型为内部自行修复,则说明CPU可以依据自身配置或者辅助功能模块对异常运行项进行修复或者通过整个系统重新启动运行解决,进一步为了实时监测当出现异常运行项时,CPU所下达的修复指令是否执行以及获取修复指令执行后相应的修复结果即步骤S106中的第一修复结果,将上述出现的异常运行项,以及异常运行项对应的修复指令和第一修复结果记录至第一日志,第一日志是记载上述修复类型为内部自行修复的异常运行项以及相应系统动作的记录。

例如,当信号监控器接收到CATERR#信号时,代表CPU出现关键运算错误,一般情况下,当CPU诊断出关键错误时都是由CPU自身解决处理,进一步跟踪记录CPU针对出现关键运算错误所下达的修复指令,以及相应的修复结果,修复指令可以是通过保持置位状态,直到热或冷复位,第一修复结果为复位后CPU的关键运算参数,将上述CPU关键运算错误、热或冷复位以及复位后CPU的关键运算参数记录至第一日志,当然第一日志中也会记录到信号监控器接收到CATERR#信号的发出时间。

其中,单片机系统从没加电到加上电源,而自动产生的复位称为冷复位,单片机系统在已经通电的情况下,给他一个复位信号,称为热复位。冷复位会使单片机的特殊功能寄存器和数据存储器的内容都改变,而热复位只是特殊功能寄存器的内容改变而单片机的内部数据存储器的内容不变。

需要说明的是,若异常运行项的修复类型为外部控制修复,则信号监控器通过识别该异常运行项对应的目标运行信号,向外部系统发送相应的修复控制指令对CPU进行修复,此时记录识别到的异常运行项、向外部发送的修复控制指令即修复策略以及执行修复策略后该异常运行项所对应的运行参数值即第二修复结果至第二日志,第二日志是记载上述修复类型为外部控制修复的异常运行项以及相应系统动作的记录,其中,异常运行项的修复类型为内部自行修复或者外部控制修复的识别判断,是根据信号监控器内部对CPU输出信号的分类识别训化所形成的识别模型来区分的。

例如,当信号监控器接收到PROCHOT#信号时,代表CPU普通过热,则此时对应的修复策略为将CPU频率降到最低,降低自身发热,根据上述修复策略,信号监控器分别发送限制CPU频率控制指令和系统风扇启动控制指令,上述修复策略对应的第二修复结果为CPU的实时频率值和CPU实时温度,随即将CPU普通过热、CPU频率控制指令和系统风扇启动控制指令、CPU的实时频率值和CPU实时温度记录至第二日志。

本实施方式提供的轨道交通整机监控方法,根据信号监控器接收到设备的目标运行信号,以便于将设备的系统运行参数与对应的参数运行指标做对比,得出系统存在运行问题的异常运行项,进一步为了清楚区分记录异常运行项以及其对应的修复类型,将可通过系统内部自行修复的异常运行项、异常运行项对应的修复指令以及相应的第一修复结果记录至第一日志,将需通过外部控制修复的异常运行项、异常运行项对应的修复策略以及相应的第二修复结果记录至第二日志,从而便于通过第一日志或第二日志记录追溯系统出现的异常问题以及异常问题的修复处理过程,提升了对轨道交通整机的监控效果。

在本实施例的其中一种实施方式中,如图3所示,异常运行项包括CPU运算错误,并且步骤S106即若修复类型为内部自行修复,则获取并记录异常运行项、异常运行项对应的修复指令以及修复指令对应的第一修复结果至第一日志包括以下步骤:

S201.若修复类型为内部自行修复,则获取并判断CPU运算错误的错误类型;

S202.若错误类型为CPU运算不可纠正错误,则生成对应的重启指令作为第一修复指令;

S203.执行第一修复指令,获取对应的重启运行参数作为第一修复结果;

S204.记录CPU运算不可纠正错误、第一修复指令和第一修复结果至第一日志;

S205.若错误类型为CPU运算可纠正错误,则生成对应的恢复指令作为第二修复指令;

S206.执行第二修复指令,获取对应的恢复运行参数作为第一修复结果;

S207.记录CPU运算可纠正错误、第二修复指令和第一修复结果至第一日志。

在实际运用中,CPU运算错误是指CPU在正常工作过程中出现的数据读取或者运算的错误,其中,CPU运算错误的错误类型包括可通过自身控制消除错误即CPU运算可纠正错误或者错误无法纠正需系统重启即CPU运算不可纠正错误。

其中,出现蓝屏就是CPU运算不可纠正错误的一种类型,蓝屏是一种WINDOWS操作系统上使用的保护机制,一般来说,当一个程序或者进程的低权限代码去访问一个高权限的数据区的时候,或者CPU运算内错误的时候操作系统会把它交给异常处理程序,当异常处理程序也无法进行处理的时候,操作系统就有可能停止响应而出现蓝屏。

再者,ECC内存出现错误就属于CPU运算可纠正错误,CPU会把要运算的各种数据从硬盘读取到内存,和内存交互数据,内存的稳定性很大程度决定了电脑平台运行时的稳定性,无线电磁干扰等一些干扰都会导致内存在和CPU交互数据时发生比特翻转,ECC内存可以主动发现数据传输过程中出现的错误,并将错误纠正,所以ECC内存出现错误就无法主动发现数据传输过程中出现的错误。

例如,当信号监控器接收到CPU的CATERR#信号时,说明CPU关键运算出现错误,进一步识别到CPU运算错误的修复类型为内部自行修复后,再次判断出CPU运算错误为蓝屏且属于CPU运算不可纠正错误,因为出现蓝屏一般通过重启来解决,所以生成对应的重启指令即步骤S202中的第一修复指令,经手动或者自动重启后,系统重启后运行的相关参数即重启运行参数作为第一修复结果,将上述过程中的蓝屏即CPU运算不可纠正错误、重启指令即第一修复指令、重启运行参数即第一修复结果记录至第一日志,从而通过第一日志可以追溯蓝屏的产生原因、重启指令是否执行以及重启后系统的相关运行参数是否正常。

又例如,当信号监控器识别到CPU运算错误的修复类型为内部自行修复时后,又判断出ECC内存错误为CPU运算可纠正错误,随即生成对应的恢复指令即步骤S205中的第二修复指令为热或冷复位,将热或冷复位后的ECC内存运行参数作为第一修复结果,将上述过程中的ECC内存错误即CPU运算可纠正错误、恢复指令即第二修复指令、ECC内存运行参数即第一修复结果记录至第一日志,从而通过第一日志可以追溯ECC内存错误、恢复指令是否执行以及热或冷复位后ECC内存运行参数是否正常。

本实施方式提供的轨道交通整机监控方法,进一步对CPU运算错误的错误类型进行分类细化,从而便于通过第一日志对CPU运算不可纠正错误或者CPU运算可纠正错误的异常运行项以及相应修复指令和修复结果进行记录追踪,实时记录系统的异常状态以及相应修复过程。

在本实施例的其中一种实施方式中,如图4所示,异常运行项包括CPU温度异常,并且步骤S107即若修复类型为外部控制修复,则获取并记录异常运行项、异常运行项对应的修复策略以及修复策略对应的第二修复结果至第二日志包括以下步骤:

S301.若修复类型为外部控制修复,则获取并判断CPU温度异常的异常类型;

S302.若异常类型为主板过热,则生成对应的降热指令作为第一修复策略;

S303.执行第一修复策略,获取对应的CPU实时温度作为第二修复结果;

S304.记录主板过热、第一修复策略和第二修复结果至第二日志。

在实际运用中,CPU温度异常是指由于CPU温度过高而产生的异常,其中主板温度过高也是引起CPU温度过高的原因之一,一般引起主板温度过高的原因有:机箱内及主板灰尘多、机箱排风通道不流畅、主板传感器损坏等原因导致。

其中,CPU和主板正常温度应该是40度左右,一般在夏季主板温度在60度以下都算正常,但由于长时间的工作或玩大型游戏,主板在80度以下也可以算是正常,现在的主板一般可以承受的温度可以高达110度,但主板长时间在高温状态下工作,会使主板、芯片组的寿命降低。

例如,信号监控器接收到CPU的PROCHOT#信号时,代表着CPU此时出现过热,进一步识别判断该PROCHOT#信号属于外部控制修复,且CPU温度异常的异常类型为主板过热,则生成对应的降热指令作为第一修复策略,降热指令是指对CPU进行降频和散热的指令,执行上述降热指令后会限制CPU的运行频率,以及启动CPU风扇对CPU进行物理降温。

其中,执行降热指令后,再次获取CPU实时温度作为第二修复结果,其中,CPU实时温度的获取可以通过温度传感器对CPU温度进行实时获取,进一步将主板过热、降热指令即第一修复策略、CPU实时温度即第二修复结果记录至第二日志,通过第二日志可对CPU温度异常的异常类型、出现CPU温度异常系统所下达的修复策略以及修复后CPU的实时温度进行追溯。

本实施方式提供的交通整机监控方法,将主板过热、降热指令以及执行降热指令后CPU实时温度记录至第二日志,从而便于通过第二日志实时对主板过热的异常情况以及相应修复处理过程进行记录追踪。

在本实施例的其中一种实施方式中,如图5所示,降热指令包括降频指令和散热指令,并且步骤S303即执行第一修复策略,获取对应的CPU实时温度作为第二修复结果包括以下步骤:

S401.执行降频指令,获取对应的CPU频率值;

S402.判断CPU频率值是否达到预设CPU频率最低值;

S403.若CPU频率值达到预设CPU频率最低值,则获取对应的CPU实时温度;

S404.判断CPU实时温度是否处于预设CPU正常温度阈值范围;

S405.若CPU实时温度处于预设CPU正常温度阈值范围,则停止执行散热指令,并获取CPU实时温度作为第二修复结果;

S406.若CPU实时温度超出预设CPU正常温度阈值范围,则继续执行散热指令,并获取CPU实时温度作为第二修复结果。

在实际运用中,CPU频率即CPU的时钟频率,是指CPU运算时的工作频率,决定计算技术的运行速度,单位是Hz,CPU频率处于2.8-3.0GHZ即CPU频率值较为合适,CPU主频越高,处理器的性能越好,主频的高低对于CPU运算速度至关重要,主频越高,处理器越快,所处理的数据就越多越快。其中,启动超频很容易引起CPU的发热,因为一旦使用超频就要提高CPU的工作电压,电压升高,CPU的发热量自然增加,只要发热量与散热量不平衡就会导致CPU温度过高,所以降低CPU频率的频率值是对CPU降温的有效手段。

需要说明的是,系统执行降频指令后,对CPU的主频进行限制,为了快速对CPU降温,本方案选择将CPU主频降到最低值即步骤S402中的预设CPU频率最低值为CPU主频最低值,以预设CPU频率最低值为标准判断当前CPU频率值是否达到相应标准,若达到则获取当前CPU的温度即步骤S403中的CPU实时温度,判断此时的CPU实时温度是否处于CPU的正常温度值范围即步骤S404中的预设CPU正常温度阈值范围。

其中,若CPU实时温度处于预设CPU正常温度阈值范围,则说明执行降频指令达到了预期降温的效果,此时为了减少系统功耗,停止执行散热指令,若CPU实时温度超出预设CPU正常温度阈值范围,则说明执行降频指令未达到预期降温的效果,此时为了加强对CPU的降温效果,继续执行散热指令,CPU风扇根据散热指令启动,并对CPU进行吹风降温,必要时还可将CPU风扇转速调至最大;为了实时关注CPU的温度,执行降频指令或者散热指令后,都需要对CPU的实时温度进行获取记录,CPU实时温度可通过系统内置的CPU温度传感器获取。

本实施方式提供的轨道交通整机监控方法,判断执行降频指令后的CPU实时温度是否处于预设CPU正常温度阈值范围,依此作为是否继续执行散热指令的依据,从而降低了系统功耗。

在本实施例的其中一种实施方式中,如图6所示,在步骤S301即若修复类型为外部控制修复,则获取并判断CPU温度异常的异常类型之后还包括以下步骤:

S501.若异常类型为CPU内核过热,则获取当前运行程序;

S502.判断当前运行程序的数量是否超过预设程序数量阈值;

S503.若当前运行程序的数量超过预设程序数量阈值,则获取当前运行程序的数量和名称,并读取当前CPU内核温度;

S504.判断当前CPU内核温度是否超出预设报警温度阈值;

S505.若当前CPU内核温度超出预设报警温度阈值,则生成输出低电平指令和主板电源关闭指令作为第二修复策略;

S506.执行第二修复策略,获取对应的实时CPU内核温度作为第二修复结果;

S507.记录当前运行程序的数量和名称、第二修复策略和第二修复结果至第二日志。

在实际运用中,CPU内核是CPU中间的核心芯片,有单晶硅制成,用来完成所有的计算,接受/存储命令、处理数据等,是数字处理核心,由于所有的计算都要在CPU内核上进行,所以CPU内核会散发出大量的热量,一旦温度过高,就会造成CPU运行不正常甚至烧毁,所以CPU内核的控温至关重要。

其中,系统运行程序即步骤S501中的当前运行程序的增多会导致CPU内核工作量的加大,故为了减少了更多程序的同时运行,对当前运行程序的数量进行判断,判断其是否超出系统规定可同时运行的数量即步骤S502中的预设程序数量阈值,预设程序数量阈值的设置也是防止CPU内核继续升温的有效措施,若当前运行程序的数量超过预设程序数量阈值,则说明系统同时运行的当前运行程序数量已经给CPU内核带来负担,并且为CPU内核继续升温提供了条件,此时将当前运行程序数量以及相应的名称记录至第二修复结果,以便后续为工作人员提供分析材料。

进一步,获取并判断当前CPU内核温度是否超出预设报警温度阈值,预设报警温度阈值是指预先设置的CPU内核温度最大值,超出该CPU内核温度最大值可能造成CPU烧毁,若当前CPU内核温度超出该预设报警温度阈值,则生成对应的低电平指令和主板电源关闭指令,根据低电平指令控制CPU输出低电压,根据主板电源关闭指令切断系统内的主板电源,并将生成低电平指令和主板电源关闭指令,以及执行低电平指令和主板电源关闭指令后的CPU内核温度即步骤S506中的实时CPU内核温度记录至第二日志,以便于工作人员对CPU内核温度以及该CPU内核温度过高时的修复过程进行追溯。

本实施方式提供的轨道交通整机监控方法,判断当前运行程序的数量是否超过预设程序数量阈值,可分析出CPU内核过热是否由于程序同时运行过多的原因导致的,若当前运行程序的数量超出预设程序数量阈值,则进一步记录其数量以及对应的名称、后续的修复策略以及修复结果至第二日志,从而通过第二日志便于对引发CPU内核过热的原因以及相应修复处理过程进行追踪。

在本实施例的其中一种实施方式中,如图7所示,在步骤S504即判断当前CPU内核温度是否超出预设报警温度阈值之后还包括以下步骤:

S601.若当前CPU内核温度超出预设报警温度阈值,则生成对应的清除COMS设置指令;

S602.执行清除COMS设置指令,获取对应的清除COMS设置完成度;

S603.记录清除COMS设置指令和清除COMS设置完成度至第二日志。

在实际运用中,对一台新安装的电脑或者系统,要对它做一些设置即COMS设置,主板的COMS记录计算机的日期、时间、硬盘参数、软驱情况及它的高级参数,又称BIOS设置,COMS能把这些信息保存下来,即使关机它们也不会丢失,所以不必对它重新设置,除非需要改变电脑配置或意外情况导致的COMS内容丢失。

需要说明的是,若当前CPU内核温度超出预设报警温度阈值,可能是CPU开启了的超频模式,此种情况下超频可能导致系统不稳定或者黑屏,此时就需要清除COMS设置即步骤S601中的清除COMS设置指令,此时CPU的频率也可回到超频之前的默认速度,另一方面,信号的监控器通过GPIO清除COMS设置,也可减少设置错误,设置错误包括CPU、DDR和PCIE频率设置错误,以及偶发因素造成的寄存器错误,都需要清除COMS设置,从而在CPU内核温度过高需要重启时不能正常开机情况的发生。

其中,当前CPU内核温度超出对应的预设报警温度阈值时,生成并执行清除COMS设置指令,并实时记录清除COMS设置过程中的清除记录即步骤S602中的清除COMS设置完成度,最后记录清除COMS设置指令和对应的清除COMS设置完成度至第二日志,以便于通过第二日志追溯信号监控器下达的清除COMS设置指令以及下达清除COMS设置指令后COMS设置清除的完成度。

本实施方式提供的轨道交通整机监控方法,若当前CPU内核温度超出对应预设报警温度阈值需要重新开机时,通过清除COMS设置,从而可减少因COMS设置错误造成系统不开机情况的发生。

在本实施例的其中一种实施方式中,如图8所示,在步骤S506即执行第二修复策略,获取对应的实时CPU内核温度作为第二修复结果之后还包括以下步骤:

S701.判断实时CPU内核温度是否超出预设报警温度阈值;

S702.若实时CPU内核温度超出预设报警温度阈值,则生成并执行对应的重启指令;

S703.判断在预设重启时长内系统是否生成对应的开启信号;

S704.若在预设重启时长内系统未生成对应的开启信号,则输出开机异常信息;

S705.记录实时CPU内核温度、重启指令和开机异常信息至第二日志。

在实际运用中,若实时CPU内核温度超出对应的预设报警温度阈值,则CPU随时都有烧毁的危险,为了减少此类情况的发生,可预先生成对应的重启指令,为了提升CPU正常启动系统的概率,在预设重启时长内判断系统是否生成对应的开启信号,预设重启时长是指预先设置的CPU重新启动相应系统的时长,开启信号是指CPU重新启动系统时所发出的指示信号。

需要说明的是,CPU无法正常启动系统的原因有,SPI ROM存在概率性单个字节不良,其中,CPU正常启动系统时,CPU会关闭信号监控器内置的看门狗,CPU无法正常启动系统时,信号监控器内置的看门狗生效,信号监控器会重置系统并将SPI切换到备用的SPI ROM。

由上述可得,当CPU无法正常启动系统时,信号监控器会重置系统并将SPI切换到备用的SPI ROM,使得主机重新从备用的BIOS ROM启动,为了实时监控CPU的正常启动,判断系统在预设重启时长内是否生成对应的开启信号,此处的预设重启时长也可以指信号监控器重置系统并将SPI切换到备用的SPI ROM,使得主机重新从备用的BIOS ROM启动所用的标准时长,若在预设重启时长内未检测到对应的开启信号,则说明CPU重启失败,随即输出对应的开机异常信息,记录实时CPU内核温度、重启指令和开机异常信息至第二日志,若在预设重启时长内检测到生成的开启信号,则将开启信号对应的生成时间记录至第二日志。

本实施方式提供的轨道交通整机监控方法,对超出预设报警温度阈值的实时CPU内核温度以及执行重启指令后的运行开启信号进行记录,从而便于通过第二日志对实时CPU内核温度以及相应执行重启指令后的开启信号进行识别追踪。

本申请实施例公开一种轨道交通整机监控方法,如图9所示,包括:

第一获取模块1,用于获取信号监控器接收到的目标运行信号;

识别模块2,用于识别目标运行信号,生成对应的系统运行参数;

第一判断模块3,用于判断系统运行参数是否符合对应的参数运行指标;

第二获取模块4,若系统运行参数不符合对应的参数运行指标,第二获取模块4则用于获取对应的异常运行项;

第二判断模块5,用于判断异常运行项对应的修复类型;

第一记录模块6,若修复类型为内部自行修复,第一记录模块6则用于获取并记录异常运行项、异常运行项对应的修复指令以及修复指令对应的第一修复结果至第一日志;

第二记录模块7,若修复类型为外部控制修复,第二记录模块7则用于获取并记录异常运行项、异常运行项对应的修复策略以及修复策略对应的第二修复结果至第二日志。

本实施例提供的轨道交通整机监控系统,根据第一获取模块1获取信号监控器接收到设备的目标运行信号,以便于通过第一判断模块3将设备的系统运行参数与对应的参数运行指标做对比,进而通过第二获取模块4得出系统存在运行问题的异常运行项,进一步通过第二判断模块5便于清楚区分异常运行项以及其对应的修复类型,随即通过第一记录模块6将可通过系统内部自行修复的异常运行项、异常运行项对应的修复指令以及相应的第一修复结果记录至第一日志,通过第二记录模块7将需通过外部控制修复的异常运行项、异常运行项对应的修复策略以及相应的第二修复结果记录至第二日志,从而便于通过第一日志或第二日志记录追溯系统出现的异常问题以及异常问题的修复处理过程,提升了对轨道交通整机的监控效果。

需要说明的是,本申请实施例所提供的轨道交通整机监控系统,还包括与上述任一轨道交通整机监控方法的逻辑功能或逻辑步骤所对应的各个模块和/或对应的子模块,实现与各个逻辑功能或者逻辑步骤相同的效果,具体在此不再累述。

本申请实施例还公开一种终端设备,包括存储器、处理器以及存储在存储器中并能够在处理器上运行的计算机指令,其中,处理器执行计算机指令时,采用了上述实施例中的任意一种轨道交通整机监控方法。

其中,终端设备可以采用台式电脑、笔记本电脑或者云端服务器等计算机设备,并且,终端设备包括但不限于处理器以及存储器,例如,终端设备还可以包括输入输出设备、网络接入设备以及总线等。

其中,处理器可以采用中央处理单元(CPU),当然,根据实际的使用情况,也可以采用其他通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等,通用处理器可以采用微处理器或者任何常规的处理器等,本申请对此不做限制。

其中,存储器可以为终端设备的内部存储单元,例如,终端设备的硬盘或者内存,也可以为终端设备的外部存储设备,例如,终端设备上配备的插接式硬盘、智能存储卡(SMC)、安全数字卡(SD)或者闪存卡(FC)等,并且,存储器还可以为终端设备的内部存储单元与外部存储设备的组合,存储器用于存储计算机指令以及终端设备所需的其他指令和数据,存储器还可以用于暂时地存储已经输出或者将要输出的数据,本申请对此不做限制。

其中,通过本终端设备,将上述实施例中的任意一种轨道交通整机监控方法存储于终端设备的存储器中,并且,被加载并执行于终端设备的处理器上,方便使用。

本申请实施例还公开一种计算机可读存储介质,并且,计算机可读存储介质存储有计算机指令,其中,计算机指令被处理器执行时,采用了上述实施例中的任意一种轨道交通整机监控方法。

其中,计算机指令可以存储于计算机可读介质中,计算机指令包括计算机指令代码,计算机指令代码可以为源代码形式、对象代码形式、可执行文件或某些中间件形式等,计算机可读介质包括能够携带计算机指令代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM)、随机存取存储器(RAM)、电载波信号、电信信号以及软件分发介质等,需要说明的是,计算机可读介质包括但不限于上述元器件。

其中,通过本计算机可读存储介质,将上述实施例中的任意一种轨道交通整机监控方法存储于计算机可读存储介质中,并且,被加载并执行于处理器上,以方便上述方法的存储及应用。

以上均为本申请的较佳实施例,并非依此限制本申请的保护范围,故:凡依本申请的结构、形状、原理所做的等效变化,均应涵盖于本申请的保护范围之内。

技术分类

06120115629832