[Moims-sc] [CCSDS SM&C] MAL Book 521.0-B-3
roger.rocketbrain at btinternet.com
roger.rocketbrain at btinternet.com
Tue Feb 1 17:00:35 UTC 2022
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
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
4. The draft MPS BB currently has one PubSub operation that has 3
different Publish/Notify messages:
activityUpdate : (ActivityUpdate)
eventUpdate : (EventUpdate)
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.
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
Happy New Year to you too!
Please find attached, a copy of the draft MAL book with my comments
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.
I have detailed these points in the individual comments in the document.
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
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
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MOIMS-SC