第121章　诊断理论

121.1 提出背景

第120章建立了异常检测理论。机器通过状态检测、行为检测、结果检测、数据检测和结构检测，可以发现对象是否偏离正常状态。

但是，发现异常并不等于理解异常。

例如，一个设备运行结果异常，机器只能确认：

$ActualResult≠ExpectedResultActualResult \neq ExpectedResult$

这说明“结果出现了问题”，却没有回答：

为什么会出现这个结果？

可能原因包括：

输入数据错误；
对象状态错误；
某个部件发生故障；
某个行为没有正确执行；
执行条件发生变化；
结构关系发生错误；
上游对象产生异常；
多个因素共同作用。

因此，在异常检测之后必须建立诊断（Diagnosis）机制。

诊断的核心过程为：

异常发现 → 异常对象识别 → 原因候选生成 → 原因匹配 → 原因评价 → 诊断结果

诊断理论解决的是机器认知中的因果判断问题。

121.2 诊断定义

诊断（Diagnosis）是指机器根据已经检测到的异常对象，通过分析异常表现、对象状态、行为、数据、结构以及相关条件，从候选原因中寻找与异常最匹配的原因，并形成结构化诊断结果的认知过程。

可以定义诊断函数：

$Dg=Diagnose(A,C,K)Dg=Diagnose(A,C,K)$

其中：

$AA$ ：Anomaly，异常对象；
$CC$ ：Cause，候选原因集合；
$KK$ ：Knowledge，已有规则、关系和经验知识；
$DgDg$ ：Diagnosis，诊断结果。

最基本的诊断关系为：

$A←CA \leftarrow C$

表示异常 $AA$ 可能由原因 $CC$ 导致。

因此：

$Cause→AnomalyCause \rightarrow Anomaly$

是原因到异常的产生关系，而：

$Anomaly→CauseAnomaly \rightarrow Cause$

是机器进行诊断时的逆向推理过程。

诊断理论就是建立这种逆向推理能力。

121.3 诊断与异常检测的区别

异常检测和诊断属于两个不同的认知过程。

异常检测回答：

是否异常？

诊断回答：

为什么异常？

因此：

$Detection≠DiagnosisDetection \neq Diagnosis$

其关系为：

$Observation→Detection→Anomaly→Diagnosis→CauseObservation \rightarrow Detection \rightarrow Anomaly \rightarrow Diagnosis \rightarrow Cause$

例如：

检测：
设备温度 = 95℃
正常范围 = 20℃～80℃

机器可以得到：

$TemperatureAnomaly=TRUETemperatureAnomaly=TRUE$

这是异常检测。

进一步分析：

冷却系统状态 = OFF
正常情况下 = ON

于是机器可以推断：

$CoolingSystemOff→TemperatureIncreaseCoolingSystemOff \rightarrow TemperatureIncrease$

这才进入诊断过程。

因此，异常检测提供诊断的输入，诊断则进一步寻找异常原因。

121.4 异常对象

121.4.1 异常对象定义

异常对象（Anomaly Object）是机器经过异常检测后形成的、用于描述异常目标、异常类型、实际状态、期望状态以及偏差信息的结构化对象。

可以定义：

$AO={O,T,E,A,D,S,C}AO=\{O,T,E,A,D,S,C\}$

其中：

$OO$ ：Target Object，异常目标对象；
$TT$ ：Anomaly Type，异常类型；
$EE$ ：Expected，期望值；
$AA$ ：Actual，实际值；
$DD$ ：Deviation，偏差；
$SS$ ：Severity，严重程度；
$CC$ ：Condition，异常发生条件。

因此，一个异常不能只保存：

异常 = TRUE

而应该保存完整结构：

异常对象
├── 目标对象
├── 异常类型
├── 期望值
├── 实际值
├── 偏差
├── 严重程度
└── 发生条件

只有这样，诊断系统才能根据异常特征寻找原因。

121.5 异常对象的诊断特征

不同异常具有不同特征。

例如数据异常：

$AD={Data,Expected,Actual,Deviation}A_D=\{Data,Expected,Actual,Deviation\}$

状态异常：

$AS={State,ExpectedState,ActualState,Transition}A_S=\{State,ExpectedState,ActualState,Transition\}$

行为异常：

$AB={Behavior,ExpectedBehavior,ActualBehavior,Condition}A_B=\{Behavior,ExpectedBehavior,ActualBehavior,Condition\}$

