Enhance Device Rollup to support subdevices from multiple datasets

Big Picture User Experience

Enhance device rollup from subdevices (telemetered and device object) that belong to datasets that differ from the parent device (top-level device) object dataset.

Background

With large systems it is now very common to find customers build their systems as horizontally scaled systems. This means that there are 3 systems that own and control data. To achieve this, the DOAS configuration requires to configure multiple datasets, one for each system and in some cases even more, to achieve customers operational needs.

With multiple datasets configured, there are typical 3 terms used to categorize these datasets.

1. Segregated - no RT replication between system only configuration data is replicated between 3 systems.

2. Parly shared - RT data is replicated to a dedicated system but no where else. While configuration data is fully replicated among all systems.

3. Fully shared - RT and Configuration data is fully replicated to all systems.

Although the horizontally scaled systems are designed to clearly define sections of pipeline into their own systems, in some cases to achieve these clear cut is impossible. There are points of interest where operators on both sides of this boundary require to obtain field information from or the other neighboring systems. To enable these points to replicate data to a neighboring system a partly shared dataset are used.

To monitor field operations and improve controllers situational awareness, customers use Enterprise SCADA Device object rollup feature to help SCADA operators inspect field condition at a glance. The device object can represent number of telemetry points or other devices as sub-device points. The device rolls up points data attributes meta state such as alarm, quality, tag presence, and controllability indication are rolled up to the top-level device.

Detailed Description

At present, the device rollup functionality is limited to points and sub-devices that are belong to one and only one dataset. In other words, all child points/devices must belong to the same dataset as the parent/Top-Level device. No mixed datasets are allowed.

As such this enhancement request is to enhance the DeviceMonitor Application so that the top level device can roll up above mentioned attributes from supported child DB points that has different datasets.

In essence, to remove the restriction that the Datasets of top-level device and child device/point must have the same dataset.

All other functionality that previously defined for the device shall continue working and no other change is requested.

Acceptance Criteria

• The device object shall roll up alarm, quality and tag presence from points that are configured with a different dataset from the Top-Level device.

  • Given that the data is replicated and available on the local system.

  • Dataset of a child point not required to be owned by the local system. But the data should be replicated to the system of the top level device.

• The removal of the current limitation should be applies system wide. It will be up to the customer to choose if this is required.

  • As such this should be made system wide config and not per device level. For customers that do not need this functionality, the old restrictive configuration shall remain in place.

• Controllability continues to work correctly

  • Special care should be taken to ensure that if the master point is in a non-controllable dataset, that it correctly show the device as non-controllable

Business Value

Support customer needs.

Target Version

Target version for this feature: ES2022 SP2

Version the customer is on or consuming: ES2022 SP1

Version being targeted by project or future opportunity: ES2022SP2

Enbridge has requested this be backported to ES21, but we have declined and they seem to be on board as of Aug 2022.

Customer, Project, and Deadline Details

Customers (names/projects) that will consume this: ENB

Deadlines and Commitments: Q4 2022

Commercial and/or Contractual Impacts: Will impact their ability to start POV in Q1 2023

Customers System / Architecture

Size: Small, Med, Large

Topology: Single site, Multi Site, and Enterprise

Any Unique configuration to note?: Split Realtimes, shared datasets, high load

Has this functionality been delivered before?: yes and no. Shared datasets are "normal" except in this situation when they are used for horizontal scaling/load balancing. In this case, there are likely many other applications that have unknown side effects when running them across multiple datasets, as most applications are designed to work within one at a time.

Out of Scope

No other changes to the application, just allow it to work across multiple datasets

Assumptions

Functionality of the Device rollup shall not change and is not requested.

Dependencies

Can think of any.

Upgradability

As always must be considered.

PSR - Performance, Scalability, Resilience

Important PSR aspects for this feature? same as the previous version

What if there are 10,000 of these? Same test as defined earlier in the original FDD.

How quickly is this expected to react/respond? same as the previous version

Does this impact failover / mode switch? yes

Is this assumed to have performance impact, or not? no

NFR - Non-Functional Requirements

Operating System: n/a

Other AVEVA products: n/a

3rd Party products: n/a

CPU / Memory / Disk requirements/constraints: n/a

Risks/Mitigations

PSR

Data smear

Architecture Review Required?

No

Do we need a SPIKE?

Perhaps to get more details from alarm replication behavior

Links

Aha: OASYS-525

ADO Estimate request Calss-T: https://dev.azure.com/AVEVA-VSTS/OASyS/_workitems/edit/1889194

Implementation: .