10.1 Typical Software

The software has many roles in a spacecraft’s lifetime. In chronological order, the spacecraft must have ground test software, embedded flight software, and mission operations software. During testing and verification, the spacecraft will need software to communicate and verify the functionality of the spacecraft sensors and actuators. During the space mission, the spacecraft will rely on embedded flight software to fulfill the mission. During the space mission, the mission operators will need software to monitor the spacecraft’s status and send the spacecraft commands. This section will primarily focus on the flight software but will also conceptually review ground test software and mission operations software.

Flight Software

Software Architecture

Flight software is software that runs on the spacecraft during the mission. For spacecraft that use an embedded computer (computer with no mouse, keyboard, or monitor), the flight software is a type of embedded software. Fundamentally, the software must receive, transmit, manipulate, and store data from the hardware.

Flight software consists of an operating system and application software. Most of these general functions are handled by an operating system (OS), “a system software that manages computer hardware, software resources, and provides common services for computer programs” [Wikipedia]. The operating system keeps track of time to schedule tasks, processor time, and mass storage. The OS interacts with embedded hardware, like memory, and peripheral devices through input/output interfaces, like the payload. An embedded operating system utilizes real-time preemptive multi-tasking and is typically smaller than Windows, Mac OS X, or Linux, like VxWorks, RTEMS, and FreeRTOS.

The components of an OS that make a computer work together include a kernel, networking, security, and a user interface; although, networking and a user interface are less prevalent in space. “With the aid of the firmware and device drivers, the kernel provides the most basic level of control over all of the computer’s hardware devices. It manages memory access for programs in the RAM, it determines which programs get access to which hardware resources, it sets up or resets the CPU’s operating states for optimal operation at all times, and it organizes the data for long-term non-volatile storage with file systems on such media as disks, tapes, flash memory, etc. The operating system provides an interface between an application program and the computer hardware so that an application program can interact with the hardware only by obeying rules and procedures programmed into the operating system” [Wikipedia]. Networking on the ground refers to “computers running dissimilar operating systems can participate in a common network for sharing resources such as computing, files, printers, and scanners using either wired or wireless connections” [Wikipedia].

In space, the spacecraft typically only communicates with the ground but recent advances in constellations, like SpaceX Starlink, and decentralized intelligence may force us to think about networking in space more deeply. For security, “the operating system must be capable of distinguishing between requests which should be allowed to be processed, and others which should not be processed” [Wikipedia]. “Hackers could pull off a cyberattack by taking remote control of a satellite or by spoofing or jamming its signals. With spoofing, a hacker can send out fake signals to disguise their activity. Jamming is designed to flood a server with so much traffic it causes an interruption” [Newcomb]. As satellite communication frequencies are regulated, a hacker can transmit fake signals with a strong enough antenna. “For example, an attacker could access the systems on the Hubble Telescope and open its camera hatch while pointing at the sun, destroying the sensitive optics. They could also use solar panels to blow out the batteries. Many satellites are also vulnerable to jamming attacks that could disrupt important commands from ground control. Malik suggests using frequency hops to make it harder for attackers to jam signals. In the case of GPS, ground systems should make greater use of GPS authentication to ensure the signals are authentic and not manipulated by a third party. Thankfully, newer satellites are using encryption, but Malik stresses that is not a silver bullet. Operators still need to carefully monitor and log satellite traffic” [Whitwam]. An embedded operating system will not need a user interface but will need a way to ingest user commands.

Application software includes mission-specific software that does work required by the user or the mission rather than in support of the computer. We can think of application software as one level of abstraction closer to the user, higher-level intelligence that has to do with the mission. The following table contrasts the duties of an operating system vs. application software.

Aspects of flight software include real-time processing and centralization. Real-time processing or computing is the ability of a program to guarantee a response within specified time constraints in the order of milliseconds, and sometimes microseconds [Wikipedia]. The stringency of real-time processing may be characterized by “hard” or “soft” real-time processing. Hard real-time requires precise timing to achieve correct results, where absolute deadlines must be met, and missing a time boundary has severe consequences, like entry, descent, and landing (EDL) operations, some critical orbit maneuvers, and observation of fast-moving or transient phenomena. These mission components are tied to fast dynamical systems for which the system must react. Soft real-time requires that the tasks be performed in a timely manner, where missing a time boundary results in degraded but continuous performance, like coarse pointing maneuvers to transmit to the ground station and orientation of solar panels.

