Big Picture User Experience
Omnicomm API to allow protocols to update DQ and value with 4 permutations. Bad Quality only, Bad quality With value, Good Quality only and Good Quality with Value.
Detailed Description
With adoption of more sophisticated protocols more and more Data Quality determination is being transferred to the protocols and field devices.
Protocols and field devices can now send questionable, good and bad Data Quality with the field values (data). In some cases protocols send only the DQ without data at all. As such point krunching within AVEVA Enterprise SCADA has to support these options. Predominantly, these are RBE protocols and in particular OPC protocol.
AVEVA Enterprise SCADA shall be able to support these cases:
Bad Quality only - krunch engine will stale the point in question, preserve last known value, update timestamp (to indicate point was krunched) and replicate the changes to all other systems.
Bad Quality with value - krunch engine will stale the point in question, update the value, update timestamp (to indicate point was krunched) and replicate the changes to all other systems.
Good Quality Only - krunch engine will mark the point in question as fresh, preserve last known value, update timestamp (to indicate point was krunched) and replicate the changes to all other systems.
Good quality with Value - krunch engine will mark the point in question as fresh, update the value, update timestamp (to indicate point was krunched) and replicate the changes to all other systems.
In essence this can be viewed as a 2x2 matrix.
|
Update Value |
Do not update value |
Good DQ |
|
|
Bad DQ |
|
|
The common denominator of this matrix is the timestamp update and replication of timestamp and DQ.
In case protocol cannot support this. The functionality shall be used as current baseline capabilities.
This shall be configured per point basis.
In the past, AVEVA Enterprise SCADA was enhanced for protocols to indicate questionable DQ and stale the point (see OASYS-518). This feature will encapsulate and suppressed this functionality. As functionality described here, is addressing the questionable DQ as well.
Business Value
Support new protocol capabilities and stay current with Protocol and field devices evolution.
Customer, Project, and Deadline Details
Customers (names/projects) that will consume this: Extensions, SE-WWW, SE-Spain and any other SI that develops protocols.
Deadlines and Commitments: TBC
Commercial and/or Contractual Impacts: TCB
Customers System / Architecture
Size: Small, Med, Large
Topology: Single site, Multi Site, and Enterprise
Any Unique configuration to note?: DNP3, BSAP, OPC protocols and MQTT
Has this functionality been delivered before?: Yes
Out of Scope
No change to any baseline code for BSAP or OPC, other than it is possible to trigger it using both the new API and the old method
Krunch pipelene. THis will be mentioned until it is removed from product.
Assumptions
We can safely leave the existing BSAP and OPC if-statements in the krunch code, and handle this new API in addition.
Baseline should assume protocols are not using this, and set appropriate defaults.
Dependencies
Extensions protocols that will be modified to use this new API. now: DNP3 and OPC
Extensions protocols that will be modified to use this new API eventually: BSAP, OPC-UA. When this occurs, we may request that the protocol-specific code in baseline be removed, but this will depend on how the protocol design at that time.
Collect on the non-owning system is collecting the same data as the owning.
Upgradability
As a new API that will only be used by the 2024 version of DNP3 from Extensions, no upgradability considerations are required.
Maintaining the existing method is important for backwards compatibility. If/when we remove that capability, it will be handled like an API deprecation.
PSR - Performance, Scalability, Resilience
Important PSR aspects for this feature? Protocol krunch
What if there are 10,000 of these? We should anticipate very large numbers of points will use this feature, if DNP3 is being used.
How quickly is this expected to react/respond? Same as krunch now
Does this impact failover / mode switch? no
Is this assumed to have performance impact, or not? no
NFR - Non-Functional Requirements
Documentation: Doc must be updated.
Operating System: n/a
Other AVEVA products: Extensions Protocols.
3rd Party products: n/a
CPU / Memory / Disk requirements/constraints: n/a
Risks/Mitigations
API modifications in Omnicomm are high risk.
Mock-up / Supporting Information
None
Architecture Review Required?
Perhaps, although Omnicomm SME might be enough
Do we need a SPIKE?
Unlikely
