Stands for “Consultative Committee for Space Data Systems”. At a high level, they are a multi-national organization that creates standards for data and communication systems. Many flight programs require that their software, avionics, and communication systems implement CCSDS standards. There has been a recent trend to increasingly rely on their standards so it’s well worth understanding what they’re up to.

Their website is here: https://public.ccsds.org/default.aspx

Stands for “Command and Data Handling”. This is the part of your software that manages the chaos of signals zipping around everywhere. Commands and data can come from the ground, other systems on the space vehicle, and even from itself. The Command and Data Handling “Handles” the chaos in different ways depending on your flight software architecture.

Short for “Critical Data Storage”. This is the data you want protected at all costs. It’s the tables and parameters that even a hard computer reset won’t delete. The Operating System and Core Flight Software both use this data to help initialize at start-up. This part of the data storage is not often large but it can be expensive since space-qualified hardware works hard to protect it from radiation, vibration, and other sources of damage. You’ll often find this data stored in hardened, “permanent” memory like Flash or EEPROM.

Stands for “core Flight Executive”. There are three layers to “core Flight Software” and cFE is the middle layer. This layer is the “brains”. It helps you send messages around, monitors performance, lets Apps plug into it, and generally manages things for you. This is one of the most valuable parts of the cFS architecture and solves many common problems for you out of the box.

Stands for “core Flight Software”. NASA intentionally made the “c” lowercase to emphasize the architecture should be built with a “little and lightweight core”. Users extend the small core architecture with their own Apps.

Core Flight Software uses Apps to accomplish most of your mission tasks. Each App has a Main Task and can have multiple Child Tasks. Child Tasks run on their own threads but only communicate with their parent task. The Core Flight Executive layer and other Apps don’t talk with Child Tasks directly.

For example, you might have a Sun Tracking App. The Main Task in the App would receive data from the Sun Sensor and then could ask a Child Task to lookup where the Sun should be in the sky given the current time. The Main Task would get the answer from the Child Task, combine it with the Sun Sensor data and make an estimate of which way the vehicle is pointing.

Stands for Configuration Management. This typically means that documents, files, and other resources cannot be changed without authorization from designated people. The designated people may require you to follow a process, convene a review board, and/or justify why changes should be allowed. It also usually means that everything is backed up and given a version number.

Short for “Command”. These are the commands you send and receive that result in some sort of action or response.

Short for “Commercial Off-The-Shelf”. In theory, you can save money and time by buying parts from a hardware store instead of making an exquisite, over-engineered part at aerospace labor rates. In practice, issues around quality control, material incompatibilities, environment incompatibility, and extreme loads have cost programs more money trying to make off-the-shelf parts work than if they’d done it themselves. Be careful going too hard on COTS without an expert or two around to adjudicate “gotchas”.

Stands for “Central Processing Unit”. Many people use the word “Processor” to mean the same thing. This is chip that processes many of the logic-based instructions. Space flight hardware tends to have a single CPU although newer systems do sometimes have multiple CPUs.

Short for “Cyclic Redundancy Check”. This is a bit-level math equation that computers run on each packet to determine if it was transmitted and received correctly. One of the challenges with space-based communication is that lots of noise and signal failures can occur. By running an equation on every packet and comparing it to what the answer should be, we can determine if the packet should be resent or not. This adds processing overhead and can reduce how much data you get across your communications link but not having it is worse.

This YouTube video does a good job explaining it: https://www.youtube.com/watch?v=IeSzUKCQYjM

NASA provides a free tool for CRC here: https://github.com/nasa/tblCRCTool

NOTE: There are additional ways to check packet quality including Checksum, which is computationally faster.

Short for “Checksum”. This is a family of algorithms that perform bit and word-level algorithms on your data to make sure they’ve been transferred correctly. Space transmissions are notoriously noisy/lossy so you need some form of data check to make sure you, first, got the date correct and, second, that it’s coming from the right source (for security reasons).

NASA’ Core Flight Software has a Checksum application that verifies data integrity for memory, tables, and files. However, this App is not available for all releases of Core Flight Software. It’s also not a true “checksum” algorithm since it’s not safe enough for their work. Instead, they use a Cyclical Redundancy Check (CRC) algorithm but call it Checksum for historical reasons.