# D-InSAR 增强 Task 文档

更新日期：2026-03-13

## 1. 文档目的

这份文档用于统一管理本轮 D-InSAR 系统重构任务，覆盖以下两大方向：

- D-InSAR 多引擎生产系统增强
- D-InSAR 结果管理系统增强

文档定位是“任务总表 + 实施边界 + 验收口径”，用于后续分阶段实施、联调和运维验收。

## 2. 背景

当前系统的 D-InSAR 生产能力主要绑定在 ENVI + SARscape 链路上，前端、后端任务模型、运行监控和结果入库都默认只有一个处理引擎。这会带来两个直接问题：

- 客户如果没有 ENVI/SARscape license，D-InSAR 核心生产能力会直接失效。
- 后续接入 ISCE2、LANDSAR 时，只能继续堆在现有 IDL/ENVI 语义上，导致架构持续恶化。

同时，当前 D-InSAR 结果管理能力偏轻，更多是“结果浏览 + 缓存管理”，还不足以支撑多引擎、多版本、多产物、多轮生产的正式管理需求。

## 3. 本轮目标

### 3.1 生产系统目标

- 将 D-InSAR 生产系统升级为“多引擎生产中心”
- 正式支持两类可执行引擎：
  - `sarscape`：ENVI + SARscape
  - `isce2`：WSL 内部署的 ISCE2
- 预留第三类引擎：
  - `landsar`：仅保留接口和前端占位，不实现算法
- 将运维自检升级为“系统级 + D-InSAR 专项级”双层检查

### 3.2 结果管理目标

- 将 D-InSAR 结果从“单文件记录”升级为“可追踪、可治理、可比对”的结果资产
- 支持来源追踪、版本管理、多产物管理、审核状态和运维治理
- 让结果管理适配多引擎场景，而不是继续依赖单一文件命名和单一路径假设

## 4. 范围与非范围

### 4.1 本轮范围

- 多引擎 D-InSAR 后端抽象层
- 新 D-InSAR 生产中心前端架构
- ENVI/SARscape 的兼容接入
- ISCE2 的 WSL 环境校验与运行接口
- 运维自检与 D-InSAR 专项健康检查
- D-InSAR 结果管理增强

### 4.2 明确不在本轮范围

- LANDSAR 算法实现
- 对现有配对算法本身做大幅重写
- 对 AI 诊断能力做独立重构
- 一次性替换全部旧接口

## 5. 现状要点

### 5.1 ENVI 现有处理模式

当前 ENVI 侧应明确建模为 `sarscape` 引擎下的两种 profile：

- `metatask`
- `custom6`

其中 `custom6` 的 6 步链路为：

1. Interferogram Generation
2. Filtering and Coherence
3. Orbital Trend Removal
4. Phase Unwrapping
5. GCP Generation + Refinement
6. Phase to Displacement + Geocoding

### 5.2 ISCE2 的特殊约束

ISCE2 不走本机 Windows 直接执行链路，默认按 WSL 方式部署与运行，因此必须把 WSL 环境校验设计成正式能力，而不是上线前人工检查事项。

### 5.3 当前结果管理主要短板

- 结果记录字段偏少，缺少引擎来源、运行来源、版本、产物类型等核心字段
- 结果入库逻辑仍偏向单文件扫描，不适合多引擎多版本
- 前端结果面板偏重展示，缺少治理、比对、版本和来源追踪能力
- 运维自检尚未覆盖结果资产层面的异常

## 6. Task 总览

| Task ID | 主题 | 目标 |
|---|---|---|
| T1 | 多引擎生产基座 | 建立统一的 D-InSAR 引擎抽象、调度和兼容层 |
| T2 | 前端生产中心 | 将现有 IDL 自动化面板升级为多引擎生产中心 |
| T3 | SARSCAPE 兼容接入 | 将现有 ENVI 链路适配到新抽象层 |
| T4 | ISCE2 + WSL 接入 | 建立 ISCE2 的 WSL 检查、运行和日志链路 |
| T5 | 运维自检增强 | 增加多引擎专项健康检查和自愈入口 |
| T6 | 结果管理增强 | 将 D-InSAR 结果升级为正式结果资产管理体系 |

## 7. 任务拆分

### T1. 多引擎生产基座

#### 目标

