The worlds of operational technology (OT) and information technology (IT) are coming together in factories around the world, each with the same goal: use digitalization to improve productivity and other business objectives. But sometimes the two worlds require some translation and teamwork so that transactions between them flow as smoothly as possible.
OT systems must handle the parameters for all the production recipes, amounting to a lot of operational data and creating challenges for programmable logic controllers (PLC). Not only is a PLC’s memory very expensive, but its memory and performance are also optimized for production processes—from moving machines to making products. On the other hand, an SQL database, the centerpiece of IT systems, is good at handling complex data and tables and can relieve the computational burden from your PLC. In fact, your IT manager is probably already using one across your company to share information.
By implementing a transaction manager, you can control the worlds between the PLC and the SQL database. Doing so will relieve the burden from your PLC and also tap into the massive resource that is your enterprise SQL database.
To get started, just follow these three steps:
Prep the PLC. You’ll no longer need hard-coded recipes in your PLC. Instead, change these constants to tags in your PLC. Now, you’ll have one logic code base using variables, enabling you to update the variables each time you have a different part to manufacture. Each time there’s a new recipe, simply download it from the SQL database to the PLC.
Prep the SQL enterprise database. For your IT manager to create the table in the SQL database, you’ll need to provide him or her with three pieces of information: headers, recipe names and recipe data. Headers are a short description, or a column title, for your data. If you use Microsoft Excel as your tool to build a template, start by defining headers in the spreadsheet and placing these values at the top of each column.
In an SQL database, each row is called a record, and recipe names are placed in the first cell of each row. If you have 10 recipes, you’ll have 10 rows, or records. For each recipe, fill in the data values, which will be constants, for each column.
Implement a transaction manager. After you create the PLC tags and SQL table, the data needs to move between the PLC and database. This is where a transaction manager comes into place. Now that your tags are set up in your PLC, and your tables are set up in your SQL database, the transaction manager will log into the PLC and database and browse both tags (destination) and tables (source). The transaction manager is like your map—containing all the connections between PLC tags and table records. It also includes triggers to initiate the data movement.
The transaction manager controls the worlds between the PLC and the SQL database, and luckily for us, it understands them both so we don’t have to. A transaction manager also provides failover paths, email alerts upon successful transactions and status tags so we know when a transaction has been completed. And best of all, it requires no time-consuming code to set up and operate.
Transaction managers come in many forms. One example is our tManager, a PLC in-chassis transaction manager that moves plant floor data between ControlLogix® or CompactLogix™ PLC modules and SQL databases.
To learn more about the role of transaction managers in OT-IT cooperation, please read our full article.