^{Breakdown of hard vs soft real-time systems by Kanaka Juvva. Image courtesy of Carnegie Mellon University}

Centralization refers to the degree of that computing happens on one or multiple processors. A centralized system has one processor designated as the master unit, which provides all housekeeping and data handling. All commands are processed and routed through this central unit. Distributed (multi-processor) architectures use multiple processors to divide the avionics tasks into two possible configurations: distributed computing and/or redundant processing. In distributed computing, executive tasks are shared by all processors, dedicated processors are assigned to each sub-system, and processors communicate through the spacecraft bus. Redundant processing utilizes multiple processors for which any can assume the role of master. This architecture tolerates faults well as redundant systems can implement voting logic.

Flight software falls under the categorization of embedded software. “Embedded software needs to include all needed device drivers at manufacturing time, and the device drivers are written for the specific hardware. The software is highly dependent on the CPU and specific chips were chosen” [Wikipedia]. For example, operating systems run on microprocessors and not microcontrollers, so the hardware dictates the ability to boot an operating system. “Most embedded software engineers have at least a passing knowledge of reading schematics, and reading datasheets for components to determine usage of registers and communication system. Web applications are rarely used, although XML files and other output may be passed to a computer for display. File systems with folders are typically absent as are SQL databases. Software development requires the use of a cross compiler, which runs on a computer but produces executable code for the target device. Debugging requires the use of an in-circuit emulator, JTAG or SWD. Software developers often have access to the complete kernel (OS) source code” [Wikipedia].

To develop flight software, we typically use a process called cross-development. We write code on a Windows, Mac, or Linux computer, cross-compile for target processors, transfer object code to embedded computers, and control embedded systems with a ground system. Cross compilers create executable code for a platform other than the one on which the compiler is running [Wikipedia]. The object code is the product of a compiler. The source code that creates the object code is typically in C, C++, Assembly Language, sometimes Ada and runs on real-time operating systems like Linux, VxWorks, RTEMS, and FreeRTOS. The control of the embedded system comes from the mission operators that pass through a ground station and through the spacecraft communications systems.

Examples of flight software architectures include HSFL’s Comprehensive Open-architecture Solution for Mission Operations Systems (COSMOS) and NASA’s core Flight System. The cFS is a re-usable spacecraft flight software architecture that provides flight software services, applications, and operating environments [NASA]. cFS is a layered architecture that supports a variety of hardware platforms, provides standardized Application Programmer Interfaces (API), supports and hosts flight software (FSW) applications, supports software development for on-board FSW, desktop FSW development, and simulators, and contains platform and mission configuration parameters that are used to tailor to a specific platform and mission.  Applications can be added and removed at run-time (eases system integration and FSW maintenance).

^{Cosmos Agents Demo with MOST. Video courtesy of Miguel Nunes with HSFL.}

For the Artemis CubeSat Kit, the flight software runs on a Linux operating system in a framework called COSMOS. COSMOS is an open-software framework designed to primarily support the development, mission operations, and flight software of one or more small spacecraft. If you are developing the software in Linux, the flight software does not need to be cross-compiled. COSMOS is a suite of software tools (including external modules) that enables the operations team to interface with the spacecraft, ground control network, payload, and other customers in order to perform the mission operations functions including mission planning and scheduling; contact operations; data management and analysis; simulations (including the operational testbed); ground network control; payload operations; flight dynamics; and system management. COSMOS is also being designed to be easily adapted for new spacecraft or installation in new mission operations centers (MOCs).

Communication Architecture

Communications between processors and between one processor and other components are essential. This communication typically occurs across a software bus or pipeline in which all telemetry and commands pass through the same bus/pipeline. The applications that need certain telemetry or commands can subscribe and unsubscribe to any and all messages that travel across the bus. The software bus is used for data and control flow. All messages on the software bus or between hardware have messages formatted in command and telemetry packet standards, defined by communication protocols in a protocol stack or Open Systems Interconnection Model. There are different protocol stacks so we will explore the most common and minimal layers necessary for spacecraft. The OSI Model is commonly used to describe computing on ground and has language we would associate with the Internet of Things. The SpaceFibre Protocol has multiple lower-level layers, lane layers, and a management layer between layers that are specific to this framework.

