我的老板说客户不能接受当前状态的日志。如果出现故障，设备的十几个不同模块会报告它们自己的错误，并且它们都会记录在日志中。故障的原始原因可能隐藏在列表中间的某个地方，可能不会出现在列表中（考虑到模块损坏太大而无法报告），或者在其他所有内容完成报告原始故障导致的问题之后才出现。无论如何，除了系统开发人员之外，很少有人能够正确解释日志并得出实际发生的情况。
我目前的任务是编写一个模块来进行客户友好的故障报告。也就是说，收集过去约 3 秒内报告的所有事件（大约是故障发生的起源和最后产生的后遗症之间的最大间隔），对这些数据进行一些神奇的处理，然后得出一条清晰、友好的路线，什么是坏的，需要修复。
问题是神奇的部分：如何在给定大量故障报告的情况下找出故障的原始来源。没有简单的因果列表。只有经常发生的事件链显示出某些规律性。
例子：
- 检测到短路，导致限制操作模式，限制操作不排除故障，因此紧急状态升级，总输出功率断开。
- 安全线被启用。没有模块报告在它被接合后的 3 秒内接合它，因此将“未知来源或干扰”归结为系统停止的原因。
- 大多数输出模块报告没有输出电压。大约1s后，电源监控模块报告power out，这是原来的原因。
- 输出模块在其所有输出线路中均未报告输出电压。电源模块无报告。原因是电源线与模块断开。
- 输出模块报告其输出线路之一没有输出电压。未报告其他故障。原因是保险丝烧毁。
- 输出模块没有报告应用收到的状态。不久之后，控制模块报告了非法状态或输出线，（由于输出模块确实没有及时更新状态。）原因是输出模块（引入故障），而不是控制模块（停止了故障）。系统由于检测到故障）。
- 输入模块故障将设备切换到备用故障安全模式。迄今为止未使用的有故障的输出模块进入此模式，并且故障模式升级为严重。最初的原因不是输入，它允许报告有关故障的误报，而是中断的备份输出导致操作中止。
- 在最后 2 秒内，输出模块没有任何类型的活动。这意味着它已损坏，必须进入故障模式。
对于什么导致什么，没有完整的规则列表。这些规则将随着新类型的故障“在野外”发生并被诊断和修复而添加。其中一些是启发式的——如果这个错误伴随着这些错误，那么很可能是这个错误。有些故障将无法解决 - 一个平淡无奇的模块报告列表就足够了。有些答案会模棱两可，一组症状可能表明两种不同的故障。这更像是“尽力而为”，而不是“有保证的解决方案”。
现在对于（过于笼统和模糊的）问题：如何解决这个问题？这类问题是否有特定的算法、方法或通用解决方案？如何编写通用规则集并与之匹配？如何进行软匹配？（比如说，一个输入模块在紧急停止过程中损坏了，这是一个完全不相关的事件，可以忽略。）请帮忙？