[Sea-sa] [EXTERNAL] RE: Corrigenda issues re "service" and "capability"

[Shames, Peter M (US 312B)]

Hi John,

Thanks for the (as usual) thoughtful reply.  You carry a lot of the historical knowledge of the organization.  When you finally decide to RETIRE retire that knowledge history and will walk out the door.

I was wrong about the ISO BRM sources of the SLE language, thanks for the correction.

That said, you can still see the vestiges of it in the ASDC definitions, and from a clean, crisp, ontology PoV I still have a problem with that ASDC definition of “service” that includes “capability”.  I think that inverts the “proper” ordering of those terms.

I do agree that you can say “a ground station has certain capabilities.”
You can even say that the S-band feed has the capability of heating technicians lunches (no other microwave required).
But I think when you say “This service (a real thing) has capabilities.”, instead of “this service has functions” you are, in my opinion, putting the horse inside the cart.

I could be content in allowing the statement “an abstract-service entity has capabilities.”  But when you are really saying “a concrete service offers functions accessed via interfaces” then I  do not think you can just substitute “capability” for “function” and have the meaning be the same.

To borrow from your last sentence:  I’m still think that the distinction of “service” is that it is whatever capability(ies)/ function(s)  is(are) exposed to an external entity (i.e., the “user”) via a standard interface.

Can we all agree on this?

Thanks, Peter


From: John Pietras <john.pietras at gst.com>
Date: Thursday, May 27, 2021 at 4:39 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Erik Barkley <erik.j.barkley at jpl.nasa.gov>, Colin Haddow <Colin.Haddow at esa.int>, "Holger.Dreihahn at esa.int" <Holger.Dreihahn at esa.int>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>
Subject: [EXTERNAL] RE: Corrigenda issues re "service" and "capability"

