You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Frequently Asked Questions concering the RCS.


Table of content

CDF-related questions

What is a "skeleton table"?

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?".

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/.

How to deliver a skeleton CDF file to the ROC?

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:

  • Skeleton CDFs must be delivered as a skeleton table in the ASCII format
  • Skeleton CDFs must be "pushed" by teams in the "SOLO/RPW/CDF/Skeleton" folder of the ROC "DataPool" Git respository (https://gitlab.obspm.fr/ROC/DataPool)
  • Skeleton CDFs can be only "pushed" by teams in the "rcs" branch of the ROC "DataPool" Git respository


IMPORTANT

Every "commit" should be commented to have a traceability of the changes.

How to generate a skeleton or master CDF file from an Excel format file?

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/.

RCS software-related questions

How a RCS software must be delivered to the ROC?

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:

  • RCS software must be delivered with at least the source code and the executable "ready-to-be-used" on the roc-dev server. The executable can be a script or a binary file.
  • RCS software must be delivered with the up-to-date documentation (user manual, software specification and design)
  • RCS software must be delivered with the up-to-date descriptor file (see RCS ICD for more details, available in ROC Documents)
  • RCS software must be "pushed" on the "master" branch of the dedicated project in the https://gitlab.obspm.fr/ROC/RCS group. There is one project by RCS
  • Every RCS software delivered must be tagged on Git with a version (use "git tag" command for this)
  • The ROC team must be informed each time a new version of the software is "pushed"

What is the descriptor file?

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.

How can be sure that my descriptor file is well formatted?

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).

How can be sure that my RCS software is compliant with the ROC pipeline calling interface?

The ROC pipeline calling interface is described in the RCS ICD (available in ROC Documents).

Additionaly, the ROC will make available in its roc-dev server a tool that allows teams to verify that their software is compliant. This tool simulates the calling of the software as expected by the ROC pipelines.

This tool should be released prior to the launch.

ROC Gitlab-related questions

How to get a local copy of the ROC "DataPool" Git repository?

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.

WARNING

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 :

  1. git checkout -b rcs
  2. git branch --set-upstream-to=origin/rcs rcs
  3. git pull

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:

  • All of the "git ..." command must be run from the DataPool/ folder
  • The "git pull" command should always be run at first, in order to ensure that the remote and local branches are always synchronized
  • To switch from a branch to another, use the "git checkout name_of_the_branch" command.

How to access to the ROC "DataPool" Git repository?

  1. Connect a first time to the gitlab server https://gitlab.obspm.fr, using your LDAP login/pass (i.e., the same used to access to  the roc-dev server.)
  2. Send an email to the roc.support list when it is done, and the ROC team will give you the access to the repository
  3. You should then be able to see the https://gitlab.obspm.fr/ROC/DataPool repository


INFO

  • The step 1 is only required at the first connexion to register your account into the gitlab server.
  • You will have only the read/write access to the "rcs" branch of the repository ; this branch must be used to deliver your CDF skeletons. The « master » branch is used by the ROC and cannot be changed by teams.
  • You might use ssh keys to access to the repository. In this case, just send your public key to the roc.support list and the ROC team will add it to the authorized key list.

RCS issue management questions

Where I can submit issues in case of problems?

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:

How can I access to the RCS issue tracking interface?

The access is restricted and must be requested to the RPW ground segment project manager.

RPW Calibration Tables-related questions

How can I deliver my RCT file?

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.

Miscellaneous questions

Where I can find the list of acronyms relative to the ROC project?

The list of acronyms are available here: Acronyms and Definitions

  • No labels