<html><head></head><body><div class="ydpf0f1e671yahoo-style-wrap" style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-size: 13px;"><div><div dir="ltr" data-setdir="false">I have some preliminary input for the diagram entitled "<span>rasds.onto.physical.v2captioned notes.pdf"</span> after a cursory review...<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">(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, ...<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Therefore, consider: <br></div><div dir="ltr" data-setdir="false">(a) keeping such generality, or <br></div><div dir="ltr" data-setdir="false">(b) qualifying the terms with additional words to better capture the intended meaning.<br></div><div dir="ltr" data-setdir="false">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.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">(2) Shouldn't the Service class be related to the Concern class via the 'manages concern' relation? (rather than to the View class)</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">(3) Unclear why 'requires' is necessary as a relation between the Node class and the Service class. <br></div><div dir="ltr" data-setdir="false">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. <br></div><div dir="ltr" data-setdir="false">Ontologically (in the pure sense), one would examine what 'requires' would entail. <br></div><div><br></div><div dir="ltr" data-setdir="false">(4) There are alternative ways to model the Interface section. The current subclasses may not need to be subclasses at all. Consider...</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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.<br></div><div class="ydpf0f1e671signature"><div style="font-size:13px;font-family:Helvetica, Arial, sans-serif;"><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Formalized approximately as:</div><div dir="ltr" data-setdir="false">Required_Interface =def. Interface has_status xsd:string 'required'<br></div><div dir="ltr" data-setdir="false">ProvidedInterface =def. Interface has_status xsd:string 'provided'</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">But...as mentioned above, one should expand what 'requires' and 'provided' entails. Presumably they mean (in a natural language form)...</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Required interface =def. an interface that is required by a designated authority...</div><div dir="ltr" data-setdir="false">Provided interface =def. an interface that is provided by a designated provider...</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">These definitions would then call for the formal assertion of the authority and provider and the relationships described.<br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">(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.</div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">Terminologically, this is inaccurate because of point (1), above.</div><div dir="ltr" data-setdir="false">For example, voltage is electrical potential. This is a physical feature, aspect, etc. <br></div><div dir="ltr" data-setdir="false">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. <br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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? <br></div><div dir="ltr" data-setdir="false">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. <br></div><div dir="ltr" data-setdir="false"><br></div><div dir="ltr" data-setdir="false">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.<br></div><div dir="ltr" data-setdir="false"><br></div><div><div class="ydp10393cf1gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Robert <font size="2">Rovetto</font><br><div>--</div><div dir="ltr"><i>Afford others the opportunity to succeed, learn and grow.<br></i></div><div>-<br></div></div><div dir="ltr"><div dir="ltr" data-setdir="false"><font size="2"><span><span><span></span></span></span><span></span></font><span style="font-size:16px;"><span></span><span></span><font style="background-color: inherit;" size="2"><i><span></span></i></font></span><span style="font-size:16px;"> <span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span><span><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span>Urgently searching for to work & study opportunities worldwide<span><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><i><span>.</span></i></font></span></span></span></span></span></i></font></span></span></span></span><br></span></i></font></span></span></span></div><div dir="ltr" data-setdir="false">-<span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span><span><br></span></span></span></font></span></span></span><div><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span><span><a href="https://purl.org/space-ontology" rel="nofollow" target="_blank">https://purl.org/space-ontology</a></span></span></span></font></span></span></span></div></div><div><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span><span><a href="https://open.nasa.gov/blog/welcome-datanauts-2017-spring-class/" rel="nofollow" target="_blank">NASA Datanauts Open Data Initiative</a>.</span><span></span></span></span><span></span></font></span></span></span></div><div dir="ltr"><span style="font-size:16px;"><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span></font></span></span></span></div><span style="font-size:16px;"><span><span style="font-size:16px;"><div><div><font size="2"><span></span><span><a href="http://www.coder.umd.edu/node/287" rel="nofollow" target="_blank">Research Affiliate</a>,
<a href="http://www.coder.umd.edu/research-affiliates" rel="nofollow" target="_blank">Center
for Orbital Debris Education & Research.</a></span></font></div><div><div><font size="2"><span><span><span>Education Committee, International Association for Ontology and its Applications.</span></span></span></font></div><div dir="ltr" data-setdir="false"><font size="2"><span><span><span><a href="http://orcid.org/0000-0003-3835-7817" rel="nofollow" target="_blank">http://orcid.org/0000-0003-3835-7817</a></span></span></span></font></div><span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span><span></span></span></font></span></span></div></div></span></span></span><div dir="ltr"><span></span></div><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span></font></span><span style="font-size:16px;"><font style="background-color: inherit;" size="2"><span></span><span></span><span></span><span></span><span></span><span></span></font></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div><div id="yahoo_quoted_2951586808" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Tuesday, May 25, 2021, 7:58:20 PM EDT, Shames, Peter M (US 312B) via SEA-SA <sea-sa@mailman.ccsds.org> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div id="yiv8389542000">
<style><!--
#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;}
--></style>
<div>
<div class="yiv8389542000WordSection1">
<p class="yiv8389542000MsoNormal"><b><span style="color:black;">We held the second of three SEA-SA RASDS working meetings on 25 May 21</span></b></p>
<p class="yiv8389542000MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv8389542000MsoNormal"><span style="color:black;">Attendees: Huang, Krosley, Radulescu, Shames</span></p>
<p class="yiv8389542000MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv8389542000MsoNormal"><u><span style="color:black;">Review of Notes - Shames</span></u></p>
<ul style="margin-top:0in;" type="disc">
<li class="yiv8389542000MsoNormal" style="color:black;">Briefly reviewed the notes from the 24 May 21 meeting</li><li class="yiv8389542000MsoNormal" style="color:black;">No issues were identified</li><li class="yiv8389542000MsoNormal" style="color:black;">The WG agree that the operational viewpoint descriptions and new terms were accurate and clear</li></ul>
<p class="yiv8389542000MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv8389542000MsoNormal"><u><span style="color:black;">RASDS++ Physical Viewpoint – Krosley</span></u></p>
<ul style="margin-top:0in;" type="disc">
<li class="yiv8389542000MsoNormal" style="color:black;">Ramon presented the new Physical Viewpoint ontology which led to a lot of extremely useful discussions</li><li class="yiv8389542000MsoNormal" style="color:black;">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.</li><li class="yiv8389542000MsoNormal" style="color:black;">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.</li><li class="yiv8389542000MsoNormal" style="color:black;">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.</li><li class="yiv8389542000MsoNormal" style="color:black;">Some adjustments to the diagram were made, after the fact,<i> </i>to better align with the rest of the RASDS method and terms, the revised version is attached.</li></ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;"><span style="color:black;"> </span></p>
<ul style="margin-top:0in;" type="disc">
<li class="yiv8389542000MsoNormal" style="color:black;">A concept to keep in mind when considering the following discussion, quoted from
<span style="font-family:serif;color:windowtext;">Edsger W. Dijkstra in the 42010 draft</span>:
</li></ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#49AAC4;">1118</span><span style="font-size:8.0pt;font-family:serif;color:#2E75B6;"> </span><span style="font-family:serif;color:#2E75B6;">Let
me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1119 </span><span style="font-family:serif;color:#2E75B6;">is
willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1120 </span><span style="font-family:serif;color:#2E75B6;">consistency,
all the time knowing that one is occupying oneself only with one of the aspects. We know
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1121 </span><span style="font-family:serif;color:#2E75B6;">that
a program must be correct and we can study it from that viewpoint only; we also know that it
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1122 </span><span style="font-family:serif;color:#2E75B6;">should
be efficient and we can study its efficiency on another day, so to speak. In another mood we may
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1123 </span><span style="font-family:serif;color:#2E75B6;">ask
ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1124 </span><span style="font-family:serif;color:#2E75B6;">contrary!—by
tackling these various aspects simultaneously. It is what I sometimes have called “the
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1125 </span><span style="font-family:serif;color:#2E75B6;">separation
of concerns”, which, even if not perfectly possible, is yet the only available technique for
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1126 </span><span style="font-family:serif;color:#2E75B6;">effective
ordering of one's thoughts, that I know of. This is what I mean by “focussing one’s attention
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1127 </span><span style="font-family:serif;color:#2E75B6;">upon
some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">1128 </span><span style="font-family:serif;color:#2E75B6;">from
this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded
</span><span style="color:#2E75B6;"></span></p>
<ul type="disc">
<ol type="1" start="1129">
<li class="yiv8389542000MsoListParagraph" style="color:#5B9BD5;"><span style="font-size:8.0pt;font-family:serif;color:#2E75B6;"><span style="color:windowtext;"> </span></span><span style="font-family:serif;color:#2E75B6;"><span style="color:windowtext;">simultaneously.
</span></span><span style="color:#2E75B6;"></span></li></ol>
</ul>
<ul type="disc">
<li class="yiv8389542000MsoListParagraph" style="color:black;">The particular issue that needed sorting out is the relationship of this new Physical Viewpoint to the existing RASDS Connectivity Viewpoint.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Happily, the RASDS actually provided the “hooks” for this in the text we published in Sec 2.6, the Connectivity Viewpoint intro (<i>emphasis added</i>).</li></ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;"><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">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. </span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;"><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;"> </span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;"><i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">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.
</span></i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">However, for the description of space
</span><i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">data
</span></i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">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.
</span><span style="color:#2E75B6;"></span></p>
<ul type="disc">
<li class="yiv8389542000MsoListParagraph" style="color:black;">So the hooks are in to provide a Physical Viewpoint that addresses these other physical aspects of Nodes and Links:</li></ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.5in;"><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">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,
<s>and</s> communication, </span><span style="font-size:12.0pt;font-family:serif;color:red;">propulsion, electrical, and other </span><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;">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.
</span><span style="color:#2E75B6;"></span></p>
<ul type="disc">
<li class="yiv8389542000MsoListParagraph" style="color:black;">For the Physical Viewpoint we are concerned not with communications, data flows, bits, and protocols, but with these
<b><i>same physical entities</i></b> 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. </li><li class="yiv8389542000MsoListParagraph" style="color:black;">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 “<i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;"><span style="color:windowtext;">represented
in what might be called a Physical Viewpoint</span></span></i>” to read “<i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;"><span style="color:windowtext;">represented
in what </span></span></i><i><span style="font-size:12.0pt;font-family:serif;color:red;">is called the
</span></i><i><span style="font-size:12.0pt;font-family:serif;color:#2E75B6;"><span style="color:windowtext;">Physical Viewpoint</span></span></i><i><span style="font-size:12.0pt;font-family:serif;color:red;">,
see sec 2.nnn</span></i>”, and to add this new Physical Viewpoint that Ramon sketched out.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Ramon proposed an approach that caught me by surprise, but I think it works conceptually. The attached diagram makes most of this clear.
<ul type="circle">
<li class="yiv8389542000MsoListParagraph" style="color:black;">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</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Each Node may be decomposed into lower level Nodes.
</li><li class="yiv8389542000MsoListParagraph" style="color:black;">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.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Each of the different kinds of physical connections will be treated as a different Aspect of the Physical Viewpoint</li><li class="yiv8389542000MsoListParagraph" style="color:black;">“Aspect” is used casually in may docs, but it is defined in the new ISO 42010 – 2020 as this:</li></ul>
</li></ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">212 </span><b><span style="font-family:serif;color:#2E75B6;">aspect
</span></b><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">213 </span><b><span style="font-family:serif;color:#2E75B6;">architecture
aspect </span></b><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">214 </span><span style="font-family:serif;color:#2E75B6;">typical
characteristic or feature of one or more architectures (3.2) </span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">215 </span><span style="font-size:10.0pt;font-family:serif;color:#2E75B6;">EXAMPLE
Functional and Structural aspects of an architecture. </span></p>
<ul type="disc">
<ul type="circle">
<li class="yiv8389542000MsoListParagraph" style="color:black;">And …</li></ul>
</ul>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">387 </span><span style="font-family:serif;color:#2E75B6;">By
examining architecture aspects, relevant features or properties of the entity can be discerned or predicted.
</span><span style="color:#2E75B6;"></span></p>
<p class="yiv8389542000MsoNormal" style="margin-left:.75in;">
<span style="font-size:8.0pt;font-family:serif;color:#2E75B6;">388 </span><span style="font-family:serif;color:#2E75B6;">Often
multiple architecture aspects must be examined to determine how the architecture addresses a concern.
</span><span style="color:#2E75B6;"></span></p>
<ul type="disc">
<ul type="circle">
<li class="yiv8389542000MsoListParagraph" style="color:black;">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.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">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.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Service (RASDS): “A
<b>service </b>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. “</li><li class="yiv8389542000MsoListParagraph" style="color:black;">Service (ASL):
<b>“</b>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. “</li><li class="yiv8389542000MsoListParagraph" style="color:black;">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. </li><li class="yiv8389542000MsoListParagraph" style="color:black;">This may seem a little peculiar at first, but we believe it has a certain unifying quality that is worth considering.</li><li class="yiv8389542000MsoListParagraph" style="color:black;">We will have more to say about this in following meetings where our SC14 colleagues can contribute to the discussion.</li></ul>
</ul>
<p class="yiv8389542000MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv8389542000MsoNormal"><span style="color:black;">Next Working Meeting, 26 May 21 @ 0700 AM PDT</span></p>
<p class="yiv8389542000MsoNormal"><span style="color:black;">Agenda:</span></p>
<ul style="margin-top:0in;" type="disc">
<li class="yiv8389542000MsoNormal" style="color:black;">Briefly review these notes and the updated diagrams from Ramon</li><li class="yiv8389542000MsoNormal" style="color:black;">Review the revised RASDS diagrams proposed for the document</li><li class="yiv8389542000MsoNormal" style="color:black;">Start to review how these new Viewpoints can be merged into the existing text in the RASDS document.</li></ul>
<p class="yiv8389542000MsoNormal"><span style="color:black;"> </span></p>
<p class="yiv8389542000MsoNormal"> </p>
</div>
</div>
</div>_______________________________________________<br>SEA-SA mailing list<br><a ymailto="mailto:SEA-SA@mailman.ccsds.org" href="mailto:SEA-SA@mailman.ccsds.org">SEA-SA@mailman.ccsds.org</a><br><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa" target="_blank">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sea-sa</a><br></div>
</div>
</div></body></html>