| Systems Engineering Area (SEA) |
Title of Group | 1.01 System Architecture Working Group |
Chairperson | Peter Shames |
Chairperson E-Mail Address | |
Chairperson Agency | NASA/JPL |
Deputy Chairperson | TBD |
Deputy E-Mail Address | |
Deputy Agency | TBD |
Mailing List | |
Scope of Activity
Prioritized List of Projects
CCSDS Reference Architecture
- Approach: Developed as a pair of documents using the RASDS reference architecture methodology. The lower layers (1-4, and some 7) are covered by the SCCS-ARD/ADD, and include the standards developed by the CSS, SLS, SIS, and SEA Areas. The upper layers (5-7 and applications) are covered by the ASL-ADD, and include the standards developed by the MOIMS and SOIS Areas.
- Describe how all of the CCSDS application standards fit together with other communications standards, the map of the territory
- Define and refine necessary interfaces and ontology terms
- Update and revise these documents, as needed, with direct support from CSS, SLS, SIS, SEA, SOIS, and MOIMS area expert.
CCSDS Registries & Information Model
Approach: Support CCSDS registries and information models, develop a unified approach across all CCSDS working groups
- Registry Management Policy (RMP) document derived from existing SCID and MACAO registries. Provide updated WG guidelines and SANA Operator guidelines.
- Extend registry model to define core, re-usable, registries for agencies & other organizations, identified persons (head of delegation / points of contact), assigned registry management role.
- Develop other core registries for object identifiers (OID), URN, Schema, service sites & apertures, as needed.
- CCSDS wide registry information model covering all of the major defined info / data objects and their relationships
-Reference Architecture for Space Information Management (RASIM) document that encompasses the capture, management, access, and exchange of data for both flight and ground systems
Perform RASDS refresh, include Annex for SysML/UML representation
Approach: Update and refresh RASDS
- Work with ISO SC-14 to define needs for operational, physical, and service viewpoints
- Refine existing viewpoint specifications based on user experience and feedback, as well as ASL ADD developed extensions
- Include Annex for UML/SysML representation that uses the core methodology, consider Annex to describe abstraction, protocol, concrete realization relationships
- Complete RASDS revision and update now that resources are available
CCSDS XML standards
Approach: Identify source of adequate XML schema development guidelines, develop draft for CCSDS and review with CESG
- Adopt suite of schema analysis and validation tools
- Extract set(s) of common terms as library elements
CCSDS ontology (terms, definition, and relationships; glossary revision)
Approach: Complete analysis, work key issues within WG as part of CCSDS Reference Architecture
- Based on existing CCSDS Glossary, with refinements
- Deploy On-line; queryable, leverages RASDS & QUDV as core
- Extensible with other domain ontologies, specializations and extensions
- Revised and reviewed with the other WGs - Work integration of TC20 / SC14 terminology and develop a more formalized governance approach with their support
Rationale for ActivityThe CMC has been requesting a "CCSDS Reference Architecture" for some time, motivated by the presence of the SCCS-ARD and ADD, which covers the CSS, SLS, SIS, and SEA areas, and the lack of any comparable vision for SOIS, MOIMS, and how they relate to each other or to the rest of CCSDS.
Over time CCSDS has created a large set of registries in the SANA, but it has no policy for dealing with common registries nor even for re-use of existing registries. The current approach has created a "wild west" approach where new registries that actually overlap existing ones are proposed without checking or any attempt at alignment.
The RASDS is due for a refresh in satisfaction of the CCSDS 5 year review policy. It is also time for a refresh and expansion of content, to add new viewpoints (services, operations, and physical) and to adopt more modern use of SysML representations, at least in an annex, even if the current PPT "cartoon" style is retained.
As a part of analysis of the reference architecture and RASDS projects, and after studying the current CCSDS Glossary, it has become clear that our set of terminology is in need of a clean up and normalization. There are a number of overlaps and disconnects. The Ontology task will do this work and coordinate it with the affected working groups.
Related to all of this, one of the key kinds of information artifacts that CCSDS produces today are XML schema. These have grown over the years, but without any overall information model or XML guidelines they are in something of a state of disarray. Because they use different styles and different terminology the ability to re-use them effectively is limited. This project is to provide a set of guidelines and, over time, to work with the affected WGs to bring current spec in line. This is being added to this WG because the work needs a home and the XML SIG, which was created to deal with the issue, has no resources to actually do the job.
GoalsGoals:
- Develop useful reference architecture for CCSDS
- Develop a CCSDS Registry Management Policy and commonly used set of core registries
- Develop a CCSDS information model that described the major data objects and their relationships,br /> - Update the RASDS to include additional viewpoints and newer MBSE representations
- Turn the current "mare's nest" of a Glossary into a well-formed ontology for CCSDS along with a process for keeping it up to date
- Develop a set of XML guidelines and reform the existing XML specs to make them more usable
- Refine the RASIM to include cloud and containerization, role of ontologies, machine learning (ML), Artificial Intelligence (AI), and security aspects
Survey of Similar Work Undertaken in Other BodiesThe work proposed here leverages earlier work in the SEA SAWG and also work done in the CSS CSA WG and elsewhere in CCSDS. It builds upon work done in the SCCS-ARD & ADD , work done in the ASL-ADD & and also earlier work done in SOIS and in the creation of the SOIS / MOIMS MOU. To the extent that this reference architecture is unique to CCSDS there is nothing that can be directly leveraged from other organizations.
The RASDS work already leverages work done in RM-ODP (a set of ISO specs) and it is also compliant with ISO 42010 and IEEE 1471. The RASDS framework has been adopted by ISO TC 20 / SC 14 systems engineering and a liaison relationship has been established so that they may collaborate with us on this work since they would value the addition of the operations and physical viewpoints for their own work. The proposed SysML extensions leverage work done in the OMG, which now supports viewpoints, and also work done in several NASA tasks that have explored use of SysML in this context.
The XML guidelines are expected to leverage similar work done in ESA and also by Google, as well as other organizations. The use of XML is not unique to space nor CCSDS, but we do need a set of guidelines that will work in our context of interoperable and re-usable standards.
The glossary work will leverage efforts that are underway in the Ontology community as well as various efforts elsewhere in CCSDS (SOIS DoT) and in various agencies. This will utilize tools like Protege, SPARQL, and others that are in wide use in the ontology community. The ontology contents, however, must largely be derived from CCSDS itself, with the addition of conceptual frameworks like QUDV and SysML.
The Registry Management Policies are to be aligned with and derived from the approaches used in the existing SCID and MACAO standards. They are a superset of that work and formalize, extend, and integrate their organization and person registries to support the registry information needed by other areas.
The information model draws from all of the information object and data object work done in the CCSDS working groups, but brings it together in a consistent way so that the relationships may be better understood. Patent Licensing Applicability for Future Standards
<div>None of this work is licensed or has patent issues.</div> Technical Risk Mitigation StrategyThere are no known technical risks, the technology is quite well understood. Management Risk Mitigation StrategyThe biggest risks are lack of suitable and sustained resources to get this work done in a timely fashion. The risk mitigation is to use the proposed plan that separates these different tasks and that phases them where possible. |
| Systems Engineering Area (SEA) |
Title of Group | 1.02 Security Working Group |
Chairperson | Howard Weiss |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Marcus Wallum |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityThe CCSDS Security Working Group develops security guidance, security standards, and provides advice & guidance to other CCSDS working groups. Rationale for ActivityCCSDS develops communications and mission operation standards that support inter and intra agency operations and cross support. CCSDS standards include elements of flight and ground systems that are developed and operated by different agencies and organizations.
Given that ubiquitous network connectivity among principal investigators and mission operations has become the norm, mission operations have become more exposed than in the past when operations were carried out over closed, mission-only networks. Furthermore, the threat of sophisticated cyber attacks has increased over recent years and will continue to increase. Thus, the security risks to both spacecraft and ground systems have increased to the point where CCSDS must introduce Information Security standards, either by adopting existing standards or developing (as necessary) them in order to protect both flight and ground mission critical resources and protect sensitive mission information and selected communication protocol data fields.
Mission planners must perform mission security threat analyses to better understand threats that they should plan to counter via security requirements. Mission planners must also design security into their systems from the outset to balance security with mission ensure requirements. CCSDS must promote secure interoperability for mission resources. CCSDS also requires Information Security standards as part of, or as an accompaniment to its communications and mission operations standards.
In order to help the mission planner successfully design-in security the CCSDS Security Working Group will provide “tools” such as security standards, guides, and architectures which must be identified, defined, maintained, and updated to ensure relevance with current threats identified by CCSDS as well as other sources.
GoalsThe goals of the Security Working Group are to:
1) provide advice and guidance on information security to all CCSDS activities, working groups, and the general space community;
2) identify information security issues across the full spectrum of CCSDS activities and provide solutions;
3) adopt or develop (as necessary) interoperable security standards for CCSDS and CCSDS cross support infrastructure (e.g., authentication, encryption, integrity, key management, key distribution);
4) formulate courses of actions to incorporate security policies, security services, and security mechanisms into CCSDS work items across all Working Groups;
5) hold working meetings with other Working Groups to develop agreed approaches and formulate the plans for integrating them into the work of these other Working Groups
The Security Working Group shall develop, revise, and maintain guides (Green Books), best practice documents (Magenta Books), and recommendations (Blue Books) such as:
1) an information security guide for mission planners;
2) a policy framework for developing trust agreements, rules for operational engagement, ensuring security compliance of legacy systems, and standard, secure interfaces between systems and across security domains;
3) a CCSDS security architecture;
4) an Information Security threat statement for CCSDS which is periodically reviewed in order to remain relevant with the evolving threat environment against space missions;
5) an integration of relevant existing and arising standards into the development of mission security requirements and other documents;
6) key management guide and recommendations;
7) a description of guidelines for secure development, implementation, and testing;
8) a guide to standardized cryptographic algorithms and the particulars of their application to space mission security;
9) an adaptation profile for the use of IPsec to provide network layer security for CCSDS missions
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
<div> There are no known or potential patent license that would be required for users to implement standards from this group.
<br> </div> Technical Risk Mitigation StrategySecurity is a key part of rigorous systems engineering. In the past, it has been met with resistance in CCSDS. However, there is now general acceptance of the need for security services even for civilian space missions and, as a result interactions with other working groups are increasing. Working group resources have increased and need to remain at their current level.
Management Risk Mitigation StrategyUnavailability of resources will delay achievement of milestones. Fallback option would be to reschedule the milestones.
Identification of specific security guidelines may result in additional work items being agreed upon with other working groups.
|
| Systems Engineering Area (SEA) |
Title of Group | 1.06 Delta-DOR Working Group |
Chairperson | Javier de Vicente |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Christopher Volk |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of ActivityThe scope of the proposed Delta-DOR WG is to clearly define the steps and procedures for the interoperability and cross-support among the Agencies for Delta-DOR observations. More in detail, the aim of the WG is to produce:
- A Magenta Book (Delta-DOR operations) with the standard recommended practice to be used for interoperability and cross-support among different Agencies
- A Magenta Book (Quasar catalogue) addressing the recommended practice for the development/update of a Quasar Catalogue
- A Green Book containing the principles, the technical descriptions and the achievable performance of the Delta-DOR technique plus explanations supporting Magenta Book
- A Blue Book (Raw Data Exchange Format - RDEF) describing the interface for raw Delta-DOR data exchange format
- A Magenta Book (Architectural Guidelines) providing guidelines on spacecraft and ground station technical options to meet Delta-DOR target performance
- A Blue Book (DOR signal structure) providing specifications on spacecraft signal structure for improved Delta-DOR performance (with RF&Mod)
The Working Group is also responsible of updating/maintaining such books when necessary
Rationale for ActivityDuring the last years Delta-DOR (Delta Differential One-Way Ranging) support has become a point of interest for many space Agencies due to its intrinsic reliability and robustness as a technique capable to provide precise navigation data and to be used as an independent mean to validate orbit solutions or for fast orbit determination recovery in case of unexpected events prior or after spacecraft manoeuvres.
Being an interferometric technique, it needs two stations (forming a baseline) for contemporary tracking of a deep-space probe and of an angularly nearby quasar. The way the measurement is performed offers a great opportunity for interoperability among Agencies using Delta-DOR for navigating their probes.
The proposed standardization has the aim to reduce operational costs while improving deep space navigation capabilities by increasing the number of intercontinental baselines able to perform jointly Delta-DOR measurements.
GoalsThere are three parts to providing Delta-DOR services, the first being the definition of the RF domain signals and reception (allocated to CCSDS SLS), the second being the definition of the data products (allocated to CCSDS MOIMS), and the third being the definition of the method for requesting service and transferring data products (to be developed under CCSDS CSS).
The main output of the WG will be the following books.
The Recommended Practice (Magenta Book) on “Delta-DOR operations Operations“ (COMPLETED, to be updated) addresses aspects of the technique that require standardization in order to enable Delta-DOR interoperability among space agencies, e.g.:
- the end-to-end process
- the specific cross-support interfaces
- the parameters needed to implement the defined end-to-end process
- the ground station and spacecraft configuration aspects
- the way agencies will exchange data and the format of such data
- the validation process and qualitative assessment of the Delta-DOR interoperability
- the identification and parameterisation of the standards to be applied to the end-to-end process
The Delta-DOR operations Magenta Book shall undergo a 3-years review in order to address aspects related in particular to:In its revision it also addresses
- the quantitative criterion for the achieved performance level
- the update of the service request needed to enable the Delta-DOR cross-support
The Recommended Practice (Magenta Book) on “Delta-DOR Quasar Catalogue” development addresses:
- the process for establishing, validating, maintaining and updating of a Quasar catalogue enabling Delta-DOR operations.
- SANA operational guidelines
The Green Book on Technical Characteristics and Performance (COMPLETED, to be updated) contains all the descriptive material which is needed, in order to introduce the technique, such as:
- the theoretical background
- the rationales and the trade-offs which led to current and envisaged implementations with particular focus on the signal structure
- the achievable performance
- the overview of the process
The revision of the GB will provide materials that could evolve into a new Magenta Book for the recommendations on architectures and into a new Blue Book for the specific signal structures to be employed (to be issued with the RF&Mod WG). This is still under discussion.
The Proposed Blue Book “Raw Data Exchange Format (RDEF)”(COMPLETED) covers the interface for raw Delta-DOR data exchange
The Magenta Book “Architectural Guidelines” on spacecraft and ground station to meet Delta-DOR target performance addresses the following:
- signal structure of on-board transponder
- ground station receiver and recorder characteristics
- provision for media calibration
The Blue Book “DOR signal structure” provides specifications on spacecraft signal structure for improved Delta-DOR performance.
The development of Delta-DOR interoperability among Agencies would be greatly beneficial for all planned or future Science and Solar System Exploration space missions.
Other topics to be discussed by the WG are:
- techniques to enhance accuracy
- liason with other WGs belonging to the SLS, MOIMS and CSS areas, in order to harmonise the end-to-end system.
Survey of Similar Work Undertaken in Other BodiesDelta-DOR is a specialised activity.
No other WG or other entities outside CCSDS are undertaking any work on Delta-DOR specific matters. Patent Licensing Applicability for Future Standards
N/A Technical Risk Mitigation StrategyDelta-DOR technique for interplanetary navigation is a stable and very well-defined technique; therefore no specific risks can be identified.
Management Risk Mitigation StrategyUnless adequate manpower is allocated, by reviewing Agencies, delays in the documents issues, comments and reviews may defer the finalisation of both the proposed outputs. |
| Systems Engineering Area (SEA) |
Title of Group | 1.07 Time Management Working Group |
Chairperson | Sinda Mejri |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | |
Deputy E-Mail Address | |
Deputy Agency | |
Mailing List | |
Scope of Activity
The Time Management Working Group will concentrate on
creating and maintaining standards relating to time transfer, time correlation,
and time synchronization in space operations contexts. The activities will be coordinated under the
Systems Engineering Area (SEA). Rationale for ActivitySpace agencies need to manage time on their spacecraft for the effective execution of maneuvers, coordination of scientific observations, docking or other robotic collaboration, and for scheduling of communications links or other activities. CCSDS member agencies see value in standardizing parameters and protocols for accomplishing time correlation and synchronization, so that agencies can offer cross support for their timing needs. The biggest motivation for doing this work in CCSDS is to enable a move from mission or agency approaches to internationally interoperable standardized approaches.GoalsStandards shall be developed to promote common understanding of time correlation and synchronization approaches and to facilitate cross support of time management operations among space operations assets. The Working Group has the following goals:
1) Collect and analyze the technical literature, and codify it into specific time correlation and synchronization methods that can be analyzed and compared, in preparation for developing CCSDS Green, Blue, and Magenta Books. As part of this, the requirements for time correlation and synchronization for emerging mission domains/enterprises will be determined and reviewed with other CCSDS stakeholders.
2) Produce a Green Book describing suitable operational domains, applications, and methods used for time correlation and synchronization. The Green Book will identify requirements for interoperable time correlation and time synchronization services. Applications that may make use of time correlation and/or synchronization include maneuvers, coordination of scientific observations, one-way ranging, docking or other robotic collaboration, and scheduling of communications links or other activities. The book will describe methods for time correlation and synchronization, including those for near Earth, cislunar, and deep space regimes. The book will separately address application domains in which a Global Navigation Satellite Service (GNSS) is or is not available. A multitude of time transferand synchronization methods will be described, using correlation techniques such as existing CCSDS ranging methods, one way data delay coupled with trajectory data, two-way range signaling similar to that used by the Tracking and Data Relay Satellite System (TDRSS)), the use of local aera time zones (e.g., rovers and orbiters around Mars), and methods using or not using explicit time code format representations in the signaling. The Green Book will also discuss the roles of clocks, frequency standards, and topics such as X-Ray Pulsars as frequency sources for timekeeping. Error sources will be identified, including limitations in orbit knowledge, calibration, and time tags.
3) Produce a Blue Book describing protocols for time transfer, clock correlation, and clock synchronization. Also, it will include a recommendation for distribution of time in a space network. The Blue Book(s) will define the signaling of time correlation data (signaling containing time code formats) or use of other suitable signals such as telemetry/PN/GMSK+PN ranging needed to accomplish time correlation. They will define protocols for clock synchronization that are suitable for use in traditional single space link deployments as well as in Solar System Internet (SSI) deployments using DTN or IP protocols. As part of the Blue Book development, a Yellow Book describing two independent prototype implementations may be produced, in accordance with CCSDS procedures. 4) A revision of the Time Code Formats Blue Book will be undertaken, with the intent to bring it up to date and re-release it.
Survey of Similar Work Undertaken in Other BodiesCCSDS has developed standards for Time Code Formats (CCSDS 301.0-B-4), Pseudo-Noise (PN) Ranging Systems (CCSDS 414.1-B-2), GMSK+PN Ranging, and is in the process of developing a standard for telemetry ranging (to be included in CCSDS 401.0-B-30), PN ranging using CDMA from a Relay Satellite (CCSDS 415.1-B-1), Earth Receive Time (ERT) time stamps delivered by Space Link Extension (SLE) return frame services (CCSDS 911.1-B-4, CCSDS 911.2-B-3). Each of these standards relates to the representation of or exchange of time, or the measurement of elapsed time useful in determining the range between a reference point on the ground and a reference point on a spacecraft.
A series of IETF RFCs (RFCs 778, 781, 956, 958, 1059, 1305, 5905, 7822) describes the Network Time Protocol (NTP) and its extensions, for time synchronization over the Internet. NTP is one of the oldest Internet protocols in current use. There is not yet a corresponding set of time synchronization standards for the Delay Tolerant Network (DTN) suite.
There are time and position services from GPS/GNSS that are in wide use for near Earth and that have a usable service volume that may extend to cis-Lunar distances. There is an European Cooperation for Space Standardization (ECSS) clock correlation standard that is used in Europe, and there are other agency and mission clock correrlation approaches, some of which are well documented.
This is not intended to be a comprehensive list, but NIST maintains an atomic clock standard, and has established standard definitions for much of the terminology involved. BIPM also maintains an atomic clock standard and uses the same standard definitions. There are a few terrestrial deployments of synchronized clocks that may be used for timekeeping on Earth, but, aside from GNSS systems, no such “fabric” is deployed in space.
These various standards and standard definitions will be utilized where they are suitable in formulating a time transfer and time correlation protocol, and time synchronization standards. In formulating this approach we will study and utilize, as possible, standards efforts and related reports from other international and national organizations.
Patent Licensing Applicability for Future Standards
The current WG participants know of no limitations at this stage on usage of the planned technologies as far as patent restrictions or licensing requirements are concerned. Certain GPS localization technologies may be patented and require a license. Technical Risk Mitigation StrategyNo technical risks have been identified by the BOF at this stage.
There are several systems that already support parts of the desired features in specific environments. The Space Network (SN) has deployed transponders that successfully use PN ranging since 1985. GPS and other GNSS systems, for Earth surface and near Earth uses, provide highly accurate time and position information that is globally used.
The following is one example of recent activities that provide some technical risk mitigation. JPL has been testing telemetry ranging and PN ranging and the next generation transponder has accepted the requirement to time tag their clock in association with a specified bit in the PN.
The WG will review and evaluate existing approaches to determine where, and if, they are applicable in the space operations domain.
The WG will define a consistent set of terms that align with best current practices, see annex for definitions of the terms used in this Charter.
Management Risk Mitigation StrategySchedule relies upon the support of multiple CCSDS Agencies and on the allocation of adequate Agency resources to the WG.
This work involves coordination between the Systems Engineering Area (SEA) and the Space Link Services (SLS) and Space Internetworking Services (SIS) areas which develop specific link and internetworking protcols used in time exchange. This will be particularly important for IP and DTN “wide area” deployment in the Solar System Internet. Coordination will also be required between this WG and the Mission Operations and Information Management (MOIMS) SM&C & Nav WGs for requirements and as stakeholders when they work on MO Time Services and Nav data exchange standards. Coordination will also be required between this WG and the Spacecraft Onboard Information Services (SOIS) App WG when they work on electronic data sheets for onboard clocks to provide time access services for MO Time Services and for other applications. Security topics, if there are any, will be reviewed with the SEA Sec WG when and as required.
A risk management approach will be used to formulate a risk management plan and identify risks other than schedule and resources.
|
| Mission Operations and Information Management Services Area (MOIMS) |
Title of Group | 2.01 Data Archive Interoperability Working Group |
Chairperson | David Giaretta |
Chairperson E-Mail Address | |
Chairperson Agency | UKSA |
Deputy Chairperson | John Garrett |
Deputy E-Mail Address | |
Deputy Agency | USA (formerly NASA) |
Mailing List | |
Scope of ActivityThe DAI WG will address all
areas of Archive data formats, functions, services, operations, and
interoperability for long-term preservation and exploitation for current and
future user communities. Audit and certification issues are also within the
scope for this group. The scope includes data and information preservation,
discoverability, accessibility, interoperability and adding value for long term
usage. and exploitation
Rationale for ActivityAgencies have a critical need to make data available for use by current missions and preserved for use and re-use by future missions and future generations, the science and engineering data that is the hard-won benefits from their space missions. Further, they need to establish interoperable mechanisms to reduce the cost and increase the automation and capabilities for interorganizational cooperation associated with acquiring, ingesting, managing, and disseminating data and metadata to, within, and from archives. Digital obsolescence is a major threat to cope with for preservation while disruptive technology has broadened the value and insights of the data for much wider communities then originally foreseen at the time of data generation. The needs of Producers, Archives, and Consumers can be met by developing additional standards addressing gaps in our current suite of standards. All archives that protect the assets of our space agencies, including both mission archives, final archives and repositories performing long-term preservation, need appropriate processes and mechanisms to be agreed among the agencies to insure long-term digital preservation in a way that supports: findability, accessibility, interoperability and reusability between agencies and other organizations (such as their partners, contractors, and users.) This working group will supply standards for those interoperability mechanisms. The DAI WG will also endeavor, as in the past, to involve additional organizations in ISO and outside the space agency community, so that (as with OAIS), the CCSDS standards will be so broadly acceptable worldwide that they will be supported long term and commercially, hence truly assuring long-term preservation of the agencies’ data and information assets. GoalsGoal 1: Establish an extensible, interoperable, architectural framework for long-term digital preservation for archives. Then proceed to develop standards required to support that architecture. The standards produced will ultimately address:
- A layered architecture
- Provider, consumer and management user interfaces
- Abstraction layer functions that provide platform independence for those user interfaces.
- Adaptations or bindings (plug-ins, drivers, APIs) for various archive types, both within the space agencies and across the worldwide community of archives.
- Secure participation from external organizations to supplement the resources from the space agencies, and to completely perform any standards development that is of negligible interest to the space agencies.
- Approaches for legacy archive interface compatibility
Goal 2: Provide best practices for users regarding information/data asset management throughout the mission or project phases from planning through re-use in order to promote long-term preservation.
Goal 3: As other needs are identified within the scope of this group, we will develop new standards to address those needs. New projects will be undertaken when defined through the CCSDS project framework and following approval by the CESG.
Goal 4: While this working group exists, support other CCSDS Working Groups with their Archive related issues
Goal 5: While this working group exists, support CCSDS requirements in regard to Archives:
– monitor and report on Agency archival issues and implementations;
– perform the required 5-year CCSDS and ISO reviews on existing archive related standards. Update and extend these standards as needs are identified during the reviews.
– and follow it through CCSDS and ISO approvals. Survey of Similar Work Undertaken in Other BodiesThe area of archiving standardization is active. Due to the successful adoption of past CCSDS archival standards, this working group is looked to as a leader in the archival standardization field, and the past work in OAIS has been widely adopted in those other bodies. Additionally, the DAI WG has provided an extensive response to CCSDS management concerning surveys of other bodies working in this area. In summary, that list of other bodies is: CCSDS SM&C, the OGC, ISO TC211/WG7, the IIPC, the OMG, the RDA, ISO TC46, the LTDP, PIN, the GEO, LOTAR, IVOA, and METS. We have confirmed that there are no conflicts or overlaps with those bodies. Working group members continue to network with their colleagues outside the CCSDS attempting to ensure that duplication of efforts is minimized. Patent Licensing Applicability for Future Standards
No patent licensing issues are currently envisioned. As new projects are defined, any patent licensing issues will be identified within the individual projects. Technical Risk Mitigation StrategyTechnical risks are low since there is already broad activity in this area and many years of experience of ad hoc non-standardized activities meeting the needs of individual archives. The initial scoping is the Space agency archives and their Producers. It may also be expanded if reviewers outside the proposed scope find it relevant and useful. Attempts will be made to include participation by interested parties from outside the traditional CCSDS members. If outside participation is not obtained, these activities may result in standards that are less well accepted outside the CCSDS community. Lack of outside participation introduces more possibilities for outside standards that may overtake or conflict with CCSDS activities. Working group members continue to network with their colleagues outside the CCSDS to mitigate as much of the risk as possible.
Management Risk Mitigation StrategyUnavailability of resources could delay achievement of milestones. There is the potential that one or more active experts from various agencies may become unavailable and this could impact the schedule if the timeline slips substantially. A fallback option would be to reschedule the milestones in accordance with actual availability of personnel and other resources. There are no missions within agencies that have an interdependency or critical path need date for these products, so they will be produced at a pace commensurate with the resources. This allows the opportunity to prioritize quality of product over speed of production. This is appropriate considering the long-term view of long-term digital preservation. |
| Mission Operations and Information Management Services Area (MOIMS) |
Title of Group | 2.02 Navigation Working Group |
Chairperson | David Berry |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Frank Dreger |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityThe Navigation Working Group provides a discipline-oriented forum for detailed discussions and development of technical flight dynamics standards (orbit/trajectory, attitude, tracking, maneuver, pointing, orbital events, conjunction assessment, satellite re-entry, etc.).
Rationale for ActivityIncreased possibility of flight dynamics interoperability.
Goals
1) Establish the content and format required for the exchange of orbit/trajectory descriptions for use in tracking spacecraft, mission planning, conjunction assessment, and other space applications. Deliverable: Orbit Data Messages Blue Book.
2) Establish the content and format required for the exchange of spacecraft tracking data and navigation sensor data for use in orbit determination applications. Deliverable: Tracking Data Message Blue Book.
3 Establish the content and format required for the exchange of spacecraft attitude/orientation data and attitude sensor data for use in attitude determination applications. Deliverable: Attitude Data Messages Blue Book.
4) Establish the content and format required to facilitate the transmission of requests related to pointing spacecraft instruments and/or onboard antennas, which require ephemeris and attitude knowledge to process. Deliverable: Pointing Requests Message Blue Book
5) Establish the content and format required to exchange spacecraft maneuver information, both predicted and reconstructed, related to intentional changes to the spacecraft orbit and attitude using spacecraft actuators. Deliverable: Orbit Data Messages Blue Book, Attitude Data Messages Blue Book.
6) Establish the content and format required to exchange warnings related to conjunctions of space objects and re-entry of space objects. Deliverable: Conjunction Data Message Blue Book, Re-Entry Data Message Blue Book.
7) Establish the content and format required to facilitate the exchange of predicted orbital events which affect spacecraft operations. Deliverable: Navkgation Events Message Blue Book.
8) Establish a structure and format that allows the creation of an integrated message combining data from the Blue Books in the Navigation Working Group charter. Deliverable: Navigation Data Messages XML Specification.
9) Develop informational reports that provide explanatory information regarding the published and in progress flight dynamics standards. Deliverable: Green Books containing material relevant to the several flight dynamics standards.
10) Explore additional opportunities for standardization in the area of flight dynamics. Deliverable: Concept Papers.
Survey of Similar Work Undertaken in Other BodiesThe CCSDS Navigation Working Group maintains a liaison with the ISO TC20/SC14/WG3, a related standards organization in the space operations community. Patent Licensing Applicability for Future Standards
<div>At this time (12/2020) there are no known or potential patent licenses that apply to the standards developed by the Navigation Working Group
<br></div> Technical Risk Mitigation StrategyProblems and proposed solutions are well understood, as they are derived from existing and tested navigation data support functions. Technical risk is minimal. Management Risk Mitigation StrategyUnavailability of resources could delay achievement of milestones. Fallback option would be to reschedule the milestones. |
| Mission Operations and Information Management Services Area (MOIMS) |
Title of Group | 2.04 Spacecraft Monitoring and Control Working Group |
Chairperson | Mehran Sarkarati |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Costin Radulescu |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of ActivityThe scope of SM&C includes:
1.) Operational concept: definition of an operational concept that covers a set of standard operations activities related to the monitoring and control of both ground and space segments.
2.) Core Set of Services: definition of an extensible set of services to support the operational concept together with its information model and behaviours. This includes (non exhaustively) ground systems such as Automatic Command and Control, Data Archiving and Retrieval, Flight Dynamics, Mission Planning, Automation, and Performance Evaluation.
3.) Application-layer information: definition of the standard information set to be exchanged for SM&C purposes.
Rationale for ActivityThe ability to standardize the interfaces for spacecraft monitoring and control (SM&C) will allow significant saving in the development of the flight components and the ground segment of future space missions. In fact, it will be possible to use standardized SM&C infrastructure systems, to seamlessly transfer data across systems, and to adopt commercial-off-the-shelf applications for monitoring and control. The high level goal of this standardization effort is to make economies by:
1.) allowing interoperability with partner system and infrastructure.
2.) reducing the risk of space missions by re-using systems and operational concepts, thus increasing their reliability.
3.) facilitating the development of generic (infrastructure) on-board and on ground software that can be shared by multiple projects via simple re-configuration
4.) applying the SM&C approach and systems throughout all mission phases and to other M&C domains (e.g., ground stations, control centers, test facilities, etc.) GoalsThe goal of the working group is
GOAL 1: to pave the way for the technical work that will be performed in the context of spacecraft monitoring and control. This will be done by defining the technology-independent framework to be used in future work. It is noted that this activity involves also the space segment and therefore requires close coordination with the SOIS. This will be done by initially producing a white book and to bring it to Green status.
GOAL 2: to specify and produce the corresponding Blue/Magenta Books for the following initial set of services:
• SM&C Messaging Abstraction Layer (BB)
• SM&C Common Services (BB)
• SM&C Core Services (BB)
• SM&C Binding/Encoding MBs (former SM&C Protocol)
• SM&C Language Specific API MBs
• Update the SM&C GB to bring it in line with the changes above.
GOAL 3: to update the XTCE standard with the result of the public review together with the OMG. To update the XTCE Green Book from presentation format to actual book. To produce the XTCE Magenta Book as recommended practice on how to tailor XTCE for a CCSDS-enabled mission.
GOAL 4: to specify the other application level SM&C services identified in the Green Book.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
NA Technical Risk Mitigation StrategyNone.
Management Risk Mitigation StrategyRisk 1: Unavailability of resources to finalise started work and the relative prototypes
Mitigation: Reduce individual agencies costs by distributing work across several agencies participating to the WG. Bring issue to CMC so as to raise awareness of contributing agencies. In the worst case, descope the work.
|
| Mission Operations and Information Management Services Area (MOIMS) |
Title of Group | 2.07 Mission Planning And Scheduling |
Chairperson | Mehren Sarkarati |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Steve Chien |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of ActivityMission Planning is an activity that often requires interaction between multiple agencies or organisations. This may be to support collaboration between missions, or to allow tasking of payloads by multiple end-users. Some spacecraft may host multiple payloads, potentially from different agencies, and each with an associated Principal Investigator. Other missions, such as observatories, make a single payload instrument available to a wider user community. Mission Planning itself may be distributed between different organisations and in the future some planning responsibility may be delegated to the spacecraft itself. Currently such interoperable interfaces are defined on a per-mission basis.
The Scope of the proposed activity is to define standard CCSDS Mission Planning services, focussing on two aspects:
• The submission of Planning Requests (input to Mission Planning)
• The distribution of Plans/Schedules (output of Mission Planning)
Initial emphasis of the working group will be placed on the specification of the Mission Planning and Scheduling Information Model in form of standardised messages, which are typically exchanged between organisations to support these interfaces. As many organisations exchange such information today through file based communication, the working group shall ensure that the specified Mission Planning and Scheduling Information is generic enough and does not preclude the usage of files for the exchange of the specified messages.
For this purpose the working group shall start with the analysis of current common practices and existing mission planning and scheduling file formats, which are currently in use in the participating agencies. Special focus shall be given to analysis of the mission planning and scheduling file formats, which are currently in use by multi-agency missions with existing cross agency planning scenarios. The analysis shall however be focused and limited to the mission planning and scheduling information, which pertains to the mission planning boundaries: Planning Request files (input), Plan and Schedule files (output).
In the medium-term it is intended to specify the interaction of the involved entities, through standardisation of service-based interfaces that define the dynamic interaction between software applications that are providers and consumers of these services. It is recognised that for this to be possible, the initial specification of Mission Planning and Scheduling messages should be “service aware” to allow the message formats to be re-used in the context of service-based interactions.
In this context, it is important to emphasise that the working group believes the main challenges and difficulties pertains to the first task, i.e. the specification of the actual Mission Planning and Scheduling Information Model, regardless of if the corresponding information is transferred via files or through messages of corresponding service interfaces. Hence the focus of the work and majority of the effort shall be dedicated to this task. Once the syntax and the semantic of the messages to be exchanged is formalised, the specification of the corresponding services for their exchange shall be straight forward and a natural conclusion.
For the specification of the Mission Planning and Scheduling Information Model and the related services, the WG shall identify and document (in the green book?) the relevant scenarios, use cases and deployment architectures. This is to ensure that the resulting Information Model and Services are practical, useful and compliant to the existing operational concepts, organisational constraints and security directives of the participating agencies.
As Ground station and network planning is an important aspect of the overall space mission planning and scheduling, it is important to clarify the scope of the work of the Mission Planning and Scheduling WG and its relationship to other CCSDS Working Groups such as the CSS WG. The planning and scheduling of the ground stations and the network is not in the scope of the envisage Mission Planning and Scheduling services of this WG. As Mission Planning will in many cases interface with Ground Station Planning, the Information Model, specified by this WG must however respect such interfaces.
The CCSDS SM&C working group has specified a generic, service oriented framework for Mission Operations (MO). With the publication of the CCSDS Mission Operations Message Abstraction Layer (MAL) [CCSDS 521.0-B-2] and the CCSDS Mission Operations Common Object Model (COM) [CCSDS 521.1-B-1] blue books, the foundation of the MO service oriented framework has been established. Domain specific information models and the corresponding mission operation services for their exchange, such as Mission Planning services, can now be specified as Common Object Model data entities and MO-compliant services by the respective domain experts in an implementation and communication agnostic manner. One of the objectives of the Common Object Model, is to allow establishing interrelationship between data entities from different Mission Operation Services. In the context of the Mission Planning and Scheduling this means, for instance, to be able to answer questions such as: The value of Parameter X has changed to A, due to the Event Y, which has been triggered on board the spacecraft due to the execution of the Command Z, which has been part of Schedule S, which pertains to Plan P, which included the Planning Request R, …
A green book shall be produced to outline the underlying Mission Planning Services concept.
The actual Mission Planning and Scheduing messages and services shall be specified in one or more blue books. The final list of the Mission Planning services for the blue books shall be identified by the working group and described in the green book. The current proposed list is: Planning Request Service (including associated Planning Request Status Tracking), Plan/Schedule Distribution Service (including associated Execution Status feedback), with initial focus on the specification of Planning Request and Plan/Schedule Distribution messages as XML-based files.
Rationale for ActivityMission Planning and Scheduling is an integral part of overall space mission operations. It encompasses work in preparation before the execution of commands (also often referred to as off-line planning) as well as the immediate work to automation systems on the ground and on-board (be it the traditional on-board schedule or more advanced on-board automation systems). In this regard, Mission Planning and Scheduling Information Model and Services are closely linked to other Mission Operation Services such as commanding, monitoring, on-board queue management and automation services as well as to the information model of navigation services and ground station and network planning and scheduling.
The SM&C working group is currently specifying the first set of domain specific services, starting with those, which pertain directly to the monitoring and control of spacecraft, the so-called MO M&C services. At the same time the SM&C working group has reached out to other CCSDS Working Groups and domain experts to promote the specification of their domain specific services as new MO services. This has included the navigation, mission planning and telerobotics operations domains.
An initial list of envisaged Mission Operations services is outlined in the MO Services Concept green book (CCSDS 520.0-G-3). As it can be seen in the referenced list, mission planning and scheduling services have been among the envisaged candidate Mission Operation services at the foundation of the Mission Operations concept.
In this context, two dedicated technical meetings where held during two CCSDS meetings in Europe and in the US, which received active participation of a large community of planning domain experts from different planning agencies and organisations involved in mission operations. The first meeting took place as part of the CCSDS Technical Meeting held in Darmstadt, Germany in April 2012. 58 mission planning specialists attended the meeting, mostly from Europe [Ref-1]. A second session was held during CCSDS Technical Meeting in Cleveland, Ohio in 2012, with similar attendance mainly from US experts [Ref-2].
Despite differences in planning application domains and a diversity of expert views, a consensus quickly emerged at both meetings as follows:
• The lack of standardised services for exchange of planning data among different entities involved in mission planning scenarios was generally recognised;
• It was acknowledged by the participants that this identified lack of standardised mission planning services lead to the invention of new format and exchange mechanisms for each planning application domain and potentially for each deployment (e.g. for each mission);
• There has been a general agreement that standardising mission planning services would accordingly reduce effort (hence cost) in both software development as well as mission operation domains, by simplifying the integration of distributed mission planning and wider mission operations systems.
• With regard to the approach for specifying standardised mission planning services, it was recommended to start with a so-called black-box approach, where the planning functionality is considered as a black box. The focus shall be accordingly on specifying the operational interfaces for exchange of related planning information items.
• With regard to the scope of the respective services the recommendation has been to start simple, i.e. focus initially on the Planning Request, Plan Result Exchange and Scheduling services rather than attempting to address the more complex problem of exchanging planning constraints and other configuration data;
• Harmonisation of terminology was considered equally important;
[Ref-3] elaborates in more detail on the outcome of the discussions and the conclusions of the technical meetings. A draft concept paper on CCSDS MO Mission Planning Services [Ref-4] was prepared in advance of the Cleveland meeting.
A Mission Planning BOF session was held at the CCSDS Fall 2014 Technical Meeting in London. The need for standardisation of Mission Planning and Scheduling interactions between organisations and systems was generally acknowledged by the BOF. The participants concluded that majority of the effort of the envisaged Working Group shall be focused on and priority shall be given to the definition of the underlying Mission Planning and Scheduling Information Model in form of standardised message formats for Planning Requests and Plan/Schedule Distribution. It was felt that specifying the Planning and Scheduling Information Model in a transport agnostic manner would provide immediate benefit for interoperability, as the resulting messages could be exchanged through file-based communication protocols. This would allow an early adoption of the results of the Mission Planning and Scheduling Working Group within the current file-based deployment architectures.. It was also accepted that any such definition of message formats should be done in a “service-aware” manner to enable their re-use within the subsequent standardisation of service-based interfaces. GoalsThe initial goals of the Mission Planning Services Working Group are:
a) develop an "MO Mission Planning and Scheduling Concept" in the Green Book.
b) Formally specify the Mission Planning and Scheduling Information Model and Services in blue
Survey of Similar Work Undertaken in Other BodiesESA has current activities providing draft mission planning service specifications, which they would like to bring as an input to the WG:
• Specification of Generic Mission Planning Services: Results of the work done by the industry in the context of a dedicated activity as part of the ESA PECS programme.
• Specification of Mission Planning Services for NetSat: Results of the work to be performed in the context of a PhD. NPI contract between ESA and University of Würzburg Patent Licensing Applicability for Future Standards
There are NO known patent license issues. Technical Risk Mitigation StrategyThe involvement of Mission Planning domain experts from the participating agencies will ensure that the Mission Planning Services Working Group will be able to meet its stated goals.
The initial focus on specifying the Mission Planning and Scheduling Information model in form of message exchange formats (which could also be done via file-exchange) allows the quick adoption of the WG results, within current (often file based) cross-agency deployment architectures.
The involvement of Mission Planning domain experts from the participating agencies will ensure that the Mission Planning Services Working Group will be able to meet its stated goals.
The initial focus on specifying the Mission Planning and Scheduling Information model in form of message exchange formats (which could also be done via file-exchange) allows the quick adoption of the WG results, within current (often file based) cross-agency deployment architectures.Management Risk Mitigation StrategyResources already committed by ESA and UKSA are sufficient to defined two projects. |
| Cross Support Services Area (CSS) |
Title of Group | 3.03 Cross Support Service Management Working Group |
Chairperson | Erik Barkley |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Marcin Gnat |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityThe scope is the standardization of the managerial interfaces related to the management of Tracking, Telemetry and Command (TTC) services provided to spacecraft mission operations centers by ground domain TTC networks.
The scope also includes maintenance of CCSDS' current service management recommendation, 910.11x-B-1,taking into account information from member agency implementations. Rationale for ActivityCCSDS member agencies operate TTC networks that provide telecommunications and radiometric services between mission operation centers and mission spacecraft. CCSDS has produced recommendations for both spacelink and terrestrial data transfer services. The coordination and management of these spacelink and terrestrial data transfer services, generally termed "service management" also benefits from standardization as individual missions and TTC network providers can, upon deployment of standards, reduce the need for mission/network unique pairing adaptations -- this in turn fosters cross support which is a primary driver for CCSDS in general. This cross support has applicability both in planned, routine day-to-day operations and also in emergency situations where communications services are requested with very short notice.
CCSDS published its first blue book with regard to service management in August 2009 . This existing recommended standard is scoped to address management of a restricted subset of the typical CCSDS member agency telemetry and command services involving the CCSDS 401 compliant space links and the RAF, RCF, and FCLTU space link extension (SLE) services.
However, the need for a variety of improvements to that initial version has been identified, as described in the following paragraphs.
During its development it was noted that the recommended standard would not scale well when new services to be managed were defined. This was recognized but held as a lower priority in deference to defining the hundreds of parameters, their inter-relationships, and concise definition and statement of the behavior needed for service management.
The current recommended standard does not adequately treat "upstream" processes involved in arriving at communications support planning or concepts such as "standing orders" which are used in placing several related service packages on a schedule of communication services. It is also been recognized that the "downstream" processes to account for delivery of services are also not addressed. This lack for full lifecycle support has been indicated via member agency inputs.
Since the publication of the service management blue book, the Cross Support Services Area has made significant progress in developing a generic Cross Support Transfer Services (CSTS) framework that goes beyond SLE to address additional terrestrial data transfer services as well as observational data about the space link that are needed for a complete set of cross support functions. New services based on the CSTS framework include provision of radiometric observables (for example Doppler and ranging) and delivery of monitor data.
CCSDS has published recommended standards for Pseudo-Noise (PN) Ranging Systems and Code Division Multiple Access (CDMA)-based communications and ranging , both of which require management. The System Engineering Area of CCSDS is currently advancing a recommendation for Delta Differential One-Way Ranging (DDOR) that requires coordination and management of two ground stations which may be operated in an inter-agency context.
The Mission Operations and Information Management (MOIMS) area is currently planning to develop a mission planning service recommendation that will ultimately interface with the communications planning aspect of the service management life-cycle. The MOIMS area has also chartered work that is aimed at event definitions in general which is complimentary to the communication planning aspect of service management with regard to orbital events/communications geometry.
The Space Networking Services area is currently developing recommendations for the Solar System Internet (SSI), based on Delay Tolerant Networking (DTN). SSI planning will ultimately interface with the communications planning aspect of the service management lifecycle, especially with regard to spacelink communications geometry.
In summary, because of the need for management of new services being defined by CCSDS, the lack of complete service management process coverage, the complementary nature of mission operations and TTC network operations, the complementary nature of (space) link level and (SSI inter-)network level operations, and the difficulty with regard to scaling the current service management recommendation, a new approach that leads to a more capable service management recommendation or set of recommendations is required thereby necessitating chartering a new working group. GoalsThe goals include:
1) Identification of CCSDS Member Agency Use Cases (CMAUCs) with regard to management of typical member agency TTC network services
2) A Recommended standard or set of standards for management of spacelink and terrestrial data transfer services. The recommended standard or standards should address the following
Formal definition of the service management life-cycle in accordance with CMAUCs
Identification of the management services or functions needed to support the CMAUCs
An ability to accommodate management of services yet-to-be defined by CCSDS.
In general the set of services are those defined in IOAG Service Catalog 1. An initial sub-set includes the following (CCSDS terms used for the equivalent items in the IOAG catalog):
RAF
RCF
ROCF
FCLTU
FSP
Delta-DOR
TD-CSTS (Tracking Data via CSTS)
MD-CSTS (Monitor Data)
The recommended standard or standards shall also address standardization of commonly identified information artifacts that are exchanged between service providers and service users. Examples of such information include
publication of TTC Network capabilities (service catalog)
publication of TTC Network Schedules
service agreement parameters
calculation of communications geometry (from trajectory predictions)
spacelink signal strength and capacity estimates (link budget, estimated return data volume)
service requests
service level events and service execution configuration change requests
service delivery accounting
3) Support of the management of space inter-networking and the IOAG Catalog 2 services. . Note that this is considered to be a lower priority. It is assumed that the SIS Area of CCSDS has the lead in defining space inter-networking management.
4)Definition of on-the-wire precise interoperable data formats (for example, eXtensible Markup Language (XML)). Survey of Similar Work Undertaken in Other BodiesThe IOAG has conducted a survey of service management needs which has been delivered to CCSDS as an official communiqué . The IOAG has also performed detailed conceptual studies with regard to Solar System Inter-networking which includes management considerations of such an inter-networking capability.
CCSDS has already published a recommendation for management of telemetry and command services (910.11xB1) and found that the prototypes developed by ESA, JAXA, and NASA-JPL inter-operated well via the exchange of XML formatted messages, but the recommendation was insufficiently scoped to meet the full needs of member agencies (see rationale above). Patent Licensing Applicability for Future Standards
<div>None.</div> Technical Risk Mitigation StrategyTechnical risk is not seen as a significant issue for standardization of service management; it does not involve new and/or exotic algorithms but rather is technically well within the state of modern day industry IT practices.
XML technology was proven to be adequate and workable via earlier CCSDS prototyping effort in support of the current Blue Book on service management.
Technical risk is alleviated by the fact that CCSDS has already produced a recommendation for the management of telemetry and command services. The earlier recommendation will provide a significant reference against which to check the new recommendation or recommendations to be developed.
The relatively small technical risk associated with development of data-only format type recommendations (see below for management risk mitigation) without the benefit of the full service definition as a cross-check will be mitigated by first developing a complete concept prior to embarking on the definition of the data-only format recommendations. Management Risk Mitigation StrategyThe main managerial risk is that the set of recommendations will run over schedule with regard to production resources available.
The mitigation is a near-term prioritization with regard to data-only format standards for those items identified as being useful for agencies and judged technically to not require as much, if anything, in the way of extensibility. Such examples include the definition for publication of a schedule of services, and planning information associated with communications link geometry. This will help to ensure that pragmatic recommendations are produced in the near term while allowing the extensibility/scaling capabilities to be developed in a deliberative and technically-sound fashion. |
| Cross Support Services Area (CSS) |
Title of Group | 3.06 Cross Support Transfer Services Working Group |
Chairperson | Holger Dreihahn |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | not appointed |
Deputy E-Mail Address | |
Deputy Agency | N/A |
Mailing List | |
Scope of ActivityThe CCSDS has published recommendations for five Space Link Extension (SLE) Transfer Services. Each of these recommendations contains nearly identical specifications for association, operations, and communications management. Recently a number of new cross support services have been requested by member Agencies. Recommendations for these new services would repeat the redundant sections of the earlier recommendations if specified in the conventional manner. The monolithic nature of the current specification also has the more serious disadvantage that it requires changes to the abstract syntax notation specification for each new service. Although the specifications do not strictly require that the transfer syntax be directly derived form routines generated by an ASN.1 compiler, the practical result is the need to recompile the local-to-transfer syntax translation routines for each implementation of each new service definition. A more efficient method will be to define a framework infrastructure that covers the behavior common to cross-support services. That common behavior will address the association handling, procedures with associated operations. The Framework will define the operation syntax using ASN.1 and will use the ISP (CCSDS 913.1-R-1). Service using the Framework will have the capability to define their behavior and their specific syntax that may be different from ASN.1.
To assist with defining the
content of the information exchanged in the cross support services and ultimately
also with their management, a functional resource model is developed to abstract
CCSDS member agency ground station functions. This model is registered with SANA to help
ensure that the model is maintained as CCSDS standards evolve.
Rationale for ActivityThe purpose of this Working Group is to develop a specification capable of supporting new services implementing each their own behavior and their own syntax. This Working Group, to be known as the Cross Support Transfer Service, will provide:
1) The Framework: a set of procedures defining the behavior required for the establishment and the release of an association and the behavior required for the exchange of information for new data transfer services. To demonstrate the use of this data type indifferent specification, this Working Group will develop a recommendation including the Association Control, the Generic Procedures, the Operations and the Common Principles for the new services.
2) Concept: this informative book will provide an introduction to the concept associated to the Framework and the definition of new services.
3) Guidelines: the Recommendation will be complemented by prescripitve Guidelines describing the definition of new services and a Concept Definition for introducing the overall approach.
Once defined the Framework recommendation will be the basis of the definition of the Monitored Data Service and the Streaming Tracking Data Service. Subsequently, the Forward Frame Service and the Service Control Service will be developed.
The Framework recommendation will be the baseline for the implementation of a prototype demonstrating the Framework concept.
A subset of the Monitored Data Service functionality will be the baseline for the implementation of a prototype demonstrating the interoperability.
The Streaming Tracking Data Service will be the baseline for the implementation of the prototype demonstrating the interoperability.
A subset of the Forward Frame Services functionality will be the baseline for the implementation of a prototype demonstrating the interoperability.
A subset of the Service Control functionality will be the baseline for the implementation of a prototype demonstrating the interoperability.
In the context of the CSTS service definitions it has become clear that the description of the so called production gear underlying the CSTS services, need to be described in terms of semantics, interaction and monitored parameters and control actions. The latter are in particular relevant for CSTS-MD and CSTS-SC. For that purpose the CSTS WG has come up with the concept of Functional Resources.
Functional Resources are abstract representations of the functionality needed to provide space communication and navigation services provided by a Tracking, Telemetry, and Command (TT&C) service provider (e.g., a ground station), defined at a level of granularity sufficient to specify the configuration parameters, monitored parameters, notifiable events, and control actions that may be requested. Functional Resources contain the information that configures, controls, and/or monitors the characteristics of the interfaces between the TT&C service provider and the user ground element(s) (e.g., spacefilght Mission Operation Center) and user space elelemnts (e.g., Mission spacecraft) - e.g., frequencies, modulation schemes, coding schemes, virtual channel organization, and terrestrial transfer services. Real implementations of TT&C service provider systems map these Functional Resource parameters, events, and directives onto the the physical equipment that actually performs these functions.
Functional Resources provide a standard representation of TT&C service provider functionality in CCSDS standards for cross support transfer services and cross support service management.
The CSTS WG will define Functional Resources relevant in the context of an ground station and will ensure proper registration, publication and update of those Functional Resources as a SANA registry.
In parallel with this activity, the Cross Support Transfer Service WG will ensure the maintenance of the existing SLE books: CLTU, FSP, RAF, R-CF and R-OCF. The working group will also ensure the maintenance of the SLE API books.
GoalsThe goals of this Working Group include:
1) Complete the Cross Support Transfer Service Specification of a Framework and advance it to the CCSDS Recommendation state;
2) Complete the Guidelines and the Concept for the Definition of a new Service based on the Framework;
3) Implement a prototype demonstrating the Framework interoperability of the proposed approach;
4) Complete the production of the Monitored Data Specification and advance it to the CCSDS Recommendation state.
5) Implement a prototype demonstrating the Monitored Data interoperability of the proposed approach;
6) Complete the production of the Streaming Tracking Data Specification and advance it to the CCSDS Recommendation state.
7) Implement a prototype demonstrating the Streaming Tracking Data interoperability of the proposed approach;
8) Complete the production of the Forward Frame Service Specification and advance it to the CCSDS Recommendation state.
9) Implement a prototype demonstrating the Forward Frame Service interoperability of the proposed approach;
10) Complete the production of the Service Control Specification and advance it to the CCSDS Recommendation state.
11) Implement a prototype demonstrating the Service Control Data interoperability of the proposed approach;
12) Maintain the SLE suite of books;
13) Complete the production of a best practice for the Functional Resource Model and advance it to the CCSDS Recommendation state;
14) Publish the Functional Resources via the SANA Registry.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
NA Technical Risk Mitigation StrategyBecause the Cross Support Transfer Service will be based upon existing successful implementations of conventional specifications there is little technical risk to this proposed capability. Management Risk Mitigation StrategyThe approach shall ensure extensibility to ensure that definition or new procedures and operation does not require a major rework of the Framework recommendation.
Lack of resources or reassignment of resources is a constant risk to all standards-development processes. Lack of sufficient budget to ensure that the Working Group members can participate in all meetings. As alternatives videoconferences, teleconferences, and email will be utilized whenever possible to reduce costs. |
| Cross Support Services Area (CSS) |
Title of Group | 3.08 Cloud Data Delivery Standards Working Group |
Chairperson | Holger Dreihahn |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Erik Barkley |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of Activity1) Standardization of relevant data formats for delivery of telemetry frames, telecommand data, ground station monitor data, and radiometric data suitable for use in a cloud computing environment.
2) Leveraging of existing CCSDS data format/PDU (protocol data units) such as SLE/CSTS to the extent possible.
3) Cloud friendly/modern encoding schemes that preserve the content of leveraged CCSDS Standards for the above datatypes, including metadata.
4) Messages suitable for stream delivery and file delivery.
5) Identify and define considerations for mission operations centers to utilize the standards with cloud providers.
6) Identify and define consideration for ground stations to utilize the standards with cloud providers.
7) Cybersecurity considerations, in consultation with SE Area Security WG.
It should be noted that the scope of activity regarding telemetry is strictly at the level of providing delivery of telemetry frames; extraction of telemetry packets and any subsequent processing is out of scope for this activity.
Rationale for ActivityPoint-to-Point Data Delivery: SLE is limited to point-to-point data delivery, requiring separate instances for routing to different destinations. Scaling becomes challenging, prompting exploration of alternative solutions like cloud-based storage and processing
Troubleshooting Challenges: SLE bind operation has been time-consuming during early mission test and checkout. Resolving agency firewall and implementation issues is a hidden expense. Cloud computing's omnipresent context can potentially eliminate such issues.
ASN.1 Compiler: SLE mandates the purchase or licensing of an ASN.1 compiler, posing a significant cost for missions, especially those with limited budgets. Modern encoding techniques in a cloud environment could negate the need for a specialized compiler.
Outdated Model and Workforce Challenges: The SLE model is outdated, potentially hindering recruitment of qualified personnel Today's graduates are more knowledgeable about cloud computing, with dedicated courses and degree programs available.
Cost and Scalability Issues: SLE can be expensive for TT&C providers to scale for emerging missions with high data volumes. Cloud computing provides rapid scalability, making it a cost-effective solution for increasing processing, storage, and bandwidth capacities.
GoalsProduce efficient, flexible standards in line with current industry practices.
Leveraging existing CCSDS to promote the good work already done for industry adoption consideration and minimize CDDS WG standards development time.
Provide harmonized access and data delivery for cloud-based mission to agency (and commercial) ground stations.
Survey of Similar Work Undertaken in Other BodiesCCSDS has investigated cloud-based prototyping in general and concluded that it is a worthwhile approach. Patent Licensing Applicability for Future Standards
None.
Open-source technologies will be given priority regarding standards development.
Technical Risk Mitigation StrategyEncoding technology continues to evolve and therefore has an inherent obsolescence risk. The mitigation is to maintain an abstract encoding model and be prepared to adopt alternate technologies if needed. Management Risk Mitigation StrategyRisk: Running behind schedule
Mitigation: more resources, request industry participation
Risk: proper cyber-security definitions
Mitigation: involve SE Area Security WG
|
| Spacecraft Onboard Interface Services Area (SOIS) |
Title of Group | 4.01 Subnetwork Services Working Group |
Chairperson | Glenn Rakow |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Marco Rovatti |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityThe Subnetwork Services Working Group (SUBNET WG) is concerned with the transfer of information onboard a spacecraft between its constituent subsystem components. In practice this involves both hardwired systems and wireless systems.
The mission of the SUBNET WG is to serve as a CCSDS focus group for onboard network technologies. The goals of the WG are to define services and make recommendations pursuant to standardization of applicable data link protocols and related subnetwork services, ensuring inter-operability of independently developed space vehicles and spacecraft onboard networks.
In the past the SUBNET WG has already defined the requirements for information transfer services that must be provided by a subnetwork, along with the service interface provided to higher layers of the communication stack (SOIS Application Support Layer). Considerations for these services included reliable delivery, timeliness, and security that need to be met at the subnetwork layer.
The scope of the SUBNET WG is to perform an overall review of the existing SOIS architecture and Magenta Books. In consultation as necessary with other SOIS WGs, analyze existing service definitions and interfaces, and compare to existing and future mission use cases to determine how well they align. Special attention will be given to distributed systems, software bus, and fault tolerant systems. From this activity, develop a work plan to update any services as necessary to bring existing service books in alignment to an overall coordinated architecture applicable for SOIS and other CCSDS Areas.
It shall further review existing deterministic protocols applicable for space. Define and catalog the deterministic protocols by use cases, and analyze their applicability space. Rationale for ActivityDuring the Onboard Deterministic Network BoF meeting in spring 2015 it was concluded that deterministic networks naturally fit within the domain of the SOIS SUBNET WG. The definition of onboard deterministic subnetwork services may require a number of updates to the SOIS subnetwork Service Magenta book and is therefore best combined with the five-year review of these books. Additionally, during the book review, a mapping of the SOIS Subnetwork services to the most widely used data link types used for on board spacecraft applications will be performed. These mappings will be captured in a SOIS Subnetwork Service Utilization Profile Blue Book.
Five SOIS Subnetwork Service Magenta books have been published in December 2009 and are due for revision or reconfirmation. These include the Subnetwork Packet Service, CCSDS 851.0-M-1; Subnetwork Memory Access Service, CCSDS 852.0-M-1; Subnetwork Synchronization Service, CCSDS 853.0-M-1; Subnetwork Device Discovery Service, CCSDS 854.0-M-1; and Subnetwork Test Service, CCSDS 855.0-M-1. GoalsThe goals of this Working Group are to:
a) Define deterministic subnetwork services in the form of a SOIS Subnetwork deterministic service magenta book.
b) Perform a five-year review of SOIS Subnetwork Services Magenta Books. This entails analysis of and perform, where necessary, updates to existing SOIS Subnetwork Services Magenta Books based upon the current assessment of requirements for future exploration systems, their relevance to a broad range of requirements for human-rated and robotic missions, and new areas of interest such as deterministic and wireless networks. The following are the published SOIS Subnetwork Services Magenta books for review:
1. Subnetwork Packet Service, CCSDS 851.0-M-1
2. Subnetwork Memory Access Service, CCSDS 852.0-M-1
3. Subnetwork Synchronization Service, CCSDS 853.0-M-1
4. Subnetwork Device Discovery Service, CCSDS 854.0-M-1
5. Subnetwork Test Service, CCSDS 855.0-M-1
The outcome of the review process may result in the addition of new book(s) and, or deletion of existing book(s), as well as updates to existing books. In case that the books are not confirmed but it is concluded that an update is needed the respective CWE Projects will be created and submitted for approval as required.
c) Perform mapping of Subnetwork Services Magenta books to a selected list of data link protocols relevant to spacecraft onboard networks. The mappings will be compiled and published in a new SOIS Subnetwork Services Utilization Profile Blue Book.
It is expected that this effort will involve identifying existing mappings in most cases, but in a very few cases may require creating or leveraging a portion of another specification to create a mapping if it does not already exist. Potential data link protocol candidates for providing the mapping include:
1. CAN
2. Ethernet
3. Mil-Std-1553 (Milbus)
4. RapidIO
5. SpaceFibre (SpFi)
6. SpaceWire (SpW)
7. Time Triggered Ethernet (TTE)
8. Time Triggered Protocol/C (TTP/C)
9. Wireless protocols (various)
d) Provide inputs to the to the Dictionary of Terms (DoT) which is developed by the SOIS Application Support Services WG to define terms that may be used to describe the targeted data link protocols. These would be terms that are specific to a particular data link protocol’s terminology.
Survey of Similar Work Undertaken in Other BodiesThe data link protocols used for the mapping are standardized by other bodies like IEEE, ECSS and others. Their mapping to the SOIS service is normally not performed by these standardization bodies. Wherever similar service mapping information is available it will be referred to. Patent Licensing Applicability for Future Standards
No limitations on the usage of the planned technologies, patent restrictions or licensing requirements have been identified. Technical Risk Mitigation StrategyWith respect to the deterministic networks for safety critical applications, other industries such as commercial aircraft, automobile, rail, etc. are already using these protocols and related architectures for their respective industries. The safety critical concepts are well established for human-rated vehicles but are just beginning to creep into the robotic spacecraft arena to provide gains in integration through more robust composability and fault tolerance. For non-safety critical deterministic networks, spacecraft use them but work is necessary to make interoperability widespread. Hence, the technical risks for these two topic areas are low. The risks center more on resources and ability to educate the appropriate decision makers to see the cost and risk reduction advantages.
For the SOIS SUBNET five-year review, the services have already been defined and prototyped for two onboard data link protocols, SpaceWire and Mil Bus (1553). The mappings for other protocols mostly exist, and where they do not, it is expected that mappings may be adopted soon. The bigger picture is updating the existing books for more advanced architectures that use deterministic networks, and time triggered software in architectures for distributed computing and available computing applications. For this, the technology exists and it is a matter of properly capturing the information, and getting the members of the SUBNET WG up to speed on the technology (if not already). Again, the technical risk is low. Management Risk Mitigation StrategyThe main supporting agencies ESA and NASA have demonstrated in the past their long term commitment for long term support for the work in the Spacecraft Onboard Interface Services area and the subnetwork working group.
In addition it is anticipated that supplemental support will be available from sources external to CCSDS, such as Advanced Exploration System (AES) to support to achieve the identified milestones.
The precise amount of the work can only be defined during the 5 year review of the SOIS Subnetwork Services Magenta Books when the level of required updates and changes will be estimated.
It is still expected that a technical team correct composition will be available to complete the identified work in the projected time frame. At this time the members of the revived WG must still be formally appointed pending the confirmation of resources. |
| Spacecraft Onboard Interface Services Area (SOIS) |
Title of Group | 4.02 Application Support Services Working Group |
Chairperson | Jonathan Wilmot |
Chairperson E-Mail Address | |
Chairperson Agency | NASA (GSFC) |
Deputy Chairperson | Richard Melvin |
Deputy E-Mail Address | |
Deputy Agency | UK Space Agency |
Mailing List | |
Scope of ActivityThe standard services that are addressed by this working group are those that have been identified during previous CCSDS SOIF activities as being common requirements in all spacecraft missions, and providing the maximum benefit for flight software development and exchange of data between on-board software and hardware components. Furthermore, it is explicitly recognized that interoperability and cross support capabilities need to be provided throughout the project lifecycle, not just during operations, and particularly during application development; integration, and testing. It has also been recongnized that potential users of the SOIS standards may have existing software architectures and/or frameworks that provide those services but with very different implementations. To achieve the benefits to interoperability, cross support, and full lifecycle application development, SOIS is developing interface definition standards that support mapping of interfaces both within a software architecture and between different software architectures.
Rationale for ActivityThe Application Support Services Working Group defines standard services that are provided to onboard software applications. These services isolate the flight software from the underlying hardware details and thereby increase the portability and reuse potential of the flight software. Furthermore, the service access points constitute cross-support interfaces. Defining these services and interfaces using a standard machine readable interface definition language retains the benefits to interoperability, cross support, and full lifecycle application development while allowing domain specific and optimized implementations to be used.GoalsIt is the overall goal of the SOIS area to produce machine readable device and software component interface specification standard(s) that can be widely adopted and included with spacecraft devices, software components, and science instruments enabling the rapid integration of those components into systems. This would lower the cost of space systems, and enable device and software component interoperability across agencies and industry.
The specific goals of this Working Group are to:
1) document the concepts of onboard communication architectures for applications and devices, including plug-and-play modes of operations, showing the interfaces needed for inter-agency cross support and interoperability, and showing clearly the relationship between the onboard application services and other CCSDS standards;
2) produce machine-readable interface definition schema(s) supporting data exchange, command, and acquisition services. that enable onboard applications to command and acquire data from onboard devices and/or software components.
3) produce guides and a dictionary of terms in support of goals 1 and 2 above
4) gather and incorporate feedback from agencies and industry on applicability of the standards
5) develop and execute approaches to gain wide adoption and infuse the capabilities in missions
6) develop and document software tools to demonstrate application of the standard(s) to existing and future mission systems
7) Work with other Working Groups and BOFs to ensure alignment with the overall CCSDS architecture and other CCSDS areas
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
None known Technical Risk Mitigation StrategyThe WG requires members who have expertise in full life cycle software and avionics development and systems engineering. The WG intends to recuit members who have that expertise and consult other experts as needed.
Management Risk Mitigation StrategyThe Working group addresses several topics within the domain of spacecraft software and avionics. Maintaining the schedule requires members with expertise in those topics and continuous support of Agencies in making them available. |
| Spacecraft Onboard Interface Services Area (SOIS) |
Title of Group | 4.03 Onboard Wireless Working Group |
Chairperson | Kevin K Gifford |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Yuriy Sheynin |
Deputy E-Mail Address | |
Deputy Agency | RFSA |
Mailing List | |
Scope of ActivityThe mission of the Wireless Working Group (WWG) is to serve as a general CCSDS focus group for wireless technologies. We will investigate and make recommendations pursuant to standardization of applicable wireless network protocols, ensuring the interoperability of independently developed wireless communication assets.
The WWG is focused on wireless, either RF or optical, networks, (i.e., WLAN, WPAN, WMAN, and sensor networks) and does not consider point-to-point wireless standards that are addressed by other CCSDS technical areas including Space Link Services (SLS) and Space Internetworking Services (SIS).
The goal of the Wireless Working Group is to provide the CCSDS development community and participating members with standards-based resources to achieve interoperable wireless network communications, including specific protocol recommendations for anticipated communication scenarios associated with, but not limited to, Lunar and Martian exploration activities. The deliverables will be provided in the form of a Green Book summarizing wireless usage scenarios and technology applicability, followed by a set of Magenta and Blue books specifying current best practices in the application of wireless network communications for asset management, intra-vehicle communication, high data-rate (HDR) wireless communications, and for support of ground-based assembly, integrations and test (AIT) operations. Rationale for ActivityCCSDS develops communications and mission operation standards that support inter- and intra-agency operations and cross support. CCSDS standards include elements of flight and ground systems that are developed and operated by different agencies and organizations. International standards for wireless space networking do not yet exist. The CCSDS has subcategorized wireless short-range and surface proximity networks as:
1) Intra-vehicle: Internal vehicle (or habitat) extremely short-range wireless links and networking (up to 10 m range).
2) Inter-vehicle: Vehicle-to-vehicle short-range and medium range (up to 20 km).
3) Planetary surface-to-surface wireless links and networking (up to several kilometers).
a. EVA (Extra-Vehicular Activity) local links with planetary rover vehicles (RV) and/or habitats; b. RV-habitat links when RV is close to habitat; c. Links between independent local systems (e.g., habitats, robots, external assets).
4) Orbiter relay-to-planetary surface links and networking.
The recommendations of this Working Group will enable member agencies to select the best option(s) available for space communications and internetworking, based upon industry-standard evaluation metrics such as power expenditure, data rates, noise immunity, and range of communication as well as on space systems metrics such as reliability, availability, maintenance and safety.
Wireless communications is an enabling technology for both manned and unmanned spacecraft – it enables untethered mobility of crew and instruments, increasing safety and science return, and decreasing mass by eliminating expensive cabling. Wireless networks automatically enable communication between compliant devices that dynamically come into and out of range of the network. Wireless communication is fundamental for communicating outside of a spacecraft (e.g., inter-spacecraft communications, planetary surface communications), and provides for mobile crew monitoring within a habitat or spacecraft (intra-vehicle communications). Added value for using wireless communications is also identified for the ground.
From an engineering standpoint, mission managers, along with engineers and developers, are faced with a plethora of wireless communication choices – both standards-based and proprietary. The provision of a CCSDS standard reference that summarizes wireless protocol capabilities, constraints, and typical deployment scenarios, will decrease the up-front engineering evaluation effort significantly, and provide a standards-based common reference to improve interoperability between disparate systems that need to cooperate in wireless data transmission and networking.GoalsThe goals of the working group are as follows.
1. Derive, and publicize in a CCSDS Green Book, communications usage cases for the three initial focus areas of (1) asset tracking and management; (2) intra-vehicle communications; and (3) assembly, integration and test (AIT) activities. The Green Book shall:
Summarize canonical usage scenarios;
Include a technology assessment of current wireless technologies applicability for the each focus area;
Summarize (speculative) requirements associated for each focus areas; and
Identify gaps in available technology when contrasted with operational requirements associated for each focus area.
2. Prepare three two Magenta books to summarize scenarios, requirements, and suggested wireless protocols requirements for:
Asset/inventory tracking and control via wireless communications;
Low data-rate wireless communications for spacecraft monitoring and control;
High data-rate wireless communications for spacecraft monitoring, control and multimedia services.
3. Prepare two Blue books to specify wireless communication standards for:
RFID tag encoding for inventory management and control and sensing
High data-rate wireless communications for spacecraft monitoring, control and multimedia services, including intra-vehicle communications and communications for extra-vehicular activities.Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
None Technical Risk Mitigation StrategyTo mitigate the technical risk, the following coordination activities are identified for the WWG.
1. Coordinate activities with SLS that contribute to the technical assessment of wireless protocols and requirements for surface inter-asset communications, including location and ranging scenarios;
2. Coordinate activities with SLS that contribute to the technical assessment of wireless protocols and requirements for surface inter-vehicle communications, including location and ranging scenarios.
3. Interact with the Systems Engineering Security Working Group to ensure security concerns are adequately addressed in all recommended wireless standards.
4. Summarize the interoperability of recommended wireless protocols at the physical, data link, network, and transport layers of the OSI communications protocol stack.
6. Facilitate reference implementations and performance of interoperability testing.Management Risk Mitigation StrategyTo mitigate the management risk, the following coordination activities are identified for the WWG.
1. Guide adoption and derivation of interoperable wireless communication protocols in support of CCSDS activities.
2. Hold working meetings with other Working Groups to develop consistent approaches and formulate plans for integrating wireless communications into the activities of other CCSDS Working Groups.
3. Evolve and maintain the WWG Green Book and Magenta and Blue Books to provide comprehensive wireless protocol reference documents for use by CCSDS member agencies and Working Groups. |
| Space Link Services Area (SLS) |
Title of Group | 5.01 RF and Modulation Working Group |
Chairperson | Dennis Lee |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Gunther Sessler |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of ActivityRationale for ActivityAgencies are planning demanding missions to the Moon with links at 2 GHz for low data rates and 22 (the band near 22 GHz)/26 GHz for very high data rates, as well as missions to Mars with 32 GHz trunk links. The 22 (the band near 22 GHz), 26 and 32 GHz frequency bands are not covered by the existing RF and Modulation Blue Book (401.0-B-16). New techniques may be needed for the 2 GHz links to the Moon.
The Proximity-1 Physical Layer Blue Book (211.1-B-3) has to undergo the 5-years review; additionally, the other two layers Blue Books and the Green Book have to be reviewed for what concerns the requirements having RF&Modulation implications.
Additionally, developing requirements on phase/amplitude imbalance and phase noise for the advanced modulation schemes of the current Blue Book (recommendation 2.4.17A) is needed.
The bandwidth-efficient modulations Green Book (413.0-G-1) needs has to be updated to reflect the recent changes in the Blue Book relating to recommendation 2.4.17B, 2.4.18 as well as a number of nomenclature changes (bit and symbol rate definition, OQPSK filtering, T-OQPSK suppression, etc.) Moreover, a mixture of informative and normative information exists in the current Green Book, which is confusing. The normative part has to be removed from the Green Book and inserted in 2.4.17A, 2.4.17B and 2.4.18.
Additionally, 2.4.17A includes a number of modulations that have not been used to date nor are expected to be used in the foreseeable future. Re-opening discussion on 2.4.17A could solve this problem and provide a basis to respond to the request from IOAG on trying to limit the number of schemes allowed by 2.4.17A.
The Green Book (412.0-G-1) on RF Spacecraft-Earth Station Compatibility Test Procedure has to be reviewed and updated in line with current practices if deemed necessary.
Additionally, this WG will develop a Green Book that will include, on the one hand those requirements on local planetary communications in support to future manned and unmanned missions to the moon, Mars and other solar system bodies such as asteroids, and on the other hand state-of-the-art system concepts, techniques and technologies candidates for possible standardization.
The requirements will focus on offering increased data transfer capability as compared with current standards (Proximity-1), but also consider networking capability and increased interoperability.
GoalsThe goals of this Working Group are to:
1) Develop modulation recommendations for 22 (the band near 22 GHz), 26 and 32 GHz high rate links;
2) Develop recommendations for Lunar missions to operate at 2 GHz with other users;
3) Revise the recommended schemes in 2.4.17A and develop necessary companion recommendations on imbalances and other impairments;
4) Update 413.0-G-1 in line with recent changes to 401.0-B-16 and move normative text from 413 to 401 (as attachments to 2.4.17A, 2.4.17B and 2.4.18);
5) Update the RF and Modulation Book CCSDS 401.0-B-16 set of recommendations on modulation techniques as per items 1 to 4 above and possible changes required by technical or regulatory issues;
6) Review the RF and Modulation Compatibility Test Procedures Book CCSDS 412.0-G-1 and update it if necessary;
7) Study future Earth Exploration-Satellite-Service requirements in terms of modulation schemes with signaling efficiency better than the schemes in recommendation 401 (2.4.18) for the 8025-8400 MHz band and possibly the 25.5-27.0 GHz band, and study performance of the advanced modulation schemes proposed by the coding and synchronization WG;
8) Study efficient way to combine high rate telemetry and PN ranging with suppressed carrier modulations for the space research service bands;
9) Study the NGU requirements for file uploading and as a consequence update recommendation 2.2.8;
10) Study the NGU requirements for MSPA support and as a consequence develop flexible turn-around ratios recommendations for the 7/8, 34/32 and 40/37 GHz bands or an alternative technique to provide MSPA (multi-carrier operations, CDMA, etc.);
11) Study impairments for 4D-8PSK TCM and propose relevant recommendations;
12)Review the Proximity-1 Blue and Green Books and propose changes if needed;
13) Perform 5-years review of 413.0-G-2 and update it as needed;
14) Co-operate with SLS-C&S for ACM/VCM techniques for the 26 GHz EESS channel;
15) Study turn-around ratios for the new EESS uplink allocation at 7 GHz in association with the 8 GHz downlink and propose relevant recommendation;
16) Propose changes to DDOR recommendation 2.5.6B for low cost missions;
17) Study telemetry ranging concept and propose relevant recommendation;
18) Study modulation technique and position for pilots symbols of high order modulations used in conjunction with the codes of CCSDS 131.0-B-2.
19) Develop high order modulations recommendation for space research (Cat. A) missions in the 8450-8500 MHz band based (subset) on the ones for earth exploration satellites.
20) Propose changes to DDOR recommendation 2.5.6B for more performing and less interfering wideband pseudo-noise (WB PN) DDOR signal.
21) Propose changes to Proximity Physical BB (211x1b4) relating to channel frequencies, modulations, and requirements from future Martian/Lunar scenarios.
22) Address requirements of Position, Navigation and Time (PNT) related to the Lunar environment in cooperation with CCSDS NAV WG and SFCG, and issue relevant recommendations covering frequency bands, modulations, etc.
23) Prepare green book material to address project issues on filtering implementation to comply with SFCG spectral mask recommendation 21-2R4.
24) Study phase noise including both transmitters and receivers for space-to-space links and lunar surface equipment.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
None have been identified. Technical Risk Mitigation StrategyNo technical risks have been identified. Management Risk Mitigation StrategySchedules are dependent upon Agency participation. |
| Space Link Services Area (SLS) |
Title of Group | 5.02 Space Link Coding and Synchronization Working Group |
Chairperson | Andrea Modenini |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Kenneth Andrews |
Deputy E-Mail Address | |
Deputy Agency | NASA |
Mailing List | |
Scope of ActivityThis working group will concentrate on creating, maintaining and updating the set of Channel Coding Books to incorporate recommended coding scheme for Telemetry, Telecommand and Proximity-1 links. Rationale for ActivityIn order to establish a common framework within which the Agencies may develop standardized services for Telemetry, Telecommand and Proximity-1 links, the CCSDS advocates adoption of a layered systems architecture. Within this approach, the Coding and Synchronization Layer has the purpose of protecting higher layer data units (i.e. "frames") against errors induced during transmission through the physical path to/from a spacecraft. The Coding layer shall satisfy the System requirement for the delivery of data units to the receiving end upper layer. It shall satisfy this task by encoding the user data from the layer above to protect them against noise-induced errors during transmission through the underlying radio frequency channel and by using suitable synchronization techniques to allow proper identification of the individual data units.. In addition the wide range of environment (space-Earth or space-space, near Earth congested bands and deep space link operations in extreme conditions of SNR, links dependent of atmospheric conditions in the new high frequency bands) requires coding systems with different levels of power efficiency and bandwidth efficiency, or different levels of link reliability or delivered data quality. Additionally, harsh environment impairments such as out-of-synchronization events and adverse weather conditions, demand for the application of higher-layer coding techniques, actually complementing the lower layers channel coding schemes. GoalsThe targets mentioned above shall be achieved by defining the methods by which data can be sent from a source to a destination such that distinct messages can be easily distinguishable from one another and their reconstruction can be performed with low error probability, thus improving the performance of the channel. The Coding and Synchronization WG shall provide/maintain standards to be applied to Telemetry, Telecommand and Proximity-1 links to allow Agencies to implement the most appropriate Coding & Synchronization procedures. The characteristics of the codes shall be specified only to the extent necessary to ensure interoperability and cross-support. Correct interaction with the procedures at the Data Link Protocol sublayer and Physical layers shall be ensured too. These goals shall be achieved by updating the existing set of Channel Coding Books by either modifying existing books or creating new books as required and described in the WG Projects.
The full list of current goals/projects and completed ones is provided at https://cwe.ccsds.org/fm/Lists/Projects/AllOpenChartersWithAllProjects.aspx (charter 5.02)
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
YES - The WG is working on patented technologies for 3 items: LDPCC, SCCC and DVB-S2 Technical Risk Mitigation StrategyNo technical risks have been identified. Management Risk Mitigation StrategyThe schedule is very dependent upon Agency commitment of resources and the use of the same personnel working on concurrent CCSDS tasks. |
| Space Link Services Area (SLS) |
Title of Group | 5.03 Data Compression Working Group |
Chairperson | Englin (Mark) Wong |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Lucana Santos |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityRationale for ActivityFuture space missions will make increasing use of multispectral and hyperspectral imagers and other instruments, that significantly increase the volume of data to be collected and transmitted to the ground. Cooperative mission scenarios exist where cross-support is needed for handling the resulting increased data volume. Industry, principal investigators, instrument developers, etc., will welcome international standards for compression of these data types to meet the unique requirements of space missions and provide state-of-the-art performance levels.
Implementation constraints severely limit the complexity of on-board processing. Existing standard approaches to compression of multispectral and hyperspectral data (e.g., JP3D, an existing 3D extension to the JPEG2000 standard) have high implementation complexity as they have not been optimized with respect to performance-complexity tradeoff for space applications. Current CCSDS data compression recommendations 121.0-B-1 and 122.0-B-1 have lower complexity and can be applied to multi- and hyperspectral data, but offer substantially less effective compression than modern compression algorithms designed specifically for multi- and hyperspectral image data. Therefore, it is the consensus of the participating agencies that the development of new recommendations for compression of multispectral and hyperspectral image data and other data types is necessary together with regular "maintenance" of existing books.
The Working Group goals shall be achieved by updating the existing set of Data Compression Books by either modifying existing books or creating new books as required and described in the WG Projects.
GoalsThe goals of the Multispectral and Hyperspectral Data Compression Working Group are to:
1. Finalize selection criteria and requirements matrix for compression standard(s) for lossless and lossy compression of multispectral and hyperspectral imager data. Criterion will include implementation complexity as well as quantitative quality criteria to evaluate lossy compression effectiveness.
2. Establish a set of test data (including, when available, ground truth data for a relevant application) for testing and evaluation of candidate compression algorithms.
3. Evaluate candidate algorithms using the selection criteria established and considering the needs of the CCSDS member agencies.
4. Develop a recommendation together with supporting information (simulation software, test data sets, and Green Book).
5. Develop Recommended Standard for Compression of Housekeeping Data.
6. Develop Recommended Standard for Compression of Synthetic Aperture Radar (SAR) Data.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
<div>See individual projects.</div> Technical Risk Mitigation StrategyThere is a possibility that no single algorithm will suit all of the agency needs given the diversity of sensors and mission constraints. Management Risk Mitigation StrategyThe resource commitments significantly leverage previous and ongoing data compression work efforts. However, increased resource commitments will likely be necessary in future years for timely completion of a recommendation. |
| Space Link Services Area (SLS) |
Title of Group | 5.04 Space Link Protocols Working Group |
Chairperson | Greg Kazz |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Mathew Cosby |
Deputy E-Mail Address | |
Deputy Agency | UK Space Agency |
Mailing List | |
Scope of ActivityThis WG develops and adapts wherever possible link layer protocols for new mission environments (proximity communication, formation flying, optical communication, missions utilizing high rate telemetry and telecommand. Rationale for ActivityDevelop the CCSDS next generation link layer protocol, called the Unified Space Data Link Protocol (USLP). This protocol is to support data exchange over all space communications links: space-to-ground, ground-to-space, and space-to-space. This protocol has provision for several margin enhancing capabilities including but not limited to high data rate (hundreds of Megabytes) missions and expanded Spacecraft ID Name Space.
In line with the evolutions in the CCSDS link layer protocols which occurred in the recent years, e.g., development of the Proximity-1 Space Link Protocol, it has become necessary to update and complete the Green Books related to these link layer protocols.
It is important to note that this WG maintains a very close liaison with the related Channel Coding WG and RF & Modulation WG.
Goals1) Develop the Unified Space Data Link Protocol (USLP) Blue Book.
2) Develop the Unified Space Data Link Protocol (USLP) Green Book.
3) Revise CCSDS 133.0-B-1 to modify and limit the scope of concepts such as Logical Data Path and APID Qualifiers.
4) Revise CCSDS 130.0-G-3 Overview of Space Communications Protocols Green Book to be consistent with the revised SPP.
5) Revise CCSDS 133.1-B (Encapsulation Service) to remove applicability for Space Packets and consistently rename it to "Encapsulation Packet Protocol"
In the past years, the SLP WG has completed the following goals:
Updated Proximity-1 Space Link Protocol—Data Link Layer - Blue Book to Issue 5; Updated Proximity-1 Green Book to Issue 2; Updated Space Data Link Protocols Green Book to Issue 2; Updated Overview of Space Communications Protocols Green Book to Issue 3; Updated TC Space Data Link Protocol for inclusion of SDLS Requirements; Updated AOS Space Data Link Protocol for inclusion of 5-year Review and SDLS Requirements; Update the TM Space Data Link Protocol Blue Book for inclusion of 5-year Review and SDLS Requirements; Updated Space Data Link Protocol Green Book 130.2 to conform to the changes to the TC Sync and Channel Coding Blue Book.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
There are no patents envisioned as a result of this working group. Technical Risk Mitigation StrategyNo technical risks have been identified. Management Risk Mitigation StrategyThe schedule is somewhat dependent upon having the members of the Working Group provide a sufficient review of draft white, red, and green books. Another schedule risk involves getting technical editing assistance from the Document Editor on the submitted technical documentation. |
| Space Link Services Area (SLS) |
Title of Group | 5.09 Space Data Link Security WG |
Chairperson | Gilles MOURY |
Chairperson E-Mail Address | |
Chairperson Agency | CNES |
Deputy Chairperson | Howard Weiss |
Deputy E-Mail Address | |
Deputy Agency | |
Mailing List | |
Scope of ActivityThe objectives of this SDLS WG is to develop a recommendation for a security protocol operating at the data link layer of CCSDS spacelinks. Target missions are civilian missions (science, earth observation, telecommunications, ...). This security protocol should provide authentication and/or encryption both for uplink and downlink. It should be compatible with CCSDS TM, TC and AOS data link protocols and be independant from any specific cryptographic algorithm.
An additional objective of the SDLS WG is to develop standard security mechanisms at the physical layer of CCSDS spacelinks to provide protection against jamming and denial of service.
Rationale for ActivitySecurity of TC and TM space links has become a major concern for not only defense related missions but also for mainstream missions like science and commercial (telecommunications, earth observation, ...). Consequently, CCSDS has embarked on developing recommendations for security architectures, authentication/encryption algorithms, key management, ... that offer a framework and tools to develop standards track recommendations for security protocols at various layers.
New cooperative missions are emerging requiring interoperable security functions operating at data link layer or higher. More generally, it appears that governmental & commercial missions, with no defense related security constraints, would welcome an open standard and industry supported solution for TM/TC link security (in particular TC authentication and TM/AOS encryption) usable in a wide variety of civilian missions.
Implementation of security functions at network or application layers offers the advantage of providing end-to-end security which is desirable for multi-hop TM/TC link configurations (e.g. : earth to orbiter to lander to rover). On the other hand, most missions have only single hop TM/TC configurations. In that case, data link layer security will usually provide end-to-end security because transfer frames are generated in the control center and are validated in the TM/TC procesor on-board. As a consequence, this data link security solution centralizes the security functions in two entities only, minimizing development, validation and operational cost.
In response to the missions needs exposed above, a TM/TC data link security BOF has been formed at the CCSDS march 2008 meeting with the main objective of producing a User Requirement Document (URD) for a data link layer security protocol providing encryption and/or authentication, and compatible with CCSDS data link protocols. This URD has been finalized and accepted by all the agencies involved at the CCSDS october 2008 meeting. Therefore, the creation of a Space Data Link Security WG was proposed to develop a recommendation (blue book) for a data link layer security protocol fulfilling established URD. GoalsThe Space Data Link Security WG has the following goals :
1- Develop Data Link Security Protocol according to URD through the CCSDS standard track (white, red, blue book)
2- Validate Data Link Security Protocol through interoperability testing of at least two independant implementations
3- Develop a Data Link Security Protocol green book containing : rationale, justification of the design, user manual, mission profiles, discussion of performance, choice of cryptographic algorithm(s)
4- Develop a Physical Layer Security Recommendation specifying anti-jamming technique
The protocol development will be performed in 2 stages : build-1 and build-2 :
- build 1 : core protocol, including : definition of formats specific to the security layer, state machines, operations concept, ...
- build 2 : protocol extension, including : specification of the application in charge of security protocol configuration : key management, security associations management, ... Survey of Similar Work Undertaken in Other BodiesNo standard security protocol available nor in development for the CCSDS communication stack. Patent Licensing Applicability for Future Standards
NA Technical Risk Mitigation StrategyUser Requirements for the protocol having been agreed among participating agencies before the start of the protocol development, this development should be relatively straightforward if agencies invest in the frame of the CCSDS group, with a view of using it for one of their future missions. Management Risk Mitigation StrategyNA |
| Space Link Services Area (SLS) |
Title of Group | 5.10 Optical Communications Working Group |
Chairperson | Jon Hamkins |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Clemens Heese |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of ActivityStandardization in the field of Optical Communications in space addressing:
• The physical layer, including modulation and link acquisition
• The coding, and synchronization sublayer of the Data Link Layer
• Ancillary information needed for optical communications, e.g. weather and atmospheric data
Coordination within the SLS area and within CCSDS for matters pertaining to optical communications will be conducted.
Rationale for ActivitySpace Agencies intend to extend their portfolio of interoperable space communications into the optical domain covering space-Earth and space-space links. Optical communications systems that have to operate through Earth’s atmosphere can be severely impacted. The result is that a typical spacecraft has to be supported by several optical communications ground stations to overcome atmospheric link outages. Standards for space-space links will allow the sharing of space assets, e.g. relay satellites.
This CCSDS Working Group will develop standards that can be applied by the space agencies for space optical communications interoperability and optical cross support.
GoalsFree space optical communications standards shall be developed only to the extent necessary to ensure interoperability and cross-support.
The working group will develop standards for the modulation, coding, interleaving, synchronization, and acquisition of optical communications signals. This working group will also define the physical parameters that should be collected and shared between ground stations via existing CCSDS cross support services.
The goals are listed hereafter.
1. Blue Book for Optical Communications Physical Layer for the scenarios High Photon Efficiency (HPE) and Low Complexity (LC)
2. Blue Book for Optical Communications Coding & Synchronization for the scenarios High Photon Efficiency (HPE) and Low Complexity (LC)
3. Green Book for Optical communications concepts and terminologies
4. Green Book for Real-Time Weather and Atmospheric Characterization Data
5. Green Book for optical communications physical layer and coding and synchronization sublayer
6. Magenta Book(s) for Real-Time Weather and Atmospheric Characterization Data
7. Orange Book(s) on Optical Communications Physical Layer and Coding & Synchronization for the scenario High Date Rate (HDR) .
Coordination with SLS-C&S and SLS-RFM for weather data needed for optical communication and VCM/ACM in the 26GHz band in order to prevent duplication of effort or incompatibilities in envisaged.
Moreover, depending on the techniques that will be standardized for low and high signal photon flux, the Working Group will analyze the need of a Magenta Book for Optical Communications Profiles.
Survey of Similar Work Undertaken in Other BodiesThe Optical Link Study Group performed a study and issued a report, which supports this standardization work.
There is no similar work undertaken in other bodies and relevant to CCSDS that the BOF members are aware of.
Patent Licensing Applicability for Future Standards
The current WG participants know of no limitations at this stage on usage of the planned technologies as far as patent restrictions or licensing requirements are concerned. Technical Risk Mitigation StrategyNo technical risks have been identified by the BOF at this stage.Management Risk Mitigation StrategyThe schedule is very dependent upon space agencies commitment of resources and on the success of several optical communications demonstration missions. |
| Space Internetworking Services Area (SIS) |
Title of Group | 6.08 Motion Imagery and Applications Working Group |
Chairperson | Falk Schiffner |
Chairperson E-Mail Address | |
Chairperson Agency | DLR |
Deputy Chairperson | Beth St. Peter |
Deputy E-Mail Address | |
Deputy Agency | ESA |
Mailing List | |
Scope of Activity This WG developed a Green Book (CCSDS 700.0-G-2) documenting the in-use architectures for spacecraft motion imagery and a Blue Book (CCSDS 766.1-B-1*) specifying standards for digital motion imagery transmission. Having completed those books, the WG will now examine the requirements for using the CCSDS Bundle Protocol (CCSDS 734.2-B-1) for streaming applications, including video.
Rationale for ActivityIn the early days of human spaceflight, motion imagery was accomplished with motion picture cameras, set at varying frame rates depending on lighting conditions. Upon safe return the film was processed and eventually shared with the world via documentaries or television. Inevitably live video became operationally desirable for situational awareness and to satisfy the public’s interest in high profile events such as the Moon landings or the Apollo-Soyuz test project. Compromises were made with those first video systems to fit within the constraints of bandwidth, avionics, and transmission systems. Even in the modern era, video systems on spacecraft are a hybrid of analog and digital systems, typically made to work within the spacecrafts avionics, telemetry and command/control systems.
With the advent of digital cameras, encoding algorithms and modulation techniques, it is desirable to treat video as data and utilize commercially available technologies to capture and transmit live and recorded motion imagery, possibly in high definition or even better.
Future Human Spaceflight endeavors are expected to be collaborations between many agencies, with complex interactions between spacecraft, and Lunar/Mars surface systems, with intermediate locations (EVA crew, habitats, etc.) requiring the ability to view video generated by another agency’s systems. Therefore interoperability between these systems will be essential to mission success and in some cases crew safety. Such interoperability will only be achieved by use of common references and joint agreement on international standards, either commercial or CCSDS or a combination of the two.
Representative issues to be addressed by this Working Group will include:
• Packetization of compressed and uncompressed data streams
• Metadata
• Embedded audio
• Command and control methodologies
• Compression standards and implementations
• Distribution formats
• Remote operations of space-based MIA systems
• Compatibility with avionics systems
• Common references and quality standards
GoalsThe Motion Imagery & Applications Working Group will develop a Green Book documenting the requirements for using the Bundle Protocol for CCSDS (CCSDS 734.2-B-1) to support streaming applications (including video and possibly voice), and documenting existing approaches to and results of using BP to support streaming. During this process the working group may identify additional follow-on work; if such work is identified the WG will propose further charter modifications and projects to carry out the work.
Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
<div>The MIA documents will include patented technology. However the research from the WG at this time gives us confidence that no programs from space agencies will have to pay any license fees. This is largely because the MIA documents will specify the usage of commercial hardware and software, and license fees apply to those manufacturers, not to end users. Additionally, as far as this WG can determine, the cited technologies are already standardized, and have been verified by ISO as Reasonable and Non Discriminatory (RAND). </div> Technical Risk Mitigation StrategyLow risk due to intent to utilize existing technologies and standards.
Possibility of technology surpassing or out-dating any documents produced.
Risk will be mitigated by referencing internationally recognized standards such as ISO, MPEG or Society of Motion Picture and Television Engineers vs. proprietary or commercial solutions or other unique applications of technologies.
Management Risk Mitigation StrategyLack of resources or Agency support.
The schedule outlined in this document is not so aggressive that WG members will be forced to choose between their other responsibilities and the group’s work. Further, much of the group’s work should be able to be accomplished electronically. Commitments to support the group’s objectives have been sought and obtained from other Agencies before pursuing working group status
|
| Space Internetworking Services Area (SIS) |
Title of Group | 6.09 Delay Tolerant Networking Working Group |
Chairperson | Robert Durst |
Chairperson E-Mail Address | |
Chairperson Agency | NASA |
Deputy Chairperson | Kiyohisa Suzuki |
Deputy E-Mail Address | |
Deputy Agency | JAXA |
Mailing List | |
Scope of ActivityStandardization of a space internetworking protocol capable of operating in environments with large and/or highly varying delays and disruptions caused by planned or unplanned link unavailability. Disruptions may partition the network so that there may be significant times when no end-to-end path exists. The internetworking protocol definition may include support for quality of service and streaming delivery mechanisms.
Standardization of supporting protocols and conventions such as link-layer reliability protocols, routing protocols, network management, a unified naming scheme, etc. In particular the network management work (here 'network' is interpreted as the internetworking layer and not NASA's interpretation of e.g. the DSN, NEN, etc.) will interact with other cross-support activities. Where appropriate the WG will work with the Cross Support Services Area to ensure a coherent system and to avoid duplication of effort.
Rationale for ActivityHistorically, lunar and planetary exploration spacecraft have been few in number and have communicated only with operations centers on Earth. Such communications have in effect been dedicated interplanetary communication circuits, established and configured by human operators. Recent experiences at Mars have shown that using orbiters to relay data from the surface can greatly increase science data return; similar benefits are expected in other locales such as around the moon. International cross-support for this relaying capability will increase mission robustness and science data return, allowing surface elements multiple opportunities to forward data to Earth. As the number of relays and relay users increases, the need to automate a standard data relay service will increase.
The familiar Internet network protocol model is not equal to this task, as it is not designed for effective operations over communication links characterized by very long signal propagation latencies, frequent and prolonged service interruptions, and limited and highly asymmetrical transmission rates. Something new will be needed.
In short, communication with and among a large and growing population of communicating entities (robotic sensors, for example) separated from Earth by interplanetary distances and/or by recurring lapses in mutual visibility due to orbital or planetary motion will require deployment of a store-and-forward communication network that is capable of providing reliable data delivery and dynamic routing in a fully automated fashion.
GoalsDTN-WG is a Standards Track Working Group. The Working Group will determine whether or not “Delay-Tolerant Networking” as specified in RFC5050 is a feasible solution for a store-and-forward networking protocol for space environments where data relay is likely.
If RFC5050 is deemed suitable overall but lacking in certain specific capabilities needed by the space community, this working group may define extensions to RFC5050 to address these needs. If RFC5050 is not suitable, the WG will attempt to define an alternate protocol that meets the needs of the space community.
RFC5050 requires a reliable data delivery service between overlay routers. While CCSDS has reliable data link protocols in TC and AOS, neither is well-suited for use as a convergence layer by RFC5050. It is likely that any Delay Tolerant Networking protocol proposed by this group will need reliability on a hop-by-hop basis. Thus this working group will also standardize a reliable hop-by-hop data delivery service that can be used by the Delay Tolerant Networking protocol specified by this WG. The Licklider Transport Protocol (LTP) as described in the work-in-progress http:// www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt was designed for exactly this purpose, and will be the initial focus of this part of the WG effort.
The WG will also develop a Pink Sheet for CFDP to specify additional mechanisms to be used when CFDP is used over BP (allow an acknowledgement that the file has been delivered when CFDP is used in unreliable mode).
This working group will also develop the Solar System Internetworking Architecture Document in response to the IOAG request to CCSDS. This document will be targeted as a Green or Magenta (under the proposed modified procedures) book.
The working group will develop a Green and a Blue Book related to network management of BP-based networks. The books will define the concepts (Green book) and protocols to effect network management of DTN networks.
Finally, the group will develop a Blue Book to standardize Quality of Service mechanisms and behaviors for CCSDS BP networks.
Per standard CCSDS procedure, development of this Recommended Practice will entail demonstration of mission operations in a prototypical DTN-based network environment.
Survey of Similar Work Undertaken in Other BodiesSee Technical Risk Mitigation Strategy below. Work on Delay / Disruption Tolerant Networking has been ongoing in the Internet Research Task Force (IRTF) and experimental protocols have been defined. Patent Licensing Applicability for Future Standards
<div>There is a US Patent "US 7,930,379 B2" http://<a href="http://www.freepatentsonline.com/7930379.html">www.freepatentsonline.com/7930379.html</a> that MAY be applicable to the Bundle Protocol.</div> Technical Risk Mitigation StrategyIt is believed that the DTN architecture and the DTN protocol as defined by the IETF are generally suitable for the CCSDS community. Where space-specific capabilities are needed, we believe that extensions to the base DTN protocol will be able to address the required functionalities. If the base DTN protocol as specified by the IETF is found to be unsuitable for space missions, development of a completely new protocol could be required and the schedule would slip, probably by a year.
A stable implementation (believed to be suitable for space mission operations) of a previous version of the DTN specifications exists. Slight modification of this version should bring it in line with the specification of RFC5050. Multiple other implementations of the DTN protocol exist, most not suitable for space mission operations. Resources have been identified to develop a second “space-qualifiable” DTN implementation if such is required. These facts argue that there is little technical risk in generating two interoperable implementations, provided that the protocol in RFC5050 is basically suitable.
Similarly, the LTP protocol described in http:// www.ietf.org/internet-drafts/draft-irtf-dtnrg-ltp-09.txt was designed specifically to be a reliable hop-by-hop transfer service for long-haul space links. As such, it should fulfill the requirements of the upper-layer DTN protocols. There is at least one LTP implementation that was designed for use on space missions. As part of the work program for recommending a reliable hop-by-hop delivery protocol, another implementation may need to be developed. Because there are multiple LTP implementations (though not necessarily designed for space mission operations), this should be a low-risk activity.
Management Risk Mitigation StrategyUnavailability of resources could delay achievement of milestones. Fallback option would be to reschedule the milestones. |
| Space Internetworking Services Area (SIS) |
Title of Group | 6.10 Voice Working Group |
Chairperson | Osvaldo Peinado |
Chairperson E-Mail Address | |
Chairperson Agency | German Aerospace Center (DLR) |
Deputy Chairperson | Ivan Antonov |
Deputy E-Mail Address | |
Deputy Agency | |
Mailing List | |
Scope of ActivityRationale for ActivityA major goal of CCSDS is to enhance interagency interoperability and cross-support, while also reducing risk, development time and project costs. Interoperability of mission voice communications is an enabler of mission success and mission safety.
Historically, mission voice communications within the various space agencies tend to reflect the technology and standards of the regional telecommunications industry. Though digital technologies have long supplanted analog technologies, there is a new wave of technological evolution in voice communications as disparate technologies converge, driven at least partially by the Internet and cellular phones.
Yet there remain significant interoperability issues. Even with current terrestrial technologies (e.g., 3rd generation cell phones, packet-switched networks and etc), there exist multiple boundary interfaces at which data conversion and transcoding must occur. Within large scale and high performance voice conferencing equipment, voice data must be decoded and processed in lossless digital waveform format to create the required high capacity conference loops, which then may be re-encoded for further transmission.
Voice communications with crewed vehicles was once the realm of analog RF communications and so long as participants shared common radio frequencies and modulation schemes interoperability was accomplished. Now voice is data encoded through lossy compression predictive algorithms, then multiplexed with telemetry/telecommand data, all of which may be wrapped in layers of transport headers, and finally modulated upon RF for transmission. Thus, in today’s digital world, voice interoperability among agencies can be an even greater challenge. As technologies converge there have appeared a growing number of interface boundaries.
As with the International Space Station, once a human spaceflight program is fully engaged, the magnitude of cost and schedule becomes ever clearer, and international participation is likely. Looking at three compelling future mission classes that face mankind, cost, schedule and even mission importance are drivers to international partnership. Consider:
• Moon outpost(s)
• Mars outpost(s)
• Rendezvous with a Near Earth Object (NEO)
Outposts are established goals, first on the Moon and then Mars. As current US and Chinese programs mature, cooperation may result, if not actual international participation. As lunar outposts mature the importance of science objectives increase, which provides further justification for international participation.
Rendezvous with a NEO may be a purely scientific mission to sample primordial material. However, a rendezvous may be warranted to alter the orbit of a NEO that would otherwise pass too near the Earth. (Asteroid Apophis will pass between the Earth and geo-synchronous satellites in 2029.)
There are six challenging domains as it concerns internationally interoperable mission voice communications:
• That among earthbound mission operations personnel at any number of agency, contractor, academia and private locations.
• That among space denizens, whether at an outpost in one or more structures, in single or multiple vehicles, suited and on EVA, at distance or nearby.
• That between space denizens and earthbound personnel, which includes mission operations and mission support personnel, private medical conferencing, public affairs, friends and family. At Martian distances, this will likely include recorded voice and voice to text technologies with associated metadata, using Delay / Disruption Tolerant Networking (DTN) technologies.• That between space denizens and earthbound personnel, or among space denizens, using low power emergency voice for use during a power shortage contingency.That to be used between space denizens for use during proximity and docking operations with a visiting crewed spacecraft approaching the ISS (ex. C2V2).• That between landed space denizens and earthbound personnel to be used for International Search and Rescue (SAR) operations during a contingency situation in which a returning space vehicle has landed in an unplanned location and has powered down onboard systems.
Regardless of whether exploration programs have initial requirements for cross-support between agencies, multiple manned programs in the Lunar or Mars environment will clearly require voice system compatibility for contingency or emergency operations. This work should enable that capability. GoalsThe Voice WG (V-WG) is a standards track working group that will produce:
• Green Book of Voice Communications for Human Spaceflight
• Magenta book of Voice Communications for Human Spaceflight
Through its assessment of current and emerging technologies of voice communications, the V-WG may choose to produce a later volume, Red/Blue Book of Mission Voice Communications if requirements dictate that a further evolution of standards is required to accommodate the needs of voice communications in support of human spaceflight. Survey of Similar Work Undertaken in Other BodiesPatent Licensing Applicability for Future Standards
<div>BLANK</div> Technical Risk Mitigation StrategyEvolving and converging technologies in the terrestrial voice communications result in solutions that may not be effective for human space missions. This is in fact a reason for which to begin a Voice Working Group - to mitigate this risk by forming an international team to evaluation and recommend a common set of solutions for voice communication during human space missions. In the unlikely event that no terrestrial voice communications can be adapted to support human space missions, the working group will propose development of recommended standards (Blue books) to address the missing capabilities as part of a rechartering activity. Management Risk Mitigation StrategyAvailability of resources that can contribute to the V-WG effort. As there are no current mission schedules dependent upon the delivery of products from this WG, milestones of this WG can be rescheduled. International participation. International participation is committed by NASA and, in the long term, ESA, although current mission obligations may affect immediate participation. |
| Space Internetworking Services Area (SIS) |
Title of Group | 6.12 CFDP Revisions Working Group |
Chairperson | Felix Flentge |
Chairperson E-Mail Address | |
Chairperson Agency | ESA |
Deputy Chairperson | Dai Stanton |
Deputy E-Mail Address | |
Deputy Agency | UKSA |
Mailing List | |
Scope of ActivityThe working group will accomplish the mandated 5-year reconfirmation review of the CCSDS File Delivery Protocol (CFDP) Blue Book. To this end, the working group will consider a number of proposed revisions to CFDP (listed below) and thereupon apply to the specification some agreed-upon subset of those revisions; will perform interoperability testing between two independently developed implementations of the changes incorporated into the revised CFDP Blue Book, to ensure that the revised specification can be successfully implemented; and will revise the three CFDP Green Books accordingly.
The following CFDP revisions have been proposed:
• Remove the Extended Procedures, which are unused.
• Relocate the Store and Forward Overlay User Operation (SFO) to a normative annex. (This could be a step toward eventually deprecating SFO in favor of operating CFDP over a Bundle Protocol unitdata transfer layer.)
• Provide a way of using CFDP to transfer files that are larger than 4 GB.
• Increase the maximum file data segment size, to reduce per-segment processing overhead.
• Add per-segment metadata to increase the utility of individually received file data segments prior to reassembly of an entire file.
• Enable file record boundaries to be encoded in file data segments, so that a record may span multiple segments or multiple records may be aggregated into a single segment.
• Define additional standard service classes that include different subsets of CFDP functionality.
• Add more Delivery Code values to make the Finished PDU more informative in proxy operations.
• Add the ability to aggregate the Finished information for multiple transactions into a single segment.
• Standardize the format for listing the contents of a remote directory.
In developing the agreed-upon revisions the working group will preserve backward compatibility with existing CFDP implementations to the extent possible.
Rationale for ActivityPublication CCSDS A02.1-Y-3, CCSDS Organization and Processes, requires that
Recommended Standards undergo reconfirmation review every five years; the current release of the CFDP specification (CCSDS 727.0-B-4) was published in January of 2007. Moreover, a number of revisions to CFDP have been proposed with the intent of making the specification more suitable for current and future space flight missions including the NASA Mars program and operations on the International Space Station.
GoalsThe goals of the CFDP Revisions Working Group are:
• Publish a new version of the CFDP Blue Book, incorporating an agreed-upon subset of the revisions proposed in the “Scope of Activity” above.
•As part of the Blue Book activity, document the results of interoperability testing of the revised CFDP Blue Book.
• Publish revised editions of the three CFDP Green Books, aligning them with the revised CFDP Blue Book.
Survey of Similar Work Undertaken in Other BodiesPink sheets for one CFDP revision – providing for the transmission of a “Finished” PDU on completion of a file transfer transaction in Unacknowledged mode – are being developed within the SIS Delay-Tolerant Networking Working Group. Development of this revision has been migrated into the proposed scope of work of the CFDP Revisions Working Group. No other revisions to CFDP, nor development of alternative space flight file transfer protocol specifications, are in progress elsewhere within CCSDS or within other known standards bodies. Patent Licensing Applicability for Future Standards
<div>There are NO known patent license issues. </div> Technical Risk Mitigation StrategyThe participating agencies were involved in the original development of CFDP and in its implementation. Their familiarity with the issues minimizes the likelihood of failure in developing the proposed revisions. Management Risk Mitigation StrategyResource estimates provided by the participating agencies ensure that sufficient technical resources will be applied to enable the CFDP Revisions Working Group to meet its goals. |