[Sea-sa] CESG: My notes from the MOIMS / SOIS issues discussion on Friday afternoon

[Shames, Peter M (312B)]

Dear CESG members,

I wanted to make sure that I provided some notes while they were still fresh in my mind on what I heard stated during the discussion of the issues that were surfaced in the context of the MOIMS / SOIS Yellow Book.  That presentation, with the agreed front page markings, has been put into the CWE CESG 2019 Spring Meeting folder, https://cwe.ccsds.org/cesg/docs/Forms/AllItems.aspx?RootFolder=%2Fcesg%2Fdocs%2FCWE%20Private%2FMeetings%2F2019%20Spring%20Meeting%20Mountain%20View%2FCESG%20Meeting%2C%2010%20May%202019&FolderCTID=0x0120008F128D83E4774A40906DD60662AC3B27&View=%7B448728FC%2D9186%2D4BCF%2D80F0%2D192B39C01942%7D.

Based on the feedback during the CESG discussions I believe that there is agreement on the following points which start to fill in part of the “terra incognita” that has existed to date in this discussion:

  1.  Agreement that Spacecraft are controlled by reliable, robust, fault-tolerant, hard real time operating systems and software, and that this fact has been absent from all prior discussions.
  2.  Assertion by Mario that any MAL services that might be placed on-board are there for “remote management” purposes and that they are only for remote monitor and control and not real-time processes.
  3.  Agreement that any MAL services deployed in a real-time OS have to be implemented using Class A/B processes, and in a way that does not interfere with the actual “hard real time” apps that run the spacecraft.  Recognition that this limitation might be relaxed a little if a separate processor were deployed to host the MO services on-board, and possibly if a separate, tightly controlled OS partition were possible.
  4.  Statement from Mario that MO never intended to move their current applications on board, and that “they have to be implemented by avionics SW providers”.
  5.  Agreement that Case 0 (things as they are) and Case 1 (MO on ground, standard TT&C sent to S/C) make the most sense, that Case 2 (MO on ground, MO Façade with limited MO monitor and control interfaces on-board) may also be viable if point 3) above, is adhered to.  There appeared to be little strong support from anyone but MOIMS for any of the Case 3 variants that moved the whole MO frame work on-board.
  6.  Assertion that many of the service constructs and interchange patterns in the MAL document are either unsuited (pub-sub) or inappropriate (command / ack) for use in the real-time, on-board environment, Jonathan to provide an analysis.
  7.  Agreement that Peter is to update the Yellow Book to reflect these agreements and send it to the CESG for further review during a follow-on telecon.  The stated purpose of the Yellow Book will now be to document this interaction between SOIS and MOIMS on-board, and not just to document the comparative features of the MAL and EDS.

I would like to ask if there is concurrence among the CESG that these are the essential parts of the discussion on which we do have agreement.  Please provide that feedback before reading further.


There was a long discussion of what it would mean to be “MO compliant in the on-board environment”.  There were assertions by Mario and Scott that being compliant with the MO “requirements” in the Blue Book would be sufficient.  The issue with this is that the SM&C WG has always agreed that in order to turn their very abstract, and not directly implementable, “Blue Book” into a fully implementable, normative, and interoperable spec that two other “technology binding” specs, and an API, must also be specified.  These two technology bindings would include an instance of some presentation layer binding, turning the abstract PDUs emitted by abstract services into actual “on-the-wire” data structures, and an instance of some transport layer binding which would actually be used to transfer PDUs from the service user to the service provider.  Absent these concrete bindings there is no interoperable protocol spec, nor real PDUs, just abstractions.  The SM&C MAL is only “Blue” once you have constructed such a three layer sandwich.  Absent that it is just abstractions.

Please keep in mind that an API is of value for cost savings and portability, but in and of itself provides no interoperability.  It’s a Magenta Book.

Quoted from the MO MAL, CCSDS 521.0-B-2e1.

Sec 2.1 General