Peter,
With respect to SLE terminology, we specifically did NOT use ISO-BRM (ISO 7498) terminology fro SLE. When we (what was then Panel 3) started what became SLE in the early 1990s, some folks were thinking in terms of the layered OSI model (e.g., N-layer services being provided to N-1 layer entities), but we realized that was not the right model – SLE cross-support was peer-to-peer (or client-server). So we adopted the terminology from what was then ISO/IEC 10021-3, Information Technology—Text Communication—Message-Oriented Text Interchange
Systems (MOTIS)—Part 3: Abstract Service Definition Conventions, which we referred to simply as ASDC. The Standard Terminology, Conventions, and Methodology (TCM) for Defining Data Services Green Book (CCSDS 910.2-G-1, 1994) addressed both the ISO-BRM (section 3) and ASDC (section 4) as a way of helping Panel 3 members understand the distinctions between the two service models (and section 5 summarized how the two service models would play together in real systems. But the selection of ASDC for SLE is explicit in paragraph six of section 2 of the TCM, which begins:
“The ASDC have been selected for use in the definition of CCSDS Space Link Extension (SLE) services. At first glance, the communication-oriented OSI conventions seem to be most suitable for the SLE services, which deal with the transfer of spacecraft data to and from ground destinations remote from the ground station (reference [4]). However, on
further investigation, several aspects of the OSI model are found to be unsuitable for the cross-support environment envisioned for the provision of SLE services.” [and the examples follow]

ASDC itself was literally an abstraction of the ISO Remote Operations Service (ROS, ISO/IEC 9072-1), where ISO realized that they could create a general-purpose service model be prepending “abstract-“ to all of the terms defined for the ROS – that’s why SLE is defined in terms of “abstract-service”, although of course once it gets realized in SLE it’s no longer “abstract”. If you look at the Cross Support Reference Model and the individual SLE specifications, you’ll see eveythig expressed in terms of [abstract-]service and [abstract-ports], and nothing about “N-layer” services.

[As an aside, there still remained a group of people, mainly in ESA, that were thinking in terms of developing software and having interchangeable modules that could plug-and-play within a given computer – in particular a core common SLE engine and SLE-service-specific (e.g., RAF) modules that would plug into that engine. Those folks developed the suite of SLE API Magenta Books (CCSDS 914 and 915). The M-2 versions of those books were published in 2015, and I haven’t heard of anyone expressing interest in a 5-year recertification of them.]

Now getting to the specific definition of “service”, or in the case of SLE, “abstract-service”, the full definition from ASDC is “A set of capabilities that one abstract-object offers to another by means of
one or more of its abstract-ports.” This definition worked extremely well for SLE, especially in the cross-support context. What it says is that an object (e.g., a ground station) may have lots of “capabilities” (i.e., do a lot of things) but those capabilities become services only when they are made available to other objects in standardized ways (i.e., via one or more defined ports). To be only slightly facetious, a ground station may have a capability to heat technicians’ lunches in the breakroom microwave oven, but that’s not a capability tha’st part of any ground station cross-support service.

Now let’s look at the concept of (perhaps) multiple capabilities per service. The Monitored Data CSTS – a single service –is able to (a) periodically report the values of monitored parameters, (2) send event notifications upon occurrence of subscribed-to events, and (c) return the values of queried parameters. One could easily contend that these are 3 different capabilities all wrapped up in a single service.

So in summary, SLE does not use ISO BRM “N-layer” terminology, so there’s no issue about CSS standards having to migrate away from such terminology.  If you want to use either “capability” or “function” in lieu of the other, I don’t have an opinion one way or the other. But I’m still think that the distinction of “service” is that it is whatever capability(ies)/function(s)  is(are) exposed to an external entity (i.e., the “user”) via a standard interface.

Best regards,
John


From: Shames, Peter M (US 312B) [mailto:peter.m.shames at jpl.nasa.gov]
Sent: Thursday, May 27, 2021 4:25 PM
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>; Colin Haddow <Colin.Haddow at esa.int>; Holger.Dreihahn at esa.int; John Pietras <john.pietras at gst.com>
Cc: SEA-SA <sea-sa at mailman.ccsds.org>
Subject: Corrigenda issues re "service" and "capability"

Dear CSS colleagues,

The SEA SAWG has identified an issue that we believe needs a relatively minor corrigendum update.  We have fixes to make in the ASL Green Book, CCSDS 371.0-G-1, where we defined (or referenced) a set of terms that we used in the document.  During yesterday’s SAWG meeting while we were examining the ontology (yes, an actual ontology) that is going to be incorporated in the RASDS updates we stumbled upon an issue in one particular definition.  On further exploration it appears that this also shows up in many of the CSS Area docs as well.

The term “Service” is defined in at least two different ways in CCSDS:

  *   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. “

The problem that we have is that we believe that “capability” is a rather high level, generalized, term describing what an organization wants, or needs, to achieve, and that service (and the functions that offer service interfaces) is a more specific and focused term that implies an actual implementation.   This “service is a set of capabilities” definition inverts that sense, hence the issue.

In trying to come to terms with this we looked in the CCSDS Terms set.  We also found “abstract-service” from 910.2, which is loosely aligned with the ASL usage as shown, “application-service-element”(ditto), “communications service” from 912.3 (911.1, 912.2. etc).  In fact, a lot of these CSS related definitions seem to derive from the venerable OSI-BRM, ISO 7498, which defined (N)-Service:

[page12image55298912]
(N)-service: A capability of the (N)-layer and the layers beneath it, which is provided to (N+l)-entities at the boundary between the (N)-layer and the (N+l)-layer.

Here they appear to be talking in a sort of general way about the capability of a layer.  But then the BRM also defines:
(N)-service-access-point,
(N)-SAP: The point at which (N)-services are provided by an (N)-entity to a (N+l)-entity.
And …
(N)-function: A part of the activity of (N)-entities.
The ISO BRM also talks about N-layer functions, and how the protocol associated  with the N-Layer exposes those functions.  There is, in effect, an unexpressed distinction between the “capabilities of a layer” and the “functions in a layer”.  One is an abstract outside view, the other a technical inside view.  Unfortunately this is not made crystal clear, but there is a consistent distinction between what shows up as a description of a layer and what is inside as functions.  Later specs dealing with service oriented architectures, and other kinds of services, get this  right.  But the ISO BRM predates all of that stuff.

Our concerns are that the meaning of “capability” and the meaning of “function” and the distinctions between them are somewhat muddied, and it only gets worse with (casual) use.   In my other “day job” I just went through an exercise with one of the “Enterprise Architecture” weenies who was describing how they were defining “capabilities” and then mapping these to “services”.  And then he mumbled something about how the applications and services were related, but this all sounded vague and further questions did not clarify it.  So I went looking for decent definitions, and found some, which I am providing here.  Some are a little at odds with one another, which is just indicative of how hard it is to  get this ”right”.


  *   Capability, business
     *   An expression of what business does and can do.  A business capability denotes the “What” a business can do, whereas a business process outlines how a particular activity gets done.
     *   At an elemental level, a business capability is the encapsulation of the underlying functionality expressed abstractly.
  *   Capability, system
     *   An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.
  *   Capability
     *   A set of features implemented by technical, physical, and procedural means. Such features are typically selected to achieve a common organizationally valued purpose.
  *   System
     *   A System is a group of interacting or interrelated Elements that act according to a set of rules to form a unified whole. A System, surrounded and influenced by its environment, is described by its boundaries, structure and purpose and expressed in its functioning.
     *   A collection of interacting components organized to accomplish a specific function or set of functions.  A System is composed of Elements, which may be any of: Hardware, Software, People, and Procedures.
  *   Function
     *   A Function is the purpose for which an Element is intended. This can be an activity performed by the Element or the usage of this Element by other parts of the system.
     *   A Function is interpreted as a specific process, action or task that a System is able to perform.
  *   Service
     *   A mechanism to enable access to a set of one or more functions of an Element, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.
     *   A Service is an exposed interface of a Function.
  *   Interface
     *   An Interface represents a set of mechanical, electrical, signal, or other properties that describe some aspect of a Element’s connection to or interaction with another Element.
     *   An interface is formed of the ports on two or more elements and the junction that joins them.

My conclusion after looking at this stuff and talking it over with my SAWG team and my JPL Data System Standards team is that “capability” is a rather high level, generalized, term describing what an organization wants, or needs, to achieve, and that service (and the functions that offer service interfaces) is a more specific and focused term that implies an actual implementation.

All of which motivates me to propose that all of these definitions that loosely use “capabilities” where they really mean functions or services, need to be changed.   So instead of the ASL saying “A set of capabilities that a component provides …” it should say “A set of functions that a component provides…”.  I intend to ask Tom Gannett to make a small number of changes to the ASL to fix the definition and a limited number of places where the phrase appears in a similar context.  There are other locations in the document where “capability” is used more loosely, and more accurately, that we can leave alone.  I think this is suitable for a corrigendum.

That said, I believe that there are similar changes of definition and usage to the set of CSS / SLE documents.  This is going to be rather more laborious and troublesome, but since I have been informed that they are in revision now perhps this is the right time to  fix this so we get consistent terms.

Are you open to discussing this?

Peter


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210528/aba88382/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 816 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210528/aba88382/attachment-0001.png>