Electronic Data Sheets are a way to create and document your software interfaces. You can use them for any software project to make it much easier to maintain. And NASA's cFS team sees the potential, too, so they and the community have started to create the capability in an add-on package. They may also make it a part of the default code at some point.
The most important thing to note as you get started with them is that you don't have to use them! They are an advanced topic that you may want to tackle once you've got the basics down. When you're starting to find yourself in interface nightmares, though, check out some of the links at the bottom of the page to find more information.
Most spacecraft missions fail because something has gone wrong at an interface. For hardware, it’s not the mirror that fails, it’s the way it was bonded to a flexure. For software, it’s not often the function, it’s the bad data handed to it. Spacecraft teams need to focus hard on tracking, documenting, and managing interfaces. It’s a big job.
And software folks have maybe more interfaces than anyone else because software touches so many things. Among other things, you’ve got software that talks directly with computer chips, software that sends messages to different parts of the spacecraft, and software that watches other software.There can be dozens and even hundreds of interfaces using different programming languages, styles, and tools.
And, adding pressure, different teams need to interact with software in different ways. For instance, mission operations needs to send commands to the spacecraft. And Unit Testing software needs to check compatibility. In the “old days”, different teams would maintain different databases and tools that were supposed to have the same interface information but often didn’t. “Old days” is in quotation marks because, frankly, it’s still true today that many teams don’t have a central database and toolchain with well-documented information about how to work with the software.
Teams need to figure out a single approach for all the systems, for all the software interfaces, and all the tools.
Electronic Data Sheets describe what data should be sent/received at an interface and the way that data should be formatted. They can also map how to convert a desired behaviour to messages and commands of various types. And, because they can be read by both machines and humans, they’re a kind of documentation that you can use everywhere. Think of them as a mix of instructions and definitions in a single Sheet and you’re pretty close to the truth.
One way these things combine to make you successful is through system integration. You can have one team working part of your software development and another team doing something completely different. And/or teams may be using different versions of cFS or Apps or whatever. As long as they're using the same data sheet for the interface, though, you can have high confidence that the different code sets will work. This is a "big deal" for large teams and can save you serious time and money.
Electronic Data Sheets are most often created with XML (which is like HTML if you haven’t used XML before). And the parameters you can use in the tags are defined by the rules the team uses. For instance, you could have a parameter that states how the binary data being sent to a function should be formatted. And a parameter that specifies Little Endian vs. Big Endian so you don't have to worrry about how the hardware prefers to handle things. And you can make it easier for your C code to work with C++, Rust, Python, or whatever other language. And you can even define state machines. In fact, you might have a whole dictionary of parameters and values that make it easy to understand what needs to happen.
Your software and tools read in the Electronic Data Sheets to “educate themselves” and set expectations. One example is that you can have your testing suite make sure the correct variables and types are being sent and/or received. Another example is your compiler can use the information to help link things. A third example is your mission operations team can use it to create their flight procedures.
The Electronic Data Sheet specifications most often used in the space industry are version controlled by the Consultative Committee for Space Data Systems (CCSDS). This group supports, for instance, both NASA and the European Space Agency (ESA) and others so it’s a worldwide effort to create a single standard.
Side note: The CCSDS calls Electronic Data Sheet “SEDS”, which is short for SOIS Electronic Data Sheets, and SOIS is short for “Spacecraft Onboard Interface Services”. However, few people call them “SEDS”; you’ll hear most people just call them “Data Sheets” or perhaps “EDS”.
As of this writing, the main specification is the “Blue Book” 876.0: Spacecraft Onboard Interface Services - XML Specification for Electronic Data Sheets. There is a working group that discusses updates on a regular basis so be sure you’re reading the latest version. As of this writing it’s 876.0-B-1.
The Dictionary of Terms (DoT) is in the “Magenta Book”, 876.1. These are all the parameters and terms that people have agreed to use in the XML tags. The list is extensive! You can use Data Sheets for a lot of things and they’ve tried to cover all the core and edge cases. (And you can create your own custom terms, too.)
And the use cases for data sheets and the Dictionary of Terms are provided in the “Green Book” 870.0-B-1. These are the examples for how things can work together. Although they try to flesh out some concepts, the takeaway is really that you can use Data Sheets for things well beyond just software. Some people have even extended the Dictionary of Terms to include hardware, avionics, and entire systems.
https://www.youtube.com/watch?v=35yEgnay2rM&t=959s
The European Space Agency has interested in extending data sheets to avionics and even to mapping an entire spacecraft. The team they funded created the SECT tool to help. Note that this isn't an official definition supported by the CCSDS team. However, it does show both how powerful data sheets can be as well as a path forward to harnessing that potential.
https://github.com/nasa/EdsLib
Joe Hickey is a key developer and supported of electronic datasheets. His “EdsLib” tool can be used generically to create and importa electronic datasheets for any embedded system and it’s got hooks and patches for integration with NASA’s Core Flight System versions 7.0 and above. Note that there’s a forked version of the NASA repository (https://github.com/jphickey/EdsLib) but it isn’t updated as often and Joe is the engine driving both versions. Stick with the NASA version but check out Joe’s repository in case something cool is happening there independently.
https://github.com/jphickey/cfe-eds-framework
This is a distribution of NASA's cFS with the electronic data sheet hooks and overlays already included. (The link above this one adds data sheet compatibility on top of NASA's plain code.) Note that this isn't updated as often as the links above. But! There's some good notes and documentation here that may be worht checking out even if you don't use the integrated apprroach.
https://public.ccsds.org/Pubs/Forms/AllItems.aspx
These are all the CCSDS specifications.The electronic datasheet documents start with 870 and 876. You can find lots of other great specifications on the page, though, so this is a handy link to have.
https://www.esa.int/Enabling_Support/Space_Engineering_Technology/Electronic_Data_Sheets_a_common_language_for_space
The European Space Agency (ESA) wrote an overview article on data sheets and where they see the future. It's worth a read through and they've got some images to help anchor concepts.
https://flightsoftware.jhuapl.edu/files/2018/Day-1/14-Jonathan-Wilmot-CCSDS-Electronic-Data-Sheets.pptx
The Flight Software Workshop website and YouTube channel has lots of great information. This PowerPoint presentation has a good overview of things with plenty of pictures.