[0001] 本申请涉及物联网运维的领域，尤其是涉及一种基于云边协同框架下的物联终端故障诊断方法及系统。

[0002] 目前，随着物联网的快速发展，各类传感器、执行器、控制器等物联网终端设备被广泛部署，用于工业、交通、医疗、家庭等各个领域。这些物联网终端与互联网连接，大量产生各类数据。但是物联网终端也面临维护管理难题，它们部署地点分散，数量繁多，故障时缺乏快速准确的远程诊断和维护，依赖人工成本高。因此，开发智能、自动化的物联网终端故障诊断和运维技术，具有重要意义。

[0015] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图1‑附图8及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

[0016] 本申请提供的一种基于云边协同框架下的物联终端故障诊断方法，采用如下的技术方案：第一方面，如图1所示，提供一种基于云边协同框架下的物联终端故障诊断方法，包括：
S1：云端将故障诊断指令发送到MQTT Broker中；云端利用用户界面形式，提供设备诊断配置功能，用户可以选择需要进行诊断的边端设备，并指定诊断类型，如系统诊断、网络诊断、工况诊断等，同时填写相关诊断参数。配置完成后，云端将生成对应的诊断指令，并发送到 MQTT Broker指定的Topic中。

[0017] S2：物联终端通过MQTT Broker获取所述故障诊断指令，并对物联终端自身进行诊断，获取诊断结果；物联终端设备上运行诊断程序订阅诊断指令Topic，该诊断程序会实时接收 云端发布的诊断指令。接收到诊断指令后，诊断程序会调用解析模块对诊断指令进行解析，提取出诊断类型和诊断参数等信息。解析完成后，诊断执行模块会根据消息中指示的诊断类型，启用对应的诊断插件来执行具体的诊断工作，并传入解析得到的参数。

[0018] S3：物联终端将所述诊断结果发送给MQTT Broker；诊断插件使用各类采集器采集边端设备的数据，按照指定策略进行诊断分析，最终输出诊断结果。程序会将诊断结果构造为标准JSON格式的消息，并发布 到Broker中。

[0019] S4：云端通过MQTT Broker获取所述诊断结果。云端同时也有程序订阅诊断结果Topic，解析诊断结果并进行存储和可视化操作。

[0020] 优选的，如图2所示，所述云端将故障诊断指令发送到MQTT Broker中，包括：S11：响应于所述物联终端被选中，云端基于被选中的所述物联终端生成与所述物联终端对应的故障诊断指令；不同的物联终端，需要运维诊断的任务不一样；例如，现有的诊断任务包括：网络诊断、工况诊断、进程诊断、系统诊断、全面诊断；根据这些诊断任务，云端生成所述物联终端对应的故障诊断指令。在选择诊断任务的类型后，用户需要指定目标设备，并根据具体诊断任务类型填写相关参数，如诊断运行时间等。这些信息将构成最终下发的诊断指令。在指令下发前，系统需要判断目标设备是否有正在进行的诊断任务。如果存在正在运行的任务，则需要等待其结束返回结果之后，方可下发新诊断指令。当确认目标设备就绪时，系统即构造诊断指令并下发到MQTT Broker指定的Topic（主题）中。以此完成一次诊断任务的下发。通过该设计，我们实现了灵活的诊断类型选择和参数配置，并考虑了对设备诊断状态的检测，避免下发冲突。

[0021] S12：所述云端将所述故障诊断指令，发送给MQTT Broker。

[0022] 优选的，如图3所示，所述物联终端通过MQTT Broker获取所述故障诊断指令，并对物联终端自身进行诊断，获取诊断结果，包括：S21：所述物联终端在指定时间范围内，定时获取所述MQTT Broker发布的所述故障诊断指令；所述指定时间范围，为在程序运行时间内实时获取。

[0023] S22：所述物联终端中的诊断程序解析所述故障诊断指令；S23：所述物联终端中的诊断执行模块根据所述故障诊断指令，启用所述故障诊断指令对应的诊断模块对所述物联终端进行诊断。

