An OPC UA FX Descriptor defines the information for using and configuring one or more AutomationComponents. This information may contain data provided by the vendor of the AutomationComponent or configuration data produced by Controls Engineers in the OfflineEngineering phase.

A Descriptor is a digitally signed multi-document file (AML Container) containing Information Model files in the AutomationML language and other artefacts such as manuals, drawings, product pictures, binary files, certificates for authorship and conformance, etc. This is shown in Figure 5.

Figure 5 – A Descriptor as an AML Container

A Descriptor is based on the AML Container format and the Open Packaging Conventions standard. It has the file name extension “.amlx”.

A descriptor comprises up to five kinds of files (see Figure 6). It contains a Descriptor manifest file and Information Model file(s) and can contain attachment files, embedded Descriptors, or Common Services .

Figure 6 – Organization of the files in a Descriptor

The Descriptor manifest contains metadata information such as an identifier, a version number for the content and a version number for the format.

The Information Model files contain AML representations of UAFX Information Models.

Attachment files contain information useful for understanding and using the AutomationComponent in engineering, operation, or another phase of the AutomationComponent life cycle. This information can be considered supplemental to the information from the Information Model files. There is no specific format required for these files – these could be PDF, XML, image files, certificates, or even software binaries (e.g., for firmware updates).

Embedded Descriptors are useful for including information that is available in other Descriptors. For example, product-specific information could be available as a Descriptor created by the AutomationComponent vendor and embedded in a Descriptor created by an engineering tool.

Common Services files support the organization of the Descriptor content as specified by the Open Packaging Conventions standard. The Common Services can also be vendor-specific. They describe the file types present in the AML Container, the relationships between files, and the digital signatures.

A Descriptor has one or more Root AML Files. Root AML Files are the entry points from where engineering tools can parse and browse the content. The path of a Root AML File can be found by looking up a special Open Packaging Conventions relationship in the package relationship file of the Descriptor. This is explained further in 7.4.

More than one Root AML File can be used, for example, if more than one AutomationComponent is defined in a Descriptor.

The Descriptor concept supports URI-based references as the mechanism to link files and content together.

References can be used to link to content included in a Descriptor (internal references) or to reference resources outside the Descriptor (external references).

For example, a Descriptor created by a Controls Engineer containing configuration information for an AutomationComponent usually contains a reference to a Descriptor with the product information provided by the AutomationComponent vendor by either including the Descriptor with product information as an embedded Descriptor or by defining an external reference to it with a URI or URL. The example is shown in Figure 7.

With external references, it is possible to reduce the size of the Descriptor. On the other hand, in this case, the Descriptor is not self-contained and external references can be broken. Therefore, it is recommended to only use external references for well-defined and stable URIs.

Figure 7 – References in a Descriptor

There are three means to implement references in a Descriptor:

• Open Packaging Conventions define “Relationships” (Annex G.3). Relationships are encoded in special management files (with the file name extension “.rels”). Relationships can be used for internal or external file references and for identifying a file. As an example, the Descriptor manifest file or a Root AML File can be identified by specific relationships in the package relationship file of the Descriptor.
• AutomationML ExternalReferences are used for linking AutomationML content within and between Information Model files (see 7.5.2).
• AutomationML ExternalDataReference interfaces can be used for referencing attachments. The target of an AutomationML reference can be either a file or an object in an XML-based file (see 7.5.3).

A Descriptor shall contain at least one AML Information Model file. An OPC UA FX AML Information Model file is an AML file that contains an Information Model based on the OPC UA FX AML libraries.

The OPC UA FX AML libraries define OPC UA type information in the AML. The OPC UA FX AML libraries corresponding to a subset of the OPC 10000 series standards, including UAFX, DI and Safety, are described in this document. Other OPC UA FX AML libraries can be constructed by following the rules in Annex B.

Typically, a Root AML File is an OPC UA FX AML file with an Information Model of the AutomationComponent.

The OPC UA FX AML libraries that are used in an Information Model file can either be included in the Descriptor or externally referenced from the Descriptor. Included libraries can be present in the Information Model file, in a separate referenced file included in the Descriptor, or in an embedded Descriptor. External libraries are referenced by an Open Packaging Conventions relationship.

An external reference for referencing the OPC UA FX AML libraries can be used to optimize the Descriptor file size. Annex B, Annex C, Annex D, and Annex E are where the locations for OPC UA FX AML libraries are defined.

In order to provide integrity and authenticity for the Descriptor’s content, a Descriptor contains one or more digital signatures.

Digital signatures do not prevent the data of the Descriptor from being changed. However, engineering tools using the Descriptor can detect whether the content has been altered and notify the user.

It is required that a Descriptor contains at least one digital signature for the whole content. The last editor of the Descriptor usually creates this signature. This can be useful if part of the content is provided by another party or the creator of the Descriptor is different from the user that applies a change to it.

Digital signatures are also present in embedded Descriptors.

The digital signature as it resides inside a Descriptor is detailed in Figure 8.

Figure 8 – An example of a digital signature inside a Descriptor