[Sea-sa] Brief meeting notes from 13 Sep 21 SEA-SA working meeting, RASDS subset

[Shames, Peter M (US 312B)]

SEA-SA RASDS working meeting on 13 Sep 21

Attendees: Krosley, Radulescu, Shames, Slane

Review of TC20/SC14 issues – Fred Slane

  *   Review the current state of SC14 work.  Some of the items mentioned in 12 Jul 21 meeting notes are still open Action Items.  These will be listed at the end and tracked.
     *   The spreadsheets that represent the SC14 plan of work still need coordination from the SC14 workplan to Akiro-san’s categories
  *   In the SC14 & CONFERS contexts there is work being reviewed that involves something called the European Operations Framework (EOF).  We need a presentation from / about this work.
  *   => Action Item: Fred is to see if he can arrange a presentation or joint meeting with them.  One specific question for them is “What are the EOF/PERASPERA concerns and how might RASDS++ be able to help?”
  *   In RASDS++, relative to the Enterprise VP, we again discussed the relationship of the RASDS++ conceptual framework and methodology, and any specific mission or agency use of this framework.  The RASDS++ framework is intended, explicitly, to be agency and mission agnostic.  That said, there may be examples that are relevant to different contexts, such as an ISO 15288 related example in the Enterprise Viewpoint.
  *   RASDS++ will, as it has, use a defined set of terms in a carefully specified way, for consistency and clarity.  The point will be made that some of these terms (such a system, subsystem, module, component) may not be aligned with any particular mission or agency.  There will be clear guidance that when this is the case (and it may be often) that the agency of mission is encouraged to carefully define and use their own terms, and to stick to them.  Likewise any needed updates to Correspondences.

