This feature is necessary for the stability and should be standard

Redundancy plays at two levels:

1) source level redundancy:
an adapter instance can loose connection or loose data flow (watchdog item) to trigger failover to either a secondary data source, or a secondary adapter

2) adapter level redundancy: if an adapter shuts down it should trigger failover to a secondary adapter (like UNIINT failover). Not sure if we need more than that (e.g. arbiter) as this has proven to be sufficient for most scenarios

Redundant is very important to guarantee to full High availability for the solution (DA, SQL, AF Vision).
It is important for the patching strategy. (trigger to switch the primary)
Actually we use OPC DA interface and we want to migrate to Adapter with the same features.
Like Kenneth Barber said it is also important when the service scrash to launch the secondary in order to continue to collect data.
That why the monitoring of some counters it is also very important.
The warm failover is more interesting in our case to not double the connection everytime.

I'm not sure that I completely understand the "specific ask", but I'll try to answer. If my answer is not what Allison was getting at, please let me know.

We currently have redundant instances of DeltaV that send their data to redundant OPC DA servers, which use redundant instances of the PI Interface For OPC DA to send data to a PI Collective in the DMZ network, which uses redundant instances of the PI To PI Interface to send data to a PI Collective on the business network. Everything that can be redundant is redundant, and we don't want to sacrifice any of this redundancy. Our PI Asset Framework and PI Analysis Service would probably also be redundant if we used them more.

As for reasons why we might expect a PI Adapter to go down, that would include everything that Ingo@Uniper said plus:
• The PI Adapter license expires (a perpetual option would be nice)
• The PI Adapter or the computer on which it is installed fails to start up for whatever reason. This includes failing to start up due to a bug in the PI Adapter.
• More wiggle room and peace of mind when making changes to the PI Adapter computer. If we have only the 1 computer, then we won't make changes to it, even if they're good changes (e.g. software/OS/security updates), for fear of disrupting the data flow and being in a rush to restore it.

Uniint failover is a very good feature to keep up data availability, in case of pi-node downtimes due to failure, maintenance, migration or other reasons. There should be a similar mechanism for adapters.

We use the PI Interface For OPC DA to send data to a PI Collective in the DMZ network, which uses the PI To PI Interface to send data to a PI Collective on the business network. Having redundancy is very important to us, so if the PI Adapter For OPC UA supported failover, then I could propose that we use it instead, and we could simplify our setup to have 1 less PI Collective and no PI Interfaces.

Nice suggestion

Hi Jiyeon,

I have a customer that is looking at Adapters, EDS and OCS as an option in a GMP/pharmaceutical setting. They realize there will have to be some concessions for cloud based software in GMP, but they would like to ensure data integrity is present from the data source all the way to the cloud service, and so have asked for adapter failover that will ensure no data loss. This is one qualification of a data integrity assessment that they would do for the solution should they decide to test it.

If PI Adapters are to eventually replace PI Interfaces and PI Connectors, this will be necessary. To many customers, having redundancy is more important than using the latest, fastest, most secure/user-friendly/lightweight/scalable technology.