SRS (Software Requirements Specification)

advertisement
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
1 of 16
EarthCARE Level 2 Documentation
ACM-CAP
Cloud and Precipitation Best Estimate
Software Requirements Specification
(SRS)
VARSY Project
Code:
Issue:
Date:
Reference:
L2-ACM-CAP-SRS
0.1
27/08/2012
Name
Function
Prepared by
Robin Hogan
Project Scientist
Reviewed by
Pavlos Kollias
Project Scientist
Approved by
Pavlos Kollias
Project Manager
Signatures and approvals on original
Signature
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
2 of 16
This page intentionally left blank
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
3 of 16
Document Information
Contract Data
Contract Number:
4000104528/11/NL/CT
Contract Issuer:
ESA-ESTEC
Internal Distribution
Name
Unit
Copies
Pavlos Kollias
McGill University
1
Aleksandra Tatarevic
McGill University
1
Wanda Szyrmer
McGill University
1
Internal Confidentiality Level
Unclassified

Restricted
Confidential


External Distribution
Name
Organisation
Copies
Tobias Wehr
ESA-ESTEC
1
Michael Eisinger
ESA-ESTEC
1
Dulce Lajas
ESA-ESTEC
1
Robin Hogan
University of Reading
1
LATMOS
1
Gerd-Jan van Zadelhof
KNMI
1
David Donovan
KNMI
1
University of Leicester
1
Julien Delanoë
Alessandro Battaglia
Archiving
Word Processor:
MS Word 2003
File Name:
VARSY-READING-SRS-001
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
4 of 16
Document Status Log
Issue
01-draft
Change description
Draft version.
Date
Approved
25/08/2012
Contents
1. Purpose and Scope.............................................................................................................................. 6
1.1. Applicable Documents ................................................................................................................. 6
1.2. Reference Documents.................................................................................................................. 7
1.3. List of Abbreviations .................................................................................................................... 8
2. Compliance Matrix .............................................................................................................................. 9
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
5 of 16
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
6 of 16
1. PURPOSE AND SCOPE
This document specifies the software requirements associated with the implementation of the
ACM-CAP L2b algorithm.
1.1. Applicable Documents
Table 1: Applicable Documents
Reference
Code
Title
Issue
[SOW]
EC-SW-ESA-SY-0310
Statement of Work: VARSY - 1-Dimensional
VARiational Retrieval of SYnergistic
EarthCARE Products
1.0
[CC]
Appendix 2 to
AO/1-6823/11/NL/CT
Draft Contract (attachment to SOW)
1.0
[AD 1]
EC-SW-ESA-SY-0152
EarthCARE Level 2 Processor Development
1.0
General Requirements Baseline
[AD 2]
EC.ICD.ASD.SY.00004
EarthCARE Product Definitions. Vol. 0:
Introduction
[AD 3]
EC.ICD.ASD.SY.00005
EarthCARE Product Definitions. Vol. 1:
1.0
Common Product Definitions
[AD 4]
EC.ICD.ASD.ATL.00021
EarthCARE Product Definitions. Vol. 2b:
1.0
ATLID level 1
[AD 5]
EC.ICD.ASD.BBR.00022
EarthCARE Product Definitions. Vol. 3b:
1.0
BBR level 1
[AD 6]
EC.ICD.ASD.MSI.00023
EarthCARE Product Definitions. Vol. 4b:
1.0
MSI level 1
[AD 7]
ECSIM-DMS-TEC-ICD01-R
ECSIM Simulator Interface Control Document
[AD 8]
PE-TN-ESA-GS-0001
Ground Segment: File Format Standard
1.0
[AD 9]
EC-TN-ESA-GS-0218
Tailoring of the Earth Explorer File Format
Standard for the EarthCARE Ground Segment
2.0
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
7 of 16
1.2. Reference Documents
Table 2: Reference Documents
Reference
Code
Title
[RD1]
ECSIM-DMS-TEC-SUM-01-R
ECSIM System User Manual
[RD2]
ECSIM-KNMI-MAD01-R
ECSIM Model and Algorithms Document
[RD3]
EE-MA-DMS-GS-0001
Earth Explorer Mission CFI Software:
Issue
General Software User Manual
[RD4]
EOP-SM/1567/TW
[ATLAS-FR] EC-FR-KNMI-ATL-027
EarthCARE Mission Requirements Document
ATLAS Final report
[ATLASACM-TC]
EC-TN-KNMI-ATL-ACM-TC-024 L2b Classification ATBD
[ATLASEBD]
EC-TN-KNMI-ATL-ATBD-A-EBD- L2a ATLID Extinction, Backscatter and
021
Depolarization algorithm ATBD
[ATLAS-FM] EC-TN-KNMI-ATL-ATBD-A-FM- L2a ATLID Feature mask ATBD
010
[RATEC-FR] RATEC-FR-READING-1
RATEC Final Report
1.0
1.2
13/03/08
1.1
27/04/09
2.2
1.0, April
2011
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
8 of 16
1.3. List of Abbreviations
Table 3: List of abbreviations
Abbreviation
Name
1D-VAR RS
1-dimensional variational retrieval scheme
ATLID
Atmospheric Lidar (The EarthCARE lidar)
CASPER
Cloud and Aerosol Synergetic Products from EarthCARE retrievals
CPR
Cloud Precipitation Radar (The EarthCARE radar)
EarthCARE
The Earth Clouds, Aerosols and Radiation Explorer
ECSIM
EarthCARE Simulator
HSRL
High-Spectral Resolution Lidar
MSI
Multi-spectral Imager (The EarthCARE imager )
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
9 of 16
2. COMPLIANCE MATRIX
The following table lists all the requirements in the General Requirements Baseline [AD1] related
to the software and the degree of compliance with each requirement.
*C=compliant, P=partly non-compliant, N=not compliant, NY=not yet compliant but will be,
NA=Not applicable
Reference Requirement
Implementation Compliance*
Design Requirements
DES-1
The level 2 processor shall be implemented as a
set of independent executable entities, referred to
below as level 2 modules, each one implementing
a specific algorithm generating a specific level 2
data product.
The ACM-CAP
is implemented
as a standalone
executable
C
DES-2
No proprietary libraries or code shall be used
Libraries used: C
GNU Scientific
Library (GPL),
LIDORT
(permissive
open source
license),
“Adept”
automatic
differentiation
library (GPL),
Multiscatter
library (LGPL);
note that Hogan
is copyright
holder for
“Adept” and
“Multiscatter”;
Mishchenko’s
T-matrix code
(permissive
BSD license);
BHMIE does
not specify a
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
10 of 16
license so have
emailed Bruce
Draine.
DES-3
Only portable libraries or code shall be used.
In this context, "portable" means that any
libraries or code invoked within a level 2 module,
including bespoke libraries and code, must not
depend on any special features of, e.g., the
operating system, the compiler, the specific
programming language implementation on the
development or target platform.
The ACM-CAP N
currently uses
an extension of
the GNU C++
compiler in
permitting
variable-length
arrays (a C
feature) in
C++.
Functional Requirements
FUN-1
Level 2 modules shall derive geophysical
See associated
quantities (level 2 data products) from
ATBD
EarthCARE level 1b data products. Synergistic
(level 2b) modules may use EarthCARE level 2
data products on input as well (see also INT-10).
C
FUN-2
Level 2 modules shall implement the algorithm
specified in the corresponding ATBD.
C
FUN-3
Level 2 modules shall compute and store into
products: geophysical parameters, error
descriptors and product confidence data (i.e.,
quality flags).
FUN-4
Level 2 modules shall check whether all required
data are available before running.
FUN-5
Level 2 modules shall respond in a controlled
way to instrument degradation or failure or
unexpected values in the input data as per INT10.
FUN-6
Convergence criteria shall be established for
The
C
each algorithm. These criteria shall be monitored convergence
during the execution of the algorithm. Abortion
criterion is that
See associated
PDD
C
C
Meaningful
C
errors are
reported and
program
gracefully exits
if appropriate
in response to
missing or
corrupt data
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
11 of 16
criteria shall be established and applied for
deviation from accepted convergence profile.
Respective error information shall be produced.
the L2 norm of
the gradient of
the cost
function falls to
less than unity.
If this is not
reached in a
specified
number of
iterations, the
algorithm
aborts. Error
and
convergence
information is
reported
FUN-7
Level 2 modules shall provide a trace of their
execution in a single Log File for each execution
run.
C
FUN-8
The configuration files of a level 2 module shall See associated
allow to configure the logging level of the level 2 ICD
module.
C
FUN-9
The following logging levels shall be supported
for a level 2 module: Error, Warning, Info,
Debug, Progress.
See associated
ICD
C
FUN-10
An Error shall be logged when an unexpected
condition was detected and the
level 2 module cannot perform any error
recovery and must exit.
See associated
ICD
C
FUN-11
A Warning shall be logged when an unexpected
condition was detected but error recovery is
possible.
See associated
ICD
C
FUN-12
An Info shall be logged when a significant
condition occurred that directly or indirectly
affects the level 2 module outputs. An info shall
also be logged at module startup and module
termination.
See associated
ICD
C
FUN-13
Debug should be used as needed for the
development of the Level 2 module.
See associated
ICD
C
FUN-14
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
12 of 16
Progress shall be used to log the progress of the
simulation from 0% to 100%, exploiting the
processing steps of level 2 modules.
See associated
ICD
C
Interface Requirements
INT-1
The Unix operating system shall be used. The
Code developed C
actual hardware/operating system
under Linux
configuration shall be PC (multi-core/multiprocessor system if needed)/Linux. Details
(including the Linux distribution and its version)
shall be agreed with the agency.
INT-2
Coding shall be performed in a high-level
programming language such as C/C++
or Fortran-90. Details (including compiler
versions) shall be agreed with the Agency.
INT-3
Compilation options and compiler versions shall GNU compiler
be documented and justified.
collection is
needed
C
INT-4
Each level 2 module shall be able to run standalone.
C
INT-5
Besides being able to run stand-alone, Level 2
Not yet
modules shall be compatible with and run within
the EarthCARE end-to-end simulator ECSIM.
NY
INT-6
Input to and output from level 2 modules shall be
performed via files.
C
INT-7
In addition, level 2 modules shall use Unix
standard output for status messages.
INT-8
Level 2 modules shall not use Unix standard
input.
C
INT-9
Level 2 modules shall not produce graphical
output. Graphical output (e.g. for quicklook
results) may be produced from additional tools.
C
C (1990
C
standard), C++
(1998 standard)
and Fortran
(1977 and 1990
standards) are
required
Not yet,
NY
currently sends
some messages
to standard
error
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
13 of 16
INT-10
Level 2 modules shall read the following files on
input: 1. one EarthCARE level
1b data product (in case of synergistic
processors: one or more EarthCARE level 1b
data products from different instruments, and/or
one or more level 2 data products) covering
up to 2 orbits worth of data, 2. a configuration
file, 3. support files (e.g., meteorological data
from ECMWF, look-up tables, topographic
databases, etc.) as required.
C
INT-11
Level 2 modules shall write the following files on Currently no
output: 1. one level 2 data product, 2. a log file. log file is
written but this
will be fixed
NY
INT-12
All files (including configuration and
ntermediate input/output files) shall be in XML
or NetCDF format. The default format shall be
XML while NetCDF shall be used for data
products and large files only (i.e., where using
XML would significantly degrade performance).
Details (including the NetCDF version) shall be
agreed with the agency.
Output data is NY
in netcdf but
configuration is
via an ascii
format that is
much more
easily edited.
INT-13
The functions of the Earth Explorer mission CFI
software shall be used wherever possible.
What are these
?
N
INT-14
The reference systems defined in the Earth
Explorer mission CFI software shall
be used throughout, in particular for all outputs.
???
N
INT-15
All processing parameters including the
environment of level 2 modules (e.g.,
paths) shall be configurable in external
configuration files without code updates or
recompilation.
C
INT-16
Level 2 modules shall read their configuration
file(s) at run-time at start-up.
C
INT-17
Level 2 products shall follow the general
EarthCARE file format as specified in [AD1].
Not sure the
general
baseline
document
defines a
NY
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
14 of 16
format?
INT-18
Level 2 modules shall generate one level 2 output
data product per level 1 input data product.
C
INT-19
Each level 2 module, complete with reference
configuration and support files, shall be
delivered as a single tar file, optionally
compressed by gzip.
C
INT-20
No unused or otherwise unneeded files shall be
delivered with a level 2 module.
C
INT-21
Each level 2 module shall be delivered with a
script that plugs it into the ECSIM framework.
NY
INT-22
Only relative path names shall be used in the
installation scripts of Level 2 modules.
C
INT-23
The tar file used to deliver a level 2 module shall
conform to the naming convention described in
Section 6.7 of the General Requirements
Baseline Document [AD?]
NY
Testing Requirements
TST-1
Test entry points shall be defined to facilitate
testing and debugging. They shall allow running
selected parts of the processing chain by
providing breakpoints for reading intermediate
input data and writing intermediate output data.
TST-2
ECSIM shall be used for end-to-end performance
testing using appropriate ECSIM models
(including scenes, forward models, instrument
and L1b simulators). Furthermore, realistic
scenes shall be used, derived from existing
measurements.
The ACM-CAP
processor ins
indivisible
N
NA
Configuration management requirements
CFG-1
All elements and sub-elements composing the
level 2 processor shall be put under
configuration management.
CFG-2
At least the following configuration items shall
be managed under configuration
management:
What is
configuration
management?
N
N






Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
15 of 16
Software modules (source code and
object code)
Static configuration and support data
Acceptance Test Data Sets
Procedures and scripts
Any static data, e.g., delivered tar files
Software and hardware environment
documentation
CFG-3
Widely supported Software Configuration
Management tools shall be used.
N
CFG-4
It shall be possible to know, for any discrete
point in time, the software
configuration of the level 2 processor.
?
CFG-5
It shall be possible to retrieve, for any discrete
point in time, the level 2 processor
in this configuration.
?
CFG-6
To maintain software integrity throughout the life
cycle, a proper and systematic
control of software changes shall be provided.
NY
CFG-7
For all versions of any software module, the
modifications with respect to the
previous version shall clearly be identified and
documented in the software module itself.
NY
CFG-8
All versions of all software modules shall be
archived with a version identifier
and the time from which the software module was
in use.
NY
CFG-9
For each delivery of any Configuration Item, a
Change Log detailing all changes
since the previous delivery shall be provided.
NY
CFG-10
Each version of an Level 2 module shall be
uniquely identified through an
Overall Version Number in the following format:
VERSION = Major Version.Minor Version, each
over two digits
C
Coding Rules
COD-1
Common code should be separately packaged
and reused within a single level 2
C
Code
L2b-ACMCAP-SRS
ACM-CAP SRS
Issue
01
VARSY Project
Date
27/08/2012
Page
16 of 16
module as well as across level 2 modules.
Code duplication should be eschewed as far as
possible.
COD-2
Code related to the interfaces (input/output) shall
be separated (in different
subroutines and different source code files) from
code implementing the algorithm.
C
COD-3
File or path names shall not be used inside the
code.
C
COD-4
Redundant calculations in Level 2 modules
should be avoided.
C
COD-5
It shall be shown that code does not include any
uninitialised variables, unused variables,
memory leaks, and dead (i.e., unused) code.
All issues can
be verified
rigorously
using various
compiler
options, except
for memory
leaks. The
absence of any
potential leaks
would be
difficult to
rigorously
demonstrate
P
COD-6
Standard headers shall be used for subroutines.
Details shall be agreed with the agency.
Define
“standard
header”
?
COD-7
Ample use of comments shall be made.
C
COD-8
Comments shall be used to describe the structure
of the code.
C
*C=compliant, P=partly non-compliant, N=not compliant, NY=not yet compliant but will be,
NA=Not applicable
Download