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

[Shames, Peter M (US 312B)]

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/20210527/854cec5e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1549 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20210527/854cec5e/attachment-0001.png>