Attitude control subsystem development using Julia

The development of a satellite attitude and orbit control subsystem (AOCS) imposes challenges since the dynamics cannot be reproduced on the ground. The entire process relies on simulation. We developed a novel workflow that improved productivity by using the outstanding adaptability of the Julia language and its ecosystem. We could adapt a validated simulator to test and verify all the AOCS algorithms at each development phase, drastically reducing error propagation and, consequently, test cost

The satellite attitude is defined as its orientation in space. Most satellites require attitude control to point their payloads to acquire the data. The satellite subsystem in charge of estimating and controlling the attitude is the attitude determination and control subsystem (ADCS). When this subsystem can also maintain the satellite orbit, it is called the attitude and orbit control subsystem (AOCS).

It is almost impossible to reliably reproduce the space rigid-body dynamics on the ground. Hence, the development of the AOCS highly depends on simulation from the design phase up to the acceptance tests. This specificity leads to an "n-simulator" problem, where each development phase requires constructing some simulation tool. For example, when developing and tuning the control loop, the specialist must use a minimal dynamics simulation to verify the control law. In a more advanced phase, when the embedded software is being coded, the software engineer should also use a simulator to perform closed-loop tests to check whether the control laws are correctly implemented.

Given all the difficulties that arise from keeping all those simulators, the AOCS development usually happens through unit tests and simple scenarios. However, unit tests can hardly verify the entire AOCS algorithms, for it depends on Markov chains. Thus, more than a simple input/output verification is needed, and a vast number of internal states must be taken into account. Deeper tests only occur with the onboard computer in a hardware-in-the-loop simulation when everything is implemented. Even though this approach usually simplifies the simulation requirements, some errors can only be spotted late, leading to significant problems for the project. One of them is the time required for algorithm testing and debugging using real hardware. Those are expensive tests since they happen in real-time, leading to a significant mobilization of the test team and the use of expensive flight hardware.

Previously, using the packages SatelliteToolbox.jl, ReferenceFrameRotations.jl, and DifferentialEquations.jl, we managed to create high fidelity simulator for the Brazilian Multi-Mission Platform (PMM, in Portuguese), called PmmAocsSimulator.jl. We validated this tool using on-orbit data from the Amazonia-1 satellite.

For our next AOCS generation, we want to rely on the validated simulator code for all the development phases. The algorithms for the embedded software are initially constructed in Julia inside the PmmAocsSimulator.jl. When the control engineer validates the dynamics, the Julia code is translated to C++ using the CxxWrap.jl package, which is also run inside the same environment. Afterward, the same C++ code is compiled for the onboard processor and run in its emulator. In this phase, the onboard software is also tested in a closed-loop environment using the PmmAocsSimulator.jl. Lastly, the AOCS software is integrated with the rest of the satellite computer software, and a final simulation takes place using the real onboard computer.

Since all the phases are simulated using the same validated environment, the results must be perfectly matched. This workflow allows us to develop the next AOCS generation with a huge gain compared to the classic scenario. The development can happen incrementally but also with a full test suite encompassing the most significant dynamics states of the satellite, which is impossible to reproduce without such an environment. Hence, most of the issues related to attitude control can be spotted and solved by the AOCS team before the final software integration. All this workflow is only possible given the considerable adaptability of the Julia language and the tools available in its ecosystem.

Finally, the gains obtained by this new workflow are massive. We have already implemented 50% of the AOCS functions for the next-generation software, and we have yet to identify a single algorithm bug at the final test stage with the flight hardware. This process allowed us to drastically reduce the test hours using the real satellite computer, which also helped diminish the development cost.

This talk will detail all the processes mentioned before, stating how the Julia language and its ecosystem are being used at the National Institute for Space Research (INPE) to solve the n-simulator problem by providing one single simulator for all the AOCS development phases.