PS -0 System Architecture Working Group RASDS Status 14 June 2006 Peter Shames NASA / JPL

PS June 2006 Goals for Rome meeting Reach closure on disposition of review comments Determine if any of the review comments requires significant effort to resolve Finalize document content for agency review GOING-IN POSITION

PS June 2006 RASDS OVERVIEW Review feedback from reviewers CESG External reviewers: Villemos / ESA, Vallecillo / ISO/JTC1/WG19 Other feedback from early users: NASA ECANS, JPL JIMO, JPL DSMS architecture Agree on disposition of reviewer comments Develop approach for revised document for agency review Discuss issue of Magenta “boilerplate” SIS AD Feedback Discuss future of this work within CCSDS New BoF for formal architecture description Alignment w/ SysML and ISO/JTC1/WG19 UML4ODP Resolve issues w/ RM-ODP, RASDS & DODAF

PS June 2006 Review what happened in Atlanta, Fall 2005 Reviewed document within SAWG, with ISO/OMG expert support Dealt with CESG requests re Magenta Book & content Agreed on next set of changes to deal with issues and make needed extensions Review what has happened since Doc updated derived from use in CCSDS and missions Included feedback from ISO RM-ODP experts Clarified use of correspondences/representations across Viewpoints - Info objects in Information Viewpoint have representations in Functional, Connectivity and Enterprise Viewpoints - Functional Objects have Corrsepondences to Engineering Objects in Connectivity Viewpoint (H/W & S/W) Added ontology overview and additional cross-viewpoint discussion and diagrams Clarified allowable elements and relationships in each Viewpoint Document submitted for CESG concurrence prior to release for agency review RASDS STATUS

PS June 2006 RASDS STATUS, contd CESG vote was: ABSTAIN: 1 (12.5%) (Gerner) APPROVE UNCONDITIONALLY`: 5 (62.5%) (Lapaian, Peccia, Shames, Moury, Plancke) APPROVE WITH CONDITIONS: 2 (25%) (Durst, Hooke) DISAPPROVE WITH COMMENT: 0 (0%) Total Respondents: 8 Reviewing feedback from CESG and external reviewers. Other inputs from Yamada-san re RM- ODP and DoDAF are also being reviewed. Feedback from early mission users of RASDS has been solicited, most of it is favorable and users report that it provides capabilities that DoDAF does not have.

PS June 2006 Review issues: At CCSDS level - Approval at CESG with minor issues, but … - Agreed status of RASDS Magenta Book, i.e. “should be used by CCSDS for development of standards” or “may be used by WG if they wish”, see later slides - Format of Magenta Book standard boilerplate - Additional specification of attributes on objects - References to transition from conceptual representation to formal one, i.e. UML, SysML - Inclusion of other elements re DoDAF, RM-ODP, UML / SysML - Specification of service interfaces, adoption of RM-ODP ‘binding” specification Preparation for Rome - Solicited inputs from early adopters of RASDS and from experts in the system and software architecture domain - Feedback from external US and international colleagues has been generally very favorable ISSUES

PS June 2006 Specification of Attributes All RASDS objects and links have attributes We have not specified these in any detail in the current revision SIS AD specifically asked for attributes in Connectivity and Communications diagrams Desire to have more analytical elements in representation Concern about consistent level of abstraction across viewpoints Requested SIS AD to suggest what attributes would be useful in annotating protocol descriptions E.g. congestion control Behavioral specifications We could provide a representative set of attributes for all objects and links in all views => Gert to develop draft attribute set and to request making it available as an example for inclusion in an appendix

PS June 2006 Service Specification Feedback from ESA that they found use for the RM-ODP channel and binding concepts in service interface definition Provides a level of implementation detail that is now missing RM-ODP approach is an abstraction of CORBA style interactions May wish to find a more implementation neutral approach that handles client / server, peer - peer, and SOA style abstractions This is more effort and will further delay release of the document for external review

PS June 2006 Magenta Book Boilerplate Hooke version - 11 Apr 06 CCSDS Recommendations take two forms: Recommended Standards that are prescriptive and are the formal vehicles by which CCSDS Agencies create the standards that specify how elements of their space mission support infrastructure shall operate and interoperate with others; and Recommended Practices that are more descriptive in nature and are intended to provide general guidance about how to approach a particular problem associated with space mission support. Shames version - 11 Apr 06 CCSDS Recommendations take two forms: Recommended Standards that are prescriptive and are the formal vehicles by which CCSDS Agencies create the standards that specify how elements of their space mission support infrastructure shall operate and interoperate with others; and Recommended Practices that are prescriptive but not binding on CCSDS member agencies, and are intended to provide general guidance about how to approach a particular problem associated with space mission support.

PS June 2006 RASDS Applicability Statement 1.3 Applicability (RASDS original version) The methodology described in this recommended practice document should be used for the description of all data system architectures in any relevant CCSDS documents. The Viewpoint Specifications and representational methodologies may be used where applicable, but only those Viewpoints that are needed for the specific purpose need to be utilized. Not all Viewpoints are needed for every task. In many instances only the Functional and Connectivity Viewpoints will be needed. The methodology described in this document may be used in the description of other space data system architectures, but its use is not required. 1.3 Applicability (Hooke version, 11 Apr 06) The methodology described in this recommended practice document may be used by individual working groups for the description of all data system architectures in any relevant CCSDS documents. However, there is no general requirement that all CCSDS architectures must be expressed in RASDS-compliant notation. The use of RASDS is therefore completely voluntary and it is assumed that individual working groups who are looking for guidance or good engineering practice will find it useful. The Viewpoint Specifications and representational methodologies may be used where applicable, but only those Viewpoints that are needed for the specific purpose should be utilized. Not all Viewpoints are needed for every task. In many instances only the Functional and Connectivity Viewpoints mayl be needed. The methodology described in this document may be used in the description of other space data system architectures, but its use is not required.

PS June 2006 Summary Disposition of RIDs Boilerplate: accede to CESG request Attributes: in sec 4-8 add example attributes to object and relationship types by VP Service Viewpoint: show three layer diagram from Gert w/ mapping from services to protocols UML / SysML, DoDAF: add Appendix showing RASDS / DoDAF mapping (TY), add appendix showing RASDS / SysML mapping Definitions: obj_role (i.e. client/server), pattern (MEP), behavior (relate to UML diag) ODP Stubs / Bindings: consider whether to add a section to Comm VP to include this topic, AMS only space topic RD? Planned release date: end of July Identify any more work that needs to be done Determine if there is interest and agency resources to establish new BoF for architecture formalisms Determine proposed scope of effort - SysML - UML4ODP - DoDAF

PS June 2006 BACKUP