The Software Systems Division (TEC-SW) and Data Systems, Microelectronics & Component Technology Division (TEC-ED) Final Presentation Days are scheduled to take place on 4th & 5th June 2024 via WebEx / ESTEC Room EF103)
All material presented at the Final Presentation Days must, before submission, be cleared of any restrictions preventing it from being published on this web-site.
Next Presentation Days: 19th & 20th November 2024
Development of two modules for the TASinB RTU. Both GIM and FSMOT modules have been designed on existing and new building blocks with the aim to immediately arrive at a flight compatible design.
Therefore, the design took all flight-related constraints into account to allow for immediate and direct transfer to flight grade manufacturing. The EM prototypes that were built have been tested at extended temperature range and all flight-related analyses have been performed, serving as direct input to the CDR of the first-use project, being RIDU ESPRIT. The exact PCB routing has been used for FM manufacturing within that project and the EM prototypes have even been transferred to RIDU ESPRIT to serve in the EM RIDU, successfully in use for more than a year now. This was only possible due to the achieved functional and physical compliance of the EM prototypes with the target application. It can be concluded that the RTU portfolio extension was successful and immediately found its application in a first flight project.
The project aims to develop the first AI-to-FPGA tool flow supporting all state-of-the-art FPGAs, including NanoXplore devices. The objective is to facilitate AI deployment onboard satellites and demonstrate the applicability to NanoXplore technology, enhancing European sovereignty. We extended the FPG-AI design for compliance with NanoXplore technology, adding RNNs to the list of supported models and creating a hardware prototype. Results obtained during benchmarking indicate the success of accelerating AI models on rad-hardened FPGAs, reducing development time and cost and increasing performance compared to more advanced HLS approaches.
In the scope of the “ARM Board Support Package Criticality B Qualification” project two separate software products were created: BSP (Board Support Package) and BSW (Boot Software), targeting ARM-based space-grade microcontrollers – SAMRH71F20 and SAMV71Q21.
Board Support Package contains the low-level drivers for the peripherals of the microcontrollers and validation test suites for qualification of those drivers.
Boot Software is a low-level software, designed to perform boot, initialization and basic self-tests of the microprocessor platform. The BSW starts at CPU reset and finishes by executing the custom, user-provided, Application Software (ASW) image. It is responsible for uploading and patching of the ASW images. The BSW data package contains validation test suite for qualification on selected platforms.
Both items were developed in accordance with ECSS standards tailored for criticality category B and BSW requirements specification was derived from SAVOIR Flight Computer Initialisation Sequence Generic Specification (Issue 2.2). The aim was to provide reusable software, customizable and tailorable for various uses.
Objectives of the project were successfully met. The designed software components have been successfully implemented and validated on the SAMRH71F20 and SAMV71Q21 development boards, achieving (pre)qualified status. All unit, integration and validation tests were executed on the target hardware and have passed. Code coverage quality metric goals have been achieved and measured with unit tests. Documentation compliant with ECSS requirements and evidence for criticality level B has been provided.
To ensure proper quality of the code, various static and dynamic analysis tools were constantly used – they were integrated into Continuous Integration infrastructure and were checking each change to the repository. Multiple additional rules were enabled and their reports reviewed in tools like SonarCloud, clang-tidy and cppcheck. No critical bugs were found, but few maintainability, readability and portability issues were found and fixed.
The software already found it way into multiple deployments, including ESA missions (Comet Interceptor, Ariel, Envision and Truths) and commercial uses. Those provided a valuable insight into configurability capabilities of the products.
The demonstration version of the BSW can be obtained at https://bootloader.space, alongside the graphical tool for interfacing with the bootloader.
Future of the products include porting to SAMRH707F18 and LEON3, providing support for other communication links (Ethernet, CAN) and hopefully more deployments.
The main objective of the activity was to evaluate the usage of Rust programming language in space applications, by providing an RTOS targeting ARM Cortex-M7 SAMV71 microcontroller, a BSP (Board Support Package) and a Demonstration Application.
RTOS is implemented in the form of an executor instead of a classic scheduler. The scope of this project doesn’t include preemption. This executor runs tasklets, which are fine-grained units of computation, that execute a processing step in a finite amount of time.
Basic functionality required to create a working system is provided – tasklet priorities, recurring and time-based execution, as well as communication facilities such as queues and events. Additionally, execution time statistics are reported to facilitate scheduling analyses and discovery of real-time related issues.
Creating a real time operating system validates Rust features mentioned in the section above in practice, evaluates Rust viability in space applications and additionally checks compatibility with ECSS software development process.
The main focus of the BSP part of the project was to provide a minimal set of functionalities for peripherals required to create the RTOS and interact with the board as well as example sensors.
In the second part of the activity, a small demonstration application software was developed. This demonstration provided input to a Lessons Learned report, describing the encountered issues, potential problem and improvement areas, usage recommendations and proposed way forward.
"The EGSE Common Core (EGS-CC) is a new software framework developed for Spacecraft Assembly, Integration, Testing (AIT), and Operations. Currently in development, this framework is a collaborative effort led by ESA. The primary aim is to create a standardized platform for Electrical Ground Support Equipment (EGSE).
Complementing this, Rovsing EGSE Controller is a software framework integral to developing systems for specific applications, managing various hardware units efficiently. It can oversee subsystems like Battery Simulators, Solar Array Simulators, or Load Simulators, ensuring cohesive management of spacecraft components during testing and operations.
In a Subsystem Controller application, all necessary software components for hardware control are integrated into a single system, including:
- Man-Machine Interface (MMI): Provides a user-friendly interaction platform.
- CCS Interface: Central Checkout Systems.
- Logger and Archive Modules: Systematically records and stores data.
- Hardware Adaptors: Facilitates communication between software and hardware units.
- Script Engine: Automates tasks and procedures.
Within this in mind the project aims to create a initial framework for the EGS-CC and Rovsing EGSE Controller which could potentially standardize and streamline AIT and operations, enhancing efficiency, reliability, and interoperability across the industry."
Virtual Reality is a promising medium for training within the space area. Recent advances in VR
hardware have overcome several of the previous limitations that hindered VR adoption,
simulator e.g. resolution for viewing small details and sickness with extended use. For adoption,
particularly in the space industry, a major hurdle is that the creation of VR training elements is a
costly, time-consuming process that requires a mixture of expert field knowledge and technical
abilities in VR, as generally custom one-off applications must be built.
The Virtual and Augmented Reality for Industry and Space (VARIaS) project (contract AO/1-
10382/20/NL/GLC/hh) developed a proof-of-concept no-code, fully pipeline system for creating
VR training elements in the context of astronaut training. The VARIaS developed platform
extends an existing Augmented Reality platform developed in part in the ESA VIPER project.
The resulting VARIaS platform has a pipeline for creation of training, for instance as tested with
the ESA LSR. This pipeline contains 2 software components that are used, the VR Studio is a
desktop application for specifying the virtual and digital twin as well as creating training
processes and the VRIPR VR application. The pipeline enables a process of:
1. Import of CAD/model data and no-code creation of a digital twin representing the
behavior of object
2. Immersive specification of a process for training by performance of the actions in the
VRIPR
3. Semi-automated post-processing of the recorded performance in 2 to creation a VR
training element
4. VR Training in VPIPR
5. Live Observer with 2 way communication in either VR or desktop
6. Post-action review of training or recordings in either VR or desktop
VARIaS pipeline was tested in the European Astronaut Center using the Life Support Rack as a
test case. Two unique gloves were also tested in the VARIaS project to provide full hand
tracking and feedback; currently these hardware solutions did not provide enough value add as
the resolution and feedback capacities did not meet ESA expectations. The results of pipeline
testing showed that the approach developed is promising for creating VR training in a new more
efficient manner.
Flight software development to ECSS Category A qualification level is a technical challenge that up to now has not been required too often in the European space industry (e.g., ATV MSU, ESM PDE) and for which the production of qualification evidences are not straight forward although the requirements are clear in ECSS. Currently more and more space systems require operating systems and software building blocks to be qualified to category A, to enable the development of project specific category A software on top of them for new high criticality applications. As many of these software building blocks and operating systems are qualified up to ECSS Category B, GTD developed on behalf of ESA a methodology and its accompanying tools to systematically upgrade such software components up to category A.
The C++ language has evolved significantly over the last decade. Since 2011, the C++ standard has been updated every 3 years, with the latest revision published as C++20. Improvements introduced in the modern versions of the standard allow writing safe code, at high abstraction level, with zero or close to zero runtime overhead. Yet, there is no single ESA mission that takes advantage of C++20. The purpose of this activity is to research the latest versions of the standard and determine if they are suitable for flight software development.
EDS is computer-readable replacement (or supplement) to the current printable documents used to manage the interfaces to and from onboard electronic devices. SOIS EDS is the CCSDS standard for such datasheets. Following feedback from various study projects and operational users, an updated version of the standard has been developed. As is the usual CCSDS process for normative standards, this requires interoperability testing between two independent implementations.
SOIS EDS Common Tooling is the ESA-owned open source EDS toolkit. Under the scope of this study, this was updated to incorporate the standard updates and then used to run the updated interoperability tests against the NASA-owned toolset.