[Sea-sa] [EXTERNAL] SC14 meeting

Shames, Peter M (US 312B) peter.m.shames at jpl.nasa.gov
Tue Apr 6 16:32:43 UTC 2021


Define: recursive

  1.  characterized by recurrence or repetition.
o    Mathematics
relating to or involving the repeated application of a rule, definition, or procedure to successive results.
"this restriction ensures that the grammar is recursive"
o    Computing
relating to or involving a program or routine of which a part requires the application of the whole, so that its explicit interpretation requires in general many successive executions.
"a recursive subroutine"

Define: decomposition (in computers)

Decomposition in computer science<https://en.wikipedia.org/wiki/Computer_science>, also known as factoring, is breaking a complex problem<https://en.wikipedia.org/wiki/Computational_problem> or system<https://en.wikipedia.org/wiki/System> into parts that are easier to conceive, understand, program, and maintain.
Decomposition diagram

  *   [cid:image001.png at 01D72AC7.CBB2A520] <https://en.wikipedia.org/wiki/File:6_Decomposition_Structure.svg>
Decomposition Structure

  *   [cid:image002.png at 01D72AC7.CBB2A520] <https://en.wikipedia.org/wiki/File:21_Negative_Node-Numbered_Context.svg>
Negative Node-Numbered Context

  *   [cid:image003.jpg at 01D72AC7.CBB2A520] <https://en.wikipedia.org/wiki/File:Static,_Dynamic,_and_Requirements_Models_for_Sys_Partition.jpg>
Static, Dynamic, and Requirements Models for Systems Partition

  *   [cid:image004.jpg at 01D72AC7.CBB2A520] <https://en.wikipedia.org/wiki/File:Functions_and_Use_Scenarios_Mapping_to_Requirements_and_Goals.jpg>
Functions and Use Scenarios Mapping to Requirements and Goals
A decomposition diagram shows a complex, process, organization, data subject area, or other type of object broken down into lower level, more detailed components. For example, decomposition diagrams may represent organizational structure or functional decomposition into processes. Decomposition diagrams provide a logical hierarchical decomposition of a system.
I think that what we do in the process of systems engineering is create successive levels of decomposition of the system.  That said, it may we be that we could call that process itself one of recursion.  “Involving a routine of which a part requires the application of the whole …”.  It’s a process vs product distinction.

So, if you want a nail, go find a blacksmith.  But the nail, and the process for making nails, are not one and the same…

Peter

From: Fred Slane <frederick.slane at gmail.com>
Date: Monday, April 5, 2021 at 12:19 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Ramon Krosley <r.krosley at andropogon.org>, SEA-SA <sea-sa at mailman.ccsds.org>
Subject: Re: [EXTERNAL] SC14 meeting

There are certain properties or characteristics that are recursive in the decomposition. Reliability, and all brethren.  This gets to a major point of interest in identifying nails, as in "for want of a nail, a shoe was lost..."

Fred
Frederick A. Slane
Executive Director
Space Infrastructure Foundation
731 North Tejon Street
Colorado Springs, CO 80904
freds at spacestandards.org<mailto:freds at spacestandards.org>
www.spacestandards.org<https://urldefense.us/v3/__http:/www.spacestandards.org__;!!PvBDto6Hs4WbVuu7!ZggPxMDqysCPSEmZGo2_VVxtFAvm0V5wRWKnbeYovBAYlUTQvnYfx2DZTpqnh8j43iep0DQB$>
+1-719-229-4252

"If you can't describe what you are doing as a process, you don't know what you're doing." ~W. Edwards Deming



On Mon, Apr 5, 2021 at 10:59 AM Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
IMHO it’s really successive decomposition, not recursion.  At the top “levels” it is often “systems “ level decomposition.  At lower levels hw & Sw appear in it own views.

Peter
Sent from Peter's JPL iPhone X

Everything should be made as simple as possible,
but not simpler.

~Albert Einstein


On Apr 3, 2021, at 5:01 PM, r.krosley at andropogon.org<mailto:r.krosley at andropogon.org> wrote:
Those are good points, Fred,
The “scales”, “levels”, or “tiers” that you mention are examples that provide alternative names for the boundaries between different scales of descriptions.  We should use the word that resonates with folks.
The “Physical Interfaces” is a good descriptive name for the viewpoint to me.
Ramon

From: Frederick Slane <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Sent: Saturday, April 3, 2021 11:23 AM
To: Ray Krosley <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>>
Cc: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>; SEA-SA <sea-sa at mailman.ccsds.org<mailto:sea-sa at mailman.ccsds.org>>
Subject: Re: [EXTERNAL] SC14 meeting