[0024] 当接收到云端下发的JSON格式诊断指令时，开始执行以下流程：解析指令，提取诊断类型及参数信息。根据诊断类型，对参数进行校验。例如网络诊断需要包含对端IP、协议、端口等。如果参数校验不通过，则直接构造错误结果，发送到MQTT Broker，告知云端诊断失败原因。如果参数校验通过，则调用对应诊断插件执行任务。插件使用给定参数进行诊断，最终输出结果。

[0025] 这样，我们实现了对指令参数的校验，不合规的参数将返回错误而不是执行诊断；验证通过则调用插件执行实际诊断，并将最终结果返回给云端。

[0026] 优选的，如图4所示，所述物联终端将所述诊断结果发送给MQTT Broker，包括：S31：所述物联终端中的转换程序将所述诊断结果转换为标准信息；
S32：所述物联终端将所述标准信息定时推送到MQTT Broker。将诊断结果转化为JSON格式，发送到MQTT Broker指定Topic。云端从Broker订阅Topic，接收到结果并保存。所述标准信息定时推送的时刻，为在诊断结束后立即发送。

[0027] 第二方面，如图5所示，还提供一种基于云边协同框架下的物联终端故障诊断系统1，包括：
发送单元11：用于云端将故障诊断指令发送到MQTT Broker中；
诊断单元12：用于物联终端通过MQTT Broker获取所述故障诊断指令，并对物联终端自身进行诊断，获取诊断结果；
发布单元13：用于物联终端将所述诊断结果发送给MQTT Broker；
接收单元14：用于云端通过MQTT Broker获取所述诊断结果。

[0028] 优选的，如图6所示，所述发送单元11，包括：选择单元111：用于响应于所述物联终端被选中，云端基于被选中的所述物联终端生成与所述物联终端对应的故障诊断指令；
信息发送单元112：用于所述云端将所述故障诊断指令，发送给MQTT Broker。

[0029] 优选的，如图7所示，所述诊断单元12，包括：获取单元121：用于所述物联终端在指定时间范围内，定时获取所述MQTT Broker发布的所述故障诊断指令；
解析单元122：用于所述物联终端中的诊断程序解析所述故障诊断指令；
执行单元123：用于所述物联终端中的诊断执行模块根据所述故障诊断指令，启用所述故障诊断指令对应的诊断模块对所述物联终端进行诊断。

[0030] 优选的，如图8所示，所述发布单元13，包括：转换单元131：用于所述物联终端中的转换程序将所述诊断结果转换为标准信息；
推送单元132：用于所述物联终端将所述标准信息定时推送到MQTT Broker。

[0031] 如图9所示，是一种基于云边协同框架下的物联终端故障诊断系统构成图。其中，包括：1.物联终端设备：包含各类操作系统、架构的物联网传感器，负责收集和上传业务数据。

[0032] 2.Agent：可以部署于各种CPU架构和操作系统中，解析并执行诊断指令，在诊断结束后返回结果。

[0033] 3.MQTT Broker：提供MQTT协议支持，负责设备与系统的连接。

[0034] 4.云平台：提供设备诊断的人机交互，构造并下发诊断指令，负责展示诊断结果。

[0035] 基于云边协同框架下的物联终端故障诊断方法的工作具体实施例，如下：网络诊断：网络诊断结合了Traceroute和Ping的功能，旨在帮助分析网络问题。在指定时间段内下发命令，返回从本机出发到目标主机的每跳的网络情况，每跳包含信息包含当前跳数、当前主机IP地址、本跳丢包率、本跳发包数、本跳收包数、本跳的平均时延、本跳的最佳时延、本跳的最差时延和本跳的时延标准差（波动率）。接收到诊断任务后，网络诊断插件会解析出以下信息:诊断时间、目标设备地址(域名或IP)、网络协议(支持ICMP、TCP、UDP)、目标端口(ICMP不需要)；若为域名，则先进行解析获取目标IP。接下来，在诊断时间内。对目标发起正向链路探测。客户端持续向目标发送探测包，根据返回信息计算网络指标。主要统计指标有时延和丢包率，可以观察到每跳节点的网络质量。测量完成后，将结果打包并通过MQTT发送到云端。这样，用户和运维人员可以快速了解设备到目标的网络连接状况，发现链路上可能存在的故障点，比如时延过高或丢包严重的节点。这有助于网络问题的定位和优化。