结果异常：

$AR={Result,ExpectedResult,ActualResult,Deviation}A_R=\{Result,ExpectedResult,ActualResult,Deviation\}$

结构异常：

$ASt={Structure,ExpectedStructure,ActualStructure,Difference}A_{St}=\{Structure,ExpectedStructure,ActualStructure,Difference\}$

这些异常对象都可以进入统一诊断模型。

因此：

$AnomalyObject→DiagnosticFeatureAnomalyObject \rightarrow DiagnosticFeature$

诊断系统不是直接对一个“异常标记”进行处理，而是对异常对象的具体特征进行分析。

121.6 异常原因

121.6.1 异常原因定义

异常原因（Anomaly Cause）是能够直接或间接导致异常对象产生的对象、状态、行为、数据、结构、条件或事件。

可以定义原因对象：

$C={O,S,B,D,St,K,E}C=\{O,S,B,D,St,K,E\}$

其中：

$OO$ ：Object，对象；
$SS$ ：State，状态；
$BB$ ：Behavior，行为；
$DD$ ：Data，数据；
$StSt$ ：Structure，结构；
$KK$ ：Condition，条件；
$EE$ ：Event，事件。

例如：

异常：
设备温度过高

候选原因：
├── 冷却系统关闭
├── 冷却能力下降
├── 环境温度过高
├── 温度传感器错误
└── 设备负载过高

这些都是候选原因。

但是，候选原因并不等于真实原因。

因此：

$CandidateCause≠ConfirmedCauseCandidateCause \neq ConfirmedCause$

机器还必须通过原因匹配进一步判断。

121.7 原因与异常的关系

原因和异常之间可以建立因果关系：

$Ci→AjC_i \rightarrow A_j$

表示原因 $CiC_i$ 可以导致异常 $AjA_j$ 。

例如：

$CoolingOff→TemperatureIncreaseCoolingOff \rightarrow TemperatureIncrease$

进一步：

$TemperatureIncrease→OverheatTemperatureIncrease \rightarrow Overheat$

形成：

$CoolingOff→TemperatureIncrease→OverheatCoolingOff \rightarrow TemperatureIncrease \rightarrow Overheat$

如果机器观察到了：

$OverheatOverheat$

则可以反向寻找：

$Overheat←TemperatureIncrease←CoolingOffOverheat \leftarrow TemperatureIncrease \leftarrow CoolingOff$

这就是诊断过程中的逆向原因搜索。

121.8 原因匹配

121.8.1 原因匹配定义

原因匹配（Cause Matching）是将异常对象的特征与候选原因的特征、条件、关系和历史结果进行比较，以确定候选原因与当前异常之间匹配程度的过程。

定义原因匹配函数：

$M(C,A)=Match(C,A)M(C,A)=Match(C,A)$

其中：

$CC$ ：候选原因；
$AA$ ：异常对象；
$MM$ ：匹配结果。

最简单的匹配结果为：

$M(C,A)∈{0,1}M(C,A)\in\{0,1\}$

其中：

$00$ ：不匹配；
$11$ ：匹配。

但是实际诊断通常需要多个原因之间进行比较，因此可以进一步定义匹配度：

$Score(C,A)=f(F,R,S,T,H)Score(C,A)=f(F,R,S,T,H)$

其中：

$FF$ ：Feature，异常特征匹配；
$RR$ ：Relation，因果关系匹配；
$SS$ ：State，状态条件匹配；
$TT$ ：Time，时间关系匹配；
$HH$ ：History，历史经验匹配。

121.9 原因匹配的核心条件

原因匹配至少需要检查五个方面。

1. 特征匹配

判断原因是否能够解释异常表现。

例如：

$CauseFeature↔AnomalyFeatureCauseFeature \leftrightarrow AnomalyFeature$

如果异常表现与原因特征完全不相关，则匹配度低。

2. 状态匹配

判断原因发生时对象是否处于相关状态。

例如：

冷却系统 = OFF

与：

设备温度持续升高

具有较强状态关系。

3. 条件匹配

判断原因发生条件是否成立。

例如：

$Temperature>80Temperature>80$

只有在相应条件成立时，某些原因才具有意义。

4. 关系匹配

判断原因对象与异常对象之间是否存在已知关系：

$Relation(C,A)=TRUERelation(C,A)=TRUE$

例如：

$CoolingSystem→TemperatureCoolingSystem \rightarrow Temperature$

