IEC 61850 User Feedback Task Force

There is no benefit in using the setting group concept - it is easier to use multiple FSCH instances.

The problem is the text in Annex K which states that values may be changed when the state is "Not-ready".
This implies values may not be changed if the schedule is running.
I think it would be safe to allow updates of the ValXXXn regardless of the state, provided that the schedule is re-evaluated after any update.

"Schedules are in one of the following four states:
• Not ready: the schedule is not ready to be run. The schedule does not contain valid entries, If schedule is in the Not ready state, values may be changed."

Tom Berry wrote in #note-4:

An example
I have a schedule with 25 entries: ValING1 corresponds to 00:00, ValING2 corresponds to 01:00 etc

At 14:00 the schedule is outputs a copy of value ValING13
Sometime between 14:01 and 15:59, I want to update the schedule values for two individual entries ValING15 (for 16:00) and ValING16 (for 17:00).

Updating just ValING15 or ValING16 makes no difference to the schedule output, so I don't think it should be to make it mandatory to send extra messages to first disable and later re-enable the schedule.
Even in the case where ValING13 is updated, it is trivial to update the schedule output immediately.

Is there a real life example where this scenario could happen? In opinion of the group - schedules are planed and their changes are not a real-time requirements, and when one or two changes are needed, they will be done once a day or a week.
Also, can this be solved with priority mechanism (usage of higher priority schedules - disabling active schedule and make a change while higher prio. schedule is running)?
Another question is about concern related to amount of data - is it due to low transfer rate or something else (GPRS usage etc.) - or it is only request for process optimization (to reduce number of steps)?
In addition, there is validation of values at the time of enabling so this dynamic change could require additional steps in state machine (to keep consistency).

The use cases are related to energy dispatch and demand response, particularly in areas where there is a lot of solar power relative to the strength of the grid.

Day-ahead markets will forecast/dispatch with regular schedules, typically 60 minutes, sometimes 30 or 15 minute intervals
Most ISOs run balancing several times a day, typically every 3-4 hours, maybe an hour ahead
Although solar irradiation can be predicted accurately well in advance, weather related aspects like wind, cloud cover, air temperature are more difficult to forecast, so generation/demand needs re-forecasting and rescheduling throughout the day.
Demand response and DER curtailment programs allow short-term scheduling which maybe a few hours in advance but some systems already work with 30,20,10 minutes notice

This particular issue is related to the number of steps.
For the IED this doesn't matter, but a client could have 1000s of devices to update.

Note: this issue only applies to the VALxxG settings data objects, where changes do not affect the instantaneous outputs
At present the standard requires three request-response messages to update a single value even though that will not have an effect on the current value until at least the next time step.

Schedule data values can be validated for min,max ranges independently of the schedule execution status.

Reference

https://reglobal.co/technology-trends-in-forecasting-renewable-energy-generation

Related to tissue #1825

Copied into WG10 improvement database

Discussed in WG10 Meeting September 2022

The key issue is to clarify the consistency checks made when updating a FSCH.
The FSCH state machine is used to ensure that a schedule is consistent before it is enabled, but part 7-4 Annex K does not provide details of the checks that must / should be performed.

Tom Berry to write a proposal to describe expected checks for each data object.
For example, changing the number of points needs a full consistency check, changing a single ASG value does not.