[Moims-mp] [Moims-sc] [CCSDS SM&C] MAL Book 521.0-B-3

Tue Feb 1 17:00:35 UTC 2022

Dear All,

This is just to document the agreements made in todays SM&C Telecon
regarding issues on the draft MAL BB which have potential impact on the MPS
BB.  These are the 3 main points noted in my previous email below, and one
further point.

1.	ObjectRef:  It was agreed that there will be a single MAL::Attribute
type ObjectRef with the SFP 19.  The MAL::Attribute type ObjectRef<T> with
SFP 20 will be removed from the MAL BB.  In MO Service specifications, such
as MPS, a field of ObjectRef type can be specified as ObjectRef<T>, where T
is a concrete MO Object type.  This indicates that the reference must be to
an MO Object of this type  and this is assumed by both provider and
consumer.  If the <T> is omitted, then the reference can be to any MO Object
type (although this may still be constrained to a limited set of MO Object
types by the MO Service specification).  A dumb encoder will always encode
all elements of the Object reference, including Area and Type; a smart
encoder with knowledge of the service specification could encode
ObjectRef<T> more efficiently by omitting the Area and Type.   This is fully
consistent with the approach already taken in the draft MPS BB.
2.	Representation of Domain:  it was agreed to revert to the
representation of Domain as an ordered List of MAL::Identifiers.  This is
also consistent with the approach taken in the draft MPS BB.
3.	Use of wildcards in Domain:  it was agreed that it should be
possible to use a wildcard at any level of a Domain hierarchy, not just the
final node.
4.	The draft MPS BB currently has one PubSub operation that has 3
different Publish/Notify messages:

Operation Identifier
monitorPlanExecutionDetail

Interaction Pattern
PUBLISH-SUBSCRIBE

Pattern Sequence
Message
Body Signature

OUT
PUBLISH/NOTIFY
activityUpdate : (ActivityUpdate)

OUT
PUBLISH/NOTIFY
eventUpdate : (EventUpdate)

OUT
PUBLISH/NOTIFY
resourceUpdate : (ResourceUpdate)
It was clarified that this is not currently supported by the MAL PubSub
Interaction pattern.  Only a single Publish/Notify message can be defined.
This will need to be updated in the MPS BB.  There are three possible
solutions: a) The operation is split into 3 separate PubSub subscriptions;
b) A supertype is defined to allow the three different Update structures to
be supported through polymorphism;  c) a structure is defined with 3
optional fields corresponding to the 3 types of update  at least one of
which must be populated.  Option a) is not ideal for MPS, b) is preferred if
possible given polymorphism constraints (cannot have two abstract parents),
c) will be adopted as a fall-back solution.
With these four decisions, the issues of consistency between draft MAL and
MPS books are resolved.  The first three points require updates to the MAL
BB but not he MPS BB.  The last point requires an update to the MPS BB.
Best regards,
Roger

From: roger.rocketbrain at btinternet.com <roger.rocketbrain at btinternet.com> 
Sent: 25 January 2022 13:35
To: 'Coelho, César' <cesar.coelho at cgi.com>
Cc: 'moims-sc at mailman.ccsds.org' <moims-sc at mailman.ccsds.org>;
'Mehran.Sarkarati at esa.int' <Mehran.Sarkarati at esa.int>;
'Peter.van.der.Plas at esa.int' <Peter.van.der.Plas at esa.int>
Subject: RE: [Moims-sc] [CCSDS SM&C] MAL Book 521.0-B-3

Dear César,

Happy New Year to you too!

Please find attached, a copy of the draft MAL book with my comments
included.

Many of the comments concern clarification  either that we have a common
understanding, or that the document itself requires additional explanation
to be clear and unambiguous to its readers.

However, with my MPS hat on, there are a couple that have potential impact
on the MPS Blue Book, specifically:
*	Are ObjectRef and ObjectRef<T> separate MAL attribute types, or two
distinct formulations of the same MAL attribute type?  And which way round
are they?  My understanding was that we had a single ObjectRef attribute
type, with an optional declaration of Object Type and Area in an MO service
standard.  If the Object Type is specified in the standard (as
ObjectRef<T>), then this can be encoded as an implicit type (i.e. Area and
Type are omitted from the encoding of the ObjectRef).  If the ObjectRef is
untyped, then the Area and Type of the referenced object must be encoded
within the attribute.
*	Representation of Domain in ObjectIdentity and PubSub operations.
My understanding was this is represented an ordered list of
MAL::Identifiers, to allow for the specification of multiple levels of
domain hierarchy, rather than a single MAL::Identifier.  If it is a single
Identifier string, then we need to define the delimiter between levels of
the hierarchy as part of the MAL standard (could be dot .).  
*	It is also stated in the draft that only the last element of the
domain hierarchy can be wildcarded (not sure how this works if it is a
single Identifier).  I think this is too restrictive, as it excludes the
possibility of subscribing to a common subsystem for multiple spacecraft in
a constellation, or multiple ground stations in a network  e.g.
galileo.*.aocs

I have detailed these points in the individual comments in the document.

Best regards,
Roger Thompson

From: MOIMS-SC <moims-sc-bounces at mailman.ccsds.org
<mailto:moims-sc-bounces at mailman.ccsds.org> > On Behalf Of Coelho, César via
MOIMS-SC
Sent: 13 January 2022 09:28
To: moims-sc at mailman.ccsds.org <mailto:moims-sc at mailman.ccsds.org> 
Subject: [Moims-sc] [CCSDS SM&C] MAL Book 521.0-B-3

Dear All,

Happy New Year!
Please find attached the updated MAL book ready for your review!
I would appreciate if you send me your feedback by the 30th of January.

Best regards,
César Coelho

Dr. César Coelho
CGI Deutschland B.V. & Co. KG  | Space
Mornewegstr. 30 | 64293 Darmstadt | Germany
T: +49 173 54100 45 | email: cesar.coelho at cgi.com
<mailto:cesar.coelho at cgi.com> 

Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
de.cgi.com/pflichtangaben.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-mp/attachments/20220201/1d429766/attachment-0001.htm>