Understanding XTCE and SEDS in Mission Operations
XTCE (XML Telemetric and Command Exchange) and SEDS (Space Experiments Data System) are essential tools in mission operations. XTCE serves as a standard database language for telemetry and commanding, while SEDS provides a platform for managing space experiment data. These tools are related through their role in facilitating data exchange and mission interoperability. To enhance their use, it is crucial to address challenges like packet formats and database interoperability.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
XTCE and SEDS Some thoughts on them and how they are related (And what we should do to facilitate their use) Kevin Rice 11/15 (ASRC Inc) 9/6/2024 1
Some Questions and Possible Answers What is XTCE? What is SEDS? Are they related? How? If you want to describe a CCSDS packet in XTCE, how do you that? And what about PUS in XTCE? Do we need similar approaches for SEDS? Issues GSFC specific What about interfaces? 9/6/2024 2
What is XTCE? XTCE is a: An XML Schema A mission operations database language A standard published by the OMG and CCSDS Version 1.1 (there is 1.2 being readied) Official Name: XML Telemetric and Command Exchange What s the EXCHANGE part? Really there s nothing specific in XTCE about this. It s a schema syntax for telemetry and commanding, non-science really The term exchange was put forward because many people wanted a standard database format but didn t want to support it natively An independent neutral format What s it got in it then? A place for packets or any blocky message with at least one identifying feature (e.g. apid) Mnemonic definitions and common properties: encoding, data types, limits, calibrators and more Command: packet, arguments and other command properties such as permission, etc ALSO: algorithms (but not a specific language syntax), streams, and services These are very open general in nature 9/6/2024 3
Some XTCE Use Cases My T&C Tool s Database Developed Developed Justification: Gold Standard, exists outside of any tool chain XTCE Translator XTCE Translators Justification: Possible Use In Another Tool XTCE Native DB My T&C Tool s Database Your T&C Tool s Database Translator My T&C Tool(s) Grok XTCE Your T&C Tool s Database Way back, case 1 & 2 were thought to be the most likely avenues of use. But several have now gone down the 3rd path and this looks increasingly popular. (case from left to right) 9/6/2024 4
And just briefly Does anyone really use XTCE? Yes its been or being in an increasing # of missions in various ways Actual native tool chain support seems increasingly popular And there is vendor support also in different ways as well Does this mean everyone can just send each other their XTCE files and they ve achieved mission database interoperability? Alas, no that to a degree leads to slide #9 But in a nutshell: packet formats and properties supported make free ride interoperability difficult Example: GSFC T&C systems support arrays and structured (record) based mnemonics, JPL T&C system does not. 9/6/2024 5
What is SEDS? SEDS is: An XML Schema Based on the XTCE schema types but extended and refactored to be more domain specific That domain being flight software A FSW meta language by which a tool will read SEDs XML files and autogenerate portions of the onboard flight software At least that s a core use case A candidate Blue Book Report from CCSDS SOIS Electronic Data Sheet 9/6/2024 6
The first use (left to right) is primary case the schema was developed against, the 2nd use case is the GSFC one, and final one has only been discussed as an historical approach. Some SEDS Use Cases Device1 Device2 Device1 Device2 Missions Ops Database Device3 Device3 SEDS XML(s) Scrapes Tlm & Cmd Packet Info Scrapes Tlm & Cmd Packet Defs Inputs Tool Tool Tool Converts to Tlm & Cmd Packet Defs Here Converts Generates Device1 Device2 Missions Ops Database FSW Target Language Device3 9/6/2024 7
SEDS and XTCE How Are They Related? SEDS many of its schema types were based on XTCE s But these were slowly made more domain specific to FSW Although these often remain clearly related More importantly: the definitive overlapping area is within the telemetry and command area: Packets: On the ground these are describes in the mission ops database and includes all the various properties previously mentioned On the FSW side these are describe in programming language data structures (e.g. struct in C) 9/6/2024 8
SEDS and XTCE Overlap? FSW packet definitions and XTCE ground system packet definitions are related - It doesn t seem necessarily to be 1 to 1 in every aspect however, this is definitely true for GSFC for the mission database - Examples: - fsw structs probably don t reflect sub-fields the same as on the ground - Ground names are not likely the same T&C Feature SEDS XTCE Packet ContainerDataType ContainerType Hierarchical Mnemonic Name Child ContainerDataType AggregateParameterType Integer, Float, String, Boolean, Enum, Binary Mnemonic Data Type Integer, Float, String, Boolean, Enum, Binary DataType Integer, Float, String, Boolean, Enum, Binary ParameterType Limits XXX? Alarms (various) Calibrators In Components (onboard function?) In ParameterType (various ground function) Abstract Command Info (not packet) N/A MetaCommand Array ArrayDataType ArrayPacketType 9/6/2024 9
Identify a CCSDS or PUS Packet Definition in XTCE There s no specific syntax for packet or CCSDS or PUS in XTCE Containers XTCE s generic term to describe blocky things Container hierarchy XTCE s generic way of describing the identifying feature or features in a blocky thing AND construction Terms: Parent container, root container (all borrowed from object oriented nomenclature) More is still needed: GovSat is a NASA specification published by the OMG that defines a standard way to describe a CCSDS packet and the APID using container hierarchies ESA has a similar unpublished specification 9/6/2024 10
GovSat In A Nutshell Not a schema itself Rules for using XTCE Rules are checked against instance docs Removes some tags Limits others (or attributes) Not perfect, default schema values are a problem Rules for CCDSD Header creation in the XML And more importantly the container hierarchy to define CCSDS packets Most of the rules are written in Xpath 2.0, a few are not Several implementations In reality the rules based approach works but is slow for very large docs The current GSFC govsat checker actually buries a hidden govsat schema to make it faster What s a GovSat document? A valid XTCE document that passes all GovSat rules! Published by the OMG Because certain people in CCSDS no further comment Proven to be relatively popular and a good thing overall GovSat 2.0 may appear when XTCE 1.2 appears ESA has it s own version which is unpublished but copies the approach 9/6/2024 11
Does SOIS EDS Need a GovSat (ESASat)? Similar to GovSat, rules and patterns of usage The rules would be domain specific, although likely a lot of overlap between ccsds mission producers And for patterns of usage: the two likely candidates are SOIS containers and SOIS Interfaces SOIS like XTCE does not have specific syntax for CCSDS (PUS) Packets Or specific interfaces but a general concept So, defining a set of rules for constructing CCSDS packets (&PUS) and various well known and typically supported Interfaces (1553, etc ) Seems reasonable Because, why? By having common rules and construction patterns for packets and interfaces You ll have some hope of reading my files & doing something reasonable with them 9/6/2024 12
Conclusions? XTCE and SEDs are related XTCE is a ground system database SEDs is a FSW meta language Telemetry and Command Packet definitions Relating them needs some consistent rules and conventions Otherwise I won t known your CCSDS_HEADER_CONTAINER from my CcsdsHeaderContainer GovSat seems a reasonable approach to consider But, there are likely domain specific issues in terms of converting one to another Names of mnemonics, sub-fields But this may be solvable in domain specific ways From a mission database point of view, a lot of info is missing: limits, cals, etc Still a SEDS doc could be a starting point In addition, SOIS interfaces while not related to XTCE per se seem a candidate as well for a govsat like set of rules 9/6/2024 13
