Using FactoryTalk Optix for MES, ERP, and Plant-Floor Data Integration

FactoryTalk Optix is a modern, open-architecture visualization and IIoT platform from Rockwell Automation with obvious uses for HMI and SCADA applications, but its value doesn’t end there. Optix can also be implemented as a middleware layer between ERP/MES systems and PLC/SCADA applications on the plant floor. This approach comes with many advantages, providing benefits at the plant equipment, database, and MES levels.

Database integration, for instance, enables data buffering to improve resilience during outages, while full MES and ERP integration reduces manual data entry and improves traceability. Additionally, Optix’s built-in drivers simplify data aggregation from a variety of PLC platforms, databases, and other servers, and its .NET backend provides the flexibility to customize and scale the solution as project requirements and connected systems evolve.

Data Layer Components

Model Objects

Optix uses objects, located under the “Model” folder, to group and organize variables. Objects can contain variables of any data type, providing a structured way to organize application data. In the design environment, objects also host any events associated with them. This makes it easy to view data sources, identify related functions, and trace dependencies between variables. An example Motor object is shown below.

Model Types

A type is a generic object from which object instances can be made. In the example of the “Motor” object above, this object should be refactored into a type in order to create a set of motor instances, as shown below.

Object instances of a particular type can be added by navigating to the “type view” in the bottom left corner and dragging new instances of that type into the desired location. Each motor instance created updates with the type.

Communication Drivers

Optix includes built-in communication drivers that allow easy import from several PLC platforms.

The PLC’s available tag structures will be imported directly into the Optix project as field variables and made available for read/write functions. To keep the project lightweight and prevent performance issues, only import the necessary tags from a PLC.

OPCUA

Using the Open Platform Communications Unified Architecture (OPC UA) server and client, Optix applications publish data over OPC UA or read data from other OPC UA servers. These tags are imported into the project in a similar manner to the communication drivers.

MQTT

Using its MQTT client, Optix applications can publish plant-floor data to topics on an MQTT broker or subscribe to topics to receive data from other systems. The built-in broker and client components provide a lightweight, event-driven interface for connecting controllers and application data with cloud, IIoT, and enterprise systems.

Databases

Optix supports both embedded and external databases. Using SQLite, ODBC, and InfluxDB connections, Optix applications can read from and write to databases using standard SQL queries. This allows application data, historical records, recipes, and event information to be exchanged with enterprise systems while providing a centralized location for long-term data storage and reporting.

Custom NetLogic

Custom C# NetLogic scripts can easily interface with systems using protocols not supported by standard studio functions, such as REST APIs, SQL queries, and raw TCP messaging.

For example, the code below demonstrates a TCP client testing a connection to a station.

This code can be used within a NetLogic tasking implementation to connect to stations and send/receive messages.

Reading/Writing Data

Planning out and optimizing the dataflow within an Optix project is crucial to preventing project overloading and avoiding unintended behavior.

Dynamic Links

Dynamic links are the simplest way to define the data flow throughout the components of an Optix project.

To create a dynamic link:

1. Navigate to the variable location that will receive the data and select the button shown below.

2. In the navigation popup, select the variable to link to the host variable.

3. Reopen the dynamic link. Open “Advanced” and select the dynamic link direction. Dynamic links default to bi-directional, but it is best practice to set the intended direction and avoid using bi-directional dynamic links where possible.

	Direction	Description
	Bi-directional	Changes in either host or linked variable will set the other variable.
	Read only	Host variable reads linked variable.
	Write only	Host variable writes to linked variable

Additional dynamic link configurations are available under the “advanced” tab, which provide data transformation functions such as value converters, expression evaluators, and string formatters. This is a clean way to transform data based on the consumer’s needs.

Limitations

• Remote variable synchronizers must be used to drive dynamic link updates.
• Dynamic links cannot be used to write to OPC UA variables.
• Bi-directional dynamic links can potentially cause inconsistent behavior (if not accounted for) and should be used with caution.

Remote Variable Synchronizers

Remote variable synchronizers are objects which are used to keep project variables (variables which exist within the project structure) synchronized with field variables (external variables such as controller tag variables, OPC UA client/server variables, etc.) Dynamic links do not update consistently without remote variable synchronizers if the object being linked is not present on a screen.

Remote variable synchronizers are created in NetLogic scripts. The example below adds all object variables under the “Instances” folder to an RVS set at three seconds, unless the subfolder is specified as needing a higher refresh rate, in which case the variables are added to a one-second synchronizer.

Remote variable synchronizers are recommended only for lower tag quantities, as their update cycles can slow down project performance. To mitigate project performance risk, you can use multiple remote variable synchronizers at different update rates, as shown above.

For more details on remote variable synchronizer implementation, refer to the Rockwell Optix documentation in “References.”

Set Commands

Set commands can enact event-based variable writes instead of updating variables on regular intervals. These can be tied to tag change events on model variables to reduce the load on the synchronizers. For example, setting a PLC variable based on a tag-change event.

NetLogic Scripting

For more data read/write customization,  you can use NetLogic scripting. In particular, the IUAVariable.RemoteRead and IUAVariable.RemoteWrite can be used to attempt to write to a field variable and throw an error after a timeout. Using these functions as part of the wider NetLogic implementation can make data updates more deterministic and traceable.

The following method is a simple example that takes the NodeIds of source and destination variables and uses the RemoteWrite function to set the destination to the source value.

As a more advanced example, the following method uses the RemoteRead function to force a variable update on all children variables of a node, tracking the operation time.

For more information, see the Rockwell Optix Documentation and the NetLogic Cheat Sheet in “References.”

Data Bridging Examples

Simple Example: Siemens PLC > Optix > Rockwell PLC

You can accomplish simple data bridging using the following architecture. While you can create this implementation quickly, it offers no safeguards for data validity. The example below shows a Siemens PLC tag shuttled to a Rockwell PLC tag using Optix.

Advanced Example: API Endpoint > Optix > PLC

The example below shows a data exchange diagram where Optix queries and processes data from an API endpoint for use in a PLC. For sensitive data exchange between Optix and the PLC, handshakes should be implemented, as shown in the diagram.

In this example:

1. An API is periodically queried using NetLogic tasks.
2. C# functions process the data.
3. The data is written to model variables and a task which handshakes with the PLC is triggered.
4. The data is written to the PLC from model variables using dynamic links.
5. The PLC acknowledges the data, and the handshake task is completed.

The PLC now has data from the API endpoint.

Additional Architecture Tips

Proper architecture and application design is a critical part of any project. And with Optix, it is no different. As projects scale, it is possible to encounter performance issues if not properly designed. To reduce the risk of this, distribute the computational load between multiple Optix projects whenever possible. Additionally, hosting headless Optix data layers on IDC servers is recommended to maximize the resources the project has access to, which mitigates performance risks.