CCSDS 508.0-R-1, Conjunction Data Message (Red Book, Issue 1 ...

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESFOREWORDThis document is a Recommended Standard for Conjunction Data Messages (CDMs) and hasbeen prepared by the CCSDS. The CDM described in this Recommended Standard is thebaseline concept for conjunction information interchange applications between interestedparties.This Recommended Standard establishes a common framework and provides a commonbasis for the format of conjunction information exchange between originators of conjunctionassessment data and satellite owner/operators. It allows implementing organizations withineach Agency to proceed coherently with the development of compatible derived standardsfor the flight and ground systems that are within their cognizance. Derived Agency standardscan implement only a subset of the optional features allowed by the Recommended Standardand can incorporate features not addressed by this Recommended Standard.Attention is drawn to the possibility that some of the elements of this document may be thesubject of patent rights. CCSDS shall not be held responsible for identifying any or all suchpatent rights.Through the process of normal evolution, it is expected that expansion, deletion, ormodification of this document may occur. This Recommended Standard is therefore subjectto CCSDS document management and change control procedures, which are defined inOrganization and Processes for the Consultative Committee for Space Data Systems(CCSDS A02.1-Y-3). Current versions of CCSDS documents are maintained at the CCSDSWeb site:http://www.ccsds.org/Questions relating to the contents or status of this document should be addressed to theCCSDS Secretariat at the address indicated on page i.CCSDS 508.0-R-1 Page iii March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESAt time of publication, the active Member and Observer Agencies of the CCSDS were:Member Agencies– Agenzia Spaziale Italiana (ASI)/Italy.– Canadian Space Agency (CSA)/Canada.– Centre National d’Etudes Spatiales (CNES)/France.– China National Space Administration (CNSA)/People’s Republic of China.– Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)/Germany.– European Space Agency (ESA)/Europe.– Federal Space Agency (FSA)/Russian Federation.– Instituto Nacional de Pesquisas Espaciais (INPE)/Brazil.– Japan Aerospace Exploration Agency (JAXA)/Japan.– National Aeronautics and Space Administration (NASA)/USA.– UK Space Agency/United Kingdom.Observer Agencies– Austrian Space Agency (ASA)/Austria.– Belgian Federal Science Policy Office (BFSPO)/Belgium.– Central Research Institute of Machine Building (TsNIIMash)/Russian Federation.– China Satellite Launch and Tracking Control General, Beijing Institute of Trackingand Telecommunications Technology (CLTC/BITTT)/China.– Chinese Academy of Sciences (CAS)/China.– Chinese Academy of Space Technology (CAST)/China.– Commonwealth Scientific and Industrial Research Organization (CSIRO)/Australia.– CSIR Satellite Applications Centre (CSIR)/Republic of South Africa.– Danish National Space Center (DNSC)/Denmark.– Departamento de Ciência e Tecnologia Aeroespacial (DCTA)/Brazil.– European Organization for the Exploitation of Meteorological Satellites(EUMETSAT)/Europe.– European Telecommunications Satellite Organization (EUTELSAT)/Europe.– Geo-Informatics and Space Technology Development Agency (GISTDA)/Thailand.– Hellenic National Space Committee (HNSC)/Greece.– Indian Space Research Organization (ISRO)/India.– Institute of Space Research (IKI)/Russian Federation.– KFKI Research Institute for Particle & Nuclear Physics (KFKI)/Hungary.– Korea Aerospace Research Institute (KARI)/Korea.– Ministry of Communications (MOC)/Israel.– National Institute of Information and Communications Technology (NICT)/Japan.– National Oceanic and Atmospheric Administration (NOAA)/USA.– National Space Agency of the Republic of Kazakhstan (NSARK)/Kazakhstan.– National Space Organization (NSPO)/Chinese Taipei.– Naval Center for Space Technology (NCST)/USA.– Scientific and Technological Research Council of Turkey (TUBITAK)/Turkey.– Space and Upper Atmosphere Research Commission (SUPARCO)/Pakistan.– Swedish Space Corporation (SSC)/Sweden.– United States Geological Survey (USGS)/USA.CCSDS 508.0-R-1 Page iv March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESPREFACEThis document is a draft CCSDS Recommended Standard. Its ‘Red Book’ status indicates thatthe CCSDS believes the document to be technically mature and has released it for formalreview by appropriate technical organizations. As such, its technical contents are not stable,and several iterations of it may occur in response to comments received during the reviewprocess.Implementers are cautioned not to fabricate any final equipment in accordance with thisdocument’s technical content.Recipients of this draft are invited to submit, with their comments, notification of anyrelevant patent rights of which they are aware and to provide supporting documentation.CCSDS 508.0-R-1 Page v March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESDOCUMENT CONTROLDocument Title Date StatusCCSDS508.0-R-1Conjunction Data Message, DraftRecommended Standard, Issue 1March 2012Current draftCCSDS 508.0-R-1 Page vi March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCONTENTSSectionPage1 INTRODUCTION .......................................................................................................... 1-11.1 PURPOSE AND SCOPE ........................................................................................ 1-11.2 APPLICABILITY ................................................................................................... 1-11.3 DOCUMENT STRUCTURE ................................................................................. 1-21.4 CONVENTIONS AND DEFINITIONS................................................................. 1-21.5 REFERENCES ....................................................................................................... 1-42 OVERVIEW ................................................................................................................... 2-12.1 GENERAL .............................................................................................................. 2-12.2 CDM BASIC CONTENT ....................................................................................... 2-13 CDM CONTENT/STRUCTURE IN KVN .................................................................. 3-13.1 GENERAL .............................................................................................................. 3-13.2 CDM HEADER ...................................................................................................... 3-13.3 CDM RELATIVE METADATA/DATA ............................................................... 3-23.4 CDM METADATA ................................................................................................ 3-43.5 CDM DATA ........................................................................................................... 3-73.6 DISCUSSION—CDM/KVN EXAMPLES .......................................................... 3-104 CDM CONTENT/STRUCTURE IN XML .................................................................. 4-14.1 DISCUSSION—THE CDM/XML SCHEMA ....................................................... 4-14.2 CDM/XML BASIC STRUCTURE ........................................................................ 4-14.3 CONSTRUCTING A CDM/XML INSTANCE ..................................................... 4-24.4 DISCUSSION—CDM/XML EXAMPLE .............................................................. 4-65 CDM DATA IN GENERAL ......................................................................................... 5-15.1 OVERVIEW ........................................................................................................... 5-15.2 RULES THAT APPLY IN KVN AND XML ........................................................ 5-16 CDM SYNTAX ............................................................................................................... 6-16.1 OVERVIEW ........................................................................................................... 6-16.2 THE CDM IN KVN ................................................................................................ 6-16.3 THE CDM IN XML ............................................................................................... 6-4CCSDS 508.0-R-1 Page vii March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCONTENTS (continued)SectionPageANNEX A ABBREVIATIONS AND ACRONYMS (INFORMATIVE) .................... A-1ANNEX B RATIONALE AND REQUIREMENTS FOR CONJUNCTIONDATA MESSAGES (INFORMATIVE) ......................................................B-1ANNEX C CONJUNCTION INFORMATION DESCRIPTION(INFORMATIVE) ......................................................................................... C-1ANNEX D INFORMATIVE REFERENCES (INFORMATIVE) .............................. D-1ANNEX E SECURITY, SANA AND PATENT CONSIDERATIONS(INFORMATIVE) ..........................................................................................E-1ANNEX F CDM XML SCHEMA DEFINITION (INFORMATIVE) ......................... F-1ANNEX G CDM XML TO KVN TRANSLATOR—XLSTIMPLEMENTATION (INFORMATIVE) ................................................. G-1Figure4-1 CDM XML Basic Structure .......................................................................................... 4-1C-1 Definition of the RTN and TVN Coordinate Frames ...................................................C-2Table3-1 CDM KVN Header ....................................................................................................... 3-23-2 CDM KVN Relative Metadata/Data ............................................................................. 3-23-3 CDM KVN Metadata .................................................................................................... 3-53-4 CDM KVN Data ........................................................................................................... 3-74-1 Relation of KVN Logical Blocks to Special CDM/XML Tags .................................... 4-54-2 Other Special CDM/XML Tags .................................................................................... 4-56-1 Example XML Keyword Tags With Specified Units ................................................... 6-6B-1 Primary Requirements ..................................................................................................B-2B-2 Heritage Requirements .................................................................................................B-4B-3 Desirable Characteristics ..............................................................................................B-4CCSDS 508.0-R-1 Page viii March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESThis Recommended Standard is applicable only to the message format and content, but not toits transmission nor to the algorithms used to produce the data within. The method oftransmitting the message between exchange partners is beyond the scope of this documentand could be specified in an ICD.The methods used to predict conjunctions and calculate the probability of collision, and thedefinition of the conjunction assessment accuracy underlying a particular CDM, are alsooutside the scope of this Recommended Standard.1.3 DOCUMENT STRUCTURESection 2 provides a brief overview of the CCSDS-proposed CDM.Section 3 provides details about the structure and content of the CDM in ‘Keyword = ValueNotation’ (KVN).Section 4 provides details about the structure and content of the CDM in eXtensible MarkupLanguage (XML).Section 5 addresses the CDM data in general.Section 6 discusses the syntax considerations of the CDM.Annex A is a list of abbreviations and acronyms applicable to the CDM.Annex B provides rationale and requirements for the CDM Recommended Standard.Annex C provides a description of the CA information contained in the CDM.Annex D provides informative references.Annex E provides information on security, the Space Assigned Numbers Authority (SANA),and patent-related information.Annex F provides an example CDM XML schema definition.Annex G provides a CDM XML-to-KVN translator.1.4 CONVENTIONS AND DEFINITIONS1.4.1 NOTATION1.4.1.1 GeneralThe following notational conventions are used in this document:a) multiplication of units is denoted with a single asterisk ‘*’ (e.g., ‘[kg*s]’);CCSDS 508.0-R-1 Page 1-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESb) exponents of units are denoted with a double asterisk (i.e., ‘**’, for example, m/s 2 =m/s**2).1.4.1.2 Unit NotationsThe following conventions for unit notations apply throughout this Recommended Standard.Insofar as possible, an effort has been made to use units that are part of the InternationalSystem of Units (SI); units are either SI base units, SI derived units, or units outside the SIthat are accepted for use with the SI (see reference [1]). There is one specific case, that of thenotation for degrees of plane angle, where the notation that is more widely used in thenavigation community is specified (‘deg’ instead of ‘°’), but every effort has been made tominimize these departures from the SI. The units used within this document are as follows:– deg: degrees of plane angle;– km: kilometers;– m: meters;– m/s: meters per second;– m**2/s: square meters per second;– m**2/s**2: square meters per second squared;– d: days, 86400 SI seconds;– h: hours, 3600 SI seconds;– s: SI seconds;– kg: kilograms;– W/kg: watt per kilogram.1.4.2 NOMENCLATURE1.4.2.1 GeneralThe CDM contains information about a conjunction between two space objects (hereafterreferred to as ‘Object1’ and ‘Object2’).1.4.2.2 Normative TextThe following conventions apply for the normative specifications in this RecommendedStandard:a) the words ‘shall’ and ‘must’ imply a binding and verifiable specification;CCSDS 508.0-R-1 Page 1-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESb) the word ‘should’ implies an optional, but desirable, specification;c) the word ‘may’ implies an optional specification;d) the words ‘is’, ‘are’, and ‘will’ imply statements of fact.NOTE – These conventions do not imply constraints on diction in text that is clearlyinformative in nature.1.4.2.3 Informative TextIn the normative sections of this document (sections 3-6), informative text is set off from thenormative specifications either in notes or under one of the following subsection headings:– Overview;– Background;– Rationale;– Discussion.1.4.3 OTHER CONVENTIONS1.4.3.1 TerminologyIn this document, the term ‘ASCII’ is used generically to refer to the text character setdefined in reference [2].1.4.3.2 OrthographyThe following terms define orthographic conventions for XML notation in thisRecommended Standard:CamelCase. A style of capitalization in which the initial characters of concatenated wordsare capitalized, as in CamelCase.lowerCamelCase. A variant of CamelCase in which the first character of a character stringformed from concatenated words is lowercase, as in lowerCamelCase. In the case of acharacter string consisting of only a single word, only lowercase characters are used.1.5 REFERENCESThe following documents contain provisions which, through reference in this text, constituteprovisions of this Recommended Standard. At the time of publication, the editions indicatedwere valid. All documents are subject to revision, and users of this Recommended StandardCCSDS 508.0-R-1 Page 1-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESare encouraged to investigate the possibility of applying the most recent editions of thedocuments indicated below. The CCSDS Secretariat maintains a register of currently validCCSDS documents.[1] The International System of Units (SI). 8th ed. Sèvres, France: BIPM, 2006.[2] Information Technology—8-Bit Single-Byte Coded Graphic Character Sets—Part 1:Latin Alphabet No. 1. International Standard, ISO/IEC 8859-1:1998. Geneva: ISO,1998.[3] Henry S. Thompson, et al., eds. XML Schema Part 1: Structures. 2nd ed. W3CRecommendation. N.p.: W3C, October 2004.[4] Paul V. Biron and Ashok Malhotra, eds. XML Schema Part 2: Datatypes. 2nd ed.W3C Recommendation. N.p.: W3C, October 2004.[5] Time Code Formats. Recommendation for Space Data System Standards, CCSDS301.0-B-4. Blue Book. Issue 4. Washington, D.C.: CCSDS, November 2010.[6] XML Specification for Navigation Data Messages. Recommendation for Space DataSystem Standards, CCSDS 505.0-B-1. Blue Book. Issue 1. Washington, D.C.:CCSDS, December 2010.CCSDS 508.0-R-1 Page 1-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES2 OVERVIEW2.1 GENERALThis section provides a high-level overview of the CCSDS-proposed CDM, a messageformat designed to facilitate standardized exchange of conjunction information between dataoriginators of CA and satellite owner/operators.2.2 CDM BASIC CONTENTThe proposed CDM is ASCII format encoded either in plain text or XML (see references [2],[3], and [4]). This CDM document describes a KVN-formatted message as well as an XMLformattedmessage (it is desirable that the ICD specify which of these formats will beexchanged).The CDM contains information about a single conjunction between Object1 and Object2. Itcontains– Object1/Object2 positions/velocities at time of closest approach with respect to oneof a small set of widely used reference frames (ITRF, GCRF, EME2000);– Object1/Object2 covariances at time of closest approach with respect to an objectcentered reference frame;– the relative position/velocity of Object2 with respect to an Object1 centered referenceframe;– information relevant to how all the above data was determined.This information is used by satellite owner/operators to evaluate the risk of a conjunction andplan maneuvers if deemed warranted by that agency/organization.Where possible, the CDM is consistent with other CCSDS Navigation Data Messages(NDMs). Similar tables have been used to describe header, metadata, and data information.Common keywords have been used in order to minimize duplication and confusion (e.g.,CREATION_DATE, ORIGINATOR, OBJECT_NAME, OBJECT_ID, etc.).CCSDS 508.0-R-1 Page 2-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES3 CDM CONTENT/STRUCTURE IN KVN3.1 GENERAL3.1.1 The CDM in KVN shall consist of digital data represented as ASCII text lines. Thelines constituting a CDM shall be represented as a combination of the following:a) a header;b) relative metadata/data (metadata/data describing relative relationships betweenObject1 and Object2);c) metadata (data about how Object1 and Object2 data were created);d) data (for both Object1 and Object2); ande) optional comments (explanatory information).NOTES1 KVN messages contain one keyword per line (see 6.2.1.8).2 The order of keywords in the KVN representation is fixed by this RecommendedStandard (see 6.2.1.13).3.1.2 The CDM shall be a plain text file consisting of CA data for a single conjunctionevent. The CDM file shall be readily ported between, and useable within, ‘all’ computingenvironments in use by Member Agencies. It shall be easily readable by both humans andcomputers.3.1.3 The CDM file naming scheme, file name syntax, and file name length shall be agreedto on a case-by-case basis between the participating parties, typically specified in an ICD.3.1.4 The method of exchanging CDMs shall be decided on a case-by-case basis by theparticipating parties and should be documented in an ICD.3.2 CDM HEADERThe CDM header shall consist of the KVN elements defined in table 3-1, which specifies foreach KVN header item:a) the keyword to be used;b) a short description of the item;c) examples of allowed values; andd) whether the item is obligatory or optional.CCSDS 508.0-R-1 Page 3-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESKeyword Description Units ObligatoryMISS_DISTANCEThe miss distance is the norm ofthe components of the relativeposition vector. It indicates howclose the two objects are going tobe based upon the conjunctionassessment screening results.mYesRELATIVE_SPEEDThe relative speed is the norm ofthe components of the relativevelocity vector. It defines how fastthe two objects are moving relativeto each other at the time of thepredicted encounter.m/sNoRELATIVE_POSITION_RThe R component of Object2’sposition relative to Object1’sposition in the Radial, Transverse,and Normal (RTN) coordinateframe (see annex C for definition).mNoRELATIVE_POSITION_TThe T component of Object2’sposition relative to Object1’sposition in the RTN coordinateframe (see annex C for definition).mNoRELATIVE_POSITION_NThe N component of Object2’sposition relative to Object1’sposition in the RTN coordinateframe (see annex C for definition).mNoRELATIVE_VELOCITY_RThe R component of Object2’svelocity relative to Object1’svelocity in the RTN coordinateframe (see annex C for definition).m/sNoRELATIVE_VELOCITY_TThe T component of Object2’svelocity relative to Object1’svelocity in the RTN coordinateframe (see annex C for definition).m/sNoRELATIVE_VELOCITY_NThe N component of Object2’svelocity relative to Object1’svelocity in the RTN coordinateframe (see annex C for definition).m/sNoSTART_SCREEN_PERIODThe start time in UTC of thescreening period for theconjunction assessment. (See6.2.2.11 for formatting rules.)n/aNoSTOP_SCREEN_PERIODThe stop time in UTC of thescreening period for theconjunction assessment. (See6.2.2.11 for formatting rules.)n/aNoSCREEN_VOLUME_FRAMEName of the Object1 centeredreference frame in which thescreening volume data are given(available options are RTN andTransverse, Velocity, and Normal[TVN] [see annex C for definition]).n/aNoSCREEN_VOLUME_SHAPEShape of the screening volume:ELLIPSOID or BOX.n/aNoCCSDS 508.0-R-1 Page 3-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESSCREEN_VOLUME_XSCREEN_VOLUME_YSCREEN_VOLUME_ZENTRY_TIMEEXIT_TIMECOLLISION_PROBABILITYKeyword Description Units ObligatoryCOLLISION_PROBABILITY_METHODThe R or T (depending on if RTNor TVN is selected) componentsize of the screening volume in theSCREEN_VOLUME_FRAME.The T or V (depending on if RTNor TVN is selected) componentsize of the screening volume in theCREEN_VOLUME_FRAME.The N component size of thescreening volume in theSCREEN_VOLUME_FRAME.The time in UTC when Object2enters the screening volume (see6.2.2.11 for formatting rules).The time in UTC when Object2exits the screening volume (see6.2.2.11 for formatting rules).The collision probability is theprobability that Object1 andObject2 will collide.The method that was used tocalculate the collision probability(available options are FOSTER-1992, CHAN-1997, PATERA-2001,ALFANO-2005 or OTHER [seeannex C for definition]).mmmn/an/an/an/aNoNoNoNoNoNoNo3.4 CDM METADATAThe CDM metadata shall consist of the KVN elements defined in table 3-3, which specifiesfor each KVN metadata item:a) the keyword to be used;b) a short description of the item;c) normative (N) values or examples (E) of allowed values;d) the distinction of normative values versus examples of allowed values is specified inthe ‘N/E’ column in the table; ande) whether the item is obligatory or optional.NOTE – Table 3-3 and table 3-4 will be used to define both Object1 and Object2depending on the value of the keyword OBJECT which is specified in table 3-3.CCSDS 508.0-R-1 Page 3-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESTable 3-3: CDM KVN MetadataKeywordDescriptionNormative Values/Examples N/E ObligatoryCOMMENT (See 6.2.4 for formatting rules.) COMMENT This is acommentE NoOBJECTOBJECT_NUMBERSAT_CATALOGThis specifies whether themetadata and data applies toObject1 or Object2.This is the satellite catalognumber for the object.This is the satellite catalog usedfor the object.OBJECT1OBJECT2NYes12345 E YesSATCAT E YesOBJECT_NAME Spacecraft name for the object. SPOT, ENVISAT,IRIDIUM, INTELSATOBJECT_IDThis is the full internationaldesignator for the object. Valueshave the formatYYYY-NNNP{PP}, where:YYYY = year of launch;NNN = three-digit serial numberof launch (with leading zeros);P{PP} = At least one capitalletter for the identification ofthe part brought into space bythe launch. In cases where theobject has no internationaldesignator, the valueUNKNOWN should be used.2002-021A2002-009A1997-020A1998-037AUNKNOWNOBJECT_TYPE This is the object type. PAYLOAD,ROCKET BODY,DEBRIS,UNKNOWN, OTHEROPERATOR_CONTACT_POSITIONOPERATOR_ORGANIZATIONOPERATOR_PHONEOPERATOR_EMAILEPHEMERIS_NAMEContact position of the operatorof the object.Contact organization of theobject.Phone number of the contactposition for the object.Email address of the contactorganization of the object.Unique name of the externalephemeris file used for theobject or NONE. This is used toindicate whether an external(i.e., Owner/Operator [O/O]provided) ephemeris file wasused to calculate the CA.ORBITAL SAFETYANALYST (OSA),NETWORKCONTROLLEREUMETSAT, ESA,INTELSAT, IRIDIUMEENEEYesYesNoNoNo+49615130312 E NoHANS.WALDVOGEL@EUMETSAT.INTEPHEMERISSATELLITE A,NONEEENoYesCCSDS 508.0-R-1 Page 3-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESKeywordNUMBER_SENSORSTRACKING_DATA_TYPESADDITIONAL_TRACKINGCOVARIANCE_METHODMANEUVERABLEMAN_INCLUDEDORBIT_CENTERREF_FRAMEGRAVITY_MODELATMOSPHERIC_MODELN_BODY_PERTURBATIONSSOLAR_RAD_PRESSUREEARTH_TIDESINTRACK_THRUSTDescriptionThe number of sensors thatwere used to provide theobservations used in the OrbitDetermination (OD) of theobject.Describes the type(s) of trackingdata used in the OD of theobject.Has additional sensor trackingbeen applied to the OD of theobject (see annex C fordefinition)?Describes if the covariance wascalculated during the OD thatproduced the state vector or a ifdefault value was used.The maneuver capacity of theobject.In the event that an externalephemeris was used to calculatethe CA, this indicates that amaneuver was included in theexternally provided ephemeris.Defines the central body aboutwhich Object1 and Object2 orbit.If not specified, the center isassumed to be Earth.Name of the reference frame inwhich the state vector data aregiven (value must be selectedfrom the list of values to the right(see reference [D1]) and beconsistent between Object1 andObject2).The gravity model used for theOD of the object (see annex Cunder GRAVITY_MODEL fordefinition).The atmospheric drag modelused for the OD of the object.The N-body gravitationalperturbations that were used forthe OD of the object.Are solar radiation pressureperturbations used for the OD ofthe object?Are solid earth and ocean tidesused for the OD of the object?Is in-track thrust modeling usedfor the OD of the object?Normative Values/Examples N/E Obligatory1,2,3 E NoRADAR, OPTICAL,GPS, DOPPLERENoYES, NO N NoCALCULATED,DEFAULTNYesYES, NO,N YesUNKNOWNYES, NO N NoEARTH, SUN,MOON, MARS,GCRFEME2000ITRFEGM-96: 36D 36O,WGS-84_GEOID:24D 24O,JGM-2 : 41D 41OJACCHIA 70, MSIS,JACCHIA 70 DCA,NONEMOON, SUN,MARS, JUPITERENEEENoYesNoNoNoYES, NO N NoYES, NO N NoYES, NO N NoCCSDS 508.0-R-1 Page 3-6 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES3.5 CDM DATA3.5.1 The CDM Data section shall be formed as logical blocks:– OD Parameters;– Additional Parameters;– State Vector; and– Covariance.3.5.2 The logical blocks of the CDM Data section shall consist of KVN elements asdefined in table 3-4, which specifies for each data item:a) the keyword to be used;b) a short description of the item;c) the units to be used; andd) whether the item is obligatory or optional.Table 3-4: CDM KVN DataKeyword Description Units ObligatoryCOMMENT (See 6.2.4 for formatting rules.) n/a NoOD ParametersCOMMENT (See 6.2.4 for formatting rules.) n/a NoTIME_LASTOBThe time in UTC of the last accepted observationused in the OD of the object. This can be enteredas the exact time (see 6.2.2.11 for formattingrules) or an elapsed time, from the messagecreation time, that includes the time of the lastaccepted observation used in the OD of theobject. The rules for the latter case are as follows(see 6.2.2.12 for formatting rules):n/a or hNoFor all Near Earth (NE) objects:- Less than 6 hours from message creation time- 6 to 12 hours from message creation time- Greater than 12 hours from message creationtimeFor all Far From Earth (FE) objects (see annex Cunder TIME_LASTOB for definition of FE):- Less than 24 hours from message creation time- 24 to 48 hours from message creation time- Greater than 48 hours from message creationtimeRECOMMENDED_OD_SPANThe recommended OD time span calculated forthe object (see annex C for definition).dNoCCSDS 508.0-R-1 Page 3-7 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESKeyword Description Units ObligatoryACTUAL_OD_SPANBased on the observations available and theRECOMMENDED_OD_SPAN, this is the actualtime span used for the OD of the object (seeannex C for definition).dNoMAXIMUM_OBS_GAPOBS_AVAILABLEOBS_USEDTRACKS_AVAILABLETRACKS_USEDWEIGHTED_RMSTIME_NEXT_UPDATEThe maximum time between observationsaccepted for the OD of the object (see annex Cfor definition).The number of observations available for the ODof the object (see annex C for definition).The number of observations accepted for the ODof the object(see annex C for definition).The number of sensor tracks available for the ODof the object(see annex C for definition).The number of sensor tracks accepted for the ODof the object (see annex C for definition).The weighted Root Mean Square (RMS) of theresiduals from a batch least squares OD (seeannex C for definition).The expected elapsed time from the current ODupdate that was used to create the current CDMto the next OD update.Additional ParametersCOMMENT (See 6.2.4 for formatting rules) n/a NoAREA The area of the object (see annex C for definition). m**2 NoMASS The mass of the object. kg Nohn/an/an/an/an/ahNoNoNoNoNoNoNoCD_AREA_OVER_MASSThe object’s C D •A/m used to propagate the statevector and covariance to TCA (see annex C fordefinition).m**2/kgNoCR_AREA_OVER_MASSThe object’s C r •A/m used to propagate the statevector and covariance to TCA (see annex C fordefinition).m**2/kgNoTHRUST_ACCELERATIONThe object’s acceleration due to in-track thrustused to propagate the state vector and covarianceto TCA (see annex C for definition).m/s**2NoSEDRSpecific Energy Dissipation Rate (SEDR) isrepresentative of the amount of energy beingremoved from the object’s orbit by atmosphericdrag. This value is an average calculated duringthe OD(see annex C for definition).W/kgNoState VectorCOMMENT (See 6.2.4 for formatting rules.) n/a NoX Object Position Vector X component. km YesY Object Position Vector Y component. km YesZ Object Position Vector Z component. km YesX_DOT Object Velocity Vector X component. km/s YesY_DOT Object Velocity Vector Y component. km/s YesZ_DOT Object Velocity Vector Z component. km/s YesCCSDS 508.0-R-1 Page 3-8 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESKeyword Description Units ObligatoryCovariance Matrix in the RTN Coordinate Frame (see annex C for definition)(Covariance Matrix 9x9 Lower Triangular Form. All parameters of the 6x6 matrix must be given.)COMMENT (See 6.2.4 for formatting rules.) n/a NoCR_R Object covariance matrix [1,1] m**2 YesCT_R Object covariance matrix [2,1] m**2 YesCT_T Object covariance matrix [2,2] m**2 YesCN_R Object covariance matrix [3,1] m**2 YesCN_T Object covariance matrix [3,2] m**2 YesCN_N Object covariance matrix [3,3] m**2 YesCRDOT_R Object covariance matrix [4,1] m**2/s YesCRDOT_T Object covariance matrix [4,2] m**2/s YesCRDOT_N Object covariance matrix [4,3] m**2/s YesCRDOT_RDOT Object covariance matrix [4,4] m**2/s**2 YesCTDOT_R Object covariance matrix [5,1] m**2/s YesCTDOT_T Object covariance matrix [5,2] m**2/s YesCTDOT_N Object covariance matrix [5,3] m**2/s YesCTDOT_RDOT Object covariance matrix [5,4] m**2/s**2 YesCTDOT_TDOT Object covariance matrix [5,5] m**2/s**2 YesCNDOT_R Object covariance matrix [6,1] m**2/s YesCNDOT_T Object covariance matrix [6,2] m**2/s YesCNDOT_N Object covariance matrix [6,3] m**2/s YesCNDOT_RDOT Object covariance matrix [6,4] m**2/s**2 YesCNDOT_TDOT Object covariance matrix [6,5] m**2/s**2 YesCNDOT_NDOT Object covariance matrix [6,6] m**2/s**2 YesCDRG_R Object covariance matrix [7,1] m**3/kg NoCDRG_T Object covariance matrix [7,2] m**3/kg NoCDRG_N Object covariance matrix [7,3] m**3/kg NoCDRG_RDOT Object covariance matrix [7,4] m**3/kg*s NoCDRG_TDOT Object covariance matrix [7,5] m**3/kg*s NoCDRG_NDOT Object covariance matrix [7,6] m**3/kg*s NoCDRG_DRG Object covariance matrix [7,7] m**4/kg**2 NoCSRP_R Object covariance matrix [8,1] m**3/kg NoCSRP_T Object covariance matrix [8,2] m**3/kg NoCSRP_N Object covariance matrix [8,3] m**3/kg NoCSRP_RDOT Object covariance matrix [8,4] m**3/kg*s NoCSRP_TDOT Object covariance matrix [8,5] m**3/kg*s NoCSRP_NDOT Object covariance matrix [8,6] m**3/kg*s NoCSRP_DRG Object covariance matrix [8,7] m**4/kg**2 NoCSRP_SRP Object covariance matrix [8,8] m**4/kg**2 NoCTHR_R Object covariance matrix [9,1] m**2/s**2 NoCTHR_T Object covariance matrix [9,2] m**2/s**2 NoCTHR_N Object covariance matrix [9,3] m**2/s**2 NoCCSDS 508.0-R-1 Page 3-9 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESKeyword Description Units ObligatoryCTHR_RDOT Object covariance matrix [9,4] m**2/s**3 NoCTHR_TDOT Object covariance matrix [9,5] m**2/s**3 NoCTHR_NDOT Object covariance matrix [9,6] m**2/s**3 NoCTHR_DRG Object covariance matrix [9,7] m**3/kg*s**2 NoCTHR_SRP Object covariance matrix [9,8] m**3/kg*s**2 NoCTHR_THR Object covariance matrix [9,9] m**2/s**4 No3.6 DISCUSSION—CDM/KVN EXAMPLES3.6.1 OVERVIEWSubsections 3.6.2-3.6.4 show examples of a CDM message in KVN. Subsection 3.6.2includes only obligatory keywords and subsections 3.6.3-3.6.4 include optional keywords aswell as obligatory.3.6.2 AN EXAMPLE OF A CDM IN KVN WITH ONLY OBLIGATORY KEYWORDSCCSDS_CDM_VERS = 1.0CREATION_DATE= 2010-03-12T22:31:12.000ORIGINATOR= JSPOCMESSAGE_ID = 201113719185TCA= 2010-03-13T22:37:52.618MISS_DISTANCE = 715 [m]OBJECT= OBJECT1OBJECT_NUMBER = 12345SAT_CATALOG= SATCATOBJECT_NAME= SATELLITE AOBJECT_ID = 1997-030EEPHEMERIS_NAME= EPHEMERIS SATELLITE ACOVARIANCE_METHOD= CALCULATEDMANEUVERABLE= YESREF_FRAME= EME2000X = 2570.097065 [km]Y = 2244.654904 [km]Z = 6281.497978 [km]X_DOT = 4.418769571 [km/s]Y_DOT = 4.833547743 [km/s]Z_DOT = -3.526774282 [km/s]CR_R = 4.142E+01 [m**2]CT_R = -8.579E+00 [m**2]CT_T = 2.533E+03 [m**2]CN_R = -2.313E+01 [m**2]CN_T = 1.336E+01 [m**2]CCSDS 508.0-R-1 Page 3-10 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCN_N = 7.098E+01 [m**2]CRDOT_R = 2.520E-03 [m**2/s]CRDOT_T = -5.476E+00 [m**2/s]CRDOT_N = 8.626E-04 [m**2/s]CRDOT_RDOT = 5.744E-03 [m**2/s**2]CTDOT_RCTDOT_T= -1.006E-02= 4.041E-03[m**2/s][m**2/s]CTDOT_N = -1.359E-03 [m**2/s]CTDOT_RDOT = -1.502E-05 [m**2/s**2]CTDOT_TDOT = 1.049E-05 [m**2/s**2]CNDOT_R = 1.053E-03 [m**2/s]CNDOT_T = -3.412E-03 [m**2/s]CNDOT_N = 1.213E-02 [m**2/s]CNDOT_RDOT = -3.004E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOTOBJECT= -1.091E-06= 5.529E-05= OBJECT2[m**2/s**2][m**2/s**2]OBJECT_NUMBER = 30337SAT_CATALOG= SATCATOBJECT_NAME= FENGYUN 1C DEBOBJECT_ID= 1999-025AAEPHEMERIS_NAME= NONECOVARIANCE_METHOD= CALCULATEDMANEUVERABLE= NOREF_FRAME= EME2000X = 2569.540800 [km]Y = 2245.093614 [km]Z = 6281.599946 [km]X_DOT = -2.888612500 [km/s]Y_DOT = -6.007247516 [km/s]Z_DOT = 3.328770172 [km/s]CR_R = 1.337E+03 [m**2]CT_R = -4.806E+04 [m**2]CT_T = 2.492E+06 [m**2]CN_R = -3.298E+01 [m**2]CN_T = -7.5888E+02 [m**2]CN_N = 7.105E+01 [m**2]CRDOT_R = 2.591E-03 [m**2/s]CRDOT_T = -4.152E-02 [m**2/s]CRDOT_N = -1.784E-06 [m**2/s]CRDOT_RDOT = 6.886E-05 [m**2/s**2]CTDOT_RCTDOT_T= -1.016E-02= -1.506E-04[m**2/s][m**2/s]CTDOT_N = 1.637E-03 [m**2/s]CTDOT_RDOT = -2.987E-06 [m**2/s**2]CCSDS 508.0-R-1 Page 3-11 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCTDOT_TDOT = 1.059E-05 [m**2/s**2]CNDOT_R = 4.400E-03 [m**2/s]CNDOT_T = 8.482E-03 [m**2/s]CNDOT_N = 8.633E-05 [m**2/s]CNDOT_RDOT = -1.903E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOT= -4.594E-06= 5.178E-05[m**2/s**2][m**2/s**2]3.6.3 AN EXAMPLE OF A CDM IN KVN WHICH INCLUDES OPTIONAL KEYWORDSCCSDS_CDM_VERS = 1.0CREATION_DATE= 2010-03-12T22:31:12.000ORIGINATOR= JSPOCCDM_FOR= SATELLITE AMESSAGE_ID = 201113719185COMMENT Relative Metadata/DataTCA= 2010-03-13T22:37:52.618MISS_DISTANCE = 715 [m]RELATIVE_SPEED = 14762 [m/s]RELATIVE_POSITION_R = 27.4 [m]RELATIVE_POSITION_T = -70.2 [m]RELATIVE_POSITION_N = 711.8 [m]RELATIVE_VELOCITY_R = -7.2 [m/s]RELATIVE_VELOCITY_T = -14692.0 [m/s]RELATIVE_VELOCITY_N = -1437.2 [m/s]START_SCREEN_PERIOD= 2010-03-12T18:29:32:212STOP_SCREEN_PERIOD= 2010-03-15T18:29:32:212SCREEN_VOLUME_FRAME= RTNSCREEN_VOLUME_SHAPE= ELLIPSOIDSCREEN_VOLUME_X = 200 [m]SCREEN_VOLUME_Y = 1000 [m]SCREEN_VOLUME_Z = 1000 [m]ENTRY_TIME= 2010-03-13T20:25:43.222EXIT_TIME= 2010-03-13T23:44:29.324COLLISION_PROBABILITY= 4.835E-05COLLISION_PROBABILITY_METHOD= FOSTER-1992COMMENT Object1 MetadataOBJECT= OBJECT1OBJECT_NUMBER = 12345SAT_CATALOG= SATCATOBJECT_NAME= SATELLITE AOBJECT_ID = 1997-030EOBJECT_TYPE= PAYLOADOPERATOR_CONTACT_POSITION= OSACCSDS 508.0-R-1 Page 3-12 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESOPERATOR_ORGANIZATION= EUMETSATOPERATOR_PHONE = +49615130312OPERATOR_EMAILEPHEMERIS_NAMENUMBER_SENSORS = 2TRACKING_DATA_TYPESADDITIONAL_TRACKINGCOVARIANCE_METHODMANEUVERABLEMAN_INCLUDEDREF_FRAMEGRAVITY_MODELATMOSPHERIC_MODELN_BODY_PERTURBATIONSSOLAR_RAD_PRESSUREEARTH_TIDESINTRACK_THRUSTCOMMENT Object1 DataCOMMENT Object1 OD ParametersTIME_LASTOB= HANS.WALDVOGEL@EUMETSAT.INT= EPHEMERIS SATELLITE A= GPS, DOPPLER= YES= CALCULATED= YES= YES= EME2000= EGM-96: 36D 36O= JACCHIA 70 DCA= MOON, SUN= NO= NO= NO= 2010-03-12T02:14:12.746RECOMMENDED_OD_SPAN = 7.88 [d]ACTUAL_OD_SPAN = 5.50 [d]MAXIMUM_OBS_GAP = 2.4 [h]OBS_AVAILABLE = 592OBS_USED = 418TRACKS_AVAILABLE = 123TRACKS USED = 98WEIGHTED_RMS = 0.864TIME_NEXT_UPDATE = 2.0 [h]COMMENT Object1 Additional ParametersAREA = 5.2 [m**2]MASS = 2516 [kg]CD_AREA_OVER_MASSCR_AREA_OVER_MASS= 0.045663= 0.000000[m**2/kg][m**2/kg]THRUST_ACCELERATION = 0.0 [m/s**2]SEDR = 4.54570E-05 [W/kg]COMMENT Object1 State VectorX = 2570.097065 [km]Y = 2244.654904 [km]Z = 6281.497978 [km]X_DOT = 4.418769571 [km/s]Y_DOT = 4.833547743 [km/s]Z_DOT = -3.526774282 [km/s]COMMENT Object1 Covariance in the RTN Coordinate FrameCR_R = 4.142E+01 [m**2]CCSDS 508.0-R-1 Page 3-13 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCT_R = -8.579E+00 [m**2]CT_T = 2.533E+03 [m**2]CN_R = -2.313E+01 [m**2]CN_T = 1.336E+01 [m**2]CN_N = 7.098E+01 [m**2]CRDOT_R = 2.520E-03 [m**2/s]CRDOT_T = -5.476E+00 [m**2/s]CRDOT_N = 8.626E-04 [m**2/s]CRDOT_RDOT = 5.744E-03 [m**2/s**2]CTDOT_RCTDOT_T= -1.006E-02= 4.041E-03[m**2/s][m**2/s]CTDOT_N = -1.359E-03 [m**2/s]CTDOT_RDOT = -1.502E-05 [m**2/s**2]CTDOT_TDOT = 1.049E-05 [m**2/s**2]CNDOT_R = 1.053E-03 [m**2/s]CNDOT_T = -3.412E-03 [m**2/s]CNDOT_N = 1.213E-02 [m**2/s]CNDOT_RDOT = -3.004E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOTCOMMENT Object2 MetadataOBJECT= -1.091E-06= 5.529E-05= OBJECT2OBJECT_NUMBER = 30337SAT_CATALOG= SATCATOBJECT_NAME= FENGYUN 1C DEBOBJECT_ID= 1999-025AAOBJECT_TYPE= DEBRISEPHEMERIS_NAME= NONENUMBER_SENSORS = 3TRACKING_DATA_TYPES= RADARADDITIONAL_TRACKING= NOCOVARIANCE_METHOD= CALCULATEDMANEUVERABLE= NOREF_FRAME= EME2000GRAVITY_MODEL= EGM-96: 36D 36OATMOSPHERIC_MODEL= JACCHIA 70 DCAN_BODY_PERTURBATIONS= MOON, SUNSOLAR_RAD_PRESSURE= YESEARTH_TIDES= NOINTRACK_THRUST= NOCOMMENT Object2 DataCOMMENT Object2 OD ParametersTIME_LASTOB = 6-12 [h]RECOMMENDED_OD_SPAN = 2.63 [d]ACTUAL_OD_SPAN = 2.63 [d][m**2/s**2][m**2/s**2]CCSDS 508.0-R-1 Page 3-14 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESMAXIMUM_OBS_GAP = 5.7 [h]OBS_AVAILABLE = 59OBS_USED = 58TRACKS_AVAILABLE = 15TRACKS USED = 15WEIGHTED_RMS = 0.864COMMENT Object2 Additional ParametersAREA = 0.9 [m**2]CD_AREA_OVER_MASSCR_AREA_OVER_MASS= 0.118668= 0.075204[m**2/kg][m**2/kg]THRUST_ACCELERATION = 0.0 [m/s**2]SEDR = 5.40900E-03 [W/kg]COMMENT Object2 State VectorX = 2569.540800 [km]Y = 2245.093614 [km]Z = 6281.599946 [km]X_DOT = -2.888612500 [km/s]Y_DOT = -6.007247516 [km/s]Z_DOT = 3.328770172 [km/s]COMMENT Object2 Covariance in the RTN Coordinate FrameCR_R = 1.337E+03 [m**2]CT_R = -4.806E+04 [m**2]CT_T = 2.492E+06 [m**2]CN_R = -3.298E+01 [m**2]CN_T = -7.5888E+02 [m**2]CN_N = 7.105E+01 [m**2]CRDOT_R = 2.591E-03 [m**2/s]CRDOT_T = -4.152E-02 [m**2/s]CRDOT_N = -1.784E-06 [m**2/s]CRDOT_RDOT = 6.886E-05 [m**2/s**2]CTDOT_RCTDOT_T= -1.016E-02= -1.506E-04[m**2/s][m**2/s]CTDOT_N = 1.637E-03 [m**2/s]CTDOT_RDOT = -2.987E-06 [m**2/s**2]CTDOT_TDOT = 1.059E-05 [m**2/s**2]CNDOT_R = 4.400E-03 [m**2/s]CNDOT_T = 8.482E-03 [m**2/s]CNDOT_N = 8.633E-05 [m**2/s]CNDOT_RDOT = -1.903E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOT= -4.594E-06= 5.178E-05[m**2/s**2][m**2/s**2]CCSDS 508.0-R-1 Page 3-15 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES3.6.4 ANOTHER EXAMPLE OF A CDM IN KVN WHICH INCLUDES OPTIONALKEYWORDSCCSDS_CDM_VERS = 1.0CREATION_DATE= 2012-01-12T22:31:12.000ORIGINATOR= SDCCDM_FOR = GALAXY 15MESSAGE_ID = 20120112223112COMMENT Relative Metadata/DataTCA= 2012-12-13T22:37:52.618MISS_DISTANCE = 104.92 [m]RELATIVE_SPEED = 12093.52 [m/s]RELATIVE_POSITION_R = 30.6 [m]RELATIVE_POSITION_T = 100.2 [m]RELATIVE_POSITION_N = 5.7 [m]RELATIVE_VELOCITY_R = -20.3 [m/s]RELATIVE_VELOCITY_T = -12000.0 [m/s]RELATIVE_VELOCITY_N = -1500.9 [m/s]START_SCREEN_PERIOD= 2012-09-12T18:29:32:212STOP_SCREEN_PERIOD= 2012-16-15T18:29:32:212SCREEN_VOLUME_FRAME= RTNSCREEN_VOLUME_SHAPE= ELLIPSOIDSCREEN_VOLUME_X = 500 [m]SCREEN_VOLUME_Y = 500 [m]SCREEN_VOLUME_Z = 500 [m]ENTRY_TIME= 2012-12-13T20:25:43.222EXIT_TIME= 2010-12-13T23:44:29.324COLLISION_PROBABILITY= 2.355e-03COLLISION_PROBABILITY_METHOD = ALFANO-2005COMMENT Object1 MetadataOBJECT= OBJECT1OBJECT_NUMBER = 28884SAT_CATALOG= SATCATOBJECT_NAME = GALAXY 15OBJECT_ID = 2005-041AOBJECT_TYPE= PAYLOADOPERATOR_ORGANIZATION= INTELSATEPHEMERIS_NAME= GALAXY-15A-2012JAN-WMANEUVER23ACOVARIANCE_METHOD= CALCULATEDMANEUVERABLE= YESMAN_INCLUDED= YESREF_FRAME= EME2000COMMENT Object1 DataCOMMENT Object1 OD ParametersTIME_LASTOB= 2012-09-06T20:25:43.222CCSDS 508.0-R-1 Page 3-16 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESX = -41600.46272465 [km]Y = 3626.912120064 [km]Z = 6039.06350924 [km]X_DOT = -0.306132852503 [km/s]Y_DOT = -3.044998353334 [km/s]Z_DOT = -0.287674310725 [km/s]COMMENT Object1 Covariance in the RTN Coordinate FrameCR_R= 4.142E+01CT_R = -8.579E+00 [m**2]CT_T = 2.533E+03 [m**2]CN_R = -2.313E+01 [m**2]CN_T = 1.336E+01 [m**2]CN_N = 7.098E+01 [m**2]CRDOT_R = 2.520E-03 [m**2/s]CRDOT_T = -5.476E+00 [m**2/s]CRDOT_N = 8.626E-04 [m**2/s]CRDOT_RDOT = 5.744E-03 [m**2/s**2]CTDOT_RCTDOT_T= -1.006E-02= 4.041E-03[m**2/s][m**2/s]CTDOT_N = -1.359E-03 [m**2/s]CTDOT_RDOT = -1.502E-05 [m**2/s**2]CTDOT_TDOT = 1.049E-05 [m**2/s**2]CNDOT_R = 1.053E-03 [m**2/s]CNDOT_T = -3.412E-03 [m**2/s]CNDOT_N = 1.213E-02 [m**2/s]CNDOT_RDOT = -3.004E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOTCOMMENT Object2 MetadataOBJECT= -1.091E-06= 5.529E-05= OBJECT2OBJECT_NUMBER = 21139SAT_CATALOG= SATCATOBJECT_NAME= ASTRA 1BOBJECT_ID = 1991-051AOBJECT_TYPE= PAYLOADEPHEMERIS_NAME= NONEADDITIONAL_TRACKING= YESCOVARIANCE_METHOD= CALCULATEDMANEUVERABLE= YESREF_FRAME= EME2000COMMENT Object1 DataCOMMENT Object1 OD ParametersTIME_LASTOB= 2012-08-03T10:22:14.548X = -2956.02034826 [km]Y = 42584.37595741 [km][m**2/s**2][m**2/s**2]CCSDS 508.0-R-1 Page 3-17 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESZ = 123.77550476 [km]X_DOT = -3.047096589536 [km/s]Y_DOT = -0.211583631026 [km/s]Z_DOT = 0.062261259643 [km/s]COMMENT Object2 Covariance in the RTN Coordinate FrameCR_R = 1.337E+03 [m**2]CT_R = -4.806E+04 [m**2]CT_T = 2.492E+06 [m**2]CN_R = -3.298E+01 [m**2]CN_T = -7.5888E+02 [m**2]CN_N = 7.105E+01 [m**2]CRDOT_R = 2.591E-03 [m**2/s]CRDOT_T = -4.152E-02 [m**2/s]CRDOT_N = -1.784E-06 [m**2/s]CRDOT_RDOT = 6.886E-05 [m**2/s**2]CTDOT_RCTDOT_T= -1.016E-02= -1.506E-04[m**2/s][m**2/s]CTDOT_N = 1.637E-03 [m**2/s]CTDOT_RDOT = -2.987E-06 [m**2/s**2]CTDOT_TDOT = 1.059E-05 [m**2/s**2]CNDOT_R = 4.400E-03 [m**2/s]CNDOT_T = 8.482E-03 [m**2/s]CNDOT_N = 8.633E-05 [m**2/s]CNDOT_RDOT = -1.903E-06 [m**2/s**2]CNDOT_TDOTCNDOT_NDOT= -4.594E-06= 5.178E-05[m**2/s**2][m**2/s**2]CCSDS 508.0-R-1 Page 3-18 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4 CDM CONTENT/STRUCTURE IN XML4.1 DISCUSSION—THE CDM/XML SCHEMAThe CDM/XML schema will be available on the SANA Web site. SANA is the registrar forthe protocol registries created under CCSDS.The CDM XML schema explicitly defines the permitted data elements and values acceptablefor the XML version of the CDM message.The location of the CDM/XML schema will be:http://sanaregistry.org/r/ndmxml/ndmxml-1.0-cdm-1.0.xsdWhere possible this schema uses simple types and complex types used by the constituentschemas that make up NDMs (AEM, APM, OEM, OMM, OPM, TDM). 14.2 CDM/XML BASIC STRUCTURE4.2.1 Each CDM shall consist of a and a .4.2.2 The CDM body shall consist of exactly two segment constructs.4.2.3 Each shall consist of a / pair, as shown in figure 4-1.Figure 4-1: CDM XML Basic Structure1 An example CDM/XML schema is currently referenced in annex F of this document. Once this document is finalized, annex F will beremoved. This will allow updates of the schema on the Web site without correspondingly updating the CDM document.CCSDS 508.0-R-1 Page 4-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4.2.4 KVN keywords shall be uppercase with ‘_’ (the underscore character) as separators.XML tags shall be uppercase and correspond with the keywords in 3.2 through 3.6. TheXML logical tags related to message structure shall be in lowerCamelCase.4.3 CONSTRUCTING A CDM/XML INSTANCE4.3.1 OVERVIEWThis subsection provides more detailed instructions for the user on how to create an XMLmessage based on the ASCII-text KVN-formatted message described in 3.1 through 3.6 (seereference [6]).4.3.2 XML VERSIONThe first line in the instantiation shall specify the XML version:This line must appear on the first line of each instantiation, exactly as shown.4.3.3 BEGINNING THE INSTANTIATION: ROOT DATA ELEMENT4.3.3.1 A CDM instantiation shall be delimited with the root element tagsusing the standard attributes documented in reference [3].4.3.3.2 The XML Schema Instance namespace attribute must appear in the root element tagof all CDM/XML instantiations, exactly as shown:xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"4.3.3.3 If it is desired to validate an instantiation against the CCSDS Web-based schema,the xsi:noNamespaceSchemaLocation attribute must be coded as a single string of non-blankcharacters, with no line breaks, exactly as shown:xsi:noNamespaceSchemaLocation="http://sanaregistry.org/r/ndmxml/ndmxml-1.0-master.xsd"NOTE – The length of the value associated with the xsi:noNamespaceSchemaLocationattribute can cause the string to wrap to a new line; however, the string itselfcontains no breaks.4.3.3.4 For use in a local operations environment, the schema set may be downloaded fromthe CCSDS Web site to a local server that meets local requirements for operationsrobustness.CCSDS 508.0-R-1 Page 4-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4.3.3.5 If a local version is used, the value associated with thexsi:noNamespaceSchemaLocation attribute must be changed to a URL that is accessible tothe local server.4.3.3.6 The final attributes of the tag shall be ‘id’ and ‘version’.4.3.3.7 The ‘id’ attribute shall be ‘id="CCSDS_CDM_VERS"’.4.3.3.8 The ‘version’ attribute shall be ‘version="1.0"’.NOTE – The following example root element tag for a CDM instantiation combines all thedirections in the preceding several subsections:4.3.4 THE CDM/XML HEADER SECTION4.3.4.1 The CDM header shall have a standard header format, with tags and.4.3.4.2 Immediately following the tag the message may have any number of tag pairs.4.3.4.3 The standard CDM header shall contain the following element tags:a) b) c) d) NOTE – The rules for these keywords are specified in 3.2. The header would look likethis:Some comment string.2010-03-12T22:31:12.000JSpOCSATELLITE A201113719185CCSDS 508.0-R-1 Page 4-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4.3.5 THE CDM/XML BODY SECTION4.3.5.1 After coding the , the instantiation must include a tagpair.4.3.5.2 Inside the tag pair must appear one tag pair.4.3.5.3 Following the tag pair mustappear two tag pairs, one for Object1 and one for Object2.4.3.5.4 Each segment must be made up of one tag pair and one tag pair.4.3.6 THE CDM/XML RELATIVE METADATA/DATA SECTIONThe relative metadata/data section shall be set off by the tag combination. Between the and tags, the keywords shall be thosespecified in table 3-2.4.3.7 THE CDM/XML METADATA SECTION4.3.7.1 All CDMs must have two metadata sections, one for Object1 and one for Object2.4.3.7.2 The metadata section for Object1 shall follow the relative metadata/data section andshall be set off by the tag combination. The metadata section forObject2 shall follow the Object1 data section and shall be set off by the tag combination.4.3.7.3 Between the and tags for both Object1 and Object2, thekeywords shall be those specified in table 3-3. The value of the keyword OBJECT shall beused to define whether the metadata defines Object1 or Object2.4.3.8 THE CDM DATA SECTION4.3.8.1 All CDMs must have two data sections, one for Object1 and one for Object2.4.3.8.2 Each data section shall follow the corresponding metadata section and shall be setoff by the tag combination.4.3.8.3 Between the and tags, the keywords shall be those specified intable 3-4. The value of the keyword OBJECT, referenced in table 3-3, shall be used to definewhether the data defines Object1 or Object2.CCSDS 508.0-R-1 Page 4-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4.3.9 SPECIAL CDM/XML TAGS4.3.9.1 The information content in the CDM shall be separated into constructs described in3.5 as ‘logical blocks’. Special tags in the CDM shall be used to encapsulate the informationin the logical blocks of the CDM. The special tags indicating logical block divisions shall bethose defined in table 4-1.Table 4-1: Relation of KVN Logical Blocks to Special CDM/XML TagsCDM Logical BlockOD ParametersAdditional ParametersState VectorCovariance MatrixAssociated CDM/XML Tag4.3.9.2 Other special tags used shall be those defined in table 4-2.Table 4-2: Other Special CDM/XML TagsSpecial TagDefinitionIncludes the relative state vector keywords:RELATIVE_POSITION_R, RELATIVE_POSITION_T,RELATIVE_POSITION_N, RELATIVE_VELOCITY_R,RELATIVE_VELOCITY_T, andRELATIVE_VELOCITY_N.The TIME_LASTOB entered as the exact time (seetable 3-4, TIME_LASTOB).The TIME_LASTOB entered as an elapsed time, fromthe message creation time, that includes the time ofthe last accepted observation used in the OD of theobject (see table 3-4, TIME_LASTOB).4.3.10 UNITS IN THE CDM/XMLThe units in the CDM/XML shall be the same units used in the KVN-formatted CDMdescribed in 3.5. XML attributes shall be used to explicitly define the units or otherimportant information associated with the given data element.CCSDS 508.0-R-1 Page 4-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES4.4 DISCUSSION—CDM/XML EXAMPLEThe following is a sample of a CDM in XML format:Sample CDM - XML version2010-03-12T22:31:12.000JSPOCSATELLITE A20111371985Relative Metadata/Data2010-03-13T22:37:52.6187151476227.4-70.2711.8-7.2-14692.0-1437.22010-03-12T18:29:32.2122010-03-15T18:29:32.212RTNELLIPSOID200100010002010-03-13T20:25:43.2222010-03-13T23:44:29.3244.835E-05FOSTER-1992Object1 MetadataOBJECT112345SATCATSATELLITE A1997-030EPAYLOADOSAEUMETSAT+49615130312CCSDS 508.0-R-1 Page 4-6 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESHANS.WALDVOGEL@EUMETSAT.INTEPHEMERIS SATELLITE A2GPS,DOPPLERYESCALCULATEDYESYESEME2000EGM-96: 36D 36OJACCHIA 70 DCAMOON,SUNNONONOObject1 DataObject1 OD Parameters2010-03-12T02:14:12.7467.885.502.4592418123980.8642.0Object 1 Additional Parameters5.225160.0456630.0000000.04.54570E-05Object1 State Vector2570.0970652244.6549046281.4979784.4187695714.833547743-3.526774282Object1 Covariance in the RTN Coordinate Frame 4.142E+01-8.579E+00CCSDS 508.0-R-1 Page 4-7 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES2.533E+03-2.313E+011.336E+017.098E+012.520E-03-5.476E+008.626E-045.744E-03-1.006E-024.041E-03-1.359E-03-1.502E-051.049E-051.053E-03-3.412E-031.213E-02-3.004E-06-1.091E-065.529E-05Object2 MetadataOBJECT230337SATCATFENGYUN 1C DEB1999-025AADEBRISNONE3RADARNOCALCULATEDNOEME2000EGM-96: 36D 36OJACCHIA 70 DCAMOON,SUNYESNONOObject2 DataObject2 OD Parameters6-122.632.635.7CCSDS 508.0-R-1 Page 4-8 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES595815150.864Object2 Additional Parameters0.90.1186680.0752040.05.40900E-03Object2 State Vector2569.5408002245.0936146281.599946-2.888612500-6.0072475163.328770172Object2 Covariance in the RTN Coordinate Frame1.337E+03-4.806E+042.492E+06-3.298E+01-7.5888E+027.105E+012.591E-03-4.152E-02-1.784E-066.886E-05-1.016E-02-1.506E-041.637E-03-2.987E-061.059E-054.400E-038.482E-038.633E-05-1.903E-06-4.594E-065.178E-05CCSDS 508.0-R-1 Page 4-9 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES5 CDM DATA IN GENERAL5.1 OVERVIEWThe following rules apply for both KVN- and XML-formatted CDMs.5.2 RULES THAT APPLY IN KVN AND XML5.2.1 Some keywords represent obligatory items and some are optional. KVN and XMLassignments representing optional items may be omitted.5.2.2 The objects’ state vectors and covariance shall be given ‘at the time of closestapproach’, i.e., at the time specified in the TCA keyword.5.2.3 Table 3-4 is broken into four logical blocks, each of which has a descriptive heading.These descriptive headings shall not be included in a CDM, unless they appear in a properlyformatted COMMENT statement for the KVN implementation and with values between the and tags for the XML implementation.5.2.4 For C R •A/m, CR_AREA_OVER_MASS, a value of zero shall indicate no solarradiation pressure was taken into account in the orbit determination process.5.2.5 For C D •A/m, CD_AREA_OVER_MASS, a value of zero shall indicate no atmosphericdrag was taken into account in the orbit determination process.5.2.6 For acceleration due to in-track thrust, THRUST_ACCELERATION, a value of zeroshall indicate no in-track thrust acceleration was taken into account in the orbit determinationprocess.5.2.7 Values in the covariance matrix shall be presented sequentially from upper left [1,1]to lower right [9,9], lower triangular form, row by row, left to right. Variance and covariancevalues shall be expressed in standard double precision as related in 6.2.2.5.5.2.8 The covariance matrix is obligatory for the position and velocity terms, given in thelower triangular form of a 6x6 matrix. Optional terms for CD_AREA_OVER_MASS(denoted ‘DRG’), CR_AREA_OVER_MASS (denoted ‘SRP’), andTHRUST_ACCELERATION (denoted ‘THR’) should be added to the 6x6 matrix, in thelower triangular form, to complete a 9x9 matrix. If any element in any of these rows (7, 8, or9) is provided, then all of the elements for that row must be provided (i.e., a subset of theterms for any of these rows is not allowed).NOTE – The purpose for providing the 7, 8, and 9 terms is so that users, who have thepropagator model available, can correctly propagate the 6x6 position and velocitycovariance to another time point.CCSDS 508.0-R-1 Page 5-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6 CDM SYNTAX6.1 OVERVIEWThis section details the syntax requirements for the CDM using both KVN and XMLformats.6.2 THE CDM IN KVN6.2.1 CDM LINES IN KVN6.2.1.1 Each CDM file shall consist of a set of CDM lines. Each CDM line shall be one ofthe following:– Header line;– Relative Metadata/Data line;– Metadata line;– Data line; or– Blank line.6.2.1.2 Each CDM line must not exceed 254 ASCII characters and spaces (excluding linetermination character[s]).6.2.1.3 Only printable ASCII characters and blanks shall be used. Control characters (suchas TAB, etc.) shall not be used, with the exception of the line termination charactersspecified below.6.2.1.4 Blank lines may be used at any position within the file. Blank lines shall have noassignable meaning, and may be ignored.6.2.1.5 The first header line must be the first non-blank line in the file.6.2.1.6 All lines shall be terminated by a single Carriage Return or a single Line Feed, or aCarriage Return/Line Feed pair or a Line Feed/Carriage Return pair.6.2.1.7 All header, relative metadata/data, metadata, and data lines shall use ‘keyword =value’ notation. For this purpose, only those keywords shown in table 3-1, table 3-2,table 3-3, and table 3-4 shall be used in a CDM.6.2.1.8 Only a single ‘keyword = value’ assignment shall be made on a line.6.2.1.9 Keywords must be uppercase and must not contain blanks.CCSDS 508.0-R-1 Page 6-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6.2.1.10 Any white space immediately preceding or following the keyword shall not besignificant.6.2.1.11 Any white space immediately preceding or following the ‘equals’ sign shall not besignificant.6.2.1.12 Any white space immediately preceding the end of line shall not be significant.6.2.1.13 The order of occurrence of obligatory and optional KVN assignments shall be fixedas shown in the tables in section 3 that describe the CDM keywords.6.2.2 CDM VALUES IN KVN6.2.2.1 A nonempty value field must be specified for each obligatory keyword.6.2.2.2 Integer values shall consist of a sequence of decimal digits with an optional leadingsign (‘+’ or ‘-’). If the sign is omitted, ‘+’ shall be assumed. Leading zeroes may be used.The range of values that may be expressed as an integer is:-2,147,483,648

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESd) The exponent must be an integer, and may have either a ‘+’ or ‘-’ sign (if the sign isomitted, then ‘+’ shall be assumed).e) The maximum positive floating point value is approximately 1.798E+308, with 16significant decimal digits precision. The minimum positive floating point value isapproximately 4.94E-324, with 16 significant decimal digits precision.6.2.2.6 Text value fields must be constructed using only all uppercase or all lowercase.6.2.2.7 Blanks shall not be used within numeric values.6.2.2.8 Time strings must follow the formats specified in 6.2.2.11.6.2.2.9 In value fields that are text, an underscore shall be equivalent to a single blank.Individual blanks shall be retained (shall be significant), but multiple contiguous blanks shallbe equivalent to a single blank.6.2.2.10 All time tags in the CDM shall be in UTC.6.2.2.11 In value fields that represent a time tag, times shall be given in one of the followingtwo formats:yyyy-mm-ddThh:mm:ss[.d→d]oryyyy-dddThh:mm:ss[.d→d]where ‘yyyy’ is the year, ‘mm’ is the two-digit month, ‘dd’ is the two-digit day-of-month and‘ddd’ is the three-digit day of the year, separated by hyphens, ‘T’ is a fixed separatorbetween the date and time portions of the string, and ‘hh:mm:ss[.d→d]’ is the time in hours,minutes, seconds and fractional seconds, separated by colons. As many ‘d’ characters to theright of the period as required may be used to obtain the required precision, up to themaximum allowed for a fixed-point number. Because all times in the CDM are UTC, the ‘Z’indicator allowed by the CCSDS Time Codes Recommended Standard should be omitted. Allfields require leading zeros. (See reference [5], ASCII Time Code A or B.)6.2.2.12 In the value fields that represent TIME_LASTOB, the data type shall be either theexact time (see 6.2.2.11 for formatting rules) or an elapsed time, from the message creationtime, since the last observation used in the OD of the object. When the elapsed time option ischosen, the notation ‘’ shall be used.NOTE – The ‘’ means ‘greaterthan’, as in ‘> 12’, meaning ‘greater than twelve hours’.CCSDS 508.0-R-1 Page 6-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6.2.3 CDM UNITS IN KVN6.2.3.1 If units are applicable, as specified in table 3-2 and/or table 3-4, they must bedisplayed and must exactly match the units specified in table 3-2 and table 3-4 (includingcase). When units are displayed, then:a) there must be at least one blank character between the value and the units;b) the units must be enclosed within square brackets (e.g., ‘[km]’);c) multiplication of units shall be denoted with a single asterisk ‘*’ (e.g., ‘[kg*s]’);d) exponents of units shall be denoted with a double asterisk (i.e., ‘**’, for example,m/s 2 = m/s**2).6.2.3.2 The notation ‘[n/a]’ shall not appear in a CDM.NOTE – Some of the items in the applicable tables are dimensionless. For such items, thetable shows a unit value of ‘n/a’, which in this case means that there is noapplicable units designator for those items (e.g., forCOLLISION_PROBABILITY, WEIGHTED_RMS).6.2.4 CDM COMMENTS IN KVN6.2.4.1 For the CDM, comment lines shall be optional.6.2.4.2 All comment lines shall begin with the ‘COMMENT’ keyword followed by at leastone space. This keyword must appear on every comment line, not just the first such line. Theremainder of the line shall be the comment value. White space shall be retained (shall besignificant) in comment values.6.2.4.3 Placement of comments shall be as specified in the tables in section 3 that describethe CDM keywords.6.3 THE CDM IN XML6.3.1 CDM LINES IN XML6.3.1.1 Each CDM file shall consist of a set of CDM lines. Each CDM line shall be one ofthe following:– XML version line;– an XML-formatted data line; or– a blank line.CCSDS 508.0-R-1 Page 6-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6.3.1.2 Each CDM line must not exceed 254 ASCII characters and spaces (excluding linetermination character[s]).6.3.1.3 Only printable ASCII characters and blanks shall be used. Control characters (suchas TAB, etc.) shall not be used, with the exception of the line termination charactersspecified below.6.3.1.4 Blank lines may be used at any position within the file. Blank lines shall have noassignable meaning, and may be ignored.6.3.1.5 The first line in the instantiation shall specify the XML version.6.3.1.6 All lines shall be terminated by a single Carriage Return or a single Line Feed, or aCarriage Return/Line Feed pair or a Line Feed/Carriage Return pair.6.3.1.7 While specific formatting of an XML message is not critical, and white space andline breaks are not significant, the message should be organized and formatted to facilitatehuman comprehension.6.3.2 CDM VALUES IN XML6.3.2.1 Each obligatory XML tag must be present and contain a meaningful value.6.3.2.2 Integer values shall follow the conventions of the integer data type per reference [4].Additional restrictions on the allowable range or values permitted for any integer dataelement may also be defined in the CDM XML Schema.NOTE – Examples of such restrictions may include a defined range (e.g., 0 - 100, 1 - 10,etc.), a set of enumerated values (e.g., 0,1,2,4,8), a pre-defined specific variationsuch as positiveInteger, or a user-defined data type variation.6.3.2.3 Non-integer numeric values may be expressed in either fixed-point or floating-pointnotation. Numeric values shall follow the conventions of the double data type per reference [4].Additional restrictions on the allowable range or values permitted for any numeric dataelement may also be defined in the CDM XML Schema.NOTE – Examples of such restrictions may include a defined range (e.g., 0.0-100.0, etc.),or a user-defined data type variation.6.3.2.4 Text value data shall follow the conventions of the string data type per reference [4].Additional restrictions on the allowable range or values permitted for any data element mayalso be defined in the CDM XML Schema.NOTE – Examples of such restrictions may include a set of enumerated values (e.g.,‘YES’/‘NO’, or ‘RTN’/‘TVN’), or other user-defined data type variation.CCSDS 508.0-R-1 Page 6-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6.3.2.5 In value fields that represent a time tag in UTC, values shall follow the conventionsof the ndm:epochType data type used in all CCSDS NDM/XML schemas.NOTE – An example of this format:yyyy-mm-ddThh:mm:ss[.d→d]where ‘yyyy’ is the year, ‘mm’ is the two-digit month, ‘dd’ is the two-digit dayof-monthseparated by hyphens, ‘T’ is a fixed separator between the date andtime portions of the string, and ‘hh:mm:ss[.d→d]’ is the time in hours, minutes,seconds and fractional seconds separated by colons. As many ‘d’ characters tothe right of the period as required may be used to obtain the required precision,up to the maximum allowed for a fixed-point number. Because all times in theCDM are UTC, the ‘Z’ indicator allowed by the CCSDS Time CodesRecommended Standard should be omitted. All fields require leading zeros (see6.2.2.11).6.3.2.6 In the value fields that represent TIME_LASTOB, the data type shall be either theexact time (see 6.3.2.5 for formatting rules) or an elapsed time, from the message creationtime, of the last observation used in the OD of the object. When the elapsed time option ischosen, the notation ‘LT’, ‘-’, and ‘GT’ shall be used.NOTE – The ‘LT’ means ‘less than’ as in ‘less than six hours’. The ‘-’ means ‘to’ as in ‘6-12’, meaning ‘six to twelve hours’. The ‘GT’ means ‘greater than’ as in ‘greaterthan twelve hours’.6.3.3 CDM UNITS IN XMLMany of the CDM tags must have a units attribute. In all cases, the units shall match thosespecified in table 3-2 and table 3-4 (including case).NOTE – Table 6-1 gives examples of XML keyword tags with specified units.Table 6-1: Example XML Keyword Tags with Specified UnitsTag Units ExampleMISS_DISTANCE m 715RELATIVE_SPEED m/s 14762ACTUAL_OD_SPAN d 5.50MAXIMUM_OBS_GAP h 2.36.3.4 CDM COMMENTS IN XMLComments are optional and must be displayed as values between the and tags, which may be in any case desired by the user.CCSDS 508.0-R-1 Page 6-6 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES6.3.5 XML TEXT VALUESText values in XML instantiations (i.e., the values between the opening and closing tags),shall consist of all uppercase or all lowercase characters; an exception is made for valuesbetween the and tags, which may be in any case desired bythe user.CCSDS 508.0-R-1 Page 6-7 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX AABBREVIATIONS AND ACRONYMS(INFORMATIVE)ASCII American Standard Code for Information InterchangeCA Conjunction AssessmentCDM Conjunction Data MessageCCSDS Consultative Committee for Space Data SystemsDCA Dynamic Calibration of the AtmosphereEGM Earth Gravitational ModelEME2000 Earth Mean Equator and Equinox of J2000 (Julian Date 2000)FE Far from EarthGCRF Geocentric Celestial Reference FrameICD Interface Control DocumentITRF International Terrestrial Reference FrameKVN Keyword = Value NotationNDM Navigation Data MessageNE Near EarthOD Orbit DeterminationO/O Owner/OperatorOSA Orbital Safety AnalystRCS Radar Cross SectionRMS Root Mean SquareRTN Radial, Transverse and NormalSANA Space Assigned Numbers AuthoritySEDR Specific Energy Dissipation RateSIInternational System of UnitsTCA Time of Closest ApproachTVN Transverse, Velocity and NormalUTC Coordinated Universal TimeWGS World Geodetic SystemXML Extensible Markup LanguageCCSDS 508.0-R-1 Page A-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX BRATIONALE AND REQUIREMENTS FORCONJUNCTION DATA MESSAGES(INFORMATIVE)B1OVERVIEWThis annex presents the rationale behind the design of this message.A specification of requirements agreed to by all parties is essential to focus design and toensure the product meets the needs of the Member Agencies and satellite operators. Thereare many ways of organizing requirements, but the categorization of requirements is not asimportant as the agreement on a sufficiently comprehensive set. In this annex therequirements are organized into three categories:a) Primary Requirements: These are the most elementary and necessary requirements.They would exist no matter the context in which the CCSDS is operating, i.e.,regardless of pre-existing conditions within the CCSDS, its Member Agencies, orother independent users.b) Heritage Requirements: These are additional requirements that derive from preexistingMember Agency or other independent user requirements, conditions, orneeds. Ultimately these carry the same weight as the Primary Requirements. ThisRecommended Standard reflects heritage requirements pertaining to some of theCCSDS Areas’ home institutions collected during the preparation of the document; itdoes not speculate on heritage requirements that could arise from other sources.Corrections and/or additions to these requirements are expected during futureupdates.c) Desirable Characteristics: These are not requirements, but they are felt to beimportant or useful features of the Recommended Standard.CCSDS 508.0-R-1 Page B-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESB2PRIMARY REQUIREMENTS ACCEPTED BY THE CDMTable B-1: Primary RequirementsReqt # Requirement Rationale TraceCDM-P01CDM-P02CDM-P03CDM-P04CDM-P05CDM-P06The CDM data shall be provided indigital form (computer file).The CDM shall be provided in datastructures (e.g., files) that are readilyported between, and useable within,‘all’ computing environments in useby Member Agencies.The CDM shall be provided usingfile name syntax and length that donot violate computer constraints forthose computing environments inuse by Member Agencies.The CDM shall provide amechanism by which messages maybe uniquely identified and clearlyannotated. The file name alone isconsidered insufficient for thispurpose.The CDM shall clearly andunambiguously identify the twoobjects involved in a conjunction.The CDM shall provide the time ofclosest approach of the two objectsinvolved in the conjunction.CDM-P07 The CDM shall provide timemeasurements (time stamps, orepochs) in commonly used, clearlyspecified systems.CDM-P08CDM-P09The CDM shall provide the states ofthe two objects involved in theconjunction at the time of closestapproach.The CDM shall provide the missdistance of the two objects involvedin the conjunction at the time ofclosest approach.Facilitates computerized processingof CDMs.The CCSDS objective of promotinginteroperability is not met if messagesare produced using esoteric orproprietary data structures.The CCSDS objective of promotinginteroperability is not met if messagesare provided using nonstandard filenamesyntax or length.Facilitates discussion between amessage recipient and the originatorshould it become necessary.This information is fundamental to theoperator(s) of the objects in theconjunction. Cited as required in ISO16158 (reference [D2]).This datum is required in order todetermine remaining reaction time, toassess the risk of collision, and toassess potential preventivemeasures. Cited as required in ISO16158 (reference [D2]).The CCSDS objective of promotinginteroperability is not met if timemeasurements are produced inesoteric or proprietary time systems.The states at time of closestapproach are required for calculationof collision probability in mostmethods. This information is usefulto operators who wish to perform anindependent assessment of theconjunction and/or the probability ofcollision. Cited as desirable in ISO16158 (reference [D2]).This datum is required in order toassess the risk of collision andassess potential preventivemeasures. Cited as required in ISO16158 (reference [D2]).3.1.1, 3.1.23.1.23.1.3Table 3-1Table 3-3Table 3-26.2.2.11, 6.3.2.5,Table 3-2Table 3-4Table 3-2CCSDS 508.0-R-1 Page B-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESReqt # Requirement Rationale TraceCDM-P10CDM-P11CDM-P12CDM-P13CDM-P14CDM-P15CDM-P16The CDM shall provide state vectorinformation for both objects involvedin the conjunction in a referenceframe that is clearly identified andunambiguous.The CDM shall provide for clearspecification of units of measure.The CDM shall provide a covariancematrix that includes at least 6x6position/velocity uncertaintyinformation.The CDM shall provide the mostrecently known operational status ofthe two objects.The CDM shall allow the possibilityto exchange information regardingconjunctions of objects orbiting anarbitrary body or point in space.The CDM shall provide data and/ormetadata that will allow the recipientto calculate the probability ofcollision if it is not provided by theCDM originator.The CDM must not require of thereceiving exchange partner theseparate application of, or modelingof, spacecraft dynamics orgravitational force models, orintegration or propagation.Clearly understanding the frame ofreference in which measurements areprovided is fundamental to theanalysis of most, if not all, physicalprocesses.Without clear specification of units ofmeasure, mistakes can be made thatinvolve the unit system in effect (e.g.,Metric or Imperial) and/or orders ofmagnitude (e.g., meters orkilometers).The determination of a satellite stateis subject to measurement andprocess uncertainties at all phases ofits development. Consideration ofthis uncertainty is a necessary part ofconjunction analysis and riskassessment. The covariance matrixcaptures the requisite uncertainty.Cited as required in ISO 16158(reference [D2]).This datum is required in order toassess the risk of collision andassess potential preventivemeasures. Cited as required in ISO16158 (reference [D2]).While Earth is the most likely objectabout which orbiting objects maycollide, there are other orbit centerswith more than one orbiting object(e.g., the Moon, Mars, Earth/Sun L1,Earth/Sun L2).Some CDM originators will not wantto explicitly provide a probability ofcollision, but their customers may beinterested in performing a calculationof their own based on data in theCDM.The situation in which a CDM isprovided may not allow time forchecking/confirming a predictedconjunction by a recipient. Someoperators may not be able to performthe required computations.3.4, Table 3-3,Table 3-4,4.3.10, 6.2.3,6.3.3Table 3-4Table 3-3Table 3-2Table 3-2,Table 3-3, Table3-4Table 3-2,Table 3-3, Table3-4CCSDS 508.0-R-1 Page B-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESTable B-2: Heritage RequirementsID Requirement Rationale TraceCDM-H01The CDM shall be provided in, orshall include, an ASCII format.ASCII character-based messagespromote interoperability. ASCIImessages are useful in transferringdata between heterogeneouscomputing systems, because theASCII character set is nearlyuniversally used and is interpretableby all popular systems. In addition,direct human-readable dumps of textto displays, emails, documents orprinters are possible withoutpreprocessing.3.1, 4.2CDM-H02The CDM shall not require softwaresupplied by other Agencies.This principle was agreed upon earlyin the history of the CCSDS NavigationWorking Group.n/aTable B-3: Desirable CharacteristicsID Requirement Rationale TraceCDM-D01CDM-D02CDM-D03CDM-D04CDM-D05The CDM should be extensible withno disruption to existing users/uses.The CDM should be as consistentas reasonable with any relatedCCSDS Recommended Standardsused for earth-to-spacecraft orspacecraft-to-spacecraftapplications.CDM originators should maintainconsistency with respect to theoptional keywords provided in theirimplementations; i.e., thecomposition of the CDMs providedshould not change on a frequentbasis.The CDM should allow the option fororiginators to provide a probability ofcollision of the two objects involvedin the conjunction.The CDM should provide informationwith which each object’s sphericalradius may be calculated.Space agencies and operatorsupgrade systems and processes onschedules that make sense for theirorganizations. In practice, someorganizations will be early adoptersbut others will opt to wait untilperformance of a new version of theCDM has been proven in otheroperations facilities.Ideally, the set of RecommendedStandards developed by a givenCCSDS Working Group will beconsistent.Implementations that change on afrequent basis do not promote stableoperations or interoperability.Some CDM originators will beinterested in providing this datum.Cited as desirable by ISO 16158(reference [D2]).The object radius is required forcalculation of collision probability inmost methods, which usually modelobjects as spheres given the lack ofattitude information.Table 3-1n/an/aTable 3-2Table 3-4CCSDS 508.0-R-1 Page B-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESID Requirement Rationale TraceCDM-D06CDM-D07CDM-D08The CDM should provide thethreshold of close approach used bythe originator in the screening.The CDM should provide thecomponents of the relative positionat the time of closest approach.The CDM should provide the relativevelocity of the two objects in theconjunction at the time of closestapproach.This datum is desirable in order toassess the risk of collision andassess potential preventivemeasures. Cited as desirable by ISO16158 (reference [D2]).These data allow an operator toquickly do a first-order qualitativeassessment of the probability ofcollision immediately upon receipt ofa CDM.This datum is desirable in order toassess the risk of collision andassess potential preventivemeasures. Called out as desirable byISO 16158 (reference [D2]).Table 3-2Table 3-2Table 3-2CCSDS 508.0-R-1 Page B-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX CCONJUNCTION INFORMATION DESCRIPTION(INFORMATIVE)C1RELATIVE DATATCA (Time of Closest Approach): The date and time of the predicted conjunction. Thistime tag is also the epoch of the relative state vector, Object1 and Object2 state vectors, aswell as the effective time of the covariance matrices for both Object1 and Object2.COLLISION_PROBABILITY: The probability that Object1 and Object2 will collide.COLLISION_PROBABILITY_METHOD: The method used to compute the valueassociated with the COLLISION_PROBABILITY keyword. Options are ‘FOSTER-1992’(see reference [D4]), ‘CHAN-1997’ (see reference [D8]), ‘PATERA-2001’ (see reference[D6]), ‘ALFANO-2005’ (see reference [D7]), or ‘OTHER’. If ‘OTHER’ is specified, a fullreference should be provided in CDM comments.MISS_DISTANCE: How close the two objects are going to be based upon the conjunctionassessment screening results.RELATIVE_SPEED: How fast the two objects are moving relative to each other at thetime of the predicted encounter.RELATIVE_POSITION/RELATIVE_VELOCITY: Object2’s position/velocity relativeto Object1’s position/velocity, calculated by taking the difference of the position and velocityvectors relative to the frame in which they are defined, with components expressed in theObject1-centered RTN coordinate frame at the time of closest approach.RTN Coordinate Frame: Object-centered coordinate system. The Object1-centered RTNcoordinate frame: R (Radial) is the unit vector in the radial direction, N (Normal) is the unitvector normal to the satellite’s inertial orbit plane (in the direction of the satellite’s angularmomentum), and T (Transverse) is the unit vector that completes the right-hand coordinateframe (see figure C-1).TVN Coordinate Frame: Object-centered coordinate system. The Object1-centered TVNcoordinate frame is defined as: V (Velocity) is the unit vector in the velocity direction, N(Normal) is the unit vector normal to the satellite’s inertial orbit plane (in the direction of thesatellite’s angular momentum), and T (Transverse) is the unit vector that completes the righthandcoordinate frame (see figure C-1).CCSDS 508.0-R-1 Page C-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCommonality Between RTN and TVNThe primary difference between the RTN and the TVN frames is that the RTN frame isanchored on the unit radial vector R, and the TVN frame is anchored on the unit velocityvector V. The unit normal vector N is the same vector for both the RTN and TVN frames.The unit transverse vector T completes the right-hand coordinate frame for both the RTN andTVN frames, but is not in the same direction for both frames. The TVN frame can beparticularly useful for analyzing elliptical orbits where the user would like one coordinateaxis to align with the velocity direction of motion. The RTN and TVN frames are the samewhen Object1 is at apoapsis, periapsis, or when its orbit is perfectly circular. Transformationsfrom EME2000, GCRF or ITRF to RTN or TVN should always use inertial velocities in thetransformation.NGeocentricRadius Vectorof VehicleDirection ofMotionNTObject1OrbitalPlaneVRTFigure C-1: Definition of the RTN and TVN Coordinate FramesSCREEN_VOLUME_SHAPE/SCREEN_VOLUME: Shape (ellipsoid or box) of thescreening volume used to screen the satellite catalog for possible conjunctors with Object1.The screening volume is the component size of the screening volume shape (in the Object1centered RTN or TVN reference frame).C2METADATAADDITIONAL_TRACKING: Information concerning whether additional sensor trackinghas been applied to the orbit determination of the object. Once a potential conjunction hasbeen determined, it is common practice to then use additional sensor resources wherepossible, beyond what is normally used, to better define the object’s orbit.CCSDS 508.0-R-1 Page C-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESC3ORBIT DETERMINATION PARAMETERSObservation: Unique measurement of a satellite’s location from a single sensor at a singletime (e.g., azimuth from a single sensor at a single time).TIME_LASTOB: Information about the time of the last accepted observation that was usedin the creation of the object’s state vector. It can be entered as an exact time or an elapsedtime, from the message creation time, that includes the time of the last good observation thatwas used in the creation of the object’s state vector. The rules for the latter case are definedbelow for Near Earth (NE) and Far From Earth (FE) objects (FE is defined as any object witha period greater than 225 minutes):– for all NE objects:• 12 hours from message creation time;– for all FE objects:• 48 hours from message creation time.RECOMMENDED_OD_SPAN: How many days of observations were recommended forthe orbit determination (OD) of the object.ACTUAL_OD_SPAN: The actual time span used for the OD of the object based on theobservations available and the RECOMMENDED_OD_SPAN.OBS_AVAILABLE: The number of observations, for the recommended time span, thatwere available for the OD.OBS_USED: The number of observations, for the recommended time span, that wereaccepted for the OD.Sensor Track: A set of at least three observations for the same object, observed by the samesensor, where each observation is within a specified number of minutes (which is dependenton the orbit regime of the object) of the other observations in the track.TRACKS_AVAILABLE: The number of sensor tracks, for the recommended time span,that were available for the OD. This provides information about the independence of theobservational data used in the OD.CCSDS 508.0-R-1 Page C-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESTRACKS_USED: The number of sensor tracks, for the recommended time span, that wereaccepted for the OD. This provides information about the independence of the observationaldata used in the OD.MAXIMUM_OBS_GAP: The maximum time between observations in the OD of the object.WEIGHTED_RMS:WhereWeighted RMS Ni1y i is the observation measurement at the ith time;yˆiis the current estimate of y i ; ˆ 2w y yi i i1wi is the weight (sigma) associated with the measurement at the ith time; and2iNN is the number of observations.This is a value that can generally identify the quality of the most recent vector update, and isused by the analyst in evaluating the OD process. A value of 1.00 is ideal.C4MODEL PARAMETERSGRAVITY_MODEL: The geopotential model used in the state vector update. The degree(D) and order (O) of the spherical harmonic coefficients applied should be given along withthe name of the model.ATMOSPHERIC_MODEL: The atmospheric drag model used in the state vector update.N_BODY_PERTURBATIONS: Which (if any) N-body gravitational perturbations wereincluded in the state vector update. The value is a comma-separated list of the body names.SOLAR_RAD_PRESSURE: Whether perturbations due to solar radiation pressure wereincluded in the state vector update.EARTH_TIDES: Whether perturbations due to solid earth and ocean tides were included inthe state vector update.CCSDS 508.0-R-1 Page C-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESC5ADDITIONAL PARAMETERSAREA: The area of the object (m**2). The area could be defined by using a Radar CrossSection (RCS).CD_AREA_OVER_MASS: The perturbation of the object due to atmospheric drag(m**2/kg) used to propagate the state vector and covariance to TCA. Defined as C D •A/m,where C D is the drag coefficient, A is the area of the object, and m is the mass of the object.CR_AREA_OVER_MASS: The perturbation of the object due to solar radiation pressure(m**2/kg) used to propagate the state vector and covariance to TCA. Defined as C R •A/m,where C R is the solar radiation pressure coefficient, A is the area of the object and m is the massof the object.THRUST_ACCELERATION: The object’s acceleration due to in-track thrust (m/s**2)used to propagate the state vector and covariance of the object to TCA.SEDR (Specific Energy Dissipation Rate): The amount of energy (W/kg) being removedfrom a satellite’s orbit by atmospheric drag. It is a very useful metric for characterizingsatellites since it takes into account both the drag environment (atmospheric density) and the‘area to mass ratio’ of the specific object. It does this by including drag acceleration in thecomputation. Drag acceleration is proportional to atmospheric density and to satellite area tomass.SEDR is computed as follows:Instantaneous SEDR at time t is given by SEDR(t) A D Vwhere, = drag acceleration vector (inertial)ADV = velocity vector (inertial)Average SEDR over the orbit determination interval is given byt1SEDR(t)dtT 0where,CCSDS 508.0-R-1 Page C-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESin order to correctly average over a complete orbital revolution, T is an integer multiple ofthe satellite period. This consideration is primarily for eccentric orbits. Aside from thisconsideration, T is the orbit determination interval.C6COVARIANCE MATRIXThe covariance matrix is obligatory for the position and velocity terms, given in the lowertriangular form of a 6x6 matrix. Optional terms for CD_AREA_OVER_MASS (denoted‘DRG’), CR_AREA_OVER_MASS (denoted ‘SRP’), and THRUST_ACCELERATION(denoted ‘THR’) should be added to the 6x6 matrix, in the lower triangular form, to completea 9x9 matrix. If any element in any of these rows (7, 8, or 9) is provided, then all of theelements for that row must be provided (i.e., a subset of the terms for any of these rows is notallowed). The purpose for providing the 7, 8, and 9 terms is so that users, who have thepropagator model available, can correctly propagate the 6x6 position and velocity covarianceto another time point.CCSDS 508.0-R-1 Page C-6 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX DINFORMATIVE REFERENCES(INFORMATIVE)[D1] Navigation Data—Definitions and Conventions. Report Concerning Space DataSystem Standards, CCSDS 500.0-G-3. Green Book. Issue 3. Washington, D.C.:CCSDS, May 2010.[D2] Space Systems—Avoiding Collisions with Orbiting Objects. ISO/AWI 16158. Geneva:ISO, 2009.[D3] Astrodynamics—Propagation Specifications, Technical Definitions, and RecommendedPractices. ANSI/AIAA S-131-2010. Reston, Virginia: AIAA, 2010.[D4] J. L. Foster and H. S. Estes. A Parametric Analysis of Orbital Debris CollisionProbability and Maneuver Rate for Space Vehicles. NASA/JSC-25898. Houston,Texas: NASA Johnson Space Flight Center, August 1992.[D5] Ken Chan. “Collision Probability Analyses for Earth Orbiting Satellites.” In SpaceCooperation into the 21st Century: 7th AAS/JRS/CSA Symposium, International SpaceConference of Pacific-Basin Societies (ISCOPS; formerly PISSTA) (July 15-18, 1997,Nagasaki, Japan), edited by Peter M. Bainum, et al., 1033-1050. Advances in theAstronautical Sciences Series 96. San Diego, California: Univelt, 1997.[D6] Russell P. Patera. “General Method for Calculating Satellite Collision Probability.”Journal of Guidance, Control, and Dynamics 24, no. 4 (July–August 2001): 716-722.[D7] Salvatore Alfanol. “A Numerical Implementation of Spherical Object CollisionProbability.” The Journal of the Astronautical Sciences 53, no. 1 (January-March2005): 103-109.[D8] Salvatore Alfano. “Review of Conjunction Probability Methods for Short-TermEncounters.” In Proceedings of the 17th AAS/AIAA Space Flight Mechanics Meeting(January 28 - February 1, 2007, Sedona, Arizona), edited by Maruthi R. Akella, et al.,719-747. Advances in the Astronautical Sciences Series 127. San Diego, California:Univelt, 2007.[D9] K. Alfriend, et al. “Probability of Collision Error Analysis.” Space Debris 1, no. 1(1999): 21-35.CCSDS 508.0-R-1 Page D-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX ESECURITY, SANA, AND PATENT CONSIDERATIONS(INFORMATIVE)E1SECURITY CONSIDERATIONSE1.1 ANALYSIS OF SECURITY CONSIDERATIONSThis subsection presents the results of an analysis of security considerations applied to thetechnologies specified in this Recommended Standard.E1.2 CONSEQUENCES OF NOT APPLYING SECURITY TO THETECHNOLOGYThe consequences of not applying security to the systems and networks on which thisRecommended Standard is implemented could include potential loss, corruption, and theft ofdata. Because these messages are used in collision avoidance analyses and potentialmaneuvers, the consequences of not applying security to the systems and networks on whichthis Recommended Standard is implemented could include compromise or loss of themission if malicious tampering of a particularly severe nature occurs.E1.3 POTENTIAL THREATS AND ATTACK SCENARIOSPotential threats or attack scenarios include, but are not limited to, (a) unauthorized access tothe programs/processes that generate and interpret the messages, and (b) unauthorized accessto the messages during transmission between exchange partners. Protection fromunauthorized access during transmission is especially important if the mission utilizes openground networks such as the Internet to provide ground-station connectivity for the exchangeof data formatted in compliance with this Recommended Standard. It is stronglyrecommended that potential threats or attack scenarios applicable to the systems andnetworks on which this Recommended Standard is implemented be addressed by themanagement of those systems and networks.E1.4 DATA PRIVACYPrivacy of data formatted in compliance with the specifications of this RecommendedStandard should be assured by the systems and networks on which this RecommendedStandard is implemented.CCSDS 508.0-R-1 Page E-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESE1.5 DATA INTEGRITYIntegrity of data formatted in compliance with the specifications of this RecommendedStandard should be assured by the systems and networks on which this RecommendedStandard is implemented.E1.6 AUTHENTICATION OF COMMUNICATING ENTITIESAuthentication of communicating entities involved in the transport of data which complieswith the specifications of this Recommended Standard should be provided by the systemsand networks on which this Recommended Standard is implemented.E1.7 DATA TRANSFER BETWEEN COMMUNICATING ENTITIESThe transfer of data formatted in compliance with this Recommended Standard betweencommunicating entities should be accomplished via secure mechanisms approved by theInformation Technology Security functionaries of exchange participants.E1.8 CONTROL OF ACCESS TO RESOURCESControl of access to resources should be managed by the systems upon which originatorformatting and recipient processing are performed.E1.9 AUDITING OF RESOURCE USAGEAuditing of resource usage should be handled by the management of systems and networkson which this Recommended Standard is implemented.E1.10 UNAUTHORIZED ACCESSUnauthorized access to the programs/processes that generate and interpret the messagesshould be prohibited in order to minimize potential threats and attack scenarios.E1.11 DATA SECURITY IMPLEMENTATION SPECIFICSSpecific information-security interoperability provisions that may apply between agenciesand other independent users involved in an exchange of data formatted in compliance withthis Recommended Standard should be specified in an ICD.CCSDS 508.0-R-1 Page E-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESE2SANA CONSIDERATIONSThe CDM XML schema and a transform to the CDM KVN version will be registered withthe SANA Operator.E3PATENT CONSIDERATIONSThe recommendations of this document have no patent issues.CCSDS 508.0-R-1 Page E-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX FCDM XML SCHEMA DEFINITION(INFORMATIVE)CCSDS 508.0-R-1 Page F-1 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGES CCSDS 508.0-R-1 Page F-6 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-7 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-8 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCCSDS 508.0-R-1 Page F-9 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESANNEX GCDM XML-TO-KVN TRANSLATOR—XLST IMPLEMENTATION(INFORMATIVE)select="@version"/>=

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESRELATIVE_POSITION_R= RELATIVE_POSITION_T= RELATIVE_POSITION_N= RELATIVE_VELOCITY_R= RELATIVE_VELOCITY_T= RELATIVE_VELOCITY_N= ORBIT_CENTER= START_SCREEN_PERIOD= STOP_SCREEN_PERIOD= SCREEN_VOLUME_FRAME= SCREEN_VOLUME_SHAPE= SCREEN_VOLUME_X= SCREEN_VOLUME_Y= SCREEN_VOLUME_Z= ENTRY_TIME= EXIT_TIME= COLLISION_PROBABILITY= CCSDS 508.0-R-1 Page G-2 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESCOLLISION_PROBABILITY_METHOD= COMMENT OBJECT= OBJECT_NUMBER= SAT_CATALOG= OBJECT_NAME= OBJECT_ID= OBJECT_TYPE= OPERATOR_CONTACT_POSITION= OPERATOR_ORGANIZATION= OPERATOR_PHONE= OPERATOR_EMAIL= EPHEMERIS_NAME= NUMBER_SENSORS= TRACKING_DATA_TYPES= ADDITIONAL_TRACKING= COVARIANCE_METHOD= MANEUVERABLE= CCSDS 508.0-R-1 Page G-3 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESMAN_INCLUDED= REF_FRAME= GRAVITY_MODEL= ATMOSPHERIC_MODEL= N_BODY_PERTUBATIONS= SOLAR_RAD_PRESSURE= EARTH_TIDES= INTRACK_THRUST= COMMENT COMMENT TIME_LASTOB= RECOMMENDED_OD_SPAN= ACTUAL_OD_SPAN= MAXIMUM_OBS_GAP= OBS_AVAILABLE= OBS_USED= TRACKS_AVAILABLE= CCSDS 508.0-R-1 Page G-4 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESTRACKS_USED= WEIGHTED_RMS= TIME_NEXT_UPDATE= COMMENT AREA= MASS= CD_AREA_OVER_MASS= CR_AREA_OVER_MASS= THRUST_ACCELERATION= SEDR= COMMENT X= Y= Z= X_DOT= Y_DOT= CCSDS 508.0-R-1 Page G-5 March 2012

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESZ_DOT= COMMENT CR_R= CT_R= CT_T= CN_R= CN_T= CN_N= CRDOT_R= CRDOT_T= CRDOT_N= CRDOT_RDOT= CTDOT_R= CTDOT_T= CTDOT_N= CTDOT_RDOT=

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESmatch="ndm:segment/ndm:data/ndm:covarianceMatrix/ndm:CTDOT_TDOT">CTDOT_TDOT= CNDOT_R= CNDOT_T= CNDOT_N= CNDOT_RDOT= CNDOT_TDOT= CNDOT_NDOT= CDRG_R= CDRG_T= CDRG_N= CDRG_RDOT= CDRG_TDOT= CDRG_NDOT= CDRG_DRG= CSRP_R=

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESmatch="ndm:segment/ndm:data/ndm:covarianceMatrix/ndm:CSRP_T">CSRP_T= CSRP_N= CSRP_RDOT= CSRP_TDOT= CSRP_NDOT= CSRP_DRG= CSRP_SRP= CTHR_R= CTHR_T= CTHR_N= CTHR_RDOT= CTHR_TDOT= CTHR_NDOT= CTHR_DRG= CTHR_SRP=

DRAFT CCSDS RECOMMENDED STANDARD FOR CONJUNCTION DATA MESSAGESmatch="ndm:segment/ndm:data/ndm:covarianceMatrix/ndm:CTHR_THR">CTHR_THR= CCSDS 508.0-R-1 Page G-9 March 2012