Software System Specification (SSS)#
Field |
Value |
|---|---|
Document |
SSS — Software System Specification |
DRD ref |
ECSS-E-ST-40C Rev.1, Annex B |
Container |
EOPF SDE — |
Project |
|
Software criticality |
Category C (ECSS-Q-ST-80C Rev.2 / ECSS-E-ST-40C Annex R) |
Baselined at |
SRR (System Requirements Review) |
Status |
Draft for SRR |
This SSS is the highest-level specification of
sar-processorand, together with the IRD, forms the requirements baseline and the primary input to the SRR. Per the SDP tailoring for a single-developer Category C project there is no external customer or separate system tier: the mission/ground-segment context that would otherwise sit in a parent system specification is folded into this document (clauses <1> and <4>). System-level requirements defined here (SYS-*) are decomposed into software requirements in the SRS (Annex D) at PDR.
<1> Introduction#
Purpose. This document specifies, at system level, the sar-processor software product: a
generic spaceborne Synthetic Aperture Radar (SAR) ground-segment forward data processor. It
transforms downlinked RAW (Level-0) SAR instrument source packets (ISPs) into focused,
calibrated and geolocated products — Level-1 SLC (Single Look Complex), Level-1 GRD (Ground
Range Detected) and geocoded terrain-corrected GTC imagery — through decoding, focusing,
radiometric calibration, detection/multi-looking and geocoding. The SSS captures what the
processor must do as a product within an Earth-observation ground segment — its capabilities,
performance and quality objectives, operational environment and system-level constraints —
independent of internal software design (the subject of the SDD, Annex F).
Objective. The SSS establishes the requirements baseline against which the software is validated
and accepted. It is the parent of the SRS: every software requirement traces back to a system
requirement (SYS-*) defined here, and every system requirement is associated with a validation
method (clause <5.1>, <6>).
Content. Clause <4> gives the general description (product perspective, capabilities, constraints, operational environment, assumptions). Clause <5> states the specific system requirements grouped by type. Clause <6> defines the verification, validation and integration requirements. Clause <7> addresses system models.
Reason for preparation. The project is an integration and ECSS productisation effort. The SAR processing chain’s mathematical basis is established public engineering (ESA/Aresys Sentinel-1 Level-1 Detailed Algorithm Definition and the SentiWiki technical corpus, RD-05/RD-09); it is not new-algorithm research. The SSS turns that algorithmic basis plus the EOPF platform into a documented, verifiable, configuration-driven product. The chain is sensor-agnostic, driven by a per-sensor profile; the first instantiated profile is C-band SAR with Sentinel-1 C-SAR as the public reference dataset and acquisition mode Interferometric Wide (IW, TOPSAR).
Contrast with the sibling
msi-processor(informative). Both products share the sensor-agnostic EOPF scaffold, but SAR is an active, coherent, phase-preserving instrument whereas MSI is passive optical. Consequently the SAR chain and its quality budgets differ fundamentally: L0 is an unfocused complex echo stream (not an image), the core work is focusing (range/azimuth compression), and quality is expressed as impulse-response (PSLR/ISLR/IRW), geolocation (ALE), noise-floor (NESZ) and phase-preservation budgets. No structural identity withmsi-processoris levied; only the scaffold/process is reused (SRF, RD-12).
<2> Applicable and reference documents#
Applicable documents (AD)#
Id |
Document |
Reference |
|---|---|---|
AD-01 |
ECSS Space engineering — Software |
ECSS-E-ST-40C Rev.1 (30 April 2025) |
AD-02 |
ECSS Space product assurance — Software product assurance |
ECSS-Q-ST-80C Rev.2 |
AD-03 |
ECSS System engineering — General requirements |
ECSS-E-ST-10C Rev.1 |
AD-04 |
|
|
AD-05 |
EOPF Core Python Modules (CPM) — Product Structure and Format Definition (PSFD) / common data model |
EOPF CPM documentation ( |
Reference documents (RD)#
Id |
Document |
Reference |
|---|---|---|
RD-01 |
ECSS Software engineering handbook |
ECSS-E-HB-40A |
RD-02 |
ECSS Technical requirements specification |
ECSS-E-ST-10-06C |
RD-03 |
ECSS Risk management |
ECSS-M-ST-80C |
RD-04 |
|
|
RD-05 |
Sentinel-1 Level-1 Detailed Algorithm Definition (IPFDPM) — focusing / DCE / calibration algorithm basis |
ESA DI-MPC-IPFDPM (vault: |
RD-06 |
|
|
RD-07 |
EOPF CPM API documentation |
EOPF CPM API ( |
RD-08 |
Cloud-native data conventions |
Zarr v2/v3, CF metadata, STAC |
RD-09 |
Sentinel-1 technical reference corpus (products, radiometric calibration, TOPS deramping, geocoding, thermal denoising, ADF specification) |
Vault |
RD-10 |
Sentinel-1 Product Definition & Product Specification |
ESA S1-RS-MDA-52-7440/7441 (vault: |
RD-11 |
Sentinel-1 IPF Auxiliary Product Specification (ADF set) |
ESA S1-RS-MDA-52-7443 (vault: |
RD-12 |
|
|
<3> Terms, definitions and abbreviated terms#
Only terms not already defined in the AD/RD are listed. SAR-domain terms are collected here and are the project glossary referenced by the IRD and SDP.
Term / abbr. |
Definition |
|---|---|
SAR |
Synthetic Aperture Radar (active, coherent microwave imaging instrument) |
Profile |
Per-sensor configuration set (radar constants, geometry, polarisations, calibration references, processing parameters) that specialises the generic chain for one instrument/mode |
ISP |
Instrument Source Packet — the Level-0 space-packet carrying compressed echo/calibration/noise samples + secondary header |
FDBAQ |
Flexible Dynamic Block Adaptive Quantization — the S1 echo compression scheme (Huffman-coded) decoded at L0 |
L0 (RAW) |
Level-0: compressed instrument source packets + annotation; the unfocused complex echo stream |
SLC |
Single Look Complex — focused, slant-range, phase-preserving complex L1 product (per-burst for TOPSAR) |
GRD |
Ground Range Detected — focused, detected (amplitude), multi-looked, ground-range-projected L1 product |
GTC / GEC |
Geocoded Terrain-Corrected (DEM) / Geocoded Ellipsoid-Corrected — map-projected geometry classes |
Focusing |
Conversion of the unfocused echo to an image via range compression (chirp matched filter) + azimuth compression (synthetic aperture) |
RDA |
Range-Doppler Algorithm — the focusing algorithm used by the S1 IPF |
Range / azimuth compression |
Matched-filtering in the range (fast-time) / azimuth (slow-time) direction |
RCMC / SRC |
Range Cell Migration Correction / Secondary Range Compression (RDA sub-steps) |
DCE |
Doppler Centroid Estimation (absolute from orbit/attitude; fine from data via ACCC) |
TOPSAR |
Terrain Observation by Progressive Scans — S1 IW/EW mode; azimuth beam-steering → bursts + azimuth-Doppler ramp |
Burst / deburst |
TOPSAR azimuth acquisition unit / the merge of focused bursts into a continuous image |
De-ramp / re-ramp |
Removal/reapplication of the TOPSAR azimuth-steering phase ramp (mandatory before any resampling) |
PRF / SWST |
Pulse Repetition Frequency / Sampling Window Start Time (instrument timing from ISP headers) |
Chirp / replica |
Linear-FM transmitted pulse / its reconstruction used as the range matched filter |
σ0 / β0 / γ0 |
Radiometric backscatter conventions (sigma/beta/gamma nought) |
EAP / AAP / AAEP |
Elevation / Azimuth Antenna Pattern / Azimuth Antenna Element Pattern (calibration corrections) |
NESZ |
Noise-Equivalent Sigma Zero — the σ0 of the instrument noise floor |
PSLR / ISLR |
Peak / Integrated Side-Lobe Ratio — impulse-response (focusing) quality metrics |
IRW |
Impulse Response Width — the −3 dB main-lobe width = spatial resolution |
ALE |
Absolute Location Error — geolocation accuracy (range/azimuth) |
ENL |
Equivalent Number of Looks — speckle-reduction measure of a multi-looked product |
IPF |
Instrument Processing Facility — the reference (ESA) Level-1/2 processor; its version gates corrections |
ADF |
Auxiliary Data File (AUX_CAL, AUX_INS, AUX_PP1, AUX_POE/RES/PRE, AUX_ATT, DEM) |
DEM |
Digital Elevation Model |
SAFE |
Standard Archive Format for Europe — the S1 product packaging (manifest + measurement + annotation) |
QA |
Quality assurance / quality indicators (per-pixel flags and masks) |
CPM / EOProduct / EOProcessingUnit |
EOPF Core Python Modules / CPM in-memory product object / CPM processing-stage unit |
Zarr / EOPF / SDE |
Cloud-native chunked array storage / Earth Observation Processing Framework (ESA) / EOPF cloud development & processing environment |
DPM / ATBD |
Data Processing Model / Algorithm Theoretical Basis Document (per-stage algorithm basis, PDR) |
T / A / I / R |
Validation/verification methods: Test / Analysis / Inspection / Review of design |
<4> General description#
<4.1> Product perspective#
sar-processor is a software product within an Earth-observation ground segment. In the wider
mission, a spaceborne SAR satellite acquires coherent microwave echoes and downlinks RAW (Level-0)
data; the ground segment ingests, archives and processes that data into user-facing products.
sar-processor occupies the payload data processing function: it consumes Level-0 SAR ISPs plus
auxiliary/calibration data (ADFs) and produces focused, calibrated and geolocated products up to
L1 SLC, L1 GRD and geocoded GTC. (Level-2 ocean products — OWI/OSW/RVL — are out of scope for the
current baseline, TBC at a later increment.)
The product is sensor-agnostic by design: the processing chain is fixed, while the instrument-specific behaviour is supplied as a per-sensor profile. The first instantiated profile is C-band SAR (Sentinel-1 C-SAR, IW/TOPSAR). Because SAR products are coherent and phase-preserving, the chain maintains complex (I/Q) data through focusing and preserves phase into the SLC product (a prerequisite for interferometric use downstream).
The product does not replace a specific legacy system; it is a new, EOPF-native implementation. The ESA Sentinel-1 IPF is used as the numerical cross-validation reference (clause <6.2>), not replaced in place. Upstream (reception, demodulation, downlink to L0) and downstream (archiving, cataloguing, dissemination, Level-2 geophysical retrieval) ground-segment functions are external and not specified here.
<4.2> General capabilities#
The software provides the end-to-end L0→L1→GTC capability, decomposed by processing stage:
Ingestion & decoding (L0): ingest Level-0 SAR ISPs and the profile-selected ADFs; decode the compressed echo (FDBAQ), reconstruct instrument timing (PRF, SWST) from the ISP headers, and de-multiplex per sub-swath / polarisation into complex channels.
Pre-processing: I/Q bias removal, internal-calibration and transmitted-replica reconstruction (for range matched-filtering and spectrum whitening), missing-line detection.
Doppler-centroid estimation (DCE): absolute Doppler centroid from orbit & attitude and fine estimation from the data; for TOPSAR, azimuth-steering de-ramp prior to estimation.
Focusing to SLC: range compression (chirp matched filter) and azimuth compression (Range-Doppler Algorithm — SRC, RCMC, azimuth matched filter), preserving phase; for TOPSAR, azimuth de-ramp/re-ramp, spectral unfolding and deburst/merge of the focused bursts and sub-swaths into a continuous SLC.
Radiometric calibration: application of the σ0/β0/γ0 calibration (range look-up tables folding the absolute constant, elevation antenna pattern and range-spreading loss), elevation-antenna- pattern (gain and phase) correction, and optional thermal-noise removal.
GRD generation: range weighting, azimuth multi-looking, TOPSAR de-scalloping, detection (power), and slant-range-to-ground-range projection.
GTC geocoding: Range-Doppler terrain correction using orbit and a DEM, mapping the product to a cartographic grid (GTC with DEM; GEC on the ellipsoid where no DEM is available).
Product generation: output of cloud-native Zarr
EOProducts conformant to the EOPF data model, carrying acquisition/processing metadata, provenance and per-pixel QA flags.Configuration / profile management and pipeline orchestration: each stage is a CPM
EOProcessingUnit; stages are chainable, individually runnable and chunked (per burst / sub-swath) for bounded-memory / parallel execution.
States and modes (informative). At system level the processor exhibits: configured/idle (profile and inputs resolved, ready), processing (one or more stages executing), and error/aborted (a stage failed; outputs flagged, no partial product silently published). Two production modes are foreseen: nominal (L0→SLC→GRD→GTC) and calibration (internal-cal / replica characterisation and cross-check). The processor is a non-resident batch component — no continuous resident or real-time mode.
<4.3> General constraints#
The product shall be built on the EOPF CPM (
EOProcessingUnit,EOProduct) pinned toeopf == 2.8.1, matching the SDE build image.Products shall be cloud-native Zarr conforming to the EOPF data model (AD-05).
The implementation language is Python 3.11.
The processing algorithms reuse the established public mathematical basis (RD-05/RD-09); the project is an integration/productisation effort, not new-algorithm research. Bit-identical reproduction of the reference IPF output is not an objective (it would require the reference IPF binary); correctness is demonstrated against tolerance budgets (clause <5.9>, <6.2>).
Data policy: source code is public (Apache-2.0); raw input data and instrument calibration (ADFs) are private — never committed, never used in public CI. The private calibration set may be held in the project’s Studio VM data store and referenced at run time.
The project is single-developer, Category C; process rigour is achieved through automated tooling and checklists rather than independent organisational roles.
<4.4> Operational environment#
Narrative. sar-processor runs as a batch payload-data processor in a cloud-native Linux
environment. The reference operational and development environment is the EOPF SDE: a container
image based on registry.eopf.copernicus.eu/sde/..., with optional Dask-based parallelism and
object storage (S3-compatible) or POSIX filesystem for Zarr input/output. The same software also
runs locally / on the Studio VM for numerical verification against private real data.
Context (external exchanges). Detailed in the ICD (RD-06):
Direction |
Counterpart |
Exchange |
|---|---|---|
Input |
Upstream L0 production (reception/downlink) |
Level-0 SAR product (SAFE: ISPs + annotation) |
Input |
Auxiliary/calibration store (private, Studio VM) |
AUX_CAL (EAP/AAP/AAEP/K_abs), AUX_INS (roll-steering/decode tables/timeline), AUX_PP1 (processing params), AUX_POE/RES/PRE (orbit), AUX_ATT (attitude), DEM |
Input |
Configuration store |
Per-sensor profile + production parameters |
Output |
Downstream archive / dissemination |
|
Output |
Operations / monitoring |
Processing logs, reports, QA summaries |
Computer infrastructure. Target: x86-64 Linux, multi-core CPU, no GPU required; RAM and storage scale with sub-swath/burst size and chunking; optional Dask cluster for horizontal scaling. Constraint: the public CI runner is a shell executor with no container runtime, Dask gateway or S3 — jobs requiring those are non-blocking in CI, and numerical verification on real data is performed locally / on the Studio VM (clause <6>).
<4.5> Assumptions and dependencies#
A-1 — Level-0 SAR products (ISPs + annotation) are available and well-formed; reception/downlink are done upstream and out of scope.
A-2 — A complete, version-controlled ADF set matching the input’s IPF version exists per profile (AUX_CAL, AUX_INS, AUX_PP1, orbit, attitude, DEM). This data is private and supplied at run time, not embedded in the software.
A-3 — The public algorithm basis (RD-05/RD-09) is correct and sufficient for the targeted accuracy; the project integrates rather than re-derives it.
A-4 —
eopf == 2.8.1(CPM) and the EOPF Zarr data model are stable for the development baseline, and support complex (I/Q) variables and per-burst grouping (or a documented convention exists — tracked as a project risk, RD-03).A-5 — DEM and orbit/attitude auxiliaries cover the processed scene’s footprint and epoch.
A-6 — A reference Sentinel-1 product set (matching L0 + L1 SLC/GRD + ADFs, plus point-target / corner-reflector or stable-σ0 ground truth) is available locally / on the Studio VM for numerical validation (clause <6.2>).
<5> Specific requirements#
<5.1> General#
a. Each system requirement is uniquely identified by a
SYS-<group>-<nn>tag.b. Where requirements are expressed through schemas/models (the profile JSON schema, the CPM computing-model JSON, the EOProduct data model), identifiers are assigned within the schema for traceability.
c. Each requirement is associated with a validation method — T (Test), A (Analysis), I (Inspection), R (Review of design) — baselined at version 1.0 (this issue). The requirement-to-method mapping is consolidated in the project traceability matrix (
compliance/traceability/).
Performance figures that depend on instrument calibration (radiometric, geolocation and focusing budgets) are expressed as per-profile budget parameters (clause <5.9>). Their baseline numerical values are held in the private auxiliary/calibration store and verified locally; the public Sentinel-1 specification values (RD-10) are cited as informative references only.
<5.2> Capabilities requirements#
System behaviour and associated performance, organised by capability (processing stage).
Ingestion & L0 decoding
SYS-CAP-01 — The system shall ingest Level-0 SAR products (ISPs + annotation) and the auxiliary/calibration data resolved by the active profile, and shall reject or flag inputs that fail structural and metadata legality checks before processing. (Validation: T)
SYS-CAP-02 — The system shall decode the compressed Level-0 echo (FDBAQ), reconstruct instrument timing (PRF, SWST, acquisition time) from the ISP secondary headers, detect lost/missing lines, and de-multiplex the stream per sub-swath and polarisation into complex (I/Q) channels, per the DPM (RD-05). (Validation: T)
Focusing to SLC
SYS-CAP-03 — The system shall pre-process the decoded echo (I/Q bias removal, transmitted- replica / internal-calibration reconstruction, missing-line handling) and estimate the Doppler centroid (absolute from orbit/attitude and fine from the data), per the DPM. (Validation: T, A)
SYS-CAP-04 — The system shall focus the echo to a Single Look Complex (SLC) product by range compression and azimuth compression (Range-Doppler Algorithm), preserving phase. Focusing quality shall meet the per-profile impulse-response budgets — resolution
IRW_RG/IRW_AZ, peak side-lobe ratioPSLR, integrated side-lobe ratioISLR— verified on a point-target / corner-reflector response. (Validation: T, A)SYS-CAP-05 — For TOPSAR acquisition modes (e.g. IW/EW), the system shall perform azimuth de-ramp/re-ramp and spectral unfolding, and shall merge focused bursts and sub-swaths (deburst / merge) into a continuous SLC without introducing seams or phase discontinuities across burst overlaps. (Validation: T, A)
SYS-CAP-06 — The SLC product shall be phase-preserving to interferometric grade (
PHASE_PRES): all focusing and calibration operations shall maintain the relative phase required for downstream interferometric use, verified by phase continuity across burst overlaps and (where reference data exist) against the reference product. (Validation: A, T)
Radiometric calibration
SYS-CAP-07 — The system shall radiometrically calibrate the product to the selectable backscatter conventions σ0/β0/γ0 using the calibration look-up tables and applying the elevation-antenna-pattern (gain and phase) and range-spreading-loss corrections, per the DPM and the active profile. Radiometric accuracy shall meet the per-profile budget
RAD_ACCon stable/reference targets. (Validation: T, A)SYS-CAP-08 — The system shall support optional thermal-noise removal (subtract-in-power using the noise vectors), disabled by default; where enabled it shall flag rather than silently clip non-physical (negative) results. The noise-floor
NESZshall be characterisable. (Validation: T, A)
GRD generation and geocoding
SYS-CAP-09 — The system shall generate a Ground Range Detected (GRD) product by range weighting, azimuth multi-looking, TOPSAR de-scalloping, detection (power) and slant-range-to- ground-range projection; the multi-looked product shall meet the per-profile speckle budget
ENL. (Validation: T, A)SYS-CAP-10 — The system shall geocode the product by Range-Doppler terrain correction using orbit and a DEM (GTC; ellipsoid GEC where no DEM is available), meeting the per-profile geolocation budget
ALE_RG/ALE_AZon ground reference (corner reflectors / GCPs). (Validation: A, T)
Version gating, product generation, configuration and orchestration
SYS-CAP-11 — Corrections whose definition depends on the reference processor version shall be IPF-version-gated: the system shall read the input’s IPF version (product manifest) and apply the correction variant valid for that version (e.g. antenna-pattern phase, noise-vector form), within the profile’s
supported_ipf_versionsenvelope. (Validation: T, R)SYS-CAP-12 — The system shall write outputs as cloud-native Zarr
EOProducts conformant to the EOPF data model (AD-05), each carrying acquisition/processing metadata, provenance, and per-pixel QA flags (including no-data, missing-line, black-fill/SWST, saturation, thermal-noise- subtracted, deramp-invalid, layover/shadow, cal-invalid). (Validation: I, T)SYS-CAP-13 — The system shall be sensor-agnostic: all instrument-specific behaviour shall be supplied through the per-sensor profile and the product annotation, with no instrument constants hard-coded in the processing core. (Validation: R, T)
SYS-CAP-14 — Each processing stage shall be implemented as a CPM
EOProcessingUnit; stages shall be runnable individually, as a sub-chain, or as the full L0→GTC chain. (Validation: T)SYS-CAP-15 — The system shall support chunked / per-burst / per-sub-swath processing so that large SAR scenes are processed within bounded memory, optionally distributed via Dask. (Validation: T, A)
Real-time behaviour and constraints. The processor has no hard real-time constraints; it is a throughput-oriented batch component. Timing is expressed as a throughput objective in clause <5.5.2>, not as a real-time deadline. HMI capability and on-board control procedures are not applicable (CLI / Python API only, no on-board element).
<5.3> System interface requirements#
Interface requirements are listed here and detailed in the ICD (RD-06); the IRD (Annex C) states them
at requirement level (REQ-IF-*).
SYS-IF-01 (software interfaces) — The system shall expose its capabilities through a Python API built on the CPM (
EOProcessingUnit,EOProduct,EOZarrStore) and a command-line interface for batch invocation. (Validation: T, I)SYS-IF-02 (data — input) — The system shall consume Level-0 SAR products and ADFs in the formats defined in the ICD; the profile and the product annotation/IPF-version select the concrete sources and versions. (Validation: T)
SYS-IF-03 (data — output) — The system shall produce
SLC/GRD/GTCEOProducts as Zarr stores on object storage (S3-compatible) or POSIX filesystem, per the ICD. (Validation: T, I)SYS-IF-04 (communication / storage) — Storage and (optional) Dask cluster interfaces shall be configurable (endpoint, credentials via environment/CI variables) and shall not require a resident network service for single-host operation. (Validation: T)
SYS-IF-05 (HMI) — Human interaction shall be limited to the CLI, configuration files and logs/reports; no graphical user interface is provided. (Validation: I)
<5.4> Adaptation and missionization requirements#
SYS-ADP-01 — All data that varies by sensor or acquisition mode shall be externalised into the profile, including at least: carrier frequency / wavelength; acquisition mode; polarisation channels; sub-swath static definitions (nominal incidence, PRF band); the ADF bindings (AUX_CAL, AUX_INS, AUX_PP1, orbit, attitude, DEM by URI); the supported-IPF-version envelope; and per-stage processing parameters/toggles. (Validation: R, T)
SYS-ADP-02 — Per-acquisition varying parameters — azimuth steering rate, Doppler-centroid and azimuth-FM-rate polynomials, burst times, SWST, calibration/noise LUTs — shall be read from the product annotation at run time and shall not be stored in the profile or hard-coded. (Validation: T, R)
SYS-ADP-03 — Site- and epoch-dependent data (DEM, orbit, attitude) shall be selected by reference from the profile / run configuration, not embedded in the software. (Validation: T)
SYS-ADP-04 — The profile schema shall be versioned and validated at load time; an invalid or incomplete profile shall cause a controlled, reported failure before processing. (Validation: T)
The auxiliary/calibration store acts as the “system database” of ECSS-E-ST-40 5.2.4.4; it is private and out of the source repository (clause <4.3>). The annotation-vs-ADF split (per-acquisition vs sensor/version constants) is a defining SAR characteristic and is enforced at this level.
<5.5> Computer resource requirements#
<5.5.1> Computer hardware resource requirements#
SYS-RES-01 — The system shall run on x86-64 Linux with a multi-core CPU and shall not require a GPU. (Validation: T)
SYS-RES-02 — The system shall operate against object storage (S3-compatible) or a POSIX filesystem for input/output; no other specialised hardware is required. (Validation: T)
<5.5.2> Computer hardware resource utilization requirements#
SYS-RES-03 — Peak memory shall be bounded by the configured chunk granularity (per burst / per sub-swath) so that a datatake is processed within a per-worker memory budget
MEM_BUDGET. (Validation: A, T)SYS-RES-04 — End-to-end L0→GTC throughput shall meet the per-profile objective
THRU_SCENE(datatakes or km²/hour on a stated reference configuration), measured locally. (Validation: A, T)
<5.5.3> Computer software resource requirements#
SYS-RES-05 — The system shall run on Python 3.11 with EOPF CPM
eopf == 2.8.1and its declared dependency stack (numpy, xarray, zarr, Dask, and the SAR numerical additions — FFT backend — recorded in the SRF (RD-04) andpyproject.toml). No proprietary runtime is required. (Validation: I, T)
<5.6> Security requirements#
SYS-SEC-01 — Source code shall be public under Apache-2.0; raw input data and instrument calibration ADFs shall remain private and shall never be committed to the repository nor used in public CI. (Validation: I, R)
SYS-SEC-02 — Credentials and access tokens (storage, registry, Dask, Studio VM) shall be provided exclusively via environment / CI variables and shall never appear in source or product artefacts. (Validation: I, T)
SYS-SEC-03 — Access to the private auxiliary/calibration store (Studio VM data store) shall be controlled and independent of the public code repository. (Validation: R)
<5.7> Safety requirements#
SYS-SAF-01 — The product is a ground-segment data processor with no command authority over the space segment and no direct human-safety hazard; therefore no safety-critical functions are defined. The principal residual hazard class is product-data integrity (e.g. a mislabelled, mis-calibrated or phase-corrupted product); this shall be mitigated by QA flags, provenance metadata and fail-stop behaviour (SYS-CAP-12, SYS-OPS-02). (Validation: R)
<5.8> Reliability and availability requirements#
SYS-RAM-01 — Processing shall be deterministic and reproducible: identical inputs, auxiliary data, profile version and processor version shall yield identical products (bit-identical where the operation is deterministic — e.g. FDBAQ decode; otherwise within a documented numerical tolerance — e.g. FFT-based focusing). (Validation: T, A)
SYS-RAM-02 — Processing shall be resumable / re-runnable at stage granularity; a failed run shall not leave a partial product presented as complete. (Validation: T)
SYS-RAM-03 — Service availability is a property of the hosting ground segment, not of this batch component; no continuous-availability target is levied on the software itself. (Validation: R)
<5.9> Quality requirements#
SYS-QUA-01 — The software shall conform to ECSS-Q-ST-80C Rev.2 for Category C and to the project coding standards enforced by the toolchain (black, isort, flake8, mypy, bandit, xenon). (Validation: I)
SYS-QUA-02 — Automated test coverage shall meet the project gate (inherited EOPF threshold), measured by the unit-test CI job. (Validation: T)
SYS-QUA-03 — The software shall be portable / relocatable between the EOPF SDE, the Studio VM and a local workstation without code changes (configuration only). (Validation: T, I)
SYS-QUA-04 — Numerical product-quality objectives shall be met per the following per-profile budget parameters, validated locally on mission-representative real data (informative public Sentinel-1 reference values in brackets, RD-10):
focusing:
IRW_RG/IRW_AZ(resolution),PSLR(≈ −13.3 dB unweighted point target; deeper with the product’s weighting window),ISLR;geolocation:
ALE_RG/ALE_AZ(target ≤ ~1 pixel with precise orbit);radiometry:
RAD_ACC(≈ 1 dB, 3σ),NESZ(≤ ~ −22 dB);speckle:
ENL(≈ nominal number of looks);phase:
PHASE_PRES(interferometric-grade phase continuity). (Validation: A, T)
SYS-QUA-05 — Maintainability shall be supported by reusability of the generic chain across profiles and by bounded cyclomatic complexity (xenon thresholds). (Validation: I, A)
<5.10> Design requirements and constraints#
SYS-DES-01 (architecture) — Each processing stage shall be a CPM
EOProcessingUnitand products shall beEOProductinstances; the architecture shall be a config-driven, sensor-agnostic pipeline with a framework-free algorithmic core per stage. (Validation: R)SYS-DES-02 (standards) — The software shall conform to the ECSS-E-ST-40C / Q-ST-80C tailoring in the SDP (AD-04) and to PEP 8 (enforced by the toolchain). (Validation: I)
SYS-DES-03 (existing components / COTS) — The software shall reuse EOPF CPM, numpy, xarray, zarr, Dask and a declared FFT backend per the SRF (RD-04); no customer-furnished components are levied. (Validation: I)
SYS-DES-04 (data standard) — Outputs shall use Zarr with EOPF/CF-style metadata and STAC- compatible cataloguing fields (RD-08, AD-05); complex (I/Q) SLC variables and per-burst grouping shall follow a documented convention. (Validation: I, T)
SYS-DES-05 (language / version pin) — Implementation shall be Python 3.11 with
eopf == 2.8.1pinned. (Validation: I)SYS-DES-06 (naming) — Product, variable and metadata naming shall follow the EOPF data-model and the S1 SAFE-naming conventions. (Validation: I)
SYS-DES-07 (flexibility and expansion) — Adding a new sensor/mode shall be achievable by adding a profile (and its private auxiliaries) without modifying the processing core. (Validation: T, R)
SYS-DES-08 (data confidentiality) — No raw or calibration data shall be required at build time or embedded in any delivered artefact. (Validation: I)
Utilization of HMI standards is not applicable (no GUI).
<5.11> Software operations requirements#
SYS-OPS-01 — The system shall be operable as a batch job (CLI or Python API), invoked with a profile, an input reference and an auxiliary-data reference, optionally restricted to a single stage, a sub-chain, or a production mode (nominal / calibration). (Validation: T)
SYS-OPS-02 — Each run shall emit structured logs and a processing report sufficient to determine success/failure, parameters used and product provenance (including the IPF version applied); on failure it shall exit non-zero and shall not publish a misleading product. (Validation: T)
<5.12> Software maintenance requirements#
SYS-MNT-01 — Maintenance shall be performed under a GitLab issue → branch → merge-request workflow with SemVer releases, by the single developer acting in the supplier roles. (Validation: R)
SYS-MNT-02 — Calibration/auxiliary and IPF-version-gating updates shall be deliverable by replacing the referenced private data / extending the version envelope, without changing the processing core (clause <5.4>). (Validation: T, R)
SYS-MNT-03 — A documented procedure shall govern bumping the pinned
eopfversion and re-running the full V&V before re-baselining. (Validation: R)
<5.13> System and software observability requirements#
SYS-OBS-01 — The system shall record, in the product and/or report, the processing chain version, profile version, ADF versions, the input IPF version applied, and key parameters (processing provenance) so that any product can be reproduced. (Validation: I, T)
SYS-OBS-02 — Per-pixel QA flags and per-stage quality indicators (focusing metrics, saturation, missing lines, black-fill, thermal-noise-subtracted, layover/shadow, no-data) shall be carried through to the output product. (Validation: T)
SYS-OBS-03 — Unit and integration test reports shall be generated and published with the documentation (SUITR). (Validation: I)
<5.14> Security constraints for the software development and integration environment#
SYS-DEVSEC-01 — Development and integration shall use the self-hosted EOPF SDE GitLab; CI shall run on the SDE shell executor with secrets injected as masked CI variables. (Validation: I)
SYS-DEVSEC-02 — The CI pipeline shall run dependency and code security scanning (bandit, Trivy) and quality gating (SonarQube); private real data shall never be introduced into the CI environment. (Validation: I, T)
SYS-DEVSEC-03 — Pre-commit hooks shall enforce hygiene (formatting, large-file and secret-leak prevention) before code enters the repository. (Validation: I)
<5.15> Secure software delivery requirements#
SYS-DEL-01 — Releases shall be delivered as versioned Python wheels published to the GitLab package registry and as versioned documentation via GitLab Pages, built reproducibly by CI from a tagged commit. (Validation: T, I)
SYS-DEL-02 — Delivered artefacts shall contain no private data; integrity is anchored to the Git tag and registry record of the delivered version (cf. SCF / SRN). (Validation: I)
<6> Verification, validation and system integration#
<6.1> Verification and validation process requirements#
SYS-VV-01 — The V&V process shall combine T/A/I/R methods (clause <5.1>): automated unit/integration tests, static analysis, design/inspection review against this SSS, and numerical analysis against the DPM/ATBD (RD-05). (Validation: R)
SYS-VV-02 — Public CI shall execute all tests that do not require private data, a container runtime, a Dask gateway or S3 — including a synthetic point-target focusing test (Tier A) that needs no private data; tests needing those shall be marked non-blocking in CI and executed locally. (Validation: I)
SYS-VV-03 — Security V&V (dependency/code scanning, secret-leak prevention, confidentiality of private data) shall be part of the V&V process. (Validation: I, T)
<6.2> Validation approach#
SYS-VV-04 — The software shall be validated against this requirements baseline and the DPM/ATBD using mission-representative real Sentinel-1 data, processed locally / on the Studio VM. For the first sensor profile, focusing quality shall be validated on a synthetic point-target impulse response (
PSLR/ISLR/IRW) and on real corner-reflector / bright-target responses; SLC/GRD/GTC outputs shall be compared against the reference Sentinel-1 products within the clause <5.9> tolerance budgets (amplitude correlation, burst-overlap phase continuity, σ0 over stable targets, ALE on corner reflectors). Bit-identical reproduction is explicitly not required. Operational procedures (CLI runs, configuration, modes) shall be exercised as part of validation. (Validation: A, T)
<6.3> Validation requirements#
SYS-VV-05 — Each requirement in clause <5> shall carry a validation method (assigned inline and consolidated in the traceability matrix). A requirement excluded from validation against the baseline shall be explicitly identified there with rationale. (Validation: R)
<6.4> Verification requirements#
SYS-VV-06 (installation & acceptance) — Clean installation (
pip install) into the SDE / Studio VM and a local environment, and successful execution of the acceptance test set, shall be verified. (Validation: T, I)SYS-VV-07 (versions, content, medium) — The delivered versions, their content and medium (Zarr
EOProducts, Python wheel, versioned documentation) shall be verified against the SCF / SRN. (Validation: I)SYS-VV-08 (integration support) — The single developer shall provide the support needed for integration of the product into the ground segment / SDE. (Validation: R)
SYS-VV-09 (exchanged-data format & medium) — The format and delivery medium of all exchanged data — input L0 (SAFE), private ADFs, and output products — shall be verified against the ICD (RD-06). (Validation: I, T)
<7> System models#
Formal system-specification-language models (computational, data, event, failure) are tailored out for this Category C, single-developer project. The role of the system model is served by concrete project artefacts, maintained as the design matures:
the EOProcessingUnit pipeline graph (functional/processing model) — detailed in the SDD;
the per-sensor profile schema (configuration/data model) — clause <5.4>;
the EOProduct / Zarr data model (product data model, AD-05), including the complex-SLC / per-burst convention — referenced by the ICD;
the DPM / ATBD (RD-05) as the algorithm/behavioural model per processing stage.
No schedulability analysis or model checking is required (no real-time or on-board element, clause <5.2>).
End of SSS. Authored per ECSS-E-ST-40C Rev.1 Annex B.