[Sea-sa] Request for SEA-SA review of SOIS / MOIMS analysis document

[Shames, Peter M (312B)]

Hi Richard,

Thanks for taking the time to review and provide these comments.  I also want to state at the outset that I understand that without support to do this you cannot take on more work.  Assuming that the team agrees, my intent is to get to consensus on the needed changes using this Excel spreadsheet approach and then to update the document myself, seeking support and feedback from the combined team.

You question about services and bindings is a really good one and I agree that it appears to be an on-going point of confusion.  CCSDS has tried to address this in RASDS, MO, and SLE (in particular) in the following ways:

object (RASDS 311.0-M-1):
An object is an abstract model of an entity in the real world. It contains information, has behavior, and may offer services. A system is composed of interacting objects. An object is characterized by that which makes it distinct from other objects.

Interface (RASDS 311.0-M-1):
A set of interactions performed by an object for participation with another object for some purpose, along with constraints on how they can occur. An interface is therefore where the behavior of an object is exposed. Objects may have one or more interfaces.

service (RASDS 311.0-M-1):
A service is a provision of an interface of an object to support actions of another object.

Cross support service (RASDS 311.0-M-1):
Cross-support service interfaces are really just the exposed set of interfaces of applications layer Engineering Objects. All application Engineering Objects have interfaces; the ones that are exposed between facilities owned and operated by (the same or) different Enterprises are called cross-support service interfaces.

service interface (MO Ref Model 520.1-M-1):
A set of interactions provided by a component for participation with another component for some purpose, along with constraints on how they can occur. A Service Interface is an external interface of a Service where the behaviour of the Service Provider Component is exposed. Each Service will have one defined ‘Provided Service Interface’, and may have one or more ‘Consumed Service Interface’ and one ‘Management Service Interface’.

abstract service (SLE 910.2-G-1):
A set of capabilities that one abstract-object offers to another by means of one or more of its abstract-ports.

communications service (SLE 912.3-B-2, and others):
A capability that enables an SLE service-providing application entity and an SLE service-using application entity to exchange information.

OSI services (SLE 910.2-G-1):
The capability of an OSI-service-provider to OSI-service-users at the boundary between the OSI-service-provider and the OSI-service-users.

provided service interface (MO Ref Model 520.1-M-1):
A Service Interface that exposes the Service function contained in a component for use by Service Consumers. It receives the MAL messages from a Consumed Service Interface and maps them into API calls on the Provider component.

service access point (RASDS 311.0-M-1):
The point at which (N-layer)-services are provided by an (N-layer)-protocol-entity to an (N+l-layer)-protocol-entity.

service interface (MO Ref Model 520.1-M-1):
A set of interactions provided by a component for participation with another component for some purpose, along with constraints on how they can occur. A Service Interface is an external interface of a Service where the behaviour of the Service Provider Component is exposed. Each Service will have one defined ‘Provided Service Interface’, and may have one or more ‘Consumed Service Interface’ and one ‘Management Service Interface’.

service provider (SLE 910.4-B-2, and others):
An entity that offers a service to another by means of one or more of its ports.

I'm including all of these different, but related, definitions to make a point.  We have been trying really hard to bring a level of consistency to the CCSDS standards and their uses of terms.  I'd say we have only partly succeeded.  One thing to keep in mind is that RASDS was intended to provide as set of (largely abstract) terms that were consistent and could be broadly used.  It also provides a set of defined viewpoints from which systems could be described and addressed how these different views are related.  This kind of precision has not been not always been adhered to across CCSDS, and as a result we get some "leakage" in the definitions and also need to identify for ourselves just which views are being addressed at any given point.  It is also the case that individual standards will often specialize their definitions, we see that in the MAL and SLE definitions.

Depending on where one stands an "interface" may be some software thing (an API), a hardware thing (Ethernet), a protocol thing (TCP/IP & socket), exposed inside a system for local use (software bus) or exposed outside a system (SLE).  I tend to think of interfaces as all of these things and have worked to define a way to model all of these aspects in relationship one to another.  I'm attaching an MBSE paper I jointly wrote about this that was published in INCOSE in 2016.  It carefully (I think) lays out how to model all of these parts in relationship one to another.  The future update to RASDS will add MBSE considerations and reference these materials.

