[Ccsds-omg-liaison] [EXT] Preliminary AB Review of the Space Telecommunication Interface (STI) RFP

[Elisa Kendall]

Hi Char,

On 6/11/2019 2:34 PM, Char Wales wrote:
Speaking for MARS - this RFP is being developed jointly with Space DTF.  It was decided a while ago that for various reasons -- among them being that the SNC WG is part of MARS  -- MARS would be the proper home for this RFP.

And yes -- the RFP is building off of and is in fact a rewrite/update/extension of the old PIM & PSM for SWRadio Components prepared by the SBC DTF in 2002 which cited the SCA as well.  Note too that NASA-- and why they're invovled in this -- used and extended the SCA to cover communications in the Space domain. Am cc'ng Steve MacLaird who can fill you in on the political issues surrounding the SCA vis-a-vis the Wireless Innovation Forum (WinF).
Ok, thanks.  I think the references and version should be included properly, then.

MARS doesn't do JUST CORBA and IDL and IDL mappings .. as you know .. There's much that can be dropped into the last two letters of MARS -- Related Services.;-)

Yes, of course, but then you need to really clean up the requirements, and say precisely what mappings you are looking for, because they are fairly vague at the moment :).

Best,

Elisa

Hope this helps rather than confuses.

Char
.
On 6/11/2019 12:30 PM, Elisa Kendall wrote:

Hi Jeff and all,

Here is my preliminary review of the STI RFP (mars/19-05-12).  I noticed
that Matthew already submitted something, but haven't reviewed his
comments, so apologies for any duplication.

First, I'm a little surprised that this is coming out of MARS rather
than the Space DTF.  I'm assuming there is a back-story there, such as
some revision to IDL or CORBA planned?

Overall - this seems like a really early draft to me.  The language
needs tightening up in lots of places, no timeline, etc., so I'll only
mention a few highlights with respect to the language, which needs some
careful review.  I will skip the overview as a result and dive into the
middle.

1. The numbering of the requirements is off - this needs to be cleaned
up and every paragraph properly numbered.  There were some duplicates
and unclear requirements numbering, among other things.

2. Fix 'Section Error! Reference source not found.,' in 6.1, second
paragraph, and the first part of that first sentence in that paragraph
is duplicative.

3. The sentence under the set of bullets in 6.1 doesn't make sense - "We
will describe problem each of these elements bring in the following" -
copy and paste errors?

4. The language in the requirements doesn't really reflect requirements
language at all for me.  For example, some of the bullets in 6.2 are a
bit hand wavy, such as being adaptable and flexible enough to support
missions starting 5 years ago and running 10 years into the future?

5. Paragraph beginning "Radiation Suitable Processing:" needs an editing
pass - words missing here and there? e.g. "certain level immunity" --.
"certain level of immunity"? "not as capable as commercial off the shelf
electronics" - explain in what way they are not as capable, leading to
requirements for this RFP? Similarly, the paragraph starting
"Specialized Signal Processing Abstraction:", and paragraph starting
"Static Deployment:" need a review pass for grammar, etc.

6. If the "PIM and PSM for SWRadio Components Final Adopted
Specification [SWR]" is expected to be reused to the extent possible, it
should be described in 6.3.1, not in a "related" section.  It is listed
as mandatory in 6.3.

7. Should the QoS elements listed in 6.5.2 (should be 3?) Networking,
under i, be more specific?  There is nothing quantitative here to say
reliability or timeliness, would be measured, under what circumstances,
to ensure that the goals of the RFP are met.

I asked a friend who actually works on software radios and has done for
years for feedback, especially with respect to 6.5.2, and he said that
the three things you need for distributed communication is a destination
address, a transport, and a protocol, which corresponds to my
recollection. I think you have the first two, but the the protocol piece
needs more work.

The trouble with space communication is the large amount of time it
takes for signals to reach a satellite. I seem to recall that it is in
the 10's of minutes to reach the outer planets of our solar system. This
issue is discussed in 6.5.2.f, but 6.5.2.b says "IP routing", so one
presumes some type of IP protocol. TCP/IP won't work for these
latencies, but perhaps UDP would be OK. Were you thinking that you
really want UDP?  The software radio specification is built on CORBA,
and he had seen examples of use of CORBA for UDP. Are you asking for
CORBA? What about the Internet Inter-ORB Protocol (IIOP) for CORBA? What
version?

8. Also, you mention security in 6.5.3, but what standard protocol?
Were you thinking about CORBA for this?

9. Then, after reading through this a couple of times - my
understanding, and again after talking with colleagues, is that a lot of
the software radio work was built on Software Communication Architecture
(SCA) version 2.2.2. The RFP mentions the SCA a couple of times. It's
now at version 4.1, and some of the new 4.1 features will address
features you are asking for. Do you want to comply to the latest version
of the SCA?  Shouldn't that be mandated?

That's it for me - I think this is still quite early, but look forward
to seeing updates next week.

Best regards,

Elisa





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20190611/3f901a00/attachment-0001.html>