[Ccsds-omg-liaison] Space Telecommunication Interface (STI) RFP - Prelim AB Review

Mon Sep 9 12:31:33 UTC 2019

Since Space DTF keeps getting mentioned, I thought I would respond.  Jeff Smith, et al, have kept Space DTF informed on the progress of this RFP.  One of the major reasons we haven’t taken it on as a TF is that most of the CORBA/IDL/SCA expertise we would need is in MARS.  I am not opposed to having it proposed as a domain specification, but it is likely the evaluation, feedback, and revision would be mostly the same people that are bringing it forward in MARS, so at a minimum, it would have to proceed jointly as a domain RFP.  The largest area of overlap with other domains and the reason for a platform rather than domain specification would be the area of Disruption Tolerant Networking, which is applicable across robotics, IoT, mobile communications, etc.  Space has a slight advantage that many communication disruptions can be predicted and planned due to physics, but DTN is definitely applicable to many domains, so a platform specification may be the best place.  Perhaps a title change would help with acceptance as a platform RFP and specification.

Brad

From: Jason Smith <jason at elementalreasoning.com>
Sent: Sunday, September 8, 2019 10:40 PM
To: Jeff Smith PhD <jeff.smith at macefusion.com>; mars at omg.org
Cc: space at omg.org; ab at omg.org
Subject: Space Telecommunication Interface (STI) RFP - Prelim AB Review

Greetings all!

This is my preliminary AB feedback report on the Space Telecommunication Interface (STI) RFP: mars/19-08-02.  I have not conferred with colleagues, and this does not preclude later comments.

Some general notes before getting into specifics…

Like a good scotch this is bold, complex, and a little hard to define.  Luckily, I like scotch, because the lack of clear definition here is a bit hard to swallow in a few places, which I will go into later.  I don’t believe it’s unfixable, however.  Overall, I like the goal and the direction, it builds on existing specifications (not always clearly), and goes into new territory.  (I really wanted to say ‘frontiers’ here, but that was a bit too on the nose.)

But first, a question… why MARSPTF and not SpaceDTF?  It appears as if it could fit in either due to the middleware aspects, but wondering why the choice of the *platform* TF when the domain TF seems to be a much better fit?  Are there areas outside of Space domain that this would be applicable?  Has the SpaceDTF been given a chance to weigh in?

Introduction:
This seems straightforward, build on SWRadio to add Space specific solutions.  Got it.

6.1: Problem statement:
pg 18:
Paragraph 1, line 11: The OMG originally commercialized?  I don’t think we’re supposed to do that.  “standardized” “developed” “published”…

Ah, here’s my concern popping up.  Last paragraph pg 18 under Figure 1, flowing into page 19:  “Even though the SWRadio specification defines radio […] it does not address key communications and platform requirements imposed by the space domain sufficiently.”  That makes me think SpaceDTF if this is Space specific.  To be clear, this is not a showstopper if all have agreed that MARS is the place to put it, it just seems like an odd choice from this vantage.

pg 19:
This is exacerbated by the end of that same paragraph: “The extent of reuse of the existing SWRadio Profile will be up to the submitters.”  If using this SWRadio Profile is not required… is it just to be considered informative?  If so, then this is a further step away from a platform solution to a domain solution, and SpaceDTF should be at least signing off on this.  Again, if there is communication and agreement to place it here for whatever reason, the concern is waived.

“This RFP is intended to address issues with the following elements:” —> “This RFP is intended to solicit submissions that address issues with the following elements:”  The RFP doesn’t address the issues.  It states them.

Under ‘Spacecraft Resource Constraints’: “An item limiting […] is the available resources …”  Perhaps ‘property’ instead of ‘item’, “Properties limiting […] are the available resources…”

pg 20:
Space Waveforms:“The architecture will have applicability greater than 2 GHz.”  I would think that a sliding scalability (think log) would be more important here than a declaration of frequency width.  kHz resolution at 10MHz is (arguably) more important than kHz resolution at tens of GHz.

6.2: Scope:
pg 21:
Normally there’s a comment about not using color in diagrams unless absolutely necessary, but that kind of goes out the window with Figure 1, so I’ll let this one pass.  Unfortunately this is also where my understanding of how the SWRadio, SSRC, STRS and STI are supposed to interact, fell down, scraped its knee, and wanted a lollipop.  (Again, the prevalent use of an unmodified ‘Space’ descriptor here makes me wonder about the TF placement…)

