事件链分析和推理

Question

我的老板说客户无法接受当前状态的日志。如果出现故障，设备的十几个不同模块会报告自己的错误，并且都会记录在日志中。故障的原因可能隐藏在列表中间的某个位置，可能不会出现在列表中（给定模块损坏太大而无法报告），或者在其他所有内容完成报告原始故障导致的问题后出现。无论如何，系统开发人员之外很少有人可以正确地解释日志并提出实际发生的事情。

我目前的任务是编写一个能够进行客户友好型故障报告的模块。也就是说，收集在过去~3秒内报告的所有事件（大约是发生故障的原点和最后产生的后果之间的最大间隔），对这些数据做一些神奇的处理，并拿出来一条清晰，友好的线条，什么是破碎的，需要修复。

问题是神奇的部分：在给出大量故障报告的情况下，如何提出故障的原始来源。没有简单的因果清单列表。只有通常发生的事件链显示出某些规律性。

示例：

• 检测到短路，导致运行模式受限，限制运行不排除故障，因此紧急状态升级，总输出功率断开。
• 安全线订婚了。没有任何模块报告说自从参与以来已经在3s内使用它，因此“未知来源或干扰”被认为是系统停止的原因。
• 大多数输出​​模块报告没有输出电压。大约1秒后，电源监控模块报告电源耗尽，这是原因。
• 输出模块在其所有输出线中均未报告输出电压。没有来自电源模块的报告。原因是电源线与模块断开连接。
• 输出模块在其输出线之一中不报告输出电压。没有报告其他故障。原因是烧毁了保险丝。
• 输出模块未报告应用已接收状态。不久之后，控制模块报告非法状态或输出线，（由输出模块导致实际上没有及时更新状态。）原因是输出模块（引入故障），而不是控制模块（停止了由于检测到故障而导致的系统）。
• 输入模块的故障将设备切换到备用故障保护模式。到目前为止尚未使用的输出模块在此模式下处于故障状态且故障模式升级为严重。最初的原因不是输入，它可以报告有关故障的误报，但是中断的备份输出会中止操作。
• 最近2秒内输出模块没有任何活动。这意味着它已损坏，必须输入故障模式。

没有关于导致什么原因的全面规则列表。当新的故障“在野外”发生并被诊断​​和修复时，将添加规则。其中一些是启发式的 - 如果这个错误伴随着这些错误，那么错误很可能就是这个。有些故障无法解决 - 一份乏味的模块报告清单就足够了。一些答案将是暧昧的，一组症状可能暗示两种不同的缺点。这更像是“尽力而为”而不是“保证解决方案”。

现在针对（过于笼统和模糊）的问题：如何解决这个问题？是否有针对此类问题的特定算法，方法或通用解决方案？如何编写通用规则集并与之匹配？如何进行软匹配？ （比如，一个输入模块在紧急停止期间突然断开，这是一个完全无关的事件被忽略。）请帮忙吗？

Answer 1

说实话，我会写一系列简单的规则并完成它。这将是一个痛苦的维护明智，但做到这一点可能是耗时和脆弱的。

如果你坚持，我会通过让每个错误为每个错误代码删除某种符号/标记来解决这个问题 - 如果你尝试做一些单词/关键字匹配，你会更加努力。然后，您将在某种分类器中输入输出的令牌。

从本质上讲，你需要某种规则引擎 - 无论是模糊还是精确。首先想到的是手工构建的贝叶斯网络。这将允许模糊匹配，因为您可以计算最可能的“报告”作为您收到的令牌的函数。它还允许您通过指定返回答案的最小概率来为实际上没有指示任何内容的令牌组设置阈值。

你也可以训练一个贝叶斯网或其他类型的分类器，但你需要手动标记的相当多的数据（token1，token2，token3-＆gt; faultxyz），它可能更准确它自己。