Ray,
Recursion is a nice elegant approach.  I would hve called it "scalable" instead of "recursive", but that's perhaps a nit.

Recursion may also be another way of expressing the "Levels" as described in NASA HDBK 1005, where we list systems and subsystems and assemblies and so forth.

In feedback from the US SC14 TAG, Alan Kirchbaum suggests "Physical Interfaces", which may be better than "Physical" for that Viewpoint. Thus, Recursion and Physical Interfaces will go a long way in consistently addressing system, subsystem, assembly etc. standards work. We do not really want to standardize anything but the interfaces.

Cheers,
Fred
Frederick A. Slane
Executive Director
Space Infrastructure Foundation
731 North Tejon Street
Colorado Springs, CO 80904
freds at spacestandards.org<mailto:freds at spacestandards.org>
www.spacestandards.org<https://urldefense.us/v3/__http:/www.spacestandards.org__;!!PvBDto6Hs4WbVuu7!dQGp2ush1q1eMLe2LHV-etOfFmzfQdFMbMbIdAyTsh-Ib1elSsQgYVFPuY002rvbe0E12Ce6$>
+1-719-229-4252

"If you can't describe what you are doing as a process, you don't know what you're doing." ~W. Edwards Deming



On Fri, Apr 2, 2021 at 8:29 AM <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>> wrote:
Hi Peter,
One feature that I started to add, but then removed pending discussion, was a recursive structure of the view products.  This structure might help to manage the correspondences that are possible.  The main example of the recursive structure is two communications/connectivity views:  One view that is used in CCSDS has the scope of the mission and has spacecraft, relay vehicles, habitats, and ground stations as its nodes.  The view within that view, which is used in SOIS, has the scope of a single vehicle, and has the instruments of the vehicle as its nodes and subnetworks as connections.  We have occasionally drawn diagrams that mix these views to describe how a communication link terminates in a vehicle and in a ground station (for example).  The view-within-a-view establishes a context for other views whose scope is limited to the same vehicle.  The other vehicle-scoped views include minimally the physical/structural view and an electrical power distribution view and may also include a thermal distribution view, a propulsion view, and others.  Perhaps all these vehicle-scoped views could be considered products of the physical/structural viewpoint.  The correspondences between objects in the vehicle-scoped views would indicate where each instrument of the vehicle participates in each view.  These vehicle-scoped correspondences would not extend to the nodes of the mission-scoped communication/connectivity view, except that a whole vehicle may correspond to a node in the mission-scoped communication/connectivity view.
The vehicle-scoped views described above could express the energy flows that you identified in your second point.  I think that we can describe the interaction between energy flows and information flows that occurs in the instruments of a vehicle.  That interaction would be the subject of the vehicle-scoped communication/connectivity view if the recursive structure is agreeable.
Ramon

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Thursday, April 1, 2021 6:09 PM
To: r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>; 'Frederick Slane' <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Cc: SEA-SA <sea-sa at mailman.ccsds.org<mailto:sea-sa at mailman.ccsds.org>>
Subject: Re: [EXTERNAL] SC14 meeting

Hi Ray,

I like what you have done with this.  It makes sense and it fits into the overall format used for the other viewpoints.

There are two items that occur to me that we may need to adjust:

  1.  I think we need to be careful about how we talk about correspondences to other views.  This is especially tricky in this instance, where we essentially have a communications / connectivity view of physical Nodes, with a focus on how they connect for communication, and also the allocation of what we might call computational functions to the Nodes, and your Physical / Structural view of the same Nodes, where the concern is their physical connections and the allocation of what we might think of as energetic vs computational functions.
  2.  Related to that distinction, in this viewpoint, I think we would talk about those energetic flows instead of information flows (ref pg 4).  So on pgs 5 & 6 I think we will want to avoid things like referencing IP addresses and control algorithms (except by correspondence) and instead would want to focus on the structural and energetic connections and even functions.  Batteries, power panels, thrusters, etc all have energetic aspects which must be expressed in these views.  But I think that any control / monitor interfaces should be handled in the communications / connectivity views.

Does this make sense to your way of thinking?

Thanks, Peter


From: Ramon Krosley <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>>
Date: Wednesday, March 31, 2021 at 2:24 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Fred Slane <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Cc: "Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>" <Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>>, 'Yonghui Huang' <huangyonghui at hotmail.com<mailto:huangyonghui at hotmail.com>>
Subject: RE: [EXTERNAL] SC14 meeting

