1825   Permission mode for control/setting of a scheduled entity from a client

Created: 01 May 2022

Status: Future Improvement

Part: Part 7-4 (2020; Edition 2.1)

Links:

Page: 479

Clause: Annex K

Paragraph: All paragraphs in Annex K

Issue

Our use case requires that a client can control or set a data object on demand even in a case where it is a scheduled entity and an FSCC instance for it is active (FSCC.Beh.stVal = on). Such control or setting from a client overwrites the data object and the value controlled or set by the client is valid until the next time when the FSCC instance write a new value according to the schedule.

Of course, we could guess another use case might require that such control or setting of a schedule entity should be blocked. Therefore, we would need a mechanism for switching a mode indicating whether a client can control or set a data object which is a scheduled entity.

However, the current definition of FSCC in the part 7-4 Ed. 2.1 does not have such mechanism or data object.

Proposal

FSCC should have a data object to represent the permission indicating whether a control/setting from a client is not blocked. The DO would be typed with SPS and named BlkChgTgtVal (Block a change of target value). If the stVal is true, a direct control/setting is blocked, and otherwise, a client can control or set the data object on demand.

In addition, the Annex K of part 7-4 should add a description about this switching mechanism.

Discussion Created Status
Approve 11 Oct 22 Future Improvement
Change to "Future Improvement" discussion 23 May 22 Approval (Future Improvement)
I would agree on the suggestion to deal with this issue as future improvement for part 7-5. 21 May 22 Triage
If FSCH.SchdIntv is changed, the instance of FSCH has to be in the state of "Not Ready" according to the definition in Annex K. That is;

During the Ready, Running states, the elements below shall not be changed:
• Priority of schedule
• Configuration for reusability
• Configuration for event driven execution of the schedule
• Number of schedule entries (NumEntr)
• Duration of the schedule interval (IntvEntr)
• Instances of typed value representing the schedule entries
• Configuration of (multiple) Start Time(s) of schedule (StrTm) including the configuration of periodic execution

They are described on page 486 of part 7-4 Ed. 2.1.

So, a client has to disable the FSCH instance for emergency, set the start time, duration and values for schedule, and then enable it.

This issue might have a relation to the improvement #5323 registered in the Redmine. 		21 May 22 Triage
A possible solution can be used to solve the problem. Therefore I tend to state this issue as future improvement for part 7-5. Any objections? 20 May 22 Triage
One possible solution could be setting a proper value to FSCH.SchdIntv when the emergency value is used.

I don't understand why another solution is required.
In the mentioned solution, the client doesnot need to disable the schedule to stop it (DsaReq): the emergency schedule automatically stopps, and the schedule which behaviour needed to be "overwritten" is back as the active schedule. 		06 May 22 Triage
In the case where an FSCH instance with the highest priority is used for setting an emergency value, switching back to a normal process seems to be an issue. One possible solution could be setting a proper value to FSCH.SchdIntv when the emergency value is used. Another possible solution could be using an operate.req to FSCH.DsaReq at the moment to stop using the emergency value. Both solutions need a message from a client.

If direct setting to a scheduled entity is permitted, a server can switch the process on the entity back to a scheduling process without communications from a client when it's time to start the next entity. 		06 May 22 Triage
Thank you for your comment, Thierry.

The process you show works well for setting an emergency value to a schedule operation.
However, the behavior may still be different from IED to IED when a SetDataValue.req or Operate.req for a scheduled entity is received. That is, such request may be accepted or rejected.
I'd prefer to clarify the behavior when such request is received and provide a mechanism that allows users to select the behavior.

Thank you again. 		03 May 22 Triage
For this use case, you can already today start an emergency schedule, i.e. a schedule with a higher priority than the current active schedule. The emergency schedule is configured to have a duration that last until the next originally scheduled value is active. 03 May 22 Triage
Thank you for your comment, Henry.

The behavior of FSCC is not deterministic because part 7-4 does not describe such case where an Operate.req or SetDataValues.req for the scheduled DO is received. So, some IED product may block the requests and others may accept them. I'm afraid that this may cause an interoperability issue.

But, if "Future improvement" is more suitable for the proposal, I will post this topic to it.

Thank you again. 		02 May 22 Triage
This is not an interopability issue. It's more an extension of the FSCC/FSCH mechanism. Therefore it should be categorized a "Future Improvement" (something for the discussion about edition3).
Personally I am not convinced about the need of such a DO. I don't know the use case. 		02 May 22 Triage
Let me complement the type of the proposed DO. The DO could be typed with SPC because some use cases might have a requirement to change the mode remotely. 01 May 22 Triage

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1