8.3 Engineering tool architecture
Figure 21 presents the architecture of a hypothetical engineering tool for OPC UA FX OfflineEngineering, which has two main functions: “Descriptor Export” and “Descriptor Import” and four supporting functions for working with a Descriptor. Other functionality of an engineering tool, e.g., managing signal lists, writing control applications, modifying/extending Descriptor content, or designing safety applications, is left out of the figure for simplification.
8.3.1 Descriptor Export
The Descriptor Export function “exports” a Descriptor from an engineering tool.
Use cases for the export of a Descriptor are:
The types of vendor-specific AutomationComponent products are made available in a Descriptor as OPC UA FX AML types for usage in OfflineEngineering projects.
An OPC UA FX Information Model of an AutomationComponent configuration is provided in a Descriptor for further sharing with other engineering tools.
The Descriptor Export function uses the support functions stated in 8.3.3, 8.3.4, and 8.3.6.
Important tasks for Descriptor Export are:
Convert the internal model of the AutomationComponent to an OPC UA FX AML Information Model (8.3.6);
Collect and select the files (AML files, attachment files, embedded Descriptors) and place their files into a file structure. Part of this step is also to decide which files are included in the Descriptor or accessible by external references. (8.3.3);
Select the Root AML files and create the Descriptor manifest (8.3.3);
Create the Common Services files with the relationship references and content types as required by the Open Packaging Conventions (8.2.3);
Create the AML Container with an archiving function in the ZIP format. (8.3.3);
Sign the Descriptor with a valid certificate and add the digital signature to the Descriptor (8.3.4).
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.
8.3.3 AML Container management
AML Container management is a support function for handling AML Container and Open Packaging Conventions packages.
An overview of the tasks for container management is given here:
Identification of the Descriptor manifest, AML files, attachment files, embedded Descriptor and Common Services files;
Finding and defining the Root AML files;
Browsing the references of a Descriptor starting from the Root AML files and building a structure for navigating through the content;
Resolving external relationship references;
Creating and managing the file system of a Descriptor;
Adding and removing AML modelling files;
Adding and removing attachment files;
Adding and removing embedded Descriptor;
Updating the [Content_Types].xml file;
Compression method(s) to produce the final output;
Managing relationships, ExternalReferences, and ExternalDataReferences between the files and the content.
8.3.4 Certificate and signature management
Certificate and signature management is a support function for dealing with certificates and signature methods needed for signing a Descriptor and validating digital signatures.
An overview of the tasks for certificate and signature management follows:
Access certificates either on a file system or on a certificate store;
Secure handling of authentication factor(s), e.g., the password that may be needed for accessing a private key associated with a certificate;
Creating digital signatures according to the Open Packaging Conventions standard;
Validating a Descriptor digital signature by checking the validity of all involved certificates as defined in 7.8.2 and checking the signature hash against the hash of the content;
Ability to create a self-signed certificate that can be used if no CA-signed certificate is available;
Warning the user of signature errors (non-valid certificates, non-matching signatures);
Reporting of the scope of each digital signature of a Descriptor (which files are signed with a signature).
8.3.5 Conversion to an internal model
Conversion to an internal model is a support function for parsing the data of the Information Model AML files into the internal representation of the AutomationComponent used by the engineering tool.
An overview of the tasks for conversion to an internal model is below:
AML parser for reading the content of an AML file;
Ability to fetch additional AML libraries from links in the AML file if these libraries are not already present in the engineering tool;
Creating the objects and relationships in the internal model of the engineering tool from the parsed information.
8.3.6 Conversion to an OPC UA FX AML Information Model
Conversion to OPC UA FX AML Information Model is a support function that converts the internal model of an engineering tool to an OPC UA FX AML model, which can be serialized to a Descriptor.
The main steps for conversion are:
Ability to produce OPC UA FX AML content from the configuration done in the internal model of an engineering tool;
Serialize the model into AML files.
There are three options for producing the OPC UA FX AML content. This is shown in Figure 22.
The Controls Engineer creates the AML model directly using an engineering tool that allows the creation and editing of AML structures using the OPC UA FX AML Libraries. In this case, no conversion to AML is needed, but the serialization step is still needed.
The Control Engineer starts with the OPC UA FX Information Model in NodeSet format and uses a conversion tool to create an OPC UA FX AML file.
An existing Information Model in a vendor-specific format is converted into an OPC UA FX AML file using a vendor-specific conversion tool. For developing vendor-specific conversion tools, a software library for the creation of AML files (AMLEngine) is available from the AML Association.
