[Sea-sa] Brief notes from 25 May 2021 RASDS++ discussions

Tue May 25 23:56:46 UTC 2021

We held the second of three SEA-SA RASDS working meetings on 25 May 21

Attendees: Huang, Krosley, Radulescu, Shames

Review of Notes - Shames

  *   Briefly reviewed the notes from the 24 May 21 meeting
  *   No issues were identified
  *   The WG agree that the operational viewpoint descriptions and new terms were accurate and clear

RASDS++ Physical Viewpoint – Krosley

  *   Ramon presented the new Physical Viewpoint ontology which led to a lot of extremely useful discussions
  *   As with the new Operational Viewpoint, it is essential for any new terminology definitions and the assertions in the ontology to align correctly with existing terms.  Some adjustments were needed to what was initially offered.
  *   The ontology view addresses physical objects and their relationships (see attached view with proposed mark-ups).  It also aligns with the existing definitions of terms.
  *   No example of the new Physical Viewpoint has been provided, yet, but references were made to existing Connectivity Viewpoint diagrams and definition in the RASDS, as well as reference to the ISO 7498 (Basic Reference Model), the ISO 42010-2020 (the latest draft of the “Software, systems and enterprise — Architecture description” document), and to a document called COOKBOOK FOR MBSE WITH SYSML, published by the MBSE Challenge Team.
  *   Some adjustments to the diagram were made, after the fact, to better align with the rest of the RASDS method and terms, the revised version is attached.

  *   A concept to keep in mind when considering the following discussion, quoted from Edsger W. Dijkstra in the 42010 draft:
1118  Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one
1119  is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own
1120  consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know
1121  that a program must be correct and we can study it from that viewpoint only; we also know that it
1122  should be efficient and we can study its efficiency on another day, so to speak. In another mood we may
1123  ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the
1124  contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called “the
1125  separation of concerns”, which, even if not perfectly possible, is yet the only available technique for
1126  effective ordering of one's thoughts, that I know of. This is what I mean by “focussing one’s attention
1127  upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that
1128  from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded

     *    simultaneously.

  *   The particular issue that needed sorting out is the relationship of this new Physical Viewpoint to the existing RASDS Connectivity Viewpoint.
  *   Happily, the RASDS actually provided the “hooks” for this in the text we published in Sec 2.6, the Connectivity Viewpoint intro (emphasis added).
The Connectivity Viewpoint shows how space data systems are made up of physical elements that must operate in space, and the connections between elements, the physics of motion, and external environmental forces that must be considered. Some space data system elements are in motion through space. Consequently, connectivity issues associated with pointing, scheduling, long Round-Trip Light Times (RTLTs), and low signal-to-noise ratios require special protocols and functionality. The Connectivity Viewpoint Specification is used to address these aspects of space data systems, along with the interactions with the ‘fixed’ external world.

For analysis of complete space systems, other physical aspects, including the propulsion, power, thermal, and structural aspects associated with them, must be considered and represented in what might be called a Physical Viewpoint. However, for the description of space data systems, focus is on the Connectivity Viewpoint, where consideration is given to nodes, links, external forces, implementation of functionality as basic Engineering Objects (software or hardware), and other considerations related to the engineering of data system functionality and performance.

  *   So the hooks are in to provide a Physical Viewpoint that addresses these other physical aspects of Nodes and Links:
