首页 理论 架构 工程 文档 白皮书 著作 研究 案例 下载 博客 关于 开始使用 →
首页 › 第二十四篇　Self Maintenance› 第74章　Diagnosis

第74章　Diagnosis

📅 2026年09月12日 👤 东塬一老翁 📂 第二十四篇　Self Maintenance

第二十四篇 Self-Maintenance

第74章　Diagnosis

第72章 Detection 解决的是：

有没有异常？

第73章 Risk 与 Conflict 解决的是：

可能有什么风险？
有没有冲突？
哪个问题应该优先处理？

第74章 Diagnosis 则进一步解决：

问题在哪里？
问题是什么？
为什么发生？
影响了什么？
依赖链中哪一个环节出现问题？

因此，自我维护过程进一步形成：

Detection
   ↓
Risk / Conflict
   ↓
Diagnosis
   ↓
Decision
   ↓
Repair
   ↓
Verification

Diagnosis 不直接执行修复，而是为后面的 Repair 提供问题定位和原因依据。

1. Diagnosis

1.1 Diagnosis 定义

Diagnosis（诊断）是 SAI/ICAI 根据 Detection Result、Risk、Conflict、状态、依赖、历史记录、行为结果和相关事实，对异常进行定位、分析原因、判断影响范围并形成结构化诊断结果的机制。

核心关系：

DetectionResult
      ↓
Diagnosis
      ↓
Problem
      ↓
Cause
      ↓
Impact
      ↓
DiagnosisResult

例如：

Detection：

Motor_A.temperature = 95℃
状态 = ABNORMAL

Diagnosis 不应该直接写：

Motor_A 已损坏

因为检测结果只能证明：

temperature > allowed_max

诊断需要继续检查：

温度异常
 ↓
读取 Motor_A 状态
 ↓
读取运行时间
 ↓
读取负载
 ↓
检查 CoolingSystem
 ↓
检查 Sensor
 ↓
检查历史经验
 ↓
形成原因判断

最终可能得到：

Diagnosis:
CoolingSystem unavailable

或者：

Diagnosis:
High load caused temperature increase

因此：

Detection = 发现
Diagnosis = 定位与原因分析

2. 问题定位

Diagnosis 的第一步是Problem Localization（问题定位）。

Detection 可能只发现：

System = ABNORMAL

但这个结果范围太大。

Diagnosis 需要逐层缩小范围：

System
 ↓
Module
 ↓
Object
 ↓
Property
 ↓
State
 ↓
Behavior
 ↓
Action
 ↓
具体问题

例如：

System
 ↓
Device Module
 ↓
Motor_A
 ↓
Temperature
 ↓
95℃

最终定位：

Problem Target = Motor_A.temperature

2.1 问题定位结构

ProblemLocation
{
    system
    module
    object
    property
    state
    behavior
    action
    location
}

例如：

ProblemLocation
{
    system: "FactorySystem",
    module: "DeviceModule",
    object: "Motor_A",
    property: "temperature",
    state: "ABNORMAL",
    behavior: "RUNNING",
    action: "ROTATE"
}

2.2 定位过程

DetectionResult
      ↓
Target Identification
      ↓
Module Check
      ↓
Object Check
      ↓
Property Check
      ↓
State Check
      ↓
Behavior Check
      ↓
Problem Location

定位的目标是：

从“系统异常”
缩小到
“哪个对象”
再缩小到
“哪个属性/状态/行为”

2.3 问题定位不能等于原因

例如：

Motor_A.temperature = 95℃

可以定位：

Problem:
Motor_A.temperature abnormal

但是：

Cause:
Cooling failure

还不能仅凭这一条信息确认。

因此：

Problem Location ≠ Root Cause

3. 原因分析

完成问题定位后，Diagnosis 进入 Cause Analysis（原因分析）。

核心问题：

为什么出现这个问题？

3.1 原因来源

原因分析可以使用：

Fact
State
Rule
Relation
Behavior
Action
Feedback
Experience
Memory
Dependency
History

形成：

Problem
 ↓
Related Information
 ↓
Comparison
 ↓
Cause Candidates
 ↓
Cause Evaluation
 ↓
Possible Cause

3.2 原因候选

例如：

Problem:
Motor_A.temperature = 95℃

可能存在：

Cause_A:
Motor load too high

Cause_B:
Cooling system unavailable

Cause_C:
Temperature sensor error

Cause_D:
Motor running time too long

Diagnosis 不应该立即选择一个原因。

先形成：

CauseCandidate
{
    id
    problem
    cause
    evidence
    relation
    score
    state
}

例如：

CauseCandidate
{
    id: "CC001",
    problem: "Motor_A.temperature",
    cause: "CoolingSystem unavailable",
    evidence: [
        "CoolingSystem.state = ERROR",
        "Motor_A.temperature > 80"
    ],
    score: 0.90,
    state: "SUPPORTED"
}

3.3 原因与结果

需要区分：

Cause → Problem

例如：

CoolingSystem ERROR
        ↓
