1.1.

Educational Irish Research Satellite

The 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).²⁶ 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.²⁷ 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,²⁶ 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,³⁰ and the Gamma-Ray Module (GMOD), discussed in Sec. 1.2, is a miniaturized $\gamma$-ray detector.^31,32

Fig. 1

FM of EIRSAT-1, showing the satellite’s constituent components.

The EIRSAT-1 spacecraft consists of custom hardware that was designed in-house for the EMOD and GMOD payloads. An antenna deployment module (ADM),³³ 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.³⁴

1.2.

Gamma-Ray Module

The 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 $\gamma$-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 $25\mathrm{mm}\times 25\mathrm{mm}\times 40\mathrm{mm}$ cerium bromide (${\mathrm{CeBr}}_3$) 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.³² The TTEs produced by GMOD on-orbit will be used to understand the payload’s $\gamma$-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 $10\sigma$ (and up to 32 at $5\sigma$).³¹

3.1.

Requirements

Requirements 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.”⁴⁸ 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 1

Example 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 Hardware

A 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.⁵¹

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.

Resources

As 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.⁵¹

Table 2

Advantages (‘✓’) and potential disadvantages (‘×’) of kit-driven development.51

3.4.

Concept of Operations

A 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.1.

Flight Software Architecture

Figure 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.⁵¹

Fig. 2

High-level overview of the main flight software architecture, where solid lines represent the general flow of data/data dependencies in the system, FDIR = fault detection, isolation, and recovery, OBDH = onboard data handling, and I/F = interface, with these components providing an interface to an external subsystem (via physical connections that are given as dashed lines), TM/TC = telemetry/telecommand and “external subsystems” refers to microprocessors on the EPS, ADCS, battery, radio transceiver, GMOD, and EMOD subsystems. Components that are not present in the failsafe image are identified with a triangle (▴).

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.⁵¹ 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 Management

4.2.2.

Separation sequence

This 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:

• 1. u8_State : initialization—a number of initialization tasks are first performed. For instance, watchdog functionality (discussed in Sec. 4.4) is enabled to ensure that the ADM firmware is responsive throughout the sequence.

• 2. u8_State : post-launch wait—to satisfy a mission requirement (Sec. 3.1), a 45-min wait period is observed before antenna deployment is attempted.

• 3. u8_State : −Y/+Y/−X/+X primary burn—deployment attempts are initiated via I2C commands to the ADM firmware, which is responsible for EIRSAT-1’s primary antenna release mechanism.³³ This mechanism involves the ‘burning’ of resistors on the ADM to melt lines holding the antenna in a stowed state. Through these states, the resistors that are responsible for the release of the four antennas are burned individually, each for a 30-second period.

• 4. u8_State : between burn wait—radio transmission is enabled if either element door switch on the ADM indicates that the downlink/UHF antennas are released, or $n$ deployment attempts have occurred. These conditions are implemented to prevent radio transmissions while antennas are still stowed as power radiated into the transceiver could damage the component. However, the conditions also eventually prioritize radio transmission to favor the likelihood of acquiring a signal (AOS) from the satellite.

  A 25- or 100-min wait period is then observed. The duration is dictated by the status of the door switches on the ADM, with a longer wait-time being implemented if all antennas are likely deployed.

• 5. u8_State : secondary burn—a deployment attempt is initiated via I2C communication with the EPS, which is responsible for EIRSAT-1’s secondary antenna release mechanism. In this case, the EPS powers one of its power distribution modules, which burns four resistors on the ADM at once, for a 30-second period.

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.

Fig. 3

Separation sequence states and operational modes.

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.3.

Subsystem Interfacing

The 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.

GMOD