5. 时间匹配

判断原因是否在异常发生之前或异常形成过程中发生。

例如：

$CoolingOff→5min→TemperatureIncreaseCoolingOff \rightarrow 5min \rightarrow TemperatureIncrease$

时间顺序具有诊断意义。

121.10 原因匹配模型

可以建立统一匹配模型：

$CM=wfF+wrR+wsS+wtT+whHCM= w_fF+ w_rR+ w_sS+ w_tT+ w_hH$

其中：

$CMCM$ ：Cause Match Score，原因匹配分数；
$FF$ ：特征匹配分数；
$RR$ ：关系匹配分数；
$SS$ ：状态匹配分数；
$TT$ ：时间匹配分数；
$HH$ ：历史匹配分数；
$wf,wr,ws,wt,whw_f,w_r,w_s,w_t,w_h$ ：各项权重。

权重满足：

$wf+wr+ws+wt+wh=1w_f+w_r+w_s+w_t+w_h=1$

例如：

$CM(C1,A)=0.85CM(C_1,A)=0.85$ $CM(C2,A)=0.52CM(C_2,A)=0.52$ $CM(C3,A)=0.21CM(C_3,A)=0.21$

则：

$C1>C2>C3C_1>C_2>C_3$

可以将 $C1C_1$ 排在最高优先级。

需要注意：

匹配度最高不等于绝对真实原因。

它表示当前结构、规则和证据条件下， $C1C_1$ 是最符合当前异常的候选原因。

121.11 原因匹配与概率

在具有多个候选原因的情况下，可以进一步使用概率表示原因可信程度：

$P(Ci∣A)P(C_i|A)$

表示：

已知异常 $AA$ 发生时，原因 $CiC_i$ 的条件概率。

根据贝叶斯关系：

$P(Ci∣A)=P(A∣Ci)P(Ci)P(A)P(C_i|A)= \frac{P(A|C_i)P(C_i)} {P(A)}$

其中：

$P(Ci∣A)P(C_i|A)$ ：观察到异常后的原因概率；
$P(A∣Ci)P(A|C_i)$ ：原因发生时产生该异常的概率；
$P(Ci)P(C_i)$ ：原因的先验概率；
$P(A)P(A)$ ：异常发生的总体概率。

这样，WSaiOS可以同时使用：

规则匹配 + 结构匹配 + 条件匹配 + 概率计算

形成更加完整的诊断机制。

这仍然属于符号逻辑、规则计算和概率计算，而不是神经网络推理。

121.12 单一原因诊断

如果一个异常只对应一个明确原因：

$A←CA \leftarrow C$

则：

$Diagnosis(A)=CDiagnosis(A)=C$

例如：

异常：
数据库连接失败

检测：
数据库服务 = OFF

如果规则明确规定：

$DatabaseService=OFF→ConnectionFailureDatabaseService=OFF \rightarrow ConnectionFailure$

则可以直接得到：

$Cause=DatabaseServiceOffCause=DatabaseServiceOff$

这是直接诊断。

121.13 多原因诊断

现实对象通常存在多个可能原因：

$A←{C1,C2,C3,…,Cn}A \leftarrow \{C_1,C_2,C_3,\ldots,C_n\}$

此时不能简单选择第一个原因。

必须进行：

候选原因生成 → 原因匹配 → 匹配评分 → 原因排序 → 诊断选择

即：

$A→Candidates→Match→Score→Rank→DiagnosisA \rightarrow Candidates \rightarrow Match \rightarrow Score \rightarrow Rank \rightarrow Diagnosis$

例如：

异常：设备温度过高

C1：冷却系统关闭
C2：环境温度过高
C3：设备负载过高
C4：传感器异常

机器计算：

$Score(C1,A)=0.91Score(C_1,A)=0.91$ $Score(C2,A)=0.63Score(C_2,A)=0.63$ $Score(C3,A)=0.78Score(C_3,A)=0.78$ $Score(C4,A)=0.35Score(C_4,A)=0.35$

于是形成：

$C1>C3>C2>C4C_1>C_3>C_2>C_4$

诊断系统可以把 $C1C_1$ 作为当前首要诊断原因，同时保留其他候选原因。

121.14 多重原因诊断

某些异常不是单一原因产生，而是多个条件共同产生：

$C1∧C2→AC_1\land C_2\rightarrow A$

例如：

