Frequently Asked Questions concering the RCS.
All SOC-provided Solar Orbiter SPICE kernels retrieved by the ROC are made available in https://rpw.lesia.obspm.fr/roc/data/private/solo/esa/soc/spice/ (restricted access).
For more details about:
A "skeleton table" is an ASCII format file used to generate a "master" binary CDF file.
The "master" binary CDF file can be then used as a template to produce series of CDF files with the same structure.
See also "How to generate a "master" CDF binary file?".
The CDF generation principle for RPW is described here.
For more information about the CDF and skeleton/master mechanism, visit http://cdf.gsfc.nasa.gov/.
The mechanism to deliver skeleton CDF to the ROC is presented in the "ROC Engineering Guidelines for External Users" (REGU) document (see ROC-GEN-SYS-NTT-00019-LES, available in ROC Documents).
In summary:
Every "commit" should be commented to have a traceability of the changes. |
The MASER4PY Python package allows to generate skeleton table or Master CDF from an Excel 2007 format file (.xlsx).
More details can be found in https://pypi.org/project/maser4py/.
The mechanism to deliver RCS software to the ROC is presented in the "ROC Engineering Guidelines for External Users" (REGU) document (see ROC-GEN-SYS-NTT-00019-LES, available in ROC Documents).
In summary:
The descriptor file (or descriptor) is JSON format file used by the ROC pipelines to identify and call the RCS in an autonomous way.
A RCS delivered without or with a badly formatted descriptor cannot be run by the ROC pipelines.
See RCS ICD for more details about the descriptor, available in ROC Documents.
The ROC team will always performed verifications of your descriptor just after each RCS delivery.
A JSON format file, as for XML, can be validated against a schema. A JSON schema is following the specifications from http://json-schema.org/draft-04/schema. Dedicated documentation can be found at https://spacetelescope.github.io/understanding-json-schema.
A copy of the RCS descriptor JSON file “cawa-schema.json” can be found in the RCS folder of the https://gitlab.obspm.fr/ROC/DataPool Git repository. Teams are free to download and use this file to verify that their descriptor is compliant.
This schema is also showed in the appendices of the RCS ICD (available in ROC Documents).
N.B. The ROC team plans to make available an instance of its RCS Interface Validation Pipeline (RIVP) on the roc-dev.obspm.fr server. The RIVP is the light version of the ROC pipeline, which can be used to test the execution of RCS in conditions closed to the production.
The ROC pipeline calling interface is described in the RCS ICD (available in ROC Documents).
The RIVP can also be used to test the compliance (see How can be sure that my descriptor file is well formatted? above).
The RCS skeleton CDF files must deliver to the ROC team using Git.
The "DataPool" Git respository to use is hosted on the ROC Gitlab server. Before working with this repository, be sure that you have the right access permissions (if not, please contact the ROC team using the roc.support mailing list). To know how to access to this repository, see next question.
To get a local copy of the "DataPool" repository (i.e., clone), enter the following command from a terminal:
git clone https://gitlab.obspm.fr/ROC/DataPool (HTTPS)
or
git clone git@gitlab.obspm.fr:ROC/DataPool (SSH)
If everything goes right, you should have a local folder "DataPool" in your system.
By default, Git will download the "master" branch only. This branch is protected and contain the skeleton/master CDF files actually used by the ROC. In order to submit their skeleton CDF files, the RCS teams must use the dedicated "rcs" branch. |
To switch to the "rcs" branch, enter the following commands in the given order :
The first command creates the local branch "rcs" and switches to this new branch. The second one synchronizes the local branch with the remote branch "origin/rcs" on the ROC Gitlab server. The third command downloads (i.e., merges) data from the remote branch "origin/rcs" into the local branch "rcs.
NOTES:
|
Any issue related to a given RCS must be submitted using the dedicated issue tracking interface in the RCS project on the "ROC/RCS" gitlab group.
The table below lists the URLs of the issue tracking interface for each RCS:
RCS name | Issue tracker |
---|---|
BICAS | https://gitlab.obspm.fr/ROC/RCS/BICAS/issues |
LFR_CALBUT | https://gitlab.obspm.fr/ROC/RCS/THR_CALBAR/issues |
SCMCAL | https://gitlab.obspm.fr/ROC/RCS/SCMCAL/issues |
TDS_CALBA | https://gitlab.obspm.fr/ROC/RCS/TDS_CALBA/issues |
THR_CALBAR | https://gitlab.obspm.fr/ROC/RCS/THR_CALBAR/issues |
The access is restricted and must be requested to roc.support sympa mailing list (i.e., roc dot support at sympa dot obspm dot fr).
The mechanism to deliver the RPW Calibration Table files (RCT) is described in the "ROC Engineering Guidelines for External Users" document (REGU) [ROC-GEN-SYS-NTT-00019-LES].
The latest issue of the REGU is available in the ROC Documents page.
The list of acronyms are available here: Acronyms and Definitions