[Smwg] AI2017-0512-54: Create draft Tech Note on State Machines

Tue Oct 2 08:50:26 UTC 2018

Hi Wes,

You brought it nicely to the point.

Answer to 1) would be - in my opinion - definitely yes. On the other hand, maybe there would be some implementations at some agencies where they do not care about that, so they do not need that. This was I think the thought for SM-1 to make these fields optional. But I do not know if it still holds. In principle ALL of scheduling systems I know, use (in that way or another) status information which is exchanged between user and provider. And I soon we think about automation services in future, it will be obligatory anyhow.

The only reason to have that optional, which comes to my mind, is that there might be some other bilateral way (different file format, notification or carrier pigeons) to exchange the status/state.

Regarding 2) we have had already several discussions about that in last years, and every time we ended with the simplest solution having just one relevant state (SCHEDULED). There are two aspects:

a)      The partially/fully was related in SM-1 to the fact, that one Service Package could stretch over longer time period and thus actually include several physical bookings/contacts/actions. The PARTIALLY was an option to show the user, that some of the actions/contacts related to the SP has been already scheduled, but there are still some left (can't be scheduled yet, due to whatever reasons). As we focused the SP in our new attempt to more or less one contact/pass, there is no more reason for that. Either the SP is scheduled or it is not. Very binary.... ;-)

b)      The story behind TENTATIVE is more complicated, and I think also more controversial among providers/agencies and users. In previous SM-1 and some agencies (also partially in DLR) such status of the pass booking is used. It should give the user some kind of the answer "yes, we booked you in this time slot, but keep in mind, that there is some other mission/customer who has higher priority, thus he might kick you out". Typically the status changes to "SCHEDULED" after some deadline is reached (many talk about change of "priority based scheduling" into "first come, first serve scheduling" - this may happen for example 1 week ahead of the pass). Such booking with tentative confirmations gives especially for the provider/stations some profit, because they get better usage of their antenna. On the other hand, for many missions I work with, such status is useless, because the mission wants to know 100% sure they got the pass, so that they can set up on-board timeline. There is also some combination of both possible, if the mission buys itself just highest priority, it will be scheduled for sure.

We agreed in working group, that the case with no tentative confirmation is the one being most making sense, thus decided not to pursue the TENTATIVE branch. Nevertheless, maybe it would not be bad to consider some optional parameter which could convey such additional information for projects/users/providers who want to play around with TENTATIVE.

So, finally, the parameters would look like this:

-          servicePackageStatus (obligatory, with CREATED, SCHEDULED, ALTERNATIVE, EXECUTING, REJECTED, CANCELLED, ABORTED, ARCHIVED)

-          servicePackageStatusAnnotation (optional, with either Enum or even better String, where bilaterally some additional "substatus" can be agreed - for example "TENTATIVE" or "TENTATIVE, PRIO 5" or whatever....)

What are your thoughts?

Best Regards
Marcin

From: Eddy, Wesley M. (GRC-LCN0)[MTI SYSTEMS, INC.] [mailto:wesley.m.eddy at nasa.gov]
Sent: Montag, 1. Oktober 2018 18:25
To: Gnat, Marcin; smwg at mailman.ccsds.org
Subject: RE: AI2017-0512-54: Create draft Tech Note on State Machines

Hi Marcin, I like your proposal to fix and simplify the way that the service package status is indicated.

To be clear, we currently have two fields:

-          servicePackageResultStatus (can be TENTATIVELY SCHEDULED, PARTIALLY SCHEDULED, or FULLY SCHEDULED)

-          servicePackageResultType (can be NEW, UPDATE, ALTERNATE, FLEXIBILITY CHANGE)
And both are optional.

If I understand correctly, you think it would be better to consolidate to a single more explicit indication of the service package state, like:

-          servicePackageStatus (can be CREATED, SCHEDULED, ALTERNATIVE, EXECUTING, REJECTED, CANCELLED, ABORTED, ARCHIVED)

This seems basically good to me.  Two questions I have are:

1)      Should the servicePackageStatus be mandatory?  I think so.  I'm not sure why the original book had the equivalent fields as optional.

2)      How are the 3 degrees of being scheduled that the old fields conveyed (tentative, partial, or full) reflected in the state machine?

From: SMWG <smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org>> On Behalf Of Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>
Sent: Monday, October 1, 2018 8:32 AM
To: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [Smwg] AI2017-0512-54: Create draft Tech Note on State Machines

Dear all,

And here is another debt which I had in terms of an Action Item. Please see attached draft Tech Note on State Machines. Also some small corresponding presentation (content is more or less same).

Uploaded to CWE as well:
Doc:
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Administration/Inter%20Recommendation/Models/Information%20Entities%20State%20Machine%20Model/StateMachinesForCSSMInformationEntities_TechNote-v0x1.docx

PowerPoint:
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Administration/Inter%20Recommendation/Models/Information%20Entities%20State%20Machine%20Model/AI2017-0512-11_Service_Package_State_Machine_20181015.pptx

MagicDraw UML File:
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Administration/Inter%20Recommendation/Models/Information%20Entities%20State%20Machine%20Model/SP_StateMachine_20180925.zip

I saw Erik had planned some time during Fall Meetings for the State Machine topic, so maybe it would be not bad if you could drop an eye on this stuff (one more doc to be reviewed - add to the list of "Berlin Pointers" ;-). It's not long though... so maybe you can make it...

Best Regards
Marcin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20181002/cfad4d1c/attachment.html>