Hi Fred and Peter,
The attachment contains the charts from the core deck that relate to the Physical/Structural view.  I added a few charts at the end that provide additional information for discussion in the April 12 teleconference.  There is an improved example of a physical/structural diagram adapted from OPS-SAT, using the drawing style of RASDS.  The additional charts identify information that the physical/structural model provides to its users.  The users of the model constitute an additional set of stakeholders.
Ramon

From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Sent: Monday, March 29, 2021 12:08 PM
To: Frederick Slane <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Cc: Ray Krosley <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>>; Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>; Yonghui Huang <huangyonghui at hotmail.com<mailto:huangyonghui at hotmail.com>>
Subject: Re: [EXTERNAL] SC14 meeting

Hi Fred,

On the surface this sounds fine to me.  I’d suggest that you try to create a revised set of the core deck we have been using that:

  1.  Moves things around to meet SC14 needs
  2.  Adds your desired expansions of the common / shared viewpoints (Services, Operations, and expanded Enterprise)
  3.  Adds the SC14 specific Physical / Structural viewpoint
  4.  Moves anything you think detracts from the SC14 message to backup

I assume that you will show these revised materials to all of us before showing them to SC14.  Is that correct?  Can we review them at the 12 April SAWG meeting or will that be too late for you?  If you want to schedule a working session sooner, just to focus on this in a timely way, I’ll be happy to set that up.

Thanks, Peter


From: Fred Slane <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Date: Monday, March 29, 2021 at 10:54 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Cc: Ramon Krosley <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>>, "Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>" <Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>>, Yonghui Huang <huangyonghui at hotmail.com<mailto:huangyonghui at hotmail.com>>
Subject: Re: [EXTERNAL] SC14 meeting

I'll have updated SC14 slides from the larger presentation on my priority list today. I will intentionally leave some SC14 details for the SC14 architecture group to fill in.
I think an abridged version of slides to present, with full set as reading material will be good for the meeting.

The message I want to get across has three primary parts:
1- RASDS core establishes the framework and methodology (i.e., Views) for our common baseline.  References ISO 42010: Systems and Software Engineering - Architecture Description
2- CCSDS extensions go into greater detail using the common baseline (CCSDS: ASL, SCCS ADD)
3- SC14 has its own story to tell and uses the common baseline for needed crosstalk.
    -- Engineering basis for Systems and Operations Views. Engineering "V" describes Space System Design Engineering and Verification. Reference ISO 15288: Systems Engineering
    -- Major SC14 extension Views are Physical, Operational, Services (expanded from previous RASDS), Enterprise (expanded back into CCSDS?)

I have one slide that will be for SC14 technical management related to how the Working Groups correlate to Views.

I would like to move the exploration of DoDAF to a footnote. While useful in our development work, I think it detracts from the primary product for the standards committees.

Cheers,
Fred
Frederick A. Slane
mobile

On Mon, Mar 29, 2021, 7:55 AM Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
Hi Fred,

Then we had best get hopping at the next CCSDS working meeting, right?  Or do you think what  we have already is suitable as it is?

Thanks, Peter


From: Fred Slane <frederick.slane at gmail.com<mailto:frederick.slane at gmail.com>>
Date: Sunday, March 28, 2021 at 2:10 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, Ramon Krosley <r.krosley at andropogon.org<mailto:r.krosley at andropogon.org>>, "Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>" <Christian.Stangl at dlr.de<mailto:Christian.Stangl at dlr.de>>, Yonghui Huang <huangyonghui at hotmail.com<mailto:huangyonghui at hotmail.com>>
Subject: [EXTERNAL] SC14 meeting

Hi Peter and All,
The SC14 meeting where I'll present our work is mid-April.

Fred
Frederick A. Slane
Executive Director
Space Infrastructure Foundation
731 North Tejon Street
Colorado Springs, CO 80904
freds at spacestandards.org<mailto:freds at spacestandards.org>
www.spacestandards.org<https://urldefense.us/v3/__http:/www.spacestandards.org__;!!PvBDto6Hs4WbVuu7!Z9QQVdae-rx4ji6veNe9h8S34Iun-nQ1ay7iS8bPwu6OtTPht_9R0HgYen4WiwjAniOwyUu9$>
+1-719-229-4252

"If you can't describe what you are doing as a process, you don't know what you're doing." ~W. Edwards Deming

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210406/971b39a5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3768 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210406/971b39a5/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2593 bytes
Desc: image002.png
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210406/971b39a5/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 4015 bytes
Desc: image003.jpg
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210406/971b39a5/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 4717 bytes
Desc: image004.jpg
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210406/971b39a5/attachment-0003.jpg>


More information about the SEA-SA mailing list