$HighLoad∧CoolingOff→OverheatHighLoad \land CoolingOff \rightarrow Overheat$

这意味着：

单独高负载可能不会造成严重异常；
单独关闭冷却系统也可能不会立即造成严重异常；
两者同时成立时才形成严重过热。

因此，诊断系统必须支持：

$ANDAND$

关系。

同时，也需要支持：

$OROR$

关系：

$C1∨C2→AC_1\lor C_2\rightarrow A$

表示多个原因中的任意一个都可能导致异常。

因此原因结构至少包括：

单原因、AND多原因、OR多原因、链式原因、间接原因。

121.15 原因链

异常可能不是由一个直接原因产生，而是经过多个中间状态逐步形成。

例如：

$C1→S1→B1→R1→AC_1 \rightarrow S_1 \rightarrow B_1 \rightarrow R_1 \rightarrow A$

具体可以表示：

冷却系统关闭 → 温度上升 → 设备进入高温状态 → 工作效率下降 → 结果异常

因此诊断系统不仅要寻找直接原因，还需要寻找原因链。

定义：

$CauseChain={C1,C2,…,Cn,A}CauseChain=\{C_1,C_2,\ldots,C_n,A\}$

并检查：

$C1→C2→⋯→AC_1\rightarrow C_2\rightarrow\cdots\rightarrow A$

如果链条中的每个关系均成立，则可以形成完整诊断路径。

121.16 诊断结果

121.16.1 诊断结果定义

诊断结果（Diagnosis Result）是机器根据异常对象、候选原因和原因匹配结果形成的结构化判断结果。

可以定义：

$DR={A,C,S,E,P,R}DR=\{A,C,S,E,P,R\}$

其中：

$AA$ ：异常对象；
$CC$ ：诊断原因；
$SS$ ：原因匹配分数；
$EE$ ：Evidence，诊断证据；
$PP$ ：Probability，原因概率；
$RR$ ：Result，最终诊断状态。

诊断结果不能只表示：

原因 = X

而应该保存：

异常对象
↓
候选原因
↓
匹配条件
↓
匹配分数
↓
诊断原因
↓
诊断可信程度
↓
诊断状态

121.17 诊断状态

诊断结果可以划分为：

UNKNOWN
POSSIBLE
LIKELY
CONFIRMED
REJECTED

其中：

UNKNOWN：无法确定；
POSSIBLE：存在可能；
LIKELY：高度可能；
CONFIRMED：已经确认；
REJECTED：候选原因被排除。

这样可以避免机器在证据不足时强行生成确定结论。

例如：

$Score(C,A)<T1Score(C,A)<T_1$

则：

$UNKNOWNUNKNOWN$

如果：

$T1≤Score(C,A)<T2T_1\leq Score(C,A)<T_2$

则：

$POSSIBLEPOSSIBLE$

如果：

$T2≤Score(C,A)<T3T_2\leq Score(C,A)<T_3$

则：

$LIKELYLIKELY$

只有当存在足够规则、证据或验证结果时，才能进入：

$CONFIRMEDCONFIRMED$

121.18 诊断验证

诊断不能停留在原因匹配阶段。

如果机器认为：

$C→AC\rightarrow A$

则应该进一步验证：

$Test(C)→ResultTest(C)\rightarrow Result$

例如机器判断：

冷却系统关闭

是设备过热的原因。

恢复冷却系统后：

$Temperature↓Temperature\downarrow$

并且：

$Overheat→NormalOverheat\rightarrow Normal$

那么该原因获得更强的验证支持。

因此：

$Diagnosis→Treatment/Test→Observation→VerificationDiagnosis \rightarrow Treatment/Test \rightarrow Observation \rightarrow Verification$

诊断结果可以因此从：

$LIKELY→CONFIRMEDLIKELY \rightarrow CONFIRMED$

或者：

$LIKELY→REJECTEDLIKELY \rightarrow REJECTED$

这使诊断形成可验证的机器认知过程。

121.19 诊断对象工程模型

在PHP OOP中，可以建立 Diagnosis 对象：

class Diagnosis
{
    public $diagnosisId;
    public $anomalyId;
    public $targetObject;
    public $candidateCauses;
    public $selectedCause;
    public $matchScore;
    public $evidence;
    public $probability;
    public $status;
    public $verification;
    public $createdAt;
}

候选原因可以定义为：