Cooling unavailable
        ↓
Motor temperature increases
        ↓
Motor temperature = 95℃

诊断就是在建立这种因果路径。

Cause
 ↓
Intermediate State
 ↓
Problem

3.4 根因与直接原因

可以区分：

Direct Cause
Root Cause

例如：

Sensor_A ERROR
      ↓
Temperature value abnormal
      ↓
Detection reports overheating

直接原因可能是：

Temperature value abnormal

更深层原因可能是：

Sensor_A communication failure

所以 Diagnosis 可以继续向依赖链追踪：

Problem
 ↓
Direct Cause
 ↓
Related Cause
 ↓
Root Cause Candidate

4. 状态分析

Diagnosis 必须分析问题发生前后的状态。

因为很多异常并不是孤立出现的，而是由状态变化产生。

基本模型：

Previous State
      ↓
State Change
      ↓
Current State
      ↓
Abnormal State

例如：

Motor_A

READY
 ↓
RUNNING
 ↓
temperature = 65℃
 ↓
temperature = 95℃
 ↓
ERROR

Diagnosis 可以发现：

正常状态
→ 高温状态
→ 错误状态

4.1 状态分析结构

StateAnalysis
{
    object
    previous_state
    current_state
    expected_state
    state_changes
    abnormal_state
    duration
    related_events
}

例如：

StateAnalysis
{
    object: "Motor_A",

    previous_state: "RUNNING",
    current_state: "ERROR",

    expected_state: "RUNNING",

    state_changes: [
        "temperature_high",
        "overheat",
        "error"
    ],

    abnormal_state: "ERROR",

    duration: 35
}

4.2 状态序列

Diagnosis 可以检查状态顺序：

READY
 ↓
RUNNING
 ↓
OVERHEAT
 ↓
ERROR

如果系统规定：

READY → RUNNING → STOPPED

却出现：

READY → ERROR

则可以形成：

Unexpected State Transition

状态分析因此不仅检查：

Current State

还检查：

State History

4.3 状态与原因

例如：

Motor_A
RUNNING
 ↓
temperature 95℃
 ↓
ERROR

Diagnosis 可以将：

Temperature abnormal

与：

ERROR

建立关系：

temperature_high
      ↓
overheat
      ↓
ERROR

形成诊断链。

5. 依赖分析

现代 SAI/ICAI 系统由多个模块、对象和设备组成，因此一个异常可能不是自身产生，而是依赖对象产生。

这就需要 Dependency Analysis（依赖分析）。

5.1 依赖关系

例如：

LearningEngine
      ↓
Memory
      ↓
Storage

如果：

Storage = ERROR

那么可能出现：

Memory = UNAVAILABLE

进一步：

LearningEngine = PARTIAL

因此：

表面问题
LearningEngine异常

可能根因
Storage异常

5.2 Dependency Graph

可以建立：

Dependency Graph

LearningEngine
      │
      ↓
   Memory
      │
      ↓
   Storage

设备系统也可以：

Motor
  │
  ├── Controller
  │
  ├── Power
  │
  ├── Sensor
  │
  └── Cooling

如果 Motor 出现：

OVERHEAT

Diagnosis 可以检查：

Cooling
Sensor
Power
Controller
Load

5.3 DependencyAnalysis

结构：

DependencyAnalysis
{
    target
    dependency
    dependency_type
    dependency_state
    relation
    impact
    state
}

例如：

DependencyAnalysis
{
    target: "Motor_A",

    dependency: "Cooling_A",

    dependency_type: "REQUIRED",

    dependency_state: "ERROR",

    relation: "depends_on",

    impact: "HIGH",

    state: "ABNORMAL"
}

5.4 依赖链诊断

完整过程：

Problem
 ↓
Check Direct Dependency
 ↓
Dependency State
 ↓
Check Dependency's Dependency
 ↓
Continue
 ↓
Root Cause Candidate

例如：

LearningEngine
 ↓
Memory
 ↓
Storage
 ↓
Disk

如果：

Disk = FULL

可能形成：

Disk FULL
 ↓
Storage WRITE FAILED
 ↓
Memory UPDATE FAILED
 ↓
LearningEngine UPDATE FAILED

这就是典型的依赖链。

6. Diagnosis Result

Diagnosis 最终需要形成结构化的 Diagnosis Result。

6.1 DiagnosisResult

DiagnosisResult
{
    id

    detection_id
    target

    problem
    location

    state_analysis

    causes
    dependencies

    impact
    risk

    conclusion
    confidence

    state

    created_at
    updated_at
}

例如：

DiagnosisResult
{
    id: "DR001",

    detection_id: "D001",

    target: "Motor_A",

    problem: {
        property: "temperature",
        value: 95
    },

    location: {
        module: "DeviceModule",
        object: "Motor_A",
        property: "temperature"
    },

    state_analysis: {
        previous: "RUNNING",
        current: "ERROR"
    },

    causes: [
        {
            cause: "Cooling_A unavailable",
            score: 0.90
        }
    ],

    dependencies: [
        {
            object: "Cooling_A",
            state: "ERROR"
        }
    ],

    impact: "Motor may stop",

    risk: "CRITICAL",

    conclusion: "Cooling_A failure is primary cause candidate",

    confidence: 0.90,

    state: "SUPPORTED"
}