Communication protocols occur between different levels or layers, typically: physical, data link, network, and user layers. The physical layer is responsible for the serialization and de-serialization, electrical driver and receiver, connectors and cables, in short, the individual bits. Common physical and lane layer protocols interfacing with hardware include I²C, SPI, serial ports, and USB. The common physical layer protocols specific to spacecraft include MIL-STD-1553 bus protocol and SpaceWire Protocol, which will be discussed in a later section.

Data-link protocols specify how devices detect and recover from such collisions, and may provide mechanisms to reduce or prevent them. This layer is the protocol layer that transfers data, called frames, between nodes on a network segment across the physical layer. Examples of data link protocols are Ethernet for local area networks (multi-node), the Point-to-Point Protocol (PPP), HDLC, and ADCCP for point-to-point (dual-node) connections. In the figure below, the Ethernet protocol attaches a header and trailer that act to direct the flow of data with the ability to detect, recover from, reduce, or prevent collisions in this frame stream.

The network layer is responsible for packet forwarding including routing through intermediate routers. Network layer protocols include the CubeSat Space Protocol and Internet Protocols, like IPv4.

The transport layer ensures the data reaches without errors. The SpaceFibre communication protocol doesn’t have a transport layer but terminates at the User Application, which is application software embedded onto the spacecraft. This software encodes spacecraft autonomy or mission operator control. The layer beyond the spacecraft’s embedded software is the communication link with the ground, which is the Space Development Agency’s interpretation of the transport layer. This communication link depends on digital modulation schemes, like amplitude-shift keying (ASK), phase-shift keying (PSK), frequency-shift keying (FSK), and quadrature amplitude modulation (QAM), which we talk about in the communications chapter [Hsu].

The last layers (session, presentation, and application) are the layers going from the ground station to the mission operator’s monitor. Generally, “the application layer is the scope within which applications, or processes, create user data and communicate this data to other applications on another or the same host” [Wikipedia]. This final layer strips away all the headers and we are left with the actual data, which can be displayed, interpreted, and acted upon in the mission control center.

A selected list of features to consider when selecting a communication architecture include [Gwaltney and Briscoe]:

• • Communication Control Event-/TimeTriggered, etc.
  • Maximum Data Rate (MB/s)
  • Message Size
  • Message CRC (Yes/No)
  • Provide All Nodes With Data Transmitted by Other Nodes for Local Node Use as Required
  • Duplex
  • Media Access
  • Media Access Without Arbitration (Yes/No)
  • Clock Synchronization
  • Global Time Base (Yes/No)
  • Latency Jitter

Suggested Reading

Communication Protocols

Physical Layer

At the physical layer, the MIL-STD-1553 bus protocol is a specific format for messages that consists of 16-bit words in Manchester code. All communication on the bus is under the control of the bus controller using commands from the bus controller to the remote terminals to receive or transmit. Messages include command words, status words, and data words. The bus controller can pursue a transaction with a specific remote terminal or broadcast to all capable remote terminals. The information transfer formats for the specific transactions are in the figure below. A visualization of the electric signal from a transaction is shown.

As discussed previously in I/O interfaces, SpaceWire not only has a physical architecture but also has multiple communication protocols. SpaceWire’s modulation and data formats generally follow the data strobe encoding – differential ended signaling (DS-DE) part of the IEEE Std 1355-1995. SpaceWire utilizes asynchronous communication and allows speeds between 2 Mbit/s and 400 Mbit/s, with the initial signaling rate of 10Mbit/s, through the use of space-qualified 9-pin connectors.

Data Link Layer

The Ethernet II frame, the most common Ethernet Frame format, “preceded by destination and source MAC addresses, that identifies an upper layer protocol encapsulated by the frame data. Since the recipient still needs to know how to interpret the frame, the standard required an IEEE 802.2 header to follow the length and specify the type” [Wikipedia].

The SpaceFibre data link layer “sends packet information in frames of up to 256 bytes” [STAR-Dundee]. “Each transferred character starts with a Parity bit and a Data-Control Flag bit. If Data-Control Flag is a 0-bit, an 8-bit LSB character follows. Otherwise one of the control codes, including end of packet (EOP)” [Wikipedia].

“Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 uses a 32-bit address space which provides 4,294,967,296 (232) unique addresses, but large blocks are reserved for special networking methods. An IP packet consists of a header section and a data section. An IP packet has no data checksum or any other footer after the data section. Typically the link-layer encapsulates IP packets in frames with a CRC footer that detects most errors, many transport-layer protocols carried by IP also have their own error checking. The IPv4 packet header consists of 14 fields, of which 13 are required. The 14th field is optional and aptly named: options. The fields in the header are packed with the most significant byte first (big-endian), and for the diagram and discussion, the most significant bits are considered to come first (MSB 0 bit numbering)” [Wikipedia]. The CubeSat Space Protocol was created as a small network-layer delivery protocol specifically for CubeSats. “The protocol is based on a 32-bit header containing both network and transport layer information. The implementation is written in C and is ported to run on FreeRTOS and POSIX and pthreads-based operating systems such as Linux. The protocol and the implementation are actively maintained by the students at Aalborg University and the spin-off company GomSpace. The source code is available under an LGPL license and hosted on GitHub” [Wikipedia].

SpaceWire’s network layer has the following data frame format:

“One or more address bytes are used for the routing. Addresses are either physical ones (0-31) or logical ones. The difference is that the physical addresses are deleted from the frame header during routing – which is used for hop-based routing (based on the path specified in the frame itself). Logical addresses may be deleted as well, depending on the router configuration” [Wikipedia]. The ESA has a draft specification in place for the Protocol ID. The following Protocol ID’s have been assigned in ECSS-E-ST-50-11 [SpaceWire Handbook]:

Artemis CubeSat Kit Communication Protocol

The Artemis CubeSat Kit uses a variety of physical layer communication protocols, like SPI, I2C, UART, and Camera Software Interface (CSI), as seen in the figure above. For Ethernet connections, a SLIP protocol with a 16-bit CRC appended to each packet is used for any Serial interactions. At the data link and network layers, standard IP protocols are used for all Ethernet interactions; only UDP –based protocols are used for Earth/Space communications. The application layer displays information through the COSMOS mission operations support tool (MOST).

Modes

Like the idea of modes in the power chapter, the command and data handling system dictate and transition between software modes. The CDH system coordinates with the power management system to dictate which components to supply power to, the components to collect information from, and the components to command. Each software mode has a series of functions to perform and conditional gates to pass to autonomously transition to the next mode. Mode transitions can also be commanded by the ground from mission operators. Common operating modes will be discussed in the mission operations chapter but briefly include [Pasetti]:

• Stand-By Mode generates basic housekeeping telemetry and listens for incoming telemetry but takes no action to control the spacecraft. The satellite is typically in this mode before it separates from the launcher and in the first seconds after separation.
  • Housekeeping telemetry includes temperatures, pressures, voltages, currents of critical components like pressure vessels and batteries.

Software considerations could be the frequency at which we ping the subsystems for this information, likened to the heartbeat of the spacecraft.

• Initial Checkouts are typically entered after the satellite has separated from the launcher. In this mode, the satellite must perform its initialization, acquire a nominal attitude, and communicate with the ground as soon as possible. Initial checkouts may also be entered as part of the recovery sequence after a failure. The onboard computer must
  • collect attitude and orbit information, then calculate an initial estimate of attitude, position, and rate
    • Software considerations could be the computational intensity of processing the attitude and orbit determination algorithms onboard, the number of sensor measurements to keep post-calculation, and the precision of the attitude and orbit estimate.
  • ensure that each subsystem can communicate and read sensible data, or passes on housekeeping information from all subsystem components to send to mission operators to interpret the state of health
    • Software considerations could be the level to which we check the functionality of each subsystem. For passive components, a simple measurement of the gyroscope could be compared to the expected tip-off rate from deployment, encoded in a statement: if the gyroscope reads an angular rate value within this expected range, then the gyroscope sensor is healthy and the spacecraft is behaving as expected. For active components, a functionality check could be spinning up reaction wheels, ensuring that the wheels are operating at the right current/voltage, and measuring the angular rate as a result of this spin-up.
  • must compress, store, and wait to transmit this information to ground
    • Software considerations could be the maximum size of data able to transmit to the ground, the necessary information to transmit to the ground, and the degree to which we compress the data to fit the information in one ground pass.
