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

Created: 13 Nov 2014

Status: In Force (green)

Part: Part 7-3 (2010; Edition 2)

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 date expired 08 Jun 15 In Force (green)
This is the proposal for Edition 3.

An intermediate solution (IntOp) is proposed under TISSUE 697
24 Apr 15 Ballot Period
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 Discussion (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 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.12.13.1