View Issue Details

IDProjectCategoryView StatusLast Update
0009184Part 81: UAFX Connecting Devices and Information ModelSpecpublic2024-09-18 16:28
ReporterBrian Batke Assigned ToPaul Hunkar  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status resolvedResolutionreopened 
Fixed in Version1.00.03 
Summary0009184: Use of PortableRelativePath needs further clarification
Description

During discussion in the Base Facet WG, a number of questions were raised regarding PortableRelativePath usage as described in section 13:

  • should the CM always include the reference type? If not included, "all References are included" which could result in multiple NodeIds being returned. How would the CM know how to handle that?

  • even if the ref type is included, it was stated that it is possible the path could result in multiple NodeIds from the translate method.

In either case it is not clear how a CM would deterministically know how to handle multiple NodeIds from the Translate method. We should see whether this could in fact be a problem for what the CM needs to translate. And if so, either state that servers must prevent this from happening, or otherwise have mechanisms to ensure that connections are reliably made using the correct nodes.

TagsNo tags attached.

Relationships

related to 0009839 resolvedPaul Hunkar InputsFolderType should allow variables via HasComponent references 

Activities

Paul Hunkar

2024-01-12 14:59

manager   ~0020629

Last edited: 2024-03-15 12:33

this is to be address when we handle CM error reporting / processing.

we need to also add text explaining the possible error and that user should create configurations that would avoid the issue.

Paul Hunkar

2024-07-09 02:28

manager   ~0021425

A CM defines the CCS and browse paths - since a descriptor contain the AddressSpace of the Server - an engineering tool should be able to create BrowsePaths that are unique (and do not result in multiple nodes). Also the Server by definition in base OPC UA specification is to return the node that is most appropriate first, if multiple node do result and the CM should just use the first returned node.

additional text can be added to section 13 describing this expect behavior.

Paul Hunkar

2024-09-17 07:22

manager   ~0021728

Added text to Section 13 (in Browsename resolution section) describing what clients are expected to do and that unique browsepath are expect from engineering tools

Brian Batke

2024-09-17 20:35

developer   ~0021735

See comments in Part 81. I don't think the text is sufficient

Paul Hunkar

2024-09-18 10:40

manager   ~0021742

updated text

Brian Batke

2024-09-18 12:24

developer   ~0021743

Still more comments on the resolution in Part 81

Issue History

Date Modified Username Field Change
2023-10-05 15:42 Brian Batke New Issue
2023-11-03 13:49 Paul Hunkar Description Updated
2023-11-03 13:50 Paul Hunkar Assigned To => Paul Hunkar
2023-11-03 13:50 Paul Hunkar Status new => assigned
2024-01-12 14:59 Paul Hunkar Note Added: 0020629
2024-03-15 12:33 Paul Hunkar Note Edited: 0020629
2024-07-09 02:28 Paul Hunkar Note Added: 0021425
2024-09-17 07:22 Paul Hunkar Status assigned => resolved
2024-09-17 07:22 Paul Hunkar Resolution open => fixed
2024-09-17 07:22 Paul Hunkar Fixed in Version => 1.00.03
2024-09-17 07:22 Paul Hunkar Note Added: 0021728
2024-09-17 20:35 Brian Batke Status resolved => feedback
2024-09-17 20:35 Brian Batke Resolution fixed => reopened
2024-09-17 20:35 Brian Batke Note Added: 0021735
2024-09-18 10:40 Paul Hunkar Status feedback => resolved
2024-09-18 10:40 Paul Hunkar Note Added: 0021742
2024-09-18 10:40 Paul Hunkar Resolution reopened => fixed
2024-09-18 12:24 Brian Batke Status resolved => feedback
2024-09-18 12:24 Brian Batke Resolution fixed => reopened
2024-09-18 12:24 Brian Batke Note Added: 0021743
2024-09-18 16:28 Paul Hunkar Relationship added related to 0009839
2024-09-18 16:28 Paul Hunkar Status feedback => resolved