6.2 Diagnosis 状态

可以定义：

NEW
ANALYZING
LOCATED
SUPPORTED
CONFIRMED
UNCERTAIN
CONFLICT
UNRESOLVED
FAILED

其中：

LOCATED

表示已经找到问题位置。

SUPPORTED

表示原因存在充分支持证据，但仍可能需要进一步验证。

CONFIRMED

表示原因已经通过系统规定的确认条件。

UNCERTAIN

表示存在多个可能原因，但无法确定。

CONFLICT

表示不同诊断证据互相矛盾。

UNRESOLVED

表示当前无法完成诊断。

Diagnosis 完整案例

继续使用前面 Motor_A 的案例。

当前：

Motor_A.temperature = 95℃

第一步：Detection

DetectionResult

target = Motor_A
property = temperature

expected = <= 80
actual = 95

state = ABNORMAL

第二步：Risk

Risk

event = motor_overheat
probability = 0.90
impact = 0.90

RiskScore = 0.81

level = CRITICAL

第三步：问题定位

检查：

System
 ↓
DeviceModule
 ↓
Motor_A
 ↓
temperature

得到：

ProblemLocation = Motor_A.temperature

第四步：状态分析

历史状态：

READY
 ↓
RUNNING
 ↓
temperature_high
 ↓
ERROR

得到：

Current State = ERROR
Previous State = RUNNING

第五步：原因候选

检查：

Load
Cooling
Sensor
Power
Controller

发现：

Cooling_A.state = ERROR

同时：

Motor_A.temperature = 95℃

建立：

Cooling_A ERROR
       ↓
Cooling unavailable
       ↓
Motor_A temperature increases
       ↓
Motor_A ERROR

第六步：依赖分析

发现：

Motor_A
   ↓ depends_on
Cooling_A

而：

Cooling_A = ERROR

因此：

Dependency Impact = HIGH

第七步：Diagnosis Result

最终：

DiagnosisResult

Problem:
Motor_A.temperature abnormal

Location:
Motor_A.temperature

Current State:
ERROR

Primary Cause Candidate:
Cooling_A ERROR

Dependency:
Motor_A → Cooling_A

Risk:
CRITICAL

State:
SUPPORTED

此时系统还没有执行修复。

下一步应该进入：

DiagnosisResult
       ↓
Decision
       ↓
Repair

如果修复完成：

Repair
 ↓
Verification
 ↓
Detection

重新检测：

Motor_A.temperature = 65℃
Motor_A.state = RUNNING

才可以确认：

Repair = SUCCESS

Detection、Risk、Conflict、Diagnosis 的完整关系

到第74章为止，自我维护链条已经非常清晰：

Detection
    ↓
发现异常
    ↓
Risk
    ↓
判断潜在影响
    ↓
Conflict
    ↓
判断是否存在矛盾
    ↓
Priority
    ↓
确定处理优先级
    ↓
Diagnosis
    ↓
定位问题、分析原因
    ↓
Decision
    ↓
选择处理方案
    ↓
Repair
    ↓
执行修复
    ↓
Verification
    ↓
重新检测

其中 Diagnosis 位于：

发现问题
     ↓
理解问题
     ↓
解决问题

中的理解问题阶段。

本章核心模型

DetectionResult
      ↓
Problem Localization
      ↓
State Analysis
      ↓
Cause Analysis
      ↓
Dependency Analysis
      ↓
Cause Evaluation
      ↓
DiagnosisResult

完整自我维护闭环：

Detection
   ↓
Risk
   ↓
Conflict
   ↓
Priority
   ↓
Diagnosis
   ↓
Decision
   ↓
Repair
   ↓
Verification
   ↓
Detection

本章核心定义

Diagnosis 是 SAI/ICAI 在检测发现异常之后，通过问题定位、状态分析、原因分析和依赖分析，对异常发生的位置、原因、影响和相关依赖进行结构化判断，并形成可供 Decision 与 Repair 使用的 Diagnosis Result 的机制。

核心关系：

Detection = 哪里异常？
Risk = 可能造成什么？
Conflict = 什么发生了矛盾？
Diagnosis = 为什么异常？
Decision = 应该怎么办？
Repair = 执行什么修复？
Verification = 修复是否成功？

最终形成：

Detection
   ↓
Risk / Conflict
   ↓
Diagnosis
   ↓
Decision
   ↓
Repair
   ↓
Verification

这使 Diagnosis 成为 ICAI 自我维护体系中从“发现问题”进入“解决问题”的关键桥梁。

← 第二十四篇 Self-Maintenance
第75章　Repair 与 Verification →

Leave a Reply

Your email address will not be published. Required fields are marked *