Enough of definitions and pedantics, now to the details that show up in your note.  See below, <<in-line>>.

Thanks, Peter





From: Richard Melvin <Richard.Melvin at scisys.co.uk>
Date: Monday, October 29, 2018 at 6:28 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Cc: Sam Cooper <sam at brightascension.com>
Subject: RE: Request for SEA-SA review of SOIS / MOIMS analysis document


Ok, now I can read the comments.

Mostly makes sense to me, the required changes seem to be all doable.

A couple of points of understanding:

1. services and binding

In RASDS and/or MO terminology, a 'service' is an abstract definition which gets given a 'binding' to a particular 'component', 'port' and 'technology' and then becomes an 'interface'.
<<Components have interfaces.  Components have behavior (in the application / function sense).  Interfaces have bindings to particular port, technology, and a protocol stack).  Each protocol in the stack has PDU, interactions "on the wire", and behaviors (at the protocol level) within the protocol entities.  The top level protocol in the stack, and the binding interface, is the one that exhibits the behavior at that interface.>>

In existing SEDS terminology (taken from ESA SAVOIR):

-  an 'interface definition' is an abstract thing that speciifies a specific pattern of message exchange
<<This is a very limited definition of "interface", since it appears to assume "messages" and "message exchange".  I think SOIS overall is broader than this.  This sounds like a software kind of message abstract view at application layer.  Right?>>
- when bound to a particular component type and port ('name', in the schema), but not technology, it becomes an 'instance' of that definition, or just an 'interface'
<<Talking about an interface of a component, and a port, in the absence of technology, sounds like a very limited view of an interface.  It is not that you cannot limit discussion to these sorts of software views, but it is the case that "interface" is much broader than that, and at some point you really need to understand the rest, behavior, protocol stack, all the way down to physical bindings for hardware components and the allocation of software components to hardware components.>>
- a 'service' is more abstract still; it defines the goals or requirements of a pattern of message exchange, but doesn't necessarily specific the actual patterns or messages.
<< This is also a very limited definition of "interface", since it appears to assume "messages" and "message exchange">>

So device component 'StarTracker' provides a 'Attitude' interface definition under the name 'currentAttitude'. And that is an example of a 'device access' service.

<<This "Device Access service" is an abstraction of a specific device, making reference to a specific abstracted data item.  It hides all the real details of the device and the real attributes and physical interface behind some software layer.  If this is what we mean by "Device Access Service" then we're on common ground.  But any such "service" is going to present a different interface depending on other factors, such as the nature of the "message bus", the nature of the actual device (real counts vs engineering units), and the nature of the real device interfaces, 1553 vs spacewire vs RS422 vs LVDS vs TTEthernet).  Right?

The strength of EDS, as I understand it, is that you can talk in this abstract fashion about the provided service from the real device, and about the real physical connections, and use the EDS to autogenerate the mappings.>>


Binding of non-subnetwork interfaces to a technology is not something SEDS attempts to address; you can use calls in a programming language, message passing, or whatever. But naiive C++ code would be something like:
<<Interesting statement.  I would think that EDS would want to be able to specify these bindings all the way from the S/W abstractions down to the physical layer, or down to a message bus or other "layer".  It's fair enough to say "the Subnetwork WG will handle those grimy details.", but then you are assuming that those guys expose a consistent interface across all underling subnetworks AND that the only thing that EDS can handle is subnets that have such a specification.  This strikes me as being a rather limited approach, but it's your (collective) choice.>>

class StarTracker
{
   Attitude * currentAttitude;

}

Binding to subnetwork technologies is one of the jobs of the subnetwork WG; so far only Spacewire has been covered. Or of course you could use a mission-specific or local-standard binding.


Is that all correct?

If so, in an ideal world, I'd be keen to change 'Interface definition' to 'service', and use 'service class' or omething for the cases where that is distinct from simple 'service'.
But I think that would have to be judged quite a high priority to be worth the documentation and example changes now.

<< I think I would council sticking to "interface" and adequately specifying (and constraining) just what it is that you are talking about, SW, message bus, "subnet", physical, etc".  I do not think that all of these things are services in any sense of the term.>>

