The following subclauses describe some examples of Descriptors being used in OfflineEngineering. These subclauses are not introductions to special definitions of Descriptors. The intention is to demonstrate that a Descriptor, depending on the use case, can contain different information.

When starting a project in OfflineEngineering, a Controls Engineer needs access to product information for the AutomationComponents that have been selected. Traditionally, this information is available on the vendor’s website, on a storage medium provided by the vendor or included in the vendor’s engineering tool.

Typically, the product information contains an Information Model of the AutomationComponent that can be used for starting the configuration and supplemental documentation, like user manuals, drawings, pictures, firmware files or even software tools that are useful for understanding and using the product.

In OPC UA FX, the information of the AutomationComponent product contains the Asset and functional structure, (pre-configured) DataSets, capabilities, and the property name defined in OPC 10000-81.

In the Information Model, there can be variations depending on the type of the AutomationComponent:

• for a controller product, the functional structure is typically empty;
• for IO and field devices, the functional structure is typically defined.

In the case of a modular device, that asset structure contains some flexibility, e.g., connectors and slots that can be attached to a defined set of modules. A Descriptor with product information is usually created by the AutomationComponent vendor. It contains the vendor’s digital signature, which makes it possible to validate the integrity of the content and, if a Public Key Infrastructure is in place, to check the authenticity and trust of the creator of the Descriptor.

For accessing a Descriptor with product information, the vendor could make it available on the vendor’s website, include it in the database of the vendor’s engineering tool or deliver it on a storage medium together with the physical AutomationComponent.

There is also the possibility of getting the Descriptor for the AutomationComponent product from an online AutomationComponent. The OPC UA FX Information Model defines a folder Descriptors in the AutomationComponentType, which can contain instances of AcDescriptorType. AcDescriptorType is fully defined in OPC 10000-81.

An example of a Descriptor for a product can be seen in Figure 9.

Figure 9 – A Descriptor with product information

A Descriptor with configuration information contains the Information Model that incorporates the configuration of AutomationComponent. The product information can also be part of a Descriptor with configuration information, for example, in the case where the product information is relevant to understanding and using the configuration information.

The configuration information provided may be different, depending on the type of the AutomationComponent or the use case for sharing.

Configuration information dependent on the type of AutomationComponent:

• Controller configurations typically contain the FunctionalEntities together with input and output Variables, DataSets, and the publisher and subscriber capabilities.
• For IO and field devices, the configuration typically contains the values for the parameters for the built-in FunctionalEntities, the built-in DataSets, and the publisher and subscriber capabilities. For modular devices, the configuration may also include the definitions for the Asset structure, e.g., installed modules.
• For machines and modular process skids that are supplied as a single product, the configuration may be similar to field and IO devices, i.e., fixing some or restricting some configuration parameters for functions and communication.
• For machines and modular process skids that are not available as products, the configuration may include the full assembly of the hardware from other AutomationComponents, together with the configuration for each part.

Configuration information dependent on use cases for information sharing:

• When engineering the same AutomationComponent by multiple Controls Engineers, a Descriptor with configuration information may contain a full snapshot of the configuration state. For example, the saved work of one Controls Engineer can be used for the continuation of the work of the next Controls Engineer.
• When a Connection needs to be defined between two Controllers, the two Controls Engineers may provide information about the communication interfaces to each other using a Descriptor. This information would include the respective FunctionalEntities, DataSets and the publisher and subscriber capabilities, whereas non-relevant information would not be included.
• For configuration of the Connections, a special set of configuration information is needed that describes the ConnectionConfigurationSets. This can be provided with a Descriptor. The use case here is that a System Integrator has created ConnectionConfigurationSets information, and the System Integrator wants to provide it to the Controls Engineer, who is configuring the ConnectionManager component that is responsible for the connection establishment.

A Descriptor with configuration information is typically built based on data from Descriptors with product information. In this case, the relevant Descriptors with product information are either included or referenced by the Descriptor with the configuration information.

The configuration information included in a Descriptor may be incomplete. It is possible that a Descriptor only contains a partial configuration for an AutomationComponent. This can be useful when a Controls Engineer wants to share only the relevant information with another Controls Engineer.

Figure 10 shows a Descriptor with configuration information for a Controller stored in the configuration.aml file. The Descriptor with product information is included.

Figure 10 – Example of a Descriptor with configuration information

Figure 11 shows a Descriptor with configuration information and product information for a Controller. The Descriptor has an external reference to the Descriptor with product information instead of including it in an EmbeddedDescriptors file.

Figure 11 – Example of a Descriptor with configuration information referencing a Descriptor with product information from the vendor’s website

A Descriptor can also be used to share the product information of AutomationComponents building a product family. By a product family, one usually understands a range of similar products that have a set of common features but are distinct in certain aspects, like size and performance. There is no clear rule either on how small or big the common feature part is or on how many individual products a product family contains. A product family may also be split into subfamilies.

Drives are an example of a product family, as seen in Figure 12. The drives have the same basic features and a similar look and feel. The product dimensions, power, voltage, and other drive features will vary within the family, but the general structure, operation and application are the same.

Figure 12 – A drives product family

There are two examples of designing product family information with Descriptors.

Each member of a product family or subfamily is described by its own Descriptor with product information. All these Descriptors are embedded in a new Descriptor for the product family, and the Root AML Files of the embedded Descriptors become Root AML Files of this new Descriptor. This is shown in Figure 13.

Figure 13 – Example of a Descriptor for a product family using embedded Descriptors

However, this approach leads to duplication of the common part of the family data. Therefore, another example of creating a Descriptor for a product family is to combine the common part data into one OPC UA FX Information Model file and create one file for each product family member with the individual features, e.g., product identification data and distinct capabilities. This can be done either by adding the features to the common part or changing (overriding) a common part (default) feature. This is shown in Figure 14.

Figure 14 – Example of a Descriptor for a product family with common data part

In this example, the product information for a modular AutomationComponent that has been pre-configured with a known set of allowable modules is considered. In this example, the modular AutomationComponent consists of a head end and a number of modules that can be either attached to the head end or to slots in a chassis.

A Descriptor with product information for this modular AutomationComponent can contain the following elements:

• one or more Information Model AML files or one embedded Descriptor for the head end and chassis;
• one or more Information Model AML files or one embedded Descriptor for each module that can be attached;
• documentation and pictures.

Figure 15 shows the situation where the head end and the modules are described with Information Model files.

Figure 15 – Modular device Descriptor with AML files

Figure 16 shows the situation where the head end and the modules are described with embedded Descriptors.

Figure 16 – Modular device Descriptor with embedded Descriptors

In Figure 16, a module can also exist outside of the modular device Descriptor. In this case, there is a reference from the modular device Descriptor to the external module Descriptor.