Improvement #3098
Need to Change 8-1 to allow multiple DOs to be written
Added by Herbert Falk over 3 years ago.
Updated over 2 years ago.
Due date:
02/08/2022 (over 2 years late)
Discuss in Upcoming Meeting:
No
Description
WG17 has identified a use case that may require a SetDataValue request to write multiple FCD/FCDAs in a single request.
8-1 has a note that prohibits this.
Proposal descriptions
This requires ACSI extension in part 7-2 and change in 8-1. To be discussed in WG10.
8-1 only maps what is defined in the ACSI.
The signature of the 7-2 SetDataValues is 1 (one) Reference. The mapping of SetDataValues therefore maps 1 (one) reference to 1 (one) MMS VariableAccessSpecification.
The "s" of values in ACSI SetDataValues is NOT determine by the usage of multiple References, but by the usage of multiple values that are needed to set a single FCD. "Values for all data attributes of A data object referenced by FCDA".
In other words: IEC 61850-7-2 also restricts the service SetDataValues to a SINGLE IEC 61850 reference.
Then we should evaluate changing 7-2 and 8-1. MMS supports the writes of multiple Variable Access Specifications and it is the same as writing a DataSet.
Remember that ACSI has an object-oriented approach. The SetDataValues service is associated to the GenDataObjectClass and not to the GenServer.
Background:
The requirement is to update multiple values in a schedule consistently.
Often only a subset of the schedule values may need to be updated, for example ValASG14 to ValASG48
Ideally the update should be done via a single message, with a single result.
Part 7.2 services appear to support two alternative methods but neither seems efficient.
- A single message with all the values whether they have changed or not
- One message per changed value
- Due date set to 02/08/2022
- ID set to 1
- Source set to WG17
- TF Unique ID set to 1 # WG17
- TF Unique ID set
- Due date updated
- Discuss in Upcoming Meeting changed from No to Yes
The underlying MMS protocol supports it, but we do not have the ACSI service.
Do we want to change the standard?
What is the use case from WG17?
Action item for Carlos: Ask Frances Cleveland about the use case and then we can study it.
The original use case (from Japan) is short term planning within a day
A schedule is prepared a day ahead. The schedule execution starts as normal.
During the day something happens which means part of the schedule for the afternoon or evening needs to be changed.
As comment #5 - option 1: the entire schedule (maybe 96 values) must be re-written, or a series of messages sent to update individual values one by one.
An alternative modelling approach: the IED needs to support both the periodic schedule and one or more alternative, short schedules with a higher priority.
When needed the alternative schedule(s) are updated and enabled to temporarily override the base schedule.
- Status changed from New to In Progress
- Discuss in Upcoming Meeting changed from Yes to No
- Proposal descriptions updated (diff)
- To discuss in WG10 changed from No to Yes
Also available in: Atom
PDF