class Cause
{
    public $causeId;
    public $causeType;
    public $object;
    public $condition;
    public $state;
    public $behavior;
    public $relation;
    public $rule;
}

原因匹配器：

class CauseMatcher
{
    public function match($anomaly, $cause)
    {
        $score = 0;

        if ($this->matchFeature($anomaly, $cause)) {
            $score += 0.30;
        }

        if ($this->matchRelation($anomaly, $cause)) {
            $score += 0.25;
        }

        if ($this->matchState($anomaly, $cause)) {
            $score += 0.20;
        }

        if ($this->matchCondition($anomaly, $cause)) {
            $score += 0.15;
        }

        if ($this->matchHistory($anomaly, $cause)) {
            $score += 0.10;
        }

        return $score;
    }
}

该结构体现了WSaiOS的核心思想：

异常是结构化对象，原因也是结构化对象，诊断就是两个对象之间的规则匹配和计算。

121.20 诊断系统工程模块

WSaiOS可以建立独立的诊断模块：

Diagnosis System
│
├── AnomalyReceiver
├── AnomalyAnalyzer
├── CauseRepository
├── CauseGenerator
├── CauseMatcher
├── CauseScorer
├── CauseRanker
├── DiagnosisEngine
├── DiagnosisVerifier
└── DiagnosisStore

运行过程：

异常接收 → 异常分析 → 原因生成 → 原因匹配 → 原因评分 → 原因排序 → 诊断 → 验证 → 保存

其中：

AnomalyReceiver 接收异常对象；

AnomalyAnalyzer 提取异常特征；

CauseRepository 提供候选原因；

CauseGenerator 根据异常特征生成候选原因；

CauseMatcher 进行原因匹配；

CauseScorer 计算匹配分数；

CauseRanker 对候选原因进行排序；

DiagnosisEngine 生成诊断结果；

DiagnosisVerifier 验证诊断结果；

DiagnosisStore 保存诊断记录。

121.21 诊断规则

可以建立基础诊断规则：

规则1：

IF AnomalyDetected = TRUE
THEN GenerateCandidateCauses

规则2：

IF CauseRelationExists = TRUE
THEN CalculateCauseMatch

规则3：

IF CauseConditionSatisfied = TRUE
THEN IncreaseCauseScore

规则4：

IF CauseScore >= DiagnosisThreshold
THEN CreateDiagnosis

规则5：

IF VerificationSuccess = TRUE
THEN DiagnosisStatus = CONFIRMED

规则6：

IF VerificationFailed = TRUE
THEN DiagnosisStatus = REJECTED

由此形成：

$Anomaly→Cause→Match→Score→Diagnosis→VerificationAnomaly \rightarrow Cause \rightarrow Match \rightarrow Score \rightarrow Diagnosis \rightarrow Verification$

121.22 诊断状态机

诊断过程可以建立独立状态机：

$Detected→Analyzing→CandidateGenerated→Matching→Ranked→Diagnosed→Verifying→ConfirmedDetected \rightarrow Analyzing \rightarrow CandidateGenerated \rightarrow Matching \rightarrow Ranked \rightarrow Diagnosed \rightarrow Verifying \rightarrow Confirmed$

如果没有找到有效原因：

$Matching→UnknownMatching \rightarrow Unknown$

如果诊断验证失败：

$Verifying→Rejected→AnalyzingVerifying \rightarrow Rejected \rightarrow Analyzing$

如果存在多个高匹配原因：

$Ranked→MultipleCandidates→FurtherDiagnosisRanked \rightarrow MultipleCandidates \rightarrow FurtherDiagnosis$

这样诊断系统能够持续修正，而不是一次判断后永久结束。

121.23 诊断闭环

诊断最终应该进入机器认知闭环：

$Observation→Detection→Anomaly→Diagnosis→Cause→Decision→Action→Result→VerificationObservation \rightarrow Detection \rightarrow Anomaly \rightarrow Diagnosis \rightarrow Cause \rightarrow Decision \rightarrow Action \rightarrow Result \rightarrow Verification$

其中：

异常检测解决“发生了什么”；

诊断解决“为什么发生”；

决策解决“应该怎么办”；

行为解决“实际做什么”；

结果验证解决“诊断是否正确”。

因此可以形成：

$异常→原因→诊断→验证\boxed{ 异常 \rightarrow 原因 \rightarrow 诊断 \rightarrow 验证 }$

诊断不是机器认知的终点，而是从“异常认知”进入“原因认知”的关键桥梁。