GMOD (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 storage

When configured to run its primary experiment, the GMOD payload collates 256-byte ‘pages’ of TTE data, which are stored to its flash memory.³² The expected rate at which data will be produced on-orbit ranges from $\sim 2$ to 30 pages/second, which correspond to the $\gamma$-ray background (i.e., a $\sim 50\mathrm{Hz}$ TTE rate) and a $20\sigma$ 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.³² These TTEs are then passed to a number of different functions within the component, as described below and summarized in Fig. 4.

Fig. 4

Data acquisition/parsing process implemented in GMOD’s main flight software component.

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 $\sim 35-40$ 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 generation

The mission will make use of one primary ground station, located at UCD (53.3065°N, 6.2255°W), allowing for $\sim 30\min$ 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).

Fig. 5

Data compression carried out by the GMOD main flight software component, showing an example 20-min light curve (a) and spectrum (b) produced by the component from raw/paged TTE data.

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.³² 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 $\gamma$-ray environment; (iii) if anomalous results/features are observed in the data; and (iv) when a GRB is detected (discussed below).

GRB triggering

An 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 $n$ 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

Eq. (1)

$$\mathrm{u}32\_\mathrm{S}\mathrm{i}\mathrm{g}=\frac{(N\times \mathrm{S}\mathrm{i}\mathrm{g}\mathrm{n}\mathrm{a}\mathrm{l})-\mathrm{B}\mathrm{a}\mathrm{c}\mathrm{k}\mathrm{g}\mathrm{r}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}}{\sqrt{(N^2\times \mathrm{S}\mathrm{i}\mathrm{g}\mathrm{n}\mathrm{a}\mathrm{l})+\mathrm{B}\mathrm{a}\mathrm{c}\mathrm{k}\mathrm{g}\mathrm{r}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}}}$$

where u32_Sig is the calculated significance of the signal within the signal window, $\mathrm{S}\mathrm{i}\mathrm{g}\mathrm{n}\mathrm{a}\mathrm{l}=\mathrm{\Sigma }$ (TTEs in the signal window bins), $\mathrm{B}\mathrm{a}\mathrm{c}\mathrm{k}\mathrm{g}\mathrm{r}\mathrm{o}\mathrm{u}\mathrm{n}\mathrm{d}=\mathrm{\Sigma }$ (TTEs in the background window bins), and $N=\frac{\text{Background window size}}{\text{Signal window size}}$ (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:

• • $m$ sectors of TTE data, that were logged to the OBC’s flash memory as part of the normal data acquisition process, are copied (or ‘protected’) to a separate location in flash memory. This memory is dedicated to potential GRB data and can store data associated with up to 40 triggers at a time. The aim is to isolate high priority data for downlinking and protect it against the possibility of being overwritten by less significant, background TTE data. Configurable parameters in the software specify the time period around the trigger and the number of sectors (i.e. $m$) to be protected.

• • As $m$ sectors of TTE data are read in by the component (i.e., as they are copied from one location in flash memory to another), a lightweight light curve and spectrum are generated. Information about the trigger (e.g., the peak S/N ratio recorded, its duration, and where the protected TTE data are located in flash memory), as well as the light curve and spectrum, are logged to the OBC’s flash memory to enable rapid downlinking and analyses. In contrast to the non-triggered light curves and spectra (Fig. 5), the start and end times of the triggered light curve and spectrum are centered around the high S/N event.

• • To rapidly communicate the trigger to the astronomical community (e.g., through the Gamma-ray Coordination Network⁵⁶), the light curve and spectrum are also transmitted by the spacecraft as part of a periodic telemetry beacon that is automatically transmitted every 1.5 min. This allows key information about the detection to be disseminated rapidly. It also provides advanced notice to the mission control team, so preparations can be made to prioritize downlinking of GRB data during the next available communication windows. In particular, the $m$ sectors of TTE data “protected” in the OBC’s flash memory will be downlinked such that a more comprehensive analysis of the GRB can be conducted on the ground.

More information about the planned on-orbit operation of GMOD is provided in Ref. 57.

4.4.

Fault Protection

The Bright Ascension FSDK is equipped with a number of features and components intended to help implement autonomous FDIR methods, including:⁵⁵

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 3

Examples 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.1.

Setup and Tools

5.2.

Life Cycle

The 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.

Tests

Testing of the main flight software was undertaken throughout the development process.