View Issue Details

IDProjectCategoryView StatusLast Update
0009486Part 83: UAFX Offline EngineeringSpecpublic2024-11-14 13:39
ReporterSuad Morgan Assigned ToPaul Hunkar  
PrioritynormalSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
Product Version1.00.02 
Target Version1.00.03 
Summary0009486: OPC UA FX Part 81 Does Not Convey Capabilities of Supported Data Types for Automation Component
Description

When exchanging descriptors, engineering tools are unable to predict the supported data types of the automation component due to the absence of conveying capabilities in descriptor or Part 81."

Steps To Reproduce

Engineer A exports a descriptor of Automation Component (AC) that has Functional Extension (FE) with output variables of type Int64.
Engineer B imports the descriptor, but AC B can only support variables of type Int32.
This forces the two engineers to communicate about the issue and how to fix. The specification is silent about how to include this capability or how to solve it.

TagsNo tags attached.

Activities

Emanuel Kolb

2024-09-17 18:34

manager   ~0021733

The capabilities fur supporting a built-in datatype should be present in the information model in order to be available in a descriptor. Therefore this is a task for the base facet team to define the necessary UA variables.

Paul Hunkar

2024-10-05 14:51

manager   ~0021828

I think this is something that just should be described in the Off-line descriptor. In controllers this is usually in a datasheet associate with the product. In a controller the functionblock describe what datatype they use and expose and an empty controller has no functionblocks loaded (FunctionBlock in UAFX is equivalent to FunctionalEntity). A descriptor for a Controller has no FunctionalEntities in it. If you use a different library you will get different datatypes (even an 8 bit processor can have 64 bit integers - they are just implemented in software - same for floating point). This may make sense in a device, but in the device there will be FunctionalEntities.

The idea that a descriptor does not include any information that is not obtained directly from a controller does not make sense. descriptor will have User manual and other external documentation. I would envision that for a controller it will include a description of available functionblocks (libraries). I don't think that this will be generated directly from the controller.

Emanuel Kolb

2024-11-14 13:14

manager   ~0022061

OE team agrees that information on supported data types should be in the (product) descriptor and this information does not need to be present on the online server. But this information needs to be defined in the information model and this needs to be done in part 81 (or in some other base UA spec).

Paul Hunkar

2024-11-14 13:39

manager   ~0022062

defining it in the information model, mean it is in the server - so the above comment is confusing? OPC UA has aa long list of possible datatype defined in Part 3,5,6 depending on what you are looking for. also other companion specification may further define datatypes.

Part 83 should define a section of the AML file that is to be filled in by the vendor (not generated from a Nodeset) that lists the supported datatypes, a default list could be provided in part 83, but I would just reference part 3/5 for a base list .

Issue History

Date Modified Username Field Change
2024-03-21 07:26 Suad Morgan New Issue
2024-09-12 12:56 Emanuel Kolb Target Version => 1.00.03
2024-09-17 18:34 Emanuel Kolb Note Added: 0021733
2024-09-17 18:35 Jim Luth Assigned To => Paul Hunkar
2024-09-17 18:35 Jim Luth Status new => assigned
2024-09-17 18:35 Jim Luth Project Part 83: UAFX Offline Engineering => Part 81: UAFX Connecting Devices and Information Model
2024-10-05 14:51 Paul Hunkar Note Added: 0021828
2024-10-05 14:52 Paul Hunkar Project Part 81: UAFX Connecting Devices and Information Model => Part 83: UAFX Offline Engineering
2024-11-14 13:14 Emanuel Kolb Note Added: 0022061
2024-11-14 13:39 Paul Hunkar Note Added: 0022062