8.3.2 Descriptor Import
The Descriptor Import function “imports” a Descriptor to an engineering tool.
The Descriptor Import function uses the support functions stated in 8.3.3, 8.3.5, and 8.3.6
Important tasks for Descriptor Import are:
Open and decompress the Descriptor to a temporary folder or in memory. (8.3.3);
Validate the digital signatures and certificates. (8.3.4);
Parse the Descriptor Manifest and check for the OpcUaFxVersion element (8.3.3);
Build up the file navigation structure by identifying the Root AML files and the relationship references (8.3.3);
Parse the data of the Information Model files and convert the OPC UA FX Information Model to an internal representation of the engineering tool (8.3.5).
The two main use cases for import are the import of an OPC UA FX Information Model of an AutomationComponent product and the import of an AutomationComponent configuration.
Before starting the engineering work, a Controls Engineer must select and procure the product data information for an AutomationComponent. Typically, the selection and procurement of the production data information will be made in one of three different options, as described below.
One option for procurement is to download a Descriptor with product information from the vendor’s website.
Another option exists if the Descriptor for a product can be exposed as a file or as a reference to it in the online Information Model of the AutomationComponent. A Controls Engineer who wants to see this information can retrieve this data from the online AutomationComponent by browsing the Descriptors folder and reading the AcDescriptorType instances.
A third option would be the engineering tool that already has the product information for the AutomationComponent available in its database.
Another use case for importing a Descriptor with configuration information arises in the sharing of work between Control Engineers. Engineer A exports a Descriptor with configuration information for Controller A and sends it to Engineer B. Engineer B needs to know what data Controller A is providing or is required for the Connections. After receiving the Descriptor, Engineer B imports it into an engineering tool and uses the Information Model of Controller A to complete the Information Model for Controller B, e.g., defining the complementary FunctionalEntity, InputData and OutputData information for Controller B. The exchange of a Descriptor between Controls Engineers is further described in detail in 8.4.