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
msi-processorand, together with the ICD, 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).
<1> Introduction#
Purpose. This document specifies, at system level, the msi-processor software product: a
generic, high-resolution pushbroom multispectral imager (MSI) ground-segment data processor.
It transforms downlinked RAW (Level-0) MSI data into Level-2 products through radiometric,
geometric and atmospheric correction. 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
(which is 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 processing chain’s mathematical basis already exists in prior work (referenced via the SRF and the Detailed Processing Model, RD-04/RD-05) and is not new-algorithm research. The SSS exists to turn that prior algorithmic basis plus the EOPF platform into a documented, verifiable, configuration-driven product. The chain is sensor-agnostic, driven by a per-sensor configuration profile; the first profile instantiated is the project owner’s own sensor.
<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 |
|
|
RD-06 |
|
|
RD-07 |
EOPF CPM API documentation |
EOPF CPM API ( |
RD-08 |
Cloud-native data conventions |
Zarr v2/v3, CF metadata, STAC |
<3> Terms, definitions and abbreviated terms#
Only terms not already defined in the AD/RD are listed.
Term / abbr. |
Definition |
|---|---|
MSI |
Multispectral imager (pushbroom / along-track scanning instrument) |
Profile |
Per-sensor configuration set (bands, geometry, calibration references, processing parameters, output grid) that specialises the generic chain for one instrument |
L0 / L0c |
Level-0 / consolidated Level-0: decompressed, source-packet-reassembled raw instrument data with ancillary and telemetry |
L1A |
Reformatted, geo-annotated detector samples in instrument (focal-plane) geometry, radiometrically uncorrected |
L1B |
Radiometrically corrected at-sensor product (top-of-atmosphere radiance) in instrument geometry |
L1C |
Geometrically corrected, orthorectified top-of-atmosphere reflectance on a cartographic grid |
L2A |
Atmospherically corrected bottom-of-atmosphere (surface) reflectance with scene classification and cloud/shadow masks |
TOA / BOA |
Top-of-atmosphere / bottom-of-atmosphere |
NUC / PRNU / DSNU |
Non-uniformity correction / photo-response non-uniformity / dark-signal non-uniformity |
SRF |
Spectral response function (instrument); also Software Reuse File (RD-04) where stated |
AOT |
Aerosol optical thickness |
DEM |
Digital elevation model |
CRS |
Coordinate reference system |
QA |
Quality assurance / quality indicators (per-pixel flags and masks) |
CPM |
EOPF Core Python Modules (the |
EOProduct / EOProcessingUnit |
CPM in-memory product object / CPM processing-stage unit |
Zarr |
Cloud-native chunked array storage format (product output format) |
EOPF |
Earth Observation Processing Framework (ESA) |
SDE |
The EOPF cloud development and processing environment (GitLab + Studio + Dask gateway + object storage), per CI image |
DPM |
Detailed Processing Model (RD-05) — the algorithm theoretical basis per processing level |
T / A / I / R |
Validation/verification methods: Test / Analysis / Inspection / Review of design |
<4> General description#
<4.1> Product perspective#
msi-processor is a software product within an Earth-observation ground segment. In the wider
mission, a high-resolution pushbroom MSI satellite acquires multispectral imagery and downlinks
RAW data to the ground; the ground segment ingests, archives and processes that data into
user-facing products. msi-processor occupies the payload data processing function of that
ground segment: it consumes consolidated Level-0 (L0c) raw MSI data plus auxiliary/calibration
data and produces calibrated, orthorectified, atmospherically corrected products up to Level-2.
The product is sensor-agnostic by design: the processing chain is fixed, while the instrument-specific behaviour is supplied as a per-sensor profile. This allows the same software to serve multiple MSI instruments; the first instantiated profile is the project owner’s own sensor.
The product does not replace a specific legacy system; it is a new, EOPF-native
implementation. Where a prior reference processor exists for a given sensor, that reference is used
for numerical cross-validation (clause <6.2>) rather than being replaced in place. Upstream
(reception, demodulation, decompression to L0c) and downstream (archiving, cataloguing,
dissemination) ground-segment functions are external to this product and are not specified here.
<4.2> General capabilities#
The software provides the end-to-end raw→L2 capability, decomposed by processing level:
Ingestion of
L0/L0craw MSI data and the associated auxiliary/calibration data selected through the active profile.Radiometric correction (L0 → L1B): dark/offset subtraction, non-uniformity / flat-field correction (PRNU/DSNU), gain application to physical radiance, defective-pixel detection and handling, per-detector / per-band assembly.
Geometric correction (L1B → L1C): application of the viewing/geometric model, DEM-based orthorectification, resampling to a cartographic grid, geolocation and inter-band co-registration.
Atmospheric correction (L1C → L2A): retrieval or ingestion of atmospheric parameters (AOT, water vapour), conversion to bottom-of-atmosphere reflectance, scene classification and cloud / cloud-shadow masking.
Product generation: output of cloud-native Zarr
EOProducts conformant to the EOPF data model, carrying metadata, processing provenance and per-pixel QA flags.Configuration / profile management: a single mechanism that specialises the generic chain for one sensor and one production scenario.
Pipeline orchestration: each level is realised as a CPM
EOProcessingUnit; stages are chainable, individually runnable and chunked for 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). The processor is a non-resident batch component — there is no continuous resident or real-time mode.
<4.3> General constraints#
The following items constrain the supplier’s design and development options and are therefore fixed at system level (detailed as requirements in clause <5.10>):
The product shall be built on the EOPF CPM (
EOProcessingUnit,EOProduct) pinned toeopf == 2.8.1, matching the SDEcpm-build-environmentimage.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 existing mathematical basis (RD-05); the project is an integration/productisation effort, not new-algorithm research.
Data policy: source code is public (Apache-2.0); raw input data and instrument calibration (gain/offset, dark, flat-field, geometric/atmospheric auxiliaries) are private — never committed, never used in public CI.
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. msi-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/cpm-build-environment, with optional
Dask-based parallelism (Dask gateway/cluster) and object storage (S3-compatible) or POSIX
filesystem for Zarr input/output. The same software also runs locally on a developer workstation
for numerical verification against private real data.
Context (external exchanges). The processor exchanges data with the following external ground-segment actors (detailed in the ICD, RD-06):
Direction |
Counterpart |
Exchange |
|---|---|---|
Input |
Upstream L0 production (reception/decompression) |
|
Input |
Auxiliary/calibration store (private) |
Gain/offset, dark, flat-field/NUC tables, spectral response, geometric/viewing model, DEM, atmospheric auxiliaries |
Input |
Configuration store |
Per-sensor profile + production parameters |
Output |
Downstream archive / dissemination |
|
Output |
Operations / monitoring |
Processing logs, reports, QA summaries |
Activities supported by external systems. Upstream systems perform satellite contact,
demodulation, decompression and L0c consolidation; downstream systems perform archiving,
cataloguing and user dissemination; the auxiliary/calibration store is maintained by the
instrument calibration process (private). These activities are not in the scope of this product.
Interface documents. External interfaces are defined in the ICD (RD-06); this SSS lists the interface requirements in clause <5.3> and refers to the ICD for their detailed design.
Computer infrastructure. Target: x86-64 Linux, multi-core CPU, no GPU required; RAM and storage scale with tile 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 (clause <6>).
<4.5> Assumptions and dependencies#
The specific requirements rely on the following assumptions (risks of invalidity are tracked in the project risk register per RD-03):
A-1 — Consolidated Level-0 (
L0c) is available and well-formed; reception/decompression are done upstream and out of scope.A-2 — A complete, version-controlled auxiliary/calibration set exists per profile (gain, dark, flat-field, spectral response, geometric model, DEM, atmospheric auxiliaries). This data is private and supplied at run time, not embedded in the software.
A-3 — The pre-existing algorithm mathematical basis (RD-05) 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.A-5 — DEM and atmospheric auxiliary coverage exist for the processed scene’s footprint and epoch.
A-6 — Reference products / cal-val targets are available locally for the first sensor profile to support 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 (e.g. the profile JSON/YAML schema or 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) — and is 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 spectral accuracy budgets) are expressed as per-profile budget parameters. Their baseline numerical values are held in the private auxiliary/calibration repository and verified locally; they are not reproduced here, in conformance with the data policy (clause <4.3>).
<5.2> Capabilities requirements#
System behaviour and associated performance, organised by capability (processing level).
Ingestion
SYS-CAP-01 — The system shall ingest
L0/L0craw MSI data 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)
Radiometric correction (L0 → L1B)
SYS-CAP-02 — The system shall perform radiometric correction comprising dark/offset subtraction, non-uniformity / flat-field correction (PRNU/DSNU), gain application to physical TOA radiance, and defective-pixel detection and handling, per the DPM (RD-05) and the active profile. (Validation: T, A)
SYS-CAP-03 — Radiometric output (L1B) shall meet the per-profile radiometric accuracy budget
RAD_ACCwhen processing reference inputs, verified locally on real data. (Validation: A, T)
Geometric correction (L1B → L1C)
SYS-CAP-04 — The system shall geometrically correct the product by applying the viewing / geometric model, performing DEM-based orthorectification, resampling to the profile-defined cartographic grid and CRS, and co-registering bands. (Validation: T, A)
SYS-CAP-05 — Geolocation error of the L1C product shall meet the per-profile budget
GEO_CE90(circular error, 90 %), and inter-band co-registration shall meetBAND_COREG, verified locally against ground reference. (Validation: A, T)
Atmospheric correction (L1C → L2A)
SYS-CAP-06 — The system shall perform atmospheric correction to bottom-of-atmosphere (surface) reflectance, retrieving or ingesting atmospheric parameters (AOT, water vapour) per the DPM and profile. (Validation: T, A)
SYS-CAP-07 — The system shall produce a scene classification and cloud / cloud-shadow mask as part of the L2A product. (Validation: T)
Product generation, configuration and orchestration
SYS-CAP-08 — The system shall write outputs as cloud-native Zarr
EOProducts conformant to the EOPF data model (AD-05), each carrying acquisition/processing metadata, processing provenance, and per-pixel QA flags. (Validation: I, T)SYS-CAP-09 — The system shall be sensor-agnostic: all instrument-specific behaviour shall be supplied through the per-sensor profile, with no instrument constants hard-coded in the processing core. (Validation: R, T)
SYS-CAP-10 — Each processing level shall be implemented as a CPM
EOProcessingUnit; stages shall be runnable individually (a single level), as a sub-chain, or as the full raw→L2 chain. (Validation: T)SYS-CAP-11 — The system shall support chunked / tiled processing so that large 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 (OBCP) are not applicable: the product has no graphical HMI (CLI / Python API only, clause <5.3>) and no on-board element.
<5.3> System interface requirements#
Interface requirements are listed here and detailed in the ICD (RD-06).
SYS-IF-01 (software interfaces) — The system shall expose its capabilities through a Python API built on the CPM (
EOProcessingUnit,EOProduct, EOPF Zarr store) and a command-line interface for batch invocation. (Validation: T, I)SYS-IF-02 (data — input) — The system shall consume
L0/L0cproducts and auxiliary / calibration data in the formats defined in the ICD; the profile selects the concrete sources and versions. (Validation: T)SYS-IF-03 (data — output) — The system shall produce
L1B/L1C/L2AEOProducts 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 production scenario shall be externalised into the profile, including at least: band list and centre wavelengths / spectral response references; detector and focal-plane geometry; references to calibration tables (gain, dark, flat-field/NUC); viewing/geometric model reference; output CRS, grid, resolution and tiling; per-stage processing parameters and toggles. (Validation: R, T)
SYS-ADP-02 — Site- and epoch-dependent data (DEM, atmospheric auxiliaries) shall be selected by reference from the profile / run configuration, not embedded in the software. (Validation: T)
SYS-ADP-03 — 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>).
<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/tile size so that a scene can be processed within a per-worker memory budget
MEM_BUDGETdefined in the profile/run configuration. (Validation: A, T)SYS-RES-04 — End-to-end raw→L2 throughput shall meet the per-profile objective
THRU_SCENE(scenes 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 (xarray, zarr, numpy, Dask), as 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 data 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, SonarQube) 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 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 or silently corrupted product); this shall be mitigated by QA flags, provenance metadata and fail-stop behaviour (SYS-CAP-08, SYS-OPS-02). (Validation: R)
<5.8> Reliability and availability requirements#
SYS-RAM-01 — Processing shall be deterministic and reproducible: identical inputs, auxiliary data and profile version shall yield identical products. (Validation: T, A)
SYS-RAM-02 — Processing shall be resumable / re-runnable at processing-level 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 and a local workstation without code changes (configuration only). (Validation: T, I)
SYS-QUA-04 — Numerical product-quality objectives (radiometric, geolocation, spectral fidelity) shall be met per the per-profile budgets referenced in clause <5.2>, validated locally on mission-representative real data. (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#
At least the following constrain the design and production of the system:
SYS-DES-01 (architecture) — Each processing level shall be a CPM
EOProcessingUnitand products shall beEOProductinstances; the architecture shall be a config-driven, sensor- agnostic pipeline. (Validation: R)SYS-DES-02 (standards) — The software shall conform to 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, xarray, zarr, numpy and Dask 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). (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 conventions. (Validation: I)
SYS-DES-07 (flexibility and expansion) — Adding a new sensor 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 processing level or sub-chain. (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; on failure it shall exit with a non-zero status and shall not publish a misleading product. (Validation: T)
The supplier’s operational response is the SUM / operations documentation; this clause states the operational requirements only.
<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 updates shall be deliverable by replacing the referenced private data, without changing the software (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)
No in-flight / in-orbit modification capability is required (ground software).
<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, auxiliary-data versions 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 (e.g. saturation, defective pixels, no-data, cloud) 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 (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; 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 using mission-representative real data and scenarios, processed locally. For the first sensor profile, L1B/L1C/L2A outputs shall be compared against reference products and/or cal-val targets (radiometric, geolocation, surface-reflectance accuracy). Operational procedures (CLI runs, configuration) 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#
The SSS levies verification requirements for:
SYS-VV-06 (installation & acceptance) — Clean installation (
pip install) into the SDE 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
L0c, private auxiliaries, 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) — referenced by the ICD;
the DPM (RD-05) as the algorithm/behavioural model per processing level.
No schedulability analysis or model checking is required (no real-time or on-board element, clause <5.2>).