There are many unique words, acronyms, initialisms, and phrases used in the Flight Software world. Please let us know if we've missed something and we'll add it.
Short for "Acknowledge" or "Acknowledgement". In the flight software world, it means that when you send a data packet you're expecting the receiving point to "Acknowledge" that it received it correctly. (It verifies data integrity with things like Cyclic Redundancy Checks.) Your code might spin and do nothing while waiting for the "Ack" or "Acks" to come back before you send the next file. Some things require "Acks" but it can slow things down, especially for bad connections where you simply never hear the Ack. For this reason, not all transmissions require Acknowledgements and instead send a stream of data without caring if the data is fully verified.
Short for "Application Programming Interface". In other words, it's the Interface between two sets of software. It's how you get your code to talk with somebody else's code. Each Interface can have different rules, commands, methods of initialization, and more.
This one is tricky because different functions and organizations use this to mean different things.
CCSDS Definition: Short for "Application Process Identifier". It's the field in a packet's primary header that uniquely identifies a stream of packets (indicates source, destination, or type). It helps route data, commands, telemetry, etc. to the correct locations.
Core Flight Software Definition: Short for "Application Identification". This is a unique reference assigned to Apps you install on top of Core Flight Software.
A Core Flight Software App is similar in concept to the Apps you install on your phone. It's a set of data and functions that work together to accomplish a task. For instance, you could have an app that manages your files. And you can have an App that points your spacecraft in the right direction. Apps are portable, which means you can use them on different space vehicles and even on drones and robots that run Core Flight Software.
Apps have a Main Task and can have children Tasks.
Short for "Bytes per second". It's a measure of how many packets of 8 bits are streamed through a data channel every second. It is sometimes confused with "bits per second (bps)". See the entry for a "bit" more context.
Short for "Board Support Package". Sometimes also known as the "Platform Support Package". This is the layer of code closest to your hardware. It's got the drivers, low-level execution code, and other software specific to your unique hardware. When you power on, it's what the operating system and Core Flight Executive layers use to initialize and talk to the hardware.
Because hardware is always changing and different companies use different variations of hardware, this is an area you may find yourself focusing on for flight hardware. However, if you're using common hardware (like a Raspberry Pi) then the BSP is already written for you. Vendors may also have software for you already, too.
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. 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.
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 systems via your software.
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. While you can be successful with it, you'll often see it advocated for most strongly by people who have little or no experience flying real missions.
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.
You! (Or anyone else writing code)
Duplex literally means, "twofold". In computer science, it refers to a connection between two points and the flow of data between them. "Half Duplex" means that data can only flow one way. Once data starts streaming, the sender cannot listen for incoming data until it stops sending its own data. "Full Duplex" means the interface can send and receive data at the same time.
Most interfaces in spaceflight software within a system are full duplex. For instance, RS-232, SpaceWire, and Ethernet are all full-duplex. However, space-to-ground and ground-to-space systems are often half-duplex. While an antenna is sending information, it is not receiving information. Some antenna and radio combinations can be full-duplex and some systems have channels just for sending and just for receiving so the overall spacecraft is "full duplex".
This tends to matter when designing your communication strategy. For instance, if you send to the ground on a half-duplex link then you may want to pause after sending a file to make sure the ground "Acknowledges" receiving it correctly. This can chew up time and lower your data throughput.
Short for "Electrically Erasable Programmable Read-Only Memory". EEPROM is for semi-permanent data and commands you don't want to lose when the computer resets. You can cycle power and read the data again and again. But, unlike ROM (Read Only Memory), if you need to change what it's storing you can rewrite the contents. Within the Core Flight System ecosystem, the EEPROM is most often used for tables and commands that you want to run when you start your computer. It can also hold important information about, for instance, timing, commands to run in case of problems, and parameters used in your control algorithms.
EEPROM doesn't usually have lots of storage on space flight hardware so you have to think about what critical things need to be stored and not just put everything in there.
Short for "End of File". Most file types have a series of bits or symbols that let the operating system and other software know that the stream of bits that make up the file is complete.
Short for "Executive Service(s)". This one can be a bit confusing. There are three layers to Core Flight Software: the Operating System Abstraction Layer, the Core Flight Executive Layer, and the App Layer. Within the Core Flight Executive Layer, there are five Services. The "Executive Service" is one of those five and could be considered the heart of everything. It is the primary interface to the Operating System, starts/restarts the software, manages Apps, logs errors, manages memory resources, and more. This is one of the more complex sections of code but understanding how it works and why will pay dividends.
The Core Flight Executive (cFE) layer uses Events to track the status of systems. Examples include a hardware failure, a notice that a picture has been taken, and/or that an App returned an error. Events include Event Types, Event IDs, and Event Data, which contains the Event Message. Events are not meant for standard traffic and functionality, they're intended to let you know about the health and status of things happening in your vehicle.
NASA put all this together for you in the "Event Service". Every vehicle needs to have status updates so having a proven solution here is a big win for your team.
Events include Event Data, which contains the Event Message. This should (hopefully) have enough information in it to help you understand what's happening.
This one can be confusing at first so we'll start with the problem. The problem is that some events happen a lot. Maybe an event is triggered every time you take a picture. If you take thousands of pictures, you don't want to waste valuable communication time being told (yet again) that another picture has been taken. But maybe you're okay with being told every 8th time just so you can be sure it's still happening.
An Event Filter is a hexadecimal bit mask that tells the Core Flight Executive "Event Service" when it should forward an event to the ground. There are other parameters that help you tailor it to, "Send every 8th event notice until you've sent 100 of them, then stop sending any at all until I tell you to".
All Events in the Core Flight Executive's Event Service must have a unique number assigned to them. This Event ID is registered with the Event Service.
Short for "Event Services". Event Services is one of the five core applications within the Core Flight Executive layer. It sends and receives Event messages such as errors, failures, debug messages, and information. Their primary purpose is to alert you, the user, to what's happening in the vehicle. The service also provides ways for you to limit how often and how many messages are sent.
Short for "Function Code". Function Codes are shorthand "nicknames" for commands your system can run. You might ask why you wouldn't just use the command and the answer is, "bandwidth". Some commands can have very long names. For instance, "ReactionWheel_SetSpeed" is descriptive (which is great!) but that's a lot of characters. When it's tough to send/receive data you'd rather tell the computer to run function "11" than "ReactionWheel_SetSpeed". The Core Flight System lets you specify what Function Codes link to what Commands.
Can mean multiple things:
- File Management
- Fault Management
Short for Flight Software
Short for "Guidance, Navigation, and Control". This is the spacecraft system that understands where you are, how you're pointing, and gives you the tools to change those things. One of the largest tasks of flight software is supporting the GNC team. Doing so often requires high frequency math, which can stress your system if resource planning was inadequate.
Short for "Housekeeping". The cFS uses this term to describe a telemetry packet that contains status infomation about an app. Apps send a HK telemetry packet in response to the cFS Scheduler (SCH) App's 'send HK request' software bus message that is published at a table-defined rate.
Another use of the HK term is with the NASA cFS open source app called HK. The HK app combines portions of multiple telemetry packets into a single new telemetry packet. The app was originally named HK because it combined portions of multiple HK telemetry packets into a new system HK packet. The HK app can combine the contents of any type of source packet so the name HK can be misleading.
Short for "Hardware". It can mean computer hardware or solar panels or any other hardware on the vehicle.
Short for "Hertz". A Hertz is a unit of measure for the number of times an action occurs in one second. For instance, 10 Hz means something happens 10 times per second.
Short for "Interface Control Document". This is a document (usually a Word file or PDF) that describes interfaces in detail. In this context, it describes software interfaces. It sets expectations about connecting, transmitting data, data types, formats, commands, and more. It is THE handbook that should be the source of truth. Unfortunately, keeping the ICD and the latest versions of software current with each other is exceedingly difficult and the ICD can sometimes lag reality.
Short for "Mission Elapsed Time". As the name suggests, a clock on your spacecraft starts counting from the moment it's turned on. For most missions, this happens when the vehicle is released from the rocket and the computer starts for the first. Other missions launch with their computers turned on and time starts at liftoff. The parameters that define it are stored in non-volatile memory so that computer restarts don't reset the clock. The ground team also keeps their own record of it.
Mission Elapsed Time is used often by mission operations teams to anchor events and plan the next steps. Meanwhile, the computer on the spacecraft is usually tracking both Elapsed Time and UTC/GPS time, at a minimum.
Short for "Message Identification". Core Flight Software works by passing messages around between systems. The Message Identification number is unique to a particular Message Type. It's like ordering a "#5" meal at the Drive Thru. Instead of saying everything that comes in the meal, you just order #5 and everyone knows what you're talking about. Message ID's are listed in a table that you update when you define a new message type.
Short for "Memory Management Unit". This is (usually) a hardware-based system that helps you manage memory resources. It can provide a relatively simple interface to you while working complex memory allocation behind the scenes.
Short for "No-Op", which is short for "No Operation". This is a special command that counts as a command in the system but it doesn't do anything besides increment the counter of the number of commands received and displays an informational message about the App you sent the NOOP to. For instance, many Apps will return their version number in response to a NOOP command. It's primarily used as a check that everything is working. It's sometimes used to "wake up" a system and make sure it's ready to run.
Short for "Operating System". The Core Flight Software must be installed on top of an Operating System (e.g. Linux) but that's not true for all flight software.
Short for "Operating System Abstraction Layer". This is the lowest layer in the stack of three layers that make up the Core Flight System. It translates commands between your operating system and the Core Flight Executive layer. The OSAL has already been written for you if you use Linux, RTEMS, VxWorks, and POSIX operating systems. Some people have written an OSAL variant for FreeRTOS, but that has not been publicly released.
The GitHub link to is here: https://github.com/nasa/osal
NASA's cFS GitHub includes it as well: https://github.com/nasa/cFS
Short for "Pipeline Identification". Messages are sent to "Pipes". They're like mailboxes that are unique to a given Task. Messages stack up in a queue (pipe) until they're processed by whatever service owns it. What can be confusing initially is that Pipeline IDs are only unique on a given processor. If your system has two processors, there could be two Pipeline IDs called "112". However, since Tasks run on their own threads on a given processor, Tasks don't get confused. It's like how there could be multiple houses with the address "123 Main St." but since they're in different zip codes, mail still gets delivered correctly.
Pipes are managed by the Software Bus service.
Short for "Packet". A Packet, as defined by the CCSDS, has three parts: a primary header, a secondary header, and a data section. In other words, it states what type of data it holds, additional information (such as the time it was sent), and then the data itself. A packet is the smallest collection of data that you can send.
Short for "Programmable Read-Only Memory". A PROM can be written to once with data and then be queried for that data "forever". But you only get one shot... a PROM cannot be written to a second time. Despite this limitation, they're important because you can reset the computer or store it for years and the data will still be there. This is great for parameters that will never change (like hardware configuration parameters) because PROM tends to be well protected against radiation, temperature, and other effects that other memory types can be wiped out by.
An alternative is EEPROM, which is "Electrically Erasable" PROM. EEPROM does let your rewrite the contents of the PROM.
Short for "Platform Support Package". Sometimes called the "Board Support Package". This is the layer of code closest to your hardware. It's got the drivers, low-level execution code, and other software specific to your unique hardware. When you power on, it's what the operating system and Core Flight Executive layers use to initialize and talk to the hardware.
Because hardware is always changing and different companies use different variations of hardware, this is an area you may find yourself focusing on for flight hardware. However, if you're using common hardware (like a Raspberry Pi) then the PSP is already written for you. Vendors may also have PSP software for you already, too. We hope more vendors start offering pre-made PSP in the future.
Short for Random Access Memory. This is the type of memory people most often think about when it comes to computers. It's fast and systems tend to have a lot of it so they can do everything from add numbers together to store files. The downside is that it's volatile, which means that when the power goes out, it loses everything it was storing.
Short for "Real-Time".
Short for "Real-Time Operating System". A real-time operating system prioritizes running actions at precise times. This means, for instance, that high-priority events can interrupt low-priority events "instantly". The supermajority of spacecraft that have an operating system use a real-time version because even milliseconds count when you're flying 8 km/s. (One millisecond is 8 km of distance.)
For Core Flight Software, real-time options include VxWorks, RTEMS, and POSIX systems. FreeRTOS has also been shown to work. While Core Flight Software runs great on Linux, Linux isn't real-time by default. However, you can make modifications to it to make it mostly real-time.
Short for "Software Bus", also known as the "Software Bus Service". The Software Bus Service is one of the five core services hosted by the Core Flight Executive layer. The Core Flight Software system works by sending messages around. Apps and systems that care about these messages can subscribe to them. They can also send (publish) messages. The Software Bus manages this messaging traffic. It keeps track of which Apps want which message types, routes messages appropriately, reports errors if message transfer fails, manages the pipes (queues), and can report statistics.
Short for "Single-Board Computer". Many spacecraft have a box of boards or even multiple boxes of boards. Simple spacecraft can get everything onto a single board.
Short for "Spacecraft Time Correlation Factor". The short answer is that this is the "extra time" you add to your Mission Elapsed Time to calculate the Spacecraft Time relative to the Ground Epoch. The longer answer:
- The Ground Epoch is a date and time that everyone agrees to. It could be Midnight on Jan 1, 2001 or it could be the precise moment of your birth. It's just a time that everyone on the program agrees is "Time Zero" and everything is calculated up from there.
- Mission Elapsed Time starts counting up the first time the computer is turned on for flight operations.
- And then the Spacecraft Time Correlation Factor is what you have to add to the Mission Elapsed Time to figure out the time since the Ground Epoch. In theory, it should never change once it's calculated. So if the Ground Epoch is midnight of Jan 01 of this year and you launched at midnight of Jan 05 of this year then your STCF would be four days. You would store this number in your EEPROM so you could recalculate your Mission Elapsed Time if something bad happened to your system.
It can mean multiple things:
Short for "International Atomic Time". (The actual phrase for TAI is French so the letters don't line up in English.) Technically, International Atomic Time started at midnight on January 01, 1958. However, for flight software, its primary appeal is that it does NOT track leap seconds. It's simply the number of seconds and sub-seconds since some initial time, usually known as the Ground Epoch. You can calculate it by adding your Mission Elapsed Time to your Spacecraft Time Correction Factor (SCTF). The difference between TAI and UTC is that UTC tracks leap seconds. (UTC = TAI - "Number of Leap Seconds").
In Core Flight Software, the System Time Structure in the TIME service can track time in TAI and UTC by default.
From NASA's documentation: A Task is a thread of execution in the operating system, often associated with a Core Flight Executive (cFE) Application. Each cFE Application has a Main task providing its CPU context, stack, and other OS resources. In addition, each cFE Application can create multiple Child Tasks which are closely associated with the Parent Task and cFE Application.
In a traditional Real Time Operating System (such as vxWorks or RTEMS), the cFE Application Main task and child tasks end up being mapped to these OS tasks in the same shared memory space. For example, a Stored Command cFE Application that consists of a cFE Main Task and 10 Relative Time Sequence Child Tasks would have 11 tasks on a vxWorks system. The only association between these tasks exists in the cFE.
In a memory-protected, process-oriented Operating System, the intention is to have a cFE Application implemented as a memory-protected process with its own virtual address space. In this Process Model, each cFE Child Task would be a thread in the parent Process, much like a Unix process with multiple threads. In this model, the Stored Command example with a cFE Main Task and 10 Relative Time Sequence Child Tasks would consist of a Unix Process and 10 pthreads, all under the same virtual address space.
Short for "To Be Determined". It means there's an intent to get information in place but it hasn't happened yet.
Short for "Table". In Core Flight Software, it can refer to "Table Services", one of the five core services hosted by the Core Flight Executive layer. Tables are immensely valuable in flight software. You can organize parameters and their values, making it easy to look things up. You can store a series of commands and the times they should run. You don't have to use them but they offer convenience for many common tasks.
The Table Service lets you create tables, update them, delete them, store them, verify them, and more.
Short for "To Be Reviewed". It means the information is "probably" correct or at least close to the truth but people are still working to verify a final value. This is stronger and more reliable than "To Be Determined".
Short for "Task Identification". Every Task is assigned its own ID. The Core Flight System gives you tools to track, query, and interact with tasks via this ID. See "Task" for more information.
When fully capitalized, it is shorthand for "TIME SERVICE", one of the five core services hosted in the Core Flight Executive layer. See that entry for more information.
The Time Service is one of the five core services hosted in the Core Flight Executive layer. Getting time right on spacecraft can be -exceptionally- difficult. This service gets you much closer to success with features that track time, help you synchronize the system, provide functions to query and manipulate time values, and can trigger tasks with distributed time-triggered wake-up packets.
However, there's still work to do on your end because different hardware uses different methods and interfaces. This is where the Platform Support Package and/or the Board Support Package come in. You'll update that software interface to talk with your hardware and then the higher level Time Service takes over from there.
Short for "Telemetry". Telemetry is data your system generates and/or collects and sends to you. It could be temperature sensor readings, a report on how much storage space you have left, the time since the last error, or anything else you decide would give you insight into the health and performance of your system.
In Core Flight Software, Telemetry is managed by the Executive Service. It provides functions that help you create, log, and send telemetry. NASA also provides a "Telemetry Output (TO)" example App that extends functionality, especially for ground testing.
Short for "Coordinated Universal Time". (The original words are French so the words are rearranged.) Coordinated Universal Time is one of the two default time standards supported by the Time Service in the Core Flight Executive layer. (The other one is TAI, "International Atomic Time.). Of primary note is that UTC tracks leap seconds while TAI does not.