220 likes | 394 Views
GSFC SEDS Schema. Overview & Major Differences Kevin Rice NASA/GSFC CCSDS Fall 2013. Agenda. What We Did What We May Do Major Elemental Differences in Diagrams. What We Did. Some Initial Goals. Try to solve “our” problem first
E N D
GSFC SEDS Schema Overview & Major Differences Kevin Rice NASA/GSFC CCSDS Fall 2013
Agenda • What We Did • What We May Do • Major Elemental Differences in Diagrams
Some Initial Goals • Try to solve “our” problem first • Definitely interested in data types and packet descriptions that are found in C FSW header files • Could be interested in other SOIS aspects • Gain increased understanding of SOIS concepts by being “hands on” • Replace Sam Price’s XSD with SOIS or SOIS-like XSD • Experiment • Multiple schemas? • Improve emerging standard • Hopefully
One GSFC Problem Space • FSW already exists • C and C-header (“.h”) files • But annotated • Holds “metadata” not storable in C directly • units, calibrator, limit, apid, etc… • Sam Price “invention” as C has no annotationitself • In comments as “@keyword value” largely • Parsable, Sam has tool • Desire: • Build independent metadata, feed development or test tool chains • History • Replace “in house” XML solution, move towards SOIS
Concept XML Metadata Tool Chain Metadata Annotated .C or .H Files Docs Directions of Definite Interest: RedBlueGreen BlueRed, BlueGreen
Example of Annotation /*! * @ingroup MESSAGES * @brief An example message for Power point. * @apid 135 */ typedefstructBasic_M{ /*! * @is_packet_header */ CCSDS_Telemetry_Headerpacket_header; //CCSDS Packet Header /*! * @brief Temp of the baseplate the ram is attached to. * @polynomial [1566.7676,-18.85822,-.17372, 0.00229, 0.00001] * @units fahrenheit * @red_limit [-Inf,-20), (120,Inf] * @yellow_limit [-20,-15), (115,120] */ int32_t cpu_temp; /*! * @brief Receiver Position * @coordinate_frame ECEF * @unit meter */ double position[3]; };
Initial Efforts • Pre-existing XML solution • XTCE • Found it difficult to readily understand and apply • SciSys Schema • Found it difficult to readily understand and apply • Created new schema for just data types • Attempted to “evolve” over time towards SOIS solution, adding functionality, some experimentation
Some New Goals • Narrow syntax • XTCE is very general • Closer to C data types plus annotation • Go towards typical programming language terms • Parameter Variable • ParameterType DataType • Copy XTCE concepts but fix items if there are known issues • Simplify if possible • Flatten if possible
Results • Experimentation • 8 major versions! -- numerous minor versions • Ex. Tried a three schema split • But, in the end (for now): • Consists of the overall structure of SciSys schema • But is hand created, has its own schema types • Is flatter and has a different “ref” mechanism • New data types • And a myriad of other “efficiencies”, “improvements” • All SciSys Examples Converted over using Software Tool • NPAL, FOG, Hydra Star Tracker, Dot. Example, etc… • GSFC GPS metadata converted to it (but this is just the data types) • Lives in NASA GITHUB Account • Self Evaluation • A derivative work that needs further refinement and thinking • We need to understand SOIS concepts more deeply
Some Ideas • Further clean up of schema • A number of areas need further refinement • Possibly experiment again w/multiple schema solutions • Expand GPS metadata into it • Generate GPS .h/.c files, compare to hand created version • Validate Sci Sys Examples • Possibly round-trip back to sci sys format • Maybe use them directly in a tool
Removed AncillaryData and AliasSet, capped short description at 128.
Import other packages in another SEDS instance Name change Version, schema version, authorship log Basically the same as SciSys Name change. Flatter XML, but hierarchical references: NPAL.DAS::BatV1
More C-like Place to say a “struct” is a packet. Give APIDs Very similar to SciSys. Parameter is now Variable, uses the term “prototype” instead of Command. Probably change… Also very similar to SciSys. DataType, Variable as above
Just a list mainly… May remove or re-think… Abstract data type “Packed” or masks More…
But only one more… Bitfields and unions are also “struct-like” in syntax
Most of the other data types are similar. But wait!? Where are units, cal, etc…?
Variables refer to DataTypes. But attributes are child elements aligned with type. Hence an IntegerVariable should have an IntegerDataType, and its various attributes should be aligned with it (e.g. initialValue is an xs:integer). Experimental… But wait!?The units, cal, etc…again!?
They are in the variable area… XTCE keeps the bulk of this at the type. But typical .H definition re-uses “UINT32” and although the annotation changed – new units, new cal or limit, etc… Experimental!
Suggest Now Using XMLSpyfor Viewing Additional Changes If there is Time and Interest…