Frank Kuehndel created an issue: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/issues/15
## Summary <!-- ---------------------------------------------------------------------- --> At 28th of January 2026 embedded brains presented on Discord that ESA funds an RTEMS SMP Qualification Extension activity with the goals * to produce an usable and documented public qualification toolchain (QT) for RTEMS * to extend the QDP by a (limited) POSIX interface * to extend the pre-qualification for new hardware (GR765) * to perform an ISVV for all that. This issue provides more information on the activity and provides room for comments and discussions. ## What is Pre-Qualification? <!-- ---------------------------------------------------------------------- --> Qualification is intended to prove the usability of a product in safety-critical applications. The development process and the product must undergo a certification by an authority and must follow a standard which defines rules and requirements which must be met. For being used in European space applications, the certification authority is ESA and the standard is [ECSS (European Cooperation for Space Standardization)]( https://ecss.nl/standards/). Only the complete product (i.e. all hardware, operating system and application software together) is qualifiable. Thus RTEMS can only be prepared for being used in a qualified product. This is called *pre-qualification*. For this purpose, RTEMS is configured and translated for the target hardware. Various small test applications are linked to the compiled RTEMS system, executed automatically on the target hardware and information about the execution (e.g. code/branch coverage) and the results are collected. This collected information is then used to generate various documents which summarize the correct execution of the tests and act as proof for the quality of RTEMS on that target hardware. The result is a Qualified Data Packet (QDP). Some QDPs are downloadable from the [ESA web-site](https://rtems-qual.io.esa.int/). To facilitate the repetition of the pre-qualification (for example when features are added or a new RTEMS version is released), all these steps are carried out automatically by a Qualification Toolchain. Note that each repetition of the pre-qualification for changed source code base requires manual work (such as creating or adapting requirements, tests, check for known bugs etc.) and must again be assessed by the certification authority (e.g. ESA). ## What is the Qualification Tool Chain? <!-- ---------------------------------------------------------------------- --> QDPs are build using various standard tools such as `gcc`, `latex`, `lcov`, `tar` and so on. The overall build process is orchestrated by three Python packages – often referred to as *Qualification Tool Chain*: * *specitems* – A Python package to work with specification items * *specware* – Python utilities to specify software and generate source code for interfaces (incl. API documentation) and tests from specification items * *specbuild* – Python utilities to build software packages along with their documentation from specification items A *specification item* is a YAML file which describes a part of the build process or content of the QDP. The `specbuild` tool reads the specification items and builds the QDP step by step resolving the dependencies depicted in the specification items and executing the instructions contained in them. One can think of the `specbuild` tool as a kind of `make` utility and the specification items as a `Makefile`. {width=700 height=305} Thus these three Python packages are fundamental to build QDPs. They are maintained in the [*specthings*](https://github.com/specthings) public open source software project on Github. The tools are also provided as packages on [pyip.org](https://pypi.org/) ready for installing with `pip`. ## API Specification <!-- ---------------------------------------------------------------------- --> **Current state:** Currently, the `rtems-central` repository contains specification items in `spec/` which include (among other things): * RTEMS specifications (API function names, parameters, results and description of those functions, parameters, results, constrains) (e.g. `spec/rtems/clock/if/get-tod.yml`) * Requirements covering RTEMS API functions, types and #defines (e.g. `spec/rtems/clock/req/get-tod.yml`) * Code to test these requirements (e.g. `spec/rtems/clock/req/get-tod.yml`) A tool from the qualification tool chain (`specbuild`) produces from these specification items: * API header `.h`-files found in the `rtems` repository (e.g. `cpukit/include/rtems/rtems/clock.h`) * Validation test `.c`-files by collecting the manually written code and adding the execution logic. These files are found in the `rtems` repository (e.g. `testsuites/validation/tc-clock-get-tod.c`) * Documentation `.md`-files found in the `rtems-docs` repository (e.g. `c-user/clock/directives.md`) **Problems with the above approach:** * Changes to the API (even text changes) must be made in `rtems-central`. Due to the extra effort and complexity, people tend to modify the files in `rtems` and `rtems-docs` directly. * The whole API modification process is cumbersome. In order to change an API one needs to change `rtems-central`, `rtems` and `rtems-docs` and file three merge requests. **Proposed solution:** The relevant content of the `spec/` directory should be moved from the `rtems-central` repository into the `rtems` repository. Any modifications to the specification items could then be done in the `rtems` repository. Furthermore, the changed specification items and the changes generated from it by `specbuild` could be committed with a single merge request. With this solution it is still necessary to distribute changes from `rtems` to the `rtems-docs` repository. This could be supported by a CI job which * generates the changed documentation for review and * generates the needed patches for `rtems-docs` or * creates the merge request in `rtems-docs` or * even commits the changes to `rtems-docs` As in the past, all modifications caused by specification items to any `.c` or `.h`-files should be committed to the `rtems` repository. So that ordinary RTEMS users do not need to use the qualification tool chain and do not need to build these files. (See also issue [rtems-central#8 "Interface maintenance workflow is too cumbersome"](https://gitlab.rtems.org/rtems/prequal/rtems-central/-/issues/8)) ## What Is Needed to Build a QDP? <!-- ---------------------------------------------------------------------- --> The `rtems-central` repository should be retired. Instead two new public repositories in `rtems.org/pre-qualification` are suggested to build QDPs in the future: * A package repository containing all the data and sub-modules to build a QDP. This is named `rtems-qdp-build` in the graphic below. * A repository to keep the sources of the documents required by the ESA qualification standard ECSS. This is named `rtems-qdp-docs` in the graphic below. Other suggested names: `rtems-qdp-ecss-snippets`, `rtems-qdp-doc-ecss-parts`, `rtems-qdp-ecss-templates`. The `specthings` packages on PyPI are managed and build with the Rust tool `uv`. This tool will also be used with the new package repository to download and install the `specthings` tools (qualification tool chain). One can uses `pip` or `poetry` for the same purpose. `uv` is saver to use as it ensures to install the correct untampered package versions. The content of the `rtems` repository must be enhanced – maybe in a dedicated branch. It needs patches to build the pre-qualified feature set, it needs the memory benchmarks (the results are part of the QDP documentation), etc. {width=723 height=340} This environment is needed to build a QDP: * A Linux OS (we use Ubuntu 24.04 LTS contractual) * The `uv` tool to manage Python packages * The usual Linux packages needed to run the source builder and build rtems and rtems-docs * Static analyzers (`clang`, `cppcheck`) A public CI job for building a sample QDP can be added, if the `rtems.org` GitLab has the infrastructure and enough resources to run that job. Alternatively, documentation how to run the QDP build will be added. ## How Is a QDP Build? <!-- ---------------------------------------------------------------------- --> The following graphic shows the QDP build process steps undertaken by the qualification tool chain. These steps are strongly simplified for the purpose of presentation. What actually happens and in which order depends on the specification items. {width=892 height=1168} The blue boxes indicate steps usually manually executed. The steps in the big black outlined box are executed by the qualification tool chain. Such a build takes usually one to two hours. -- View it on GitLab: https://gitlab.rtems.org/rtems/prequal/rtems-central/-/issues/15 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
