Project

General

Profile

Improvement #5323

Schedules - allow updates to single values while schedules are running

Added by Tom Berry 11 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Category:
Standard clarification required
Start date:
03/02/2022
Due date:
09/02/2022 (about 5 months late)
% Done:

0%

Estimated time:
ID:
3
Source:
WG17
TF Unique ID:
3 # WG17
WG10 Proposal:
Estimated Completion:
Discuss in Upcoming Meeting:
No
To discuss in WG10:
No
Short Proposal:
Standard(s):

IEC 61850-7-4,7-5

Needs More Information:

Description

Context: how to use IEC 61850 for DER and microgrids (IEC 61850-90-23 CD1).

IEC 61850-7-4 prescribes that schedules may only be updated whilst they are offline. This is a conservative approach that allows for validation of all the settings to ensure consistency before re-starting i.e. evaluating the schedule output.
There are two approaches:
1. Stop the running schedule; change it, restart
2. Write to another schedule with a higher priority and start that; stop the original schedule; change it, restart it; stop the second schedule.

This approach is unnecessarily complex for some cases. A common use case is to update a schedule for one or more periods in the future. In these cases, updating individual schedule values will not affect the current schedule output, so there is no need to require the schedule to be deactivated and reactivated.

See also #3098


Proposal descriptions

We recommend people from WG17 to explain the specific requirements to WG10 7-5 Task Force.


Related issues

Copied to IEC TC57 WG10 Future Work - WG10FutureWork #5965: Schedules - allow updates to single values while schedules are runningNew03/02/202209/02/2022

Actions
#1

Updated by Tom Berry 11 months ago

  • Standard(s) set to IEC 61850-7-4,7-5
#2

Updated by Tom Berry 11 months ago

  • Description updated (diff)
#3

Updated by Carlos Rodriguez del Castillo 11 months ago

  • Due date set to 09/02/2022
  • Category set to Standard clarification required
  • Status changed from New to Triage
  • ID set to 3
  • TF Unique ID set to 3 # WG17

Could it be possible to put the setting values in a setting group?
We need more information.

#4

Updated by Tom Berry 10 months ago

  • Subject changed from Schedules - allow updates to future values while schedules are running to Schedules - allow updates to single values while schedules are running

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.

#5

Updated by Tom Berry 10 months ago

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."

#6

Updated by Vladan Cvejic 10 months ago

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).

#7

Updated by Tom Berry 9 months ago

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.

#9

Updated by Carlos Rodriguez del Castillo 9 months ago

  • Status changed from Triage to Resolved
  • Proposal descriptions updated (diff)
#10

Updated by Henry Dawidczak 5 months ago

Related to tissue #1825

#11

Updated by Carlos Rodriguez del Castillo 5 months ago

  • Discuss in Upcoming Meeting changed from No to Yes
#12

Updated by Vladan Cvejic 5 months ago

  • Copied to WG10FutureWork #5965: Schedules - allow updates to single values while schedules are running added
#13

Updated by Carlos Rodriguez del Castillo 5 months ago

  • Discuss in Upcoming Meeting changed from Yes to No
#14

Updated by Carlos Rodriguez del Castillo 5 months ago

Copied into WG10 improvement database

#15

Updated by Tom Berry 4 months ago

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.

Also available in: Atom PDF