[Sea-sa] Brief meeting notes from SEA-SA RASDS meeting on 26 May 2021

[Shames, Peter M (US 312B)]

We held the third of three SEA-SA RASDS working meetings on 26 May 21

Attendees: Huang, Krosley, Radulescu, Shames

Review of Notes - Shames

  *   Briefly reviewed the notes from the 25 May 21 meeting
  *   No additional issues, other than the ones discussed on 25 May, were identified with the Physical Viewpoint materials that Ramon had presented
  *   The WG agreed that the Physical Viewpoint descriptions and new terms, as modified, were sufficiently accurate and clear
  *   After review of the ISO 42010 definition for “aspect”, and the newly defined relationships (in the 2020 version), among aspect, architecture concerns, and  stakeholder perspective (fig 4) the WG agreed that the proposed approach of referring to these different Physical VP aspects of the same set of Nodes was acceptable and appropriate.

RASDS++ Presentation Set – Shames

  *   The updates to the RASDS++ presentation set were briefly reviewed.  These included the new (scribbled on) Physical VP ontology diagrams from Ramon and the new Operations VP diagrams from Costin.
  *   These two sets of diagrams were both produced using the Protégé ontology modeling tool, and using the OWL language to capture the models.  What we noticed is that the representations that were used were somewhat different, and that some were more appealing, for various reasons, than others.
  *   What I think we want are these features in the presentation:
     *   “Clean” graphics with a minimum of “clutter” and yet clear information
     *   Easy to  read labels on the objects
     *   Clear labels on the relationships among objects and “connectors” between objects that express those relationships
     *   The option to apply colors to objects if that is useful
     *   The ability to display definitions of objects where that is useful
     *   The ability to eliminate the OWL root object, “Thing”, from which all other objects descend … it clutters up the diagrams.
  *   We discussed the several tools that we know about: OWL-viz, Onto-Graph, and web-based tool called WebVOWL.  There may be others.
  *   Action Item: Costin will evaluate these tools, and others, and propose an approach that we will use consistently across all of the viewpoints
  *   Magic Draw and other SysML tools like System Architect are other possible sources for Ontology definition and presentation.
  *   We will also consider using the ISO 42010 style abstract models for represent our concepts.  These tend to be simple, but clear, diagrams that have a lot of these features.

  *   We had a lengthy  discussion about the definition of “Service”, which appeared in the Physical Viewpoint ontology.
  *   The selected definition that had been included in the draft terminology set came from the ASL document, because it had been the most recently published, and therefore was likely to be the “best”.  It’s not.  That definition is this:
     *   Service (ASL): “A set of capabilities that a component provides to another component via an interface. A service is defined in terms of the set of operations that can be invoked and performed through the service interface. Service specifications define the capabilities, behavior, and external interfaces, but do not define the implementation. “
  *   The problem that we have is that we believe that “capability” is a rather high level, generalized, term describing what an organization wants, or needs, to achieve, and that service (and the functions that offer service interfaces) is a more specific and focused term that implies an actual implementation.   This “service is a set of capabilities” definition inverts that sense, hence the issue.
  *   We think we should either adopt the more straightforward RASDS definition “A service is a provision of an interface of an object to support actions of another object.” Or change “capabilities” in that ASL definition to “functions”. Simple word change, big change in conceptual clarity and consistency.
  *   This definition was marked as  coming from RASDS, but that is erroneous.  And it appears to be derived from the SM&C  MAL, and from CSS services, and before that, from the ISO Baric Reference Model (BRM) that predated the existed of services, Service Architectures, Web Services, and the like.  We are now pursuing the fix for this.
  *   Action Item: Peter will update the PPT materials to reflect the outcome of these meetings and include new diagrams for the two new viewpoints.
RASDS Document Update planning – Shames

  *   We reviewed parts of the RASDS document and discussed how we might  tackle some thorny issues.  This was a follow-on to the discussion from 25 May 21 where we looked at the issue of  how to relate the existing Connectivity VP and the new Physical VP.
  *   In the case of the Physical VP we agreed to leave the Connectivity VP as it is except to point to the Physical VP as another “owner” of Nodes and a provider of other physical attributes.
  *   One of the challenges in providing support for TC20/SC14 is how to handle their desire to reference the ISO SE Life Cycle Processes Standard 15288 and the new NASA SPACE MISSION ARCHITECTURE FRAMEWORK (SMAF) HANDBOOK FOR UNCREWED SPACE MISSIONS, NASA-HDBK-1005.
  *   ISO 15288 is what its name says, a document describing lifecycle processes such as planning, project control, risk management, CM, and information management, and also technical processes such as architecture, design, engineering, implementation, V&V.  Each of these is covered by a one or two page process description.  This is intended to be tailored and expended into individual processes within a project that adopts them.  We propose referencing ISO 15288 in the Enterprise VP, including the list of subject headings, and recommending that the project review, tailor, and utilize it as needed.  This also fits into situations where systems are acquired, rather than built, by an organization.
  *   NASA-HDBK-1005 is intended to “provide guidance for establishing a mission architecture as part of an acquisition framework”.  This document uses ISO 42010 terminology, such as viewpoint, view, stakeholder, and concerns, but its views are primarily process and mission development timeline and process/product focused rather than being useful for describing technical architectures.  It does provide what may be a useful mission system abstraction (fig 14).  As such we think it  is best handled as a reference within the Enterprise VP for NASA and other missions who wish to consult it.

Next Working Meeting, 14 June 21 @ 0700 AM PDT
Agenda:

  *   Briefly review these notes and the updated diagrams and representation approach from Costin
  *   Review the revised RASDS diagrams in the edited PPT file proposed for the document
  *   Continue  to review how these new Viewpoints and concerns can be merged into the existing text in the RASDS document.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210528/c7ecea58/attachment-0001.htm>