insar-management-system-v2/docs/archive/DINSAR_ENHANCEMENT_TASKS.md

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 文档为总入口。