Hi,

Sorry, you probably saw something historical (or something we might have not updated..). Also note that this post got kind long (my usually do), but the info hopefully is useful both for you and anyone else reading this.

I assuming here that you are using SDK version 4 (preferably the latest, but anyway, this applies to whole 4.x).

We used to generate them to be directly part of the SDK, but in SDK version 4.0.0-> (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html#version-4-0-0) we no longer do that. If you need the DI/ADI/PLCOpen models you must generate them with the bundled Codegen. See the codegen/commandline/configexamples/di_adi_plcopen.xml in the distribution zip. We ship with _some_ versions of the models, but please check e.g. https://github.com/OPCFoundation/UA-Nodeset for potentially more up-to-date-ones (in practice they tend to evolve faster than we can keep track of).

This change allowed SDK users to only include the generated code if needed while also allowing easier updates of the DI model (if I recall, a version 1.02 of it was on the way when we were making the change). In addition, SDK didn’t do any manual changes to the generated output, thus users generating them would give the same result (with the overhead of needing to run the codegen). But also opened options to implement e.g. methods or anything needed to potentially utilize the models better (plus any updates to the model itself might have rendered our pre-generated classes useless if the generation might have been needed anyway on an updated model).

Thus SDK only generates the base/standard model (+GDS model, though that is mainly for client usage since we do not have any out-of-the-box-support for the server side yet), which also does mean updating that one must in practice be made by us (which was sort of problematic with OPC UA 1.04 Amendments updating it a bit faster than we were used to). Hopefully some day we can make also the base model to be updateable by SDK users, but that might be somewhat complicated if even doable (in a practical way that is).

P.S.
Also I guess I should mention that nowadays we are quite good in loading the models even without codegen, there are few edge cases where it wont work or the end result is not 100% perfect, e.g. if you have a Value tag defining a Value Attribute of a node and the value (as XML encoded; Binary would work; long story) contains a custom Structure whose field is a custom Structure it will not load, unless you have codegenerated the model defining said Structure. So depending how you need to manipulate/instantiate the loaded nodes/types, you might be good to go by just loading the NodeSet2 XMLs of the models.

P.S.2.
The number of models out there has skyrocketed, this is our (most-up-to-date) current knowledge what works: https://www.prosysopc.com/blog/nodeset-file-importing/ (the NodeSet2 XML schema is not enough to validate an OPC UA rules conforming model by itself, some models may have errors, some might need a bit of configuration due to name clashes and SDK current design). Though it should be noted that as long as the model itself loads, everything codegen is “addon” on top of that and everything the codegen uses can also be done with the base UaNode API (and StructureSpecification/DynamicStructure/EnumerationSpecification/DynamicEnumeration for custom Structure/Enumerations).