2. the three stages


The document currently only considers stages 1 and 3; the approach of a 'hybrid' architecture where some MO services are onboard and some on the ground was not considered.
In particular, the use of onboard MO is assumed to mean the use of onboard MO-based commanding and parameters.

<<So you are asserting that both fig 5-1 and fig 5-3 are Case 3 examples.  In looking at this more closely I can see that you could make that claim.  I think we need some comparable Case 2 example.  As we were discussing this in the SAWG we thought that Case 2 would involve what we called an "MO Proxy" on-board which would accept "MO commanding and parameters", and provide "MO responses", but would otherwise be a "normal" real-time, on-board, resource constrained environment.   In such an environment you would still have more typical GNC, M&C, C&DH, FDIR, power & thermal management, etc in control.>>

For example, a MO onboard scheduler application should, as I understand it, be layered on top of the MO action service to actually do the things it needs to do. And a planner probably layered on top of that.

I am not actually convinced such a hybrid is viable; it would mean either:

- onboard MO applications sending messages to the ground to ask the MO gateway to request the execution of a command
- losing centralised coherency over operational concepts like 'what commands have been executed' and 'can a command be executed now?'
- having the ground gateway operate at a higher logical layer than previously presented

<<I know that we have migrated some amount of higher level GNC and even science analysis on-board.  We have also migrated higher level autonomous behaviors.  But all of this has occured on an underlying RT, OB, RC framework, and not some GDS framework that takes over the flight system.>>

Addressing those concerns is the kind of thing a presentation of such a model should do. While no doubt someone should do that, I don;t see how I can do so.

Richard

<<Let's see if we can get to a viable middle ground. Without requiring major new work.  I think all of this is still evolving and we only need to point to a way to make the best use of capabilities in the environments in which they are best suited.

Thanks, Peter


>>


________________________________
From: Shames, Peter M (312B) [Peter.M.Shames at jpl.nasa.gov]
Sent: 26 October 2018 6:41 PM
To: Richard Melvin; SEA-SA
Cc: Sam Cooper
Subject: Re: Request for SEA-SA review of SOIS / MOIMS analysis document
Dear Richard, et al,

I could not find a straightforward way to make these comments visible in the exported PDF, except within the Mac Preview app.  Happily that document still contained (almost all) of my comments in a form where I could easily extract them.

As a result of this PDF compatibility issue I have gone crawling through the PDF document and extracted the attached set of comments and responses, represented now in an Excel spreadsheet.   I put in page and section references and these are in the same order as the original.  If you want to see exactly what any inputs relate to you will have to follow the bouncing balls from the PDF to the spreadsheet.
As noted before there are three kinds of notes in the document:
1.       Notes that show up as a white square came from MOIMS, apparently Mario Merri
2.       Notes that show up as a yellow square with a "thought bubble" also came from MOIMS, apparently Mehran Sarkarati
3.       Notes that show up as a magenta square, are comments from me (SEA) as to responses not requiring any changes and the rationale for this choice
4.       Notes that show up as a red square are suggested changes to the draft document, many in response to MOIMS issues, some reflecting issues I found in reading the document
See if this works any better.

There is a column in the spreadsheet for SAWG Comments.  Would each of you who choose to provide comments please use that column to indicate agreement, or not, and save a copy of the file named to indicate who you are.

We will sort out any glaring disconnects in a telecon, as necessary.

Thanks, Peter


From: Richard Melvin <Richard.Melvin at scisys.co.uk>
Date: Friday, October 26, 2018 at 4:16 AM
To: Peter Shames <Peter.M.Shames at jpl.nasa.gov>, SEA-SA <sea-sa at mailman.ccsds.org>
Cc: Sam Cooper <sam at brightascension.com>
Subject: RE: Request for SEA-SA review of SOIS / MOIMS analysis document

Thanks for doing the work on this.

Unfortunately, I couldn’t find a way to view the document comments in an offline PDF.
Both adobe and foxit reader show the icons, but clicking on them does nothing and the comments it’s is empty.

Apologies if I am missing something stupid…

Richard

