CoChat
Sign Up
Cited by 32Advanced Software Engineering MethodologiesSpacecraft Design and TechnologyModel-Driven Software Engineering Techniques

The DOI matches its Crossref record; 40 of the 42 references it cites were found in a registry or an index.

An Architecture-Tracking Approach to Evaluate a Modular and Extensible Flight Software for CubeSat Nanosatellites

Open access
Gonzalez, Carlos E., Rojas, Camilo J., Bergel, Alexandre, Diaz, Marcos A.·2019·IEEE Access
DOI 10.1109/access.2019.2927931
Open this paper in CoChat — free accountOpen PDF

Abstract

Delivering better flight software is an important concern to improve CubeSat missions success. It has been identified as a key element to enhance team collaboration, increase reusability, reduce the mission risk, and facilitate the development and operation of new mission concepts, such as satellite mega-constellations. An appropriated fight software architecture represents the functional and non-functional requirements and guides the development. Therefore, to achieve the expected software quality, the architecture should be closely monitored during the entire software life cycle. However, ensuring that a flight software for a spacecraft embedded system closely follows the proposed architecture and addresses the set of non-functional requirements is a difficult and nontrivial problem. Motivated by requirements commonly described in previous CubeSat missions, in this work, we present the design and implementation of a flight software architecture based on the command design pattern. We also present an architecture tracking methodology to verify and control the flight software quality criteria during the development process through the use of graphical software analysis tools and agile programming techniques. This automatic software analysis tool was developed using Git, Jenkins, Moose, and Roassal, and has been applied in the SUCHAI series of nanosatellites to evaluate the impact of the architecture verification during the development history. The implemented flight software and the verification tools have been released as open source platforms and are available for the CubeSat community.

Overview

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Integrity signals

Registry

Crossref · 10.1109/access.2019.2927931

Cites

40 of 40 references verified0 citation errors · 0 not checkable

Statistics

Figures

FIGURE 1 Example of satellite operations. Operators can send commands to the satellite which are executed immediately or queued in the flight plan. Additionally the satellite has to perform autonomous activities such as sending periodic beacons and executing the commands listed in the flight plan. All this activities may be considered commands, despite of they are remote or autonomous instructions.
FIGURE 1 Example of satellite operations. Operators can send commands to the satellite which are executed immediately or queued in the flight plan. Additionally the satellite has to perform autonomous activities such as sending periodic beacons and executing the commands listed in the flight plan. All this activities may be considered commands, despite of they are remote or autonomous instructions.CC-BY · From the PDF
FIGURE 2 SUCHAI Flight software architecture: UML model diagram. Each layer consists of number of coarse-grain modules, a module being the result of compiling a number of C files and headers. A direct dependency between modules is indicated with an arrow. Our architecture follows a top-down interaction: Higher level layers can interact with layers below, but a lower level layer should never depend on layers above.
FIGURE 2 SUCHAI Flight software architecture: UML model diagram. Each layer consists of number of coarse-grain modules, a module being the result of compiling a number of C files and headers. A direct dependency between modules is indicated with an arrow. Our architecture follows a top-down interaction: Higher level layers can interact with layers below, but a lower level layer should never depend on layers above.CC-BY · From the PDF
FIGURE 3 SUCHAI Flight software architecture: UML communication diagram. In this architecture clients only generate requests to execute commands, depending on the control strategy that each client implements. These requests are sent as messages to the invoker that may implement some control strategies over the command execution such as filtering, priorities, logging, among others. If the invoker decides that the command can be executed, it sends the request to the receiver. The receiver actually executes the command by calling the corresponding function. The command and data repositories provide an interface to handle commands creation and data storage respectively. From this diagram, we can extract the application messages path and how modules interact with each other.
FIGURE 3 SUCHAI Flight software architecture: UML communication diagram. In this architecture clients only generate requests to execute commands, depending on the control strategy that each client implements. These requests are sent as messages to the invoker that may implement some control strategies over the command execution such as filtering, priorities, logging, among others. If the invoker decides that the command can be executed, it sends the request to the receiver. The receiver actually executes the command by calling the corresponding function. The command and data repositories provide an interface to handle commands creation and data storage respectively. From this diagram, we can extract the application messages path and how modules interact with each other.CC-BY · From the PDF
FIGURE 4 SUCHAI Flight software architecture: UML sequence diagram. Each client implements a control strategy and can request commands execution under certain circumstances. To execute a command the client has to create it using the command repository and then send an asynchronous message to the invoker. The invoker receives all client messages and organizes the execution by sending the request to the receiver. The receiver actually executes the command by calling the corresponding function. Once the command is executed, the receiver send a message back to the invoker with the execution result. From this diagram we can extract the application concurrency and the sequence of operations required to execute a command. We can see that clients works in parallel, that the invoker acts as a load balancer or proxy for the requests, and that the receiver performs the heavy work executing the code corresponding to each command. Note that clients send execution requests asynchronously and do not have direct feedback of the execution result.
FIGURE 4 SUCHAI Flight software architecture: UML sequence diagram. Each client implements a control strategy and can request commands execution under certain circumstances. To execute a command the client has to create it using the command repository and then send an asynchronous message to the invoker. The invoker receives all client messages and organizes the execution by sending the request to the receiver. The receiver actually executes the command by calling the corresponding function. Once the command is executed, the receiver send a message back to the invoker with the execution result. From this diagram we can extract the application concurrency and the sequence of operations required to execute a command. We can see that clients works in parallel, that the invoker acts as a load balancer or proxy for the requests, and that the receiver performs the heavy work executing the code corresponding to each command. Note that clients send execution requests asynchronously and do not have direct feedback of the execution result.CC-BY · From the PDF
FIGURE 5 Capture of the Jenkins pipeline status. The continuous integration system can run several stages to extract visualizations, build, and test the source code to detect any error introduced in a commit.
FIGURE 5 Capture of the Jenkins pipeline status. The continuous integration system can run several stages to extract visualizations, build, and test the source code to detect any error introduced in a commit.CC-BY · From the PDF
FIGURE 6 Modules dependencies comparison between commits 765c128 and 0ca21db .
FIGURE 6 Modules dependencies comparison between commits 765c128 and 0ca21db .CC-BY · From the PDF
FIGURE 7 Example of an architecture disruption in commit f1d695a . The flight plan module includes code from the data storage driver, but this is not allowed in the architecture. Client modules should use the data repository API instead.
FIGURE 7 Example of an architecture disruption in commit f1d695a . The flight plan module includes code from the data storage driver, but this is not allowed in the architecture. Client modules should use the data repository API instead.CC-BY · From the PDF
Image 8
CC-BY · From the PDF
FIGURE 9 Application layer architecture visualization. Relation between Task modules, Invoker, Recevier and messages queues for commits 765c128 and 0ca21db .
FIGURE 9 Application layer architecture visualization. Relation between Task modules, Invoker, Recevier and messages queues for commits 765c128 and 0ca21db .CC-BY · From the PDF
Image 10
CC-BY · From the PDF
FIGURE 11 Comparing software architecture after adding a client module and new commands in commit de059ae . The module task watchdog ( taskWatchdog.c ) was added, and new lines of code were added to the OBC commands module ( cmdOBC.c ).
FIGURE 11 Comparing software architecture after adding a client module and new commands in commit de059ae . The module task watchdog ( taskWatchdog.c ) was added, and new lines of code were added to the OBC commands module ( cmdOBC.c ).CC-BY · From the PDF
Image 12
CC-BY · From the PDF
Image 13
CC-BY · From the PDF
Image 14
CC-BY · From the PDF
Image 15
CC-BY · From the PDF

