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.

Broadly, Events are things that the software is trained to listen to. For example, the radio receiving a signal is an event that would trigger the software to start reacting. Another example is a temperature being higher than what you want.

In cFS, 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 further. For instance, “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.