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

[Robert Rovetto]

I have some preliminary input for the diagram entitled "rasds.onto.physical.v2captioned notes.pdf" after a cursory review...

Background FYI: A few months ago I previously offered some initial ontology development work I did for figure 2-8 in the RASDS Magenta Book. See the email archives.

(1) Some of the terms are highly generic and thereby may be too abstract for the specific sense and our specific context. Examples: View, Node, ...

Therefore, consider: 
(a) keeping such generality, or 
(b) qualifying the terms with additional words to better capture the intended meaning.
I personally suggestion the latter to more precisely capture the intended meaning. This will also create a future possibility of a potential nested structure whereby degrees of abstraction can be interconnected if desired.

(2) Shouldn't the Service class be related to the Concern class via the 'manages concern' relation? (rather than to the View class)
(3) Unclear why 'requires' is necessary as a relation between the Node class and the Service class. 
It may be more accurate to say that a stakeholder or a requirements document requires that a Node has a Service, rather than the Node itself. 
Ontologically (in the pure sense), one would examine what 'requires' would entail. 

(4) There are alternative ways to model the Interface section. The current subclasses may not need to be subclasses at all. Consider...
In OWL, the RequiredInterface can be defined as an Interface that has a particular status (e.g. 'required', 'provided') via the OWL Data Property construct.

Formalized approximately as:Required_Interface =def. Interface  has_status xsd:string 'required'
ProvidedInterface =def. Interface has_status xsd:string 'provided'
But...as mentioned above, one should expand what 'requires' and 'provided' entails. Presumably they mean (in a natural language form)...
Required interface =def. an interface that is required by a designated authority...Provided interface =def. an interface that is provided by a designated provider...
These definitions would then call for the formal assertion of the authority and provider and the relationships described.

(5) If I read the diagram correctly, it expresses that Voltage is a subclass of Concern, and likewise for DeltaV, et al. Similarly so for Power et al. for the View class.
Terminologically, this is inaccurate because of point (1), above.For example, voltage is electrical potential. This is a physical feature, aspect, etc. 
A concern, by contrast, is ontologically (in a pure sense) more of a psychological attitude held by persons. if we accept this, then it is a category mistake to say that Voltage is a subclass of Concern. 

In other terms, (if I remember correctly) the formal semantics in OWL for the subclass relation would have all instances of the Voltage class be instances of the Concern class. But according to the current diagram, is this so? 
It does not appear so because wouldn't an instance of voltage presumably be some physically-manifested electrical potential?...or that with a measurement thereof? Likewise fo the other subclasses. 

Therefore, that is why I suggested (1b): qualify the terms to more precisely capture the intended meaning. In this case, perhaps a more accurate phrasing for the class Voltage would be 'Voltage concern' et al.

Robert Rovetto
--Afford others the opportunity to succeed, learn and grow.
-
 Urgently searching for to work & study opportunities worldwide.
-
https://purl.org/space-ontologyNASA Datanauts Open Data Initiative.Research Affiliate,Centerfor Orbital Debris Education & Research.Education Committee, International Association for Ontology and its Applications.http://orcid.org/0000-0003-3835-7817    On Tuesday, May 25, 2021, 7:58:20 PM EDT, Shames, Peter M (US 312B) via SEA-SA <sea-sa at mailman.ccsds.org> wrote:  
 
  <!--#yiv8389542000 _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}#yiv8389542000 #yiv8389542000 p.yiv8389542000MsoNormal, #yiv8389542000 li.yiv8389542000MsoNormal, #yiv8389542000 div.yiv8389542000MsoNormal {margin:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8389542000 p.yiv8389542000MsoListParagraph, #yiv8389542000 li.yiv8389542000MsoListParagraph, #yiv8389542000 div.yiv8389542000MsoListParagraph {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv8389542000 span.yiv8389542000EmailStyle17 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv8389542000 .yiv8389542000MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv8389542000 div.yiv8389542000WordSection1 {}#yiv8389542000 _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {} _filtered {}#yiv8389542000 ol {margin-bottom:0in;}#yiv8389542000 ul {margin-bottom:0in;}-->
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 fromEdsger 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 spacedatasystems, 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 thesesame 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 thePhysical 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): “Aservice 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.
 
 
 
  
 _______________________________________________
SEA-SA mailing list
SEA-SA at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210526/fec159ad/attachment-0001.htm>