- 将 D-InSAR 生产从 `IDL/ENVI 单引擎假设` 中抽离
- 为 `sarscape`、`isce2`、`landsar` 建立统一抽象

#### 关键任务

- 定义统一引擎接口
- 建立引擎注册表
- 建立统一运行记录模型
- 建立统一产物收集与入库接口
- 保留旧 `/idl/...` 路由兼容转发能力

#### 目标结构

- `dinsar_engines/base.py`
- `dinsar_engines/registry.py`
- `dinsar_engines/sarscape_engine.py`
- `dinsar_engines/isce2_engine.py`
- `dinsar_engines/landsar_engine.py`
- `dinsar_orchestrator.py`

#### 验收标准

- 新生产调度层可按 `engine_code` 分发
- `sarscape`、`isce2`、`landsar` 均可在注册表中查询到
- 旧 ENVI 生产功能不回归

### T2. 前端生产中心

#### 目标

- 用统一生产中心替代当前单引擎 `IDLAutomationPanel`
- 支持多引擎选择、运行监控、日志查看和结果入库操作

#### 前端信息架构

- 引擎状态区
  - SARSCAPE
  - ISCE2
  - LANDSAR
- 生产提交区
  - 批次选择
  - 引擎选择
  - profile 选择
  - 输入/输出目录
  - 参数模板
- 运行监控区
  - 当前任务
  - 步骤进度
  - 运行日志
  - 历史记录
- 产物处理区
  - 提取
  - 入库
  - 重扫
  - 缓存重建

#### 关键任务

- 新建 `DinsarProductionPanel`
- 废弃前端对 `/idl/...` 语义的直接依赖
- 增加引擎状态卡和 WSL 状态卡
- 运行记录中展示 `engine`、`profile`、`run_id`

#### 验收标准

- 前端可以清晰区分三类引擎状态
- `landsar` 显示为预留，不可执行
- 当 ENVI 不可用但 ISCE2 可用时，页面仍可提交 ISCE2 任务

### T3. SARSCAPE 兼容接入

#### 目标

- 将现有 ENVI 链路正式纳入新生产体系
- 明确 `metatask` 与 `custom6` 是同一引擎下的两个 profile

#### 关键任务

- 封装现有 ENVI 运行逻辑为 `sarscape_engine`
- 将 `metatask` 和 `custom6` 暴露为 profile
- 保留进度文件、日志、超时监控和历史运行能力

#### 验收标准

- 旧 ENVI 作业仍可执行
- 新系统中可选择 `sarscape/metatask` 与 `sarscape/custom6`
- 原有任务状态、日志和结果提取行为保持兼容

### T4. ISCE2 + WSL 接入

#### 目标

- 建立 ISCE2 运行的正式环境检查、任务执行和输出接入能力

#### WSL 环境校验任务

- 检查 WSL 是否安装
- 检查是否支持 WSL2
- 检查目标 distro 是否存在
- 检查目标 distro 是否可启动
- 检查 `bash -lc` 是否可执行
- 检查 Python 是否可执行
- 检查 ISCE2 是否可 import
- 检查目标入口命令是否可执行
- 检查 DEM 路径在 WSL 内是否可读
- 检查轨道目录在 WSL 内是否可读
- 检查输出目录在 WSL 内是否可写
- 检查 Windows 路径到 WSL 路径转换是否正确
- 增加可选 smoke test

#### 建议配置项

- `ISCE2_ENABLED`
- `ISCE2_WSL_DISTRO`
- `ISCE2_PYTHON`
- `ISCE2_PROFILE`
- `ISCE2_DEM_PATH`
- `ISCE2_ORBIT_DIR`
- `ISCE2_WORK_ROOT`
- `ISCE2_OUTPUT_ROOT`
- `ISCE2_SMOKE_TEST_ENABLED`

#### 关键任务

- 新建 `wsl_service.py`
- 新建 `isce2_engine.py`
- 建立 WSL 执行和日志封装
- 将 ISCE2 输出纳入统一结果收集和入库流程

#### 验收标准

- 前端可见 ISCE2 环境状态
- WSL 校验结果可解释、可定位故障点
- ISCE2 至少有一个正式 profile 可提交并跑通

### T5. 运维自检增强

#### 目标

- 将当前“系统健康检查”升级为“系统级 + D-InSAR 专项级”双层运维自检

