Charters - 1.01 System Architecture Working Group

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	Brian Oliver (3/18/2021 12:12 PM): Revised to reflect the start of RASDS refresh work, the inclusion of the SCCS-ARD/ADD that has been "adopted" from the CSS area, and the active role that TC20/SC14 expects to play in the RASDS and ontology revisions. 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

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