Software Development Plan (SDP)#
Document |
Software Development Plan (SDP) |
DRD |
ECSS-E-ST-40C Rev.1, Annex O |
Container |
Management File (MGT) |
Project |
|
Configuration item |
|
Software criticality |
Category C (ECSS-Q-ST-80C Rev.2 / ECSS-E-ST-40C Annex R) |
Baselined at |
SRR |
Status |
Draft for SRR |
This SDP is the top-level management artefact of the ECSS software life cycle for the
sar-processorproject. It follows the ECSS-E-ST-40C Rev.1 Annex O DRD section structure and records the management and development approach, the life-cycle model, the review milestones, and — through the tailoring in §5.5 / §5.6 — the documentation tree the project commits to. The footprint is tailored to a Category C, single-developer ground-segment processor. This issue completes the SRR baseline: the life-cycle model, tailored DRL, work breakdown and the WP-5 implementation increment plan are committed; the per-milestone technical documents (SRS/ICD/DPM/ATBD/SDD/…) follow at their respective gates (PDR/CDR/QR).
<1> Introduction#
The sar-processor is an operational ground-segment forward data processor that transforms
downlinked raw (Level-0) synthetic aperture radar (SAR) instrument source packets into focused
and calibrated products: Level-1 SLC (single-look complex), Level-1 GRD (detected,
multi-looked, ground-range projected), with Level-2 ocean products TBC at SRR. It is designed as a
generic spaceborne SAR processor: the processing chain (L0 decode → Doppler-centroid estimation
→ range compression → azimuth focusing → radiometric calibration → multilook/detection → geocoding)
is sensor-agnostic and driven by a per-sensor configuration/profile. The first instantiated profile
is a C-band SAR, with Sentinel-1 C-SAR as the public reference dataset.
The processor is built on the ESA Earth Observation Processing Framework (EOPF): each
processing stage is an EOPF Core Python Modules (CPM) EOProcessingUnit (eopf == 2.8.1),
products are handled as EOPF EOProduct objects, and outputs are written as cloud-native Zarr.
The platform machinery (CI, documentation toolchain, package layout, single-driver convention) is
reused from the sibling ipf/msi-processor project (see SRF, RD-12).
The purpose of this SDP is to describe the established management and development approach for the
software items of sar-processor, in accordance with ECSS-E-ST-40C Rev.1. It is prepared at
project start to establish the SRR baseline and is maintained throughout the life cycle.
<2> Applicable and reference documents#
Applicable documents
Ref |
Document |
|---|---|
AD-1 |
ECSS-E-ST-40C Rev.1 (30 April 2025) — Space engineering — Software |
AD-2 |
ECSS-Q-ST-80C Rev.2 (30 April 2025) — Space product assurance — Software product assurance |
AD-3 |
ECSS-M-ST-10C Rev.1 — Space project management — Project planning and implementation |
AD-4 |
ECSS-M-ST-40C — Configuration and information management |
Reference documents
Ref |
Document |
|---|---|
RD-1 |
SSS — |
RD-2 |
IRD — |
RD-3 |
SRS — |
RD-4 |
ICD — |
RD-5 |
SDD — |
RD-6 |
DPM — |
RD-7 |
ATBD — |
RD-8 |
V&V Plan — |
RD-9 |
Traceability matrix — |
RD-10 |
SUITP — |
RD-11 |
DJF — |
RD-12 |
SRF — |
RD-13 |
SPAP — |
RD-14 |
SRevP — |
RD-15 |
Risk Register — |
<3> Terms, definitions and abbreviated terms#
Terms per AD-1 clause 3. The full project SAR glossary (ISP, FDBAQ, SLC, GRD, GTC, focusing, RDA, DCE, TOPSAR, burst, deramp, PRF/SWST, chirp/replica, σ0/β0/γ0, EAP/AAP/AAEP, NESZ, PSLR/ISLR, IRW, ALE, ENL, IPF, ADF, SAFE, annotation, …) is collected in the SSS (RD-1) <3> and applies here.
<4> Software life cycle management#
<4.1> Life cycle. Incremental development within the ECSS review frame SRR → PDR → CDR → QR → AR, mirroring the msi-processor precedent: requirements baseline at SRR, architectural design + preliminary ICD/DPM/ATBD at PDR, detailed design + SUITP at CDR, verification results at QR, acceptance at AR.
Work breakdown (WP → milestone).
WP |
Title |
Milestone |
|---|---|---|
WP-1 |
Project setup (repo, CI, |
pre-SRR (done) |
WP-2 |
SRR documentation (SDP, SRevP, SPAP, Risk Register, SSS, IRD, initial SRF) |
SRR |
WP-3 |
PDR documentation (SRS, V&V plan, ICD start, DPM, ATBD, preliminary SDD) |
PDR |
WP-4 |
CDR documentation (detailed SDD+DJF, SUITP, final ICD, SRF, traceability matrix) |
CDR |
WP-5 |
Implementation — SAR processing stages, decomposed into the increments below |
post-CDR |
WP-6 |
Verification & validation (SVR, SUITR), release (SRelD/SRN), SUM |
QR / AR |
Implementation increment plan (WP-5, post-CDR). WP-5 is decomposed into pedagogically-ordered
increments — fundamentals before TOPSAR complexity. The v1 target is IW/TOPSAR SLC + GRD + GTC,
validated against real Sentinel-1 data (tolerance-based, not bit-identical). Each increment carries a
teaching ATBD section + a reference notebook (authored during PDR/CDR as DPM breakpoint studies) that is
hardened — not rewritten — into core.py/unit.py after CDR.
Inc |
Scope |
Principal artefacts |
|---|---|---|
0 |
Ground zero: L0-package extract, one real IW datatake+ADFs into the data store, typed-but-empty package skeleton, point-target simulator, driver phases |
|
1 |
L0 decode (FDBAQ) + product/annotation model + pre-processing |
|
2 |
Single-burst focusing (range + azimuth RDA); point-target then real burst |
|
3 |
Doppler-centroid estimation + TOPSAR deramp/UFR |
|
4 |
Multi-burst deburst/merge → full IW SLC |
|
5 |
Radiometric calibration (σ0/β0/γ0 + EAP) + thermal-noise |
|
6 |
GRD (detection / multilook / ground-range) |
|
7 |
GTC geocoding (Range-Doppler terrain correction + DEM) |
|
8 |
Full-chain integration + calibration mode + QR hardening |
|
Detailed activities are managed as GitLab issues assigned to the corresponding milestone.
<4.2> Organisation. Single developer (project owner) acting as designer, implementer and verifier; reviews conducted asynchronously on the GitLab instance via MRs and milestone review issues (SRevP, RD-14).
<4.3> Development environment. EOPF SDE: shared cpm-build-environment CI image, GitLab CI on
project runners, Python 3.11, EOPF CPM pinned (eopf == 2.8.1).
<4.5> Risk management. See Risk Register (RD-15).
<5> Software development approach#
<5.1>–<5.4> Development standards (PEP8 via black/flake8/isort at 120 columns, mypy strict on
the package, bandit security scanning), methods and tools follow the msi-processor conventions;
they are enforced by the CI pipeline (.gitlab-ci.yml). The SAR-specific numerical addition over
the msi toolchain is a fast-FFT backend for range/azimuth compression — numpy.fft as the deterministic
baseline, with scipy.fft / pyFFTW as an optional accelerated backend — declared in pyproject.toml
and justified in the SDD/SRF. The chosen FFT backend and the complex working dtype (complex64) are
fixed for reproducible CI budgets (SSS SYS-RAM-01); the design method (pure core.py + thin unit.py
EOProcessingUnit + CPM computing-model JSON, sensor-profile-driven) and the single mode-only pipeline
driver follow the msi-processor pattern.
<5.5> Documentation plan#
<5.5.1> The documentation tree lives in compliance/ (authoritative markdown sources) and is
published through the Sphinx site (docs/compliance/ symlinks). One document = one file.
<5.5.2> Tailored Document Requirements List (DRL)#
ECSS-E-ST-40C Rev.1 (engineering)
DRD |
Annex |
Decision |
Delivered |
File |
|---|---|---|---|---|
SSS — Software System Specification |
B |
PRODUCE |
SRR |
|
IRD — Interface Requirements Document |
C |
PRODUCE |
SRR |
|
SRS — Software Requirements Specification |
D |
PRODUCE |
PDR |
|
ICD — Interface Control Document |
E |
PRODUCE |
PDR (prelim) / CDR (final) |
|
SDD — Software Design Document |
F |
PRODUCE |
CDR |
|
DJF — Design Justification |
§4.2.4/5 |
PRODUCE (light) |
CDR |
|
DPM — Data Processing Model |
— (EOPF DPR) |
PRODUCE |
PDR |
|
ATBD — Algorithm Theoretical Basis |
— (EO domain) |
PRODUCE |
PDR |
|
SVerP / SValP — Verification & Validation Plans |
I / J |
PRODUCE (merged) |
PDR |
|
SUITP — Unit & Integration Test Plan |
K |
PRODUCE |
CDR |
|
SVR — Verification Report |
M |
PRODUCE |
QR |
|
SUITR — Unit & Integration Test Report |
K→M |
PRODUCE |
QR |
|
SRF — Software Reuse File |
N |
PRODUCE |
SRR (initial) / CDR |
|
SRevP — Software Review Plan |
P |
PRODUCE (light) |
SRR |
|
SRN / SRelD — Software Release Note |
SRelD |
PRODUCE |
QR / each release |
|
SUM — Software User Manual |
H |
PRODUCE |
QR |
|
SMP — Software Maintenance Plan |
T |
TAILORED-OUT (light) |
AR |
maintenance = GitLab issues + SemVer |
ECSS-Q-ST-80C Rev.2 + cross-discipline
Artefact |
Decision |
Delivered |
File |
|---|---|---|---|
SPAP — Software Product Assurance Plan |
PRODUCE (light) |
SRR |
|
Risk Register |
PRODUCE |
SRR (living) |
|
Traceability matrix |
PRODUCE |
PDR (living) |
|
CIDL — Configuration Item Data List |
PRODUCE |
QR |
|
SCF — Software Configuration File |
PRODUCE |
QR |
|
QR report |
PRODUCE |
QR |
|
<5.6> Tailoring rationale#
Category C, single-developer, ground-segment-only: documents merged or lightened exactly as in the msi-processor precedent (V&V plans merged per Annex I/J; SMP tailored out in favour of the GitLab issue tracker + SemVer releases; DJF kept light).
Clause-5 tailoring summary (ECSS-E-ST-40C, Category C / Annex R). Requirements, interface, design,
verification and validation clauses are applied in full (SSS/IRD → SRS/ICD → SDD → vv-plan → SVR).
Formal system-specification-language models (E-40 §5.2.7 / SSS <7>) are tailored out — concrete project
artefacts (the EOProcessingUnit pipeline graph, the profile schema, the EOProduct/Zarr data model, the
DPM/ATBD) serve the model role. Independent IV&V and separate PA/verification roles are replaced by
automated CI gates + review checklists (Category C, single developer). TAILORED-OUT with rationale:
SMP (light — GitLab issues + SemVer); SPAMR (subsumed by the SVR + milestone reviews); SVS (realised by
the test suite + vv-plan). Reuse is only of the sensor-agnostic scaffold/process from msi-processor:
the product/ subpackage and the SAR-specific data types (complex64, per-burst grouping) and stage
set are new development recorded in the SRF (RD-12) — no structural identity with msi-processor is
levied.
<6> Schedule and milestones#
Milestone |
Scope |
Target |
|---|---|---|
SRR |
Requirements baseline (SSS, IRD, SDP, SPAP, SRevP, Risk Register, initial SRF) |
GitLab milestone |
PDR |
SRS, preliminary ICD, DPM, ATBD, V&V Plan |
GitLab milestone |
CDR |
SDD, final ICD, DJF, SUITP, SRF, traceability matrix |
GitLab milestone |
QR |
SVR, SUITR, SRN, CIDL, SCF, QR report, SUM |
GitLab milestone |
AR |
Acceptance, delivery baseline |
GitLab milestone |
Calendar dates are managed in the GitLab group ipf milestones, not duplicated here. The milestone
order is fixed SRR → PDR → CDR → QR → AR; implementation (WP-5, §4.1) starts only after CDR closure.
End of SDP. Authored per ECSS-E-ST-40C Rev.1 Annex O.