Name of Group
Short Name
Area
Chairperson
Chairperson E-Mail Address
Chairperson Agency
Deputy Chairperson
Deputy Chairperson E-Mail Address
Deputy Chairperson Agency
Mailing List
Scope of Activity
Rationale for Activity
Goals
Survey of Similar Standards Efforts Undertaken in Other Bodies and elsewhere in CCSDS
Patent Licensing Applicability for Future Standards
Technical Risk Mitigation Strategy
Management Risk Mitigation Strategy
Description of Change
CCSDS Tech Support (7/23/2015 9:21 PM):
CCSDS Tech Support (7/23/2015 9:21 PM):
CCSDS Tech Support (7/23/2015 9:15 PM):
Disable Alert
Area Director E-Mail Address
Deputy Area Director E-Mail Address
Create Poll
CC Yourself
Completed/Closed
Approval Status
Attachments

Name of Group

1.01 System Architecture Working Group

Area

Systems Engineering Area (SEA)

Chairperson

Peter Shames

Chairperson E-Mail Address

peter.m.shames@jpl.nasa.gov

Chairperson Agency

NASA/JPL

Deputy Chairperson

TBD

Deputy Chairperson E-Mail Address

TBD

Deputy Chairperson Agency

TBD

Mailing List

sea-sa@mailman.ccsds.org

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 neeeded.
- CCSDS wide registry information model covering all of the major defined info / data objects and their relationships
 
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 specificatioons based on user experience and feedback, as well as ASL ADD developed extentions\
- Include Annex for UML / SysML representation that uses the core methodology, consider Annex to rescribe 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 Activity

The 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.

Goals

Goals:
- 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 are reform the existing XML specs to make them more usable

Survey of Similar Standards Efforts Undertaken in
Other Bodies and elsewhere in CCSDS

The 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

None of this work is licensed or has patent issues.
 

Technical Risk Mitigation Strategy

There are no known technical risks, the technology is quite well understood.

Management Risk Mitigation Strategy

The 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.
Version:
Created at by

Note - To view "Draft" projects, which are not yet approved Click Here.

 Approved Projects

|Export to Spreadsheet|
Currently 5 Projects     
Document Type
Project Status
Project Phase
Modified By
Space Communication Cross Support Architecture Requirements Document, version 2MagentaBehind ScheduleProject ApprovedTom Gannett 
Registry Management PolicyYellowAll Tasks CompletedProject CompletedBrian Oliver 
CCSDS Global Spacecraft Identifier Field: Code Assignment Control Procedures (Issue 7)MagentaAll Tasks CompletedProject CompletedTom Gannett 
CCSDS Application & Support Architecture - Green BookGreenAll Tasks CompletedProject CompletedBrian Oliver 
Reference Architecture for Space Data Systems (RASDS), revision 2MagentaBehind ScheduleProject not StartedBrian Oliver