[cssm] Action 240502-05 on NSN SACP parameters

Fri Jun 14 11:56:41 UTC 2024

That sounds fine to me, and I'll be happy to participate if others think it would be useful.  Maybe having an artifact result like the updated spreadsheet that captures our collective analysis would later ease the agency reviews, etc.

I think one thing that might be good to state from my own perspective on the Service Agreement part is that given this was basically only a paper document in the past (for us at least), I don't think that 100% feature parity is what I would strive for, but rather just ensuring that:

  1.  The most critical high-level aspects are captured.
  2.  Everything is captured that would need to be referenced back from configuration profiles, and other electronic message structures.
  3.  There are plenty of things like "free text" fields that could be used to flexibly capture other information as needed.

I guess you could say I might be thinking of the need here as more like an "MVP" (minimum viable product) that is suitably useful and extensible to get us to start using it, but don't care if it's 100% suitable to fully replace (or generate) the written documents.   This line of thought probably comes through in the analysis below a bit.

From: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Sent: Thursday, June 13, 2024 8:23 PM
To: Eddy, Wesley M. (GSFC-580.0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Cc: Gnat, Marcin (JSC-MA111)[German Aerospace Center (DLR)] <marcin.gnat at dlr.de>
Subject: RE: Action 240502-05 on NSN SACP parameters

Wes,

Thank you for the really good analysis and write-up.  It strikes me that we probably should re-double our efforts some what for gathering agency service agreement parameters.  I can foresee spending some time go through this comparing agency by agency - although it would be kind of difficult over teleconferences but perhaps we could consider allocating something like 20 minutes at each teleconference to work our way through comparison of agency service agreement parameters versus the UML class diagrams as you have done for NSN. And then probably we will need to have some sort of face-to-face conclusion summary at the London meetings -- perhaps dedicating at least 1/2 day or so to rounding it all up.

Best regards,
-Erik

From: Eddy, Wesley M. (GSFC-580.0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov<mailto:wesley.m.eddy at nasa.gov>>
Sent: Tuesday, June 11, 2024 14:20
To: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Cc: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>; Gnat, Marcin (JSC-MA111)[German Aerospace Center (DLR)] <marcin.gnat at dlr.de<mailto:marcin.gnat at dlr.de>>
Subject: Action 240502-05 on NSN SACP parameters

Hello all, this is a summary of relevant parts of the 457-TMPL-0001 Word document that is on the CWE next to the DSN example, under the folder for blue book production of the SACP, in the "Planning and Dev Materials" under "Agency Profile Examples".

It is probably more useful to have this in writing / email rather than just verbally in a meeting.  The focus has been initially on making sure the service agreement is well representable, and less so on the configuration profile data with the logic that an approach based on the functional resource model will almost certainly capture what's needed (with maybe minor extension).

The template document is way more than what's needed to capture in the SACP, as it incorporates complete scope of mission SLA (service level agreements, directly relatable to CCSDS Service Agreement), special requirements, the space link interface definitions (directly relatable to CCSDS Configuration Profile), and a number of other topics related to ground interfaces, etc. (not all of which are relevant for SACP).

Note: the analysis below was started from earlier material Marcin presented, and may need to be updated a bit with regard to what is now on Github.

For the CCSDS Configuration Profile, the Section 2 content (page 13 - 23) are the relevant parts.  I think the mapping of this material to content of the ServiceAgreementDetails class of the UML model that Marcin has been presenting is roughly:

UML Class
457-TMPL Section / Content
SAGenInfo / SAGeneralInformation

  *   providerAgency is a given (NSN) and userAgency relates to 2.1.2 ("Sponsor")
  *   providerContacts and userContacts maybe aren't part of the document template (aside from signature page 3)
  *   supportedSpacecraft relates to section 2.1.1 ("Project/Mission Full Name") but goes beyond by letting the SANA identification be provided
  *   missionDescription text serves the purpose for 2.1.3 ("Mission Type") and 2.2 ("Mission Background")
  *   spacecraftCharacteristics can serve to reference an outside source with information that is in 2.1.4 ("Launch and Orbit Information") though doesn't encode it directly
  *   agreedProviderApertures and agreedUserApertures are not really apparent in Section 2 of NSN's template document, though relevant stations and antennas are indicated later in Section 4 data corresponding to configuration profiles
SAKeyMissionDates
Generally 2.1.5 ("Mission Milestones") and 2.3.1 ("Mission Integration Milestones and Customer Deliverables")

  *   srvAgrSupportStart and stop are implied based on the dates in "Committed Services" in 2.1.5
  *   missionPhases is representing similar data to Tables 2-5, 2-7, 2-8, and 2-9, however specific resource indications ("involvedResource") within the phaseDetails are not part of NSN's template, as the NSN tables are oriented towards the specific service types and volume of services during each phase (not really indicated so well by the missionPhases in the SACP)
  *   launchWindows may not be so specifically indicated in the NSN service agreement; typically vectors are updated based on specific launch windows as part of operations, and not "baked into" the agreement
SAStationInformation
Is not really a part of the agreement, which is more "network level" rather than station-level, and should especially be that way for future use of commercial services where the station may need to be very flexibly defined.
SAServiceLevel

  *   frequencyOfContacts can be used for the values that are part of Table 2-4 and 2-6.
  *   costOfService is covered in Section 2.6 ("Funding Responsibility")
  *   successCriteria is maybe a bit implicit in the NSN agreement
  *   availability may be a bit implicit in the NSN agreement, based on indication of critical events versus other phases
  *   ancillaryServices gives good flexibility to indicate other aspects that are part of some NSN user agreements
  *   productDeliveryTiming is indicated standard for services
  *   providedServiceLevels and supportPeriods can represent additional content from Table 2-5 and 2-7.
SADataStorageDelivery

  *   productRetentionTime is sort of hard-coded to a network-standard # of days, which could be overridden in specific cases, so the SACP capability to indicate explicitly seems fine
  *   productStorage is implicit
SAProvidedServices

  *   serviceList relates well to section 2.4 ("NSN Services"), and can capture the content of Table 2-4 ("DTE Standard Services") Table 2-6 ("SR Standard Services") and seems like it could extend possibly to Table 2-8 ("FDF Services") and maybe even 2.4.4 ("Terrestrial Data and Voice Services") though that may be a bit disjoint and probably not a general CCSDS service agreement need
  *   trackingConfiguration isn't really explicit in NSN's template
This could also probably be used to capture section 2.9 ("End of Mission") content.
SALicensingInfo
Should be able to capture what is in 2.3.2 ("Frequency Authorization").
SAGroundComms

  *   commsBandwidth is part of 2.4.4 ("Terrestrial Data and Voice Services")
  *   cmdLatency is nice to have, though may be implicit for some NSN cases (Note: why is this specific to commanding in the SACP, as it should apply to telemetry as well, e.g. for astronaut voice, etc.?)
  *   redundancy, being text, can I think can express what's needed nicely, though NSN's template separates the NSN's expectation (in 2.4.5 "NSN Operational Services") from the user's (in 2.4.6 "MUE Systems and Services" and 2.5 "MOC Operations") since the needed outcomes depend on both parties.
SASpaceUserNodeCharacteristics
Is not part of the NSN template for agreement data?
SATimeplan
Not sure.
SATrajectoryInfo
In general, this represents fine what is in 2.1.4 ("Launch and Orbit Information"), though actual trajectory info and format agreements for what will be exchanged during operations are later on as "Acquisition Data" e.g. in 4.3.2.3 within the scope of service management.
SASpaceUserNodeComms
Is not part of the NSN template for agreement data?

Small things maybe absent from the SACP UML, but that could be indicated through additional strings/notes attached:

  *   Source of acquisition data (e.g. user or common facility)
  *   What method of scheduling may be used
  *   Risks are part of the NSN document (2.8)

In general, I think the SA structures will be well-aligned to our NSN doc's Section 2.

I don't think Section 3 relates to anything needed in the SACP standard.

Section 4, on "Mission Interfaces" covers things for the Configuration Profile scope.  I think the approach we are taking related to the CCSDS resource model is going to result in what's needed long-term.  The aspects of the tables within the current NSN template are able to be captured, though the organization of the information is maybe quite a bit different, and some of the TDRSS-specific types of things are not as clearly indicated (they would be handled through bilaterally agreed extension, I believe).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20240614/83ced42a/attachment-0001.htm>