# Software Reuse File (SRF)

| Field | Value |
|---|---|
| **Document** | SRF — Software Reuse File |
| **DRD ref** | ECSS-E-ST-40C Rev.1, Annex N (SRF DRD); ECSS-Q-ST-80C Rev.2 §6.2.7 |
| **Container** | Design Justification File (DJF) — `compliance/drd/` (source), published subset in `docs/srf.md` |
| **Project** | `sar-processor` (gitlab.eopf.copernicus.eu/ipf/sar-processor) |
| **Software criticality** | Category C (ECSS-Q-ST-80C Rev.2 / ECSS-E-ST-40C Annex R) |
| **Baselined at** | **SRR (initial)** / CDR (final) |
| **Status** | Draft for SRR — initial issue |

> **Purpose of this issue.** `sar-processor` reuses the **sensor-agnostic platform and process machinery**
> proven on the sibling `ipf/msi-processor` project, and reuses the **public Sentinel-1 algorithm basis**
> (the IPFDPM and the SentiWiki technical corpus) as the mathematical reference for its focusing,
> calibration and geocoding stages. The SAR **processing content is new development** — there is **no
> requirement that `sar-processor` be structurally identical to `msi-processor`**; the two are different
> sensors with different chains, data models and stage sets. This SRF (initial issue, SRR) records what
> is reused, on what licence, at what quality level, and — explicitly — the **reuse-vs-new boundary**. The
> detailed per-module evaluation and corrective-action results are finalised at CDR, before implementation
> (WP-5) starts. Sensor-private content (calibration coefficients, private ADF values) is **not**
> reproduced here (data policy).

---

## <1> Reused software items

Reused items are identified as **`SRF-RU-*`**. Three reuse bodies, each with its own category and
treatment:

| Id | Item | Origin | Category | Scope of reuse | Pedigree |
|---|---|---|---|---|---|
| SRF-RU-01 | CI pipeline (stages, quality/security gates, Pages / versioned-docs machinery) | `ipf/msi-processor` `.gitlab-ci.yml` | scaffold (as-is, names adapted) | adopted verbatim, project names adapted | CI green on donor through QR |
| SRF-RU-02 | Documentation toolchain (Sphinx conf, `compliance/` source + `docs/compliance/` symlink publishing, SUM/DRD skeletons) | `ipf/msi-processor` `docs/` + `compliance/` | scaffold (as-is) | adopted verbatim | published donor site |
| SRF-RU-03 | Package/process conventions — the **`core.py` (framework-free) + `unit.py` (`EOProcessingUnit`) + `models/*.json` (CPM computing model)** stage pattern; typed error hierarchy with `stage=` tags; Pydantic `SensorProfile` with ADF-reference bindings; single mode-only pipeline driver; `tests/ut`+`tests/it` layout | `ipf/msi-processor` | **pattern reuse** (not code copy) | the *conventions* are reused; SAR *content* is new | donor SDD, QR-verified |
| SRF-RU-04 | EOPF CPM runtime (`eopf == 2.8.1`) | ESA EOPF | COTS/platform (as-is) | mandated runtime | ESA-maintained, pinned |
| SRF-RU-05 | Shared data-store fetch/publish mechanism (`ipf/data-store`, GitLab generic package registry, sha256 manifest) | `ipf/msi-processor` driver | scaffold (as-is, `[TBC@PDR]` for SAR store layout) | fetch-store/publish-store convention | donor integration tests |
| SRF-RU-06 | **Public Sentinel-1 algorithm basis** — IPFDPM (focusing/DCE/calibration math), SentiWiki product/calibration/geocoding/TOPS-deramp/thermal-noise/ADF references | ESA/Aresys/DLR/UZH (public; vault `wiki/`) | **algorithm reuse — re-engineered** | equations reused; code written new into SAR Cores | public engineering, peer-referenced |
| SRF-RU-07 | Scientific-Python OSS stack (numpy, scipy, xarray, zarr, dask) + FFT backend (`numpy.fft` baseline; optional `scipy.fft`/`pyFFTW`) | OSS communities | OSS (as-is, by dependency) | numerical kernels inside the Cores | mature, semantically versioned |

## <2> Reuse categories and the reuse-vs-new boundary

- **Scaffold / process (SRF-RU-01/02/03/05):** reused from msi-processor because it is **sensor-agnostic
  infrastructure** — CI gates, docs publishing, the `core`/`unit`/`model` separation, the profile-driven
  design, the data-store protocol, the test layout. Reuse here is of *conventions and machinery*, adapted
  by name; it is **not** a constraint that the SAR chain mirror the MSI chain.
- **Platform (SRF-RU-04):** the EOPF CPM, reused as-is (mandated runtime), pinned at `eopf == 2.8.1`.
- **Algorithm basis (SRF-RU-06):** the public Sentinel-1 algorithm mathematics is reused as the
  *reference*; the SAR Cores that realise it (decode, focusing, DCE, TOPSAR, calibration, GRD, geocode)
  are **written new** against the ATBD/DPM — algorithm reuse, code new.
