1329   cmdQual “persistent until feedback” was available for DPC in Ed.1 and is no more available in Ed. 2.

This tissue has following status: green

Created: 13 Nov 2014

Links: #697 persistent command / PulseConfig

Page:

Clause:

Paragraph:

Category: Issue for edition 3 of this part

Issue: Hi all,

In Edition 1, the note in cmdQual allows to use it as “persistent until feedback” for DPC.
cmdQual: this identifier shall define if the control output is a pulse output or if it is a persistent output. If it is set to pulse, then the duration of the pulse shall be defined with the identifiers onDur, offDur and numPls. If it is set to persistent, the deactivation of the output pulse is a local issue determined in the server; as an example, when a switch controlled by this control output has reached the end position, the local control logic in the in the device implementing the server will deactivate the output.

This chapter become in Edition 2:
cmdQual: this identifier shall define if the control output is a pulse output or if it is a persistent output. If it is set to pulse, then the duration of the pulse shall be defined with the identifiers onDur, offDur and numPls. If it is set to persistent, the output stays in the state indicated in the operate service.

With the Tissue 697 “the value "persistent" for cmdQual is not allowed for the usage in DPC”.

This is a loss of Functionality from Ed 1 to Ed2.
DPC is often used by customers in “Persistent until feedback” to control circuit breaker.
So this will be an issue with Ed 2 device.

Proposal: Allows the use of persistent mode for DPC with the same note than in Ed.1 i.e.:
If it is set to persistent, the deactivation of the output pulse is a local issue determined in the server; as an example, when a switch controlled by this control output has reached the end position, the local control logic in the in the device implementing the server will deactivate the output.

Discussion Created Status
?
Ballot until Editor
ballot date expired 08 Jun 15 green
This is the proposal for Edition 3.

An intermediate solution (IntOp) is proposed under TISSUE 697
24 Apr 15 final proposal 24.5.2015
1. The Problem of the interpretation of persistent is not really an issue of DPC versus SPC as the solution for TISSUE 697 assumes. It is in reality related to how the cotrol Output (on/off) is physically realised.

2. If the controlled object is internally to the device, PulseConfig shall not be present; PulseConfig is only relevant if the controlled object is linked to a physical output.

3. If there is one single physical Output and cmdQual is set to pulse; both an on as well as an off command create a pulse Output.

4. If there is one single physical Output and cmdQual is set to persistent, on command activates the Output and off command deactivates the Output.

5. If there is one single physical Output and cmdQual is set to persistemt-feedback, any command activates the Output und the Feedback deactivates the Output.

6. If there are two physical Outputs - one for on and one for off, there shall be two PulseConfig DAs - one for each Output.

7. In such a case, if cmdQual is set to pulse, the command associated to that Output shall create a pulse. The value persistent shall not be allowed for cmdQual. If cmdQual is set to persistent-feedback, the Output shall remain active until the Feedback is received.
24 Apr 15 red
Proposal for Ed2.1 / or intOp2 : add a new enumeration value for cmdQual: persistent until feedback

as pulse: means pulse,
as persistent: means persistent,
and obviosusly the despicted functionality is "persistent until feedback" wich is a pulse without a fixed duration
05 Mar 15 red

 

Privacy | Contact | Disclaimer