[Smwg] SPDF: second WG review

Mon Dec 10 21:46:27 UTC 2018

Hi Marcin, thanks for looking this over and thinking about it.

I agree with you that servicePackageStatus would be good to keep as an optional string, and that its values could be used by the provider to (optionally) provide additional information on the status of a package (there should be no need to work out all the possible or permissible values now).  Since the activeScenario flag in ScenarioDetails already covers the case of scheduled versus alternate, we should just make sure that ScenarioDetails is clearly described as mandatory to be present when alternate scenarios are present.

From: Marcin.Gnat at dlr.de <Marcin.Gnat at dlr.de>
Sent: Friday, November 23, 2018 8:10 AM
To: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] <wesley.m.eddy at nasa.gov>
Cc: smwg at mailman.ccsds.org
Subject: RE: SPDF: second WG review

Dear Wes and SMWG,

I assume when you write about servicePackageType you actually mean servicePackageSatus (otherwise I can't find any mention of servicePackageType in the current white book).

We also said, that eventually the servicePackageStatus should be rather called servicePackageState, which however would imply actually state machine behind. As we said, this won't however be formalized for time being, therefore servicePackageStatus could stay as it is.

Now to the main issue: I agree, in case the only states would be SCHEDULED and ALTERNATIVE there is no much sense in having something else than activeScenario flag. Here is to note, however, in case the scenarios are not being used at all for specific case, than there is no other way of conveying the status (which is than apparently the only "SCHEDULED"). Here we come actually to my main question: are we than imply, that as soon the Service Package exists, it is immediately SCHEDULED? This may be appealing for the simplicity, but it does not correspond to the real life right now. I think everybody has in their scheduling systems some notion of the state or status of the request or pass or service or whatever. And they are being somehow "requested", later on are "planned" and/or firmly "booked", than are being "executed" to get finally "done". Whatever we do in CCSDS (if it will be state machine or some other mechanism) we need (in my opinion) to reflect such states/statuses.

Getting back to the state machine a bit, the question (again) is, when the Service Package actually comes into life? I remember some discussion where we've said, the Service Package actually pops up already when the request is being initially processed. This was the time, when we decided to work on the state machine (-ish) to exactly check how the Service Package actually behaves. Therefore (despite of future continuing work on that), I'd say we have currently 8 states/statuses: CREATED, SCHEDULED, REJECTED, CANCELLED, ABORTED, ARCHIVED, EXECUTING and ALTERNATIVE. What eventually comes to my mind is to actually scratch the ALTERNATIVE status, because it is truly covered by ScenarioDetails class and activeScenario parameter.

And finally, because we need to support the user's notion of pass/contact/service/schedule/request* status, the same time however are not yet so far to provide consistent state machine model or automation services which would such model support, I'd vote for keeping the servicePackageStatus as optional parameter with data type set to string, allowing in early implementation phases to bilaterally agree between user and provider how this field is being used.

*I intentionally use all these terms as synonyms, because the currently in the world used definitions are not clear, and being used randomly - users asking "what is the status of my request" often expect to hear "it is scheduled" or "is being executed" - ergo unconsciously they actually ask for status of the service or, in our terms, Service Package.

Except that, I saw you changed the servicePkgStatus into servicePkgUsage, which I think nicely now differentiates to the status itself. I like it.

Best Regards
Marcin

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] via SMWG
Sent: Dienstag, 20. November 2018 19:04
To: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [Smwg] SPDF: second WG review

Hello, as discussed in today's meeting, there is an updated SPDF book ready for the 2nd working group review:
https://cwe.ccsds.org/css/_layouts/15/WopiFrame.aspx?sourcedoc=/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Service%20Package%20Data%20Formats/White%20Book/Drafts/ServicePackageSpecification%20902.4-w0.02.docx&action=default

The question we discussed in the meeting is:

-          Right now, we have both:

o   a servicePackageType that is OPTIONAL indicating the state machine status (which right now is just whether the package is primary/active/scheduled or an alternate)

o   within the OPTIONAL ScenarioDetails, there is an activeScenario boolean that indicates the same thing

-          If we don't have any additional state machine states that are conveyed, then the activeScenario is better placed because the distinction between scheduled vs alternative is only relevant when using scenarios, in which case ScenarioDetails (and activeScenario) is present.

-          I think the servicePackageType is only useful to retain if there are additional sub-states that it would indicate, but from what I could tell in the examples Marcin worked with the group, I wasn't sure that we had any.  Marcin had some other states like 'CREATED', etc., that I think were internal, and wouldn't be relevant to the message exchanges, if I understood correct.

So, I think the options are:

1.       Get rid of servicePackageStatus. (this did not seem to be preferred in the meeting, and there might be uses for conveying states in the future)

2.       Define other states in the enumeration for servicePackageStatus, or leave it open to take some additional TBD states (e.g. by making it an xsd:string rather than an enumeration).  (this seems slightly preferable at the moment?)

3.       Leave it alone under the assumption that there will be more states we think of later that we want the servicePackageStatus to be able to convey and that we'll add them to the enumeration at some point in the future?

Other than this, I will also update the XML schema file and post that as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20181210/225a5cd6/attachment-0001.html>