121.24 诊断理论的核心模型

综合本章内容，可以建立完整诊断模型：

$A={O,T,E,A,D,S,C}A=\{O,T,E,A,D,S,C\}$

首先得到异常对象 $AA$ 。

然后生成候选原因：

$C={C1,C2,…,Cn}C=\{C_1,C_2,\ldots,C_n\}$

对每个候选原因进行匹配：

$Mi=Match(Ci,A)M_i=Match(C_i,A)$

计算原因分数：

$Scorei=f(Mi)Score_i=f(M_i)$

进行排序：

$C(1)>C(2)>⋯>C(n)C_{(1)}>C_{(2)}>\cdots>C_{(n)}$

选择当前最佳诊断：

$C∗=argmaxCiScore(Ci,A)C^*=argmax_{C_i}Score(C_i,A)$

最终形成：

$Diagnosis(A)=C*Diagnosis(A)=C^*$

如果经过验证：

$Verify(C*,A)=TRUEVerify(C^*,A)=TRUE$

则：

$DiagnosisStatus=CONFIRMEDDiagnosisStatus=CONFIRMED$

否则：

$DiagnosisStatus=REJECTEDDiagnosisStatus=REJECTED$

或者返回重新诊断：

$Diagnosis→ReanalysisDiagnosis \rightarrow Reanalysis$

121.25 本章总结

诊断理论建立在异常检测理论之上。

第120章回答：

$哪里异常？\boxed{哪里异常？}$

第121章进一步回答：

$为什么异常？\boxed{为什么异常？}$

本章建立了五个核心概念：

第一，诊断定义。

诊断是根据异常对象寻找异常原因，并通过原因匹配、排序和验证形成诊断结果的过程。

第二，异常对象。

异常必须被结构化表示：

$AO={Object,Type,Expected,Actual,Deviation,Severity,Condition}AO=\{Object,Type,Expected,Actual,Deviation,Severity,Condition\}$

第三，异常原因。

原因是能够直接或间接导致异常的对象、状态、行为、数据、结构、条件或事件。

第四，原因匹配。

机器通过特征、关系、状态、条件、时间和历史等信息计算候选原因与异常之间的匹配程度：

$Score(C,A)=f(F,R,S,T,H)Score(C,A)=f(F,R,S,T,H)$

第五，诊断结果。

诊断结果不是简单的“原因=某个对象”，而是：

$Diagnosis={Anomaly,Cause,Score,Evidence,Probability,Status}Diagnosis= \{ Anomaly, Cause, Score, Evidence, Probability, Status \}$

最终形成完整诊断流程：

$异常检测→异常对象→候选原因→原因匹配→原因排序→诊断结果→诊断验证\boxed{ 异常检测 \rightarrow 异常对象 \rightarrow 候选原因 \rightarrow 原因匹配 \rightarrow 原因排序 \rightarrow 诊断结果 \rightarrow 诊断验证 }$

从工程角度看，诊断理论进一步把WSaiOS的机器认知能力从异常发现推进到原因识别。

机器由此开始形成一种更加完整的认知结构：

$实际对象→异常→原因→诊断→验证\boxed{ 实际对象 \rightarrow 异常 \rightarrow 原因 \rightarrow 诊断 \rightarrow 验证 }$

这为后续的故障处理、原因消除、恢复控制以及诊断反馈建立了理论和工程基础。

第121章 诊断理论

第121章 诊断理论

121.1 提出背景

121.2 诊断定义

121.3 诊断与异常检测的区别

121.4 异常对象

121.4.1 异常对象定义

121.5 异常对象的诊断特征

121.6 异常原因

121.6.1 异常原因定义

121.7 原因与异常的关系

121.8 原因匹配

121.8.1 原因匹配定义

121.9 原因匹配的核心条件

1. 特征匹配

2. 状态匹配

3. 条件匹配

4. 关系匹配

5. 时间匹配

121.10 原因匹配模型

121.11 原因匹配与概率

121.12 单一原因诊断

121.13 多原因诊断

121.14 多重原因诊断

121.15 原因链

121.16 诊断结果

121.16.1 诊断结果定义

121.17 诊断状态

121.18 诊断验证

121.19 诊断对象工程模型

121.20 诊断系统工程模块

121.21 诊断规则

121.22 诊断状态机

121.23 诊断闭环

121.24 诊断理论的核心模型

121.25 本章总结