Issue 4757: Quality codes (dais-ftf) Source: ABB Power Technologies, Power Automation & Substat (Mr. Lars-Ola Osterlund, lars-ola.g.osterlund@se.abb.com) Nature: Uncategorized Issue Severity: Summary: Currently there is no space for user specific quality codes.The mapping between OPC and IEC61850 quality codes shall be made explicit in the DAIS spec. Resolution: see above Revised Text: Refer to comments in [1] · LOO12, LOO13, LOO14, LOO15, LOO16 and LOO17 in section 3.1.5 Actions taken: December 14, 2001: received issue October 23, 2002: closed issue Discussion: Add a new 32 bit member UserQuality in DAIS::Quality.Refer to appendix for the mapping.Remove the DAIS::ExtendedQuality.Put the EXQ_SOURCE and EXQ_TEST from the appendix in the unused OPCQuality byte.Implemented in DAISCommon.idl. 1) Add a new 32 bit member UserQuality in DAIS::Quality. 2) DAIS to IEC61850 quality code mapping. Remove the DAIS::ExtendedQuality. Put the EXQ_SOURCE and EXQ_TEST from the appendix in the unused OPCQuality byte. This mapping below is based on the IEC61850-7-3 draft version 57/519/CDV from 2001-03-16. DAIS quality DAIS detailed quality IEC 61850 quality IEC 61850 detail-quality OPC_QUALITY_GOOD <none> validity(Enum) = good <none> OPC_QUALITY_GOOD OPC_QUALITY_LOCAL_OVERRIDE (use EXQ_SOURCE instead) <refer to source> EXQ_SOURCE_PROCESS source(Enum) = process EXQ_SOURCE_PRIMARY_SUBSTITUTED (manually) source(Enum) = substituted EXQ_SOURCE_INHERITED_SUBSTITUTED (manually or by application) source(Enum) = substituted EXQ_SOURCE_CORRECTED (by application, e.g. SE) source(Enum) = substituted EXQ_SOURCE_DEFAULTED source(Enum) = defaulted OPC_QUALITY_BAD OPC_QUALITY_CONFIG_ERROR validity(Enum) = invalid failure OPC_QUALITY_BAD OPC_QUALITY_NOT_CONNECTED validity(Enum) = invalid failure OPC_QUALITY_BAD OPC_QUALITY_DEVICE_FAILURE validity(Enum) = invalid failure OPC_QUALITY_BAD OPC_QUALITY_SENSOR_FAILURE validity(Enum) = invalid overflow OPC_QUALITY_BAD OPC_QUALITY_LAST_KNOWN validity(Enum) = invalid oldData OPC_QUALITY_BAD OPC_QUALITY_COMM_FAILURE validity(Enum) = invalid failure OPC_QUALITY_BAD OPC_QUALITY_OUT_OF_SERVICE validity(Enum) = invalid oldData OPC_QUALITY_UNCERTAIN OPC_QUALITY_LAST_USABLE validity(Enum) = questionable oldData OPC_QUALITY_UNCERTAIN OPC_QUALITY_SENSOR_CAL validity(Enum) = questionable badReference OPC_QUALITY_UNCERTAIN OPC_QUALITY_EGU_EXCEEDED validity(Enum) = questionable outOfRange OPC_QUALITY_UNCERTAIN OPC_QUALITY_SUB_NORMAL validity(Enum) = questionable inconsistent OPC_QUALITY_UNCERTAIN DAIS_QUALITY_OCILLATORY validity(Enum) = questionable ocillatory EXQ_TEST test(Boolean) EXQ_OPERATOR_BLOCKED operatorBlocked(Boolean) (oldData shall be set when true) The following table describes the quality in more detail. DAIS quality DAIS detailed quality Description OPC_QUALITY_GOOD <none> Value is good. OPC_QUALITY_GOOD OPC_QUALITY_LOCAL_OVERRIDE A problem with OPC is a locally and bad value can not be reported. Such a bad value might appear if a local operator manully enter, e.g. a switch position, that not correspond to the actual value. Use EXQ_SOURCE_ to report manual entries. EXQ_SOURCE_PROCESS The value shall be provided by an input function from the process I/O or being calculated from some application function. EXQ_SOURCE_PRIMARY_SUBSTITUTED The value has been manually substiuted. EXQ_SOURCE_INHERITED_SUBSTITUTED The value has inherited the manually substituion from the source where it was picked up. One use case is when the value originate in a local control system and is collected by a central control system. If substituted in the local control system it will be indicated EXQ_SOURCE_PRIMARY_SUBSTITUTED locally and EXQ_SOURCE_INHERITED_SUBSTITUTED centrally. The value may be manually updated also in the central system and will then be indicated EXQ_SOURCE_PRIMARY_SUBSTITUTED centrally. Another use case is a calculated value where one of the input values is EXQ_SOURCE_PRIMARY_SUBSTITUTED. This shall result in the clalculated result value to be EXQ_SOURCE_INHERITED_SUBSTITUTED. EXQ_SOURCE_CORRECTED An alternate and more acurate value has been calculated by some application, e.g. a State Estimator. If this value has been used to correct the original value it shall be indicated EXQ_SOURCE_CORRECTED. EXQ_SOURCE_DEFAULTED If a default value is used it shall be indicated by EXQ_SOURCE_DEFAULTED OPC_QUALITY_BAD <none> The value is bad but no specific reason is known OPC_QUALITY_BAD OPC_QUALITY_CONFIG_ERROR There is some server specific problem with the configuration. For example the item is question has been deleted from the configuration. OPC_QUALITY_BAD OPC_QUALITY_NOT_CONNECTED The input is required to be logically connected to something but is not. This quality may reflect that no value is available at this time, for reasons like the value may have not been provided by the data source. OPC_QUALITY_BAD OPC_QUALITY_DEVICE_FAILURE A device failure has been detected OPC_QUALITY_BAD OPC_QUALITY_SENSOR_FAILURE A sensor overflow failure had been detected (the 'Limits' field can provide additional diagnostic information in some situations.). OPC_QUALITY_BAD OPC_QUALITY_LAST_KNOWN The updating has stopped but there is an old value available. The time stamp gives the age. OPC_QUALITY_BAD OPC_QUALITY_COMM_FAILURE Communications have failed. There is no last known value available. OPC_QUALITY_BAD OPC_QUALITY_OUT_OF_SERVICE The block is off scan or otherwise locked This quality is also used when the active state of the item or the group containing the item is InActive. OPC_QUALITY_UNCERTAIN OPC_QUALITY_LAST_USABLE The value is old. The time stamp gives the age. OPC_QUALITY_UNCERTAIN OPC_QUALITY_SENSOR_CAL Either the value has 'pegged' at one of the sensor limits (in which case the limit field should be set to 1 or 2) or the sensor is otherwise known to be out of calibration via some form of internal diagnostics (in which case the limit field should be 0). OPC_QUALITY_UNCERTAIN OPC_QUALITY_EGU_EXCEEDED The returned value is outside the limits defined for this parameter. Note that in this case (per the Fieldbus Specification) the 'Limits' field indicates which limit has been exceeded but does NOT necessarily imply that the value cannot move farther out of range. OPC_QUALITY_UNCERTAIN OPC_QUALITY_SUB_NORMAL The value is derived from multiple sources and has less than the required number of Good sources. OPC_QUALITY_UNCERTAIN DAIS_QUALITY_OCILLATORY To prevent some overload for event driven communication channels it is sensible to detect and suppress oscillating (fast changing) binary inputs. If a signal changes in a defined time (tosc) twice in the same direction (from 0 to 1 or from 1 to 0) then oscillation shall be detected and the detail quality identifier "oscillatory" shall be set. If a configured numbers of transient changes is detected, they shall be passed by. In this time the validity status "questionable" shall be set. If after this defined numbers of changes the signal is still in the oscillating state the value shall be set either to the opposite state of the previous stable value or to a defined default value. In this case the validity status "questionable" shall be reset and "invalid" shall be set as long as the signal is oscillating. If it is configured such that no transient changes should be passed by then the validity status "invalid" shall be set immediately in addition to the detail quality identifier "oscillatory" (used for status information only). EXQ_TEST Test shall be an additional identifier that may be used to classify a value being a test value and not to be used for operational purpose. The processing of the test quality in the client is a local issue. The indicator is completely independent from the other quality descriptors. The propagation through different hierarchical levels follows the concepts of source. EXQ_OPERATOR_BLOCKED This identifier shall be set if further update of the value has been blocked by an operator. The value shall be the information that was acquired before blocking. If this identifier is set then the identifier oldData of detail-qual shall be set too. EXQ_TIMESTAMP_ACCURACY_MASK This is the accuracy for the time stamp and can have the following valuesEXQ_TS_ACC_10_MSEC better than 10 millisecEXQ_TS_ACC_100_MSEC, better than 100 msecEXQ_TS_ACC_SECOND, in the range of secondsEXQ_TS_ACC_BAD_TIME, bad time stamp End of Annotations:===== Quality codesCurrently there is no space for user specific quality codes.The mapping between OPC and IEC61850 quality codes shall be made explicit in the DAIS spec. Add a new 32 bit member UserQuality in DAIS::Quality.Refer to appendix for the mapping.Remove the DAIS::ExtendedQuality.Put the EXQ_SOURCE and EXQ_TEST from the appendix in the unused OPCQuality byte. Implemented in DAISCommon.idl Subject: DAIS FTF 13 -> 14 To: "Arnold deVos" , "Robert Fairchild" , Steve Mauser , wavisnich@switch.com, Juergen Boldt , Linda Heaton Cc: "Jay Britton" , John Gillerman From: lars-ola.osterlund@se.abb.com Date: Thu, 23 May 2002 18:07:06 +0200 X-MIMETrack: Serialize by Router on ABB_EMEA_SMTP02/EMEA/ABB(Release 5.0.8 |June 18, 2001) at 2002-05-23 18:10:48 Hi again Bill I particularily want you to review this one. I have been asked to add accuracy for the timestamp in the quality. The change is that another two bits of the extended quality of OPCQuality now contains the timestamp accuracy. The following accuracy classes are defined EXQ_TS_ACC_10_MSEC for 10 milliseconds and better (class T0 from IEC61850) EXQ_TS_ACC_100_MSEC for 100 milliseconds and better EXQ_TS_ACC_SECOND in the range of a few seconds or better EXQ_TS_ACC_BAD_TIME the time stamp is bad IEC 61850 defines a couple of better accuracies (T1 - 1 millisecond, T2 - 100 microseconds and so on). Do we need them and shall I add them? The issue number is 4757. (See attached file: DAISFTFrev14.ZIP) /Lars-Ola ---------------------- Forwarded by Lars-Ola Osterlund/SEASY/ABB on 2002-05-23 17:51 --------------------------- (Embedded Lars-Ola Osterlund/SEASY/ABB image moved 2002-05-23 13:18 (Phone: +46 21 324 159, Dept.: NKDD) to file: pic18129.pcx) "Arnold deVos" "Robert Fairchild" Steve Mauser wavisnich@switch.com Juergen Boldt Linda Heaton "Jay Britton" John Gillerman Subject: DAIS FTF 13 Security Level:? Internal Hi DAIS FTF team After a request from John Gillerman I have made yet another update. John wants more advanced filtering functions based on the newly introduced XPath as well as filtering on source types. So to meet his requirements I have made the following changes 1) DAIS already include support for types but can't filter on them. Support for source type filtering is added by having a new TypeIDs member in the AlarmsAndEvents::Subscription::FilterSpec. A new constant telling this option is available is added const Filter FILTER_BY_SOURCE_TYPE = 0x0040; 2) The AlarmsAndEvents::Subscription::FilterSpec currently contains the two members areas and sources for filtering of sources. Both are a sequence of FilteringIdents. FilteringIdent is a union of pathname and ResourceID. FilteringIdent is the same as DAIS::ServerItemIdentification so it is replaced by it. The OPC filter style for sources is supported by the new struct struct OPCSourceFilter { ServerItemIdentifications areas; ServerItemIdentifications sources; }; The source filter is a new union that can hold either to OPC style or the XPAth style filter union SourceFilter switch(SourceFilterType) { case OPC_SOURCE_FILTER_TYPE : OPCSourceFilter opc_source_filters; case XPATH_SOURCE_FILTER_TYPE : string xpath_source_filter; }; A new constant telling if the XPath option is supported is added const Filter FILTER_WITH_XPATH = 0x0020; 3) The AlarmsAndEvents::Subscription::FilterSpec currently contains the member resons for filtering of reasons. To support XPath filtering also for reasons a new union is added union ReasonFilter switch(ReasonFilterType) { case OPC_REASON_FILTER_TYPE : ServerItemIdentifications opc_reason_filters; case XPATH_REASON_FILTER_TYPE : string xpath_reason_filter; }; 4) ...and the new filter spec now looks like struct FilterSpec { ReasonFilter reason_filter; unsigned long low_severity; unsigned long high_severity; SourceFilter source_filter; TypeIDs type_filter; }; 5) As XPath filtering is not discussed in the OPC E&A spec it is made an optional requirements such that DAIS implementations having the goal to bridge with OPC does not need to implement XPath. ------------------------------------------------------------------ The whole thing is covered by issue 5264 and the DAISFTF report is updated accordingly. (See attached file: DAISFTFrev13.ZIP) /Lars-Ola DAISFTFrev14.ZIP pic18129.pcx DAISFTFrev131.ZIP Date: Thu, 23 May 2002 17:13:55 -0400 From: "Visnich, William A" Subject: RE: DAIS FTF 13 -> 14 To: "'lars-ola.osterlund@se.abb.com'" , Arnold deVos , Robert Fairchild , Steve Mauser , wavisnich@switch.com, Juergen Boldt , Linda Heaton Cc: Jay Britton , John Gillerman X-Mailer: Internet Mail Service (5.5.2653.19) Hi Lars-Ola, Regarding the timestamp accuracy codes in issue 4757 Sorry to respond so late. In the rail and transit industry, the accuracy codes as defined (10 ms, 100 ms, 1s, bad) would be sufficient, and in most cases more than sufficient to meet the requirements of the industry. I hope that answers your question. Bill > -----Original Message----- > From: lars-ola.osterlund@se.abb.com [SMTP:lars-ola.osterlund@se.abb.com] > Sent: Thursday, May 23, 2002 12:07 PM > To: Arnold deVos; Robert Fairchild; Steve Mauser; wavisnich@switch.com; > Juergen Boldt; Linda Heaton > Cc: Jay Britton; John Gillerman > Subject: DAIS FTF 13 -> 14 > > Hi again > > Bill > I particularily want you to review this one. > > I have been asked to add accuracy for the timestamp in the quality. The > change is that another two bits of the extended quality of OPCQuality now > contains the timestamp accuracy. The following accuracy classes are > defined > EXQ_TS_ACC_10_MSEC for 10 milliseconds and better (class T0 from IEC61850) > EXQ_TS_ACC_100_MSEC for 100 milliseconds and better > EXQ_TS_ACC_SECOND in the range of a few seconds or better > EXQ_TS_ACC_BAD_TIME the time stamp is bad > > IEC 61850 defines a couple of better accuracies (T1 - 1 millisecond, T2 - > 100 microseconds and so on). Do we need them and shall I add them? > > The issue number is 4757. > > (See attached file: DAISFTFrev14.ZIP) > > /Lars-Ola > ---------------------- Forwarded by Lars-Ola Osterlund/SEASY/ABB on > 2002-05-23 17:51 --------------------------- > > > (Embedded Lars-Ola Osterlund/SEASY/ABB > > image moved 2002-05-23 13:18 (Phone: +46 21 324 159, Dept.: NKDD) > > to file: > > pic18129.pcx) > > > > > > > > > "Arnold deVos" > "Robert Fairchild" > Steve Mauser > wavisnich@switch.com > Juergen Boldt > Linda Heaton > > "Jay Britton" > John Gillerman > Subject: DAIS FTF 13 > > Security Level:? Internal > > Hi DAIS FTF team > > After a request from John Gillerman I have made yet another update. John > wants more advanced filtering functions based on the newly introduced > XPath > as well as filtering on source types. So to meet his requirements I have > made the following changes > > 1) > DAIS already include support for types but can't filter on them. Support > for source type filtering is added by having a new TypeIDs member in the > AlarmsAndEvents::Subscription::FilterSpec. > > A new constant telling this option is available is added > const Filter FILTER_BY_SOURCE_TYPE = 0x0040; > > 2) > The AlarmsAndEvents::Subscription::FilterSpec currently contains the two > members areas and sources for filtering of sources. Both are a sequence of > FilteringIdents. FilteringIdent is a union of pathname and ResourceID. > FilteringIdent is the same as DAIS::ServerItemIdentification so it is > replaced by it. The OPC filter style for sources is supported by the new > struct > struct OPCSourceFilter { > ServerItemIdentifications areas; > ServerItemIdentifications sources; > }; > > The source filter is a new union that can hold either to OPC style or the > XPAth style filter > union SourceFilter switch(SourceFilterType) { > case OPC_SOURCE_FILTER_TYPE : OPCSourceFilter opc_source_filters; > case XPATH_SOURCE_FILTER_TYPE : string xpath_source_filter; > > }; > > A new constant telling if the XPath option is supported is added > const Filter FILTER_WITH_XPATH = 0x0020; > > 3) > The AlarmsAndEvents::Subscription::FilterSpec currently contains the > member > resons for filtering of reasons. To support XPath filtering also for > reasons a new union is added > union ReasonFilter switch(ReasonFilterType) { > case OPC_REASON_FILTER_TYPE : ServerItemIdentifications > opc_reason_filters; > case XPATH_REASON_FILTER_TYPE : string xpath_reason_filter; > }; > > 4) > ...and the new filter spec now looks like > struct FilterSpec { > ReasonFilter reason_filter; > unsigned long low_severity; > unsigned long high_severity; > SourceFilter source_filter; > TypeIDs type_filter; > }; > > 5) > As XPath filtering is not discussed in the OPC E&A spec it is made an > optional requirements such that DAIS implementations having the goal to > bridge with OPC does not need to implement XPath. > > ------------------------------------------------------------------ > > The whole thing is covered by issue 5264 and the DAISFTF report is updated > accordingly. > > (See attached file: DAISFTFrev13.ZIP) > > /Lars-Ola > << File: DAISFTFrev14.ZIP >> << File: pic18129.pcx >> << File: > DAISFTFrev13.ZIP >>