The MO service specifications and the MAL are abstract in their definition; they do not contain any specific information on how to implement them for a particular programming language or transport encoding. Moving from the abstract to the implemented system, two other specifications are needed. One is the Language Mapping that states how the abstract MAL and MO service specifications are to be realised in some specific language: this defines the API in that language. The second is the transport mapping from the abstract MAL data structures into a specific and unambiguous encoding of the messages and to a defined and unambiguous mapping to a specific data transport. It is only when these mappings are defined that is possible to implement services that use the MAL interface and use the transport bindings to exchange data. (For further information on this, see reference [1, Mission Operations Reference Model. CCSDS 520.1-M-1].
The assertion was made by Scott that an implementation could somehow comply with the “MAL” requirements, which I interpreted to mean as stated in the MAL Blue Book, but without such a technology binding.  But the MAL consists entirely of abstractions and by its very nature does not describe anything that can be directly implemented.  In fact, I believe that this abstract “MAL” document would also need the Mission Operation Common Object Model, COM, CCSDS 521.1-B-1, and the Mission Operations Monitor & Control Services, CCSDS 522.1-B-1, in order to provide a set of even basic M&C functions that is in any way complete, even in this abstract sense.  See the following.

Quoted from the MO COM, CCSDS 521.1-B-1

Sec 2.2.1 General

The COM provides a standard data object model for MO Services to utilise. Whereas the MAL provides the building blocks that can be used to define the operations of a MO service, the COM provides the building blocks for the specification of the data objects of a service. This builds upon the MAL to define a standard data model for an MO service.
And, quoting from  the MO M&C Services, CCSDS 522.1-B-1

Sec 2.1 General

The MO M&C services build upon the layering concept outlined in reference [D1, Mission Operations Services Concept. Issue 3. CCSDS 520.0-G-3] and are defined in terms of the MO MAL outlined in reference [2, Mission Operations Message Abstraction Layer. Issue 2. CCSDS 521.0-B-2], so it is possible to deploy them over any supported protocol and message transport. The M&C services are also defined in terms of the COM, as defined in reference [3, Mission Operations Common Object Model. Issue 1. CCSDS 521.1-B-1], and builds upon the COM activity tracking service, the COM event service and the COM archive.

NOTE – The services defined in this specification are not dependent on any of the other services, other than the COM services, and are complete in their own right. An implementation is free to opt out of any service and also any capability set of these services; however, it may not make sense to support certain services without others.

Sec 2.2 MONITOR AND CONTROL CONCEPT

The M&C service provides the basic ability to monitor and control a remote entity. It provides three basic classes of information:

– Actions allow executable tasks to be invoked and their evolving status to be monitored: spacecraft telecommands are an example of an action.

– Parameters provide status monitoring capability but also may have their value set.

– Alerts provide a mechanism for asynchronous notification of operationally

significant events or anomalies by the service provider to the service consumer.

In most modern systems the M&C services will be used in conjunction with higher level services such as automation and planning, which utilise the M&C services to fulfil their high level functions. For example, a planning service may take in requests to perform activities, these may get decomposed into automated procedures executed by the automation system, which in turn may monitor and control the remote entity using the M&C services:

According to these docs all three of these abstract specs are required to specify even the most basic “MAL services”, but more importantly, none of this abstract stuff provides real, on-the-wire, bindings of any sort, those must be specified separately as “technology bindings”.  There are none of these available at present for any flavor of real time environment.  The current MAL Space Packet Transport binding, which is probably the most efficient, has a 29 byte header in the best case (including the mandatory 6 byte SPP fields).  This is hardly “efficient” for sending commands and telemetry that may only be a few bytes of real data around on a spacecraft, or even over a space link.  That is a lot of overhead.  I assert that it is completely unsuitable for use on-board.  A recent email discussion with Sam Cooper (28 Feb 19), re the Yellow Book, confirmed this.

>> 1) Well you don't need to "put MAL on-board" you just need to encode to the MAL SPP format. But your assumption is that people have something existing and are modifying it. If we assume that people are developing something new (and they do all the time for missions) then they are not doing any more testing than previously. Supporting a new/different protocol is day to day business in embedded SW development. So I disagree that it is anything special/specific to the use of MO.
>> 2) Personally I would strongly recommend people don't use CCSDS SPP onboard, it is not a great packet format, being neither a transport nor a true protocol. I think you said to me once its a PDU without the "P" :-)
>> 3) It is the same in most embedded systems, which is why SPP is not a great choice. This why most devices do not speak SPP but their own protocol, and this is why something like EDS is great because it allows and supports that.
>> I think for me I would like to see for case 3 "MO" only used between flight applications, not to devices. Flight applications can then use EDS/SOIS to talk to the devices in their devices specific protocol. This is not a hard and fast rule, in some situations I would expect to see "MO" spoken between an instrument and a flight application when the instrument is a more capable instrument. So probably a camera I would not expect it, but something like a star tracker that is quite powerful then yes. But like I say I would not expect it to be a hard rule (why should it be?!).

During the CESG meeting the assertion was made that SM&C WG, or someone else, could develop some new, efficient, on-board mappings of the MAL to a suitably efficient on-board, real-time, messaging service and that this would be compliant.  I agree that this is possible, but if it has occurred it is not standardized and there do not appear to be plans to create such an efficient binding.    Furthermore, in the CCSDS context any such binding ought to adhere to the SOIS Packet and Subnet services, and probably ought to be described using the SOIS EDS.  We did not even get into that part of the discussion of the SOIS / MOIMS intersection, but I think there is fertile ground to be plowed relating to how to use EDS to describe S/C and device interfaces such that MO could control them from the ground.

I am going into all of this detail so that those of you who may not be familiar with the details of how MOIMS SM&C is specified will gain some understanding of its complexities.  And those three documents, taken together, really only define a set of very primitive services: Action, Parameter, Alert, Check, Statistics, Aggregation, Conversion, and Group.  The COM provides three other slightly higher level services: Event, Archive, and Activity Tracking.  All of the other higher level services have yet to be specified.

As I said during the meeting, I think we need to present a set of recommendations to our users, in the YB and in the ASL GB, that are not just intellectually interesting, but that actually make sense.  I will be working to create an update of the SOIS Yellow Book , CCSDS 876.0-Y-10, MO Services and Electronic Datasheets.  I’ll also provide some new MOIMS / SOIS intersection diagrams, and case diagrams, that reflect the agreements we reach.  I will review these with the rest of the SEA SAWG before sending them out more widely.

Thanks, Peter




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-sa/attachments/20190513/49a7f9aa/attachment-0001.html>