During the application and QoS engineering phase, Controls Engineers, working in an OfflineEngineering environment, first create the user programs and UAFX Applications and set up the (default) networking configuration of the End Station Components (see 6.3) on their Controller. Next, Controls Engineers set up the Connection configurations needed for sharing data between Controllers. As a final step, Connection configurations are transferred to a ConnectionManager that establishes the Connections during the workflow’s connection establishment and operation phase (see 5.6.4.5). This subclause describes the details of these steps, including the setup of network interface configurations and Connection information provided to the ConnectionManager. Complete details of the ConnectionManager are defined in OPC 1000081.
Figure 6 illustrates an example where two engineers jointly create a UAFX Application containing Controller A and Controller B while separated in time and space and potentially without physical devices. For example, Controller A might control a conveyor belt, and Controller B might be a line controller using this conveyor belt (Controller) as part of controlling a production line. Descriptors, defined in OPC 1000083, enable the engineers to share application information between their respective engineering tools. In this example, Controller B hosts the ConnectionManager (CM) for configuring and establishing the Connection.
Figure 6 – UAFX Application engineering
As the first step in this example, Engineer A creates Controller A’s User Program using an engineering tool specific to Controller A. In addition to the Controller’s program, the engineering tool is used to create the UAFX Information Model representing that program. This Information Model consists of an AutomationComponent representing the entity being created by Engineer A. Part of the AutomationComponent is the functional model representing the logical functionality of the User Program. FunctionalEntities contained in the AutomationComponent represent that functional model. Input and output Variables in the FunctionalEntity expose the data to be exchanged using Connections with FunctionalEntities in another Controller. The Variables PublisherCapabilities and SubscriberCapabilities, also contained in the AutomationComponent, describe communication capabilities such as publishing intervals and, most important for the scope of this example workflow, the QoS capabilities that this AutomationComponent supports. OPC 1000081 provides details about the AutomationComponent, FunctionalEntity, the functional model, PublisherCapabilities, and SubscriberCapabilities.
To configure the use of priority-based QoS for a UAFX Application, Engineer A sets up and references a PriorityMappingTable from each physical network interface available to the UAFX Application. Virtual interfaces inherit the PriorityMappingTable from the physical interface if they do not reference a PriorityMappingTable directly. A PriorityMappingTable consists of entries that map a combination of abstract QosCategory and PriorityLabel values to concrete PCP and DSCP values for priority-based QoS at the Ethernet and IP layer, respectively. The default PriorityMappingTable settings for priority-based QoS with UAFX are defined in 6.5.4. OPC 1000014 provides detailed descriptions of QosCategory and PriorityLabel.
For priority-based QoS at the IP layer, no additional configuration is needed. For priority-based QoS at the Ethernet layer, the UAFX Station has default VLAN interfaces created as defined in 6.5.3. To this end, Engineer A may modify the VLAN IDs or add additional VLAN interfaces. The VLAN IDs or additional VLAN interfaces can also be changed during the system integration step of the workflow (see 5.6.4.4) as appropriate for the given deployment.
In either case, the VLAN interface is represented in the Information Model by an IetfBaseNetworkInterfaceType object, as described in 6.5.3. Figure 7 illustrates the Information Model of a physical interface with the name “eth0” referencing a PriorityMappingTable, DefaultPriorityMappingTable, with at least the PriorityMappingEntries defined in 6.5.4, and an associated VLAN interface named “eth0.uafx-vlan” and VID set to 100 as defined in 6.5.3.
Figure 7 – Example Information Model for a physical interface
NOTE: Setting VlanId to zero results in Ethernet frames being transmitted through that interface as priority tagged frames, i.e., the VID set to zero in the VLAN Tag.
Once the configuration for Controller A is complete, Engineer A transfers the User Program, PriorityMappingTable, and all created network interfaces to Controller A using this Controller’s engineering tool. Engineer A also exports a Descriptor that is shared with Engineer B to complete the UAFX Application configuration. The exported Descriptor includes, amongst others, the AutomationComponent, FunctionalEntity(ies), PublisherCapabilities and SubscriberCapabilities (including QosCategories and PriorityLabels), PriorityMappingTable, and IetfBaseNetworkInterfaces representing Controller A’s User Program. OPC 1000081 provides the detailed definitions of ConnectionManager, PublisherCapabilities and SubscriberCapabilities, and PubSubCommunicationFlowConfiguration.
Engineer B creates the User Program and the UAFX Information Model for Controller B using an engineering tool specific to Controller B, much as Engineer A did for Controller A. Engineer B also imports the Descriptor exported by Engineer A into Controller B’s engineering tool, allowing Engineer B to configure the Connections between Controller A’s and Controller B’s FunctionalEntity(ies).
By importing the Descriptor from Controller A, Controller B’s engineering tool contains the UAFX Information Model for both Controllers, including the configuration of both Controllers’ AutomationComponent’s PublisherCapabilities and SubscriberCapabilities, PriorityMappingTable, and IetfBaseNetworkInterfaces. With this information, Engineer B configures the QoS and addresses for each Connection between the Controllers by setting the sender and receiver Address, QosCategory, and PriorityLabel Variables in the ConnectionManager PubSubCommunicationFlowConfiguration.
Figure 8 illustrates the Variables used by Controller B’s engineering tool for configuring the Connection’s QoS. This step involves setting the QosCategory and PriorityLabel Variables in the ConnectionManager’s PubSubCommunicationFlowConfiguration Variable. The available values for QoS are derived from the respective AutomationComponent’s PublisherCapabilities and SubscriberCapabilities Variables. More precisely, each Controller’s supported QoS options are described in the SupportedQos Array contained in the PublisherCapabilities and SubscriberCapabilities Variables. Each element of the SupportedQos Array, in turn, contains a single QosCategory value with its related DatagramQos Array. For QosCategory “opc.qos.cat://priority”, the DatagramQos Array contains a single element containing the supported PriorityLabel (e.g., “opc.qos.lbl://green”).
Engineering tools can ensure QosCategory is set consistently in both the sender and receiver by only listing those elements having the same QosCategory values in both Controller A and Controller B, i.e., the intersection of values from both Controllers. The list of supported PriorityLabels can be different in each Controller, so separate PriorityLabel lists are presented by the engineering tool for each side of the Connection.
NOTE: The example in this figure only uses standard OPC UA values for QosCategory and PriorityLabel. However, a vendor can extend the labels with vendor-specific labels should they choose (e.g., acme://blue). The only QosCategory value defined in the current release of OPC 1000014 is opc.qos.cat://priority. Table 3 defines the only standard PriorityLabel value defined in this release for opc.qos.cat://priority is opc.qos.lbl://green. Future releases may define additional QosCategory and PriorityLabel values.
In addition to the QosCategory and PriorityLabel, Engineer B can set the interface configuration in the NetworkInterface Variable to be used by a Connection as part of the PubSubCommunicationFlowConfiguration sender and receiver Address parameters. A NetworkInterface Variable may either be the BrowseName of a physical interface or a VLAN interface. The NetworkInterface Variable may also be set to an empty string. In this case, the AutomationComponent chooses the appropriate network interface (e.g., using a routing table). All available network interfaces available to the UAFX Application, including VLAN interfaces, are contained in the NetworkInterfaces Folder defined in OPC 10000-22. The System Commissioner can finish the configuration of the Connections (i.e., modify the network interface and QoS selection) in the system integration phase (see 5.6.4.4).
Once the Connection configuration is complete, Engineer B transfers the Connection configurations for the ConnectionManager, including their QoS requirements, User Program, and network interface configuration, into Controller B using a vendor-specific engineering tool.