The description for schedule state “Ready” in K2.6.2 states that “As soon as a schedule is Ready, it shall update its planned starting time (NxtStrTm).”
As there is no further description this implies that NxtStrTm is only to be updated in schedule state Ready. Hence NxtStrTm becomes invalid as soon as the next start time arrives and schedule becomes Running. A client then must wait until the schedule duration has ended (and schedule transitions to state Ready again) to receive information about the updated next start time (NxtStrTm). Especially when gaps between start times are short – or in extreme case start times overlap – data object NxtStrTm becomes unserviceable.
It is therefore proposed to extend description in such a way that the planned next starting time (NxtStrTm) shall also be updated when a schedule becomes Running.
Proposal
Change the description for schedule state “Ready” by replacing the sentence “As soon as a schedule is Ready, it shall update its planned starting time (NxtStrTm).” with “As soon as a schedule transitions from Not Ready to Ready, it shall update its planned starting time (NxtStrTm).”
Extend the description for schedule state “Running” by replacing the sentence “As soon as a schedule is Running, it may update its actual active starting time (ActStrTm).” with “As soon as a schedule is Running and not all of its configured start times have been consumed, it shall update its planned starting time (NxtStrTm). As soon as a schedule is Running it may also update its actual active starting time (ActStrTm). This data object …”
Discussion
Created
Status
Change to state Discussion, because the Tissue has interop character.
Additionally idea: in case all configured start time times have been consumed, quality of NxtStrTm will be changed to invalid.
03 Aug 22
Discussion (red)
I agree with the proposal. It allows clear and useful rules for the update of next start time