[Sea-sa] Brief minutes from SEA-SA RASDS working meeting on 14 Feb 22

Tue Feb 15 00:15:24 UTC 2022

SEA-SA RASDS working meeting on 14 Feb 22

Attendees: Krosley, Radulescu, Shames, Slane, Stangl

Review of open issues from 10 Jan 22 meeting – Peter Shames & team

  *   Fred mentioned that the SC14, as part of their considerations of how to leverage the SANA registry of terms, is now starting to more seriously consider the architecture aspects of their work and to find value in the RASDS++ work as a viable framework. That is excellent.
  *   We spent some time at the beginning of the session exploring the relationships between a purely “Enterprise” viewpoint (pg 15) and the relationships to the Functional and Connectivity viewpoints (pg 53).  We all agreed that including these diagrams was a real value, as will be the explanation of the relationships.  An updated pg 53, showing the “home viewpoints” of all these objects is included in the (slightly) revised 14 Feb 22 version, attached here.
  *   Ramon pointed out that there are solid correspondence relationships among these primary objects that we should leverage and describe.
  *   Reviewed the notes from 10 Jan relating to file “SEA SAWG RASDS Update Views 13Dec21” that was edited following the 10 Jan 22 meeting.
  *   We discussed the relationships between the “abstract” Enterprise views of “application” and “service” elements and the “realized” Functional and Connectivity views of “service”, “function”, and “system” elements.  And then we discussed the truly recursive nature of these relationships where the “abstract functions” from the Functional viewpoint are “realized” by the more concrete Connectivity and Physical views, and then, again, where these abstract component design views are turned into real, concrete, Components by the implementation processes.
  *   We also, briefly, discussed how this can be thought of as a recursive descent down the left hand side of the “Systems Engineering V”, followed by an ascent up the right hand side of the V as components are created, tested, assembled into modules, elements, integrated, tested and eventually launched and operated.  We may mention that in the RASDS, but will not be exploring it in any depth since it is a whole subject on its own.
  *   Touched upon, again, the need for a consistent set of terms that we can all agree upon and that have good provenance and alignment with common usage in our space operations domain.
  *   Fred asked “what does system mean”, relative to pg 51 and 53, and we used that to springboard into a look through the definitions of “system”, “Capability”, “Role”, “Actor”, and “Resource”.  Most of these terms are already defined in RASDS, but were not carried into this slide deck.  After review we determined that the RASDS definitions are fine as they are, so we will just reference them as they are in the future.
  *   We discussed the casual use of terms, as in “resource” or “actor” as opposed to a formalized definition.  On 10 Jan 22 we discussed capturing this distinction using bold or italics when it is a formal use as opposed to a casual one.
  *   Christian asked about adding some additional examples, in addition to the abstract object, definition, and representation aspects.  Peter pointed out that we did already have these for all of the viewpoints, but that they need to be reviewed.
  *   Fred asked about On Orbit Servicing (OOS) as an example.  Peter suggested that this might be a bit esoteric as a general example, since it is essentially a very important, but quite specialized, systems of systems example.  Ramon suggested we could treat this kind of “worked example” as a CCSDS Orange Book.  We could consider doing that, or find a way to create a “testimonial folder” containing info on worked examples using RASDS++.
  *   We then reviewed the items left from the 10 Jan 22 meeting
     *   Pg 17: Element may be used recursively, it may be a whole or a part of a larger whole.  “Element” is defined in RASDS, find it in the SANA Registry https://sanaregistry.org/r/terms.  Any definition from Doc 311.0-M-1 is RASDS.
     *   Pg 50: the term “Capability” may be defined as an “enterprise capability” in an Enterprise view or a “system capability” in a system view (Functional or Connectivity view).
     *   Pg 51: Christian asked if we should consider adding the term “Role” to this diagram.  The term “Role” is used as a few points in this deck, particularly in relationship to Enterprise VP, but it is not defined within this deck.  It is, however, defined in the existing RASDS terms as: “The way in which an entity participates in a relationship; an object’s set of behaviors and actions associated with the relationship of that object with other objects.”
     *   Pg 54: This list of viewpoints changes for SC14 uses the term(s) “space domain (physical, hardware, software) objects” and in this context the term “space domain”, with whatever qualifiers, means different aspects of some class of elements that are part of space enterprises, writ large.   The term “Space domain” is not in wide use, but space domain awareness is: “Space domain awareness is the study and monitoring of satellites orbiting the earth. It involves the detection, tracking, cataloging and identification of artificial objects, i.e. active/inactive satellites, spent rocket bodies, or fragmentation debris.”  We may want to find a different term, or to define it ourselves.  The current RASDS definition of “domain” is strictly in the Enterprise viewpoint and may be too narrow for current purposes.  Other CCSDS uses are more narrowly focused down in “protocol land”.  Should we retain this term, and define it, or drop it in terms of
     *   Pg 60: The term Role needs to be defined in the realm of Enterprise and “resources”, in the general sense of the word.  The definition identified in notes for pg 51 may suffice.
  *   Not discussed today, also from the 10 Jan 22 meeting:
     *   We agreed to be careful to distinguish examples from class definitions
     *   We agreed to carefully include ontology and representational diagrams for each viewpoint, but not to make this be a more dominant feature than that, such as including more formalized ontological definitions in OWL or some other representation
     *   We agreed to define, early in the doc, what we were doing and how we were doing it vis-à-vis ontologies
     *   Pg 64 & 65:   The operational view terms that were provided, derived largely from NIST, need to be carefully reviewed.  For instance, do we really need all three of “activity”, “task”, and “work”?  Would two of the three be enough?  What is the relationship of these operational / behavioral terms to Role and Resource?
     *   Pg 84: Are all “Connectors” in these Physical / Structural viewpoints really physical components, as opposed to the more abstract connections as in the Connectivity viewpoint?

Next Steps Discussion – Shames

  *   Peter made minor changes to the slides from 10 Jan 22
  *   That updated file is attached here.  Look specifically at pg 53, which was edited and re-colored to reflect the viewpoints where these various object types are defined.  Note: pg 63 still needs to be updated.
  *   Review assignments.  Each member of the team agreed to take responsibility for reviewing one viewpoint, and also one closely related viewpoint, for clarity, wording, definitions, and representational consistency

Next Working Meeting, 14 Mar 2022 @ 0700 AM PDT
Agenda:

  *   Briefly review these notes
  *   Christian: review updated diagrams, ontology, and representation approaches for Enterprise viewpoint and secondarily Functional viewpoint
  *   Fred: Review updated diagrams, ontology, and representation approaches for Operational viewpoint and secondarily Enterprise viewpoint
  *   Ramon: Review updated diagrams, ontology, and representation approaches for Physical viewpoint and secondarily Connectivity viewpoint
  *   Costin: Review updated diagrams, ontology, and representation approaches for Functional viewpoint and secondarily Operational viewpoint
  *   Peter: Review the entire package for consistency of topic coverage and presentation across all of the RASDS++ viewpoints

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20220215/e91b4273/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SEA SAWG RASDS Update Views 14Feb22.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 4784045 bytes
Desc: SEA SAWG RASDS Update Views 14Feb22.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20220215/e91b4273/attachment-0001.pptx>