View Issue Details

IDProjectCategoryView StatusLast Update
000745710000-004: ServicesSpecpublic2023-03-22 16:40
ReporterJim Luth Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Target Version1.05.03 RC1Fixed in Version1.05.03 RC1 
Summary0007457: Registration of Server supporting nontransparent Redundancy not clear
Description

Part 12 clause 6.3.6 states for transparent "Servers that support transparent redundancy shall register as a single application and pass the DiscoveryUrls for all available instances and/or network paths".
Based on this statement presumably nontransparent servers should register separate applications which makes sense however duplicate ApplicationUris are described as 'misconfiguration'. I would expect redundant servers to use the same ApplicationUri to indicate they provide the same address space and function.
Is there a contradiction here?
If not I think we need to explain how nontransparent redundancy is expected to work with Global Services.

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0006398 closedJeff Harding 10000-012: Discovery Registration of Server supporting nontransparent Redundancy not clear 

Activities

Jeff Harding

2021-12-08 18:15

developer   ~0015504

During Working Group call we agreed that we need to clarify how non-transparent redundancy is expected to work.
Either:
1) The ApplicationUri is used to describe the Server set with each member of the set using the same Uri
2) or, there needs to be a new GDS way to associate servers in the Server Set.

Matthias Damm

2021-12-08 18:15

developer   ~0015505

Servers in a non-transparent redundancy set have unique ApplicationUris for each server in the set. Otherwise the reduancy information in the server and the discovery would not work.

Therefore each server in the redundant set needs to be registered with the GDS.
What we miss is a linking of redundant servers in the GDS but we did not publish an application information model in Part 12 (this was part of an early draft)

Jeff Harding

2021-12-08 18:15

developer   ~0015506

I think we have made a mistake sometime over the years by assuming the ApplicationUri and the ServerUri are the same. While this is true for a non-redundant server I think our original intent was to use the ApplicationUri to represent the Server Set of non-transparent redundant servers and the ServerUri to represent the individual members of the Set.
If this wasn't the case then what is the reason for having both ApplicationUri and ServerUri as separate concepts if they are always the same?

Jeff Harding

2021-12-08 18:15

developer   ~0015507

Consider using the Alias concept for Server Groups.

Randy Armstrong

2021-12-08 18:15

administrator   ~0015508

Explicitly defined behavior for that non-transparent redundant Servers in 6.3.6.

Jim Luth

2021-12-08 18:15

administrator   ~0015509

Need to clone to Part 4 to require non-transparent redundant servers shall register the Server Capability "NTRS".

Matthias Damm

2023-03-20 04:07

developer   ~0018897

6.6.2.4 Non-transparent Redundancy

Added clarification:
The Servers in the non-transparent Redundant Server Set shall use the ServerCapability NTRS defined in OPC 10000-12 for discovery including the registration with a Global Discovery Server.

Jim Luth

2023-03-22 16:40

administrator   ~0018969

Agreed to changes edited in Dallas meeting.

Issue History

Date Modified Username Field Change
2021-12-08 18:15 Jim Luth New Issue
2021-12-08 18:15 Jim Luth Status new => assigned
2021-12-08 18:15 Jim Luth Assigned To => Jeff Harding
2021-12-08 18:15 Jim Luth Issue generated from: 0006398
2021-12-08 18:15 Jim Luth Note Added: 0015504
2021-12-08 18:15 Jim Luth Note Added: 0015505
2021-12-08 18:15 Jim Luth Note Added: 0015506
2021-12-08 18:15 Jim Luth Note Added: 0015507
2021-12-08 18:15 Jim Luth Note Added: 0015508
2021-12-08 18:15 Jim Luth Note Added: 0015509
2021-12-08 18:15 Jim Luth Relationship added related to 0006398
2021-12-08 18:16 Jim Luth Assigned To Jeff Harding => Matthias Damm
2021-12-08 18:16 Jim Luth Project 10000-012: Discovery => 10000-004: Services
2022-07-05 14:15 Jim Luth Target Version 1.05.02 RC1 => 1.05.03 RC1
2023-03-20 04:07 Matthias Damm Status assigned => resolved
2023-03-20 04:07 Matthias Damm Resolution open => fixed
2023-03-20 04:07 Matthias Damm Fixed in Version => 1.05.03 RC1
2023-03-20 04:07 Matthias Damm Note Added: 0018897
2023-03-22 16:40 Jim Luth Status resolved => closed
2023-03-22 16:40 Jim Luth Note Added: 0018969