Project

General

Profile

Improvement #3098

Need to Change 8-1 to allow multiple DOs to be written

Added by Herbert Falk over 1 year ago. Updated 10 months ago.

Status:
In Progress
Priority:
Normal
Category:
-
Start date:
08/08/2021
Due date:
02/08/2022 (about 12 months late)
% Done:

0%

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

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.


Related issues

Related to IEC 61850 User Feedback Task Force - Improvement #5321: Schedules - allow 3 values per time pointResolved03/02/202209/02/2022

Actions
#1

Updated by Thierry Dufaure over 1 year ago

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.

#2

Updated by Herbert Falk over 1 year ago

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.

#3

Updated by Thierry Dufaure over 1 year ago

Remember that ACSI has an object-oriented approach. The SetDataValues service is associated to the GenDataObjectClass and not to the GenServer.

#4

Updated by Tom Berry over 1 year ago

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

#5

Updated by Carlos Rodriguez del Castillo over 1 year ago

  • 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

#6

Updated by Carlos Rodriguez del Castillo about 1 year ago

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

#7

Updated by Tom Berry about 1 year ago

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.

#8

Updated by Vladan Cvejic 10 months ago

#9

Updated by Vladan Cvejic 10 months ago

  • 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