The capabilities of CubeSats have grown significantly since the first of these small satellites was launched in the early 2000s. These capabilities enable a wide range of mission profiles, with CubeSats emerging as viable platforms for certain space-based astronomical research applications. The Educational Irish Research Satellite (EIRSAT-1) is a CubeSat being developed as part of the European Space Agency’s Fly Your Satellite! program. In addition to its educational aims, the mission is driven by several scientific and technological goals, including goals related to a novel gamma-ray instrument for the detection of bright transient astrophysical sources, such as gamma-ray bursts. This work provides a detailed description of the software development life-cycle for EIRSAT-1, addressing the design, development and testing of robust flight software, aspects of payload interfacing, and risk mitigation. The described design-to-testing approach was implemented to establish, prior to launch, that EIRSAT-1 can perform its intended mission. Constraints and challenges typically experienced by CubeSat teams, which can impact the likelihood of mission success, are considered throughout this work, and lessons learned are discussed. The aim of this work is to highlight the advanced capabilities of CubeSats while providing a useful resource for teams implementing their own flight software. |
1.IntroductionThe concept of CubeSats—nanosatellites measured in units (U) of and weighing 1—was first proposed in the late-1990s as a teaching tool for university-level students.2,3 More than 20 years and 1800 launches later,4 CubeSats are now considered by many to be a disruptive space innovation.5–7 The CubeSat design specification defines a compact satellite form factor,1 facilitating the use of commercial off-the-shelf components (COTS) and drastically reducing the cost of space entry compared with conventional approaches, which typically employ large, one-off spacecraft.8 The resulting accessibility of CubeSats drives their growing popularity, with each five-year period since 2000 witnessing 24, 78, 415, and 1109 CubeSats launches, respectively.4 In parallel, and as a result of recent advances in technology miniaturization, the capabilities of CubeSats have also grown such that their mission objectives now span technology demonstration, communications, Earth observation, and science.7 Their usefulness for diverse research areas in astrophysics, heliophysics, and deep space exploration are becoming more widely understood and acknowledged.9–12 As one example, the multi-messenger era of astronomy, in which astrophysical sources are studied through electromagnetic, gravitational wave (GW), and particle channels, was boosted in 2017 with the first joint detection of a gamma-ray burst (GRB)13 and a GW signal from the merger of two neutron stars.14 There are significant observational challenges to making progress beyond this first detection. The gamma-ray sources are short-lived (tens of seconds long), and their locations are unpredictable. To maximize the chances of more joint GRB and GW detections, all-sky coverage of the gamma-ray sky is required. Although this is mostly achieved by the current fleet of -ray satellites (e.g., INTEGRAL,15 the Neil Gehrels Swift Observatory,16 Fermi,17,18 and ASTROSAT19), these missions are operating well beyond their intended lifetimes. For example, INTEGRAL was launched in 2002 with a 2-5 year mission lifetime. For the detection of bright, transient sources such as GRBs, CubeSats offer a low-cost, fast-paced alternative to traditional large gamma-ray astronomy missions. One example is GRBAlpha—a 1U CubeSat that was launched in March 2022 and is equipped with a miniaturized -ray sensor20 to detect GRBs. GRBAlpha also aims to test the in-flight performance of technologies for a constellation of CubeSats, known as CAMELOT.21,22 As of June 2022, GRBAlpha has successfully detected at least five GRBs. Other examples of GRB-dedicated CubeSat missions include VZLUSAT-2,23 BurstCube,24 and HERMES.25 To advance the use of CubeSats as viable platforms for gamma-ray astrophysics research, this work presents details on CubeSat flight software (Sec. 2). More specifically, a detailed description of the design (Secs. 3 and 4) and the development and testing (Sec. 5) of flight software for the EIRSAT-1 mission and its primary -ray detector payload is presented. Aspects of the software development process dedicated to improving reliability through extensive testing methods are discussed in Sec. 5. Finally, key lessons learned from developing flight software for a CubeSat mission are presented in Sec. 6. 1.1.Educational Irish Research SatelliteThe Educational Irish Research Satellite (EIRSAT-1), as shown in Fig. 1, is a 2U CubeSat being developed by a student-led team at University College Dublin (UCD).26 The project, which aims to launch EIRSAT-1 as Ireland’s first satellite, is supported by the Education Office of the European Space Agency (ESA), under the second round of the Fly Your Satellite! (FYS!) program.27 The main objective of the mission is to enhance the capabilities of the national higher education sector in space science and engineering. However, the project is also motivated by a number of technology demonstration and scientific aims,26 to be achieved with three novel payloads. The ENBIO Module (EMOD) is a thermal materials experiment,28,29 Wave-Based Control (WBC) is a software-based attitude control test-bed,30 and the Gamma-Ray Module (GMOD), discussed in Sec. 1.2, is a miniaturized -ray detector.31,32 The EIRSAT-1 spacecraft consists of custom hardware that was designed in-house for the EMOD and GMOD payloads. An antenna deployment module (ADM),33 which is responsible for deploying the mission’s Ultra High Frequency (UHF)/Very High Frequency (VHF) antenna elements on-orbit, was also developed in-house. The remainder of the spacecraft consists of COTS components supplied by AAC Clyde Space, including the battery, electrical power system (EPS), solar cells, radio transceiver, attitude determine and control system (ADCS), and onboard computer (OBC). Two versions of the EIRSAT-1 spacecraft—an engineering qualification model (EQM) and a near-identical flight model (FM)—are being built as part of this project to reduce the level of risk arising from the team’s initial lack of experience with spacecraft development as well as the complexity of the mission’s payloads/objectives.34 1.2.Gamma-Ray ModuleThe primary aims of the GMOD payload are to detect GRBs, assess the on-orbit performance of novel gamma-ray detection technology, and demonstrate the role of CubeSats in the multi-messenger era of astrophysics. GMOD (Fig. 1) is a miniaturized -ray detector that was developed in-house. The payload comprises a motherboard, with the necessary electronics to operate the payload, and a detector assembly.31,32 This assembly consists of a cerium bromide () scintillator crystal, an array of silicon photomultipliers (SiPMs), and low-power read-out electronics, which are all contained within a compact, light-tight enclosure. For each high-energy photon incident on the detector assembly, a time-tagged event (TTE) is produced, with an ADC value corresponding to the photon’s energy.32 The TTEs produced by GMOD on-orbit will be used to understand the payload’s -ray environment and to study high-energy events, such as GRBs.32,35,36 GMOD is expected to detect between 11 and 14 GRBs per year (in an energy range from tens of keV to a few MeV), at a significance greater than (and up to 32 at ).31 2.CubeSat Flight SoftwareFlight software generally refers to the onboard software responsible for the on-orbit behavior of the complete satellite system, performing a wide range of tasks from subsystem interfacing to data handling and fault management. Its reliable performance is essential to mission success. Although CubeSats are much smaller than conventional spacecraft that are typically employed for astronomical research, the required flight software in many ways faces similar needs and challenges to that of larger missions—flight software complexity is not proportional to the satellite volume.37 To implement this software in a way that is consistent with the low-cost, fast-paced CubeSat design philosophy, several platforms that assist the software development process (also known as frameworks) have been developed. Some examples are
These frameworks, some of which are reviewed in comparison studies by Refs. 37 and 42, aim to reduce project costs and development times through software reusability, similar to the approach driving the use of standardized COTS hardware. Alternative approaches to the use of frameworks include re-use of software that was previously developed in-house, use of open-source materials, such as code provided by the Libre Space Foundation,43 and in-house development from scratch. However, the lack of specialized literature on the topic has been identified as a potential challenge for CubeSat teams when developing flight software.44 To address this deficit in knowledge dissemination around flight software development for CubeSats, this paper documents the approach adopted for EIRSAT-1, complementing the existing literature on other CubeSat missions, including Refs. 4445.46.–47. 3.Design DriversThere are several factors that drive a CubeSat’s flight software design and development. In the case of EIRSAT-1, these are (i) the mission requirements (Sec. 3.1), (ii) the available resources (Secs. 3.2 and 3.3), and (iii) the planned strategy for operating the mission (Sec. 3.4). 3.1.RequirementsRequirements concisely state some goal that “shall” be achieved. More formally, the European Cooperation for Space Standardisation (ECSS) define a requirement as a “documented demand to be complied with.”48 A project’s requirements are typically defined during the very early project phase and provide the foundation for the CubeSat design, including the flight software design. Requirements capture, at a high-level, what the satellite system must do to achieve the mission’s objectives and the constraints within which it must perform. Two sets of requirements are associated with EIRSAT-1.
Table 1 shows some of the requirements that must be satisfied (at least in part) by the flight software. Prior to launch, the capability of the mission to satisfy these requirements must be formally verified. This is primarily achieved via testing (Sec. 5.3), with the test setup, test procedures, and as-run results being extensively documented. Table 1Example requirements from the EIR_TS and the FDS.
In addition to the strict set of requirements set out in the EIR_TS and FDS, the project also follows the guidance of ECSS standards, which act as a coherent, single set of standards for use in European space activities. These standards provide exhaustive lists of requirements and recommendations encouraging best practices and are presented in several documents that are specific to different areas of space mission development. Given the extent of the information provided within these documents, ECSS standards are typically tailored and used by teams in a way that best suits their projects.44,49,50 For EIRSAT-1, this tailoring is decided on with input from FYS!, but it is largely driven by what is feasibly achievable given the timeline and resources available to the CubeSat project. 3.2.Computer HardwareA spacecraft’s hardware design is largely defined during a very early project phase and typically precedes any major software development activities. The flight software design is then driven by the hardware architecture for which it is being developed. For EIRSAT-1, the flight software can be categorized based on hardware, as given in the following.51
The below work is primarily focused on the OBC-run software, which is referred to as the “main” flight software. The OBC for which this software is developed is provided by AAC Clyde Space. It is built around a MicroSemi SmartFusion2 System-on-Chip and incorporates an ARM Cortex M3 processor. The memory bus consists of 8 MB of magnetoresistive RAM (MRAM) storage, as well as 4 GB of flash memory, both of which are protected against radiation effects via an error detection and correction mechanism. The OBC is equipped with multiple onboard data buses, including I2C and serial/UART. The AAC Clyde Space OBC was primarily chosen for EIRSAT-1 given its flight heritage as well as the possibility of procuring all COTS components from a single supplier. As an additional advantage, a FSDK supports software development for this OBC. 3.3.ResourcesAs this is Ireland’s first satellite, there was no in-house developed software with flight heritage. To reduce risk, the Bright Ascension GenerationOne FSDK was selected for this project. This kit allows for rapid development of flight software, in the C programming language, using a model-based development approach known as component-based development. In this context, a component is a reusable, standalone software module in which a certain set of functions are implemented. Components are then integrated to form a mission’s flight software image. The FSDK is provided with libraries of prevalidated components—many with flight heritage—including components that provide low-level, supplier-specific hardware interfacing through to high-level functionality. The kit is also equipped with development and test tools, such as those for automatic code generation. Although this kit and kit-driven development in general were considered a good fit for EIRSAT-1 over other development options, some of which are discussed in Sec. 2, this is not necessarily the case for all CubeSat teams. Table 2 highlights the key advantages and potential disadvantages of this approach, which ultimately favored the use of the Bright Ascension FSDK for the EIRSAT-1 project.51 Table 2Advantages (‘✓’) and potential disadvantages (‘×’) of kit-driven development.51
3.4.Concept of OperationsA system’s concept of operations (ConOps) describes the strategy for operating the system from the point of view of the user/operator. Many aspects of a system’s ConOps must be implemented, or at least accounted for, in the system’s software design. For example, a common ConOps strategy used for space missions is to use operational modes, whereby the mission operator gains an initial understanding about the state of the spacecraft based on the current mode.44,52–54 Modes also generally dictate which of the satellite’s subsystems are active and what activities are on-going at any point in time. The software implementation of operational modes and mode management for EIRSAT-1 is discussed in Sec. 4. 4.Main Flight Software DesignThe OBC’s memory is mapped to hold more than one mission image at a time. Embedded flash memory is used to hold a 256 KB “failsafe” image, and part of MRAM is used for two 1 MB “primary’ images.”55 The primary image slots are intended for images compiled with all of the components that allow EIRSAT-1 to fully achieve its mission objectives. Two images slots are provided to facilitate on-orbit image updates without the need to overwrite the existing/active image. In contrast, the failsafe image slot is intended to hold a simplified image, with fewer components and only the functionality needed to keep the mission in a stable, operable state. At start-up, the OBC’s bootloader determines which of these images to load based on configurable data stored in MRAM. In the event of multiple or unsuccessful reboots (e.g., as a result of an unstable image), the OBC defaults to operating in failsafe. The software architecture of the primary mission image is presented in Sec. 4.1, followed by a more detailed description of key components related to onboard operational state management (Sec. 4.2), subsystem interfacing (Sec. 4.3), and fault protection (Sec. 4.4). 4.1.Flight Software ArchitectureFigure 2 presents a block diagram of the main flight software architecture, in which software components are grouped and placed into tiers based on their function.51
Much of the functionality provided by the two lower tier components in this architecture is standard across different space missions. For instance, all missions require at least some data aggregation and logging functionality as part of their onboard data handling (OBDH) software. As another example, missions employing AAC Clyde Space subsystems must implement similar software to interface with this hardware. To address this, the Bright Ascension FSDK is provided with much of this functionality implemented in (near) flight-ready components. As a result, the in-house development time required for different aspects of the flight software is well represented by the architecture in Fig. 2, with the management tier requiring the most effort.51 This is for two reasons: (i) in some instances, the management tier functions required more mission-specific software (e.g., to implement EIRSAT-1’s ConOps approach [Sec. 3.4]) and (ii) many of the management tier functions are critical to mission success. Therefore, for cases in which kit-provided software was available, significant efforts were still given to developing a more in-depth understanding of the software, to ensure that its functionality was used and tested correctly. This was particularly the case when modifications to the software were required. For the capabilities tier, the in-house development time was primarily dedicated to payload software development. The remaining efforts then, across all tiers, was focused on any mission-specific updates required to kit-provided components and bug fixes. Software components from the management and capabilities tiers that are essential to achieving EIRSAT-1’s objectives are now discussed in more detail. 4.2.Operational State Management4.2.1.Configuration managerThe configuration manager component manages the persistence of data through OBC reboots. When its functions are called by other components within the image, the configuration manager stores a select amount of data (i.e., stores values of a set number of parameters) to the OBC’s non-volatile MRAM. Following a reboot, the persisted data are then loaded from MRAM. The usefulness of this functionality is best demonstrated by the mode manager component (Sec. 4.2.3), which uses the last known u8_Mode parameter value to determine which operational mode should be loaded following a reboot. Caution must be taken with this functionality as reboots are an important method of recovering software to a known, working state in the event of an anomaly. The more data that are persisted by this component, the less effective a reboot is at recovery. Therefore, only a small sub-set of parameters with persisted states that serve a functional purpose (e.g., u8_Mode) are persisted within the main flight software image. 4.2.2.Separation sequenceThis component is responsible for the satellite’s immediate post-launch behavior—referred to as the “separation sequence”—and is designed to reliably enable two-way communications with the spacecraft via a series of automatic onboard operations. In software, this component is built as a basic finite state machine, in which the required operations occur as part of different states. The sequence of states and their primary tasks are as follows:
During the separation sequence, steps 3 to 5 are repeated. Deployment attempts are periodically carried out, alternating between the primary and secondary antenna release mechanisms, and are separated by a wait period (that is not a multiple of the orbital period so that deployment attempts occur at different ambient temperatures). This chain of functionality is represented in Fig. 3. The sequence will be configured to initialize following the first-boot on-orbit. A telecommand is required to terminate the sequence, following which the sequence’s u8_State: finished state will be persisted by the configuration manager. Given the importance of this component in achieving AOS, its reliability in the event of a fault is essential, motivating a number of design decisions. For instance, (i) the ADM watchdog functionality ensures the ADM firmware can reliably be commanded throughout the sequence, ensuring the primary antenna release mechanism is operable; (ii) the separation sequence only ceases to cycle through deployment attempts in response to a telecommand, instead of automatic onboard logic, which might use, for example, the status of the ADM’s door switches. This approach removes any reliance on additional functionality/hardware and reduces the risk of the sequence ceasing early, for example prior to a successful deployment due to a faulty switch reading; (iii) the wait time implemented between deployment attempts allows for time for battery charging between resistor burns but also ensures an eventual deployment attempt in favorable temperature conditions; and (iv) both the failsafe and primary images are equipped with this component and are configured at launch to enter the sequence’s u8_State : initialization state. 4.2.3.Mode managerThe mode manager component is responsible for determining and setting the operational mode of EIRSAT-1. Modes allow operators to rapidly assess the operational state of the spacecraft and determine which subsystems are active and what, if any, autonomous activities have recently occurred. The mode manager is implemented in software as a finite state machine that sets up a defined configuration while transitioning between states via mode-specific exit and entry functions. The modes implemented in EIRSAT-1’s mode manager are given in the following:
Unlike the separation sequence, in which state changes are almost entirely autonomous, mode transitions are invoked via both autonomous and commanded operations in the mode manager component and do not follow a set sequence. The different modes defined for EIRSAT-1 and the operations that invoke mode transitions are shown in Fig. 3. 4.3.Subsystem InterfacingThe Bright Ascension FSDK comes with software components for interfacing with some supplier-specific COTS hardware, including AAC Clyde Space subsystems. Therefore, kit-provided components were implemented in the main flight software’s capabilities tier to interface with the EPS, ADCS, transceiver, and battery, with only minor updates made, e.g., to implement bug fixes. In contrast, software components for the custom payloads were developed entirely in-house. Section 4.3.1 provides an overview of the GMOD software component, which provides an interface to the payload and performs key tasks associated with the payload’s scientific objectives. Further details about the GMOD firmware with which this component interfaces are provided in Refs. 32, 35, and 36. 4.3.1.GMODGMOD (Sec. 1.2) is the primary scientific payload, with a scientific goal of detecting GRBs. Key requirements driving the design of the software components are given in Table 1. To satisfy these requirements, the GMOD software component is designed with the following functionality. Data handling and storageWhen configured to run its primary experiment, the GMOD payload collates 256-byte ‘pages’ of TTE data, which are stored to its flash memory.32 The expected rate at which data will be produced on-orbit ranges from to 30 pages/second, which correspond to the -ray background (i.e., a TTE rate) and a GRB, respectively. A parameter in the payload firmware, that is settable via I2C communication, controls whether GMOD periodically sends, or “streams,” data from GMOD’s flash memory to the OBC. The fastest period at which this can occur is also controlled by a configurable parameter (0.2 s is configured by default, which allows the page streaming rate to keep pace with potential page production rates). This streaming approach was chosen over an implementation in which the OBC requested pages one at a time via I2C commands to reduce the computational resources required to transfer science data to the OBC. Although I2C communication is adopted for all commanded operations of GMOD, the pages of TTE data are transferred to the OBC via serial, with each payload having access to an independent port. This implementation was chosen to minimize traffic on the payloads’ I2C bus, which is shared by both EMOD and GMOD. As pages are received, GMOD’s main flight software component first assesses the validity of the data (e.g., by comparing a checksum transferred with the data to a calculated checksum) before parsing the data into individual TTEs, each with a 4-byte coarse timestamp, 4-byte fine timestamp, and 12-bit ADC value.32 These TTEs are then passed to a number of different functions within the component, as described below and summarized in Fig. 4. Finally, this software component collates the TTE data received into 16-page “sectors,” before storing the data to the OBC’s flash memory for later downlink to the ground station. Approximately 1.25 GiB of memory was allocated for this purpose; this is sufficient for holding days worth of data. Using calibration data obtained prior to launch, TTE ADC values will be converted to physical energy units on the ground following downlink of the data. GMOD’s time is synced with that of the OBC during the experiment setup and will be maintained using the output of the OBC’s pulse per second pin. TTE timestamps will be converted to UTC on the ground from the onboard time (OBT) frame, using OBT and GPS time data that is periodically logged to onboard storage as well as transmitted as part of a beacon. Because GMOD’s main flight software component uses OBT and raw ADC values in its operation, these TTE conversions do not need to be implemented onboard the spacecraft. Light curve and spectrum generationThe mission will make use of one primary ground station, located at UCD (53.3065°N, 6.2255°W), allowing for of communication time with the spacecraft per day. As a result, when prolonged nominal operations are achieved, GMOD will likely produce more TTE data than is feasible to downlink. For this reason, in addition to logging sectors of “raw” TTE data for downlinking, GMOD’s main flight software component also packs the TTE data into more compressed data products, namely light curves and spectra (Fig. 5). Two buffers are defined in the software to build these light curves and spectra. The light curve buffer is 2000 bytes in size to provide 1000 uint16 time bins, and the spectrum buffer is 480-bytes, with 240 uint16 ADC/energy bins. As page data are received and parsed into individual TTEs, this component adds to these buffers, separating events into bins based on their timestamp and ADC/energy. By default, the GMOD component generates 20-min light curves and spectra; however, the time bin widths and integration times used to generate these products are configurable with millisecond and second resolution, respectively. When the buffers are “full” (i.e., when the last time bin of the light curve is reached, and the spectrum integration time has elapsed), frame data are appended to the buffers with information on the generated data products before the data are logged to the OBC’s flash memory for later downlink.32 Following logging, a new light curve and spectrum are started. To manage constraints on two-way communication time with the spacecraft, these light curves and spectra will regularly take downlink preference over the sectors of raw TTE data. However, in some cases, the TTE data will be assigned higher priority. Examples of such cases include (i) during commissioning, when the less compressed data type will be more useful for assessing the payload’s health and performance; (ii) when performing a more detailed analysis on EIRSAT-1’s -ray environment; (iii) if anomalous results/features are observed in the data; and (iv) when a GRB is detected (discussed below). GRB triggeringAn additional capability of the GMOD main flight software component is triggering, in which the software can identify and act on high signal-to-noise (S/N) ratios within the TTE data. To achieve this, the parsed page data are also added to a separate “triggering” light curve buffer, measuring up to 8192 uint16 time bins. Unlike the light curves discussed above, which are built, logged, and restarted every minutes, the triggering light curve is implemented as a circular buffer, which is continuously updated with newer data at the expense of the oldest data in the buffer. The time bins comprising this light curve are divided into three segments, referred to as the “background window,” the “signal window” and the “signal window offset,” which separates the background and signal segments by a configurable number of bins. As event data are added to the triggering light curve, the sum of events in these segments is calculated and passed to a triggering algorithm where u32_Sig is the calculated significance of the signal within the signal window, (TTEs in the signal window bins), (TTEs in the background window bins), and (i.e., a scaling factor given the ratio of the background window size, in terms of bins, compared with the signal window).If a high S/N ratio is detected in the signal window through this algorithm (i.e., if u32_Sig > u32_SigThreshold, where u32_SigThreshold is configurable), the component marks that a trigger has occurred. The data acquisition process then continues as normal for a configurable time period to allow the OBC to acquire some post-trigger data before the following tasks are performed:
More information about the planned on-orbit operation of GMOD is provided in Ref. 57. 4.4.Fault ProtectionThe Bright Ascension FSDK is equipped with a number of features and components intended to help implement autonomous FDIR methods, including:55
Table 3 provides examples of the integration of these autonomous FDIR features into the main flight software to reduce the risk of mission loss. Table 3Examples of FDIR functionality implemented in EIRSAT-1’s main flight software, where TC = telecommand, S/C = spacecraft, and n denotes parameters that are configurable via TC.
Fault tree analyses were performed to (i) better understand the spacecraft’s expected on-orbit behavior in the event of a fault; (ii) determine how the flight software could be improved to ensure a robust system; and (iii) assess the mission’s ability to recover, at least to a “safe” state, using the FDIR functions. 5.Development and TestingDevelopment and testing of the main flight software largely proceeded in parallel from the outset. Introducing software test and verification activities from an early stage in the development process has several advantages, including (i) improved understanding of the expected performance of the software as part of the full satellite system through hardware-in-the-loop (HIL) testing; (ii) rapid identification of bugs and design issues; and (iii) building confidence in the flight software before proceeding to more formal test and requirement verification campaigns. 5.1.Setup and Tools5.1.1.Development environmentThe Eclipse58 integrated development environment for C/C++ developers was chosen to implement the flight software. This choice was driven by the availability of Eclipse plug-ins, which provide automatic-code generation capabilities, with the Bright Ascension FSDK. This tooling also generates “spacecraft databases,” which list all of the accessible parameters and functions provided by the flight software. These databases can then be used with mission control software to interface with the spacecraft. 5.1.2.Version controlGit59 and GitHub60 are used to track day-to-day software development activities. Git releases mark more significant milestones in the development process. Software releases are made prior to the project’s formal test and requirement verification campaigns, with a given software version being used throughout the campaign. A software configuration file is separately maintained in Google sheets to capture, at a high-level, any updates made to the software components between releases. Google sheets were adopted for this purpose over other, more conventional methods (e.g., a GitHub wiki or more detailed Git release notes) primarily as the Bright Ascension FSDK auto-generates documentation that includes a csv file listing an image’s constituent components. The presentation of EIRSAT-1’s main flight software as a simplified list of components has been particularly useful for communicating summaries of software updates to ESA/FYS!. Furthermore, Google sheets are easily shared (with limited access/permissions) to facilitate reviews by external ESA experts. In the absence of further software updates following testing, the released software will be used for flight. 5.1.3.Continuous integrationUsing a Docker image with the necessary build tools, CircleCI61 was integrated with GitHub to automatically build the flight software and perform basic checks each time a commit is made to the Git repository. If the build succeeds and checks are passed, merging of Git branches into the main development branch is “unlocked.” This process alerts developers to issues with their code and protects the main development branch. For EIRSAT-1, these checks include standard compiler checks and unit tests (discussed in Sec. 5.3). However, more rigorous checks, for instance, using static code analysis tools, can also be implemented. The flight software images built as part of this process are used for HIL test activities to ensure that images programmed onto the OBC are generated using a consistent build environment. 5.1.4.TestingThe following setups and tools are used for testing throughout the software development process.
Where required, mission control software provided by Bright Ascension, along with a spacecraft database, is used to facilitate TM/TC communication with the flight software. 5.2.Life CycleThe main flight software was produced following an iterative and incremental development process. The timeline over which this development took place is strongly tied to the mission’s two-model philosophy. More specifically, a flight-worthy version of the software was “frozen” prior to the EQM test and requirement verification campaign. By aiming to freeze a (near) flight-ready version of the software for EQM testing, the main flight software is extensively tested twice, through both the EQM and FM test campaigns, providing confidence in the software design and implementation. The risk of project delays arising from software development is also reduced by this parallel development approach. 5.3.TestsTesting of the main flight software was undertaken throughout the development process. 5.3.1.Unit testingIn unit testing, individual units, corresponding to an individual software component, of source code are tested. Unit testing allows the behavior of blocks or units of code to be verified prior to further development or other test activities. It also provides testing for code that otherwise might not be readily assessed. A component’s run-time environment is mimicked, and its functions are then called, with inputs where required. The resulting output, or behavior, of the functions is then compared with the expected output. Unit testing is implemented using a framework provided with the Bright Ascension FSDK that makes use of the CMock and Unity63,64 testing tools. A further benefit of unit testing relates to code changes, in which previously implemented tests can be run after a change to inspect if the performance of the component was impacted and whether the impact was as expected. For EIRSAT-1, this functionality is implemented using CirceCI (Sec. 5.1.3), in which unit tests are automatically compiled and run and the results are checked each time a commit is made to the Git repository in which the software was developed. When a compile or unit test fails, CircleCI automatically emails the software developer to alert them to this failure, so it can be resolved before the code is merged into the main software development branch. For kit-provided components (many with flight heritage), in which unit tests were also provided, test coverage ranges between and 100% and averages . Due to resource constraints, unit test development has focused on in-house developed components that are critical to EIRSAT-1’s on-orbit performance and safety, particularly the mode manager and separation sequence components. Using the gcov test coverage program to assess the quality/completeness of the tests, 76 – 96% coverage was achieved for these components. Lower coverage metrics are currently achieved for less critical in-house developed components, including those that implement the GMOD, EMOD, and WBC experiments. Testing of these components through, for example, HIL testing is described in Sec. 5.3.2. 5.3.2.Integration and HIL testingDuring integration tests, software components are brought together to form a software image. This image is then run on either the developer’s desktop or on the OBC to test the functionality of the integrated components. Integration testing also commonly includes other spacecraft hardware to allow for HIL testing. As many of the main flight software components interact with, and use data from, the spacecraft’s hardware, HIL tests provide the most representative environment to test the software’s performance. In addition to HIL tests performed during the software development process, the main flight software was also tested with the spacecraft’s hardware as part of test campaigns during which the mission’s requirements were formally verified.34 Although these tests were primarily focused on the mission’s performance as a whole, their success required the reliable performance of the main flight software. The following tests were included.
6.Lessons LearnedEIRSAT-1’s main flight software was developed with an overarching aim of maximizing the likelihood of mission success given the project’s highly constrained resources and initial lack of expertise. The success of the approaches taken was demonstrated through a test campaign with an EQM of the spacecraft, in which the flight software largely performed as intended.69 Further confidence in the software’s performance will be achieved via the FM test campaign. Key lessons learned from the experience to date are given in the following.
7.ConclusionsFor certain applications, CubeSats offer an alternate and more accessible route to space in comparison with conventional satellites, which typically require highly specialized facilities and are more costly to develop. Advances in miniaturized technologies have allowed the capabilities of CubeSats to grow, widening the scope of this small satellite platform well beyond education to encompass Earth observation, communications, astrophysics, and heliophysics. To further advance the use of CubeSats as capable and reliable platforms for scientific research, this work presents key details on the design, development, and testing of robust flight software for the EIRSAT-1 mission. The reliable performance of the software methods implemented was demonstrated through a comprehensive test campaign with an EQM of the EIRSAT-1 spacecraft. An FM test campaign is the next step in the verification of the flight software for the mission. AcknowledgmentsThe EIRSAT-1 project is supported by ESA Education, under the second round of the FYS! program. The authors thank the Bright Ascension support team for their continued support and guidance. The project acknowledges all students who have contributed to the development of EIRSAT-1 and support from Parameter Space Ltd. M.D., R.D., D.M., L.S., and J.T. acknowledge support from the Irish Research Council (Grant Nos. GOIPG/2018/2564, GOIPG/2019/2033, GOIPG/2014/453, GOIPG/2017/1525, and GOIPG/2014/684, respectively). N.W. acknowledges support from Science Foundation Ireland (SFI) (Grant No. 19/FFP/6795). G.F. acknowledges support from a scholarship associated with the UCD Ad Astra fellowship program. D.M., A.U., J.M., and S.M. acknowledge support from SFI (Grant No. 17/CDA/4723). S.W. acknowledges support from ESA (PRODEX contract number 400012071). J.E. and J.R. acknowledge scholarships from the UCD School of Physics. L.H. acknowledges support from SFI (Grant No. 19/FFP/6777) and support from EU H2020 AHEAD2020 project (Grant No. 871158). This study was supported by ESA’s Science program (contract 4000104771/11/NL/Cbi) and by ESA’s PRODEX program (contract number C 4000124425). This work is based on content previously reported at the SPIE Software and Cyberinfrastructure for Astronomy VII conference, and will appear in the conference proceedings. ReferencesCalifornia Polytechnic State University,
“CubeSat design specification (CDS) Rev 13, CP-CDS-R13,”
(2015). Google Scholar
H. Heidt et al.,
“CubeSat: a new generation of picosatellite for education and industry low-cost space experimentation,”
in Proc. 14th Annu. AIAA/USU Conf. Small Satellites, SSC00-V-5,
(2000). Google Scholar
National Aeronautics and Space Administration (NASA), CubeSat 101: Basic Concepts and Processes for First-Time CubeSat Developers, 1st ed.NASA CubeSat Launch Initiative(
(2017). Google Scholar
L. Summerer,
“Signs of potentially disruptive innovation in the space sector,”
Int. J. Innov. Sci., 3
(3), 127
–140 https://doi.org/10.1260/1757-2223.3.3.127
(2011).
Google Scholar
T. H. Zurbuchen,
“Achieving science with CubeSats: thinking inside the box (conference presentation),”
Proc. SPIE, 9978 997802 https://doi.org/10.1117/12.2238764 PSISDG 0277-786X
(2016).
Google Scholar
T. Villela et al.,
“Towards the thousandth cubesat: a statistical overview,”
Int. J. Aerosp. Eng., 2019 1
–13 https://doi.org/10.1155/2019/5063145
(2019).
Google Scholar
C. Cappelletti, S. Battistini and B. Malphrus, CubeSat Handbook: From Mission Design to Operations, Elsevier(
(2020). Google Scholar
E. L. Shkolnik,
“On the verge of an astronomy CubeSat revolution,”
Nat. Astron., 2
(5), 374
–378 https://doi.org/10.1038/s41550-018-0438-8
(2018).
Google Scholar
K. Woellert et al.,
“Cubesats: cost-effective science and technology platforms for emerging and developing nations,”
Adv. Space Res., 47
(4), 663
–684 https://doi.org/10.1016/j.asr.2010.10.009 ASRSDW 0273-1177
(2011).
Google Scholar
A. Poghosyan and A. Golkar,
“CubeSat evolution: analyzing CubeSat capabilities for conducting science missions,”
Progr. Aerosp. Sci., 88 59
–83 https://doi.org/10.1016/j.paerosci.2016.11.002 PAESD6 0376-0421
(2017).
Google Scholar
P. F. Bloser et al.,
“CubeSats for gamma-ray astronomy,”
(2022). Google Scholar
P. Mészáros,
“Gamma-ray bursts,”
Rep. Progr. Phys., 69
(8), 2259
–2321 https://doi.org/10.1088/0034-4885/69/8/R01
(2006).
Google Scholar
B. P. Abbott et al.,
“Gravitational waves and gamma-rays from a binary neutron star merger: GW170817 and GRB 170817A,”
ApJL, 848 L13 https://doi.org/10.3847/2041-8213/aa920c
(2017).
Google Scholar
C. Winkler et al.,
“The INTEGRAL mission,”
Astron. Astrophys., 411 L1
–L6 https://doi.org/10.1051/0004-6361:20031288 AAEJAF 0004-6361
(2003).
Google Scholar
N. Gehrels et al.,
“The swift gamma-ray burst mission,”
Astrophys. J., 611
(2), 1005
–1020 https://doi.org/10.1086/422091 ASJOAB 0004-637X
(2004).
Google Scholar
C. Meegan et al.,
“The fermi gamma-ray burst monitor,”
Astrophys. J., 702
(1), 791
–804 https://doi.org/10.1088/0004-637X/702/1/791 ASJOAB 0004-637X
(2009).
Google Scholar
W. B. Atwood et al.,
“The large area telescope on the fermi gamma-ray space telescope mission,”
Astrophys. J., 697
(2), 1071
–1102 https://doi.org/10.1088/0004-637X/697/2/1071 ASJOAB 0004-637X
(2009).
Google Scholar
K. P. Singh et al.,
“ASTROSAT mission,”
Proc. SPIE, 9144 517
–531 https://doi.org/10.1117/12.2062667 PSISDG 0277-786X
(2014).
Google Scholar
A. Pál et al.,
“GRBAlpha: a 1U CubeSat mission for validating timing-based gamma-ray burst localization,”
Proc. SPIE, 11444 114444V https://doi.org/10.1117/12.2561351 PSISDG 0277-786X
(2020).
Google Scholar
N. Werner et al.,
“CAMELOT: cubesats applied for measuring and localising transients mission overview,”
Proc. SPIE, 10699 106992P https://doi.org/10.1117/12.2313764 PSISDG 0277-786X
(2018).
Google Scholar
M. Ohno et al.,
“CAMELOT: design and performance verification of the detector concept and localization capability,”
Proc. SPIE, 10699 1069964 https://doi.org/10.1117/12.2313228 PSISDG 0277-786X
(2018).
Google Scholar
J. Ripa et al., GRB 220320A: detection by VZLUSAT-2 1
(2022). Google Scholar
J. S. Perkins et al.,
“BurstCube: a CubeSat for gravitational wave counterparts,”
Proc. SPIE, 11444 114441X https://doi.org/10.1117/12.2562796 PSISDG 0277-786X
(2020).
Google Scholar
F. Fiore et al.,
“The HERMES-technologic and scientific pathfinder,”
Proc. SPIE, 11444 114441R https://doi.org/10.1117/12.2560680 PSISDG 0277-786X
(2020).
Google Scholar
D. Murphy et al.,
“EIRSAT-1 – The Educational Irish Research Satellite,”
in Proc. 2nd Symp. Space Educ. Activities (SSEA), SSEA-2018-73,
(2018). Google Scholar
J. Vanreusel,
“Fly your satellite! The ESA Academy CubeSats programme,”
in ITU Symp. & Workshop on Small Satellite Regulation and Commun. Syst,
(2016). Google Scholar
K. Doherty et al.,
“High-temperature solar reflector coating for the solar orbiter,”
J. Spacecraft Rockets, 53 1
–8 https://doi.org/10.2514/1.A33561
(2016).
Google Scholar
K. A. J. Doherty et al.,
“Flat absorber coating for spacecraft thermal control applications,”
J. Spacecraft Rockets, 53
(6), 1035
–1042 https://doi.org/10.2514/1.A33490
(2016).
Google Scholar
D. Sherwin et al.,
“Wave-based attitude control of EIRSAT-1, a 2U CubeSat,”
in Proc. 2nd Symp. Space Educ. Activities, SSEA-2018-93,
(2018). Google Scholar
D. Murphy et al.,
“A compact instrument for gamma-ray burst detection on a CubeSat platform I,”
Exp. Astron., 52
(1–2), 59
–84 https://doi.org/10.1007/s10686-021-09779-9 EXASER 0922-6435
(2021).
Google Scholar
D. Murphy et al.,
“A compact instrument for gamma-ray burst detection on a CubeSat platform II,”
Exp. Astron., 53 961
–990 https://doi.org/10.1007/s10686-022-09842-z EXASER 0922-6435
(2022).
Google Scholar
J. Thompson et al.,
“Double-dipole antenna deployment system for EIRSAT-1, a 2U CubeSat,”
in Proc. 2nd Symp. Space Educ. Activities (SSEA), SSEA-2018-78,
(2018). Google Scholar
S. Walsh et al.,
“Assembly, integration, and verification activities for a 2U CubeSat, EIRSAT-1,”
in Proc. 3rd Symp. Space Educ. Activities (SSEA),
(2019). Google Scholar
J. Mangan et al.,
“Embedded firmware development for a novel CubeSat gamma-ray detector,”
in 8th IEEE Int. Conf. Space Mission Challenge,
(2021). https://doi.org/10.1109/SMC-IT51442.2021.00009 Google Scholar
J. Mangan et al.,
“Experiences in firmware development for a CubeSat instrument payload,”
in Proc. 4th Symp. Space Educ. Activities (SSEA),
(2022). Google Scholar
D. Miranda et al.,
“A comparative survey on flight software frameworks for ‘new space’ nanosatellite missions,”
J. Aerosp. Technol. Manage., 11 https://doi.org/10.5028/jatm.v11.1081
(2019).
Google Scholar
A. Cudmore et al.,
“Big software for SmallSats: adapting CFS to CubeSat missions,”
in Annu. AIAA/USU Conf. Small Satellites,
(2015). Google Scholar
Bright Ascension, “Flight software development kit,”
https://brightascension.com/products/flight-software-development-kit/
().
Google Scholar
O. Quiros-Jimenez and D. D’Hemecourt,
“Development of a flight software framework for student CubeSat missions,”
Revista Tecnología en Marcha, 6 180
–197 https://doi.org/10.18845/tm.v32i8.4992
(2019).
Google Scholar
I. Latachi et al.,
“Reusable and reliable flight-control software for a fail-safe and cost-efficient CubeSat mission: design and implementation,”
Aerospace, 7
(10), 146 https://doi.org/10.3390/aerospace7100146
(2020).
Google Scholar
S. F. Hishmeh, T. J. Doering and J. E. Lumpp,
“Design of flight software for the KySat CubeSat bus,”
in IEEE Aerosp. Conf.,
1
–15
(2009). https://doi.org/10.1109/AERO.2009.4839646 Google Scholar
H. Askari et al.,
“Software development for galassia CubeSat-design, implementation and in-orbit validation,”
in Joint Conf. 31st Int. Symp. Space Technol. And Sci. (ISTS),
(2017). Google Scholar
K. V. C. K. de Souza, Y. Bouslimani and M. Ghribi,
“Flight software development for a CubeSat application,”
IEEE J. Miniaturization Air Space Syst., 3
(4), 184
–196 https://doi.org/10.1109/JMASS.2022.3206713
(2022).
Google Scholar
European Cooperation for Space Standardization,
“ECSS-S-ST-00-01C – Glossary of terms,”
(2012). Google Scholar
European Space Agency,
“Tailored ECSS engineering standards for in-orbit demonstration CubeSat projects,”
(2016). Google Scholar
B. Tiseo et al.,
“Tailoring of ECSS standard for space qualification test of CubeSat nano-satellite,”
Int. J. Aerosp. Mech. Eng., 13
(4), 295
–302 https://doi.org/10.5281/zenodo.2643923
(2019).
Google Scholar
M. Doyle et al.,
“Flight software development for the EIRSAT-1 mission,”
in Proc. 3rd Symp. Space Educ. Activities (SSEA),
(2019). Google Scholar
R. Mahmood, K. Khurshid and Q. U. Islam,
“Institute of space technology CubeSat: ICUBE-1 subsystem analysis and design,”
in Aerosp. Conf.,
1
–11
(2011). https://doi.org/10.1109/AERO.2011.5747229 Google Scholar
ATHENA Study Team,
“ATHENA – concept of operations,”
(2015). Google Scholar
M. W. Smith et al.,
“On-orbit results and lessons learned from the ASTERIA space telescope mission,”
in 32nd Annu. AIAA/USU Conf. Small Satellites,
(2018). Google Scholar
Bright Ascension,
“User manual – generationone flight software development kit,”
(2018). Google Scholar
R. Dunwoody et al.,
“Validation of the operations manual for EIRSAT-1, a 2U CubeSat with a novel gamma-ray burst detector,”
Proc. SPIE, 12186 121861B https://doi.org/10.1117/12.2631695 PSISDG 0277-786X
(2022).
Google Scholar
J. Reilly et al.,
“EIRFLAT-1: a FlatSat platform for the development and testing of the 2U CubeSat EIRSAT-1,”
in Proc. 4th Symp. Space Educ. Activities (SSEA),
(2022). Google Scholar
S. Walsh et al.,
“Development of the EIRSAT-1 CubeSat through functional verification of the engineering qualification model,”
Aerospace, 8
(9), 254 https://doi.org/10.3390/aerospace8090254
(2021).
Google Scholar
M. Doyle et al.,
“Mission testing for improved reliability of CubeSats,”
Proc. SPIE, 11852 118526M https://doi.org/10.1117/12.2600305 PSISDG 0277-786X
(2021).
Google Scholar
M. Doyle et al.,
“Mission test campaign for the EIRSAT-1 engineering qualification model,”
Aerospace, 9
(2), 100 https://doi.org/10.3390/aerospace9020100
(2022).
Google Scholar
R. Dunwoody et al.,
“Thermal vacuum test campaign of the EIRSAT-1 engineering qualification model,”
Aerospace, 9
(2), 99 https://doi.org/10.3390/aerospace9020099
(2022).
Google Scholar
M. Doyle et al.,
“Update on the status of The Educational Irish Research Satellite (EIRSAT-1),”
in Proc. 4th Symp. Space Educ. Activities (SSEA),
(2022). Google Scholar
|