• Normal Mode (NM): in NM the satellite performs the tasks for which it was designed. Most of a mission is to be spent in this mode if everything goes nominally. This set of modes has functional modes for a nominal mission but also has modes to catch failures. This set of modes can be thought of as a state machine where the spacecraft always occupies a specific mode but is always checking to see if it should transition to another mode with conditional statements (if, then).
  

  

  • • Science Operations – given enough charge in the battery, the onboard computer needs to coordinate with the payload, attitude control, and other subsystems to conduct science operations. The onboard computer must
      • calculate or be told from mission operators the relative orientation of the subject to observe for the payload to point at
      • coordinate with the attitude control system to point at that subject, refer to the attitude control function
      • collect data from the payload
        • Software considerations could be the payload throughput to the flight computer, the total mass storage onboard to hold all the payload data, and the need to compress the payload data.
      • compress and store the data in mass storage, then wait to transmit this information to ground
    • Data uplink and downlink – given enough charge in the battery, the onboard computer needs to coordinate with the telecommunications, attitude control, and other subsystems to transmit and receive data. The onboard computer must
      • calculate the relative orientation of a ground station
      • coordinate with the attitude control system to point toward and track the ground station during a ground pass, refer to the attitude control function
      • transmit data to the ground station
        • Software considerations could be the degree of compression/loss or encryption for the transmitted data packets.
      • receive confirmation of receipt and delete redundant data from mass storage
        • • receive commands or other data from the ground station
    • Spacecraft charging/sun pointing – if the spacecraft is not actively in another mode or the battery needs more charge, the onboard computer needs to coordinate with attitude control to point solar panels toward the sun. The onboard computer must
      • • • • enter this mode before the battery enters a permanent and unsafe discharge point
              • Software considerations could be the frequency of estimating the state of charge to ensure the battery does not drain in between pings and the precision of the state of charge algorithm so that the battery state of charge doesn’t accidentally slip into dangerous discharge without the computer knowledge.
            • calculate the relative orientation of the sun
            • coordinate with the attitude control system to point toward and track the sun, refer to the attitude control function
            • exit this mode before the battery enters a permanent and unsafe charging point
    • Attitude Control Function – the onboard computer must track, point, or slew at a desired orientation or angular rate
• Software considerations could be the processing rate at which the estimation and control algorithms can update (real-time operations) and the precision to which the estimation algorithm can generate an estimate / the control algorithm can point.

• • Orbit Control Function – the onboard computer must control the spacecraft’s orbit, whether that be maintaining the same orbit or transferring to a new orbit
    • Software considerations could be the criticality of timing to achieve the desired orbit.
  • Failure Detection and Isolation – the onboard computer must detect when a fault or failure has occurred. A hardware failure could manifest as sensor measurements that are outside of expected bounds and persists even after software reset. A software failure due to radiation effects could manifest as garbled data packets. A software failure due to bad code could manifest as the spacecraft getting stuck in modes or not handling sensor measurements outside of expected ranges. This mode must encode autonomous transition to a safe mode in which these discrepancies can be parsed out or a software reset can happen safely.
    • Software considerations could be how often we ping the subsystems for the state of health, how often to evaluate if a failure has happened, to what degree we explicitly encode fault detection (amount of code), and where to put conditional gates in other mode’s code to detect failure.
  • Failure Recovery – the onboard computer must autonomously recover from a failure when detected. Typically, failure recovery comes out of a safe mode. This recovery process could include reaching out to mission operators for help if the spacecraft is functional enough to transition between modes. If the spacecraft is stuck in failure, the last option could be rebooting the system.
    • Software considerations could be what software to keep in non-volatile memory upon reboot and the condition statements to encode to lead to and from failure recovery.
  • Reconfigurations – the onboard computer can accept software updates from the ground to improve performance, fix damaging code, or finish unfinished code! In NASA’s Mars rover Curiosity, the “software for Mars surface operations was uploaded to the rover’s memory during the Mars Science Laboratory spacecraft’s flight from Earth” [NASA].
• Safe Mode (SM): SM is entered after a very serious anomaly has been detected. The objective of SM is to keep the satellite in a safe state (ie. a state where no permanent damage is done to it or its instruments) and to keep the radio link with the ground open (to allow the ground to identify the cause of the anomaly and if possible to take remedial action).

Suggested Activity

Simulation/Emulators

We’d like to test our spacecraft on the ground before we send it to space and can’t change the design anymore. Testing rigorously and comprehensively on the ground can flesh out software glitches, like being stuck in an unsafe mode or not being able to get out of safe mode. To replicate the space environment and physics in microgravity, we need to create or use a simulation that:

