UAFX defines a mechanism for standardising the exchange of information used for establishing Connections between AutomationComponents (see 6.2) in an OfflineEngineering environment (see 6.4). From initial AutomationComponent development to on-site commissioning, engineers exchange offline data using the Descriptor (see 6.4). See OPC 10000-83 for more details regarding OfflineEngineering and Descriptors.
Assets and FunctionalEntities being used in applications, their available input, output, configuration data, and communication capabilities are shared between engineers using Descriptors. The Descriptor allows product and system configuration data to be added by different engineers using their engineering tools at each phase of the workflow until the configuration ultimately can be deployed in the field.
This subclause defines actors interacting with a UAFX system during the system's engineering that are referenced in workflow phase descriptions in all parts of the UAFX specifications.
Controls Engineers are responsible for the design of an automation or control system. Their primary responsibility is the programming/configuration of the application code in a PLC, PAC or DCS (etc.) necessary to execute algorithms defining the operation of a piece of equipment. In support of this function, they are typically responsible for integrating automation devices into the controller engineering tools and parameterising those devices with all information necessary for their correct functional operation.
Within Controls Engineer, there are multiple disciplines, including safety engineer, PLC programmer and process automation engineer, all of whom fulfil essentially the same function but with differing expertise.
The Network Engineer, a peer to the Controls Engineer, is responsible for designing and configuring the network infrastructure and implementing network technologies. At the machine or skid level, the Network Engineer is often the same individual as the Controls Engineer.
The Security Administrator has no direct stake in production operations or technologies. They are responsible for ensuring that there is no unauthorised access to production operations (whether from an outside hacker, inside bad actor or former employee). They are also charged with ensuring that the propagation of viruses, worms, malware, ransomware, etc., is restricted and that reasonable measures are taken to ensure resilience against these threats. They are responsible for the security of proprietary data entering and leaving facilities.
The System Commissioner or commissioning engineer is responsible for the start-up of a system once it has been installed in a manufacturing/processing plant. In some cases, the System Commissioner may have operated as Controls Engineer earlier in the project lifecycle. In machine/skid builders, the commissioning engineer may never have met the Controls Engineer in person as they may work in different locations, or the machine design may be many years old.
Figure 4 shows an example engineering workflow where Controls Engineers A and B jointly create a control application consisting of Controller A and Controller B while separated in time and space and potentially without the physical devices. Using Controller A’s engineering tool, Engineer A creates the User Program for Controller A and describes the inputs and outputs to be shared. Engineer A then exports an updated, signed Descriptor with the shared information. Engineer B then imports this Descriptor using Controller B’s engineering tool and adds the information needed for Controller A and B Connections. Engineer B may import additional Descriptors describing components used with their Controller or other Controllers to be connected. Engineer B then adds the Connection configuration needed to exchange the data required for the application.
NoteThis workflow describes the actions necessary for Controller B to obtain the data needed for its program during design time. If Controller A needs data from Controller B, it would need to import a Descriptor from Controller B to understand its interface.
Figure 4 – Engineering workflow – design and commissioning
Engineer A and Engineer B deploy their applications to their respective Controllers and deliver them to the site. Initial network address assignment is a precondition for the following steps.
Using a Security Provisioning Entity, the Security Administrator configures the Controllers for OPC UA security and rolls out the security policy required for the site per Controller, as shown in Figure 5. The security policy contains, amongst others, certificates, roles, and user management. For PubSub, this includes the configuration of the SecurityKeyServer (see OPC 10000-14). The Security Administrator may use a GlobalDiscoveryServer ( see OPC 10000-12) for security configuration.
Figure 5 – Security commissioning
The Network Engineer commissions the Controllers with a hostname, DNS information, and an IP address or address acquisition mechanism such as DHCP. The Network Engineer may apply firmware or software updates if needed.
Using a Network Provisioning Entity, the Network Engineer then rolls out the network configuration as required for the site using vendor-independent mechanisms and tools, such as a Network Provisioning Entity, as shown in Figure 6. The network configuration contains, amongst others, VLAN usage, the configuration of time synchronisation, and the configuration of QoS (see 6.3).
Figure 6 – Network commissioning
The System Commissioner may adjust the Connection configuration, such as addresses of Connection partners, publishing intervals, and QoS mapping tables using a generic OPC UA client or a tool based on standard OPC UA Client Server services, as shown in Figure 7.
Figure 7 – Connection commissioning
The ConnectionManager uses OPC UA Methods exposed by each AutomationComponent to establish the configured Connections when the system goes operational, as shown in Figure 8. See clause 6.2 for more details on Connections and the ConnectionManager.
See OPC 10000-81 for more details.
