XTCE vs xTEDS /
A brief comparison /
Kevin Rice /
1/21/2010 /
XTCE and xTEDS are two XML Schemas used in the Space Domain, one is oriented towards ground segment processing, the other towards onboard configurations – there are similarities but neither can fully replace the other. /
1XTCE vs xTEDS
1.1Introduction
XML Telemetric and Command Exchange (XTCE) is an XML language for describing many aspects of telemetry and commanding as it is commonly used within the ground domain, principally for the purposes of operations. It is a Consultative Committee for Space Data System (CCSDS) recommendation (blue book) as well as the Object Management Group (OMG) standard.
xTEDS is a public domain XML language for principally created to describe certain aspects of onboard interfaces, components, and messages intended for communication between them.
1.2SpaceSystem Telemetry and Command Background
As is common practice throughout the space industry remote space systems send and receive information to and from the ground for purposes of reception of engineering and payload data, and control.
Information sent from the spacecraft to the ground is called telemetry and information from the ground to the spacecraft is called commanding (or telecommanding).
Although specific details differ across the world in terms of implementation, there is a great deal of similarity in this way thisinformation is formatted and transportedbetween space and ground among various organizations.
To further increase commonalities, various standards and approaches are widely adopted in terms of these formats. In many cases specific telemetry and command formatsare tied to particular organizations or groups of organizations, for example, the “CCSDS packet format” is widely used at NASA.
Many of these format specifications cover the frame, specialty encoding, channelization and packetization, whereas others use a major frame/minor frame approach. For the purposes of this paper, the term “format” will be adopted to mean the binary information as is processed by end users – such as telemetry packets for the CCSDS packet format and specifically include the others aspects of these formats such as framing.
One keyaspect of these formats that is generally true across all organizations is that the information packed in the format (i.e. “the packet body”) has very little descriptive information built into itself, it is largely unmarked data.
Because of this, format description information must be held on the ground in order for ground processing to occur on individual groups of bits that make up the information placed in each format unit ( such as a packet).
These ground segment side descriptions are used to describethe many facets of the telemetry data stream (in particular the individual packets for example) so that the individual values of interest in each can be properly captured, converted and further processed as needed.
This is true of engineering or operations data and payload data (sometimes called science data), although payload data is usually processed separately from the data needed to operate the spacecraft in terms of mission operations.
Command descriptive information is very similar and used in a similar but “reverse” way to build properly formatted data for uplink. And these format descriptions taken together are often tied to specific ground segment applications so that each application may have its down descriptive formats, whether they are GOTs or COTs tools.
These descriptive formats are used to configure the tools as a pre-processing step and are developed and maintained throughout the life cycle of the mission; often the term “mission ops database” is used to mean the specific format descriptions related to.
1.3XTCE’s Role
It is within this ground context that XTCE is set against. XTCE is a particular description format for telemetry and commanding, oriented towards the ground segment in conception, and written in XML Schema. It is a standard published by both CCSDS and OMG.
Principally it was conceived as a mechanism for sharingtelemetry and command descriptions across a project team in an independent manner as an import/export mechanism to various tool chains. In essence any particular tool that uses telemetry and command descriptions could export the current snapshot of their database to an XTCE file, give that file to their project team member who would then import it into their tool chain, configuring it.
The main beneficiary of this approach is the customer – they get more flexibility in terms of being able to mix and match various vendor applications to solve their missions needs, either across sub-teams (such as integration and test, and operations) or for specific mission related scenarios.
Of course conversion tools to and from XTCE would need to be developed for each vendor or application that needs the XTCE files, and while that might constitute an upfront cost – later missions could leverage that initial investment, saving money in the longer run as well as adding flexibility to the ground segment application mix.
Even if such import/export tools needed to be tuned each time per mission, such incremental development should be cheaper than paying for new conversions to custom formats over and over again (avoiding vendor lock-in), and the flexibility alone may make such overhead costs worth it regardless.
Other use cases exist.
Onesuch case would make XTCE a complete replacement for pre-existing proprietary format for a particular telemetry and command tool. Nothing prevents XTCE in being uses as the “native” database format as it is a fully featured telemetry and command description language but since most existing tool chains already have their own formats, this is more likely to occur for new development than any pre-existing packages.
A second use caseis to use XTCE as a central repository of information for both ground and flight information, encompassing more than just the telemetry and command descriptive information.
Using XTCE as the “central repository” which when applied with various forms of processing could be used to generate various “products” for the flight software developers and ground segment developers, is somewhat outside the scope of the original intentions of XTCE but due to XTCE flexibility may well be possible for certain classes of mission.
One important item to note between these various cases is that in the first case which is its principal use case – XTCE is merely a snapshot of some other tools information set – and once transported and transferred to another tool; it can be completely thrown away (and re-generated as needed).
Whereas in the later cases, the XTCE descriptions themselves must be maintained directly; these differences suggest different sets of tools and software that would need to be developed as well.
1.4XTCE Characteristics
XTCE contains many XML elements and attributes that allow one to describe most common telemetry and command practices used throughout the greater industry including many advanced features only in use by a certain segments in the industry:
-generic spaceystem concept, and spaceystem trees
-integer, floating point, string, enumeration, time, arrays and otherdata types
-the relationship and conversion from a link data type to host data type
-various forms of limit/alarm checking
-various forms of calibration
-range checking
-validity
-time offsets
-flexible packaging (format) information (packets, minor frames, messages, etc…)
-commands
-command arguments
-command checking
-various forms of command constraints
-command priority
-command side effects
-stream info
-algorithm capture
-arrays
-documentation available
There are others.
1.5XTCE Criticisms
XTCE has been criticized in a number of ways in various quarters, criticisms include:
-overly generalized
-too many features
-too flexible
-certain missing features
-too complex
-costly to implement
-difficult to guarantee 100% exchange
-tends to reflect local features
-not “my” technology of choice (UML, OWL, Relax-NG, etc…)
-ambiguous or more than one way to do things
There may be more.
Many of these criticisms have an element of truth to them but many simply reflect a difficult truth about the industry – a lack of real commonality in many of the implementation details of telemetry and commanding. And this is reflected in XTCE.
1.6Using XTCE in Practice
XTCE use to date has largely been in the context of its original use case – as an exchange mechanism between various parties involved in a mission’s deployment (in fact it has mainly been prototyped in this aspect and not used in a real mission profile at this time that the author is aware of).
As such one key aspect of such use is to develop mappings from the various applications of interest and XTCE.
Due to the fact that XTCE is a syntax first, and the semantics (or meaning) of each element and the meaning of the content in the end must be interpreted by the user’s application, and given the fact that XTCE has a large number of many optional elements and attributes that must be chosen among by implementers, and due to the fact that most implementers have at this point chosen very narrow implementations of XTCE that are rigid and inflexible, and due to specific choices made by many application developers in terms of the content of their vendor specific formats – such mappings can be variable among parties to the extent that “anonymous” exchange between parties will result in some information loss (although it debatable that dealing with this may still be easier and cheaper than dealing with proprietary formats depending on the size and scope of the mission).
Therefore a better first step by a user is to capture the way their institution and mission implements telemetry and commanding, and then develop that mapping as an official guide. Once complete it can then be distributed to team members so that their XTCE mapping may be aligned with it completely.
Developing this guide can be hard.
Many institutions have not documented the way they implement telemetry and commanding, instead relying on historical precedent, institutional memory and a cadre of vendors that know how business is done there specifically to pull off each mission, time and time again.
Documenting it by mission may be a challenge then – although in the ideal world the mission would simply narrow any necessary mission specifics from an institutional guide which is itself narrowed from some community guide, which is itself based on some greater standards – but it’s not impossible and is the best first step. (Note: CCSDS and GovSat have such guides in development)
Once the mapping has been developed, something must enforce its use. One aspect of this involves developing an application to check that the rules in the mapping guide have been properly applied to any XTCE file for the mission. This program should first check that any given file is first a proper XTCE file, and then check that the specific rules for the mission as defined in the guide are being properly applied.
Developing such a program is not that hard and easier than developing the original mapping guide itself but someone has to do it.
A more difficult aspect of this process is actually enforcing the guide’s use and getting local buy in among team members, particularly among the vendors and contractors that traditionally have charged for the conversion of their various description formats.
All of this then usually falls on the customer, either directly or by proxy and it is better thought of and started as early in the mission lifecycle as possible.
Once though all these pieces are in place, the creation and exchange of XTCE files the mission can use should proceed in a seamless manner with 100% exchange guaranteed.
Another option to all this is simply to get far broader agreement across the industry or segments of it on how telemetry and commanding is implemented. Even with slight variability for certain aspects of flight hardware which may be impossible to ever fully unify – such common approaches could greatly reduce the complexity of telemetry and command descriptions and variability in telemetry command specific between various institutions, and in so doing simplify any mission’s descriptions need in this area to the point that perhaps even the XTCE mapping and rules guide itself would be a thing of the past. (Note: GovSat is one such effort in this area)
A final aspect of this that would simplify the adoption of XTCE for missions would be for there tobe more robust but easily tunable XTCE implementations. Such an implementation could (in theory) with minimal effort be tuned for any specific set of mapping rules and in so doing greatly simplify at least the implementation side of the mapping and rules tool equation. If the rules themselves could be developed in a processable manner, then such rules could be directly ingested by a very general XTCE implementation which would configure itself to match the rules. Such a piece of software doesn’t exist and it’s not clear if it is even possible to develop one general enough to cover the vast majority of user needs in this area, still even somewhat more flexible and general implementations of XTCE would greatly ease its adoption for any particular mission.
1.7xTEDS Role
XML Transducer Electronic Data Sheet (xTEDS) was created by Utah State to compliment their Satellite Data Model (SDM). xTEDS has been further tailored in association with work by the Operationally Responsive Space (ORS) program office of the United States Air Force at Kirtland and Utah State University.
xTEDS was conceived principally for the configuration of onboard subsystems.
1.8xTEDS Characteristics
xTEDS is a small light-weight schema oriented towards describing aspects of onboard interfacesand their messages. Its principle characteristics are:
-aspects of onboard tasks
-aspects of onboard devices
-aspects of interfaces
-various forms of messages by interface
-polynomial calibrator
-linear scale calibrator
-3-level alarms (green, yellow, red)
-various data types
-1-D arrays
-range checking
There are more.
1.9xTEDS Criticisms
Some aspects of xTEDS suffer from the same issues that XTCE has – ambiguity. For example, in the understandable desire to make xTEDS small and light weight, the exact construction of the xTEDS Schema makes it possible to have seemingly contradictory settings (e.g. a polynomial calibrator with a linear scale). Other criticisms refer to the message definitions as being overly simplistic and only allowing the definition of messages which are made up of contiguous items, no gaps or other features that can sometimes be found in telemetry. The documentation that seems to be available is also weak.
-ambiguous in places
-message mechanism very simple, perhaps too simple for some applications
-variables mix concepts together between, data types, calibrators, range, limit checking
-documentation may not be available
-not broadly reviewed
1.10Using xTEDS in Practice
1.11Comparison Table
The following table highlights some of the many differences and commonalities between the two XML Schemas. The table may imply a contrast between the two that is not as cut and dry as it may appear. For example XTCE is a very general schema and some of it features can be molded to emulate a feature in another Schema. The table notes in some cases how this can be done.
Legend:
- Best – built-in explicitly
- Medium – not as full featured or may use an element which has a user defined meaning that is not far from the concept
- Low – limited feature or may use an element in a possibly unintended manner
- None – it’s just not there
Characteristic / XTCE Feature / xTEDS FeatureOMG Standard / /
CCSDS Standard / /
Support Hierarchical definitions / (optional) /
Onboard Tasks Info / (optional use of Algorithms could be ground or space side) /
Onboard Devices / (ad-hoc) /
Host/Link data type relationship / / (must infer)
Standard Data Type / String, Enumeration, Binary, Float, Integer, Boolean, Time, Array, Aggregate / Int, uint, float
Format details of data type / /
Bit/Byte Order / /
Time Data Types / /
Array Data / Any dimension / One dimension
Aggregate (“struct”) Data Type / /
Alarm/Limits / Various forms by data type (inside) / One form (inside)
Calibrators / Polys, line segments, spline, general expressions / Linear scale and poly
Range checking / /
Accuracy / /
Validity / /
Flexible Packaging / Container / CommandMsg, DataMsg, DataReplyMsg, FaultMsg
Packaging addressing (offset, holes, etc…) / /
Packaging Indentifying Info / RestrictionCriteria / (possibly use qualifier)
Commands / (commands and how they are packaged a separate concepts in XTCE) /
Command Packaging / /
Command Verification / /
Command Priority/Constraints / /
Command side effects / /
Block Commands / /
Command Packaging / /
Explicitly tie command message to response / (may be able to use cmd verification) /
Parameter Time Offsets / /
Stream / /
Various Descriptive elements and attributes / /
Algorithm / /
Documentation / /
1.12Conclusion
XTCE is a large complex and very general schema oriented towards ground system processing of telemetry and command stream, as they are implemented by organizations around the world. It is not beholding to any particular telemetry or command format, is highly flexible, reasonably well documented and prototyped by a fairly large number of organizations internationally. It is maintained by the standards community and has been prototyped by many “NASAs” around the world. Two vendors support XTCE at this time (Harris OS/Comet and GMV Archiva), and more are coming onboard with GovSat initiative.
xTEDS is a very small schema oriented towards describing specific aspects of onboard sub-systems for the purposes of auto-configuration.
Although there is the potential for some overlap in terms of what both could describe, they are specialized for their specific sub-domains.