A Node is a configuration of hardware Engineering Objects forming a single unit for the purpose of location in space and embodying a set of processing, storage, and communication, propulsion, electrical, and other  functions. A Node represents a system entity (such as a spacecraft, a tracking system, or a control system) or an individual physical entity of a system (such as an instrument, a computer, or a piece of communications equipment). A Node may be composed of other Nodes. Each Node has one or more Ports where connections to other Nodes are made. For purposes of system analysis, people may also be modeled as Nodes that have functional responsibilities assigned to them.

  *   For the Physical Viewpoint we are concerned not with communications,  data flows, bits, and protocols, but with these same physical entities and how they connect in physical ways, using flows of physical energy or force.  These “connections” between the Nodes may involve flows of electro-magnetic force, of gravity, or thermal energy, or propulsive, rotational or kinetic energy.
  *   The approach that we believe will work within the current context is to leave the RASDS Connectivity Viewpoint as it is, aside from changing that phrase “represented in what might be called a Physical Viewpoint” to read “represented in what is called the Physical Viewpoint, see sec 2.nnn”, and to add this new Physical Viewpoint that Ramon sketched out.
  *   Ramon proposed an approach that caught me by surprise, but I think it works conceptually.  The attached diagram makes most of this clear.
     *   The Nodes in a Physical Viewpoint are the same physical Nodes, operating in the same sorts of physical environments,  as the Nodes in the Connectivity Viewpoint
     *   Each Node may be decomposed into lower level Nodes.
     *   There are no canonical names applied to this  Node decomposition, any project that uses this method may choose whatever names for the decomposition hierarchy that makes sense in their context.  A ‘top level” node could be a “Radio Component” or a “System of Systems”, depending.
     *   Each of the different kinds of physical connections will be treated as a different Aspect of the Physical Viewpoint
     *   “Aspect” is used casually in may docs, but it is defined in the new ISO 42010 – 2020 as this:
212  aspect
213  architecture aspect
214  typical characteristic or feature of one or more architectures (3.2)
215  EXAMPLE Functional and Structural aspects of an architecture.

     *   And …
387  By examining architecture aspects, relevant features or properties of the entity can be discerned or predicted.
388  Often multiple architecture aspects must be examined to determine how the architecture addresses a concern.

     *   We propose that the different kinds of physical connections will each be addressed in their own Aspect views, and the Connections may also be specialized to use terms like “magnetic fields”, “electro-magnetic radiation”, “gravitational field“, “propulsive force”, “thermal radiation”, etc.  In this way these different energetic affects can be addressed in their own relevant views, using their own terms, but all related through the fundamental Physical Viewpoint, the Nodes, and the set of different, specialized, Connections.
     *   The other consideration in this Viewpoint is that of Nodes providing Services, and of the nature of the “offered” and “provided” Interfaces of these Services.  This language derives from the ISO BRM, 7498, and it seemed a little out of place at first, but on reflection we think it may actually work.
     *   Service (RASDS): “A service is a provision of an interface of an object to support actions of another object.”   And “Any given Object may expose one or more Service Interfaces and provide one or more Core Functions. Through its External Interface, it may call upon other Objects to provide services to it. “
     *   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. “
     *   We think that a heat pump offers a service, as does a micro thruster, a battery, a solar cell, a launch vehicle, a spacecraft, an instrument.  We think they can be described in terms of “provided services” and that the users of these services can be described in terms of “required services”.  We also think that an “adapting shim” can be described when the provided and required service interfaces do not quite match.  An example of that is an adapter ring that mates a spacecraft to a launch vehicle.
     *   This may seem a little peculiar at first, but we believe it has a certain unifying quality that is worth considering.
     *   We will have more to say about this in following meetings where our SC14 colleagues can contribute to  the discussion.

Next Working Meeting, 26 May 21 @ 0700 AM PDT
Agenda:

  *   Briefly review these notes and the updated diagrams from Ramon
  *   Review the revised RASDS diagrams proposed for the document
  *   Start to review how these new Viewpoints 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/20210525/e0863e20/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rasds.onto.physical.v2.captioned notes.pdf
Type: application/pdf
Size: 157994 bytes
Desc: rasds.onto.physical.v2.captioned notes.pdf
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210525/e0863e20/attachment-0002.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MBSE2PracticesAndGuidelines Cookbook with SysML.pdf
Type: application/pdf
Size: 16195132 bytes
Desc: MBSE2PracticesAndGuidelines Cookbook with SysML.pdf
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210525/e0863e20/attachment-0003.pdf>