<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Courier;
panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Times;
panose-1:2 2 6 3 5 4 5 2 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:622539295;
mso-list-template-ids:-172324386;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:921373741;
mso-list-template-ids:-1448682634;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2
{mso-list-id:1537816705;
mso-list-template-ids:-318103386;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l3
{mso-list-id:2122144114;
mso-list-template-ids:2053899110;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Peter,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I don’t have a problem with using “functions” instead of “capabilities” – I was just quoting the ADSC definition of “[abstract-]service”. The purpose of my email was to clear up the source of SLE’s definition
of “service” and related terminology, and in particular to point out that it is determinedly NOT ISO 7498-based.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Shames, Peter M (US 312B) [mailto:peter.m.shames@jpl.nasa.gov]
<br>
<b>Sent:</b> Friday, May 28, 2021 4:58 PM<br>
<b>To:</b> John Pietras <john.pietras@gst.com>; Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>; Colin Haddow <Colin.Haddow@esa.int>; Holger.Dreihahn@esa.int<br>
<b>Cc:</b> SEA-SA <sea-sa@mailman.ccsds.org><br>
<b>Subject:</b> Re: [EXTERNAL] RE: Corrigenda issues re "service" and "capability"<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi John,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I was wrong about the ISO BRM sources of the SLE language, thanks for the correction.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I do agree that you can say “a ground station has certain capabilities.”<o:p></o:p></p>
<p class="MsoNormal">You can even say that the S-band feed has the capability of heating technicians lunches (no other microwave required).<o:p></o:p></p>
<p class="MsoNormal">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
<b><i>inside</i></b> the cart.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="text-autospace:none">To borrow from your last sentence:
<span style="font-size:12.0pt;color:#1F4E79">I’m still think that the distinction of “service” is that it is whatever
</span><s><span style="font-size:12.0pt;color:red">capability(ies)/</span></s><span style="font-size:12.0pt;color:red">
</span><span style="font-size:12.0pt;color:#1F4E79">function(s) is(are) exposed to an external entity (i.e., the “user”) via a standard interface.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Can we all agree on this?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Date: </b>Thursday, May 27, 2021 at 4:39 PM<br>
<b>To: </b>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, Erik Barkley <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>>, Colin Haddow <<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>>,
"<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>" <<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>><br>
<b>Cc: </b>SEA-SA <<a href="mailto:sea-sa@mailman.ccsds.org">sea-sa@mailman.ccsds.org</a>><br>
<b>Subject: </b>[EXTERNAL] RE: Corrigenda issues re "service" and "capability"<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:#1F4E79">Peter,</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">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, <i>Information Technology—Text Communication—Message-Oriented Text Interchange</i></span><o:p></o:p></p>
<p class="MsoNormal"><i><span style="font-size:12.0pt;color:#1F4E79">Systems (MOTIS)—Part 3: Abstract Service Definition Conventions</span></i><span style="font-size:12.0pt;color:#1F4E79">, which we referred to simply as ASDC. The
<i>Standard Terminology, Conventions, and Methodology (TCM) for Defining Data Services</i> 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:</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">“</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif">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</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">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.” </span><span style="font-size:12.0pt;color:#1F4E79">[and the examples follow]</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">[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.]</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">Now getting to the specific definition of “service”, or in the case of SLE, “abstract-service”, the full definition from ASDC is “</span><span style="font-size:12.0pt;font-family:"Times New Roman",serif">A
set of capabilities that one abstract-object offers to another by means of</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">one or more of its abstract-ports.”
</span><span style="font-size:12.0pt;color:#1F4E79">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.
</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">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.
</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">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.</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79"> </span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;color:#1F4E79">John
</span><o:p></o:p></p>
<p class="MsoNormal" style="text-autospace:none"><span style="font-size:12.0pt;font-family:"Times New Roman",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Shames, Peter M (US 312B) [<a href="mailto:peter.m.shames@jpl.nasa.gov">mailto:peter.m.shames@jpl.nasa.gov</a>]
<br>
<b>Sent:</b> Thursday, May 27, 2021 4:25 PM<br>
<b>To:</b> Barkley, Erik J (US 3970) <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>>; Colin Haddow <<a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a>>;
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>; John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>><br>
<b>Cc:</b> SEA-SA <<a href="mailto:sea-sa@mailman.ccsds.org">sea-sa@mailman.ccsds.org</a>><br>
<b>Subject:</b> Corrigenda issues re "service" and "capability"<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Dear CSS colleagues,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">The term “Service” is defined in at least two different ways in CCSDS:</span><o:p></o:p></p>
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3">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. “<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l2 level1 lfo3">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. “<o:p></o:p></li></ul>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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:</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;color:#2E75B6"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:12.0pt;color:#5B9BD5"><img border="0" width="48" height="8" id="_x0000_i1025" src="cid:image001.png@01D75640.2CD60C40" alt="page12image55298912"></span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in;background:white"><span style="font-size:12.0pt;font-family:Times;color:#2E75B6">(N)-service: <b>A </b>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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Here they appear to be talking in a sort of general way about the capability of a layer. But then the BRM also defines:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;background:white">
<b><span style="font-size:9.0pt;font-family:Courier;color:#2E75B6">(N)-service-access-point,</span></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;background:white">
<span style="font-size:10.0pt;font-family:Times;color:#2E75B6">(N)-SAP: The point at which (N)-services are provided by an (N)-entity to a (N+l)-entity. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">And …</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in;background:white">
<span style="font-size:10.0pt;font-family:Times;color:#2E75B6">(N)-function: A part of the activity of (N)-entities.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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 <b><i>of</i></b> a
layer” and the “functions <b><i>in</i></b> a layer”. One is an abstract <b><i>outside</i></b> view, the other a technical <b><i>inside</i></b> 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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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”.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Capability, business
<o:p></o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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. <o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">At an elemental level, a business capability is the encapsulation of the underlying functionality expressed abstractly. <o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Capability, system
<o:p></o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Capability <o:p>
</o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">A set of features implemented by technical, physical, and procedural means. Such features are typically selected to achieve a common organizationally valued purpose.<o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">System <o:p></o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Function <o:p></o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">A Function is interpreted as a specific process, action or task that a System is able to perform.<o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Service <o:p></o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">A Service is an exposed interface of a Function.<o:p></o:p></li></ul>
<li class="MsoNormal" style="color:black;mso-list:l3 level1 lfo6">Interface <o:p>
</o:p></li><ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">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.<o:p></o:p></li><li class="MsoNormal" style="color:black;mso-list:l3 level2 lfo6">An interface is formed of the ports on two or more elements and the junction that joins them.<o:p></o:p></li></ul>
</ul>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Are you open to discussing this?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black">Peter</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</body>
</html>