Page 29

Industrial Ethernet Book 99

Technology A prototype implementation of deterministic OPC UA Leveraging IoT software, line operators can send pre-saved recipes with more than 20 parameters from a web interface to an IoT Gateway, which distributes the instructions to machines on the line. This approach is more effective than the previous manual process of providing device connectivity to multiple PLCs. OPC CLASSIC HAS ESTABLISHED ITSELF on the market as the standard for manufacturerindependent data exchange between applications. Since this standard is based on the COM/DCOM model from Microsoft, however, it is associated with a number of restrictions for the end user. This OPC technology is not suitable for communication over the Internet, for example, and cannot be used with firewalls or operated on non-Windows platforms; it also requires a wealth of specialized expertise for configuring data exchange between PCs. To resolve this problem, the OPC Foundation developed OPC UA (Unified Architecture), a fully revised and expanded version of the OPC standard that also accommodates the additional needs and requirements from industry customers, such as support for security mechanisms, protection against data loss, the setup of redundant connections, and support for complex data structures. OPC UA is a non-propriety version that is independent of the operating system, programming language or proprietary technologies deployed. It also supports scalability and high availability, and is Internet-capable. As a consequence, OPC UA has established itself over the last few years as the leading manufacturer-independent standard for data exchange between heterogeneous devices. Implementing the IIoT For industry, with its many needs and requirements, the OPC UA standard is an ideal solution and accordingly has major potential for the future. In fact, design decisions made for OPC UA also considered its use as a data exchange technology for the future implementation of the industrial Internet (Industrial Internet of Things, IIoT) and Industrie 4.0 applications. If we look a little more closely at the possible scenarios for an IIoT implementation, however, we quickly realize that their communication requirements are not perfectly matched by the communication features offered in the latest OPC UA standard. Some scenarios encountered require the implementation of communication strategies such as one-to-many, many-to-one and many-to-many, for example. Accordingly, the publisher/subscriber model is a better match for IIoT implementations than the OPC UA architecture for simplified data exchange between applications. client/server architecture defined in the OPC UA standard. The two use cases below offer a summary of the various use cases supported by the publisher/subscriber model. High data exchange use cases The following use cases have data exchange requirements that exceed an OPC UA client/ server’s capabilities. Public Subscription: Many clients require information about configuration changes for a list of variables. Data exchange takes place after initial system start-up and for each configuration change. The client/server model is not particularly efficient in handling this situation, for the following reasons: • A large number of client/server connections need to be made. • Each client needs to provide storage space for saving connection data and the various variable values. • Handling messaging for all of the existing connections is a heavy workload for the server processor. This server processor workload increases still further if clients are not using the same sampling rate for the variables. Secure Multicast: The server must send data to many clients. Data exchange is cyclic or takes place after every value change. Many-to-One Publishing: One or more clients in a cloud require data from many (thousands of) devices situated behind a firewall. Data exchange is cyclic or triggered by a change in value, quality value, or alarm. This situation cannot be handled, as this volume of open SOURCE: SOFTING connections cannot be processed in parallel. Machine-to-Machine Communication: Machinery exchanges process data downstream with machine modules and upstream with process visualization systems; ;otal transfer times must be between 2 and 100 ms. Process data may contain control data and status information conformant to ISA Technical Report TR88.00.02 (DIN EN 61512), such as PackML/PackTags. Data exchange is cyclic. Dynamic Network Connections: Mobile devices, such as optional machinery parts, mobile robots and mobile instruments, can be removed or added to a machine in a flexible fashion. This applies to robots supporting the full range of programming including the associated mobile devices, for example, and to remote procedure calls. Machinery and mobile devices have discrete control systems that need to communicate in a deterministic way. Some mobile devices are capable of performing multiple tasks (e.g. a mobile robot can weld at one location, perform adhesive work at another station and pick parts at a third station). When connecting a mobile device to a machine, an appropriate form of communication must be set up while taking the variable list and the mobile device’s functionality into account. Data exchange involves cyclic process data and remote function calls. OPC UA Multi-HMI: Complex control systems need to provide multiple servers with data simultaneously. As one example, many HMI (Human Machine Interface) applications visualize identical information at multiple 29 4.2017 industrial ethernet book


Industrial Ethernet Book 99
To see the actual publication please follow the link above