[0036] 工况诊断：旨在分析当前操作系统的工况信息，当前支持对CPU温度的诊断，在指定时间段内下发工况诊断命令，返回结果数据，包含的信息有时间段内CPU温度最大值、最小值、平均值。接收到诊断任务后，工况诊断插件会解析出以下信息：诊断时间、设备CPU温度文件路径；对于常见操作系统，插件已知晓默认温度文件。不常见设备则需要提供自定义路径。在诊断时间范围内，插件定期读取该文件，获取CPU温度值。并对温度值进行必要的单位转换。统计出时间段内的最大温度、最小温度和平均温度。最后，将结果打包通过MQTT发送到云端。这样，用户和运维人员可以实时掌握设CPU的硬件工作情况，无需直接接触设备测量。相比传统方法，这种诊断方式更高效便捷。也节省了人力成本。

[0037] 系统诊断：在分析当前操作系统的性能情况，当前主要包含系统的CPU使用率、内存使用率和磁盘使用率，在指定时间段内下发系统诊断命令，返回结果数据，包含的信息如下：CPU使用率（最大值、最小值、平均值）、内存使用率（最大值、最小值、平均值）、磁盘使用率（最大值、最小值、平均值）；接收到诊断任务后，系统诊断插件仅需解析出诊断的时间长度。在此时间范围内，插件会定期读取系统的CPU、内存和磁盘等信息文件。并提取出关键指标数据，进行必要的单位转换。统计出各项指标在诊断期间的平均值、最大值和最小值。最终将这些统计结果打包，通过MQTT发送到云端。这样，用户可以在无需登录设备的情况下，实时了解系统的CPU、内存和磁盘等资源运行状态。相比传统方法，这种基于云端的诊断方式更高效便捷。

[0038] 进程诊断：为了分析当前操作系统的进程信息，以发现进程占用系统资源过大或僵尸进程情况，在指定时间段内下发进程诊断命令，返回结果数据，包含的信息如下：时间段内CPU使用率最多的三个进程（进程ID、进程名、进程状态、CPU使用率最大值、最小值、平均值）；时间段内内存使用率最多的三个进程（进程ID、进程名、进程状态、内存使用率最大值、最小值、平均值）；时间段内出现过的所有僵尸进程（进程ID、进程名和进程状态）。接收到诊断任务后，进程插件解析出诊断时长。在此时间范围内，插件定期收集系统所有进程的快照数据，包括CPU和内存占用率。对每个快照，插件分别统计CPU和内存占用率最高的3个进程，并进行累加计数。同时记录状态为“Z”的僵尸进程。在诊断结束后，插件基于计数次数对所有进程进行排序，分别找出CPU和内存占用率最高的3个进程。如果遇到次数相同的情况，则比对它们的平均占用率，选择更高的进程。最后，插件收集所有僵尸进程，并附加上述的TOP进程信息。将结果打包通过MQTT发送云端。进程诊断结果可以让用户直观地了解关键进程的资源占用分布情况，方便发现异常的僵尸进程，避免登录设备逐一检查的麻烦，提升了效率。

[0039] 综上所述，本申请包括以下至少一种有益技术效果：1.达到了快速、智能和远程化的物联网终端故障检测、定位、决策的需求；
2.减少了人工运维成本，提高了物联网终端的可靠性和系统运行效率。

[0040] 以上均为本申请的较佳实施例，并非依此限制本申请的保护范围，本说明书（包括摘要和附图）中公开的任一特征，除非特别叙述，均可被其他等效或者具有类似目的的替代特征加以替换。即，除非特别叙述，每个特征只是一系列等效或类似特征中的一个例子而已。