• replicates what the spacecraft would feel or see from the environment
  • Atmospheric density, pressure, temperature
  • Magnetic field
  • Sun position yields solar pressure, irradiance
    • Temperature distribution of spacecraft
    • Power generation from solar panels
  • Earth albedo or another planetary albedo
    • Optical brightness
  • Star map
• spoofs measurements that the sensors would read within the spacecraft
  • Pressure transducer based upon atmospheric density, pressure
  • Thermistor or temperature sensor from atmospheric temperature and sun solar irradiance
  • Magnetometer based on the magnetic field and electromagnetic interference noise
  • Attitude based upon stars in the field of view
• propagates orbital mechanics and attitude dynamics
  • Atmospheric density, pressure, temperature leads to atmospheric drag
  • Sun position leads to solar pressure
  • Magnetic field leads to magnetic torque
  • thruster and momentum control contribution
  • integral to developing attitude and orbit control algorithms

Simulation software is written in MATLAB, C, C++, Python, Java, Ruby, etc.:

• 42  is a comprehensive general-purpose simulation of spacecraft attitude and orbit dynamics. Its primary purpose is to support the design and validation of attitude control systems, from concept studies through integration and test.

GMAT is designed to model, optimize, and estimate spacecraft trajectories in flight regimes ranging from low Earth orbit to lunar applications, interplanetary trajectories, and other deep space missions. Analysts model space missions in GMAT by first creating resources such as spacecraft, propagators, estimators, and optimizers.

• Orekit,  a low-level space dynamics library written in Java, has gained widespread recognition since it was released under an open-source license in 2008.
• Basilisk astrodynamics software architecture is being designed to be capable of both faster-than-real-time simulations, including repeatable Monte-Carlo simulation options, as well as providing real-time options for hardware-in-the-loop simulations.
• Poliastro is an open-source (MIT) collection of Python functions useful in Astrodynamics and Orbital Mechanics, focusing on interplanetary applications. It provides a simple and intuitive API and handles physical quantities with units.
• STK SOLIS is a commercial plug-in to the Analytical Graphics, Inc (AGI) Systems ToolKit (STK™) mission analysis software, providing integrated end-to-end spacecraft simulation.

COSMOS architecture includes the visualization tools, support tools, and underlying programs that produce and manipulate the data needed by the rest of the toolsets. It combines both the software and unique hardware needed to support mission operations, including an operations testbed (OTB) and simulators. The simulators are all software applications, and the OTB combines simulators with spacecraft hardware where possible to mimic as closely as possible the reaction of the spacecraft to commands and operational states.

To select a simulation, consider:

• Capabilities to :
  • Define the parameters of body
  • Simulate attitude dynamics
  • Orbit modeling and simulation
  • Control policy design
  • Availability of constants and coordinates
  • Integrators
• Extensive documentation and tutorials are found on this website.
• 3-D Visualization for orbits and trajectories
• Time to set up for concept studies
• Extrapolation to the entire CubeSat design and mission lifetime
• Programming Language
• Maintenance and Support

Mission Operations Interface

Mission operators need to monitor various critical aspects of the spacecraft (the state of health, orbit, attitude) and are able to command the spacecraft (desired mode, attitude, orbit). A graphical user interface (GUI) is a visually intuitive interface for mission operators to be able to monitor and command the spacecraft, although we weren’t always able to get such high definition or visual aids in our monitors. The number of monitors necessary to view critical information depends on the complexity of the mission. The Apollo missions were huge projects and the technology for monitor displays was much coarser in the number of pixels that could display information. The mission operations team resorted to many monitors (and physical buttons for commands), typically one or monitor per subsystem, to be able to support the flagship mission [Hutchinson]. Today, we can have a single mission operator in front of one LCD display monitoring all of the subsystems and speaking directly to the spacecraft, which is a reasonable task for small spacecraft like CubeSats.

The CDH specialist will collaborate with the mission operations specialist to help create an intuitive and informative interface. Outside of making sure the spacecraft data reaches the mission control center, the data must be intuitively displayed on the monitors. For values that are changing with time, like orbital trajectories or power draw, time series are intuitive displays. For attitude or angular rate for tumbling or pointing, an updating, rotating CAD could be the most intuitive way to display this information. Precise numbers could display values like latitude and longitude of a ground track. This process also helps the CDH specialist know what information the spacecraft should transmit back to the ground.

Suggested Reading

NASA Study on Flight Software Complexity.