AURORA auto-coding technology was developed using models created for the European Space Agency’s Euclid Mission to reduce the cost of satellite production.
From predicting the weather to communications, satellites are present in our everyday life. Satellites circle around the Earth in a specific orbit, but how do they know their way to reach it?
Before sending a spacecraft to outer space, scientists need to make sure that they have the right instructions to get to their destination. For this purpose, satellites have a specific software called an Attitude and Orbit Control System (AOCS). The code behind this software is generated by model-based engineering, which produces different models by simulating different conditions and possible errors.
The next phase is to translate the models into a custom-code, specific for every satellite, to create the navigation software. Although this step is automatic, it needs deep verification and must pass multiple manual tests to make sure there will be no errors in the flight. This raises the cost of the process significantly.
With space agencies seeing an increase in interest and funding, a sudden demand has also surfaced concerning the use of auto-coding. Unfortunately, little has been done so far to satisfy this demand.
That is what the project AURORA wanted to change. AURORA uses the models created for the European Space Agency’s (ESA) Euclid Mission to validate a novel auto-coding process. The team then tests this code in a hardware environment that simulates possible failures the satellite might encounter while it is getting into its orbit.
The objective was to develop a set of tools to automatise the validation process and reduce the cost of satellite production.
Auto-coded flight software life-cycle process and methodology
The AURORA auto-coding technology connects the QGen product to transform the Simulink models into source code. QGen is a code generation and model verification toolset that grew out of European projects.
The technology demonstration is carried out by exercising the QGen automated code with the already validated and verified results of the Euclid AOCS auto-generated code. The demonstration process makes use of the test cases designed for Euclid AOCS formal verification and testing is performed in the actual Euclid test environment. This approach facilitates the assessment of a higher Technology Readiness Level (TRL) for QGen. The TRLs adopted in AURORA conform with the H2020’s definition.
Departing from the existing Simulink AOCS models for the Euclid project, which were developed by Sener Aeroespacial, AURORA generates the code from those models with the QGen tool to evaluate the quality of the resultant software given the previously qualified Euclid software.
The workflow to validate and verify a software is progressive, starting from the Model-in-the-loop (MIL) activities in which the algorithms are tested at model level, to the Software-in-the-loop (SIL) campaign that verifies the quality metrics of the generated software.
Finally, the Processor-in-the-loop (PIL) campaign tests the software, in either a simulated or real target processor, ending in a Hardware-in-the-loop (HIL) test facility in which the software is integrated inside the flight software.
A Euclid evaluator includes the operation environment used during the original Euclid’s development and test campaign. The evaluation report determined that the overall TRL established for the QGen toolset is TRL-7.
AURORA auto-coding technology also provides the definition of an auto-coded flight software life-cycle process based on QGen. The workflow and standards involved in the Model-in-the-loop process were defined, supported by AURORA modelling guidelines and the definition of the model’s unitary integration and performance test campaign.
QGen simulation framework code was ported to run on TSIM/Leon2, allowing us to perform the Platform-in-the-loop test campaign and finally, the Hardware-in-the-loop phase executed on the Euclid Software Validation Facility. During this, the autogenerated QGen code is integrated with the application software (ASW) to run selected tests to check code behaviour in a representative scenario.
The gathered results of all the software verification activities are provided in the SW Verification Report, including static and dynamic/coverage, analysis of MISRA compliance, and detailed test results rationale.
The code generation toolchain is integrated into the TASTE framework – the ESA development environment dedicated to embedded real-time software. This task has a double goal: to take advantage of this framework for the technology demonstration process, as well as to give visibility to the AURORA auto-coding technology in the space SW community through the TASTE open access (Open-Source License).
Interoperable component-based interface
The interoperability of the AURORA auto-coding technology is ensured through a standard specification of component-based interfaces (CBI), both for manual and auto-generated code, as a basis to develop the critical SW product in TASTE. ESA’s TASTE model-based toolchain was selected as the basis for CBI implementation.
In AURORA, we have studied a specific solution to integrate model-driven techniques for cFS execution platforms. We integrated cFS, a message-oriented NASA framework based on a publish-subscribe architecture, inside TASTE and SpaceCreator, to provide modelling capabilities and automatically generate code from models, thus avoiding error-prone repetitive tasks, ensuring consistency throughout the different stages, and allowing the end-user to focus on the implementation-specific details.
An analysis on trends for SW architecture design using AUTOSAR, NASA cFS and SAVOIR was carried out. The result is compiled in the Component-Based Interface (CBI) Requirements Specification. The Technical Architecture Design and the Interface Specification describe the AURORA auto-coding process. Components are designed using TASTE SpaceCreator.
ESA’s TASTE model-based toolchain was selected as the basis for CBI implementation. SpaceCreator Integrated Development Environment (IDE), serving as the main graphical interface of TASTE, was extended with multiple additions, including:
- Function Tester Plugin, facilitating the execution of data-driven component tests;
- Simulink Importer Plugin, simplifying the integration of Simulink models as components;
- Multicast support, enabling the incorporation of publisher-subscriber patterns;
- Layer support, improving system architecture readability; and
- Archetype support, providing a framework for interface standardisation.
The changes to the IDE were supplemented by the relevant modifications of the rest of the toolchain, including a Kazoo template processor and code generator. The integration of the QGen code generator was redesigned and re-tested. It was also improved by adding the support for vector IO optimisations and S-Functions.
In order to enable the deployment of the designed systems to the LEON3FT GR712RC high-reliability processor, a new TASTE runtime was developed using ESA’s customised, pre-qualified version of the RTEMS operating system. Its implementation was accompanied by improvements to the simple instruction simulator (SIS), enabling testing of the runtime without the need for any hardware.
The developed software was validated against the requirements via a set of tests, example models, analyses, and inspections. Full requirement coverage was achieved. CBI Software is integrated with the main TASTE repository available to the public.
The Technology Readiness Assessment Plan was prepared for the Demonstration Viability Assessment that allows AURORA to go for a target TRL-6/7.
UPMSat-2’s Attitude Control System (ACS) and EUCLID’s Attitude and Orbit Control System (AOCS) are used as technology evaluators to allow the obtention of a set of measurable values that, in turn, helped to fulfil the key performance indicators (KPIs) defined in the plan. A specific report covers the evidence for the applicability of the QGen tool set in the software design, modelling, simulation, and verification of autogenerated code. Obtained data are compared with the KPIs’ reference values.
The evaluation report has determined that the overall TRL established for the QGen toolset is TRL-7 ‘System prototype demonstration in operational environment’.
The TRL Assessment process has also allowed us to demonstrate the viability of a reduction in the efforts and planning of the software life cycle at incorporating auto-coding technologies in the process, showing:
- A general increase in productivity;
- A reduction of development effort by 60%;
- A reduction of testing campaign; and
- A reduction in testing time by 30%.
Project Coordinator: Sener Aeroespacial
Participants:
Please note, this article will also appear in the fifteenth edition of our quarterly publication.