Physical / Structural Viewpoint – Shames

  *   From 12 Jul 21 Notes: The major set of topic areas where more work is needed appears to be the Physical / Structural  viewpoint(s).  Will these be one set, or several (structure, electro-magnetic, gravitational, mass, thermal, orbit, propulsion?  Is this one VP with aspects or multiple VP?  What do we need to say about representations?
  *   There was a somewhat lengthy discussion of how best to approach this issue of the Physical / Structural Viewpoint(s), whether this should be one Physical Viewpoint that addresses all the different considerations relating to Components, or a set of related Physical Viewpoints: structural connections (welded, bolted, rotational joints); electrical properties; thermal properties and flows; propulsion and thrust; etc.
  *   Alternatively there could be a single Physical/Component Viewpoint and these different considerations could be treated as different Aspects of these Components that would each be explored separately.
  *   We looked into the ISO/IEC 42010:2011 spec, which is the current one we are referencing, and it does not formally define the term “aspect”.   It does, however, have a quote from Edgser Dijkstra re “Separation of concerns”, in sec A.3:
Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained—on the contrary!—by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by “focussing one’s attention upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

  *   While this quote was being used in the context of “separation of concerns”, and as a motivation for separate Viewpoints, it struck us that the term “aspect” could equally well be used within a Viewpoint, such as Information, as the means to sort out the distinctions between abstract information objects, their syntax and semantics, and their data structures.  These are all quite clearly, we thought, parts of the Information Viewpoint, but could be described as different Aspects that could usefully be addressed separately within the context of that viewpoint.
  *   Information Viewpoint example aside, we actually arrived at this discussion from what we might call the Physical Viewpoint, where the core objects are Physical Components.  For our earlier work in CCSDS we needed these objects in physical space with which we could associate realized functional deployments (hardware or software) and as locations (nodes/end points) where protocol stacks would be deployed.  We had to concern ourselves with the physics of these component assemblies that were flying around in space, or roving some remote planet, because this motion and associated distance scales affected communications, but we tended not to deal with other physical aspects because it was not a protocol and communications concern.
  *   Now, with ISO TC20/SC14, they care about the real physics of these components: structural connections (welded, bolted, rotational joints); electrical properties; thermal properties and flows; propulsion and thrust; etc.  We could spin off a whole new set of Viewpoint specs.  But all of these concerns are tied to the same set of physical components, just looked at through a different set of filters.  Some concept like “Aspect”, used much like what Dijkstra described, seems like a useful way to provide appropriate separation of concerns in this Physical context.

  *   The newest ISO 42010:2021, which we have a draft of, formally defines Aspect this way:
Architecture aspects are typical characteristics or features of one or more architectures. Collectively architecture aspects relate to relevant emerging or expressed concerns of stakeholders based upon prior experience within a field of application. Usage of known architecture aspects can enable a more systematic  coverage of the range of established concerns and also the identification of new concerns.  Considering that, for a specific architecture, concerns are very subjective while aspects are more objective.
By examining architecture aspects, relevant features or properties of the entity can be discerned or predicted. Often multiple architecture aspects must be examined to determine how the architecture addresses a concern.

  *   Later in this ISO 42010 revision they list examples of “Architecture Aspects” to be addressed in an Architecture Description.  A non-exhaustive list includes: data; activity; function; location; people; time; motivation; taxonomy; structure; connectivity; behavior; information; parameters; constraints; requirements; regulatory; roadmap; and traceability.
  *   What is curious, in our context, is that many of these elements appear as formal entities int our specific Viewpoint specs (function, data, location, time, people, structure, connectivity, behavior, information, etc).  Others appear as attributes (parameters, constraints, taxonomy).  So it appears that we have already accounted for these elements in our Viewpoint spec decompositions.
  *   In section A.4.2 they define Aspect in a broader and somewhat cross cutting sense:

This document uses the term architecture aspect as a characteristic part or feature of the architecture. Aspects can be used to focus architecture considerations such as characteristics into cohesive subsets of an architecture description. Collectively the aspects cover all relevant architecture considerations and are organized in a way  which draws upon theory and established practice. Architecture aspects provide a way to partition the architecture to enable a more systematic examination of the architecture’s fundamental concepts such as structure and properties, and the evaluation of architecture alternatives. Aspects are neutral with respect to any particular concern although these concerns can be mapped to many relevant aspects. By examining the aspects of an architecture, certain relevant features or properties of the entity can be discerned or predicted. Aspects such as structure and behavior can be captured as abstractions. These abstractions are defined as ontologies and are typically shared (for example in reusable modeling patterns) within and across professional communities and application domains.

Architecture aspects often come from domain knowledge and the experience of engineers and architects. They also come from the architecture description frameworks that have found certain aspects to be useful for architecting for the scoped domain for that framework. These aspects are also embedded in methods that are  taught to architects and encapsulated in some modeling tools.

The scopes of architecture aspects and concerns are different. Concerns can apply to an entity of interest or an architecture whereas an aspect is a characteristic or a feature of an architecture.

  *   I got to read an earlier version of this revision where the term Aspect had been pushed to the fore, and basically read as replacing the concept Viewpoint.  Some of this still seems to be present in this version of the document, and I have the strong opinion that we could replace the word “Aspect”, in every place where it appears in this section, with the word “Viewpoint”, with no loss of meaning or relevance.
  *   We wish to align with ISO 42010, and have found a lot to value in the version that has been published.  There is still much that is of value in this latest version, but the way that they use Aspect may cause some confusion.  My recommendation is that we review and discuss this and make our own choices as to how we align on terminology and on these Physical Viewpoint extensions.  We get to interpret and create our own realizations, in our own domain specific meta-model, of these ISO 42010 terms.


Next Working Meetings, TBD

The CCSDS “Working Meetings” have been declared to be virtual again.  Several members of our core group have other CCSDS responsibilities.  We wish to schedule three (3) days of 2-3 hour virtual meetings at a time that allows all of our members to participate.  We will work with the WG Chairs for the other involved WGs, primarily in SOIS and MOIMS, to pick dates that will reduce collisions.  This might mean scheduling our meetings after the others, or even before them.

I you have knowledge of working meeting schedules from WG you are involved in please pass them along so that we can schedule our meetings accordingly.

Action Item Tracking

From 12 Jul 21 Meeting

  *   => Action Item: Fred has agreed to look at this in some detail and to review it with the nascent SC14 architecture team.  Fred will report back during a future meeting.
  *   => Action Item: agree to  incorporate in the early sections of the RASDS++ update a description of the concepts that power Fred’s additions to that spreadsheet.  Definitions of the terms “stage”, “tier”, Tech area” will be briefly introduced, because will reference them in the revised Enterprise VP, along with a recommendation for a project that uses RASDS++ to adopt, and carefully define, their own terms and meanings.  Note that different orgs may well use different terms.
  *   => Action Item:  everyone is to review the terms in the file “SEA SAWG RASDS Definition updates 15Jun21”, on pgs 8 & 9, and either concur, or provide some other self consistent set of definitions and relationships for these Operations VP terms.

  *   => Action item: Christian is to review the terms and those that the European agencies are using, and suggest how to handle this.

  *   => Action Item: All – consider how to best approach this Physical Viewpoint set of guidelines.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210914/0c5f27f6/attachment-0001.htm>