- **OSS kernels (SRF-RU-07):** reused as-is by dependency.

**New development (NOT reuse) — the SAR-specific boundary.** The following are new to `sar-processor` and
are *expected* differences from msi-processor, not deviations to be justified against a msi baseline:

| New element | Reason it is SAR-specific |
|---|---|
| `sar_processor/product/` subpackage (SAFE/annotation/LUT/orbit I/O) | SAR's per-product metadata (annotation XML, CADS/NADS LUTs, orbit/attitude) is far heavier than MSI's; kept out of the framework-free cores |
| Complex data model — `SlcImage` (`complex64`), `BurstStack`, per-burst grouping | SAR is coherent/phase-preserving; MSI is real-valued |
| SAR stage set — `l0_decode`(+FDBAQ), `preproc`, `doppler`, `range_comp`, `azimuth_comp`, `topsar`, `calibration`, `noise`, `grd`, `geocode` | the SAR chain (focusing + TOPSAR + geocoding) has no MSI counterpart |
| SAR QA flags — `BLACK_FILL`, `DERAMP_INVALID`, `THERMAL_NOISE_SUBTRACTED`, `GEO_LAYOVER_SHADOW`, … | SAR-specific quality conditions |
| Image-quality metrics — PSLR, ISLR, IRW, ENL, NESZ, ALE | SAR focusing/geolocation/noise metrics |
| SAR `SensorProfile` extension (carrier frequency, polarisations, sub-swath specs, IPF-version envelope) + the annotation-vs-ADF split | SAR radar geometry and IPF-version gating |
| FFT backend dependency | range/azimuth compression |

## <3> Licence compatibility (project code is public)

Project licence: **Apache-2.0**. All reused runtime software is permissive and Apache-2.0-compatible:
EOPF CPM (Apache-2.0), numpy/scipy/dask (BSD-3-Clause), xarray (Apache-2.0), zarr (MIT); the FFT backend
options are BSD (`numpy`/`scipy`) or, if `pyFFTW` is adopted, **BSD-3-Clause** (its FFTW binding wrapper)
— note FFTW itself is **GPL**, so `pyFFTW` is admitted only if the deployment can accept that or is kept
optional/non-distributed; `numpy.fft` (BSD) is the default to avoid any copyleft obligation. The public
Sentinel-1 algorithm basis (SRF-RU-06) is documentation/engineering, not code, and imposes no code
licence. `[confirm-before-release]`: the final FFT-backend decision and any optional accelerated backend
are pinned and licence-audited at CDR/release.

## <4> Reuse assessment (initial — Annex N <5>)

| Item | Quality level vs Category C | Decision | Re-verification |
|---|---|---|---|
| SRF-RU-01/02 (CI, docs) | HIGH — donor CI green through QR | reuse as-is (names adapted) | pipeline runs green on SAR repo |
| SRF-RU-03 (patterns) | HIGH — donor SDD, QR-verified | pattern reuse | SAR Cores/units verified under project V&V |
| SRF-RU-04 (EOPF CPM) | HIGH — mandated, pinned | reuse as-is | verify *use* (Wrapper/Zarr round-trip), not internals; complex/burst support probed (RSK-05) |
| SRF-RU-05 (data-store) | HIGH — donor integration-tested | reuse as-is; SAR store layout `[TBC@PDR]` | fetch/publish round-trip |
| SRF-RU-06 (S1 algorithm basis) | HIGH as *reference* (public, peer-referenced); LOW as *code* (there is no code to reuse) | **reuse algorithm, write code new** | each Core re-derived vs ATBD, validated on point-target + real data (tolerance-based) |
| SRF-RU-07 (OSS + FFT) | HIGH — mature, versioned | reuse as-is | verify kernel use vs ATBD; pin versions; licence audit |

## <5> Corrective actions / conditions (initial)

| Id | Action | Applies to | Closes at |
|---|---|---|---|
| CA-01 | Confirm EOPF Zarr support for `complex64` + per-burst grouping, or define a documented convention | SRF-RU-04 | PDR (RSK-05) |
| CA-02 | Fix the FFT-backend decision + licence audit (avoid FFTW/GPL by default) | SRF-RU-07 | CDR/release |
| CA-03 | Baseline the SAR data-store layout for `fetch-store`/`publish-store` | SRF-RU-05 | PDR |
| CA-04 | Finalise the per-stage algorithm-basis → Core mapping (ALG-*), with keep/adapt notes | SRF-RU-06 | CDR |
| CA-05 | Record the `product/` subpackage + complex/burst types + SAR stage set as new development in the SDD | new-dev boundary | CDR |

> **Status at SRR: initial.** No corrective action is closed at this issue; implementation (code) starts
> only after CDR. The final SRF (CDR) will carry the per-module evaluation, the closed corrective actions,
> and the configuration status of every reused baseline.

---

*End of SRF (initial issue). Authored per ECSS-E-ST-40C Rev.1 Annex N, tailored for Category C; finalised
at CDR.*