Verification

Claims the paper makes

The claims and statistics of this paper haven’t been checked yet.

Run the check — free, no account needed. It reads the open-access text and checks the sources it cites.

A few free checks a day · papers already verified open instantly · results are public

Claims other papers make about this one

Each is checked against this paper’s own text: does it say what the citing paper says it does?

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

The self-check needs the paper’s full text.

Citations

Cites

Show all 42 references

Research works printed but not linked: 5

  1. 2004, MISRA-C 2004 Guidelines for the Use of the C Language in Critical Systems
  2. bergel, 2016, Agile Visualization
  3. bergel, 2013, Deep into Pharo
  4. 2016, Achieving Science with CubeSats Thinking Inside the Box
  5. sommerville, 2011, Software Engineering

Cited by

See all 32

Related

Metadata

Authors
Gonzalez, C. E., Rojas, C. J., Bergel, A., & Diaz, M. A.
Affiliations
  • University of Chile (CL)
  • Electrical Engineering Department, Space and Planetary Exploration Laboratory (SPEL), Faculty of Physical and Mathematical Sciences, University of Chile, Santiago, Chile
ORCID
Venue
IEEE Access
Publisher
Institute of Electrical and Electronics Engineers (IEEE)
Published
2019
Volume
7
Pages
126409-126429
ISSN
2169-3536 (ISSN-L)
DOI
10.1109/access.2019.2927931
OpenAlex
W2961353240
Cited by
31
References
42
Citations by year
2026: 5 · 2025: 4 · 2024: 4 · 2023: 6 · 2022: 3 · 2021: 6 · 2020: 3
FWCI
1.38
Type
journal article
Language
en
Open access
Licence
Locations
  • IEEE Access (publishedVersion, cc-by)
  • DOAJ (DOAJ: Directory of Open Access Journals) (submittedVersion, cc-by-sa)
Funders
  • Grant Fondecyt (1151476)
  • Grant Anillo (ACT1405)
  • Grant Fondequip (EQM150138)
  • Comisión Nacional de Investigación Científica y Tecnológica
Topics
  • Physical Sciences › Computer Science › Software › Advanced Software Engineering Methodologies
  • Physical Sciences › Engineering › Aerospace Engineering › Spacecraft Design and Technology
  • Physical Sciences › Computer Science › Software › Model-Driven Software Engineering Techniques
Keywords
CubeSat, nanosatellites, architecture verification, non-functional requirements, embedded software, agile software development, software quality, open source tools, software analysis tools

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review