#### 关键任务

- 保留现有 `/health` 简版接口
- 增加管理员详细健康接口
- 增加多引擎专项检查
- 增加 WSL 专项检查
- 增加 D-InSAR 队列、存储、结果一致性检查
- 增加自愈动作入口

#### 专项健康检查项

- 核心服务状态
  - 数据库
  - schema
  - worker
  - queue
- 引擎状态
  - `sarscape`
  - `isce2`
  - `landsar`
- WSL 状态
- DEM/轨道/输出目录可用性
- D-InSAR 运行任务积压
- stale run 检测
- 输出未入库检测
- 入库但源文件缺失检测
- 缓存一致性检测

#### 自愈入口建议

- 重扫结果目录
- 重建缓存
- 重试入库
- 重置 stale run
- 标记失效结果

#### 验收标准

- 运维面板能区分系统级故障与引擎级故障
- 当 ENVI 不可用但 ISCE2 可用时，总体 D-InSAR 服务状态应为 `degraded` 或 `ok`，不能直接判全系统失败
- WSL 故障能定位到具体检查项

### T6. 结果管理增强

#### 目标

- 将 D-InSAR 结果从“扫描到的一条文件记录”升级为“正式结果资产”

#### 核心设计

- `Run`
  - 一次真实生产执行
- `Artifact`
  - 一次运行产出的具体文件
- `Managed Result`
  - 面向前端与业务的主结果对象

#### 关键任务

- 扩充结果模型字段
- 增加结果来源追踪
- 增加版本管理
- 增加多产物管理
- 增加结果生命周期状态
- 增加批量治理能力
- 增加多引擎结果对比能力

#### 结果管理能力清单

- 来源追踪
  - engine
  - profile
  - batch
  - pair
  - run
- 版本管理
  - 当前版本
  - 历史版本
  - 最新成功版本
- 多产物管理
  - disp
  - coherence
  - unwrapped phase
  - geotiff
  - browse
  - log
- 生命周期管理
  - `NEW`
  - `INGESTED`
  - `QC_PENDING`
  - `QC_PASSED`
  - `QC_REJECTED`
  - `PUBLISHED`
  - `ARCHIVED`
- 批量操作
  - 发布
  - 归档
  - 重扫
  - 重建缓存
  - 重绑定来源
  - 导出
- 检索增强
  - 按引擎
  - 按批次
  - 按任务名
  - 按状态
  - 按 AOI
  - 按版本

#### 前端结果管理架构建议

- 结果列表视图
- 结果详情视图
- 来源与版本视图
- 治理与运维视图

#### 运维治理项

- 入库记录存在但源文件缺失
- run 存在但 artifact 缺失
- 当前版本指针异常
- 同名结果冲突
- 缓存与主文件不一致
- 已发布结果未完成审核

#### 验收标准

- 同一对影像允许保留多引擎结果
- 同一任务允许保留多版本
- 结果详情页能追踪到来源 run 和主产物列表
- 运维面板可识别结果资产层异常

## 8. 实施顺序

### Phase 1

- 完成多引擎与结果管理设计冻结
- 完成接口契约
- 完成数据模型草案

### Phase 2

- 实现后端抽象层
- 完成 SARSCAPE 兼容接入
- 保持旧接口兼容

### Phase 3

- 实现新前端生产中心
- 实现引擎状态、运行监控和运维自检增强

### Phase 4

- 接入 ISCE2 + WSL
- 打通首条正式生产链

### Phase 5

- 实现结果管理增强
- 补齐版本、来源、治理与自愈

## 9. 交付顺序建议

建议按照以下顺序落地：

1. 先重构生产抽象层，不先碰最终结果治理细节
2. 先让 `sarscape` 在新体系下跑通
3. 再接入 `isce2`
4. 最后再把结果管理全面升级

这样可以避免在“生产链尚未稳定”时提前锁死结果模型细节。

## 10. 当前结论

本轮不应被理解为“给当前 ENVI 面板再加一个 ISCE2 按钮”，而应被理解为：

- D-InSAR 生产系统平台化
- D-InSAR 结果资产化
- 运维自检从系统健康升级为多引擎专项健康

后续所有开发任务、联调任务和运维验收，均以本 Task 文档为总入口。