Custom OPC UA types: non-NS0 types are not allowed to reference non-built-in types
Description
Custom OPC UA types generated in src/Common/opcua_types/sopc_types.h
are allowed to reference themselves but it is not the case for new custom types.
Analysis
This is due to generic encoding type management and encoding type field representation which only references an array index which is always considered to be index in the SOPC_KnownEncodeableTypes
global variable array of src/Common/opcua_types/sopc_types.h
.
When generating custom types for non-NS0 types that are not part of the src/Common/opcua_types/sopc_types.h
, a dedicated global variable array is created but the src/Common/opcua_types/sopc_encodeabletypes.h
module is not able to access the array and to know it should be used neither.
Possibles treatment:
- Forbid to generate non-NS0 custom types in the script with types referencing themselves (note: Safety model requires to have some)
- Allow non-NS0 custom types to reference themselves only (cannot reference another NS except for built-in types): it might be implemented by storing the global array referenced in the EncodeableType definition
- Allow non-NS0 custom type to reference any NS custom types: it implies a) to register all types in a common structure, b) to reference them using (ns+TypeId) in field description + retrieve them with (ns+TypeId)
First step is to implement 1. to avoid creating types which will be badly interpreted by the src/Common/opcua_types/sopc_encodeabletypes.h
module if used.
2. might be a reasonable compromise but forbids dependency between several NS/Models, 3. might be hard to setup (at runtime only) and might lead to heavy treatment for those types since it require to retrieve type in a dictionary instead of simple array access for any init/clear/encode/decode.
Implementation
As stated in comment the option 2 is chosen as a reasonable compromise.
It replaces the implementation of option 1. which was implemented temporarily by commit 44f99f81.