From: Shames, Peter M (312B) [mailto:Peter.M.Shames at jpl.nasa.gov]
Sent: 25 October 2018 22:49
To: SEA-SA
Cc: Sam Cooper; Richard Melvin
Subject: Request for SEA-SA review of SOIS / MOIMS analysis document

Dear SAWG members,

During the joint SAWG / MOIMS / SOIS meeting on Wednesday we spent quite some time discussing the draft document that SOIS produced comparing MO Services (based on the MAL) and SOIS EDS.  This is a Yellow Book, CCSDS 870.10-Y-0, titled "MO SERVICES AND SOIS ELECTRONIC DATASHEETS".  The MOIMS AD identified a series of conditions that were written into the body of the PDF.  It did not appear that the MOIMS and SOIS were going to reach agreement on the disposition of these comments without some help, so I volunteered to provide an analysis on behalf of SEA.  I want to enlist you in making sure that this is fair and balanced.

I am also adding Richard Melvin and Sam Cooper to this list, since Richard was the author of the document and Sam was the primary MOIMS point of contact.  I ask them to put their "SAWG hats on" and participate in as unbiased a way as they are capable of, while offering any technical clarity and accuracy is needed.  In this they are supplemented, of course, by Roger and Ray.

The first thing to say about this analysis is this:
1.      We have the ASL document and our own analyses and discussions of the suite of standards to draw upon
2.      We have agreed, among ourselves and in this joint meeting, that there are three stages of MOIMS deployment into the on-board environment

Both of these are background and criteria for providing feedback.  The three stages were stated during the joint meeting and they are repeated here for reference:
1.      SOIS device interfaces, subnets, and services on-board with the usual Real Time flight software and resource constraints, MOIMS only on ground, typical TT&C interfaces between them
2.      Same SOIS services and RT FSW on-board, MOIMS Proxy interfaces to RT FSW on-board, "MAL" interfaces over TT&C
3.      Same SOIS services and RT FSW on-board, MOIMS MAL adapted to RT environment and "standard" MOIMS services migrated on board as appropriate
Attached is the modified draft CCSDS 870.10-Y-0 document, in PDF form.  It has three kinds of notes in it:
1.       Notes that show up as a white square came from MOIMS
2.      Notes that show up as a yellow square with a "thought bubble" also came from MOIMS
3.      Notes that show up as a magenta square, are comments from me as to responses and rationale
4.      Notes that show up as a red square are suggested changes to the draft document, many in response to MOIMS issues, some reflecting issues I found in reading the document
You will see that I recommend adding text to reflect the three stages we have agreed to, even though that is new material from the SAWG.  I think it will help to clarify the options relating to deployment.  Some of the MOIMS comments attempt to push boundaries and I suggest that not be allowed.  Existing scope, functions, and standards are to be respected. Some MOIMS comments propose on-board services, like MO compliant device interfaces, that are very speculative.  I think that they should be labelled as such since there are no MOIMS documents that can be referenced.  The current work in SOIS to define use of EDS to document deployments of components and spacecraft configurations, however, is within scope since they are actively working on that.  I also found that this document, in general, is lacking a recognition of the importance of specifying interface bindings along with behaviors and data structures.  I recommend that it gets added.
Please review these MOIMS comments and my proposed dispositions.  I would like to have your feedback in two weeks, by 9 November, if not sooner.  This has dragged on long enough.  Assuming we can reach consensus I will then send the final result to the combined MOIMS and SOIS teams.   I will provide final edits to the document in Word form once we have closure.
While we are working together to reach consensus I ask that you all treat these materials, and the discussion, as SAWG internal work product.
Thanks, Peter




SCISYS UK Limited. Registered in England and Wales No. 4373530.
Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK.

Before printing, please think about the environment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20181029/e1c2dc12/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A Representative Application of a Layered Interface Modeling 2016-07-11.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 2224511 bytes
Desc: A Representative Application of a Layered Interface Modeling 2016-07-11.pptx
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20181029/e1c2dc12/attachment.pptx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: INCOSE_IS_2016_interface_ports_96.pdf
Type: application/pdf
Size: 1101508 bytes
Desc: INCOSE_IS_2016_interface_ports_96.pdf
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20181029/e1c2dc12/attachment.pdf>