chore: initialize insar management system v2

This commit is contained in:
2026-04-14 13:16:01 +08:00
commit ecc72ec9cd
361 changed files with 2142522 additions and 0 deletions
+426
View File
@@ -0,0 +1,426 @@
# D-InSAR 增强 Task 文档
更新日期:2026-03-13
## 1. 文档目的
这份文档用于统一管理本轮 D-InSAR 系统重构任务,覆盖以下两大方向:
- D-InSAR 多引擎生产系统增强
- D-InSAR 结果管理系统增强
文档定位是“任务总表 + 实施边界 + 验收口径”,用于后续分阶段实施、联调和运维验收。
## 2. 背景
当前系统的 D-InSAR 生产能力主要绑定在 ENVI + SARscape 链路上,前端、后端任务模型、运行监控和结果入库都默认只有一个处理引擎。这会带来两个直接问题:
- 客户如果没有 ENVI/SARscape licenseD-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 文档为总入口。