Skip Ribbon Commands
Skip to main content
SharePoint
Manage PermissionsManage Permissions
|
Version HistoryVersion History

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

Shames Peter (11/23/2015 3:50 PM): Change priorities to align with those agreed in CESG meeting on 13 Nov 2015

Shames Peter (8/31/2015 4:36 PM): Minor editorial changes prior to submission to CESG

CCSDS Tech Support (7/23/2015 9:24 PM):
CCSDS Tech Support (7/23/2015 9:22 PM):
CCSDS Tech Support (7/23/2015 9:22 PM):
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

Version:
Created at by
Last modified at by

Manage PermissionsManage Permissions
|
Version HistoryVersion History

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: Phased, initial cartoon version, using RASDS and based on SCCS-ADD, covering the applications domain and its relationship to CSS, SLS, SIS, and SEA; final more accurate one, after other work is done.
- 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
- Develop this with direct support from SOIS and MOIMS area experts
 
CCSDS Registries & Information Model
Approach: Analyze CCSDS registries and information models, develop a unified approach across all CCSDS working groups
- Registry management policy document derived from existing SCID and MACAO registries
- Extend registry model to define core, re-usable, registries for agencies & other organizations, identified persons (head of delegation / points of contact), assigned registry management roles
- other core registries for object identifiers (OID), URN, Schema
- CCSDS wide registry information model covering all of the major defined info / data objects and their relationships
 
Perform RASDS refresh, evaluate whether to use SysML/UML or not
Approach: Update and refresh RASDS
- Initial re-confirmation now for 2 years
- Work with ISO SC-14 to define needs for operational, physical, and service viewpoints
- Complete revision and update when 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
 

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. It builds upon work done in the SCCS-ARD & 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 they wish to 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
Last modified at by

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

 Approved Projects

|Export to Spreadsheet|
Currently 3 Projects     
Document Type
Project Status
Project Phase
Modified By
Registry Management PolicyYellowBehind ScheduleProject ApprovedSecretariat Proxy 
CCSDS Global Spacecraft Identifier Field: Code Assignment Control Procedures (Issue 7)MagentaBehind ScheduleProject not StartedSecretariat Proxy 
CCSDS Application & Support Architecture - Green BookGreenBehind ScheduleProject not StartedSecretariat Proxy