“Submitters shall provide responses that not only respond to STRS specific requirements […]” Okay, so are the STI requirements a *superset* of STRS requirements?

“Examples of benefits’ isn’t scope of proposals, it’s end results.  I would think this would be more suitable in Sec 6.1 explaining why this is necessary as a proposal.

This section is really unclear to me.  The introduction was fine, and it seemed to lay out a sensible roadmap.  Section 6.1 laid out the case for the constraints quite well, I was expecting a scope and requirements that hit on those issues while building on SWRadio.  Instead, it’s a conceptual frappé.  I would hope that it is clear to those versed in the art here, but to my external reviewer sensibilities, I honestly have no idea what you expect to have submitted.  That is a problem.

6.3.1: Relationship to OMG specs
This is where I have a bit of an issue, and it is procedural, not content.  You have created a pseudo-reference list here, and back in Appendix A (which is intended to be a formal reference list), you simply refer back here.  That won’t do.  References are intended to provide an archival snapshot in time on how to obtain specific information.  These discussions of the OMG specs do not, they simply have a bracketed acronym prefixed to them.

Please provide a proper Appendix A with full references, and then refer to those references here for the discussions.

6.3.2: Other OMG Docs and WIP:
As with 6.3.1.  Provide references in Appendix A, and refer to them here.  I am curious though, why are SysML and UML listed here, and not under 6.3.1?  This section is for documents and works in progress that have not yet been adopted.  If you are referring to versions of SysML and UML that are still in the works, then please note that and change the URLs appropriately to point to the specific documents, not just the home page for the spec.  That should only be used if you don’t care which version of the spec is used or referred to, unless you note “use current version as of the date of this document”.  Same goes for 6.3.1. above - refer to a specific version if it matters, note ‘current as of this date’ if not.

6.4: Related non-OMG:
ALSO as with 6.3, and you forgot to call back to Section 6.4 in Appendix A completely.  Appendix A isn’t just for OMG items, it’s for anything referred to in this document that is not already included in Appendix B.  Luckily, you’re a lot closer to proper references here.  Copy and paste them down to Appendix A, then discuss why each one is included here.

6.5: Mandatory Reqs:
6.5.1 General
[3]: This is really asking for a *hardware* architecture specification?  What level of granularity?  SysML or something more like VHDL?  It is unclear if the requested STI HID API  is a metamodel for defining HIDs (“As part of a radio delivery, the radio supplied is require to provide a HID…”), or a specific HID.
[5]: “The STI response…”  ->  “The STI proposed submission”
6.5.2 Compliance Points
What is the plan for proof of compliance, if any?
6.5.3 Networking
[1] I assume the multi-mission mandatory req is to be determined qualitatively?
[9] Any guidance on kinds of performance metrics, as you did in [8]?
6.5.4 Security
“C2” is not defined in the document.  Add to the Appendix A.2 Glossary.

6.6: Non-Mandatory Features:
6.6.2 Interface
I’d be curious to see how the STI API bridges with these COTS interfaces. Are there established interfaces you have in mind, or is this literally ‘if you can build a bridge to a COTS system, that’s a plus’?
6.6.3 Functional
[9] Secure transmissions is a nicety?  I thought you had a whole section above in 6.5.4 that talked about how it was mandatory.  Clarify the two situations?

6.7: Issues to be discussed:
[3] POSIX alternatives?  This appears nowhere else in the document, other than the reference.  Can you elaborate on the need/reason for this?  It just comes out of left field.

6.8: Evaluation Criteria
Are there any plans for defining ‘effectiveness’ or is it to be qualitative assessment?
I’m surprised that ‘issues to be discussed’ is not higher on the list, given that the issues in 6.7 cover most of the scope.

6.11: Timetable:
I can only assume from the *VERY* rapid 6 months (and only three to LOI) that there is at least one implementation in the wings, otherwise this is an extremely compressed timeline for a spec of this complexity.

A.1: References
Create a proper reference list for 6.3.1, 6.3.2, and 6.4.  The template provided in ab/19-07-01 states the following for Appendix A, please follow it:

“<Note to RFP Editors: Insert any references specific to this RFP that are referred to in the Objective Section, Section 6 and any additional sections in the same format as in Section B.1 and in alphabetical order in this section.>”

A.2: Glossary:
Add ‘C2’ as per 6.5.4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/ccsds-omg-liaison/attachments/20190909/3d54dbde/attachment-0001.html>